Posts by smmmo

    Hallo,

    Quote from SusiTux

    Daraus schließe ich, dass es zuvor funktioniert hat. Die erste Frage lautet also: "Was hat sich verändert?" Hattest Du dieses Zertifikat zuvor auch schon in Benutzung?

    Hab ich gemacht, bin aber zu keinem Ergebnis gekommen, da ich nicht sagen kann, wie lang dieser Kalender schon nicht mehr funktioniert. Thunderbird wurde zwischenzeitlich möglicherweise über die Paket-Aktualisierung erneuert, ebenso nginx (der den Kalender über webdav ausliefert), das Zertifikat habe ich vor ner Weile auch mal verlängern müssen..


    Quote from SusiTux

    Zum Debugging:


    Wenn Du da einen Breakpoint gesetzt hast, sollte die Ausführung an dieser Stelle stoppen. Wenn der Debugger richtig funktioniert und die Ausführung an dieser Stelle nicht unterbrochen wird, dann hast Du nicht die richtige Stelle erwischt.
    Der Fehler selbst tritt übrigens nicht in Zeile 226 auf. Dort wird er nur geloggt. Wenn das überhaupt die richtige Stelle ist, dann wurde der Fehler bereits vorher festgestellt und zwar daran, dass in Zeile 219 der Wert von (Components.isSuccessCode(status)) den Fehler anzeigt. Wenn Du weiter debuggen willst, musst Du also die Stelle finden, an der dieser Wert gesetzt wird.

    Tja, nur wie finde ich dir richtige Stelle?
    Dass die Code-Zeile nur eine Log-Ausgabe ist, ist mir klar, das hatte ich schlecht formuliert. Daher ja meine Frage wer denn überhaupt die jeweiligen functions (s.o.) aufruft.. Ob der Debugger richtig funktioniert, kann ich nicht sagen, benutze ihn das 1. Mal..


    Aktueller Stand:
    -- ssl deaktiviert: Funktioniert über Chrome in neuem private Tab, aber nicht in Thunderbird
    -- htaccess deaktiviert: Funktioniert über Chrome ein neuem private Tab (ohne Username/PW-Abfrage) aber nicht in Thunderbird (jetzt mit https://james-ross.co.uk/mozilla/misc/nserror?0x804B000D)


    Workaround
    Zum Test habe ich die 3 Debian-Versionen stable, testing, unstable gegeneinander in VirtualBox antreten lassen und herausgefunden, dass der Kalender nur mit dem Icedove aus stable funktioniert.
    D.h. nach Downgrade auf die Icedove-Version aus Debian stable (1:45.2.0-1~deb8u1) funktioniert es wie gewünscht! :) Es scheint also definitiv an meiner Thunderbird-Version zu liegen (unter Windows hat der Kalender ja auch mit Thunderbird funktioniert).


    Gruß
    smo

    Hallo,


    ein neues Profil hatte ich schon versucht (siehe mein vorheriger Kommentar), hat nichts geholfen. Unter einem anderen Linux-User tritt das Problem ebenfalls auf..


    Leider kann ich kein JS, aber ich gebe mein Bestes.. ;-) Der Fehler tritt wie von dir vermutet in calICSCalendar.js in Zeile 226 auf (ich hatte den Kommentar dort mal testweise angepasst und dann diese Anpassung auch im log gesehen):


    Wann er hier reinläuft habe ich aber leider nicht verstanden. Wenn ich mit dem Addon "Tiny JavaScript Debugger" debugge, dann bleibt er an diesem Breakpoint nie stehen (an anderen schon).


    Wenn ich einen Refresh auf den Kalender auslöse, dann läuft er in "doRefresh: function calICSCalendar_doRefresh(aForce)". Dort fällt mir auf, dass this.mUri zwar die richtig URL enthält, aber kein "username" und "password". Ich habe auch nicht verstanden wo diese beiden Werte herkommen sollten.. :-(


    Viele Grüße
    smo

    Hallo,


    danke für die Antwort.


    Das Ergebnis von ssllabs sieht ok aus, oder? Unter "Certification Paths" tauchen die Zertifikate auf, wenn ich es richtig lese.


    Testweise habe ich gerade Thunderbird 45.3.0 unter Windows installiert, dort funktioniert der Zugriff per Webdav sofort (nach Einrichten per Wizard). Allerdings kommt dort eine Abfrage bezgl. Username/PW die ich unter Debian nicht (mehr) bekomme, auch nicht wenn ich ein neues Profil anlege. Wenn ich den Thunderbird-Passwort-Manager öffne, dann sind auch unter Debian keine Passwörter hinterlegt.


    Unter Debian bekomme ich ohne Import des Zertifikats diesen Fehler, was einem NS_ERROR_ABORT entspricht:

    Code
    1. [calICSCalendar] Unable to load stream - status: 2147500036

    Hm, was kann ich noch versuchen? Evtl. fehlt einfach nur die PW-Abfrage? Scheint fast so, also ob es nicht am Profil liegt, sondern irgendwo anders noch ein Setting nicht passt?


    Gruß
    smo

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
    * Thunderbird-Version: 45.2.0 (Icedove/Debian testing)
    * Lightning-Version: 4.7.2 (Iceowl/Debian testing)
    * Betriebssystem + Version: Debian testing
    * Eingesetzte Antivirensoftware: keine
    * Firewall (Betriebssystem-intern/Externe Software): keine


    Hallo,


    seit einigen Tagen kann ich einen ics-Kalender nicht mehr sehen. Auf dem ipad und Android-Phone funktioniert es wie bisher problemlos.


    Der Kalender ist auf meinem privaten Server hinterlegt und wird per webdav zugegriffen (mittels nginx). Das Ganze läuft ssl-verschlüsselt ab mit einem Zertifikat von letsencrypt.


    Ich habe zum Test bereits ein neues Profil angelegt. Danach musste ich mein ssl-Zertifikat in Thunderbird/Icedove in den Einstellungen importieren: Screenshot. Nun bekomme ich folgende Ausgabe (mit aktiviertem debug-logging):

    Code
    1. [calBackendLoader] Using libical backend at /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
    2. [calSleepMonitor] Starting sleep monitor.
    3. [calTimezoneService] Loading resource://calendar/timezones/zones.json
    4. [calTimezoneService] Timezones version 2.2016c loaded
    5. [calICSCalendar] Refreshing birthdaysSMO
    6. [calICSCalendar] Unable to load stream - status: 2153390060
    7. *** BUG ***
    8. In pixman_region32_reset: Malformed region region
    9. Set a breakpoint on '_pixman_log_error' to debug

    Der "status: 2153390060" bedeutet "SEC_ERROR_UNTRUSTED_ISSUER". D.h. das Zertifikat ist von einem nicht vertrauenswürdigem Aussteller? In meinem Fall ist das letsencrypt.


    Was kann ich tun, damit das Zertifikat akzeptiert wird? Oder bin ich auf dem Weg?


    Danke und Gruß
    smo