Diskless Booting For the Modern Age

An anonymous reader writes "Ever wonder what happened to PXE? Intel's popular standard for diskless booting hasn't been updated since 1999, and has missed out on such revolutions as wireless Ethernet, cloud computing, and iSCSI. An open source project called Etherboot has been trying to drag PXE into the 21st century. One of their programmers explains how to set up diskless booting for your cloud, using copy-on-write to save space."

Re:Authentication

[rathaven]

It wasn't designed for it - PXE boots without authentication on the client so that the hardware gets the image thinly and then auth takes place when the OS is installed. It assumes control of the local LAN is in place and it is trusted. If you are looking for auth at this level you'd need to look at authentication to the switch or wireless on the network - pre-authentication using something like 802.1X. I'm not 100% clear but I believe gPXE has something that probably covers that in the docs as it has scripting capability pre-receiving DHCP addresses (at the level for wireless authentication and possibly 802.1X)...

Re:Cloud?

[fauxhemian]

It doesn't scale and isn't modular in a Unixy way. Modern applications just suck because they're so inflexible. Why can I do so many things from a little text terminal, but I can't easily script the behavior of my web browser without special add-ons?

http://en.wikipedia.org/wiki/Uzbl [wikipedia.org]

Re:Cloud?

[Anonymous Coward]

http://www.uzbl.org/faq.php

Cool, so I can install uzbl and have a "Unixy" browser that does next to nothing without a headache and a weekend of tinkering ... or I can install Firefox and actually get shit done. Sounds about right.

Re:How is it slow?

[Junta]

Well, one issue is boot payload is getting bigger and bigger. One distro has about 20MB of download that would be tftped in the default case. Windows uses tftp for a *lot* more.

tftp has the following issues:
-16-bit block indexes. Most firmware won't go above 1400 or so blocksize (with good reason, if they go higher and the network is set for jumbo frames, transfers will fail in many scenarios). This means a cap of about 98MB before you overflow the counter. Most tftp servers nowadays can deal with it in a unicast case, but it's not technically fixed in the spec.

-tftp exhibits a sort of half-duplex character with regards to transmits and block acknowledgement. Server sends 1.5 kilobytes, then does nothing, client receives the block, and only then does it request the other one. Compare to TCP windows in ftp and http and the differences are massive.

Re:How is it slow?

[Junta]

Issues:
-tftp multicast is inherently limited to smaller than 98MB images with sane MTU. The same block number wrapping in unicast can't work in multicast. When you want speedup the most, tftp multicast can't even work
-multicast only buys you something if a large number of clients are acquiring the same payload at the same time. In a large scale 'cloud 'configuration, things are generally heterogenous enough to negate any such hypothetical benefit.
-Most ethernet fabrics are either incapable or not configured for IGMP/MLDv2 snooping required to properly scope multicast resulting in all multicast traffic degrading to broadcast. This has very adverse results unless every entity on the network only cares about the transfer.

Re:How is it slow?

[guruevi]

Yes, Apple has been able to do it for a couple of years now (since the PowerPC era).

Basically a DHCP server says: I have a boot image
Client1 says: thanks - starts downloading 0-10%
Client2 comes on: starts downloading 10%-100%
Client1 continues downloading 10%-100%
Client1 boots up
Client2 requests 0%-10%
Client2 boots up

I think your example involves P2P but unless your client also has the boot image and a mechanism to give it to others after it has booted (which could be potentially a security risk) it doesn't work that way.