sean finney on 10 Aug 2011 04:19:54 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] ClusterSSH & friends


On Wed, Aug 10, 2011 at 01:39:37AM -0400, Julien Vehent wrote:
> On Wed, 10 Aug 2011 01:35:27 -0400, JP Vossen wrote:
> >Last night at PLUG N we were talking about running the same command
> >on a bunch of servers.  Here is some follow-up for that.
> >
> >I was thinking of "multixterm", which seems to be part of the
> >expect-dev (possibly just expect on some distros), but the references
> >on the NIST site seem otherwise dead. [1]
> >
> >Then there is "Execute commands simultaneously on multiple servers
> >Using PSSH/Cluster SSH/Multixterm" [2] and "Parallel SSH execution
> >and
> >a single shell to control them all" [3].
> >
> >There's this non-Interactive one:
> >http://www.stearns.org/fanout/    Run non-interactive commands on
> >remote machines simultaneously
> >
> >And of course, CFEngine [4], Puppet [5] and chef [6] and a comparison
> >of a bunch of config management tools [7], but these are all more
> >heavy duty than the original topic.
> >
> >I haven't really used any of them, but from my brief survey, PSSH
> >sounds the most interesting since it includes (scriptable) pssh,
> >pscp,
> >prsync, and pnuke.  http://code.google.com/p/parallel-ssh/
> >
> >If anyone (Kevin?) dives into these, let us know how it works out.
> >
> I have not used pssh yet, it's in the todo list, but I have
> experimented a bit with classic SSH and SUDO to automate user
> creation on multiple servers.

So when you create one user, it goes out to multiple hosts to create
the same user/homedir locally on each of them?  That sounds like a pretty
bad starting design.  

I'm assuming there's some kind of limitation as to why you couldn't use
something like LDAP (or even NIS, yucky as it is), and that maybe you need
the users to be local for some reason... but even so, what if one of the
hosts is down, has a full disk, etc?  I see it as a pretty big risk to
keep the user lists consistant with such an approach, and it doesn't
scale very well either.

A better approach might be to have each server periodically poll a
reference server (or file), sync it over, and take whatever actions
are necessary to fix the missing accounts.  But then you're about 30%
of the way to having a configuration management system, and you might
as well consider something like cfengine or puppet, where this would
be one of the many, many ways your life was made easier :)

> It took me some time to deal with sudo asking for a password, but I
> reached a somewhat acceptable solution. By the way, if someone knows
> of an ssh-agent-like sudo agent, that could transport my sudo
> session from a machine to another, I'd love to hear about it.

how about just having a well-restricted NOPASSWD line in /etc/sudoers?

	%people_who_can_adduser	ALL=(ALL) /path/to/your/adduser/command

no need for extra complication if it's not entirely necessary...



	sean

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug