DHCP configuration installed via `foreman-installer` vs. DHCP configured via Foreman > Infrastructure > Subnets

Support
1

Problem:

I am trying to figure out how to configure a single Foreman server to have two DHCP subnets on two different interfaces.

We used foreman-installer to install Foreman + Puppet, and I don’t see an option to configure multiple DHCP subnets. Is there a way to configure multiple DHCP subnets via foreman-installer?

In Foreman UI itself, under Infrastructure > Subnets, we have defined multiple subnets already. If we make a change via the Foreman UI, how are these changes pushed out to the node? Are they pushed out at all?

Expected outcome:

Foreman and Proxy versions:

Foreman and Proxy plugin versions:

Foreman 1.23.2
Foreman Proxy 1.23.2

Distribution and version:

Ubuntu 18.04 LTS

Other relevant data:

2

Ok we really need to tackle this @spetrosi @mcorr and @ekohl. IMHO users need to be told in the planning guide and/or installation guide how to handle this.

Stefan, unfortunately Foreman does not perform any subnet management, you need to take care of this. Our installer only supports one subnet, then you need to use custom-hiera.yaml to add multiple subnets. Foreman only uses OMAPI to talk with DHCP server creating records within those subnets.

The above statement should be probably in the Planning Guide. Then we need to put this into the Installation Guide:

https://theforeman.org/2017/07/adding-new-subnet-for-provisioning.html

@ekohl to confirm if these instructions are still valid.

2 Likes
3

Do you have any examples of doing this with DHCP? I see examples for Apache and Postgres, but those are simpler examples as there is only one entity. Since the primary DHCP subnet already exists, I’m confused how I would add a second thing.

4

I have only configured one additional one using this syntax:

dhcp::pools:
 isolated.lan:
   network: 192.168.99.0
   mask: 255.255.255.0
   gateway: 192.168.99.1
   range: 192.168.99.5 192.168.99.49

I am not sure what you mean, you create the file and run our installer which runs Puppet which sets everything up. Alternatively, you don’t need to use the installer and you can turn off DHCP management and start editing config files manually.

5

The biggest problem is that DHCP or really ISC DHCP isn’t easily managed without knowledge. It also has no API to manage it. That’s why there’s no support in the Smart Proxy to manage subnets themeselves, only entries within the subnets. All subnet management is out of band.

Historically a common way for doing this was when people used the Puppet modules, they queried Foreman for the subnets. If you’re a Puppet user, I would still recommend to use the modules directly and avoid the installer.

For non-Puppet users that means you need something else. The installer can set it up, but only provides very limited options on the CLI. With the installer I don’t know how you’d reasonably expose the complex options on the command line without confusing the user.

On the one hand there’s a very strong desire from many users to simplify the installer and for a lot of them that meant removing options to customize. @tbrisker has argued to completely drop DHCP management from the installer and fully move the responsibility to the user. On the other hand, there’s also a desire that features should just work, end to end. Clearly those two are at odds.

For DHCP management in particular, there have been changes but https://github.com/theforeman/puppet-foreman_proxy/blob/master/manifests/proxydhcp.pp is virtually unchanged. If you go back to the first version from 2012 and compare it to today’s version you see that it gained variables and failover, but otherwise it’s still just “deploy DHCP with a single pool”.

The big question is: where should we end up? And if we know that, who’s going to implement it? Or are we happy enough with the current situation?

2 Likes
6

Understood. That’s what I will try.

The foreman-installer makes some things super simple, however it’s complicated to look inside to figure out what it’s doing and to know if the options are necessary. For example, foreman-installer adds this, but theforeman::dhcp doesn’t. I’m not familiar enough to know if I need this logic or not. This is one reason I avoided using the Puppet modules initially.

# Bootfile Handoff
option architecture code 93 = unsigned integer 16 ;
if option architecture = 00:06 {
  filename "grub2/bootia32.efi";
} elsif option architecture = 00:07 {
  filename "grub2/bootx64.efi";
} elsif option architecture = 00:09 {
  filename "grub2/bootx64.efi";
} else {
  filename "pxelinux.0";
}
7

For example, foreman-installer adds this, but theforeman::dhcp doesn’t.

Just to clarify, I don’t need support here (I’ll figure it out). I’m just trying to illustrate a point as a user. I’m not sure how to do this all via Puppet modules.

-= Stefan

8

Just for the record since others might run into this same problem.

I want to manage the DHCP subnets using the theforeman/dhcp Puppet module. However, I still need Foreman itself to be able to use DHCP to PXEboot hosts.

I think the right way to do this is to use the following flags for Foreman Installer, which will activate the DHCP Proxy but disable Foreman’s management of the DHCP configuration:

foreman-installer --foreman-proxy-dhcp true --foreman-proxy-dhcp-managed false

If I try to disable DHCP using foreman-installer --foreman-proxy-dhcp false, then when I had Bare Metal hosts to Foreman and try to build them, Foreman complains with [ERF12-6899].(ERF12-6899 - Foreman).

1 Like
9

This works for me. Thanks for the suggestions.

10

Thanks.

1 Like
11

Btw, for some reason this was added to the Katello docs (Foreman :: Plugin Manuals) but never to the Foreman docs, even though it’s not Katello specific.