You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The dscontainer currently signals that the container is healthy (via the dscontainer -H healthcheck) before the Directory Manager password is actually set. For users/consumers of dscontainer the healthcheck is generally the signal that the container is ready and that configuration can commence (including configuration using the Directory Manager account). The workaround at the moment is for users/consumers to issue a sleep command and hope to order the setup commands after the Directory Manager account password is set to the provided environment variable value, else resort to local-only ldapi setup commands in a root run container.
Describe the solution you'd like
One solution would be to update the healthcheck such that it monitors an additional condition: that it is only "healthy" once the existing check says so and a marker file has been set indicating that core initialization is complete (including Directory Manager password handling).
Describe alternatives you've considered
One alternative is to only set the password the first time the server is initialized. This makes the container much less useful as it's often desirable to initialize the container and run setup ahead of time during a container build phase, yet this would "hard-code" the password. The option to dynamically set it at runtime via environment variable is desirable.
There is some otherwise non-specific initialization that can be run during the docker build except for the Directory Manager password. It has been suggested that it is possible to set the Directory Manager password in such a way as to make it unusable for clients to bind with, yet satisfies the initialization requirement. This could be ideal. Otherwise, setting a fixed one hard-coded into the pre-built image could be justified if either strong warnings are given OR a check such that a dynamic password to override is no longer optional, but required else the server won't start.
Bug Description:
The dscontainer currently signals that the container is healthy (via the dscontainer -H healthcheck) before the Directory Manager password is actually set.
Fix Description:
The startup code now sets a marker file once the runtime supplied password is set and the command line invoked healthcheck returns healthy only if the existing checks pass and the marker file exists
Fixes389ds#6069
Replacing the existing random password code with code that uses a fixed password, but one that can't be used to bind with may be a separate issue? Also worth mentioning that there is the container concept of secrets that may be preferrable to environment variables when available. Unfortunately they appear to be runtime specific such as Docker Compose Secrets
slominskir
added a commit
to slominskir/389-ds-base
that referenced
this issue
Feb 6, 2024
Bug Description:
The dscontainer currently signals that the container is healthy (via the dscontainer -H healthcheck) before the Directory Manager password is actually set.
Fix Description:
The startup code now sets a marker file once the runtime supplied password is set and the command line invoked healthcheck returns healthy only if the existing checks pass and the marker file exists
Fixes389ds#6069
Is your feature request related to a problem? Please describe.
The dscontainer currently signals that the container is healthy (via the
dscontainer -H
healthcheck) before the Directory Manager password is actually set. For users/consumers of dscontainer the healthcheck is generally the signal that the container is ready and that configuration can commence (including configuration using the Directory Manager account). The workaround at the moment is for users/consumers to issue a sleep command and hope to order the setup commands after the Directory Manager account password is set to the provided environment variable value, else resort to local-only ldapi setup commands in a root run container.Describe the solution you'd like
One solution would be to update the healthcheck such that it monitors an additional condition: that it is only "healthy" once the existing check says so and a marker file has been set indicating that core initialization is complete (including Directory Manager password handling).
Describe alternatives you've considered
One alternative is to only set the password the first time the server is initialized. This makes the container much less useful as it's often desirable to initialize the container and run setup ahead of time during a container build phase, yet this would "hard-code" the password. The option to dynamically set it at runtime via environment variable is desirable.
There is some otherwise non-specific initialization that can be run during the docker build except for the Directory Manager password. It has been suggested that it is possible to set the Directory Manager password in such a way as to make it unusable for clients to bind with, yet satisfies the initialization requirement. This could be ideal. Otherwise, setting a fixed one hard-coded into the pre-built image could be justified if either strong warnings are given OR a check such that a dynamic password to override is no longer optional, but required else the server won't start.
Additional context
Discussed in #6058
The text was updated successfully, but these errors were encountered: