/etc/resolv.conf and hostname being overwritten on reset

Submitted by oneearth on Fri, 01/20/2017 - 11:21

i'm experiencing the /etc/resolv.conf and hostname being reset upon reboot. i did see the info about chattr +i at: https://www.virtualmin.com/documentation/dns/faq

i'm in contact with the vps provider. they tried some configuration modification on their end but after that, i could ssh in and couldn't access parts of the system.

mba:~ om$ ssh harrca@seva108.com -p12345
ssh: connect to host seva108.com port 12345: Connection refused

in browser:
http://seva108.com/roundcube --> connection refused

they thought it was because i had changed the port number.

in any case, they are provisioning a new vps so that i can at least start from ground zero again.

question:

  1. will the chattr +i resolve both the /etc/resolv.conf reset and the hostname reset (it resets back to a non FQDN)?

  2. i don't like the idea of slower dns lookup by unchecking "check resolv.conf for this system" i imagine that the chattr +i maintain normal dns lookup. could you confirm that as true?

thanks

Status: 
Active

Comments

Submitted by oneearth on Fri, 01/20/2017 - 11:23

also, why do some vps provider overwrite /etc/resolv.conf and some do not?

Submitted by oneearth on Fri, 01/20/2017 - 11:32

also, where does chattr live? is it supposed to live in centos 7? bash can't find it and neither can find.

Submitted by andreychek on Fri, 01/20/2017 - 11:41

Howdy -- yeah you'd want to talk to your provider about that particular issue; they have differing reasons for why they would reset that.

However, they may also be able to disable that if you were to explain that it's causing a problem.

As to whether chattr would resolve it, it depends on how they're going about overwriting those files. The provider is capable of ignore the chattr setting, so only they would know for sure.

And yeah we do recommend having "!27.0.0.1" in your /etc/resolv.conf file, though the setting "check resolv.conf for this system" doesn't affect how lookups are done. That particular setting only affects whether Virtualmin complains about the resolv.conf file or not.

The chattr command is part of the e2fsprogs package. It's normally installed by default, but if you don't have chattr you could try installing that.

Submitted by oneearth on Fri, 01/20/2017 - 12:19

thank you - i have installed e2fsprogs and now chattr is accessible.

question: what is this resolver address that they are inserting into /etc/resolv.conf? it's a different ip that is not my vps static ip. this is what they have to say about it:

Actually 208.87.241.170 is the resolver IP address which is present in /etc/resolver.conf. I will go ahead and change your configuration file to have Google's IP addresses, ie 8.8.8.8 and 8.8.4.4.

Submitted by andreychek on Fri, 01/20/2017 - 12:35

I'm not sure what IP address they are adding; you may want to talk to your host about that.

We recommend using 127.0.0.1 if your server needs to act as a nameserver.

If it does not need to act as a nameserver for your domains, then you can disable the BIND DNS feature, and you'll no longer receive a warning about what is or isn't in that file.

Submitted by oneearth on Fri, 01/20/2017 - 13:11

yes, i do want the server to act as a nameserver, so i want 127.0.0.1 in the config file.

the vps provider stuck in their resolver ip in /etc/resolv.conf so i have kept both:

[root@server ~]# vi /etc/resolv.conf
nameserver 127.0.0.1
nameserver 208.87.241.170
nameserver 8.8.8.8
nameserver 8.8.4.4
<code>
 
i've executed the chattr +i /etc/resolv.conf. that is successfully preventing /etc/resolv.conf from being overwritten upon reboot.
 
however, reboot still resets hostname. how can i stop this from happening?

Submitted by oneearth on Fri, 01/20/2017 - 13:16

to protect hostname upon rebooting, would it be another chattr command? eg.

chattr +i /etc/hosts

Submitted by andreychek on Fri, 01/20/2017 - 13:51

We'd really recommend talking to your provider about that.

If they're resetting the hostname, there may be a reason for that.

There's several networking related files it sounds like they're resetting, and changing those to +i could create a problem.

It's very unlikely that setting /etc/hosts to +i would resolve this issue though.