Hi All...
Thanks for the clarifications. Following Maarten suggestion, I've opened
the following GGUS ticket:
https://gus.fzk.de/ws/ticket_info.php?ticket=46736
Cheers
Goncalo
Maarten Litmaath wrote:
> 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...
>
|