Network configuration

Why this matters

A server with no network is a paperweight. Configuring one is straightforward once you know which tool owns the configuration on this distribution — and that is the actual difficulty, because there are three competing systems and editing the wrong one changes nothing at all.

Name resolution is the other half. More "the network is down" tickets are DNS than are actually the network, and the files that control it are small enough to read in a minute.

The lesson

Who owns the configuration here?

Before typing anything, find out what is managing the interfaces. Change the wrong layer and your edit is silently overwritten or simply ignored.

systemctl status NetworkManager    # RHEL/Fedora/most Ubuntu desktops
systemctl status systemd-networkd  # minimal servers, containers
ls /etc/netplan/                   # Ubuntu server: YAML that CONFIGURES the above

Netplan is not a third network stack. It is a configuration front end: you write YAML, and it renders configuration for NetworkManager or systemd-networkd underneath. That indirection is exactly what confuses people — on Ubuntu server, editing NetworkManager directly may be overwritten the next time Netplan is applied.

NetworkManager and nmcli

nmcli device status                 # interfaces and their state
nmcli connection show               # saved connection profiles
nmcli connection show "Wired connection 1"

# a static address
nmcli connection modify "Wired connection 1" \
  ipv4.addresses 192.168.1.50/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns "1.1.1.1 8.8.8.8" \
  ipv4.method manual
nmcli connection up "Wired connection 1"   # apply

# back to DHCP
nmcli connection modify "Wired connection 1" ipv4.method auto

nmcli device connect eth0
nmcli device disconnect eth0
nmcli connection reload             # re-read files edited by hand

The distinction that trips everyone: a device is the hardware, a connection is a saved profile of settings. One device can have several connection profiles, and only one is active. nmcli device status shows the hardware; nmcli connection show shows the profiles.

Changes made with nmcli connection modify are written to disk immediately but do not take effect until you bring the connection up again. Editing without reactivating is the most common "I changed it and nothing happened".

nmcli also has a text interface, nmtui, which is genuinely the quickest way to fix a network by hand on a console.

The objectives also list nmconnect. There is no such command. NetworkManager ships nmcli, nmtui (with nmtui-connect and nmtui-edit as direct entry points), and nm-connection-editor for the desktop — and that is the whole set. Do not go looking for an nmconnect binary; you will not find one on any distribution.

The likely origin is the file extension. NetworkManager stores each profile as a keyfile named <name>.nmconnection under /etc/NetworkManager/system-connections/, which is where the name appears for real. If a question offers nmconnect as a command, that is the tell that it is the wrong answer.

Netplan

Ubuntu server writes YAML in /etc/netplan/:

# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.1.50/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

netplan status         # what is configured and active now
netplan try            # apply, and AUTO-REVERT after 120s unless confirmed
netplan apply          # apply permanently
netplan generate       # render the backend config without applying

netplan try is the command that saves remote administrators. It applies the change and starts a timer; if you do not press Enter to confirm — because you have just cut off your own SSH session — it reverts automatically after two minutes and your connection comes back. Use it every time you edit networking on a machine you are connected to remotely. netplan apply has no such safety net.

YAML is indentation-sensitive and Netplan is unforgiving about it. Files are read in lexical order, so 01- before 50-, and later files override earlier ones. Permissions matter too — the files hold no secrets by default but should be 600 if you ever put a WiFi passphrase in one.

Name resolution

Three files, each answering a different question.

/etc/hosts — static, local name-to-address mappings, checked before DNS.

127.0.0.1   localhost
::1         localhost
192.168.1.10  fileserver fileserver.internal

Useful for pinning a name during a migration, for hosts with no DNS entry, and for testing a new server before you cut the DNS over. It is also the first place to look when one machine resolves a name differently from everything else.

/etc/resolv.conf — which DNS servers to ask.

nameserver 1.1.1.1
nameserver 8.8.8.8
search internal.example.com

search is what lets ping fileserver work by silently trying fileserver.internal.example.com.

This file is usually generated, and editing it by hand usually does not stick. NetworkManager, systemd-resolved and DHCP clients all rewrite it. On a systemd-resolved system it is a symlink to a stub listing only 127.0.0.53, which tells you nothing about the real upstream servers — resolvectl status does. To set servers permanently, set them in whatever owns the connection (nmcli, Netplan), not here.

/etc/nsswitch.conf — the order in which sources are consulted, for names and much else:

hosts:      files dns myhostname
passwd:     files sss
group:      files sss

hosts: files dns means /etc/hosts is checked before DNS — which is precisely why a stale entry there overrides a correct DNS record and produces a baffling one-machine-only fault. The same file is why getent passwd sees LDAP users while cat /etc/passwd does not: sss is another source in the chain.

First tools for looking at the network

arp -n                     # the ARP cache: IP to MAC on the local segment
ip neigh                   # the modern equivalent

dig example.com            # full DNS query and answer
dig +short example.com     # just the address
dig @1.1.1.1 example.com   # ask a specific server
dig -x 192.168.1.10        # reverse lookup
dig example.com MX         # a specific record type

curl -I https://example.com          # headers only
curl -v https://example.com          # verbose: DNS, TCP, TLS, request, response
curl -o file.tar.gz https://example.com/file.tar.gz
curl -L https://example.com          # follow redirects

dig is the DNS diagnostic tool. Its value is that dig @server name lets you ask a specific resolver, which is how you prove whether a problem is your configuration or the DNS server itself. If dig @1.1.1.1 example.com works and dig example.com does not, the fault is local — your configured resolver — not the internet.

curl -v is the whole-stack test. It shows DNS resolution, TCP connection, TLS handshake and the HTTP exchange in order, so the first line that fails tells you which layer is broken. That is far more informative than a browser saying "could not connect".

arp -n shows which MAC addresses are behind which local IPs. It matters for one specific and confusing fault: two devices with the same IP address. The ARP entry flips between two MACs and connectivity becomes intermittent in a way that looks like a failing cable.

The order to diagnose in

Work up the stack, and stop at the first failure:

1. ip address — do we have an address at all?
2. ip route — is there a default gateway?
3. ping <gateway> — is the local segment working?
4. ping 1.1.1.1 — does routing off the network work?
5. dig example.com — is it DNS?

If step 4 succeeds and step 5 fails, it is DNS — which is the single most common outcome and the reason the joke exists.

On the exam

• Know which tool owns configuration: NetworkManager (nmcli), systemd-networkd, or Netplan rendering to one of them.
• In nmcli, a device is hardware and a connection is a saved profile. Changes need nmcli connection up to take effect.
• netplan try auto-reverts after 120 seconds; netplan apply does not. Use try remotely.
• /etc/resolv.conf is generated — set DNS in the connection manager instead.
• /etc/nsswitch.conf decides source order, and hosts: files dns is why /etc/hosts beats DNS.
• dig @server name isolates whether a DNS fault is local or upstream.
• Ping the IP, then the name: if the address works and the name does not, it is DNS.