Passing host variable to iPXE menu
-
@dcldn said in Passing host variable to iPXE menu:
Your solution worked perfectly, thank you so much, George!
The next time I chat with the developers, I’ll ask about making this a “feature” instead of a “hack”. If it is promoted to a feature it will be in the next release (1.5.0 stable [probably]) They won’t back port solutions normally.
-
I want to click a host (or group of hosts), click the Basic Tasks menu -> Advanced tasks and choose a “Deploy CentOS” task from there which starts the kickstart installation I’ve configured in the iPXE menu. It already works fine from the iPXE menu itself.
-
@dcldn yeah, then look at the link I provided. You will need to do some programming to complete that plugin. It is only a framework. It just so happens that the OP of that thread is doing something similar to what you need. Should there be better FOG documentation, simply yes. If you are willing to contribute, please do once you get it figured out.
-
@george1421 said in Passing host variable to iPXE menu:
@dcldn said in Passing host variable to iPXE menu:
Your solution worked perfectly, thank you so much, George!
The next time I chat with the developers, I’ll ask about making this a “feature” instead of a “hack”. If it is promoted to a feature it will be in the next release (1.5.0 stable [probably]) They won’t back port solutions normally.
I suspect there are people handing off to a different provisioning solution to handle hostname config etc. for nix hosts. It’s awesome being able to do this through Fog now, particularly in my environment where I have workstations dual booting Windows and Linux.
-
@dcldn Really the FOG Client for linux should do the same thing, if you image your systems like the windows folks do (create a golden image and then clone from that). Then the fog client will rename the system and install any snapins that you might want. But if you have a working solution run with it until you run into a show stopper. Then realize there are other ways to go about things too.
-
@dcldn The FOG Client works on Linux: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client
-
@george1421 said in Passing host variable to iPXE menu:
The next time I chat with the developers, I’ll ask about making this a “feature” instead of a “hack”.
AFAIK the hack is not needed at all if DHCP is properly propagating the hostname to the client within the DHCP answers as iPXE already has config setting
hostname
. So you should be able to just use${hostname}
(also see here). -
@sebastian-roth I don’t think this is possible here. I think we have the chicken and egg situation here. dhcp knows about the computer’s name because the client tells it during dhcp negotiations. In this case, the client is a new born and doesn’t know enough to tell the dhcp server its name. To get it to work correctly the OP may have to setup dhcp reservations to inform the dhcp server what the client associated with mac address xxxx is.
-
@george1421 said in Passing host variable to iPXE menu:
@dcldn Really the FOG Client for linux should do the same thing, if you image your systems like the windows folks do (create a golden image and then clone from that). Then the fog client will rename the system and install any snapins that you might want. But if you have a working solution run with it until you run into a show stopper. Then realize there are other ways to go about things too.
We currently provision our Linux boxes by bootstrapping with PXE/Kickstart which then hands off to Puppet to do the rest. I like this solution as we’re able to make incremental changes to the workstation estate through Puppet and we know that when we add a new box to the network it will end up with the same state. With that said, I can definitely see the benefits of cloning and it may be something we investigate in the future. We deploy Windows with FOG in the traditional way and it works great, multi-casting for example is a fantastic feature.
-
@george1421 said in Passing host variable to iPXE menu:
@sebastian-roth I don’t think this is possible here. I think we have the chicken and egg situation here. dhcp knows about the computer’s name because the client tells it during dhcp negotiations. In this case, the client is a new born and doesn’t know enough to tell the dhcp server its name. To get it to work correctly the OP may have to setup dhcp reservations to inform the dhcp server what the client associated with mac address xxxx is.
Exactly this. We should used to furnish boxes with the hostname through DHCP (using option 012) but it requires manually configuring reservations.