ஆல் Matt Connor 2026-10-12

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

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

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

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 வாங்குவதே சிறந்தது. ஒரே server-ல் 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-ன் non-heap நினைவகம் மற்றும் operating system ஆகியவற்றைக் கொண்டிருக்கும். இது சாதாரண நாட்களில் சரியாக இருக்கும், ஆனால் அதிகப்படியான பயன்பாடு இருக்கும்போது, kernel-ன் out-of-memory killer இந்த இரண்டு process-களில் ஒன்றை நிறுத்திவிடும். காரணமில்லாமல் service restart ஆனால், அதுதான் காரணமா என்பதை அறிய dmesg -T | grep -i 'killed process' கட்டளையை இயக்கவும். உங்களிடம் 2 GB மட்டுமே இருந்தால், ஒரு swap file-ஐச் சேர்க்கவும்.

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

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

grep -m1 -o avx /proc/cpuinfo

MongoDB 5.0 மற்றும் அதற்குப் பிந்தைய பதிப்புகளுக்கு x86_64 hardware-ல் AVX (advanced vector extensions) தேவை. இந்தக் கட்டளை எதையும் காட்டவில்லை என்றால், CPU-வில் இல்லாத ஒரு instruction-ஐ binary இயக்க முயற்சிப்பதால், mongod தொடங்கும்போதே நின்றுவிடும் மற்றும் container மீண்டும் மீண்டும் restart ஆகும். பழைய Intel Celeron மற்றும் Pentium hosts அல்லது CPU flags-ஐ மறைக்கும் hypervisors-களில் இது பொதுவாக நடக்கும். AVX இல்லாமல் இயங்கும் மிகப்புதிய பதிப்பு MongoDB 4.4 ஆகும்; 3.6 வரையிலான பழைய பதிப்புகளையும் image ஏற்கும். ஆனால், 4.4 பதிப்பு பிப்ரவரி 2024-ல் தனது ஆயுட்காலத்தை முடித்துக்கொண்டது. CVE-2025-14847 பாதிப்பிற்காக டிசம்பர் 2025-ல் MongoDB 4.4-ன் build-ஐ வெளியிட்டது, ஆனால் அடுத்த பாதிப்பிற்கு இது உறுதி அளிக்கப்படவில்லை. பழைய பதிப்புகள் பாதுகாப்பு அபாயங்களைக் கொண்டவை. புதிய CPU கொண்ட host-க்கு மாறுவதே சிறந்த தீர்வு. ARM VPS-ல் இந்தப் பிரச்சினை வராது, ஏனெனில் AVX என்பது x86 instruction set ஆகும்; மேலும் இரண்டு image-களும் arm64 build-களை வழங்குகின்றன. நீங்கள் இரண்டில் ஒன்றைத் தேர்வு செய்கிறீர்கள் என்றால், 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 வெளியிடப்பட்டுள்ளது, எனவே Docker Engine 28.0.0 அல்லது அதற்குப் பிந்தைய பதிப்புகளில் VPS-க்கு வெளியே உள்ள எவராலும் இந்த நிர்வாக இடைமுகத்தை அணுக முடியாது. பழைய பதிப்புகளில், ஒரே network switch-ல் உள்ள பிற கணினிகள் போன்ற அதே L2 segment-ல் உள்ள பிற hosts, localhost-க்கு வெளியிடப்பட்ட ports-ஐ அணுக முடியும். எனவே, server பழைய பதிப்பைக் காட்டினால் 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-க்குச் செல்லவும். இது self signed certificate என்பதால், browser ஒருமுறை எச்சரிக்கை செய்யும். administrator account-ஐ உருவாக்கி, தளத்திற்குப் பெயரிட்டு, 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-ஐ திறக்க வேண்டும், எவற்றைத் தனிப்பட்டதாக வைத்திருக்க வேண்டும்

தொலைதூர தளத்திலிருந்து சாதனங்களை இணைப்பதற்கும் (adoption), அன்றாட நிர்வாகத்திற்கும் இரண்டு ports-ஐ அணுகக்கூடியதாக வைத்திருக்க வேண்டும்.

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

சில வசதிகளுக்கு கூடுதல் ports தேவைப்படும். L2 அல்லது L3 networks-ல் இணைக்கப்பட்ட UXG gateways-லிருந்து Traffic Flow logs-ஐப் பெற, Ubiquiti-யின் port reference-ல் TCP 5671 பரிந்துரைக்கப்படுகிறது. எனவே, உங்கள் controller-க்கு UXG தகவல்களை அனுப்புகிறது மற்றும் உங்களுக்கு அந்த logs தேவை என்றால், அந்தத் தளத்திற்கு 5671-ஐயும் திறந்து வைக்கவும்.

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

TCP 8443 என்பது admin interface ஆகும். இதை ஒருபோதும் பொதுவெளியில் (public) வைக்கக்கூடாது. இது controller நிர்வகிக்கும் அனைத்து தளங்களின் configuration-களையும் ஒரே கடவுச்சொல்லின் கீழ் வைத்திருக்கிறது.
UDP 10001 மற்றும் UDP 1900 ஆகியவை broadcast discovery-க்காகப் பயன்படுபவை. Broadcast-கள் இணையத்தைக் கடந்து செல்லாது என்பதால், இவற்றைத் திறப்பதால் எந்தப் பயனும் இல்லை.
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-ஐயும் பகிரவில்லை, எனவே அது internal Docker 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 deny 8443 என்பது ufw status-ல் சரியாகத் தெரிந்தாலும், அந்த port உலகிற்குத் திறந்தே இருக்கும். இதைச் சோதிக்க, VPS-லிருந்து அல்லாமல், வேறொரு கணினியிலிருந்து முயற்சிக்கவும்:

nc -vz vps.example.com 8443

Connection மறுக்கப்படுவது அல்லது timeout ஆவதுதான் நீங்கள் எதிர்பார்க்கும் முடிவு. ஒருவேளை connection ஏற்பட்டால், 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-ஐ வெளியிடுகிறது. அக்டோபர் 2026 நிலவரப்படி, அதன் உதவி மையம் அந்த முறையை பழையது (legacy) என்றும், UniFi OS Server-ஐ self-hosting-க்கான புதிய தரநிலை என்றும் குறிப்பிடுகிறது. அந்த package வேலை செய்யும், ஆனால் தற்போதைய Ubuntu-வில் அது MongoDB தொடர்பான ஒரு சிக்கலை எழுப்புகிறது; 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 நிலவரப்படி, Ubiquiti ஒரு x86-64 CPU, Ubuntu 24.04 அல்லது அதற்குப் பிந்தைய பதிப்பு அல்லது Debian 13 அல்லது அதற்குப் பிந்தைய பதிப்பு, slirp4netns 1.2 அல்லது அதற்குப் புதிய பதிப்புடன் கூடிய Podman 4.9.3 அல்லது அதற்குப் புதிய பதிப்பு, குறைந்தபட்சம் 2 GB RAM மற்றும் 10 GB காலி சேமிப்பு இடம் தேவை என்று குறிப்பிடுகிறது. Ubiquiti-ன் Releases அல்லது Download பக்கத்தில் உள்ள installer இணைப்பு பதிப்பு சார்ந்தது: பதிவிறக்க இணைப்பை right click செய்து, link address-ஐ நகலெடுத்து, curl -O அல்லது wget மூலம் அதைப் பெறவும். ஒவ்வொரு வெளியீட்டிற்கும் தனித்தனி URL இருப்பதால், ஒரு வழிகாட்டி ஒரு குறிப்பிட்ட பதிப்பை மட்டும் குறிப்பிட முடியுமே தவிர, எப்போதும் சமீபத்திய பதிப்பைக் காட்டும் இணைப்பை வழங்க முடியாது. இந்த installer uosserver என்ற systemd service-ஐ அமைக்கிறது, இதை நீங்கள் systemctl மூலம் நிறுத்தலாம் மற்றும் தொடங்கலாம். விற்பனையாளரின் சொந்த 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 நிலவரப்படி, Ubiquiti-ன் US store-ல் இது Official UniFi Hosting என்ற பெயரில் மாதத்திற்கு $29 முதல் கிடைக்கிறது. இது Ubiquiti இயக்கும் server-ல் 1,000 UniFi Network சாதனங்கள் வரை நிர்வகிக்க உதவுகிறது. நீங்கள் இப்போது நிறுவிய self-hosted application இலவசமானது மற்றும் இதற்கு சந்தா கட்டணம் ஏதுமில்லை.

நீங்கள் ஒரு தளத்தை மட்டும் நிர்வகிப்பவர் மற்றும் patch செய்வதை விட கட்டணம் செலுத்துவதை விரும்புபவர் என்றால், hosted console-ஐத் தேர்ந்தெடுக்கவும். நீங்கள் பல தளங்களை நிர்வகிப்பவர் என்றாலோ, அல்லது உங்கள் கட்டுப்பாட்டில் உள்ள network-க்குள் 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 மூலம் சாதனத்தை அந்த முகவரிக்குச் சுட்டிக்காட்டவும். சாதனம் 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 நிர்வகிக்கும் அனைத்து தளங்களின் கட்டமைப்பையும் கொண்டுள்ளது. Docker Engine 28.0.0 அல்லது அதற்குப் பிந்தைய பதிப்பைப் பயன்படுத்தி, அதை 127.0.0.1-ல் வெளியிட்டு, ssh -L 8443:127.0.0.1:8443 you@vps.example.com மூலம் அணுகவும். அல்லது அதை WireGuard அல்லது Tailscale முகவரியுடன் பிணைக்கவும் (bind). சாதனங்களை இணைக்கவும் நிர்வகிக்கவும் உங்கள் தளங்கள் TCP 8080 மற்றும் UDP 3478-ஐ அணுக வேண்டும். UXG gateway Traffic Flow logs-ஐ அனுப்பினால் TCP 5671-ம் தேவைப்படும். தளங்களின் public IP முகவரிகள் நிலையானதாக இருந்தால், அந்த முகவரிகளுக்கு மட்டும் இவற்றை மட்டுப்படுத்தலாம். Docker-ல் வெளியிடப்பட்ட port-ஐ ufw வடிகட்டாது என்பதை நினைவில் கொள்க. எனவே, ufw status-ஐ நம்புவதை விட, வெளியிலிருந்து ஒரு machine மூலம் சோதிக்கவும்.

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

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

UniFi controller தனது தானியங்கி backup-களை எங்கே சேமிக்கிறது?

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

இந்தக் கட்டுரை பயனுள்ளதாக இருந்ததா?

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