angenommen... ich würde apache und php updaten wollen

[itti]

gerade hab ich ne höllentour hinter mir. hab mir vom "chef" ein zeitfenster von 1 stunde einrichten lassen um den webserver mal down zu nehmen weil ich auf apache 2.0.53 updaten wollte. daraus resultierend natürlich auch gleich ein php update auf 4.10. tja daraus wurd natürlich nix.

system ist ein suse 9.1 auf nem 1&1.

ich hab mir die aktuellen pakete vom suse ftp unter http://ftp.suse.com/pub/projects/apache ... /9.1-i386/
bzw.
http://ftp.suse.com/pub/projects/apache/php4/9.1-i386/

gezogen. beim apache gabs auch keine probleme laut rpm, lediglich php wollte sowas von garnicht. die einzelnen pakete unter sich waren schon sehr inkompatibel. ich hab die genaue meldung jetzt nicht mehr parat aber ich glaub es waren dependency konflikte von php4-recode und php4-imap. ich weiß nicht warum, denn beide waren in alten versionen parallel installiert ohne probleme. das neue apache2-mod_auth_mysql vom vorherigen schritt wurde auch noch angemeckert usw...

naja ich hab dann viel hin und her installiert, haupsächlich mit der yast2 oberfläche. die genaue reihenfolge kenne ich nicht mehr. aus zeitdruck dacht ich mir "was solls" und hah die kompletten php4 pakete alle mit --nodeps draufgeklatscht und dann wars vorbei. nix ging mehr. apache2 ist beim start sofort in segfault gelaufen und der php-parser konnte auch ungefähr 10-20 shared objects nicht einbinden.

danach hab ich ungefähr eine stunde damit zugebracht yast2 dazu zu bewegen das zeug wieder zu deinstallieren. abwechselnd hab ichs auch mit rpm -e versucht, aber irgendwie kommt sich das auch wieder in die quere.

ich weiß nicht wie ich es dann geschafft habe aber jetzt bin ich wieder auf aktuellem stand mit den offiziellen paketen von suse. sprich apache 2.0.49 und php 4.3.4.

das soll so natürlich nicht bleiben. ich hätte jetzt nur gern jemand der mir unter die arme greift und mir sagt wo ich wirklich verlässliche und kompatible rpm pakete für php und apache bekomme. ich würds ja gern selbst kompilieren, da is das ergebnis nur auch nicht so prima. die softwareinstallation von yast2 nervt dann nämlich unbereinigbar mit "muss neu installiert werden" und ich schaffe es auch nicht vorher php4 komplett weg zu bekommen. damit hat suse wohl entweder nicht gerechnet oder die rpm datenbank ist nach all dem hin und her irgendwie leicht beschädigt.

naja ich hoffe auf konstruktive antworten. eigentlich hab ich mich ja schon an die hilfestellungen hier gehalten bzw. die faqs gelesen aber so recht geklappt hats halt noch nicht.

[itti]

ok war wohl etwas wirr geschrieben (nach dem marathon da...)

ganz simple frage, für die ich aber keine antwort finden konnte. ich habe suse 9.1 im einsatz und möchte jetzt (möglichst mit dritt-rpms) gleichzeitig auf apache 2.0.53 und php 4.10 updaten. wo bekomme ich die rpms und passen diese auch zusammen?

[Joe User]

3rd-Party verwendet man grundsätzlich nur dann, wenn weder der Distributor/Maintainer, noch man selbst die gewünschte Version/das gewünschte Feature bereitstellt.

Was stört Dich also genau an den (in)offiziellen SuSE-Paketen?
http://ftp.gwdg.de/pub/linux/suse/ftp.s ... /9.1-i386/
http://ftp.gwdg.de/pub/linux/suse/ftp.s ... /9.1-i386/

[itti]

als ich diese pakete für ein update verwenden wollte sind segfaults beim apache aufgetreten und php konnte seine sämtlichen shard objects nicht finden. ausserdem konfliktieren die rpm pakete von php schon rein untereinander (nicht mit installierten paketen).

[Joe User]

Probiere es bitte nochmals mit den neuen RPMs und halte dabei Dein Vorgehen step-by-step (inklusive eventueller Fehlermeldungen) fest. Alternativ kannst Du auch Apache/PHP selbst kompilieren...

