Jump to content
linuxserver.io

[Support] Linuxserver.io - Unifi

902 posts in this topic Last Reply

Recommended Posts

I'm sorry for causing such a hubub.  I really didn't mean for this to get out of hand.

 

 

Share this post


Link to post

I take offense not only on behalf of the LS team for the routine version complaining asshattery. But also because said recent instance of asshattery buried my legitimate and actually unique query for support. 

 

So I thought maybe I'd bump it in hopes of seeing if anyone knows how I can continue troubleshooting it. 

 

https://forums.unraid.net/topic/42110-support-linuxserverio-unifi/?do=findComment&comment=719766

 

Using an external MongoDB instance is a supported method of deploying the controller so I'm dead set on getting it to work in the container. Nothing about being a Docker container should make this fail to work. I'm determined. Plus this container is not so usable within Kubernetes when the MongoDB instance is bundled alongside it since it cannot be scaled to more than one replica. As this will cause the database to crash.

 

Other people have supposedly gotten this to work. At least they've done the same work I have in a different way. For example this other container supports this via environment variables but yields the same result. And there's even a Helm chart to accomplish this. Which I also cannot get working for the same reason. Here is my implementation in Kubernetes if anyone wants to poke around. 

 

As always a big thank you to the LS team for being the best resource for Docker containers on the internet. And of course all of the work they volunteer for the community. 

Edited by zimmertr

Share this post


Link to post
43 minutes ago, zimmertr said:

I take offense not only on behalf of the LS team for the routine version complaining asshattery. But also because said recent instance of asshattery buried my legitimate and actually unique query for support. 

 

So I thought maybe I'd bump it in hopes of seeing if anyone knows how I can continue troubleshooting it. 

 

https://forums.unraid.net/topic/42110-support-linuxserverio-unifi/?do=findComment&comment=719766

 

Using an external MongoDB instance is a supported method of deploying the controller so I'm dead set on getting it to work in the container. Nothing about being a Docker container should make this fail to work. I'm determined. Plus this container is not so usable within Kubernetes when the MongoDB instance is bundled alongside it since it cannot be scaled to more than one replica. As this will cause the database to crash.

 

Other people have supposedly gotten this to work. At least they've done the same work I have in a different way. For example this other container supports this via environment variables but yields the same result. And there's even a Helm chart to accomplish this. Which I also cannot get working for the same reason. Here is my implementation in Kubernetes if anyone wants to poke around. 

 

As always a big thank you to the LS team for being the best resource for Docker containers on the internet. And of course all of the work they volunteer for the community. 

I don't think any of us are running unifi with external db and in kubernetes. So we will be of little help. 

 

Does it work if you use an IP instead of name to connect to the db? 

And you set it up like the solution in this thread: https://community.ubnt.com/t5/UniFi-Wireless/External-MongoDB-Server/td-p/1305297

 

Are you using unraid? 

Edited by saarg

Share this post


Link to post

I think there should be a description in the OP about how the versions work for this image and anytime someone asks a question about why the image isn't "up to date" they should only be directed to the OP.  No responses, just a link to the OP.  I too am tired of LSIO having to continually explain themselves because of this image.  

Share this post


Link to post
Quote

Does it work if you use an IP instead of name to connect to the db? 

This isn't something I have tried but I don't think it would change anything. Kubernetes randomly assigns a pod (container) an IP Address on provisioning. However, coredns (Common DNS resolver for Kubernetes) allows you to resolve pods by hostname via the name that you set for the service (Object that defines access to a pod). I can try and swap it to an IP manually after deployment though I suppose. 

tl;dr I can manually exec into the container and connect to the external database without any issues. Also, Unifi is definitely networking with the database because it is provisioning many collections on the `unifi` database that I created. The logs just stop after this point. And the unifi service itself never starts up. And if I try and manually start it from within the container it just says  FAIL without logging a failure reason. 
 

Quote

Are you using unraid?


I am not using Unraid. I am deploying this to a Kubernetes cluster created with Kubeadm that lives on top of Proxmox 5.3-8

Edited by zimmertr

Share this post


Link to post
23 minutes ago, zimmertr said:

This isn't something I have tried but I don't think it would change anything. Kubernetes randomly assigns a pod (container) an IP Address on provisioning. However, coredns (Common DNS resolver for Kubernetes) allows you to resolve pods by hostname via the name that you set for the service (Object that defines access to a pod). I can try and swap it to an IP manually after deployment though I suppose. 

tl;dr I can manually exec into the container and connect to the external database without any issues. Also, Unifi is definitely networking with the database because it is provisioning many collections on the `unifi` database that I created. The logs just stop after this point. And the unifi service itself never starts up. And if I try and manually start it from within the container it just says  FAIL without logging a failure reason. 
 


I am not using Unraid. I am deploying this to a Kubernetes cluster created with Kubeadm that lives on top of Proxmox 5.3-8

This is all out of my experience, so not much I can help with I'm afraid. 

I think the only one of us that have experience with kubernetes is @ironicbadger but unsure if he used unifi. 

 

This is support for unraid users, so better to use our discourse/discord/github for support. 

 

Share this post


Link to post
This is all out of my experience, so not much I can help with I'm afraid. 
I think the only one of us that have experience with kubernetes is [mention=11173]ironicbadger[/mention] but unsure if he used unifi. 
 
This is support for unraid users, so better to use our discourse/discord/github for support. 
 
Pretty sure IB does have a Unifi

Sent from my Mi A1 using Tapatalk

Share this post


Link to post

I might have found a possible cause of the issue. 

I have written the following script that runs at provision time for the MongoDB container:

mongo \
  --username ubnt \
  --password "{{ mongodb_password }}" \
  --authenticationDatabase admin \
  --eval 'db.getSiblingDB("unifi").createUser({user: "ubnt", pwd: "{{ mongodb_password }}", roles: [{role: "readWrite", db: "unifi"}]})'

  mongo \
  --username ubnt \
  --password "{{ mongodb_password }}" \
  --authenticationDatabase admin \
  --eval 'db.getSiblingDB("unifi_stat").createUser({user: "ubnt", pwd: "{{ mongodb_password }}", roles: [{role: "readWrite", db: "unifi_stat"}]})'

And then I have configured the Unifi Controller to talk to the database through a volume mounted `system.properties` file configured like so:

# Inform IP Address
system_ip={{ load_balancer_ip }}

# Autobackup directory
autobackup.dir=/backups

# External MongoDB information
db.mongo.local=false
db.mongo.uri=mongodb://ubnt:{{ mongodb_password }}@unifi-controller-mongodb:27017/unifi
statdb.mongo.uri=mongodb://ubnt:{{ mongodb_password }}@unifi-controller-mongodb:27017/unifi_stat
unifi.db.name=unifi

As mentioned, this all works. And I can confirm that the Unifi Controller talks with the external MongoDB database since many collections are made in both `unifi` and `unifi_stat`. However, the Unifi Controller stops producing logs there and never actually starts up.

I discovered that the Controller is started within the container by executing a jar file. So I tried to stop and start this jar and the following stack trace appeared:

$> s6-setuidgid abc java -Xmx1024M -jar /usr/lib/unifi/lib/ace.jar start
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
Exception in thread "launcher" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'Ò00000' defined in class com.ubnt.service.AppContext: Instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Factory method [com.ubnt.service.P.D com.ubnt.service.AppContext00000()] threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dbService' defined in class com.ubnt.service.AppContext: Invocation of init method failed; nested exception is com.mongodb.CommandFailureException: { "serverUsed" : "unifi-controller-mongodb:27017" , "ok" : 0.0 , "errmsg" : "not authorized on unifi to execute command { dropDatabase: 1 }" , "code" : 13 , "codeName" : "Unauthorized"}

The key element here is

Quote

not authorized on unifi to execute command { dropDatabase: 1 }"

And this is where my understanding of MongoDB comes to an end. And my question comes to a beginning. I believe that the reason the Unifi Controller does not continue to start or log any additional messages after connecting to the database and creating the collections is that it is silently failing to perform an action on the MongoDB database. For which it does not have the requisite permissions to do.
 

When I provision the MongoDB Docker container, I specify the `MONGO_INITDB_ROOT_USERNAME` & `MONGO_INITDB_ROOT_PASSWORD` environment variables. Which, I believe, turns `auth` mode on. This belief is reiterated by the fact that I can connect to MongoDB's `admin` authentication database via the username and password I provide to these variables.

However, based on the script I posted above that creates my databases and assigns the role `readWrite` to the `ubnt` user, I'm curious how I should go about giving the `ubnt` user the requisite permissions required to drop a database. If I swap out `readWrite` for other roles like `root` and `dbAdminAnyDatabase` the commands fail.

What do I have to do to make it so my ubnt user can drop the `unifi` and `unifi_stat` databases? Or what do I have to change about my connection strings to prevent this from happening? I'm a bit of a database admin noob.

Share this post


Link to post
42 minutes ago, zimmertr said:

I might have found a possible cause of the issue. 

I have written the following script that runs at provision time for the MongoDB container:


mongo \
  --username ubnt \
  --password "{{ mongodb_password }}" \
  --authenticationDatabase admin \
  --eval 'db.getSiblingDB("unifi").createUser({user: "ubnt", pwd: "{{ mongodb_password }}", roles: [{role: "readWrite", db: "unifi"}]})'

  mongo \
  --username ubnt \
  --password "{{ mongodb_password }}" \
  --authenticationDatabase admin \
  --eval 'db.getSiblingDB("unifi_stat").createUser({user: "ubnt", pwd: "{{ mongodb_password }}", roles: [{role: "readWrite", db: "unifi_stat"}]})'

And then I have configured the Unifi Controller to talk to the database through a volume mounted `system.properties` file configured like so:


# Inform IP Address
system_ip={{ load_balancer_ip }}

# Autobackup directory
autobackup.dir=/backups

# External MongoDB information
db.mongo.local=false
db.mongo.uri=mongodb://ubnt:{{ mongodb_password }}@unifi-controller-mongodb:27017/unifi
statdb.mongo.uri=mongodb://ubnt:{{ mongodb_password }}@unifi-controller-mongodb:27017/unifi_stat
unifi.db.name=unifi

As mentioned, this all works. And I can confirm that the Unifi Controller talks with the external MongoDB database since many collections are made in both `unifi` and `unifi_stat`. However, the Unifi Controller stops producing logs there and never actually starts up.

I discovered that the Controller is started within the container by executing a jar file. So I tried to stop and start this jar and the following stack trace appeared:


$> s6-setuidgid abc java -Xmx1024M -jar /usr/lib/unifi/lib/ace.jar start
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called
Exception in thread "launcher" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'Ò00000' defined in class com.ubnt.service.AppContext: Instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Factory method [com.ubnt.service.P.D com.ubnt.service.AppContext00000()] threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dbService' defined in class com.ubnt.service.AppContext: Invocation of init method failed; nested exception is com.mongodb.CommandFailureException: { "serverUsed" : "unifi-controller-mongodb:27017" , "ok" : 0.0 , "errmsg" : "not authorized on unifi to execute command { dropDatabase: 1 }" , "code" : 13 , "codeName" : "Unauthorized"}

The key element here is

And this is where my understanding of MongoDB comes to an end. And my question comes to a beginning. I believe that the reason the Unifi Controller does not continue to start or log any additional messages after connecting to the database and creating the collections is that it is silently failing to perform an action on the MongoDB database. For which it does not have the requisite permissions to do.
 

When I provision the MongoDB Docker container, I specify the `MONGO_INITDB_ROOT_USERNAME` & `MONGO_INITDB_ROOT_PASSWORD` environment variables. Which, I believe, turns `auth` mode on. This belief is reiterated by the fact that I can connect to MongoDB's `admin` authentication database via the username and password I provide to these variables.

However, based on the script I posted above that creates my databases and assigns the role `readWrite` to the `ubnt` user, I'm curious how I should go about giving the `ubnt` user the requisite permissions required to drop a database. If I swap out `readWrite` for other roles like `root` and `dbAdminAnyDatabase` the commands fail.

