بقلم Matt Connor 2026-10-12

تشغيل متحكم UniFi على خادم VPS

Q: أين تخزن وحدة تحكم UniFi نسخها الاحتياطية التلقائية؟

في صورة الحاوية المستخدمة هنا، يتم تخزينها في /config/data/backup/autobackup، والتي يتم ربطها بمسار بياناتك بالإضافة إلى data/backup/autobackup على المضيف، كملفات .unf مسماة وفقاً للإصدار والطابع الزمني. في بعض عمليات التثبيت الجديدة، لا يوجد المجلد autobackup، وبالتالي لا يكتب النسخ الاحتياطي المجدول أي شيء دون الإبلاغ عن خطأ، لذا تحقق من محتويات ذلك المجلد بعد يوم من ضبط الجدول الزمني وأنشئه بنفسك إذا كان فارغاً. انسخ الملفات خارج الـ VPS، لأن ملف .unf يحتوي على إعدادات الموقع وحسابات المسؤول.

تعرف إلى متطلبات تشغيل UniFi Network Application على VPS، ولماذا تحتاج إلى 4 جيجابايت RAM، وكيفية استخدام Docker وMongoDB واعتماد الأجهزة عبر set-inform، مع إبقاء المنافذ الحساسة خاصة.

ما الذي يفعله متحكم UniFi فعلياً على VPS

متحكم UniFi على VPS هو خادم إدارة واحد يظل قابلاً للوصول عندما تتوقف المواقع التي يديرها. البرنامج هو UniFi Network Application من Ubiquiti: برنامج Java تقف خلفه قاعدة بيانات MongoDB. يضبط نقاط الوصول والمبدّلات لديك، ويخزّن إحصاءاتها، ويعرض واجهة الإدارة. لكنه لا ينقل حركة مرور العملاء.

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

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

ما مقدار ذاكرة الوصول العشوائي (RAM) التي يحتاجها متحكم UniFi؟

حجم 2 جيجابايت هو الحد الأدنى، و4 جيجابايت هو الحجم الموصى به للشراء. يوجد مستهلكان للذاكرة في الحاوية نفسها، وهما Java وMongoDB، ويقوم كل منهما بتحديد حجمه بشكل مستقل عن الآخر.

يتم تحديد سقف كومة ذاكرة Java (Java heap) بواسطة MEM_LIMIT، والذي تضبطه صورة الحاوية افتراضياً على 1024 ميجابايت. أما النصف الآخر فيستهلكه MongoDB؛ حيث يقوم محرك التخزين WiredTiger بتحديد حجم ذاكرته المؤقتة (cache) بنصف حجم ذاكرة RAM التي تزيد عن 1 جيجابايت، أو 256 ميجابايت، أيهما أكبر. على خادم VPS بحجم 2 جيجابايت، يبلغ حجم الذاكرة المؤقتة حوالي 512 ميجابايت، بالإضافة إلى 1 جيجابايت للكومة، وذاكرة JVM غير المخصصة للكومة، ونظام التشغيل. يعمل هذا الإعداد بشكل جيد حتى يزداد الضغط، عندها يقوم مدير الذاكرة في النواة (OOM killer) بإنهاء إحدى العمليتين. بعد أي إعادة تشغيل غير مبررة، نفّذ dmesg -T | grep -i 'killed process' لمعرفة ما إذا كان هذا هو السبب. أضف ملف تبديل (swap file) إذا كان لديك 2 جيجابايت فقط.

لا يتطلب المعالج (CPU) والقرص موارد كبيرة. يمكن لمعالج vCPU واحد أو اثنين التعامل مع بضع عشرات من الأجهزة. ابدأ بـ 20 جيجابايت من مساحة القرص وراقبها، لأن قاعدة البيانات تنمو مع زيادة عدد العملاء الذين تراهم ومدة احتفاظك بالإحصائيات. يترك المتحكم وحده معظم موارد خادم بحجم 4 جيجابايت في حالة خمول، لذا إذا كنت تخطط لاستضافة خدمة أخرى معه، فحدد الحجم بناءً على متطلبات الخدمة الأخرى أولاً، لأن PhotoPrism و Immich لهما متطلبات ذاكرة مختلفة تماماً وكلاهما يستهلك ذاكرة أكثر مما يستهلكه المتحكم.

هناك ميزة واحدة في المعالج تهمنا، ومن السهل تجاهلها في الخطط الرخيصة:

grep -m1 -o avx /proc/cpuinfo

تحتاج إصدارات MongoDB 5.0 وما بعدها إلى ميزة AVX (امتدادات المتجهات المتقدمة) على معالجات x86_64. إذا لم يطبع هذا الأمر أي شيء، فسيتوقف mongod عن العمل أثناء الإقلاع وستدخل الحاوية في حلقة إعادة تشغيل، لأن الملف الثنائي يحاول تنفيذ تعليمات لا يدعمها المعالج. غالباً ما يكون السبب هو معالجات Intel Celeron و Pentium القديمة، أو برمجيات المحاكاة (hypervisors) التي تخفي أعلام المعالج عن النظام الضيف. MongoDB 4.4 هو أحدث إصدار يعمل بدون AVX، وتقبل الصورة أيضاً إصدارات أقدم تصل إلى 3.6، لكن دعم 4.4 انتهى في فبراير 2024. أصدرت MongoDB إصدارات 4.4 في ديسمبر 2025 لإصلاح الثغرة CVE-2025-14847، ولكن لا يوجد ضمان لاستمرار ذلك مع الثغرات القادمة، كما أن الإصدارات الأقدم تفتقر إلى تحديثات أمنية أكثر. الانتقال إلى خادم بمعالج أحدث هو الحل الأفضل. على خوادم ARM VPS لا تظهر هذه المشكلة، لأن AVX هي مجموعة تعليمات خاصة بـ x86، وتوفر كلتا الصورتين إصدارات arm64. إذا كنت تختار بين الاثنين، فإن الفروقات بين خطط ARM و x86 VPS تتجاوز مجرد السعر.

ثبّت تطبيق UniFi Network باستخدام Docker Compose

يُعد Docker الخيار الأقل عرضة للمفاجآت، لأنّه يتيح لك تثبيت MongoDB على إصدار يدعمه التطبيق بدلاً من استخدام الإصدار الذي توفّره توزيعتك. إذا لم يكن Docker مثبتاً على الخادم بعد، فـثبّت Docker على VPS أولاً.

mkdir -p ~/unifi/config ~/unifi/db
cd ~/unifi

يحتاج MongoDB إلى مستخدم قبل أن يتمكن التطبيق من تسجيل الدخول. تشغّل صورة MongoDB الرسمية أي برنامج نصي تجده في /docker-entrypoint-initdb.d عند التشغيل الأول. احفظ ما يلي باسم ~/unifi/init-mongo.sh:

#!/bin/bash
if which mongosh > /dev/null 2>&1; then
  mongo_init_bin='mongosh'
else
  mongo_init_bin='mongo'
fi
"${mongo_init_bin}" <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "${MONGO_PASS}",
  roles: [
    "clusterMonitor",
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_audit", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_restore", role: "dbOwner" }
  ]
})
EOF

يُشغَّل هذا البرنامج النصي فقط عندما يكون مجلد قاعدة البيانات فارغاً. إذا بدأت الحزمة مرة واحدة باستخدام كلمة المرور الخاطئة، فسيُنشأ المستخدم بهذه الكلمة، ولن يؤدي تعديل ملف Compose بعد ذلك إلى تغيير شيء، لأن البرنامج النصي لن يُشغَّل مجدداً. يتمثل العَرَض في تسجيل حاوية التطبيق أخطاء مصادقة MongoDB، بينما لا تظهر واجهة الويب إطلاقاً. في التثبيت الجديد، أوقف الحزمة، واحذف ~/unifi/db، ثم شغّلها مجدداً.

اكتب بعد ذلك ~/unifi/compose.yaml:

services:
  unifi-db:
    image: docker.io/mongo:8.0
    container_name: unifi-db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=change-this-root-password
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - ./db:/data/db
      - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    restart: unless-stopped

  unifi-network-application:
    image: lscr.io/linuxserver/unifi-network-application:10.5.67-ls141
    container_name: unifi-network-application
    depends_on:
      - unifi-db
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - MONGO_PASS=change-this-unifi-password
      - MONGO_HOST=unifi-db
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
      - MEM_LIMIT=1024
      - MEM_STARTUP=1024
    volumes:
      - ./config:/config
    ports:
      - "8080:8080"
      - "3478:3478/udp"
      - "127.0.0.1:8443:8443"
    restart: unless-stopped

تم تثبيت وسمَي الصورتين عمداً. كان 10.5.67-ls141 هو إصدار التطبيق الحالي في August 2026، لذلك تحقّق من قائمة إصدارات الصورة وثبّت الإصدار الحالي عند التثبيت. وسم قاعدة البيانات أهم. لا يرقّي MongoDB ملفات بياناته تلقائياً بين الإصدارات الرئيسية، لذلك سيجلب mongo:latest يوماً ما إصداراً رئيسياً جديداً، ويرفض فتح الملفات الموجودة، ثم يعيد التشغيل في حلقة متكررة. ثبّت الإصدار الرئيسي وانقله بصورة مقصودة. تدعم UniFi Network 8.1 والإصدارات الأحدث MongoDB من 3.6 إلى 7.0، وأضاف الإصدار 9.0 دعم MongoDB 8.0.

يجب أن يتطابق PUID وPGID مع مستخدم فعلي على الخادم، وإلا ستصبح الملفات الموجودة ضمن ./config مملوكة لهوية لا تستطيع الكتابة فيها. شغّل id لمعرفة القيم الخاصة بك. يوضّح كيفية عمل PUID وPGID في صور الحاويات شكل المشكلة عند عدم التطابق.

شغّلها وراقب السجل:

docker compose up -d
docker compose ps
docker compose logs -f unifi-network-application

يجب أن يعرض docker compose ps الحاويتين بالحالة running. تكون unifi-db العالقة في restarting ناتجة إما عن مشكلة AVX المذكورة أعلاه أو عن مشكلة صلاحيات في ./db. بعد استقرار السجل، تحقّق من المستمعَين:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8443/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/inform

يعني ظهور أي رمز حالة HTTP أن المستمع مرتبط بمنفذ ويستجيب. يعني Connection refused أن التطبيق لا يزال قيد التشغيل، وقد يستغرق ذلك دقيقة أو دقيقتين على VPS صغير عند التشغيل الأول، أو أن التطبيق لم يبدأ مطلقاً.

الوصول إلى واجهة الإدارة دون كشفها

يتم نشر المنفذ 8443 على 127.0.0.1 في الملف أعلاه، لذا في إصدار Docker Engine 28.0.0 أو أحدث، لا يمكن لأي شيء خارج الـVPS الوصول إلى واجهة الإدارة. في الإصدارات الأقدم، يمكن للمضيفين الآخرين على نفس نطاق L2، مثل الأجهزة الموجودة على نفس محول الشبكة، الوصول إلى المنافذ المنشورة على localhost، لذا شغّل docker version وقم بالترقية أولاً إذا كان الخادم يبلغ عن أي إصدار أقدم. قم بتوجيه المنفذ عبر SSH لتشغيل معالج الإعداد:

ssh -L 8443:127.0.0.1:8443 you@vps.example.com

اترك تلك الجلسة مفتوحة وتصفح https://127.0.0.1:8443. الشهادة موقعة ذاتياً، لذا سيحذرك المتصفح مرة واحدة. أنشئ حساب المسؤول، وسمِّ الموقع، وتخطَّ اعتماد الجهاز في الوقت الحالي.

يعد نفق SSH خياراً جيداً لمسؤول واحد. بالنسبة للفريق، امنح الـVPS عنواناً خاصاً واربط الواجهة به بدلاً من ذلك. يوفر كل من شبكة WireGuard VPN على الـVPS الخاص بك وموجه شبكة فرعية Tailscale عنواناً لا يمكن توجيه حركة المرور إليه إلا من قبل أفراد فريقك. غيّر المنفذ المنشور إلى 10.8.0.1:8443:8443 لـWireGuard، أو إلى العنوان الذي يعينه Tailscale. هناك عقبة واحدة: لا يمكن لـDocker النشر على عنوان غير موجود بعد، لذا يجب أن تعمل واجهة النفق قبل بدء الحاوية، وإلا ستفشل الحاوية مع خطأ في الربط (bind error).

لماذا لا يعتمد جهاز UniFi البعيد

يبحث جهاز UniFi افتراضياً عن وحدة التحكم عبر البث في الشبكة المحلية، باستخدام منفذ UDP ‏10001. لا يغادر البث الشبكة المحلية، لذلك لن يكتشف جهاز موجود في مكتب بمدينة أخرى وحدة تحكم تعمل على VPS. هذا هو الاعتماد عبر Layer 3، وهنا يواجه معظم المستخدمين المشكلة. الجهاز سليم ووحدة التحكم سليمة. لم يحدد أي شيء للجهاز المكان الذي يجب أن يبحث فيه.

أولاً، حدّد لوحدة التحكم العنوان الذي يجب أن توزّعه. في إعدادات وحدة التحكم، ضمن قسم System، يوجد إعداد inform host مع خيار override. اضبطه على اسم المضيف العام أو عنوان IP العام لـVPS. إذا لم تفعل ذلك، تعلن وحدة التحكم العنوان الذي تراه على واجهتها الخاصة. داخل شبكة Docker bridge يكون هذا عنواناً خاصاً مثل 172.18.0.3. يتلقى الجهاز هذا العنوان، ولا يستطيع توجيه traffic إليه، ثم يعود إلى البحث.

بعد ذلك، وجّه الجهاز إلى هذا العنوان. اتصل بالجهاز عبر SSH من الشبكة المحلية البعيدة. يقبل الجهاز الذي في حالة الإعداد الافتراضية اسم المستخدم ubnt وكلمة المرور ubnt:

ssh ubnt@192.168.1.20
set-inform http://vps.example.com:8080/inform

تفتح إصدارات firmware الأحدث قائمة بدلاً من shell. شغّل الأمر نفسه كأمر واحد:

ssh ubnt@192.168.1.20 mca-cli-op set-inform http://vps.example.com:8080/inform

يظهر الجهاز الآن في وحدة التحكم بحالة جاهز للاعتماد. انقر على Adopt، فتتغير الحالة إلى Adopting. الجزء المفاجئ هنا هو أنّه يجب عليك عادةً تشغيل set-inform مرة ثانية. يعيد الجهاز التشغيل للدخول في عملية provisioning، ثم يعود إلى عنوان inform المحفوظ في إعداداته الخاصة، والذي لم تُكمل وحدة التحكم استبداله بعد. يؤدي تشغيل الأمر مرة أخرى أثناء ظهور الحالة Adopting إلى إكمال التسليم. اكتب info على الجهاز لعرض عنوان inform والحالة المحفوظين حالياً.

إذا كان الجهاز قد اعتمدته وحدة تحكم أخرى من قبل، فلن يكمل set-inform العملية وحده، لأن الجهاز لا يزال يحتفظ ببيانات اعتماد وحدة التحكم السابقة. أعده أولاً إلى إعدادات المصنع الافتراضية، إما باستخدام زر reset أو باستخدام set-default عبر SSH ببيانات الاعتماد القديمة.

إذا كان لديك أكثر من بضعة أجهزة، فاستخدم DHCP بدلاً من ذلك. يحمل خيار DHCP (dynamic host configuration protocol) رقم 43 قيمة خاصة بالمورّد، وتقرأ أجهزة UniFi عنوان inform من suboption 2. أنشئ السلسلة السداسية على أي جهاز Linux:

URL="http://vps.example.com:8080/inform"
HEX=$(printf '%s' "$URL" | od -An -tx1 | tr -d ' \n')
printf '02%02x%s\n' "${#URL}" "$HEX"

بالنسبة إلى http://192.168.3.10:8080/inform، وهي سلسلة من 31 بايت، يطبع الأمر 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d. الصق النتيجة في حقل DHCP option 43 في الموجّه باعتبارها قيمة سداسية. يتعلم كل جهاز يقلع على تلك الشبكة عنوان وحدة التحكم من lease الخاص به، من دون استخدام SSH إطلاقاً. تعرض الأدلة الأقدم suboption 1 بدلاً من ذلك، أي 0104 متبوعاً بالبايتات الأربعة لعنوان IPv4 بصيغة سداسية، ولا تزال الأجهزة تقبل هذا الشكل.

يوجد مسار ثالث إذا كنت تدير DNS في الموقع. يحاول جهاز UniFi حل اسم المضيف unifi عند الإقلاع، لذلك يؤدي إنشاء سجل A للاسم unifi وتوجيهه إلى عنوان VPS إلى اعتماد الأجهزة من دون إعداد كل جهاز على حدة. لا يفيد ذلك إلا في المواقع التي تتحكم فيها بمحلّل الأسماء الذي تستخدمه الأجهزة فعلياً.

ما هي منافذ UniFi التي يجب فتحها، وما التي يجب إبقاؤها خاصة

يجب أن يكون منفذان متاحين من موقع بعيد لغرض الاعتماد (adoption) والإدارة اليومية.

المنفذ TCP 8080 هو قناة الإبلاغ (inform channel)، ويتصل به كل جهاز معتمد. الحمولة داخل هذه القناة مشفرة بمعيار AES باستخدام مفتاح منحه المتحكم للجهاز أثناء الاعتماد، ولهذا السبب يُعد استخدام HTTP العادي هو الإعداد الافتراضي هنا.
المنفذ UDP 3478 مخصص لـ STUN (أدوات اجتياز الجلسة لـ NAT)، والتي تستخدمها الأجهزة للحفاظ على مسار عودة إلى المتحكم.

تتطلب بعض الميزات منافذ إضافية. يضيف مرجع منافذ Ubiquiti المنفذ TCP 5671 لتسجيل تدفق حركة المرور (Traffic Flow) من بوابات UXG المعتمدة على شبكات L2 أو L3. لذا، إذا كان الموقع يحتوي على UXG يرسل تقارير إلى هذا المتحكم وترغب في الحصول على تلك السجلات، افتح المنفذ 5671 لهذا الموقع أيضاً.

يجب إبقاء كل شيء آخر مغلقاً على خادم VPS.

المنفذ TCP 8443 هو واجهة الإدارة. هذا هو المنفذ الذي يجب ألا يكون عاماً أبداً. فهو يحتوي على إعدادات كل موقع يديره المتحكم، خلف كلمة مرور واحدة.
المنفذان UDP 10001 و UDP 1900 مخصصان لاكتشاف البث (broadcast discovery). لا تعبر رسائل البث عبر الإنترنت، لذا فإن فتحهما لا يحقق أي فائدة.
المنفذان TCP 8880 و TCP 8843 مخصصان لإعادة توجيه بوابة الضيوف (guest portal). لا تفتحهما إلا إذا كنت تشغل بوابة ضيوف.
المنفذ TCP 6789 مخصص لاختبار السرعة عبر الهاتف المحمول، والمنفذ UDP 5514 مخصص لسجلات النظام البعيدة (remote syslog). أضفهما فقط عند الحاجة لاستخدامهما.
المنفذ TCP 27117 مخصص لقاعدة بيانات MongoDB. في ملف compose أعلاه، لا تنشر قاعدة البيانات أي منافذ على الإطلاق، لذا فهي موجودة فقط على شبكة Docker الداخلية. أبقِ الأمر على هذا النحو.

إذا كانت مواقعك تمتلك عناوين عامة ثابتة، اسمح فقط لتلك العناوين:

sudo ufw allow OpenSSH
sudo ufw allow proto tcp from 203.0.113.4 to any port 8080
sudo ufw allow proto udp from 203.0.113.4 to any port 3478
sudo ufw enable
sudo ufw status verbose

يغطي أساسيات ufw لجدار حماية VPS إعداد الرفض الافتراضي الذي تفترضه تلك القواعد.

هناك فخ يقع فيه المستخدمون دائماً. المنافذ المنشورة عبر Docker تتجاوز ufw. فنشر منفذ يكتب قواعد NAT والتوجيه مباشرة في iptables، وتتم تصفية تلك الحركة في سلسلة Docker الخاصة، وليس في سلسلة INPUT التي يديرها ufw. لذا قد تبدو ufw deny 8443 صحيحة في ufw status بينما يظل المنفذ مفتوحاً أمام العالم. اختبر المنفذ من جهاز آخر، ولا تختبره أبداً من داخل خادم VPS نفسه:

nc -vz vps.example.com 8443

