Neulich war es dann so weit, der erste KSK-Rollover stand an:

Nachdem mein Provider die in Rekordzeit weitergegeben hatte konnten die DNSSEC-Tools wie in der Doku beschrieben dazu gebracht werden, den Rollover abzuschließen:

Es kommt viel zu selten vor, daß mal was auf Anhieb funktioniert, wie es sollte - das hier war eine angenehme Ausnahme.

Im Gegensatz zu dem, was man im Netz so findet, ist es nicht korrekt, "set password/m5 null" zu nutzen. Richtig sieht es so aus:

Also "clear" statt "set ... null". Und man sollte mehr als einen Test-Durchlauf machen um zu sehen, ob die Konfiguration funktioniert, gerade "ins" und die Reihenfolge von "clear" und "set" können durchaus beim ersten Mal funktionieren, aber Mist bauen, wenn die Datei bereits angepasst wurde.

Guten Rutsch!

Für diejenigen, die Debian/stable aka squeeze benutzen und seit Kurzem ein Galaxy Nexus ihr eigen nennen: Keines der Musikprogramme (weder Banshee, noch Amarok, noch Rhythmbox) wird in der Lage sein, Eure Musik mit dem Device via MTP zu synchronisieren. Glaubt mir, ich habe so ziemlich alles versucht, was mir eingefallen ist:

1. Anlegen einer eigenen udev-Regel, damit das Ding für mich als User (und Mitglied der "audio"-Gruppe) beschreibbar ist, aka:
   CODE:
   echo 'SUBSYSTEMS=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="685c", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio"' >> /etc/udev/rules.d/51-android-rules udevadm trigger

   Danach funktioniert dann zwar "mtp-detect", aber die Player können immer noch nix damit anfangen.

2. Patchen der "libmtp8", damit sie das Device erkennt, aka:
   CODE:
   - apt-get source libmtp8 - apt-get build-dep libmtp8 - Einfügen der Zeile       { "Samsung", 0x04e8, "Samsung Galaxy Nexus", 0x685c, DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST_ALL },   an geeigneter Stelle in src/music-players.h - dpkg-buildpackage -rfakeroot

   Danach sagt "mtp-detect" zwar nicht mehr "Unknown Device" und Banshee hat auch tatsächlich einmal Dateien übertragen, aber keine Playlists - und es ging auch wirklich nur ein einziges Mal.

3. Aktualisieren der "libmtp8" (die "8" steht ja bekanntlich für den SONAME, also "libmtp.so.8" als Symlink auf "libmtp.8.0.3"), also zuerst auf die 1.0.6, da bleibt der SONAME der gleiche, dann auf die 1.1.1 aus Debian/unstable, da änder sich der SONAME, also auch Banshee nochmal neu gebaut -> erkennt trotzdem nix.
4. Banshee (und die halbe Distribution) auf die Version aus Debian/experimental aktualisiert, bringt nix.

Ich hab aufgegeben. Mit "mtpfs" kann man das Device mounten und per Hand Musik übertragen, aber keine Playlists. Mir wurde das dann zu doof und ich habe mich via offenem US-Proxy bei Google Music angemeldet (und danach mein Google-Paßwort geändert und die Session invalidiert!). Das Hochladen aller meiner Musik in die Cloud hat knapp eine halbe Stunde gedauert, danach war auf dem Handy noch einmal "Clear Data/Daten löschen" via App-Verwaltung für die "Musik"-Applikation angesagt, gefolgt von einem Verknüpfen des Google-Accounts via Musik -> Einstellungen, dann hatte ich Zugriff auf die Musik. Die Playlisten musste ich dann zwar einmalig neu machen, aber dafür habe ich sie jetzt auch überall zur Verfügung. Und da man Musik via WLAN auch gut offline verfügbar machen kann...

Ich hoffe, MTP bekommt jetzt mal etwas mehr Aufmerksamkeit, denn eigentlich ist das ein cooles Protokoll und auch die Tatsache, daß man den Speicher der Smartphones damit nicht mehr partitionieren muß ist ziemlich cool. Und kleiner Rant am Rande: Unter Windows 7 hat mit MTP auf Anhieb alles geklappt... mit Bordmitteln

Es ist schon lustig: In der Firma bin ich einmal im Monat in einem Meeting, bei dem es darum geht, nicht-sicherheitskritische Linux-Updates freizugeben, zu entscheiden, welche unserer selbstgebauten RPM-Pakete wir aktualisieren etc. (wir haben uns selbstironisch die "Linux Updates Group" getauft *g*). Verfügbare Sicherheitsupdates lösen in der Firma Reports via Mail aus, und der freie Satellite-Server "spacewalk" zeigt dicke, knallrote Ausrufezeichen für unsere CentOS-Systeme an, ebenso natürlich das echte RHN für die RHEL-Maschinen. Jedes Stück Software, bis hin zu Perl-Modulen aus CPAN oder Webanwendungen, ist in einer Liste vermerkt, wir vergessen da gar nichts. Und falls wir doch mal was vergessen stehen wir auf den Announce-Listen von mehreren Dutzend Projekten. Unter den Tisch fallen kann da kaum etwas.

Und privat? Distributionsupdates kriege ich natürlich mit, aber mir ist z.B. total entgangen, daß es für meine Webmail-Oberfläche oder auch dieses Blog hier Updates gibt. Na ja - jetzt ist alles aktualisiert, und ich stehe auch privat auf einem halben Dutzend announce-Listen. Noch mehr Mails, juhuu

Ich hatte diese Woche die Gelegenheit, mich mit einigen anderen IT'lern über Dinge auszutauschen, die wir so im Operations-Alltag erlebt haben. Besonders gerne höre ich natürlich immer Geschichten von Banken und Versicherungen, und ich bin da diese Woche nicht zu kurz gekommen. Deswegen, ohne weitere Einleitung:

1. Bei Bank Eins werden die Kosten, die Privatkunden für ihre Aktiendepots entstehen, einmal im Monat abgerechnet - die Daten werden dann dazu benutzt, die Gebühren via Bankeinzug (logisch!) einzusammeln. Für das Erstellen der Abrechnung wird allerdings nicht einfach auf das normale Reporting zugegriffen (die Daten über Aktienbewegungen etc. sind ja alle schon vorhanden, man muß sie nur auswerten) sondern eine speziell für diesen Zweck erstellte Software genutzt (die auch nichts anderes macht als die entsprechenden DB-Queries zu stellen). Diese Software ist auf einem einzelnen, nicht virtualisierten, Server installiert. Und wie sich herausgestellt hat gibt es zwar durchaus Backups von der Konfiguration des Servers und der Software, nur leider waren im K-Fall die Installationsmedien der Software nicht auffindbar oder die Software via Download beziehbar. Das Zusenden der Medien hat vier Tage gedauert.
2. Bank Zwei betreibt seit dem Jahr 2006 ein internes Controlling-System (irgendwas mit Kreditvergabe) auf einem Active-Passive-Cluster. Anfang des Jahres ist der aktive Knoten gestorben und der Umzug der Dienste auf den Standby-Server hat überhaupt nicht geklappt. Eine interne Untersuchungskommision hat herausgefunden, daß ein Umzug auf den Standby-Knoten noch nie - also nichtmal nach der Erstinstallation/Inbetriebnahme - getestet wurde.
3. Versicherung Eins hat über fünf Millionen Euro dafür ausgegeben um sich von einem Team externer Berater das Backup auf die IBM-Software Tivoli TSM umstellen zu lassen. Bestandteil des Vertrags war auch ein automatisiertes Monitoring und Alerting, damit man auch merkt, wenn das Backup einzelner Server fehlschlägt etc. Nach einer größeren SAN-Panne hat man bemerkt, daß viele der Backups, für die das Monitoring in der Vergangenheit "Backup OK" geliefert hatte, noch niemals ohne Fehler gelaufen waren. Es hat sich herausgestellt, daß das Skript, welches vom Monitoring aufgerufen wurde, um den Status eines Backup-Jobs zu ermitteln, von den externen Beratern anscheinend in einen Debugging-Modus versetzt wurde, in dem es stets "OK" zurückgeliefert hat.
4. Versicherung Zwei hat ein - nach ihren Maßstäben - kleineres SAN-System auf Hardware eines Herstellers, über den ich hier auch schon gebloggt habe, umgezogen. Nach neun Tagen ist das hochverfügbare System einfach aus gegangen. Nach Analyse kam man zu dem Schluß, daß ein Wackelkontakt in der SPS zu diesem Ausfall geführt hat. Der Ausfall wäre jedoch vermeidbar gewesen, hätte man auch wirklich alle Stromstecker des Systems mit den Steckerleisten im Rack verbunden und nicht nur die linke Seite.

Es ist schön zu sehen, daß wir, obwohl wir so klein sind, trotzdem ein soviel höheres Niveau halten können als Firmen, deren Monatsbudget für IT größer ist als das, was wir in einem ganzen Jahr ausgeben

Es hätte alles so schön sein können: 4 Terabyte von einem Linux-Fileserver waren auf eine EMC Celerra zu migrieren. Wie gut, daß die Celerra für so einen Fall einen Mechanismus mitbringt, der das Problem in wenigen Minuten lösbar macht: Die Rede ist von „CDMS”, dem „Celerra Data Migration Service”. Dabei handelt es sich um eine Kombination aus einem speziellen Filesystem - dem „MGFS”, aka „Migration Filesystem”, welches „offline inodes” unterstützt - und im Hintergrund laufenden Prozessen. Das Zusammenspiel klingt dabei denkbar cool: Das neu angelegte MGFS wird von einem CDMS-Thread mit dem zu migrierenden Fileserver verbunden (letzerer darf die Daten dazu natürlich nur noch an die Celerra exportieren). Danach greifen alle Clients nur noch auf die Celerra zu. Im Hintergrund werden dabei auf dem MGFS transparent die Verzeichnis-Strukturen und alle Nutzdaten, die von Clients angefragt werden, angelegt. Wurde eine Datei zwar mal aufgelistet (z.B. durch ein ls auf das Verzeichnis), aber noch nie aufgerufen, so ist der Status des Inodes offline. Sobald die Datei gelesen wird, ist der Status online, weil sie ja wie erwähnt im Hintergrund vom Source-Server übertragen wurde. Die Celerra tritt hierbei also als NFS- oder CIFS-Proxy gegenüber den Clients auf - eine Migration ist somit in wenigen Momenten erledigt. Um das übertragen der Nutzdaten zu beschleunigen, kann CDMS im Hintergrund auch aktiv Daten mirgieren. Eigentlich, so sollte man meinen, eine sehr elegant Lösung.

Der Teufel steckt wie immer im Detail: Im Gegensatz zum Standard-Dateisystem UxFS hat der Code des MGFS leider ein paar Optimierungen für große Dateisysteme verpasst. Die Folge davon ist, daß eine im Speicher des DataMover vorgehaltene Cache-Struktur bei großen Dateisystemen vollkommen versagt, wenn es darum geht, freie Blöcke für Schreibrequests zu finden. Im Log sieht man dann die Nachricht:

Wenn diese Situation auftritt, so ist die Celerra erstmal mehrere Minuten lang (je nach Größe des Filesystems und dessen Füllstand) damit beschäftigt, die gesamte Platte zu durchsuchen, um freie Blöcke zu finden, wo sie Daten hinschreiben kann. In dieser Zeit blockieren so ziemlich alle anderen Threads, die auf dem Dateisystem was tun wollen. Bei uns wurde das ganze kritisch, sobald 2,7TB auf dem 6TB Filesystem alloziert wurden. Das fiese ist, daß diese Situation bei jedem Schreibrequests passieren kann, also nicht nur bei einem im Hintergrund laufenden CDMS-Thread.

Ein Workaround, um wenigstens die Migration noch zu Ende zu bringen, ist es, permanent Sparse Files zu erzeugen (512 Byte aus /dev/zero, dann 16MByte sparse, wieder 512 Byte etc.) - Skript dazu gibt es auf Anfrage. Nach Abschluß der Migration steht ja die Konvertierung von MGFS nach UxFS an, und auch hier kann man in besagte Situation fallen, so daß ein Vorgang, der sonst knappe 30 Sekunden dauert (aktuellen NAS-Code vorausgesetzt) auch gerne mal eine Stunde Zeit erfordern könnte - und evt. das Filesystem offline bringt. Nach der Konvertierung in ein UxFS wird ein paar Minuten lang der sog. „Cylinder Group bitmap cache” initialisiert, danach sollten die Probleme der Vergangenheit angehören.

Deswegen würde ich mir momentan gut überlegen, ob ich so eine Migration - bis zum Erscheinen eines Fixes im Code, den ich hier bekannt geben würde - derzeit durchführen würde, wenn große Dateisysteme betroffen sind. Ich selbst habe auf jeden Fall eine Woche lang einen total kaputten Schlafrythmus gehabt, weil ich meinem „Severity One”-Service Requests um die ganze Welt nachgereist bin. Am Schluß habe ich die ganzen in Amerika, Kanada und Australien sitzenden L2/L3-Supporter an ihren Telefonnummern erkannt. Und ich bin froh, daß der Wahnsinn zu Ende ist - ich habe das server_cdms server_2 -C filesystemname heute Nacht hinter mich gebracht und das UxFS hält bisher, was es verspricht, keine Hinweise mehr auf hashalloc-Probleme.

Rachmaninov, Klavierkonzert Nummer 3 - genau das richtige zum Abschalten

Apache 2.2, mod_auth_kerb, mod_dav_svn und unter Windows TortoiseSVN 1.6.16. Kerberos-Authentifizierung funktioniert nicht. 1.7.1 installiert - Kerberos-Authentifizierung funktioniert nicht. 1.7.1 deinstalliert, 1.6.16 installiert, Kerberos-Authentifizierung funktioniert. WTF?

Von eins bis zehn zählen, in ksh97, z.B. unter AIX 4.2.1, Stand Mitte 1997:

Und in bash 3.2.17 (z.B. auch auf dem Mac ab OSX 10.5.2), Stand mehr oder weniger „heute”:

Wie die Zeit vergeht...

(Präambel: Falls wir, lieber Leser, derzeit oder in der Vergangenheit in der gleichen Firma arbeiten oder gearbeitet haben: Nichts hiervon ist persönlich gemeint. Nicht hier soll destruktive Kritik sein. Es gibt nur einfach viel, wo man hätte besser sein können oder werden.)

Meine ersten Erfahrungen mit IT in Unternehmen habe ich im April 2000 bei einem Ingenieurbüro in der Nähe von Ingolstadt gemacht. Meine eigentliche Aufgabe zu dem Zeitpunkt war die Gestaltung eines Intranets, aber wie das so ist wenn man jung, gierig und unerfahren ist habe ich natürlich auch in diverse andere Bereiche hereingeschnuppert. Das Unternehmen hat damals hautpstächlich eine CAD-Software namens CATIA auf IBM-Workstations unter AIX eingesetzt, aber auch Tools für die technische Berechnung und das Desgin von Oberflächen (Strak), welche dann unter Systemen wie IRIX oder HP-UX liefen. Daneben gab es natürlich noch die normalen Windows NT-Kisten für die Verwaltung und eine einzige Linux-Maschine (eben meinen Intranet-Server).

Und hier kommen wir gleich zu den ersten zwei Fehlern: Falsche/keine Frameworks und falsche Tools. Fangen wir beim Framework-Thema an: Ich habe damals angefangen, dieses Intranet zu entwerfen und kam dann relativ schnell zu dem Schluß, daß man da eine Authentifizierung für benötigt. Und ich schäme mich zu sagen, wie ich das damals erschlagen habe, aber ich muß es trotzdem erzählen (das ist so ein bißchen wie ein Besuch in einer Geisterbahn): Ich habe im PHP-Code einen smbclient-Prozess erzeugt, welcher sich mit einem Share verbunden hat - wenn das erfolgreich war, dann habe ich für alle weiteren Seiten den Usernamen und das Paßwort in einem versteckten Input-Feld weitergegeben. Im Klartext natürlich. Und während ich jetzt hier wieder aus meinem Loch im Boden hervor krieche können wir uns ja mal kurz überlegen, warum ich damals so einen Mist gebaut habe: Weil ich keine Ahnung hatte, was Session-Management ist. Und warum hatte ich das nicht? Weil ich nicht über den Tellerrand hinaus gesehen habe. Hätte ich mal nach links und rechts gekuckt, hätte ich auch damals schon Frameworks gefunden, die mir Session-Management, Datenbank-Connectivity etc. abnehmen. Und wäre wahrscheinlich um eine Sünde, die mich jetzt noch manchmal des Nachts schweißgebadet aufwachen lässt, ärmer. Auf Eure berechtigte Frage, wieso ich hier meine Jugendsünden nenne, möchte ich gerne mit „Weil der Mist immer noch passiert!” antworten. In den verschiedenen Niederlassungen des Eingangs genannten Ingenieurbüro passiert das genauso wie bei einem großen Automobilhersteller. Und in meiner jetzigen Firma haben wir einen wirklich begabten Programmierer, der hin und wieder erzählt, wie er die Anwendungen, die er gerade entwicklet, intern so abstrahiert. Und manchmal, wenn er mir dann z.B. erhält daß er jetzt eigene Session-Handling- und Authentifizierungs-Klassen entwickelt hat, oder eine elegante Möglichkeit, mit einer Datenbank zu sprechen, da denke ich mir einfach nur: „Junge, mit jedem beliebigem MVC-Framework hättest Du Dir eine Menge Zeit gespart.” Und wenn ich sehe, wieviel Code und SQL-Abfragen unsere Azubis teilweise schreiben (gut, da sind auch berechtigte Dinge dabei, z.B. Auswertungen oder Reports), schätzie ich mich immer glücklich, wenn ich zu Hause mal in die Verlegenheit komme, eine Web-Applikation zu bauen und mir ein "ruby script/generate model" die schlimmste Arbeit abnimmt (und Rails ist hier nur ein Beispiel für ein Framework, sowas gibt es garantiert auch für PHP oder Java).

