[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: /etc/ttys defaults, was Persistent green messages interrupting console on NetBSD 6.99.19 i386
On 2013-06-05 16:58, Greg Troxel wrote:
Johnny Billquist <bqt%update.uu.se@localhost> writes:
Just to once more point this out - etcupdate is not too aggressive. It
never overwrites anything, unless explicitly instructed to do so.
etcupdate is very interactive. It is not a batch tool. Any changes
suggested needs to be approved by the person running etcupdate.
In my view, etcupdate is the best tool I've encountered for the
job. However, it does require you to actually read, understand, and
act upon a lot of information. It is not a good tool for someone who
don't know what's in /etc, and it is not a good tool for the
impatient. But it will actually allow you to merge your local changes
with the changes introduced in the system distribution, in the way
that you actually want the end result to be, and skip parts that you
don't agree with.
For a clueful person updating one machine, I think your view has a lot
of merit. But for someone who is updating 50 machines, interactive
leads to annoyance which leads to overwriting files unintentionally.
And I thinks omeone who desn't know the gory details will also make
unintentional changes. My 'too aggressive' comment should have been
about the combination of etcupdate and real users.
Since etcupdate is interactive, it probably makes very little sense in a
scenario where you are going to update 50 machines.
But that is hardly a bug in etcupdate. It still is not buggy, or too
aggressive. But it's not the right tool for managing large number of
machines. If you just tell etcupdate to install from the reference for
every difference, then you are being too aggressive in your usage of
etcupdate (I think).
For clueless users, I'd be interested in hearing any solution to update
/etc that works well. That is a really hard problem...
I think that there really needs to be a default workflow that is not
interactive and has reasonable results. I think that requires storing
the previous pure etc.tgz contents to allow three-way merging, but
that's a small price to pay for reduced thinking. (My current approach
is to run etcmanage and then look at diffs.)
You are right. There needs to be a workflow for such situations. I don't
have one, and can't offer much help for that. Probably because I'm not
running large number of machines.
Main Index |
Thread Index |