Julien Vehent on 10 Aug 2011 06:18:14 -0700


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

Re: [PLUG] ClusterSSH & friends 

On Wed, 10 Aug 2011 13:22:01 +0200, sean finney wrote:

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 :)
Creating a user was just an excuse to experiment with the script. I don't need many users on those server, just 4 or 5, and I needed to add one, so I scripted it for the fun. 


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...
That's fine for recurring tasks, but what if you want to launch any root command in a secure manner on your entire environment ? I cannot list in advance what type of command I will have to launch, and I do not want a list of 50 commands with NOPASSWD. Yet again, creating a user was just for the experiment. Most likely, I will have to edit files on all of those servers at once more than creating users.
For now, the env is still small (9+ servers) but it might grow passed 30 at some point. It's far from Google's size, but it's an interesting intellectual challenge :) 



Julien

___________________________________________________________________________
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