Learn › RHCSA (EX200) › Basic Networking

Hostname Resolution

hostnamectl - a hands-on Linux lab on a real virtual machine.

Give a machine a stable name and teach it to resolve other names. Read and set the static hostname with hostnamectl and hostnamectl set-hostname NAME (which writes /etc/hostname and updates systemd in one step), add static name-to-address mappings by appending a line to /etc/hosts, resolve a name the way a real program does with getent hosts NAME, and read the resolution order in /etc/nsswitch.conf where files comes before dns so a static entry always wins. Serves EX200 basic-networking: configure hostname resolution.

It is 2am. A monitoring alert says web1 is down. You SSH into the machine, run a quick check, and everything looks healthy. So you try to reach web1 from here, by name, and the shell throws it back at you: web1: Name or service not known. The service is fine. The name is the problem. Nothing on this box knows that web1 means 10.0.0.5, so every command that reaches for it by name fails before it starts.

Names are how humans talk about machines. web1 is easier to remember than 10.0.0.5, and far easier than an IPv6 address. But the machine does not care about names until you teach it the mapping. This lesson covers the two halves of that job. First, setting the name a machine calls itself, with hostnamectl. Second, teaching it that a name points at an address, with /etc/hosts and the resolver order in /etc/nsswitch.conf. It is a small toolkit, and it appears on nearly every real troubleshooting call.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs come from a real RHEL 10 machine (AlmaLinux 10.2). A few values are per-machine, the static hostname, the exact OS build string, and the kernel version, so treat those as illustrative. What is stable everywhere is the SHAPE. hostnamectl prints a labeled status banner. An appended /etc/hosts line maps an address to names. And getent hosts resolves a name through the same path a real program would.

hostnamectl is the tool that reads and sets a machine's hostname, the name the system calls itself. Think of it as the nameplate on an office door. The person inside is the same either way, but the nameplate is how everyone else refers to the room. The hostname is that nameplate for a Linux machine.

Run with no arguments, hostnamectl reports the current state: the static hostname, plus context like the operating system and kernel. It talks to systemd behind the scenes, which is why a name you set with it persists across reboots and shows up consistently everywhere the system reports its identity.

You set a hostname so a machine has a stable, human-readable identity. Log lines get stamped with it. Your shell prompt shows it, which is how you avoid running the wrong command on the wrong box at 2am. Monitoring systems group alerts by it. Config management and clustering tools key off it. A machine still called localhost in a fleet of hundreds is a machine you cannot find when it breaks.

The old way was to hand-edit /etc/hostname and hope everything picked up the change. hostnamectl set-hostname does it correctly in one step: it writes the file, updates the running system, and tells systemd, so every layer agrees on the name immediately.

Start by asking the machine who it thinks it is. Run hostnamectl with no arguments and it prints a labeled banner. The line that matters most is Static hostname, the persistent name stored on disk. The other lines give you context: the icon type, the operating system, and the running kernel.

Before you run it, know what success looks like: a multi-line banner with a Static hostname: field near the top, not an error. Read the current identity:

hostnamectl

prompt: [root@servera ~]# answer: hostnamectl output: Static hostname: servera.lab.example.net Icon name: computer-vm Operating System: AlmaLinux 10.2 (Lavender Lion) Kernel: Linux 6.12.0-211.7.3.el10_2.x86_64 hint: The systemd hostname tool, run bare with no arguments: hostnamectl

The Static hostname: servera.lab.example.net line is the one that matters: it is the persistent name written to disk, the one that survives a reboot. Icon name: computer-vm tells you the machine is a virtual machine. Operating System names the distribution and release, and Kernel names the exact running kernel. You do not memorize these values. You confirm one thing: the static hostname reads what you expect. If it still says localhost, this machine has no identity yet, and that is the problem you are about to fix.

The static hostname, the operating system build string, and the kernel version are all per-machine. Yours will show a different hostname, a different AlmaLinux point release, and a different kernel build. That is expected. What is identical everywhere is the SHAPE of the banner: a Static hostname: field, an Operating System: field, and a Kernel: field, each on its own labeled line.

To give the machine a name, hand set-hostname the name you want. The command is hostnamectl set-hostname NAME. Use a fully qualified name when you have one, like servera.lab.example.net, because that is what the machine reports to everything else.

When it works, hostnamectl set-hostname prints nothing. That silence is success, the same way mount is silent when it works. It writes /etc/hostname, updates the live system, and notifies systemd, all in one step. Set the hostname:

hostnamectl set-hostname servera.lab.example.net

prompt: [root@servera ~]# answer: hostnamectl set-hostname servera.lab.example.net output: hint: The set-hostname subcommand of hostnamectl, then the name: hostnamectl set-hostname servera.lab.example.net

No output means success. The name servera.lab.example.net is now the machine's static hostname: written to /etc/hostname, live in the running system, and known to systemd, all from one command. Open a fresh login shell and the prompt reflects it. Run hostnamectl again and the Static hostname: line reads the new name. There was no reboot and no separate file edit, which is exactly why you use this tool instead of hand-editing /etc/hostname yourself.

Setting the hostname does NOT teach any machine what address that name maps to. These are two separate jobs. hostnamectl names THIS machine; it does nothing for name-to-address lookups of other hosts. If you set a hostname and then expect ping web1 to resolve, you will still get Name or service not known until you add the address mapping in the next step. Do not conflate naming a machine with resolving a name.

Now the other half. /etc/hosts is a plain text file that maps IP addresses to names. Each line is one address followed by one or more names for it. It is the oldest name-resolution mechanism on the system, and it is checked before DNS, which makes it the fastest way to pin a name to an address by hand.

You add an entry by appending a line: the address, then the names. Here you teach this machine that 10.0.0.5 is web1.example.net, also reachable as the short name web1. The >> appends to the file without erasing what is already there. Append the mapping:

echo "10.0.0.5 web1.example.net web1" >> /etc/hosts

prompt: [root@servera ~]# answer: echo "10.0.0.5 web1.example.net web1" >> /etc/hosts output: hint: echo the line address then names, and append it with >> to /etc/hosts

No output, and that is success: the line is now appended to /etc/hosts. The format is one address, 10.0.0.5, followed by the names that address answers to: the full name web1.example.net and the short alias web1, separated by spaces. From now on, any lookup of web1 or web1.example.net on this machine finds 10.0.0.5 instantly, without ever touching DNS. The >> matters: a single > would have wiped every existing entry, including the critical localhost line, so always append to this file, never overwrite it.

Use >> (append), never a single > (overwrite), when editing /etc/hosts from the shell. A single > truncates the file to just your one line, destroying the 127.0.0.1 localhost entry that the system depends on. That mistake breaks local resolution in ways that are confusing to diagnose. If you would rather not risk the redirection at all, open the file in an editor instead. But when you do redirect, >> is the only safe choice.

You added the mapping, but does the system actually resolve through it? Do not guess, and do not just cat /etc/hosts, that only proves the line is in the file, not that a lookup uses it. getent hosts NAME performs the exact lookup a real program would, following the system's configured resolution path, and prints the resolved address and names.

Before you run it, predict the answer: querying web1 should print 10.0.0.5 followed by the names from the file. Resolve the name:

getent hosts web1

prompt: [root@servera ~]# answer: getent hosts web1 output: 10.0.0.5 web1.example.net web1 hint: getent queries a system database; the database name for host lookups is hosts, then the name: getent hosts web1

The output 10.0.0.5 web1.example.net web1 proves the lookup succeeded and shows what it found: the address first, then every name that address answers to. This is stronger proof than reading the file, because getent walks the same resolution path a real program uses. It read your /etc/hosts entry, found the match, and returned it before ever reaching for DNS. If getent hosts web1 had printed nothing, the name would not resolve, and you would know the mapping is missing or misspelled. When a name will not resolve, this is the command that tells you whether the system can see it at all.

Why did getent check /etc/hosts before DNS? Because /etc/nsswitch.conf says so. The name-service switch file controls the ORDER in which the system consults its various databases. The hosts: line specifically governs name resolution, and reading it tells you exactly where a lookup goes first.

You do not need the whole file, just the one line. grep with ^hosts: pulls the line that starts with hosts:. Read the resolution order:

grep ^hosts: /etc/nsswitch.conf

prompt: [root@servera ~]# answer: grep ^hosts: /etc/nsswitch.conf output: hosts: files dns myhostname hint: grep for the line starting with hosts: in /etc/nsswitch.conf, anchored with ^

The line hosts: files dns myhostname reads left to right, and that order is the whole point. files means /etc/hosts is consulted FIRST. dns means if the name is not in the hosts file, the system asks DNS servers next. myhostname is a fallback that resolves the machine's own name. Because files comes first, your /etc/hosts entry always wins over DNS for any name it defines. That is why the exam and real troubleshooting both lean on /etc/hosts: it is a local override that beats DNS every time, no DNS server required.

The exact tokens after hosts: can vary slightly by machine and by what is installed, so yours might read files dns or include extras like myhostname or mymachines. What matters, and what is stable, is that files appears before dns. As long as files is first, /etc/hosts is checked before any DNS server, which is the behavior every static-mapping task relies on.

Scaffolding off. No command is printed this time. You have every piece you need.

You just added 10.0.0.5 web1.example.net web1 to /etc/hosts. A task tells you to confirm that the machine can actually resolve the short name web1, following the same path a real program would, and to read back the address it maps to. You do not want to just print the file, that only shows the line exists, not that a lookup uses it. Which single command, given the name web1, performs a real resolution through the system's databases and prints the address and names it found?

prompt: [root@servera ~]# answer: getent hosts web1 output: 10.0.0.5 web1.example.net web1 hint: It is not cat. The tool queries a system database named hosts: getent hosts web1

getent hosts web1 prints exactly one row: the address 10.0.0.5 followed by the names web1.example.net web1. That is the verify step for every static-mapping task. Reading /etc/hosts with cat would only prove the text is in the file; getent proves the resolver actually uses it, walking the same files then dns order from /etc/nsswitch.conf that a real program follows. When a task says map a name and confirm it resolves, this is the command that earns the confirm.

You earned this cheat sheet. Every row is a command you just ran or built:

The one thing to burn in for the exam: /etc/hosts is checked BEFORE DNS because files comes before dns in /etc/nsswitch.conf, so a static entry there is a local override that always wins. Name the machine with hostnamectl set-hostname; resolve other names with a /etc/hosts line, then prove it with getent hosts.

hostnamectl set-hostname names THIS machine; a /etc/hosts line teaches it about OTHER machines. Keep the two jobs separate in your head and you will never chase the wrong fix. When a name will not resolve, reach for getent hosts NAME first. If it prints an address, resolution works and the problem is elsewhere. If it prints nothing, the mapping is missing, and /etc/hosts is where you add it.

The practice terminal walked you through the whole loop. hostnamectl to read a machine's identity, hostnamectl set-hostname to give it a persistent name, an appended /etc/hosts line to map a name to an address, getent hosts to prove that name resolves, and grep ^hosts: /etc/nsswitch.conf to see the files then dns order that makes the static entry win. Every one of those you typed yourself.

Operation Uplink, the basic-networking capstone, is where you run these against a real RHEL 10 machine. A full VM boots for you, with its own real hostname and its own /etc/hosts waiting to be edited. The mission hands you objectives that use exactly what you practiced here: set the machine's hostname, add a static mapping so a named host resolves, and confirm it with getent. One difference from this lesson: the mission shows no commands. You read the objective, recall the hostnamectl set-hostname and getent hosts forms, and type them. That recall is what makes it stick on exam day.

Finish the other basic-networking lessons, then take Operation Uplink and name a real machine.

Practice Hostname Resolution in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.