Bernds Blog

Heute stieß ich auf eine Merkwürdigkeit: Die Partition /var/log war zu über der Hälfte voll, mit du -hsc /var/log/* waren aber nur ein paar MB belegt. Die Ursache war uns klar, das Problem hatten wir schonmal: Ein Programm hat eine Datei noch geöffnet, die aber bereits gelöscht ist. So wird Speicherplatz belegt, man findet aber keine Datei dazu.

Als Lösung war mit bisher nur bekannt, das Programm mittels lsof /var/log/| grep deleted zu identifizieren und neu zu starten, damit es die Datei-Handles aufgibt und die gelöschten Dateien wirklich gelöscht sind. In diesem Fall war es aber der MySQL-Server und wir hatten grade einen leistungsintensiven Import am Laufen, so dass mir das Risiko zu hoch war, den MySQL-Server neu zu starten bzw. ein SIGHUP zu senden. Gleichzeitig war aber die Gefahr groß, dass die Platte vollläuft, bevor der Import abgeschlossen ist.

Als praktisch hat sich dann das Werkzeug truncate erwiesen. Das kürzt eine offene Datei auf eine feste Größe und schiebt den Dateizeiger ebenfalls auf diese Position. Damit kann man eine Datei leeren ohne dass der andere Prozess sein File-Handle schließen muss: truncate -s0 /proc/19580/fd/11

Nach der ernüchternden Evaluation der Desktops vor etwa eineinhalb Jahren war es nun an der Zeit, irgendwas aktuelles zu installieren, da ansonsten der Support für meine bisher betriebenen Ubuntu-11.04-Installationen ausgelaufen wäre.

Auch nach einiger Überlegung, ich kann mich nicht mit Unity oder Gnome-3 anfreunden, ich schaff es einfach nicht (Das Dock bei den beiden Systemen brauchte auf meinen Rechnern eine spürbare Zeit zum aufklappen. Da das die einzige Vorgehensweise ist um mit der Maus ein Programm zu wechseln, ist das ein no-go). Bei KDE fielen mir nach wenigen Minuten wieder Inkonsistenzen und Instabilitäten auf, so dass das auch gleich wieder von meinem Rechner verschwand.

Ich halte eigentlich nicht viel von Forks alter Software, die schlafen nämlich meistens ein bevor der Unterbau fit für neuere Entwicklungen ist, aber in diesem Fall bin ich wirklich bei MATE hängen geblieben. Genauer gesagt habe ich ein Lubuntu-System installiert (damit der Unterbau recht schlank ist) und darauf dann MATE-Pakete eingespielt. Das ganze auf dem neuen Rechner, den ich nach dem Bauvorschlag der c't gebaut habe, bootet in 2 Sekunden (nach dem BIOS) zum Desktop. Der Rechner ist schneller gebootet als der Monitor aus dem Standby erwacht.

Der Desktop ist das woran ich mich die letzten 1,5 Jahre gewöhnt habe: Effektiv Gnome-2. Leider mussten die alles umbenennen, was es natürlich schwer macht, da die vorhandenen Desktop-Icons ins Leere laufen und das was man schnell mal per Alt+F2 startet, nun plötzlich anders heißt. Aber man kann damit leben.

Als Anwendungsprogramme möchte ich mich nicht mehr auf einen Desktop festlegen und verwende daher z.B. Thunderbird und Firefox bzw. momentan Chromium. Letzteren soll ich mir nach einigen Ratschlägen unbedingt anschauen. Bisher überzeugt er mich aber nicht wirklich, ich denke in Kürze werde ich wieder Firefox benutzen.

Die Tage kam bei schokokeks.org die Notwendigkeit nach einem zusätzlichen Server auf, der nichts anderes machen sollte als Backups von einigen bestehenden Maschinen entgegen zu nehmen. Der Server soll als virtuelles Gastsystem betrieben werden, da die erwartete Last minimal ausfällt. Da wir stets versuchen, IPv4-Adressen nicht zu vergeuden, wollte ich diesen Server als IPv6-only-System in Betrieb stellen.

Das hat grundsätzlich gut geklappt, es gab aber einige Stellen die (für mich unerwarteter Weise) Probleme bereitet haben.

1. OpenVPN kann nicht über IPv6. Mit der Version 2.3 soll das angeblich anders werden, die gibt es aber bisher noch nicht. Meine Lösung war, dass ich eine private IPv4-Adresse eingerichtet habe, die der physikalische Server auf einen anderen Server routet, der ebenfalls eine passende private IPv4-Adresse hat. Dadurch kann OpenVPN über diese IPv4-Verbindung kommunizieren.


2. Die normalen Gentoo-Mirror-Dienste beachten kein IPv6 und liefern im Round-Robin einfach irgendwas zurück, was ich dann nicht aufrufen kann. :( Die Lösung war, gezielt SYNC-Server und Distfiles-Mirror einzutragen die IPv6-Verbindung liefern. Die Listen gibt es hier (sync-Mirrors) und hier (Distfiles-Server). Jeweils die mit Sternchen sind IPv6-fähig.


3. Wir betreiben normalerweise lokale DNS-Resolver auf jedem Server. Für diesen speziellen Zweck ist das okay, aber man kann halt nur Namen auflösen, die auch über IPv6-fähige DNS-Server angeboten werden. IPv6-Paradebeispiel Heise online geht z.B. nicht, da deren DNS-Server keine IPv6-Adressen haben. Um etwas mehr Möglichkeiten zu haben, kann der Google-Public-DNS benutzt werden: 2001:4860:4860::8888.

Letztlich ist OpenVPN der einzige Grund, dass auf der Maschine überhaupt eine IPv4-Adresse eingerichtet ist. Und das soll sich ja angeblich mit dem nächsten Release, für das bereits ein RC angeboten wird, ändern. Ich bin jedenfalls gespannt.

Unsere normalen Serverdienste betreiben wir schon seit Jahren im Dualstack. Vor einigen Wochen wurde der Linux-Default-Resolver auch so geändert, dass er IPv6 bevorzugt, da hatten wir ein Localhost-Problem (Zugriffe auf localhost kamen dann von ::1 und nicht mehr von 127.0.0.1, da mussten einige Konfigurationen angepasst werden). Aber ansonsten bereitet uns der Dualstack-Betrieb keine Schwierigkeiten.

Letzte Woche habe ich mir ein neues Spielzeug angeschafft: Ein Epson TM-T20 Thermo-Bondrucker. Ein echter Kassenzetteldrucker.

Ich möchte mein Bag-in-Box-Kassenprogramm Bib2011 darauf portieren, so dass Kunden-Belege wesentlich schneller und günstiger gedruckt werden können. Das funktioniert nun auch schon. Bis das so weit war, war allerdings wirklich erst einmal mein Spieltrieb gefordert. Das Gerät wird nicht als normaler (grafischer) Drucker angesteuert sondern als zeichenorientierter Drucker mit Formatierungs-Steuerzeichen. Man sagt dem Drucker als zunächst welche Größe die kommenden Zeichen haben sollen und dann schickt man einfach ASCII-Zeichen hin.

Die Druckersprache ESC/P bzw. ESC/POS ist für diesen Zweck gängig und wird von fast allen POS-Druckern benutzt. Irritierend ist dabei, dass manche Befehle, Dokumentationen und auch laufender Code im Netz frei verfügbar ist, teilweise auch vom Hersteller selbst. Andererseits beginnt die Bedienungsanleitung des Geräts mit der Aussage, dass man das ESC-Reference-Manual nur gegen Unterzeichnung eines NDA erhalten kann:

To use ESC/POS commands, you need to agree to a nondisclosure contract first and obtain the ESC/POS Application Programming Guide.

Demzufolge enthält die Anleitung auch nur eine Liste der unterstützten ESC-Befehle, nicht aber deren Syntax.

Nach einigem hin und her wurde ich allerdings fündig: Die Anleitung des größeren Schwestermodells TM-T85 enthält eine umfangreiche ESC/P-Referenz. Auch nicht komplett, ich habe schon andere Befehle gefunden die da nicht drin sind und die der Drucker auch versteht, aber das meiste ist drin.

Heute bin ich über alten Sourcecode gestolpert, den ich teilweise vor langer Zeit erstellt hatte und auch diversen Leuten versprochen hatte, das "irgendwann" als freie Software zu releasen.

Im Zuge eines Warum eigentlich nicht jetzt?-Anfalls habe ich jetzt mal zwei git-Repositories erstellt und den Code dort eingespielt und gebe diese hiermit frei.

Für beide Projekte gilt: Das war Software die ich selbst gebraucht habe und sie ist in genau dem Zustand in dem ich sie bei mir momentan benutze. So ist meist die Konfiguration im Code, auch wenn ich hoffe, dass keine Zugangsdaten mehr irgendwo enthalten sind. Die Software ist vermutlich in dem Zustand in dem sie hier angeboten wird für niemanden nützlich.

Folgende Projekte gibt es hier:

Bib2011 steht für "Bag-in-Box-Kassenprogramm". Ich verwende für unsere Mosterei schon länger ein eigenes Programm zur Kassenverwaltung. 2011 habe ich dies von Grund auf neu gemacht, gedacht für die Nutzung auf einem Touchscreen.

Der Code basiert auf Python und Qt4. Die UI-Designer-Dateien sind auch dabei.

python-solarmax ist eine Bibliothek um Ertragsdaten aus Solarmax-Wechselrichtern auszulesen. Das Paket besteht aus einer Python-Bibliothek zur Kommunikation mit dem Gerät und einem kleinen Programm das diese Bibliothek nutzt um die Ertragsdaten regelmäßig in einem SQLite-Datenbank zu speichern.

Das (proprietäre) Kommunikations-Protokoll habe ich zunächst reverse-engineered, indem ich die Hersteller-Software in einer virtuellen Maschine benutzt habe und dann im Netzwerk die Daten ausgewertet habe. Nachdem ich das praktisch fertig hatte, bekam ich vom Hersteller doch noch eine Dokumentation des Protokolls, allerdings mit unbrauchbaren Lizenzhinweisen (keine Veröffentlichung des Protokolls und keine Herstellung von Software die veröffentlicht wird). Ich habe also die Bibliothek ohne die Dokumentation fertig geschrieben.

Wenn jemand die Software interessant findet und für irgendwas eigenes brauchen kann, würde ich mich sehr über eine Nachricht freuen.

Man kennt mich als KDE-Nutzer. Schon vor Jahren hatte ich mehrmals einen GNOME-Desktop ausprobiert, aber irgendwie war ich stets nach wenigen Minuten auf Dinge gestoßen die man nicht (auf normalem Wege) einstellen konnte und die einfach "anders" waren als ich es gerne gehabt hätte. Mit freier Software verbinde ich grundsätzlich auch dass eine Software sich an die Wünsche des Nutzers anpassen kann und das war bei KDE immer wesentlich einfacher zu haben als bei GNOME.

Ich habe also stets KDE gelobt und fand GNOME beschränkt, zu "appelig" und irgendwie nicht nutzbar. Und die für GNOME entwickelten Standardprogramme waren auch schon lange ein großes Problem.

Sogar das KDE-4-Desaster habe ich zähneknirschend über mich ergehen lassen. Nachdem aber KDE nun auch in den jetzt aktuellen Versionen vor (für den einfachen Anwender) nervtötenden Fehlern nur so strotzt, habe ich mich entschieden, dass ich für meine Kunden und meine Familie zukünftig GNOME verwenden möchte und habe dieses völlig vorurteilsfrei auf meinem Desktop installiert um Erfahrungen damit zu gewinnen. Das ist jetzt ungefähr 4 Wochen her und die ersten Nutzer sind schon auf erfolgreich GNOME umgestellt. Für einfache Anwender hat GNOME den großen Vorteil, dass es nicht mit offensichtlichen Fehlern nervt.

Wie sieht es aber mit meinen eigenen Erfahrungen aus? Nach 4 Wochen Dauernutzung kann ich guten Gewissens sagen: Der Test war ohne Vorurteile. Und ich habe gemerkt, dass beide genannten Alternativen unerwartet gravierende Schwächen haben.

Ich möchte mich hier vor allem auf die Schwächen der Programme stürzen, die ich im Rahmen des Tests ausprobiert habe.

Ich musste neulich einen Rechner vollständig neu installieren und haben daher vorab neben einer Sicherung der Dateien ein HDD-Image erstellt um für den Fall der Fälle alles nochmal verfügbar zu haben.

Danach, wie es eben so ist, stellte ich Inkonsistenzen der kopierten Dateien fest und wollte auf dem gemachten Image nochmal nachschauen und die Dateien von dort nochmal kopieren. Leider war ich nicht schlau genug, einzelne Partitions-Images der stark partitionierten Festplatte zu machen sondern habe nur ein komplett-Image, das sich so natürlich nicht als Loopback mounten lässt.

Doch nach kurzer Recherche fand ich heraus, dass das gar kein Problem ist. Man muss nur mittels fdisk -l sda.img die Start-Sektor-Nummer der gewünschten Partition bestimmen, diese mit 512 multiplizieren und hat dann die Startposition der Partition in Bytes.

Mit dem Befehl
mount -o loop,offset=12345678 sda.img /mnt/image
lässt sich dann das Dateisystem dieser Partition direkt mounten.

Vermutlich ist das mal wieder eine meiner Wissenslücken, die man eigentlich nach so langer Erfahrung nicht mehr haben sollte, aber das hatte ich bis gerade eben wirklich nicht gewusst (weil nie gebraucht). :)

Bedingt durch das neueste Ubuntu-Release vor gut einer Woche musste ich in den letzten Tagen ein paar Rechner aktualisieren. Dazu empfiehlt sich natürlich vorher ein möglichst gutes Backup.

In einem Fall musste ich einen Rechner komplett sichern, den ich nachher 1:1 wieder herstellen möchte (auf ähnlicher aber anderer Hardware). Damit das Restore nachher möglichst schnell und einfach funktioniert, entschied ich mich dazu, dass ich /dev/sda als Komplettimage sichern möchte. Leider habe ich keinen Rechner, auf dem ausreichend Platz für das komplette Image ist. Die Festplatte ist aber nur zu einem kleinen Teil wirklich belegt. Die Erwartung war also, wenn ich das Image sofort komprimiert abspeichere, dann müsste es auf jeden Fall passen, denn leerer Platz sollte gut komprimierbar sein.

Der Transfer sollte über eine netcat-Pipe laufen (ssh-tunnel wäre auch möglich, hat aber mehr overhead).

Das Problem an der Sache war, dass ich keine Informationen über den laufenden Fortschritt der Aktion sehen konnte. Auf dem Quellrechner kann man nicht sehen, wie viel von dem Device schon ausgelesen ist und auf dem Zielhost habe ich keine Ahnung, wie groß die endgültige komprimierte Datei werden würde.

Ein kurzes Überlegen brachte mich zu der Idee, dass es eigentlich eine triviale Aufgabe sei, ein Programm zu erstellen, das einfach Daten auf stdin liest, nach stdout schreibt und dabei mitzählt und die Zahl regelmäßig ausgibt.

Bevor ich selbst Hand anlegte, suchte ich kurz im Netz und fand auch recht schnell eine Lösung: pv, steht für »pipe viewer« und macht exakt genau dieses. Das Tool kann entweder einfach mitzählen oder man gibt ihm per Parameter die erwartete Gesamtgröße der Daten, dann erhält man eine wget-ähnliche Ausgabe mit Restzeit und Prozentbalken.

Das Tool gefällt mir so gut, dass ich es sogleich für diverse andere Aktionen ebenfalls einsetze.
Dies kann dann etwa so aussehen (bei einer tar-Pipe über netcat):

$ nc -l 10.0.0.2 1111 |gunzip| pv -s 40053354750| tar x

14,6GB 0:53:34 [ 5,2MB/s] [=========>                    ] 39% ETA 1:22:55

In diesem Beispiel habe ich auch gleich das gunzip vor pv gesetzt, damit ich die wirklichen Daten zähle und nicht die komprimierten. Auf dem Quellhost arbeitet hier ein einfacheres tar xz . | nc ....

Ach ja, Fußnote: Für das eingangs genannte Szenario sollte man das gute alte gzip benutzen. Da ich möglichst gut komprimierte Daten wollte (schließlich hatte ich wenig Platz), entschied ich mich für xz als Kompressionsprogramm. Das ist aber so dermaßen langsam, dass es auch auf meinem DualCore-Rechner nur etwa 1 MB pro Sekunde komprimierten konnte und damit den ganzen Vorgang auf viele Stunden ausgedehnt hat. Leeren Platz komprimieren hätte aber auch gzip hin bekommen.

Seit einer Weile hatten wir vor, anstelle von Bildern fürs Fotoalbum auch mal ein Fotobuch drucken zu lassen. Das scheiterte bisher immer daran, dass die üblichen Verdächtigen eine reine Windows-Software anbieten, die noch nicht mal unter Wine zum Laufen zu bewegen ist.

Vor etwa 2 Wochen fand ich allerdings einen Anbieter, der explizit mit der Unterstützung von Linux wirbt. Das hat mich gleich fasziniert und ich beschloss, dieses Angebot wahrzunehmen. Am Montag kam dann das fertige Buch an.

Da ich sehr zufrieden war, nenne ich gerne Namen: Es handelt sich um die Firma fotobuch-profi.de, die das Java-Programm Photux benutzt.

Die Java-Software läuft auf vielen Plattformen, ich konnte und wollte nur Linux/x86 und Linux/amd64 testen. :) Für den einfachen Anwender gibt es zwei Stolpersteine, die der Hersteller noch ausräumen sollte.

1. Die Speicher-Beschränkung von Java. Normalerweise hat unter Linux jedes Java-Programm nur 64 MB RAM zur Verfügung. Das mag im letzten Jahrtausend bei der Erfindung von Java eine sinnige Idee gewesen sein, heute ich das zumindest für eine Bildbearbeitung wesentlich zu knapp. Das Programm selbst kann das Limit logischerweise nicht verändern, man muss dies in der Start-Kommandozeile machen. Der Händler nennt zwar die passende Kommandozeile, liefert für Linux aber eine blanke JAR-Datei aus. Ein einfaches Script zum Starten der Anwendung mit den richtigen Parametern könnte hier echt weiter helfen.

2. Das Programm erlaubt die Verwendung diverser Bildformate. Bindet man jedoch ein PNG mit indizierten Farben ein (PNG kann beides, indizierte Farben und RGB), so schlägt die Übertragung zur Druckerei fehl ohne eine eindeutige Fehlermeldung. Es hat mich einige Stunden experimentieren gekostet um diesen Umstand herauszufinden. Wandelt man das PNG in RGB um, klappt es.

Abgesehen davon lief alles reibungslos, die Designer-Software ist akzeptabel in der Bedienung (was nicht heißt, dass ich nicht Verbesserungsvorschläge hätte) und das Druck-Ergebnis exzellent (im Gegensatz zu meinem Display sind die Bilder etwas dunkler gedruckt worden. Das macht aber mein Farblaser hier auch, vermutlich ist mein LCD einfach etwas zu hell eingestellt).

Der Preis ist zwar nicht grade Dumping, aber die Qualität des Buches stimmt. Die Produktionszeit von etwa einer Woche (zzgl. Versand) ist auf der Internetseite gut dokumentiert und stört mich nicht.

Mein Garmin eTrex Legend kann im Lieferzustand nur Kartendaten bis maximal 2 GB Größe nutzen. Da man aus OSM-Daten sehr umfangreiche Karten erzeugen kann, tangieren aktuelle Europa-Karten diese Grenze bereits. Es ist also zu erwarten, dass mit weiterer Erfassung von Daten die Dateien größer werden.

Im neuesten Firmware-Update ist das Limit aber aufgehoben.

Dieses Update wollte ich also auf jeden Fall einspielen. Da ich bekanntermaßen kein Windows in Betrieb habe, gestaltet sich das aber schwierig. Vermutlich wäre das Update-Programm auch über Wine lauffähig gewesen, das habe ich nicht probiert. Da ich aus anderen Gründen neulich schon einmal ein Windows XP (Lizenz in Form der Microsoft-Steuer war ja beim Computerkauf eh dabei) in einem QEmu-Image installiert habe, benutzte ich das für das Firmware-Update.

Dazu kann man (wenn man den Parameter -monitor stdio angibt) auf der QEmu-Konsole ein USB-Gerät an das Gast-System durch reichen.
In meinem Fall sorgt der Befehl usb_add host:091e:0003 dafür, dass der Garmin eTrex durchgeschleift wurde. Das Update-Programm auf dem Gast-System erkannte dann auch das Gerät und startete das Update.

Kritisch: Während des Update-Prozesses trennt das Gerät ab und zu die Verbindung. Das erkennt man an folgenden Meldungen in der QEmu-Konsole:
husb: device 1.11 disconnected

Dann sollte man umgehend den obigen Befehl wiederholen, damit das Update fortgeführt werden kann.

Ich möchte niemandem empfehlen, das auf diese Art zu machen, aber wenn man die USB-Durchreichung schnell genug wieder herstellt, klappt das ganz gut.