النتيجة المطلوبة هي رفض الاتصال أو انتهاء المهلة (timeout). إذا تم الاتصال، فهذا يعني أن المنفذ عام بغض النظر عما يقوله ufw. الحل الموثوق هو ذلك الموجود بالفعل في ملف compose: انشر المنفذ على 127.0.0.1 أو على عنوان نفق (tunnel address)، بحيث لا يقوم Docker بربطه بالواجهة العامة أبداً. تعمل القاعدة في سلسلة DOCKER-USER أيضاً، لكن الربط (binding) أبسط، ولا يمكن لخطأ في ترتيب القواعد أن يبطله.

ماذا عن برامج التثبيت الخاصة بـ Ubiquiti؟

تنشر Ubiquiti حزمة Debian لتطبيق الشبكة (Network Application)، واعتباراً من أكتوبر 2026 يصنّف مركز المساعدة الخاص بها هذا المسار كطريقة قديمة (legacy) ويسمّي UniFi OS Server المعيار الجديد للاستضافة الذاتية. تعمل الحزمة، ولكنها تثير في إصدارات Ubuntu الحالية تساؤلاً حول MongoDB لم تعد التوزيعة توفر له إجابة: لا توفر Ubuntu 22.04 و24.04 حزمة خادم MongoDB، لذا ينتهي بك الأمر بإضافة مستودع MongoDB الخاص ومطابقة الإصدارات يدوياً. تقوم الحاوية المذكورة أعلاه بهذه المطابقة في وسم (tag) مثبت واحد، وهذا هو سبب اعتمادها كمسار في هذا الدليل.

المنتج الأحدث للاستضافة الذاتية من Ubiquiti هو UniFi OS Server، الذي يشغّل تطبيقات UniFi داخل حاويات Podman ويمنحك نفس نظام UniFi OS الموجود في أجهزة التحكم الخاصة بهم. اعتباراً من أكتوبر 2026، تطلب Ubiquiti معالج x86-64، ونظام Ubuntu 24.04 أو أحدث أو Debian 13 أو أحدث، وPodman 4.9.3 أو أحدث مع slirp4netns 1.2 أو أحدث، وذاكرة وصول عشوائي (RAM) لا تقل عن 2 جيجابايت، ومساحة تخزين فارغة 10 جيجابايت. رابط التثبيت الموجود في صفحة الإصدارات أو التنزيلات الخاصة بـ Ubiquiti خاص بإصدار معين: انقر بزر الفأرة الأيمن على التنزيل، وانسخ عنوان الرابط، ثم اجلبه باستخدام curl -O أو wget. يحصل كل إصدار على رابط URL خاص به، لذا يمكن للدليل تثبيت إصدار واحد ولكنه لا يستطيع تزويدك برابط يشير دائماً إلى الأحدث. يقوم برنامج التثبيت بإعداد خدمة systemd تسمى uosserver، والتي توقفها وتشغلها باستخدام systemctl. اختر هذا المسار إذا كنت تفضل حزم المورّد الرسمية. اختر حزمة الحاويات إذا كنت ترغب في تثبيت الإصدارات بنفسك والحفاظ على الخادم متاحاً لأعمال أخرى.

مكان نسخ UniFi الاحتياطية وكيفية إخراجها من الخادم

يكتب المتحكم نسخه الاحتياطية وفق جدول تحدده في Settings، ضمن قسم النسخ الاحتياطي، مع تحديد عدد النسخ التي يجب الاحتفاظ بها. تُحفظ الملفات في /config/data/backup/autobackup داخل الحاوية، وهو المسار ~/unifi/config/data/backup/autobackup على المضيف، وتكون أسماؤها بالصيغة autobackup_10.5.67_20260813_1200_1755086400004.unf.

تحقق من ظهورها فعلياً:

ls -l ~/unifi/config/data/backup/autobackup

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

mkdir -p ~/unifi/config/data/backup/autobackup
docker compose restart unifi-network-application

يحتوي ملف .unf على إعدادات الموقع وحسابات المسؤولين، لذلك تعامل معه مثل مفتاح تشفير. اسحب نسخاً منه إلى جهاز تتحكم فيه واحتفظ بها بشكل خاص:

rsync -av you@vps.example.com:~/unifi/config/data/backup/autobackup/ ~/unifi-backups/

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

