Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapter 5. Running Super-Privileged Containers

5.1. Overview

Containers are designed to keep their own, contained views of namespaces and have limited access to the hosts they run on. By default, containers have a process table, network interfaces, file systems, and IPC facilities that are separate from the host. Many security features like capabilities and SELinux are wrapped around containers to control access to the host system and other containers. Although containers can use resources from the host, commands run from a container have a very limited ability to interface directly with the host.

Some containers, however, are intended to access, monitor, and possibly change features on the host system directly. These are referred to as super privileged containers. Because of the nature of Red Hat Enterprise Linux Atomic hosts (RHEL Atomic), SPCs offer some important uses for RHEL Atomic hosts. For example:

  • The RHEL Atomic Host is meant to be lean. Many tools that you might want to use to manage or troubleshoot RHEL Atomic host are not included by default.
  • Because Atomic Host does not allow for packages to be installed using yum or rpm commands, the best way to add tools from RHEL or third parties on to a RHEL Atomic Host is to include those tools in a container.
  • You can bring an SPC into a RHEL Atomic Host, troubleshoot a problem, then remove it when it is no longer needed, to free up resources.

Red Hat produces several SPCs that are tailored specifically to run on RHEL Atomic hosts, and more are in the pipeline for later. These include:

  • RHEL Atomic Tools Container Image: This container can be thought of as the administrator’s shell. Many of the debugging tools (such as strace, traceroute, and sosreport) and man pages that an administrator might use to diagnose problems on the host are in this container.
  • RHEL Atomic rsyslog Container Image: This container runs the rsyslogd service, allowing you to offload log messages to a centralized server or to manage log files in RHEL Atomic. Note that the systemd-journald service is collecting all logging data on the RHEL Atomic Host, even if you do not install the rsyslog container.
  • RHEL Atomic System Activity Data Collector (sadc) Container Image: This container runs the sadc service from the sysstat package and causes the RHEL Atomic system to gather data continuously that can be read later by the sar command.
  • RHEL Atomic System Security Services Daemon (SSSD) Container Image: This container allows the Red Hat Enterprise Linux Atomic Host authentication subsystem to be connected to central identity providers like Red Hat Identity Management and Microsoft Active Directory.

Super privileged containers can be found in other Red Hat products as well. For example, here are reasons some containers need extra privileges and examples of containers requring those features that are part of the Red Hat OpenShift Container Platform:

  • Access to docker socket: Communicating with the docker service via the docker socket requires special privilege. Containers that need to do that include the openshift3/node and openshift3/openshift-docker-builder containers.
  • Need to load kernel modules: Any container needing to load kernel modules must be privileged. These include openshift3/openvswitch and openshift3/ose-keepalived-ipfailover containers.
  • Need to bypass SELinux: If a container won’t work with SELinux in enforcing mode, it needs special privileges to escape SELinux confinement. The openshift3/logging-fluentd container is an example of such a container. (Note that it is better to create an SELinux policy for the container and label the files it needs to access appropriately so it can work with SELinux.)

The OpenShift containers just described are all available from the Red Hat Registry (registry.access.redhat.com). Search the Red Hat Container Catalog for descriptions of those containers.

Using the RHEL Atomic Tools Container Image as an example, the next section illustrates how super privileged containers are run and how host features are accessed from an SPC.

5.2. Running Privileged Containers

Running a docker command to include every option you need to run as a super privileged container would require a long and complicated command line. For that reason, we have made it simpler by introducing the atomic command to run containers. If you run an atomic command like the following: 

# atomic run rhel7/rhel-tools
[root@localhost /]#

It creates and starts up the rhel-tools container using the docker command with multiple options. This makes it simpler to use and execute containers in the RHEL Atomic Host. The resulting docker command is as follows: 

docker run -it --name rhel-tools --privileged                       \
      --ipc=host --net=host --pid=host -e HOST=/host                \
      -e NAME=rhel-tools -e IMAGE=rhel7/rhel-tools                  \
      -v /run:/run -v /var/log:/var/log                             \
      -v /etc/localtime:/etc/localtime -v /:/host rhel7/rhel-tools

By understanding what options are run for a super privileged container you can better understand how you might want to use those options when running your own containers that need to access resources on the host. Here are descriptions of those options:

  • -i -t: Open a terminal device (-t) and run interactively (-i).
  • The --name option sets the name of the container (rhel-tools, in this case).
  • The --privileged option turns off the Security separation, meaning a process running as root inside of the container has the same access to the RHEL Atomic host that it would have if it were run outside the container.
  • The --ipc=host, --net=host, and --pid=host flags turn off the ipc, net, and pid namespaces inside the container. This means that the processes within the container see the same network and process table, as well as share any IPCs with the host processes.

There several options to set environment variables inside the container (-e). You can refer to any of these options from the shell that opens when you start the container (for example, echo $HOST). These include:

  • -e HOST=/host: Sets the location of the host filesystem within the container (in other words, where / from the host is mounted). You can append $HOST to any file name so a command you run accesses that file on the host instead of within the container. For example, from within the container, $HOST/etc/passwd accesses the /etc/passwd file on the host.
  • -e NAME=rhel-tools: Sets the name of the container (what you see when you type docker ps).
  • -e IMAGE=rhel7/rhel-tools: Identifies the name of the image (what you see when you type docker images).

Several files and directories from the host (in addition to what is normally mounted from the host to a container) are mounted from the host file system to the container. These include:

  • -v /run:/run: The -v /run:/run option mounts the /run directory from the host on the /run directory inside the container. This allows processes within the container to talk to the host’s dbus service and talk directly to the systemd service. Processes within the container can even communicate with the docker daemon.
  • -v /var/log:/var/log: Allows commands run within the container to read and write log files from the host’s /var/log directory.
  • -v /etc/localtime:/etc/localtime: Causes the host system’s timezone to be used with the container.
  • -v /:/host: Mounting / from the host on /host allows a process within the container to easily modify content on the host. Running touch /host/etc/passwd would actually act on the /etc/passwd file on the host.

The last argument identifies rhel7/rhel-tools as the image to run.

In the case of the RHEL Tools privileged container, when you run it, a shell opens and you can start using the commands from inside that container. As an alternative, you could add an option to the end of the atomic or docker command line to run a particular command (such as sosreport or traceroute). The next section describes how to begin investigating that container.

5.2.1. Understanding Name Spaces in Privileged Containers

Many of the basic Red Hat Enterprise administrative commands have been modified to be aware they are running in a container. For example, when you run sosreport inside the RHEL Atomic Tools Container, it knows to use /host as the root of the file system and not /. When you run other commands from within the RHEL Atomic Tools Container (or any privileged container), however, it might help to understand how they may behave differently when run in a privileged container, based on the following topics:

  • Privileges

A privileged container runs applications as root user on the host by default. The container has this ability because it runs with an unconfined_t SELinux security context.

  • Mount Tables

When you use tools such as df and mount to see what file systems are mounted, you see different information from inside the privileged container then you would see if you ran the same command directly on the host. That’s because the two environments maintain their own mount table.

  • Process Tables

Unlike a regular container, that only sees the processes running inside the container, running a ps -e command within a privileged container (with --pid=host set) lets you see every process running on the host. So, you can pass a process ID from the host to commands that run in the privileged container (for example, kill PID). With some commands, however, permissions issues could occur when they try to access processes from the container.

  • Inter-process communications

The IPC facility on the host is accessible from within the privileged container. So, you can run commands such as ipcs to see information about active message queues, shared memory segments, and semaphone sets on the host.

5.3. Using the Atomic Tools Container Image

The Red Hat Enterprise Linux Atomic Tools Container (RHEL Tools Container) is a docker-formatted image that includes a set of software tools for troubleshooting and investigating a Red Hat Enterprise Linux Atomic (RHEL Atomic) Host. Designed to run as a privileged container, the RHEL Tools Container allows you to interact directly with the RHEL Atomic Host system to uncover and solve problems. Inside the RHEL Tools Container are popular system administration tools such as dig, iotop, ip, ss, less, ncat, lspci, perf, screen, strace, sar, tcpdump, and vim. Most of these tools are not included with RHEL Atomic.

This section covers:

  • How to get and run the RHEL Atomic Tools Container
  • How the RHEL Atomic Tools Container works
  • What commands are in the RHEL Atomic Tools Container and how to use them

5.3.1. Overview

RHEL Atomic is designed to be a light-weight, streamlined version of Red Hat Enterprise Linux that is configured and tuned specifically for running Linux containers. It is kept light so it can consume minimal amounts of resources during deployment and run efficiently once deployed. This makes RHEL Atomic particularly suited for hosting containers in cloud environments.

One of the problems of the reduced size of Atomic is that many of the standard RHEL tools are not installed in Atomic. To make the problem worse, the support for installing additional software packages is limited.

The RHEL Tools Container solves this problem. It provides a chosen set of popular system administration tools. You can install this container either during the deployment of the Atomic system or later, when you need to troubleshoot a problem.

Consider these facts about the RHEL Tools Container:

  • It opens privileges. Containers, by default, cannot see most of the Atomic Host’s file system or namespaces (networking, IPC, process table, and so on). However, because the RHEL Tools Container runs as a privileged host and opens access to host namespaces and features, most commands you run from within that container will be able to view and act on the host as if run directly on the host.
  • The tools might behave differently. Some commands, when run from within the container, even with privileges open, will behave differently than if run directly on the host system. See Running Commands from the RHEL Tools Container for examples of this.

5.3.2. Getting and Running the RHEL Tools Container

To get and run the RHEL Tools Container:

  1. Install RHEL Atomic Host using the Installation and Configuration Guide. The RHEL Tools Container is designed to run on RHEL Atomic Host systems.

  2. Pull the RHEL Tools Container image to the Atomic Host: 

    # docker pull rhel7/rhel-tools

  3. Run the RHEL Tools Container: 

    # atomic run rhel7/rhel-tools
[root@localhost /]#

You now have a shell open inside the container, with all the tools in the container ready to run. When you are finished using the tools, run exit.

5.3.3. Running Commands from the RHEL Tools Container

The following examples show some of the commands from the RHEL Tools Container and the differences between running them in the container and on the host system:

  • blktrace: To use blktrace from within a container, you need to first mount the debugfs file system. In this example the administrator mounts debugfs and runs blktrace: 

    # mount -t debugfs debugfs /sys/kernel/debug/
# blktrace /dev/vda
^C
=== vda ===
  CPU  0:                38086 events,     1786 KiB data
  Total:                 38086 events (dropped 0),     1786 KiB data

  • useradd: To add a user to do non-root activities within the container, you can use the useradd command: 

    # useradd jjones
# su - jjones
[jjones@example ~]$

5.3.4. More Information About Running RHEL Tools Container

Note these details about the RHEL Tools Container:

  • The container image that you pull is named rhel7/rhel-tools. However, once you run it, a container is created using that image. That container is called rhel-tools.
  • Changes you make to a container (for example, yum install package) continue to exist even after you stop and start the container again. This means that atomic run rhel7/rhel-tools will not pull down any files or do any additional setup on the host the second time you run it.
  • To see the name of the container, even after it is stopped, type docker ps -a.
  • Unless you explicitly remove the container (docker rm rhel-tools), the container continues to exist on your system.

  • Even if you remove the rhel7/rhel-tools container image, the rhel-tools container, if there is one, is retained. While the container is retained, you cannot upgrade the container image.

    To upgrade the rhel7/rhel-tools image, preserve any files from the existing container that you want to keep by copying them somewhere on /host. Then remove the container by running docker rm rhel-tools. Finally, get the updated container image by running docker pull rhel7/rhel-tools.

  • Commands that should run directly on the Atomic host include those related to systemd (systemctl and journalctl), LVM (lvm, lvdisplay, vgdisplay and so on), the atomic command, and any commands that modify block devices.
  • If you have any issues with the RHEL Tools Container, you can file bugs and RFEs at bugzilla.redhat.com under the "Red Hat Enterprise Linux" product and the "rhel-tools-docker" component.

5.4. Using the Atomic Support Tools Container Image

The Red Hat Enterprise Linux Atomic Support Tools container (Support Tools Container) is a docker-formatted image that includes the sos, strace, tcpdump, and redhat-support-tool tools.

The four tools comprising the Support Tools Container were previously part of the RHEL Tools Container (strace and tcpdump still are). The two containers are essentially the same but with a different set of included tools. Thus, the information in the Using the Atomic Tools Container Image section applies to Support Tools Container, except for two things: set of available tools and container size.

This section covers:

  • The relationship between the Support Tools Container and the RHEL Tools Container
  • How to get and run the RHEL Atomic Tools Container
  • What commands are in the RHEL Atomic Tools Container and how to use them

5.4.1. How It Is Different from RHEL Atomic Tools

The Support Tools Container has been created as part of the effort to reduce the size of the huge RHEL Tools Container.

A frequent use case for the RHEL Tools Container has been to gather sosreports and run tcpdump, strace, and redhat-support-tool tools. That is why the dedicated Support Tools Container, which consists of these four tools, has been created.

The Support Tools Container is much smaller than the RHEL Tools Container, 218MB instead of 370MB, and can be installed and used more liberally.

The sos and redhat-support-tool tools have been removed from the RHEL Tools Container, while the tcpdump and strace remain there.

For more information on the splitting of the RHEL Tools Container, see the RHEL Atomic Host 7.4.3 Release Note.

5.4.2. Getting and Running the Support Tools Container

To get and run the Support Tools Container:

  1. Install RHEL Atomic Host using the Installation and Configuration Guide. The Support Tools Container is designed to run on RHEL Atomic Host systems.

  2. Pull the Support Tools Container image to the Atomic Host: 

    # docker pull rhel7/support-tools

  3. Run the RHEL Tools Container: 

    # atomic run rhel7/support-tools
[root@localhost /]#

You now have a shell open inside the container, with all the tools in the container ready to run. When you are finished using the tools, run exit.

5.4.3. Running Commands from the Support Tools Container

The following examples two of the commands from the Support Tools Container and the differences between running them in the container and on the host system:

  • sosreport: The sosreport command includes an atomic plugin that makes it container-aware. This means that you can run sosreport to generate a report with almost exactly the same results as if run directly on the host. For example: 

    # sosreport
Please enter your first initial and last name [localhost.localdomain]: jjones
Please enter the case id that you are generating this report for: 12345678
...
# ls /host/var/tmp
sosreport-jjones.12345678-20150203102944.tar.xz
sosreport-jjones.12345678-20150203102944.tar.xz.md5

    Note that the report is copied to the /var/tmp directory on the host, which makes it available after you close the container. Additionally, the host’s root file system is mounted on /host within the container, which allows you to access the report in the /host/var/tmp directory within the container.

  • strace: Since the host’s process table is visible from within the RHEL Tools Container, the commands that take a process ID as an argument work from within the container. This enables using the strace command: 

    # ps -ef | grep ssh
root        998      1  0 Jan29 ?        00:00:00 /usr/sbin/sshd -D
# strace -p 998
Process 998 attached
select(7, [3 4], NULL, NULL, NULL ...

5.5. Using the Atomic rsyslog Container Image

5.5.1. Overview

The Red Hat Enterprise Linux rsyslog Atomic Container Image is a Docker formatted image that is designed to run on a Red Hat Enterprise Linux Atomic (RHEL Atomic) host.

With this container, you can start an rsyslogd daemon that:

  • Uses configuration files and log files that are stored on the Atomic host’s file system
  • Can be configured to provide any standard rsyslog features, including directing log message to a remote log host

This topic describes how to get and run the RHEL rsyslog container.

Because the rsyslog service is not installed on a Red Hat Enterprise Linux Atomic Host, the rsyslog container offers a way of adding that service to an Atomic host.

Here are some of the features of the rsyslog container:

  • Installs from atomic command: When you use the atomic install command to get and run the rsyslog container, several things happen. The container itself is pulled from the registry, files and directories needed by the rsyslog service are added to the host, and the container is started with docker run.
  • Configure from the host: Because the files needed by the rsyslog service are stored on the Atomic host, there is no need to go inside the container itself. All configuration can be done from the host.
  • Restarting the service: If you make any changes to the configuration, to pick up the changes you just have to stop, remove and restart the container again (docker stop rsyslog; docker rm rsyslog; atomic run rhel7/rsyslog).
  • Super privileged container: Keep in mind that running the rsyslog container opens privileges from that container to the host system. The container has root access to RHEL Atomic host and opens access to privileged configuration and log files.

5.5.2. Getting and Running the RHEL rsyslog Container

To use the rsyslog Atomic Container Image on a RHEL Atomic host, you need to install it, load it and run it, as described in the following procedure:

  1. Install RHEL Atomic Host: To install and configure a RHEL Atomic host, refer to the appropriate installation guide listed on the Red Hat Enterprise Linux Atomic Host Documentation page.

  2. Install the RHEL rsyslog Container: While logged into the RHEL Atomic host, get and start the RHEL rsyslog Container by running the following command: 

    # docker pull rhel7/rsyslog
# atomic install rhel7/rsyslog
...
docker run --rm --privileged -v /:/host -e HOST=/host -e IMAGE=rhel7/rsyslog -e NAME=rsyslog rhel7/rsyslog /bin/install.sh
Creating directory at /host//etc/pki/rsyslog
Installing file at /host//etc/rsyslog.conf
Installing file at /host//etc/sysconfig/rsyslog

  3. Start the rsyslog container: To run the RHEL rsyslog container, use the atomic command. The following command starts the container using the docker command with appropriate options: 

    # atomic run rhel7/rsyslog
docker run -d --privileged --name rsyslog --net=host -v /etc/pki/rsyslog:/etc/pki/rsyslog -v /etc/rsyslog.conf:/etc/rsyslog.conf -v /etc/rsyslog.d:/etc/rsyslog.d -v /var/log:/var/log -v /var/lib/rsyslog:/var/lib/rsyslog -v /run/log:/run/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -e IMAGE=rhel7/rsyslog -e NAME=rsyslog --restart=always rhel7/rsyslog /bin/rsyslog.sh
5803dbade82274158f0694a19fdcd7aac044a2656b2ce96d1aebdb0e30ad5ffd

    After the atomic command starts, you can see the exact 'docker' command that is run to start the rsyslog container. The rsyslogd container runs as a super privileged container.

  4. Check that the container is running: Type the following to check that the rsyslog container is running: 

    # docker ps
CONTAINER ID IMAGE                                                COMMAND             CREATED       STATUS        PORTS NAMES
5803dbade822 registry.access.stage.redhat.com/rhel7/rsyslog:7.1-3 "/bin/rsyslog.sh"   9 minutes ago Up 9 minutes        rsyslog
    Note

    The full name of the image is "registry.access.redhat.com/rhel7/rsyslog:7.1-3", which include both the name of the registry from which it was downloaded and the version of the image obtained. The actual container that is run locally, however, is simply called rsyslog. The difference between the image and container is central to the way docker works.

  5. Check that the rsyslog service is working: From a shell, type the following to watch as messages come into the /var/log/messages file: 

    # tail -f /var/log/messages

  6. Generate a log message: Type the following to generate a log message: 

    # logger "Test that rsyslog is doing great"

    If the rsyslog service is working, the message should appear from the shell running the tail command. You can start using the rsyslog service on the Atomic host now.

5.5.3. Tips for Running rsyslog Container

Here are some tips to help you understand a few other issues related to running the RHEL rsyslog container:

  • Understanding persistent logging: By default, the Red Hat Enterprise Linux Atomic Host system is configured to log to persistent logs on the local root filesystem with journald by setting the following value in in /etc/systemd/journald.conf: 

    Storage=persistent

    To configure persistent logging to either local rsyslog logs or to a remote rsyslog server, you may want to disable the local journald persistent logging by changing that line to: 

    Storage=volatile

    and rebooting the RHEL Atomic Host system. journald will still maintain local logs in a ramdisk if you do this, but will not write them to disk. This can save on local disk IO if the data is already being captured securely in another location. The rsyslog container will still be able to capture and process journald logs.

  • Changing rsyslog configuration: Every time you change the rsyslog container configuration, you must stop and remove the running rsyslog container, then start a new one. To do that, run the following commands: 

    # docker stop rsyslog
# docker rm rsyslog
# atomic run rhel7/rsyslog

  • Log rotation: In the initial version of the rsyslog container image, there is no support for local rotation of rsyslog log files. This will be added in a future update. But rsyslog can still be used with local log files if space permits.

    There is no requirement for local log rotation if rsyslog is configured to send logs only to a remote log collection host. Refer to the Red Hat Enterprise Linux System Administrator’s Guide for information on configuring both local and remote logging with rsyslog.

  • Ensure there is enough space for logs.

    • The ideal configuration for many cloud environments is to configure rsyslog to log to a remote rsyslog server.
    • If you are logging to local storage, be aware that log rotation within a container currently does not occur. In upcoming releases, we will support the configuring log file size limits for the rsyslog configuration by editing logrotate configuration file (such as those in /etc/logrotate.d/ directory and the /etc/logrotate.conf file). This feature is not yet supported.
    • Note especially that the amount of space available on the root file system of Atomic host qcow2 images is limited. A larger space can be provisioned by installing via the Red Hat Enterprise Linux Atomic host anaconda installer ISO image.

  • Image and Container Lifecycle

    If you want to upgrade to a newer version of the Red Hat Enterprise Linux rsyslog Atomic container image, it is not enough to merely download the new image with docker pull rhel7/rsyslog. You must also explicitly remove the existing rsyslog container with the following commands, before re-running it, in order to create a fresh container from the new image: 

    # docker pull rhel7/rsyslog

    If a new image downloads, run the following: 

    # docker stop rsyslog
# docker rm rsyslog
# atomic install rhel7/rsyslog
# atomic run rhel7/rsyslog

5.6. Using the Atomic System Activity Data Collector (sadc) Container Image

The Red Hat Enterprise Linux sadc Atomic Container Image is a Docker-formatted containerized version of the system monitoring and data collection utilities contained in the sysstat package. This container is designed to run on a Red Hat Enterprise Linux Atomic host. With this container installed and running, the following occurs on your Atomic system:

  • System activity data are gathered on an on-going basis
  • Commands such as cifsiostat, iostat, mpstat, nfsiostat, pidstat, sadf, and sar are available to display that data. You use the docker exec sadc command to run the commands.

This topic describes how to get and run the sadc container.

5.6.1. Overview

Because sysstat package (which includes sar, iostat, sadc an other tools) is not installed on a Red Hat Enterprise Linux Atomic host, the sadc container offers a way of adding those utilities to an Atomic host. Here are some of the features of the sadc container:

  • Installs from atomic command: When you use the "atomic install" command to get and run the sadc container, several things happen. The container itself is pulled from the registry, files and directories needed by the sadc service are added to the host, and the container is started with docker run.
  • Configure from the host: Because the files needed by the sadc data collection service are stored on the Atomic host, there is no need to go inside the container itself. All configuration can be done from the host.
  • Super privileged container: Keep in mind that running the sadc container opens privileges from that container to the host system. The container has root access to RHEL Atomic host and opens access to privileged configuration and log files. For more information on privileged containers, see Running Privileged Docker Containers in RHEL Atomic.

5.6.2. Getting and Running the RHEL sadc Container

To use the sadc container on a Red Hat Enterprise Linux Atomic host, you need to install it, load it and run it, as described in the following procedure:

  1. Install RHEL Atomic Host: To install and configure a RHEL Atomic host, refer to the appropriate installation guide listed on the Red Hat Enterprise Linux Atomic Host Documentation page.

  2. Install the RHEL sadc Container: While logged into the RHEL Atomic host, get and start the sadc container by running the following command:: 

    # docker pull rhel7/sadc
# atomic install rhel7/sadc
docker run --rm --privileged --name sadc -v /:/host -e HOST=/host -e IMAGE=rhel7/sadc -e NAME=name rhel7/sadc /usr/local/bin/sysstat-install.sh
Installing file at /host//etc/cron.d/sysstat
Installing file at /host//etc/sysconfig/sysstat
Installing file at /host//etc/sysconfig/sysstat.ioconf
Installing file at /host//usr/local/bin/sysstat.sh

  3. Start the sadc container: To run the RHEL sadc container, use the atomic command. The following command starts the container using the docker command with appropriate options: 

    # atomic run rhel7/sadc
docker run -d --privileged --name sadc -v /etc/sysconfig/sysstat:/etc/sysconfig/sysstat -v /etc/sysconfig/sysstat.ioconf:/etc/sysconfig/sysstat.ioconf -v /var/log/sa:/var/log/sa -v /:/host -e HOST=/host -e IMAGE=rhel7/sadc -e NAME=sadc --net=host --restart=always rhel7/sadc /usr/local/bin/sysstat.sh
11c566e20ec995a164f815d9bb76b4b876c555f507c9f56c41f5009c9b1bebf4

    After the atomic command starts, you can see the exact docker command that is run to start the sadc container. The sadc container runs as a super privileged container. For more information on super privileged containers, refer to Running Super Privileged Docker Containers on a Red Hat Enterprise Linux Atomic Host.

  4. Check that the container is running: Type the following to check that the sadc container is running: 

    # docker ps
CONTAINER ID IMAGE                                             COMMAND              CREATED       STATUS       PORTS NAMES
11c566e20ec9 registry.access.stage.redhat.com/rhel7/sadc:7.1-3 "/usr/local/bin/syss 3 minutes ago Up 2 minutes       sadc
    Note

    While "registry.access.redhat.com/rhel7/sadc:7.1-3" is the full name of the image, including both the name of the registry from which it was downloaded and the version of the image obtained. The actual container that is run locally, however, is simply called "sadc". The difference between the image and container is central to the way docker works.

  5. Generate sadc data: From a shell, type the following generate some system activity data and test that sadc is working properly: 

    # docker exec sadc /usr/lib64/sa/sa1 1 1

  6. Check that sadc worked properly: If sadc generated some system activity data, you should be able to see it using the sar command as follows: 

    # docker exec sadc sar
Linux 3.10.0-229.el7.x86_64 (minion1.example.com) 02/27/15 _x86_64_ (1 CPU)

09:31:25          LINUX RESTART
09:32:00 CPU %user  %nice %system  %iowait  %steal   %idle
09:32:18 all 0.86   0.00    0.92      0.00    0.00   98.22

If sadc is working, you should be able to see the data generated by the sadc command you just ran. New data should be generated every 10 minutes. So you can run the sar command again to make sure that data is being collected in an on-going basis.

5.6.3. Tips for Running the sadc Container

Here are some tips to help you understand a few other issues related to running the sadc container:

  • Running sysstat commands: You can run any of the commands in the sysstat package to view data gathered by the sadc container. These include cifsiostat, iostat, mpstat, nfsiostat, pidstat, sadf, and sar. Because these commands are not on the Atomic host, you must run them using docker exec. For example: 

    # docker exec sadc iostat

  • Image and Container Lifecycle

    If you want to upgrade to a newer version of the Red Hat Enterprise Linux sadc Atomic container image, it is not enough to merely download the new image with docker pull rhel7/sadc. You must also explicitly remove the existing sadc container with the following commands, before re-running it, in order to create a fresh container from the new image: 

    # docker stop sadc
# docker rm sadc

5.7. Using the Atomic Net-SNMP Container Image

The Red Hat Enterprise Linux Atomic Net-SNMP Container (Net-SNMP Container) is a docker-formatted image that provides the Net-SNMP software suite, including an SNMP agent. Net-SNMP allows you to set up performance monitoring of an Atomic Host system using the SNMP protocol.

Non-containerized Net-SNMP is documented in the RHEL7 System Administrator’s Guide.

5.7.1. Installing and Running the Net-SNMP Container

To install and run the Net-SNMP Container:

  1. Pull the Net-SNMP Container image: 

    # atomic pull rhel7/net-snmp

  2. Install the image: 

    # atomic install --system --system-package=no --name=net-snmp rhel7/net-snmp

    Currently, Red Hat recommends using the --system-package=no option to prevent rpmbuild from creating an RPM file during installation and to fall back to copying files to the host instead.

  3. Run the Net-SNMP service: 

    # systemctl start net-snmp

5.7.2. Running Commands in the Net-SNMP Container

When you need to run the commands, for example commands in the non-containerized Net-SNMP documentation, they must be run inside the container: 

# atomic run --storage ostree net-snmp COMMAND ARGUMENTS

For example, to run snmpwalk -v3 localhost system, use: 

# atomic run --storage ostree net-snmp snmpwalk -v3 localhost system

5.7.3. Configuring the SNMP Agent

To configure the SNMP Agent, follow the instructions in Configuring Net-SNMP. That document shows how to set the system information and configure authentication.

Note

If you want increased security, configure Net-SNMP to use version 3 of SNMP.

During configuring, you will change configuration files such as /etc/snmp/snmpd.conf and run commands such as net-snmp-create-v3-user.

When you change configuration files:

  1. Stop the net-snmp service: 

    # systemctl stop net-snmp
  2. Make changes in the configuration files.

  3. Start the net-snmp service: 

    # systemctl start net-snmp

When you run commands:

  1. Make sure the net-snmp service is running: 

    # systemctl start net-snmp
  2. Run the commands.

5.7.4. Monitoring an Atomic Host System Using Net-SNMP

See Retrieving Performance Data over SNMP to learn how to access performance data about the managed Atomic Host over SNMP.

5.7.5. Extending Net-SNMP to Provide Application Metrics

See Extending Net-SNMP for information on extending Net-SNMP to provide application metrics in addition to the system metrics. The document shows how to extend Net-SNMP using shell scripts and Perl scripts.

Note that RHEL Atomic Host is a containerized system, and might not support some extensions.

5.8. Using the Atomic SSSD Container Image

5.8.1. Overview

The Red Hat Enterprise Linux Atomic SSSD Container Image provides the ipa-client-install and realmd tools for enrolling the host to an Identity Management (IdM) server or for connecting it to an Active Directory domain. It makes it possible to run the System Security Services Daemon (SSSD) in a container to provide identity, authentication, and authorization services to the Atomic Host itself and to applications running in other containers on the same Atomic Host system.

Usage of the SSSD container is described in the Using Containerized Identity Management Services guide:

IdM and non-containerized SSSD are described in other Identity Management Guides:

5.9. Using the Atomic rhevm-guest-agent Container Image

5.9.1. Overview

The rhevm-guest-agent container image is a Docker-formatted container that is used to run an agent inside of virtual machines on Red Hat Virtualization hosts. Communications between that agent and the Red Hat Virtualization Manager allows that manager to both monitor and change the state of the agent’s virtual machine.

This topic describes how to get and run the rhevm-guest-agent container.

5.9.1.1. Overview of the rhevm-guest-agent Container

A rhevm-guest-agent running inside a virtual machine on a Red Hat Virtualization host allows a Red Hat Virtualization Manager (RHV-M) to access data and control the state of that virtual machine (VM). That agent provides information to the RHV-M that include heart-beat data, CPU usage, IP addresses, installed applications, and other content related to the health and processing of the virtual machine. Likewise, through the agent, the RHEV-M can shutdown, restart or check the status of the virtual machine.

5.9.2. Getting and Running the RHEL rhevm-guest-agent Container

To use the rhevm-guest-agent container on a RHEL or RHEL Atomic host system, you need to install it and run it as described in the following procedure:

  1. Install RHEL or RHEL Atomic Host: Install and configure a RHEL or RHEL Atomic host system as a virtual machine in a Red Hat Virtualization environment (from the RHV Manager). The rhevm-guest-agent is made to run on a RHEL system on a RHEV Host so it can be managed by a RHV Manager.

  2. Pull the rhevm-guest-agent container: While logged into the virtual machine, pull the rhevm-guest-agent container as follows: 

    # docker pull registry.access.redhat.com/rhev4/rhevm-guest-agent
Using default tag: latest
Trying to pull repository registry.access.redhat.com/rhev4/rhevm-guest-agent ...
latest: Pulling from registry.access.redhat.com/rhev4/rhevm-guest-agent
16dc1f96e3a1: Pull complete
83abca08dea6: Pull complete
Digest: sha256:0ea0bf8729957454e1f134747d7539e37ea128f39e9757271eea4cbba8737655
Status: Downloaded newer image for registry.access.redhat.com/rhev4/rhevm-guest-agent:latest

  3. Install the rhevm-guest-agent container: Use the atomic command to install the rhevm-guest-agent container as follows: 

    # atomic install rhev4/rhevm-guest-agent
docker run --rm --privileged --pid=host -v /:/host -e HOST=/host -e IMAGE=rhev4/rhevm-guest-agent -e NAME=rhevm-guest-agent rhev4/rhevm-guest-agent /usr/local/bin/ovirt-guest-agent-install.sh
Host group is
Creating ovirtagent group on host system
Host user is
Creating ovirtagent user on host system

    Notice that the process of installing the container on the hosts system includes opening privileges to the host system and creating ovirtagent user and group accounts on the host.

  4. Start the rhevm-guest-agent container: To run the RHEL rhevm-guest-agent container, use the atomic command as follows: 

    # atomic run rhev4/rhevm-guest-agent
docker run --privileged --pid=host --net=host -v /:/host -e HOST=/host -v /proc:/hostproc -v /dev/virtio-ports/com.redhat.rhevm.vdsm:/dev/virtio-ports/com.redhat.rhevm.vdsm --env container=docker --restart=always -e IMAGE=rhev4/rhevm-guest-agent -e NAME=rhevm-guest-agent rhev4/rhevm-guest-agent

    After the atomic command starts, you can see the exact docker command that is run to start the rhevm-guest-agent container. In this case, the container is set to always restart if the service ever goes down (--restart=always). See the "Tips" section for information about privileges that are open to the host system.

5.9.3. Tips for Running the rhevm-guest-agent Container

Here are some tips to help you understand a few other issues related to running the rhevm-guest-agent container:

  • Privileges opened: The rhevm-guest-agent is a super privileged container, opening up various features on the host. Privileges rhevm-guest-agent opens include: --privileged (turns of security separation, allowing root access to the host), --pid=host (allows access to host process table), --net=host (allows access to host network interfaces), and -v /:/host (mount host’s root file system in the container). Several other host assets are mounted inside the container as well. For more information on the implications of opening these privileges, see Running Super-privileged Containers.
  • Viewing rhevm-guest-agent: The data made accessible by the rhevm-guest-agent can be displayed from the Red Hat Virtualization Manager. From the RHV-M web-based interface, select the virtual machine on which the agent is running to be able to view information collected from the agent about the health and activity of that virtual machine.
  • Information, Notifications, and Actions: The rhevm-guest-agent provides information, notifications, and actions to the RHV-M. To see details about what the rhevm-guest-agent provides, you can view the upstream oVirt-guest-agent page.

  • Image and Container Lifecycle

    If you want to upgrade to a newer version of the rhevm-guest-agent container image, it is not enough to merely download the new image with docker pull. You must also explicitly remove the existing rhevm-guest-agent container with the following commands, before re-running it, in order to create a fresh container from the new image: 

    # docker stop rhevm-guest-agent
# docker rm rhevm-guest-agent

5.10. Using the Atomic RHEL7 Init Container Image

5.10.1. Overview

The Red Hat Enterprise Linux 7 Init Image allows creating containerized services based on the systemd init system. This container image configures systemd in an OCI container and enables running one or more services in a RHEL7 user space using unit files, init scripts, or both.

This image is maintained by Red Hat and is updated regularly. Use this image like a regular Red Hat Enterprise Linux 7 system. Tools such as yum, gzip, and bash are provided by default.

You never run this container. It is only used when creating your container images.

Note that behavior of containers created using this image might be different from behavior of the corresponding application on a non-Atomic RHEL7 system.

IMPORTANT: To run the rhel7-init container on a RHEL or RHEL Atomic host system with SELinux enabled, the container_manage_cgroup boolean must be turned on. The boolean is off by default. You can turn that boolean on permanently by typing the following on the host system: setsebool -P container_manage_cgroup 1

5.10.2. Getting the Atomic RHEL7 Init Container Image

To use the RHEL7 Init Atomic Container Image on a RHEL Atomic host, you need to install an Atomic host system:

  1. Install RHEL Atomic Host: To install and configure a RHEL Atomic host, refer to the appropriate installation guide listed on the Red Hat Enterprise Linux Atomic Host Installation and Configuration Guide.

  2. Pull the RHEL7 Init Container: While logged into the RHEL Atomic host, get the RHEL7 Init Container by running the following command: 

    # docker pull rhel7-init

  3. Allow init container to manage cgroups: Turn on the container_manage_cgroup SELinux boolean on the host system to allow the init image to run: 

    # setsebool -P container_manage_cgroup 1

5.10.3. Creating Container Images based on the Atomic RHEL7 Init Container Image

To assemble a new image from the RHEL7 Init Image:

  1. Create a Dockerfile that includes these entries: 

    FROM rhel7-init

    and 

    RUN yum -y install <daemon> && yum clean all && systemctl enable <daemon>

    Substitute <daemon> with the name of the package containing the daemon for which you are creating the image.

    For example, to create an Apache container image: 

    RUN yum -y install httpd && yum clean all && systemctl enable httpd

  2. Assemble the image: 

    # docker build --tag <new_container_name> <directory_containing_dockerfile>

    For example, to assemble the Apache container image: 

    # docker build -t myhttpd .

  3. (optional) Run the new image: 

    # docker run <options> <new_container_name>

    For example, to run the Apache container: 

    # docker run -d -p 80:80 --name my-httpd -v /var/log/httpd myhttpd

5.11. Using the Atomic RHEL6 Init Container Image

5.11.1. Overview

The Red Hat Enterprise Linux 6 Init Image allows creating containerized services in a RHEL6-like environment. This container image enables running one or more services in a RHEL6 user space using init scripts. While the init system for Red Hat Enterprise Linux 6 is upstart, this image uses another init system, so no upstart-specific feature is supported in this image.

This image is maintained by Red Hat and is updated regularly. Use this image like a regular Red Hat Enterprise Linux 6 system. Tools such as yum, gzip, and bash are provided by default.

You never run this container. It is only used when creating your container images.

Note that behavior of containers created using this image might be different from behavior of the corresponding application on a non-Atomic RHEL6 system.

5.11.2. Getting the Atomic RHEL6 Init Container Image

To use the RHEL6 Init Atomic Container Image on a RHEL Atomic host, you need to install it:

  1. Install RHEL Atomic Host: To install and configure a RHEL Atomic host, refer to the appropriate installation guide listed on the Red Hat Enterprise Linux Atomic Host Installation and Configuration Guide.

  2. Pull the RHEL6 Init Container: While logged into the RHEL Atomic host, get the RHEL6 Init Container by running the following command: 

    # docker pull rhel6/rhel6-init

5.11.3. Creating Container Images based on the Atomic RHEL6 Init Container Image

To assemble a new image from the RHEL6 Init Image:

  1. Create a Dockerfile that includes these entries: 

    FROM rhel6-init

    and 

    RUN yum -y install <daemon> && yum clean all && chkconfig <daemon> on

    Substitute <daemon> with the name of the package containing the daemon for which you are creating the image.

    For example, to create an Apache container image: 

    RUN yum -y install httpd && yum clean all && chkconfig httpd on

  2. Assemble the image: 

    # docker build --tag <new_container_name> <directory_containing_dockerfile>

    For example, to assemble the Apache container image: 

    # docker build -t myhttpd .

  3. (optional) Run the new image: 

    # docker run <options> <new_container_name>

    For example, to run the Apache container: 

    # docker run -d -p 80:80 --name my-httpd -v /var/log/httpd myhttpd