Of course, sorry. I thought that Wei was aware of that, since I
believe he used it so far.
With the default settings, the new plug-in should fill XrdSecEntity
exactly as the 'handmade' VOMS extractor
was doing. So authorization via AuthzVOMS should just work as before.
Gerri
On 2/6/13 7:33 PM, Andrew Hanushevsky wrote:
> The third option is to use teh AuthZVOMS plugin which will do exactly
> what you want it to do and more.
>
> Andy
>
> On Wed, 6 Feb 2013, Gerardo Ganis wrote:
>
>> Hi Wei,
>>
>> Thanks for the feedback.
>>
>> About your question.
>> The module fills the XrdSecEntity structure which is the analysed
>> by the authorization module.
>>
>> Another option is to specify the group (or groups) you want to
>> authorize with the 'grps=grp1[,grp2,...]'
>> configuration option: if the group is not found, authentication
>> fails. This functionality was not correctly
>> implemented in the binary you tested, but I have just fixed it, so
>> you can try it now taking the latest
>> version.
>>
>> Cheers, Gerri
>>
>>
>> On 2/6/13 8:53 AM, Yang, Wei wrote:
>>> Hi Gerri,
>>>
>>> It turns out that the .so I tried wasn't the latest. I just tried
>>> the latest one (slc5-gcc4.3) and it can extract the VO info
>>> correctly from various types of limited proxy used at ATLAS sites. I
>>> will try again with slc5-gcc4.1 and slc6 platforms. I have another
>>> question. With this module, how to do map a VO to a specific group
>>> (and then grant this group access in oss.authdb)?
>>>
>>> regards,
>>> Wei Yang | [log in to unmask] | 650-926-3338(O)
>>>
>>>
>>>
>>>
>>> On Feb 5, 2013, at 1:21 AM, Gerardo Ganis wrote:
>>>
>>>> Hi Wei,
>>>>
>>>> It does not look as loading the right plug-in .
>>>> Are there any related messages at xrootd startup?
>>>> Could you post the full startup log?
>>>>
>>>> You should get something like this at a certain point:
>>>>
>>>> 130205 10:20:13 4689 secgsiVOMS_VOMSInit: ++++++++++++++++++ VOMS
>>>> plugi-in ++++++++++++++++++++++++++++++
>>>> 130205 10:20:13 4689 secgsiVOMS_VOMSInit: +++ proxy fmt: raw
>>>> 130205 10:20:13 4689 secgsiVOMS_VOMSInit: +++ group option: last of
>>>> all
>>>> 130205 10:20:13 4689 secgsiVOMS_VOMSInit:
>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 130205 10:20:13 4689 secgsi_LoadVOMSFun: using 'XrdSecgsiVOMSFun()'
>>>> from
>>>> libXrdSecgsiVOMS.so
>>>> =====> sec.protocol gsi -cert:~/.globus/usercert.pem
>>>> -key:~/.globus/userkey.pem
>>>> -certdir:/afs/cern.ch/user/g/ganis/.globus/certificates -ca:2 -crl:3
>>>> -crldir:/afs/cern.ch/user/g/ganis/.globus/certificates
>>>> Config 2 authentication directives processed in xrd.voms.cf
>>>> ------ Authentication system initialization completed.
>>>>
>>>> Gerri
>>>>
>>>>
>>>> On 2/4/13 8:15 PM, Yang, Wei wrote:
>>>>> [Adding David Smith since he may want to know this ...]
>>>>>
>>>>> Hi Gerri,
>>>>>
>>>>> I am having trouble getting it to work. On RHEL5-64, I compiled
>>>>> xrootd git head with gcc 4.3 and use the .so you compiled. Here is
>>>>> my config file:
>>>>>
>>>>> all.export /xrootd/atlas r/o
>>>>> all.role server
>>>>> xrootd.async off
>>>>> xrootd.seclib
>>>>> /afs/slac.stanford.edu/package/xrootd/githead/amd64_rhel50/src/libXrdSec.so
>>>>> sec.protparm gsi -vomsfun:/etc/xrootd/libXrdSecgsiVOMS.so.1
>>>>> -vomsfunparms:grpopt=0|certfmt=raw|vos=atlas|dbg
>>>>> sec.protocol
>>>>> /afs/slac.stanford.edu/package/xrootd/githead/amd64_rhel50/src gsi
>>>>> -ca:1 -crl:3
>>>>> acc.authdb /etc/xrootd/auth_file
>>>>> acc.authrefresh 60
>>>>> ofs.authorize
>>>>>
>>>>> here is my proxy info (I tried a proxy created locally using VOMS
>>>>> 1.8.8 and a proxy created at CERN using VOMS 2.0.8).
>>>>>
>>>>> subject : /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203/CN=proxy
>>>>> issuer : /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>>>>> identity : /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>>>>> type : proxy
>>>>> strength : 1024 bits
>>>>> path : /tmp/x509up_u2353
>>>>> timeleft : 11:58:22
>>>>> === VO atlas extension information ===
>>>>> VO : atlas
>>>>> subject : /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>>>>> issuer : /DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch
>>>>> attribute : /atlas/Role=NULL/Capability=NULL
>>>>> attribute : /atlas/lcg1/Role=NULL/Capability=NULL
>>>>> attribute : /atlas/usatlas/Role=NULL/Capability=NULL
>>>>> attribute : nickname = yangw (atlas)
>>>>> timeleft : 11:58:22
>>>>> uri : lcg-voms.cern.ch:15001
>>>>>
>>>>> Here is the $X509_VOMS_DIR
>>>>>
>>>>> [yangw@atl-prod08 xrootd]$ ls -l $X509_VOMS_DIR
>>>>> total 68
>>>>> -rw-r--r-- 1 yangw sf 69 Feb 16 2010 README
>>>>> drwxr-xr-x 2 yangw sf 2048 Nov 25 2011 atlas/
>>>>> -rw-r--r-- 1 yangw sf 1440 Feb 2 2010 cert-voms-01.cnaf.infn.it.pem
>>>>> -rw-r--r-- 1 yangw sf 1440 Feb 2 2010
>>>>> cert-voms-01.cnaf.infn.it.pem.1
>>>>> -rw-r--r-- 1 yangw sf 1424 Feb 2 2010
>>>>> cert-voms-01.cnaf.infn.it.pem.2
>>>>> -rw-r--r-- 1 yangw sf 1436 Feb 2 2010 grid12.lal.in2p3.fr.pem
>>>>> -rw-r--r-- 1 yangw sf 5154 Feb 2 2010 mu4.matrix.sara.nl.pem
>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms-01.pd.infn.it.pem
>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms-01.pd.infn.it.pem.1
>>>>> -rw-r--r-- 1 yangw sf 1420 Feb 2 2010 voms-01.pd.infn.it.pem.2
>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms-02.pd.infn.it.pem
>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms-02.pd.infn.it.pem.1
>>>>> -rw-r--r-- 1 yangw sf 1420 Feb 2 2010 voms-02.pd.infn.it.pem.2
>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms.cnaf.infn.it.pem
>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms.cnaf.infn.it.pem.1
>>>>> -rw-r--r-- 1 yangw sf 1419 Feb 2 2010 voms.cnaf.infn.it.pem.2
>>>>> -rw-r--r-- 1 yangw sf 1399 Feb 2 2010 voms.cnaf.infn.it.pem.3
>>>>> -rw-r--r-- 1 yangw sf 1484 Feb 2 2010 voms.fnal.gov.pem
>>>>> -rw-r--r-- 1 yangw sf 1298 Feb 2 2010 voms.fnal.gov.pem.1
>>>>> -rw-r--r-- 1 yangw sf 1651 Feb 2 2010 voms.grid.sara.nl.pem
>>>>> -rw-r--r-- 1 yangw sf 5152 Feb 2 2010 voms.grid.sara.nl.pem.1
>>>>> -rw-r--r-- 1 yangw sf 1793 Feb 2 2010 voms.grid.sinica.edu.tw.pem
>>>>> -rw-r--r-- 1 yangw sf 1842 Feb 2 2010 voms.gridpp.ac.uk.pem
>>>>> -rw-r--r-- 1 yangw sf 1843 Feb 2 2010 voms.gridpp.ac.uk.pem.1
>>>>> -rw-r--r-- 1 yangw sf 2138 Feb 2 2010 voms.gridpp.ac.uk.pem.2
>>>>> -rw-r--r-- 1 yangw sf 1472 Feb 2 2010
>>>>> voms.research-infrastructures.eu.pem
>>>>> -rw-r--r-- 1 yangw sf 1472 Feb 2 2010
>>>>> voms.research-infrastructures.eu.pem.1
>>>>> -rw-r--r-- 1 yangw sf 1424 Feb 2 2010 voms2.cnaf.infn.it.pem
>>>>> -rw-r--r-- 1 yangw sf 1424 Feb 2 2010 voms2.cnaf.infn.it.pem.1
>>>>> -rw-r--r-- 1 yangw sf 1404 Feb 2 2010 voms2.cnaf.infn.it.pem.2
>>>>>
>>>>> And here is the log file:
>>>>>
>>>>> X509Chain::Dump://------------------Dumping X509 chain content
>>>>> ------------------//
>>>>> X509Chain::Dump://
>>>>> X509Chain::Dump:// Chain instance: 0x8eeb7d0
>>>>> X509Chain::Dump://
>>>>> X509Chain::Dump:// Number of certificates: 3
>>>>> X509Chain::Dump://
>>>>> X509Chain::Dump:// CA: /DC=org/DC=DOEGrids/OU=Certificate
>>>>> Authorities/CN=DOEGrids CA 1
>>>>> X509Chain::Dump:// EEC: /DC=org/DC=doegrids/OU=People/CN=Wei Yang
>>>>> 74203
>>>>> X509Chain::Dump://
>>>>> X509Chain::Dump:// Issuer: d1b603c3.0 Subject: 1c3f2ca8.0 Type: CA
>>>>> X509Chain::Dump:// Issuer: 1c3f2ca8.0 Subject: 684536c7.0 Type: EEC
>>>>> X509Chain::Dump:// Issuer: 684536c7.0 Subject: f81adb11.0 Type: Proxy
>>>>> X509Chain::Dump://
>>>>> X509Chain::Dump://---------------------------- END
>>>>> ------------------------------//
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +++++++++++++++ X509 dump
>>>>> +++++++++++++++++++++++
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + File:
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Type: Proxy
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Serial Number: 283485584
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Subject:
>>>>> /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203/CN=proxy
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Subject hash: f81adb11.0
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Issuer:
>>>>> /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Issuer hash: 684536c7.0
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + Validity:
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + NotBefore: 1360032944
>>>>> UTC - Mon Feb 4 18:55:44 2013
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + NotAfter: 1360076444
>>>>> UTC - Tue Feb 5 07:00:44 2013
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: + PKI: Public
>>>>> 130204 11:02:36 14262 crypto_X509::Dump: +
>>>>> 130204 11:02:36 14262 crypto_X509::Dump:
>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> 130204 11:02:36 14262 secgsi_VOMSFun: xrc: 1
>>>>> 130204 11:02:36 14262 secgsi_VOMSFun: NOT OK: Cannot discover
>>>>> holder from certificate chain!
>>>>> 130204 11:02:36 14262 secgsi_VOMSFun: WARNING: no VO found! (VOMS
>>>>> attributes: '')
>>>>> 130204 11:02:36 14262 XrootdXeq: yangw.27906:22@atlint01 login as
>>>>> 684536c7.0
>>>>> 130204 11:02:41 14262 XrootdXeq: yangw.27906:22@atlint01 disc 0:00:05
>>>>>
>>>>> I am not sure what the 4th line from the bottom mean.
>>>>>
>>>>> regards,
>>>>> Wei Yang | [log in to unmask] | 650-926-3338(O)
>>>>>
>>>>>
>>>>> On Feb 4, 2013, at 9:42 AM, Gerardo Ganis 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
########################################################################
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
|
