On 21-Jul-06, Jan Schneider wrote:
> Am Freitag, 21. Juli 2006 17:18 schrieb Olaf Dabrunz:
> > I see. For your application it seems to be enough to know when a client
> > requests a file (and maybe you communicate client details using some
> > other communication channel). Otherwise I would expect the patch to
> > communicate client-specific information to the program that provides the
> > file.
> Thats right.
>
> Think about a client on which you want to install debian or suse or some
> other
> operating system using PXE, PXELINUX, atftpd, a kernel and an initrd.
> You would have to create the file in pxelinux.cfg/01-01-02-03-04-05-06,
> where 01-02-03-04-05-06 is the hw address of the client.
> The file should contain something like:
> ------
> default install-linux
>
> label install-linux
> kernel vmlinuz
> append ramdisk_size=64000 init=/etc/init initrd=initrd
> ------
> On the next boot the client will read this config, transfer the kernel and
> initrd and start linux.
> After the operating system installation on the clients harddisk is completed,
> the client needs a reboot to start the new os.
> Before the restart you will have to delete the pxelinux config file or end up
> in a loop.
> For security reasons you will not allow the client to delete files on the
> server.
>
> >
> > Anyway, AFAICT you will have a problem with concurrent access to the
> > FIFO by multiple instances of atftpd (when multiple clients request
> > their files at the same time). If your environment (opsi) works around
> > this problem, it would be helpful to either give a simple example in the
> > manpage how the FIFO could be used safely, or to document it as a
> > special feature that cannot be used in a simple way from the command
> > line.
> We only use FIFOs for client configuration data.
>
> >
> > The feature itself needs documentation in the manpage anyway. Please
> > explain how it can be useful to the user, with and without opsi.
> >
> > > After reading the pipe it is possible to close it, so the computer will
> > > not find a boot-configuration on the next reboot and will boot from its
> > > local harddisk.
> >
> > How can you do this on a client-by-client basis? Is it possible only
> > from within opsi, or is it possible for every user of atftpd?
> ------------------------------------------------------------------------
> [EMAIL PROTECTED]:~# mkfifo /tftpboot/pipe
> [EMAIL PROTECTED]:~# echo "atftpd fifo test" > /tftpboot/pipe \
> && rm /tftpboot/pipe \
> && echo "fifo read and deleted" | wall &
> [EMAIL PROTECTED]:~# atftp localhost
> tftp> get pipe
>
> Broadcast Message from [EMAIL PROTECTED]
> (/dev/pts/7) at 17:49 ...
>
> fifo read and deleted
> --------------------------------------------------------------------------
> #!/usr/bin/perl
> use POSIX;
> my $pipe = "/tftpboot/linux/pxelinux.cfg/01-00-01-02-03-04-05";
> POSIX::mkfifo($pipe, 0644) or
> die("cannot create Pipe %s.\n", $pipe);
> sysopen(FIFO, $pipe, O_WRONLY, 0644);
> print FIFO "default linux\n";
> print FIFO "label linux\n";
> print FIFO " kernel vmlinuz\n";
> print FIFO " append ramdisk_size=64000 init=/etc/init initrd=initrd\n";
> close(FIFO);
> unlink($pipe);
> ---------------------------------------------------------------------------
I see.
And I guess opsi will take care the pipe is only created when that
specific machine needs to boot over the network, e.g. when you want to
install or reinstall it.
It would be good to have this information in the manpage of atftpd. I
would suggest including the following:
- a description of the FIFO feature ("you can use named pipes/FIFOs
in addition to files")
- how to use it ("it can be used on the tftp server side to tell the
clients (separately, if you want) to boot from network or to boot
from their fallback boot method")
- your example
- it may or may not be a good idea to mention that opsi uses this
feature ("opsi uses this to provide...")
A patch that contains both the documentation and the code would be much
easier to consider.
Regards,
--
Olaf Dabrunz (od/odabrunz), SUSE Linux Products GmbH, Nürnberg
