Die Daten meines Text-Pads
…gehören mir!
Letzte Woche bin ich über unhosted.org – „Personal data freedom; A movement to separate web apps from user data“ – gestolpert. Und die haben die Web-App „Libre Docs“ auf Basis von Etherpad Lite geschaffen, die das von Libre Docs zur Verfügung gestellte Etherpad nutzt, die erzeugten Daten bzw. Dokumente jedoch in der Cloud ablegt/speichert. Und der Oberknaller daran ist, dass diese Cloud-Schnittstelle mittels der Javascript-Client-Bibliothek remoteStorage.js, die die Realisierung einer W3C-Spezifikation ist, umgesetzt wurde und somit auch meine eigen Cloud benutzt werden kann.
Wie jetzt, meine eigene Cloud…!? – Na die, die ich mit ownCloud auf meinem Webspace betreibe und in der ich schon meine(n) Kalender (CalDAV), mein Adressbuch (CardDAV) und ein paar Dateien (WebDAV) mittels Desktop (Thunderbird & Ubuntu) und Smartphone (Android) verwalte und synchronisiere.
Also ich kanns nur empfehlen und bedanke mich jetzt schon mal bei allen Beteiligten der oben genannten Projekte! 
Thunderbird-Lightning-Huddelei
Ich verstehe es nicht… – System-Update (Ubuntu Precise; ohne fremde PPAs) auf Thunderbird 12.0.1 und danach funktioniert die manuell installierte Lightning-Extension (1.3) nicht mehr.
Nach etwas Suchens bin ich dann zu einer Lösung gekommen: Installation der Version 1.4.
Allerdings ist diese Version nur (direkt) über addons.mozilla.org und nicht über die Hauptseite des „Mozilla Calendar“ Projekts erhältlich. Auf der Projektseite wird als aktuelle Versionsnummer die 1.3 angegeben… *naja*
Trotz alledem: Es funktioniert wieder alles und die CalDAV-Unterstützung, welche IMHO (auch) durch das Team von Inverse inc. unterstützt/voran getrieben wird, ist großartig!
eCryptfs-Meldungen im syslog
Seit ein paar Tagen habe ich in meinem /var/log/syslog ein paar hässliche Meldungen, die das ganze syslog ‚vollmüllen‘.
Hier mal ein Beispiel:
Apr 24 08:55:10 axolotl kernel: [36283.935663] Valid eCryptfs headers not found in file header region or xattr region, inode 1717173 Apr 24 08:55:10 axolotl kernel: [36283.935674] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
Auf der Suche nach Ursache & Lösung bin ich über
- den launchpad-Bug #509180 („ecryptfs sometimes seems to add trailing garbage to encrypted files“) und
- den Blog-Artikel „eCryptfs Fehler und seine Ursache“ von Raphael (aus dem Jahr 2010) gestolpert.
Das Problem der Meldungen (siehe Raphaels Erklärungen) ist wohl, dass es in meinem (mit eCryptfs verschlüsseltem) home Dateien gibt, die eine Größe von 0 Bytes haben. Wie die da hin gekommen sind kann ich nicht mehr rekapitulieren, da ich mir auch nicht mehr ganz sicher bin, seit wann die Meldungen im syslog stehen (und ich ebenfalls wenig Lust habe, die alten syslog-Dateien zu durchsuchen…).
Am Ende habe ich nun Folgendes durgeführt, um das eCryptfs wieder konsisten zu machen & somit auch die Meldungen los zu werden.
sudo find /home/.ecryptfs/$username/.Private/ -xdev -size 0c($username= mein Login-Name)- Der erste Befehl sucht alle Dateien mit der 0-Byte-Größe und gibt diese aus. – Bei mir waren es zehn dieser Dateien.
- Danach habe ich alle ausgegebenen Dateien per Hand nochmal kontrolliert –
ls -lha $datei. - Abschließend (nachdem ich festgestellt hatte, dass alle Dateien wirklich mir gehören & wirklich 0 Bytes groß waren) habe ich dann alle zehn Dateien einzeln gelöscht:
sudo rm "$datei".
Das Ganze habe ich immer mit root-Rechten (sudo) gemacht, da es ohne diese ständig zu Fehlermeldungen bzgl. der Rechte kam – was aber auch an der Benutzung von trash-cli liegen kann!
Zusammenfassend kann ich sagen, dass
- seit dem die Meldungen im syslog nicht mehr vorhanden sind *claro!*;
- ich seit dem keine Probleme feststellen konnte,
- der Bug offensichtlich (für bestimmte Anwendungen) bereits gefixed ist (nichts desto trotz kann ein Systemcrash nat. dazu führen, dass diese Dateien wieder existieren und dann mosert eCryptfs ja zurecht…) und
- ich der Meinung bin, dass man die Dateien relativ gefahrlos löschen kann – 0 Byte große Dateien haben keinen (privaten) Inhalt und sollte es sich um Spezialdateien von bestimmtn Anwendungen handeln, werden die beim Neustart der Anwendung wahrsch. wieder neu erstellt.
In diesem Sinne & ohne die Übernahme irgend welcher Gewehre,
der sokai
Ubuntu: Downgrade vom „proposed“-Repo
Schon seit einer Weile habe ich unter Ubuntu auf meinem EeePC das „proposed“-Repository installiert. Doch gerade nach meinem Upgrade zu Oneiric habe ich einige merkwürdige Erscheinungen, als deren Ursache ich eben dieses Repo in Verdacht habe. (Außerdem ist das „proposed“-Repo für ein Produktivsystem – auf dem also im Alltag alles funktionieren soll – wohl eh nicht gut…)
Nun wollte ich einfach das „proposed“-Repo deaktivieren und mein System sozusagen (wieder auf den Standard) „deaktualisieren“. Aber irgendwie funktioniert das nicht so einfach…
Nach einigem Suchen habe ich dann einen funktionierenden Weg bei „Ask Ubuntu“ gefunden, den ich hier mal (auch für mich zum Merken) verlinke: „How can I revert back from an upgrade to the Proposed repository?“.
Noch ein kleiner Hinweis zu obigem Vorgehen: Bevor ihr die beiden Skripte durchlaufen lasst, deaktiviert das „proposed“-Repo nicht. Erst nachdem ihr euer System deaktualisiert habt, könnt ihr bspw. über die Software-Paketquellen-Verwaltung auf dem Reiter „Aktualisierungen“ den Haken beim Repo weg machen.
Viel Glück!