Date: Mon, 25 Mar 2002 17:27:49 +0100
From: Karsten Rothemund <[EMAIL PROTECTED]>
The machine lives of course in different network environment (@work in
the university net, @home in a 192-net, etc). I've found
bootrofile[1], which seems to be perfect for booting in different
environments.
There are a number of packages that provide similar functionality.
Here is a list of those I know about:
arping
divine
guessnet
intuitively
laptop-net
laptop-netconf
whereami
I haven't studied all of these tools in detail, but I believe the one
different feature provided by bootprofile is the ability to prompt the
user at boot time for the network configuration. Most of the other
tools use ARP requests to probe the network for known hosts, or else
rely on DHCP. There is a varying level of support for configuration
of the machine after network selection has taken place.
I am a little concerned about bootprofile's design -- it doesn't seem
necessary to do this configuration at such an early stage. If I were
designing such a tool, I'd delay the decision until later in the boot
sequence.
I recommend you use one of the existing tools unless you have a
specific need to manually select a network at boot time. If you
really need that feature, it shouldn't be hard to integrate it into
one of the existing packages. (I've been intending to do this for a
while, but since I have no need for it there's been little urgency.)
There are further issues, previously raised on this list, regarding
the proliferation of such tools, their essential similarity and widely
different configuration styles, and their general lack of modularity.
I have been thinking about this problem and have come to the
conclusion that what is needed is an event-driven system in which each
stage of detection or decision generates an event, which is then
dispatched to one or more programs that act on it. This would enable
the building of various alternative modules for each stage of the
process, while still allowing them to interoperate. There remains the
issue of a more comprehensive configuration language, but that is
almost certain to be contentious.
Chris
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
