द्वारे Matt Connor 2026-10-12

VPS वर UniFi controller कसा चालवायचा

Q: UniFi controller चे automatic backups कुठे साठवले जातात?

येथे वापरलेल्या container image मध्ये ते /config/data/backup/autobackup मध्ये साठवले जातात. Host वरील हे स्थान तुमच्या data path मधील data/backup/autobackup शी map होते. Backup files या .unf स्वरूपात असतात आणि त्यांच्या नावात version व timestamp असतो. काही नव्या installations मध्ये autobackup directory अस्तित्वात नसते. अशा वेळी scheduled backup कोणतीही error नोंदवता काहीही लिहित नाही. त्यामुळे schedule सेट केल्यानंतर एक दिवसाने ती directory list करा. ती रिकामी असल्यास स्वतः तयार करा. Files VPS च्या बाहेर copy करा, कारण .unf मध्ये site configuration आणि administrator accounts असतात.

VPS वर UniFi Network Application होस्ट करण्यासाठी RAM निवड, Docker आणि MongoDB, Layer 3 adoption साठी set-inform, तसेच खासगी ठेवायचे ports जाणून घ्या.

VPS वरील UniFi controller नक्की काय करतो

VPS वरील UniFi controller हा एक असा व्यवस्थापन सर्व्हर आहे, जो तो व्यवस्थापित करत असलेली ठिकाणे (sites) बंद पडली तरीही उपलब्ध राहतो. हे सॉफ्टवेअर म्हणजे Ubiquiti चे UniFi Network Application आहे: हे एक Java प्रोग्राम असून त्यामागे MongoDB डेटाबेस असतो. हे तुमच्या ॲक्सेस पॉइंट्स आणि स्विचेसचे कॉन्फिगरेशन करते, त्यांची आकडेवारी साठवते आणि ॲडमिन इंटरफेस पुरवते. हे क्लायंट ट्रॅफिक हाताळत नाही.

हा शेवटचा मुद्दा तो कुठे असावा हे ठरवतो. जर तुम्ही कंट्रोलरला ऑफिसमधील मशीनवर ठेवले, तर नेटवर्क बंद पडल्यास ते पाहण्याचे साधनही त्याच क्षणी बंद होते. जर तुम्ही ते स्थिर पब्लिक IP असलेल्या VPS वर ठेवले, तर ते चालू राहते, माहिती गोळा करत राहते आणि एकाच ठिकाणाहून अनेक साइट्सवरील उपकरणांना ॲडॉप्ट (adopt) करू शकते. याला जास्त प्रोसेसिंग पॉवरपेक्षा अपटाइमची अधिक गरज असते.

जेव्हा कंट्रोलर ऑफलाइन असतो, तेव्हा ॲडॉप्ट केलेले ॲक्सेस पॉइंट्स आणि स्विचेस आधीच पुश केलेल्या कॉन्फिगरेशननुसार ट्रॅफिक फॉरवर्ड करत राहतात. अशा वेळी तुम्ही डॅशबोर्ड आणि आकडेवारी गमावता, तसेच कंट्रोलर जिवंत असणे आवश्यक असलेली इतर वैशिष्ट्येही बंद पडतात: जसे की गेस्ट पोर्टल लॉगिन, किंवा जर कंट्रोलर तुमचा RADIUS (remote authentication dial-in user service) सर्व्हर असेल तर RADIUS सेवा. क्लायंटचे कनेक्शन मात्र सुरूच राहते.

UniFi controller ला किती RAM आवश्यक आहे?

2 GB ही किमान मर्यादा आहे आणि 4 GB ही खरेदीसाठी योग्य क्षमता आहे. एका सर्व्हरवर RAM वापरणारे दोन घटक आहेत: Java आणि MongoDB. दोन्ही एकमेकांपासून स्वतंत्रपणे त्यांच्या memory requirements ठरवतात.

Java heap ची कमाल मर्यादा MEM_LIMIT ने ठरते. Container image मध्ये ती default म्हणून 1024 MB सेट केलेली असते. दुसरा घटक MongoDB आहे. त्याचे WiredTiger storage engine 1 GB पेक्षा जास्त असलेल्या RAM च्या निम्म्या प्रमाणात cache आकारते; मात्र 256 MB ही किमान मर्यादा असते. 2 GB VPS वर हे साधारणपणे 512 MB cache, 1 GB heap, JVM ची स्वतःची non-heap memory आणि operating system यांचे एकत्रित वापरमान असते. व्यस्त दिवशी मात्र ही क्षमता अपुरी पडू शकते आणि kernel चा out-of-memory killer या दोन प्रक्रियांपैकी एक बंद करतो. कोणतेही स्पष्ट कारण नसताना restart झाल्यानंतर असे झाले का हे पाहण्यासाठी dmesg -T | grep -i 'killed process' चालवा. तुमच्याकडे 2 GBच असल्यास swap file जोडा.

CPU आणि disk च्या आवश्यकता कमी आहेत. काही डझन devices साठी एक किंवा दोन vCPU पुरेसे असतात. सुरुवातीला 20 GB disk द्या आणि त्यावर लक्ष ठेवा. तुम्ही पाहत असलेल्या clients ची संख्या आणि statistics किती काळ साठवता यानुसार database वाढतो. फक्त controller चालू असल्यास 4 GB क्षमतेच्या सर्व्हरचा बराच भाग रिकामा राहतो. त्यामुळे त्याच्यावर दुसरी सेवा चालवणार असाल, तर त्या सेवेनुसार क्षमता ठरवा. कारण PhotoPrism आणि Immich साठी आवश्यक असलेली किमान RAM वेगवेगळी आहे आणि दोन्हीपैकी कोणत्याही सेवेला controller पेक्षा अधिक RAM लागते.

एक CPU feature महत्त्वाचे आहे आणि स्वस्त plan मध्ये ते सहज दुर्लक्षित होऊ शकते:

grep -m1 -o avx /proc/cpuinfo

x86_64 hardware वर MongoDB 5.0 आणि त्यानंतरच्या आवृत्त्यांना AVX (advanced vector extensions) आवश्यक आहे. त्या command च्या output मध्ये काहीही दिसत नसेल, तर mongod startup दरम्यान बंद होते आणि container सतत restart होत राहतो. कारण binary अशा instruction चालवते जी CPU मध्ये उपलब्ध नसते. जुने Intel Celeron आणि Pentium hosts हे याचे नेहमीचे कारण आहेत. Guest system पासून CPU flags लपवणारे hypervisors हेही कारण असू शकतात. AVX शिवाय चालणारी MongoDB 4.4 ही सर्वात नवीन release आहे. Image 3.6 पर्यंतच्या जुन्या आवृत्त्याही स्वीकारते; मात्र 4.4 चे support February 2024 मध्ये संपले. CVE-2025-14847 साठी December 2025 मध्ये MongoDB ने 4.4 builds प्रसिद्ध केले, परंतु पुढील security flaw साठीही तसेच होईल याची हमी नाही. त्याहून जुन्या 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 ऑथेंटिकेशन फेल्युअरचे लॉग दाखवतो आणि वेब इंटरफेस कधीही दिसत नाही. नवीन इन्स्टॉलेशनमध्ये यावर उपाय म्हणजे स्टॅक थांबवणे, ~/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

दोन्ही इमेज टॅग मुद्दाम पिन केले आहेत. ऑगस्ट 2026 मध्ये 10.5.67-ls141 हे सध्याचे ॲप्लिकेशन रिलीज होते, त्यामुळे इमेजची रिलीज लिस्ट तपासा आणि तुम्ही इंस्टॉल करत असताना जे लेटेस्ट असेल ते पिन करा. डेटाबेस टॅग अधिक महत्त्वाचा आहे. 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 वर एक-दोन मिनिटे लागू शकतात, किंवा ते कधीही सुरू झाले नाही.

प्रशासक इंटरफेस सार्वजनिक न करता त्यात प्रवेश मिळवा

वरील फाइलमध्ये 127.0.0.1 वर पोर्ट 8443 प्रकाशित केला आहे. त्यामुळे Docker Engine 28.0.0 किंवा त्यानंतरच्या आवृत्तीत VPS च्या बाहेरून प्रशासक इंटरफेसपर्यंत पोहोचता येत नाही. जुन्या आवृत्त्यांमध्ये त्याच L2 segment वरील इतर host, उदाहरणार्थ त्याच network switch ला जोडलेली मशीन, localhost वर प्रकाशित केलेल्या पोर्टपर्यंत पोहोचू शकतात. त्यामुळे सर्व्हरवर त्यापेक्षा जुनी आवृत्ती असल्यास प्रथम docker 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 करा. प्रमाणपत्र self signed असल्यामुळे browser एकदा warning दाखवतो. Administrator account तयार करा, site ला नाव द्या आणि सध्या device adoption वगळा.

एका administrator साठी SSH tunnel पुरेसा आहे. Team साठी VPS ला private address द्या आणि त्याऐवजी interface त्या address वर bind करा. तुमच्या स्वतःच्या VPS वरील WireGuard VPN आणि Tailscale subnet router हे दोन्ही तुमच्या team मधील लोकच route करू शकतील असा address देतात. WireGuard साठी published port 10.8.0.1:8443:8443 वर बदला किंवा Tailscale ने दिलेल्या address वर bind करा. मात्र एक अडचण आहे: अद्याप अस्तित्वात नसलेल्या address वर Docker publish करू शकत नाही. त्यामुळे container सुरू होण्यापूर्वी tunnel interface सुरू झालेले असणे आवश्यक आहे; अन्यथा bind error मुळे container सुरू होत नाही.

रिमोट UniFi डिव्हाइस ॲडॉप्ट (adopt) का होत नाही

UniFi डिव्हाइस बॉक्समधून बाहेर काढल्यावर स्थानिक नेटवर्कवर UDP पोर्ट 10001 वर ब्रॉडकास्ट करून आपला कंट्रोलर शोधते. ब्रॉडकास्ट LAN च्या बाहेर जात नाही, त्यामुळे दुसऱ्या शहरातील ऑफिसमधील डिव्हाइस VPS वरील कंट्रोलर शोधू शकत नाही. याला Layer 3 ॲडॉप्शन म्हणतात आणि इथेच बहुतेक लोक अडकतात. डिव्हाइस आणि कंट्रोलर दोन्ही व्यवस्थित असतात, पण डिव्हाइसला कुठे पाहायचे हे कोणीही सांगितलेले नसते.

प्रथम, कंट्रोलरला कोणता पत्ता द्यायचा ते सांगा. कंट्रोलरच्या Settings मध्ये, System विभागात, inform host सेटिंग आणि एक override पर्याय असतो. तो तुमच्या VPS च्या पब्लिक होस्टनेम किंवा IP वर सेट करा. त्याशिवाय, कंट्रोलर स्वतःच्या इंटरफेसवर दिसणारा पत्ता जाहिरात करतो, जो Docker ब्रिज नेटवर्कमध्ये 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

आता डिव्हाइस कंट्रोलरमध्ये ॲडॉप्ट करण्यासाठी तयार असल्याचे दिसते. Adopt वर क्लिक करा, आणि स्थिती Adopting अशी होईल. इथेच सर्वांना आश्चर्य वाटते: तुम्हाला सहसा set-inform कमांड दुसऱ्यांदा चालवावी लागते. डिव्हाइस प्रोव्हिजनिंगसाठी रीस्टार्ट होते आणि स्वतःच्या कॉन्फिगरेशनमध्ये सेव्ह केलेल्या inform URL वर परत जाते, जी कंट्रोलरने अजून पूर्णपणे बदललेली नसते. स्थिती Adopting असताना पुन्हा कमांड चालवल्यास हस्तांतरण पूर्ण होते. डिव्हाइसवर सध्या कोणती inform URL आणि स्थिती आहे हे पाहण्यासाठी info टाईप करा.

जर डिव्हाइस आधी दुसऱ्या कंट्रोलरद्वारे ॲडॉप्ट केले असेल, तर फक्त set-inform ने काम होणार नाही, कारण त्यात अजूनही जुन्या कंट्रोलरचे क्रेडेंशियल्स असतात. प्रथम त्याला फॅक्टरी डिफॉल्टवर रीसेट करा, त्यासाठी रीसेट बटण वापरा किंवा जुन्या क्रेडेंशियल्सचा वापर करून SSH द्वारे set-default चालवा.

