Re: Thoughts on network detection and configuration on Debian
On Sun, 2001-12-09 at 07:44, Siggi Langauf wrote:
> On 9 Dec 2001, Anders Jackson wrote:
>
> > Henrique de Moraes Holschuh <hmh@debian.org> writes:
> >
> > > 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.
>
> There's a conceptual issue as well: Runlevels are fine for selecting one
> of various sets of services that should run, but reconfiguring the system
> requires more:
>
> - reconfigure network interfaces and firewall
> - mount/unmount network shares or reconfigure automounter
> - use another set of search domains for DNS
> - reconfigure hardware (eg. disable wireless Network when you're in a
> location that desn't have an access point, in order to save power)
> - (maybe) switch nntp, smtp, pop, imap and whatever servers
> - lots of too specific stuff that I have forgotten...
As far as a lot of this stuff goes, I think support would need to be
built into the applications.
I mean, the average service that reads one config file, it will be a
pain. You will need to let the user be able to modify settings for an
individual setup and globally, which may require them modifying two
files, then running some kind of update command.
If, for example, Exim knew to load /etc/exim/global.conf, then
/etc/exim/location.d/<CUR_LOC>.conf on top of that, it would work a lot
better. Users could put whatever global/default settings they wanted in
the global file (which, for 95% of users, would be the only file they
needed to edit), and then place any overrides in the other file.
This could done as is, and have an update script, but then you'd need a
complex update script for each app. Exim, for example, would need to
have the two files merged (which would be damn complex, given the way
the Exim files are broken into sections), properly merged (including
removing any definitions in the global versions that are over-ridden or
specifically undef'd in the location file), write the new config, then
signal Exim.
Compare that with just setting the new location in /etc/location.conf
and signaling Exim. The same goes for a lot of other services, many of
which can't just be signaled, but instead have to be brought down.
Remoate shares wouldn't work well since you can't unmount the share when
a program is using it; you must have a way of cleanly shutting down the
service and starting it again. For many services, they might need
modification.
Then take things like user apps. Evolution would need to be modified,
so that it can use the correct SMTP/POP/IMAP/whatever servers for the
given location. And the user would appreciate it if the app didn't have
to be restarted to function properly.
Or am I missing some big huge point that makes my entire argument
invalid? ~,^
>
> One of these specific things could be switching runlevels, but most of
> these changes can't be mapped to a runlevel switch, at least not without
> tricks (like copy an existing runlevel and add a script that does the
> reconfiguration).
>
> => Dont reconfigure by switching runlevels, but allow switching runlevels
> in reconfiguration.
>
> Cheers,
> Siggi
>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: