We use puppet to manage all of our configs and systems, and keep our puppet configs in git. I'm a little depressed to hear you don't know anyone personally who does that.
I actually laid down the law and mandated that nothing go into production that isn't built by puppet (we FAI a minimal base system from "bare metal" then kick off puppet), and I wouldn't have it any other way. It's so much easier to manage systems that way. It's maybe 20% more work up front and 80% less down the road. :) Nicholas -- Sent via mobile. On Oct 3, 2012 11:22 PM, "Howard Bampton" <[email protected]> wrote: > On Wed, Oct 3, 2012 at 7:00 PM, Jesse Becker <[email protected]> wrote: > > On Wed, Oct 3, 2012 at 6:46 PM, Yves Dorfsman <[email protected]> wrote: > >> On 2012-10-03 16:16, Howard Bampton wrote: > >>> All my NIS maps were historically under RCS (periodically purged by > >>> hand), with a secondary repository of daily snaps kept in a second > >>> spot for disaster recovery/"how long has this defect been out there" > >>> purposes. I'll probably do something similar to the second style for > >>> my LDAP stuff some day (hard to tell when a field changed/got > >>> added/whatever). > >>> > >> > >> The sad part is that you consider this unorthodox. > >> RCS, mercurial, git, etc... are so cheap to use that there is > absolutely no > >> reason not to use them for NIS, DNS, ldif files etc... I mean unless you > >> hire those type of admins who never ever make even a single mistake. > >> > >> Personally I think any machine that needs any tweaking after a rebuild > >> should have /etc under VC. > >> > > > > To take it a step further: any machine should have its configuration > > management tool rules/promises/recipes under VC. Nothing on the > > machine should be modified directly. > > I've worked with people that did one or more of the following: > * hadn't goofed up badly enough that the "pain" of using some form of > backups of such files was less painful than redoing something from > memory/seat of the pants > * had goofed up, but used comments in various files to track changes > (nearly impossible to find the live content after a while and knowing > when the changes were made is problematic) > * used brute force and saved entire copies by wrapping "vi" (horribly > wasteful of space at a time when disks were in the <10 GB range and > large files change dozens of times a day)- history files got wiped > after a month or two as a result, but part of the lesson was learned. > * manually made backup copies with random naming schemes (for the same > file on the same host- hosts.YYYYMMDD, hosts.save, hosts.old, > hosts.older, holds.$username.<something>, ...) > * knew I did something on the sly for select things, and came to me > when things broke > * hadn't done so...yet. > > I can't say any of the people I have worked with or know personally > have ever done something to manage OS configs on an ongoing basis via > chef/puppet/other-free-alternative/$$$$ome-commercial-product/something > homebrewed. The closest I've seen was a solid Jumpstart setup and a > nearly as good Kickstart one. > > Clearly such shops exist, just not at the handful of larger employers > (or subsets of their infrastructure) I know about first or second > hand. > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
