/var/run/slapd also has to be accessible to slapd

[rysiekpl]

Sharing unix sockets via data-only containers is a viable way of communicating between processes; to do this, however, /var/run/slapd has to be on a volume from an external container. There is no guarantee that it will have the correct permissions, hence the need to chown it in the entrypoint script.

[dinkel]

Hello rysiekpl,

I just merged your pull request, thanks for that.

I however don't really understand, in what circumstances this sharing of unix sockets becomes handy. Do you have a real world example to explain it to me?

Thanks,

Dinkel

[rysiekpl]

Sure. For instance when you want to have containers with software connecting to the LDAP server, but for one reason or other using TCP/IP is unwieldy or impossible.

Consider two containers that you want to be able to connect to the LDAP server. Using docker links means that they are connected via TCP/IP, and that means that their IP addresses must remain constant, and that they have to have TCP/IP connectivity between them. If for some reason you recreate the LDAP container, its IP address will change, and that means that either there is a way for the other containers to have that info updated too, or they will loose connectivity.

If, on the other hand, they comminicate with the LDAP container via a UNIX socket in a volume-mounded directory, the containers can be recreated as much as you want, and their IP addresses can change, but the containers will still be able to connect via the UNIX socket.

[dinkel]

OK, I understand now. Thanks!