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.

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.

Ich hatte vor einiger Zeit den Tipp erhalten, dass man mit »Disconnected IMAP« (oder auch »Cached-IMAP« genannt) bei KMail das Verhalten hin bekommt, das ich so lange gesucht habe: IMAP aber ein Cache, der mir erlaubt, zumindest die neuesten X Mails jederzeit schnell und ohne Netzverbindung verfügbar zu haben.

Gehört, getan, habe ich mein IMAP-Konto erstmal mit einem Rotations-script ausgestattet (alle Mails älter als 1 Monat wandert in eine andere Mailbox) und das was noch da geblieben ist dann per »Disconnected IMAP« eingerichtet. Erst einmal klang das alles recht gut, die Mailbox war extrem schnell da, man kann ständig jede Mailbox öffnen, auch wenn grade eine andere abgeholt wird.

Die erste Ernüchterung kam sehr schnell: Das Abrufen der Mailbox dauerte etwa 20 Mal so lange wie vorher. Jeder Ordner für sich dauerte fast so lange wie sonst der komplette Baum. Das liegt daran, dass KMail nicht nur nach neuen Mails schaut sondern auch lokale Änderungen (gelesen, ...) hochladen muss.

Ich habe als automatisches, periodisches Abholen eingestellt, sodass ich immer alle Mails sehe. Da man auch während des Abholens andere Ordner schon lesen kann, ist das kein Problem.
Was aber etwas störend war: KMail bzw. der ganze Rechner geriet etwas in Stocken, wenn der IMAP-Abruf-Vorgang lief. Erst fiel das gar nicht sonderlich auf, dann aber immer öfter (man erkennt irgendwann den Zusammenhang ;) ). Als ich bemerkt habe, dass man während des Abrufens keine Mail mehr vernünftig verfassen kann (das Fenster war oft für ~10 Sekunden reaktionslos), habe ich den Entschluss gefasst, wieder zurück auf normales IMAP zu stellen.

Da meine Mailbox jetzt sowieso relativ klein ist, geht auch da das Abrufen sehr flott.

Fazit: Disconnected-IMAP ist eine schöne Idee, funktioniert auch prinzipiell ganz gut, muss aber noch deutlich besser auf Nebenläufigkeit optimiert werden.

Ich nehme an, jeder, der unter Gentoo mal eine Netzwerkkonfiguration eingerichtet hat, die über den Trivialfall hinaus geht, stolpert über das irgendwie krude aber leistungsfähige Konzept des Netzwerk-Init-Scripts.

Leider ist die Doku dazu etwas mangelhaft und beschränkt sich nur auf einzelne Spezialfälle anstatt systematisch alle Möglichkeiten zu dokumentieren.

Heute habe ich eine lange Zeit damit verbracht, einen IPv6-Tunnel zu SixXS einzurichten. Bisher hatte ich das über ein eigenes init-script gelöst, aber das ist ja auch nicht das gelbe vom Ei.

Nach etwas herumprobieren kam ich dann auf eine funktionierende Konfiguration, deren Nennung ich auf den erweiterten Eintrag lege, damit das Layout durch preformatted text nicht zu sehr zerlegt wird.

Letzte Woche ist mir im Server meiner Eltern (Fax- und Dateiserver sowie Router und noch ein bisschen Kleinkram) die Festplatte gestorben und hat alle Daten darauf in die ewigen Festplatten-Jagdgründe genommen (Ja, ein nicht topaktuelles Backup war vorhanden).

Da ich also dann sehr schnell ein neues System gebraucht. Vorher war Gentoo installiert, aber da habe ich mich schon seit geraumer Zeit daran gestört, denn die Upgrades waren immer so heikel, da ich keinen physikalischen Zugriff darauf habe. Also wurde als Feldversuch der Server mit der Serverversion von Ubuntu-Linux eingerichtet. Installation war Ubuntu-Typisch in wenigen Minuten vorbei.

Die kranke Installationsprozedur von DJBdns war mir bekannt und hat mich folglich auch nicht so sehr schockiert. :)