Die falschen Tools sind auch so ein Kapitel für sich. In meinem ersten Job habe ich z.B. via Cron-Job regelmäßig abgefragt, wieviel Speicher noch auf bestimmten NFS-Volumes frei ist und diesen Wert dann in eine Datenbank geschrieben. Daraus konnte man sich dann eine schöne Übersichtsseite rauslassen. Das klingt relativ harmlos, aber irgendwann kam dann die Anforderung, doch bitte eine Mail zu generieren, wenn kein Speicher mehr frei war. Und dann musste in den Cron-Job noch eine Möglichkeit rein, sich zu merken, wann die letzte Benachrichtigung erstellt wurde (damit man nicht alle 5 Minuten eine rausschickt). Und spätestens jetzt sollte jedem klar sein, daß ich hier damals das falsche Tool gewählt habe. Wenn ich es heute einfach und schnell erledigen wollte, dann würde ich Nagios oder Icinga nehmen. Für die Benachrichtigungen. Und vielleicht auch für das Erstellen von Graphen, es gibt ja schließlich Plugins wie n2rrd, nagviz etc. Und doch ist ach dieser letzte Schritt evt. schon wieder ein falscher, denn diese ganzen Graphing-Lösungen sind oft nur "drangedübelt" und oft muß man sich einen abbrechen, damit man aus den Checks vernünftige Performance-Daten kriegt. Wer sehen will, wie eklig das werden kann, dem schicke ich gerne mal den n2rrd-Code, mit dem wir zu einem gegebenen Zeitpunkt Filesysteme auf einer großen NAS-Appliance überwacht und gegrapht haben - ich würde einen nüchternen Magen empfehlen. Ziemlich oft fehlt für den Einsatz der richtigen Tools leider auch immer noch ein einheitliches Konzept, über Abteilungen hinweg. Team 1 erschlägt dann seinen Kram mit Nagios-Plugins, Team zwei nimmt MRTG, Team 3 füttert rrdtool per Hand und Team 4 wünscht sich Cacti, hat aber niemanden, der einen Cacti-Server bereitstellen könnte (um beim Beispiel Graphing zu bleiben). Ja, machmal ist es toll, wenn ein einzelnes Tool verschiedene Aufgaben übernehmen kann. Aber nach 14 Jahren Linux weiß ich schon warum "one job, one tool" so lange überlebt hat. Die Unfähigkeit, sich auf einen kleinsten gemeinsamen Nenner bei der Toolunterstützung zu einigen ist etwas, was sich in den 11 Jahren, die ich im IT Operations-Betrieb bin, kein Stück geändert hat.

Diese Unfähigkeit hat etwas mit Kommunikation und Planung zu tun - und hallo, hier kommt der nächste Fail. Das klassische Beispiel dafür durfte ich entweder 2002 oder 2003 erleben, als sich eine Firma eine neue, große NAS-Appliance gekauft hatte, weil der Speicherplatz auf dem bisherigen Fileserver zur Neige ging. Aus Kostengründen hat man sich damals dafür entschieden gehabt, ein relativ kleines Modell besagter Appliance zu kaufen (war immer noch teuer genug), dessen Maximalausbau bei exakt dem doppelten Netto-Platz des alten Fileservers lag. Also alles gut? Mitnichten, denn sieben Wochen danach hieß es von seiten der Fachabteilungen, die mit Abstand den meisten Speicherplatz belegt hatten: „Ach übrigens, unser größter Kunde, die Oemcorp, steigt bis Jahresende auf Supersoft 2.0 um - da müssen wir mitgehen, und die größe der einzelnen Dokumente verdoppelt sich da ungefähr.” Übrigens einer der wenigen Momente meiner IT-Laufbahn, in denen mir vor Lachen die Tränen gekommen sind (lustige Momente - für mich - waren übrigens auch: „Auf dem Volume haben wir gar keinen Platz mehr, das hatte ich Dir doch vor sechs Wochen per Mail geschrieben.”, „Ein kompletter Restore dauert über 60 Stunden.” und „Von den Backups der Dateien in dem Pfad kann ich mindestens 23% nicht mehr herstellen.”). Das Thema Projektplanung ist auch so eines, daß ich noch nirgendwo habe vollständig funktionieren sehen. Bei großen Firmen (20000+) hat man zwar meist extrem detaillierte Projektpläne, dutzende Lenkungsausschüsse, ein großes Budget, ist aber auch fast immer auf externes Know-How angewiesen und die ganze Manpower verschwindet meistens irgendwo im Planungs-Overhead. Bei kleinen Firmen - na sagen wir mal so, die meisten, die ich kenne, hatten gar kein Projektmanagement (und damit auch keine Planung), das den Namen wert gewesen wäre. Und gerade kleine Firmen leiden extrem oft daran, daß Mitarbeiter oft in bester Einzelkämpfer-Manier ihre Projekte planen, mit Zeithorizonten, die für sie selbst realistisch sind, aber ohne zu berücksichtigen, daß andere Teile der Organisation ihre eigenen Projekte haben und deswegen auch wenig freie Kapzität. Bei ganz kleinen Teams ist das kein Problem, bei größeren Teams wird es hin und wieder unangenehm. Ein gutes Beispiel ist mir selbst erst vor kurzem passiert, als das Netzwerk-Team ein Renumbering vorgeschrieben hat, daß sich direkt mit einem Livegang überschnitten hätte. Ironisch ist das vor allem, weil wir uns eigentlich einmal im Monat zusammensetzen, um uns zwischen den Fachbereichen auszutauschen - was dann schon die Frage aufwirft, wie effektiv diese Meetings einmal im Monat sind.

Worin ironischerweise ausgerechnet IT-Operations-Teams regelmäßig versagen ist übrigens auch die Fähigkeit, mal einen Schritt zurück zu treten und bestehende Strukturen und Abläufe kritisch zu prüfen. Besonders paradox dabei ist die Tatsache, daß die Wahrscheinlichkeit, mit der man ein bestehendes System (oder auch nur eine bestimmte Konfigurationseinstellung) verändert, immer kleiner wird, je länger das System in Betrieb ist - wo eigentlich klar sein müsste, daß es sich genau anders herum verhalten müsste. Ich hatte 2004 mal ein Shellskript geschrieben, das für den Datenaustausch auf einem Multi-Homed-Host vorgesehen war. Das ganze war eine extrem hässliche Krücke (obwohl der Code in Ordnung war, ich meine eher das Konzept) und war für eine Übergangsfrist von vier bis sechs Wochen gedacht. Ihr könnt Euch mein Entsetzen vorstellen, als ich 2006 wieder in dieselbe Firma kam und besagte Krücke - symbolisch gesprochen - bei einem 100m-Hürdenlauf beobachten durfte. Jetzt könnte man vermuten, daß das einfach funktioniert hat und es darum jeder vergessen hatte - dem war aber nicht so (was wiederum nicht am Skript, sondern am Datenvolumen und der vorhandenen HW lag). In einer anderen Firma hat man knappe 100 Server via NFS an einen zentralen Fileserver gehängt - und als Mount-Option "soft" gewählt. Weil die Applikationen auf besagten Servern nämlich auch Datenbank-Sessions offen hatten. Hängender NFS-Mount = hängende Datenbank-Session, das schaukelt sich auf. Der Logik kann man im Prinzip folgen - nur hatte sich nie jemand ernsthaft die Mühe gemacht zu untersuchen, wie man "hängende NFS-Mounts" in den Griff kriegt (was nicht weiter schwer ist, besagte Firma hat heute Oracle-Voting-Disks auf NFS). Der Grund war, daß besagter Fileserver ein echter Datenschatz ist und sich einfach nie jemand rangetraut hatte. Ich überlasse es jetzt Eurer Phantasie, wie oft man bei "soft"-Mounts I/O-Fehler hat oder manuell intervenieren muß. Wahrscheinlich hat diese gewisse Trägheit was mit der Art und Weise zu tun, wie die Operations-Teams normalerweise psychologisch funktionieren (Beständigkeit, stabile Umgebungen, Change nur bei klaren Vorteilen etc.).

Der Ehrlichkeit halber muß man sagen, daß es bei vielen der hier erwähnten Firmen eigentlich trotzdem ganz angenehm war - und gerade mein gegenwärtiger Job ist ziemlich gut, von den oben erwähnten Dingen sind wir da deutlich weniger betroffen als anderswo - was nicht heißt, daß wir nicht besser werden könnten (und ich bin überzeugt, daß wir das auch werden!).

Und um den Ascbhluß zu kriegen: Ich kann mir auch gar nichts anderes vorstellen als IT-Operations: There's nothing like beating a server into submission.. Schönes Wochenende Euch allen!

Nur damit ich es das nächste mal wieder finde: Wenn man sich ne Bridge baut und die entweder ewig lange braucht um "ready" zu werden oder nachher keine IPv6-Advertisements kriegt, dann gibt es wahrscheinlich bridge_fd nicht. Es funktioniert perfekt mit folgendem Eintrag in /etc/network/interfaces:

...wird endlich signiert:

In letzter Zeit habe ich viel mit unseren Security-Auditoren, meinem Chef, diversen Kollegen etc. pp. geredet und über Komplexität, Zuverlässigkeit, Sicherheit phillosophiert. Im Endeffekt denke ich kann man das alles mit zwei Regeln abhandeln (die bestimmt nicht neu sind, ich aber erst jetzt wirklich verinnerlicht habe):

Jay, wollen wir das in die LUG-Statuten schreiben?

Ich fange diesen Artikel bewusst mit einem Zitat von Stephane Bortzmeyer an, einem der Betreiber der TLD-DNS-Server für die „.fr”-Zone:

Fühlt Euch also gewarnt. Es gibt (für mich) zwei gute Gründe, Views einzusetzen. Der Erste ist das Bedürfnis, gewisse interne Zonendaten (z.B. die RFC1918-IPs meiner virtuellen Maschinen sowie die Adressen der Point-to-Point-Links, die selbige verbinden, jeweils vor- wie auch rückwärts) auch wirklich nur den Clients zur Verfügung zu stellen, die sie benötigen. Der andere hat mit einer Besonderheit von DNSSEC zu tun und der Tatsache, daß ich nunmal kein ganzes Array von Servern besitze und somit auf ein und dem selben Server gerne einen authoritativen und einen rekursiven Nameserver zur gleichen Zeit betreiben möchte. Holen wir also zu einem Rundumschlag in Sachen Begriffsklärung aus (und erledigen den Buchstabensalat aus der Überschrift):

1. Wenn ein Client (das kann jetzt ein Programm mit einer DNSSEC-fähigen Resolver-Library oder z.B. ein DNSSEC sprechender Nameserver, der Clients bedient, sein) Daten haben möchte, die mit DNSSEC authentifiziert wurden, so setzt er dazu in seiner Anfrage das „DNSSEC OK” (DO)-Bit.
2. Ist der anfragende Client kein echter Resolver, der in der Lage ist, einen beliebigen Namen aufzulösen, in dem er sich „von oben herab” durch die DNS-Hierarchie hangelt, dann teilt er dem Server, dem er die Anfrage schickt mit, daß doch bitte jener für ihn die Rekursion übernehmen solle - er setzt das „Recursion Desired” (RD)-Bit.
3. Wenn der Server, den die Anfrage trifft, so konfiguriert wurde, daß er dem Client die Rekursion abnimmt, dann setzt er in seiner Antwort das „Recursion Allowed” (RA)-Bit.
4. Der Client bekommt die Bestätigung, daß die Antwort kryptographisch verifiziert wurde, in dem in der Antwort das „Authenticated Data” (AD)-Bit gesetzt wird.
5. Ein Nameserver, der auf eine Anfrage betreffend einer Zone, für die er verantwortlich ist, antwortet, setzt das „Authenticated Answer” (AA)-Bit.

Und hier haben wir ein Problem: Angenommen, der BIND9 auf thrassa.incertum.net sei sowohl authoritativer Server für die Zone incertum.net, aber auch rekursiver Resolver für irgendeine VM auf der Kiste. Wenn ihn jetzt eine Anfrage mit gesetztem DO-Bit nach einem Eintrag aus der Zone incertum.net erreicht, dann müsste er gleichzeitig AA und AD setzten - das geht aber nicht, die beiden schließen sich gegenseitig aus (nur weil der authoritative Server Schlüssel hat, heisst das ja nicht, daß das auch die richtigen sind. Die ganze „chain of trust” kann nur ein rekursiver Resolver verifizieren).

Und hier kommen Views in's Spiel. Man legt sich einfach einen View für interne Clients an, bei dem man Rekursion zulässt und in dem man die Zonen definiert, die nur interne Clients sehen sollen (N.B: Wenn man auch nur eine einzige Zone in einem View anlegt, dann muss man das mit allen Zonen so machen!). Die zweite Zone ist dann die, die wir nach außen präsentieren. Wenn ein interner Client jetzt eine Anfrage mit gesetztem DO-Bit an den Nameserver schickt, dann verifiziert dieser von oben nach unten die Vertrauensstellung der einzelnen Zonen und kommt dann irgendwann bei sich selber an - der Client erhält so das gewünschte AD- und nicht das AA-Bit.

Wichtig: Aus dem oben gesagten folgt, wenn man BIND9 ein bisschen kennt, dass man auf keinen Fall die IP(s), auf denen der Server die offizielle Zone dem Rest der Welt präsentieren soll, mit in die Liste der Clients aufnimmt, die den rekursiven View zu sehen bekommen soll. Man handelt sich sonst nur einen Haufen Fehlermeldungen der Art „lame server resolving <eine unserer Adressen>: <IP unseres Servers>” ein.

Die Umsetzung ist dann relativ straightforward und kann bei Debian in der Datei named.conf.local erfolgen - na ja, fast, denn bevor wir loslegen, müssen wir noch eine Zeile aus der named.conf entfernen (wir erinnern uns: Eine Zone in einem View, alle Zonen in einem View!):

Es handelt sich dabei um diverse Zonen, die wir sowieso nur für den rekursiven View brauchen können. In der named.conf.local steht bei mir dann z.B. folgendes:

Ich bin gerade ernsthaft am Überlegen, ob ich obigen Auszug kommentieren soll, aber ich glaube, er spricht für sich. Wichtig ist, wie oben erwähnt, daß man keine der IPs, auf denen der Server nach außen hin die offiziellen Zonen präsentieren soll und auch keinen der Secondaries versehentlich in den internen View aufnimmt. Und man sollte ebenfalls wissen, daß das Setup unglaublich viel komplexer wird wenn man z.B. dynamische Updates mit dazunimmt. Also kommt bitte nicht bei mir vorbei, wenn ihr Euch Euren DNS zerschießt

Ohne jeglichen Zusammenhang: Morgen kommt der Packerlmann und bringt mir The Road To Reality. Gehirn, stell' Dich schonmal drauf ein, Du wirst ab jetzt wieder benutzt!

...they hatin'!

Fangen wir mal so an:

Ich habe in den letzten zwei Wochen sehr sehr viel getestet und mich dann gestern dazu entschlossen, DNSSEC für alle meine privaten Domains live zu stellen. Im folgenden dann kurz - primär für mich als Gedächtnisstützte, aber vielleicht ja auch für andere Leute interessant - die Dokumentation dazu, was ich alles dafür tun musste.

Dokumentation zu DNSSEC gibt es zahlreich, aber sie krankt, ebenso wie die vorhandene Tool-Unterstützung dafür, teilweise sehr in den Bereichein Aktualität oder Zuverlässigkeit. Über Google stolpert man recht schnell über das DNSSEC HOWTO von nlnetlabs.nl - und wer sich mit DNSSEC noch gar nicht beschäftigt hat, der findet hier einen guten Einstieg. Ebenso empfehlenswert ist dnssec.net, gespickt mit Dutzenden hilfreicher weiterführender Links. Da ich die Umsetzung bei mir mit BIND vorgenommen habe ist es natürlich auch sinnvoll, das Bind 9 Administrator Reference Manual zur Hand zu haben. Den Part der Tool-Unterstützung habe ich mit den Dnssec-Tools abgedeckt, auch wenn ich eine wenig erfolgreiche Iteration meines Test-Zyklusses mit OpenDNSSEC durchgeführt habe. Und auch mit DNSSEC Look-aside Validation (aka DLV) sollte man sich mal beschäftigt haben .

Zu den Voraussetzungen: Es ist sinnvoll, seine eigene DNS-Infrastruktur zu betreiben (an dieser Stelle mal wieder herzlichen Dank an Andreas Scherbaum, seines Zeichens nicht nur PostgreSQL-Gott, sondern auch Spender des dritten Nameservers für meine Domains). Ebenso ist die Einführung von DNSSEC nichts für Unerfahrene Administratoren, man sollte sich mit DNS, mit Unix und mit Testprozeduren auskennen. Ein dediziertes Test-Lab bietet sich an, in Ermangelung dessen geht natürlich auch eine Sammlung virtueller Maschinen. Und es erfordert einen gewissen Mut, den endgültigen Switchover durchzuführen
Sinnvoll ist ebenso ein Registrar, der die DNS-Keys denn auch bei der Registry hinterlegt, daran arbeite ich gerade - und solange laufe ich via DLV.

Als Scope hatte ich für mich persönlich festgelegt, daß ich keine Software selber installieren und keine Backports durchführen will. Diese Entscheidung hat bei mir dann leider OpenDNSSEC aus dem Rennen geworfen - die Version in Debian/stable hat einfach zu viele Fehler. Das fing damit an, daß der ods-auditor mit meinen DKIM-RRs nicht klargekommen ist und hörte damit auf, daß die signierten Zonen unvollständig waren. Neuere Versionen sind hier bestimmt zuverlässiger, so signiert z.B. ICANN die ip6.arpa-Zone mit einem OpenDNSSEC-Cluster (ok, gut, da war neulich mal Land unter, aber trotzdem) und z.B. auch .fr ist mit OpenDNSSEC verwaltet (schön zu erkennen an den mindestens fünf DNSKEY-RRs in der Zone, KSK live, KSK emergency, ZSK live, ZSK emergency, ZSK prepublish - OpenDNSSEC kann da gierig werden). Ebenso musste ich leider zkt außen vor lassen. Meine Wahl fiel dann jedoch auf die klassischen dnssec-tools und so war der erste Schritt denn auch die Nachinstallation der benötigten Pakete (bind9 hatte ich natürlich schon):

Der erste Schritt bestand für mich darin, meinen Nameserver DNSSEC-fähig zu machen. Unter Debian liegt die Konfiguration unter /etc/bind. Dort fügt man als erstes drei Zeilen in die Datei named.conf.options ein:

Die erste Zeile bewegt BIND dazu, überhaupt DNSSEC zu sprechen, also z.B. die AD- und CD-Flags zu unterstützen. Mit derzweiten Anweisung bringt man BIND dazu, DNS-Antworten zu validieren. Von besonderem Interesse ist die dritte Zeile - mit ihr sagt man BIND nämlich, daß man nicht nur die Trust-Chains von der Root-Zone abwärts benutzen will, sondern aktiviert auch die Nutzung von DLV - z.B. eben wenn die Registriy offiziell noch kein DNSSEC kann bzw. die Zone noch nicht signiert wurde wie in .de oder der Registrar einem DNSSEC nicht anbietet. Innerhalb der DLV-Registry wird dann für jede Zone ein DLV-RR hinterlegt (das ist jetzt nur ein Beispiel, keine Sorge, ihr habt nix vergessen):

Damit das unter Debian ohne hässliche Fehlermeldungen beim Start des Nameservers funktioniert, muß man noch eine Zeile an den Anfang der Datei named.conf.local anfügen:

Die zweite Zeile in der named.conf (dnssec-validation yes;) habe ich übrigens nur da drin stehen, weil die Kiste für die VMs als Resolver auftritt. Das kann ich tun, weil sich meine Clients nicht im geringsten dafür interessieren, ob AD oder AA gesetzt ist. Würden sie das tun, müsste ich mit match-recursive-only und Views in der BIND-Konfiguration arbeiten.

Da ich am Anfang etwas unsicher mit der ganzen DNSSEC-Geschichte war habe ich mir zusätzlich in der named.conf.local eine Debugging-Ausgabe für DNSSEC nach /tmp/dnssec.log eingerichtet:

Jetzt wäre dann der richtige Moment, um ein paar Test durchzuführen und dabei das Debug-Log im Auge zu behalten. Funktioniert alles wie erwartet, kann man die Änderungen auf allen Nameservern, die die eigenen Zonen verwalten, durchführen und auch dort testen.

Bevor man mit dem DNSSEC-Deployment weitermacht, bietet es sich an, sich Gedanken über die Verzeichnisstruktur zu machen, die man einsetzen möchte. Für jede Zone, die man verwaltet, wird es am Ende eine ganze Reihe von Dateien geben:

1. Die eigentliche Zonendatei - bei mir einfach wie die Zone benannt, also z.B. incertum.net
2. Die signierte Zonendatei mit der Endung .signed, also z.B. incertum.net.signed
3. Mindestens drei Schlüsselpaare (private + public) im Format K$zonename.+$algorithm+$keyid jeweils mit den Endungen .key und .private, also z.B. Kincertum.net.+008+40084.key und Kincertum.net.+008+40084.private
4. Eine Datei mit den DS-Records zu Übermittlung an den Registrar/die Registry, z.B. dsset-incertum.net.
5. Ein sogenanntes "Key Rollfile", in dem sich die dnssec-tools merken, wann welcher Schlüssel generiert wurde, wie lang die Signaturen, die damit erstellt wurden, gültig sind, ob der Schlüssel gerade im Rollover ist etc. Der Name wäre z.B. incertum.net.krf

Der Dämon, der die Key-Rollovers (also den Prozess einen neuen Key im DNS einzufügen und den alten außer Dienst zu nehmen) durchführt, benötigt ebenfalls eine Steuerdatei (bei mir: all.rollrec). Das ganze kann dann ungefähr so aussehen:

Ich habe den ganzen Kram nach /etc/bind/forward-zones/ gelegt.

Bevor wir die erste Zone mit DNSSEC signieren sollte man noch einen kleinen Fehler in der Datei /etc/dnssec-tools/dnssec-tools.conf ausbügeln:

