How can we regularly update a disconnected system (A system without internet connection)?
Environment
- Red Hat Enterprise Linux (without internet connectivity)
- Red Hat Network (RHN)
- Red Hat Subscription Manager (RHSM)
- Red Hat Network Satellite
Issue
- How can a system without internet connection regularly be updated?
- Is there a way to automate the checking for and installation of new updates?
- How can offline installation/upgrade of packages be performed without connecting to RHN?
- Is it possible to get a list of packages to be updated on system with no internet connection?
- How to patch the 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: https://www.redhat.com/red_hat_network/ . Please also refer to the document Update a Disconnected Red Hat Network Satellite.
- 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 has the same packages installed (the same package profile)
- 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 more details refer to:
- Need to set up yum repository for locally-mounted DVD on Red Hat Enterprise Linux 5
- Need to set up yum repository for locally-mounted DVD on Red Hat Enterprise Linux 6
-
Need to set up yum repository for locally-mounted DVD on Red Hat Enterprise Linux 7
-
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. 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.
- Pros:
- Automation 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 new system is required for each architecture / major version of RHEL (such as 6.x)
- Clients can not version lock to a minor version using a local repository. The repository must version lock before the reposync to collect only the specified version packages.
- Clients will not see any new updates until the local repository runs
reposyncandcreaterepo --updateto download new packages and create new metadata- The clients will likely have to run
yum clean allto clear out old metadata and collect the new repo metadata
- The clients will likely have to run
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 How to update security Erratas on system which is not connected to internet ? knowledgebase.
Root Cause
Without a connection to the RHN/RHSM the updates have to be transferred over other paths. These are partly hard to implement and automate.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
