[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ltsp-discuss
Subject:    Re: [Discuss] Automated configuration of thin-clients
From:       Adrian Likins <alikins () redhat ! com>
Date:       2000-03-29 18:15:39
[Download RAW message or body]

On Tue, Mar 28, 2000 at 07:58:06PM -0800, Daniel wrote:
> 
> > > I then used vendor-encapsulated-tags to store information
> > > about all the clients inside the dhcpd.conf file itself.
> > > This way, after the client has loaded its network driver,
> > > it calls a dhcp client which fetches all the relevant options,
> > > including its IP address.
> > >
> >         I was considering the possibility of this, or possibly
> > passing basic config info via kernel commandline option. At least
> > enough info to get the machine on the net and talking (maybe the approriate
> > driver to load, and a nfs or ldap server). I could pass it via the pxe
> > loader config files these way, and wouldnt need to modify dhcp. Would
> > be limted to a small set of options, which could be a problem.
> > 
> 
> As for passing option in the command line of the kernel, it would work.
> But in some circumstances (lets say that there is already is a DHCP
> server in your network and that you cannot change it) etherboot
> or netboot will fail.
> So you basicaly have to put the kernel
> on disk and use a special dhcp client to filter out reply from
> the other DHCP using client identifiers. That is, to be general
> passing option on the cmd line should be optional. Does anyone
> know if theres a size limit of 256 chars on the cmd line as well?
> 
	Didnt find any hard limit on the length in a quick glance
though the source, but I suspect it really is more of a limit
of the boot loader you are using.  

 
> One important thing is that whatever the method we use to get these
> options, it must be possible to change the settings :
> 
> 	a) Without rebooting the station 
> 	   (hard one for DHCP, I'am still thinking about it...)
> 
> 	b) At the begening of the bootup phase.
>
 
> Now since DHCP will reset your network adapter we loose NFS root at the 
> same time (very, very bad) so it's a one time shoot during the ramdisk
> stage. LDAP may be better but it's a heck of a service to maintain.
>
	if root is on a ramdisk, and has enough tools to handle resetting
the interface, this might not be a problem. One of the reasons I like the
concept of root-on-ramdisk, it is potentially much less dependent
on network issues.
 

Adrian

[prev in list] [next in list] [prev in thread] [next in thread]