RHEL System Roles is a collection of Ansible roles and modules. RHEL System Roles provide a configuration interface to remotely manage multiple RHEL systems. The interface enables managing system configurations across multiple versions of RHEL, as well as adopting new major releases.

On Red Hat Enterprise Linux 8, the interface currently consists of the following roles:

All these roles are provided by the rhel-system-roles package available in the AppStream repository.

You can find the following terms across this documentation:

The following procedure describes how to apply a particular role.

Accurate timekeeping is important for a number of reasons. In Red Hat Enterprise Linux, timekeeping is ensured by the NTP protocol, which is implemented by a daemon running in user space. The user-space daemon updates the system clock running in the kernel. The system clock can keep time by using various clock sources.

Red Hat Enterprise Linux 8 uses the chronyd daemon to implement NTP. chronyd is available from the chrony package. For more information, see Using the chrony suite to configure NTP.

System-wide locale settings are stored in the /etc/locale.conf file, which is read at early boot by the systemd daemon. Every service or user inherits the locale settings configured in /etc/locale.conf, unless individual programs or individual users override them.

This section describes how to manage system locale.

The keyboard layout settings control the layout used on the text console and graphical user interfaces.

This section describes how to change the system language using the desktop GUI.

Follow the steps in this procedure to configure your network and host name.

This procedure describes adding an Ethernet connection with the following settings using the nmcli utility:

The nmtui application provides a text user interface to NetworkManager. This procedure describes how to add a new connection profile.

In the web console, the Networking menu enables you:

Figure 3.1. Managing Networking in the RHEL 8 web console

You can configure the networking connections on multiple target machines using the network role.

The network role allows to configure the following types of interfaces:

The required networking connections for each host are provided as a list within the network_connections variable.

The following example shows how to apply the network role to ensure that an Ethernet connection with the required parameters exists:

# SPDX-License-Identifier: BSD-3-Clause
---
- hosts: network-test
  vars:
    network_connections:

      # Create one ethernet profile and activate it.
      # The profile uses automatic IP addressing
      # and is tied to the interface by MAC address.
      - name: prod1
        state: up
        type: ethernet
        autoconnect: yes
        mac: "00:00:5e:00:53:00"
        mtu: 1450

  roles:
    - rhel-system-roles.network

Use the following procedure to register your system if you have not registered it during the installation process already.

Use the following steps to register a newly installed Red Hat Enterprise Linux using the RHEL 8 web console.

At this point, your Red Hat Enterprise Linux 8 system has been successfully registered.

Follow the steps in this procedure to enroll your system with your Red Hat account.

Follow the steps in this procedure to register your system with an activation key. You can get the activation key from your organization administrator.

You can determine which services are enabled or disabled at boot time already during the installation process. You can also enable or disable a service on an installed operating system.

This section describes the steps for enabling or disabling those services on an already installed operating system:

# systemctl unmask service_name

This section describes how you can also enable or disable a service using the web console. You can manage systemd targets, services, sockets, timers, and paths. You can also check the service status, start or stop services, enable or disable them.

A firewall is a network security system that monitors and controls incoming and outgoing network traffic according to configured security rules. A firewall typically establishes a barrier between a trusted secure internal network and another outside network.

The firewalld service, which provides a firewall in Red Hat Enterprise Linux, is automatically enabled during installation.

To enable the firewalld service, follow this procedure.

To configure the firewalld service in the web console, navigate to Networking → Firewall.

By default, the firewalld service is enabled.

Security-Enhanced Linux (SELinux) is an additional layer of system security that determines which processes can access which files, directories, and ports. These permissions are defined in SELinux policies. A policy is a set of rules that guide the SELinux security engine.

SELinux has two possible states:

When SELinux is enabled, it runs in one of the following modes:

In enforcing mode, SELinux enforces the loaded policies. SELinux denies access based on SELinux policy rules and enables only the interactions that are explicitly allowed. Enforcing mode is the safest SELinux mode and is the default mode after installation.

In permissive mode, SELinux does not enforce the loaded policies. SELinux does not deny access, but reports actions that break the rules to the /var/log/audit/audit.log log. Permissive mode is the default mode during installation. Permissive mode is also useful in some specific cases, for example when troubleshooting problems.

