Our smart-proxies have multiple interfaces in different subnets.
The foreman_url is set to the hostname (primary inteface) of the smart-proxy. The additional Interfaces/IPs does not have an A record in our DNS.
The foreman_url parameter can be changed in the settings tab, but this changes the foreman_url universally.
Is there any option to change this parameter for specific subnets?
So far our solution is to create DNS-Records for the additional IP-Addresses which also point to the primary hostname of our smart-proxy. Otherwise a newly created host will try to contact the smart proxy on his primary interface during installation. This does not work because our subnets a separated by firewalls.
Expected outcome:
Possibility to change foreman_url for specific subnet.
This has been a problem for years. There was a request but the maintainers misunderstood what the request was for and closed it.
Everytime I upgrade I have to comment out the line in /usr/share/foreman-proxy//modules/dhcp_common/isc/omapi_provider.rb that adds nextServer to the statements array. I’m on 1.19 currently.
To workaround, I have a subnet parameter pxe_server that has the correct IP to use for the subnet, and have to substitute it in the foreman_url in some snippets as a result.
Is it not possible to just make multiple smart proxies, or in the case of foreman_url specifically, use location or rule aware load balancing?
We have something like 30 foreman servers behind an f5 ltm’s and gtm, and the gtm rules centrally handle redirection(s) to the proper “smart proxy” for the various foreman URL’s we have configured.
I’d imagine other load balancers have similar configuration options??
Maybe it helps as a workaround, maybe not, but setting this in the hierarchy could probably be a valid use case too I’d imagine
Why is it needed to specify multiple foreman URLs?
The design behind this is that the smart proxy with the TFTP feature knows the value of the nextServer value. This is configured in /etc/foreman-proxy/settings.d/tftp.yml via tftp_servername. Foreman will query for this when a host record is written. If unset, it falls back to the hostname of the smart-proxy. Do note that currently it’s resolved to a DNS name and then to an IP. That means it will do a reverse DNS lookup if it’s an IP. This may give an unexpected result and in https://github.com/theforeman/foreman/pull/6465 we’re looking at removing this behavior.
My reading of this (as I’ve commented) is that you shouldn’t select a Foreman TFTP proxy to avoid writing a nextServer entry. This may mean that it won’t download the TFTP files for you though. A possible solution may be to add the option to set tftp_servername to false in tftp.yaml and let Foreman interpret that as skip writing.
A maintainer. It was me, sorry. But I reopened the issue. Today, I have tested and I can confirm that setting PXE Loader to None does not prevent Foreman from writing the next-server. Let me fix that for you.
First: Wow I didn’t expect that this thread will get so much attention after 6 months.
Second: I think we are mixing two different topics.
Topic 1: The problem, that foreman overrides the next-server dhcp parameter
Topic 2: foreman_url will automatically be set to the DNS-Name of the responsible smart proxy
Let us assume that we have a multi-homed smart-proxy with two interfaces in different subnets.
Subnet A
Subnet B
Both subnets are seperated by a firewall.
In the past when I had to install a new system in the second subnet (subnet B) via PXE, I commented out the “next-server” parameter in the /etc/dhcp/dhcpd.conf file.
Otherwise the System, which I wanted to install would receive the IP address from the first interface (Subnet A) via DHCP.
After that change the DHCP-Part worked, but when the Installer (In my case anaconda, RHEL 7.X) started and tried to contact the smart-proxy for downloading the kickstart file,
it always tried to contact the smart-proxy via his first (Subnet A) interface.
This happened because foreman replaces the foreman_url variable with the hostname of the responsible smart-proxy.
There was no option (maybe nowadays?) to set the foreman_url parameter to another address or hostname. Aside from the global foreman_url value.
My solution so far is to create an additional A-Record with the same name in our central DNS for the Subnet B address of the smart-proxy… Which is not the cleanest solution…
Is there any other way to resolve this? Aside from installing a separate smart-proxy for Subnet B
The two things (changing the foreman URL and avoiding writing next-server to the dhcp lease) are actually related for me. I have several multi-homed smart proxies. In our production datacenters we have to do our builds over private non-routable networks. So each smart proxy server in those datacenters has a main interface to the rest of the world, and an interface to one or more of these private networks that do not have a gateway, and as a result cannot be reached by the foreman server itself or even have access to DNS.
When provisioning a host, the smart proxy would write the main IP of the smart proxy as next-server in the dhcp lease, and the foreman url would use the foreman hostname. In my case I need to change the foreman url to use the IP of the appropriate interface of the smart proxy since I don’t have DNS available at the time. That might be a little bit of a rare case considering how most people use foreman (we only use it as a traditional OS provisioning tool for on-prem VMs and physicals, similar to how people use Cobbler), but I do definitely appreciate the fix for next-server.
Are you using the Foreman Proxy Templates module? If you can reach the smart proxy main IP you can use http://$IP:8000 and let it rewrite the foreman_url.
Now, for the second part - what do you need foreman_url for? Provisioned nodes never need to reach out to Foreman app directly, we do provide complete isolation through smart proxy. If you need this for kickstart template or even iPXE templates, just use mentioned SP template module. When the SP module is installed correctly, Foreman app notice this and renders templates in a way that provisioned nodes reach out to Smart Proxy instead of Foreman core.
Thanks lukas I will give it a try next time I install a new system via PXE. Since it’s possible to let foreman automatically upload the bootdisk to the VMWare Datastore, we use the bootdisk-way to install new systems, works like a charm.
My problem was, that the the foreman_url will always be converted to the Hostname of the responsible smart-proxy. And this hostname normally points to the primary IP of the smart-proxy.
But for provisioning the system in the different subnet, the system which is going to get installed, should contact the smart-proxy on his secondary interface, not on the primary one.
If it’s just two NICs (Foreman <-> Foreman Proxy (LAN) + Foreman Proxy (Provision) <-> client) then you can configure the templates plugin to point to Foreman Proxy (Provision). I think this should be fully supported, including isolation where the client shouldn’t need to contact Foreman. If you encounter issues, then we should fix those (bonus points for patches).
When there are multiple provision lans, then our model breaks down. A common workaround will be to deploy multiple Foreman Proxies or allow routing. This is a known limitation. It’ll depend on how complex the fixes are whether we actually want to support this.
I will give it a try next time I install a new system via PXE. Since it’s possible to let foreman automatically upload the bootdisk to the VMWare Datastore, we use the bootdisk-way to install new systems, works like a charm. 