TechNixen.net

Kein Programm fängt bei Null an. Idealerweise steht nicht nur für die betriebssystemnahe Funktionalität, sondern auch für die Oberflächenprogrammierung, für Datenbankzugriffe, für mathematische Berechnungen usw. ausgetestete Basis-Software zur Verfügung. Solche nach Themenbereichen zusammengefassten Grundfunktionen werden Bibliotheken (Libraries) genannt.

Da beliebig viele Programme auf einer bestehenden Bibliothek aufbauen können, liegen Letztere häufig in übergeordneten Spezialverzeichnissen. Diese wären z.B. /lib, /usr/lib und /usr/local/lib. Unterschiedliche Fassungen ein und derselben Bibliothek erhalten verschiedene Versionsnummern, wodurch sie im selben Verzeichnis "koexistieren" können.

Woher weiss nun ein Programm, wo sich die benötigten Bibliotheken befinden? Eine sehr starre Möglichkeit wäre, die Datei in einem bestimmten Verzeichnis und nur dort zu suchen. Mit einem symbolic link, dessen Name dem der Bibliothek entspricht, könnte auf eine andere Datei auch in einem anderen Verzeichnis verwiesen werden.

Häufig wertet ein Programm eine bestimmte Umgebungsvariable wie etwa LD_LIBRARY_PATH aus, um die zu durchsuchenden Bibliothekspfade zu erhalten. Oder aber die globale Verzeichnisliste /etc/ld.so.conf wird gelesen und die dort eingetragenen Pfade der Reihe nach überprüft.

Doch nicht nur das Auffinden der Bibliotheken ist eine Herausforderung. Welcher Compiler ist auf der Maschine installiert? Sind alle notwendigen globalen Definitionen bzw. die zugehörigen Include-Dateien vorhanden? Gibt es Native Language Support? Eventuell: Welche Datenbank wird verwendet? Usw. usw.

Dank Paketmanagern wie aptget für Debian und rpm von Redhat bzw. libtool, einem Generator für Analyse- und Übersetzungs-Scripten, muss sich frau in problemlosen Fällen nicht um solche Details kümmern. Treten allerdings Fehler während der Installation auf, sollte jede in etwa wissen, wie sie deren Ursachen auf den Grund gehen kann.

Ich beziehe mich bei den folgenden ersten vier Schritten auf den Download einer komprimierten Datei, z.B. im tar.gz-Format:

1. Durchsuchen der Web-Site nach Installationshinweisen und - falls vorhanden - lesen 2. Download der komprimierten Source- oder Binary-Fassung und Ablage im gewünschten Installationsverzeichnis 3. Entkomprimieren der Datei z.B. mit gunzip datei.tar.gz tar -xvf datei.tar 4. Suchen einer Datei namens INSTALL oder Ähnlichem und lesen

Sowohl Apache als auch MySQL können während des Boot-Vorgangs automatisch gestartet werden. Um sicher zu gehen, dass keine ältere Version läuft, die den Test der neuen Fassung behindern würde, sollte zu Beginn ein ps auf die beiden Prozesse gemacht werden. Z.B.:

ps -elf | grep httpd für den Apache und ps -elf | grep mysqld für den MySQL-Server

Wie Boot-Start- und Shutdown-Stop-Anweisungen entfernt werden, hängt von der Linux-Distribution ab. Für neuere SuSE-Varianten gibt es z.B. den Runlevel-Editor innerhalb von YAST2. Nicht mehr benötigte Scripts in /etc/init.d lassen sich auch von Hand in ein Backup-Verzeichnis verschieben. Die zugehörigen symbolic links in den Unterverzeichnissen rc3.d und rc5.d können dann gelöscht werden. Wie immer gilt bei solchen Aktionen, vorher READMEs, Hilfetexte und Dokumentationen zu Rate zu ziehen und darauf zu achten, dass jede Änderung rückgängig gemacht werden kann.

Installation von MySQL4.1.5

