UniFi OS Server¶
Ubiquiti network controller.
| Runtime | VM (Proxmox), cloud-init template |
| Node | pve |
| IP | 10.36.0.13 |
| MAC (net0) | bc:24:11:f8:aa:27 (see Network) |
| Installer | UniFi OS Server, version pinned by unifi_installer_filename/_md5 |
| URL | https://unifi.lab.riversfamily.uk (management UI) |
| Auth | Own login |
| Source | ansible/roles/unifi/ |
Configuration¶
| Variable | Default | Set in |
|---|---|---|
unifi_web_port |
11443 |
ansible/roles/unifi/defaults/main.yml — routed through Traefik |
unifi_device_inform_port |
8080 |
served directly on the LAN, not through Traefik |
unifi_stun_port |
3478 |
UDP, served directly on the LAN |
unifi_l2_discovery_port |
10001 |
served directly on the LAN |
The management UI is fronted by Traefik like every other appliance, but device-communication ports are not: device inform, STUN, and L2 discovery are how Ubiquiti hardware on the LAN reaches the controller, and none of those are HTTP — they are the second of the two accepted exceptions to the single-ingress rule (the other is Pi-hole's DNS port).
Installation is not idempotent by nature, so the role first checks
service_facts for an existing uosserver.service and skips reinstalling if
present. It then installs podman/slirp4netns/curl, downloads the
installer (checksum-verified against unifi_installer_md5), and runs it
non-interactively (stdin: "y\n").
Gotchas¶
- Re-running the role after a version bump in
unifi_installer_filenamewon't reinstall over an already-presentuosserver.service— that check is a first-install guard, not an upgrade path. An in-place version upgrade needs its own handling if the pinned installer version ever moves.