تحریر: Matt Connor 2026-10-12

VPS پر UniFi controller کیسے انسٹال کریں

Q: UniFi controller اپنے automatic backups کہاں محفوظ کرتا ہے؟

یہاں استعمال ہونے والی container image میں یہ backups /config/data/backup/autobackup میں محفوظ ہوتے ہیں۔ یہ path host پر آپ کے data path کے ساتھ data/backup/autobackup سے map ہوتا ہے، اور backups .unf files کی صورت میں version اور timestamp کے نام سے بنائے جاتے ہیں۔ کچھ fresh installs میں autobackup directory موجود نہیں ہوتی۔ ایسی صورت میں scheduled backup error رپورٹ کیے بغیر کچھ بھی نہیں لکھتا۔ اس لیے schedule set کرنے کے ایک دن بعد اس directory کی فہرست دیکھیں، اور اگر یہ خالی ہو تو اسے خود بنائیں۔ Files کو VPS سے باہر copy کریں، کیونکہ ایک .unf میں site configuration اور administrator accounts شامل ہوتے ہیں۔

UniFi Network Application کو VPS پر ہوسٹ کرنے کا مکمل طریقہ سیکھیں۔ اس گائیڈ میں Docker، MongoDB کنفیگریشن، RAM کی ضروریات، اور Layer 3 adoption کے لیے set-inform کمانڈ شامل ہے۔

VPS پر UniFi controller اصل میں کیا کرتا ہے

VPS پر موجود UniFi controller ایک ایسا انتظامی سرور ہے جو ان سائٹس کے ڈاؤن ہونے پر بھی قابل رسائی رہتا ہے جنہیں یہ manage کرتا ہے۔ یہ سافٹ ویئر Ubiquiti کی UniFi Network Application ہے: ایک Java پروگرام جس کے پیچھے MongoDB ڈیٹا بیس ہوتا ہے۔ یہ آپ کے access points اور switches کو configure کرتا ہے، ان کے اعداد و شمار (statistics) کو محفوظ کرتا ہے، اور admin interface فراہم کرتا ہے۔ یہ کلائنٹ کا ٹریفک نہیں اٹھاتا۔

یہ آخری نکتہ فیصلہ کرتا ہے کہ اسے کہاں ہونا چاہیے۔ اگر آپ controller کو اس دفتر کے اندر کسی مشین پر رکھیں جسے وہ manage کر رہا ہے، تو نیٹ ورک کے ڈاؤن ہوتے ہی آپ اسے دیکھنے والا ٹول بھی کھو دیں گے۔ اگر آپ اسے ایک مستحکم public address والے VPS پر رکھیں، تو یہ چلتا رہتا ہے، ڈیٹا اکٹھا کرتا رہتا ہے، اور ایک ہی جگہ سے کئی سائٹس پر موجود ڈیوائسز کو adopt کر سکتا ہے۔ اسے uptime کی ضرورت ہوتی ہے، نہ کہ زیادہ طاقتور ہارڈویئر کی۔

جب controller آف لائن ہوتا ہے، تو adopt شدہ access points اور switches پہلے سے بھیجی گئی configuration کے مطابق ٹریفک کو فارورڈ کرتے رہتے ہیں۔ آپ ڈیش بورڈ اور اعداد و شمار سے محروم ہو جاتے ہیں، نیز ان تمام فیچرز سے بھی جن کے لیے controller کا لائیو ہونا ضروری ہے: جیسے guest portal لاگ ان، یا RADIUS (remote authentication dial-in user service) اگر controller ہی آپ کا RADIUS سرور ہے۔ کلائنٹس کا کنکشن برقرار رہتا ہے۔

UniFi controller کو کتنی RAM درکار ہوتی ہے؟

دو GB کم از کم ضرورت ہے، اور خریدتے وقت 4 GB منتخب کریں۔ ایک ہی box میں memory استعمال کرنے والے دو اجزا ہیں: Java اور MongoDB۔ دونوں ایک دوسرے سے آزادانہ طور پر اپنی memory کی ضرورت طے کرتے ہیں۔

