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. > > 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? CUPS: definitely. Most of its "configuration" is in reality persistent state which most certainly belongs under /var. This has been a major bug in CUPS since its inception. This includes all its queues, PPD files, and even dynamically updated parts of cupsd.conf. It definitely needs fixing, despite upstream's objection to that. Other admin tools may or may not be buggy (see below). There's a fuzzy area between "static configuration" (/etc) and "persistent state" (/var) [and there's also "ephemeral state" (/run)]. If it's generated by a program, it's most likely /not/ static. CUPS queue configuration is this type of data: on one hand one may create it by hand, but it can also be created and updated via lpadmin or via the web interface. The deciding factor for me here is that it also stores queue state in here--that makes it require /var. It could be split into static and dynamic parts split between /etc and /var, or just moved wholesale to /var. Static state is usually obvious stuff such as interfaces and port numbers to listen on. Dynamic state isn't always quite so obvious, but wireless AP info is certainly more on the "persistent state" side than static. It's still configuration, but it's not truly "static" configuration, and so it falls outside the remit of /etc. > I repeat myself: users capable of running a wicd ui are enabled by root, by > adding them to a specific system group (`netdev'). This is not relevant: /etc can not be considered to be writable by default, irrespective of the user/group making changes. > > The specific data shown in the bug report is clearly variable "state" > > information and not static configuration info, [..] > > 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. > d> Why not? It works. Read-only root is a goal we have had for a number of years. We'll actually be mostly there in the very near future with /run and mtab symlinking. Anything which writes to /etc during its normal operation is de facto broken and needs fixing (e.g. CUPS). Programs can not, and should not, expect to have a writable /etc under normal conditions. To clarify, programs such as editors and even custom tools to modify configuration are obviously needed to update configuration files under /etc. However, the admin may have been required to remount / read-write prior to using their tool-of-choice for making changes. Other than this usage, writing to /etc is bad practice. IMO it should be considered RC buggy for wheezy, and banned outright--it's fundamentally incompatible with a r/o rootfs. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature