bind (Named) question

I upgraded my box from fc3 to fc4 all went well after I learned a bunch of stuff… hahaha BUT…

the bind mod (wibmin) always has "Start Named Server" button even tho named is running and virtualmin pukes on adding new virtual host on the named restart… virtualmin config check comes up OK but also shows the "Start Named Server" button even tho named is running.

Any idea how to fix this so everything will work right again???

BIND 9.3.1, under chroot /var/named/chroot
Apache version 2.0.54
PHP Version 5.0.4

thanks for any suggestions
Top

do a whereis named and make sure that bind module is looking at the new named if there is one

here is the shell info:

whereis named

named: /usr/sbin/named /etc/named.conf

#ps aux|grep named
named 1644 0.0 1.2 36552 2900 ? Ssl 07:12 0:00 /usr/sbin/named -u named -t /var/named/chroot
root 2904 0.0 0.2 3772 656 pts/0 R+ 07:24 0:00 grep named

rpm -qa|egrep -i bind

bind-chroot-9.3.1-20.FC4
bind-libs-9.3.1-20.FC4
bind-utils-9.3.1-20.FC4
bind-9.3.1-20.FC4

the bind mod in webmin Configuration is:
Full path to the named executable: /usr/sbin/named
start,stop,restart point to: /etc/rc.d/init.d/named (which works in shell)

must I uninstall Virtualmin & Webmin then re-install it to fix this problem??? everything else on the box is working fine with out a single down minute since the upgrade and cleanup of old stuff.

hope this helps

must I uninstall Virtualmin & Webmin then re-install it to fix this problem???

Goodness gracious NO! When your instincts tell you to “re-install”, in almost every case your instincts are horribly wrong. Think of all of the troubles you’d run into having to recreate all of your domains in Virtualmin (or re-import them and remember all of the right settings, or recover from backup if you’re keeping good backups). Never fun, regardless of how good your backups are. :wink:

The problem is probably that Webmin is looking in the wrong place for the PID file–things often move around between versions of Fedora, and this could be one of them. Webmin, I believe, uses PID to determine whether BIND is running (though rndc is also probably involved, and you should check to be sure rndc works and the path in the Module Config is correct as well). So, make sure the PID path is correct, and check rndc.

rndc status

If this fails, then BIND is broken in some way, and I suspect Webmin will have a lot of troubles, but we’ll cross that bridge when we come to it…let us know what you find out, and we’ll help you get it straightened out.

hi Joe, I have no idea what this is but it is a cool command… something to add to my list of good comamds…hahahaha…

rndc status

number of zones: 12
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/1000
tcp clients: 0/100
server is up and running

I guess since it returned with the number of zones it shows that bind is running fine.

and will not a “remove & re-install” of webmin & virtualmin just pickup all the domains and server packages on it’s own???

other than reboots the server has been running fine so far. (no mail drops, no failed web pages, no problem adding packages, etc.)

Hey William,

I guess since it returned with the number of zones it shows that bind is running fine.

Yep, rndc looks good here–we weren’t trying to figure out if BIND was running, since I think we’d already established that it was, we were trying to figure out if rndc worked correctly (Webmin uses it for quite a few things).

The other bit I mentioned is probably the culprit in your case.

Find the named.pid file using locate:

locate named.pid

It’s probably within a chroot, like so:

/var/named/chroot/var/run/named/named.pid

And so, the path according to Webmin (found in the BIND Module Config) will be:

/var/run/named/named.pid

Since Webmin should already know about the chroot.

and will not a “remove & re-install” of webmin & virtualmin just pickup all the domains and server packages on it’s own???

Nope. No way it could. The domains will continue to run–because Virtualmin merely configures them (mail might stop delivering, however, since the procmail configs for domains are stored in the Virtualmin configuration directory), but the Virtualmin data about them will be lost if you remove Virtualmin. Virtualmin isn’t like Webmin, where the vast majority of “work” you do happens in the configuration files of your software. It has it’s own quite large set of configuration data that it keeps up with, as it must to keep up with your domains, mail settings, templates, etc. for you.

If you have backups of the Webmin configuration directories, then you can restore the data easily (it’s small–no reason not to keep a separate backup of this data). But you’d probably also be restoring the configuration that is wrong in the case of your BIND problem! :wink:

This is merely a configuration problem. Nothing major, nothing difficult to fix, certainly nothing that requires doing drastic measures like restoring from backups or reinstalling. We just need to figure out which path Webmin has wrong, and correct it.

Thanks Joe…found it…
it was in the webmin bind config…
the "Default PID file location(s)" had it at:
/var/run/named.pid

but it was at:
/var/run/named/named.pid

if I had know this was the path "AFTER" the chroot I might have found it on my own. as it was I just keep changing the path, then putting them back, until it worked right.

Thanks for all your help… I guess I have a running box again… I just added a sub for one of my domains and it is up and working…