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:

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.

  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
  4. Wenn keine Referenz mehr in Proxmox genutzt, dann in Proxmox Webseite unter Storage erst VG entfernen, dann ISCSI Target
  5. Auf Konsole VG vollständig auf beliebiger Node löschen (vgremove)
  6. Gerät aus dem LVM entfernen (pvremove)
  7. Name aus multipath -ll entnehmen
  8. 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.
  9. Gerät aus Multipath entfernen
    • multipath -f 26f35644f35736a70
  10. Wenn “map in use”
    • dmsetup --tree prüfen
  11. Dann entfernen: -dmsetup remove jbod2--testvg-vm--121--disk--1
  12. Bei Erfolg, nochmals: -multipath -f 26f35644f35736a70
  13. ISCSI Sessions auflisten:
    • iscsiadm -m session
  14. Bei aktiver session, ausloggen:
    • iscsiadm -m node -T jbod-vmdata-02-test --portal 192.168.1.100 --logout
  15. Dann passendes Portal löschen:
    • iscsiadm -m node -o delete -T jbod-vmdata-02-test --portal 192.168.1.100
  16. Prüfen mittels: iscsiadm -m node | grep jbod-vmdata-02-test ob keins mehr vorhanden ist

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.

Splunk – wie arschig ist das dann!

Ich bin auf der Suche nach einem „hübscheren“ Webinterface für Logdaten, als PHPCon, Alias Loganalyzer (was unter Safari einfach kaputt ist) und wollte mir dann dochmal Splunk anschauen. Da lese ich was passiert, wenn die 60 Tage Testversion aufgelaufen ist und man dann auf die Free Version zurück gestuft wird:

Important: Splunk Free does not include authentication or scheduled searches/alerting. This means that any user accessing your Splunk installation (via Splunk Web or the CLI) will not have to provide credentials. Additionally, scheduled saved searches/alerts will no longer fire.

Da denke ich mir auch nur, wie arschig das ist. Hätte man es nicht bei was anderem belassen können als mal eben die Authentifizierung zu kippen?

Doveadm expunge

Weil ich es mir nicht merken kann:

doveadm expunge -u linuxmail@4lin.net mailbox INBOX/debian savedbefore 1d

Aficio Drucker, Cups und Restriktionen

Kurze Story, lang erzählt.

Auf Arbeit haben mich die letzten Wochen sehr viele Nerven gekostet. Die Aufgabenstellung war eigentlich trivial:

ermögliche Studenten sowohl ihre Freiquota zu nutzen, als auch ihre Mensakarte bei aufgebrauchter Quota.

Als Endgerät wird sowohl ein Ricoh Aficio 4000 als auch ein 5000 eingesetzt. Beide verfügen über einen eingebauten Dokumentenserver (oder auch locked print), der Druckdaten auf die lokale Festplatte ablegt. Diese Dateien können dann am Gerät ausgewählt und gedruckt werden. In unserem Fall muss der Student seine Mensakarte in einen altmodischen Kartenleser stecken, der mittels elektrischen Impuls vom Drucker mitgeteilt bekommt, wie viele Seiten gedruckt wurden, und den Betrag von der Karte abzieht. Beim Einstecken der Karte wird das Bedienpanel freigeschaltet.

Die Entscheidung ob Aufträge nun direkt ausgedruckt, oder auf der Festplatte des Druckers landen, wird per Treibereinstellung definiert. Der Benutzer wählt also selbstständig das Ziel im Druckmenü von seinem Betriebssystem aus.

Die Kunst bestand nun darin, genau das zu unterbinden. Ein Administrator konfiguriert Profile für unterschiedliche Anwendungszwecke und möchte ungern sehen, wie Benutzer dies umgehen.

In einem kontrolliertem Umfeld ist dies noch in Teilen zu realisieren, wobei Windows an dieser Stelle allen anderen Systemen (ich nehme da Novell mal raus) weit voraus ist (sic!). Mittels Gruppenrichtlinien etc. kann man recht viel vor dem Benutzer „schützen“, hat man auch OSX und Linux mit im Boot, sieht es da schon hoffnungsloser aus.

Noch komplizierte wird es, wenn die jeweiligen Rechner gar nicht unter der Kontrolle des Administrators stehen (Stichwort BYOD).

