Opensuse Leap 42.1, Apache 2.4, Nagios-Modul und veraltete Access Right Syntax

Vor kurzem hatte ich das zweifelhafte Vergnügen, einen virtualisierten LAMP-Server von Opensuse 13.1 auf Opensuse Leap 42.1 zu hieven. Das ging zu meiner Überraschung weitgehend problemfrei über die Bühne. Eine kleine Besonderheit gab es aber schon.

Problem mit Apache 2.4 und der Konfiguration des Nagios-Moduls

Das Problem, dass bei der Umstellung auftauchte, war der Übergang des Apache-Servers zu einer neuen Version (2.2 => 2.4). Auf dem alten Server lief auch das Nagios-Modul für Apache mit. Nach dem Upgrade auf Opensuse Leap 42.1 verweigerte Apache den Start.

lamp:~ # systemctl start apache2.service 
Job for apache2.service failed. See "systemctl status apache2.service" and "journalctl -xn" for details.
xlamp:~ # systemctl start apache2.service 
Job for apache2.service failed. See "systemctl status apache2.service" and "journalctl -xn" for details.

 
und

lmp:~ # systemctl status apache2.service 
apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
   Active: failed (Result: exit-code) since Wed 2016-10-19 17:47:09 CEST; 37s ago
  Process: 2279 ExecStop=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k graceful-stop (code=exited, status=1/FAILURE)
  Process: 2272 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k start (code=exited, status=1/FAILURE)
 Main PID: 2272 (code=exited, status=1/FAILURE)

Oct 19 17:47:09 lmp start_apache2[2272]: AH00526: Syntax error on line 15 of /etc/apache2/conf.d/nagios.conf:
Oct 19 17:47:09 lmp start_apache2[2272]: Invalid command 'Order', perhaps misspelled or defined by a module ...ation
Oct 19 17:47:09 lmp systemd[1]: apache2.service: main process exited, code=exited, status=1/FAILURE
Oct 19 17:47:09 lmp start_apache2[2279]: AH00526: Syntax error on line 15 of /etc/apache2/conf.d/nagios.conf:
Oct 19 17:47:09 lmp start_apache2[2279]: Invalid command 'Order', perhaps misspelled or defined by a module ...ation
Oct 19 17:47:09 lmp systemd[1]: apache2.service: control process exited, code=exited status=1
Oct 19 17:47:09 lmp systemd[1]: Failed to start The Apache Webserver.
Oct 19 17:47:09 lmp systemd[1]: Unit apache2.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

 

Problemlösung 1 – Korrektur des Files nagios.conf

Die Ursache dieses Problems liegt in der Anweisungssyntax der Konfigurationsdatei zum Nagios-Modul und nicht im Nagios-Modul selbst. Die Anweisung zu den Zugangsrechten für Webserver-Verzeichnisse sind zwar noch für Apache-Versionen < 2.4 gültig; nicht aber für die Version 2.4.

Nehmen wir als Beispiel die Direktiven zu einem Verzeichnis aus der Datei „/etc/apache2/conf.d/nagios.conf“:

   
<Directory "/usr/lib/nagios/cgi">
#  SSLRequireSSL
   Options ExecCGI
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /etc/nagios/htpasswd.users
   Require valid-user
</Directory>

Hier werden die Zugangsrechte in klassischer Manier durch die Statements

   Order allow,deny
   Allow from all

geregelt. Diese Statements sind unter Apache 2.4 aber nicht mehr zu verwenden!

Nähere Informationen zur neuen Syntax liefert die Dokumentation unter:
https://httpd.apache.org/docs/2.4/upgrading.html

Die obige Sequenz ist – falls man die Zugriffsberechtigung tatsächlich so handhaben will –
durch das Statement

Require all granted

zu ersetzen. Also

   
<Directory "/usr/lib/nagios/cgi">
#  SSLRequireSSL
   Options ExecCGI
   AllowOverride None
#	
   Require all granted 
   #   Order allow,deny
   #   Allow from all
#
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /etc/nagios/htpasswd.users
   Require valid-user
</Directory>

Die auskommentierte Sequenz

#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1

wäre übrigens zu ersetzen durch

Require host 127.0.0.1

Führt man die vorgeschlagenen Änderungen für alle Directories in der „nagios.conf“ durch, so läuft der Neustart u.U. erfolgreich. In meinem Fall war das nicht so, da ich natürlich auch in anderen Konfigurationsfiles (u.a. zu Webdomainen) weitere Access Right Statements mit alter Syntax eingefügt hatte. Hat man auch die dortigen Fehler korrigiert, läuft Apache2 wieder.

Problemlösung 2 – Nutzung eines Kompatibilitätsmoduls

Die Seite https://httpd.apache.org/docs/2.4/upgrading.html empfiehlt, wenn möglich, alle Änderungen auf einen Schlag durchzuführen. Das kann je nach Apache-Host und selbst eingeführten Zugangsrechten für die implementierten Web-Domainen aber aufwändig werden.

Ist einem diese Arbeit erstmal zu viel und will man nach dem Upgrade zunächst nur den Start des Apache-Servers trotz der neuen Syntax sicherstellen, so kann man das Modul „mod_access_compat“ zu den Modulen hinzufügen, die der Apache-Server laden soll.

Hierzu benutzt man z.B. das Kommando „a2enmod“ (s. etwa http://www.sysadminslife.com/linux/aktivierte-apache-module-anzeigen-deaktivieren-aktivieren/.
Unter Opensuse kann man die Module aber auch in einer entsprechenden Zeile der Datei „/etc/sysconfig/apache2“ hinterlegen; also z.B.:

APACHE_MODULES=“actions alias auth_basic authn_file authz_host authz_groupfile authz_user autoindex cgi dir env expires include log_config mime mod_access_compat mod_rewrite negotiation setenvif ssl userdir php5 reqtimeout authn_core authz_core version“

Viel Spaß weiter beim Betrieb von Apache!

Apache Rewrite für zwei Domänen, die gemeinsame Datei-Ressourcen nutzen

Gestern wurden wir mit zwei Websites konfrontiert, die wir um einen Blog ergänzen sollten. Die Webserver-Installation, die wir vorfanden, war interessant und hat uns ein wenig beschäftigt:

Zwei Domain-Namen (alpha.de und beta.de) waren beim Hosting-Provider mit ein und demselben Webserver-Verzeichnis verbunden. Dieses wiederum wies zwei Unterverzeichnisse auf, in denen sich vor allem HTML-Seiten zu den verschiedenen Domänen befanden. Die Idee hinter diesem Setup war wohl, von den Webseiten beider Domänen aus gemeinsame Datei-Ressourcen im Hauptverzeichnis zu nutzen.

Setup zur Nutzung gemeinsamer Datei-Ressourcen durch zwei Web-Domänen auf demselben Webserver

Nennen wir das Hauptverzeichnis mal dir_domains und die Subverzeichnisse dir_alpha und dir_beta.

Die Webseiten von alpha.de und beta.de nutzen gleiche Datei-Ressourcen (CSS-Dateien, Javascripts, PHP-Programme, …). Entsprechende Verzeichnisse fanden sich unter dir_domains:

dir_domains (Webserververzeichnis für Domains alpha/beta)
|__css
|__js
|__php
|__index.php
| ….
|
|__dir_alpha
|        |__index.html
|        |…(HTML-Dateien für die Domäne beta.de)
|        | ….
|__dir_beta
         |__index.html
         |… (HTML-Dateien für die Domäne beta.de)
         |…

Die Datei index.php übernahm die Zugangssteuerung für die Startseiten: Je nach Domain-Anforderung (alpha.de oder beta.de) des Users wurde dieser auf die jeweilige Index-Seite unter dir_alpha oder dir_beta umgelenkt. So weit, so gut – oder eher so schlecht ….

Nach Inaugenscheinnahme der beiden Domänen im Internet war mir klar, warum das so aufgesetzt worden war:

Die Webseiten unter alpha.de bzw. beta.de haben einen ganz ähnlichen Aufbau und nutzen gleiche PHP-Programme und Scripts. Da bei der Anforderung von Ressourcen wie CSS-/JS-/PHP-Dateien Domaingrenzen in der Verzeichnisstruktur des Web-Servers normalerweise nicht überschritten werden dürfen, waren die Web-Designer gezwungen gewesen, beiden Domänen dasselbe Hauptverzeichnis des gehosteten Webserver-Accounts zuzuweisen. Zur Kompensation musste eine Art Umlenkung auf die jeweiligen Verzeichnisstrukturen integriert werden. (Anmerkung am Rande: Die Domängrenzen, im Sinne von Verzeichnisgrenzen, gelten übrigens nicht für Include-Dateien, die in PHP-Programmen nachgeladen werden. Solche Include-Dateien kann man ruhig oberhalb des Domainverzeichnisses unterbringen!).

Was war am Setup schlecht?

Während die Nutzung gemeinsamer Ressourcen durchaus zu befürworten ist, war die „Umlenkung“ durch das PHP-Skript schlecht gelöst. Sie funktionierte eigentlich nur für den Aufruf einer der beiden Domän-Namen selbst (Umlenkung auf die jeweilige index.html-Seiten). Die Navigation innerhalb der Webseiten einer Domäne war über relative Pfade gelöst; sobald ein User sich einmal innerhalb einer Domäne bewegte, funktionierte deshalb alles aus Nutzersicht alles bestens.

Aber: Der Aufruf einer spezifischen Seite einer Domäne über eine direkte Eingabe in die Adresszeile des Browsers – z.B. http://alpha.de/infos/impressum.html – funktionierte mit dem vorhandenen PHP-Script nicht. Das Script index.php kümmerte sich nur um die Index-Seiten der Domänen. Es wurde als Index-Datei ja nur dann aktiv, wenn eine der Domän-Adressen alpha.de oder beta.de ohne weitere Zusätze im Browser
aufgerufen wurde.

Lösungsansatz über Apache Rewrite

Bei dem gehosteten Webserver handelte es sich um einen Apache-Server. Eine saubere Lösung für den gewünschten Setup-Ansatz mit geteilten Datei-Ressourcen besteht dann natürlich darin, das Apache Rewrite-Modul (mod_rewrite) zu nutzen. Die Servereinstellungen beim Provider waren so, dass die Rewrite Engine über lokale „.htaccess“-Dateien aktiviert und gesteuert werden konnte. Wir haben dann folgenden einfachen Vorschlag umgesetzt:

Inhalt der .htaccess-Datei für das Verzeichnis dir_domains:

Options +FollowSymLinks 
RewriteEngine On 
RewriteBase /

RewriteRule ^alpha/(.*)$ - [L]
RewriteRule ^beta/(.*)$ - [L]

RewriteRule ^css/(.*)$ - [L]
RewriteRule ^images/(.*)$ - [L]
RewriteRule ^php/(.*)$ - [L]
RewriteRule ^script/(.*)$ - [L]

RewriteCond %{SERVER_NAME} alpha.de [OR]
RewriteCond %{SERVER_NAME} www.alpha.de
RewriteRule ^$ alpha/index.html [L]

RewriteCond %{SERVER_NAME} alpha.de [OR]
RewriteCond %{SERVER_NAME} www.alpha.de
RewriteRule ^(.*)$ alpha/$1 [NC,L]

RewriteCond %{SERVER_NAME} beta.de [OR]
RewriteCond %{SERVER_NAME} www.beta.de
RewriteRule ^$ beta/index.html [L]

RewriteCond %{SERVER_NAME} beta.de [OR]
RewriteCond %{SERVER_NAME} www.beta.de
RewriteRule ^(.*)$ beta/$1 [NC,L]

 
Die ersten 2 Rewrite-Regeln sorgen dafür, dass keine Umlenkung mehr vorgenommen wird, wenn man sich bereits im Verzeichnisbereich der Seite befindet. Dieser Vorspann ist wichtiger, als man meinen möchte: die nachfolgenden Regeln würden für sich allein zu einer unbegrenzten Iteration von Rewrites führen!

Die nächsten 4 Regeln sorgen dann dafür, dass Verweise auf die gemeinsam genutzten Ressourcen-Verzeichnisse und zugehörige GET-Anforderungen an den Server unangetastet bleiben. Diese Verzeichnisse werden ja aus dem HTML-Code der Webseiten unter dem alpha- bzw. dem beta-Sub-Verzeichnis referenziert; z.B. über relative Pfade.

Danach kommen die eigentlichen Umlenkungsregeln. Wir haben hier die Grundregel befolgt, dass eine oder mehrere Rewrite Conditions sich nur und ausschließlich auf die nächste Rewrite Rule beziehen – also auf genau eine Rewrite Rule! Das wird in der hektik oft übersehen; es gibt keine native Klammerung mehrerer Rewrite Rules zu Rewrite Conditions. Allerdings kann man mit Negationen der Bedingungen und Skip-Zusätzen hinter den Rewrite-Regeln tricksen. Um das Verständnis nicht zu erschweren, haben wir hier auf solche Hacks verzichtet.

Wird keine Dateiname angegeben – ist also der Pfad hinter dem Domain-Anteil leer – wird auf die jeweilige Index-Seite umgelenkt. Sind konkrete Webseiten einer Domäne angefordert, wird auf die gewünschte Datei im jeweiligen Unterverzeichnis verwiesen.

Das war es schon; die Datei index.php kann und sollte danach gelöscht werden. Unser Kunde kann nun 2 Domänen im gleichen Webserververzeichnis nutzen und zwischen beiden Implementierungen gemeinsame Ressourcen teilen. Eigentlich eine nette kleine Geschichte, die ich vielleicht auch mal für eigene Sites nutzen werde – Apache sei Dank!

Lokaler Apache/PHP-Testserver

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 !

Ergänzung 02.10.2012:

Eine knappe Grundinstallationsanleitung zu Apache2, MySQL, PHP (LAMP) unter Opensuse 12.1 findet man übrigens unter:
http://www.
liveconfig.com/de/kb/9.html

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