[Feature Request]: Allow setting Redis authpassword via docker env variables

[systemofapwne]

Description

It would be nice to be able to set an auth-password for redis backends via an env-variable in docker.
Right now, iobroker supports authentication against redis out of the box:

# Somewhere in /opt/iobroker/iobroker-data/iobroker.json

#...
 "objects": {
    "type": "redis",
    "// type": "Possible values: 'file' - [port 9001], 'jsonl' - [port 9001], 'redis' - [port 6379 or 26379 for sentinel].",
    "host": "iot_redis_1",
    "port": 6379,
    "noFileCache": false,
    "maxQueue": 1000,
    "connectTimeout": 5000,
    "writeFileInterval": 5000,
    "options": {
      "auth_pass": "SomeScretSuperCoolPasswordSetViaEnvVarInTheDockerFile",
      "retry_max_delay": 5000,
      "retry_max_count": 19,
      "db": 0,
      "family": 0
    },
#...

Adding a knob to set a password for both, states and objects, via an env-var set in a docker-compose config would be nice.
E.g.
IOB_OBJECTSDB_AUTH="somepassword"
IOB_STATESDB_AUTH="somepassword"
If these env-vars are not set, the iobroker.json file should not be touched/modified. This will not interfere with setups, where the password already has been set manually.
If these env-vars are set, the file should be modified. (even when it is the empty string "")

The reason why I ask for this is, that I already set a password in there manually. But a recent upgrade of this docker container and/or the js-controller however reset that config such, that "auth_pass" was empty. Therefore, my container stopped working with a generic "There was a problem detecting the admin instance of your iobroker"-error, while actually the redis connection could not be established due to incorrect credentials. This took me an hour to figure out.
Enforcing a password via an env-var via docker(-compose) would do the trick and is way more cleaner IMHO. That should be rather easy to implement, since your iorboker_startup.sh script already does some "jq"-magic on that config file.

[buanet]

Thanks for the request.
There is a small rework for statesdb and objectsdb configuration on my roadmap.
I will add the password together with the rework.

Regards,
André

[buanet]

Feature is now available in v8.0.0-beta.1.
I successfully tested it in my testing environment.

example:

    environment:
      - IOB_OBJECTSDB_TYPE=redis
      - IOB_OBJECTSDB_HOST=redis
      - IOB_OBJECTSDB_PORT=6379
      - IOB_OBJECTSDB_PASS=mysuperawesomesecretpassword
      - IOB_STATESDB_TYPE=redis
      - IOB_STATESDB_HOST=redis
      - IOB_STATESDB_PORT=6379
      - IOB_STATESDB_PASS=mysuperawesomesecretpassword

Would be nice if someone cloud test this and give some feedback.

Regards,
André

[buanet]

@systemofapwne Any feedback until I move this to a stable state?

Regards,
André

[systemofapwne]

Give me some time up to the weekend. I am currently busy with many side-projects but I intend to add an additional dockerized secondary ioBroker system this weekend.

[systemofapwne]

I just successfully tested the changes. Setting a password via ENVs works for states and objects.
When reviewing your changes, everything was implemented as suggested.

Thank you so much!

[systemofapwne]

Some more feedback: Using IOB_STATESDB_PASS= in order to unset a password will be omitted by this check:

ioBroker.docker/debian/scripts/setup_iob_db.sh

Line 247 in a369647

if [[ "$statesdbpass" != "" ]]; then set_statesdb_pass; fi

Same is true for objectsdb.

This is a rare situation TBH but could lead to strange situations, where unsetting a pasword is required.

Here is a nice suggestion on how to implement an "is set/is unset" check to also respect the empty string: https://stackoverflow.com/a/13864829

[buanet]

I also had this in mind, but as the database connection stays "untouched" when you do not configure its environment variables I would prefer to do this to the authentication as well. If no env is set, nothing will be touched.
This allows you to configure your database connection directly from ioBroker without setting any env.

If I would delete the password this might break it the same way but in other rare situations.

The only way I can imagine is to check on an specific value like "none" as trigger to delete the password.

Regards,
André

[buanet]

In new beta release it is now possible to empty the password with value "none". If ENV is not set, the value will stay untouched. Please test.

Regards,
André