Forcing update of bind tables

[catdude]

I am running ISPConfig on two servers. My coworker has configured MySQL to perform master-master replication between the servers. This is working quite nicely so far.

However, last night we spotted a problem. My two servers are named ga and ge. If I log in to ge and update a DNS entry, I can see the update reflected in ga's database (as shown by going into DNS Manager on ga). However, the bind tables on ga are not getting updated when the database gets updated. The bind tables only get updated on the machine on which the update is performed.

I am looking now at how to extract all DNS info using the remoting framework, and possibly rebuilding all of bind's tables that way. What I would like to know is if there is a simple way to tell ISPConfig "rebuild all of bind's tables using your current database contents".

[till]

A master-master replication between two ISPConfig configurations can never work, as the second server will not know which config files will be updated as the configuration daemon on the primary server resets the status when he is finished.

The esaiest solution to synchronize two servers with ISPConfig 2 is to synchronize the bind config files with rsync.

ISPConfig 3 will support multi server setups where you may have multiple dns, mail, web and database servers incl. replication from one interface, but ISPConfig 2 is build to be used on single servers, thats why it is not so easy to replicate the data.

[catdude]

Originally Posted by till

A master-master replication between two ISPConfig configurations can never work, as the second server will not know which config files will be updated as the configuration daemon on the primary server resets the status when he is finished.

The esaiest solution to synchronize two servers with ISPConfig 2 is to synchronize the bind config files with rsync.

ISPConfig 3 will support multi server setups where you may have multiple dns, mail, web and database servers incl. replication from one interface, but ISPConfig 2 is build to be used on single servers, thats why it is not so easy to replicate the data.

Ok, how about this method: I'm thinking we could use ge as the live machine; users would use ge for mail, admins would log in to ge, etc. Ga would then be a hot backup machine. An rsync script could keep the named zone record files current, with reloads performed when changes are actually detected/transferred. Our Cisco GSS could most likely be configured to take care of the actual failover.

And as a related issue, when ISPConfig 3 is available, do you expect it will be possible to upgrade from version 2, as opposed to a clean install with mysqldumps, etc?

[till]

Originally Posted by catdude

Ok, how about this method: I'm thinking we could use ge as the live machine; users would use ge for mail, admins would log in to ge, etc. Ga would then be a hot backup machine. An rsync script could keep the named zone record files current, with reloads performed when changes are actually detected/transferred. Our Cisco GSS could most likely be configured to take care of the actual failover.

I guess this should work!

And as a related issue, when ISPConfig 3 is available,

I hope to get out a first bet version soon and the final might be available at the end of the year.

do you expect it will be possible to upgrade from version 2, as opposed to a clean install with mysqldumps, etc?

ISPConfig 3 is a completely different system written from scratch and has other system requirements then ISPConfig 2. A direct update will most likely not possible. We will provide some kind of importing tool to migrate ISPConfug 2 instalations to ISPConfig 3.