[itti]

ja das werde ich wohl demnächst tun. muss nur den chef nochmal dazu überreden ein zeitfenster zu bekommen. nach der letzten aktion sicherlich nicht so einfach.

-edit:

ich hab mal testweise alle php pakete bezogen und so stellt sich das jetzt erstmal da:

Code: Select all

 rpm -Uvh --test *rpm
warning: apache-mod_php4-4.3.10-10.1.i586.rpm: V3 DSA signature: NOKEY, key ID efb694ea
error: Failed dependencies:
        apache_mmn_19990320_15 is needed by apache-mod_php4-4.3.10-10.1
        php4-recode conflicts with php4-imap-4.3.10-10.1
        php4-recode conflicts with php4-mysql-4.3.10-10.1
        php4-imap conflicts with php4-recode-4.3.10-10.1
        php4-mysql conflicts with php4-recode-4.3.10-10.1
        apache2-mod_auth_mysql conflicts with php4-recode-4.3.10-10.1

die fehlende abhängigkeit kann ich sicherlich auflösen wenn ich entsprechendes paket noch nachinstalliere. dass aber -recode und -imap zum beispiel miteinander konfliktieren ist mir ein rätsel, da bereits beide pakete in den alten versionen bestens miteinander klarkommen. wahrscheinlich werde ich also auf php-recode verzichten müssen.

[Joe User]

Apache 1.3.33 -> apache-mod_php4-4.3.10-10.1.i586.rpm
Apache 2.0.53 -> apache2-mod_php4-4.3.10-10.1.i586.rpm

- reverted dlopen flag back to RTLD_GLOBAL (bugs #39197 and
#41866), php4-recode now conflicts with php4-imap, php4-mysql and
apache2-mod_auth_mysql, mod_php4-core does not require
php4-recode any more

[beff]

Hallo.

Ich habe auch einen 1&1 Rootserver mit SuSE 9.1, Apache 2.0.49 und PHP 4.3.4. Ich bin vor dem selben Problem gestanden wie du, aber da schon einen Schritt weitergekommen (zumindest PHP ist nun neu).

Das updaten der PHP-Dateien funktioniert, wenn zuerst via php-recode deinstalliert wird (rpm -e). Dann kann man problemlos das PHP-Update fahren (dabei aber bitte die PHP-Recode-RPM nicht mit verwenden ;)).

Beim Apachen sieht das leider ganz ganz anders aus. Ein Problem ist, dass die Konfiguration des 1&1er-Rooties nicht mit der einer normalen 9.1er Installation übereinstimmt. Vor allem der Pfad zu den HTTP-Dokumenten ist falsch (1&1: /home/htdocs, Standard: /srv/irgendwas-weiß-nicht-mehr *g*). Wenn man mit einem Standard-RPM ein Update fährt, findet der Apache zwar alle Dokumente (Pfade stehen in der httpd.conf), aber CGI oder Frontpage funktionieren nicht. Grund: In die dafür zuständige Datei suexec2 wurde der falsche Pfad fest hineinkompiliert. Das selbe Problem hat man übrigens auch bei 8.1er Root-Servern von 1&1.

Man wird also wahrscheinlich nicht daran vorbeikommen, den Apachen selber zu kompilieren. Dies kann man entweder via configure + make + make install und noch einigen weiteren Spagaten machen. Manche Linux-Gurus finden sowas sexy, ich hingegen find's einfach nur krank :p.

Schöner sind da schon die RPMs, denn die kann man auch selber bauen. Man zieht sich eine SRC.RPM-Datei von SuSE und "installiert" dieses ganz normal mit rpm -i. Anschließend geht man ins Verzeichnis /usr/src/packages/SPECS. Dort ist eine Datei namens apache2.SPEC, die im Grunde alle Konfigurations- und Compilerdinge enthält. Wir müssen diese (fast) fix und fertige "Bauanleitung" nur noch anpassen.


Doch was genau hat 1&1 gegenüber der Standard-SuSE-Distribution geändert? Eine Antwort dafür finden wir via w3m update.pureserver.info. Dort unter /local-updates/9.1/ gibt es mehrere Apache-Verzeichnisse (mit alten Versionen) in denen DIFF-Dateien über die Veränderungen an den SPECS Auskunft geben. Leider gehen diese etwas auseinander, und ich hab deshalb die einfachste genommen (Unterversion 23, hier war nur der with-suexec-docroot anzupassen).

