dhcp-users Digest, Vol 165, Issue 6

Patrick Trapp ptrapp at nex-tech.com
Fri Jul 15 17:46:29 UTC 2022 

I inherited a three-host system, so I take no credit for this design. The staging system is where I make all of my changes and test the configuration (done via a script). If the script indicates a success, a second script updates the configuration on production #1 and restarts it, then updates the configuration on production #2 and restarts it.

It's pretty painless and allows us to manage an independent DHCP infrastructure for thousands of customer-facing devices without having to muddy the waters of the DHCP of our corporate infrastructure, which is handled by a completely different Windows-based team.
________________________________
From: dhcp-users <dhcp-users-bounces at lists.isc.org> on behalf of Gregory Sloop <gregs at sloop.net>
Sent: Friday, July 15, 2022 12:35 PM
To: Ryan Shea <ryan at muppethouse.com>; dhcp-users at lists.isc.org <dhcp-users at lists.isc.org>
Subject: Re: dhcp-users Digest, Vol 165, Issue 6


CAUTION: This email originated from outside of the company. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Top posting...



I think many of us use the same concept...



I treat the one of my servers as "primary" and make all changes to it (and never the "secondary" peer).

I have a bash script that runs a syntax check, pauses for confirmation, restarts the primary [Testing!? I don't need no stinkin' testing, sheesh! :) ] and then rsyncs the conf files to the peer and restarts the peer.



Pretty easy and painless. [As long as that testing I skipped works out ok.]



And using a script makes sure I don't skip or miss (or even forget how to do) a step.

You know, like make changes and then get distracted by some shiny object and forget to sync the peer and restart it.



-Greg






Ahh, so I'm not a unique snowflake. I did actually already separate out the static host definitions into a separate file. My process for updating the file (which is a somewhat frequent operation) is

  1.  update one of the files
  2.  test the config `dhcpd -t -cf dhcpd.conf`
  3.  reload the daemon
  4.  scp to the secondary
  5.  reload the daemon
  6.  hope that you don't miss any of these steps

Let's compare this to our friends running an active-directory integrated built-in Windows DHCP server.

  1.  They clickity click on a thing to add a new reservation.
  2.  There is no step 2

I suppose my take-away is that this is not a user journey I should expect dhcpd to be helpful with. If we're off in roll-your-own territory, I was thinking that using Syncthing to keep the configs automatically in sync, along with some manner of cron job or inotifywait to trigger the secondary to reload would probably work fine. To me, this seems such a common operational pattern that making everyone do their own dental work seems not so terrific - but yes I can come up with something that can work better than manual tomfoolery.

On Fri, Jul 15, 2022 at 8:05 AM <dhcp-users-request at lists.isc.org<mailto:dhcp-users-request at lists.isc.org>> wrote:
Send dhcp-users mailing list submissions to
        dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
        dhcp-users-request at lists.isc.org<mailto:dhcp-users-request at lists.isc.org>

You can reach the person managing the list at
        dhcp-users-owner at lists.isc.org<mailto:dhcp-users-owner at lists.isc.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."


Today's Topics:

   1. Failover + Static host definitions (Ryan Shea)
   2. Re: Failover + Static host definitions (Richard L. Hamilton)
   3. Re: Failover + Static host definitions (Glenn Satchell)


----------------------------------------------------------------------

Message: 1
Date: Thu, 14 Jul 2022 10:51:04 -0400
From: Ryan Shea <ryan at muppethouse.com<mailto:ryan at muppethouse.com>>
To: dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>
Subject: Failover + Static host definitions
Message-ID:
        <CAL6QW496AknMABKu2874L=MSWvWp_Q9THoUm8QLQnnOjPhO=TQ at mail.gmail.com<mailto:TQ at mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

Failover of a pool seems straightforward enough - however this is
insufficient in the case where static reservations are present in host
definitions. I am looking for some solution by which I have a redundant
pair of dhcpd services which can not only fail over leases from a pool, but
also keep those hosts with static reservations working.

Is this as simple as synchronizing the host config definitions and running
both services - without any particular concern about which server replies?
Manually managing host configs for reservations in two places seems
sub-optimal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220714/12157430/attachment-0001.htm>

------------------------------

Message: 2
Date: Thu, 14 Jul 2022 11:22:13 -0400
From: "Richard L. Hamilton" <rlhamil at smart.net<mailto:rlhamil at smart.net>>
To: Users of ISC DHCP <dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>>
Subject: Re: Failover + Static host definitions
Message-ID: <29780D6E-64C1-47CE-9D5C-6094F46B04E1 at smart.net<mailto:29780D6E-64C1-47CE-9D5C-6094F46B04E1 at smart.net>>
Content-Type: text/plain;       charset=utf-8

I have failover set up, and while I have a dynamic range, all known devices have static reservations configured.

Except for what has to be different between primary and secondary, the configuration files are the same; they both have the same host definitions.

Separating the configuration file into two parts: the main part with the primary or secondary information and pool definitions, which then includes on both an identical copy of  the file with the static host information, seems like it would simplify matters; you?d only be editing one file and copying it (and restarting both DHCP servers, presumably). Or you could script something really kewl with omshell to do both maybe, but if you make a mistake, you mess up both at the same time. At least if you?re editing a file, you can make sure the primary is behaving after restarting it before copying the edited file over to the secondary and restarting it too.

Putting the included file on a share that both can access would NOT be as good as it sounds, since that?s one more thing that has to be up in the right order, and could break.

> On Jul 14, 2022, at 10:51 AM, Ryan Shea <ryan at muppethouse.com<mailto:ryan at muppethouse.com>> wrote:
>
> Failover of a pool seems straightforward enough - however this is insufficient in the case where static reservations are present in host definitions. I am looking for some solution by which I have a redundant pair of dhcpd services which can not only fail over leases from a pool, but also keep those hosts with static reservations working.
>
> Is this as simple as synchronizing the host config definitions and running both services - without any particular concern about which server replies? Manually managing host configs for reservations in two places seems sub-optimal.
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> dhcp-users mailing list
> dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>
> https://lists.isc.org/mailman/listinfo/dhcp-users



------------------------------

Message: 3
Date: Fri, 15 Jul 2022 11:04:26 +1000
From: Glenn Satchell <glenn.satchell at uniq.com.au<mailto:glenn.satchell at uniq.com.au>>
To: Users of ISC DHCP <dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>>
Subject: Re: Failover + Static host definitions
Message-ID: <305edd76-55db-4ca5-9945-8238ea7449da at email.android.com<mailto:305edd76-55db-4ca5-9945-8238ea7449da at email.android.com>>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220715/6852c278/attachment-0001.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
dhcp-users at lists.isc.org<mailto:dhcp-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/dhcp-users


------------------------------

End of dhcp-users Digest, Vol 165, Issue 6
******************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220715/e1f0fe28/attachment-0001.htm>

More information about the dhcp-users mailing list