Submitted by Locutus on Fri, 06/10/2011 - 03:52
I'm operating two production virtual machines, one with Virtualmin ("Orion"), one with a basic Webmin and BIND ("Gemini"), as secondary nameserver.
Gemini is configured as DNS Cluster Slave for Orion.
Creating and deleting vservers on Orion works (in terms of cluster DNS operation) all okay.
Renaming a domain though, through "Server Configuration -> Change Domain Name", fails to rename the zone on Gemini, despite the log text says it is going to do so, and does not report any errors. The zone simply still has the old name on Gemini afterwards.
If I should do further tests regarding this, please let me know!
Status:
Closed (fixed)
Comments
Submitted by JamieCameron on Fri, 06/10/2011 - 13:35 Comment #1
That's odd, I just tested this and it worked OK for me.
During the rename, do you see a message like "Changing slave domain on gemini" ?
Submitted by Locutus on Fri, 06/10/2011 - 14:15 Comment #2
Yeah, that message appeared. I just tested it again, with an unimportant production domain "tools.tianet.de".
Zone name and zone file (including contents) on Gemini stay like before.
Might the reason be that I'm using "ns2.tianet.de" as cluster slave host name instead of "gemini.tianet.de"? (Creating and deleting zones does work though, only renaming fails.)
Anything I can do to narrow down the cause? Might some Webmin debug logging details be interesting?
Submitted by JamieCameron on Fri, 06/10/2011 - 15:03 Comment #3
One thing to check is that at Webmin -> Webmin Servers Index -> gemini (edit), that "Fast RPC mode" is set to Yes. This requires that ports 10000 - 10010 be open on the slave.
Also, I would be interested to see the debugging logs from the slave system if possible. You can enable more detailed logging by adding the line rpcdebug=1 to /etc/webmin/config on the slave, trying a domain rename, then sending me what is logged to /var/webmin/miniserv.error at jcameron@virtualmin.com .
Submitted by Locutus on Fri, 06/10/2011 - 18:31 Comment #4
"Fast RPC mode" was already active; ports are all open since the two virtual servers have no local iptables, and the virtual router between their LANs allows traffic between the two LANs unrestricted.
Email with the requested log is on its way.
Another interesting thing to note: I just tried to rename the domain two times in a row,
tools.tianet.de
->tools2.tianet.de
->tools.tianet.de
.In both cases there was no error message for the "rename on slave" step, despite for the second rename, the slave zone with that name did not even exist.
When deleting zones, there is an error message when it is not found on the slave.
Submitted by JamieCameron on Sat, 06/11/2011 - 00:16 Comment #5
Thanks for the logs - it looks like the master system isn't even trying the rename, which could explain the behavior you are seeing.
If you look in the domain's file under
/etc/webmin/virtual-server/domains
, what does thedns_slave=
line contain?Submitted by JamieCameron on Sat, 06/11/2011 - 00:17 Comment #6
Thanks for the logs - it looks like the master system isn't even trying the rename, which could explain the behavior you are seeing.
If you look in the domain's file under
/etc/webmin/virtual-server/domains
, what does thedns_slave=
line contain?Submitted by JamieCameron on Sat, 06/11/2011 - 00:18 Comment #7
Thanks for the logs - it looks like the master system isn't even trying the rename, which could explain the behavior you are seeing.
If you look in the domain's file under
/etc/webmin/virtual-server/domains
, what does thedns_slave=
line contain?Submitted by JamieCameron on Sat, 06/11/2011 - 00:23 Comment #8
Thanks for the logs - it looks like the master system isn't even trying the rename, which could explain the behavior you are seeing.
If you look in the domain's file under
/etc/webmin/virtual-server/domains
, what does thedns_slave=
line contain?Submitted by JamieCameron on Sat, 06/11/2011 - 00:25 Comment #9
Thanks for the logs - it looks like the master system isn't even trying the rename, which could explain the behavior you are seeing.
If you look in the domain's file under
/etc/webmin/virtual-server/domains
, what does thedns_slave=
line contain?Submitted by Locutus on Sat, 06/11/2011 - 03:47 Comment #10
Yeah, from the debug log I indeed wondered if there was a rename command in there at all. It didn't look like it.
The requested line says:
dns_slave=ns2.tianet.de
I did those tests on my production system so far, but my experimental "Virtualmin Lyra / BIND-Webmin Ara" pair exhibits the same behavior. If it helps, feel free to do tests there to your liking; the login I sent you yesterday is for Lyra, and I can create a Webmin login and add your public key to root's authorized-keys on Ara if you'd like.
Also, you posted your last message 5 times. ;)
Submitted by JamieCameron on Sat, 06/11/2011 - 13:46 Comment #11
Yes, a remote login to the slave system would be really useful to debug this ... my SSH public key can be copied from /root/.ssh/authorized_keys on the system that you already granted access on.
Submitted by Locutus on Sat, 06/11/2011 - 15:57 Comment #12
SSH key is copied, and Virtualmin login data on its way to you via email!
Submitted by JamieCameron on Sat, 06/11/2011 - 16:43 Comment #13
Ok, thanks - I see the cause of this bug now, and have patch Virtualmin on your system with a fix. I will also include the fix in the next Webmin release (1.560).
Submitted by Locutus on Sat, 06/11/2011 - 18:52 Comment #14
Great!
Could you tell me the patch please, so I can apply it to my production server?
Submitted by JamieCameron on Sat, 06/11/2011 - 19:06 Comment #15
Just copy /usr/share/webmin/bind8/bind8-lib.pl to the other system.
Submitted by Locutus on Sun, 06/12/2011 - 06:30 Comment #16
Will do, thanks!
I compared the file on the two machines, and it looks to me like the bug indeed had something to do with the fact that I'm using a "custom" hostname for the DNS slave?
Submitted by JamieCameron on Sun, 06/12/2011 - 12:17 Comment #17
Yes, that was indeed the trigger.
Submitted by Issues on Sun, 06/26/2011 - 21:21 Comment #18
Automatically closed -- issue fixed for 2 weeks with no activity.