Technik

Wir hatten gestern nachmittag einen Ausfall im Storage-System. Mail ist seit irgendwann vor 18:00 Uhr wieder verfügbar, die anderen Dienste seit ca. 22:00 Uhr.

Ein zweiter Storage Server steht seit ungefähr einer Woche im Rack, wir konnten ihn auf Grund fehlender Hardware leider noch nicht in Betrieb nehmen. In den nächsten Wochen wird es dann redundanten Storage geben, was Probleme wie heute hoffentlich in die Vergangenheit verbannt.

Am Samstag abend wurde bei der Migration von einigen Virtuellen Maschinen auf ein neues iSCSI Storage System der IMAP Server neu gestartet.

Unter normalen Umständen wäre der Mailserver nach ca. 2 Minuten wieder erreichbar gewesen. Allerdings wurde nicht daran gedacht, dass nach einer Laufzeit von mehreren Monaten beim Neustart automatisch das Filesystem auf Fehler überprüft wird.

Diese Fehlerprüfung (fsck) läuft aufgrund der hohen Anzahl an Dateien leider noch immer. Bis diese abgeschlossen ist, ist der IMAP Server nicht erreichbar.

UPDATE2: Die IMAP und POP3 sind seit dem 24. Januar 2010 21:50 wieder wie gewohnt erreichbar. Der Filesystemcheck hat bis Sonntag Mittag angedauert. Die restliche Zeit haben wir damit verbracht sicherzustellen dass keine Mails verloren gegangen sind.
Entgegen des ursprünglichen Updates haben wir den Spool nicht neu erzeugt. D.h. sämtliche IDs der Mails sind gleichgeblieben.

Im moment werden die am Samstag und Sonntag zwischengespeicherten Mails zugestellt. Dies kann noch ein klein wenig dauern, Mails vom Wochenende sind aber nicht verlorengegangen.

UPDATE: Da die Überprüfung des Dateisystems _immer_ noch andauert (GRRRR!) werden wir wohl einen leeren Spool initialisieren damit auf Mails wieder zugegriffen werden kann.

Nach Ablauf des fsck werden wir dann die beiden Spools wieder konsolidieren indem wir die Mails einzeln von einem Spool in den anderen kopieren und anschliessend die entsprechenden Datenbanken neu erzeugen.

Solltet Ihr Eure eMails nicht nur auf dem IMAP Server sondern auch offline auf Euren Rechnern zu Hause haben, so solltet Ihr eine Kopie Eurer lokalen Daten vorsichtshalber anlegen. Manche eMail Clients löschen gerne einfach mal den gesamten Cache wenn sich die Datenbank auf dem IMAP Server ändert. Mit der Sicherheitskopie habt Ihr für diesen Fall wenigstens eine Kopie.

Angeregt durch den Admin-Stammtisch und diverse Gespräche im IRC habe ich vor ein paar Tagen angefangen einen Trac/Subversion Server zu bauen.

Wir wollen damit drei Fliegen mit einer Klappe Schlagen:

1. Wir wollen Repositories, Ticket System und was man sonst noch so braucht um die für Bawue.Net entwickelte Software (Munin Plugins, Sync Scripte, Automatische Konfigurationssysteme, was auch immer) als Open Source zu veröffentlichen.


2. Wir wollen die Möglichkeit haben, die Infrastruktur für spezielle Projekte mit Zugriffsrechten zu versehen, um Bawue.Net interne und nicht zur Veröffentlichung geeignete Software zu verwalten (Easy, Homepage, My, andere sehr stark auf Bawue.Net zugeschnittene Software).


3. Wir wollen unseren Kunden die Infrastruktur für eigene Projekte anbieten.

Im Moment existiert ein Subversion Server unter svn.bawue.org und der Trac Server unter trac.bawue.org. Die Dienste sind nur per https erreichbar (d.h. SSL verschlüsselt). Wir haben mit absicht die Domain bawue.org gewählt, um unter diesem Namen (unter dieser "Marke") den Open Source Bereich von Bawue.Net zu präsentieren.

Obwohl der Grundstein gelegt ist, gibt es noch viel zu tun:

• Bisher unterstützen wir nur Subversion, andere Versionsverwaltungssysteme können aber noch hinzugefügt werden. In erster Linie denke ich da an Git, aber auch Bazaar oder Monotone sind möglich.


• Trac Schaut schon recht gut aus, allerdings würden wir gerne einen eigenen Skin verwenden um Bawue.Net mehr in den Vordergrund zu rücken.


• Die Authentifizierung muss bisher komplett von Hand konfiguriert werden. ausserdem müssen Repositories im Subversion und Projekte im Trac vom Hand erstellt werden. Dies soll an die Bawue.Net Infrastruktur angepasst werden und automatisiert geschehen.

Für die Admins unter euch gibt es mehr im Admin Wiki, mit Details zur Implementierung (wir haben übrigens mod_wsgi verwendet) und einer ausführlicheren ToDo Liste.

Falls jemand von euch ein Subversion Repository und Trac Projekt haben will, bitte einfach eine Email an die Admin Mailingliste senden. Falls ein anderes Versionskontrollsystem benötigt wird, kann eine Anfrage an die oben genannte Liste die Umsetzung beschleunigen.