Skip to content

Bind10 early testing

Am 02.06. diesen Jahres ist ein weiteres Developer-Release von Bind10 erschienen. Nachdem ich als DNS-Admin die Announcements vor einem Jahr gelesen hatte, begann schon die Vorfreude auf die neue Version.

Anständige Skalierbarkeit, Datenbankbackends, modularer Aufbau, dynamsiche Konfiguration zur Laufzeit, definierte APIs zur Konfiguration. Alles Features, die einen leitgeplagten Admin von größeren Bind9-Systemen das Herz höher schlagen lassen.

Das Developer-Release veranlasste mich nun dazu das ganze mal zu testen. Im Wiki ist zu lesen, das die Entwickler auch auf Debian entwickeln. Also sollte das auf meinem Debian ja kein Problem sein. Aber bei den Requirements geht es schon los. Als erstes Backend wurde sqlite implementiert. Dies ist im stable-Debian auch bereits in ausreichender Version vorhanden. Die boost-Libs sind ebenfalls aktuell genug. Auch die Compilerauswahl von 3.4.3 bis 4.4.1 ist mit stable abbildbar. Aber was hat die Entwickler geritten, als sie Abhängigkeiten zu Python 3.1 eingebaut haben??? Im Stable ist python 2.5 enthalten.

Aber was soll's. Fix eine neue Virtualbox-Instanz aufgesetzt, Debian-testing draufgepackt und los gehts. Dort ist Python 3.1 bereits enthalten. (obwohl 2.6 imho Distributionsdefault werden soll...) Der svn-Checkout ist auch problemlos (wer es wirklich testen will, sollte beim Verzeichnis trunk bleiben. Meine 2GB /home-Partition haben für einen kompletten checkout nicht ausgereicht). Mit dem Installieren von "base-essentials" und "pkg-config" (was in den Requirements nicht angegeben ist aber trotzdem benötigt wird) war auch schon das Basissystem für die Tests geschaffen.

Apropos Testsystem. Ich bin Teilpurist. Deswegen hat mein virtuelles Testsystem 64MB RAM und 2 Festplatten mit je 2GB Plattenplatz. Da ich ja kein Unmensch bin und meiner Software auch mal was gönne, hab ich noch 148MB von der einen Platte als swap zugewiesen. Wenn das nicht ausreicht, schieb ich Bind10 wieder in die Schublade, bis die Entwickler ihr Semester in Entwicklung resourcenschonender Software besucht haben.

Nach dem svn-Checkout liegen im trunk-Verzeichnis die Sourcecodes. Für den Üblichen Dreisatz aus ./configure && make && make install fehlt nur eines. Das ./configure-Script. Ein Aufruf von "autoreconf --install" erledigt das Problem und erzeugt das Script. Da ich meine Software gerne unter Kontrolle habe, will ich diese nicht im /usr/local oder gar direkt unter /usr liegen haben. Deswegen wird dem configure-Script ein extra Verzeichnis mittels "--prefix=/opt/bind10-trunk" mitgegeben. Damit alles durchlief hab ich noch hier und da mit ein paar dev-Packaten nachhelfen müssen. Diese habe ich aber leider nicht gelistet. Aber ein bischen Spaß sollst Du beim Testen ja auch haben...

Da ich nicht nur Teilpurist sondern auch Hobby-Paranoiker bin, habe ich die Software natürlich als normaler User gebaut. Damit das make-install klappt, muss dafür das Verzeichnis unter /opt angelegt werden. Das erledigt ein "sudo /usr/bin/install -u frank -g frank -m 755 -d /opt/bind10-trunk" für mich. Und wie zur Bestätigung steht auch gleich im Bind10-Guide, das die Entwicklungsversionen so konfiguriert sind, das sie nicht per Default auf Port udp/53 lauschen sondern auf udp/5300. Also noch ein Pluspunkt. Das Ding läuft bis zur entgültigen Version bei mir zum Testen also als unpreviligierter User. ;-)

Nun noch mit "/opt/bind10-trunk/sbin/bind10 --verbose" starten und los gehts. Der Parameter --verbose bewirkt dabei, das der Prozess sich nicht als Daemon in den Hintergrund verfrachtet sondern schön alles auf der Konsole ausgibt, was er so macht.

Als DNS-Admin haue ich an dieser Stelle natürlich gleich den passenden dig-Befehl in die Konsole, um meinen neuen DNS-Server zu testen. Aber da teilt mir die bash mit einem freundlichen "dig: command not found" auch gleich mit, dass ich vergessen habe noch etwas zu erwähnen. Auf dem System sind nämlich (um Wechselwirkungen mit vorgängerversionen auszuschliessen) keinerlei DNS-Tools installiert. Also parallele Session zum nächsten virtuellen testsystem aufbauen und dort mit dig die ersten Anfragen starten...

... aber die Ernüchterung kommt sofort. In der aktuellen Fassung kennt der Bind10 noch nichtmal die Root-Zone. Der ist wirklich blanko. Da diese frühe Version aber noch nicht für DNS-Cache konzipiert ist, spielt das erstmal eigentlich keine Rolle. Also gleich ein bischen schnüffeln und schon findet man im Internet nichtnur den Root-Zonefile sondern auch ältere Versionen von .edu, .in-addr.arpa und .ipv6.arpa. Also ausreichend Basismaterial zum testen. Mit dem Befehl "/opt/bind10-trunk/b10-loadzone ./root.zone" wird also flink die root-Zone importiert. Die anderen Beispielzonen folgen kurz darauf. Jetzt führen die Testabfragen vom anderen System auch zu den gewünschten Erfolgen. Also: Bind10 is up and running !!!

Fazit des Ganzen:
Die aktuelle Entwicklungsversion hat noch keine Ahnung, was Notifyer sind. Laut Doku soll man bereits Zonentransfers manuell anstoßen können. Aber das wollte noch nicht so. Nach bisherigen Forschungen liegt das wohl daran, das zwar alle Basisrequirements vorhanden sind, aber scheinbar für die boostlib doch Module notwendig sind, die in der Form nicht im Debian-testing enthalten sind. DNS-SEC wird auch noch nicht unterstützt. Das Konfigurationstool "bindctl" arbeitet interaktiv und kommt schon mit einer Onlinehilfe um die Ecke. Die Konfiguration wird nicht mehr in Textfiles erledigt, sondern in einer Datenbank. Das Datenbankschema des sqlite-Datenbank ist bisher recht schmal. Dort sind noch keine Speichermöglichkeiten für Slave-Zonen zu erkennen. Andere Backends als sqlite sind bisher nicht vorhanden, sollen aber folgen. Der eigentlich erst für den 2YearMilestone angekündigte Webinterface zur Konfiguration ist bereits soweit, das es auf 127.0.0.1 einen Serverport öffnen, ist aber noch nicht funktionsfähig. Und was mich aufatmen lässt ist die Tatsache, das ich Bind10 mit den geringen Resourcen sowohl kompelieren als auch starten konnte. Bleibt mir eigentlich nurnoch den Entwicklern ein "Danke (Jungs|Mädels). Weiter so" zuzurufen.

Und um hier auch gleich mal einen weiteren Meilenstein meiner OpenSourceAktivitäten in den Google-Cache-Zement zu meisseln...
... wenn man mal die Announcements der Entwickler ausser auch lässt, ist dies das erste Posting eines Bind10-Users auf der Mailingliste. Und ratet mal, wer der Autor ist :-D :-D :-D

X4450 - Überflieger für den Serverschrank

Vor kurzem machte sich ein Spediteur zu unserem Lieblingsspediteur indem er uns einfach nur zwei Kartons geliefert hat. Und bevor der Inhalt so im dunklen Lager ganz einsam vor sich hin steht, kann man doch was sinnvolles damit anfangen. z.B. den Administratorpuls ein bischen in die Höhe treiben. Links oben seht Ihr das schon ein wenig entblöste Angesicht einer Sun X4450.

Die schmucken Geräte sehen im Schrank nicht nur erheblich cooler aus als die schwarzen Vertreter anderer Serverlieferanten, sondern bringen auch ein bischen Wumms mit. Im zweiten Bild seht ihr Admins Liebling mit herausgenommenem RAM-Board. Zum vorscheinen kommen darunter die 4 CPUs. Ganz rechts sind dann noch mal kurz ein halbes Dutzend PCI-Express Steckplätze untergebracht, die in diesem Fall mit ein bischen Außenanbindung bestückt sind.

Und für diejenigen Leser, denen das RAM-Board irgendwie komisch erscheint im dritten Bild nochmal die 128GB RAM in Großaufnahme. In den kommenden Tages wird unser neues Baby dann auch seiner Bestimmung zugeführt.

Eigentlich war ja noch ein bischen Softwarespielerei und Performancequälen auf dem System in Planung, um mal ein wenig näher auf Tuchfühlung zu gehen, aber unserem Distributor hat es noch mehr in den Fingern gekribelt als uns und er hat das System nicht nur dem normalen Funktionscheck unterzogen sondern auch gleich installiert, fertig eingerichtet und durchoptimiert. Spielverderber ;-) Zum Abschluss meiner kleinen Schwärmerei nochmal ein größeres Bildchen der CPUs.
cronjob