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

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.

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.

Wir nutzen bei uns auf dem Hof eine Gigaset 3060isdn-Basisstation mit einigen Mobilteilen.

Seit einiger Zeit hatten wir das Problem, dass ein spezifisches Mobilteil nicht mehr extern angerufen werden konnte. Intern war es erreichbar und wenn man auf dessen Externnummer ein anderes Mobilteil programmiert hat, war das auch anrufbar. Also eine eher unlogische Situation.

Heute konnte ich das Problem endlich mal lösen.

Und zwar erlaubt diese Basis 8 Mobilteile (plus 2 Analoganschlüsse). Seit einiger Zeit haben wir das 7. Mobilteil angemeldet. Und just ab dem Zeitpunkt traten die Probleme (mit einem anderen Mobilteil) auf. Das fiel mir heute bei genauerem Nachdenken auf.

Heute kam mir der Geistesblitz: Wir nutzen 2 Repeater. Irgendwo meine ich mal gelesen zu haben, dass die Basis für den Repeaterbetrieb je einen Mobilteil-Slot belegt. Leider kann die Basis das nicht intern verwalten sondern erlaubt fröhlich das Anmelden aller Mobilteile, was dann aber im Betrieb zu diesen schwer nachvollziehbaren Problemen führt.

Bei uns ist das 7. Mobilteil nicht wirklich wichtig, es lag nur so tatenlos rum und wir wollten es als Babyfon einsetzen. Aber wenn man sich auf die Angabe der 8 Mobilteile verlässt, kann man da böse Überraschungen erleben.

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.

Schon seit einer Weile stört mich, dass ein handelsüblicher Desktop-PC mit etwa 80 Watt Stromverbrauch und einem Geräuschpegel Marke »Kopfschmerzen« so viel Leistung erzeugt, dass man damit prinzipiell alles machen kann was man nie machen wird.

Daher habe ich versucht, mich an diversen Quellen über die neuen Minimalrechner, genannt »NetTop«, zu informieren. Nachdem das mehrfach missglückt ist und keiner Erfahrungen dazu hatte, habe ich mir jetzt einfach mal eine ASUS eeeBox B202 gekauft um damit selbst zu experimentieren.

Vor dem Kauf fällt auf, dass es dieses Gerät (wohlgemerkt unter der selben Modellbezeichnung) entweder mit einer Ausstattung von 2 GB RAM und einem Linux-Betriebssystem oder mit 1 GB RAM und Windows XP Home verkauft wird.
Eine RAM-Erweiterung ist zwar (nach diversen Berichten) nur mit Schraubendreher und sanfter Gewalt beim Öffnen des Gehäuses möglich, aber es stehen zwei Slots zur Verfügung.
Um das 1-GB-Modell also auf 2 GB zu erweitern benötigt man kostenverursachenderweise nur einen 1-GB-SO-DIMM-Riegel, der im freien Markt momentan ca. 10-15 € kostet.

Wenn man jetzt also unterstellt, dass das Linux-System keine nenneswerten Lizenzkosten verursacht und der Aufwand, en ASUS zur Anpassung von Windows betreibt in etwa gleich ist wie der, den ASUS zur Anpassung ihres Linux-Systems treibt, dann ist zu erwarten, dass das Windows-Modell um die Windows-Lizenz minus 10-15 € teurer ist. Da man natürlich nicht weiß, was eine Windows-XP-Lizenz für einen Großabnehmer kostet, muss ich das empirisch herausfinden.

Da sich das Angebot bzgl. der Verfügbarkeit und der Preise momentan mehrmals täglich ändert, ist der Preisspiegel meiner Bestellung jetzt nicht mehr so extrem nachzuvollziehen:
Letzte Woche wurde die Linux-Variante mit 2 GB RAM um etwa 20 € teurer verkauft als die Windows-Variante.
Das macht einen Windows-Lizenzpreis von -5-10 € pro verkauftem Gerät.

Da bei mir noch nicht absehbar war, wo genau das Gerät später eingesetzt wird und ob dafür die Windows-Lizenz eine Relevanz hat, habe ich mich für diese entschieden, da es mich insgesamt einfach billiger kommt, selbst wenn ich das RAM-Upgrade noch machen möchte.

Schließlich ist es also so, dass sich keiner wundern braucht, dass sich die Windows-Version so viel besser verkauft, da die Linux-Version wirtschaftlich einfach keinen Sinn macht. Und auf einem Desktop-Rechner den man für die tägliche Arbeit einsetzen möchte, würde ich auch ungern das on ASUS vorgekaute Minimalsystem einsetzen sondern lieber ein aktuelleres, Community-gepflegtes System.

Nach meinen ersten Gehversuchen mit eigenen OSM-Karte auf meinem neuen Garmin-Navi wollte ich unbedingt auch Höhenlinien verfügbar haben. Die Höhenlinien werden üblicherweise aus den SRTM-Daten der NASA gewonnen. Es gibt auch Software, die diese Daten nach OSM konvertiert, aber das ist leider eine Windows-Software, die bei mir folglich nicht läuft.

Zudem ist es etwas unpraktisch, wenn sich jeder die Rohdaten runterladen muss un die dann selbst konvertiert. Ich habe daher auf der OSM-Mailingliste nach jemandem gefragt, der einen entsprechenden Bereich konvertiert und das Ergebnis dann bei dem besten Provider der Welt auf den Mirror-Server gelegt:
http://mirror.schokokeks.org/OpenStreetMap/SRTM/

Dort befinden sich (im entsprechenden Unterverzeichnis) die Daten in 10-Höhenmeter-Auflösung oder in 25-Höhenmeter-Auflösung.

Dank und Ehre gebührt Stefan Dettenhofer, der die Dateien erzeugt hat und im Original anbietet, wenn auch nur über eine Kabel-Deutschland-Flatrate.
Bei ihm gibt es aber eine schöne Übersicht über die verfügbaren Kacheln.

UPDATE (2011-01-09): Ich meine mich zu erinnern dass ich neulich gelesen habe dass es jetzt mehrere Anbieter von SRTM für OSM gibt. Ich habe die Dateien vom oben genannten Mirror entfernt.

Da ich seit langem bei OSM aktiv bin, hatte es mich immer wieder gestört, dass ich kein mobiles Gerät habe, auf dem ich diese Karten nutzen kann.

Momentan gibt es leider keinen voll befriedigenden Weg, OSM-Karte auf einem mobilen Gerät zu betreiben und umfassend zu benutzen.
Die dafür programmierten Anwendungen sind einfach noch nicht so weit, dass man sich damit in fremden Gefilden navigieren lassen könnte und die Hersteller proprietärer Navigationssysteme halten ihr Dateiformat aus verständlichen Gründen unter Verschluss.