Cronjobs Jailkit PERL

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von ufreier, 10. Feb. 2012.

  1. ufreier

    ufreier New Member

    Hi,

    ich versuche gerade PERL-Scripts in chroot-Umgebungen via cron ausführen zu lassen, nicht wirklich erfolgreich. Jailkit scheint soweit zu laufen, jedenfalls legt er munter seine ganzen Verzeichnisse im Jail an, dreht die Rechte und gibt solche Meldungen in der messages:

    Code:
    Feb 10 18:48:01 unit2-1 /USR/SBIN/CRON[29999]: (web22) CMD (/srv/www/[...]/home/web22/test.pl^I#$domainname)
    Feb 10 18:48:01 unit2-1 jk_chrootsh[29999]: now entering jail /srv/www/clients/client4/web22 for user web22 (5016)
    Hier ist gleich die erste Frage: gibt man im ISPConfig-UI bei Cron Jobs den absoluten, maschinenphysikalischen Pfad zum Script an, oder den relativen im Jail (also z.B. /home/web22/test.pl)? Ich bekomme nämlich nie einen Fehler à la "file not found", egal was ich da reinschreibe.

    Aber auch egal wie ich es mache, das Script soll eine Datei anlegen und es tut nicht. Nun steht zwar in der "Serverkonfiguration" unter "Jailkit" in "Jailkit cron chrooted Anwendungen" u.a. /usr/bin/perl - aber im Jail selbst unter /usr/bin hat's kein perl. Muss man das (natürlich sinnvollerweise mit seinen libs) erst noch manuell ins Jail kopieren?

    Gruß, Uwe
     
  2. ufreier

    ufreier New Member

    hab's gefunden

    okay... also die "Jailkit chroot Anwendungsbereiche" in der Serverkonfiguration um "perl" erweitern und im ISPConfig-UI den relativen Pfad zum Script eintragen, dann klappt's.

    Gruß, Uwe
     
  3. ufreier

    ufreier New Member

    OTRS ISPConfig Jailkit Chroot Mini-Howto

    zum Abschließen dieses Threads habe ich mal ein Mini-Howto geschrieben, wie man OTRS unter ISPConfig im chroot des Jailkits zum Laufen bringt. Evtl. interessiert das ja den einen oder anderen.
    Das Ganze ist für ein OTRS 3.1.1 unter openSUSE 11.4 /64 bit, bei anderen Distributionen sind an entsprechenden Stellen ggf. andere Register zu ziehen.

    Anpassen der Apache-Conf unter Webdomain -> Optionen:

    Code:
    DocumentRoot /srv/www/clients/clientX/webY/web/var/httpd/htdocs
    ScriptAlias /otrs/ /srv/www/clients/clientX/webY/web/bin/cgi-bin/
    Alias /otrs-web/ /srv/www/clients/clientX/webY/web/var/httpd/htdocs/
    
    <Directory /srv/www/clients/clientX/webY/web/bin/cgi-bin>
     AllowOverride None
     Options +ExecCGI -Includes
     Order allow,deny
     Allow from all
    </Directory>
    
    <Directory /srv/www/clients/clientX/webY/web/var/httpd/htdocs>
     AllowOverride None
     Order allow,deny
     Allow from all
    </Directory>
    
    <IfModule mod_headers.c>
        <Directory "/srv/www/clients/clientX/webY/var/httpd/htdocs/skins/*/*/css-cache">
            <FilesMatch "\.(css|CSS)$">
                Header set Cache-Control "max-age=2592000 must-revalidate"
            </FilesMatch>
        </Directory>
    
        <Directory "/srv/www/clients/clientX/webY/var/httpd/htdocs/js/js-cache">
            <FilesMatch "\.(js|JS)$">
                Header set Cache-Control "max-age=2592000 must-revalidate"
            </FilesMatch>
        </Directory>
    </IfModule>
    
    Wir brauchen PERL im Jail. Serverkonfiguration -> Jailkit chroot Anwendungsbereiche -> perl hinzufuegen.
    Wenn manuell, die notwendigen executables/paths stehen auch in der jk_init.ini bei [perl].
    BTW: die anderen Sachen mal kurz ueberfliegen, je weniger desto besser, HINT: OTRS braucht kein SSH, SFTP etc.

    Cron auf max. erlaubt chrooted stellen (unter Kunde -> Limits).

    Wir brauchen fuer OTRS die mySQL-Client-Libs im Jail, d.h.

    Code:
    cd $JAIL
    cp /usr/lib64/libmysqlclient.so.16.0.0 usr/lib64/
    cd usr/lib64/
    ln -s libmysqlclient.so.16.0.0 libmysqlclient.so
    ln -s libmysqlclient.so.16.0.0 libmysqlclient.so.16
    
    Anmerkung: bei anderen Versionen muss die Anpassung analog erfolgen.

    Wir brauchen einen Syslog-Socket im JAIL,

    Code:
     
    vi /etc/sysconfig/syslog
    ++ SYSLOGD_ADDITIONAL_SOCKET_JAIL_OTRS="/srv/www/$domain/dev/log"
    
    Anmerkung: in anderen Distributionen muss man dem syslogd mit
    der Option "-a" den zusätzlichen Socket übergeben.

    Die OTRS-Konfiguration muss etwas an die JAIL-Anforderungen angepasst werden,

    Code:
    cd $JAIL
    vi web/Kernel/Config.pm
    
    OTRS wird die mySQL im JAIL nicht ueber socket bekommen, also auf tcp umstellen mit

    Code:
     
    -- $Self->{DatabaseHost} = 'localhost';
    ++ $Self->{DatabaseHost} = '127.0.0.1';
    
    -- $Self->{Home} = '/opt/otrs';
    ++ $Self->{Home} = '/srv/www/$domain/web';
    
    wobei der der Pfad

    $Self->{Home} = '/srv/www/$domain/web';

    ein zweischneidiges Schwert ist, einerseits braucht der Webserver den systemischen, die Cron-
    gesteuerten Scripts jedoch den Pfad im JAIL, dazu linken wir

    Code:
     
    mkdir srv
    mkdir srv/www
    mkdir srv/www/$domain
    cd srv/www/$domain
    ln -s ../../../web/ ./web
    
    Jetzt stimmt der Pfad sowohl als auch.

    Im JAIL gibt's kein sendmail, OTRS auf SMTP umstellen,

    Code:
    Im OTRS Backend: 
    
    Admin -> SysConfig
    Framework::Core::Sendmail
    
    Die otrs.cleanup braucht eine Spezialbehandlung:

    Code:
     
    cd JAIL
    vi web/bin/otrs.cleanup
     
    -- OTRS_ROOT=$HOME
    ++ OTRS_ROOT=/web
    
    Dann die OTRS-Cronjobs so in die ISPConfig-UI eintragen:

    Code:
     
    20 0 * * 0  /web/bin/otrs.DeleteCache.pl --expired
    30 0 * * 0  /web/bin/otrs.LoaderCache.pl -o delete
    */20 * * * *    /web/bin/otrs.GenericAgent.pl
    */10 * * * *    /web/bin/otrs.GenericAgent.pl -c db
    45 */2 * * *    /web/bin/otrs.PendingJobs.pl
    10 0 * * *  /web/bin/otrs.cleanup
    */10 * * * *    /web/bin/otrs.PostMasterMailbox.pl
    01 01 * * * /web/bin/otrs.RebuildTicketIndex.pl
    55 */2 * * *    /web/bin/otrs.DeleteSessionIDs.pl --expired
    35 * * * *  /web/bin/otrs.UnlockTickets.pl --timeout
    
    Done.
     
  4. Till

    Till Administrator

    Danke für das Howto!
     
  5. ufreier

    ufreier New Member

    Automatische Rechteverstellung bei chroot jails

    ein Problem bleibt, ich habe das jetzt über einen längeren Zeitraum beobachtet, um einfach sicher zu gehen, dass ich nicht durch welche Handlung auch immer dieses Phänomen aktiv hervorrufe.
    Es passiert von Zeit zu Zeit, dass gechrootete (oh weh...) Website-Root-Directories auf den ursprünglichen Owner (webY:clientX) und die Rechte auf 751 zurückgesetzt werden - ich weiß nicht wann das passiert und habe leider keine Vermutung, durch was es ausgelöst wird, sonst hätte ich da selbst schon tiefer nachgeforscht.
    Folge: natürlich kommt Jailkit nicht damit klar, dass das Root-Directory nicht mehr root:root hat und verweigert seinen Dienst beim Versuch z.B. über cron gesteuert PERL-Scripts auszuführen mit der logischen Meldung

    Code:
    [...] jk_chrootsh[17482]: path /srv/www/clients/clientX/webY is not owned by user 0
    [...] jk_chrootsh[17482]: path /srv/www/clients/clientX/webY is not owned by group 0
    [...] /srv/www/clients/clientX/webY is not a safe chroot jail.
    
    Die Besitzverhältnisse des Root-Directories wieder auf root:root und die Rechte auf 755 setzen heilt die Sache zwar, jedoch geschehen diese Vorfälle natürlich 'silently', d.h. man bekommt es erst einmal nicht mit, dass die Cronjobs nicht mehr ausgeführt werden und das ist extrem lästig - man verlässt sich ja irgendwo darauf.

    Der Vollständigkeit halber: es bezieht sich ausschließlich auf das Root-Directory, es werden darunter keine Rechte geändert und auch die /etc/passwd wird nicht zurückgesetzt, dort bleibt der Eintrag mit 'jk_chrootsh" erhalten.

    Hat jemand eine Idee wo/wie man hier ansetzen kann?

    Gruß, Uwe
     
  6. Till

    Till Administrator

    Welche ISPConfig Version verwendest Du denn und hast Du ispconfig so konfiguriert dass er die Rechte des Webs bei Änderungen neu setzen soll oder nicht?
     
  7. ufreier

    ufreier New Member

    3.0.4.3 und der Haken bei 'Set folder permissions on update' gehört einfach raus, richtig? Mist, habe ich übersehen. Reingemacht habe ich ihn nicht, aber natürlich auch nicht rausgenommen.

    Vielen Dank und Gruß, Uwe
     
  8. Till

    Till Administrator

    Wenn die Berechtigungen nach dem anlegen nicht mehr geändert werden sollen, dann muss er raus.
     
  9. ufreier

    ufreier New Member

    Alles klar, vielen Dank nochmal! Wie ich gerade sehe gehört das zu den noch 'undokumentierten Features'.:) Also in der Doku zum 3.0.4 ist es noch nicht drin.

    Gruß, Uwe
     
  10. Till

    Till Administrator

    ja, es wurde nach dem 3.0.4.0 Release eingebaut.
     

Diese Seite empfehlen