Handling DHCP host reservations

Support
1

We're in the process of migrating our hardware provisioning from Cobbler to
Foreman, and I've run into an issue with DHCP configuration. We're running
a Cobbler server in each of our datacenters, of which there are many, for
hardware provisioning.

On our Cobbler servers, we run DHCP with host reservations, while
disallowing unknown hosts. We do this via Cobbler's DHCP Management
feature: http://cobbler.github.io/manuals/2.6.0/3/4/1_-_Managing_DHCP.html,
and a dhcpd.conf template. Since our Cobbler server lives on the same host
as the DHCP server, it's able to rebuild dhcp.conf from a template, and
create hardware reservations for each system stored locally on disk.

We're replacing this configuration with one that uses Foreman + local
Foreman smart proxies in each datacenter, and I need a way to dynamically
create these host reservations.

I looked at the DHCP puppet module:
https://github.com/puppetlabs/puppetlabs-dhcp, but using it seems to
require that I have host information stored within puppet. Host
reservations are created like so:

dhcp::host {
'server1':
mac => '00:50:56:00:00:01',
ip => '10.0.1.51',
}

…I want to avoid storing the host data in two places (in Foreman records,
and within a Puppet module). I'd like to have the DHCP host reservation
created directly from the Foreman host record.

Since the Proxy doesn't seem to be able to manage the dhcpd.conf file, it
seems like the only way to accomplish this is via OMAPI (which
unfortunately is transient and doesn't manage the dhcpd.conf file), or a
locally hosted, custom script on the Smart Proxy which manages dhcpd.conf.
My thought is to have a foreman hook on the Foreman server that calls this
custom "DHCP Manage" script on the local Smart Proxy whenever "Build" is
clicked on a host, to ensure its hardware reservation exists.

Does that sound reasonable, or is there a better way to do this? (Side
note: I was going to use a small pool of DHCP addresses (5-10) in each
segment, and dedicate them to new builds, rather than use host
reservations, but there are many segments, and some of them don't have free
IP space… hence, I chose to stick with the host reservations)

2

> We're in the process of migrating our hardware provisioning from Cobbler
> to Foreman, and I've run into an issue with DHCP configuration. We're
> running a Cobbler server in each of our datacenters, of which there are
> many, for hardware provisioning.
>
> On our Cobbler servers, we run DHCP with host reservations, while
> disallowing unknown hosts. We do this via Cobbler's DHCP Management
> feature: http://cobbler.github.io/manuals/2.6.0/3/4/1_-_Managing_DHCP.html,
> and a dhcpd.conf template. Since our Cobbler server lives on the same host
> as the DHCP server, it's able to rebuild dhcp.conf from a template, and
> create hardware reservations for each system stored locally on disk.
>
> We're replacing this configuration with one that uses Foreman + local
> Foreman smart proxies in each datacenter, and I need a way to dynamically
> create these host reservations.
>
> I looked at the DHCP puppet module:
> https://github.com/puppetlabs/puppetlabs-dhcp, but using it seems to
> require that I have host information stored within puppet. Host
> reservations are created like so:
>
> dhcp::host {
> 'server1':
> mac => '00:50:56:00:00:01',
> ip => '10.0.1.51',
> }
>
>
> …I want to avoid storing the host data in two places (in Foreman
> records, and within a Puppet module). I'd like to have the DHCP host
> reservation created directly from the Foreman host record.
>
> Since the Proxy doesn't seem to be able to manage the dhcpd.conf file, it
> seems like the only way to accomplish this is via OMAPI (which
> unfortunately is transient and doesn't manage the dhcpd.conf file), or a
> locally hosted, custom script on the Smart Proxy which manages dhcpd.conf.
> My thought is to have a foreman hook on the Foreman server that calls this
> custom "DHCP Manage" script on the local Smart Proxy whenever "Build" is
> clicked on a host, to ensure its hardware reservation exists.
>
>
What do you mean by transient? the changes are persistent and survive
service restarts etc. the dhcp leases file is its actual db.

> Does that sound reasonable, or is there a better way to do this? (Side
> note: I was going to use a small pool of DHCP addresses (5-10) in each
> segment, and dedicate them to new builds, rather than use host
> reservations, but there are many segments, and some of them don't have free
> IP space… hence, I chose to stick with the host reservations)
>
> I would not manage it twice, foreman 1.10 has a feature to be able and fix
any dhcp (or any proxy service for provisioning such as dns, tftp etc) from
the ui once a mismatch is found.

hope this helps,
Ohad

··· On Wed, Jan 13, 2016 at 10:27 PM, Kyle Flavin wrote:

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

3

>
>
>
>
>> We're in the process of migrating our hardware provisioning from Cobbler
>> to Foreman, and I've run into an issue with DHCP configuration. We're
>> running a Cobbler server in each of our datacenters, of which there are
>> many, for hardware provisioning.
>>
>> On our Cobbler servers, we run DHCP with host reservations, while
>> disallowing unknown hosts. We do this via Cobbler's DHCP Management
>> feature:
>> http://cobbler.github.io/manuals/2.6.0/3/4/1_-_Managing_DHCP.html, and a
>> dhcpd.conf template. Since our Cobbler server lives on the same host as
>> the DHCP server, it's able to rebuild dhcp.conf from a template, and create
>> hardware reservations for each system stored locally on disk.
>>
>> We're replacing this configuration with one that uses Foreman + local
>> Foreman smart proxies in each datacenter, and I need a way to dynamically
>> create these host reservations.
>>
>> I looked at the DHCP puppet module:
>> https://github.com/puppetlabs/puppetlabs-dhcp, but using it seems to
>> require that I have host information stored within puppet. Host
>> reservations are created like so:
>>
>> dhcp::host {
>> 'server1':
>> mac => '00:50:56:00:00:01',
>> ip => '10.0.1.51',
>> }
>>
>>
>> …I want to avoid storing the host data in two places (in Foreman
>> records, and within a Puppet module). I'd like to have the DHCP host
>> reservation created directly from the Foreman host record.
>>
>> Since the Proxy doesn't seem to be able to manage the dhcpd.conf file, it
>> seems like the only way to accomplish this is via OMAPI (which
>> unfortunately is transient and doesn't manage the dhcpd.conf file), or a
>> locally hosted, custom script on the Smart Proxy which manages dhcpd.conf.
>> My thought is to have a foreman hook on the Foreman server that calls this
>> custom "DHCP Manage" script on the local Smart Proxy whenever "Build" is
>> clicked on a host, to ensure its hardware reservation exists.
>>
>>
> What do you mean by transient? the changes are persistent and survive
> service restarts etc. the dhcp leases file is its actual db.
>

Maybe I misunderstand OMAPI and DHCP. From what I was reading, I assumed
changes wouldn't survive a restart of DHCP. Shouldn't they be in
dhcpd.conf as well? Or is there no reason to keep them there?

>
>
>> Does that sound reasonable, or is there a better way to do this? (Side
>> note: I was going to use a small pool of DHCP addresses (5-10) in each
>> segment, and dedicate them to new builds, rather than use host
>> reservations, but there are many segments, and some of them don't have free
>> IP space… hence, I chose to stick with the host reservations)
>>
>> I would not manage it twice, foreman 1.10 has a feature to be able and
> fix any dhcp (or any proxy service for provisioning such as dns, tftp etc)
> from the ui once a mismatch is found.
>

I just sold management on an upgrade from 1.7 to 1.9, which we did a few
weeks ago (shortly before the release of 1.10). I'm not sure if I'll be
able to move to 1.10 right away (or at least until this current project is
complete). That looks like what I need though. I'll have to install a
1.10 and investigate a little further.

··· On Wednesday, January 13, 2016 at 12:30:28 PM UTC-8, ohad wrote: > On Wed, Jan 13, 2016 at 10:27 PM, Kyle Flavin > wrote:

hope this helps,
Ohad

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-user...@googlegroups.com <javascript:>.
To post to this group, send email to forema...@googlegroups.com
<javascript:>.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

4

>
>
>>
>>
>>
>>
>>> We're in the process of migrating our hardware provisioning from Cobbler
>>> to Foreman, and I've run into an issue with DHCP configuration. We're
>>> running a Cobbler server in each of our datacenters, of which there are
>>> many, for hardware provisioning.
>>>
>>> On our Cobbler servers, we run DHCP with host reservations, while
>>> disallowing unknown hosts. We do this via Cobbler's DHCP Management
>>> feature:
>>> http://cobbler.github.io/manuals/2.6.0/3/4/1_-_Managing_DHCP.html, and
>>> a dhcpd.conf template. Since our Cobbler server lives on the same host as
>>> the DHCP server, it's able to rebuild dhcp.conf from a template, and create
>>> hardware reservations for each system stored locally on disk.
>>>
>>> We're replacing this configuration with one that uses Foreman + local
>>> Foreman smart proxies in each datacenter, and I need a way to dynamically
>>> create these host reservations.
>>>
>>> I looked at the DHCP puppet module:
>>> https://github.com/puppetlabs/puppetlabs-dhcp, but using it seems to
>>> require that I have host information stored within puppet. Host
>>> reservations are created like so:
>>>
>>> dhcp::host {
>>> 'server1':
>>> mac => '00:50:56:00:00:01',
>>> ip => '10.0.1.51',
>>> }
>>>
>>>
>>> …I want to avoid storing the host data in two places (in Foreman
>>> records, and within a Puppet module). I'd like to have the DHCP host
>>> reservation created directly from the Foreman host record.
>>>
>>> Since the Proxy doesn't seem to be able to manage the dhcpd.conf file,
>>> it seems like the only way to accomplish this is via OMAPI (which
>>> unfortunately is transient and doesn't manage the dhcpd.conf file), or a
>>> locally hosted, custom script on the Smart Proxy which manages dhcpd.conf.
>>> My thought is to have a foreman hook on the Foreman server that calls this
>>> custom "DHCP Manage" script on the local Smart Proxy whenever "Build" is
>>> clicked on a host, to ensure its hardware reservation exists.
>>>
>>>
>> What do you mean by transient? the changes are persistent and survive
>> service restarts etc. the dhcp leases file is its actual db.
>>
>
> Maybe I misunderstand OMAPI and DHCP. From what I was reading, I assumed
> changes wouldn't survive a restart of DHCP. Shouldn't they be in
> dhcpd.conf as well? Or is there no reason to keep them there?
>

this is how isc dhcp works, try it for your self :slight_smile:

··· On Wed, Jan 13, 2016 at 10:49 PM, Kyle Flavin wrote: > On Wednesday, January 13, 2016 at 12:30:28 PM UTC-8, ohad wrote: >> On Wed, Jan 13, 2016 at 10:27 PM, Kyle Flavin wrote:

Does that sound reasonable, or is there a better way to do this? (Side
note: I was going to use a small pool of DHCP addresses (5-10) in each
segment, and dedicate them to new builds, rather than use host
reservations, but there are many segments, and some of them don’t have free
IP space… hence, I chose to stick with the host reservations)

I would not manage it twice, foreman 1.10 has a feature to be able and
fix any dhcp (or any proxy service for provisioning such as dns, tftp etc)
from the ui once a mismatch is found.

I just sold management on an upgrade from 1.7 to 1.9, which we did a few
weeks ago (shortly before the release of 1.10). I’m not sure if I’ll be
able to move to 1.10 right away (or at least until this current project is
complete). That looks like what I need though. I’ll have to install a
1.10 and investigate a little further.

hope this helps,
Ohad

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

5

> Maybe I misunderstand OMAPI and DHCP. From what I was reading, I assumed
> changes wouldn't survive a restart of DHCP. Shouldn't they be in
> dhcpd.conf as well? Or is there no reason to keep them there?
>

Seconded, it definitely survives restarts and reboots. I'd add the lease
file to your backups though, if it isn't already :wink:

> I just sold management on an upgrade from 1.7 to 1.9, which we did a few
> weeks ago (shortly before the release of 1.10). I'm not sure if I'll be
> able to move to 1.10 right away (or at least until this current project is
> complete). That looks like what I need though. I'll have to install a
> 1.10 and investigate a little further.
>

The Rebuild Config option has a preview video[1] if you want to see it in
action. I only demo-ed TFTP rebuild for speed (30s is a tight limit) but it
works for DNS/DHCP too. Alternatively, you can use the Rails console to
achieve something similar on older installs, it's just a bit more fiddly.

Greg
[1] https://www.youtube.com/watch?v=MxPtzWhiE1o

··· On 13 January 2016 at 20:49, Kyle Flavin wrote:
6

>
>
>
>> Maybe I misunderstand OMAPI and DHCP. From what I was reading, I assumed
>> changes wouldn't survive a restart of DHCP. Shouldn't they be in
>> dhcpd.conf as well? Or is there no reason to keep them there?
>>
>
> Seconded, it definitely survives restarts and reboots. I'd add the lease
> file to your backups though, if it isn't already :wink:
>

Verified that, thanks Greg!

>
>
>> I just sold management on an upgrade from 1.7 to 1.9, which we did a few
>> weeks ago (shortly before the release of 1.10). I'm not sure if I'll be
>> able to move to 1.10 right away (or at least until this current project is
>> complete). That looks like what I need though. I'll have to install a
>> 1.10 and investigate a little further.
>>
>
> The Rebuild Config option has a preview video[1] if you want to see it in
> action. I only demo-ed TFTP rebuild for speed (30s is a tight limit) but it
> works for DNS/DHCP too. Alternatively, you can use the Rails console to
> achieve something similar on older installs, it's just a bit more fiddly.
>

I watched your rebuild video yesterday - it's exactly what I need,
unfortunately I won't be able to upgrade from 1.9.3 right away. How can I
achieve the same result through the rails console? That might be the way
to go. I have a large number of hosts I'll be moving over, and none of
them will exist in the leases file, initially.

I tried changing the IP on the host's NIC, and then flipping it back to the
original IP. It worked. So I'm thinking about trying the following as a
workaround, until we can get to 1.10:

Initially:

  1. Add a bogus subnet to Foreman. (no DHCP or DNS proxy defined)

When building a host:

  1. change the IP on the host's NIC to an IP on the bogus subnet, and
    uncheck "managed" box (unchecking the box may not be necessary since there
    is no DNS proxy on the bogus subnet?)
  2. change the IP on the host's NIC back to the original IP, and check
    "managed" box.

I want to update the DHCP record, without changing the DNS. I'll have to
document this for our operators who perform regular builds, so I'm trying
to make it as simple as possible:

··· On Thursday, January 14, 2016 at 1:59:22 AM UTC-8, Greg Sutcliffe wrote: > On 13 January 2016 at 20:49, Kyle Flavin <kyle....@gmail.com > > wrote:

Greg
[1] https://www.youtube.com/watch?v=MxPtzWhiE1o

7

I watched your rebuild video yesterday - it's exactly what I need,
> unfortunately I won't be able to upgrade from 1.9.3 right away. How can I
> achieve the same result through the rails console? That might be the way
> to go. I have a large number of hosts I'll be moving over, and none of
> them will exist in the leases file, initially.
>
> I tried changing the IP on the host's NIC, and then flipping it back to
> the original IP. It worked. So I'm thinking about trying the following as
> a workaround, until we can get to 1.10:
>
> Initially:
> 1) Add a bogus subnet to Foreman. (no DHCP or DNS proxy defined)
>
> When building a host:
> 1) change the IP on the host's NIC to an IP on the bogus subnet, and
> uncheck "managed" box (unchecking the box may not be necessary since there
> is no DNS proxy on the bogus subnet?)
> 2) change the IP on the host's NIC back to the original IP, and check
> "managed" box.
>
> I want to update the DHCP record, without changing the DNS. I'll have to
> document this for our operators who perform regular builds, so I'm trying
> to make it as simple as possible:
>

Is the DNS "wrong" then? What's the rationale behind not updating DNS? I
ask because the easy ways to rebuild the lease file involve triggering all
the orchestration (DNS/DHCP/TFTP) rather than trying to pick out a single
pice of it. If that's acceptable, then you can rebuild the leases file for
all the hosts in pretty much one command on the Rails console. If not, then
you'll need to do something more complex.

The second question is whether your operators have shell access to the
Foreman box, since that's needed for the Rails console. If not, then this
whole idea is a non-starter, and you need to do something like what you're
suggesting through the UI.

For reference, here's an outdated but still broadly accurate blog post on
recovering DHCP leases -
http://theforeman.org/2012/01/recovering-lost-dhcp-reservations.html

Cheers,
Greg

··· On 14 January 2016 at 18:35, Kyle Flavin wrote:
8

> > Seconded, it definitely survives restarts and reboots. I'd add the lease
> > file to your backups though, if it isn't already :wink:
>
> Verified that, thanks Greg!

Good resource on the dhcpd.leases format is the man page. It's
append-only file, which confused zillions of admins already, including
me :slight_smile:

··· -- Later, Lukas #lzap Zapletal
9

The DNS is correct. The issue is we're migrating from another provisioning
system to Foreman, so there are no DHCP lease entries at the moment. I'll
have to create them somehow. I can do this by changing the IP on the host
record in Foreman to something bogus, and then back to the real IP again.
This adds the lease, but it also changes DNS (twice - when I change to the
bogus IP, and when I switch it back to the real IP), and since I'm only
trying to get a lease record created, the DNS change is an unwanted side
effect. It looks like it doesn't do this when I uncheck the "Managed"
checkbox on the NIC when switching to the bogus IP. This method would
require a little extra work on the part of the operators when doing a new
build.

I've also thought about scripting the creation of the leases file. But I
want to avoid running a script in our production environment that will
cause thousands of servers to flip their DNS, however brief that may be.
In the scenario above, where the operator flips the IP to initiate the
lease, a brief DNS change probably isn't a big deal, since the server is
being rebuilt anyway.

I've also thought about writing a shell script to create the dhcpd.leases
file from scratch, and bypass the Foreman orchestration entirely. If I'm
looking to automate, it seems like this might have the fewest potential
side effects.

··· On Friday, January 15, 2016 at 1:47:10 AM UTC-8, Greg Sutcliffe wrote: > > On 14 January 2016 at 18:35, Kyle Flavin <kyle....@gmail.com > > wrote: > > I watched your rebuild video yesterday - it's exactly what I need, >> unfortunately I won't be able to upgrade from 1.9.3 right away. How can I >> achieve the same result through the rails console? That might be the way >> to go. I have a large number of hosts I'll be moving over, and none of >> them will exist in the leases file, initially. >> >> I tried changing the IP on the host's NIC, and then flipping it back to >> the original IP. It worked. So I'm thinking about trying the following as >> a workaround, until we can get to 1.10: >> >> *Initially:* >> 1) Add a bogus subnet to Foreman. (no DHCP or DNS proxy defined) >> >> *When building a host:* >> 1) change the IP on the host's NIC to an IP on the bogus subnet, and >> uncheck "managed" box (unchecking the box may not be necessary since there >> is no DNS proxy on the bogus subnet?) >> 2) change the IP on the host's NIC back to the original IP, and check >> "managed" box. >> >> I want to update the DHCP record, without changing the DNS. I'll have to >> document this for our operators who perform regular builds, so I'm trying >> to make it as simple as possible: >> > > Is the DNS "wrong" then? What's the rationale behind not updating DNS? I > ask because the easy ways to rebuild the lease file involve triggering all > the orchestration (DNS/DHCP/TFTP) rather than trying to pick out a single > pice of it. If that's acceptable, then you can rebuild the leases file for > all the hosts in pretty much one command on the Rails console. If not, then > you'll need to do something more complex. >

For reference, here’s an outdated but still broadly accurate blog post on
recovering DHCP leases -
Foreman :: Recovering Lost DHCP reservations

Cheers,
Greg

10

The DNS is correct. The issue is we're migrating from another provisioning
> system to Foreman, so there are no DHCP lease entries at the moment. I'll
> have to create them somehow. I can do this by changing the IP on the host
> record in Foreman to something bogus, and then back to the real IP again.
> This adds the lease, but it also changes DNS (twice - when I change to the
> bogus IP, and when I switch it back to the real IP), and since I'm only
> trying to get a lease record created, the DNS change is an unwanted side
> effect. It looks like it doesn't do this when I uncheck the "Managed"
> checkbox on the NIC when switching to the bogus IP. This method would
> require a little extra work on the part of the operators when doing a new
> build.
>

I've also thought about scripting the creation of the leases file. But I
> want to avoid running a script in our production environment that will
> cause thousands of servers to flip their DNS, however brief that may be.
> In the scenario above, where the operator flips the IP to initiate the
> lease, a brief DNS change probably isn't a big deal, since the server is
> being rebuilt anyway.
>

Ah good. Foreman is a bit like Puppet in this case, it's all about state.
If the DNS is correct, then a call to re-write the DNS config (as 1.10
would do) will do nothing, as it's already correct. That means what 1.10
does (and indeed use that blog post I linked earlier) wouldn't flip DNS at
all, unlike altering the nics and saving before changing it back.

> I've also thought about writing a shell script to create the dhcpd.leases
> file from scratch, and bypass the Foreman orchestration entirely. If I'm
> looking to automate, it seems like this might have the fewest potential
> side effects.
>

Indeed, and you could even use the foreman_hooks plugin to run that script
on save.

A third, and potentially best, option is to consider a plugin. If you can
make an up-to-date version of the commands in that blog post that does what
you want for a single host, on the console, then it's probably only an
hour-or-so's work to turn it into a simple plugin with a button on the host
page. Then your operators can click it :slight_smile:

Greg

··· On 15 January 2016 at 17:21, Kyle Flavin wrote:
11

Hi Kyle,

It was very good information which you mentioned here regarding dhcp.lease,
I have one query for that, Did you automate to migrate the lease
information from cobbler to smproxy host?
My configuration for smproxy is working fine but not able to migrate the
existing host list (dhcp.lease) to smproxy server. Is there any way to
migrate the dhcp lease info ?
I have tried manually to update the few host info on foreman and it worked
but we have 700+ hosts, Let me know if you have any information on it.

··· On Friday, January 15, 2016 at 10:51:18 PM UTC+5:30, Kyle Flavin wrote: > > > > On Friday, January 15, 2016 at 1:47:10 AM UTC-8, Greg Sutcliffe wrote: >> >> On 14 January 2016 at 18:35, Kyle Flavin wrote: >> >> I watched your rebuild video yesterday - it's exactly what I need, >>> unfortunately I won't be able to upgrade from 1.9.3 right away. How can I >>> achieve the same result through the rails console? That might be the way >>> to go. I have a large number of hosts I'll be moving over, and none of >>> them will exist in the leases file, initially. >>> >>> I tried changing the IP on the host's NIC, and then flipping it back to >>> the original IP. It worked. So I'm thinking about trying the following as >>> a workaround, until we can get to 1.10: >>> >>> *Initially:* >>> 1) Add a bogus subnet to Foreman. (no DHCP or DNS proxy defined) >>> >>> *When building a host:* >>> 1) change the IP on the host's NIC to an IP on the bogus subnet, and >>> uncheck "managed" box (unchecking the box may not be necessary since there >>> is no DNS proxy on the bogus subnet?) >>> 2) change the IP on the host's NIC back to the original IP, and check >>> "managed" box. >>> >>> I want to update the DHCP record, without changing the DNS. I'll have >>> to document this for our operators who perform regular builds, so I'm >>> trying to make it as simple as possible: >>> >> >> Is the DNS "wrong" then? What's the rationale behind not updating DNS? I >> ask because the easy ways to rebuild the lease file involve triggering all >> the orchestration (DNS/DHCP/TFTP) rather than trying to pick out a single >> pice of it. If that's acceptable, then you can rebuild the leases file for >> all the hosts in pretty much one command on the Rails console. If not, then >> you'll need to do something more complex. >> > >> >> > >> For reference, here's an outdated but still broadly accurate blog post on >> recovering DHCP leases - >> http://theforeman.org/2012/01/recovering-lost-dhcp-reservations.html >> > > >> >> >> Cheers, >> Greg >> > > The DNS is correct. The issue is we're migrating from another > provisioning system to Foreman, so there are no DHCP lease entries at the > moment. I'll have to create them somehow. I can do this by changing the > IP on the host record in Foreman to something bogus, and then back to the > real IP again. This adds the lease, but it also changes DNS (twice - when > I change to the bogus IP, and when I switch it back to the real IP), and > since I'm only trying to get a lease record created, the DNS change is an > unwanted side effect. It looks like it doesn't do this when I uncheck the > "Managed" checkbox on the NIC when switching to the bogus IP. This method > would require a little extra work on the part of the operators when doing a > new build. > > I've also thought about scripting the creation of the leases file. But I > want to avoid running a script in our production environment that will > cause thousands of servers to flip their DNS, however brief that may be. > In the scenario above, where the operator flips the IP to initiate the > lease, a brief DNS change probably isn't a big deal, since the server is > being rebuilt anyway. > > I've also thought about writing a shell script to create the dhcpd.leases > file from scratch, and bypass the Foreman orchestration entirely. If I'm > looking to automate, it seems like this might have the fewest potential > side effects. >