Technik

Wir bieten nun ja schon etwas länger den "#shared"-Namespace auf unserem IMAP-Server an, der eine gemeinsame Mailbox bzw. ein gemeinsames Verzeichnis für alle Benutzerkonten eines Kunden darstellt.

Natürlich gibt es über die Nutzung dieses "Angebotes" keine Statistik, aber ich weiß aus direkten Gesprächen mit Kunden, dass dieses Feature Zustimmung findet und mitunter rege genutzt wird. Was immer wieder als Erweiterungs-Wunsch aufkam, war eine ähnliche Lösung verwenden zu können, wie wir es auch bei uns im Support tun:

Für normale Kunden ist der "#shared"-Namespace nur über IMAP zu erreichen, d.h. ankommende E-Mails gelangen zunächst in eine reguläre Mailbox und müssen von deren Benutzer umsortiert werden. Bei uns selbst kommen aber E-Mails an die üblichen Adressen wie info@ und support@ direkt im "#shared"-Namespace an und sind sofort für alle sichtbar.

Ich habe heute morgen einen Patch im Backend eingespielt, der es erlaubt eine Mailbox als "gemeinsames Ziel" zu definieren. Die Möglichkeiten, die sich hierdurch ergeben sind vielfältig:
Zum einen löst es das oben genannte Problem und fortan kann nun jeder eine direkte Zustellung in den "#shared"-Namespace veranlassen. Auf der anderen Seite kann nun auch direkt, quasi dediziert auf den "#shared"-Namespace zugegriffen werden und das auch mit mehreren Benutzern gleichzeitig. Wie sinnvoll letztere Möglichkeiten sind weiß ich noch nicht, aber auf jeden Fall geht es nun und wird auch nicht künstlich von uns unterbunden.

Damit unsere Kunden die Einstellungen selbst vornehmen können bedarf es aber noch der Dokumentation und einem Patch für unser Frontend. Letzteres reiht sich in einen größeren Prozess der Überarbeitung ein und wird daher wohl noch etwas auf sich warten lassen - bis dahin machen wir das natürlich gerne von Hand

Ich habe mittlerweile das eine oder andere mal unsere geplante Sieve-Implementation hier im Blog erwähnt.

Bisher hatte das ganze ja noch einen "nicht Produktiv"-Stempel oben drauf, funktioniert aber bis auf einen kleinen (aber wichtigen) Ausfall recht reibungslos. Wir sind heute den Weg gegangen und haben das Backend für Sieve automatisiert, somit kann der Kunde nun theoretisch selbst bestimmen, ob seine Mails den "klassischen" Weg oder den über Sieve + ManageSieve nehmen sollen - wenn er das passende Frontend hätte

In unserem neuen Rechenzentrum bekommen wir nur noch einen entsprechend schnellen Uplink-Port gestellt, alles andere fällt dann zum ersten Mal komplett in unsere Hand. Für mich stellt sich da die Frage, was für Switches wir dort hinstellen sollen - das fängt bei der "banalen" Frage nach dem Herrsteller an und hört natürlich bei der Leistungsfähigkeit bzw. den minimal gewünschten Merkmalen der Geräte auf.

Ersteres lässt sich recht schnell auf 2-3 Herrsteller herunterbrechen. Im professionellen Bereich gibt es hierzu bekanntlich recht einschlägige Meinungen. Bei der Suche nach zweiterem habe ich auch schon eine Liste die z.B. 5 IEEE-Standards definiert - aber immer wenn ich danach suche fällt mir auf, dass kaum ein Lieferant hier über bequeme Suchfunktion verfügt da hilft oftmals nur der Griff zum Telefon, wenn überhaupt :hmm:

Ich habe vorgestern die eigentlich für letzte Woche geplanten Änderungen an unserem Domainsystem nachgeholt.

Wir können nun endlich wieder Domains sauber aus dem System löschen. Der Grund dafür war weniger die Einführung des neuen Systems für Domains, sondern eher die schon länger zurückliegende Änderung am Webhosting-System die es z.B. auch Kunden erlaubt Webserver zu löschen.

Da wir in einem verteilten System arbeiten galt es hier endlich einmal die verschiedenen Realitäten der Webserver zu berücksichtigen. Selbiges gilt natürlich auch für Domains.

Mein heutiger Arbeitsplan sah es eigentlich sowieso vor, wieder etwas an unserer Domain-Verwatlungs-Software zu tun. Die neue Version läuft zwar mittlerweile richtig schön rund, aber ein paar Ecken und Kanten hat sie dann doch noch.

Nachdem ich aber gerade von unserem Domain-Vorhändler angerufen worden bin und wir einen kleinen Plausch über die neuen zweistelligen .de-Domains, die Chancen eine solche zu bekommen (siehe auch beim Hostblogger) und deren darauf folgenden Wert hatten, habe ich meine Pläne die Anpassungen betreffend etwas abgeändert.

Wir werden uns wohl am Run auf die knapp 1400 Domains beteiligen, allerdings ohne dass ich mir da viele Hoffnungen machen würde - genau genommen mache ich mir überhaupt keine. Für mich gibt es nur zwei wesentliche Gründe: Seit Freitag läuft unsere Mailbox mit Kundenanfragen bzgl. dieser kurzen Domains über - es besteht also ein massives Interesse auf Kundenseite es zu versuchen und was für ein Dienstleister wären wir, wenn wir uns dem nicht beugen würden? Auf der anderen Seite bin ich persönlich noch von der Einführung der .eu-Domains gebranntmarkt - ich wollte diese Arbeit immer schon mal automatisieren

Ich muss teilweise meine Kritik an manchen Dingen im ICQ-Protokoll zurücknehmen.

Wie ich vorletzte Nacht herausfand ist der hier erwähnte "StringTLV" kein Array aus "String16", sondern vielmehr ein Array aus "String08", wobei das erste Element wohl immer leer ist und die Testfälle darmals wohl nur ein Element enthielten oder gerade perfekt passten (wennglich sie auch böse \0-Sequenzen enthielten).

Mit dem String08 macht das schon etwas mehr Sinn, wenngleich die maximale Länge des Arrays auf 255 Zeichen begrenzt bleibt. Bleibt die Frage, was die einzelnen Elemente im Array meinen. Im Falle des "ICQ-Status-String", ist das zweite Element immer der eigentliche "Status-String"; hat das Array noch ein 6. Element, so representierte es bisher immer die Zeichenkodierung (z.B. "iso-8859-1") des zweiten Elements, standard hierfür ist "utf-8". Die restlichen Elemente waren bei meinen Beobachtungen immer leer.

Eigentlich hatte ich gestern gar nicht vor Geld auszugeben, aber als Heise dann von der neuen Liebe zwischen Asterisk und Skype geschrieben hat, wollte ich es zumindest mal ausprobiert haben, zumal ich schon mehrere Versuche in diese Richtung unternommen habe.

Nachdem ich gestern mittag dann direkt ein paar Lizenzen bestellt habe, kam noch am selben Abend der Lizenzschlüssel - sehr passend, denn während der normalen Arbeitszeit wollte ich eigentlich nicht an der Telefonanlage gebastelt haben. Ein weiteres Problem war, dass Digium seine Lizenzen sehr Hardware-nah ausstellt. So sind in der finalen Lizenz z.B. die MAC-Adressen der im System vorhandenen Netzwerk-Adapter vermerkt.

Grund genug für mich das ganze in einem virutalisierten Container zu tun und mittels IAX2 an die eigentliche Telefonanlage zu koppeln - letztere läuft noch auf dem physischen Host, nicht zuletzt um Zugriff auf die BRIs zu haben.

Stolpersteine sind mir beim Setup eigentlich keine in den Weg gekommen. Einzig zu beachten ist, dass die Skype-Benutzer über Skype's "Business Control Panel" angelegt werden müssen, d.h. es reicht nicht aus bestehende Benutzer einfach hinzuzufügen. Ansonsten musste ich nicht mehr machen, als ein paar Pfade anzupassen, den Channel-Treiber zu kompilieren und die Konfigurationsdatei entsprechend anzupassen.

Funktioniert auf Anhieb perfekt! Ein Traum...

Das Problem mit meiner Laptop-Tastatur ist wirklich zu einer Plage geworden. Zwischenzeitlich ist mir sogar eine Taste entgegen gekommen und zwei andere, darunter auch das böse "e" machten andeutungen sie wollten es auch tun. Genug des Geizes dachte ich mir!

Letzte Woche habe ich dann zwei neue Tastaturen für meinen Laptop bestellt. Eine zum sofort einbauen und die andere weil ich meinen Umgang mit meinen Sachen kenne. Eigentlich hatte man mir eine Lieferzeit von zwei Wochen zugesagt, nach zwei Tagen jedoch schon stand der Postbote für der Tür.

Herrlich! So schön war das Tippen auf dem Laptop schon ewig nicht mehr. Und mit dieser neuen Tastatur sieht er wieder aus als hätte ich das ganze Gerät gestern erst neu gekauft (und billiger als 72 EUR waren die Tastaturen auch noch)

Mit solchen News startet man nicht gerne in den Tag:

Kritische Lücke im Linux-Kernel betrifft alle Versionen seit 2001

Mit einem gefühlten "schon wieder" - wobei Linux da eigentlich im großen und ganzen recht Wartungsfreundlich ist. Den morgen durfte ich also damit verbringen eine kleine Test-Applikation zu entwickeln, auf die Server zu verteilen und Kernel-Updates einzuspielen. Zwischenzeitlich etwas ätzend, aber zum einen empfinde ich sowas als Chefsache und das Gefühl, nachdem man die letzte Maschine abgefertigt hat, ist einfach gut

Also zurück zur eigentlichen ToDo.

Gestern Abend habe ich mir hier in Stuttgart u.a. einen Vortrag von jemandem aus der suckless.org-Community angehört der darüber referierte, wie ein Webbrowser wirklich sein sollte, wenn er endlich der UNIX-Philosophie folgt.

In seinem Vortrag ging er immer wieder auf "SLoC" ein und stellte es u.a. wohl auch immer als Qualitätsmerkmal einer Software dar. So ganz beipflichten wollte ich ihm da gestern schon nicht, aber natürlich hat er recht, wenn er behauptet je weniger Programmcode eine Software hat, desto weniger Fehler können darin enthalten sein.

Aus purer Neugier habe ich heute morgen mal die "SLoC" der von uns fürs Webhosting entwickelten Software und derer Libraries (aber auch nur die, die ebenfalls von uns stammen) gemessen und ich komme auf 75 "KLoC" :eek:

Vielleicht doch etwas viel - wobei anzumerken ist, dass es sich hierbei um eine "physische" Messung handelt, ich also die realen Zeilen inklusive Kommentare gezählt habe und das Verhältnis von Code zu Kommentar bei uns dank strenger interner Richtlinien mindestens 50:50 liegt (eher mehr Kommentare). Mit in der Zählung ist auch unser neues Domain-System, was allein schon mit 4 "KLoC" zu buche schlägt.

Zwar finden momentan die meisten Arbeiten für unsere neue Domain-Verwaltungs-Software im Backend statt, ein komplett neues Frontend wird es aber auch geben und wenn wir gerade mal im Backend auf z.B. einen Transfer (oder ein Event von diesem) warten, wird auch am Frontend kräftig gearbeitet.

Aus der Sicht des Kunden gibt es dazu dann ein komplett neues Konfigurations-Widget, das neben einer neuen Domain-Übersicht (samt DNS-Editor) natürlich auch einen Überblick über die aktuellen Transfers gibt. Bei letzterem ist für ganz neugierige auch ein Protokoll hinzu gekommen, was jederzeit Informationen über den aktuellen Status bzw. den Verlauf des Transfers gibt. (Bei der gezeigten .de-Domain sicherlich etwas langweilig)

Letzte Woche Montag bereits haben wir bei uns ein Update eingespielt, das mir eigentlich schon seit Februar sehr am Herzen lag, die meiste Zeit jedoch nur auf dem Papier existierte - bis wir uns dann doch ein Herz gefasst haben und den VPN Gateway einem "kleinen" Update unterzogen haben.

Eigentlich ist der Link auf die Webseite recht blöd. Denn nach außen hin hat sich nicht nichts verändert. :hmm:
Nach innen dafür um so mehr:

Wir haben die Untersützung für dynamische IP-Adressen und mehrere Zugänge unterhalb eines Kunden verbessert, so gibt es jetzt z.B. auch eine Aufsplittung zwischen "globaler" und "individueller" (Zugangs-bezogener) Firewall - selbiges gilt auch für die Traffic-Übersicht - und auch lassen sich zusätzliche IP-Adressen mit einem Klick auf einen anderen VPN Gateway-Zugang routen. Als kleines Add-On können die Reverse-DNS-Einträge direkt im Kundeninterface geändert werden.

Neben dem Tor-Gateway bieten wir jetzt auch eine "gemeinsame IP-Adresse" an, die sich alle Kunden teilen und über die selektiv oder auch der gesamte Traffic eines VPN Gateway Accounts geleitet bzw. anonymisiert werden kann.

Vom alten Kundeninterface ist dazu nichts mehr übrig geblieben:

Wir haben seit heute in unserem Kundeninterface eine neue Verwaltung für E-Mail-Adressen.

Ich bin gerade allerdings aufm Sprung, daher später mehr.

Eigentlich wollte ich diesen Beitrag mit etwas anderem betitel, zum Beispiel "Pidgin-Hass" - allerdings trifft das "Problem" ebenso auf Trilian zu:

Ich hab mich schon eine ganze Zeit lang gewundert, warum ich bei ICQ keinen Trilian- oder Pidgin-Benutzer erreiche - diese konnten mir immer schreiben, aber meine Nachrichten verliefen sich im nichts.

Gestern Abend lies ich mal den Proxy gegen Pidgin laufen und konnte zumindest feststellen, dass meine Nachrichten an Pidgin weitergeleitet werden, nur der wollte damit wohl nichts anfangen. In mühsamer Kleinarbeit fand ich heraus, dass Pidgin gerne ein IM_CAPABILITY-TLV in der Nachricht hätte...

... den sollte es bekommen! Allerdings hängte ich ihn ans Ende der Nachricht an, was immerhin dazu führte, dass Pidgin nur leere Nachrichten anzeigt. Ungläubig verschob ich den Eintrag an den Anfang der Nachricht und es funktionierte. :eek:

Heute morgen habe ich im Pidgin-Code (libpurple/protocols/oscar/family_icbm.c) das Verhalten noch verifizieren können: Der Pidgin-Entwickler erwartet hier wirklich eine statische Reihenfolge aus TLV 0x0501 und 0x0101. :eek:

Besonders interessant fand ich dann auch den Umstand, dass Trilian sofort lief nachdem es mit Pidgin nun wieder funktionierte.

Ein Kunde schrieb vor einiger Zeit, dass er ausversehen des öfteren im Webmail unverschlüsselt E-Mails liest - einfach, weil er vergisst https statt http zu schreiben - und bat um Abhilfe.

Kann er natürlich haben! Nur habe ich es nicht eingesehen extra dafür auf den Webserver zu gehen und eine neue Regel in den Webserver einzupflegen. Aus sehr alten Zeiten gab es bei uns bereits zwei SSL-Modi in denen man bei uns einen vHost-Eintrag mit SSL betrieben konnte: Gemischter Modus (hier wird der Webserver gleichermaßen mit wie auch ohne SSL erreicht) und den expliziten Modus (hier kann der Webserver ausschließlich per SSL erreicht werden).

Letzteres war mal gut gemeint, war aber eher ein experimentelles Feature und hat sich in der Realität eigentlich nie bewährt. Seit heute gibt es auch einen "erzwungenen Modus", wobei Anfragen, die per HTTP (also ohne SSL) kurzerhand auf HTTPS umgebogen werden und die Verbindung fortan verschlüsselt wird. Einstellbar für alle Webserver mit SSL-Support.

War zwar ein wenig mehr Arbeit, aber das wars wert