Ok, SPEC angepasst, und dann via rpmbuild -ba apache2.SPEC (evtl. müssen per YaST einige Pakete nachinstalliert werden, man sieht diese dann gleich am Anfang in einer Fehlermeldung) angefangen zu backen. Das ganze köchelt eine Zeit lang vor sich hin, bis alles komplett kompiliert ist. Am Ende hat man jedenfalls fertige RPMs im Ordner /usr/src/packages/RPM, die man dann mittels rpm -Uvh einspielen kann.

Tjoa... leider fehlt dieser Geschichte das Happy End. Denn der neue Apache liefert keine Seiten aus. Seine Kindprozesse sterben an einem segmentation fault (11), wie aus der error_log zu ersehen ist.

Vielleicht sind die SPECS doch noch weiter anzupassen. In den anderen Unterversionen, die man auf update.pureserver.info finden kann, sind umfangreichere DIFFS zu finden. Oder der Fehler liegt irgendwo anders.

Vielleicht weiß jemand hier im Forum eine Antwort. Zum wild ausprobieren fehlt mir im Moment leider die Zeit :/.

[itti]

hey danke. das war mal ne ausführliche antwort die mir wirklich schon weitergeholfen hat. als freebsd user bin ich eigentlich ner selbstkompilierung ja nicht abgeneigt, mir fehlt halt eher das wissen um rpm und die suse gepflogenheiten diesbezüglich.

nehmen wir mal an ich würde apache mit entsprechendem configure kompiliert bekommen, müsst ich dann nicht auch php selbst kompilieren, weils ja ein von apache abhängiges modul ist? das wäre das kleinste problem, das hab ich vor einiger zeit schon mal gemacht. lediglich yast2 reagiert immer böse auf sowas aber man kann ja nicht alles haben.

[beff]

Du, mir fällt grad ein, dass ich gelogen habe *gg*. Das ganze ist schon ein paar Wochen her, und mir ist eben eingefallen, dass sich PHP immer noch nicht per RPM updaten ließ (warum weiß ich nicht mehr). Ich hab dann doch PHP komplett selber kompiliert, und zwar nach folgender Anleitung:

http://www.netsecond.net/howto/index.ph ... artlang=de

Die configure-Schalter stimmten übrigens mit den bei mir verwendeten überein (bei PHP kann man die ja über phpinfo() sehen), das HowTo passt also maßgeschneidert (abgesehen von der höheren PHP-Version, aber das is ja kein Problem *g*).

Ich glaube, die RPM-Geschichte kann man also wirklich vergessen. Ich meine auch in anderen Foren gelesen zu haben, dass SuSE 9.1 in dieser Hinsicht wirklich besch...eiden ist (oder zumindest die Version von 1&1). Ich habe vorher mit einem 8.1er-Rootie gearbeitet, da war die Sache mit RPMs ein Klacks.

So wie's aussieht, muss man also auch den Apache-Webserver von Hand kompilieren. Ich hab das auch mal probiert, aber auch da hatte ich Segmentation Faults. und man hat leider auch keinen rechten Anhaltspunkt, wie man dem Fehler auf die Schliche kommt. Vielleicht hat hier in diesem Forum ja jemand bessere Erfahrungen gemacht, und mag diese mit uns teilen :).

[gleitz]

Die wirklich einfachste Methode ist das selbstkompilen vom Apache2 und die Downzeit lässt sich Problemlos auf unter großzügige 5 min. drücken.

Es ist einfach unumgänglich einen Testrechner zu hause / im Betrieb zu haben mit der selben Suse Version, wo man zumindestens die Softwareinstallation nachstellt und testet. Alles andere ist fahrlässig.

Im ersten Schritt holst du dir die apache2_trallala.src.rpm vom Suse FTP und öffnest diese in MidnightCommander (kurz mc) und kopierst dir daraus die Spec Datei, die du dir in Ruhe in einem Editor betrachtest. Dort steht der gesamte configure-Aufruf, wie Susi-Sorglos seinen Indianer erstellt.
Dabei wirst du entdecken das unnötig viele Module mit erzeugt werden die du gar nicht brauchst. -> Raus werfen! Welche du wirklich brauchst, erfährst du am einfachsten in der aktuellen httpd.conf vom produktiven Server.
Ich persönliche liebe die Datei config.layout vom Apache2. Schnappe dir die Datei und suche dort das Suse6.x Layout, das weitestgehend dem aktuellen entsprechen wird, passe einige Pfade an und nenne das Layout auf "MeinServer" um.

Jetzt hast du eigentlich genug Infos zusammen und alle Vorbereitungen für deinen ./configure Aufruf, der etwa wie folgt aussehen müsste.

./configure --enable-layout=MeinServer --with-mpm=prefork (oder worker) + die Aufrufe für die Module die mit installiert werden sollen.

Anschließend make, aber nicht make install. Jetzt kommt der Zeitpunkt wo du auf deinem Testrechner die gesammte Apache Configuation sicherst, den beim deinstallieren werden Teile davon gelöscht. Notiere dir auch genau die Einträge im Verzeichtnis /etc/init.d/* für den Indianer.
Deinstalliere auf deinem Testsystem lückenlos den RPM Indianer + die alte Configure Dateien (bis auf die gesicherte ) und anschließend mit make install die Installation abschließen. Die neue httpd.conf anpassen. Was alles geändert werden muss, sieht man ja in der gesicherten conf.

Apache2 starten und freuen :-D
Erstelle sym. Link von der apachectl nach /etc/init.d/*, damit der Indianer beim herunterfahren und Starten auch sauber beendet und gestartet wird. Fertig!

---------

Mit php gehst du genauso vor. php-trallala.src.rpm holen, Spec Datei daraus ziehen, überprüfen was man wirklich braucht, die richtigen Pfade ermitteln, da es keine Layout Datei gibt und die Pfadangaben mit Variablen besetzt sind, die vom Susi-System vorgegeben werden.

Configure Aufruf starten und warten wo es knallt, da garantiert irgendein dev-Paket fehlt. Fehlermeldung beim Abbruch studieren und daraus (mittels Google) das fehlende Paket ermitteln und nachinstallieren, bis Configure sauber durchläuft. Anschließend make && make install -> *freu*

----------

Umstellung produktiven Server!
Du kennst jetzt alle Pakete die installiert und gelöscht werden müssen. Was an RPM installiert werden muss, kann man schon mal im Vorfeld erledigen. Kopiere die Ordner, in dem du die Binaries gebaut hast, auf den Server und die neue httpd.conf für den Indianer.

So, und jetzt kann alles ganz schnell gehen. Alte Installation löschen (was weis man ja vom Testrechner noch). Für die Binaries nur noch make install ausführen, die httpd.conf dahin kopieren wo diese hingehört und den Indianer starten.
Abschließend noch die sym. Link erstellen für das Starten und Stoppen vom Indianer beim hoch und unter fahren vom System.

--------------

Das nächste Update kommt bestimmt und das wird dann ein Kinderspiel.
Du kopierst einfach die Datei config.nice bzw. config.layout in das Sourceverzeichnis der neuen Version und führst ./config.nice -> make -> Apache stop -> make install -> Apache starten aus.

PS: Keine Gewähr für Vollständigkeit und Fehlerfreiheit!
PPS: Und selber RPM basteln macht nur Sinn, wenn man in der Lage ist seine Programme selber zu kompielen aus den Sourcen und mehrere Server mit identischem System hat.

[beff]

Das Problem an der Sache:

1&1 hat eine angepasste SuSE 9.1, die von der Standardistribution in einigen kritischen Punkten abweicht. Und über die genauen Ã?nderungen und Anpassungen ist leider nix bis wenig zu erfahren. Deshalb is das leicht gesagt mit dem Testsystem daheim - ansonsten wäre das mit dem Apache bauen auch nicht so das Problem (man könnte dann ja die Standard-RPMs nehmen und gut ;)). Und ob ich nun die SPEC mittels MC raushole (hab ich auch schon gemacht) oder über rpm ins Verzeichnis /usr/src/... kopiere, kommt letztlich aufs selbe raus ;).

Aber gut, dein Ansatz ist ein anderer, und ich werde ihn mal ausprobieren. Da mein Server im Moment nicht in Produktiv-Betrieb ist, kann ich am helllichten Tag dran rumbasteln. Darum vielen Dank für den Tipp :). Ich melde mich wieder.

[gleitz]

Die von 1&1 nehmen nicht das Standardverzeichnis von SuSE /srv/www/htdocs/..., sondern ein anderes. Na und?

Das passe ich ganz bequem in meiner config.layout Datei an und ändere entsprechend die Zeilen für suexec ab. :-D

--enable-suexec
--with-suexec-bin=/usr/sbin/suexec
--with-suexec-caller=wwwrun"
--with-suexec-docroot=/srv/www/htdocs
--with-suexec-logfile=/var/log/apache2/suexec.log
--with-suexec-userdir=public_html
--with-suexec-uidmin=96
--with-suexec-gidmin=96
--with-suexec-safepath=/usr/local/bin:/usr/bin:/bin

<Layout MeinServer>
prefix: /usr
exec_prefix: ${prefix}
bindir: ${prefix}/bin
sbindir: ${prefix}/sbin
libdir: ${prefix}/lib
libexecdir: ${prefix}/lib/apache2
mandir: ${prefix}/share/man
sysconfdir: /etc/apache2
datadir: /srv/www
installbuilddir: ${prefix}/share/apache2/build
errordir: ${prefix}/share/apache2/error
iconsdir: ${prefix}/share/apache2/icons
htdocsdir: ${datadir}/htdocs
manualdir: ${prefix}/share/apache2/manual
cgidir: ${datadir}/cgi-bin
includedir: ${prefix}/include/apache2
localstatedir: /var/lib/apache2
runtimedir: /var/run
logfiledir: /var/log/apache2
proxycachedir: /var/cache/apache2
</Layout>

--------------

Du kannst sogar noch einen Schritt weiter gehen und dir den Apache2 in ein seperates Verzeichnis hinein installieren und umstellen das er auf einem anderen Port lauscht und somit parallel installieren und betreiben.
Funktioniert alles wie gewünscht, den alten Indianer stoppen und den neuen ins Rennen schicken. Damit drücke ich die Downtime sogar auf einige Sekunden herunter.

Und weil wir schon mal bei der Layout Datei sind, das Apache Layout ist klasse geeignet, um dem SuSE Apache nicht in die Quere zu kommen. 8)

[beff]

Soweit war ich im Grunde auch schon, beim anpassen der SPEC-Datei. Vielleicht lag der Fehler aber auch woanders (z.B. an mir, man ist ja nur menschlich ;)). Ich werd mich frisch gestärkt nochmal ans Werk machen. Jedenfalls nochmals danke für die ausführliche Hilfe :).

[beff]

Tja, was soll man sagen. Das Problem lag wo ganz anders. Ich hab mir heute nachmittag wirklich die Nerven wegkompiliert, und trotzdem ging nix mehr. Am Ende hab ich den Server neu aufsetzen lassen (es kost ja zum Glück nix mehr, und ist automatisiert nach höchstens ner Stunde erledigt).

Dann bin ich nochmal frisch ans Werk gegangen. PHP konnte ich doch noch via RPM updaten, in dem ich (wie bereits gesagt) php4-recode rausgeschmissen hab, und außerdem noch php4-unixODBC und mod_php4-core weggelassen hab (letzteres war von ersterem abhängig, und ist außerdem eh bald überholt, also beide weg). Dann ging das neue PHP problemlos (zuvor gab es schon hier Segmentation Faults - ich musste zu den beiden eben genannten noch unixODBC und unixODBC-devel installieren, evtl. hats wegen diesen Paketen gebockt).

Ok, dann hab ich mich nochmal an das 2.0.53er RPM des Apachen gewagt. Die alte suexec2 wurde gesichert (wegen dem einkompilierten Pfad) und kommt später wieder rein (nicht ganz sauber, aber es funzt). Dann also per RPM geupdatet und wieder SegFaults kassiert. Nun hab ich mal testweise in der Datei /etc/sysconfig/apache2 das Modul frontpage rausgeschmissen und SuSEconfig laufen lassen. Apache neu gestartet und TATAAAAAAA. Es funktioniert!!!!

Der ganze Ã?rger also nur wegen Microsoft, war ja klar ;). Zum Glück brauch ich Frontpage nicht, ansonsten müsste man mal bei Confixx nach nem Patch kucken (ich meine mich dunkel zu erinnern, in den tausenden Apache2-Threads hier mal was davon gelesen zu haben).

Nochmals danke für die Hilfe, auch wenn es hier leider nicht half ;).

[beff]

Nachtrag: Jetzt funktioniert selbstverständlich auch das bauen eines eigenen RPMs samt dessen Installation und Betrieb problemlos. Wie sagt Herbert Grönemeyer so schön: Lache, wenn's nicht zum weinen reicht :).

[itti]

sehr gut. kannst du mir dann die so abgeänderte spec datei posten?

kompiliert hast du aus dem source rpm von suse?

[beff]

Jup, ich hab das Source-RPM von SuSE genommen (oder von irgendnem Mirror).

In der SPEC-Datei hab ich nur eine einzige Zeile geändert (gemäß der "Bauanleitung" update.pureserver.info/local-updates/suse-9.1/apache2-2.0.49-23/apache2.spec.diff).

ALT:

--with-suexec-docroot=%{htdocsdir}

NEU:

--with-suexec-docroot="/home/htdocs"

Damit passt dann suexec und CGI funktioniert, wie es soll.


Die restlichen serverspezifischen Konfigurationseinstellungen stehen allesamt in der httpd.conf (bzw. den includeten Dateien), insofern muss man nix mehr am RPM basteln.

Und nicht vergessen, Frontpage rauszuwerfen. Damit das ginge, bräuchte man wohl nen Patch ;).

[itti]

sehr sehr gut.

was sagt eigentlich yast2 dazu? php hast du von den offziellen rpms oder selbst kompiliert? ich will endlich wieder ein funktionierendes yast2 rpm-interface, ohne dass andauernd meine pakete überschrieben werden oder gar schlimmeres. ich kann nämlich nicht sicherstellen dass niemand yast2 verwendet. die serveradministration teilen sich nämlich momentan 2 leute, um im notfall greifbar zu sein.

-edit: vergiss meine frage. die datenbank von yast2 ist nun endgültig tot :(
das online update will mir andauernd die selben pakete anbieten und die softwareinstallation kommt dann nichtmehr damit klar. ich werd wohl in zukunft einfach darauf verzichten.

[beff]

Ich werd die Frage trotzdem gern beantworten. Vielleicht sucht ja irgendwann wer danach ;).

Die PHP-RPMs habe ich von einem SuSE-Mirror (ebenso wie auch das Apache-SRC.RPM).

YaST2 zeigt die korrekten Versionen an: PHP 4.3.10 + Apache 2.0.53. Das ist auch mir sehr wichtig, denn ein Paketmanager erleichtert es, den Ã?berblick zu bewahren ;).

[itti]

oh mann... wem soll ich ein bier spendieren?

ich hätte mir ja evtl. apache selbst kompiliert, das wäre ja noch nachvollziehbar. aber dass man frontpage rausnehmen muss damit alles geht, darauf wär ich nie gekommen.

aber nun funktioniert alles :-D

ich bin glücklich. vielen vielen dank.

[trenied]

Lassen sich Apache, PHP und MySQL nicht mit dem Online Update Tool von yast 2 updaten? Ich denke da vor allem an die ganzen Exploits für Apache. Oder ist es nach dem Update durch yast so, dass eine neue httpd.conf installiert wird und die "alte" bzw. die confixx_vhost.conf nicht mehr existiertieren? Wir haben einen Root Server von 1und1 und würden von daher gerne mal ein Update machen. Schön wäre natürlich auch, wenn in diesem Zuge auch gleich PHP auf stand gebracht werden könnte. Bei uns läuft PHP 4.3.3 und Apache 2.0.48

[beff]

Das Problem ist, dass das Update-Tool nur Apache 2.0.49 und PHP 4.3.4 kennt. Deshalb muss man sich selber neuere RPMs besorgen bzw. backen.

Ach ja: PHP 4.3.3 würde ich DRINGEND updaten. Es sind ein paar böse Lücken drin, und es gibt Programme, die automatisch Webseiten nach diesen Lücken durchsuchen und verunstalten. PHP 4.3.10 ist Pflicht ;).

[t0x1c]

Vielleicht sind die Versionen aus dem Update-Tool gepatcht?

Btw.
*emerge -u apache2 streichel* ;)

SCNR

[Joe User]

Google: apt4rpm