|
From: <ebi...@ln...> - 2002-07-05 19:06:18
|
ke...@us... (Ken Yap) writes: > >1: Boot LTSP from server.hoffmeister.augustinnetz.de => /vmlinuz.ltsp (TFTM) > >2: Boot Doze from server.hoffmeister.augustinnetz.de => /doze.img (TFTM) > >3: Boot testfile from anselm.hoffmeister.augustinnetz.de => /test/image (NFS) > > > >How could I do this with option "next-server" ? Not at all. And having the > >server name in the URI is the trivial config, and most intuitive, too. > > Next-server is scoped just like other options in dhcpd.conf so you can > have as many next-servers as there are images, or share them in groups. > Next-server is actually more flexible in usage in DHCPD even if less > easy to read than embedding the server IP in the filename. > > Don't fool yourself into thinking that generality of expression and > adhering to a standard will automatically give you usefulness. > Etherboot is not a web browser, the protocol is not TCP, you cannot > fetch from just any server on the Internet without a lot of extra > mechanism. O.k. I have been talking about this with the users on my end and for me at least there is one very useful thing to be gained with the: ://<server>:<port>/filename syntax. And that is the ability to specify a port. Unless there is an option to specify a different one. This may be a wasteful bit of the slam protocol as I have it currently defined. But it currently uses one port per file. So I can't do the :/// trick. Not that I think specifying a different server that is on the other side of a gateway would be a good idea. But I do think being able to specify a server port in a standard way is good idea. But this code can be put into a generic part of the parser and it doesn't need to be replicated across protocol implementations. As for specifying a different server, there are plenty of useful cases where you don't need a gateway. This can be useful for distributing the load between machines, etc. Eric |
