Rehberler

Yazan Matt Connor 2026-10-11

VPS Uzerinde Radicale ile CalDAV Takvim Kurulumu

Q: VPS çökerse etkinliklerime ne olur?

Radicale'de veriler düz metin olarak saklanır: /var/lib/radicale/collections/collection-root/ altında her etkinlik için bir .ics dosyası bulunur. Bunları tar ile yedekleyebilir ve less ile okuyabilirsiniz. Geri yükleme işlemi; dosyaları çıkarma, chown -R radicale:radicale ve servisi başlatma adımlarından oluşur. Eşitleme yapan her istemci de yerel bir kopya tutar; bu nedenle çökmeden önce güncel olan bir dizüstü bilgisayar, takviminizin tam bir ikinci kopyasını barındırır.

Google bagimliligini bitirmek icin VPS uzerinde Radicale ile kendi CalDAV sunucunuzu kurun. TLS yapilandirmasi, cihaz senkronizasyonu ve kesif ayarlari dahil tum adimlar.

Ne inşa ediyorsunuz

Kendi kendine barındırılan (self-hosted) bir takvim, kontrolünüz altındaki bir VPS üzerinde, TLS arkasında ve kişi başına bir oturum açma bilgisiyle çalışan bir CalDAV sunucusudur. Cebinizdeki telefon, masanızdaki dizüstü bilgisayar ve partnerinizin dizüstü bilgisayarı aynı etkinlikleri gösterir. Araya hiçbir Google hesabı girmez.

Bu, kendi kendine barındırılan bir rezervasyon sayfasından farklı bir iştir. Rezervasyon sayfası yabancılar içindir: boş zaman dilimlerinizi yayınlar ve birinin bunlardan birini ayırtmasına olanak tanır. Takvim sunucusu ise kendi cihazlarınız içindir: etkinlikleri depolar ve her istemcinin uyum içinde kalmasını sağlar. İnsanlar genellikle her ikisini de çalıştırır; bu durumda rezervasyon aracı, uygunluk durumunu burada oluşturacağınız CalDAV sunucusundan okur.

Kurulum küçüktür. Radicale, tek bir Python paketinden ve yaklaşık on satırlık bir yapılandırmadan oluşur. Kurulumun ilk ayı atlatıp atlatamayacağını belirleyen unsurlar; TLS, keşif (discovery), kullanıcı bazlı koleksiyonlar ve yedeklemelerdir. Aşağıdaki içeriğin büyük bir kısmı bu konulara ayrılmıştır.

CalDAV nedir ve neden önemlidir?

CalDAV, HTTP üzerinden takvim eşitleme protokolüdür. RFC 4791 içerisinde, WebDAV'ın (RFC 4918 ile tanımlanan, HTTP yöntemlerine ek özellikler getiren web tabanlı dağıtık yazma ve sürümleme protokolü) bir uzantısı olarak tanımlanmıştır. Takvim, bir dizin gibi davranan bir koleksiyondur. Her bir etkinlik, bu dizin içindeki bir dosyadır ve e-postalarınızdaki .ics ekleriyle aynı format olan iCalendar metin formatında (RFC 5545) yazılır.

İstemciler, birkaç ek yöntemle birlikte standart HTTP kullanır. PROPFIND, dizinde ne olduğunu ve hangi özelliklere sahip olduğunu sorgular. REPORT, belirli bir tarih aralığındaki tüm etkinlikler gibi filtrelenmiş bir kesit talep eder. PUT bir etkinlik yazar, DELETE ise onu siler. Her etkinlik bir UID satırı taşır; bu tanımlayıcı, iki cihazın aynı etkinliğe baktığını, bir kopyasına bakmadığını doğrulamalarını sağlar.

Taşınabilirlik bu işin kazancıdır ve uğraşmaya değmesinin tek nedeni budur. iOS, macOS, Thunderbird, Evolution ve DAVx⁵ aracılığıyla Android, CalDAV protokolünü destekler. Verileriniz, bugün seçtiğiniz sunucuya bağlı değildir. Dosyaları farklı bir CalDAV sunucusuna taşıyın, istemcileri yeni ana bilgisayar adına yönlendirin; başka hiçbir şeyin değişmediğini göreceksiniz.

CardDAV de benzer bir yapıdadır. Kişiler için aynı mantığı kullanır; RFC 6352 ile tanımlanmıştır ve etkinlikler yerine vCard dosyalarını saklar. Aşağıdaki her sunucu, her iki protokolü de aynı hesap üzerinden sunar; bu nedenle takvim çalıştığında, adres defterini aktif etmek yalnızca bir onay kutusu işlemidir.

Hangi CalDAV sunucusunu çalıştırmalısınız?

Radicale, işini yapan en küçük çözümdür. Python tabanlıdır, veritabanı gerektirmez ve verileri düz dosyalardan oluşan bir klasörde saklar. Bu rehberde Radicale kullanılmaktadır çünkü ev tipi bir takvim sistemi için daha fazlasına ihtiyaç yoktur ve gece saat üçte bir sorun çıkma ihtimali oldukça düşüktür.

Baikal, web tabanlı bir yönetim paneline sahip olan seçenektir. PHP ve sabre/dav kütüphanesi üzerinde çalışır; kullanıcıları ve takvimleri SQLite veya MySQL üzerinde tutar. Komut satırı yerine tarayıcı üzerinden kullanıcı eklemenize olanak tanır. Hesapların sık sık eklenip çıkarıldığı durumlar için bu seçeneği tercih edin.

Nextcloud, takvimin diğer özelliklerin yanında sadece bir parça olduğu durumlar için uygundur. Takvim, kişiler, dosyalar ve mobil uygulama gibi özelliklere sahip olursunuz; ancak bunun karşılığında PHP-FPM, bir veritabanı ve arka plan iş çalıştırıcısı (job runner) yönetmeniz gerekir. Eğer bu gereksinimler ihtiyaçlarınıza göre ağır geliyorsa, daha hafif Nextcloud alternatifleri bu açığı kapatır ve kendi kendine barındırılan dosya eşitleme çözümleri, insanların Nextcloud kurma nedenlerinin diğer yarısını karşılar.

DAViCal, uzun süredir var olan PostgreSQL tabanlı seçenektir. Yalnızca halihazırda PostgreSQL kullanıyorsanız ve takvim verilerinin de burada tutulmasını istiyorsanız değerlendirmeye değerdir.

Ubuntu 24.04 uzerine Radicale kurulumu

8 Ekim 2026 tarihinde etiketlenen Radicale 3.8.3, 11 Ekim 2026 itibarıyla güncel sürümdür. Yazılımı, aşağıda belirtilen parola dosyasının gerektirdiği bcrypt eklentisiyle birlikte kendi sanal ortamına kurun.

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]'

Sanal ortam kullanımı bir tercih değil, zorunluluktur. Sistem Python'ı üzerine sudo pip install radicale ile kurulum yapmak error: externally-managed-environment hatasıyla sonuçlanır; çünkü Ubuntu, Python paketlerini apt yönetimine tabi tutar ve pip'in paketlenmiş dosyaların üzerine yazmasını engeller.

/etc/radicale/config dosyasını oluşturun:

[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, bilinçli olarak loopback arayüzüne bağlanır. TLS termination işlemi nginx tarafından yapılır ve trafik bu porta yönlendirilir; böylece Radicale doğrudan internete açık kalmaz. 0.0.0.0:5232 yapılandırmasındaki upstream örneği, parola kabul eden şifrelenmemiş bir servis yayınlar; bu, burada dikkat edilmesi gereken tek kritik hatadır.

Şimdi hesapları oluşturalım. -B, bcrypt algoritmasını seçer. Radicale, yukarıdaki radicale[bcrypt] kurulumundan gelen bcrypt modülü mevcut olduğunda bu dosyayı htpasswd_encryption = autodetect ile okur:

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 dosyayı oluşturur ve içindeki mevcut verileri siler. Bu komutu yalnızca ilk kullanıcı için kullanın. Aylar sonra htpasswd -B -c komutunu tekrar çalıştırmak, ilk kullanıcıdan sonra eklenen tüm hesapları siler. Bu durumun belirtisi, bir kullanıcının sorunsuz senkronizasyon yaparken diğerlerinin sürekli parola istemiyle karşılaşmasıdır. SHA-512 crypt (-5) burada bir seçenek değildir: htpasswd, SHA-2 desteğini Apache 2.4.59 ile kazanmıştır; Ubuntu 24.04 ise apache2-utils 2.4.58 sürümüyle gelir ve bu sürümdeki htpasswd komutunda -5 bayrağı bulunmaz.

Radicale dokümantasyonundaki birim dosyasından uyarlanan /etc/systemd/system/radicale.service dosyasını oluşturun:

[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/

Başarılı bir sonuç, WWW-Authenticate başlığına sahip 401 Unauthorized çıktısıdır: servis dinleme modundadır ve kimlik doğrulama aktiftir. Connection refused, ilgili adreste hiçbir servisin dinleme yapmadığı anlamına gelir; bu genellikle servisin başlatılamadığı veya başlatıldıktan sonra kapandığı durumlarda görülür. journalctl -u radicale -n 50 ise servisin reddettiği yapılandırma seçeneğini belirtir. ProtectSystem=strict, dosya sistemini bu servis için salt okunur olarak bağlar; bu nedenle ReadWritePaths=/var/lib/radicale/ satırı, servisin veri kaydetmesine izin veren tek satırdır. Bu satırı kaldırırsanız okuma işlemleri çalışmaya devam eder ancak tüm yazma işlemleri başarısız olur.

TLS isteğe bağlı değildir, çünkü istemciler düz metni reddeder

Bu kurulum, Radicale'in kabul ettiği tek şema olan HTTP Basic ile kimlik doğrulaması yapar ve Basic, her istekte user:password base64 kodlu veri gönderir. Base64 bir şifreleme değil, kodlama biçimidir. Düz HTTP üzerinden parola, telefon ile sunucu arasındaki tüm ağlara gün boyu, her eşitlemede gönderilir.

İstemciler bunu sizin yerinize zorunlu tutar. Radicale belgeleri, macOS Calendar.app uygulamasının güvenli olmayan HTTP üzerinden kimlik bilgilerini göndermeyi sessizce reddedebileceğini ve iOS'in de aynı şekilde davrandığını belirtir. Hesap yapılandırılmış görünür ancak hiçbir hata mesajı vermeden eşitleme yapmaz.

Sertifika yetkilisi kontrol edeceği için önce cal.example.com için bir A kaydını VPS'e yönlendirin. Ardından /etc/nginx/sites-available/cal.example.com dosyasını oluşturun:

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/; }
}

Dört proxy başlığı satırı Radicale belgelerinden alınmıştır. Bunları olduğu gibi koruyun.

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 komutu syntax is ok ve test is successful çıktılarını verir. Yalnızca bu çıktıları aldıktan sonra yeniden yükleme yapın; çünkü hatalı bir dosya ile yapılan yeniden yükleme, eski yapılandırmayı çalışır durumda bırakır ve hatayı bir sonraki yeniden başlatmaya kadar gizler. Certbot site dosyasını yerinde düzenler: sertifikayı kurar, bloğu 443 numaralı porta geçirir ve 80 numaralı porttan yönlendirme ekler. Son curl komutu parola ister ve Radicale'in kendi web arayüzü olan 200 sonucunu döndürmelidir. Bir 502 Bad Gateway hatası, nginx'in çalıştığını ancak 5232 numaralı porttan geçerli bir yanıt alamadığını gösterir; bunun yaygın nedeni Radicale'in o portta dinleme yapmıyor olmasıdır.

