Entferntes Skript via wget und Cron aufrufen

[Steini]

Ich schon wieder...

Möchte ein PHP-Skript auf einem entfernten Webspace via Cronjob aufrufen. Meinen schmalen rudimentären Kommandozeilenkenntnissen zufolge müsste das über den folgenden Aufruf zu realisieren sein:
/usr/syno/bin/wget --spider http://mydomain.com/irgendeinverzeichnis/irgendeinedatei.php > /dev/null

Korrigiert mich, falls ich falsch liege, aber --spider prüft doch einfach nur, ob die Seite verfügbar ist und das müsste doch eigentlich schon genügen, um ein dort befindliches Skript abzuarbeiten, oder?

Und > /dev/null habe ich angefügt, damit die eingelesene URL samt Inhalt gleich wieder verworfen wird.

Ach ja, die Crontab habe ich natürlich nach dem Eintragen neu geladen.

Wo ist der Fehler?

 

[itari]

Läuft es denn ohne cron??

Itari

 

[Steini]

Du meinst, wenn ich die URL direkt aufrufe? - Ja.

Du meinst, wenn ich die Zeile in der Shell aufrufe? - Nein.

 

[itari]

Du meinst, wenn ich die URL direkt aufrufe? - Ja.

Du meinst, wenn ich die Zeile in der Shell aufrufe? - Nein.

Ich meine schon den ganzen wget-Aufruf in der Shell. Das musste erstmal hinbekommen bevor du es in die crontab stellst.

Was kommen denn für Meldungen ohne die >/dev/null-Redirektion? Post mal.

Itari

 

[Trolli]

Kann gut sein, dass der Synology wget die Option --spider nicht kennt und deshalb versagt. Versuch es doch mal ohne diese Option.

 

[Steini]

Da ich an der Arbeit bin, kann ich das leider nur via AdminTool > Tools > Shell machen und da bekomme ich keinerlei Feedback beim Absetzen der Zeile.

 

[itari]

Gib mal am Ende der Zeile 2>&1 an, das sollte die Standard-Error-Ausgabe auf die Standard-Ausgabe umlenken, so dass du sehen kannst, ob Fehlermeldungen ausgegeben werden.

Itari

 

[itari]

Vielleicht musste cookies enablend haben oder so etwas ... das geht schon alles mit dem wget.

Itari

 

[Steini]

Gib mal am Ende der Zeile 2>&1 an [...]

Hammer! Woher weißt du das nur alles? Kann ich dieses 2>&1 standardmäßig im AdminTool aktivieren?

Eigene Doofheit. Habe in meinem Root-Verzeichnis eine .htaccess liegen, in der ich etliche Spider und Crawler geblockt habe - u. a. auch wget-Anfragen. Mann oh Mann, daran habe ich gar nicht mehr gedacht. Danke für euren Support und sorry!

 

[itari]

Habe in meinem Root-Verzeichnis eine .htaccess liegen, in der ich etliche Spider und Crawler geblockt habe - u. a. auch wget-Anfragen.

Wie machste das Blockieren von wget-Anfragen?

Itari

 

[Steini]

Du bist mir noch eine Antwort schuldig ("Kann ich dieses 2>&1 standardmäßig im AdminTool aktivieren?"), aber ich will mal nicht so sein. So mache ich das...

SetEnvIfNoCase User-Agent "Wget" bad_bot

<Limit GET POST>
order allow,deny
allow from all
deny from env=bad_bot
</Limit>

Die erste Zeile lässt sich dabei beliebig erweitern... Habe mittlerweile über 170 Spider und Crawler geblockt. Wenn's dich/euch interessiert, kann ich die momentane Liste mal hier posten...

 

[itari]

Auf die Frage: "Kann ich dieses 2>&1 standardmäßig im AdminTool aktivieren?" antworte ich mal so: Ja man könnte das einbauen. Ich hab darüber nachgedacht und bin zu dem Ergebnis gekommen, dass man es nicht einbauen sollte, sondern statt dessen '2>&1' verwenden sollte. Warum? Weil manchmal Standard-Ausgabe gemischt mit Standard-Error verwirren und man dann sofort danach fragt 'kann man das auch wieder abschalten?' Und da (fast) jeder, der mit einer Shell arbeitet, auch die Redirektionen kennt, ist es also kein wirkliches Problem.

Noch eines an dieser Stelle: Im AdminTool ist die (Web-)Shell ein 'Fake'. Die Eingabe wird nur an einen exec() weitergereicht; dieser spawnt eine non-interactive-shell. Trotzdem sieht die (Web-)Shell recht nett aus. Aber viele Shell-Spezialitäten (alias, export usw) sind natürlich nicht Session-stabil. Auch der Shell-Prompt ist ein PHP-Fake. Aber mal für Zwischendurch und für 95% aller Verwendungen ist das eh egal.

Zu der Liste: immer her damit (Dateianhang). Das mag für dein einen oder anderen sehr interessant sein.

Itari

 

[Steini]

[...] Warum? Weil manchmal Standard-Ausgabe gemischt mit Standard-Error verwirren [...]

Touché, sehe ich ein.

[...] Und da (fast) jeder, der mit einer Shell arbeitet, auch die Redirektionen kennt [...]

Eben. Fast jede(r), aber ich werde mir Mühe geben, dass ich mir diese ganzen Terminal-Geschichten merken kann. Momentan schreibe ich mir jeden Fitzel auf, damit ich ja nix falsch am Prompt eingebe.

[...] Zu der Liste: immer her damit (Dateianhang). Das mag für dein einen oder anderen sehr interessant sein. [...]

Erledigt. Kurz dazu: Wenn jemand explizit einen Spider zulassen möchte, einfach die jeweilige Zeile auskommentieren oder löschen. Die Datei als .htaccess im jeweiligen Verzeichnis speichern, welches geschützt werden soll. Achtung: Sofern in Unterverzeichnissen keine anderen Direktiven in .htaccess-Dateien rumlungern, gelten diese Anweisungen für alle Unterverzeichnisse nebst beinhalteten Dateien!