Bug 1330431

This component is not shipped in OpenStack anymore.   Moving to sat6

Created redmine issue http://projects.theforeman.org/issues/15432 from this bug

Per 6.3 planning, moving out non acked bugs to the backlog

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.

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.

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.

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?

(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).

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.

*** Bug 1528334 has been marked as a duplicate of this bug. ***

*** Bug 1528314 has been marked as a duplicate of this bug. ***

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.

(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).

> 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.

(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".

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

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.

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"

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.

*** Bug 1566310 has been marked as a duplicate of this bug. ***

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