Facter-based dynamic PXEboot menu option

Support
#1

Hi list,

I'm new to Foreman.
First of all I would like to show my appreciation for your awesome
solution… thanks :slight_smile: !

I would like (to help implement) the functionality of a PXEboot menu
option, as I need the following badly in my current organization:
A. provide my clients in OFFICE [Facter: boardproductname,ipaddress(check
if we are in OFFICE-VLANs)] with a service to self-reinstall latest
supported OS on their laptops from a PXEboot menu - if they accidentally
choose PXEboot during startup, it should boot from local HDD after a
defined timeout = no harm done (that is - if they don't choose anything
else in the PXEboot menu) - not possible in Foreman today if you need
multiple dynamic menus
B. provide my clients in LAB [Facter: boardproductname,ipaddress(check if
we are in LAB-VLANs)] with a service similar to clients in office but
provide a wide range of supported OS's - not possible in Foreman today if
you need multiple dynamic menus
C. install each servers in DC [Facter: macaddress,ipaddress(check if we are
in DC-server VLANs)] with a specific OS depending on MAC - possible in
Foreman-discovery today
D. install my hadoop servers in DC [Facter: ipaddress(check if we are in
DC-hadoop VLANs)] with a specific OS 100% unattended – not possible in
Foreman today
E. keep everything centralized (not have to implement another provisioning
app)
Conclusion: we need Facter-based dynamic PXEboot menu options in
Puppet/Foreman to handle all scenarios !

To achieve this, I have thought of the following…
Flow description:
0. Client Bios settings (always: 1st=PXE ; 2nd=LocalBoot [HDD])

  1. Client PXE boots

  2. Puppet server microkernel loads

  3. Facter information is send to Puppet server (inventory on all equipment
    during boot time)

  4. New clients only: yes:->4.1 ; no:->5.

4.1 $Facter_macaddress in DB: yes:LocalBoot ; no:->5.

  1. PXEboot menu hardlink is created/changed/deleted based on configured
    Facter rule values [~firewall rules]: (01:$Facter_macaddress →
    PXEboot_menu_ID)

  2. Puppet server PXE loads

PXE webinterface menu (new, edit, delete)

Name Name of the PXEboot menu 32 chars

New_Client_Only Should this PXEboot menu only show to new clients checkbox

Facter rules What Facter rules should apply Facter prioritized “known
variables” + ”known possible values” multi dropdown

Boot images What images should available Multiselect dropdown
(PXEboot_menu_ID files will be created/deleted/edited when commands are
executed)

Please let me know your thoughts…

I haven't tested Windows provisioning in Puppet/Foreman yet, is this
supported ?
Otherwise, just if you haven't noticed: there is a opensource project (GNU
GPL) that already supports this (perhaps some code/ideas could be reused):
http://www.ultimatedeployment.org

Thanks in advance :slight_smile: !

~maymann

#2

> Hi list,
>
> I'm new to Foreman.
> First of all I would like to show my appreciation for your awesome
> solution… thanks :slight_smile: !
>

Glad you like it :wink:

Replies inline…

> I would like (to help implement) the functionality of a PXEboot menu
> option, as I need the following badly in my current organization:
> A. provide my clients in OFFICE [Facter: boardproductname,ipaddress(check
> if we are in OFFICE-VLANs)] with a service to self-reinstall latest
> supported OS on their laptops from a PXEboot menu - if they accidentally
> choose PXEboot during startup, it should boot from local HDD after a
> defined timeout = no harm done (that is - if they don't choose anything
> else in the PXEboot menu) - not possible in Foreman today if you need
> multiple dynamic menus
> B. provide my clients in LAB [Facter: boardproductname,ipaddress(check if
> we are in LAB-VLANs)] with a service similar to clients in office but
> provide a wide range of supported OS's - not possible in Foreman today if
> you need multiple dynamic menus
> C. install each servers in DC [Facter: macaddress,ipaddress(check if we
> are in DC-server VLANs)] with a specific OS depending on MAC - possible in
> Foreman-discovery today
> D. install my hadoop servers in DC [Facter: ipaddress(check if we are in
> DC-hadoop VLANs)] with a specific OS 100% unattended – not possible in
> Foreman today
> E. keep everything centralized (not have to implement another provisioning
> app)
> Conclusion: we need Facter-based dynamic PXEboot menu options in
> Puppet/Foreman to handle all scenarios !
>

I don't see where you're going with this - Foreman is intended for 2
things; one, to be a single point of truth for your infrastructure; and
two, to fully automate installs. To me, that means you should be adding
machines (regardless of which of the 4 cases above the machine is in) to
Foreman, and then letting the fully automated install handle the rest.
Showing a menu implies a user is interacting with the install, which by
definition is not unattended. To give a couple of examples of how I'd
tackle your use cases:

Build flag set, users cannot accidentally reinstall anyway
B: Give users control over {a,b,c,d}.lab.foo.com and allow them to set the
OS and Build flags to they can be reinstalled with desired OS
C/D: Add servers to Foreman, specify OS, boot/build them.

If what you're asking for is the ablilty to install an OS without creating
a Host in Foreman at all, then it seems to me that what you are actually
asking for is some form of subnet-specific "pxelinux.cfg/default" file
(rather than the Global one we have today) which is something we have on
the roadmap. If that is what you're looking for, then contributions are
welcome, and we can discuss design a little more.

An alternative approach is to use a default file which loads iPXE, and then
point iPXE to an HTTP url which contains more complex logic - this could be
Foreman (/unattended/gPXE), or a simple webservice that returns an
appropriate iPXE template based on the data provided. Worth looking into,
anyway, and far from re-implementing the whole provisioning app.

Hope that helps :wink:
Greg

··· On 14 July 2013 14:17, Michael Maymann wrote: A: Add myofficebox.office.foo.com to Foreman with correct OS - without
#3

>
>> Hi list,
>>
>> I'm new to Foreman.
>> First of all I would like to show my appreciation for your awesome
>> solution… thanks :slight_smile: !
>>
>
> Glad you like it :wink:
>
> Replies inline…
>
>> I would like (to help implement) the functionality of a PXEboot menu
>> option, as I need the following badly in my current organization:
>> A. provide my clients in OFFICE [Facter: boardproductname,ipaddress(check
>> if we are in OFFICE-VLANs)] with a service to self-reinstall latest
>> supported OS on their laptops from a PXEboot menu - if they accidentally
>> choose PXEboot during startup, it should boot from local HDD after a
>> defined timeout = no harm done (that is - if they don't choose anything
>> else in the PXEboot menu) - not possible in Foreman today if you need
>> multiple dynamic menus
>> B. provide my clients in LAB [Facter: boardproductname,ipaddress(check if
>> we are in LAB-VLANs)] with a service similar to clients in office but
>> provide a wide range of supported OS's - not possible in Foreman today if
>> you need multiple dynamic menus
>> C. install each servers in DC [Facter: macaddress,ipaddress(check if we
>> are in DC-server VLANs)] with a specific OS depending on MAC - possible in
>> Foreman-discovery today
>> D. install my hadoop servers in DC [Facter: ipaddress(check if we are in
>> DC-hadoop VLANs)] with a specific OS 100% unattended – not possible in
>> Foreman today
>> E. keep everything centralized (not have to implement another
>> provisioning app)
>> Conclusion: we need Facter-based dynamic PXEboot menu options in
>> Puppet/Foreman to handle all scenarios !
>>
>
> I don't see where you're going with this - Foreman is intended for 2
> things; one, to be a single point of truth for your infrastructure; and
> two, to fully automate installs. To me, that means you should be adding
> machines (regardless of which of the 4 cases above the machine is in) to
> Foreman, and then letting the fully automated install handle the rest.
> Showing a menu implies a user is interacting with the install, which by
> definition is not unattended. To give a couple of examples of how I'd
> tackle your use cases:
>
> A: Add myofficebox.office.foo.com to Foreman with correct OS - without
> Build flag set, users cannot accidentally reinstall anyway
> B: Give users control over {a,b,c,d}.lab.foo.com and allow them to set
> the OS and Build flags to they can be reinstalled with desired OS
> C/D: Add servers to Foreman, specify OS, boot/build them.
>
> If what you're asking for is the ablilty to install an OS without creating
> a Host in Foreman at all, then it seems to me that what you are actually
> asking for is some form of subnet-specific "pxelinux.cfg/default" file
> (rather than the Global one we have today) which is something we have on
> the roadmap. If that is what you're looking for, then contributions are
> welcome, and we can discuss design a little more.
>

Greg, you might be surprised to know, but foreman supports hostgroup based
provisioning… it basicilly just set up a menu (hence the @profile in the
tftp default pxe templates) per os, so you could boot from… not ideal,
as you can't complete a fully unattended provisioning proecss. but maybe
useful for someone… see [1] for more details

Ohad

[1]
http://projects.theforeman.org/projects/foreman/wiki/TemplateWriting#Hostgroup-based-rendering

··· On Mon, Jul 22, 2013 at 1:48 PM, Greg Sutcliffe wrote: > On 14 July 2013 14:17, Michael Maymann wrote:

An alternative approach is to use a default file which loads iPXE, and
then point iPXE to an HTTP url which contains more complex logic - this
could be Foreman (/unattended/gPXE), or a simple webservice that returns an
appropriate iPXE template based on the data provided. Worth looking into,
anyway, and far from re-implementing the whole provisioning app.

Hope that helps :wink:
Greg

–
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 http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.

#4

I know it does, in theory, but that @profile block in the default template
has never generated anything for me - I only ever have LOCALBOOT in the
default file. So I don't rely on it :slight_smile:

··· On 22 July 2013 12:53, Ohad Levy wrote:

Greg, you might be surprised to know, but foreman supports hostgroup based
provisioning… it basicilly just set up a menu (hence the @profile in the
tftp default pxe templates) per os, so you could boot from… not ideal,
as you can’t complete a fully unattended provisioning proecss. but maybe
useful for someone… see [1] for more details