truecrypt mount ext2 reparieren

Was tun wenn eine ext2-formatierte truecrypt Partition repariert werden muss? Praktisch kann das schnell der Fall sein, wenn z.B. das Filesystem nicht mehr sauber ist und mittels Ext2FS für Mac OS X (Paragon) eingehängt wird.

Dann muß unter Linux e2fsck (fsck.ext2) ran, bspw.

e2fsck -a /dev/mapper/truecrypt1

D.h. der Befehl wird nicht auf die Partition selber, sonder auf den dm-Container ausgeführt. Das bereinigen der Partition funktioniert aber nur zuverlässig, wenn beim truecrypt mount unter „Optionen“ die Checkbox „Do not mount“ angehackt ist, d.h. der eigentliche Inhalt des dm-Containers wird unter keinem Mountpoint (normalerweise /media/truecrypt1) angelegt, trotz aktiviertem dm-Container.

CalDAV Synchronisationsprobleme (mit davical)

Mir ist es jetzt schon zweimal passiert, dass die Clients untereinander die Synchronisation entweder komplett eingestellt haben oder nur noch teilweise Kalendereinträge anzeigten. Was war passiert?

Beim ersten Fall hatte ich in Mozilla Lightning einen Kalendereintrag mit einer speziellen (customized) Wiederholungsregel angelegt (letzter Mittwoch im Monat). Das schmeckt dem iOS Kalender (egal ob Version 4.x oder 5.x) gar nicht – genauso wenig wie dem Programm iCal (3.x) unter Mac OS X (Snow Leopard). In diesem Fall blieb mir nichts anderes übrig als auf diese Wiederholungsregel zu verzichten.
Darauf gekommen bin ich relativ schnell, da ich einfach die letzten Einträge die ich vorgenommen habe sukzessiv zurückgenommen habe.

Der zweite Fall war etwas schwieriger. Am Sonntag erzeugte ich noch munter Einträge (3 Wochen im Voraus) in Mozilla Lightning, alles ok. Beim Blick auf den iOS Kalender fiel mir nichts auf – ich hatte aber eh nur die momentane Woche in Beobachtung.
Das Problem bemerkte ich später wiederum an Lightning, der jetzt einige Einträge gar nicht mehr anzeigte – auch der laufenden Woche. Ausserdem waren die Einträge die ich am Sonntag vornahm, weg (die übrigens im iOS Kalender gar nicht auftauchten).
Was war den hier passiert? Eine Beobachtung des Apache Log ergab, dass sehr wohl alle Kalenderänderungen mit
"PUT /davical/caldav.php/<myCalender>/<current-ID.ics> HTTP/1.1 ..."
immer noch übertragen werden. Einträge löschen wurde übrigens noch sauber synchronisiert. Eine erstmalige Synchro auf einem Mac OS X Rechner mit iCal schlug fehl, nichts wurde übertragen.
Die Lösung brachte eine erstmalige Synchro mit dem KDE Kontact Kalender – der holte alle (auch die verschwundenen) Einträge hervor und zeigte sie an. Und in einem, der am Sonntag angelegten Einträge, befand sich im Beschreibungstext ein Sonderzeichen (falsche Kodierung), welches mit Copy/Paste von einem Webartikel reinkopiert wurde. Nachdem ich das Zeichen entfernte, klappte die Synchro anstandslos auf allen Clients. Daher kann ich nur empfehlen keine Texte aus einer Quelle zu kopieren, bei der die Zeichensatzkodierung nicht mit dem des Kalender-Clients übereinstimmt. Gerade auf Webseiten ist die Kodierung oft sehr unterschiedlich.
Die fast noch wichtigere Erkenntnis ist, dass schnelles Fehlertracking nicht mit einer SW Monokultur zu schaffen ist. Je heterogener die SW Landschaft (Clients) ist, desto robuster läuft der Netzwerkdienst.

Ubuntu 12.04 LTS vs. openSUSE

Vorab: Dieser Artikel ist noch in Bearbeitung

Nach fast 13 Jahren SuSE erwäge ich Ernsthaft die ganze Linux Infrastruktur auf Ubuntu zu migrieren. Nachdem ich Ubuntu 12.04 auf einem Laptop bisher zur vollen Zufriedenheit im Einsatz habe, wird allmählich aus der Erwägung Gewissheit.

