ISO/USB Script (MicroInstall OS) Example/ Micro Tutorial. - Printable Version +- iPXE discussion forum (https://forum.ipxe.org) +-- Forum: iPXE user forums (/forumdisplay.php?fid=1) +--- Forum: General (/forumdisplay.php?fid=2) +--- Thread: ISO/USB Script (MicroInstall OS) Example/ Micro Tutorial. (/showthread.php?tid=13275) |
ISO/USB Script (MicroInstall OS) Example/ Micro Tutorial. - MultimediaMan - 2018-09-27 21:21 On an earlier thread, a Forum member was attempting to build something I had already built sometime ago for Networks (or Hardware) which might not have DHCP or PXE configured. This embedded script is fairly comprehensive and will help Sysadmins with one-off systems and/or legacy networks leverage iPXE. Broadly, the script enables the img/ISO to attempt to DHCP three times, and failing that, drop to an interactive menu for the user to input the Host/Network Information manually, hopefully getting onto the network. Once on the network, the embedded script will attempt to reach the webserver defined by the user or in the ${17} variable for further commands using a number of schemes (UUID, Hostname, MAC address and then a default.ipxe) before failing out. There are a good number of variable tests placed into the script to programmatically obtain, utilize and display information about a given booted host, allowing the Sysadmin a fair degree of flexibility in controlling the host both locally (and with the correct backend, remotely). Assumptions: A webserver with a directory structure of ${17}/NetBoot/iPXE/ipxelinux.cfg/ With subdirectories of "uuid", "dns", "net" with all files contained being ${VariableType}.ipxe e.g. for /net; 01-${HypenatedMACAddr}.ipxe Also with a subdirectory and file of "default/default.ipxe" Code: #!ipxe Notes: I prefer to start embedded script variables with "0_" and Web Hosted scripts with a "1_" and progressing after that, depending on how the backend setup is configured. There are some other unique variables which could be used which I have purposely omitted: ${asset} (Dell systems rely on this entry) and ${serial} (notionally the Serial Number of the system), but the implementation by other vendors is haphazard. Use caution when using a MAC address as a unique identifier: In today's virtualized environments, these addresses can change or (in large environments) be duplicated, and you can have a devil of a time sorting it all out. My favorite unique variable is the UUID, and it is not without it's foibles: The BIOS, OS and iPXE may not agree on how to display this variable (older systems, particularly consumer-grade motherboards, may not have a truly unique UUID). There are bit shifting schemes you can use to compensate for "Endian-ness" which aren't too complicated to implement and maintain. Resourceful administrators will embed/write unique values in whichever "uuid", "dns", "net" file/ entry applies to a particular host and have various scripts/ processes refer to that. Experienced administrators will write the backend processes (in Ansible/CHEF/Ironic or good old PHP or even BASH) to where even "unknown" systems can be automatically discovered, recorded when using the ISO (or PXE) and will have generic entries written into the Webserver by a backend process for future use. |