Über einen garnicht so seltenen Fallstrick bin ich bei der Installation der 4.1.5er-Binary-Version von MySQL gestolpert: Eine deutlich ältere Version war bereits installiert und in Gebrauch. Obwohl ich mich streng an die Installationsanweisungen gehalten habe, greift die neue Fassung teilweise auf inkompatible Bestandteile der alten zu:

1. Z.B. mysql-standard-4.1.5-gamma-pc-linux-i686.tar.gz in /programs/mysql entpacken 2. Den Anweisungen von /programs/mysql/mysql-standard-4.1.5-gamma-pc-linux-i686/INSTALL-BINARY folgen (Bei einer Binary-Version müssen die Quelldateien - oder Sourcen - nicht mehr in maschinenlesbare ausführbare Dateien - oder Binaries - übersetzt werden.) 3. Den MySQL-Server starten 4. Mit ps - z.B. ps -elf | grep mysqld - überprüfen, ob der Prozess läuft und bei Bedarf mit mysql_config die zu Grunde gelegten Parameter sichten. (Das MySQL-bin-Verzeichnis muss dafür vor /usr/sbin über die PATH- Umgebungsvariable bekannt gegeben worden sein.)

Achtung: Ein veraltetes .my.cnf im $HOME-Verzeichnis kann dazu führen, dass das Hilfsprogramm mysqladmin über den Socket /var/lib/mysql/mysql.sock zu kommunizieren versucht, während der Server an /tmp/mysql.sock lauscht. Die globale Konfigurationsdatei /etc/my.cnf sollte durch die Installation auf den neuesten Stand gebracht sein. Eine Server-spezifische Variante kann angelegt werden, indem /usr/local/mysql/support-files/my-small.cnf, -my-medium.cnf, -my-large.cnf oder my-huge.cnf nach /usr/local/mysql/data/my.cnf kopiert wird.

Da ich aus historischen Gründen den Befehl rcmysql start bzw. rcmysql stop gewöhnt bin, habe ich abschließend in /usr/sbin einen symbolic link namens rcmysql mit Ziel /usr/local/mysql/support-files/mysql.server erzeugt, wobei /usr/local/mysql gemäß den Anweisungen in INSTALL-BINARY wiederum ein link auf /programs/mysql/mysql-standard-4.1.5-gamma-pc-linux-i686 ist.

Installation von Apache2.0.5

1. Z.B. httpd-2.0.50-i686-pc-linux-gnu.tar.gz in /programs/apache entpacken 2. /programs/apache/httpd-2.0.50/INSTALL lesen

Auch in diesem Fall existierte bereits eine ältere Version, die nun nicht mehr automatisch gestartet werden und sich nicht bei einem apachectl- oder rcapache-Befehl angesprochen fühlen soll.

Achtung: Bei ernsthafter Nutzung der alten Apache-Version empfiehlt es sich, die ursprüngliche /etc/httpd/httpd.conf zu sichern!

Die Apache-Source-Fassung wird mit Hilfe des Script-Generators libtool übersetzt und installiert. Normalerweise bedeutet dies, dass für die Installation lediglich die Aufrufe

./configure make make install

notwendig sind. ./configure analysiert die Gegebenheiten auf dem Rechner, mit make werden die Sourcen übersetzt, make install verteilt die ausführbaren Dateien. Soll ein Programm unter geänderten Bedingungen erneut übersetzt werden, löscht ein make clean vor dem make die bereits erzeugten Binaries. Denn make übersetzt eine Source nur dann, wenn das zugehörige Binary nicht existiert oder wenn das Änderungsdatum des Binary älter ist als das der Source.

Eine spezielle Anmerkung zu Apache 2.0.5: make sollte nicht als root aufgerufen werden, da absolute Pfade wie /home/gatekeeper/minfrin eine fehlerfreie Übersetzung verhindern.

