Technik

Statt dem "n" in der Überschrift wollte ich eigentlich eine 2 nehmen, aber da ich mich als Mathematiker fühle und das gleich beschriebene für eine unbegrenzte Anzahl (n) Domains gilt kam ich nicht darum eine Variable einzusetzen.

Wer kennt das nicht: Man hat mehrere Domains, sei es tiggerswelt.net und tiggerswelt.eu, will aber auf allen diesen Domains die selben E-Mail-Adressen abbilden. Bisher eigentlich ein Unding, denn für jede Domain musste seperat jede E-Mail-Adresse angelegt werden.

Sei n die Anzahl der (identischen) Domains, a die Anzahl der wirklich gewollten und c die Anzahl der eingerichteten E-Mail-Adressen, so ergibt sich die wunderschöne Formel: c = n * a.
Das ganze mit Zahlen befüllt (3 Domains, 13 gewollte Adressen) ergibt dann etwas wie: 39 = 3 * 13...

Jeder sieht sofort, dass hier (n - 1) * a zuviel arbeit verrichtet werden muss - im günstigsten Fall 100% mehr Arbeit.

Genug gerechnet! Heute habe ich diesen Umstand aus der Welt geschafft!
Ab sofort kann man (wenn auch noch nicht im Webinterface) den gesamten Mailverkehr einer Domain auf eine andere umleiten.

Umleiten klingt jetzt ein wenig umständlich. Genauer gesehen ist es eine kleinere Modifikation im Resolver für E-Mail-Adressen. Klein, aber äußert effektiv!

Nachtrag:

Jetzt auch im Webinterface verfügbar!

Heute mittag habe ich auf ein neues Feature hingewiesen. In den Kommentaren hats auch schon der Chris erraten. Und nun der nächste Schritt: Wünsch Dir was!

Ich habe lange hin und her überlegt, ob ich für das neue Feature der Mailinglists auf bestehende und erprobte Lösungen wie Mailman oder Majordomo zurückgreifen soll. Eigentlich schien es mir die sichere Variante, aber die Kompatibilität gerade mit meinem Mailserver lässt mehr als zu wünschen übrig und im Falle eines Serverumzugs ist sowas immer ein großer Faktor der schief zu gehen droht.
Aus dem Grund schreibe und teste ich schon seit einiger Zeit an einer eigenen Lösung - vollkommen in mein System integriert und vollständig portabel. Ausserdem sind da die Möglichkeiten des Debuggings und der Erweiterungen viel größer. Drum die Frage an meine Leser:

Was wünscht Ihr euch von einer Mailinglist?

(Ganz nebenbei hab ich auch Angst einfach etwas zu vergessen)

Im Zuge des Log-Rewrite ziehe ich gerade 27 Millionen Datensätze um. Genauer: Ich kopiere nicht nur, ich konvertiere gleich mit. Schon seit langem habe ich die Vermutung, dass die darunterliegende Datenbank für ein solches Datenvolumen nicht wirklich gebaut ist und so ihre Problemchen damit hat und so dauert allein die Anfrage an die Tabelle mit den vielen Datensätzen schonmal mehrere Minuten - obwohl es einen wunderschönen Primary Key und 11 weitere Indizies gibt.

Zum Fluchen!

Komisch ist nur: Die Datenbank ist partitioniert, d.h. ich ziehe immer kleine Päckchen von ca. 8-10 Millionen Datensätzen um. Dabei musste mir bisher folgendes auffallen:

• In 50% der Fällen wird die reine Datenmenge mehr (zuwachs um ca. 6%)
• In den andernen 50% sinkt die reine Datenmenge ab (abnahme um ca. 4%)
• Der Index ist um 50% gewachsen und umfasst nun pro 10 Millionen Datensätzen ca. 2 GB Speicherplatz

Ich war heute schon sehr fleißig!

Nachdem ich gerade mal den Rewrite angedacht habe bin ich auch direkt zur Tat geschritten, habe die neue Tabelle und eine erste Version des neuen Apache-Moduls geschrieben. Dank der Datenbankinfrastruktur, die ich mittlerweile aufgebaut habe, war das nur ne Sache von 30 Minuten. Faszinierend!
Bis das Modul in den produktiven Betrieb geht, wird aber noch etwas Zeit vergehen und der eine oder andere Test zu bestehen sein.

Ich überlege nur, ob ich die virtuellen Hostnamen als String oder als interne ID loggen soll. Ersteres geht schneller, verbraucht aber auf dauer mehr Speicher. Letzteres braucht mehr Anfragen an die Datenbank, wird aber eher einem RDBMS treu, spart Speicher und sollte auch besser zu durchsuchen sein :hmm:

Nächste Frage: Wenn wir schon nach der Internen ID auflösen, wieso nicht gleich ACLs auf die Log-Datenbank portieren? :hmm:

Eine Killerapplikation?

Gestern Abend musste mir wieder eines auffallen: Mein Logging ist veraltet und überholt!

Es stammt noch aus der Zeit, als ich nur einen Webserver betrieb und hat sich seitdem kaum Weiterentwickelt. Seitdem sind jedoch andere Umstände gewachsen, die Anforderungen steigen stetig und die Datenmengen sowieso. So kämpft das Modul mittlerweile mit Logs im zweistelligen Gigabyte-Bereich und mit ca. 5 Anfragen pro Sekunde.

Unter hoher Last bekommt das Modul dann Panik und weiß anscheinend nicht mehr, was es tun soll. Bei einem Ausfall der Hauptdatenbank gibt es vollkommen den Geist auf.

Das ist alles eher suboptimal! Von daher habe ich mich gestern Abend dazu entschlossen ein neues Apache-Modul zum logging zu entwickeln. Gerade eben habe ich angefangen.

Eigentlich nur ein weiterer Punkt auf meiner langen langen ToDo
Wenns gut läuft bin ich nächste Woche fertig und hab ein viel geileres Logging als vorher....

Irgendwie war ich es leid immer Domain-Neuregistrierungen und -Transfers (KK) seperat zu behandeln. Deswegen habe ich einfach mal die System-Klasse, die bisher für das Monitoring von Domains und den Transfer selbiger zuständig war dahingehend erweitert, dass sie auch neue Domains registrieren und modifizieren kann.

Eigentlich mittlerweile eine richtig Runde Sache: Ich muss nur noch den begehrte Domainnamen kennen und den Rest erledigt das System für mich (wenn man mal von Spielereien wie Auth-Codes, dem Monitoring oder Trustee absieht) .

Hinzu kommt noch, dass ich endlich meine Kontaktdatenbank und nicht nur die Benutzerdatenbank an diese Klasse angeschlossen habe. Jeder Benutzer kann bei mir mehrer Kontakte haben (seien es verschiedene Adressen oder Ansprechpartner). Einer davon ist immer der primäre Kontakt der für alles (Rechnung, Whois, etc.) genutzt wird, die restlichen Kontakte blieben bisher ungenutzt. Die neue Klasse räumt auch damit endlich auf! Aus aktuellem Anlass...

Ich habe mich gerade im Internet nach Clients für den neuen DynDNS-Dienst umgeschaut, die man leicht adaptieren könnte um sich mit unserem Server zu verbinden - sonderlich weit bin ich dabei nicht gekommen, aber ich habe einige nette Ideen für Zusatzdienste gefunden:

• Smarthost zum versenden von E-Mails (AOL akzeptiert ja keine E-Mails von Servern mit dynamischer IP)
• Secondary Mailserver - für den Fall, dass der dynamische Mailserver ausfällt
• Monitoring der Internet-Verbindung

Der Smarthost zum versenden von E-Mails ist wohl schwachsinnig, da das in der Regel beim Hosting schon mit dabei ist - für Domain-Only-Kunden hingegen wieder interessant.

Letzteres aber, das Monitoring, finde ich besonders interessant! Denn ein Kunde, der am DynDNS-Dienst interessiert ist hat mich auch vor kurzem an anderer Stelle nach Monitoring gefragt. Das könnte doch bestimmt einen Sinn machen, oder nicht?

