Re: Is there a way to install DragonFly via network (w/o CD) ?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:10-4.   Let me know how I should go from here, but I really think I can 
:make it simple judging from the feedback we received for the installer 
:on how to KISS it.   It seems to be a priority any more to keep thing 
:KISS which I really agree with ;)
:
:-Scott

    Ok, I figured out a dhcpd configuration that ought to work.  It looks like
    it *IS* possible to have multiple dhcpd servers.  When a machine is
    PXE booting it asks for all sorts of identifiers that a normal dhcp
    server (e.g. cable modem, dsl line, etc) cannot return.  The Intel PXEBoot
    code appears to ignore responses that have insufficient information, so
    if there is a second dhcp server which does return more complete info
    the PXE client will use it.

    This means that we can run a second dhcp server on the network that 
    responds specifically to PXEBoot requests and it should not intefere
    with the main dhcpd server for the network.

    Isn't that cool?  

    So here's the idea... when you tell the installer to run a DHCP PXEBoot
    server it should

    * configure its IP address to something specific, e.g. in my example
      10.1.0.1 netmask 255.255.255.0  (this can be an alias, separate from
      a normal DHCP discovered IP).

    * enable tftp and nfs

    * install pxeboot in the tftp directory.

    * mount the CD fresh on /cdrom or something like that and export it via
      NFS.  Or maybe just exporting '/' will work, I think NFS servers
      ignore mount points.
      
    * run dhcpd (I compiled up /usr/ports/net/isc-dhcp3-server) with a
      configuration file that only responds to requests from PXE clients.

    The DHCPD configuration file should look something like this:

# /usr/local/etc/dhcpd.conf
#
ddns-update-style none;

class "pxeboot-class" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
}

class "etherboot-class" {
    match if substring (option vendor-class-identifier, 0, 9) = "Etherboot";
}

subnet 10.1.0.0 netmask 255.255.0.0 {
    pool {
        allow members of "pxeboot-class";
        allow members of "etherboot-class";
        range 10.1.0.128 10.1.0.254;
        option subnet-mask 255.255.255.0;
        option broadcast-address 10.1.0.255;
        filename "pxeboot";
        option root-path "10.1.0.1:/cdrom";
	next-server 10.1.0.1;
    }
}

    The above configuration file should only respond to requests matching
    PXEClient or Etherboot sources, and so should ignore normal dhclient or
    windows automatic IP DHCP requests.

    I tested this on my LAN and it *almost* works.  It is able to load pxeboot
    and it is able to load the CD's exported /cdrom/kernel, but of course the
    kernel is not a BOOTP kernel so we also have to:

    * We need to include a BOOTP kernel on the CD (e.g. as /kernel.BOOTP)

    * We need to compile up a version of pxeboot which loads /kernel.BOOTP
      instead of /kernel by default.

    I will do these two items now... that is, generate a BOOTP generic kernel
    as part of the release building mechanism and also change the default
    kernel name that pxeboot tries to load.

    What you need to do is build the infrastructure that starts the tftp
    server, the nfs server, configures the fixed IP addresses, includes the
    isc-dhcp3-server package on the CD, creates the /usr/local/etc/dhcpd.conf
    file, and starts dhcpd.

    I think this is going to be *VERY* cool, guys!

							-Matt