[Maintain-dev] [JIRA] Closed: (MNT-1381) Allow multiple failover peers

Frederic Wenzel (JIRA) jira at osuosl.org
Mon Apr 3 16:07:17 PDT 2006

     [ http://bugs.osuosl.org/browse/MNT-1381?page=history ]
Frederic Wenzel closed MNT-1381:

      Assign To: Frederic Wenzel  (was: Michael Clay)
     Resolution: Fixed
    Fix Version: 3.0

MT3 allows an arbitrary number of servers now.

> Allow multiple failover peers
> -----------------------------
>          Key: MNT-1381
>          URL: http://bugs.osuosl.org/browse/MNT-1381
>      Project: Maintain
>         Type: Improvement
>     Versions: 2.4.0
>  Environment: Patch tested on: RedHat Enterprise Server 3.0
>     Reporter: Greg Connor
>     Assignee: Frederic Wenzel
>     Priority: Minor
>      Fix For: 3.0
>  Attachments: README.wg-failover-patch
> We have have 4 dhcp servers, one primary, and three secondaries, corresponding to the different regions.  The proposed patch allows any number of dhcp servers, not just "primary" and "secondary", and also generates multiple dhcpd.conf.data files (each intended to be read by two dhcp servers)
> ISC dhcpd supports multiple secondaries, but it's kind of a pain... you have to change 'failover peer "dhcp"' to some specific name that matches one of the failover stanzas in the peer file.  And, you have to split up the data file so that each server only sees the subnets assigned to it, and cannot see subnet declarations if it is neither primary nor secondary.
> See proposed patch here: http://lists.osuosl.org/pipermail/maintain-dev/2005-July/000102.html
> (Note that the proposed patch applies to this feature req, and also to MNT-1380.  It's possible to do MNT-1380 (Associate subnets with workgroups) by itself, but I would not recommend doing this one (Allow multiple failover peers) without doing MNT-1380 first or at the same time.  If Subnets are not somehow related to Workgroups, then more UI changes would be needed to tell Maintain which Subnet goes with which peering scheme.)
> The proposed patch also renames some of the config files, so it should be applied with care and not pushed as is to users as an update.  With a bit of tweaking, it can be made to use "primary" and "secondary" files if the feature is not activated in config, and use dhcpd.config.${hostname} if the user enters the new config option, but the patch I prepared uses just the new naming scheme.
> Old naming scheme:
> dhcpd.conf - same on all servers
> dhcpd.conf.primary - shipped to "primary" server as "dhcpd.conf.peer"
> dhcpd.conf.secondary - shipped to "secondary" server as "dhcpd.conf.peer"
> dhcpd.conf.data - auto-generated
> New naming scheme:
> dhcpd.conf.${hostname} - shipped to ${hostname} as dhcpd.conf
> dhcpd.conf.data - auto-generated, includes hosts, and any subnets without dynamic ranges
> dhcpd.conf.groups/* - shipped to all machines, but should only be included by certain hosts
> dhcpd.conf.groups/dhcpd.conf.peer.dhcp1-dhcp2-primary - Peer file for "dhcp1-dhcp2" scheme
> dhcpd.conf.groups/dhcpd.conf.peer.dhcp1-dhcp2-secondary - Peer file for "dhcp1-dhcp2" scheme
> dhcpd.conf.groups/dhcpd.conf.data.dhcp1-dhcp2 - Data file for subnets tagged as "dhcp1-dhcp2"
> I have the patch running on our production server.  OK to contact me at "gconnor at sgi.com" or "gconnor at nekodojo.org" with questions or comments about the patch.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

More information about the Maintain-dev mailing list