تحریر: Matt Connor 2026-08-15

VPS پر Google کے بغیر CalDAV calendar کیسے بنائیں

Q: کیا دو افراد ایک calendar شیئر کر سکتے ہیں؟

جی ہاں، اور قابل اعتماد طریقہ shared login ہے۔ htpasswd کے ذریعے تیسرا account بنائیں، shared calendar اس کے تحت رکھیں، اور ہر device پر اسے دوسرے CalDAV account کے طور پر شامل کریں۔ Radicale کی rights file اس کے بجائے کسی named user کو دوسرے user کے path کے تحت ایک collection پر read اور write کی اجازت دے سکتی ہے، لیکن جو client صرف اپنے calendar home set کو پڑھتا ہے وہ اسے کبھی ظاہر نہیں کرے گا۔ اس لیے یہ طریقہ iOS کے بجائے Thunderbird اور DAVx⁵ کے لیے موزوں ہے۔

Q: VPS بند ہو جائے تو میرے events کا کیا ہوگا؟

Radicale میں store plain text ہوتا ہے: /var/lib/radicale/collections/collection-root/ کے تحت ہر event کے لیے ایک .ics file ہوتی ہے، جس کا backup آپ tar سے لے سکتے ہیں اور less سے پڑھ سکتے ہیں۔ Restore کا طریقہ extract، chown -R radicale:radicale، اور service start کرنا ہے۔ ہر synced client ایک local copy بھی رکھتا ہے، اس لیے failure سے پہلے up-to-date رہنے والے laptop میں آپ کے calendar کی مکمل دوسری copy موجود ہوتی ہے۔

Radicale کے ساتھ VPS پر CalDAV server بنائیں، TLS اور discovery ترتیب دیں، اور phone و laptop sync کریں۔ اس guide میں تقریباً 10 lines کی config شامل ہے۔

آپ کیا بنا رہے ہیں

Self-hosted calendar ایک VPS پر چلنے والا واحد CalDAV server ہے جسے آپ خود control کرتے ہیں۔ یہ TLS کے پیچھے چلتا ہے اور ہر شخص کے لیے ایک login ہوتا ہے۔ آپ کی جیب میں موجود phone اور میز پر رکھا laptop ایک ہی events دکھاتے ہیں، اور آپ کے partner کا laptop بھی یہی events دکھاتا ہے۔ درمیان میں کوئی Google account نہیں ہوتا۔

یہ کام self-hosted booking page سے مختلف ہے۔ Booking page اجنبی افراد کے لیے ہوتی ہے: یہ آپ کے دستیاب وقت کے slots شائع کرتی ہے اور کسی کو ایک slot منتخب کرنے دیتی ہے۔ Calendar server آپ کے اپنے devices کے لیے ہوتا ہے: یہ events محفوظ کرتا ہے اور ہر client کو ایک ہی حالت میں رکھتا ہے۔ لوگ اکثر دونوں چلاتے ہیں، اور booking tool اپنی availability اسی CalDAV server سے حاصل کرتا ہے جسے آپ یہاں بنائیں گے۔

یہ installation مختصر ہے۔ Radicale ایک Python package اور تقریباً دس lines کی 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 ایک collection ہوتا ہے جو directory کی طرح کام کرتا ہے۔ ایک event اس collection کے اندر ایک file ہوتا ہے، جس میں iCalendar کا text format استعمال ہوتا ہے (RFC 5545)۔ یہی format آپ کی mail میں موجود .ics attachments کے لیے بھی استعمال ہوتا ہے۔

Clients عام HTTP استعمال کرتے ہیں، جس میں چند اضافی methods شامل ہوتے ہیں۔ PROPFIND یہ معلوم کرتا ہے کہ یہاں کیا موجود ہے اور اس کی کون سی properties ہیں۔ REPORT کسی filtered حصے کے لیے درخواست کرتا ہے، مثلاً کسی date range کے تمام events۔ PUT ایک event لکھتا ہے، جبکہ DELETE اسے حذف کرتا ہے۔ ہر event میں UID line ہوتی ہے۔ یہی identifier دو devices کو یہ طے کرنے میں مدد دیتا ہے کہ وہ ایک ہی event دیکھ رہے ہیں، نہ کہ اس کی الگ copy۔

