[GH-ISSUE #1069] [FEATURE REQUEST] Configure RO_ADMIN using env vars like you configure the default user

kerem commented

2026-02-27 08:16:59 +03:00

Owner

Originally created by @traverseda on GitHub (Jan 3, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1069

Motivation

This would enable scripted deploys of services like nextcloud.

Ideally there's be a generic way to pre-populate arbitrary users through ENV vars, but barring that just duplicating the admin prepopulation to allow for the creation of a readonly user would be very useful.

Originally created by @traverseda on GitHub (Jan 3, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1069 **Motivation** This would enable scripted deploys of services like nextcloud. Ideally there's be a generic way to pre-populate arbitrary users through ENV vars, but barring that just duplicating the admin prepopulation to allow for the creation of a readonly user would be very useful.

kerem added the

enhancement

help wanted

integration

labels

2026-02-27 08:16:59 +03:00

kerem commented

2026-02-27 08:17:00 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 3, 2025):

Have you had a look at scripts/bootstrap.sh? It allows a declarative approach to creating users

@nitnelave commented on GitHub (Jan 3, 2025): Have you had a look at scripts/bootstrap.sh? It allows a declarative approach to creating users

kerem commented

2026-02-27 08:17:00 +03:00

Author

Owner

@traverseda commented on GitHub (Jan 3, 2025):

I saw it, but I presumed it was specific to kubernetes. Does this run in a regular docker container? Not really seeing it documented at all.

If you're asking me to exec into the docker container and run that script separately, it doesn't really fill the need of a one-click installer for more complicated lldap provisions. It looks like you expect that to be run separately using a helm chart, or Argo CD, or some other solution.

Kubernetes is not something I've explored and frankly it seems like a lot of work to maintain.

Is there a way to create a RO_ADMIN user in a declarative way, like you can for the default user? I could modify the entrypoint to first call bootstrap.sh I suppose. The whole thing just seems very undocumented.

@traverseda commented on GitHub (Jan 3, 2025): I saw it, but I presumed it was specific to kubernetes. Does this run in a regular docker container? Not really seeing it documented at all. If you're asking me to exec into the docker container and run that script separately, it doesn't really fill the need of a one-click installer for more complicated lldap provisions. It looks like you expect that to be run separately using a helm chart, or Argo CD, or some other solution. Kubernetes is not something I've explored and frankly it seems like a lot of work to maintain. Is there a way to create a RO_ADMIN user in a declarative way, like you can for the default user? I could modify the entrypoint to first call bootstrap.sh I suppose. The whole thing just seems very undocumented.

kerem commented

2026-02-27 08:17:00 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 3, 2025):

It's not specific to Kubernetes or anything: it just connects to a running LLDAP instance and sends some commands to reflect the declared, desired state. You can use environment variables to configure it, and pass the expected users and groups as json in a folder.

As such, you can use it with docker: bring up your container, then run the script to "sync" the state.

It's not "packaged" in a one-click install, no, but that'd be trivial to do: if you want to do it with docker, you can start LLDAP with an overridden entrypoint with your own script.

You also don't have to rely on the full bootstrap.sh (since it'll delete the users that are not listed). You can send simple commands to check if the read-only user already exists, and create it if it doesn't. Check out docs/scripting.md and/or lldap-cli.

@nitnelave commented on GitHub (Jan 3, 2025): It's not specific to Kubernetes or anything: it just connects to a running LLDAP instance and sends some commands to reflect the declared, desired state. You can use environment variables to configure it, and pass the expected users and groups as json in a folder. As such, you can use it with docker: bring up your container, then run the script to "sync" the state. It's not "packaged" in a one-click install, no, but that'd be trivial to do: if you want to do it with docker, you can start LLDAP with an overridden entrypoint with your own script. You also don't have to rely on the full bootstrap.sh (since it'll delete the users that are not listed). You can send simple commands to check if the read-only user already exists, and create it if it doesn't. Check out docs/scripting.md and/or lldap-cli.

kerem commented

2026-02-27 08:17:00 +03:00

Author

Owner

@traverseda commented on GitHub (Jan 3, 2025):

Alright, documentation for the bootstrap script is here: https://github.com/lldap/lldap/blob/main/example_configs/bootstrap/bootstrap.md

I'm finding this to be really confusing compared to the rest of LLDAP's design.

The main advantage of lldap over something like fusiondirectory is that it is more approachable for smaller teams, self-hosting, etc.

I have some suggestions.

Config should be done using 12factor: https://12factor.net/config . The current way of using environment variables is a great example of this.
The script isn't called by default. If for some architectural reason you want to make this kind of default schema a separate script, it needs to be run by default in the container.
While it is largely configurable through ENV vars, the actual data needs to be stored separately. Considering you've got such an excellent system for mapping env vars to TOML, I just don't understand why you have a whole separate mechanism for ensuring system accounts exist. Is that the intended use, ensuring system accounts exist?
If you are going to use files for it, why aren't they globbed? Config files like this might be better for enterprise where different groups could "own" different parts of the config, but only if they can separate it out into multiple files?

Just saw your post about it removing users that aren't listed, and I found myself more confused by the intent behind this particular script. It is very much not declarative, and will behave in an unexpected way if run more than once, deleting all third-party users.

Maybe give that feature and script a second thought?

@traverseda commented on GitHub (Jan 3, 2025): Alright, documentation for the bootstrap script is here: https://github.com/lldap/lldap/blob/main/example_configs/bootstrap/bootstrap.md I'm finding this to be really confusing compared to the rest of LLDAP's design. The main advantage of lldap over something like fusiondirectory is that it is more approachable for smaller teams, self-hosting, etc. I have some suggestions. - Config should be done using 12factor: https://12factor.net/config . The current way of using environment variables is a great example of this. - The script isn't called by default. If for some architectural reason you want to make this kind of default schema a separate script, it needs to be run by default in the container. - While it is largely configurable through ENV vars, the actual data needs to be stored separately. Considering you've got such an excellent system for mapping env vars to TOML, I just don't understand why you have a whole separate mechanism for ensuring system accounts exist. Is that the intended use, ensuring system accounts exist? - If you are going to use files for it, why aren't they globbed? Config files like this might be better for enterprise where different groups could "own" different parts of the config, but only if they can separate it out into multiple files? Just saw your post about it removing users that aren't listed, and I found myself more confused by the intent behind this particular script. It is very much not declarative, and will behave in an unexpected way if run more than once, deleting all third-party users. Maybe give that feature and script a second thought?

kerem commented

2026-02-27 08:17:00 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 3, 2025):

Maybe something that should be made clearer in the documentation is that bootstrap.sh is a community-driven, community-developed script. I had no part in the design, in part because I am pretty far away from the intended user (I have never used kube and have simpler needs for my LDAP setup). That said, many people have found it useful as is, to manage users in a declarative fashion, with or without deleting the third-party users (which I now realize can be controlled with the DO_CLEANUP variable). It allows them to have a git repository with the JSON files and commit new users/groups.

What is interesting to note is that it is entirely developed using LLDAP's existing API: nothing new was implemented to support it. In general, specific setups can be scripted on top of the existing API, and I don't plan on making LLDAP more complex to support custom setups (like, for instance, a default read-only user).

As such, if you don't like bootstrap.sh (and it seems that it doesn't fit your needs), it should be easy to create a script to do what you need.

@nitnelave commented on GitHub (Jan 3, 2025): Maybe something that should be made clearer in the documentation is that bootstrap.sh is a community-driven, community-developed script. I had no part in the design, in part because I am pretty far away from the intended user (I have never used kube and have simpler needs for my LDAP setup). That said, many people have found it useful as is, to manage users in a declarative fashion, with or without deleting the third-party users (which I now realize can be controlled with the DO_CLEANUP variable). It allows them to have a git repository with the JSON files and commit new users/groups. What is interesting to note is that it is entirely developed using LLDAP's existing API: nothing new was implemented to support it. In general, specific setups can be scripted on top of the existing API, and I don't plan on making LLDAP more complex to support custom setups (like, for instance, a default read-only user). As such, if you don't like bootstrap.sh (and it seems that it doesn't fit your needs), it should be easy to create a script to do what you need.

kerem commented

2026-02-27 08:17:00 +03:00

Author

Owner

@traverseda commented on GitHub (Jan 3, 2025):

is that bootstrap.sh is a community-driven, community-developed script. I had no part in the design

Ahh, that makes sense. I was pretty confused by the completely different way of architecting it. It was not designed in a way that I think makes sense for this project.

You'd accept PR's for a better script, including the possibility of including it in the entry-point?

I'm not sure what would make the most sense for mapping environment variables to schemas. Maybe something like this?

EXTRA_USER_PASSWORD_ro_admin=password
EXTRA_USER_GROUPS_ro_admin="biz,baz,buzz"

Seeing as it would be a community script and not part of LLDAP directly, I think it makes sense to not prepend LLDAP to the variable names?

Let me know if you're be interested in this and I can see about putting something together. I would want it to be either enabled by default or enabled through a flag though.

@traverseda commented on GitHub (Jan 3, 2025): > is that bootstrap.sh is a community-driven, community-developed script. I had no part in the design Ahh, that makes sense. I was pretty confused by the completely different way of architecting it. It was not designed in a way that I think makes sense for this project. You'd accept PR's for a better script, including the possibility of including it in the entry-point? I'm not sure what would make the most sense for mapping environment variables to schemas. Maybe something like this? ```bash EXTRA_USER_PASSWORD_ro_admin=password EXTRA_USER_GROUPS_ro_admin="biz,baz,buzz" ``` Seeing as it would be a community script and not part of LLDAP directly, I think it makes sense to not prepend LLDAP to the variable names? Let me know if you're be interested in this and I can see about putting something together. I would want it to be either enabled by default or enabled through a flag though.

kerem commented

2026-02-27 08:17:00 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 3, 2025):

I would accept PRs for a new script, that does things differently. Quite a few people are already relying on this script and its interface, I wouldn't want to change it without need.

I don't think it should be enabled by default or through an environment variable. I'd like to keep things simple. However, it should be simple to opt in: we can make it part of the image (like bootstrap.sh) and then you would just have to override the entrypoint.

As for the environment variables, I think it's okay to use the LLDAP_ prefix; but if you want, feel free to use a different prefix (LLDAP_BOOTSTRAP for instance, or however you want to call your script).

@nitnelave commented on GitHub (Jan 3, 2025): I would accept PRs for a _new_ script, that does things differently. Quite a few people are already relying on this script and its interface, I wouldn't want to change it without need. I don't think it should be enabled by default or through an environment variable. I'd like to keep things simple. However, it should be simple to opt in: we can make it part of the image (like bootstrap.sh) and then you would just have to override the entrypoint. As for the environment variables, I think it's okay to use the LLDAP_ prefix; but if you want, feel free to use a different prefix (LLDAP_BOOTSTRAP for instance, or however you want to call your script).

kerem referenced this issue

2026-02-27 09:09:28 +03:00

[PR #385] [MERGED] server: fix user password setting #712

Rows
Columns

[GH-ISSUE #1069] [FEATURE REQUEST] Configure RO_ADMIN using env vars like you configure the default user #385