I have been playing around with 3 google cloud compute instances using webmin/virtualmin (web hosting and email), Vestacp (hosting only), and ISPconfig (hosting only) control panels.

The ISPConfig instance has a static external ip address, however the other 2 at this stage are dhcp.

All 3 instances are using a dynamically assigned internal ip addresses, although i have not yet seen any of those ip addresses change in 6 months of testing and restarting and deleting and re-deploying. Whenever i delete an instance, the same internal ip sequence is used (ie whatever is the next lowest unassigned available number is re-added as internal ip address).

I am having some problems with forcing google cloud to bloodywell stop changing my hostname -f configuration in my /etc/hosts file.

It should read localhost.localdomain localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.x.x.x server1.foo.com.au server1

(where x is my internal ip address, "foo" is my domain name)

However, on any 3 of my instances, as soon as i reboot the instance, google cloud adds its own code back in again on next restart. ie by default google cloud keeps changing the file to read the same 2 "# added by Google" lines as shown below localhost.localdomain localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.x.x.x server1.foo.com.au server1
10.x.x.x server1.c.bar.internal server1 # Added by Google metadata.google.internal # Added by Google

(where x is my internal ip address, "foo" is my actual domain name, and "bar" is my google cloud project ID)

This is really causing me problems and i have no idea on which is the best way around it.

-Do i do it from within google cloud DNS API? -setup a static internal ip address in google cloud network settings? -setup a script that continues to check for a change to this file and immediately replace any changes google cloud attempts to make? -or do i need to change the metadata information on the last line of my hosts file so it does not have "...metadata.google.internal # Added by Google" line?

At present option 1 above is not working. As soon as i enable the DNS API then try to enter it i get a "failed to load" error from within my google cloud console. This is a flaming pain in the ass!!! (i have sent a support request to google...who knows how long it will take for an answer)


Ghetto option that may not work: sudo chattr +i /etc/hosts

Do man chattr for details, but this makes the file "(i)mmutable", which means even root can't change it (unless root does chattr -i /etc/hosts first, of course).

As above, you can undo this with sudo chattr -i /etc/hosts

Why it happens: I'm guessing you have a process (perhaps dhcpcd or something) that obtains host information from some source, and then updates various files including /etc/hosts (and probably /etc/resolv.conf, which was why I ended up using chattr). The right way to fix things is figure out what process is doing this and configure it do the right thing. You could also do "cp /etc/hosts.correct /etc/hosts" after the process is done mangling your file, but you have to do this late enough in the bootup process that it happens after the process is done mangling.

  • @Zanna I've done this previously w/ another file for another reason. I was hoping the OP would confirm it worked and then I'd explain it. Should this have been a comment instead? I've been told previously that many of my comments should really be answers. Have I flipped it the wrong way this time? – barrycarter Oct 1 '17 at 13:27
  • Hmm I wouldn't say it should be a comment, though I sometimes suggest something that might work in the comments, generally when the problem isn't very clear and trying things can reveal what's happening - I would say just add the explanation in the first place. I can't think of any answer that is more likely to work without explanation :) here's a good reference on comment-answers – Zanna Oct 1 '17 at 13:38
  • OK, improved it slightly. – barrycarter Oct 1 '17 at 15:37
  • sorry guys, i have been posting on so many forums...i didnt check this one sooner. Before i go attempting the suggestion sudo chattr +i /etc/hosts, can i undo this if it doesnt work? I dont want to stuff anything. Also, can anyone think of a reason why google cloud compute keeps changing the hosts file back to their own defaults in this way? (does this sort of thing happen with other providers such as Amazon or Azure?) Also, i would just like to add, if i leave the google added lines as they are, and add my own line above them, my control panel displays the correct hostname fqdn. Is this ok? – adam Oct 3 '17 at 4:00
  • just like to add, i made the suggested change sudo nano /etc/hosts (commented out the first "added by Google" line, then i performed the sudo chattr +i /etc/hosts as suggested...it worked a charm. I would just like to make the observation, under do not comment out the second metadata line that google adds to the hosts file. Doing this will lock on out of ssh access from within google cloud dashboard. I was fortunate that i had shell access through webmin/virtualmin control panel to undo this error. – adam Oct 3 '17 at 4:19

On GCP/Ubuntu (Xenial at least), /etc/hosts is manipulated and hostname is being via a DHCP (client) exit hook:


which is installed by the package gce-compute-image-packages which is default on GCE images.

You can hack it (exit 0) or remove it; make sure to take care when the package is upgraded, it can overwrite the hook again depending on apt/dpkg settings.

  • The "ghetto" option in the accepted answer could work, but only for /etc/hosts; current hostname will still be set by the hook. – Ricardo Pardini Feb 14 at 15:31

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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