Kombiniert mit dem kleinen SMS-Dienst den ich am Laufen habe und dem "normalen" Server-Monitoring eigentlich ein recht starkes Tool und sehr leicht zu implementieren.

Wenn jemand Interesse, Ideen oder Vorschläge hat, einfach mal melden

Ach ja: Und wenn jemand nen guten DynDNS-Client kennt, wo man "*.dyndns.org" als Server-Adresse rausnehmen und meinen Server einsetzen kann, auch melden!

Heute morgen habe ich nach intensiven Tests einen neuen (wichtigen) Teil meines Systems in den produktiven Betrieb genommen:

Löschen von (Sub-)Domains - oder auch vhosts - vom Webserver.

Sicher, die Einträge aus der Apache-Konfiguration zu nehmen ist eigentlich kein Problem, nur verbleiben dann noch meist Überreste im Dateisystem. Auch ist es bei meiner Datenstruktur je nach Systemteil recht schwer mitzubekommen, wann ein Datensatz gelöscht werden muss bzw. wann Serverdienste auf den neusten Stand gebracht werden müssen.

Ich hatte vor einiger Zeit mal ein System ausgeklügelt, dass einen Datensatz als gelöscht markiert und dieser dann erst von einem Deamon richtig gelöscht wird. In Sachen Webserver-Domains habe ich das aber spontan wieder verworfen und so "erkennt" nun der Deamon, der regelmäßig das Dateisystem auf Zugriffsrechte und Verzeichnisse prüft, wenn eine Domain aus dem Webserver entfernt wurde und räumt dementsprechend auf.

Aufräumen heißt in dem Falle, dass das Webserver-Verzeichnis gesichert (als .tar.bz2 für den Kunden) anschließend gelöscht und der Webserver neu konfiguriert wird.

Auch wenn ich die neue Erweiterung recht ausgiebig getestet habe so hatte ich doch richtig viel Angst im Gesicht stehen als ich sie heute morgen auf die Server repliziert habe. Immerhin: Sie funktioniert einwandfrei!

Ich habe heute mal wieder begonnen meine DNS-Server als Datenbank zu missbrauchen - an anderer Stelle für einen anderen Dienst. Was genau ist egal und uninteressant.

Jedenfalls hat mich diese Sache veranlasst in den letzten zwei Stunden mehrere tausend DNS-Datensätze zu sichten, zu testen und aufzuräumen. Alles in allem sind ca. 40 Datensätze von mir gelöscht worden... Ich bezweifle, dass das die Sache wert war, aber immerhin habe ich jetzt die Gewissheit einen sauberes DNS-Sytem zu betreiben - auch was wert! :hmm:

Eigentlich auch gar nicht mal falsch, wenn man bedenkt, dass die Datenbank schon bald von dynamischen Domains beansprucht wird und auch die Tatsache berücksichtigt, dass ich gerade einen Online-Editor für die Domains zusammenbastle...

Ich bin mir heute quasi selbst auf den Laim gegangen...

Nachdem ich mich letzte Woche vom Königsstuhl geworfen (mir zumindest die Möglichkeit gegeben) habe, musste mir heute auffallen, dass dieser Wurf wohl ein elastischer war - immer bekam ich meine Administrationsrechte zurück sobald ich in einen anderen Teil der Webseite wechselte.

Lösung des Problems: Ich hatte vergessen explizit einen Pfad für einen Keks zu setzen, den mein System meinem Browser immer wieder spendiert hat. Das konnte ja nicht funktionieren :hmm:

So endete ich in einem heillosen Chaos aus (Admin) sein oder nicht sein. Abhilfe schaffte nur das löschen aller Cookies von ssl.tiggerswelt.net :hmm:

Und um noch mehr von dem Schmerz zu bekommen werde ich jetzt "Master-User" implementieren

Gerade beim tcpdumpen gefunden:

02:13:28.032236 arp who-has 192.168.10.145 tell 192.168.10.145

Irre ich mich oder sollte das entsprechende Endgerät das nicht selber wissen? :hmm: