إعداد خادم تقويم CalDAV على VPS دون Google

ما الذي ستبنيه

التقويم المستضاف ذاتياً هو خادم CalDAV واحد على VPS تتحكم به، يعمل خلف TLS، مع حساب دخول لكل شخص. يعرض الهاتف الذي تحمله والحاسوب المحمول على مكتبك الأحداث نفسها، وكذلك حاسوب شريكك المحمول. لا يوجد حساب Google في الوسط.

يختلف هذا عن صفحة حجز مستضافة ذاتياً. صفحة الحجز مخصصة للغرباء: تنشر الأوقات المتاحة لديك وتتيح لشخص ما حجز أحدها. أما خادم التقويم فمخصص لأجهزتك: يخزّن الأحداث ويحافظ على توافق جميع العملاء. غالباً ما يشغّل الأشخاص النظامين معاً، ثم تقرأ أداة الحجز مدى التوفر من خادم CalDAV الذي ستبنيه هنا.

التثبيت صغير. Radicale عبارة عن حزمة Python واحدة ونحو عشرة أسطر من الإعدادات. ما يحدد قدرة الإعداد على الاستمرار خلال الشهر الأول هو TLS، والاكتشاف، والمجموعات المنفصلة لكل مستخدم، والنسخ الاحتياطية. وتستحوذ هذه الجوانب على معظم المساحة أدناه.

ما هو CalDAV، ولماذا يهم؟

CalDAV هو مزامنة التقويم عبر HTTP. ويُعرَّف في RFC 4791 على أنه امتدادات لـWebDAV، أي تأليف الويب الموزّع وإصدار نسخه، وهو مجموعة من أساليب HTTP الإضافية المعرّفة في RFC 4918. التقويم مجموعة تتصرف مثل دليل. والحدث الواحد ملف واحد داخلها، ويُكتب بتنسيق iCalendar النصي (RFC 5545)، وهو التنسيق نفسه لمرفقات .ics في بريدك.

تستخدم العملاء HTTP العادي مع إضافة بضعة أساليب. يسأل PROPFIND عمّا هو موجود وما الخصائص التي يملكها. ويطلب REPORT جزءاً مُرشَّحاً، مثل كل حدث يقع ضمن نطاق زمني. يكتب PUT حدثاً واحداً، بينما يزيله DELETE. يتضمن كل حدث سطر UID، ويُستخدم هذا المعرّف لكي يتفق جهازان على أنهما يعرضان الحدث نفسه، لا نسخة منه.

الفائدة هي قابلية النقل، وهذا هو السبب الكامل لاستخدام CalDAV. تتحدث iOS وmacOS وThunderbird وEvolution وAndroid عبر DAVx⁵ جميعاً بلغة CalDAV. لا ترتبط بياناتك بالخادم الذي اخترته اليوم. انقل الملفات إلى خادم CalDAV مختلفاً، ووجّه العملاء إلى اسم المضيف الجديد، ولن يتغير شيء آخر.

يأتي CardDAV معه. وهو الفكرة نفسها لجهات الاتصال، ويُعرَّف في RFC 6352 ويخزّن ملفات vCard بدلاً من الأحداث. يقدّم كل خادم أدناه كلا البروتوكولين من الحساب نفسه، لذلك بعد أن يعمل التقويم، لا يبقى إلا تحديد خيار دفتر العناوين.

ما خادم CalDAV الذي ينبغي تشغيله؟

Radicale هو أصغر خيار عملي. يعتمد على Python، ولا يحتاج إلى قاعدة بيانات، ويخزّن البيانات في مجلد يحتوي على ملفات نصية عادية. يستخدم هذا الدليل Radicale لأن تقويم الأسرة لا يحتاج إلى أكثر من ذلك، ولأن احتمال حدوث مشكلات فيه ضئيل جداً في الثالثة صباحاً.

Baikal هو الخيار الذي يوفّر لوحة إدارة عبر الويب. يعمل على PHP ومكتبة sabre/dav، ويخزّن المستخدمين والتقاويم في SQLite أو MySQL، ويتيح إضافة شخص من المتصفح بدلاً من سطر الأوامر. اختره عندما تتغير الحسابات باستمرار.

Nextcloud مناسب عندما يكون التقويم إحدى ميزات عدة. ستحصل على التقويم وجهات الاتصال والملفات وتطبيقاً للهاتف، مقابل الحاجة إلى PHP-FPM وقاعدة بيانات ومشغّل للمهام الخلفية. إذا بدا ذلك ثقيلاً مقارنة بما تحتاج إليه فعلياً، فتغطي بدائل Nextcloud الأخف هذه المقايضة، بينما يغطّي مزامنة الملفات المستضافة ذاتياً الجانب الآخر من استخدام Nextcloud.

DAViCal هو الخيار العريق المعتمد على PostgreSQL. يستحق النظر فيه فقط إذا كنت تشغّل PostgreSQL بالفعل وتريد تخزين بيانات التقويم فيه.

تثبيت Radicale على Ubuntu 24.04

كان Radicale 3.5.10 هو الإصدار الحالي في August 2026. ثبّته في 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 إلى 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/collections

يربط hosts الخدمة بواجهة loopback عمداً. ينهي nginx TLS ويمرّر الطلبات إلى ذلك المنفذ، ولذلك لا يتصل Radicale بالإنترنت مباشرة. ينشئ المثال الأصلي لـ0.0.0.0:5232 خدمة غير مشفّرة تقبل كلمات المرور، وهذا هو الخطأ الوحيد المهم هنا.

ننتقل الآن إلى الحسابات. يختار -5 خوارزمية SHA-512 crypt، التي يقرأها Radicale باستخدام htpasswd_encryption = autodetect من دون وحدة إضافية:

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 الملف ويفرّغ محتواه السابق. استخدمه للمستخدم الأول فقط. يؤدي تشغيل htpasswd -5 -c مرة أخرى بعد أشهر إلى حذف كل حساب أُضيف بعد الحساب الأول، وتظهر المشكلة عندما تتمكّن جهة واحدة من المزامنة بشكل صحيح بينما يحصل جميع الآخرين على مطالبة بكلمة المرور لا تنتهي أبداً. يعمل Bcrypt أيضاً، لكنه يحتاج إلى التثبيت الإضافي radicale[bcrypt].

أنشئ /etc/systemd/system/radicale.service، بالاعتماد على الوحدة الواردة في توثيق Radicale:

[Unit]
Description=CalDAV and CardDAV server
After=network.target
Requires=network.target

[Service]
ExecStart=/opt/radicale/venv/bin/python -m radicale
Restart=on-failure
User=radicale
UMask=0027
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
NoNewPrivileges=true
ReadWritePaths=/var/lib/radicale/

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now radicale
curl -i http://127.0.0.1:5232/

تكون النتيجة السليمة 401 Unauthorized مع رأس WWW-Authenticate: الخدمة تستمع، والمصادقة مفعّلة. يعني Connection refused أنها لم تبدأ أبداً، ويحدّد journalctl -u radicale -n 50 الخيار الذي رفضته. يربط ProtectSystem=strict نظام الملفات بالخدمة في وضع القراءة فقط، ولذلك فإن ReadWritePaths=/var/lib/radicale/ هو السطر الذي يتيح لها حفظ أي حدث. إذا حذفت ذلك السطر، فستستمر عمليات القراءة بينما تفشل كل عمليات الكتابة.

TLS ليس اختيارياً، لأن العملاء يرفضون الاتصالات بالنص الصريح

تستخدم CalDAV مصادقة HTTP Basic، التي ترسل user:password بترميز base64 مع كل طلب. Base64 هو ترميز وليس تشفيراً. عند استخدام HTTP العادي، ترسل كلمة المرور إلى كل شبكة بين الهاتف والخادم طوال اليوم، ومع كل عملية مزامنة.

يفرض العملاء ذلك بالنيابة عنك. توضح وثائق Radicale أن تطبيق Calendar.app في macOS قد يرفض بصمت إرسال بيانات الاعتماد عبر HTTP غير الآمن، ويتصرف iOS بالطريقة نفسها. يبدو الحساب مُعدّاً، لكنه لا يزامن مطلقاً، من دون ظهور خطأ يمكن قراءته.

أضف أولاً سجل A لـ cal.example.com ليشير إلى VPS، لأن المرجع المصدّق يتحقق منه. ثم أنشئ /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/; }
}

تأتي أسطر رؤوس الوكيل الأربعة من وثائق 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. لا تعِد تحميل الإعدادات إلا بعد ذلك، لأن إعادة التحميل مع وجود ملف معطوب تُبقي الإعدادات القديمة قيد التشغيل وتخفي الخطأ حتى إعادة التشغيل التالية. يحرّر Certbot ملف الموقع في مكانه: يثبّت الشهادة، وينقل الكتلة إلى المنفذ 443، ويضيف إعادة توجيه من المنفذ 80. يطلب أمر curl النهائي كلمة المرور، وينبغي أن يعيد 200، وهي واجهة الويب الخاصة بـ Radicale. يعني ظهور 502 Bad Gateway أن nginx قيد التشغيل وأن Radicale لا يستمع على 5232.

لماذا تفشل إضافة الحساب على الهاتف؟

السبب هو الاكتشاف. يوضّح RFC 6764 كيفية تحويل العميل اسم مضيف إلى عنوان URL للتقويم. يبحث عن سجل SRV من النوع _caldavs._tcp، ثم يطلب https://cal.example.com/.well-known/caldav ويتوقع إعادة توجيه إلى جذر DAV. بعد ذلك يطلب current-user-principal، ثم يطلب calendar-home-set لذلك المعرّف الرئيسي، وعندها فقط تظهر تقاويمك. يوفّر الهاتف حقلاً واحداً للخادم، لذلك يجب أن تعمل كل خطوة تلقائياً.

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

الإجابة السليمة هي HTTP/2 301 مع ترويسة location: https://cal.example.com/. وجود 404 هناك هو سبب عرض iOS رسالة تفيد بتعذّر التحقق من معلومات الحساب، بينما يعمل Thunderbird على الشبكة نفسها. يستخدم Thunderbird عنوان URL الكامل الذي أدخلته، لذلك لا يحتاج إلى إعادة التوجيه.

يعتمد هدف إعادة التوجيه على الخادم. يعيد Radicale، عند تقديمه من جذر الموقع، التوجيه إلى /. تأتي Baikal مع قواعد نموذجية تعيد التوجيه إلى /dav.php بحالة 308. يعيد Nextcloud التوجيه إلى /remote.php/dav/.

إنشاء التقويمات ومشاركة أحدها مع شريكك

لا يستطيع العديد من العملاء إنشاء تقويم، بل يمكنهم الاشتراك في تقويم موجود فقط. افتح https://cal.example.com/ في متصفح، وسجّل الدخول باستخدام you، ثم أنشئ التقويم هناك. سيُخزَّن على القرص ضمن /var/lib/radicale/collections/collection-root/you/، مع معرّف مُنشأ تلقائياً يُستخدم اسماً للمجلد.

واجهة الحقوق الافتراضية في Radicale هي owner_only: يقرأ الحساب الذي تمت مصادقته مجموعاته الخاصة ضمن /USERNAME/ ويكتب فيها، ولا يصل إلى أي شيء آخر. هذا هو الإعداد الصحيح لمعظم الأسر، وأبسط طريقة لمشاركة تقويم هي استخدام حساب ثالث. أنشئ household باستخدام htpasswd، وأنشئ التقويم المشترك بعد تسجيل الدخول بهذا الحساب، ثم أضِفه على كل جهاز بوصفه حساب CalDAV ثانياً. يعمل ذلك مع كل العملاء، بما في ذلك iOS، لأن التقويم يوجد ضمن الدليل الرئيسي الخاص بذلك الحساب.

عندما تحتاج إلى تحكم أدق، بدّل إلى حقوق تستند إلى القواعد. أضف ما يلي إلى /etc/radicale/config:

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

ثم أضف /etc/radicale/rights، استناداً إلى المثال الوارد في وثائق Radicale:

[root]
user: .+
collection:
permissions: R

[principal]
user: .+
collection: {user}
permissions: RW

[own-calendars]
user: .+
collection: {user}/[^/]+
permissions: rw

[shared-household]
user: you|partner
collection: you/2f0a9c1e-1f4c-4c2b-9a1b-0d2f7a5c9e11
permissions: rw

للحروف الكبيرة والصغيرة معانٍ مختلفة. يقرأ R وW المجموعات التي ليست تقاويم أو دفاتر عناوين ويكتبان فيها، وهذا هو المقصود بمجلد principal. ويقرأ r وw التقويمات نفسها ويكتبان فيها. استبدل ذلك المعرّف باسم المجلد الفعلي لتقويمك من مسار التخزين أعلاه.

هناك حد مهم يجب معرفته: العميل الذي يقرأ فقط مجموعة الدليل الرئيسي للتقويم لن يعرض تقويماً موجوداً ضمن مسار مستخدم آخر، لأن الاكتشاف لا يبحث هناك. يستطيع Thunderbird وDAVx⁵ إضافته باستخدام URL كامل. أما iOS فلا يستطيع ذلك، ولذلك فإن نمط الحساب المشترك هو الخيار الذي يعمل دائماً.

إعداد العملاء، لأن تقويمات الاستضافة الذاتية تتعطل هنا

iPhone وiPad. افتح Settings، ثم Calendar (يوجد ضمن Apps في إصدارات iOS الحديثة)، ثم Calendar Accounts، ثم Add Account، ثم Other، ثم Add CalDAV Account. الخادم هو cal.example.com، ثم أدخل اسم المستخدم وكلمة المرور. الحقل Description مجرد تسمية. إذا رفض حفظ الإعدادات، افتح الحساب مرة أخرى: يعرض العرض المتقدم الخيار Use SSL والمنفذ وعنوان الحساب الكامل، كما يؤدي لصق العنوان إلى تجاوز الاكتشاف بالكامل.

Android. لا يتضمن النظام عميلاً مدمجاً لـCalDAV. ثبّت DAVx⁵ من F-Droid أو Google Play، وأضف حساباً باستخدام عنوان URL الأساسي https://cal.example.com/ واسم المستخدم، ثم حدّد التقويمات المطلوبة. يكتب DAVx⁵ البيانات في موفّر التقويم في Android، لذلك تظهر الأحداث في تطبيق التقويم الذي تستخدمه بالفعل.

Thunderbird. اختر New Calendar، ثم On the Network، ثم أدخل اسم المستخدم والموقع https://cal.example.com/. يعرض البرنامج ما عثر عليه ويسألك عن التقويمات التي تريد إضافتها.

macOS. افتح System Settings، ثم Internet Accounts، ثم Add Other Account، ثم CalDAV، واضبط Account Type على Manual، ثم أدخل اسم المستخدم وكلمة المرور وعنوان الخادم نفسيهما.

CalDAV بروتوكول يعتمد على الاستطلاع. لا تتضمن المواصفة آلية push، لذلك يصل الحدث الذي تضيفه على الكمبيوتر المحمول إلى الهاتف عند المزامنة التالية، وليس في الثانية نفسها. اضبط الفاصل الزمني في كل عميل على قيمة مناسبة لك، وتذكّر أن تقصير الفاصل الزمني على الهاتف يستهلك البطارية.

النسخ الاحتياطي لمخزن يتكوّن من ملفات فقط

في Radicale، تقويمك عبارة عن مجلد من ملفات .ics، ملف واحد لكل حدث، بالإضافة إلى ملف خصائص صغير لكل مجموعة. أي أداة تنسخ مجلداً تنشئ نسخة احتياطية منه، ويمكنك فتح النسخة الاحتياطية باستخدام less للتأكد من أنّها تحتوي على أحداث فعلية. وهذه ميزة حقيقية مقارنةً بتفريغ قاعدة بيانات لا يمكنك قراءته.

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

