I’m creating a new thread to ease future reference for other community members (so they won’t have to read the whole original thread since I’m trying to sum up my experience and understanding of such a setup.
So, I did come up with a working setup. Let me sum up what I did, what I learned and what is still unclear to me :
What I wanted to achieve :
foreman with dual network interface, one in a public routable subnet, the other one in a private non routed subnet
foreman and its Smart Proxies on the same host
in order to provision hosts on the private subnet
How I did it :
eth0 : private ip/private name/domain
eth1 : public ip/public name/public domain
add a private interface in the private subnet to the “media” (distribution/packages mirror) host
foreman and media private ip/name in /etc/hosts
public dns in /etc/resolv.conf (for the bootstrap phase)
change the public dns to 127.0.0.1 in /etc/resolv.conf
add (via nsupdate) the mirrors A and PTR records in the corresponding zones
create needed objects in the UI (domain, subnet, media, OS, templates clones, host groups, hosts).
Note : the smart proxies are seen with their private names, which is what I want to ease contact with the client (or just make it possible without too much trickery)
What (I think) I learned:
subnet section in dhcpd.conf comes from --foreman-proxy-dhcp-subnets installer option, not from subnet “object” in UI
parameters such as ‘gateway’ or ‘dns servers’ in UI Subnet tab correspond to the network settings of the client when chosen to be in static boot. Nothing to do with dhcpd.conf
option router in dhcpd.conf comes from --foreman-proxy-dhcp-gateway installer option or is 192.168.100.1 (not to be confused with the gateway in the UI Subnet tab)
foreman installer seems to create a A record for foreman itself when the zone it’s in is foreman managed (but no PTR even if it manages the reverse zone also). Or is it for the foreman DNS Smart Proxy (they’re the same in my setup) ?
What I still wrapping my head around:
I was told by @lzap that next-server IP came from a reverse DNS lookup when not set with --foreman-proxy-tftp-servername : how can it be set then for me as I did not provide this option neither did I had a PTR record ?
where do the following dhcpd.conf directives come from : UI ? (I didn’t provide any domain neither --dhcp-server (thus should be 127.0.0.1 according to --help) installer option) :
when set in static boot mode, my client gets the expected gateway ( 192.168.10.10 I provided in the UI - not that I needed it since it’s a non routed network but just to test if it would be different from the default one (192.168.100.1), which I see in the dhcpd.conf file for my subnet. But when in dhcp boot mode, I don’t see any gateway. I was expecting this 192.168.100.1 default one on my client (since it’s what I see in my dhcpd.conf file as ‘option router’) : why ?
Am I correct assuming that PXE, tftp and DHCP and DNS dialog is between the to-be-installed client and the corresponding Smart Proxies directly (or does it goes through foreman server ?) and that kickstart (and corresponding templates) download is between the to-be-installed client and the Foreman server directly (or does it go through a Smart Proxy) ?
Not quite. First of all you are correct that Foreman currently can’t manage subnets on the actual system. You need configuration management or manual operation to create the subnets in your DHCP server. Our installer tries to help you by setting up one (there is a hidden way to add more via custom-hiera.yaml) but after that you’re on your own.
The option --foreman-proxy-dhcp-subnets controls the :subnets option in /etc/foreman-proxy/settings.d/dhcp.yml. dhcpd.conf comes from proxydhcp.pp. By default it derives the network and netmask from --foreman-proxy-dhcp-interface but you can override these with -dhcp-{network,netmask}. The PXE IP is also taken by default from this interface but again, -dhcp-pxeserver can be used to override this.
I’m not sure if it writes these in the lease file. If it doesn’t, then it’s good to know there are people who query the Foreman subnet API and create they DHCP config via configuration management (like Puppet) and then it does work like that.
We have a default value of 192.168.100.1 which I think was poorly chosen, but it’s there. You can provide --foreman-proxy-dhcp-gateway '' but we should really remove the default.
It should be able to create the PTR. If it doesn’t, that’s a bug. Note that selecting the DHCP proxy and DNS proxy are two separate settings on a subnet because that service can be handled by a different proxy.
I have never heard of the next-server IP being done through a reverse DNS lookup. The option --foreman-proxy-tftp-servername is to configure the tfp_servername option in /etc/foreman-proxy/settings.d/tftp.yml. This is useful in a multi homing setup where you run TFTP on a different IP than the smart proxy because by default the smart proxy hostname is used. It is true that the Foreman server resolves this value to an IP if it is a hostname. That is where /etc/resolv.conf might be important.
The domain name comes from --foreman-proxy-dhcp-option-domain which defaults to the domain fact. The name server comes from --foreman-proxy-dhcp-nameservers which default to the -dhcp-interface IP.
Note that for advanced users --foreman-proxy-dhcp-managed false can make sense if they want to manage DHCP themselves.
I just wanted to double check : if foreman main server runs on MainHost and I have Host1 as a tftp SmartProxy, Host2 as a DNS smartProxy, …etc…clients (hosts using those services) would talk directly to Host1, Host2, correct ?
The REST API is only/mostly for foreman <-> smartProxies orchestration ?
Ah, I didn’t know it did a IP -> reverse DNS -> forward DNS -> IP translation there. Even after years you can still find new things. The NicIpResolver does indeed do dark magic.
Ok thanks. It’s getting clearer.
May I ask, though it’s not in the scope I guess of this support forum, how things are proccessed from installer options to the actual file (in a general manner) regarding smart proxied services ?
I don’t know much of Ruby on rails and just the basics of Puppet (I tried CFengine and Ansible) so I’m a bit confused about how things unfold :
my understanding is that :
as you say, installer options translates in variables in the corresponding foreman-proxy/settings.d/*.yml files
puppet manifests are in the corresponding /usr/share/foreman-installer/modules/foreman_proxy/manifests/*.pp files
But regarding templates, I don’t get the whole picture since :
my dhcpd.conf seems to come from the /usr/share/foreman-installer/modules/dhcp/templates/dhcpd.conf.erbERB template
but since :use_provider: dhcp_isc is stated in dhcp.yml settings, I guess somewhere along the way /usr/share/foreman-installer/modules/foreman_proxy/templates/dhcp_isc.yml.erb may be used as well ?
Or asked in another way : what part template/manifest/… translates for instance subnet: in setting.d/dhcpd.yml into subnet in the actual file (the manifest you mentionned doesn’t seem to do it directly as far as I understand) ?
Well I never succeeded to make it create it at least.
Well in my case, since I’ve got no PTR, I guess somehow /etc/hosts is used, not pure DNS requests
Thanks for your (precious) help. It gives a more precise overview of the whole picture, which I’m sure is useful.
The short version is that you list classes that you want to expose and every parameter for that class is exposed as an option as --class-parameter (normalized to dashes). If data types are available then additional type checking is done.
All answers are stored in a YAML file which is transformed into hiera data and then included. At the end a puppet apply is ran.
The installer doesn’t care about RoR. It just tries to configure the system.
It’s just a puppet module, we do no special magic in our installer. The foreman_proxy module does install the package, configure files (see config.pp and run the service. It also includes the DHCP config (when $dhcp_managed is true) and that pulls in the DHCP class with a pool (subnet) in proxydhcp.
After our installer has ran, we point you to the Ruby on Rails application URL.
Can you show how you configured the subnet in the UI?
I learned a few about Puppet and now my understanding is this about the Foreman layout (I’m sure I over simplify it, sorry) :
for instance, for dhcp module/Smart Proxy :
puppet classes are defined in /usr/share/foreman-installer/modules/dhcp/manifests/*.pp (erb templates alongside)
puppet classes are declared in /usr/share/foreman-installer/modules/foreman_proxy/manifests/*.pp (erb templates alongside) in order to actually configure chosen Smart Proxies and generate corresponding service files.
installer command line options are changed into classes parameters via the tool you described (kafo)
Am I correct ? If so, I still don’t quite get if /etc/foreman-proxy/settings.d/*.yml files are a source (for instance to get classes parameter values to pass) or just dumped to reflect what’s has been done
Thanks and sorry, I might be too curious but again, my goal is not to have me explained the foreman internals knowing close to nothing about Puppet ! but to have a precise enough general understanding to be able to look at the right places to solve my initial setup issues (UI/installer what goes where …etc…)
kafo is a ruby gem looking into scenario.d/ for some yaml file describing the scenario (I guess it knows the file is a scenario vs an answer file because it has a :name ?)
the scenario indicates the location of the answer yaml file and the location of the modules storing the Puppet classes which parameters will be assigned values according to the answer file and/or the installer --arguments
values stored in turn in the same answer file
a migration mechanism similar in spirit to the RoR migration mechanism can track/replay scenarii upgrades
My questions are at this point :
do the params.pp manifests have special meaning (vs the other .pp files alongside) in this architecture ? (same question for the init.pp file)
I though dhcp or dns were Smart Proxies, so why do I see for instance dhcp related manifests in 2 different directories :
/usr/share/foreman-installer/modules/dhcp/manifests/*.pp AND
/usr/share/foreman-installer/modules/foreman_proxy/manifests/proxydhcp.pp
?
where does the /etc/foreman-proxy/settings.d directory fit into this architecture : what is it used for and who creates it ?
The puppet-dhcp module is a generic Puppet module which can be used to declare a variety of complex DHCP configurations - multiple zones, pools, ranges, etc. This is the module we tell people to go use directly when the installer can’t meet their needs.
The proxy module defines a very limited usecase of puppet-dhcp, for a single subnet - if you look in the code you’ll see that it parses the installer Puppet params and then calls the puppet-dhcp module with appropriate data. So it’s not 2 separate modules, only one module and a specific use of the module.
Context: the installer is meant to solve the 80-90% of install scenarios where a single subnet will be enough. More complex scenarios require using the puppet-dhcp module directly and disabling the call to it from puppet-foreman_proxy
It has nothing to do with the installer. Those files are the config for the proxy itself, once it’s up and running. The directory comes from the foreman-proxy RPM/DEB package, and the installer sets the correct config values in the appropriate files (e.g. enabled: true if you’ve enabled a feature, etc)
This is a puppet module pattern to determine the defaults for init.pp. Recently the preferred pattern has changed to hiera data in modules but many modules are still in the old style. Here is an example of a relatively simple module converted from params.pp to hiera. Note that by now Hiera format 5 is current but the general structure is pretty much the same.
sorry for the delay. I had to learn about Puppet, Kafo and take some time to understand how foreman-installer was laid out.
Regarding the no PTR for the foreman server itself, I did a fresh install on a new VM and as a matter of fact, I see a A record but no PTR record : here’s what I did :
Sorry, I hit return by mistake and for some reason I’ve got an error when I try to sumit an edit to my post. So here it is again :
Hello,
sorry for the delay. I had to learn about Puppet, Kafo and take some time to understand how foreman-installer was laid out
Regarding the no PTR for the foreman server itself, I did a fresh install on a new VM and as a matter of fact, I see a A record but no PTR record : here’s what I did (did not even log into the UI yet) :
