----- Forwarded Message ----- From: Alexander Graf agraf@suse.de To: Heinrich Schuchardt xypron.glpk@gmx.de
The appended README explains how U-Boot and iPXE can be used to boot a diskless system from an iSCSI SAN.
The maintainer for README.efi and README.iscsi is set.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
+U-Boot has only a reduced set of supported network protocols. A major gap is
major gap is +the lack of a TCP stack.
This is only semi-true. There is work in progress to get TCP support into U-Boot. The protocols on top however are still missing and using iPXE here is definitely a very reasonable approach.
We are implementeinga limited TCP and a wget (http 1.0) app. It is almost ready for an test release. Selective Acknowledgment (SACK) is under test as a final piece of the TCP stack.
We have noticed that omitting the http 1.0 declaration in downloading the kernel from an nginx web server that we remove the overhead of an http header completely.
+For booting a diskless computer this leaves us with BOOTP or DHCP to get the +address of a boot script. TFTP can be used to load the boot script and the +operating system kernel and initial file system (initrd).
We use DHCP or DNS. DHCP assumes one has control of the DHCP server and are generally inside the firewall, and is complex to adminsited is there are many (branch office) DHCP servers. With MS 2012 R2 server configuring DHCP options is complex.
+These protocols are insecure. The client cannot validate the authenticity +of the contacted servers. And the server cannot verify the identity of the +client.
Yes and no. We (optionally) use the burnt in MAC address or serial number to identify a client machine, and can prevent boot if it is not authorized by denying the download of the *nix kernel. If inside the firewall and using DHCP security is probably completly under the control of the enterprise admins. We use locally administered DNS servers to control address resolution under DNS.
iPXE is the "swiss army knife" of +network booting. It supports both HTTPS and iSCSI. It has a script engine for +fine grained control of the boot process and can provide a command shell. +
(1)u-boot (+ missing functions)->iPXE->grub->kernel (appears complex) or (2)u-boot (+ missing functions)->kernel?
+protocol. Now iPXE can call the simple file protocol to load Grub.
I seem to be missing the point. We use U-boot to load and run the kernel with tcp+http 1.0. https would be a nice enhancement, as would an encrypted connection for the *nix kernel to access the image, but complete security requires more.
If you are going to do this we need to discuss accessing the *nix image over a secure protocol. AFAIK the *nix kernel does not use secure protocols with network *nix images.
In the netboot process we'd address the performance limitations of NFS, especially during boot, with either lookahead caching at the client or use HTTPS for image access, both of which are outside u-boot's scope.