mirror of
https://github.com/qdm12/ddns-updater.git
synced 2026-05-31 12:21:43 -04:00
FEATURE REQUEST: read environment variables for setup #35
Assignees
saavagebueno
Clear assignees
saavagebueno
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/ddns-updater#35
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bcurran3 on GitHub (May 21, 2020).
Originally assigned to: @qdm12 on GitHub.
It would be absolutely positively greatly beneficially (I'm in a "lee" mood) enhance ddns-updater to alternatively read all (config.json) setup variables from environment variables. This would add the ability to completely script an install without having to manually create or modify any files.
@qdm12 commented on GitHub (May 21, 2020):
Ha that's how it was initially, with environment variables only! Problem is, supporting corner cases with different providers, different accounts on the same provider etc is a bit of a nightmare that way.
On the other hand, maybe the container could output a compressed base64 encoded string of your json config file so that you can put it in an env variable for a subsequent fileless run. What do you think?
@bcurran3 commented on GitHub (May 21, 2020):
Ironic!
I didn't necessarily understand all that, :), but I'm good with anything that's easily and generically script-able. The way I would do it (that is if I was able, HA! Kudos to you.) would be to use the config.json but check for environment variables and they would override the values of the json file if available. If 95% of config cases could be done via changing a few lines BEFORE installing the container and having a "instantly" working container - that would be.... magnificent.
FULLY DISCLOSURE: I plan on adding this to https://github.com/davestephens/ansible-nas once it works for me.
@qdm12 commented on GitHub (May 22, 2020):
So my take on it would be to run for example:
That would give you a long (but not too long) string that contains the json content.
You can put in
-e CONFIG_BASE64=<long string>which would disable the use of the config.json file.That would even allow to remove the setup instructions with the data directory and only rely on 'converting' a config.json file.
What do you think? I'll do that today/tomorrow, it's relatively easy to do I think.
@bcurran3 commented on GitHub (May 24, 2020):
I'd have to try that and see how it worked.
The way I imagined it would be to add env settings during container creation such as:
@qdm12 commented on GitHub (May 24, 2020):
That's exactly how it was back a year or more ago hahaha 😄 (see here). The problem I see now with the environment variable is that with that new web ui, there would not be persistence when you add/edit settings. It could however generate the config file from the environment variables but you would likely have to bind mount and manage permission+ownership as it is now as well (or not forget to not delete some docker volumes).
Other than that, I guess an approach would be to just put the json config in a single line as an env variable as json doesn't require spaces/tabs/new lines. Such that it's still readable, configurable and editable.
@qdm12 commented on GitHub (May 30, 2020):
I haven't tested it fully (I've being killing off issues and PRs on this repo today haha!) but it should greatly simplify the setup somehow I think, great idea 👍
I'm starting to code an API http server such that I can do a web ui with it to create/change settings as well as see the updates in a more fashionable way 😉 I guess 2-5 weeks should do it for a web interactive frontend.
@qdm12 commented on GitHub (May 31, 2020):
Just a little note, the version from yesterday is bugged, please pull the
:latestDocker image (building here) which contains the fix. Thanks!