Hi,
I'm currently trying to install 389 Directory Server on CentOS, but it looks like related packages are broken. Here's what I get:
# yum install 389-* ... --> Processing Dependency: libadminutil.so.0()(64bit) for package: 389-dsgw-1.1.11-5.el7.x86_64 --> Processing Dependency: libadmsslutil.so.0()(64bit) for package: 389-dsgw-1.1.11-5.el7.x86_64 ---> Package avahi-libs.x86_64 0:0.6.31-19.el7 will be installed ---> Package libfontenc.x86_64 0:1.1.3-3.el7 will be installed ---> Package python-lxml.x86_64 0:3.2.1-4.el7 will be installed --> Finished Dependency Resolution Error: Package: 389-ds-1.2.2-6.el7.noarch (epel) Requires: 389-console Error: Package: 389-admin-1.1.46-1.el7.x86_64 (epel) Requires: libadminutil.so.0()(64bit) Error: Package: 389-dsgw-1.1.11-5.el7.x86_64 (epel) Requires: libadminutil.so.0()(64bit) Error: Package: 389-admin-1.1.46-1.el7.x86_64 (epel) Requires: libadmsslutil.so.0()(64bit) Error: Package: 389-dsgw-1.1.11-5.el7.x86_64 (epel) Requires: libadmsslutil.so.0()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Any suggestions ?
Niki
Le 15/08/2019 à 13:49, Ulf Volmer a écrit :
No issues here. libadmsslutil.so.0 comes from 389-adminutil. Do you have a recently updated system?
I'm using yum-cron on all my CentOS servers, so yes.
On 15.08.19 14:31, Nicolas Kovacs wrote:
Le 15/08/2019 à 13:49, Ulf Volmer a écrit :
No issues here. libadmsslutil.so.0 comes from 389-adminutil. Do you have a recently updated system?
I'm using yum-cron on all my CentOS servers, so yes.
Could you post the output of
yum info 389-adminutil
Best regards Ulf
Le 15/08/2019 à 14:51, Ulf Volmer a écrit :
Could you post the output of
yum info 389-adminutil
I just installed a vanilla CentOS 7.6 on a sandbox machine.
Left configuration as is.
Upgraded system : yum update.
Configured EPEL without customizing anything.
And all the 389-related packages installed successfully.
So I guess the problem comes from my base configuration. Here's what I usually modify:
1. Activate the Yum CR Community Repository.
2. Install Yum Priorities Plugin.
3. Configure official and CR repository with a priority of 1.
4. Configure EPEL repository with a priority of 10.
My suspicion is that some stuff from CR broke dependencies.
I have to investigate this further.
Cheers,
Niki
Le 15/08/2019 à 15:20, Nicolas Kovacs a écrit :
I have to investigate this further.
I found the culprit, after a few unnerving hours of trial and error. Turns out I'm using a hardcoded EPEL mirror in France to bypass my filtering proxy. Unfortunately this mirror is not quite in sync, and there's a few vital packages missing.
As soon as I reverted to a vanilla EPEL configuration, things worked perfectly.
Cheers,
Niki
On 8/15/19 8:20 AM, Nicolas Kovacs wrote:
<snip>
My suspicion is that some stuff from CR broke dependencies.
CR is normally completely empty. The only time CR is normally populated is for a small time before a new release is done .. and it is populated with packages that will go into the new release. Right now, for example, CR is empty:
http://mirror.centos.org/centos/7/cr/x86_64/Packages/
CR for CentOS-7 will be populated, sometime soon (:D), with the packages that we will use to upgrade from CentOS version 7.6.1810 to 7.7.1908.
The whole purpose of CR is to offer the NEXT release packages, once QA'ed, for being able to do an upgrade to what will be the next version.
That will give you the packages WHILE we work on the install tree and install media for the next version (in this case it would upgrade you to all the 7.7.1908 packages).
Even when CR is populated, it does not contain any packages that will not be in either os/ or updates/ in the next release.
Thanks, Johnny Hughes
Le 16/08/2019 à 13:29, Johnny Hughes a écrit :
CR is normally completely empty. The only time CR is normally populated is for a small time before a new release is done .. and it is populated with packages that will go into the new release. Right now, for example, CR is empty:
Thanks for the clarification. As it turned out (see my subsequent post), the error came from a badly maintained EPEL mirror in France.
Cheers,
Niki