Bug 1330431 - [Sat 6.3.Z] RHEL 7.5 blocker: remove rubygem-rkerberos dependency on libkadm5clnt_mit.so
Summary: [Sat 6.3.Z] RHEL 7.5 blocker: remove rubygem-rkerberos dependency on libkadm5...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Packaging
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Sanket Jagtap
URL:
Whiteboard:
: 1528334 1566310 (view as bug list)
Depends On:
Blocks: 1420851 1533621 1563780
TreeView+ depends on / blocked
 
Reported: 2016-04-26 08:48 UTC by Patrik Kis
Modified: 2021-09-09 11:49 UTC (History)
32 users (show)

Fixed In Version: rubygem-rkerberos-0.1.3-5.el7sat
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1533621 1563780 (view as bug list)
Environment:
Last Closed: 2018-04-13 13:29:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 15432 0 Normal Closed remove rubygem-rkerberos dependency on libkadm5clnt_mit.so 2020-12-20 09:03:32 UTC
Red Hat Bugzilla 1166012 0 high CLOSED libkadmclnt SONAME change (8 to 9) in krb5 1.12 update 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1292153 0 high CLOSED Rebase krb5 to 1.14.x 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1528314 0 unspecified CLOSED Satellite installation fails on rhel7.5 beta -- rubygem-rkerberos missing dependency 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1528334 0 unspecified CLOSED missing dependencies in krb5-libs cause Satellite installations to fail 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2018:1126 0 None None None 2018-04-13 13:31:33 UTC

Internal Links: 1166012 1292153 1528314 1528334

Description Patrik Kis 2016-04-26 08:48:16 UTC
Description of problem:
The current version of rubygem-rkerberos requires libkadm5clnt_mit.so.8. This is quite unfortunate as functions provided by this lib are not considered stable by upstream [1] and it may change with krb5 rebase. If it changes (what happened with RHEL-7.2 and now with RHEL-7.3), krb5 has no other option than pretending that it is still providing the old version [2]. This is a very bad practice, IMHO.

It looks like our layered product do not use the kadm5 functions provided by this gem [3], so I think this could be removed from this package and provided as an extra  package (ideally distributed in extras repository as we can not guarantee the stability) to still provide this functionality to potential third party consumers.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1166012#c5
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1292153#c24
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1166012#c8

Version-Release number of selected component (if applicable):
rubygem-rkerberos-0.1.2-3.el7sat

How reproducible:
always

Steps to Reproduce:
# rpm -qpR rubygem-rkerberos-0.1.2-3.el7sat.x86_64.rpm |grep kadm5
libkadm5clnt_mit.so.8()(64bit)
libkadm5clnt_mit.so.8(kadm5clnt_mit_8_MIT)(64bit)

Comment 2 Mike Burns 2016-04-26 16:25:09 UTC
This component is not shipped in OpenStack anymore.   Moving to sat6

Comment 4 Ivan Necas 2016-06-16 10:39:04 UTC
Created redmine issue http://projects.theforeman.org/issues/15432 from this bug

Comment 5 Bryan Kearney 2016-07-08 20:41:43 UTC
Per 6.3 planning, moving out non acked bugs to the backlog

Comment 7 Bryan Kearney 2017-01-04 17:41:21 UTC
This is an older bug, which is being tracked upstream. We will not be tracking this downstream. When the upstream issue is resolved, the next rebase will pull in the fix.

Comment 8 Patrik Kis 2017-01-05 08:24:38 UTC
Let me disagree here and open the BZ again.

One of the reasons why this BZ was filed is that in krb5 package the version of libkadm5clnt_mit.so had to be virtually lowered because rubygem-rkerberos. Until this is fixed in rubygem-rkerberos, krb5 package has to maintain this change, therefore it is important to somehow notify krb5 maintainers that the issue disappeared and probably watching satellite upstream is not the best way.

So I think it would be nice to have this kept opened so that way krb5 can be warned that the fix is not needed.

