red hat update infrastructure self …...red hat update infrastructure self-implementation guide in...

RED HAT CERTIFIED CLOUD PROVIDER

RED HAT UPDATE INFRASTRUCTURE

SELF-IMPLEMENTATION GUIDE

RHCCP PROGRAM CONFIDENTIAL

RED HAT UPDATE INFRASTRUCTURESELF-IMPLEMENTATION GUIDE

TABLE OF CONTENTS

1 PREFACE .................................................................................................................................. 41.1 Confidentiality, Copyright, and Disclaimer ................................................................................. 41.2 About This Document ................................................................................................................... 41.3 Audience ....................................................................................................................................... 41.4 Background ................................................................................................................................... 4

1.4.1 Red Hat Certified Cloud Providers ............................................................................................ 41.4.2 Red Hat Update Infrastructure .................................................................................................. 4

1.5 Related Documents ...................................................................................................................... 51.6 Document History ......................................................................................................................... 5

2 OVERVIEW ................................................................................................................................ 62.1 Scope ............................................................................................................................................. 62.2 Steps .............................................................................................................................................. 6

3 STEP 1 – GATHER REQUIRED INFORMATION ..................................................................... 73.1 Red Hat Credentials ...................................................................................................................... 73.2 Network Information ..................................................................................................................... 73.3 Red Hat Content ............................................................................................................................ 73.4 Content Repository Size .............................................................................................................. 83.5 Client Profiles ............................................................................................................................... 8

4 STEP 2 – CHECK PRE-REQUISITES ...................................................................................... 94.1 Cloud Provider Subscriptions ..................................................................................................... 94.2 Bugzilla Account ......................................................................................................................... 12

5 STEP 3 – CREATE SSL CERTIFICATES ............................................................................... 14

6 STEP 4 – SETUP THE RED HAT UPDATE APPLIANCE (RHUA) ........................................ 166.1 Operating System Installation ................................................................................................... 166.2 System Registration ................................................................................................................... 166.3 Operating System Configuration ............................................................................................... 20

6.3.1 iptables ................................................................................................................................... 206.3.2 Content Repository Storage .................................................................................................... 216.3.3 SELinux .................................................................................................................................. 216.3.4 Apply Updates ......................................................................................................................... 21

6.4 Install Red Hat Update Appliance Software .............................................................................. 216.4.1 Download Entitlement Certificates .......................................................................................... 216.4.2 Download the RHUI ISO ......................................................................................................... 236.4.3 Install RHUI Packages ............................................................................................................ 23

6.5 SSL Certificates .......................................................................................................................... 246.6 Answers File ................................................................................................................................ 246.7 RHUI Installer .............................................................................................................................. 256.8 Start the RHUA ............................................................................................................................ 25

7 STEP 5 – SYNC RED HAT CONTENT TO THE RHUA ......................................................... 277.1 Run the RHUI Manager ............................................................................................................... 277.2 Add Red Hat Content Repositories ........................................................................................... 287.3 Sync Red Hat Repositories ........................................................................................................ 30

8 STEP 6 – SETUP THE CONTENT DELIVERY SERVERS (CDS'S) ...................................... 31

RH CCSP Program Confidential Do Not Redistribute


8.1 Operating System Installation ................................................................................................... 318.2 Temporary yum Repository ....................................................................................................... 318.3 Operating System Configuration ............................................................................................... 31

8.3.1 iptables ................................................................................................................................... 318.3.2 Content Repository Storage .................................................................................................... 328.3.3 SELinux .................................................................................................................................. 33

8.4 Install Content Delivery Server Software .................................................................................. 338.5 Start the CDS .............................................................................................................................. 338.6 Register the CDS with the RHUA ............................................................................................... 338.7 Associate Content With the CDS Cluster .................................................................................. 348.8 Synchronize the CDS ................................................................................................................. 34

9 STEP 7 – SETUP MONITORING OF THE RHUI .................................................................... 35

10 STEP 8 – CREATE CLIENT PROFILES FOR THE RHUI SERVERS ................................. 3610.1 Generate GPG Keys .................................................................................................................. 3610.2 Set Up Custom Repositories ................................................................................................... 3810.3 Create Entitlement Certificate .................................................................................................. 3910.4 Create Client Configuration RPM ............................................................................................ 4110.5 Push RPM to Custom Repository ............................................................................................ 4110.6 Perform a CDS Sync ................................................................................................................. 4110.7 Configure CDS Servers for Updates ....................................................................................... 4210.8 Configure the RHUA for Updates ............................................................................................ 42

11STEP 9 – CREATE OTHER CLIENT PROFILES .................................................................. 4311.1 GPG Keys .................................................................................................................................. 4311.2 Custom Repositories ................................................................................................................ 4311.3 Entitlement Certificates ............................................................................................................ 44

11.3.1 Red Hat Enterprise Linux 5 ................................................................................................... 4411.3.2 Red Hat Enterprise Linux 6 ................................................................................................... 45

11.4 Client Configuration RPMs ...................................................................................................... 45

12 STEP 10 – CREATE CLIENT IMAGES/TEMPLATES .......................................................... 4612.1 Image Requirements ................................................................................................................ 4612.2 RHUI Integration ....................................................................................................................... 4612.3 Template Preparation ............................................................................................................... 46

13 STEP 11 – SUBMIT IMAGE CERTIFICATION REQUESTS ................................................ 4813.1 Submit Bugzilla Account .......................................................................................................... 4813.2 Cloud Provider Certification Workflow ................................................................................... 4813.3 Cloud Provider Certification Website ...................................................................................... 48

14 APPENDICES ........................................................................................................................ 4914.1 Appendix A: RHUI MONITORING SCRIPT ............................................................................... 5014.2 Appendix B: TEMPLATE PREPARATION SCRIPT .................................................................. 5114.3Appendix C: RHUI PREREQUISITES ........................................................................................ 53



1 PREFACE

1.1 Confidentiality, Copyright, and Disclaimer

This is a confidential document, provided to you under the Red Hat Certified Cloud Provider program.

Copyright 2013 Red Hat, Inc. All rights reserved. Except as required to share this document within your organization, no part of the work covered by the copyright herein may be reproduced or used in any form or by any means – graphic, electronic, or mechanical – including photocopying, recording, taping, or information storage and retrieval systems – without permission in writing from Red Hat.

This document is not a quote and does not include any binding commitments by Red Hat.

1.2 About This Document

This document is a step-by-step guide to performing the technical enablement steps required of a new Red Hat Certified Cloud Provider. It supplements the official Red Hat Update Infrastructure documentation and provides a prescriptive approach to subjects including:

SSL certificate creation,

Red Hat Update Infrastructure installation and configuration,

Naming conventions, and

Custom repositories and signing keys.

1.3 Audience

This document is intended for cloud provider system administrators who are preparing their infrastructure for participation in the Red Hat Certified Cloud Provider program.

This guide is written for experienced Red Hat Enterprise Linux system administrators. Cloud providers whose staff do not have extensive Red Hat Enterprise Linux skills should consider engaging Red Hat Consulting to provide a Red Hat Certified Cloud Provider Architecture Service.

1.4 Background

1.4.1 Red Hat Certified Cloud Providers

The Red Hat Certified Cloud Provider (CCP) program allows public cloud providers to offer certified instances of Red Hat Enterprise Linux (RHEL) and other Red Hat software to their customers.

CCPs offer “on-demand” RHEL instances. The CCP’s customers purchase on-demand instances from the provider, and the provider is responsible for monitoring the use of RHEL instances, reporting that use to Red Hat on a regular basis, and remitting payment as required by their CCP agreement. The cloud provider is also responsible for providing support for “on-demand” RHEL instances running in their cloud.

1.4.2 Red Hat Update Infrastructure

Red Hat’s traditional systems management tools (Red Hat Network and Satellite) do not work well in a cloud-computing environment – where RHEL instances may be created and destroyed with great frequency and the number of instances used is only known retrospectively. Red Hat Update Infrastructure (RHUI) addresses this problem. This section provides a short overview of RHUI.

RHUI uses yum, along with SSL, to make Red Hat content available to authorized users within a CCP’s cloud. AnSSL client certificate is created for each profile within a provider’s environment (where a profile simply identifies the set of RHUI repositories that a system can access). The repository identifiers are added to the certificate, so the RHUI servers can simply examine the SSL certificate presented by the client to determine if access to a certain repository is allowed.



In a CCP environment, all responsibility for tracking the usage of RHEL instances and reporting that usage to RedHat is placed on the provider. RHUI provides no metering; if a client’s profile certificate provides access to a repository, RHUI will make the content available to that client.

Figure 1- shows the Red Hat Update Infrastructure architecture, whichconsists of the following components:

Red Hat Content Delivery Network (CDN) – This is the infrastructure usedto distribute content via the Red Hat Network (to customers who have notdisabled location-aware updates). It is currently managed by Akamai.

Red Hat Update Appliance (RHUA) – A RHUA pulls content from the CDNand pushes it to the Content Delivery Servers. It also provides themanagement interface (the RHUI Manager) for itself and any associateddelivery servers. Most cloud providers will deploy one RHUA per physicallocation. One or more RHUAs will be set up as part of this engagement.

Content Delivery Server (CDS) – A CDS receives content from a RHUA.(Technically, the RHUA tells the CDS to initiate a sync, and the CDS thenpulls the content from the RHUA.) Tenant VMs pull content from a CDSwith yum. Each CDS also serves as a load balancer; it can redirect arequest from a tenant VM to one of its peers. In most cases, at least twoCDS will be set up during the engagement.

Tenant VMs – These are the RHEL virtual machines that the cloudprovider makes available to its customers. Each instance includes a pre-installed configuration RPM, which includes a yum configuration pointingto the appropriate CDS(s) and a profile-specific client certificate whichprovides access to appropriate repositories.

1.5 Related Documents

Red Hat Update Infrastructure documentation – https://access.redhat.com/site/documentation/Red_Hat_Update_Infrastructure/

1.6 Document History

Version Date Contributor Description3.0 5 February 2015 Matthew Mariani

<[email protected]>Updated with RHEL7 comments and Image Certification Workflow links.

2.0 5 December 2013 Ian Pilcher <[email protected]>

Update screenshots and Bugzilla product/component

1.0 31 May 2013 Ian Pilcher <[email protected]>

First release

Table 1-1: Document History


Red Hat Content Delivery Network

(Akamai)

Red Hat Update

Appliance

Red Hat Update

Appliance

Content Delivery Server

Content Delivery Server

Tenant VM

Tenant VM

Tenant VM

Figure 1-1: RHUI Architecture

mailto:[email protected]

https://access.redhat.com/site/documentation/Red_Hat_Update_Infrastructure/


2 OVERVIEW

2.1 Scope

This guide provides instructions for creating a basic RHUI configuration, consisting of a single Red Hat Update Appliance (RHUA) and two content delivery servers (CDS) in a single cluster.

FYI: RHUI content repositories are associated with CDS clusters, rather than individual servers, sohaving a single CDS cluster implies that all content will be pushed from the RHUA to all CDS (or not available at all).

2.2 Steps

The implementation process is divided into the steps listed below.

1. Gather Required Information2. Check Pre-Requisites3. Create SSL Certificates4. Set Up the Red Hat Update Appliance5. Sync Red Hat content to the RHUA6. Set Up the Content Delivery Servers7. Set Up Monitoring of the RHUI8. Create a Client Profile for the RHUI Servers9. Create Other Client Profiles10. Create Client Images/Templates11. Submit Image Certification Requests



3 STEP 1 – GATHER REQUIRED INFORMATION

Gather the information listed below before beginning an implementation.

3.1 Red Hat Credentials

Two separate sets of Red Hat credentials are required: 1.) Red Hat Customer Portal account and 2.) Red Hat Bugzilla account.

The Red Hat Customer Portal (http://access.redhat.com) is used for a variety of purposes, including:

RHUI registration,

Entitlement certificate downloads,

Subscription management,

Software downloads,

Technical support, and

Access to the Red Hat knowledgebase.

The Red Hat Bugzilla (http://bugzilla.redhat.com) is used to submit image certification requests. The Bugzilla account must be submitted to your Red Hat account team and tagged to receive image certification information.

3.2 Network Information

For the Red Hat Update Appliance (RHUA):

Fully qualified domain name (FQDN)

IP address

If the RHUA will use a proxy for access to the Red Hat CDN, the following information is also required.

Proxy FQDN or IP address

Proxy username and password (if required)

For each CDS:

FQDN

IP address

It is possible for a CDS to have a different “client facing” hostname, which differs from the hostname used for intra-RHUI communication. If client facing hostnames will be used, note each CDS’s client facing FQDN and the corresponding IP address.

3.3 Red Hat Content

Determine which of the following Red Hat Enterprise Linux content repositories the RHUI will manage.

Red Hat Enterprise Linux 5, 6, and 7

32-bit (i386)

64-bit (x86_64)

Red Hat Enterprise Linux Add-Ons

Red Hat Enterprise Linux Additional and Supplementary Repositories

Red Hat Software Collections Library

Note: 64-bit Red Hat Enterprise Linux 6 is required by the Red Hat Update Infrastructure.


http://bugzilla.redhat.com/

http://access.redhat.com/


3.4 Content Repository Size

An individual Red Hat Enterprise Linux repository can be large; it contains every package ever released for that major version (e.g. 5 or 6) of the operating system, including every update release (5.0 - 5.9 for example) and anybetween-update errata. With every semi-annual update release, it grows by several gigabytes.

To estimate the required content repository size, allow 40GB for a single architecture of a given major version. There is some overlap between the two different architectures of a single version, so allow 60GB if both architectures will be needed. For example, RHEL 5 32-bit only and RHEL 6 32- and 64-bit would collectively require a 100GB content repository (40GB for RHEL 5 32-bit plus 60GB for both architectures of RHEL 6).

Each RHUI server (RHUA or CDS) will require a separate content repository filesystem of the required size. It is important to use technologies such as LVM, SAN, or NAS storage that will allow the content repository to grow if needed. The above example would require 300GB total (100GB for the RHUA and 100GB for each CDS).

3.5 Client Profiles

Identify the client profiles to be created. A client’s profile will determine:

The RHUI content that is available to the client, and

The set of content delivery servers (CDS cluster) from which the client will download that content.

FYI: In some cases, a single profile can be used for both 32- and 64-bit clients. See section 10.2.

Each client profile should have a short, descriptive name that can be incorporated into the names of files associated with the profile.



4 STEP 2 – CHECK PRE-REQUISITES

4.1 Cloud Provider Subscriptions

Verify that the required subscriptions have been added to your Red Hat account.

1 Access the Red Hat Customer Portal at https://access.redhat.com and click on Log in.

Figure 4-1: Red Hat Customer Portal – Landing Page

12. Enter your Red Hat credentials and click on the Log In button.

Figure 4-2: Red Hat Customer Portal – Login Page

13. Click on Subscriptions.

Figure 4-3: Accessing Subscription Management


https://access.redhat.com/


14. Click on Active Subscriptions.

Figure 4-4: Accessing Active Subscriptions



15. Verify that your account contains the required subscriptions. The names of the subscriptions may vary slightly, depending on the exact SKUs in your Red Hat account.

Red Hat Enterprise Linux from RHUI

Red Hat Update Infrastructure (RHUI)

or

Red Hat Update Infrastructure – Content Service – for Providers

Red Hat Enterprise Linux for Update Content Service

Figure 4-5: Red Hat Customer Portal – Active Subscriptions



4.2 Bugzilla Account

Cloud image certification requests are submitted to Red Hat through Bugzilla. This section contains instructions for verifying that your Red Hat Bugzilla account has been added to the Software Test Suite Entry (swcert_enter) group.

1 Access Red Hat Bugzilla at https://bugzilla.redhat.com and click on Log In.

Figure 4-6: Red Hat Buzilla – Not Logged In

16. Enter your Red Hat Bugzilla credentials and click on the Log In button.

Figure 4-7: Red Hat Bugzilla – Logging In


https://bugzilla.redhat.com/


17. Click on Preferences.

Figure 4-8: Red Hat Bugzilla – Logged In

18. Click on Permissions.

Figure 4-9: Red Hat Bugzilla – General Preferences

19. Ensure that swcert_enter Software Test Suite Entry is listed. (Other permissions may also be listed.)

Figure 4-10: Red Hat Bugzilla – Permissions

4.3


Root CA

Server CA

RHUA

CDS2

CDS1

…

Client CA

RHEL5

RHEL6

…


5 STEP 3 – CREATE SSL CERTIFICATES

This section provides instructions for using the Red Hat-provided script, create_rhui_ssl_certs.sh, to create the CA and server certificates required by RHUI. A tar file containing the script and associated files can be downloaded at:

Red Hat Certified Cloud Services Provider Implementation Guide Resources Page

https://access.redhat.com/articles/1326733

Note: If you have already downloaded the RHUI ISO and executed ' install_RHUA.sh ” as describedin Section 6, the certificate generation script and associated files will be placed in:

/usr/share/rh-rhua/rhui_certs/create_rhui_ssl_certs.sh

Figure 5-0 illustrates the certificate hierarchy that the script will create. (The client profile certificates, which will besigned by the client CA, are shown in gray, because they will be created during a later step.)

Figure 5-0: SSL Certificate Hierarchy

Note: The steps in this section should be performed on a separate, secure system. Only the files placed in the cert-results directory should be copied to the RHUI.

1 Extract provided create_rhui_ssl_certs.sh.gz file as needed.

2 'cd' into the appropriate script directory.


https://access.redhat.com/articles/1326733


3 Edit the script, and set the certificate hearder variables, which will be used to construct the distinguished names for the RHUA and CDS server certificates. Any values containing whitespace must be quoted. i.e. C=<Country Code>, ST=<State (fully spelled)>, L=<City>, O=<Org>, OU=<Org Unit>For example:

…

C=US

ST=Texas

L=Dallas

O=”Red Hat, Inc.”

OU=”Certified Cloud Provider Program”

…

4 Execute the script, passing the fully qualified domain names of the RHUA and all content delivery servers on the command line.

FYI: The certificate generation script is not limited to 2 content delivery servers; any number of CDS hostnames can be passed on the command line (subject to the limits of the operating system and shell).

Note: Be sure to use the client-facing FQDNs of the content delivery servers. (See section 3.2 .)

When prompted, enter a different password for each CA private key:

Root CA

Server CA

Client CA

Each password should be recorded in a secure, offline location.

$ ./create_rhui_ssl_certs.sh <rhuaFQDN> <cds1FQDN> <cds2FQDN>

…

Setting password for root CA private key:

Writing RSA key

Enter PEM pass phrase:<rootCAPassword>

Verifying – Enter PEM pass phrase:<rootCAPassword>

Setting password for server CA private key:

Writing RSA key

Enter PEM pass phrase:<serverCAPassword>

Verifying – Enter PEM pass phrase:<serverCAPassword>

Setting password for client CA private key:

Writing RSA key

Enter PEM pass phrase:<clientCAPassword>

Verifying – Enter PEM pass phrase:<clientCAPassword>

Done preparing SSL chain and answers file.

Now run rhui installer with ./answers file. Check it first.

The output files in the cert-results directory will be copied to the RHUA in section 6.5. The contents of the server-ca and root-ca directories should be saved for signing additional or replacement server and CA certificates.



6 STEP 4 – SETUP THE RED HAT UPDATE APPLIANCE (RHUA)

6.1 Operating System Installation

Install the most recent release of Red Hat Enterprise Linux 6 Server (x86_64).

If the content repository will be stored on the system disk(s), create a separate logical volume and filesystem mounted at /var/lib/pulp.

Choose the Minimal installation type.

6.2 System Registration

Follow the steps below to create the RHUI, attach subscriptions, and register the RHUA.

1 Log in to the Red Hat Customer Portal. (If necessary, see steps 1 and 12 in section 4.1.)

2 Click on Subscriptions.

Figure 6-1: Accessing the Subscriptions Menu

3 “Mouse over” Subscription Management and click on Units.

Figure 6-2: Accessing Subscribed Units



4 Click on Register a unit.

Figure 6-3: Register a Unit

20. Set the Type drop-down to RHUI, enter a name for the RHUI (such as the FQDN of the RHUA), and click on the Register button.

Figure 6-4: Create the RHUI



21. Click on Attach a subscription.

Figure 6-5: Newly Created RHUI

22. Select the required subscriptions (see section 4.1, step 15) and click on the Attach Selected button.

Figure 6-6: Attaching Subscriptions



23. Note the UUID of the RHUI.

Figure 6-7: RHUI UUID

24. On the RHUA, use the subscription-manager command to register the system. Copy the UUID from the Customer Portal to the command line.

# subscription-manager register --consumerid=<UUID>

Username: <ccpRedHatID>

Password: <ccpRedHatPassword>

The system has been registered with id: <UUID>

25. Verify that RHEL packages are available via yum.

# yum list zsh

Loaded plugins: product-id, subscription-manager

Updating certificate-based repositories.

Please use yum-config-manager to configure which software

repositories are used with Red Hat Subscription Management.

rhel-6-server-rhui-rpms | 3.7 kB 00:00

Available Packages

zsh.x86_64 4.3.10-5.el6 rhel-6-server-rhui-rpms



6.3 Operating System Configuration

6.3.1 iptables

The RHUA must accept incoming connections from the CDS(s) on two ports:

HTTPS (TCP port 443)

AMQP over SSL (TCP port 5674)

The steps below will configure the RHUA to accept connections on these ports only from the known IP addresses of the CDS, while leaving all other rules unchanged.

Determine the where the new rules should be inserted into the INPUT chain.

# iptables –L INPUT --line-numbers

Chain INPUT (policy ACCEPT)

num target prot opt source destination

1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0

3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22

5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Note the line number of the rule for ssh (line 4 in this example). For each CDS, issue the following commands.

# iptables –I INPUT <line> -s <cdsIpAddr> -p tcp –m state --state NEW --dport 443 \

–j ACCEPT

# iptables –I INPUT <line> -s <cdsIpAddr> -p tcp –m state --state NEW --dport 5674 \

-j ACCEPT

Below is an example of the result after adding two CDS. The new rules are boldfaced.

# iptables –L INPUT –n


target prot opt source destination

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

ACCEPT tcp -- 10.15.180.16 0.0.0.0/0 state NEW tcp dpt:5674




ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22

REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Make the changes persistent.

# service iptables save

iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]



6.3.2 Content Repository Storage

If the content repository filesystem was not created during operating system installation (see section 6.1), it must be created or configured. Any block storage technology supported by Red Hat Enterprise Linux 6 may be used – including local disks (physical or virtual), Fibre Channel, iSCSI, and FCoE. NFS can also be used.

The exact steps required to prepare storage for the package repository vary, depending on the type of storage used, but the end result must be a filesystem with the following characteristics.

The filesystem type is ext4 (on LVM) or NFS.

The filesystem is mounted at /var/lib/pulp.

If using NFS, the chown and chmod commands can be used successfully on the filesystem, including its root directory. (I.e. “root squashing” is turned off on the NFS server).

If using NFS version 4, the NFS server must allow the ownership of files and directories to be set to apache:apache. This may require adding the apache user and group to the NFS server’s user directory.

FYI: Installing the httpd package is an easy way to create the apache user and group for testing purposes.

6.3.3 SELinux

If using NFS, set an SELinux boolean to allow httpd to access NFS filesystems.

# setsebool –P httpd_use_nfs on

6.3.4 Apply Updates

As a final step before installing the RHUA packages, apply any available operating system updates and reboot.

# yum –y update && reboot

Verify that all configuration changes have persisted.

6.4 Install Red Hat Update Appliance Software

6.4.1 Download Entitlement Certificates

An entitlement certificate is an (X.509) SSL client certificate that provides access to content within the Red Hat CDN. Entitlement certificates are used for various purposes during installation and ongoing operation of the RHUI.

yum access to Red Hat Enterprise Linux and Red Hat Update Infrastructure packages during RHUA setup

Access to the RHUI installation ISO

Access to ISOs, packages, etc. during RHUI repository synchronization

Use the steps below to download entitlement certificates for Red Hat Enterprise Linux (RHEL) and Red Hat Update Infrastructure (RHUI).

1 Follow steps 1 through 3 in section 6.2 to access your subscribed units.



2 Click on the name of the RHUI.

Figure 6-8: Registered Units

3 Click on the Download link next to each subscription. Save the Red Hat Enterprise Linux entitlement certificate as rhel-entitlement.pem, and save the Red Hat Update Infrastructure entitlement certificate as rhui-entitlement.pem.

Figure 6-9: Download Entitlement Certificates

4 Copy the entitlement certificates to the /root/entitlement directory on the RHUA.



6.4.2 Download the RHUI ISO

The RHUI installation ISO must be downloaded from the Red Hat CDN, using the RHUI entitlement certificate downloaded in the previous section.

Refer to section 2.3 of the Red Hat Update Infrastructure Installation Guide for the current download URL. (At the time of this writing, the URL is https://cdn.redhat.com/content/dist/rhel/rhui/server/6/6Server/x86_64/rhui/2/iso/RHEL-6-RHUI-2-LATEST-Server-x86_64-DVD.iso.)

# yum install wget

…

# wget --no-check-certificate --certificate=/root/entitlement/rhui-entitlement.pem \

<rhuiIsoURL>

…

6.4.3 Install RHUI Packages

Warning: Before running the installation script, ensure that the hostname of the RHUA is set correctly.

Mount the ISO and run the installation script.

# mount –o ro,loop <rhuiISO> /mnt

# cd /mnt

# ./install_RHUA.sh

Checking for hostname...

Hostname set to rhua.gsso.redhat.com.

Installing Red Hat Update Appliance packages

…

Red Hat Update Appliance packages installed.

Installing RHUI Tools packages

…

Artifacts copied to: /etc/rhui/qpid.

Red Hat Update Infrastructure Tools packages successfully installed and can be startedby executing rhui-tools from the prompt.

Enable the Red Hat Update Infrastructure repository and install any RHUI updates.

# yum install yum-utils

…

# yum-config-manager --enable rhel-x86_64-6-rhui-2-rpms

…

# yum update

…



6.5 SSL Certificates

The following SSL certificates that were created in section 5 must be copied to the RHUA.

Server CA “chain file” – server-ca-chain.pem

Client CA “chain file” – client-ca-chain.pem

Client CA private key – client-ca-key.pem

Server certificate for each RHUI server – <fqdn>-cert.pem

Private key for each RHUI server – <fqdn>-key.pem

Place the files in /root/ssl on the RHUA. (You may need to install the openssh-clients package if you wish touse scp to transfer the files.)

6.6 Answers File

RHUI uses an answers file to create configuration RPMs for the RHUA and CDS servers. Follow the instructions in section 3.2 of the Red Hat Update Infrastructure Installation Guide to create the answers file, based on the sample at /etc/rhui/answers.sample.

Recommended values for items that should be changed are shown below. (Context, including an items for which no change is required are not shown.)

Note: Proxy-related entries are only required if an HTTP proxy is being used. See section 3.2 and the comments in the sample answers file.

[general]

dest_dir: /root/rhui

[rhua]

rpm_name: rhui-cfg-<rhuaHost>

hostname: <rhuaFQDN>

ssl_cert: /root/ssl/<rhuaHost>-cert.pem

ssl_key: /root/ssl/<rhuaHost>-key.pem

ca_cert: /root/ssl/server-ca-chain.pem

proxy_server_host: <proxyFQDN>

proxy_server_port: <proxyPort>

proxy_server_username: <proxyUser>

proxy_server_password: <proxyPassword>

[cds-1]

rpm_name: rhui-cfg-<cds1Host>

hostname: <cds1FQDN>

ssl_cert: /root/ssl/<cds1Host>-cert.pem

ssl_key: /root/ssl/<cds1Host>-key.pem

[cds-2]

rpm_name: rhui-cfg-<cds2Host>



hostname: <cds2FQDN>

ssl_cert: /root/ssl/<cds2Host>-cert.pem

ssl_key: /root/ssl/<cds2Host>-key.pem

6.7 RHUI Installer

Run the RHUI installer to create the RHUA and CDS configuration RPMs. For example:

# rhui-installer /root/answers.txt

Generating RHUA configuration RPM

RHUA RPM can be found at [/root/rhui]

Generating CDS bundle for CDS [cds1.gsso.redhat.com]

CDS RPM can be found at [/root/rhui]

Generating CDS bundle for CDS [cds2.gsso.redhat.com]

CDS RPM can be found at [/root/rhui]

# ls –l /root/rhui

total 60

drwxr-xr-x. 4 root root 4096 Aug 18 15:34 rhui-cfg-cds1-2.0

-rw-r--r--. 1 root root 10056 Aug 18 15:34 rhui-cfg-cds1-2.0-2.el6.noarch.rpm

drwxr-xr-x. 4 root root 4096 Aug 18 15:34 rhui-cfg-cds2-2.0

-rw-r--r--. 1 root root 10074 Aug 18 15:34 rhui-cfg-cds2-2.0-2.el6.noarch.rpm

drwxr-xr-x. 4 root root 4096 Aug 18 15:34 rhui-cfg-rhua-2.0

-rw-r--r--. 1 root root 20852 Aug 18 15:34 rhui-cfg-rhua-2.0-2.el6.noarch.rpm

6.8 Start the RHUA

Install the RHUA configuration package to start the services that make up the RHUA.

# rpm –ihv /root/rhui/rhui-cfg-<rhuaHost>-2.0-2.el6.noarch.rpm

Preparing... ########################################### [100%]

1:rhui-cfg-rhua ########################################### [100%]

Updating RHUA Server Configuration

Updating RHUA Repository Authentication Configuration

Updating Apache SSL Configuration

Starting mongod: [ OK ]

removing persisted tasks

database migration to version 41 complete

Stopping httpd: [FAILED]

Stopping Qpid AMQP daemon: [FAILED]

Stopping mongod: [ OK ]

Starting mongod: [ OK ]

Starting Qpid AMQP daemon: [ OK ]

Starting httpd: [ OK ]



FYI: The [FAILED] messages are expected if the httpd or qpidd services aren’t already running.



7 STEP 5 – SYNC RED HAT CONTENT TO THE RHUA

The initial sync of Red Hat content can be a very long process. Thus, it is useful to begin syncing as soon as possible – before setting up the CDS servers.

7.1 Run the RHUI Manager

On the RHUA, run rhui-manager.

When executed for the first time, rhui-manager will prompt for a “signing CA certificate.” This is the certificate that will be used by the RHUI Manager to sign client profile certificates – i.e. the client CA certificate that was created in section 5. It will also be used for validation of client certificates.

Next, rhui-manager will prompt for the file containing the client CA private key.

The RHUI Manager will then prompt for the lifetime of the RHUI identity certificate. The RHUI identity certificate isa special certificate, signed by the client CA, that allows access to all of the content managed by the RHUI. It is used by the CDS servers when they pull content from the RHUA. The default lifetime of 3,650 days (10 years) is a good choice, but note that it may need to be reduced to ensure that the identity certificate does not “outlive” the client CA certificate by which it was signed.

FYI: The identify certificate and its associated private key are stored in /etc/pki/rhui/identity.crt and /etc/pki/rhui/identify/identity.key.

The pass phrase of the client CA private key is required to sign the identity certificate.

The RHUI username is admin, and the initial password is admin.

An example of running rhui-manager for the first time is shown below.

# rhui-manager

An entitlement signing CA certificate is required to use RHUI Tools

but was not found.

Full path to the new signing CA certificate:

/root/ssl/client-ca-chain.pem

Full path to the new signing CA certificate private key:

/root/ssl/client-ca-key.pem

Generating entitlement certificate serial number database file /etc/pki/rhui/entitlement-ca.srl

A RHUI identity certificate is required to use RHUI Tools but was not found.

A new identity certificate will be generated now using the CA certificate

found at /etc/pki/rhui/entitlement-ca.crt.

Enter the number of days the RHUI identity certificate will be valid.

If the identity certificate ever expires, it will need to be

regenerated using rhui-manager [Default: 3650]:

......+++



...................................+++

Enter pass phrase for /etc/pki/rhui/entitlement-ca-key.pem: <clientCaKeyPasswd>

Previous authentication credentials could not be found. Logging into

the RHUI.

If this is the first time using the RHUI, it is recommended to change

the user's password in the User Management section of RHUI Tools.

RHUI Username: admin

RHUI Password: admin

The RHUI Manager uses a simple text-based, menu-driven interface, which is described in section 1.2 of the Red Hat Update Infrastructure Administration Guide. Choose u (manage users), p (change a user’s password) to change the admin password.

Note: The RHUI Manager caches authentication credentials, so you will not be prompted for a password if you q (quit) rhui-manager and restart it. Instead, use the logout command to remove the cached authentication credentials.

It is recommended that the RHUA be restarted after the password has been changed. This ensures that no running services are using the old password. The simplest way to achieve this is to reboot the system.

7.2 Add Red Hat Content Repositories

The first step in adding Red Hat content repositories to the RHUI is to upload the entitlement certificates that weredownloaded in section 6.4.1.

1 When the RHUA has restarted, log in and run rhui-manager. If required, log in to the manager.

2 Enter n to select manage Red Hat entitlement certificates, then enter u to select upload a new or updated Red Hat content certificate.

3 When prompted, enter the path to the Red Hat Enterprise Linux entitlement certificate (/root/entitlement/rhel-entitlement.pem). Enter y to proceed.

4 A list of the products included in the entitlement certificate will be printed, and you will be returned to the Entitlements Manager menu.

5 Enter u to select upload a new or updated Red Hat content certificate.

6 When prompted enter the path to the Red Hat Update Infrastructure entitlement certificate (/root/entitlement/rhui-entitlement.pem). Enter y to proceed.

7 If entitlement certificates for any additional subscriptions have been downloaded, repeat steps 5 and 6 to upload those entitlement certificates.

8 Enter a caret character (^) to return to the Home menu.

Next, the actual content repositories to be synced must be selected.

1 Enter r to select manage repositories, then enter a to select add a new Red Hat content repository. The manager may pause for a minute or so while it determines which entitled repositories have not yet been added.



2 The manager will prompt for a selection method.

All in Certificate will select all content in all entitlement certificates that have been uploaded. In addition tobinary packages, this will also select beta software repositories and source and debug packages. This option is not recommended.

By Product provides a fairly granular level of selection. This is the recommended option.

By Repository is very similar to By Product, except that it allows for separate selection of 32- and 64-bit repositories. This option should be selected if only the 32- or 64-bit version of a particular product is desired.

1. If By Product or By Repository is selected, the manager will display a list of all available products or repositories. Enter the value associated with a particular item to toggle its selection status. The majority of the repositories will usually not be of interest; generally only non-beta binary RPMs are desired. An example of a selection list with only supported binary software is shown below. (Selected products are boldfaced.)

Select the products to be deployed to the RHUI (only undeployed products are displayed):

- 1 : Red Hat Enterprise Linux 5 Server Beta from RHUI (Debug RPMs)

- 2 : Red Hat Enterprise Linux 5 Server Beta from RHUI (RPMs)

- 3 : Red Hat Enterprise Linux 5 Server Beta from RHUI (Source RPMs)

- 4 : Red Hat Enterprise Linux 5 Server from RHUI (Debug RPMs)

x 5 : Red Hat Enterprise Linux 5 Server from RHUI (RPMs)

- 6 : Red Hat Enterprise Linux 5 Server from RHUI (Source RPMs)

- 7 : Red Hat Enterprise Linux 6 Server - Optional Beta from RHUI (RPMs)

- 8 : Red Hat Enterprise Linux 6 Server - Optional Beta from RHUI (Source RPMs)

- 9 : Red Hat Enterprise Linux 6 Server - Optional Beta from RHUI(Debug RPMs)

- 10: Red Hat Enterprise Linux 6 Server - Optional from RHUI (Debug RPMs)

x 11: Red Hat Enterprise Linux 6 Server - Optional from RHUI (RPMs)

- 12: Red Hat Enterprise Linux 6 Server - Optional from RHUI (Source RPMs)

- 13: Red Hat Enterprise Linux 6 Server Beta from RHUI (Debug RPMs)

- 14: Red Hat Enterprise Linux 6 Server Beta from RHUI (RPMs)

- 15: Red Hat Enterprise Linux 6 Server Beta from RHUI (Source RPMs)

- 16: Red Hat Enterprise Linux 6 Server from RHUI (Debug RPMs)

x 17: Red Hat Enterprise Linux 6 Server from RHUI (RPMs)

- 18: Red Hat Enterprise Linux 6 Server from RHUI (Source RPMs)

- 19: Red Hat Update Infrastructure 1.2 (Debug RPMs)

- 20: Red Hat Update Infrastructure 1.2 (RPMs)

- 21: Red Hat Update Infrastructure 1.2 (Source RPMs)

- 22: Red Hat Update Infrastructure 2 (Debug RPMs)

x 23: Red Hat Update Infrastructure 2 (RPMs)

- 24: Red Hat Update Infrastructure 2 (Source RPMs)

2. When satisfied with the selection, enter c. The manager will display a list of the products or repositories to be deployed (added to the RHUI) and prompt for confirmation. Enter y to proceed. A message will be printed as each repository is deployed.

3. Enter a caret character (^) to return to the Home menu.



7.3 Sync Red Hat Repositories

When new Red Hat repositories are deployed to the RHUI, the manager prints the following message.

Content will not be downloaded to the newly imported repositories

until the next sync is run.

Follow the steps in this section to begin syncing Red Hat content immediately.

1 At the Home menu, enter s to select synchronization status and scheduling, then enter dr to select display repo sync summary. The newly deployed Red Hat content repositories will be displayed. Barring an unlikely coincidence, none of the repositories will have started syncing. The next scheduled sync for each repository is displayed in the first column.

2 Enter ctrl-c to leave the Repository Synchronization Status display and return to the Synchronization Status menu. (The synchronization status displays in the RHUI Manager are based on the watch command.)

3 Enter sr to select sync an individual repository immediately.

4 All of the deployed Red Hat repositories will be displayed in a selection list. Enter a to choose all of the repositories, followed by c to confirm the selection and y to proceed. A message will be printed as each repository is scheduled for synchronization.

5 When returned to the Synchronization Status menu, enter dr to select display repo sync summary. All Red Hat content repositories should now be syncing (In Progress) or queued to sync (Awaiting Execution).

FYI: In addition to the Repository Synchronization Status display, status of the repository sync can be in /var/log/pulp/grinder.log.



8 STEP 6 – SETUP THE CONTENT DELIVERY SERVERS (CDS'S)

8.1 Operating System Installation

Install the most recent release of Red Hat Enterprise Linux 6 Server (x86_64).

If the package repository will be stored on the system disk(s), create a separate logical volume and filesystemmounted at /var/lib/pulp-cds.

Note: The content repository mount point on a CDS differs from the mount point on a RHUA.

Choose the Minimal installation type.

8.2 Temporary yum Repository

CDS servers are intended to operate without direct access to the Red Hat CDN. When the RHUI is operational, the CDS servers (and potentially the RHUA) will “self-update,” retrieving updated packages from the RHUI. Until that time, however, it is helpful to create a temporary repository that makes the contents of the RHEL installation media available via yum.

Mount the RHEL 6 installation media (ISO or DVD).

# mkdir /mnt/rhel

# mount –o ro /dev/cdrom /mnt/rhel

Create a yum repo file, /etc/yum.repos.d/temp.repo, with the following contents.

[temp]

name = Temporary RHEL Installation Media repo

baseurl = file:///mnt/rhel

gpgcheck = 0

enabled = 1

Verify that RHEL packages are available from the temporary repository.

# yum list zsh

Loaded plugins: product-id, subscription-manager

Updating certificate-based repositories.

Unable to read consumer identity

temp | 4.0 kB 00:00 ...

temp/primary_db | 3.1 MB 00:00 ...

Available Packages

zsh.x86_64 4.3.10-5.el6 temp

8.3 Operating System Configuration

8.3.1 iptables

The CDS must accept incoming HTTPS (TCP port 443) connections from client instances (VMs)

Determine the where the new rules should be inserted into the INPUT chain.

# iptables –L INPUT --line-numbers




num target prot opt source destination

1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0

3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22

5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Note the line number of the rule for ssh (line 4 in this example), and issue the following command.

# iptables –I INPUT <line> -s <clientCIDR> -p tcp –m state --state NEW --dport 443 \

-j ACCEPT

Note: <clientCIDR> represents the IP range of the client instances. If necessary, enter additional commands for additional IP ranges. Alternatively, simply omit -s <clientCIDR> from the command to open the HTTPS port to all source IP addresses.

Also, keep in mind that other content delivery servers (and possibly the RHUA) must be able to connect to the CDS, so that they can “self update.”

Below is an example of the result. The new rule is boldfaced.

# iptables –L INPUT –n


target prot opt source destination

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0



REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Make the changes persistent.

# service iptables save

iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]

8.3.2 Content Repository Storage

If the content repository filesystem was not created during operating system installation (see section 8.1), it must be created or configured. Any block storage technology supported by Red Hat Enterprise Linux 6 may be used – including local disks (physical or virtual), Fibre Channel, iSCSI, and FCoE. NFS can also be used.

The exact steps required to prepare storage for the package repository vary, depending on the type of storage used, but the end result must be a filesystem with the following characteristics.

The filesystem type is ext4 (on LVM) or NFS.

The filesystem is mounted at /var/lib/pulp-cds.

If using NFS, the chown and chmod commands can be used successfully on the filesystem, including its root directory. (I.e. “root squashing” is turned off on the NFS server).



If using NFS version 4, the NFS server must allow the ownership of files and directories to be set to apache:apache. This may require adding the apache user and group to the NFS server’s user directory.

FYI: Installing the httpd package is an easy way to create the apache user and group for testing purposes.

8.3.3 SELinux

If using NFS, set an SELinux boolean to allow httpd to access NFS filesystems.

# setsebool –P httpd_use_nfs on

8.4 Install Content Delivery Server Software

On the CDS, install the openssh-clients package, which includes the scp command.

On the RHUA, copy the RHUI ISO and the CDS configuration package (see section 6.7) to the CDS.

Mount the ISO and run the CDS installation script.

# mkdir /mnt/iso

# mount –o ro,loop <rhuiISO> /mnt/iso

# cd /mnt/iso

# ./install_CDS.sh

Installing Red Hat Content Deliver Server packages

…

Red Hat Content Delivery Server packages installed.

8.5 Start the CDS

Install the CDS configuration package to start the services that make up the CDS.

# rpm –ihv rhui-cfg-<cds1Host>-2.0-2.el6.noarch.rpm

Preparing... ########################################### [100%]

1:rhui-cfg-cds1 ########################################### [100%]

Updating CDS Server Configuration

Updating RHUA Repository Authentication Configuration

Updating Apache SSL Configuration

Stopping httpd: [FAILED]

Stopping goferd[FAILED]

Starting goferd[ OK ]

Starting httpd: [ OK ]

FYI: The [FAILED] messages are expected if the httpd or goferd services aren’t already running.

8.6 Register the CDS with the RHUA

1. On the RHUA, run the RHUI Manager. If necessary, log in.

2. Enter c to select manage content delivery servers (CDS), then enter a to select register (add) a new CDS instance.

3. When prompted for the hostname, enter the fully qualified hostname of the CDS.



4. If clients will use a different hostname to connect to the CDS, enter it when prompted; otherwise press enter to accept the default. (See section 3.2.)

5. When prompted for the display name of the CDS, press enter to accept the default (the hostname) or enter the desired display name.

6. If this is the first CDS registered with the RHUA, enter the name of the cluster to which the CDS will belong. (The name should reflect the set of clients that it will serve – geography, network topology, client profile, etc.) If one or more clusters already exist, either select the value corresponding to an existing cluster, or choose *** Create a new cluster *** and enter the new cluster name.

7. Enter y to proceed.

8. A message will be displayed if registration is successful.

8.7 Associate Content With the CDS Cluster

1. Enter s to select associate a repository with a CDS cluster.

2. Select the value corresponding to the desired cluster.3. Select the repositories to be associated with the cluster.

4. Enter y to proceed.

5. A message will be displayed as each repository is associated with the CDS cluster.


8.8 Synchronize the CDS

Note: Wait for the initial Red Hat content sync that was started in section 7.3 to complete before attempting to sync content to a CDS.

1. Enter s to select synchronization and scheduling, then enter dc to select display CDS sync summary. The newly registered CDS will be displayed. Barring an unlikely coincidence, the CDS will not have started syncing. The next scheduled sync for the CDS is displayed in the first column.

2. Enter ctrl-c to leave the CDS Synchronization Status display and return to the Synchronization Status menu.

3. Enter sc to select sync an individual CDS immediately.

4. The newly registered CDS will be listed within a selection list. Enter the value that corresponds to the newly registered CDS (1 if it is the first CDS to be registered), followed by c to confirm the selection and y to proceed. A message will be printed when the CDS is scheduled for synchronization.

5. When returned to the Synchronization Status menu, enter dc to select display CDS sync summary. The synchronization status of the CDS should be In Progress.



9 STEP 7 – SETUP MONITORING OF THE RHUI

It is important to monitor the status of the RHUA and content delivery servers, to ensure that updates are made available to client instances promptly.

Appendix A contains a simple script that will send an e-mail message if the RHUA detects any abnormal conditions. This script can be run as a cron job on the RHUA. An external monitoring tool should also be used toensure that the RHUA is actually running.



10 STEP 8 – CREATE CLIENT PROFILES FOR THE RHUI SERVERS

This section provides instructions for creating a RHUI client profile RPM for the RHUI servers. When this packageis installed on a RHUI server (RHUA or CDS), the RHUI server will be able to pull updates from the RHUI. (If the server is a CDS, it may “download” updates from itself.) This is the recommended method for making updates available to CDS servers, which are not expected to directly access the Red Hat CDN. It can also be used to provide updates to the RHUA, which avoids downloading those updates from the Red Hat CDN twice – once during a repository sync and once during a yum update.

This section also serves as an introduction to the steps required to create any client profile, including:

Creating GPG keys,

Setting up custom repositories,

Generating client entitlement certificates,

Building client configuration packages,

Signing RPMs, and

Managing the content of custom repositories.

10.1 Generate GPG Keys

Create a GPG key with which to sign custom packages (including client configuration RPMs) for the RHUI client profile. Note the following:

Because this profile will be used for RHUI servers which run on RHEL 6, a 4,096-bit RSA key is used.

The name of the client profile RPM (rhui-client-rhui), which will be created in a later step, is used as the comment portion of the user ID. It is recommended that a different signing key be used for each client profile; the client profile name is used to distinguish the user IDs of the different keys.

# gpg --gen-key

gpg (GnuPG) 2.0.14; Copyright (C) 2009 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.

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? 4

RSA keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048) 4096

Requested keysize is 4096 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) 0

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: Red Hat GSSO RHUI

Email address: [email protected]

Comment: rhui-client-rhui

You selected this USER-ID:

"Red Hat GSSO RHUI (rhui-client-rhui) <[email protected]>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

You need a Passphrase to protect your secret key.

Enter a high quality passphrase, and record it in a secure location.

Note: Gathering sufficient random data to generate a 4,096-bit key may take a significant amount oftime, particularly if the RHUA is a virtual machine. The disk activity created by a repository orCDS sync may speed up the process.

gpg: key EDD092F4 marked as ultimately trusted

public and secret key created and signed.

gpg: checking the trustdb

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model

gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u

pub 4096R/EDD092F4 2012-08-24

Key fingerprint = 1139 932A 26E2 981A 1341 D636 0DDB B5F6 EDD0 92F4

uid Red Hat GSSO RHUI (rhui-client-rhui) <[email protected]>

Note that this key cannot be used for encryption. You may want to use

the command "--edit-key" to generate a subkey for this purpose.

Create a second key. This time choose option 3, DSA (sign only), as the key type and enter 1024-bits as the key size. These options create a key that can be used to sign RPMs for both RHEL 5 and RHEL 6. Use rhui-client-all as the comment portion of the user ID.

Export the two keys.

# mkdir /root/rpm-gpg

# gpg --export --armor rhui-client-rhui > /root/rpm-gpg/rhui-client-rhui

