द्वारे Matt Connor 2026-08-13 · अपडेटेड 2026-08-16

VPS वर UniFi Controller कसा सेट करावा?

Q: UniFi कंट्रोलर त्याचे ऑटोमॅटिक बॅकअप कुठे साठवतो?

येथे वापरलेल्या कंटेनर इमेजमध्ये ते /config/data/backup/autobackup मध्ये साठवले जातात, जे होस्टवरील तुमच्या डेटा पाथ आणि data/backup/autobackup शी मॅप केलेले असते. हे बॅकअप .unf फाइल्सच्या स्वरूपात असतात, ज्यांना व्हर्जन आणि टाइमस्टॅम्पचे नाव दिलेले असते. काही नवीन इन्स्टॉलेशन्समध्ये autobackup डिरेक्टरी अस्तित्वात नसते आणि अशा वेळी शेड्युल केलेले बॅकअप कोणतीही त्रुटी न दाखवता काहीही सेव्ह करत नाहीत. त्यामुळे शेड्युल सेट केल्यानंतर एक दिवसाने ती डिरेक्टरी तपासा आणि ती रिकामी असल्यास स्वतः तयार करा. या फाइल्स VPS च्या बाहेर कॉपी करून ठेवा, कारण .unf मध्ये साइट कॉन्फिगरेशन आणि ॲडमिनिस्ट्रेटर अकाउंट्सची माहिती असते.

VPS वर UniFi Network Application होस्ट करण्यासाठी आवश्यक RAM, Docker सह MongoDB सेटअप, Layer 3 adoption साठी set-inform कमांड आणि सुरक्षिततेसाठी आवश्यक पोर्ट्सची माहिती.

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 लागते?

दोन GB ही किमान मर्यादा आहे आणि 4 GB असणे सोयीचे ठरते. एकाच बॉक्समध्ये Java आणि MongoDB हे दोन मेमरी वापरणारे घटक असतात आणि ते एकमेकांपासून स्वतंत्रपणे स्वतःचा आकार ठरवतात.

Java heap ची मर्यादा MEM_LIMIT द्वारे निश्चित केली जाते, जी कंटेनर इमेजमध्ये डीफॉल्टनुसार 1024 MB वर सेट केलेली असते. MongoDB हा दुसरा अर्धा भाग आहे. त्याचा WiredTiger स्टोरेज इंजिन 1 GB पेक्षा जास्त असलेल्या RAM च्या अर्ध्या भागावर किंवा 256 MB, यापैकी जे मोठे असेल, तितका कॅशे आकार निश्चित करतो. 2 GB च्या VPS वर हे साधारणपणे 512 MB कॅशे, 1 GB heap, JVM ची स्वतःची non-heap मेमरी आणि ऑपरेटिंग सिस्टम मिळून होते. जोपर्यंत दिवस सामान्य असतो तोपर्यंत हे चालते, पण कामाचा ताण वाढल्यास कर्नलचा out-of-memory killer या दोनपैकी एका प्रोसेसला बंद करतो. कोणत्याही अनाकलनीय रीस्टार्टनंतर, असेच घडले आहे का हे तपासण्यासाठी dmesg -T | grep -i 'killed process' चालवा. जर तुमच्याकडे 2 GB RAM असेल, तर swap file जोडा.

CPU आणि डिस्कची मागणी कमी असते. एक किंवा दोन vCPU काही डझन उपकरणांना हाताळू शकतात. 20 GB डिस्कने सुरुवात करा आणि त्यावर लक्ष ठेवा, कारण तुम्ही पाहता त्या क्लायंटच्या संख्येनुसार आणि तुम्ही किती काळ आकडेवारी साठवता त्यानुसार डेटाबेस वाढत जातो. केवळ कंट्रोलर चालवल्यास 4 GB बॉक्समधील बहुतेक जागा रिकामी राहते, त्यामुळे जर तुम्ही तिथे दुसरी एखादी सेवा ठेवणार असाल, तर त्या सेवेच्या गरजेनुसार आकार ठरवा, कारण PhotoPrism आणि Immich च्या RAM च्या किमान गरजा खूप वेगळ्या आहेत आणि त्यापैकी कोणतीही सेवा कंट्रोलरपेक्षा जास्त RAM मागते.

