Archiv der Kategorie: Software

Alles was mit Software zu tun hat

Windows: Wo ist Java?

Ich bin von Linux ja irgendwie verwöhnt: Alle Binärdateien sind üblicherweise unter /usr/bin und lassen sich direkt über den Namen des Programms aufrufen. Unter Windows gibt es mit $PATH zwar eine ähnliche Funktion, jedoch ist dort meist nur der Systempfad eingetragen. Da es für fast jedes Programm ein eigenes Verzeichnis gibt hat man so keine direkte Möglichkeit ein Programm zu starten ohne an den Systemvariabeln herumzueditieren.

In vielen Fällen nicht wirklich ein Problem – einmal gefunden kann man den Pfad in seinen Scripten hinterlegen und so die Software ansprechen. Leider ist das bei Programmen wie Java nicht so einfach: Diese legen ein Verzeichnis mit der Versionsnummer an, z.B. C:\Program Files\Java\jre_8.0.121\bin\java.exe. Ergebnis: Nach jedem Update versteckt sich die gesuchte EXE an einer anderen Stelle.

Hier ein Quick&Dirty CMD, welches die Java-Binary aufspüren sollte. Nicht Ideal, da z.B. nur das Systemlaufwerk unterstützt wird und diverses Errorhandling fehlt, aber immerhin zuverlässiger als hardcoded…

 

Thunderbird: Couldn’t load XPCOM

Diese Meldung weist erst mal darauf hin, dass die Installation beschädigt ist. Dies kommt häufig vor, wenn der Updater unterbrochen wird oder ein übereifriger Virenscanner genutzt wird. Eine Reparaturinstallation ist meist keine schlechte Idee – hierzu einfach die aktuelle Installation von der Webseite ohne vorherige Deinstallation ausführen. E-Mails und Einstellungen bleiben hierbei zu großen Teilen erhalten. Zeigt dies keine Wirkung kann auch ein Blick auf die Dateirechte nicht schaden – in meinem Fall war für den Ordner bzw. dessen Dateien das Execute-Recht verweigert.

Linux/Sane: Segfault mit Panasonic/Matsushita KVS-50xx-Scanner

Business as usual: Pünktlich zum Jahresanfang wird man von sämtlichen Vertragspartnern mit totem Baum zugeworfen. Glücklicherweise habe ich passende Scanner, die das Material in etwas besser verwaltbare Formen überführen können. Zuletzt verwendete ich dazu einen Panasonic/Matsushita KVS-5026, welchen ich aus dem Schrott retten konnte. Zwar habe ich noch einige schnellere Modelle, dieser hatte jedoch bisher die wenigsten Probleme mit Double-Feeding und ist durch die Bauform bei mir einfacher zu nutzen.

Leider war der Start dieses Jahr nicht ganz so erfolgreich – der Scanner wird korrekt erkannt, versuchte ich jedoch einen Scan zu starten gab es den allseits beliebten „Segmentation fault“. Boo.

Der Trick des letzten Problems half dieses mal leider nicht – auch die aktuelle GIT-Version zeigen den selben Fehler. Da es für das passende Backend kvs20xx keinen Maintainer gibt ist wohl auch keine Besserung zu erwarten.

OK, ich bin kein C-Programmierer, habe keine Ahnung von Debuggern unter X86 und produziere auch sonst eher nicht qualitätsorientieren Code – was kann schon schief gehen.

Ein paar Debug-Textausgaben später konnte ich den Fehler auf die Funktion sane_open, genauer die erste „echte“ Codezeile dort „for (i = 0; devlist[i]; i++)“ eingrenzen. Offenbar wurde früher durch sane automatisch ein Scan iniziiert und die devlist daher gefüllt. In der aktuellen Version scheint es beim Aufruf leer zu sein und mit NULL hantieren mag C wohl nicht. Als workaround konnte ich ein paar Zeilen des Fujitsu-Treibers ruberkopieren, welche die Inizialisierung ggf. nachholen. Auch diese musste etwas angepasst werden um mit dem direkten Aufruf umgehen zu können. Immerhin: Der Scanner läuft und ich kann weitermachen. Fein.

 

Upstream: #315625

Debian Jessie: linux-base Fehler bei Installation neuer Backport-Kernel

Debian mag stabil sein, der aktuell bei Jessie mitgelieferte 3.16er Kernel wird von einigen Dingen jedoch nicht mehr unterstützt, die Installation dieser Softwarepakete ist also nicht mehr möglich. Glücklicherweise gibt es die so genannten Backports, welche neuere Versionen bereitstellen. Nicht ganz so gut getestet, aber immerhin eine Möglichkeit.

Die Einrichtung geht recht schnell – man muss lediglich folgende Zeile in /etc/apt/sources.list hinzufügen:

Sucht man nun nach linux-image, also dem Kernel, findet man auch einige neue Versionen. In meinem Fall ist die 4.9.0 aktuell:

Leider gelingt die Installation nicht ohne Klimmzüge, denn der erste Versuch wird mit einer Fehlermeldung quittiert:

Auf den ersten Blick scheint es jedoch keine neue Verison des Paketes zu geben:

Ursache ist die Priorisierung: Sowohl im „offiziellen“ Jessie-Repository als auch in den Backports steckt ein Paket mit dem Namen linux-base. Zwar ist jenes in den Backports aktueller, jedoch werden die Pakete des Stable-Repos bevorzugt. Abhilfe schafft es das Paket explizit aus dem Backports-Repo zu beziehen.

Im Anschluss ist auch die Installation des Kernels fehlerfrei möglich. Mit dieser Methode kann man auch das Kernel-Metapaket installieren um zukünftige Updates automatisch zu erhalten:

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.

vSphere vCenter Server Appliance (vCSA) 6.0 -> 6.5 VIX Upgrade Fehler

Beim Upgrade einer vCSA 6.0 zu 6.5 ergeben sich die tollsten Fehlermeldungen – und keine ist dokumentiert. Immerhin eine konnte ich Dank des VMWare-Forums schnell herausfinden:

Selbstverständlich waren die Zugangsdaten des Quellserver korrekt und funktionierten in WebUI bzw. SSH fehlerfrei. Ich übersetze mal in eine für Administratoren verständliche Sprache:

Nachdem ein neues Kennwort vergeben wurde läuft das Update an dieser Stelle weiter.

Nutzung von GIT auf Debian/Ubuntu nicht möglich: GnuTLS

(Anm: Angeblich soll der Bug inzwischen behoben sein)

Debian und dessen Devirate geben sich zur Zeit wieder eine Menge Mühe meine Vorurteile zu erfüllen. Dieses mal hat es GIT erwischt: Beim Klonen eines Repositories kommt es zu einem Verbindungsfehler durch GnuTLS.

Offenbar hat die bei Debian mitgelieferte Version von GnuTLS Probleme mit einigen Cipher-Suites und Proxyservern. Ich folge mal den Tipps von Nyambaa@AskUbuntu bzw. xmendez und habe GIT statt mit GnuTLS gegen OpenSSL gebaut:

Die Version muss natürlich der jeweils aktuellen angepasst werden – lässt sich ggf. per ls nach apt-get source herausfinden.

In der Datei debian/control muss nun überall der Text libcurl4-gnutls-dev gegen libcurl4-openssl-dev ersetzt werden. Im Anschluss wird das Paket gebaut und installiert. Ggf meckert buildpackage noch über fehlende libraries, welche man schnell per apt-get nachziehen kann.

Nun sollte das installierte git auf OpenSSL basieren und keine Verbindungsprobleme mehr zeigen.

VMWare vMotion auf VMA per CLI auslösen

Kleines Script zwischendurch: Über dieses Perl-Konstrukt kann man auf einem vSphere Management Assistant eine vMotion auf der Konsole auslösen. So lassen sich recht einfach eventgesteuerte vMotion-Aktionen umsetzen. Ich nutze es z.B. um zeitgesteuert VMs an Standorte mit höherer erwarteter Hitrate zu verlegen oder bei Störungen kritische VMs automatisiert auf „sicherere“ Hosts zu migrieren. Das Original stammt von William Lam, ich habe einige Punkte etwas umgebaut um Storage-vMotion auszuklammern. Üblicher Disclaimer: Proof of concept, keine Garantie, nicht-Programmierer-versucht-sich-an Perl, Works for me.

Aufruf:

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.

FRITZ!Box per Konsole auslesen (PHP/TR64)

Statistiken sind toll. Wäre fein, wenn man auch der FRITZ!Box einiges entlocken könnte. Das Zauberwort lautet TR64 und ist über HTTP/SOAP im LAN erreichbar. Hierzu müssen in den Netzwerkeinstellungen die Anwendungszugriffe und Statusinformationen aktiv sein.

Allgemeine Infos wie die aktuell verwendete Bandbreite lassen sich von jedem Abrufen, andere Bereiche konnte ich bisher nur über /control abrufen – hier werden die Zugangsdaten eines FB-Nutzers benötigt.

Über das Protokoll lassen sich neben IP, Verbindungsstatus und Bandbreiten auch erweiterte Infos wie Dämpfungen & Co aufzeichnen. Technisch kann man sogar Aktionen wie einen Reconnect oder komplette Konfigurationsänderungen durchführen, das würde hier jedoch den Rahmen sprengen. Einige Infos gibt es in der Wiki von WeHaveMoreFun oder das ausgiebigere Perl-Modul von FHem.

Hier mal mein Notizzettel, welcher eine Abfrage per PHP erlaubt: