Module 6: Manage Basic Networking

RHCSA domain covered: Manage Basic Networking (7).

Lab in this kit: Lab 08 (nmcli IP config, hostname, /etc/hosts).

Networking on the RHCSA is about making a machine reachable at a known, *persistent* address, giving it a name, and controlling what traffic reaches it. The single most important idea in this module: on RHEL 9, all persistent network config flows through NetworkManager, and the runtime ip commands you might know from older systems don't survive a reboot. The exam tests whether you can configure an interface that comes back correctly after a restart — so every change here goes through nmcli, not ip.

Why NetworkManager is the only path

What it is: NetworkManager is the service that owns network configuration on RHEL 9. It stores each connection as a *profile* (a keyfile under /etc/NetworkManager/system-connections/), and nmcli is its command-line front end.

Why it matters: the older ifcfg-* scripts are deprecated, and raw ip addr commands are runtime-only. If you configure an address any way other than through NetworkManager, it vanishes on reboot and you fail the task.

Configuring an interface with nmcli

What it is: nmcli connection modify changes a connection profile's settings; nmcli connection up activates the change.

Why it matters: static IP assignment is the core networking task, and the modify→up two-step is where people get tripped up — editing a profile doesn't apply it until you bring it up.

nmcli connection show                              # list all profiles
nmcli connection show --active                     # only active ones
nmcli device status                                # interfaces + bound profile

# Set a static IPv4 config on a profile (persists in NetworkManager)
nmcli connection modify 'System eth0' \
    ipv4.addresses 192.168.4.71/24 \
    ipv4.gateway   192.168.4.1 \
    ipv4.dns       '192.168.10.1 1.1.1.1' \
    ipv4.method    manual \
    autoconnect    yes

# Apply it (reload the profile and bring it up)
nmcli connection up 'System eth0'

# Add a SECOND IP without losing the first (note the leading +)
nmcli connection modify 'System eth0' +ipv4.addresses 192.168.4.131/24

The pieces: ipv4.method manual switches the profile from DHCP to static (forget this and your hand-set address may be ignored in favor of DHCP). ipv4.addresses, .gateway, and .dns set the obvious things. The detail that costs points is the + prefix: ipv4.addresses 192.168.4.131/24 *replaces* the entire address list, while +ipv4.addresses 192.168.4.131/24 *appends* — so adding a secondary IP without the + silently wipes the primary. And nothing you modify takes effect until nmcli connection up reloads and reactivates the profile.

Setting the hostname

What it is: hostnamectl set-hostname sets the system's name, writing /etc/hostname and updating the running kernel hostname in one step.

Why it matters: "set the hostname to X" is a guaranteed-points one-liner — as long as you use the right command instead of just editing the file and forgetting the runtime side.

hostnamectl set-hostname web01.lab.knzlabs        # persistent + immediate
hostnamectl                                        # view current

hostnamectl handles both the file and the live kernel value, so you don't have to edit /etc/hostname by hand and reboot. The hostname is what shows in your shell prompt after the next login and what the machine reports to DNS and logging.

Host file aliases

What it is: /etc/hosts is a local name-to-IP table that the resolver consults *before* DNS (per /etc/nsswitch.conf).

Why it matters: it's how you make names resolve without a DNS server — common in lab and air-gapped setups, and a likely exam task ("make node2 resolve to this IP").

192.168.4.71  rhcsa-node1 node1
192.168.4.72  rhcsa-node2 node2
192.168.4.73  rhcsa-repo  repo

Each line is an IP followed by one or more names for it. Because hosts is checked before DNS, an entry here wins over whatever a DNS server would say — useful for overrides, but also a gotcha if you forget a stale entry is there. Multiple aliases on one line (e.g. rhcsa-node1 node1) all resolve to the same address.

firewalld basics

What it is: firewalld is the dynamic firewall manager. It groups rules into *zones*, and an interface belongs to a zone. You add services or ports to a zone to allow that traffic.

Why it matters: "allow service X" / "open port Y" is one of the most common task types, and the permanent-then-reload pattern is the whole trick.

firewall-cmd --state                              # is it running?
firewall-cmd --get-default-zone
firewall-cmd --list-all                           # what the active zone allows
firewall-cmd --get-active-zones                   # which interface is in which zone

# Allow a service and a port PERMANENTLY, then apply
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-port=9100/tcp
firewall-cmd --reload

# Block ICMP echo (ping)
firewall-cmd --permanent --add-icmp-block=echo-request
firewall-cmd --reload

The pattern to burn in: --permanent writes the rule to the on-disk config but does *not* affect the running firewall; --reload then loads that config into the live ruleset. So the reliable recipe is "make all your --permanent changes, then --reload once." A change made *without* --permanent is runtime-only and disappears on reload or reboot — which is exactly the kind of thing the exam's post-reboot grading catches. Using a named service (--add-service=https) is preferred over a raw port when one exists, because it's clearer and covers the right port automatically.

DNS troubleshooting

What it is: a set of tools for testing name resolution, each querying a slightly different path.

Why it matters: when "the name won't resolve," knowing which tool tests which layer (hosts file vs. DNS) tells you where the problem is.

getent hosts repo.lab        # full resolver path (hosts file THEN dns)
dig +short repo.lab          # DNS only, concise output
host repo.lab                # quick resolver check
cat /etc/resolv.conf         # what DNS servers are configured

getent hosts follows the same path the system actually uses (nsswitch: /etc/hosts first, then DNS), so it tells you what an application would really get. dig and host query DNS directly, bypassing the hosts file — so if getent resolves a name but dig doesn't, the answer is coming from /etc/hosts, not DNS. That comparison is the fastest way to locate where a name is (or isn't) being resolved.

Common pitfalls

• ip addr add is runtime only — it's gone after reboot. Use nmcli connection modify for anything that needs to persist.
• nmcli connection modify doesn't take effect until nmcli connection up <name> reactivates the profile.
• Setting ipv4.addresses without the + prefix REPLACES the whole address list. Use +ipv4.addresses to add a secondary IP.
• Forgetting ipv4.method manual → the interface may stay on DHCP and ignore your static address.
• firewall-cmd changes without --permanent are runtime-only; without --reload, --permanent changes aren't live yet. You need both.

Exam tips

• The networking task is the one most likely to lock you out if you fumble it (change the IP wrong over SSH and you lose your session). The exam console always lets you back in — but verify with nmcli connection show --active before you reboot.
• Reflex sequence for a static IP: nmcli connection modify … ipv4.method manual → nmcli connection up <name> → confirm with ip addr → reboot → reconfirm.
• Reflex sequence for firewalld: all your --permanent adds, then a single --reload, then firewall-cmd --list-all to verify.

Next: Module 7 — Users and groups.