Technik

Seit gestern scheint die Saison der Phishing-Mails (zumindest bei uns) begonnen zu haben. Jedenfalls zieht der Virenscanner so viele Phishing-Mails wie noch nie aus dem Verkehr.

Hat das einen besonderen Grund, stehe ich einfach nur auf dem Schlauch?

Heute gab es in den frühen Morgenstunden einen Stromausfall in einem Netzwerksegments unseres Rechenzentrums in Frankfurt. Dort stehen keine Maschinen auf denen Kunden gehostet würden, allerdings Maschinen die für die Verwaltung notwendig sind - unter anderem auch der DNS-Master (der so eigentlich gar nicht zu erreichen ist)

Nach dem Ausfall schafften die DNS-Slaves (ns1-ns3) es leider nicht mehr die Verbindung wiederherzustellen, weshalb es zu einer zeitweisen Störung all unserer Domains kam.

Das Problem ist mittlerweile behoben und sollte auch in Zukunft nicht mehr in dieser Form auftreten.

MySQL als Datenbank im Hintergrund ist beim Webhosting zum Standard geworden und wird in der Regel vorausgesetzt. Auch bei uns gibt es natürlich MySQL standardmäßig zum Hosting dazu. Andernorts gibt es Wahlweise statt MySQL auch noch den OpenSource-Konkurrenten PostgreSQL. Mangels Erfahrungen mit dieser Datenbank bin ich diesen Schritt noch nie gegangen und es wird wohl noch eine Weile vergehen ehe ich ihn beschreite (auf meiner ToDo steht er nichts desto trotz).

Einen anderen Schritt in Sachen Datenbanken gehe ich indes viel früher, nämlich im Laufe des August - zumindest gehe ich in diesem Monat mit ihm an die Öffentlichkeit, die Vorbereitungen im stillen Kämmerlein laufen bereits seit April:

In ca. 2 Wochen wird das "normale" Hosting-Angebot um Angebote mit IBM's DB2 als Datenbank im Hintergrund (oder auch nur die Datenbank als Stand-Alone-Version) erweitert. Zum Einsatz wird die recht frische Version 9 mit nativem XML-Storage kommen, was wohl neben der Datenbank an sich auch ein recht großes Novum auf dem Markt sein dürfte (oder auch: ist ).
Somit ermöglichen wir es nun auch unseren Kunden beim Webhosting von einer "OpenSource Datenbank" auf eine "Business Datenbank", die eben auf diesem Gebiet eine langwierige Erfahrung vorweisen kann, zu wechseln.

Zur Zeit sind wir noch aktiv am Testen des Angebotes, wer aber vorab gerne Informationen oder eine DB2-Version auf DVD (Windows/Linux, VMWare Images, etc.) haben will kann sich gerne per Kommentar oder Mail melden.

PAM steht für Plugable Authentication Modules und ist auf Unix-Systemen eine recht weit verbreitete Methode um Benutzer zu authentifizieren - eigentlich scheint es mir die Methode schlechthin zu sein.

Ich setze bei so ziemlich allem - abgesehen von Diensten die über den Webserver laufen - ebenfalls auf PAM und habe hierfür auch ein eigenes Modul entwickelt. Nun ist dieses Modul schon recht alt und in die Tage gekommen, weshalb ich in der letzten Woche an einem neuen Modul gearbeitet habe. Seit gestern bin ich das neue Modul intensiv am testen und wollte es heute eigentlich in den Regelbetrieb übernehmen. Da das Modul auf die selben Datenstrukturen zugreift und wohlgetestet ist hätte es eigentlich funktionieren müssen, doch fiel mir in letzter Sekunde doch noch etwas auf:

Es funktioniert nicht in allen Fällen.

