cardDav-server mit Catalina gesucht

dg2rbf schrieb:
Hi,
scheinbar unterschätzt du das "kleine private Projekt", ich hatte auch schon versch. Server in Betrieb, ich habe es wieder aufgegeben, der Aufwand für Sicherheit und Verwaltung, ist heftig und Zeit raubend.
Franz
Zum Vergrößern anklicken....
Hast Du denn wirklich alles gelesen was ich geschrieben habe?
Wenn ja, erkläre mir bitte den Aufwand, denn ich sehe und verstehe diesen gerade wirklich nicht. Ich rede von einem kleinen Baikal CalDav Server für einen einzigen User und einen einzigen Kalender auf einem gemangten Webspace.
 
lisanet schrieb:
Ja, das ist schon klar. Und diese Hilfstool hat 2 Beispielkonfigurationen, die du auf die konkreten Pfade deines Webservers anpassen musst. Dazu benötigst du halte auch sowohl Zugriff auf die Konfiguration deines Webservers als auch etwas Wissen, wo und wie das zu bewerkstelligen ist. Die Konfiguration für Baikal ist eher recht einfach aufgebaut, aber das, wie du selbst sagst, überfordert dich eben. Dann bleibt halt nur die Alternative eines anderen Dienstleisters. Oder was hast du erwartet?
Zum Vergrößern anklicken....
Nein, es überfordert mich aus dem Stegreif die richtigen Anpassungen aus der Apache Beispielkonfiguration vorzunehmen. Das heißt nicht, dass es nicht alleine lösbar ist und schon gar nicht mit der zusätzlichen Unterstützung von Experten.
 
https://posteo.de kann man noch als vernünftigen (insbesondere im sinne des Datenschutzes) Hoster für Kontakte und Kalender ins Rennen werfen.

alles schick verschlüsselt - Allerdings ohne Kontaktgruppen.
 
tocotronaut schrieb:
https://posteo.de kann man noch als vernünftigen (insbesondere im sinne des Datenschutzes) Hoster für Kontakte und Kalender ins Rennen werfen.

alles schick verschlüsselt - Allerdings ohne Kontaktgruppen.
Zum Vergrößern anklicken....
Es gibt viele Dienste und auch über meinen Provider wird mir so ein Dienst angeboten. Aber mir ging es explizit um die Baikal-Konfiguration.
 
mirotsu schrieb:
Das heißt nicht, dass es nicht alleine lösbar ist und schon gar nicht mit der zusätzlichen Unterstützung von Experten.
Zum Vergrößern anklicken....
Für Apache kann ich dir nicht helfen, für nginx schon. Aber mal grundsätzlich: Da du keinen eigenen Server hast, sondern so wie das klingt, einen Webserver eines Webspaceproviders nutzt, kannst du da überhaupt die config Dateien für den Apache ändern?

Soweit ich Apache kenne, musst du diese Einstellungen in den config-Dateien des wevbservers vornehmen, nicht in den htaccess-Dateien. Und genau auf diese config-Datei bezog auch auch den Aufwand an Pflege und Notwendigkeit, dich mit der Sicherheit auseinander zu setzen. Aber wie gesagt: ich bin kein Apache-Profi, eher nginx
 
Nein, die Config-Datei kann ich nicht ändern. Ich kann verschiedene PHP-Versionen auswählen, habe SSH Zugang auf den Server und kann auch die htaccess anlegen und bearbeiten.
Anscheinend geht es weiterhin um den Pfad, den der Mac nicht automatisch findet. Und diesen müsste man doch über die htaccess setzen können.
 
Die Beispieldateien generieren einen virtuellen Host. Dafür benötigst du Zugriff auf die config des webservers.

Die beiden rewrite-Rules solltest du auch in htaccess unterbringen können, allerdings musst du dann den Pfad "/dav.php" auf den exakten Pfad, ausgehend vom Document-Root deines Webspaces, zu dem Pfad deiner Baikal-Installation, in dem das dav.php eben liegt, anpassen.

So wie ich mich erinnere musst du https:/deine.subdomain.de/caldav in iOS erfassen. Voraussetzung dabei ist, dass in den configs das https://deine.domain.de auch auf den Pfad zeigt in welchem Baikal installiert ist. ggf. must du den Pfad dort um ein Unterverzeichnis erweiteren und das auch in den rewrite-Rules entsprechend ergänzen. Sollte das nicht gehen, kannst du probieren ob der komplette Pfad des dav.php-Files funktioniert, was dann in etwas os aussehen kann "https://deine.domain.de/verzeichnis/von/baikal/unterverzeichnis/dav.php"

Wie das mit dem <Directory>-Abschnitt ist, ob das in htacces funktioniert oder nicht, kann ich dir nicht sagen. Das regelt den Zugriff. Die config deines Provider-Apache sollte aber stimmige Daten liefern. Musst du halt testen.

Meiner Erfahrung nach funktioniert iOS mit dem rewrite-Rule auf https://deine.domain.de/caldav besser als mit dem kompletten Pfad zum dav.php. So war es zumindest unter nginx. Für nginx brauchst du Zugriff auf die configs. htaccess-Dateien greifen da nicht.

Edit: Wenn die rewrite-Rule passt, sollte iOS und macOS sogar mit einem simplen https://deine.domain.de automatisch den Baikal-Server finden.
 
Zuletzt bearbeitet:
Vielen Dank für Deine Mühe!
Ich lese mich noch ein wenig ein und versuche es mit den Tipps!
 
Da schalte ich mich nochmals ein. Sobald Ich wieder in heimatlichen Gefilden bin probiere ich das von lisanet beschriebene mal aus. Danke!
 
Habe jetzt gerade mal 0.71 installiert:
- Baikal erreiche ich unter https://localhost/~heiner/baikal/html/admin/
- user virk@gmx.net ist eingerichtet, alternativ hatte ich "Heiner" versucht
- Wenn Ich in Systemeinstellungen/Internetaccounts einen neuen carddav-account einrichten will mit:
a) Automatisch: virk@gmx.net und Passwort
b) Manuell: Heiner und Passwort und https://localhost/~heiner/baikal

erscheint in rot "Accountname/Passwort konnte nicht überprüft werden". Das ist die gleiche Hürde, an der ich auch damals scheiterte.

Meine .htaccess in baikal und in baikal/html ist identisch und sieht JETZT so aus:

# Disabling cache management
# that could cause problems with DAV requests
# Useful only for Apache servers, with AllowOverride All
# (ie, .htaccess files enabled)

# Allow HTTP headers with Apache/FastCGI
# See http://code.google.com/p/sabredav/wiki/Authentication#Apache_+_(Fast)CGI

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
</IfModule>

<IfModule mod_expires.c>
ExpiresActive Off
</IfModule>

<IfModule mod_alias.c>
Redirect 308 /.well-known/caldav /html/dav.php
Redirect 308 /.well-known/carddav /html/dav.php
</IfModule>

Wo liegt da bei mir der (Denk-)Fehler?
 
Mein Blog-Artikel ist über die Installation von baikal auf einem Webspace eines Hostingsproviders. Dort läuft regelmäßig Apache. Der Apache dort hat auch in seiner config-Datei Einstellungen für einen virtuellen Host. Dieser virtuelle Host ist die Subdomain, welche auf das Verzeichnis baikal zeigt.

Du installierst das lokal. Hast du da überhaupt einen Apache laufen? Ist dieser korrekt konfiguriert? Du hast auch keine subdomain eingerichtet, sondern nutzt als Serveradresse einen kompletten Pfad.

Zudem dürfen die beiden .htaccess eben nicht identisch sein. Ich habe ja nur geschrieben, dass die ins Verzeichnis baikal kopierte .htaccess angepasst werden muss auf /html/dav.php. Die Version in baikal/html muss / sollte schon auf /dav.php bleiben. Con html aus gesehen, musst du ja keinen erneuten Redirect nach html machen.

Ich habe bisher immer die Erfahrung gemacht, dass iOS / macOS als Serveradresse Probleme macht mit einem Pfad, daher nutze ausschließlich die Subdomain.

Wie gesagt, meine Anleitung gilt für einen Webspace-Provider, der einen Apache verwendet, mit SSL-Zertifikat und Subdomain.

Edit: Automatische Einrichtung geht definitv nicht, da aus deiner user-Adresse nicht die korrekte Domain ermittelbar ist, baikal läuft ja nicht auf gmx.de Eine lokale Installation habe ich nicht getestet und finde ich auch wenig sinnvoll (und werde sie daher auch nicht testen)
 
Ja, ein apache läuft; mit dem erreiche ich ja auch die Baikalseite und parallel ein laufendes dokuwiki. Ob apache richtig configuriert ist, vermag ich nicht zu sagen. Ein "sudo apachectl configtest" liefert:

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using virk.local. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Ich werde mal weiterprobieren und recherchieren. Danke Dir für Deine Bemühungen.
 
Jetzt läuft es bei mir auch: Ich habe ggü. der standardmäßig durchgeführten Installation lediglich die base_uri auf '~heiner/baikal/html/' geändert.

Kommando zurück: Kann doch noch nicht sagen, dass es funktioniert. Lediglich den account konnte ich im Adressbuch fehlerfrei einrichten. Jedoch kann ich ihn anscheinend nicht so mit Daten beladen, dass diese Daten auch im Browser auftauchen, wenn man sich als user anmeldet. Mal weiter experimentieren!
 
Zuletzt bearbeitet:
In /baikal/config/baikal.yaml

Aber ich bin lediglich einen Schritt weiter gekommen; es läuft doch nicht. /baikal/Specific/dp/db.sqlite wird nicht"gefüllt". Das Adressbuch "suggeriert" mir allerdings, dass es läuft: Im Adressbuch konnte ich den account einrichten und beladen. Desweiteren kann ich mich "jetzt" im Browser als user anmelden.
 
Warum legst du keine Subdomain an, so wie ich das beschrieben habe und so wie es auch die Doku vorgibt?

Klar kannst du versuchen nun alles umzubiegen, aber der einfachere Weg ist das nun nicht gerade. Es macht einfach wenig Sinn, ausgerechnet localhost als server und Documentroot heranzuziehen und dann alles manuell umzubiegen, anstatt eine eigene virtuelle Subdomain für das baikal-Verzeichnis anzulegen. Was versprichst du dir davon, keine eigene Subdomain zu verwenden?
 
Ehrlich gesagt, verspreche ich mir nix davon :) Mir fehlen einfach die Kenntnisse, um GEZIELT was umzusetzen. Wüsstest Du denn einen link zu einer Information, die mir das Einrichten einer virtuellen subdomain ausreichend beschreibt. Natürlich sehe ich mir Deine Beiträge jetzt noch einmal an :) Nur befürchte ich halt, dass es dann bei mir auch irgendwann erst mal wieder hakt.
 
Wenn du dich mit Apache nicht auskennst, dann lass es sein, den unbedignt lokal laufen zu lassen und besorge dir einen Webspace. Dort läuft eigentlich immer Apache passend konfiguriert und man kann beliebige Subdomains anlegen. Dann kannst du das schrittweise nach meinem Blogposting machen.

Ich dachte bislang, eben weil du gerade lokal herum hantierst und in config-Dateien herum bastelst, dass du dich mit Apache auskennst. Ich kenne mich nicht damit aus, sondern habe mich einfach an die Dokus gehalten und gerade mal 1 Wort in 2 Zeilen ergänzt. Mehr ist da nicht anzupassen.
 
Zurück
Oben Unten