اصل فائدہ portability ہے، اور CalDAV استعمال کرنے کی بنیادی وجہ بھی یہی ہے۔ iOS، macOS، Thunderbird، Evolution اور DAVx⁵ کے ذریعے Android، سب CalDAV کو support کرتے ہیں۔ آپ کا data اس server تک محدود نہیں رہتا جسے آپ آج منتخب کرتے ہیں۔ Files کو کسی دوسرے CalDAV server پر منتقل کریں، clients کو نئے hostname کی طرف point کریں، اور باقی کچھ تبدیل نہیں ہوتا۔

CardDAV بھی اسی طریقے سے کام کرتا ہے۔ یہ contacts کے لیے یہی تصور ہے، جسے RFC 6352 میں بیان کیا گیا ہے، اور اس میں events کے بجائے vCard files محفوظ ہوتی ہیں۔ ذیل میں موجود ہر server ایک ہی account سے دونوں protocols فراہم کرتا ہے۔ اس لیے calendar کے کام کرنے کے بعد address book کو صرف checkbox منتخب کرنا ہوتا ہے۔

کون سا CalDAV server چلانا چاہیے؟

Radicale وہ کم سے کم حل ہے جو کام کرتا ہے۔ یہ Python پر چلتا ہے، اسے database کی ضرورت نہیں ہوتی، اور data plain files کے folder میں محفوظ ہوتا ہے۔ یہ guide اسے اس لیے استعمال کرتی ہے کہ گھریلو calendar کو اس سے زیادہ کی ضرورت نہیں ہوتی، اور رات کے تین بجے خراب ہونے والی چیزیں بھی بہت کم ہوتی ہیں۔

Baikal وہ option ہے جس میں web admin panel موجود ہے۔ یہ PHP اور sabre/dav library پر چلتا ہے، users اور calendars کو SQLite یا MySQL میں محفوظ کرتا ہے، اور command line کے بجائے browser میں کسی شخص کو شامل کرنے دیتا ہے۔ جب accounts اکثر شامل یا حذف ہوتے رہیں تو اسے منتخب کریں۔

Nextcloud اس وقت موزوں ہے جب calendar کئی features میں سے صرف ایک ہو۔ اس کے ساتھ calendar، contacts، files اور mobile app ملتے ہیں، لیکن اس کے لیے PHP-FPM، database اور background job runner درکار ہوتے ہیں۔ اگر آپ کی اصل ضرورت کے مقابلے میں یہ setup زیادہ بھاری لگے تو Nextcloud کے ہلکے متبادل اس trade-off کا احاطہ کرتے ہیں، جبکہ self-hosted file sync اس دوسری بنیادی وجہ کا احاطہ کرتا ہے جس کے لیے لوگ Nextcloud install کرتے ہیں۔

DAViCal طویل عرصے سے موجود PostgreSQL option ہے۔ اسے صرف اس صورت میں دیکھیں جب آپ پہلے ہی PostgreSQL چلا رہے ہوں اور calendar data اسی میں محفوظ رکھنا چاہتے ہوں۔

Ubuntu 24.04 پر Radicale انسٹال کریں

August 2026 تک Radicale 3.5.10 موجودہ release تھا۔ اسے اپنے الگ 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

virtual environment صرف پسند کا معاملہ نہیں ہے۔ sudo pip install radicale کو system Python میں چلانے سے error: externally-managed-environment آتا ہے، کیونکہ Ubuntu اپنے Python کو apt کی ملکیت قرار دیتا ہے تاکہ pip package کی فراہم کردہ 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 terminate کرتا ہے اور درخواستیں اسی port پر forward کرتا ہے، اس لیے Radicale براہِ راست internet کے سامنے نہیں آتا۔ 0.0.0.0:5232 کی upstream مثال ایک غیر encrypted service publish کرتی ہے جو passwords قبول کرتی ہے۔ یہاں یہی وہ غلطی ہے جو اہم ہے۔

اب accounts بنائیں۔ -5 SHA-512 crypt منتخب کرتا ہے، جسے Radicale htpasswd_encryption = autodetect کے ذریعے پڑھ لیتا ہے اور کسی اضافی module کی ضرورت نہیں ہوتی:

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 file بناتا ہے اور اس میں موجود تمام مواد truncate کر دیتا ہے۔ اسے صرف پہلے user کے لیے استعمال کریں۔ کئی ماہ بعد htpasswd -5 -c دوبارہ چلانے سے پہلے user کے بعد شامل کیے گئے تمام accounts حذف ہو جاتے ہیں۔ اس کی علامت یہ ہے کہ ایک شخص کی syncing درست کام کرتی ہے، جبکہ باقی سب کو ایسا password prompt ملتا رہتا ہے جو کبھی مکمل نہیں ہوتا۔ bcrypt بھی کام کرتا ہے، لیکن اس کے لیے اضافی install radicale[bcrypt] درکار ہے۔

/etc/systemd/system/radicale.service بنائیں، جسے Radicale documentation میں موجود unit سے اخذ کیا گیا ہے:

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

درست نتیجہ 401 Unauthorized ہے، جس میں WWW-Authenticate header شامل ہو: اس کا مطلب ہے کہ service listening کر رہی ہے اور authentication فعال ہے۔ Connection refused کا مطلب ہے کہ service کبھی start نہیں ہوئی، جبکہ journalctl -u radicale -n 50 اس option کا نام بتاتا ہے جسے اس نے reject کیا۔ ProtectSystem=strict اس service کے لیے filesystem کو read-only mount کرتا ہے، اس لیے ReadWritePaths=/var/lib/radicale/ وہ line ہے جو اسے event محفوظ کرنے دیتی ہے۔ یہ line ہٹا دیں تو reads کام کرتی رہیں گی، لیکن ہر write ناکام ہو جائے گی۔

TLS اختیاری نہیں ہے، کیونکہ clients plaintext کنکشن قبول نہیں کرتے

CalDAV، HTTP Basic کے ذریعے authentication کرتا ہے، جو ہر request پر user:password کو base64 میں encoded صورت میں بھیجتا ہے۔ Base64 encoding ہے، encryption نہیں۔ سادہ HTTP پر phone اور server کے درمیان موجود ہر network کو password دے دیا جاتا ہے، پورا دن اور ہر sync کے دوران۔

Clients یہ پابندی خود نافذ کرتے ہیں۔ Radicale documentation کے مطابق macOS Calendar.app غیر محفوظ HTTP پر credentials بھیجنے سے خاموشی سے انکار کر سکتا ہے، اور iOS بھی اسی طرح کام کرتا ہے۔ Account configured دکھائی دیتا ہے، لیکن sync کبھی نہیں ہوتا اور پڑھنے کے لیے کوئی error بھی نہیں ہوتا۔

پہلے cal.example.com کے لیے VPS کی طرف ایک A record بنائیں، کیونکہ 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 دکھاتا ہے۔ اس کے بعد ہی reload کریں، کیونکہ broken file کے ساتھ reload کرنے سے پرانی configuration چلتی رہتی ہے اور غلطی اگلے restart تک چھپی رہتی ہے۔ Certbot site file کو براہ راست edit کرتا ہے: یہ certificate install کرتا ہے، block کو port 443 پر منتقل کرتا ہے، اور port 80 سے redirect شامل کرتا ہے۔ آخری curl password طلب کرتا ہے اور اسے 200 واپس کرنا چاہیے، جو Radicale کا اپنا web interface ہے۔ 502 Bad Gateway کا مطلب ہے کہ nginx چل رہا ہے لیکن Radicale port 5232 پر listening نہیں کر رہا۔

فون پر account شامل کرنا کیوں ناکام ہوتا ہے؟

اس کی وجہ discovery ہے۔ RFC 6764 میں بتایا گیا ہے کہ client hostname کو calendar URL میں کیسے تبدیل کرتا ہے۔ یہ _caldavs._tcp SRV record تلاش کرتا ہے، پھر https://cal.example.com/.well-known/caldav کی درخواست بھیجتا ہے اور توقع کرتا ہے کہ جواب DAV root کی طرف redirect کرے گا۔ اس کے بعد یہ current-user-principal کے لیے، پھر اس principal کے calendar-home-set کے لیے درخواست بھیجتا ہے، اور صرف اس کے بعد اسے آپ کے calendars نظر آتے ہیں۔ فون server کے لیے صرف ایک field فراہم کرتا ہے، اس لیے ہر مرحلہ خودکار طور پر کامیاب ہونا چاہیے۔

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 کرتا ہے۔ Baikal ایسی sample rules فراہم کرتا ہے جو status 308 کے ساتھ /dav.php کی طرف redirect کرتی ہیں۔ Nextcloud /remote.php/dav/ کی طرف redirect کرتا ہے۔

کیلنڈر بنائیں اور ایک کیلنڈر اپنے شریکِ حیات کے ساتھ شیئر کریں

بہت سے clients کیلنڈر نہیں بنا سکتے، صرف اسے subscribe کر سکتے ہیں۔ browser میں https://cal.example.com/ کھولیں، you کے طور پر login کریں، اور وہیں کیلنڈر بنائیں۔ disk پر یہ /var/lib/radicale/collections/collection-root/you/ کے اندر محفوظ ہوگا، جہاں folder name کے لیے generated identifier استعمال ہوگا۔

Radicale کا default rights backend owner_only ہے: authenticated account اپنی collections کو /USERNAME/ کے اندر پڑھ اور لکھ سکتا ہے، اس کے علاوہ کسی اور چیز تک رسائی نہیں ہوتی۔ زیادہ تر گھروں کے لیے یہ درست setting ہے، اور کیلنڈر شیئر کرنے کا سب سے آسان طریقہ ایک تیسرا account ہے۔ htpasswd کے ساتھ household بنائیں، اس login کے تحت shared calendar بنائیں، اور ہر device پر اسے دوسرے CalDAV account کے طور پر شامل کریں۔ یہ ہر client پر کام کرتا ہے، iOS پر بھی، کیونکہ کیلنڈر اسی account کے اپنے home میں موجود ہوتا ہے۔

جب زیادہ باریک control درکار ہو تو rule based rights استعمال کریں۔ /etc/radicale/config میں یہ شامل کریں:

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

پھر /etc/radicale/rights چلائیں، اور Radicale documentation میں موجود example کو بنیاد بنائیں:

[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 ان collections کو پڑھتے اور لکھتے ہیں جو calendars یا address books نہیں ہیں، کیونکہ principal folder اسی نوعیت کا ہوتا ہے۔ r اور w خود calendars کو پڑھتے اور لکھتے ہیں۔ اس identifier کو اوپر دیے گئے storage path میں موجود اپنے کیلنڈر کے اصل folder name سے تبدیل کریں۔

ایک اہم حد یہ ہے: جو client صرف calendar home set پڑھتا ہے، وہ کسی دوسرے user کے path کے اندر موجود کیلنڈر نہیں دکھائے گا، کیونکہ discovery وہاں تلاش نہیں کرتی۔ Thunderbird اور DAVx⁵ اسے مکمل URL کے ذریعے شامل کر سکتے ہیں۔ iOS ایسا نہیں کر سکتا، اسی لیے shared account کا طریقہ ہمیشہ کام کرتا ہے۔

کلائنٹس ترتیب دیں، کیونکہ self-hosted calendars عموماً اسی مرحلے پر ناکام ہوتے ہیں

iPhone اور iPad۔ Settings کھولیں، پھر Calendar کھولیں۔ حالیہ iOS versions میں یہ Apps کے اندر ہوتا ہے۔ اس کے بعد Calendar Accounts، Add Account، Other، Add CalDAV Account منتخب کریں۔ Server کے طور پر cal.example.com درج کریں، پھر user name اور password درج کریں۔ Description صرف ایک label ہے۔ اگر account save نہ ہو تو اسے دوبارہ کھولیں۔ Advanced view میں Use SSL، port اور مکمل account URL دکھائی دیتے ہیں۔ URL paste کرنے سے discovery مکمل طور پر نظرانداز ہو جاتی ہے۔

Android۔ اس میں built-in CalDAV client موجود نہیں ہے۔ F-Droid یا Google Play سے DAVx⁵ install کریں۔ Base URL https://cal.example.com/ استعمال کرتے ہوئے user name کے ساتھ account شامل کریں، پھر مطلوبہ calendars منتخب کریں۔ DAVx⁵ Android calendar provider میں data لکھتا ہے، اس لیے events اسی calendar app میں ظاہر ہوتے ہیں جو آپ پہلے سے استعمال کرتے ہیں۔

Thunderbird۔ New Calendar، On the Network منتخب کریں، پھر user name اور location https://cal.example.com/ درج کریں۔ یہ دستیاب 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 زیادہ استعمال کرتا ہے۔

صرف files پر مشتمل store کا backup لیں

Radicale میں آپ کا calendar ایک directory ہے جس میں .ics files ہوتی ہیں، ہر event کے لیے ایک file، اور ہر collection کے لیے ایک چھوٹی properties file ہوتی ہے۔ جو بھی طریقہ directory کو copy کرتا ہے، وہ اس کا backup لے لیتا ہے۔ آپ backup کو less سے کھول کر تصدیق کر سکتے ہیں کہ اس میں حقیقی events موجود ہیں۔ یہ اس 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 تیار ہونے میں جتنے چند seconds لگتے ہیں، اتنی دیر کے لیے service روک دیں، تاکہ files پڑھے جانے کے وقت کوئی client write کے دوران درمیان میں نہ ہو۔ اس کے بعد archive کو server سے باہر copy کریں، کیونکہ اسی VPS پر موجود backup اس failure سے محفوظ نہیں رہتا جس کے لیے آپ تیاری کر رہے ہیں۔ Restore کا طریقہ الٹ ہے: extract کریں، sudo chown -R radicale:radicale /var/lib/radicale/collections چلائیں، اور service شروع کریں۔ ہر client اپنے calendars کی local copy بھی رکھتا ہے، اس لیے وہ laptop جس نے failure کے بعد sync نہیں کیا، آپ کے data کی دوسری copy ہوتا ہے۔

Baikal یا Nextcloud کب بہتر انتخاب ہے

Baikal 0.12.1، 5 August 2026 کو جاری ہوا اور اسے PHP 8.2 یا اس کے بعد کا ورژن درکار ہے۔ اسے web root سے باہر unpack کریں اور صرف اس کی html directory کو expose کریں:

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 لکھتا ہے، اس لیے کسی اور مقام کو 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 پر بھیجتا ہے۔

Nextcloud کا انتخاب اسی وقت مناسب ہے جب آپ اسی login کے تحت files اور phone app بھی چاہتے ہوں۔ اس کا DAV root /remote.php/dav/ ہے، اور یہی discovery rules یہاں بھی لاگو ہوتے ہیں۔ ان میں سے کسی بھی سروس کو container میں چلانے سے PHP versions آپ کے host سے الگ رہتے ہیں: VPS پر Docker Compose میں compose file اور اس کے سامنے reverse proxy کی وضاحت ہے، جبکہ 2026 میں self-host کرنا کیا فائدہ مند ہے اس بات کا فیصلہ کرنے کے لیے مناسب جگہ ہے کہ آپ اس راستے پر کس حد تک آگے بڑھنا چاہتے ہیں۔

خرابی کی صورتیں اور نظر آنے والی strings

ہر 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 طور پر ایک second بھی انتظار کرتا ہے، اس لیے stale password والا client rejected دکھائی دینے کے بجائے سست محسوس ہوتا ہے۔

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 درست کام کرتا ہے۔ اس کی دو عام وجوہات ہیں۔ Well-known redirect موجود نہیں، جس کی جانچ اوپر دیے گئے curl سے کی جاتی ہے۔ یا certificate chain نامکمل ہے۔ Browsers missing intermediate کو حاصل کر کے اس مسئلے کو عموماً چھپا دیتے ہیں، لیکن 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 سمجھتے ہیں۔ اگر ایسا ہی file کسی ایسے tool کے ذریعے دو بار import کیا جائے جو identifiers دوبارہ بناتا ہے، تو دو events پیدا ہو جاتے ہیں جنہیں کوئی چیز کبھی merge نہیں کرے گی۔ ایک device پر اضافی copies حذف کریں اور deletion کو sync ہونے دیں۔

Reboot کے بعد سب کچھ کام کرنا بند کر دیتا ہے۔ Service ہاتھ سے start کی گئی تھی۔ sudo systemctl is-enabled radicale، disabled دکھاتا ہے، اور sudo systemctl enable --now radicale اسے مستقل طور پر درست کر دیتا ہے۔

FAQ

کیا self-hosted CalDAV server کے لیے TLS واقعی ضروری ہے؟

جی ہاں۔ CalDAV، HTTP Basic کے ذریعے authentication کرتا ہے، اس لیے password ہر request پر base64 encoded صورت میں بھیجا جاتا ہے، اور base64 کو آسانی سے اصل شکل میں تبدیل کیا جا سکتا ہے۔ Clients بھی اس تقاضے کو نافذ کرتے ہیں: macOS Calendar.app غیر محفوظ HTTP پر credentials بھیجنے سے خاموشی سے انکار کر سکتا ہے، اور iOS بھی یہی طریقہ اختیار کرتا ہے۔ اس لیے account محفوظ ہوتا دکھائی دیتا ہے، لیکن کبھی sync نہیں ہوتا۔ sudo certbot --nginx -d cal.example.com پورا کام انجام دیتا ہے۔

Thunderbird کے کام کرنے کے باوجود میرا phone account شامل کرنے میں ناکام کیوں ہوتا ہے؟

Thunderbird وہ مکمل URL استعمال کرتا ہے جو آپ درج کرتے ہیں۔ Phone میں server کے لیے ایک ہی field ہوتی ہے، اس لیے وہ RFC 6764 کے مطابق discovery کرتا ہے: یہ https://cal.example.com/.well-known/caldav کو request بھیجتا ہے اور DAV root پر redirect کی توقع کرتا ہے۔ اس redirect کے بغیر phone کو 404 ملتا ہے اور وہ بتاتا ہے کہ account کی تصدیق نہیں ہو سکتی۔ nginx میں location = /.well-known/caldav { return 301 https://$host/; } شامل کریں، پھر curl -sI https://cal.example.com/.well-known/caldav سے تصدیق کریں کہ آپ کو 301 اور location header مل رہا ہے۔

کیا دو افراد ایک calendar شیئر کر سکتے ہیں؟

جی ہاں، اور قابل اعتماد طریقہ shared login ہے۔ htpasswd کے ذریعے تیسرا account بنائیں، shared calendar اس کے تحت رکھیں، اور ہر device پر اسے دوسرے CalDAV account کے طور پر شامل کریں۔ Radicale کی rights file اس کے بجائے کسی named user کو دوسرے user کے path کے تحت ایک collection پر read اور write کی اجازت دے سکتی ہے، لیکن جو client صرف اپنے calendar home set کو پڑھتا ہے وہ اسے کبھی ظاہر نہیں کرے گا۔ اس لیے یہ طریقہ iOS کے بجائے Thunderbird اور DAVx⁵ کے لیے موزوں ہے۔

VPS بند ہو جائے تو میرے events کا کیا ہوگا؟

Radicale میں store plain text ہوتا ہے: /var/lib/radicale/collections/collection-root/ کے تحت ہر event کے لیے ایک .ics file ہوتی ہے، جس کا backup آپ tar سے لے سکتے ہیں اور less سے پڑھ سکتے ہیں۔ Restore کا طریقہ extract، chown -R radicale:radicale، اور service start کرنا ہے۔ ہر synced client ایک local copy بھی رکھتا ہے، اس لیے failure سے پہلے up-to-date رہنے والے laptop میں آپ کے calendar کی مکمل دوسری copy موجود ہوتی ہے۔

کیا CalDAV server میرے contacts بھی sync کرتا ہے؟

Contacts کے لیے CardDAV استعمال ہوتا ہے۔ یہ RFC 6352 میں بیان کردہ sibling protocol ہے، جو events کے بجائے vCard files محفوظ کرتا ہے۔ Radicale، Baikal اور Nextcloud تینوں اسے اسی account اور اسی hostname سے serve کرتے ہیں۔ Android پر DAVx⁵ ایک ہی account سے calendars اور contacts sync کرتا ہے۔ iOS پر آپ کو اسی credentials کے ساتھ CardDAV type کا دوسرا account شامل کرنا ہوتا ہے، اسی لیے /.well-known/carddav redirect آپ کی nginx config میں CalDAV والے redirect کے ساتھ شامل ہونا چاہیے۔

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