Technik

Letzten Freitag haben wir ein Update auf unserem Jabber-Server vorgenommen, wodurch sich ein paar nette Features ergeben haben.

Eines davon ist z.B. das Abfragen des Online-Statuses in Echtzeit ohne dabei mit Jabber verbunden zu sein. da diese Informationen nicht jeder freigeben will, geht das vorerst nur für unseren Support:

http://api.tiggerswelt.net/xmpp/status/support@tiggerswelt.net

Das Ausgabe-Format ist hierbei an das "normale" presence-Format wie man es von XMPP gewöhnt ist angelehnt. Hinzu kommt noch Support für XEP 256

Auch wenn das nur ein kleiner Teil der Blogleser verstehen wird, so muss ich es doch mal hier loswerden...

AOL definiert das Datensegment ("opaque") einer BART__ID mit einer 8-Bit (1 Byte) Länge, also maximal 255 Zeichen. Ist die BART__ID nun vom Typ 2, also ein ICQ-Status-String, so ist der Inhalt ein in der Dokumentation nicht näher spezifierter "StringTLV".

Schaut man sich diesen "StringTLV" mal in der realen Welt an, so entpuppt er sich als "Array aus String16", also ein String, mit einer 16-Bit (2 Byte) Länge - die allerdings natürlich über die maximale Breite des Datensegments (wir erinnern uns: 255 Zeichen) eingeschränkt wird.

Wer hat sich das ausgedacht? :eek:

Mein Wunsch für eines der nächsten MySQL-Releases:

Benutzernamen, die auch länger als 16 Zeichen sein können!

Diese Beschränkung hat schon mehr als einmal bei Kunden für Verwunderung gesorgt...

Ich habe in der letzten Woche ein wenig mit einer Sieve-Erweiterung für unseren IMAP-Server herumexperimentiert, mit der sich E-Mails bereits ohne die Hilfe unseres Supports bereits auf dem Server sortiern lassen - sofern man eine "ManageSieve"-Schnittstelle dazu nimmt, wie es sie in meinem Test natürlich auch gab.

Gestern Nachmittag haben wir mit einem Software-Update auf den Produktiv-Systemen bereits erste Vorbereitungen für die Umsetzung in der "richtigen Welt" getroffen. Ist für den Anfang sicherlich eine Lösung für versiertere Benutzer, aber ich habe da schon ein paar Ideen, was man da in Zukunft noch draus machen könnte

Wie ich heute morgen von einem Termin mit der Straßenbahn nach Hause ins Büro fuhr, schlug ich mir an den Kopf und dachte "Mensch, hättest Du nur schon mal Deinen Rechner hochgefahren" - konkreter Hintergrund war, dass es mir schon ein wenig unter den Fingern kribbelte und ich eigentlich sofort weiterarbeiten wollte. Wie ich mit der Hand über meine Stirn rieb, hatte ich eine fixe Idee...

Man müsste Computer doch auch per SMS einschalten können!

Diese Idee fraß sich in meinen Kopf und so war es dann das erste, was ich dann am hochgefahrenen Rechner tat: Mittels Asterisk und app_sms auf einer speziellen MSN eingehende Nachrichten verarbeiten und je nach Befehl (und PIN!) einen Computer per WOL aufwecken. Oder auch - als kleines Goodie - den Status von Domains prüfen und/oder diese auch registrieren.

Das schreit nach mehr!

Ich habe heute einen Interessenten zufriedenstellen können, der unseren DDNS-Dienst mit Cisco-Hardware nutzen wollte.

Im Vorfeld hatte ich schon gefühlte hundert Stunden bei uns in die Logs geschaut und darauf gewartet eine entsprechende DDNS-Anfrage bei uns aufprallen zu sehen. Nichts. Bis mich ein Kollege des Interessenten auf den Satz "Sie sind soeben auf einem Webserver ... angekommen" aufmerksam machte.

An entsprechend falscher Stelle fand ich sofort auch einen Haufen von fehlgeleiteten DDNS-Anfragen, die nur einen schluss zuließen:

Der Client schickt in seinen HTTP-Anfragen (die er wohlgemerkt als HTTP/1.1 ausgibt) keinen Host:-Eintrag mit, sodass unser Apache kaum eine Chance hatte die DDNS-Anfragen richtig zu verarbeiten. So habe ich gestern mittag ein entsprechendes Update bei uns im System eingearbeitet, dass die Verarbeitung von DDNS-Anfragen zulässt, auch wenn kein Host übertragen wurde.

Auch wenn böse Zungen behaupten, dass es Stromverschwendung ist, so bin ich doch ein richtige Wake-On-LAN-Fan!

Abgesehen von meinem Laptop schalte ich hier mittlerweile fast alles über Netzwerk bei Bedarf ein - und dadurch dass ich es öfter auch mal wieder ausschalte wette ich, dass sich der zusätzliche Stromverbrauch für WOL wieder rechnet. Aber das war nicht immer so:

Meine Workstation weigerte sich in der Vergangenheit permanent (obwohl die Lämpchen grün waren) sich übers Netzwerk einschalten zu lassen. Ich war bisher immer nur weise genug gewesen, mal das BIOS zu checken um danach wieder zu resignieren, weil alles richtig schien und doch nichts funktionierte. Bis ich letzte Woche wieder auf das gute alte ethtool gestoßen bin - was ich eigentlich noch nie gebraucht habe. Jedoch fielen mir dort 2 Zeilen auf:

Supports Wake-on: g
Wake-on: d

Die Man-Page verrät: "Supports Wake-on" verrät welche Modi vom Adapter unterstützt werden und "Wake-on" zeigt an, welches aktuell eingestellt ist - das "d" kam mir in dem Zusammenhang gleich spanisch und falsch vor und es steht auch wirklich für "disabled". Eigentlich schon böse, dass es neben dem BIOS-Setting des Computers noch dieses kleine Flag in der Netzwerk-Karte gibt :hmm:

Der Befehl

ethtool -s eth0 wol g

hat es dann umgestellt und der Computer wacht brav nach dem Senden eines "magischen Paket" auf. Allerdings vergisst meine Maschine hier diese Einstellung bei jedem Reboot wieder (dass das immer der Fall ist wage ich gerade nicht zu schreiben), sodass ich es einfach mal in einen Start-Skript eingebaut habe

Bei einem Kunden ist vergangene Woche der Notes-Server abgestürzt.

Lustigerweise befinden sich die Kontaktdaten zu den Menschen, die da ggf. weiterhelfen könnten, in der Notes-Datenbank und alle anderen sind im Urlaub. Ich selbst habe da keinerlei Fachwissen, aber vielleicht liest hier jemand mit.

Konkret ist es so: Der Server hat über die Feiertage die Stromzufuhr verloren und Notes wurde nicht sauber herunter gefahren. Nach dem erneuten Hochfahren kommen für sämtliche (zumindest gehe ich davon aus) die Fehlermeldung:

Error checking database some_db.nsf: This database is
currently being used by someone else.  In order to share a Notes database, all
users must use a Domino Server instead of a File Server.

Diesen "someone else" gibt es aber nicht. Hat da vielleicht jemand einen Tipp?

Heute habe ich zwei kleine Produkte aus unserem Portfolio eine Symbiose eingehen lassen, indem ich unseren SMS Gateway mit unserem Jabber-Dienst verbunden habe.

Die Idee ist sicherlich nichts neues und findet schon vielerorts Anwendung (leider nicht über uns ), allerdings kann meine Implementation etwas, was ich - bis mich jemand eines besseren belehrt - als einmalig bezeichnen würde: Schicke ich über Jabber eine SMS-Nachricht raus kann der Empfänger der Nachricht mit seinem Handy auf die Nachricht per SMS antworten und die Antwort erscheint wieder bei Jabber. Ich würde das einen "Bi-Direktionalen SMS Transport" nennen oder auch "unified chatting"

Leider musste ich feststellen, dass sich die Konversationen dank lästiger SMS-Tipperei am Handy schon mal etwas hinziehen können. Kaum auszudenken was passiert, wenn das Gegenüber gerade nicht auf dem Sofa sitzt und darauf wartet zurückzuschreiben sondern wild durch die Weltgeschichte dümpelt und nicht sofort zurückschreibt. Eine echte Geduldprobe vor dem Bildschirm wie man es vom chatten sonst wohl nicht gewohnt ist.

Für den Moment ist der Gateway noch in der Testphase und steht nicht für die breite Kundschaft bereit. Aber wer weiß, was daraus noch wird

Ich weiß nicht mehr, wie wir drauf gekommen sind, aber vor nicht allzu langer Zeit saß ich mit einem Freund bei einem Kaffee zusammen und wir sprachen über Faxe. An irgendeinem Punkt warf ich ein, dass ich auf unserem Mailserver schon länger die Möglichkeit einrichten wollte mit unseren Mailboxen Fax-Nachrichten zu empfangen (oder auch zu verschicken).

Seitdem habe ich ein wenig meiner Zeit in die Umsetzung eines entsprechenden Projektes gesteckt, sodass heute Nacht ein Fax rausging.

Und ja: Der Inhalt der Nachricht stimmt! Allerdings gibt es da noch ein paar andere Fragen zu klären bevor wir weitere Details (wie z.B. Durchwahlen) veröffentlichen. Der Blog-Eintrag muss allerdings sein - immerhin weiß ich jetzt, dass ich mich noch wie ein kleines Kind freuen kann

Wir stellen unsere Webserver sowie den VPN Gateway momentan auf neue IP-Adressen um, da unsere alten IP-Bereiche nicht mehr ausgereicht haben.

Nicht ganz trivial dieses Unterfangen und so hat es leider schon in zwei Fällen "geknallt", da auch unser System eigentlich nicht für solche Aktionen ausgelegt ist, aber wie ein Kunde in diesem Zusammenhang bereits von sich aus anmerkte: "Besser als Confixx ist es sicher allemal!"

Im Laufe der nächsten Tage werden wir auf den Webservern (bis auf einen Fall, wo ich etwas versäumt habe) die alten IP-Adressen (über die aktuell auch noch das Routing läuft) komplett abschalten. Ich bin respektvoll gespannt!

Ich habe mich die Woche mit einem vielleicht etwas bösen Thema beschäftigt: Dem Sperren von säumigen Kunden.

Bisher mussten wir immer von Hand alle Dienste des Kunden raussuchen und genau so manuell sperren bzw. die Sperre wieder entfernen. Mit dem neuen System passiert das bei Bedarf ganz automatisch - sowohl für die Sperrung wie auch für die Aufhebung selbiger. Und ganz nebenbei kann der Kunde (wenn es ihn denn wirklich interessiert) in unserem Kundeninterface einsehen, seit wann eine Sperrung welcher Dienste existiert.

Es war wohl mehr so eine Art Proof of Concept, denn so wie heute werde ich sicherlich nie mehr Telefonieren:

1. SIP-Telefon an UMTS-Router angeschlossen
2. UMTS-Router ins Internet eingewählt
3. Über die UMTS-Verbindung eine VPN-Verbindung aufgebaut
4. Über die VPN-Verbindung hier auf der Telefonanlage eingebucht
5. Spezielle interne Nummer angerufen (Nein, an die kann ich niemanden weiterstellen) die ein Internet-Radio abspielt.
6. Als Krönung des ganzen: Zweite SIP-Verbindung zu mir selbst aufgebaut und eine Konferenz geschaltet

Immerhin weiß ich jetzt, dass ich relativ komfortabel 2 SIP-Verbindungen über UMTS bedienen kann

Wo ich schon heute nach ein wenig an unserem VPN Gateway gearbeitet und entsprechenden Patch schon verbloggt habe, habe ich mich heute morgen auch gleich einem anderen Projekt gewidmet:

Dynamische IP-Adressen.

Das Thema habe ich bestimmt schon ein ganzes Jahr vor mir hergeschoben, obwohl immer wieder danach gefragt worden ist. Mittlerweile bin ich schon ganz zuversichtlich und fleißig am testen. Ich hatte es mir eigentlich viel aufwändiger vorgestellt, aber das war bestimmt mal wieder zu viel Respekt vor der Arbeit....

Ich habe es mit heute Abend Nacht nicht nehmen lassen und einen kleinen Patch für OpenVPN geschrieben:

Mit der "--limit-traffic"-Option können wir jetzt in unseren OpenVPN-Servern ein Traffic-Limit für alle oder bestimmte Client-Verbindungen bestimmen. Will heißen, dass entsprechende Verbindungen automatisch beendet werden, sobald eine bestimmte Menge an Traffic über die Verbindung gegangen ist.

Ein kleinen Nachteil hat die Sache allerdings noch:

Baut der Client erneut eine Verbindung auf, wird das Limit zurückgesetzt und er kann erneut die selbe Menge an Traffic generieren. Sprich ein entsprechendes "Accounting" muss über externe Skripte gelöst werden. Wir tun das, indem wir das Limit beim Aufbau mittels --client-connect-Skript bestimmen - in Abhängigkeit von den bei Verbindungs-Abbruch (--client-disconnect) ermittelten Traffic-Daten ($bytes_received und $bytes_sent).

Wer den Skript gerne haben will findet ihn auf der Mailinglist - oder bei uns im Support (einfach fragen)