Größtes Problem war, dass beim Aufstellen am späteren Einsatzort das NFS sich ganz komisch verhalten hat. Mozilla-Firefox und -Thunderbird ließen sich nicht starten weil sie angeblich schon laufen (nein, an den Lock-Files lag es nicht), KMail brachte wahllos Zugriffsfehler beim IMAP-Cache und ein sofort eingerichtetes Backup per rsync auf einen anderen Rechner führte oft zu der Meldung »stale NFS handles« und danach gab es nurnoch »permission denied« in dem Verzeichnis. Ein heraus und wieder hineinwechseln behebt das Problem kurzfristig.

Nach etwa einem Tag erfolgloser Suche und vielen Fragen an viele andere ratlose Leute, bin ich zufällig an diesen Bugreport herangestolpert.

Der dort vorgeschlagene Workaround hat bei mir funktioniert: Die Option »no_subtree_check« in alle exports-Einträge aufnehmen.
Bisher traten bei mir keine derartigen Probleme mehr auf.

Als Kritiker von zentralisierten Diensten und sowieso Freund und Verfechter von freiem Datenfluss kann ich natürlich die verbreiteten, proprietären Instant-Messaging-Netzwerke wie ICQ, AIM oder noch schlimmer MSN-Messenger gar nicht gut heißen.

Diese IM-Protokolle gehen alle über einen zentralen Server (ja, ich weiß dass da Cluster stehen), der von jeweils einer Firma betrieben wird und alle Nachrichten die man schickt, können von dieser Firma gelesen und gespeichert werden. Technisch. AOL nimmt sich eben dieses Recht auch in den Nutzungsbedingungen explizit heraus.

Aber zum Glück hat die Free-Software-Gemeinde hier einen guten Gegenvorschlag eingebracht und mit Jabber steht ein System zur Verfügung, das genau diese Krankheit nicht hat. Es ist genau so organisiert wie E-Mail, man hat eine ID in der nicht nur ein Name sondern auch eine Domain enthalten ist und jeder kann (wenn er will) einen Jabber-Server installieren. Es stehen dazu verschiedene freie Varianten zur Verfügung.

Vorteil: Jabber ist sicher. Im Gegensatz zu den meisten anderen IM-Diensten wird bei Jabber (sofern man die Option setzt) alles SSL-gesichert übertragen. Und Jabber ist dezentral. Ich entscheide, wer meine Nachrichten sehen kann. Ich entscheide, wer meine Kontaktliste sieht. Und keiner kann die Liste der Kontakte meiner Kontakte erstellen, solange er nur einen Server einsehen kann, noch nichtmal ich selbst.

Nachteil: Leider ist die Masse der User noch der Meinung, nur was alle haben kann was taugen. ICQ ist einfach "etabliert".

Zum Glück wachsen jetzt nicht, wie vor ein paar Jahren, noch mehr neue Ausgeburten von eigenständigen, proprietären IM-Protokollen. Dennoch gibt es neue Messenger. Und zwar nach Google-Talk nun auch GMX- und web.de-Messenger. Und alle drei bauen auf Jabber auf. Man sieht es nicht an deren Werbung. Aber man kann die Messenger-Funktion mit einem ganz normalen Jabber-Client benutzen.

Also, wenn jetzt alle, die Google-Mail, web.de oder GMX nutzen als Instant-Messenger auch noch Jabber nutzen (Hint: GAIM kann auch noch ICQ zusätzlich), dann wird die Welt wieder ein bisschen besser. Einfach E-Mail-Adresse als Jabber-ID benutzen. Dann kann man mit mir (auch E-Mail-Adresse und Jabber-ID gleich) chatten, ohne dass ich irgendwo bei einer Firma einen zentralen Account brauche.

Kleiner Hinweis am Rande: GMX bietet leider keine Transports zu ICQ und anderen Netzwerken, obwohl das technisch natürlich geht. Unser Jabber-Server hat sowas. :) Zudem muss man zumindest bei PSI die Option "Passwort unverschlüsselt übertragen" aktivieren, was mich nicht grade gefreut hat. Wenigstens funktioniert eine SSL-Verbindung.

Seit einiger Zeit betreibe ich einen IPv6-Block auf unserem Server, zusammen mit ein paar Subnetzen zu meinen Rechnern zu Hause. Alle Verbindungen sind momentan leider per 6-in-4-Tunnel realisiert, da keiner meiner Verbidungs-Provider IPv6 anbietet.