So kann ich das Modul schon Problemlos in die FTP-Server laden, sobald es jedoch an den MDA (Mail Delivery Agent) geht schlägt jegliche Authentifizierung fehl. :hmm: Ich frag mich so langsam, ob ich nicht doch vielleicht etwas übersehen habe. Ich glaube mir bleibt nichts anderes über als alte und neue Version einmal miteinander zu vergleichen - besonders unter dem Aspekt der exportierten Funktionen...

Ich bereite momentan das entfernen von mod_php5 aus dem Webserver - eigentlich eine ganz simple Sache: "LoadModule modules/libphp5.so" auskommentieren und neu starten.

Denkste!

Das sind Maschinen auf denen Kunden ihre Sachen hinknallen dürfen in der Hoffnung, dass dabei nichts explodiert. In weiser Vorraussicht (ohne, dass ich es auch nur ahnte) habe ich vor Monaten mein eigenes System schon dahingehend erweitert, dass es mit "<IfModule>"-Direktiven arbeitet. Aber das tut längst nicht jeder Und selbst wenn doch wäre es eine Schande, wenn auf einmal die Mühevoll gesetzten PHP-Werte weg wären - drum wird es bald einen (nahezu) kompletten php.ini-Editor geben. Vorerst nur dem Support vorbehalten, aber eine Integration ins Kundeninterface ist geplant.

Für diesen Zweck sammel ich momentan die ganzen php_values und php_flags meiner Kunden zusammen, packe sie in die Datenbank und setze die "<IfModule>"-Direktiven.

Wann mod_php jetzt komplett verschwindet vermag ich noch nicht abzuschätzen Aber spätestens in 2 Wochen.

Im Zuge der Einführung des Bloghosting-Angebotes habe ich in den letzten Wochen immermal wieder an Serendipity rumgeschrieben. Das "Problem" hierbei war, dass wir das ganze Hosting als eine Art "managed Hosting" verkaufen, die bloggenden Kunden sich also nicht um Installation, Updates etc. kümmern müssen.

Es erschien mir etwas dumm jedem Blogger ein eigenes Webroot zuzuordnen und auch die in der README angepriesene "Shared Installation" kam für mich nicht in Frage - einfach aus dem Grund, weil ich damit bisher nur negative Erfahrungen gemacht habe.
Überhaupt reagierte Serendipity bisher immer recht allergisch, wenn ich es versuchte anzufassen, weshalb die jetzige Lösung etwas mehr Hand und Fuss haben sollte. Ausserdem sollen die Benutzer auch nicht wichtige Systemeinstellungen wie etwa die Verbindung zur Datenbank oder die Systempfade ändern können.

Herausgekommen ist eine Lösung mit der zumindest ich sehr zufrieden bin: Ein Serendipity das mit einer Installation eine unbegrenzte Anzahl an virtuellen Nutzern verwalten kann, dabei den Zugriff auf bestimmte Einstellungen verwehrt und sich einfach mit einem kleinen Bash-Skript installieren lässt. Wunderbar

Vielleicht sollte ich zumindest ersteres der Serendipity-Forschung zur Verfügung stellen... :hmm:

Seinerzeit bin ich diesen Weg gegangen, weil mir da das Tor einfach zu offen stand (in Sachen Sicherheit fang ich schon beim kleinsten Windzug an zu bibbern), habe mir aber in der Zwischenzeit Alternativen ausgedacht, denn ein Dauerzustand sollte dies nicht werden und für mein Gefühl musste ich in letzter Zeit einfach zu vielen Kunden absagen, weil sie Perl (etc) haben wollten.

Heute bin ich der Lösung des Problemes ein wenig näher gekommen: Ich sperre meine Kunden ein!

In baldiger Zukunft werden die Skripte der Kunden wohl (ein wenig aufwändiger) in einem chroot-jail laufen und somit ist die Gefahr, dass sie auf irgendwelche Systemdateien (man weiß ja nie) oder Daten anderer Kunden Zugriff bekommen wesentlich geringer. In Kombination mit der neuen FastCGI-Schnittstelle, die ich momentan auf meine Server migriere, ein echter Vorteil.