Der Autor hat alle Systeme ausgetestet. Von Linux (OpenSuse12), über OSX 10.9 und Windows 2012r2, bei keinem System gelang es die Druckprofile durchzusetzen. Warum? Ganz einfach: Postscript/PCL. In der Sekunde bei dem der Drucker z.B. Postscript versteht, reichen die Spooler das zu druckende Dokument 1:1 an den Drucker durch (RAW). Innerhalb des Postscript stehen auch alle notwendigen Befehle drin (A4, Schwarz/Weiß, Sortierer, Duplex…) ,aber auch das Ziel, ob Festplatte, oder direkt ausdrucken. Daher werden die definierten Profile ignoriert.

Nun gibt es theoretisch unterschiedliche Möglichkeiten, das Ziel zu erzwingen:

  • Manipulierter Treiber bereitstellen -> unrealistisch, da meist im Betriebssystem vorhanden
  • Filter für Cups schreiben und nicht gewünschte Optionen rausfiltern
  • Backend für Cups schreiben und ebenfalls Filter einbinden

Da ich als Legastheniker in Sachen Programmierung die Filter nicht selbst passend schreiben konnte, fiel mir heute eine weitere Methode ein, das Problem zu lösen: cups-pdf!

Die Idee (sogar schon ein paar Tage alt) war, die Studenten auf einen PDF Drucker drucken zu lassen und die Dateien per Script selbst mit den gewünschten Optionen an den Drucker zu senden. Auf diese Weise entzieht man den Benutzern die Möglichkeit, selbst zu bestimmen, wo und wie das Dokument zum Drucker gelangt.

Die Schlussfrage wäre nur gewesen, wie übermittelt man z.B. den Benutzernamen etc. sodass der Student am Drucker nach seinen Aufträgen suchen kann. Doch es war einfacher als gedacht. cups-pdf besitzt die Option „postprocessing“ in der /etc/cups/cups-pdf.conf. Als Parameter wird ein Script/Kommando angegeben werden, welches ausgeführt wird, nachdem die PDF erstellt wurde.

Ein Beispiel:

#!/bin/bash
CURRENT_PDF="${1}"
CURRENT_USER="${2}"
lp -U $CURRENT_USER -d mensakarte $CURRENT_PDF
rm $CURRENT_PDF

Es gibt also den Drucker „mensakarte“, auf den nur per „localhost“ Cups ACL zugegriffen werden kann. Ein Benutzer druckt auf den PDF Drucker (für den ein Generic Postscript Treiber genügt), das Script erzeugt die PDF Datei, sendet die PDF zum echten Drucker mit den Voreinstellungen von Cups und übermittelt den Benutzernamen. Im Anschluss wird die Datei gelöscht.

Auf diese Weise kann jede Voreinstellung forciert werden, und der Benutzer hat keine Möglichkeit abseits des Formats etwas anderes zu definieren, da alle Postscript Befehle bei der Umwandlung entfernt werden, die den Drucker steuern.

Warum auch immer: in unserem Fall musste ich auch die Länge der Dateinamen der PDF Dateien auf 20 Zeichen beschränken, da sonst der Aficio die Daten nicht akzeptiert hat. Es passierte sonst nichts.

Was für ein Aufwand …

Verkettung von unglücklichen Zeilen

Da wirft man mal ein paar Stunden keinen Blick auf den Server und schon ist dieser eingeschnappt. Beim Umzug von Hetzner wurden einige Zeilen nicht auf einen aktuellen Stand gebracht, die dazu führten, dass Postfix Amok lief. Der Reihe nach:

Auf meiner Dom0 läuft ein lokaler Postfix der eigentlich nicht viel zu tun hat, außer Cron Mails zu verarbeiten. Beim Umzug von Hetzner sind beim Rsync allerdings nicht alle Verzeichnisse und Dateien korrekt angepasst worden, sodass Postfix Amok lief und das Verzeichnis spool/postfix/Maildrop mit zig hunderten/tausenden Dateien befüllte. Jede nur ein paar wenige KB groß, sodass es im Monitoring nicht auffiel. Doch jede Datei benötigt auch eine Inode. Auf ext4 nach wie vor ein wichtiger Faktor.

Es waren dann irgendwann alle Inodes aufgebraucht, sodass Problem Nummer 2 zum tragen kam: LVM. Jede Nacht werden Snapshots für das Backup angelegt. Doch LVM benutzt für sein Locking ebenfalls den selben Einhängepunkt, wie Postfix (/var). Dadurch das Postfix alle Inodes aufgebraucht hat, konnte LVM keine Snapshots anlegen, ja nicht einmal LVs löschen oder sonstwie editieren. Das muss das System dermaßen aus den Tritt gebracht haben, das ein Reboot/Reset ausgelöst wurde. Booten wollte Debian allerdings auch nicht richtig, was Problem Nummer 3 zum Vorschein brachte: Mdadm. Dubioser Weise enthielt /etc/mdadm/mdadm.conf noch das falsche Raid (UUID) und somit auch die Initrd. Was seltsam daran ist, ist die Tatsache, dass das System ja schon bootete … die einzige Erklärung ist demnach, dass beim finalen Rsync die Datei überschrieben wurde uns somit in die Ramdisk gelangte.

Fazit: ein installiertes System per Rsync von A nach B zu schaufeln klappt zwar ganz gut, aber Fallstricke kommen schneller als der Admin denkt.

Abkehr von Hetzner

Durch meinen Nachfolger Admin (CS&T iT-Systemhaus) bin ich zu Hetzner gekommen und das ist jetzt bestimmt rund 5-6 Jahre her. Heutzutage eine relativ lange Zeit, wie ich meine und es hätten noch mehr werden können. Was war passiert? Kurz: Erstens Hetzner will ungenutzte IP Adressen zurück und zweitens wollen sie mehr Geld. Für ersteres habe ich absolut Verständnis, aber für das zweite nicht. Sie wollen nämlich nicht einfach nur für neue IPs und Netze mehr Geld, sondern sie wollen es auch für bestehende, ja selbst für jene, die Anfangs als Dreingabe zum Server dazu gab.

Ich finde die Art und Weise, wie Hetzner da mit seinen Kunden umgegeht eine absolute Frechheit. Für mich hätten dies im Monat 11€ mehr bedeutet und das ohne irgendeinen zusätzlichen Nutzen. Man hat natürlich dann die Wahl gehabt die Netze od. IP Addressen zurück zugeben, die Mehrkosten zu zahlen oder vom Sonderkündigungsrecht von 14 Tagen gebrauch zu machen. Wer da nur ein paar Dinste laufen hat, mag das können, wer mehrere VMs am Start hat etc. pp. dem fällt es dann schon nicht mehr leicht, mal eben einen neuen Hostdienstleister zu finden. Ganz zu schweigen benötigt auch der Domain Registrar Umzug (sofern man wie ich den DNS Robot genutzt hat) einiges an Zeit. Der Umzug von jhell.org kann bis zu 5 Tage benötigen …, aktuell sind schon drei Tage vergangen und sie liegt immer noch bei Hetzner. Fein raus ist der, wer seine Domains eh bei einem externen Registrar hat (so wie ich nun bei InterNetX.de)

Schützenhilfe bekam ich für den neuen Rootserver von Johannes Maus von () (durch meine Anfrage an die Liste der Pug.org), der noch in seinem RZ Ressourcen übrig hatte. Ein verdammt guter Support und völlig unkompliziert. Ich denke, da werde ich ein paar Jahre bleiben.

Moneyplex: Beta und die Schmarotzer

Ich vermute mal, dass ich mit einer der ersten Kunden von Matrica war, der Moneyplex für Linux gekauft (nutzen konnte ich sie nicht, da die Feducia (VB) kein HBCI unterstützte). Damals™, als alles noch besser war. Seither hab ich Versionen für Windows, Linux und seit 2 Jahren auch für OSX. Auch meine andere Hälfte nutzt die OSX Version. Nun liegt es in meiner Natur mir Sorgen zu machen, dass Firmen nicht genügend Geld bekommen, um das Produkt langfristig weiterzuentwickeln. Was macht man als treuer Kunde also? Klar, nachfragen ob man für die aus dem Betastatus gekommene Software auch kaufen darf, obwohl das nicht notwendig wäre, da der hinterlegte Lizenzschlüssel wohl ewig gültig ist.

Die Antwort von Matrica:

Das würde uns natürlich freuen. Denn damit unterstützen Sie uns und

natürlich auch die Weiterentwicklung.

Da Sie moneyplex bereits haben, können Sie natürlich die

Updatekonditionen auf unserer Webseite nutzen.

Tatsächlich sind Sie aber die absolute und löbliche Ausnahme.

Andere Anwender der Beta Version, wehren sich nach zwei Jahren

kostenfreier Nutzung der Software mit Händen und Füssen

und sind der Meinung, dass Sie als Nutzer der Beta Version Anspruch auf eine

kostenlose Vollversion hätten.

Auf solche Leute bekomme ich ja einen Hass. Nur weil sie Betatester waren, die Vollversion nicht kaufen wollen. Ich würde es verstehen, wenn sie geholfen haben Bugs zu finden sowie zu melden und dann nur z.B. den Ppgrade Preis bezahlen möchten, aber so überhaupt nix … Da kann ich nur mit dem Kopf schütteln.

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 12 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.