My goal is to implement a way to create the most portable and plug-n-play method for PXE booting on an existing network regardless of subnet constraints.
A simple DHCP request is more than just acquiring an IP address, it has the capability to deliver information that aids in proper network configuration encompassing lots of special parameters in order to bring this DHCP requestor online. Most just need an IP address and that's it.
A list of these special parameters can be analyzed here: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml
PXE booting is a method of booting off of the network. This technology is not widely used because it is not enterprise reliable but is available in most standard bios configurations from major manufacturers of computers.
Why is PXE booting not reliable? When a DHCP request is made and it contains information containing PXE information, an IP address for the PXE host is delivered to the DHCP requester. This IP address contains the bootable image or code that is to be transmitted over TFTP. TFTP is very unreliable because there is no checking and is simply a game of chance. Similiar to UDP, TFTP transfers do not check with the server to see if the packets were received so they could be lost in translation. Also, TFTP does check to see if these packets are in order.
How can we make PXE reliable? Transfer the bootable image or code over HTTP. As we all should know, HTTP is very reliable as it corrects both faults found in TFTP.
Unless the DHCP is configured otherwise, by nature computers don't care where the DHCP information comes from as long as they get it. This sounds really insecure because it is. This is also standard protocol for most internet connected "things". On the flip side, if there is more than one DHCP server on the network actively leasing IP addresses a race will ensue to see which DHCP server can deliver the IP lease the quickest. This is not an ideal situation for a stable and predictable network which is why PXE booting is almost always going to configured along side with the DHCP server.
What if there was a way to deliver PXE DHCP information without leasing an IP address or disrupting the natural flow of a predictable network and also reliably deliver bootable images and/or code? There is, and I introduce proxyDHCP.
ProxyDHCP allows this very thing and, if configured properly, can adapt to the network in order to deliver a completely dynamic PXE server. My post title was a little misleading in that a DHCP was not required... In fact it is required but in a state that would not interfere or modify the existing network.
I have done a lot of research and have concluded that psychomario's implementation of a runnable python-based PXE DHCP combo server is the best way for making this scenario a reality.
Huge props to psychomario for developing this awesome tool.
https://github.com/psychomario/PyPXE
However, there are a few caveats to these series of scripts. The TFTP server and HTTP server python implementations only allow for 1 connection at a time. The alternative would be to host your own TFTP and HTTP servers that can handle multiple connections such as a node.js simple server and "TFTP server for mac". I have used both of these and successfully booted 20 computers at the same time in about 5 minutes with TinyCore Plus.
References, research, and code segments:
https://github.com/psychomario/PyPXE
http://www.fogproject.org/
http://www.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server
http://ipxe.org/gsoc
http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
https://rom-o-matic.eu/
https://github.com/xbgmsharp/ipxe-buildweb/
/* ignore emacs backups and dotfiles */
|
|
if (len == 0 ||
|
|
ent->d_name[len - 1] == '~' ||
|
|
(ent->d_name[0] == '#' && ent->d_name[len - 1] == '#') ||
|
|
ent->d_name[0] == '.')
|
|
continue;
| |
pypxe is the winner
No comments:
Post a Comment