Description of problem: Attempting to install updates for 389-ds-base* from the rhel-7-server-rpms repo via yum results in the following error: Transaction check error: file /usr/lib64/dirsrv from install of 389-ds-base-libs-1.3.10.2-6.el7.x86_64 conflicts with file from package 389-admin-1.1.46-1.el7.x86_64 Version-Release number of selected component (if applicable): Installed 389* packages: # rpm -qa 389* 389-console-1.1.19-6.el7.noarch 389-ds-base-1.3.10.1-14.el7_8.x86_64 389-admin-console-doc-1.1.12-1.el7.noarch 389-ds-1.2.2-6.el7.noarch 389-admin-1.1.46-1.el7.x86_64 389-admin-console-1.1.12-1.el7.noarch 389-ds-console-1.2.16-1.el7.noarch 389-ds-base-libs-1.3.10.1-14.el7_8.x86_64 389-ds-console-doc-1.2.16-1.el7.noarch 389-dsgw-1.1.11-5.el7.x86_64 389-adminutil-1.1.22-2.el7.x86_64 Updated Packages: (from yum list updates) 389-ds-base.x86_64 1.3.10.2-6.el7 rhel-7-server-rpms 389-ds-base-libs.x86_64 1.3.10.2-6.el7 rhel-7-server-rpms How reproducible: The above are the only updates available. The server was already updated to RHEL 7.9 by excluding 389* packages as it would fail otherwise. Steps to Reproduce: 1. Run 'yum list updates' to list available packages 2. Attempt to install updates 3. Actual results: 1. List available updates # yum list updates Loaded plugins: enabled_repos_upload, langpacks, package_upload, product-id, : search-disabled-repos, subscription-manager Updated Packages 389-ds-base.x86_64 1.3.10.2-6.el7 rhel-7-server-rpms 389-ds-base-libs.x86_64 1.3.10.2-6.el7 rhel-7-server-rpms Uploading Enabled Repositories Report Loaded plugins: langpacks, product-id, subscription-manager 2. Attempt to install updates # yum update -y Loaded plugins: enabled_repos_upload, langpacks, package_upload, product-id, : search-disabled-repos, subscription-manager Resolving Dependencies --> Running transaction check ---> Package 389-ds-base.x86_64 0:1.3.10.1-14.el7_8 will be updated ---> Package 389-ds-base.x86_64 0:1.3.10.2-6.el7 will be an update ---> Package 389-ds-base-libs.x86_64 0:1.3.10.1-14.el7_8 will be updated ---> Package 389-ds-base-libs.x86_64 0:1.3.10.2-6.el7 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: 389-ds-base x86_64 1.3.10.2-6.el7 rhel-7-server-rpms 1.7 M 389-ds-base-libs x86_64 1.3.10.2-6.el7 rhel-7-server-rpms 713 k Transaction Summary ================================================================================ Upgrade 2 Packages Total size: 2.4 M Downloading packages: Running transaction check Running transaction test Transaction check error: file /usr/lib64/dirsrv from install of 389-ds-base-libs-1.3.10.2-6.el7.x86_64 conflicts with file from package 389-admin-1.1.46-1.el7.x86_64 Error Summary ------------- Uploading Enabled Repositories Report Loaded plugins: langpacks, product-id, subscription-manager Expected results: The expected result is for the 389-ds-base and 389-ds-base-libs packages to be updated successfully to the latest version Additional info: Troubleshooting done. 1. List install 389* package using rpm # rpm -qa 389* 389-console-1.1.19-6.el7.noarch 389-ds-base-1.3.10.1-14.el7_8.x86_64 389-admin-console-doc-1.1.12-1.el7.noarch 389-ds-1.2.2-6.el7.noarch 389-admin-1.1.46-1.el7.x86_64 389-admin-console-1.1.12-1.el7.noarch 389-ds-console-1.2.16-1.el7.noarch 389-ds-base-libs-1.3.10.1-14.el7_8.x86_64 389-ds-console-doc-1.2.16-1.el7.noarch 389-dsgw-1.1.11-5.el7.x86_64 389-adminutil-1.1.22-2.el7.x86_64 2. Check permission of /usr/lib64/dirsrv for the installed 389-admin and 389-ds-base-libs packages # rpm -qlv 389-admin-1.1.46-1.el7.x86_64 | grep /usr/lib64/dirsrv\$ drwxr-xr-x 2 root root 0 Nov 2 2016 /usr/lib64/dirsrv # rpm -qlv 389-ds-base-libs-1.3.10.1-14.el7_8.x86_64 | grep /usr/lib64/dirsrv\$ drwxr-xr-x 2 root root 0 Jun 15 22:06 /usr/lib64/dirsrv The permission of /usr/lib64/dirsrv in both packages is mode 755 3. Check permission of /usr/lib64/dirsrv in the new package in the yum cache. # cd /var/cache/yum/x86_64/7Server/rhel-7-server-rpms/packages # rpm -qlvp 389-ds-base-libs-1.3.10.2-6.el7.x86_64.rpm | grep /usr/lib64/dirsrv\$ drwxrwxr-x 2 root root 0 Jun 4 23:26 /usr/lib64/dirsrv ^^^^^^^^^ As can be seen, the new 389-ds-base-libs package has the permissions of /usr/lib64/dirsrv set to mode 775, which results in the conflict. This issue has also been logged as case #02770000 with Red Hat Support.
I just discovered that this same issue was previously reported as bug 1814603, where the issue was reported for 389-ds-base-libs-1.3.10.1-13.el7_8.x86_64. We have the next release installed - 389-ds-base-libs-1.3.10.1-14.el7_8.x86_64, the obvious the fix was in that release. However in 389-ds-base-libs-1.3.10.2-6.el7.x86_64 it is broken again.
The issue is with 389-admin in EPEL, there is a spec file change that needs to applied. 389-admin from RHDS repository works correctly.
Hi Viktor, Does this mean we will see a new update in Fedora EPEL soon that reflects this spec file change? The EPEL version has not been updated in nearly four years (Nov 2016)! Looking at the changelog for 389-ds-base-libs-1.3.10.2-6.el7.x86_64.rpm I cannot see why the directory permissions of /usr/lib64/dirsrv were changed. I see that bug 1700987 is referenced, but that bug report doesn't mention this directory at all. I would've thought that permissions of mode 755 would be better or more secure than mode 775 as set in the new package. Thanks, Gunter
Hi Gunter, > Does this mean we will see a new update in Fedora EPEL soon that reflects > this spec file change? Yes, I think so. > The EPEL version has not been updated in nearly four years (Nov 2016)! RHDS version of 389-admin also did not receive an update in 4 years until this fix. RHDS 10 (that includes 389-admin, 389-console) is in maintenance mode and will be EOL on November 30, 2020: https://access.redhat.com/support/policy/updates/directory > Looking at the changelog for 389-ds-base-libs-1.3.10.2-6.el7.x86_64.rpm I > cannot see why the directory permissions of /usr/lib64/dirsrv were changed. > I see that bug 1700987 is referenced, but that bug report doesn't mention > this directory at all. I would've thought that permissions of mode 755 > would be better or more secure than mode 775 as set in the new package. Here's the fix: https://pagure.io/389-ds-base/pull-request/50941 https://git.centos.org/rpms/389-ds-base/blob/c7/f/SPECS/389-ds-base.spec#_270 It's not really obvious, but > chmod 775 $(DESTDIR)$(serverdir) is changing the permissions of /usr/lib64/dirsrv. 389-admin co-owns same directories as 389-ds-base, as it installs some files there: # rpm -qf /usr/lib64/dirsrv 389-ds-base-libs-1.3.10.2-6.el7.x86_64 389-admin-1.1.46-4.el7dsrv.x86_64 So the fix has to be applied on both sides: 389-ds-base and 389-admin. As for 755 vs 775: # ls -ld /usr/lib64/dirsrv/ drwxrwxr-x. 7 root root 4096 Oct 19 05:38 /usr/lib64/dirsrv/ The owner of this directory is root, so it doesn't really matter. HTH
Hi Gunter, I've submitted a PR for review with the fix: https://src.fedoraproject.org/rpms/389-admin/pull-request/1 Once it's merged, new build will be available in epel-testing. In the meantime there is a copr build that you can install for testing right away: https://copr.fedorainfracloud.org/coprs/vashirov/389-admin/ Thanks.
FEDORA-EPEL-2020-0d461626b9 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d461626b9
FEDORA-EPEL-2020-0d461626b9 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d461626b9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hi Viktor, Thank you for your efforts to create the fix for 389-admin. I've used the package in EPEL 7 Testing and applied it successfully to our LDAP Testing environment. Thanks, Gunter
FEDORA-EPEL-2020-0d461626b9 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.