How to share custom repositories across organizations

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Satellite 6 is strictly a multi-tenant application meaning that every organization gets its own subscription manifest and must select appropriate repositories and sync it. Although the design of Satellite 6 makes sure every single RPM package is downloaded only once across all organization, syncing metadata and publishing and promoting content within many organizations can be time consuming for some specific use cases. The following will work with Satellite 6.2 or newer.

One use case is a custom Yum repository with EPEL. This type of content can be easily shared across organizations in case there is a need to use latest and greatest EPEL content synced on a daily basis for example. In this case, the recommended way is to create a special organization which we will refer to under the name "SharedContent". It is recommended to give it unique and short label as it will be present in all repository URLs; a good candidate would be "shared".

Under SharedContent organization new Custom Product and Repository can be created, let's say EPEL product and EPEL7 repository. During creation, the Publish via HTTP option must be checked, or it can be enabled later on in the Repository detail page. For such a large repository like EPEL, it is recommended to use the on-demand download policy and also to customize Satellite 6 squid daemon configuration and cache volume size to handle a large cache .

After initial synchronization which usually takes longer, the key thing is to find out the URL where the content is being published to. This can be done in the Product - Repository detail page as Published At field. It will be something like:

http://sat6.host.lan/pulp/repos/shared/Library/custom/EPEL/EPEL7/

The same content is also available under HTTPS but to access content via SSL, a client certificate must be provided. One is available under Organization detail page and it's called Debug Certificate. It is possible to use it to consume the shared content if HTTP is not preferred.

To consume EPEL content, provisioning templates or puppet manifests need to be updated to use the custom repository. As an example, we will leave here a snippet for Anaconda RHEL kickstart. It is recommended to clone the original template and create a custom one associating it with all Operating Systems and setting it as default:

...
repo --name=epel --baseurl=http://sat6.host.lan/pulp/repos/shared/Library/custom/EPEL/EPEL7/
...

For HTTPS URL make sure to use --noverifyssl option or use post scriplet to deploy server certificate and yum configuration after installation when SSL server cert verification is a must.

Once everything is tested, Sync Plan can be created. It is also possible to create Content Environments or Content Views and leverage content promotion capabilities in the shared organization. That's how any custom repository can be easily shared.