Switching from Cobbler - Questions

Support
1

Hey everyone,

We're entertaining the idea of switching from Cobbler over to Foreman. Not
because of any big issues we've had with Cobbler, but more of a future
proofing, as Cobbler development has slowed dramatically. Before we do
that though, I have some questions about how to translate certain functions
from Cobbler to Foreman.

First off - our infrastructure:

  • We have a largish infrastructure ( 30k+ systems ) and most of our Cobbler
    provisioning deals with bare metal systems. We do some VM installs, but we
    treat then pretty much exactly the same as BMs.
  • For each hosting zone, it has a dedicated, non-routed provisioning VLAN
    that has no access to the internet or even other services within our DC
  • Each of our Cobbler servers ( we have 9, for the different hosting zones
    ), is dual-homed, with one NIC on the run network for that zone, and the
    other on the provisioning vlan.
  • We provision a mix of OEL, RHEL, CentOS and Windows via Cobbler.
  • We're a Salt/Chef shop - no Puppet

So, onto some questions:

1 - Cobbler's ks_meta - This seems to translate directly over to Foreman's
Parameters - is that correct? We can set various key/value pairs and use
those in the templates/snippets to direct the build?

2 - Do foreman parameters accept more complication structures than just
k=v, like dicts, lists, nested versions of those, etc?

3 - This feels like a dumb one, but where the heck do you host your OS
media? In Cobbler, we host the media on each individual Cobbler server and
sync it from a central source. I could only find options to point at an
NFS mount or some URL. Cobbler generally handles loading the media into
it's tree for you, does Foreman have something like that?

4 - How do you deal with dual-homed installations? I've gone over some of
the documentation and I'm unsure if it's just using smart proxies, or
subnets, or even the Locations feature

5 - Windows provisioning - anyone played with this? We use iPXE's wimboot
in Cobbler to boot into WinPE and install from there

