Linux

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.

Seit langem sind mir Besucher-Tracker ein Dorn im Auge. Daher sind Domains wie www.etracker.de und google-analytics.com seit einiger Zeit bei mir im lokalen DNS-Server gesperrt, so dass diese aus meinem lokalen Netz nicht mehr aufgerufen werden können.

Leider wird grade etracker oftmals so penetrant eingesetzt, dann man einfache Unterseiten oder Downloads nicht mehr aufrufen kann, wenn deren Seite nicht mehr erreichbar ist.

Daher habe ich mir jetzt einen lokalen "Proxy" für dieses Problem erstellt. Das Setup ist simpel:

• Ein lokaler DNS-Resolver wird so konfiguriert, dass er für den betreffenden Host die Adresse eines eigenen Webservers zurückliefert.


• Der Webserver erhält einen neuen VHost, der für die Hostnames der betreffenden Websites verantwortlich ist.


• Ein CGI-Script liest die URL aus dem Aufruf-Parameter und sendet eine Weiterleitung an die betreffende Adresse ohne dass irgendwelche Statistiken zentral gespeichert werden.

Nachfolgend meine dafür verwendeten Konfigurationen und Scripte.

Seit geraumer Zeit haben sich bei uns neben einer beachtlichen DVD-Sammlung auch einige Filme angesammelt, die z.B. vom Fernsehen aufgezeichnet wurden.

Ich bin dagegen, für solche Filme krampfhaft ein Original-Cover zu suchen bzw. die DVD kaum vom Original unterscheibar zu machen. Im Gegenteil, ich möchte die Chance nutzen, die Filme dann einheitlich, sachlich und erkennbar zu positioniren.

In unserer lokalen Installation von VideoDB haben wir alle Filme erfasst. Sowohl die Kauf-DVDs als auch die selbst aufgezeichneten.

Um aus den dort hinterlegten Daten automatisch Cover zu erzeugen, habe ich mir gestern ein kleines Script zusammengebastelt.
Teile des Sourcecodes stammen aus einem anderen Projekt, daher auch die unsinnige Aufteilung auf zwei Dateien. Das Script ist aus der Not entstanden und so sieht es auch aus. Aber es dürfte leicht sein, daraus was eigenes zu erstellen.

Python-Code ist zugänglich unter https://svn.bwurst.org/software/dvdcover/, Lizenz: Public Domain.

Als Dateneingabe fungiert ein XML-Export (von phpMyAdmin) der "videodata"-Tabelle aus der VideoDB-Datenbank.
Ausgabe sind einzelne PDF-Dateien für die einzelnen Cover.

Heute habe ich einen weiteren Linux-PC an eine Kundin ausgeliefert. Hier wurde ich letzte Woche gerufen, da der PC beim hochfahren immer Scandisk angeworfen hatte und das sich in einer Endlosschleife festgefressen hatte.

Ergebnis einer schnellen Diagnose mit der System-Rescue-CD: Auch hier war die Festplatte schlicht und einfach kaputt. Die Geräuschkulisse war zwar nicht besonders beängstigend, aber deutet auch in diese Richtung.

Da nach Austausch der Festplatte sowieso eine Neuinstallation ins Haus stand, habe ich auch hier die obligatorische Frage gestellt: "Für was brauchst du denn den Computer alles?" Da sich auch da schnell abzeichnete, dass die offensichtlichen Vorteile eines Linux-Systems (Kinder machen nicht versehentlich das System kaputt, keine ernsthaften Viren-Probleme) durch kein haltbares Argument zu entkräften waren, konnte ich auch hier deutlich machen, dass die Kundin mit einem Linux-System besser beraten ist.

Vor einigen Tagen wurde ich zu einem Kunden gerufen, der Probleme mit seinem "Server" hatte. In anführungszeichen deshalb, weil es sich um einen Arbeitsplatz-Rechner handelte, der in der Ecke stand und ein paar Freigaben im Netz publiziert hat.

Die Probleme des Servers waren schnell erkennbar, die ersten Sektoren der Festplatte waren komplett hinüber. Da sowieso eine neue Festplatte und damit eine Neuinstallation nötig war, habe ich gleich vorgeschlagen, das bisher eingesetzte Windows durch einen einfachen Linux-Server zu ersetzen. Windows-Dateifreigaben sind damit auch kein Problem und die Backups auf den im "Server" verbauten DVD-Brenner zu sichern dürfte mit K3B keine Probleme bereiten.

Ich entschied mich für Ubuntu 6.06 LTS. Das ist zwar schon etwas älter, wird aber noch eine Weile supported. Ich denke mal, in einigen Tagen kann ich dann gleich auf die neue 8.04 LTS aktualisieren. ich warte noch, weil ich denke dass es bestimmt noch Migrations-Probleme geben kann.

Dort arbeitet jetzt also seit etwa einer Woche ein Ubuntu-Server mit Samba und KDE/K3B zum Brennen von DVDs. Die Festplatte wurde durch einen Software-RAID-1-Verbund ersetzt, damit ein Platten-Ausfall erstens schneller bemerkt werden kann und zweitens vielleicht reparabel bleibt.

Der Kunde hat jetzt noch ein wenig Spaß, die knapp 40.000 Dateien, die von der Datenrettungs-Software des PC-Fachhändlers knallhart durchnummeriert zurück kamen inhaltlich zu bewerten und zu sortieren.

Mit dem Linux-PC ist der Kunde allerdings zufrieden, auch wenn es in seinem Tagesablauf keinen nennenswerten Unterschied zu vorher gibt.

Hatte neulich bei einem Desktop-PC versehentlich die Tastatur in den Maus-PS/2-Port eingesteckt. Dank USB-Maus hab ich das Versehen nicht bemerkt.

Linux bootete auch ganz normal und es hat alles funktioniert.

Dann ist mir aufgefallen, dass das BIOS vor dem boot recht lange wartet und dann sagt "No keyboard found".

Linux hat die Tastatur aber trotzdem benutzen können. Als ob nichts wäre. Das find ich mal cool. :)

Hier mal kurz eine Erfahrung von heute, auf dass dies vielleicht andere finden, die sich in der selben Situation wiederfinden.

Gestern Abend teilten mir meine Eltern mit, dass ihr Rechner keinen Login mehr macht. Egal welcher Benutzer sich anmeldet, es bleibt immer sofort nach Verschwinden der Login-Maske alles stehen.

Nach einigem Debugging habe ich erstmal aufgegeben (es war spät) und heute früh weiter gemacht. Im Netz habe ich auch nicht wirklich was gefunden was passend war.

Der Lösung näher kam ich als ich ein simples xterm (mittels xinit bzw. .xinitrc) gestartet habe und dort dann "strace kwin" aufgerufen habe. Damit zeigte sich, dass der Prozess beim Locking auf die ~/.qt/.qtrc.lock stehen blieb. Da das NFS-Homedir schon manchmal beim Locking Probleme hatte, habe ich also getippt, es kann daran liegen. Laut rpcinfo -p war aber der nfslockd aktiv.

Über einiges trial und error und den entscheidenden Fund im Netz, dass das Locking Probleme macht, wenn der Server die IP-Adresse des Clients nicht auflösen kann, bin ich dann darauf gestoßen, dass der bind auf dem Server aus mir unerklärlichen Gründen sich nicht für die lokale reverse-Zone zuständig gefühlt hat. Ein einfaches Restart des bind hat genau das behoben, ab dann waren auch lokale reverse-lookups wieder möglich.

Der NFS-Server hat die Situation aber nicht verkraftet, einen restart-Versuch hat er immer mit einem Segmentation fault verweigert. Als ich dann aber den Server-Rechner neu gestartet habe, hat wieder alles wunderbar funktioniert. ohne das ich irgend etwas ändern musste.