Technik

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

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)

Die meisten administrativen Aufgaben auf unseren Servern werden von sog. Daemons übernommen. Die laufen immer und wenn nicht, werden sie bei Bedarf automatisch gestartet.

Ärgerlich bzw. ein wenig lästig war das ganze immer, wenn es Neuerungen an unserem System gab: Die entsprechenden Dienste mussten alle von Hand neu gestartet werden, was natürlich ab einer entsprechenden Anzahl an Servern keinen Spass mehr macht.

Mittlerweile - und da bin ich recht stolz drauf - ist das nicht mehr so. Die Deamons überwachen sich selbst und starten sich so zum Beispiel automatisch neu, sollte im System eine neuere Version verfügbar sein. Weiter haben sie auch immer ein Auge auf ihren aktuellen Speicherverbrauch und sollte der einmal zu hoch sein (z.B. durch Memory-Leaks) räumen sie ebenfalls durch einen automatischen Neustart auf.

Hach, was ist das doch schön

Ich bin schon den ganzen Morgen etwas kribbelig, denn wir testen heute zum ersten Mal im laufenden Betrieb unser neues Backend für unsere MySQL-Datenbanken. Man sollte erwähnen, dass "neu" in diesem Zusammenhang wirklich "neu" bedeutet und nicht etwa einen Versionssprung marktiert. Bisher hatten wir keine Automatisierung für das Datenbanken-Management im System, sondern mussten auf Kundenwunsch hin jede Datenbank manuell anlegen.

Würde es eine Statistik über die konkreten Aufgaben im Support geben, würde das wohl einen der aufwändigsten Punkte markieren.

Bei diesem neuen System hatte ich ja schon bei der Vorarbeit wahnsinnigen "Respekt", der bei den ersten Tests in unserer Sandbox etwas abgeklungen ist, der aber eigentlich nur ein Klacks im Vergleich zu dem ist was ich heute durchmache.

Vollkommen unbegründet: Alles läuft bisher hervorragend und ich bin guter Dinge das entsprechende Plugin für unser Kundeninterface noch diese Woche freizugeben. Weiterhin basiert das neue Datenbank-System auf einer recht neuen Methode alle Server bei uns auf den aktuellsten Stand zu bringen - richtig spannend!

Apropo Kundeninterface...

Wärend ich neulich ein wenig über die Webseiten einiger Marktbegleiter surfte und deren Angebote studierte, kam mir eine recht zündende Idee die mich nicht mehr los lies. (Die Idee ist zwar nur eine kleine, dennoch mag ich sie hier noch nicht erwähnen)

Grundlage dieser Idee war ein IMAP-Server, allerdings konnte ich mit gängigen Implementationen nicht direkt etwas anfangen, da ich (für die Idee eben) recht einfachen Zugriff auf jede Nachricht in der Mailbox (bzw. deren Ordner) brauche. Man hätte es sicherlich irgendwie über unsere bestehende Installation modelieren können, aber das kam mir ein wenig dreckig vor.

... und so musste ich unbedingt das Rad (mal wieder) neu erfinden und habe eine eigene, recht abstrakte IMAP-Implementation (Server, kein Client) in PHP geschrieben. Der wichtigste Teil meiner Idee funktioniert bereits und das IMAP RFC 3501 wird auch schon zu sicherlich 90% erfüllt.

Nicht, dass das etwas neues wäre: Ich habe bereits wie ich 18 Jahre alt war an meiner ersten IMAP-Implementation gearbeitet, diese allerdings niemals komplettiert. Manchmal glaube ich, dass ich gelegentlich etwas zu viel Zeit habe... (was allerdings nicht stimmt) :hmm:

Auf meinem Arbeitsgerät habe ich vor zwei Wochen mal experimentell SVN-Bindings für PHP einkompiliert.

Herausgekommen ist ein kleines "Proof-of-concept": Ein Online-Browser für SVN-Repositories.

Die PHP-SVN-Bindings haben es mittlerweile auch in die Produktiv-Version unseres Systems geschafft, sind mangels Neukompilierung auf den Webservern aber noch nicht produktiv verfügbar.

In den letzten Tagen bekam ich immer per SMS bestätigt, dass meine Sandbox nun gebootet ist.

Der Webserver hatte eines der letzten System-Updates nicht überlebt und versagte beim Starten. Da wir mittlerweile konsequent automatisch jede Maschine testen, die auch nur den Hauch eines Webservers vermuten lässt, schlug hier sofort das Monitoring zu und informierte mich über den toten Indianer.

Ich weiß nicht so recht, ob früher doch alles besser war, wo man explizit bestimmen musste, welche Maschine überwacht wird und welche nicht. Letzten Endes haben mich die SMS-Kosten, auch wenn es nur ein paar Cent waren, mich dann doch dazu beworgen den Webserver in der Sandbox mal zu reparieren.

Heute morgen habe ich in unserem internen Wiki meine aktuelle Arbeit dokumentiert und in einem Artikel zu einer neuen "Technologie" angeregt mittels einer recht kleinen Erweiterung in Zukunft alle Objekte, die wir so im System haben, zu versionieren...

Damit könnte man dann z.B. einen Webserver (resp. Virtual Host) auf den Stand vor zwei Wochen bringen - obs was bringt? :hmm:

Gestern saß ich mal wieder vor dem Bildschirm und bastelte fleißig an einer Verbesserung unseres Administrations-Backend.

Irgendwann merkte ich, dass ich gar nicht mehr so bei der Sache bin und mich eigentlich um das aktuelle Projekt herumdrücke. Anscheinend hatte ich wohl ein wenig zu viel Respekt vor der Aufgabe - zu unrecht: Menschen sterben hierbei sowieso nicht und kaputt machen konnte ich auch nichts.

Schlussendlich habe ich die Augen zu gemacht und dann alles in ca. 10 Minuten fertig gemacht - hautpsache vorher 40 Minuten verschwendet.... :eek:

Ich musste gerade schon ein wenig über mich selbst schmunzeln, wie ich in einer E-Mail schrieb:

[...] daher kann sich der gefühlte Umzug noch ein wenig [...]

Ein "gefühlter Umzug"? :hmm:

Tatsächlich ist es ja wirklich so und wurde von mir soweit ich weiß hier auch schon mal thematisiert: Ändert sich das Ziel (die IP-Adresse) einer Domain, so bekommt das im Internet nicht jeder sofort mit, da diese Einträge zwischengespeichert werden. Somit kann die Webseite bereits längst auf dem neuen Server verweilen, der Besucher "fühlt" sie aber noch auf der alten Maschine.

Wir versuchen dem immer vorweg zu greifen, indem wir bereits ein paar Stunden vor dem eigentlichen Umzug die Lebensdauer von DNS-Datensätzen (eben die Zeit, wie lange sie zwischengespeichert werden) drastisch verkürzen. Allerdings ist das bei kurzfristigen Aktionen nicht immer möglich, sodass der "gefühlte Umzug" meist weit hinter dem eigentlichen Umzug liegt. Weiterhin wird die entsprechende Webseite - sofern es denn ein interner Umzug ist - noch bis zu 24h auf der alten Maschine vorgehalten.

Besonders schlimm ist der "gefühlte Umzug" wohl immer für die Mütter und Väter der jeweiligen Webseiten, denn die haben die Seite meist erst vor kurzem aufgerufen und müssen dementsprechend viiiieeelll länger warten.