Schlagwort-Archive: Linux

ZFS/ZOL: Pool UNAVAIL nach Reboot

Nicht schön. Nach dem Reboot eines Server musste ich feststellen, dass diverse Storages nicht mehr zugreifbar waren. Schnell stellte sich heraus, dass alle ZFS-Pools offline waren und die Geräte mit der Meldung „too many errors“ als FAULTED markiert wurden.

Nunja, Consumer-Platten traue ich ja viele defekte zu, aber drei unabhängige Platten gleichzeitig? Eher nein. Auch S.M.A.R.T. zeigte keine wirklich bedenkenswerten Werte. Aufschlussreicher ist da schon das Kernel-Log:

*kick* Da war ja was. ZOL läuft wegen der Lizenzproblematik als Kernel-Modul. Ich hatte zuletzt am Kernel einige Treiber nachgezogen. Hierbei sind zwar Version und Ablageort gleich geblieben, offenbar ist aber die ABI etwas gewandert, sodass SPL/ZFS etwas verwirrt den Dienst quittierten.

Für Gentoo heißt das einmal Module neu Bauen, in meinem Fall

 

Alternativ und in den meisten Fällen zuverlässiger ist es nach jeder Kernel-Änderung alle Module automatisch neu zu erstellen:

Storage online, Admins glücklich, Update-Doku ergänzt. Passt.

STDOUT verdoppeln mit ftee

Mal wieder eine etwas andere Anforderung: Für eine automatische Verarbeitung soll eine Audioquelle durch eine Software auf der Konsole ausgewertet werden. Die Software ist hierbei für die Analyse von Dateien ausgelegt, kann allerdings auch von STDIN lesen. So weit kein Problem – arecord kümmert sich um die Aufnahme und per STDOUT/Pipe geht es in die Analysesoftware. Leider gibt es hier einen Haken: Es funktioniert nicht zuverlässig. Um zu prüfen ob die Audioquelle oder die Analyse das Problem verursacht müsste ich die eingehenden Audiodateien abhören. Am PC ginge das mit Pulseaudio recht einfach, am Server möchte ich auf dieses Ressourcen- und Dependency-Monster jedoch vorzugsweise verzichten.

Dann halt per File

Meine erste Idee: tee. Mit diesem Befehl kann man die Dateien einer Pipe in eine zusätzliche Datei „abzwacken“:

Was prinzipiell funktioniert hat jedoch einen entscheidenden Nachteil: Es landet alles in der Datei. Dauerhaft. Möchte man nicht, dass die Festplatte voll läuft, muss man nach dem reinhören das Konstrukt abbrechen und ohne tee-Befehl neu starten. Eher unschön, denn das heißt auch Deattime, also eine kurze Zeitspanne in der ich möglicherweise Ereignisse verpasse.

Und was ist mit FIFO?

Als Alternative eignet sich ein FIFO, auch als named Pipe bezeichnet. Diese lassen sich mit mkfifo anlegen und stellen sozusagen einen „Puffer“ zur Verfügung, über den sich Prozesse verbinden lassen. Hier können wir im ersten Terminal z.B. wie folgt starten:

und im Zweiten den Stream abgreifen

Dummerweise gibt es auch hier Probleme: Es blockiert. Der Analyzer im ersten Terminal wird erst gestartet, wenn wir im Zweiten beginnen den Puffer zu lesen. Schlimmer noch: Brechen wir im zweiten Terminal das Mitlesen ab wird auch der Analyzer beendet. Nicht wirklich was ich suche.

Dauer-Interimslösung

Nunja, da mir die Ideen ausgingen und das Internet auf den ersten Blick nichts passendes lieferte blieb es erst mal bei der dauerhaften Dateiaufzeichnung auf einen speziell limitierten Ordner. Lief alle paar Wochen die zugehörige Partition voll brach die Software ab und ich startete per Hand neu. Auf der Todo-Liste stand etwas von automatischen Neustarts oder einem Gebastel um nur bei Bedarf die Ausgabe zur named Pipe zu starten. Dieser Zustand hielt nun für etwa 2 Jahre.

Rettung bei Stackoverflow

Heute ging es dann um die Behebung. Ich hatte grade ein Rendering gestartet und entsprechend etwas Leerlauf als die altbekannte Mail kam: Partition voll, die Erkennung steht. Jetzt reicht es. Also schnell auf Google und etwas in die Verwendung von Named Pipes einlesen.

Moment.

Nach kurzer Recherche landete ich bei Stackoverflow (wo auch sonst). Nach „Linux non-blocking fifo“ erkundigt sich der Autor „Dronus“ und beschreibt ein Szenario, welches recht Nah an meine Andorderungen heran kam. Und Beantworter „racic“ lieferte auf ganzer Linie: „ftee“ nennt sich sein überschaubarer C-Code, welcher das verhalten von tee nachmacht, jedoch für den FIFO nicht blockiert. Auch wird SIGPIPE, welches beim Abbrechen des Lesevorgangs der Pipe ausgelöst wird, nicht beachtet, der Analyzer läuft also fleißig weiter. Greift man später erneut auf die Pipe zu erhält man wieder die aktuellen Daten.

Wer „wichtige“ Daten nutzt kann alternativ auf das ebenfalls dort zu findende bftee von Fabraxias zurückgreifen, welches bei einem Abbruch der Verbindung alle eingehenden Daten zwischenspeichert und bei der nächsten Verbindung erst einmal nachliefert.

Für mich ist die nicht gepufferte Variante ideal – alte Audiodaten sind für mich nicht relevant. Das Kompilieren ist mit aktuellem GCC schnell erledigt und allein das ersetzen von tee gegen ftee im vorherigen Beispiel löst alle Probleme. Der Analyzer läuft und ich kann bei Bedarf in den Audiostream reinhören ohne eine Unterbrechung der Auswertung zu bekommen. Fein.

rsync vs. curlftpfs: mkstemp-Fehler

Hach ja, wenn Theorie und Praxis mal passen würden. Bei vielen meiner Server bietet der Anbieter einen kostenfreien Backupspeicher an. Gut, ob man dem Vertraut steht wo anders, aber eine weitere (verschlüsselte) Kopie kann ja nicht schaden, richtig?

Am schönsten wäre es für mich Borg einfach ein weiteres Repo auf dem Backupspeicher anlegen zu lassen. Leider gibt es da ein Problem: Der Anbieter bietet den Zugriff nur per FTP an, welches von Borg nicht nativ unterstützt wird.

Zwar ist es mit curlftpfs möglich den Server als lokalen Ordner einzubinden, allerdings unterstützt der Dateisystemtreiber viele Standardoperationen nicht wirklich und hat seit 2008 kein Update mehr gesehen. Mangels Alternativen bleibt wohl nur herumbasteln. Leider konnte ich mit keiner noch so exotischen Kombination – egal ob mount-Parameter oder loop-Devices – eine Funktionierende Umgebung für Borg kreieren, also muss ein weiterer Umweg als Workaround her.

Da lokal genug Platz vorhanden ist lautet das Konzept: Borg sichert in einen lokalen Ordner, der wird dann auf den FTP gespiegelt. Klarer Job für rsync, oder? Naja, sieht die Software anders:

Glücklicherweise betrifft das Problem wohl ausschließlich die mkstemp-Funktion, welche rsync nur für temporäre Kopien benötigt. Diese werden Standardmäßig auf dem Ziel erstellt, lassen sich über einen passenden Parameter aber auch in anderen, lokalen Ordnern ablegen. Der komplette Befehl lautet dann z.B.

So werden nur noch die wirklichen Zieldaten auf dem FTP-Server abgelegt und die Kopie scheint zuverlässig zu funktionieren. Alles nicht sonderlich schön, aber immerhin funktioniert das Konstrukt und eine weitere Kopie liegt irgendwo rum. Man könnte natürlich auch einfach NFS/iSCSI/… anbieten, aber das wäre ja moderne Technik…

BitBastelei #204 – Linux-Shell-Erweiterung: Powerline für Bash/vim/tmux & Co

powerline-miniAls Bastler arbeite ich recht viel auf der Linux-Konsole – ein mächtiges Werkzeug, aber nicht unbedingt übersichtlich. Mit dem Tool „powerline“ kann man mit überschaubarem Aufwand die Shell aufhübschen und um diverse Widgets ergänzen. Während Dinge wie Wettervorhersage für mich eher nach unnötiger Spielerei aussehen sind z.B. Statusinformationen in GIT-Ordnern oder der aktuelle Batteriezustand wertvolle Helfer.

Die Installation kann bei Arch, Gentoo und Debian über bereitgestellte Pakete erfolgen, alternativ lässt sich der distributionsunabhängige Python-Paketmanager „pip“ verwenden. Alle Installationsmethoden werden in der Doku beschrieben.

Konfigurationen

https://gist.github.com/adlerweb/14f7543479645483b01e679d7ca307b7

 

virt-manager/libvirt: Installation nicht möglich: virtlogd-sock

Beim Erstellen einer neuen VM über virt-manager erhielt ich heute folgende Meldung:

Ursache ist das Logging, welches in einen eigenen Dienst ausgelagert wurde. Neben libvirtd muss nun auch virtlogd vor dem Start der VM geladen werden. Für systemd-Nutzer heißt das also…

 

Gentoo: Pakete von Distcc/pump ausnehmen

Verteiltes Kompilieren mit distcc und pump macht vor allem auf langsamen Systemen eine Menge Sinn. Leider vertragen nicht alle Pakete diese Lastverteilung, so z.B. mysql/mariadb. Um einzelne Pakete von distcc oder pump auszunehmen geht man wie folgt vor:

Folgende Dateien erstellen:

Nun ggf. den Ordner /etc/portage/package.env anlegen und dort – analog zu package.use/package.keywords/… – dateien für die Pakete anlegen, z.B.

So wird z.B. für MariaDB der Pump-Modus abgeschaltet, distcc bleibt jedoch aktiv. Alternativ kann die ebenfalls erstellte no-distcc.conf verwendet werden um das verteilte Kompilieren komplett zu unterbinden.

Synergy 1.7.6 (Pro) unter Gentoo nutzen

Synerwas?

Synergy ist eine Software um eine Tastatus/Maus-Kombination mit mehreren Rechnern nutzen zu können. Bewegt man z.B. die Maus am Haput-PC an den rechten Bildschirmrand steuert man fortan den danebenstehenden Laptop. Sehr praktisch, wenn man viele Systeme nebeneinander stehen hat. Alles konfigurierbar, versteht sich.

Leider hat die Software einen faden Beigeschmack: Zwar ist der Kern Open Source (GPL), wird vom Hersteller aber nur noch gegen Geld zum Download angeboten. Neue Funktionen sind ebenfalls nur noch mit DRM-online-Aktivierung verfügbar und während die Anpassung an neue Betriebssysteme soweit zügig von statten geht ist die Stabilität in meinen Augen eher auf dem absteigenden Ast.

Wie auch immer: Ich komme nicht drumrum. An einem Arbeitsplatz stehen 4 Rechner nebeneinander und ich habe keinen Nerv ständig die Tastaturen zu wechseln. Da ich dank einer Spende aus Full-Open-Source-Zeiten einen Zugang zu den Downloads habe und meine bisherige Version mit Windows 10 und Server 2016 einige Probleme hat heißt es Aktualisieren.

TLS? Proxy? WTF?

Also rauf auf die Webseite, Login-Formular ausgefüllt und … man landet auf einer HTTP-Seite. Auf der das Login-Cookie unverschlüsselt durch die Gegend geht. Great.

Weiter mit dem Windows-Setup. Installieren, aktivieren. Immerhin: Bei der Aktivierung wird offenbar die OS-API verwendet und der Request augenscheinlich per TLS mit OCSP-Abfrage über den Systemproxy übermittelt. Beim anschließenden Download der Plugins ist dann jedoch Schluss: Direktes CONNECT ohne Möglichkeit einen Proxy einzustellen. Ohne direkten Internetzugriff am Rechner also nicht viel Möglichkeiten.

Konfigurationsterror

Die Konfiguration gestaltet sich mühselig, da Dienst und GUI ständig abstürzten. Letztendlich griff ich auf den Texteditor für die Konfigurationsdatei zurück. Das ging in der Vorversion rigendwie besser. Immerhin: Im Betrieb scheint es bisher stabil zu funktionieren.

Linux? Eat my binary!

Etwas mehr Probleme hatte ich jedoch mit Linux: Im Konstrukt ist ein Gentoo-Rechner, welcher ebenfalls gesteuert werden soll. Die aktuelle Version ist dank GPL über Portage verfügbar und schnell kompiliert und installiert. Nach Eingabe meiner Zugangsdaten verwandelt sie sich nach kurzem Plugin-Download zur Pro-Version. Immerhin. Nur Verbinden geht nicht.

