Mirror On Sync

By unixsysadminRed Hat Satellite
Satellite

Mirror on sync is a feature that is available Red Hat Satellite (since version 6.2 if I remember correctly). The idea behind it is a simple one. From the Satellite 6.3 Content Management Guide:

Mirror on Sync – Ensures the content that is no longer part of the upstream repository is removed during synchronization. Leave this checked, which is the default.

Example

Let us look at a sample repository that always publishes the latest version of the packages. On week 1 it contains:

foo-2.7-1.x86_64.rpm
foo-server-2.7-1.x86_64.rpm
foo-client-2.7-1.x86_64.rpm
bazlib-5.6-1.i386.rpm

The following week, a new set of packages are released and the upstream repository replaces the foo packages:

foo-3.0-0.x86_64.rpm
foo-server-3.0-0.x86_64.rpm
foo-client-3.0-0.x86_64.rpm
bazlib-5.6-1.i386.rpm

For Satellite repositories that were created in 6.2 and later, Mirror on Sync is selected by default and will show in the Satellite UI as follows:

After the sync is performed, the repository will contain:
foo-3.0-0.x86_64.rpm
foo-server-3.0-0.x86_64.rpm
foo-client-3.0-0.x86_64.rpm
bazlib-5.6-1.i386.rpm

Depending on your use case, this may be ideal.

  • The repository contains the latest version of the packages
  • Any packages that may be published in error upstream and were downloaded to the satellite will be removed during a sync
  • Fewer packages for Satellite to manage should improve performance
  • Less space is consumed as only the latest packages are retained(*)

* Provided that the older packages are not part of an existing Content View or Composite Content View

When would you want to disable Mirror on Sync?

The Mirror on Sync feature was not available on earlier versions of Satellite and any repositories that were created would have been set with the flag set as ‘false’.  In the UI this shows as:

Following on from our example above, when a ‘mirror on sync = false’ repository is synchronised the old packages are retained on the Satellite server.  The repository would look as follows:

foo-2.7-1.x86_64.rpm
foo-3.0-0.x86_64.rpm
foo-server-2.7-1.x86_64.rpm
foo-server-3.0-0.x86_64.rpm
foo-client-2.7-1.x86_64.rpm
foo-client-3.0-0.x86_64.rpm
bazlib-5.6-1.i386.rpm

Although this approach takes up more space, the advantage is that you will always have a local copy of all RPMs. So, if for some reason you need to revert back to an old package such as foo-2.7-1.x86_64.rpm, it will be relatively easy to do so. In contrast to the ‘Mirror on sync’ option:

  • The repository contains all the versions of a package, allowing a client to consume older versions if they need to do so
  • If an RPM is published in error upstream and a sync was performed which fetched the RPM, it will be kept(*)
  • More space is consumed on the Satellite server

* As an example as to why this may cause issues, see Red Hat Bugzilla 1258686 – satellite 6.1.1 Content view filter erratum by Date and Type not excluding kernels

Download Policy

A related feature introduced in Satellite 6.7 allows for different default download policies for Red Hat and custom repositories. Bugzilla 1732056 – [RFE] custom repositories should default to immediate has some useful information on this.  Red Hat content hosted on the Content Distribution Network (CDN) tends to be ‘cumulative’, that is to say the packages are added to their repositories but never removed so you’ll see many versions of the same package in, say, the rhel-7-server-rpms or rhel-8-for-x86_64-baseos-rpms repos.  By using an ‘on demand’ download policy for these repositories we can save a significant amount of space on the Red Hat Satellite server without the worry that packages will be unavailable if they are ultimately needed (they can be taken from the CDN).  Other repositories such as EPEL, CentOS and Fedora tend to remove older packages as newer ones are released.  This could have bad consequences if a Content View specifically includes a version of a package due to a filter and that RPM is not downloaded when the View is created.  For this reason, third party repositories are set to ‘immediate’ download policy by default.  This has a drawback, for large repos such as EPEL you will end up consuming a lot of space on the Satellite server, which in turn can cause additional processing overhead when content is manipulated.  The positive: if you are relying on a specific version of a package, you will have an archived copy of it, even if it’s removed upstream and mirror on sync is set to false.

Multiple Package Versions – the client view

For a client, the default behaviour from yum is to install or display the most recent version of a package that is in the repository.  For example:

# yum search ssh-server
Loaded plugins: enabled_repos_upload, langpacks, package_upload, product-id, search-disabled-repos, subscription-manager
================================================ N/S matched: ssh-server ===============================================
openssh-server.x86_64 : An open source SSH server daemon

To identify the versions of a package that are available in a repository use the ‘show-duplicates’ option in yum:

# yum search ssh-server --show-duplicates
Loaded plugins: enabled_repos_upload, langpacks, package_upload, product-id, search-disabled-repos, subscription-manager
================================================ N/S matched: ssh-server ===============================================
openssh-server-6.4p1-8.el7.x86_64 : An open source SSH server daemon
openssh-server-6.6.1p1-11.el7.x86_64 : An open source SSH server daemon
openssh-server-6.6.1p1-12.el7_1.x86_64 : An open source SSH server daemon
openssh-server-6.6.1p1-22.el7.x86_64 : An open source SSH server daemon
openssh-server-6.6.1p1-23.el7_2.x86_64 : An open source SSH server daemon
openssh-server-6.6.1p1-25.el7_2.x86_64 : An open source SSH server daemon
openssh-server-6.6.1p1-31.el7.x86_64 : An open source SSH server daemon
openssh-server-6.6.1p1-33.el7_3.x86_64 : An open source SSH server daemon
openssh-server-6.6.1p1-35.el7_3.x86_64 : An open source SSH server daemon
openssh-server-7.4p1-11.el7.x86_64 : An open source SSH server daemon
openssh-server-7.4p1-12.el7_4.x86_64 : An open source SSH server daemon
openssh-server-7.4p1-13.el7_4.x86_64 : An open source SSH server daemon
openssh-server-7.4p1-16.el7.x86_64 : An open source SSH server daemon
openssh-server-7.4p1-16.el7.x86_64 : An open source SSH server daemon

Summary

The ‘mirror on sync’ feature is useful and can save time and space.  For enterprise environments the ability to install a package that has long been removed from an upstream repository can be very useful indeed (it’s 2am, you need to rebuild a server and you need that specific package from 7 years ago!).  So look at your requirements and select the option that works best for you.