Für den üblichen Client-PC ist es nicht weiter problematisch, wenn die Systemuhr nicht auf die Sekunde genau gestellt ist. Auf Servern möchte man aber exaktere Uhrzeiten, z.B. damit zeitlich abgestimmte Prozesse in einem Serververbund korrekt ablaufen oder aber clusterweit einheitliche Zeiten in den Logfiles sichergestellt sind.

Windows bietet zwar seit Version 5.1 (XP bzw. Server 2003) einen integrierten NTP-Client und -Server an, der jedoch in den aktuellen Windows-Versionen leider ab Werk derart fehlkonfiguriert ist, dass er für verlässliche Zeitsynchronisation nicht brauchbar ist: Auf Standalone PCs und Server (d.h. keine Windows-Domain) wird der Dienst nicht automatisch sondern nur einmal wöchentlich per Taskplaner gestartet. Selbst wenn man ihn auf automatischen Start umstellt, beendet er sich i.d.R. danach wieder selbst. Mit wenigen Zeilen auf der Shell bringt man ihm aber wieder eine brauchbare Funktion bei.

Folgendes Script führt der Reihe nach die nötigen Schritte durch:

net stop w32time
reg add HKLM\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpClient \
    /v SpecialPollInterval /t REG_DWORD /d 86400 /f
sc triggerinfo w32time delete
sc config w32time start= Auto
net start w32time
w32tm /config /manualpeerlist:"0.de.pool.ntp.org,0x9 1.de.pool.ntp.org,0x9 \
    2.de.pool.ntp.org,0x9 3.de.pool.ntp.org,0x9" /syncfromflags:manual /update
w32tm /resync

• Der Dienst wird gestoppt (falls er wider erwarten doch gerade läuft).
• Das Poll-Interval wird von 7 Tagen auf 24 Stunden reduziert.
• Die Dienste-Trigger, die den Dienst außerhalb von Windows-Domains stoppen, werden gelöscht.
• Der automatische Dienst-Start wird aktiviert und…
• …der Dienst gestartet.
• Die de-Pool NTP-Server werden konfiguriert.
• Ein sofortiger Resync der Zeit wird ausgelöst.

Als kleine Batchdatei abgelegt kann man damit neu einzurichtende PCs oder Server schnell mit brauchbarer NTP-Synchronisation ausstatten oder den Aufruf sogar in einen automatischen Installationsprozess integrieren.

Nachdem es mir bei fast jedem Serverumzug wieder passiert, schreibe ich es doch mal so auf, dass ich mich beim nächsten Mal erinnere, es finde oder zumindest Google es findet:

Gegeben ist ein Debian/Postfix/Cyrus-Virtual-User-Setup mit MySQL-Datenbank und Authentifikation über saslauthd. Dass Debian in einem „chroot jail“ läuft und man daher das saslauthd-Socket in /etc/default/saslauthd von /var/run/saslauthd nach /var/spool/postfix/var/run/saslauthd umbiegen muss (und die entsprechenden Verzeichnisse mit passenden Berechtigungen auch anlegen sollte), daran habe ich mich mittlerweile gewöhnt. Was ich jedoch regelmäßig vergesse, ist, dass man dann auch /var/run/saslauthd als Symlink auf /var/spool/postfix/var/run/saslauthd anlegen sollten… sonst kann man sich herrlich lang die Finger wund suchen.

Für elegantere Lösungen bin ich jederzeit offen.

Update 02.03.2014:

Bei Debian Wheezy ist der Symlink von /var/run/saslauthd nach /var/spool/postfix/var/run/saslauthd nach jedem Reboot wieder weg, weil /var/run seinerseits nur noch ein Link auf /run ist, was wiederum als tmpfs nach jedem Neustart leer ist. Am besten legt man sich in /etc/rc.local eine Zeile an, die den Symlink wiederherstellt.

Für elegantere Lösungen auch dafür bin ich offen.

In meinem Bekanntenkreis bin ich einer der wenigen der (auch) Postfix mit Cyrus einsetzt – die geläufigere Kombination ist dort wohl Exim mit Dovecot. Mit Postfix habe ich bisher keine negativen Erfahrungen mit Cyrus war das auch so bis mir neulich eine etwas ältere Installation Spaß bereiten wollte.

20. Dezember

Es trudeln Meldungen zweier User ein, dass sich das Webmail komisch verhalte. Der Mailabruf per POP3 oder IMAP4 ist nicht komplett ausgefallen jedoch führt ein EXPUNGE zu Ende der TCP-Connection… und das Webmail möchte beim öffnen eines Ordner erstmal ein EXPUNGE ausführen. Im Logfile äußerst sich das so:

cyrus/master[7067]: service imap pid 8873 in BUSY state: terminated abnormally

Später gesellen sich noch Meldungen folgender Art dazu:

cyrus/imaps[11644]: DBERROR db4: 24 lockers

Okay, führe ich also ein manuelles Recovery der Cyrus-Datenbanken durch und… nichts ändert sich. Eine Recherche bei Google nach der ersten Fehlermeldung führt zu der Empfehlung Cyrus upzudaten und der Einheizkater schließt sich dieser Empfehlung an. Kommt mir zwar komisch vor, wo es doch bis vor wenigen Stunden noch funktioniert hat, aber in meiner Ratlosigkeit versuche ich das und… es funktioniert wieder.

Damit war das Thema für mich erstmal erledigt, doch es sollte wieder auf meinen Tisch zurückkommen.

22. Dezember

Wir fahren über die Weihnachtsfeiertage zur schwäbischen Verwandschaft. Dort angekommen fehlt mir die Motivation nochmal den Rechner anzuwerfen, daher merke ich erstmal nicht, dass bei Cyrus schon wieder etwas im Argen ist. Im Logfile finde ich später Meldungen folgender Art:

couldn't connect to lmtpd: Connection timed out_ 421 4.3.0 deliver: couldn't connect to lmtpd_

23. Dezember

Nagios begrüßt mich mit zwei Mails, der POP3- und IMAP4-Dienst seien gegen 5:23 ausgefallen. Zu der Zeit findet ein täglicher Restart der Cyrus-Dienste statt um liegengebliebene Prozesse – die leider bei TLS/SSL-verschlüsselten Sessions häufig auftreten – abzuräumen. Ich schaue dem System in die Eingeweide und stelle fest, dass ein cyr_expire-Prozess beinahe alle CPU-Leistung auffrisst aber nichts tut. Nach einem Versuch Cyrus per Restart zu motivieren finde ich das hier im Log:

cyrus/cyr_expire[19078]: DBERROR db4: PANIC: fatal region error detected; run recovery
cyrus/cyr_expire[19078]: DBERROR: critical database situation

Aha, das erinnert mich wieder an die Meldungen vom 20. Dezember. Also nochmal ein manuelles Recovery versucht, leider wieder ohne Verbesserung. Nach etwas Recherche wird mir klar dass cyr_expire sich um deliver.db bearbeitet, das normale Recovery jedoch mailboxes.db und annotations.db repariert. Da ich nichts finde, dass mir für eine Reparatur der deliver.db gedacht erscheint, benenne ich die Datei um und starte Cyrus ein weiteres Mal neu und… siehe da: Es läuft wieder.

26. Dezember

Wieder beglückt mich Nagios mit zwei Mails am Morgen. Der Server war von ca. 23:20 bis 01:10 nicht erreichbar. Nach einem Blick im Logfile ist er in der Zeit tatsächlich tot gewesen, wurde um 01:10 wieder gestartet und um 03:20 nochmals. Ich vermute einen kleinen Stromausfall in einem Teil des beheimatenden RZ. Mal sehen was der Betreiber dazu sagt. Nach obigen Cyrus-Incidents und einem unpuscheligen Bootsektor Anfang des Monats wünsche ich mir etwas Ruhe an dieser Baustelle.

Im Gegensatz zu den Karlsruher Mitbewerbern bietet Hetzner bei seinen dedizierten Servern keine serielle Konsole mit an. Zwar benötigt man dieses Feature nicht wirklich oft, praktisch ist es aber dennoch, wenn man ein Unwohlbefinden des Servers beim Bootvorgang genauer untersuchen möchte bzw. auch einfach nach einem Systemupgrade den Bootvorgang miterleben will.

Als Ersatz gibt es bei Hetzner schon längere auf Anfrage stundenweise die sogenannte LARA, die ich bisher zum Glück nicht gebraucht habe. Die LARA wird an die Keyboard-, Video- und Mouse-Anschlüsse angeschlossen und bietet dem Kunden dann über ein Java-Applet Zugriff auf seinen Server. Damit hat man sogar etwas mehr Möglichkeiten als mit einer seriellen Konsole, da man mit der LARA auch den Bootvorgang boch vor dem Bootloader beobachten kann. Im Notfall muss man aber erst eine Supportanfrage absetzen und drauf hoffen, dass zeitnah eine LARA verfügbar ist.

Als Zwischenlösung gibt es seit etwas über einem Jahr auch VKVM bei Hetzner. Dabei wird der Server über das Netzwerk in ein Rescue-System geboot und darin eine VM gestartet, auf die man per VNC zugreifen kann. Diese VM kann dann das System von der Platte des Servers starten, so dass man den kompletten Bootvorgang miterleben kann.

Nachdem ich nun auch einen noch nicht produktiven Server zur Hand hatte, um das mal auszuprobieren, habe ich die Gelegenheit genutzt. Besser man macht sich vorab mit dem Feature vertraut anstatt erst im Notfall wenn man dann eh schon aufgeregt ist und die Zeit knapp ist.

Als erstes wählt man im Hetzner Robot bei seinem Server unter Rescue VKVM in der zur Installation passenden Variante aus. Man erfährt sofort URL und Zugangsdaten der VKVM-Konsole. Nicht wundern braucht man sich darüber, dass die URL auf die Haupt-IP-Adresse des eigenen Servers verweist. Nun löst man den Restart des Servers aus; entweder per Reboot auf dem Server selbst oder – wenn dieser nicht mehr erreichbar ist – über den Hetzner Robot. Es dauert nun einige Zeit bis das Rescue-Virtualisierungs-System hochgefahren ist. Nach einiger Zeit kann man dann per Java-fähigemBrowser auf die genannte URL zugreifen und sich mit den genannten Zugangsdaten anmelden. Es startet ein Java-Applet über dass man Zugriff auf die Konsole des virtualisierten Systems erhält. In dieser Konsole sieht man nun eine etwas verwirrende Boot-Schleife, bei der scheinbar versucht wird, das lokale System zu starten, was jedoch nicht klappen mag. Des rätsels Lösung ist, auf folgende Frage mit Q zu antworten:

Boot from (N)etwork or (Q)uit?

Erst dadurch wird der Bootloader auf der Festplatte des eigenen Systems gestartet, der Default N bietet hingegen weitere Diagnose- und Rescue-Möglichkeiten an aber nichtden Zugriff auf das installierte System. Einen weiteren Fallstrick gibt es nun beim Start des installierten Systems: Benutzt man einen Kernel, der auf Hardware-Virtualisierungstechniken angewiesen ist, z.B. mit Xen-Support, so scheitert der Start, denn man ist ja bereits in einer virtuellen Umgebung in der keine Hardware-Virtualisierungstechniken mehr verfügbar sein können.

Hat man auch diese Hürde geschafft startet endlich das installierte System und ist dann auch aus dem Internet z.B. per SSH erreichbar, was für Arbeiten an den Konfigurationsdateien sicherlich etwas angenehmer ist als der Zugriff über die Konsole im Java-Applet.

Verzwickt ist zum Schluss nochmal der Wechsel zurück zum „echten“ System. Die Menüpunkte des Java-Applets, die einen Strg+Alt+Entf senden lassen bzw. einen Hardware-Reset durchführen lassen wirken sich nur auf die virtuelle Umgebung aus, d.h. man verläßt damit das Rescue-VKVM-System nicht. Erst durch einen richtigen Reboot aus dem Hetzner-Robot kommt man hier wieder raus.

Fazit: Von der Handhabung her etwas komplizierter als eine serielle Konsole her, von den Diagnose- und Reparaturmöglichkeiten möglicherweise sogar etwas besser.

Seit 2003 hatte ich diverse Root-Server bei einem großen deutschen Hoster angemietet – insgesamt bisher 6 (okay, einer war nur ein virtueller Server). Bei zwei aufgetretenen Defekten (Netzteil und Festplatte) und der Beantragung der IPv6-Tunnel und -Reverse-Delegationen gab es bisher nur positive Erfahrungen mit dem Server-Support dieses Hosters.

Den letzten Monat bemühte sich der Server-Support jedoch, dass sich dieses Bild wandelt, doch von Anfang an:

Anfang März 2010 wurde eine neue Servergeneration mit neuen Preisen angeboten und ich nutzte die Gelegenheit und bestellte einen Nachfolger für einen im Juni auslaufenden Root-Server. Da ich Einrichtungszeiten von mindestens einigen Tagen gewohnt war, überraschte mich die Bereitstellungszeit von nur 2 Stunden. Außerdem überraschte mich, dass die zugeteilte IP-Adresse aus einem Bereich war, der meines Wissens nach bisher nicht für Root-Server verwendet wurde. Aber egal, Adresse ist Adresse, sollte man meinen… Für diverse NNRPD-Instanzen waren noch weitere IP-Adressen notwendig, die dann allesamt wieder aus den bisher „typischen“ Adressbereichen für Root-Server kamen.

Anfang April 2010 stand dann der Umzug meines Primary-DNS auf den neuen Server an. Komischerweise scheiterten diese Umzugsversuche jedoch daran, dass der Secondary-DNS – auch im Netz das großen Hosters befindlich – die Zone-Files nicht von meinem neuen Primary-DNS abrufen konnte.

Verwunderte stellte ich fest, dass von der primären IP-Adresse des Systems aus (die aus dem mir ungewöhnlich erscheinenden IP-Adressbereich) tatsächlich keinerlei Kontakt zum Secondary-DNS (wohlgemerkt auch beim selben Hoster befindlich) möglich war. Auch weitere „neben“ dem Secondary-DNS stehende Hosts und der Router direkt „davor“ waren nicht erreichbar. Von jeder der zusätzlich bestellten IP-Adressen aus funktionierte es jedoch problemlos. Ich dachte mir also: „Okay, liegt halt eine temporäre Routingstörung zu dem einen Adressbereich vor, aber ich hab’s nicht eilig, warten wir mal ein paar Tage ab.“

Am 18. April lag das Problem noch immer vor. Ich entschloss mich, nun den bisher guten Server Support einzuschalten. Kann ja nur eine Kleinigkeit sein… denkste. Zwei Versuche mit dem Kontaktformular scheiterten, weil das System trotz ausgewähltem Thema darauf bestand, dass man ein Thema auswählt, also das ganze nochmal per Mail geschildert und zwei Traceroutes – einmal nicht funktionierend von der primären IP-Adresse und einmal funktionierend von einer zusätzlichen IP-Adresse – angehängt. Der Übersichtlichkeit halber habe ich den Hopcount bei den Traceroutes auf 10 beschränkt, da bereits mit Hop 5 das Problem deutlich wird… erster Fehler.

Am 22. April kam die erste Antwort, ich solle doch Traceroute nicht auf 10 Hops limitieren sondern bei 30 Hops belassen, dann würde es funktionieren. Okay, schicken wir das Ganze halt nochmal mit unbegrenzten Traceroutes. Natürlich hilft es nichts, 30 Hops zuzulassen.

Am 29. April kam die zweite Antwort, ich solle doch ICMP statt UDP verwenden. Hm, das mag dem Supporter geholfen haben, von sich aus per Traceroute Kontakt zu meinen Secondary-DNS aufzunehmen. Ich kann ihn von der primären IP-Adresse aus gar nicht erreichen, und selbst wenn ICMP funktionieren würde: Wie soll man einen DNS-Zone-Transfer per ICMP machen? Also habe ich das Problem in der Antwort nochmal genau geschildert, ich wurde ja wohl falsch verstanden…

Leider habe ich die nun folgende Antwort vom 30. April mit der Bitte um einen Shell-Zugang, um das Problem nachvollziehen zu können, erst am 18. Mai, als die Bitte wiederholt wurde, gesehen und selbigen Zugang sofort eingerichtet, da ich nun Hoffnung hatte, dass man das Problem endlich offensiv angehen möchte.

Am 19. Mai erhielt ich die Antwort, dass man das Problem von meinem System aus nicht nachvollziehen könne. Die mitgeschickten Ausgaben von Ping und Traceroute zeigten jedoch, dass sich der Supporter um eine Stelle in der IP-Adresse vertan hatte. Ich antwortete ihm nochmal, welche genauen Adressbereiche betroffen wären.

Am 20. Mai erhielt ich die Antwort, dass die Ursache für das Problem sei, dass ich keine Routen für 127/8 und 169.254/16 definiert hätte. Okay, diese Routen bringen zwar absolut nichts, aber sie schaden auch nichts (sollte man meinen). Also lege ich sie an, probiere es sicherheitshalber nochmal aus und teile dem Supporter mit, dass es auch mit den gewünschten Routen (natürlich) nicht geht.

Am 21. Mai erhielt ich nun die Antwort, dass man nochmals nach der Ursache gesucht habe, aber leider das Problem weiterhin nicht nachvollziehen könne. Ich solle das System doch neu installieren, um eventuelle Konfigurationsfehler auszuschließen und mich – wenn es danach wieder auftritt – erneut melden. Da es bei allen zusätzlichen IP-Adressen kein Problem gibt, nur bei der primären IP-Adresse, ist für mich klar, dass es nicht an der Konfiguration liegen kann. Insbesondere, da die Netzkonfiguration im wesentlichen identisch zu meinen anderen Servern beim selben Hoster ist. Ich antworte dem Support also, dass die Fehlersuche auf meinem Server nichts bringen wird, da aus den bisherigen Analysen bereits erkennbar sei, dass das Problem nicht auf dem Server zu suchen ist und bitte ganz konkret darum, auf dem Router direkt vor den nicht erreichbaren IP-Bereichen (der selbst über die primäre IP-Adresse auch nicht anpingbar ist) nach der Ursache zu suchen. Wahrscheinlich erschlägt man damit alle Probleme auf einmal.

Am 22. und 24. Mai erfolgten weitere Shell-Logins vom Server-Support und .bash_history zeigte, dass man sich jeweils die Routing-Tabelle auf dem Server ansah. Dann folgte wieder eine E-Mail, mit dem Hinweis darauf, dass ich die Routing-Tabelle auf dem Server verändert hätte (ich wurde ja am 20. Mai darum gebeten, diese zu verändern) und ich solle doch den Server neu installieren, damit ein Konfigurationsfehler ausgeschlossen werden kann. Wenn das Problem dann immernoch bestehe, würde man die Sache an die Netzwerker übergeben.

Aha, aus den bisherigen Antworten konnte man erahnen, dass ich nicht mit Netzwerkern zu tun hatte, aber nun gaben sie es offen zu.

Ich wollte mir natürlich die unnötige Neuinstallation – die keinerlei Änderung herbeiführen würde – sparen, daher habe ich testweise in das Rescuesystem (das ja richtig konfiguriert sein müsste) gebootet und dort die Verbindung zum Secondary DNS geprüft – natürlich auch mit negativem Ergebnis. Hoffentlich gibt sich der Support nun damit zufrieden und eskaliert das Problem endlich an jemanden, der tatsächlich Ahnung von Routing hat.

Am 25. Mai dann wieder eine Mail vom Support, ich solle doch bitte Traceroutes aus dem Rescue-System heraus machen und schicken. Blöd, dass Traceroute beim Rescue-System nicht installiert ist, aber das kann ich mir ja von einem anderen System per SCP holen. Sicherheitshalber machte ich die Traceroutes mit UDP und auch noch ICMP, damit man mir nicht – wie ganz zu Anfang – einfach rät, ICMP statt UDP zu benutzen.

Am 26. Mai stellte ich mittags fest, dass sich zweimal ein Support-Mitarbeiter auf dem Server eingeloggt hat. Dabei hat er sich die Routingtabelle und die Ausgabe von ifconfig angesehen, die beiden dort erscheinenden IPv6-Tunnel (zum IPv6-Gateway des Hosters und zu mir nach Hause) heruntergefahren, per traceroute verfiziert, dass das Routingproblem weiterhin besteht, und dann die beiden IPv6-Tunnel wieder gestartet. Am Abend des 26. erhielt ich eine Mail, in der nach den Ausgaben von route -n und ifconfig gefragt wird (hm, hat man sich doch mittags schon selbst angesehen), da diese sich augenscheinlich verändert hätten. Ja, natürlich haben die sich verändert, schließlich wurde ich am 20. gebeten, unnütze Änderungen vorzunehmen, und habe diese nach der Mail vom 24. wieder rückgängig gemacht.

Am 27. Mai fand noch vor 9 Uhr morgens erneut ein Login eines Support-Mitarbeiters auf dem Server statt. Es wurden erneut die IPv6-Tunnel heruntergefahren, ein traceroute versucht und dann die IPv6-Tunnel wieder hochgefahren. Nach 11 Uhr fand erneut ein Login statt, den ich erst gegen halb 12 bemerkt habe. Diesmal hat der Support-Mitarbeiter mittels mtr ein paar Ziele zu erreichen versucht, und siehe da: Plötzlich funktioniert alles einwandfrei. Nach 14 Uhr bekam ich dann eine E-Mail vom Support, in der man mir nun endlich nach nochmaliger Untersuchung die Behebung des Problems meldete und – ich hätte das nicht mal erwartet – eine angenehme Gutschrift ankündigte.

Liebes Server-Support-Team, es freut mich, dass das Problem dann doch noch gelöst werden konnte. Ich war schon kurz davor aufzugeben und meinen DNS-Kram auf einen anderen Root-Server (von einem anderen Anbieter) umzuziehen. Schön wäre es natürlich, wenn andere mit einer solch konkreten Problemmeldung sich zukünftig nicht erst wochenlang über viele hingehaltene Stöckchen kämpfen müssten. Ich wette, die eigentliche Problembehebung war, nachdem meine Meldung endlich an die richtige Stelle weitergegeben wurde, vergleichsweise schnell erledigt.