Hesap ekleme işlemi telefonda neden başarısız oluyor?

Bunun nedeni keşif sürecidir. RFC 6764, bir istemcinin ana makine adını nasıl takvim URL'sine dönüştürdüğünü açıklar. İstemci önce bir _caldavs._tcp SRV kaydı arar, ardından https://cal.example.com/.well-known/caldav isteğinde bulunur ve DAV kök dizinine bir yönlendirme bekler. Buradan current-user-principal adresini, ardından ilgili asıl kullanıcının calendar-home-set adresini ister ve ancak o zaman takvimlerinizi görür. Telefon size sunucu için tek bir alan sunduğundan, her adımın kullanıcı müdahalesi olmadan çalışması gerekir.

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

Sağlıklı bir yanıt, location: https://cal.example.com/ başlığına sahip bir HTTP/2 301 durum kodudur. Buradaki bir 404 hatası, aynı ağdaki Thunderbird çalışırken iOS'in hesap bilgilerini doğrulayamamasının yaygın bir nedenidir: Thunderbird sizin girdiğiniz tam URL'yi kullanır, bu nedenle yönlendirmeye ihtiyaç duymaz.

Yönlendirme hedefi sunucuya bağlıdır. Sitenin kök dizininde sunulan Radicale, / adresine yönlendirme yapar ve istek kendisine ulaştığında Radicale bu yola kendisi 301 yanıtı verir; bu nedenle nginx kuralları yönlendirmeyi oluşturmak yerine açık hale getirir. Baikal, /dav.php adresine 308 durumuyla yönlendiren örnek kurallar ile gelir. Nextcloud ise /remote.php/dav/ adresine yönlendirme yapar.

Takvimleri oluşturun ve birini partnerinizle paylaşın

Birçok istemci takvim oluşturamaz, yalnızca mevcut bir takvime abone olabilir. Bir tarayıcıda https://cal.example.com/ adresini açın, you olarak giriş yapın ve takvimi orada oluşturun. Disk üzerinde bu takvim, klasör adı için oluşturulan bir tanımlayıcı ile /var/lib/radicale/collections/collection-root/you/ altında yer alır.

Radicale'in varsayılan haklar arka ucu owner_only'dur: kimliği doğrulanmış bir hesap, /USERNAME/ altındaki kendi koleksiyonlarını okur ve yazar, başka hiçbir şeye erişemez. Çoğu hane halkı için bu doğru ayardır ve bir takvimi paylaşmanın en basit yolu üçüncü bir hesap kullanmaktır. household hesabını htpasswd ile oluşturun, paylaşılan takvimi bu giriş altında yapın ve her cihazda ikinci bir CalDAV hesabı olarak ekleyin. Takvim bu hesabın kendi dizininde yer aldığı için iOS dahil her istemcide çalışır.

Daha hassas bir kontrol istediğinizde, kural tabanlı haklara geçiş yapın. /etc/radicale/config dosyasına şunu ekleyin:

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

Ardından, Radicale belgelerindeki örneği temel alarak /etc/radicale/rights dosyasını düzenleyin:

[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

Büyük ve küçük harfler farklı anlamlara gelir. R ve W, takvim veya adres defteri olmayan koleksiyonları okur ve yazar; bu, bir ana (principal) klasörün işlevidir. r ve w ise takvimlerin kendisini okur ve yazar. Bu tanımlayıcıyı, yukarıdaki depolama yolunda bulunan takviminizin gerçek klasör adıyla değiştirin.

Dürüst bir sınırlama: Yalnızca takvim ana dizinini okuyan bir istemci, başka bir kullanıcının yolu altında bulunan bir takvimi görüntüleyemez; çünkü keşif süreci o yola hiçbir zaman girmez. Thunderbird ve DAVx⁵, tam URL ile bu takvimi ekleyebilir. iOS bunu yapamaz; bu nedenle paylaşılan hesap modeli her zaman çalışan yöntemdir.

İstemcileri yapılandırın, çünkü self-hosted takvimlerin başarısız olduğu nokta burasıdır

iPhone ve iPad. Ayarlar'ı, ardından Takvim'i (güncel iOS sürümlerinde Uygulamalar altında listelenir), Takvim Hesapları'nı, Hesap Ekle'yi, Diğer'i ve CalDAV Hesabı Ekle'yi açın. Sunucu kısmına cal.example.com yazın, ardından kullanıcı adı ve parolanızı girin. Açıklama yalnızca bir etikettir. Kaydetmeyi reddederse hesabı tekrar açın: gelişmiş görünümde SSL Kullan, port ve tam hesap URL'si seçenekleri görünür; URL'yi buraya yapıştırmak keşif sürecini tamamen atlamanızı sağlar.

Android. Yerleşik bir CalDAV istemcisi bulunmaz. F-Droid veya Google Play üzerinden DAVx⁵ uygulamasını yükleyin, https://cal.example.com/ temel URL'sini ve kullanıcı adınızı kullanarak bir hesap ekleyin, ardından istediğiniz takvimleri işaretleyin. DAVx⁵ verileri Android takvim sağlayıcısına yazar, bu sayede etkinlikler halihazırda kullandığınız herhangi bir takvim uygulamasında görünür.

Thunderbird. Yeni Takvim, Ağ Üzerinde seçeneğini belirleyin, ardından kullanıcı adınızı ve https://cal.example.com/ konumunu girin. Bulunan öğeleri listeleyecek ve hangi takvimlerin ekleneceğini soracaktır.

macOS. Sistem Ayarları, İnternet Hesapları, Diğer Hesap Ekle, CalDAV yolunu izleyin, Hesap Türü'nü Manuel olarak ayarlayın, ardından aynı kullanıcı adı, parola ve sunucu adresini girin.

CalDAV bir yoklama (polling) protokolüdür. Spesifikasyonda anlık bildirim (push) özelliği yoktur; bu nedenle dizüstü bilgisayarda eklediğiniz bir etkinlik, telefona aynı saniyede değil, bir sonraki eşitleme sırasında ulaşır. Her istemcide kabul edilebilir bir aralık belirleyin ve telefonda daha kısa bir aralığın pil tüketimini artıracağını unutmayın.

Depoyu yedekleme, sadece dosyalardan ibarettir

Radicale altında takviminiz, her etkinlik için bir dosya ve her koleksiyon için küçük bir özellik dosyasından oluşan .ics dosyaları dizinidir. Bir dizini kopyalayan her işlem onu yedekler ve gerçek etkinlikleri içerdiğini doğrulamak için bir yedeği less ile açabilirsiniz. Bu, okuyamayacağınız bir veritabanı dökümüne kıyasla gerçek bir avantajdır.

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

Arşivleme işleminin sürdüğü birkaç saniye boyunca servisi durdurun; böylece dosyalar okunurken hiçbir istemci yazma işleminin ortasında kalmaz. Arşiv dosyasını daha sonra sunucudan dışarı kopyalayın, çünkü aynı VPS üzerindeki bir yedek, hazırlık yaptığınız arıza durumunda hayatta kalamaz. Geri yükleme işlemi bunun tersidir: arşivden çıkarın, sudo chown -R radicale:radicale /var/lib/radicale/collections yapın ve servisi başlatın. Her istemci de takvimlerinin yerel bir kopyasını tutar; bu nedenle arızadan beri eşitleme yapmamış bir dizüstü bilgisayar, verilerinizin ikinci bir kopyası niteliğindedir.

Baikal mı Nextcloud mu daha uygun

Baikal 0.12.1, 5 Ağustos 2026 tarihinde yayınlanmıştır ve PHP 8.2 veya daha yeni bir sürüm gerektirir. Yazılımı web kök dizininin dışına açın ve yalnızca html dizinini dış dünyaya açın:

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

Bu iki dizin, web sunucusunun yazma iznine sahip olduğu tek yerdir; dolayısıyla başka hiçbir dizinin yazılabilir olması gerekmez. Nginx sunucu bloğunuz içerisinde, Baikal'a özgü kısımlar şunlardır:

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; }

Nginx yapılandırmasını yeniden yükleyin, siteyi bir tarayıcıda açın; kurulum sihirbazı yönetici hesabını ve SQLite veritabanını oluşturacaktır. İstemci kurulumu Radicale ile aynıdır; sunucu adresi olarak https://cal.example.com/ kullanılır, çünkü "well-known" kuralı keşif isteğini /dav.php adresine yönlendirir.

Nextcloud, yalnızca dosyalarınızı ve telefon uygulamanızı aynı oturum bilgileriyle kullanmak istiyorsanız tercih edilmelidir. DAV kök dizini /remote.php/dav/ şeklindedir ve aynı keşif kuralları burada da geçerlidir. Bu servislerin herhangi biri için, servisi bir container içerisinde çalıştırmak PHP sürümlerini ana makinenizden (host) uzak tutmanızı sağlar: VPS üzerinde Docker Compose rehberi, compose dosyasını ve önündeki reverse proxy yapılandırmasını ele alır; 2026 yılında neler self-host edilmeye değer makalesi ise bu yolda ne kadar ilerlemek istediğinize karar vermek için uygun bir başlangıç noktasıdır.

Hata modları ve karşılaşacağınız dizgeler

Her eşitleme 401 hatası döndürüyor. Parola dosyası ya ikinci bir htpasswd -c işlemine kurban gitmiştir ya da radicale kullanıcısı dosyayı okuyamıyordur. sudo -u radicale cat /etc/radicale/users ile kontrol edin; bir "permission denied" hatası alıyorsanız sorun budur ve çözümü radicale grubuna atayıp 640 modunu vermektir. Radicale varsayılan olarak her başarısız girişten sonra bir saniye bekler; bu nedenle eski parolaya sahip bir istemci reddedilmiş gibi değil, yavaş çalışıyor gibi görünür.

nginx, PROPFIND isteğine 405 yanıtı veriyor. URL statik bir dosya olarak sunuluyordur, bu yüzden WebDAV metodu Radicale'e ulaşmıyordur. Uç noktayı doğrudan test edin:

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

Çalışan bir DAV koleksiyonu 207 Multi-Status yanıtını verir. Başka bir yanıt, isteğin web sunucusunda takıldığını gösterir.

Telefon hesabı doğrulayamıyor ancak tarayıcıda sorun yok. İki yaygın neden vardır. Yukarıdaki curl komutuyla test edilen "well-known" yönlendirmesi eksiktir. Ya da sertifika zinciri tam değildir; tarayıcılar eksik ara sertifikayı kendileri çekerek bunu telafi ederken iOS bunu yapmaz. Kabuk üzerinden kontrol edin:

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

Verify return code: 0 (ok) dizgesini arayın. Eğer başarısız olursa, nginx yapılandırması fullchain.pem yerine cert.pem dosyasına işaret ediyordur.

İçe aktarma işleminden sonra yinelenen etkinlikler oluşuyor. Her etkinlik bir UID taşır ve istemciler bunu kimlik olarak kabul eder. Tanımlayıcıları yeniden oluşturan bir araçla aynı dosyayı iki kez içe aktarırsanız, hiçbir şekilde birleştirilemeyecek iki ayrı etkinlik oluşur. Bir cihazdaki fazladan kopyaları silin ve silme işleminin eşitlenmesini bekleyin.

