# ISPConfig3 / MySQLDumper Cronjob



## novamax (27. Juli 2012)

Das Thema ISPConfig-Cronjob mit MySQLDumper scheint hier wirklich ein Dauerbrenner zu sein, aber ich konnte aus den bisherigen Beiträgen die Lösung nicht rauslesen...

Was läuft:
Ich betreibe einen vServer mit Debian queeze und ISPConfig. Die Hauptdomain läuft unter einem reseller (Ich habe subdomains dann als Kunden eingerichtet). MySQL-Dumper liegt im /web Verzeichnis dieses Resellers. Skript und Module sind korrekt konfiguriert. In MySQLDumper geht Alles rund und ich kann das Backup bei URL im Browser aufrufen.

Was nicht läuft:
Cronjob in ISPConfig3 ruft das Skript nicht zum dort eingetragenen Zeitpunkt auf:
- sowohl root-Cronjob als auch Reseller-Cronjob: fail (kein Backup).
- Befehle von mySQLDumper (in putty: funktioniert) wg. der "jailkit"-Hinweise um vollen Pfad zu perl ergänzt. Sowohl für root/usr/bin als auch für web1/usr/bin: fail.
- relative und absolute Pfade zum Skript: fail.

Ich bin wirklich ratlos und würde mich über Hinweise freuen, wie ich den Fehler finden kann.


----------



## novamax (27. Juli 2012)

Nachtrag: Im Reiter "ISPConfig Cron Error Log" (root) habe ich eine Fehlermeldung gefunden, dass er den User nicht verändern kann. Es scheint auf diese Zeile hinauszulaufen:

ERROR: /usr/bin/lesspipe does not exist

Ich habe den Server nicht selbst aufgesetzt, sondern er war per Image von meinem vServer-Hoster konfiguriert. Ich habe schon diverse Packages nachinstallieren müssen. (MIME::Lite, NET:FTPSSL).


----------



## Till (27. Juli 2012)

Also von einem Dauerbrenner würde ich bei dem Thema nicht gerade sprechen, da müsstest Du bei der Verbreitung von ISPConfig schon ein par hundert bis tausend Threads zu dem Thema hier bzw. im englischen Forum haben denn ISPConfig wird auf ca. 40 tausend Servern pro Monat installiert. Mysqldumper ist doch als url über http erreichbar? Dann erstellst Du den Cronjob einfach indem Du die URL als cron Befehl einträgst, also:

http://www.deinedomain.de/abcde/mysqlumper.php

um den Rest kümmert sich ISPConfig automatisch.


----------



## novamax (27. Juli 2012)

Naja, Dauerbrenner war sicher übertrieben, das Thema "Cronjob läuft nicht" scheint halt kein Einzelfall zu sein, sondern mit unterschiedlichen Ursachen immer mal wieder jemanden zu beschäftigen - Ist ja offenbar auch nicht trivial...

Den URL-Aufruf habe ich schon probiert - Aufruf im Browser läuft, im Cronjob wird er nicht ausgelöst. Ich habe nicht den Eindruck, dass der Befehl fehlerhaft ist, sondern dass der Cronjob gar nicht erst aktiv wird... 

Ich habe den Cronjob mal testweise umgebaut:
touch /var/www/clients/<clientX>/<webY>/web/crontest.txt
sowie mit /usr/bin/touch (...) und /var/www/clients/<clientX>/<webY>/usr/bin/touch (...)

Wenn ich es richtig verstehe, müsste danach im ./web-Verzeichnis eine neue  leere Datei crontest.txt liegen - Tut sie aber nicht.

Als Zeit habe ich nur die Stunde und die Minute des Backups angegeben... Leider ist die Uhrzeit des vHosts bei meinem Provide um knapp Stunden verstellt, aber das habe ich berücksichtigt... Ich habe es jetzt sogar mit Sternchen überall probiert (Ausführung jede Minute). Keine Aktion.


----------



## novamax (27. Juli 2012)

Stopp!
/usr/bin/touch /var/www/clients/<clientX>/<webY>/web/crontest.txt
hat funktioniert! Die Datei wurde von clientX/webY angelegt (Der Cronjob ist der Website zugeordnet).

Keine Ahnung, warum die minütliche Ausführung auf sich warten lässt - Vielleicht braucht der Indianer 'ne Weile, bis der die Rauchzeichen verarbeitet hat. Dann geht's auch regelmäßig...

/usr/bin/ würde aber bedeuten, dass ClientX auf root zugriff hat - richtig? Das dürfte er doch mit Jailkit gar nicht...?

Edit: Jetzt hat er auch ein Backup geschoben! Hurra - Endlich redundante Sicherheit!
Ich war wohl etwas eilig mit dem Prüfen und hab's dann zu schnell wieder geändert. Jetzt wo ich mich getraut hatte, den Cron minütlich loszuschicken und den Trick mit dem Pfad für perl berücksichtigt hatte, den ich hier 1-2x gelesen hatte, geht's endlich!

Danke für die Geduld!


----------



## F4RR3LL (27. Juli 2012)

Zitat von novamax:


> /usr/bin/ würde aber bedeuten, dass ClientX auf root zugriff hat - richtig? Das dürfte er doch mit Jailkit gar nicht...?


Innerhalb des Jails ist dies genau der richtig Pfad. Extern als root gesehen wäre der Pfad /da/wo/das/Jail/liegt/usr/bin.... innerhalb des Jails eben obiges. Passt.


Gruß Sven


----------



## novamax (28. Juli 2012)

Stimmt, hab grad gesehen, dass es auch im /usr/bin/Verzeichnis des Client liegt (Hatte Perl ja auch dem User freigegeben).

Hätte ich den Pfad des .pl-Skripts denn genauso abkürzen können? Den vollen Pfad für das Skript hab ich ja von MSD übernommen (genauso wie den Befehl perl ohne Pfad... ) - An sich dürfte der ja für den User gar nicht funktionieren, wenn die Pfadangaben relativ zum "User-Root" sind?

Will mich nicht beschweren - läuft ja Alles. Aber wenn ich schon am Dazulernen bin, dann will ich's komplett verstehen


----------

