Patch Management / Copy all of Satellite Content ISO images
Satellite 6.10
RedHat 7.9
Subscription Allocation > New Subscription Allocation >
(name: xxx, type: Satellite 6.10) > Subscriptions > Add Subscriptions
Options are:
1) Red Hat Beta Access
2) Red Hat Enterprise Linux Server with Smart Management + Satellite, Standard, Confirmed Stateside Support (Physical or Virtual Nodes)
3) Red Hat Enterprise Linux Server with Smart Management + Satellite, Standard, Confirmed Stateside Support (Physical or Virtual Nodes)
4) Red Hat Satellite Infrastructure Subscription
Which one would I have to select to create a manifest for patching RedHat servers? I'm assuming 2 or 3... or should it be 4?
Correct me if I'm wrong but after that, you load the manifest into your RedHat Satellite and will receive available updates and patches correct?
Responses
Dennis,
Satellite does more than just provide updates and patches. It also manages subscriptions. So when creating a manifest, you need to load ALL the subscriptions that will be needed by the servers connecting to your Satellite.
Once your manifest is created, and is loaded to your Satellite, your other servers or workstations will need to be registered with your Satellite. Once a server or workstation is registered, and if it can use a subscription, it will then contact your Satellite server for all of its available updates and patches.
Obviously, you still need to set up a schedule for downloading the patches to your Satellite, as well as configure content views, but this lets your systems talk to your Satellite for patches and subscription info instead of talking directly to the Red Hat Network.
Frank
Guru
20879 points
Hi Dennis,
See Franks' good info above.
- Also, Please examine the Red Hat Content Management guide at their documentation site
- Also, please see paragraph 4.1 of the guide too.
Are you using a "connected" (to Red Hat) Satellite or a "disconnected" (not-connected to public-Internet, not connected to Red Hat) satellite???
We use activation keys for our servers and workstations, and we make a separate activation key for server and workstation to make registration smoother and to make standardization of adding specific repositories to the right type of system smoother.
To receive updates into a public-facing (connected, connected-to-Red-Hat) satellite, you will want to set up a synchronization plan. The Content Management documentation describes this and updating your content views which are all separate tasks.
Kind Regards,
RJ
Guru
20879 points
Dennis, you probably have read the instructions for Disconnected installation. Regarding ISOs, I used to use ISOs for years until I found a tremendously easier ways, namely "content view export".
As one who spent many years dealing with ISO files, I seriously highly recommend considering this method (content view export) https://access.redhat.com/articles/2390791 SEE THE VIDEO AT THAT RED HAT LINK because it is tremendously easier. THAT VIDEO IS KINDA OLD, HOWEVER, IT DESCRIBES THE PROCESS USEFULLY
With a "disconnected Satellite" you will have to bring the Red Hat repos in some way to your "disconnected" Satellite. Your disconnected Satellite will obviously not be able to reach Red Hat and acquire your repositories you require. That's where you have at minimum two choices, FIRST: download a bunch of iso files (very annoying) and ingest them in the proper order or SECOND (and better, trust me, I've been doing this for over a decade) a Content View Export.
A Content View Export is done with a satellite that FACES the public Internet and it acquires the repos from Red Hat CDN servers. This process is described in the Red Hat documentation "Content View Management" Chapter 8 here. There are some crucial steps in that chapter, such as setting the download type to IMMEDIATE, that's vital..
To do a content-view export, you have one satellite facing the public Internet where you do the content view export (after a good synchronization from Red Hat).
NOT LISTED IN THE DOCUMENTATION are a few things I've learned that must be done occasionally on a recurring basis.
- Before a sync, I often do a refresh of the manifest on the public-facing Satellite, ESPECIALLY if you get bad synchronizations on numerous Red Hat repositories! Doing this on failed repo sync fixes that so many times, it's very important.
- Have at minimum one-terabyte for the place you export the data to (that's MINIMUM, I recommend double or more). I'm speaking from a lot of experience in maintaining a lot of satellites, it is best not to skimp on storage for your public facing satellite where you do a content-view export.
- AFTER THE EXPORT - you can reduce the footprint of size of data from the resulting content-view export from (in my case) 1TB to about 350GB or less (again, in my case, and my set of repositories). This is done with
hardlink -cvv /var/export/name_of_org_blah_blah.1.0(the name will be different, I'm typing this from memory, It will start with your org name). - Look at the man(ual) page for the
hardlinkcommand, the command is literallyhardlinkand it does a de-duplication of rpms across a file system. Various repositories have the IDENTICAL rpm and you can reduce your footprint of data from 1TB content view export to about 350G (in my case). - IT IS vital after the hardlink -cvv command -- when you do an rsync to have "rsync -Hau --progress /var/export/name_of_org_blah_blah.1.0 /mnt/2tb_external_fast_ssd_xfs_drive/`
- RECOMMEND a tmux session for the above command so if your client system gets disconnected/rebooted, you do not lose the session.
- WITHOUT the "-H" above, your rsync WILL EXPAND out to it's original drive.
- RECOMMEND USING XFS and not a windows-formatted ssd drive. rsync works better on xfs than ntfs external drive.
Each time you rsync your data, do not forget the "-H" or it will expand your 300GB to the original footprint.
You can do iso files, but it's annoying. Ever since Content View Exports came along, I've stopped doing ISO files.
Regards,
RJ
Guru
20879 points
Please always use the most current edition of Satellite. So if by the time you are reading this, and they release 6.10.7 - please use that - whatever is current as of when/what day you are reading this.
Regarding your next question, please put in a case with Red Hat and let us know how it goes. I put in a case, and as I put in a case, it gave me this article https://access.redhat.com/articles/6454191, look first for the instances of "6.10" and then examine for other things to see if the lengthy list of solutions they offer there offer any help or not. Not sure if this is an issue for you.
If I get a response from my ticket I'll post here, if you get a response from your ticket, please let us know here too.
Thanks/Regards,
RJ
Guru
20879 points
Also see this https://www.youtube.com/watch?v=VgxDtQvIaaM
Also see this https://www.youtube.com/watch?v=hX2eSzg6ss8 which I mentioned above from Rich Jerrido's article here https://access.redhat.com/articles/2390791
Guru
20879 points
Dennis,
Red Hat responded to my ticket.
For satellite 6.10, you need to have both your connected satellite where you acquire updates from Red Hat and do content views AND your disconnected Satellite to be both version 6.10 due to the changes of pulp 2 going to pulp3.
So all of your Satellite servers would need to be at 6.10. I'd highly recommend building or UPDATING your satellites to 6.10
YOU CAN UPDATE your Satellites to 6.10 with the guidance of this Red Hat upgrade helper https://access.redhat.com/labs/satelliteupgradehelper/ Please look at that Red Hat "application".
IMPORTANT NOTE: ANY UPGRADES - FROM another Red Hat Accelerator member - Thanks RenaissanceRick
One very strong cautionary note for that...make sure you are upgraded to Satellite 6.9.9 before trying the upgrade. There were bugs found in the upgrade process, and they are fixed in 6.9.9.
ANOTHER IMPORTANT NOTE: from another Red Hat Accelerator member - Thanks Jason B
And have an eye out for disk space. You will need double the diskspace for the migration from Pulp 2 to Pulp 3. Should be all in the docs though
Kind Regards,
RJ
Guru
20879 points
Dennis,
I put in a ticket (and mentioned above) that the issue with pulp3 is taking a content view from 6.9.x or lower which uses pulp2 to - Satellite version 6.10.x (regardless of 6.10.5 or 6.10.6) which uses 6.10.3.
However, going from a minor-point release of 6.10.5 to 6.10.6 is not affected because they both use pulp3. The issue and warning from Red Hat is taking a content-view from something earlier like 6.9.x or below to Satellite 6.10.x because anything earlier than 6.10.x is using pulp2. Going from 6.10.5 to a higher version to Satellite 6.10.x doesn't fit the problem Red Hat warned of (regardless of the minor-point version) because both still uses pulp3.
You can safely carry a content view export from a Satellite 6.10.5 system to Satellite 6.10.6 - but I invite you to take your concern if you do not trust my answer to a ticket with Red Hat and ask them this directly. I've been doing Red Hat Satellite for some years, and I believe when they say the concern is going from a lower-version satellite earlier than 6.10 (like I said, 6.9.x or below) to Satellite 6.10.X THAT is the concern scenario where you would be in a situation where you'd be taking a content view created with pulp2 to a satellite with pulp3 (Satellite 6.10) and that would fit the problem.
Again, going from 6.10.5 or lower than 5 to 6.10.6 both will use pulp3 and avoid that problem because there is no pulp2 involved in the content-view export with 6.10.x.
Regards,
RJ
Guru
20879 points
Hi Dennis,
Regarding your question of the Red Hat Satellite Content ISOs. The ISO file purpose and method for importing content from Red Hat through ISO files, and this is covered in the Red Hat Content Guide, Appendix E.
You asked what the Satellite Content ISOS are... Here's the answer. With a Disconnected Satellite, you need to bring the Red Hat content to that Disconnected satellite. I explained what a Disconnected satellite is previously, a Disconnected satellite can not acquire updates from Red Hat, and that's why they call it a Disconnected satellite. So there are two methods to get Red Hat content (repositories) to a disconnected satellite, the way I recommended previously in other posts/replies, and the ISO files you mentioned and the link above which explains how to ingest repositories (content) in ISO form.
You asked why there are so many. In the case of RHEL 7, you're bringing ALL the content from RHEL 7.0 to 7.9 - so that's a lot. With RHEL 8, you're bringing everything from RHEL 8.0 to 8.6 (as I type this). so that's a lot too. Now there's RHEL 9, and there's other content too. Your choice, download and bring all the ISOS for all repos or do a content view export and be done with it.
If you remember nothing else, remember this: every time, guaranteed without fail, always ALWAYS validate the SHA-256 sum for EVERY SINGLE ISO FILE or you will RUIN your repository (ask me how I know).
As very annoying as the ISO method is, it may be a good stop-gap method for a while until you can establish a more sustainable method such as content-view exports.
Did you see the youtube videos on content management with a content view export I provided?
Kind Regards,
RJ