Thoughts on network detection and configuration on Debian
enr...@debian.org
There are a lot of packages for automatic network detection and
reconfiguration on debian: whereami, divine, intuitively,
laptop-netconf, laptop-net, netenv and maybe others. IMHO they all have
a problem: they do network detection AND reconfiguration. This is a
problem because Debian already has a way to configure network
interfaces, provided by the base package ifupdown.
ifupdown already provides a way to define configuration profiles, and
hooks for selecting the good one. This means that Debian does not need
a unique tool for network detection AND reconfiguration, but two
different tools, one for network detection and one for system
reconfiguration.
All the mentioned packages provide great ways of detecting what the
correct configuration profile is, and great ways for reconfiguring the
system to use the correct profile. When I say great, I mean great: have
a look at whereami, for example.
The problem is, they don't integrate with Debian. guessnet is a try at
solving the network detection part of the problem, but it only chooses a
profile looking if a given NIC is found on an ethernet network. Much
more can be done: have a look at whereami again, for some good examples.
Then we have the system reconfiguration part. For simple needs,
ifupdown can take care of it, possibly with the aid of a couple of
up/pre-up/down/pre-down commands. For more complex needs, ifupdown
doesn't provide an elegant solution. Maybe the existing reconfiguration
methods could be hooked to ifupdown like wvdial has been, but I'm not
confortable with the entangled ifupdown sources to elaborate more on
that. Maybe the problem of system reconfiguration is an intrinsic mess
and an attempt to solve it cleanly will always bring you to the fields
that linuxconf, dotfile, webmin and others try to address.
In my opinion we should have, as a rule of thumb, one single tool to
solve one single problem. laptop-net is another example on breaking
this rule: it has a nice feature to monitor link beat on ethernet
interfaces, reconfiguring the system when you replace the network cable
from your NIC. I'd like to use it to just call ifdown and ifup, that in
turn do network detection using guessnet, and configuration using
whatever I like best, but that facility is tied to laptop-net network
reconfiguration and other gizmos that I don't need.
I'd like to cooperate with the authors and users of the involved
packages to address this problem and see what they think. If we share
the same concerns, maybe we should merge efforts and try to clean up the
mess.
I'm posting this message on both debian-devel and debian-laptop to try
and reach all the interested parties. I have no idea, however, on where
the discussion should take place.
Bye, Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enr...@debian.org>
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Halls
> * Thoughts on network detection and configuration on Debian
>
> There are a lot of packages for automatic network detection and
> reconfiguration on debian: whereami, divine, intuitively,
> laptop-netconf, laptop-net, netenv and maybe others. IMHO they all have
> a problem: they do network detection AND reconfiguration. This is a
> problem because Debian already has a way to configure network
> interfaces, provided by the base package ifupdown.
>
> ifupdown already provides a way to define configuration profiles, and
> hooks for selecting the good one. This means that Debian does not need
> a unique tool for network detection AND reconfiguration, but two
> different tools, one for network detection and one for system
> reconfiguration.
reconfigure when a laptop wakes up in a new location. Could that be done?
The ifupdown part is only really a part of the big picture for laptop
reconfiguration. Even ifupdown is, in a way, yet another combination of the
detection and reconfiguration steps. It does some things well, others not
so well. Some of the packages in Debian use it, others do not, generally
because they are trying not to be Debain-specific.
I'll try and go through the different steps in the procedure, and look at
what is done to handle them. I use whereami, so sorry if I miss something
out from the others.
Detection-required event
------------------------
The detection process should be started when one of these events occur:
- at boot-time
- hardware, such as a PCMCIA card is added/removed
- APM or ACPI suspend/resume event
- a network cable is plugged in
Each package supports a different combination of events. No package
provides all possibilities out of the box.
Detection flow of control
-------------------------
Some packages treat each interface seperately for detection as ifupdown
does, others do the detection all in one go. I guess generally it is
possible to treat each interface seperately, since usually only one
interface at a time will be active. But maybe someone is doing something
more complicated?
Detection methods
-----------------
Most detection methods boil down to doing ARP pings to different machines to
see if they respond. netenv doesn't even do that - it displays a dialog at
boot time and asks you to choose a location. laptop-net is started from the
command line with a given scheme name.
I decided to use whereami because it can also configure based on an address
received by DHCP. I have also added a pppoe detection script for when I am
on a DSL line.
Reconfiguration - network
-------------------------
Network configuration inolves setting up IP addresses, default gateway,
routes, DNS etc. ifupdown has easy ways for setting the IP address and
gateway, but more advanced configuration such as DNS setup is not provided.
See the last section for a discussion.
Reconfiguration - services
--------------------------
When moving around, various services may need to be started or stopped. For
example, fetchmail should only run when on a network with a permanent
internet connection. Most packages leave that up to the user to script.
laptop-net has a more intricate solution.
Reconfiguration - software
--------------------------
Your DNS servers may need to be changed, or your proxy server, or your SMTP
delivery method, etc. Some packages provide an automatic way of moving new
files in place, such as a new resolv.conf. This means however that you must
start maintaining several copies of configuration files. So every time you
tweak your MTA config, you have to update all other copies etc. etc...
Whereami is building up a reconfiguration script library, for operations
such as changing MTA configuration, proxy configuration and so on. It would
be really useful if we could pool these together so everyone can use them,
rather than each package writing their own.
Another thing I would like to see is the ability to group common actions
together, such as the tasks which are always performed when connected to the
internet, or when I arrive at different subnets on the same network. There
is very little support for this directly in the config files - you usually end
up having to write a seperate script and call that.
All we have to do now is integrate them all togetheri! I'm for extending
whereami, but I was busy helping do that already :)
Chris
--
Chris Halls | Frankfurt, Germany
Enrico Zini
Many great people provided great comments and ideas to my thought and
the picture gets bigger. Another twist is added by the fact that it's
holiday time here in Italy, and I have eaten and drunk things that no
English words to my knowledge can describe :)
You made me discover that my thoughts were limited in may ways; among
others I considered ifupdown the main center for profile detection and
reconfiguration, and I supposed that all the possible system
configurations could be represented by many distinct profiles.
The problem gets bigger and involves many (still independent) parts of
Debian: apmd, acpid, network tools, pppd, pcmcia-cs, hotplug are some
examples of parts of Debian that cause or detect changes on the system
and provide hooks to react to them, and more can be expected to be added
in the future. Reacting to IrDA discoveries comes to mind, as well as
deploying a tool to enable some services based on user requests (take a
look to http://reshare.sf.net for an example of a tool to manage such
requests. Ready to be added to Debian if needed, btw.).
Right now there are utilities to scratch many of the itches related to
this, but Debian seems not to have a masterplan to define its behaviour
for a system that should react to a changing configuration.
Maybe I should retarget my thoughts and start addressing this whole
issue? In fact, right now we already have some problems: pppd scripts
might need to be filled with `if's checking if other network
connectivity is present, and start some network services only depending
on if the system is running on AC power or if a given PCMCIA hard drive
is present. A DNS or a network route might need to be reconfigured by
pppd, pcmcia-cs and network-detection tools. At the current state of
things this things, if pushed, can easily lead to a mess.
Maybe it's time to design a tool that gathers all notification of the
changes that happen in the system and provides the user with a single
point to program the logic to react to them, and standardize it in such
a way that other parts of Debian can interact with it? With it we could
have tools specialized for detection, tools specialized for
reconfiguration and a central point that can do the coordination to make
them work together.
I can easily see that the issue will become more important in the
future, as outplugging devices will become more popular and Linux
systems will be deployed in environments that require more flexibility.
Am I still under the effects of my wonder-lunch (anyone here is invided
should you pass in the nearby) or is there some logic in all this?
If there is, I'm ready to get to work.
Bye, Enrico
P.S.
In the meantime, we might still like to think about merging efforts to
share functionalities with all the network detection tools, and it would
still be an interesting work. Unluckily I won't have access to
whereami until tuesday so I can't make studies right now,
besides proposing to extract the link-beat detection code from
laptop-net in a daemon that launches a script when the link goes up or
down on a given interface and let users hook their preferred tool to it.
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enr...@debian.org>
David Roundy
> Hi everybody!
Hello everyone! I've recently been thinking about this also, and have some
thoughts I'd like to share on the subject. First though, I'd like to say
that I've enjoyed reading peoples emails on the subject, and you guys have
some great ideas.
After some thought, I think that perhaps we need three separate tools for
three separate jobs (but which would, of course, work together). As I see
it, I have three things that I'd like autoconfiguration tools to be able to
do:
(1) Detect my network environment and configure networking properly.
(This is reasonably well served by guessnet along with ifupdown, which is
what I'm using at the moment).
(2) Configure my computer based on location, as in everything else.
In theory this could be done by the same tool as (1), but I think it is
better to be done by a separate utility, so that those who don't need it
won't have to worry about the necesary complexity of such a tool.
Naturally, this should be linked with (1)... this need seems to be served
best by whereami. For a while I used whereami, but for my purposes at the
moment it is overkill. Also, preferably tool (2) would be preconfigured to
work seamlessly with tool (1).
(3) Determine when to redetect my environment and reconfigure.
This tool would detect when you plug in and unplug the ethernet cable,
would be activated on suspend/resume events, pcmcia cards (if I had
any...), etc. I imagine this tool would probably consist primarily of
config scripts in /etc/apm/events.d/ etc., which would then be configured
to call either (1) or (2) as appropriate.
The reason I think these should be separate is that I can see wanting to
use them separately, or in combination. For example, anyone with very
simple reconfiguration needs (like me at the moment) could just not install
(2). Then later, when I configure my computer as a client to an nfs
server or something, I would be able to install (2) and configure it while
still using my existing configuration of (1).
Switching subjects briefly...
As far as ideas for improvement to whereami, I was just thinking that
perhaps a nice way to do some of its work would be to have it switch
runlevels. Since we already have the runlevel mechanism for creating
different configurations (esp for daemons, etc), it might be nice to use
that, although we'd still need a mechanism for changing config files.
Also, that would limit us to three such configurations, which is probably
usually more than enough, but still you hate to build a limitation in to
the software... oh well. Maybe not such a hot idea...
Anyhow, I guess that's about all my thoughts on the subject.
--
David Roundy
http://civet.berkeley.edu/droundy/
Anders Jackson
> On Sun, 09 Dec 2001, Andrew McMillan wrote:
> > I think there aren't enough runlevels for this. I wouldn't want to be
> > restricted to just three choices.
>
> Runlevels 7 to 9 are available, as well.
Still to few for generic use. Only six different areas available with
this solution.
We should probably have some declarative programming language for this
system, like the new system controlling Linux kernel compilation
(don't remember the name of it).
See my last mail on the subject.
/Jackson
John Hasler
> We should probably have some declarative programming language for this
> system, like the new system controlling Linux kernel compilation (don't
> remember the name of it).
CML2. See <http://www.tuxedo.org/~esr/kbuild/>
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, Wisconsin
Tollef Fog Heen
| This doesn't deal with the problem of changing configuration files,
| though (I'd like to start up AFS with its root cell more-or-less
| corresponding to where I physically am, for example). Hmm.
I have solved this in intuively in a way which at least I like. It
symlinks the files it finds in /etc/intuitively/$PROFILE/ to the
corresponding files other places in the file system (being careful not
to overwrite normal files, just symlinks pointing to
/etc/intuitively/$OTHER_PROFILE.
--
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.
Thomas Hood
> Debian seems not to have a masterplan to define its behaviour
> for a system that should react to a changing configuration.
A master plan (i.e., policy) is clearly needed.
> Maybe it's time to design a tool that gathers all notification
> of the changes that happen in the system and provides the user
> with a single point to program the logic to react to them, and
> standardize it in such a way that other parts of Debian can
> interact with it?
A master plan does not entail having a master tool, however.
It has been suggested that at least three tools are
required, but I think that there should be a separate
low-level configurator for each subsystem. If we want to
give the user a unified interface to all the configurators
then that can also be provided.
What is needed in policy is a specification of how configurators
are to be notified of configuration changes (or alternatively,
of how configurators should poll for config changes). The
mechanism needs to take into account the fact that there are
dependencies and conflicts in reconfiguration. Not a trivial
problem.
As a general comment, let me just say that Debian needs to act
on this. I was just playing with Windows 2000 for the first
time and I was very impressed with the latter's plug-and-play
behavior. What impressed me more than anything was the fact
that I was able to move my W2K hard drive to another machine
with a different processor and different installed hardware,
and W2K booted without any problem. It simply detected the
new hardware and hummed along. Debian must aim to be equally
well behaved, IMHO.
--
Thomas Hood