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.

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.

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.

Notiz: Vmware Fusion: Word Dateien unter OSX öffnen

Man, das nenne ich mal einen total absurden und kranken Hack, doch was will man machen. Wenn Word unter OSX installiert wurde, möchte man dieses auch gerne nutzen. Nun gibt es Programme (z.B. Schulprogramme) die in einer Windows VM laufen, die bringen einen Haufen Word und Excel Dateien mit und eine dazu passende Software, die diese verwaltet.
Das Problem: die Word Dateien lassen sich nur mit dem OSX Word öffnen, wenn diese in dem Shared Folder von Vmware liegen, zumeist z:\ in dem sich auch der persönliche Ordner vom OSX Benutzer befindet. Nun könnte man einfach dem Installer sagen, er möge das Programm (und damit auch die Word Dateien) auf z:\ installieren. Zu dumm nur, dass viele Installer dies nicht zulassen z.B. „Erlebnis Physik“ aus dem Schroedel Verlag.
Um dennoch zum Ziel zu kommen, verwendet man am einfachsten einen USB Stick und weist ihm einen Laufwerksbuchstaben zu, der später zu einem Netzlaufwerk wird. Hat der Stick den passenden Buchstaben, installiert man das Programm eben auf den Stick. Nach der Installation wird der Ordner in dem das Programm installiert wurde, auf die lokale Festplatte kopiert. Dann wird der Stick entfernt und per „net ‚use p: \\.host\Shared Folders\Programme‘ der selbe Buchstabe und Struktur für das Netzlaufwerk verwendet. Dann wird der Programm Ordner von der lokalen Festplatte eben zurück verschoben. Strukturell hat sich dann nur der Untergrund geändert, aber der Pfad ist geblieben.
Nun kann man das Programm starten und wenn dieses ein Word Dokument öffnet, wird das Word von OSX geöffnet. Natürlich unter der Vorraussetzung, das *.doc etc. dem Vmware-Host Application“ zugewiesen hat.