Thread: [SSI-devel] Re: Knoppix OpenSSI cluster
Brought to you by:
brucewalker,
rogertsang
From: Brian J. W. <Bri...@hp...> - 2005-01-24 22:02:43
|
En Chiang Lee wrote: > Hi Brian, > > I've modified the Clustertab.pm to allow for <DHCP>. These nodes will > not use PXE or Etherboot? Should they be forced to specify a local boot > device? Not always. Sometimes the nodes will get their dynamic address from a DHCP server on the initnode. > Attached is the patch which allows <DHCP>. This tries to create the > dhcpd.conf entries for <DHCP> entries since it still asks for E/P. > Perhaps we can add a L option which will be ignored by mkdhcpd.conf. mkdhcpd.conf should ignore any clustertab entries with '<DHCP>' for IP address. I don't think there's a need for an additional network boot state. In fact, I'd like to eliminate the E/P field sometime with a strategy that Chirag suggested. I attached a patch with some corrections in match_ifconfig(). One of the changes just makes the intent clearer, by eliminating a double negative (unless ... ne). Next, I'd like you to implement: 1) write_boottab() should not write a netmask for <DHCP> entries. 2) Modify mkinitrd to generate a /linuxrc that responds appropriately to <DHCP>. It should run dhclient rather than trying to parse and apply a static IP address and netmask. 3) Add support for an optional line in /etc/clustertab that can specify an allowable range of dynamic address. mkdhcpd.conf should create an appropriate stanza for handing out these dynamic addresses. Try to restrict this stanza to just the MAC addresses of <DHCP> nodes, if the syntax of /etc/dhcpd.conf lets you do this. Also, the various validation routines in Clustertab.pm, etc. should make sure that the dynamic address range is on the proper network, and that no static addresses in /etc/clustertab are part of the dynamic range. Thanks and regards, Brian |
From: Chirag K. <ch...@sy...> - 2005-01-27 06:48:08
|
En Chiang Lee wrote: |> mkdhcpd.conf should ignore any clustertab entries with "<DHCP>" for IP= =20 |> address. I don"t think there"s a need for an additional network boot=20 |> state. In fact, I"d like to eliminate the E/P field sometime with a=20 |> strategy that Chirag suggested. | I"ve made the change to mkdhcpd.conf to ignore <DHCP> entries. I can"t=20 | remember what Chirag had suggested :-( Basically, the E/P field can be eliminated from the clsutertab file. (Not sure, if this would break some apps in openssi-tools). Currently, that field's used by mkdhcp.conf to generate suitable dhcpd.conf (if it's P, then create a stanza for PXE network boot, and if E, .. so on). DHCP can `detect' the network boot client (etherboot or pxe). Have a look at the dhcpd.conf files, that Roopa would have, for multicast tftp. We could have both etherboot style and PXE style stanza for all the nodes. Depending on the client type detected, the filename to sent to the client, can be set to combined or pxelinux.0, as required. (Sorry, for responding late to the thread; apparently, my ISP's been blacklisted, and mail servers, including those of sourceforge and hp.com, aren't accepting mails from me). Regards, --=20 Chirag Kantharia, puggy.symonds.net/~chyrag/ |
From: En C. L. <en...@in...> - 2005-01-27 08:42:36
|
Cool! I'll look at removing the E/P field from the clustertab. It seems like a simple "if" statement in the dhcpd.conf will do. Thanks, En Chiang Chirag Kantharia wrote: > En Chiang Lee wrote: > |> mkdhcpd.conf should ignore any clustertab entries with "<DHCP>" for IP > |> address. I don"t think there"s a need for an additional network boot > |> state. In fact, I"d like to eliminate the E/P field sometime with a > |> strategy that Chirag suggested. > | I"ve made the change to mkdhcpd.conf to ignore <DHCP> entries. I can"t > | remember what Chirag had suggested :-( > > Basically, the E/P field can be eliminated from the clsutertab file. > (Not sure, if this would break some apps in openssi-tools). > > Currently, that field's used by mkdhcp.conf to generate suitable > dhcpd.conf (if it's P, then create a stanza for PXE network boot, and if > E, .. so on). > > DHCP can `detect' the network boot client (etherboot or pxe). Have a > look at the dhcpd.conf files, that Roopa would have, for multicast tftp. > We could have both etherboot style and PXE style stanza for all the > nodes. Depending on the client type detected, the filename to sent to > the client, can be set to combined or pxelinux.0, as required. > > (Sorry, for responding late to the thread; apparently, my ISP's been > blacklisted, and mail servers, including those of sourceforge and > hp.com, aren't accepting mails from me). > > Regards, > |
From: Brian J. W. <Bri...@hp...> - 2005-02-02 04:21:31
|
That would be great! The E/P field is an unnecessary complication that the user doesn't need to see. Brian En Chiang Lee wrote: > Cool! I'll look at removing the E/P field from the clustertab. It seems > like a simple "if" statement in the dhcpd.conf will do. > > Thanks, > > En Chiang > > Chirag Kantharia wrote: > >> En Chiang Lee wrote: >> |> mkdhcpd.conf should ignore any clustertab entries with "<DHCP>" for >> IP |> address. I don"t think there"s a need for an additional network >> boot |> state. In fact, I"d like to eliminate the E/P field sometime >> with a |> strategy that Chirag suggested. >> | I"ve made the change to mkdhcpd.conf to ignore <DHCP> entries. I >> can"t | remember what Chirag had suggested :-( >> >> Basically, the E/P field can be eliminated from the clsutertab file. >> (Not sure, if this would break some apps in openssi-tools). >> >> Currently, that field's used by mkdhcp.conf to generate suitable >> dhcpd.conf (if it's P, then create a stanza for PXE network boot, and if >> E, .. so on). >> >> DHCP can `detect' the network boot client (etherboot or pxe). Have a >> look at the dhcpd.conf files, that Roopa would have, for multicast tftp. >> We could have both etherboot style and PXE style stanza for all the >> nodes. Depending on the client type detected, the filename to sent to >> the client, can be set to combined or pxelinux.0, as required. >> >> (Sorry, for responding late to the thread; apparently, my ISP's been >> blacklisted, and mail servers, including those of sourceforge and >> hp.com, aren't accepting mails from me). >> >> Regards, >> > > |
From: Brian J. W. <Bri...@hp...> - 2005-01-24 22:10:12
Attachments:
openssi-tools.bjw.jan24.patch
|
Brian J. Watson wrote: > I attached a patch with some corrections in match_ifconfig(). One of the > changes just makes the intent clearer, by eliminating a double negative > (unless ... ne). And now I'll actually attach the patch... Brian |
From: En C. L. <en...@in...> - 2005-01-25 11:51:28
|
> mkdhcpd.conf should ignore any clustertab entries with '<DHCP>' for IP > address. I don't think there's a need for an additional network boot > state. In fact, I'd like to eliminate the E/P field sometime with a > strategy that Chirag suggested. I've made the change to mkdhcpd.conf to ignore <DHCP> entries. I can't remember what Chirag had suggested :-( > I attached a patch with some corrections in match_ifconfig(). One of the > changes just makes the intent clearer, by eliminating a double negative > (unless ... ne). Thanks. > Next, I'd like you to implement: > > 1) write_boottab() should not write a netmask for <DHCP> entries. Done. > 2) Modify mkinitrd to generate a /linuxrc that responds appropriately to > <DHCP>. It should run dhclient rather than trying to parse and apply a > static IP address and netmask. dhclient runs a bash script "/sbin/dhclient-script" to configure the specified interface. This script requires plenty of stuff, including: - route - /etc/sysconfig/network-scripts/network-functions - /etc/sysconfig/network-scripts/ifcfg-<interface> - hostname - domainname (depends on what reply he gets from dhcpd) - ping - ifconfig Also, dhclient writes to /var/run/dhclient.pid and /var/lib/dhcp/dhclient.leases. These will all have to be included in the ramdisk (kinda big, don't you think?) > > 3) Add support for an optional line in /etc/clustertab that can specify > an allowable range of dynamic address. mkdhcpd.conf should create an > appropriate stanza for handing out these dynamic addresses. Try to > restrict this stanza to just the MAC addresses of <DHCP> nodes, if the > syntax of /etc/dhcpd.conf lets you do this. Also, the various validation > routines in Clustertab.pm, etc. should make sure that the dynamic > address range is on the proper network, and that no static addresses in > /etc/clustertab are part of the dynamic range. I'll look at the dhcpd.conf format and see how this can be done. Thanks, En Chiang > > Thanks and regards, > > Brian > > |
From: Brian J. W. <Bri...@hp...> - 2005-01-25 19:23:35
|
En Chiang Lee wrote: >> mkdhcpd.conf should ignore any clustertab entries with '<DHCP>' for IP >> address. I don't think there's a need for an additional network boot >> state. In fact, I'd like to eliminate the E/P field sometime with a >> strategy that Chirag suggested. > > > I've made the change to mkdhcpd.conf to ignore <DHCP> entries. I can't > remember what Chirag had suggested :-( I have a copy of it somewhere. It involves generating an /etc/dhcpd.conf that can dynamically recognize whether a node is booting with PXE or Etherboot. >> 2) Modify mkinitrd to generate a /linuxrc that responds appropriately >> to <DHCP>. It should run dhclient rather than trying to parse and >> apply a static IP address and netmask. > > > dhclient runs a bash script "/sbin/dhclient-script" to configure the > specified interface. This script requires plenty of stuff, including: > - route > - /etc/sysconfig/network-scripts/network-functions > - /etc/sysconfig/network-scripts/ifcfg-<interface> > - hostname > - domainname (depends on what reply he gets from dhcpd) > - ping > - ifconfig > Also, dhclient writes to /var/run/dhclient.pid and > /var/lib/dhcp/dhclient.leases. > > These will all have to be included in the ramdisk (kinda big, don't you > think?) Don't know. All this might not be that big, compared to the behemoths of libc and bash that we've already added to our initrd. See what the size difference is after adding the dhclient support. >> 3) Add support for an optional line in /etc/clustertab that can >> specify an allowable range of dynamic address. mkdhcpd.conf should >> create an appropriate stanza for handing out these dynamic addresses. >> Try to restrict this stanza to just the MAC addresses of <DHCP> nodes, >> if the syntax of /etc/dhcpd.conf lets you do this. Also, the various >> validation routines in Clustertab.pm, etc. should make sure that the >> dynamic address range is on the proper network, and that no static >> addresses in /etc/clustertab are part of the dynamic range. > > > I'll look at the dhcpd.conf format and see how this can be done. > > Thanks, > > En Chiang |
From: En C. L. <en...@in...> - 2005-01-27 14:26:01
|
>>> 2) Modify mkinitrd to generate a /linuxrc that responds appropriately >>> to <DHCP>. It should run dhclient rather than trying to parse and >>> apply a static IP address and netmask. I handcrafted an initrd to do this, and it works, after a fashion :-) ssi-addnode created entries with <DHCP> in clustertab which was used by mkdhcpd.conf to create the boottab. At this point, the dhcpd.conf did not have an entry for this second node, so I added these lines: ....... range a.b.c.d a.b.c.d; group { ....... host node2 { hardware ethernet xx:xx:xx:xx:xx:xx; } ........ where the range started and ended with the same ip address. With these lines, the second node, booting up with an etherboot floppy gets an ip from the dhcp server and tftps /combined. When I run dhclient from the linuxrc, the dhcp server on my initnode sees the DHCPDISCOVER and sends out the DHCPOFFER, but this is not seen by the client. This same machine, when booted non-ssi, can get its ip from the dhcp server on the initnode. Interestingly, after some time, it got an IP from another DHCP server and booted into the cluster with an IP on another subnet! Any ideas about why the dhclient doesn't get the DHCPOFFER packets from the initnode when it's running the linuxrc? Thanks, En Chiang > >>> 3) Add support for an optional line in /etc/clustertab that can >>> specify an allowable range of dynamic address. mkdhcpd.conf should >>> create an appropriate stanza for handing out these dynamic addresses. >>> Try to restrict this stanza to just the MAC addresses of <DHCP> >>> nodes, if the syntax of /etc/dhcpd.conf lets you do this. Also, the >>> various validation routines in Clustertab.pm, etc. should make sure >>> that the dynamic address range is on the proper network, and that no >>> static addresses in /etc/clustertab are part of the dynamic range. >> >> >> >> I'll look at the dhcpd.conf format and see how this can be done. >> >> Thanks, >> >> En Chiang > > > |
From: En C. L. <en...@in...> - 2005-01-31 10:20:34
|
The problem of not receiving the DHCPOFFER packets in the linuxrc is caused by the failure of a select call in dhclient. The select system call eventually calls ssidev_do_poll_nodes() which uses 'this_node'. Since I was calling dhclient before 'cluster_config --prep', this_node is set to CLUSTERNODE_INVAL, and hence dhclient would fail. Does there need to be a check for the validity of 'this_node' before it is used? Otherwise, anything that uses select before 'cluster_config --prep' could cause a illegal memory address. I moved the dhclient call to after 'cluster_config --prep', and now the secondary node can get an IP from a dhcp server. Regards, En Chiang En Chiang Lee wrote: >>>> 2) Modify mkinitrd to generate a /linuxrc that responds >>>> appropriately to <DHCP>. It should run dhclient rather than trying >>>> to parse and apply a static IP address and netmask. > > > I handcrafted an initrd to do this, and it works, after a fashion :-) > > ssi-addnode created entries with <DHCP> in clustertab which was used by > mkdhcpd.conf to create the boottab. At this point, the dhcpd.conf did > not have an entry for this second node, so I added these lines: > ....... > range a.b.c.d a.b.c.d; > group { > ....... > host node2 { > hardware ethernet xx:xx:xx:xx:xx:xx; > } > ........ > > where the range started and ended with the same ip address. > > With these lines, the second node, booting up with an etherboot floppy > gets an ip from the dhcp server and tftps /combined. When I run dhclient > from the linuxrc, the dhcp server on my initnode sees the DHCPDISCOVER > and sends out the DHCPOFFER, but this is not seen by the client. > This same machine, when booted non-ssi, can get its ip from the dhcp > server on the initnode. > > Interestingly, after some time, it got an IP from another DHCP server > and booted into the cluster with an IP on another subnet! > > Any ideas about why the dhclient doesn't get the DHCPOFFER packets from > the initnode when it's running the linuxrc? > > Thanks, > > En Chiang > >> >>>> 3) Add support for an optional line in /etc/clustertab that can >>>> specify an allowable range of dynamic address. mkdhcpd.conf should >>>> create an appropriate stanza for handing out these dynamic >>>> addresses. Try to restrict this stanza to just the MAC addresses of >>>> <DHCP> nodes, if the syntax of /etc/dhcpd.conf lets you do this. >>>> Also, the various validation routines in Clustertab.pm, etc. should >>>> make sure that the dynamic address range is on the proper network, >>>> and that no static addresses in /etc/clustertab are part of the >>>> dynamic range. >>> >>> >>> >>> >>> I'll look at the dhcpd.conf format and see how this can be done. >>> >>> Thanks, >>> >>> En Chiang >> >> >> >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: En C. L. <en...@in...> - 2005-01-31 14:41:42
Attachments:
mkinitrd.patch
ot.dhcp.patch
|
Hi Brian, Attached are the patches to mkinitrd and openssi-tools which allow <DHCP> entries during ssi-addnode. Also, /etc/clustertab can contain a line: IPRANGE a.b.c.d w.x.y.z This is taken by mkdhcpd.conf and dhcpd.conf generated will answer only to the MACs in /etc/clustertab and distribute IPs from this range. TODO: The validation of this range has to be improved. The error checking in the linuxrc also has to be improved. Also, should the mkinitrd changes be part of a new option to mkinitrd? Thanks, En Chiang En Chiang Lee wrote: > The problem of not receiving the DHCPOFFER packets in the linuxrc is > caused by the failure of a select call in dhclient. > > The select system call eventually calls ssidev_do_poll_nodes() which > uses 'this_node'. Since I was calling dhclient before 'cluster_config > --prep', this_node is set to CLUSTERNODE_INVAL, and hence dhclient would > fail. > Does there need to be a check for the validity of 'this_node' before it > is used? Otherwise, anything that uses select before 'cluster_config > --prep' could cause a illegal memory address. > > I moved the dhclient call to after 'cluster_config --prep', and now the > secondary node can get an IP from a dhcp server. > > Regards, > > En Chiang > > En Chiang Lee wrote: > >>>>> 2) Modify mkinitrd to generate a /linuxrc that responds >>>>> appropriately to <DHCP>. It should run dhclient rather than trying >>>>> to parse and apply a static IP address and netmask. >> >> >> >> I handcrafted an initrd to do this, and it works, after a fashion :-) >> >> ssi-addnode created entries with <DHCP> in clustertab which was used >> by mkdhcpd.conf to create the boottab. At this point, the dhcpd.conf >> did not have an entry for this second node, so I added these lines: >> ....... >> range a.b.c.d a.b.c.d; >> group { >> ....... >> host node2 { >> hardware ethernet xx:xx:xx:xx:xx:xx; >> } >> ........ >> >> where the range started and ended with the same ip address. >> >> With these lines, the second node, booting up with an etherboot floppy >> gets an ip from the dhcp server and tftps /combined. When I run >> dhclient from the linuxrc, the dhcp server on my initnode sees the >> DHCPDISCOVER and sends out the DHCPOFFER, but this is not seen by the >> client. >> This same machine, when booted non-ssi, can get its ip from the dhcp >> server on the initnode. >> >> Interestingly, after some time, it got an IP from another DHCP server >> and booted into the cluster with an IP on another subnet! >> >> Any ideas about why the dhclient doesn't get the DHCPOFFER packets >> from the initnode when it's running the linuxrc? >> >> Thanks, >> >> En Chiang >> >>> >>>>> 3) Add support for an optional line in /etc/clustertab that can >>>>> specify an allowable range of dynamic address. mkdhcpd.conf should >>>>> create an appropriate stanza for handing out these dynamic >>>>> addresses. Try to restrict this stanza to just the MAC addresses of >>>>> <DHCP> nodes, if the syntax of /etc/dhcpd.conf lets you do this. >>>>> Also, the various validation routines in Clustertab.pm, etc. should >>>>> make sure that the dynamic address range is on the proper network, >>>>> and that no static addresses in /etc/clustertab are part of the >>>>> dynamic range. >>>> >>>> >>>> >>>> >>>> >>>> I'll look at the dhcpd.conf format and see how this can be done. >>>> >>>> Thanks, >>>> >>>> En Chiang >>> >>> >>> >>> >>> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> ssic-linux-devel mailing list >> ssi...@li... >> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >> >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: Brian J. W. <Bri...@hp...> - 2005-02-18 00:19:12
|
En Chiang Lee wrote: > Hi Brian, > > Attached are the patches to mkinitrd and openssi-tools which allow > <DHCP> entries during ssi-addnode. Also, /etc/clustertab can contain a > line: > IPRANGE a.b.c.d w.x.y.z > This is taken by mkdhcpd.conf and dhcpd.conf generated will answer only > to the MACs in /etc/clustertab and distribute IPs from this range. Your patches look good. > TODO: > The validation of this range has to be improved. > The error checking in the linuxrc also has to be improved. Can you add SSI_XXX comments to the code to indicate that these tests need to be added? You could also add a test that there's one and only one IPRANGE entry in clustertab. > Also, should the mkinitrd changes be part of a new option to mkinitrd? Only if there's a signficant size difference caused by loading all the dhclient stuff into the initrd. If not, then I don't think there's any reason to make this a special command line option. It will only run the special code for the <DHCP> entries. Thanks and regards, Brian |
From: Brian J. W. <Bri...@hp...> - 2005-02-02 04:36:23
|
Hi John, How hard would it be to fix the problem in ssidev_do_poll_nodes() that En Chiang describes below? It seems to me that it might not be a good idea to wait until after `cluster_config --prep` to configure the ICS interface using dhclient. Thanks, Brian En Chiang Lee wrote: > The problem of not receiving the DHCPOFFER packets in the linuxrc is > caused by the failure of a select call in dhclient. > > The select system call eventually calls ssidev_do_poll_nodes() which > uses 'this_node'. Since I was calling dhclient before 'cluster_config > --prep', this_node is set to CLUSTERNODE_INVAL, and hence dhclient would > fail. > Does there need to be a check for the validity of 'this_node' before it > is used? Otherwise, anything that uses select before 'cluster_config > --prep' could cause a illegal memory address. > > I moved the dhclient call to after 'cluster_config --prep', and now the > secondary node can get an IP from a dhcp server. > > Regards, > > En Chiang > > En Chiang Lee wrote: > >>>>> 2) Modify mkinitrd to generate a /linuxrc that responds >>>>> appropriately to <DHCP>. It should run dhclient rather than trying >>>>> to parse and apply a static IP address and netmask. >> >> >> >> I handcrafted an initrd to do this, and it works, after a fashion :-) >> >> ssi-addnode created entries with <DHCP> in clustertab which was used >> by mkdhcpd.conf to create the boottab. At this point, the dhcpd.conf >> did not have an entry for this second node, so I added these lines: >> ....... >> range a.b.c.d a.b.c.d; >> group { >> ....... >> host node2 { >> hardware ethernet xx:xx:xx:xx:xx:xx; >> } >> ........ >> >> where the range started and ended with the same ip address. >> >> With these lines, the second node, booting up with an etherboot floppy >> gets an ip from the dhcp server and tftps /combined. When I run >> dhclient from the linuxrc, the dhcp server on my initnode sees the >> DHCPDISCOVER and sends out the DHCPOFFER, but this is not seen by the >> client. >> This same machine, when booted non-ssi, can get its ip from the dhcp >> server on the initnode. >> >> Interestingly, after some time, it got an IP from another DHCP server >> and booted into the cluster with an IP on another subnet! >> >> Any ideas about why the dhclient doesn't get the DHCPOFFER packets >> from the initnode when it's running the linuxrc? >> >> Thanks, >> >> En Chiang >> >>> >>>>> 3) Add support for an optional line in /etc/clustertab that can >>>>> specify an allowable range of dynamic address. mkdhcpd.conf should >>>>> create an appropriate stanza for handing out these dynamic >>>>> addresses. Try to restrict this stanza to just the MAC addresses of >>>>> <DHCP> nodes, if the syntax of /etc/dhcpd.conf lets you do this. >>>>> Also, the various validation routines in Clustertab.pm, etc. should >>>>> make sure that the dynamic address range is on the proper network, >>>>> and that no static addresses in /etc/clustertab are part of the >>>>> dynamic range. >>>> >>>> >>>> >>>> >>>> >>>> I'll look at the dhcpd.conf format and see how this can be done. >>>> >>>> Thanks, >>>> >>>> En Chiang >>> >>> >>> >>> >>> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> ssic-linux-devel mailing list >> ssi...@li... >> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >> >> > > |
From: John B. <joh...@hp...> - 2005-02-02 17:54:57
Attachments:
pollhack.patch
|
Brian J. Watson wrote: > Hi John, > > How hard would it be to fix the problem in ssidev_do_poll_nodes() that > En Chiang describes below? It seems to me that it might not be a good > idea to wait until after `cluster_config --prep` to configure the ICS > interface using dhclient. > > Thanks, > > Brian It doesn't look straightforward. It looks like the code will also run into problems ssidev_pollfd_add(). I'm also worried that the calling things that early may be running into uninitialized SSI locks and data structures. On the other hand, I don't see how we can wait after "prep" if we are counting on DHCP to tell us what node number we are. The attached hack might fix things, but without setting up to do the test myself, I'm not sure whether it will work. Anything polling will have to exit before doing the "prep". I don't suppose you have a copy of the initrd he has been testing with? John <...snipped...> |
From: Brian J. W. <Bri...@hp...> - 2005-02-18 00:16:52
|
Hi En Chiang, How did John's poll hack work for calling dhclient before `cluster_config --prep'? Brian En Chiang Lee wrote: > Hi John, > > Attached is the initrd which uses dhclient to get its ip address. It > uses a node number from the boottab to do `cluster_config --prep`, and > then calls dhclient. > > I'm going to have to change it since we'll depend on the dhcp ip for the > node number. > > I'll test the attached fix. > > Thanks, > > En Chiang > > John Byrne wrote: > >> Brian J. Watson wrote: >> >>> Hi John, >>> >>> How hard would it be to fix the problem in ssidev_do_poll_nodes() >>> that En Chiang describes below? It seems to me that it might not be a >>> good idea to wait until after `cluster_config --prep` to configure >>> the ICS interface using dhclient. >>> >>> Thanks, >>> >>> Brian >> >> >> >> It doesn't look straightforward. It looks like the code will also run >> into problems ssidev_pollfd_add(). I'm also worried that the calling >> things that early may be running into uninitialized SSI locks and data >> structures. On the other hand, I don't see how we can wait after >> "prep" if we are counting on DHCP to tell us what node number we are. >> >> The attached hack might fix things, but without setting up to do the >> test myself, I'm not sure whether it will work. Anything polling will >> have to exit before doing the "prep". I don't suppose you have a copy >> of the initrd he has been testing with? >> >> >> John >> >> <...snipped...> >> >> >> ------------------------------------------------------------------------ >> >> Index: cluster/ssi/util/ssidev.c >> =================================================================== >> RCS file: /cvsroot/ssic-linux/openssi/kernel/cluster/ssi/util/ssidev.c,v >> retrieving revision 1.5.2.13 >> diff -U4 -r1.5.2.13 ssidev.c >> --- cluster/ssi/util/ssidev.c 14 Dec 2004 02:47:11 -0000 1.5.2.13 >> +++ cluster/ssi/util/ssidev.c 2 Feb 2005 17:48:52 -0000 >> @@ -834,10 +834,14 @@ >> rmtfb_gethandle(rfb, &fh); >> rmtfb_putcli(rfb); >> fput(file); >> file = NULL; >> - } else >> - server = this_node; >> + } else { >> + if (this_node != CLUSTERNODE_INVAL) >> + server = this_node; >> + else >> + server = 1; >> + } >> } else >> server = CLUSTERNODE_INVAL; >> if (server == CLUSTERNODE_INVAL) { >> if (pcp->pc_events & POLLNVAL) { >> @@ -1084,17 +1088,20 @@ >> long *timeout) >> { >> int error = 0; >> int ucount = 0; >> + clusternode_t our_node = this_node; >> int tmpret; >> unsigned int i; >> ssidev_poll_node_t *pnp; >> ics_chunk_t *icp; >> >> + if (our_node == CLUSTERNODE_INVAL) >> + our_node = 1; >> if (*timeout == 0) >> wait = NULL; >> for (i = 0; i < NSC_MAX_NODE_VALUE; i++) { >> - if (i + 1 == this_node) >> + if (i + 1 == our_node) >> continue; >> pnp = pcp->pc_node[i]; >> if (pnp == NULL) >> continue; >> @@ -1150,9 +1157,9 @@ >> pnp->pn_ch = NULL; >> } >> } >> set_current_state(TASK_INTERRUPTIBLE); >> - pnp = pcp->pc_node[this_node - 1]; >> + pnp = pcp->pc_node[our_node - 1]; >> if (pnp != NULL) { >> icp = &pnp->pn_pollfd; >> ics_chunk_free_extra(icp); >> if (icp->ic_nentries > 0) { |
From: En C. L. <en...@in...> - 2005-02-18 05:59:35
|
Yup, John's hack works. I'm sorry, I forgot to send mail. En Chiang Brian J. Watson wrote: > Hi En Chiang, > > How did John's poll hack work for calling dhclient before > `cluster_config --prep'? > > Brian > > > En Chiang Lee wrote: > >> Hi John, >> >> Attached is the initrd which uses dhclient to get its ip address. It >> uses a node number from the boottab to do `cluster_config --prep`, and >> then calls dhclient. >> >> I'm going to have to change it since we'll depend on the dhcp ip for >> the node number. >> >> I'll test the attached fix. >> >> Thanks, >> >> En Chiang >> >> John Byrne wrote: >> >>> Brian J. Watson wrote: >>> >>>> Hi John, >>>> >>>> How hard would it be to fix the problem in ssidev_do_poll_nodes() >>>> that En Chiang describes below? It seems to me that it might not be >>>> a good idea to wait until after `cluster_config --prep` to configure >>>> the ICS interface using dhclient. >>>> >>>> Thanks, >>>> >>>> Brian >>> >>> >>> >>> >>> It doesn't look straightforward. It looks like the code will also run >>> into problems ssidev_pollfd_add(). I'm also worried that the calling >>> things that early may be running into uninitialized SSI locks and >>> data structures. On the other hand, I don't see how we can wait after >>> "prep" if we are counting on DHCP to tell us what node number we are. >>> >>> The attached hack might fix things, but without setting up to do the >>> test myself, I'm not sure whether it will work. Anything polling will >>> have to exit before doing the "prep". I don't suppose you have a copy >>> of the initrd he has been testing with? >>> >>> >>> John >>> >>> <...snipped...> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Index: cluster/ssi/util/ssidev.c >>> =================================================================== >>> RCS file: /cvsroot/ssic-linux/openssi/kernel/cluster/ssi/util/ssidev.c,v >>> retrieving revision 1.5.2.13 >>> diff -U4 -r1.5.2.13 ssidev.c >>> --- cluster/ssi/util/ssidev.c 14 Dec 2004 02:47:11 -0000 1.5.2.13 >>> +++ cluster/ssi/util/ssidev.c 2 Feb 2005 17:48:52 -0000 >>> @@ -834,10 +834,14 @@ >>> rmtfb_gethandle(rfb, &fh); >>> rmtfb_putcli(rfb); >>> fput(file); >>> file = NULL; >>> - } else >>> - server = this_node; >>> + } else { >>> + if (this_node != CLUSTERNODE_INVAL) >>> + server = this_node; >>> + else >>> + server = 1; >>> + } >>> } else >>> server = CLUSTERNODE_INVAL; >>> if (server == CLUSTERNODE_INVAL) { >>> if (pcp->pc_events & POLLNVAL) { >>> @@ -1084,17 +1088,20 @@ >>> long *timeout) >>> { >>> int error = 0; >>> int ucount = 0; >>> + clusternode_t our_node = this_node; >>> int tmpret; >>> unsigned int i; >>> ssidev_poll_node_t *pnp; >>> ics_chunk_t *icp; >>> >>> + if (our_node == CLUSTERNODE_INVAL) >>> + our_node = 1; >>> if (*timeout == 0) >>> wait = NULL; >>> for (i = 0; i < NSC_MAX_NODE_VALUE; i++) { >>> - if (i + 1 == this_node) >>> + if (i + 1 == our_node) >>> continue; >>> pnp = pcp->pc_node[i]; >>> if (pnp == NULL) >>> continue; >>> @@ -1150,9 +1157,9 @@ >>> pnp->pn_ch = NULL; >>> } >>> } >>> set_current_state(TASK_INTERRUPTIBLE); >>> - pnp = pcp->pc_node[this_node - 1]; >>> + pnp = pcp->pc_node[our_node - 1]; >>> if (pnp != NULL) { >>> icp = &pnp->pn_pollfd; >>> ics_chunk_free_extra(icp); >>> if (icp->ic_nentries > 0) { > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: Brian J. W. <Bri...@hp...> - 2005-02-03 03:58:30
|
Brian J. Watson wrote: > 3) Add support for an optional line in /etc/clustertab that can specify > an allowable range of dynamic address. mkdhcpd.conf should create an > appropriate stanza for handing out these dynamic addresses. Try to > restrict this stanza to just the MAC addresses of <DHCP> nodes, if the > syntax of /etc/dhcpd.conf lets you do this. Also, the various validation > routines in Clustertab.pm, etc. should make sure that the dynamic > address range is on the proper network, and that no static addresses in > /etc/clustertab are part of the dynamic range. Hi En Chiang, Forget about the part where I asked you to restrict the dynamic range to just MAC addresses configured with <DHCP>. After talking with Bruce, there doesn't seem to be much point in doing this. An ICS interface will only use DHCP for one of two strategies: - the "quickup" strategy, where any node that boots gets an IP address, kernel, etc., parses its node number from the low order bits of the IP address, and joins without any manual configuration, or - the "corporate network", where all nodes boot from a local boot device (hard disk partition, Live CD, etc.), and get an IP address for their ICS interfaces from a DHCP server outside of the cluster admin's control. Only the quickup strategy will depend on mkdhcpd.conf to generate a dhcpd.conf with a dynamic range of addresses, and we definitely don't want to restrict who can get an address for this approach. Sorry for the confusion, Brian |
From: En C. L. <en...@in...> - 2005-02-03 11:58:32
|
> Forget about the part where I asked you to restrict the dynamic range to > just MAC addresses configured with <DHCP>. After talking with Bruce, > there doesn't seem to be much point in doing this. An ICS interface will > only use DHCP for one of two strategies: > > - the "quickup" strategy, where any node that boots gets an IP address, > kernel, etc., parses its node number from the low order bits of the IP > address, and joins without any manual configuration, or In this case, a `ssi-addiprange` command will create the clustertab line with `IPRANGE <start> <end>` and create the /cluster/node{start..end} directories. mkdhcpd.conf will add the range to dhcpd.conf and generate a boottab with a line to indicate that linuxrc should use dhclient to get ips if there is no matching MAC in the boottab. linuxrc will loop through the NICs on the machine and use the first one which gets an IP from the dhcp server. It will then use the least significant part of the IP as the node number. > - the "corporate network", where all nodes boot from a local boot device > (hard disk partition, Live CD, etc.), and get an IP address for their > ICS interfaces from a DHCP server outside of the cluster admin's control. ssi-addnode will create the /cluster/node{num} directory and the other stuff as it does right now, except that it will accept <DHCP> as a valid ip address and so there will be no change in the dhcpd.conf. What's in the boottab for this node? If there isn't a MAC address, how does the linuxrc associate a booting node with a valid node number? If there is a MAC address, where does it come from? I'm not very clear about what the setup procedure for this `corporate network` will be. Regards, En Chiang > > Only the quickup strategy will depend on mkdhcpd.conf to generate a > dhcpd.conf with a dynamic range of addresses, and we definitely don't > want to restrict who can get an address for this approach. > > Sorry for the confusion, > > Brian > > |
From: Brian J. W. <Bri...@hp...> - 2005-02-03 19:27:19
|
En Chiang Lee wrote: >> - the "quickup" strategy, where any node that boots gets an IP >> address, kernel, etc., parses its node number from the low order bits >> of the IP address, and joins without any manual configuration, or > > > In this case, a `ssi-addiprange` command will create the clustertab line > with `IPRANGE <start> <end>` and create the /cluster/node{start..end} > directories. Let's call it ssi-addnode-dynamic, since it's doing more than just adding an IP range. Be sure it can deal with modifying an existing dynamic node configuration, if one already exists. As for the /cluster/node{nodenum} directories, I think it would be preferable if they were created on-the-fly by the rc.nodeup script, and destroyed by the rc.nodedown script. We don't need to waste a user's hard drive space (or RAM, in the case of a Live CD) with a bunch of these directories. Also, there's no need for a dynamic node to have persistent state in its /cluster/node{nodenum} directory, since its not guaranteed to be the same node when it reboots. Also, ssi-addnode-dynamic should check that the node range does not conflict with any static node numbers already assigned, in addition to checking that the IP addresses don't conflict. It would be unfortunate if a dynamic node deleted or interfered with the /cluster/node{nodenum} directory of a static node. > mkdhcpd.conf will add the range to dhcpd.conf and generate a boottab > with a line to indicate that linuxrc should use dhclient to get ips if > there is no matching MAC in the boottab. linuxrc will loop through the > NICs on the machine and use the first one which gets an IP from the dhcp > server. It will then use the least significant part of the IP as the > node number. This sounds like a good plan. What's the special line you're thinking of adding to the boottab? When linuxrc fails to match a NIC to a static configuration, it would be good to echo a message like this: No network interface was found matching a static node configuration. Dynamically allocating an IP address and node number, instead. That way, if a node was supposed to be static, and a user sees this message, then it would be clear that something's wrong. >> - the "corporate network", where all nodes boot from a local boot >> device (hard disk partition, Live CD, etc.), and get an IP address for >> their ICS interfaces from a DHCP server outside of the cluster admin's >> control. > > > ssi-addnode will create the /cluster/node{num} directory and the other > stuff as it does right now, except that it will accept <DHCP> as a valid > ip address and so there will be no change in the dhcpd.conf. Sounds good. > What's in the boottab for this node? If there isn't a MAC address, how > does the linuxrc associate a booting node with a valid node number? If > there is a MAC address, where does it come from? > > I'm not very clear about what the setup procedure for this `corporate > network` will be. For the Live CD, Bruce was talking about enhancing CLMS to dynamically allocate node numbers. This will obviously require someone to do a bit of kernel programming. Apart from this, it would work similar to the private network "quickup" strategy described above. In fact, the private network "quickup" strategy could also use CLMS to allocate its node number. The trick of parsing a node number out of a dynamic IP address is just a work-around for not having dynamic node number allocation in CLMS. For traditional hard drive installations, it's more complicated. A user might want some nodes to have a static node number based on MAC address, and just use the corporate DHCP server to assign an IP address. This approach would use a standard boottab line, except for <DHCP> in the IP address field. I haven't thought much about how to setup these nodes. For now, we could document how to manually provide the MAC address to ssi-addnode, and how to manually set up a local boot partition with a kernel, initrd, and bootloader. Later, this process can be more automated somehow. For other nodes, a user might want them to be completely dynamic, using the new CLMS feature to allocate a node number. The setup required for these nodes is running ssi-addnode-dynamic on the cluster, and creating a CD or local boot partion with a kernel, initrd, and bootloader. Again, we could initially document this approach, then later figure out how to better automate it. Of course, we won't support this approach until the new CLMS feature is implemented. In summary, running a cluster on a corporate network complicates things. Nodes can't network boot, ssi-addnode can't automatically detect a new node's MAC address, and the range of IP addresses can't be controlled well enough to parse a dynamic node number from an address. The only thing I can suggest you do for this strategy is write documentation for how to configure a node with a static node number and a dynamic IP address, as I briefly described two paragraphs above. That way, users can leverage the <DHCP> work that you did. Best regards, Brian |
From: En C. L. <en...@in...> - 2005-02-14 10:29:48
|
Hi Brian, There's a problem with the "quickup" strategy. Below is a paragraph from the dhcpd.conf man page: "Host declarations are matched to actual DHCP or BOOTP clients by match-ing the dhcp-client-identifier option specified in the host declaration to the one supplied by the client, or, if the host declaration or the client does not provide a dhcp-client-identifier option, by matching the hardware parameter in the host declaration to the network hardware address supplied by the client. BOOTP clients do not normally provide a dhcp-client-identifier, so the hardware address must be used for all clients that may boot using the BOOTP protocol." This implies that for a machine to use etherboot/pxe to boot, then we must specify the MAC address in the dhcpd.conf. Any suggestions? En Chiang Brian J. Watson wrote: > En Chiang Lee wrote: > >>> - the "quickup" strategy, where any node that boots gets an IP >>> address, kernel, etc., parses its node number from the low order bits >>> of the IP address, and joins without any manual configuration, or >> >> >> >> In this case, a `ssi-addiprange` command will create the clustertab >> line with `IPRANGE <start> <end>` and create the >> /cluster/node{start..end} directories. > > > Let's call it ssi-addnode-dynamic, since it's doing more than just > adding an IP range. Be sure it can deal with modifying an existing > dynamic node configuration, if one already exists. > > As for the /cluster/node{nodenum} directories, I think it would be > preferable if they were created on-the-fly by the rc.nodeup script, and > destroyed by the rc.nodedown script. We don't need to waste a user's > hard drive space (or RAM, in the case of a Live CD) with a bunch of > these directories. Also, there's no need for a dynamic node to have > persistent state in its /cluster/node{nodenum} directory, since its not > guaranteed to be the same node when it reboots. > > Also, ssi-addnode-dynamic should check that the node range does not > conflict with any static node numbers already assigned, in addition to > checking that the IP addresses don't conflict. It would be unfortunate > if a dynamic node deleted or interfered with the /cluster/node{nodenum} > directory of a static node. > >> mkdhcpd.conf will add the range to dhcpd.conf and generate a boottab >> with a line to indicate that linuxrc should use dhclient to get ips if >> there is no matching MAC in the boottab. linuxrc will loop through the >> NICs on the machine and use the first one which gets an IP from the >> dhcp server. It will then use the least significant part of the IP as >> the node number. > > > This sounds like a good plan. What's the special line you're thinking of > adding to the boottab? > > When linuxrc fails to match a NIC to a static configuration, it would be > good to echo a message like this: > > No network interface was found matching a static node configuration. > Dynamically allocating an IP address and node number, instead. > > That way, if a node was supposed to be static, and a user sees this > message, then it would be clear that something's wrong. > >>> - the "corporate network", where all nodes boot from a local boot >>> device (hard disk partition, Live CD, etc.), and get an IP address >>> for their ICS interfaces from a DHCP server outside of the cluster >>> admin's control. >> >> >> >> ssi-addnode will create the /cluster/node{num} directory and the other >> stuff as it does right now, except that it will accept <DHCP> as a >> valid ip address and so there will be no change in the dhcpd.conf. > > > Sounds good. > >> What's in the boottab for this node? If there isn't a MAC address, how >> does the linuxrc associate a booting node with a valid node number? If >> there is a MAC address, where does it come from? >> >> I'm not very clear about what the setup procedure for this `corporate >> network` will be. > > > For the Live CD, Bruce was talking about enhancing CLMS to dynamically > allocate node numbers. This will obviously require someone to do a bit > of kernel programming. Apart from this, it would work similar to the > private network "quickup" strategy described above. > > In fact, the private network "quickup" strategy could also use CLMS to > allocate its node number. The trick of parsing a node number out of a > dynamic IP address is just a work-around for not having dynamic node > number allocation in CLMS. > > For traditional hard drive installations, it's more complicated. A user > might want some nodes to have a static node number based on MAC address, > and just use the corporate DHCP server to assign an IP address. This > approach would use a standard boottab line, except for <DHCP> in the IP > address field. I haven't thought much about how to setup these nodes. > For now, we could document how to manually provide the MAC address to > ssi-addnode, and how to manually set up a local boot partition with a > kernel, initrd, and bootloader. Later, this process can be more > automated somehow. > > For other nodes, a user might want them to be completely dynamic, using > the new CLMS feature to allocate a node number. The setup required for > these nodes is running ssi-addnode-dynamic on the cluster, and creating > a CD or local boot partion with a kernel, initrd, and bootloader. Again, > we could initially document this approach, then later figure out how to > better automate it. Of course, we won't support this approach until the > new CLMS feature is implemented. > > In summary, running a cluster on a corporate network complicates things. > Nodes can't network boot, ssi-addnode can't automatically detect a new > node's MAC address, and the range of IP addresses can't be controlled > well enough to parse a dynamic node number from an address. The only > thing I can suggest you do for this strategy is write documentation for > how to configure a node with a static node number and a dynamic IP > address, as I briefly described two paragraphs above. That way, users > can leverage the <DHCP> work that you did. > > Best regards, > > Brian > > |
From: Brian J. W. <Bri...@hp...> - 2005-02-16 06:17:28
|
En Chiang Lee wrote: > Hi Brian, > > There's a problem with the "quickup" strategy. Below is a paragraph from > the dhcpd.conf man page: > > "Host declarations are matched to actual DHCP or BOOTP clients by > match-ing the dhcp-client-identifier option specified in the host > declaration to the one supplied by the client, or, if the host > declaration or the client does not provide a dhcp-client-identifier > option, by matching the hardware parameter in the host declaration to > the network hardware address supplied by the client. BOOTP clients do > not normally provide a dhcp-client-identifier, so the hardware address > must be used for all clients that may boot using the BOOTP protocol." > > This implies that for a machine to use etherboot/pxe to boot, then we > must specify the MAC address in the dhcpd.conf. > > Any suggestions? > > En Chiang Isn't there a way to give dhcpd.conf a wildcard as the MAC address? If you can't find a solution to this problem today, I'll spend some time tomorrow looking into it. Brian |
From: En C. L. <en...@in...> - 2005-02-17 11:10:38
|
Brian J. Watson wrote: > Isn't there a way to give dhcpd.conf a wildcard as the MAC address? If > you can't find a solution to this problem today, I'll spend some time > tomorrow looking into it. > > Brian Hi Brian, I've been unable to find a solution for this yet. Do take a look when you have the time. Thanks, En Chiang |
From: Brian J. W. <Bri...@hp...> - 2005-02-18 00:56:45
|
En Chiang Lee wrote: > Hi Brian, > > There's a problem with the "quickup" strategy. Below is a paragraph from > the dhcpd.conf man page: > > "Host declarations are matched to actual DHCP or BOOTP clients by > match-ing the dhcp-client-identifier option specified in the host > declaration to the one supplied by the client, or, if the host > declaration or the client does not provide a dhcp-client-identifier > option, by matching the hardware parameter in the host declaration to > the network hardware address supplied by the client. BOOTP clients do > not normally provide a dhcp-client-identifier, so the hardware address > must be used for all clients that may boot using the BOOTP protocol." > > This implies that for a machine to use etherboot/pxe to boot, then we > must specify the MAC address in the dhcpd.conf. > > Any suggestions? > > En Chiang Here's a simple solution: subnet 172.30.0.0 netmask 255.255.0.0 { + filename "/pxelinux.0"; range $startip $endip; group { filename "/combined"; } group { filename "/pxelinux.0"; } By default this will serve pxelinux.0 to any MAC address dhcpd doesn't recognize. For any MAC addresses that it does know, it will serve the appropriate 'filename' for whichever 'group' the MAC address is defined. I tested it myself, and it seems to work the way I described. If we want more flexibility so that users can promiscuously add nodes with Etherboot, we could look at how Chirag's automatic PXE/Etherboot detection strategy would work with dynamic IP address allocation. Alternatively, we could treat everything as PXE, since John Hughes said that Etherboot 5.3 can do PXE emulation. That would simplify our tools! Regards, Brian |
From: En C. L. <en...@in...> - 2005-02-18 11:05:23
|
Hi Brian, Running the dhcp server with your suggestion allows unknown clients to boot from the file specified. However, it's not sufficient to create /cluster/node{number} directory in rc.nodeup because ssisys_cluster_initproc() calls ssidev_mount_devfs() which expects the existence of /cluster/node{number}/dev directory to mount devfs. What would be a good place to create the /cluster/node{number} stuff? Thanks, En Chiang Brian J. Watson wrote: > En Chiang Lee wrote: > >> Hi Brian, >> >> There's a problem with the "quickup" strategy. Below is a paragraph >> from the dhcpd.conf man page: >> >> "Host declarations are matched to actual DHCP or BOOTP clients by >> match-ing the dhcp-client-identifier option specified in the host >> declaration to the one supplied by the client, or, if the host >> declaration or the client does not provide a dhcp-client-identifier >> option, by matching the hardware parameter in the host declaration to >> the network hardware address supplied by the client. BOOTP clients do >> not normally provide a dhcp-client-identifier, so the hardware >> address must be used for all clients that may boot using the BOOTP >> protocol." >> >> This implies that for a machine to use etherboot/pxe to boot, then we >> must specify the MAC address in the dhcpd.conf. >> >> Any suggestions? >> >> En Chiang > > > > Here's a simple solution: > > subnet 172.30.0.0 netmask 255.255.0.0 { > + filename "/pxelinux.0"; > range $startip $endip; > group { > filename "/combined"; > } > group { > filename "/pxelinux.0"; > } > > > By default this will serve pxelinux.0 to any MAC address dhcpd doesn't > recognize. For any MAC addresses that it does know, it will serve the > appropriate 'filename' for whichever 'group' the MAC address is defined. > > I tested it myself, and it seems to work the way I described. If we want > more flexibility so that users can promiscuously add nodes with > Etherboot, we could look at how Chirag's automatic PXE/Etherboot > detection strategy would work with dynamic IP address allocation. > > Alternatively, we could treat everything as PXE, since John Hughes said > that Etherboot 5.3 can do PXE emulation. That would simplify our tools! > > Regards, > > Brian > > |