Description of problem: For a system subscribed to RHEL 7.2 EUS channel, "Alter Channel Subscription" does not list RHEL 7.3 EUS channel as a available channel. The only option displayed is RHEL 7 Server base channel. Version-Release number of selected component (if applicable): Satellite v 5.7 How reproducible: Always Steps to Reproduce: 1. Install RHEL 7.2 system (redhat-release-server package v 7.2 should be installed on the system) 2. Sync RHEL 7.2 EUS and 7.3 EUS channels on satellite server. 3. Register the system using rhn_register and associate RHEL 7.2 EUS base channel 4. From webui try to change the base channel to RHEL 7.3 EUS Actual results: RHEL 7.3 EUS channels is not available on "Alter Channel Subscription" other than RHEL 7 base Server channel Expected results: RHEL 7.3 EUS channels should be available on "Alter Channel Subscription" along with RHEL 7 Server base channel. Additional info:
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