ஆல் VPS-ல் சொந்தமாக CalDAV server அமைப்பது எப்படி?
Google இன்றி உங்கள் சாதனங்களை ஒத்திசைக்க Radicale மூலம் CalDAV server-ஐ VPS-ல் நிறுவுவது எப்படி என்பதை அறியுங்கள். TLS பாதுகாப்பு, தானியங்கி discovery மற்றும் client setup முறைகளை
நீங்கள் உருவாக்குவது என்ன
நீங்கள் நிர்வகிக்கும் VPS-ல், TLS பாதுகாப்பிற்குப் பின்னால் இயங்கும் ஒரு CalDAV server-தான் self-hosted calendar. இதில் ஒவ்வொரு பயனருக்கும் தனித்தனி login இருக்கும். உங்கள் கைபேசி, மடிக்கணினி மற்றும் உங்கள் துணையின் மடிக்கணினி என அனைத்திலும் ஒரே நிகழ்வுகள் (events) ஒத்திசைக்கப்படும். இதில் Google கணக்கின் தலையீடு இருக்காது.
இது self-hosted booking page என்பதிலிருந்து முற்றிலும் மாறுபட்டது. Booking page என்பது அந்நியர்களுக்காக உருவாக்கப்படுவது; அது உங்கள் ஓய்வு நேரங்களை வெளியிட்டு, மற்றவர்கள் அதை முன்பதிவு செய்ய அனுமதிக்கிறது. Calendar server என்பது உங்கள் சொந்த சாதனங்களுக்காக உருவாக்கப்படுவது; இது நிகழ்வுகளைச் சேமித்து, அனைத்து client-களையும் ஒத்திசைவில் வைத்திருக்கிறது. பலர் இவ்விரண்டையும் பயன்படுத்துவார்கள்; அப்போது booking tool, நீங்கள் இங்கே உருவாக்கும் CalDAV server-லிருந்து உங்கள் கிடைக்கும் நேரத்தை (availability) வாசிக்கும்.
இதன் நிறுவல் சிறியது. Radicale என்பது ஒரு Python package மற்றும் சுமார் பத்து வரிகள் கொண்ட configuration மட்டுமே. இந்த அமைப்பு முதல் மாதத்தைத் தாண்டி நீடிக்குமா என்பதை TLS, discovery, பயனர் வாரியான collections மற்றும் backups ஆகியவையே தீர்மானிக்கின்றன. கீழே உள்ள பகுதிகளில் இவை குறித்து விரிவாகக் காண்போம்.
CalDAV என்றால் என்ன, அது ஏன் முக்கியமானது?
CalDAV என்பது HTTP வழியாக காலெண்டரை ஒத்திசைக்கும் (sync) முறையாகும். இது RFC 4791-ல் WebDAV-ன் நீட்டிப்பாக வரையறுக்கப்பட்டுள்ளது (WebDAV என்பது RFC 4918-ல் வரையறுக்கப்பட்ட கூடுதல் HTTP முறைகளைக் கொண்ட, இணையம் சார்ந்த ஆவண உருவாக்கம் மற்றும் பதிப்பு மேலாண்மை முறையாகும்). ஒரு காலெண்டர் என்பது ஒரு கோப்பகம் (directory) போலச் செயல்படும் தொகுப்பாகும். இதில் உள்ள ஒவ்வொரு நிகழ்வும் (event) ஒரு தனி கோப்பாக இருக்கும்; இது iCalendar உரை வடிவத்தில் (RFC 5545) எழுதப்பட்டிருக்கும். இது உங்கள் மின்னஞ்சலில் வரும் .ics இணைப்புகளின் அதே வடிவமாகும்.
Clients சாதாரண HTTP-ஐப் பயன்படுத்தி, அதனுடன் சில கூடுதல் முறைகளைச் சேர்க்கின்றன. PROPFIND என்பது அங்கு என்ன இருக்கிறது மற்றும் அதன் பண்புகள் என்ன என்று கேட்கிறது. REPORT என்பது ஒரு குறிப்பிட்ட கால இடைவெளியில் உள்ள நிகழ்வுகள் போன்ற வடிகட்டப்பட்ட தகவல்களைக் கேட்கிறது. PUT ஒரு நிகழ்வை எழுதுகிறது மற்றும் DELETE அதை நீக்குகிறது. ஒவ்வொரு நிகழ்வும் ஒரு UID வரியைக் கொண்டிருக்கும். அந்த அடையாளங்காட்டி (identifier) மூலமே, இரண்டு சாதனங்களும் ஒரே நிகழ்வைப் பார்க்கின்றனவா அல்லது நகலைப் பார்க்கின்றனவா என்பதை உறுதிப்படுத்திக் கொள்கின்றன.
இதன் முக்கியப் பயன் இடமாற்றத்தன்மை (portability) ஆகும்; இதற்காகவே இது பயன்படுத்தப்படுகிறது. iOS, macOS, Thunderbird, Evolution மற்றும் DAVx⁵ வழியாக Android என அனைத்தும் CalDAV-ஐ ஆதரிக்கின்றன. உங்கள் தரவு நீங்கள் இன்று தேர்ந்தெடுத்த server-டன் மட்டும் பிணைக்கப்படவில்லை. கோப்புகளை வேறொரு CalDAV server-க்கு நகர்த்திவிட்டு, புதிய hostname-ஐ clients-ல் குறிப்பிட்டால் போதும், மற்றவை மாறாது.
CardDAV-ம் இதனுடன் இணைந்து செயல்படுகிறது. இது தொடர்புகளுக்கான (contacts) அதே கருத்தாகும்; இது RFC 6352-ல் வரையறுக்கப்பட்டுள்ளது மற்றும் நிகழ்வுகளுக்குப் பதிலாக vCard கோப்புகளைச் சேமிக்கிறது. கீழே கொடுக்கப்பட்டுள்ள ஒவ்வொரு server-ம் ஒரே கணக்கிலிருந்து இரண்டு நெறிமுறைகளையும் (protocols) வழங்குகிறது. எனவே, காலெண்டர் சரியாகச் செயல்படத் தொடங்கினால், முகவரிப் புத்தகத்தை (address book) ஒரு checkbox மூலம் எளிதாகச் செயல்படுத்தலாம்.
எந்த CalDAV server-ஐ நீங்கள் இயக்க வேண்டும்?
Radicale என்பது மிகச்சிறிய மற்றும் திறம்பட செயல்படும் ஒரு தீர்வாகும். இது Python-ல் இயங்குகிறது, இதற்கு database தேவையில்லை, மேலும் தரவுகள் அனைத்தும் சாதாரண கோப்புகளாக (plain files) ஒரு கோப்புறையில் சேமிக்கப்படும். ஒரு வீட்டு உபயோகக் காலண்டருக்கு இதற்கு மேல் எதுவும் தேவையில்லை என்பதாலும், அதிகாலை மூன்று மணிக்கு இதில் கோளாறுகள் ஏற்படுவதற்கான வாய்ப்புகள் மிகக் குறைவு என்பதாலும் இந்த வழிகாட்டி இதைப் பயன்படுத்துகிறது.
Baikal என்பது இணைய அடிப்படையிலான நிர்வாகக் குழுவைக் (web admin panel) கொண்ட ஒரு விருப்பமாகும். இது PHP மற்றும் sabre/dav library-ல் இயங்குகிறது. இது பயனர்கள் மற்றும் காலண்டர்களை SQLite அல்லது MySQL-ல் சேமிக்கிறது. command line-க்கு பதிலாக browser மூலமாகவே புதிய நபர்களைச் சேர்க்க இது அனுமதிக்கிறது. கணக்குகள் அடிக்கடி உருவாக்கப்படும் அல்லது நீக்கப்படும் சூழலில் இதைத் தேர்ந்தெடுக்கவும்.
Nextcloud என்பது காலண்டர் ஒரு அங்கமாக மட்டுமே தேவைப்படும்போது பொருத்தமானதாகும். இதில் காலண்டர், தொடர்புகள் (contacts), கோப்புகள் மற்றும் mobile app ஆகிய வசதிகள் கிடைக்கும். ஆனால் இதற்கு ஈடாக PHP-FPM, ஒரு database மற்றும் background job runner ஆகியவற்றை நீங்கள் பராமரிக்க வேண்டும். இது உங்கள் தேவைக்கு மிக அதிகப்படியானதாகத் தோன்றினால், இலகுவான Nextcloud மாற்றுகள் குறித்த தகவல்களைப் பார்க்கவும். மேலும், மக்கள் Nextcloud-ஐ நிறுவுவதற்கான மற்றொரு முக்கிய காரணமான self-hosted file sync வசதி குறித்தும் தெரிந்துகொள்ளலாம்.
DAViCal என்பது நீண்டகாலமாகப் பயன்பாட்டில் உள்ள PostgreSQL அடிப்படையிலான விருப்பமாகும். நீங்கள் ஏற்கனவே PostgreSQL-ஐப் பயன்படுத்தி, காலண்டர் தரவுகளையும் அதிலேயே சேமிக்க விரும்பினால் மட்டுமே இதைப் பரிசீலிக்கலாம்.
Ubuntu 24.04-ல் Radicale-ஐ நிறுவுதல்
11 அக்டோபர் 2026 நிலவரப்படி, 8 அக்டோபர் 2026 அன்று வெளியிடப்பட்ட Radicale 3.8.3 தற்போதைய release ஆகும். கீழே உள்ள password கோப்பு சார்ந்திருக்கும் bcrypt வசதியுடன், இதை ஒரு தனி virtual environment-ல் நிறுவவும்.
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 என்பது ஒரு விருப்பத்தேர்வு அல்ல. sudo pip install radicale மூலம் system Python-ல் நேரடியாக நிறுவுவது error: externally-managed-environment பிழையுடன் நிற்கும். ஏனெனில், Ubuntu-வின் Python தொகுப்புகள் apt மூலம் நிர்வகிக்கப்படுகின்றன; எனவே pip மூலம் அவற்றை மாற்றியமைக்க முடியாது.
/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/collectionshosts வேண்டுமென்றே loopback-ல் பிணைக்கப்பட்டுள்ளது (bind). nginx மூலம் TLS termination செய்யப்பட்டு இந்த port-க்கு அனுப்பப்படுவதால், Radicale நேரடியாக இணையத்தை எதிர்கொள்வதில்லை. 0.0.0.0:5232-ன் upstream உதாரணம், கடவுச்சொற்களை ஏற்கும் குறியாக்கப்படாத (unencrypted) சேவையை வெளியிடுகிறது; இதுவே இங்கு தவிர்க்கப்பட வேண்டிய முக்கியமான தவறு.
இப்போது கணக்குகளை உருவாக்கலாம். -B bcrypt-ஐத் தேர்ந்தெடுக்கிறது. மேலே உள்ள radicale[bcrypt] நிறுவலில் உள்ள 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 கோப்பை உருவாக்கி, அதில் உள்ள பழைய தரவுகளை நீக்கிவிடும். இதை முதல் பயனருக்கு மட்டும் பயன்படுத்தவும். சில மாதங்களுக்குப் பிறகு மீண்டும் htpasswd -B -c-ஐ இயக்கினால், முதல் பயனருக்குப் பிறகு சேர்க்கப்பட்ட அனைத்து கணக்குகளும் நீக்கப்படும். இதன் அறிகுறி என்னவென்றால், ஒரு பயனர் மட்டும் சரியாக sync செய்வார், மற்ற அனைவருக்கும் கடவுச்சொல் கேட்கும் திரை முடிவில்லாமல் வந்து கொண்டே இருக்கும். SHA-512 crypt (-5) இங்கு ஒரு விருப்பமல்ல: Apache 2.4.59-ல் தான் htpasswd-க்கு SHA-2 ஆதரவு கிடைத்தது. Ubuntu 24.04-ல் உள்ள apache2-utils 2.4.58-ன் htpasswd-ல் -5 flag கிடையாது.
Radicale ஆவணத்தில் உள்ள 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.targetsudo systemctl daemon-reload
sudo systemctl enable --now radicale
curl -i http://127.0.0.1:5232/சரியான முடிவு 401 Unauthorized மற்றும் WWW-Authenticate header-ஆக இருக்க வேண்டும்: சேவை இயங்குகிறது மற்றும் அங்கீகாரம் (authentication) செயல்பாட்டில் உள்ளது. Connection refused என்பது அந்த முகவரியில் எந்த சேவையும் இயங்கவில்லை என்று பொருள்; பொதுவாக சேவை தொடங்கத் தவறியதாலோ அல்லது வெளியேறியதாலோ இது நிகழும். journalctl -u radicale -n 50 என்பது நிராகரிக்கப்பட்ட விருப்பத்தைக் குறிக்கும். ProtectSystem=strict இந்த சேவைக்காக filesystem-ஐ read-only முறையில் mount செய்கிறது, எனவே ReadWritePaths=/var/lib/radicale/ என்பது மட்டுமே தரவுகளைச் சேமிக்க அனுமதிக்கும் வரியாகும். அந்த வரியை நீக்கினால், வாசிப்பு (read) வேலை செய்யும், ஆனால் அனைத்து எழுதும் (write) செயல்பாடுகளும் தோல்வியடையும்.
TLS கட்டாயமானது, ஏனெனில் கிளையண்டுகள் plaintext-ஐ ஏற்க மறுக்கின்றன
இந்த அமைப்பு HTTP Basic மூலம் அங்கீகரிக்கப்படுகிறது; இதுவே Radicale ஏற்கும் ஒரே முறையாகும். Basic முறை ஒவ்வொரு கோரிக்கையிலும் user:password base64 குறியாக்கத்தை அனுப்புகிறது. Base64 என்பது ஒரு குறியாக்கம் மட்டுமே, அது encryption அல்ல. சாதாரண HTTP வழியாக நீங்கள் கடவுச்சொல்லை அனுப்பும்போது, தொலைபேசிக்கும் server-க்கும் இடையே உள்ள ஒவ்வொரு நெட்வொர்க்கிலும் நாள் முழுவதும், ஒவ்வொரு sync-ன் போதும் அது வெளிப்படும்.
கிளையண்டுகள் உங்களுக்காக இதை அமல்படுத்துகின்றன. macOS Calendar.app பாதுகாப்பற்ற HTTP வழியாக credentials-ஐ அனுப்பாமல் அமைதியாக மறுக்கக்கூடும் என்றும், iOS-ம் இதேபோல் செயல்படும் என்றும் Radicale ஆவணங்கள் குறிப்பிடுகின்றன. கணக்கு சரியாக உள்ளமைக்கப்பட்டதாகத் தோன்றும், ஆனால் எந்தப் பிழையும் காட்டப்படாமல் sync ஆகாது.
முதலில் 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 வரிகள் Radicale ஆவணங்களிலிருந்து பெறப்பட்டவை. அவற்றை அப்படியே வைத்திருக்கவும்.
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-ஐ அச்சிடும். அது முடிந்த பிறகு மட்டும் reload செய்யவும், ஏனெனில் தவறான கோப்புடன் reload செய்தால் பழைய config-யே இயங்கும், அடுத்த restart வரை பிழை தெரியாது. Certbot site கோப்பை நேரடியாக மாற்றியமைக்கும்: அது certificate-ஐ நிறுவி, block-ஐ port 443-க்கு மாற்றி, port 80-லிருந்து redirect-ஐச் சேர்க்கும். இறுதி curl கட்டளை கடவுச்சொல்லைக் கேட்கும், அது Radicale-ன் சொந்த web interface-ஆன 200-ஐத் தர வேண்டும். 502 Bad Gateway பிழை வந்தால், nginx இயங்குகிறது ஆனால் port 5232-லிருந்து சரியான பதில் கிடைக்கவில்லை என்று பொருள்; Radicale அங்கு listening நிலையில் இல்லாததே இதற்குப் பொதுவான காரணமாகும்.
தொலைபேசியில் கணக்கைச் சேர்க்கும்போது ஏன் தோல்வியடைகிறது?
இதற்குக் காரணம் discovery ஆகும். ஒரு client எவ்வாறு hostname-ஐ calendar URL-ஆக மாற்றுகிறது என்பதை RFC 6764 விவரிக்கிறது. இது முதலில் ஒரு _caldavs._tcp SRV record-ஐத் தேடுகிறது, பின்னர் https://cal.example.com/.well-known/caldav-க்கு கோரிக்கை விடுத்து, DAV root-க்கு redirect செய்யப்படுவதை எதிர்பார்க்கிறது. அங்கிருந்து அது current-user-principal-ஐக் கேட்கிறது, அதன் பிறகு அந்த principal-ன் calendar-home-set-ஐக் கேட்கிறது, அதன் பின்னரே உங்கள் calendar-களை அது கண்டறியும். தொலைபேசியில் server-க்காக ஒரே ஒரு field மட்டுமே இருப்பதால், ஒவ்வொரு படியும் தானாகவே (unattended) செயல்பட வேண்டும்.
curl -sI https://cal.example.com/.well-known/caldavசரியான பதில் location: https://cal.example.com/ header-உடன் கூடிய HTTP/2 301 ஆகும். அதே network-ல் Thunderbird வேலை செய்யும்போது, iOS கணக்குத் தகவலைச் சரிபார்க்க முடியவில்லை என்று கூறுவதற்கு 404 ஒரு பொதுவான காரணமாகும்: Thunderbird நீங்கள் உள்ளிட்ட முழுமையான URL-ஐப் பயன்படுத்துகிறது, எனவே அதற்கு redirect தேவைப்படுவதில்லை.
Redirect இலக்கு server-ஐப் பொறுத்தது. தளத்தின் root-ல் இயங்கும் Radicale, /-க்கு redirect செய்கிறது. கோரிக்கை அதை அடையும்போது Radicale அந்தப் பாதைக்கு 301 பதிலை அளிக்கிறது, எனவே nginx விதிகள் redirect-ஐ உருவாக்குவதற்குப் பதிலாக அதை வெளிப்படையானதாக மாற்றுகின்றன. Baikal, /dav.php-க்கு 308 status-உடன் redirect செய்யும் மாதிரி விதிகளை வழங்குகிறது. Nextcloud, /remote.php/dav/-க்கு redirect செய்கிறது.
Calendar-களை உருவாக்குதல் மற்றும் உங்கள் துணையுடன் ஒன்றைப் பகிர்தல்
பல client-கள் calendar-ஐ உருவாக்க முடியாது, அவை ஏற்கனவே உள்ள ஒன்றிற்கு subscribe மட்டுமே செய்ய முடியும். ஒரு browser-ல் https://cal.example.com/-ஐத் திறந்து, you-ஆக login செய்து, அங்கு calendar-ஐ உருவாக்கவும். வட்டில் (disk) அது /var/lib/radicale/collections/collection-root/you/-ன் கீழ் சேமிக்கப்படும், அங்கு folder பெயருக்காக ஒரு identifier உருவாக்கப்படும்.
Radicale-ன் இயல்புநிலை rights backend owner_only ஆகும்: ஒரு authenticated account தனது சொந்த collection-களை மட்டும் /USERNAME/-ன் கீழ் படிக்கவும் எழுதவும் முடியும், மற்றவற்றை அணுக முடியாது. பெரும்பாலான இல்லங்களுக்கு இதுவே சரியான அமைப்பாகும், மேலும் ஒரு calendar-ஐப் பகிர்வதற்கான எளிமையான வழி மூன்றாவது account-ஐப் பயன்படுத்துவதாகும். household-ஐ htpasswd மூலம் உருவாக்கி, அந்த login-ன் கீழ் பகிரப்பட்ட calendar-ஐ உருவாக்கி, ஒவ்வொரு சாதனத்திலும் இரண்டாவது CalDAV account-ஆக அதைச் சேர்க்கவும். இது iOS உட்பட அனைத்து client-களிலும் வேலை செய்யும், ஏனெனில் அந்த calendar அந்த account-ன் சொந்த home-ல் உள்ளது.
உங்களுக்குக் கூடுதல் கட்டுப்பாடு தேவைப்படும்போது, rule-based rights-க்கு மாறவும். இதை /etc/radicale/config-ல் சேர்க்கவும்:
[rights]
type = from_file
file = /etc/radicale/rightsபின்பு, Radicale ஆவணத்தில் உள்ள உதாரணத்தின் அடிப்படையில் /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 என்பவை calendar அல்லது address book அல்லாத collection-களைப் படிக்கவும் எழுதவும் பயன்படுகின்றன, இதுவே principal folder ஆகும். r மற்றும் w என்பவை calendar-களைப் படிக்கவும் எழுதவும் பயன்படுகின்றன. அந்த identifier-க்கு பதிலாக மேலே உள்ள storage path-ல் உள்ள உங்கள் calendar-ன் உண்மையான folder பெயரை இடவும்.
ஒரு முக்கிய வரம்பு: calendar home-ஐ மட்டும் படிக்கும் ஒரு client, மற்றொரு பயனர் பாதையில் உள்ள calendar-ஐக் காட்டாது, ஏனெனில் discovery அந்தப் பாதைக்குச் செல்லாது. Thunderbird மற்றும் DAVx⁵ ஆகியவற்றில் முழு URL-ஐக் கொண்டு அதைச் சேர்க்க முடியும். iOS-ல் இதைச் செய்ய முடியாது, அதனால்தான் பகிரப்பட்ட account முறை எப்போதும் வேலை செய்யும் தீர்வாக உள்ளது.
Clients-ஐ அமைத்தல், ஏனெனில் self-hosted calendar-கள் தோல்வியடைவது இங்குதான்
iPhone மற்றும் iPad. Settings-ஐத் திறந்து, பின் Calendar (சமீபத்திய iOS பதிப்புகளில் Apps-ன் கீழ் இருக்கும்), Calendar Accounts, Add Account, Other, Add CalDAV Account ஆகியவற்றைத் தேர்ந்தெடுக்கவும். Server என்பது cal.example.com, அதைத் தொடர்ந்து பயனர் பெயர் மற்றும் கடவுச்சொல்லை உள்ளிடவும். Description என்பது ஒரு பெயர்ப்பலகை மட்டுமே. சேமிக்க மறுத்தால், கணக்கை மீண்டும் திறக்கவும்: advanced view-ல் Use SSL, port மற்றும் முழுமையான account URL ஆகியவை இருக்கும்; URL-ஐ நகலெடுத்து ஒட்டுவது discovery செயல்முறையைத் தவிர்க்க உதவும்.
Android. இதில் உள்ளமைக்கப்பட்ட CalDAV client கிடையாது. F-Droid அல்லது Google Play-லிருந்து DAVx⁵-ஐ நிறுவவும். https://cal.example.com/ என்ற base URL மற்றும் உங்கள் பயனர் பெயரைப் பயன்படுத்தி ஒரு கணக்கைச் சேர்க்கவும், பின் உங்களுக்குத் தேவையான calendar-களைத் தேர்ந்தெடுக்கவும். DAVx⁵ தகவல்களை Android calendar provider-ல் எழுதும், எனவே நீங்கள் ஏற்கனவே பயன்படுத்தும் எந்தவொரு calendar app-லும் நிகழ்வுகள் தோன்றும்.
Thunderbird. New Calendar, On the Network என்பதைத் தேர்ந்தெடுத்து, உங்கள் பயனர் பெயர் மற்றும் https://cal.example.com/ என்ற இருப்பிடத்தை உள்ளிடவும். அது கண்டறியப்பட்டவற்றைப் பட்டியலிட்டு, எந்தெந்த calendar-களைச் சேர்க்க வேண்டும் என்று கேட்கும்.
macOS. System Settings, Internet Accounts, Add Other Account, CalDAV என்பதற்குச் செல்லவும். Account Type-ஐ Manual என அமைத்து, அதே பயனர் பெயர், கடவுச்சொல் மற்றும் server முகவரியை உள்ளிடவும்.
CalDAV என்பது ஒரு polling protocol ஆகும். இதன் விவரக்குறிப்பில் (specification) push வசதி இல்லை, எனவே லேப்டாப்பில் நீங்கள் சேர்க்கும் ஒரு நிகழ்வு, அதே நொடியில் போனுக்கு வராது; அடுத்த sync-ன் போதுதான் வரும். ஒவ்வொரு client-லும் உங்களுக்கு ஏற்ற sync இடைவெளியை (interval) அமைக்கவும். போனில் மிகக் குறுகிய இடைவெளியை அமைப்பது battery பயன்பாட்டை அதிகரிக்கும் என்பதை நினைவில் கொள்ளவும்.
கோப்புகளை மட்டும் கொண்ட store-ஐ காப்புப்பிரதி எடுத்தல்
Radicale-ல் உங்கள் காலண்டர் என்பது .ics கோப்புகளின் ஒரு கோப்பகம் (directory) ஆகும். ஒவ்வொரு நிகழ்வும் ஒரு கோப்பாக இருக்கும், மேலும் ஒவ்வொரு தொகுப்பிற்கும் ஒரு சிறிய properties கோப்பு இருக்கும். ஒரு கோப்பகத்தை நகலெடுக்கும் எந்தவொரு முறையும் அதை காப்புப்பிரதி எடுக்கும். காப்புப்பிரதி உண்மையான நிகழ்வுகளைக் கொண்டுள்ளதா என்பதை உறுதிப்படுத்த, அதை நீங்கள் 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-ம் பாதியில் எழுதும் பணியில் இருக்காது. அதன் பிறகு காப்பகத்தை அந்த server-லிருந்து வெளியே நகலெடுக்கவும். ஏனெனில், அதே VPS-ல் இருக்கும் காப்புப்பிரதி, நீங்கள் எதிர்பார்க்கும் தோல்வியின் போது பாதுகாப்பாக இருக்காது. மீட்டெடுப்பது என்பது இதற்கு நேர்மாறானது: கோப்புகளைப் பிரித்தெடுத்து, sudo chown -R radicale:radicale /var/lib/radicale/collections செய்து, பின் service-ஐத் தொடங்கவும். ஒவ்வொரு client-ம் தனது காலண்டர்களின் உள்ளூர் நகலை வைத்திருக்கும். எனவே, தோல்விக்குப்பின் sync செய்யப்படாத ஒரு மடிக்கணினி உங்கள் தரவின் இரண்டாவது நகலாகச் செயல்படும்.
Baikal அல்லது Nextcloud - எது சிறந்தது
Baikal 0.12.1, 5 August 2026 அன்று வெளியிடப்பட்டது. இதற்கு PHP 8.2 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. இதை web root-க்கு வெளியே பிரித்தெடுத்து, அதன் 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இந்த இரண்டு கோப்பகங்கள் மட்டுமே web server-ஆல் எழுதப்படக்கூடியவை, எனவே மற்ற எதற்கும் எழுதும் அனுமதி (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) தளத்தைத் திறக்கவும். setup wizard, admin கணக்கையும் SQLite database-ஐயும் உருவாக்கும். client setup, Radicale-ஐப் போலவே இருக்கும். https://cal.example.com/ என்பதை server முகவரியாகப் பயன்படுத்தவும், ஏனெனில் well-known விதி discovery-ஐ /dav.php-க்கு அனுப்புகிறது.
ஒரே login-ல் கோப்புகள் மற்றும் phone app ஆகியவையும் தேவைப்பட்டால் மட்டுமே Nextcloud-ஐப் பயன்படுத்துவது பயனுள்ளது. அதன் DAV root /remote.php/dav/ ஆகும், மேலும் அதே discovery விதிகள் இதற்கும் பொருந்தும். இவற்றில் எதை இயக்கினாலும், service-ஐ container-ல் இயக்குவது உங்கள் host-ல் PHP பதிப்புகள் குழப்பமடையாமல் இருக்க உதவும்: Docker Compose on a VPS என்பது compose கோப்பு மற்றும் அதற்கு முன்னால் உள்ள reverse proxy பற்றிய தகவல்களை வழங்குகிறது. மேலும், what is worth self-hosting in 2026 என்பது நீங்கள் எந்த அளவுக்கு இந்தத் தொழில்நுட்பத்தில் ஈடுபடலாம் என்பதைத் தீர்மானிக்க உதவும் ஒரு சிறந்த இடமாகும்.
தோல்வி முறைகள் மற்றும் நீங்கள் காணும் சரங்கள் (strings)
ஒவ்வொரு sync-ம் 401 பிழையைத் தருகிறது. ஒன்று, password கோப்பில் உள்ள கணக்குகள் இரண்டாவது htpasswd -c-ஆல் நீக்கப்பட்டிருக்கலாம், அல்லது radicale பயனரால் அதை வாசிக்க முடியவில்லை. sudo -u radicale cat /etc/radicale/users மூலம் சரிபார்க்கவும்; அங்கே permission denied என்று வந்தால் அதுவே காரணம். இதற்கு radicale குழுவைச் சேர்த்து, mode 640-க்கு மாற்ற வேண்டும். Radicale இயல்பாகவே ஒவ்வொரு தோல்வியுற்ற login-க்கு பிறகும் ஒரு வினாடி காத்திருக்கும், எனவே பழைய கடவுச்சொல்லைக் கொண்ட client, நிராகரிக்கப்பட்டதை விட மெதுவாகச் செயல்படுவது போலத் தோன்றும்.
PROPFIND-க்கு nginx 405 பிழையைத் தருகிறது. அந்த URL ஒரு static கோப்பாக வழங்கப்படுகிறது, எனவே WebDAV முறை Radicale-ஐச் சென்றடையவில்லை. endpoint-ஐ நேரடியாகச் சோதிக்கவும்:
curl -u you -X PROPFIND -H "Depth: 0" -i https://cal.example.com/you/சரியாகச் செயல்படும் DAV collection 207 Multi-Status என்று பதிலளிக்கும். வேறு ஏதேனும் வந்தால், கோரிக்கை web server-லேயே நின்றுவிட்டது என்று பொருள்.
Browser-ல் சரியாக வேலை செய்கிறது, ஆனால் போனில் கணக்கைச் சரிபார்க்க முடியவில்லை. இதற்கு இரண்டு பொதுவான காரணங்கள் உள்ளன. ஒன்று, well-known redirect விடுபட்டிருக்கலாம், இதை மேலே உள்ள curl மூலம் சோதிக்கலாம். அல்லது certificate chain முழுமையற்றதாக இருக்கலாம்; browsers விடுபட்ட intermediate certificate-ஐத் தாமாகவே பதிவிறக்கிச் சரிசெய்துவிடும், ஆனால் iOS அவ்வாறு செய்யாது. shell மூலம் சரிபார்க்கவும்:
openssl s_client -connect cal.example.com:443 -servername cal.example.com </dev/nullVerify return code: 0 (ok) உள்ளதா என்று பார்க்கவும். அது தோல்வியுற்றால், nginx config cert.pem-ஐச் சுட்டிக்காட்டுகிறது, அது fullchain.pem-ஐச் சுட்டிக்காட்ட வேண்டும்.
Import செய்த பிறகு நிகழ்வுகள் (events) நகல்களாகத் தோன்றுகின்றன. ஒவ்வொரு நிகழ்வும் ஒரு UID-ஐக் கொண்டிருக்கும், அதைத்தான் clients அடையாளமாக எடுத்துக்கொள்ளும். ஒரே கோப்பை, identifiers-ஐ மாற்றும் ஒரு கருவி மூலம் இருமுறை import செய்தால், இரண்டு தனித்தனி நிகழ்வுகள் உருவாகும்; அவற்றை எதனாலும் இணைக்க முடியாது. ஒரு சாதனத்தில் உள்ள கூடுதல் நகல்களை நீக்கிவிட்டு, அந்த நீக்கம் sync ஆகுமாறு செய்யவும்.
Reboot செய்த பிறகு அனைத்தும் வேலை செய்வதை நிறுத்திவிடுகிறது. service கைமுறையாகத் தொடங்கப்பட்டிருக்கலாம். sudo systemctl is-enabled radicale கட்டளை disabled என்று காட்டினால், sudo systemctl enable --now radicale கட்டளை அதை நிரந்தரமாகச் சரிசெய்யும்.
FAQ
self-hosted CalDAV server-க்கு TLS உண்மையிலேயே தேவையா?
ஆம். Radicale, HTTP Basic மூலம் அங்கீகரிப்பதால், கடவுச்சொல் ஒவ்வொரு கோரிக்கையிலும் base64 குறியாக்கத்துடன் பயணிக்கிறது; base64-ஐ எளிதாகத் தலைகீழாக மாற்ற முடியும். கிளையண்டுகளும் இதை அமல்படுத்துகின்றன: macOS Calendar.app பாதுகாப்பற்ற HTTP வழியாக credentials-ஐ அனுப்பாமல் அமைதியாக மறுக்கக்கூடும், iOS-ம் இதேபோல் செயல்படும். இதனால் கணக்கு சேமிக்கப்பட்டது போலத் தோன்றும், ஆனால் ஒருபோதும் sync ஆகாது. sudo certbot --nginx -d cal.example.com என்பது முழுமையான தீர்வாகும்.
Thunderbird வேலை செய்யும்போது, எனது தொலைபேசியில் ஏன் கணக்கைச் சேர்க்க முடியவில்லை?
Thunderbird நீங்கள் உள்ளிட்ட முழு URL-ஐயும் பயன்படுத்துகிறது. தொலைபேசியில் ஒரு server புலம் மட்டுமே இருப்பதால், அது RFC 6764 discovery-ஐ நம்பியிருக்கிறது. SRV record இல்லையெனில், அது https://cal.example.com/.well-known/caldav-ஐக் கோரி, DAV root-க்கு redirect-ஐ எதிர்பார்க்கும். அந்த கோரிக்கை 404 பிழையைத் தந்தால், கணக்கைச் சரிபார்க்க முடியவில்லை என்று தொலைபேசி வழக்கமாகத் தெரிவிக்கும். nginx-ல் location = /.well-known/caldav { return 301 https://$host/; }-ஐச் சேர்க்கவும், பிறகு curl -sI https://cal.example.com/.well-known/caldav மூலம் 301 மற்றும் location header கிடைப்பதை உறுதிப்படுத்தவும். iOS advanced settings-ல் முழு கணக்கு URL-ஐயும் நகலெடுத்து ஒட்டுவது discovery-ஐத் தவிர்க்க உதவும்.
இருவர் ஒரே calendar-ஐப் பகிர முடியுமா?
ஆம், நம்பகமான வழி பகிரப்பட்ட login-ஐப் பயன்படுத்துவதாகும். htpasswd மூலம் மூன்றாவது கணக்கை உருவாக்கி, பகிரப்பட்ட calendar-ஐ அதன் கீழ் வைத்து, ஒவ்வொரு சாதனத்திலும் இரண்டாவது CalDAV கணக்காகச் சேர்க்கவும். Radicale-ன் rights கோப்பு மூலம் ஒரு பயனருக்கு மற்றொரு பயனரின் path-ல் உள்ள collection-க்கு read/write அனுமதி வழங்க முடியும். ஆனால், தனது சொந்த calendar home set-ஐ மட்டும் வாசிக்கும் கிளையண்ட் அதை ஒருபோதும் காட்டாது என்பதால், இந்த முறை iOS-க்கு பதிலாக Thunderbird மற்றும் DAVx⁵-க்கு ஏற்றது.
VPS செயலிழந்தால் எனது நிகழ்வுகள் (events) என்னவாகும்?
Radicale-ல் தரவு plain text வடிவில் இருக்கும்: ஒவ்வொரு நிகழ்வும் /var/lib/radicale/collections/collection-root/-க்கு கீழ் ஒரு .ics கோப்பாக இருக்கும். இதை tar மூலம் backup எடுத்து less மூலம் வாசிக்கலாம். மீட்டெடுக்க, கோப்புகளைப் பிரித்தெடுத்து (extract), chown -R radicale:radicale செய்து, service-ஐத் தொடங்கவும். sync செய்யப்பட்ட ஒவ்வொரு கிளையண்டிலும் உள்ளூர் நகல் இருக்கும் என்பதால், செயலிழப்புக்கு முன்பு sync செய்த laptop-ல் உங்கள் calendar-ன் முழுமையான இரண்டாவது நகல் இருக்கும்.
CalDAV server எனது தொடர்புகளையும் (contacts) sync செய்யுமா?
தொடர்புகள் CardDAV-ஐப் பயன்படுத்துகின்றன. இது RFC 6352-ல் வரையறுக்கப்பட்ட ஒரு சகோதர protocol ஆகும், இது நிகழ்வுகளுக்குப் பதிலாக vCard கோப்புகளைச் சேமிக்கிறது. Radicale, Baikal மற்றும் Nextcloud ஆகிய அனைத்தும் ஒரே கணக்கு மற்றும் ஒரே hostname-லிருந்து இதை வழங்குகின்றன. Android-ல், DAVx⁵ ஒரே கணக்கிலிருந்து calendar மற்றும் தொடர்புகளை sync செய்கிறது. iOS-ல், அதே credentials-உடன் CardDAV வகையிலான இரண்டாவது கணக்கைச் சேர்க்க வேண்டும்; இதனால்தான் /.well-known/carddav redirect உங்கள் nginx config-ல் CalDAV-க்கு அடுத்ததாக இருக்க வேண்டும்.