17.3 Configure Network Services to Start Automatically at Boot

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

17.3 Configure Network Services to Start Automatically at Boot

Key Takeaways Explain This Topic AI

NetworkManager is the primary network service on RHEL 10—enable and start it with systemctl enable --now NetworkManager so interfaces and connection profiles apply at boot.

connection.autoconnect yes (and an appropriate profile bound to the device) makes a specific connection activate when the device appears.

systemctl enable controls unit boot behavior; nmcli autoconnect controls whether a given connection profile is eligible to activate—both matter for networking after reboot.

Verify with systemctl is-enabled/is-active NetworkManager, nmcli device status, and ip addr after boot—not only with a green status during the current session.

Do not mask NetworkManager or leave networking disabled unless a task explicitly requires an unusual state; EX200 assumes managed connectivity.

Last updated: August 2026

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:

systemd: NetworkManager.service enabled.

NetworkManager: connection autoconnect (and correct profile).

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

• Check Healthy result
• is-active active
• is-enabled enabled
• nmcli general NM running, devices managed 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

• Property Meaning
• connection.autoconnect yes NM may auto-activate this profile
• connection.autoconnect no Manual connection up required
• connection.interface-name / ifname Which device the profile prefers
• connection.autoconnect-priority Higher wins when multiple profiles compete

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:

• Goal Command
• Run now + at boot systemctl enable --now UNIT
• At boot only systemctl enable UNIT
• Stop and remove from boot systemctl disable --now UNIT

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

start without enable on NetworkManager — dies across reboot.

Perfect static IP in a profile with autoconnect no .

Editing a non-active profile while another profile owns the NIC at boot.

masking NetworkManager while troubleshooting—host may never return networking automatically.

Assuming network.service name from old RHEL docs without checking what the host actually runs.

firewalld disabled so “network service” ports appear dead (symptom looks like networking down).

Only checking systemctl status once without is-enabled .

confusable: enabling NetworkManager-wait-online alone does not set your IP.

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.

Forgetting remote lockout risk when stopping NM over SSH.

Relationship to other chapters

• Topic Link
• Static/DHCP addresses 17.1
• DNS on profiles 17.2
• NM + autoconnect at boot 17.3
• firewalld permanent rules need firewalld enabled 17.4 + security chapter
• generic enable --now pattern Ch15 services
• NFS _netdev mounts need network up Ch14
• 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.