Those are implementation specifics that the user/admin can be largely
unaware of. It would be quite trivial to assume the same environment
as .ssh (system-level password authentication and/or key-files on a
shared file system).
The unfortunate side of that is it requires shared distributed file
system or shared auth mechanisms be present which mean you require
something more than the drone systems we currently deploy with xcpu2
which are much easier to manage.
However, that being said, there is no reason (that I can see) why
xcpu2 couldn't support both sorts of environments.
-eric
On Tue, Nov 24, 2009 at 2:05 PM, Josh England <[email protected]> wrote:
>
> 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
>>
>
