You lost me at LDAP. Then you lost me again when you said zeroconf. The distributed auth/registry I just somewhat glazed over. The whole argument here is that ssh is simple/easy as compared to xcpu2, and these kinds of things just make it worse. All large installations that I know of use passwd authentication with ssh keys to go passwordless. It takes a little less than 30 seconds to set up and it just plain works.
-JE On Tue, Nov 24, 2009 at 11:39 AM, Eric Van Hensbergen <[email protected]> wrote: > > On Tue, Nov 24, 2009 at 1:26 PM, ron minnich <[email protected]> wrote: >> >> On Tue, Nov 24, 2009 at 11:22 AM, Eric Van Hensbergen <[email protected]> >> wrote: >>> >>> but xcpu2 solves this problem - it can run any manner of scripts quite >>> handily. >> >> xcpu2 is the way forward. The remaining issues are getting it to be >> more familiar to sysadmins on setup, performance, and so on. But it's >> all doable. >> > > I think it would be useful to have some well defined requirements > here. What about it do sysadmins find difficult to configure? > > My experience is there are two things that one needs to know how to do: > > a) setup authentication > b) manage the machine list > > ssh gets around (a) by using LDAP or some other local auth. xcpu2 > could do something similar, but there are some folks that use xcpu2 > locally specifically because they don't have to get involved with an > outside userid/authentication mechanism > > ssh doesn't get around (b) either, but it does seem like it would be > nice to have some easier mechanism for maintaining this sort of > information. Something like zeroconf could help on a local network, > but many of the networks we deploy xcpu2 on are segmented. > > I guess (b) can be got around by using another workload management > system on top of xcpu/ssh which handles the management/monitoring of > physical resources. > > Something like a distributed registry with distributed auth could help > solve some of these problems, but you'll likely need to configure at > least one node per network segment with the right information (auth > server and registry server) and then everyone else could pick it up > with zero conf. Alternatively, you could point all nodes to a > hierarchical parent which would eventually fully connect a > hierarchical tree of nodes in a manner which the > auth/registry/monitoring information could be distributed. > > -eric >