What do I have to do to make it so my ubnt user can drop the `unifi` and `unifi_stat` databases? Or what do I have to change about my connection strings to prevent this from happening? I'm a bit of a database admin noob.

Happy to help, but with all due respect, you're not an Unraid user and we have other support channels that are more appropriate for this.  As it states in the first post...

 

Quote

If you are not using Unraid (and you should be!) then please do not post here, instead head to linuxserver.io to see how to get support.

 

Share this post


Link to post

You're correct, I apologize. I'll refrain from posting here any more.

I only came here as a last resort after working on this for two entire days. I did post in the Discord before posting here for what it is worth. But the ephemeral means of communication there aren't really conductive for troubleshooting such a detailed problem. And I decided to post here due to the level of activity that the thread has experienced. 

Thank you for your time. 

Share this post


Link to post
4 minutes ago, zimmertr said:

You're correct, I apologize. I'll refrain from posting here any more.

I only came here as a last resort after working on this for two entire days. I did post in the Discord before posting here for what it is worth. But the ephemeral means of communication there aren't really conductive for troubleshooting such a detailed problem. And I decided to post here due to the level of activity that the thread has experienced. 

Thank you for your time. 

We have our own Discourse forum too. ;)

 

Share this post


Link to post

So it's pretty easy to just fork the linuxserver.io images and modify the Dockerfiles as needed, and build the image yourself to run a new image. That's the beauty of Docker, it's fairly easy to take an upstream image or Dockerfile and modify it.

So, for everyone complaining, you can do that, just like I've done. Here's a 5.10.12 image for anyone unable to do the above themselves. That said:
- You should always verify images yourself, so while I consider myself a good guy, you shouldn't just trust me/random images.
- There's no guarantee at all this will work for you, and I've done effectively 0 testing of this version, as I needed it to migrate from my windows Unifi controller after setting up my gear.
- My image tags may change wildly, so this could cause you to pull new versions unexpectedly.

Here's my fork's unstable branch: https://github.com/chancez/docker-unifi/compare/unstable...NASholes:unstable
The image is quay.io/nasholes/unifi:unstable, which you can find at https://quay.io/repository/nasholes/unifi?tab=tags

Builds are just automated from Github pushes like Docker hub does. I will probably switch back to the upstream Linuxserver.io images when they're available, so don't expect updates.

Share this post


Link to post

Dang, I missed all the fun over the weekend! 😀

 

Why does this UniFi docker cause so much angst if the unstable branch is not up-to-the-minute up-to-date?  I don't see this with ANY other docker.

 

Frankly, I think LSIO is doing us a favor by waiting a few days after public release given Ubiquiti's less-than-stellar track record with major new releases.  If the prior version is working, what's the rush to try a release that has a 50/50 chance of breaking something?  It must be the hope that Ubiquiti has finally implemented some basic and oft-requested missing features in the GUI.  I am still waiting for OpenVPN Server for the USG/UniFI GUI since it is in the EdgeRouter GUI.

 

There is another UniFi docker that updates frequently to the latest version, even those that are not publicly released.  If LSIO doesn't move fast enough for you, maybe you should try that one.  I prefer LSIO for my dockers when possible, so, I am happy to wait on their schedule.

 

Carry on.

 

  • Upvote 1

Share this post


Link to post

anyone having issues accessing the WebUI? all of a sudden it is refusing to connect

Share this post


Link to post
17 hours ago, Aurao said:

anyone having issues accessing the WebUI? all of a sudden it is refusing to connect

Mine's been fine...

Share this post


Link to post
17 hours ago, Aurao said:

anyone having issues accessing the WebUI? all of a sudden it is refusing to connect

No problems here.

Share this post


Link to post
On 2/11/2019 at 4:50 PM, Hoopster said:

Dang, I missed all the fun over the weekend! 😀

 

Why does this UniFi docker cause so much angst if the unstable branch is not up-to-the-minute up-to-date?  I don't see this with ANY other docker.

 

Frankly, I think LSIO is doing us a favor by waiting a few days after public release given Ubiquiti's less-than-stellar track record with major new releases.  If the prior version is working, what's the rush to try a release that has a 50/50 chance of breaking something?  It must be the hope that Ubiquiti has finally implemented some basic and oft-requested missing features in the GUI.  I am still waiting for OpenVPN Server for the USG/UniFI GUI since it is in the EdgeRouter GUI.

 

There is another UniFi docker that updates frequently to the latest version, even those that are not publicly released.  If LSIO doesn't move fast enough for you, maybe you should try that one.  I prefer LSIO for my dockers when possible, so, I am happy to wait on their schedule.

 

Carry on.

 

We very regularly ponder this amongst ourselves as well. 

 

Sometimes people mention "security" but given that Unifi is a huge cut above most consumer routers and ISP provided hardware I think they are vastly overestimating the attack vector on their own home network unless they're on a corporate network, in which case, they really should be contracting someone to maintain their own software or be purchasing a cloud controller, not relying on us. 

 

That is unless they want to start donating a monthly fee to provide corporate support, but nobody has every approached us enquiring about this so I'm guessing that's not the case.  :D

 

I assume everyone is running a small home network and my opinion is based on that assumption.

  • Upvote 1

Share this post


Link to post

I am very happy with what LSIO provides, it fulfills my personal requirements perfectly. Keep up the good work.

  • Upvote 3

Share this post


Link to post

Perfectly happy with the work LSIO does, the only feature I need from 5.10 is dark mode so I don't have to switch windows to night mode when I check on my network. 😉

 

Making a docker for yourself is extremely easy, making a flexible one that works for the masses is worth money IMO. (https://www.linuxserver.io/donate)

Share this post


Link to post

LOL - Since the public release of 5.10.12 last week, several new releases have come out (each with issues).  The latest 'stable' release on the public download page is now 5.10.17 and there are two pages of complaints about it in their forums. 

Share this post


Link to post
LOL - Since the public release of 5.10.12 last week, several new releases have come out (each with issues).  The latest 'stable' release on the public download page is now 5.10.17 and there are two pages of complaints about it in their forums. 
Sounds about normal.....

Sent from my Mi A1 using Tapatalk

Share this post


Link to post

Is anyone else having memory issues? I just restarted Unifi and my memory usage went from 91% down to 54%, is this normal with 8GB of ram. I know if I didn't restart Unifi I'm pretty sure it would have froze my system after maxing out the memory.

 

When I looked at top.txt it shows mongod using 38.7.

 

Is there a setting I should check? either in Unraid or Unifi?

Share this post


Link to post
1 hour ago, Bydgoszcz said:

Is anyone else having memory issues? I just restarted Unifi and my memory usage went from 91% down to 54%, is this normal with 8GB of ram. I know if I didn't restart Unifi I'm pretty sure it would have froze my system after maxing out the memory.

 

When I looked at top.txt it shows mongod using 38.7.

 

Is there a setting I should check? either in Unraid or Unifi?

Never noticed any issues and to be honest, we're not going to bother investigating at the moment, as we're in the process of developing a new container.

Share this post


Link to post
4 hours ago, Bydgoszcz said:

Is anyone else having memory issues? I just restarted Unifi and my memory usage went from 91% down to 54%, is this normal with 8GB of ram. I know if I didn't restart Unifi I'm pretty sure it would have froze my system after maxing out the memory.

 

When I looked at top.txt it shows mongod using 38.7.

 

Is there a setting I should check? either in Unraid or Unifi?

 

@Bydgoszcz I do not think this is not the containers fault - it's MongoDB issue I've seen over at the UniFi forums. I have the same problem. Two options to deal with it - limit the amount of RAM that he container can use (add -m "2g" to the extra parameters field to limit to 2GB) to prevent it from making other containers and server angry OR try and have the controller directly limit the amount of RAM that it uses setting "unifi.xms=256" or similar in UniFi properties (see here for discussion).

 

You could also try pruning the database to see if that's contributing to the issue - see here for the script

 

I did the easy thing and just limited my docker container., hoping that one day the controller will behave better...

 

 

Edited by sreknob
add prune info
  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now