Lightning + sogo- Probleme

Moin liebe Leute

Nach einer frustrierenden Woche mit Fehlersuche und endlosen Recherchen im Web gebe ich mich geschlagen. Ich habe keine Idee mehr und hoffe auf erfahrene Helfer und Tips, wie ich meine Probleme lösen

* Thunderbird-Version: aktuell upgedatet von 38.1 auf 38.6
* Betriebssystem + Version: Clients = Debian Jessie, Server = Raspian Jessie als Hoster für die Profile
* Kontenart (POP / IMAP): beides
* Postfachanbieter (z.B. GMX): verschiedene
* Sync-Add-on für Online-Adressbuch?: eigener Server (RPI 2) mit Nginx und Baikal und sogo connector auf den Clients
* Eingesetzte Antivirensoftware: keine
* Firewall (Betriebssystem-intern/Externe Software): keine

Kurze zusätzliche Erläuterung zur "Umgebung": mehrere Clients verwenden ihr eigenes Thunderbird-Profil, die alle zusammen in einem Verzeichnis "Mail" auf der Server-Platte meines Raspberry PI abgelegt sind. Das User-eigene Mail-Dir wird dann jeweils im Server-seitigen-Home-Dir des User ge'bind'et ist, welches (via smb.conf verfügbar gemacht) dann wiederum auf dem Client ins lokale Home-Dir des User gemountet ist.
Tja, das hat jetzt wirklich lange Zeit perfekt funktioniert. Und auf einmal -nach dem Update- geht nix mehr. In den bestehenden Profile kann ich weder lightning noch sogo einrichten. Folgende unterschiedliche Phänomene habe ich, die ich weder gezielt reproduzieren noch vorhersagen kann... soll heissen, das, was nicht funktioniert, scheint eher zufällig von irgendwas anderem getriggert zu sein:

1. Server-Profil: lightning funktioniert, es wird eingerichtet, nach TB-Neustart die Fehlermeldung, dass lightning die falsche Version ist.
2. Server-Profil: sogo wird ohne Fehlermeldungen installiert, ist aber nach dem Neustart nicht mehr vorhanden.
3. Lokales Profil: Ich kann lightning und sogo einrichten. Verschiebe ich das Profil auf den Server, teilt er mir mit, dass lightning nicht kompatibel ist. Keine Option Remote-Adressbuch
4. Neues Server-Profil: Ich kann sogo und lightning installieren und beide werden bei den AddOns gelistet. CalDav funktioniert, der Calender ist vorhanden. Eine Verbindung zum Adressbuch ist nicht möglich, die Option Remote-Adress-Buch existiert nicht.
5. Es funktioniert auf keinem Client, unabhänging vom Desktop: also nicht mit XFCE, LXDE, KDE und auch nicht mit meinem Custom-Desktop

Randbemerkung: Alle Android-Endgeräte verbinden sich unverändert problemlos mit dem jeweiligen persönlichen Cal/Dav-Kalender bzw. mit dem Card/Dav-Adressbuch auf dem Server. Das frustrierende an der ganzen Geschichte ist: Jetzt bekomme ich bei den Linux-Clients nicht mal mehr die vorherige Version 38.1 ans laufen.

Hat jemand eine Idee, wie ich am besten bei der weiteren Fehlerdiagnose vorgehen kann? Meine größte Hoffnung ist, dass es vielleicht hier gleichgesinnte gibt, die eine ähnliche Lösung via RPi eingerichtet haben.

Viele Grüße
Martin

Nachtrag:
Wegen eines gefundenen Hinweises auf CardBook in einem anderen Forums-Thread habe ich das AddOn aus Neugier mal installiert. Und siehe da, es funktioniert einwandfrei. Ich füge diesen Hinweis noch mal hinter dem ersten Posting an.... denn so ganz am Rande meiner Problemsucherei hatte ich auch mal auf der Frage rumgekaut, ob vielleicht auf meinem Server was nicht stimmt. Nun, ich denke, das kann ich jetzt ausschließen: Die Freigabe ist da und die Berechtigungen passen auch... CardBook kann lesen, schreiben und sync'd sich.

