Apache updaten /sauber deinstallieren?
MaCo
- webserver
0 Christoph Schnauß0 MaCo
0 Michael Schröpl0 MaCo
Hallo,
ich betreibe einen lokalen SuSE Linux 7.2 Server mit Apache.
Nun möchte ich den als rpm installieren Apache 1.3.20 mit einer source-download auf 1.3.26 updaten.
meine erste Frage... mit --with-layout=SuSE kann ich ja die Verzeichnisse schön übernehmen die SuSE mir vorgibt, wunderbar, aber wie sieht das mit den Modulen und den Apacheeinstellungen (also den kompiliereinstellungen) aus? Der Apache der installiert ist ist ja ne rpm installation... wo kann ich herausfinden mit welchen Modulen der kompiliert wurde, bzw. wie kann ich sicher gehen das bei meinem update auch nur die module geupdatet werden die auch schon da sind, neue möchte ich erstmal nicht installieren...
gibt es da vielleicht ne datei die alle momentanen modul und verzechnisskonfigurationen speichert, und die man für die updateinstallation als schablone nehmen kann?
So, und dann noch eins... hat man mal einen non-rpm Apache installiert, wie kann man den dann wieder deinstallieren... also nicht unbedingt von hand löschen... im makefile gibts ja keine option für uninstall o.ä... was könnte man da tun?
Ansonsten, bitte nicht den Kopf abreisen... ich hab hier schon Apache Bücher... nur sagen die leider herzlich wenig über deinstallieren und updates... nur installation und konfiguration...
Schonmal Danke,
MaCo
hi,
wir haben wenig weiter noch einen Thread zur Apache-Installation auf einer SUSE. Nach meiner Erfahrung (ich habe fast alle SUSE-Versionen seit 4.4.2 gehabt) ist es günstiger, die "Update"-Angebote mit rpm-Paketen _nicht_ zu nutzen. Du kannst deinen "alten" Apache ganz und gar deinstallieren, sichern mußt du dir nur vorher deine httpd.conf. Bei der Gelegenheit kannst du dann auch mal die alten logfiles revidieren oder noch besser ebenfalls ganz wegwerfen, falls da nix drinstehen sollte, was du unbedingt noch als Info brauchst.
Installiere dir den Apache einfach neu, spiel deine httpd.conf zurück, das ist die einfachste (und wahrscheinlich auch "sauberste") Lösung.
gibt es da vielleicht ne datei die alle momentanen modul und verzechnisskonfigurationen speichert, und die man für die updateinstallation als schablone nehmen kann?
Das gibt es. Aber ich bin im Moment nicht mit der SUSE unterwegs, und habs nicht im Kopf, wo das Teil liegt.
Grüße aus Berlin
Christoph S.
Hi,
ja... genau das will ich ja tun.. aber wie deinstalliere ich dann wieder eine normale, non-rpm version? im Makefile ist keine uninstall option...
und für die neuinstallation würde ich schon gerne die struktur des alten Apache beibehalten, kann ich ja auch mit dem layout... aber die module sind das problem.. ich weis nicht welche bei der standartinstallation schon mitkompiliert wurden... sind das auch die normalen standartmodule die apache selber vorgibt (die im standartverzeichniss, oder sind das noch weitere, oder fehlen da noch welche)... ich bin noch kein guru auf dem gebiet, bei den meisten modulen weis ich ja noch nicht mal was die tun, oder ob sie wichtig sind...
CU MaCo
rehi,
ja... genau das will ich ja tun.. aber wie deinstalliere ich dann wieder eine normale, non-rpm version? im Makefile ist keine uninstall option...
das ist zu sehr "in Windows gedacht". Bei Windows-Programmen hast du immer das Problem, daß die registry-Einträge ja übrigbleiben (was auch beim Indianer leicht über 100 Einträge sein können). Unter LINUX gibts keine registry, es reicht also, die Dateien und Verzeichnisse (nach Sicherung der httpd.conf) einfach zu löschen - mußt du natürlich als "root" machen. Das einzige Problem ist, daß die SUSE Konfigurationsdateien, logfiles, Startscripts usw. ziemlich eigenwillig "verstreut", aber bei einer "non-rpm"-Installation hast du diese Verzeichnisse ja mal selber vorgegeben und müßtest sie wiederfinden können. Wichtig ist noch, die rc.config zu überprüfen.
Außerdem: wenn du unsicher bist und deine bisherige Installation gut läuft, kannst du dir doch einfach für nen Probelauf erst mal einen zweiten Apache dazu installieren
und für die neuinstallation würde ich schon gerne die struktur des alten Apache beibehalten,
nichts hindert dich daran ;-) Diese "Struktur" wird ohnehin von deiner httpd.conf abgefragt, da hast du alle Pfade eingetragen, die du auch wieder benötigst.
... aber die module sind das problem.. ich weis nicht welche bei der standartinstallation schon mitkompiliert wurden
und mir ist nicht ganz klar, ob wir unter "Modul" dasselbe verstehn. Falls es dir nur um die Modul-Liste in der httpd.conf geht, ist das doch leicht zu überschauen und anzupassen.
sind das auch die normalen standartmodule die apache selber vorgibt (die im standartverzeichniss, oder sind das noch weitere, oder fehlen da noch welche)
im Prinzip kann es beinahe unzählig viele weitere geben, weil es dir freisteht, für eventuelle eigene Bedürfnisse auch eigene Module zu bauen und einzubinden. Aber für den "Normalfall" sollten die Module, die mitgeliefert werden, eigentlich ausreichen. Mach dir klar, was du vom Apache verlangst und ob du dafür irgendein Modul brauchst.
ich bin noch kein guru auf dem gebiet, bei den meisten modulen weis ich ja noch nicht mal was die tun, oder ob sie wichtig sind...
einige mögen wichtig sein, das hängt wirklich davon ab, was du von deinem Apache verlangst. Um heruaszufinden, was die "Standard-Module" machen, solltest du einfach Schritt für Schritt immer mal eins einbinden und gründlich nachschauen, was dann passiert. Im übrigen gibts für alle Module eine gut entwickelte Dokumentation, die du mitgeliefert bekommst, aber auch online abrufen kannst.
Grüße
Christoph S.
CU MaCo
Hi,
hey danke für deine Tipps... das war echt hilfreich... hab das mit dem update nun tatsächlich hin bekommen... hab zwar die alte rpm nicht deinstalliert sondern einfach die 3.26 drüber installiert, aber das sollte ja keine probleme geben, oder?
Funktionieren tut das ganze auch wunderbar... nun muss ich nur noch rausfinden wieso die shared libs vom alten apache nicht mehr eingebunden werden können...
nochmals danke, hat mir sehr geholfen.
CU Maco
Hi MaCo,
Nun möchte ich den als rpm installieren Apache 1.3.20 mit einer
source-download auf 1.3.26 updaten.
fein. Ich bin nämlich kein Freund von binären Blackboxen, wenn es
auch saubere Source-Installationen gibt.
Und auf Deiner Plattform, unter Verwendung von "configure", ist das
vertretbar einfach - auf einem Windows-PC ohne C-Compiler wäre das
etwas ganz Anderes.
meine erste Frage... mit --with-layout=SuSE kann ich ja die
Verzeichnisse schön übernehmen die SuSE mir vorgibt, wunderbar,
Naja. Als "wunderbar" würde ich freiwillig nichts ansehen, was von
der Installationsstruktur dessen abweicht, was die Apache Group
selbst vorgibt - dort ist beispielsweise _alles_ innerhalb eines
einzigen Zielverzeichnisses enthalten, und das kannst Du jederzeit
auch einfach löschen, wenn Du den Apache deinstallieren willst.
Aber die Geschmäcker sind verschieden.
aber wie sieht das mit den Modulen und den Apacheeinstellungen
(also den kompiliereinstellungen) aus? Der Apache der installiert
ist ist ja ne rpm installation... wo kann ich herausfinden mit
welchen Modulen der kompiliert wurde
"httpd -l" sagt Dir das. Wohlgemerkt - damit siehst Du, was alles
einkompiliert ist - mehr nicht.
Es kann gut sein, daß Du als Ausgabe bekommst, daß "mod_so" einkom-
piliert ist und sonst nichts, weil alles andere als shared objects
nachgeladen wurde (was ich persönlich nicht mag, aber ...).
In diesem Falle mußt Du die komplette httpd.conf lesen und verstehen
(dazu schon mal mein Beileid, wenn Du eine vorgefertigte httpd.conf
mit Müllionen von "LoadModule"- Zeilen vorliegen hast).
bzw. wie kann ich sicher gehen das bei meinem update auch nur die
module geupdatet werden die auch schon da sind, neue möchte ich
erstmal nicht installieren...
Dabei mußt Du unterscheiden, wie Du mit den Modulen umgehst.
Geht es darum, sie wirklich in den Apache einzukompilieren, dann ist
jedes Modul mehr in der Tat auch mehr RAM-Belegung, aber jedes Modul
zuwenig zwingt Dich dazu, den Apache neu zu übersetzen, falls Du
Deine Meinung nachträglich änderst.
"configure" ist dafür das Werkzeug Deiner Wahl; da es extrem viele
Parameter verwendet, benutze ich ein kleines Shell-Skript, in dem ich
den "configure"-Aufruf speichere. Wenn ich ein Modul mehr brauche,
dann füge ich dort eine Zeile ein, übersetze den Apache neu (das
kann ein paar Minuten dauern), stoppe ihn, mache "make install" (das
dauert nur ein paar Sekunden) und starte ihn wieder - fertig.
Wenn Du dagegen die Module nur via mod_so dynamisch nachladen willst,
dann ist es reichlich egal, was alles an übersetzten Modulen auf
Deiner Platte herumliegt - entscheidend ist dann nur der Inhalt
Deiner httpd.conf mit den entsprechenden LoadModule-Anweisungen.
Nachladen ist also flexibler, aber nicht ganz so performant.
Und Du mußt Dich damit befassen, in welcher Reihenfolge die Module
geladen werden sollen - das ist nicht ganz einfach. Wenn Du alle
Module einkompilierst, dann übernimmt "configure" diesen Job - der
weiß, welche Reihenfolge funktioniert.
gibt es da vielleicht ne datei die alle momentanen modul und
verzechnisskonfigurationen speichert, und die man für die
updateinstallation als schablone nehmen kann?
Bei der Kompilationsmethode stehen die Module im httpd-binary drin,
deshalb kann sie via "httpd -l" ja auch ausgegeben werden.
Beim Nachladen hilft nur httpd.conf lesen und verstehen.
Was die Pfade angeht - diese Informationen sind auf viele Stellen
verstreut. Beispielsweise werden im Skript "apachectl" (mit dem
man den Apache startet etc. - vergiß alles, was Dir irgendwelche
Betriebssystem-Verpacker statt dessen anzudrehen versuchen ;-)
während dessen Installation der Installationspfad der Apache-
Binaries eingebrannt.
Auch die Apache-Konfiguration (httpd.conf) enthält Pfade Deines
Servers (z. B. ServerRoot) und wird also während der Installation
verändert.
So, und dann noch eins... hat man mal einen non-rpm Apache
installiert, wie kann man den dann wieder deinstallieren...
Dazu hat Christoph m. E. alles gesagt.
also nicht unbedingt von hand löschen... im makefile gibts ja
keine option für uninstall o.ä... was könnte man da tun?
Das ist genau der Grund, weshalb ich schon beim Installieren wissen
möchte, wo genau das "make install" herumgesaut hat.
Wenn ich per "configure ---prefix=<pfad>" ein Makefile gebaut habe,
dann kann ich mir sicher sein, daß auch nur in <pfad> das Ergebnis
von "make install" gelandet ist.
Ansonsten, bitte nicht den Kopf abreisen... ich hab hier schon
Apache Bücher... nur sagen die leider herzlich wenig über
deinstallieren und updates... nur installation und konfiguration...
Das liegt daran, daß Dein Problem gar nichts mit Apache zu tun hat,
sondern mit Deinem Unix-Verpacker, der glaubt, alles selbst und hin-
reichend anders tun zu wollen, als es vom Apache selbst vorgesehen
ist. Auch deshalb empfehle ich die Methode via "configure": Die ist
von der Apache-Dokumentation abgedeckt.
Viele Grüße
Michael
Hi,
also... ich hab jetzt das ganz mal upgedatet... mit dem SuSE Layout... zwar wäre es mir schon auch lieber alles in einem Hauptverzeichniss zu haben wie Apache das auch selber vorschlägt, aber dann ist z.b. die apachectl nicht direkt ausführbar... ich muss sie dann voll adressieren bis zu dem Verzeichniss... ansonsten liegt die ja bei mir im /usr/sbin verzeichniss... kann es sein das dieses eine besondere bewandniss im bezug auf automatisches ausführen hat (bin noch nicht so lang bei linux.. hab aber sowas ähnliches mal gelesen...).
Die rcapache ist dann wohl auch eine Datei die SuSE anlegt... gut.. und die apache in /etc/init.d/ scheint ja auch so eine zu sein... wenn das so ist, und apache selber keine erzeugt... wie kann ich dann apache wieder in die rc.3 bekommn? die ist momentan auf die /etc/init.d gelinkt... mit der runcontroll hab ich auch noch nicht soviel erfahrung, aber zumindest verstehe ich die startscripte einigermaßen (auch wenn ich die selber noch nicht verändern oder gar neu schreiben wollte/könnte)...
Gut...
das mit den Modulen hab ich nun auch einigermaßen verstanden.. zumindest den unterschied von DSO und einkompilierten Modul... ich hab noch die alten DSO module vom apache in dessen modulverzeichniss (halt von der rpm install)... wenn ich da nun eines extra einbinden will, dann gehts nicht weil er probleme mit dem modul hat... müssen DSOs auch neu kompiliert werden bevor sie wieder verlinkt werden?
So, und eine letzte Frage... ist es besser den alten apache erst zu deinistallieren (die rpm), oder den neuen gleich drüber zu installieren.. bzw. kann ich die rpm im nachhinein noch deinstallieren (dann müsste es ja eigentlich den neuen apache löschen, aber das wäre ok wenns auch die module und alles vom alten mitnimmt)...
CU MaCo
Hi,
dann ist z.b. die apachectl nicht direkt
ausführbar... ich muss sie dann voll adressieren
bis zu dem Verzeichniss...
niemand hindert Dich daran, Deine Environment-Variable
PATH um das bin-Verzeichnis der Apache-Installation
zu erweitert, oder auch in irgend einem Verzeichnis,
das schon in PATH liegt, einen symbolic link auf
apachectl zu setzen.
ansonsten liegt die ja bei mir im /usr/sbin
verzeichniss... kann es sein das dieses eine
besondere bewandniss im bezug auf automatisches
ausführen hat (bin noch nicht so lang bei linux..
hab aber sowas ähnliches mal gelesen...).
Nicht für die Automatik (da sind eher Verzeichnisse
wie /etc/* von Interesse), sondern eher für die
Zugriffskontrolle ("sbin" soll wohl "secure binaries"
heißen und erlaubt ggf. nur "root" den Zugriff etc.).
Die rcapache ist dann wohl auch eine Datei die SuSE
anlegt... gut.. und die apache in /etc/init.d/
scheint ja auch so eine zu sein...
Das ist wohl die Einbindung des Apache-Starts in den
Bootvorgang. Alles, was dort in bestimmten Verzeich-
nissen herumliegt und bestimmte Namen hat, wird beim
Booten ausgeführt ... und nein, ich kenne da nicht
die konkreten Namen, die sind ggf. bei jedem UNIX-
Dialekt irgendwie anders.
wenn das so ist, und apache selber keine erzeugt...
wie kann ich dann apache wieder in die rc.3 bekommn?
die ist momentan auf die /etc/init.d gelinkt...
Auch innerhalb von /etc/init.d darfst Du symbolic links
verwenden, würde ich mal vermuten.
ich hab noch die alten DSO module vom apache in
dessen modulverzeichniss (halt von der rpm
install)... wenn ich da nun eines extra einbinden
will, dann gehts nicht weil er probleme mit dem
modul hat... müssen DSOs auch neu kompiliert werden
bevor sie wieder verlinkt werden?
Wie ich schon gesagt hatte: Das kann durchaus der Fall
sein (falls sich am API von mod_so etwas geändert hat).
Je größer Dein Versionssprung, desto wahrscheinlicher
sind m. E. solche Probleme.
ist es besser den alten apache erst zu
deinistallieren (die rpm), oder den neuen gleich
drüber zu installieren.. bzw. kann ich die rpm im
nachhinein noch deinstallieren (dann müsste es ja
eigentlich den neuen apache löschen, aber das wäre
ok wenns auch die module und alles vom alten
mitnimmt)...
Zunächst einmal kannst Du (wenn Du die Zielverzeich-
nisse selbst kontrollierst) beliebig viel Apaches
nebeneinander installieren.
Du kannst sie sogar nebeneinander und simultan be-
treiben - vorausgesetzt, die Apaches lauschen nicht
auf denselben Port derselben TCP/IP-Adresse. Du kannst
also einen neuen Apache irgendwohin installieren,
in dessen "httpd.conf" den Wert der Direktive "Port"
anpassen (z. B. von 80 auf 81) und dann diesen Apache
starten. Der darf auch dieselben Dokumente ausliefern!
Ich selbst besitze üblicherweise eine anwendungs-
spezifisch umgeschriebene httpd.conf, welche ich aber
nicht in dieser Datei selbst speichere, sondern in
einer Datei außerhalb des Apache-Verzeichnisses.
Die httpd.conf des Apache-conf-Verzeichnisses enthält
nur noch zwei Zeilen:
a) eine "Port"-Direktive und
b) eine include-Anweisung auf die eigentliche Apache-
Konfiguration.
Auf diese Weise kann ich dieselbe Apache-Konfiguration
gleichzeitig in zwei parallel laufenden Apaches ver-
wenden - ich muß bloß im Browser hinter dem DNS-Namen
mit ":81" etc. den Port des neuen Apache angeben.
Auf diese Weise kann ich im laufenden Betrieb einen
neuen Apache in aller Ruhe mit realen Seiten durch-
testen ... und wenn ich zufrieden bin, ändere ich
die Port-Angabe in beiden httpd.conf, stoppe und
starte beide Apaches und habe nun den neuen Apache
auf Port 80 aktiv und den alten auf Port 81 als
"Reserve" (falls doch irgendwas nicht funktioniert).
Und ich kann auch jederzeit in wenigen Sekunden auf
die alte Version zurück ... niemand zwingt mich dazu,
diese überhaupt jemals zu löschen ... und ich muß
auch nicht für mehrere Apaches die Konfiguration mehr-
fach pflegen, weil die eben nicht innerhalb der Apache-
Installation steht.
Mit derselben Methode kann ich auch neue Module fest
einkompilieren, durchtesten und irgendwann den Apache
austauschen ... ich brauche kein mod_so.
Viele Grüße
Michael