At work, I work on a small website using Ubuntu servers hosted on Amazon EC2 instances. We have two webservers, and at any given time one of them is 'live' and one is 'testing', but when we've got our new features or bugfixes working on the 'testing' server, we run a script that uses the AWS API to swap the IP addresses assigned to the two boxes so that the domains being served by the two servers are swapped.

Consequently, at any given moment, one of these servers can be either our 'live' server or our 'testing' server, but these are not permanent states.

To avoid confusion when SSHing into either of these servers, especially if some silly person (like me) leaves an SSH session open for a long time and gets confused about which server they're on, I want to modify the hostnames of the two servers so that the prompt and title in the terminal window will read ubuntu@ourwebsiteLIVE or ubuntu@ourwebsiteTESTING depending upon whether the server is currently live or testing.

I know I can do this by running hostname ourwebsiteLIVE etc. in our IP-swapping script, and have already implemented this. It works, but now every time I sudo anything on either of our servers it prints e.g.

sudo: unable to resolve host ourwebsiteLIVE

which doesn't seem to break anything, but is fairly irritating. I figure it also might end up breaking stuff in future if I try to chain commands that pipe output to each other, so I guess it's technically not just an aesthetics issue.

All the solutions I've seen to the 'unable to resolve hostname' message involve modifying /etc/hosts or some similar file and then rebooting the server. I can see that this would be fine for many use cases, but is far from ideal for us since we're modifying the hostname routinely and programmatically; we don't want to have to wait for a reboot every time we run our swap script.

Is there a way I can make the error message go away without having to reboot?

  • 1
    The title shown by your terminal window would need to be reset, and I doubt that ssh checks routinely if the hostname has changed (why should it, a hostname is supposed to be permanent). And I find the "switch test/live" a strange idea. Just have a test machine, and copy data over to the live one whenever it is OK doesn't work because? – vonbrand Feb 13 '13 at 11:34
  • @vonbrand Changing the IP kills all open ssh sessions anyway, so modifying the title of currently open sessions is not an issue. As for why we don't just push to live when stuff is working, it's because your way we have the ability to screw up any time we change something on the servers that isn't in our source control repo and therefore isn't part of our normal change-pushing process (e.g. modifying config files or installing new software). Our way, there's no risk we'll break the site by screwing up deployment to the live site (and reverting server admin mistakes is easy; just swap back). – Mark Amery Feb 13 '13 at 11:47

I would suggest using nss-myhostname. It is a nss plugin which just always resolves your current hostname, so there is no need to modify /etc/hosts.

As the issue you are describing is just a resolver issue you can fix it by having a proper DNS setup, i.e. ourwebsiteLIVE.$DOMAIN just resolves to the ip of the machine.

| improve this answer | |
  • It's probably my lack of basic knowledge at fault, but I don't understand your final paragraph at all. Can you clarify? As for your first paragraph, I don't fully understand what the tools does (I don't really have any grasp of the implications of changing hostname to begin with) but it looks like the linked tool will solve our problem. Thank you. I will test it on Monday and accept if it works. – Mark Amery Feb 16 '13 at 14:41

A fast workaround could be to hostname ourwebsiteLIVE AND edit /etc/hosts without rebooting the error should disappear.

| improve this answer | |
  • Can you describe the changes I need to make? Do I need to modify only /etc/hosts or also /etc/hostname? – Mark Amery Feb 16 '13 at 14:38
  • you edit all ourwebsiteOFF in the file /etc/hosts to ourwebsiteLIVE and execute command on command-line hostname ourwebsiteLIVE then re-login. – xx4h Feb 16 '13 at 18:23

I know I'm bring this question back from the dead but currently ( at least in Ubuntu Server 16.04 ) you can do the following to update the hostname with out rebooting.

First edit your /etc/hosts and /etc/hostname with your new hostname

The run the commands

systemctl restart systemd-logind.service
hostnamectl --static --transient --pretty set-hostname YOURHOSTNAME

Your new hostname is now active without a reboot and of course will persist after a reboot.

| improve this answer | |

Ahem... dynamically changing the server's hostname will likely cause a great many of the system daemons to malfunction, and often in ways that are not immediately apparent. The O/S expects the hostname to be set when the system is installed and remain unchanged. hostname is almost always checked just once on process startup. There are other ways to switch versions on the fly however...

The easiest is to setup a level of indirection using symlinks...

You don't need two servers for this. Instead, on the same directory level as the website's "home" directory (i.e. /var/www, hosted/server/html, etc.) create a directory for each version of the site as in...


The v1.1a and v1.1b will be your alternating "LIVE" and "TEST".

Here comes the indirection...

Creating symlinks is very fast so you can probably recreate them when you want to swap versions with the site under light load without too much disruption.

The hosting service I'm basing this on requires the website "home" directory to be "html" as in...


So we rename the html directory the service gives us to a version directory like v1.1a and create a symlink to it named html.

With our symlinks set, the directory listing might look like...

.../TEST -> v1.1b
.../html -> v1.1a

Upon making changes to website files in the .../v1.1b directory, we run a script that removes (Ubuntu has a safer unlink command) and recreates the symlinks with "html" and "TEST" swapped as in...

.../TEST -> v1.1a
.../html -> v1.1b

Hope this helps.

2013-02-16 18:15:12 EST supplemental...

Today's research reveals there's a lot conflicting opinion about this it seems.

My own experience comes from spending a lot of time restoring Xwindows and Ubuntu "zeroconfig" functionality after changing the hostname, as a few of my notes from the incident indicate...

  • Ubuntu-10.04
  • Net

    • As of the May 2011 updates, network settings requirements have changed dramatically in order to support Zeroconf!
    • The main issue encountered has to do with the 'hostname' command.

      • The method Ubuntu uses to maintain the hostname, ip address, etc. has changed.
      • The /etc/hostname and /etc/hosts files are now the authority for all of these values
      • There can no longer be multiple aliases for a host in /etc/hosts
      • In /etc/hosts, the first name should be the Fully Qualified Domain Name (FQDN) -- in other words, hostname.domainname.
      • SSH now sends the FQDN instead of just the host name, so /etc/hosts.allow must be changed from...

        ALL: LOCAL
        ALL: LOCAL *.DORIS

  • Excerpt from http://www.oldapps.com/linux/ubuntu.php?old_ubuntu=35?changelog...

    • 'Avahi will always start even if a .local domain is present. The avahi-daemon package, which implements the mDNS "zeroconf" standard, formerly included a check to avoid running when a conflicting .local DNS domain is present, as it was reported that some ISPs advertise such a .local domain on their networks, leaving Ubuntu hosts unable to see names advertised on the local network (327362). In Ubuntu 9.10, avahi-daemon is started regardless. It is possible that this may cause other problems. If your network is configured this way, you can disable mDNS using the following command:'

      sudo stop avahi-daemon sudo sed -e '/^start/,+1s/^/#/' /etc/init/avahi-daemon.conf

A couple of relevent articles...

| improve this answer | |
  • As I explained already in response to a comment, the reason we use hotswapping is not simply to be able to push changes to our code to live. That would already be easy with two servers and source control. The hotswapping lets us install or update third party software, or make changes to things like our Apache server config that require us to restart it, in a way that is immediately reversable and doesn't cause any downtime on the live site. What you've proposed isn't an alternate solution, it's a substantial step backwards from just having hotswappable servers without changing the hostname. – Mark Amery Feb 16 '13 at 14:34
  • Also, hosting both websites on one server seems potentially dangerous to me since if we push something to the staging site that causes it to consume all the server's memory or CPU capacity, then it breaks the live site too. Finally, can you describe what non-obvious malfunctions changing the hostname might cause? You've asserted the existence, but not provided examples. – Mark Amery Feb 16 '13 at 14:37
  • In addition to my edit above, there are a number of related questions listed in the right column that might shed more light on this. – DocSalvager Feb 16 '13 at 23:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.