6 - Can you call arbitrary URLs from a provisioning host to the Foreman
server ( or whatever we'd be using, smart proxies? ) to get a generic
template that's rendered for the host? For instance, during a Windows
installation, we'll call up to Cobbler's
/cblr/svc/op/script/system/acme.example.com?script=somescript.cmd and it'll
return a templated version of the script for that host.

7 - Foreman's hooks. We tried to use Cobbler's triggers, but they were too
generic. We have orchestration in our builds where we call a URL on the
Cobbler server and have it execute a script for us on the Cobbler server
itself. We use this for sending events up to our Salt master. We ended
up just writing our own WSGI app to do this and the provisioning host calls
it and sends the event.

8 - Log shipping. We use Cobbler's anamon process to ship over logs from
the provisioning host, during the provision, back to the Cobbler host and
upload those into Splunk, so we can watch a provision run remotely.
Anything like this in Foreman?

I could probably come up with alot more, but that's probably too many as is.

Any help with some general guidelines or pointers at specific points of the
documentation that speak on how to do these would be appreciated.

Thanks

··· -- sh
2

> 1 - Cobbler's ks_meta - This seems to translate directly over to
> Foreman's Parameters - is that correct? We can set various key/value
> pairs and use those in the templates/snippets to direct the build?

Yes, pretty much the same. They inherit too, see "Global parameters" at
Foreman :: Manual.

> 2 - Do foreman parameters accept more complication structures than just
> k=v, like dicts, lists, nested versions of those, etc?

No, only smart class parameters and variables do this. Those are
typically only used with Puppet and other config management, not
provisioning templates where regular parameters are only strings.

> 3 - This feels like a dumb one, but where the heck do you host your OS
> media? In Cobbler, we host the media on each individual Cobbler server
> and sync it from a central source. I could only find options to point
> at an NFS mount or some URL. Cobbler generally handles loading the
> media into it's tree for you, does Foreman have something like that?

No, I'd keep it external and use mrepo, apt caching and similar.

> 4 - How do you deal with dual-homed installations? I've gone over some
> of the documentation and I'm unsure if it's just using smart proxies, or
> subnets, or even the Locations feature

At its simplest, add a Subnet to Foreman for each unique network that
you're provisioning onto. You will need basic network services (DHCP,
TFTP, DNS) available in both - if you're hosting this on the Foreman
server then just ensure they're configured to listen/serve on every
interface. Remember that it's only really DHCP that needs presence on a
subnet (and only then if you're not using relays), both TFTP and DNS can
be routed.

You can put those services on remote hosts in those networks by
installing a smart proxy service onto it, which lets Foreman manage
those DHCP/TFTP/DNS services (add/remove entries). Foreman needs access
to connect to that smart proxy port (typically 8443/tcp). You'd then add
the Subnet/Domain again in Foreman, but be able to select that other
smart proxy for DHCP/TFTP.

> 6 - Can you call arbitrary URLs from a provisioning host to the Foreman
> server ( or whatever we'd be using, smart proxies? ) to get a generic
> template that's rendered for the host? For instance, during a Windows
> installation, we'll call up to Cobbler's
> /cblr/svc/op/script/system/acme.example.com?script=somescript.cmd and
> it'll return a templated version of the script for that host.

Yeah, but it's limited to known types of templates. There's a template
type called "script" which would let you have a single script assigned
to a host and accessible with GET /unattended/script from the host.

> 7 - Foreman's hooks. We tried to use Cobbler's triggers, but they were
> too generic. We have orchestration in our builds where we call a URL on
> the Cobbler server and have it execute a script for us on the Cobbler
> server itself. We use this for sending events up to our Salt master.
> We ended up just writing our own WSGI app to do this and the
> provisioning host calls it and sends the event.

I don't think anything like this exists. The closest might be
foreman_hooks but it only lets you add scripts to certain events in
Foreman's object lifecycle.

> 8 - Log shipping. We use Cobbler's anamon process to ship over logs
> from the provisioning host, during the provision, back to the Cobbler
> host and upload those into Splunk, so we can watch a provision run
> remotely. Anything like this in Foreman?

I don't think so.

··· On 15/07/16 06:52, Steve Hajducko wrote:

–
Dominic Cleal
dominic@cleal.org

3

+1 to everything Dominic said, plus:

> 2 - complex data types for params

As Dom said you can't do it today, but I believe it's being worked on, in
case that matters to you. In the meantime, for relatively trivial cases you
might also be able to do things like using a comma-separated string and
calling .split(',') on it in the template.

> 5 - Windows provisioning - anyone played with this? We use iPXE's wimboot
in Cobbler to boot into WinPE and install from there

There's a system for using wimboot with Foreman that some of the community
have been working on - see https://github.com/kireevco/wimaging and there
was a Deep Dive into it, see https://www.youtube.com/watch?v=_R8-0KAkoPc

> 7 - re Salt

Depending on exactly what you're sending to the Salt master, the
foreman_salt plugin may already handle it. Worth looking into, certainly.

Greg

4

Thanks for the replies. Most of these seem doable - I'd have to consider
how we'd accomplish the templated scripts in Foreman, as it sounds like you
can only have a single script and we use several of these calls during an
installation.

My biggest concern would be around the dual-homed networks.

  • Do we have to have Foreman control DNS? We already have DNS automation
    tools and have no wish to port that over to Foreman

  • We don't route any services to the prov vlan - including DNS. We make
    dhcp/tftp/http available to it, but those are all served by the provision
    Cobble server. Will that still work?

  • We only use DHCP for the provisioning process. Everything else has static
    IPs. I assume that's ok, as long as we let Foreman control the DHCP server
    on the prov vlan

  • Do we install one Foreman server for the entire DC in our case and
    replace the Cobbler servers with Smart proxies or would we need a Foreman
    server to replace each existing Cobbler server?

Thanks again - much appreciated

··· On Fri, Jul 15, 2016 at 4:08 AM Greg Sutcliffe wrote:

+1 to everything Dominic said, plus:

2 - complex data types for params

As Dom said you can’t do it today, but I believe it’s being worked on,
in case that matters to you. In the meantime, for relatively trivial cases
you might also be able to do things like using a comma-separated string and
calling .split(‘,’) on it in the template.

5 - Windows provisioning - anyone played with this? We use iPXE’s
wimboot in Cobbler to boot into WinPE and install from there

There’s a system for using wimboot with Foreman that some of the community
have been working on - see GitHub - AutomationD/wimaging: Windows Imaging Toolkit and there
was a Deep Dive into it, see https://www.youtube.com/watch?v=_R8-0KAkoPc

7 - re Salt

Depending on exactly what you’re sending to the Salt master, the
foreman_salt plugin may already handle it. Worth looking into, certainly.

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

5

> Thanks for the replies. Most of these seem doable - I'd have to consider
> how we'd accomplish the templated scripts in Foreman, as it sounds like you
> can only have a single script and we use several of these calls during an
> installation.
>
> My biggest concern would be around the dual-homed networks.
>
> - Do we have to have Foreman control DNS? We already have DNS automation
> tools and have no wish to port that over to Foreman
>

It's optional - if the Domain/Subnet (s) associated with the host don't
have a DNS proxy, Foreman will skip the record creation.

> - We don't route any services to the prov vlan - including DNS. We make
> dhcp/tftp/http available to it, but those are all served by the provision
> Cobble server. Will that still work?
>

I'm unclear from that on whether you made a typo with "Cobble server" or
you're planning to keep it for some services. I'm going to assume a typo
based on the questions below about per-DC provisioning - do correct me and
clarify otherwise :slight_smile:

For Foreman provisioning, you can achieve a completely segregated
provisioning network - the Foreman Proxy can relay templates. So long as
the proxy (which you'd have for TFTP/DHCP management anyway) has a route to
Foreman, it can retrieve rendered templates on behalf of the installing
host. See Foreman :: Manual
for more.

  • We only use DHCP for the provisioning process. Everything else has static
    > IPs. I assume that's ok, as long as we let Foreman control the DHCP server
    > on the prov vlan
    >

Yes, that's fine. The default templates (for Kickstart anyway) come with
static configuration snippets, and there's an IP allocation mode for the
Subnet in the UI. Set that to static, and the templates should render
correctly. For other OSs (you mentioned Windows? :p) then you may want to
see how we're detected the IPAM mode and re-use it in templates of your own.

> - Do we install one Foreman server for the entire DC in our case and
> replace the Cobbler servers with Smart proxies or would we need a Foreman
> server to replace each existing Cobbler server?
>

In general, and assuming all the proxies can reach the central Foreman
server, one Foreman server should be fine - it designed to scale out. You
have a fair number of options on how to separate out logical entities in
the UI, depending on who should have access to what, and so forth.

That said, you'll want to think about scale, no doubt, with the number of
systems you mentioned in the OP. It's quite possible to scale out the
various parts of Foreman itself (in addition to the obvious scaling of the
proxies) in different ways, so that's something we can go into if you need
more info.

Greg

··· On 15 July 2016 at 15:26, Steve Hajducko wrote:
6

>
>
> I'm unclear from that on whether you made a typo with "Cobble server" or
> you're planning to keep it for some services. I'm going to assume a typo
> based on the questions below about per-DC provisioning - do correct me and
> clarify otherwise :slight_smile:
>
> For Foreman provisioning, you can achieve a completely segregated
> provisioning network - the Foreman Proxy can relay templates. So long as
> the proxy (which you'd have for TFTP/DHCP management anyway) has a route to
> Foreman, it can retrieve rendered templates on behalf of the installing
> host. See Foreman :: Manual
> for more.
>
>
No, we'd be replacing the Cobbler server with a Foreman one entirely, I was
just reiterating that the only things that the installing hosts have access
to IS the 'Cobbler|Foreman' server, and in general, all we provide as a
service is HTTP/TFTP/DHCP to those installing hosts. The 'Cobbler|Foreman'
host would definitely have access to the Foreman server, which sounds like
it would work.

> - We only use DHCP for the provisioning process. Everything else has
>> static IPs. I assume that's ok, as long as we let Foreman control the DHCP
>> server on the prov vlan
>>
>
> Yes, that's fine. The default templates (for Kickstart anyway) come with
> static configuration snippets, and there's an IP allocation mode for the
> Subnet in the UI. Set that to static, and the templates should render
> correctly. For other OSs (you mentioned Windows? :p) then you may want to
> see how we're detected the IPAM mode and re-use it in templates of your own.
>

Yeah, Windows was… interesting. Basically, we iPXE, chainload into a
custom iPXE script, into a wimboot of a custom WinPE image, that figures
out the Cobbler server IP, downloads some scripts from it and runs them,
which then boots us into Windows, where we then download a Chef cookbook
and configure the host appropriately. I'm not super happy with it, as it
takes too many reboots ( and rebooting Dell R820's is a 5 minute process…
), so total provision time ends up at 30 min or so.

> That said, you'll want to think about scale, no doubt, with the number of
> systems you mentioned in the OP. It's quite possible to scale out the
> various parts of Foreman itself (in addition to the obvious scaling of the
> proxies) in different ways, so that's something we can go into if you need
> more info.
>
>
So I'm not sure we'd actually use too much of Foreman's lifecycle
management, as we have other tools for that. One of the main reasons we're
investigating it ( besides Cobbler's lack of development lately ) is
because the team in control of our yum repos is looking at deploying
Katello, which means we'd have Foreman anyways, so why not consolidate if
we can get it to work.

I did checkout the Salt plugin and it looks like it manages what we were
doing, although in a little bit of a intrusive way compared to our solution
( we just send an even through the salt-minion on the Cobbler host and the
master takes care of everything else… nothing installed on the master to
get it working )

Thanks for bearing with me Greg - sounds like I've got enough where we
could at least go to a POC stage on it.

··· -- sh