Hallo Christian,
kein Problem. Du kannst den neuen Apache ja erstmal auf einem anderen Port
und in einem anderen Verzeichnis hochfahren und dann in Ruhe alle Module
unter dem neuen Port testen. Der alte Apache kann dabei problemlos
weiterarbeiten.
Ich habe mir folgende Arbeitsweise angeeignet:
- Download des Sourcecodes zum Apache und aller weiteren notwendigen Module.
- Anlegen eines Arbeitsverzeichnisses zum Kompilieren des neuen Apache's.
Das Arbeitsverzeichnis sollte ganz leer sein. Der "make install"-Lauf
legt die notwendigen Unterverzeichnisse später eigenständig an.
- Anpassung der Datei "config.layout".
Es ist wichtig, daß der neue Apache während der Tests in ganz anderen
Verzeichnissen abgelegt wird, als der produktive Apache.
Wenn zwei verschiedene Apache's parallel betrieben werden sollen,
dann ist es schliesslich gar nicht gut, wenn beide Apache's in das
gleiche Logverzeichnis schreiben.
Es muss also eine Konfiguration angelegt werden, die dafür sorgt,
daß beim "make install"-Lauf sämtliche Dateien in Verzeichnissen
unterhalb des Arbeitsverzeichnisses abgelegt werden. Hierzu lässt
sich das opt-Layout mit ein paar kleinen Anpassungen ganz gut nutzen.
- Erstes Kompilieren eines Grund-Apache's (ohne jegliches Modul)
mit Angabe des Ports und des geänderten Layouts.
Dieser erste Compile-Lauf dient zum grundsätzlichen Testen des neuen
Apache's. Bei Systemen, auf denen noch nie ein Apache kompiliert wurde,
scheitert dieser Schritt oftmals schon an den Grundvoraussetzungen zur
Kompilierung des Apache's. Wenn man sich also viel Zeit bei der späteren
Fehlersuche sparen möchte, dann sollte man diesen Schritt unbedingt
durchführen. Treten hierbei Probleme/Fehler auf, dann müssen diese
erstmal gelöst werden, bevor es weitergehen kann.
- Aufruf von "make install" kopiert den neu gebauten Grund-Apache mit allen
Konfigurationsdateien in das bis jetzt leere Arbeitsverzeichnis.
Dabei werden auch alle notwendigen Unterverzeichnisse angelegt.
- Abgleich der vom "make install"-Lauf angelegten neuen httpd.conf
mit der bestehenden httpd.conf-Datei des produktiven Apache's.
- Wenn es neue Einträge/Features in der httpd.conf gibt, die es in der
alten
httpd.conf noch nicht gibt (weil der alte Apache ggf. eine Uralt-Version
ist),
nehme ich meist die neue httpd.conf als Vorlage und uebertrage alle
abweichenden Konfigurationseinstellungen der produktiven httpd.conf
in die neue httpd.conf im Arbeitsverzeichnis (nicht gerade komfortabel,
hat sich aber bewährt).
- Nochmalige Kontrolle der httpd.conf, damit der Apache auch wirklich auf
dem richtigen Port hochfährt.
- Testlauf des Grund-Apache's auf dem neuen Port.
- Kontrolle der Apache Logfiles.
- Kompilieren des neuen Apache's mit allen notwendigen Modulen (das ist
meist der schmerzhafteste und zeitaufwändigste Teil der Arbeit)
- Ein erneuter "make install"-Lauf zum Kompilieren des mit allen Modulen
bestückten Apache's wird die mühsam angepasste httpd.conf in unserem
Arbeitsverzeichnis nicht überschreiben (keine Angst!)
- Starten des neuen Apache's
- Abnahmetest aller betroffenen Internet-/Intranet-Anwendungen
- Nach erfolgreichem Abschluß der Abnahmetests, kann dann der
alte Apache heruntergefahren werden und der neue Apache wird so
konfiguriert, daß er die produktive Arbeit aufnehmen kann.
Aufwand: je nach Apache-Kenntnissen und Anzahl der auftretenden Probleme
mit den einzubindenden Modulen, ca. 1-3 Manntage.
Gegenüber Verbesserungsvorschlägen, die den Ablauf optimieren, bin ich
aufgeschlossen.
Gruß
Marcus Reimann
M. Reimann Systemberatung
http://www.reimann-systemberatung.de
-----Ursprüngliche Nachricht-----
Von: Christian Talberg [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 9. Mai 2003 15:01
An: users-de@httpd.apache.org
Betreff: laufenden Indianer updaten
Hallo Liste,
ich pflege einen (geerbten) apache 1.3.19 auf Suse 7.2 mit SSL - im
wesentlichen
eine Standardkonfiguration via RPMs - leider weiss ich nicht alles über
die Installation, sprich Abhängigkeiten usw - und ich will mich nicht
totbasteln an dem Ding.
Der Apache soll im laufenden Betrieb auf 1.3.27 aktualisiert werden.
Hat jemand einen einen Link oder eine Anleitung wie das am besten
vonstatten geht? Einfach passende RPMs für Suse 7.2 einzuspielen
scheitert an div Modulabhängigkeiten und ich will nicht alles neu
aufsetzen.
Ggf. eine Parallelinstallation - wenn ja wie?
Ich würde es am liebsten neu kompilieren und separat installieren
damit ich weiß was läuft - aber die laufende Kiste brauche ich halt
auch - Tips?
--
Best regards,
Christian Talberg
mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
