Salut Re'mi,
> Hi Goncalo, Maarten,
>
>
>>>[...]
>>>
>>>2) This is my proxy-info:
>>>
>>>-bash-3.00$ voms-proxy-info --all
>>>subject : /C=PT/O=LIPCA/O=LIP/OU=Lisboa/CN=Goncalo Borges/CN=proxy
>>>issuer : /C=PT/O=LIPCA/O=LIP/OU=Lisboa/CN=Goncalo Borges
>>>identity : /C=PT/O=LIPCA/O=LIP/OU=Lisboa/CN=Goncalo Borges
>>>type : proxy
>>>strength : 1024 bits
>>>path : /tmp/x509up_u266
>>>timeleft : 11:24:29
>>>=== VO dteam extension information ===
>>>VO : dteam
>>>subject : /C=PT/O=LIPCA/O=LIP/OU=Lisboa/CN=Goncalo Borges
>>>issuer : /DC=ch/DC=cern/OU=computers/CN=voms.cern.ch
>>>attribute : /dteam/Role=NULL/Capability=NULL
>>>attribute : /dteam/swe/Role=NULL/Capability=NULL
>>>attribute : /dteam/swe/lip/Role=NULL/Capability=NULL
>>>timeleft : 11:24:29
>>>uri : voms.cern.ch:15004
>>>
>>>[...]
>>>
>>>4) I can perform an lcg-cr requesting VO SWETEST and registering the
>>>file on DTEAM catalogue (neither LFC or DPM complain about the incoherence):
>>>
>>
>>You can open a bug for that.
>>
>
>
> No need to open a bug, see explanations below...
I think a bug _does_ make sense, see below.
>>>-bash-3.00$ lcg-cr -v --vo swetest -d se05.lip.pt -l
>>>lfn:/grid/dteam/goncalo/teste3.txt file:/home/csys/goncalo/sleep.sh
>>>Using grid catalog type: lfc
>>>Using grid catalog : prod-lfc-shared-central.cern.ch
>>>Using LFN : /grid/dteam/goncalo/teste3.txt
>>>[BDII] ii02.lip.pt:2170: Warning, no GlueVOInfo information found about
>>>SE 'se05.lip.pt' (with no tag)
>>>SE type: SRMv1
>>>Using SURL :
>>>srm://se05.lip.pt/dpm/lip.pt/home/swetest/generated/2009-02-26/filefe631748-d9e5-458c-819f-30920e5371df
>>>Alias registered in Catalog: lfn:/grid/dteam/goncalo/teste3.txt
>>>SRM Request Token: 166071
>>>Source URL: file:/home/csys/goncalo/sleep.sh
>>>File size: 122
>>>VO name: swetest
>>>Destination specified: se05.lip.pt
>>>Destination URL for copy:
>>>gsiftp://se05.lip.pt/se05.lip.pt:/dpm1/dteam/2009-02-26/filefe631748-d9e5-458c-819f-30920e5371df.166071.0
>>># streams: 1
>>># set timeout to 0 seconds
>>> 122 bytes 0.13 KB/sec avg 0.13 KB/sec inst
>>>Transfer took 2030 ms
>>>Destination URL registered in Catalog:
>>>srm://se05.lip.pt/dpm/lip.pt/home/swetest/generated/2009-02-26/filefe631748-d9e5-458c-819f-30920e5371df
>>>guid:bbaa307f-3c10-4e82-abd1-c30936175e81
>>>
>>>QUESTION 1: I guess that this is only possible because the permissions
>>>are OK at the LFC level and DPM doesn't recognize that I'm running with
>>>the DTEAM extension... Is it really like this or do I have something
>>>incorrectly configured.
>>>
>>
>>LFC: the endpoint for dteam was used, either because the proxy has dteam
>>or because you set LFC_HOST; then you spelled out the LFN and your dteam
>>proxy can write there.
>>
>>DPM: the generated directory for "swetest" was looked up and it appears
>>that dteam can write there. Check with these commands:
>>
>> export DPNS_HOST=se05.lip.pt
>> dpns-ls -ld /dpm/lip.pt/home/swetest/generated/2009-02-26
>> dpns-getacl /dpm/lip.pt/home/swetest/generated/2009-02-26
>>
>
>
> There is no way from lcg-util to force a specific VO during the
> authentication/authorization process, remote services use either the
> VOMS extension in the proxy, or the gridmap file to determine what is
> the VO of users.
>
> The VO which is specified at command line is used for:
>
> - looking for corresponding information in BDII:
> * lfc endpoint
> * SE space area (used to generate SURLs)
>
> - generating LFNs
>
>
> If the used LFC endpoint is the one for dteam VO, it certainly means
> that LFC_HOST was defined to that host (BDII is used for getting LFC
> endpoint only of this variable is not defined).
>
> Therefore, both LFC and DPM authenticated you as a DTEAM member,
> according to your VOMS proxy.
> And you were able to write in swetest, because directory permissions
> allow that.
The lcg_util code could report a warning when the specified VO does not
correspond to the VO in the proxy...
|