DB-유

Configuring a Static IP on CentOS 7

· linux, centos, networking

A database VM in our lab picked up a different DHCP lease after a reboot, and everything pointing at it broke in ways that took far too long to trace. Servers shouldn't move. Where I don't control the DHCP server, I give the host a static address on the host itself.

CentOS 7 uses NetworkManager with the familiar ifcfg-* files. I use nmcli when I'm logged into a machine and the files when building images, so both are below.

One warning before you start: have console or out-of-band access (IPMI, VM console). Don't do this over SSH alone. Also have the address, prefix, gateway and DNS servers decided, with the address confirmed free.

Find the interface

CentOS 7 uses predictable names like ens192, eno1 or enp0s3, not eth0.

ip addr
nmcli device status
nmcli connection show

Note the device name and the connection name. They often match, but on cloned VMs you sometimes get a connection called Wired connection 1 attached to ens192. The file behind it is /etc/sysconfig/network-scripts/ifcfg-<connection-name>.

With nmcli

Swap in your own interface and addresses:

sudo nmcli connection modify ens192 ipv4.method manual \
  ipv4.addresses 192.168.10.20/24 \
  ipv4.gateway 192.168.10.1 \
  ipv4.dns "192.168.10.5 8.8.8.8" \
  ipv4.dns-search example.internal
sudo nmcli connection modify ens192 connection.autoconnect yes

Nothing changes on the wire until you bring the connection down and up:

sudo nmcli connection down ens192 && sudo nmcli connection up ens192

Chain down and up with && in one line. If you're on SSH and only run down, you've locked yourself out.

Or the ifcfg file

Same result as a file, /etc/sysconfig/network-scripts/ifcfg-ens192:

TYPE=Ethernet
NAME=ens192
DEVICE=ens192
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.10.20
PREFIX=24
GATEWAY=192.168.10.1
DNS1=192.168.10.5
DNS2=8.8.8.8
DOMAIN=example.internal
IPV6INIT=no
DEFROUTE=yes
PEERDNS=yes

BOOTPROTO=none (or static) turns DHCP off. PREFIX=24 can also be NETMASK=255.255.255.0. If you copy this file to a cloned machine, remove any UUID= or HWADDR= lines; a mismatched MAC stops the profile binding to the interface.

Then have NetworkManager re-read it:

sudo nmcli connection reload
sudo nmcli connection down ens192 && sudo nmcli connection up ens192

resolv.conf and hostname

NetworkManager writes /etc/resolv.conf from DNS1/DNS2. Don't hand-edit it; it gets overwritten. Check it has your servers:

cat /etc/resolv.conf

To manage resolv.conf yourself, set PEERDNS=no in the ifcfg file (or ipv4.ignore-auto-dns yes with nmcli).

I also set the hostname and add it to /etc/hosts so local lookups work when DNS doesn't:

sudo hostnamectl set-hostname db01.example.internal
echo '192.168.10.20 db01.example.internal db01' | sudo tee -a /etc/hosts

Check

ip -4 addr show ens192
ip route
nmcli connection show ens192 | grep ipv4
ping -c 3 192.168.10.1
ping -c 3 google.com

You want exactly one address on the interface, a default via 192.168.10.1 route, and working pings to the gateway (layer 3) and a public name (DNS and NAT). Reboot when convenient and repeat. A config that only works until the next reboot is the most common failure here.

When it doesn't come up

  • Both the old DHCP address and the new one on the device: the old lease is still active. Bring the connection down again, or reboot. Confirm nmcli connection show ens192 | grep ipv4.method says manual.
  • Error: Connection activation failed: No suitable device found for this connection: NAME/DEVICE or HWADDR in the ifcfg file doesn't match the real interface. Remove HWADDR and check DEVICE.
  • Network works but ping google.com gives Name or service not known: DNS. Look at /etc/resolv.conf; if empty, you set PEERDNS=no without a manual nameserver.
  • Two default routes on a multi-homed server: DEFROUTE=no on the secondary interface.
  • If you'd rather drop NetworkManager, systemctl disable --now NetworkManager && systemctl enable network switches to the legacy service, which reads the same ifcfg files. I only bother on servers with bonding or complex bridging.

Keep the ifcfg file in your notes or config management. It's the first thing you want back after a rebuild, and the one thing you can't download until the network is up.