أوقف الخدمة لبضع ثوانٍ، وهي المدة اللازمة لإنشاء الأرشيف، حتى لا يكون أي عميل قد بدأ عملية كتابة لم تكتمل عند قراءة الملفات. انقل الأرشيف خارج الخادم بعد ذلك، لأن النسخة الاحتياطية الموجودة على VPS نفسه لا تصمد أمام العطل الذي تستعد له. الاستعادة هي العملية العكسية: فك الضغط، ثم sudo chown -R radicale:radicale /var/lib/radicale/collections، ثم شغّل الخدمة. يحتفظ كل عميل أيضاً بنسخة محلية من تقاويمه، لذلك يشكّل حاسوب محمول لم يزامن بياناته منذ وقوع العطل نسخة ثانية من بياناتك.

عندما يكون Baikal أو Nextcloud الخيار الأنسب

تم إصدار Baikal 0.12.1 في 5 August 2026، ويتطلب PHP 8.2 أو إصداراً أحدث. فك ضغطه خارج جذر الويب، واعرض دليله 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

هذان الدليليان هما الوحيدان اللذان يكتب خادم الويب فيهما، لذلك لا حاجة إلى جعل أي مسار آخر قابلاً للكتابة. داخل كتلة خادم nginx، تكون الأجزاء الخاصة بـ 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، وافتح الموقع في المتصفح، وسيُنشئ معالج الإعداد حساب المسؤول وقاعدة بيانات SQLite. إعداد العميل مطابق لإعداد Radicale، مع استخدام https://cal.example.com/ عنواناً للخادم، لأن قاعدة well-known ترسل الاكتشاف إلى /dav.php.

لا يبرر Nextcloud موارده إلا إذا كنت تريد أيضاً الملفات وتطبيق الهاتف باستخدام تسجيل الدخول نفسه. جذر DAV الخاص به هو /remote.php/dav/، وتنطبق قواعد الاكتشاف نفسها. بالنسبة إلى أي من هذه الخدمات، يؤدي تشغيل الخدمة داخل حاوية إلى إبقاء إصدارات PHP خارج المضيف: يشرح Docker Compose على VPS ملف compose والـreverse proxy الموضوع أمامه، ويُعدّ ما يستحق الاستضافة الذاتية في 2026 مكاناً مناسباً لتحديد مدى رغبتك في متابعة هذا المسار.

أوضاع الفشل والعبارات التي ستظهر لك

تعيد كل مزامنة الرمز 401. إمّا أن ملف كلمات المرور فقد حساباته بسبب htpasswd -c ثانٍ، أو أن مستخدم radicale لا يستطيع قراءته. تحقّق باستخدام sudo -u radicale cat /etc/radicale/users؛ فإذا ظهر فيه رفض للأذونات، فقد وجدت السبب، ويكون الإصلاح بإضافة المجموعة radicale وضبط النمط على 640. ينتظر Radicale أيضاً ثانية واحدة بعد كل تسجيل دخول فاشل افتراضياً، لذلك يبدو العميل الذي يملك كلمة مرور قديمة بطيئاً بدلاً من أن يظهر مرفوضاً.

يعيد nginx الرمز 405 عند استخدام PROPFIND. يجري تقديم عنوان URL كملف ثابت، لذلك لا تصل طريقة WebDAV إلى Radicale. اختبر نقطة النهاية مباشرة:

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

تعيد مجموعة DAV العاملة 207 Multi-Status. وأي نتيجة أخرى تعني أن الطلب توقف عند خادم الويب.

لا يستطيع الهاتف التحقق من الحساب، بينما يعمل المتصفح بصورة طبيعية. هناك سببان شائعان. قد تكون إعادة التوجيه المعروفة مفقودة؛ اختبرها باستخدام أمر curl أعلاه. أو قد تكون سلسلة الشهادة غير مكتملة؛ إذ يتجاوز المتصفح ذلك بجلب الشهادة الوسيطة المفقودة، بينما لا يفعل iOS ذلك. تحقّق منها من shell:

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

ابحث عن Verify return code: 0 (ok). إذا فشل الاختبار، فإن إعداد nginx يشير إلى cert.pem بدلاً من fullchain.pem.

ظهور أحداث مكررة بعد الاستيراد. يحمل كل حدث UID، ويتعامل العملاء معه على أنه هوية الحدث. إذا استوردت الملف نفسه مرتين باستخدام أداة تعيد إنشاء المعرّفات، فستحصل على حدثين لن يدمجهما أي شيء. احذف النسخ الإضافية من أحد الأجهزة، ودَع الحذف يتزامن مع بقية الأجهزة.

يتوقف كل شيء عن العمل بعد إعادة التشغيل. شُغّلت الخدمة يدوياً. يعرض sudo systemctl is-enabled radicale القيمة disabled، ويحل sudo systemctl enable --now radicale المشكلة نهائياً.

FAQ

هل أحتاج فعلاً إلى TLS لخادم CalDAV مستضاف ذاتياً؟

نعم. يستخدم CalDAV مصادقة HTTP Basic، لذلك تنتقل كلمة المرور بترميز base64 مع كل طلب، ويمكن عكس ترميز base64 بسهولة. كما تفرضه العملاء أيضاً: قد يرفض macOS Calendar.app بصمت إرسال بيانات الاعتماد عبر HTTP غير الآمن، ويتصرف iOS بالطريقة نفسها. لذلك يبدو أن الحساب حُفظ، لكنه لا يزامن مطلقاً. تتولى sudo certbot --nginx -d cal.example.com المهمة كاملة.

لماذا يفشل هاتفي في إضافة الحساب بينما يعمل Thunderbird؟

يستخدم Thunderbird عنوان URL الكامل الذي أدخلته. أما الهاتف فيوفّر حقلاً واحداً للخادم، لذلك يتبع آلية الاكتشاف المحددة في RFC 6764: يطلب https://cal.example.com/.well-known/caldav ويتوقع إعادة توجيهه إلى جذر DAV. من دون إعادة التوجيه هذه، يحصل الهاتف على 404 ويبلغ عن تعذر التحقق من الحساب. أضف location = /.well-known/caldav { return 301 https://$host/; } إلى nginx، ثم تأكد باستخدام curl -sI https://cal.example.com/.well-known/caldav من حصولك على 301 ورأس location.

هل يمكن لشخصين مشاركة تقويم واحد؟

نعم، والطريقة الموثوقة هي استخدام حساب مشترك. أنشئ حساباً ثالثاً باستخدام htpasswd، وضع التقويم المشترك ضمنه، ثم أضفه كحساب CalDAV ثانٍ على كل جهاز. يمكن لملف الحقوق في Radicale بدلاً من ذلك منح مستخدم مُسمّى صلاحيات القراءة والكتابة على مجموعة واحدة ضمن مسار مستخدم آخر. لكن العميل الذي يقرأ فقط مجموعة صفحات التقويم الخاصة به لن يعرضها مطلقاً. لذلك تناسب هذه الطريقة Thunderbird وDAVx⁵ أكثر من iOS.

ماذا يحدث لأحداثي إذا تعطل VPS؟

يخزن Radicale البيانات كنص عادي: ملف .ics واحد لكل حدث ضمن /var/lib/radicale/collections/collection-root/، ويمكنك نسخه احتياطياً باستخدام tar وقراءته باستخدام less. تتكون الاستعادة من الاستخراج، ثم chown -R radicale:radicale، ثم بدء الخدمة. يحتفظ كل عميل متزامن أيضاً بنسخة محلية، لذلك يحتوي الحاسوب المحمول الذي كان محدثاً قبل العطل على نسخة ثانية كاملة من تقويمك.

هل يزامن خادم CalDAV جهات الاتصال أيضاً؟

تستخدم جهات الاتصال CardDAV، وهو بروتوكول شقيق محدد في RFC 6352 يخزن ملفات vCard بدلاً من الأحداث. يوفّر Radicale وBaikal وNextcloud هذا البروتوكول من الحساب نفسه واسم المضيف نفسه. على Android، يزامن DAVx⁵ التقويمات وجهات الاتصال من حساب واحد. على iOS، تضيف حساباً ثانياً من نوع CardDAV باستخدام بيانات الاعتماد نفسها. لذلك يجب وضع إعادة توجيه /.well-known/carddav في إعداد nginx بجوار إعادة توجيه CalDAV.