Einen kleinen Vorgeschmack gibts mit einem kleinen Explorer-Skript

Manchmal wünsche ich mir hier an meinem Arbeitsplatz einen großen roten Knopf (auch Buzzer genannt) auf dem in Großbuchstaben P-A-U-S-E steht. Bei Betätigen eben dieses Buzzers würde die ganze Welt "einfrieren" und für einen Augenblick lang würde die Zeit stehen bleiben - für den Rest der Welt, aber nicht für mich, ich würde fröhlich weiter arbeiten.

... eigentlich genau wie bei diesem einen Mädel aus "Mein Vater ist ein Ausserirdischer" dessen Name mir gerade nicht einfällt. Ich glaube Yvie...

Hätte ich die Macht dies zu tun, wäre einiges sicherlich einfacher. So könnte man zum Beispiel während der Rushhour Änderungen am Webserver vornehmen, völlig frei und ohne Angst haben zu müssen, dass etwas passiert. Ich hab sie aber nicht und darum muss ich dies alles zu Zeiten wie diesen machen...

Wo stand noch die Kaffee-Maschine? :hmm:

Gestern Abend hatte ich richtigen Heißhunger auf Spam und was passierte in dem Moment: Nichts! Es ist schon ärgerlich, will man Spam nicht haben, bekommt man ihn, will man ihn jedoch haben, erlebt man eine lange Durststrecke. Danke, Murphy!

Heute morgen hab ich dann noch ein paar alte gelöschte Spams gefunden (46 an der Zahl) - auf meinem PDA. Die hab ich natürlich gleich hergenommen und in einen neuen experimentellen Ordner meiner Mailbox verschoen.

Das tolle an diesem Ordner: Es ist kein richtiger Ordner. Es ist ein Interface für sa-learn - das lustige Tool den Spam-Filter zu trainerien.

Ich verwende zur Authentifizierung beim Zugriff auf Webseiten sehr gerne PHP und HTTP Auth (auch noch in Verbindung mit HTTPS )

Aus diversen (z.T. Sicherheits-)technischen Gründen bereiten wir momentan die Umstellung der Webserver weg von mod_php5 hin zur FastCGI-Version von PHP 5 vor. Heute war ich schon drauf und dran die Migration zu kippen, denn mein heiß geliebtes Feature funktioniert per Default nicht mehr.
Abgesehen von der Tatsache, dass es von mir so geliebt ist, tue ich mich immer recht schwer damit Dinge zu entfernen, die mal funktioniert haben - denn irgendein Kunde könnte sie ja derweil benutzen.

Doch die Lösung war so einfach: Einfach den FastCGI-Wrapper mod_fcgid patchen! Abgesehen davon, dass es mit PHP nun tut, tut es rein theoretisch auch mit jeder anderen FastCGI-Anwendung...

Einen Auszug aus meinem Patch gibt es im Anhang, die orginale Datei gerne per Mail

Gestern morgen meldete sich ein Kunde bei mir und meinte, dass eine Weiterleitung nicht funktioniert. Sicherlich, diese Aussage war nicht ganz richtig, denn die Weiterleitung funktioniert nur teilweise nicht. Und eben dieses Teilweise hängt sehr stark vom Absender der E-Mail ab.

Nach ein wenig Recherche habe ich nun SPF in Verdacht schuld an der ganzen Sache zu sein, denn es scheint, dass es immer dann schief geht, sobal die Mail an die Weiterleitung von einer Domain kommt die auch einen SPF-Datensatz beherbergt.

Nachgeprüft habe ich es noch nicht, aber ich denke, dass mein Mailserver, sofern er eine Mail weiterleitet ein "MAIL FROM: absender@domain.tld" sendet und - sofern der empfangende Mailserver SPF-Checks macht - die Mail zurückweist, da mein Server z.B. keine Absender @gmx.de versenden darf.

