Continuing on my project to re-do my internal services, today we’ll talk about Preboot eXecution Environnement, AKA PXE.
\nThe principle is quite simple, and widely spread in everyday infrastructures.<\/p>\n
Most PXE setups I’ve heard about involve serving installation images for a single system.
\nMost tutorials I’ve found, struggling configuring my service, would stick to serving a specific image, most likely taken from the host system, …
\nAlthough PXE is able to provide with a complete set of systems, as well as live environments from memtests, BIOS update utilities as well as liveCDs.<\/p>\n
Being refractory to the idea of setting up an NFS server on a PXE server, I’m avoiding this later usage.
\nThe main reason being my former work involved OpenVZ virtualization: using NFS is usually a pain in the ass, assuming your physical host\/virtual host combination actually support NFS.
\nIf setting up a NFS client is most likely doable, setting up a NFS server remain a bad idea, … and well, I ended up avoiding all kind of NFS services running on my core services.<\/p>\n
Anyway, back to PXE. PXE use a very small set of commands. The kernel<\/em>, initrd<\/em> and append<\/em> being the most common booting a system. If unattended installations have limited benefits within smaller networks – not using CDs is still a big one – they are tremendous towards huge networks. Continuing on my project to re-do my internal services, today we’ll talk about Preboot eXecution Environnement, AKA PXE. The principle is quite simple, and widely spread in everyday infrastructures. Most PXE setups I’ve heard about involve serving installation images for a single system. Most tutorials I’ve found, struggling configuring my service, would stick to serving […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[2],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/28"}],"collection":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=28"}],"version-history":[{"count":3,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/28\/revisions"}],"predecessor-version":[{"id":32,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=\/wp\/v2\/posts\/28\/revisions\/32"}],"wp:attachment":[{"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=28"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=28"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.unetresgrossebite.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=28"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nRelying on industry standards such as DHCP (RFC1531<\/a>, RFC4578<\/a>), TFTP (RFC783<\/a>, RFC906<\/a>) then BOOTP (RFC951<\/a>), PXE uses a set of low-level protocols clients, allowing lightweight implementation, inducing a low enough footprint to fit on regular network controllers.
\nMost DHCP servers can be reconfigured to provide its clients with a PXE server address (‘next-server’) and a file (‘filename’), supposed to be distributed by your PXE.
\nOnce the client retrieved these info from its DHCP, it is able to download and render the downloaded file. Once the first image (usually named pxelinux.0<\/em>, pxeboot.0<\/em>, or anyway you want…, there’s a lot of declinations, mostly doing the same thing) is executed, the client would query the TFTP server again for files contained within pxelinux.cfg<\/em> directory.
\nLooking for additional configurations, the PXE client would usually look up for a file matching its complete hardware address (eg pxelinux.cfg\/aa-bb-cc-dd-ee-ff<\/em> having the booting NIC hardware address set to AA:BB:CC:DD:EE:FF<\/em>). The client would then query for a file matching its complete IP (eg pxelinux.cfg\/C000025A<\/em> having the client IP address set to 192.0.2.90<\/em>). If not found, the last digit of the previous query is removed, and then again, … until the string is empty, at which point, the client queries for a file ‘default’.
\nThe ‘default<\/em>‘ file, as of any file from pxelinux.cfg<\/em>, can either define menus layout and several boot options, or simply boot a given image without further notice.<\/p>\n
\nSetting up a system requires you to download the proper kernel and initramfs, then declare a menu item loading them. Automating the process is thus pretty straight-forward: two files to downloads, a template to include from your main menu, … See puppet defines, downloading CentOS, CoreOS, Debian, Fedora, FreeBSD, mfsBSD, OpenBSD, OpenSUSE and Ubuntu<\/a>.
\nMost initramfs could be started with specific arguments such as which device to use, which keyboard layout to load, which repository to use, or even a URL the system installation process would use to retrieve either a preseed<\/a>, a kickstart<\/a>, or anything that may help automating installation process.<\/p>\n
\nTargeting such infrastructures, products emerged bringing PXE to its next level.
\nCobbler, for instance, a system-agnostic Python-based command-line tool managing PXE configuration. Its primary functionality is to automate repetitive actions and encourage the reuse of existing data through templating.
\nMAAS, from Canonical, in combination with Juju, based on Ubuntu, able to bootstrap complete infrastructures — which is what they do, I guess, with BootStack.<\/p>\n","protected":false},"excerpt":{"rendered":"