By default, SELinux operates in enforcing mode. However, in specific scenarios, you can set SELinux to permissive mode or even disable it.

Follow this procedure to change the state and mode of SELinux on your system.

You can set SELinux mode through the RHEL 8 web console in the SELinux menu item.

By default, SELinux enforcing policy in the web console is on, and SELinux operates in enforcing mode. By turning it off, you switch SELinux to permissive mode. Note that this selection is automatically reverted on the next boot to the configuration defined in the /etc/sysconfig/selinux file.

This section describes basic command-line tools to manage user accounts and groups.

With user accounts displayed in the RHEL web console you can:

The RHEL web console displays all user accounts located in the system. Therefore, you can see at least one user account just after the first login to the web console.

After logging into the RHEL web console, you can perform the following operations:

Use the following steps for adding user accounts to the system and setting administration rights to the accounts through the RHEL web console.

kdump is a service providing a crash dumping mechanism. The service enables you to save the contents of the system’s memory for later analysis. kdump uses the kexec system call to boot into the second kernel (a capture kernel) without rebooting; and then captures the contents of the crashed kernel’s memory (a crash dump or a vmcore) and saves it. The second kernel resides in a reserved part of the system memory.

The procedure below shows you how to use the Kernel Dump tab in the Red Hat Enterprise Linux web console interface to configure the amount of memory that is reserved for the kdump kernel. The procedure also describes how to specify the target location of the vmcore dump file and how to test your configuration.

RHEL System Roles is a collection of Ansible roles and modules that provide a consistent configuration interface to remotely manage multiple RHEL systems. The kdump role enables you to set basic kernel dump parameters on multiple systems.

The following example playbook shows how to apply the kdump system role to set the location of the crash dump files:

---
- hosts: kdump-test
  vars:
    kdump_path: /var/crash
  roles:
    - rhel-system-roles.kdump

For a detailed reference on kdump role variables, install the rhel-system-roles package, and see the README.md or README.html files in the /usr/share/doc/rhel-system-roles/kdump directory.

Use the following steps to install the packages for using the Relax-and-Recover (ReaR) utility, create a rescue system, configure and generate a backup.

The following two services handle syslog messages:

The systemd-journald daemon collects messages from various sources and forwards them to Rsyslog for further processing. The systemd-journald daemon collects messages from the following sources:

The Rsyslog service sorts the syslog messages by type and priority and writes them to the files in the /var/log directory. The /var/log directory persistently stores the log messages.

The following subdirectories under the /var/log directory store syslog messages.

Follow the steps in this procedure to inspect the log files using the web console.

Figure 10.1. Inspecting the log files in the RHEL 8 web console

The Journal is a component of systemd that helps to view and manage log files. It addresses problems connected with traditional logging, closely integrated with the rest of the system, and supports various logging technologies and access management for the log files.

You can use the journalctl command to view messages in the system journal using the command line, for example:

$ journalctl -b | grep kvm
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: cpu 0, msr 76401001, primary cpu clock
...

The following section describes how to use the Red Hat Customer Portal to get help.

The sosreport command collects configuration details, system information and diagnostic information from a Red Hat Enterprise Linux system.

The following section describes how to use the sosreport command to produce reports for your support cases.

In RHEL 8, software installation is enabled by the new version of the YUM tool (YUM v4), which is based on the DNF technology.

Although YUM v4 used in RHEL 8 is based on DNF, it is compatible with YUM v3 used in RHEL 7. For software installation, the yum command and most of its options work the same way in RHEL 8 as they did in RHEL 7.

Selected yum plug-ins and utilities have been ported to the new DNF back end, and can be installed under the same names as in RHEL 7. Packages also provide compatibility symlinks, so the binaries, configuration files, and directories can be found in usual locations.

Note that the legacy Python API provided by YUM v3 is no longer available. You can migrate your plug-ins and scripts to the new API provided by YUM v4 (DNF Python API), which is stable and fully supported. See DNF API Reference for more information.

Red Hat Enterprise Linux 8 introduces the concept of Application Streams. Multiple versions of user space components are now delivered and updated more frequently than the core operating system packages. This provides greater flexibility to customize Red Hat Enterprise Linux without impacting the underlying stability of the platform or specific deployments.

