Persiste DNS servers on Reboot in Hostname and DNS Client tab.

In tab Hostname and DNS Client, add a feature to persist DNS settings on reboot.

A check box with text similar to: Persist DNS Servers on Reboot

Then using SED or something, search rc.local (for CentOS) for persist line below and add or replace it:

echo -e "nameserver $DNS_1\nnameserver $DNS_2\nnameserver $DNS_3\nnameserver $DNS_4" > /etc/resolv.conf

Where $DNS_1 - 4 are the the actual variables for the DNS settings on this page, a check to see if 127.0.0.1 is one of them is required.

On a lot of hosted VPS accounts, this can be a pain to resolve for some users, this option should work on any server that uses /etc/resolv.conf, and can be modified to work for systems with other ways to accomplish same task, so care needs to be taken for each supported OS, to deal with OS dependent issues.

There are other ways to accomplish this, but I have found this method works and will not break anything, its only run on boot, so it has little impact on startup time, and will not hurt systems that do not require this, meaning that the server does not overwrite this file on reboot, as is the case with a lot of hosting companies, and placing it in rc.local ensures it gets ran after the server starts up, so the system can overwrite the file before this command runs, preventing it from being stepped on.

This is one major requirement for being able to use this panel on hosted VPS accounts like myhosting.com which uses Virtuozzo, so when it fails System Settings -> Re-Check Configuration, which is every time you install it, the user will see the option to persist setting on reboot, this saves countless questions on how to fix this issue, and its always an issue if you use Virtuozzo, you can also add a note to explain why you want to do this, as well as give you a place to undo it if you are not using the DNS server.

Unchecking it should remove this line if it exist.

Reference: https://virtualmin.com/documentation/dns/faq

Also note that you do not want to write protect this file on Virtuozzo systems, it will lock the VPS up, and you can not even ssh in to fix it, making it far better idea to add a feature to correctly fix this issue for each OS and system type, rather then having the user try to fix it, making this not only a feature request, but a required feature.

Thanks

Status: 
Closed (fixed)

Comments

Is your VM perhaps using DHCP for address assignment? If so, switching to a fixed IP may be a better solution .. adding a script to /etc/rc.local seems like a hack, and would confuse other tools that change nameservers.

My problem is that the Virtuozzo VPS server writes to resolve on boot up, it drops the 127.0.0.1 every time, so when I System Settings -> Re-Check Configuration, if fails telling me to add 127.0.0.1 In tab Hostname and DNS Client, which fixes it till next reboot, when Virtuozzo overwrites the file again, trying to fix it on that end, has been an uphill battle, and has crashed the server many times, so the only way I found to get around this behavior is to overwrite the file, I have ran into this issue with every VPS host I have tried, which have been a lot... but do not have this issue on my own server, just the VPS accounts, specifically those using VM's like: OpenVZ or Virtuozzo.

For Hosting on VPS using Virtuozzo, installing Virtualmin needs to work out of the box, so weather this is a hack or not is another question, but all we are talking about here is updating the resolve file on boot up, I do not see any harm in that, so I would not call it a hack, but lets face it, Virtuozzo is why we are doing this, so this is a work around that issue.

cpanel does not have this issue, do not know why that is, but I know its why tech support at with my ISP knows about this issue, and doesn't recommend it for this reason alone, which makes it hard to sell them on the idea of supporting it, since they have to fix this issue, I did not get any other complaints from them, other then this issue, so I thought I would try to get it resolved, so I can approach them again, but they need to be able to install it and get all checks to pass with minimal effort, my solution is simple, if it fails, it takes them to a this tab as normal, only it now has a feature to check that will update the rc.local file on save only, no reason to do it unless you change the DNS server names, but the rc.local file will update the system every reboot, so it will pass the check every time.

One other option would be to configure Virtualmin to not report a warning when 127.0.0.1 is missing from resolv.conf. The only possible issue with this could be that newly created domains will not be accessible from the system itself until they are properly registered with a registrar..

How do you configure it to not warn for 127.0.0.1 missing?

You can set that in System Settings -> Virtualmin Config -> Advanced Settings, and in there you can change "Check resolv.conf for this system" to "No".

