|
On 12/15/2015 10:54 AM, Christopher
wrote:
On
12/14/2015 02:47 PM, Christopher wrote:
> On Mon, Dec 14, 2015 at 11:22 AM Reindl Harald <h.reindl@xxxxxxxxxxxxx
> <mailto:h.reindl@xxxxxxxxxxxxx>>
wrote:
>
> i modified my "httpd.conf" based on Apache 2.2
years ago, as Fedora
> swicthed to Apache 2.4 your approach would have
compared a customized
> Apache 2.2 version with a Fedora 2.4 version
>
>
> But, that's precisely what I want to do.... I want to
know which fields
> in the current configuration could possibly have
introduced a breakage I
> see... or which changes I need to make from a clean
installation to get
> a user back to the state they wanted.
>
But in order to do the former, you'd best compare the new
default to the
old default, to see what had changed in the default. (E.g.
distro 2.2 to
distro 2.4) To do the latter, you'd compare the old default
(distro 2.2)
to your modified version (altered 2.2), to see what you'd
changed
locally. And yet, you seem to be proposing comparing the new
default to
the old default (distro 2.4 to altered 2.2), which gets you
neither? (Or
both, really, but uselessly mashed together so you don't
know which is
which.) Am I missing something?
I'm less interested in what the user intended to change
in an older version than the full difference between the
current default (presumably working) configs and the current
files (which would include any user modifications AND any
old defaults carried forward). The current system breakage
could be the result of user edits, or a carry-forward of an
older config. I don't care which is the case... I just want
to see the differences to troubleshoot the problem... I just
want to fix the system as it exists today... not question
user edit decisions which occurred years ago.
Certainly, a full history, tracking all user edits, and
all system updates, would be useful to some. It's just more
than what I personally need, and seems a bit outside the
scope of the existing installer tools (as previously stated
with the suggestion to use etckeeper).
Full tracking of user edits and system edits, seems like a very
development-focused perspective on config management. Sometimes, a
sysadmin just wants to see what's different *now* without too much
more detail.
For now, I think I'm going to write a script to parse the
output of `rpm -V` and then `dnf download` all the packages
corresponding to changed configs, then extract each rpm's
%config files, to compare with those on the system. It's
messy, but it'll work, and in the absence of rpm storing the
full configs or being able to instruct rpm/dnf to reset
configs back to the defaults (after backing up), there
doesn't seem to be an existing solution that will give me
the same result.
It seems like there's already a little bit of precedent for
"alternate trees" representing the existing file system with the
debuginfo rpms and /usr/lib/debug/ hierarchy. Although the easiest
solution might be to have RPM deposit a duplicate copy of *all*
config files (not just %config(noreplace)) adjacent to the config
file actually read by the programs (e.g., /etc/httpd/conf.d/ssl.conf
and /etc/httpd/conf.d/ssl.conf.rpmdist), that leaves lots of ugly,
mostly unused, files everywhere.
Perhaps RPM (or yum/dnf, via plugin) could write a duplicate copy of
all config files into a tree somewhere? (E.g., /usr/lib/config/ or
/usr/share/config/?) RPM/yum/dnf could then do the equivalent of an
`rpm -qlca` and compare each /etc/httpd/conf.d/ssl.conf to
/usr/lib/config/etc/httpd/conf.d/ssl.conf with no real magic or
complex tech needed. Merging left up to the sysadmin.
Having everything in one location might also give some future
options for automated compression, refreshing scripts, and the like.
Regards,
-jc
|
