ok, I found a little issue with parameters (it seems the second -debug was overriding all the rest).
Now I get exactly as in Wei's case:
130208 10:49:07 30219 boccali.6999:8@gridui1 XrootdResponse: 0100 sending 50 data bytes; status=0
130208 10:49:07 30219 boccali.6999:8@gridui1 XrootdProtocol: 0100 req=3000 dlen=101
130208 10:49:07 30219 boccali.6999:8@gridui1 XrootdProtocol: 0100 more auth requested; sz=1837
130208 10:49:07 30219 boccali.6999:8@gridui1 XrootdResponse: 0100 sending 1837 data bytes; status=4002
130208 10:49:07 30219 boccali.6999:8@gridui1 XrootdProtocol: 0100 req=3000 dlen=6581
130208 10:49:07 30219 secgsi_Authenticate: WARNING: user mapping lookup ok, but the requested user is not authorized (boccali). Instead, mapped as .dteam.
130208 10:49:07 30219 secgsiVOMS_Fun: proxy: /C=IT/O=INFN/OU=Personal Certificate/L=Pisa/CN=Enrico Mazzoni/CN=proxy
130208 10:49:07 30219 secgsiVOMS_Fun: adding cert: /C=IT/O=INFN/OU=Personal Certificate/L=Pisa/CN=Enrico Mazzoni
130208 10:49:07 30219 secgsiVOMS_Fun: retrieval successful
130208 10:49:07 30219 secgsiVOMS_Fun: found VO: theophys
130208 10:49:07 30219 secgsiVOMS_Fun: VOMS extensions do not match required criteria (grpopt=0;grps=/cms;vos=cms)
130208 10:49:07 30219 boccali.6999:8@gridui1 XrootdResponse: 0100 sending OK
130208 10:49:07 30219 XrootdXeq: boccali.6999:8@gridui1 login as .dteam
130208 10:49:07 30219 boccali.6999:8@gridui1 XrootdProtocol: 0100 req=3010 dlen=160
130208 10:49:07 30219 boccali.6999:8@gridui1 XrootdProtocol: 0100 open rat /store/mc/Winter10/DYJetsToLL_TuneZ2_M-50_7TeV-madgraph-tauola/AODSIM/E7TeV_ProbDist_2010Data_BX156_START39_V8-v1/0078/C0D6C43D-F615-E011-ADBA-E0CB4E19F9A1.root
130208 10:49:07 30219 boccali.6999:8@gridui1 ofs_open: 0-600 fn=/store/mc/Winter10/DYJetsToLL_TuneZ2_M-50_7TeV-madgraph-tauola/AODSIM/E7TeV_ProbDist_2010Data_BX156_START39_V8-v1/0078/C0D6C43D-F615-E011-ADBA-E0CB4E19F9A1.root
130208 10:49:07 30219 acc_Audit: boccali.6999:8@gridui1 grant gsi [log in to unmask] read /store/mc/Winter10/DYJetsToLL_TuneZ2_M-50_7TeV-madgraph-tauola/AODSIM/E7TeV_ProbDist_2010Data_BX156_START39_V8-v1/0078/C0D6C43D-F615-E011-ADBA-E0CB4E19F9A1.root
130208 10:49:07 30219 boccali.6999:8@gridui1 oss_Open_ufs: fd=32768 flags=0 mode=600 path=/gpfs/ddn/srm/cms/store/mc/Winter10/DYJetsToLL_TuneZ2_M-50_7TeV-madgraph-tauola/AODSIM/E7TeV_ProbDist_2010Data_BX156_START39_V8-v1/0078/C0D6C43D-F615-E011-ADBA-E0CB4E19F9A1.root
the difference here is that the File::Open is NOT blocked by the FS and hence it still works
so even if the log says
130208 10:49:07 30219 secgsiVOMS_Fun: VOMS extensions do not match required criteria (grpopt=0;grps=/cms;vos=cms)
it still goes on..
tom
On Feb 8, 2013, at 10:19 AM, Tommaso Boccali <[log in to unmask]> wrote:
> wait, but here i think the filesystem rejects you, not the plugin (FS says permission denied)
is it correct? In our case we would like Xrootd to say no-go (based on VOMS) before even attempting the file::Open
>
> my impression from this log is instead that the plugin said "please go ahead"
>
>
> tom
>
> On Feb 7, 2013, at 11:02 PM, "Yang, Wei" <[log in to unmask]> wrote:
>
>> I am an atlas user. I have this config
>>
>> -vomsfunparms:certfmt=raw|dbg|vos=cms|grps=/atlas
>>
>> and it correctly rejected me:
>>
>> 130207 13:57:32 6683 secgsiVOMS_Fun: proxy: /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203/CN=proxy
>> 130207 13:57:32 6683 secgsiVOMS_Fun: adding cert: /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>> 130207 13:57:32 6683 secgsiVOMS_Fun: retrieval successful
>> 130207 13:57:32 6683 secgsiVOMS_Fun: found VO: atlas
>> 130207 13:57:32 6683 secgsiVOMS_Fun: VOMS extensions do not match required criteria (/atlas;vos=cms)
>> 130207 13:57:32 6683 XrootdXeq: yangw.17099:8@atlint01 login as 684536c7.0
>> 130207 13:57:32 6683 ofs_open: yangw.17099:8@atlint01 Unable to open /atlas/dq2/user/HironoriIto/user.HironoriIto.xrootd.wt2/user.HironoriIto.xrootd.wt2-100M; Permission denied
>>
>> it allows me to connect but ultimately I am rejected because the oss.authdb has "g /atlas /path rl". This is the version before Gerri's fix of the uninitialized string, and it is slc5-gcc4.1.
>>
>> regards,
>> Wei Yang | [log in to unmask] | 650-926-3338(O)
>>
>>
>> On Feb 7, 2013, at 2:12 AM, Tommaso Boccali wrote:
>>
>>> too optimistic unfortunately: an atlas user is allowed
>>>
>>> 130207 11:09:51 5718 stupputi.6186:[log in to unmask] XrootdProtocol: 0100 req=3000 dlen=5877
>>> 130207 11:09:51 5718 secgsi_Authenticate: WARNING: user mapping lookup ok, but the requested user is not authorized (stupputi). Instead, mapped as .atlas.
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: proxy: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Salvatore Alessandro Tupputi/CN=proxy
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: adding cert: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Salvatore Alessandro Tupputi
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: retrieval successful
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: found VO: atlas
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> group: '/atlas', role: 'NULL', cap: 'NULL'
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> group: '/atlas/it', role: 'NULL', cap: 'NULL'
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> group: '/atlas/lcg1', role: 'NULL', cap: 'NULL'
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> fqan: '/atlas/Role=NULL/Capability=NULL'
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> fqan: '/atlas/it/Role=NULL/Capability=NULL'
>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> fqan: '/atlas/lcg1/Role=NULL/Capability=NULL'
>>> 130207 11:09:51 5718 stupputi.6186:[log in to unmask] XrootdResponse: 0100 sending OK
>>> 130207 11:09:51 5718 XrootdMonitor: 196 bytes sent to xrootd.t2.ucsd.edu:9930 rc=0
>>> 130207 11:09:51 5718 XrootdXeq: stupputi.6186:[log in to unmask] login as .atlas
>>>
>>> any idea why is wrong?
>>>
>>> thanks
>>>
>>> tom
>>>
>>>
>>> On Feb 7, 2013, at 11:10 , Tommaso Boccali <[log in to unmask]> wrote:
>>>
>>>>
and non cms user gets
>>>>
>>>> 130207 11:01:43 5718 XrdSched: scheduling monitor window clock in 5 seconds
>>>> 130207 11:01:43 5846 tentiams.685:[log in to unmask] XrootdProtocol: 0100 req=3000 dlen=5349
>>>> 130207 11:01:43 5846 secgsi_Authenticate: WARNING: user mapping lookup ok, but the requested user is not authorized (tentiams). Instead, mapped as .dteam.
>>>> 130207 11:01:43 5846 secgsiVOMS_Fun: proxy: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Matteo Tenti/CN=proxy
>>>> 130207 11:01:43 5846 secgsiVOMS_Fun: adding cert: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Matteo Tenti
>>>> 130207 11:01:43 5846 secgsiVOMS_Fun: retrieval FAILED: Cannot verify AC signature!
>>>> 130207 11:01:43 5846 secgsi_Authenticate: ERROR: the VOMS extraction plug-in reported a failure for this handshake
>>>> 130207 11:01:43 5846 XrootdXeq: User authentication failed;
>>>> 130207 11:01:43 5846 tentiams.685:[log in to unmask] XrootdResponse: 0100 sending err 3010:
>>>> 130207 11:01:43 4964 XrdInet: Accepted connection from [log in to unmask]
>>>>
>>>> if this is what is expected, we are good to go
>>>>
>>>> tom
>>>>
>>>> On Feb 7, 2013, at 10:12 , Tommaso Boccali <[log in to unmask]> wrote:
>>>>
>>>>> ciao gerri, for the moment I have the _impression_ it is working:
>>>>>
>>>>> 130207 10:08:18 4968 XrdSched: scheduling stats reporter in 30 seconds
>>>>> 130207 10:08:19 4964 XrdInet: Accepted connection from [log in to unmask]
>>>>> 130207 10:08:19 4967 XrdSched: running ?:8@so1wn60 inq=0
>>>>> 130207 10:08:19 4967 XrdProtocol: matched protocol xrootd
>>>>> 130207 10:08:19 4967 ?:8@so1wn60 XrdPoll: FD 8 attached to poller 0; num=1
>>>>> 130207 10:08:19 4967 ?:8@so1wn60 XrootdProtocol: 0100 req=3007 dlen=0
>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdResponse: 0100 sending 50 data bytes; status=0
>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdProtocol: 0100 req=3000 dlen=101
>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdProtocol: 0100 more auth requested; sz=1837
>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdResponse: 0100 sending 1837 data bytes; status=4002
>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdProtocol: 0100 req=3000 dlen=15253
>>>>> 130207 10:08:19 4967 secgsi_Authenticate: WARNING: user mapping lookup ok, but the requested user is not authorized (cmsprd). Instead, mapped as cmssgm.
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: proxy: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy/CN=proxy/CN=pro
>>>>> xy/CN=proxy/CN=limited proxy
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy/CN=proxy
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy/CN=proxy/
>>>>> CN=proxy
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy/CN=proxy/
>>>>> CN=proxy/CN=proxy
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: retrieval successful
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: found VO: cms
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> group: '/cms', role: 'production', cap: 'NULL'
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> group: '/cms', role: 'NULL', cap: 'NULL'
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> group: '/cms/TEAM', role: 'NULL', cap: 'NULL'
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> group: '/cms/dbs', role: 'NULL', cap: 'NULL'
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> fqan: '/cms/Role=production/Capability=NULL'
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> fqan: '/cms/Role=NULL/Capability=NULL'
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> fqan: '/cms/TEAM/Role=NULL/Capability=NULL'
>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> fqan: '/cms/dbs/Role=NULL/Capability=NULL'
>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdResponse: 0100 sending OK
>>>>>
>>>>>
>>>>> is this what you would expect?
>>>>>
>>>>> config is as simple as
>>>>>
>>>>> sec.protparm gsi -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:grpopt=0|vos=cms|certfmt=raw
>>>>> sec.protocol /usr/lib64 gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/hostcert.pem -key:/etc/grid-security/xrd/hostkey.pem -crl:3 -moninfo
>>>>>
>>>>>
>>>>> On Feb 7, 2013, at 10:00 , Tommaso Boccali <[log in to unmask]> wrote:
>>>>>
>>>>>> ok thanks, will do
>>>>>> because I found out voms 2.0.8 requires a change EMI1->EMI2 which is not that trivial on a production machine
>>>>>>
>>>>>> tom
>>>>>> On Feb 7, 2013, at 9:58 , Gerardo Ganis <[log in to unmask]> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> My statement 'The builds require VOMS 2.0.8' is probably too strong. The right statement is probably
>>>>>>> 'require VOMS 2.x', so I would give a try with 2.0.7 before bothering finding ways to update ...
>>>>>>>
>>>>>>> Cheers, Gerri
>>>>>>>
>>>>>>> On 2/7/13 9:12 AM, Tommaso Boccali wrote:
>>>>>>>> ciao Gerri, starting to look into this
(sorry for the delay)
>>>>>>>>
>>>>>>>> I am stuck at point #1:
>>>>>>>>
>>>>>>>>> 1. The builds require VOMS 2.0.8 which, if I understand correctly, is a not (yet?) available in OSG
>>>>>>>> I have
>>>>>>>>
>>>>>>>> [root@stormgf1 xroot-tests]# rpm -qa|grep voms
>>>>>>>> voms-2.0.7-1.el5.x86_64
>>>>>>>>
>>>>>>>> So I need to find a way to update this
standard way from the repository does not allow me to get a 2.0.8
>>>>>>>>
>>>>>>>> stay tuned
>>>>>>>>
>>>>>>>> tom
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 4, 2013, at 18:42 , Gerardo Ganis <[log in to unmask]> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> This is the status of things:
>>>>>>>>>
>>>>>>>>> The plug-in is available for test at 'https://github.com/gganis/voms.git' from where you can download
>>>>>>>>> the sources. Binaries for SLC5 (x86_64, gcc-4.1, gcc 4.3) and SLC6 (x86_64, gcc-4.6) are available under
>>>>>>>>>
>>>>>>>>> /afs/cern.ch/work/g/ganis/public/vomsxrd/vomsxrd-0.0.1
>>>>>>>>>
>>>>>>>>> (README and examples under /afs/cern.ch/work/g/ganis/public/vomsxrd).
>>>>>>>>>
>>>>>>>>> With the following caveats:
>>>>>>>>>
>>>>>>>>> 1. The builds require VOMS 2.0.8 which, if I understand correctly, is a not (yet?) available in OSG
>>>>>>>>> 2. Unfortunately the backport of the vomsfun functionality was not complete in the 3.2.x stable branch,
>>>>>>>>> so to use the plug-in you have either to use the HEAD of the 'stable' branch or 3.3.x-rc1 .
>>>>>>>>> RPMs for the stable branch are available from the Teamcity portal:
>>>>>>>>>
>>>>>>>>> https://teamcity-dss.cern.ch:8443/project.html?projectId=project13&tab=projectOverview
>>>>>>>>>
>>>>>>>>> Can you please let me know if you can try this out or what you miss to be able to try?
>>>>>>>>>
>>>>>>>>> Gerri
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/31/13 7:19 PM, Yang, Wei wrote:
>>>>>>>>>> I haven't get it to work yet. I am communicating with the developer.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> Wei Yang | [log in to unmask] | 650-926-3338(O)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jan 31, 2013, at 2:28 AM, Tommaso Boccali wrote:
>>>>>>>>>>
>>>>>>>>>>> Follow-up Comment #2, sr #135141 (project xrootd):
>>>>>>>>>>>
>>>>>>>>>>> ciao, news on that plugin?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>>
>>>>>>>>>>> tom
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________________
>>>>>>>>>>>
>>>>>>>>>>> Reply to this item at:
>>>>>>>>>>>
>>>>>>>>>>> <http://savannah.cern.ch/support/?135141>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Message sent via/by LCG Savannah
>>>>>>>>>>> http://savannah.cern.ch/
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> +--------------------------------------------------------------------------+
>>>>>>>>> Gerardo GANIS CERN, PH Dept, SFT group, CH 1211 Geneve 23
>>>>>>>>> room: 32-RC-006, tel: +41 22 7676439
>>>>>>>>> email: [log in to unmask], fax: +41 22 7669133
>>>>>>>>> +--------------------------------------------------------------------------+
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|
