BIND DNS Server is uninstalled after the last upgrade

Submitted by yngens on Thu, 02/06/2014 - 16:57

After the last upgrade of Virtualmin, all servers sent this alert:

Monitor on host.domain.tld for 'BIND DNS Server' has detected that the service is uninstalled at 06/Feb/2014 12:30

Logging to any Virtualmin UI shows BIND is down. Restarting doesn't help. Nevertheless all the websites are working just fine. This means BIND is there, but Virtualmin UI and the last version of BIND are not connected.

Status: 
Closed (fixed)

Comments

Submitted by yngens on Thu, 02/06/2014 - 17:35

Rechecking Virtualmin's configuration gives:

Checking Configuration
The status of your system is being checked to ensure that all enabled features are available, that the mail domain is properly configured, and that quotas are active ..
Your system has 1.48 GB of memory, which is at or above the Virtualmin recommended minimum of 256 MB.
The BIND DNS domain version 8 or 9 does not appear to be installed on your system, or has not yet been set up properly in Webmin's BIND DNS Domain module. If your system does not use BIND, it should be disabled in Site Manager's module configuration page.

.. your system is not ready for use by Virtualmin.

Running "named -ver" gives:

named -ver
BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6

If I click on "BIND DNS Domain" link (goes to https://xxx.xxx.xxx.xx:10000/bind8 by the way, when Bind is already is of version 9.x), then it shows:

BIND DNS Server
BIND version 9.8.2, under chroot /var/named/chroot Start BIND
Search Docs..
The primary configuration file for BIND /var/named/chroot/etc/named.conf does not exist, or is not valid. Create it?

Setup nameserver for internal non-internet use only
Setup as an internet name server, and download root server information
Setup as an internet name server, but use Host Manager's older root server information

I am not confused here as never used chroot. Should I just proceed? And this issue came up on all our Virtlamin servers, on which last updates took this morning, so I really hope Virtualmin will release another update to fix this. I hope we will not be fixing this manually on tens of our Virtualmin servers.

Submitted by yngens on Thu, 02/06/2014 - 17:41

Further findings...

So, I have proceeded with default option selected (i.e. Setup as an internet name server, and download root server information) and it output:

Error
Download failed : Failed to open /var/named/chroot/var/run/named/named.pid for writing : No such file or directory

Firing 'locate named.pid' commands gives:

locate named.pid
/var/run/named.pid
/var/run/named/named.pid

So it should be looking for named.pid in /var/named/chroot/var/run/named? And why my systems have duplicate 'named.pid' files now in /var/run/ and /var/run/named/?

Submitted by yngens on Thu, 02/06/2014 - 18:00

Comparing a server that was not updated this morning with fully functional server Bind shows:

BIND DNS Server
BIND version 9.8.2

while on the corrupted one it shows:

BIND DNS Server
BIND version 9.8.2, under chroot /var/named/chroot

Submitted by yngens on Thu, 02/06/2014 - 18:08

I went to the module configuration page and changed

(1) "Chroot directory to run BIND under" from

/var/named/chroot to none

(2) "Command to find chroot directory" from

sh -c '. /etc/sysconfig/named && echo "$ROOTDIR"' to "Use fixed directory above". And it has given the following warning:

BIND DNS Server
BIND version 9.8.2 Apply Configuration
Stop BIND
Search Docs..
Warning : Webmin thinks that BIND is not using a chroot directory, but that may be incorrect. The zone files for 5 domains could not be found.

Make sure that the chroot directory is set correctly on the module configuration page.

Global Server Options

However, at least now finally Virtualmin configuration check can pass validation. I hope this change doesn't break anything on the server.

Why the last update would change this on ALL our Virtualmin servers without our consent?! We have dozens and dozens of Virtualmin servers and after the last upgrade all of them are facing the same issue. Are we supposed to fix this manually on all of them or Virtualmin will release a fix? And if the first, then what is the most correct way of solving this? Are above steps correct ones?

Submitted by JamieCameron on Thu, 02/06/2014 - 21:46

The latest Webmin update changed the way the chroot directory is detected on some systems. It doesn't actually effect the active BIND configuration in any way, but may need some configuration changes to be properly recognized.

Does the file /etc/named.conf exist on your system? And if so, do the zone files referenced inside it also exist?

Submitted by yngens on Thu, 02/06/2014 - 21:54

Yep, /etc/named.conf exists and contains all the zone files references. I just never used chroot. Will it become default from now on?

Submitted by JamieCameron on Thu, 02/06/2014 - 22:20

How many zones do you have in your named.conf file? Webmin's error said that 5 are missing, but I am wondering if that is your zones or just some of them?

Submitted by yngens on Thu, 02/06/2014 - 22:32

Jamie,

The problem is not about one particular server as we are observing exactly the same issue on all Virtualmin instances, which had been updated in the morning through Cloudmin UI. The number of zone referenced above is irrelevant. Please read above how I addressed the issue - I had to revert two settings in Bind configuration page to the default ones, because for the last Virtualmin update set them as if I was using chrooted DNS. And I never did. I am afraid I might be the first one to report this issue, but surely am not the only one. Virtualmin update should've not changed Bind settings.

Now I am not sure what should we do with this issue - should we proceed editing Bind settings manually on each Virtualmin server or there will be another release fixing this one?

Submitted by JamieCameron on Thu, 02/06/2014 - 23:08

So there appear to be two issues here - the configuration check failure in Virtualmin, and the warning "Webmin thinks that BIND is not using a chroot directory". Disabling use of chroot on the Module Config page is the correct way to fix the first problem.

As to how this happened, I'm still uncertain as by default on a CentOS / RHEL 6 install those options are not set. Prior to the Webmin 1.675 release there was special-case code to ignore them on CentOS 6 as they were often set un-necessarily, but that code was removed to simplify Webmin.

Were your systems perhaps upgraded over time from an older version of Webmin and Virtualmin?

Submitted by yngens on Thu, 02/06/2014 - 23:28

I doubt our systems had been upgraded from an older version of Webmin and Virtualmin since we run updates quite regularly. But everything is possible.

I will wait just in case if other Virtualmin users will start reporting the same issue.

Thanks for clarifying. Now I know that we can start manually fixing all other servers in correct way.

Submitted by JamieCameron on Thu, 02/06/2014 - 23:33

What I was wondering if which version of Webmin you had when you first installed Virtualmin?

Submitted by yngens on Thu, 02/06/2014 - 23:51

Jamie,

Unfortunately, I can't tell that because this issue is being observed on ALL Virtualmin instances which were deployed at different time frames during last couple years on DIFFERENT Cloudmin servers. All of them have been updated regularly through Cloudmin UI. So I believe they all had last, but one version of Vertualmin prior the last upgrade.

Submitted by yngens on Thu, 02/06/2014 - 23:55

In fact, I've found one of the Virtualmin servers that had not been updated yet. So I logged in and made sure Bind is running just fine. The version were:

Webmin version 1.660 Virtualmin version 4.04.gpl GPL

Then I've updated the available packages through Virtualmin UI:

Update Packages
Now updating webmin ..
Installing package(s) with command yum -y install webmin ..
Loaded plugins: fastestmirror, presto, priorities
Loading mirror speeds from cached hostfile
* base: ftp.plusline.de
* epel: mirrors.n-ix.net
79 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package webmin.noarch 0:1.660-1 will be updated
---> Package webmin.noarch 0:1.675-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package       Arch          Version          Repository                   Size
================================================================================
Updating:
webmin        noarch        1.675-1          virtualmin-universal         21 M

Transaction Summary
================================================================================
Upgrade       1 Package(s)

Total download size: 21 M
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 21 M
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction

And now I have:

Webmin version 1.675 Virtualmin version 4.04.gpl GPL

with Bind down. I am telling you that this is not only me. I am pretty sure soon everybody else will start complaining about this issue. The last update is changing the Bind settings.

Submitted by JamieCameron on Fri, 02/07/2014 - 01:21

Do you happen to know when that system was first installed? The cause of this may be an old configuration setting that is being preserved from older Webmin versions, but is not present on systems that have been recently freshly installed.

Submitted by yngens on Fri, 02/07/2014 - 05:22

Now I see what you mean. All those Virtualmin instances indeed have been deployed from an old image. Does this mean we need to fix this manually on each machine?

Submitted by JamieCameron on Fri, 02/07/2014 - 11:39

Yes - also, I'd advise fixing the settings in the image.

Submitted by yngens on Mon, 02/10/2014 - 23:00

Done, thanks for the advice. Changing this to closed.