Components made available as Application Streams can be packaged as modules or RPM packages, and are delivered through the AppStream repository in Red Hat Enterprise Linux 8. Each Application Stream has a given life cycle, either the same as RHEL 8 or shorter, more suitable to the particular application. Application Streams with a shorter life cycle are listed in the Red Hat Enterprise Linux 8 Application Streams Life Cycle page.

Modules are collections of packages representing a logical unit: an application, a language stack, a database, or a set of tools. These packages are built, tested, and released together.

Module streams represent versions of the Application Stream components. For example, two streams (versions) of the PostgreSQL database server are available in the postgresql module: PostgreSQL 10 (the default stream) and PostgreSQL 9.6. Only one module stream can be installed on the system. Different versions can be used in separate containers.

Detailed module commands are described in the Installing, managing, and removing user-space components document. For a list of modules available in AppStream, see the Package manifest.

yum allows you to perform a complete set of operations with software packages.

The following section describes how to use yum to:

The following section describes how to use yum to:

yum allows you to check if your system has any pending updates. You can list packages that need updating and choose to update a single package, multiple packages, or all packages at once. If any of the packages you choose to update have dependencies, they are updated as well.

The following section describes how to use yum to:

# systemctl enable dnf-automatic-download.timer

# systemctl start dnf-automatic-download.timer

# systemctl enable dnf-automatic-install.timer

# systemctl start dnf-automatic-install.timer

# systemctl enable dnf-automatic-notifyonly.timer

# systemctl start dnf-automatic-notifyonly.timer

# systemctl enable dnf-automatic.timer

# systemctl start dnf-automatic.timer

The following section describes how to use yum to:

A package group is a collection of packages that serve a common purpose (System Tools, Sound and Video). Installing a package group pulls a set of dependent packages, which saves time considerably.

The following section describes how to use yum to:

The yum history command allows you to review information about the timeline of yum transactions, dates and times they occurred, the number of packages affected, whether these transactions succeeded or were aborted, and if the RPM database was changed between transactions. yum history command can also be used to undo or redo the transactions.

The following section describes how to use yum to:

The configuration information for yum and related utilities are stored in the /etc/yum.conf file. This file contains one or more [repository] sections, which allow you to set repository-specific options.

It is recommended to define individual repositories in new or existing .repo files in the /etc/yum.repos.d/ directory.

Note that the values you define in individual [repository] sections of the /etc/yum.conf file override values set in the [main] section.

The following section describes how to:

The configuration information for yum and related utilities are stored in the /etc/yum.conf file. This file contains one mandatory [main] section, which enables you to set yum options that have global effect.

The following section describes how to:

The systemd system and service manager provides the following main features:

The systemd system and service manager is designed to be mostly compatible with SysV init and Upstart. The following are the most notable compatibility changes with regards to Red Hat Enterprise Linux 6 system that used SysV init:

For a detailed list of compatibility changes introduced with systemd, see the Migration Planning Guide for Red Hat Enterprise Linux 7.

The service units help to control the state of services and daemons in your system.

Service units end with the .service file extension, for example nfs-server.service. However, while using service file names in commands, you can omit the file extension. The systemctl utility assumes the argument is a service unit. For example, to stop the nfs-server.service, enter the following command:

# systemctl stop nfs-server

Additionally, some service units have alias names. Aliases can be shorter than units, and you can use them instead of the actual unit names.

To find all aliases that can be used for a particular unit, use:

# systemctl show nfs-server.service -p Names

This section shows a comparison between a service utility and the usage of systemctl command.

You can list all currently loaded service units and the status of all available service units.

You can inspect any service unit to get its detailed information and verify the state of the service whether it is enabled or running. You can also view services that are ordered to start after or before a particular service unit.

In systemd, positive and negative dependencies between services exist. Starting a particular service may require starting one or more other services (positive dependency) or stopping one or more services (negative dependency).

When you attempt to start a new service, systemd resolves all dependencies automatically, without explicit notification to the user. This means that if you are already running a service, and you attempt to start another service with a negative dependency, the first service is automatically stopped.

