On 22/12/2011 18:58, richardvo...@gmail.com wrote:
To sync the DHCP-Leases to the secondary server, you need to create a
ssh-key (ssh-keygen) to copy the lease-file without knowing the ssh-passord.
scp 10.0.0.251:/var/dhcp/dnsmasq.leases /var/dhcp/dnsmasq.leases
Please note that by default, automatic DNS registrations and the list
of existing DHCP leases are going to be lost during failover.
Copying the dnsmasq.leases file with cron creates a race condition as
it is not synchronized with dnsmasq updating the file. I would
recommend using a external database to store the leases with support
for atomic updates instead of letting dnsmasq put them in
/var/*/dnsmasq.leases.
See the dhcp-script and leasefile-ro options.
Seems like there are two interesting opportunities for someone
sponsoring dnsmasq changes:
1) Atomic updates to the leasefile (or near enough for practical purposes)
2) Re-reading of the leasefile on change (in a way designed to support
use with a cluster filesystem or manual sync)
3) Some intra-dhcp communication mechanism designed to support high
availability, eg enhancing dhcp protocol to broadcast change events,
some kind of master server election (eg see netbios), or something more
sophisticated eg Paxos (see googles Chubby for implementation ideas)
The basic problem of having multiple overlapping dhcp servers is
desirable to solve for all dhcp servers, so any general solution would
ideally be simple and presented as an RFC so that we could get a cross
platform solution going... (thinking something simple involving
broadcasts to allow an election process... Technically leases don't need
to be sync'd, so separate process can handle that)
Cheers
Ed W