Seit ein paar Tagen nun funktionierte meine Verbindung nur noch ein bisschen, genauer gesagt konnte ich keine Verbindungen von schokokeks.org zu einem per Tunnel angebundenen Rechner aufbauen. Die Verbindung mit dem Tunnel nach außen sowie die Kommunikation verschiedener Tunnel untereinander war unberührt, aber vom Server weg ging es nicht.

Die einzige mit bekannte Änderung des Setups war das upgrade von kernel 2.6.14-irgendwas auf 2.6.17.4-grsec.

Ich habe jetzt mit Bastians Hilfe das Setup so umgestellt, dass ich keine Adressen mehr für die Tunnel-devices benutze und die routing-Tabelle direkt in das device selbst hineinroutet. Wusste garnicht dass das möglich ist, aber es funktioniert und das genannte Problem ist behoben.

Jetzt nochmal zusammenfassend, warum ich gestern herausfinden musste ob ein Kabel in der Netzwerkkarte steckt. ;-)
Und zwar bekam ich einen Anruf, dass das Netzwerk meiner Eltern nicht mehr ganz funktioniert, erst war's "irgendwie komisch" und nach einem Neustart aller beteiligten (incl. Server) ging nichts mehr.

Nach kurzem Debuggen sah für mich alles komplett normal aus, Server von außen erreichbar, interface oben, alle Kabel eingesteckt, alle daemons laufen. Aber kein einziges Bit Daten ging über die Leitung. Ich konnte machen was ich wollte, es ging nichts durch. Auch nicht mit festem ARP-Eintrag und auch nicht die DHCP-broadcasts der anderen Rechner.

Nach dann schon etwas längerem Nachdenken und Googlen kam ich irgendwann auf die Idee, mal das Kernel log anzuschauen. Siehe da, vor dem Reboot einige Kernel-Oops, danach Fehlermeldungen der Art:

May 22 12:31:53 frodo eth0: Transmit error, Tx status register 90.

May 22 12:31:53 frodo Flags; bus-master 1, dirty 1(1) current 1(1)

May 22 12:31:53 frodo Transmit list 00000000 vs. c132b2a0.

May 22 12:31:53 frodo 0: @c132b200  length 8000005a status 8001005a

May 22 12:31:53 frodo 1: @c132b2a0  length 00000000 status 00000000

May 22 12:31:53 frodo 2: @c132b340  length 00000000 status 00000000

May 22 12:31:53 frodo 3: @c132b3e0  length 00000000 status 00000000

May 22 12:31:53 frodo 4: @c132b480  length 00000000 status 00000000

May 22 12:31:53 frodo 5: @c132b520  length 00000000 status 00000000

May 22 12:31:53 frodo 6: @c132b5c0  length 00000000 status 00000000

May 22 12:31:53 frodo 7: @c132b660  length 00000000 status 00000000

May 22 12:31:53 frodo 8: @c132b700  length 00000000 status 00000000

May 22 12:31:53 frodo 9: @c132b7a0  length 00000000 status 00000000

May 22 12:31:53 frodo 10: @c132b840  length 00000000 status 00000000

May 22 12:31:53 frodo 11: @c132b8e0  length 00000000 status 00000000

May 22 12:31:53 frodo 12: @c132b980  length 00000000 status 00000000

May 22 12:31:53 frodo 13: @c132ba20  length 00000000 status 00000000

May 22 12:31:53 frodo 14: @c132bac0  length 00000000 status 00000000

May 22 12:31:53 frodo 15: @c132bb60  length 00000000 status 00000000

Letztlich hat ein Austauschen der Netzwerkkarte das Problem behoben. Da ich nicht selbst vor Ort war, musste ich meine Schwester anleiten, wie man sowas macht. Hat aber geklappt, ich bin stolz. ;-)

Ach ja: Meine andere Idee, das DSL-Modem in den Hub einzustecken und damit nur eine Netzwerkkarte des Servers zu brauchen hat nicht geklappt weil man wohl ein Cross-Kabel zwischen Hub und DSL-Modem bräuchte damit das geht. Jedenfalls gab es keinen physikalischen Link wenn man das Modem in den Hub einsteckt.


[ Update 2006-08-05: Augrund enormem Spam-Aufkommen ist die Kommentarfunktion bei diesem Posting ab sofort gesperrt. ]