How can we update a disconnected or an air-gapped system (A system without internet connection)?

Resolution

Depending on the environment and circumstances, there are different approaches for updating an offline system.

Approach 1: Red Hat Satellite

For this approach a Red Hat Satellite server is deployed. The Satellite receives the latest packages from Red Hat repositories. Client systems connect to the Satellite and install updates. More details on Red Hat Satellite are available here: The best way to manage your Red Hat infrastructure .

• Pros:
  • Installation of updates can be automated.
  • Completely supported solution.
  • Provides selective granualarity regarding which updates get made available and installed
  • Satellite can provide repositories for different major versions of Red Hat products
• Cons:
  • Purchase of Satellite subscription required, setup and maintenance of the Satellite server.

Approach 2: Download the updates on a connected system

If a second, similar system exists

• which is the same Product variant (Workstation for Workstation) and Major release (RHEL 7 for RHEL 7)
• and if this second system can be activated/connected to the RHN

then the second system can download applicable errata packages. After downloading the errata packages can be applied to other systems. More documentation: How to update offline RHEL server without network connection to Red Hat Network/Proxy/Satellite?.

• Pros:
  • No additional server required.
• Cons:
  • Updating procedure is hard to automate, will probably be performed manually each time.
  • A new system is required for each architecture / major version of RHEL (such as 6.x)

Approach 3: Update with new minor release media

DVD media of new RHEL minor releases (i.e. RHEL6.1) are available from RHN. These media images can directly on the system be used for updating, or offered i.e. via http and be used from other systems as a yum repository for updating. For details, please refer to the kbase solutions with detailed instructions, which are specific to the various RHEL major versions: for RHEL5, for RHEL6, for RHEL7, for RHEL8 and for RHEL9

• Pros:
  • No additional server required.
• Cons:
  • Updates are restricted to updated packages that are part of the minor releases. Erratas released after the minor release becomes available will be contained in the next minor release.
  • Fetching the update media and updating the systems is difficult to automate.
  • The media only contains the base RHEL packages. They do not contain packages from the optional repository. This prevents the bundled download of the packages from these these channels as media image.

Approach 4: Manually downloading and installing or updating packages

It is possible to download and install errata packages. For details refer to this document: How do I download security RPMs using the Red Hat Errata Website? .

• Pros:
  • No additional server required.
• Cons:
  • Consumes a lot of time.
  • Difficult to automate.
  • Dependency resolution can become very complicated and time consuming.

Approach 5: Create a Local Repository

This approach is applicable to RHEL 5/6/7/8/9. With a registered server that is connected to Red Hat repositories, and is the same Major version. The connected system can use reposync to download all the rpms from a specified repository into a local directory. Then using http,nfs,ftp,or targeting a local directory (file://) this can be configured as a repository which yum can use to install packages and resolve dependencies.

How to create a local mirror of the latest update for Red Hat Enterprise Linux 5-9 without using Satellite server?

• Pros:
  • Automation is possible.
  • For Development and testing environments, this allows a static (unchanging) repository for the Dev systems to verify updates before the Prod systems update.
• Cons:
  • Advanced features that Satellite provides are not available in this approach.
  • Does not provide selective granularity as to which errata get made available and installed.
  • A distinct system is required for each architecture / major version of RHEL (such as 6.x)
  • The clients can not version lock to a minor version using a local repository. The repository server must version lock before the reposync to collect only the specified version packages.
  • The clients will not see any new updates until the local repository runs reposync -n to download new packages and for RHEL 6 & 7 createrepo --update to create new metadata. The createrepo command should be avoided on RHEL 8 normally for createrepo_c version lower than 0.16.2-1.el8. The known issues it causes can be solved at How to add the modules information after cloning the RHEL8 repository
  • The clients must run yum clean all to clear out old metadata and collect the new repo metadata after any changes in reposync metadata.

Checking the security erratas :-

To check the security erratas on the system that is not connected to the internet, download the copy the updateinfo.xml.gz file from the identical registered system. The detailed steps can be checked in the link shared in Approach 5