[Swift-devel] May need VOMS proxy for many OSG sites

[Michael Wilde]

Arjun, this may be the reason that your access to many OSG sites is failing.

Find a site that fails using grid-proxy-init from say teraport.
Then try that same site, using voms-proxy-init (sp?) on engage-login.

We'll both need to dig into the full meaning of a "VOMS" proxy, but basically it appends extra "role" information to the proxy to indicate that you are activing as a member of a specific VO (in your case, the "engage" VO).

I dont recall if we added that to Swift yet (I think not). Mihael, do you recal?

If not, you'll need to do more of the initial testing from engage-login until we instal; OSG clients.

- Mike

----- Forwarded Message -----
From: "Brian Bockelman" <bbockelm at cse.unl.edu>
To: "Robert Engel" <engel_r at ligo.caltech.edu>
Cc: "Keith Chadwick" <chadwick at fnal.gov>, "Iwona Sakrejda" <isakrejda at lbl.gov>, OSG-int at opensciencegrid.org, OSG-VO-FORUM at opensciencegrid.org, "Arvind Gopu" <agopu at indiana.edu>, "Rob Quick" <rquick at iupui.edu>
Sent: Thursday, June 17, 2010 2:44:16 AM GMT -06:00 US/Canada Central
Subject: Re: How to know if a site requires a VOMS Proxy or a Grid Proxy for authentication?


On Jun 17, 2010, at 12:39 AM, Robert Engel wrote:

> Keith,
> 
>   thanks for the link. But that is what I meant by manually knocking on each door. As an OSG user I want a simple way to find out what proxy to use on each of the potential 50+ resources there are.
> 

Use a VOMS proxy.  Didn't we just determine they are a superset of grid proxies?  Reading through the thread, I didn't see any site saying "I accept grid proxies but not VOMS proxies."

Ultimately, there are a million things that can go wrong in distributed computing (cosmic rays hitting fiber cables at FNAL).  Why concentrate on this one?  I'm not against having better probes or tests - but we have extremely limited effort.  I'd rather identify the areas where we need this the most.  

The only way to know if a site accepts your jobs are to submit jobs.  Why should we add central complexity instead of using auto-discovery (esp since the central view, whether MyOSG, BDII, etc, is always going to be wrong as they don't use your proxy)?

We are a decentralized, distributed computing facility.  You can't have centralized information that's "correct" if you have a decentralized computing system.

Brian

> I am thinking that myOSG could provide the required proxy information for each of the resources. Perhaps Arvind and Rob can comment on that.
> 
> Robert
> 
> 
> 
> Keith Chadwick wrote:
>> At 3:17 PM -0700 6/16/10, Robert Engel wrote:
>>> Hey Iwona,
>>> 
>>>   currently I recommend in the documentation to always check with the membership VO if they support VOMS and provide a VOMS server. Just as you said, the VOMS proxy in the end is just a 'fancy' grid proxy and can be used as such. I recommend using the VOMS Proxy under this circumstances.
>>> 
>>> On the other hand I would like users who can't generate a VOMS Proxy with extended attributes to know if a certain site requires such without having to 'knock on every door' manually? Like for instance at Fermilab where this is required. I only know it is required because I talked to Burt. Otherwise I would have no idea.
>> 
>> The requirement for voms proxies is explicitly published in the
>> FermiGrid policy document:
>> 
>>    http://fermigrid.fnal.gov/policy.html
>> 
>> Direct quote from the above document:
>> 
>>    VOs and VO members that desire to Fermilab grid resources must initialize
>>    their credentials using:
>> 
>>        * $VDT_LOCATION/voms/bin/voms-proxy-init
>> 
>>    Those VOs and VO members that fail to use voms-proxy-init may be blocked
>>    from accessing Fermilab grid resources.
>> 
>> -Keith.
>> 
>>> Thanks,
>>> Robert
>>> 
>>> Iwona Sakrejda wrote:
>>>> But even not all the sites that run GUMS servers requirer VOMS proxy.
>>>> 
>>>> So I'd say - if a proxy is rejected by a site, is the error message clear? I never tried....
>>>> 
>>>> Also the user should check with the VO. If a vo is utilizing functionality that comes with
>>>> a VOMS proxy, it will be presumably educating its users about available roles and such, no?
>>>> 
>>>> Always asking for a VOMS proxy is safer. If no VOMS server available - it will be reduced to
>>>> a regular proxy. If a site is using map files, the extra stuff will be ignored and the proxy will
>>>> work anyway.
>>>> 
>>>> Isn't it so?
>>>> 
>>>> Iwona
>>>> 
>>>> On Wed, Jun 16, 2010 at 2:57 PM, Robert Engel <engel_r at ligo.caltech.edu <mailto:engel_r at ligo.caltech.edu>> wrote:
>>>> 
>>>>    Steven,
>>>> 
>>>>    ? Do you know how a user could find out what RSV probes are
>>>>    running on any given site? I tried to find this in myOSG, but
>>>>    nothing turned up.
>>>> 
>>>>    Thanks,
>>>>    Robert
>>>> 
>>>> 
>>>>    Steven Timm wrote:
>>>> 
>>>>        The answer is not always a clear yes or no. ?If a site copies
>>>>        the OSG GUMS template and runs GUMS then they will end up
>>>>        requiring voms proxies for about half of the VO's and not
>>>>        for the other half.
>>>>        You could indirectly find out by which RSV probes any given site
>>>>        is running, GUMS sites run different RSV probes than grid-mapfile
>>>>        sites do. ?by default all grid-mapfile sites do not require
>>>>        any VOMS proxy.
>>>> 
>>>>        FermiGrid is the only site I know of that requires VOMS proxy for
>>>>        everyone and even we have a way to make exceptions if necessary.
>>>> 
>>>>        Steve
>>>> 
>>>> 
>>>>        On Wed, 16 Jun 2010, Robert Engel wrote:
>>>> 
>>>>            Hello,
>>>> 
>>>>            ?I am writing documentation for end users. I would like to
>>>>            write how a user can find out if a site accepts a Grid
>>>>            Proxy or requires a VOMS Proxy. Can that information be
>>>>            found in myOSG?
>>>> 
>>>>            Thanks,
>>>>            Robert
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> Attachment converted: Macintosh HD:engel_r 18.vcf (TEXT/ttxt) (0040AFA0)
>> 
>> 
> <engel_r.vcf>


-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory