Bug 1466006

Is this a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1442313#c6 ? 7.3 EUS metadata was broken earlier this year, if the broken data was *ever* sync'd, it requires deleting the 7.3EUS channel and resynching to fix.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1427354

Hi Grant,

Thank you for the update,

I had discussion with Tomas Lestach about this issue, he cross checked few things on the setup and agreed to create bz for same. 

This issue is reproducible locally and also at customer end. We tried removing and re-syncing channels on the customers satellite but there was no change. The mapping in the rhnReleaseChannelMap table is correct.

One more thing I would like to share is, when we downgrade the redhat-release-server package to v 7.1 the RHEL 7.2 EUS , RHEL 7.3 EUS and RHEL 7 Server base channels are available on "Alter Channel Subscription" page. From this I think we can confirm that the mapping is correctly reflected...


Regards,
Ashish

Actually I see a very similar problem on sputnik, what is Sat 5.8.

A system with redhat-release-server-7.2-9.el7 will be offered to be subscribed to:
* RHEL EUS Server v7.3 if currently in RHEL Server v.7
* RHEL Server v.7 if currently in RHEL EUS Server v. 7.3
* RHEL Server v.7 if currently in RHEL EUS Server v. 7.2
* RHEL Server v.7 if currently in RHEL EUS Server v. 7.1

My understanding is following:
A system with redhat-release-server-7.2-9.el7 should be offered to be subscribed to:
* RHEL EUS Server v7.2 (AND RHEL EUS Server v. 7.3) if currently in RHEL Server v.7
* RHEL Server v.7 AND RHEL EUS Server v. 7.3 if currently in RHEL EUS Server v7.2
* RHEL Server v.7 AND RHEL EUS Server v. 7.3 AND RHEL EUS Server v7.2 if currently in RHEL EUS Server v. 7.1


Let's investigate the issue and clarify, if the expectations are incorrect.

The EUS-subscription-logic is based on two things:

* what does the redhat-release RPM *currently on the system* say the system 'is'?
* what base-channel is the system currently subscribed to?

The allowed base-channel changes should be as follows, for a system whose *redhat-release RPM* is X.Y (note that you can always change to any custom-base-channel)

* subscribed to BaseX?
 * can change to BaseX.max(N)

* subscribed to BaseX.n?
 * can change to any X.N, where N >= Y, or to RHEL BaseX
 * example: redhat-release says 7.2 EUS, 7.4 is max, subscribed to RHEL7.3 - can move to 7.[234]

* subscribed to custom channel?
 * can change to RHEL BaseX

Basically, the webUI logic is based around the assumption that going 'backwards' from the installed redhat-release RPM is likely to result in an unstable system, and doesn't allow it.

With RHEL7, the way version and release can be found from the redhat-release RPM changed in ways that broke the RHEL4/5/6 heuristics. The fix for https://bugzilla.redhat.com/show_bug.cgi?id=1282474 (q.v.) was incorrect/incomplete - but in a way that 'worked' for RHEL7.0, .1, and .2. It wasn't until 7.3 that the problem started to bite us.

(note error in #c5 - from custom, you should be able to get to "any X.N, where N >= Y, or to RHEL BaseX")

spacewalk.github:
dc92c9a008bbf2583d1b2b99e4ab592089eae56c

I look that I can't register system rhel7.0+ to EUS with parameter "--use-eus-channel" by rhnreg_ks.

function s.registration.available_eus_channels(username, password, server_arch, server_version, server_release) return empty result. I suppose that it can be problem of backend, not client. I need check it due to cdn mapping.

The RHEL6 works good.

Is it possible that this issue related with my problem?

(In reply to Pavel Studeník from comment #8)
> I look that I can't register system rhel7.0+ to EUS with parameter
> "--use-eus-channel" by rhnreg_ks.
> 
> function s.registration.available_eus_channels(username, password,
> server_arch, server_version, server_release) return empty result. I suppose
> that it can be problem of backend, not client. I need check it due to cdn
> mapping.
> 
> The RHEL6 works good.
> 
> Is it possible that this issue related with my problem?

This BZ is for the behavior on the web-ui side of things, which is the Java stack.

Registration is entirely in the python code - so even if there exists a 'rhel7-eus-registration' issue, it's a completely different codebase. Also, the issue we're talking about here only bites Sat5 in RHEL7.3+ - if you're having trouble registering to EUS with RHEL7.0/1/2, then Something Else went worng.

VERIFIED on spacewalk-java-2.3.8-165

Reproducer:
1. We have got satellite 5.7 with RHEL7 base channel and 7.1 EUS, 7.2 EUS and 7.3 EUS.
2. Create activation key for 7.1 EUS
3. We have got a client machine with RHEL7, register this client via AK.

4. downgrade redhat-release-server package to 7.0 version
> yum downgrade redhat-release-server-7.0-1.el7
> rhn-profile-sync
Open profile of client in WebUI and check to which versions of channels we can use.
  Base, 7.1 EUS, 7.2 EUS, 7.3 EUS

5. Upgrade redhat-release-server to newer version
> yum downgrade redhat-release-server-7.1-1.el7
> rhn-profile-sync
Reload page and we get 
  Base, 7.1 EUS, 7.2 EUS, 7.3 EUS

6. Upgrade redhat-release-server to newer version
> yum downgrade redhat-release-server-7.2-9.el7
> rhn-profile-sync
Reload page and we get 
  Base, 7.2 EUS, 7.3 EUS


7. Upgrade redhat-release-server to latest version
> yum downgrade redhat-release-server-7.3-7.el7
> rhn-profile-sync
Reload page and we get 
  Base, 7.3 EUS

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-2017:3085