RH403 - ch05s05

Bookmark this page

Administer Custom Products and Repositories

Objectives

Update custom products and repositories and use content views to make them available to hosts.

Synchronize Custom and Third-party Software Repositories

Similarly to Red Hat content products and repositories, you can manually synchronize or associate an existing sync plan with the products and repositories of custom and third-party software for automated, routine synchronization. If the intended sync plans exist, then you can select them when creating custom and third-party products and repositories.

It is optional to specify a URL for the source repository while you are creating a repository. When no source repository is specified, the repository becomes an independent, stand-alone repository. Even though the controls for synchronization are still available for stand-alone repositories, any attempt to synchronize fails due to the absence of a synchronization source.

Note

Custom and third-party repositories are unaffected after enabling the Simple Content Access feature on Red Hat Satellite. Custom repositories are enabled by default on the content hosts.

Manage Subscriptions to non-Red Hat Products and Repositories

When you create a non-Red Hat product, a corresponding subscription automatically appears under Content → Subscriptions. Because subscriptions control the content that hosts can access, you must add the chosen subscriptions to a custom product. The subscriptions are then assigned to a host profile before the host can access its contents.

Enable Host Subscription to Custom Repositories

To activate a subscription for a host, add the subscription to a host profile on Satellite Server on a per-host basis.

To enable host subscription to a custom repository:

In the Satellite web UI, choose the required organization and location from the main menu, and then click Hosts → Content Hosts, and click the name of the intended host.
Click the Subscriptions tab, and then click the Add tab, and select the checkbox next to the chosen subscription for the host.
Click Add Selected to add the subscription.
Click the Product Content tab, and then click the pencil icon to change the Enabled by Default setting for the repositories in the new product.
Select the required enable setting from the menu and then click Save.

Enable Activation Key Subscription to Custom Repositories

An alternative to adding subscriptions to host profiles is to add subscriptions to activation keys so that hosts that are registered with the activation key automatically inherit the subscription.

To enable activation key subscription to a custom repository:

In the Satellite web UI, choose the required organization and location from the main menu, and then click Content → Activation Keys.
Click the name of the activation key that you want to add the subscription to.
Click the Subscriptions tab, and then click the Add tab.
Select the checkbox next to the chosen subscription, and then click Add Selected.
On the Product Content tab, click the edit icon to change the Enabled by Default setting for the repositories in the new product.
Select the required configuration from the menu, and then click Save.

Secure RPM Packages with GPG Keys

A GnuPG (GPG) key can encrypt and sign files to protect privacy or to verify the authenticity of the issuer of the file. Red Hat repositories are configured to use GPG to maintain the integrity of the packages. Red Hat Satellite supports the use of GPG keys to secure custom products and repositories.

When you create non-Red Hat products and repositories, you can specify a GPG public key to associate it with the repository's RPM files. The repository configuration on the managed hosts has the gpgcheck option set to enabled only if you specify a GPG key.

Satellite Server makes the GPG public key available to hosts, which then use the key to verify the origin and integrity of packages during package installation. Packages in a repository that are specified with a GPG key pair must be signed with the correct GPG private key so they can be loaded to that repository.

If you configure a GPG key pair on a product, then all repositories within that product use the same GPG public key. Additionally, a GPG key pair that is configured on a repository for a product overrides the GPG key pair that is configured for the product.

Manage GPG Keys in Satellite

You can associate a GPG key when you create a product or repository, provided that the GPG key is already imported into Satellite. To import a GPG key into Satellite, follow these steps:

Ensure that the correct organization context is set for this task.
Click Content → Content Credentials.
In the Content Credentials page, click Create Content Credentials.
Set a name for the content credential and select GPG Key as the value of the Type field.
Click Browse to upload the GPG key file or paste the content of the GPG key file into the Content Credential Contents field, and click Save.

If the custom repository contains content that is signed by multiple GPG keys, then you must import all required GPG keys in the same Content Credential Contents entry.

After the GPG key is imported, a page is loaded with the summary of the key. In this page, you can see the number of products and repositories that are associated with this key. You require administrative privileges to add or remove GPG keys in a product or repository. The Satellite web UI displays these GPG keys as content credentials.

Important

If you create a custom repository with no key and add unsigned packages to it, then you cannot associate a GPG key to the repository later. In this scenario, you must create a new repository and associate the key before adding packages.

To remove or modify a GPG key, follow these steps:

Navigate to Content → Content Credentials and select the GPG key.
To modify GPG key attributes, click the pencil icon next to the Content field and replace the content of the GPG key. Alternatively, click Browse and select the file with the new GPG key.
To remove the GPG key, click Remove Content Credential in the upper-right corner of the page.

Digitally Sign the RPM Packages

RPM packages are normally digitally signed so that you can verify that a package came from the declared source. This signature can be verified to block forged packages from being installed if a DNF repository is compromised. The following steps explain how to create a signing key.

Install the supporting RPM packages.

[user@host ~]$ sudo dnf install rpm-sign
...output omitted...

Generate a GPG key for the user account that manages RPMs.

Important

Generating enough entropy to create the keys can cause the gpg utility to hang while waiting for completion. To avoid this issue, you can use the rngd -r /dev/urandom command before generating the GPG keys.

You must have a graphical session open to run gpg --full-generate-key. It uses a graphical box to accept your input for the passphrase.

[user@host ~]$ sudo rngd -r /dev/urandom
Initializing available sources
Initializing entropy source hwrng
Enabling RDSEED rng support
Initializing entropy source rdrand
Initializing AES buffer
Enabling JITTER rng support
Initializing entropy source jitter
[user@host ~]$ gpg --full-generate-key
gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory '/home/user/.gnupg' created
gpg: keybox '/home/user/.gnupg/pubring.kbx' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
  (14) Existing key from card
Your selection? Enter
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) Enter
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) Enter
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: user
Email address: user@host.lab.example.com
Comment: Enter
You selected this USER-ID:
    "user <user@host.lab.example.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key 3F75CCFC7A079E92 marked as ultimately trusted
gpg: directory '/home/user/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/user/.gnupg/openpgp-revocs.d/7D39000BEA3EB3F9D33E7D313F75CCFC7A079E92.rev'
public and secret key created and signed.

pub   rsa2048 2022-05-31 [SC]
      7D39000BEA3EB3F9D33E7D313F75CCFC7A079E92
uid                      user <user@host.lab.example.com>
sub   rsa2048 2022-05-31 [E]

Find the username and email address from the output of gpg --full-generate-key, or with the gpg --fingerprint command, and then export the public key into an ASCII encoded file.

[user@host ~]$ gpg --fingerprint
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/home/user/.gnupg/pubring.kbx
------------------------
pub   rsa2048 2022-05-31 [SC]
      7D39 000B EA3E B3F9 D33E  7D31 3F75 CCFC 7A07 9E92
uid           [ultimate] user <user@host.lab.example.com>
sub   rsa2048 2022-05-31 [E]

Export an ASCII encoded version of the public key to publish to client machines so that they can verify RPM packages that are signed with the private key.

[user@host ~]$ gpg --armor \
--export user@host.lab.example.com > /tmp/DEMO-GPG-KEY

Instead of creating a new GPG key pair, you can import an existing key pair on a file with the gpg --import command. You need the passphrase to import that key pair.

[user@host ~]$ gpg --import file.asc
gpg: key 3F75CCFC7A079E92: "user <user@host.lab.example.com>" not changed
gpg: key 3F75CCFC7A079E92: secret key imported
gpg: Total number processed: 1
gpg:              unchanged: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

Individual users can override selected system-wide macros by creating the ~/.rpmmacros file in their home directory. By adding your key's username and email address to this file, the rpm and rpmbuild commands can scan the ~/.rpmmacros file for the value of the %_gpg_name macro and use that key to sign RPM packages. Instead of using the key's username and email address, you can also use the GPG key ID, such as A7A051123, the GPG pub key ID, such as 7D39000BEA3EB3F9D33E7D313F75CCFC7A079E92, or the email address.
Create or modify ~/.rpmmacros so that %_gpg_name is set to the username and email address of the previously created key. For example:
```
[user@host ~]$ echo '%_gpg_name user user@host.lab.example.com' >> ~/.rpmmacros
```

You can now sign packages by using this new GPG key.

[user@host ~]$ rpmsign --addsign rpm_file_name.rpm

You can check the signature for a package.

[user@host ~]$ rpm --checksig rpm_file_name.rpm
rpm_file_name.rpm: size pgp md5 OK

Synchronize the EPEL Repository

The Extra Packages for Enterprise Linux (EPEL) repository is a collection of add-on packages for use on enterprise Linux distributions. The Fedora project distributes the EPEL repository. Although Red Hat does not support the EPEL repository, system administrators commonly use it, because it follows strict packaging guidelines, and a broad community backs it.

Because the EPEL repository includes the upstream version for the packages, syncing and using the full EPEL repository can conflict with the packages from Red Hat. For this reason, select only the appropriate packages, rather than the full EPEL repository. This recommendation affects any other third-party repositories.

To use packages from the EPEL repository, first download the EPEL public GPG key from the official Fedora project web page. Then, create a content credential and add the EPEL public GPG key. Create a product, associate the public GPG key with it, and create a DNF type repository. To use only the required packages from the EPEL repository, you have two options.

The first option is to download only the required packages from the EPEL repository and to manually add them to your DNF repository. Then, add the repository to the chosen content view, create a new version, and publish it. Finally, promote the content view to the appropriate lifecycle environment to provide it to the required hosts. This option requires manual steps for downloading the packages from the EPEL repository and uploading them to the custom repository. Moreover, every time that you need a new package from the EPEL repository, you must upload it to your custom repository.

The second option is to fill the Upstream URL field for your custom repository with the EPEL repository URL. Then, synchronize the entire repository. To add only the chosen packages, add the repository to the content view, and use a content view filter to select those packages. Finally, create a new content view version, publish it, and promote it to the chosen lifecycle environment. Syncing the full EPEL repository takes approximately 30 minutes. However, you can reuse the repository in different content views by applying different filters to select the appropriate packages.

References

For more information, see to the Creating a Custom Product section of the Importing Content chapter in the Red Hat Satellite 6.11 Managing Content Guide at https://access.redhat.com/documentation/en-us/red_hat_satellite/6.11/html-single/managing_content/index#Creating_a_Custom_Product_content-management

For more information, see to the Adding Custom RPM Repositories section of the Importing Content chapter in the Red Hat Satellite 6.11 Managing Content Guide at https://access.redhat.com/documentation/en-us/red_hat_satellite/6.11/html-single/managing_content/index#Adding_Custom_RPM_Repositories_content-management

For more information, see to the Extra Packages for Enterprise Linux (EPEL) documentation in the Fedora project web page at https://docs.fedoraproject.org/en-US/epel

For more information about how to add an EPEL or other third-party repository to Red Hat Satellite, see to https://access.redhat.com/solutions/2211261

Discuss Red Hat Satellite 6 Administration

Go to community

Welcome to the Red Hat Satellite 6 Administration (RH403) group in the Red Hat Learning Community!

Syed

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Satellite 6 Administration! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH403.Read more about Red Hat Satellite 6 Administration here.

Revision: rh403-6.11-3ad886e