Java heap کی حد MEM_LIMIT مقرر کرتا ہے، جسے container image بطور default 1024 MB پر set کرتی ہے۔ دوسرا حصہ MongoDB ہے۔ اس کا WiredTiger storage engine 1 GB سے زیادہ RAM کے نصف، یا 256 MB، میں سے جو زیادہ ہو، اتنا cache مقرر کرتا ہے۔ 2 GB VPS پر یہ تقریباً 512 MB cache، 1 GB heap، JVM کی اپنی non-heap memory، اور operating system کے برابر بنتا ہے۔ یہ عام استعمال تک چل جاتا ہے، لیکن مصروف دن میں kernel کا out-of-memory killer دونوں میں سے کسی ایک process کو ختم کر دیتا ہے۔ کسی بھی غیر واضح restart کے بعد dmesg -T | grep -i 'killed process' چلائیں تاکہ معلوم ہو سکے کہ یہی وجہ تھی یا نہیں۔ اگر آپ کے پاس 2 GB ہی ہے تو swap file شامل کریں۔

CPU اور disk کی ضروریات کم ہیں۔ ایک یا دو vCPU چند درجن devices کے لیے کافی ہیں۔ ابتدا میں 20 GB disk مختص کریں اور اس کی نگرانی کریں، کیونکہ database میں اضافہ آپ کے دیکھے جانے والے clients کی تعداد اور statistics محفوظ رکھنے کی مدت کے ساتھ ہوتا ہے۔ صرف controller چلانے پر 4 GB box کی زیادہ تر capacity خالی رہتی ہے۔ اگر آپ اس کے ساتھ دوسری ایپ چلانے کا منصوبہ رکھتے ہیں تو پہلے دوسری ایپ کی ضرورت کے مطابق resources مقرر کریں، کیونکہ PhotoPrism اور Immich کی RAM کی کم از کم ضروریات بہت مختلف ہیں اور دونوں میں سے ہر ایک کو controller سے زیادہ RAM درکار ہوتی ہے۔

ایک CPU feature اہم ہے، اور سستے plan میں اسے نظر انداز کرنا آسان ہے:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 اور بعد کے versions کو x86_64 hardware پر AVX (advanced vector extensions) درکار ہوتا ہے۔ اگر یہ command کوئی output نہ دے تو mongod startup کے دوران ختم ہو جاتا ہے اور container بار بار restart ہوتا رہتا ہے، کیونکہ binary ایسی instruction چلاتی ہے جو CPU میں موجود نہیں ہوتی۔ پرانے Intel Celeron اور Pentium hosts اس مسئلے کی عام وجہ ہیں۔ ایسے hypervisors بھی یہی مسئلہ پیدا کرتے ہیں جو guest سے CPU flags چھپا دیتے ہیں۔ MongoDB 4.4 جدید ترین release ہے جو AVX کے بغیر چلتی ہے، اور image 3.6 تک کے پرانے versions بھی قبول کرتی ہے، لیکن 4.4 فروری 2024 میں end of life ہو گیا۔ MongoDB نے CVE-2025-14847 کے لیے دسمبر 2025 کی fix میں 4.4 builds جاری کیے تھے، لیکن آئندہ vulnerability کے لیے ایسا ہونے کی کوئی ضمانت نہیں ہے، اور پرانے releases اس سے بھی زیادہ پیچھے ہیں۔ جدید CPU والے host پر منتقل ہونا بہتر حل ہے۔ ARM VPS پر یہ سوال پیدا نہیں ہوتا، کیونکہ AVX x86 instruction set ہے، اور دونوں images arm64 builds بھی جاری کرتی ہیں۔ اگر آپ دونوں میں انتخاب کر رہے ہیں تو ARM اور x86 VPS plans کے درمیان فرق قیمت سے کہیں زیادہ پہلوؤں پر مشتمل ہے۔

Docker Compose کے ساتھ UniFi Network Application انسٹال کریں

Docker استعمال کرنا سب سے محفوظ طریقہ ہے، کیونکہ یہ آپ کو MongoDB کا وہ ورژن استعمال کرنے کی سہولت دیتا ہے جسے ایپلیکیشن سپورٹ کرتی ہے، بجائے اس کے کہ آپ اپنی ڈسٹری بیوشن کے فراہم کردہ ورژن پر انحصار کریں۔ اگر سرور پر Docker موجود نہیں ہے تو پہلے VPS پر Docker انسٹال کریں۔

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 کی تصدیق میں ناکامی (authentication failures) کے لاگز دکھائے گا اور ویب انٹرفیس کبھی ظاہر نہیں ہوگا۔ تازہ انسٹالیشن پر اس کا حل یہ ہے کہ اسٹیک کو روکیں، ~/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

دونوں امیج ٹیگز کو جان بوجھ کر پن (pin) کیا گیا ہے۔ 10.5.67-ls141 اگست 2026 میں ایپلیکیشن کا موجودہ ریلیز تھا، لہذا امیج کی ریلیز لسٹ چیک کریں اور انسٹالیشن کے وقت جو ورژن موجود ہو اسے پن کریں۔ ڈیٹا بیس کا ٹیگ زیادہ اہم ہے۔ MongoDB خود بخود اپنے ڈیٹا فائلز کو بڑے ورژنز (major versions) میں اپ گریڈ نہیں کرتا، اس لیے mongo:latest ایک دن نیا میجر ورژن پل (pull) کر لے گا، موجودہ فائلز کو کھولنے سے انکار کر دے گا، اور لوپ میں ری اسٹارٹ ہوتا رہے گا۔ میجر ورژن کو پن کریں اور اسے سوچ سمجھ کر اپ ڈیٹ کریں۔ UniFi Network 8.1 اور بعد کے ورژنز MongoDB 3.6 سے 7.0 تک کو سپورٹ کرتے ہیں، اور 9.0 نے MongoDB 8.0 کے لیے سپورٹ شامل کی ہے۔

PUID اور PGID کا ہوسٹ پر موجود ایک حقیقی صارف سے میل کھانا ضروری ہے، ورنہ ./config کے تحت موجود فائلز ایسی شناخت کی ملکیت بن جائیں گی جو انہیں لکھ (write) نہیں سکتی۔ اپنا یوزر آئی ڈی حاصل کرنے کے لیے 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 پر اجازت (permission) کا مسئلہ۔ جب لاگ مستحکم ہو جائے تو دونوں لسنرز کو چیک کریں:

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 پر ایک یا دو منٹ لگ سکتے ہیں، یا پھر یہ کہ ایپلیکیشن کبھی اسٹارٹ ہی نہیں ہوئی۔

منتظمین کے interface تک اسے public کیے بغیر رسائی حاصل کریں

اوپر موجود file میں port 8443 کو 127.0.0.1 پر publish کیا گیا ہے، اس لیے Docker Engine 28.0.0 یا اس کے بعد کے version میں VPS سے باہر کوئی host admin interface تک نہیں پہنچ سکتا۔ پرانے releases میں اسی L2 segment پر موجود دوسرے hosts، مثلاً اسی network switch سے منسلک machines، localhost پر publish کیے گئے ports تک پہنچ سکتے ہیں۔ اس لیے پہلے docker version چلائیں اور اگر server اس سے پرانا version دکھائے تو upgrade کریں۔ setup wizard چلانے کے لیے اسے SSH کے ذریعے forward کریں:

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

یہ session کھلا رہنے دیں اور https://127.0.0.1:8443 پر browse کریں۔ certificate self signed ہے، اس لیے browser ایک بار warning دکھائے گا۔ administrator account بنائیں، site کا نام دیں، اور فی الحال device adoption چھوڑ دیں۔

ایک administrator کے لیے SSH tunnel کافی ہے۔ ٹیم کے لیے VPS کو private address دیں اور interface کو اسی address پر bind کریں۔ اپنے VPS پر WireGuard VPN اور Tailscale subnet router دونوں آپ کو ایسا address دیتے ہیں جس تک صرف آپ کے لوگ route کر سکتے ہیں۔ WireGuard کے لیے published port کو 10.8.0.1:8443:8443 پر تبدیل کریں، یا اسے Tailscale کے تفویض کردہ address پر bind کریں۔ ایک اہم مسئلہ یہ ہے کہ Docker ایسے address پر publish نہیں کر سکتا جو ابھی موجود نہ ہو۔ اس لیے container شروع ہونے سے پہلے tunnel interface کا up ہونا ضروری ہے، ورنہ container bind error کے ساتھ fail ہو جائے گا۔

ایک ریموٹ UniFi ڈیوائس کیوں adopt نہیں ہوتی

