Bernds Blog

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.

Wir haben vor Kurzem ein Upgrade von MySQL 5.0 auf 5.1 vollzogen. Nach dem Update fiel auf, dass beim Zugriff auf einige (wenn nicht alle) Views eine Warnung kommt: View [...] has no creation context

Die Meldung lässt sich am einfachsten dadurch beheben, dass man den View einfach mit sich selbst überschreibt. Da dies bei uns eine größere Menge Views war, habe ich dazu folgendes Stück Code geschrieben.
(Ich nutze dafür unsere SQL-Library, die einfach eine gewisse Abstraktion bereitstellt, z.B. die Zugangsdaten aus einem Configfile lesen, DictCursor initialisieren und db.query() als Wrapper für db.execute() und db.fetchall(). Diese Library sollten wir wohl demnächst mal veröffentlichen. :))

#!/usr/bin/python



import re



from sql import sql

db = sql()



views = db.query("select TABLE_SCHEMA `schema`, TABLE_NAME `name` "+

                 "FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION =''")



for v in views:

  print 'fixing %s.%s\n=========================' % (v['schema'], v['name'])

  vdef = db.query("SHOW CREATE VIEW %s.%s" % (v['schema'], v['name']))

  new = re.sub('CREATE .* VIEW (`?%s`?.)?`?%s`?' % (v['schema'], v['name']), 

               'ALTER VIEW `%s`.`%s`' % (v['schema'], v['name']), vdef[0]['Create View'])

  db.query(new)

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.

Heute fiel mir eine sehr unschöne Sache bei .org-Domains auf. Registriert man eine solche Domain und setzt Nameserver-Einträge, die ebenfalls unter .org laufen, dann ruft die .org-Registry die IP-Adressen dieser Nameserver ab und speichert die. Diese werden dann zusammen mit der NS-Antwort als "Additional Section" an den anfragenden Client übertragen.

Das Ganze ist eine eigentlich nette Service-Leistung und klingt auf den ersten Blick plausibel.

Das Problem beginnt allerdings dann, wenn sich die IP-Adressen der Nameserver ändern. Bei uns wurde einer der drei Name-Server vor über einem halben Jahr entfernt und ein zweiter letzte Woche. Die .org-nameserver liefern aber noch immer unbeeindruckt die alten Adressen aus. Das führt dazu, dass unsere .org-Domains ohne unser Wissen jetzt nicht mehr nur schlecht sondern sogar sehr schlecht erreichbar waren.
Durch eine Änderung der Nameserver kann man erreichen, dass diese IP-Adressen neu angefragt werden. Wie man diesen Vorgang für die einmal irgendwann eingetragenen DNS-Server-Namen macht, ist mir schleierhaft.

Ich hatte mir heute den Tag über Gedanken über ein mögliches DoS-Angriffs-Szenario gemacht, aber kein wirkliches gefunden. Ich hab aber immer noch das Gefühl, dass man das DoS'en kann.

Ich komme mir grade vor als hätte ich ein paar Jahre hinterm Mond gelebt. Und zwar war mir die Existenz von CSS »block formatting contexts« völlig fremd.

Für meine Leser, von denen ich erwarte, dass es ihnen genauso geht, kurz ein Abriss:
Wenn man ein Element mittels float: left links ran kleben will, ist das einfach. Will man aber dieses float mittels clear: left wieder aufheben, dann fängt der nachfolgende Text erst unter der meistens vorhandenen linken Sidebar an. Zudem macht Internet-Explorer (< 7) gerne mal sehr komische Dinge bei einem traditionellen Sidebar-Layout.

Auf der Suche nach einer Lösung bin ich heute darauf gestoßen, dass man ein div auch in einen eigenen Formatierungs-Kontext setzen kann, innerhalb dessen beliebige clear-Statements möglich sind ohne das ganze Layout zu zerstören.

So einfach geht's: Dem Inhalts-div einfach overflow: hidden mit auf den Weg geben. Natürlich kann diese Eigenschaft Nebenwirkungen haben. Z.B. wenn man ein Element hat, das potenziell breiter ist als das Browser-Fenster. Sofern man aber die Größe des div nicht festlegt, sollte man oftmals gar keine Nebenwirkungen bekommen.
Der Internet-Explorer möchte (mittels conditional comments) noch zusätzlich ein float: left bekommen, damit das so funktioniert. Aber dann spielt auch der mit.

Die Lösung habe ich auf zahlreichen CSS-Hilfe-Seiten gefunden, eine Seite die es so hinbekommen hatte, dass ich es verstanden hab ist z.B. diese hier.

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.

Gestern habe ich vom neuen CAcert Assurer Test gelesen:

To meet the increased demands on quality assurance due to the CAcert Systems Audit, which is needed to be included in Mozilla’s browsers, CAcert has decided to initiate a Challenge for all for Assurers.
To be an Assurer, you will need to reach 100 assurance points, and you will have to pass the Assurer Challenge. The assurer challenge and training system called CATS is so now avaliable. Under http://wiki.cacert.org/wiki/AssurerChallenge you can find the infos how to join and participate.

Natürlich war ich gleich neugierig und habe den Test absolviert. Da ich schon mehrfach auf Fachmessen für das CAcert-Projekt am Stand tätig war, war der Test inhaltlich machbar. Zeitbedarf: deutlich unter 10 Minuten.

Das Problem an der Sache begann danach. Um das Zertifikat »Certified CAcert Assurer« als PDF ausgestellt zu bekommen, muss man eine möglichst verschlüsselte und zwingend mit seinem X.509-Client-Zertifikat signierte E-Mail an CAcert senden.
Und eben das ist mit KMail zur Zeit eine völlige Katastrophe. Zeitbedarf für mich: 1 Tag. ;-)

Der Reihe nach:
KMail benutzt gpgsm zur Verarbeitung von S/MIME. Das Frontend Kleopatra erlaubt das halbwegs komfortable Einfügen meines Zertifikats in gpgsm. Damit gpgsm überhaupt irgendwelche Zertifikate benutzt, will es eine CRL konsultieren:

gpgsm[12626]: can't connect server: `ERR 50331917 can't exec `/usr/bin/dirmngr': Datei oder Verzeichnis nicht gefunden'
gpgsm: can't connect to the dirmngr: IPC "connect" Aufruf fehlgeschlagen
gpgsm: certificate #04BD1F/1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: Die CRL konnte nicht geprüft werden: Kein Dirmngr
gpgsm: error creating signature: Kein Dirmngr <GPGSM>

CRLs sind eigentlich grundsätzlich sinnvoll, aber nicht bei gpgsm. Um nämlich bei gpgsm eine CRL zu benutzen, braucht man dirmngr. dirmngr braucht dazu aber auch OpenLDAP und man muss beide Kollegen manuell konfigurieren. Es gibt zumindest bei Gentoo keine dafür brauchbare Standard-Konfiguration.

Also will man bei gpgsm lieber auf eine CRL verzichten. Dazu muss man die Option disable-crl-checks in die Datei ~/.gnupg/gpgsm.conf eintragen.

Das nächste Problem sieht so aus:

gpgsm: Fingerprint=13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
gpgsm: DBG: BEGIN Certificate `issuer':
gpgsm: DBG: serial: 00
gpgsm: DBG: notBefore: 2003-03-30 12:29:49
gpgsm: DBG: notAfter: 2033-03-29 12:29:49
gpgsm: DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.4
gpgsm: DBG: SHA1 Fingerprint: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
gpgsm: DBG: END Certificate
gpgsm: after checking the fingerprint, you may want to add it manually to the list of trusted certificates.
gpgsm: Interaktives vertrauenswürdig-Markieren ist in gpg-agent ausgeschaltet
gpgsm: error creating signature: Nicht vertrauenswürdig <GPG Agent>

Der hervorgehobene Teil führt zum Ziel; man muss in der Datei ~/.gnupg/gpg-agent.conf die Zeile allow-mark-trusted eintragen.

Damit der gpg-agent das auch weiß, muss er neu gestartet werden. Überflüssig zu erwähnen, dass natürlich alle Programme, die den gpg-agent verwenden möchten auch neu gestartet werden sollten. Insbesondere gilt das bei KDE und KMail so, dass KDE neu gestartet werden muss.

Nach dieser Prozedur fragt gpg-agent bei Bedarf in kaputtem UTF-8 nach, ob das Zertifikat okay ist. Bestätigt man das, stürzt er erst einmal ab:

*** glibc detected *** gpg-agent: free(): invalid next size (fast): 0x000000000065d190 ***
======= Backtrace: =========
/lib/libc.so.6[0x2ac27fb11b7d]
/lib/libc.so.6(cfree+0x76)[0x2ac27fb13896]
gpg-agent[0x415452]
gpg-agent[0x409649]
gpg-agent[0x428a38]
gpg-agent[0x40867c]
gpg-agent[0x407851]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2ac27fac01f4]
gpg-agent(realloc+0x1e1)[0x4053c9]
======= Memory map: ========
[...]

Beim nächsten Versuch sollte aber alles soweit klappen.


Damit konnte ich dann eine X.509-signierte und -verschlüsselte E-Mail senden.

Am nächsten Morgen ...

Heute war dann die Antwort von CAcert da, eine E-Mail mit ~140 KB. KMail sagt dazu:

Verschlüsselte Nachricht (keine Entschlüsselung möglich)
Grund: Nicht unterstütztes Verfahren
smime.p7m
S/MIME Encrypted Message

Ende der verschlüsselten Nachricht

Um dieses Problem weiter einzugrenzen habe ich die Datei smime.p7m gespeichert und mit gpgsm auf der Konsole versucht, weitere Infos einzuholen:

$ gpgsm -v --decrypt smime.p7m
gpgsm: unsupported algorithm `1.2.840.113549.3.2'
gpgsm: (Dies ist der RC-2 Algorithmus)
gpgsm: message decryption failed: Nicht unterstütztes Verfahren <GPGSM>

Eine kleine Internet-Such-Aktion später war klar: gpgsm unterstützt den alten RC2-Algorthmus schlicht und einfach nicht mehr. Thunderbird meint aber leider viel zu oft, diesen benutzen zu müssen.

Einzige mir sinnvoll erscheinende Lösung: Ich habe Mozilla Thunderbird installiert, dort meinen IMAP-Zugang konfiguriert, mein X.509-Zertifikat importiert und mit diesem die E-Mail geöffnet und das angehängte PDF gespeichert.


Nach knapp 10 Minuten Assurer-Prüfung und etwa einem Tag Kampf mit S/MIME bin ich nun also offiziell Certified CAcert Assurer Nummer 78. ;-)

Lange plagt mich (und einige in meinem Umfeld) schon das Problem, dass man bei Firefox nicht offensichtlich gespeicherte Formulardaten löschen kann.
Diese Speicherung ist ziemlich praktisch, aber beim Löschen der Daten gilt immer alles oder nichts.

Aber nicht so, es geht einfacher:

Wenn das Formularfeld »aufklappt«, einfach den zu löschenden Eintrag mit der Maus anvisieren (also nicht klicken) und Shift + Del drücken.

Diese Funktion ist verdammt gut versteckt und es hat jetzt mehrere Jahre halbherziges Suchen erfordert, das herauszufinden. Aber jetzt find ich es praktisch. ;-)

Wer einen Account auf einem Server hat, dem kommt ab und zu das Verlangen, sich in der Fremde einfach mal dort einzuloggen um eine vertraute Umgebung vorzufinden. Seit es um den perfekt konfigurierten »mutt« zu benutzen, schnell im »screen« dem laufenden »irssi« zu zu schauen oder einfach um eine vorher dort hinterlegte Datei zu lesen.

Praktisch ist es natürlich gefährlich, sich von einem nicht vertrauenswürdigen Rechner auf einem Server einzuloggen. Bei der Eingabe des Passwortes auf einem fremden Rechner besteht immer die Gefahr, dass ein böswilliger Admin, ein Schäuble oder die Werbeindustrie einfach alle Tastendrücke aufzeichnet und damit sehr einfach das Passwort für den sicher geglaubten Account erhält.

Um diesem Problem generisch, also für alle fremden Rechner brauchbar zu begegnen, gibt es Einmalpasswörter. Mit diesem Verfahren (das in etwa den TANs vom PIN/TAN-Onlinebanking nahe kommt), gibt es eine Liste von Passwörtern, die jeweils nur einmal gültig sind. Sind die verbraucht, sind sie ungültig.

Unter unixoiden Systemen hat sich dafür das S/Key-System einen Namen gemacht. Es läuft auf den meisten Plattformen und lässt sich sauber z.B. mit PAM einbinden. Das Verfahren ist sehr transparent und die Einmalpasswörter lassen sich mit dem challenge, das vom Server beim Login genannt wird auch extern berechnen. So braucht man keine Papier-Liste mitnehmen sondern kann z.B. mit einem Java-fähigen Handy die Einmalpasswörter (auf einem vertrauenwürdigen Gerät) errechnen lassen.

Sehr edel das ganze, daher haben wir das auch gleich auf schokokeks.org eingebaut. Als Anleitung verweise ich hier mal auf unseren Wiki-Artikel zu Einmalpasswörtern.

Sei noch erwähnt, dass es mehrere Möglichkeiten gibt, S/Key unter SSH zu benutzen. SSH bringt eine solche Funktionalität selbst mit (Gentoo-USE-Flag skey) und es gibt alternativ dazu das PAM-Modul pam_skey.

Wir haben uns für letztere Variante entschieden, da die SSH-Lösung für den Benutzer weniger transparent ist. Bei SSH wird erst nach dem normalen Passwort gefragt und wenn dies leer oder falsch ist, dann wird nach dem S/Key-Einmalpasswort gefragt.

Bei pam_skey dagegen wird, sofern der Benutzer skey für sich aktiviert hat, gleich nach »S/Key response or system password« gefragt. Ist skey für den Benutzer nicht aktiviert, wird das PAM-Modul einfach übergangen und das normale Passwort abgefragt.