Wie ich gerade lesen musste, gehört Strato nun der Deutschen Telekom (naja bald, wenn die Kartellbehörden zugestimmt haben etc). Irgendwie bin ich unschlüssig, ob mir das nun gefallen soll oder nicht (u.a. dieser Blog läuft seit kurzem auf einem Server bei Strato)… Wenn man sich allerdings anschaut, wer noch Interesse an Strato hatte… dann kann man 1 und 1 zusammenzählen und wird feststellen, die Deutsche Telekom ist wohl das kleinere Übel… Wobei mich durchaus interessiert hätte, was denn die Kartellbehörden zu einer Übernahme durch United Internet (1und1) gesagt hätten…

Mal sehen wie Strato integriert wird und auf welche Umstellungen man sich in naher Zukunft dann gefasst machen darf… (bei meinem Internetanschluss bin ich ja auch mal gespannt, was aus Alice nach der Übernahme durch O2/Telefonica passiert…)

Bei meinem AdServer haben sich im Laufe der Zeit größere Mengen an Statistiken angesammelt, die eigentlich nicht mehr benötigt werden (ich schau sie mir nicht mehr an und sonst hat derzeit Niemand zugriff darauf). Aber wie wird man die alten Statistiken los? Eine Funktion dafür gibts in OpenX leider nicht und im Forum gibts nur ein paar Anmerkungen, wie “lösch halt die Tabellen mit _data_”. Im Internet bin ich dann über diesen Blogbeitrag “Purge OpenX statistics tables” gestolpert und im Grunde ist es also auch gar nicht so schwer (unverständlich, warum man das nicht im Backend direkt machen kann).

Sprich, wer wie ich alle Daten die älter als 3 Monate sind, kann auf eigene Gefahr folgendes probieren:
DELETE FROM ox_data_intermediate_ad WHERE interval_end < DATE_SUB(CURDATE(), INTERVAL 3 MONTH);
DELETE FROM ox_data_summary_ad_hourly WHERE date_time < DATE_SUB(CURDATE(), INTERVAL 3 MONTH);
DELETE FROM ox_data_summary_zone_impression_history WHERE interval_end < DATE_SUB(CURDATE(), INTERVAL 3 MONTH);

Vor kurzem hatte ich ja schon darüber berichtet, ich durfte einmal mehr einen Server durch einen neuen Server ersetzen (mod_fastcgi -> mod_fcgi). Eine weitere Änderung gab es nun beim Backup.

Für inkrementelle Backups auf unsichere Medien (FTP) setze ich schon seit langem auf Duplicity. Für die leichtere Konfiguration/Bedienung kam bei mir bisher Ftplicity zum Einsatz. Doch leider wurde dieses von heise.de entwickelte Skript nicht mehr gepflegt. Aber es gibt Ersatz: Duply. Duply kann alles was auch Ftplicity kann und noch ein paar Dinge mehr. Es wird auch (noch) aktiv weiterentwickelt (und insbesondere an aktuelle Versionen von Duplicity angepasst).

Im Zuge der Umstellung habe ich nun auch die bisherige “ich sichere einfach alles in einem Backup-Strategie” gesplittet in System- und “Webseiten”-Backups (inkl. DB). Warum? Änderungen am System sind seltener (und bei grösseren Änderungen kann man ja noch schnell ein manuelles Backup machen) und ein Backup einmal die Woche sollte dafür eigentlich ausreichend sein. Bei Webseiten/DB sieht es allerdings anders aus, hier sind möglichste aktuelle Backups interessant (wenn auch hoffentlich weiterhin nicht wirklich notwendig) und so sollte dies mind. einmal am Tag stattfinden.

Ein kurze Anleitung zur Verwendung von Duplicity + Duply für Backups unter Debian Lenny gibts hier.

Aktuell darf ich mich wiedermal mit dem Problem rumschlagen, einer Server durch einen neuen zu ersetzen. Wie so oft gilt, wo gehobelt wird… und so kam es auch zu kleineren Zwischenfällen, u.a. war auch mein Blog Gestern für einige Stunden von der Aussenwelt abgetrennt (ich hatte unbeabsichtigterweise den DNS-Eintrag fürs Blog schon auf die neue Adresse geändert, der Umzug kommt allerdings erst die Tage).

» weiterlesen…

Betreibt man einen eigenen Server ist es unerlässlich, ist man auf den Server seines Providers so kann man seine Arbeit aber auch gelegentlich überprüfen und testen ob der/die Mailserver auf irgendwelchen Blacklisten gelandet sind.

Für den eigenen Server empfiehlt es sich, die Tests regelmässig durchzuführen und dabei zumindest die wichtigsten Listen abzufragen. Ein passendes Skript findet man z.B. bei heise.de (Shell- bzw. Nagios-Skript). Wenn man nicht auf Nagios setzt, empfiehlt es sich das Shell-Skript regelmässig per Cron aufzurufen und sich die Ergebnisse per E-Mail schicken zu lassen (dann vergisst man es nicht).

Wer nur gelegentlich ein derartiges Tool benötigt oder vll. einfach nur überprüfen will, gegen welche Blacklisten denn sonst noch so getestet wird für den Empfehlen sich entsprechende Webdienste:

• DNS Blacklist Test: Link
• DNSBL.info: Link
• slashbit.com: Link
• MX Toolbox SuperTool: Link (mit diesem Dienst kann man nicht nur gegen Blacklisten testen, es gibt u.a. auch ein SPF-Test oder einen Portscan)
• What Is My IP Adress: Link
• Software Projects: Link

Und wenn man nicht solange warten will,  bis der eigene Server auf einer Blacklist landet, so empfiehlt es sich den Server mit entsprechenden Tools zu testen, ob er als “Open Relay” missbraucht werden kann (einen entsprechenden Test gibts z.B. hier).

Wer sich über die Erfolgsquote (bzw. Fehlerquote) von Blacklisten interessiert findet hier eine interessante Statistik.

Nachdem ich die Tage einen neuen Mailserver aufgesetzt habe (mehr oder weniger nach dem Howto von johker), hatte ich mich nun ein bischen mit dem Feintuning beschäftigt. U.a. habe ich das Skript fürs Trainieren von Ham- bzw. Spam-Mails für die Bayes-Datenbank von Spamassassin überarbeitet, damit weniger (Fehler-)Meldungen produziert werden und man sich das Ergebnis damit eher per E-Mail (zur Kontrolle der Arbeit) zuschicken lassen kann:
» weiterlesen…

Für nur ein kleines Postfach reicht das Kopieren vom alten zum neuen Account via Thunderbird sicherlich aus. Was aber tun, wenn man einen kompletten Mailserver umziehen muss?

Hier kommt imapsync ins Spiel, damit lassen sich die E-Mails von 2 Accounts synchronisieren (z.B. Postfach auf dem altem Server mit dem Postfach auf dem neuem Server) inkl. der Flags. Beim Austausch zwischen 2 virtuellen Maschinen (unterschiedliche physikalische Server/100Mbit Netzwerk) kam das Tool bei mir immerhin auf +/-5,2 Mails/Sekunde (ohne Flags, d.h. mit –fast dürfte sich der Vorgang noch deutlich beschleunigen lassen).

Frei nach “Murphy’s Law”: Wenn etwas schiefgeht, dann so richtig. Und so in etwa war mein gestriger Tag. Angefangen hat es damit, das ich wiedereinmal vergeblich auf eine S-Bahn warten durfte. Ansagen kommen i.d.R. erst weit nach der eigentlichen Abfahrtszeit (wenn überhaupt) und somit zu spät um auf Alternativen umzusteigen. Nunja, wie auch immer… bei der Rückfahrt wieder das gleiche Spiel. Grund für die Ausfälle, eine völlig überraschende Weichenstörung die schon seit mind. 24h bestand (aber so schnell kann man darauf ja nicht reagieren). In der Zwischenzeit wurde nun bekannt gegeben, dass die Störung noch bis mind. 16. August besteht (super, bis gestern Abend hoffte man noch, die Störung schnellst möglich beheben zu können).

Aber der Tag war lange nicht um, kaum wieder zuhause erreichte mich die Nachricht, “Der Mailserver geht nicht”. Jegliche Versuche von mir remote darauf zuzugreifen schlugen fehl. Der Server (n Dual Opteron mit 16GB Ram und entsprechend einigen XEN DomU’s) verweigerte jegliche (Mit)Arbeit. Selbst ein (mehrfacher) Reboot brachte keinen Erfolg (auch der RAID-Kontroller meldete keine Probleme). Glücklicherweise liess der Server sich nach einigen Versuchen überreden, Knoppix von CD zu booten (was anderes war gerade nicht vor Ort). Ergo kam ich an die Platten und damit an die aktuellen Daten heran. Beim Packen/Kopieren der Daten hatte ich bei tar dummerweise nicht aufgepasst (ich hatte –numeric-owner vergessen) und somit liessen sich die DomU’s auf einer Ersatzmaschine zwar starten, aber so wirklich ihren Dienst wollten sie nicht verrichten (es stimmten die Datei/Verzeichnissbesitzer einfach nicht mehr). Wie auch immer, auch der Misserfolg (dummerweise dauert das Packen/Kopieren von >50GB doch ein bischen mehr Zeit) konnte mich nicht davon abbringen die 2 wichtigsten DomU’s auf der Erstazmaschine schlussendlich zum Laufen zu bekommen. Alles toll? Denkste, nun wurde der ursprüngliche Server nochmals rebootet und siehe da, er lief wieder ohne Probleme *narf* und ich hatte mir die Mühe gemacht, alles umzuziehen… Zum Glück hatte ich die restlichen DomU’s noch nicht auf dem Ersatzserver eingerichtet. Momentan laufen also 2 DomU’s auf dem Ersatzserver und der Rest noch auf dem eigentlichen Server. Viel Zeit für nichts? Wer weiss, der Server wird nun von mir erstmal noch genauer beobachtet

Vorgewarnt, hab ich dann gestern Abend nichts mehr wichtiges angefangen und bin schlafen gegangen.

Unglücklicherweise rechnet Murphy wohl aber nicht in Kalendertagen sondern in 24h Einheiten. Und so durfte ich heute Morgen im Monitoring auch gleich die 100% CPU-Auslastung eines Webservers zur Kenntnis nehmen. Top lieferte auch gleich den Schuldigen, MySQL krallte sich soviel CPU-Power wie nur möglich. Doch wer war der eigentliche Übeltäter. Dank der Einbindung von PHP via FastCGI wurde auch hier schnell ein Prozess ausgemacht. Und schwupps, kaum war die Webseite vom Netz, war auf dem Server wieder alles ruhig. Die Analyse der Logfiles brachte dann dann einen Angriff auf die Webseite über eine IP aus dem lateinamerikanischen Raum zu Tage. Achja, vll. sollte ich noch erwähnen, der Angriff war (zum Glück) eher erfolglos, ausser das der Server über Minuten hinweg mit der 100%-tiger CPU-Last zu kämpfen hatte, ist nichts kaputt gegangen…

Fazit: Die 24h sind nun endlich rum, und ich genehmige mir nun erstmal mein Frühstück

Heute hatte ich das Glück/die Aufgabe Zimbra (Open Source Edition), ein Mail/Calender-Server, zu installieren. Der Erste Eindruck ist durchaus positiv (einfache Installation), aber es zeigen sich leider auch recht schnell ein paar kleinere Mankos.

Installation:

Da leider von Zimbra keine Pakete für Debian/AMD64 zur Verfügung gestellt werden (die aktuelle Version von Zimbra gibts für Ubuntu derzeit leider auch nur für 6.06 *narf*) durfte ich mir heute wiedereinmal CentOS anschauen. Die “Installation von CentOS 5.2 unter XEN” (Sprich Image auspacken, Inhalt auf ein LVM-Laufwerk kopieren und ne Konfigurationsdatei schreiben) verlief, wie nicht anders erwartet, ohne besondere Vorkommnisse. Auch die Installation von Zimbra ist eigentlich ein Kinderspiel (bei CentOS sollte man allerdings gleich “./install.sh –platform-override” verwenden, man wird darauf aber auch hingewiesen, falls man doch nur install.sh aufgerufen hatte). Nur der Versand von E-Mails wollte ersteinmal nicht funktionieren. Ein Blick ins Maillog brachte allerdings schnell die Erleuchtung, es fehlte noch das Paket “file” (dank yum war aber auch das schnell installiert).

