ubuntuusers.de

Hi,

Problem: Kalendereinträge in Evolution werden nicht auf den CalDav-Server weitergegeben, also Eintragungen in Evolution gehen zwar auf den CalDav-Server, Evolution liest aber nichts von dort.

Ich habe dies hier studiert

https://wiki.ubuntuusers.de/Evolution/#Kalender

und alle Rechtevarianten durchprobiert ....

Problem: Kalenderdaten werden vom CalDAV-Server nicht akzeptiert. Fehlermeldung: "Keine Berechtigung" (wenn mit CalDAV-Kontodaten angemeldet)

Fehlermeldung: (wenn als bloßer Abonnent angemeldet)

"Ein Fehler trat im Kalender-Backend für »Kalender von info@dorober.it« auf.

Die Fehlermeldung war »Daten konnten nicht gesendet werden: HTTP-Fehlercode 500 (Internal Server Error): Sabre\DAV\Exception
  SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'event_title' at row 1
  1.8.12[exception][message][sabredav-version]«.

WebDAV KANN gar nicht funktionieren, weil von Evolution gar kein Passwort abgefragt wird, meine ich, funktioniert auch nicht.

Jemand 'ne Idee? Danke im Voraus!

dorober schrieb:

"Ein Fehler trat im Kalender-Backend für »Kalender von info@dorober.it« auf.

Die Fehlermeldung war »Daten konnten nicht gesendet werden: HTTP-Fehlercode 500 (Internal Server Error): Sabre\DAV\Exception
  SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'event_title' at row 1
  1.8.12[exception][message][sabredav-version]«.

Wie in der Fehlermeldung beschrieben hat das Problem nichts mit "evolution" zu tun. Der CalDAV Server meldet, dass seine Datenbank (wahrscheinlich DB2 unter AIX) ein Problem hat, Daten in das Feld "event_title" zu speichern. Dieses ist in der Datenbank auf dem Server kleiner definiert als die Anzahl der Zeichen, die dort schreiben willst ("The length of an exported field or facet value is longer than the length of the corresponding column in the database table").

Bei CalDAV wird eine .ics Datei (gemäß RFC5545) übertragen. Wahrscheinlich hast du beim SUMMARY Tag einen zu langen String für deinen CalDAV Server eingetragen. "Evolution" kommt damit klar, dein eingebundener CalDAV Server nicht.

Wenn du willst, können wir ins erweiterte "Soap" Debugging mit "evolution" einsteigen, doch denke ich, dass du mit einer vernünftigen Nutzung des Kalenders (kurzer SUMMARY Tag, ausführliche Informationen unter dem DESCRIPTION Tag) schneller zum Ziel kommen wirst.

Danke!

Ergänzung: Der CalDav-Server steht bei einem renommierten deutschen Internetprovider mit vielen Großkunden, deshalb denke ich, dass der Fehler doch bei mir liegt, also, dass die ihren Server schon korrekt konfiguriert haben?

Grundfrage: Welchen Art der dort angebotenen Authentifizierung sollte ich eigentlich wählen, mache das zum ersten Mal selbst. Mir geht es nur darum, dass meine stationären und meine mobilen Geräte sich syncen können.

"CalDAV-Abonnement" (ohne Passwort) oder "CalDAV-Konto" (mit Passwort) oder "WebDAV" ?

Danke, auch vorab! 😉

ps. Aus Datenschutzgründen wäre es mir am liebsten, die syncten sich untereinander und nicht über einen Server meines Internetproviders, aber das, das technisch Trivialste, können die Geräte wohl nicht?

pps. Mich hat der Fehler erst nach längerer Zeit gestört bzw. über Monate hatte ich keine Zeit, mich ausführlicher drum zu kümmern, deshalb ist die Suche nach DER Eintragung, die angeblich eine ungewöhnliche Länge aufweist, müßig ... bzw. mir nicht derzeit nicht möglich. Optimistisch macht mich aber, dass dieser eine oder mehrere "überlange" Eintrag wohl nicht die gesamte Synchronisation blockiert, obwohl die Meldung jedes Mal bei manuellem Anstoß zur Synchronisation auftaucht. Oder ?

Der CalDav-Server steht bei einem renommierten deutschen Internetprovider mit vielen Großkunden, deshalb denke ich, dass der Fehler doch bei mir liegt, also, dass die ihren Server schon korrekt konfiguriert haben?

Wie heißt denn der Internetprovider? Ich denke auch nicht, dass dieser seinen Server falsch konfiguriert hat. Ich habe nur versucht, dir zu erklären, warum der angeführte Fehler aufgetreten ist.

