Die Möglichkeit, die Synology im 3rd_party_integration_guide aufzeigt (Seite 20), läuft über ein cgi-Skript. Könnte man damit nicht aus PHP heraus prüfen, ob auch wirklich der admin eingeloggt ist?
CronJobs - die Alternative
- Ersteller itari
- Erstellt am
- Status
Matthieu
Benutzer
- Mitglied seit
- 03. Nov 2008
- Beiträge
- 13.222
- Punkte für Reaktionen
- 88
- Punkte
- 344
- Mitglied seit
- 15. Mai 2008
- Beiträge
- 21.900
- Punkte für Reaktionen
- 14
- Punkte
- 0
Ja das ist beim AdminTool so. Bei jedem AJAX-Request auf die Standard-Befehlsausführung wird überprüft, ob der angemeldete User auch der 'admin' ist und ob das Verfallsdatum des ID-Cookie noch nicht überschritten ist (das ist das, welches man via DS-Manager einstellen kann). Auch wird geprüft, ob der Aufruf aus dem lokalen Netz erfolgt ... wenn nicht, dann wird HTTP-Code 403 ausgegeben.
Die Diskussion dazu kann man in dem ersten Diskussions-Thread des AdminTools nachlesen.
Itari
cronjob.spk command
Das Paket läuft wunderbar. Nur leider bekomme ich mein backup.php-Skript nicht zum Laufen
Pfad des Skripts: /volume1/web/meineBackups/auto/backup.php
Über einen Browser aufgerufen tut das Skript, was es soll (http://diskstation/meineBackups/auto/backup.php)
In cronjob eingetragen...
User: root
Command: php /volume1/web/meineBackups/auto/backup.php
Im cron-Log steht:
USER root pid 19394 cmd php /volume1/web/meineBackups/auto/backup.php
Ausgeführt wurde das Skript nicht bzw. es gab keinen Output in Form des Backups.
Wie ruft man das Skript in cronjobs richtig auf?
Das Paket läuft wunderbar. Nur leider bekomme ich mein backup.php-Skript nicht zum Laufen
Pfad des Skripts: /volume1/web/meineBackups/auto/backup.php
Über einen Browser aufgerufen tut das Skript, was es soll (http://diskstation/meineBackups/auto/backup.php)
In cronjob eingetragen...
User: root
Command: php /volume1/web/meineBackups/auto/backup.php
Im cron-Log steht:
USER root pid 19394 cmd php /volume1/web/meineBackups/auto/backup.php
Ausgeführt wurde das Skript nicht bzw. es gab keinen Output in Form des Backups.
Wie ruft man das Skript in cronjobs richtig auf?
jahlives
Benutzer
- Mitglied seit
- 19. Aug 2008
- Beiträge
- 18.275
- Punkte für Reaktionen
- 4
- Punkte
- 0
Wahrscheinlich findet der cron den php Interpreter nicht. In cronjobs würde ich immer komplette Pfadangaben zu einem Befehl verwenden.
Der php Interpreter liegt afaik unter /usr/bin, du kannst den korrekten Pfad eines Befehls aber immer mittels
herausbekommen. Wobei du php natürlich durch den Befehl ersetzen musst den du suchst.
Der php Interpreter liegt afaik unter /usr/bin, du kannst den korrekten Pfad eines Befehls aber immer mittels
Code:
which phpDanke jahlives für deine Antwort.
Ja, der Pfad ist nötig. Mit folgendem Aufruf funktioniert der Cronjob: /usr/bin/php -f /pfad/zum/skript.php
Ja, der Pfad ist nötig. Mit folgendem Aufruf funktioniert der Cronjob: /usr/bin/php -f /pfad/zum/skript.php
cronjob geht nicht nach DSM Update
Hallo!
Nach dem Update auf die DSM 3.0-1354 ging cronjob bei mir leider nicht mehr, d.h. es kam beim Aufruf der URL "Seite nicht gefunden...".
Ich hatte seinerzeit die "Ursprungsversion", also die cronjob.php und application.cfg händisch angelegt.
Die Dateien waren nach dem Update alle noch da.
Habe die Dateien dann gelöscht und cronjob nochmal per spk installiert, kein Erfolg.
Dann init_3rdParty erneut installiert, Neustart, kein Erfolg.
Die Dateien liegen jetzt alle unter /usr/syno/synoman/webman/3rdparty/cronjobs/.
Ich habe nun einen Symlink von /usr/syno/synoman/webman/3rdparty/cronjobs/cronjobs.php nach /usr/syno/synoman/phpsrc/cronjob/cronjobs.php gesetzt und nun gehts.
Mit anderen spks haben aber das gleiche Problem, d.h. ich komme nicht über den Browser auf die php-Dateien.
Was muss tun damit es wieder ohne irgendwelche symlinks geht?
Ich dachte an /usr/syno/apache/conf/httpd.conf-sys ändern damit er wieder auf das richtige Verzeichnis kommt? Oder muss ich was am user-apache machen (läuft auch bei mir)?
DocumentRoot ist "/usr/syno/synoman"
Komme leider nicht alleine weiter, hoffe mir kann jemand einen Hinweis geben,
Gruß
Zentis
Hallo!
Nach dem Update auf die DSM 3.0-1354 ging cronjob bei mir leider nicht mehr, d.h. es kam beim Aufruf der URL "Seite nicht gefunden...".
Ich hatte seinerzeit die "Ursprungsversion", also die cronjob.php und application.cfg händisch angelegt.
Die Dateien waren nach dem Update alle noch da.
Habe die Dateien dann gelöscht und cronjob nochmal per spk installiert, kein Erfolg.
Dann init_3rdParty erneut installiert, Neustart, kein Erfolg.
Die Dateien liegen jetzt alle unter /usr/syno/synoman/webman/3rdparty/cronjobs/.
Ich habe nun einen Symlink von /usr/syno/synoman/webman/3rdparty/cronjobs/cronjobs.php nach /usr/syno/synoman/phpsrc/cronjob/cronjobs.php gesetzt und nun gehts.
Mit anderen spks haben aber das gleiche Problem, d.h. ich komme nicht über den Browser auf die php-Dateien.
Was muss tun damit es wieder ohne irgendwelche symlinks geht?
Ich dachte an /usr/syno/apache/conf/httpd.conf-sys ändern damit er wieder auf das richtige Verzeichnis kommt? Oder muss ich was am user-apache machen (läuft auch bei mir)?
DocumentRoot ist "/usr/syno/synoman"
Komme leider nicht alleine weiter, hoffe mir kann jemand einen Hinweis geben,
Gruß
Zentis
garnichts
Die URL hat sich wohl geändert, habe gerade festgestellt
mit https://ip-der-synology:5001/webman/3rdparty/cronjobs/cronjobs.php
geht es auch mit der aktuellen Version vom DSM...
Die URL hat sich wohl geändert, habe gerade festgestellt
mit https://ip-der-synology:5001/webman/3rdparty/cronjobs/cronjobs.php
geht es auch mit der aktuellen Version vom DSM...
Mexx
Benutzer
- Mitglied seit
- 27. Aug 2007
- Beiträge
- 553
- Punkte für Reaktionen
- 0
- Punkte
- 42
servus itari
warum? kann ich dir sagen, ich finde das durch diese sehr vielen fred´s das ganze ziemlich unübersichtlich geworden ist, genau so geht es mir auch bei dem ipgk
brauche ich jetzt nur das admin tool oder noch andere schritte davor ?
thx
warum? kann ich dir sagen, ich finde das durch diese sehr vielen fred´s das ganze ziemlich unübersichtlich geworden ist, genau so geht es mir auch bei dem ipgk
brauche ich jetzt nur das admin tool oder noch andere schritte davor ?
thx
- Mitglied seit
- 15. Mai 2008
- Beiträge
- 21.900
- Punkte für Reaktionen
- 14
- Punkte
- 0
Der Gedanke ist recht einfach ... ich hatte mir letztes Jahr überlegt, ob ich die Tools nicht alle zusammenfassen kann und mittels eines spk installieren könnte. Daraus ist das AdminTool geworden. Hier steht so ziemlich alles, was du brauchst und berücksichtigen musst. Und klar .. für manche Funktionen brauchst zusätzlich per IPKG installierte Unterstützung (habe das auch in einem Skript zusammengefasst - nur der IPKG-Bootstrap ist wie im Wiki beschrieben nötig).
Es ist ein Angebot ... ob du es machst, bleibt dir überlassen. Ich wollte nur erklären, dass ich die anderen Skripte nicht mehr groß im Auge habe, weil es dafür einen Ersatz gibt. Selbstverständlich laufen die anderen Skripte auch weiterhin, aber es kann sein, dass man das ein oder andere ab DSM 3.0 anders machen muss oder abändern muss - und das werde ich mir nicht mehr in meiner Freizeit an tuen.
Zum Thema IPKG habe ich nichts wirklich Neues oder Verwirrendes bemerken können. Außer dass es wächst und für die neuen Modell (noch) nicht immer alles vorhanden ist.
Itari
Hervorragene Arbeit!
Ich habe erst die Vorlage von Tuono genutzt. Da hatte ich allerdings das Problem das die Crontab garnicht verändert wird bzw. garnicht richtig eingelesen wird. Nach dem Editieren oder neuanlegen wäre es Sinnvoll das wieder nach cronjob.php gesprungen wird. Die Vorlage von Wizjos hatte dies dann berücksichtigt und die Crontab wurde auch entsprechend verändert und korrekt eingelesen. Nur hab ich einen Fehler entdeckt den vielleicht nochmal jemand ändern könnte. Da ich kein php Crack bin.
Crond akzeptiert für Wday keine 7, sondern nur die 0. Bei mir ist das jedenfalls so. Der deamon startet erst korrekt wenn statt der 7 eine 0 verwendet wird!
Auch sehr schön aus der Fehlermeldung im Log zu sehen
Ich habe erst die Vorlage von Tuono genutzt. Da hatte ich allerdings das Problem das die Crontab garnicht verändert wird bzw. garnicht richtig eingelesen wird. Nach dem Editieren oder neuanlegen wäre es Sinnvoll das wieder nach cronjob.php gesprungen wird. Die Vorlage von Wizjos hatte dies dann berücksichtigt und die Crontab wurde auch entsprechend verändert und korrekt eingelesen. Nur hab ich einen Fehler entdeckt den vielleicht nochmal jemand ändern könnte. Da ich kein php Crack bin.
Crond akzeptiert für Wday keine 7, sondern nur die 0. Bei mir ist das jedenfalls so. Der deamon startet erst korrekt wenn statt der 7 eine 0 verwendet wird!
Auch sehr schön aus der Fehlermeldung im Log zu sehen
Rich (BBCode):
failed user root parsing 1-4,7 root /opt/bin/bash /opt/var/etc/shutdown.sh #test@ itari:
Hallo itari ich habe da eine Frage zu deinem CRONTAB Paket. Finde irgendwie nicht, dass ich dir ne PN schicken kann^^ Würde Crontab gerne bei mir an der Arbeit auf einen RS407 installieren, der nur als Intranet Server dient. Darf ich es da benutzen oder wie scahut das mit den Rechten aus?
Gruß
Hallo itari ich habe da eine Frage zu deinem CRONTAB Paket. Finde irgendwie nicht, dass ich dir ne PN schicken kann^^ Würde Crontab gerne bei mir an der Arbeit auf einen RS407 installieren, der nur als Intranet Server dient. Darf ich es da benutzen oder wie scahut das mit den Rechten aus?
Gruß
@itari
erstmal ein Lob, eine GUI für die etc/crontab zu basteln ist ne feine Sache, für alle die cronjobs kompfortabel per Webinterface eintragen wollen, auch ich benutze deine GUI.
Als ich mich die Tage mal etwas in die DiskStation cronjobs Materie eingelesen habe stiess ich auf folgende Sache:
Da ich selbst noch nie mit sogenannten "special time specifications" gearbeitet habe, dachte ich mir probierste es doch mal aus.
Habe also ein kleines Shellskript geschrieben das ausgeführt werden soll und zwar mit dem ersten dieser "special time specifications": 1. @reboot
Da dieses "@reboot" ja die 5 zeitlichen Angaben ersetzen soll habe ich es in der cronjob GUI ins erste Feld eingetragen und die restlichen 4 Felder leer gelassen. Als Benutzer habe ich "root" eingetragen (siehe Screenshot).
Leider hat dies nicht funktioniert und das Shellskript wurde nach dem Reboot nicht ausgeführt, schlimmer noch der Eintrag wurde einfach wieder herausgelöscht.
Nun versuchte ich diesen Eintrag manuell vorzunehmen ohne die GUI, ich editierte also die "etc/crontab" und ergänzte sie mit folgendem Eintrag:
Nach dem Neustarten meiner Box (DS409/DSM3.1) trat wieder das selbe Problem auf, mein Eintrag wurde einfach aus der crontab gelöscht.
Infos zur "test.sh": Simples Skript das eine log Datei erstellt um zu sehn das es ausgeführt wurde. Es hat 755-Rechte.
Ich habe es auch ohne der Angabe des Benutzers "root" versucht auch ohne Erfolg.
Was mache ich falsch?
MfG pulsar
erstmal ein Lob, eine GUI für die etc/crontab zu basteln ist ne feine Sache, für alle die cronjobs kompfortabel per Webinterface eintragen wollen, auch ich benutze deine GUI.
Als ich mich die Tage mal etwas in die DiskStation cronjobs Materie eingelesen habe stiess ich auf folgende Sache:
Dieser Auszug stammt aus dem Wiki: http://www.synology-wiki.de/index.php/Cron
Da ich selbst noch nie mit sogenannten "special time specifications" gearbeitet habe, dachte ich mir probierste es doch mal aus.
Habe also ein kleines Shellskript geschrieben das ausgeführt werden soll und zwar mit dem ersten dieser "special time specifications": 1. @reboot
Da dieses "@reboot" ja die 5 zeitlichen Angaben ersetzen soll habe ich es in der cronjob GUI ins erste Feld eingetragen und die restlichen 4 Felder leer gelassen. Als Benutzer habe ich "root" eingetragen (siehe Screenshot).
Leider hat dies nicht funktioniert und das Shellskript wurde nach dem Reboot nicht ausgeführt, schlimmer noch der Eintrag wurde einfach wieder herausgelöscht.
Nun versuchte ich diesen Eintrag manuell vorzunehmen ohne die GUI, ich editierte also die "etc/crontab" und ergänzte sie mit folgendem Eintrag:
Rich (BBCode):
@reboot root sh /temp/test.shInfos zur "test.sh": Simples Skript das eine log Datei erstellt um zu sehn das es ausgeführt wurde. Es hat 755-Rechte.
Ich habe es auch ohne der Angabe des Benutzers "root" versucht auch ohne Erfolg.
Was mache ich falsch?
MfG pulsar
Hallo,
ich denke das geht nur mit dem ipkg crond. Synology benutzt einen angepassten und abgespeckten crond der busybox der mit den specials nicht anfangen kann. Es wird bei jedem Start geprüft ob die Syntax in /etc/crontab richtig ist und entsprechend fehlerhafte Einträge rausgeworfen. Wenn Du ein Sript zum Systemstart laufen lassen willst, packe es mit ordentlichen
start/stop Zweigen nach /usr/local/etc/rd.d
Gruß Götz
ich denke das geht nur mit dem ipkg crond. Synology benutzt einen angepassten und abgespeckten crond der busybox der mit den specials nicht anfangen kann. Es wird bei jedem Start geprüft ob die Syntax in /etc/crontab richtig ist und entsprechend fehlerhafte Einträge rausgeworfen. Wenn Du ein Sript zum Systemstart laufen lassen willst, packe es mit ordentlichen
start/stop Zweigen nach /usr/local/etc/rd.d
Gruß Götz
Da bin ich ganz deiner Meinung goetz, vermutlich packt das busybox crond das nicht. Wär vielleicht nicht verkehrt den besagten Wiki Eintrag dahingehend abzuändern, könnte sonst irreführen sein.
Ich wollt das nur mal testen da ich bei cronjobs noch nie mit diesen "special time specifications" zu tun hatte. Bei meinem Debian funktioniert das problemlos wie ich nun festgestellt habe. Was die Startskripts angeht das mache ich über das "opt/etc/init.d" Verzeichnis, klappt prima.
MfG pulsar
Ich wollt das nur mal testen da ich bei cronjobs noch nie mit diesen "special time specifications" zu tun hatte. Bei meinem Debian funktioniert das problemlos wie ich nun festgestellt habe. Was die Startskripts angeht das mache ich über das "opt/etc/init.d" Verzeichnis, klappt prima.
MfG pulsar
- Status
Kaffeautomat
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.
