[CentOS] mismatch in openssh latest rpm available at centos
rswwalker at gmail.com
Fri Mar 30 00:42:50 UTC 2012
On Mar 29, 2012, at 11:39 AM, Johnny Hughes <johnny at centos.org> wrote:
> On 03/29/2012 09:56 AM, m.roth at 5-cent.us wrote:
>> Johnny Hughes wrote:
>>> On 03/28/2012 08:05 PM, Vinay Nagrik wrote:
>>>> The latest rpm in openssh is 5.8, however, the corresponding latest rpm
>>>> available in centos 5.7 is only
>>>> and in 6.0 centos is
>>>> I have following questions.
>>>> 1. I want to start from src.rpm and where can I get the src.rpm for
>>>> 2. Can I install openssh-5.3p1-20.el6.x86_64.rpm SAFELY with 5.7 centos
>>>> without causing any problems.
>>> If you rebuild it, if it rebuilds, and if you rebuild anything that
>>> depends on the old one, then yes. It may not build without newer
>>> "buildrequires" being met though. And now, every time there is an
>>> upgrade, you have to remember to get the new one and rebuild again. You
>>> also have to track any changes of the new "buildrequires" that you had
>>> to build.
>>>> 3. Which of these two rpms will be most compatible with latest openssh
>>>> rpm version 5.8.
>>> If you rebuild a new ssh, you will also have to rebuild any packages
>>> that are built against the old openssh against the new openssh.
>>> If you are concerned about security ... that is the whole purpose of
>>> enterprise linux ... it backports security patches for 10 years while
>>> maintaining consistent APIs/ABIs.
>>> If you want the latest packages on your machine, then you want Fedora
>>> and not CentOS.
>> Well... I can see it. We had to build a newer package for 5.x, because we
>> *had* to have PIV-II/pkcs11 support. That's *just* come in with 6.2, to be
>> able to log in with a smart card. Even so, there's a bug/enhancement (and
>> my manager has this in w/ Redhat, and it's been escalated) needed, that it
>> insists on showing the userlist of recent logins.
> And this can be the case ... they will roll back security items, but
> there will be some new functionality that is not rolled back.
> If you really need some new function, then yes, a rebuild is in order.
> That entails all the things I outlined above though ... figuring out
> "what else" you need to build first to use as a "BuildRequires", figure
> out what you have to build after because they depend on the built Share
> libraries of the package (or one they depend on one of your Newer
> BuildRequires that you needed). Then you need to set up a method to
> track all the "out of band" packages that you are adding so you keep
> them up2date.
> This can sometimes just be the package in question ... but sometimes it
> can be a whole bunch of other packages too ... for example, if you built
> a newer openssl, you would also need to rebuild all of these afterwards
> (which build against openssl):
> [hughesjr at localhost SRPMS]$ for srpms in $(ls *.src.rpm); do
> is_openssl=$(rpm -qp --requires $srpms | grep openssl); if [
> "$is_openssl" != "" ]; then echo $srpms; fi; done
> So, this can be very challenging.
I think when substituting core packages it's better to root the substitutes in /usr/local, use tagged init scripts and employ the 'alternatives' feature instead of trying to replace the core packages, their dependencies and dependents.
Then both can be installed and the operator can switch from one to the other as necessary.
More information about the CentOS