On Sun, Dec 13, 2015 at 2:50 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
Am 13.12.2015 um 05:58 schrieb Christopher:
> rpm could track more than hashes of config files, and instead track the
> full file. This could be optional, as it uses more disk space, but disk
> space is cheap these days, and config files are relatively small. This
> would avoid having to re-download the rpm, and would make it easier to
> see what has been modified on their system. So, some users may find that
> a worthwhile trade-off
first: disk space is *not* cheap these days *
second: etckeeper exists
third: no need to re-invent the wheel
I meant that it's cheaper than it ever has been, and that the marginal costs of adding a 100MB or so is very small compared to the overall size of the disk. Certainly, it wouldn't be appropriate for all cases, but I feel confident saying that the average user isn't going to notice, in terms of disk utilization or costs, if the size of /etc doubles. Honestly, I didn't think that would be a contentious premise, and it's not exactly the main point of what I was trying to say. I did point out that it would be worthwhile only for "some users".
Didn't know about etckeeper. Suggestions like that are exactly why I raised the question. I'm not suggesting the wheel be reinvented. I'm trying to figure out whether there exists an appropriate wheel to use, and if not, what materials should we build one out of.
After looking into it, I think etckeeper might be a bit overkill (for my use case, at least). While etckeeper hooks the update system to track changes between updates, I'm more interested in knowing the answer to the question "what is the difference between the current package maintainer's version, and the current version on my system?", at any point in time. In other words, "what has the user modified?". Currently, the only time that is easily answered is when an *.rpmnew file exists, because that's when I have a copy of the package maintainer's unmodified version to compare with. However, I'd like to be able to ask this of any system, at any time. I'm not sure a VCS really helps all that much.
After looking into it, I think etckeeper might be a bit overkill (for my use case, at least). While etckeeper hooks the update system to track changes between updates, I'm more interested in knowing the answer to the question "what is the difference between the current package maintainer's version, and the current version on my system?", at any point in time. In other words, "what has the user modified?". Currently, the only time that is easily answered is when an *.rpmnew file exists, because that's when I have a copy of the package maintainer's unmodified version to compare with. However, I'd like to be able to ask this of any system, at any time. I'm not sure a VCS really helps all that much.
99% of all users don't care and the yone who cares using a VCS for /etc
like "etckeeper" while i never ever would use that directly on
production servers but on a admin-server pull from the infrastrcuture
and fire etckepper there - works like a charme for many year
You're right, and I agree that most users don't care. This makes it hard to support/troubleshoot user's systems, when they've changed from the working defaults. I'm sure there's other use cases (I've seen some interesting ones in this thread), but my primary interest is having baked-in configuration management, when users don't do it themselves.
If users were good at configuration management, they'd keep a record of
everything they change, and this wouldn't be an
issue. I'm more concerned about asking the system the question about
what the user has edited, precisely because I want to support users who
aren't good at configuration management, and don't keep track of what
they've changed from the defaults. That's hard to do in Fedora... there
isn't even really a way to easily "reset Fedora to defaults" using
yum/dnf/rpm, because there isn't an easy way to retrieve the defaults.
That's essentially the core of this problem: how to easily retrieve the
(current) defaults.
*
disk space maybe cheap for some fire-and-forget machines, but not on
enterprise storage hosting hundrets of instances
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
