Re: Proposal: /etc /usr/etc /usr/local/etc
On Tue, 8 Jul 1997, Bill Mitchell wrote:
> > 1. Moving various files to /usr/etc (the Simple Solution)
> > 2. Having symlinks in /etc pointing to /usr/etc (the Symlink Solution)
> > 3. Making the programs in Debian first seek for conffile in /etc, then
> > in /usr/etc (Yann's Solution)
> > 3.a Write a function which will do it (Yann's Solution 1)
> > 3.b Write a driver that will do it (Yann't Solution 2)
> > 4. Using [.. the transname stuff..] to mount remote /etc (the Remote /etc
> > Solution)
> There should be at least two other alternatives added to this list:
> 0. Putting all config files in /etc (the Very Simple Solution)
> 5. Using the transame stuff to mount a remote root partition
> (the Diskless Workstation Solution)
> Solution (2) is current practice.
> I would vote for (2) today because it's FSSTND-compliant, and because
> it provides for both site-wide and machine-specific config files.
> The package maintainer decides where the config files go, and
> it's illegal to move them unless/until the dpkg-maintainers give
> their OK (dpkg must deal with the relocated files properly on
> package upgrades and removals).
But you've seen the explanation of the problem. Then, I would vote
> I would vote against (0) because it doesn't address admin concerns
> in networked systems (doesn't share common site-wide config files,
> all config files are machine-local). It's perfectly possible to
> have and administer a system where all conffiles are machine-local,
> of course, but there's less chance of error and confusion if files
> intended to bethe same in all machines are shared from one single
> copy located in one single location.
I wouldn't call it a solution, but a problem, and that's what we have
now. I'm strongly against it.
> I would vote against (3[ab]) unless and until it can be shown that
> they're FSSTND-compliant. Even then, I'd be leery of (3a) because
> it would break many existing programs so that they would run but
> would fail to find config files in /usr/etc.
IMO FSSTND is not a canon, but a guide, and we must use a better
solution if we find one. Su I would vote for it.
> From what little I've read in debian-devel about transname, I think
> (4) and/or (5) may offer the best solution. However, I can see how
> they might be looked on with suspicion by some sysadmins just
> because they look strange. I'd say go with (2) in the short term,
> and consider moving to or, better, offering the sysadmin the option
> of using (4) and/or (5) later on.
Yes, they look too weird. I wouldn't like the solution 5 because
diskless workstation is a completely different issue, and making a
workstation diskless only to solve the conffiles problem sounds
> I think it would be dynamite for debian to offer sysadmins the
> option of choosing (2) or (4/5), and to provide effective admin
> support tools to support maintenance of the machine-specific
> conffiles (including tools to convert installed confiles between
> the (2) and (4/5) schemes).
I would like the solution 3 ('cause people don't agree to solution 2),
because mounting /etc sounds bad to me (see one of my other mails for
the explanation of my point of view).
> Some days ago (it seems longer than just a few days) I opined
> that this topic wasn't yet timely. Despite having become involved
> in this too-long discussion on this thread, I still believe that.
> I think we ought to put this aside for now, and take it up
> again once we have a working set of install disks for
> debian-standalone, debian-fileserver, and debian-workstation.
Does someone work on it now?
> Finally, Bruce Perens <email@example.com> said:
> > I've been writing an architecture for remote and workgroup administration
> > that would address most of these issues. It'll take some time to be implemented,
> > but expect to see demonstrations soon. Watch debian-admintool if you are
> > interested.
> So, we need to wait for that in any case.
Vadim Vygonets * firstname.lastname@example.org * email@example.com * Unix admin
The fish doesn't think, because the fish knows... everything.
-- Arizona Dream
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .