robotto7831a
Well-Known Member
Liest du eigentlich die Antworten?
Du verwendest einen veralteten Browser. Dieser kann eventuell diese oder andere Webseiten nicht richtig darstellen.
Du solltest deinen Browser aktualisieren oder einen alternativen Browser verwenden.
Du solltest deinen Browser aktualisieren oder einen alternativen Browser verwenden.
Cron-Jobs
- Ersteller des Themas hahni
- Erstellungsdatum
robotto7831a
Well-Known Member
Das nichts aber auch gar nichts ich betone nichts mit SSL zu tun.
robotto7831a
Well-Known Member
Das ist das was ich dir die ganze Zeit erzähle.
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?
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
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
Inwiefern hängt das eine vom anderen ab, oder anders gefragt: Wie kommst du darauf?Brauche ich Chroot für SSL?
robotto7831a
Well-Known Member
Fängst Du wieder mit dem SSL an?
Jailkit und jk_cp ist hier dein Stichwort.
Jailkit und jk_cp ist hier dein Stichwort.
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.
Na klar... und wenn du nicht schwimmen kannst, ist auch der Bademeister schuld...Irgendwas ist da an ISPConfig kaputt
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...
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.
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.
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
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
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
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 {} \;
--
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 {} \;
--
Zuletzt bearbeitet:
Support buchenWas mache ich denn nun? Leider habe ich es immer noch nicht zum Laufen bekommen.