(re)-using discovery image for dhcp less networks

Development
1

Hi,

I'm trying to solve two problems, and wanted a sanity check/feedback.

The requirements are:

  • Provision without dhcp (manual ip assignments or dhcp outside of foreman
    control etc)
  • Do not require a pre defined host entry in foreman.

I thought we can reuse discovery, as it can both boot unknown(new) clients,
and automatically provision based on rules (e.g. provision all of this
systems to be desktops for example), or when there are no provisioning
rules, its still possible to provision/approve the new hosts centrally.

I assumed we can reuse discovery for that if we:

  • add a fallback to manual network configuration (and probably hostname
    too) when there is no dhcp
  • potentially extend the discovery image to send additional key/values that
    can be used in rules (e.g. user input)
  • add the ability to pull the kernel / initrd and boot it using kexec (or
    similar) - as we can't reboot to pxe.

The only drawback i could think of is re-building the host, which in that
case we would need to use something similar to [1] or delete the host entry
first.

would that work? am i missing an obvious alternative using the bootdisk
plugin?

thanks,
Ohad

[1]

2

> > Hi,
> >
> > I'm trying to solve two problems, and wanted a sanity check/feedback.
> >
> > The requirements are:
> > - Provision without dhcp (manual ip assignments or dhcp outside of foreman
> > control etc)
> > - Do not require a pre defined host entry in foreman.
> >
> > I thought we can reuse discovery, as it can both boot unknown(new) clients,
> > and automatically provision based on rules (e.g. provision all of this
> > systems to be desktops for example), or when there are no provisioning
> > rules, its still possible to provision/approve the new hosts centrally.
> >
> > I assumed we can reuse discovery for that if we:
> > - add a fallback to manual network configuration (and probably hostname
> > too)
> > when there is no dhcp
> > - potentially extend the discovery image to send additional key/values that
> > can be used in rules (e.g. user input)
> > - add the ability to pull the kernel / initrd and boot it using kexec (or
> > similar) - as we can't reboot to pxe.
>
> This will work from a technical view, but I question the requirement.
>
> The point of Discovery (to me) is to automate the process of adding
> hardware to your estate (removing human error in working with MACs,
> IPs, and so on), and the idea of being physically present at every
> machine when it boots Discovery (to enter the network details) sounds
> backwards to me.
>
> I would expect a way to do completely hands-off configuration to be a
> requirement for a tool like Discovery. Perhaps you can elaborate a
> little more on these requirements?

I've been thinking about this for some time (there is a nice pool of compute
resources that I would like to control from foreman, but will never get my
dhcp on that network). The discovery image was always a candidate for doing
so. However, as you described, the rebuild functionality puts some new light
on that: from this perspective, you have the discovery image just in half
cases.

Therefore, I'm now more fan of leveraging remote execution to automate the [1],
both on the discovered or on managed host.

What exactly means the need for no need for pre-defined host?

– Ivan

··· ----- Original Message ----- > On 2 March 2015 at 08:44, Ohad Levy wrote:

Greg

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

3

This is the scenario I heard:

Assume a very locked down data center. The data center does not run DHCP
or PXE. The operators, who rack the machines, do not have access to the
Foreman server. They would like to operators to be able to rack
machines, define the IP address, and to select from a fixed set of
machine types (host groups) to provision.

The discussion was had that a better pattern would be to use RBAC to
define an operator view, where they can create hosts only to the fixed
set of machine types. The story above is seen as a way to work towards
that goal.

– bk

··· On 03/02/2015 05:29 AM, Greg Sutcliffe wrote: > I would expect a way to do completely hands-off configuration to be a > requirement for a tool like Discovery. Perhaps you can elaborate a > little more on these requirements?
4

This will work from a technical view, but I question the requirement.

The point of Discovery (to me) is to automate the process of adding
hardware to your estate (removing human error in working with MACs,
IPs, and so on), and the idea of being physically present at every
machine when it boots Discovery (to enter the network details) sounds
backwards to me.

I would expect a way to do completely hands-off configuration to be a
requirement for a tool like Discovery. Perhaps you can elaborate a
little more on these requirements?

Greg

··· On 2 March 2015 at 08:44, Ohad Levy wrote: > Hi, > > I'm trying to solve two problems, and wanted a sanity check/feedback. > > The requirements are: > - Provision without dhcp (manual ip assignments or dhcp outside of foreman > control etc) > - Do not require a pre defined host entry in foreman. > > I thought we can reuse discovery, as it can both boot unknown(new) clients, > and automatically provision based on rules (e.g. provision all of this > systems to be desktops for example), or when there are no provisioning > rules, its still possible to provision/approve the new hosts centrally. > > I assumed we can reuse discovery for that if we: > - add a fallback to manual network configuration (and probably hostname too) > when there is no dhcp > - potentially extend the discovery image to send additional key/values that > can be used in rules (e.g. user input) > - add the ability to pull the kernel / initrd and boot it using kexec (or > similar) - as we can't reboot to pxe.
5

You don't need your DHCP. Any DHCP will do, so long as it points to
the PXE server and the discovery image. PXE is your roadblock, since
sysadmins usually give out even less access to that :slight_smile:

That said, Discovery could be booted from USB, or chainloaded from a
USB iPXE iso. You'll still need a way to automate attaching that
usb/iso to the machine (to make it properly hands-off), and you'll
still need DHCP (otherwise you're generating a host-specific iso,
which violates the premise of Discovery in the first place).

Greg

··· On 2 March 2015 at 11:33, Ivan Necas wrote: > I've been thinking about this for some time (there is a nice pool of compute > resources that I would like to control from foreman, but will never get my > dhcp on that network).
6

> This is the scenario I heard:
>
> Assume a very locked down data center. The data center does not run DHCP or
> PXE. The operators, who rack the machines, do not have access to the Foreman
> server. They would like to operators to be able to rack machines, define the
> IP address, and to select from a fixed set of machine types (host groups) to
> provision.

That makes sense as a use case, although (as ever) I question the
premise of "DHCP is bad" :slight_smile:

> The discussion was had that a better pattern would be to use RBAC to define
> an operator view, where they can create hosts only to the fixed set of
> machine types. The story above is seen as a way to work towards that goal.

I think the RBAC solution is a great goal - especially if done nicely
so it's usable from devices within the datacentre (so you carry your
tablet and create the machines in your operator view while racking
them up, assuming you have WiFi). So, what's stopping us using it? How
much gap is there, given we already have fairly comprehensive
(although far from perfect, I know) RBAC?

Returning to the short term - Discovery (in my view) is all about
working without human interaction. Once you involve manual steps, its
utility is mostly negated - and you don't need Discovery for the above
usecase if you have Hostgroup provisioning working. The only missing
piece (I think) is getting the new machine as far as the "default" PXE
menu (which will contain your Hostgroup provisioning options). I seem
to recall the Bootdisk plugin can create a generic image - perhaps
it's not too hard to have an iPXE image that requests user input for
an IP, or auto selects from a pool? That would would seem to be a far
simpler solution that forcing Discovery into a different role.

··· On 2 March 2015 at 13:08, Bryan Kearney wrote:
7

> Hi,
Hello,

> I'm trying to solve two problems, and wanted a sanity check/feedback.
>
> The requirements are:
> - Provision without dhcp (manual ip assignments or dhcp outside of foreman
> control etc)
> - Do not require a pre defined host entry in foreman.

Do you have a management card? iDrac or iLo or other?

> I thought we can reuse discovery, as it can both boot unknown(new) clients,
> and automatically provision based on rules (e.g. provision all of this
> systems to be desktops for example), or when there are no provisioning
> rules, its still possible to provision/approve the new hosts centrally.
>
> I assumed we can reuse discovery for that if we:
> - add a fallback to manual network configuration (and probably hostname
> too) when there is no dhcp
> - potentially extend the discovery image to send additional key/values that
> can be used in rules (e.g. user input)
> - add the ability to pull the kernel / initrd and boot it using kexec (or
> similar) - as we can't reboot to pxe.
>
> The only drawback i could think of is re-building the host, which in that
> case we would need to use something similar to [1] or delete the host entry
> first.
>
> would that work? am i missing an obvious alternative using the bootdisk
> plugin?

If you have a management card such as one listed before, I always wanted to
combine bootdisk plugin to BMC. For the moment, you'll create the nodes one
by one using hammer to save the BMC informations. Then you could provision
one by creating a bootdisk image specifically for this node, mount it and
boot from it via management card. It could be the role of a new plugin.

Reprovision woudn't be an issue in this model.

It is a very different way to solve the problem and in any case don't
address the way to fastly configure the servers for provisionning.

On the topic of PXE, why you don't want PXE boot on some infrastructures?
Simply because companies use firewalls as LAN gateways and some firewalls
are bad at having dhcp-relay on more than one interface. I wont name any
brand but be sure this use case do exists in more than one brand :wink:

Claer

··· On Mon, Mar 02 2015 at 44:10, Ohad Levy wrote:
8

Hey,

> I assumed we can reuse discovery for that if we:
> - add a fallback to manual network configuration (and probably hostname
> too) when there is no dhcp
> - potentially extend the discovery image to send additional key/values that
> can be used in rules (e.g. user input)

this will work, I think implementation would be as easy as a Shell/Ruby
script calling Whiptail or other (n)curses utility to acquire the input
in case the ISO is booted directly (not PXE-booted). All we need to
change is the syslinux configuration for the image and add a systemd
service.

> - add the ability to pull the kernel / initrd and boot it using kexec (or
> similar) - as we can't reboot to pxe.

But this one can be tough, I am not sure how stable kexec is and if it
works with Anaconda init images. Not for this reason I think it is not
good idea to try to leverage discovery for this particular use case.

I can imagine a use case when customer wants to use discovery on a
network without DHCP/PXE. It should be technically possible to ask the
user to enter networking information, but nothing else. No key/value
pairs or host group information, just enough for discovery to put the
host into the registry. Then operators with access to Foreman can either
interactively or non-interactively provision it.

I agree with Greg that what you describe is not task for discovery
image, but for bootdisk plugin. I believe iPXE has very powerful
capabilities in terms of allowing users to enter arbitrary data,
including some key/value pairs:

http://ipxe.org/cmd/read
http://ipxe.org/cmd/choose

In regard to tracebility and audit, there are multiple ways to solve
that. The easiest one is to require operators to sign in (if this is
really required):

http://ipxe.org/cmd/login

The more comfortable is to allow operators to generate their very own
bootdisk images with a token embedded. Someone with access to Foreman
needs to generate that of course, but then no login is required which
can save some time.

In all cases, we can leverage capabilities of Foreman - template
rendering. It is possible to chainload iPXE scripts and menus once
network information is correctly confirmed.

TL;DR - I think we should evaluate how to implement this via new
bootdisk feature with the following workflow:

  • operator enters network credentials
  • operator enters additional key/value pairs (optional)
  • operator signs-in (or have an image with security token)
  • menu is chain-loaded from Foreman
  • operator selects host group (or whatever is presented)
  • system boots into an installer

And I also thing we should implement Discovery without DHCP capability,
which should be relatively easy - enter IP/netmask/router/foreman IP and
that's it. While we could do this via iPXE as well, for discovery we
can carry on with PXELinux and ask the user during boot.

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

> > I've been thinking about this for some time (there is a nice pool of
> > compute
> > resources that I would like to control from foreman, but will never get my
> > dhcp on that network).
>
> You don't need your DHCP. Any DHCP will do, so long as it points to
> the PXE server and the discovery image. PXE is your roadblock, since
> sysadmins usually give out even less access to that :slight_smile:

To be more precise, I will never be able to change the PXE server.

··· ----- Original Message ----- > On 2 March 2015 at 11:33, Ivan Necas wrote:

That said, Discovery could be booted from USB, or chainloaded from a
USB iPXE iso. You’ll still need a way to automate attaching that
usb/iso to the machine (to make it properly hands-off), and you’ll
still need DHCP (otherwise you’re generating a host-specific iso,
which violates the premise of Discovery in the first place).

Greg

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

10

>> This is the scenario I heard:
>>
>> Assume a very locked down data center. The data center does not run DHCP or
>> PXE. The operators, who rack the machines, do not have access to the Foreman
>> server. They would like to operators to be able to rack machines, define the
>> IP address, and to select from a fixed set of machine types (host groups) to
>> provision.
>
> That makes sense as a use case, although (as ever) I question the
> premise of "DHCP is bad" :slight_smile:

I believe this is a journe which will take a while.

>
>> The discussion was had that a better pattern would be to use RBAC to define
>> an operator view, where they can create hosts only to the fixed set of
>> machine types. The story above is seen as a way to work towards that goal.
>
> I think the RBAC solution is a great goal - especially if done nicely
> so it's usable from devices within the datacentre (so you carry your
> tablet and create the machines in your operator view while racking
> them up, assuming you have WiFi). So, what's stopping us using it? How
> much gap is there, given we already have fairly comprehensive
> (although far from perfect, I know) RBAC?
>
> Returning to the short term - Discovery (in my view) is all about
> working without human interaction. Once you involve manual steps, its
> utility is mostly negated - and you don't need Discovery for the above
> usecase if you have Hostgroup provisioning working. The only missing
> piece (I think) is getting the new machine as far as the "default" PXE
> menu (which will contain your Hostgroup provisioning options). I seem
> to recall the Bootdisk plugin can create a generic image - perhaps
> it's not too hard to have an iPXE image that requests user input for
> an IP, or auto selects from a pool? That would would seem to be a far
> simpler solution that forcing Discovery into a different role.

I will let Ohad jump in here, but as often as I hear DHCP is bad… I
hear PXE is as well.

– bk

··· On 03/02/2015 08:45 AM, Greg Sutcliffe wrote: > On 2 March 2015 at 13:08, Bryan Kearney wrote:
11

> > This is the scenario I heard:
> >
> > Assume a very locked down data center. The data center does not run DHCP
> or
> > PXE. The operators, who rack the machines, do not have access to the
> Foreman
> > server. They would like to operators to be able to rack machines, define
> the
> > IP address, and to select from a fixed set of machine types (host
> groups) to
> > provision.
>
> That makes sense as a use case, although (as ever) I question the
> premise of "DHCP is bad" :slight_smile:
>
> > The discussion was had that a better pattern would be to use RBAC to
> define
> > an operator view, where they can create hosts only to the fixed set of
> > machine types. The story above is seen as a way to work towards that
> goal.
>
> I think the RBAC solution is a great goal - especially if done nicely
> so it's usable from devices within the datacentre (so you carry your
> tablet and create the machines in your operator view while racking
> them up, assuming you have WiFi). So, what's stopping us using it? How
> much gap is there, given we already have fairly comprehensive
> (although far from perfect, I know) RBAC?
>
> Returning to the short term - Discovery (in my view) is all about
> working without human interaction. Once you involve manual steps, its
> utility is mostly negated - and you don't need Discovery for the above
> usecase if you have Hostgroup provisioning working. The only missing
> piece (I think) is getting the new machine as far as the "default" PXE
> menu (which will contain your Hostgroup provisioning options). I seem
> to recall the Bootdisk plugin can create a generic image - perhaps
> it's not too hard to have an iPXE image that requests user input for
> an IP, or auto selects from a pool? That would would seem to be a far
> simpler solution that forcing Discovery into a different role.
>

the problem there is with hostgroup based provisioning, you dont get an
identity, puppet won't run etc, as the operation is not audited, there is
no tractability etc etc.

however, if the admin, decided to create a rule that provision into a given
hostgroup, i think its fine, but I dont think we should allow any operator
to create a db host from the db hostgroup and get the super secure password.

Ohad

··· On Mon, Mar 2, 2015 at 3:45 PM, Greg Sutcliffe wrote: > On 2 March 2015 at 13:08, Bryan Kearney wrote:

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

12

Do you have any data on why? I'd love to challenge that statement,
but without understanding why, I'm battling a religion, not a
viewpoint :wink:

··· On 2 March 2015 at 14:18, Bryan Kearney wrote: > I will let Ohad jump in here, but as often as I hear DHCP is bad.. I hear > PXE is as well.
13

NACK on sign-in. Need a model where the only interaction is the host,
no pxe or dhcp

– bk

··· On 03/04/2015 11:13 AM, Lukas Zapletal wrote: > Hey, > >> I assumed we can reuse discovery for that if we: >> - add a fallback to manual network configuration (and probably hostname >> too) when there is no dhcp >> - potentially extend the discovery image to send additional key/values that >> can be used in rules (e.g. user input) > > this will work, I think implementation would be as easy as a Shell/Ruby > script calling Whiptail or other (n)curses utility to acquire the input > in case the ISO is booted directly (not PXE-booted). All we need to > change is the syslinux configuration for the image and add a systemd > service. > >> - add the ability to pull the kernel / initrd and boot it using kexec (or >> similar) - as we can't reboot to pxe. > > But this one can be tough, I am not sure how stable kexec is and if it > works with Anaconda init images. Not for this reason I think it is not > good idea to try to leverage discovery for this particular use case. > > I can imagine a use case when customer wants to use discovery on a > network without DHCP/PXE. It should be technically possible to ask the > user to enter networking information, but nothing else. No key/value > pairs or host group information, just enough for discovery to put the > host into the registry. Then operators with access to Foreman can either > interactively or non-interactively provision it. > > I agree with Greg that what you describe is not task for discovery > image, but for bootdisk plugin. I believe iPXE has very powerful > capabilities in terms of allowing users to enter arbitrary data, > including some key/value pairs: > > http://ipxe.org/cmd/read > http://ipxe.org/cmd/choose > > In regard to tracebility and audit, there are multiple ways to solve > that. The easiest one is to require operators to sign in (if this is > really required): > > http://ipxe.org/cmd/login > > The more comfortable is to allow operators to generate their very own > bootdisk images with a token embedded. Someone with access to Foreman > needs to generate that of course, but then no login is required which > can save some time. > > In all cases, we can leverage capabilities of Foreman - template > rendering. It is possible to chainload iPXE scripts and menus once > network information is correctly confirmed. > > TL;DR - I think we should evaluate how to implement this via new > bootdisk feature with the following workflow: > > - operator enters network credentials > - operator enters additional key/value pairs (optional) > - operator signs-in (or have an image with security token)
14

> Hey,
>
> > I assumed we can reuse discovery for that if we:
> > - add a fallback to manual network configuration (and probably hostname
> > too) when there is no dhcp
> > - potentially extend the discovery image to send additional key/values
> that
> > can be used in rules (e.g. user input)
>
> this will work, I think implementation would be as easy as a Shell/Ruby
> script calling Whiptail or other (n)curses utility to acquire the input
> in case the ISO is booted directly (not PXE-booted). All we need to
> change is the syslinux configuration for the image and add a systemd
> service.
>
> > - add the ability to pull the kernel / initrd and boot it using kexec (or
> > similar) - as we can't reboot to pxe.
>
> But this one can be tough, I am not sure how stable kexec is and if it
> works with Anaconda init images. Not for this reason I think it is not
> good idea to try to leverage discovery for this particular use case.
>
> I've tried to explore that in various public bug archives, and could not
find an actual kernel panic because of kexec, it seems to be supported in
rhel, and last z.stream for fixes was in 5.7 as far as i could find.

i see it as a usefuln option for discovery regardless, as it can reduce
about 10m of hardware boot time?

Ohad

··· On Wed, Mar 4, 2015 at 6:13 PM, Lukas Zapletal wrote:

I can imagine a use case when customer wants to use discovery on a
network without DHCP/PXE. It should be technically possible to ask the
user to enter networking information, but nothing else. No key/value
pairs or host group information, just enough for discovery to put the
host into the registry. Then operators with access to Foreman can either
interactively or non-interactively provision it.

I agree with Greg that what you describe is not task for discovery
image, but for bootdisk plugin. I believe iPXE has very powerful
capabilities in terms of allowing users to enter arbitrary data,
including some key/value pairs:

http://ipxe.org/cmd/read
iPXE - open source boot firmware [cmd:choose]

In regard to tracebility and audit, there are multiple ways to solve
that. The easiest one is to require operators to sign in (if this is
really required):

iPXE - open source boot firmware [cmd:login]

The more comfortable is to allow operators to generate their very own
bootdisk images with a token embedded. Someone with access to Foreman
needs to generate that of course, but then no login is required which
can save some time.

In all cases, we can leverage capabilities of Foreman - template
rendering. It is possible to chainload iPXE scripts and menus once
network information is correctly confirmed.

TL;DR - I think we should evaluate how to implement this via new
bootdisk feature with the following workflow:

  • operator enters network credentials
  • operator enters additional key/value pairs (optional)
  • operator signs-in (or have an image with security token)
  • menu is chain-loaded from Foreman
  • operator selects host group (or whatever is presented)
  • system boots into an installer

And I also thing we should implement Discovery without DHCP capability,
which should be relatively easy - enter IP/netmask/router/foreman IP and
that’s it. While we could do this via iPXE as well, for discovery we
can carry on with PXELinux and ask the user during boot.

–
Later,
Lukas #lzap Zapletal

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

15

I have no data… only customer facing folks who say "My customer does
not allow DHCP or PXE".

– bk

··· On 03/02/2015 11:27 AM, Greg Sutcliffe wrote: > On 2 March 2015 at 14:18, Bryan Kearney wrote: >> I will let Ohad jump in here, but as often as I hear DHCP is bad.. I hear >> PXE is as well. > > Do you have any data on *why*? I'd love to challenge that statement, > but without understanding why, I'm battling a religion, not a > viewpoint ;) >
16

>> Returning to the short term - Discovery (in my view) is all about
>> working without human interaction. Once you involve manual steps, its
>> utility is mostly negated - and you don't need Discovery for the above
>> usecase if you have Hostgroup provisioning working. The only missing
>> piece (I think) is getting the new machine as far as the "default" PXE
>> menu (which will contain your Hostgroup provisioning options). I seem
>> to recall the Bootdisk plugin can create a generic image - perhaps
>> it's not too hard to have an iPXE image that requests user input for
>> an IP, or auto selects from a pool? That would would seem to be a far
>> simpler solution that forcing Discovery into a different role.
>
>
> the problem there is with hostgroup based provisioning, you dont get an
> identity, puppet won't run etc

Ok, that's fair. We could improve that though. The way the Discovery
rules generate a hostname could be used for Hostgroup provisioning
too, and the hostgroup provisioning methods in the controller could
easily generate a basic host from the other defaults in the group.
Orchestration would then be easy to attach.

> , as the operation is not audited, there is no tractability etc etc.

Audit is irrelevant here, as you don't get any traceability from
Discovery either (the API will create the host, not the guy in the
datacentre). If you want to know who racked that machine, then that
user will have to create the host.

> however, if the admin, decided to create a rule that provision into a given
> hostgroup, i think its fine, but I dont think we should allow any operator
> to create a db host from the db hostgroup and get the super secure password.

That doesn't make sense to me. The operators shouldn't have login
access to these hosts anyway (or not superuser login). If they do,
then it doesn't matter if Discovery does the provisioning or
Hostgroups do - they can still log in and get the data you're worried
about.

I still don't like the idea of this being part of Discovery though (of
course, that's just my vote) - it's a manual addition to an automation
tool. However, I can see me losing this debate in the short term :).
It shouldn't be much work to add static IP configuration options to
/proc/cmdline and make use of them. Going further, integrating
Bootdisk and Disocvery could also be interesting if Bootdisk could
provide a prewrapped image with a nice way to ask for that IP data…

Greg

··· On 2 March 2015 at 14:05, Ohad Levy wrote:
17

i faced several customers with those why:
-dhcp disabled for security reasons.
-lots of vlans so using multiple dhcpservers of relays just for
installation seems cumbersome

  • in virtualization world, using a dedicated install net requires
    additional hacks to change the vlan to its final destination.
    -even for bare metal, for older hardware, there s a need to force dhcp on
    the first nic.
    regards,
    -bonus point: in the virtualization world, what s the point of kickstarting
    when you can cloudinit and use puppet or whatever to configure.

regards,

··· El 02/03/2015 17:34, "Bryan Kearney" escribió:

On 03/02/2015 11:27 AM, Greg Sutcliffe wrote:

On 2 March 2015 at 14:18, Bryan Kearney bryan.kearney@gmail.com wrote:

I will let Ohad jump in here, but as often as I hear DHCP is bad… I hear
PXE is as well.

Do you have any data on why? I’d love to challenge that statement,
but without understanding why, I’m battling a religion, not a
viewpoint :wink:

I have no data… only customer facing folks who say “My customer does
not allow DHCP or PXE”.

– bk

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