Hintergrund: Beim Würfeln des Postfix (der temporären Hostadresse) verwendet Linux zwei Timer: valid lifetime und preferred lifetime. Solange die preferred lifetime nicht abgelaufen ist, verwendet der Kernel für rausgehende Verbindungen diese Adresse. Im Hintergrund wird daneben noch eine Liste geführt mit abgelaufenen IPv6-Hostadressen für die aber noch Verbindungen akzeptiert werden (valid lifetime).

In dem betroffenen System sind beide Werte große genug, daß dies auch für lange Verbindungen kein Problem darstellen sollte:

$ sysctl net.ipv6.conf.eth1.temp_valid_lft
net.ipv6.conf.eth1.temp_valid_lft = 604800

$ sysctl net.ipv6.conf.eth1.temp_prefered_lft
net.ipv6.conf.eth1.temp_prefered_lft = 86400

Obwohl das System vor nicht allzulanger Zeit gebootet wurde zeigt ein ip -6 addr show bereits mehrere temporäre IPv6-Adressen mit verdächtig kurzen Lebenszeiten:

inet6 2002:55b4:2d3b:1:3059:12ab:caf1:8475/64 scope global temporary dynamic
valid_lft 245sec preferred_lft 65sec
inet6 2002:55b4:2d3b:1:98f4:ba60:7ed3:dbba/64 scope global temporary deprecated dynamic
valid_lft 155sec preferred_lft 0sec
inet6 2002:55b4:2d3b:1:607a:bd6c:25d4:f4b8/64 scope global temporary deprecated dynamic
valid_lft 43sec preferred_lft 0sec

Es hat sich rausgestellt, daß der Kernel die definierten Werte mit der Lebenszeit der Router-Advertisements überschreibt und dies auch dann tut, wenn vor dem Ablauf des alten ein neues Advertisement empfangen wurde.

Offenbar ist das Ganze sogar in RFC3041 so gefordert. Seit Kernel-Version 3.2 ist das neuere RFC4941 implementiert, daß diese Schwachstelle ausbessert. Leider sind damit ohne Kernel-Update die Privacy-Extensions auf älteren Systemen ziemlich untauglich. Aber immerhin scheint das Problem in einer Vorabversion von Ubuntu 12.04 behoben zu sein.

Nach längerer Fehlersuche stellt sich heraus, daß die Mails in die Unterverzeichnisse von /var/spool/courier/tmp/ eingestellt werden, aber die Einreihung in die Queue scheitert. Ein Aufruf von mailq zeigt keine Einträge an.

Ein strace -Ffo out.txt bash -c 'echo test|sendmail adresse@example.com' offenbart, daß eine Datei nicht geöffnet werden kann:

24201 open(“/var/spool/courier/tmp/trigger”, O_WRONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENXIO (No such device or address)

Bei trigger handelt es sich um eine Pipe. Das Schreiben eines einfachen Newlines in die Datei veranlasst den courierd-Prozeß die Daten aus dem tmp-Verzeichnis zu Scannen und in die Mail-Queue einzureihen. Klappt das Öffnen einer Pipe-Datei nicht, ist das ein Zeichen dafür, daß auf der anderen Seite ein Prozeß fehlt, der die Befehle entgegen nimmt.

In der Tat fehlt der zentrale Prozeß courierd. Ein manueller Aufruf mit strace -fo out_courierd.txt /usr/lib/courier/sbin/courier start führt zu der Ursache des Problems:

1938  stat64(“/etc/sysconfig/i18n”, 0xbfe96c10) = -1 ENOENT (No such file or directory)
1938  open(“/etc/sysconfig/i18n”, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)

1938  write(2, “/etc/courier/courierd: line 43: “…, 79) = 79

Während des Aufstartens wird die Konfigurationsdatei /etc/courier/courierd im Shellkontext aufgerufen. Diese Datei ist im Grunde ein Shell-Skript und setzt bestimmt Umgebungsvariablen, die von später gestarteten Prozessen ausgewertet werden.

Beim Durchlaufen des Skripts ist offenbar ist Zeile 43 ein Fehler aufgetreten, der zum Abbruch führte. Tatsächlich wird dort schlicht /etc/sysconfig.i18n eingebunden (. /etc/sysconfig.i18n).

Aus welchen Gründen auch immer ist auf dem betroffenen System diese Datei nicht vorhanden. Dazu muß man wissen, daß bei courier in letzter Zeit größere Umbau-Arbeiten im Internationalisierungs- und Sprachenbereich stattgefunden haben. Wahrscheinlich deshalb hat das Fehlen der Datei erst in dieser Version zu einem schweren Fehler geführt.

Das Problem lässt sich einfach lösen, indem man die Datei /etc/sysconfig.i18n mit folgenden Standardwerten füllt:

LANG=”de_DE.UTF-8″
SYSFONT=”latarcyrheb-sun16″

Nach einem /etc/init.d/courier restart start auch wieder der courierd – Prozeß und das Queueing funktioniert wieder.

RewriteEngine on
# Prevent redundant rewrites - only rewrite when https is off
RewriteCond %{HTTPS} !=on
RewriteRule ^/tracks(.*) https://example.com/tracks$1 [R,L]

ServerSignature On
ProxyRequests Off

     Order deny,allow
     Allow from all

ProxyPass /tracks http://127.0.0.1:3000
ProxyPassReverse /tracks http://127.0.0.1:3000
ProxyPreserveHost On

Im Grunde ist das nicht besonders schwer. tt-rss bietet schon von sich aus für jeden Feed einen Link an, der wiederrum die Inhalte des ursprünglichen Feed beinhaltet:

Passt man die GET-Parameter an, kann auch man auf die ungelesenen Einträge filtern:

public.php?op=rss&view_mode=unread&id=1key=abcde123

Der Parameter id spiegelt dabei die interne ID des abonnierten Feeds wieder. Der Parameter key ist ein Zufallswert, der für jeden Feed und tt-rss-Benutzer eindeutig ist. Damit ist es möglich auch ohne die Login-Daten einzutragen, diesen speziellen Feeds zu abonnieren.

Calibre selbst wiederrum fasst Feeds in sogenannten Recipes zusammen, wobei ein Recipe in einem einzelnen Ebook mündet. Die Advanced-Einstellung offenbart den zugrundliegenden Python-Code:

class AdvancedUserRecipe1324229980(BasicNewsRecipe):
   title = u'ttrss'
   oldest_article = 100
   max_articles_per_feed = 100
   feeds = [(u'Name Feed 1', u'https://server/ttrss/public.php?op=rss&view-mode=unread&limit=200&id=22&key=29...'), \
            (u"Name Feed 2", u'https://server/ttrss/public.php?op=rss&view-mode=unread&limit=200&id=64&key=79...)}

Hat man viele Feeds ist es aber zum einen sehr mühsam in der tt-rss-Oberfläche sich diese Feeds zusammenzuklicken und händisch GET-die Parameter anzupassen. Aus diesem Grund habe ich das Skript ttrss2calibre geschrieben, was die Handarbeit abnimmt und direkt einen String generiert für den “feeds = ” Teil.

Der Kindle/calibre ist übrigens so schlau, nur die Feeds anzuzeigen, in denen tatsächlich es auch ungelesen Nachrichten gibt. Das Endergebnis sieht dann z.B. so aus:

Einen sauberen heise-Feed bekommt man übrigens mit dem rss-extender.

Ein Blick in dmesg verrät, daß ein Dateisystem tatsächlich erst nach 437s gemountet wird:

[  437.483764] device label backup-intern devid 1 transid 1620 /dev/sdb1

Dabei handelt es sich um eine btrfs-Partition, mit der es unter der Version 10.10 keine Probleme gegeben hatte. Für das Problem wurde auch schon ein Bugreport geschrieben. Ironischerweise ist die Ursache ein Bugfix für einen Fehler in Ubuntu 10.10.

Hintergrund

Ist bei einem Eintrag in /etc/fstab das sechste Feld auf “1″ gesetzt (was bei mir aus welchen Gründen auch immer der Fall war), wird auf diesem Dateisystem beim Booten ein fsck ausgeführt. Technisch wird dabei unter /sbin/fsck.[filesystemname] aufgerufen.

Bekanntlich ist nun btrfsck im aktuellen Zustand nur von begrenztem Nutzen. Aus diesem Grund gab es bei 10.10 keinen Symlink von /sbin/fsck.btrsfs auf /sbin/btrfsck. Dies wurde aufgrund des ersten Bugreports “gefixt”. Aufgrund der unvollständigen Implementierung führt btrfsck aber einen jedesmal einen vollen Scan des Dateisystems durch, auch wenn es zuletzt korrekt ungemountet wurde.

In letzter Konsequenz wird also bei jedem Booten ein voller Dateisystem-Scan durchgeführt, was zu der erheblichen Verzögerung führt.

Workaround

Entweder den Symlink /sbin/fsck.btrsfs löschen oder das sechste Feld in /etc/fstab auf “0″ setzen.

Will man Outlook 2007 dazu bringen Emails grundsätzlich erstmal als Text-Only anzuzeigen, so findet man diese Einstellung nicht etwa unter Extras - Optionen, sondern im Vertrauenseinstellungscenter und dort im Unterpunkt E-Mail-Sicherheit.

Wer hat sich das nur wieder ausgedacht …

• Befehle in der crontab des Users werden doppelt – zweimal hintereinander – ausgeführt.
• su – Kommandos auf den User werden doppelt ausgeführt (su -c ls user führt zur zweifachen Ausgabe des Verzeichnisinhaltes)

Nach einigen Nachforschen hat sich ein Zusammenhang zu ecryptfs rausgestellt. Mit einem testweise umbenannten ~/.ecryptfs verschwanden die Phänomene. Dabei hatte der User ein ~/.ecryptfs angelegt, welches nicht beim Einloggen automatisch eingehängt wird (~/.ecryptfs/auto-mount existiert nicht).

Das Verhalten ist auch schon beschrieben im Ubuntu-Bugtracker :

This bug is most likely not in cron. The integration of eCryptfs in PAM is causing problems elsewhere as well. If I log out from a VC and have an ~/.ecryptfs directory, then logout behaves weirdly, and I have to quit *two* shells, before I’m actually logged out.

The icky behaviour seems to be triggered because I’m not using the ~/.ecryptfs/auto-mount option.

Glücklicherweise funktioniert der dort beschriebene Workaround (in /etc/pam.d/common-session* ecryptfs auskommentieren) auch in meinem Fall und die Befehle kommen nur noch einmal zum Zug.

Das ganze ist auch Beschrieben unter http://neokipling.blogspot.com/2011/05/ecryptfs.html .

#
# Email am 2010-02-17:
# "Mein Alter ist diesmal eine Primzahl, deren Quersumme um genau
# eins größer ist als der Tag meines Geburtsdatums."
#

def isprime(n):
   for x in range(2, int(n**0.5)+1):
      if n % x == 0:
         return False
   return True

for p in range(1,100):
    if isprime(p):
       a = int(p/10)
       b = p % 10
       # Tag auf sinnvolle Werte einschraenken
       if (9<=(a+b)) and ((a+b)<=15):
          print p

Nach einem Ändern der Zeit innerhalb des Gastes sprang jedoch die Zeit wieder auf die des Hosts-Systems. Weder das Ausschalten der automatischen NTP-Synchronisierung unter Windows, noch der Aurruf von VBoxManage modifyvm <name> -biossystemtimeoffset -3600  brachte den Erfolg.

Die Lösung ist, die automatische VirtualBox-Zeit-Synchronisierung explizit auszuschalten:

vboxmanage setextradata [VMname] “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “1″

Einschalten (default-Zustand) lässt sie sich wieder mit

vboxmanage setextradata [VMname] “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “0″

Die Wirkung setzt jeweils erst nach einem Neustart des Gastes ein.

Der Fix besteht darin, den lokalen Cache des Outlook-Adressbuchs zu löschen. Dazu schließt man Outlook, sucht man im Windows-Profil-Verzeichnis nach *.oab – Dateien und löscht diese einfach.

Im oben beschriebenen Fall waren beim nächsten Starten von Outlook im Adressbuch die vermissten Einträge wieder sichtbar.