As of today (April 2021) we use two specific workflows depending on whether we are dealing with a registered machine (present on LANDB) or an unregistered machine (no LANDB registry).
## Use case for unregistered machines
For machines not yet present on LANDB, it is the DHCP server who decides which bootfile/bootloader to use.
Take this ISC DHCP configuration extract as an example:
```
# Installation services require a divided pool for unknown devices. Only secondaries are allowed
(...)
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
option vendor-class-identifier "PXEClient";
vendor-option-space LINUX;
option LINUX.discovery-control 11;
next-server aims.cern.ch;
if option client-architecture = 00:00 { # Intel x86PC - in use now.
As the configuration shows, DHCP will decide which file to use depending on the vendor class, i.e. which architecture/bootmode the client is using.
The future KEA DHCP replacement also allows to do the same decission making.
## Use case for registered machines
Machines already present on LANDB have multiple properties. Among these, the Operative System, which will help deciding where to go to continue with the booting process.
Take these extracts from ISC DHCP configuration as an example:
```
# LINUX
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
option vendor-class-identifier "PXEClient";
option dhcp-server-identifier aims.cern.ch;
next-server aims.cern.ch;
}
(...)
# PXELINTEST
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
option vendor-class-identifier "PXEClient";
option dhcp-server-identifier aimstest.cern.ch;
next-server aimstest.cern.ch;
}
```
Depending on the OS the machine has on LANDB, it will go through one group or the other, pointing to the next server required for the PXE process, i.e. `aims.cern.ch` for `LINUX` or `aimstest.cern.ch` for `PXELINTEST`.
To ease debugging on our side and agility in changes, the decission making for these cases is in AIMS side. For this matter, we use `dnsmasq` in proxy-DHCP mode.
`dnsmasq` will just take these vendor class options and make clients use one filename/bootloader or other, depending on them. Just as the DHCP does.
On <https://gitlab.cern.ch/ai/it-puppet-hostgroup-aims/-/blob/qa/code/templates/dnsmasq_old_patched.conf.epp> you will find the matching we are currently using.
**PS: Please note for this `dnsmasq` matter we use an old version as newer ones do not behave well enough with old hardware models. We will eventually migrate to upstream `dnsmasq` once such hardware has been retired.**
## Considerations
* Any unregistered node will always go through the first use case
* For this case, we have to agree with DHCP service managers on which configuration, filenames and paths to use.
* We could standarise everything at some point if we agree on a way to debug PXE calls