Koozali.org: home of the SME Server
Obsolete Releases => SME Server 9.x => Topic started by: DanB35 on August 15, 2014, 01:41:11 PM
-
Yesterday, my SME 9 server informed me that there's an update available to openssl-perl (to openssl-perl-1.0.1e-16.el6_5.15.x86_64). The update wouldn't install, though; there was a dependancy problem with openssl. This morning, there were more updates available, still including openssl-perl, but not including openssl. Again, the openssl-perl update wouldn't install:
[root@e-smith ~]# yum update
Loaded plugins: fastestmirror, smeserver
Loading mirror speeds from cached hostfile
* base: mirror.team-cymru.org
* smeaddons: mirror.canada.pialasse.com
* smeextras: mirror.canada.pialasse.com
* smeos: mirror.canada.pialasse.com
* smeupdates: mirror.canada.pialasse.com
* updates: mirrors-pa.sioru.com
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package glibc.x86_64 0:2.12-1.132.el6_5.2 will be updated
---> Package glibc.x86_64 0:2.12-1.132.el6_5.3 will be an update
---> Package glibc-common.x86_64 0:2.12-1.132.el6_5.2 will be updated
---> Package glibc-common.x86_64 0:2.12-1.132.el6_5.3 will be an update
---> Package glibc-devel.x86_64 0:2.12-1.132.el6_5.2 will be updated
---> Package glibc-devel.x86_64 0:2.12-1.132.el6_5.3 will be an update
---> Package glibc-headers.x86_64 0:2.12-1.132.el6_5.2 will be updated
---> Package glibc-headers.x86_64 0:2.12-1.132.el6_5.3 will be an update
---> Package nscd.x86_64 0:2.12-1.132.el6_5.2 will be updated
---> Package nscd.x86_64 0:2.12-1.132.el6_5.3 will be an update
---> Package openssl-perl.x86_64 0:1.0.1e-16.el6_5.14 will be updated
---> Package openssl-perl.x86_64 0:1.0.1e-16.el6_5.15 will be an update
--> Processing Dependency: openssl = 1.0.1e-16.el6_5.15 for package: openssl-perl-1.0.1e-16.el6_5.15.x86_64
--> Finished Dependency Resolution
Error: Package: openssl-perl-1.0.1e-16.el6_5.15.x86_64 (updates)
Requires: openssl = 1.0.1e-16.el6_5.15
Installed: openssl-1.0.1e-16.el6_5.14.x86_64 (@anaconda-base-201406271835.x86_64/9.0)
openssl = 1.0.1e-16.el6_5.14
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
I have run rpm -Va --nofiles --nodigest; it produces no output and does not correct the problem. I have not tried the --skip-broken option.
-
Not really a solution to your problem, but you can install the rest of the updates for now by issueing:
yum update --exclude=*openssl*
HTH
guest
-
I've opened Bug 8530 (http://bugs.contribs.org/show_bug.cgi?id=8530) on this issue. The appropriate version of openssl appears to be in the repo, but yum doesn't appear to see it for some reason.
-
hi DanB35,
I met this issue in the past for libvirt, i solved it by playing with yum options :
yum install --disablerepo=* --enablerepo=base,updates libvirt
Now, I'm not mixing Koozali SME and Centos updated RPM !
From my point of view, for the moment users/developpers should install only CentOS updates on SME9/Centos6 server.
Regards
-
Xavier.A & other readers
Please see the bug report comment 9
http://bugs.contribs.org/show_bug.cgi?id=8530#c9
the repo info was set incorrectly, blocking the update of openssl
I am not so sure Xavier that what you have done is the right (best) approach.
-
Yes, both the updates repo and the base repo were set to exclude openssl. I can't imagine why, but I don't suppose "why" is really that important. Changed the configuration on both of them to remove that exclusion, rebuilt the config file, and now the update works properly.
-
Could it be it was a "left over and forgotten action" due the heartbleed issue at that time?
-
Dan, please edit the Subject of the first message in the thread to include [SOLVED].
-
Could it be it was a "left over and forgotten action" due the heartbleed issue at that time?
Not likely, as SME server wan't affected by heartbleed, and excluding openssl updates would be a very strange way of alleviating a heartbleed problem.
The problem may be a legacy of this:
http://bugs.contribs.org/show_bug.cgi?id=8208#c13
-
If this exclusion results from a change made in a previous version of the smeserver-support RPM, is it still correct to mark the bug report as RESOLVED/NOTABUG?
-
If this exclusion results from a change made in a previous version of the smeserver-support RPM, is it still correct to mark the bug report as RESOLVED/NOTABUG?
If you think it might be, re-open the bug, and re-start the discussion there.