PDA

View Full Version : SUMA 3.2 w/RHEL 7 Native Client - restrict minor version?



kamansmg
06-Nov-2019, 16:30
I have a SUSE Manager 3.2 installation and adding support for updating RHEL 7 Native clients.
I have the RHEL 7 client bootstrapped with the salt support ok and the RHEL 7 Server channels built and assigned.
The problem is that I need to restrict the minor version updates for RHEL (7.6, 7.7, ...) until the supported application is certified for that release level.

I tired using the recommended Red Hat tool "subscription-manager" to set the release version lock.
It works if I retrieve updates directly from Red Hat, but is ignored when getting updates through SUSE Manager.

Do I need to set up additional channels per minor release ?
Is there any other way to restrict updates to the next minor release level?

SUSE keeps it clear and simple with their SP level repos.

malcolmlewis
06-Nov-2019, 22:27
Hi and welcome to the Forum :)
Sounds like you need to setup staging to manage this. There was a session at SUSECon about this as well as some others here;
https://www.susecon.com/archive-2019.html

This was the one from memory: https://www.suse.com/media/presentation/CAS1317_Patching_at_Large_with_SUSE_Manager.pdf

strahil-nikolov-dxc
10-Nov-2019, 20:35
I have a SUSE Manager 3.2 installation and adding support for updating RHEL 7 Native clients.
I have the RHEL 7 client bootstrapped with the salt support ok and the RHEL 7 Server channels built and assigned.
The problem is that I need to restrict the minor version updates for RHEL (7.6, 7.7, ...) until the supported application is certified for that release level.

I tired using the recommended Red Hat tool "subscription-manager" to set the release version lock.
It works if I retrieve updates directly from Red Hat, but is ignored when getting updates through SUSE Manager.

Do I need to set up additional channels per minor release ?
Is there any other way to restrict updates to the next minor release level?

SUSE keeps it clear and simple with their SP level repos.

You can use the 'spacewalk-clone-by-date' utility to clone rhel channels upto a certain date.
For example, if /var/log/rhn/reposync/<your-channel>.log shows that a lot of packages were synced on 01.Nov.2019 , you can use '--to_date' with 2019-10-31 to create a clone that is locking to previous minor release.
Please provide feedback once you test it.

Note: '--channels=' can be used multiple times in the command.
For example , '--channels=base base-2019-10-31 --channels=child1 child1-2019-10-31 --channels=childN childN-2019-10-31' .

strahil-nikolov-dxc
10-Nov-2019, 21:00
Forgot to mention another approach 'spacewalk-create-channel'.

More info can be read at:
https://wiki.microfocus.com/index.php/SUSE_Manager/rhel-minor-version
https://access.redhat.com/solutions/696653

kamansmg
11-Nov-2019, 20:18
Hi and welcome to the Forum :)
Sounds like you need to setup staging to manage this. There was a session at SUSECon about this as well as some others here;
https://www.susecon.com/archive-2019.html

This was the one from memory: https://www.suse.com/media/presentation/CAS1317_Patching_at_Large_with_SUSE_Manager.pdf

Thanks for the suggestions. There is a wealth on information in the SUSECON site.
I do have staging set up from DEV, QA, and PROD but it currently includes all RHEL 7.x patches.

kamansmg
11-Nov-2019, 20:19
Forgot to mention another approach 'spacewalk-create-channel'.

More info can be read at:
https://wiki.microfocus.com/index.php/SUSE_Manager/rhel-minor-version
https://access.redhat.com/solutions/696653

Thank you for the suggestions. I may have to work with the 'spacewalk-clone-by-date' approach to get what I need.

strahil-nikolov-dxc
14-Nov-2019, 06:09
Thank you for the suggestions. I may have to work with the 'spacewalk-clone-by-date' approach to get what I need.

I have already done a presentation on that feature on Uyuni, so it definately will work on your SUMA. Keep in mind that the dates in 'https://access.redhat.com/articles/3078' is when the last package was synced to the channel - so it is safer to pick at least 5 days ahead of that.


Once the new parent (+ childs) are created, check the version of the kernel as a simple check if it really is version locked.

P.S.: Sadly, this approach does not work for CentOS, so the simplest way is to setup channel creation every day (maybe a script) and them delete all but last channel - so you will have a kind of 'to_date' .