Proxmox: ISCSI aus dem System werfen (auch mit Multipath)

ProxMox macht es einem einfach, neue ISCSI Targets ins System aufzunehmen. Ein Klick im Admincenter und schon kann man los legen. Will man das Target allerdings wieder loswerden, wird es schon nicht mehr so trivial. Wurden sämtliche ISCSI Geräte von VMs befreit, sodass die Targets ungenutzt sind, lassen die sich zwar aus dem Webinterface entfernen (Storage …), aber dann sind sie nur aus dem Blick, nicht jedoch aus dem Sinn. Die ISCSI Targets sind nach wie vor verfügbar, was spätestens ein Blick mit „iscsiadm node“ bzw. statt „node“ auch „session“ zeigt. Hat man es nicht nur mit einer einzelnen Node zu tun, sondern hat einen ProxMox Cluster, wird es 1*n mal so hässlich.
Kommt man auf die böse Idee das ISCSI Target auf der ISCSI Serverseite zu entfernen, friert die Node unter Umständen ein, bzw. wirft Haufen Fehler, weil die Geräte nicht mehr verfügbar sind, besonders „multipath“ fängt kräftig an zu jammern.

Hier also mein Notizzettel (ungefiltert) , wie die „Geräte“ sauber aus dem System entfernt werden können – ohne Reboot der Node.

ISCSI Target aus Proxmox entfernen

1. Alle VMs auf anderes Gerät migrieren / local / anderes ISCSI Target
2. Alte LVs in Proxmox löschen (meist unused disk in jeweiliger VM)
3. Prüfen auf Konsole mit lvscan, ob wirklich keine VM mehr die VG verwendet
3. Wenn keine Referenz mehr in Proxmox genutzt, dann in Proxmox Webseite unter Storage
erst VG entfernen, dann ISCSI Target
4. Auf Konsole VG vollständig auf beliebiger Node löschen (vgremove)
5. Gerät aus dem LVM entfernen (pvremove)
6. Name aus Multipath -ll entnehmen:

26f35644f35736a70 dm-5 SCST_BIO,o5dO5sjpPn4ZxszR
size=3.9T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 13:0:0:0 sdh 8:112 active ready running
|- 15:0:0:0 sdi 8:128 active ready running
|- 16:0:0:0 sdj 8:144 active ready running
`- 17:0:0:0 sdk 8:160 active ready running

"o5dO5sjpPn4ZxszR" ist Name vom ISCSI Target -> verifizieren über den ISCSI Server, ob das
wirklich das zu löschende ist

"26f35644f35736a70" ist der Name des Multipath Gerätes

7. Gerät aus Multipath entfernen -> multipath -f 26f35644f35736a70
7.1 Wenn "map in use" -> dmsetup --tree prüfen
7.2 Dann entfernen: dmsetup remove jbod2--testvg-vm--121--disk--1
7.3 Bei Erfolg, nochmals multipath -f 26f35644f35736a70

8. ISCSI Sessions auflisten: iscsiadm -m session
9. Bei aktiver session, ausloggen: iscsiadm -m node -T jbod-vmdata-02-test --portal 192.168.1.100 --logout
10. Dann passendes Portal löschen: iscsiadm -m node -o delete -T jbod-vmdata-02-test --portal 192.168.1.100
11. Prüfen mittels: iscsiadm -m node | grep jbod-vmdata-02-test ob keins mehr vorhanden ist
12. Gegebenenfalls für alle weiteren Portale wiederholen

Wer es mit mehr als einer Node zu tun hat, sollte zu einem Cluster SSH greifen, um alle Kommandos parallel an allen n-Nodes auszuführen.

Puppet 3.x unter Debian Squeeze mit LDAP und Dashboard

Da ich mich gerade mit Puppet beschäftige, musste ich mir mal meinen Zeilen zusammenschreiben, um bei der nächsten Installation nicht wieder ewig die Teile zusammen suchen zu müssen. Die Dokumentation ist manchmal so löchrig, was Puppet 3.x angeht, dass ein Großteil der Anleitungen überhaupt nicht funktionieren. Bis alles lief, sind mal locker 2 1/2 Arbeitstage draufgegangen, da jede Fehlerzeile wieder ewiges Suchen nach sich zog. Wie auch immer, die Zeilen sind eine Kombination aus der Bash History und meinem Kopf entsprungen, aber hoffe inständig, dass es weitestgehend vollständig ist.

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

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.

Notiz: Solaris NFS4 Server + Linux NFS4 Client und chgrp

Hat man einen Solaris NFS4 Server und einen NFS4 Client mittels Linux, muss man darauf achten, dass Linux Gruppen (die Namen(!) ) nur selten auch auf Solaris Seite vorhanden sind. Das hat zur Konsequenz, dass z.B. ein „chgrp shadow“ od. ein „chown 0:42“ auf der NFS Clientseite fehl schlägt, da es die Gruppe „shadow“ nicht gibt. NFS4 überträgt nämlich den Namen, gibt es ihn nicht, meldet tar zB. ein exit 1.

Lösung daher, alle benötigten Gruppen von Linux, müssen auch unter Solaris vorhanden sein. Die selbe ID ist allerdings nicht notwendig, aber hilfreich, doch leider nicht immer frei.

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.

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.