Comprehensive reviews:

Manage Users and Groups, Permissions, and Processes

Specifications

• Identify and terminate the process that currently uses the most CPU time.

• Create the database group with a GID of 50000.

• Create the dbadmin1 user and configure it with the following requirements:

  • Add the database group as a secondary group.

  • Set the password to redhat and force a password change on first login.

  • Allow the password to change after 10 days since the day of the last password change.

  • Set the password expiration to 30 days since the day of the last password change.

  • Allow the user to use the sudo command to run any command as the superuser.

  • Configure the default umask as 007.

• Create the /home/student/grading/review2 directory with dbadmin1 as the owning user and the database group as the owning group.

• Configure the /home/student/grading/review2 directory so that the database group owns any file that is created in this directory, irrespective of which user created the file.

  • Configure the permissions on the directory to allow members of the database group and the student user to access the directory and create contents in it.

  • All other users should have read and execute permissions on the directory.

• Ensure that users are allowed to delete only files that they own from the /home/student/grading/review2 directory

Configure and Manage a Server

Specifications

• Generate SSH keys for the student user on serverb. Do not protect the private key with a passphrase. Save the private and public keys as the /home/student/.ssh/review3_key and /home/student/.ssh/review3_key.pub files respectively.

• Configure the student user on servera to accept logins authenticated by the review3_key SSH key pair. The student user on serverb should be able to log in to servera using SSH without entering a password.

• On serverb, configure the sshd service to prevent the root user from logging in.

• On serverb, configure the sshd service to prevent users from using their passwords to log in. Users should still be able to authenticate logins using an SSH key pair.

• Create a /tmp/log.tar tar archive containing the contents of the /var/log directory on serverb. Remotely transfer the tar archive to the /tmp directory on servera, authenticating as the student user with the review3_key private key.

• Configure the rsyslog service on serverb to log all debug priority messages or higher to the /var/log/grading-debug file. Define the configuration in the /etc/rsyslog.d/grading-debug.conf file.

• Install the zsh package on the serverb machine.

• Set the time zone of serverb to Asia/Kolkata.

Manage Networks

Specifications

• On serverb, determine the name of the Ethernet interface and its active connection profile.

Network Configuration Parameters:

Parameter	Setting
IPv4 address	172.25.250.111
Netmask	255.255.255.0
Gateway	172.25.250.254
DNS Server	172.25.250.254

• On serverb, create a static connection profile for the available Ethernet interface. The static profile statically sets network settings and does not use DHCP. Configure the static profile to use the network settings in the table above.

• Set the serverb hostname to server-review4.lab4.example.com.

• On serverb, set client-review4 as the canonical hostname for the servera 172.25.250.10 IPv4 address.

• Configure the static connection profile with an additional IPv4 address of 172.25.250.211 with a netmask of 255.255.255.0. Do not remove the existing IPv4 address. Ensure that serverb responds to all addresses when the static connection is active.

• On serverb, restore the original network settings by activating the original network connection profile.

Mount File Systems and Find Files

Specifications

• Identify the unmounted block device that contains an XFS file system on the serverb machine. Mount the block device on the /review5-disk directory.

• Locate the review5-path file. Create the /review5-disk/review5-path.txt file that contains a single line with the absolute path to the review5-path file.

• Locate all the files that the contractor1 user and the contractor group own. The files must also have the octal permissions of 640. Save the list of these files in the /review5-disk/review5-perms.txt file.

• Locate all files with a size of 100 bytes. Save the absolute paths of these files in /review5-disk/review5-size.txt.

Fix Boot Issues and Maintain Servers

Specifications

• On workstation, run the /tmp/rhcsa-break1 script. This script causes an issue with the boot process on serverb and then reboots the machine. Troubleshoot the cause and repair the boot issue. When prompted, use redhat as the password of the root user.

• On workstation, run the /tmp/rhcsa-break2 script. This script causes the default target to switch from the multi-user target to the graphical target on the serverb machine and then reboots the machine. On serverb, reset the default target to use the multi-user target. The default target settings must persist after reboot without manual intervention. As the student user, use the sudo command for performing privileged commands. Use student as the password when required.

• On serverb, schedule a recurring job as the student user that executes the /home/student/backup-home.sh script hourly between 7 PM and 9 PM every day except on Saturday and Sunday. Download the backup script from http://materials.example.com/labs/backup-home.sh. The backup-home.sh script backs up the /home/student directory from serverb to servera in the /home/student/serverb-backup directory. Use the backup-home.sh script to schedule the recurring job as the student user.

• Reboot the serverb machine and wait for the boot to complete before grading.

Configure and Manage File Systems and Storage

Specifications

• On serverb, configure a new 1 GiB vol_home logical volume in a new 2 GiB extra_storage volume group. Use the unpartitioned /dev/vdb disk to create the partition.

• Format the vol_home logical volume with the XFS file-system type, and persistently mount it on the /user-homes directory.

• On serverb, persistently mount the /share network file system that servera exports on the /local-share directory. The servera machine exports the servera.lab.example.com:/share path.

• On serverb, create a new 512 MiB swap partition on the /dev/vdc disk. Persistently mount the swap partition.

• Create the production user group. Create the production1, production2, production3, and production4 users with the production group as their supplementary group.

• On serverb, configure the /run/volatile directory to store temporary files. If the files in this directory are not accessed for more than 30 seconds, the system automatically deletes them. Set 0700 as the octal permissions for the directory. Use the /etc/tmpfiles.d/volatile.conf file to configure the time-based deletion of the files in the /run/volatile directory.

Configure and Manage Server Security

Specifications

• On serverb, generate an SSH key pair for the student user. Do not protect the private key with a passphrase.

• Configure the student user on servera to accept login authentication with the SSH key pair that you generated on the serverb machine. The student user on serverb must be able to log in to servera via SSH without entering a password.

• On servera, check the /user-homes/production5 directory permissions. Then, configure SELinux to run in the permissive mode by default.

• On serverb, verify that the /localhome directory does not exist. Then, configure the production5 user's home directory to mount the /user-homes/production5 network file system. The servera.lab.example.com machine exports the file system as the servera.lab.example.com:/user-homes/production5 NFS share. Use the autofs service to mount the network share. Verify that the autofs service creates the /localhome/production5 directory with the same permissions as on servera.

• On serverb, adjust the appropriate SELinux Boolean so that the production5 user may use the NFS-mounted home directory after authenticating with an SSH key. If required, use redhat as the password of the production5 user.

• On serverb, adjust the firewall settings to reject all connection requests from the servera machine. Use the servera IPv4 address (172.25.250.10) to configure the firewall rule.

• On serverb, investigate and fix the issue with the failing Apache web service, which listens on port 30080/TCP for connections. Adjust the firewall settings appropriately so that the port 30080/TCP is open for incoming connections.

Run Containers

Specifications

• On serverb, configure the podmgr user with redhat as the password and set up the appropriate tools for the podmgr user to manage the containers for this comprehensive review. Configure registry.lab.example.com as the remote registry. Use admin as the user and redhat321 as the password to authenticate. You can use the /tmp/review4/registry.conf file to configure the registry.

• The /tmp/review4/container-dev directory contains two directories with development files for the containers in this comprehensive review. Copy the two directories under the /tmp/review4/container-dev directory to the podmgr home directory. Configure the /home/podmgr/storage/database subdirectory so that you can use it as persistent storage for a container.

• Create the production DNS-enabled container network. Use the 10.81.0.0/16 subnet and 10.81.0.1 as the gateway. Use this container network for the containers that you create in this comprehensive review.

• Create the db-app01 detached container based on the registry.lab.example.com/rhel8/mariadb-103 container image with the lowest tag number in the production network. Use the /home/podmgr/storage/database directory as persistent storage for the /var/lib/mysql/data directory of the db-app01 container. Map the 13306 port on the local machine to the 3306 port in the container. Use the following environment variables to create the containerized database:

  Variable	Value
  MYSQL_USER	developer
  MYSQL_PASSWORD	redhat
  MYSQL_DATABASE	inventory
  MYSQL_ROOT_PASSWORD	redhat

• Create a systemd service file to manage the db-app01 container. Configure the systemd service so that when you start the service, the systemd daemon keeps the original container. Start and enable the container as a systemd service. Configure the db-app01 container to start at system boot.

• Copy the /home/podmgr/db-dev/inventory.sql script into the /tmp directory of the db-app01 container and execute it inside the container. If you executed the script locally, you would use the following command: mysql -u root inventory < /tmp/inventory.sql.

• Use the container file in the /home/podmgr/http-dev directory to create the http-app01 detached container in the production network. The container image name must be http-client with the 9.0 tag. Map the 8080 port on the local machine to the 8080 port in the container.

• Use the curl command to query the content of the http-app01 container. Verify that the output of the command shows the container name of the client and that the status of the database is "up".