ما الذي يمكن أن يتعطل أثناء ترقية وحدة التحكم

أنشئ نسخة احتياطية يدوية ونزّلها قبل كل ترقية. ثم:

docker compose pull
docker compose up -d
docker compose logs -f unifi-network-application

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

الذاكرة هي المشكلة التالية. يحتاج الإصدار الأكبر إلى heap أكبر. إذا بدأ التطبيق، وعمل بضع دقائق، ثم توقف، فارفع MEM_LIMIT وMEM_STARTUP إلى 1536 أو 2048 ثم أعد التشغيل. يؤكد dmesg -T | grep -i 'killed process' على المضيف ما إذا كانت النواة هي التي أنهت العملية.

البرنامج الثابت للأجهزة هو الخطر الذي ينساه الناس. بعد أن تُرقّي وحدة التحكم نفسها، ستعرض ترقيات للبرنامج الثابت للأجهزة المعتمدة. لا توافق عليها في الجلسة نفسها. إذا تزامنت ترقية جهاز مع ترقية وحدة التحكم وانقطع الرابط بينهما، فقد يبقى الجهاز في حالة تهيئة جزئية، وستعود إلى set-inform عبر SSH على جهاز موجود في مبنى آخر.

نافذة الترقية نفسها أقل إزعاجاً مما تبدو. تواصل الأجهزة تمرير حركة الشبكة أثناء إعادة تشغيل وحدة التحكم، لذلك لا يلاحظ المستخدمون شيئاً. لكن بوابة الضيوف وRADIUS يتوقفان إذا كانت وحدة التحكم تقدّمهما، لذا اختر وقتاً لا يستخدمهما فيه أحد. من المفيد معرفة ما إذا توقفت وحدة التحكم بصمت عند الساعة 3 صباحاً، لذلك وجّه مراقب حالة Uptime Kuma إلى المنفذ 8080 ودعه يخبرك.

البديل الموثوق: وحدة التحكم المستضافة من Ubiquiti

تبيع شركة Ubiquiti نفس الخدمة كمنتج مُدار. اعتباراً من أكتوبر 2026، يوفّر متجر Ubiquiti في الولايات المتحدة هذه الخدمة تحت اسم Official UniFi Hosting، بأسعار تبدأ من 29 دولاراً شهرياً، وتدعم إدارة ما يصل إلى 1,000 جهاز UniFi Network على خادم تديره Ubiquiti. أما التطبيق الذي قمت بتثبيته ذاتياً للتو فهو مجاني ولا يتطلب أي اشتراك.

اختر وحدة التحكم المستضافة إذا كنت تدير موقعاً واحداً وتفضل الدفع مقابل تجنب مهام الصيانة. اختر خادم VPS إذا كنت تدير عدة مواقع، أو إذا كنت ترغب في تشغيل وحدة التحكم داخل شبكة تسيطر عليها ومشاركتها مع خدمات أخرى تقوم بتشغيلها. فارق التكلفة ملموس على النطاق الصغير، لكنه ليس العامل الوحيد الذي يجب مراعاته: ففي حالة الخدمة المستضافة، تعتمد على وقت تشغيل الخادم الخاص بالشركة، بينما في حالة الـVPS، أنت المسؤول عن وقت التشغيل، بما في ذلك التعامل مع حالات امتلاء القرص ليلاً. إذا كان الخادم سيثبت جدواه في كلتا الحالتين، فإن ما يمكنك تشغيله أيضاً على خادم VPS هو القائمة التي يجب عليك قراءتها تالياً.

FAQ

لماذا لا يتم اعتماد جهاز UniFi الخاص بي على وحدة تحكم موجودة في خادم افتراضي خاص (VPS)؟

تكتشف الأجهزة وحدات التحكم عن طريق البث عبر منفذ UDP 10001، ولا يخرج هذا البث من الشبكة المحلية، لذا لا يمكن لجهاز في موقع بعيد العثور على وحدة تحكم عبر الإنترنت العام. اضبط خيار "تجاوز مضيف الإبلاغ" (inform host override) في إعدادات نظام وحدة التحكم ليشير إلى اسم مضيف الـ VPS الخاص بك، ثم وجّه الجهاز إليه باستخدام ssh ubnt@<device-ip> متبوعاً بـ set-inform http://vps.example.com:8080/inform. إذا ظل الجهاز في حالة "الاعتماد" (Adopting)، شغّل set-inform مرة أخرى أثناء وجوده في هذه الحالة. إذا كانت وحدة تحكم أخرى قد اعتمدته سابقاً، فأعد ضبطه إلى إعدادات المصنع أولاً، لأنه لا يزال يحتفظ ببيانات اعتماد وحدة التحكم القديمة.

ما مقدار ذاكرة الوصول العشوائي (RAM) التي تحتاجها وحدة تحكم UniFi ذاتية الاستضافة؟

تعد 2 جيجابايت هي الحد الأدنى للتشغيل، بينما توفر 4 جيجابايت أداءً مريحاً. يعتمد التطبيق على Java وMongoDB، ويقوم كلاهما بتحديد حجم ذاكرته بشكل منفصل: تحد صورة الحاوية كومة ذاكرة Java بـ 1024 ميجابايت افتراضياً، بينما تستهلك ذاكرة التخزين المؤقت WiredTiger الخاصة بـ MongoDB نصف ذاكرة RAM التي تزيد عن 1 جيجابايت. على معمارية x86_64، تأكد أيضاً من أن المعالج يدعم تعليمات AVX باستخدام grep -m1 -o avx /proc/cpuinfo، لأن MongoDB 5.0 والإصدارات الأحدث لن تبدأ بدونها، مما سيؤدي إلى إعادة تشغيل حاوية قاعدة البيانات في حلقة مفرغة.

هل يجب أن أعرض المنفذ 8443 على الإنترنت؟

لا. المنفذ 8443 هو واجهة الإدارة، ويحتوي على إعدادات كل موقع تديره وحدة التحكم. انشره على 127.0.0.1 باستخدام Docker Engine 28.0.0 أو أحدث وادخل إليه عبر ssh -L 8443:127.0.0.1:8443 you@vps.example.com، أو اربطه بعنوان WireGuard أو Tailscale. لغرض الاعتماد والإدارة، تحتاج مواقعك إلى الوصول إلى TCP 8080 وUDP 3478، بالإضافة إلى TCP 5671 إذا كان بوابة UXG يرسل سجلات تدفق حركة المرور (Traffic Flow) إلى وحدة التحكم، ويمكنك تقييد هذه المنافذ على العناوين العامة للمواقع إذا كانت ثابتة. تذكر أن المنفذ المنشور عبر Docker لا يخضع للتصفية بواسطة ufw، لذا اختبر الاتصال من جهاز خارجي بدلاً من الوثوق بـ ufw status.

هل تتوقف شبكتي عن العمل إذا تعطلت وحدة تحكم الـ VPS؟

لا. تستمر نقاط الوصول والمحولات المعتمدة في توجيه حركة المرور باستخدام الإعدادات التي دفعتها وحدة التحكم مسبقاً، لذا يظل العملاء متصلين وتستمر شبكة Wi-Fi في العمل. ما يتوقف هو الإدارة فقط. ستفقد لوحة التحكم وجمع الإحصائيات، بالإضافة إلى أي ميزة مباشرة تقدمها وحدة التحكم، مثل مصادقة بوابة الضيوف أو RADIUS عندما تكون وحدة التحكم هي خادم RADIUS.

أين تخزن وحدة تحكم UniFi نسخها الاحتياطية التلقائية؟

في صورة الحاوية المستخدمة هنا، يتم تخزينها في /config/data/backup/autobackup، والتي يتم ربطها بمسار بياناتك بالإضافة إلى data/backup/autobackup على المضيف، كملفات .unf مسماة وفقاً للإصدار والطابع الزمني. في بعض عمليات التثبيت الجديدة، لا يوجد المجلد autobackup، وبالتالي لا يكتب النسخ الاحتياطي المجدول أي شيء دون الإبلاغ عن خطأ، لذا تحقق من محتويات ذلك المجلد بعد يوم من ضبط الجدول الزمني وأنشئه بنفسك إذا كان فارغاً. انسخ الملفات خارج الـ VPS، لأن ملف .unf يحتوي على إعدادات الموقع وحسابات المسؤول.

#unifi#ubiquiti#network-management#Docker #استضافة ذاتية