For example, if you are running the postfix service, and you attempt to start the sendmail service, systemd first automatically stops postfix, because these two services are conflicting and cannot run on the same port.

You can start system service in the current session using the start command. You must have a root access as starting a service may affect the state of the operating system.

You can stop system service in the current session using the stop command. You must have a root access as stopping a service may affect the state of the operating system.

You can restart system service in the current session using the restart command. You must have a root access as restarting a service may affect the state of the operating system.

This procedure describes how to:

You can configure service to start automatically at the system booting time. The enable command reads the [Install] section of the selected service unit and creates appropriate symbolic links to the /usr/lib/systemd/system/name.service file in the /etc/systemd/system/ directory and its sub-directories. However, it does not rewrite links that already exist.

You can prevent a service unit from starting automatically at boot time. The disable command reads the [Install] section of the selected service unit and removes appropriate symbolic links to the /usr/lib/systemd/system/name.service file from the /etc/systemd/system/ directory and its sub-directories.

The previous versions of Red Hat Enterprise Linux were distributed with SysV init or Upstart, and implemented a predefined set of runlevels that represented specific modes of operation. These runlevels were numbered from 0 to 6 and were defined by a selection of system services to be run when a particular runlevel was enabled by the system administrator. Starting with Red Hat Enterprise Linux 7, the concept of runlevels has been replaced with systemd targets.

Red Hat Enterprise Linux 7 was distributed with a number of predefined targets that are more or less similar to the standard set of runlevels from the previous releases. For compatibility reasons, it also provides aliases for these targets that directly maps to the SysV runlevels.

The following table provides a complete list of SysV runlevels and their corresponding systemd targets:

The following table compares the SysV init commands with systemctl. Use the systemctl utility to view, change, or configure systemd targets:

The default target unit is represented by the /etc/systemd/system/default.target file.

By default, the systemctl list-units command displays only active units.

The default target unit is represented by the /etc/systemd/system/default.target file. The following procedure describes how to change the default target by using the systemctl command:

The following procedure describes how to change the default target by creating a symbolic link to the target.

This procedure explains how to change the target unit in the current session using the systemctl command.

Replace multi-user with the name of the target unit you want to use by default.

Rescue mode provides a convenient single-user environment and allows you to repair your system in situations when it is unable to complete a regular booting process. In rescue mode, the system attempts to mount all local file systems and start some important system services, but it does not activate network interfaces or allow more users to be logged into the system at the same time.

Emergency mode provides the most minimal environment possible and allows you to repair your system even in situations when the system is unable to enter rescue mode. In emergency mode, the system mounts the root file system only for reading, does not attempt to mount any other local file systems, does not activate network interfaces, and only starts a few essential services.

To shut down the system, you can either use the systemctl utility directly, or call this utility through the shutdown command.

The advantage of using the shutdown command is:

By following this procedure, you can use the shutdown command to perform various operations. You can either shut down the system and power off the machine at a certain time, or shut down and halt the system without powering off the machine, or cancel a pending shutdown.

By following this procedure, you can use the systemctl command to perform various operations. You can either shut down the system and power off the machine, or shut down and halt the system without powering off the machine.

You can restart the system by following this procedure.

You can suspend the system by following this procedure.

By following this procedure, you can either hibernate the system, or hibernate and suspend the system.

You can use the following list of the systemctl commands to control the power management of your system.

A unit file contains configuration directives that describe the unit and define its behavior. Several systemctl commands work with unit files in the background. To make finer adjustments, system administrator must edit or create unit files manually. Table 13.1, “Systemd unit files locations” lists three main directories where unit files are stored on the system, the /etc/systemd/system/ directory is reserved for unit files created or customized by the system administrator.

Unit file names take the following form:

unit_name.type_extension

Here, unit_name stands for the name of the unit and type_extension identifies the unit type, see Table 13.2, “Available systemd unit types” for a complete list of unit types. For example, there usually is sshd.service as well as sshd.socket unit present on your system.

Unit files can be supplemented with a directory for additional configuration files. For example, to add custom configuration options to sshd.service, create the sshd.service.d/custom.conf file and insert additional directives there. For more information on configuration directories, see Modifying existing unit files.

Also, the sshd.service.wants/ and sshd.service.requires/ directories can be created. These directories contain symbolic links to unit files that are dependencies of the sshd service. The symbolic links are automatically created either during installation according to [Install] unit file options or at runtime based on [Unit] options. It is also possible to create these directories and symbolic links manually. For more details on [Install] and [Unit] options, see the tables below.

Many unit file options can be set using the so called unit specifiers – wildcard strings that are dynamically replaced with unit parameters when the unit file is loaded. This enables creation of generic unit files that serve as templates for generating instantiated units. See Working with instantiated units for details.

Unit files typically consist of three sections:

There are several use cases for creating unit files from scratch: you could run a custom daemon, create a second instance of some existing service (as in Creating a second instance of the sshd service), or import a SysV init script (more in Converting SysV init scripts to unit files). On the other hand, if you intend just to modify or extend the behavior of an existing unit, use the instructions from Modifying existing unit files. The following procedure describes the general process of creating a custom service.

Before taking time to convert a SysV init script to a unit file, make sure that the conversion was not already done elsewhere. All core services installed on Red Hat Enterprise Linux come with default unit files, and the same applies for many third-party software packages.

Converting an init script to a unit file requires analyzing the script and extracting the necessary information from it. Based on this data you can create a unit file. As init scripts can vary greatly depending on the type of the service, you might need to employ more configuration options for translation than outlined in this chapter. Note that some levels of customization that were available with init scripts are no longer supported by systemd units.

The majority of information needed for conversion is provided in the script’s header. The following example shows the opening section of the init script used to start the postfix service on Red Hat Enterprise Linux 6:

!/bin/bash # postfix Postfix Mail Transfer Agent # chkconfig: 2345 80 30 # description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # processname: master # pidfile: /var/spool/postfix/pid/master.pid # config: /etc/postfix/main.cf # config: /etc/postfix/master.cf  BEGIN INIT INFO # Provides: postfix MTA # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop postfix # Description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # END INIT INFO

In the above example, only lines starting with # chkconfig and # description are mandatory, so you might not find the rest in different init files. The text enclosed between the BEGIN INIT INFO and END INIT INFO lines is called Linux Standard Base (LSB) header. If specified, LSB headers contain directives defining the service description, dependencies, and default runlevels. What follows is an overview of analytic tasks aiming to collect the data needed for a new unit file. The postfix init script is used as an example.

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}

start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}

Services installed on the system come with default unit files that are stored in the /usr/lib/systemd/system/ directory. System Administrators should not modify these files directly, therefore any customization must be confined to configuration files in the /etc/systemd/system/ directory.

It is possible to instantiate multiple units from a single template configuration file at runtime. The "@" character is used to mark the template and to associate units with it. Instantiated units can be started from another unit file (using Requires or Wants options), or with the systemctl start command. Instantiated service units are named the following way:

template_name@instance_name.service

Where template_name stands for the name of the template configuration file. Replace instance_name with the name for the unit instance. Several instances can point to the same template file with configuration options common for all instances of the unit. Template unit name has the form of:

unit_name@.service

For example, the following Wants setting in a unit file:

Wants=getty@ttyA.service getty@ttyB.service

first makes systemd search for given service units. If no such units are found, the part between "@" and the type suffix is ignored and systemd searches for the getty@.service file, reads the configuration from it, and starts the services.

For example, the getty@.service template contains the following directives:

[Unit]
Description=Getty on %I
…​
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
…​

When the getty@ttyA.service and getty@ttyB.service are instantiated from the above template, Description= is resolved as Getty on ttyA and Getty on ttyB.

To examine system boot performance, you can use the systemd-analyze command. This command has many options available. However, this section covers only the selected ones that may be important for systemd tuning in order to shorten the boot time.

For a complete list and detailed description of all options, see the systemd-analyze man page.

$ systemctl list-unit-files --state=enabled

Analyzing overall boot time

$ systemd-analyze

Analyzing unit initialization time

$ systemd-analyze blame

The output lists the units in descending order according to the time they took to initialize during the last successful boot.

Identifying critical units

$ systemd-analyze critical-chain

The output highlights the units that critically slow down the boot with the red color.

Figure 18.1. The output of the systemd-analyze critical-chain command

