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

W sierpniu 2026 roku najnowszą wersją Radicale była 3.5.10. Należy zainstalować ją w odizolowanym środowisku wirtualnym.

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

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

Wpisz /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 nasłuchuje tylko na interfejsie loopback. Nginx wykonuje terminację TLS i przekazuje ruch na ten port, dzięki czemu Radicale nigdy nie jest bezpośrednio wystawione na działanie Internetu. Przykład upstream dla 0.0.0.0:5232 publikuje niezaszyfrowaną usługę akceptującą hasła, co stanowi krytyczny błąd bezpieczeństwa.

Teraz konfiguracja kont. -5 wybiera algorytm SHA-512 crypt, który Radicale odczytuje za pomocą htpasswd_encryption = autodetect bez potrzeby instalacji dodatkowych modułów:

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

-c tworzy plik i nadpisuje jego dotychczasową zawartość. Należy go użyć tylko dla pierwszego użytkownika. Uruchomienie htpasswd -5 -c po kilku miesiącach usunie wszystkie konta dodane po pierwszym użytkowniku. Objawem tego błędu jest sytuacja, w której jedna osoba synchronizuje dane poprawnie, a pozostali użytkownicy otrzymują ciągłe żądanie podania hasła. Algorytm Bcrypt również działa, ale wymaga dodatkowej instalacji radicale[bcrypt].

Utwórz /etc/systemd/system/radicale.service, dostosowując plik jednostki na podstawie 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/

Prawidłowy wynik to 401 Unauthorized z nagłówkiem WWW-Authenticate: usługa nasłuchuje, a uwierzytelnianie jest włączone. Connection refused oznacza, że usługa nie została uruchomiona, a journalctl -u radicale -n 50 wskazuje nazwę odrzuconej opcji. ProtectSystem=strict montuje system plików w trybie tylko do odczytu dla tej usługi, dlatego ReadWritePaths=/var/lib/radicale/ jest linią, która umożliwia zapisywanie zdarzeń. Usunięcie tej linii spowoduje, że odczyt będzie działał, ale każda próba zapisu zakończy się niepowodzeniem.

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

CalDAV uwierzytelnia się za pomocą HTTP Basic, co oznacza przesyłanie user:password zakodowanego w base64 przy każdym żądaniu. Base64 to kodowanie, a nie szyfrowanie. Przesyłając dane przez zwykłe HTTP, udostępniasz hasło każdej sieci znajdującej się między telefonem a serwerem, przez cały czas trwania każdej synchronizacji.

Klienci wymuszają to zabezpieczenie za Ciebie. Dokumentacja Radicale wskazuje, że macOS Calendar.app może po cichu odmawiać wysyłania poświadczeń przez niezabezpieczone HTTP, a iOS zachowuje się w ten sam sposób. Konto wygląda na skonfigurowane, ale po prostu nigdy się nie synchronizuje, 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. Pozostaw 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 uzyskaniu tego wyniku, 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. Ostateczne polecenie curl prosi o hasło i powinno zwrócić 200, czyli interfejs WWW programu Radicale. Błąd 502 Bad Gateway oznacza, że nginx działa, ale Radicale nie nasłuchuje na porcie 5232.

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 SRV _caldavs._tcp, następnie wysyła zapytanie https://cal.example.com/.well-known/caldav i oczekuje przekierowania do katalogu głównego DAV. Stamtąd pobiera current-user-principal, a następnie calendar-home-set dla 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ź to HTTP/2 301 z nagłówkiem location: https://cal.example.com/. Błąd 404 w tym miejscu jest powodem, dla którego 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 /. 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 serwera CalDAV hostowanego samodzielnie?

Tak. CalDAV uwierzytelnia się za pomocą HTTP Basic, więc hasło jest przesyłane w kodowaniu base64 przy każdym żądaniu, a base64 można łatwo odwrócić. Klienci również wymuszają to zabezpieczenie: macOS Calendar.app może bez ostrzeżenia odmówić wysłania poświadczeń przez niezabezpieczony protokół HTTP, a system iOS zachowuje się identycznie, przez co konto wydaje się zapisane, ale nigdy nie synchronizuje danych. sudo certbot --nginx -d cal.example.com to niezbędne minimum.

Dlaczego telefon nie może dodać konta, mimo że Thunderbird działa?

Thunderbird używa pełnego adresu URL, który został wprowadzony. Telefon udostępnia tylko jedno pole serwera, więc postępuje zgodnie z mechanizmem wykrywania RFC 6764: wysyła żądanie https://cal.example.com/.well-known/caldav i oczekuje przekierowania do katalogu głównego DAV. Bez tego przekierowania telefon otrzymuje błąd 404 i zgłasza brak możliwości weryfikacji konta. Dodaj location = /.well-known/caldav { return 301 https://$host/; } do konfiguracji nginx, a następnie sprawdź za pomocą curl -sI https://cal.example.com/.well-known/caldav, czy otrzymujesz kod 301 oraz nagłówek location.

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

Tak, a 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 pozwala również nadać konkretnemu użytkownikowi prawa odczytu i zapisu do kolekcji w ścieżce innego użytkownika, jednak klient, który odczytuje tylko swój własny zestaw kalendarzy, nigdy go nie wyświetli, dlatego to rozwiązanie sprawdza się w Thunderbird i DAVx⁵, a nie w systemie iOS.

Co stanie się z moimi wydarzeniami w przypadku awarii VPS?

W przypadku Radicale dane są przechowywane w postaci zwykłego tekstu: jeden plik .ics na wydarzenie w katalogu /var/lib/radicale/collections/collection-root/, który można archiwizować za pomocą tar i odczytać narzędziem less. Przywracanie polega na rozpakowaniu 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 korzystają z protokołu CardDAV, pokrewnego standardu zdefiniowanego w RFC 6352, który przechowuje pliki vCard zamiast wydarzeń. Radicale, Baikal oraz Nextcloud obsługują ten protokół w ramach tego samego konta i pod tą samą nazwą 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.