Google शिवाय VPS वर CalDAV calendar कसा चालवायचा

तुम्ही काय तयार करणार आहात

Self-hosted calendar म्हणजे तुम्ही नियंत्रित करत असलेल्या VPS वर TLS मागे चालणारा एक CalDAV server आणि प्रत्येक व्यक्तीसाठी एक login. तुमच्या हातातील phone आणि तुमच्या desk वरील laptop मध्ये समान events दिसतात. तुमच्या partner च्या laptop मध्येही तेच events दिसतात. मध्ये कोणतेही Google account नसते.

हे self-hosted booking page तयार करण्यापेक्षा वेगळे काम आहे. Booking page अनोळखी लोकांसाठी असते: ते तुमचे मोकळे वेळापत्रक प्रकाशित करते आणि कोणालाही एक वेळ निवडण्याची अनुमती देते. Calendar server तुमच्या स्वतःच्या devices साठी असतो: तो events साठवतो आणि प्रत्येक client मधील माहिती समान ठेवतो. अनेक जण दोन्ही वापरतात. त्यानंतर booking tool त्याची availability तुम्ही येथे तयार केलेल्या CalDAV server कडून वाचते.

ही installation लहान आहे. Radicale हे एक Python package आहे आणि configuration सुमारे दहा ओळींची आहे. ही setup पहिला महिना सुरळीत चालेल की नाही हे TLS, discovery, प्रत्येक user साठी collections आणि backups यावर ठरते. खालील मजकुरात यांनाच सर्वाधिक जागा दिली आहे.

CalDAV म्हणजे काय आणि ते महत्त्वाचे का आहे?

CalDAV म्हणजे HTTP वर आधारित calendar sync. RFC 4791 मध्ये WebDAV साठीच्या extensions म्हणून त्याची व्याख्या केली आहे. WebDAV म्हणजे web distributed authoring and versioning; RFC 4918 मध्ये परिभाषित केलेल्या अतिरिक्त HTTP methods चा हा संच आहे. Calendar हा एका directory प्रमाणे कार्य करणारा collection असतो. त्यातील प्रत्येक event ही एक file असते. ती iCalendar text format (RFC 5545) मध्ये लिहिलेली असते. तुमच्या mail मधील .ics attachments साठीही हेच format वापरले जाते.

Clients काही अतिरिक्त methods सह सामान्य HTTP वापरतात. PROPFIND येथे काय उपलब्ध आहे आणि त्याचे कोणते properties आहेत हे विचारते. REPORT filtered slice मागते, जसे एखाद्या date range मधील प्रत्येक event. PUT एक event लिहिते आणि DELETE तो काढून टाकते. प्रत्येक event मध्ये UID line असते. दोन devices एकाच event कडे पाहत आहेत, त्याची copy नाही, हे ठरवण्यासाठी हा identifier वापरला जातो.

याचा मुख्य लाभ portability हा आहे आणि CalDAV वापरण्याचे तेच संपूर्ण कारण आहे. iOS, macOS, Thunderbird, Evolution आणि DAVx⁵ द्वारे Android हे सर्व CalDAV ला support करतात. तुमचा data तुम्ही आज निवडलेल्या server शी बांधलेला राहत नाही. Files वेगळ्या CalDAV server वर हलवा, clients मध्ये नवीन hostname द्या आणि इतर कोणताही बदल करावा लागत नाही.

CardDAV देखील याच्यासोबत उपलब्ध असते. Contacts साठी हीच संकल्पना वापरली जाते. ती RFC 6352 मध्ये परिभाषित केली आहे आणि events ऐवजी vCard files साठवते. खालील प्रत्येक server त्याच account मधून दोन्ही protocols उपलब्ध करून देतो. त्यामुळे calendar कार्यरत झाल्यावर address book साठी फक्त checkbox निवडावे लागते.

कोणता CalDAV server चालवावा?

Radicale हा काम करणारा सर्वात लहान पर्याय आहे. तो Python वर चालतो, त्याला database लागत नाही आणि data store साध्या files असलेल्या एका folder मध्ये असतो. या मार्गदर्शकात तो वापरला आहे, कारण घरगुती calendar साठी यापेक्षा अधिक काही आवश्यक नाही. तसेच पहाटे तीन वाजता बिघाड होण्याची शक्यता कमी असते.

Baikal हा web admin panel असलेला पर्याय आहे. तो PHP आणि sabre/dav library वर चालतो. तो users आणि calendars SQLite किंवा MySQL मध्ये ठेवतो. त्यामुळे command line ऐवजी browser मधून person जोडता येतो. Accounts वारंवार जोडले किंवा काढले जात असतील, तर हा पर्याय निवडा.

Nextcloud योग्य आहे, जेव्हा calendar हा अनेक features पैकी एक feature असतो. तुम्हाला calendar, contacts, files आणि mobile app मिळतात. मात्र त्यासाठी PHP-FPM, database आणि background job runner आवश्यक असतात. तुमच्या प्रत्यक्ष गरजेसाठी हे जड वाटत असेल, तर हलके Nextcloud पर्याय हा तडजोडीचा भाग स्पष्ट करतात. तसेच self-hosted file sync मध्ये लोक Nextcloud install करण्यामागील दुसऱ्या प्रमुख गरजेचा पर्याय दिला आहे.

DAViCal हा दीर्घकाळापासून उपलब्ध असलेला PostgreSQL पर्याय आहे. तुम्ही आधीच PostgreSQL चालवत असाल आणि calendar data त्यात ठेवायचा असेल, तरच त्याचा विचार करा.

Ubuntu 24.04 वर Radicale install करा

8 October 2026 रोजी tag केलेले Radicale 3.8.3 हे 11 October 2026 रोजीचे current release आहे. ते स्वतंत्र virtual environment मध्ये install करा. खालील password file साठी आवश्यक असलेला bcrypt extra देखील install करा.

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

virtual environment हा केवळ शैलीचा पर्याय नाही. system Python मध्ये sudo pip install radicale केल्यास error: externally-managed-environment येते, कारण Ubuntu त्याच्या Python ला apt च्या मालकीचे चिन्हांकित करते. त्यामुळे pip packaged files overwrite करू शकत नाही.

/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 जाणीवपूर्वक loopback वर bind होते. nginx TLS termination करते आणि विनंत्या त्या port कडे forward करते. त्यामुळे Radicale थेट internet समोर येत नाही. 0.0.0.0:5232 चे upstream example passwords स्वीकारणारी unencrypted service प्रकाशित करते. येथे महत्त्वाची चूक हीच आहे.

आता accounts तयार करा. -B bcrypt निवडते. radicale[bcrypt] install मधील bcrypt module उपलब्ध असल्यावर Radicale ते htpasswd_encryption = autodetect द्वारे वाचते:

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 file तयार करते आणि त्यातील आधीची संपूर्ण सामग्री truncate करते. ती फक्त पहिल्या user साठी वापरा. काही महिन्यांनी पुन्हा htpasswd -B -c चालवल्यास पहिल्या user नंतर जोडलेले सर्व accounts हटतात. त्याचे लक्षण म्हणजे एका व्यक्तीचे syncing व्यवस्थित होते, तर इतर सर्वांना न संपणारा password prompt दिसतो. SHA-512 crypt (-5) येथे पर्याय नाही. Apache 2.4.59 मध्ये htpasswd ला SHA-2 support मिळाले, परंतु Ubuntu 24.04 मध्ये apache2-utils 2.4.58 येते आणि त्याच्या htpasswd मध्ये -5 flag नाही.

Radicale documentation मधील unit वर आधारित /etc/systemd/system/radicale.service तयार करा:

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

योग्य output म्हणजे 401 Unauthorized आणि WWW-Authenticate header. याचा अर्थ service listening आहे आणि authentication सुरू आहे. Connection refused म्हणजे त्या address वर काहीही listening नाही. सामान्यतः service सुरू होण्यात अपयशी ठरली असते किंवा त्यानंतर exit झालेली असते. journalctl -u radicale -n 50 ने service ने नाकारलेला option दाखवला जातो. ProtectSystem=strict या service साठी filesystem read only mount करते. त्यामुळे ReadWritePaths=/var/lib/radicale/ हीच अशी line आहे जी event save करण्याची परवानगी देते. ती line काढल्यास reads सुरू राहतात, पण प्रत्येक write अयशस्वी होते.

TLS ऐच्छिक नाही, कारण clients plaintext नाकारतात

या सेटअपमध्ये HTTP Basic वापरले आहे. Radicale स्वीकारत असलेली ही एकमेव authentication scheme आहे. Basic प्रत्येक request मध्ये user:password ला base64 encoded स्वरूपात पाठवते. Base64 हे encoding आहे; encryption नाही. Plain HTTP वापरल्यास फोन आणि server यांच्या दरम्यान असलेल्या प्रत्येक network ला password दिसतो. हे प्रत्येक sync वेळी घडते.

Clients ही अट आपोआप लागू करतात. Radicale documentation नुसार, macOS Calendar.app unsecured HTTP वर credentials पाठवण्यास शांतपणे नकार देऊ शकतो. iOS देखील तसेच वागते. Account configured दिसतो, पण तो कधीही sync होत नाही. वाचता येईल अशी कोणतीही error दिसत नाही.

प्रथम cal.example.com साठी A record VPS कडे निर्देशित करा, कारण certificate authority त्याची तपासणी करते. त्यानंतर /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/; }
}

Proxy header च्या या चार lines Radicale documentation मधून घेतल्या आहेत. त्या जशा आहेत तशाच ठेवा.

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 हे syntax is ok आणि test is successful print करते. ते तसे print झाल्यानंतरच reload करा. Broken file सह केलेल्या reload मुळे जुने config चालू राहते आणि चूक पुढील restart पर्यंत लपून राहते. Certbot site file मध्ये थेट बदल करते: ते certificate install करते, block port 443 वर बदलते आणि port 80 वरून redirect जोडते. शेवटचा curl password साठी prompt दाखवतो आणि त्याने 200 return केले पाहिजे. हे Radicale चे स्वतःचे web interface आहे. 502 Bad Gateway याचा अर्थ nginx चालू आहे, पण port 5232 कडून त्याला valid answer मिळाले नाही. याचे नेहमीचे कारण म्हणजे Radicale त्या port वर listening करत नाही.

फोनवर खाते जोडणे का अयशस्वी होते?

कारण discovery प्रक्रिया. RFC 6764 मध्ये client hostname चे calendar URL मध्ये रूपांतर कसे करतो हे वर्णन केले आहे. तो _caldavs._tcp SRV record शोधतो, त्यानंतर https://cal.example.com/.well-known/caldav साठी request पाठवतो आणि DAV root कडे redirect अपेक्षित ठेवतो. तेथून तो current-user-principal साठी आणि नंतर त्या principal च्या calendar-home-set साठी request पाठवतो. त्यानंतरच त्याला तुमची calendars दिसतात. फोनवर server साठी एकच field असतो. त्यामुळे प्रत्येक पायरी unattended पद्धतीने यशस्वी झाली पाहिजे.

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

यशस्वी प्रतिसाद म्हणजे HTTP/2 301 आणि त्यामध्ये location: https://cal.example.com/ header असतो. तेथे 404 असणे हे iOS ला account information पडताळता येत नसल्याचे एक सामान्य कारण आहे, जरी त्याच network वरील Thunderbird कार्यरत असला तरी. Thunderbird तुम्ही टाइप केलेला पूर्ण URL वापरतो. त्यामुळे त्याला redirect ची आवश्यकता नसते.

Redirect target server वर अवलंबून असतो. Site च्या root वर Radicale सेवा दिली असल्यास ती / कडे redirect करते. Request Radicale पर्यंत पोहोचल्यावर Radicale स्वतः त्या path साठी 301 प्रतिसाद देते. त्यामुळे nginx rules तो redirect तयार न करता स्पष्टपणे लागू करतात. Baikal मध्ये /dav.php कडे status 308 सह redirect करणारे sample rules दिलेले असतात. Nextcloud /remote.php/dav/ कडे redirect करते.

कॅलेंडर तयार करा आणि त्यापैकी एक तुमच्या जोडीदारासोबत शेअर करा

अनेक क्लायंटमध्ये कॅलेंडर तयार करता येत नाही; ते फक्त कॅलेंडरला subscribe करू शकतात. ब्राउझरमध्ये https://cal.example.com/ उघडा, you म्हणून log in करा आणि तेथे कॅलेंडर तयार करा. डिस्कवर ते /var/lib/radicale/collections/collection-root/you/ अंतर्गत साठवले जाते. फोल्डरच्या नावासाठी तयार केलेला identifier वापरला जातो.

Radicale चा default rights backend owner_only आहे: authenticated account /USERNAME/ अंतर्गत स्वतःच्या collections वाचू आणि लिहू शकतो, इतर काहीही नाही. बहुतेक घरांसाठी हीच योग्य setting आहे. कॅलेंडर शेअर करण्याचा सर्वात सोपा मार्ग म्हणजे तिसरे account वापरणे. htpasswd वापरून household तयार करा. त्या login ने shared calendar तयार करा आणि प्रत्येक device वर ते दुसरे CalDAV account म्हणून जोडा. हे iOS सहित प्रत्येक क्लायंटवर कार्य करते, कारण कॅलेंडर त्या account च्या स्वतःच्या home मध्ये असते.

तुम्हाला अधिक सूक्ष्म नियंत्रण हवे असल्यास rule based rights वापरा. हे /etc/radicale/config मध्ये जोडा:

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

त्यानंतर Radicale documentation मधील उदाहरणावर आधारित /etc/radicale/rights जोडा:

[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

मोठ्या आणि लहान अक्षरांचा अर्थ वेगवेगळा असतो. R आणि W calendars किंवा address books नसलेल्या collections वाचतात आणि लिहितात. Principal folder साठी हेच आवश्यक असते. r आणि w स्वतः calendars वाचतात आणि लिहितात. त्या identifier ऐवजी वरील storage path मधून तुमच्या calendar चे खरे folder name वापरा.

एक महत्त्वाची मर्यादा लक्षात ठेवा: फक्त calendar home set वाचणारा क्लायंट दुसऱ्या user च्या path अंतर्गत असलेले कॅलेंडर दाखवणार नाही, कारण discovery तेथे जाऊन शोध घेत नाही. Thunderbird आणि DAVx⁵ ते full URL वापरून जोडू शकतात. iOS मध्ये हे शक्य नाही. म्हणून shared account pattern हा नेहमी कार्य करणारा पर्याय आहे.

क्लायंट सेट करा, कारण self-hosted calendars बहुतेक वेळा इथेच अपयशी ठरतात

iPhone आणि iPad. Settings उघडा. त्यानंतर Calendar निवडा. अलीकडील iOS आवृत्त्यांमध्ये ते Apps अंतर्गत असते. पुढे Calendar Accounts, Add Account, Other, Add CalDAV Account निवडा. Server म्हणून cal.example.com द्या. त्यानंतर user name आणि password द्या. Description हे फक्त label आहे. जतन करताना त्रुटी येत असल्यास खाते पुन्हा उघडा. Advanced view मध्ये Use SSL, port आणि पूर्ण account URL दिसतो. URL paste केल्यास discovery पूर्णपणे वगळली जाते.

Android. Android मध्ये built-in CalDAV client नाही. F-Droid किंवा Google Play मधून DAVx⁵ install करा. https://cal.example.com/ हा base URL वापरून user name सह account जोडा. त्यानंतर आवश्यक calendars निवडा. DAVx⁵ Android calendar provider मध्ये नोंदी करते. त्यामुळे events तुम्ही आधीपासून वापरत असलेल्या कोणत्याही calendar app मध्ये दिसतात.

Thunderbird. New Calendar, On the Network निवडा. त्यानंतर user name आणि https://cal.example.com/ हे location द्या. Thunderbird ला सापडलेली calendars ची यादी दाखवतो आणि कोणती calendars जोडायची ते विचारतो.

macOS. System Settings, Internet Accounts, Add Other Account, CalDAV निवडा. Account Type म्हणून Manual निवडा. त्यानंतर तोच user name, password आणि server address द्या.

CalDAV हा polling protocol आहे. Specification मध्ये push नाही. त्यामुळे laptop वर जोडलेला event त्याच क्षणी phone वर येत नाही. तो पुढील sync वेळी येतो. प्रत्येक client मध्ये तुम्हाला योग्य वाटेल असा interval सेट करा. Phone वर कमी interval ठेवल्यास battery अधिक खर्च होते हे लक्षात ठेवा.

फक्त फाइल्स असलेल्या store चा बॅकअप घ्या

Radicale अंतर्गत तुमचे calendar हे .ics फाइल्सची एक directory असते. प्रत्येक event साठी एक फाइल असते. प्रत्येक collection साठी एक लहान properties फाइल असते. एखादी directory कॉपी करणारे कोणतेही साधन तिचा बॅकअप घेते. बॅकअपमध्ये प्रत्यक्ष events आहेत याची खात्री करण्यासाठी तो less ने उघडू शकता. वाचता न येणाऱ्या database dump पेक्षा हा खरा फायदा आहे.

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

archive तयार होण्यासाठी लागणाऱ्या काही सेकंदांसाठी service थांबवा. त्यामुळे फाइल्स वाचल्या जात असताना कोणताही client लेखनक्रियेत अर्धवट राहणार नाही. त्यानंतर archive त्या box बाहेर कॉपी करा. कारण त्याच VPS वरील बॅकअप ज्या बिघाडासाठी तुम्ही तयारी करत आहात तो बिघाड झाल्यास टिकणार नाही. restore करण्याची प्रक्रिया उलट आहे: extract करा, sudo chown -R radicale:radicale /var/lib/radicale/collections चालवा आणि service सुरू करा. प्रत्येक client कडे त्याच्या calendars ची स्थानिक प्रतही असते. त्यामुळे failure झाल्यापासून sync न केलेला laptop तुमच्या डेटाची दुसरी प्रत ठरतो.

Baikal किंवा Nextcloud यापैकी योग्य पर्याय कोणता

Baikal 0.12.1 हे 5 August 2026 रोजी release झाले आणि त्यासाठी PHP 8.2 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. ते web root च्या बाहेर unpack करा आणि फक्त त्याची html directory उपलब्ध करून द्या:

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

या दोन directories मध्येच web server लिहितो. त्यामुळे इतर कोणतीही directory writable ठेवण्याची गरज नाही. तुमच्या nginx server block मध्ये Baikal साठीचे विशिष्ट भाग असे आहेत:

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 reload करा आणि browser मध्ये site उघडा. Setup wizard admin account आणि SQLite database तयार करेल. Client setup Radicale प्रमाणेच आहे. Server address म्हणून https://cal.example.com/ वापरा, कारण well-known rule discovery विनंत्या /dav.php कडे पाठवतो.

तुम्हाला त्याच login मध्ये files आणि phone app देखील हवे असतील, तेव्हाच Nextcloud अतिरिक्त जटिलतेचे समर्थन करते. त्याचा DAV root /remote.php/dav/ आहे आणि त्याच discovery rules लागू होतात. यापैकी कोणतीही service container मध्ये चालवल्यास PHP versions तुमच्या host पासून वेगळ्या ठेवता येतात: VPS वर Docker Compose मध्ये compose file आणि त्याच्या समोरील reverse proxy यांचे वर्णन आहे, तर 2026 मध्ये self-hosting करणे कोणत्या गोष्टींसाठी योग्य आहे या मार्गावर किती पुढे जायचे हे ठरवण्यासाठी योग्य संदर्भ आहे.

अपयशाच्या स्थिती आणि दिसणारे संदेश

प्रत्येक sync 401 परत करते. एकतर password file मधील accounts दुसऱ्या htpasswd -c मुळे नष्ट झाले आहेत किंवा radicale user ला ती वाचता येत नाही. sudo -u radicale cat /etc/radicale/users वापरून तपासा; तेथे permission denied मिळणे हेच कारण स्पष्ट करते. दुरुस्ती म्हणजे group radicale आणि mode 640 ठेवणे. Radicale प्रत्येक अयशस्वी login नंतर default ने एक सेकंद थांबते. त्यामुळे stale password असलेला client नाकारला गेल्यासारखा न दिसता संथ वाटतो.

nginx PROPFIND वर 405 उत्तर देते. URL static file म्हणून serve होत आहे. त्यामुळे WebDAV method Radicale पर्यंत पोहोचत नाही. Endpoint थेट तपासा:

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

कार्यरत DAV collection 207 Multi-Status उत्तर देते. इतर कोणतेही उत्तर मिळाल्यास request web server मध्येच थांबली आहे.

फोन account पडताळू शकत नाही, पण browser मध्ये सर्व काही व्यवस्थित चालते. याची दोन सामान्य कारणे आहेत. curl ने वर तपासलेला well-known redirect नसू शकतो. किंवा certificate chain अपूर्ण असू शकते. Browser गहाळ intermediate मिळवण्यासाठी तो स्वतः fetch करून ही त्रुटी भरून काढतो; iOS तसे करत नाही. Shell मधून तपासा:

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

Verify return code: 0 (ok) शोधा. ते अयशस्वी झाल्यास nginx config मध्ये cert.pem ऐवजी fullchain.pem कडे निर्देश असणे आवश्यक आहे.

Import केल्यानंतर duplicate events दिसतात. प्रत्येक event मध्ये UID असतो आणि clients त्याला identity मानतात. identifiers पुन्हा निर्माण करणाऱ्या tool द्वारे तीच file दोनदा import केल्यास दोन events तयार होतात. ते कधीही merge होणार नाहीत. एका device वरील अतिरिक्त copies delete करा आणि deletion sync होऊ द्या.

Reboot नंतर सर्व काही बंद पडते. Service manually सुरू केली होती. sudo systemctl is-enabled radicale disabled दाखवते आणि sudo systemctl enable --now radicale ही समस्या कायमची दूर करते.

FAQ

मला self-hosted CalDAV सर्व्हरसाठी TLS खरोखर आवश्यक आहे का?

होय. Radicale HTTP Basic authentication वापरते. त्यामुळे प्रत्येक विनंतीसोबत पासवर्ड base64 encoded स्वरूपात पाठवला जातो आणि base64 सहजपणे उलटवता येतो. Clients देखील TLS आवश्यक करतात. macOS Calendar.app असुरक्षित HTTP वर credentials पाठवण्यास मूकपणे नकार देऊ शकते. iOS मध्येही असेच होते. त्यामुळे account save झाल्यासारखे दिसते, पण तो कधीही sync होत नाही. sudo certbot --nginx -d cal.example.com हे संपूर्ण काम करते.

Thunderbird मध्ये account काम करते, पण माझ्या phone वर ते add का होत नाही?

Thunderbird तुम्ही टाइप केलेला पूर्ण URL वापरते. Phone मध्ये एकच server field असते. त्यामुळे ते RFC 6764 discovery वर अवलंबून असते. SRV record नसल्यास ते https://cal.example.com/.well-known/caldav साठी विनंती करते आणि DAV root कडे redirect अपेक्षित करते. त्या विनंतीला 404 मिळाल्यास phone सहसा account verify करता येत नसल्याचे सांगते. nginx मध्ये location = /.well-known/caldav { return 301 https://$host/; } जोडा. त्यानंतर curl -sI https://cal.example.com/.well-known/caldav वापरून 301 आणि location header मिळत आहे याची पुष्टी करा. iOS च्या advanced settings मध्ये पूर्ण account URL paste केल्यास discovery पूर्णपणे वगळली जाते.

दोन व्यक्ती एक calendar share करू शकतात का?

होय. यासाठी shared login हा विश्वसनीय मार्ग आहे. htpasswd वापरून तिसरे account तयार करा. Shared calendar त्याखाली ठेवा आणि प्रत्येक device वर ते दुसरे CalDAV account म्हणून add करा. Radicale च्या rights file मधून दुसऱ्या user च्या path अंतर्गत असलेल्या एका collection वर named user ला read आणि write अधिकार देता येतात. परंतु स्वतःच्या calendar home set मधीलच calendars वाचणारा client तो calendar कधीही दाखवणार नाही. त्यामुळे हा मार्ग iOS पेक्षा Thunderbird आणि DAVx⁵ साठी अधिक योग्य आहे.

VPS बंद पडल्यास माझ्या events चे काय होते?

Radicale मध्ये store plain text असतो. प्रत्येक event साठी .ics file /var/lib/radicale/collections/collection-root/ अंतर्गत असते. तिचा backup tar वापरून घेता येतो आणि less वापरून वाचता येते. Restore करण्यासाठी extract करा, chown -R radicale:radicale चालवा आणि service सुरू करा. प्रत्येक synced client स्थानिक copy देखील ठेवतो. त्यामुळे failure होण्यापूर्वी अद्ययावत असलेल्या laptop वर तुमच्या calendar ची पूर्ण दुसरी copy असते.

CalDAV server माझे contacts देखील sync करतो का?

Contacts साठी CardDAV वापरले जाते. हा RFC 6352 मध्ये परिभाषित केलेला sibling protocol आहे आणि त्यात events ऐवजी vCard files साठवल्या जातात. Radicale, Baikal आणि Nextcloud हे सर्व समान account आणि समान hostname वरून ते उपलब्ध करून देतात. Android वर DAVx⁵ एकाच account मधून calendars आणि contacts sync करते. iOS वर त्याच credentials सह CardDAV प्रकारचे दुसरे account add करावे लागते. म्हणून /.well-known/carddav redirect तुमच्या nginx config मध्ये CalDAV redirect च्या शेजारी असणे आवश्यक आहे.