Tipp: Perlscript hostupd als nsupdate Alternative

Ich bin ja nicht so der Programmierer, daher suche ich mir meist Programme, die können, was ich benötige. In diesem Fall war ich auf der Suche nach einer Alternative für „nsupdate“ aus dem dns-utils Paket, um eine Zone vom Bind9 (Stichwort: DDNS) zu aktualisieren. Geben tut es zwar so einige, aber so richtig funktioniert hat keins, zumal viele auch nur Wrapper Scripte waren. Hostupd ist da eine bequeme Alternative.


./hostupd add host.domain.foo `wget -q -O - http://4lin.net/ip.php` -p -q -s ns1.4lin.net -u -z domain.foo

  • add – fügt den neuen Hosteintrag „host.domain.foo“ hinzu
  • wget … – holt sich die aktuelle IP vom Server
  • -p – PTR brauche ich nicht
  • -q – Nicht zuviele Ausgaben
  • -s – Der entsprechende DNS Server
  • -u – Update, wenn es den Eintrag schon gibt
  • -z – Die Zone, in welcher der Eintrag hinzugefügt werden soll

Das Programm verwendet auch noch eine kleine Konfigurations- Datei, in welcher unter anderem der DNS Key abgelegt wird, für die Legitimation. Wie man Bind9 selbst einrichtet, kann man zuhauf im Netz nachlesen.

Dracut – Die Alternative für initramfs-tools

Alle paar Schaltjahre begebe ich mich auf die Suche, ob es mittlerweile möglich ist, unsere „diskless“ Debian Clients statt via NFSv3 über NFSv4 zu booten. Ich würde mir ein wenig flotteres booten versprechen und eine ungleich einfachere Firewall. Die Initram bietet diese Möglichkeit nach wie vor nicht und das wird sicher auch noch eine Weile so bleiben, wenn man Google so befragt. Doch der gestrige Tag brachte einen Lichtblick: Dracut. Dracut gibt es schon seit einiger Zeit, ist mir aber nur über einen Bug Eintrag („[…] just for the records [..]“) über den Weg gelaufen, dass Dracut in der Lage ist NFSv4 für das Rootfs zu verwenden. Da sah ich schon das Funkeln in meinen Augen, als ich schnell mit dem IPhone mein Gesicht kontrollierte.

Kurz: es funktioniert tatsächlich!

Lang: Es ist besser, wenn ihr euch halbwegs aktuelle Quellen von Dracut besorgt, da die Debian Squeeze Version mit 0.05 (aktuell 0.20) wirklich alt ist. Allerdings gelang es mir nicht ohne viel Zeit zu investieren, 0.20 zu übersetzen. Make brach mit irgendwelchen Fehlern ab, doch 0.19 klappte auf Anhieb. ein anschließendes „make install“ bringt die Dateien an Ort und stelle, sodass man zügig die erste initrd erzeugen kann:


# dracut -f -i /etc/dracut/hooks/pre-pivot/create-dirs.sh \
/lib/dracut/hooks/pre-pivot -m "nfs network base" -H dracut.img

  • -f Force
  • -i Die Datei create-dirs.sh in die initrd packen, nach /lib/dracut/hooks/pre-pivot
  • -m Zusätzliche Module – wobei keine Kernel Module gemeint sind, sondern eher Plugins
  • -H Nur wirklich benötigte Kernel Module, für diesen Rechner einbinden
  • dracut.img Selbst gewählter Dateiname, für die neue Ramdisk

Das Verzeichnis „/etc/dracut/hooks/pre-pivot/“ plus die Datei habe ich selbst erstellt. In meinem Fall benötige ich vor dem Pivot einfach zusätzlich Ordner und Ramdisks. Wichtig ist: Die Scripte müssen auf „*.sh“ enden.
Ansonsten gibt es noch die /etc/dracut.conf, in der ich ebenfalls noch Module einbinden kann, aber nicht muss (z.B. benötige ich kein LVM / MDADM):


#dracutmodules=""

# Dracut modules to omit
#omit_dracutmodules=""

# Dracut modules to add to the default
add_dracutmodules="busybox plymouth"

# additional kernel modules to the default
#add_drivers=""

# list of kernel filesystem modules to be included in the generic initramfs
#filesystems=""

# build initrd only to boot current hardware
hostonly="yes"

# install local /etc/mdadm.conf
mdadmconf="no"

# install local /etc/lvm/lvm.conf
lvmconf="no"