CPU चे एक वैशिष्ट्य महत्त्वाचे आहे, जे स्वस्त प्लॅनमध्ये दुर्लक्षित राहू शकते:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 आणि त्यानंतरच्या आवृत्त्यांना x86_64 हार्डवेअरवर AVX (advanced vector extensions) ची आवश्यकता असते. जर या कमांडने काहीही आउटपुट दिले नाही, तर mongod स्टार्टअप दरम्यान बंद पडतो आणि कंटेनर लूपमध्ये रीस्टार्ट होतो, कारण बायनरी अशी सूचना चालवते जी CPU कडे नसते. जुने Intel Celeron आणि Pentium होस्ट किंवा अतिथी (guest) कडून CPU फ्लॅग लपवणारे हायपरव्हायझर याचे सामान्य कारण असतात. MongoDB 4.4 ला AVX ची गरज नसते आणि तो एकमेव पर्याय आहे, परंतु ही डेटाबेसची अशी आवृत्ती आहे ज्याला अपस्ट्रीम आता पॅच देत नाही. नवीन CPU असलेल्या होस्टवर स्थलांतर करणे हा उत्तम उपाय आहे. ARM VPS वर हा प्रश्न उद्भवत नाही, कारण AVX हा x86 इंस्ट्रक्शन सेट आहे आणि दोन्ही इमेजेस arm64 बिल्ड्स प्रकाशित करतात. जर तुम्ही या दोघांमध्ये निवड करत असाल, तर ARM आणि x86 VPS प्लॅन मधील फरक केवळ किमतीपेक्षा अधिक महत्त्वाचे आहेत.

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 पब्लिश केले आहे, त्यामुळे VPS च्या बाहेरील कोणतीही व्यक्ती प्रशासकीय इंटरफेसपर्यंत पोहोचू शकत नाही. सेटअप विझार्ड चालवण्यासाठी ते SSH द्वारे फॉरवर्ड करा:

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

ते सत्र (session) चालू ठेवा आणि https://127.0.0.1:8443 वर ब्राउझ करा. प्रमाणपत्र self-signed असल्याने, ब्राउझर एकदा चेतावणी देईल. प्रशासक खाते तयार करा, साइटला नाव द्या आणि सध्यापुरते डिव्हाइस अडॉप्शन (device adoption) वगळा.

एका प्रशासकासाठी SSH टनेल पुरेसा आहे. टीमसाठी, VPS ला एक खाजगी पत्ता (private address) द्या आणि इंटरफेस त्या पत्त्यावर बाइंड करा. तुमच्या स्वतःच्या VPS वर WireGuard VPN आणि Tailscale subnet router हे दोन्ही तुम्हाला असा पत्ता देतात ज्यावर फक्त तुमच्या टीममधील लोक राउट करू शकतात. WireGuard साठी पब्लिश केलेले पोर्ट 10.8.0.1:8443:8443 वर बदला किंवा Tailscale ने दिलेल्या पत्त्यावर बदला. एक अडचण अशी आहे की, जो पत्ता अस्तित्वात नाही त्यावर Docker पब्लिश करू शकत नाही. त्यामुळे कंटेनर सुरू होण्यापूर्वी टनेल इंटरफेस कार्यान्वित होणे आवश्यक आहे, अन्यथा कंटेनर bind error मुळे अयशस्वी होतो.

रिमोट 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 पोर्ट्स उघडे ठेवावेत आणि कोणते खाजगी ठेवावेत

रिमोट साइटवरून फक्त दोन पोर्ट्स ॲक्सेस करण्यायोग्य असणे आवश्यक आहे.

TCP 8080 हे 'inform' चॅनेल आहे आणि प्रत्येक अडॉप्ट केलेले डिव्हाइस याला कनेक्ट होते. यातील डेटा अडॉप्शनच्या वेळी कंट्रोलरने दिलेल्या की (key) द्वारे AES एनक्रिप्ट केलेला असतो, म्हणूनच येथे साधे HTTP वापरणे सामान्य आहे.
UDP 3478 हे STUN (session traversal utilities for NAT) आहे, ज्याचा वापर डिव्हाइसेस कंट्रोलरकडे परत जाण्यासाठी मार्ग खुला ठेवण्यासाठी करतात.

इतर सर्व गोष्टी VPS वर बंद ठेवाव्यात.

TCP 8443 हे ॲडमिन इंटरफेस आहे. हे पोर्ट कधीही सार्वजनिक नसावे. यात कंट्रोलरद्वारे व्यवस्थापित केल्या जाणाऱ्या प्रत्येक साइटचे कॉन्फिगरेशन एका पासवर्डच्या मागे सुरक्षित असते.
UDP 10001 आणि UDP 1900 हे ब्रॉडकास्ट डिस्कव्हरीसाठी आहेत. ब्रॉडकास्ट इंटरनेट ओलांडून जात नाहीत, त्यामुळे ते उघडून काहीही साध्य होत नाही.
TCP 8880 आणि TCP 8843 हे गेस्ट पोर्टल रीडायरेक्ट्स आहेत. जर तुम्ही गेस्ट पोर्टल चालवत असाल तरच ते उघडा.
TCP 6789 हे मोबाईल स्पीड टेस्टसाठी आणि UDP 5514 हे रिमोट 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

VPS फायरवॉलसाठी ufw ची मूलभूत माहिती मध्ये डीफॉल्ट 'deny' सेटअप कव्हर केला आहे, ज्यावर हे नियम आधारित आहेत.

येथे एक चूक आहे जी अनेकांकडून वारंवार होते. Docker चे पब्लिश केलेले पोर्ट्स ufw ला बायपास करतात. पोर्ट पब्लिश केल्यामुळे NAT आणि फॉरवर्डिंगचे नियम थेट iptables मध्ये लिहिले जातात आणि तो ट्रॅफिक ufw द्वारे व्यवस्थापित केल्या जाणाऱ्या INPUT चेनमध्ये न जाता Docker च्या स्वतःच्या चेनमध्ये फिल्टर होतो. त्यामुळे ufw deny 8443 हे ufw status मध्ये बरोबर दिसत असले तरी पोर्ट जगासाठी उघडेच राहते. याची चाचणी दुसऱ्या मशीनवरून करा, कधीही VPS वरून करू नका:

nc -vz vps.example.com 8443

कनेक्शन नाकारले जाणे (refusal) किंवा टाइमआउट होणे अपेक्षित आहे. जर कनेक्शन यशस्वी झाले, तर ufw काहीही म्हणत असला तरी पोर्ट सार्वजनिक आहे. यावर खात्रीशीर उपाय म्हणजे compose फाइलमध्ये आधीच दिलेला पर्याय: पोर्टला 127.0.0.1 वर किंवा टनेल ॲड्रेसवर पब्लिश करा, जेणेकरून Docker त्याला कधीही पब्लिक इंटरफेसवर बाइंड करणार नाही. DOCKER-USER चेन मधील नियम देखील काम करतो, परंतु बाइंडिंग करणे सोपे आहे आणि नियमांच्या क्रमामधील चुकीमुळे ते निकामी होत नाही.

Ubiquiti च्या स्वतःच्या इन्स्टॉलर्सचे काय?

Ubiquiti नेटवर्क ॲप्लिकेशनसाठी एक Debian पॅकेज प्रकाशित करते. ते कार्य करते, परंतु सध्याच्या Ubuntu वर ते MongoDB चा असा प्रश्न उपस्थित करते ज्याचे उत्तर आता वितरण (distribution) देत नाही: Ubuntu 22.04 आणि 24.04 मध्ये MongoDB सर्व्हर पॅकेज समाविष्ट नाही, त्यामुळे तुम्हाला शेवटी MongoDB ची स्वतःची रिपॉझिटरी जोडावी लागते आणि आवृत्त्या हाताने जुळवाव्या लागतात. वरील कंटेनर त्या आवृत्त्या एका पिन केलेल्या टॅगमध्ये जुळवतो, म्हणूनच हा मार्ग येथे निवडला आहे.

Ubiquiti चे नवीन self-hosted उत्पादन म्हणजे UniFi OS Server, जे UniFi ॲप्लिकेशन्स Podman कंटेनरमध्ये चालवते आणि तुम्हाला त्यांच्या हार्डवेअर कन्सोलसारखाच UniFi OS अनुभव देते. ऑगस्ट 2026 पर्यंत, यासाठी x86_64 Ubuntu 22.04 किंवा 24.04, slirp4netns सह Podman 4.3.1 किंवा नवीन आवृत्ती आवश्यक आहे. किमान 2 vCPU आणि 4 GB RAM, तर शिफारस केलेली 4 vCPU आणि 8 GB RAM आवश्यक आहे. इन्स्टॉलर त्यांच्या डाउनलोड पेजवर मोफत Ubiquiti अकाउंटच्या मागे असतो, त्यामुळे मार्गदर्शकामध्ये पेस्ट करण्यासाठी कोणतीही स्थिर एक-ओळीची URL उपलब्ध नाही. हे uosserver नावाचा सिस्टम युजर तयार करते आणि त्या युजरच्या माध्यमातून कंटेनर चालवते. जर तुम्हाला व्हेंडरचे स्वतःचे पॅकेजिंग हवे असेल तर ते निवडा. जर तुम्हाला आवृत्त्या स्वतः नियंत्रित करायच्या असतील आणि सर्व्हर इतर कामांसाठी मोकळा ठेवायचा असेल, तर कंटेनर स्टॅक निवडा.

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 ची होस्ट केलेली कन्सोल

Ubiquiti हेच काम सेवा म्हणून विकते. ऑगस्ट 2026 पर्यंत, अधिकृत UniFi Cloud Console ची किंमत दरमहा $29 पासून सुरू होते आणि ती 500 पर्यंत UniFi उपकरणांचे व्यवस्थापन करते, ज्यामध्ये अपडेट्स आणि बॅकअपची जबाबदारी Ubiquiti कडे असते. तुम्ही नुकतेच इन्स्टॉल केलेले self-hosted ॲप्लिकेशन विनामूल्य आहे आणि त्यासाठी कोणतेही सबस्क्रिप्शन लागत नाही.

जर तुम्ही एकाच साइटचे व्यवस्थापन करत असाल आणि पॅचिंग करण्यापेक्षा पैसे देणे पसंत करत असाल, तर होस्ट केलेली कन्सोल निवडा. जर तुम्ही अनेक साइट्सचे व्यवस्थापन करत असाल, किंवा तुम्हाला कंट्रोलर तुमच्या नियंत्रणाखालील नेटवर्कमध्ये हवा असेल आणि तो तुम्ही चालवत असलेल्या इतर सेवांसोबत एकाच सर्व्हरवर ठेवायचा असेल, तर VPS निवडा. लहान स्तरावर खर्चातील फरक मोठा वाटू शकतो, परंतु विचारात घेण्यासारखी ही एकमेव गोष्ट नाही: होस्ट केलेली कन्सोल म्हणजे दुसऱ्याच्या अपटाइमवर अवलंबून राहणे, तर VPS म्हणजे तुमची स्वतःची जबाबदारी, ज्यामध्ये डिस्क भरल्यास येणाऱ्या समस्यांचाही समावेश होतो. जर सर्व्हर कोणत्याही परिस्थितीत उपयुक्त ठरणार असेल, तर VPS वर तुम्ही आणखी काय चालवू शकता ही यादी पुढे वाचण्यासाठी योग्य आहे.

FAQ

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

डिव्हाइसेस UDP पोर्ट 10001 वर ब्रॉडकास्ट करून कंट्रोलरचा शोध घेतात. ब्रॉडकास्ट स्थानिक नेटवर्कच्या बाहेर जात नाही, त्यामुळे रिमोट साइटवरील डिव्हाइस इंटरनेटवरील कंट्रोलर शोधू शकत नाही. कंट्रोलरच्या सिस्टिम सेटिंग्जमध्ये 'inform host override' मध्ये तुमच्या VPS चे hostname सेट करा. त्यानंतर ssh ubnt@<device-ip> आणि त्यापाठोपाठ set-inform http://vps.example.com:8080/inform वापरून डिव्हाइसला त्याकडे निर्देशित करा. जर डिव्हाइस 'Adopting' स्थितीत अडकले असेल, तर ते तिथे असताना पुन्हा एकदा set-inform रन करा. जर ते आधी दुसऱ्या कंट्रोलरशी जोडलेले असेल, तर त्याला फॅक्टरी डिफॉल्टवर रिसेट करा, कारण त्यात जुन्या कंट्रोलरचे क्रेडेंशियल्स साठवलेले असतात.

सेल्फ-होस्टेड UniFi कंट्रोलरला किती RAM लागते?

2 GB ही किमान गरज आहे आणि 4 GB असल्यास काम सुरळीत चालते. हे ॲप्लिकेशन Java आणि MongoDB वर आधारित आहे आणि दोन्ही आपली मेमरी स्वतंत्रपणे वापरतात: कंटेनर इमेज Java heap ला डिफॉल्टनुसार 1024 MB वर मर्यादित ठेवते, तर MongoDB चा WiredTiger कॅशे 1 GB च्या वरील RAM पैकी अर्धी मेमरी वापरतो. x86_64 वर, CPU मध्ये AVX सपोर्ट आहे का हे grep -m1 -o avx /proc/cpuinfo वापरून तपासा, कारण MongoDB 5.0 आणि त्यानंतरच्या आवृत्त्या त्याशिवाय सुरू होत नाहीत आणि डेटाबेस कंटेनर सतत रीस्टार्ट होत राहतो.

मी पोर्ट 8443 इंटरनेटसाठी उघडावे का?

नाही. पोर्ट 8443 हे ॲडमिन इंटरफेस आहे आणि त्यात कंट्रोलरद्वारे व्यवस्थापित केल्या जाणाऱ्या सर्व साइट्सचे कॉन्फिगरेशन असते. ते 127.0.0.1 वर पब्लिश करा आणि ssh -L 8443:127.0.0.1:8443 you@vps.example.com वापरून ॲक्सेस करा, किंवा ते WireGuard किंवा Tailscale ॲड्रेसवर बाइंड करा. फक्त TCP 8080 आणि UDP 3478 हे पोर्ट्स तुमच्या साइट्सवरून ॲक्सेस करण्यायोग्य असणे आवश्यक आहे. जर साइट्सचे IP स्टॅटिक असतील, तर तुम्ही ते फक्त त्या IP साठी मर्यादित करू शकता. लक्षात ठेवा की Docker द्वारे पब्लिश केलेले पोर्ट ufw द्वारे फिल्टर होत नाही, त्यामुळे ufw status वर विश्वास ठेवण्याऐवजी बाहेरील मशीनवरून चाचणी करा.

VPS कंट्रोलर बंद पडल्यास माझे नेटवर्क काम करणे थांबवते का?

नाही. एकदा ॲडॉप्ट केलेले ॲक्सेस पॉइंट्स आणि स्विचेस कंट्रोलरने आधीच पाठवलेल्या कॉन्फिगरेशननुसार ट्रॅफिक फॉरवर्ड करत राहतात, त्यामुळे क्लायंट्स कनेक्टेड राहतात आणि Wi-Fi सुरू राहते. फक्त व्यवस्थापन थांबते. तुम्हाला डॅशबोर्ड आणि आकडेवारी (statistics) दिसणार नाही, तसेच कंट्रोलरद्वारे पुरवल्या जाणाऱ्या लाइव्ह सुविधा, जसे की गेस्ट पोर्टल ऑथेंटिकेशन किंवा RADIUS (जर कंट्रोलर स्वतः RADIUS सर्व्हर असेल), बंद पडतील.

UniFi कंट्रोलर त्याचे ऑटोमॅटिक बॅकअप कुठे साठवतो?

येथे वापरलेल्या कंटेनर इमेजमध्ये ते /config/data/backup/autobackup मध्ये साठवले जातात, जे होस्टवरील तुमच्या डेटा पाथ आणि data/backup/autobackup शी मॅप केलेले असते. हे बॅकअप .unf फाइल्सच्या स्वरूपात असतात, ज्यांना व्हर्जन आणि टाइमस्टॅम्पचे नाव दिलेले असते. काही नवीन इन्स्टॉलेशन्समध्ये autobackup डिरेक्टरी अस्तित्वात नसते आणि अशा वेळी शेड्युल केलेले बॅकअप कोणतीही त्रुटी न दाखवता काहीही सेव्ह करत नाहीत. त्यामुळे शेड्युल सेट केल्यानंतर एक दिवसाने ती डिरेक्टरी तपासा आणि ती रिकामी असल्यास स्वतः तयार करा. या फाइल्स VPS च्या बाहेर कॉपी करून ठेवा, कारण .unf मध्ये साइट कॉन्फिगरेशन आणि ॲडमिनिस्ट्रेटर अकाउंट्सची माहिती असते.

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