something like cfengine or puppet.
At this point, when I want to run something across my cluster, to
install users or do something else, I use a pyexpect script I wrote.
It creates a deliverable (typically either archives a directory,
or a single script) SSH's to the machine (possibly SSH'ing through
intermediaries first), then SCP's back to the starting machine to get
the deliverable. It then extractes the package (if it was packaged)
and runs the script, compiling the stdout to a report on the starting
machine.
It is based on principles I used back in my youth running tests across
the machines in a Quality Assurance lab.
This sort of approach is great for running one-off scripts everywhere.
(This made it easy to check how my machines would handle the DST
changes. It also make it easy for me to find which other machines
had Maxtor drives, when I had two of them fail in relatively quick
succession recently.)
My script to create accounts simply checks the hostname and does
different things based upon where it is run.
If you decide on something like Puppet or cfengine, both have a lot of
activity around them. Puppet is based on Ruby, which can be a plus or
minus depending on your feelings for the language. However, it leverages
more standard components than cfengine.
If my script or something derived from my script sounds more
appealing to you, let me know and we can talk offline about it. I've
implimented solutions like this in both (TCL-based) Expect, as well as
(Python-based) Pexpect.
I must note, though, that I personally plan to migrate to something
like cfengine or Puppet in the future. (Currently, I'm leaning toward
cfengine due to a philosophical disagreement with some of the Ruby
folks.)
Cheers,
Steven Black
On Wed, Mar 19, 2008 at 12:49:33PM +0000, Mark Krenz wrote:
>
> I'm curious if anyone out there has something special that they use
> for passing jobs between machines. Say if you want to run a program on
> machine A to create a user and then it submits jobs on machine B, C and
> D to create the user's mailbox, website, etc., which may be on different
> machines.
>
> Does anyone here do anything like that? I'd be very interested to
> know so that I don't re-invent the wheel.
>
> When I worked at Kiva, we had a great system written by Matt Liggett
> called Mcfeely that was a job queuing system for passing jobs over ssh
> tunnels. Then we had a set of perl modules called Kiva::User written by
> Adrian Hosey and Chris Dent that allowed us to do sophisticated creation
> and transform operations on users. It was really quite remarkable, but
> now its a bit antiquated and unmaintained. When it was written (~1999)
> we couldn't find anything that did the same and I've still never seen
> anything like it. I've been needing to do this stuff on Suso for the
> past few years, but Mcfeely no longer compiles under new gcc/glibc
> versions. However, I'm not sure that Mcfeely is really needed. Jobs
> could be passed directly over an ssh session or through a queuing
> system, but its more up to the implementer. Kinda like whether you want
> to run postfix or just SSMTP. They both still implement SMTP, but they
> have different goals.
>
> So I'm thinking of writing my own job submission/communication suite
> that is not so much a set of programs as it would be a set of standards
> for using an XML DTD to submit jobs information and guidelines for
> security such as authenticating the sender, signing requests and
> responses. After a trial phase I'm willing to release this stuff as
> open source. I was thinking of calling it Newman (Mcfeely was named
> after the famous mailman on Three's Company).
>
> Anyone have any input?
>
>
> --
> Mark Krenz
> Bloomington Linux Users Group
> http://www.bloomingtonlinux.org/
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
No comments:
Post a Comment