#50343 Option to disable LDAPI in dscreate
Opened 6 months ago by edewata. Modified 3 months ago

Currently dscreate will always create an LDAPI socket. This seems to be causing a problem for containerization. Presumably dscreate does not have a permission to create the LDAPI socket in the container, and also it may not be needed at all for containers, so having an option to skip LDAPI socket creation would probably avoid this problem.

To reproduce the problem, use the following Dockerfile:

FROM fedora:29

ENV container docker
EXPOSE 10389 10636

RUN dnf install -y 389-ds-base
RUN dscreate create-template | sed \
    -e "s/;root_password = .*/root_password = Secret.123/g" \
    -e "s/;suffix = .*/suffix = dc=example,dc=com/g" \
    -e "s/;selinux = .*/selinux = False/g" \
    -e "s/;port = .*/port = 10389/g" \
    -e "s/;secure_port = .*/secure_port = 10636/g" \
    > /root/ds.inf
RUN dscreate from-file /root/ds.inf --containerised

USER dirsrv

CMD [ \
    "/usr/sbin/ns-slapd", \
    "-D", "/etc/dirsrv/slapd-localhost", \
    "-i", "/var/run/dirsrv/slapd-localhost.pid" \
]

Then execute the following commands:

$ docker build -t ds .
$ docker run --rm --name ds ds

It will fail with the following error:

[26/Apr/2019:18:23:47.052692715 +0000] - ERR - createprlistensockets - PR_Bind()
 on localhost file /var/run/slapd-localhost.socket failed: Netscape Portable Run
time error -5966 (Access Denied.)

Ideally the container should be able to run without errors.


Upstream has a "better" way to manage container builds now. Could you test with a different dockerfile based on: https://pagure.io/389-ds-base/blob/master/f/src/lib389/cli/dscontainer I can provide a dockerfile if required.

Metadata Update from @firstyear:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

6 months ago

Hi, if you could provide the Dockerfile and the commands to build and run it that'll be great. Thanks!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
FROM opensuse/tumbleweed:latest
MAINTAINER wbrown@suse.de

EXPOSE 3389 3636

RUN zypper in -y 389-ds

RUN mkdir -p /data/config && \
    mkdir -p /data/ssca && \
    ln -s /data/config /etc/dirsrv/slapd-localhost && \
    ln -s /data/ssca /etc/dirsrv/ssca

# Install 389-ds ...

# Temporal volumes for each instance

VOLUME /data/

CMD [ "/usr/sbin/dscontainer", "-r" ]

THis is what I have been using: I'm sure you wouldl be able to adjust it for fedora/rhel easily.

Is this still a valid request? Do we need to disable LDAPI in docker?

We require it in docker :) if there is an issue with it in docker, that means there is a docker file issue.

Sorry for the delay. I managed to deploy DS into OpenShift with this procedure:
https://www.dogtagpki.org/wiki/DS_OpenShift

As shown in the above page, it's necessary to disable LDAPI after installation. So an option to disable it during installation would be nice. Thanks!

@edewata I'm actually considering making ldapi a required part of the setup for containers rather than using a known directory manager password during the setup. So I think if there is an issue we should resolve that directly so that ldapi works in all cases.

@edewata So, removing USER dirsrv makes things run OK. I think we, who are not much knowledgeable in containers, need to understand what (POSIX?) constraints we need to make our provisioning/tooling and runtime to work within. Is the aforementioned non-privileged USER dirsrv a requirement? Would be obtaining a CAP_NET_RAW an option? Note that ns-slapd drops privileges after it does the necessary root "stuff".

Additionally, we should think about what are the differences in expected approaches of Endi and William and find some common solution.

@edewata I'm actually considering making ldapi a required part of the setup for containers rather than using a known directory manager password during the setup. So I think if there is an issue we should resolve that directly so that ldapi works in all cases.

But if LDAPI can not work in Openshift, then providing an option in dscreate to turn it off seems harmless. What I don't understand is why LDAPI does not work in Openshift.

About the USER dirsrv directive, I think it's actually ignored by OpenShift. It's there to avoid a warning about container running as root, but OpenShift will actually assign an unnamed runtime user with some kind of random UID to the container. The container will never run with root privileges.

About LDAPI, I'm not sure why it doesn't work in OpenShift. It's possible the runtime user doesn't have the permission to access the LDAPI socket.

I think it would be best if you try this yourself on OpenShift. You probably can use the free trial account here: https://www.openshift.com.

It would be better to fix our server to work in openshift/k8s which is something I plan to do in the coming months, but it's much more complicated than just "fix ldapi". You need to coordinate replication, scaling and more. So I think that we should not trivialise k8s integration to just "fix ldapi" when the problems are much larger, and in fact, having working ldapi would mean we could have the system make changes on the fly as needed inside of the containers / pods.

About LDAPI, I'm not sure why it doesn't work in OpenShift. It's possible the runtime user doesn't have the permission to access the LDAPI socket.

The problem is the server is actually creating the socket. This workarounds the issue in Docker:

RUN sed -i -E 's#^nsslapd-ldapifilepath: /var/run/slapd-(.*)#nsslapd-ldapifilepath: /var/run/dirsrv/slapd-\1#' /etc/dirsrv/slapd-localhost/dse.ldif

The /var/run is writeable only by root, thus non-privileged user is not able to create a socket there. However, the /var/run/dirsrv is owned by dirsrv so creating it there just works. A side-effect is the socket is owned by dirsrv (is this good, bad, neutral?). I would find this to be a saner default. Would we make this default the backwards compatibility could be handled on RPM level. ..... And/Or we provide this option in default.inf.

I agree with William there is many more issues for openshift/k8s integration for which, however, there should be a separate issue ticket; let's keep this one about the original issue.

And finally, I believe we should strive for being able to configure and run the server by a non-privileged user out-of-box.

A side note -- changing to /var/run/dirsrv/slapd-* for the ldapi socket might be preferable in a default.inf as an option so that the setting can be enforced. FreeIPA expects /var/run/slapd-* and this is currently hard-coded. FreeIPA expects to be working in a privileged container due to systemd integration so this might be a not that big deal in that case, though.

A side note -- changing to /var/run/dirsrv/slapd- for the ldapi socket might be preferable in a default.inf as an option so that the setting can be enforced. FreeIPA expects /var/run/slapd- and this is currently hard-coded. FreeIPA expects to be working in a privileged container due to systemd integration so this might be a not that big deal in that case, though.

Sure, the default.inf should have an option for that (maybe turning off the LDAPI when empty-valued?), as I've already suggested. When we would change the default location then for backwards compatibility (in ns-slapd) we could make a "best effort" (meaning in privileged case this would work, else live without it) of creating a symlink to mimic the old location.

My point is I am considering making ldapi a requirement of dscreate so that we don't have to set the temporary root pw and then do the setup. Additionally there are other areas that can benefit from this.

In docker, the socket should also end up in /data by the way, so that it can be accessed from the container host. So that's something for the container setup to fix.

Login to comment on this ticket.

Metadata