Re: postinstall wiped out my /etc/rc changes

[George Georgalis <george%galis.org@localhost>]

On Tue 06 May 2008 at 02:29:08 AM -0400, David Holland wrote:
>On Fri, May 02, 2008 at 03:37:00PM +0000, Steven M. Bellovin wrote:
> > I think it's more complex than that.  It isn't obvious -- at least not
> > to me -- which files in /etc are "owned" by the system (and hence are
> > fair game for auto-replacement), and which are owned by the
> > administrator.  (I raised similar questions a few months ago about the
> > power management scripts.)  We need a clear, clean way to make that
> > distinction, and to make it obvious to the community.
>
>I agree.
>
>At the risk of opening a can of worms, I'd argue that anything in /etc
>that is *not* meant to be administrator-modified should be moved out
>of /etc, to /libexec or /libdata or /usr/share or whatever.
>
>Doing this right would in some cases require being able to read the
>contents from two places (e.g. /libdata/services and /etc/services) or
>partitioning the contents of files and reworking the config formats
>(e.g., inetd.conf; the definitions of the standard services should be
>tucked away in /usr/share) or other hacking.
>
>Trouble is, a lot of this stuff is standardized by historic practice
>and changing it around won't be popular. (Even if done right.)

...that's an interesting approach, but even in the best
implementation would be confusing for administration. I think it
would be more sensible to specify alternates in rc.conf, but even
that is confusing if you are navigating the filesystem and come
across config files which are not actually being used.

My approach is to use a repository based configuration management
system. For system changes, I add/commit the file to the repo,
rsync the root filesystem (could use tar) from a tmp export and
restart all managed services. -- that's in responce to the OP, make
no opportunity for the system to squelch my files...

In light of this discussion I should pull existing files to my
checkout, as needed; or at least before each push, so I can diff
the repo for damage control.

As far as best way for the install process to DTRT; if a md5 db is
kept, eg /var/db/nb.inst.db the install process could determine if
target files have changed, or even what to do about it if the hash
matches a known version. (eg a 2.x file could be treated different
than a 3.x one)

In any event, I think simpler is better. I do have needs for
several etc directories, but if I only had one on my system that
would be better for me ;)

// George


-- 
George Georgalis, information system scientist <IXOYE><