Wie man sieht, habe ich noch die Busybox (für chmod und co) eingebaut und Plymouth. Da Dracut aus den Quellen installiert wurde, stimmen einige Pfade nicht, wenn z.B. Plymouth eingebunden werden soll. Diese Pfade stehen in den Modulen unter /usr/lib/dracut/modules.d/, welche angepasst werden sollten/müssen/können.

Da ich den NFS Pfad etc. per DHCP übergebe, benötige ich an dieser Stelle keine weitere Konfiguration. Spannend wird es dann, wenn es nicht gleich auf Anhieb klappt. Dracut bietet einige Hooks an, die z.B. die Debug Funktion der Shell (sh -x) aktiviert, od. bevor der Pivot erfolgt mich auf eine Kommandozeile schmeißt. Auf diese weise lässt sich prüfen, was nicht funktioniert.

Tja, bei mir hat es theoretisch super geklappt, leider kann ich das noch nicht ins Produktiv- System überspielen, da es dummerweise im AuFS Dateisystem einen Bug gibt, der verhindert, dass richtig gelesen / geschrieben werden kann.

Nichts desto trotz … Dracut ist eine Lösung, die bei mir Initramfs auf lange Sicht bestimmt ersetzen wird.

Notiz: Linux + Acer + EDID + 640×480 + Nvidia

Es gibt Firmen, denen sollte man den Zugang zu wertvollen Rohstoffen und Arbeitskräften verweigern. Ganz klar oben auf der Liste steht Acer. Grund sind die ~105 (+ einer in Reparatur, wegen exakt diesem Problem) Acer Monitore, mit Namen H243HX, die scheinbar nach und nach sich selbst, bzw. ihre EDID Informationen verstümmeln, sodass sich Nvidia weigert, die Monitore mit ihrer normalen Auflösung anzusprechen. Stattdessen erhält man nur 640×480. Um es dem Support noch spannender zu gestalten, tritt das Problem natürlich häufiger unter Linux auf, als unter Windows. Wie auch immer, heute fand ich einen sehr schönen Blogeintrag, der sich dem Problem annimmt.

In meinem Fall ist die Lösung etwas einfacher:

An einen Rechner setzen, bei dem das Problem noch nicht auftritt:

  1. sudo nvidia-settings unter X starten
  2. DFP-0/1 anklicken
  3. „Acquire EDID“
  4. Datei passend ablegen, z.B. /etc/X11/acer_h243hx.edid

/etc/xorg.conf anpassen


Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce 9300 / nForce 730i"
Option "DynamicTwinView" "0"
Option "CustomEDID" "DFP-1:/etc/X11/acer_h243hx.edid
EndSection

Da wir ein einziges Image ausrollen, muss ich das nur am Masterimage anpassen und es dann ausrollen lassen. Damit bekommen auch all die anderen Rechner die neue Information verpasst und es dürfte nun egal sein, wenn ein weiterer Acer sich selbst verstümmelt. Allerdings habe ich ein Exemplar, da stimmt noch nochmal die Auflösung auf Biosebene, somit erkennt auch der Kernel nicht mehr, was er für den VESA Mode verwenden kann und fragt entsprechend nach.

Grafik der Postfix Architektur in groß

Da will man mal eben die Postfix Architektur plotten und muss dann feststellen, dass es keine gibt, die sich zum plotten eignen würde. Daher mal eben eine selbst erstellt, die gut auf ein DinA1 passt. Später stelle ich noch eine SVG Variante bereit, damit die Größe dann egal ist.

Hier ist sie.

Postfix architecture

Postfix architecture

So, hier die versprochende SVG Grafik, hinterlegt bei Wikipedia: http://upload.wikimedia.org/wikipedia/de/5/51/Postfix-arch.svg

Solaris Jumpstart von Linux (Debian) aus

Damit ich das nochmal hinbekomme, habe ich mir einen kleinen Notizzettel geschrieben, wie man Jumpstart von einer Linux Kiste aus initiieren kann, ohne dass man sich von Hand erstmal eine Solaris Kiste installieren muss.

https://www.pug.org/mediawiki/index.php/Solaris_Jumpstart_von_Linux

Haut mich nicht wegen dem Finish Script, das ist nur zusammen gestückelt.

Fai Anleitung um von X86 eine Sparc zu betanken + Vorgeschichte

Meine Güte, was für ein Stress. In den letzten Wochen – achwas, Monaten – suche ich nach einer gangbaren Alternative zum verhassten Solaris10. Dieses Betriebssystem hat mich in zwei Jahren mehr Nerven gekostet, als Windows in 10(!). Für jeden Scheiß braucht es unter Solaris irgendwelche Workarounds, spezial Parameter oder obskure Dateien, um halbwegs aktuelle Software installieren zu können. Wer dann in der SunSW, CSW, SunFreeWare, /usr/local Hölle angekommen ist, für den ist die DLL Geschichte von damals(tm) nicht mehr als ein Augenzwinkern. Klar, man kann auch nehmen, was Sun einem bietet, die Kiste einmauern und hoffen, dass dem Hacker/Cracker das Ding zu halt ist, um näher betrachtet zu werden, aber darauf verlassen würde ich mich nicht. Bis dahin würde die Kiste sicher klaglos, bis in die Unendlichkeit und noch viel weiter, laufen.
Wer sich sagt: na, dann nehme ich doch einfach Solaris11?! Tja, dann sicher zum studieren, um eigene Software zu testen oder um 30 Tage Spaß zu haben, danach wird es teuer. Wer nicht bereit ist, mit Oracle einen (Ehe-)Vertrag einzugehen (wir bekommen dein Haus, und du bezahlst die Miete) und dennoch die SPARC Rechner nicht bei Ebay verscherbeln möchte, braucht etwas anderes, als Solaris10.

Ich hatte einen Exkurs mit FreeBSD und das sah soweit OK aus, allerdings merkt man sehr schnell, dass auch die FreeBSD Menschen nur selten Leute wie mich treffen, die da was anderes als Solaris drauf haben wollen. Fast hätte es geklappt, wären die Jails mit VNET stabil gelaufen. Doch es wäre nur eine Frage der Zeit gewesen, wieder gegen eine Wand zu laufen. Spätestens beim Versuch eine T2000 zu installieren. Die wird von FreeBSD9 nämlich nicht unterstützt. Yeahh..

Also doch wieder zu Linux. Und es soll mir keiner sagen, ich würde mal nicht über den Tellerrand schauen. 2.6.39 + Linux Container (LXC) = effiziente Hardwarenutzung.

So, da ich nun einige dieser Kisten habe und das Ziel sein soll, mittels Fai + Puppet + Backup einen ausgefallenen Rechner innerhalb von Zeitraum X wieder in Betrieb zu nehmen, durfte ich mich nun mit Fai auseinander setzen. Ich sag euch, … ihr seid mit SPARC wieder (nahezu) allein. Das fängt damit an, dass OpenBoot von der Sunfire v245 nur maximal 9,5MB als (TFTP) Image zulässt. Versucht mal einen Kernel + Initrd zu erstellen, der diese Kriterien erfüllt. Ich habe Stunden damit zubracht, passendes zurecht zu basteln. Dann geht es weiter mit der SUN Partitionierung, die Fai nicht beherrscht (Squeeze Version), aka -> alles selbst machen, und dann endet es irgendwo beim Bootloader Silo.

Kurzum, rund zwei Wochen mit „Try and Error“ verbracht. Doch jetzt steht die Anleitung für die wenigen (deutschsprachigen) Menschen auf der Welt, die ebenfalls gezwungen werden, aktuelle Software einzusetzen, flexibel zu sein und Oracle nicht ein Mitspracherecht auf das Konto einräumen wollen.

Zur Anleitung

Viel Spaß damit.

ps. Da die Rechtschreibkorrektur aktuell im Firefox nicht klappt, können noch Fehler enthalten sein. Ich werde sie nach und nach korrigieren.

Notiz: Nvidia / Acer Problem (checksum for EDID version 1 is invalid)

Fast hätte ich zwei Monitor eingesendet, weil Xorg sich weigerte, die Acer Monitore mit ihre nativen Auflösung anzusprechen, statt 640×480. Kurios an der Stelle: von 110 Stück tritt das Problem bisher bei zweien auf. Da alle das selbe Image erhalten (NFS Root) muss es ein Problem der Acer Monitore sein. Es tritt auch nur dann auf, wenn die Monitore längere Zeit am Stromnetz hängen / verwendet werden. Wird der Monitor gegen das selbe Model getauscht, reicht ein Xorg Neustart …

Wie auch immer: wenn die Meldung: „checksum for EDID version 1 is invalid“ in der xorg.log auftaucht, dann in der Screen Sektion der xorg.conf folgende Zeilen hinzufügen:


# Wegen 640 x 480 Nvidia / Acer Monitor Problem
Option "IgnoreEDIDChecksum" "DFP-1"
Option "ModeValidation" "NoDFPNativeResolutionCheck"

Dann klappt es wieder.