On Sun, 2006-05-07 at 20:47 -0400, David Nusinow wrote: > First of all, kudos on this excellent program. It's really fantastic.
Thanks :-)
> I think that a very common use case is to have a series of wireless
> networks that you might connect to, and you may have a preferred order by
> which you want to connect to them. Such as, try home first, then work, then
> other work location, etc. This can obviously be expressed just fine by
> detect.conf, but it's rather complicated to set up as it is.
Indeed. Many vague thoughts about simplification of this have entered
my head, but unfortunately haven't managed to materialise into any
significant concrete implementable ideas...
> I think a good default config file to ship would be to bring up dhcp if
> eth* is plugged in. If not, try to get a wireless address from some
> available network.
This is a good thought. One problem is handling possible conflict with
ifupdown which is there by default, and still needed event with whereami
installed. I would like to do that though, and really the only need for
ifupdown is to handle the "lo" interface, which is not hard. Possibly I
should just teach whereami to handle "lo" and the Provides: and
Conflicts: with ifupdown. That seems a harsh approach, perhaps, however
it would enable me to ship much more sensible default configuration...
Of course if I "Provides:" ifupdown then I would possibly have to
implement some additional functionality that users might expect.
> Also, if possible, give the user a set of debconf
> prompts to list wireless networks in order that they'd like to use. This
> may be too complicated for debconf though, so providing a simplified
> default conf file that uses a more complicated detect.conf behind it to
> actually configure this. The config file could be a "wireless_order.conf"
> or something, which would just be a list of wireless networks to be tried,
> in order, along with an optional WEP key next to network name. The user
> could simply edit this file, or a very basic frontend could be put in front
> of it. Any user needing something more complicated could have a detect.conf
> that ignores this file.
This is certainly an interesting idea.
Perhaps adding a "wireless-priorities" file, that operated this way, and
a new keyword in detect.conf which triggered that parsing. That way
detect.conf would continue to apply exactly as it does at the moment,
but the wireless detection could be (in that file) a simple command,
returning the correct detected and prioritised network name. A user
needing more complicated setup (or with an existing working setup) would
then not be affected in any way.
Does this sound like a reasonable approach to you?
> I know this is rather complicated, but it'd be great to have whereami
> ship a functional setup on install for most people, that could be easily
> modified further down the line. If I get some time, I'll try and code up an
> implementation for this myself, but please beat me to it if you like the
> idea :-)
That would, of course, be ideal :-)
If you are able to think about a script to run from detect.conf (or a
subroutine called from within the parsing of it) then that would be
great. Meanwhile I will try and have a think about this myself.
Also, thank _you_ for all your good work for Debian also :-)
Regards,
Andrew McMillan.
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
Powering the .NZ namespace with Open Source Software
-------------------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part