Auslöser ist die Pro-Version: Diese kann – im Gegensatz zum OSS-Kern – eine Verschlüsselte Verbindung zwischen den beteiligten Rechnern nutzen, sodass nicht jeder Netznutzer alle Tastenanschläge mitlesen kann. Dieses Pro-Feature ist jedoch nicht in den Quellcodes vorhanden sondern wird als „Plugin“ bei der Installation heruntergeladen und in ~/.synergy/plugins/ deponiert. Plugin heißt hierbei .so-Library. In Binär. Natürlich gelinkt gegen Bibliotheken bzw. Dateinamen, die ich nicht habe.

Konkret geht es um folgende Liste:

  • linux-vdso.so.1
  • libpthread.so.0
  • libcurl.so.4
  • libSM.so.6
  • libICE.so.6
  • libXtst.so.6
  • libX11.so.6
  • libXext.so.6
  • libXinerama.so.1
  • libXrandr.so.2
  • libXi.so.6
  • libssl.so.10
  • libcrypto.so.10
  • libdl.so.2
  • libstdc++.so.6
  • libm.so.6
  • libgcc_s.so.1
  • libc.so.6
  • libidn.so.11
  • libldap-2.4.so.2
  • liblber-2.4.so.2
  • libresolv.so.2
  • libgnutls.so.28
  • libgcrypt.so.20
  • libz.so.1
  • libuuid.so.1
  • libxcb.so.1
  • libXrender.so.1
  • libtasn1.so.6
  • libnettle.so.6
  • libhogweed.so.4
  • libgmp.so.10
  • libgpg-error.so.0
  • libXau.so.6
  • libXdmcp.so.6

Die Libraries selbst sollten auf einem Desktop-System meist vorhanden sein, nachinstallieren musste ich jedenfalls bei mir nichts. Problematisch waren jedoch libssl.so.10 und libcrypto.so.10 – diese sind unter Gentoo nicht verfügbar und dürften sich auf OpenSSL mit einer Version >= 1.0 beziehen. Die Dateibenennung scheint dabei von Debian(?) zu stammen und wird bei Gentoo anders durchgeführt. Da hierdurch das Plugin nicht lädt wird es ignoriert und die Verbindung zu dem bereits eingerichteten Windows-Clients schlägt, wegen der fehlenden Cryptofunktion, fehl. Zwar erscheint dies auch im Synergy-Log, versteckt sich aber zwischen den ganzen Connect-Nachrichten und ist schnell zu übersehen:

Als Quick’n’Dirty-Workarround habe ich bei mir die angemeckerten Dateinamen als Symlink auf die echten OpenSSL-Files angelegt.

Zumindest für’s erste ist hiermit das Plugin funktionsfähig und die Software wieder nutzbar. Sonderlich schön ist es trotzdem nicht.

Veeam B&R: „Auf das verworfene Objekt kann nicht zugegriffen werden. Objektname: System.Net.Sockets.Socket“

Tolle Meldung, die das Backupsystem „Veeam Backup&Replication“ da abwirft:

…heißt es lapidar in der GUI, die sonst nur darüber informiert, dass kein Backup mehr funktioniert. Zwar ist recht klar, dass es am Netzwerk hängen dürfte, da hier aber pro VM-Sicherung mindestens 5 Server involviert sind gestaltet sich das etwas aufwändiger.  Vor allem wenn alle relevanten Systeme fehlerfrei auf ICMP-Ping reagierten.

Tiefer im Log des Jobs fand sich eine Meldung, welche auf einen Fehler des Backupziels hindeutet. In meinem Fall handelt es sich hierbei um einen Linux-Server, welcher übers Netz beschickt wird.

Uhmk? Im Monitoring war nichts zu sehen, außerdem kommt ja der SSH-Header. Schnell mal per KVM auf die Kiste und geprüft:

Also uname sollte also funktionieren. Auch der SSH-Daemon läuft noch. Im Log sind jedoch einige Meldungen, die möglicherweise das Problem beschreiben:

freedesktop? Das ding ist Xless -.-. Übeltäter ist wieder einmal „Server sind ja nur Ausnahmeerscheinungen“ Systemd. Dessen Loginmanager bekommt Schluckauf wenn, z.B. im Rahmen von Updated, dbus neu gestartet wird. Als Ergebnis lässt sich PAM bei Logins durchaus mal 15 Sekunden Zeit um in den Timeout zu laufen. Je nach Client/Verbindungsart kann dies jedoch bereits zum Timeout der gesamten Verbindung führen – und nichts geht mehr. um den Fehler zu beheben reicht es aus den Logind neu zu starten:

Warum ein System, was sonst ja auch alles „on demand“ startet/stoppt/überwacht, sowas seit offenbar langer Zeit nicht in den Griff bekommt bleibt offen. Ebenso wie die Frage, warum Veeam keine genaueren Fehlermeldungen liefert.

QEMU: Festplatten als SATA/AHCI einbinden

Physikalische Remote-Server aufsetzen macht ohne KVM-IP eher wenig Spaß. Groß ist die Gefahr, dass durch Kernel-Updates oder spielen am Bootloader die Kiste nach einem Reboot nicht mehr bootet. Wäre es nicht praktisch, wenn man die Platten nicht kurz in eine VM werfen und da booten könnte?

QEMU ist – spätestens mit KVM – sicher der schnellste Weg, das übliche -hda bindet die Festplatten jedoch als IDE-Geräte ein. Schlecht, wenn man nur AHCI, also SATA, in fstab, Treibern & Co vorgesehen hat.

Abhilfe schaffen folgende Parameter, welche mir bei Rubénerd über den Weg gelaufen sind:

Wichtig: Hierbei sollte das System im Haupt-OS nicht eingehangen oder Read-Only sein. Sowas ist üblicherweise nur mit einem Rettungssystem möglich, andernfalls kann es zu Dateisystemschäden kommen. Alternativ könnte confinedrv helfen eine Testumgebung zu schaffen.

Now fail already! Wenn der Browser über Umwege XOrg lahmlegt

Ugh. Schon wieder. Das Rattern in der Ecke hat meist eine recht konstante Ursache: Die CPU meines Laptops läuft auf 100% und sorgt für ordentliche Lüfterdrehzahlen. Gehen wir mal auf Ursachensuche:

Bei CPU-Last ist erster Anlaufpunkt natürlich top/htop. In meinem Fall aber leider nicht sehr Hilfreich: Xorg sei der Verursacher. Weites Feld. Aus meiner Erfahrung geht dann der Blick erst mal auf die laufenden Programme. Nicht selten hat sich auf einer geöffneten Webseite eine Flash-Werbung, ein HTML5-Video oder sonstige zappelnde Dinge mit Nervfaktor versteckt und bringen das Rendering in Gang. Leider konnte ich dieses mal nichts finden. Auch der interne Taskmanager von Google Chrome zeigt – anders als in solchen Fällen üblich – keine auffällig hohen Lasten. Um sicher zu gehen halte ich per SIGSTOP alle UI-Programme kurz an – keine Änderung. Es ist also mit hoher Wahrscheinlichkeit keine Grafikausgabe, welche die Probleme auslöst.

Zurück zum Start. Wir wissen, dass Xorg die Last bringt, allerdings vermutlich nicht im Grafikbereich. Schauen wir uns top nochmal genauer an. Die Browser sind noch in SIGSTOP und entsprechend verschwunden. Hinter XOrg macht sich nun dbus breit. Dbus? Kurze Lastspitzen OK, aber Dauerlast? Ein Blick mit dbus-monitor bringt eine Wall-of-log zum Vorschein:

…und das in Endlosschleife. Uhm, ja. mailto? Das sind üblicherweise Links in Webseiten oder Dokumenten um E-Mails zu versenden. Stimmt, ich hatte vor einigen Stunden auf einer Webseite einen Mail-Link angeklickt. Ohne Reaktion.

Offenbar hat sich die DE an eben diesem Maillink festgefressen. „Der angegebene Ort wird nicht unterstützt“. Kein Wunder, denn in den „Standardprogrammen“ ist für E-Mails nichts hinterlegt. Anstatt das Ganze aber einfach als Fehlschlag einzuordnen und abzubrechen wird die Aktion in Endlossschleife ständig wiederholt. Da auch Xorg an Dbus hängt (und offenbar nicht sonderlich effizient auf dessen Events reagiert) geht auch dieser in die Knie. Da ich auf die Schnelle keine Möglichkeit fand das dbus-event rauszuwerfen musste ein Dummy-Mailprogramm hinhalten. Event geht rein, Returncode kommt, Dbus gibt Ruhe. Warum nicht gleich so?