PHP-Konfiguration

Nicht immer entsprechen die standardmäßig vorgegebenen PHP-Parameter den von Contao empfohlenen Werten.  Bei meinem augenblicklichen Hauptprovider (Hosteurope) sieht die Sache schon recht gut aus.

Die PHP-Grundeinstellung lautet auf safe_mode = off und register_globals = off , so dass hier schon einmal gewisse Sicherheitslöcher gestopft sind.

Gegebenenfalls wünschenswert und erwägenswert wäre (laut Screenshot unten) eine Vergrößerung der Dateigröße für hochzuladende Dateien.

Wenn auf dem Server das Administrationsprogramm Plesk installiert ist wie auf den meisten von Hostern angebotenen Servern, dann kann man pro Domain individuelle PHP.ini Einstellungen hinterlegen.

Dazu muss man

1. unter Plesk FAST_CGI aktivieren
2. und einen Eintrag für den Parameter upload_max_filesize in der Datei php.ini im Verzeichnis /var/www/vhosts/domainname.de/etc/

vornehmen.

Beispiel
Syntax der erforderlichen Eintragszeile in php.ini:

[PHP]
open_basedir = /var/www/vhosts/IhreDomain.de/httpdocs:/tmp
safe_mode = Off
upload_max_filesize = 8M

Weitere Blogbeiträge zu dieser Thematik

Perfect-Knowhow: File permission (Aktivierung von FAST_CGI unter Plesk)

Anzeige

   Die Version 2.0 von Moodle benötigt hierbei als Systemvoraussetzung eine PHP-Version größer als 5.2.8, welche nicht so leicht zu finden ist, aber bei der Server-Administrationssoftware Plesk in der Version 9.5.4 dabei wäre.

Lösung:
Host-Europe hat zur Zeit (bis 6. Februar 2011) den Preis für seine Windows-Server gesenkt, mit dem sehr interessanten Zusatz, dass der erniedrigte Preis nicht nur für eine beschränkte Einführungszeit, wie bei anderen Anbietern gang und gebe, sondern für die gesamte Laufzeit des Vertrags gilt.

Eigentlich setze ich Server auf Basis von Linux auf, aber da der Windows Server genauso wie bei Linux mit Plesk als leicht zu bedienendes Server Administrationsprogramm arbeitet, sah ich darin kein Problem. Was dann auch so war.

Schnelle Einrichtung des Servers

Fünf Stunden nach der Bestellung des Windows Servers XL 4.0 war dieser schon eingerichtet und ich hatte alle Zugangsdaten per E-Mail erhalten. 

Welche PHP Version steht zur Verfügung?

Ich hatte mich schon zuvor über die Host-Europe FAQ Seite darüber informiert, welche Plesk Version für Windows Server 2003 bei zur Verfügung stehen und hatte gehofft, dass die Grundinstallation gleich mit der stabilen Plesk 9.5.4 Version erfolgt, die PHP 5.2.13 mit sich bringt.
   Dem war aber leider nicht so. Die Grundinstallation erfolgte mit Plesk 9.2.1, was doch zunächst etwas enttäuschend war.

Plesk 9.5.4 Update ist problemlos und total einfach

 Was mich dann allerdings sofort wieder versöhnte, war die absolut leichte Anleitung, die Host-Europe zur Verfügung stellt, um auf die neueste Version 9.5.2 zu updaten. Von Version 9.2 auf 9.5 ist es ja wirklich ein Sprung, aber die Anleitung mit Bildern ist so easy vorzunehmen, dass absolut jeder Laie das Pleskupdate ohne Probleme selbst durchführen kann.

   Werbung        

Siehe auch:

Host-Europe: Plesk Updates unter Windows

Außerdem existiert noch eine viel größere Hürde. Ich habe bis jetzt (27.12.2010) noch keinen Provider gefunden, bei dem die neue Version installiert werden kann.

Als Systemvoraussetzung ist bei Moodle 2.0.1 die PHP-Version 5.2.8 zu lesen. 

Die aktuell von den Providern angebotenen Distributionen beinhalten jedoch PHP-Versionsstände, die allesamt dieses Systemanforderungskriterium (PHP 5.2.8) nicht erfüllen.

Siehe auch:

DistroWatch: Softwareversionen bei openSuse Distributionen
Host Europe: Software-Versionsstände bei Betriebssystemen

Warning: mkdir() [function.mkdir]: SAFE MODE Restriction in effect. The script whose uid is 10001 is not allowed to access /var/www/vhosts/domain.de/httpdocs/…/tmp owned by uid 0 in /root/domain.de/httpdocs/verzeichnis/…/Cache.php on line 271

Ein phpinfo() zeigt
safe_mode=On

Hintergrund
Gerade bei virtuellen Hostern wird der PHP-Parameter SAFE_MODE gerne auf ON gesetzt.  Das mag zwar zunächst einmal richtig sein, da man damit den bösen Buben das Leben erschwert, aber im Grunde genommen ist diese Sicherheitseinstellung mehr hinderlich als nützlich.

1. Die Sicherheitseinstellung bringt nur etwas, wenn der Angreifer PHP verwendet. Weicht er aber dann auf z.B. Perl als Skriptsprache aus, dann bringt diese restriktive Einstellung gar nichts.
2. Ab PHP-Version 5.3.0 ist die PHP-Einstellung SAFE_MODE als DEPRICATED gekennzeichnet, sollte also nicht mehr verwendet werden.
3. Die SAFE_MODE=ON Einstellung behindert die PHP-Skripte Verzeichnisse zu erstellen und zu benutzen (die angelegten Verzeichnisse werden dem WWW-Server Benutzer zugeordnet und nicht dem Besitzer der PHP-Skripte)

Lösung

PHP-SAFE_MODE als Domainowner deaktivieren.

Anmerkung: Der Admin eines virtuellen Servers hat die Möglichkeit seinen Kunden das Recht zum PHP SAFE_MODE Management einzuräumen oder auch nicht.

Der Domain-Administrator kann unter dem Menüpunkt WEB HOSTING SETUP den PHP-Parameter ‘save_mode’ für seine Domain verändern (siehe Anmerkung zum virtuellen Server Admin). 

Siehe auch:
Vollständige TOP-20 Liste von Tiobe

Es empfiehlt sich hierbei eine Version 2.x des Debuggers XDebug zu verwenden, da diese Version mit PHP5 kompatibel ist.

Installation des Debuggers XDebug
Die Installation des Debuggers kann in wenigen Schritten durchgeführt werden. Exemplarisch soll hier die Aktivierung unter einer vorhandenen WAMP (Windows/Apache/MySQL/PHP) Laufzeitumgebung gezeigt werden.

1. XDebug  Library herunterladen
   Von der XDebug Downloadseite ist eine geeignete Version der Datei php_xdebug.dll herunterzuladen.
2. PHP Konfigurationsdatei anpassenZend Debugger
   In der PHP-Konfigurationsdatei php.ini, ist (falls vorhanden) der Abschnitt der Zend Studio Debugger Erweiterung zu deaktivieren, da beide Debugger nicht gleichzeitig aktiviert sein dürfen.

   [Zend]
   ;zend_extension_ts = “C:\xampp\….dll”
   ;zend_extension_manager.optimizer_ts = …Optimizer”
   ;zend_optimizer.enable_loader = 0
   ;zend_optimizer.optimization_level=15
   ;zend_optimizer.license_path =
   ; Local Variables:
   ; tab-width: 4
   ; Local Variables:
   ; tab-width: 4
   ; End:

   XDebug
   Statt dessen sind die folgenden Zeilen einzufügen, wobei man die Pfadangabe zur DLL-Datei anpassen muss.

   zend_extension_ts=”C:/wamp/ext/php_xdebug.dll”
   xdebug.remote_enable=on
   xdebug.remote_handler=dbgp
   xdebug.remote_host=localhost
   xdebug.remote_port=9000

   Zu Beachten: Ab PHP 5.3 wird man das Schlüsselwort zend_extension und nicht mehr zend_extension_ts verwenden müssen! (s.a. How to configure XDebug)

3. Prüfung der Installation
   Nach einem Neustart von Apache/PHP sollte ein phpinfo() einen xdebug-Abschnitt aufweisen.

   

Siehe auch
XDebug Homepage: XDebug Extension for PHP
Netbeans Docs & Support: PHP Learning Trail
Netbeans Docs & Support: How to configure XDebug

Um es vorwegzunehmen, ich halte Webservices für etwas ganz Tolles. Kapselung des Codes, definierte Aufrufschnittstelle, Verknüpfung von heterogenen Systemen/Programmiersprachen das sind alles Pluspunkte für mich, aber nach dem Lesen des Buches erschließt sich für mich nicht, warum ich Webservices nach REST Style programmieren sollte, was mir dieser Ansatz für einen Zusatznutzen bringt.

