sean finney on 10 Aug 2011 07:48:09 -0700

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

Re: [PLUG] ClusterSSH & friends

Hi Julien,

On Wed, Aug 10, 2011 at 09:17:58AM -0400, Julien Vehent wrote:
> On Wed, 10 Aug 2011 13:22:01 +0200, sean finney wrote:
> 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.

right, but you have the same potential issue of do $x on all machines,
when all machines may not be up, or $x may not succeed, or behave slightly
differently based on the OS flavor or environment conditions, etc.

As a one-off task it's not unreasonable do have some kinda parallel
ssh helper (or even a for loop in bash), but as time goes on it may
be less exceptional and more commonplace that you need to do tasks
like this (syncing files, running commands, checking disks/mountpoints,
etc).  In which case, the likelihood of something getting missed is
a bit more significant.

> 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.

Picking out a few points here:

 * I'm not convinced that a "sudo-agent" would be any more secure than
   just granting a blanket ALL=(ALL) NOPASSWD: ALL rule.  In fact I
   would assume the opposite, that it'd be a significant security hole.
 * you might be able to do some trickery via PAM, using kerberos or something
   like libpam-ssh, though i'm not sure it's worth the effort.
 * you could also just bypass sudo and use ssh keys for root on the remotes,
   though sudo has the benefit of a little extra accounting of who's doing
 * for a more aesthetically pleasing sudoers file, i'd suggest listing
   them under a command alias and then having a single NOPASSWD line.
   Though i would only do this for regular/automated type commands and
   not one-off jobs.

> 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.

Which would make me suggest once more looking at some kinda CM service
like cfengine/puppet.   Well, maybe not if it were going to be for only
a dozen servers (that's about my personal threshold for the cost/benefit
formula whether to do so), but if it's going to go anything beyond that
then yes.

These types of systems usually require some up-front time with getting
them installed and configured, and of course the self-education of
figuring out how the damned things work, but once you have them in place
it's pretty nice to have.  Put in a new directive/promise, test it on
one system, and then go do something else whiel the other machines will
eventually catch up.

> 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 :)

Yeah, kinda a borderline area whether a CM system is worth it or not
(I'd personally go for it, but I've already gotten over most of that 
inertia threshold) But otherwise, why not just give yourself NOPASSWD:
ALL and be done with it?


Philadelphia Linux Users Group         --
Announcements -
General Discussion  --