# Cron-Jobs



## hahni (11. März 2018)

Hallo zusammen,

ich möchte bei den Magento-Installationen automatisch die Session-Verzeichnisse bereinigen. Dafür habe ich Skripte geschrieben, die auch in der Kommando-Zeile wunderbar funktionieren. Der Cronjob jedoch wird nicht ausgeführt. Ich habe diesen im Backend von ISPConfig entsprechend hinterlegt. Als Befehl habe ich in der entsprechenden Zeile z. B. "[web_root]/session_cleanup.sh" hinterlegt. Wäre dies so richtig?

Viele Grüße

Hahni


----------



## hahni (12. März 2018)

Nutzt niemand die Funktion oder möchte mir keiner helfen?


----------



## robotto7831a (12. März 2018)

Woher hast du denn den Platzhalter [web_root]?


----------



## hahni (12. März 2018)

Von ISPConfig. Daher dachte ich, dass ich den benutzen kann?


----------



## robotto7831a (12. März 2018)

Ah habe ich jetzt auch gesehen. 

Was sagt das Logfile?
Wird der Job in der Crondatei angelegt?


----------



## hahni (13. März 2018)

Ja. Im Filesystem liegt eine extra Datei für den Cron-Job.


----------



## hahni (13. März 2018)

Es gibt z. B. einen Cronjob "/etc/cron.d/ispc_chrooted_web211". Inhalt ist unter anderem:

--
0       3       *       *       *       web211  /web/session_cleanup.sh >/dev/null 2>&1
--

Nun stellt sich mir die Frage, ob der Pfad reicht oder ob der voll ausgeschriebene Pfad da stehen müsste. Syntaktisch wäre ja alles korrekt - meine ich!


----------



## robotto7831a (13. März 2018)

Der Pfad ist korrekt, da es ein Chrooted Cronjob ist. Stimmen die Berechtigungen?

Was sagt das Logfile bei der Ausführung?


----------



## hahni (13. März 2018)

Worauf muss denn bei den Berechtigungen geachtet werden? Besitzer und Gruppe ist der FTP-Benutzer und ausführbar auf der Console ist der Cron-Job auch... Logfiles werden keine erstellt. Sollten laut Beschreibung im "/private/"-Verzeichnis stehen. Und im Logs-Verzeichnis des Webs ist auch nichts zu finden.


----------



## robotto7831a (13. März 2018)

web211 sollte der Owner der Datei sein und das Ausführungsrecht haben. 

Was sagt das Syslog zum Zeitpunkt der Cronjob Ausführung?


----------



## hahni (13. März 2018)

Also an dem Benutzer sollte es nicht liegen:
--
-rwxr-xr-x  1 web211 client36    112 Okt  1 11:30 session_cleanup.sh
--


----------



## robotto7831a (14. März 2018)

Und was ist mit der anderen Frage?


----------



## Till (14. März 2018)

Generell zu Linux cronjobs: in shellscripten die von cron aufgerufen werden musst Du für Programme deren absoluten pfda verwenden.


----------



## hahni (14. März 2018)

Da steht leider kein Eintrag. Jedenfalls nicht im Cron-Log von ISPConfig, obwohl der Cron ja 5-minütlich ausgeführt werden sollte.

@Till 
Was habe ich demnach falsch gemacht?


----------



## Till (14. März 2018)

Ich habe nicht gesagt dass Du etwas falsch gemacht hast sondern Dir einen Hinweis gegeben was Du in Deinem cron script prüfen solltest, denn wenn ein script auf der shell manuell läuft aber nicht per cron, dann ist das von mir beschrieben Problem häufig die Ursache.


----------



## hahni (14. März 2018)

Aber die Einstellung im Backend stimmt, richtig? Der Inhalt im Cron-Job auch, oder? Und im Skript selbst (Inhalte kann ich ja gerne posten) habe ich auch direkte Aufrufe. Ich bin echt ratlos. Oder ist doch etwas an ISPConfig kaputt?


----------



## robotto7831a (14. März 2018)

Laufen deine Cronjobs in einer Chrooted Umgebung?

Leg doch mal einen Ordner web direkt unter / an und legt dort ein Shellskript mit dem gleichen Namen an und lass dir in dem Shellskript eine Mail schicken. Vielleicht will er dort ja ausführen. 

Du sollst auch im Syslog schauen was zu der Ausführungszeit steht. Dort steht nämlich der Cronjob, wenn er ausgeführt wird.


----------



## hahni (14. März 2018)

Nein, Chrooted-Umgebung läuft nicht - jedenfalls weiß ich nichts davon. Gilt das für SSL-Präsenzen?


----------



## robotto7831a (14. März 2018)

Was hat jetzt SSL damit zu tun?

Dann ist doch klar warum es nicht läuft. Er findet das Skript nicht. Was du vermutlich im Syslog siehst.


----------



## hahni (14. März 2018)

Einige der Webpräsenzen laufen mit SSL. Andere nicht. Und du meinst, dass wegen eingeschaltetem SSL der Aufruf nicht möglich ist?


----------



## robotto7831a (14. März 2018)

Liest du eigentlich die Antworten?


----------



## hahni (14. März 2018)

Lesen ja - aber nicht deuten. Und vor allem: wozu ist dann der Platzhalter, wenn er bei SSL nicht funktioniert?


----------



## robotto7831a (14. März 2018)

Das nichts aber auch gar nichts ich betone nichts mit SSL zu tun.


----------



## hahni (14. März 2018)

Dann bleibt nur die Möglichkeit, die Sache einmal mit einem relativen Pfad anstelle des Platzhalters auszuprobieren?


----------



## robotto7831a (14. März 2018)

Das ist das was ich dir die ganze Zeit erzähle.


----------



## Till (15. März 2018)

Es scheint sch ja um einen chrooted cronjob zu hendeln, dem Namen der datei nach: /etc/cron.d/ispc_chrooted_web211 daher müsste ein absoluter Pfad mit /web/.... ok sein, wenn die Datei im web Verzeichnis liegt. Aber: bei einem chrooted cronjob müssen natürlich auch alle Befehle die Du in Deinem cronjob verwendest im chroot installiert sein. Hast Du das geprüft?


----------



## hahni (15. März 2018)

Hallo Till,

die Frage ist ja grundsätzlich einmal, ob es chrooted überhaupt sein muss? Wenn nicht, wäre es doch einfacher, darauf zu verzichten. Die Befehle habe ich nicht im chroot eingetragen. Ich würde eher von einer einfachen Lösung träumen, die funktioniert.

Viele Grüße von

Hahni


----------



## Till (15. März 2018)

Ob Du einen cron als chrooted anlegst oder nicht liegt doch nur bei Dir. Dann lösche ihn halt und lege ihn als nicht chrooted in ISPConfig an wenn Du kein Chroot nutzen willst.


----------



## hahni (15. März 2018)

Und wo wähle ich das ab? Brauche ich Chroot für SSL?


----------



## nowayback (15. März 2018)

Zitat von hahni:


> Brauche ich Chroot für SSL?


Inwiefern hängt das eine vom anderen ab, oder anders gefragt: Wie kommst du darauf?


----------



## hahni (15. März 2018)

Ich habe schon in anderen Threads gelesen, dass es gefährlich ist, den Cron nicht als Chroot laufen zu lassen. Demnach würde ich es lieber als Chroot laufen lassen. Doch ich weiß eben nicht, wo ich die Skripte dann zusätzlich hinzufügen muss, damit alles läuft.


----------



## robotto7831a (15. März 2018)

Fängst Du wieder mit dem SSL an?

Jailkit und jk_cp ist hier dein Stichwort.


----------



## hahni (15. März 2018)

Da finde ich nichts. Jedenfalls auch im englischen Forum nichts, wie ich mein Cron zum Laufen bekomme. Irgendwas ist da an ISPConfig kaputt, wenn man zwar im Backend alles einstellen kann, aber es dann nicht läuft und man noch irgendwelche Skripte bei Chroot eintragen muss.


----------



## nowayback (15. März 2018)

Zitat von hahni:


> Irgendwas ist da an ISPConfig kaputt


Na klar... und wenn du nicht schwimmen kannst, ist auch der Bademeister schuld...

Jetzt hör aber mal auf. 
Zitat der Seite in deiner Signatur:


> Von Anfang an haben wir uns auf die Entwicklung von innovativer Individual-Software und Internetdienstleistungen (Betrieb des eigenen Rechenzentrums am Standort Nürnberg, Co-Location und Server-Housing sowie Domain-Delegation) spezialisiert.


Du oder dein Personal welches ein eigenes Rechenzentrum betreiben kann, wird wohl in der Lage sein zwischen Chroot und SSL unterscheiden zu können und auch in der Lage sein, rauszubekommen warum ein Cronjob nicht läuft oder welcher Pfad da eingetragen werden muss. Nur weil jemand zu dämlich ist in "euerm" Rechenzentrum das Licht anzumachen, ist auch auch noch lange nicht kaputt...


----------



## Till (15. März 2018)

Hahni, wie schon von meinen Vorrednern angemerkt ist da nichts in ISPConfig kaputt, aber man muss schon ein wenig wissen was man da macht. Du nutzt doch ISPConfig schon seit ISPConfig 2 wenn ich mich recht entsinne, betreibst also Servers eit 10 Jahren oder mehr, da müsstest Du doch inzwischen ein paar Grundlagen kennen.

Ich versuche es mal möglichst umgangssprachlich zu erläutern: Ein chroot ist eine reduzierte, abgeschottete, Umgebung in der man scripte ausführt, oder sich auch einloggen kann. Reduziert meint in diesem Zusammenhang dass dort nicht alle Programme vorliegen die es auf dem Server gibt. Wie Du selbst schon gelesen hast, dient dass der Sicherheit. Der andere aspekt ist das 'chroot' welches man mit Wechsel des Wurzelverzeicgnisses umschreiben kann. wenn man, oder ein script, im chroot ist, dann ist das Wurzelverzeichnis / nicht das / des servers sndern ein Unterverzeichnis, das Basisverzeichnis des chroot. Im Fall einer ISPConfig website ist / also das web root Verzeichnis.

Beispiel:

Das Verzeicgnis /var/www/clients/client1/web1/ auf dem Server ist das Verzeichnis / innerhalb des chroot. Man muss also, wenn man ein script programmiert dass in einem chroot laufen soll, beachten dass die Pfade im script sich auf das chroot beziehen.

Beispiel:

in einem script ohne chroot wüdest Du z.B. aufrufen:

rm -f /var/www/clients/client1/web1/tmp/*.sess

wenn dieses script im chroot läuft und dann noch als cron, müsste der Befehl lauten:

/bin/rm -f /tmp/*.sess

Woher kommen also die Differenzen.

1) Cron löst per default keine Pfade auf aus der $PATH variable, hatte ich erwähnt, daher muss es /bin/rm heißen und nicht nur rm.
2) Dann haben wir das chroot auf /var/www/clients/client1/web1/, wodurch im Pfad /var/www/clients/client1/web1/ zu / wird und der resulterende Pfad /tmp/*.sess ist.
3) Dann gibt es noch dass potentielle Problem dass Du in Deinem shellscript ein programm nutzt welches zwar auf dem Server installiert ist, aber nicht im chroot jail. Da kommt dann das jk_cp ins spiel, was @robotto7831a bereits erwähnt hat.

Also, wenn Du mit einem chroot nicht zurecht kommst, dann frage entweder jemanden ob er es für Dich einrichtet der sich damit auskennt oder Du legst den Cronjob ohne chroot an. Die pbige Erläuterungen sind übrigens auch nicht ISPConfig spezifisch sondern betreffen jedes chroot und jeden cronjob, auch wenn Du kein ISPConfig installiert hast. Und wie bereits mehrfach erwähnt Cron und Chroot haben nichts mit SSL zu tun.


----------



## hahni (16. März 2018)

Hallo Till,

vielen Dank für deine ausführliche Antwort. Zunächst einmal hast du recht, dass ich seit ISPConfig 2 mit an Bord bin. Da aber gingen die Cron-Jobs direkt in den letzten Versionen. Da gab es auch noch keine Chroot-Einstellungen.

Deine Erklärungen haben mir weitergeholfen. Es wäre aber trotzdem schön, wenn in der Oberfläche von ISPConfig 3 stehen würde, dass wenn in den Limits des Benutzers Chroot hinterlegt ist, beispielsweise anders mit den Crons agiert werden muss - und vor allem wie.

Genau das Problem habe ich ja nun. Da wäre ich sonst nie drauf gekommen. Und die Skripte an die neuen Pfade anzupassen, stellt sicherlich auch kein Problem dar. Aber wie ich die Skripte eben nun lauffähig bekomme, immer noch. Da helfen auch die Schlagworte nicht weiter.

Denn meine Suche war nicht erfolgreich diesbezüglich und wenn ich es richtig sehe, hatten vor mir auch schon andere Benutzer Probleme mit dieser Thematik (in EN- und DE-Forum).

LG

Hahni


----------



## Till (18. März 2018)

Zitat von hahni:


> Aber wie ich die Skripte eben nun lauffähig bekomme, immer noch. Da helfen auch die Schlagworte nicht weiter.


Ein Script unter Linux ist lauffähig wenn es das execute Bit (x) gesetzt hat. das ist aber nicht ISPConfig spezifisch oder spezifisch für cronjobs sondern es ist immer so. Das Execute Bit setzt man mit dem chmod Befehl, z.B.

chmod +x deinscript.sh


----------



## hahni (21. März 2018)

Lauffähig war das Skript vorher schon. Das habe ich ja geprüft. Das Problem besteht vielmehr, dass scheinbar die Pfade nicht gepasst haben (das hatte ich ja wegen Jailkit angepasst). Aber wenn ich es richtig verstanden habe, muss ja wegen der chroot-Umgebung auch noch etwas anderes geändert werden?

Und das Skript habe ich gemäß deinen sehr schönen und ausführlichen Erklärungen auch angepasst:
--
#!/bin/sh
/usr/bin/find /web/var/session -name 'sess_*' -type f -mtime +7 -exec /bin/rm {} \;
--


----------



## hahni (7. Apr. 2018)

Was mache ich denn nun? Leider habe ich es immer noch nicht zum Laufen bekommen.


----------



## nowayback (7. Apr. 2018)

Zitat von hahni:


> Was mache ich denn nun? Leider habe ich es immer noch nicht zum Laufen bekommen.


Support buchen


----------



## hahni (17. Apr. 2018)

Die schlechteste Hilfe, die ich bisher in diesem Forum erhalten habe. Besten Dank!


----------



## robotto7831a (17. Apr. 2018)

Man hat dir in diversen Threads erklärt, wie Du das Problem lösen kannst bzw. was geprüft werden muss um es lösen zu können. 

Da du es mit Hilfe der Beiträge nicht hinbekommst, ist der Hinweis auf kostenpflichtigen Support legitim. Du möchtest das Problem gelöst haben also hat man dir einen Hinweis gegeben wo Du weitere Hilfe bekommst. Manchmal muss man sich Sachen eben live im System anschauen um die Lösung zu finden bzw. dir zu sagen was genau dein Problem ist und wie es gelöst wird.


----------