Warum habe ich als Java Programmierer überhaupt ein PHP-Buch gelesen. Zum einen kann man nicht leugnen, dass PHP insbesondere im Bereich der Frontendprogrammierung marktrelevant ist und seit der Version PHP 5 ist die Skriptsprache stark objektorientiert.  Das Buch “RESTful Java Webservices” soll erst gegen Ende des Jahres herauskommen. Kernpunkt meines Interesses war die Idee der Restprogrammierung kennenzulernen. Die Codebespiele sind in diesem Buch natürlich allesamt in PHP geschrieben, aber in welcher Programmiersprache man die  grundsätzliche Idee des REST Ansatzes umsetzt (PHP oder Java) ist von zweitrangiger Bedeutung.  Es ist für einen Programmierer absolut leicht den PHP-Code des Buchs zu verstehen und sich das Java Gegenstück dazu gedanklich vorzustellen.

Es wird immer wieder betont, dass REST (Representational State Transfer) keine neue Programmiersprache ist und auch kein neues Programmierframework, sondern ein Softwarearchitekturstil.  Und ich glaube, dass diese Kernaussage auch den Nutzen und die Limitierung von REST beschreibt. REST wird sich nicht weiterentwicklen, weil es keine Möglichkeit zur Weiterentwicklung gibt. Stillstand ist aber in der Softwareentwicklung für jede gute Idee fatal.

In der REST Programmierung wird alles als Ressource mit eigener URI deklariert und es ist verpönt, Parameter zu übergeben.

Wenn beispielsweise der Bibliotheksbenutzer (ID=4) das Buch mit der ID= 6 ausleiht, so würde man vielleicht normalerweise
pfad/kunde.php?client=4&book=6
schreiben.

Im REST Stil mit der verpönten Parameterübergabe schreibt man dann
pfad/kunde/4/book/6

Es tut mir leid, aber ich kann dabei keinen großen Unterschied sehen. Auch wenn dies nun als Ressource (URI) geschrieben wurde, bleibt es für mich doch grundsätzlich eine Parameterübergabe.

Auch bei der REST-Schreibweise existiert physikalisch keine Datei in dem angegebenen Pfad und wir kommen zu meinem ersten Kritikpunkt an REST. Für jeden Ressourceaufruf wie pfad/kunde/4/book/6 ist ein Controller zu programmieren, der den Ressourceaufruf erst einmal wieder auseinanderbaut, um dann letztendlich die erforderlichen Verarbeitungs- bzw. Datenaufbereitungsschritte durchzuführen.

Während man bei HTTP-Aufrufen sonst nur mit GET und POST agiert, so wird von REST fast das volle Repertoire (GET, POST, PUT, DELETE) eingesetzt.  Dies wird einem als großer Vorteil gegenüber einem normalen Webservice Aufruf verkauft, bei dem man den Modus explizit mitgibt. Aber ob ich nun den Modus des Webservices als Parameter übergeben bekomme oder ihn mir erst durch Betrachtung des HTTP-Befehls (GET, PUT, …) erschließen muss, bleibt sich für mich doch gleich.  Der Modus muss und wird auf jeden Fall übergeben, ob auf die eine oder andere Art.  Theoretisch gesehen, mag die REST Methode die sauberere Art der Modussteuerung sein, praxisbezogen würde ich sie allerdings als die schlechtere Verfahrensweise bezeichnen. Aus Sicherheitsgründen wird oft der PUT-Befehl auf Servern deaktiviert (insbesondere bei externen Serverbetreibern), so dass man mit einem Programm, welches auf der REST-Architektur basiert, ein richtiges Problem beim Deployment bekommt.  Was nützt einem das beste theoretische Konzept, wenn es auf dem Produktionsserver nicht läuft!

Um die URIs aufzulösen, braucht es einen Controller, der den HTTP-Befehl auflöst, dann die Parameter (die ja keine Parameter sind) interpretiert um dann in einer Art Kaskadierung mit vielen “wenn dann” Fallbetrachtungen irgendwann einmal das zuständige Aufbereitungsprogramm/die zuständigen Aufbereitungsprogramme bestimmt zu haben.
Bei einfachen Webservices mag das ja noch angehen, wenn mit steigender Komplexität sehe ich auch eine steigende Fehlerträchtigkeit mit dieser Architektur und damit einhergehend eine Verschlechterung der Wartbarkeit der Software.

Das Thema REST wird bald von einem anderen Strohfeuer abgelöst werden. Die durchaus vorhandenen, positiven Gedankenanstöße von REST (zustandslose Webservices, keine Notwendigkeit von Cookies) werden hoffentlich von anderen, noch kommenden Techniken aufgegriffen und weitergeführt.

REST ist und bleibt das Kapitel 5 der Dissertation von Roy Thomas Fielding aus dem Jahr 2000.