Wollmilchsau Server: 3. LAMP
Kapitelübersicht:
Der LAMP ist wohl der Haupt-Einsatzzweck von Linuxservern. Das Kürzel steht
für
L - Linux als Betriebssystem A - für den Apache Webserver M - für die Datenbank MySQL P - für die Programmiersprachen PHP oder Perl.Sowohl Perl als auch PHP haben ihre Stärken und Schwächen. Die Stärke von PHP liegt m.E. bei der Vielzahl der unterstützten Datenbanken und der Steuerbarkeit. Allerdings ist das fließend, denn sowohl Perl und Perl-Module als auch PHP werden ständig weiterentwickelt. Da jeder Programmierer auch sein Lieblingskind pflegt, ziehe ich es vor, nicht in die Debatte um die besseren Programmiersprache einzusteigen. Wer lieber Perl anstelle des hier verwendeten PHP haben möchte: Es lässt sich ähnlich in den Webserver einbinden wie PHP, kein Problem, just do it. Auch beide Sprachen parallel geht ohne weiteres.
3.1. Verzeichnisse
Die von den Programmen verwendeten Pfade für Datendateien finde ich nicht besonders übersichtlich, deshalb habe ich sie verlegt. Es existiert in meinem System ein Verzeichnis /data. Unter diesem Dach finden sich die verschiedenen Datenverzeichnisse, also /data/sqldata, /data/httpd, /data/imap usw. Das ist wiederum eine eigene Entscheidung des Benutzers. Wenn Sie andere Pfade verwenden möchten, müssen die Konfigurationen entsprechend angepasst werden.
3.2. Quellen
Ich habe die Programme fast sämtlich selbst kompiliert. Die Programme wurden in der Distribution teils stark verändert. Dies kann ganz nützlich sein, kann aber auch Probleme aufwerfen, die dann schwierig zu finden sind. Dazu kommt, dass einige der von mir vorgesehenen Tests doch eigene Einstellungen bei der Kompilierung verlangen, so dass die Benutzung der fertigen Binaries ohnehin wenig Sinn macht. Es wurden aktuelle stabile Versionen von den jeweiligen Homepages verwendet (Apache 1.3.22, PHP-4.1.1, MySQL 3.23.47 und mod_ssl 2.8.5-1.3.22), jedoch keine bleeding edge-Entwicklerversionen.
3.3. Kompilation
Die Default-Kompilation nach configure-make-make install kann man nicht anwenden, wenn, wie hier, eigene Optionen gewünscht sind. Es wurde daher vor ./configure ein eigenes Script vorgeschaltet, in dem der configure-Befehl mit den gewünschten Optionen aufgeführt ist. Das ist wesentlich einfacher und weniger Tippfehler-verdächtig. Darüber hinaus ist die Konfiguration im Fehlerfall einfacher nachzuvollziehen und besser zu warten.
Wer selbst ein solches Script zusammenstellen möchte: Eine wirksame Grundlage kann man sich schnell schaffen:
>> ./configure -help > myscripterzeugt eine Datei myscript, die das Help des configure-Befehls mit allen Optionen enthält. Die benötigten Optionszeilen werden an den Dateianfang kopiert. Ergänzen Sie noch die Anfangszeilen und die Backslashes, wie in den Beispielen hier gezeigt. Achtung Falle: Nach dem Backslash muss unmittelbar CR folgen, aber keine weiteren Leerzeichen. Diese Eigenheit hat bei mir zu schwer nachvollziehbaren Abbrüchen geführt.
3.4. Sourcen
Eine einfache Handhabung: Zum Kompilieren müssen die Sourcen entpackt werden.
Hier wurde ein Verzeichnis /root/source angelegt und alle Source-tgz bzw .tar.gz dorthin kopiert. Sie werden mit tar -xzvf sourcefile dort entpackt. Das tar entpackt die Sourcen in entsprechende Unterverzeichnisse. Als Beispiel:
>> tar -xzvf apache_1.3.22.tar.gzin dem Verzeichnis /root/source erzeugt das Verzeichnis /root/source/apache_1.3.22 mit allen zur Erstellung nötigen Files usw. Um nicht jedesmal einen langen Pfad eingeben zu müssen, wurden die Verzeichnisse noch ins /root verlinkt:
>> ln -s /root/source/apache_1.3.22 /root/apacheund entsprechend für alle anderen Sourcen.
3.5. MySQL
Da PHP auf MySQL-Dateien beimKompilieren zugreift, wird zuerst der SQL-Server kompiliert. Das unten abgedruckte Script steuert die Optionen für configure. Es wird unter myscript abgespeichert.
# ! /bin/sh ./configure \ --sysconfdir=/etc/mysql \ --prefix=/usr/local/mysql \ --localstatedir=/data/sqldata \ --with-gnu-ld \ --with-mysqld-user=mysql \ --with-libwrap \ --without-debug \ --with-comment \ --without-bench \ --with-berkeley-db \ --enable-assembler --with-unix-socket-path=/var/lib/mysql/mysql.sockDas Erstellen eines solchen Scriptes ohne viel Tippen ist weiter oben beschrieben.
Es wird mit
>> ./myscriptaufgerufen. Die Ausgabe des configure-Prozesses sollte man im Auge behalten: Die Fehlerausgaben sind wichtige Hinweise, wenn etwas grob schiefläuft. Configure bricht dann ab. In den meisten Fällen sind fehlende Libraries (Bei SuSE i.d.R. in Paketen, die den Namensteil devel enthalten). Mitunter ist auch eine Option oder Kombination von Optionen unzulässig oder falsch angegeben. Ist der Fehler behoben, kann man erneut das Script aufrufen. Config fährt dann an der Stelle fort, wo es abgebrochen hat. Dies ist komfortabel, funktioniert aber nicht immer reibungsfrei. Wer sicher gehen will, sollte zuerst ein make clean aufrufen, dann die Dateien config.log, config.cache und config.status vor einem neuen Start des Scriptes löschen.
Die eigentliche Kompilation wird nach dem Ablauf des configure-Scriptes mit
>> makegestartet. Die Kompilation von MySQL dauert auch auf schnellen Rechnern einige Zeit. Also ist der nächste Kaffee fällig. Ist der Kompilierlauf ohne Fehler beendet worden, wird mit
>> make installdas Installieren der Dateien aufgerufen.
Als nächster Schritt muss der System-User für MySQL geprüft und ggf. angelegt werden. Der User heisst mysql, die Usergroup ist bei SuSE daemon. Für andere Distributionen muss man gegebenenfalls entsprechende eigene Gruppen bzw. User anlegen.
Wie üblich verwaltet MySQL Benutzer, Zugriffsrechte usw. in eigenen Tabellen, den so genannten Tables. Diese existieren nach einer Neuinstallation noch nicht, deshalb werden Sie nun angelegt. Rufen Sie zum Anlegen dieser Tables das Script
>> /usr/local/mysql/bin/mysql_install_dbauf. Das Script legt die notwendigen Tabellen an und beendet sich wieder.
Wichtig: Sie müssen die Zugriffsrechte der Dateien und Verzeichnisse ändern:
>> chown -R mysql /data/sqldata/ >> chgrp -R daemon /data/sqldataAndernfalls gibt es beim Starten von MySQL u.U. die ersten Probleme, wenn MySQL nicht korrekt zugreifen kann. Jetzt können Sie MySQL zum ersten Mal starten:
>> /usr/local/mysql/bin/safe_mysqld &Sollte nach einigen Sekunden als letzte Ausgabe ein "MySQL ended" auftauchen, liegt ein Fehler vor. Im Datenverzeichnis liegt eine Datei <servername>.err, in die MySQL seine Fehler ablegt. Meist sind Tables nicht zugänglich aufgrund falscher Pfade oder fehlender Zugriffsrechte. Ein Blick in diese Datei hilft zumeist weiter. Steht jedoch Ready for connection in der .err-Datei, dann hat alles geklappt.
Es muss nun für den root-User des SQL-Servers ein Kennwort vergeben werden. Dazu geben Sie nun folgenden Befehl ein:
>> /usr/local/mysql/bin/mysqladmin -u root password geheim(BITTE nehmen Sie ein anderes Kennwort als ausgerechnet geheim....).
Diese Befehlszeile funktioniert so nur beim ersten Aufruf. Bei allen weiteren Aufrufen muss der Parameter -p mit angegeben werden, damit das vorhandene Kennwort auch abgefragt wird...
Damit ist der SQL-Server betriebsbereit.
Sie können dies einfach testen:
>> /usr/local/mysql/bin/mysqladmin -p versionfragt zunächst das gerade vergebene Kennwort ab und gibt dann Versionsnummer und einige Betriebsdaten des SQL-Servers aus.
Es sollte für den automatischen Start noch ein Script installiert bzw. verlinkt werden.
Aus /root/source/mysql/support-files wird dazu die Datei mysql.server nach /etc/init.d kopiert
Setzen Sie die Rechte auf 744:
>> chmod 744 /etc/init.d/mysql.serverIm Runlevel 3-Verzeichnis /etc/init.d/rc3.d werden zwei Links angelegt:
>> ln -s /etc/init.d/mysql.server S22mysql >> ln -s /etc/init.d/mysql.server K01mysqlWer es ganz perfekt im SuSE-Stil haben möchte, fügt noch hinzu:
>> ln -s /etc/init.d/mysql.server /usr/bin/rcmysqlDamit ist dann auch das rcmysql start bzw stop möglich.
3.6. MySQL: Konfigurationsdatei
Für MySQL gibt es eine Reihe vorkonfigurierter Konfigurationsdateien, die man für den Testserver und viele produktive Konfigurationen unbesorgt als Grundlage übernehmen kann. Sie finden sich im Source-Verzeichnis von MySQL, im Unterverzeichnis support-files. Die Dateien heißen my-small.cnf, my-medim.cnf, my-large.cnf und my-huge.cnf. Die Einstellungen unterscheiden sich erheblich im Ressourcenverbrauch, die Optionen my-large und my-huge (0,5 GB bzw 1 - 2 GB RAM-Verbrauch) sind für ein Testsystem ungeeignet. my-small ist eine Minimalkonfiguration für Systeme mit wenig Speicher, in denen SQL nur gelegentlich verwendet wird. my-medium ist ebenfalls für wenig Speicher, jedoch häufigere Nutzung ausgelegt, besonders bei Parallelbetrieb mit PHP, Webservern usw.
Wenig Speicher bei 512 MB bestücktem RAM? Das ist schon richtig, denn Apache, PHP, Linux, Fax usw. möchten auch noch etwas vom RAM-Kuchen abbekommen ;-).
Die Konfigurationsdatei kann an verschiedenen Stellen eingetragen werden:
- Die Datei soll global für alle User und Datenbanken gelten:
Erstellen Sie ein Verzeichnis /etc/mysql, (oder das Verzeichnis, das Sie im Konfigurationsscript als sysconfdir angegeben haben) und kopieren Sie die Datei dorthin. - Die Datei soll nur für den lokalen Server gelten:
Kopieren Sie die Datei ins Datenverzeichnis (localstatedir, im Konfigurationsscript festgelegt). - Die Datei soll nur für einen User gelten:
Kopieren Sie die Datei in das Home-Verzeichnis des Users.
Besonders die letzte Variante ist für ein Testsystem nicht uninteressant. Sie ermöglicht, verschiedene Konfigurationen des gleichen Servers zu testen, indem man den User wechselt.
Nach dem Kopieren wird die Datei nach my.cnf umbenannt. Für Testversuche muss sie nicht geändert werden, oft kann man sie gänzlich lassen, wie sie ist.
3.7. Apache: Module oder nicht?
Der Apache-Webserver beherrscht grundsätzlich zwei verschiedene Arten der Konfiguration:
z.B. kann die Programmiersprache PHP als externes Modul eingesetzt werden, sie kann aber auch fest in den Webserver einkompiliert werden. Vorteil des Moduls ist natürlich seine hohe Flexibilität: Eine Revisionierung ist vollkommen problemlos, eine neue Version wird einfach installiert, dann genügt ein kurzer Neustart des Apache. Die Unterbrechungszeit beträgt nur Sekunden, der Aufwand ist gering. Dies wird erkauft mit einem geringfügig höheren Ressourcenbedarf, der aber bei den heutigen CPU's vernachlässigbar ist. Eine Revisionierung bei einkompilierten Modulen ist weitaus aufwendiger, da immer alles neu übersetzt werden muss. Für einen Testserver ist die schnelle Konfigurierbarkeit wichtig, deswegen gebe ich den externen Modulen den Vorzug.
3.8. Apache: Hinweise zur Sicherheit
Die hier beschriebene Konfiguration ist in keiner Weise sicher. Für einen produktiven Server, womöglich noch vom Internet aus zugänglich, ist eine Version mit einkompilierten Modulen u.U. sinnvoller. Darüber hinaus muss man sich einen ganzen Haufen von Sicherheitsoptionen usw. zur Konfiguration heranziehen. Ein Webserver ist ein komplexes System und dementsprechend aufwändig auf Sicherheit zu konfigurieren. Einen guten Einstieg zur Apache-Konfiguration auch in Punkto Sicherheit gibt das Buch Webserver betreiben [1].
3.9. Apache: ohne SSL
Auch hier wird eine Script-Datei myscript verwendet, die die Konfiguration
übernimmt. Es wird nur ein Modul fest einkompiliert,
--enable-module=so nimmt das mod_so mit auf. mod_so ist für das
Nachladen der anderen Module zuständig und deshalb Voraussetzung.
Apache bringt eine ganze Reihe vorgefertigter Module mit. Im myscript
für den configure-Lauf finden sich nur wenige davon aufgeführt,
einige werden als Standard mit eingebaut. Einem Einsteiger in Sachen Webserver
ist zu empfehlen, es bei der Standardauswahl zuzüglich der im Script
freigegebenen Module zu belassen. Später kann man dann immer noch Module hinzufügen.
Kompiliert und aktiviert man alle Module, kann es zu Problemen kommen. Einige Module
haben ähnliche Aufgaben (alle Module mit auth sind z.B. für
Authentifizierungszwecke zuständig). Es ist nicht einfach, die
Reihenfolge der Abarbeitung zu durchschauen, daraus ergeben sich mitunter
unvorhersehbare Nebeneffekte. Eine explizite Reihenfolge muss präzise
konfiguriert werden.
Module werden zum Kompilieren freigegeben mit
--enable-module=<modul>Will man sie als DSO (externes Modul) einbinden, verwendet man als zweiten Parameter
--enable-shared=<modul>Der Name <modul> ist dabei der Modulname ohne das vorangestellte mod_; für mod_ssl lautet der Eintrag entsprechend
--enable-module=ssl --enable-shared=sslDas verwendete Konfigurationsscript sieht so aus:
#! /bin/sh ./configure -v \ --with-layout=Apache \ --prefix=/usr/local/httpd \ --sysconfdir=/etc/httpd \ --htdocsdir=/data/httpd/htdocs \ --enable-module=so \ --enable-module=rewrite \ --enable-shared=rewrite \ --datadir=/data/httpd/ro-files \ --iconsdir=/data/httpd/icons \ --cgidir=/data/httpd/ro-cgi \ --includedir=/data/httpd/includes \ --localstatedir=/data/httpd/localstate \ --runtimedir=/data/httpd/runtime \ --logfiledir=/data/httpd/log \ --proxycachedir=/data/httpd/pcache \ --server-uid=wwwrun \ --server-gid=nogroupWer möchte, wird sich hier weitere Module aktivieren bzw. einbinden. Auch bei diesem Script wird die geänderte Verzeichniseinstellung sichtbar. Die Datendateien liegen unter /data/httpd, Binaries usw. liegen im Standard-Verzeichnis. Auch hier gilt: Beim Ausführen des Scriptes zusehen, ob Fehlermeldungen auftauchen. Läuft das Script glatt durch, kann wie gewohnt mit
>> makedas Programm kompiliert werden.Wurde ohne Fehlermeldung kompiliert, können Sie mit
>> make installdie Dateien installieren.
3.10. Apache: mit SSL
SSL-Verschlüsselung ist mit wenig Aufwand mit dem Apache zu realisieren. Wer erste Gehversuche mit SSL unternehmen will, sollte hier unbedingt einsteigen. Wer eher ein internes Webseiten-Testsystem haben möchte oder Verschlüsselung nicht benötigt, nutzt die o.a. Installation ohne SSL.
Um Apache mit mod_SSL zu installieren, sind einige Vorarbeiten notwendig
- Die Scriptdatei muss angepasst werden.
- openSSL muss installiert sein.
- Optional sollte das Programm mm installiert sein, ohnehin auch für PHP gut verwendbar.
- Beachten: openSSL kann man so kompilieren, dass eine Einbindung als DSO-Modul in Apache nicht möglich ist. Bei der getesteten SuSE 7.3 klappt das Einbinden ohne Probleme. Andere Distributionen sind von mir nicht getestet worden. Ähnliches gilt für mm.
- Und natürlich muss man sich die Sourcen von mod_ssl passend zu der verwendeten Apache-Version besorgen.
3.11. Apache: mod_ssl Konfiguration
Zum Kompilieren von mod_ssl reicht eine Standard-Konfiguration ohne besondere Optionen.
>> ./configure -with-apache=/root/source/apache_1.3.22Der Pfad zu den Apache-Sourcen muss natürlich an Ihre Gegebenheiten angepasst sein.
Das configure-Script schiebt die notwendigen Dateien usw. in das Source-Verzeichnis des Apache. Auch die Vorgabe für httpd.conf wird entsprechend modifiziert.
Das myscript für die Konfiguration des Apache mit SSL enthält zusätzliche Einträge:
#! /bin/sh SSL_BASE=SYSTEM EAPI_MM=SYSTEM ./configure -v \ --with-layout=Apache \ --prefix=/usr/local/httpd \ --sysconfdir=/etc/httpd \ --htdocsdir=/data/httpd/htdocs \ --enable-module=so \ --enable-module=ssl \ --enable-shared=ssl \ --enable-module=rewrite \ --enable-shared=rewrite \ --datadir=/data/httpd/ro-files \ --iconsdir=/data/httpd/icons \ --cgidir=/data/httpd/ro-cgi \ --includedir=/data/httpd/includes \ --localstatedir=/data/httpd/localstate \ --runtimedir=/data/httpd/runtime \ --logfiledir=/data/httpd/log \ --proxycachedir=/data/httpd/pcache \ --server-uid=wwwrun \ --server-gid=nogroup(Wie oben: Weitere Module nach Geschmack und Notwendigkeit.)
Die Zeile EAPI_MM=SYSTEM kann entfallen, wenn Sie nicht mit der MM-Library arbeiten. Sie fordert den Compiler auf, die MM-Libraries in den Dateipfaden des laufenden Systems zu suchen. MM verlegt einige Operationen von SSL von der Platte in den Speicher, es fördert die Performance. Die Zeile SSL_BASE=SYSTEM fordert den Compiler ebenfalls zur Suche im System auf, in diesem Falle werden die SSL-Libraries von OpenSSL gesucht. In beiden Fällen kann man auch den Pfad zu den benötigten Bibliotheken angeben, wenn man z.B. bestimmte Versionen unabhängig von der installierten Distribution testen möchte.
Auch hier kompilieren Sie den Apache durch Eingabe von
>> makeführen jedoch kein make install durch!
3.12. Apache: Zertifikat erstellen
Bevor sie den Apache mit SSL installieren, müssen Sie ein Zertifikat bauen.
Ein Zertifikat ist die Echtheitsbestätigung des Webservers. Anhand des Zertifikates wird die verschlüsselte Verbindung aufgebaut, gleichzeitig belegt es die Echtheit des Webservers. Im Normalfall wird ein Zertifikat von einem Trustcenter o.ä. (CA, Certificate Authority) signiert und gilt damit gemeinhin als vertrauenswürdig. Bekannte Trustcenter sind z.B. Thawte und Verisign.
Ein Exkurs: Man sollte sich hin und wieder ein paar Gedanken machen, was im Internet der Begriff vertrauenswürdig besagt. Es waren schon gefälschte Updates eines großen Softwareherstellers mit Verisign-Zertifikat im Umlauf....
Für einen Testserver ist das Signieren zu aufwändig und u.U. auch zu teuer. Deshalb wird ein Testzertifikat erstellt. Das make-File von Apache wurde so modifiziert, das es dazu herangezogen werden kann; es nutzt dazu letztlich die Funktionen von OpenSSL.
Folgende Zertifikatstypen können erstellt werden
| dummy | Nur für Packet Maintainer, u.ä. Minimalzertifikat, halt ein Dummy. |
| test | Für Testsysteme, signiert von Snake Oil. Nur zum Testen, nicht für produktive Systeme |
| custom | für echte Zertifikate, die von einer CA signiert werden |
| existing | es existiert bereits ein gültiges Zertifikat. Bei Existing muss ein Pfad zum vorhandenen Zertifikat angegeben werden! |
Für unseren Server erstellen wir ein Testzertifikat. Im Apache-Sourceverzeichnis wird dazu eingegeben:
>> make certificate TYPE=testIm Folgenden sind nur die Eingaben aufgeführt, alle anderen Felder werden mit [Enter] bestätigt. Die folgenden Abfragen beantworten Sie wie folgt:
Signature Algorithm: [R]SA or [D]SA R
Es wird der Server-Key erzeugt.
Dann:
Country Name: DE
State or Province Name: NRW (Oder ein anderes Bundesland, oder ein Dummy)
Locality Name: Entenhausen
Organization Name: Panzerknacker ltd
Organizational Unit Name: NR1805
Common Name: my.server.dom
Email Address: web@server.dom
Certifikate Validity: 999
Beachten: bei Common Name sollte schon der korrekte Name (FQDN) des Servers angegeben werden. Bei der Entgegennahme eines Zertifikates durch den Browser prüft dieser, ob Common Name und Server-URL übereinstimmen. Beim Netscape kann man z.B. in der Anzeige "Neues Zertifikat" unter "Details" feststellen, ob diese Übereinstimmung gegeben ist.
Certificate version [1] or[3] 3
Encrypt the Private Key Now [Y/n] Y
Enter PEM pass phrase [Kennwort eingeben]
Eingabe wiederholen
ACHTUNG: Dieser Text ist Startkennwort des Servers, ohne das es
erstmal keinen SSL-Zugang zum Apache gibt!
Die Zertifikate sind damit erzeugt und können mit dem Apache installiert werden. Dies besorgt wie schon gewohnt ein
>> make install
3.13. Apache: Konfiguration + Testlauf
Beim Installieren hat der Apache bereits eine ganze Reihe von Parametern übernommen. Für den ersten Start genügt diese Konfiguration bis auf ein kleines Detail, eine Änderung sollte in jedem Fall vorgenommen werden: Tragen Sie unter ServerName den echten FQDN-Name des Servers ein. Kontrollieren Sie bitte, ob die Gruppe nogroup existiert (sollte bei SuSE der Fall sein), der User wwwrun existiert und Mitglied der Gruppe nogroup ist. Die httpd.conf empfiehlt sich zum genauen Studium. Die Anzahl der Möglichkeiten ist riesengroß, entsprechend viel Unsinn kann man hier auch einbauen. Bei Änderungen sollte man recht genau wissen, was man tut. Die Erklärungen im httpd.conf sind nur als Gedächtnisstütze gedacht, nicht als Handbuchersatz. Der erste Start erfolgt nun mit dem Kommando
>> /usr/local/httpd/bin/apachectl startDas System sollte dies mit einem schlichten httpd started quittieren.
Ein lynx localhost sollte jetzt die Textausgabe des Webservers erbringen.
"If you can see this, it means that the installation of the apache web server
software on this system was successful" usw.
Wurde der Apache mit SSL konfiguriert, stoppen Sie den Apache und starten neu mit
>> /usr/local/httpd/bin/apachectl stop >> /usr/local/httpd/bin/apachectl sslstartDer Apache fragt nun nach der Passphrase, die beim Erzeugen des Zertifikates eingegeben wurde. Geben Sie die Passphrase ein, danach sollte der Server normal starten (dauert einen Moment länger als ohne SSL. Benutzen Sie nun einen SSL-fähigen Browser und melden sich mit https://your.server.here am Apache an. Wichtig dabei ist das vorangestellte https (mit dem "s" am Ende!). Das Your.Server.here ersetzen Sie natürlich mit dem Servernamen Ihres Webservers. Der Browser sollte nun die Zertifikate bestätigen und danach eine verschlüsselte (https-) Seite anzeigen.
3.14. Apache: Automatischer Start
Um den Apache beim Booten automatisch mitzustarten, müssen wieder einige Links angelegt werden wie z.B. :
>> ln -s /usr/local/httpd/bin/apachectl S23httpd >> ln -s /usr/local/httpd/bin/apachectl K23httpdWer es auch hier im SuSE-Stil haben möchte fügt noch hinzu:
>> ln -s /usr/local/httpd/bin/apachectl /usr/bin/rcapache
3.15. Apache: Entfernen der Passphrase des Zertifikates
Beim Starten gibt es zwei Möglichkeiten: Starten mit SSL erfordert eine Kennworteingabe, und ist deshalb fürs Booten wenig geeignet. Starten ohne SSL hat einen anderen Effekt: Ruft man eine PHP-Seite auf, wird statt einer Website der Quellcode angezeigt. Dies ist unerwünscht, da einerseits Quellcode abgekupfert werden kann, andererseits wird eine große Sicherheitslücke geöffnet. Man könnte jetzt die entsprechenden if-Abfragen in der httpd.conf ausbauen. Zum Test oder Betrieb z.B. eines eCommerce-Servers sollte aber eine PHP-Page nicht ohne SSL ausführbar sein, da u.U. Personendaten etc. abgehört werden können. Deshalb wird nun die Passphrase entfernt:
- wechseln Sie in das Verzeichnis /etc/httpd/ssl.key
- kopieren Sie die Datei server.key nach server.pass.key
- entfernen Sie die Passphrase mit
>> openssl rsa -in server.pass.key -out server.key - stoppen Sie den Webserver zum Testen mit apachectl stop, starten Sie ihn neu mit apachectl sslstart.
- Ein Miniscript erstellen:
# ! /bin/sh /usr/local/httpd/bin/apachectl sslstartDieses Script speichern und auf chmod 755 setzen. - Dieses Script im Verzeichnis /etc/init.d/rc3.d verlinken statt dem vorhandenen Sxxhttpd
Danach sollte der Apache beim Systemstart im SSL-Modus starten.
3.16. PHP
Auch PHP muss übersetzt werden, will man eine brandaktuelle und/oder angepasste Version haben. Wie gehabt wird auch hier ein - diesmal umfangreicheres - Script zum Konfigurieren verwendet:
# ! /bin/sh ./configure \ --with-apxs=/usr/local/httpd/bin/apxs \ --prefix=/usr/local/php \ --sysconfdir=/etc/php \ --enable-force-cgi-redirect \ --with-config-file-path=/etc/php \ --enable-safe-mode \ --enable-track-vars \ --with-db3 \ --with-gd \ --with-mysql=/usr/local/mysql \ --with-gettext \ --with-mm \ --enable-ftp \ --with-imap-ssl \ --with-zlib \ --with-png \ --disable-debug \ --with-xml \ --with-mcrypt \ --with-imapIn diesem Script sind etliche Optionen eingebunden, deshalb einige Kommentare:
| --with-apxs: | hier findet sich die APXS des Apache. Diese Datei wird benötigt, um PHP als Modul zu bauen. |
| --sysconfdir | Pfad zu Dateien der PHP-Systemkonfiguration |
| --enable-force-cgi-redirect | Security check für interne Server-Weiterleitungen. |
| --with-config-file-path | Pfad zu Dateien der PHP-Konfiguration |
| --with-db3 | Unterstützung von Berkeley DB3 |
| --with-gd | Unterstützung der Graphics Library gd |
| --with-mysql | MySQL-Unterstützung, Dateipfad zu MySQL |
| --with-gettext | gettext einbinden (Multilingual-unterstützung) |
| --with-mm | MM Speicherverwaltung einbinden (optional) |
| --enable-ftp | ftp einbinden |
| --with-imap-ssl | UW-IMAP-SSL einbinden |
| --with-zlib | zlib einbinden |
| --with-png | png-Unterstützung einbinden |
| --disable-debug | zusätzliche Debug-Optionen ausschalten. |
| --with-xml | XML-Support aktivieren |
| --with-mcrypt | mcrypt-Lib (stärkere Verschlüsselung) statt der eingebauten Verschlüsselung |
| --with-imap | UW-IMAP einbinden |
Das Script erzeugt eine ellenlange Ausgabe, deren Zeilen etwa
checking for xxxxxxx....yes
aussehen. Nicht erschrecken, wenn dort mal ein
no steht. Es wird geprüft, ob bestimmte Libraries vorhanden sind.
Dies kann z.B. unterschiedlich ausfallen, je nach dem zugrunde liegenden
Betriebssystem. Fehlt eine existenziell wichtige Datei, wird das configure
mit einer Fehlermeldung abgebrochen, installieren Sie in dem Fall die
fehlenden Dateien. In den allermeisten Fällen fehlen
Funktionsbibliotheken (Libraries). Diese finden sich bei SuSE in den
Paketen mit dem Namenszusatz -devel. Läuft das Script ohne Fehler,
kompilieren Sie wie gehabt mit make, danach werden die Dateien mit make
install einkopiert.
3.17. PHP: Hinweise:
Kompiliert man das Modul neu, um Optionen zuzufügen oder wegzunehmen, sollten Sie erst ein make clean ausführen, um vorhandene Object files etc. zu löschen. Danach sollten die Dateien config.cache, config.status und config.log gelöscht werden. Damit sind eventuelle Reste eines vorherigen Compile-Laufes beseitigt.
Wenn - wie hier - der MySQL-Support aktiviert ist, muss der Pfad zu den MySQL-Libs in der /etc/ld.so.conf enthalten sein Es ist einige Male vorgekommen, das dieser Eintrag fehlte. Das ./configure-Script brach dann mit einer entsprechenden Fehlermeldung ab. In diesem Falle hilft folgendes Vorgehen: Editieren Sie die Datei /etc/ld.so.conf und fügen Sie den Eintrag
/usr/local/mysql/lib/mysqlhinzu. Danach muss die neue Konfiguration eingearbeitet werden, dies erledigt der Befehl
>> ldconfig
3.18. PHP: Anpassen der Apache-Konfiguration
In der /etc/httpd/httpd.conf müssen folgende Anpassungen vorgenommen werden:Das PHP-Install sollte bereits eine Zeile hinzugefügt haben:
LoadModule php4_module libexec/libphp4.soFalls die Zeile fehlt, in der Sektion Dynamic Shared Objects (DSO) Support nachtragen. Sollte die mit einem # auskommentiert sein, entkommentieren Sie bitte die Zeile.
Sollte von vorherigen Tests ein ClearModuleList in der httpd.conf stehen, muss danach(!) noch ein Eintrag
AddModule mod_php4.ceingetragen werden.
Schlussendlich muss dem Apache noch die Verbindung zwischen Dateien mit der Endung .php und dem PHP4-Modul beigebracht werden. Dies geschieht durch den Eintrag
AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phpsDiese Einträge sind in der httpd-conf bereits vorhanden und müssen lediglich entkommentiert werden ( # entfernen). Da viele PHP-Programme eine Hauptseite (Index) unter PHP statt unter HTML verwenden, sollte noch eine Anpassung erfolgen.
Suchen Sie die Zeile
Directory Index index.htmlund ändern Sie sie in
Directory Index index.html index.php.Damit erkennt Apache sowohl index.html als auch index.php als default-Seite an.
Nun noch ein Neustart des Apache mit apachectl stop und apachectl start (bzw sslstart, wenn Sie den Apache mit SSL gebaut haben), dann ist das PHP-Modul eingebunden.
3.19. PHP: Konfiguration
Die Konfiguration ist vergleichsweise einfach. Im Source-Verzeichnis des PHP finden sich zwei Dateien php.ini-dist und php.ini-recommended. Erstere ist eine "Alles offen"-Datei, die für Entwicklungszwecke gedacht ist. Die Datei php.ini-recommended ist enger gefasst und entspricht den Konventionen der PHP-Version 4.
Legen Sie das Verzeichnis /etc/php an (oder ggf. das von Ihnen bei der Kompilierung angegebene Verzeichnis). Kopieren Sie eine der beiden, bevorzugt die recommended-Fassung, in dieses Verzeichnis. Ich empfehle, die beiden Dateien im Sourceverzeichnis als Referenz unverändert zu lassen. Benennen Sie die Datei in /etc/php nach php.ini um.
An sich ist die Datei so verwendbar. Eine Einstellung lohnt sich jedoch. Jede Session unter PHP erzeugt eine Referenzdatei, die mit dem Ende der Session wieder gelöscht wird. Diese Datei liegt standardmäßig in /tmp. Das Verzeichnis ist aber einfach zugänglich, eine Session könnte damit von einem Angreifer übernommen werden. Ein Geschwindigkeitswunder ist das Arbeiten mit diesem Verzeichnis auf der Platte ebenfalls nicht (auch wenn's für eine Testumgebung eigentlich egal ist).
Eine weitere u.U. nützliche Änderung: setzen Sie den Parameter error.log auf eine Datei, z.B. /var/log/php.err. Für ein Textsystem kann das ganz sinnvoll sein.
Wenn Sie PHP mit der Option -with-mm kompiliert haben, können Sie diesen Session-Handler in den Arbeitsspeicher verlegen. Dort ist er besser geschützt und schneller.
Suchen Sie dazu den Eintrag session.safe_handler = files in /etc/php/php.ini. Ändern Sie das files in mm und speichern Sie die Datei wieder ab.
ACHTUNG: Diese Änderung nehmen Sie bitte nicht vor, wenn Sie die Version 4.1.2 einsetzen.
3.20. PHP: Vorsicht, Bug`s
Diese Installation wurde erstellt und geprüft mit der PHP-Version 4.1.1. Anfang März 2002 wurde eine Sicherheitslücke in PHP bekannt, es wurde umgehend ein Upgrade auf Version 4.1.2 verfügbar. Unter der Version 4.1.2 läuft das MM-Modul nicht mehr korrekt. Tiefergehende Programme wie z.B. das test.php des Horde-Application Framework oder Squirrelmail jagen das PHP-Modul in einen Segmentation Fault!
Lassen Sie die Option with-mm im configure-Script weg oder lassen Sie in der php.ini die Option session.save_handles auf files stehen (nicht auf mm umstellen), wenn Sie die Version 4.1.2 einsetzen. Der Fehler sollte mit dem nächsten Release beseitigt sein; im letzten Snapshot ist er bereits behoben. Sollten Probleme auftreten, sollte man zunächst in der php.ini den Eintrag session.save_handles = files setzen und erneut testen.
3.21. PHP: Funktionstest
Im Dokumentenverzeichnis des Apache (hier /data/httpd/htdocs) wird eine Datei phptest.php erstellt:
<html> <body> <?phpinfo()?> </body> </html>Dieses kleine Programm kann man anschließend starten mit z.B. server.domain.local/phptest als URL im Browser oder an der Linux-Konsole mit lynx localhost/phptest.
Die Ausgabe ergibt - so denn alles läuft - eine ziemlich umfassende Info über die Befindlichkeiten des LAMP-Servers aus. Die Lektüre ist interessant.
HINWEIS: Lassen Sie dieses Programm niemals, wirklich NIEMALS, auf einem produktiven System. Wenn Sie die Ausgabe genau lesen, werden Sie feststellen: Die Info ist sehr ausführlich. Kompilations- und Konfigurationsparameter, Dateipfade, Versionen usw - alles drin. Wesentlich mehr Info kann sich ein Hacker kaum wünschen (außer dem root-password ;-) ).
Bis hier läuft alles ohne Probleme?
Herzlichen Glückwunsch! Sie haben einen kompletten LAMP-Server aufgesetzt.
3.22. Sicherheitsempfehlung
DIESES SYSTEM IST SO NICHT SICHER!
Wenn Sie dieses System in einem Netz mit Internetverbindung einsetzen, sollten Sie unbedingt Schutzmaßnahmen ergreifen. Andernfalls haben Sie selbst bei Wählverbindung einen Webserver ins Internet gestellt, der so nicht sicher konfiguriert ist.
Minimalste Absicherung wäre auf dem Server eine iptable-Regel zu etablieren, die den Zugriff auf das lokale Netz und die wirklich benötigten Dienste eingrenzt. Grundsätzlich ist eine Maschine mit vielen Diensten ein Risiko. Das Risiko steigt mit der Anzahl der Dienste. Wer auf einer solchen Maschine zusätzlich ein Gateway, z.B. per ISDN-Karte, ins Internet installiert, könnte recht schnell sein blaues Wunder erleben (und sich den verdienten Kommentar Strafe für Dummheit einhandeln). Eine Firewall unmittelbar auf dem Server bietet nur begrenzten Schutz, ist aber durchaus sinnvoll (es soll ja auch neugierige Mitarbeiter im Hause geben...). Sie ersetzt keinesfalls eine Firewall zum Internet: InternetGateway und InternetFirewall gehören in jedem Fall auf einen eigenen PC.
[1] Webserver betreiben (Schröder, Müller). dpunkt.verlag, ISBN3-932588-00-2
Talkback Area
Enter Own Comment