Send dhcp-users mailing list submissions to
        dhcp-users@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-requ...@lists.isc.org

You can reach the person managing the list at
        dhcp-users-ow...@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. Re: dhcp-users Digest, Vol 165, Issue 6 (Gregory Sloop)
   2. Re: dhcp-users Digest, Vol 165, Issue 6 (Patrick Trapp)


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

Message: 1
Date: Fri, 15 Jul 2022 10:35:09 -0700
From: Gregory Sloop <gr...@sloop.net>
To: Ryan Shea <r...@muppethouse.com>, dhcp-users@lists.isc.org
Subject: Re: dhcp-users Digest, Vol 165, Issue 6
Message-ID: <1745536723.20220715103...@sloop.net>
Content-Type: text/plain; charset="utf-8"

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-requ...@lists.isc.org> wrote:

>> Send dhcp-users mailing list submissions to
>> ? ? ? ? dhcp-users@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-requ...@lists.isc.org

>> You can reach the person managing the list at
>> ? ? ? ? dhcp-users-ow...@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 <r...@muppethouse.com>
>> To: dhcp-users@lists.isc.org
>> Subject: Failover + Static host definitions
>> Message-ID:
>> ? ? ? ? 
>> <CAL6QW496AknMABKu2874L=MSWvWp_Q9THoUm8QLQnnOjPhO=t...@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" <rlha...@smart.net>
>> To: Users of ISC DHCP <dhcp-users@lists.isc.org>
>> Subject: Re: Failover + Static host definitions
>> Message-ID: <29780d6e-64c1-47ce-9d5c-6094f46b0...@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 <r...@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@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.satch...@uniq.com.au>
>> To: Users of ISC DHCP <dhcp-users@lists.isc.org>
>> Subject: Re: Failover + Static host definitions
>> Message-ID: <305edd76-55db-4ca5-9945-8238ea744...@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@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/35d3d7cc/attachment-0001.htm>

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

Message: 2
Date: Fri, 15 Jul 2022 17:46:29 +0000
From: Patrick Trapp <ptr...@nex-tech.com>
To: Greg Sloop <gr...@sloop.net>, Users of ISC DHCP
        <dhcp-users@lists.isc.org>
Subject: Re: dhcp-users Digest, Vol 165, Issue 6
Message-ID:
        
<mn0pr12mb62957831cb55fd0a3eae63e5e6...@mn0pr12mb6295.namprd12.prod.outlook.com>
        
Content-Type: text/plain; charset="us-ascii"

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-boun...@lists.isc.org> on behalf of Gregory Sloop 
<gr...@sloop.net>
Sent: Friday, July 15, 2022 12:35 PM
To: Ryan Shea <r...@muppethouse.com>; dhcp-users@lists.isc.org 
<dhcp-users@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-requ...@lists.isc.org<mailto:dhcp-users-requ...@lists.isc.org>> 
wrote:
Send dhcp-users mailing list submissions to
        dhcp-users@lists.isc.org<mailto:dhcp-users@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-requ...@lists.isc.org<mailto:dhcp-users-requ...@lists.isc.org>

You can reach the person managing the list at
        dhcp-users-ow...@lists.isc.org<mailto:dhcp-users-ow...@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 <r...@muppethouse.com<mailto:r...@muppethouse.com>>
To: dhcp-users@lists.isc.org<mailto:dhcp-users@lists.isc.org>
Subject: Failover + Static host definitions
Message-ID:
        
<CAL6QW496AknMABKu2874L=MSWvWp_Q9THoUm8QLQnnOjPhO=t...@mail.gmail.com<mailto:t...@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" <rlha...@smart.net<mailto:rlha...@smart.net>>
To: Users of ISC DHCP 
<dhcp-users@lists.isc.org<mailto:dhcp-users@lists.isc.org>>
Subject: Re: Failover + Static host definitions
Message-ID: 
<29780d6e-64c1-47ce-9d5c-6094f46b0...@smart.net<mailto:29780d6e-64c1-47ce-9d5c-6094f46b0...@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 
> <r...@muppethouse.com<mailto:r...@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@lists.isc.org<mailto:dhcp-users@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.satch...@uniq.com.au<mailto:glenn.satch...@uniq.com.au>>
To: Users of ISC DHCP 
<dhcp-users@lists.isc.org<mailto:dhcp-users@lists.isc.org>>
Subject: Re: Failover + Static host definitions
Message-ID: 
<305edd76-55db-4ca5-9945-8238ea744...@email.android.com<mailto:305edd76-55db-4ca5-9945-8238ea744...@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@lists.isc.org<mailto:dhcp-users@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.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@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users


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

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

Reply via email to