Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable openldap uid/gid to be specified at runtime #336

Merged
merged 7 commits into from
Jun 15, 2020

Conversation

lj020326
Copy link
Contributor

No description provided.

@BertrandGouny
Copy link
Member

Hello,
thanks for the PR, can you describe the problem solved by this ?

Thanks

@lj020326
Copy link
Contributor Author

lj020326 commented Aug 1, 2019 via email

@EugenMayer
Copy link

This is very usual practise - e.g. all LinuxServer/ images have this setting, and others. Usually this is ony needed when you want to use host-mounts, not named volumes, and thus need to align with the host uid/gid for other tooling or e.g. shared volume / smb / nfs permissions.

@BertrandGouny
Copy link
Member

Thanks for you feedbacks. This sounds good to me.

groupadd -g 911 -r openldap
useradd -u 911 -r -g openldap
does this can break existing configurations ?

May the user adjusments done in entrypoint.sh would fit better in startup.sh on container first start section ?

@lj020326
Copy link
Contributor Author

lj020326 commented Dec 2, 2019

Hi Bertrand,

I wasn't sure where the startup.sh was ultimately getting called from and did not want to adversely impact any of the existing code.

In order to minimize the impact, I looked for the least invasive approach which seemed to me the approach taken by the jenkins docker implementation for the related feature of defining the user/group id at startup used here: https://github.com/sudo-bmitch/jenkins-docker/blob/master/entrypoint.sh

If the startup.sh is simply getting kicked off at container start, then I imagine it should work fine with no adverse impact. I could rework the logic into the startup.sh and test for the specific configuration I am using.

I would imagine testing for all of the existing configurations would be required to make sure that is the case.

Is there test automation already setup to test PR changes to run/test each of the configurations available in order to determine if the relevant PR does not break anything? If so, and if the test automation is kicked off automatically upon submitting the PR, I can rework the logic into the startup.sh as mentioned above and push the changes through this PR. Just let me know if this approach is desired.

-Lee

@BertrandGouny
Copy link
Member

Thanks Lee,

startup.sh is called when the container start.

i guess group and user adjustments would fit great just before

# fix file permissions

tests are run via travis, but you can run them locally with make test.

Make sure to have bats installed before :
https://github.com/bats-core/bats-core

@lj020326
Copy link
Contributor Author

lj020326 commented Dec 11, 2019

Hi Bertrand,

As requested, I moved the logic from entrypoint.sh into the startup.sh and tested successfully:

administrator@admin2:~/repos/docker/docker-openldap-1$ docker container prune -f
Deleted Containers:
1afff9f0e9fd2fa8bcdbf823eaefe5b8a63159cc312393705d61374b6db5504a
db2bcd843030125852d83e12d62862c0b5aa911f85c4372c2a5a299d88be575d

Total reclaimed space: 2.589MB
administrator@admin2:~/repos/docker/docker-openldap-1$ docker volume prune -f
Total reclaimed space: 0B
administrator@admin2:~/repos/docker/docker-openldap-1$ docker rmi osixia/openldap:1.2.4
Untagged: osixia/openldap:1.2.4
Deleted: sha256:5382adc0ab451abaaf9cca27a924b818bf7453ee83ff985c405254beb4051922
Deleted: sha256:88c74a283ea9c835c95645a94d9bcb802599813568a9d4ada068cae2a7c03753
Deleted: sha256:c10c04aa1b6bb8e60413bf3aa593a2d44c56b33438eb58c2edf71061e57b527a
Deleted: sha256:512ae00d3dee67cccae921b9255c43e115085a80399e9a205c7a505b68967450
Deleted: sha256:70d8f269ebfe3e7bcbc8b04846778fa256fe5f15fde25b7c1f40759d5726200f
Deleted: sha256:4fb1cbdf6b7ccd19d27635997ce07d928fc784aa54de08de907ec1e0351bf0cc
Deleted: sha256:dfe96b03a7bd267d44822690adb3fd7945bc2664f7a4db8263ccaa9d436960a3
administrator@admin2:~/repos/docker/docker-openldap-1$
administrator@admin2:~/repos/docker/docker-openldap-1$ make test
env NAME=osixia/openldap VERSION=1.2.4 bats test/test.bats
 ✓ image build
 ✓ ldapsearch new database
 ✓ ldapsearch database from created volumes
 ✓ ldapsearch new database with strict TLS
 ✓ ldapsearch new database with strict TLS and custom ca/crt
 ✓ ldapsearch new database with strict TLS and custom ca/crt and custom dhparam
 ✓ ldapsearch existing hdb database and config
 ✓ replication with new databases and strict TLS

8 tests, 0 failures

administrator@admin2:~/repos/docker/docker-openldap-1$

@@ -10,8 +10,8 @@ ARG PQCHECKER_MD5=c005ce596e97d13e39485e711dcbc7e1

# Add openldap user and group first to make sure their IDs get assigned consistently, regardless of whatever dependencies get added
# If explicit uid or gid is given, use it.
RUN if [ -z "${LDAP_OPENLDAP_GID}" ]; then groupadd -r openldap; else groupadd -r -g ${LDAP_OPENLDAP_GID} openldap; fi \
&& if [ -z "${LDAP_OPENLDAP_UID}" ]; then useradd -r -g openldap openldap; else useradd -r -g openldap -u ${LDAP_OPENLDAP_UID} openldap; fi
RUN if [ -z "${LDAP_OPENLDAP_GID}" ]; then groupadd -g 911 -r openldap; else groupadd -r -g ${LDAP_OPENLDAP_GID} openldap; fi \
Copy link
Contributor Author

@lj020326 lj020326 Dec 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not necessary since the startup.sh will check to see if the ID matches the defined or default.
If the id did not match, the startup.sh will update the id and make the necessary chown updates.

This saves time in the case where the default is to be expected/used in the startup.sh runtime since files impacted by the chown operations should be lesser and performance enhanced.

RUN if [ -z "${LDAP_OPENLDAP_GID}" ]; then groupadd -r openldap; else groupadd -r -g ${LDAP_OPENLDAP_GID} openldap; fi \
&& if [ -z "${LDAP_OPENLDAP_UID}" ]; then useradd -r -g openldap openldap; else useradd -r -g openldap -u ${LDAP_OPENLDAP_UID} openldap; fi
RUN if [ -z "${LDAP_OPENLDAP_GID}" ]; then groupadd -g 911 -r openldap; else groupadd -r -g ${LDAP_OPENLDAP_GID} openldap; fi \
&& if [ -z "${LDAP_OPENLDAP_UID}" ]; then useradd -u 911 -r -g openldap openldap; else useradd -r -g openldap -u ${LDAP_OPENLDAP_UID} openldap; fi
Copy link
Contributor Author

@lj020326 lj020326 Dec 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not necessary since the startup.sh will check to see if the ID matches the defined or default.
If the id did not match, the startup.sh will update the id and make the necessary chown updates.

This saves time in the case where the default is to be expected/used in the startup.sh runtime since files impacted by the chown operations should be lesser and performance enhanced.

@chikamichi
Copy link

chikamichi commented Jun 2, 2020

HI! Any news on this PR? It looks promising! (missing documentation though)

@lj020326
Copy link
Contributor Author

lj020326 commented Jun 2, 2020

HI! Any news on this PR? It looks promising! (missing documentation though)

Hi - I just added a brief description for the new env vars in the environments section of the doc here:
c6844f6

@BertrandGouny
Copy link
Member

Thanks a lot !

@BertrandGouny BertrandGouny merged commit 2bd5d31 into osixia:stable Jun 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants