The Server’s DHCP Nightmare
Imagine this scenario: It’s 3 AM, the system crashes, and the Web Server suddenly can’t find the Database. After 15 minutes of sweating over log files, you discover the DB server just rebooted and was “gifted” a brand-new IP address by the Router via DHCP. This is a basic but catastrophic mistake I made early in my career: Whether it’s a server running MySQL, Nginx, or a Proxy, the first rule is to lock down that IP.
Back in the CentOS 7 days, we were used to diving straight into /etc/sysconfig/network-scripts/ to edit the ifcfg-eth0 file. However, in CentOS Stream 9 or RHEL 9, that legendary directory is now just a ghost town. Red Hat has officially phased out the old management style in favor of keyfiles (stored at /etc/NetworkManager/system-connections/).
Stubbornly sticking to the old file-editing method will eventually lead to headaches when the system updates. Here is the standard procedure to master networking with nmcli.
Understanding Devices vs. Connections
If you don’t distinguish between these two concepts, you’ll likely mistype commands and accidentally “cut off” your own connection.
- Device: The physical network card, such as
ens33oreth0. You cannot rename it using standard IP configuration commands. - Connection: A configuration profile (like a Wi-Fi name). A network card can have 2-3 different profiles, but only one can be active at any given time.
The nmcli philosophy is clear: You create a blueprint (Connection) and then apply it to the frame (Device). This approach is highly logical when managing complex network layers.
Practical Guide: 3 Steps to Flawless Static IP Configuration
Step 1: Identify the “Target”
Before typing any commands, identify the name of the network card the server is using:
nmcli device statusThe result will clearly show the connected status. For example, my machine uses enp0s3. Next, check the existing profiles:
nmcli connection showUsually, the system automatically creates a profile with the same name as the network card. We will overwrite this profile directly to save time.
Step 2: Execute the Configuration Commands
Suppose you need to set the IP to 192.168.1.100 for an app server, with a Gateway of 192.168.1.1. Instead of typing 5-6 separate commands, combine them into one shot:
nmcli con mod enp0s3 \
ipv4.addresses 192.168.1.100/24 \
ipv4.gateway 192.168.1.1 \
ipv4.dns "8.8.8.8 1.1.1.1" \
ipv4.method manualImportant notes:
- The
/24notation represents the Subnet Mask 255.255.255.0. Without it,nmcliwill throw an error immediately. ipv4.method manualis the key. It tells NetworkManager to stop requesting IPs from the Router and switch to manual mode.
Step 3: Activate the Changes
Note that after Step 2, the IP hasn’t changed yet. You need to “kick-start” the system to load the new configuration:
nmcli con up enp0s3Warning: If you are SSHing into the server via the old IP, you will be disconnected immediately. Don’t panic; just log back in using the new IP 192.168.1.100.
Pro Tip: Use nmtui if You Dislike Long Commands
If you suddenly forget all the parameters, just type nmtui. A simple graphical interface will appear right in the terminal. Use the arrow keys and Tab to enter numbers just like on Windows. This is a lifesaver when working directly at the console in a freezing server room.
Verifying the Results
Engineers speak through results. Use the ip addr command to confirm:
ip addr show enp0s3If you see the line inet 192.168.1.100/24, you’re 90% done. Finally, don’t forget to run ping google.com -c 4 to ensure your server isn’t “isolated” from the outside world.
Conclusion
Switching from file editing to nmcli might feel strange at first, but it makes server administration much more professional and stable. One final note: NetworkManager automatically manages the /etc/resolv.conf file. If you manually edit it, your settings will be wiped after a reboot. Always use nmcli to declare DNS if you want to avoid repeating the work.
