Patch Management / Copy all of Satellite Content ISO images

Latest response

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

Hi Dennis,

See Franks' good info above.

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

Setting it up as "disconnected" .. airgap solution but haven't figured it all out yet.

Makes sense..

In a disconnected environment:

In the upper left of the window, click Downloads and select Red Hat Satellite. Click the Content ISOs tab. This page lists all the products that are available in your subscription. Click the link for the product name, such as Red Hat Enterprise Linux 7 Server (x86_64) to download the ISO image. Copy all of Satellite Content ISO images

There are around 40 Base Satellite Content ISO's, totaling to around 180GB. Trying to understand why all of the ISO's have to be downloaded. What's the specific reason having all ISOs>

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 hardlink command, the command is literally hardlink and 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

That's what I'm looking for.

The description says that Satellite 6.10 and 6.9 (and below) are incompatible for export and import due to different Pulp versions. Would Satellite 6.10.5.1 work for this scenario of two satellite servers (disconnect and connect) ?

The next version is 6.10.6 that seems to be the latest.

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

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

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

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