Skip to content

Fehler beim Aktualisieren in F-Droid

Beim letzten Update von F-Droid gab es Probleme. Updates wurden nicht mehr geladen und stattdessen zeigte das Telefon die Meldung »error getting index file« an. Nach einigem erfolglosen Herumprobieren stieß ich auf den Mastodon-Account von F-Droid. Laut der letzten Meldung versuchten die Entwickler einen anderen Fehler zu beheben. Dies löste dann dieses Problem aus.

Doch wie lässt sich das nun beheben? Ein Hinweis liefert der Blogbeitrag der Entwickler. Sie schreiben, man solle das alte Indexformat aktivieren. Dazu geht ihr im F-Droid auf Optionen. Recht weit unten in den Einstellungen müsst ihr den Expertenmodus aktivieren und dann findet ihr ganz unten den Menüeintrag «Altes Index-Format erzwingen«. Nun lassen sich, wie gewohnt, die Updates herunterladen und installieren.

Viel Spass mit aktueller freier Software auf euren Smartphones.

mutt will jede E-Mail entschlüsseln

E-Mail in muttMein Mailprogramm mutt brachte mich kürzlich zur Verzweiflung. Denn beim Öffnen eines Mailordners wollte die Software jede E-Mail öffnen. Insbesondere bei verschlüsselten Mails wurde immer wieder nach dem Passwort gefragt. Enthielt der Ordner mal keine verschlüsselte E-Mail, so erschien immer noch die Meldung Kann keinen Mailcap-Eintrag für [MIME-Typ] finden.. Der MIME-Typ hängt vom eventuellen Anhang der Mail ab. Beispiele sind image/png, application/pdf oder anderes. Wie lässt sich das Problem nun lösen?

Immerhin wusste ich, dass die Probleme nach einem Update auf Ubuntu 12.04 begannen. Also vermutete ich das Problem bei Ubuntu. Allerdings zeigte ein Debian mit derselben Konfiguration gleiches Verhalten. In der Manpage von mutt suchte ich nach einem Debugging-Schalter. Den gibt es nicht. Jedoch lassen sich systemweite und lokale Variablen deaktivieren.

  1. mutt -n -F /dev/null war der erste Versuch. Der Schalter -n umgeht die systemweite Konfiguration und -F /dev/null legt den Ort der lokalen Konfiguration fest. In dem Fall bekommt mutt ein Dateiendezeichen (EOF) und nutzt also keine Konfiguration. Mit den Einstellungen trat das Verhalten nicht auf. Also zum nächsten Versuch
  2. mutt -F /dev/null nutzt nur die Systemkonfiguration. Auch hier trat das Verhalten nicht auf.
  3. mutt -n nutzt nur die lokale Konfiguration. Also war klar, dass ich in meinen Einstellungen weiter suchen muss.

Bei knapp 100 kB an Konfigurationsdateien ist suchen natürlich leichter gesagt als getan. Glücklicherweise habe ich die Dateien mit source eingebunden. So kam ich vergleichsweise schnell auf eine Datei, die sich um die Farbgestaltung der Einträge im Index kümmert. Mit klassischer Binärsuche ging es dann weiter und nach etwa zehn Schritten fand ich den Übeltäter.

color index black black   “! ~b .”

Dieser Eintrag macht bestimmte E-Mails »unsichtbar«. Ich erhalte immermal wieder Spam, der keinerlei Text im Nachrichtenteil enthält. Die obige Regel weist mutt an, den Body (~b) zu durchsuchen. Der Punkt trifft auf ein beliebiges Zeichen zu und das Ausrufezeichen negiert das Ganze. Insgesamt passt diese Regel also auf E-Mail, die keine Zeichen im Body haben. Alle diese E-Mails werden schwarz auf schwarzem Hintergrund gezeichnet.

Jetzt ist also klar, warum mutt unbedingt in diverse E-Mails schauen wollte. Denn nur so kann diese Regel angewendet werden. Also habe ich die zunächst rausgeschmissen. Sven Guckes wies mich später darauf hin, dass mit ~G PGP-Nachrichten ausgeschlossen werden können.

Ich bin mit meinem Mailprogramm nun wieder glücklich und freue mich auf neue E-Mails. :-) 

Spamschutz bei S9Y

Im Hintergrund tut Serendipity oder kurz S9Y seinen Dienst. Vor mehr als sieben Jahren stieg ich von Wordpress auf die Software um. Die Software tut im wesentlichen ihren Dienst. Außer, wenn wie heute, ein Plugin merkwürdige Sachen macht.

Ich hatte bis heute abend das Autosave-Plugin installiert. Das speichert die Einträge zwischen und soll eigentlich vor Datenverlust schützen. Bei mir sorgte es dafür, dass die Rezension mehrfach verschwand. Der Grund war, dass ich auf Speichern im Artikelfenster drückte und das Fenster offen liess. Das Plugin wollte einfach alte Werte speichern und löschte so den Beitrag.

Seit dem Jahreswechsel bereitet mir nicht die Blogsoftware Kopfschmerzen, sondern der Spam der eintrudelt. Anfangs hatte ich den Spamschutz aktiviert, den S9Y von Haus aus mitbringt. Dazu setzte ich ein paar Worte auf die Blacklist. Das reichte aus. Nebenan im Datenkanal habe ich noch das Bayes-Plugin im Einsatz. Das wurde von Beginn an angelernt und verrichtet gute Dienste.

Das S9Y Infocamp hat sich nun dem Thema Spamschutz bei S9Y angenommen. In dem Podcast besprechen sie verschiedene Mechanismen. Dabei kommt die Rede auf die SpamBee. Die arbeitet unter anderem mit versteckten CAPTCHAs. Die vier Podcaster sind voll das Lobes. Ich habe den Podcast glücklicherweise zur rechten Zeit gehört. Denn direkt nachdem ich die Biene hier installierte, traf das Blog eine Spamwelle. Von den Lesern hat das vermutlich niemand bemerkt. Die Spambiene hat den Spam wirklich sehr gut abgefangen. Wer also da draußen mit Spam bei S9Y zu kämpfen hat, sollte unbedingt SpamBee probieren. Vermutlich bringt das Plugin Linderung.

Firefox Add-On Ant Video Downloader spioniert Nutzer aus

Ein Add-On für den Firefox, welches 4 von 5 Sternen hat und von mehr als sieben Millionen Nutzer installiert wurde, sollte doch halbwegs vertrauenswürdig sein. Zumindest legt Linus’ Law diese Erkenntnis nahe. Das Add-On Ant Video Downloader straft diese Annahme nun Lügen.

Der Ant Video Downloader soll Videos von Youtube, Facebook und vielen anderen Seiten auf einfache Weise herunterladen. Daneben hat die Software noch einen anderen Zweck. Sie sammelt Daten über jede Seite, die der Benutzer besucht. Dazu wird eine eindeutige Nummer, die so genannte Ant-UID, angelegt. Wenn eine Webseite aufgerufen wird, sendet Ant eine zweite Anfrage mit eben dieser Nummer, der URL der aufgerufenen Seite sowie der Browserkennung an die Adresse rpc.ant.com.  Somit kommt dort jeder Seitenaufruf (also auch interne URLs im privaten Netzwerk) an, den ihr jemals gemacht habt. Damit aber noch nicht genug. Bei der Deinstallation der Software wird die Informationen mit der eindeutigen Nummer, der Ant-UID, behalten. Wenn ihr die Software später neu installiert, wird genau dieselbe Nummer wieder verwendet. Das ist also eine massive Verletzung der Privatsphäre der Nutzer.

Wie ein Witz klingt da die Privacy Policy von Ant.com:

As a responsible member of the community of website owners, Ant.com solutions (Here in after Ant.com) takes the privacy and security of its users with the highest regard.

Insgesamt finde ich in der Policy keinen Hinweis auf diese Spionagemaßnahme. Glücklicherweise haben die Betreiber der Add-On-Seite die Notbremse gezogen. Zunächst wurde der Download der Software komplett deaktiviert und jetzt ist diese als experimentell gekennzeichnet. Damit sollten nur erfahrenere Nutzer diese installieren können.

Das Beispiel zeigt mal wieder, das man sich offensichtlich auf keine Software verlassen kann und insbesondere das die Warnungen bezüglich der Add-Ons sehr ernst zu nehmen sind.

via InterWeb Task Force und The Register

Fehlersuche

Der Bug mit der Nummer 1926 raubt mir derzeit ein wenig den Nerv. Ich sammle Informationen, um diesem ein wenig auf den Grund zu gehen. Dazu tippte ich die folgende Zeile in meine Shell ein:

for file in `find extra-infos-2011-02 -type f`; do
   awk ‘BEGIN {RS=“” } /history (2000-01-01|2008-09-11|…)/ { print $0 }’ \
     >> wrong.2010-07
 done

Die Datei wollte einfach nicht voll werden. Da knapp über 200000 Dateien durchsucht werden, machte ich mir anfangs keine Gedanken. Irgendwann warf ich einen langen Blick auf die Eingabe, dann noch einen und dann noch einen. Schließlich fiel mir auf, dass $file nicht referenziert wird. Kaum macht man es richtig, schon wird die Datei mit Inhalten befüllt. :-)

Start des Wintersemesters

Heute startete das Wintersemester an der Uni. Für mich ist es das erste Mal, dass ich keine Vorlesungen höre, sondern selbst eine halte. Das Thema ist IT-Sicherheit. Dort bespreche ich die üblichen Schwerpunkte (Kryptografie, Sicherheitsmodelle, CC etc.). Zur ersten Veranstaltung kamen etwa 40 Personen. Ich bin gespannt, wie die Zahl am Ende des Semesters ist.