# gpg --export --armor rhui-client-all > /root/rpm-gpg/rhui-client-all



Note: GPG defaults to substring matching when searching for keys. Thus, it is only necessary to specify the unique portion of the user ID (the client profile RPM name in this case).

FYI: The traditional RPM-GPG-KEY- prefix will be added to the GPG key file names when the RHUI Manager creates client configuration packages.

10.2 Set Up Custom Repositories

Create custom repositories that can be used to distribute updated client configuration packages or other non-Red Hat software to the RHUI servers. Four custom repositories will be created.

client-rhui-x86_64 – A protected repository for 64-bit RHUI servers. This repository will be the preferred vehicle for distributing new non-Red Hat packages (such as an updated client configuration package) to the RHUI servers.

FYI: Although there are no 32-bit RHUI servers, the processor architecture is included in the repository name for consistency with the recommended naming convention for protected custom repositories. (See section 11.2.)

A protected repository is only accessible by clients that present an appropriate client entitlement certificate (as their SSL client certificate) when communicating with the CDS.

Like Red Hat content repositories – all of which are protected – protected custom repositoriesthat differ only in processor architecture (i386 vs. x86_64) are consolidated into a single entitlement within an entitlement certificate, using the $basearch yum variable. (See section 5.1 of the Red Hat Update Infrastructure Installation Guide.)

client-rhui-unprotected – An unprotected repository for RHUI servers. In the event of certificate problems, this repository can be used as a fallback method of distributing updated RPMs to the RHUI servers.

Note: As the name implies, the content in an unprotected repository is available to any system that requests it, without any need for a client entitlement certificate. Care must be exercised whenusing an unprotected repository to distribute any content, particularly content such as updated client configuration RPMs which will then provide access to protected repositories.

Use of unprotected repositories is a “break glass in case of emergency” course of action.

FYI: Unlike protected repositories, unprotected repositories that differ only in processor architecture are not consolidated into a single entitlement (because no entitlement is requiredto access an unprotected repository). This makes the use of separate i386 and x86_64 variants of an unprotected repository less convenient than the use of separate protected repositories.

This, along with the “break glass” nature of unprotected repositories and the fact that the content distributed via an unprotected repository will almost certainly be architecture-independent configuration RPMs, leads to the recommendation that unprotected repositories not be separated into i386 and x86_64 variants.

client-all-x86_64 – A protected repository that can be used to distribute packages to 64-bit clients of any profile. (A corresponding 32-bit repository is created in section 11.2.)

client-all-unprotected – An unprotected repository that is included in all client profiles.

Use the RHUI Manager to create the custom repositories, using the information in Table 10-0.



RHUI Server Custom RepositoriesUnique ID client-rhui-x86_64 client-rhui-unprotected

Display NameProtected repo for 64-bit RHUI servers (client-rhui-x86_64)

Unprotected repo for RHUI servers(client-rhui-unprotected)

Repository Path /client/rhui/x86_64 /client/rhui/unprotected

Checksum Algorithm SHA256 SHA256Entitlement Required? Yes NoEntitlement Path /client/rhui/$basearch

GPG Checking Yes NoGPG Public Key /root/rpm-gpg/rhui-client-rhui

All-Client Custom RepositoriesUnique ID client-all-x86_64 client-all-unprotected

Display NameProtected repo for all 64-bit RHUI clients (client-all-x86_64)

Unprotected repo for all RHUI clients (client-all-unprotected)

Repository Path /client/all/x86_64 /client/all/unprotected

Checksum Algorithm SHA1 SHA1Entitlement Required? Yes NoEntitlement Path /client/all/$basearch

GPG Checking Yes NoGPG Public Key /root/rpm-gpg/rhui-client-all

Table 10-0: Custom Repository Information

1. At the Home menu, enter r to select manage repositories.

2. At the Repository Management menu enter c to select create a new custom repository.

3. When prompted for the unique ID of the repository, enter the repository name.4. If desired, a more descriptive display name can be entered for the repository.5. When prompted for the repository path, enter the repository name with hyphens replaced by slashes.6. The appropriate repository metadata checksum algorithm depends on the RHEL versions that will be

supported by the repository. Repositories that will be accessed by RHEL 5 clients must use SHA1 checksums; repositories that will only be used by RHEL 6 (or later) clients should use SHA256.

7. For a protected repository, answer y when asked whether access to the repository should require an entitlement certificate; for an unprotected repository, answer n.

8. For the protected repositories, accept the default entitlement path. The processor architecture (x86_64) should be replaced by $basearch.

9. When asked whether the repository should require GPG checking, answer y for protected repositories; answer n for unprotected repositories.

10. For protected repositories only:

Answer n when asked if the repository will host Red Hat-signed content,

Answer y when asked if the repository will host custom-signed content,

Enter the full path to the appropriate GPG public key, and

Answer n to the question about another public key.

11. A summary of the repository to be created will be displayed. If everything is correct, enter y to proceed.

12. Repeat steps 2 through 11 to create the other three custom repositories.

10.3 Create Entitlement Certificate

Before creating an entitlement certificate, all repositories to be included in the certificate must be associated with the CDS cluster from which clients using the certificate will download content. Follow the steps in section 8.7 to associate the newly created custom repositories with a CDS cluster.

Use the RHUI Manager to create a client entitlement certificate for the RHUI servers.



1 At the Home menu, enter e to select create entitlement certificates and client configuration RPMs.

26. At the Client Entitlement Management menu, enter e to select generate an entitlement certificate.

27. Select the desired CDS cluster.28. At the repository selection list, select the protected custom repositories that were created in previous section,

along with the Red Hat Enterprise Linux 6 and Red Hat Update Infrastructure 2 repositories.

Custom Repositories

x 1 : /client/rhui/$basearch

Protected repo for RHUI servers

x 2 : /client/all/$basearch

Protected repo for all x86_64 RHUI clients

Red Hat Repositories

- 3 : Red Hat Enterprise Linux 5 Server Beta from RHUI (Debug RPMs)

- 4 : Red Hat Enterprise Linux 5 Server Beta from RHUI (RPMs)

- 5 : Red Hat Enterprise Linux 5 Server Beta from RHUI (Source RPMs)

- 6 : Red Hat Enterprise Linux 5 Server from RHUI (Debug RPMs)

- 7 : Red Hat Enterprise Linux 5 Server from RHUI (RPMs) *

- 8 : Red Hat Enterprise Linux 5 Server from RHUI (Source RPMs)

- 9 : Red Hat Enterprise Linux 6 Server - Optional Beta from RHUI (RPMs)

- 10: Red Hat Enterprise Linux 6 Server - Optional Beta from RHUI (Source RPMs)

- 11: Red Hat Enterprise Linux 6 Server - Optional Beta from RHUI(Debug RPMs)

- 12: Red Hat Enterprise Linux 6 Server - Optional from RHUI (Debug RPMs)

- 13: Red Hat Enterprise Linux 6 Server - Optional from RHUI (RPMs) *

- 14: Red Hat Enterprise Linux 6 Server - Optional from RHUI (Source RPMs)

- 15: Red Hat Enterprise Linux 6 Server Beta from RHUI (Debug RPMs)

- 16: Red Hat Enterprise Linux 6 Server Beta from RHUI (RPMs)

- 17: Red Hat Enterprise Linux 6 Server Beta from RHUI (Source RPMs)

- 18: Red Hat Enterprise Linux 6 Server from RHUI (Debug RPMs)

x 19: Red Hat Enterprise Linux 6 Server from RHUI (RPMs) *

- 20: Red Hat Enterprise Linux 6 Server from RHUI (Source RPMs)

- 21: Red Hat Update Infrastructure 1.2 (Debug RPMs)

- 22: Red Hat Update Infrastructure 1.2 (RPMs)

- 23: Red Hat Update Infrastructure 1.2 (Source RPMs)

- 24: Red Hat Update Infrastructure 2 (Debug RPMs)

x 25: Red Hat Update Infrastructure 2 (RPMs) *

- 26: Red Hat Update Infrastructure 2 (Source RPMs)

29. Enter c to confirm the selection.

30. When prompted for the name of the certificate, enter rhui.



31. When prompted for the local directory in which to save the certificate, enter /root/rhui-clients/rhui.

32. When prompted for the certificate lifetime (the number of days the certificate should be valid), enter a value such as 3650 (10 years), but ensure that the client entitlement certificate lifetime does not extend beyond the lifetime of the client CA certificate (or any of the certificates in its CA chain).

33. The entitlements to be included in the certificate will be displayed. If everything is correct, enter y to proceed.

34. When prompted for a pass phrase, enter the pass phrase of the client CA private key.

10.4 Create Client Configuration RPM

Create the client configuration RPM.

1. At the Client Entitlement Management menu, enter c to select create a client configuration RPM from an entitlement certificate.

2. When prompted for a local directory in which to store the generated files, enter /root/rhui-clients/rhui.

3. When prompted for the name of the RPM, enter rhui-client-rhui.

4. When prompted for the version of the configuration RPM, accept the default (2.0).

5. When prompted for the path the entitlement certificate, enter /root/rhui-clients/rhui/rhui.crt.

6. When prompted for the path to the private key, enter /root/rhui-clients/rhui/rhui.key.

7. Select the CDS cluster from which the clients will download content. This must be the same cluster that was selected in step 27 of the previous section.

8. When prompted, select a CDS to serve as the primary load balancer. If one CDS is better suited for the role because of capacity or network topology, select that CDS.

9. When presented with a selection list for unprotected repositories, select the two unprotected repositories that were created in section 10.2 and enter c to confirm the selections.

The client configuration package is written to a subdirectory of the location that was entered in step 2. Locate the package, move it to a more convenient location, and sign it with the appropriate GPG key.

# cd /root/rhui-clients/rhui

# find . –name '*.rpm'

./rhui-client-rhui-2.0/build/RPMS/noarch/rhui-client-rhui-2.0-1.noarch.rpm

# mv ./rhui-client-rhui-2.0/build/RPMS/noarch/rhui-client-rhui-2.0-1.noarch.rpm .

# rpmsign --define '_gpg_name rhui-client-rhui' --addsign \

rhui-client-rhui-2.0-1.noarch.rpm

Note: _gpg_name is normally defined in ~/.rpmmacros , on the assumption that a user will only ever use a single key to sign packages. Specifying the GPG user ID on the command line allows multiple keys to be used.

10.5 Push RPM to Custom Repository

1. From the RHUI Manager Home menu, enter r to select manage repositories.

2. From the Repository Management menu, enter u to select upload content to a custom repository.

3. Select Protected repo for 64-bit RHUI servers (client-rhui-x86_64) and enter c to confirm.

4. When prompted for the package location, enter /root/rhui-clients/rhui.

5. The client configuration RPM filename will be displayed. Enter y to proceed.


10.6 Perform a CDS Sync

The RHUI servers will not be able to “self-update” until the new custom repositories have been synced to the CDSservers. (See section 8.8.)



FYI: Even though the RHUI servers will not be downloading any updates from the custom repositories at this time, they must be synced to the CDS servers to avoid SSL errors.

yum will not present an SSL client certificate when attempting to download the metadata for an unprotected repository, but the CDS will not allow the connection, because it has not yet been configured to allow unrestricted access to that path. (All CDS content is protected by default.)

10.7 Configure CDS Servers for Updates

Copy /root/rhui-clients/rhui/rhui-client-rhui-2.0-1.noarch.rpm from the RHUA to each CDS.

On the CDS, delete the temporary repo file and unmount the RHEL 6 installation media.

# rm –f /etc/yum.repos.d/temp.repo

# umount /mnt/rhel

# rmdir /mnt/rhel

Install the client configuration package and apply updates.

# rpm -ihv rhui-client-rhui-2.0-1.noarch.rpm

Preparing... ########################################### [100%]

1:rhui-client-rhui ########################################### [100%]

# yum update

…

Verify that the client configuration RPM is visible in the custom repository.

# yum list extras

…

Extra Packages

rhui-cfg-cds1.noarch 2.0-2.el6 installed

The rhui-client-rhui package should not be listed. (The CDS configuration package should be listed, because it is not present in any yum repository.)

10.8 Configure the RHUA for Updates

The steps in this section are optional. It is perfectly acceptable for the RHUA to continue to download updated packages directly from the Red Hat CDN.

Disable the CDN-based Red Hat Enterprise Linux and Red Hat Update Infrastructure repositories and install the client configuration RPM.

# yum-config-manager --disable rhel-6-server-rhui-rpms rhel-x86_64-6-rhui-2-rpms

…

# rpm –ihv /root/rhui-clients/rhui/rhui-client-rhui-2.0-1.noarch.rpm

Preparing... ########################################### [100%]

1:rhui-client-rhui ########################################### [100%]



11 STEP 9 – CREATE OTHER CLIENT PROFILES

See section 3.5. As an example, this guide discusses the steps required to support two client profiles – Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6. Each profile can be used for either 32- or 64-bit clients.

11.1 GPG Keys

Create a GPG key for each profile. (See section 10.1.)

rhui-client-rhel5 – 1,024-bit DSA (sign only)

rhui-client-rhel6 – 4,096-bit RSA (sign only)

Export the public keys as /root/rpm-gpg/rhui-client-rhel5 and /root/rpm-gpg/rhui-client-rhel5.

11.2 Custom Repositories

Follow the steps in section 10.2 to create the required custom repositories. For completeness, create a 32-bit “all clients” protected repository.

Red Hat Enterprise Linux 5 – Protected RepositoriesUnique ID client-rhel5-i386 client-rhel5-x86_64

Display NameProtected repo for 32-bit RHEL 5 clients (client-rhel5-i386)

Protected repo for 64-bit RHEL 5 clients (client-rhel5-x86_64)

Repository Path /client/rhel5/i386 /client/rhel5/x86_64

Checksum Algorithm SHA1 SHA1Entitlement Required? Yes YesEntitlement Path /client/rhel5/$basearch /client/rhel5/$basearch

GPG Checking Yes YesGPG Public Key /root/rpm-gpg/rhui-client-rhel5 /root/rpm-gpg/rhui-client-rhel5

Red Hat Enterprise Linux 5 – Unprotected RepositoryUnique ID client-rhel5-unprotected

Display NameUnprotected repo for all RHEL 5 clients (client-rhel5-unprotected)

Repository Path /client/rhel5/unprotected

Checksum Algorithm SHA1Entitlement Required? NoGPG Checking No

Table 11-1: Red Hat Enterprise Linux 5 Custom Repositories



Red Hat Enterprise Linux 6 – Protected RepositoriesUnique ID client-rhel6-i386 client-rhel6-x86_64

Display NameProtected repo for 32-bit RHEL 6 clients (client-rhel6-i386)


Repository Path /client/rhel6/i386 /client/rhel6/x86_64

Checksum Algorithm SHA256 SHA256Entitlement Required? Yes YesEntitlement Path /client/rhel6/$basearch /client/rhel6/$basearch

GPG Checking Yes YesGPG Public Key /root/rpm-gpg/rhui-client-rhel6 /root/rpm-gpg/rhui-client-rhel6

Red Hat Enterprise Linux 6 – Unprotected RepositoryUnique ID client-rhel6-unprotected

Display NameUnprotected repo for all RHEL 6 clients (client-rhel6-unprotected)

Repository Path /client/rhel6/unprotected

Checksum Algorithm SHA256Entitlement Required? NoGPG Checking No

Table 11-2: Red Hat Enterprise Linux 6 Custom Repositories

32-Bit All-Client Protected RepositoryUnique ID client-all-i386

Display NameProtected repo for all 32-bit RHUI clients (client-all-i386)

Repository Path /client/all/i386

Checksum Algorithm SHA1Entitlement Required? YesEntitlement Path /client/all/$basearch

GPG Checking YesGPG Public Key /root/rpm-gpg/rhui-client-all

Table 11-3: 32-Bit All-Client Protected Repository

11.3 Entitlement Certificates

Create an entitlement certificate for each client profile. (See section 10.3.)

11.3.1 Red Hat Enterprise Linux 5

The Red Hat Enterprise Linux 5 entitlement certificate should contain at least the following repositories. (Additional Red Hat or custom repositories can be added if appropriate.)

/client/rhel5/$basearch

Protected repo for 32-bit RHEL 5 clients (client-rhel5-i386)


/client/all/$basearch

Protected repo for all 32-bit RHUI clients (client-all-i386)

Protected repo for all 64-bit RHUI clients (client-all-x86_64)

Red Hat Enterprise Linux 5 Server from RHUI (RPMs)

The name of the certificate (and key) should be rhel5, and it should be saved in /root/rhui-clients/rhel5.



11.3.2 Red Hat Enterprise Linux 6

The Red Hat Enterprise Linux 6 entitlement certificate should contain at least the following repositories. (Additional Red Hat or custom repositories – such as the Optional or Supplementary repositories – can be added ifappropriate.)

/client/rhel6/$basearch

Protected repo for 32-bit RHEL 6 clients (client-rhel6-i386)


/client/all/$basearch

Protected repo for all 32-bit RHUI clients (client-all-i386)

Protected repo for all 64-bit RHUI clients (client-all-x86_64)

Red Hat Enterprise Linux 6 Server from RHUI (RPMs)

The name of the certificate (and key) should be rhel6, and it should be saved in /root/rhui-clients/rhel6.

11.4 Client Configuration RPMs

See section 10.4. Add additional unprotected repositories as appropriate.

Red Hat Enterprise Linux 5 RPM:

Directory – /root/rhui-clients/rhel5

RPM Name – rhui-client-rhel5

Entitlement Certificate – /root/rhui-clients/rhel5/rhel5.crt

Private Key – /root/rhui-clients/rhel5/rhel5.key

Unprotected Repositories


Unprotected repo for all RHEL 5 clients (client-rhel5-unprotected)

Red Hat Enterprise Linux 6 RPM:

Directory – /root/rhui-clients/rhel6

RPM Name – rhui-client-rhel6

Entitlement Certificate – /root/rhui-clients/rhel6/rhel6.crt

Private Key – /root/rhui-clients/rhel6/rhel6.key

Unprotected Repositories


Unprotected repo for all RHEL 6 clients (client-rhel6-unprotected)

Sign each package with the appropriate key that was created in section 11.1.

Push the rhui-client-rhel5 RPM to both of the RHEL 5 protected repositories, client-rhel5-i386 and client-rhel5-x86_64, and push the rhui-client-rhel6 RPM to client-rhel6-i386 and client-rhel6-x86_64.

Sync the appropriate CDS cluster.



12 STEP 10 – CREATE CLIENT IMAGES/TEMPLATES

The exact nature of the RHEL images to be created depends on the technology stack in your environment. In all cases, however, the goal is to create an artifact (image, template, etc.) that, will meet certain criteria when instantiated.

12.1 Image Requirements

Note the following requirements for certified cloud images (most of which are default behaviors/configurations).

Red Hat packages may not be altered, rebuilt, or replaced.

SELinux should be enabled, in enforcing mode.

iptables should be blocking access to all ports other than ssh (and any other ports required for proper operation of the cloud infrastructure).

Local passwords should use a hashing algorithm at least as strong as the default for that Red Hat Enterprise Linux version (MD5 for RHEL 5, SHA-512 for RHEL 6).

Disk size should be at least 6GB.

Filesystem type should be ext3 (RHEL 5), ext4 (RHEL 6), or xfs (RHEL7)

sshd should be enabled for remote access.

syslog configuration should be unchanged from the OS default.

12.2 RHUI Integration

Integrate the image with the RHUI by performing the following steps by transferring the RHUI entitlement RPM and GPG Key to the target RHEL client system.

Install the appropriate client configuration RPM (yum install <rhui-client-rhel5,6,etc>).

Import the Red Hat release GPG key (/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release) into RPM, along with any custom repository keys.

Import the entitlement RPM GPG key (rpm –import <rhui-client-rhui>)

Updates will come from RHUI vs. Red Hat Subscription Manager (rhsm); therefore, turn off rhsm (edit /etc/yum/pluginconf.d/rhsm.conf, enabled=1 )

Optionally (but strongly recommended), use yum update to apply all available updates.

12.3 Template Preparation

Finally, the image must be sanitized to make it suitable for use as a template. Appendix B contains a script that can be used for this purpose. It is compatible with both RHEL 5 and RHEL 6 images.

Note: The script may require modification in some environments.

Copy the script to /mktemplate.sh and reboot the system to runlevel 1.

Note: It is not sufficient to change to runlevel 1 (with init 1 , for example). Changing to runlevel 1 leaves certain daemons running that are not running when the system is booted to single-user mode (notably rsyslog ).

When the system has rebooted into single-user mode, execute the following commands.

# unset HISTFILE

# chmod 0755 /mktemplate.sh

# /mktemplate.sh

# rm –f /mktemplate.sh



# poweroff



13 STEP 11 – SUBMIT IMAGE CERTIFICATION REQUESTS

The CCP agreement requires that the images (templates) from which tenant instances are created be certified by Red Hat. This ensures a fully supported configuration for end customers.

13.1 Submit Bugzilla Account

As described earlier, image certification results are submitted to an account at https://bugzilla.redhat.com/. If not already in place, a Bugzilla account should be created. This account then needs to be sent to your Red Hat account team for submission to "cloudcert-services" <[email protected]> for tagging to accept image certification data.

13.2 Cloud Provider Certification Workflow

The full certification workflow is now documented onlne at:

Certified Cloud Provider Certification Workflow

https://access.redhat.com/articles/1302363#SubscribetoRedHatCertificationChannel

Most RHUI users will leverage the installation method described in Section 1 under the header “Install the Certification Test Suite from the Red Hat Customer Portal”. This method installs the certification packages via download and copy to the image being used for certification

13.3 Cloud Provider Certification Website

After certifications have been reviewed by Red Hat, a pass/fail will be assigned to the Bugzilla entries and certification will be posted to on the public Red Hat certification website at https://access.redhat.com/certifications.


https://access.redhat.com/articles/1302363#SubscribetoRedHatCertificationChannel

https://access.redhat.com/certifications

mailto:[email protected]

https://bugzilla.redhat.com/


14 APPENDICES

This section contains the following appendices.

Appendix A RHUI Monitoring Script

Appendix B Template Preparation Script

Appendix C RHUI Pre-requisites



14.1 Appendix A: RHUI MONITORING SCRIPT

Note: This script makes use of the mail command, which is provided by the mailx package.

It may also be necessary to configure the MTA on the RHUA to use the cloud provider’s SMTP server.

#!/bin/bash

# Address to which any error reports should be sent

ADMIN_EMAIL=

# RHUI credentials

RHUI_USERNAME=admin

RHUI_PASSWORD=

###############################################################################

TEMP_FILE=`mktemp`

if rhui-manager --username $RHUI_USERNAME --password $RHUI_PASSWORD status > \

$TEMP_FILE; then

rm -f $TEMP_FILE

exit 0

fi

# Remove ANSI escape sequences from output

sed -i -r 's/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g' $TEMP_FILE

cat $TEMP_FILE | mail -s 'RHUI Error' $ADMIN_EMAIL

rm -f $TEMP_FILE

exit 0



14.2 Appendix B: TEMPLATE PREPARATION SCRIPT

This script can be used to “sanitize” a VM image, in preparation for use as a template. See section 12.3.

Note: Review this script carefully before use, and ensure that the changes it makes to the image are compatible with your environment.

#!/bin/bash

if [ "`runlevel`" != '1 S' ]; then

echo "Please *boot* to runlevel 1"

exit 1

fi

# RHEL 5

if service syslog status &> /dev/null; then


exit 2

fi

# RHEL 6

if service rsyslog status &> /dev/null; then


exit 3

fi

# Kill udev

killall -9 udevd

# Clean out /root

rm -rf /root/*

rm -f /root/.bash_history

rm -rf /root/.ssh

# SSH host keys

rm -f /etc/ssh/ssh_host_*

# Remove all files in /var that are not owned by an RPM

for FILE in `find /var -type f`; do

rpm -qf --quiet "$FILE" || rm -f "$FILE"



done

# Remove empty directories in /var that are not owned by an RPM

until [ "$REMOVED_DIR" = false ]; do

REMOVED_DIR=false

for DIR in `find /var -type d -empty`; do

if ! rpm -qf --quiet "$DIR"; then

REMOVED_DIR=true

rmdir "$DIR"

fi

done

done

# Truncate any remaining files in /var/log

for FILE in `find /var/log -type f`; do

echo -n > "$FILE"

done

# Make sure the RPM GPG key has been imported

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release 2> /dev/null

# Remove MAC addresses from /etc/sysconfig/network-scripts/ifcfg-*

for FILE in /etc/sysconfig/network-scripts/ifcfg-*; do

sed -i /^HWADDR/d "$FILE"

done

# Remove auto-generated udev rules for CD-ROM and network devices

rm -f /etc/udev/rules.d/70-persistent-{cd,net}.rules

# Clean out /tmp

rm -rf /tmp

mkdir /tmp

chmod 1777 /tmp

restorecon /tmp



14.3 Appendix C: RHUI PREREQUISITES

RHUI Architecture (Reviewed)


Red Hat CDN(cdn.redhat.com)

Red Hat CDN(cdn.redhat.com)

RHUARHUA

Grinder (HTTPS)

CDS/LBCDS/LB CDS/LBCDS/LB CDS/LBCDS/LB

CDS Cluster

RHELInstance

RHELInstance

RHELInstance

RHELInstance

RHELInstance

RHELInstance

QPID/HTTPS for Command & ControlGrinder (HTTPS) for Content Sync

RHELInstance

RHELInstance

YUM/HTTPS

Ports: 443,5674

Ports: 443

Manual RPM Uploads (Custom Repositories)

Red Hat Update Infrastructure (RHUI)

Ports: 443


Client will provide the following technical prerequisites:

Completion of the initial stages of the Red Hat Certified Cloud Provider (RHCCP) certification, including:

Review of Client's virtualization, image creation, and instance provisioning technologies, tools, and processes

Review of Client's proposed process for measuring and reporting consumption of Red Hat software

Review of Client's proposed process for notifying customers of errata updates to Red Hat software

Review of Client's proposed process for making images which include Red Hat software available to customers, including image lifecycle management and retiring outdated images.

Creation of a Red Hat bugzilla account for image certification at http://bu g zilla.redhat.com. Send this account to your Red Hat solution architect for processing.

Self-signed certificates are typically used for RHUI deployment. If SSL certificates signed by a third-party certificate authority will be used, they have been obtained by Client and reviewed by Red Hat. (The Red Hat Consultant can assist with the development of self-signed certificates, and their use will not affect the user experience of Client's customers.)

Client will provide systems, virtual machines, or tenant instances for installation of all Red HatUpdate Appliances (RHUA’s), external Load Balancers, and Content Distribution Servers (CDS’s), configured as described below.

RHUI Installation includes 3 REQUIRED servers: 1x RHUA and 2x CDS’s (physical or virtual) as follows:

◦ RHEL 6.4 or greater with ‘Minimal’ install recommended, SELinux On

◦ 2 CPUs, x86_64 processor architecture

◦ 4 GB memory minimum

◦ 6 GB disk for OS

◦ 50 GB disk per major RHEL release (i.e. RHEL5 64-bit + RHEL6 64-bit= 100GB) , mounted as a logical volume at /var

▪ Full path on RHUA: /var/lib/pulp; Full path on CDS: /var/lib/pulp-cds

Certification Generation using 'openssl' requires 1 server, new or existing, configured as follows:

◦ RHEL 6.4 or greater with ‘Minimal’ install recommended, SELinux On

◦ 2 CPUs, x86_64 processor architecture

◦ 2 GB memory

◦ 6 GB disk for OS






Image certification is performed on RHEL guest templates as provided

Typically 1x RHEL 5 guest, 1x RHEL 6 guest, 1x RHEL7 guest

◦ Minimum 6GB disk for OS

◦ iptables 'on'

◦ SELinux 'on'

◦ If password authentication is turned on, must use strongest possible hash

◦ Default logging turned on

Client's network must be properly configured for the Red Hat Update Infrastructure (RHUI).

◦ IP addresses must be allocated for all Red Hat Update Appliances (RHUAs), external Load Balancers (if any), and Content Distribution Servers (CDS’s).

◦ DNS records (forward and reverse) have been created for all IP addresses.

▪ Example: rhua.company.com, cds1.company.com, cds2.company.com, certs.company.com

▪ If the server has multiple NIC's, the FQDN of the RHUA and CDS's must be resolved to the IP of the NIC which is used for communication between RHUA and CDS's.

◦ All required network ports are open.

▪ The Red Hat Update Appliance(s) can connect to the Red Hat content delivery network (*.redhat.com) via HTTPS (443/tcp).

▪ The Red Hat Update Appliance(s) can connect to the Content Distribution Server(s) via AMQPS (5674/tcp).

▪ The Content Distribution Server(s) can connect to the Red Hat Update Appliance(s) via HTTPS (443/tcp) and AMQPS (5674/tcp).

▪ Tenant instances can connect to the Content Distribution Server(s) via HTTPS (443/tcp).

◦ Network proxy settings are configured appropriately.

▪ Between RHUA and CDN (cdn.redhat.com): via RHUI installation answers file

▪ Between CDS's and clients: via yum.conf