باکس سے باہر نکلنے پر ایک UniFi ڈیوائس اپنے controller کو لوکل نیٹ ورک پر UDP port 10001 کے ذریعے براڈکاسٹ کر کے تلاش کرتی ہے۔ براڈکاسٹ LAN سے باہر نہیں جاتا، اس لیے دوسرے شہر کے دفتر میں موجود ڈیوائس کبھی بھی VPS پر موجود controller کو دریافت نہیں کر سکے گی۔ یہ Layer 3 adoption ہے، اور یہی وہ مرحلہ ہے جہاں زیادہ تر لوگ پھنس جاتے ہیں۔ ڈیوائس ٹھیک ہے اور controller بھی ٹھیک ہے۔ کسی چیز نے ڈیوائس کو یہ نہیں بتایا کہ اسے کہاں تلاش کرنا ہے۔

سب سے پہلے، controller کو بتائیں کہ کون سا ایڈریس دینا ہے۔ Controller کی Settings میں، System سیکشن کے اندر، ایک inform host کی ترتیب ہے جس میں override کا آپشن موجود ہے۔ اسے اپنے VPS کے public hostname یا IP پر سیٹ کریں۔ اس کے بغیر controller وہی ایڈریس مشتہر کرتا ہے جو اسے اپنے انٹرفیس پر نظر آتا ہے، جو کہ Docker bridge نیٹ ورک کے اندر 172.18.0.3 جیسا ایک پرائیویٹ ایڈریس ہوتا ہے۔ ڈیوائس کو وہ ایڈریس موصول ہوتا ہے، وہ اس تک روٹ نہیں کر پاتی، اور دوبارہ تلاش شروع کر دیتی ہے۔

پھر ڈیوائس کو اس ایڈریس کی طرف پوائنٹ کریں۔ ریموٹ LAN پر موجود ڈیوائس پر SSH کریں۔ فیکٹری ڈیفالٹ ڈیوائس ubnt یوزر نیم اور ubnt پاس ورڈ قبول کرتی ہے:

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

نئے ڈیوائس فرم ویئر آپ کو شیل کے بجائے مینو میں لے جاتے ہیں۔ وہی کام ایک سنگل کمانڈ کے طور پر چلائیں:

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

ڈیوائس اب controller میں adopt ہونے کے لیے تیار نظر آتی ہے۔ Adopt پر کلک کریں، اور اسٹیٹ Adopting میں تبدیل ہو جاتی ہے۔ یہاں وہ حصہ ہے جو سب کو حیران کرتا ہے: آپ کو عام طور پر set-inform دوسری بار چلانا پڑتا ہے۔ ڈیوائس ری اسٹارٹ ہو کر provisioning میں جاتی ہے اور اپنی کنفیگریشن میں محفوظ inform URL پر واپس آ جاتی ہے، جسے controller نے ابھی مکمل طور پر تبدیل نہیں کیا ہوتا۔ اسٹیٹ کے Adopting ہونے کے دوران کمانڈ کو دوبارہ چلانے سے ہینڈ اوور مکمل ہو جاتا ہے۔ ڈیوائس پر info ٹائپ کریں تاکہ وہ inform URL اور اسٹیٹ دیکھ سکیں جو اس وقت اس کے پاس موجود ہے۔

اگر ڈیوائس پہلے کسی اور controller کے ذریعے adopt کی گئی تھی، تو صرف set-inform کام مکمل نہیں کرے گا، کیونکہ اس کے پاس اب بھی اس پرانے controller کے اسناد (credentials) موجود ہیں۔ اسے پہلے فیکٹری ڈیفالٹ پر ری سیٹ کریں، یا تو ری سیٹ بٹن سے یا پرانے اسناد استعمال کرتے ہوئے SSH کے ذریعے set-default سے۔

چند ڈیوائسز سے زیادہ کے لیے، DHCP استعمال کریں۔ DHCP (dynamic host configuration protocol) option 43 ایک وینڈر مخصوص ویلیو لے کر جاتا ہے، اور UniFi ڈیوائسز suboption 2 سے inform URL پڑھ لیتی ہیں۔ کسی بھی 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) سے controller کا ایڈریس سیکھ لیتی ہے، بغیر کسی SSH کے۔ پرانی گائیڈز suboption 1 دکھاتی ہیں، 0104 جس کے بعد IPv4 ایڈریس کے چار بائٹس ہیکس میں ہوتے ہیں، اور ڈیوائسز اب بھی اس فارمیٹ کو قبول کرتی ہیں۔

اگر آپ سائٹ پر DNS چلاتے ہیں تو ایک تیسرا راستہ بھی موجود ہے۔ ایک UniFi ڈیوائس بوٹ ہونے پر unifi ہوسٹ نیم کو ریزولو کرنے کی کوشش کرتی ہے، لہذا unifi کے لیے ایک A record جو آپ کے VPS ایڈریس کی طرف اشارہ کرے، ڈیوائسز کو بغیر کسی فی ڈیوائس کام کے adopt کر لیتا ہے۔ یہ صرف وہاں مددگار ہے جہاں آپ اس ریزورور (resolver) کو کنٹرول کرتے ہیں جسے ڈیوائسز درحقیقت استعمال کرتی ہیں۔

UniFi کے کون سے ports کھولنے ہیں، اور کنہیں private رکھنا ہے

adoption اور روزمرہ management کے لیے remote site سے دو ports قابلِ رسائی ہونے چاہییں۔

TCP 8080 inform channel ہے، اور adopted ہر device اس سے connect ہوتا ہے۔ اس کے اندر موجود payload کو adoption کے دوران controller کی طرف سے device کو دی گئی key کے ذریعے AES سے encrypt کیا جاتا ہے، اسی لیے یہاں plain HTTP عام setting ہے۔
UDP 3478 STUN (session traversal utilities for NAT) ہے، جسے devices controller تک واپس راستہ برقرار رکھنے کے لیے استعمال کرتے ہیں۔

کچھ features کے لیے مزید ports درکار ہوتے ہیں۔ Ubiquiti کے port reference میں L2 یا L3 networks پر adopted UXG gateways سے Traffic Flow logging کے لیے TCP 5671 شامل ہے۔ اس لیے اگر کوئی site اس controller کو UXG کے ذریعے reports بھیجتی ہے اور آپ وہ logs چاہتے ہیں تو اس site کے لیے 5671 بھی کھولیں۔

VPS پر باقی تمام ports بند رہنے چاہییں۔

TCP 8443 admin interface ہے۔ اسے کبھی public نہیں ہونا چاہیے۔ اس میں controller کے زیرِ انتظام ہر site کی configuration ایک ہی password کے پیچھے محفوظ ہوتی ہے۔
UDP 10001 اور UDP 1900 broadcast discovery کے لیے ہیں۔ Broadcasts internet سے نہیں گزرتے، اس لیے انہیں کھولنے کا کوئی فائدہ نہیں۔
TCP 8880 اور TCP 8843 guest portal redirects ہیں۔ انہیں صرف اس وقت کھولیں جب آپ guest portal چلا رہے ہوں۔
TCP 6789 mobile speed test کے لیے اور UDP 5514 remote syslog کے لیے ہے۔ انہیں استعمال کرنے پر شامل کریں۔
TCP 27117 MongoDB ہے۔ اوپر دی گئی compose file میں database کوئی port publish نہیں کرتا، اس لیے یہ صرف internal Docker network پر موجود ہے۔ اسے اسی طرح رکھیں۔

اگر آپ کی sites کے پاس static public addresses ہیں تو صرف انہی کو اجازت دیں:

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

VPS firewall کے لیے ufw کی بنیادی معلومات ان rules کے مفروضہ default deny setup کا احاطہ کرتی ہے۔

یہاں ایک ایسا trap ہے جو ہر بار لوگوں کو متاثر کرتا ہے۔ Docker کے published ports ufw کو bypass کر دیتے ہیں۔ کسی port کو publish کرنے سے NAT اور forwarding rules براہِ راست iptables میں لکھی جاتی ہیں، اور اس traffic کو ufw کے زیرِ انتظام INPUT chain کے بجائے Docker کی اپنی chain میں filter کیا جاتا ہے۔ اس لیے ufw deny 8443، ufw status میں درست دکھائی دیتا ہے، جبکہ port پوری دنیا کے لیے کھلا رہتا ہے۔ اسے کسی دوسری machine سے test کریں، VPS سے کبھی نہیں:

nc -vz vps.example.com 8443

Refusal یا timeout مطلوبہ نتیجہ ہے۔ اگر connection قائم ہو جائے تو ufw کچھ بھی کہے، port public ہے۔ قابلِ اعتماد حل وہی ہے جو compose file میں پہلے سے موجود ہے: port کو 127.0.0.1 یا tunnel address پر publish کریں، تاکہ Docker اسے public interface پر bind ہی نہ کرے۔ DOCKER-USER chain میں rule بھی کام کرتا ہے، لیکن binding زیادہ سادہ ہے، اور rule ordering کی غلطی اسے غیر مؤثر نہیں بنا سکتی۔

