Linux

Ich weiss, dass viele Admins "Lighty" wegen seiner teilweise höheren Geschwindigkeit dem Apache vorziehen. Leider konnten das meine Tests in der Vergangenheit nicht bestätigen. Aber man muss natürlich mehrere Szenarien probieren. Also gab ich "Lighty" erneut die Chance, sich gegen den Apache zu beweisen. Und zwar auf einem Server, der nur Suchvorschläge für die User ausgibt, ähnlich dem Prinzip auf Google Suggest. Dabei sind in unserem Umfeld ~200 Requests/sec. auf ein PHP-Script zu beantworten, welches einige SQLite Datenbanken abfragt und die Ergebnisse ausgibt. Im Grunde ein sehr einfaches Script, aber die Masse der Anfragen macht hier die Last aus. Peaks von 300-400 Requests/sec. sind durchaus möglich.

Als Umgebung kam ein Debian GNU/Linux 4.0 AMD64 (Kernel 2.6.18-4-amd64) Server mit 2 Stück Dual-Core AMD Opteron(tm) Processor 2216 HE (sagt cat /proc/cpuinfo | grep Opteron | head -n1) @ 2.4 GHz, 4 GByte RAM und 2x WD-Rapor SATA-Platten an einem 3Ware-8000 Controller zum Einsatz. Ich würde das als duchaus leistungsfähiges System bezeichnen.

Zuerst wurde Lighty via apt-get in Version 1.4.13-4etch1 samt xCache (aus Sourcen) und PHP 5.2.0-8+etch5~pu1 (eingebunden via FastCGI) installiert, was aber nicht wirklich gut funktionierte. Denn nach einigen Minuten ging die CPU-Last auf 100% und der Server reagierte nicht mehr wie gewünscht auf Anfragen. Nach einigen Recherchen im Wiki auf der HP von Lighty stieß ich dann auf den wahrscheinlichsten Grund, eine Lösung war leider nicht zu finden. Seltsamerweise trat das Problem in der anschließend von Hand kompilierten Version 1.4.18 nicht mehr auf, so dass der Server ca. 24 Stunden unter Last durchlaufen konnte. Die Load bewegte sich bei 3.x im Schnitt und alle Anfragen wurden schnell beantwortet. Allein die Prozessanzahl war mit mehreren hundert PHP-Prozessen etwas hoch (8 Lighty-Prozesse mit je 64 PHP-Prozessen waren konfiguriert), was aber kein Problem war. Änderungen an der Anzahl der PHP-Prozesse brachten keinerlei Veränderungen an der Last.

Nun konnte der Apache in Version 1.3.34-4.1 (Debian-Paket) samt PHP-Modul libapache-mod-php5 in Version 5.2.0-8+etch5~pu1 zum Einsatz kommen. Statt xCache habe ich hier den eAccelerator v0.9.5.2 aus Sourcen zum Einsatz gebracht. Die Konfiguration gefiel mir sowieso deutlich besser also bei Lighty, schließlich kenne und benutze ich Apache seit vielen Jahren. Auch scheint mir das Finetuning hier etwas genauer möglich zu sein, zumindest was KeepAlive etc. angeht. Das KeepAliveTimeout wurde also auf 5 sec. gesetzt, MinSpareServers auf 15, MaxSpareServers auf 25 - die anderen Werte habe ich nicht verändert. Der Apache läuft nun seit rund 48h im Dauertest und hat eine mittlere Load von 2.x. Alle Anfragen werden ebenfalls problemlos beantwortet. Außerdem ist die Prozessanzahl deutlich geringer, da für PHP als Modul keine FastCGI-Prozesse "gespawnt" werden müssen wir bei Lighty.

In beiden Webservern wurde übrigens alle überflüssigen (also quasi alle ausser fcgi bzw. PHP) Module für den Test deaktiviert. Abschließend kann ich nur sagen, dass ich hier erneut keinen Vorteil für Lighty verbuchen kann und daher Apache auf diesem Server im Einsatz bleibt. Aber vielleicht finde ich ja noch das ideale Szenario für Lighty

In der aktuellen iX geht es (wieder einmal) um Spamfilterung. Viel kann man dabei heutzutage mit Blacklist-Abfragen bzw. Hash-Listen erreichen, die sich in alle gängigen MTA's bzw. Spamassassin einbinden lassen. Also habe ich direkt mal iXhash bei mir im Spamassassin eingebunden, eine Liste die von der iX gepflegt und bereitgestellt wird. Das Ganze gestaltet sich recht einfach, ist aber schlecht dokumentiert. Daher habe ich direkt mal einen kleinen Howto-Eintrag dazu im kürzlich wieder gestarteten AdminWiki gemacht Bisher habe ich durch diese recht kleine Liste (rund 40k Einträge im Mittel) zwar noch keine Treffer erzielen können, es hat aber auch keine negativen Folgen und funktioniert reibungslos.

Die diversen von mir gewarteten Mailschleudern basieren alle auf dem sehr schönen Howto von workaround.org, also auf Debian, Postfix als MTA, Dovecot als POP3(S)/IMAP(S) - Server und amavisd-new als Schnittstelle zu Spamassassin und ClamAV. Außerdem wurden die Installationen durch kleine Erweiterungen wie dem von mir geschriebenen Spamreporter-Script erweitert. Und ich muss sagen, es funktioniert vorzüglich - kaum noch Spams, False-Posivites oder Probleme. Die User sind alle zufrieden und der Admin dementsprechend auch Und die Wartung ist dank der Zuarbeit meines Kollegen Ronny auch denkbar einfach, er hat für die Konstellation von workaround.org kürzlich ein kleines Verwaltungsscript in PHP geschrieben, mit dem man über ein Webinterface neue Domains, User und virtuelle Aliase anlegen kann. Solltet ihr euch also noch mit Textfiles rumschlagen, wird es Zeit für ein Update auf postfix-mysql samt o.g. Konfiguration!

Nach diversen Problemen mit den Marvell-GBit-NIC's (siehe Posting hier weiter unten) in verschiedenen Thomas-Krenn Servern habe ich nun offenbar eine Lösung gefunden: Das Debian-Paket linux-image-2.6.22-2-686 aus dem Lenny- Zweig. Dieses lässt sich auch unter Etch installieren und scheint den Fehler mit ständigigen Hängern des sky2-Modules zu beheben. Zumindest läuft der entsprechende Server mit Netzwerkdurchsatz von ~15 MBit/sek. seit dem Update völlig problemlos (an einem 100 MBit-Switch - im GBit-Betrieb sollte es aber ebenfalls behoben sein).

Etwas verwirrend ist allerdings, dass sich offenbar im Kernel 2.6.22 eine ältere Version den Treibers befindet, nämlich die 1.14. Zumindest ist auf der Konsole mit dem 2.6.22er Kernel zu lesen:

~# dmesg | grep sky2
sky2 0000:02:00.0: v1.14 addr 0xdedfc000 irq 16 Yukon-EC (0xb6) rev 2

Auf einer Debian-Maschine mit 2.6.18-5-686 hingegen scheint Version 1.5 aktiv zu sein (die nur Probleme macht):

~# dmesg | grep sky2
sky2 v1.5 addr 0xdedfc000 irq 169 Yukon-EC (0xb6) rev 2

Die Version spielt hier aber keine Rolle, solange die Server stabil im Dauereinsatz laufen und nicht aller $kleine_zahl Tage die Netzwerkkarte hängt. Eigentlich sollte das eine Selbstverständlichkeit sein, aber leider scheint hier das Debian-Team ein wenig hinterherzuhängen - schließlich ist im aktuellen Etch immernoch bzw. schon wieder der seit Jahren bekannte Fehler vorhanden. Auf http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396185#102 sind zumindest weitere Berichte zu finden.

Leider haben wir in diversen Servern von Thomas-Krenn NIC's der Marke Marvell Yukon2 Gigabit LAN auf dem Board, meist zusätzlich zu einem Intel Pro 100[0]. Keine Ahnung, warum hier nicht einfach 2 Intel-Chips draufgepackt wurden, schließlich gibts damit so gut wie keine Probleme. Der Marvell-Treiber sky2 macht hingegen unter Linux seit Ewigkeiten Probleme - bei mir auch noch im aktuellen Etch-Kernel 2.6.18-5-686. So kennen viele User folgenden Fehler:

NETDEV WATCHDOG: eth0: transmit timed out
sky2 eth0: tx timeout
sky2 eth0: transmit ring 263 .. 240 report=263 done=263
sky2 hardware hung? flushing

bzw. diesen "Auswurf" in /var/log/messages:

Nov 1 18:09:43 hostname kernel: sky2 status report lost?
Nov 1 18:10:41 hostname kernel: sky2 eth0: disabling interface
Nov 1 18:10:46 hostname kernel: sky2 eth0: enabling interface

In der Praxis geht dann mit dem Interface gar nichts mehr und es hilft nur ein Reboot oder manchmal auch ein rmmod sky2 && modprobe sky2, womit das Modul neu geladen wird. Mir ist dabei aufgefallen, dass Interfaces mit mehr Traffic den Fehler eher aufweisen. So rennt der das exakt identische Modul auf einigen Servern mit kaum Traffic auf dem jeweiligen Interface völlig problemlos, wo es hingegen auf anderen Servern mit Traffic von durchschnittlich 10 MBits/sek. aller 2-3 Tage zu obigem Fehler kommt. Angeblich soll die nächste Kernel-Version das Problem fixen, wünschenswert wäre es auf jeden Fall. Ansonsten sehe ich mich gezwungen, zumindest in diesem einen Server hier noch eine Intel Pro 1000 einzubauen und die Marvell auf dem Board zu deaktivieren. Oder gibts noch einen Trick, den ich bisher nicht herausgefunden habe?

Auf dem selben Server ist via dmesg auch noch folgender Fehler zu lesen:

BUG: warning at kernel/cpu.c:51/unlock_cpu_hotplug()
[] unlock_cpu_hotplug+0x2c/0x54
[] sched_getaffinity+0x67/0x6e
[] sys_sched_getaffinity+0x1f/0x41
[] sysenter_past_esp+0x56/0x79

Das scheint allerdings keine negativen Auswirkungen zu haben. In diversen Mailinglisten findet man zumindest viele User, die diesen Fehler auch bekommen. Wenn man Leidensgenossen hat, ist es gleich nur noch halb so schlimm

Leider ist die Sommerzeit wieder zu Ende, so dass in dieser Nacht die Uhren um eine Stunde zurückgestellt werden mussten. Unter Linux übernimmt das erfahrungsgemäß der ntpd automatisch, der sich auf Debian im Paket ntp-server verbirgt. Die Umstellung hat auch problemlos geklappt - nur cacti, mein installiertes RRD-Graphing Tool, kam damit nicht so ganz klar, wie folgende Grafik zeigt:



Ich kann das aber durchaus verstehen, denn schließlich kann cacti nun wirklich nicht wissen, dass auf einmal eine Stunde doppelt vorkommt
Für die "manuellen" Umsteller unter uns gibts unter http://www.uhrzeit.org/atomuhr.html eine zuverlässige Uhrzeit. Armband- und Küchenuhren tun sich ja mitunter schwer bei der Installation von ntp-server.

Auf unseren Webservern (32 Bit Debian Etch) mit je 8 x Xeon E5310 hatte ich bisher den Debian-Kernel kernel-image-2.6-em64t-p4-smp im Einsatz. Allerdings konnte ich via dmesg immer irgendeinen ACPI-Bug bewundern, der aber offenbar den Betrieb nicht weiter beeinflusste. Schlimmer war jedoch, dass der 3dm2 nicht funktionierte, so dass ich über einen Plattendefekt im 3Ware-RAID5 nicht informiert worden wäre. Sämtliche Tests mit den Files von 3ware.com und den Debian-Paketen von Jonas Genannt (http://jonas.genannt.name/) scheiterten, obwohl diese auf anderen Servern problemlos rennen. An dieser Stelle gleich mal einen lieben Dank an Jonas für die Pakete, schließlich sind diese auf allen Servern hier installiert.

Nunja, also setzte ich testweise den Kernel linux-image-2.6.18-5-686 auf einem der Server auf und siehe da, der 3dm2 ließ sich problemlos installieren und das Webinterface zeigte mir den Controller samt Platten an. Die Installation glückte zwar auch schon mit dem anderen Kernel, nur stand nach dem Login dann "NO CONTROLLERS" da. Auch der seltsame APCI-Fehler trat seither nicht mehr auf, ich hoffe das bleibt so. Ansonsten kann ich mit diesem Kernel keine Unterschiede erkennen, die Serverapps laufen problemlos wie zuvor. Es scheint also, ob ob ein 64 Bit-Kernel unter Umständen Probleme auf einem 32 Bit-System machen kann. Es gibt aber in diesem Fall eigentlich auch keinen Grund für 64 Bit, denn die Maschinen laufen nur mit je 2 GByte RAM und Apache als Hauptanwendung.

Die seit einer Weile bekannte Lücke in openssl wurde gestern endlich auch vom Debian-Team mit neuen Paketen behoben. Zwar habe ich jetzt keinen direkten Exploit gesehen, aber besonders bei solchen Sachen bin ich mit Updates immer ganz schnell

Seit meinem Release von Updian (siehe ein paar Postings vorher) zum automatischen Update von Debian-Servern verfolge ich, wie sich das bei Google in den Ergebnissen verbreitet. Es gab nämlich bisher nur sehr wenige Treffer zu "Updian" bei Google bzw. im europäischen Raum gar keine. Inzwischen gibts schon einige Treffer und ich bin gespannt, wie das weitergeht

Ich bin übrigens ab morgen eine Woche im Urlaub (Sonne, ich komme!) - in diesem Sinne bis bald und euch ebenfalls eine schöne Zeit

Jeder Admin, der dutzende Server zu betreuen hat, steht irgendwann vor dem Problem, dass die Distribution regelmäßig auf den neuesten Stand gebracht werden muss. Sei es durch Weiterentwicklung der installierten Pakete oder - was besonders kritisch ist - durch Patches für Sicherheitslücken. Einzeln auf jeden Server zu gehen kann da nach einer Weile schon ganz schön nerven, vor Allem wenn man beispielsweise den Testing-Tree (Lenny) von Debian einsetzt. Aber auch bei Stable (Etch) gibt es schonmal Updates, die dann auf allen Servern eingespielt werden müssen.

Zu diesem Zweck habe ich in in PHP "Updian" geschrieben, was für "DebianUpdater" steht. Man könnte es als minimalistischen Update-Manager für Debian bezeichnen, denn es ist damit möglich, diverse Server in kurzer Zeit auf den neuesten Stand zu bringen. Updian stützt sich dabei natürlich auf "apt-get". Das Management der Updates geschieht in einem einfachen Webinterface, wo man in einer Übersicht die Server aufgelistet bekommt, welche Updates bereithalten. Ein Klick auf den Server zeigt detailliert die Pakete samt Versionsnummern an, für die es Updates gibt (siehe Screenshot). Man kann also einfach auswählen, auf welchen Servern der Update-Cronjob beim nächsten Durchlauf ein apt-get upgrade ausführt. Die entsprechenden Ausgaben kann man sich unter "Logs" anschließend ebenfalls im Webinterface anschauen. Ebenfalls ist es möglich, die bei der Automatisierung störende Nachfrage bei neuen Versionen von Config's zu unterdrücken und immer die aktuelle Version zu behalten.

Es ist erforderlich, dass der passwortlose Zugriff via SSH vom Updian-Server auf die "Clients" konfiguriert ist, damit Updian seine Befehle absetzen kann. Diverse andere Einstellungen kann man in der mitgelieferten config.php anpassen. Updian versendet auf Wunsch auch eine Infomail an den Admin, wo es über neue Updates informiert. Weitere Infos und Installationshinweise finden sich in der beigelegten README.txt. Da ich bisher der einzige User dieser Software bin, habe ich es als v0.1 beta released, man sollte also nicht zuviel erwarten. Es erfüllt aber bisher hervorragend seinen Zweck

Über Anregungen, Feedback usw. zu dem kleinen Tool würde ich mich sehr freuen. Mir jedenfalls hat es schon eine Menge Arbeit erspart, vielleicht hilft es Dir ja auch

• Website von "Updian"
  
• Screenshot vom Webinterface

Man liest ja seit einer Weile sehr viel von lighttpd, dem Webserver mit dem Spitznamen "lighty". Also habe ich mir das Ding mal näher angeschaut und ein paar Tests mit der Apache Benchmark (ab) gemacht. Schließlich war auf einigen Seiten von Performance-Boots bis zu 20% zu lesen, und auch Webgrößen wie YouTube, Flickr, Mininova, Freenet u.v.a. setzen auf lighty, wenn auch mit teilweise selber angepassten Versionen. Weniger Speicher verbrauchen soll er, da sämtliche Anfragen von einem einzigen Prozess bedient werden. Nunja, an Speicher mangelts bei meinen Servern i.d.R. kaum Scriptsprachen (in diesem Beispiel PHP5) werden via FastCGI angesprochen und nicht, wie in vielen Apache-Setups, als Severmodul. Die Tests wurden alle mit lighttpd und apache2 duchgeführt, um einen gewissen Vergleich zu bekommen. Zusätzlich habe ich je noch einen Test mit aktiviertem PHP-Optimizer gemacht, für lighty war das XCache, für das Apachemodul kam eAccelerator zum Einsatz.

Als Testserver stand ein Server mit 2x Xeon@3 GHz HT, 2 GByte RAM und SATA-RAID5 zur Verfügung. Installiert war Debian/Lenny mit aktuellem Softwarestand. Also wurden erstmal flott die Pakete apache2, libapache2-mod-php5, php5-cgi, php5-xcache und lighttpd via apt geholt. Der eAccelerator wurde mangels Paketen aus den Sourcen gebaut. Ich habe, soweit möglich, die Standard-Configs belassen und nur das nötigste wie Pfade etc. angepasst. Den Caches habe ich jeweils 32 MByte an Speicher zugewiesen, wenn diese im Einsatz waren. Das Paket mysql-server wurde ebenfalls installiert, der key_buffer auf 128M gesetzt. Natürlich habe ich noch log_bin auskommentiert, schließlich wollen wir hier keine Replikation betreiben. Ansonsten lief auf dem Testsystem nur noch ein Postfix, der aber sowieso nichts zu tun hatte.

Als Testsoftware erschien mir S9Y geeignet zu sein, da es recht viele Ressourcen benötigt und bei mir auch Live im Einsatz ist (siehe dieses tolle Blog hier ). Also wurde es in der aktuellen Version 1.2 frisch auf dem Testserver installiert. Um ein wenig Content im Blog zu haben, füllte ich es mit 10 Posts, die alle die GPL v3 in Textform beinhalteten und auch alle auf der Startseite angezeigt wurden. Ansonsten wurde an S9Y nichts verändert. Apache kam in Version 2.2.4-3 (Debian), lighttpd in Version 1.4.18-1 (Debian), PHP sowohl als Modul wie als CGI in Version 5.2.3-1+b1 (Debian) zum Einsatz.

Dann begann der Test von meinem lokalen Linuxrechner aus (Athlon64 3500+, 1 GByte RAM, Ubuntu 7.04, ab in Version 1.146), der am selben 100MBit/s-Switch hing wie der Testserver. Es wurden insgesamt jeweils 500 Requests mit 2 gleichzeitigen Anfragen simuliert (ab -n500 -c2 -dS http://...), welche die index.php von S9Y aufriefen. Um die "Ausrutscher" zu eliminieren führte ich jeden der Tests 3x durch und entschied mich für den schnellsten Durchlauf, sofern dieser realistisch aussah. Das funktioniert auch ganz gut.

Los ging es mit der "Default-Config", also apache mit PHP als Modul ohne PHP-Cache, wo die ganze Geschichte 276.35 sek. dauerte. Prinzipiell finde ich das ziemlich langsam, aber immerhin sind es für alle Testläufe die gleichen Bedingungen. Anschließend der selbe Test mit lighttpd ohne PHP-Cache, womit das Ganze dann 246.30 sek. dauerte, also rund 30 sek. weniger als mit Apache. Das entspricht rund 0.2 Requests/sek. oder 10% Vorsprung. Gar nicht schlecht. Anschließend der Test mit zugeschaltetem eAccelerator unter Apache: 272.44 sek! Komischerweise bringt der eAccelerator hier so gut wie gar nichts - in einem anderen Versuch war er sogar langsamer als der schnellste Versuch ohne ihn! Woran das liegt kann ich nicht sagen, bisher hatte ich nur gute Erfahrungen mit dem Beschleuniger. Im letzten Test kam dann lighttpd samt aktiviertem XCache zum Einsatz und absolvierte die Testaufrufe mit 204.26 sek. - der deutlich beste Wert. Es scheint also, dass lighttpd hier durchaus einige Vorteile hat.

Die genauen Ergebnisse kann man hier bestaunen:

• apache2_mod-php5_plain.txt
  
• lighttpd_php-fcgi_plain.txt
  
• apache2_mod-php5-eAccelerator.txt
  
• lighttpd_php-fcgi_XCache.txt

Es könnte also in gewissen Umgebungen durchaus Sinn zu machen, einen Umstieg in Betracht zu ziehen. Leider muss man sich teilweise umgewöhnen, denn z.B. unterstützt er offenbar keine bekannten .htaccess-Files und auch die Rewrite-Rules werden ein wenig anderes dargestellt. Das macht den Umstieg in Shared-Umgebungen problematisch. Wahrscheinlich werde ich einen unserer Webserver hinter einem Loadbalancer testweise mit lighttpd aufsetzen und dann parallel mit den Apache-Servern laufen lassen. Daran sollte man dann besonders gut eventuelle Vorteile bei Lastspitzen etc. beurteilen können. News gibts dann natürlich wieder hier ...

Das Admin-Blog meldet sich mit einem besonders tollen Posting wieder zurück

sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; apt-get install condom; mount; fsck; gasp; more; yes; more; umount; apt-get remove --purge condom; make clean; sleep

Da mir mein Ubuntu 5.10 auf dem Arbeits-PC seit einiger Zeit stets das Update auf die "6.06 LTS" (LTS = Long Term Support, d.h. Updates gibts für mehrere Jahre) angeboten hatte, klickte ich gestern ohne groß nachzudenken direkt mal auf "aktualisieren". Das war gegen 17 Uhr und kurz vor Feierabend. Die rund 1400 zu erneuernden Pakete zog der Update-Manager gemächlich aus dem Netz, weswegen ich den Rechner anließ und eine Weile später heimging.

Als ich dann heute früh voller Vorfreude auf mein "Dapper Drake" die Monitore wieder anschaltete, sah auf den ersten Blick alles OK aus. Sogar die Icons waren schon neu und Firefox etc. erstrahlten in neuer Version. Komischerweise lief allerdings das Updatetool noch und hing am Paket "pcmcia-cs" fest. Ich hatte keine Chance, irgendwie abbrechen oder so etwas zu klicken. Also töte ich als Root den Update-Prozess. Dass das keine gute Idee war merkte man sofort daran, dass die Tastatur nicht mehr ging. Die Maus hingegen schon noch. Zu dem Zeitpunkt kam ich leider auch nicht auf die gute Idee, via Remote-SSH noch etwas zu retten - das fiel mir vorhin erst ein
Also drückte ich befrustet Reset und ahnte schon, dass das Probleme gibt

Und so war es dann auch, die Kiste (Dell Optiplex GX620 mit P4 HT) blieb einfach hängen. Ganz toll. Also musste ich mir wohl oder übel die aktuelle Ubuntu-ISO download. Das dauerte trotz Standleitung eine Weile, schließlich mache ja nicht nur ich Traffic auf der Leitung
In der Zwischenzeit hatte ich bereits diverse Leidensgenossen gefunden. Offenbar hing es damit zusammen, dass es Probleme mit dem 2.6.12-smp Ubuntu-Kernel gab. Nachdem der Download fertig und die CD gebrannt war, konnte ich wenigstens in Rescue-System booten. Xorg wollte zwar dort nicht laufen,
aber das war mir egal.

Nachdem ich dpkg --configure -a und nochmals apt-get update && apt-get dist-upgrade ausgeführt hatte, machte er endlich weiter. Da kam dann auch der neue Kernel 2.6.15-smp mit runter, wo das Problem wohl nicht mehr auftreten soll. Ein Reboot bestätigte das erfreulicherweise. Als erste Tat deinstallierte ich sämtliche PCMCIA-Pakete, schließlich ist das hier kein Notebook
Komisch, dass die überhaupt mit installiert wurden damals ...

So habe ich nun "Dapper Drake" im Einsatz und finde die neue Optik sehr gelungen.
Leider fällt mir bisher negativ auf, dass z.B. der Löschvorgang einer Datei auf dem Desktop extrem lange dauert (+10 sek). Einen Grund dafür habe ich noch nicht gefunden. Außerdem funktionieren meine Samba-Mounts nicht mehr, was ärgerlich ist. Aber ich bin optimistisch, den Grund noch zu finden
Was ich positiv erwähnen muss ist, der bessere "fglrx"-Treiber/Support für meine Ati-Karte hier. Dual-Head ist nun im verhalten wie unter Windows, denn wenn ich nun ein Fenster maximiere, füllt es genau einen Bildschirm aus - nicht wie vorher 2. Da gestaltet sich das Arbeiten deutlich angenehmer.

Auf einem unserer Server läuft auch Ubuntu, das werde ich mir nächste Woche noch vornehmen ... aber da fliegen alle PCMCIA-Pakete vorher runter, soviel ist sicher

Da ich trotz dem Einsatz unzähliger RBL's in Postfix noch immer recht viele Spams bekommen habe, entschied ich mich für den Einsatz von Spamassassin zum Content-Scanning und ClamAV als Virenscanner. Das Ganze ist dank amavisd-new auch recht schnell implementiert, so dass man nur minimale Anpassungen an der Config vornehmen muss. Das Unterprogramm "freshclam" von ClamAV sollte als Daemon laufen, um stets die aktuellen Virensignaturen aus dem Netz beziehen zu können, der ebenfalls auf eine Bayes-Engine setzt.

Mit den Default-Einstellungen ist die Erkennungsrate von Spamassassin schon durchaus beachtlich, externe Prüfdienste wie Razor, Pyzor oder DCC helfen helfen ebenfalls mit. Wenn dann mal einige hundert Spams bzw. Hams zusammengekommen sind, kann man den Scanner via "sa-learn" noch besser trainieren. Durch die Bayes-Engine sind die Erkennungsraten danach durchaus beachtenswert. Zumindest waren meine Erfahrungen diesbezüglich bei einem früheren Einsatz des "bogofilter" durchaus positiv.

Als einzigen Nachteil kann ich eigentlich nur die etwas höhere CPU-Last beim Scannen (das ließe sich aber wahrscheinlich mit dem Einsatz von Spamassassin bzw. ClamAV als Daemons noch optimieren) sowie die etwas umständliche Config von amavisd-new nennen. So habe ich es bisher noch nicht hinbekommen, dass amavis mir an jeden Mailheader einen sinnvollen X-Spam-Report anhängt, wo die einzelnen Scannings genau erläutert werden. Dennoch macht die Lösung einen sehr guten Eindruck und ist in kurzer Zeit aufgesetzt. Seit 2 Tagen hat sich damit zumindest mein Spamaufkommen deutlich reduziert. Dank "courier-maildrop" werden Mails mit "X-Spam-Status: Yes" im Header auch direkt in dem Spamordner der jeweiligen Maildir geleitet. So kann man tatsächlich einige Stunden im Mailprogramm verbringen, ohne irgendwas von Viagra etc. lesen zu müssen - sofern man nicht versehentlich auf den Spamordner klickt

Für die Interessierten habe ich das alles mal in eine kleine Howto gepackt. Man beachte auch mein tolles Reportingscript, welches dem User eine Zusammenfassung der gefundenen Spams sendet.

PS:
Heute um 2 Uhr begann die Sommerzeit! Also mal ntpdate (sofern ntpd nicht rennt) laufen lassen oder das Datum von Hand stellen. Schade, dass meine Armbanduhr kein ntpdate implementiert hat ...

Es war an der Zeit, einige private Webprojekte umzustellen etc, so dass ich mich wieder einmal für die Anmietung eines Rootservers entschied. Nach Preis/Leistungsvergleich zwischen den "großen Hostern" fiel die Wahl diesmal auf Strato. So habe ich kurzerhand den HighEnd-Server MR2 mit Opteron 146, 2x 160 GByte SATA-HDD, 1024 MByte RAM und "Traffic Flatrate" bestellt. Offenbar will Strato damit den Anschein erwecken, ich könne unendlich viel Traffic verbrauchen. Dennoch mutmaße ich natürlich, dass ich bei > 5 TByte im Monat dauerhaft Probleme bekommen würde - aber das habe ich ja gar nicht vor

Also Montag morgen online bestellt, brav die telefonisch mitgeteilte PIN ins Webinterface eingetragen, und gewartet. Schon am Nachmittag teilte man mir via Mail mit, mein Server sei bereit. Wirklich schnell, das macht einen guten Eindruck (ja, ich weiss, dass man Images i.d.R. sehr schnell aufspielen kann, freue mich aber trotzdem darüber *g*).

Das vorinstallierte SuSE 9.3. mit Plesk und anderen (für mich) sinnlosen Tools musste natürlich weichen. Auf diesem Server sollte natürlich wie immer Debian laufen. Strato bewirbt den MR2 zwar mit RAID1, meint damit aber, dass sich 2 identische Platten (SATAII, Hitachi) im Server befinden. Mit dem via Configmenü unter "Neuinstallation" gewählten Debian erwartete mich also ein sauber installiertes Debian Sarge auf /dev/sda! Toll, aber was war nun mit RAID bzw. was sollte ich mit der 160 GByte großen (leeren) /dev/sdb machen?

Nach kurzer Google-Recherche fand ich eine hervorragend geschriebene Anleitung dazu von Andre Hotzler, der bereits vor der selben Aufgabenstellung stand - vielen Dank an dieser Stelle! Also das Rescuesystem hochgefahren und die beschriebenen Schritte ausgeführt. Es lief alles wunderbar und ich bin bisher sehr zufrieden. Als Kernel habe ich allerdings entgegen der Anleitung die Variante "2.6.8-11-amd64-k8" gewählt. Die Platten laufen nun als Software-RAID1 (/dev/mdX) und angenehm performant. Der Opteron scheint deutlich schneller zu sein (wer hätte das gedacht ) als der im alten Server werkelnde AthlonXP bei gleicher Taktgeschwindigkeit. Das merkt man u.a. bei Rechenintensiven Sachen wie Logfileanalyse durch Webalizer usw. Auch PHP ist angenehm schnell, zumal ich natürlich wieder auf eAccelerator (v0.9.5 beta1) setze.

Das Configmenü von Strato macht ebenfalls einen sehr guten Eindruck. Zusammen mit dem 160 GByte großen FTP-Space, 6 Domains, der seriellen Konsole und der Hard-Reset-Möglichkeit des Servers finde ich 69 EUR im Monat durchaus fair dafür. Wie der Support ist, werde ich sehen, wenn die Kiste mal nicht mehr erreichbar ist. Aber dann bekomme ich ja eine SMS vom Monitoring-Server, da die Überwachung eines Dienstes (bei mir: PING) gratis dabei ist ...

Wenn man auf der Shell statt vim file ein spontanes rm file eingibt, hat man schlechte Karten. So ging es mir eben. Da hatte ich eine schöne PHP-Klasse zur Erzeugung von RSS-Feed geschrieben, und weg ist sie wieder
Ich hoffe, mein Backup zu Hause ist nicht zu alt. Auf dem Server hatte ich leider vergessen, den entsprechenden Ordner in mein REOback aufzunehmen. Selber schuld, trotzdem sehr nervig.

Unter ext3 scheint man auch keine Chancen zu haben, das File wiederzubeschaffen. Meine angestrengten Versuche bei ausgehangenem Filesystem mit:

grep --binary-files=text -50 "<\?php" /dev/hda6 > recovery

brachten zwar jede Menge Zeugs zum Vorschein, mein Script war aber nicht dabei. Zumindest konnte ich mit strings nichts aus dem Binaryfile entlocken ...

Naja, daraus kann man nur lernen. Oder so

Als ich gestern mal wieder auf eAccelerator.net vorbeischaute staunte ich nicht schlecht. So gibts seit 20.11.05 den Release Candidate 1 der Version 9.4! Laut den Release Notes handelt es sich allerdings nur um ein reines Bugfix-Release. Ich werde daher meine Server nicht updaten, da die 0.93 problemlos überall läuft. Aber gut zu wissen, dass das Projekt nicht eingeschlafen ist, denn diese Befürchtung hatte ich bereits ...

Auch von Fedora gibt es etwas Neues, nämlich "Core 5 Test 1". Laut den Release Notes sind viele Neuerungen wie z.B. x.org 7.0 und KDE 3.5 bzw. Gnome 2.12 enthalten. Laut Roadmap erscheint die Final im Februar 2006. Einige Server bei uns laufen zwar auch mit Fedora (Core 3 und 4), ich bin allerdings kein großer Fan dieser Distribution. Der Paketmanager yum konnte mich nicht überzeugen, so war er einfach nur langsam, was Updates und Installationen anging. Da geht das Arbeiten mit apt schon besser von der Hand Aber irgendwas muss ja doch dran, schließlich erfreut sich Fedora recht großer Beliebtheit. Oder liegt das nur am großen Bruder und Vater RHEL?

Laut Heise ergab eine Studie von IDC, dass Windows-Server im 3. Quartal erstmals mehr Umsatz alle anderen Systeme zusammen gemacht hätten. Das liegt wohl an der Stagnation im Unix-Markt. Linux konnte erfreulicherweise mit einem Wachstum von 20,5 % zulegen - MS wuchs um 15,3 %, Unix fiel um 13,7 %! Das klingt nach schlechten Zeiten für SCO und Konsorten ...