Creating minimal, standalone YUM update repositories (for disconnected systems)

Latest response

We already know how to use reposync (or even pulp) to create standalone, disconnected YUM repositories. E.g., Solution [23016] for instance.

But what we're looking for is to feed a subset( of RPM packages, and only build a minimal, standalone, disconnected YUM repository with only those RPM packages (such as updates), and their dependencies, and *nothing else. This is both for "size" and "control" considerations. I.e., we neither want to cut 100s of GiBs for RHEL4+5+6+7 i386+x86-64 nor want our remote sites installing new software that wasn't already installed. Again, these are disconnected (or even "airgap") sites with no Internet, and usually running from one-way (or read-only) media.

What I would like to know is if there is a deterministic tool do to this directly. E.g., some past solutions I've tried include ...
- Build up 1 example system of each release/arch, run "yum upgrade," then scrap the packages out of /var/cache/yum/, and then run createrepo on
- Script, use a package dependency tool, to resolve and give a RPM list, which we then run createrepo on

And if not, should I just create a YUM Python (and, eventually DNF) plug-in that createrepo can use? I'm thinking that's where I'm headed, because I'm creating a lot of one-off scripts, nothing sustained and long-term usable.

I know I'm not the only one who has run into this, and there are always customers I've had who want just the minimal YUM repo to update packages, and not allow their customers to install any, additional software -- especially for updates, especially when the systems are on a private, disconnected (or even "airgap") network.

-- bjs

[23016] https://access.redhat.com/solutions/23016

Responses

Hello Bryan

For Red Hat Satellite 6.2 there will be a --since option for the the hammer repository export command. The command can be used for exporting repositories or Content Views. It uses the time stamp when you last synced your Satellite Server, not when the package was added to the repo, so some thought and planning is required. The command is not documented yet but will appear here soon: Synchronizing Content Between Satellite Servers.

Stephen --

Exporting a Content View with Package/Errata Filters would be extremely helpful. Thank you for the Satellite 6.2 Beta reference [Sat62ISS]. Furthermore, this begs the question ... we have not only Satellite 5.7 and Satellite 6.1, but we're also using the Upstream components for Satellite 6 as well. Is this functionality already in Hammer/Pulp/etc...? Or is this being added as part of Red Hat's downstream fork in the eventual Satellite 6.2 release?

I.e., internally (in our lab), we're already using the Upstream components, but for our customer, we're using Satellite 6. That way we're ahead of the curve.

Also, I've been using [mock] and have setup RHEL3-7 i386/x86_64 configuration files that build chroot environments. This might be my temporary solution, as mock works well to resolve dependencies, and I can feed it DVDs and YUM repos as well. Not ideal, but it will at least give me the package list, while not having to install every release as a VM, and then each chroot can still be used to create it's repo.

Red Hat Support also passed on Solution [55654], which removes the need to have to create the repo too, although mock uses the host YUM (instead of the chroot release YUM), so I'll still have to do some more hacking on this.

-- bjs

[Sat62ISS] Satellite 6.2 Beta Content Management Guide - "Appendix C. Synchronizing Content Between Satellite Servers" - https://access.redhat.com/documentation/en/red-hat-satellite/version-6.2-beta/content-management-guide/#Using_ISS

[mock] 'Using Mock to test package builds' - https://fedoraproject.org/wiki/Mock

[55654] 'How to update security Erratas on system which is not connected to internet ?' - https://access.redhat.com/solutions/55654

EDIT: Corrected Solution Number and Link

Hello Bryan

I cannot answer about the upstream support, there are mailing lists where you could ask, but a quick way to see if the --since option is supported in the version of hammer you are testing is to view the usage statement on a test system:

# hammer repository export -h

Do you see --since SINCE Optional date of last export ?

BTW, I think you have a typo in the last para, the solution number you entered is this solution.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.