Eine relationale Datenbank verwendet Tabellen mit Spalten (Fields), in denen die Daten abgelegt und abgerufen werden können. Bei der Definition des Schemas dieser Tabelle legt man fest, welcher Datentyp in welcher Länge in diesem Feld abgelegt werden kann. Wenn man versucht, illegale Daten (z.B. zu lange Strings) abzuspeichern, liefert die Datenbank einen Fehler.

Grundfrage: Welchen Art der dort angebotenen Authentifizierung sollte ich eigentlich wählen, ... "CalDAV-Abonnement" (ohne Passwort) oder "CalDAV-Konto" (mit Passwort) oder "WebDAV" ?

Basierend auf der RFC5545 Spezifikation kann man unterschiedliche Elemente speichern.

• Kalender:VCALENDAR,

• Termine:VEVENT,

• Aufgaben: VTODO,

• Journaleinträge:VJOURNAL,

• Free/Busy-Zeiten:VFREEBUSY,

• Zeitzonen:VTIMEZONE,

• Benachrichtigungen:VALARM

So ein Element ist durch BEGIN/END Markierungen gruppiert. Heute würde man diese Aufgabe zwar über XML lösen doch vor etlichen Jahrzehnten hat man sich auf dieses Format geeinigt. Man kann entweder viele oder nur ein einzelnes Element (z.B. eine Besprechung) mit einem BEGIN/END Block in einer Datei speichern (.ics, .ical usw).

Damit auf diese abgelegten Informationen über das Netzwerk zugreifen kann, verwendet man das http Protokoll. Als Faustregel spricht man von "WebDAV", wenn eine (.ics) Datei mit vielen Element-Blöcken angesprochen wird. Nachteil ist, dass diese Speicherform nicht sehr änderungsfreundlich ist. Jede Änderung erfordert die Erstellung einer neuen (großen) Datei.

Bei CalDAV wird jedes Element in einer eigenen Datei abgelegt. Bei einer Änderung braucht nur die betroffene Datei erneuert werden. Natürlich sind diese "Dateien" heute nicht wirklich sequentielle Files im Filesystem sondern eher BLOB (Binary-Large-OBject) Felder in einer Datenbank. Wenn du dich dafür näher interessierst, wie diese Daten bei "evolution" in den Datenbanken abgelegt sind, können wir dies intensiver analysieren.

Wie bei jeder Webseite kann man dies mit und ohne Authentifizierung (d.h. auch unterschiedlichen Authentisierung-Arten) aufrufen. Wenn du private Informationen abspeichern willst, ist ein authentifizierter Zugriff zu empfehlen.

Ich kenne Evolution nicht, aber Client und DB sind doch anscheinend integrierte Bestandteile. Bei FF sind das ja immer "Plugins", wenn es Probleme gibt mit Syncro.

22.04 und Debian? Da könnte man doch flott mal den Flatpak Container testen.

Bugs zu Evolution gibt es im Kontext schon ... ☹

Äh ... Ja???

In den obigen Posts ging es doch um die CalDAV/WebCAL Kommunikation zum Anbieter des Kalenders. Ob man da "ThunderBird" oder "evolution" nutzt ist relativ egal. "Evolution" besteht aus mehreren Ebenen. Neben dem Client, den der User bedient, arbeiten im Hintergrund diverse Background-Prozesse (z.B. evolution-data-server, evolution-calendar-factory usw.). Die Hintergrund-Prozesse arbeiten teils mit flat-Files und Datenbanken. Die Kalenderdaten können dann in der Datenbank gecached sein. Da kann man dann sehr einfach sehen, wie WebCal ("Auf diesem Rechner") und CalDAV (.cache/evolution) ohne Netzwerk-Randbedingungen funktioniert.

Ich hatte den Eindruck, dass der Themenstarter mit den xxxDAV Themen nicht ganz so bewandert ist und habe ein paar Hintergrund-Informationen geben wollen. Wenn ich damit falsch lag, und hier zu viele Trivialitäten verbreitet habe, bitte ich das zu entschuldigen. Es ist für mich immer schwer festzustellen, welchen Allgemeinwissen der Teilnehmer hat und erkläre dann zu viel.

Da könnte man doch flott mal den Flatpak Container testen.

Kann man machen. Ich würde allerdings hiervon abraten, da mit der "Sandkasten"-Philosophie von "Flatpak" (ähnlich wie bei "snap") man sich das Thema sehr viel komplexer macht. Die Dateien und Datenbanken liegen woanders und können nicht so einfach wie bei der deb Installation gestoppt, gestartet oder gar angepasst werden (obwohl dies alles möglich ist).

Flatpak scheint bei Evolution alternativlos zu sein, wenn man eine neuere Version testen will.

Bei FF und TB kann man ja in so einem Fall nach Alternativen suchen, weil da solche Dinge oft über Fremdanbieter gelöst wird.

Ich kann es mir zumindest vorstellen, daß die Version in den Quellen "vermodert" ist.

Ubuntu Philosophie! ☹

Ich kann es mir zumindest vorstellen, dass die Version in den Quellen "vermodert" ist.

Na ja, Ubuntu macht einem das Leben nicht leicht. Aber so schlimm ist es auch nicht. Im Moment sind folgende Versionen von "evolution" bei den jeweiligen Ubuntu Versionen vorhanden:

Das geht eigentlich. Bei LTS ist man allerdings was die Aktualität der "evolution" Version angeht etwas gekniffen. Hier lohnt es sich eine "Flatpak" Version parallel zu installieren, falls man ein super neues Feature nutzen will. Man kann dann gleichzeitig 2 unterschiedliche "evolution" Versionen nebeneinander (deb und flatpak) auf dem Bildschirm nutzen.

Danke! Auch die 'allgemeinen Ausführungen' lese ich gern.

CalDav-Provider ist bei mir Hetzner. Die bieten das im Rahmen von deren Webmail an.

Ich habe gerade festgestellt, dass jedenfalls angehängte pdf eine noch großartigere Fehlermeldung erzeugen. (Hintergrund: Evolution bietet "Erzeugen-Termin-aus-Email" an und da hing dann durchaus sinnvoll auch ein pdf zur Veranstaltung dran. Das löste die besonders dunkelrote Fehlermeldung aus.)

Ich stelle gerade erst fest, dass auch das Abholen von anderen Terminen durch Evolution unterbleibt. Das sind Termine, die ich per iPhone als ics eingetragen habe ... kann das sein, weil ich jetzt nicht die WebDAV/ICS-Abonnement-Adresse nutze, sondern die CalDAV-Abonnement-Adresse?

Hab jetzt mal auf WebDAV/ICS-Abo umgestellt. Fehlermeldung:

Die Fehlermeldung war

Ein Fehler trat im Kalender-Backend für »Kalender von info@dorober.it« auf.
»Daten konnten nicht gesendet werden: HTTP-Fehlercode 409 (Conflict): Sabre\DAV\Exception\Conflict
  Files can only be created as children of collections
  1.8.12[exception][message][sabredav-version]«.

Das gab meiner Naivität, dass das CalDAV eine triviale, weil ernsthaft standardisierte Sache ist, den Rest. Naja, zwischen iPhone und Hetzner funktioniert ja alles, nur nicht zwischen Evolution und Hetzner. Das läuft bei denen unter Webmail:

https://docs.hetzner.com/de/konsoleh/account-management/email/webmail-faq/#wie-kann-ich-meine-kontakte-und-termine-synchronisieren

ps. Kein Problem gibt es auch bei Nutzung von Thunderbird .... 🙄 (Naja, WebDAV/ICS-Abo hab ich dort nicht hinbekommen.)

Da mein CalDAV-Server-Provider es problemlos mit iOS und Thunderbird kann, liegt der Fehler also bei Evolution.

Bin ich aber denn der einzige, der Evolution mit Kalendersync nutzt??

Bin ich aber denn der einzige, der Evolution mit Kalendersync nutzt??

Sicher nicht. Aber bei anderen funktioniert es halt.

Da mein CalDAV-Server-Provider es problemlos mit iOS und Thunderbird kann, liegt der Fehler also bei Evolution.

Dies ist sicher eine starke Aussage. Ob sie stimmt, müsste zunächst untersucht werden.

Da ich nicht weis, wie firm du im CalDAV Protokoll bist, hier eine sehr oberflächliche Beschreibung, die das von dir beobachtete Verhalten erklären kann:

Da CalDAV das http Protokoll verwendet, werden eine Reihe von Informationen im http Header transportiert. Hierbei werden zusätzliche http Request Definitionen (neben z.B. den bekannten GET und POST) verwendet. Den allgemeinen Aufbau kann man leicht in den RFC2616 und RFC4229 als Einstieg nachlesen.

Die Nutzdaten werden üblicherweise über das SOAP Protokoll übertragen. Hier sei auf die RFC3288 und RFC4227 verwiesen.

Der Verbindungsaufbau erfolgt in der Regel durch einen bzw mehrere OPTIONS Requests, die der Authentifizierung dienen und die unterstützten Header-Requests beschreiben. Dann kommen in der Regel PROPFIND Requests, mit denen die Berechtigung an den einzelnen Objekten abgefragt wird. Eine ganz wichtige Information, die hier abgefragt wird ist die CTAG-ID (getctag). Diese CTAG-ID kann man als Änderungs-Nummer des abgefragten Objekts verstehen. Ist die im Client vermerkte CTAG-ID größer oder gleich der, die der Server meldet, hat es keine Änderungen auf dem Server gegeben. Dies bedeutet, dass keine Änderungen vom Client abgefragt werden (brauchen). Ist die CTAG-ID, die der Server liefert größer als die auf dem Client gespeicherte, müssen vom Client die Änderungen abgefragt und lokal abgespeichert (eingepflegt) werden. Dies erfolgt über die Abfrage mit Hilfe des REPORT Headers und der ETAG-ID. Die relevanten ETAGs, die der Server liefert, können dann vom Client z.B. in Form von ics "Dateien" abgerufen werden. Natürlich ist das kein physikalischer Dateitransfer sondern XML im SOAP Kontext.

Wo jetzt bei dir das Problem besteht, lässt sich leicht ermitteln, indem du "evolution" im geeigneten Debug-Modus online betreibst. Hierzu definierst du Symbole, mit denen du bewirkst, dass interessante Debug-Informationen ausgegeben und z.B. in einer Datei gespeichert werden, damit du diese intensiv auswerten kannst. Für diese Auswertung lohnt es sich die relevanten RFCs nicht nur zu lesen sondern auch zu verstehen.

Als Ergebnis dieses Lernens wirst du in der Lage sein, zu verstehen, welche Kommunikations-Komponente gemäß RFC fehlerhaft oder zu lax arbeitet. Ein Beispiel für eine laxe, fehlerhafte Kommunikation ist bekannt bei der Synchronisation von iOS und Thunderbird. Hier werden die CTAG und ETAG Regeln teilweise missachtet und statt einer inkrementellen Synchronisation ein vollständiger Abgleich durchgeführt wodurch man zu dem Fehlschluss verleitet werden kann, dass eine Kommunikation zwischen iOS und TH funktioniert obwohl dies nicht der Fall ist.

Das Tracing der WebCAL Kommunikation überspringe ich hier, da du scheinbar eine CalDAV Kommunikation verwendest. Das Tracing der CalDAV Kommunikation kannst du wie folgt bewirken:

$ # Beenden der evolution Hintergrund-Prozesse
$ evolution --force-shutdown
$ # Starten des Hintergrund-Prozesses für den Kalender im CalDav Debug mode
$ CALDAV_DEBUG=1 /usr/libexec/evolution-calendar-factory -w >& ~/Downloads/caldav.log &
$ # Starten der evolution GUI Oberfläche und der restlichen Hintergrund-Prozesse
$ evolution
$ Nach Sychronisation des Kalenders wird die Session wieder beendet
$ evolution --force-shutdown
$ 

Der Logfile "~/Downloads/caldav.log" enthält die CalDAV Kommunikation zwischen "evolution" und deinem Kalender-Provider. Bitte untersuche ihn genau!

Bin ich aber denn der einzige, der Evolution mit Kalendersync nutzt??

Sicher nicht. Aber bei anderen funktioniert es halt.

Ich kann nur bestätigen, dass Evolution schon seit Jahren einwandfrei mit dem über CalDAV-eingebundenen Kalender meiner Schule zusammenarbeitet. Momentan habe ich das Flatpak Evolution 3.50.4 und Ubuntu 22.04.4.

Info: Ein Teilaspekt (Tracking durch Kontakt zum CalDAV-Server) wurde hierhin abgetrennt.

TobiasH schrieb:

Bin ich aber denn der einzige, der Evolution mit Kalendersync nutzt??

Sicher nicht. Aber bei anderen funktioniert es halt.

Ich kann nur bestätigen, dass Evolution schon seit Jahren einwandfrei mit dem über CalDAV-eingebundenen Kalender meiner Schule zusammenarbeitet. Momentan habe ich das Flatpak Evolution 3.50.4 und Ubuntu 22.04.4.

Danke für die Meldung, das macht Mut.

Funktionieren tut es bei mir nachwievor nicht.

Ich danke allen für die sachlichen, teils genialen Beiträge. 👍 Ich musste nun eh mal upgraden (auf 24.04 bzw. Evolution 3.52.3-0ubuntu1) und siehe da ... DAS Problem ist Vergangenheit.