Franks Blog

Ist es mir doch in letzter Zeit häufiger passiert, dass die Zeit des einen oder anderen Servers leicht abgedriftet ist. Besonders ärgerlich ist dass, wenn der Server die Angewohnheit hat zu hetzen und schon ein paar Minuten weiter ist als alle anderen...

Unter Linux verwende ich dafür für die erste Korrektur immer ntpdate. Einfach per ntpdate <zeitserver> den Abgleich anwerfen und es wird die synchronisierte Zeit und der ausgeglichene Offset angezeigt. Hat man allerdings Dienste wie z.B. den IMAP-Server Dovecot laufen, finden die das z.T. garnicht witzig, wenn die eine Zeitepoche auf einmal noch ein weiteres mal durchleben sollen. Dovecot quittiert dies z.B. mit einer Arbeitsverweigerung bis der wiederholte Zeitabschnitt verstrichen ist.

Prinzipiell gibt es dafür jetzt zwei Lösungsmöglichkeiten. Die eine davon ist das Packet ntp nachzuinstallieren. Darin enthalten ist der Zeitserver ntpd, den man mit der Anweisuung server in der Datei /etc/ntp.conf auf den gewünschten Zeitserver schickt und dann startet. Die Zeit wird vom ntpd dann im Hintergrund syncron gehalten. Empfehlenswert ist es trotzdem vorher einmal mit ntpdate manuell die Zeit zu synchronisieren, da ein zu großes Offset vom ntpd nicht ausgeglichen wird.

Die zweite Version ist etwas konsequeter, weil sie auch bei größeren Offsets arbeitet. Dafür wird das Packet ntpdate installiert. Unter Debian wird danacj in der Datei /etc/default/ntpdate die Einstellung NTPDATE_USE_NTP_CONF auf no gesetzt. Die Zeile mit NTPSERVERS kann bei bedarf erweitert werden. Damit die Zeitsynchronisation regelmässig ausgeführt wird, wird noch ein passender Cronjob erstellt. Am besten ruft man dafür den Befehl

crontab -e

auf, um die Crontab mit dem Default-Editor zu bearbeiten.

# m h  dom mon dow   command

*/5 * * * * /usr/sbin/ntpdate-debian 2>&1 >/dev/null

Damit wird alle 5 Minuten einmal die Zeit abgeglichen. Je nachdem wie stark die Systemuhr abdriftet kann man hier auch größere Abstände konfigurieren. Das Zeilenände "2>&1 >/dev/null" leitet alles Ausgaben in die Mülltonne. Dies sollte man unbedingt mit angeben. Sonst produziert der Befehl alle 5 Minuten eine Mail, die an den Systemadministrator geht.

Alle hier beschriebenen Befehle müssen als root-User ausgeführt werden, da die Änderung der Systemzeit nur durch diesen User zu erledigen ist.

Unter Ubuntu sollte der Ablauf der gleiche sein. Hier muss lediglich vor jeden gezeigten Befehl ein sudo vorgestellt werden, da Ubuntu per Default mit deaktiviertem Root-Account arbeitet.

Bei meinem Home-Rechner hab ich bereits vor ca einem Jahr das rotierende Rost mit dem Betriebssystem durch eine SSD ersetzt. Dort laufen nur noch die Datenplatten mit rotierendem Altmetall. Für die Weihnachtszeit habe ich gleiches für mein Thinkpad T60 Laptop geplant. Und aus beruflichen Gründen habe ich das Upgrade gleich mit einem neuen OS von WinXP(r) auf Win7(r) verbunden.

Die Installation konnte ich nicht als Benchmark verwenden. War schliesslich meine erste Win7-Installation. Aber die Startzeiten vom Libreoffice waren mir vertraut. Und was soll ich sagen? Anschnallen ist angesagt. Nichts mehr mit Klicken und dann erstmal zur Käffchentasse greifen. Nein. Klicken und Anwendung läuft. Coooool.

Aber den Effekt beim LibreOffice-Start habe ich erwartet. War beim PC unter Linux genauso. Also musste ich zu stärkeren Waffen greifen. In meinem Softwaresortiment schlummerte noch ein CorelDraw12. Das brauchte mit RostXP schonmal ne halbe Minute und länger für den Start. Aber auch hier war die Beschleunigung deutlich zu spüren. Beim Corel kann ich jetzt auch nicht mehr zum Käffchen greifen.

Nochwas zu Win7 auf dieser Hardware. Damit die mittlere Maustaste und der Tastaturknubbel wieder erwartungskonform gemeinsam genutzt zu einem Scrollen des Browserinhalts führten, war ein Download von Tastatus/Maus-Treibern von Lenevo notwendig. Auch ohne dieses Update funktionierte alles im Prinzip. Aber grade die Scrollfunktion hätte ich doch vermisst. Nachdem die Powermanagement-Treiber von Lenovo ebenfalls installiert waren, verdoppelte sich auch die Akkudauer auf einen Schlag. Alles andere ist noch auf "normal"-Zustand.

Und für die Lizenzanwälte unter den Lesern: Ich bin Admin. Alle Lizenzen sind entweder offiziell gekauft oder Open-Source.

Stolperte ich doch kürzlich beim Hardwaredealer meines Vertrauens über ein kleines Schwarzes in Größe eines Routers. Dieses Stückchen Hardware beinhaltet einen PC mit Atom D525 Dual-Core CPU onboard, 2GB RAM und einer 1GBit/sec Netzwerkkarte. Ein ION2 Grafikchip aus dem Hause NVidia sorgt für bis zu 1920x1200 Auflösung. Die 320GB Festplatte ermöglicht die notwendigsten Arbeiten. Wer dem Netzwerkkabel abgeneigt ist und das Gerät lieber mit der mitgelieferten Halterung hinten an den Fernseher oder das Display schraubt, kann sich auch auf eine 802.11b/g/n WLAN-Karte mit RTL8191SU-Chip stürzen. Die Grafik wird mittels VGA oder HDMI-Anschluss herausgeführt. 4 USB Anschlüsse ermöglichen ausreichend Anschlussmöglichkeiten für weitere Addons. Laut Hersteller kommt das Gerät mit einem Gehäusevolumen von 0,5 Liter daher. Im Original wird das gute Stück für ca. 285€ mit einem FreeDOS (!) distributiert. Die Version mit Windows 7 ist dementsprechend preisintensiever.

Beim Erstkontakt war das Gerät bereits mit einer Windows7 Installation aus dem hauseigenen Testlabor meines Dealers kompromitiert. Mit geweckter Neugier konnte ich das Gerät für einen Linux Test in Form einer Teststellung leihen. Und so fand das kleine Schwarze den Weg in mein...

... Büro mit Werkstattkarakter. Was dachtet Ihr den. tststs. Mangels CD-Laufwerk (brauch man ja eh nur zur Installation) fix einen USB-Installer für Debian Squeeze zurechtgeklöppelt. Die Anleitung dazu befindet sich im Debian Installationshandbuch. Nach dem Einschalten erreicht man recht zügig mit F11 das Boot-Menü, das bei eingestecktem USB-Stick diesen als Bootmedium anzeigt. Die Installation startet erwartungskonform im Textmodus. Der Netzwerkchip gehört zu der Sorte, die eine als non-free eingestufte Firmware benötigt. Diese ist allerdings im non-free Firmware-Image von Debian enthalten. Einfach das 11MB große firmware.tar.gz ebenfalls auf dem USB-Stick entpacken und der Installer findet auch die Netzwerkkarte und installiert anstandslos weiter. Die WLAN-Unterstützung ist damit jedoch nicht in Betrieb zu bekommen. Also muss das Gerät doch für den Erstkontakt ans Netz und nicht gleich mit WLAN-only loslegen.

Das Debian-System läuft flüssig und leise vor sich hin. Weiteres Tuning an Grafik oder ähnlichem ist nicht notwendig. Je nach Montage wird nur die blaue Betriebs-LED irgendwann nervig. In einem des Nachts nicht beleuchteten Büro sorgt diese LED doch schon für ausreichend erhellung, um sich im Büro zurechtzufinden.

Das WLAN-Problem ließ sich mit den Standard-Packeten von Squeeze nicht beheben. Den Mailinglisten nach soll der notwendige Treiber allerdings im non-free Zweig von Wheezy vorhanden sein, so dass auch dieses Problem mit dem nächsten Release erledigt sein dürfte.

Alles in allem ein hübsches kleines Gerät, welches ich durchaus für größere Büroinstallationen in Betracht ziehen würde...

Und damit wandert das Gerät wieder zurück zum Dealer. Wer das Gerät also life sehen möchte, müss dort vorbeischauen.

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

Wieder einmal sitze ich an einem "Euer Server performt nicht" Problem, was aber erst auftritt, wenn eine ganz bestimmte Anwendung darauf laufen soll.
Wie häufig ist das mit viel PDF-Lesen verbunden. Wie groß soll die optimale PageSize für den Prozess sein? Sollen die CPUs dynamisch zugeordnet werden oder doch lieber fest? Naja. Das übliche halt.

Aber da ich jetzt zwischen zwei PDF Seiten mal wieder meinen 5-Türen-Weg zum Käffchendistributor anstosse (und das zum Xten mal heute) kommt mir der Gedanke, ob es im Amiland eigentlich möglich wäre Adobe zu verklagen, wenn ich durch zu viel Käffchenkonsum beim PDF-Lesen Nebenwirkungen der Käffchenins erleide...

Spannende Überlegung. Aber vor einem EU Gericht wäre da eh nicht viel zu holen. Also wieder zurück an die Arbeit und Prost Käffchen...