How can we regularly update a disconnected system (A system without internet connection)?

Solution Verified - Updated -


  • Red Hat Enterprise Linux (without internet connectivity)
  • Red Hat Network (RHN)
  • Red Hat Subscription Manager (RHSM)
  • Red Hat Network Satellite


  • 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 ?


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 more details refer to:

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. 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 without using Satellite server?

  • 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 reposync and createrepo --update to download new packages and create new metadata
      • The clients will likely have to run yum clean all to clear out old metadata and collect the new repo 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 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.


"Approach 3: update with new minor release media" will not work with RHEL 6.  Many packages (over 1500) in the "optional" channels simply are not present on any iso images.  There is an open case, but the issue will not be addressed before RHEL 6 Update 4 (and possibly never).

I agree with "Randy Zager" "optional" packages should be available offline along with other channels which are not available in ISO's.

Can Approach 5 "additional server, reposync fetching" be applied with RHEL 7 servers?

Yes. You need to:
- subscribe server to RH 
- synchronize repositories with reposync util
- up to 40GB per major release of RHEL.

However, won't I need to stand up another RHEL 7 server in additional to the RHEL 6 server?

Correct. When using an external server to reposync updates, you will need one system for each Major Version of RHEL that you want to sync packages from.

RHEL 7 does not have access to RHEL 6 repositories just as RHEL 6 can't access RHEL 7 repositories

what I am looking for is the instructions on the reposync install AND how to update off line clients

do I have to manually install apache?

You will need: a RH Satellite or RH Proxy server, an internal yum server, and a RHN client for each OS variant (and architecture) you intend to support "offline". E.g. supporting 6Server, 6Client, and 6Workstation for i686 and x86_64 would normally require 6 RHN clients, but only three RHN clients would be necessary for RHEL7, as there's no support for i686 architecture

Yum clients can (according to the docs) use nfs resource paths in the baseurl statement, so apache is not strictly necessary on your yum server, but most people do it that way...

Each RHN client will need: local storage to store packages downloaded via reposync (e.g. "reposync -d -g -l -n -t -p /my/storage --repoid=rhel-i686-workstation-optional-6"). You'll need to run "createrepo" on each repository that gets updated, and you'll need to create an rsync service that provides access to each clients' /my/storage volume

Your internal yum server will need a cron script to run rsync against your RHN clients so you can collect all these software channels in one spot.

You'll also need to create custom yum repo files for your client systems (e.g. redhat-6Workstation.repo) that will point to the correct repositories on your yum server.

I'd recommend you NOT run these cron scripts during normal business hours... your sys-admins will want a stable copy so they can clone things for other offline networks.

If you're clever, you can convince one RHN client system to impersonate the different OS variants, reducing the number of systems you need to deploy.

You'll also most likely want to run "hardlink" on your yum server pretty regularly as there's lots of redundant packages across each OS variant.

While logged in, I can't access (Update a Disconnected Red Hat Network Satellite). I get "access denied".

Could you add link to to Approach 2 and 5? Using container make possible consolidating RHEL 6, 7, 8 reposync processes into one server.

Kazuo, this is a good detail. Thanks.

I'm curious why number 5 from above, "Create a Local Repository" isn't applicable to RHEL8? Does AppStream somehow break the ability to reposync or createrepo?

It actually does work for RHEL 8. I had not noticed this and will have that updated shortly. The steps for RHEL 8 are slightly different but are noted in the 23016 solution.

What type of automation You mean when it comes to Approach 5? Could You give some examples?

That is especially in contrast to Approach 4, "manual download" requires much work by hand, downloading to desktop with a browser and then distributing to the "to be patched system(s)". Approach 5 can for example via daily cronjob run reposync to fetch down the newest erratas. Also rsync or such could be used to distribute a downsynced repository to multiple other systems in the intranet - that allows also to choose times for that transfer when the network is not loaded with other things.