Changing a hostname sounds trivial until it happens on a server that other systems depend on. A Fedora 45 workstation can usually be renamed in seconds, but a production web server, database node, Kubernetes worker, or CI runner may have monitoring agents, TLS certificates, firewall rules, Ansible inventories, backup jobs, and DNS records tied to its old identity.

Fedora 45 uses systemd, so hostnamectl is the correct tool for the job. It updates the persistent hostname configuration, applies the change to the running system, and avoids the half-finished state that can occur when someone edits /etc/hostname manually and forgets the runtime hostname. Fedora’s documentation identifies three hostname types: static, transient, and pretty. [2] The static hostname is the one that normally matters for long-term server identity, while the transient name can be supplied by network configuration and the pretty name is mainly a human-readable label. [2][6]

This guide covers the safe way to change a hostname on Fedora 45, how to verify it, how to update /etc/hosts and DNS, and what to check before renaming a system that is already in production.

Understand Fedora 45 Hostname Types

Before running commands, it helps to know what systemd is actually changing. A hostname is not just one value stored in one file. Modern Linux systems separate the concept into three related names.

Fedora’s documentation explains that the static hostname is used by default at boot and should generally be short, using letters, numbers, and dashes. The transient hostname can be assigned by the network, especially when there is a name conflict on the local network. The pretty hostname may contain spaces, mixed case, and other characters because it is intended for display rather than system-level identification. [2]

The hostnamectl manual is equally clear: if a valid static hostname is set, the transient hostname is not used. Static and transient names are limited to conventional Internet hostname characters and a maximum of 64 characters, while pretty hostnames have far fewer restrictions. [6]

That distinction matters. If you rename a machine using only the legacy hostname command, you may change the transient name but leave the persistent static name untouched. After a reboot, DHCP or the old /etc/hostname value can bring the old identity back.

Check the Current Hostname

Start by inspecting the current configuration. Do not assume the hostname is correct just because the shell prompt looks right. Prompts can be stale, especially in long-lived SSH sessions.

Run:

hostnamectl

A typical response looks like this:

Static hostname: old-name
Pretty hostname: n/a
      Icon name: computer-vm
        Chassis: vm
     Machine ID: 8f2b1e0a4d5c4f6b9c1d2e3f4a5b6c7d
        Boot ID: 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d
Virtualization: kvm
Operating System: Fedora Linux 45 (Server Edition)
     CPE OS Name: cpe:/o:fedoraproject:fedora:45
          Kernel: Linux 7.2.0-xxxx.fc45.x86_64
    Architecture: x86-64

You can also query each hostname type separately:

hostnamectl --static
hostnamectl --transient
hostnamectl --pretty

Fedora documents these exact query options. [2] On a clean system, the static and transient names often match. On cloud instances, containers, or systems managed by configuration management tools, they may not.

Another useful command is:

hostname

This prints the current kernel hostname. It is quick, but it does not tell you whether the value is static or transient. For operational work, hostnamectl gives you the context you need.

Change the Hostname on Fedora 45

The recommended command is:

sudo hostnamectl set-hostname new-hostname

For example, to rename a server from old-name to web01:

sudo hostnamectl set-hostname web01

This command:

• Updates the static hostname in /etc/hostname
• Applies the new hostname immediately to the running system
• Communicates with systemd-hostnamed
• Does not require a reboot

Fedora’s quick docs specifically show hostnamectl set-hostname as the command-line method for setting hostnames. [2] The change applies immediately, so there is no need to restart the machine for the hostname itself to take effect.

Set a Short Hostname

For most servers, use a short, lowercase hostname:

sudo hostnamectl set-hostname app01

Good examples include:

web01
db01
cache01
backup01
k8s-worker-03
jenkins-runner-02

Short names are easier to read in logs, terminal titles, monitoring dashboards, SSH banners, and shell prompts. They also reduce the chance of accidental typos in automation.

Set a Fully Qualified Domain Name

If the machine has a proper DNS domain, use the fully qualified domain name:

sudo hostnamectl set-hostname web01.example.com

This is common for internet-facing servers, internal infrastructure with split-horizon DNS, and environments where certificates or service discovery rely on FQDNs.

However, do not use an FQDN unless DNS is actually configured for it. A hostname such as web01.example.com is only useful if web01.example.com resolves correctly, both locally and from other hosts that need to reach it.

Set Static, Transient, and Pretty Names Separately

You can be explicit about which hostname type you want to change.

Set only the static hostname:

sudo hostnamectl set-hostname --static web01

Set only the transient hostname:

sudo hostnamectl set-hostname --transient web01-temp

Set a descriptive pretty hostname:

sudo hostnamectl set-hostname --pretty "Primary Web Server"

Fedora’s documentation gives similar examples, including a static name such as emily-dev-2 and a pretty name such as “Emily’s 2nd dev laptop.” [2] In practice, most server administrators set the static hostname and leave the pretty name empty. Desktop users may prefer a pretty name because GNOME and other graphical environments can display it in a more friendly form.

Set Both Static and Pretty Names

For a workstation or lab machine, this can be useful:

sudo hostnamectl set-hostname --static dev-laptop-01
sudo hostnamectl set-hostname --pretty "Development Laptop 01"

Verify the result:

hostnamectl

Expected output:

Static hostname: dev-laptop-01
Pretty hostname: Development Laptop 01

The pretty name is not a substitute for the static name. Scripts, SSH configurations, monitoring systems, and network services should use the static hostname or FQDN.

Verify the Hostname Change

After changing the hostname, verify all relevant values:

hostnamectl
hostname
cat /etc/hostname

You should see the new name in all three places.

For a more direct check:

hostnamectl --static
hostnamectl --transient

If the static hostname is set correctly, the transient value should normally match it. If it does not, something else is managing the hostname, such as DHCP, NetworkManager, cloud-init, or a container runtime.

A quick functional test is to open a new SSH session or terminal tab:

ssh user@server
hostname

Existing shell sessions may continue displaying the old hostname in the prompt. That does not necessarily mean the change failed. The prompt is often set when the shell starts and will update after a new login or after reloading the shell configuration.

Update /etc/hosts

Changing the hostname with hostnamectl does not automatically rewrite every reference to the old name in /etc/hosts. This is one of the most common sources of confusion.

Open the file:

sudo nano /etc/hosts

You may see something like:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
127.0.1.1   old-name

Change the old hostname:

127.0.1.1   web01

If you use an FQDN, a practical entry is:

127.0.1.1   web01.example.com web01

Save the file, then verify resolution:

getent hosts web01
getent hosts web01.example.com

You can also test with:

ping -c 3 web01

On Fedora, 127.0.1.1 is not always present by default, particularly on minimal server installations. If it is not there, you do not necessarily need to add it. What matters is that the system can resolve its own hostname consistently, especially for applications that perform reverse lookups or bind services to a hostname.

Avoid careless broad edits to /etc/hosts. A malformed entry can break local name resolution, delay application startup, or interfere with services that depend on hostname lookups.

Update DNS Records

A local hostname change does not update external DNS. If other systems connect to this server by name, update the relevant DNS records.

For an internal server, that may involve:

web01.example.com.    A     192.168.1.50
web01.example.com.    AAAA  fd00::50
50.1.168.192.in-addr.arpa.  PTR  web01.example.com.

For a public server, update the A or AAAA record through your DNS provider or authoritative DNS server. If the server uses a CDN, load balancer, reverse proxy, or cloud-managed DNS service, update the record there instead.

After DNS changes, test from a separate machine:

dig +short web01.example.com
dig +short -x 192.168.1.50

Or use nslookup if dig is not installed:

nslookup web01.example.com

DNS propagation can take time, particularly when the record has a high TTL. Before renaming a production host, lower the TTL well in advance. A TTL of 300 seconds is often a sensible temporary value during a planned change. Once the change is stable, raise it again to reduce DNS query load.

Rename a Fedora 45 Server Safely

On a workstation, renaming is low risk. On a server, it deserves a short maintenance window.

1. Inventory Hostname Dependencies

Before changing anything, search for the old hostname in likely configuration locations:

sudo grep -R --exclude-dir=.git -n "old-name" \
  /etc /opt /srv /var/lib 2>/dev/null

Be careful with this command on large filesystems. It can take time and may surface irrelevant matches. Still, it is valuable before renaming systems with custom application configurations.

Check common services manually:

sudo grep -R -n "old-name" /etc/httpd /etc/nginx /etc/postfix /etc/ssh 2>/dev/null

Also review:

• Monitoring agents
• Backup clients
• Configuration management systems
• Container orchestration labels
• TLS certificate subject alternative names
• Firewall rules that reference hostnames
• Application configuration files
• Cron jobs and systemd timers
• Database replication configurations
• Load balancer backend definitions

A hostname is often used as an identifier rather than a network address. Changing it may not break connectivity, but it can break reporting, authentication, inventory, or certificate validation.

2. Back Up Configuration

Create a simple backup before touching system files:

sudo cp -a /etc/hostname /root/hostname.backup.$(date +%F)
sudo cp -a /etc/hosts /root/hosts.backup.$(date +%F)

For broader protection, use your normal configuration backup process. On servers managed by Ansible, Puppet, Chef, or Salt, confirm that the desired hostname is defined in the appropriate inventory or node data. Otherwise, the next configuration run may rename the machine back.

3. Apply the New Hostname

Run:

sudo hostnamectl set-hostname web01.example.com

Then update /etc/hosts if needed:

sudo nano /etc/hosts

Use an entry such as:

127.0.1.1   web01.example.com web01

4. Restart Affected Services

The hostname change itself does not require a reboot. Some services, however, cache the old hostname at startup.

Common candidates include:

sudo systemctl restart sshd
sudo systemctl restart postfix
sudo systemctl restart httpd
sudo systemctl restart nginx

Only restart services that actually depend on the hostname. Restarting everything “just in case” is not a best practice on a busy production server.

For systemd services, inspect which units may be affected:

systemctl list-units --type=service --state=running

Then check logs after restarting a service:

journalctl -u nginx -b --no-pager
journalctl -u sshd -b --no-pager

5. Confirm From Another Host

From another trusted system, test the new identity:

ssh user@web01.example.com
hostname

Also confirm that monitoring, backups, and service discovery see the new name. A rename is not complete because the local command succeeds. It is complete when the systems that depend on the host recognize the new identity.

Change Hostname Through GNOME Settings

On Fedora 45 Workstation, GNOME provides a graphical method as well.

1. Open Settings.
2. Go to About or System, depending on the GNOME layout.
3. Locate Device Name.
4. Enter the new name.
5. Apply the change.

Fedora’s documentation notes that a short name containing lowercase letters, numbers, and dashes sets the static hostname, while a more descriptive mixed-case name sets the pretty hostname and derives a static name automatically. [2]

The graphical method is convenient for laptops and desktops. For servers, use hostnamectl. It is scriptable, works over SSH, and produces predictable results in automation.

Manual Method: Editing /etc/hostname

You can change the hostname by editing /etc/hostname directly:

sudo nano /etc/hostname

Replace the contents with:

web01

Then apply it immediately:

sudo hostname web01

However, this is not the preferred method on Fedora 45. Fedora’s documentation notes that manually editing /etc/hostname does not necessarily update all hostname values the way hostnamectl does. [5] Red Hat’s guidance similarly recommends hostnamectl because it coordinates the static, transient, and pretty hostname values through systemd. [5]

Use the manual method only in constrained environments, such as image building, recovery shells, or systems where systemd-hostnamed is unavailable. For normal Fedora 45 administration, use:

sudo hostnamectl set-hostname web01

Common Problems and Fixes

The Hostname Reverts After Reboot

If the hostname changes back after reboot, the static hostname was probably never set.

Check:

hostnamectl --static
cat /etc/hostname

Fix it with:

sudo hostnamectl set-hostname web01

Then confirm:

hostnamectl --static

A static hostname should survive reboot. If it does not, investigate cloud-init, network configuration, or configuration management tools that may be resetting it.

The Transient Hostname Is Different

Run:

hostnamectl

If the transient hostname differs from the static hostname, a network service may have assigned it. DHCP servers can do this when they detect a name collision or provide their own hostname option.

Check NetworkManager:

nmcli general hostname

Set NetworkManager’s hostname if needed:

sudo nmcli general hostname web01

Then verify:

hostnamectl

On servers, it is usually best to set the static hostname explicitly. That prevents DHCP or another network component from choosing a runtime name for you.

SSH Still Shows the Old Hostname

This is usually cosmetic. Existing shells often retain the prompt from login time.

Open a new session or reload your shell:

exec bash

If you use zsh:

exec zsh

If the old name persists in new sessions, inspect your shell prompt configuration. For Bash, check:

~/.bashrc
/etc/bashrc

Look for hardcoded values such as:

PS1='\u@old-name:\w\$ '

Replace old-name with \h, which uses the current hostname dynamically:

PS1='\u@\h:\w\$ '

Applications Fail After the Rename

Applications may fail if they cache the old hostname, use it in configuration, or expect a certificate that matches the old name.

Check service logs:

journalctl -xe

For a specific service:

journalctl -u application-name -b --no-pager

Search configuration files for the old hostname:

sudo grep -R -n "old-name" /etc /opt /srv 2>/dev/null

Update the references, restart only the affected services, and test their health endpoints or primary functions.

TLS Certificates Stop Matching

If a service uses a certificate with CN=old-name.example.com or a Subject Alternative Name containing the old hostname, renaming the machine does not update the certificate.

Check the certificate:

sudo openssl x509 -in /etc/pki/tls/certs/server.crt -noout -text | grep -A2 "Subject Alternative Name"

If necessary, issue a new certificate with the new hostname in the SAN list. For Let’s Encrypt, update the certificate request configuration and renew:

sudo certbot certificates
sudo certbot renew --dry-run

Do not disable certificate verification to make an error disappear. Fix the certificate or update the trusted name instead.

Cloud-Init Resets the Hostname

Cloud images often use cloud-init to preserve or regenerate instance identity. If the hostname changes back after reboot, inspect cloud-init configuration:

sudo cat /etc/cloud/cloud.cfg

Look for settings related to hostname preservation. Depending on the image and cloud environment, you may need to set preserve_hostname: true in cloud-init configuration:

sudo nano /etc/cloud/cloud.cfg

Example:

preserve_hostname: true

Then reapply the hostname:

sudo hostnamectl set-hostname web01

Cloud behavior varies by provider and image. Test the change after a reboot before assuming it is permanent.

Hostname Contains Invalid Characters

Static and transient hostnames should use letters, numbers, hyphens, and optionally dots for an FQDN. Avoid spaces, underscores, slashes, and most special characters.

Invalid:

Web Server 01
web_server
web/server

Valid:

web-server-01
web01
web01.example.com

If you want a friendly display name, use the pretty hostname:

sudo hostnamectl set-hostname --pretty "Web Server 01"
sudo hostnamectl set-hostname --static web-server-01

Quick Reference