Date: Tue, 30 Aug 94 04:24 PDT From: iwj10@cus.cam.ac.uk (Ian Jackson) Subject: Re: initialization files, and /etc/skel There seems to be a certain amount of confusion about /etc/skel and /usr/doc/examples. The most important thing to remember is the following: Files in /etc/skel will automatically be copied into new user accounts by adduser. They should not be referenced there by any program. Files in /usr/doc/examples should not be installed automatically. Therefore, if the program in question need a dotfile to exist in advance in $HOME to work sensibly that dotfile should be installed in /etc/skel (and listed in conffiles). However, what my little rant was about was my strongly held views that programs that require dotfiles in order to operate sensibly (dotfiles that they don't create themselves automatically, that is) are a bad thing, and that programs should be configured by the Debian default installation as close to normal as possible. Therefore, if a program in a Debian package needs to be configured in some way in order to operate sensibly that configuration should be done in a site-wide global configuration file elsewhere in /etc (and that file should be listed in conffiles). Only if the program doesn't support a site-wide default configuration should a default per-user file be placed in /etc/skel (and listed in conffiles). The idea is as follows: The sysadmin should ideally not have to do any configuration other than that done (semi-)automatically by the postinst script. However, if they wish to change their configuration themselves (because the configuration they want is beyond the scope of the autoconfiguration, or because the autoconfiguration doesn't exist yet, or because they just want to do it themselves for any reason) then /usr/doc/examples exists as *documentation* for their benefit. The only time these files should be read are by the sysadmin using their favourite editor or pager, or *perhaps* (in very complex packages) by the postinst as a template to build on or modify. /etc/skel is part of the *implementation* of this configuration. It contains the files that are copied into new user accounts. It should probably be as empty as we can make it. Ian Murdock writes ("initialization files, and /etc/skel"): > The Debian 0.93 /etc/skel only contains .bash_logout and .profile. > There may also be a .xsession added to the next xbase package. IMO /etc/skel should not contain a .profile file. Anything that needs to be done there should be done in /etc/profile. Anything that shouldn't go in /etc/profile (which users can't avoid running, btw) probably shouldn't be in the default configuration. bash has generally good default behaviour. Likewise, bash functions perfectly happily without a .bash_logout, so none should be provided, since anything in it is a deviation from the sensible default behaviour. /etc/skel should not contain a .xsession. xdm's system-wide startup file /usr/lib/X11/xdm/Xsession supports a system-wide default user configuration (which should probably be /etc/X11/Xsession or some such) which may be overridden by .xsession in the user's home directory. Therefore there is no need for a .xsession to be installed by default and none should be provided. Instead, a sensible /etc/X11/Xsession should be provided, and if desired this can be used as a template by users who wish to install their own configuration, or alternatively a more comprehensive example with much commented-out interesting stuff could be put in /usr/doc/examples. If the sysadmin wishes to change the system-wide default they should probably do this by editing /etc/X11/Xsession rather than creating the file in /etc/skel, because the former will affect all user accounts that haven't explicitly overridden things by creating their own file while the latter will only affect new accounts. > In general, we should not add files to /etc/skel and assume that the > administrators of a Debian system are going to want a copy of that > file put into the home directory of every user. /etc/skel should be > the domain of the administrator, but sample files should be in > /usr/doc/examples for them to use, customize and put into their > /etc/skel if they want to. The key words here being _if they want to_. We should, if feasible, provide all the configuration necessary for a program to function. Therefore sysadmins will not need to go through /usr/doc/examples while editing configuration files in /etc except in extreme cases (like INN) where the configuration was too difficult to do automatically. Bill Mitchell writes ("Re: initialization files, and /etc/skel"): > You lost me there. Given a program without site-wide defaults, are you > saying that its init files should go in /usr/skel or in /usr/doc/examples? Its site-wide init shouldn't go in either. In the case of twm, for example, the system-wide default should be in /etc/X11/system.twmrc. (The default location for this in X11R5, btw, is in /usr/lib/X11 somewhere, but we can't put it on /usr because of CDROM distributions, etc - hence the FSSTND's mandate to put configuration files in /etc.) There should be no .twmrc file in /etc/skel. You can have one in /usr/doc/examples if you *like*, but why bother if system.twmrc is a good example (and indeed is the one the user is using before they create their own) ? /usr/doc/examples isn't mainly for example *configuration files*. It's for any kind of example file distributed with a package. For example, GNU m4 comes with a whole pile of example m4 macro scripts, which is exactly what /usr/doc/examples is for. > /usr/doc/examples is a nonstandard debian abberation. Not necessarily > a bad thing, unless it becomes an undocumented dumping-ground, but it's > a nonstandard debain-specific departure from whatever is done elsewhere. /usr/doc is an FSSTND-recommended location, and its existence will be prominent in many of the notices that the postinst scripts, /etc/issue, etc. will display. `examples' is just a useful categorisation of the stuff in it. > I'm concerned that installers end up with a bunch of package init > files over in /usr/doc/examples without knowing the significance of that, > and without knowing that they then need to manually review what's there > and possibly move some of it to /etc/skel. Any non-debian documentation > they find will lead them to look in /usr/skel for the files, and we won't > have put them there. /etc/skel (not /usr/skel) is for a completely different purpose. It's not for *examples*, it's for the *defaults* *installed* in *new accounts*. > On the other hand, I guess I could drom a kermit.README file into > /usr/doc/examples explaining what I've put there and what should be > done with it. Whatever I do, though, should be the same thing everyone > else does (not that everyone should follow my lead -- just that everyone > should not take their own unique approach to this). I'm not sure what Kermit is like wrt config files. If you give me more details I can answer. See below for some comments, but if you can say `what should be done with it' you should probably do that yourself in the postinst, or by simply installing the files in the right places. Bill Mitchell writes ("Re: initialization files in general -- kermit in particular"): > What you're saying here is that the unassisted manual step of evaluating > /usr/doc/examples/dot. files will be required of all debain > installers. Individual installers must then manually install whatever > they individually decide on into /etc/skel. I'm not saying that this > is necessarily an unreasonable requirement, just being clear that it > sounds like you're saying that this will be a requirement. No, this won't be a requirement - or at least, not for the packages for which the package maintainer was able to provide a sensible default file (this isn't always possible due to the fact that some programs have very system-dependent configuration requirements - named is probably a good example). > It always rankles me when we start talking about "administrators" and > "users", [...] The distinction *is* important here, because we're talking about the (admittedly sometimes subtle) differences between site-wide and per-user configuration. The differences are important though. > Most linux systems will be administered by a non-guru who does not have > extensive *nix systems administration background, who has little > fallback support readily available to him, and who does not have an > extensive technical reference library. But I digress...... Err, you've misunderstood me if you think what I'm saying will make life harder for the sysadmin. What I'm trying to do is to reduce the number of places that specify the same piece of information for different contexts - to one, if possible. This is a good and useful thing for the sysadmin. > I don't think either of the two approaches we've articulated (putting > skel files in /etc/skel/. vs. /usr/doc/examples/dot.) > is really a good one, given that system installers are likely to have > marginal amounts of background. Either one, though, is better than a > mixture of the two. I'll take the pronouncement that /usr/doc/examples > is the proper place for files which would normally go into /etc/skel as the > final word on this. You've clearly misunderstood me. I was expressing my opinion that there are very few files that would `normally go into /etc/skel'. Ie, an out-of-the-box Unix-like system of any description should not install zillions of dotfiles in new user accounts by default. Files that should be installed in new user accounts should be in /etc/skel, as that will ensure that they *are* installed in new user accounts ! However, we should try to avoid the need for this. > I presume that some documentation will be provided > by someone which will explain the nature and significance of debian's > /usr/doc/examples/dot. files, since they won't be mentioned in > any non-debian reference materials which debian installers look at. /usr/doc/examples is just what it says: documentation in the form of examples. If a sysadmin is required to go and read these files for their system to work they should be told about it. For example, here is what the Smail postinst script says right at the start: I can do certain kinds of automatic configuration of your mail system, by asking you a number of questions. Later you may to confirm and/or correct your answers. In any case, comprehensive information on configuring Smail is in smail(5) and in /usr/doc/examples/smail and /usr/doc/smail-admin-guide. /usr/doc/examples/smail contains a number of directories with different kinds of example configuration. /usr/doc/smail-admin-guide is a roff -ms document that comes with Smail. > I'll put together a kermit distribution which places its skel files > in /usr/doc/examples as dot.kermrc, dot.mykermrc, dot.kdd, and dot.ksd. > I see this kermit distribution as a fallback, for use in the event that > no distribution is forthcoming from the kermit maintainer. What will Kermit do in the absence of .kermrc, .mykermrc (what's the difference between those two), .kdd and .ksd files ? If it can be made to look for system-wide defaults then they should probably be provided in /etc/kermit or some such. Otherwise, if its behaviour in the absence of the dotfiles is undesirable, you should put files in /etc/skel. After all this you can then decide whether you want to give any other examples in /usr/doc/examples/kermit. Ian.