On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote:
> * David Paleino <email@example.com> [110509 04:19]:
> > On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote:
> > > /etc may include only _static_ configuration. What you have is variable
> > > state which belongs in /var. It's no different from a database, or dpkg's
> > > status data.
> > Static IPs, DNS servers and WEP/WPA keys for a given wireless network are
> > "variable state"? Sorry, I disagree.
> > I already said that I have a patch not to save networks for which no
> > configuration is made -- which is the "variable state" thing at the moment.
> > The question was different
> This isn't about whether the data saved in the config file is variable,
> it is about whether the config file is variable. Files in /etc should
> only be modified when the sysadmin is doing what (s)he considers to be
> "configuration", not when a user is running a program.
So the CUPS web interface, and GNOME/KDE settings UIs, and such other things are
all RC-buggy, because the info under /etc/ was not edited using
vim/nano/emacs/... but through a UI?
I repeat myself: users capable of running a wicd ui are enabled by root, by
adding them to a specific system group (`netdev').
> The specific data shown in the bug report is clearly variable "state"
> information and not static configuration info, [..]
Again, I disagree.
BSSID, ESSID, encryption key, "automatic connection"-flag all sound like
configuration to me. Granted, there are more things to purge (channel and mode,
for example), but that's a bug with a different solution than "move everything
> but even adding and removing more permanent wireless access point info should
> not be done in /etc during the normal, continuous operation of a daemon.
Why not? It works.
> If I were designing the config structure, since each AP is a distinct
> entity that doesn't depend on any other AP (maybe that should be essid,
> not AP), I would have a .d directory where each essid had its own config
> file. There could be corresponding /etc/wicd/something.d and
> /var/lib/wicd/something.d directories. The admin could place files in
> /etc that he didn't want users messing with. Non-conflicting files in
> /etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would
> be treated equally by wicd, with preference to ~user/.config/wicd then
> /var/lib/wicd, then /etc/wicd for any conflicting entries.
> Actually, one normal user should not be able to override the admin
> defaults for another user, so if there is already an entry in /etc, wicd
> should place any user change to that entry in ~user, but new,
> non-conflicting entries should go in /var/lib. Then, the order of
> preference should be ~user, /etc, /var/lib.
I can't understand all this. Network connections are system-wide by their own
nature -- or do you know cases where there could be different concurrent
connections used by different users?
> Transient state information, like signal strength and quality should
> _not_ go in these files, but rather in /var/run/wicd/ (soon to be
I probably haven't been clear enough. That's not configuration, and they
shouldn't go in any config file. And that's already fixed.
There I drop 'quality', 'strength', 'bitrates' and 'has_profile' from the
configuration file. As stated before in this mail, that list could include
'mode' and 'channel', but I prefer to be careful, since those are passed to
. '`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174