Is it possible to reference an environment variable in olcSyncrepl: {0}rid= ?
--On Saturday, August 10, 2019 6:54 PM +0200 Michael Ströder michael@stroeder.com wrote:
Are you talking about the serverID?
serverID is not needed on a read-only consumer. Just leave it out.
He's talking about replication ID (rid), and it's clearly out of bounds in his post. The slapd.conf/slapd-config man pages clearly document the allowed range that can be used for a RID.
rid identifies the current syncrepl directive within the replication consumer site. It is a non-negative integer not greater than 999 (limited to three decimal digits
--Quanah
--
Il ven 16 ago 2019, 12:20 Michael Ströder michael@stroeder.com ha scritto:
On 8/16/19 12:02 PM, Marc Roos wrote:
Is it possible to reference an environment variable in olcSyncrepl: {0}rid= ?
No.
My recommendation is to use a decent config managment (ansible, chef, puppet, salt, ..) for the job.
I agree, I made this ansible playbook with also a delta-syncrepl configuration (see readme.delta-syncrepl.md)
https://github.com/peppelinux/ansible-slapd-eduperson2016
If someone want to contribute or change, suggest, share something, I'll accept contributions and ideas.
Cheers
Michael Ströder wrote:
On 8/16/19 12:02 PM, Marc Roos wrote:
Is it possible to reference an environment variable in olcSyncrepl: {0}rid= ?
No.
The example doesn't even make sense. RIDs are supposed to be unique within a single config, there's no reason for them to have any global context such as an env var would imply.
My recommendation is to use a decent config managment (ansible, chef, puppet, salt, ..) for the job.
If you have a container image, and you spawn from that multiple instances, you have to be able to 'easily' change unique qualifiers, not?
-----Original Message----- Subject: Re: Environment variable in slapd config
Michael Ströder wrote:
On 8/16/19 12:02 PM, Marc Roos wrote:
Is it possible to reference an environment variable in olcSyncrepl: {0}rid= ?
No.
The example doesn't even make sense. RIDs are supposed to be unique within a single config, there's no reason for them to have any global context such as an env var would imply.
My recommendation is to use a decent config managment (ansible, chef, puppet, salt, ..) for the job.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Marc Roos wrote:
If you have a container image, and you spawn from that multiple instances, you have to be able to 'easily' change unique qualifiers, not?
What part of "RIDs are supposed to be unique within a single config" did you not understand?
If you run multiple instances, each one has its own config. It doesn't matter if you use the same RID in multiple configs.
-----Original Message----- Subject: Re: Environment variable in slapd config
Michael Ströder wrote:
On 8/16/19 12:02 PM, Marc Roos wrote:
Is it possible to reference an environment variable in olcSyncrepl: {0}rid= ?
No.
The example doesn't even make sense. RIDs are supposed to be unique within a single config, there's no reason for them to have any global context such as an env var would imply.
My recommendation is to use a decent config managment (ansible, chef, puppet, salt, ..) for the job.
Yes and an environment variable is easy to set on task launch to a 'unique' value or can be parsed from the marathon gui eg.
-----Original Message----- Subject: Re: Environment variable in slapd config
If you have a container image, and you spawn from that multiple instances, you have to be able to 'easily' change unique qualifiers, not?
What part of "RIDs are supposed to be unique within a single config" did you not understand?
If you run multiple instances, each one has its own config. It doesn't matter if you use the same RID in multiple configs.
-----Original Message----- Subject: Re: Environment variable in slapd config
Michael Ströder wrote:
On 8/16/19 12:02 PM, Marc Roos wrote:
Is it possible to reference an environment variable in olcSyncrepl: {0}rid= ?
No.
The example doesn't even make sense. RIDs are supposed to be unique within a single config, there's no reason for them to have any global context such as an env var would imply.
My recommendation is to use a decent config managment (ansible, chef,
puppet, salt, ..) for the job.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 8/16/19 2:54 PM, Howard Chu wrote:
Michael Ströder wrote:
On 8/16/19 12:02 PM, Marc Roos wrote:
Is it possible to reference an environment variable in olcSyncrepl: {0}rid= ?
No.
The example doesn't even make sense. RIDs are supposed to be unique within a single config, there's no reason for them to have any global context such as an env var would imply.
Probably the original poster wanted to set several env vars and use them as distinct RID values for multiple syncrepl directives. This is a common pattern for poor man's config management.
Ciao, Michael.
Indeed. Ansible is just a tool you should use for the fitting job. Afaik I only have to set a few variables and I do not have in the hundreds of services. But I would not mind looking at your Dockerfile to see how you prepare the image.
The ceph mailing list is 'full' of people using ansible, and then whining on what to do, and how to fix things when something does not work. Because they do not know how and where things are configured. All these 'easy' tools are like these higher level programming languages. They just lower the threshold for the 'bunglers' to enter an area of expertise, they were not able to enter before.
-----Original Message----- Subject: Re: Environment variable in slapd config
Probably the original poster wanted to set several env vars and use them as distinct RID values for multiple syncrepl directives. This is a common pattern for poor man's config management.
Ciao, Michael.
Marc Roos wrote:
Indeed. Ansible is just a tool you should use for the fitting job. Afaik I only have to set a few variables and I do not have in the hundreds of services. But I would not mind looking at your Dockerfile to see how you prepare the image.
The ceph mailing list is 'full' of people using ansible, and then whining on what to do, and how to fix things when something does not work. Because they do not know how and where things are configured. All these 'easy' tools are like these higher level programming languages. They just lower the threshold for the 'bunglers' to enter an area of expertise, they were not able to enter before.
-----Original Message----- Subject: Re: Environment variable in slapd config
Probably the original poster wanted to set several env vars and use them as distinct RID values for multiple syncrepl directives. This is a common pattern for poor man's config management.
Ciao, Michael.
For this use case the simplest approach is to start with a template file that uses shell variables and just let the shell do the substitution for you. This is exactly what the OpenLDAP test suite does for its own config files.
If you need to get fancier use sed or awk. These are basic Unix admin questions and have nothing to do with OpenLDAP.
Thanks Howard, I am already doing this for the default configuration. I was hoping I could get around fetching secrets and importing changes at run time.
-----Original Message----- Subject: Re: Environment variable in slapd config
Marc Roos wrote:
Indeed. Ansible is just a tool you should use for the fitting job. Afaik I only have to set a few variables and I do not have in the hundreds of services. But I would not mind looking at your Dockerfile to see how you prepare the image.
The ceph mailing list is 'full' of people using ansible, and then whining on what to do, and how to fix things when something does not work. Because they do not know how and where things are configured. All these 'easy' tools are like these higher level programming languages. They just lower the threshold for the 'bunglers' to enter an area of expertise, they were not able to enter before.
-----Original Message----- Subject: Re: Environment variable in slapd config
Probably the original poster wanted to set several env vars and use them as distinct RID values for multiple syncrepl directives. This is a common pattern for poor man's config management.
Ciao, Michael.
For this use case the simplest approach is to start with a template file that uses shell variables and just let the shell do the substitution for you. This is exactly what the OpenLDAP test suite does for its own config files.
If you need to get fancier use sed or awk. These are basic Unix admin questions and have nothing to do with OpenLDAP.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
I have been working on a docker image with a script that likely does almost what you want with some mods, you’re welcome to steal it and make your own modifications. https://github.com/DoctorOgg/docker-openldap https://github.com/DoctorOgg/docker-openldap
On Aug 16, 2019, at 6:36 AM, Howard Chu hyc@symas.com wrote:
Marc Roos wrote:
Indeed. Ansible is just a tool you should use for the fitting job. Afaik I only have to set a few variables and I do not have in the hundreds of services. But I would not mind looking at your Dockerfile to see how you prepare the image.
The ceph mailing list is 'full' of people using ansible, and then whining on what to do, and how to fix things when something does not work. Because they do not know how and where things are configured. All these 'easy' tools are like these higher level programming languages. They just lower the threshold for the 'bunglers' to enter an area of expertise, they were not able to enter before.
-----Original Message----- Subject: Re: Environment variable in slapd config
Probably the original poster wanted to set several env vars and use them as distinct RID values for multiple syncrepl directives. This is a common pattern for poor man's config management.
Ciao, Michael.
For this use case the simplest approach is to start with a template file that uses shell variables and just let the shell do the substitution for you. This is exactly what the OpenLDAP test suite does for its own config files.
If you need to get fancier use sed or awk. These are basic Unix admin questions and have nothing to do with OpenLDAP.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Cool thanks! I am more fan of Centos because then I can fall back on RedHat support, especially for production environments. I am not sure your script is takling the issue described here, but looking at it, I think you can add also --no-cache. You should beware of ENV LDAP_ROOTPASS that stays when the task is launched (at least on mesos), better work with the hashes. Furthermore I try to run as less tasks as possible under root so I am binding to a high port ;) I also need to be able to use slapadd otherwise syncing will take to long.
So at the moment mine looks like this ;)
# Version: 0.0.1 - openldap FROM centos:7
ENV SLAPD_USER="ldap" \ SLAPD_UID=10061 \ SLAPD_CFG_DIR="/etc/openldap/" \ SLAPD_DATA_DIR="/var/lib/ldap" \ SLAPD_KEY_DIR="/etc/pki/tls/private" \ SLAPD_CRT_DIR="/etc/pki/tls/certs" \ SLAPD_OPTS="-d 0 -4 -u ldap" \ SLAPD_URLS="ldap://0.0.0.0:8443/"
# create user/group RUN groupadd $SLAPD_USER -g $SLAPD_UID \ && useradd $SLAPD_USER -u $SLAPD_UID -g $SLAPD_UID --system --comment "Openldap server" --home-dir $SLAPD_DATA_DIR
# install xxxx-ca COPY ca-xxxx.crt /etc/pki/ca-trust/source/anchors/ca-xxxx.crt RUN update-ca-trust
# install necessary packages RUN yum install openldap-clients openldap-servers -y \ && yum clean all
# copy configuration files COPY ca-xxxx.crt $SLAPD_CFG_DIR/cacerts/ COPY ldap.local.key $SLAPD_KEY_DIR COPY ldap.local.crt $SLAPD_CRT_DIR ADD http://192.168.10.2/cobbler/tools/noarch/change-db.ldif $SLAPD_CFG_DIR/change-db.ldif ADD http://192.168.10.2/cobbler/tools/noarch/centos7/change-config.ldif $SLAPD_CFG_DIR/change-config.ldif ADD http://192.168.10.2/cobbler/tools/noarch/change-config-sendmail.ldif $SLAPD_CFG_DIR/change-config-sendmail.ldif ADD http://192.168.10.2/cobbler/tools/noarch/change-frontend.ldif $SLAPD_CFG_DIR/change-frontend.ldif ADD http://192.168.10.2/cobbler/tools/noarch/idnsZone.ldif $SLAPD_CFG_DIR/schema/idnsZone.ldif ADD http://192.168.10.2/cobbler/tools/noarch/sendmail.ldif $SLAPD_CFG_DIR/schema/sendmail.ldif ADD http://192.168.10.2/cobbler/tools/noarch/samba.ldif $SLAPD_CFG_DIR/schema/samba.ldif ADD http://192.168.10.2/cobbler/tools/noarch/apache.ldif $SLAPD_CFG_DIR/schema/apache.ldif ADD http://192.168.10.2/cobbler/tools/noarch/quota.ldif $SLAPD_CFG_DIR/schema/quota.ldif ADD http://192.168.10.2/cobbler/tools/noarch/xxxx.ldif $SLAPD_CFG_DIR/schema/xxxx.ldif ADD http://192.168.10.2/cobbler/tools/noarch/DB_CONFIG $SLAPD_DATA_DIR/DB_CONFIG COPY ldap-test.db.gz /tmp/ldap.db.gz
# change defaults in configs RUN sed -i "s#^olcTLSCertificateFile:.*#olcTLSCertificateFile: $SLAPD_CRT_DIR/ldap.local.crt#g" $SLAPD_CFG_DIR/change-config.ldif \ && sed -i "s#^olcTLSCertificateKeyFile:.*#olcTLSCertificateKeyFile: $SLAPD_KEY_DIR/ldap.local.key#g" $SLAPD_CFG_DIR/change-config.ldif \ && sed -i "s#^olcRootPW:.*#olcRootPW: {SSHA}xxx#g" $SLAPD_CFG_DIR/change-config.ldif
RUN sed -i "s#rid=326#rid=999#g" $SLAPD_CFG_DIR/change-db.ldif \ && sed -i 's/cn=app,ou=Hosts,dc=xxxx,dc=xxxx,dc=local/cn=mesosldap,ou=Hosts,dc=xxx x,dc=xxxx,dc=local/g' $SLAPD_CFG_DIR/change-db.ldif \ && sed -i "s#tls_cert="/etc/pki/tls/certs/app1.local.pem"#tls_cert="$SLAPD_CRT_ DIR/ldap.local.crt"#g" $SLAPD_CFG_DIR/change-db.ldif \ && sed -i "s#tls_key="/etc/pki/tls/certs/app1.local.pem"#tls_key="$SLAPD_KEY_DI R/ldap.local.key"#g" $SLAPD_CFG_DIR/change-db.ldif \ && sed -i "s/credentials="xxxx"/credentials="xxxx"/g" $SLAPD_CFG_DIR/change-db.ldif
# change permissions RUN chgrp $SLAPD_USER $SLAPD_KEY_DIR/ldap.local.key $SLAPD_CRT_DIR/ldap.local.crt \ && chmod u=r,g=r,o= $SLAPD_KEY_DIR/ldap.local.key \ && chmod a+r $SLAPD_DATA_DIR/DB_CONFIG \ && chmod +t,o+w /var/run/ RUN [ -f "/tmp/ldap.db.gz" ] && chown $SLAPD_USER /tmp/ldap.db.gz || echo "not-chown-db"
RUN slapd -u ldap -4 -h ldapi:/// \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/cosine.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/inetorgperson.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/nis.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/misc.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/sendmail.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/idnsZone.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/apache.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/samba.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/xxxx.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/quota.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-frontend.ldif \ && rm -f $SLAPD_CFG_DIR/change-frontend.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-db.ldif \ && rm -f $SLAPD_CFG_DIR/change-db.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-config-sendmail.ldif \
&& ldapadd -Q -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-config.ldif \ && rm -f $SLAPD_CFG_DIR/change-config.ldif \ && kill -HUP $(cat /var/run/openldap/slapd.pid) \ && sync \ && chown $SLAPD_USER /var/run/ldapi
#ADD db.tgz /var/lib/ldap/ RUN [ -f "/tmp/ldap.db.gz" ] \ && runuser -l ldap -c 'gunzip -c /tmp/ldap.db.gz | slapadd -c 2> /tmp/import-errors' \ && cd /var/lib/ldap && db_checkpoint -1 -h /var/lib/ldap && db_archive -d \ && rm -f /tmp/ldap.db.gz || echo "not importing ldap.db"
COPY entrypoint.sh /sbin/
CMD ["/sbin/entrypoint.sh"]
-----Original Message----- From: Neal Lawson [mailto:ogg@sr375.com] Sent: vrijdag 16 augustus 2019 15:41 To: Howard Chu Cc: Marc Roos; michael; openldap-technical@openldap.org Subject: Re: Environment variable in slapd config
I have been working on a docker image with a script that likely does almost what you want with some mods, you’re welcome to steal it and make your own modifications. https://github.com/DoctorOgg/docker-openldap
On Aug 16, 2019, at 6:36 AM, Howard Chu hyc@symas.com wrote:
Marc Roos wrote:
Indeed. Ansible is just a tool you should use for the fitting job. Afaik I only have to set a few variables and I do not have in the hundreds of services. But I would not mind looking at your Dockerfile to see how you prepare the image. The ceph mailing list is 'full' of people using ansible, and then whining on what to do, and how to fix things when something does not work. Because they do not know how and where things are configured. All these 'easy' tools are like these higher level programming
languages. They just lower the threshold for the 'bunglers' to enter an area of expertise, they were not able to enter before. -----Original Message----- Subject: Re: Environment variable in slapd config Probably the original poster wanted to set several env vars and use them as distinct RID values for multiple syncrepl directives. This is a common pattern for poor man's config management. Ciao, Michael.
For this use case the simplest approach is to start with a template file that uses shell variables and just let the shell do the substitution for you. This is exactly what the OpenLDAP test suite does for its own config files. If you need to get fancier use sed or awk. These are basic Unix admin questions and have nothing to do with OpenLDAP. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Marc Roos wrote:
Cool thanks! I am more fan of Centos because then I can fall back on RedHat support, especially for production environments. I am not sure your script is takling the issue described here, but looking at it, I think you can add also --no-cache. You should beware of ENV LDAP_ROOTPASS that stays when the task is launched (at least on mesos), better work with the hashes. Furthermore I try to run as less tasks as possible under root so I am binding to a high port ;) I also need to be able to use slapadd otherwise syncing will take to long.
So at the moment mine looks like this ;)
# Version: 0.0.1 - openldap FROM centos:7
ENV SLAPD_USER="ldap" \ SLAPD_UID=10061 \ SLAPD_CFG_DIR="/etc/openldap/" \ SLAPD_DATA_DIR="/var/lib/ldap" \ SLAPD_KEY_DIR="/etc/pki/tls/private" \ SLAPD_CRT_DIR="/etc/pki/tls/certs" \ SLAPD_OPTS="-d 0 -4 -u ldap" \ SLAPD_URLS="ldap://0.0.0.0:8443/"
# create user/group RUN groupadd $SLAPD_USER -g $SLAPD_UID \ && useradd $SLAPD_USER -u $SLAPD_UID -g $SLAPD_UID --system --comment "Openldap server" --home-dir $SLAPD_DATA_DIR
# install xxxx-ca COPY ca-xxxx.crt /etc/pki/ca-trust/source/anchors/ca-xxxx.crt RUN update-ca-trust
# install necessary packages RUN yum install openldap-clients openldap-servers -y \ && yum clean all
# copy configuration files COPY ca-xxxx.crt $SLAPD_CFG_DIR/cacerts/ COPY ldap.local.key $SLAPD_KEY_DIR COPY ldap.local.crt $SLAPD_CRT_DIR ADD http://192.168.10.2/cobbler/tools/noarch/change-db.ldif $SLAPD_CFG_DIR/change-db.ldif ADD http://192.168.10.2/cobbler/tools/noarch/centos7/change-config.ldif $SLAPD_CFG_DIR/change-config.ldif ADD http://192.168.10.2/cobbler/tools/noarch/change-config-sendmail.ldif $SLAPD_CFG_DIR/change-config-sendmail.ldif ADD http://192.168.10.2/cobbler/tools/noarch/change-frontend.ldif $SLAPD_CFG_DIR/change-frontend.ldif ADD http://192.168.10.2/cobbler/tools/noarch/idnsZone.ldif $SLAPD_CFG_DIR/schema/idnsZone.ldif ADD http://192.168.10.2/cobbler/tools/noarch/sendmail.ldif $SLAPD_CFG_DIR/schema/sendmail.ldif ADD http://192.168.10.2/cobbler/tools/noarch/samba.ldif $SLAPD_CFG_DIR/schema/samba.ldif ADD http://192.168.10.2/cobbler/tools/noarch/apache.ldif $SLAPD_CFG_DIR/schema/apache.ldif ADD http://192.168.10.2/cobbler/tools/noarch/quota.ldif $SLAPD_CFG_DIR/schema/quota.ldif ADD http://192.168.10.2/cobbler/tools/noarch/xxxx.ldif $SLAPD_CFG_DIR/schema/xxxx.ldif ADD http://192.168.10.2/cobbler/tools/noarch/DB_CONFIG $SLAPD_DATA_DIR/DB_CONFIG COPY ldap-test.db.gz /tmp/ldap.db.gz
# change defaults in configs RUN sed -i "s#^olcTLSCertificateFile:.*#olcTLSCertificateFile: $SLAPD_CRT_DIR/ldap.local.crt#g" $SLAPD_CFG_DIR/change-config.ldif \ && sed -i "s#^olcTLSCertificateKeyFile:.*#olcTLSCertificateKeyFile: $SLAPD_KEY_DIR/ldap.local.key#g" $SLAPD_CFG_DIR/change-config.ldif \ && sed -i "s#^olcRootPW:.*#olcRootPW: {SSHA}xxx#g" $SLAPD_CFG_DIR/change-config.ldif
You're just replacing once constant with another here, why not just set it correctly once, in the source file?
Why use a rootpw at all?
RUN sed -i "s#rid=326#rid=999#g" $SLAPD_CFG_DIR/change-db.ldif \ && sed -i 's/cn=app,ou=Hosts,dc=xxxx,dc=xxxx,dc=local/cn=mesosldap,ou=Hosts,dc=xxx x,dc=xxxx,dc=local/g' $SLAPD_CFG_DIR/change-db.ldif \ && sed -i "s#tls_cert="/etc/pki/tls/certs/app1.local.pem"#tls_cert="$SLAPD_CRT_ DIR/ldap.local.crt"#g" $SLAPD_CFG_DIR/change-db.ldif \ && sed -i "s#tls_key="/etc/pki/tls/certs/app1.local.pem"#tls_key="$SLAPD_KEY_DI R/ldap.local.key"#g" $SLAPD_CFG_DIR/change-db.ldif \ && sed -i "s/credentials="xxxx"/credentials="xxxx"/g" $SLAPD_CFG_DIR/change-db.ldif
Again, why not just set this once, in the source file?
# change permissions RUN chgrp $SLAPD_USER $SLAPD_KEY_DIR/ldap.local.key $SLAPD_CRT_DIR/ldap.local.crt \ && chmod u=r,g=r,o= $SLAPD_KEY_DIR/ldap.local.key \ && chmod a+r $SLAPD_DATA_DIR/DB_CONFIG \ && chmod +t,o+w /var/run/ RUN [ -f "/tmp/ldap.db.gz" ] && chown $SLAPD_USER /tmp/ldap.db.gz || echo "not-chown-db"
Why aren't you using slapadd to initialize the config?
RUN slapd -u ldap -4 -h ldapi:/// \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/cosine.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/inetorgperson.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/nis.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/misc.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f$SLAPD_CFG_DIR/schema/sendmail.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/idnsZone.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/apache.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/samba.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/xxxx.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/schema/quota.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f$SLAPD_CFG_DIR/change-frontend.ldif \ && rm -f $SLAPD_CFG_DIR/change-frontend.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-db.ldif \ && rm -f $SLAPD_CFG_DIR/change-db.ldif \ && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-config-sendmail.ldif \
&& ldapadd -Q -Y EXTERNAL -H ldapi:/// -f$SLAPD_CFG_DIR/change-config.ldif \ && rm -f $SLAPD_CFG_DIR/change-config.ldif \ && kill -HUP $(cat /var/run/openldap/slapd.pid) \ && sync \ && chown $SLAPD_USER /var/run/ldapi
#ADD db.tgz /var/lib/ldap/ RUN [ -f "/tmp/ldap.db.gz" ] \ && runuser -l ldap -c 'gunzip -c /tmp/ldap.db.gz | slapadd -c 2> /tmp/import-errors' \ && cd /var/lib/ldap && db_checkpoint -1 -h /var/lib/ldap && db_archive -d \ && rm -f /tmp/ldap.db.gz || echo "not importing ldap.db"
COPY entrypoint.sh /sbin/
CMD ["/sbin/entrypoint.sh"]
-----Original Message----- From: Neal Lawson [mailto:ogg@sr375.com] Sent: vrijdag 16 augustus 2019 15:41 To: Howard Chu Cc: Marc Roos; michael; openldap-technical@openldap.org Subject: Re: Environment variable in slapd config
I have been working on a docker image with a script that likely does almost what you want with some mods, you’re welcome to steal it and make your own modifications. https://github.com/DoctorOgg/docker-openldap
On Aug 16, 2019, at 6:36 AM, Howard Chu hyc@symas.com wrote:
Marc Roos wrote:
Indeed. Ansible is just a tool you should use for the fittingjob. Afaik I only have to set a few variables and I do not have in the hundreds of services. But I would not mind looking at your Dockerfile to see how you prepare the image. The ceph mailing list is 'full' of people using ansible, and then whining on what to do, and how to fix things when something does not work. Because they do not know how and where things are configured. All these 'easy' tools are like these higher level programming
languages. They just lower the threshold for the 'bunglers' toenter an area of expertise, they were not able to enter before. -----Original Message----- Subject: Re: Environment variable in slapd config Probably the original poster wanted to set several env vars and use them as distinct RID values for multiple syncrepl directives. This is a common pattern for poor man's config management. Ciao, Michael.
For this use case the simplest approach is to start with a template file that uses shell variables and just let the shell do the substitution for you. This is exactly what the OpenLDAP test suite does for its own config files.
If you need to get fancier use sed or awk. These are basic Unix admin questions and have nothing to do with OpenLDAP.
You're just replacing once constant with another here, why not just
set it correctly once, in the source file?
Because the destination field is not always the same, it is different for different vm groups.
Why use a rootpw at all?
I though I cannot get around using this when changing the log level or acls during runtime for instance?
Why aren't you using slapadd to initialize the config?
No specific reason.
Cool thanks! I am more fan of Centos because then I can fall back on RedHat support, especially for production environments. I am not sure
your script is takling the issue described here, but looking at it, I
think you can add also --no-cache. You should beware of ENV LDAP_ROOTPASS that stays when the task is launched (at least on mesos), better work with the hashes. Furthermore I try to run as less
tasks as possible under root so I am binding to a high port ;) I also
need to be able to use slapadd otherwise syncing will take to long.
So at the moment mine looks like this ;)
# Version: 0.0.1 - openldap FROM centos:7
ENV SLAPD_USER="ldap" \ SLAPD_UID=10061 \ SLAPD_CFG_DIR="/etc/openldap/" \ SLAPD_DATA_DIR="/var/lib/ldap" \ SLAPD_KEY_DIR="/etc/pki/tls/private" \ SLAPD_CRT_DIR="/etc/pki/tls/certs" \ SLAPD_OPTS="-d 0 -4 -u ldap" \ SLAPD_URLS="ldap://0.0.0.0:8443/"
# create user/group RUN groupadd $SLAPD_USER -g $SLAPD_UID \
&& useradd $SLAPD_USER -u $SLAPD_UID -g $SLAPD_UID --system
--On Friday, August 16, 2019 6:10 PM +0200 Marc Roos M.Roos@f1-outsourcing.eu wrote:
Why use a rootpw at all?
I though I cannot get around using this when changing the log level or acls during runtime for instance?
You can't get around having a way to write to cn=config. RedHat/CentOS and Debian and Ubuntu all provide ways to do this via connecting with the SASL/EXTERNAL mechanism over the ldapi:/// socket as the root user as a part of their default configuration for cn=config.
I.e.,
[root@c7 ~]# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config 1.1 dn: cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}inetorgperson,cn=schema,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}monitor,cn=config
dn: olcDatabase={2}hdb,cn=config
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Friday, August 16, 2019 5:17 PM +0200 Marc Roos M.Roos@f1-outsourcing.eu wrote:
I am more fan of Centos because then I can fall back on RedHat support, especially for production environments.
That's the most laughable statement (in relation to OpenLDAP at least) that I've heard in years. Thanks for the morning chuckle.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Giuseppe De Marco -
Howard Chu -
Marc Roos -
Michael Ströder -
Neal Lawson -
Quanah Gibson-Mount