Comment 9 Patrik Kis 2017-01-05 08:32:16 UTC
BTW, what is the status in the upstream, I don't really see any changes there.

Please note that this change us also in rubygem-rkerberos interest. The mentioned API in krb5 is not stable and can change with every rebase. What was done in krb5 package is that the version number was virtually lowered (and that probably can be done again) so rubygem-rkerberos can be installed without problem.
But that does not mean that the API itself did not change. It change in fact, and it may change again in the future in the way it will be not compatible with the current rubygem-rkerberos. In that case no version lowering will help and rubygem-rkerberos have to be rebuit or stop using this API.

This issue is known for almost a year. I think it would be really nice to have fixed before it will cause more problems.

Comment 12 Eric Helms 2017-02-08 18:40:01 UTC
This package (rubygem-rkerberos) is required by the Foreman Proxy and would require figuring out how to now use that functionality with upstream. Thus I have a few questions:

 1) Does the latest version (https://github.com/domcleal/rkerberos/commits/master) contain a fix for the above mentioned issues?
 2) If not, has an issue been filed with upstream to address this?
 3) Is there an alternative to this package to use?

Comment 13 Robbie Harwood 2017-02-08 20:16:54 UTC
(In reply to Eric Helms from comment #12)
> This package (rubygem-rkerberos) is required by the Foreman Proxy and would
> require figuring out how to now use that functionality with upstream. Thus I
> have a few questions:
> 
>  1) Does the latest version
> (https://github.com/domcleal/rkerberos/commits/master) contain a fix for the
> above mentioned issues?

https://github.com/domcleal/rkerberos/issues/13

>  2) If not, has an issue been filed with upstream to address this?

http://projects.theforeman.org/issues/15432

>  3) Is there an alternative to this package to use?

We're not asking you to use a different package (though you can if you want), just to stop depending on the kadm libs specifically (the rest of krb5 is fine).  We provide no stability guarantees on these libraries, and will inevitably break them (if we haven't already; because we have to lie about version number, no one will know until they try).

Comment 15 Eric Helms 2017-07-10 17:42:15 UTC
I am dropping myself from the needinfo here. I am not familiar with this package and functionality used in the Foreman Proxy project to be able to answer this. The gem itself is an upstream project outside our projects direct control so we could spend time to contribute and work on it but I'd rather someone with more knowledge address the use of the gem.

Comment 18 Robbie Harwood 2018-01-02 17:29:42 UTC
*** Bug 1528334 has been marked as a duplicate of this bug. ***

Comment 21 Brad Buckingham 2018-01-05 16:28:54 UTC
*** Bug 1528314 has been marked as a duplicate of this bug. ***

Comment 22 Dmitri Dolguikh 2018-02-23 19:34:39 UTC
Rebuilding rubygem-rkerberos every time libkadm5clnt_mit (or any other dependency) changes will resolve the issue. Please note that Fedora 27 ships rubygem-rkerberos compiled against libkadm5clnt_mit v.11.

rkerberos gem has been around for awhile, which makes it difficult (if possible at all) to remove libkadm5clnt bindings from it. Considering that kadm5clnt_mit has changed little in the last two (or more) years, I don't think removal of said bindings is even necessary.

Comment 23 Robbie Harwood 2018-02-23 21:06:57 UTC
(In reply to Dmitri Dolguikh from comment #22)
> rkerberos gem has been around for awhile, which makes it difficult (if
> possible at all) to remove libkadm5clnt bindings from it. 

In RHEL, it's only used by Satellite as far as I know.  I was given to understand from the above that Satellite does not use the kadm5 bindings, so I don't see why this would be hard.   Having looked at the code, it's not even a particularly complex patch, since it's just bindings.

Could you upstream such a thing?  No, but that's hardly relevant to this discussion.

> Considering that
> kadm5clnt_mit has changed little in the last two (or more) years, I don't
> think removal of said bindings is even necessary.

I would really rather you not do that, since it perpetuates the myth that this is supported.  kadm5 is *not* in the guaranteed ABI/API stability list (while everything in krb5-libs is).  In practice, what this is going to mean is:

- I can't guarantee stability of that API
- I can't support problems you may encounter due to migrations with that API
- I can't go out of my way to make it easy (e.g., by downgrading soname)

That will apply to any customers who may try to use this package as well (I hope we don't provide this for customer use, but it's not my package, so I don't know).

Comment 24 Dmitri Dolguikh 2018-02-24 00:07:11 UTC
> In RHEL, it's only used by Satellite as far as I know.  I was given to
> understand from the above that Satellite does not use the kadm5 bindings, so
> don't see why this would be hard.   Having looked at the code, it's not even a
> particularly complex patch, since it's just bindings.

The gem isn't used just by Red Hat. There's a comment in the upstream issue stating that someone is using kadm5 binding the gem provides. Unilaterally removing these bindings isn't an option.

> I would really rather you not do that, since it perpetuates the myth that this
> is supported.  kadm5 is *not* in the guaranteed ABI/API stability list (while
> everything in krb5-libs is).

I don't know if this is an issue at all upstream. The gem can follow (or not) the changes in kadm5 as closely as the upstream community needs it to. Downstream we only need to rebuild the package every time kadm5 version changes, which, as far as I understand is acceptable.

Comment 25 Robbie Harwood 2018-02-26 18:01:08 UTC
(In reply to Dmitri Dolguikh from comment #24)
> > In RHEL, it's only used by Satellite as far as I know.  I was given to
> > understand from the above that Satellite does not use the kadm5 bindings, so
> > don't see why this would be hard.   Having looked at the code, it's not even a
> > particularly complex patch, since it's just bindings.
> 
> The gem isn't used just by Red Hat. There's a comment in the upstream issue
> stating that someone is using kadm5 binding the gem provides. Unilaterally
> removing these bindings isn't an option.

Removing them *upstream* may not be an option.  You are not bound by that downstream, and since upstream doesn't care about this issue, you'll probably have to diverge anyway.

> I don't know if this is an issue at all upstream. The gem can follow (or not) the changes in kadm5 as closely as the upstream community needs it to. Downstream we only need to rebuild the package every time kadm5 version changes, which, as far as I understand is acceptable.

To quote freeBSD: "If it breaks then you get to keep both pieces".

Comment 29 Mike McCune 2018-04-05 17:25:00 UTC
This is the 6.3.z bug

6.2.z:

https://bugzilla.redhat.com/show_bug.cgi?id=1533621

6.1.z:

https://bugzilla.redhat.com/show_bug.cgi?id=1563780

Comment 30 evan.hisey 2018-04-11 21:06:30 UTC
Do we have a supported workaround for patching RHEL 7.4 Satellite 6.3 hosts till a full upgrade is supported? I would rather not just disable the Satellite repo to upgrade since I am not sure of the full dependency tree and would rather not break a working system.

Comment 31 Sanket Jagtap 2018-04-12 12:46:23 UTC
Build: Satellite 6.3.1 Snap 3

Satellite and Capsule were Successfully Installed on RHEL 7.5, there were no dependency issues during "yum install"

Satellite+Capsule(6.2.14) (RHEL 7.4) were Successfully Upgraded  to latest
Satellite+Capsule(6.3.1 Snap3) (RHEL 7.5) there were no dependency issues during "yum update"

Comment 32 Nikhil Kathole 2018-04-12 12:51:25 UTC
Adding to this, Provisioning rhel 7.5 as well as package installation on rhel 7.5 content hosts from satellite 6.3.1 snap 3 worked successfully.

Comment 33 Robbie Harwood 2018-04-12 17:13:20 UTC
*** Bug 1566310 has been marked as a duplicate of this bug. ***

Comment 36 errata-xmlrpc 2018-04-13 13:29:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1126


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