[kepler-dev] Metacat and MyProxy Running on Roadrunner (fwd)

[Jing Tao]

Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

---------- Forwarded message ----------
Date: Thu, 18 Aug 2005 13:48:55 -0500
From: Bill Baker <bbaker at ncsa.uiuc.edu>
To: ltergrid at nsf-middleware.org
Subject: Re: Metacat and MyProxy Running on Roadrunner

To follow up on the questions raised in yesterday's conference call,

1. Incompatibility between GSI server-side connector and Tomcat 5.5:

Yes, what Terry said.  Some of the Tomcat classes that the connector depends on 
have been repackaged in 5.5, and so the connector can't link to them.  I 
suspect that it wouldn't be hard to update the connector, but I haven't tried.

2. Duplicate LDAP UIDs:

We configure OpenLDAP, which provides the PAM back end, to only look at one 
organizational unit, specifically "o=lter,dc=ecoinformatics,dc=org", within 
LTER's LDAP.  Within each organizational unit, the UIDs are unique.

Practically speaking, I don't know how we would manage multiple LDAP domains -- 
theoretically, I can think of a few alternatives, but they all have drawbacks.

     - Extend the PAM sequence to include organization in addition to UID
       Problem: MyProxy currently only supports username+password

     - Encode the organization name into the PAM username
       Problem: that's a lot for people to remember

At 09:21 2005-08-18, Von Welch wrote:

> Bill,
>
>  Thanks for the update. Questions and comment below.
> 
> On Aug 17, 2005, at 5:14 PM, Bill Baker wrote:
>>    - running under Tomcat 5.0.28 (Tomcat 5.5 is not compatible with
>> our
>>      GSI server-side connector)
> 
> What are the details of this incompatibility?
> 
>> MyProxy:
>>    - configured for LDAP PAM for password authentication
> 
> Following up on the conversation from yesterday, what happens today
> if we use a uid that is duplicated in LDAP?
> 
>> Questions:
>>    - Is there interest in running a CA on roadrunner, so that MyProxy
>>      can originate its own certificates?  They would require (simple)
>>      command-line initialization for each new user, but users wouldn't
>>      need NCSA credentials.  On the other hand, only grid resources
>>      that are configured to trust that CA will accept them.
>>      Such a CA could peacefully coexist with the current setup.
> 
> I don't see strong benefit for this in the scope of the demo.
> 
> Von
> 
>> -- Bill Baker
>> Visiting Research Programmer, NCSA
>>