Die Gründe sind mannigfaltig:

  • openSUSE muß spätestens alle 18 Monate erneuert werden, ein Distributions-Update ist aber immer mit Problemen behaftet und wird bei Änderungen der Major Release (z.B. von 11.x auf 12.x) nicht empfohlen.
    Ubuntu 12.04 hat hingegen 5 Jahre Langzeitsupport.
  • Ubuntu (und nur Ubuntu) bringt das Desktop System Unity mit. Eigentlich müßte man denken: Oh nein, nicht schon wieder ein neues. Tatsache ist aber, dass Unity sehr stabil läuft (vielleicht gerade wegen seiner rudimentären Einstellungsmöglichkeiten), ein durchdachtes Konzept bietet und sich geschmeidig mit der Tastatur steuern lässt.
    KDE hingegen halte ich persönlich für eine der größten Enttäuschung im Open Source Umfeld. Die Versionen 4.x sind bis heute nicht stabilisiert und immer wieder wird Kompatibilität gebrochen. XFCE läuft zwar recht gut, hat aber im Detail auch kleine Problemchen. Eventuell wäre unter openSUSE ein Gnome Desktop die Lösung, aber das Major Update von 2.x auf 3.x schreckte mich ab (wahrscheinlich wegen der schlechten Erfahrungen des KDE Updates von 3.x auf 4.x).
  • Beim Paketmanagement machte ich mir Umstiegssorgen, denn zypper/YaST läuft auf openSUSE seit der Version 11.0 hervorragend. Tatsächlich steht aber apt-get und das Ubuntu Software Center auf 12.04 LTS der Konkurrenz prinzipiell in nichts nach. Die Syntaxunterschiede zwischen zypper und apt-get sind beherschbar, allerding macht zypper einen leicht besseren Eindruck.
    Es scheint aber so, dass die reduzierte Anzahl von Paketquellen bei Ubuntu im Gegensatz zu openSUSE, mehr Stabilität bietet. Hier denke ich vorwiegend an die vielen unterschiedlichen KDE/Qt Repositories bei openSUSE die sich immer wieder in einem inkonsistenten Zustand befinden und daher den simplen Wunsch ein KDE Programm updaten zu wollen, in einen Albtraum verwandeln.
  • YaST mit seinen vielfältigen Einstellungen gibt es unter Ubuntu in dieser Form nicht. Nur leicht komplex angehauchte Aufgaben müssen auf der Kommandozeile erledigt werden. Die Systemsteuerung kennt nur wenige Einstellungen. Diese sind aber einwandfrei aufgearbeitet – außerdem integriert Ubuntu in den Systemeinstellungen auch die Desktopeinstellungen.
    Eine verwirrende Trennung zwischen YaST und den KDE-Systemeinstellungen wie unter openSuSE gibt es unter Ubuntu nicht.

Zu meistern sind strukturelle Unteschiede zwischen openSuSE und Ubuntu, im Detail wären das

  • administrator access: Unter openSUSE wechselt man auf den root account (id:0). Dieser ist unter Ubuntu deaktiviert, man erledigt alle administrativen Aufgaben mit einem sudo Kommando. Dazu muss man natürlich Mitglied der Gruppe sudo sein.
  • user-ID’sUnter Ubuntu kann man zwar auch neue User manuell mit einer User-ID unter 1000 ausstatten, es kommt dann aber zu Komplikationen bswp. bei der grafischen Anmeldung. Gerade im Umfeld von NFSv3 müssen aber die User-ID’s zwangsläufig synchronisiert werden.

PDFStudio7 als Standardprogramm für .pdf’s unter Linux (Ubuntu 12.04)

Trotz erfolgreicher Installation von PDFStudio7 auf Ubuntu 12.04 und damit gelungener Intregration in das Startmenü (dash in der Ubuntu-Nomenklatura) wurde mir im Dateimanager das Programm nicht für das Öffnen von .pdf Dateien angeboten. Es lies sich auch nicht über den Menüpunkt Andere Anwendungen hervorzaubern.

Abhilfe schafft – bezogen auf den lokalen User Account – folgender Eintrag in die Datei
~/.local/share/applications/mimeapps.list

[Added Associations]
....
application/pdf=pdfstudio7-0.desktop

Die .desktop Datei selber liegt übrigens bei mir unter /usr/share/applications
Möchte man das Programm auch gleich zum Standardprogramm für .pdf Dateien machen, erweitert man die o.g. mimeapps.list Datei mit folgendem Eintrag:

[Default Applications]
....
application/pdf=pdfstudio7-0.desktop

Create (birth) time auf ext4

…nein – eine Create Time gibt es tatsächlich unter POSIX nicht lautete eine nebensächliche Feststellung eines Artikels vom Juni 2007.

Auch wenn es immer noch nicht POSIX konform ist – das gegenwärtige Standardfilesystem auf Linux – ext4 – hat dieses Feature.

Abfragen lässt es sich aber derzeit mit dem stat Kommando leider noch nicht. Die Verrenkung um an das Datum zu kommen lautet:

debugfs -R 'stat NAME_OF_FILE_REALTIVE_FROM_DEVICE_MOUNT_POINT' DEVICE_MOUNT_POINT

CardDAV

Nachdem ich CalDAV zur Synchronisierung von Kalendern schon einige Zeit im Einsatz habe, stolperte ich erst kürzlich über das Adressbuch-Pendant CardDAV. Das Protokoll – ein weiteres der DAV Familie – ist erst im Request For Comments Status, aber dieser ist quasi schon abgeschlossen.
Interessant wurde CardDAV für mich als ich hörte, dass Davical – der CalDAV Server den ich einsetze – seit einiger Zeit (Version 0.9.9.4) auch CardDAV vollständig beherrscht.

Und was gibt es schöneres als synchronisierte Adressdaten?

Ich muss noch dazusagen, dass ich immer noch einen openLDAP Adressserver laufen habe, welcher aber an 2 Krankheiten leidet (und das schon seit Jahren)

  1. Es gibt kein verbindliches Personenschema für die Applikationen (Mozilla verwendet ein anderes als Apple.. und das wiederum hat nichts gemeinsam mit anderen Welten der kommerziellen LDAP Server)
  2. Schreibunterstützung: nada – am besten man programmiert sich seinen eigenen LDAP Client – aber da der Tag nur 24h hat…

Ok – genug geschwafelt: CardDAV rocks – es geht alles

..aber nur nach stundenlanger Frickelei (es lohnt sich aber, also dranbleiben).

  1. Davical updaten, falls nicht schon geschehen. Folgende Stolperfallen warten:
    Ev. sind die User davical_app und davical_dba noch nicht angelegt (kommt bei sehr alter davicaldb vor). In diesem Fall mit
    psql -qXAt -c "CREATE USER davical_app NOCREATEDB NOCREATEROLE;" template1
    psql -qXAt -c "CREATE USER davical_dba NOCREATEDB NOCREATEROLE;" template1
    die User anlegen.
    Einige Sequenzen und Tables gehören ev. direkt postgres anstatt davical_dba – mit folgendem Befehl wird bspw. hier die Sequenz dav_id_seq geändert:
    psql davical -c "ALTER SEQUENCE dav_id_seq OWNER TO davical_dba"
  2. Das Anlegen einer neuen Collection (Principal Collection) ist ganz einfach.
    In der neugestalteten Webseite einfach Ist ein Kalender ab- und Ist ein Adressbuch anhacken. Der Name der Collection ist natürlich wählbar – es empfiehlt sich z.B. „contacts“

    Konkret ist dann diese Kollektion (das Adressbuch) unter /davical/caldav.php/USERNAME/contacts
    auf dem Server zu erreichen.

  3. Mac OS X Adressbuch anschliessen
    Oh ja – wenn man mittels SSL drauzugreift, dann gibts Probleme.
    Im der Applikation Adressbuch kann man zwar ein CardDAV Account anlegen bei dem man die Authorisierungsdaten und den kompletten Serverpfad (s.o.) eingeben kann, man läuft aber immer auf eine Fehlermeldung hinaus.
    Die Lösung ist, zweimal „Create“ anzuklicken um den fehlerhaften Account anzulegen.

    Dann editiert man manuell folgende Datei:

    ~/Library/Application Support/AddressBook/Sources/<UNIQUE-ID>/Configuration.plist
    Dort trägt man unter Server String die komplette URL ein.
    https://SERVERNAME/davical/caldav.php/USERNAME/contacts
    Am besten modifiziert man noch das Feld HaveWriteAccess auf den Wert auf „1“

  4. iPhone Konfigurieren
    Das geht im Falle eines SSL Zugriffes NICHT am Handy selber. Es geht nur über das iPhone Configuration Utility welches man von Apple herunterladen muss.
    Dort erstellt man einen neues Konfigurationsprofil mit einem CardDAV Account und installiert dieses dann auf dem angeschlossenen iPhone (es beeinträchtigt ein ev. vorhandenes Profil nicht!)
    Das Konfigurationsprofil innerhalb dieses Programmes erlaubt die komplette Angabe einer URL (Principal URL).
  5. KDE / akonadi
    Unglaublich – es geht einfach – man muss nur erstmal draufkommen wie.
    In den KDE Systemeinstellungen kann man bei
    Persönliche Informationen -> Einrichtung der Akonadi Resourcen -> GroupDAV Resourcen
    u.a. CardDAV und CalDAV Anschlüsse einrichten, welche dann von allen akonadi-aware Programmen (wie KMail oder Adressbook) genutzt werden kann.