Heute habe ich als Einführungsbeispiel etwas zu Stuxnet erzählt. Der Wurm ist wegen seiner Komplexität sehr interessant. Es schien so, als ob der Großteil der Teilnehmer meinen Ausführungen folgen konnte. Immerhin gab es am Ende einige Fragen und zur Freude der Studenten war auch einige Minuten eher Schluss.

Am letzten Freitag des Monats startet dann ein Seminar zu Wikileaks. Hier erstaunt mich die Zahl der Teilnehmer. Im Friedolin steht nur der Titel des Seminars und es haben sich etwa 50 Personen angemeldet. Ich würde mich freuen, wenn sich alle für das Seminar entscheiden. Dann können wir vielleicht wirklich etwas auf die Beine stellen.

Natürlich will ich mich in die eine oder andere Vorlesung reinsetzen. In der Mathematik finde ich algebraische Zahlentheorie recht interessant und das passt bei mir gut rein. Andere Vorlesungen sind entweder zu lang oder ich schaffe es zu den Terminen nicht. Dann habe ich mir einige Jura-Veranstaltungen herausgesucht. Eine davon sollte heute beginnen. Als ich die Tür öffnete, stand ich vor einer Wand Menschen und habe den Saal gleich wieder verlassen. Mal sehen, ob die anderen Veranstaltungen genauso sind.

Ich wünsche allen Studenten ein erfolgreiches Semester. :-)

Fehlersuche beim Linux-Kernel (Bootprobleme)

Vor nicht allzu langer Zeit sass ich entspannt bei einem Kaffee und wollte meinen Rechner starten. Einschaltknopf gedrückt und der Bildschirm lächelte mich mit einer Fehlermeldung an:

error: unexpectedly disconnected from boot status daemon
Begin: Waiting for root file system ...

grml, warum muss das ausgerechnet jetzt passieren? Sehr schnell war klar, dass ich an dieser Stelle nicht weiter komme. Also bootete ich einen alten, funktionierenden Kernel und änderte meine grub-Einstellungen entsprechend. Damit lebte ich einige Zeit gut, bis mir mal wieder der Workaround auffiel. Jetzt wollte ich das Problem mal genauer angehen.

Beispielansicht eines Plymouth-Bootscreen

Die Fehlermeldung, die irgendwas von dem Boot Status Daemon erzählte, schien auf plymouth hinzudeuten. Der Sinn der Software ist es, den Bootprozess zu verschönern. Das heißt, es macht schicke Bildchen anstatt der Kernelmeldungen.

Der Bugtracker von Debian hatte einen Eintrag zu meiner Meldung. Die in dem Bugreport genannten Einstellungen änderten bei mir nichts am Problem. In meinem nächstem Versuch wollte ich plymouth deinstallieren. Aber da gab es eine winzige Abhängigkeit zu mountall(8). Der Zufall führte mich zu einem angepasstem Paket, mit dem plymouth deinstalliert werden kann. In freudiger Erwartung startete ich den Rechner neu. Aber es wäre nur zu schön gewesen, wenn sich das Problem so leicht lösen ließe.

Zu diesem Zeitpunkt kam mir in den Sinn, die Bootoptionen quiet und splash zu entfernen. Siehe da, ein wenig mehr kam zum Vorschein:

Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ...

Warten, warten und nochmal warten. Oh, nun noch eine BusyBox-Shell:

(initramfs) Gave up waiting for root device. Common problems:
...
ALERT! /dev/disk/by-uuid/.... does not exist. Dropping to a shell!

Nebenbei stellte ich dann fest, dass die Meldung mit dem Boot Status Daemon nur bei einer speziellen Kernelversion auftrat. Die Meldung oben konnte ich mit jeder Standard-Ubuntu-Kernelversion größer als 2.6.32-20 erzeugen. Für mich wäre es viel wichtiger zu erfahren, woher denn diese Meldung stammt!

Ein Hinweis brachte mich dann zu den Mainline-Builds. Das sind spezielle Pakete des Ubuntu Kernelteams, die recht nahe am Original-Kernel sind. Ich versuchte wieder diverse Versionen. Alle brachten mir die Fehlermeldung. Na gut, dann baue ich eben einen eigenen Kernel.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cp /boot/config-2.6.32-24-generic /usr/src/linux-2.6/.config
make oldnoconfig
make deb-pkg
dpkg -i ../linux*.deb
reboot

Beim ersten Reboot startete der Kernel tatsächlich korrekt. Sollte Ubuntu wirklich einen Bug in den eigenen Kernel eingebaut haben? Plötzlich fiel mir ein, dass die Zeile im grub einen kleinen, aber feinen Unterschied zu den restlichen Einträgen aufwies. Ich hatte root=/dev/sda1 angegeben. Alle anderen Einträge trugen root=UUID=.... Also versuchte ich die Änderung bei den anderen Kerneln und es klappte. Jede Kernelversion bootete mit dieser Änderung.

Jetzt muss ich nur noch herausfinden, warum das nicht klappt und ich bin wieder ein glücklicher Mensch. :-)

Das Bild stammt vom Blog Linux und ich

tweetbackcheck