Ted: Since you seem to be quite knowledgeable with DHCP Server and the likes, do you know what is the "correct" way of providing multiple search domains via DHCP? Is that even supported?
What I mean is for /etc/resolv.conf to be like: search openclustergroup.org ocg.org Thanks, Bernard > -----Original Message----- > From: Ted Powell [mailto:[EMAIL PROTECTED] On Behalf > Of Ted Powell > Sent: Tuesday, June 06, 2006 16:16 > To: Neil Costigan; Bernard Li; Erich Focht > Cc: [email protected] > Subject: ISC DHCP Server > > On Mon, Jun 05, 2006 at 09:48:29PM +0100, Neil Costigan wrote: > > > > a solution was emailed to me direct... > > thanks to Igor N. > > > > >I am not sure if you have figured out the problem you had with > > >etherboot and dhcpd in FC5. > > >Just in case, I had a similar problem - etherboot stopped > accepting > > >dhcpd offers after upgrade to FC5. > > > > > >After banging my head against the wall for a couple of > days, I have > > >found a solution. > > >For some reason etherboot wants to see the "next-server" > option in > > >the DHCP offer. And for some reason the new version of > dhcpd in FC5 > > >does not send that option. > > FC5 uses the ISC (Internet Systems Consortium) DHCP server. In any > version after 3.0.2, the following release note applies: > > - The siaddr field was being improperly set to the > server-identifier when > responding to DHCP messages. RFC2131 clarified the siaddr field as > meaning the 'next server in the bootstrap process', eg a > tftp server. > The siaddr field is now left zeroed unless next-server is > configured. > (/usr/share/doc/dhcp-3.0.3/RELNOTES) > > The relevant paragraph of RFC2131 is: > > DHCP clarifies the interpretation of the 'siaddr' field as the > address of the server to use in the next step of the client's > bootstrap process. A DHCP server may return its own address in the > 'siaddr' field, if the server is prepared to supply the next > bootstrap service (e.g., delivery of an operating system executable > image). A DHCP server always returns its own address in > the 'server > identifier' option. > (http://rfc.net/rfc2131.html) > > The change in the ISC server is appropriate, because unless > the server's > administrator tells it so, it has no business claiming > capabilities of the > host computer that it does not itself provide. If a client > machine has no > other default to try, it can always use the 'server > identifier' option to > try the machine hosting the DHCP server. The PXE code in my > host machine > does so, and successfully downloads pxelinux.0, but > pxelinux.0 does not, > and so it was trying to download its config file from 0.0.0.0. Once I > added "next-server 192.168.150.101;" to /etc/dhcpd.conf, > things worked. > > I was going to make a patch for mkdhcpconf, but I see that Bernard is > already working with that file. > > BTW, unlike the "routers" option (e.g. option routers > 192.168.150.101;), > "next-server" is a _statement_ (e.g. next-server 192.168.150.101;), > contrary to the quote from Igor N. > > > -- > Ted Powell <[EMAIL PROTECTED]> http://psg.com/~ted/ > "If you don't look, you don't know." > Dr. Sam Ting, Nobel laureate experimental physicist. > _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
