Bug 1886024 - 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
Summary: file /usr/lib64/dirsrv from install of 389-ds-base-libs-1.3.10.2-6.el7.x86_64...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: 389-admin
Version: epel7
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: mreynolds
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-10-07 13:37 UTC by Gunter Muller
Modified: 2023-12-15 19:41 UTC (History)
10 users (show)

Fixed In Version: 389-admin-1.1.46-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-12 04:50:55 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Gunter Muller 2020-10-07 13:37:16 UTC
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.

Comment 2 Gunter Muller 2020-10-09 08:52:54 UTC
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.

Comment 6 Viktor Ashirov 2020-10-15 16:09:32 UTC
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.

Comment 8 Gunter Muller 2020-10-16 09:51:07 UTC
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

Comment 9 Viktor Ashirov 2020-10-19 09:58:46 UTC
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

Comment 10 Viktor Ashirov 2020-10-26 13:02:06 UTC
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.

Comment 11 Fedora Update System 2020-10-27 16:04:21 UTC
FEDORA-EPEL-2020-0d461626b9 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d461626b9

Comment 12 Fedora Update System 2020-10-28 02:36:01 UTC
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.

Comment 13 Gunter Muller 2020-11-05 01:40:35 UTC
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

Comment 14 Fedora Update System 2020-11-12 04:50:55 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.