zimmertr

Members
  • Posts

    5
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

zimmertr's Achievements

Noob

Noob (1/14)

0

Reputation

  1. 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.
  2. 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.AppContext.Ò00000()] 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.
  3. 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
  4. 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.
  5. So I've managed to get the Unifi Controller image working with an external database however the Unifi Controller never actually starts up. Using MongoDB 3.4.19. The Server.log stops adding entries after it connects to the database and the mongod.log is never created. [2019-02-10 18:37:32,771] <launcher> INFO system - *** Running for the first time, creating identity *** [2019-02-10 18:37:32,779] <launcher> INFO system - UUID: bf5e13cf-3c84-476b-aaa3-e9feb51ae995 [2019-02-10 18:37:32,820] <launcher> INFO system - ====================================================================== [2019-02-10 18:37:32,821] <launcher> INFO system - UniFi 5.6.40 (build atag_5.6.40_10370 - release) is started [2019-02-10 18:37:32,821] <launcher> INFO system - ====================================================================== [2019-02-10 18:37:32,828] <launcher> INFO system - BASE dir:/usr/lib/unifi [2019-02-10 18:37:32,848] <launcher> INFO system - Current System IP: 192.168.0.1 [2019-02-10 18:37:32,848] <launcher> INFO system - Hostname: unifi-controller-5bb95c7688-xj99j [2019-02-10 18:37:36,202] <launcher> INFO db - waiting for db connection... [2019-02-10 18:37:36,722] <launcher> INFO db - Connecting to mongodb://ubnt:PASSWORD@unifi-controller-mongodb:27017/unifi [2019-02-10 18:37:51,296] <launcher> INFO db - Connecting to mongodb://ubnt:PASSWORD@unifi-controller-mongodb:27017/unifi_stat [2019-02-10 18:37:54,295] <launcher> INFO webrtc - WebRTC library version: EvoStream Media Server (www.evostream.com) build v1.0.31 - Gladiator - (built for Debian-7.0.5-x86_64 on 2018-02-01T22:48:38.000) OpenSSL version: 1.0.2l usrsctp version: 6d79bcc19755bc08 compiled on machine: Linux debian-7-0-5-64 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u6 x86_64 GNU/Linux [2019-02-10 18:38:56,232] <autoupdate-check> INFO system - firmware[U7E] new version (3.8.17.6789) is available [2019-02-10 18:38:56,233] <autoupdate-check> INFO system - firmware[U7MP] new version (4.0.21.9965) is available [2019-02-10 18:38:56,233] <autoupdate-check> INFO system - firmware[U7SHD] new version (4.0.21.9965) is available [2019-02-10 18:38:56,233] <autoupdate-check> INFO system - firmware[US48] new version (4.0.21.9965) is available [2019-02-10 18:38:56,233] <autoupdate-check> INFO system - firmware[U7O] new version (3.8.17.6789) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[U7P] new version (4.0.15.9872) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[U7PG2] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[U7EDU] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[U7IW] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[US48P500] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[USXG] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[S216150] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[BZ2LR] new version (4.0.15.9872) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[U7LT] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[U7LR] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[UHDIW] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[U2Sv2] new version (4.0.15.9872) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[US24P500] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[US24PL2] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[US48P750] new version (4.0.21.9965) is available [2019-02-10 18:38:56,234] <autoupdate-check> INFO system - firmware[S224250] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[S248750] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[S224500] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[US24] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[US8P60] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[U2IW] new version (4.0.15.9872) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[U5O] new version (4.0.15.9872) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[U2HSR] new version (4.0.15.9872) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[U7NHD] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[USC8] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[US8P150] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[U7HD] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[US16P150] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[BZ2] new version (4.0.15.9872) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[US8] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[US48PL2] new version (4.0.21.9965) is available [2019-02-10 18:38:56,235] <autoupdate-check> INFO system - firmware[US24P250] new version (4.0.21.9965) is available [2019-02-10 18:38:56,236] <autoupdate-check> INFO system - firmware[U7MSH] new version (4.0.21.9965) is available [2019-02-10 18:38:56,236] <autoupdate-check> INFO system - firmware[U7IWP] new version (4.0.21.9965) is available [2019-02-10 18:38:56,236] <autoupdate-check> INFO system - firmware[UGW4] new version (4.4.29.5124212) is available [2019-02-10 18:38:56,236] <autoupdate-check> INFO system - firmware[UGW3] new version (4.4.29.5124210) is available [2019-02-10 18:38:56,240] <autoupdate-check> INFO system - firmware[S28150] new version (4.0.21.9965) is available [2019-02-10 18:38:56,240] <autoupdate-check> INFO system - firmware[U2Lv2] new version (4.0.15.9872) is available [2019-02-10 18:38:56,240] <autoupdate-check> INFO system - firmware[U2O] new version (4.0.15.9872) is available [2019-02-10 18:38:56,240] <autoupdate-check> INFO system - firmware[U7Ev2] new version (3.8.17.6789) is available [2019-02-10 18:38:56,240] <autoupdate-check> INFO system - firmware[UGWXG] new version (4.4.29.5124239) is available [2019-02-10 18:38:56,240] <autoupdate-check> INFO system - firmware[S248500] new version (4.0.21.9965) is available If I manually connect to the database and run a show collections I can see that the controller has talked to the database as there are many new collections obviously created by the controller. EG: firewallgroup, broadcastgroup, networkconf, etc. $> mongo -host mongodb://ubnt:PASSWORD@unifi-controller-mongodb:27017/unifi MongoDB shell version v3.4.19 connecting to: mongodb://ubnt:PASSWORD@unifi-controller-mongodb:27017/unifi MongoDB server version: 3.4.19 Welcome to the MongoDB shell. For interactive help, type "help". For more comprehensive documentation, see http://docs.mongodb.org/ Questions? Try the support group http://groups.google.com/group/mongodb-user > show collections account admin alarm broadcastgroup device dpiapp dpigroup dynamicdns event extension firewallgroup firewallrule guest heatmap heatmappoint hotspot2conf hotspotop hotspotpackage map mediafile networkconf payment portalfile portconf portforward privilege radiusprofile rogue rogueknown routing scheduletask setting site stat tag task user usergroup verification voucher wall wlanconf wlangroup Here are the logs from STDOUT: [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 10-adduser: executing... ------------------------------------- _ () | | ___ _ __ | | / __| | | / \ | | \__ \ | | | () | |_| |___/ |_| \__/ Brought to you by linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donate/ ------------------------------------- GID/UID ------------------------------------- User uid: 1002 User gid: 1007 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] 20-config: executing... [cont-init.d] 20-config: exited 0. [cont-init.d] 30-keygen: executing... Warning: The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /config/data/keystore -destkeystore /config/data/keystore -deststoretype pkcs12". [cont-init.d] 30-keygen: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. And lastly a lame attempt at starting the service manually: root@unifi-controller-c76f46bcc-nnrhh:/usr/lib/unifi# service unifi status * unifi is not running root@unifi-controller-c76f46bcc-nnrhh:/usr/lib/unifi# service unifi start * Starting Ubiquiti UniFi Controller unifi [fail] root@unifi-controller-c76f46bcc-nnrhh:/usr/lib/unifi# service unifi stop * Stopping Ubiquiti UniFi Controller unifi [ OK ] root@unifi-controller-c76f46bcc-nnrhh:/usr/lib/unifi# service unifi start * Starting Ubiquiti UniFi Controller unifi [fail] Any idea how I can continue troubleshooting from here? I'm at my witts end unfortunately after 2 days of work.