On Mon, Apr 22, 2013 at 4:50 PM, Mark McCullough <mark.mc...@gmail.com>wrote:
>
> On 2013 Apr 22, at 16:36 , Brian Mathis wrote:
> > Say what you will about them, but Microsoft realized this was a problem
> with INI files a long time ago and migrated to the registry. You may
> scoff, and one could say that early *implementations* of the registry left
> something to be desired, but the *idea* of having a centrally managed
> config store with a standard API used by all programs is what allows them
> to completely dominate in the Enterprise market (and is what Puppet tries
> to achieve now). A lot of the complex things you do with Puppet are
> complete child's play with Group Policy.
>
> Yes, because the AIX configuration DB and the mandatory commands (smit,
> smitty, et al) behind them never break for anyone.
>
> And for every job that is trivial with group policy, there's another job
> that is hell with group policy and trivial with Unix's more freeform
> approach to configuration.
>
> At $oldjob, I worked on the Unix security team and talked regularly with
> the Windows security team. Almost every week, there was a problem that one
> side found trivial due to the underlying OS, and it changed regularly which
> side had the easier time. Some things, Windows had a great and clean
> answer, other things, Unix was far simpler.
>
> A DB/API isn't the only answer, and in some cases, believe it or not, it's
> the wrong answer.
>
> Mark McCullough
> mark.mc...@gmail.com
>
>
This is merely an implementation issue. What is Puppet, if not an attempt
to solve exactly the same problem (of a central repository), but by forcing
re-invention of the wheel for every dissimilar file format out of necessity?
Anyway, we're pretty far off topic here, so let me try to get back on it...
The issues of config management and version backups is not the same thing
that were originally raised. Revision control directly on the files allows
you to see exactly every change that has been made to a file. It's even
nicer when you get an email alert about changes and you can see the diffs
right there.
Version backups let you go back, but so does any kind of backup and it's
just not the same thing to have to proactively check if a file was updated
and see if you need to restore it. AIDE can help, but it still doesn't
give you a line-by-line comparison of what was changed, only that
*something* changed.
CM allows you to push out changes easily, but that is not the same thing as
seeing what happened after the fact on each server, which is what revision
control/etckeeper will get you. You might think it redundant, but it's
nice to see changes go full circle through:
CM release -> Apply to clients -> changes detected -> change alerts sent
Going through this process gives you more confidence that everything is
working correctly, and also provides a nice test of AIDE and anything else
you have watching the files, independent of the CM tool.
It might not be scalable if you have a huge number of servers (as everyone
is fond of pretending to have these days), but for many size installations,
it would work fine.
❧ Brian Mathis
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
