Engineering Software, Linux, and Operations. The website of Jack Neely.    

Thoughts on gPXE

  January 2, 2012   Operations

I maintain a RHEL deployment with automatic installs.  You PXE boot, type in a version string that equates to your RHEL version and arch and during the install process you get the Red Hat Kickstart that matches your fully qualified host name.

So no images here.  All installs are based on descriptions of what the end result should look like rather than a large image of it.  Especially with a large install base these descriptions scale much better than having a place to store what would be thousands of images.

However, VM Farms and other cloud based technologies really like working with images. They’re easy I guess.  Slap the image down and boot it.  Somehow I need to merge both worlds.  Step in gPXE or formally Etherboot.  Its an Open Source PXE boot loader that is highly scriptable.  I could hand out an image to those that want them that when first booted would query our Kickstart system and being the install.  The images are small, the kernel/initrd files are stored on the TFTP server so they can be updated with out modifying the gPXE images, and they can trigger fully automated installs.

Did I mention scriptable?  With a bit more magic, I can use a token to reference my Kickstart rather than host name and create custom gPXE images that install by referencing this token.  This solves the issues with cloud environments where we don’t know the target machine’s FQDN until the machine is dynamically provisioned.  But that begs the small question of how to build these custom gPXE images for each customer.  The gPXE source actually has GNU make targets and variables that even automate this process for you.  A small web app to build your gPXE image based of your magic token become very easy.

I’ve got some coding to do.

 Previous  Up  Next

comments powered by Disqus