UniFi controller under Docker

[seren]

Cool, that's pretty quick!

 

[jeyare]

I ordered Unifi equipment and planning to rebuild my home network with that in a few days/weeks. In preparation I already installed the unifi controller docker image, to explore a bit. I had to change the ports in the config file though, because of other containers already using them. I assume as long as other ports work, I won't have issues with those? Or will Unifi equipment expect me to use default ports?

I immediately noticed that jacobalberty/unifi:latest runs a bit behind with the official versions. Makes sense of course since it's not an officially supported build. I was wondering though, typically how quickly are updates processed in this docker image after the official release?

re Ports - it's up to your setup and decision (I have my own ports in my setup)

re Support - no one can guarantee endless support from Jacob side, till now it's more than great. Agree with @xbmcnut. More important is the Docker feature - you can run 5 different releases and switch between them up to stable conditions provided. What is for me main enabler to use container for such Controller operation = it's saving my mental health from an issues in new release

 

[Mnl-]

My UniFi reached over 1Gb sometimes so I have maxed it to 1Gb.
Regarding the adoption if you have trouble because of different ports, connect in SSH to the devices and run:
set-inform http://pi:port/inform where port is what you mapped for 8080.

 

[xbmcnut]

FYI, I've found that if I put the NAS IP in Controller Hostname/IP and check the box for Override inform host with controller hostname/IP (as recommended by the UniFi docker readme), my internal devices are all very happy and re-adopt without issue after an automatic UniFi controller update. My remote A/P's are less happy as with Override inform host with controller hostname/IP checked, I get STUN errors.

Might be easier to spin up another container for my remote A/P's?

 

[jeyare]

SSH is the proper way for all the illness based on wrong adoption

 

[xbmcnut]

@jeyare Thanks. My problem with my remote site is when I SSH in after a factory reset (without removing the device from the controller), after successful adoption the SSH connection dumps me which is OK but it does not pick up the SSH credentials from the controller for some reason. ubnt:ubnt works to adopt after reset but after adoption, I can no longer SSH in. I've tried accessing locally when it's like this and same thing, unknown username and password.

Ironically, I adopted a new switch locally yesterday and while I was booted out of the SSH SSH during adoption, logging back in with the controller SSH credentials was possible.

Should I remove the problematic A/P's from the controller first, reset them and try again?

 

[jeyare]

@xbmcnut

1. Clear pls. this part of your description:

My problem with my remote site is when I SSH in after a factory reset (without removing the device from the controller),

a) the factory reset = did you mean "forgetting" of adopted device by Controller GUI or "set-default" by SSH of the device or by Physical reset?
b) the factory reset of what? AP?

After factory reset you can use:
ubnt/ubnt or root/ubnt credentials by SSH
then adopt to proper controller:

set-inform http://Controller-IP-Public-Address: port/inform
..... Primary site

after adoption you will use administration credentials defined in the Unifi Controller = one of the reason for the adoption process.

OFC, you can do it:

Should I remove the problematic A/P's from the controller first, reset them and try again?

use one of these methods:
- "forgetting" of adopted device by Controller GUI
- "set-default" by SSH
- Physical reset of the device
all of them provide clean factory reset of the device

2. You don’t need another container for your remote site APs.
You need just single container for all the sites, then:
- proper STUN port forwarding from remote site to your primary (NAS/Docker): 3478
- also proper "inform" port forwarding: 8080
- also for Remote Guest portal management: e.g. 8880

nothing more

 

[xbmcnut]

@jeyare Thanks for the reply. Yes, I reset both AC Lite's by using the reset button on the power supply but without removing them from the controller. This restored access to them using ubnt:ubnt and set-inform was used to reconnect them back to my remote controller. One of them also had set-default used prior as a test.

While they both joined the controller and we're happy and connected, SSH access was gone as neither ubnt:ubnt or the controller SSH credentials work so something odd is going on. I'm going to try and remove them from the controller first and then ask the customer to use the reset button as well to see if I can somehow restore controller based SSH access.

In regards set-inform, I always use SSH but I suppose the question is whether you can have the controller set to use the IP of the NAS and IP override on to keep my local devices super happy after upgrade/restart (even though I use SSH to join them as well) and have the remote AP's using a different FQDN for their set-form address and have this remembered through all restarts and upgrades.

 

[jeyare]

@xbmcnut
regarding reset of Unifi devices adopted into controller:
- device after reset lose adoption, what is OK. Doesn't mater what kind of reset method was used (mentioned in my previous post).

Next:

While they both joined the controller and we're happy and connected, SSH access was gone as neither ubnt:ubnt or the controller SSH credentials work so something odd is going on.

Q1: to be sure the access was established (SSH target = LAN IP address of the AP)? Y/N
Q1.1: SSH access from primary site to the remote site AP (thought WAN)?
Q2: but the access was denied? Y/N
Q2.1: used Authentication for the defined Unifi Controller Admin credentials? Y/N

just to be sure:
try to open USG page from browser e.g. http://192.168.1.1 .... up to your IP config
and use the SSH credential failed (Q2 + Q2.1) in the SSH access to AP
when yours Controller Admin credential fails, so then you have set different credentials for SSH access (what is also OK) and you have to use right credentials for the SSH access (Settings/Site/Enable Advanced features), don't forget to chose right Site in Site selector (Top-right corner):

Last point:

In regards set-inform, I always use SSH but I suppose the question is whether you can have the controller set to use the IP of the NAS and IP override on to keep my local devices super happy after upgrade/restart (even though I use SSH to join them as well) and have the remote AP's using a different FQDN for their set-form address and have this remembered through all restarts and upgrades.

This is my setup:

1. as you can see the checkbox for Override inform is empty
and my Remote devices are always happy after upgrade to new device firmware - no need perform the adoption. Each Reset of Unifi devices to factory default reasonable needs the adoption process (set inform).
2. Because your controller IP is IP defined by Docker, you need unchecked the Override inform feature. This just one annoying tax for the perfect containerized solution for your Controller.

Regarding the IP address for the adoption:
- Primary site (NAS) needs NAS IP address
- each remote sites need WAN IP of your Gateway, properly NATed to NAS (mentioned in my previous post).