Should i use my local ip address (eg 192.168.0.1) or 127.0.1.1 in /etc/hosts when setting up a webserver?
For example, in Section 10.4 of the Debian Reference Manual
Some software (e.g., GNOME) expects the system hostname to be resolvable to an IP address with a canonical fully qualified domain name. This is really improper because system hostnames and domain names are two very different things; but there you have it. In order to support that software, it is necessary to ensure that the system hostname can be resolved. Most often this is done by putting a line in /etc/hosts containing some IP address and the system hostname. If your system has a permanent IP address then use that; otherwise use the address 127.0.1.1.
My google cloud instance does not have a static internal ip address at this stage (due to it being a trial i can only use 1 static ip, which i have set to the external ip).
10.152.0.4 server3.foo.com.au server3 #10.152.0.4 server3.c.myprojectID-1.internal server3 # Added by Google
169.254.169.254 metadata.google.internal # Added by Google
So does this information from the Debian quote above, and the fact i am not using a static internal ip address mean that i should change the line in my /etc/hosts file commencing with current internal ip address"10.152.0.4" to “127.0.1.1”?
If the Debian standard was to use 127.0.1.1, why is google automatically adding 10.152.0.4 by default along with the projectID in its own default entries?
I hope this makes sense…i am keen to understand this in far more detail…I realise that in a web server environment it seems like i “should” also have a static internal ip address, however with regard to my original configuration shown above, is it important to have one over the other ip address in /etc/hosts?
But, also hosting on Google makes things complicated.
127.0.1.1 is a loopback address. It is completely private to your system. Nothing outside of your system can reach it. So, you can always count on it to be there for the system itself (there can never be a conflict with another system). That’s why Debian suggests it, but note that not every distribution does; it’s not a universally agreed upon solution to the problem.
Regardless, for your current testing just update if it you need to (if the IP changes). I wouldn’t worry about it. As long as hostname -f resolves correctly, all the things Virtualmin wants a hostname for will work. So, test that and don’t worry about how it’s implemented in hosts.
Debian suggests it, but note that not every distribution does; it’s not a universally agreed upon solution to the problem.
I think this is why i am getting so confused by this…different forums seem to keep posting alternative answers to the question of how a hosts file should look…drives me crazy becaue i cannot understand why or which one should be used.
Add to the the stupid “Added By Google” line that gets put into /etc/hosts by google cloud and you can clearly see my complete confusion.
I will use my internal ip address (because i am eventually going to set this to a static one anyway…unless there is a good reason i should not do this)
I will comment out the “Added by Google” line and then :~$sudo chattr +i /etc/hosts (so that bloody google cannot keep changing my hosts file)
10.152.0.4 server3.foo.com.au server3 #10.152.0.4 server3.c.myprojectid.internal server3 # Added by Google
169.254.169.254 metadata.google.internal # Added by Google
If i do perform a sudo chattr +i /etc/hosts (thus preventing any changes to that file and locking in as shown above), if the server internal ip address happens to get changed, will i loose access to it via virtualmin dashboard and also google cloud shell?
The line aded by google is harmless and might be important for googly purposes. I wouldn’t touch it.
Why are you so concerned with your hosts file, anyway? There’s nothing interesting there. Just make sure “hostname -f” returns what you want your mail to show as being from and forget about the hosts file. It’s not important.
Because ihave found that google will change the hostname -f to its internal fqdn if i dont either have my line above its “Added by Google” line, or chattr +i /etc/hosts.
If idont do one of the above, this line added by google then changes my system hostname -f to server3.c.myprojectname.internal instead of server3.foo.com.au
Iam really struggling with the automation with google cloud…almost none of the tutorials i have followed for anything have worked as expected on it.
Adam, is there any particular reason for using their service? They seem to be a deadset pain. There are -plenty- of reputable VPS hosts out there that are reasonably priced.
It was an opportunity that turned out to be a rather involved learning experience full of closed doors and hallways that lead no where. I feel like i am charting these waters for future generations.
Is another way of saying the above…it was a hair brain idea?
Trouble is, and i say this from an inexperienced viewpoint, its pretty much working now…what could possibly go wong? (“r” left out intentionally)
Ps im hoping that setting a static internal ip in the near future will resolve the hosts file issue.
