On Mon, 9 May 2011 09:45:41 -0400, Marvin Renich wrote: > * David Paleino <dapal@debian.org> [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 to /var/". > 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 > /run/wicd/). 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. http://git.debian.org/?p=collab-maint/wicd.git;a=blob;f=debian/patches/34-dont_save_useless_config.patch 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 iwconfig. Kindly, David -- . ''`. 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
Attachment:
signature.asc
Description: PGP signature