Jetzt könnte man die erste Zone signieren - und ich weise noch ein allerletztes Mal drauf hin, daß man die Dokumentation und die Konfigurationsfiles lesen und verstehen sollte! Das initiale Signieren einer Zone erfordert das manuelle Generieren von Schlüsseln - 1xKSK, 2xZSK. Übrigens verwenden wir derzeit noch /dev/urandom - wenn das bei Euch viele Zonen sind mit vielen Keys, dann solltet ihr einen irgendeine Hardware benutzen, die Euch Entropy zur Verfügung stellt, bevor ihr das ändert! Der Aufruf dazu ist - wenn die Zonen-Datei genauso heißt wie die Zone denkbar einfach:

Der Aufruf erstellt die Datei incertum.net.signed - und die KÖNNTE man jetzt schon in BIND einlesen, allerdings würde ich diesen Schritt erst am Ende durchführen. Es sollte jetzt auch klar sein, daß sich für die Zukunft der Workflow für das Ändern von DNS-Einträgen anders darstellt: Man editiert die Zonendatei, überprüft sie, signiert sie und sagt BIND erst dann, daß man die Zone gerne neu geladen hätte. Das ist natürlich eine klassische Aufgabe für ein Makefile. Es gibt bestimmt elegantere Lösungen, aber für mich funktioniert:

Damit kann man dann nach Änderungen an den Zonenfiles einfach ein make einwerfen und sich freuen Man bemerkt übrigens, daß hier der Parameter --genkeys beim zonesigner-Aufruf fehlt.

Jetzt wo wir die ersten Zonen signiert haben wäre es an der Zeit, sich die signierten Zonendateien mal anzusehen. Wir stellen fest, daß sie drei DNSKEY-Einträge enthalten. Zwei davon sollten in den Flags ein 256 3 8 tragen. Damit sind sie sogenannte Zone Signing Keys, also die Schlüssel mit denen wir die RRs der Zone signieren, gekennzeichnet. Signaturen die wir mit diesen Schlüsseln erstellen sind kurzlebig und müssen in sehr regelmäßigen Abständen getauscht werden. Die von uns verwendete Toolchain verwendet dazu einen Key-Rollover mit Pre-Publishing - deswegen gibt es zwei ZSKs. Kommt der Zeitpunkt des Rollovers wird ein neuer Key generiert und der derzeit verwendete in Ruhestand geschickt - natürlich immer mit Augenmerk auf die TTL der Zone. Der Key mit den Flags 257 3 8 ist der Key Signing Key oder KSK. Mit ihm signiert die Toolchain die ZSKs und das ist auch derjenige, der bei der Registry hinterlegt werden muß (Lemma: Ist die erste Nummer eine Primzahl, so geht man von einem KSK aus, sonst von einem ZSK. Die zweite Zahl bezeichnet den Verwendungszweck, 3 steht für DNSSEC. Und die letzte Ziffer bezeichnet den Algorithmus, hier RSA/SHA-256). Aus all dem folgen zwei wichtige Dinge:

1. Man muß Signaturen in regelmäßigen Abständen erneuern.
2. Ein ZSK-Rollover ist relativ unkompliziert da ich ihn selbst ausführen kann, bei einem KSK dagegen muß der Registry neues Schlüsselmaterial mitgeteilt werden.

Unsere Toolchain unterstützt uns beim Key-Rollover mit den Tools rollerd(1p) und rollctl(1p). Ersteres ist der Dämon, der die Key-Rollovers automatisch durchführt, Signaturen erneuert etc., letzteres ist das Control-Programm dafür. Der rollerd benötigt eine Steuerdatei, die man mit dem Utility rollinit erstellt (die Mailadresse hinter -admin bitte sinnvoll setzen!):

Der Dämon selbst hat kein Init-Skript, ich habe ihn in die /etc/rc.local verfrachtet und starte ihn dort folgendermaßen:

Die Logausgaben findet man in der Datei /var/log/dnssec-tools/rollerd.log.

Als letzte Komponente der Infrastruktur benötigen wir noch ein Tool, das unsere Zonen im Auge behält. Unsere Toolchain liefert dafür den Donuts Demon mit (was für ein Name, echt mal...). Auch der donutsd hat kein Init-Skript, das ist aber nicht weiter schlimm. Wiederum in der /etc/rc.local:

Das File checkzones.txt sieht folgendermaßen aus:

Sollte klar sein, Zonendatei, Zonenname, Kontaktperson. Der Donut kippt Mails standardmäßig via SMTP auf 127.0.0.1, Port 25 ein. Das Ding ist recht simpel, es prüft die Zone und wenn sich die Ausgabe des gegenwärtigen Runs von der letzten Ausgabe unterscheidet dann schickt er uns eine Mail.

Jetzt haben wir es eigentlich fast geschafft. Bevor wir jedoch Key-Material bei unserer Registry oder z.B. bei der ISC DLV Registry einkippen, müssen wir zum einen in der BIND-Konfiguration noch das unsignierte Zonenfile durch das signierte Zonenfile ersetzen ($serial++ und rndc reload nicht vergessen!), testen, ob die Key-Rollovers funktionieren (siehe Link oben zu rollctl) und mit unserem Registrar den Abstand der KSK-Rollover (kann man in der dnssec-tools.conf anpassen) sowie einen Transportweg des Schlüsselmaterials klären. Und dann, dann ist es auch wirklich geschafft.

Wisst ihr Bescheid. Ich gehe jetzt das Klavierkonzert Nummer vier von Rachmaninov anhören. Schönen Sonntag noch!

Update 1: Folgende Punkte ergänzt:

• Verwendung von /dev/urandom vs. /dev/random
• Vermischen von authoritativen Nameservern (geben AA-Bit zurück) und rekursiven Servern (geben AD-Bit zurück).

Update 2: Auf Anregung von Alexander Wirt ein para Absätze umgebaut und das Makefile überarbeitet.