Bedienung:

Der Webclient macht einen modernen Eindruck (dank AJAX und Co). Doch er offenbart (zumindest zumindest für mich) direkt nach dem Login ein kleines Manko, so etwas wie ein Dashboard (Aktuelle Termine/Aufgaben/E-Mails als Übersucht) fehlt, man landet direkt im “E-Mail-Client”. Ansonsten hat er alles so erledigt wie ich es mir gedacht hatte.

Der nächste Versuch galt Sunbird. Der Kalender lässt sich einfach via CalDAV integrieren (Link: http://server.domain.com/dav/username/Calendar ). Es fehlen allerdings die Aufgaben. Ein Blick ins Forum half weiter. Die Aufgaben sind derzeit anscheinend nur via .ics zu bekommen, und sofern man nun also einfach einen zweiten Kalender in Sunbird anlegt hat man auch die Termine (Link: http(s)://mail.example.com/home/<user>/Tasks). Nachdem hinzufügen von ein paar Aufgaben kam allerdings schon wieder die ernüchterung. Keine der Aufgaben wollte sich im SunBird wieder löschen lassen. Aber auch dafür gibt es Abhilfe: Man ändere einfach der Status der Aufgabe auf “Cancelled” und siehe da, die Aufgabe ist verschwunden (sowohl in Sunbird als auch im WebClient).

Erstes Fazit:

Zimbra (Open Source Edition) scheint, sofern man mit dem WebClient zufrieden ist eine Runde Sache zu sein (den Desktop Client habe ich mir noch nicht angeschaut). Einfache Installation, einfache Bedienung. Die Anbindung an Sunbird ist leider nicht optimal, aber durchaus zu verschmerzen (für Thunderbird/Lightning gilt das Gleiche). Mal schauen, was die nächsten Tage/Wochen an weiteren Erkenntnissen bringt und ob Zimbra es schafft das bisher im Einsatz befindliche Scalix zu ersetzen (wobei ich da eher keine Bedenken habe).

In den letzten Tagen musste ich leider wieder einen Anstieg (> 15%) in Sachen Spammails zur Kenntnis nehmen und stelle mir so einmal mehr die Frage, was kann man denn noch dagegen tun. Mein Ansatz, mit dem Proxy als Secondary-Mailserver scheint noch immer recht brauchbar, der Spam hat hauptsächlich nur auf den nicht mit dem zusätzlichen DNS-Eintrag versehenen Domains zugenommen. Auf Freshmeat.net habe ich dann auch die Tage ein weiteres Tool für diesen Einsatzzweck gefunden: mxallowd.

mxallowd ist ein Daemon für Linux/Netfilter (via libnetfilter_queue), der eine Verfeinerung der nolisting-Methode darstellt. Hierbei werden für eine Domain zwei MX-Einträge vom Nameserver ausgeliefert, wobei auf der IP-Adresse des ersten MX-Eintrags kein Mailserver läuft. Einige Spammer versuchen nun, nur auf den ersten Mailserver Spam auszuliefern und werden damit keinen Erfolg haben. Auf der IP-Adresse des zweiten MX-Eintrags läuft dann ein richtiger Mailserver, der die E-Mails entgegennimmt. Echte Mailserver probieren – im Gegensatz zu Spammern – alle MX-Einträge in der angegeben Reihenfolge (geordnet nach Priorität) durch, bis sie die Mail zustellen können. Somit kommen echte Mails an und Spam bleibt draußen.

Der Ansatz gegenüber dem Proxy ist geringfügig anders, dürfte aufjedenfall Resourcenschonender und im Zweifelsfalle sogar etwas zuverlässiger arbeiten. Da z.b. beim Whitelisting nicht nur die anfragende IP sondern alle hinter dem DNS-Eintrag stehende IP’s auf die Liste gesetzt werden (ist bei Mailserverpools wie z.B. GMail nicht unwichtig, da könnte der nächste Versuch von einer anderen IP kommen). Kommt aufjedenfall auf meine Liste mit interessanten Tools. Nur bei meinem Problem hilft es mir auch nicht wirklich. Naja, schau mehr mal, vll. nimmt der Spam ja auch von selbst wieder ein bischen ab