ஆல் Matt Connor 2026-08-13 · புதுப்பிக்கப்பட்டது 2026-08-16

VPS-ல் UniFi Controller-ஐ நிறுவுவது எப்படி?

Q: UniFi controller தனது தானியங்கி backups-ஐ எங்கே சேமிக்கிறது?

இங்கே பயன்படுத்தப்படும் container image-ல், அவை /config/data/backup/autobackup-ல் சேமிக்கப்படுகின்றன. இது host-ல் உள்ள உங்கள் data path மற்றும் data/backup/autobackup ஆகியவற்றுடன் இணைக்கப்பட்டுள்ளது. இவை .unf கோப்புகளாக, பதிப்பு மற்றும் நேர முத்திரையுடன் (timestamp) சேமிக்கப்படும். சில புதிய நிறுவல்களில் autobackup கோப்பகம் (directory) இருக்காது. அப்போது திட்டமிடப்பட்ட backup எந்தப் பிழையையும் காட்டாமல் எதையும் சேமிக்காது. எனவே, schedule செய்த ஒரு நாள் கழித்து அந்த directory-ஐச் சரிபார்க்கவும்; அது காலியாக இருந்தால் நீங்களே அதை உருவாக்கவும். அந்த backup கோப்புகளை VPS-லிருந்து வெளியே நகலெடுத்து வைக்கவும், ஏனெனில் ஒரு .unf கோப்பில் தான் தளத்தின் configuration மற்றும் நிர்வாகி கணக்குகள் அனைத்தும் உள்ளன.

VPS-ல் UniFi Network Application-ஐ நிறுவும் முறையை அறியுங்கள். RAM அளவு, Docker மற்றும் MongoDB கட்டமைப்பு, Layer 3 adoption மற்றும் பாதுகாப்புக்கான Port விவரங்களை இதில் காணலாம்.

VPS-ல் இயங்கும் UniFi controller-ன் செயல்பாடுகள்

VPS-ல் இயங்கும் UniFi controller என்பது, அது நிர்வகிக்கும் தளங்கள் செயலிழந்தாலும் தொடர்ந்து அணுகக்கூடிய ஒரு மேலாண்மை server ஆகும். இந்த மென்பொருள் Ubiquiti நிறுவனத்தின் UniFi Network Application ஆகும்: இது MongoDB database-ஐப் பயன்படுத்தும் ஒரு Java நிரலாகும். இது உங்கள் access points மற்றும் switches-ஐ உள்ளமைக்கவும், அவற்றின் புள்ளிவிவரங்களைச் சேமிக்கவும், நிர்வாக இடைமுகத்தை (admin interface) வழங்கவும் பயன்படுகிறது. இது client traffic-ஐக் கையாளுவதில்லை.

இந்தக் கடைசி அம்சம், இந்த மென்பொருளை எங்கு நிறுவ வேண்டும் என்பதைத் தீர்மானிக்கிறது. Controller-ஐ அது நிர்வகிக்கும் அலுவலகத்திற்குள் இருக்கும் ஒரு கணினியில் வைத்தால், நெட்வொர்க் செயலிழக்கும் அதே நிமிடத்தில், அந்த நெட்வொர்க்கைக் கண்காணிக்கும் கருவியையும் நீங்கள் இழந்துவிடுவீர்கள். மாறாக, நிலையான பொது முகவரி (public address) கொண்ட ஒரு VPS-ல் அதை வைத்தால், அது தொடர்ந்து இயங்கும், தரவுகளைச் சேகரிக்கும், மேலும் பல இடங்களில் உள்ள சாதனங்களை ஒரே இடத்திலிருந்து இணைக்க (adopt) முடியும். இதற்கு அதிக செயல்திறனை விட, தடையற்ற இயக்கம் (uptime) அவசியம்.

Controller offline-ல் இருக்கும்போது, ஏற்கனவே உள்ளமைக்கப்பட்ட access points மற்றும் switches தொடர்ந்து traffic-ஐ அனுப்பும். ஆனால், dashboard மற்றும் புள்ளிவிவரங்களை நீங்கள் இழப்பீர்கள். மேலும், controller-ன் நேரடித் தேவை கொண்ட அம்சங்களான guest portal login அல்லது RADIUS (remote authentication dial-in user service) போன்றவை இயங்காது (controller உங்கள் RADIUS server-ஆக இருந்தால்). Clients தொடர்ந்து இணைப்பில் இருப்பார்கள்.

UniFi controller-க்கு எவ்வளவு RAM தேவை?

குறைந்தபட்சம் 2 GB RAM தேவை, ஆனால் 4 GB RAM இருப்பது சிறந்தது. ஒரே பெட்டியில் Java மற்றும் MongoDB என இரண்டு நினைவகத்தை நுகரும் மென்பொருள்கள் இயங்குகின்றன; இவை ஒவ்வொன்றும் தங்களுக்குத் தேவையான நினைவகத்தை தனித்தனியாக ஒதுக்கிக்கொள்கின்றன.