Ubiquiti کے اپنے installers کے بارے میں کیا خیال ہے؟

Ubiquiti، Network Application کے لیے Debian package جاری کرتا ہے۔ اکتوبر 2026 تک اس کا help center اس طریقے کو legacy قرار دیتا ہے اور UniFi OS Server کو self-hosting کے لیے نیا standard بتاتا ہے۔ یہ package کام کرتا ہے، لیکن موجودہ Ubuntu پر MongoDB سے متعلق ایک سوال پیدا کرتا ہے جس کا distribution اب جواب نہیں دیتا: Ubuntu 22.04 اور 24.04 میں MongoDB server package شامل نہیں ہے۔ اس لیے آپ کو MongoDB کی اپنی repository شامل کرکے versions کو دستی طور پر ہم آہنگ کرنا پڑتا ہے۔ اوپر دیا گیا container یہ matching ایک pinned tag میں کرتا ہے، اسی لیے یہاں یہی طریقہ اختیار کیا گیا ہے۔

Ubiquiti کی نئی self-hosted product، UniFi OS Server ہے۔ یہ UniFi applications کو Podman containers میں چلاتی ہے اور آپ کو وہی UniFi OS فراہم کرتی ہے جو اس کے hardware consoles میں ہوتا ہے۔ اکتوبر 2026 تک Ubiquiti x86-64 CPU، Ubuntu 24.04 یا بعد کا version، یا Debian 13 یا بعد کا version، slirp4netns 1.2 یا بعد کے version کے ساتھ Podman 4.9.3 یا بعد کا version، کم از کم 2 GB RAM، اور 10 GB خالی storage درکار قرار دیتا ہے۔ Ubiquiti کے Releases یا Download page پر installer link version-specific ہوتا ہے: download پر right-click کریں، link address copy کریں، پھر اسے curl -O یا wget سے fetch کریں۔ ہر release کا اپنا URL ہوتا ہے، اس لیے guide میں ایک version pin کیا جا سکتا ہے، لیکن ایسا link نہیں دیا جا سکتا جو ہمیشہ latest version کی طرف اشارہ کرے۔ Installer uosserver نام کی systemd service قائم کرتا ہے، جسے آپ systemctl سے stop اور start کرتے ہیں۔ اگر آپ vendor کی اپنی packaging چاہتے ہیں تو اسے منتخب کریں۔ اگر آپ versions خود pin کرنا اور machine کو دوسرے کاموں کے لیے دستیاب رکھنا چاہتے ہیں تو container stack منتخب کریں۔

UniFi کے بیک اپ کہاں محفوظ ہوتے ہیں اور انہیں سرور سے باہر کیسے منتقل کریں

Controller اپنے بیک اپس Settings کے backup حصے میں مقرر کردہ schedule کے مطابق خود بناتا ہے۔ اسی جگہ یہ بھی مقرر کیا جاتا ہے کہ کتنے بیک اپس محفوظ رکھنے ہیں۔ فائلیں container کے اندر /config/data/backup/autobackup میں محفوظ ہوتی ہیں، جو host پر ~/unifi/config/data/backup/autobackup ہے، اور ان کے نام autobackup_10.5.67_20260813_1200_1755086400004.unf جیسے ہوتے ہیں۔

تصدیق کریں کہ یہ واقعی بن رہی ہیں:

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

نئے container installation پر schedule مقرر کرنے کے ایک دن بعد بھی directory کا خالی رہنا ایک معروف failure ہے۔ Application کے لیے autobackup directory کا موجود ہونا ضروری ہے، لیکن یہ اسے خود نہیں بناتی۔ اس لیے scheduled job خاموشی سے کچھ بھی نہیں لکھتی۔ اسے خود اسی user کے طور پر بنائیں جس کے تحت container چلتا ہے، پھر اگلی run کا انتظار کریں:

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

.unf فائل میں site configuration اور administrator accounts ہوتے ہیں، اس لیے اسے cryptographic key کی طرح محفوظ رکھیں۔ اس کی copies اپنے زیرِ اختیار machine پر منتقل کریں اور انہیں private رکھیں:

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

Restore ایک ہی step ہے۔ نئی installation پر setup wizard کا پہلا صفحہ backup file سے restore کرنے کا اختیار دیتا ہے، اور running controller اسی settings page سے backup restore کرتا ہے۔ اسی version یا اس سے نئے version میں restore کریں۔ جس application سے backup لکھا گیا ہو اگر وہ اس application سے نئی ہو جس میں آپ restore کر رہے ہیں، تو backup reject ہو جاتا ہے۔ اسی لیے file کے ساتھ version number بھی record کریں۔

