On 12/15/2015 10:54 AM, Christopher wrote:
On Tue, Dec 15, 2015 at 12:37 AM J. Randall Owens
<jrowens.fed...@ghiapet.net <mailto:jrowens.fed...@ghiapet.net>> wrote:
On 12/14/2015 02:47 PM, Christopher wrote:
> On Mon, Dec 14, 2015 at 11:22 AM Reindl Harald
<h.rei...@thelounge.net <mailto:h.rei...@thelounge.net>
> <mailto:h.rei...@thelounge.net <mailto:h.rei...@thelounge.net>>>
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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