Didn't know that, if there isn't much advantage, then why set it on by default?

Here I thought this was an issue.

Well, that's not the first choice... not having 127.0.0.1 in your /etc/resolv.conf requires an additional DNS lookup when performing queries regarding domains you host.

It first has to ask your provider's nameservers to perform a lookup of a domain hosted on your server, and when they don't have that info, those nameservers will in turn query the DNS service on your own server.

Having "127.0.0.1" in the resolv.conf skips the step of querying your provider.

However, it will indeed work either way.

I suspect the other control panels you're referring to simply don't complain when this occurs.

When Virtualmin initially added the check of /etc/resolv.conf some years back, the typical reason 127.0.0.1 went missing was that folks using DHCP were inadvertently overwriting it with nameservers they didn't mean to use.

At the time, we weren't considering that providers at some point might intentionally overwrite it!

But for folks in your predicament, Jamie added an option to skip testing /etc/resolv.conf.

I've added it to my notes to explore the idea of doing that by default on OpenVZ systems. Although not all OpenVZ users seem to run into that, enough do that it may be beneficial to skip testing that by default. Or maybe just offer a link to that page when running the Re-Check Config on an OpenVZ system.

I still think my method, be it a hack, is a better alternative, I would let the web-master decide by giving them two choices, one to turn the check off, the second to write the updates to rc.local.

My option has just gotten stronger support, since all we are doing is updating the file with the correct settings, you could add a ping test to make sure the servers answer, or do a reverse proxy and other test to test the servers, other then that, I do not see the down side to my solution, it works great on three servers so far, and should work on all CentOS server, not sure about all the others you support.

As it is... this is the only correct solution to fixing this issue on OpenVZ at this time, that may change in the future, but this hack will still work.

Maybe you can find a test to see if this system is using OpenVZ, but it is a problem that requires and easier way to resolve it, even it that means duplicating the setting to turn off the check at the page in mention, so the user doesn't have to dig through the forums to find an answer, it should all be on the page you sent them to - to fix this issue.

But to just turn it off, knowing it has a very limiting DNS issue, is not the right thing to do, and you know that, if nothing else, let them know about this alternative method, even if you do not implement it, because its a hack, I have been a Computer Programmer since 1972, in 20 years of Programming for the Government, I found a Hack is an Undocumented Fix, and nothing more, and after you document it, its not a Hack, but a fix to another Problem, which was normally was a Hack in itself, and is in this case, since the system was written like this to support Dynamic DNS servers, by testing to see what servers in the DNS pool are up at the time of reboot, and writing those servers into the resolve file, and it does works, and allows the system to update the DNS servers before the system starts up, in case a DNS server(s) go down during a reboot, you might call that a Hack, but it was a design concept that works well for them, and may break more servers by removing this feature built into OpenVZ, if those servers change during a reboot, so I would recommend adding at least one public DNS server into the 4 DNS servers, along with 127.0.0.1, you could add two more slots for Public DNS servers and localhost IP, this will solve this problem, you can add a DNS server test to the check configuration test, this way its not a hack, but a design concept, document it, then its not a hack, but a solution to problems that effect every hosting environment using OpenVZ or this type of Dynamic DNS server resolve rewrite on reboot scheme.

I am on Static IP, just to clarify.

This issue plagues your Forums, and it will continue to until you fix it, its a problem let face it, and only a problem to those using OpenVZ, which is becoming very popular, so you can not ignore it any longer, the fix is easy, and solves more issues then it can cause.

If I add 2-4 DNS servers from my Hosting Provider, chances are one will be up, then 1 Public DNS Server and localhost IP at the end, I should never have a DNS issue, I could also try to get OpenVZ to add in the localhost IP, this has been brought up many times, with no fix in sight, but they should, but until that fix gets done, this is still an issue, and this fix will still work after the fix, since its only going to give you this option if you chose it or require it, or if you want to use the DNS servers of your choice and not their's, making this a Feature and not a Hack.

Its hard to argue with Logic like that...

Figured this out, no idea why it is still open.

Thanks