Changing Hostname on Red Hat & Fedora

---

system configuration - Red Hat based systems

For many years Red Hat systems have used the same approach for configuration of the hostname.  Starting with RHEL 7 and Fedora 18 there is a new procedure for changing the hostname that represents a significant break with this tradition.  There are now multiple hostname classes and a new command to manage them.  This new password scheme is a component of systemd.

The legacy and new configuration procedures required to make a permanent hostname change on current Red Hat and Fedora systems is covered below.

Traditional Red Hat Hostname Configuration

Applicable: RHEL6, RHEL5, Fedora 17 and older

If possible you should reboot the system when changing the hostname, however, the steps for changing the hostname with and without a system reboot are covered.

Procedure Overview

How to Change Hostname with Reboot

1. Edit /etc/sysconfig/network and update HOSTNAME entry
2. Update hostname in /etc/hosts
3. Reboot
4. Verify hostname

How to Change Hostname without Reboot

1. Edit /etc/sysconfig/network and update HOSTNAME entry
2. Update hostname in /etc/hosts
3. Change hostname with command: hostname new_hostname
4. Verify hostname
5. Restart system logging
6. Restart system networking
7. Consider rebooting when convenient

Procedure Detail

If possible plan to reboot the system when you change the hostname.  There are a number of reasons, some of them discussed below, to strongly favour this approach.  Before starting you may also wish to review the "Additional Considerations" section below to help plan for the change.

1. Edit /etc/sysconfig/network and update the HOSTNAME entry.  A fully qualified domain name should be used.

• vi /etc/sysconfig/network
• HOSTNAME=newname.example.com

Note: The hostname can be temporarily changed without updating /etc/sysconfig/network but it will not be a persistant change.

2. Update hostname in /etc/hosts if required.

• vi /etc/hosts

Warning: If your current hostname is simply localhost do not remove the current localhost entries.  These are required entries in /etc/hosts.  Instead you will either need to add a new entry (static IPs), add to the localhost entry (dynamic IPs), or skip this step if an entry is not needed or desired.

3. Reboot - reboot NOW if possible.  If you cannot reboot skip to step 4.

• shutdown -r now

If you are able to reboot do so and verify that the hostname is set correctly.  If so you are done.  Do NOT perform steps 4-6.  You may wish to skip down to "Other Considerations" below.

Continue with this section only if you cannot reboot

4.  Update the hostname using the hostname command.  You should use the fully qualified domain name.

•  hostname newname.example.com

The hostname is changed immediately.  If you enter hostname again with no arguments you should see the new hostname. Even though the hostname has been changed processes running prior to the change may continue to have a reference to the original hostname.  Steps can taken to mitigate this possibility.  For example, system logging will still use the old hostname. System logging can be restarted to begin logging under the new hostname.  We can also potentially refresh listening network processes that have a reference to the old hostname with a network restart.

5. Restart system logging with the new hostname.

  To restart logging on RHEL5:

• service syslog restart

  To restart logging on RHEL6:

• service rsyslog restart 

If you check your logs you should now see the new hostname in entries where expected.

6. Restart networking

• service network restart

Restarting the network can generally be done without interruption.  However, if there is an issue with the network configuration or a hardware problem it is possible that attempting to restart the network will fail and result in a system network outage.  You should ensure that you have console access available before beginning so that you will be able to correct a configuration issue that prevents the network from restarting.

At this point you should hopefully be in pretty good shape, however, there may still be processes that have a reference to the old hostname.  As an example, if you have not logged off and back on since the hostname change, look at your shell session.  If you echo $HOSTNAME you will see the old hostname.  If your command prompt incorporates the hostname it may still display the old hostname.  You can address this for your current session by logging off and back on, however, the point is that long running processes may continue to hold a reference to the old hostname.  This may or may not be of consequence.

Use your knowledge of your environment to examine running applications to determine if there could be a potential issue.  If there are applications for which there is a concern you might consider restarting them if possible.  You might also consider rebooting when possible.

New Red Hat Hostname Configuration

Applicable: RHEL7, Fedora-18 and newer [Fedora-20]

Starting with RHEL7 and Fedora 18 the hostname is no longer set in /etc/sysconfig/network.  There are now 3 classes of hostnames and a new command named hostnamectl that communicates with a service daemon named systemd-hostnamed for setting and querying hostnames.

The classes are named static, transient, and pretty.  Static is the default hostname and is stored in a system configuration file (i.e., /etc/hostname).  This represents the traditional user configured persistent hostname.  On servers and other non-mobile devices this is all you will probably ever need to worry about. The transient hostname defaults to the static hostname but can be dynamically updated and presumably fills a role in the mobile computing arena.  At the moment pretty just strikes me as a dubious idea but perhaps I just do not know enough to understand where it might be relevant. By default it is not set.

The command 'hostnamectl' or 'hostnamectl status' displays certain host information including the static hostname.  The transient and pretty hostnames will be displayed only if they are set and are unique from the static hostname.

• hostnamectl status

You can also query hostname by class with the static, transient, and pretty options.  If the hostname for a class is not set the command will return an empty string.

• hostnamectl --static status
• hostnamectl --transient status
• hostnamectl --pretty status

Note: Early versions of hostnamectl did not support this usage.  See man page to determine if supported.

The hostname and sysctl kernel.hostname commands can still be used for displaying the current hostname and are important for doing so since the hostnamectl output is not always accurate.

1. To permanently change the system password perform the following steps.  We assume you are running a default configuration where transient is inherited from static and pretty is not set.  For other scenarios you may wish to consult the man page for other options.

• hostnamectl set-hostname newhostname.example.com

The above command results in the current hostname being changed and the /etc/hostname configuration file being updated to make the change permanent.  If a pretty hostname was set, and the above is a legal hostname, it will be unset.  If a unique transient hostname was set it will be unset and will default to the static hostname.

Note: If the provided hostname is NOT a legal hostname the command will assume you want to use that as the pretty hostname and will automatically convert the supplied name into a simplified legal name to be used for the static and transient hostnames.

2. Update hostname in the /etc/hosts file if required.

• vi /etc/hosts

Warning: If your current hostname is simply localhost do not remove the current localhost entries.  These are required entries in /etc/hosts. Instead you will either need to add a new entry (static IPs), add to the localhost entry (dynamic IPs), or skip this step if an entry is not needed or desired.

3. Reboot - Reboot now if possible.

• shutdown -r now

If you are able to reboot do so and verify that the hostname is set correctly.  If so you are done.

If you cannot reboot at this time you should presumably restart the network (systemctl restart network) and review all services, applications, and processes that have been running since before the hostname change to determine if they might have a reference to the old hostname and refresh if needed.  This is discussed in greater detail in the "Traditional Red Hat Hostname Configuration" section above.  The part about logging in that section might not be relevant in this case.

Notes on hostnamectl and systemd-hostnamed

Exploring the Strangeness

There are a few things that might be worth understanding that accompany this new hostname configuration scheme.

Verification 

First, if you have not rebooted, you should verify your change not just with the hostnamectl command but also with the 'hostname' or 'sysctl kernel.hostname' commands as well.  This is due to the potential for hostnamectl status to temporarily report inaccurate results.  The following commands are useful for gathering hostname information:

• hostnamectl status
• hostnamectl --static status
• hostnamectl --transient status
• hostnamectl --pretty status 

• hostname
• sysctl kernel.hostname

Note: The static, transient, and pretty options to hostnamectl status is a feature that was not initially available.  You can drop the status argument to hostnamectl as hostnamectl defaults to status.

The hostname command

The hostname command still exists and is useful for displaying the current effective system hostname.  It can also still set the hostname (non-persistant) as in the past.  Mapped to the new hostname scheme it can be thought of as reporting and setting the transient hostname.

However, hostnamectl is now the appropriate command to use for changing hostnames.  The hostnamectl command communicates with the systemd-hostnamed service deamon.

If you change the hostname without using hostnamectl the hostname information reported by hostnamectl may be inconsistent with the actual system state for a period of time.  This can be confusing when trying to set and verify hostnames if you are unaware of this behavior.  Any tools or scripts that use hostnamectl may also act on inaccurate information.

This is not as bad, however, as it first appears since the systemd-hostnamed service daemon will eventually terminate itself after a period of inactivity.  The next time it is invoked it will have the then current information.  You can also manually refresh it if desired (e.g., systemctl restart systemd-hostnamed) to ensure you see the current state.

The /etc/hostname file

The /etc/hostname file is where the permanent system static hostname configuration is stored.  However, unlike /etc/sysconfig/network on old Red Hat based systems, it is probably best not to edit this file directly.  If you do one thing to be aware of is that the current hostname will immediately be changed.  Also, as with the hostname command discussed above, the output from hostnamctl status will be inconsistent with the actual system state for a period of time.

Update: It appears the NetworkManager is detecting the change in /etc/hostname and applying it.  With NetworkManager down simply updating /etc/hostname does not change the current hostname.  However, by default NetworkManager is likely running.

Other observations

The hostnamectl command can temporarily report inaccurate hostname information even when used exclusively for setting the hostname.

From a system perspective, you cannot really set just the static hostname without impacting the transient hostname even though hostnamectl has an option to do so.  In addition, in this case, the hostnamectl command can report inaccurate transient hostname information for a period of time.

Consider the following as an example:

• hostnamectl --static set-hostname newhostname.example.com

Even though only static is specified the transient hostname, even if set and unique from the static hostname, is impacted as evidenced by the output from 'hostname' and 'sysctl kernel.hostname'.  However, the hostnamectl command will continue to report it as unchanged until systemd-hostnamed is refreshed at which point it correctly reports it as changed.  

I speculate this is because hostnamectl in fact did not change the transient hostname when it was run and as a result systemd-hostnamed was not informed.  However,  as expected, it did update /etc/hostname and as we saw during testing the system is immediately aware of changes made to /etc/hostname and sets the current hostname when updated.

Update: This behavior appears to be the result of NetworkManager updating the current hostname based on contents of /etc/hostname.  If NetworkManager is not running this behavior is not observed. 

Note: All testing with hostnamectl was done on Fedora 20.

For more information on hostnamectl and the changes to system hostnames see the Fedora 18 release notes [section 2.3.2.4] and the Fedora 18 Systems Administrator_Guide

Resources

• http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm36771376 [section 2.3.2.4]
• http://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/s1_Using_Hostnamectl.html
• http://www.freedesktop.org/wiki/Software/systemd/hostnamed

Other Considerations

When changing a hostname you may need to consider more than just the system hostname change.  Below are some possible areas to consider.

Do you need to update DNS?
Will you set an alias for the transition period?  Remember to remove it when appropriate?
Do you need to update /etc/hosts on other systems?
Do you need to update nfs references in /etc/fstab or /etc/exports files?
Do programs or scripts have hard coded host references that need to be updated?
Do user clients have to be updated?  How will users be informed?  In an an enterprise environment has the help desk and client systems group been informed?
...