That's weird.
I do not see anything wrong with your configuration.
I have managed to try with gcc 4.1 and for me it works (see attached
log).
Gerri
On 2/7/13 4:27 PM, Tommaso Boccali wrote:
> apparently yes:
>
> [root@stormgf1 ~]# md5sum /usr/lib64/libXrdSecgsiVOMS.so
> af8c1a3f6b170c3264e83ac894c79f1f /usr/lib64/libXrdSecgsiVOMS.so
>
>
> I paste here my xrootd config in case I forgot something stupid (quite likely …)
>
> ########################################
> # Port specifications; only the redirector needs to use a well-known port
> # "any" will cause rooted to bind to any available port. Change as needed for firewalls.
> xrd.port 7070
> xrd.port 1094 if xrootd.ba.infn.it
>
> # The roles this server will play.
> all.role server
> all.role manager if xrootd.unl.edu xrootd.ba.infn.it
> # The known managers
> all.manager xrootd.ba.infn.it 1213
> #all.manager xrootd‐itb.unl.edu 1213
> #all.manager xrootd.ultralight.org:1213
>
> # Allow any path to be exported; this is further refined in the authfile.
> all.export / r
>
> # Hosts allowed to use this xrootd cluster
> cms.allow host *
>
> # Keep this as a work-around for an xrootd bug
> oss.localroot /gpfs/ddn/srm/cms
>
> ### Standard directives
> # Simple sites probably don't need to touch these.
> xrootd.trace all
> ofs.trace all
> xrd.trace all
> cms.trace all
> oss.trace all
>
>
> # Integrate with CMS TFC, placed in /etc/storage.xml
> #oss.namelib /usr/lib/libXrdCmsTfc.so file:/etc/storage.xml?protocol=hadoop
>
> # Use the VOMS extrenal plug-in for VOMS attribute extraction
> #sec.protparm gsi -vomsfun:/afs/cern.ch/work/g/ganis/public/vomsxrd/vomsxrd-0.0.1/slc5-gcc41/lib64/libXrdSecgsiVOMS.so
> sec.protparm gsi -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:grpopt=0|vos=cms|grps=/cms|certfmt=raw
>
> # Require the chosen VO
>
> # Use this to switchon verbosity
> sec.protparm gsi -vomsfunparms:dbg
>
>
> # Turn on authorization
> ofs.authorize 1
> acc.authdb /etc/xrootd/Authfile
> acc.audit deny grant
>
> # Security configuration
> 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
> #sec.protocol /usr/lib64 gsi -d:2 -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/hostcert.pem -key:/etc/grid-security/xrd/hostkey.pem -crl:3 -moninfo -authzfun:libXrdSecgsiAuthzVO.so -authzfunparms:valido=cms -gmapopt:10 -gmapto:0
>
>
> xrootd.seclib /usr/lib64/libXrdSec.so
> xrootd.fslib /usr/lib64/libXrdOfs.so
> #ofs.osslib /usr/lib/libXrdHdfs.so
> all.adminpath /var/run/xrootd
> cms.pidpath /var/run/xrootd
>
> if exec xrootd
> xrd.report xrootd.t2.ucsd.edu:9931 every 30s all sync
> xrootd.monitor all auth flush 30s mbuff 1472 window 5s dest files io info user xrootd.t2.ucsd.edu:9930
> fi
>
>
> #############################################
>
> On Feb 7, 2013, at 4:16 PM, Gerardo Ganis <[log in to unmask]> wrote:
>
>> Are you sure that you are using the last binary?
>>
>> I could not try the SLC5-gcc41, but the other two, with your configuration, deny access to my 'atlas'
>> proxy.
>>
>> Cheers, Gerri
>>
>> af8c1a3f6b170c3264e83ac894c79f1f /afs/cern.ch/user/g/ganis/work/public/vomsxrd/vomsxrd-0.0.1/slc5-gcc41/lib64/libXrdSecgsiVOMS.so.1.0.0
>> 520bdb749e359f7f5b01d57bea5be89b /afs/cern.ch/user/g/ganis/work/public/vomsxrd/vomsxrd-0.0.1/slc5/lib64/libXrdSecgsiVOMS.so.1.0.0
>> bdb3ca9d27f0b35a045234d30794e859 /afs/cern.ch/user/g/ganis/work/public/vomsxrd/vomsxrd-0.0.1/slc6/lib64/libXrdSecgsiVOMS.so.1.0.0
>>
>>
>>
>>
>> On 2/7/13 3:02 PM, Tommaso Boccali wrote:
>>> ciao seems still allowing lhcb guys
>>>
>>> 130207 15:00:05 23665 XrdSched: running ?:[log in to unmask] inq=0
>>> 130207 15:00:05 23665 XrdProtocol: matched protocol xrootd
>>> 130207 15:00:05 23665 ?:[log in to unmask] XrdPoll: FD 8 attached to poller 0; num=1
>>> 130207 15:00:05 23665 ?:[log in to unmask] XrootdProtocol: 0100 req=3007 dlen=0
>>> 130207 15:00:05 23665 perazzin.28132:[log in to unmask] XrootdResponse: 0100 sending 50 data bytes; status=0
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] XrootdProtocol: 0100 req=3000 dlen=101
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] XrootdProtocol: 0100 more auth requested; sz=1837
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] XrootdResponse: 0100 sending 1837 data bytes; status=4002
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] XrootdProtocol: 0100 req=3000 dlen=6533
>>> 130207 15:00:06 23665 secgsiVOMS_Fun: proxy: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Stefano Perazzini/CN=proxy
>>> 130207 15:00:06 23665 secgsiVOMS_Fun: adding cert: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Stefano Perazzini
>>> 130207 15:00:06 23665 secgsiVOMS_Fun: retrieval successful
>>> 130207 15:00:06 23665 secgsiVOMS_Fun: found VO: lhcb
>>> 130207 15:00:06 23665 secgsiVOMS_Fun: ---> group: '/lhcb', role: 'NULL', cap: 'NULL'
>>> 130207 15:00:06 23665 secgsiVOMS_Fun: ---> fqan: '/lhcb/Role=NULL/Capability=NULL'
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] XrootdResponse: 0100 sending OK
>>> 130207 15:00:06 23665 XrootdMonitor: 195 bytes sent to xrootd.t2.ucsd.edu:9930 rc=0
>>> 130207 15:00:06 23665 XrootdXeq: perazzin.28132:[log in to unmask] login as lhcbsgm
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] XrootdProtocol: 0100 req=3010 dlen=160
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] XrootdProtocol: 0100 open rat /store/mc/Winter10/DYJetsToLL_TuneZ2_M-50_7TeV-madgraph-tauola/AODSIM/E7TeV_ProbDist_2010Data_BX156_START39_V
>>> 8-v1/0078/C0D6C43D-F615-E011-ADBA-E0CB4E19F9A1.root
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] ofs_open: 0-600 fn=/store/mc/Winter10/DYJetsToLL_TuneZ2_M-50_7TeV-madgraph-tauola/AODSIM/E7TeV_ProbDist_2010Data_BX156_START39_V8-v1/0078/C
>>> 0D6C43D-F615-E011-ADBA-E0CB4E19F9A1.root
>>> 130207 15:00:06 23665 acc_Audit: perazzin.28132:[log in to unmask] grant gsi [log in to unmask] read /store/mc/Winter10/DYJetsToLL_TuneZ2_M-50_7TeV-madgraph-tauola/AODSIM/E7TeV_Prob
>>> Dist_2010Data_BX156_START39_V8-v1/0078/C0D6C43D-F615-E011-ADBA-E0CB4E19F9A1.root
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] 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_P
>>> robDist_2010Data_BX156_START39_V8-v1/0078/C0D6C43D-F615-E011-ADBA-E0CB4E19F9A1.root
>>> 130207 15:00:06 23665 perazzin.28132:[log in to unmask] ofs_fstat: fn=/store/mc/Winter10/DYJetsToLL_TuneZ2_M-50_7TeV-madgraph-tauola/AODSIM/E7TeV_ProbDist_2010Data_BX156_START39_V8-v1/0078/C0D6C
>>> 43D-F615-E011-ADBA-E0CB4E19F9A1.root
>>> 130207 15:00:06 23665 XrootdMonitor: 223 bytes sent to xrootd.t2.ucsd.edu:9930 rc=0
>>>
>>>
>>>
>>> VO:lhcb is found, but denying is not enforced
>>>
>>>
>>> I am now using
>>>
>>> sec.protparm gsi -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:grpopt=0|vos=cms|grps=/cms|certfmt=raw
>>>
>>> tom
>>>
>>> On Feb 7, 2013, at 12:17 , Gerardo Ganis <[log in to unmask]> wrote:
>>>
>>>> Hi Tom,
>>>>
>>>> Ok, a string was not correctly re-initialized.
>>>> I should have fixed it. Could you please retry now?
>>>>
>>>> Thanks for the feedback.
>>>>
>>>> Gerri
>>>>
>>>>
>>>> On 2/7/13 11: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
130207 18:14:18 15472 secgsiVOMS_Init: ++++++++++++++++++ VOMS plugi-in ++++++++++++++++++++++++++++++
130207 18:14:18 15472 secgsiVOMS_Init: +++ proxy fmt: raw
130207 18:14:18 15472 secgsiVOMS_Init: +++ group option: first of all
130207 18:14:18 15472 secgsiVOMS_Init: +++ VO(s): cms
130207 18:14:18 15472 secgsiVOMS_Init: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
130207 18:14:18 15472 secgsi_LoadVOMSFun: using 'XrdSecgsiVOMSFun()' from libXrdSecgsiVOMS.so
=====> sec.protocol gsi -cert:~/.globus/usercert.pem -key:~/.globus/userkey.pem -ca:2 -crl:1 -certdir:/afs/cern.ch/project/gd/LCG-share2/certificates -crldir:/afs/cern.ch/project/gd/LCG-share2/certificates
Config 3 authentication directives processed in /afs/cern.ch/user/g/ganis/work/public/vomsxrd/xrd.voms.cf
------ Authentication system initialization completed.
++++++ File system initialization started.
++++++ Storage system initialization started.
Config effective /afs/cern.ch/user/g/ganis/work/public/vomsxrd/xrd.voms.cf oss configuration:
oss.alloc 0 0 0
oss.cachescan 600
oss.fdlimit 512 1024
oss.maxsize 0
oss.trace 0
oss.xfr 1 deny 10800 keep 1200
oss.memfile off max 25250656256
oss.defaults r/w nocheck nodread nomig norcreate nopurge nostage xattr
------ Storage system initialization completed.
Config effective /afs/cern.ch/user/g/ganis/work/public/vomsxrd/xrd.voms.cf ofs configuration:
ofs.role server
ofs.maxdelay 60
ofs.persist manual hold 600 logdir /tmp/ganis/admin/.ofs/posc.log
ofs.trace 0
------ File system server initialization completed.
Config warning: 'xrootd.prepare logdir' not specified; prepare tracking disabled.
130207 18:14:18 15472 XrootdConfig: Unable to open /tmp//xrootd.pid; permission denied
------ xrootd protocol initialization completed.
------ xrootd [log in to unmask]:1094 initialization completed.
130207 18:14:21 15476 secgsiVOMS_Fun: proxy: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=ganis/CN=393971/CN=Gerardo Ganis/CN=proxy
130207 18:14:21 15476 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=ganis/CN=393971/CN=Gerardo Ganis
130207 18:14:21 15476 secgsiVOMS_Fun: retrieval successful
130207 18:14:21 15476 secgsiVOMS_Fun: found VO: atlas
130207 18:14:21 15476 secgsiVOMS_Fun: VOMS extensions do not match required criteria (grpopt=0;vos=cms)
130207 18:14:21 15476 XrootdXeq: gganis.26049:25@lxplus445 login as 43d6fd1c.0
130207 18:14:21 15476 ofs_open: gganis.26049:25@lxplus445 Unable to open /tmp/ganis/test.root; No such file or directory
130207 18:14:21 15476 XrootdXeq: gganis.26049:25@lxplus445 disc 0:00:00
########################################################################
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
|
