[syslinux] Network Boot IP Configuration Dilemma

Fred Feirtag ffeirtag at integrityns.com
Mon Sep 8 14:02:39 PDT 2003


H. Peter Anvin wrote:

>Fred Feirtag wrote:
>  
>
>>If the pxelinux.cfg "IPAPPEND 1" entry is used, an "ip=..." string is
>>appended to the parameters passed to the kernel.  This is, as I will
>>ultimately conclude below, a less problematic approach, however,
>>it is in need of being extended to use the currently unused "device"
>>parameter.
>>    
>>
>
>Except, it's not.  If the "device" parameter is specified then the
>kernel may very well configure a different device.  Always tagging
>::eth0: at the end is highly problematic (in fact, it's downright wrong.)
>
I never wanted to "always" do that.  My hack always does that, but
my suggestion was maintain the "1" flag for the current behavior,
but have any other string passed through as the device:
IPAPPEND 1
--same as now
IPAPPEND eth0
--passes ip=#:#:#:#::eth0:
IPAPPEND eth1
--passes ip=#:#:#:#::eth1:
IPAPPEND fd0
--passes ip=#:#:#:#::fd0:  for fddi devices or whatever.
Of course something like
IPDEVAPPEND eth0
would be good or even better.

>There is another issue to keep in mind: unless you're running a dhcp
>server in userspace, your dhcp lease will eventually time out and the
>dhcp server may assign an IP address conflict.
>
Now I see at least part of my difference in perspective.
I'm using static IP's, as if plain old bootp.  The security
and organizational implications of leasing are not good for me.

>>3)  A second DHCP server answers the request differently than
>>   the first.  This is from my experience, the much more likely
>>   and frequent problem....
>>
>Of all your problem descriptions, this is the only one which isn't
>actually a problem.  You will either obtain a legal configuration, or
>you have a much more serious problem of two unsynchronized dhcp servers
>stomping on each other.
>
>...#3 is not a problem in a properly set up environment...
>

In fact, extraneous leasings are the sole source of the actual
problems I've seen.  A system that dishes out IP leases occasionally
becomes active on our network, and it occasionally answers
my booting clients before my static server.  My focus has been
how to identify and respond to this problem.  The error report
will never be "someone plugged a leasing IP server into the
network" it will be "my workstation is hanging sometimes."
Reducing the numer of ways a workstation hangs on bootup
is a good thing for anyone having to diagnose trouble calls.

I would rather create 10 potential, but solid, hardware configuration
errors that, once fixed stay fixed, than create one intermittant operational
error, or even as in this case, make one intermittant operational error
harder to diagnose!  I freely admit that is a strong bias, but that's the
"Dilemma" of my original subject.  That is what I see at issue between
the single vs. double dhcp request, by depending on identical duplicate
dhcp responses.

 From what I can tell, there are good reasons to do it either way.
(The argument by James that the kernel might understand and
potentially utilize more items than PXE is a good one, I think.)
If IPAPPEND is going to be provided as a feature, it shouldn't
be crippled.  I really, really don't see providing for passing useful
parameter values as "plugging random crud" into it.

Many elements of the replies I've seen seem to be considering
what's happening when everything's working right and
configured right.  The ip=::::::dhcp + compiling for kenel
dhcp reconfiguration is an easy solution, and it tests out fine,
when everything's configured right.  I should have been emphatic
that this DOES work just fine, for my purposes under normal
circumstances, when I wrote before.

--Fred

-- 
Fred Feirtag
Chief Technologist
Integrity Linux Systems, a division of Integrity Networking Systems, Inc.
1001 Medical Arts Avenue, NE
Albuquerque, NM  87012
email: ffeirtag at integrityns.com
phone: (505) 294 - 7747
fax: (505) 275 - 1125





More information about the Syslinux mailing list