کنٹرولر اپ گریڈ سے کیا خراب ہو سکتا ہے

ہر اپ گریڈ سے پہلے دستی بیک اپ لیں اور اسے ڈاؤن لوڈ کریں۔ پھر:

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' سے تصدیق ہوتی ہے کہ آیا کرنل اسے بند کر رہا ہے۔

ڈیوائس فرم ویئر وہ خطرہ ہے جسے لوگ بھول جاتے ہیں۔ کنٹرولر کے خود کو اپ گریڈ کرنے کے بعد، یہ منسلک ڈیوائسز کے لیے فرم ویئر اپ گریڈ پیش کرتا ہے۔ انہیں ایک ہی سیشن میں قبول نہ کریں۔ اگر ڈیوائس اپ گریڈ اور کنٹرولر اپ گریڈ ایک ساتھ ہوں اور ان کے درمیان رابطہ منقطع ہو جائے، تو ڈیوائس آدھی کنفیگرڈ حالت میں پھنس سکتی ہے، اور آپ کو دوسری عمارت میں موجود ہارڈویئر پر SSH کے ذریعے set-inform کرنا پڑے گا۔

اپ گریڈ کا دورانیہ سننے میں جتنا لگتا ہے اس سے کہیں زیادہ پرسکون ہوتا ہے۔ کنٹرولر کے ری سٹارٹ ہونے کے دوران ڈیوائسز ٹریفک فارورڈ کرتی رہتی ہیں، اس لیے صارفین کو کچھ محسوس نہیں ہوتا۔ جو چیز رک جاتی ہے وہ گیسٹ پورٹل اور RADIUS ہے اگر کنٹرولر انہیں فراہم کر رہا ہو، لہذا ایسا وقت منتخب کریں جب ان میں سے کوئی بھی استعمال نہ ہو رہا ہو۔ رات کے 3 بجے خاموشی سے بند ہونے والے کنٹرولر کے بارے میں جاننا ضروری ہے، اس لیے Uptime Kuma سٹیٹس مانیٹر کو پورٹ 8080 پر پوائنٹ کریں اور اسے آپ کو مطلع کرنے دیں۔

ایمان دار متبادل: Ubiquiti کا hosted console

Ubiquiti یہی کام بطور سروس فراہم کرتا ہے۔ October 2026 تک Ubiquiti کا US store اسے Official UniFi Hosting کے نام سے فروخت کرتا ہے۔ قیمت $29 فی ماہ سے شروع ہوتی ہے، اور یہ Ubiquiti کے زیر انتظام server پر زیادہ سے زیادہ 1,000 UniFi Network devices manage کرتا ہے۔ ابھی آپ نے جو self-hosted application install کی ہے وہ free ہے اور اس کے لیے subscription درکار نہیں۔

اگر آپ ایک site manage کرتے ہیں اور patching کے بجائے ادائیگی کرنا پسند کرتے ہیں تو hosted console منتخب کریں۔ اگر آپ کئی sites manage کرتے ہیں، یا controller کو اپنے زیر انتظام network کے اندر رکھنا چاہتے ہیں اور اسے اپنی دیگر services کے ساتھ ایک ہی box پر چلانا چاہتے ہیں، تو VPS منتخب کریں۔ کم پیمانے پر cost کا فرق حقیقی ہے، لیکن فیصلہ کرتے وقت صرف اسی کو نہ دیکھیں۔ hosted console کسی دوسرے فریق کا uptime ہے، جبکہ VPS آپ کی ذمہ داری ہے، بشمول اس رات کے جب اس کی disk بھر جائے۔ اگر box دونوں صورتوں میں اپنی لاگت پوری کرنے والا ہے تو VPS پر آپ مزید کیا چلا سکتے ہیں وہ فہرست ہے جسے اگلا پڑھیں۔

FAQ

میرے UniFi device کو VPS پر موجود controller اپنٹ کیوں نہیں کرتا؟

Devices، UDP port 10001 پر broadcast کے ذریعے controllers دریافت کرتے ہیں۔ Broadcast مقامی network سے باہر نہیں جاتی، اس لیے remote site پر موجود device public internet پر controller تلاش نہیں کر سکتا۔ Controller کی system settings میں inform host override کو اپنے VPS hostname پر set کریں، پھر ssh ubnt@<device-ip> کے ذریعے device کو set-inform http://vps.example.com:8080/inform پر point کریں۔ اگر device Adopting state میں ہو تو اسی حالت میں set-inform دوبارہ چلائیں۔ اگر اسے پہلے کسی دوسرے controller نے adopt کیا تھا تو پہلے اسے factory default پر reset کریں، کیونکہ اس میں اب بھی پرانے controller کے credentials محفوظ ہیں۔

self-hosted UniFi controller کو کتنی RAM درکار ہوتی ہے؟

2 GB عملی کم از کم مقدار ہے، جبکہ 4 GB مناسب گنجائش فراہم کرتی ہے۔ یہ application Java اور MongoDB پر مشتمل ہے، اور دونوں اپنی memory الگ الگ استعمال کرتے ہیں: container image بطور default Java heap کو 1024 MB تک محدود کرتی ہے، جبکہ MongoDB کا WiredTiger cache، 1 GB سے زیادہ RAM کے نصف حصے کو استعمال کرتا ہے۔ x86_64 پر grep -m1 -o avx /proc/cpuinfo کے ذریعے یہ بھی تصدیق کریں کہ CPU، AVX فراہم کرتا ہے، کیونکہ MongoDB 5.0 اور اس کے بعد کے ورژنز اس کے بغیر start نہیں ہوں گے اور database container مسلسل restart loop میں چلا جائے گا۔

کیا مجھے port 8443 کو internet پر expose کرنا چاہیے؟

نہیں۔ Port 8443 admin interface ہے، اور اس میں controller کے زیر انتظام ہر site کی configuration موجود ہوتی ہے۔ Docker Engine 28.0.0 یا اس کے بعد کے ورژن کے ساتھ اسے 127.0.0.1 پر publish کریں اور ssh -L 8443:127.0.0.1:8443 you@vps.example.com کے ذریعے access کریں، یا اسے WireGuard یا Tailscale address سے bind کریں۔ Adoption اور management کے لیے آپ کی sites کو TCP 8080 اور UDP 3478 تک رسائی درکار ہے۔ اگر UXG gateway Traffic Flow logs کو controller کو بھیجتا ہے تو TCP 5671 بھی درکار ہے۔ جب sites کے public addresses static ہوں تو آپ ان ports کو صرف انہی addresses تک محدود کر سکتے ہیں۔ یاد رکھیں کہ Docker کا published port ufw کے ذریعے filter نہیں ہوتا، اس لیے ufw status پر اعتماد کرنے کے بجائے کسی بیرونی machine سے test کریں۔

کیا VPS controller بند ہونے پر میرا network کام کرنا بند کر دے گا؟

نہیں۔ Adopted access points اور switches، controller کی جانب سے پہلے push کی گئی configuration کے مطابق traffic forward کرتے رہتے ہیں، اس لیے clients connected رہتے ہیں اور Wi-Fi کام کرتا رہتا ہے۔ بند ہونے والی چیز management ہے۔ آپ dashboard اور statistics collection سے محروم ہو جاتے ہیں، نیز controller کی فراہم کردہ ہر live feature بھی رک جاتی ہے، مثلاً guest portal authentication یا RADIUS، جب controller ہی RADIUS server ہو۔

UniFi controller اپنے automatic backups کہاں محفوظ کرتا ہے؟

یہاں استعمال ہونے والی container image میں یہ backups /config/data/backup/autobackup میں محفوظ ہوتے ہیں۔ یہ path host پر آپ کے data path کے ساتھ data/backup/autobackup سے map ہوتا ہے، اور backups .unf files کی صورت میں version اور timestamp کے نام سے بنائے جاتے ہیں۔ کچھ fresh installs میں autobackup directory موجود نہیں ہوتی۔ ایسی صورت میں scheduled backup error رپورٹ کیے بغیر کچھ بھی نہیں لکھتا۔ اس لیے schedule set کرنے کے ایک دن بعد اس directory کی فہرست دیکھیں، اور اگر یہ خالی ہو تو اسے خود بنائیں۔ Files کو VPS سے باہر copy کریں، کیونکہ ایک .unf میں site configuration اور administrator accounts شامل ہوتے ہیں۔

کیا یہ مضمون مفید تھا؟

#unifi#ubiquiti#network-management#docker #self-hosting