Installation guide

Important

Do not create an RPM by archiving files and then unarchiving them in the post-install script. This

defeats the purpose of RPM.

If the files in the archive are not included in the file list, they cannot be verified or examined for conflicts.

In the vast majority of cases, RPM itself can pack and unpack archives most effectively anyway. For

instance, don't create files in a %post that cannot or will not be cleaned up in a %postun section.

4.2. Digital Signatures for Red Hat Network Packages

All packages distributed through Red Hat Network should have a digital signature. A digital signature is

created with a unique private key and can be verified with the corresponding public key. After creating a

package, the SRPM (Source RPM) and the RPM can be digitally signed with a GnuPG key. Before the

package is installed, the public key is used to verify the package was signed by a trusted party and the

package has not changed since it was signed.

4.2.1. Generating a GnuPG Keypair

A GnuPG keypair consists of the private and public keys. T o generate a keypair:

1. Type the following command as the root user on the shell prompt:

gpg --gen-key

GPG Keypairs should not be created by non-root users. T he root user can lock memory pages

which means the information is never written to disk, unlike non-root users.

2. After executing the command to generate a keypair, an introductory screen containing key options

similar to the following will appear:

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

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)

Your selection?

3. Choose the option: (2) DSA and ElGamal. This option allows you to create a digital signature and

encrypt/decrypt with two types of technologies. T ype 2 and then press Enter.

4. Choose the key size, which is how long the key should be. T he longer the key, the more resistant

against attacks the messages are. Creating a key of at least 2048 bits in size is recommended.

5. The next option will ask to specify how long the key needs to be valid. When choosing an

expiration date, remember that anyone using the public key must also be informed of the

expiration and supplied with a new public key. It is recommended to not select an expiration date. If

an expiration date is not specified, you are asked to confirm your decision:

Key does not expire at all Is this correct (y/n)?

Chapter 4. Custom Package Management