Chris' Blog

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.

Wer mit WordPress bloggt wird merken, dass es sich hierbei um die „Duplicate Content“ Maschine schlechthin handelt, aber glücklicherweise gibts ein nettes Plugin namens WordPress Duplicate Content Cure welches sich diesem Problem annimmt.

Mittels soll eine Indizierung der kritischen Seiten wie Kategorien und Archiv verhindert werden.

Zur Sicherheit auch gleich noch die robots.txt von texto hinzugefügt:

User-agent: *
Disallow: /blog/wp-
Disallow: /blog/search
Disallow: /blog/feed
Disallow: /blog/comments/feed
Disallow: /blog/feed/$
Disallow: /blog/*/feed/$
Disallow: /blog/*/feed/rss/$
Disallow: /blog/*/trackback/$
Disallow: /blog/*/*/feed/$
Disallow: /blog/*/*/feed/rss/$
Disallow: /blog/*/*/trackback/$
Disallow: /blog/*/*/*/feed/$
Disallow: /blog/*/*/*/feed/rss/$
Disallow: /blog/*/*/*/trackback/$

Mal schauen obs hilft. 🙂

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“

Zwei Server komplett ident aufgesetzt, aber einer muckte dann natürlich doch noch:

Can't locate DBD/mysql.pm

Ein emerge -avutD world
brachte dev-perl/DBD-mysql-3.0008
ans Tageslicht und wurde sogleich nachinstalliert.
Ob Mensch oder Software geschlampt haben sei dahingestellt 🙂