Bleiben nun zwei Fragen: Wer sollte vorrang haben - Schutz gegen Spam und Absenderfäschung (SPF) oder die Weiterleitungen? Ich bin da ja eher für ersteres zumal ich für zweiteres schon einen Plan aushäcke, der sich auch just auf die Zweite Frage bezieht: Wie lösen wir das Problem?

Wäre es nicht sinnvoll bzw. in Anbetracht der Tatsachen angemessen beim Weiterleiten einer E-Mail ein "MAIL FROM: alias@weiterleitung.tld" (also die Adresse der Weiterleitung) zu senden anstatt des ursprünglichen "MAIL FROM: absender@domain.tld". Solange kein Bounce entsteht, funktioniert das eigentlich recht gut und ist auch Nachvollziehbar. Aber was, wenn doch ein Bounce entsteht? Wäre dann sowas wie "MAIL FROM: postmaster@anderedomain.tld" sinnvoll um die Bounces abzufangen?

Ehrlich gesagt: Die perfekte Lösung scheint es nicht zu geben oder ich habe sie noch nicht gefunden. Ich frage mich, ob da jemand dran gedacht hat, als SPF geschaffen worden ist.

Und was erzähl ich nun dem Kunden?
Eine Weiterleitung, die nur partiell funktioniert, ist wohl nicht gerade etwas, was man gerne im Portfolio hat...

Mit ASCII fing das Problem an, mit ISO-8859-X wurde es temporär gelöst, UTF-8 räumt vorerst mit allem auf - sofern wir nicht demnächst auf extra-terrestrisches Leben treffen, das gerne bereit ist mit uns zu kommunizieren (anstatt uns auszulöschen) und wir deren Zeichensatz auch noch unterstützen müssen.

Doch hat sich UTF-8 noch lange nicht als Standard durchgesetzt und somit gibt es schon mal gerne einen Zeichensalat - so passiert ist es mir gestern Abend - Mit MySQL. Ich sehe mich schon irgendwo ein wenig als Vorreiter in Sachen UTF-8, denn meine Webserver laufen schon lange auf diesem Zeichensatz. Meine neueren Datenbank-Server tun dies ebenfalls und bisher dachte ich, würde es da mit der Migration keine Probleme geben, dank individueller Festlegung der Kodierung für jede Tabelle. Doch Trugschluss!

Es kommt nicht nur auf den Zeichensatz der Tabelle an, nein, bei MySQL gibt es an anderer Stelle noch viele weitere Punkte, bei denen man auf die richtigen Angaben achten muss. So werden die Daten z.B. für die Kommunikation mit dem Client nochmal extra kodiert. Sollte man nun also von einem MySQL-Server der latin1 sprach auf einen der utf8 spricht wechseln, sollte man entweder für den gesamten Datenbankserver den Zeichensatz für Client-Verbindungen auf latin1 zurücksetzen, oder dies pro Verbindung tun:

SET character_set_client=latin1;
SET character_set_connection=latin1;
SET character_set_results=latin1;

... so sollten auch in Zukunft "alte" Anwendungen mit der neuen Datenbank laufen, während neue Anwendungen sich gleich schon mal an UTF-8 gewöhnen können.

Nachdem ich vor viel zu langer Zeit das Logging für die Statistiken abgeschaltet hatte, läuft das Logging mit dem Update der Apache-Server nun komplett über das neue System - zwar ist das ganze noch etwas langsamer als vorher, dafür ist die Basis eine wesentlich robustere und bietet auch ein kleines Stückchen mehr Komfort. In Zukunft werde ich mich also auf die Geschwindigkeit des Logging-Vorgangs konzentrieren - die keinesfalls Auswirkung auf die Geschwindigkeit des Webservers hat.

Statistiken gehen trotzdem noch nicht, da werde ich mich in den nächsten Tagen drum kümmern.

Ich fühl mich heute morgen (ein Blick auf die Uhr sagt "mittag", aber das ist mir egal.) ein wenig in die Vergangenheit zurückgesetzt, denn ich hab es schon echt lange nicht mehr gemacht.

Die Rede ist von Sprachen sprechen, die nicht meine eigene ist. In diesem Falle werden sie sogar nur recht selten von Menschen gesprochen, dafür aber von Computern untereinander sicherlich eine Milliarde mal am Tag.

Konkret heißt das für mich: FTP, HTTP, SMTP, POP3, IMAP, XMPP, IGMP und etwas was ich nicht wirklich kann aber zu erraten versuche: SSH

Der Hintergrund der ganzen Geschichte ist ein Programm zum monitoren von Servern, das ein wenig weiter geht als einfach nur Ports zu öffnen und wieder zu schließen. So kann es sich z.B. via FTP einloggen und Verzeichnisse überprüfen oder eine Testseite via HTTP abrufen.

Hinzu kommt dann noch die Möglichkeit bei Ausfall nicht nur via SMS und E-Mail sondern auch via Jabber und per Fax (!!!) informiert zu werden

Seit gestern Abend durfte ich schon mehrere dynamische Subdomains für Kunden und auch ein paar .de- und .info*-Domains für "Neukunden" / Beta-Tester registrieren. Es hällt sich in Grenzen - soll es auch - und macht schon ein wenig Spass. Schön dabei ist, dass sich der Support hierfür durchaus stark in Grenzen hällt und unsere Tester sich eigentlich komplett selbst ihren Weg durch die neue DynDNS-Welt suchen.

An dieser Stelle möchte ich vielleicht noch einmal erwähnen, dass das Kontingent an "kostenlosen Domains" nicht aus vorregistrierten Domains besteht, sondern jeder Tester seine ganz eigene Domain a la irgendwas.de bekommt. - Hat schon mehrmals Missverständnisse gegeben

Doch was genau steckt eigentlich hinter dem System, wie funktioniert das?

Im Prinzip ist unser DynDNS-Server nur ein kleineres Frontend zur bestehenden Datenbank. Jede dort liegende Zone hat ein spezielles DynDNS-Flag bekommen, welches sie über den DynDNS-Server editierbar macht und wo dann auch beliebig viele "Unterzonen" erstellt werden können.

Aus technischen Gründen sind ca. 8 Datensätze für jede Zone automatisch vorhanden:

• Der normale A-Record für die Zone selbst
• Ein Wildcard-Record für alles unterhalb der Zone
• Zwei Records für Primary und Backup MX
• Ein Record zur Weiterleitung sofern die Zone offline ist
• Drei Einträge meiner Nameserver

Alle diese Records sind immer vorhanden und werden nur bei Bedarf entsprechend (de-)aktiviert. In der Alpha-Phase des neuen Dienstes war das noch anders, da ist sehr viel mit INSERT's und DELETE's gearbeitet worden - was mir am Tag schon mal bis zu 500 neuer Zeilen in der Datenbank beschehrt hat - zumindest wenn man nach dem Primärschlüssel geht und sowas sehe ich eigentlich überhaupt nicht gerne.

Der DynDNS-Server ist nahezu 100% kompatibel mit dem Server von DynDNS.org - nur der Servername ist ein anderer, sogar die Pfade stimmen überein - und ist via HTTP und HTTPS erreichbar. In dieser Ausbauphase sind bisher keine anderen Schnittstellen geplant.

Bei einer Update-Anfrage an den Server werden alle Informationen, abgesehen von den Anmelde-Informationen, per GET in der URL übertragen - das will die Spezifikation so, wobei wir uns erlaubt haben auch POST zuzulassen. Der Server geht dann lediglich her und überprüft die Werte (recht streng) bevor er ein internes Handle für die entsprechende Zone erzeugt und die neuen Daten übernimmt.

Fertig ist der DynDNS-Dienst.
Wobei im Hintergrund noch ein ausführliches Logging (für den Support) stattfindet, das scheint aber eher unerheblich zu sein

* Ja, .info-Domains gibts auch im Kontingent...