Java heap-ன் அளவு MEM_LIMIT மூலம் கட்டுப்படுத்தப்படுகிறது, இது container image-ல் இயல்பாக 1024 MB என அமைக்கப்பட்டுள்ளது. மீதமுள்ள பாதி MongoDB-க்குச் செல்கிறது. அதன் WiredTiger storage engine, 1 GB-க்கு மேல் உள்ள RAM-ல் பாதியை அல்லது 256 MB-ஐ (எது அதிகமோ அதை) cache-ஆக எடுத்துக்கொள்ளும். 2 GB VPS-ல், இது தோராயமாக 512 MB cache, 1 GB heap, JVM-ன் heap அல்லாத நினைவகம் மற்றும் இயங்குதளம் எனப் பிரியும். சாதாரண நாட்களில் இது சரியாக இருக்கும், ஆனால் அதிகப்படியான பயன்பாடு இருக்கும்போது, kernel-ன் out-of-memory killer இந்த இரண்டு செயல்முறைகளில் ஒன்றை நிறுத்திவிடும். காரணமில்லாமல் service restart ஆனால், என்ன நடந்தது என்பதை அறிய dmesg -T | grep -i 'killed process' கட்டளையை இயக்கவும். உங்களிடம் 2 GB மட்டுமே இருந்தால், swap file ஒன்றைச் சேர்க்கவும்.

CPU மற்றும் disk பயன்பாடு மிகக் குறைவு. ஒன்று அல்லது இரண்டு vCPU-க்கள் சில டஜன் சாதனங்களைக் கையாளப் போதுமானது. 20 GB disk-உடன் தொடங்கவும், ஆனால் அதைத் தொடர்ந்து கண்காணிக்கவும்; ஏனெனில் நீங்கள் பார்க்கும் clients-ன் எண்ணிக்கை மற்றும் புள்ளிவிவரங்களைச் சேமிக்கும் காலத்தைப் பொறுத்து database-ன் அளவு வளரும். 4 GB வசதி கொண்ட server-ல் controller மட்டும் இயங்கினால், பெரும்பாலான நினைவகம் பயன்பாடின்றி இருக்கும். எனவே, இதனுடன் வேறு மென்பொருள்களை இயக்கத் திட்டமிட்டால், அந்த மென்பொருள்களின் தேவைக்கேற்ப RAM-ஐத் தீர்மானிக்கவும். ஏனெனில் PhotoPrism மற்றும் Immich ஆகியவற்றின் குறைந்தபட்ச RAM தேவை மாறுபடும் மற்றும் இவை இரண்டும் controller-ஐ விட அதிக நினைவகத்தைக் கோரும்.

CPU-வில் ஒரு அம்சம் முக்கியமானது, மலிவான திட்டங்களில் இதை கவனிக்கத் தவறிவிட வாய்ப்புள்ளது:

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 மற்றும் அதற்குப் பிந்தைய பதிப்புகளுக்கு x86_64 வன்பொருளில் AVX (advanced vector extensions) தேவை. இந்தக் கட்டளை எந்த வெளியீட்டையும் காட்டவில்லை என்றால், CPU-வில் இல்லாத ஒரு instruction-ஐ binary இயக்க முயற்சிப்பதால், mongod தொடங்கும்போதே செயலிழந்து, container தொடர்ந்து restart ஆகிக்கொண்டே இருக்கும். பழைய Intel Celeron மற்றும் Pentium hosts-களில் இது பொதுவாக நடக்கும்; அதேபோல், guest-க்கு CPU flags-ஐ மறைக்கும் hypervisors-களிலும் இது நிகழும். MongoDB 4.4-க்கு AVX தேவையில்லை, இதுவே ஒரே மாற்று வழி, ஆனால் இந்த database பதிப்பிற்கு upstream-ல் இனி patches வழங்கப்படுவதில்லை. புதிய CPU கொண்ட host-க்கு மாறுவதே சிறந்த தீர்வாகும். ARM VPS-ல் இந்தப் பிரச்சினை வராது, ஏனெனில் AVX என்பது x86 instruction set ஆகும், மேலும் இரண்டு படங்களும் arm64 builds-ஐ வழங்குகின்றன. நீங்கள் இரண்டிற்கும் இடையே தேர்வு செய்கிறீர்கள் என்றால், ARM மற்றும் x86 VPS திட்டங்களுக்கு இடையிலான வேறுபாடுகள் விலையைத் தாண்டி பல அம்சங்களைக் கொண்டுள்ளன.

Docker Compose மூலம் UniFi Network Application-ஐ நிறுவுதல்

Docker-ஐப் பயன்படுத்துவதே குறைவான சிக்கல்களைத் தரும் வழியாகும். ஏனெனில், உங்கள் distribution வழங்கும் பதிப்பைச் சார்ந்திருக்காமல், application ஆதரிக்கும் MongoDB பதிப்பை நீங்களே தேர்வு செய்ய இது அனுமதிக்கிறது. உங்கள் server-ல் Docker இன்னும் இல்லை என்றால், முதலில் VPS-ல் Docker-ஐ நிறுவவும்.

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

Application உள்நுழைவதற்கு முன்பாக MongoDB-க்கு ஒரு பயனர் தேவை. அதிகாரப்பூர்வ MongoDB image, /docker-entrypoint-initdb.d-ல் உள்ள எந்தவொரு script-ஐயும் முதல்முறை தொடங்கும் போது இயக்கும். இதை ~/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

அந்த script, database directory காலியாக இருக்கும்போது மட்டுமே இயங்கும். தவறான கடவுச்சொல்லுடன் stack-ஐ ஒருமுறை தொடங்கினால், அந்தப் பயனர் தவறான கடவுச்சொல்லுடனேயே உருவாக்கப்படுவார். அதன் பிறகு compose file-ஐ மாற்றினாலும் எந்தப் பயனும் இல்லை, ஏனெனில் அந்த script மீண்டும் இயங்காது. இதன் அறிகுறி என்னவென்றால், web interface தோன்றாது மற்றும் application container-ல் MongoDB authentication தோல்வியடைந்ததாக log காட்டும். புதிய நிறுவலாக இருந்தால், stack-ஐ நிறுத்திவிட்டு, ~/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

இரண்டு image tags-களும் வேண்டுமென்றே குறிப்பிட்ட பதிப்பில் முடக்கப்பட்டுள்ளன (pinned). 10.5.67-ls141 என்பது ஆகஸ்ட் 2026-ல் தற்போதைய application release ஆகும், எனவே நீங்கள் நிறுவும் போது image-ன் release list-ஐச் சரிபார்த்து தற்போதைய பதிப்பைப் பயன்படுத்தவும். Database tag மிகவும் முக்கியமானது. MongoDB தானாகவே major versions-க்கு இடையே தரவுக் கோப்புகளை மேம்படுத்தாது (upgrade). எனவே mongo:latest ஒரு கட்டத்தில் புதிய major version-ஐப் பதிவிறக்கி, ஏற்கனவே உள்ள கோப்புகளைத் திறக்க மறுத்து, மீண்டும் மீண்டும் restart ஆகிக்கொண்டே இருக்கும். Major version-ஐ முடக்கி வைத்துவிட்டு, தேவைப்படும்போது மட்டும் கவனமாக மேம்படுத்தவும். UniFi Network 8.1 மற்றும் அதற்குப் பிந்தைய பதிப்புகள் MongoDB 3.6 முதல் 7.0 வரை ஆதரிக்கின்றன, 9.0 பதிப்பு MongoDB 8.0-க்கான ஆதரவைச் சேர்த்துள்ளது.

PUID மற்றும் PGID ஆகியவை host-ல் உள்ள உண்மையான பயனருடன் பொருந்த வேண்டும், இல்லையெனில் ./config-ல் உள்ள கோப்புகள் எழுத முடியாத ஒரு அடையாளத்திற்குச் சொந்தமாகிவிடும். உங்களுடையதை அறிய id-ஐ இயக்கவும். container images-ல் PUID மற்றும் PGID எவ்வாறு செயல்படுகின்றன என்பது பொருந்தாத சூழலில் என்ன நடக்கும் என்பதை விளக்குகிறது.

இதைத்தொடங்கி கவனிக்கவும்:

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

docker compose ps-ல் இரண்டு container-களும் running நிலையில் இருக்க வேண்டும். unifi-db, restarting நிலையில் சிக்கிக்கொண்டால், அது மேலே குறிப்பிட்ட AVX சிக்கலாகவோ அல்லது ./db-ல் உள்ள அனுமதி (permission) சிக்கலாகவோ இருக்கலாம். Log சீரானதும், இரண்டு listeners-ஐயும் சரிபார்க்கவும்:

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 status code கிடைத்தால், listener இயங்கி பதிலளிக்கிறது என்று அர்த்தம். Connection refused என்றால் application இன்னும் தொடங்கிக்கொண்டிருக்கிறது என்று பொருள் (முதல்முறை தொடங்கும் போது சிறிய VPS-ல் இதற்கு ஒன்று அல்லது இரண்டு நிமிடங்கள் ஆகலாம்), அல்லது அது தொடங்கவே இல்லை என்று அர்த்தம்.

நிர்வாக இடைமுகத்தை வெளிப்படுத்தாமல் அணுகுதல்

மேலே உள்ள கோப்பில் 127.0.0.1-ல் port 8443 வெளியிடப்பட்டுள்ளது, எனவே VPS-க்கு வெளியே இருந்து யாரும் நிர்வாக இடைமுகத்தை அணுக முடியாது. அமைவு வழிகாட்டியை (setup wizard) இயக்க, SSH மூலம் அதை forward செய்யவும்:

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

அந்த session-ஐ அப்படியே விட்டுவிட்டு https://127.0.0.1:8443-க்குச் செல்லவும். இது self-signed certificate என்பதால், browser ஒருமுறை எச்சரிக்கை செய்யும். நிர்வாகி கணக்கை உருவாக்கி, தளத்திற்குப் பெயரிட்டு, இப்போதைக்கு device adoption-ஐத் தவிர்க்கவும்.

ஒரு நிர்வாகிக்கு SSH tunnel போதுமானது. ஒரு குழுவிற்கு என்றால், VPS-க்கு ஒரு private address-ஐ வழங்கி, அந்த interface-ல் மட்டும் bind செய்யவும். உங்கள் சொந்த VPS-ல் WireGuard VPN மற்றும் Tailscale subnet router ஆகிய இரண்டும் உங்கள் குழுவினர் மட்டும் அணுகக்கூடிய முகவரியை வழங்கும். WireGuard-க்கு வெளியிடப்பட்ட port-ஐ 10.8.0.1:8443:8443-க்கு மாற்றவும், அல்லது Tailscale வழங்கும் முகவரிக்கு மாற்றவும். ஒரு சிக்கல்: இன்னும் உருவாக்கப்படாத முகவரியில் Docker-ஆல் port-ஐ வெளியிட முடியாது. எனவே, container தொடங்குவதற்கு முன்பே tunnel interface தயாராக இருக்க வேண்டும், இல்லையெனில் bind error காரணமாக container இயங்காது.

தொலைதூரத்தில் உள்ள UniFi சாதனம் ஏன் adopt ஆகவில்லை

பெட்டியில் இருந்து எடுக்கப்பட்ட புதிய UniFi சாதனம், உள்ளூர் நெட்வொர்க்கில் UDP port 10001 மூலம் ஒளிபரப்பு (broadcast) செய்து தனது controller-ஐக் கண்டறியும். இந்த ஒளிபரப்பு LAN-ஐ விட்டு வெளியேறாது என்பதால், மற்றொரு நகரத்தில் உள்ள அலுவலகத்தில் இருக்கும் சாதனம், VPS-ல் உள்ள controller-ஐ ஒருபோதும் கண்டறியாது. இது Layer 3 adoption ஆகும்; இங்குதான் பெரும்பாலானோர் சிக்கிக்கொள்கிறார்கள். சாதனமும் controller-ம் சரியாகவே உள்ளன. ஆனால், எங்கு பார்க்க வேண்டும் என்று சாதனத்திற்கு யாரும் சொல்லவில்லை.

முதலில், எந்த முகவரியை வழங்க வேண்டும் என்பதை controller-க்குத் தெரிவிக்கவும். Controller-ன் Settings-ல், System பகுதியில், override விருப்பத்துடன் கூடிய inform host அமைப்பு உள்ளது. அதை உங்கள் VPS-ன் public hostname அல்லது IP-க்கு அமைக்கவும். இல்லையெனில், controller தனது சொந்த interface-ல் உள்ள முகவரியையே விளம்பரப்படுத்தும். Docker bridge நெட்வொர்க்கிற்குள் அது 172.18.0.3 போன்ற ஒரு private முகவரியாக இருக்கும். சாதனம் அந்த முகவரியைப் பெற்று, அதற்கு routing செய்ய முடியாமல், மீண்டும் தேடத் தொடங்கும்.

பிறகு, அந்த முகவரிக்குச் சாதனத்தை வழிநடத்தவும். தொலைதூர LAN-ல் உள்ள சாதனத்திற்கு SSH செய்யவும். தொழிற்சாலை அமைப்பில் (factory default) உள்ள சாதனம் ubnt என்ற username மற்றும் ubnt என்ற கடவுச்சொல்லை ஏற்கும்:

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

புதிய சாதன firmware உங்களை shell-க்கு பதிலாக ஒரு menu-விற்கு அழைத்துச் செல்லும். அதே கட்டளையை ஒரே வரியாக இயக்கவும்:

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

இப்போது சாதனம் controller-ல் adopt செய்யத் தயாராகத் தோன்றும். Adopt என்பதைக் கிளிக் செய்யவும், அதன் நிலை Adopting என்று மாறும். அனைவரையும் ஆச்சரியப்படுத்தும் பகுதி இதுதான்: நீங்கள் வழக்கமாக set-inform கட்டளையை இரண்டாவது முறையாக இயக்க வேண்டும். சாதனம் provisioning நிலைக்கு restart ஆகி, தனது சொந்த configuration-ல் சேமிக்கப்பட்ட inform URL-க்குத் திரும்பும்; controller இன்னும் அதை முழுமையாக மாற்றியிருக்காது. நிலை Adopting என்று இருக்கும்போதே மீண்டும் கட்டளையை இயக்கினால், handover முழுமையடையும். சாதனத்தில் தற்போதுள்ள inform URL மற்றும் நிலையைக் காண info என்று தட்டச்சு செய்யவும்.

சாதனம் ஏற்கனவே வேறொரு controller-ஆல் adopt செய்யப்பட்டிருந்தால், set-inform மட்டும் வேலை செய்யாது, ஏனெனில் அது பழைய controller-ன் நற்சான்றிதழ்களை (credentials) வைத்திருக்கும். முதலில் அதை factory default நிலைக்கு reset செய்யவும்; reset பட்டனைப் பயன்படுத்தலாம் அல்லது பழைய நற்சான்றிதழ்களைக் கொண்டு SSH வழியாக set-default கட்டளையைப் பயன்படுத்தலாம்.

குறைந்த எண்ணிக்கையிலான சாதனங்களுக்கு மேல் இருந்தால், அதற்குப் பதிலாக DHCP-ஐப் பயன்படுத்தவும். DHCP (dynamic host configuration protocol) option 43 ஒரு vendor-specific மதிப்பைக் கொண்டுள்ளது, UniFi சாதனங்கள் suboption 2-லிருந்து inform URL-ஐ வாசிக்கும். எந்தவொரு Linux கணினியிலும் hex string-ஐ உருவாக்கவும்:

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 byte string, அது 021f687474703a2f2f3139322e3136382e332e31303a383038302f696e666f726d என்று அச்சிடும். அந்த முடிவை உங்கள் router-ன் DHCP option 43 புலத்தில் hex மதிப்பாக ஒட்டவும். அந்த நெட்வொர்க்கில் boot ஆகும் ஒவ்வொரு சாதனமும் தனது lease மூலம் controller முகவரியைக் கற்றுக்கொள்ளும், SSH தேவையில்லை. பழைய வழிகாட்டிகள் suboption 1-ஐக் காட்டுகின்றன, 0104 மற்றும் அதைத் தொடர்ந்து IPv4 முகவரியின் நான்கு byte-கள் hex வடிவில் இருக்கும், சாதனங்கள் அந்த வடிவத்தையும் இன்னும் ஏற்கும்.

நீங்கள் அந்த இடத்தில் DNS-ஐ நிர்வகித்தால் மூன்றாவது வழி உள்ளது. UniFi சாதனம் boot ஆகும்போது unifi என்ற hostname-ஐ resolve செய்ய முயற்சிக்கும், எனவே உங்கள் VPS முகவரியைச் சுட்டிக்காட்டும் unifi-க்கான A record, ஒவ்வொரு சாதனத்திலும் வேலை செய்யாமலேயே அவற்றை adopt செய்யும். சாதனங்கள் பயன்படுத்தும் resolver-ஐ நீங்கள் கட்டுப்படுத்தும் இடங்களில் மட்டுமே இது உதவும்.

எந்த UniFi ports-ஐத் திறக்க வேண்டும், எவற்றைத் தனிப்பட்டதாக வைத்திருக்க வேண்டும்

தொலைதூர இடத்திலிருந்து இரண்டு ports-ஐ மட்டுமே அணுகக்கூடியதாக வைத்திருக்க வேண்டும்.

TCP 8080 என்பது inform channel ஆகும்; இணைக்கப்பட்ட (adopted) ஒவ்வொரு சாதனமும் இதனுடன் இணையும். இதனுள் இருக்கும் தரவு, சாதனத்தை இணைக்கும்போது controller வழங்கிய key மூலம் AES முறையில் குறியாக்கம் (encrypt) செய்யப்படுகிறது. இதனால்தான் சாதாரண HTTP இங்கு இயல்பான அமைப்பாக உள்ளது.
UDP 3478 என்பது STUN (session traversal utilities for NAT) ஆகும்; சாதனங்கள் controller-க்குத் திரும்பும் பாதையைத் தக்கவைக்க இதைப் பயன்படுத்துகின்றன.

மற்ற அனைத்தும் VPS-ல் மூடப்பட்டிருக்க வேண்டும்.

TCP 8443 என்பது admin interface ஆகும். இதை ஒருபோதும் பொதுவெளியில் திறக்கக்கூடாது. இது controller நிர்வகிக்கும் அனைத்து தளங்களின் கட்டமைப்பையும் (configuration) ஒரே கடவுச்சொல்லின் கீழ் வைத்திருக்கிறது.
UDP 10001 மற்றும் UDP 1900 ஆகியவை broadcast discovery-க்காகப் பயன்படுபவை. Broadcast-கள் இணையத்தைக் கடந்து செல்லாது என்பதால், இவற்றைத் திறப்பதால் எந்தப் பயனும் இல்லை.
TCP 8880 மற்றும் TCP 8843 ஆகியவை guest portal redirect-களுக்கானவை. நீங்கள் guest portal-ஐ இயக்கினால் மட்டுமே இவற்றைத் திறக்கவும்.
TCP 6789 என்பது mobile speed test-க்கும், UDP 5514 என்பது remote syslog-க்கும் உரியவை. தேவைப்படும்போது மட்டும் இவற்றைச் சேர்க்கவும்.
TCP 27117 என்பது MongoDB-க்கானது. மேலே உள்ள compose file-ல் database எந்தப் port-ஐயும் வெளியிடவில்லை (publish), எனவே அது Docker-ன் internal network-ல் மட்டுமே இருக்கும். அதை அப்படியே வைத்திருக்கவும்.

உங்கள் தளங்களுக்கு 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 அடிப்படைகள் பகுதியில், அந்த விதிகள் சார்ந்த default deny அமைப்பு விளக்கப்பட்டுள்ளது.

இதில் பலரும் சிக்கிக்கொள்ளும் ஒரு பொதுவான தவறு உள்ளது. Docker-ன் published ports, ufw-ஐத் தவிர்த்துச் செயல்படும். ஒரு port-ஐ publish செய்யும்போது, அது NAT மற்றும் forwarding விதிகளை நேரடியாக iptables-ல் எழுதிவிடும். அந்த traffic, ufw நிர்வகிக்கும் INPUT chain-ல் அல்லாமல், Docker-ன் சொந்த chain-ல் வடிகட்டப்படும். எனவே, ufw status-ல் ufw deny 8443 சரியாகத் தெரிந்தாலும், அந்த port உலகிற்குத் திறந்தே இருக்கும். இதை VPS-லிருந்து சோதிக்காமல், வேறொரு கணினியிலிருந்து சோதிக்கவும்:

nc -vz vps.example.com 8443

Connection மறுக்கப்படுவது அல்லது timeout ஆவதுதான் நீங்கள் எதிர்பார்க்கும் முடிவு. அது இணைப்பை ஏற்படுத்தினால், ufw என்ன சொன்னாலும் அந்த port பொதுவெளியில் திறந்தே இருக்கிறது என்று அர்த்தம். இதற்கு நம்பகமான தீர்வு, ஏற்கனவே compose file-ல் உள்ளது: port-ஐ 127.0.0.1-ல் அல்லது tunnel address-ல் publish செய்யவும். அப்போதுதான் Docker அதை public interface-ல் இணைக்காது. DOCKER-USER chain-ல் ஒரு விதியைச் சேர்ப்பதும் வேலை செய்யும், ஆனால் binding முறையே எளிதானது; விதிகளின் வரிசையில் தவறு நடந்தாலும் இது பாதுகாப்பாக இருக்கும்.

Ubiquiti-ன் சொந்த installers பற்றி என்ன?

Ubiquiti, Network Application-க்காக ஒரு Debian package-ஐ வெளியிடுகிறது. இது வேலை செய்யும், ஆனால் தற்போதைய Ubuntu-வில் இது MongoDB தொடர்பான ஒரு சிக்கலை எழுப்புகிறது; இதற்கு அந்த distribution-ல் பதில் இல்லை: Ubuntu 22.04 மற்றும் 24.04-ல் MongoDB server package இல்லை. எனவே, நீங்கள் MongoDB-ன் சொந்த repository-ஐச் சேர்த்து, பதிப்புகளை நீங்களே கைமுறையாகப் பொருத்த வேண்டியிருக்கும். மேலே உள்ள container அந்தப் பொருத்தத்தை ஒரே pinned tag-ல் செய்கிறது, அதனால்தான் இந்த வழிகாட்டி அந்த முறையைப் பின்பற்றுகிறது.

Ubiquiti-ன் புதிய self-hosted தயாரிப்பு UniFi OS Server ஆகும். இது UniFi applications-ஐ Podman containers-ல் இயக்குகிறது மற்றும் அவற்றின் hardware consoles-ல் உள்ள அதே 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 ஆகும். இந்த installer அவர்களின் downloads பக்கத்தில் இலவச Ubiquiti கணக்கிற்குப் பின்னால் உள்ளது, எனவே வழிகாட்டியில் பதிவிட நிலையான ஒற்றை வரி URL எதுவும் இல்லை. இது uosserver என்ற பெயரில் ஒரு system user-ஐ உருவாக்கி, அந்த user-ன் கீழ் containers-ஐ இயக்குகிறது. விற்பனையாளரின் சொந்த packaging உங்களுக்குத் தேவைப்பட்டால் இதைத் தேர்ந்தெடுக்கவும். பதிப்புகளை நீங்களே கட்டுப்படுத்தவும், server-ஐ பிற பணிகளுக்குப் பயன்படுத்தவும் விரும்பினால் container stack-ஐத் தேர்ந்தெடுக்கவும்.

UniFi backups எங்கே சேமிக்கப்படுகின்றன மற்றும் அவற்றை எவ்வாறு வெளியே எடுப்பது

நீங்கள் Settings-ல் உள்ள backup பகுதியில் அமைக்கும் கால அட்டவணையின்படி, controller அதன் backups-ஐ உருவாக்குகிறது. எத்தனை கோப்புகளை வைத்திருக்க வேண்டும் என்பதையும் அங்கேயே குறிப்பிடலாம். இந்தக் கோப்புகள் 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 நிறுவல்களில் ஏற்படும் ஒரு பொதுவான தோல்வியாகும். இந்த application autobackup கோப்பகம் ஏற்கனவே இருக்கும் என்று எதிர்பார்க்கிறது, ஆனால் அதை அதுவே உருவாக்குவதில்லை. இதனால் திட்டமிடப்பட்ட பணி எந்தக் கோப்பையும் உருவாக்காமல் நின்றுவிடும். container இயங்கும் அதே user-ஐப் பயன்படுத்தி நீங்களே அந்தக் கோப்பகத்தை உருவாக்கவும், பின்னர் அடுத்த முறை backup நடக்கும் வரை காத்திருக்கவும்:

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

ஒரு .unf கோப்பு, site-ன் கட்டமைப்பு மற்றும் administrator கணக்குகளைக் கொண்டுள்ளது. எனவே, இதை ஒரு cryptographic key-ஐப் போலவே பாதுகாப்பாகக் கையாளவும். உங்கள் கட்டுப்பாட்டில் உள்ள ஒரு கணினிக்கு இவற்றின் பிரதிகளை எடுத்து, தனிப்பட்ட முறையில் பாதுகாப்பாக வைக்கவும்:

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

மீட்டெடுப்பது (Restoring) ஒரு எளிய படிநிலை மட்டுமே. புதிய நிறுவலின் setup wizard-ன் முதல் பக்கத்தில் backup கோப்பிலிருந்து மீட்டெடுக்கும் வசதி இருக்கும். இயங்கிக்கொண்டிருக்கும் controller-ல் அதே settings பக்கத்திலிருந்து மீட்டெடுக்கலாம். அதே version அல்லது புதிய version-க்கு மட்டுமே மீட்டெடுக்க முடியும். நீங்கள் மீட்டெடுக்கும் controller-ன் version-ஐ விட, backup உருவாக்கப்பட்ட application-ன் version புதியதாக இருந்தால், அது நிராகரிக்கப்படும். இதனால்தான் கோப்புடன் சேர்த்து அதன் version எண்ணையும் குறித்து வைப்பது அவசியம்.

Controller upgrade-ஆல் ஏற்படக்கூடிய பாதிப்புகள்

ஒவ்வொரு upgrade-க்கு முன்பும் manual backup எடுத்து அதை download செய்யவும். பிறகு:

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

முதலில் பாதிக்கப்படுவது database தான். Application-ஐ மாற்றும் அதே சமயத்தில் mongo tag-ஐ புதிய major version-க்கு மாற்றுவது, controller தொடங்காமல் போவதற்கு மிக விரைவான வழியாகும். ஏனெனில், staged upgrade இல்லாமல் MongoDB வெவ்வேறு major version-களின் data files-ஐத் திறக்காது. Application-ஐ மட்டும் தனியாக upgrade செய்யவும். MongoDB-ஐத் தனியாக, ஒரு நேரத்தில் ஒரு major version வீதம், புதிய backup கையில் இருக்கும்போது மட்டும் upgrade செய்யவும்.

அடுத்தது memory. பெரிய release-களுக்கு அதிக heap தேவைப்படும். Application தொடங்கி, சில நிமிடங்கள் இயங்கிவிட்டு நின்றுவிட்டால், MEM_LIMIT மற்றும் MEM_STARTUP மதிப்புகளை 1536 அல்லது 2048-க்கு உயர்த்தி restart செய்யவும். Kernel அந்த process-ஐ நிறுத்துகிறதா என்பதை host-ல் உள்ள dmesg -T | grep -i 'killed process' உறுதிப்படுத்தும்.

மக்கள் மறக்கும் ஆபத்து device firmware ஆகும். Controller தன்னைத்தானே upgrade செய்துகொண்ட பிறகு, அது இணைக்கப்பட்ட (adopted) சாதனங்களுக்கு firmware upgrade-ஐப் பரிந்துரைக்கும். ஒரே சமயத்தில் இரண்டையும் செய்ய வேண்டாம். Device upgrade-ம் controller upgrade-ம் ஒரே நேரத்தில் நடந்து, அவற்றுக்கு இடையேயான இணைப்பு துண்டிக்கப்பட்டால், சாதனம் பாதியிலேயே provision ஆகிவிடும். பிறகு நீங்கள் வேறொரு கட்டிடத்தில் உள்ள hardware-ல் SSH மூலம் set-inform செய்ய வேண்டியிருக்கும்.

Upgrade window என்பது கேட்பதை விட எளிதானதுதான். Controller restart ஆகும்போது சாதனங்கள் தொடர்ந்து traffic-ஐ forward செய்யும், எனவே பயனர்களுக்கு எந்த மாற்றமும் தெரியாது. Controller-ஆல் வழங்கப்படும் guest portal மற்றும் RADIUS மட்டுமே நின்றுவிடும், எனவே அவை பயன்பாட்டில் இல்லாத நேரத்தைத் தேர்ந்தெடுக்கவும். அதிகாலை 3 மணிக்கு controller செயலிழந்தால் அது உங்களுக்குத் தெரிய வேண்டும், எனவே Uptime Kuma status monitor-ஐ port 8080-ல் point செய்து அதன் மூலம் தெரிந்துகொள்ளவும்.

நேர்மையான மாற்று: Ubiquiti-ன் hosted console

Ubiquiti இதே பணியை ஒரு சேவையாக வழங்குகிறது. ஆகஸ்ட் 2026 நிலவரப்படி, Official UniFi Cloud Console மாதத்திற்கு $29 என்ற விலையில் தொடங்குகிறது. இது 500 UniFi சாதனங்கள் வரை நிர்வகிக்க உதவுகிறது; இதற்கான அப்டேட்கள் மற்றும் பேக்கப்களை Ubiquiti கவனித்துக்கொள்ளும். நீங்கள் இப்போது நிறுவிய self-hosted application இலவசமானது மற்றும் இதற்கு சந்தா கட்டணம் ஏதுமில்லை.

நீங்கள் ஒரு தளத்தை மட்டும் நிர்வகிப்பவர் மற்றும் பராமரிப்புப் பணிகளைச் செய்வதை விட கட்டணம் செலுத்துவது மேல் என்று கருதினால், hosted console-ஐத் தேர்ந்தெடுக்கவும். நீங்கள் பல தளங்களை நிர்வகிப்பவராக இருந்தாலோ, அல்லது உங்கள் கட்டுப்பாட்டில் உள்ள நெட்வொர்க்கிற்குள் controller இருக்க வேண்டும் என்று விரும்பினாலோ, அல்லது நீங்கள் இயக்கும் பிற சேவைகளுடன் ஒரே server-ஐப் பகிர விரும்பினாலோ VPS-ஐத் தேர்ந்தெடுக்கவும். சிறிய அளவில் செலவு வித்தியாசம் குறிப்பிடத்தக்கதாக இருந்தாலும், கவனிக்க வேண்டியது அது மட்டுமே அல்ல: hosted console-ன் uptime பிறருடைய பொறுப்பு, ஆனால் VPS-ன் uptime உங்களுடையது; அதன் disk நிறைந்தால் அதைச் சரிசெய்ய வேண்டியதும் நீங்களே. இந்த server-ஐ நீங்கள் எப்படிப் பயன்படுத்தினாலும், VPS-ல் நீங்கள் இயக்கக்கூடிய பிற சேவைகள் என்ற பட்டியலை அடுத்து வாசிக்கவும்.

FAQ

எனது UniFi சாதனம் ஏன் VPS-ல் உள்ள controller-உடன் இணையவில்லை?

சாதனங்கள் UDP port 10001-ல் broadcast செய்வதன் மூலமே controller-ஐக் கண்டறியும். இந்த broadcast உள்ளூர் network-ஐ விட்டு வெளியேறாது என்பதால், தொலைதூர இடத்தில் உள்ள சாதனம் பொது இணையத்தில் உள்ள controller-ஐக் கண்டறிய முடியாது. Controller-ன் system settings-ல் உள்ள inform host override-ல் உங்கள் VPS hostname-ஐக் குறிப்பிடவும். பின், ssh ubnt@<device-ip>-ஐத் தொடர்ந்து set-inform http://vps.example.com:8080/inform-ஐப் பயன்படுத்தி அந்தச் சாதனத்தை controller-ஐ நோக்கித் திருப்பவும். சாதனம் Adopting நிலையிலேயே இருந்தால், அதே நிலையில் இருக்கும்போது மீண்டும் set-inform-ஐ இயக்கவும். முன்னதாக வேறொரு controller-உடன் அது இணைக்கப்பட்டிருந்தால், முதலில் அதை factory default நிலைக்கு reset செய்யவும், ஏனெனில் பழைய controller-ன் credentials இன்னும் அதில் இருக்கலாம்.

சுய-வழங்கப்பட்ட (self-hosted) UniFi controller-க்கு எவ்வளவு RAM தேவை?

2 GB என்பது குறைந்தபட்சத் தேவை, 4 GB இருந்தால் சிறப்பாகச் செயல்படும். இந்த application Java மற்றும் MongoDB-ஐ உள்ளடக்கியது; இவை இரண்டுக்கும் தனித்தனியாக memory ஒதுக்கப்படும். Container image இயல்பாகவே Java heap-ஐ 1024 MB-க்குள் கட்டுப்படுத்துகிறது. MongoDB-ன் WiredTiger cache, 1 GB-க்கு மேல் உள்ள RAM-ல் பாதியைப் பயன்படுத்திக்கொள்ளும். x86_64 கட்டமைப்பில், CPU-வில் AVX வசதி உள்ளதா என்பதை grep -m1 -o avx /proc/cpuinfo மூலம் உறுதிப்படுத்தவும். ஏனெனில், MongoDB 5.0 மற்றும் அதற்குப் பிந்தைய பதிப்புகள் AVX இல்லாமல் இயங்காது, இதனால் database container மீண்டும் மீண்டும் restart ஆகிக்கொண்டே இருக்கும்.

8443 port-ஐ இணையத்தில் பகிரங்கமாகத் திறக்கலாமா?

கூடாது. 8443 port என்பது நிர்வாக இடைமுகம் (admin interface). இது controller நிர்வகிக்கும் அனைத்து தளங்களின் configuration-களையும் கொண்டுள்ளது. இதை 127.0.0.1-ல் மட்டும் வெளியிடவும், ssh -L 8443:127.0.0.1:8443 you@vps.example.com மூலம் அணுகவும் அல்லது WireGuard அல்லது Tailscale முகவரியுடன் இணைக்கவும். TCP 8080 மற்றும் UDP 3478 ஆகியவற்றை மட்டுமே உங்கள் தளங்களிலிருந்து அணுகக்கூடியதாக வைக்க வேண்டும். தளங்களின் public IP முகவரிகள் நிலையானதாக இருந்தால், அவற்றை மட்டும் அனுமதிக்கும்படி கட்டுப்படுத்தலாம். Docker-ல் வெளியிடப்பட்ட port-ஐ ufw வடிகட்டாது என்பதை நினைவில் கொள்க. எனவே, ufw status-ஐ மட்டும் நம்பியிருக்காமல், வெளியிலிருந்து ஒரு machine மூலம் சோதித்துப் பார்க்கவும்.

VPS controller செயலிழந்தால் எனது network வேலை செய்வதை நிறுத்திவிடுமா?

இல்லை. ஏற்கனவே இணைக்கப்பட்ட (adopted) access points மற்றும் switches, controller வழங்கிய configuration-ஐப் பயன்படுத்தி traffic-ஐத் தொடர்ந்து அனுப்பும். எனவே, வாடிக்கையாளர்கள் தொடர்ந்து இணைப்பில் இருப்பார்கள், Wi-Fi-யும் வேலை செய்யும். நிர்வாகம் மட்டுமே நின்றுவிடும். Dashboard மற்றும் புள்ளிவிவரங்கள் சேகரிப்பு, அத்துடன் guest portal authentication அல்லது controller-ஐ RADIUS server-ஆகப் பயன்படுத்தும் வசதிகள் போன்ற நேரடிச் செயல்பாடுகள் மட்டுமே கிடைக்காது.

UniFi controller தனது தானியங்கி backups-ஐ எங்கே சேமிக்கிறது?

இங்கே பயன்படுத்தப்படும் container image-ல், அவை /config/data/backup/autobackup-ல் சேமிக்கப்படுகின்றன. இது host-ல் உள்ள உங்கள் data path மற்றும் data/backup/autobackup ஆகியவற்றுடன் இணைக்கப்பட்டுள்ளது. இவை .unf கோப்புகளாக, பதிப்பு மற்றும் நேர முத்திரையுடன் (timestamp) சேமிக்கப்படும். சில புதிய நிறுவல்களில் autobackup கோப்பகம் (directory) இருக்காது. அப்போது திட்டமிடப்பட்ட backup எந்தப் பிழையையும் காட்டாமல் எதையும் சேமிக்காது. எனவே, schedule செய்த ஒரு நாள் கழித்து அந்த directory-ஐச் சரிபார்க்கவும்; அது காலியாக இருந்தால் நீங்களே அதை உருவாக்கவும். அந்த backup கோப்புகளை VPS-லிருந்து வெளியே நகலெடுத்து வைக்கவும், ஏனெனில் ஒரு .unf கோப்பில் தான் தளத்தின் configuration மற்றும் நிர்வாகி கணக்குகள் அனைத்தும் உள்ளன.

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