Mẹo Which Windows 10 feature provides an automated diagnosis and repair of boot problems plus a centralized platform for advanced recovery tool?

The systemctl cat command provides the content of the service file located under /usr/lib/systemd/system/, as well as all applicable overrides. The applicable overrides include unit file overrides from the /etc/systemd/system/ 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.

18.3. Additional resources

systemctl(1) man page systemd(1) man page systemd-delta(1) man page systemd.directives(7) man page systemd.unit(5) man page systemd.service(5) man page systemd.target(5) man page systemd.kill(5) man page systemd trang chủ Page

Chapter 19. Introduction to managing user and group accounts

The control of users and groups is a core element of Red Hat Enterprise Linux (RHEL) system administration. Each RHEL user has distinct login credentials and can be assigned to various groups to customize their system privileges.

19.1. Introduction to users and groups

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 thành viên 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.

19.2. Configuring reserved user and group IDs

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:

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

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

Procedure

To modify and make the IDs assigned to new users start 5000 by default:

Find the lines that define the minimum value for automatic UID selection.

Modify the UID_MIN value to start 5000.

Find the lines that define the minimum value for automatic GID selection.

Modify the GID_MIN value to start 5000.

The dynamically assigned UIDs and GIDs for the regular users now start 5000.

The UID’s and GID’s of users and groups created before you changed the UID_MIN and GID_MIN values do not change.

This will allow new user’s group to have same 5000+ ID as UID and GID.

Do not raise IDs reserved by the system above 1000 by changing SYS_UID_MAX to avoid conflict with systems that retain the 1000 limit.

19.3. User private groups

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 thành viên 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.

Chapter 20. Managing user accounts in the web console

The RHEL web console offers a graphical interface that enables you to execute a wide range of administrative tasks without accessing your terminal directly. For example, you can add, edit or remove system user accounts.

After reading this section, you will know:

From where the existing accounts come from. How to add new accounts. How to set password expiration. How and when to terminate user sessions.

Prerequisites

Set up the RHEL web console. For details, see Getting started using the RHEL web console. Log in to the RHEL web console with an account that has administrator permissions assigned. For details, see Logging in to the RHEL web console.

20.1. System user accounts managed in the web console

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

Authenticate users when accessing the system. Set the access rights to the system.

The RHEL web console displays all user accounts located in the system. Therefore, you can see 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:

Create new users accounts. Change their parameters. Lock accounts. Terminate user sessions.

20.2. Adding new accounts using the web console

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

Procedure

In the Full Name field, enter the full name of the user.

The RHEL web console automatically suggests a user name from the full name and fills it in the User Name field. If you do not want to use the original naming convention consisting of the first letter of the first name and the whole surname, update the suggestion.

In the Password/Confirm fields, enter the password and retype it for verification that your password is correct.

The color bar placed below the fields shows you security level of the entered password, which does not allow you to create a user with a weak password.

Select Server Administrator in the Roles item.

Now you can see the new account in the Accounts settings and you can use the credentials to connect to the system.

20.3. Enforcing password expiration in the 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.

Procedure

Verification steps

To verify that the password expiration is set, open the account settings.

The RHEL 8 web console displays a link with the date of expiration.

20.4. Terminating user sessions in the web console

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.

Procedure

Click Terminate Session.

If the Terminate Session button is inactive, the user is not logged in to the system.

The RHEL web console terminates the sessions.

Chapter 21. Managing users from the command line

You can manage users and groups using the command-line interface (CLI). This enables you to add, remove, and modify users and user groups in Red Hat Enterprise Linux environment.

21.1. Adding a new user from the command line

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

Prerequisites

Root access

Procedure

To add a new user, use:

# useradd options username

Replace options with the command-line options for the useradd command, and replace username with the name of the user.

Example 21.1. Adding a new user

To add the user sarah with user ID 5000, use:

+

# useradd -u 5000 sarah

Verification steps

To verify the new user is added, use the id utility.

# id sarah

The output returns:

uid=5000(sarah) gid=5000(sarah) groups=5000(sarah)

Additional resources

useradd man page

21.2. Adding a new group from the command line

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

Prerequisites

Root access

Procedure

To add a new group, use:

# groupadd options group-name

Replace options with the command-line options for the groupadd command, and replace group-name with the name of the group.

Example 21.2. Adding a new group

To add the group sysadmins with group ID 5000, use:

+

# groupadd -g 5000 sysadmins

Verification steps

To verify the new group is added, use the tail utility.

# tail /etc/group

The output returns:

sysadmins:x:5000:

Additional resources

groupadd man page

21.3. Adding a user to a supplementary group from the command line

You can add a user to a supplementary group to manage permissions or enable access to certain files or devices.

Prerequisites

root access

Procedure

To add a group to the supplementary groups of the user, use:

# usermod --append -G group-name username

Replace group-name with the name of the group, and replace username with the name of the user.

Example 21.3. Adding a user to a supplementary group

To add the user sysadmin to the group system-administrators, use:

# usermod --append -G system-administrators sysadmin

Verification steps

To verify the new groups is added to the supplementary groups of the user sysadmin, use:

# groups sysadmin

The output displays:

sysadmin : sysadmin system-administrators

21.4. Creating a group directory

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.

Prerequisites

Root access

Procedure

Create a directory:

Replace directory-name with the name of the directory.

Create a group:

Replace group-name with the name of the group.

Add users to the group:

Replace group-name with the name of the group, and replace username with the name of the user.

Associate the user and group ownership of the directory with the group-name group:

Replace group-name with the name of the group, and replace directory-name with the name of the directory.

Set the write permissions to allow the users to create and modify files and directories and set the setgid bit to make this permission be applied within the directory-name directory:

Replace directory-name with the name of the directory.

Now all members of the group-name group can create and edit files in the directory-name directory. Newly created files retain the group ownership of group-name group.

Verification steps

To verify the correctness of set permissions, use:

# ls -ld directory-name

Replace directory-name with the name of the directory.

The output returns:

drwxrwsr-x. 2 root group-name 6 Nov 25 08:45 directory-name

Chapter 22. Editing user groups using the command line

A user belongs to a certain set of groups that allow a logical collection of users with a similar access to files and folders. You can edit the primary and supplementary user groups from the command line to change the user’s permissions.

22.1. Primary and supplementary user groups

A group is an entity which ties together multiple user accounts for a common purpose, such as granting access to particular files.

On Linux, user groups can act as primary or supplementary. Primary and supplementary groups have the following properties:

Primary group

Every user has just one primary group all times. You can change the user’s primary group.

You can add an existing user to an existing supplementary group to manage users with the same security and access privileges within the group. Users can be members of zero or multiple supplementary groups.

22.2. Listing the primary and supplementary groups of a user

You can list the groups of users to see which primary and supplementary groups they belong to.

Procedure

Display the names of the primary and any supplementary group of a user:

$ groups user-name

Replace user-name with the name of the user. If you do not provide a user name, the command displays the group membership for the current user. The first group is the primary group followed by the optional supplementary groups.

Example 22.1. Listing of groups for user sarah:

$ groups sarah

The output displays:

sarah : sarah wheel developer

User sarah has a primary group sarah and is a thành viên of supplementary groups wheel and developer.

Example 22.2. Listing of groups for user marc:

$ groups marc

The output displays:

marc : marc

User marc has only a primary group marc and no supplementary groups.

22.3. Changing the primary group of a user

You can change the primary group of an existing user to a new group.

Prerequisites:

Procedure

Change the primary group of a user:

# usermod -g group-name user-name

Replace group-name with the name of the new primary group, and replace user-name with the name of the user.

When you change a user’s primary group, the command also automatically changes the group ownership of all files in the user’s home directory to the new primary group. You must fix the group ownership of files outside of the user’s home directory manually.

Example 22.3. Example of changing the primary group of a user:

If the user sarah belongs to the primary group sarah2, and you want to change the primary group of the user to sarah2, use:

# usermod -g sarah2 sarah

Verification steps

Verify that you changed the primary group of the user:

$ groups sarah

The output displays:

sarah : sarah2

22.4. Adding a user to a supplementary group from the command line

You can add a user to a supplementary group to manage permissions or enable access to certain files or devices.

Prerequisites

root access

Procedure

To add a group to the supplementary groups of the user, use:

# usermod --append -G group-name username

Replace group-name with the name of the group, and replace username with the name of the user.

Example 22.4. Adding a user to a supplementary group

To add the user sysadmin to the group system-administrators, use:

# usermod --append -G system-administrators sysadmin

Verification steps

To verify the new groups is added to the supplementary groups of the user sysadmin, use:

# groups sysadmin

The output displays:

sysadmin : sysadmin system-administrators

22.5. Removing a user from a supplementary group

You can remove an existing user from a supplementary group to limit their permissions or access to files and devices.

Prerequisites

root access

Procedure

Remove a user from a supplementary group:

# gpasswd -d user-name group-name

Replace user-name with the name of the user, and replace group-name with the name of the supplementary group.

Example 22.5. Removing user from a supplementary group

If the user sarah has a primary group sarah2, and belongs to the secondary groups wheel and developers, and you want to remove that user from the group developers, use:

# gpasswd -d sarah developers

Verification steps

Verify that you removed the user sarah from the secondary group developers:

$ groups sarah

The output displays:

sarah : sarah2 wheel

22.6. Changing all of the supplementary groups of a user

You can overwrite the list of supplementary groups that you want the user to remain a thành viên of.

Prerequisites

root access The supplementary groups must exist

Procedure

Overwrite a list of user’s supplementary groups:

# usermod -G group-names username

Replace group-names with the name of one or more supplementary groups. To add the user to several supplementary groups once, separate the group names using commas and no intervening spaces. For example: wheel,developer.

Replace user-name with the name of the user.

If the user is currently a thành viên of a group that you do not specify, the command removes the user from the group.

Example 22.6. Changing the list of supplementary groups of a user

If the user sarah has a primary group sarah2, and belongs to the supplementary group wheel, and you want the user to belong to three more supplementary groups developer, sysadmin, and security, use:

# usermod -G wheel,developer,sysadmin,security sarah

Verification steps

Verify that you set the list of the supplementary groups correct:

# groups sarah

The output displays:

sarah : sarah2 wheel developer sysadmin security

Chapter 23. Managing sudo access

System administrators can grant sudo access to allow non-root users to execute administrative commands that are normally reserved for the root user. As a result, non-root users can execute such commands without logging in to the root user account.

23.1. User authorizations in sudoers

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:

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

Where:

username is the name of the user or group, for example, user1 or %group1. hostname is the name of the host on which the rule applies. path/to/command is the complete absolute path to the command. You can also limit the user to only performing a command with specific options and arguments by adding those options after the command path. If you do not specify any options, the user can use the command with all options.

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

With overly permissive rules, such as ALL ALL=(ALL) ALL, all users are able to run all commands as all users on all hosts. This can lead to security risks.

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.

Avoid using negative rules for commands because users can overcome such rules by renaming commands using the alias command.

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:

Note that the number sign # 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 ~.

23.2. Granting sudo access to a user

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:

Only users listed in the /etc/sudoers configuration file can use the sudo command. The command is executed in the shell of the user, not in the root shell.

Prerequisites

root access

Procedure

As root, open the /etc/sudoers file.

The /etc/sudoers file defines the policies applied by the sudo command.

In the /etc/sudoers file, find the lines that grant sudo access to users in the administrative wheel group.

Add users you want to grant sudo access to into the administrative wheel group.

Replace username with the name of the user.

Verification steps

Verify that the user is added to the administrative wheel group:

# id username uid=5000(username) gid=5000(_username) groups=5000(username),10(wheel)

23.3. Enabling unprivileged users to run certain commands

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

Prerequisites

root access

Procedure

As root, create a new sudoers.d directory under /etc/:

Create a new file in the /etc/sudoers.d directory:

Replace file-name with the name of the file you want to create. The file will open automatically.

Add the following line to the newly created file:

Replace username with the name of the user. Replace hostname with the name of the host. Replace /path/to/the/command with the absolute path to the command (for example, /usr/bin/yum).

Save any changes, and exit the editor.

Example 23.1. Enabling an unprivileged user to install programs with yum

To enable the user sarah to install programs on the localhost.localdomain workstation using the yum utilities with sudo privileges, use:

As root, create a new sudoers.d directory under /etc/:

Create a new file in the /etc/sudoers.d directory:

The file will open automatically.

Add the following line to the /etc/sudoers.d/sarah file:

Ensure that the two command paths are separated by a , comma followed by a space.

Optional: To receive email notifications every time the user sarah attempts to use sudo privileges, add the following lines to the file:

To verify if the user sarah can run the yum command with sudo privileges, switch the account:

Enter the sudo yum command:

Enter the sudo password for the user sarah.

The system displays the list of yum commands and options:

If you receive the sarah is not in the sudoers file. This incident will be reported. message, the configuration was not completed correctly. Ensure that you are executing this procedure as root and that you followed the steps thoroughly.

23.4. Additional resources

The sudo(8) man page The visudo(8) man page

Chapter 24. Changing and resetting the root password

If the existing root password is no longer satisfactory or is forgotten, you can change or reset it both as the root user and a non-root user.

24.1. Changing the root password as the root user

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

Prerequisites

Root access

Procedure

To change the root password, use:

# passwd

You are prompted to enter your current password before you can change it.

24.2. Changing or resetting the forgotten root password as a non-root user

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

Prerequisites

You are able to log in as a non-root user. You are a thành viên of the administrative wheel group.

Procedure

To change or reset the root password as a non-root user that belongs to the wheel group, use:

$ sudo passwd root

You are prompted to enter your current non-root password before you can change the root password.

24.3. Resetting the root password on boot

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.

Procedure

Reboot the system and, on the GRUB 2 boot screen, press the e key to interrupt the boot process.

The kernel boot parameters appear.

Go to the end of the line that starts with linux.

Press Ctrl+e to jump to the end of the line.

Add rd.break to the end of the line that starts with linux.

Press Ctrl+x to start the system with the changed parameters.

The switch_root prompt appears.

Remount the file system as writable:

The file system is mounted as read-only in the /sysroot directory. Remounting the file system as writable allows you to change the password.

Enter the chroot environment:

The sh-4.4# prompt appears.

Reset the root password:

Follow the instructions displayed by the command line to finalize the change of the root password.

Enable the SELinux relabeling process on the next system boot:

Exit the chroot environment:

Exit the switch_root prompt:

Verification steps

Run the interactive shell as root:

Print the user name associated with the current effective user ID:

The output returns:

Chapter 25. Managing file permissions

File permissions control the ability of user and group accounts to view, modify, access, and execute the contents of the files and directories.

Every file or directory has three levels of ownership:

User owner (u). Group owner (g). Others (o).

Each level of ownership can be assigned the following permissions:

Read (r). Write (w). Execute (x).

Note that the execute permission for a file allows you to execute that file. The execute permission for a directory allows you to access the contents of the directory, but not execute it.

When a new file or directory is created, the default set of permissions are automatically assigned to it. The default permissions for a file or directory are based on two factors:

Base permission. The user file-creation mode mask (umask).

25.1. Base file permissions

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.

Permission

Symbolic value

Octal value

No permission

---

0

Execute

--x

1

Write

-w-

2

Write and execute

-wx

3

Read

r--

4

Read and execute

r-x

5

Read and write

rw-

6

Read, write, execute

rwx

7

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.

Example 25.1. Permissions for a file

If a file has the following permissions:

- indicates it is a file. rwx indicates that the file owner has permissions to read, write, and execute the file. rw- indicates that the group has permissions to read and write, but not execute the file. --- indicates that other users have no permission to read, write, or execute the file. . indicates that the SELinux security context is set for the file.

Example 25.2. Permissions for a directory

If a directory has the following permissions:

d indicates it is a directory.

rwx indicates that the directory owner has the permissions to read, write, and access the contents of the directory.

As a directory owner, you can list the items (files, subdirectories) within the directory, access the content of those items, and modify them.

r-- indicates that the group has permissions to read, but not write or access the contents of the directory.

As a thành viên of the group that owns the directory, you can list the items within the directory. You cannot access information about the items within the directory or modify them.

--- indicates that other users have no permission to read, write, or access the contents of the directory.

As someone who is not a user owner, or as group owner of the directory, you cannot list the items within the directory, access information about those items, or modify them.

. indicates that the SELinux security context is set for the directory.

The base permission that is automatically assigned to a file or directory is not the default permission the file or directory ends up with. When you create a file or directory, the base permission is altered by the umask. The combination of the base permission and the umask creates the default permission for files and directories.

25.2. User file-creation mode mask

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.

Permission

Symbolic value

Octal value

Read, write, and execute

rwx

0

Read and write

rw-

1

Read and execute

r-x

2

Read

r--

3

Write and execute

-wx

4

Write

-w-

5

Execute

--x

6

No permissions

---

7

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 25.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.

25.3. Default file permissions

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.

Example 25.4. Default permissions for a directory created by a standard user

When a standard user creates a new directory, the umask is set to 002 (rwxrwxr-x), and the base permissions for a directory are set to 777 (rwxrwxrwx). This brings the default permissions to 775 (drwxrwxr-x).

Symbolic value

Octal value

Base permission

rwxrwxrwx

777

Umask

rwxrwxr-x

002

Default permission

rwxrwxr-x

775

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.

Example 25.5. Default permissions for a file created by a standard user

When a standard user creates a new file, the umask is set to 002 (rwxrwxr-x), and the base permissions for a file are set to 666 (rw-rw-rw-). This brings the default permissions to 664 (-rw-rw-r--).

Symbolic value

Octal value

Base permission

rw-rw-rw-

666

Umask

rwxrwxr-x

002

Default permission

rw-rw-r--

664

This means that the file owner and the group can read and edit the file, while other users can only read the file.

Example 25.6. Default permissions for a directory created by the root user

When a root user creates a new directory, the umask is set to 022 (rwxr-xr-x), and the base permissions for a directory are set to 777 (rwxrwxrwx). This brings the default permissions to 755 (rwxr-xr-x).

Symbolic value

Octal value

Base permission

rwxrwxrwx

777

Umask

rwxr-xr-x

022

Default permission

rwxr-xr-x

755

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

Example 25.7. Default permissions for a file created by the root user

When a root user creates a new file, the umask is set to 022 (rwxr-xr-x), and the base permissions for a file are set to 666 (rw-rw-rw-). This brings the default permissions to 644 (-rw-r—​r--).

Symbolic value

Octal value

Base permission

rw-rw-rw-

666

Umask

rwxr-xr-x

022

Default permission

rw-r—​r--

644

This means that the file owner can read and edit the file, while the group and others can only read the file.

For security reasons, regular files cannot have execute permissions by default, even if the umask is set to 000 (rwxrwxrwx). However, directories can be created with execute permissions.

25.4. Changing file permissions using symbolic values

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:

Read (r) Write (w) Execute (x)

Permissions can be assigned to the following levels of ownership:

User owner (u) Group owner (g) Other (o) All (a)

To add or remove permissions you can use the following signs:

+ to add the permissions on top of the existing permissions - to remove the permissions from the existing permission = to remove the existing permissions and explicitly define the new ones

Procedure

To change the permissions for a file or directory, use:

$ chmod file-name

Replace with the level of ownership you want to set the permissions for. Replace with one of the signs. Replace with the permissions you want to assign. Replace file-name with the name of the file or directory. For example, to grant everyone the permissions to read, write, and execute (rwx) my-script.sh, use the chmod a=rwx my-script.sh command.

See Base file permissions for more details.

Verification steps

To see the permissions for a particular file, use:

$ ls -l file-name

Replace file-name with the name of the file.

To see the permissions for a particular directory, use:

$ ls -dl directory-name

Replace directory-name with the name of the directory.

To see the permissions for all the files within a particular directory, use:

$ ls -l directory-name

Replace directory-name with the name of the directory.

Example 25.8. Changing permissions for files and directories

To change file permissions for my-file.txt from -rw-rw-r-- to -rw------, use:

Display the current permissions for my-file.txt:

$ ls -l my-file.txt -rw-rw-r--. 1 username username 0 Feb 24 17:56 my-file.txt

Remove the permissions to read, write, and execute (rwx) the file from group owner (g) and others (o):

$ chmod go= my-file.txt

Note that any permission that is not specified after the equals sign (=) is automatically prohibited.

Verify that the permissions for my-file.txt were set correctly:

$ ls -l my-file.txt -rw-------. 1 username username 0 Feb 24 17:56 my-file.txt

To change file permissions for my-directory from drwxrwx--- to drwxrwxr-x, use:

Display the current permissions for my-directory:

$ ls -dl my-directory drwxrwx---. 2 username username 4096 Feb 24 18:12 my-directory

Add the read and execute (r-x) access for all users (a):

$ chmod o+rx my-directory

Verify that the permissions for my-directory and its content were set correctly:

$ ls -dl my-directory drwxrwxr-x. 2 username username 4096 Feb 24 18:12 my-directory

25.5. Changing file permissions using octal values

You can use the chmod utility with octal values (numbers) to change file permissions for a file or directory.

Procedure

To change the file permissions for an existing file or directory, use:

$ chmod octal_value file-name

Replace file-name with the name of the file or directory. Replace octal_value with an octal value. See Base file permissions for more details.

Chapter 26. Managing the umask

You can use the umask utility to display, set, or change the current or default value of the umask.

26.1. Displaying the current value of the umask

You can use the umask utility to display the current value of the umask in symbolic or octal mode.

Procedure

To display the current value of the umask in symbolic mode, use:

$ umask -S

To display the current value of the umask in the octal mode, use:

$ umask

When displaying the umask in octal mode, you may notice it displayed as a four digit number (0002 or 0022). The first digit of the umask represents a special bit (sticky bit, SGID bit, or SUID bit). If the first digit is set to 0, the special bit is not set.

26.2. Displaying the default bash umask

There are a number of shells you can use, such as bash, ksh, zsh and tcsh. Those shells can behave as login or non-login shells. You can invoke the login shell by opening a native or a GUI terminal.

To determine whether you are executing a command in a login or a non-login shell, use the echo $0 command.

Example 26.1. Determining if you are working in a login or a non-login bash shell

If the output of the echo $0 command returns bash, you are executing the command in a non-login shell.

$ echo $0 bash

The default umask for the non-login shell is set in the /etc/bashrc configuration file.

If the output of the echo $0 command returns -bash, you are executing the command in a login shell.

# echo $0 -bash

The default umask for the login shell is set in the /etc/profile configuration file.

Procedure

To display the default bash umask for the non-login shell, use:

$ grep umask /etc/bashrc

The output returns:

# By default, we want umask to get set. This sets it for non-login shell. umask 002 umask 022

To display the default bash umask for the login shell, use:

$ grep umask /etc/profile

The output returns:

# By default, we want umask to get set. This sets it for login shell umask 002 umask 022

26.3. Setting the umask using symbolic values

You can use the umask utility with symbolic values (a combination letters and signs) to set the umask for the current shell session

You can assign the following permissions:

Read (r) Write (w) Execute (x)

Permissions can be assigned to the following levels of ownership:

User owner (u) Group owner (g) Other (o) All (a)

To add or remove permissions you can use the following signs:

+ to add the permissions on top of the existing permissions - to remove the permissions from the existing permission

= to remove the existing permissions and explicitly define the new ones

Any permission that is not specified after the equals sign (=) is automatically prohibited.

Procedure

To set the umask for the current shell session, use:

$ umask -S

Replace with the level of ownership you want to set the umask for. Replace with one of the signs. Replace with the permissions you want to assign. For example, to set the umask to u=rwx,g=rwx,o=rwx, use umask -S a=rwx.

See User file-creation mode for more details.

The umask is only valid for the current shell session.

26.4. Setting the umask using octal values

You can use the umask utility with octal values (numbers) to set the umask for the current shell session.

Procedure

To set the umask for the current shell session, use:

$ umask octal_value

Replace octal_value with an octal value. See User file-creation mode mask for more details.

The umask is only valid for the current shell session.

26.5. Changing the default umask for the non-login shell

You can change the default bash umask for standard users by modifying the /etc/bashrc file.

Prerequisites

root access

Procedure

Modify the following sections to set a new default bash umask:

Replace the default octal value of the umask (002) with another octal value. See User file-creation mode mask for more details.

26.6. Changing the default umask for the login shell

You can change the default bash umask for the root user by modifying the /etc/profile file.

Prerequisites

root access

Procedure

Modify the following sections to set a new default bash umask:

Replace the default octal value of the umask (022) with another octal value. See User file-creation mode mask for more details.

26.7. Changing the default umask for a specific user

You can change the default umask for a specific user by modifying the .bashrc for that user.

Procedure

Append the line that specifies the octal value of the umask into the .bashrc file for the particular user.

$ echo 'umask octal_value' >> /home/username/.bashrc

Replace octal_value with an octal value and replace username with the name of the user. See User file-creation mode mask for more details.

26.8. Setting default permissions for newly created home directories

You can change the permission modes for home directories of newly created users by modifying the /etc/login.defs file.

Procedure

Modify the following section to set a new default HOME_MODE:

Replace the default octal value (0700) with another octal value. The selected mode will be used to create the permissions for the home directory.

If HOME_MODE is not set, modify the UMASK to set the mode for the newly created home directories:

Replace the default octal value (022) with another octal value. See User file-creation mode mask for more details.

Chapter 27. Using dnstap in RHEL

The dnstap utility provides an advanced way to monitor and log details of incoming name queries. It records sent messages from the named service. This section explains how to record DNS queries using dnstap.

27.1. Recording DNS queries using dnstap in RHEL

The network administrators can record the DNS queries to collect the website or IP address information along with the domain health.

Prerequisites

Upgrade BIND packages to version bind-9.11.26-2 or newer.

If you already have a BIND version installed and running, adding a new version of BIND will overwrite the existing version.

Procedure

Following are the steps to record DNS queries:

Edit the /etc/named.conf file in the options block to enable dnstap and target file:

( all | auth | client | forwarder | resolver | update ) [ ( query | response ) ];

The dnstap filter contains multiple definitions delimited by a ; in the dnstap block.

Following is the syntax for each rule:

auth - Authoritative zone response or answer. client - Internal client query or answer. forwarder - Forwarded query or response from it. resolver - Iterative resolution query or response. update - Dynamic zone update requests. all - Any from the above options.

query | response - If no query or response keyword is specified, both would be recorded.

The following example requests auth responses only, client queries and both queries and responses of dynamic updates:

Configure the periodic rollout for the active logs.

In the following example, the content of the user-edited script run once per day by cron. Number 3 signifies the backup log files limited to that number. Because the file gets removed, it never reaches the .2 suffix.

Use the dnstap-read utility to handle and analyze the logs in a human-readable format.

In the following example, the detailed dnstap output gets printed in the YAML file format.

Chapter 28. Managing the Access Control List

Each file and directory can only have one user owner and one group owner a time. If you want to grant a user permissions to access specific files or directories that belong to a different user or group while keeping other files and directories private, you can utilize Linux Access Control Lists (ACLs).

28.1. Displaying the current Access Control List

You can use the getfacl utility to display the current ACL.

Procedure

To display the current ACL for a particular file or directory, use:

$ getfacl file-name

Replace file-name with the name of the file or directory.

28.2. Setting the Access Control List

You can use the setfacl utility to set the ACL for a file or directory.

Prerequisites

root access.

Procedure

To set the ACL for a file or directory, use:

Replace username with the name of the user, symbolic_value with a symbolic value, and file-name with the name of the file or directory. For more information see the setfacl man page.

Example 28.1. Modifying permissions for a group project

The following example describes how to modify permissions for the group-project file owned by the root user that belongs to the root group so that this file is:

Not executable by anyone. The user andrew has the rw- permissions. The user susan has the --- permissions. Other users have the r-- permissions.

Procedure

Verification steps

To verify that the user andrew has the rw- permission, the user susan has the --- permission, and other users have the r-- permission, use:

$ getfacl group-project

The output returns:

# file: group-project # owner: root # group: root user:andrew:rw- user:susan:--- group::r-- mask::rw- other::r--

Chapter 29. Using the Chrony suite to configure NTP

Accurate timekeeping is important for a number of reasons in IT. In networking for example, accurate time stamps in packets and logs are required. In Linux systems, the NTP protocol 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. Usually, the Time Stamp Counter (TSC) is used. The TSC is a CPU register which counts the number of cycles since it was last reset. It is very fast, has a high resolution, and there are no interruptions.

Starting with Red Hat Enterprise Linux 8, the NTP protocol is implemented by the chronyd daemon, available from the repositories in the chrony package.

The following sections describe how to use the chrony suite to configure NTP.

29.1. Introduction to chrony suite

chrony is an implementation of the Network Time Protocol (NTP). You can use chrony:

To synchronize the system clock with NTP servers To synchronize the system clock with a reference clock, for example a GPS receiver To synchronize the system clock with a manual time input As an NTPv4(RFC 5905) server or peer to provide a time service to other computers in the network

chrony performs well in a wide range of conditions, including intermittent network connections, heavily congested networks, changing temperatures (ordinary computer clocks are sensitive to temperature), and systems that do not run continuously, or run on a virtual machine.

Typical accuracy between two machines synchronized over the Internet is within a few milliseconds, and for machines on a LAN within tens of microseconds. Hardware timestamping or a hardware reference clock may improve accuracy between two machines synchronized to a sub-microsecond level.

chrony consists of chronyd, a daemon that runs in user space, and chronyc, a command line program which can be used to monitor the performance of chronyd and to change various operating parameters when it is running.

The chrony daemon, chronyd, can be monitored and controlled by the command line utility chronyc. This utility provides a command prompt which allows entering a number of commands to query the current state of chronyd and make changes to its configuration. By default, chronyd accepts only commands from a local instance of chronyc, but it can be configured to accept monitoring commands also from remote hosts. The remote access should be restricted.

29.2. Using chronyc to control chronyd

This section describes how to control chronyd using the chronyc command line utility.

Procedure

To make changes to the local instance of chronyd using the command line utility chronyc in interactive mode, enter the following command as root:

chronyc must run as root if some of the restricted commands are to be used.

The chronyc command prompt will be displayed as follows:

Alternatively, the utility can also be invoked in non-interactive command mode if called together with a command as follows:

Changes made using chronyc are not permanent, they will be lost after a chronyd restart. For permanent changes, modify /etc/chrony.conf.

29.3. Migrating to chrony

In Red Hat Enterprise Linux 7, users could choose between ntp and chrony to ensure accurate timekeeping. For differences between ntp and chrony, ntpd and chronyd, see Differences between ntpd and chronyd.

Starting with Red Hat Enterprise Linux 8, ntp is no longer supported. chrony is enabled by default. For this reason, you might need to migrate from ntp to chrony.

Migrating from ntp to chrony is straightforward in most cases. The corresponding names of the programs, configuration files and services are:

Table 29.1. Corresponding names of the programs, configuration files and services when migrating from ntp to chrony

/etc/ntp.conf

/etc/chrony.conf

/etc/ntp/keys

/etc/chrony.keys

ntpd

chronyd

ntpq

chronyc

ntpd.service

chronyd.service

ntp-wait.service

chrony-wait.service

The ntpdate and sntp utilities, which are included in the ntp distribution, can be replaced with chronyd using the -q option or the -t option. The configuration can be specified on the command line to avoid reading /etc/chrony.conf. For example, instead of running ntpdate ntp.example.com, chronyd could be started as:

The ntpstat utility, which was previously included in the ntp package and supported only ntpd, now supports both ntpd and chronyd. It is available in the ntpstat package.

29.3.1. Migration script

A Python script called ntp2chrony.py is included in the documentation of the chrony package (/usr/share/doc/chrony). The script automatically converts an existing ntp configuration to chrony. It supports the most common directives and options in the ntp.conf file. Any lines that are ignored in the conversion are included as comments in the generated chrony.conf file for review. Keys that are specified in the ntp key file, but are not marked as trusted keys in ntp.conf are included in the generated chrony.keys file as comments.

By default, the script does not overwrite any files. If /etc/chrony.conf or /etc/chrony.keys already exist, the -b option can be used to rename the file as a backup. The script supports other options. The --help option prints all supported options.

An example of an invocation of the script with the default ntp.conf provided in the ntp package is:

The only directive ignored in this case is disable monitor, which has a chrony equivalent in the noclientlog directive, but it was included in the default ntp.conf only to mitigate an amplification attack.

The generated chrony.conf file typically includes a number of allow directives corresponding to the restrict lines in ntp.conf. If you do not want to run chronyd as an NTP server, remove all allow directives from chrony.conf.

Chapter 30. Using Chrony

The following sections describe how to install, start, and stop chronyd, and how to check if chrony is synchronized. Sections also describe how to manually adjust System Clock.

30.1. Managing chrony

The following procedure describes how to install, start, stop, and check the status of chronyd.

Procedure

The chrony suite is installed by default on Red Hat Enterprise Linux. To ensure that it is, run the following command as root:

The default location for the chrony daemon is /usr/sbin/chronyd. The command line utility will be installed to /usr/bin/chronyc.

To check the status of chronyd, issue the following command:

To start chronyd, issue the following command as root:

To ensure chronyd starts automatically system start, issue the following command as root:

To stop chronyd, issue the following command as root:

To prevent chronyd from starting automatically system start, issue the following command as root:

30.2. Checking if chrony is synchronized

The following procedure describes how to check if chrony is synchronized with the use of the tracking, sources, and sourcestats commands.

Procedure

To check chrony tracking, issue the following command:

The sources command displays information about the current time sources that chronyd is accessing. To check chrony sources, issue the following command:

The optional argument -v can be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.

The sourcestats command displays information about the drift rate and offset estimation process for each of the sources currently being examined by chronyd. To check chrony source statistics, issue the following command:

The optional argument -v can be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.

Additional resources

chronyc(1) man page

30.3. Manually adjusting the System Clock

The following procedure describes how to manually adjust the System Clock.

Procedure

To step the system clock immediately, bypassing any adjustments in progress by slewing, issue the following command as root:

If the rtcfile directive is used, the real-time clock should not be manually adjusted. Random adjustments would interfere with chrony's need to measure the rate which the real-time clock drifts.

30.4. Setting up chrony for a system in an isolated network

For a network that is never connected to the Internet, one computer is selected to be the master timeserver. The other computers are either direct clients of the master, or clients of clients. On the master, the drift file must be manually set with the average rate of drift of the system clock. If the master is rebooted, it will obtain the time from surrounding systems and calculate an average to set its system clock. Thereafter it resumes applying adjustments based on the drift file. The drift file will be updated automatically when the settime command is used.

The following procedure describes how to set up chrony for asystem in an isolated network.

Procedure

On the system selected to be the master, using a text editor running as root, edit /etc/chrony.conf as follows:

Where 192.0.2.0 is the network or subnet address from which the clients are allowed to connect.

On the systems selected to be direct clients of the master, using a text editor running as root, edit the /etc/chrony.conf as follows:

Where 192.0.2.123 is the address of the master, and master is the host name of the master. Clients with this configuration will resynchronize the master if it restarts.

On the client systems which are not to be direct clients of the master, the /etc/chrony.conf file should be the same except that the local and allow directives should be omitted.

In an isolated network, you can also use the local directive that enables a local reference mode, which allows chronyd operating as an NTP server to appear synchronized to real time, even when it was never synchronized or the last update of the clock happened a long time ago.

To allow multiple servers in the network to use the same local configuration and to be synchronized to one another, without confusing clients that poll more than one server, use the orphan option of the local directive which enables the orphan mode. Each server needs to be configured to poll all other servers with local. This ensures that only the server with the smallest reference ID has the local reference active and other servers are synchronized to it. When the server fails, another one will take over.

30.5. Configuring remote monitoring access

chronyc can access chronyd in two ways:

Internet Protocol, IPv4 or IPv6. Unix domain socket, which is accessible locally by the root or chrony user.

By default, chronyc connects to the Unix domain socket. The default path is /var/run/chrony/chronyd.sock. If this connection fails, which can happen for example when chronyc is running under a non-root user, chronyc tries to connect to 127.0.0.1 and then ::1.

Only the following monitoring commands, which do not affect the behavior of chronyd, are allowed from the network:

activity manual list rtcdata smoothing sources sourcestats tracking waitsync

The set of hosts from which chronyd accepts these commands can be configured with the cmdallow directive in the configuration file of chronyd, or the cmdallow command in chronyc. By default, the commands are accepted only from localhost (127.0.0.1 or ::1).

All other commands are allowed only through the Unix domain socket. When sent over the network, chronyd responds with a Not authorised error, even if it is from localhost.

The following procedure describes how to access chronyd remotely with chronyc.

Procedure

Allow access from both IPv4 and IPv6 addresses by adding the following to the /etc/chrony.conf file:

or

Allow commands from the remote IP address, network, or subnet by using the cmdallow directive.

Add the following content to the /etc/chrony.conf file:

Open port 323 in the firewall to connect from a remote system:

Optionally, you can open port 323 permanently using the --permanent option:

If you opened port 323 permanently, reload the firewall configuration:

Additional resources

chrony.conf(5) man page

30.6. Managing time synchronization using RHEL System Roles

You can manage time synchronization on multiple target machines using the timesync role. The timesync role installs and configures an NTP or PTP implementation to operate as an NTP client or PTP slave in order to synchronize the system clock with NTP servers or grandmasters in PTP domains.

Note that using the timesync role also facilitates migration to chrony, because you can use the same playbook on all versions of Red Hat Enterprise Linux starting with RHEL 6 regardless of whether the system uses ntp or chrony to implement the NTP protocol.

The timesync role replaces the configuration of the given or detected provider service on the managed host. Previous settings are lost, even if they are not specified in the role variables. The only preserved setting is the choice of provider if the timesync_ntp_provider variable is not defined.

The following example shows how to apply the timesync role in a situation with just one pool of servers.

Example 30.1. An example playbook applying the timesync role for a single pool of servers

--- - hosts: timesync-test vars: timesync_ntp_servers: - hostname: 2.rhel.pool.ntp.org pool: yes iburst: yes roles: - rhel-system-roles.timesync

For a detailed reference on timesync 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/timesync directory.

30.7. Additional resources

chronyc(1) man page chronyd(8) man page Frequently Asked Questions

Chapter 31. Chrony with HW timestamping

Hardware timestamping is a feature supported in some Network Interface Controller (NICs) which provides accurate timestamping of incoming and outgoing packets. NTP timestamps are usually created by the kernel and chronyd with the use of the system clock. However, when HW timestamping is enabled, the NIC uses its own clock to generate the timestamps when packets are entering or leaving the link layer or the physical layer. When used with NTP, hardware timestamping can significantly improve the accuracy of synchronization. For best accuracy, both NTP servers and NTP clients need to use hardware timestamping. Under ideal conditions, a sub-microsecond accuracy may be possible.

Another protocol for time synchronization that uses hardware timestamping is PTP.

Unlike NTP, PTP relies on assistance in network switches and routers. If you want to reach the best accuracy of synchronization, use PTP on networks that have switches and routers with PTP support, and prefer NTP on networks that do not have such switches and routers.

The following sections describe how to:

Verify support for hardware timestamping Enable hardware timestamping Configure client polling interval Enable interleaved mode Configure server for large number of clients Verify hardware timestamping Configure PTP-NTP bridge

31.1. Verifying support for hardware timestamping

To verify that hardware timestamping with NTP is supported by an interface, use the ethtool -T command. An interface can be used for hardware timestamping with NTP if ethtool lists the SOF_TIMESTAMPING_TX_HARDWARE and SOF_TIMESTAMPING_TX_SOFTWARE capabilities and also the HWTSTAMP_FILTER_ALL filter mode.

Example 31.1. Verifying support for hardware timestamping on a specific interface

# ethtool -T eth0

Output:

31.2. Enabling hardware timestamping

To enable hardware timestamping, use the hwtimestamp directive in the /etc/chrony.conf file. The directive can either specify a single interface, or a wildcard character can be used to enable hardware timestamping on all interfaces that support it. Use the wildcard specification in case that no other application, like ptp4l from the linuxptp package, is using hardware timestamping on an interface. Multiple hwtimestamp directives are allowed in the chrony configuration file.

Example 31.2. Enabling hardware timestamping by using the hwtimestamp directive

hwtimestamp eth0 hwtimestamp eth2 hwtimestamp *

31.3. Configuring client polling interval

The default range of a polling interval (64-1024 seconds) is recommended for servers on the Internet. For local servers and hardware timestamping, a shorter polling interval needs to be configured in order to minimize offset of the system clock.

The following directive in /etc/chrony.conf specifies a local NTP server using one second polling interval:

31.4. Enabling interleaved mode

NTP servers that are not hardware NTP appliances, but rather general purpose computers running a software NTP implementation, like chrony, will get a hardware transmit timestamp only after sending a packet. This behavior prevents the server from saving the timestamp in the packet to which it corresponds. In order to enable NTP clients receiving transmit timestamps that were generated after the transmission, configure the clients to use the NTP interleaved mode by adding the xleave option to the server directive in /etc/chrony.conf:

31.5. Configuring server for large number of clients

The default server configuration allows a few thousands of clients most to use the interleaved mode concurrently. To configure the server for a larger number of clients, increase the clientloglimit directive in /etc/chrony.conf. This directive specifies the maximum size of memory allocated for logging of clients' access on the server:

31.6. Verifying hardware timestamping

To verify that the interface has successfully enabled hardware timestamping, check the system log. The log should contain a message from chronyd for each interface with successfully enabled hardware timestamping.

Example 31.3. Log messages for interfaces with enabled hardware timestamping

chronyd[4081]: Enabled HW timestamping on eth0 chronyd[4081]: Enabled HW timestamping on eth2

When chronyd is configured as an NTP client or peer, you can have the transmit and receive timestamping modes and the interleaved mode reported for each NTP source by the chronyc ntpdata command:

Example 31.4. Reporting the transmit, receive timestamping and interleaved mode for each NTP source

# chronyc ntpdata

Output:

Example 31.5. Reporting the stability of NTP measurements

# chronyc sourcestats

With hardware timestamping enabled, stability of NTP measurements should be in tens or hundreds of nanoseconds, under normal load. This stability is reported in the Std Dev column of the output of the chronyc sourcestats command:

Output:

31.7. Configuring PTP-NTP bridge

If a highly accurate Precision Time Protocol (PTP) grandmaster is available in a network that does not have switches or routers with PTP support, a computer may be dedicated to operate as a PTP slave and a stratum-1 NTP server. Such a computer needs to have two or more network interfaces, and be close to the grandmaster or have a direct connection to it. This will ensure highly accurate synchronization in the network.

Configure the ptp4l and phc2sys programs from the linuxptp packages to use one interface to synchronize the system clock using PTP.

Configure chronyd to provide the system time using the other interface:

Example 31.6. Configuring chronyd to provide the system time using the other interface

bindaddress 203.0.113.74 hwtimestamp eth2 local stratum 1

Chapter 32. Achieving some settings previously supported by NTP in chrony

Some settings that were in previous major version of Red Hat Enterprise Linux supported by ntp, are not supported by chrony. The following sections list such settings, and describe ways to achieve them on a system with chrony.

32.1. Monitoring by ntpq and ntpdc

chronyd cannot be monitored by the ntpq and ntpdc utilities from the ntp distribution, because chrony does not support the NTP modes 6 and 7. It supports a different protocol and chronyc is the client implementation. For more information, see the chronyc(1) man page.

To monitor the status of the system clock sychronized by chronyd, you can:

Use the tracking command Use the ntpstat utility, which supports chrony and provides a similar output as it used to with ntpd

Example 32.1. Using the tracking command

$ chronyc -n tracking Reference ID : 0A051B0A (10.5.27.10) Stratum : 2 Ref time (UTC) : Thu Mar 08 15:46:20 2022 System time : 0.000000338 seconds slow of NTP time Last offset : +0.000339408 seconds RMS offset : 0.000339408 seconds Frequency : 2.968 ppm slow Residual freq : +0.001 ppm Skew : 3.336 ppm Root delay : 0.157559142 seconds Root dispersion : 0.001339232 seconds Update interval : 64.5 seconds Leap status : Normal

Example 32.2. Using the ntpstat utility

$ ntpstat synchronised to NTP server (10.5.27.10) stratum 2 time correct to within 80 ms polling server every 64 s

32.2. Using authentication mechanism based on public key cryptography

In Red Hat Enterprise Linux 7, ntp supported Autokey, which is an authentication mechanism based on public key cryptography.

In Red Hat Enterprise Linux 8, chronyd supports Network Time Security (NTS), a modern secure authentication mechanism, instead of Autokey. For more information, see Overview of Network Time Security (NTS) in chrony.

32.3. Using ephemeral symmetric associations

In Red Hat Enterprise Linux 7, ntpd supported ephemeral symmetric associations, which can be mobilized by packets from peers which are not specified in the ntp.conf configuration file. In Red Hat Enterprise Linux 8, chronyd needs all peers to be specified in chrony.conf. Ephemeral symmetric associations are not supported.

Note that using the client/server mode enabled by the server or pool directive is more secure compared to the symmetric mode enabled by the peer directive.

32.4. multicast/broadcast client

Red Hat Enterprise Linux 7 supported the broadcast/multicast NTP mode, which simplifies configuration of clients. With this mode, clients can be configured to just listen for packets sent to a multicast/broadcast address instead of listening for specific names or addresses of individual servers, which may change over time.

In Red Hat Enterprise Linux 8, chronyd does not support the broadcast/multicast mode. The main reason is that it is less accurate and less secure than the ordinary client/server and symmetric modes.

There are several options of migration from an NTP broadcast/multicast setup:

Configure DNS to translate a single name, such as ntp.example.com, to multiple addresses of different servers

Clients can have a static configuration using only a single pool directive to synchronize with multiple servers. If a server from the pool becomes unreacheable, or otherwise unsuitable for synchronization, the clients automatically replace it with another server from the pool.

Distribute the list of NTP servers over DHCP

When NetworkManager gets a list of NTP servers from the DHCP server, chronyd is automatically configured to use them. This feature can be disabled by adding PEERNTP=no to the /etc/sysconfig/network file.

Use the Precision Time Protocol (PTP)

This option is suitable mainly for environments where servers change frequently, or if a larger group of clients needs to be able to synchronize to each other without having a designated server.

PTP was designed for multicast messaging and works similarly to the NTP broadcast mode. A PTP implementation is available in the linuxptp package.

PTP normally requires hardware timestamping and support in network switches to perform well. However, PTP is expected to work better than NTP in the broadcast mode even with software timestamping and no support in network switches.

In networks with very large number of PTP slaves in one communication path, it is recommended to configure the PTP slaves with the hybrid_e2e option in order to reduce the amount of network traffic generated by the slaves. You can configure a computer running chronyd as an NTP client, and possibly NTP server, to operate also as a PTP grandmaster to distribute synchronized time to a large number of computers using multicast messaging.

Chapter 33. Overview of Network Time Security (NTS) in chrony

Network Time Security (NTS) is an authentication mechanism for Network Time Protocol (NTP), designed to scale substantial clients. It verifies that the packets received from the server machines are unaltered while moving to the client machine. Network Time Security (NTS) includes a Key Establishment (NTS-KE) protocol that automatically creates the encryption keys used between the server and its clients.

33.1. Enabling Network Time Security (NTS) in the client configuration file

By default, Network Time Security (NTS) is not enabled. You can enable NTS in the /etc/chrony.conf. For that, perform the following steps:

Prerequisites

Server with the NTS support

Procedure

In the client configuration file:

Specify the server with the nts option in addition to the recommended iburst option.

To avoid repeating the Network Time Security-Key Establishment (NTS-KE) session during system boot, add the following line to chrony.conf, if it is not present:

Add the following line to /etc/sysconfig/network to disable synchronization with Network Time Protocol (NTP) servers provided by DHCP:

Restart the chronyd service:

Verification

Verify if the NTS keys were successfully established:

# chronyc -N authdata Name/IP address Mode KeyID Type KLen Last Atmp NAK Cook CLen ================================================================ time.example.com NTS 1 15 256 33m 0 0 8 100 nts.sth2.ntp.se NTS 1 15 256 33m 0 0 8 100 nts.sth2.ntp.se NTS 1 15 256 33m 0 0 8 100

The KeyID, Type, and KLen should have non-zero values. If the value is zero, check the system log for error messages from chronyd.

Verify the client is making NTP measurements:

# chronyc -N sources MS Name/IP address Stratum Poll Reach LastRx Last sample ========================================================= time.example.com 3 6 377 45 +355us[ +375us] +/- 11ms nts.sth2.ntp.se 1 6 377 44 +237us[ +237us] +/- 23ms nts.sth2.ntp.se 1 6 377 44 -170us[ -170us] +/- 22ms

The Reach column should have a non-zero value; ideally 377. If the value rarely gets 377 or never gets to 377, it indicates that NTP requests or responses are getting lost in the network.

Additional resources

chrony.conf(5) man page

33.2. Enabling Network Time Security (NTS) on the server

If you run your own Network Time Protocol (NTP) server, you can enable the server Network Time Security (NTS) support to facilitate its clients to synchronize securely.

If the NTP server is a client of other servers, that is, it is not a Stratum 1 server, it should use NTS or symmetric key for its synchronization.

Prerequisites

Server private key in PEM format Server certificate with required intermediate certificates in PEM format

Procedure

Specify the private key and the certificate file in chrony.conf

Ensure that both the key and certificate files are readable by the chrony system user, by setting the group ownership.

Restart the chronyd service:

If the server has a firewall, it needs to allow both the UDP 123 and TCP 4460 ports for NTP and Network Time Security-Key Establishment (NTS-KE).

Verification

Perform a quick test from a client machine with the following command:

$ chronyd -Q. -t 3 'server foo.example iburst nts maxsamples 1' 2022-09-15T13:45:26Z chronyd version 4.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG) 2022-09-15T13:45:26Z Disabled control of system clock 2022-09-15T13:45:28Z System clock wrong by 0.002205 seconds (ignored) 2022-09-15T13:45:28Z chronyd exiting

The System clock wrong message indicates the NTP server is accepting NTS-KE connections and responding with NTS-protected NTP messages.

Verify the NTS-KE connections and authenticated NTP packets observed on the server:

# chronyc serverstats NTP packets received : 7 NTP packets dropped : 0 Command packets received : 22 Command packets dropped : 0 Client log records dropped : 0 NTS-KE connections accepted: 1 NTS-KE connections dropped : 0 Authenticated NTP packets: 7

If the value of the NTS-KE connections accepted and Authenticated NTP packets field is a non-zero value, it means that least one client was able to connect to the NTS-KE port and send an authenticated NTP request.

Chapter 34. Using secure communications between two systems with OpenSSH

SSH (Secure Shell) is a protocol which provides secure communications between two systems using a client-server architecture and allows users to log in to server host systems remotely. Unlike other remote communication protocols, such as FTP or Telnet, SSH encrypts the login session, which prevents intruders to collect unencrypted passwords from the connection.

Red Hat Enterprise Linux includes the basic OpenSSH packages: the general openssh package, the openssh-server package and the openssh-clients package. Note that the OpenSSH packages require the OpenSSL package openssl-libs, which installs several important cryptographic libraries that enable OpenSSH to provide encrypted communications.

34.1. SSH and OpenSSH

SSH (Secure Shell) is a program for logging into a remote machine and executing commands on that machine. The SSH protocol provides secure encrypted communications between two untrusted hosts over an insecure network. You can also forward X11 connections and arbitrary TCP/IP ports over the secure channel.

The SSH protocol mitigates security threats, such as interception of communication between two systems and impersonation of a particular host, when you use it for remote shell login or file copying. This is because the SSH client and server use digital signatures to verify their identities. Additionally, all communication between the client and server systems is encrypted.

A host key authenticates hosts in the SSH protocol. Host keys are cryptographic keys that are generated automatically when OpenSSH is first installed, or when the host boots for the first time.

OpenSSH is an implementation of the SSH protocol supported by Linux, UNIX, and similar operating systems. It includes the core files necessary for both the OpenSSH client and server. The OpenSSH suite consists of the following user-space tools:

ssh is a remote login program (SSH client). sshd is an OpenSSH SSH daemon. scp is a secure remote file copy program. sftp is a secure file transfer program. ssh-agent is an authentication agent for caching private keys. ssh-add adds private key identities to ssh-agent. ssh-keygen generates, manages, and converts authentication keys for ssh. ssh-copy-id is a script that adds local public keys to the authorized_keys file on a remote SSH server. ssh-keyscan gathers SSH public host keys.

Two versions of SSH currently exist: version 1, and the newer version 2. The OpenSSH suite in RHEL supports only SSH version 2. It has an enhanced key-exchange algorithm that is not vulnerable to exploits known in version 1.

OpenSSH, as one of core cryptographic subsystems of RHEL, uses system-wide crypto policies. This ensures that weak cipher suites and cryptographic algorithms are disabled in the default configuration. To modify the policy, the administrator must either use the update-crypto-policies command to adjust the settings or manually opt out of the system-wide crypto policies.

The OpenSSH suite uses two sets of configuration files: one for client programs (that is, ssh, scp, and sftp), and another for the server (the sshd daemon).

System-wide SSH configuration information is stored in the /etc/ssh/ directory. User-specific SSH configuration information is stored in ~/.ssh/ in the user’s home directory. For a detailed list of OpenSSH configuration files, see the FILES section in the sshd(8) man page.

34.2. Configuring and starting an OpenSSH server

Use the following procedure for a basic configuration that might be required for your environment and for starting an OpenSSH server. Note that after the default RHEL installation, the sshd daemon is already started and server host keys are automatically created.

Prerequisites

The openssh-server package is installed.

Procedure

Start the sshd daemon in the current session and set it to start automatically boot time:

To specify different addresses than the default 0.0.0.0 (IPv4) or :: (IPv6) for the ListenAddress directive in the /etc/ssh/sshd_config configuration file and to use a slower dynamic network configuration, add the dependency on the network-online.target target unit to the sshd.service unit file. To achieve this, create the /etc/systemd/system/sshd.service.d/local.conf file with the following content:

Optionally, change the welcome message that your OpenSSH server displays before a client authenticates by editing the /etc/issue file, for example:

Ensure that the Banner option is not commented out in /etc/ssh/sshd_config and its value contains /etc/issue:

Note that to change the message displayed after a successful login you have to edit the /etc/motd file on the server. See the pam_motd man page for more information.

Reload the systemd configuration and restart sshd to apply the changes:

Verification

Check that the sshd daemon is running:

Connect to the SSH server with an SSH client.

Additional resources

sshd(8) and sshd_config(5) man pages.

34.3. Setting an OpenSSH server for key-based authentication

To improve system security, enforce key-based authentication by disabling password authentication on your OpenSSH server.

Prerequisites

The openssh-server package is installed. The sshd daemon is running on the server.

Procedure

Open the /etc/ssh/sshd_config configuration in a text editor, for example:

Change the PasswordAuthentication option to no:

On a system other than a new default installation, check that PubkeyAuthentication no has not been set and the ChallengeResponseAuthentication directive is set to no. If you are connected remotely, not using console or out-of-band access, test the key-based login process before disabling password authentication.

To use key-based authentication with NFS-mounted home directories, enable the use_nfs_home_dirs SELinux boolean:

Reload the sshd daemon to apply the changes:

Additional resources

sshd(8), sshd_config(5), and setsebool(8) man pages.

34.4. Generating SSH key pairs

Use this procedure to generate an SSH key pair on a local system and to copy the generated public key to an OpenSSH server. If the server is configured accordingly, you can log in to the OpenSSH server without providing any password.

If you complete the following steps as root, only root is able to use the keys.

Procedure

To generate an ECDSA key pair for version 2 of the SSH protocol:

You can also generate an RSA key pair by using the -t rsa option with the ssh-keygen command or an Ed25519 key pair by entering the ssh-keygen -t ed25519 command.

To copy the public key to a remote machine:

If you do not use the ssh-agent program in your session, the previous command copies the most recently modified ~/.ssh/id*.pub public key if it is not yet installed. To specify another public-key file or to prioritize keys in files over keys cached in memory by ssh-agent, use the ssh-copy-id command with the -i option.

If you reinstall your system and want to keep previously generated key pairs, back up the ~/.ssh/ directory. After reinstalling, copy it back to your home directory. You can do this for all users on your system, including root.

Verification

Log in to the OpenSSH server without providing any password:

Additional resources

ssh-keygen(1) and ssh-copy-id(1) man pages.

34.5. Using SSH keys stored on a smart card

Red Hat Enterprise Linux enables you to use RSA and ECDSA keys stored on a smart card on OpenSSH clients. Use this procedure to enable authentication using a smart card instead of using a password.

Prerequisites

On the client side, the opensc package is installed and the pcscd service is running.

Procedure

List all keys provided by the OpenSC PKCS #11 module including their PKCS #11 URIs and save the output to the keys.pub file:

To enable authentication using a smart card on a remote server (example.com), transfer the public key to the remote server. Use the ssh-copy-id command with keys.pub created in the previous step:

To connect to example.com using the ECDSA key from the output of the ssh-keygen -D command in step 1, you can use just a subset of the URI, which uniquely references your key, for example:

You can use the same URI string in the ~/.ssh/config file to make the configuration permanent:

Because OpenSSH uses the p11-kit-proxy wrapper and the OpenSC PKCS #11 module is registered to PKCS#11 Kit, you can simplify the previous commands:

If you skip the id= part of a PKCS #11 URI, OpenSSH loads all keys that are available in the proxy module. This can reduce the amount of typing required:

34.6. Making OpenSSH more secure

The following tips help you to increase security when using OpenSSH. Note that changes in the /etc/ssh/sshd_config OpenSSH configuration file require reloading the sshd daemon to take effect:

The majority of security hardening configuration changes reduce compatibility with clients that do not support up-to-date algorithms or cipher suites.

Disabling insecure connection protocols

To make SSH truly effective, prevent the use of insecure connection protocols that are replaced by the OpenSSH suite. Otherwise, a user’s password might be protected using SSH for one session only to be captured later when logging in using Telnet. For this reason, consider disabling insecure protocols, such as telnet, rsh, rlogin, and ftp.

Enabling key-based authentication and disabling password-based authentication

Disabling passwords for authentication and allowing only key pairs reduces the attack surface and it also might save users’ time. On clients, generate key pairs using the ssh-keygen tool and use the ssh-copy-id utility to copy public keys from clients on the OpenSSH server. To disable password-based authentication on your OpenSSH server, edit /etc/ssh/sshd_config and change the PasswordAuthentication option to no:

PasswordAuthentication no

Key types

Although the ssh-keygen command generates a pair of RSA keys by default, you can instruct it to generate ECDSA or Ed25519 keys by using the -t option. The ECDSA (Elliptic Curve Digital Signature Algorithm) offers better performance than RSA the equivalent symmetric key strength. It also generates shorter keys. The Ed25519 public-key algorithm is an implementation of twisted Edwards curves that is more secure and also faster than RSA, DSA, and ECDSA.

OpenSSH creates RSA, ECDSA, and Ed25519 server host keys automatically if they are missing. To configure the host key creation in RHEL, use the [email protected] instantiated service. For example, to disable the automatic creation of the RSA key type:

# systemctl mask [email protected]rsa.service

To exclude particular key types for SSH connections, comment out the relevant lines in /etc/ssh/sshd_config, and reload the sshd service. For example, to allow only Ed25519 host keys:

# HostKey /etc/ssh/ssh_host_rsa_key # HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key

Non-default port

By default, the sshd daemon listens on TCP port 22. Changing the port reduces the exposure of the system to attacks based on automated network scanning and thus increase security through obscurity. You can specify the port using the Port directive in the /etc/ssh/sshd_config configuration file.

You also have to update the default SELinux policy to allow the use of a non-default port. To do so, use the semanage tool from the policycoreutils-python-utils package:

# semanage port -a -t ssh_port_t -p tcp port_number

Furthermore, update firewalld configuration:

# firewall-cmd --add-port port_number/tcp # firewall-cmd --runtime-to-permanent

In the previous commands, replace port_number with the new port number specified using the Port directive.

No root login

If your particular use case does not require the possibility of logging in as the root user, you should consider setting the PermitRootLogin configuration directive to no in the /etc/ssh/sshd_config file. By disabling the possibility of logging in as the root user, the administrator can audit which users run what privileged commands after they log in as regular users and then gain root rights.

Alternatively, set PermitRootLogin to prohibit-password:

PermitRootLogin prohibit-password

This enforces the use of key-based authentication instead of the use of passwords for logging in as root and reduces risks by preventing brute-force attacks.

Using the X Security extension

The X server in Red Hat Enterprise Linux clients does not provide the X Security extension. Therefore, clients cannot request another security layer when connecting to untrusted SSH servers with X11 forwarding. Most applications are not able to run with this extension enabled anyway.

By default, the ForwardX11Trusted option in the /etc/ssh/ssh_config.d/05-redhat.conf file is set to yes, and there is no difference between the ssh -X remote_machine (untrusted host) and ssh -Y remote_machine (trusted host) command.

If your scenario does not require the X11 forwarding feature all, set the X11Forwarding directive in the /etc/ssh/sshd_config configuration file to no.

Restricting access to specific users, groups, or domains

The AllowUsers and AllowGroups directives in the /etc/ssh/sshd_config configuration file server enable you to permit only certain users, domains, or groups to connect to your OpenSSH server. You can combine AllowUsers and AllowGroups to restrict access more precisely, for example:

AllowUsers *@192.168.1.*,*@10.0.0.*,!*@192.168.1.2 AllowGroups example-group

The previous configuration lines accept connections from all users from systems in 192.168.1.* and 10.0.0.* subnets except from the system with the 192.168.1.2 address. All users must be in the example-group group. The OpenSSH server denies all other connections.

Note that using allowlists (directives starting with Allow) is more secure than using blocklists (options starting with Deny) because allowlists block also new unauthorized users or groups.

Changing system-wide cryptographic policies

OpenSSH uses RHEL system-wide cryptographic policies, and the default system-wide cryptographic policy level offers secure settings for current threat models. To make your cryptographic settings more strict, change the current policy level:

# update-crypto-policies --set FUTURE Setting system policy to FUTURE To opt-out of the system-wide crypto policies for your OpenSSH server, uncomment the line with the CRYPTO_POLICY= variable in the /etc/sysconfig/sshd file. After this change, values that you specify in the Ciphers, MACs, KexAlgoritms, and GSSAPIKexAlgorithms sections in the /etc/ssh/sshd_config file are not overridden. Note that this task requires deep expertise in configuring cryptographic options. See Using system-wide cryptographic policies in the Security hardening title for more information.

Additional resources

sshd_config(5), ssh-keygen(1), crypto-policies(7), and update-crypto-policies(8) man pages.

34.7. Connecting to a remote server using an SSH jump host

Use this procedure for connecting your local system to a remote server through an intermediary server, also called jump host.

Prerequisites

A jump host accepts SSH connections from your local system. A remote server accepts SSH connections only from the jump host.

Procedure

Define the jump host by editing the ~/.ssh/config file on your local system, for example:

The Host parameter defines a name or alias for the host you can use in ssh commands. The value can match the real host name, but can also be any string. The HostName parameter sets the actual host name or IP address of the jump host.

Add the remote server jump configuration with the ProxyJump directive to ~/.ssh/config file on your local system, for example:

Use your local system to connect to the remote server through the jump server:

The previous command is equivalent to the ssh -J jump-server1 remote-server command if you omit the configuration steps 1 and 2.

You can specify more jump servers and you can also skip adding host definitions to the configurations file when you provide their complete host names, for example:

Change the host name-only notation in the previous command if the user names or SSH ports on the jump servers differ from the names and ports on the remote server, for example:

Additional resources

ssh_config(5) and ssh(1) man pages.

34.8. Connecting to remote machines with SSH keys using ssh-agent

To avoid entering a passphrase each time you initiate an SSH connection, you can use the ssh-agent utility to cache the private SSH key. The private key and the passphrase remain secure.

Prerequisites

You have a remote host with SSH daemon running and reachable through the network. You know the IP address or hostname and credentials to log in to the remote host. You have generated an SSH key pair with a passphrase and transferred the public key to the remote machine.

For more information, see Generating SSH key pairs.

Procedure

Optional: Verify you can use the key to authenticate to the remote host:

Connect to the remote host using SSH:

Enter the passphrase you set while creating the key to grant access to the private key.

Start the ssh-agent.

Add the key to ssh-agent.

Verification

Optional: Log in to the host machine using SSH.

$ ssh example.user1@198.51.100.1 Last login: Mon Sep 14 12:56:37 2022

Note that you did not have to enter the passphrase.

34.9. Additional resources

sshd(8), ssh(1), scp(1), sftp(1), ssh-keygen(1), ssh-copy-id(1), ssh_config(5), sshd_config(5), update-crypto-policies(8), and crypto-policies(7) man pages. OpenSSH trang chủ Page Configuring SELinux for applications and services with non-standard configurations Controlling network traffic using firewalld

Chapter 35. Configuring a remote logging solution

To ensure that logs from various machines in your environment are recorded centrally on a logging server, you can configure the Rsyslog application to record logs that fit specific criteria from the client system to the server.

35.1. The Rsyslog logging service

The Rsyslog application, in combination with the systemd-journald service, provides local and remote logging support in Red Hat Enterprise Linux. The rsyslogd daemon continuously reads syslog messages received by the systemd-journald service from the Journal. rsyslogd then filters and processes these syslog events and records them to rsyslog log files or forwards them to other services according to its configuration.

The rsyslogd daemon also provides extended filtering, encryption protected relaying of messages, input and output modules, and support for transportation using the TCP and UDP protocols.

In /etc/rsyslog.conf, which is the main configuration file for rsyslog, you can specify the rules according to which rsyslogd handles the messages. Generally, you can classify messages by their source and topic (facility) and urgency (priority), and then assign an action that should be performed when a message fits these criteria.

In /etc/rsyslog.conf, you can also see a list of log files maintained by rsyslogd. Most log files are located in the /var/log/ directory. Some applications, such as httpd and samba, store their log files in a subdirectory within /var/log/.

Additional resources

The rsyslogd(8) and rsyslog.conf(5) man pages. Documentation installed with the rsyslog-doc package in the /usr/share/doc/rsyslog/html/index.html file.

35.2. Installing Rsyslog documentation

The Rsyslog application has extensive online documentation that is available https://www.rsyslog.com/doc/, but you can also install the rsyslog-doc documentation package locally.

Prerequisites

You have activated the AppStream repository on your system. You are authorized to install new packages using sudo.

Procedure

Install the rsyslog-doc package:

# yum install rsyslog-doc

Verification

Open the /usr/share/doc/rsyslog/html/index.html file in a browser of your choice, for example:

$ firefox /usr/share/doc/rsyslog/html/index.html &

35.3. Configuring a server for remote logging over TCP

The Rsyslog application enables you to both run a logging server and configure individual systems to send their log files to the logging server. To use remote logging through TCP, configure both the server and the client. The server collects and analyzes the logs sent by one or more client systems.

With the Rsyslog application, you can maintain a centralized logging system where log messages are forwarded to a server over the network. To avoid message loss when the server is not available, you can configure an action queue for the forwarding action. This way, messages that failed to be sent are stored locally until the server is reachable again. Note that such queues cannot be configured for connections using the UDP protocol.

The omfwd plug-in provides forwarding over UDP or TCP. The default protocol is UDP. Because the plug-in is built in, it does not have to be loaded.

By default, rsyslog uses TCP on port 514.

Prerequisites

Rsyslog is installed on the server system. You are logged in as root on the server. The policycoreutils-python-utils package is installed for the optional step using the semanage command. The firewalld service is running.

Procedure

Optional: To use a different port for rsyslog traffic, add the syslogd_port_t SELinux type to port. For example, enable port 30514:

Optional: To use a different port for rsyslog traffic, configure firewalld to allow incoming rsyslog traffic on that port. For example, allow TCP traffic on port 30514:

Create a new file in the /etc/rsyslog.d/ directory named, for example, remotelog.conf, and insert the following content:

Test the syntax of the /etc/rsyslog.conf file:

Make sure the rsyslog service is running and enabled on the logging server:

Restart the rsyslog service.

Optional: If rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

Your log server is now configured to receive and store log files from the other systems in your environment.

Additional resources

rsyslogd(8), rsyslog.conf(5), semanage(8), and firewall-cmd(1) man pages. Documentation installed with the rsyslog-doc package in the /usr/share/doc/rsyslog/html/index.html file.

35.4. Configuring remote logging to a server over TCP

Follow this procedure to configure a system for forwarding log messages to a server over the TCP protocol. The omfwd plug-in provides forwarding over UDP or TCP. The default protocol is UDP. Because the plug-in is built in, you do not have to load it.

Prerequisites

The rsyslog package is installed on the client systems that should report to the server. You have configured the server for remote logging. The specified port is permitted in SELinux and open in firewall. The system contains the policycoreutils-python-utils package, which provides the semanage command for adding a non-standard port to the SELinux configuration.

Procedure

Create a new file in the /etc/rsyslog.d/ directory named, for example, 10-remotelog.conf, and insert the following content:

Where:

queue.type="linkedlist" enables a LinkedList in-memory queue, queue.filename defines a disk storage. The backup files are created with the example_fwd prefix in the working directory specified by the preceding global workDirectory directive, the action.resumeRetryCount -1 setting prevents rsyslog from dropping messages when retrying to connect if server is not responding, enabled queue.saveOnShutdown="on" saves in-memory data if rsyslog shuts down,

the last line forwards all received messages to the logging server, port specification is optional.

With this configuration, rsyslog sends messages to the server but keeps messages in memory if the remote server is not reachable. A file on disk is created only if rsyslog runs out of the configured memory queue space or needs to shut down, which benefits the system performance.

Rsyslog processes configuration files /etc/rsyslog.d/ in the lexical order.

Restart the rsyslog service.

Verification

To verify that the client system sends messages to the server, follow these steps:

On the client system, send a test message:

On the server system, view the /var/log/messages log, for example:

Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Additional resources

rsyslogd(8) and rsyslog.conf(5) man pages. Documentation installed with the rsyslog-doc package in the /usr/share/doc/rsyslog/html/index.html file.

35.5. Configuring TLS-encrypted remote logging

By default, Rsyslog sends remote-logging communication in the plain text format. If your scenario requires to secure this communication channel, you can encrypt it using TLS.

To use encrypted transport through TLS, configure both the server and the client. The server collects and analyzes the logs sent by one or more client systems.

You can use either the ossl network stream driver (OpenSSL) or the gtls stream driver (GnuTLS).

If you have a separate system with higher security, for example, a system that is not connected to any network or has stricter authorizations, use the separate system as the certifying authority (CA).

Prerequisites

You have root access to both the client and server systems. The rsyslog and rsyslog-openssl packages are installed on the server and the client systems. If you use the gtls network stream driver, install the rsyslog-gnutls package instead of rsyslog-openssl. If you generate certificates using the certtool command, install the gnutls-utils package.

On your logging server, the following certificates are in the /etc/pki/ca-trust/source/anchors/ directory and your system configuration is updated by using the update-ca-trust command:

ca-cert.pem - a CA certificate that can verify keys and certificates on logging servers and clients. server-cert.pem - a public key of the logging server. server-key.pem - a private key of the logging server.

On your logging clients, the following certificates are in the /etc/pki/ca-trust/source/anchors/ directory and your system configuration is updated by using update-ca-trust:

ca-cert.pem - a CA certificate that can verify keys and certificates on logging servers and clients. client-cert.pem - a public key of a client. client-key.pem - a private key of a client.

Procedure

Configure the server for receiving encrypted logs from your client systems:

To encrypt the communication, the configuration file must contain paths to certificate files on your server, a selected authentication method, and a stream driver that supports TLS encryption. Add the following lines to the /etc/rsyslog.d/securelogser.conf file:

If you prefer the GnuTLS driver, use the StreamDriver.Name="gtls" configuration option. See the documentation installed with the rsyslog-doc package for more information about less strict authentication modes than x509/name.

Verify the syntax of the /etc/rsyslog.conf file and any files in the /etc/rsyslog.d/ directory:

Make sure the rsyslog service is running and enabled on the logging server:

Restart the rsyslog service:

Optional: If Rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

Configure clients for sending encrypted logs to the server:

Add the following lines to the /etc/rsyslog.d/securelogcli.conf file:

If you prefer the GnuTLS driver, use the StreamDriver.Name="gtls" configuration option.

Verify the syntax of the `/etc/rsyslog.conf file and other files in the /etc/rsyslog.d/ directory:

Make sure the rsyslog service is running and enabled on the logging server:

Restart the rsyslog service:

Optional: If Rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

Verification

To verify that the client system sends messages to the server, follow these steps:

On the client system, send a test message:

On the server system, view the /var/log/messages log, for example:

Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Additional resources

The certtool(1), openssl(1), update-ca-trust(8), rsyslogd(8), and rsyslog.conf(5) man pages. Documentation installed with the rsyslog-doc package /usr/share/doc/rsyslog/html/index.html. The Using the Logging System Role article.

35.6. Configuring a server for receiving remote logging information over UDP

The Rsyslog application enables you to configure a system to receive logging information from remote systems. To use remote logging through UDP, configure both the server and the client. The receiving server collects and analyzes the logs sent by one or more client systems. By default, rsyslog uses UDP on port 514 to receive log information from remote systems.

Follow this procedure to configure a server for collecting and analyzing logs sent by one or more client systems over the UDP protocol.

Prerequisites

Rsyslog is installed on the server system. You are logged in as root on the server. The policycoreutils-python-utils package is installed for the optional step using the semanage command. The firewalld service is running.

Procedure

Optional: To use a different port for rsyslog traffic than the default port 514:

Add the syslogd_port_t SELinux type to the SELinux policy configuration, replacing portno with the port number you want rsyslog to use:

Configure firewalld to allow incoming rsyslog traffic, replacing portno with the port number and zone with the zone you want rsyslog to use:

Reload the firewall rules:

Create a new .conf file in the /etc/rsyslog.d/ directory, for example, remotelogserv.conf, and insert the following content:

Where 514 is the port number rsyslog uses by default. You can specify a different port instead.

Verify the syntax of the /etc/rsyslog.conf file and all .conf files in the /etc/rsyslog.d/ directory:

Restart the rsyslog service.

Optional: If rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

Additional resources

rsyslogd(8) , rsyslog.conf(5), semanage(8), and firewall-cmd(1) man pages. Documentation installed with the rsyslog-doc package in the /usr/share/doc/rsyslog/html/index.html file.

35.7. Configuring remote logging to a server over UDP

Follow this procedure to configure a system for forwarding log messages to a server over the UDP protocol. The omfwd plug-in provides forwarding over UDP or TCP. The default protocol is UDP. Because the plug-in is built in, you do not have to load it.

Prerequisites

The rsyslog package is installed on the client systems that should report to the server. You have configured the server for remote logging as described in Configuring a server for receiving remote logging information over UDP.

Procedure

Create a new .conf file in the /etc/rsyslog.d/ directory, for example, 10-remotelogcli.conf, and insert the following content:

Where:

queue.type="linkedlist" enables a LinkedList in-memory queue. queue.filename defines a disk storage. The backup files are created with the example_fwd prefix in the working directory specified by the preceding global workDirectory directive. The action.resumeRetryCount -1 setting prevents rsyslog from dropping messages when retrying to connect if the server is not responding. enabled queue.saveOnShutdown="on" saves in-memory data if rsyslog shuts down. portno is the port number you want rsyslog to use. The default value is 514.

The last line forwards all received messages to the logging server, port specification is optional.

With this configuration, rsyslog sends messages to the server but keeps messages in memory if the remote server is not reachable. A file on disk is created only if rsyslog runs out of the configured memory queue space or needs to shut down, which benefits the system performance.

Rsyslog processes configuration files /etc/rsyslog.d/ in the lexical order.

Restart the rsyslog service.

Optional: If rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

Verification

To verify that the client system sends messages to the server, follow these steps:

On the client system, send a test message:

On the server system, view the /var/log/remote/msg/hostname/root.log log, for example:

Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Additional resources

rsyslogd(8) and rsyslog.conf(5) man pages. Documentation installed with the rsyslog-doc package /usr/share/doc/rsyslog/html/index.html.

35.8. Load balancing helper in Rsyslog

The RebindInterval setting specifies an interval which the current connection is broken and is re-established. This setting applies to TCP, UDP, and RELP traffic. The load balancers perceive it as a new connection and forward the messages to another physical target system.

The RebindInterval setting proves to be helpful in scenarios when a target system has changed its IP address. The Rsyslog application caches the IP address when the connection establishes, therefore, the messages are sent to the same server. If the IP address changes, the UDP packets will be lost until the Rsyslog service restarts. Re-establishing the connection will ensure the IP to be resolved by DNS again.

35.9. Configuring reliable remote logging

With the Reliable Event Logging Protocol (RELP), you can send and receive syslog messages over TCP with a much reduced risk of message loss. RELP provides reliable delivery of sự kiện messages, which makes it useful in environments where message loss is not acceptable. To use RELP, configure the imrelp input module, which runs on the server and receives the logs, and the omrelp output module, which runs on the client and sends logs to the logging server.

Prerequisites

You have installed the rsyslog, librelp, and rsyslog-relp packages on the server and the client systems. The specified port is permitted in SELinux and open in the firewall.

Procedure

Configure the client system for reliable remote logging:

On the client system, create a new .conf file in the /etc/rsyslog.d/ directory named, for example, relpclient.conf, and insert the following content:

Where:

target_IP is the IP address of the logging server. target_port is the port of the logging server.

Restart the rsyslog service.

Optional: If rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

Configure the server system for reliable remote logging:

On the server system, create a new .conf file in the /etc/rsyslog.d/ directory named, for example, relpserv.conf, and insert the following content:

Where:

log_path specifies the path for storing messages. target_port is the port of the logging server. Use the same value as in the client configuration file.

Restart the rsyslog service.

Optional: If rsyslog is not enabled, ensure the rsyslog service starts automatically after reboot:

Verification

To verify that the client system sends messages to the server, follow these steps:

On the client system, send a test message:

On the server system, view the log the specified log_path, for example:

Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Additional resources

rsyslogd(8) and rsyslog.conf(5) man pages. Documentation installed with the rsyslog-doc package in the /usr/share/doc/rsyslog/html/index.html file.

35.10. Supported Rsyslog modules

To expand the functionality of the Rsyslog application, you can use specific modules. Modules provide additional inputs (Input Modules), outputs (Output Modules), and other functionalities. A module can also provide additional configuration directives that become available after you load the module.

You can list the input and output modules installed on your system by entering the following command:

You can view the list of all available rsyslog modules in the /usr/share/doc/rsyslog/html/configuration/modules/idx_output.html file after you install the rsyslog-doc package.

35.11. Additional resources

Documentation installed with the rsyslog-doc package file:///usr/share/doc/rsyslog/html/index.html. The rsyslog.conf(5) and rsyslogd(8) man pages. The Configuring system logging without journald or with minimized journald usage Knowledgebase article. The Negative effects of the RHEL default logging setup on performance and their mitigations article. The Using the Logging System Role article.

Chapter 36. Using the Logging System Role

As a system administrator, you can use the Logging System Role to configure a RHEL host as a logging server to collect logs from many client systems.

36.1. The Logging System Role

With the Logging System Role, you can deploy logging configurations on local and remote hosts.

To apply a Logging System Role on one or more systems, you define the logging configuration in a playbook. A playbook is a list of one or more plays. Playbooks are human-readable, and they are written in the YAML format. For more information about playbooks, see Working with playbooks in Ansible documentation.

The set of systems that you want to configure according to the playbook is defined in an inventory file. For more information on creating and using inventories, see How to build your inventory in Ansible documentation.

Logging solutions provide multiple ways of reading logs and multiple logging outputs.

For example, a logging system can receive the following inputs:

local files, systemd/journal, another logging system over the network.

In addition, a logging system can have the following outputs:

logs stored in the local files in the /var/log directory, logs sent to Elasticsearch, logs forwarded to another logging system.

With the Logging System Role, you can combine the inputs and outputs to fit your scenario. For example, you can configure a logging solution that stores inputs from journal in a local file, whereas inputs read from files are both forwarded to another logging system and stored in the local log files.

36.2. Logging System Role parameters

In a Logging System Role playbook, you define the inputs in the logging_inputs parameter, outputs in the logging_outputs parameter, and the relationships between the inputs and outputs in the logging_flows parameter. The Logging System Role processes these variables with additional options to configure the logging system. You can also enable encryption.

Currently, the only available logging system in the Logging System Role is Rsyslog.

logging_inputs: List of inputs for the logging solution.

name: Unique name of the input. Used in the logging_flows: inputs list and a part of the generated config file name.

type: Type of the input element. The type specifies a task type which corresponds to a directory name in roles/rsyslog/tasks,vars/inputs/.

basics: Inputs configuring inputs from systemd journal or unix socket.

kernel_message: Load imklog if set to true. Default to false. use_imuxsock: Use imuxsock instead of imjournal. Default to false. ratelimit_burst: Maximum number of messages that can be emitted within ratelimit_interval. Default to 20000 if use_imuxsock is false. Default to 200 if use_imuxsock is true. ratelimit_interval: Interval to evaluate ratelimit_burst. Default to 600 seconds if use_imuxsock is false. Default to 0 if use_imuxsock is true. 0 indicates rate limiting is turned off. persist_state_interval: Journal state is persisted every value messages. Default to 10. Effective only when use_imuxsock is false.
files: Inputs configuring inputs from local files. remote: Inputs configuring inputs from the other logging system over network.
state: State of the configuration file. present or absent. Default to present.

logging_outputs: List of outputs for the logging solution.

files: Outputs configuring outputs to local files. forwards: Outputs configuring outputs to another logging system. remote_files: Outputs configuring outputs from another logging system to local files.

logging_flows: List of flows that define relationships between logging_inputs and logging_outputs. The logging_flows variable has the following keys:

name: Unique name of the flow inputs: List of logging_inputs name values outputs: List of logging_outputs name values.

Additional resources

Documentation installed with the rhel-system-roles package in /usr/share/ansible/roles/rhel-system-roles.logging/README.html

36.3. Applying a local Logging System Role

Follow these steps to prepare and apply an Ansible playbook to configure a logging solution on a set of separate machines. Each machine will record logs locally.

Prerequisites

Access and permissions to one or more managed nodes, which are systems you want to configure with the Logging System Role.

Access and permissions to a control node, which is a system from which Red Hat Ansible Core configures other systems.

On the control node:

The ansible-core and rhel-system-roles packages are installed.

RHEL 8.0-8.5 provided access to a separate Ansible repository that contains Ansible Engine 2.9 for automation based on Ansible. Ansible Engine contains command-line utilities such as ansible, ansible-playbook, connectors such as docker and podman, and many plugins and modules. For information on how to obtain and install Ansible Engine, see the How to tải về and install Red Hat Ansible Engine Knowledgebase article.

RHEL 8.6 and 9.0 have introduced Ansible Core (provided as the ansible-core package), which contains the Ansible command-line utilities, commands, and a small set of built-in Ansible plugins. RHEL provides this package through the AppStream repository, and it has a limited scope of support. For more information, see the Scope of support for the Ansible Core package included in the RHEL 9 and RHEL 8.6 and later AppStream repositories Knowledgebase article.

An inventory file which lists the managed nodes.

You do not have to have the rsyslog package installed, because the system role installs rsyslog when deployed.

Procedure

Create a playbook that defines the required role:

Create a new YAML file and open it in a text editor, for example:

Insert the following content:

Run the playbook on a specific inventory:

Where:

inventory-file is the inventory file. logging-playbook.yml is the playbook you use.

Verification

Test the syntax of the /etc/rsyslog.conf file:

Verify that the system sends messages to the log:

Send a test message:

View the /var/log/messages log, for example:

Where `hostname` is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

36.4. Filtering logs in a local Logging System Role

You can deploy a logging solution which filters the logs based on the rsyslog property-based filter.

Prerequisites

Access and permissions to one or more managed nodes, which are systems you want to configure with the Logging System Role.

Access and permissions to a control node, which is a system from which Red Hat Ansible Core configures other systems.

On the control node:

Red Hat Ansible Core is installed The rhel-system-roles package is installed An inventory file which lists the managed nodes.

You do not have to have the rsyslog package installed, because the System Role installs rsyslog when deployed.

Procedure

Create a new playbook.yml file with the following content:

Using this configuration, all messages that contain the error string are logged in /var/log/errors.log, and all other messages are logged in /var/log/others.log.

You can replace the error property value with the string by which you want to filter.

You can modify the variables according to your preferences.

Optional: Verify playbook syntax.

Run the playbook on your inventory file:

Verification

Test the syntax of the /etc/rsyslog.conf file:

Verify that the system sends messages that contain the error string to the log:

Send a test message:

View the /var/log/errors.log log, for example:

Where hostname is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Additional resources

Documentation installed with the rhel-system-roles package in /usr/share/ansible/roles/rhel-system-roles.logging/README.html

36.5. Applying a remote logging solution using the Logging System Role

Follow these steps to prepare and apply a Red Hat Ansible Core playbook to configure a remote logging solution. In this playbook, one or more clients take logs from systemd-journal and forward them to a remote server. The server receives remote input from remote_rsyslog and remote_files and outputs the logs to local files in directories named by remote host names.

Prerequisites

Access and permissions to one or more managed nodes, which are systems you want to configure with the Logging System Role.

Access and permissions to a control node, which is a system from which Red Hat Ansible Core configures other systems.

On the control node:

The ansible-core and rhel-system-roles packages are installed. An inventory file which lists the managed nodes.

You do not have to have the rsyslog package installed, because the System Role installs rsyslog when deployed.

Procedure

Create a playbook that defines the required role:

Create a new YAML file and open it in a text editor, for example:

Insert the following content into the file:

Where host1.example.com is the logging server.

You can modify the parameters in the playbook to fit your needs.

The logging solution works only with the ports defined in the SELinux policy of the server or client system and open in the firewall. The default SELinux policy includes ports 601, 514, 6514, 10514, and 20514. To use a different port, modify the SELinux policy on the client and server systems. Configuring the firewall through System Roles is not yet supported.

Create an inventory file that lists your servers and clients:

Create a new file and open it in a text editor, for example:

Insert the following content into the inventory file:

Where:

host1.example.com is the logging server. host2.example.com is the logging client.

Run the playbook on your inventory.

Where:

inventory.ini is the inventory file. logging-playbook.yml is the playbook you created.

Verification

On both the client and the server system, test the syntax of the /etc/rsyslog.conf file:

Verify that the client system sends messages to the server:

On the client system, send a test message:

On the server system, view the /var/log/messages log, for example:

Where host2.example.com is the host name of the client system. Note that the log contains the user name of the user that entered the logger command, in this case root.

Additional resources

Getting started with RHEL System Roles Documentation installed with the rhel-system-roles package in /usr/share/ansible/roles/rhel-system-roles.logging/README.html RHEL System Roles KB article

36.6. Using the Logging System Role with TLS

Transport Layer Security (TLS) is a cryptographic protocol designed to securely communicate over the computer network.

As an administrator, you can use the Logging RHEL System Role to configure secure transfer of logs using Red Hat Ansible Automation Platform.

36.6.1. Configuring client logging with TLS

You can use the Logging System Role to configure logging in RHEL systems that are logged on a local machine and can transfer logs to the remote logging system with TLS by running an Ansible playbook.

This procedure configures TLS on all hosts in the clients group in the Ansible inventory. The TLS protocol encrypts the message transmission for secure transfer of logs over the network.

Prerequisites

You have permissions to run playbooks on managed nodes on which you want to configure TLS. The managed nodes are listed in the inventory file on the control node. The ansible and rhel-system-roles packages are installed on the control node.

Procedure

Create a playbook.yml file with the following content:

The playbook uses the following parameters:

logging_pki_files Using this parameter you can configure TLS and has to pass ca_cert_src, cert_src, and private_key_src parameters. ca_cert Represents the path to CA certificate. Default path is /etc/pki/tls/certs/ca.pem and the file name is set by the user. cert Represents the path to cert. Default path is /etc/pki/tls/certs/server-cert.pem and the file name is set by the user. private_key Represents the path to private key. Default path is /etc/pki/tls/private/server-key.pem and the file name is set by the user. ca_cert_src Represents local CA cert file path which is copied to the target host. If ca_cert is specified, it is copied to the location. cert_src Represents the local cert file path which is copied to the target host. If cert is specified, it is copied to the location. private_key_src Represents the local key file path which is copied to the target host. If private_key is specified, it is copied to the location. tls Using this parameter ensures secure transfer of logs over the network. If you do not want a secure wrapper, you can set tls: true.

Verify playbook syntax:

Run the playbook on your inventory file:

36.6.2. Configuring server logging with TLS

You can use the Logging System Role to configure logging in RHEL systems as a server and can receive logs from the remote logging system with TLS by running an Ansible playbook.

This procedure configures TLS on all hosts in the server group in the Ansible inventory.

Prerequisites

You have permissions to run playbooks on managed nodes on which you want to configure TLS. The managed nodes are listed in the inventory file on the control node. The ansible and rhel-system-roles packages are installed on the control node.

Procedure

Create a playbook.yml file with the following content:

The playbook uses the following parameters:

logging_pki_files Using this parameter you can configure TLS and has to pass ca_cert_src, cert_src, and private_key_src parameters. ca_cert Represents the path to CA certificate. Default path is /etc/pki/tls/certs/ca.pem and the file name is set by the user. cert Represents the path to cert. Default path is /etc/pki/tls/certs/server-cert.pem and the file name is set by the user. private_key Represents the path to private key. Default path is /etc/pki/tls/private/server-key.pem and the file name is set by the user. ca_cert_src Represents local CA cert file path which is copied to the target host. If ca_cert is specified, it is copied to the location. cert_src Represents the local cert file path which is copied to the target host. If cert is specified, it is copied to the location. private_key_src Represents the local key file path which is copied to the target host. If private_key is specified, it is copied to the location. tls Using this parameter ensures secure transfer of logs over the network. If you do not want a secure wrapper, you can set tls: true.

Verify playbook syntax:

Run the playbook on your inventory file:

36.7. Using the Logging System Roles with RELP

Reliable Event Logging Protocol (RELP) is a networking protocol for data and message logging over the TCP network. It ensures reliable delivery of sự kiện messages and you can use it in environments that do not tolerate any message loss.

The RELP sender transfers log entries in form of commands and the receiver acknowledges them once they are processed. To ensure consistency, RELP stores the transaction number to each transferred command for any kind of message recovery.

You can consider a remote logging system in between the RELP Client and RELP Server. The RELP Client transfers the logs to the remote logging system and the RELP Server receives all the logs sent by the remote logging system.

Administrators can use the Logging System Role to configure the logging system to reliably send and receive log entries.

36.7.1. Configuring client logging with RELP

You can use the Logging System Role to configure logging in RHEL systems that are logged on a local machine and can transfer logs to the remote logging system with RELP by running an Ansible playbook.

This procedure configures RELP on all hosts in the clients group in the Ansible inventory. The RELP configuration uses Transport Layer Security (TLS) to encrypt the message transmission for secure transfer of logs over the network.

Prerequisites

You have permissions to run playbooks on managed nodes on which you want to configure RELP. The managed nodes are listed in the inventory file on the control node. The ansible and rhel-system-roles packages are installed on the control node.

Procedure

Create a playbook.yml file with the following content:

The playbooks uses following settings:

target: This is a required parameter that specifies the host name where the remote logging system is running. port: Port number the remote logging system is listening.

tls: Ensures secure transfer of logs over the network. If you do not want a secure wrapper you can set the tls variable to false. By default tls parameter is set to true while working with RELP and requires key/certificates and triplets ca_cert, cert, private_key and/or ca_cert_src, cert_src, private_key_src.

If ca_cert_src, cert_src, private_key_src triplet is set, the default locations /etc/pki/tls/certs and /etc/pki/tls/private are used as the destination on the managed node to transfer files from control node. In this case, the file names are identical to the original ones in the triplet If ca_cert, cert, private_key triplet is set, files are expected to be on the default path before the logging configuration. If both the triplets are set, files are transferred from local path from control node to specific path of the managed node.
ca_cert: Represents the path to CA certificate. Default path is /etc/pki/tls/certs/ca.pem and the file name is set by the user. cert: Represents the path to cert. Default path is /etc/pki/tls/certs/server-cert.pem and the file name is set by the user. private_key: Represents the path to private key. Default path is /etc/pki/tls/private/server-key.pem and the file name is set by the user. ca_cert_src: Represents local CA cert file path which is copied to the target host. If ca_cert is specified, it is copied to the location. cert_src: Represents the local cert file path which is copied to the target host. If cert is specified, it is copied to the location. private_key_src: Represents the local key file path which is copied to the target host. If private_key is specified, it is copied to the location. pki_authmode: Accepts the authentication mode as name or fingerprint. permitted_servers: List of servers that will be allowed by the logging client to connect and send logs over TLS. inputs: List of logging input dictionary. outputs: List of logging output dictionary.

Optional: Verify playbook syntax.

Run the playbook:

36.7.2. Configuring server logging with RELP

You can use the Logging System Role to configure logging in RHEL systems as a server and can receive logs from the remote logging system with RELP by running an Ansible playbook.

This procedure configures RELP on all hosts in the server group in the Ansible inventory. The RELP configuration uses TLS to encrypt the message transmission for secure transfer of logs over the network.

Prerequisites

You have permissions to run playbooks on managed nodes on which you want to configure RELP. The managed nodes are listed in the inventory file on the control node. The ansible and rhel-system-roles packages are installed on the control node.

Procedure

Create a playbook.yml file with the following content:

The playbooks uses following settings:

port: Port number the remote logging system is listening.

tls: Ensures secure transfer of logs over the network. If you do not want a secure wrapper you can set the tls variable to false. By default tls parameter is set to true while working with RELP and requires key/certificates and triplets ca_cert, cert, private_key and/or ca_cert_src, cert_src, private_key_src.

If ca_cert_src, cert_src, private_key_src triplet is set, the default locations /etc/pki/tls/certs and /etc/pki/tls/private are used as the destination on the managed node to transfer files from control node. In this case, the file names are identical to the original ones in the triplet If ca_cert, cert, private_key triplet is set, files are expected to be on the default path before the logging configuration. If both the triplets are set, files are transferred from local path from control node to specific path of the managed node.
ca_cert: Represents the path to CA certificate. Default path is /etc/pki/tls/certs/ca.pem and the file name is set by the user. cert: Represents the path to cert. Default path is /etc/pki/tls/certs/server-cert.pem and the file name is set by the user. private_key: Represents the path to private key. Default path is /etc/pki/tls/private/server-key.pem and the file name is set by the user. ca_cert_src: Represents local CA cert file path which is copied to the target host. If ca_cert is specified, it is copied to the location. cert_src: Represents the local cert file path which is copied to the target host. If cert is specified, it is copied to the location. private_key_src: Represents the local key file path which is copied to the target host. If private_key is specified, it is copied to the location. pki_authmode: Accepts the authentication mode as name or fingerprint. permitted_clients: List of clients that will be allowed by the logging server to connect and send logs over TLS. inputs: List of logging input dictionary. outputs: List of logging output dictionary.

Optional: Verify playbook syntax.

Run the playbook:

36.8. Additional resources

Getting started with RHEL System Roles Documentation installed with the rhel-system-roles package in /usr/share/ansible/roles/rhel-system-roles.logging/README.html. RHEL System Roles ansible-playbook(1) man page.

Chapter 37. Introduction to Python

Python is a high-level programming language that supports multiple programming paradigms, such as object-oriented, imperative, functional, and procedural paradigms. Python has dynamic semantics and can be used for general-purpose programming.

With Red Hat Enterprise Linux, many packages that are installed on the system, such as packages providing system tools, tools for data analysis, or web applications, are written in Python. To use these packages, you must have the python* packages installed.

37.1. Python versions

Two incompatible versions of Python are widely used, Python 2.x and Python 3.x. RHEL 8 provides the following versions of Python.

Table 37.1. Python versions in RHEL 8

Python 3.6

python3

python3, pip3

RHEL 8.0

full RHEL 8

Python 2.7

python2

python2, pip2

RHEL 8.0

shorter

Python 3.8

python38

python3.8, pip3.8

RHEL 8.2

shorter

Python 3.9

python39

python3.9, pip3.9

RHEL 8.4

shorter

For details about the length of support, see Red Hat Enterprise Linux Life Cycle and Red Hat Enterprise Linux 8 Application Streams Life Cycle.

Each of the Python versions is distributed in a separate module and by design you can install multiple modules in parallel on the same system.

The python38 and python39 modules do not include the same bindings to system tools (RPM, DNF, SELinux, and others) that are provided for the python36 module. Therefore, use python36 in instances where the greatest compatibility with the base operating system or binary compatibility is necessary. In unique instances where system bindings are necessary together with later versions of various Python modules, use the python36 module in combination with third-party upstream Python modules installed through pip into Python’s venv or virtualenv environments.

Always specify the version of Python when installing it, invoking it, or otherwise interacting with it. For example, use python3 instead of python in package and command names. All Python-related commands should also include the version, for example, pip3, pip2, pip3.8, or pip3.9.

The unversioned python command (/usr/bin/python) is not available by default in RHEL 8. You can configure it using the alternatives command; for instructions, see Configuring the unversioned Python. Any manual changes to /usr/bin/python, except changes made using the alternatives command, might be overwritten upon an update.

As a system administrator, use Python 3 for the following reasons:

Python 3 represents the main development direction of the Python project. Support for Python 2 in the upstream community ended in 2022. Popular Python libraries are discontinuing Python 2 support in upstream. Python 2 in Red Hat Enterprise Linux 8 will have a shorter life cycle and aims to facilitate a smoother transition to Python 3 for customers.

For developers, Python 3 has the following advantages over Python 2:

Python 3 enables you to write expressive, maintainable, and correct code more easily. Code written in Python 3 will have greater longevity. Python 3 has new features, including asyncio, f-strings, advanced unpacking, keyword-only arguments, and chained exceptions.

However, legacy software might require /usr/bin/python to be configured to Python 2. For this reason, no default python package is distributed with Red Hat Enterprise Linux 8, and you can choose between using Python 2 and 3 as /usr/bin/python, as described in Configuring the unversioned Python.

System tools in Red Hat Enterprise Linux 8 use Python version 3.6 provided by the internal platform-python package. Red Hat advises customers to use the python36 package instead.

Chapter 38. Installing and using Python

In Red Hat Enterprise Linux 8, Python 3 is distributed in versions 3.6, 3.8, and 3.9, provided by the python36, python38, and python39 modules in the AppStream repository.

Using the unversioned python command to install or run Python does not work by default due to ambiguity. Always specify the version of Python, or configure the system default version by using the alternatives command.

38.1. Installing Python 3

By design, you can install RHEL 8 modules in parallel, including the python27, python36, python38, and python39 modules. Note that parallel installation is not supported for multiple streams within a single module.

You can install Python 3.8 and Python 3.9, including packages built for either version, in parallel with Python 3.6 on the same system, with the exception of the mod_wsgi module. Due to a limitation of the Apache HTTP Server, only one of the python3-mod_wsgi, python38-mod_wsgi, or python39-mod_wsgi packages can be installed on a system.

Procedure

To install Python 3.6 from the python36 module, use:

# yum install python3

The python36:3.6 module stream is enabled automatically.

To install Python 3.8 from the python38 module, use:

# yum install python38

The python38:3.8 module stream is enabled automatically.

To install Python 3.9 from the python39 module, use:

# yum install python39

The python39:3.9 module stream is enabled automatically.

Verification steps

To verify the Python version installed on your system, use the --version option with the python command specific for your required version of Python.

For Python 3.6:

$ python3 --version

For Python 3.8:

$ python3.8 --version

For Python 3.9:

$ python3.9 --version

38.2. Installing additional Python 3 packages

Packages with add-on modules for Python 3.6 generally use the python3- prefix, packages for Python 3.8 include the python38- prefix, and packages for Python 3.9 include the python39- prefix. Always include the prefix when installing additional Python packages, as shown in the examples below.

Procedure

To install the Requests module for Python 3.6, use:

# yum install python3-requests

To install the Cython extension to Python 3.8, use:

# yum install python38-Cython

To install the pip package installer from Python 3.9, use:

# yum install python39-pip

38.3. Installing additional Python 3 tools for developers

Additional Python tools for developers are distributed through the CodeReady Linux Builder repository in the respective python3x-devel module.

The python38-devel module contains the python38-pytest package and its dependencies: the pyparsing, atomicwrites, attrs, packaging, py, more-itertools, pluggy, and wcwidth packages.

The python39-devel module contains the python39-pytest package and its dependencies: the pyparsing, attrs, packaging, py, more-itertools, pluggy, wcwidth, iniconfig, and pybind11 packages. The python39-devel module also contains the python39-debug and python39-Cython packages.

The CodeReady Linux Builder repository and its content is unsupported by Red Hat.

To install packages from the python39-devel module, use the following the procedure.

Procedure

Enable the CodeReady Linux Builder repository:

Enable the python39-devel module:

Install the python39-pytest package:

To install packages from the python38-devel module, replace python39- with python38- in the commands above.

38.4. Installing Python 2

Some applications and scripts have not yet been fully ported to Python 3 and require Python 2 to run. Red Hat Enterprise Linux 8 allows parallel installation of Python 3 and Python 2. If you need the Python 2 functionality, install the python27 module, which is available in the AppStream repository.

Note that Python 3 is the main development direction of the Python project. Support for Python 2 is being phased out. The python27 module has a shorter support period than Red Hat Enterprise Linux 8.

Procedure

To install Python 2.7 from the python27 module, use:

# yum install python2

The python27:2.7 module stream is enabled automatically.

Packages with add-on modules for Python 2 generally use the python2- prefix. Always include the prefix when installing additional Python packages, as shown in the examples below.

To install the Requests module for Python 2, use:

# yum install python2-requests

To install the Cython extension to Python 2, use:

# yum install python2-Cython

Verification steps

To verify the Python version installed on your system, use:

$ python2 --version

By design, you can install RHEL 8 modules in parallel, including the python27, python36, python38, and python39 modules.

38.5. Migrating from Python 2 to Python 3

As a developer, you may want to migrate your former code that is written in Python 2 to Python 3.

For more information on how to migrate large code bases to Python 3, see The Conservative Python 3 Porting Guide.

Note that after this migration, the original Python 2 code becomes interpretable by the Python 3 interpreter and stays interpretable for the Python 2 interpreter as well.

38.6. Using Python

When running the Python interpreter or Python-related commands, always specify the version.

Prerequisites

Ensure that the required version of Python is installed.

Procedure

To run the Python 3.6 interpreter or related commands, use, for example:

$ python3 $ python3 -m cython --help $ pip3 install package

To run the Python 3.8 interpreter or related commands, use, for example:

$ python3.8 $ python3.8 -m cython --help $ pip3.8 install package

To run the Python 3.9 interpreter or related commands, use, for example:

$ python3.9 $ python3.9 -m pip --help $ pip3.9 install package

To run the Python 2 interpreter or related commands, use, for example:

$ python2 $ python2 -m cython --help $ pip2 install package

Chapter 39. Configuring the unversioned Python

System administrators can configure the unversioned python command, located /usr/bin/python, using the alternatives command. Note that the required package, python3, python38, python39, or python2, must be installed before configuring the unversioned command to the respective version.

The /usr/bin/python executable is controlled by the alternatives system. Any manual changes may be overwritten upon an update.

Additional Python-related commands, such as pip3, do not have configurable unversioned variants.

39.1. Configuring the unversioned python command directly

You can configure the unversioned python command directly to a selected version of Python.

Prerequisites

Ensure that the required version of Python is installed.

Procedure

To configure the unversioned python command to Python 3.6, use:

# alternatives --set python /usr/bin/python3

To configure the unversioned python command to Python 3.8, use:

# alternatives --set python /usr/bin/python3.8

To configure the unversioned python command to Python 3.9, use:

# alternatives --set python /usr/bin/python3.9

To configure the unversioned python command to Python 2, use:

# alternatives --set python /usr/bin/python2

39.2. Configuring the unversioned python command to the required Python version interactively

You can configure the unversioned python command to the required Python version interactively.

Prerequisites

Ensure that the required version of Python is installed.

Procedure

To configure the unversioned python command interactively, use:

To reset this configuration and remove the unversioned python command, use:

39.3. Additional resources

alternatives(8) and unversioned-python(1) man pages

Chapter 40. Packaging Python 3 RPMs

Most Python projects use Setuptools for packaging, and define package information in the setup.py file. For more information about Setuptools packaging, see the Setuptools documentation.

You can also package your Python project into an RPM package, which provides the following advantages compared to Setuptools packaging:

Specification of dependencies of a package on other RPMs (even non-Python)

Cryptographic signing

With cryptographic signing, content of RPM packages can be verified, integrated, and tested with the rest of the operating system.

40.1. SPEC file description for a Python package

A SPEC file contains instructions that the rpmbuild utility uses to build an RPM. The instructions are included in a series of sections. A SPEC file has two main parts in which the sections are defined:

Preamble (contains a series of metadata items that are used in the Body) Body (contains the main part of the instructions)

An RPM SPEC file for Python projects has some specifics compared to non-Python RPM SPEC files. Most notably, a name of any RPM package of a Python library must always include the prefix determining the version, for example, python3 for Python 3.6, python38 for Python 3.8, or python39 for Python 3.9.

Other specifics are shown in the following SPEC file example for the python3-detox package. For description of such specifics, see the notes below the example.

1

The modname macro contains the name of the Python project. In this example it is detox.

When packaging a Python project into RPM, the python3 prefix always needs to be added to the original name of the project. The original name here is detox and the name of the RPM is python3-detox.

BuildRequires specifies what packages are required to build and test this package. In BuildRequires, always include items providing tools necessary for building Python packages: python36-devel and python3-setuptools. The python36-rpm-macros package is required so that files with /usr/bin/python3 interpreter directives are automatically changed to /usr/bin/python3.6.

Every Python package requires some other packages to work correctly. Such packages need to be specified in the SPEC file as well. To specify the dependencies, you can use the %python_enable_dependency_generator macro to automatically use dependencies defined in the setup.py file. If a package has dependencies that are not specified using Setuptools, specify them within additional Requires directives.

The %py3_build and %py3_install macros run the setup.py build and setup.py install commands, respectively, with additional arguments to specify installation locations, the interpreter to use, and other details.

The check section provides a macro that runs the correct version of Python. The %__python3 macro contains a path for the Python 3 interpreter, for example /usr/bin/python3. We recommend to always use the macro rather than a literal path.

40.2. Common macros for Python 3 RPMs

In a SPEC file, always use the macros that are described in the following Macros for Python 3 RPMs table rather than hardcoding their values.

In macro names, always use python3 or python2 instead of unversioned python. Configure the particular Python 3 version in the BuildRequires of the SPEC file to python36-rpm-macros, python38-rpm-macros, or python39-rpm-macros.

Table 40.1. Macros for Python 3 RPMs

%__python3

/usr/bin/python3

Python 3 interpreter

%python3_version

3.6

The full version of the Python 3 interpreter.

%python3_sitelib

/usr/lib/python3.6/site-packages

Where pure-Python modules are installed.

%python3_sitearch

/usr/lib64/python3.6/site-packages

Where modules containing architecture-specific extensions are installed.

%py3_build

Runs the setup.py build command with arguments suitable for a system package.

%py3_install

Runs the setup.py install command with arguments suitable for a system package.

40.3. Automatic provides for Python RPMs

When packaging a Python project, make sure that the following directories are included in the resulting RPM if these directories are present:

.dist-info .egg-info .egg-link

From these directories, the RPM build process automatically generates virtual pythonX.Ydist provides, for example, python3.6dist(detox). These virtual provides are used by packages that are specified by the %python_enable_dependency_generator macro.

Chapter 41. Handling interpreter directives in Python scripts

In Red Hat Enterprise Linux 8, executable Python scripts are expected to use interpreter directives (also known as hashbangs or shebangs) that explicitly specify a minimum the major Python version. For example:

The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot policy (BRP) script is run automatically when building any RPM package, and attempts to correct interpreter directives in all executable files.

The BRP script generates errors when encountering a Python script with an ambiguous interpreter directive, such as:

or

41.1. Modifying interpreter directives in Python scripts

Modify interpreter directives in the Python scripts that cause the build errors RPM build time.

Prerequisites

Some of the interpreter directives in your Python scripts cause a build error.

Procedure

To modify interpreter directives, complete one of the following tasks:

Apply the pathfix.py script from the platform-python-devel package:

# pathfix.py -pn -i %__python3 PATH …​

Note that multiple PATHs can be specified. If a PATH is a directory, pathfix.py recursively scans for any Python scripts matching the pattern ^[a-zA-Z0-9_]+.py$, not only those with an ambiguous interpreter directive. Add this command to the %prep section or the end of the %install section.

Modify the packaged Python scripts so that they conform to the expected format. For this purpose, pathfix.py can be used outside the RPM build process, too. When running pathfix.py outside an RPM build, replace %__python3 from the example above with a path for the interpreter directive, such as /usr/bin/python3.

If the packaged Python scripts require a version other than Python 3.6, adjust the preceding commands to include the required version.

41.2. Changing /usr/bin/python3 interpreter directives in your custom packages

By default, interpreter directives in the form of /usr/bin/python3 are replaced with interpreter directives pointing to Python from the platform-python package, which is used for system tools with Red Hat Enterprise Linux. You can change the /usr/bin/python3 interpreter directives in your custom packages to point to a specific version of Python that you have installed from the AppStream repository.

Procedure

To build your package for a specific version of Python, add the python*-rpm-macros subpackage of the respective python package to the BuildRequires section of the SPEC file. For example, for Python 3.6, include the following line:

BuildRequires: python36-rpm-macros

As a result, the /usr/bin/python3 interpreter directives in your custom package are automatically converted to /usr/bin/python3.6.

To prevent the BRP script from checking and modifying interpreter directives, use the following RPM directive:

Chapter 42. Using the PHP scripting language

Hypertext Preprocessor (PHP) is a general-purpose scripting language mainly used for server-side scripting, which enables you to run the PHP code using a web server.

In RHEL 8, the PHP scripting language is provided by the php module, which is available in multiple streams (versions).

Depending on your use case, you can install a specific profile of the selected module stream:

common - The default profile for server-side scripting using a web server. It includes several widely used extensions. minimal - This profile installs only the command-line interface for scripting with PHP without using a web server. devel - This profile includes packages from the common profile and additional packages for development purposes.

42.1. Installing the PHP scripting language

This section describes how to install a selected version of the php module.

Procedure

To install a php module stream with the default profile, use:

# yum module install php:stream

Replace stream with the version of PHP you wish to install.

For example, to install PHP 8.0:

# yum module install php:8.0

The default common profile installs also the php-fpm package, and preconfigures PHP for use with the Apache HTTP Server or nginx.

To install a specific profile of a php module stream, use:

# yum module install php:stream/profile

Replace stream with the desired version and profile with the name of the profile you wish to install.

For example, to install PHP 8.0 for use without a web server:

# yum module install php:8.0/minimal

Additional resources

If you want to upgrade from an earlier version of PHP available in RHEL 8, see Switching to a later stream. For more information on managing RHEL 8 modules and streams, see Installing, managing, and removing user-space components.

42.2. Using the PHP scripting language with a web server

42.2.1. Using PHP with the Apache HTTP Server

In Red Hat Enterprise Linux 8, the Apache HTTP Server enables you to run PHP as a FastCGI process server. FastCGI Process Manager (FPM) is an alternative PHP FastCGI daemon that allows a website to manage high loads. PHP uses FastCGI Process Manager by default in RHEL 8.

This section describes how to run the PHP code using the FastCGI process server.

Procedure

Install the httpd module:

Start the Apache HTTP Server:

Or, if the Apache HTTP Server is already running on your system, restart the httpd service after installing PHP:

Start the php-fpm service:

Optional: Enable both services to start boot time:

To obtain information about your PHP settings, create the index.php file with the following content in the /var/www/html/ directory:

To run the index.php file, point the browser to:

/

Optional: Adjust configuration if you have specific requirements:

/etc/httpd/conf/httpd.conf - generic httpd configuration /etc/httpd/conf.d/php.conf - PHP-specific configuration for httpd /usr/lib/systemd/system/httpd.service.d/php-fpm.conf - by default, the php-fpm service is started with httpd /etc/php-fpm.conf - FPM main configuration /etc/php-fpm.d/www.conf - default www pool configuration

Example 42.1. Running a "Hello, World!" PHP script using the Apache HTTP Server

Create a hello directory for your project in the /var/www/html/ directory:

# mkdir hello

Create a hello.php file in the /var/www/html/hello/ directory with the following content:

#

Start the Apache HTTP Server:

# systemctl start httpd

To run the hello.php file, point the browser to:

:///hello/hello.php

As a result, a web page with the “Hello, World!” text is displayed.

42.2.2. Using PHP with the nginx web server

This section describes how to run PHP code through the nginx web server.

Procedure

Install an nginx module stream:

# yum module install nginx:stream

Replace stream with the version of nginx you wish to install.

For example, to install nginx version 1.18:

# yum module install nginx:1.18

Start the nginx server:

# systemctl start nginx

Or, if the nginx server is already running on your system, restart the nginx service after installing PHP:

# systemctl restart nginx

Start the php-fpm service:

# systemctl start php-fpm

Optional: Enable both services to start boot time:

# systemctl enable php-fpm nginx

To obtain information about your PHP settings, create the index.php file with the following content in the /usr/share/nginx/html/ directory:

echo '' > /usr/share/nginx/html/index.php

To run the index.php file, point the browser to:

:///

Optional: Adjust configuration if you have specific requirements:

/etc/nginx/nginx.conf - nginx main configuration /etc/nginx/conf.d/php-fpm.conf - FPM configuration for nginx /etc/php-fpm.conf - FPM main configuration /etc/php-fpm.d/www.conf - default www pool configuration

Example 42.2. Running a "Hello, World!" PHP script using the nginx server

Create a hello directory for your project in the /usr/share/nginx/html/ directory:

# mkdir hello

Create a hello.php file in the /usr/share/nginx/html/hello/ directory with the following content:

#

Start the nginx server:

# systemctl start nginx

To run the hello.php file, point the browser to:

:///hello/hello.php

As a result, a web page with the “Hello, World!” text is displayed.

42.3. Running a PHP script using the command-line interface

A PHP script is usually run using a web server, but also can be run using the command-line interface.

If you want to run php scripts using only command-line, install the minimal profile of a php module stream.

See Installing the PHP scripting language.

Procedure

In a text editor, create a filename.php file

Replace filename with the name of your file.

Execute the created filename.php file from the command line:

# php filename.php

Example 42.3. Running a "Hello, World!" PHP script using the command-line interface

Create a hello.php file with the following content using a text editor:

Execute the hello.php file from the command line:

# php hello.php

As a result, “Hello, World!” is printed.

42.4. Additional resources

httpd(8) — The manual page for the httpd service containing the complete list of its command-line options. httpd.conf(5) — The manual page for httpd configuration, describing the structure and location of the httpd configuration files. nginx(8) — The manual page for the nginx web server containing the complete list of its command-line options and list of signals. php-fpm(8) — The manual page for PHP FPM describing the complete list of its command-line options and configuration files.

Chapter 43. Using langpacks

Langpacks are meta-packages which install extra add-on packages containing translations, dictionaries and locales for every package installed on the system.

On a Red Hat Enterprise Linux 8 system, langpacks installation is based on the langpacks- language meta-packages and RPM weak dependencies (Supplements tag).

There are two prerequisites to be able to use langpacks for a selected language. If these prerequisites are fulfilled, the language meta-packages pull their langpack for the selected language automatically in the transaction set.

Prerequisites

The langpacks- language meta-package for the selected language has been installed on the system.

On Red Hat Enterprise Linux 8, the langpacks meta packages are installed automatically with the initial installation of the operating system using the Anaconda installer, because these packages are available in the in Application Stream repository.

For more information, see Checking languages that provide langpacks.

The base package, for which you want to search the locale packages, has already been installed on the system.

43.1. Checking languages that provide langpacks

Folow this procedure to check which languages provide langpacks.

Procedure

Execute the following command:

# yum list langpacks-*

43.2. Working with RPM weak dependency-based langpacks

This section describes multiple actions that you may want to perform when querying RPM weak dependency-based langpacks, installing or removing language support.

43.2.1. Listing already installed language support

To list the already installed language support, use this procedure.

Procedure

Execute the following command:

# yum list installed langpacks*

43.2.2. Checking the availability of language support

To check if language support is available for any language, use the following procedure.

Procedure

Execute the following command:

# yum list available langpacks*

43.2.3. Listing packages installed for a language

To list what packages get installed for any language, use the following procedure:

Procedure

Execute the following command:

# yum repoquery --whatsupplements langpacks-

43.2.4. Installing language support

To add new a language support, use the following procedure.

Procedure

Execute the following command:

# yum install langpacks-

43.2.5. Removing language support

To remove any installed language support, use the following procedure.

Procedure

Execute the following command:

# yum remove langpacks-

43.3. Saving disk space by using glibc-langpack-

Currently, all locales are stored in the /usr/lib/locale/locale-archive file, which requires a lot of disk space.

On systems where disk space is a critical issue, such as containers and cloud images, or only a few locales are needed, you can use the glibc locale langpack packages (glibc-langpack-).

To install locales individually, and thus gain a smaller package installation footprint, use the following procedure.

Procedure

Execute the following command:

# yum install glibc-langpack-

When installing the operating system with Anaconda, glibc-langpack- is installed for the language you used during the installation and also for the languages you selected as additional languages. Note that glibc-all-langpacks, which contains all locales, is installed by default, so some locales are duplicated. If you installed glibc-langpack- for one or more selected languages, you can delete glibc-all-langpacks after the installation to save the disk space.

Note that installing only selected glibc-langpack- packages instead of glibc-all-langpacks has impact on run time performance.

If disk space is not an issue, keep all locales installed by using the glibc-all-langpacks package.

Chapter 44. Getting started with Tcl/Tk

44.1. Introduction to Tcl/Tk

Tool command language (Tcl) is a dynamic programming language. The interpreter for this language, together with the C library, is provided by the tcl package.

Using Tcl paired with Tk (Tcl/Tk) enables creating cross-platform GUI applications. Tk is provided by the tk package.

Note that Tk can refer to any of the the following:

A programming toolkit for multiple languages A Tk C library bindings available for multiple languages, such as C, Ruby, Perl and Python A wish interpreter that instantiates a Tk console A Tk extension that adds a number of new commands to a particular Tcl interpreter

For more information about Tcl/Tk, see the Tcl/Tk manual or Tcl/Tk documentation web page.

44.2. Notable changes in Tcl/Tk 8.6

Red Hat Enterprise Linux 7 used Tcl/Tk 8.5. With Red Hat Enterprise Linux 8, Tcl/Tk version 8.6 is provided in the Base OS repository.

Major changes in Tcl/Tk 8.6 compared to Tcl/Tk 8.5 are:

Object-oriented programming support Stackless evaluation implementation Enhanced exceptions handling Collection of third-party packages built and installed with Tcl Multi-thread operations enabled SQL database-powered scripts support IPv6 networking support Built-in Zlib compression

List processing

Two new commands, lmap and dict map are available, which allow the expression of transformations over Tcl containers.

Stacked channels by script

Two new commands, chan push and chan pop are available, which allow to add or remove transformations to or from I/O channels.

Major changes in Tk include:

Built-in PNG image support

Busy windows

A new command, tk busy is available, which disables user interaction for a window or a widget and shows the busy cursor.

New font selection dialog interface Angled text support Moving things on a canvas support

For the detailed list of changes between Tcl 8.5 and Tcl 8.6, see Changes in Tcl/Tk 8.6.

44.3. Migrating to Tcl/Tk 8.6

Red Hat Enterprise Linux 7 used Tcl/Tk 8.5. With Red Hat Enterprise Linux 8, Tcl/Tk version 8.6 is provided in the Base OS repository.

This section describes migration path to Tcl/Tk 8.6 for:

Developers writing Tcl extensions or embedding Tcl interpreter into their applications Users scripting tasks with Tcl/Tk

44.3.1. Migration path for developers of Tcl extensions

To make your code compatible with Tcl 8.6, use the following procedure.

Procedure

Rewrite the code to use the interp structure. For example, if your code reads interp→errorLine, rewrite it to use the following function:

Tcl_GetErrorLine(interp)

This is necessary because Tcl 8.6 limits direct access to members of the interp structure.

To make your code compatible with both Tcl 8.5 and Tcl 8.6, use the following code snippet in a header file of your C or C++ application or extension that includes the Tcl library:

# include # if !defined(Tcl_GetErrorLine) # define Tcl_GetErrorLine(interp) (interp→errorLine) # endif

44.3.2. Migration path for users scripting their tasks with Tcl/Tk

In Tcl 8.6, most scripts work the same way as with the previous version of Tcl.

To migrate you code into Tcl 8.6, use this procedure.

Procedure

When writing a portable code, make sure to not use the commands that are no longer supported in Tk 8.6:

tkIconList_Arrange tkIconList_AutoScan tkIconList_Btn1 tkIconList_Config tkIconList_Create tkIconList_CtrlBtn1 tkIconList_Curselection tkIconList_DeleteAll tkIconList_Double1 tkIconList_DrawSelection tkIconList_FocusIn tkIconList_FocusOut tkIconList_Get tkIconList_Goto tkIconList_Index tkIconList_Invoke tkIconList_KeyPress tkIconList_Leave1 tkIconList_LeftRight tkIconList_Motion1 tkIconList_Reset tkIconList_ReturnKey tkIconList_See tkIconList_Select tkIconList_Selection tkIconList_ShiftBtn1 tkIconList_UpDown

Note that you can check the list of unsupported commands also in the /usr/share/tk8.6/unsupported.tcl file.

Legal Notice

Copyright © 2022 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available ://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

What Windows 10 feature is a user specific data protection mechanism that protects local resources?

Data Execution Prevention (DEP) is a processor feature in Windows 10 that monitors processes to ensure that they do not access unauthorized memory spaces. Data Collector Sets organize multiple counters into a single unit.

Which utility allows you to visually display the data generated by counters and allows you to select the individual counters you want to review?

What utility allows you to visually display the data generated by counters, and allows you to select the individual counters you want to view? Data Collector Sets organize multiple counters into a single unit.

Which of the following best describes a set of performance indicators captured when system performance is acceptable effectively defining normal performance?

Which of the following best describes a set of performance indicators captured when system performance is acceptable, effectively defining normal performance? Correct. A baseline is a set of performance indicators captured when system performance is acceptable, effectively defining normal performance.

Which Active Directory component has a central security database that is used by all computers that are members of it?

Which Active Directory component has a central security database that is used by all computers that are members of it? Domain controllers tải về Group Policy settings every five minutes. Tải thêm tài liệu liên quan đến nội dung bài viết Which Windows 10 feature provides an automated diagnosis and repair of boot problems plus a centralized platform for advanced recovery tool?

Review Which Windows 10 feature provides an automated diagnosis and repair of boot problems plus a centralized platform for advanced recovery tool? ?

Bạn vừa đọc Post Với Một số hướng dẫn một cách rõ ràng hơn về Video Which Windows 10 feature provides an automated diagnosis and repair of boot problems plus a centralized platform for advanced recovery tool? tiên tiến nhất

Chia Sẻ Link Down Which Windows 10 feature provides an automated diagnosis and repair of boot problems plus a centralized platform for advanced recovery tool? miễn phí

Pro đang tìm một số trong những ShareLink Tải Which Windows 10 feature provides an automated diagnosis and repair of boot problems plus a centralized platform for advanced recovery tool? miễn phí.

Thảo Luận thắc mắc về Which Windows 10 feature provides an automated diagnosis and repair of boot problems plus a centralized platform for advanced recovery tool?

Nếu sau khi đọc nội dung bài viết Which Windows 10 feature provides an automated diagnosis and repair of boot problems plus a centralized platform for advanced recovery tool? vẫn chưa hiểu thì hoàn toàn có thể lại Comment ở cuối bài để Mình lý giải và hướng dẫn lại nha #Windows #feature #automated #diagnosis #repair #boot #problems #centralized #platform #advanced #recovery #tool