Paul Millar wrote:
> We could use any naming scheme we choose.  Perhaps best to avoid any 
> collision with PXElinux, as the two are independent; so something 
> like /preseed/$hostname maybe?
> 
> ... BUT ... the three options above were three different ways of d-i 
> discovering which file to use.  This is independent of the transport 
> used to actually fetch the preseed file.  It could be NFS, TFTP, 
> HTTP, ... our choice.  It doesn't have to be tftp.
> 
> Assuming we use HTTP as our transport (as we do currently),  using 
> option 1 (overload the "filename" option), simply do a 
>   wget http://$nextserver/$filename
> where the two variables are expanded from DHCP values.

This seems doable, see Steve's suggestion and my reply.

> Or, (PXELinux style) option 2: work out our hex-filename and do
>   wget http://$nextserver/preseed/C0A80101
>   wget http://$nextserver/preseed/C0A80100
>   wget http://$nextserver/preseed/C0A80000
>  ...
>   wget http://$nextserver/preseed/default
> until one succeeds.

I don't think this extra complication is necessessary with preseed
files, especially ones loaded over http. The preseed setup allows one
file to be loaded and include others based on the machines's hostname
or, indeed, any other shell command that can run in the installer
environment. Added to that we have the option of making the preseed
file a cgi script, and with all that flexability I don't think we need to
bother with the pxe-style mac probes.

> Or, (Grub-style) extract our tag, treat it as an URL and do
>   wget $URL
> 
> The last option is the most flexible, as we could allow the user to 
> specify a complete URL which could (potentially) be anything we want 
> to support, e.g. nfs://host/path, ftp://server/path, 
> tftp://server/path, ...

Another way to get this level of flexability would be to overload the
filename option to just be a complete url, and not use next-server at
all (and use Steve's class-based system to deliver the filename/url to
d-i and not to pxelinux). I don't know if that's a worse or lesser
violation of the RFCs than grub's method.

-- 
see shy jo

Attachment: signature.asc
Description: Digital signature

Reply via email to