काही मोजक्यापेक्षा जास्त डिव्हाइसेस असल्यास, त्याऐवजी DHCP वापरा. DHCP (dynamic host configuration protocol) option 43 मध्ये व्हेंडर-विशिष्ट मूल्य असते आणि UniFi डिव्हाइसेस सब-ऑप्शन 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 फील्डमध्ये हेक्स व्हॅल्यू म्हणून पेस्ट करा. त्यानंतर त्या नेटवर्कवर बूट होणारे प्रत्येक डिव्हाइस त्याच्या लीजवरून कंट्रोलरचा पत्ता मिळवते, यासाठी SSH ची अजिबात गरज पडत नाही. जुन्या गाईड्समध्ये सब-ऑप्शन 1 दाखवला आहे, 0104 आणि त्यानंतर IPv4 पत्त्याचे चार हेक्स बाइट्स, आणि डिव्हाइसेस अजूनही ते स्वरूप स्वीकारतात.

जर तुम्ही त्या साइटवर DNS चालवत असाल, तर तिसरा मार्ग उपलब्ध आहे. UniFi डिव्हाइस बूट होताना unifi हे होस्टनेम रिझॉल्व्ह करण्याचा प्रयत्न करते, त्यामुळे unifi साठी एक A रेकॉर्ड तयार करा जो तुमच्या VPS पत्त्याकडे निर्देशित असेल. यामुळे प्रत्येक डिव्हाइसवर काम न करता ते ॲडॉप्ट होतात. हा मार्ग फक्त तिथेच उपयोगी पडतो जिथे तुम्ही डिव्हाइसेस वापरत असलेला रिझॉल्व्हर नियंत्रित करता.

कोणते UniFi ports उघडायचे आणि कोणते private ठेवायचे

adoption आणि दैनंदिन व्यवस्थापनासाठी remote site वरून दोन ports reachable असणे आवश्यक आहे.

TCP 8080 हे inform channel आहे आणि प्रत्येक adopted device त्याच्याशी connect होते. त्यातील payload adoption वेळी controller ने device ला दिलेल्या key ने AES encrypted असतो. त्यामुळे येथे plain HTTP हे सामान्य setting आहे.
UDP 3478 हे STUN (session traversal utilities for NAT) आहे. Devices controller कडे परत जाणारा path कायम ठेवण्यासाठी याचा वापर करतात.

काही 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 आहे. हा port कधीही 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 स्पष्ट करते.

येथे एक अडचण आहे जी प्रत्येक वेळी वापरकर्त्यांची दिशाभूल करते. Docker चे published ports ufw ला वगळून पुढे जातात. Port publish केल्यावर थेट iptables मध्ये NAT आणि forwarding rules लिहिले जातात. हा traffic ufw व्यवस्थापित करत असलेल्या INPUT chain मध्ये नव्हे, तर Docker च्या स्वतःच्या chain मध्ये filter केला जातो. त्यामुळे ufw deny 8443 हे ufw status मध्ये योग्य दिसते, पण port संपूर्ण जगासाठी open राहतो. हे दुसऱ्या machine वरून test करा; VPS वरून कधीही test करू नका:

nc -vz vps.example.com 8443

Connection न होणे किंवा 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 प्रकाशित करते. October 2026 पर्यंत Help Center मध्ये या पद्धतीला legacy असे म्हटले आहे. तसेच self-hosting साठी UniFi OS Server हा नवीन standard असल्याचे ते नमूद करते. हे package कार्य करते. मात्र सध्याच्या Ubuntu वर यामुळे MongoDB संदर्भातील एक प्रश्न निर्माण होतो, ज्याचे उत्तर distribution आता देत नाही. Ubuntu 22.04 आणि 24.04 मध्ये MongoDB server package उपलब्ध नाही. त्यामुळे तुम्हाला MongoDB चे स्वतःचे repository जोडावे लागते आणि versions manually जुळवाव्या लागतात. वरील container हे version matching एका pinned tag मध्ये करते. म्हणून येथे हीच पद्धत वापरली आहे.

Ubiquiti चे नवीन self-hosted product UniFi OS Server आहे. ते UniFi applications Podman containers मध्ये चालवते आणि त्यांच्या hardware consoles प्रमाणेच UniFi OS उपलब्ध करून देते. October 2026 पर्यंत Ubiquiti x86-64 CPU, Ubuntu 24.04 किंवा त्यानंतरची आवृत्ती किंवा Debian 13 किंवा त्यानंतरची आवृत्ती, slirp4netns 1.2 किंवा त्यानंतरच्या आवृत्तीसह Podman 4.9.3 किंवा त्यानंतरची आवृत्ती, किमान 2 GB RAM आणि 10 GB मोकळी storage आवश्यक असल्याचे नमूद करते. Ubiquiti च्या Releases किंवा Download page वरील installer link आवृत्तीनुसार बदलते. Download वर right click करा, link address copy करा आणि curl -O किंवा wget वापरून ती fetch करा. प्रत्येक release साठी स्वतंत्र URL असतो. त्यामुळे guide मध्ये एखादी version pin करता येते; मात्र नेहमी latest आवृत्तीकडे निर्देश करणारी link देता येत नाही. Installer uosserver नावाची systemd service configure करतो. ती systemctl वापरून stop आणि start करता येते. Vendor चे स्वतःचे packaging वापरायचे असल्यास ही पद्धत निवडा. Versions स्वतः pin करायच्या असतील आणि server इतर कामांसाठीही उपलब्ध ठेवायचा असेल, तर container stack निवडा.

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 फाईलमध्ये साईटचे कॉन्फिगरेशन आणि ॲडमिनिस्ट्रेटर खात्यांची माहिती असते, त्यामुळे तिला एखाद्या की (key) प्रमाणे सुरक्षित ठेवा. या फाईल्सच्या प्रती तुमच्या नियंत्रणाखाली असलेल्या मशीनवर घ्या आणि त्या खाजगी ठेवा:

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' हे कन्फर्म करते की कर्नलनेच ही प्रक्रिया बंद केली आहे का.

डिव्हाइस फर्मवेअर हा असा धोका आहे जो लोक विसरतात. कंट्रोलर स्वतः अपग्रेड झाल्यानंतर तो अडॉप्ट केलेल्या उपकरणांसाठी फर्मवेअर अपग्रेडची ऑफर देतो. एकाच सत्रात ते स्वीकारू नका. जर डिव्हाइस अपग्रेड आणि कंट्रोलर अपग्रेड एकाच वेळी झाले आणि त्यांच्यातील दुवा तुटला, तर डिव्हाइस अर्धवट प्रोव्हिजन (provision) स्थितीत राहू शकते आणि तुम्हाला दुसऱ्या इमारतीतील हार्डवेअरवर 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 व्यवस्थापित करते. तुम्ही नुकतेच install केलेले self-hosted application विनामूल्य आहे आणि त्यासाठी subscription आवश्यक नाही.

तुम्ही एक site व्यवस्थापित करत असाल आणि patching करण्यापेक्षा पैसे देणे पसंत करत असाल, तर hosted console निवडा. तुम्ही अनेक sites व्यवस्थापित करत असाल, किंवा controller तुमच्या नियंत्रणातील network मध्ये तसेच तुम्ही चालवत असलेल्या इतर services सोबत एकाच box वर ठेवायचा असेल, तर VPS निवडा. कमी प्रमाणात वापर करताना दोन्हींच्या खर्चातील फरक महत्त्वाचा आहे. मात्र विचारात घ्यायचा तो एकमेव मुद्दा नाही. Hosted console चा uptime दुसऱ्या संस्थेच्या नियंत्रणात असतो. तुमचा VPS तुमच्या नियंत्रणात असतो; त्याचा disk भरून जाण्याची रात्रसुद्धा त्यात समाविष्ट असते. Box कोणत्याही पर्यायात आपला खर्च भरून काढणार असेल, तर पुढे वाचण्यासाठी VPS वर आणखी काय चालवता येते ही यादी पहा.

FAQ

माझे UniFi डिव्हाइस VPS वरील controller शी adopt का होत नाही?

डिव्हाइसेस UDP port 10001 वर broadcast करून controllers शोधतात. Broadcast स्थानिक network च्या बाहेर जात नाही. त्यामुळे remote site वरील डिव्हाइस public internet वरील controller शोधू शकत नाही. Controller च्या system settings मध्ये inform host override म्हणून तुमचा VPS hostname सेट करा. त्यानंतर ssh ubnt@<device-ip> आणि त्यापुढे set-inform http://vps.example.com:8080/inform वापरून डिव्हाइसला त्या hostname कडे निर्देशित करा. डिव्हाइस Adopting स्थितीत अडकले असल्यास, तेथे असतानाच set-inform पुन्हा चालवा. दुसऱ्या controller ने ते आधी adopt केले असल्यास, प्रथम त्याला factory default वर reset करा. कारण त्याच्याकडे जुन्या controller ची credentials अद्याप साठवलेली असतात.

self-hosted UniFi controller साठी किती RAM आवश्यक आहे?

दोन GB ही किमान कार्यक्षम मर्यादा आहे आणि 4 GB पुरेशी आरामदायक क्षमता आहे. अॅप्लिकेशन Java आणि MongoDB वर आधारित आहे. हे दोन्ही memory स्वतंत्रपणे वापरतात. Container image Java heap ची कमाल मर्यादा default म्हणून 1024 MB ठेवते, तर MongoDB च्या WiredTiger cache साठी 1 GB पेक्षा जास्त RAM पैकी निम्मी RAM वापरली जाते. x86_64 वर grep -m1 -o avx /proc/cpuinfo वापरून CPU कडे AVX उपलब्ध आहे का तेही तपासा. MongoDB 5.0 आणि त्यानंतरच्या आवृत्त्या AVX शिवाय सुरू होत नाहीत आणि database container सतत restart होत राहतो.

Port 8443 internet साठी उघडा का?

नाही. 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 वापरून त्याच्यापर्यंत पोहोचा. किंवा तो WireGuard किंवा Tailscale address वर bind करा. Adoption आणि management साठी तुमच्या sites ना TCP 8080 आणि UDP 3478 पर्यंत पोहोचता आले पाहिजे. UXG gateway controller कडे Traffic Flow logs पाठवत असल्यास TCP 5671 देखील आवश्यक आहे. Sites चे public addresses static असल्यास हे ports त्या addresses पुरते मर्यादित करता येतात. लक्षात ठेवा, Docker ने publish केलेला port ufw द्वारे filter केला जात नाही. त्यामुळे ufw status वर अवलंबून न राहता बाहेरील machine वरून चाचणी करा.

VPS controller बंद पडल्यास माझे network काम करणे थांबेल का?

नाही. Adopt केलेले access points आणि switches controller ने आधी पाठवलेल्या configuration चा वापर करून traffic forward करत राहतात. त्यामुळे clients connected राहतात आणि Wi-Fi काम करत राहते. बंद पडणारी गोष्ट म्हणजे management. Dashboard आणि statistics collection उपलब्ध राहत नाही. तसेच controller पुरवत असलेली live features, जसे guest portal authentication किंवा controller हा RADIUS server असल्यास RADIUS, उपलब्ध राहत नाहीत.

UniFi controller चे automatic backups कुठे साठवले जातात?

येथे वापरलेल्या container image मध्ये ते /config/data/backup/autobackup मध्ये साठवले जातात. Host वरील हे स्थान तुमच्या data path मधील data/backup/autobackup शी map होते. Backup files या .unf स्वरूपात असतात आणि त्यांच्या नावात version व timestamp असतो. काही नव्या installations मध्ये autobackup directory अस्तित्वात नसते. अशा वेळी scheduled backup कोणतीही error नोंदवता काहीही लिहित नाही. त्यामुळे schedule सेट केल्यानंतर एक दिवसाने ती directory list करा. ती रिकामी असल्यास स्वतः तयार करा. Files VPS च्या बाहेर copy करा, कारण .unf मध्ये site configuration आणि administrator accounts असतात.

हा लेख उपयुक्त होता का?

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