A Fedora project Special Interest Group (SIG) builds and maintains a community-supported package repository called Extra Packages for Enterprise Linux (EPEL). EPEL versions align with major RHEL releases, and enable RHEL customers to run workloads with software dependencies that are not supported in RHEL. EPEL packages are not included in Red Hat support, but are equivalent to Fedora's level of quality. Typically, EPEL packages are built against RHEL releases.

CentOS Stream is the upstream project for RHEL. Development of the next RHEL version is open for community contributions that can directly influence the next release. Patches that are submitted to CentOS Stream are integrated faster to RHEL, to support significant changes during the current RHEL version lifecycle. CentOS Stream is a continuous integration and delivery distribution, with tested and stable nightly builds. You can download and install CentOS Stream for many use cases, including development and light production. CentOS Stream is not included in Red Hat support. Thus, do not mix CentOS Stream with RHEL repositories on the same system.

EPEL Next is an additional EPEL repository for package maintainers to build against CentOS Stream. This repository is useful when CentOS Stream contains an upcoming RHEL library rebase, or if an EPEL package has a minimum version build requirement that is already in CentOS Stream but not yet in RHEL. Use the EPEL Next repository on top of the regular EPEL repository. EPEL Next versions align with EPEL versions that might have CentOS Stream dependencies.

When you add custom and third-party content on Satellite Server, you can secure repositories that contain RPM packages and files by using GPG keys. Developers can use the RPM package format to introduce a signature of the header and payload, and as an administrator, you can verify with the GPG public key to ensure that the package comes from a valid and safe organization.

When you enable or configure a repository for a host, the repository public key is imported to that host. If you enable the gpgcheck parameter for that repository, then the host uses the public key to verify packages when they are downloaded to be installed.

For Red Hat repositories, Red Hat signs all the packages with the Red Hat private key. Satellite verifies all Red Hat packages against the Red Hat public key. You can locate the Red Hat public key in the /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release file. This key is used for most RHEL products.

Some vendors might have repositories to discover that they sign with their own key set. Then, the vendor signs the applications with their private key and make the public key available for download. If you make a custom repository to synchronize content from the vendor's repository, then you must add the vendor's repository public key to your new repository before packages start to load into the repository.

For your organization's software, you must use or create a key set. Typically, developers in an organization share the organization's signing keys, because a repository can have only one key. Thus, developers can use the same repositories to provide RPM packages, because they all use the same key set.

Satellite Server contains custom and third-party software packages in repositories, and you must associate those repositories with a product. Therefore, to use Satellite Server to host non-Red Hat content, you must first create the products. Creating products in Satellite Server requires administrative privileges.

To create a custom product, first choose the required organization and location from the main menu. Then, navigate to Content → Products and click Create Product.

Set values for the Name and Description fields. The value of Name acts as the identifier of the product. The Description field provides a human-friendly description of the repository names that the product includes. The Label field is automatically populated with the value of the Name field.

If all the repositories in the product use the same key, then you can use the GPG Key list to attach the GPG key at the product level. All the repositories in the product use the attached GPG key. If a repository on the product uses a different key, then you can override the product's public key by attaching the different key at the repository level, as explained later in this section. You must first import the key into Satellite Server to use it. Satellite uses the GPG key to validate the origin of the packages in the repository of the product, and it also uses the key when you install content in a host.

After you create a product, you can create the repositories within the product that you intend to group. Creating product repositories in Satellite Server requires administrative privileges.

To create a custom repository, navigate to Content → Products and click the product name to add a repository to. On the Repositories tab, click New Repository.

Set values for the Name and Description fields. The Label field is auto-populated from the Name field. Use the Description field to specify a human-friendly version of the repository name. Then, select the repository type in the Type list. Selecting a repository type enables additional fields under the Sync Settings section of the page. For example, if your custom repository will be a software package repository, then select yum from the Type field. The parameters in the enabled additional section control the custom repository synchronization with the upstream repository.

If you select the yum repository type, then you can select a GPG key from the GPG Key list. This GPG key overrides the product-level GPG key, and Satellite uses it to verify the RPM packages only for this repository.

Figure 5.1: Create repository for a custom product

The following table describes some common parameters in the additional fields after selecting the repository type:

Typically, you add packages to a custom repository during its initial creation; you can also add them later. Adding packages to custom product repositories in Satellite Server requires administrative privileges.

To add packages to a repository, first choose the required organization and location from the main menu. Then, navigate to Content → Products and click the product name to add packages to. On the Repositories tab, click the repository name to display the details of the repository. In the Upload Package section, click Browse to select the locally available packages, and click Open to mark the packages for uploading to the repository. Click Upload.

In the Content Counts section, the Content Type table displays the number of packages in the repository. To view the packages in the repository, click the number that corresponds to the package count, to open the Packages page of the repository.

You require administrative privileges to remove packages from product repositories.

To remove repository packages, navigate to the Packages page of the custom product repository. Select the checkbox for the package to remove, and click Remove Packages.