Yeniden başlatma sonrasında her şey çalışmayı durduruyor. Servis elle başlatılmıştır. sudo systemctl is-enabled radicale komutu disabled çıktısını veriyorsa, sudo systemctl enable --now radicale komutu sorunu kalıcı olarak çözer.

FAQ

Kendi barındırdığım CalDAV sunucum için gerçekten TLS gerekli mi?

Evet. Radicale, kimlik doğrulaması için HTTP Basic kullanır; bu nedenle parola her istekte base64 kodlanmış olarak iletilir ve base64 kolayca çözülebilir. İstemciler de bunu zorunlu tutar: macOS Calendar.app, güvenli olmayan HTTP üzerinden kimlik bilgilerini göndermeyi sessizce reddedebilir; iOS da aynı şekilde davranır, bu yüzden hesap kaydedilmiş gibi görünür ancak asla eşitleme yapmaz. sudo certbot --nginx -d cal.example.com tüm süreci kapsar.

Thunderbird çalışırken telefonum neden hesabı ekleyemiyor?

Thunderbird, girdiğiniz tam URL'yi kullanır. Telefon ise size tek bir sunucu alanı sunduğundan RFC 6764 keşif mekanizmasına güvenir; SRV kaydı yoksa https://cal.example.com/.well-known/caldav adresine istek atar ve DAV kök dizinine bir yönlendirme bekler. Eğer bu istek 404 hatası döndürürse, telefon genellikle hesabın doğrulanamadığını bildirir. Nginx yapılandırmanıza location = /.well-known/caldav { return 301 https://$host/; } ekleyin, ardından curl -sI https://cal.example.com/.well-known/caldav ile 301 yönlendirmesi ve location başlığı aldığınızı doğrulayın. iOS gelişmiş ayarlarında tam hesap URL'sini yapıştırmak, keşif sürecini tamamen atlar.

İki kişi aynı takvimi paylaşabilir mi?

Evet, bunun güvenilir yolu paylaşımlı bir oturum kullanmaktır. htpasswd ile üçüncü bir hesap oluşturun, paylaşılan takvimi bu hesabın altına yerleştirin ve her cihazda ikinci bir CalDAV hesabı olarak ekleyin. Radicale'in yetki dosyası, bir kullanıcıya başka bir kullanıcının dizini altındaki bir koleksiyon üzerinde okuma ve yazma izni verebilir; ancak yalnızca kendi takvim dizinini okuyan bir istemci bunu asla görüntülemeyecektir. Bu yöntem iOS yerine Thunderbird ve DAVx⁵ için daha uygundur.

VPS çökerse etkinliklerime ne olur?

Radicale'de veriler düz metin olarak saklanır: /var/lib/radicale/collections/collection-root/ altında her etkinlik için bir .ics dosyası bulunur. Bunları tar ile yedekleyebilir ve less ile okuyabilirsiniz. Geri yükleme işlemi; dosyaları çıkarma, chown -R radicale:radicale ve servisi başlatma adımlarından oluşur. Eşitleme yapan her istemci de yerel bir kopya tutar; bu nedenle çökmeden önce güncel olan bir dizüstü bilgisayar, takviminizin tam bir ikinci kopyasını barındırır.

CalDAV sunucusu kişilerimi de eşitler mi?

Kişiler, etkinlikler yerine vCard dosyalarını depolayan ve RFC 6352 ile tanımlanan kardeş protokol CardDAV'ı kullanır. Radicale, Baikal ve Nextcloud'un tümü bu servisi aynı hesaptan ve aynı ana makine adından sunar. Android'de DAVx⁵, takvimleri ve kişileri tek bir hesaptan eşitler. iOS'ta ise aynı kimlik bilgileriyle CardDAV türünde ikinci bir hesap eklersiniz; bu yüzden /.well-known/carddav yönlendirmesi, nginx yapılandırmanızda CalDAV yönlendirmesinin yanında yer almalıdır.

Bu yazı işinize yaradı mı?

#caldav#calendar#radicale#self-hosting#sync