Chapter 14. Manage Content

Red Hat Update Infrastructure (RHUI) can be configured to create and use a repository that will update the RHUI installation. The Red Hat Update Infrastructure Management Tool can create the repository and generate an entitlement certificate and client configuration RPM. The RPM is installed on the Red Hat Update Appliance (RHUA) and each content delivery server (CDS) node. Future updates can be downloaded and installed using yum update.

14.1. Available Channels

Red Hat’s Certified Cloud & Service Provider (CCSP) Partners control what channels and packages are delivered through their service. See this Knowledgebase article for the most current information regarding what channels are available. The repositories are available for use with:

  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 7 for SAP Applications
  • Red Hat Enterprise Linux 7 for SAP HANA
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 6 for SAP Applications
  • Red Hat Enterprise Linux 6 for SAP HANA
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 5 Extended Life Cycle Support

Contact your CCSP if a required channel is missing. You can learn more about what is available by browsing the Certification Catalog.

14.2. Manage the Linux Software Repositories

A repository is a server node that contains downloadable software for a Linux distribution. You use yum to search for, install, and control RPMs from the repository to your RHUA and CDS nodes.

14.2.1. List the Available Repositories

  1. Navigate to the Red Hat Update Infrastructure Management Tool. 

    [root@rhua ~]# rhui-manager
  2. In the Red Hat Update Infrastructure Management Tool home screen, press r to select manage repositories.

  3. Press l to select list repositories currently managed by the RHUI. 

                                                  	Connected: rhua.example.com

------------------------------------------------------------------------------
rhui (repo) => l

14.2.2. Display the Repository Information

You can use the Repository Management screen to display information about a particular repository.

  1. From the Repository Management screen, press i. The output contains all repositories that are managed by Red Hat Update Infrastructure.
  2. Select which repository to view by typing the repository’s number at the prompt. Typing the number of a repository places a checkmark next to the name of that repository. You can also choose the range of repositories, for instance, by entering 1 - 5.
  3. Continue until all repositories you want to view are checked.

  4. Press c at the prompt to confirm. 

    Name:            		RHEL RHUI Server 7 Containers (7Server-x86_64)
Type:	            	Red Hat
Relative Path:   	content/dist/rhel/rhui/server/7/7Server/x86_64/containers/
GPG Check:       	Yes
Custom GPG Keys: 	(None)
Red Hat GPG Key: 	Yes
Package Count:   	0
Last Sync:       		Never
Next Sync:       	11-30-2015 19:38

14.2.3. Add a Red Hat Repository

Load the specific repositories for entitled products before you add a new Red Hat repository.

See Section 9.1, “Create a Repository” for details.

14.2.4. Delete a Red Hat Repository

When the Red Hat Update Infrastructure Management Tool deletes a Red Hat repository, it deletes the repository from the RHUA and all applicable CDS nodes.

Note

The repository content remains on the disk and takes up disk space. This content is known as an orphan content unit, or an orphan for short. See Section 14.3, “Orphaned Content Units” for more details.

  1. From the Repository Management screen, press d at the prompt to delete a Red Hat repository. A list of all repositories currently being managed by RHUI displays.
  2. Select which repositories to delete by typing the number of the repository at the prompt. Typing the number of a repository places a checkmark next to the name of that repository. You can also choose the range of repositories, for instance, by entering 1 - 5.
  3. Continue until all repositories you want to delete are checked.

  4. Press c at the prompt to confirm.

    Note

    After you delee the repositories, the client configuration RPMs that refer to the deleted repositories will not be available to be used by yum.

14.2.5. List the RPM Packages in a Repository

When listing repositories within the Red Hat Update Infrastructure Management Tool, only repositories that contain fewer than 100 packages display their contents. Results with more than 100 packages only display a package count.

  1. To see a complete list, regardless of how many packages are contained within a repository, press r at the Home screen to access the Repository Management screen.
  2. Press p to select list packages in a repository (RPM content only).
  3. Select the number of the repository you want to view. The Red Hat Update Infrastructure Management Tool asks if you want to filter the results. Leave the line blank to see the results without a filter.
  4. Alternatively, type the first few letters of the RPM name you are looking for to filter the results.

14.2.6. Create a Custom Repository

Use a protected repository or 64-bit RHUI servers when you are distributing new non-Red Hat packages to RHUI servers. For example, use client-rhui-x86_64 if you are distributing an updated client configuration package.

Like Red Hat content repositories, all of which are protected, protected custom repositories that differ only in processor architecture (i386 versus AMD64) are consolidated into a single entitlement within an entitlement certificate, using the $basearch yum variable.

If certificate validation prevents access, you can use an unprotected server repository to distribute RPMs to the RHUI servers.

  1. From the Repository Management screen, press c to access the create a new custom repository (RPM content only) screen.
  2. Enter a unique ID for the repository. Only alphanumeric characters, _ (underscore), and - (hyphen) are permitted. You cannot use spaces in the unique ID. For example, repo1, repo_1, and repo-1 are all valid entries.
  3. Enter a display name for the repository. This name is used to identify the repository within the Red Hat Update Infrastructure Management Tool.
  4. Specify the path that will host the repository. The path must be unique across all repositories hosted by Red Hat Update Infrastructure. For example, if you specify the path at this step as some/unique/name, then the repository will be located at //<server>/pulp/repos/some/unique/name.
  5. Select sha256 as the checksum type to be used for the repository metadata.

  6. Choose whether to protect the new repository. If you answer no to this question, any client can access the repository. If you answer yes, only clients with an appropriate entitlement certificate can access the repository.

    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. Be careful when using 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.

  7. If you choose to protect the new repository, the Red Hat Update Infrastructure Management Tool will ask for the entitlement path. It will also suggest the entitlement path based on the repository’s relative path.

    Client entitlement certificates contain the download URLs that they are allowed to access. The RHUI analyzes the contents of the certificate to determine if the repository requested matches any of the permitted URLs, which determines whether to allow the client to authenticate. For example, if an entitlement certificate grants access to /some/unique/name and the request is made to a repository located at //server/pulp/repos/some/unique/name/os/repodata, RHUI will approve the request and grant the authentication because the path begins with one of the entitled download URLs. The URL only needs to begin with the correct information; it does not need to match exactly.

    Entitlements can also contain variables, as long as yum knows the value for the variable. The two most common variables to use are $basearch and $releasever, which are populated with details of the client making the request. For example, if an entitlement certificate grants access to /unique-name/$basearch/bar and the request is made to a repository located at //server/pulp/repos/unique-name/x86_64/bar, RHUI will approve the request and grant the authentication because the path matches when the variable is populated.

    The Red Hat Update Infrastructure Management Tool suggests a path to use based on the variables you used when you gave it a path for the repository. Leave the field blank to accept the suggested path.

    The Red Hat Update Infrastructure Management Tool will ask if you want GNU Privacy Guard (GPG) signature turned on for content in that repository. If you press y, you will be asked if the content will be signed by Red Hat. Answering yes will include Red Hat’s GPG key in the repository configuration. You are then asked if the content will be signed by a custom GPG key. Answering yes will prompt for a path to a public GPG key to include in the repository configuration. You can continue entering multiple paths to public GPG keys. 

    Should the repository require clients to perform a GPG check and verify packages are signed by a GPG key? (y/n) y

Will the repository be used to host any Red Hat GPG signed content? (y/n) y

Will the repository be used to host any custom GPG signed content? (y/n) y

Enter the absolute path to the public key of the GPG key pair:

/tmp/rhuitest1.gpg

Would you like to enter another public key? (y/n) y

Enter the absolute path to the public key of the GPG key pair:
/root/rpm-gpg/rhui-client-rhui.gpg

Would you like to enter another public key? (y/n) n
  8. The details of the new repository display. Press y at the prompt to confirm the information and create the repository.

14.2.7. Upload Packages to a Custom Repository

You can upload multiple packages at a time and to upload to more than one repository at a time. Packages are uploaded to the RHUA immediately but are not available on the CDS node until the next time the CDS node synchronizes.

  1. From the Repository Management screen, press u at the prompt to upload new packages to a particular repository. A list of all available custom repositories displays.

    Note

    You cannot upload packages to Red Hat repositories.

  2. Select which custom repository to add the packages to by typing the number of the repository at the prompt. Typing the number of a repository places a checkmark next to the name of that repository. Continue until all repositories you want to add to have been checked.
  3. Press c at the prompt to confirm.
  4. Specify the location of the RPMs to upload. This can be a single .rpm file, or it can be a directory containing several .rpm files. If you specify a directory, all .rpm files in that directory are uploaded. The details of the new packages to upload display.

  5. Press y at the prompt to confirm the information and upload the packages. 

    The following RPMs will be uploaded:

origin-1.0-1.noarch.rpm
parent-1.0-1.noarch.rpm
patb-0.1-2.x86_64.rpm
rh-amazon-rhui-client-rhs30-2.2.124-1.el7.noarch.rpm

Proceed? (y/n) y

14.2.8. Delete Packages from a Custom Repository

  1. From the Repository Management screen, press p to list packages in a repository (RPM content only). Enter the number of the custom repository that you want to delete packages from and press Enter. 

    rhui (repo) => p

Choose a repository:
  1  - HP Packages for Testing
Enter value (1-1) or 'b' to abort: 1

Enter the first few characters (case insensitive) of an RPM to filter the results
(blank line for no filter):


Only filtered results that contain less than 100 packages will have their
contents displayed. Results with more than 100 packages will display
a package count only.

Packages:
  hprest-1.5-79.x86_64.rpm
  hpsum-7.6.0-86.rhel7.x86_64.rpm
  ilorest-2.2.2-6.x86_64.rpm         <========== Goal, delete this package
  sum-8.2.0-53.rhel7.x86_64.rpm

  2. Use the pulp-admin command to list the repository information, including the repo_id. 

    # pulp-admin --username admin --password "redhat" repo list --snip--
Id:                              custom_repo1
Display Name:           HP Packages for Testing
Description:               HP Packages for Testing
Content Unit Counts:
  Rpm: 4

  3. List the package information. 

    # pulp-admin --username admin --password "redhat" rpm repo content rpm --repo-id "custom_repo1" --str-eq="filename=ilorest-2.2.2-6.x86_64.rpm"

Arch:         x86_64
Buildhost:    bls11u3x64001.sde.rdlabs.hpecorp.net
Checksum:     570b98fff1943819e554ff5d643f674a1aa00fc1b362900badfdc4bd0943ce06
Checksumtype: sha256
Description:  Command line interface for managing HPE ProLiant Servers  Authors:
              --------     Hewlett Packard Enterprise
Epoch:        0
Filename:     ilorest-2.2.2-6.x86_64.rpm
License:      Copyright 2016 Hewlett Packard Enterprise Development LP
Name:         ilorest
Provides:     config(ilorest) = 2.2.2-6-0, ilorest = 2.2.2-6-0, ilorest(x86-64)
              = 2.2.2-6-0, ilorest_chif.so()(64bit)
Release:      6
Requires:     /bin/sh, /bin/sh, libc.so.6()(64bit),
              libc.so.6(GLIBC_2.2.5)(64bit), libc.so.6(GLIBC_2.3)(64bit),
              libdl.so.2()(64bit), libdl.so.2(GLIBC_2.2.5)(64bit),
              libz.so.1()(64bit), rtld(GNU_HASH)
Vendor:       Hewlett Packard Enterprise Company
Version:      2.2.2

  4. Delete the package from the custom repository. 

    # pulp-admin --username admin --password "redhat" rpm repo remove rpm --repo-id "custom_repo1" --str-eq="filename=ilorest-2.2.2-6.x86_64.rpm"
This command may be exited via ctrl+c without affecting the request.

[\]
Running...

Units Removed:
  ilorest-2.2.2-6-x86_64

  5. Update the metadata and publish the repository. 

    # pulp-admin  --username admin --password "redhat" rpm repo update --repo-id "custom_repo1"
# pulp-admin --username admin --password "redhat"  rpm repo publish run --repo-id "custom_repo1"
  6. Remove the orphaned RPM disassociated from the repository and reclaim disk space as described in Section 14.3, “Orphaned Content Units”.

14.2.9. Import Errata Metadata to a Custom Repository

If you have an updateinfo.xml or updateinfo.xml.gz file containing errata metadata for the packages in a custom repository, you can import the metadata so that client systems using the repository can receive detailed information about individual updates. This detailed information contains errata IDs, bug numbers, descriptions of bug or security fixes, and references. Clients can use this data to apply updates selectively.

The import can be done only in the command line interface. Run the following command to import the data to the specified custom repository from the specified updateinfo file. 

# rhui-manager repo add_errata --repo_id my_repo --updateinfo ~/Downloads/ac4c9d01646b2100cf292a6b67672ad5
-updateinfo.xml.gz
Note

It can take a while for this command to complete, especially if the updateinfo file contains a large number of updates. Progress is logged in the /root/.rhui/rhui.log file.

Warning

Once an erratum has been imported from an updateinfo file, it cannot be imported again; that would violate the uniqueness of the errata ID as the database key. If you reimport an updateinfo file with additional errata entries, old entries remain untouched and any additional entries are added. Should you need to replace a previously added erratum, delete it in MongoDB directly before importing an updateinfo file.

14.3. Orphaned Content Units

RHUI does not delete orphaned content units (also known as orphans) when the Red Hat Update Infrastructure Management Tool deletes a repository. See Section 14.2.4, “Delete a Red Hat Repository” for more details. Orphans are package files no longer referenced by any repository but remain on the file system and consume disk space. Package files can become orphans as a result of the configuration settings or repository deletion. If you are unsure about the deletion of these content units, consider enlarging disk space instead of removing the orphans.

You can delete orphans on the RHUA and CDSs to reclaim disk space. The following procedure deletes orphans from RHUI. Perform a complete backup before using these steps.

  1. Run the following command from the RHUA to display orphaned packages. 

    [root@rhua ~]# pulp-admin -u admin -p admin orphan list

  2. Run the following command to see available arguments. 

    [root@rhua ~]# pulp-admin -u admin -p admin orphan list --help
Command: list
Description: display a list of orphaned units

Available Arguments:

  --type    - restrict to one content type such as "rpm", "errata",
              "puppet_module", etc.
  --details - include a detailed list of the individual orphaned units, ignored
              when content type is not specified

  3. There are three flags for removing orphans. 

            --type=<type> to remove all the orphaned content units of a particular type
        --id=<id> to remove a particular orphaned content unit
        --all to remove all the orphaned content units on the server

    Here is one example of how to delete an orphan. 

    [root@rhua ~]# pulp-admin orphan remove --all

  4. Run the following command to see a list of arguments. 

    [root@rhua ~]# pulp-admin -u admin -p admin orphan remove --help
Command: remove
Description: remove one or more orphaned units

Available Arguments:

  --bg      - if specified, the client process will end immediately (the task
              will continue to run on the server)
  --type    - restrict to one content type such as "rpm", "errata",
              "puppet_module", etc.
  --unit-id - ID of a content unit; if specified, you must also specify a type
  --all     - remove all orphaned units, ignoring other options

14.4. Manage the Content Delivery Server Nodes

CDS nodes are the main component of a content delivery network (CDN), offering high availability to the client. Running servers in a geographically dispersed manner can also improve response time.

The Content Delivery Server (CDS) Management screen is used to list, add, reinstall, and delete CDS nodes.

  1. In the Red Hat Update Infrastructure Management Tool home screen, press c to access the Content Delivery Server (CDS) Management screen. 

                 -= Red Hat Update Infrastructure Management Tool =-

-= Home =-

   r   manage repositories
   c   manage content delivery servers (CDS)
   l   manage HAProxy load-balancer instances
   s   synchronization status and scheduling
   e   create entitlement certificates and client configuration RPMs
   n   manage Red Hat entitlement certificates
   sm  manage Red Hat subscriptions
   u   manage RHUI users

                                                   Connected: rhua.example.com

  2. From the Content Delivery Server (CDS) Management screen, press l at the prompt to list the CDS nodes that RHUI manages. 

    ------------------------------------------------------------------------------
       	-= Red Hat Update Infrastructure Management Tool =-

-= Content Delivery Server (CDS) Management =-

l   list all known CDS instances managed by the RHUI
a   register (add) a new CDS instance
r   reinstall and reapply configuration to an existing CDS instance
d   unregister (delete) a CDS instance from the RHUI

                                	Connected: ip-10-99-206-124.ec2.internal
------------------------------------------------------------------------------
rhui (cds) =>l

-= RHUI Content Delivery Servers =-

Hostname:         	cds1.example.com
SSH Username:     	root
SSH Private Key:  	/root/.ssh/cds.rsa

Hostname:         	cds2.example.com
SSH Username:     	root
SSH Private Key:  	/root/.ssh/cds.rsa

Hostname:         	cds3.example.com
SSH Username:     	root
SSH Private Key:  	/root/.ssh/cds.rsa
------------------------------------------------------------------------------

14.5. Working with Containers

Red Hat Update Infrastructure 3.0 in a Red Hat Enterprise Linux 7 system or Red Hat Atomic Host system uses Docker to automate the deployment of applications inside Linux containers. Using Docker offers the following advantages:

  • Requires less storage and in-memory space than VMs: Because the containers hold only what is needed to run an application, saving and sharing is more efficient with Docker containers than it is with VMs that include entire operating systems.
  • Improved performance: Because you are not running an entirely separate operating system, a container typically runs faster than an application that carries the overhead of a whole new VM.
  • Secure: Because a Docker container typically has its own network interfaces, file system, and memory, the application running in that container can be isolated and secured from other activities on a host computer.
  • Flexible: With an application’s runtime requirements included with the application in the container, a Docker container can run in multiple environments.

Linux containers with docker format are supported running on hosts with SELinux enabled. SELinux is not supported when the /var/lib/docker directory is located on a volume using the B-tree file system (Btrfs).

Note

The docker API takes over the root folder (/) on the httpd instance and must run on a different port. Port 5000 is currently used, but this will be user-configurable in the future. The RHUA must know the port because the docker client uses the host name and port when finding the Certificate Authority to use for docker content.

See Get Started with Docker Formatted Container Images and Red Hat Enterprise Linux Atomic Host 7: Getting Started with Containers for more information about containers.

14.6. Manage the Content Delivery Server Docker Content

14.6.1. Docker Content in Red Hat Update Infrastructure

Docker content includes containers, images, and platform images. Currently, docker content does not have entitlement enforcement available. To put such a feature in place, the docker client must first support X.509 certificates. The implication for RHUI is that downloaded or published docker content is available publicly on the CDS’s registry.

A container is an application sandbox. Each container is based on an image that holds necessary configuration data. When you launch a container from an image, a writable layer is added on top of this image. Every time you commit a container (using the docker commit command), a new image layer is added to store your changes.

An image is a read-only layer that is never modified; all changes are made in the top-most writable layer, and it can be saved only by creating a new image. Each image depends on one or more parent images.

A platform image is an image that has no parent. Platform images define the runtime environment, packages, and utilities necessary for a containerized application to run. The platform image is read-only, so any changes are reflected in the copied images stacked on top of it.

14.6.2. Add a Container to Red Hat Update Infrastructure

The following steps describe how to add a Docker container to the client machine where docker via RHUI is going to be used. Access to docker requires access to the Red Hat Enterprise Linux Extras repository.

  1. Register the client and get subscriptions using the instructions in Chapter 4, Register Red Hat Update Infrastructure and Attach Subscriptions.

  2. Alternatively, you can register the system using Subscription Management tools and install the docker package. Also enable the software repositories needed. (Replace pool_id with the pool ID of your RHEL 7 subscription.) For example: 

    # subscription-manager register --username=rhnuser --password=rhnpasswd
# subscription-manager list --available    Find valid RHEL pool ID
# subscription-manager attach --pool=pool_id
# subscription-manager repos --enable=rhel-7-server-extras-rpms
# subscription-manager repos --enable=rhel-7-server-optional-rpms

    The current RHEL 7 release and RHEL 7 Atomic Host release each include two different versions of Docker.

    • docker: This package includes the version of Docker that is the default for the current release of RHEL. Install this package if you want a more stable version of Docker that is compatible with the current versions of Kubernetes and OpenShift available with Red Hat Enterprise Linux.

    • docker-latest: This package includes a later version of Docker that you can use if you want to work with newer features of Docker. This version is not compatible with the versions of Kubernetes and OpenShift that are available with the current release of Red Hat Enterprise Linux.

      See the Atomic Host and Containers section of the Red Hat Enterprise Linux Release Notes for more details on the contents of docker and docker-latest packages and how to enable the docker-latest package.

  3. Install and use the default docker package (along with a couple of dependent packages if they are not yet installed). 

    # yum install docker device-mapper-libs device-mapper-event-libs

    See Section 1.3. Getting Docker in RHEL 7 of the Getting Started with Containers document for more information about Docker and Red Hat Enterprise Linux and Atomic Host.

  4. Add a docker container to RHUI. 

    [root@rhua ~]# rhui-manager

  5. From the Red Hat Update Infrastructure Management Tool, press r to access the Repository Management screen. 

    -= Red Hat Update Infrastructure Management Tool =-

-= Repository Management =-

l   list repositories currently managed by the RHUI
i   display detailed information on a repository
a   add a new Red Hat content repository
ad  add a new Red Hat docker container
c   create a new custom repository (RPM content only)
d   delete a repository from the RHUI
u   upload content to a custom repository (RPM content only)
p   list packages in a repository (RPM content only)

                                      Connected: rhua.example.com

  6. Press ad to add a new Red Hat docker container. 

    rhui (repo) => ad

Name of the container in the registry:

  7. Enter the name of the container in the registry. 

    jboss-eap-6/eap64-openshift

  8. Enter a unique ID for the container.

    Note

    The rhui-manager can convert the name of the container from the registry to the format that is usable in Pulp. It does so by replacing slashes and dots with underscores. You can accept such a converted name by pressing Enter or by entering a name of your choice. 

    jboss-eap-6_eap64-openshift

  9. Enter a display name for the container. 

    jboss-eap-6_eap64-openshift
The following container will be added:
  Container Id:              jboss-eap-6_eap64-openshift
  Display Name:            jboss-eap-6_eap64-openshift
  Upstream Container Name:   jboss-eap-6/eap64-openshift
Proceed? (y/n)

  10. Press y to proceed or n to cancel. 

    y
Successfully added container JBoss_EAP_Container
  11. Press ^ to return to the Red Hat Update Infrastructure Management Tool home screen.

14.6.3. Synchronize the docker Repository

The following steps describe how to synchronize a docker repository.

  1. Press s to access the Synchronization Status screen.
  2. Press sr to synchronize an individual repository immediately.
  3. Enter the number of the repository that you wish to synchronize.
  4. Press c to confirm the selection. You can enter ? for more commands.

  5. Press y to proceed or n to cancel. 

    The following repositories will be scheduled for synchronization:
  jboss-eap-6_eap64-openshift
Proceed? (y/n) y
Scheduling sync for jboss-eap-6_eap64-openshift...
... successfully scheduled for the next available timeslot.
  6. Press ^ to return to the Red Hat Update Infrastructure Management Tool home screen.

14.6.4. Generate the docker Client Configuration

The client configuration RPM is intended for RHUI clients that should pull docker containers from RHUI. The RPM contains the load balancer’s certificate. When you install the RPM, it:

  • adds the load balancer as a docker registry.

  • modifies the docker configuration.

    1. Press e to access the Client Entitlement Management screen.
    2. Press d to create a docker client configuration RPM.

    3. Enter the full path to the local directory where the client configuration files generated will be stored. This directory will be created if it does not exist. 

      /root/

    4. Enter the name of the RPM. 

      dockertest
    5. Enter the version number of the configuration RPM. The default is 2.0.

    6. Enter the port that will serve docker content. The default is 5000. 

      Successfully created client configuration RPM.
Location: /root/dockertest-2.0/build/RPMS/noarch/dockertest-2.0-1.noarch.rpm

14.6.5. Install a RPM on the Client

  1. Navigate to the directory where the RPM is saved. 

    [root@rhua noarch]# cd /root/dockertest-2.0/build/RPMS/noarch/

  2. Copy the RPM to the client. 

    # scp dockertest-2.0-1.noarch.rpm <hostname_of_cli:path_on_cli>

  3. Switch to the client and install the RPM. 

    [root@cli01 ~]# yum install dockertest-2.0-1.noarch.rpm

Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
Examining dockertest-2.0-1.noarch.rpm: dockertest-2.0-1.noarch
Marking dockertest-2.0-1.noarch.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package dockertest.noarch 0:2.0-1 will be installed
--> Processing Dependency: docker-common for package: dockertest-2.0-1.noarch
rhel-7-server-rhui-extras-rpms                                                                    | 3.4 kB

--> Running transaction check
---> Package docker-common.x86_64 2:1.10.3-59.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================================
 Package                  Arch              Version                      Repository                                 Size
=========================================================================================================================
Installing:
 dockertest               noarch            2.0-1                        /dockertest-2.0-1.noarch                  1.7 k
Installing for dependencies:
 docker-common            x86_64            2:1.10.3-59.el7              rhel-7-server-rhui-extras-rpms             63 k

Transaction Summary
=========================================================================================================================
Install  1 Package (+1 Dependent package)

Total size: 64 k
Total download size: 63 k
Installed size: 4.7 k
Is this ok [y/d/N]: y
Downloading packages:
docker-common-1.10.3-59.el7.x86_64.rpm                                                            |  63 kB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction

Installed:
  dockertest.noarch 0:2.0-1

Dependency Installed:
  docker-common.x86_64 2:1.10.3-59.el7

Complete!

14.6.6. Test the docker pull Command on the Client

The docker pull command consumes content from a container. The following steps describe how to test a docker pull command on the client.

  1. Start the docker service. 

    [root@cli01 ~]# systemctl start docker

  2. Run the docker pull command. 

    [root@cli01 ~]# docker pull jboss-eap-6_eap64-openshift

Using default tag: latest
Trying to pull repository cds.example.com:5000/jboss-eap-6_eap64-openshift ...
latest: Pulling from cds.example.com:5000/jboss-eap-6_eap64-openshift
30cf2e26a24f: Pull complete
99dd41655d8a: Pull complete
05d9aa366d71: Pull complete
39feddb214c9: Pull complete
76786100be04: Pull complete
d48e1afdcad8: Pull complete
Digest: sha256:5331cae5edaeede56c7e14bede8608229a89f73067d7373af246cabe4b8d4a24
Status: Downloaded newer image for cds.example.com:5000/jboss-eap-6_eap64-openshift:latest

  3. If the docker pull command fails, check the rhui-manager container synchronization status. The synchronization probably has not been performed yet and you have to wait until it synchronizes. 

    Using default tag: latest
Trying to pull repository cds.example.com:5000/jboss-eap-6_eap64-openshift ...
unknown: Not Found
Trying to pull repository docker.io/library/jboss-eap-6_eap64-openshift ...
Pulling repository docker.io/library/jboss-eap-6_eap64-openshift
Error: image library/jboss-eap-6_eap64-openshift not found
Error: image library/jboss-eap-6_eap64-openshift not found

14.7. Atomic Host and OSTree Content

Red Hat Enterprise Linux Atomic Host is a variation of Red Hat Enterprise Linux 7 optimized to run Linux containers. It has been built to be lightweight and efficient, making it a particularly optimal operating system to use as a container runtime system for cloud environments. RHEL Atomic Host comes with many tools for running containers preinstalled (docker, atomic, etcd, flannel). All-in-one kubernetes installs are still supported, but Red Hat no longer supports Kubernetes clusters.

RHEL Atomic Host uses an open source tool called rpm-OSTree to manage bootable, immutable, versioned file system trees made of RPM content. Red Hat composes these trees from packages, and the rpm-ostree tool replicates the trees atomically. This results in a strategy for upgrade and maintenance that centers around atomic updates. The use of rpm-ostree instead of Yum to upgrade and maintain software means that RHEL Atomic Host is managed differently than other RHEL 7 variants.

Specifically, when using RHEL Atomic Host, the operating system content is mounted in read-only mode. There are only two writable directories for local system configuration: /etc/ and /var/. Updates work in the following way: a new bootable file system tree is generated, which shares storage with the current file system tree. When you download the new system tree, the old one is retained in parallel with it. This means that the first, pre-upgrade version of the file system tree can be atomically restored when needed.

User files that are intended to persist across upgrades, including containers and data, should be placed in the /var/ directory. The operating system itself is stored in the /usr/ directory and is read-only. If you perform a long file listing in the root directory using the command ls -l /, you will discover that many of the traditional root-level directories are symbolic links to one of these two locations. For example, the /home/ directory is a symbolic link to the /var/home/ directory. This directory will therefore persist across upgrades.

The default partitioning dedicates most of the available space for the containers, using direct LVM as the storage backend instead of the default loopback as it is on Red Hat Enterprise Linux. Storage is managed the docker-storage-setup daemon, which creates two Logical Volumes during installation, root for the file system content, and docker-pool for the images and containers.

RHEL Atomic Host uses SELinux to provide strong safeguards in multi-tenant environments. The iptables services are available as firewall; iptables is turned off by default.

See Red Hat Enterprise Linux Atomic Host 7 Installation and Configuration Guide for more information about Red Hat Atomic Host.

14.7.1. Add an Atomic Host Repository

  1. Follow Steps 1 through 5 in Section 9.1, “Create a Repository” to add a new Red Hat content repository.

  2. Select the By Product method by pressing 2. 

    Import Repositories:
  1  - All in Certificate
  2  - By Product
  3  - By Repository
Enter value (1-3) or 'b' to abort:

  3. Select the atomic repository from the list by entering the number beside the repository. 

    Red Hat Enterprise Linux Atomic Host (Trees) from RHUI
  4. Press c. The Red Hat Update Infrastructure Management Tool displays the repository to be deployed and prompts for confirmation. Press y to proceed. A message prints as the repository is deployed.
  5. Check that the repository has been installed by pressing l to access the list repositories currently managed by the RHUI screen.

14.7.2. Synchronize the OSTree Repository

The following steps describe how to synchronize an OSTree repository.

  1. Press s to access the Synchronization Status screen.
  2. Press sr to synchronize an individual repository immediately.
  3. Enter the number of the repository that you wish to synchronize.
  4. Press c to confirm the selection. You can enter ? for more commands.

  5. Press y to proceed or n to cancel. 

    The following repositories will be scheduled for synchronization:
  Red Hat Enterprise Linux Atomic Host (Trees) from RHUI (Version 7.3.4)
Proceed? (y/n) y
Scheduling sync for Red Hat Enterprise Linux Atomic Host (Trees) from RHUI (Version 7.3.4)...
... successfully scheduled for the next available timeslot.
------------------------------------------------------------------------------------------------------------------------------
rhui (sync) =>
  6. Press ^ to return to the Red Hat Update Infrastructure Management Tool home screen.

14.7.3. Generate a Client Configuration Package on the RHUA

The following steps describe how to configure the Atomic Host client.

  1. Generate an entitlement certificate for the OSTree repository by following the steps in Section 10.1, “Create an Entitlement Certificate”. Include the recently added OSTree repository in the certificate.
  2. On the Red Hat Update Infrastructure Management Tool home screen, press e to select create entitlement certificates and client configuration RPMs.

  3. On the Client Entitlement Management screen, press o to select create an atomic client configuration package. 

    -= Red Hat Update Infrastructure Management Tool =-

-= Client Entitlement Management =-

e   generate an entitlement certificate
c   create a client configuration RPM from an entitlement certificate
d   create a docker client configuration RPM
o   create an atomic client configuration package

                                      Connected: rhua.example.com

  4. Enter the full path of a local directory to save the configuration files to. 

    Full path to local directory in which the client configuration files generated by this tool
should be stored (if this directory does not exist, it will be created):

/tmp

  5. Enter the name of the tar file. 

    Name of the tar file (excluding extension):
testcerttar

  6. Enter the full path to the entitlement certificate authorizing the client to access specific channels. 

    Full path to the entitlement certificate authorizing the client to access
specific channels:
/tmp/testcert.crt

  7. Enter the full path to the private key for the entitlement certificate. 

    Full path to the private key for the above entitlement certificate:
/tmp/testcert.key

  8. Enter the port to serve Docker content on. Port 5000 is the default. 

    Port to serve Docker content on (default 5000):

Successfully created client configuration package.
Location: /tmp/testcerttar.tar.gz

14.7.4. Configure Atomic Host

  1. Copy the generated .tar.gz file to the Atomic Host.
  2. Extract the tar file.

  3. Run the install.sh script 

    [root@atomiccli01 ~]# ./install.sh

14.7.5. Test the ostree pull Command with Atomic Host

The ostree pull command consumes content from a container. The following steps describe how to test an ostree pull command on the client.

  1. Run the ostree pull command. 

    [root@atomiccli01 ~] ostree pull rhui-rhel-atomic-host-rhui-ostree:rhel-atomic-host/7/x86_64/standard

GPG: Verification enabled, found 1 signature:

  Signature made Mon 10 Apr 2017 04:46:45 PM UTC using RSA key ID 199E2F91FD431D51
  Good signature from "Red Hat, Inc. <security@redhat.com>"

809 metadata, 4395 content objects fetched; 308693 KiB transferred in 108 second
  2. If ostree pull returns an error, check the OSTree repository synchronization status. The synchronization probably has not been performed yet and you have to wait until it synchronizes.

Report a bug