Własny serwer kalendarza CalDAV na VPS z Radicale

Co budujesz

Własny serwer kalendarza to jedna instancja CalDAV na kontrolowanym przez Ciebie serwerze VPS, zabezpieczona protokołem TLS, z indywidualnym logowaniem dla każdego użytkownika. Telefon w kieszeni i laptop na biurku wyświetlają te same wydarzenia, podobnie jak komputer partnera. W procesie nie pośredniczy konto Google.

Jest to zadanie odmienne od własnej strony do rezerwacji. Strona do rezerwacji służy osobom trzecim: publikuje wolne terminy i umożliwia ich zajęcie. Serwer kalendarza służy własnym urządzeniom: przechowuje wydarzenia i synchronizuje wszystkie klienty. Często uruchamia się oba rozwiązania, a narzędzie do rezerwacji odczytuje dostępność z serwera CalDAV zbudowanego w ramach tego poradnika.

Instalacja jest niewielka. Radicale to jeden pakiet Python i około dziesięć linii konfiguracji. O trwałości rozwiązania po pierwszym miesiącu decyduje TLS, mechanizm wykrywania usług (discovery), kolekcje dla poszczególnych użytkowników oraz kopie zapasowe. Te zagadnienia zajmują większość poniższej treści.

Czym jest CalDAV i dlaczego ma znaczenie?

CalDAV to synchronizacja kalendarza za pośrednictwem HTTP. Została zdefiniowana w RFC 4791 jako rozszerzenie protokołu WebDAV (Web Distributed Authoring and Versioning, zestaw dodatkowych metod HTTP zdefiniowanych w RFC 4918). Kalendarz jest kolekcją, która zachowuje się jak katalog. Pojedyncze wydarzenie stanowi plik wewnątrz tej kolekcji, zapisany w formacie tekstowym iCalendar (RFC 5545), czyli tym samym, który jest używany w .ics załącznikach poczty elektronicznej.

Klienci korzystają ze zwykłego protokołu HTTP z kilkoma dodatkowymi metodami. PROPFIND sprawdza zawartość oraz właściwości zasobów. REPORT pobiera przefiltrowany wycinek danych, na przykład wszystkie wydarzenia z określonego zakresu dat. PUT zapisuje pojedyncze wydarzenie, a DELETE usuwa je. Każde wydarzenie zawiera linię UID; ten identyfikator pozwala dwóm urządzeniom ustalić, że odnoszą się do tego samego wydarzenia, a nie do jego kopii.

Główną korzyścią, dla której warto wdrożyć to rozwiązanie, jest przenośność. Systemy iOS, macOS, Thunderbird, Evolution oraz Android (poprzez aplikację DAVx⁵) obsługują protokół CalDAV. Dane nie są przypisane do wybranego obecnie serwera. Wystarczy przenieść pliki na inny serwer CalDAV, wskazać klientom nową nazwę hosta i cała reszta pozostaje bez zmian.

CardDAV działa na podobnej zasadzie. Jest to to samo rozwiązanie, lecz przeznaczone dla kontaktów, zdefiniowane w RFC 6352 i przechowujące pliki vCard zamiast wydarzeń. Każdy z wymienionych poniżej serwerów obsługuje oba protokoły w ramach tego samego konta, więc gdy kalendarz zacznie działać, konfiguracja książki adresowej sprowadza się do zaznaczenia jednej opcji.

Który serwer CalDAV wybrać?

Radicale to najmniejsze działające rozwiązanie. Oparte na Python, nie wymaga bazy danych, a dane przechowuje w zwykłych plikach. Ten przewodnik wykorzystuje je, ponieważ kalendarz domowy nie potrzebuje niczego więcej, a ryzyko awarii w środku nocy jest minimalne.

Baikal to opcja z panelem administracyjnym WWW. Działa w oparciu o PHP i bibliotekę sabre/dav, przechowuje użytkowników oraz kalendarze w SQLite lub MySQL i pozwala dodawać osoby przez przeglądarkę zamiast wiersza poleceń. Wybierz to rozwiązanie, jeśli konta użytkowników są często tworzone i usuwane.