Ziel meines Tuns war es, eine Testumgebung mit Apache 2 und PHP 5 zu erhalten. Aus diesem Grund genügte ein einfaches ./configure für Apache nicht. Aus der Datei INSTALL zu php-5.0.2 ist zu erfahren, dass Apache 2 zumindest mit der --enable-so-Option zu konfigurieren ist. Sie bewirkt, dass Apache zusätzliche Module nachladen kann.

Sicherheitshalber habe ich über die --prefix-Option auch noch den Zielpfad /usr/local/apache2 für das spätere make install angegeben. Welche Konfigurationsoptionen insgesamt zur Verfügung stehen, kann über ./configure --help bzw. ./configure -h ermittelt werden.

Folgende Anweisungen funktionierten problemlos: ./configure --prefix=/usr/local/apache2 --enable-so make make install

Der mir vertraute Aufruf über rcapache wird abschließend per Hand durch einen symbolic link gleichen namens in /usr/sbin auf /usr/local/apache2/bin/apachectl ermöglicht.

Sollen httpd und apachectl ohne Pfadangabe direkt aufrufbar sein, muss /usr/local/apache2/bin vor /usr/sbin zur Umgebungsvariable PATH hinzugefügt werden.

Installation von PHP5.0.2

Die Installationsanleitung für PHP5.0.2 warnt ausdrücklich davor, Apache 2 und PHP5.0.2 in einem produktiven System einzusetzen. Erfahrungen mit dieser relativ neuen Kombination sollten über Testszenarien möglichst gefahrlos gesammelt werden.

1. Z.B. php-5.0.2.tar.gz in /programs/php entpacken 2. /programs/php/php-5.0.2/INSTALL lesen

Auch die Source-Fassung von PHP5.0.2 wird mit Hilfe von libtool installiert. Die Parameter von ./configure übernehmen nun die Hauptverantwortung dafür, dass das Zusammenspiel von PHP mit MySQL und Apache funktioniert:

./configure --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/programs/mysql/mysql-standard-4.1.5-gamma-pc-linux-i686 \ --with-mysql-sock=/tmp \ --with-mysqli=/programs/mysql/mysql-standard-4.1.5-gamma-pc-linux-i686/bin/mysql_config

Über die Bedeutung der Parameter könnte ein ./configure --help Aufschluß geben. Allerdings steckt hinter der Auswahl der MySQL-Flags einiges an Try and Error. Da sich das make nach dem ersten ./configure mit einer Fehlermeldung verabschiedet hatte, blieb mir nichts anderes übrig, als genauer darauf zu achten, was Compiler und Linker während des make-Laufs von sich gaben. Auf diese Weise erfuhr ich, dass der Linker MySQL-Bibliotheken in /usr/lib/mysql suchte, anstatt in meinem neuen MySQL-lib-Unterverzeichnis nachzusehen. Die Idee, die libtool-Scripts über ./configure-Parameter auf meinen Nicht-Standard-MySQL-Pfad hinzuweisen, kam mir dann ziemlich schnell.

Der Vollständigkeit halber noch die fehlenden Schritte: make (als root:) make install cp php.ini-dist /usr/local/lib/php.ini

(in /usr/local/apache2/conf/httpd.conf:) AddType application/x-httpd-php .php .phtml AddType application/x-httpd-php-source .phps

(im PHP-Verzeichnis:) libtool --finish /programs/php/php-5.0.2/libs

Mit der letzten Anweisung wird unter anderem das Bibliotheksverzeichnis zu PHP5 bekanntgegeben. Dies könnte - falls Schwierigkeiten auftreten - auch durch den Eintrag des PHP5-Bibliotheksverzeichnisses in /etc/ld.so.conf und einen anschließenden ldconfig-Befehl geschehen.

Um Datenbankinhalte bequem verwalten zu können, habe ich mir im Anschluß daran phpMyAdmin-2.6.0-pl2 installiert. Aber eigentlich wollte ich ja nur die technixen-Seiten mit PostNuke7.5 in einer aktuellen Umgebung testen. Das wären dann die nächsten zwei Schritte.

Bis dahin Rita