Apache 1.3.34_4 und PHP 4.4.2_1 installieren

testit

Well-Known Member
Hallo allerseits,

nach einem Stromausfall bei einem Provider, von dem mein Rootserver betroffen war, funktionieren bei mir diverse Proramme auf dem Webserver nicht mehr richtig. Ein fsck ist inzwischen durchgelaufen, aber diverse Fehler sind immer noch vorhanden.

Ich habe mich daher entschlossen, meinen Apache apache+mod_ssl-1.3.33+2.8.22_1 und die bestehende PHP4 inkl. einigen Extensions zu deinstallieren, um apache 1.3.34 sowie PHP 4.4.2_1 nebst diversen Extensions zu installieren.

Leider klappt das nicht so, wie ich mir das vorgestellt habe. Habe mit pkg_deinstall den alten apache und PHP deinstalliert.

Als ich nun den Apache und PHP4 mittels pkg_add installieren wollte, erschienen folgende Fehler:

Code:
pkg_add -r ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/All/php4-4.4.2_1.tbz
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/All/php4-4.4.2_1.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6-stable/All/apache-1.3.34_4.tbz... Done.
pkg_add: warning: package 'apache-1.3.34_4' requires 'perl-5.8.8', but 'perl-5.8.6_2' is installed
pkg_add: warning: package 'apache-1.3.34_4' requires 'expat-2.0.0_1', but 'expat-1.95.8_3' is installed

===>  COMPATIBILITY NOTE:
      As of version 1.3.24, the RedirectMatch directive requires an
      absolute URL target location per RFC 2068. Uses of RedirectMatch that
      specify a relative URL will fail and must be corrected to function.

===>  BE CAREFULL HOW TO BOOT on 1.3.29_4 or after:
        To run apache www server from startup, add apache_enable="YES"
        in your /etc/rc.conf.

/libexec/ld-elf.so.1: Shared object "libcrypt.so.3" not found, required by "httpd"
apxs:Error: Sorry, no DSO support for Apache available
apxs:Error: under your platform. Make sure the Apache
apxs:Error: module mod_so is compiled into your server
apxs:Error: binary `/usr/local/sbin/httpd'.
pkg_add: command '/usr/local/sbin/apxs -e -a -n php4 libphp4.so' failed
pkg_add: warning: package 'php4-4.4.2_1' requires 'perl-5.8.8', but 'perl-5.8.6_2' is installed
pkg_add: warning: package 'php4-4.4.2_1' requires 'expat-2.0.0_1', but 'expat-1.95.8_3' is installed
Aber offensichtlich ist apache 1.3.4 und PHP 4.4.2_1 trotzdem installiert worden.
Ist es schädlich, den FTP-Pfad zu /packages-6 zu nehmen, obwohl ich 5.4 habe? Unter 5.4 packages konnte ich nämlich PHP 4.4.2_1 nicht finden!

Anschliessend wollte ich für PHP4 einige Extensions installieren:

Code:
cd /usr/ports/lang/php4-extensions
make config

Habe dann die entsprechenden Extensions selektiert und danach make install eingegeben, wobei ich folgende Meldungen erhielt:


Code:
eco3045# make install
===>  Installing for php4-extensions-1.0
===>   php4-extensions-1.0 depends on file: /usr/local/include/php/main/php.h - found
===>   php4-extensions-1.0 depends on file: /usr/local/lib/php/20020429/bcmath.so - not found
===>    Verifying install for /usr/local/lib/php/20020429/bcmath.so in /usr/ports/math/php4-bcmath
===>  Vulnerability check disabled, database not found
===>  Extracting for php4-bcmath-4.4.2_1
=> MD5 Checksum mismatch for php-4.4.2.tar.bz2.
=> SHA256 Checksum mismatch for php-4.4.2.tar.bz2.
===>  Refetch for 1 more times files: php-4.4.2.tar.bz2 php-4.4.2.tar.bz2
===>  Vulnerability check disabled, database not found
=> php-4.4.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://br.php.net/distributions/.
fetch: http://br.php.net/distributions/php-4.4.2.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://cn.php.net/distributions/.
fetch: http://cn.php.net/distributions/php-4.4.2.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://dk.php.net/distributions/.
fetch: http://dk.php.net/distributions/php-4.4.2.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://de.php.net/distributions/.
fetch: http://de.php.net/distributions/php-4.4.2.tar.bz2: Requested Range Not Satisfiable
=> Attempting to fetch from http://es.php.net/distributions/.
===>  Vulnerability check disabled, database not found
=> MD5 Checksum mismatch for php-4.4.2.tar.bz2.
=> SHA256 Checksum mismatch for php-4.4.2.tar.bz2.
===>  Giving up on fetching files: php-4.4.2.tar.bz2 php-4.4.2.tar.bz2
Make sure the Makefile and distinfo file (/usr/ports/math/php4-bcmath/../../lang/php4/distinfo)
are up to date.  If you are absolutely sure you want to override this
check, type "make NO_CHECKSUM=yes [other args]".
*** Error code 1

Stop in /usr/ports/math/php4-bcmath.
*** Error code 1

Stop in /usr/ports/math/php4-bcmath.
*** Error code 1

Stop in /usr/ports/lang/php4-extensions.

Was läuft denn hier schief? Wieso kommt es oben zu diesem MD5 Checksum mismatch?

Ich muesste möglichst rasch die Sache wieder zum Laufen bekommen und bin daher für jede Hilfe dankbar.

Nette Grüsse
testit
 
Moin,

ein Post hätte gereicht.

Dein System ist ja beim Stromausfall mächtig durchgeschüttelt worden.

Ich hatte mal einen ähnlichen Fall bei meiner privaten WS zuhause. Beim Installieren ist eine CPU wegen defektem Kühler ausgestiegen und die Kiste hat sich ins Nirvana verabschiedet. Danach war auch die Paket-DB im A..., es lagen alle möglichen Leichen unter /usr/local.. rum.

Ich habe die Configs unter /usr/local/etc gesichert, den Rest der Pakete deinstalliert und alles unter /usr/local gelöscht. Dann alles aus den Ports neuinstalliert. Meine Configs zurückgespielt und das Teil lief wieder. An Deiner Stelle würde ich wohl auch vorher nochmal die Welt und den Kernel neubauen. Vielleicht ist da beim Crash auch etwas beschädigt worden.

Ohne Dir zu nahe treten zu wollen, aber solltest Du Dir den Betrieb bzw. die Betreuung eines wohl recht wichtigen Servers unter FreeBSD nicht nochmal gründlich überlegen?

Scheinbar hast du kein Backup, die Fehlermeldungen sind eigentlich auch klar und sollten auch für einen Nichtcrack in Sachen FreeBSD zu lösen sein.
Und vorkompilierte Pakete zu installieren, dann Erweiterungen aus den Ports zu installieren ohne ein portupgrade der bereits installierten Pakete zu machen, ist auch keine so tolle Idee.

Gruß c.
 
Last edited:
crotchmaster said:
Moin,

ein Post hätte gereicht.

Dein System ist ja beim Stromausfall mächtig durchgeschüttelt worden.

Ich hatte mal einen ähnlichen Fall bei meiner privaten WS zuhause. Beim Installieren ist eine CPU wegen defektem Kühler ausgestiegen und die Kiste hat sich ins Nirvana verabschiedet. Danach war auch die Paket-DB im A..., es lagen alle möglichen Leichen unter /usr/local.. rum.

Ich habe die Configs unter /usr/local/etc gesichert, den Rest der Pakete deinstalliert und alles unter /usr/local gelöscht. Dann alles aus den Ports neuinstalliert. Meine Configs zurückgespielt und das Teil lief wieder. An Deiner Stelle würde ich wohl auch vorher nochmal die Welt und den Kernel neubauen. Vielleicht ist da beim Crash auch etwas beschädigt worden.

Ohne Dir zu nahe treten zu wollen, aber solltest Du Dir den Betrieb bzw. die Betreuung eines wohl recht wichtigen Servers unter FreeBSD nicht nochmal gründlich überlegen?

Scheinbar hast du kein Backup, die Fehlermeldungen sind eigentlich auch klar und sollten auch für einen Nichtcrack in Sachen FreeBSD zu lösen sein.
Und vorkompilierte Pakete zu installieren, dann Erweiterungen aus den Ports zu installieren ohne ein portupgrade der bereits installierten Pakete zu machen, ist auch keine so tolle Idee.

Gruß c.

Hi,

erst einmal vielen Dank für Deine Anmerkungen!

Wieso sollte EINE Post ausreichen, wenn in dieser Post Probleme angesprochen werden, die nur in DIESEm Postin beschrieben werden? Oder gibt es hier Hellseher :-) ?

Ansonsten bin ich mit FreeBSD eigentlich ganz zufrieden, um auf Deine Frage bzgl. des Betriebs unter FreeBSD zurückzukommen ;-). Das Problem ist nur, dass ich keinen direkten Zugriff auf den Server in der Form habe, als dass ich auch eine RescueCD handeln könnte. Letztere ist allerdings i.d.R. im Zusammenhang mit Repair-Versuchen mittels fsck notwendig.

Backups liegen vor, allerdings sind diese nicht tagesaktuell.

Deinen Anmerkungen zu der ganz und gar nicht tollen Idee "vorkompilierte Pakete zu installieren, dann Erweiterungen aus den Ports zu installieren ohne ein portupgrade der bereits installierten Pakete zu machen" kann ich ehrlich gesagt nicht ganz folgen.

Das eine hat mit dem anderen überhaupt nichts zu tun. Es spricht aus meiner Sicht nichts dagegen, ein PHP4-Paket zu installieren und benötigte Extensions über den Extensions-Meta-Port, was im übrigen letztlich auch gut funktioniert hat.

Wieso sollte ich in der beschriebenen Situation ein Portupgrade der bereits installierten Pakete machen? Es gibt keinen zwingenden Grund, IMMER jede Applikation via portupgrade auf dem Laufenden zu halten, wenn man aus bestimmten Gründen GANZ BESTIMMTE Versionen einer Applikation laufen lassen möchte.

Nette Grüsse
testit
 
testit said:
Wieso sollte ich in der beschriebenen Situation ein Portupgrade der bereits installierten Pakete machen? Es gibt keinen zwingenden Grund, IMMER jede Applikation via portupgrade auf dem Laufenden zu halten, wenn man aus bestimmten Gründen GANZ BESTIMMTE Versionen einer Applikation laufen lassen möchte.

Nette Grüsse
testit
Hi,

es gibt mindestens zwei Gründe:

1. Sicherheitslücken der installierten Pakete

2. das ports-Verzeichnis passt nicht zu den installierten Paketen, was die Fehlermeldungen bei perl und expat andeuten.

Gruß c.
 
crotchmaster said:
Hi,

es gibt mindestens zwei Gründe:

1. Sicherheitslücken der installierten Pakete
Das KANN der Grund für eine neuere Version sein, MUSS aber nicht.
Abgesehen davon gibt es zahlreiche bekannte Beispiele dafür, dass neuere Versionen ältere Sicherheitslücken gefixt haben, aber gleichzeitig andere generiert haben. Sei es PHP, sei es phpBB etc.

Insofern vermag ich dieser "muss immer neuste Version"-haben Philosophie nicht viel abgewinnen. Immerhin: Micros. setzt genau sehr erfolgreich auf diesen "Ohrwurm".

2. das ports-Verzeichnis passt nicht zu den installierten Paketen, was die Fehlermeldungen bei perl und expat andeuten.
Das stimmt zwar, bedeutet aber nicht, dass ein Portupgrade automatisch die von der neu installierten Applikation geforderten Pakete (Versionen) generiert.


Nette Grüsse und Danke nochmal
testit
 
Hi,

ich gehöre auch nicht zu den jenigen, die immer das Neueste haben müssen, aber eine bekannte Sicherheitslücke sollte schon gefixt werden, wenn sie einen betrifft.
Das mag auch manchmal neue Löcher aufreißen, aber die alten und bekannten Löcher sind hoffentlich gestopft.

Das du Anwendungen fährst, die eine bestimmte Version voraussetzen, hattest bisher nicht geschrieben. Trotzdem bleibt das Problem, das deine aus den ports nachinstallierten Sachen nicht zu den binären Paketen passen. Das musst du jetzt lösen.

Außerdem muss ich nochmal auf das Backup zurückkommen. Das mag ja sein, dass diese nicht tagesaktuell sind. Das muss jeder für sich und den Einsatzzweck und die Anforderungen des Servers entscheiden. Nur mir stellt es sich so dar, das du deine Kiste jetzt nicht wiederhergestellt bekommst, und daraus folgere ich, das etwas an der Backupstrategie nicht stimmt.

Wir haben auch root-Server bei einem bekannten Massenhoster. Nachdem die Kisten rund liefen und konfiguriert waren, habe ich von den Platten gezipte Images gemacht, diese mehrfach sicher verwahrt und mache in diesen Fällen eine tägliche Sicherung mit dump. So kann ich die Daten bei Verlust Servers wieder herstellen. Nach einem Austausch der Hardware, hatte das gerade vor zwei Wochen, muss ich vorher noch das Image auf die Platten klatschen.

Also, Good Luck!

Gruß c.
 
Back
Top