On Mon, May 09, 2011 at 04:59:39PM +0200, David Paleino wrote: > 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'). You are right (I'd say). > > 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? No. What I like about (parts of) this solution is that /etc is kept a bit cleaner. For a few reasons (/etc being read-only, or being stored in a VCS) I like the idea of having /etc unmodified in normal circumstances. I completely agree with you that such data wicd stores has nothing to do in ~user. But the concept of two directories, one in /etc, one in /var, is something that appeals to me. The admin can still choose to copy files from /var over if he wants to keep them. If that really solves all use cases, I don't know. If it's the most practical approach, I don't know either. It's just something I'd like in wicd (if wicd then still works as well as it does now for me). > > 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. I like that anyways. Hauke -- .''`. Jan Hauke Rahm <jhr@debian.org> www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundation www.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org
Attachment:
signature.asc
Description: Digital signature