Es scheint also was mit dem Trio TB+Lightning+sogo nicht zu stimmen. Jetzt kann ich nicht einschätzen, ob CardBook eine langfristige Alternative ist oder obs besser nur ne vorübergehende Notlösung ist. Mit Lightning und sogo habe andersrum lange erfolgreiche Zeit "verbracht".

Hi Peter

Danke für Deine Antwort. In der Zwischenzeit habe ich ein bisschen gespielt... Änderungen in den Daten auf den Android-Clients, Änderungen in den Daten auf den Jessie-Clients.... alles funktioniert. Ganz egal, wo man reinschaut, die Daten passen. Das sieht also mit CardBook richtig gut aus. Wobei mich die Vielzahl der möglichen Felder noch verwirrt... ich weiss nicht, ob die Android-Clients damit klarkommen und ob Baikal auf dem Server (die "Cloud") das verpackt. Ich kann mir nicht so recht vorstellen, dass die 3 Mitspieler (CardBook + Baikal-Datenbank + Android-Adressbücher) tatsächlich die gleiche Datensatz-Struktur verwenden.

Nun ja, egal... aber was mir jetzt noch wichtig ist, ist die Frage mit Lightning und sogo. Gibt es für sogo und den Terminkalender vielleicht auch eine gute Alternative, ähnlich wie CardBook für das sogo-Remote-Adressbuch? Wenn sogo solche Probleme hat, wäre es vielleicht nicht das schlechteste, es gar nicht mehr zu verwenden.

*hmmm*.... radicale.... klingt interessant... hast Du Dich einmal mit nginx und baikal beschäftigt? Kannst Du vielleicht mit 1-2 Sätzen ein paar markante Unterschiede nennen, warum radicale vielleicht besser für den Sync zwischen den Androids und Thunderbird geeignet ist? Da würde ich mich sehr drüber freuen.... vielleicht steige ich dann auch um.

Mein Pi's hat also schon größere Aufgaben, und synchronisierte Rechner (über Adressbuch und Terminkalender hinaus) gibts bei uns nicht. Bei uns sind alle Rechner im eigentlichen Sinne "persönliche" Rechner. Das heisst, jeder hat seine eigene Maschine(n). Die Besonderheit ist, dass es auf keinem einzigen Rechner lokale Daten gibt. Wirklich alles läuft über den PI, der mit 2 fetten Platten das gesamte Tagesgeschäft handelt, einschließlich der notwendigen automatischen Backups. Und da die mobilen Rechner sich des PI als VPN-Gateway zum Surfen bedienen und darüber hinaus als Gateway ins heimische Netz gehen, ist ein Daten-Sync nicht notwendig. Wenn notwendig verwenden die mobilen Geräte immer direkt die originalen Daten auf dem Server. Das klappt seit etlichen Jahren bestens, jetzt mit Linux noch viel besser als zuvor mit MS.

An dem werde ich also nichts ändern. Aber nginx und baikal... da würde ich gerne über eine Änderung nachdenken. Weil ich nginx ansonsten nicht verwende, schien mir das bei manchen Überlegungen auch schon mal ein wenig oversized. Und wenn das gleiche mit weniger Einsatz erreicht werden kann, wäre das eine echte Verbesserung.

Moin

Zitat von SusiTux

Zur nginx:
Bei uns läuft ein Apache. Das ist für so einen kleinen Kerl wie den Pi doch ein ordentlicher Brocken. Habt ihr Vergleichswerte Apache/nginx? Ist die Systemauslastung (vor allem des RAM) mit der nginx spürbar geringer?

Ja, Apache hatte ich damals auch erwogen, aber wieder verworfen, weils zu ressourcen-hungrig ist. Schon damals lief nginx auf dem alten Pi Mod. B+, und jetzt ebenso auf dem Pi 2. Und jetzt auf dem Pi 2 empfinde ich die Services als nicht weniger effektiv, als viel früher zu Zeiten meines fetten Windows-Servers. Der Pi ist heute bei uns File-Server, Server für die Postfächer, Print-Server, VPN-Gateway ins heimische Netz, VPN-Server für sicheres Surfen von den Mobil-Geräten, Backup-System, Cloud-Server für die Android- und Thunderbird-Clients. Selbst als Server für Multimedia-Files (nicht streamen, nur zur Verfügung stellen) kommt er locker mit mehreren gleichzeitigen Clients klar. Ich habe mir gerade mal den Thunderbird-Sync von meinem PC aus via SSH auf dem PI angesehen.... lächerlich... samba geht kurz hoch, nginx + python und dann isser fertig, keine 5 Sekunden. Wir nutzen Nginx nur für Baikal und die Syncs für alle Familienmitglieder und ich bemerke überhaupt keine Systembelastung.

Zitat von SusiTux

Habt ihr dazu Erfahrung mit nginx? Lässt sich die Authentifizierung (Radicale, Wordpress, eigene Webapps) darüber einfacher einrichten?

Kein Ahnung... bei mir gibts nur Linux-Authentifizierung, dann noch für Samba und für Baikal, immer gleicher User-Name und gleiches PWD. Viel Arbeit war das eigentlich nicht.

Zitat von SusiTux

Zum zentralen Homeserver:

Die Idee, sämtliche Homeverzeichnisse zentral zu haben, klingt verlockend. Das hat ja schon fast etwas von einem Thin-Client, obwohl in diesem Fall die Clients viel leistungsfähiger sind als der Server, also eher ein Fat-Client.

Nun ist es beim RasPi (zumindest bei meinem alten Modell B) so, dass sich Netzwerk und die USB-Ports denselben Bus teilen. Somit lässt sich maximal die halbe Datenrate von USB 2.0 erreichen. Das sind dann ca. 240 MBit/s bzw. 30 MB/s brutto, für alle Benutzer zusammen. Das ist nicht gerade üppig im Vergleich zum GBit-LAN oder gar einer lokalen SSD mit ca. 4000 MBit/s (lesend), pro Benutzer.

Aber das ist bei uns eben konzeptionell gelöst... es wird ja nix kopiert... es bleibt ja alles auf den Platten des Pi. Insofern fällt die fehlende Übertragungsgeschwindigkeit im Tagesgeschäft überhaupt nicht auf. Und alles was normale Anwenderdaten sind, LO-Dokumente, Datenbankzugriffe, Fotos gucken, Musik hören, Film gucken, etc. funktioniert ohne empfundene Beeinträchtigung. Selbst Downloads werden nicht lokal gespeichert, sondern landen direkt auf der Server-Platte. Ich habe in meinem Quad-Core-Rechner eine 500 GB-Platte eingebaut, davon werden exakt 5,2 GB (*) für alles" verwendet. Die auf dem PI laufenden Backup-Jobs brauchen natürlich länger, aber die laufen etwa 10 mal im Monat verteilt und starten um 4 Uhr morgens. Bis 6 Uhr, wenn einer aufsteht und auf die Idee käme, aufs Handy zu gucken, sind die allesamt fertig. Und falls ich wirklich mal was im GB-Bereich kopieren will, starte ich das abends auf dem Server im "screen"-Terminal und beende das Terminal am nächsten Tag... ist mir ehrlich gesagt egal, wie lange der braucht, ob 10 Minuten oder 10 Stunden für 100 GB... irgendwann isser fertig.... und das sind zudem seltene Ausnahmen, wenn ich bestimmte Verzeichnise 1 oder 2 mal im Jahr auf eine weitere 3-TB-Backupplatte kopiere, die im Regelfall ausgeschaltet ist... und den letzten Notausgang darstellt.

Zitat von SusiTux

Ein weiterer Nachteil eines solchen zentralen Konzeptes ist der, dass ausgerechnet der kleine 30-Euro-RasPi zum Single Point of Failure wird. Damit ist dann schnell mal die ganze Familie lahmgelegt. Wie gehst Du damit um? Hast Du einen zweiten, fertig konfigurierten Raspberry in der Schublade, sozusagen als LA-Failover?

Nein, natürlich nicht. Weil das auch nicht so einfach funktioniert. Auf meinem PI ist Jessie installiert, auf der SD-Card finden so gut wie keine Schreibzugriffe statt, ausser, wenn ich seltenst mal ein Upgrade mache. Selbst das Logging ist auf die Platte ausgelagert. Der läuft unberührt monatelang ohne Neustart einfach durch. Allerdings ist da auch kein Raspian-Image einschließlich des ganzen Mülls installiert, sondern nur ein nacktes Raspian Jessie und zwar ohne diese ganzen grafischen Programme. Darüber hinaus nur die für den Serverbetrieb notwendigen Komponenten. Ich habe noch nie einen Rechner zuhause "gefahren", der so stabil und wartungsarm läuft. Und wenn er stirbt, ist in 2 Stunden nen neues Debian auf ner neuen Karte installiert und ein anderer PI übernimmt den Job. Das Customizing auf dem neuen PI beansprucht keine große Zeit. Ich habe alles präzise dokumentiert und kann auf ein Restore-Drehbuch zurückgreifen plus einer Verzeichnis-Hierarchie für Conf-Files, die passend zum Drehbuch als Backup hinterlegt ist. Fakt ist, dass im 7/24-Betrieb der RasPi Modell 2 maximal zu 10 oder 15% des Tages ausgelastet ist. Das bedeutet, die Auslastung jeder anderen leistungsfähigeren Maschine ist noch mal deutlich geringer.... was für mich faktisch einem totalen wirtschaftlichen Unsinn ergibt. Mein Windows-Server hat damals zwischen 100 und 170 Watt verbraucht, im Schnitt immer deutlich über 100 Watt, mein Pi verbraucht jetzt 8 Watt komplett. Da nehme ich gerne in Kauf, dass ich gewisse Aufgaben einfach mit Verstand so einstellen muss, dass ich mich nicht übers Warten ärgere. Wichtig ist m.E. eben, die Lasten soweit es geht über den Tag zu verteilen, und das funktioniert prima, wenn man die System-Jobs ausserhalb des User-Fensters legt.

Zitat von Peter_Lehmann

Will meinen RasPi nicht totfahren und der dortige USB-Stick ist ja auch nicht gerade das zuverlässigste Speichermedium!

Zitat von SusiTux

Verständlich. Sofern es um Lesezugriffe geht, sind gute USB-Sticks durchaus robust und zum Videoschauen durchaus geeignet. Schwächster Punkt ist sicherlich die Speicherkarte im Raspberry.

Nun, das würde ich eben nicht machen.... Ich habe 2 dicke Platten dran mit eigener Stromversorgung, beide mit Sleep-Funktion, eine produktive, eine für die Backups. Journal und anderes Logging liegt auf der produktiven Platte. Die SD-Card wird m.E. eigentlich nur noch zum Lesen verwendet, und bei den seltenen Upgrades. Nand-Speicher im alltäglichen RW-Betrieb ist immer die schlechteste Wahl.

j.m.2.c.

(*) Wir nutzen natürlich auf keinem unserer Clients Windows, sondern nur noch Debian Jessie.... Windows ist für uns gottseidank (die unselige) Vergangenheit. Und seit dem Wechsel vor einigen Jahren läuft bei uns eigentlich alles genauso unkompliziert und stabil, wie derzeit unser Raspi als Server... einschließlich der alten Hardware, die unter Windows eigentlich hätte ausgemustert werden müssen.