If you find the boot time of your system long, you can shorten it by disabling some of the services enabled on boot by default.

To list such services, run:

$ systemctl list-unit-files --state=enabled

To disable a service, run:

# systemctl disable service_name

However, certain services must stay enabled in order that your operating system is safe and functions in the way you need.

You can use the table below as a guide to selecting the services that you can safely disable. The table lists all services enabled by default on a minimal installation of Red Hat Enterprise Linux 8, and for each service it states whether this service can be safely disabled.

The table also provides more information about the circumstances under which the service can be disabled, or the reason why you should not disable the service.

To find more information about a service, you can run one of the following commands:

$ systemctl cat <service_name>

$ systemctl help <service_name>

The systemctl cat command provides the content of the service file located under /usr/lib/systemd/system/<service>, as well as all applicable overrides. The applicable overrides include unit file overrides from the /etc/systemd/system/<service> file or drop-in files from a corresponding unit.type.d directory.

For more information on drop-in files, see the systemd.unit man page.

The systemctl help command shows the man page of the particular service.

A user who creates a file is the owner of that file and the group owner of that file. The file is assigned separate read, write, and execute permissions for the owner, the group, and those outside that group. The file owner can be changed only by the root user. Access permissions to the file can be changed by both the root user and the file owner. A regular user can change group ownership of a file they own to a group of which they are a member of.

Each user is associated with a unique numerical identification number called user ID (UID). Each group is associated with a group ID (GID). Users within a group share the same permissions to read, write, and execute files owned by that group.

RHEL reserves user and group IDs below 1000 for system users and groups. You can find the reserved user and group IDs in the setup package. To view reserved user and group IDs, use:

cat /usr/share/doc/setup*/uidgid

It is recommended to assign IDs to the new users and groups starting at 5000, as the reserved range can increase in the future.

To make the IDs assigned to new users start at 5000 by default, modify the UID_MIN and GID_MIN parameters in the /etc/login.defs file.

Note that for users and groups created before you changed the UID_MIN and GID_MIN values, UIDs and GIDs still start at the default 1000.

RHEL uses the user private group (UPG) system configuration, which makes UNIX groups easier to manage. A user private group is created whenever a new user is added to the system. The user private group has the same name as the user for which it was created and that user is the only member of the user private group.

UPGs simplify the collaboration on a project between multiple users. In addition, UPG system configuration makes it safe to set default permissions for a newly created file or directory, as it allows both the user, and the group this user is a part of, to make modifications to the file or directory.

A list of all groups is stored in the /etc/group configuration file.

With user accounts displayed in the RHEL web console you can:

The RHEL web console displays all user accounts located in the system. Therefore, you can see at least one user account just after the first login to the web console.

After logging into the RHEL web console, you can perform the following operations:

Use the following steps for adding user accounts to the system and setting administration rights to the accounts through the RHEL web console.

By default, user accounts have set passwords to never expire. You can set system passwords to expire after a defined number of days. When the password expires, the next login attempt will prompt for a password change.

A user creates user sessions when logging into the system. Terminating user sessions means to log the user out from the system. It can be helpful if you need to perform administrative tasks sensitive to configuration changes, for example, system upgrades.

In each user account in the RHEL 8 web console, you can terminate all sessions for the account except for the web console session you are currently using. This prevents you from loosing access to your system.

This section describes how to use the useradd utility to add a new user.

This section describes how to use the groupadd utility to add a new group.

This section describes how to use the usermod utility to add a group to the supplementary groups of the user.

Under the UPG system configuration, you can apply the set-group identification permission (setgid bit) to a directory. The setgid bit makes managing group projects that share a directory simpler. When you apply the setgid bit to a directory, files created within that directory are automatically assigned to a group that owns the directory. Any user that has the permission to write and execute within this group can now create, modify, and delete files in the directory.

The following section describes how to create group directories.

This section describes how to use the usermod utility to override the primary group of the user.

This section describes how to use the usermod utility to override the supplementary groups of the user.

The /etc/sudoers file specifies which users can run which commands using the sudo command. The rules can apply to individual users and user groups. You can also use aliases to simplify defining rules for groups of hosts, commands, and even users. Default aliases are defined in the first part of the /etc/sudoers file.

When a user tries to use sudo privileges to run a command that is not allowed in the /etc/sudoers file, the system records a message containing username : user NOT in sudoers to the journal log.

The default /etc/sudoers file provides information and examples of authorizations. You can activate a specific example rule by removing the # comment character from the beginning of the line. The authorizations section relevant for user is marked with the following introduction:

## Next comes the main part: which users can run what software on
## which machines  (the sudoers file can be shared between multiple
## systems).

You can use the following format to create new sudoers authorizations and to modify existing authorizations:

username hostname=path/to/command

Where:

You can replace any of these variables with ALL to apply the rule to all users, hosts, or commands.

You can specify the arguments negatively using the ! operator. For example, use !root to specify all users except the root user. Note that using the allowlists to allow specific users, groups, and commands, is more secure than using the blocklists to disallowing specific users, groups, and commands. By using the allowlists you also block new unauthorized users or groups.

The system reads the /etc/sudoers file from beginning to end. Therefore, if the file contains multiple entries for a user, the entries are applied in order. In case of conflicting values, the system uses the last match, even if it is not the most specific match.

The preferred way of adding new rules to sudoers is by creating new files in the /etc/sudoers.d/ directory instead of entering rules directly to the /etc/sudoers file. This is because the contents of this directory are preserved during system updates. In addition, it is easier to fix any errors in the separate files than in the /etc/sudoers file. The system reads the files in the /etc/sudoers.d directory when it reaches the following line in the /etc/sudoers file:

#includedir /etc/sudoers.d

Note that the number sign # at the beginning of this line is part of the syntax and does not mean the line is a comment. The names of files in that directory must not contain a period . and must not end with a tilde ~.

System administrators can grant sudo access to allow non-root users to execute administrative commands. The sudo command provides users with administrative access without using the password of the root user.

When users need to perform an administrative command, they can precede that command with sudo. The command is then executed as if they were the root user.

Be aware of the following limitations:

You can configure a policy that allows unprivileged user to run certain command on a specific workstation. To configure this policy, you need to edit the sudoers.d file.

This section describes how to use the passwd command to change the root password as the root user.

This section describes how to use the passwd command to change or reset the forgotten root password as a non-root user.

If you are unable to log in as a non-root user or do not belong to the administrative wheel group, you can reset the root password on boot by switching into a specialized chroot jail environment.

Whenever a new file or directory is created, a base permission is automatically assigned to it. Base permissions for a file or directory can be expressed in symbolic or octal values.

The base permission for a directory is 777 (drwxrwxrwx), which grants everyone the permissions to read, write, and execute. This means that the directory owner, the group, and others can list the contents of the directory, create, delete, and edit items within the directory, and descend into it.

Note that individual files within a directory can have their own permission that might prevent you from editing them, despite having unrestricted access to the directory.

The base permission for a file is 666 (-rw-rw-rw-), which grants everyone the permissions to read and write. This means that the file owner, the group, and others can read and edit the file.

$ ls -l
-rwxrw----. 1 sysadmins sysadmins 2 Mar 2 08:43 file

$ ls -dl directory
drwxr-----. 1 sysadmins sysadmins 2 Mar 2 08:43 directory

The user file-creation mode mask (umask) is variable that controls how file permissions are set for newly created files and directories. The umask automatically removes permissions from the base permission value to increase the overall security of a linux system. The umask can be expressed in symbolic or octal values.

The default umask for a standard user is 0002. The default umask for a root user is 0022.

The first digit of the umask represents special permissions (sticky bit, ). The last three digits of the umask represent the permissions that are removed from the user owner (u), group owner (g), and others (o) respectively.

Example 26.3. Applying the umask when creating a file

The following example illustrates how the umask with an octal value of 0137 is applied to the file with the base permission of 777, to create the file with the default permission of 640.

The default permissions are set automatically for all newly created files and directories. The value of the default permissions is determined by applying the umask to the base permission.

This means that the directory owner and the group can list the contents of the directory, create, delete, and edit items within the directory, and descend into it. Other users can only list the contents of the directory and descend into it.

You can use the chmod utility with symbolic values (a combination letters and signs) to change file permissions for a file or directory.

You can assign the following permissions: