389-ds-base

#50728 Issue 50439 - Update docker integration for Fedora
Closed by spichugi. Opened by mhonek.
mhonek/389-ds-base fix-fedora-dockerfile  into  master

Download 50728.patch

Bug Description:
Fedora Dockerfile has been unbuildable/broken for sometime.

Fix Description:
Update the Dockerfile to make it work while mimicking ideas from the
SUSE's counterpart.

Additionaly, changing wget to curl in rpm.mk since wget does not seem to
be available in the minimal image.

Relates https://pagure.io/389-ds-base/issue/50439
Relates https://pagure.io/389-ds-base/pull-request/50441#comment-88961

Author: Matus Honek mhonek@redhat.com

Review by: ???

All seems reasonable to me, but maybe someone who uses fedora more these days wants to check :)

I followed README.md, navigated to docker/389-ds-fedora and tried to build it. Current pwd doesn't have 389-ds-base sources, so make rpms failed down the line.
How this container build should be executed?
Edited by vashirov

@vashirov Ah, README seems to be fairly outdated, too. You need to build from the git root, like docker build -f docker/389-ds-fedora/Dockerfile .. I would rather address this in a follow-up ticket, if that's ok.

Ok, this way build worked (after fixing npm issues).

Now I'm trying to run this and have the following error:

DEBUG: READY: Beginning installation for localhost...                                                                              
DEBUG: ACTION: Creating dse.ldif                                                                                                   
DEBUG: ACTION: creating /data/bak                                                                                                  
DEBUG: ACTION: creating /etc/dirsrv/slapd-localhost                                                                                
DEBUG: ACTION: creating /data/db                                                                                                   
DEBUG: ACTION: creating /data/ldif
DEBUG: ACTION: creating /data/run/lock
DEBUG: ACTION: creating /data/logs
DEBUG: ACTION: creating /data/run
Traceback (most recent call last):
  File "/usr/sbin/dscontainer", line 332, in <module>
    begin_magic()
  File "/usr/sbin/dscontainer", line 193, in begin_magic
    if not sds.create_from_args(g2b.collect(), s2b.collect()):
  File "/usr/lib/python3.7/site-packages/lib389/instance/setup.py", line 654, in create_from_args
    self._install_ds(general, slapd, backends)
  File "/usr/lib/python3.7/site-packages/lib389/instance/setup.py", line 770, in _install_ds
    shutil.copy2(srcfile, dstfile)
  File "/usr/lib64/python3.7/shutil.py", line 267, in copy2
    copystat(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib64/python3.7/shutil.py", line 209, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/lib64/python3.7/shutil.py", line 165, in _copyxattr
    os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
PermissionError: [Errno 13] Permission denied: '/etc/dirsrv/slapd-localhost/slapd-collations.conf'

I see the following SELinux denials on the host system:

----
time->Wed Nov 20 11:58:31 2019
type=AVC msg=audit(1574247511.026:25023): avc:  denied  { relabelto } for  pid=2941395 comm="dscontainer" name="99user.ldif" dev="dm-1" ino=14168269 scontext=system_u:system_r:container_t:s0:c44,c359 tcontext=system_u:object_r:fusefs_t:s0 tclass=file permissive=0
----
time->Wed Nov 20 11:58:31 2019
type=AVC msg=audit(1574247511.026:25024): avc:  denied  { relabelto } for  pid=2941395 comm="dscontainer" name="slapd-collations.conf" dev="dm-1" ino=14168270 scontext=system_u:system_r:container_t:s0:c44,c359 tcontext=system_u:object_r:fusefs_t:s0 tclass=file permissive=0

It doesn't happen if /etc/dirsrv/slapd-localhost is not symlinked to a mounted /data/config/.
Is this expected?

I use podman on my F31 system, since docker doesn't support cgroups v2.
Apparently there are some differences and podman is more strict. Let's merge this as it is, and later we can address podman issues.

rebased onto 957e2ae225803cb108e6ea3beec431eb015568ae

I've rebased including an addition of a fedora target in docker.mk, per Viktor's suggestion.

FTR: my use cases are such that selinux is not an issue (unconfined) for me when it comes to volumes (it's all within the /home partition of mine, even the default docker's volumes' location). The issues mentioned here should be of course solved but reasoning and solving them is going to be non-trivial, so deferring this into future.

Thanks.

Pull-Request has been merged by mhonek

README changes ticket: #50732

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 pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3783

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.