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