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
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".
USER dirsrv
Additionally, we should think about what are the differences in expected approaches of Endi and William and find some common solution.
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.
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.
/var/run
/var/run/dirsrv
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.
/var/run/dirsrv/slapd-*
default.inf
/var/run/slapd-*
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.
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.2
Metadata Update from @vashirov: - Issue priority set to: minor - Issue set to the milestone: 1.4.3 (was: 1.4.2)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/3402
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.