pxe menu variables
johnwc opened this issue · 18 comments
Other than fog-ip, what all other variables are able to be used? We specifically are looking to use hostname of the registered host.
I have a tutorial here in the FOG forums that talk about post install scripts. This post should show you the available variables: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/17?_=1692046939324
We're looking for preinstall variables that can be used during PXE booting. So I can tell the bootloader kernel arguments what config file to pull for this specific host that is booting.
Example: The is a PXE menu item parameters, we need to dynamically fill in the ${hostname} part. Similarly how it does the same for ${fog-ip}
kernel tftp://${fog-ip}/os/harvester/harvester-v1.1.2-vmlinuz-amd64 tftp://${fog-ip}/os/harvester/harvester-v1.1.2-initrd-amd64 ip=dhcp net.ifnames=1 rd.cos.disable rd.noverifyssl console=tty1 root=live:http://${fog-ip}/os/harvester/harvester-v1.1.2-rootfs-amd64.squashfs harvester.install.automatic=true harvester.install.config_url=http://${fog-ip}/os/harvester/config-${hostname}-join.yaml
initrd tftp://${fog-ip}/os/harvester/harvester-v1.1.2-initrd-amd64
boot
I don't know specifically if the hostname variable is set. The iPXE environment is a bit limited in regards to variables from FOG. The boot.php program does the variable replacement before the iPXE menu is created. It may be possible to add the required variables, but I don't know myself how its done.
If you want to see what variables are in the FOG iPXE menu you can with a browser make a call to http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00
That will show you the ipxe menu text. You should see how the variables are built.
Now I don't know your workflow, but you could do some call logic changes in the fog post init script. This script is run before any imaging starts. You will have access to the FOG variables in there too.
This is what we are following to get things booted. If there is a way to make this so that each registered host has its own config file set in kernel parameters, that is what we are looking for. From the docs it is all being loaded from preconfigured image files, do/should we be uploading those to fog instead, and using them that way. Any and all suggestions/help is needed and appreciated.
https://docs.harvesterhci.io/v1.1/install/pxe-boot-install/
Our expectations with using FOG was the following scenario
- Boot new server into PXE, registering it with FOG via PXE menu.
- Configure host in FOG with correct name along with kernel parameter with correct config file name.
- Boot server into PXE, using menu item to install harvester based on link.
- Server now boots from disk unless manually told to boot to PXE to reinstall harvester.
Can this scenario be done?
By FOG our "setting variables" are:
${fog-ip} - The url (normally the IP address) to access your fogserver # always
${fog-webroot} - The webroot to access your fog server. # always
${boot-url} - Set to the system on bootmenu creation. Includes http schema (http/https) webserver/IP address and the bootpath to access your fogserver. # always
${setmacto} - Newer versions but for knowing what mac address host is using to perform any specific thing in FOS (register, image, etc...) # always for simplicity
${storage-ip} - When imaging need to know this (even on non-registered hosts) so stores this from the default or image specific node. # only on imaging tasks
${arch} lets us know what type of system (x86_64 or i386) # always
${key} - If you have hidden menu what key sequence to press to unhide it # only when hidemenu
${keyName} - so we can present the user with the specific key to press # only when hidemenu
${imageID} - What image ID are we using for the tasking if it is an imaging test? # Only when imaging task
Those are the ipxe variables we (FOG) set as needed.
Sure we could add more default items. Will likely want to refactor the whole bootmenu system in the near future as it's quite convoluted and complex if you ask me. It was from very early in my time and while does what it needs to, almost noone else can follow it nicely lol. Even myself sometimes.
Expanding on it to allow variables specific to each host would be wonderful. We currently have to edit the menu prior to booting a server to make sure the settings are correct for that server. That or keep adding new menu items per server, which will make our list very long.
So I could understand hostname being there, but what other variables would be necessary?
Mind you, for your usecase is not of benefit (necessarily) for all, so if we don't add something specifically that you're requesting, it's not a dig specifically at you, just that it didn't make sense from a "general" approach.
hostname absolutely makes sense (in my opinion) but what other variables might be necessary that could potentially be useful for everyone?
Anything related to the host.
- hostname
- mac address
- anything else you pull in from a inventory that could be pertinent
Also, is there any documentation with examples of what these three fields control?
It would be handy to have some fog script variables available in the ipxe menu for conditional menu displaying. There is a current post in the fog forum where someone wants to implement a fix as the default response to the ipxe menu until the fix was applied then revert to the default boot to hard drive response from the ipxe menu. Having access to unused fields like othertag or othertag1 could create a flag if set the ipxe menu could do something different.
For reference it appears these variables plus a few dynamic ones are available currently in the ipxe menu.
ftp # IP Address from Storage Management-General
hostname # Host Name from Host Managment-General
img # Image Name from Image Management-General
mac # Primary MAC from Image Management-General
osid # Host Image Index number from Image Management-General
storage # IP Address + Image Path from Storage Management-General
storageip # IP Address from Storage Management-General
web #IP Address + Web root from Storage Management-General
Here is a list of additional variables that is available to the postdownload scripts (unrelated to the ipxe menu).
hostdesc #Host Description from Host Managment-General
hostip # IP address of the FOS client
hostimageid # ID of image being deployed
hostbuilding # ??
hostusead # Join Domain after image task from Host Management-Active Directory
hostaddomain # Domain name from Host Management-Active Directory
hostaduser # Domain Username from Host Management-Active Directory
hostadou # Organizational Unit from Host Management-Active Directory
hostproductkey= # Host Product Key from Host Management-Active Directory
imagename # Image Name from Image Management-General
imagedesc # Image Description from Image Management-General
imageosid # Operating System from Image Management-General
imagepath # Image Path from Image Management-General (/images/ assumed)
primaryuser # Primary User from Host Management-Inventory
othertag # Other Tag #1 User from Host Management-Inventory
othertag1 # Other Tag #2 from Host Management-Inventory
sysman # System Manufacturer from Host Management-Inventory (from SMBIOS)
sysproduct # System Product from Host Management-Inventory (from SMBIOS)
sysserial # System Serial Number from Host Management-Inventory (from SMBIOS)
mbman # Motherboard Manufacturer from Host Management-Inventory (from SMBIOS)
mbserial # Motherboard Serial Number from Host Management-Inventory (from SMBIOS)
mbasset # Motherboard Asset Tag from Host Management-Inventory (from SMBIOS)
mbproductname # Motherboard Product Name from Host Management-Inventory (from SMBIOS)
caseman # Chassis Manufacturer from Host Management-Inventory (from SMBIOS)
caseserial # Chassis Serial from Host Management-Inventory (from SMBIOS)
caseasset # Chassis Asset from Host Management-Inventory (from SMBIOS)
location # Host Location (name) from Host Management-General
ref: https://forums.fogproject.org/post/69723
I'm not suggesting that we should do this, but there are occasions where it would be handy to have some of the common variables, at least the tags to help with creating some unique flows in the iPXE menu.
@George1422 I don't think all those are available, as @mastacontrola already listed what is usable. Are you referring to something else?
Anything related to the host.
- hostname
- mac address
- anything else you pull in from a inventory that could be pertinent
Also, is there any documentation with examples of what these three fields control?
Those relate to alternate versions of the fos kernel and init.
I don't know that we have a kernel args parameter list, there are some custom ones like debug=yes but also uses the universal kernel args I believe. I don't know that there are examples at docs.fogproject.org in the host management section but I know we have at lease a description of these fields. They're really only needed for special cases with special or legacy hardware or when you have custom kernel or inits.
The kernel is the bzImage file and the init is the init.xz
you can have other kernels and inits in the /var/www/fog/service/ipxe folder and reference them by case sensitive name
Could the new secure method of accessing hostInfo.php be used here? @mastacontrola
Could the new secure method of accessing hostInfo.php be used here? @mastacontrola
No, this issue is related to the pxe menu that is built from the php. So, no scripts are running yet. We need to be able to use other variables in the parameters field.
Example, instead of using config-hyper09-join.yaml I could use config-${hostname}-join.yaml or possibly config-${mac}-join.yaml. We are using FOG as a way to inventory hosts, then select menu item to boot pxe image to install Harvester on bare metal.
Do you mean FOG, what is FOS? I was under the impression that stood for Free Open Source.
So:
the "everything under the sun approach" only works if somehow we know everything under the sun is going to be used.
This isn't to say we can't add it, but it's adds to memory size of the menu (each variable needs to be stored somewhere), and clutters the code to build the menu.
I have created a new function called generateIpxeItems
This will dynamically build the properties of the inventory item for the host (when there's one to be found.)
The function is defined currently as such:
/**
* Builds the std class property and value items as appropriate
*
* @param object $object
* @return array
*/
public static function generateIpxeItems($object)
{
$ignore_keys = [
'id',
'hostID',
'DT_RowId',
'createdTime',
'deleteDate',
'sec_time',
'deployed',
'hostLink',
'token',
'tokenlock',
'createdBy',
];
$output = [];
foreach ($object as $property => $value) {
if (in_array($property, $ignore_keys) or is_object($value) or !$value) {
continue;
}
if (is_array($value)) {
$count = 0;
foreach ($value as $item) {
$output[] = "set {$property}{$count} {$item}";
$count++;
}
} else {
if ($property == 'name') {
$property = 'host' . $property;
}
$output[] = "set {$property} {$value}";
}
}
return $output;
}
Why am I ignoring things? because somethings makes no sense to pass in (such as empty values) and other things are "security" conscious. If you would like them displayed, feel free to adjust those items to your hearts content.
Basically, the 'id' of the item (inventory or host) is unique for that thing but irrelevant to the needs of some dynamic menu. Since on this DB host id 1 for example, could be host id 156 on another, etc... you wouldn't really want to use this as a means to dynamically build your menu.
The hostID is removed from the inventory item (or any item you may pass to this function) for the same type of reason above.
DT_RowId is just the ID of the object that's being used (but used for datatables in the UI. This is not necessary to be used here.)
Created time, delete date, createdBy, deployed, sec_time - What possible use would you have for the date-time to generate somethign (especially since these are down to the second. There's no comparators, so I don't see the value in these being provided.
The hostLink is more for the UI. I doubt (though happy to be wrong) that someone is going to build an iPXE menu based on something that is an anchor tag.
These token/tokenlock, ADUser,ADPass,ADOU,ADDomain are hidden as these are security items. Necessary for the hostinfo.php stuff that @darksidemilk was referring to. This is not useful for this particular layout.
createdBy is hidden as this is just the user who "created" the item. However, this could be used, it may not have your intended operations. Why? Well fog the "user" may have created the inventory item but joeschmoe created the host object. which "createdBy" item should we use?
Other bits that are filtered are if the property itself is a subobject (say, inventory returns the host object in its payload, you wouldn't be able to parse it into the list and you already have the direct host item itself anyway) an array or the value isn't defined at all.
So your "mac" address is already used, but you now will have "primac" and "macs0" should reference the same value as "primac" but they're both there.
The only downside is that I don't know what will or won't be available each and everytime, but any of the host or inventory items can build a variable named item.
Arrays will build items of <propertyName><indexOfvalue>
This should address all the concerns and provide all the information you were hoping for. I'm sure there will need to be a couple adjustments here or there, but this is what I got for now.
@mastacontrola how do we get a dump of all the variables that are available for use?
Never mind, I used the link shared in comment above and can see the sets.
When do you think this will be out in production?
I don't have a timeline for when this will become the "stable" release. I can say, if you install working-1.6 on your production environment, "When that happens is when it's 'out in production' :) "
I need more testing of the working-1.6 as I'd much prefer to release that than another incremental of 1.5 at this point though and that's where I focused this code.
It's pushed into the working-1.6 branch. I would strongly recommend updating to that branch https://docs.fogproject.org/en/latest/installation/server/install-fog-server/#choosing-a-fog-version