Chris' Blog

* Apache2 has detected a syntax error in your configuration files: 
/usr/sbin/apache2: error while loading shared libraries: libexpat.so.0: 
cannot open shared object file: No such file or directory

Nach dem Upgrade von pam 0.78 auf 0.99 bekam ich beim Apache Neustart obige Fehlermeldung angezeigt.
Ein
revdep-rebuild -X --library libexpat.so.0
brachte leider keinen Erfolg, daher wollte ich ein komplettes revdep-rebuild durchführen.
Dadurch sollten „apache-2.0.58“ und „apr-util-0.9.12“ neu kompiliert werden, was leider an einer Fehlermeldung von „apr-util“
scheiterte.
Aus diesem Grund kompilierte ich „apr-util“ samt Abhängigkeiten neu:
emerge -eavD apr-util
Dadurch erfuhr ich, dass man den Apache neu kompilieren soll wenn man eine Fehlermeldung wie folgende angezeigt bekommt:

/usr/share/apr-1/build-1/libtool: No such file or directory

Gesagt getan:
emerge -avD =apache-2.0.58-r2
„apr-util“ wurde dabei aktualisiert.

Glücklicherweise ließ sich der Apache jetzt wieder problemlos starten. 😀

PAM adding faulty module: /lib64/security/pam_unix.so 
PAM unable to dlopen(/lib64/security/pam_limits.so) 
PAM [dlerror: /lib64/security/pam_limits.so: symbol pam_syslog, 
version LIBPAM_EXTENSION_1.0 not defined in file libpam.so.0 
with link time reference]

Fehler trat auf nach einem PAM upgrade von Version 0.78 auf 0.99
Aufmerksam wurde ich erst nachdem meine Crons mysteriöser Weise nicht mehr funktionierten 🙂
Wer lesen kann ist klar im Vorteil:
http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml

Important: After upgrading PAM, from any version to any version, you have to restart those services that are using it to avoid internal ABI mismatches. This includes sshd, vixie-cron (and probably any other cron service), mail servers, and in general almost every service that accepts users.

Habe daraufhin der einfachheit halber den Server neugestartet, doch daraufhin trat schon der nächste Fehler auf:

* Apache2 has detected a syntax error in your configuration files: 
/usr/sbin/apache2: error while loading shared libraries: libexpat.so.0: 
cannot open shared object file: No such file or directory

Aber dazu mehr im nächsten Artikel.

checking path to cracklib dictionary... configure: error: none found 

!!! Please attach the following file when filing a report to bugs.gentoo.org: 
!!! /var/tmp/portage/sys-libs/pam-0.78-r5/work/Linux-PAM-0.78/config.log 
 * 
 * ERROR: sys-libs/pam-0.78-r5 failed. 
 * Call stack: 
 *   ebuild.sh, line 1654:   Called dyn_compile 
 *   ebuild.sh, line 990:   Called qa_call 'src_compile' 
 *   ebuild.sh, line 44:   Called src_compile 
 *   pam-0.78-r5.ebuild, line 238:   Called econf '--enable-static-libpam' '
--enable-fakeroot=/var/tmp/portage/sys-libs/pam-0.78-r5/image/' '
--libdir=/lib' '--enable-isadir=../../lib/security' 
 *   ebuild.sh, line 591:   Called die 
 * 
 * econf failed 
 * If you need support, post the topmost build error, 
and the call stack if relevant. 
 * A complete build log is located at 
'/var/tmp/portage/sys-libs/pam-0.78-r5/temp/build.log'. 
 *

Lösung in dem Fall:
cracklib neu kompilieren

Abhilfe:

cp /usr/share/zoneinfo/Europe/Vienna /etc/localtime

… getaddrinfo failed: Name or service not known in

Ein Fehler der mir kürzlich Kopfzerbrechen bereitet hatte. Im Grunde ist die Lösung simpel. Meine /etc/resolv.conf hatte sich geändert und der Apache bekommt diese Änderung scheinbar nicht mit. Peinlich aber wahr, Apache neustart hilft 🙂

Lange habe ich nach einem einfachen Weg gesucht den Motherboard-Hersteller meiner Mietserver zu eruieren und bin dabei auf „sys-apps/dmidecode“ gestoßen. Dmidecode gibt Hardwareinformationen aus die im Bios beschrieben sind, typischerweise Hersteller, Produktbezeichnung, Seriennummer, Biosversion usw.

Installiert:

# emerge -av dmidecode

Ausgeführt:

# dmidecode

Der für mich interessante Teil der Ausgabe:

Base Board Information 
        Manufacturer: 
        Product Name: ALiveNF6G-DVI 
        Version: 
        Serial Number: 
        Asset Tag: 
        Features: 
                Board is a hosting board 
                Board is replaceable 
        Location In Chassis: 
        Chassis Handle: 0x0003 
        Type: Motherboard 
        Contained Object Handles: 0

Über den Hersteller kann man jetzt streiten 😆

Geotargeting dient dazu die Herkunft einer IP Adresse zu ermitteln. In meinem Fall erhoffe ich mir Forenanmeldungen die nur zu Spamzwecken durchgeführt werden einzudämmen, indem ich regelmässig die Herkunft der Anmeldungen analysiere.

1) Gentoo Paket geoip installieren:

emerge -av geoip

2) PHP extension geoip herunterladen:

wget http://pecl.php.net/get/geoip-0.2.0.tgz

3) Um diese zu installieren wird PEAR benötigt:

emerge -av PEAR-PEAR

4) geoip extension installieren:

pecl install geoip-0.2.0.tgz

5) php.ini öffnen und folgendes in der Section „; Dynamic Extensions ;“ hinzufügen um extension zu laden:

nano /etc/php/apache2-php4/php.ini 
extension=geoip.so

6) Apache neu laden

/etc/init.d/apache2 reload

Kleines Beispiel:

Am 26.Mai wurde empfohlen PHP auf die aktuelle Version upzudaten, hauptsächlich wegen der Gefahr von „buffer und integer overflows“.

PHP 5: 
emerge --sync 
emerge --ask --oneshot --verbose ">=dev-lang/php-5.2.2"  

PHP 4: 
emerge --sync 
emerge --ask --oneshot --verbose ">=dev-lang/php-4.4.7"

Wer den eaccelerator benutzt sollte neu kompilieren nicht vergessen. In meinem Fall:

emerge -av dev-php4/eaccelerator

Suhosin bedeutet soviel wie Schutzengel und soll den Server vor bekannten und unbekannten Fehler in PHP Anwendungen schützen.

Mein Problem:
ALERT - configured POST variable limit exceeded - dropped variable 'private_auth_edit[40]'
Produziert durch die phpBB Foren taucht diese Meldung ständig in den Logs auf. Naheliegend war für mich den Wert der „suhosin.post.max_vars“ in der suhosin.ini zu erhöhen, doch auch astronomische Werte brachten keinen Erfolg.

Nach längerer Recherche dann die Lösung:

[suhosin] 
suhosin.post.max_vars = 2000 
suhosin.request.max_vars = 1000

Diese Zeilen in die php.ini kopiert und der Spuk war vorbei.

Für Kernel 2.6

Vorher (Raid 1):

hdparm -tT /dev/sda 
/dev/sda: 
Timing cached reads: 2384 MB in 2.00 seconds = 1192.22 MB/sec 
Timing buffered disk reads: 182 MB in 3.10 seconds = 58.76 MB/sec

Nachher (Raid 1):

hdparm -tT /dev/sda 
/dev/sda: 
Timing cached reads: 2174 MB in 2.00 seconds = 1086.86 MB/sec 
Timing buffered disk reads: 284 MB in 3.01 seconds = 94.35 MB/sec

Vorher (Raid 10):

hdparm -tT /dev/sda 
/dev/sda: 
Timing cached reads: 2366 MB in 2.00 seconds = 1183.86 MB/sec 
Timing buffered disk reads: 182 MB in 3.19 seconds = 57.01 MB/sec

Nachher (Raid 10):

hdparm -tT /dev/sda 
/dev/sda: 
Timing cached reads: 2278 MB in 2.00 seconds = 1139.75 MB/sec 
Timing buffered disk reads: 428 MB in 3.04 seconds = 140.99 MB/sec

Erreichen läßt sich das ganze durch den „read-ahead cache“.
Folgendes Kommando ändert den Wert:
blockdev --setra 16384 /dev/sda

16384 kann laut 3ware je nach System variieren, hat sich bei mir jedoch als Optimum herausgestellt.

Um dauerhaft in den Genuss dieser Einstellung zu kommen einfach obige Zeile zur /etc/conf.d/local.start hinzufügen.
Nachzulesen im Original in der Knowledgebase von 3ware unter der Frage „Q11050“