Kontakte- und Kalender-Synchronisation mit Baikal auf eigenem Webserver

Um Kontakte und Termine zwischen verschiedenen Endgeräten gleich zu halten, greifen viele Benutzer auf berühmte Cloud-Dienste, wie Apple iCloud oder die Google-Dienste, zurück.

Das mag sicherlich eine sehr komfortable Lösung sein – jedoch sollte man, meiner Meinung nach, offenen Cloud-Dienste kein großes Vertrauen schenken. Ich persönlich vermeide sämtliche Cloud-Dienste und versuche alle Dienste auf eigenen Servern zu implementieren.

BYOC (Bring your own cloud)

BYOC (Bring your own cloud)

Mithilfe der CardDAV– und CalDAV-Protokolle können Kontakte und Kalender synchronisiert werden. Es gibt zahlreiche quelloffene Server-Anwendungen, die diese Protokolle implementieren – darunter beispielsweise OwnCloud und Baikal. Während OwnCloud ein Rundum-Paket zur Erstellung einer privaten Cloud ist, bietet Baikal ausschließlich CardDAV-/CalDAV-Synchronisation an – genau das, was ich suchte.

CardDAV und CalDAV sind offene Standards, die von einer Vielzahl von Anwendungen und Geräten unterstützt werden, darunter beispielweise:

  • Apple iOS (Version 4 oder höher)
  • Apple iCal, Adressbook
  • Blackberry Geräte (Version 10 oder höher)
  • Evolution
  • Microsoft Outlook und Mozilla Thunderbird (jeweils mit Add-Ons)
  • Android mit CardDav-Sync (Free) / CalDav-Sync

Baikal steht in verschiedenen Versionen zur Verfügung – darunter:

  • Flat package – Installation per FTP, für verwaltete Webserver
  • Regular package – Installation per SSH oder FTP, für Root-Server/vServer
  • Bleeding-edge package – Installation per SSH und GIT, für Entwickler gedacht
Baikal-Dashboard

Baikal-Dashboard

Ich habe Baikal auf einem meiner Webserver installiert und mich für die erste Version entschieden, weil ich keinen SSH-Zugang auf diesem System habe.

Bei verwalteten Webservern kann es hier zu Problemen kommen – etwa, weil bestimmte Authentifizierungsmechanismen nicht zur Verfügung stehen oder „Eigenarten“ des Hosters beachtet werden müssen.

Ich musste bei meinem Hoster (All-Inkl) folgendes beachten:

Anpassung der ursprünglichen .htaccess-Datei

Vor der Installation musste ich die erstellte .htaccess-Datei um folgende Zeilen erweitern:

#Use PHP 5.3 and set some PHP flags
AddHandler php53-cgi .php
php_flag magic_quotes_gpc off
php_flag output_buffering   on

Die erste Code-Zeile zwingt den Webserver dazu PHP in der Version 5.3 zu verwenden – die Version ist für Baikal zwingend notwendig. Die anderen beiden Zeilen setzen zwei PHP-Einstellungswerte, die ebenfalls angepasst werden müssen, da ansonsten Authentifizierungsprobleme und andere Programmfehler entstehen.

Wird die .htaccess-Datei nicht angepasst, bricht das Installationsprogramm mit folgenden Fehlermeldungen ab:

Warning: Unexpected character in input: '' (ASCII=92) state=1 in ...
...
Warning: Unexpected character in input: '' (ASCII=92) state=1 in ...

Anpassung der Authentifizierung

Digest-Authentifizierung steht auf den meisten verwalteten Webservern nicht zur Verfügung, aber auch die Basic-Authentifizierung funktioniert – je nach Softwareumfang des verwalteten Webservers – nicht (in zahlreichen VMs hat das wunderbar funktioniert). Einige clevere Entwickler haben einen Workound hierfür programmiert: [klick mich!].

Der Ordnerpfade (in Schritt 7 und 8) haben sich in Baikal 0.26 wohl geändert:

  • baikal/Core/Frameworks/SabreDAV/lib/Sabre/DAV/Auth/Backend/ wird zu baikal/vendor/sabre/dav/lib/Sabre/DAV/Auth/Backend
  • baikal/Core/Frameworks/SabreDAV/lib/Sabre/HTTP/ wird zu baikal/vendor/sabre/dav/lib/Sabre/HTTP/

Der Workaround sollte auch bei der Verwendung anderer Hoster helfen – in meinem Fall half es auch bei meinem All-Inkl Web-Server.

Nach Anwendung des Workarounds muss in den Einstellungen von Baikal die Digest-Authentifizierung ausgewählt werden, da für diese im Quellcode entsprechende Zeilen zur Verwendung des Workaround-Moduls eingefügt wurden. Ein kleiner Schönheitsfehler, aber wen stört’s? 😉

Ersetzen der .htaccess-Konfigurationsdatei

Im verlinkten Artikel wird auch die .htaccess-Datei nochmals ersetzt, ich habe die Datei für meinen All-Inkl Web-Server wie folgt angepasst (o.g. PHP-Flags und Entfernung eines Redirects):

...

#PHP53, All-Inkl
AddHandler php53-cgi .php
php_flag magic_quotes_gpc off
php_flag output_buffering   on

# iOS
RedirectPermanent /.well-known/caldav http://servername.tld/cal.php
RedirectPermanent /.well-known/carddav http://servername.tld/card.php

Die letzten zwei Code-Zeilen definieren einen Redirect, damit Kontakte auch mit iOS-Geräten synchronisiert werden – iOS verwendet immer die Unterordner principals/benutzer zur Synchronisierung (der Ordnername lautet eigentlich addressbooks/benutzer)

Nach Anwendung dieser Tricks läuft Baikal einwandfrei auf meinem verwalteten Webserver.

Synchronisation unter Android

Für die Synchronisation von Kontakten mit Baikal unter Android kann ich CardDAV-Sync empfehlen. Diese App kostet 1,90 € – es existiert jedoch auch eine kostenfreie Version.

Zum Abgleich von Kalendern und ToDo-Listen (die zuvor in Baikal im Kalender aktiviert werden müssen) gibt es vom gleichen Entwickler die App CalDAV-Sync für 2,59 €. Es gibt keine kostenfreie Version dieser Anwendung – jedoch ist das Tool sein Geld auf jeden Fall wert, finde ich.

Die beiden Anwendungen ähneln sich sehr – es gibt einen Konfigurationsassistenten der entsprechende Systemkonten zur Synchronisierung anlegt. Hierbei muss das folgende URL-Schema verwendet werden (Beispiele):

  • Standard-Kalender, Benutzer max: http://servername.tld/baikal/cal.php/principals/max
  • Kalender mit der ID business, Benutzer paul: http://servername.tld/baikal/cal.php/principals/paul/business
  • Standard-Kontaktbuch, Benutzer john: http://servername.tld/baikal/card.php/addressbooks/john/default
  • Kontaktbuch mit der ID customers, Benutzer bill: http://servername.tld/baikal/card.php/addressbooks/bill/customers

Hinweis: Der Servername muss natürlich je nach Konfiguration (Servername, Subdomain, anderer Ordnername,…) angepasst werden!

Die beiden Programme gelten als Beta, funktionieren aber zuverlässig. Ich konnte keinerlei Datenverluste oder Abstürze feststellen. Jedoch empfiehlt der Entwickler, gelegentlich Backups der erstellen Kontakte zu pflegen.

Synchronisation mit iPhone, iPad und iPod

Während man die CardDAV- und CalDAV-Funktionalität bei Android kostenpflichtig nachrüsten muss, ist diese Funktion fester Bestandteil von Apple iOS (seit Version 4). Hier genügt die Hinzufügung eines entsprechenden Kontos im folgenden Menü:

Einstellungen > Mail, Kontakte, Kalender > Account hinzufügen > Andere > CardDAV-Account hinzufügen / CalDAV-Account hinzufügen

Hier ändert sich das URL-Format wie folgt:

  • Standard-Kalender, Benutzer max: servername.tld/baikal/cal.php/principals/max
  • Kalender mit der ID business, Benutzer paul: servername.tld/baikal/cal.php/principals/paul/business
  • Standard-Kontaktbuch, Benutzer john: servername.tld/baikal/card.php

Hinweis: Der Servername muss natürlich je nach Konfiguration (Servername, Subdomain, anderer Ordnername,…) angepasst werden – unbedingt sicherstellen, dass die .htaccess Konfigurationsdatei mit der oben erwähnten rewrite-Regel versehen wurde!

95 Kommentare Schreibe einen Kommentar

  1. Hat schon mal jemand versucht das Regular Packet zu entpacken, bei mir kommt da eine Fehlermeldunge, es sei kein tar Archiv. 🙁

    Bevor ich einen Bug berichte, wäre es schön ob jemand mal testen kann ob der Fehler evtl. bei mir liegt? Danke!

    • Hallo Erik,
      ich habe damit keine Probleme. Wie und womit entpackst Du das ganze denn?

      Der folgende Befehl entpackt das Paket unter Cygwin/Linux/UNIX:
      $ tar xvfz baikal-regular-*.tgz

      Beste Grüße,
      Christian.

  2. Pingback: OwnCloud auf einem verwalteten Webserver installieren | /var/pub/chris_blog

  3. Hi Christian,

    ohne SSL-Proxy musste ich mit Version 0.26 nur noch entpacken und eine entsprechende Subdomain einrichten, die auf das Verzeichnis html/ zeigt, schon gings.

    Allerdings will ich die Informationen eigentlich nicht unverschlüsselt transportieren und deshalb den SSL-Proxy verwenden. Wenn ich mich über den Proxy (also mit https://ssl-account.com/baikal.meinedomain.xy/admin) in die Admin-Oberfläche einlogge, dann werde ich auf die Seite ohne den Proxy umgeleitet – dass irgendwas nicht stimmt, sieht man schon daran, dass die Style Sheets gar nicht geladen werden. Und auch wenn ich eine neue Installation starte, in der von Anfang an der SSL-Proxy verwendet wird, werde ich umgeleitet.

    Bei owncloud gabs die Möglichkeit, in einer php-Datei die Konfiguration zu ändern ( http://doc.owncloud.org/server/5.0/admin_manual/configuration/configuration_reverseproxy.html ), aber bei baikal hab ich sowas bisher nicht gefunden.

    Weißt Du mehr?
    Danke schon einmal im Voraus!

    • Hallo Markus!

      Den Effekt habe ich bei meinem Server nicht – habe die Tage nochmals eine Installation mit und ohne Proxy durchgeführt und konnte das nicht nachvollziehen.

      Hast Du denn die Installation mithilfe des Proxys durchgeführt? Ich habe den Proxy von Anfang an verwendet und habe keine Probleme. Vielleicht wird beim Installieren die verwendete URL irgendwo gespeichert. Konnte in den Konfigurationsdateien zwar nichts derartiges finden, das muss aber nichts heißen.

      Beste Grüße und viel Erfolg,
      Christian.

  4. Hallo, habe meinen Server auch bei all-inkl. Bin genau nach Anleitung vorgegangen. Trotzdem wird mir „SabreDAVExceptionNotAuthenticated No basic authentication headers were found 1.8.6“ ausgeworfen und das Passwort zum Kalender link nicht akzeptiert. Das Webfaction Modul ist eingepflegt und Digest eingestellt. … 🙁 Danke, für jegliche Hilfe. Jan

    • Hallo timecrash!

      Die Dateien wurde auch exakt so editiert? Welchen Kalender-Link gibst Du denn ein? Beim Tippen auf dem Smartphone geht manchmal das ein oder andere Zeichen unter und so schleichen sich schnell Fehler ein – ging zumindest mir bei dem Projekt oft so. 😉

      Beste Grüße,
      Christian.

  5. hi christian, hi markus.

    habt ihr, bzw du markus, schon eine lösung für dein oben genanntest problem gefunden? ich stecke in der selben lage wie du.

    beste grüße

    • Hallo fero,

      ich kann das Problem bei meinem Server leider nicht nachstellen. Welchen Hosting-Tarif hast Du denn? Vielleicht variieren die Serverkonfigurationen ja je nach Tarif – ich habe eine älteren PrivatPlus Server.

      Beste Grüße,
      Christian.

  6. Moin!
    Hab alles nach Anweisung konfiguriert.
    Die Installation lief einwandfrei.
    Nur wenn ich z.B. das Adressbuch im emClient abrufen möchte. bekomme ich ein „Unauthorised“.
    Benutzer mehrmals gelöscht und neu angelegt, einfachste Passwörter das ich mich auch ja nicht verschreibe – kein Chance. Bin ebenfalls bei All-Inkl.

    • Hi Bosnigel!

      Hast Du das Problem auch bei anderen Clients? Welche URLs gibst Du an?
      Ist im Access-Log eventuell ein sachdienlicher Hinweis zu erkennen?

      Welches Webserver-Paket hast Du denn? Welche PHP-Version nutzt Du?

      Beste Grüße!

  7. Hi nochmal,
    sorry, dass ich länger nicht geantwortet habe. Ich dachte, ich bekomme eine Mail, wenn es eine Antwort gibt, aber das war nicht der Fall.

    Wie gesagt habe ich die Installation ebenfalls per SSL-Proxy gestartet, aber ich werde beim Aufruf der Installations-URL auf die unverschlüsselte Seite umgeleitet, sobald die Datei ENABLE_INSTALL erstellt ist. Diese Fehlermeldung sowie die Information, dass der Ordner Specific beschreibbar sein muss, bekomme ich allerdings noch unter der originalen URL (https://ssl-account.com/baikal.domain.de/).

    Ich habe das Paket baikal-regular-0.2.6.tar.gz direkt in mein webroot entpackt, dann den vhost (d.h. meine Subdomain) auf den Ordner baikal-regular/html gesetzt und anschließend die URL https://ssl-account.com/baikal.domain.de/ aufgerufen. Habe ich Specific/ beschreibbar gemacht und die Datei ENABLE_INSTALL erstellt, werde ich auf http://baikal.domain.de/ weitergeleitet.
    Im Quelltext sehe ich dann auch . Und das selbst dann, wenn ich manuell wieder auf https://ssl-account.com/baikal.domain.de/ zurück wechsle. Das ist wohl auch der Grund, warum die Styles fehlen.
    Achja, das mit der Weiterleitung passiert übrigens nur, wenn ich Deine .htaccess-Datei nicht erstelle (ich bin auf einem Server mit PHP 5.4 als Standard). Mit .htaccess (d.h. dem Handler-Eintrag) bekomme ich:
    1. Warning: session_start() [function.session-start]: open(/tmp/sess_f8ab900162034bf16252498f6407681f, O_RDWR) failed: Permission denied (13) in /www/htdocs//baikal-regular/Core/Frameworks/Flake/Framework.php on line 183
    2. Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at /www/htdocs//baikal-regular/Core/Frameworks/Flake/Framework.php:183) in /www/htdocs//baikal-regular/Core/Frameworks/Flake/Framework.php on line 183
    3. Warning: Cannot modify header information – headers already sent by (output started at /www/htdocs//baikal-regular/Core/Frameworks/Flake/Framework.php:183) in /www/htdocs//baikal-regular/Core/Frameworks/Flake/Controller/Page.php on line 75

    Und die dritte Warnung dürfte dann auch für die fehlende Weiterleitung verantwortlich sein…

    Eine Frage zum Schluss: Du hast unsicheres Nachladen ja blockiert, oder? Denn ich kann natürlich die Seite über SSL aufrufen und dann die unsicheren Inhalte zulassen (d.h. das Nachladen über die base-Adresse), dann funktioniert es auch – aber eben nicht verschlüsselt.

  8. Ok, Sachen in spitzen Klammern werden offensichtlich ausgefiltert 🙂
    Es sollte da stehen „Im Quelltext sehe ich dann auch SPITZEKLAMMER base href=“http://baikal.xxx.xx/“ SPITZEKLAMMER“ und in den ganzen Pfadangaben zu den Dateien (bei den Warnings) gehört zwischen die zwei Slashes meine Benutzerkennung…

    • Hi Markus!

      Ich habe ein entsprechendes Plugin installiert, damit man jetzt auch per Mail über neue Kommentare informiert wird. Vielen Dank für diese Anregung!

      Sorry für meine verspätete Antwort, aber ich hatte einiges um die Ohren und wollte mir die Zeit nehmen, das nochmal nachzustellen.

      Habe diese Probleme bei meinem Server so nicht – im Zusammenhang mit der von Dir auch genannten Fehlermeldung Cannot send session cache limiter bin ich auf folgende Webseite gestoßen: https://github.com/jeromeschneider/Baikal/issues/98

      Dort wird auf die PHP-Konfigurationen magic_quotes_gpc = off und output_buffering = on verwiesen – diese hatte ich in meinem „Trick“ ja auch entsprechend gesetzt. Hast Du diese Anpassung bei Dir auch vorgenommen?

      Beste Grüße,
      Christian!

  9. (Zitat aus einer E-Mail nach Genehmigung des Autors!)

    Hallo Christian,

    Die zwei PHP-Flags habe ich gesetzt, den Handler aber nicht, da ich wie gesagt auf einem Server mit PHP 5.4 bin. Es wundert mich sehr, dass der SSL-Proxy bei Dir ohne Änderungen funktioniert, eigentlich kann er das nämlich gar nicht. Ich habe mir den Quellcode angeschaut (insbesondere an der Stelle, an der die Base-Url ermittelt wird) und festgestellt, dass entsprechende HTTP-X-Forwarded-Felder im $_SERVER-Array gar nicht berücksichtigt werden. Flake (das Framework hinter Baikal) nimmt nur HTTP_HOST zur Erstellung der Base-URL bzw. PROJECT_URI. (Falls Dich die Stelle interessiert: baikal-regular/Core/Frameworks/Flake/Framework.php, ab ca. Zeile 166)

    Ich habe deshalb zwei Änderungen vorgenommen:

    in baikal-regular/Core/Frameworks/Flake/Util/Tools.php ab Zeile 34

    public static function getCurrentProtocol() {
    if((!empty($GLOBALS[„_SERVER“][„HTTPS“]) && $GLOBALS[„_SERVER“][‚HTTPS‘] !== ‚off‘)
    || intval($_SERVER[‚SERVER_PORT‘]) === 443
    || (!empty($_SERVER[‚HTTP_X_FORWARDED_PROTO‘]) && $_SERVER[‚HTTP_X_FORWARDED_PROTO‘] === ‚https‘ )) {
    return „https“;
    }
    return „http“;
    }

    und in baikal-regular/Core/Frameworks/Flake/Framework.php, ab ca. Zeile 166

    if(!empty($_SERVER[„HTTP_X_FORWARDED_HOST“])){
    define(„PROJECT_URI“, $sProtocol . „://“ .$_SERVER[„HTTP_X_FORWARDED_HOST“]. ‚/‘ . $_SERVER[„HTTP_HOST“] . $sHttpBaseUrl); } else {
    define(„PROJECT_URI“, $sProtocol . „://“ . $_SERVER[„HTTP_HOST“] . $sHttpBaseUrl); }

    Damit kann ich schon einmal die Adresse https://ssl-account.com/baikal.MEINEDOMAIN.DE/admin/ aufrufen, und werde nicht weitergeleitet auf die unverschlüsselte Version. (Lasse ich den letzten Slash weg, findet die Weiterleitung allerdings schon noch statt, keine Ahnung warum).
    Das Problem ist bei mir dann noch, dass die Formular-Action für die Anmeldung als absoluter Pfad (/admin/) drinsteht. Ich will die Daten aber nicht an https://ssl-account.com/admin/ posten (was mit dem führenden Slash gefordert wird), sondern an https://ssl-account.com/baikal.MEINEDOMAIN.DE/admin/.

    Also habe ich noch in baikal-regular/Core/Frameworks/BaikalAdmin/Controller/Login.php die Zeile 35 so geändert:

    $sActionUrl = FlakeUtilTools::stripBeginSlash(FlakeUtilTools::getCurrentUrl());

    Damit entfernt er den führenden Slash und die Action-Url stimmt wieder. Anmeldung am Admin-Interface klappt dann genauso wie das Erstellen neuer User, Kalender, etc. Und die Synchronisierung eines Adressbuchs unverschlüsselt auch. Aber über den SSL-Proxy geht es nicht.

    Rufe ich die Adresse https://ssl-account.com/baikal.MEINEDOMAIN.DE/card.php/addressbooks/markus/default/ im Browser auf, kommt die „korrekte“ Fehlermeldung von Sabre:
    SabreDAVExceptionNotImplementedGET is only implemented on File objects1.8.6
    Mache ich das gleiche mit einem nicht existierenden Nutzer xy, kommt SabreDAVExceptionNotFoundPrincipal with name xy not found1.8.6

    Jetzt bin ich mit meinem Latein wirklich am Ende. Die Fehlermeldungen beweisen meines Erachtens, dass Sabre richtig aufgerufen wird, und dass es unverschlüsselt klappt, zeigt auch, dass das System grundsätzlich richtig eingerichtet ist.

    Hast Du noch irgendeine Idee?

    Viele Grüße, Markus

    • Hi Markus!

      Sorry für die späte Antwort. Habe gerade viel um die Ohren, daher dauert es immer etwas, bis ich antworten kann.

      Deine Erkenntnisse sind sehr interessant – es scheint ja wirklich ein Wunder zu sein, dass das bei mir läuft.
      Ich muss zu meiner Schande gestehen, dass ich mich noch nicht so intensiv mit den Interna von Baikal beschäftigt habe.

      Ich vermute, dass das in der Tat aber auch etwas mit den All-Inkl-Verträgen zu tun hat.
      Welches Webserver-Paket hast Du denn – und seit wann? Ich habe einen recht alten Webserver, weswegen ich auch die PHP-Tricks anwenden musste.

      Vielleicht kann man das ja dadurch eingrenzen und eine qualifizierte Support-Anfrage bei All-Inkl stellen.

      Ich werde das auch nochmal auf meinem Server nachstellen – hab aber bitte Verständnis, wenn meine Ergebnisse etwas auf sich warten lassen.
      Meine bessere Hälfte verfügt auch über ein Webhosting-Paket bei All-Inkl – allerdings ein wesentlich neueres, vielleicht kann ich dort deinen Fehler nachstellen.

      Beste Grüße,
      Christian.

  10. Hallo,

    seit etwa zwei Wochen versuche ich Baikal zum Funktionieren zu überreden – keine Chance. Egal, was ich einstelle, ständig wird diese Fehlermeldung geworfen: „Incorrect username“ Username und Passwort SIND korrekt: curl -so – –digest –user test:test123 http://kalender.domain.tld/cal.php/calendars/test/default.
    Ich habe auch schon alle Möglichkeiten der .htaccess, die Google mir so geliefert hat, erfolglos ausprobiert.
    Leider antwortet der Autor der Software überhaupt nicht.

    • Und Du bist sicher, dass Du bei der Installation auch wirklich digest ausgewählt hast? Es gibt die beiden Möglichkeiten digest und basic und letztere muss man explizit auswählen, wenn ich mich recht erinnere, aber möglich wärs ja…

  11. Die Authentifizierung über Digest wurde aktiviert.
    Inzwischen habe ich Baikal durch DaviCal ersetzt und jetzt funktioniert die Sache endlich.

    • Hallo Juergen!

      Danke für die Empfehlung, DaviCal war mir bisher nicht bekannt.

      Auf welchen Geräten setzt Du das ein? Bist Du zufrieden mit der Lösung?

      Beste Grüße,
      Christian.

  12. Hallo Christian,
    über Davical kann ich nicht klagen – ich hätte schon vorher draufkommen können :-/. Es setzt auf PostgreSQL auf und nutzt Stored Procedures, was es sehr flott macht. Ich habe es auf meinem FreeBSD-Router installiert und so lassen sich alle Tablets, Notebooks und SmartPhones synchronisieren. Ich selber bastle gerade an eine Lösung, die Davical-Daten mit meiner Webpräsenz zu synchronisieren.
    Grüßle
    Juergen

    • Hallo Juergen,

      das klingt sehr interessant! Für gehostete Webserver ist leider aufgrund der Abhängigkeit zu PostgreSQL nicht immer geeignet – die meisten verwalteten Webserver nutzen ja MySQL.

      Ich bin mal gespannt, wie Du die Synchronisation implementierst – berichtest Du darüber? Für welchen Zweck wirst Du die Synchornisation nutzen? Um auf deiner Webseite eingepflegte Events direkt in den Kalender zu synchroniseren?

      Beste Grüße!

      • Zitat: „Ich bin mal gespannt, wie Du die Synchronisation implementierst – berichtest Du darüber? Für welchen Zweck wirst Du die Synchornisation nutzen? Um auf deiner Webseite eingepflegte Events direkt in den Kalender zu synchroniseren?“
        Ja genau.
        Über die Synchronisation werde ich auf meiner Webseite berichten.

  13. Das Problem mit DaviCal ist allerdings, dass man dafür meines Wissens PostgreSQL braucht, und das gibt es bei vielen Webhostern nicht. Aber wenn es für Dich funktioniert, warum nicht.

    Ich habe auch nochmal weitergesucht, und so langsam komme ich der Sache auf den Grund. Meine obigen Änderungsvorschläge für Baikal, d.h. an PROJECT_URI sind notwendig, um auch mit SSL-Proxy ins Admininterface zu kommen – aber nicht ausreichend.

    SabreDAV hat nämlich selbst auch ein Problem mit Reverse Proxies, siehe auch hier: http://code.google.com/p/sabredav/issues/detail?id=61

    SabreDAV wird mit PROJECT_BASEURI (!= PROJECT_URI für die Administration) gefüttert. Da steht aber auch beim Einsatz von Reverse-Proxies nur der Teil nach der eigentlichen Domain drin, meistens also nur ein schlichtes „/“ – denn SabreDAV prüft nur den RequestUri und da findet sich der Proxy ja nicht drin. Ändert man die PROJECT_BASEURI auf „/meine.baikal.domain/“, dann kommt allerdings beim Zugriff auf cal.php oder card.php, dass „/cal.php“ nicht Teil von „/meine.baikal.domain/cal.php“ ist. Ist auch klar, wenn SabreDAV nur den RequestUri verwendet.

    Quintessenz ist also:
    1. Entweder ähnlich wie im obigen Link schon angesprochen, die HTTPRequest-Klasse so ändern, dass bei Existenz von X-Forwarded-Host o.ä. der RequestUri geändert wird oder
    2. das $_SERVER-Array zu modifizieren, bevor der SabreDAV-Server erstellt und seine Methoden ausgeführt werden.

    Wenn ich die Änderungen getestet habe, werde ich mich nochmal melden…

    • Hi Markus,

      wow – klasse Arbeit, die Du da geleistet hast. Ich bin echt gespannt, ob deine Tests erfolgreich sind.

      Wäre natürlich super wenn das auch in den offiziellen Quellcode des Projekts einfließen würde. 🙂

      Beste Grüße und viel Erfolg,
      Christian.

  14. So, kleines Update:
    Variante 2 habe ich nun getestet und es funktioniert bisher. Ich werde es die nächste Woche mal beobachten – treten Fehler auf, melde ich mich nochmal.

    Ich werde die Änderungen beim Autor von Baikal hinterlassen, vielleicht fügt er sie sein. Eigentlich gehören die meisten Änderungen zwar eher zu Sabre, aber dort werden diese garantiert nicht eingepflegt werden – der Autor von Sabre hat die Verwendung eines SSL-Reverse-Proxy ja schon als Spezialfall bezeichnet

    „While in your case the url becomes /domainname/realurl, in other people’s cases this can be completely different.
    Because this is non-standard, this is obviously not something I can handle in SabreDAV.“

    Ein Hinweis noch zu den Änderungen: Variante 2 ändert das globale $_SERVER-Array! Wenn diese Informationen später noch gebraucht werden, sollte Variante 1 verwendet werden. Das heißt, eine neue Klasse von SabreHTTPRequest ableiten, darin den Konstruktor anpassen und dann eine Klasseninstanz dem httprequest-Member des SabreDAV-Server zuweisen.

    Die notwendigen Änderungen für SSL-Proxy hier in der Übersicht:

    1. Für die Adminoberfläche entsprechend der Mail bzw. dem Post vom 11.01.
    http://blog.christian-stankowic.de/?p=5609&cpage=1#comment-17925
    (Hinweis: Das Problem mit der Weiterleitung auf die unterschlüsselte Variante bei fehlendem Slash habe ich noch nicht behoben, aber irgendwie sieht mir das nach einem unpassenden Apache-Verhalten aus.)

    2. Für den eigentlichen Datenabruf,
    a) in Core/Frameworks/Flake/Framework.php: Zeile 160 (define(„PROJECT_BASEURI“, self::prependSlash($sBaseUrl));)

    ersetzen mit

    if(!empty($_SERVER[„HTTP_X_FORWARDED_HOST“])){
    define(„PROJECT_BASEURI“, „/“.$_SERVER[„HTTP_HOST“].self::prependSlash($sBaseUrl)); # SabreDAV needs a „/“ at the beginning of BASEURL
    }
    else{
    define(„PROJECT_BASEURI“, self::prependSlash($sBaseUrl)); # SabreDAV needs a „/“ at the beginning of BASEURL
    }

    b) in html/cal.php und html/card.php jeweils vor der Zeile 65 bzw. 66, in der der Server erzeugt wird ($server = new SabreDAVServer($nodes);) das Server-Array ändern lassen, wenn HTTP-X-Forwarded-Host gesetzt ist:
    if( !empty($_SERVER[„HTTP_X_FORWARDED_HOST“]) && isset($_SERVER[‚HTTP_HOST‘]) ) {
    $_SERVER[‚REQUEST_URI‘] = ‚/‘.$_SERVER[‚HTTP_HOST‘].$_SERVER[‚REQUEST_URI‘];
    }

    Gruß, Markus

  15. Hallo,
    ich auch, finde die Grundidee von Baikal einfach genial. Ich suche schon eit Monaten nach einer solchen Lösung. Weg von Google, aber schnell und efizient.
    Da ich zuhause noch keinen Server betreibe suchte ich nach einer Möglichkeit dies im Web auf einem Free Webspace zu machen.
    Wichtig war mir :
    von Überall per Thunderbird Termine zu verwalten die in Sekunden schnelle auf alle Handys meiner Familie verteilt werden.
    Da fand ich Baikal.
    Aber ….
    es läuft nicht überall.
    Ich hatte da meine Schwierigkeiten und ich wollte nicht in irgendwelchen php srippten rumfrickeln. Das ist meiner Meinung Sache des Entwicklers.
    Daher habe ich verschiedene FreeWebSpaces ausproprobiert mit der Grundkonfiguration von Baikal.
    Und siehe da ….
    Auf http://www.cwcity.de mit Account über zb. http://www.meinname.cwsurf.de/baikal/...
    lief es nicht. Ich habe alles mögliche ausprobiert. Das admin login und das administrieren funktioniert einwandfrei, nur auf die Kalender kann man nicht zugreifen.
    Dann , 2ter Versuch : http://www.blaced.de auch ein free Webspace Hoster !
    Gleiche Installation, gleiche Konfiguration, …
    und es lief auf Anhieb !
    Ich habe im Admin Bereich nichts verändert.
    Der Austausch zwischen Thunderbird, Sunbird und Android Handy ist sau schnell.
    So hab ich mir das gewünscht.
    Nur ?
    Warum funktioniert es Webspace A und auf Webspace B nicht ?
    Ich bin Anwender und kein.php sripptler.
    liebe Grüße
    Thomas

    • Hallo Thomas!

      In aller Regel liegt es daran, dass die einzelnen Webhoster unterschiedliche PHP-Versionen und -Konfigurationen einsetzen. Je nach Angebot gibt es ggf. noch fehlende Module, die man (wie in meinem Post beschrieben) mit Workarounds kompensieren muss.

      Freut mich, dass Baikal auf deinem kostenfreien Webserver läuft! Vielleicht hilft das ja auch dem ein oder anderen hier. 🙂

      Beste Grüße,
      Christian!

  16. Hallo zusammen,

    heute hatte etwas Zeit, Baikal nochmals zu testen und den Output von curl genauer anzusehen. Da ist mir etwas aufgefallen: In Baikal selber ist als Realm „BaikalDAV“ eingestellt und nicht verändert worden. Wenn ich per curl auf meinen Kalender zugreife, bekomme ich einen Realm „BaikalDAV-1219“ angezeigt. Wo kommt denn der her?

  17. Hallo Christian,
    ich habe mich genau an deine Anleitung gehalten und auch den Workaround mit eingebaut. Mein Hoster ist auch all-inkl.com (Tarif PrivatPlus). Die Installation und die Einrichtung waren ein Kinderspiel, jedoch bekomme ich den Sync unter IOS und Thunderbird nicht zum laufen. Er bricht jedesmal mit falschem Login ab. Was habe ich noch übersehen.
    Im überigen Top Anleitung.

    Gruß
    Andre

  18. Hallo zusammen,

    Für diejenigen die es mit wenig Aufwand selber hosten möchten, wollte nur kurz beisteuern, dass ich baikal 0.2.7 mit apache 1.3.42-SSL auf einer Fritzbox 7390 seit 8 Monaten laufen habe. Läuft mit 5 Kalendern / 3 Kontaktlisten und 5 clients problemlos.

    Gruß Norbert

    • Hei Norbert,

      Über ein TUT oder HowTo würde ich mich freuen.
      Gerne an meine email-Adresse oder hier öffentlich für alle.
      vielen Dank,
      Gruß Thomas

    • kannst du dazu ein Tut erstellen, vor allem interessiert mich wie du die athentifizierung gemacht hast (vermutlich ist deine ssl implementierung der schlüssel)

      ich selber bekomme stets SabreDAVExceptionNotAuthenticated
      und kann mich trotz korrektem link, user und passwd nicht authentifizieren. Obgleich die Admin oberfläche super läuft.

      • Hallo Jens,
        derzeit fehlt mir dazu leider die Zeit. Sobald es bei mir etwas besser aussieht, werde ich meine Anleitung nochmal mit der neuesten Baikal-Version überprüfen und Updates dokumentieren.

        Beste Grüße,
        Christian.

  19. Hallo Thomas,
    kann ich gerne machen. Allerdings müsste Christian damit einverstanden sein.
    Im Prinzip ist der Aufwand nicht mal so hoch, wenn rudimentäre LINUX-Kenntnisse vorhanden sind, überwiegend Telnet-Befehle und User-Rechte.
    – apache-ssl samt php 5.5.6 liegt für die FBn 7170/7270 und 7390/7490 fertig compiliert vor
    – baikal-flat ebenso
    – ansonsten braucht man nur einen USB-Stick im ext2 format… und eine Fritzbox

    Gruß Norbert

  20. Hallo Christian,
    es läuft jetzt bei mir. Hatte einen Fehler in der card.php und cal.php.Das einzige was jetzt noch fehlt ist die SSL Verschlüsselung. Gibt es da noch irgendwelche Neuerungen?
    @Norbert: Über eine Anleitung würde ich mich auch sehr freuen…

    Gruß
    Andre

  21. Hallo zusammen,

    ich bräuchte etwas hilfe.

    all-inkl.com
    MySQL 5.1.70
    PHP 5.3.18-nmm1

    Baikal 0.2.7

    Installation (Flat package) abgeschlossen, Patches wie in der Anleitung + Workaround + Digest.

    http://DOMAIN.de/baikal/cal.php/principals/USER
    – > HTTP 501 Nicht implementiert

    Mit Basic kommt wenigstens eine USER/Passwort Abfrage. User wird aber nicht akzeptiert. Fehler hier:


    SabreDAVExceptionNotAuthenticated
    No digest authentication headers were found
    1.8.7

    Funktioniert diese Anleitung mit 0.2.7 Baikal?

    htaccess hat alle Paches (php_flag und den code aus dem Workaround)

    Vielleicht kann mir jemand weiter helfen, Danke!

    Grüße Oli

    • Hallo Oli!

      sorry für die späte Antwort – ich hatte einiges um die Ohren.

      Oh, es gibt eine neue Version von Baikal? Danke für den Tipp, das wusste ich bisher noch nicht.

      Ich muss zugeben, mir fehlt gerade etwas die Zeit, das mit der neuen Version nachzustellen. Ich könnte mir jedoch gut vorstellen, dass sich hier einige Dinge signifikant getan haben. Leider finde ich auf der Webseite grade keinen Changelog – ich habe mal den Entwickler auf Twitter angeschrieben: [klick mich!]

      Mal schauen, ob der Entwickler sich meldet.

      Beste Grüße,
      Christian!

  22. Anleitung braucht noch 2-3 Tage, hatte viel um die Ohren. Wer Lust hat kann sich einmal diese Website unten anschauen. Da läuft ein Webkalender mit Anbindung an CalDAV (wie baikal). caldavzap habe ich ebenfalls auf meiner Fritzbox installiert.

    http://www.inf-it.com/caldavzap/

    Gruß Norbert

  23. Hi Oli,
    bei mir läuft es unter all-inkl jetzt ohne Probleme mit Baikal 0.2.7. Meine all-inkl Einstellungen:
    MySQL 5.1.73
    PHP 5.3.18
    Ich habe mich genau an die Anleitung gehalten, inkl. des Workounds. Kannst du mal deine .htaccess Datei posten?

    Andre

  24. hier meine .htaccess Datei:

    [code]
    AddHandler php53-cgi .php
    php_flag magic_quotes_gpc off
    php_flag output_buffering on

    RewriteEngine On
    # didn’t work
    # RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
    # actually works
    RewriteCond %{HTTP:Authorization} ^Basic.*
    RewriteRule ^(.*) $1?Authorization=%{HTTP:Authorization} [QSA,C]
    RequestHeader unset Authorization

    ExpiresActive Off

    # iOS
    RedirectPermanent /.well-known/caldav https://DOMAIN.de/cal.php
    RedirectPermanent /.well-known/carddav https://DOMAIN.de/card.php
    [/code]

  25. Hallöchen,

    es gibt noch einen Bug sowohl in cal.php (Zeile 58) als auch in card.php (Zeile 55):
    if( BAIKAL_DAV_AUTH_TYPE == „Basic“ || preg_match(‚/Windows-Phone-WebDAV-Client/i‘, $_SERVER[‚HTTP_USER_AGENT‘]) )

    Wenn der Ausdruck HTTP_USER_AGENT in $_SERVER[‚HTTP_USER_AGENT‘]) nicht definiert ist – manche Browser oder Clients machen das – dann knallt die Funktion preg_match.

    Daher durch dieses ersetzen:

    if (isset($_SERVER[‚HTTP_USER_AGENT‘])) {
    $s = $_SERVER[‚HTTP_USER_AGENT‘]);
    } else {
    $s = „“;
    if( BAIKAL_DAV_AUTH_TYPE == „Basic“ || preg_match(‚/Windows-Phone-WebDAV-Client/i‘, $s ) […]

  26. baikal habe ich zwar auf meinem HostEurope-Account zum Laufen bekommen, und auch das iPhone akzeptiert den Account. Allerdings lässt mich der iPhone-Kalender keine neuen Termine erstellen – hat da einer eine Idee was ich falsch mache?
    Statt „principals“ in der Adresse verwende ich allerdings „calendars“.

  27. Hallo Christian,
    die Installation von baikal-flat hat auf meinem Apache Server im Verzeichnis /var/www fehlerfrei funktioniert und ich konnte per Thunderbird den Kalender nutzen.
    Jetzt würde ich gerne den Server im User-Verzeichnis unter /home/user/public_html installieren. Allerdings kann ich dann mit Thunderbird nicht auf meinen Kalender zugreifen. Den Caldav-Link im Browser eingetragen führt zur folgenden Fehlermeldung:

    SabreDAVExceptionForbiddenRequested uri (/~user/test/baikal/baikal-flat/cal.php/calendars/test/test) is out of base uri (/public_html/test/baikal/baikal-flat/cal.php/)1.8.7

    Hast du vielleicht eine Idee?
    Vielen Dank!
    -max

    • Hi max!

      Hast Du eine Neuinstallation unterhalb des public_html-Ordners vorgenommen oder deine bereits vorhandene Installation dorthin verschoben?
      Die Fehlermeldung lässt auf letzteres schließen – ich vermute mal, dass im Rahmen der Installation irgendwo die Base-URI der Anwendung gespeichert wird und die stimmt nach dem Umzug natürlich nicht mehr.

      Gruß,
      Christian!

      • Hallo Christian,

        in beiden Verzeichnissen habe ich jeweils eine Neuinstallation durchgeführt. Zuerst unter public_html, später dann unter /var/www.
        Meine Systemeinstellungen lauten:
        – CalDAV base URI: PROJECT_BASEURI . „cal.php/“
        – Path to SabreDAV: PROJECT_PATH_FRAMEWORKS . „SabreDAV/lib/Sabre/“

        Muss hier manuell noch etwas angepasst werden? Bei der Installation habe ich nur das admin Passwort gesetzt und alles andere unverändert gelassen.

        Könnte es ev. mit der Weiterleitung zu tun haben, die ich von http://ip-adresse zu http://ip-adresse/~user über die index.html in /var/www eingerichtet habe?

        Vielen Dank für deine Rückmeldung!
        -max

      • Hallo Max!

        Die von dir erwähnten Einstellungen sollten eigentlich stimmen – zumindest habe ich dort die selben Werte (und bei mir funktioniert es ja).

        Mit der Weiterleitung sollte das eigentlich nichts zu tun haben, ich glaube da stimmt mit dem Wert der BASE_URI etwas nicht. Diese zeigt ja in deinem letzten Quote auch auf ein anderes Verzeichnis, das nicht existiert. Versuche doch mal den Pfad fest einzutragen (~benutzer/test/baikal/baikal-flat) – das sollte funktionieren. 🙂

        Beste Grüße,
        Christian.

      • Hallo Christian,

        ich habe versucht, den Pfad fest einzutragen. In den System Settings steht jetzt unter CalDAV base URI:
        ~user/test/baikal/baikal-flat . „cal.php/“

        Den Caldav-Link im Browser eingetragen führt nun zu folgender Fehlermeldung:
        SabreDAVExceptionForbidden Requested uri (/~user/test/baikal/baikal-flat/cal.php/calendars/test/test) is out of base uri (0cal.php/) 1.8.7

        Viele Grüße,
        -max

  28. so,… hab das ganze nun auch mal probiert und stoße direkt zu beginn auf einen Fehler -.-

    eine .htaccess habe ich nich im baikal Paket. Nein, auch nicht, wenn ich die versteckten Dateien anzeige 🙂 Bin ebenfalls bei all-inkl kunde und das hier war bisher meine Herangehensweise:

    1) baikal ftp paket geladen
    2) unterordnet auf webserver erstelle (/baikal)
    3) im all inkl KAS eine subdomain angelegt und auf den /baikal ordnet verlinkt
    4) zip Datei per webftp in den ordner geworfen und entpacken lassen
    5) meine angelegte subdomain aufgerufen

    Dann ballert mir eine Fehlermeldung ins Gesicht, die da lautet:

    ###
    Error – Insufficient permissions on the Specific/ folder
    In order to work properly, Baïkal needs to have write permissions in the Specific/ folder.
    ###

    wasdalos? ;(

    • Hi desy!

      Da fehlen augenscheinlich Schreibrechte im besagten Specific-Ordner. Dort müssen die Berechtigungen „755“ vergeben sein, ist das bei Dir ebenfalls der Fall?

      Beste Grüße,
      Christian.

  29. Hallo zusammen,

    hat jemand baikal unter all-inkl mit https proxy am laufen und hat eine detaillierte Anleitung?

    –lgerd

  30. Ich habe es mit der Anleitung von Markus leider auch nicht per SSL-Proxy zum Laufen bekommen. Gibt es vielleicht ein aktuelles Tutorial für den All-Inkl. SSL Proxy?

    • Kleiner Nachtrag:
      Es wäre super wenn die Erkenntnisse aus den Kommentaren in den Artikel übernommen werden könnte oder ein Update Artikel erscheinen würde, im moment komme ich in den Kommentaren immer wieder durcheinander. Das wäre super!

      • Hallo Sascha,
        das ist eine sehr gute Idee. Leider fehlt mir derzeit die Zeit, um einen solchen Artikel zu pflegen.
        Wenn ich ein wenig mehr Luft habe, werde ich meine Anleitung nochmal mit der neuesten Version testen und Updates dokumentieren.

        Beste Grüße,
        Christian!

  31. Hallo miteinander,

    ein wirklich sehr interessanter Beitrag mit sehr interessanten Kommentaren! Ich würde auf meinem Webspace von all-inkl.com ebenfalls gerne Baikal mit SSL-Proxy einsetzen, kriege es aber leider nicht zum Laufen.
    Würde sich vielleicht doch noch jemand erbarmen, eine idiotensichere Schritt-für-Schritt-Anleitung für totale Laien zu basteln, wie man die aktuelle Baikal Version 0.2.7 mit SSL bei ALL-INKL zum Laufen kriegt? Das wäre echt suuuuper! :))

    Beste Grüße
    Jay

  32. Kann mich jemand drüber aufklären, was es mit dem ssl-proxy auf sich hat? – Ich würde baikal gern auf meinem bei one.com beheimateten Server einrichten, aber ohne https-Zugriff läuft die Idee des Datenschutzes ja etwas ins Leere….

    baikal scheint https ja nicht von Haus aus zu können – oder täusche ich mich? – Oje, wenn das Teil nur nicht so grottenschlecht (also eigentlich gar nicht) dokumentiert wäre – oder habe ich das Handbuch einfach übersehen?

    Dank und Grüße,
    herrdeh

    • Hallo Wolf!

      Der SSL-Proxy ist eine Funktion der (meisten) Web-Hoster. Baikal kann prinzipiell auch HTTPS – jedoch ist die Verwendung von SSL bei den meisten Webanbietern mit zusätzlichen Kosten für ein entsprechendes Zertifikat verbunden.
      Der SSL-Proxy ist eine „günstige“ Alternative. Über eine alternative URL oder eine Subdomain kann man dann ohne den Erwerb eines SSL-Zertifikats Anfragen auf die „ungeschützte“ Webseite auf dem eigenen Server weiterleiten.
      Das bedeutet konkret: man verwendet ein SSL-Zertifikat des Hosters mit – dieser leitet einfach die Anfragen einer bestimmten Subdomain auf die eigenen Webseite um.

      Baikal ist es prinzipiell egal, ob der Server HTTP oder HTTPS verwendet.

      Beste Grüße,
      Christian.

  33. Servus Christian,
    vielen Dank für den Hinweis, da sehe ich schon etwas klarer.
    Mein Anbieter (one.com) stellt ein ssl-Zertifikat zur Verfügung, ich kann auch https-Verbindungen auf meine Domain aufbauen.

    Wie ich das aber bei baikal für ssl/https-Zugriff konfiguriert kriege, bleibt mir weiter schleierhaft. Ist das Ding wirklich so schlecht dokumentiert, oder bin ich nur zu blöd, die endsprechenden Seiten zu finden?

    Sonntagsgrüße vom
    Wolf

  34. Baikal 0.2.7 läuft bei mir mit php 5.5.14 / fcgi / lighttpd problemlos. Allerdings auf einem root server mit eigener Domain und SSL-zertifikat, so daß /etc/baikal problemlos auf den Nutzer des lighttpd servers gesetzt werden konnte und auch keine Zertifikatprobleme bestehen.

  35. In den Monaten hat sich hier ja ganz schön was getan 🙂 Ich muss wohl auch mal updaten, mal schauen, ob meine Änderungen auch mit der jetzt aktuellen baikal-Version noch funktionieren. Für den Fall, dass ich es hinkriege, werde ich eine Anleitung schreiben. Versprochen! Die kannst Du, Christian, wenn Du möchtest, dann auch bei Dir in einen Artikel übernehmen.

    Übrigens läuft die Installation bei mir seit Januar in der damals aktuellen Version problemlos mit 4 Kalendern und 3 Adressbüchern anstandslos 🙂

    • Hi Markus!

      Ja, das stimmt – bei Baikal hat sich einiges getan. Leider fehlt mir aktuell die Zeit, mein hier dokumentiertes Vorgehen nochmals mit der neuen Version zu testen.

      Wenn Du hier etwas vorzeigbares hast, verlinke ich natürlich sehr gerne deine dokumentierten Schritte! 🙂

      Beste Grüße,
      Christian.

  36. Hi,

    also ich wäre nach wie vor sehr an einer idiotensicheren Schritt-für-Schritt-Anleitung interessiert, wie man Baikal auf einem all-inkl.com Webspace mit SSL-Proxy einrichtet… Es würde mich sehr freuen, dafür eine leicht verständliche Anleitung zu bekommen.

    Lg, bennji

  37. Hallo Zusammen

    Ich kriege die Baikal auch nicht gebacken. Die Installation und Konfiguration im Admin Panel funktioniert einwandfrei. Aber dann die Verbindung mit einem Kalender, keine Chance 🙁
    Die Logindaten werden nicht akzeptiert. Schade eigentlich, dass das Projekt so schlecht dokumentiert ist. Wenn jemand die Einstellungen für 0.2.7 zusammenfassen würde, wäre das echt cool.

  38. Danke für die Empfehlung.
    Ich bin nach einer Lösung, mit der drei Nutzer auf einen Familienkalender lesend und schreibend zugreifen können. Kann ich das hiermit realisieren?
    Grüße!

      • läuft so für mich,meiner Frau und meinem Sohn seit 6 Monaten mit 6 Kalendern einwabdfrei auf unseren Handys und jedem eingerichteten PC.
        Nur SSL hab ich nicht hinbekommen.
        Gruß Thomas

  39. Nachdem ich bis eben an der Installation gescheitert bin – was an der nicht vorhandenen .htaccess lag – habe ich es jetzt geschafft Baikal ans Laufen zu bringen. Allerdings klappt die Authentifizierung nicht richtig: ich muss mich bei jedem Aufruf der Seite neu anmelden und neue Benutzer kann ich auch nicht erzeugen.

    Leider klappt auch der Aufruf über den SSL-Proxy von all-inkl nicht wirklich: ich lande immer wieder auf der unverschlüsselten Seite von Baikal. Mache ich was falsch? Hat jemand Tipps?

  40. Ich dreh noch ab. Baikal läuft auf meinem all-inkl Account laut WebAdmin. Versuche ich jedoch im emClient z.B. den Kalender ein zu binden bekomme ich „unauthorised“.

    Gibt es evtl. einen Provider auf dem man Baikal ohne gezicke laufen lassen kann?

    Gruß
    Bosnigel

  41. Hallo,
    es sieht so aus, als wenn viele Leute daran interessiert sind ihren eigenen Cloud Server für Email, Kalender und Adressbuch, einzurichten.
    Es ist wirklich einfach einen mit OwnCloud oder Baikal einzurichten. Aber dennoch ist die Synchronisation mit Outlook ein Problem.
    Ich empfehle euch folgendes: ECO.
    Es ermöglicht die Synchronisation zwischen CardDAV und CalDAV Servern.
    Wenn ihr interessiert seid checkt doch einfach mal folgende Internetadresse:
    http://synchronisiere.blogspot.de/2014/09/wie-kann-ich-macosx-server-mit-outlook.html

    Viel Erfolg!

  42. Hallo,
    erstmal DANKE an Christian und auch an Markus für Eure Arbeit, nur dadurch habe ich den Kalender auf einem all-inkl account mit ssl-proxy an den Start bekommen.

    Die Änderungen von Markus hier in den Kommentaren funktionieren bei mir auch mit 0.27. Ich denke das Problem das viele hier mit der Anppassung des Codes haben werden ist die Kommentarformatierung des Apostrophs hier im Blog. Wenn Ihr alle Anführungszeichen im Code von Markus durch ein Apostroph (einfaches Anführungszeichen) ersetzt, sollte eigentlich alles funktionieren.

    Ich hoffe ich konnte auch jemandem helfen :),
    Carsten

  43. Es gibt auch DavDroid zum Syncronisieren für Android. Beinhaltet Kontakte und Kalender und funktioniert bei mir besser als die beiden genannten Apps.

  44. Danke für diesen aufschlussreichen Blogbeitrag zu diesem Thema! Damit konnte ich es auf Anhieb bei All-Inkl und meinem iPhone einrichten. Das hatte zuvor nicht funktioniert und ich tappte im Dunklen!

  45. Hallo Christian,
    hallo Baikal-Gemeinde,

    vielen Dank für die gute Anleitung, mit der Baikal gut installiert werden konnte. In den Fragen oben habe ich mein Problem leider nicht gefunden. Beim Aufrufen des Kalenders bzw. Users findet Baikal den User nicht und gibt die folgende Fehlermeldung aus (xyz steht für den angelegten user):

    SabreDAVExceptionNotFound Principal with name xyz not found 1.8.7

    Der Kalender lässt sich somit weder in IOS einpflegen noch über einen Webbrowser aufrufen. Ist hierzu schon eine Lösung bekannt, wie der User erfolgreich gefunden werden kann?

    Aufgerufen wurde wahlweise über:
    http://servername/kalender/cal.php/principals/xyz
    oder
    http://servername/kalender/cal.php/calendars/xyz

    Es lässt sich lediglich der Admin ansprechen:
    http://servername/kalender/admin/

    Der User wurde über den eingeloggten Admin angelegt. Über einen Tip, wie Baikal den User und seine Kalender finden und einbinden kann wäre ich dankbar.

    Die gleiche Fehlermeldung kommt übrigens auch, wenn man direkt mit den z.B. „Default“ genannten Kalender aufrufen will.

    http://servername/kalender/cal.php/calendars/xyz/default

    Vielen Dank schon einmal im Voraus
    Erri

    • Hallo Erri!

      Auf iOS funktioniert das Ganze nach Erstellung der Rewrite-Regel bei mir. Unter OS X ist es unter El Capitan leider überhaupt nicht zum Laufen zu bringen – was einem WebDAV/CardDAV-Bug im System geschuldet ist.

      Welche Version von Baikal nutzt Du denn? Bei neueren Versionen scheint es wohl ein bekanntes Problem zu geben: https://github.com/fruux/Baikal/issues/472

      Beste Grüße!

      • Guten Abend Christian,

        danke für Deine Rückantwort. Ich nutze Mountain Lion i.V.m. Raspberry 2 und Raspbian Wheezy. Mit IOS habe ich den Aufruf noch nicht ausprobiert, da es bereits am Mac mit der o.g. Fehlermeldung scheiterte.

        Wenn ich in Baikal zusätzlich einen user „pi“ oder „www-data“ anlege und dann über die oben beschriebene (jedoch um den jeweils neuen user veränderte) URL aufrufe, ändert sich die Fehlermeldung auf:

        (beispielhaft user www-data):
        SabreDAVACLExceptionNeedPrivileges User did not have the required privileges ({DAV:}read) for path „principals/www-data“ 1.8.7 /kalender/cal.php/principals/www-data

        Hilft dies bei de Lokalisierung der Lösung irgendwie weiter?

        Zukünftig möchte ich gern mit user xyz (und nicht pi oder www-data) arbeiten. Diese Variante (pi bzw. www-data) habe ich nur aufgrund eines anderen von Dir geschriebenen Artikels (zu Samba und den dort notwendig einzurichtenen Nutzerrechten, welche die beiden user pi u. www-data ja bereits haben) zur Fehlersuche ausprobiert.

        Einen schönen Abend wünscht Dir mit besten Grüßen
        Erri

  46. Hi, gibt es auch eine Lösung, den Kalendar in der w10 Calendar app anzeigen zu lassen?

    Ich bekomme zwar die Kalendar angezeigt, jedoch sind diese leer; werden nicht geladen.

    Ich habe auch schon probiert, die cal.php und card.php wie folgt anzupassen:

    # Backends
    if( BAIKAL_DAV_AUTH_TYPE == "Basic" || preg_match('/Windows-Phone-WebDAV-Client/i', $_SERVER['HTTP_USER_AGENT'])
    || preg_match('/MSFT-WP*/i', $_SERVER['HTTP_USER_AGENT'])
    || preg_match('/MSFT-WIN*/i', $_SERVER['HTTP_USER_AGENT'])
    || preg_match('/MSFT-WIN-3/', $_SERVER['HTTP_USER_AGENT']) )

    Aber scheinbar ist es immer noch nicht die Lösung für mein Problem (Implementierung mit dem iCloud-Trick).

  47. Hallo Christian,

    falls unter den Lesern ein Blackberry Q10/Classic/Passport/Z10/… sein sollte, habe ich folgendes URL-Schema erfolgreich im Einsatz:
    http://„server-fqdn“/baikal/html/cal.php/calendars/“userid“
    Kein Slash am Ende! Name und Passwort müssen in die vorgesehen Felder eingegeben werden.
    Nach dem Speichern und Prüfung durch das System steht der neue Kalender zur Verfügung. Es werden auch alle „Unterkalender“ angezeigt und lassen sich auch benutzen.

    Ich hoffe, das hilft weiter.

    Grüßle
    Jürgen

Schreibe einen Kommentar