Artikel mit Tag linux
Jun 18: 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
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
Apr 4: ping timeout?
Hallo,
hier war ja nun lange nix los im Blog. Naja. Es ist mal wieder Frühjahr und die Projekte schliessen aus dem Boden. In meinem Fall sind das momentan zwei große Projekte und die reichen auch erstmal.
Zum einen wird in Flensburg am 16.05. der 1. Flensburger Sportabzeichentag veranstaltet. An einem hoffentlich genauso sonnigen Tag wie heute wollen wir das Stadion füllen und die Sportabzeichenprüfung in allen Disziplinen durchführen. Die Software zur Erfassung der Ergebnisse kommt dabei aus meiner Feder.
Auch einen Monat später tut sich was in Flensburg. Am 12. + 13. Juni wird von der WiREG zusammen mit Fonden Center for Software Innovation aus Dänemark der CBLOS - CrossBorder Linux OpenSource Day veranstaltet. Hierbei ist die LUG-Flensburg als lokale LUG mit in der Orga vertreten und wird am Community-Day (23.06.) das Veranstaltungsprogramm mit gestalten und mit einer Installations-Party Linux den Besuchern näher bringen. Wie immer ist dabei das mitbringen der eigenen PCs ausdrücklich erwünscht.
Und zum Entspannen ist dazwischen noch das LUG Camp 2009. Also ein volles Veranstaltungsprogramm.
So wird es wohl auch jetzt wieder zu einer kleinen Blog-pause kommen. Es sei denn, mir kommt noch was blogwürdiges in die Querse
hier war ja nun lange nix los im Blog. Naja. Es ist mal wieder Frühjahr und die Projekte schliessen aus dem Boden. In meinem Fall sind das momentan zwei große Projekte und die reichen auch erstmal.
Zum einen wird in Flensburg am 16.05. der 1. Flensburger Sportabzeichentag veranstaltet. An einem hoffentlich genauso sonnigen Tag wie heute wollen wir das Stadion füllen und die Sportabzeichenprüfung in allen Disziplinen durchführen. Die Software zur Erfassung der Ergebnisse kommt dabei aus meiner Feder.
Auch einen Monat später tut sich was in Flensburg. Am 12. + 13. Juni wird von der WiREG zusammen mit Fonden Center for Software Innovation aus Dänemark der CBLOS - CrossBorder Linux OpenSource Day veranstaltet. Hierbei ist die LUG-Flensburg als lokale LUG mit in der Orga vertreten und wird am Community-Day (23.06.) das Veranstaltungsprogramm mit gestalten und mit einer Installations-Party Linux den Besuchern näher bringen. Wie immer ist dabei das mitbringen der eigenen PCs ausdrücklich erwünscht.
Und zum Entspannen ist dazwischen noch das LUG Camp 2009. Also ein volles Veranstaltungsprogramm.
So wird es wohl auch jetzt wieder zu einer kleinen Blog-pause kommen. Es sei denn, mir kommt noch was blogwürdiges in die Querse
