Lokaler Apache/PHP-Testserver

25.7.2010 von rmo.

Ich entwickle oft “PHP 5″-Programme - auch unterwegs. Auf einem Laptop musste ich vor kurzem einen lokalen Apache-Server einrichten, um auch ohne Netzwerkanbindung Programme testen zu können. Der Server sollte natürlich PHP5 unterstützen und für eine bestimmte Testdomaine - “devdomain” - SSL-fähig sein. Hierzu muss man auf die Schnelle virtuelle Domainen einrichten. Das Ganze unter Opensuse 11.3.

Vielleicht ist die nachfolgende Vorgehensweise zur Lösung dieser Aufgabenstellung auch für andere interessant.

/etc/host-Einträge

Der Rechner soll später autonom - d.h. ohne Netzverbindung funktionieren. Ein DNS-Dienst ist für ein rein lokales System überflüssig. Für einen lokalen, autonomen Testserver kann für die notwendigen Einträge in der Datei “/etc/hosts” das Loopback-Interface verwenden. Die Einträge können dann etwa so aussehen:

127.0.0.1         localhost.localdomain         localhost

127.0.0.2         mylap.myprivatedomain.de         mylap

127.0.0.2         devdomain

Der erste Eintrag ist ein Standard Opensuse-Entrag, wie er bei einer automatischen Installation erzeugt wird. Den zweiten benötige ich für andere Programme. Interessant für unsere Problemstellung ist die dritte Zeile. Die dortige IP-Adresse ist u.a. wichtig für das spätere Aufsetzen der IP-basierten virtuellen Domaine “devdomain”.

Es gibt im Internet immer wieder Diskussionen um die Verwendung der Loopback-Adresse - ich denke, die oft angeführten Gegen-Argumente kann man im Zusammenhang mit dem beschriebenen Szenario getrost ignorieren. Ein System mit aktiven Netzwerkschnittstellen benötigt natürlich noch mehr Einträge an passender Stelle in der “/etc/hosts” und ggf. eine Adress-Systematisierung über einen DNS-Server. Aber die Funktionalität eines autonomen Entwicklungs- und Test-Systems ist mit den Loopback-Adressen wirklich in hinreichender Weise gegeben.

Für die korrekte lokale Namensauflösung sollte “files” die Reihenfolge der Ressourcen im “hosts”-Eintrag der Datei “/etc/nsswitch.conf” anführen:

hosts:       files mdns4_minimal [NOTFOUND=return] dns

Grundinstallation Apache

Apache2 kann man unter Opensuse einfach über die Yast und die dortige Paketverwaltung installieren. Folgende Pakete aus dem Opensuse 11.3 Standard-Repository habe ich installiert:

• apache2 (!)
• apache2-devel (!)
• apache2-doc
• apache2-example-pages (!)
• apache2-mod_dnssd
• apache2-mod_perl
• apache2-mod_php5 (!)
• apache2-mod_python
• apache2-prefork (!)
• apache2-utils (!)
• libapr-util1 (!)
• libapr-util1-devel (!)
• libapr1 (!)
• libapr1-devel (!)

Nach der Installation und einem “rcapache2 start” sollte ein

http://localhost

im Browser bereits eine Seite mit dem schönen Text “It works!” anzeigen. Danach trägt man mit Yast den Apache2-Server in die Run-Level-Konfiguration ein, damit er automatisch z.B. in den Levels 3 und 5 gestartet wird.

Grundinstallation PHP5

Für eine relativ umfassende PHP5-Unterstützung sind für mich in der Regel folgende Pakete/Module von Bedeutung:

apache2-mod_php5, php-doc, php5, php5-bcmath, php5-bz2, php5-ctype, php5-devel, php5-dom, php5-gd, php5-hash, php5-iconv, php5-imagick, php5-json, php5-mbstring, php5-mcrypt, php5-mysql, php5-pdo, php5-pear, php5-phar, php5-sqlite, php5-tidy, php5-tokenizer, php5-xdebug, php5-xmlreader, php5-xmlwriter, php5-zip, php5-zlib

