These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for New update today had strange effect on BIND on the new forum.
Web Hosting and Cloud Computing Control Panels
I have this same inssue ( Bind won't work, after lastest upgrade).
I can't restore existing virtual servers, restore hanging up on DNS records :(
Error, when i want to start DNS is - already working :(
Please help.
Say what information do you need.
I did the latest Virtualmin 3.52 packages update yesterday on my Centos Linux 5 server. Everything is still running properly externally at least. But today I noticed in my Bind DNS server:
-------------------- Start Error Message --------------------------
BIND version 9.3.3, under chroot /var/named/chroot
The primary configuration file for BIND /var/named/chroot/etc/named.conf does not exist, or is not valid. Create it?
--------------------- End Error Message ------------------------
I did some searching in this forum.
For trouble shooting Joe advised someone to type :
mdc status
When I did this I got "command not found"
Joe asked the person to type
locate named.pid
When I did this I got:
/var/run/named.pid
/var/run/named/named.pid
I know Joe said something about it being "chrooted", but I don't know anything about this. (I'm more of an applications programmer.) Could someone give me some suggestions on how to fix this before something really bad happens? ;-{
Here's my /var/named/chroot/etc/named.conf file:
options {
directory "/etc";
pid-file "/var/run/named/named.pid";
};
zone "." {
type hint;
file "/etc/db.cache";
};
There was a change in Webmin 1.400 in how it detects which directory BIND is chroot'd to. If you are using an unmodified install of CentOS, Fedora or RHEL then this shouldn't cause any problems, but if you have modified the chroot directory then Virtualmin may fail to detect that BIND is installed.
This doesn't actually break the BIND configuration - the problem is just in how Webmin finds it.
To fix it, do the following :
1) Find out what chroot path BIND is using on your system. This is usually in the /etc/sysconfig/named file, in the ROOTDIR= line. If it is not set or commented out, then no chroot is being used.
2) Login to Virtualmin, and go to Webmin -> Servers -> BIND DNS Server, and click on the Module Config link.
3) In the 'Chroot directory to run BIND under' field, enter the correct path. If you are not running chroot'd, select None. Then click Save.
Virtualmin's configuration check should now pass.
We plan to release a 1.401 version of Webmin shortly that will also fix this problem.
--
Check out the forum guidelines!
I'm using centos, but yeah I knew it was the new update's fault ;)
The config check was passing already, oddly enough.
For some reason there were several chroot settings in the config that I noticed, I did end up setting no chroot. I changed a bunch of other things as well, had to declare my zones within the named.conf file for some odd reason, which I didn't have to do previously.
Anyway, things are working now. Your fix would've been nicer to have a few hours ago ;)
Thanks!
Hi Jamie,
I have your "Managing Linux Systems with Webmin" book. I don't know how I missed your post above. ;-)
I was formulating a reeeely, reeeely complex question, when I saw that jamie had the webmin 1.401-1 update out there. I installed it on my Centros 5.x server and it fixed the Webmin BIND display problem. I noticed that it did not change any of the settings in the Webmin's Bind DNS->Module Config .
Is the server running from the BIND module? Or are you referring to the START/STOP button on the VM theme system info page? I can't replicate the problem. Try rebooting the server
The Virtualmin update wouldn't have caused this.
But, we did see a bug report in the tracker about BIND switching to chroot mode--it turned out that some package changes in the Debian 4.0 (I think) OS repository (i.e. not ours) had switched their system over to using a chrooted BIND. Webmin and Virtualmin supports this, but you have to tell Webmin about the change in the BIND module configuration.
--
Check out the forum guidelines!
I don't say that.
I'm using:
Operating system CentOS Linux 5
Webmin version 1.400
Virtualmin version 3.50.gpl (GPL)
regards;
After work, i'm try to get now does bind working.
I'm seeing the exact same issue. At some point something changed and webmin asked me to setup BIND again. There was an error saying BIND was already running, and then webmin thought BIND was chroot'ed. This caused webmin not to be able to find my zone files, changing the module config solved this and no data was lost.
I'm using Centos 5 with VM Pro, i've seen this error on 4 boxes and on my Centos 5 & VM GPL dev box
I noticed that when i try and apply changes to a zone i get this error
[size=4]VM PRO[/size]
[code:1]NDC command failed : rndc: connect failed: 127.0.0.1#953: connection refused[/code:1]
Also
[code:1]> rndc status
rndc: connect failed: 127.0.0.1#953: connection refused
[/code:1]
And
[code:1]> locate named.pid
/var/run/named.pid
/var/run/named/named.pid[/code:1]
[size=4]VM GPL[/size]
[code:1]> locate named.pid
/var/named/chroot/var/run/named/named.pid
/var/run/named.pid
[/code:1]
The following has been added to /etc/sysconfig/named
[code:1]ROOTDIR=/var/named/chroot[/code:1]
Hopefully thats of some use :)
Mine is working (had to reconfigure bind), but now I can't start/stop using the virtual interface.
How do I tell Virtualmin to use a chrooted bind?
I'll search the forums in the mean time.
I just had to overhaul my named configuration, I'm not sure if it works yet. I had to unconfigure all the chroot stuff. Installing bind-chroot did not fix it, but instead broke bind and it wouldn't start at all.
Could this be a major bind installation issue?
I'll report back after my changes propagate.
In the News forum, In the replies to the announcment for virtualin V 3.52, other folks are talking about this problem. Go there, if this link does not work.
http://www.virtualmin.com/forums/news/virtualmin-virtual%11server-3.52.html
I hope Joe comes up with an authoritative reply. Knowing him, there is probably some simple tweak....
See my post above - since it was my bug that caused this, you can consider my fix authoritative :-)
--
Check out the forum guidelines!