Chris' Blog

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 😆

Eigentlich schreibe ich ungern sinnlose Beiträge, aber da mir mein Partner Mika ein Blog Stöckchen zugeworfen hat, werde ich wohl nicht drumrum kommen auch meinen Tagesablauf der Öffentlichkeit näher zu bringen. 🙂

Der Wecker läutet um 06:30 Uhr, nicht meiner, sondern der meiner (fast-)Gattin. Selten schaffe ich es – trotz der gleichen Zu-Bett-Geh-Zeit – gleichzeitig mit aufzustehen, aber für einen Selbstständigen sollte dies kein Problem darstellen 🙂
Vor 8 geht meistens garnichts, aber dann sofort zum Rechner -> Power On. Man wird es nicht glauben, doch bevor mich das Web verschlingt geht es noch – im Sinne des Blutdrucks und Gewichts – eine halbe Stunde auf den Hometrainer.

Nach beendeter Körperpflege führt mich der Weg mit Frühstück zum PC, wo zu allererst unsere 20 Server einem Verfügbarkeitscheck unterzogen werden, meistens ist alles OK, doch mit der verwendeten Hardware und Gentoo nicht immer sicher 😉

Der restliche Tag besteht aus Supportanfragen (Mail, Forum) bearbeiten, essen, schlafen, essen, Server checken, essen und an neuen und alten Projekten basteln.
Trotz dieser oft eintönigen Tätigkeit mache ich die Arbeit immer noch gerne und hoffe auf viele weitere Jahre, was ja in dieser Sparte nicht unbedingt selbstverständlich ist.

Das Stöckchen wird von mir einbehalten und nicht weitergeworfen, da ich leider niemanden kenne der mir diese abnehmen würde 😉

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

Ausnahmsweise mal etwas aus der Windows-Welt, weils ganz gut in die Rubrik andere Zicken passt 🙂

Windows läßt sich nicht mehr bedienen weil die svchost.exe die komplette CPU beansprucht. Folgendes hat beim Rechner meines Vaters geholfen.
Dienste anzeigen:

Start -> Ausführen -> services.msc

Automatische Updates auf „Deaktiviert“ setzen.

Rechner neu starten. Diese Ordner leeren:

C:\\WINDOWS\\SoftwareDistribution\\DataStore 
C:\\WINDOWS\\SoftwareDistribution\\Download 
C:\\WINDOWS\\SoftwareDistribution\\EventCache

Bei den Diensten Automatische Updates wieder auf „Automatisch“ setzen.

Quelle: Blognotizen

Mußte heute feststellen, dass Google doch Trackback und Feedseiten indexiert hat:
http://www.chr.at/blog/2007/05/18/fehler-dev-php4suhosin-alert-configured-post-variable-limit-exceeded/trackback/
http://www.chr.at/blog/2007/05/18/fehler-dev-php4suhosin-alert-configured-post-variable-limit-exceeded/feed/

Habe die robots.txt daher um folgende Einträge erweitert:

Disallow: /blog/*/*/*/*/feed/$ 
Disallow: /blog/*/*/*/*/feed/rss/$ 
Disallow: /blog/*/*/*/*/trackback/$

EDIT 03.06.07: hilft auch nichts wies scheint

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.