Red Hat Certified System Administrator (RHCSA) #10 Basic Networking: NetworkManager (nmcli), hostname, /etc/hosts

In #9 System Operation, we synced time with chronyd and managed logs and jobs with journald and cron. This time we tackle networking — what connects the system to the outside world. On RHEL 9, the starting point and the endpoint for network configuration is NetworkManager, and the tool you handle by hand on the exam is its command-line client, nmcli.

The heart of networking tasks on RHCSA is simple: set a static IP and make sure that configuration survives a reboot. In an exam environment with no internet, getting one character of an IP wrong can block even verification, so this post drills the flow of creating and fixing connections with nmcli until it’s firmly in your hands.

What is NetworkManager #

Networking on RHEL 9 is managed by a daemon called NetworkManager. The old /etc/sysconfig/network-scripts/ifcfg-* approach you used to edit by hand is gone; now NetworkManager holds and applies all configuration. Changing the network on the exam means, in effect, instructing NetworkManager to make the change.

To understand NetworkManager you need to distinguish two concepts.

A device is close to the hardware, and a connection is the configuration profile you lay over that device. You can keep several connections for a single device and swap between them depending on the situation. The task “set a static IP” on the exam ultimately comes down to modifying the connection applied to that device.

Let’s start by checking whether NetworkManager itself is up.

systemctl status NetworkManager
systemctl is-enabled NetworkManager

If the daemon isn’t running, nmcli commands won’t work, so make it a habit to confirm it’s active before you start.

Viewing the current state with nmcli #

nmcli is NetworkManager’s command-line client. On the exam you can also use the GUI or a text menu (nmtui), but to work fast and accurately it’s better to have nmcli firmly in hand.

First, look at the state of the devices.

nmcli device status

In the STATE column of the output, check whether it’s connected or disconnected, and which connection is applied.

You list connections with the following.

nmcli connection show

This shows four columns: NAME (connection name), UUID, TYPE, and DEVICE. The NAME here is the name of what you’ll act on. To see all the detailed settings of a specific connection, append its name.

nmcli connection show "System ens160"

This command lists all properties of that connection as key/value pairs like ipv4.method, ipv4.addresses, ipv4.gateway, and ipv4.dns. When setting a static IP, you use these exact key names in modify.

Setting a static IP permanently: the heart of RHCSA #

This is the most important task in this post. Questions like “set the static IP 192.0.2.10/24 on this system, with gateway 192.0.2.1 and DNS 192.0.2.53” come up often on the exam. The flow with nmcli is as follows.

Modifying an existing connection #

If there’s already an applied connection, it’s cleaner to fix it with modify rather than create a new one. Let’s assume the connection name is System ens160.

nmcli connection modify "System ens160" \
  ipv4.addresses 192.0.2.10/24 \
  ipv4.gateway 192.0.2.1 \
  ipv4.dns 192.0.2.53 \
  ipv4.method manual

Here’s what each key means.

The decisively important key here is ipv4.method manual. If you only put in addresses and leave method as auto, an address from DHCP gets added alongside and the result differs from what you intended. For a static IP you must always switch method to manual.

Applying the change #

modify only writes to the configuration file; it does not immediately apply to the interface. To apply the change, you have to bring the connection back up.

nmcli connection up "System ens160"

up activates a connection, and down deactivates it.

nmcli connection down "System ens160"
nmcli connection up "System ens160"

Because NetworkManager writes settings saved with modify to disk, they persist across a reboot too. This is the crux on RHCSA. A setting made by hand with just ip addr add disappears on reboot, but one saved as an nmcli connection is permanent.

Creating a new connection #

It’s worth knowing how to create a new connection without touching the existing one. You use connection add.

nmcli connection add \
  type ethernet \
  con-name static-ens160 \
  ifname ens160 \
  ipv4.addresses 192.0.2.10/24 \
  ipv4.gateway 192.0.2.1 \
  ipv4.dns 192.0.2.53 \
  ipv4.method manual

A connection created with add is also saved to disk and persists across a reboot. After creating it, activate it with nmcli connection up static-ens160 and it applies.

Adding multiple DNS entries or appending one #

To specify more than one DNS server, list them with commas.

nmcli connection modify "System ens160" ipv4.dns "192.0.2.53,192.0.2.54"

If you only want to append to the existing value, prefix the key with +; to remove just some of them, prefix it with -.

nmcli connection modify "System ens160" +ipv4.dns 8.8.8.8
nmcli connection modify "System ens160" -ipv4.dns 8.8.8.8

Reverting to DHCP #

Conversely, a task to turn a static configuration back into DHCP may come up. Switch method to auto and clear out the remaining static values.

nmcli connection modify "System ens160" ipv4.method auto
nmcli connection modify "System ens160" ipv4.addresses "" ipv4.gateway ""
nmcli connection up "System ens160"

If you only switch method to auto and leave addresses in place, the static address gets added alongside the DHCP address, so when reverting don’t forget to clear the values too.

Setting the hostname #

You handle the hostname with the hostnamectl command. To see the current hostname and system information, run it with no arguments.

hostnamectl

To change the hostname, use set-hostname.

hostnamectl set-hostname server1.example.com

This command writes the hostname to the /etc/hostname file, so it persists across a reboot too. You can confirm the result again with the hostname command or hostnamectl.

hostname

After changing the hostname, the prompt in your current shell may still show the old name, but it refreshes when you open a new shell or log in again. On the exam, what’s graded is whether it’s written correctly to the file, so verify with hostnamectl output rather than the prompt display.

Resolving names with /etc/hosts #

To make a specific hostname resolve to an IP without a DNS server, write the entry directly into the /etc/hosts file. The format is the IP address, then the hostnames.

192.0.2.10   server1.example.com server1
192.0.2.20   server2.example.com server2

On one line, list one IP and the names that IP points to, separated by whitespace. Following the convention of putting the canonical name (FQDN) first with a short alias after it keeps things tidy.

Since the system usually consults /etc/hosts before DNS when resolving names, a question like “make server2 resolve to 192.0.2.20” is solved by adding one line to this file. You can verify the added entry with getent hosts server2.

getent hosts server2.example.com

This command goes through the system’s name-resolution path (both /etc/hosts and DNS) and shows the result, which makes it well suited to confirming that a setting actually takes effect.

Checking the result with the ip command #

Once you’ve finished configuring with nmcli, verify the state actually reflected in the kernel with the ip command. The ip command is for checking; remember that adding an address directly here is not permanent.

Look at the address attached to the interface.

ip addr show ens160

If you see inet 192.0.2.10/24 in the output, the IP is applied correctly.

Look at the routing table, especially the default gateway.

ip route

Confirm that the default route points to the intended gateway, like default via 192.0.2.1 dev ens160.

For the DNS configuration and the overall connection state, it’s more accurate to check with nmcli again.

nmcli connection show "System ens160" | grep ipv4

If the address and gateway shown by the ip command, and the DNS and method shown by nmcli, all match what you intended, the task is done. For actual communication, check quickly with ping -c 3 192.0.2.1.

Here are the spots where people commonly get stuck.

• Not switching ipv4.method to manual. You put in only addresses, so a DHCP address gets added alongside
• Not running up after modify. The setting is saved but not reflected on the interface
• Missing the prefix. Leaving out /24, as in 192.0.2.10, makes the apply fail
• A typo in the connection name. The name in the quotes must exactly match the NAME from connection show

Exam points #

Let’s sum up the parts of this post that tie directly to RHCSA grading.

• Set a static IP permanently with an nmcli connection. Specify ipv4.addresses, ipv4.gateway, ipv4.dns, and ipv4.method manual with modify or add
• Always specify ipv4.method manual. A static IP with method left at auto won’t behave as intended
• After modify, run connection up. Saving and applying are separate
• ip addr and ip route are for checking. An address added directly disappears after a reboot
• The hostname is hostnamectl set-hostname. It’s written to /etc/hostname and persists permanently
• Name resolution is one line added to /etc/hosts. Verify with getent hosts

Wrap-up #

What this post locked in:

• NetworkManager manages RHEL 9 networking. Distinguish device from connection (a configuration profile)
• nmcli commands. See devices with device status and connections with connection show, configure with connection modify and add, and apply with up and down
• Setting a static IP permanently. Add method manual to addresses, gateway, and dns and save, and it persists across a reboot
• hostname. Change it permanently with hostnamectl set-hostname
• /etc/hosts. Write the IP and hostname on one line to resolve names without DNS
• Verification. Confirm the apply with ip addr and ip route, and check communication with ping

Next: Users/groups #

Now that the network has connected the system to the outside world, we turn to who uses that system and with what permissions.

In #11 Users/groups: UID/GID, sudo, ACL, password policy, we’ll work through creating users and groups and assigning UID/GID, delegating permissions with sudo, granting fine-grained per-file access with ACL, and setting password expiry policy — all typed out by hand.