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...
>> -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.
I hope it is clear enough.
Cheers,
Remi.
|