docker-openldap: Bugs affecting setting up LDAP replication

I’m trying to set up two containers with replication between them. The process is failing in a couple of places.

The first is in this script:

https://github.com/osixia/docker-openldap/blob/2a03b392b019adbf810f11bd64a2fed753d77b9d/image/service/slapd/startup.sh#L259-L261

This doesn’t declare ldaps:// as a protocol which causes problems if LDAP_REPLICATION_HOSTS does reference ldaps://. That is, though, fairly simple to fix in that script.

A bigger problem - and one I cannot find the answer to - is host names and domain names.

If I set hostname to be the fully-qualified name and leave domainname unset then /etc/hosts get correctly set but the environment variable HOSTNAME in the container gets changed to just the leafname. This then causes slapd to just listen to the leafname and not the fully-qualified domain name. That results in read_config: no serverID / URL match found. Check slapd -h arguments.

If I set hostname to just be the hostname and set domainname to the domain then no change is noticed - /etc/hosts is set correctly and HOSTNAME is still set to the leafname.

If I follow the comments in docker-compose.yml and set hostname and domainname to the same value then /etc/hosts is set incorrectly - the entry is a concatenation of both hostname and domainname but HOSTNAME is left alone as the fully qualified name! That results in daemon: bind(6) failed errno=99 (Cannot assign requested address).

I cannot find a way to make sure that /etc/hosts is set correctly and HOSTNAME is left as the fully-qualified domain name.

A potential workaround would be to have HOSTNAME truncated to the leafname but then modify the references to slapd so that they concatenate the domainname value but that doesn’t seem to make it into the container’s environment variables.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 35 (2 by maintainers)

Most upvoted comments

I got it working! In conclusion i think i had 2 issues.

There seems to be a problem if you specify the port in the URI. Once I managed to free up the port on my NAS so i could use it for LDAP things almost worked.
There was still a problem with StartTLS and an error -11 which i tracked down to be related to certificate signing. The following LDIF needs to be added to make it work:

dn: cn=config changetype: modify replace: olcTLSCipherSuite olcTLSCipherSuite: SECURE256:SECURE128:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.2:+VERS-TLS1.1

Thanks @obourdon & @pcolmer for sticking with me!

guptamp on May 7, 2020

@pcolmer

Thanks for reply. Yea the self-signed certs may be a problem however Let’s Encrypt and other such authorities which I regularly utilize don’t offer the ability for client SSL certificates so I’m kind of stuck rolling my own. I’ve created all the certificates with only local CA and then manually distribute them from that source. I’ve verified all the client and server certificates can validate against the CA so I’m pretty sure I’ve set the certificates up correctly as I’m using similar certificates in other containers.

I don’t know how to describe things, but this container is “fragile”. I get things up and running and then the container will totally break when trying to add replication. I’ve bin mounted the directory containing the ssl certs, but I’ve noticed that if I change some of the SSL certs in the bin mount, they don’t get copied over to the /var/run directory unless the container is rebuilt. I wasn’t aware the actual start process worked this way. I wish I had more errors to post to help debug the problem, however it seems that anytime I make a change with the replication parameters, the entire container “breaks” and the slapd wont start. I’ve noticed if I removed the replication parameters from the docker-compose file, the changes do make it back into the container since the flag “started-with-replication” is still present although I’ve removed these from the docker-compose. The way things are constructed it appears things are kind of setup as a one way process — set things up initially and you can add features along the way (such as tls, replication, SSL client certs, etc), but later its really hard to remove these features once added – hence the “fragility” of the setup.

kevdogg on Jan 4, 2021

@fabiandsouza88 in my environment, I’m using fully-qualified domain names that are resolved via DNS. That is why I didn’t need to add node 2’s details into node 1’s /etc/hosts file.

I don’t know if that helps you figure out a solution?

pcolmer on Jun 5, 2020

@guptamp Please note the changes to docker-compose.yml though - it is very important to configure hostname and domainname correctly. They must not be the same value as per the current recommendations.

pcolmer on Apr 30, 2020