Das Plesk-Panel ist eine beliebte Oberfläche für Serverbetreiber. Plesk ermöglicht es mit wenigen Klicks Webpakete für Kunden zu erstellen oder Datenbanken, E-Mailkonten und vieles mehr einzurichten. Unter unserer Kunden gibt es viele Webdesign Agenturen, die Ihren Kunden auf unser Flexservern mit vorinstallierten Plesk  das Hosting ihrer Webseiten anbieten. Neben den oben genannten Funktionen bietet das Plesk Panel die Möglichkeit, Cronjobs anzulegen.

Cronjobs unter Plesk anlegen

Mit Cronjobs kannst Du definierte Befehle regelmäßig ausführen lassen. Allerdings funktioniert der Aufruf eines Scripts seit der Version 10.1 etwas anderes. Soll der Cron-Job zum Beispiel ein PHP-Script ausführen, kommt es wahrscheinlich zu folgendem Fehler:
Befehl:

/usr/bin/php5 /var/www/vhosts/deine-domain.de/httpdocs/cdu/dein-script.php

Fehlermeldung:

php: command not found
bzw.
No such file or directory

Das passiert, weil für den User entweder keine Shell oder eine Chroot-Shell konfiguriert wurde. Mit der Chroot-Shell hat der User Zugriff auf alle Dateien unterhalb seines Heimatverzeichnisses. Das liegt in

/var/www/vhosts/deine-domain/

Da in der dortigen Umgebung in /var/www/vhosts/deine-domain/bin kein PHP-Interpreter liegt, kommt es zu dem Fehler.

Wieso macht Plesk das?

Früher ging das doch, wieso hat Parallels das geändert? Bis zur Plesk Version 10.1 funktionierte das Erstellen von Cronjobs, die PHP oder Perl einbinden, problemlos. Diese Cronjobs wurden nämlich nicht in einem Chroot ausgeführt, sondern in der normalen Umgebung des Servers. Parallels dürfte dieses Verhalten aus Sicherheitsgründen geändert haben. Leider ist es trauriger Hosteralltag, dass auf den Webpräsenzen von Kunden nicht aktualisierte und damit unsichere Software installiert bleibt. So passiert es alle Nase lang, dass irgendein vergessenes PHPMadmin, ein ungepflegtes CMS wie Joomla oder Typo3 oder irgend eine andere Software den freundlichen Cyberkriminellen von nebenan geradezu einladen, auf dem Server den Trojaner der Woche zu installieren. Damit beteiligt sich der Server dann am Geschäftsbetrieb der Cyberkriminellen. Er

• hostet vielleicht gefälschte Webseiten von Paypal, Banken, Ebay usw. Dort werden PINs, Tans und andere Zugangsdaten ahnungslosen Usern, die per Spam auf diese Seiten gelenkt werden, abgegriffen.
• fügt Schadcodes in bestehende Webseiten ein, um ahnungslose Internetnutzer, die eine auf dem Server gehostete Website besuchen, mit Schadsoftware zu infizieren.
• betreibt Bots, die selbst nach verwundbaren Servern suchen, die Scripte und Spam versenden.
• verschickt Spam an tausende von Internetusern.
• beteiligt sich an DoS-Angriffen auf andere Server.

Jeder Bot will leben, da unterscheidet sich so ein Trojaner erst mal nicht groß von anderen Lebewesen. Also will sich eine solche Schadsoftware möglichst tief im System verankern um Neustarts des Servers und nach Möglichkeit auch unzureichende Entfernungsversuche ‚zu überleben‘. Dies geschieht hauptsächlich durch die Nutzung eines Cronjobs der die dann nötigen Programme startet. Da solche Trojaner oft zumindest teilweise in PHP oder Perl geschrieben sind, erleichtert das Vorhandensein dieser Interpreter dem Trojaner ganz kräftig seine Arbeit.
Somit hat Parallels dem Internet einen Gefallen getan, als sie in der Version 10.1 des Plesk Panels eine Funktion implementiert haben, die verhindert dass Cronjobs ohne weiteres auf den PHP-Interpreter zugreifen können.

Lösungen

Nun zu möglichen Lösungen, wie Du Dein PHP-Script über einen Cronjob ans Laufen bekommst:

Ein User auf dem Server, der Cronjobs starten kann und eine komplette Umgebung hat: Erzeugen Sie sich einen User, der /bin/bash als Shell hat und lassen Sie die Cronjobs unter diesem User laufen. Hier muss darauf geachtet werden, dass Probleme mit Dateizugriffsrechten auftreten können, die entsprechend abgefangen werden müssen.
Die Chroot-Umgebung aktualisieren: Plesk bietet die Möglichkeit die gewünschte Software auch in der Chroot-Umgebung verfügbar zu machen. Das gilt für das ‚default-chroot‘ das für neue Webs eingerichtet wird, aber auch für einzelne Domains. Paralles hat hierzu unter http://kb.parallels.com/818 einen Knowledgebase Arktikel bereitgestellt, der das Vorgehen erklärt. Kompliziert wird das ganze aber dadurch, dass nicht nur die eigentliche Programmdatei wie z.B. /usr/bin/php in das Chroot kopiert werden muss, sondern auch noch die dazugehörigen Programmbibliotheken. Im Fall von PHP könnte ein Ausweg darin bestehen, den Cronjob über eine Website zur Ausführung zu bringen. Mit dem Programm wget existiert ein kleiner Kommdazeilenwebbrowser, der dann das gewünschte PHP-Script aufruft. Hier müssen Sie einmal das wget-Binary (Programmdatei) in den Order /bin des Users legen. Dann braucht es noch drei Bibliotheken, damit wget funktioniert:

1. libz.so.1.2.3.3 gelinkt auf libz.so.
2. libssl.so.0.9.8
3. libcrypto.so.0.9.8

Das wget-Binary muss auf ausführbar (+x) gesetzt sein.

Fazit

It’s not a Bug it’s a Feature! Manchmal steckt hinter einem Fehler ein positiver Mechanismus. So auch in diesem Fall. Außerdem zeigt es, dass es durchaus sinnvoll ist, seinen Server und die installierte Software regelmäßig zu patchen wenn man von solchen Sicherheitsfeatures profitieren möchte. Ich hoffe das Dir dieser Artikel geholfen hat. Wenn dem so ist oder wenn Du noch Fragen hast, hinterlasse gerne einen Kommentar.