Configuring basic system settings

Procedure

1. From the Installation Summary window, click Network and Host Name.
2. From the list in the left-hand pane, select an interface. The details are displayed in the right-hand pane.

3. Toggle the ON/OFF switch to enable or disable the selected interface.

   You cannot add or remove interfaces manually.

4. Click + to add a virtual network interface, which can be either: Team (deprecated), Bond, Bridge, or VLAN.
5. Click - to remove a virtual interface.
6. Click Configure to change settings such as IP addresses, DNS servers, or routing configuration for an existing interface (both virtual and physical).

7. Type a host name for your system in the Host Name field.

   The host name can either be a fully qualified domain name (FQDN) in the format hostname.domainname, or a short host name without the domain. Many networks have a Dynamic Host Configuration Protocol (DHCP) service that automatically supplies connected systems with a domain name. To allow the DHCP service to assign the domain name to this system, specify only the short host name.

   Host names can only contain alphanumeric characters and - or .. Host name should be equal to or less than 64 characters. Host names cannot start or end with - and .. To be compliant with DNS, each part of a FQDN should be equal to or less than 63 characters and the FQDN total length, including dots, should not exceed 255 characters.

   The value localhost means that no specific static host name for the target system is configured, and the actual host name of the installed system is configured during the processing of the network configuration, for example, by NetworkManager using DHCP or DNS.

   When using static IP and host name configuration, it depends on the planned system use case whether to use a short name or FQDN. Red Hat Identity Management configures FQDN during provisioning but some 3rd party software products may require a short name. In either case, to ensure availability of both forms in all situations, add an entry for the host in /etc/hosts in the format IP FQDN short-alias.

8. Click Apply to apply the host name to the installer environment.
9. Alternatively, in the Network and Hostname window, you can choose the Wireless option. Click Select network in the right-hand pane to select your wifi connection, enter the password if required, and click Done.

Procedure

1. List the NetworkManager connection profiles:

   # nmcli connection show
   NAME                UUID                                  TYPE      DEVICE
   Wired connection 1  a5eb6490-cc20-3668-81f8-0314a27f3f75  ethernet  enp1s0

   By default, NetworkManager creates a profile for each NIC in the host. If you plan to connect this NIC only to a specific network, adapt the automatically-created profile. If you plan to connect this NIC to networks with different settings, create individual profiles for each network.

2. If you want to create an additional connection profile, enter:

   # nmcli connection add con-name <connection-name> ifname <device-name> type ethernet

   Skip this step to modify an existing profile.

3. Optional: Rename the connection profile:

   # nmcli connection modify "Wired connection 1" connection.id "Internal-LAN"

   On hosts with multiple profiles, a meaningful name makes it easier to identify the purpose of a profile.

4. Display the current settings of the connection profile:

   # nmcli connection show Internal-LAN
   ...
   connection.interface-name:     enp1s0
   connection.autoconnect:        yes
   ipv4.method:                   auto
   ipv6.method:                   auto
   ...

5. Configure the IPv4 settings:

   • To use DHCP, enter:

     # nmcli connection modify Internal-LAN ipv4.method auto

     Skip this step if ipv4.method is already set to auto (default).

   • To set a static IPv4 address, network mask, default gateway, DNS servers, and search domain, enter:

     # nmcli connection modify Internal-LAN ipv4.method manual ipv4.addresses 192.0.2.1/24 ipv4.gateway 192.0.2.254 ipv4.dns 192.0.2.200 ipv4.dns-search example.com

6. Configure the IPv6 settings:

   • To use stateless address autoconfiguration (SLAAC), enter:

     # nmcli connection modify Internal-LAN ipv6.method auto

     Skip this step if ipv6.method is already set to auto (default).

   • To set a static IPv6 address, network mask, default gateway, DNS servers, and search domain, enter:

     # nmcli connection modify Internal-LAN ipv6.method manual ipv6.addresses 2001:db8:1::fffe/64 ipv6.gateway 2001:db8:1::fffe ipv6.dns 2001:db8:1::ffbb ipv6.dns-search example.com

7. To customize other settings in the profile, use the following command:

   # nmcli connection modify <connection-name> <setting> <value>

   Enclose values with spaces or semicolons in quotes.

8. Activate the profile:

   # nmcli connection up Internal-LAN

Verification

1. Display the IP settings of the NIC:

   # ip address show enp1s0
   2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
       link/ether 52:54:00:17:b8:b6 brd ff:ff:ff:ff:ff:ff
       inet 192.0.2.1/24 brd 192.0.2.255 scope global noprefixroute enp1s0
          valid_lft forever preferred_lft forever
       inet6 2001:db8:1::fffe/64 scope global noprefixroute
          valid_lft forever preferred_lft forever

2. Display the IPv4 default gateway:

   # ip route show default
   default via 192.0.2.254 dev enp1s0 proto static metric 102

3. Display the IPv6 default gateway:

   # ip -6 route show default
   default via 2001:db8:1::ffee dev enp1s0 proto static metric 102 pref medium

4. Display the DNS settings:

   # cat /etc/resolv.conf
   search example.com
   nameserver 192.0.2.200
   nameserver 2001:db8:1::ffbb

   If multiple connection profiles are active at the same time, the order of nameserver entries depend on the DNS priority values in these profiles and the connection types.

5. Use the ping utility to verify that this host can send packets to other hosts:

   # ping <host-name-or-IP-address>

Procedure

1. If you do not know the network device name you want to use in the connection, display the available devices:

   # nmcli device status
   DEVICE     TYPE      STATE                   CONNECTION
   enp1s0     ethernet  unavailable             --
   ...

2. Start nmtui:

   # nmtui

3. Select Edit a connection, and press Enter.

4. Choose whether to add a new connection profile or to modify an existing one:

   • To create a new profile:

     1. Press Add.
     2. Select Ethernet from the list of network types, and press Enter.
   • To modify an existing profile, select the profile from the list, and press Enter.

5. Optional: Update the name of the connection profile.

   On hosts with multiple profiles, a meaningful name makes it easier to identify the purpose of a profile.

6. If you create a new connection profile, enter the network device name into the Device field.

7. Depending on your environment, configure the IP address settings in the IPv4 configuration and IPv6 configuration areas accordingly. For this, press the button next to these areas, and select:

   • Disabled, if this connection does not require an IP address.
   • Automatic, if a DHCP server dynamically assigns an IP address to this NIC.

   • Manual, if the network requires static IP address settings. In this case, you must fill further fields:

     1. Press Show next to the protocol you want to configure to display additional fields.

     2. Press Add next to Addresses, and enter the IP address and the subnet mask in Classless Inter-Domain Routing (CIDR) format.

        If you do not specify a subnet mask, NetworkManager sets a /32 subnet mask for IPv4 addresses and /64 for IPv6 addresses.

     3. Enter the address of the default gateway.
     4. Press Add next to DNS servers, and enter the DNS server address.
     5. Press Add next to Search domains, and enter the DNS search domain.

   Figure 1.1. Example of an Ethernet connection with static IP address settings

   
8. Press OK to create and automatically activate the new connection.
9. Press Back to return to the main menu.
10. Select Quit, and press Enter to close the nmtui application.

Verification

1. Display the IP settings of the NIC:

   # ip address show enp1s0
   2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
       link/ether 52:54:00:17:b8:b6 brd ff:ff:ff:ff:ff:ff
       inet 192.0.2.1/24 brd 192.0.2.255 scope global noprefixroute enp1s0
          valid_lft forever preferred_lft forever
       inet6 2001:db8:1::fffe/64 scope global noprefixroute
          valid_lft forever preferred_lft forever

2. Display the IPv4 default gateway:

   # ip route show default
   default via 192.0.2.254 dev enp1s0 proto static metric 102

3. Display the IPv6 default gateway:

   # ip -6 route show default
   default via 2001:db8:1::ffee dev enp1s0 proto static metric 102 pref medium

4. Display the DNS settings:

   # cat /etc/resolv.conf
   search example.com
   nameserver 192.0.2.200
   nameserver 2001:db8:1::ffbb

   If multiple connection profiles are active at the same time, the order of nameserver entries depend on the DNS priority values in these profiles and the connection types.

5. Use the ping utility to verify that this host can send packets to other hosts:

   # ping <host-name-or-IP-address>

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with dynamic IP address settings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: enp1s0
               interface_name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 dhcp4: yes
                 auto6: yes
               state: up

   The settings specified in the example playbook include the following:

   dhcp4: yes

   Enables automatic IPv4 address assignment from DHCP, PPP, or similar services.

   auto6: yes

   Enables IPv6 auto-configuration. By default, NetworkManager uses Router Advertisements. If the router announces the managed flag, NetworkManager requests an IPv6 address and prefix from a DHCPv6 server.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.network/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Open https://<ip_address_or_hostname>:9090 in a browser, and log in to the web console.

2. In the Health field on the Overview page, click the Not registered warning, or click Subscriptions in the main menu to move to page with your subscription information.

   

3. In the Overview field, click Register.

4. In the Register system dialog, select the registration method.

   

   Optional: Enter your organization’s name or ID. If your account belongs to more than one organization on the Red Hat Customer Portal, you must add the organization name or ID. To get the organization ID, check with your Technical Account Manager at Red Hat.

5. If you do not want to connect your system to Red Hat Insights, clear the Insights checkbox.
6. Click Register.

Procedure

1. Open the system menu, which is accessible from the upper-right screen corner, and click Settings.

   

2. Go to About → Subscription.

3. If you want to register the System through Red Hat Satellite:

   1. In the Registration Server section, select Custom Address.
   2. Enter the server address in the URL field.
4. In the Registration Type section, select your preferred registration method.
5. Fill the Registration Details section.
6. Click Register.

Procedure

1. Install the sos package:

   # dnf install sos

2. Generate a report:

   # sosreport

   Optionally, pass the –upload option to the command to automatically upload and attach the report to a support case. This requires internet access and your Customer Portal credentials.

3. Optional: Manually attach the report to your support case.

   See the Red Hat Knowledgebase solution How can I attach a file to a Red Hat support case? for more information.

Procedure

1. Log in to the RHEL 9 web console.

   For details, see Logging in to the web console.

2. Click the current system time in Overview.

   

3. Click System time.
4. In the Change System Time dialog box, change the time zone if necessary.

5. In the Set Time drop-down menu, select one of the following:

   Manually

   Use this option if you need to set the time manually, without an NTP server.

   Automatically using NTP server

   This is a default option, which synchronizes time automatically with the preset NTP servers.

   Automatically using specific NTP servers

   Use this option only if you need to synchronize the system with a specific NTP server. Specify the DNS name or the IP address of the server.

6. Click Change.

   

Procedure

1. Optional: Display the current system locales settings:

   # localectl status
   System Locale: LANG=en_US.UTF-8
   	VC Keymap: de-nodeadkeys
      X11 Layout: de
     X11 Variant: nodeadkeys

2. List available system locale settings:

   $ localectl list-locales
   C.UTF-8
   ...
   en_US.UTF-8
   en_ZA.UTF-8
   en_ZW.UTF-8
   ...

3. Update the syste locale setting:

Procedure

1. To list available keymaps:

   $ localectl list-keymaps
   ANSI-dvorak
   al
   al-plisi
   amiga-de
   amiga-us
   ...

2. To display the current status of keymaps settings:

   $ localectl status
   ...
   VC Keymap: us
   ...

3. To set or change the default system keymap. For example:

   # localectl set-keymap us

Procedure

1. Display the currently-used font file:

   # cat /etc/vconsole.conf
   
   FONT="eurlatgr"

2. List the available font files:

   # ls -1 /usr/lib/kbd/consolefonts/*.psfu.gz
   
   /usr/lib/kbd/consolefonts/eurlatgr.psfu.gz
   /usr/lib/kbd/consolefonts/LatArCyrHeb-08.psfu.gz
   /usr/lib/kbd/consolefonts/LatArCyrHeb-14.psfu.gz
   /usr/lib/kbd/consolefonts/LatArCyrHeb-16.psfu.gz
   /usr/lib/kbd/consolefonts/LatArCyrHeb-16+.psfu.gz
   /usr/lib/kbd/consolefonts/LatArCyrHeb-19.psfu.gz

   Select a font file that supports your character set and code page.

3. Optional: To test a font file, load it temporarily:

   # setfont LatArCyrHeb-16.psfu.gz

   The setfont utility applies the font file immediately and terminals use the new and font size until you reboot or apply a different font file.

4. To return to the font file defined in /etc/vconsole.conf, enter setfont without any parameters.

5. Edit the /etc/vconsole.conf file and set the FONT variable to the font file RHEL should load at boot time, for example:

   FONT=LatArCyrHeb-16

6. Reboot the host

   # reboot

Procedure

1. Generate an ECDSA key pair:

   $ ssh-keygen -t ecdsa
   Generating public/private ecdsa key pair.
   Enter file in which to save the key (/home/<username>/.ssh/id_ecdsa):
   Enter passphrase (empty for no passphrase): <password>
   Enter same passphrase again: <password>
   Your identification has been saved in /home/<username>/.ssh/id_ecdsa.
   Your public key has been saved in /home/<username>/.ssh/id_ecdsa.pub.
   The key fingerprint is:
   SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI <username>@<localhost.example.com>
   The key's randomart image is:
   +---[ECDSA 256]---+
   |.oo..o=++        |
   |.. o .oo .       |
   |. .. o. o        |
   |....o.+...       |
   |o.oo.o +S .      |
   |.=.+.   .o       |
   |E.*+.  .  . .    |
   |.=..+ +..  o     |
   |  .  oo*+o.      |
   +----[SHA256]-----+

   You can also generate an RSA key pair by using the ssh-keygen command without any parameter or an Ed25519 key pair by entering the ssh-keygen -t ed25519 command. Note that the Ed25519 algorithm is not FIPS-140-compliant, and OpenSSH does not work with Ed25519 keys in FIPS mode.

2. Copy the public key to a remote machine:

   $ ssh-copy-id <username>@<ssh-server-example.com>
   /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   <username>@<ssh-server-example.com>'s password:
   …
   Number of key(s) added: 1
   
   Now try logging into the machine, with: "ssh '<username>@<ssh-server-example.com>'" and check to make sure that only the key(s) you wanted were added.

   Replace <username>@<ssh-server-example.com> with your credentials.

   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.

Procedure

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

   # vi /etc/ssh/sshd_config

2. Change the PasswordAuthentication option to no:

   PasswordAuthentication no

3. On a system other than a new default installation, check that the PubkeyAuthentication parameter is either not set or set to yes.

4. Set the KbdInteractiveAuthentication directive to no.

   Note that the corresponding entry is commented out in the configuration file and the default value is yes.

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

   # setsebool -P use_nfs_home_dirs 1

6. If you are connected remotely, not using console or out-of-band access, test the key-based login process before disabling password authentication.

7. Reload the sshd daemon to apply the changes:

   # systemctl reload sshd

Procedure

1. Add the command for automatically starting ssh-agent in your session to the ~/.bashrc file:

   1. Open ~/.bashrc in a text editor of your choice, for example:

      $ vi ~/.bashrc

   2. Add the following line to the file:

      eval $(ssh-agent)

   3. Save the changes, and quit the editor.

2. Add the following line to the ~/.ssh/config file:

   AddKeysToAgent yes

   With this option and ssh-agent started in your session, the agent prompts for a password only for the first time when you connect to a host.

Procedure

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

   $ ssh-keygen -D pkcs11: > keys.pub

2. Transfer the public key to the remote server. Use the ssh-copy-id command with the keys.pub file created in the previous step:

   $ ssh-copy-id -f -i keys.pub <username@ssh-server-example.com>

3. Connect to <ssh-server-example.com> by using the ECDSA key. You can use just a subset of the URI, which uniquely references your key, for example:

   $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

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

   $ ssh -i "pkcs11:id=%01" <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

   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:

   $ ssh -i pkcs11: <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

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

   $ cat ~/.ssh/config
   IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
   $ ssh <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

   The ssh client utility now automatically uses this URI and the key from the smart card.

Procedure

1. As root, open the /etc/sudoers file.

   # visudo

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

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

   ## Allows people in group wheel to run all commands
   %wheel        ALL=(ALL)       ALL

3. Make sure the line that starts with %wheel is not commented out with the number sign (#).
4. Save any changes, and exit the editor.

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

    # usermod --append -G wheel <username>

   Replace <username> with the name of the user.

Procedure

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

   # visudo -f /etc/sudoers.d/<filename>

   The file opens automatically in an editor.

2. Add the following line to the /etc/sudoers.d/<filename> file:

   <username> <hostname.example.com> = (<run_as_user>:<run_as_group>) <path/to/command>

   • Replace <username> with the name of the user.
   • Replace <hostname.example.com> with the URL of the host.
   • Replace (<run_as_user>:<run_as_group>) with the user or group as to which the command can be executed. If you omit this section, <username> can execute the command as root.
   • Replace <path/to/command> with 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.
   • To allow two and more commands on the same host on one line, you can list them separated by a comma followed by a space.

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

   Defaults    mail_always
   Defaults    mailto="<email@example.com>"

2. Save the changes, and exit the editor.

Verification

1. To verify if a user can run a command with sudo privileges, switch the account:

   # su <username> -

2. As the user, enter the command with the sudo command:

   $ sudo whoami
   [sudo] password for <username>:

   Enter the user’s sudo password.

3. If the privileges are configured correctly, sudo executes the command as the configured user. For example, with the dnf command, it shows the following output:

   ...
   usage: dnf [options] COMMAND
   ...

   If the system returns the following error message, the user is not allowed to run commands with sudo.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: "Configure sudo"
     hosts: managed-node-01.example.com
     tasks:
       - name: "Apply custom /etc/sudoers configuration"
         ansible.builtin.include_role:
           name: rhel-system-roles.sudo
         vars:
           sudo_sudoers_files:
             - path: "/etc/sudoers"
               user_specifications:
                 - users:
                     - <user_name>
                   hosts:
                     - <host_name>
                   commands:
                     - <path_to_command_binary>

   The settings specified in the playbook include the following:

   users

   The list of users that the rule applies to.

   hosts

   The list of hosts that the rule applies to. You can use ALL for all hosts.

   commands

   The list of commands that the rule applies to. You can use ALL for all commands.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.sudo/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Verification

1. On the managed node, verify that the playbook applied the new rules.

   # cat /etc/sudoers | tail -n1
   <user_name> <host_name>= <path_to_command_binary>

Procedure

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

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

   The chronyc command prompt will be displayed as follows:

   chronyc>

2. To list all of the commands, type help.

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

   chronyc command

Procedure

1. Install the ReaR utility:

   # dnf install rear

2. Modify the ReaR configuration file in an editor of your choice, for example:

   # vi /etc/rear/local.conf

3. Add the backup setting details to /etc/rear/local.conf. For example, in the case of the NETFS backup method, add the following lines:

   BACKUP=NETFS
   BACKUP_URL=backup.location

   Replace backup.location by the URL of your backup location.

4. To configure ReaR to keep the previous backup archive when the new one is created, also add the following line to the configuration file:

   NETFS_KEEP_OLD_BACKUP_COPY=y

5. To make the backups incremental, meaning that only the changed files are backed up on each run, add the following line:

   BACKUP_TYPE=incremental

6. Create a rescue system:

   # rear mkrescue

7. Create a backup as per the restore plan. For example, in the case of the NETFS backup method, run the following command:

   # rear mkbackuponly

   Alternatively, you can create the rescue system and the backup in a single step by running the following command:

   # rear mkbackup

   This command combines the functionality of the rear mkrescue and rear mkbackuponly commands.

1. To configure the IPL output method, add OUTPUT=IPL.

2. To configure the backup method and destination, add BACKUP and BACKUP_URL variables. For example:

   BACKUP=NETFS
   
   BACKUP_URL=nfs://<nfsserver name>/<share path>

   Important

   The local backup storage is currently not supported on the 64-bit IBM Z architecture.

3. Optional: You can also configure the OUTPUT_URL variable to save the kernel and initrd files. By default, the OUTPUT_URL is aligned with BACKUP_URL.

4. To perform backup and rescue image creation:

   # rear mkbackup

5. This creates the kernel and initrd files at the location specified by the BACKUP_URL or OUTPUT_URL (if set) variable, and a backup using the specified backup method.
6. To recover the system, use the ReaR kernel and initrd files created in step 3, and boot from a Direct Attached Storage Device (DASD) or a Fibre Channel Protocol (FCP)-attached SCSI device prepared with the zipl boot loader, kernel, and initrd. For more information, see Using a Prepared DASD.
7. When the rescue kernel and initrd get booted, it starts the ReaR rescue environment. Proceed with system recovery.