17.3 Configure Network Services to Start Automatically at Boot

17.3 Configure Network Services to Start Automatically at Boot

Quick Answer: Ensure NetworkManager is enabled and active: systemctl enable --now NetworkManager. Ensure the connection profile has connection.autoconnect yes and is the one bound to your NIC. Verify with systemctl is-enabled NetworkManager, nmcli device status, and ip addr. Address settings from 17.1 only help after boot if NM starts and the profile autoconnects.

Official skill in context

Configure network services to start automatically at boot means the host regains configured networking without manual nmcli connection up after every reboot. Related task language:

• “Ensure networking is available after reboot.”
• “Configure the network service to start at boot.”
• “Make sure the static IP configuration is applied automatically.”

On RHEL 10 this is almost always:

1. systemd: NetworkManager.service enabled.
2. NetworkManager: connection autoconnect (and correct profile).
3. Optional: other network-related units the task names (for example a specific service that must listen after boot—often paired with firewall rules in 17.4).

This section is the boot persistence glue for 17.1 and 17.2.

NetworkManager as the network service

systemctl status NetworkManager --no-pager
systemctl is-active NetworkManager
systemctl is-enabled NetworkManager

Enable and start:

sudo systemctl enable NetworkManager
sudo systemctl start NetworkManager
# preferred combined form:
sudo systemctl enable --now NetworkManager

nmcli general status
nmcli device status

Devices should show as connected (or at least disconnected but managed—not unmanaged unless intentional). Unmanaged devices will not apply NM profiles.

Why enable is not optional

systemctl start NetworkManager without enable works until reboot. EX200 graders reboot. Always:

systemctl is-enabled NetworkManager

If disabled, fix with enable (and --now if currently stopped).

Autoconnect on connection profiles

Even with NetworkManager running, a profile can refuse to activate:

nmcli -f connection.autoconnect,connection.id,connection.interface-name connection show ens192

Set autoconnect:

sudo nmcli connection modify ens192 connection.autoconnect yes
sudo nmcli connection up ens192

If two ethernet profiles target the same device, the one that activates may not be the one you edited—inspect active connection:

nmcli connection show --active
nmcli device show ens192 | grep GENERAL.CONNECTION

Bring up the correct profile and disable autoconnect on stale profiles if they steal the device:

sudo nmcli connection modify "Wired connection 1" connection.autoconnect no
sudo nmcli connection modify lab-static connection.autoconnect yes
sudo nmcli connection up lab-static

network.service vs NetworkManager (awareness)

Older materials mention network.service or legacy network scripts. On current RHEL with NetworkManager as the default stack:

• Primary unit to enable: NetworkManager
• Do not blindly systemctl enable network expecting classic initscripts behavior on a pure NM system without understanding the image.

systemctl cat NetworkManager | head
systemctl list-unit-files '*Network*' '*network*'

If a task literally says “network service,” interpret it as make networking start at boot using the system’s actual stack—almost always NetworkManager on RHEL 10 exam images.

Related boot graph: network-online and wait services

Some mounts and services want “network is really up”:

systemctl is-enabled NetworkManager-wait-online.service 2>/dev/null
systemctl status network-online.target --no-pager | head

You rarely reconfigure these on EX200, but understanding them explains why NFS _netdev mounts (filesystems chapter) depend on networking coming up cleanly. Your job is still: NM enabled + profiles autoconnect + correct addresses.

Enabling other “network services” at boot

The objective wording is network services (plural). Besides NM, tasks may require application listeners that use the network:

sudo systemctl enable --now sshd
sudo systemctl enable --now firewalld
sudo systemctl enable --now httpd    # if the task installs a web service

Pattern matches Chapter 15 deploy skills:

Networking chapter focus remains connectivity stack (NetworkManager + connection autoconnect). Service enablement for httpd/nfs-server still uses the same systemctl discipline when the scenario includes them.

firewalld should usually be enabled when you use permanent firewall rules (17.4); rules alone do not start the daemon after reboot if the unit is disabled.

Verification checklist (exam discipline)

# 1) Unit boot configuration
systemctl is-enabled NetworkManager
systemctl is-active NetworkManager

# 2) Profile will auto-activate
nmcli -g connection.autoconnect connection show ens192

# 3) Live network present
nmcli device status
ip -br addr
ip route

# 4) Optional: after practice reboot
systemctl is-active NetworkManager
ip -br addr
ping -c 2 GATEWAY_OR_UTILITY

If NM is enabled but the IP is missing, debug profile (method, addresses, autoconnect, wrong active connection), not only systemd.

Recovering from “no network after reboot”

On console (or break-glass access):

sudo systemctl enable --now NetworkManager
nmcli connection show
sudo nmcli connection up CORRECT_PROFILE
sudo nmcli connection modify CORRECT_PROFILE connection.autoconnect yes
ip -br addr

If the device is unmanaged:

nmcli device set ens192 managed yes

Exam workflows

Workflow A — Ensure NM at boot (baseline)

sudo systemctl enable --now NetworkManager
systemctl is-enabled NetworkManager
systemctl is-active NetworkManager
nmcli general status

Workflow B — Static IP + auto after boot (combines 17.1 + 17.3)

sudo nmcli connection modify ens192 \
  ipv4.method manual \
  ipv4.addresses 172.25.250.11/24 \
  ipv4.gateway 172.25.250.254 \
  ipv4.dns 172.25.250.254 \
  connection.autoconnect yes
sudo nmcli connection up ens192
sudo systemctl enable NetworkManager
systemctl is-enabled NetworkManager

Workflow C — Prevent wrong profile from winning

nmcli connection show
sudo nmcli connection modify "Wired connection 1" connection.autoconnect no
sudo nmcli connection modify ens192 connection.autoconnect yes
sudo nmcli connection up ens192
nmcli connection show --active

Workflow D — Application network service + NM

sudo systemctl enable --now NetworkManager
sudo systemctl enable --now sshd
systemctl is-enabled NetworkManager sshd

Common traps

1. start without enable on NetworkManager — dies across reboot.
2. Perfect static IP in a profile with autoconnect no.
3. Editing a non-active profile while another profile owns the NIC at boot.
4. masking NetworkManager while troubleshooting—host may never return networking automatically.
5. Assuming network.service name from old RHEL docs without checking what the host actually runs.
6. firewalld disabled so “network service” ports appear dead (symptom looks like networking down).
7. Only checking systemctl status once without is-enabled.
8. ** confusable:** enabling NetworkManager-wait-online alone does not set your IP.
9. Bringing interface down with ip link set down and leaving it—NM may or may not recover as you expect; prefer nmcli to manage state.
10. Forgetting remote lockout risk when stopping NM over SSH.

Relationship to other chapters

Section checkpoint

You should systemctl enable --now NetworkManager, confirm is-enabled and is-active, set connection.autoconnect yes on the correct profile, resolve competing profiles, enable other network-facing units when tasks require them, and verify connectivity as a boot outcome, not only as a live tweak. That satisfies EX200 “network services start automatically at boot” on RHEL 10.