Description
RHCSA Red Hat Enterprise Linux 9: Training and Exam Preparation Guide, Third Edition provides an in-depth coverage of the latest RHCSA (version 9) EX200 exam objectives. The most definitive guide available on the subject, this book explains concepts, analyzes configuration files, describes command outputs, shows step-by-step procedures (includes screenshots of actual commands executed and outputs they produced), and challenges the readers’ comprehension of the concepts and procedures by presenting plenty of supplementary labs and sample realistic exam tasks to perform on their own.
This book has 22 chapters that are organized logically, from building a lab environment to the fundamentals of Linux to sophisticated Linux administration topics. The book covers the topics on local RHEL 9 installation; initial interaction with the system; essential Linux commands; file compression and archiving; file editing and manipulation; standard and special permissions; file searching and access controls; user monitoring and authentication files; users, groups, and password aging; bash shell features and startup files; processes and job scheduling; basic and advanced software administration techniques; system boot process and bootloader; kernel management and system initialization; logging and system tuning; basic and advanced storage management tools and solutions; local file systems and swap regions; network device and connection configuration; hostname resolution and time synchronization; remote file systems and automounting; the secure shell service; firewall and SELinux controls; bash shell scripting; and operating system virtualization using containers.
Each chapter highlights the major topics and relevant exam objectives at the beginning and ends with several review questions & answers and Do-It-Yourself challenge labs. Throughout the book, figures, tables, screenshots, examples, warnings, notes, and exam tips are furnished to support explanation and exam preparation. There are four sample RHCSA exams that are expected to be performed using the knowledge and skills attained from reading the material, following the in-chapter exercises, and completing the end-of-chapter challenge labs. The labs and the sample exams include hints to relevant topics and/or exercises.
This book may be used as a self-learning guide by RHCSA 9 exam aspirants, a resource by instructors and students to follow in physical and virtual training sessions, an on-the-job resource for reference, and an easy-to-understand guide by novice and non-RHEL administrators.
EXAM INFO AND OBJECTIVES
The Red Hat Certified System Administrator (RHCSA) certification exam is a performance-based hands-on exam designed for certification aspirants. This exam is presented on a live server running Red Hat Enterprise Linux 9. This server has two RHEL 9-based virtual machines to accomplish the exam tasks. During the exam, the candidates do not have access to any external resources such as the internet, printed material, electronic content, and mobile devices, except for the manuals and other documentation that is installed on the exam virtual machines.
The official exam objectives (68 in total as of February 21, 2023) are available for reference at http://www.redhat.com/training/courses/ex200/examobjective. Visit the URL for up-to-date information.
There are no pre-requisites to earn this certification.
The exam objectives are covered in detail in the chapters throughout this book. An enumerated list of the objectives are presented below along with the chapter number where each objective is discussed.
Understand and Use Essential Tools
- Access a shell prompt and issue commands with correct syntax (chapter 2)
- Use input-output redirection (>, >>, |, 2>, etc) (chapter 7)
- Use grep and regular expressions to analyze text (chapter 7)
- Access remote systems using ssh (chapters 01 and 18)
- Log in and switch users in multi-user targets (chapter 6)
- Archive, compress, unpack, and uncompress files using tar, star, gzip, and bzip2 (chapter 3)
- Create and edit text files (chapter 3)
- Create, delete, copy, and move files and directories (chapter 3)
- Create hard and soft links (chapter 3)
- List, set, and change standard ugo/rwx permissions (chapter 4)
- Locate, read, and use system documentation including man, info, and files in /usr/share/doc (chapter 2)
Create Simple Shell Scripts
- Conditionally execute code (use of: if, test, [], etc.) (chapter 21)
- Use Looping constructs (for, etc.) to process file, command line input (chapter 21)
- Process script inputs ($1, $2, etc.) (chapter 21)
- Processing output of shell commands within a script (chapter 21)
Operate Running Systems
- Boot, reboot, and shut down a system normally (chapter 12)
- Boot systems into different targets manually (chapter 12)
- Interrupt the boot process in order to gain access to a system (chapter 11)
- Identify CPU/memory intensive processes and kill processes (chapter 8)
- Adjust process scheduling (chapter 8)
- Manage tuning profiles (chapter 12)
- Locate and interpret system log files and journals (chapter 12)
- Preserve system journals (chapter 12)
- Start, stop, and check the status of network services (chapter 12)
- Securely transfer files between systems (chapter 18)
Configure Local Storage
- List, create, and delete partitions on MBR and GPT disks (chapter 13)
- Create and remove physical volumes (chapter 13)
- Assign physical volumes to volume groups (chapter 13)
- Create and delete logical volumes (chapter 13)
- Configure systems to mount file systems at boot by Universally Unique ID (UUID) or label (chapter 14)
- Add new partitions and logical volumes, and swap to a system non-destructively (chapters 13 and 14)
Create and Configure File Systems
- Create, mount, unmount, and use vfat, ext4, and xfs file systems (chapter 14)
- Mount and unmount network file systems using NFS (chapter 16)
- Configure autofs (chapter 16)
- Extend existing logical volumes (chapters 13 and 14)
- Create and configure set-GID directories for collaboration (chapter 4)
- Diagnose and correct file permission problems (chapter 4)
Deploy, Configure, and Maintain Systems
- Schedule tasks using at and cron (chapter 8)
- Start and stop services and configure services to start automatically at boot (chapter 12)
- Configure systems to boot into a specific target automatically (chapter 12)
- Configure time service clients (chapter 17)
- Install and update software packages from Red Hat Network, a remote repository, or from the local file system (chapter 9 and 10)
- Modify the system bootloader (chapter 11)
Manage Basic Networking
- Configure IPv4 and IPv6 addresses (chapter 15)
- Configure hostname resolution (chapter 17)
- Configure network services to start automatically at boot (chapter 12)
- Restrict network access using firewall-cmd/firewall (chapter 19)
Manage Users and Groups
- Create, delete, and modify local user accounts (chapter 5)
- Change passwords and adjust password aging for local user accounts (chapter 5 and 6)
- Create, delete, and modify local groups and group memberships (chapter 6)
- Configure superuser access (chapter 6)
Manage Security
- Configure firewall settings using firewall-cmd/firewalld (chapter 19)
- Manage default file permissions (chapter 04)
- Configure key-based authentication for SSH (chapter 18)
- Set enforcing and permissive modes for SELinux (chapter 20)
- List and identify SELinux file and process context (chapter 20)
- Restore default file contexts (chapter 20)
- Manage SELinux port labels (chapter 20)
- Use Boolean settings to modify system SELinux settings (chapter 20)
- Diagnose and address routine SELinux policy violations (chapter 20)
Manage Containers
- Find and retrieve container images from a remote registry (chapter 22)
- Inspect container images (chapter 22)
- Perform container management using commands such as podman and skopeo (chapter 22)
- Build a container from a Containerfile (chapter 22)
- Perform basic container management such as running, starting, stopping, and listing running containers (chapter 22)
- Run a service inside a container (chapter 22)
- Configure a container to start automatically as a systemd service (chapter 22)
- Attach persistent storage to a container (chapter 22)
SAMPLE CHAPTER
Containers and the Linux Features
The container technology employs some of the core features available in the Linux kernel. These features include control groups, namespaces, seccomp (secure computing mode), and SELinux. A short description of each of these is provided below:
Control Groups
Control groups (abbreviated as cgroups) split processes into groups to set limits on their consumption of compute resources—CPU, memory, disk, and network I/O. These restrictions result in controlling individual processes from over utilizing available resources.
Namespaces
Namespaces restrict the ability of process groups from seeing or accessing system resources—PIDs, network interfaces, mount points, hostname, etc.—thus instituting a layer of isolation between process groups and the rest of the system. This feature guarantees a secure, performant, and stable environment for containerized applications as well as the host operating system.
Secure Computing Mode (seccomp) and SELinux
These features impose security constraints thereby protecting processes from one another and the host operating system from running processes.
The container technology employs these characteristics to run processes isolated in a highly secure environment with full control over what they can or cannot do.
Benefits of Using Containers
There are several benefits linked with using containers. These benefits range from security to manageability and from independence to velocity. The following provides a quick look at common containerization benefits:
Isolation
Containers are not affected due to changes in the host operating system or in other hosted or containerized applications, as they run fully isolated from the rest of the environment.
Loose Coupling
Containerized applications are loosely coupled with the underlying operating system due to their self-containment and minimal level of dependency.
Maintenance Independence
Maintenance is performed independently on individual containers.
Less Overhead
Containers require fewer system resources than do bare metal and virtual servers.
Transition Time
Containers require a few seconds to start and stop.
Transition Independence
Transitioning from one state to another (start or stop) is independent of other containers, and it does not affect or require a restart of any underlying host operating system service.
Portability
Containers can be migrated to other servers without modifications to the contained applications. The target servers may be bare metal or virtual and located on-premises or in the cloud.
Reusability
The same container image can be used to run identical containers in development, test, pre-production, and production environments. There is no need to rebuild the image.
Rapidity
The container technology allows for accelerated application development, testing, deployment, patching, and scaling. Also, there is no need for an exhaustive testing.
Version Control
Container images can be version-controlled, which gives users the flexibility in choosing the right version to run a container.
Container Home: Bare Metal or Virtual Machine
A hypervisor software such as VMware ESXi, Oracle VirtualBox VM Manager, Microsoft Hyper-V, or KVM allows multiple virtual machines to run on the same bare metal physical server. Each virtual machine runs an isolated, independent instance of its own guest operating system. All virtual machines run in parallel and share the resources of the underlying hardware of the bare metal server. Each virtual machine may run multiple applications that share the virtualized resources allocated to it. The hypervisor runs a set of services on the bare metal server to enable virtualization and support virtual machines, which introduces management and operational overheads. Besides, any updates to the guest operating system may require a reboot or result in an application failure.
Containers, in contrast, run directly on the underlying operating system whether it be running on a bare metal server or in a virtual machine. They share hardware and operating system resources securely among themselves. This allows containerized applications to stay lightweight and isolated, and run in parallel. Containers share the same Linux kernel and require far fewer hardware resources than do virtual machines, which contributes to their speedy start and stop. Given the presence of an extra layer of hypervisor services, it may be more beneficial and economical to run containers directly on non-virtualized physical servers.
The added layer of hypervisor is shown in the middle stack. Any of the above implementation can run multiple applications concurrently. A decision as to which option to go with requires a careful use case study; however, the benefits of running containers on bare metal servers are obvious.
Container Images and Container Registries
Launching a container requires a pre-packaged image to be available. A container image is essentially a static file that is built with all necessary components—application binaries, library files, configuration settings, environment variables, static data files, etc.—required by an application to run smoothly, securely, and independently. RHEL follows the open container initiative (OCI) to allow users to build images based on industry standard specifications that define the image format, host operating system metadata, and supported hardware architectures. An OCI-compliant image can be executed and managed with OCI-compliant tools such as podman (pod manager) and Docker. Images can be version-controlled giving users the suppleness to use the latest or any of the previous versions to launch their containers. A single image can be used to run several containers at once.
Container images adhere to a standard naming convention for identification. This is referred to as fully qualified image name (FQIN). An FQIN is comprised of four components: (1) the storage location (registry_name), (2) the owner or organization name (user_name), (3) a unique repository name (repo_name), and (4) an optional version (tag). The syntax of an FQIN is registry_hostname/user_name/repo_name:tag.
Images are stored and maintained in public or private registries; however, they need to be downloaded and made locally available for consumption. There are several registries available on the Internet. These include registry.redhat.io (images based on official Red Hat products; requires authentication), registry.access.redhat.com (requires no authentication), registry.connect.redhat.com (images based on third-party products), and hub.docker.com (Docker Hub). The three Red Hat registries may be searched using the Red Hat Container Catalog at catalog.redhat.com/software/containers/search. Additional registries may be added as required. Private registries may also require authentication for access.
Rootful vs. Rootless Containers
Containers can be launched with the root user privileges (sudo or directly as the root user). This gives containers full access to perform administrative functions including the ability to map privileged network ports (1024 and below). However, launching containers with superuser rights opens a gate to potential unauthorized access to the container host if a container is compromised due to a vulnerability or misconfiguration.
To secure containers and the underlying operating system, containers should be launched and interacted with as normal Linux users. Such containers are referred to as rootless containers. Rootless containers allow regular, unprivileged users to run containers without the ability to perform tasks that require privileged access.
ERRATA
Chapter 04, Section: Using the find Command: The diagram shows the wrong switch “amin” for time modification, it should be mmin.
Chapter 04, Section: Using the find command: The third example from the last “find /dev -type c -perm -222”. The description should say read and execute permissions and not write and execute permissions.
Chapter 04, Questions and Answers: Correct sequence is here:
Review Questions
1. What would the find / -name core -ok rm {} ; command do?
2. Default permissions are calculated by subtracting the initial permissions from the umask value. True or False?
3. What would be the effect of the sticky bit on an executable file?
4. Name the permission classes, types, and modes.
5. The default umask for a normal user in bash shell is 0027. True or False?
6. What digit represents the setuid bit in the chmod command?
7. The output generated by the umask command shows the current user mask in four digits. What is the significance of the left-most digit?
8. What would the command find /dev -type c -perm 660 do?
9. What would the command chmod g-s file1 do?
10. The sticky bit is recommended for every system directory. True or False?
11. The setgid bit enables group members to run a command at a higher priority. True or False?
12. What is the equivalent symbolic value for permissions 751?
13. What permissions would the owner of the file get if the chmod command is executed with 555?
14. Which special permission bit is set on a directory for team sharing?
Answers to Review Questions
1. The find command provided will display all files by the name core in the entire directory hierarchy and ask for removal confirmation as it finds them.
2. False. Default permissions are calculated by subtracting the umask value from the initial permission values.
3. Nothing, the sticky bit is meant for directories only.
4. Permission classes are user, group, and public; permission types are read, write, and execute; and permission modes are add, revoke, and assign.
5. False. The default umask for bash shell users is 0022.
6. The digit 4 represents the setuid bit.
7. The left-most digit has no significance in the umask value.
8. The find command provided will find all character device files under /dev with permissions 660.
9. It would erase the setgid bit from file1.
10. False.
11. False.
12. The equivalent for octal 751 is rwxr-x–x.
13. The owner will get read and execute permissions.
14. The setgid bit is used for team sharing.
Chapter 08, Exercise 8-3, Step 1: The command at the at> prompt is date and not data.
Chapter 13, Lab 13-7: There is a typo in the lab description. It should be uninitialize the physical volumes and not uninitialized.
Chapter 13, Answer to Question 31: The answer is true.
Chapter 14, Section: Determining the UUID of a File System: The second paragraph has an extra is (highlighted) “The /boot file system, for instance, is located in a partition and the device file associated with it is on server2 is /dev/sda1.”
Chapter 20, Section: Querying Status: The explanation for the sestatus command should say ……….and it is running in permissive mode (Current mode) with the targeted policy in effect…………….
Chapter 20, Section, SELinux Administration: The third sentence in the first paragraph should be read as ……….. multiple packages, such as libselinux-utils provides setenforce, getenforce, and getsebool commands.