Nextcloud jest właściwym wyborem, gdy kalendarz stanowi tylko jedną z wielu funkcji. Otrzymujesz kalendarz, kontakty, pliki i aplikację mobilną kosztem konieczności utrzymywania PHP-FPM, bazy danych oraz mechanizmu zadań w tle. Jeśli wydaje się to zbyt rozbudowane w stosunku do rzeczywistych potrzeb, lżejsze alternatywy dla Nextcloud opisują inne rozwiązania, a samodzielna synchronizacja plików obejmuje drugą połowę funkcjonalności, dla których użytkownicy instalują Nextcloud.

DAViCal to długo rozwijana opcja oparta na PostgreSQL. Warto ją rozważyć tylko wtedy, gdy już korzystasz z PostgreSQL i chcesz, aby dane kalendarza były w nim przechowywane.

Instalacja Radicale na Ubuntu 24.04

Radicale 3.8.3, oznaczony 8 października 2026, jest aktualnym wydaniem na dzień 11 października 2026. Należy zainstalować go w dedykowanym środowisku wirtualnym, z dodatkiem bcrypt, od którego zależy poniższy plik haseł.

sudo apt update
sudo apt install -y python3-venv apache2-utils nginx
sudo useradd --system --user-group --home-dir / --shell /usr/sbin/nologin radicale
sudo install -d -o radicale -g radicale -m 750 /var/lib/radicale/collections
sudo install -d -m 750 -o root -g radicale /etc/radicale
sudo python3 -m venv /opt/radicale/venv
sudo /opt/radicale/venv/bin/pip install --upgrade 'radicale[bcrypt]'

Środowisko wirtualne nie jest kwestią stylu. sudo pip install radicale w systemowym Pythonie kończy się błędem error: externally-managed-environment, ponieważ Ubuntu oznacza swojego Pythona jako zarządzanego przez apt, aby uniemożliwić pip nadpisywanie plików pakietów.

Utwórz /etc/radicale/config:

[server]
hosts = 127.0.0.1:5232

[auth]
type = htpasswd
htpasswd_filename = /etc/radicale/users
htpasswd_encryption = autodetect

[storage]
filesystem_folder = /var/lib/radicale/collections

hosts celowo wiąże się z interfejsem loopback. nginx kończy połączenie TLS i przekazuje je na ten port, dzięki czemu Radicale nigdy nie jest wystawione bezpośrednio na działanie Internetu. Przykład upstream 0.0.0.0:5232 publikuje niezaszyfrowaną usługę akceptującą hasła, co jest jedynym istotnym błędem w tym kontekście.

Teraz konta. -B wybiera bcrypt, który Radicale odczytuje za pomocą htpasswd_encryption = autodetect, pod warunkiem obecności modułu bcrypt z instalacji radicale[bcrypt] powyżej:

sudo htpasswd -B -c /etc/radicale/users you
sudo htpasswd -B /etc/radicale/users partner
sudo chown root:radicale /etc/radicale/users
sudo chmod 640 /etc/radicale/users

-c tworzy plik i usuwa jego dotychczasową zawartość. Należy użyć go tylko dla pierwszego użytkownika. Ponowne uruchomienie htpasswd -B -c po kilku miesiącach usunie wszystkie konta dodane po pierwszym, a objawem będzie sytuacja, w której jedna osoba synchronizuje dane poprawnie, podczas gdy pozostali otrzymują nieskończoną pętlę z prośbą o hasło. SHA-512 crypt (-5) nie jest tutaj opcją: htpasswd zyskało wsparcie dla SHA-2 w Apache 2.4.59, a Ubuntu 24.04 dostarcza apache2-utils 2.4.58, którego htpasswd nie posiada flagi -5.

Utwórz /etc/systemd/system/radicale.service, dostosowując plik jednostki z dokumentacji Radicale:

[Unit]
Description=CalDAV and CardDAV server
After=network.target
Requires=network.target

[Service]
ExecStart=/opt/radicale/venv/bin/python -m radicale
Restart=on-failure
User=radicale
UMask=0027
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
NoNewPrivileges=true
ReadWritePaths=/var/lib/radicale/

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now radicale
curl -i http://127.0.0.1:5232/

Poprawny wynik to 401 Unauthorized z nagłówkiem WWW-Authenticate: usługa nasłuchuje, a uwierzytelnianie jest włączone. Connection refused oznacza, że nikt nie nasłuchuje pod tym adresem, zazwyczaj z powodu nieudanego startu usługi lub jej późniejszego wyjścia, a journalctl -u radicale -n 50 wskazuje opcję, która została odrzucona. ProtectSystem=strict montuje system plików w trybie tylko do odczytu dla tej usługi, więc ReadWritePaths=/var/lib/radicale/ jest linią, która pozwala na zapisywanie zdarzeń. Usunięcie tej linii sprawi, że odczyty będą działać, podczas gdy każdy zapis zakończy się niepowodzeniem.

TLS nie jest opcjonalny, ponieważ klienci odrzucają połączenia nieszyfrowane

Ta konfiguracja wykorzystuje uwierzytelnianie HTTP Basic, które jest jedynym schematem akceptowanym przez Radicale, a Basic przesyła user:password zakodowane w base64 w każdym pojedynczym żądaniu. Base64 to kodowanie, a nie szyfrowanie. W przypadku zwykłego HTTP hasło jest przekazywane do każdej sieci pomiędzy telefonem a serwerem, przez cały dzień, przy każdej synchronizacji.

Klienci wymuszają to zabezpieczenie. Dokumentacja Radicale wskazuje, że macOS Calendar.app może po cichu odmawiać wysyłania danych uwierzytelniających przez niezabezpieczone HTTP, a iOS zachowuje się w ten sam sposób. Konto wygląda na skonfigurowane, ale po prostu nigdy nie synchronizuje danych, nie wyświetlając przy tym żadnego komunikatu o błędzie.

Najpierw skieruj rekord A dla cal.example.com na VPS, ponieważ urząd certyfikujący przeprowadza jego weryfikację. Następnie utwórz /etc/nginx/sites-available/cal.example.com:

server {
    listen 80;
    server_name cal.example.com;

    location / {
        proxy_pass        http://localhost:5232/;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  X-Forwarded-Proto $scheme;
        proxy_set_header  Host $http_host;
        proxy_pass_header Authorization;
    }

    location = /.well-known/caldav  { return 301 https://$host/; }
    location = /.well-known/carddav { return 301 https://$host/; }
}

Cztery linie nagłówków proxy pochodzą z dokumentacji Radicale. Należy zachować je w niezmienionej formie.

sudo ln -s /etc/nginx/sites-available/cal.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d cal.example.com
curl -i -u you https://cal.example.com/

nginx -t wyświetla syntax is ok oraz test is successful. Przeładuj konfigurację dopiero po wykonaniu tego sprawdzenia, ponieważ przeładowanie z błędnym plikiem pozostawia aktywną starą konfigurację i ukrywa błąd aż do następnego restartu. Certbot edytuje plik witryny w miejscu: instaluje certyfikat, przełącza blok na port 443 i dodaje przekierowanie z portu 80. Końcowe polecenie curl wymaga podania hasła i powinno zwrócić 200, co stanowi interfejs WWW programu Radicale. Kod 502 Bad Gateway oznacza, że nginx działa, ale nie otrzymał poprawnej odpowiedzi z portu 5232; najczęstszą przyczyną jest fakt, że Radicale nie nasłuchuje na tym porcie.

Dlaczego dodawanie konta na telefonie kończy się niepowodzeniem?

Przyczyną jest proces wykrywania. RFC 6764 opisuje, w jaki sposób klient przekształca nazwę hosta w adres URL kalendarza. Klient wyszukuje rekord _caldavs._tcp SRV, następnie wysyła zapytanie do https://cal.example.com/.well-known/caldav i oczekuje przekierowania do katalogu głównego DAV. Stamtąd odpytuje o current-user-principal, następnie o calendar-home-set danego użytkownika i dopiero wtedy uzyskuje dostęp do kalendarzy. Telefon udostępnia tylko jedno pole na adres serwera, więc każdy etap musi przebiec automatycznie.

curl -sI https://cal.example.com/.well-known/caldav

Prawidłowa odpowiedź serwera to HTTP/2 301 z nagłówkiem location: https://cal.example.com/. Błąd 404 w tym miejscu jest częstą przyczyną, dla której system iOS zgłasza brak możliwości weryfikacji informacji o koncie, podczas gdy Thunderbird w tej samej sieci działa poprawnie: Thunderbird używa pełnego adresu URL wprowadzonego przez użytkownika, więc nie wymaga przekierowania.

Cel przekierowania zależy od serwera. Radicale działający w katalogu głównym witryny przekierowuje do /, a sam Radicale odpowiada na tę ścieżkę kodem 301, gdy żądanie do niego dotrze, dlatego reguły nginx czynią to przekierowanie jawnym, zamiast je tworzyć. Baikal zawiera przykładowe reguły, które przekierowują do /dav.php z kodem statusu 308. Nextcloud przekierowuje do /remote.php/dav/.

Tworzenie kalendarzy i udostępnianie jednego z nich partnerowi

Wiele klientów nie posiada funkcji tworzenia kalendarza, a jedynie subskrypcji. Otwórz https://cal.example.com/ w przeglądarce, zaloguj się jako you i utwórz tam kalendarz. Na dysku zostanie on zapisany w /var/lib/radicale/collections/collection-root/you/, z wygenerowanym identyfikatorem jako nazwą folderu.

Domyślnym mechanizmem uprawnień w Radicale jest owner_only: uwierzytelnione konto ma prawo odczytu i zapisu własnych kolekcji w /USERNAME/ i żadnych innych. W większości gospodarstw domowych jest to ustawienie wystarczające, a najprostszym sposobem na współdzielenie kalendarza jest utworzenie trzeciego konta. Utwórz household za pomocą htpasswd, utwórz współdzielony kalendarz w ramach tego loginu i dodaj go na każdym urządzeniu jako drugie konto CalDAV. Rozwiązanie to działa na każdym kliencie, w tym na iOS, ponieważ kalendarz znajduje się w katalogu domowym tego konta.

Jeśli wymagana jest bardziej precyzyjna kontrola, należy przejść na uprawnienia oparte na regułach. Dodaj poniższy wpis do /etc/radicale/config:

[rights]
type = from_file
file = /etc/radicale/rights

Następnie skonfiguruj /etc/radicale/rights, wzorując się na przykładzie z dokumentacji Radicale:

[root]
user: .+
collection:
permissions: R

[principal]
user: .+
collection: {user}
permissions: RW

[own-calendars]
user: .+
collection: {user}/[^/]+
permissions: rw

[shared-household]
user: you|partner
collection: you/2f0a9c1e-1f4c-4c2b-9a1b-0d2f7a5c9e11
permissions: rw

Wielkie i małe litery mają odmienne znaczenie. R oraz W odpowiadają za odczyt i zapis kolekcji, które nie są kalendarzami ani książkami adresowymi, co stanowi główny folder użytkownika (principal). r oraz w odpowiadają za odczyt i zapis samych kalendarzy. Zastąp ten identyfikator rzeczywistą nazwą folderu kalendarza, pobraną ze ścieżki przechowywania danych wskazanej powyżej.

Istotne ograniczenie: klient, który odczytuje jedynie główny katalog kalendarzy, nie wyświetli kalendarza znajdującego się w ścieżce innego użytkownika, ponieważ mechanizm wykrywania nie przeszukuje tych lokalizacji. Thunderbird oraz DAVx⁵ pozwalają na dodanie go poprzez pełny adres URL. System iOS na to nie pozwala, dlatego model współdzielonego konta jest jedynym, który działa zawsze.

Konfiguracja klientów, czyli miejsce, w którym najczęściej zawodzą własne kalendarze

iPhone i iPad. Otwórz Ustawienia, następnie Kalendarz (w nowszych wersjach iOS znajduje się w sekcji Aplikacje), potem Konta kalendarza, Dodaj konto, Inne, Dodaj konto CalDAV. Serwer to cal.example.com, następnie podaj nazwę użytkownika i hasło. Opis jest tylko etykietą. Jeśli zapisanie nie powiedzie się, otwórz konto ponownie: widok zaawansowany pozwala skonfigurować Użyj SSL, port oraz pełny adres URL konta; wklejenie pełnego adresu URL całkowicie pomija proces automatycznego wykrywania.

Android. System nie posiada wbudowanego klienta CalDAV. Zainstaluj DAVx⁵ z F-Droid lub Google Play, dodaj konto używając bazowego adresu URL https://cal.example.com/ wraz z nazwą użytkownika, a następnie zaznacz kalendarze, które chcesz synchronizować. DAVx⁵ zapisuje dane bezpośrednio do dostawcy kalendarza w systemie Android, dzięki czemu wydarzenia pojawią się w dowolnej używanej przez Ciebie aplikacji kalendarza.

Thunderbird. Nowy kalendarz, W sieci, następnie podaj nazwę użytkownika oraz lokalizację https://cal.example.com/. Aplikacja wyświetli listę znalezionych kalendarzy i zapyta, które z nich dodać.

macOS. Ustawienia systemowe, Konta internetowe, Dodaj inne konto, CalDAV, ustaw Typ konta na Ręczny, a następnie wprowadź tę samą nazwę użytkownika, hasło i adres serwera.

CalDAV jest protokołem opartym na odpytywaniu (polling). Specyfikacja nie przewiduje mechanizmu push, więc wydarzenie dodane na laptopie pojawi się na telefonie dopiero przy następnej synchronizacji, a nie w tej samej sekundzie. Ustaw w każdym kliencie interwał, który jest dla Ciebie akceptowalny, pamiętając, że krótszy interwał na telefonie szybciej zużywa baterię.

Tworzenie kopii zapasowej magazynu danych, który składa się wyłącznie z plików

W przypadku Radicale kalendarz stanowi katalog plików .ics, gdzie każdy plik odpowiada jednemu wydarzeniu, wraz z niewielkim plikiem właściwości dla każdej kolekcji. Dowolna metoda kopiowania katalogu tworzy kopię zapasową, a zawartość kopii można sprawdzić za pomocą less, aby potwierdzić obecność rzeczywistych wydarzeń. Jest to istotna przewaga nad zrzutem bazy danych, którego nie można odczytać w sposób bezpośredni.

sudo systemctl stop radicale
sudo tar czf /root/radicale-$(date +%F).tar.gz -C /var/lib/radicale collections
sudo systemctl start radicale

Zatrzymaj usługę na kilka sekund potrzebnych na wykonanie archiwizacji, aby żaden klient nie znajdował się w trakcie zapisu danych podczas odczytu plików. Następnie skopiuj archiwum poza serwer, ponieważ kopia zapasowa przechowywana na tym samym VPS nie przetrwa awarii, przed którą zabezpieczasz system. Przywracanie danych przebiega odwrotnie: rozpakuj archiwum, użyj sudo chown -R radicale:radicale /var/lib/radicale/collections i uruchom usługę. Każdy klient przechowuje również lokalną kopię kalendarzy, więc laptop, który nie synchronizował się od czasu awarii, stanowi drugą kopię danych.

Kiedy lepiej wybrać Baikal, a kiedy Nextcloud

Wersja Baikal 0.12.1 została wydana 5 sierpnia 2026 i wymaga PHP 8.2 lub nowszego. Należy rozpakować ją poza głównym katalogiem serwera WWW i udostępnić wyłącznie katalog html:

sudo apt install -y php-fpm php-sqlite3 php-xml php-mbstring php-curl unzip
cd /tmp
curl -LO https://github.com/sabre-io/Baikal/releases/download/0.12.1/baikal-0.12.1.zip
sudo unzip -q baikal-0.12.1.zip -d /srv
sudo chown -R www-data:www-data /srv/baikal/Specific /srv/baikal/config

Tylko te dwa katalogi wymagają uprawnień do zapisu dla serwera WWW, więc pozostałe elementy nie muszą być zapisywalne. W bloku serwera nginx konfiguracja specyficzna dla Baikal wygląda następująco:

root /srv/baikal/html;
index index.php;

location ~ /(\.ht|Core|Specific|config) { deny all; }

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

location = /.well-known/caldav  { return 308 /dav.php; }
location = /.well-known/carddav { return 308 /dav.php; }

Po przeładowaniu nginx i otwarciu strony w przeglądarce, kreator konfiguracji utworzy konto administratora oraz bazę danych SQLite. Konfiguracja klienta jest identyczna jak w przypadku Radicale, z adresem serwera https://cal.example.com/, ponieważ reguła well-known kieruje proces wykrywania do /dav.php.

Nextcloud jest uzasadnionym wyborem tylko wtedy, gdy wymagany jest również dostęp do plików oraz aplikacja mobilna w ramach jednego logowania. Główny punkt dostępu DAV to /remote.php/dav/, a zasady wykrywania pozostają takie same. W przypadku każdej z tych usług, uruchomienie jej w kontenerze pozwala uniknąć instalacji wersji PHP na systemie hosta: Docker Compose na VPS opisuje plik compose oraz działający przed nim reverse proxy, natomiast co warto hostować samodzielnie w 2026 stanowi odpowiednie miejsce do podjęcia decyzji o skali wdrożenia.

Tryby awarii i komunikaty, które zobaczysz

Każda synchronizacja zwraca 401. Albo plik haseł utracił konta na rzecz drugiego htpasswd -c, albo użytkownik radicale nie ma uprawnień do jego odczytu. Sprawdź to za pomocą sudo -u radicale cat /etc/radicale/users; błąd odmowy dostępu (permission denied) wskazuje przyczynę, a rozwiązaniem jest przypisanie grupy radicale i ustawienie uprawnień 640. Radicale domyślnie czeka sekundę po każdym nieudanym logowaniu, więc klient z nieaktualnym hasłem sprawia wrażenie wolnego, zamiast być odrzuconym.

nginx zwraca 405 dla PROPFIND. Adres URL jest obsługiwany jako plik statyczny, więc metoda WebDAV nie dociera do Radicale. Przetestuj punkt końcowy bezpośrednio:

curl -u you -X PROPFIND -H "Depth: 0" -i https://cal.example.com/you/

Działająca kolekcja DAV zwraca 207 Multi-Status. Cokolwiek innego oznacza, że żądanie zostało zatrzymane na serwerze WWW.

Telefon nie może zweryfikować konta, a przeglądarka działa poprawnie. Istnieją dwie typowe przyczyny. Brakuje przekierowania well-known, co można sprawdzić poleceniem curl powyżej. Alternatywnie łańcuch certyfikatów jest niekompletny; przeglądarki maskują ten problem, pobierając brakujący certyfikat pośredni, podczas gdy iOS tego nie robi. Sprawdź to z poziomu powłoki:

openssl s_client -connect cal.example.com:443 -servername cal.example.com </dev/null

Szukaj Verify return code: 0 (ok). Jeśli test kończy się niepowodzeniem, konfiguracja nginx wskazuje na cert.pem, podczas gdy powinna wskazywać na fullchain.pem.

Zduplikowane wydarzenia po imporcie. Każde wydarzenie posiada UID, który klienci traktują jako identyfikator. Zaimportowanie tego samego pliku dwukrotnie za pomocą narzędzia, które generuje nowe identyfikatory, powoduje powstanie dwóch wydarzeń, których nic nie scali. Usuń dodatkowe kopie na jednym urządzeniu i pozwól, aby usunięcie zostało zsynchronizowane.

Wszystko przestaje działać po restarcie. Usługa została uruchomiona ręcznie. sudo systemctl is-enabled radicale wyświetla disabled, a sudo systemctl enable --now radicale naprawia to na stałe.

FAQ

Czy naprawdę potrzebuję TLS dla samodzielnie hostowanego serwera CalDAV?

Tak. Radicale uwierzytelnia użytkowników za pomocą HTTP Basic, więc hasło jest przesyłane w kodowaniu base64 w każdym żądaniu, a base64 można łatwo odwrócić. Klienci również wymuszają to zabezpieczenie: macOS Calendar.app może po cichu odmawiać wysyłania poświadczeń przez niezabezpieczony protokół HTTP, a iOS zachowuje się identycznie, przez co konto wydaje się zapisane, ale nigdy nie synchronizuje danych. sudo certbot --nginx -d cal.example.com to podstawa bezpieczeństwa.

Dlaczego telefon nie może dodać konta, podczas gdy Thunderbird działa poprawnie?

Thunderbird używa pełnego adresu URL, który został wprowadzony. Telefon udostępnia tylko jedno pole serwera, więc polega na mechanizmie wykrywania zgodnie z RFC 6764, co bez rekordu SRV oznacza, że wysyła żądanie https://cal.example.com/.well-known/caldav i oczekuje przekierowania do katalogu głównego DAV. Jeśli to żądanie zwraca błąd 404, telefon zazwyczaj zgłasza brak możliwości weryfikacji konta. Dodaj location = /.well-known/caldav { return 301 https://$host/; } do konfiguracji nginx, a następnie potwierdź za pomocą curl -sI https://cal.example.com/.well-known/caldav, że otrzymujesz kod 301 oraz nagłówek location. Wklejenie pełnego adresu URL konta w ustawieniach zaawansowanych iOS całkowicie pomija proces wykrywania.

Czy dwie osoby mogą współdzielić jeden kalendarz?

Tak, a najbardziej niezawodnym sposobem jest wspólny login. Utwórz trzecie konto za pomocą htpasswd, umieść w nim współdzielony kalendarz i dodaj je jako drugie konto CalDAV na każdym urządzeniu. Plik uprawnień Radicale może alternatywnie przyznać nazwanemu użytkownikowi prawa do odczytu i zapisu w kolekcji znajdującej się w ścieżce innego użytkownika, jednak klient, który odczytuje tylko własny zestaw kalendarzy (home set), nigdy go nie wyświetli, dlatego ta metoda sprawdza się w Thunderbirdzie i DAVx⁵, a nie w iOS.

Co stanie się z moimi wydarzeniami, jeśli VPS ulegnie awarii?

W przypadku Radicale magazyn danych to zwykły tekst: jeden plik .ics na wydarzenie w lokalizacji /var/lib/radicale/collections/collection-root/, który można archiwizować za pomocą tar i odczytać przy użyciu less. Przywracanie polega na wypakowaniu danych, chown -R radicale:radicale i uruchomieniu usługi. Każdy zsynchronizowany klient przechowuje również kopię lokalną, więc laptop, który był zsynchronizowany przed awarią, posiada pełną kopię kalendarza.

Czy serwer CalDAV synchronizuje również moje kontakty?

Kontakty wykorzystują CardDAV, pokrewny protokół zdefiniowany w RFC 6352, który przechowuje pliki vCard zamiast wydarzeń. Radicale, Baikal oraz Nextcloud obsługują ten protokół w ramach tego samego konta i tej samej nazwy hosta. W systemie Android aplikacja DAVx⁵ synchronizuje kalendarze i kontakty z jednego konta. W systemie iOS należy dodać drugie konto typu CardDAV z tymi samymi poświadczeniami, dlatego przekierowanie /.well-known/carddav powinno znaleźć się w konfiguracji nginx obok przekierowania dla CalDAV.