[BUG] Cannot use different root username/password versus unifi

[jmealo]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

If you don't set the root username and password equal to that of the unifi username and password then unifi-network-application will fail to authenticate.

Expected Behavior

For the root username and password to be different than the application username and password.
For the provided init script to work properly.

Steps To Reproduce

1. Do not use the same username/password for root and mongo/application user

Environment

- OS:
- How docker service was installed:

CPU architecture

x86-64

Docker creation

N/A

Container logs

Already provided in hastily closed issues.

[aptalca]

The live test I linked uses different user/pass for the root and the db user.

You have not followed the instructions exactly. You set an extra var we don't list. Please look at it more closely.

And please stop opening new issues.

[jmealo]

This is the worst maintained image under the LinuxServer project. I sunk hours into troubleshooting prior to you issuing this "fix" and it's still full of foot canons. Folks using other environment variables doesn't negate the fact that this is brittle, error prone and a complete pain to use. I could have done all of this from scratch faster but wanted to help the community, however, the gatekeeper is OK with the experience being horrible.

Also, my config works fine when the username/password are the same for root and application user.

If there's some environment variable that cannot be set (or it breaks your script) then your script should:
a) unset it
b) log a warning when the incompatible env variable is used

[aptalca]

Dude, it's not even our image. It's the official mongodb image. We have nothing to do with it. We have no control over how it interprets the vars or what it does with them.

We could have just left it at unifi requires a mongodb set up, and put the entire burden on you. But we're being nice and including a compose snippet along with an sh file to get you up and running as easily as possible.

You failed to follow the instructions, and it didn't work. It happens. Then you claimed our instructions were wrong, turns out they aren't.

You could have easily said oh, my bad, totally missed that and we would all move on.

But no, you choose to complain about it, still looking for others to blame. Oh well, I wish you the best of luck in your future endeavors.

[jmealo]

🤦 Dude, I've had it working before and after these instructions. I'm trying to help you fix the README, to save other people time, but for some reason, you think everyone on here is an idiot, despite the fact that some of us do this for a living. I could tell going through the issue history that you had an attitude problem. Try to treat people the way you want to be treated.

The issues are with your provided script and the docker-compose config, not the mainline MongoDB image.

If there is some environment variable that you feel breaks your script and it isn't compatible, then call it out instead of closing issues. If you're going to provide a script, and tell us to use it as-is, without modifying it, it should be compatible with the MongoDB image's environment variables.

If you take a BIG STEP BACK, and actually try to follow the README, it's not difficult to break this, and it's not going to be within most people's ability to troubleshoot it. If you don't think that's a problem, then we disagree, but I'd argue you should reconsider being a maintainer if you don't want to engage with the community constructively and prefer to close tickets without understanding the underlying issue.

[aptalca]

Thanks, but no thanks. There is nothing to fix. As shown in the live test, the instructions as provided do indeed work.

We list one way to set it up as an example/suggestion. If you want to set it up differently, feel free to do so. But you'd be on your own. We have no interest in listing all the myriad of changes that can break the script.

Please refrain from personal attacks and it's time to move on.

[chrisdoherty4]

FWIW, the README is fine. My issue was that mongodb wasn't initializing properl. The tremendous amount of logging made it difficult to spot various errors. If you have issues, I would encourage you to launch it on its own and evaluate the logging.

I use a secrets setup for good practice in the least. This required some wangling of environment variables and an appreciation for how the initialization passes the secrets to the init scripts (details are irrelevant, the below just works).

services:
  mongodb:
    image: docker.io/mongo:7.0
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD_FILE=/run/secrets/mongodb-initdb-password
      - MONGO_USER=unifi
      - MONGO_PASSWORD_FILE=/run/secrets/mongodb-password
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
    - /var/lib/mongodb/db:/data/db
    - ./init-mongo.sh:/docker-entrypoint-initdb.d/init-mongo.sh:ro
    networks:
    - unifi
    expose:
    - 27017:27017
    secrets:
    - mongodb-initdb-password
    - mongodb-password
    restart: unless-stopped
  unifi:
    image: lscr.io/linuxserver/unifi-network-application:8.4.62
    container_name: unifi-network-application
    environment:
      # - PUID=1000
      # - PGID=1000
      - TZ=Etc/UTC
      - MONGO_USER=unifi
      - FILE__MONGO_PASS=/run/secrets/mongodb-password
      - MONGO_HOST=mongodb
      - MONGO_PORT=27017
      - MONGO_DBNAME=unifi
      - MONGO_AUTHSOURCE=admin
    volumes:
      - /var/lib/unifi-network-manager:/config
    networks:
    - unifi
    ports:
      - 8443:8443
      - 3478:3478/udp
      - 10001:10001/udp
      - 8080:8080
      - 1900:1900/udp
      - 8843:8843
      - 8880:8880
      - 6789:6789
      - 5514:5514/udp
    secrets:
    - mongodb-password
    restart: unless-stopped

secrets:
  mongodb-initdb-password:
    file: ./secret/mongodb-initdb-root-password
  mongodb-password:
    file: ./secret/mongodb-root-password

networks:
  unifi:

The init-mongo.sh is functionally the same - I just wangled it for some debugging.

#!/bin/bash

INIT_SCRIPT=/tmp/init

cat > $INIT_SCRIPT <<EOF
use ${MONGO_AUTHSOURCE}
db.auth("${MONGO_INITDB_ROOT_USERNAME}", "${MONGO_INITDB_ROOT_PASSWORD}")
db.createUser({
  user: "${MONGO_USER}",
  pwd: "$(cat ${MONGO_PASSWORD_FILE})",
  roles: [
    { db: "${MONGO_DBNAME}", role: "dbOwner" },
    { db: "${MONGO_DBNAME}_stat", role: "dbOwner" }
  ]
})
disableTelemetry()
EOF

mongosh <<< $(cat $INIT_SCRIPT)

@aptalca if you have the bandwidth you might consider transitioning to this to promote good security practice. The major tradeoff being people would need a rudimentary understanding of secrets.

[aptalca]

I'm already fed up with the current number of readme is wrong, it doesn't work type of support requests that I have no intention of making it any more complicated.

9 times out of 10, users create secret files with trailing newlines and it doesn't work.

We have the built-in support for secrets for any env var and there is a section on it in each readme. Advanced users can figure it out.