Bug #800
closed
No support for defining next_server in DHCP
Added by Mark Bainter over 13 years ago.
Updated over 5 years ago.
Description
Currently an attempt to lookup the 'nextServer' results in 'true' which is not a valid value.
Should return the name of the tftp server, which I suppose should be defined in the config file.
- Target version set to 0.2
- Status changed from New to Closed
- Assignee set to Mark Bainter
- Status changed from Closed to New
- Assignee deleted (
Mark Bainter)
- Status changed from New to Closed
- Assignee set to Mark Bainter
- Description updated (diff)
I know it's been some time (8 years) but do you guys remember why TFTP server name was designed to be a setting and call in a smart proxy and not Foreman app itself? This I think belongs to Subnet model as a field that users could define. I am thinking of refactoring this however I am failing to understand why this was added this way, maybe I am missing something. But I don't see a single use of this setting in the smart-proxy codebase. Thanks!
From https://github.com/theforeman/foreman/pull/6465#discussion_r311097406 I'll share my understanding:
The purpose is service discovery. Let's say you have the following setup:
foreman.example.com
dhcp.example.com
tftp.example.com
Now Foreman can query the foreman-proxy on tftp.example.com which address clients should use. Then on dhcp.example.com it can create the DHCP record with the correct TFTP server address.
If you didn't have this, then the user needs to manually do this. Since multiple DHCP servers can share the same TFTP proxy this is actually useful. All the user has to do is select the correct proxy for TFTP.
Lukas Zapletal wrote:
I know it's been some time (8 years) but do you guys remember why TFTP server name was designed to be a setting and call in a smart proxy and not Foreman app itself? This I think belongs to Subnet model as a field that users could define. I am thinking of refactoring this however I am failing to understand why this was added this way, maybe I am missing something. But I don't see a single use of this setting in the smart-proxy codebase. Thanks!
AFAIR ISC DHCP over omshell will not accept a hostname, just ip, and I think we resolve it on the proxy in case anyone is using dns aliases or something like that.
Thank you both, I think we need to keep the setting on the proxy (but we can probably leverage capabilities instead) and probably keep the IP only (since we heavily rely on OMSHELL). I need to test this first.
Also available in: Atom
PDF