CronJobs - die Alternative

[Trolli]

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?

 

[Matthieu]

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?

Frag mal itari, ich glaub das AdminTool arbeitet auch so.

MfG Matthieu

 

[itari]

Frag mal itari, ich glaub das AdminTool arbeitet auch so.

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

 

[2cool4u]

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?

 

[jahlives]

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

which php

herausbekommen. Wobei du php natürlich durch den Befehl ersetzen musst den du suchst.

 

[2cool4u]

Danke 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

 

[zentis666]

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

 

[zentis666]

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...

 

[Mexx]

*meld

auch ich würde gerne dieses script zum laufen bringen, finde aber auch den pfad

(1) Anlegen eines PHP-Skriptes im Verzeichnis /usr/syno/synoman/phpsrc/cronjobs/cronjobs.php mit folgendem Inhalt:

nicht

gibt es da eine lösung ?? thx

 

[Mexx]

gibt es hier noch ne Antwort ? pls, thx

 

[itari]

Warum nimmst nicht mein AdminTool? So ziemlich alle meine Skripte sind jetzt da drinnen und ich pflege deswegen die anderen Geschichten nicht mehr.

Itari

 

[Mexx]

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

 

[itari]

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 ?

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

 

[Mexx]

das heißt für mein jungfräuliches DSM3.0 brauch ich nur die zwei files ?

Dateityp: spk Init_3rdparty_1.5.spk (10,5 KB)
Dateityp: spk adm_0_99c.spk (1,04 MB)

thx

 

[itari]

und eine saubere IPKG-Installation, denn viele Funktionen werden erst dadurch zum Leben erweckt. Aber das kannst auch später machen.

Itari

 

[Daniel775]

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

failed user root parsing 1-4,7 root /opt/bin/bash /opt/var/etc/shutdown.sh #test

 

[crossi86]

@ 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ß

 

[pulsar]

@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:

1. special time specifications: die ersten fünf Spalten können auch durch bestimmte Schlüsselwörter ersetzt werden:
   1. '@reboot', startet einmal nach dem startup
   2. '@yearly', startet einmal im Jahr, das entspricht '0 0 1 1 *'
   3. '@annually', startet einmal im Jahr, das entspricht '0 0 1 1 *'
   4. '@monthly', startet einmal im Monat, das entspricht '0 0 1 * *'
   5. '@weekly', startet einmal in der Woche, das entspricht '0 0 * * 0'
   6. '@daily', startet einmal am Tag, das entspricht '0 0 * * *'
   7. '@hourly, startet stündlich, das entspricht '0 * * * *'

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:

@reboot root sh /temp/test.sh

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

 

[goetz]

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

 

[pulsar]

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