Over the years, I've built up a lot of shell scripts for provisioning and configuration - which makes converting to something like chef or puppet a somewhat daunting task (or even something like FAI).
I'm also a big fan of composing tool chains from piece parts - scripts linked by pipes, mashups of functions accessed via RESTful APIs, etc.
Rundeck looks pretty interesting - given that it can manage shell scripts and their execution via ssh. I'm sort of wondering what other kinds of tools people are using for adding a job and configuration control overlay to shell scripts. And what about orchestration tools that that take a "mashup maker" approach? Pointers, thoughts, ....
Thanks,
Miles Fidelman
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
we've all been there and we have all tried to shoehorn our shell scripts into a modular system. Spare yourself the pain, it's a losing game. You have to bite the bullet and learn a configuration management system, be it cfengine, puppet, chef, or foobarbaz
It may seem daunting but let me tell you it is absolutely worth the effort
> Over the years, I've built up a lot of shell scripts for provisioning and > configuration - which makes converting to something like chef or puppet a > somewhat daunting task (or even something like FAI).
> I'm also a big fan of composing tool chains from piece parts - scripts > linked by pipes, mashups of functions accessed via RESTful APIs, etc.
> Rundeck looks pretty interesting - given that it can manage shell scripts > and their execution via ssh. I'm sort of wondering what other kinds of > tools people are using for adding a job and configuration control overlay > to shell scripts. And what about orchestration tools that that take a > "mashup maker" approach? Pointers, thoughts, ....
> Thanks,
> Miles Fidelman
> -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra
<mfidel...@meetinghouse.net> wrote: > Over the years, I've built up a lot of shell scripts for provisioning and > configuration - which makes converting to something like chef or puppet a > somewhat daunting task (or even something like FAI).
> I'm also a big fan of composing tool chains from piece parts - scripts > linked by pipes, mashups of functions accessed via RESTful APIs, etc.
> Rundeck looks pretty interesting - given that it can manage shell scripts > and their execution via ssh. I'm sort of wondering what other kinds of > tools people are using for adding a job and configuration control overlay to > shell scripts. And what about orchestration tools that that take a "mashup > maker" approach? Pointers, thoughts, ....
Are you looking for a script organization tool, or a one-to-many execution tool?
I'm a fan of using Rakefiles to organize a bunch of one- or few- liner scripts into a namespaced whole. I generally wrap these with small boilerplate shell script that makes them filesystem location independent and allows me to pass variables in as required. I keep these in git, for replication/backup.
You also get the full power of ruby so it's a good gateway drug to other systems...
> On Sun, Mar 18, 2012 at 7:03 AM, Miles Fidelman > <mfidel...@meetinghouse.net> wrote: >> Over the years, I've built up a lot of shell scripts for provisioning and >> configuration - which makes converting to something like chef or puppet a >> somewhat daunting task (or even something like FAI).
>> I'm also a big fan of composing tool chains from piece parts - scripts >> linked by pipes, mashups of functions accessed via RESTful APIs, etc.
>> Rundeck looks pretty interesting - given that it can manage shell scripts >> and their execution via ssh. I'm sort of wondering what other kinds of >> tools people are using for adding a job and configuration control overlay to >> shell scripts. And what about orchestration tools that that take a "mashup >> maker" approach? Pointers, thoughts, ....
> Are you looking for a script organization tool, or a one-to-many > execution tool?
> I'm a fan of using Rakefiles to organize a bunch of one- or few- liner > scripts into a namespaced whole. I generally wrap these with small > boilerplate shell script that makes them filesystem location > independent and allows me to pass variables in as required. I keep > these in git, for replication/backup.
> You also get the full power of ruby so it's a good gateway drug to > other systems…
I'd echo Bryan with regards the worth of looking at the (sometimes large and potentially intimidating) configuration management tools.
On the other hand I do think there is a place for more adhoc script execution things, especially in smaller but still dynamic environments and mainly for asking questions of the systems. I've used Fabric (http://fabfile.org/) successfully here, partly because it provides the framework for managing hosts and roles and doing parallel execution, and the arguments can just be shell scripts. Once it's setup anyone who's happy with bash can easily jump in, and it's a good way of collecting useful one-liners. Past a certain number of hosts something like mcollective or salt are probably more useful, they use (different) message brokers to avoid problems with lots of ssh sessions.
+1 for fabric, its an awesome adhoc scripting tool
that said, I rarely reach for it as knife scripts are even easier to write w/ the knife exec sub-command.
Does puppet has something like knife exec?
My $0.02, it is worth diving into puppet/chef/foobarbaz and later filling in the gaps w/ fabric/capistrano/mcollective. However, fabric and capistrano have much lower learning curves. I just found that I had written fabfiles that would have been easier to implement (and idempotent) w/ chef recipes.
On Sun, Mar 18, 2012 at 5:10 PM, gareth rushgrove <
gareth.rushgr...@gmail.com> wrote: > On 18 March 2012 15:03, Zack Williams <zdw...@gmail.com> wrote: > > On Sun, Mar 18, 2012 at 7:03 AM, Miles Fidelman > > <mfidel...@meetinghouse.net> wrote: > >> Over the years, I've built up a lot of shell scripts for provisioning > and > >> configuration - which makes converting to something like chef or puppet > a > >> somewhat daunting task (or even something like FAI).
> >> I'm also a big fan of composing tool chains from piece parts - scripts > >> linked by pipes, mashups of functions accessed via RESTful APIs, etc.
> >> Rundeck looks pretty interesting - given that it can manage shell > scripts > >> and their execution via ssh. I'm sort of wondering what other kinds of > >> tools people are using for adding a job and configuration control > overlay to > >> shell scripts. And what about orchestration tools that that take a > "mashup > >> maker" approach? Pointers, thoughts, ....
> > Are you looking for a script organization tool, or a one-to-many > > execution tool?
> > I'm a fan of using Rakefiles to organize a bunch of one- or few- liner > > scripts into a namespaced whole. I generally wrap these with small > > boilerplate shell script that makes them filesystem location > > independent and allows me to pass variables in as required. I keep > > these in git, for replication/backup.
> > You also get the full power of ruby so it's a good gateway drug to > > other systems…
> I'd echo Bryan with regards the worth of looking at the (sometimes > large and potentially intimidating) configuration management tools.
> On the other hand I do think there is a place for more adhoc script > execution things, especially in smaller but still dynamic environments > and mainly for asking questions of the systems. I've used Fabric > (http://fabfile.org/) successfully here, partly because it provides > the framework for managing hosts and roles and doing parallel > execution, and the arguments can just be shell scripts. Once it's > setup anyone who's happy with bash can easily jump in, and it's a good > way of collecting useful one-liners. Past a certain number of hosts > something like mcollective or salt are probably more useful, they use > (different) message brokers to avoid problems with lots of ssh > sessions.
> we've all been there and we have all tried to shoehorn our shell > scripts into a modular system. Spare yourself the pain, it's a losing > game. You have to bite the bullet and learn a configuration management > system, be it cfengine, puppet, chef, or foobarbaz
> It may seem daunting but let me tell you it is absolutely worth the effort
Well you've obviously drunk the koolaid :-)
But that's not the problem I'm trying to address. As far as I can tell, pretty much any configuration management system is only one part of a toolchain - and right now, I don't see any complete toolchains, many of the tools seem don't seem to compose very well (e.g., point me at something that ties together provisioning with IP address management with DNS record management), and a lot of pieces seem to be distribution specific (e.g., FIA for debian, kickstarter for redhat-like distros).
Re. configuration tools specifically: I don't find chef, or puppet, or bcg2, or cfengine recipes/rules all that clearer or more powerful than a shell script, or perhaps a tcl script with expect statements - while I find the restrictions associated with picking one of these something I'm not ready to do.
Hence my interest in something like rundeck, that lets you manage and compose scripts, AND configurations stored in other systems.
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
Zack Williams wrote: > On Sun, Mar 18, 2012 at 7:03 AM, Miles Fidelman > <mfidel...@meetinghouse.net> wrote: >> Over the years, I've built up a lot of shell scripts for provisioning and >> configuration - which makes converting to something like chef or puppet a >> somewhat daunting task (or even something like FAI).
>> I'm also a big fan of composing tool chains from piece parts - scripts >> linked by pipes, mashups of functions accessed via RESTful APIs, etc.
>> Rundeck looks pretty interesting - given that it can manage shell scripts >> and their execution via ssh. I'm sort of wondering what other kinds of >> tools people are using for adding a job and configuration control overlay to >> shell scripts. And what about orchestration tools that that take a "mashup >> maker" approach? Pointers, thoughts, .... > Are you looking for a script organization tool, or a one-to-many > execution tool?
> I'm a fan of using Rakefiles to organize a bunch of one- or few- liner > scripts into a namespaced whole. I generally wrap these with small > boilerplate shell script that makes them filesystem location > independent and allows me to pass variables in as required. I keep > these in git, for replication/backup.
> You also get the full power of ruby so it's a good gateway drug to > other systems...
Rake looks pretty interesting. Not sure I want to bit off ruby (doing most of our development in Erlang and JavaScript at the moment), but it does seem to do some useful things.
Any thoughts on Rake vs. tcl/tk?
Thanks!
Miles
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
tcl is a full blown scripting language (with tk being the ui part), you can compare it against ruby. While rake is a ruby library that gives nice wrapper around shell , introduces a notion of task and let you establish dependencies among tasks. Its like a build tool. consider it analogous of make or ant
On Sun, Mar 18, 2012 at 11:32 PM, Miles Fidelman <mfidel...@meetinghouse.net
>> On Sun, Mar 18, 2012 at 7:03 AM, Miles Fidelman >> <mfidel...@meetinghouse.net> wrote:
>>> Over the years, I've built up a lot of shell scripts for provisioning and >>> configuration - which makes converting to something like chef or puppet a >>> somewhat daunting task (or even something like FAI).
>>> I'm also a big fan of composing tool chains from piece parts - scripts >>> linked by pipes, mashups of functions accessed via RESTful APIs, etc.
>>> Rundeck looks pretty interesting - given that it can manage shell scripts >>> and their execution via ssh. I'm sort of wondering what other kinds of >>> tools people are using for adding a job and configuration control >>> overlay to >>> shell scripts. And what about orchestration tools that that take a >>> "mashup >>> maker" approach? Pointers, thoughts, ....
>> Are you looking for a script organization tool, or a one-to-many >> execution tool?
>> I'm a fan of using Rakefiles to organize a bunch of one- or few- liner >> scripts into a namespaced whole. I generally wrap these with small >> boilerplate shell script that makes them filesystem location >> independent and allows me to pass variables in as required. I keep >> these in git, for replication/backup.
>> You also get the full power of ruby so it's a good gateway drug to >> other systems...
> Rake looks pretty interesting. Not sure I want to bit off ruby (doing > most of our development in Erlang and JavaScript at the moment), but it > does seem to do some useful things.
> Any thoughts on Rake vs. tcl/tk?
> Thanks!
> Miles
> -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra
Zack Williams wrote: > On Sun, Mar 18, 2012 at 7:03 AM, Miles Fidelman > <mfidel...@meetinghouse.net> wrote: >> Over the years, I've built up a lot of shell scripts for provisioning and >> configuration - which makes converting to something like chef or puppet a >> somewhat daunting task (or even something like FAI).
>> I'm also a big fan of composing tool chains from piece parts - scripts >> linked by pipes, mashups of functions accessed via RESTful APIs, etc.
>> Rundeck looks pretty interesting - given that it can manage shell scripts >> and their execution via ssh. I'm sort of wondering what other kinds of >> tools people are using for adding a job and configuration control overlay to >> shell scripts. And what about orchestration tools that that take a "mashup >> maker" approach? Pointers, thoughts, .... > Are you looking for a script organization tool, or a one-to-many > execution tool?
(realized I just jumped past this, right to your suggestion that I look at Rakefiles)
Both, but more focused on organization. An ideal tool would: - provide for editing/managing/versioning scripts (script = anything that can be invoked at the command line) - a library of control functions for use within scripts - invoking scripts, combinations of scripts, pipelines of scripts (in the Unix sense of pipes) - locally, remotely, across multiple machines - remote script execution via ssh, rather than some kind of agent - providing a simple database for keeping track of variables used by scripts (e.g., IP addresses, DNS records for use by a provisioning script) - that can be accessed from scripts - accessing the above via cli, RESTful API, GUI - cross-platform - (nice-to-have) minimal environmental requirements (i.e., a step above the unix shell, say the gnu buildtool suite rather than the JVM + a mass of libraries, or the ruby ecosystem -- a self-configuring basic environment would be nice, like perl+cpan)
I'm sure we've each cobbled something together along these lines - be it through manual processes, standard installs, or something fancier. I'm kind of wondering what different people have done, what pieces fit together better than others, what's available that's more integrated but that doesn't create a monolithic environment.
Rundeck seems to do most (all?) of this, running on Java. It looks nice, but it's also really new.
tcl/tk provides a lot of this - but without the organizing functions (tcl/tk + git, or maybe a tcl/tk IDE perhaps?)
I'm basically wondering what else might be out there - perhaps less visible - newer than tcl/tk, more mature than Rundeck perhaps. Essentially doing some research before provisioning several new machines and a bunch of VMs (easy enough to do from manual checklists, but I'm setting the stage for some future scaling).
Miles
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
>> On Sun, Mar 18, 2012 at 7:03 AM, Miles Fidelman >> <mfidel...@meetinghouse.net> wrote:
>>> Over the years, I've built up a lot of shell scripts for provisioning and >>> configuration - which makes converting to something like chef or puppet a >>> somewhat daunting task (or even something like FAI).
>>> I'm also a big fan of composing tool chains from piece parts - scripts >>> linked by pipes, mashups of functions accessed via RESTful APIs, etc.
>>> Rundeck looks pretty interesting - given that it can manage shell scripts >>> and their execution via ssh. I'm sort of wondering what other kinds of >>> tools people are using for adding a job and configuration control >>> overlay to >>> shell scripts. And what about orchestration tools that that take a >>> "mashup >>> maker" approach? Pointers, thoughts, ....
>> Are you looking for a script organization tool, or a one-to-many >> execution tool?
> (realized I just jumped past this, right to your suggestion that I look at > Rakefiles)
> Both, but more focused on organization. An ideal tool would: > - provide for editing/managing/versioning scripts (script = anything that > can be invoked at the command line) > - a library of control functions for use within scripts > - invoking scripts, combinations of scripts, pipelines of scripts (in the > Unix sense of pipes) - locally, remotely, across multiple machines > - remote script execution via ssh, rather than some kind of agent > - providing a simple database for keeping track of variables used by > scripts (e.g., IP addresses, DNS records for use by a provisioning script) > - that can be accessed from scripts > - accessing the above via cli, RESTful API, GUI > - cross-platform > - (nice-to-have) minimal environmental requirements (i.e., a step above > the unix shell, say the gnu buildtool suite rather than the JVM + a mass of > libraries, or the ruby ecosystem -- a self-configuring basic environment > would be nice, like perl+cpan)
> I'm sure we've each cobbled something together along these lines - be it > through manual processes, standard installs, or something fancier. I'm > kind of wondering what different people have done, what pieces fit together > better than others, what's available that's more integrated but that > doesn't create a monolithic environment.
> Rundeck seems to do most (all?) of this, running on Java. It looks nice, > but it's also really new.
> tcl/tk provides a lot of this - but without the organizing functions > (tcl/tk + git, or maybe a tcl/tk IDE perhaps?)
> I'm basically wondering what else might be out there - perhaps less > visible - newer than tcl/tk, more mature than Rundeck perhaps. Essentially > doing some research before provisioning several new machines and a bunch of > VMs (easy enough to do from manual checklists, but I'm setting the stage > for some future scaling).
> Miles
> -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra
> Is this a joke thread? Still not quite gotten the hang of American > sarcasm.
Why would you think that?
and later, AJ Christensen wrote:
> The clojure 'pallet' tool (cm) has some of these principles.
seems interesting, if a little java and cloud centric
> I've seen sloppy admins compose and reuse Bash snippets with Chef all > the time. Easy trap for beginners.
Please elaborate --- are you saying that composing bash snippets is a trap, or using Chef to do it is a trap? (If the former, who are you calling a beginner? If the latter, I agree - not what Chef is built for, and not the tool I'd use for managing shell scripts - hence my query.)
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
On Sunday, March 18, 2012 7:03:52 AM UTC-7, Miles Fidelman wrote:
> Over the years, I've built up a lot of shell scripts for provisioning > and configuration - which makes converting to something like chef or > puppet a somewhat daunting task (or even something like FAI).
> I'm also a big fan of composing tool chains from piece parts - scripts > linked by pipes, mashups of functions accessed via RESTful APIs, etc.
> Rundeck looks pretty interesting - given that it can manage shell > scripts and their execution via ssh. I'm sort of wondering what other > kinds of tools people are using for adding a job and configuration > control overlay to shell scripts. And what about orchestration tools > that that take a "mashup maker" approach? Pointers, thoughts, ....
> If your looking for a middle-ground that you can force as you will > you might find SM appealing https://bdsm.beginrescueend.com/
Two people have pointed at this, now, and the description sure sounds interesting. Anybody know how active the project is - there doesn't seem to be a mailing list or FAQ, and it seems to have one primary developer.
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
On Sunday, March 18, 2012 4:27:15 PM UTC-7, Miles Fidelman wrote:
> Scott Likens wrote:
> > If your looking for a middle-ground that you can force as you will > > you might find SM appealing https://bdsm.beginrescueend.com/
> Two people have pointed at this, now, and the description sure sounds > interesting. Anybody know how active the project is - there doesn't > seem to be a mailing list or FAQ, and it seems to have one primary > developer.
> -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra
> Over the years, I've built up a lot of shell scripts for provisioning > and configuration - which makes converting to something like chef or > puppet a somewhat daunting task (or even something like FAI).
Excuse me, I'm going to go for the utterly blunt response:
So what..? I know as a sysadmin we try our best to be "appropriately lazy", but that means evaluating the benefits too compared to the work put in. The positives of a config management system outweigh the negatives by a big enough margin to make any desire not to implement it border on pure laziness, not appropriate laziness. Just being daunted by it is not a good enough excuse.
Yes, it's a pain in the ass trying to move from what is for you a smooth working set of scripts, but you gain a system that works easily, /and /that's going to be both understandable and enhanceable by anyone else that comes along after you (or should you be 'run over by a bus'.)*
No one is requiring you to convert the entire thing on one go. I've a long way to go with the infrastructure I've inherited (an absolute mess of scripts and inconsistencies), but I've already got implemented a recipes in Chef that handle all the baseline common stuff, e.g. applications that should be on all (ntp etc), their configuration and so on, and am slowly adding more complex aspects of it. Yes it's a pain in the arse, but it's important. Just like all those niggling security requirements are a pain in the arse but you wouldn't be seen dead not implementing them.
Paul
* Every time I've gone into a sysadmin job, or picked up consulting work, I've found I've inherited a bunch of unusual bash and perl scripts, undocumented, inconsistent and bizarre in methodology (ever notice how no two sysadmins write perl / bash scripts alike?). It means it takes a stupid amount of time to piece things together and understand quite how they interact. Every time something breaks or goes wrong I'm left playing guessing games and tracking down whether it's a fringe case from some obscure aspect of a script or quite what (side note, it's amazing just how many problems I fix by enabling 'use strict; use warnings' and clearing up errors reported).
I do know Wayne, and he's usually very responsive to input, but I think he prefers IRC, which is probably why he hasn't set up a mailing list for this yet (they suck up valuable coding time, right?). Dunno how far-baked BDSM is or if you should bet the farm on it, but Wayne wrote RVM, which is a widely used project in the Ruby community (written in shell script), and has actively maintained that for years now.
If the lack of a mailing list really bothers you, open a github issue asking for one ;)
Paul Graydon wrote: > On 3/18/2012 4:03 AM, Miles Fidelman wrote: >> Over the years, I've built up a lot of shell scripts for provisioning >> and configuration - which makes converting to something like chef or >> puppet a somewhat daunting task (or even something like FAI).
> Excuse me, I'm going to go for the utterly blunt response:
> So what..? I know as a sysadmin we try our best to be "appropriately > lazy", but that means evaluating the benefits too compared to the work > put in. The positives of a config management system outweigh the > negatives by a big enough margin to make any desire not to implement > it border on pure laziness, not appropriate laziness. Just being > daunted by it is not a good enough excuse.
> Yes, it's a pain in the ass trying to move from what is for you a > smooth working set of scripts, but you gain a system that works > easily, /and /that's going to be both understandable and enhanceable > by anyone else that comes along after you (or should you be 'run over > by a bus'.)*
Pardon me for being blunt as well, then. I don't see a particularly high return on investment for investing time in converting to a tool (be it puppet, chef, cfengine, or what have you) that addresses only a small piece of an overall operations toolchain. I'd rather invest time and effort in getting my existing toolchain more automated, documented, and under configuration control.
> * Every time I've gone into a sysadmin job, or picked up consulting > work, I've found I've inherited a bunch of unusual bash and perl > scripts, undocumented, inconsistent and bizarre in methodology (ever > notice how no two sysadmins write perl / bash scripts alike?). It > means it takes a stupid amount of time to piece things together and > understand quite how they interact. Every time something breaks or > goes wrong I'm left playing guessing games and tracking down whether > it's a fringe case from some obscure aspect of a script or quite what > (side note, it's amazing just how many problems I fix by enabling 'use > strict; use warnings' and clearing up errors reported).
You ever notice that no two systems are alike?
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
Chad Woolley wrote: > On Sun, Mar 18, 2012 at 6:01 PM, Miles Fidelman > <mfidel...@meetinghouse.net> wrote: >> Scott Likens wrote: >>> Miles,
>>> It has 2 or 3 active developers to the best of my knowledge. As far as >>> the mailing list... See This response >>> <https://bdsm.beginrescueend.com/development/list> >> You mean this one?
>> "None yet, stay tuned I might setup a librelist."
>> That's what makes me wonder.
>> Miles > It's active on GitHub, and you can submit issues and pull requests > there (they accepted one 12 days ago):
> I do know Wayne, and he's usually very responsive to input, but I > think he prefers IRC, which is probably why he hasn't set up a mailing > list for this yet (they suck up valuable coding time, right?). Dunno > how far-baked BDSM is or if you should bet the farm on it, but Wayne > wrote RVM, which is a widely used project in the Ruby community > (written in shell script), and has actively maintained that for years > now.
> If the lack of a mailing list really bothers you, open a github issue > asking for one ;)
I just sent Wayne an email. Main thing about presence/absence of a list is as a way to build a user/developer community around a project.
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
> Chad Woolley wrote: >> On Sun, Mar 18, 2012 at 6:01 PM, Miles Fidelman >> <mfidel...@meetinghouse.net> wrote: >>> Scott Likens wrote: >>>> Miles,
>>>> It has 2 or 3 active developers to the best of my knowledge. As far as >>>> the mailing list... See This response >>>> <https://bdsm.beginrescueend.com/development/list> >>> You mean this one?
>>> "None yet, stay tuned I might setup a librelist."
>>> That's what makes me wonder.
>>> Miles >> It's active on GitHub, and you can submit issues and pull requests >> there (they accepted one 12 days ago):
>> I do know Wayne, and he's usually very responsive to input, but I >> think he prefers IRC, which is probably why he hasn't set up a mailing >> list for this yet (they suck up valuable coding time, right?). Dunno >> how far-baked BDSM is or if you should bet the farm on it, but Wayne >> wrote RVM, which is a widely used project in the Ruby community >> (written in shell script), and has actively maintained that for years >> now.
>> If the lack of a mailing list really bothers you, open a github issue >> asking for one ;)
> I just sent Wayne an email. Main thing about presence/absence of a list is as a way to build a user/developer community around a project.
> -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra
<mfidel...@meetinghouse.net> wrote: > Pardon me for being blunt as well, then. I don't see a particularly high > return on investment for investing time in converting to a tool (be it > puppet, chef, cfengine, or what have you) that addresses only a small piece > of an overall operations toolchain. I'd rather invest time and effort in > getting my existing toolchain more automated, documented, and under > configuration control.
The tool you are looking for does not and probably will never exist. You said yourself very early on that you like the unix way. CM is a smaller part of a bigger picture and the tools that you specifically mentioned address configuration management solely right now. Some of them have compliments and more tightly integrated add-on (i.e. mcollective) but you'll find that most of the tools around address one specific problem and do it very well.
> You ever notice that no two systems are alike?
Congrats. I figured it would get to this point. You've just described why you need proper configuration management:
Puppet -
package { "screen": ensure => "installed" }
Chef -
package "screen" do action :install end
Guess what. That works the same across all distros. Doesn't matter if those systems are alike. But here's the real crux of the matter: the point of configuration management is not to make your special snowflake systems behave the same. It's to make sure you don't have special snowflake systems. Systems are cattle...pets. They aren't artisan crafted, flame broiled, freshly brewed works of art.
I'm very sorry if you haven't gotten a very good welcome to the list. However, while we may not have a good definition of what devops *IS*, most people here feel that encouraging a pattern of brittle, busted-ass inflexible and ultimately unscalable shell scripts is wrong and downright irresponsible.
Even more telling is the fact that the questions you're asking are the first sign that you've grown beyond those shell scripts.
SM (nee BDSM) is probably up your alley. Wayne is a solid guy and he wrote SM mainly out of frustration with a poorly implemented Chef setup. While I wouldn't suggest it for the reasons I listed above, Wayne takes his community and his code seriously. Kudos if SM gets you further along your journey but at some point, you are (and I would argue already have) reached the limits of your shell addiction.
