Subject: Re: /etc/default? (was: Re: Bug#3368: cron's checksecurity still scans NFS servers)

From: Juergen Menden <[email-masked]>
Date: Mon, 1 Jul 1996 08:34:44 +0200 (MET DST)

On Sun, 30 Jun 1996, Lars Wirzenius wrote:
> 
> This might be an appropriate time to start thinking again about
> /etc/default (under whatever name).  If I remember correctly, someone
> told us that one of the commercial vendors (or SVR4?) has a directory
> /etc/default, with shell scripts that set certain variables.  This is
> used for configuration.  When a program (script) needs the configuration,
> it sources the script.  One of the benefits is that there's a lot of
> potential small configuration files like this, and it could be a bit
> neater to put them into the same directory.

can you tell me the difference between /etc and /etc/default?

jjm

-- 
Juergen Menden                   | Disclaimer: The opinions expressed by me, 
tel:    +49 (89) 289 - 22387     +-----------+ are (usually) not the opinions 
e-mail: [email-masked]     | of anyone else on this planet.

Hi! I'm a .signature virus!  Add me to your .signature and join in the fun!

---

From: Lars Wirzenius <[email-masked]>
Date: Mon, 01 Jul 1996 11:17:42 +0300

[ NB: I read the list.  Don't CC replies to me.  I pay for my PPP.  Thanks ]

> can you tell me the difference between /etc and /etc/default?

/etc is the parent directory, and /etc/default is the subdirectory. :)

All those files could surely be put into /etc, but /etc is big enough
as it is.  My system has about 120 entries in /etc.  It's neater to
put them into /etc/default, since they're all similar (small, same
syntax, similar in purpose, even if not directly related).  I don't
think we want to create fifty new files in /etc.

The current situation is to have the configuration data embedded in
the scripts (e.g., whether the hardware clock is in GMT or not, in
/etc/init.d/boot).  This is not a good thing, since you can't upgrade
the script without destroying the configuration data.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 23:29 BST

> /etc is the parent directory, and /etc/default is the subdirectory. :)

I don't like this answer at all.

> think we want to create fifty new files in /etc.

All *which* files ?  Are you suggesting moving everything from /etc
into /etc/default ?  I suppose you couldn't be.  Every config file
that we (the Debian project) create, as opposed to an upstream file ?
That's an arbitrary distinction which users will find difficult to get
to grips with.

> the script without destroying the configuration data.

I agree that we need separate files.

I think that we may need a new directory

I just want a clear and sensible statement of what goes in the
directory and what doesn't.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 23:27 BST

> can you tell me the difference between /etc and /etc/default?

Before I will even consider amending the guidelines to say to use
/etc/default (or some other name for it) I want a clear and cogent
answer to this question.

I haven't seen one yet.

Ian.

---

From: Lukas Nellen <[email-masked]>
Date: Thu, 11 Jul 1996 11:06:47 -0500

> /etc/default (or some other name for it) I want a clear and cogent

I would say that /etc/default is almost certainly NOT there to reduce the 
clutter in /etc by moving some config files there. What would be the criterium 
if a packages is priveleged enough to get permission to use /etc vs a package 
that has to keep its stuff in /etc/default? To solve the problem of clutter, 
at least partially, it might be worthwhile to check which packages put several 
config files into /etc instead of using a private subdirectory in /etc. I 
think there are still some packages like that around.

My feeling is that /etc/default is apporpriate for setup defaults which might 
be used for installation scripts. Shared runtime config files should rather be 
in /etc, though. A well-designed use of /etc/defaults might help to make the 
installation of a large number of packages less interactive - a plus when 
setting up a large number of machines. Ideas?

			Cheers,
				Lukas

-------------------------------------------------------------------------------
   Dr. Lukas Nellen                 | Email: [email-masked]
   Depto. de Fisica Teorica, IFUNAM |
   Apdo. Postal 20-364              | Tel.:  +52 5 622 5014 ext. 218
   01000 Mexico D.F., MEXICO        | Fax:   +52 5 622 5015

---

From: [email-masked] (Kai Henningsen)
Date: 11 Jul 1996 20:03:00 +0200

[email-masked] (Ian Jackson)  wrote on 09.07.96 in <[email-masked]>:

> > > used for configuration.  When a program (script) needs the
> > > configuration, it sources the script.  One of the benefits is that
> > > there's a lot of potential small configuration files like this, and it
> > > could be a bit neater to put them into the same directory.
> >
*> > can you tell me the difference between /etc and /etc/default?
> /etc/default (or some other name for it) I want a clear and cogent

To what question? The above question (*>) looks more like a weak attempt  
at humour than like a serious question.

Maybe you mean "what is /etc/default(s? I can't remember) good for".

This has, of course, been explained painfully often by now, but I'm  
willing to do it again.

/etc/default would contain files which follow a common syntax. They would  
look like shell scripts that contain *only* variable assignments, and  
comments (and no substitutions in the assignments, either - just  
name=value, and possibly quotes around the value).

Those scripts are useful for any programs (scripts or otherwise) that need  
to have some simple settings (the /rc/init.d scripts would be a good  
example, for an existing SysV example, that's where their tar has things  
like the default device). It's a separate directory both because there are  
potentially very many small files of this sort, and because this way, the  
files in that directory all have the same format and are not mixed  
together with lots of different files with lots of different syntaxes.

Besides, there's prior art - current SysV uses this, and I've also seen it  
on Xenix.

There seems to be clear consensus that scripts need to have _some_ place  
to put this stuff, outside the script itself.

I don't see why we should invent something new, when there is an existing  
mechanism that does exactly what we need.

(Perhaps I should not mention this, given the prejudices of many Linux  
users [including myself], but this directory is really very similar to the  
Windows .ini format - using files instead of sections, and using a syntax  
that makes it easy to access from shell scripts.)

MfG Kai

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 14:04 BST

Kai Henningsen writes ("Re: /etc/default?"):
...
> *> > can you tell me the difference between /etc and /etc/default?
...
> at humour than like a serious question.

That was the question I want an answer to.

If there is no difference then what's the point of the new directory ?

> name=value, and possibly quotes around the value).

So we've had at least two answers so far.

Here Kai Henningsen says `files which follow a common syntax', and
sketches the syntax briefly.

In another message someone else suggested that it was for install-time
rather than run-time configuration.

We need to think about our requirements before stampeding to create
and use this directory.  Configuration files are hard to move - let's
move slowly !

Ian.

---

From: Lukas Nellen <[email-masked]>
Date: Tue, 16 Jul 1996 22:20:21 -0500

> This has, of course, been explained painfully often by now, but I'm  

I think we have to discuss this point rather than explain the `proper use' - after all, no consensus has been reached yet. 

> name=value, and possibly quotes around the value).

To me, this sounds very much like a selection-by-contents, as in: If the file follows such-and-such syntax, it goes into /etc/default, otherwise it ends up in /etc. Or am I mis/overinterpreting your statement?

I must say that I don't like a selection by contents or structure of the file. For my taste, the selection criterion should be by intended use of the file. More or less like the criterion used in the FSSTND (or how is it called these days) to discriminate between files placed into /bin, /sbin, /usr/bin, /usr/sbin.

> like the default device). It's a separate directory both because there are  

What is wrong about /etc/tar.conf in this case? What makes tar better/worse than, say, syslogd or modules?

> together with lots of different files with lots of different syntaxes.

To put it in a slightly drastic way (no offense meant): When I configure my system, I tend to edit files grouped by function, not by syntax. E.g., one day the bootup files, next day the samba configration. Not like: today all config files which use `=' to separate name from value, tomorrow those wich separate them by ` '. So I would prefer to have all files I have to touch for setting up one subsytem grouped together - not those files that have the same syntax.
> Besides, there's prior art - current SysV uses this, and I've also seen it  

But a lot of things that where customary in other UN*X systems have been reshuffled in the FSSTND to reach a more logical arrangement of files instead of some of the historical `ad hoc' placements used in BSD and AT&T systems. I think previous art has to be reviewd critically.
> to put this stuff, outside the script itself.

Certainly the scripts in /etc/init.d need a common place to keep defaults outside the scripts. Other scripts are just like any odd program in the system and should use a config file in /etc. For the scripts in /etc/init.d, let me suggest two different possibilities:
        - A separate subdirectory in /etc
        - A second file per script in /etc/init.d. E.g., for /etc/init.d/foo, 
          add /etc/init.d/foo.conf (or conf.foo or CONF.foo - depending on the
          ordering you like in your file listing)

Before we try to fix the use of /etc/default, it might be a good idea to have a clear statement of how to use /etc by itself. I don't have my copy of the guidelines here, is there a statement about the use of /etc? 

My impression is that as a basic rule, each package (or closely related set of packages) should have at most one file in /etc. If necessary, this can be a subdirectory to hold any number of files. 

There are a number of exceptions from this to accomodate well-known paths, like the placement of /etc/passwd or the directory structure to hold the boot scripts.

Comments, improvements, clarifications or corrections? 

What about system-wide, generic config files - like the tape device ot the paper size. Do we have a mechanism to a) specify their location, b) fix their contents (syntax, allowed values) c) decide which packages have to use the information specified in those files to be considered `bug free'? For the last point, common sense is probably sufficent. For the first to point, we might need to extend the guidelines - maybe a set of appendices maintained by the owner(s) of the packages concerned.

Hopefully, at the end of this discussion we have a better idea about the purpose of /etc/default, too. 

I think to keep the defaults for postinst scripts might be one possibility (I know, I made that suggestion before). It has the same pitfalls as all the automatic maintenace of user editable config files. However, having set up the system once, these defaults could be used on the same or on a different system to install without further user intervention. This scenario requires some work for a large number of packages, though.

                              Cheers,
                                  Lukas

---

From: [email-masked] (Kai Henningsen)
Date: 21 Jul 1996 19:21:00 +0200

> and use this directory.  Configuration files are hard to move - let's

Oh, absolutely. Though I think we're already moving as slowly as possible  
on this one (ie, not at all) ...

> sketches the syntax briefly.

At least that's the only way I've seen this used, and I understood others  
that's what they wanted to use as well.

> rather than run-time configuration.

I've not seen that one. However, *if* we use it for run-time configuration  
(like default options tar, or which character bitmaps to load for the  
console, or whatever), then I don't see why we could not use the same  
mechanism for install-time configuration as well, if there should be a  
need - though the only ones that occur to me at the moment could well be  
called run-time configuration for the installation tools.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 21 Jul 1996 20:39:00 +0200

(> 300 lines. You were warned.)

> I think we have to discuss this point rather than explain the `proper use' -
> after all, no consensus has been reached yet.

Not quite. The point is that /etc/default is an *existing* concept; if we  
use it at all, we should use it in a way compatible with existing usage.

> To me, this sounds very much like a selection-by-contents, as in: If the
> file follows such-and-such syntax, it goes into /etc/default, otherwise it
> ends up in /etc. Or am I mis/overinterpreting your statement?

Somewhat, yes. It is primarily a selection by type, not form, of content  
(and by implication, use).

Stuff in /etc/default is a series of attribute-property values. That's  
certainly a lot more specific than what you can say about /etc in general.

On the other hand, _if_ it goes in there, then it _also_ has to follow a  
specific format. (This might, for example, allow us to write a general  
tool to configure what is in there, or at least to report it. In any case,  
it makes it somewhat safe to guess the syntax for changes.)

For example -

named.boot certainly does not belong in /etc/default, even ignoring  
software that knows where it is. Nor does the fstab, or the passwd file.  
It's not the right type of information, not even if you changed the  
syntax.

adduser.conf could go in there as-is.

Hmm - let's see what I have in /etc at the moment, ignoring subdirs and  
links ... (the list may be inaccurate, as I'm currently looking at the  
directory via the OS/2 ext2 driver, which seems to hide some files.)

                   might go into /etc/default ...
file               not               with syntax changes        as-is
acl.conf           x
adduser.conf                                                    x
adjtime                              ?
ae.rc              x
aliases            x
amd-master         x
at.deny            x
bootptab           x
conf.modules       x
context.conf       x
crontab            x
csh.cshrc          x
csh.login          x
csh.logout         x
debian_version                       ?
defaultdomain                        ?
diald.conf         x
diald.defs         x
diald.options      x
diphosts           x
DIR_COLORS         x
dosemu.conf        x
dosemu.users       x
efax.rc                                                         x
exports            x
fdprm              x
filter.pcl         x
filter.ps          x
fstab              x
ftpusers           x
gateways           x
gopher.rc          x
gopherd.conf       x
gopherdlocal.conf                    ?
gopherremote.rc    x
gpm-root.conf      x
group              x
host.conf                            ?
hostname                             ?
hosts              x
hosts.allow        x
hosts.deny         x
hosts.equiv        x
hosts.lpd          x
inetd.conf         x
inittab            x
ioctl.save         x
ipx.conf                                                        x
ircII.servers      x
issue              x
ld.so.cache        x
ld.so.conf         x
lilo.conf          x
lynx.cfg           x
magic              x
mail.rc            x
mailcap            x
mailname                             ?
majordomo.cf       x
manpath.config     x
mime.types         x
minicom.users      x
minirc.dfl         x
modules            x
motd               x
mtab               x
mtools.conf        x
netgroup           x
networks           x
ntp.conf           x
organization                         ?
party.conf
passwd             x
pcnfsd.conf        x
pgp-i.conf                                                      x
pgp-us.conf                                                     x
pine.conf                                                       x
pine.conf.fixed                                                 x
printcap           x
profile            x
protocols          x
rc.local           x
repair.conf                          x
resolv.conf        x
rpc                x
screenrc           x
securetty          x
services           x
shells             x
site-start.el      x
slip.dip           x
slip.hosts         x
slip.login         x
slip.logout        x
slip.tty           x
smb.conf           x
snmpd.conf         x
sudoers            x
syslog.conf        x
termcap            x
timezone                             ?
uutraf.cf          x
view.conf          x
xearth.markers     x
yp.conf            ?
ypserv.conf        x
ypserv.securenets  x
ytalkrc            x
zlogin             x
zprofile           x
zshenv             x
zshrc              x

All IMHO, of course, and I've not really researched everything in there,  
just looked at the files and made a guess. I've not even checked this list  
against the FSSTND (I wouldn't want to move a file it says lives directly  
under /etc).

It seems that most files under /etc wouldn't qualify for /etc/default, not  
even with a different syntax.

> I must say that I don't like a selection by contents or structure of the
> file. For my taste, the selection criterion should be by intended use of the
> file. More or less like the criterion used in the FSSTND (or how is it
> called these days) to discriminat

It is. Files that contain settings for specific variables for some  
application.

> than, say, syslogd or modules?

1. Well, /etc is already crowded. That's why it has subdirectories in the  
first place.
2. I don't understand. Why should there be a difference between tar and  
syslogd or modules?

> To put it in a slightly drastic way (no offense meant): When I configure my
> system, I tend to edit files grouped by function, not by syntax. E.g., one
> day the bootup files, next day the samba configration. Not like: today all

How is this even relevant to the question?

> But a lot of things that where customary in other UN*X systems have been
> reshuffled in the FSSTND to reach a more logical arrangement of files
> instead of some of the historical `ad hoc' placements used in BSD and AT&T
> >systems.

Actually, the FSSTND has done very little invention. They _have_ selected  
which features to support, and also done some streamlining, but there is  
very few stuff that they have actually invented - I couldn't recall even  
one thing just now.

> Certainly the scripts in /etc/init.d need a common place to keep defaults
> outside the scripts. Other scripts are just like any odd program in the

Nope. All scripts need to put stuff in separate files, independent of  
where they live, because scripts as config files just makes for trouble;  
and all such config files should live _somewhere_ in /etc.

I really don't see why there should be different rules for /etc/init.d  
scripts from the rest.

> Before we try to fix the use of /etc/default, it might be a good idea to
> have a clear statement of how to use /etc by itself. I don't have my copy of
> the guidelines here, is there a statement about the use of /etc?

Of course:

--- snip ---

3.4  /etc : Machine-local system configuration

/etc contains configuration files and directories, which are local to
the current system.

No binaries should go directly into /etc.  Binaries that might in the
past have been found in /etc should be placed in /sbin or /usr/sbin.
This includes such files as init, getty, and update.  Binaries such as
hostname that are used by ordinary users as well as the root user should
not be placed in /sbin but in /bin.

/etc -- Machine-local system configuration
|
+-X11       Configuration for the X Window System
+-skel      User skeleton configuration

/etc/skel is the location for so-called "skeleton" user files that are
given by default to new users when receiving an account.  This directory
may contain subdirectories for different user groups (e.g.,
/etc/skel/staff or /etc/skel/users).

/etc/X11 is the recommended location for all X11 machine-local
configuration.  This directory is necessary to allow local control if
/usr is mounted read only.  Files that should be in this directory
include Xconfig (and/or XF86Config) and Xmodmap.

Subdirectories of /etc/X11 may include those for xdm and for any other
programs (some window managers, for example) that need them.  We
recommend that window managers with only one configuration file which is
a default .*wmrc file should name it system.*wmrc (unless there is a
widely-accepted alternative name) and not use a subdirectory.  Any
window manager subdirectories should be identically named to the actual
window manager binary.

/etc/X11/xdm holds the configuration files for xdm.  These are most of
the files normally found in /usr/lib/X11/xdm; see Section 5,
/var/lib/xdm, for more information.

The following section is intended partly to illuminate the description
of the contents of /etc with a number of examples; it is definitely not
an exhaustive list.

Required files for /etc:

   o General files:

     These files are needed on most Linux systems.

     { adjtime, csh.login, disktab, fdprm, fstab, gettydefs, group,
       inittab, issue, ld.so.conf, lilo.conf, magic, motd, mtab, mtools,
       passwd, profile, psdatabase, securetty, shells, syslog.conf,
       termcap, ttytype }

   o Networking files:

     These files should be installed on most Linux systems.

     { exports, ftpusers, gateways, hosts, host.conf, hosts.equiv,
       hosts.lpd, inetd.conf, networks, printcap, protocols,
       resolv.conf, rpc, services }

     There are two models for setup of the "rc" command scripts which
     are invoked by init(8) at boot time, the /etc/rc.* BSD model and
     the /etc/rc.d/* System V model.  Either model may be used, or a
     mixture of the two.

     Systems that use the shadow password suite will have additional
     configuration files in /etc (/etc/shadow and others) and /usr/sbin
     (useradd, usermod, and others).
--- snip ---

> I think to keep the defaults for postinst scripts might be one possibility

Ah, so this is the message Ian meant that I hadn't seen yet. Well, that  
certainly wasn't my intention.

> (I know, I made that suggestion before). It has the same pitfalls as all the
> automatic maintenace of user editable config files. However, having set up
> the system once, these defa

By the way, some way, your paragraphs seem to get cut at 255 chars or  
around there. Maybe you forgot to limit your line length? Please check  
this.

MfG Kai

---

From: [email-masked] (Bernd Eckenfels)
Date: Mon, 22 Jul 1996 12:41:42 +0200 (MET DST)

Hi,

> called run-time configuration for the installation tools.

/etc/default is, AFAIK used by the iBCS2 stuuf, therefore there is an
exisiting usage for it in other SysV Systems? Perhaps somebody can look into
/etc/default/ on Solaris or SCO?

I think we should use out own configuration directory, since /etc/default is
a bad name and it is used by others which we cant influence (i.e. commercial
iBCS2 packages (in /opt)).

I think someting along the line /etc/config/ for:

subsystem specific configuration files holding name value pairs which can be
used for runtime configuration of various system parametres (including the
boot scripts).

Greetings
Bernd

---

From: Richard Kettlewell <[email-masked]>
Date: Mon, 22 Jul 96 16:37:29 +0100 (BST)

>exisiting usage for it in other SysV Systems? Perhaps somebody can
>look into /etc/default/ on Solaris or SCO?

Well, according to default(4):

             The /etc/default directory provides a common, well-defined
             location for files containing default values for specific
             system settings or parameters.

And from defadm(1):

             The defadm command prints, modifies, adds, or deletes system
             and command default values contained in the file given by
             filename; where filename is a file in the /etc/default
             directory.

(This from Unixware 2.01, a 386 version of SVR4.2.)

For example:

richard@ottawa:richard$ defadm passwd MAXWEEKS
MAXWEEKS=24
richard@ottawa:richard$

-- 
Richard Kettlewell  [email-masked]  [email-masked]
                           http://www.elmail.co.uk/staff/richard/

---

From: Dan Stromberg <[email-masked]>
Date: Mon, 22 Jul 1996 11:12:27 -0700

> used for runtime configuration of various system parametres (including the

/etc/default and /etc/config from Solaris and Irix:

bingy-strombrg> uname -a
SunOS bingy.acs.uci.edu 5.5.1 Generic sun4m sparc SUNW,SPARCstation-5
bingy-strombrg> ls /etc/default
cron    fs      init    login   passwd  su      tar     utmpd

tactical-strombrg> uname -a
IRIX tactical 5.3 11091812 IP22
tactical-strombrg> ls /etc/default
login  su
tactical-strombrg> ls /etc/config
autoconfig.options    network               timed
autoconfig_ipaddress  nfs                   timed.options
automount             noiconlogin           timeslave
automount.options     objectserver          verbose
desktop               quotacheck            videod
directoryserver       quotas                visuallogin
fontserver            rarpd                 vswap
gated                 routed                vswap.options
ifconfig-1.options    routed.options        windowsystem
lockd                 rtnetd                xdm
login.options         rwhod                 yp
mediad                sar                   ypbind.options
mrouted               savecore              ypmaster
named                 soundscheme           ypserv
netif.options         system.glGammaVal

IMO, where debian coincides with SVR4, it should use /etc/default, and
where it doesn't, it should use some other area, perhaps another
subdirectory of /etc, like /etc/debian.conf.  Be sure to note that Irix
is using /etc/config for its own rcstuff.

Even tho unixware seems to be dying, it's kind of halfway between what
sun has now, and what HP/SCO should be expected to ship eventually (In
terms of direct SysV lineage)...  It might be useful for comparison on
similar issues, but we don't have any unixware machines.

---

From: Lukas Nellen <[email-masked]>
Date: Mon, 22 Jul 1996 21:23:50 -0500

>>>>> "KH" == Kai Henningsen <[email-masked]> writes:

>> > <[email-masked]>:

KH> Not quite. The point is that /etc/default is an *existing* concept; if we  
KH> use it at all, we should use it in a way compatible with existing usage.

Ok, maybe I should have said: Is /etc/default a good solution in the
eyes of a majority of the debian users to solve the problem of clutter
in /etc? Or a different subdirectory, in case we don't want to use the
way /etc/default is used in other systems?

>> ends up in /etc. Or am I mis/overinterpreting your statement?

KH> Somewhat, yes. It is primarily a selection by type, not form, of content  
KH> (and by implication, use).

KH> Stuff in /etc/default is a series of attribute-property values. That's  
KH> certainly a lot more specific than what you can say about /etc in general.

To me, that is selection-by-syntax. Some standard use is implied - after all,
it is a configuration file :-). (not a data file...)

KH> On the other hand, _if_ it goes in there, then it _also_ has to follow a  
KH> specific format. (This might, for example, allow us to write a general  
KH> tool to configure what is in there, or at least to report it. In any case,  
KH> it makes it somewhat safe to guess the syntax for changes.)

I admit that such a tool would be nice (for pure Debian installations,
but don't forget heterogeneous setups). The problem I see, though, is
that it creates another layer of meta-configuration. What I mean by
this is: Unless _all_ (or at least a significantly large number of)
packages are changed to use directly the information from
/etc/default, each package wich cannot handle the information in
/etc/default directly must provide a tool to convert the information
from /etc/default into the form expected by the rest of the
package. By this duplication of information, you run the risk that
someone edits the derived configuration file directly. Also, packages
with a more complicated configuration would probably need to provide
some modules to extend the configuration tool. That looks like a fair
amount of work, both sorting out the guidlines for this, including an
API for the configuration tool, and then modifying t the existing
packages to benefit from this tool.

If you cannot get enough packages to use /etc/default files, you might
actually increase the number of configuration files floating around
rather than solving the problem of the clutter in /etc.

KH> For example -
	.
	.
	.
KH> It seems that most files under /etc wouldn't qualify for /etc/default, not
KH> even with a different syntax.

Is it correct then to conclude that /etc/default won't be of much help
to reduce the clutter in /etc?

BTW, I find it more confusing when a package puts several files in
/etc, often with names that make it not-obvious which package they
belong to. I have the impression, looking at the packages which
install files directly into /etc, that there is still room for
cleaning up without excessive code modifications.

>> than, say, syslogd or modules?

KH> 1. Well, /etc is already crowded. That's why it has subdirectories in the  
KH> first place.
KH> 2. I don't understand. Why should there be a difference between tar and  
KH> syslogd or modules?

Well, there isn't that's why, since I prefer selecion-by-function, I
have no criterion to justify why one package puts its configuration
files into /etc, the other one into /etc/default. Your
selection-by-syntax scheme provides such a criterion.

>> day the bootup files, next day the samba configration. Not like: today all

KH> How is this even relevant to the question?

What I don't want to see is the following: A package has two
configuration files, one has attribute-value pairs, the other one has
a more general form. Applying selection-by-syntax would put one file
into /etc/default, the other one into /etc. In that scenario, I would
have to edit files in different places to set up the package.

However, if I put all files into /etc/<packagename>, both files live
in the same place.

			Tschuess,
				Lukas

---

From: [email-masked] (Kai Henningsen)
Date: 23 Jul 1996 18:35:00 +0200

> >>>>> "KH" == Kai Henningsen <[email-masked]> writes:

KH>> [email-masked] (Lukas Nellen)  wrote on 16.07.96 in

> >> > <[email-masked]>:

KH>> Not quite. The point is that /etc/default is an *existing* concept; if we
KH>> use it at all, we should use it in a way compatible with existing usage.

> way /etc/default is used in other systems?

The problem is this:

* We have a lot of cases where config info is contained in scripts. This  
is bad.

* So we want that config info in another file. That makes for a lot of  
extra config files.

* /etc is already very full. Putting this much more config files into it  
is a problem.

So several people have suggested using /etc/default from SysV. This is an  
existing solution to these problems; I prefer using an existing solution  
to inventing a new one (or not solving the problem).

KH>> Somewhat, yes. It is primarily a selection by type, not form, of content
KH>> (and by implication, use).

KH>> Stuff in /etc/default is a series of attribute-property values. That's
KH>> certainly a lot more specific than what you can say about /etc in
KH>> general.

> To me, that is selection-by-syntax. Some standard use is implied - after
> all, it is a configuration file :-). (not a data file...)

Umm - how can it be selection by syntax if nothing syntactical is even  
mentioned here? This doesn't make sense to me.

KH>> On the other hand, _if_ it goes in there, then it _also_ has to follow a
KH>> specific format. (This might, for example, allow us to write a general
KH>> tool to configure what is in there, or at least to report it. In any
KH>> case, it makes it somewhat safe to guess the syntax for changes.)

> but don't forget heterogeneous setups). The problem I see, though, is

What's the problem with heterogeneous setups? I don't see any.

> package. By this duplication of information, you run the risk that

This makes absolutely no sense to me. Why would a package that doesn't use  
/etc/default, need to know about it?

> someone edits the derived configuration file directly. Also, packages

Why would you want to design something like that into a package? Again,  
this makes no sense to me.

> packages to benefit from this tool.

One more thing that doesn't make any sense to me. Why on earth would you  
want modules to extend a configuration tool, when we explicitely specify a  
very simple type of information to manage?

> rather than solving the problem of the clutter in /etc.

Sorry, I don't see how this could lead to even one more configuration  
file.

I get the definite impression that you are thinking of a very different  
system from the one proposed.

KH>> For example -
KH>> It seems that most files under /etc wouldn't qualify for /etc/default,
KH>> not even with a different syntax.

> to reduce the clutter in /etc?

Not at all. See above. We don't want to move everything in /etc around. We  
want to solve a specific problem, and we want to keep the solution to that  
problem from generating a new problem, and while we're at it, we want to  
solve it in as general a way as possible, so other packages besides the  
problem packages (that being packages that use scripts as config files)  
might (not must) be able to use this to solve some of *their* needs.

> cleaning up without excessive code modifications.

That seems to be a different problem.

> >> What is wrong about /etc/tar.conf in this case? What makes tar
> >> better/worse than, say, syslogd or modules?

KH>> 1. Well, /etc is already crowded. That's why it has subdirectories in the
KH>> first place.
KH>> 2. I don't understand. Why should there be a difference between tar and
KH>> syslogd or modules?

> selection-by-syntax scheme provides such a criterion.

Well, as I haven't said that one of these packages should do so while  
another one shouldn't, this seems to be a straw man.

What I did say was that *if* they put something in there, then they have  
to follow the rules. I see nothing wrong with that.

Again, the config files we want to make (because the config data should  
not be buried in scripts) are, as far as I can tell, all or nearly all of  
the nature that would be appropriate for /etc/default, so using /etc/ 
default seems like a natural solution. I really do not understand why you  
have a problem with that.

> have to edit files in different places to set up the package.

Well, don't put it there, then. Nobody ever said that all files of that  
sort *have* to go there.

In fact, if you have multiple configuration files, it may be appropriate  
to have a package-specific subdirectory.

Most packages seem to be quite content with less.

> However, if I put all files into /etc/<packagename>, both files live

True. So? You can obviously do that.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 26 Jul 1996 17:33:00 +0200

> richard@ottawa:richard$ defadm passwd MAXWEEKS

Ah! So the program I speculated about already exists elsewhere! :-)

If there is no free clone, it should not be too much trouble to look at  
the man page and write one.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 26 Jul 1996 17:32:00 +0200

> /etc/default/ on Solaris or SCO?

That is *why* it was proposed to use this for Debian. We need to do the  
same thing, so why not do it the same way?

MfG Kai

---

From: [email-masked] (Bernd Eckenfels)
Date: Sat, 27 Jul 1996 05:38:09 +0200 (MET DST)

Hi,

> Ah! So the program I speculated about already exists elsewhere! :-)

Since I can't find it with archie, I will do a rewrite of it, if some kind
sole may send me the man-page. I will set up a dconf package or something
similiar.

At least for the init.d scripts, the /etc/default/soultion with files with a
fixed syntax is ok. If noone has something to say I will maila small draft
how to 'dconf'igure the init.d scripts.

Greetings
Bernd
-- 
  (OO)      -- [email-masked] --
 ( .. )  ecki@lina.{inka.de,ka.sub.org}  http://home.pages.de/~eckes/
  o--o     *plush*  2048/A2C51749  eckes@irc  +4972573817  *plush*
(O____O)       If privacy is outlawed only Outlaws have privacy

---

From: [email-masked]
Date: Sat, 27 Jul 96 00:07 EDT

Kai>  Ah! So the program I speculated about already exists elsewhere! :-)
  Kai> 
  Kai> If there is no free clone, it should not be too much trouble to look
  Kai> at the man page and write one.

*Sigh* Why doesn't this discussion just _stop_?

We have such a program. Bruce wrote and posted it to this list in March, and
I reposted it about two months ago. All we have to is to decide to _use_
rather than to endlessly go on about it. Here it is again:

Resent-From: [email-masked]
From: [email-masked] (Bruce Perens)
To: [email-masked]
Subject: Little config files that switch things on and off
Date: Mon, 4 Mar 1996 21:40:30 -0800

System V (or is it IRIX) has a chkconfig utility that lets you throw and
check switches that are used in init scripts. You create /etc/config and
then run "chkconfig verbose on", and then "chkconfig verbose" to check the
"verbose" switch in your scripts. Here is a chkconfig.c that I wrote a while
back for Debian. Create /etc/config, compile this, and run it.

	Bruce
/*
 * chkconfig - get/set configuration flags.
 *  A work-alike of the System-V "chkconfig".
 *  Bruce Perens, December 1995
 *	Copyright (C) 1995 Bruce Perens
 *	This program is free software under the GNU General Public License.
 */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <dirent.h>
#include <fcntl.h>

static const char	dir_name[] = "/etc/config";
static const int	dir_length = sizeof(dir_name) - 1;
static const char	on[] = "on\n";
static const char	off[] = "off\n";

static int
getConfiguration(const char * name)
{
	char				pathname[PATH_MAX + 1];
	char				value[3];
	int					fd;
	int					status;
	
	memcpy(pathname, dir_name, dir_length);
	pathname[dir_length] = '/';
	strncpy(&pathname[dir_length+1], name, PATH_MAX - dir_length);

	fd = open(pathname, O_RDONLY);
	if ( fd < 0 ) {
		if ( errno != ENOENT )
			perror(pathname);
		return -1;
	}

	status = read(fd, value, sizeof(value));

	close(fd);

	if ( status < 2 )
		return 0;

	if ( value[0] != 'o' || value[1] != 'n' )
		return 0;
	if ( status > 2 ) {
		if ( value[2] != '\n' && value[2] != '\r' && value[2] != '\t'
		 &&  value[2] != ' ' )
			return 0;
	}
	return 1;
}

static void
setConfiguration(const char * name, int value, int force)
{
	char				pathname[PATH_MAX + 1];
	int					fd;
	int					failed;
	
	memcpy(pathname, dir_name, dir_length);
	pathname[dir_length] = '/';
	strncpy(&pathname[dir_length+1], name, PATH_MAX - dir_length);

	umask(0);

	fd = open(
	 pathname
	,force ? O_WRONLY|O_CREAT|O_TRUNC : O_WRONLY|O_TRUNC
	,0644);

	if ( fd < 0 ) {
		perror(pathname);
		exit(0);
	}

	if ( value )
		failed = ( write(fd, on, sizeof(on) - 1) != (sizeof(on) - 1) );
	else
		failed = ( write(fd, off, sizeof(off) - 1) != (sizeof(off) - 1) );

	close(fd);

	if ( failed ) {
		perror(pathname);
		exit(-1);
	}
	exit(0);
}

static int
noDirectories(const struct dirent * d)
{
	return ( d->d_name[0] != '.'
	 || (d->d_name[1] != '\0'
	  && (d->d_name[1] != '.' || d->d_name[2] != '\0')) );
}

static void
showConfigurations()
{
	struct dirent * *	array = 0;
	int	count = scandir(dir_name, &array, noDirectories, alphasort);
	int					i;

	if ( count < 0 ) {
		perror(dir_name);
		exit(-1);
	}

	for ( i = 0; i < count; i++ ) {
		struct dirent *	d = array[i];
		int value = getConfiguration(d->d_name);

		printf("%s\t%s", d->d_name, value ? on : off);
		free((void *)d);
	}
	free((void *)array);
}

static volatile void
usage()
{
	static const char	message[] =
	 "\n"
	 "Usage:\tchkconfig [ -s ]\t\t\tPrint all configurations.\n"
	 "\tchkconfig [ -f ] name [ on | off ]\tSet value.\n"
	 "\n"
	 "\t-f:\t\tForce creation if value doesn't exist.\n"
	 "\n"
	 "\ton | off:\tValue. Default is \"off\".\n";

	fprintf(stderr, "%s", message);
	exit(-1);
}

int
main(int argc, char * * argv)
{
	if ( argc < 2 ) {
		showConfigurations();
		return 0;
	}
	if ( argc == 2 ) {
		if ( argv[1][0] == '-' ) {
			if ( argv[1][1] == 's' && argv[2] == 0 ) {
				showConfigurations();
				return 0;
			}
			else
				usage();
		}
		return getConfiguration(argv[1]) == 0;
	}
	else if ( argc >= 3 && argc <= 4 ) {
		int	force = 0;
		int	value = 0;

		if ( argv[1][0] == '-' && argv[1][1] == 'f' && argv[1][2] == '\0' ) {
			force = 1;
			argv++;
			argc--;
		}
		if ( argc == 3 ) {
			value = ( (argv[2][0] == 'o' || argv[2][0] == 'O')
			 &&  (argv[2][1] == 'n' || argv[2][1] == 'N') );
		}
		setConfiguration(argv[1], value, force);
		return 0;
	}
	else
		usage();
}

--
Dirk Eddelb"uttel                             http://qed.econ.queensu.ca/~edd

---

From: [email-masked] (Bernd Eckenfels)
Date: Sat, 27 Jul 1996 18:30:17 +0200 (MET DST)

Hi,

> rather than to endlessly go on about it. Here it is again:

chkconfig is irix, defadm is SysV. And I would prefer defadm over the IRIX
solution, since:

if chkconfig syslogd; then syslogd `cat /etc/config/syslogd.options`; fi

is not the way I want to write botup scripts. (But I must admit its nicer
than the way we do it currently.

So, again: please, mail me the man-pages to defadm and I will write a small
clone and a documentation draf for debian usage.

Greetings
Bernd