Die Zusammenstellung kann für umfangreiche Entwicklungsszenarien natürlich komplexer aussehen.

Hinweis zur Aktualisierung der PHP-Installation:
Um eine aktuelle PHP5-Installation unter Opensuse 11.2 zu erhalten (PHP 5.3.3) muss man ggf. die passenden Repositories unter

http://download.opensuse.org/repositories/server:/php/
http://download.opensuse.org/repositories/server:/php:/extensions/

in die Paketverwaltung einbinden. Über das zweite der genannten Repositories erhält man z.B. das Xdebug-RPM.

Modifikation an der php.ini

Auf einem Entwicklungssystem will man man Fehlermeldunge zu PHP5-Programmen sehen. Evtl. hat man auch Programme, die mit der Kurzform der Script-Tags “” statt lauffähig sein sollen. Um beim Einsatz der Funktion “date()” Warnungen zu vermeiden, stellt man auch die Standardzeitzone für das PHP-Modul ein. Für all das muss man entsprechende Modifikationen an der Datei

“/etc/php5/apache2/php.ini”

vornehmen. Entsprechende Einträge (plus ein paar mehr) :

• short_open_tag = On
• error_reporting = E_ALL & ~E_DEPRECATED
• display_errors = On
• log_errors = On
• ignore_repeated_errors = Off
• ignore_repeated_source = Off
• register_globals = Off (immer gut)
• include_path = “.:/usr/share/php5:/usr/share/php5/PEAR” (PEAR soll funktionieren)
• date.timezone = Europe/Berlin

“Spiel-Zertifikat und SSL-Aktivierung unter Opensuse 11.3

Viele meiner PHP-Frameworks für Kunden erzwingen in der Regel einen HTTPS-Verbindung. Wenn ich das lokal testen will, komme ich um SSL also nicht herum. SSL geht nur über IP-basierte virtuelle Domainen. Für den Standardhost “localhost” ist dann zudem eine zweite separate virtuelle Domaine einzurichten.

SSL geht nicht ohne ein Minimal-Zertifikat. Für lokale Testzwecke reicht ein “Spiel-Zertifikat”. (Im Browser fügt man dann bei Warnungen eine Ausnahmeregel für das Zertifikat ein.)

Unter Opensuse 11.3 erreicht man die notwendige Grundausstattung des Apache-Servers unter Benutzung von Apache-Tools durch folgende Kommandos:

• a2enmod ssl
• a2enflag SSL
• /usr/bin/gensslcert (als root absetzen)
• cp /etc/apache2/vhosts.d/vhost-ssl.template /etc/apache2/vhosts.d/vhost-ssl.conf
• Anpassung der vhost-Dateien (s.u.)

Ein paralleler Blick in die “sysconfig”-Dateien des SUSE-Systems ist hier nicht verkehrt. Dafür kann man z.B. den sysconfig-Editor von Yast heranziehen. Im dortigen kategoriebaum bewegt man sich in den Zweig

“Netzwerke   >>>   WWW   >>>   Apache2″.

Unter dem Eintrag “APACHE_MODULES” sollte man folgendes finden:

authz_host actions alias auth_basic authz_groupfile authn_file authz_user autoindex cgi dir include log_config mime negotiation setenvif status userdir asis imagemap ssl php5 authz_default

Unter dem Eintrag APACHE_SERVER_FLAGS sollte SSL auftauchen:

SSL

Hinweise:

• Ein Extra-RPM für das SSL-Modul muss unter Opensuse 11.3 nicht installiert werden.
• gensslcert erzeugt nur eine Spiel-Cert. Dabei werden folgende Dateien überschrieben:

• /etc/apache2/ssl.crt/ca.crt
• /etc/apache2/ssl.key/server.key
• /etc/apache2/ssl.crt/server.crt
• /etc/apache2/ssl.csr/server.csr

• Der Virtual-Host für die SSL-Domaine muss IP-basiert (!) angelegt werden - also nicht namensbasiert. “*”-Angaben für die IP-Adressen werden mit Fehlermeldungen quittiert. In unserem Beispiel werden für das autonome Testsystem die Loopback-Adressen herangezogen.
• Man darf nicht vergessen, dass man für einen Standardzugang “http://localhost” eine eigene virtuelle Domaine einrichten muss, da es bei virtuellen Domainen ohne Vorkehrungen keinen Standard-Host (Default-Web-Server) mehr gibt.

Konfigurationsdateien

Nachfolgend gebe ich (etwas verkürzt) an, welche Grundeinträge in zwei Konfigurationsdateien unter dem Verzeichnis

/etc/apache2/vhosts.d

notwendig sind, um das Ziel zu erreichen,

• einen Standardhost ohne SSL-Verschlüsselung unter “http://localhost”
• eine Testdomaine “devdomain” für Entwicklungszwecke über “https://devdomain”

ansprechen zu können:

Inhalt der Datei “ip-based_vhosts.conf” für den Standardserver

<VirtualHost *>

DocumentRoot /srv/www/htdocs

DirectoryIndex index.html index.html.var index.htm index.php index.php5

<Directory “/srv/www/htdocs”>

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

Hinweise:

• Der Name der Datei kann beliebig gewählt werden !
• Es wird hier kein “server-name angegeben” !!!! - Default-Server
• Das Root-Verzeichnis für den Standardhost ist hier “/srv/www/htdocs”. Dort sind die Web-Dateien und PHP-Programme anzulegen.

Inhalt der Datei “vhost-ssl.conf” für den IP-basierten, SSL-Server für die Domaine “devdomain”

<IfDefine SSL>

<IfDefine !NOSSL>

<VirtualHost 127.0.0.2:443>

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/trunk/”

ServerName devdomain:443

ErrorLog /var/log/apache2/error_log

TransferLog /var/log/apache2/access_log

SSLEngine on

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile /etc/apache2/ssl.crt/server.crt

SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

<Files ~ “\.(cgi|shtml|phtml|php3?)$”>

SSLOptions +StdEnvVars

</Files>

<Directory “/srv/www/cgi-bin”>

SSLOptions +StdEnvVars

</Directory>

SetEnvIf User-Agent “.*MSIE.*” \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

CustomLog /var/log/apache2/ssl_request_log ssl_combined

</VirtualHost>

</IfDefine>

</IfDefine>

Hinweise:

• Der Host muss eine IP-Adresse erhalten - hier die lokale Loopback-Adresse.
• Der Servername (vergl. mit /etc/hosts) wird in einer speziellen, separaten Zeile eingetragen.
• Die IP-Adresse muss mit dem angegebenen Namen des Servers auch in der Datei “/etc/hosts” eigetragen sein !
• Das DocumentRoot-Verzeichnis habe ich deshalb mit dem “trunk”-Zweig ausgestattet, um die Verzeichnisstruktur eines an Eclipse angebundenes SVN-Repositories zu berücksichtigen. Das kann man natürlich auch anders machen.

Nach dem Anlegen der Dateien kann man nun die neue Konfiguration nach einem “rcapache2 restart” testen. Dazu legt man im Verzeichnis

/srv/www/htdocs/Entwicklung/devdomain/trunk/

eine kleine Testdatei an oder kopiert die “index.html” aus dem Pfad “/srv/www/htdocs” dorthin. Firefox sollte beim Aufruf der Adresse “https://devdomain” keine SSL-bezogene Fehlermeldung anzeigen, sondern nur wegen des nicht vertrauenswürdigen Zertifikats warnen. Der Warnung begegnet man mit einer dauerhaften Ausnahme-Regel. Danach sollte die Test-Datei angezeigt werden. Taucht wieder Erwarten eine Meldung “ssl_error_rx_record_too_long” auf, so ist etwas an der Apache-Konfiguration faul und man muss nacharbeiten.

Das ist natürlich nur eine Ruck-Zuck-Installation eines lokalen Testservers für den Hausgebrauch auf einem PC oder Laptop. (Ein ordentlich aufgesetzter Apache2 sieht anders aus). Aber mit der obigen Konfiguration lassen sich schon bestens PHP-Programme testen.

Viel Spaß also beim PHP-Entwickeln unterwegs - und natürlich unter Linux !

Links

http://de.opensuse.org/Apache/SSL-Anleitung
http://de.opensuse.org/Apache
http://www.schirmacher.de/display/INFO/Apache+SSL+Zertifikat+erstellen+und+installieren
http://wiki.ubuntuusers.de/Apache/SSL
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf12.htm
http://de.opensuse.org/Apache/Schnellstartanleitung

Geschrieben in Apache, LAMP / Webentwicklung | Keine Kommentare »

Apache 2, Zeichensätze und Direktiven

22.8.2009 von rmo.

Gestern hielt mich ein kleines Problemchen mit der Zeichensatzauswahl auf Apache Server unter SLES 9 auf.

Problembeschreibung

Mehrere von meiner Firma entwickelte Webseiten waren per Metatag-Ạnweisung vom ISO-8859-1 Zeichensatz

<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″>

auf UTF-8 umgestellt:

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″>

Bei den anschließenden Test mit einem Browser auf dem Server selbst sahen die Webseiten OK aus. Umlaute wurden korrekt dargestellt. Chaotisch wurde es jedoch, als wir die Seiten auf einem separaten Client-PC betrachten wollten. Alle Umlaute waren falsch. Zwar half eine explizite Umstellung des zu wählenden Zeichensatzes im Browser - aber eigentlich wünscht man sich hier eine automatische, richtige Wahl.

Ein Test derselben Web-Seiten auf einem anderen Apache-Server ergab dagegen gute Ergebnisse. Die Sache hatte also nichts mit Browser-Einstellungen oder anderen Client-Problemen zu tun.

Response Header

Weiter kommt man in einem solchen Fall zunächst dadurch, indem man sich ansieht, was der Server dem Browser nach der Seitenanfrage eigentlich so übermittelt. Den sog. “Response Header” kann man sich u.a. mit Funktionen des Firefox-Browsers ansehen. Die notwendige Angaben erhält man im aktuellen FF über den Menüpunkt:

“Extras” -> “Web Developer” -> “Information” -> “View Response Headers”.

Hier kam dann tatsächlich die Angabe, dass als Zeichensatz ISO-8859-1 gelten soll - und zwar über die Header-Zeile:

Content-Type: text/html; charset=iso-8859-1

Beim dem anderen getesteten Server, mit dem der Browser “richtig” zusammenarbeitete, war im Response Header dagegen gar keine Vorgabe zum Zeichensatz eingetragen. Der Befund, dass die Schwierigkeiten mit Servereinstellungen zu tun hatten, bestätigten sich also.

Leider sind die Einstellungen zu Zeichensätzen für den Apache2 in unterschiedlichen Linux-Distributionen auch in unterschiedlichen Dateien untergebracht. Ein wenig Suchen nach Begriffen wie “Charset” oder “ISO-8859″ in den Dateien der Apache2-Konfigurationsdateien ist im Einszelfall daher ggf. notwendig.

Zeichensatzvorgaben auf dem Apache unter SLES 9

Bei SLES9 wird man in der Datei

/etc/apache2/mod_mime-defaults.conf

fündig. Auf anderen Servern können die Einstellungen aber auch in einer Datei “/etc/apache2/conf.d/charset” vorgegeben sein!

Dort werden nach Language-Festlegungen Vorgaben für Zeichensätze in der Form

AddCharset ISO-8859-1 .iso8859-1 .latin1
AddCharset utf-8 .utf8

getroffen. Wegen der Zeile für utf-8 wundert man sich vielleicht, wieso dann im obigen Beispiel im Response Header die Vorgabe ISO-8859-1 auftaucht. Der Grund ist/war auf dem “problematischen” Server die zusätzliche Zeile

AddDefaultCharset ISO-8859-1.

Ein testweises Auskommentieren und Neustarten des Apache2-Servers zeigte dann tatsächlich, dass diese Zeile die Ursache für die “Probleme” auf dem Browser bzw. die ISO-8859-1 Zeile im Response Header darstellte.

An dieser Stelle ist nun aber ein wenig Kontemplation gefragt, denn ein generelles Auskommentieren kann ja ggf. auch ein Sicherheitsrisiko darstellen. Und was macht man, wenn man Einstellungen auf einem Server treffen muss, über dessen Apache-Konfigurationsdateien man keinen Einfluss hat? Dies ist ja die typische Situation bei Hostern. Zudem fragt man sich, wie man vorgehen muss, wenn man auf folgende Situationen trifft:

a) Man benötigt für die Dateien in ganz bestimmten definierten Verzeichnissen Charset-Vorgaben, die dem Default nicht entsprechen.

b) Man hat einen Mix aus Seiten mit unterschiedlichen Charset-Festlegungen im gleichen Verzeichnis.

Ich versuche weiter unten, nach einem Blick in die Apache-Konfiguration meinen “best guess” abzugeben.

Was sagt die Apache-Doku ?

In der Apache Dokumentation auf der Webseite “http://httpd.apache.org/docs/2.0/mod/core.html” finden sich u.a. folgende Hinweise (die Hervorhebungen habe ich vorgenommen)

Description: Default charset parameter to be added when a response content-type is text/plain or text/html
Syntax: AddDefaultCharset On|Off|charset
Default: AddDefaultCharset Off
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Core
Module:coreThis directive specifies a default value for the media type charset parameter (the name of a character encoding) to be added to a response if and only if the response’s content-type is either text/plain or text/html.

This should override any charset specified in the body of the response via a META element, though the exact behavior is often dependent on the user’s client configuration.

A setting of AddDefaultCharset Off disables this functionality. AddDefaultCharset On enables a default charset of iso-8859-1. Any other value is assumed to be the charset to be used, which should be one of the IANA registered charset values for use in MIME media types. For example:

AddDefaultCharset utf-8

AddDefaultCharset should only be used when all of the text resources to which it applies are known to be in that character encoding and it is too inconvenient to label their charset individually.

One such example is to add the charset parameter to resources containing generated content, such as legacy CGI scripts, that might be vulnerable to cross-site scripting attacks due to user-provided data being included in the output. Note, however, that a better solution is to just fix (or delete) those scripts, since setting a default charset does not protect users that have enabled the “auto-detect character encoding” feature on their browser.

Einige ergänzende Kommentare:

Ist die Direktive AddDefaultCharset gesetzt, so fügt Apache Zeichensatzinfos zum Content-Type-Header von HTTP-Antworten hinzu. Z.B.:

Content-Type: text/html; charset=iso-8859-1

Ist eine solche Angabe vorhanden, so übersteuert das bei den meisten Browsern eine evtl. vorhandene Meta-Tag-Angabe zu Zeichensätzen in der empfangenen HTML-Datei. (Dies war ja gerade die Ursache des oben beschriebenen Problems).

Man beachte, dass man lt. der obigen Beschreibung ein solches Verhalten auch durch

AddDefaultCharset Off

explizit abschalten kann.

Ferner kann man - soweit sonstige Einstellungen das zulassen - die Direktive “AddDefaultCharset” auch zusammen mit “.htaccess”-Dateien, also verzeichnisspezifisch, einsetzen.

Lösungsansätze für die Zeichensatzsteuerung

Auf den von mir selbst verwalteten Servern setze ich grundsätzlich eine serverweite Einstellung ein - in meinem Fall ISO-8859-1 (per AddDefaultCharset ISO-8859-1 ) in den globalen Apache-Einstellungen (bei SLES 9 in /etc/apache2/mod_mime-defaults.conf).

Ein Grund hierfür sind die Sicherheitsbedenken, die in der Apache-Doku bzgl. des Abschaltens anklingen und auf die man in diversen Internet-Artikeln treffen kann.

Virtuelle Domainen mit spezifischen Default Zeichensätzen

Für größere Kunden-Projekte (Webseiten-Entwicklung) lege ich mir zumeist separate virtuelle Domainen an. (Das erleichtert später den Aufruf der Seiten beim Testen, macht die Umgebung kontrollierbarer und spiegelt schon in der Entwicklungsphase mehr die Realität der Kundensicht wieder.) Habe ich eine durchgehend einheitliche Zeichensatzverwendung für die Webseiten der virtuellen Domaine zu erwarten, setze ich den Default-Zeichensatz in der Konfiguration der virtuellen Domaine per “AddDefaultCharset” auf den entsprechenden Wert.

Einsatz von “.htaccess”-Dateien für verzeichnisspezifische Festlegungen

Muss ich mit unterschiedlichen Zeichensätzen der zu erstellenden Webseiten rechnen, so versuche ich eine Strategie zu fahren, bei der man die Dateien mit jeweils gleichen Zeichensätzen in Verzeichnissen bündelt. Dann kann man nämlich zum “.htaccess”-Mechanismus greifen und die verzeichnisspezifischen Einstellungen über die Festlegungen in zugehörigen “.htaccess”-Dateien treffen. Alternativ kann man auf Servern, die der eigenen Kontrolle unterstehen, aber auch über gezielte Direktiven in <Directory>-Abschnitten zur jeweiligen Domaine vorgehen.

Über den Einsatz von “.htaccess”-Dateien erschlägt man übrigens evtl. Probleme bei den meisten Providern - soweit sie den “.htaccess”-Mechanismus überhaupt zulassen.

Verzeichnisspezifisches Abschalten des Default Zeichensatzes kann u.U. eine Möglichkeit sein

Hat man einen Mix aus Dateien mit unterschiedlichen Zeichensätzen in ein und demselben Verzeichnis einer (virtuellen) Domaine zu erwarten, so schalte man entweder die Zeichensatzvorgabe für die gesamte Domaine oder das Verzeichnis ab (”AddDefaultCharset Off”). In letzterem Fall natürlich wieder über eine “.htaccess”-Datei.

Der gezielte Einsatz von Dateiendungen

Will man zu keinem der oben genannten Mittel greifen, so kann man immer noch über Dateiendungen arbeiten. Die Zusatzangaben zu Datei-Endungen in den Direktiven “AddCharset” legen nämlich fest, auf welche Dateien der Zeichensatz angewendet werden soll.

AddCharset utf-8   .utf8

Eine betroffene Datei “test.html” muss dann halt in “test.html.utf8″ umbenannt werden. Nach gleichem Muster verfährt man für Dateien mit anderen Zeichensätzen - also: Datei-Endung für den Zeichensatz vorgeben und hinten an den Dateinamen anhängen.

Links und weitere Informationen

Grundsätzliches :
http://httpd.apache.org/docs/2.0/mod/core.html

Generelle Möglichkeiten, die Zeichensatz-Regeln des Apache-Servers für spezielle Verzeichnisse oder Files anzupassen, werden unter folgenden Links diskutiert:
http://www.w3.org/International/questions/qa-htaccess-charset
http://www.linuxforen.de/forums/showthread.php?t=229702

Das Vorgehen zur konsequente Umstellung eines LAMP Servers auf UTF-8 kann man z.B. unter folgenden Links nachlesen:
http://wiki.hetzner.de/index.php/Utf-8
http://www.xaranetblog.de/page/5/

Geschrieben in Apache, LAMP / Webentwicklung, Erfahrungsberichte | Keine Kommentare »