Renaming a BIND zone on slave nameserver fails when "changing domain name"

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

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" ?

Yeah, that message appeared. I just tested it again, with an unimportant production domain "tools.tianet.de".

Changing domain name to tools2.tianet.de ..
Changing home directory to /home/tianet.de/domains/tools2.tianet.de ..
 
 Moving home directory ..
 .. done
 
 Changing DNS domain name ..
 .. done
 
 Changing slave domain on ns2.tianet.de ..
 .. done
 
 Updating mailbox users ..
 .. done
 
 Changing home directory in website configuration ..
 .. done
 
 Changing hostname of virtual website ..
 .. done
 
 Updating home directory in PHP configuration ..
 .. done
 
 Updating log file path in Logrotate configuration ..
 .. done
 
 Updating user and group in Logrotate configuration ..
 .. done
 
 Updating paths in script database ..
 .. done
 
 Re-starting DNS server ..
 .. done
 
 Re-starting slave DNS servers ..
 .. done
 
 Applying web server configuration ..
 .. done
 
 Saving server details ..
 .. done

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?

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 .

"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.

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 the dns_slave= line contain?

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 the dns_slave= line contain?

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 the dns_slave= line contain?

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 the dns_slave= line contain?

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 the dns_slave= line contain?

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. ;)

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.

SSH key is copied, and Virtualmin login data on its way to you via email!

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).

Great!

Could you tell me the patch please, so I can apply it to my production server?

Just copy /usr/share/webmin/bind8/bind8-lib.pl to the other system.

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?

Yes, that was indeed the trigger.

Automatically closed -- issue fixed for 2 weeks with no activity.