Was noch fehlt ist ein nativer Thunderbird CardDAV Anschluss, es soll über ein 3rd Party Produkt names SoGo gehen.. aber ich sehe grade keinen Grund es auszuprobieren. Stattdessen geniesse ich mit CardDAV eine weitere Perle der OpenSource Welt.

synaptiks 0.7.0

synaptiks ist ein im KDE Umfeld angesiedeltes Programm zur Konfiguration von Touchpads (welche üblicherweise von der Fa. Synaptics stammen)

Seit synaptiks Version 0.7 steht hinter dem Programm nicht mehr der Dienst synaptiks Touchpadverwaltung – welcher automatisch in KDE gestartet wurde. Dieser sorgte dafür, dass innerhalb der KDE-Systemeinstellungen synaptiks nur konfiguriert werden musste, ohne dass man das Programm hätte explizit starten müssen.

Nun ist synaptiks ein Program ohne Dienst im Hintergrund, was folgende Auswirkungen hat:

  • synaptiks funktioniert auch ohne KDE (z.B. in XFCE)

  • synaptiks muss zumindest einmal explizit gestartet werden, so dass es sich im jeweiligen Tray (z.B. KDE-Kontrollleiste) verankert

synaptik KDE Touchpadwaltung

In dem Snapshot sieht man die erste Seite von synaptiks, die früher in den KDE Systemsettings auftauchte. Dort sucht man sie jetzt vergebens. Dafür wird sie einem angezeigt, wenn man das Programm vom Tray aufruft.
Das wichtigste Feature ist auch gleich auf dieser Seite zu sehen: Touchpad bei Tastaturaktivität ausschalten
Der Punkt Beim Anmelden automatisch starten sollte nur aktiviert werden, wenn man den Einrichtungsdialog wirklich bei jedem login ins Windowsystem sehen möchte – ansonsten nicht anhacken. Das Tray Management von einem Windowsystem (KDE,XFCE..) kümmert sich schon um das jeweilige Einladen beim Login.

Noch eine Anmerkung: Momentan stürzt leider das Programm nach einem Wakeup von Suspend-to-RAM ab, was laut dem Autor Sebastian Wiesner bekannt und in Bearbeitung ist.

cups-polld im busy-loop

Falls man in seiner CUPS Konfiguration einen Host permanent abfrägt (BrowsePoll), und CUPS der Version 1.4.x einsetzt, kann es passieren, dass bei länger aussetzender Netzwerkverbindung zum BrowsePoll Zielrechner der cups-polld Prozess in einen busy-loop gerät aus dem der Prozess nicht mehr herauskommt.

Dies kann v.a. auftreten, wenn der CUPS Client sich mit WLAN zum CUPS Server verbindet. Das Fehlverhalten merkt man dann an 100% Auslastung eines CPU-Cores durch cups-polld. Selber konnte ich dass seit längerem auf Mac OS X Clients erleben.
Mac OS X 10.6.8 beinhaltet derzeit CUPS 1.4.7, während Mac OS X Lion CUPS 1.5.x einsetzt, welches ein Bugfix für dieses Problem beinhaltet.

Eine genaue Fehlerbeschreibgung und einen source patch gibt es auf den Bugs Seiten des Debian Projektes
Die Seite wiederum widmet sich aber dem Problem unter Linux – um das Problem auf Mac OS X

  1. reproduzierbar zu machen (und damit testbar)
  2. zu lösen

stellte ich folgende Vorgehensweise auf:

  1. Auf dem Mac OS X Client wird der cups-polld Prozess mangels strace mit der Aktivitätsanzeige beobachtet
  2. Im Normallzustand war der letzte Call von cups-polld:
    _semwait_signal(..)
  3. Auf Linux Seite wird nun die erste Firewallregel geschaltet
    iptables -I OUTPUT 1 -p tcp -d --sport ipp -j REJECT --reject-with tcp-reset
  4. Danach wartet man bis der cups-polld Prozess in die Phase
    recvfrom(...)
    kommt, danach wird auf Linux noch die 2 FW Regel gestartet.
  5. iptables -I INPUT 1 -p tcp -s --dport ipp -j REJECT --reject-with tcp-reset
  6. Danach wird nach ca. 7 Minuten der cups-polld Prozess in den busy-loop übergehen.

Jetzt muss CUPS mit dem auf den Debian Seiten verfügbaren Patch versehen werden. Dazu lädt man derzeit auf den CUPS Seiten die letze 1.4 Version herunter (1.4.8) und patcht diesen. Der Patch beschränkt sich auf die Datei cups/request.c und lautet folgendermassen

+ {
+ status = httpUpdate(http);
+ }
+- while (http->state == HTTP_POST_RECV);
++ while (status != HTTP_ERROR && http->state == HTTP_POST_RECV);
+
+ DEBUG_printf(("2cupsGetResponse: status=%d", status));
+

Beim anschliessenden kompilieren unter Mac OS X ist natürlich die Entwicklungsumgebung notwendig, zumindest die gcc toolchain auf der Kommandozeile. Folgende Schritte sind notwendig:

  • ./configure CFLAGS=“-arch i386 -arch x86_64″ LDFLAGS=“-arch i386 -arch x86_64″

    Dies führt zum Kompilat von 32- und 64bit Varianten der Objects, der statischen Archive und von executables.

  • Das Mischkompilat (Universal Binary für 32- und 64bit Varianten) ist notwendig um die zentrale Bibliothek libcups.2.dylib für beide Architekturen anzubieten. Ansonsten würde so ziemlich alle 32bit Applikationen beim Start crashen.

    Leider reicht das o.g. configure nicht aus um die dynamische Bibliothek auch auf 32bit zum Kompilieren (auf einem aktuellen 64bit Rechner). LDFLAGS greift hier nicht – deshalb muss manuell in der Datei Makedefs in der Zeile ARCHFLAGS ebenfalls -arch i386 -arch x86_64 eingetragen werden. Danach nur noch

  • make
  • make install

Jetzt noch ein bischen zittern beim Neustart und dann war’s das schon,
hier ein fertiges CUPS 1.4.8 Paket für Mac OS X Snow Leopard OHNE JEGLICHE GEWÄHR!

XFCE Window Decorations

auch XFCE ist nicht von Kinder- oder Jugendkrankheiten befreit.

Falls der Auslogvorgang länger dauern sollte, im syslog eine Meldung wie folgende erscheint:
polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session21 (system bus name :1.388, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale de_DE.UTF-8) (disconnected from bus)

dann ist die Wahrscheinlich (zumindest bei Version 4.8.1 auf openSUSE 11.4) gross, daß beim nächsten Login die Window-Decoration fehlen und auch andere Probleme auftauchen.

Grund dafür ist sind Probleme mit dem Sessionmanager – provozieren kann man das, wenn man bspw. Firefox beendet und die Abspeicherung der vielen Daten im .mozilla Unterverzeichnis nicht abwartet, sondern sich versuch sofort abzumelden.
Dass wirft den Sessionmanager aus der Bahn, der dann bis zu seinem Timeout braucht um in diesem Fall die Session zu schliessen.

Der workaround lautet das Verzeichnis .cache des Users zu löschen.

stty -a < /dev/ttyS....

hängt? Ebenso der Befehl

echo „hallo“ > /dev/ttyS…

?? Dann ist wahrscheinlich die Data Carrier Detect Line (DCD) auf High, so dass diese beiden Kommandos auf ewig warten bis die DCD auf Low schaltet.

Umgehen kann man das bei dem ersten Befehl mit

stty -a -F /dev/ttyS...

Dieser benutzt beim open den O_NDELAY Flag, welcher gleichbedeutend zum O_NONBLOCKING ist.
Prinzipiell sollte man aber bei der termios Struktur das c_cflag CLOCAL setzen, welches die Modem Status Lines ignoriert. Wird dieses Flag nicht gesetzt und schreibt die termios Struktur mittels tcsetattr an die serielle Schnittstelle zurück, hat DCD high und obiges Problem tritt auf.