Technik

In Absprache mit meinem Helferlein startet mit dem heutigen Tag der "Public Beta-Test" für unseren neuen DynDNS-Dienst. Wir suchen nun nach freiwilligen Testern, die auch gerne mal bereit sind selbst nach neuen Clienten zu suchen und diese zu testen, denn gerade ich habe z.B. ein Problem Windows-Clienten zu testen.

Den Support hierfür werde ich diesmal nicht mitmachen, sondern erledigt das ausschließlich mein Helferlein, wer ihn also mal kennenlernen will sollte mitmachen!

Für Interessierte - ganz besonders auch für Nicht-Kunden - habe ich auch gleich mal ein paar .de-Domains klar gemacht, die ich zum kostenlosen Testen für ein Jahr spendiere. (Nur DynDNS, kein Hosting, kein E-Mail)

Bei Interesse kurz eine E-Mail an mich oder das Kontakt-Formular benutzen!

Merke: Alle Regeln aus einer Firewall zu löschen, deren Standard-Regel "verbieten" ist, ist dumm.
Wisse: Noch dümmer ist es, sowas von Unterwegs zu machen!

Genau das dachte ich am Dienstag im Zug, als ich "iptables -F" auf meinem Router zu Hause im Büro ausgeführt habe und sich danach nichts mehr regte...

Ich denke dieses Erlebnis war einschneidend genug um es in Zukunft seltener zu tun...

Ich habe mir in letzter Zeit angewöhnt, immer wenn ein internet Umzug auf einen anderen Webserver geplant stattfindet ca. 24h vorher die TTL der betroffenend DNS-Datensätze extrem niedrig zu setzen - in der Regel auf eine Zeitspanne von 2 bis 5 Minuten.

Auf beiden Seiten (Client und Server) mag für diesen Zeitraum wohl etwas Performance verloren gehen, doch sehe ich hier überwiegend Vorteile, denn so ist die Ausfallzeit nach Änderung der Datensätze eher minimal und alles ist perfekt

Ich denke ich werde es in Zukunft auch bei abgehenden Domain-Transfers machen, zwar nicht gerne aber was solls. Auch ein guter Abgang ist als Dienst am Kunden zu verstehen

Hiermit erkläre ich den heutigen Tag zum World-Writeable-Day!
Oder auch Tag des Satans.

Sofern ich weiß ist ersteres ganz allein auf meinem Mist gewachsen, wenn ich irre, bitte losschreien!

Ansonsten freue ich mich auf Juli nächsten Jahres, wo es für alle nochmal ein Execute-Bit gratis, quasi für umsonst, dazu gibt.

Ich sitze gerade an einem Computer auf dem kein OpenOffice installiert ist.

Schön und gut - wirklich als Standard hat sich die Software wohl auch noch nicht durchgesetzt, auch wenn sie sich offener Standards bedient.

Da mir aber ein Interessent eine .ods (OpenDocument Spreadsheet) zugemailt hat, ich wirklich neugierig auf deren Inhalt und zu faul mir einen Reader dafür zu suchen war, habe ich die Datei einfach mal von Hand "geparsed"

Ist ja bei .ods denkbar einfach - die Datei als ZIP-Datei behandeln, entpacken und die content.xml im Editor der Wahl öffnen und loslesen...

In einer Quasi-Zusammenarbeit mit dem manitu-Support hatte ich gestern eine zündende Idee für eine kleinere Erweiterung meines Rechnungssystem.

Ich weiß nicht mehr genau, wie ich darauf gekommen bin... :hmm:

Aber wenn meine Kunden Geburtstag haben, möchte ich Ihnen an diesem Tag keine Rechnung schenken. Aus dem Grund habe ich heute morgen eine kleinere Abfrage in dem Dienst der bei mir immer die Rechnungen schreibt eingefügt, so werden Rechnungen für Geburtstagskinderkunden auf frühestens den nächsten Tag vertagt. Ist das nicht toll?`

Wobei ich mich frage, ob nicht eine Auszeit von 2 Tagen ratsam wären, damit man noch Zeit hat aufzuräumen und den Rausch auszuschlafen

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...