Problem with delegated proxy

Development
1

We’ve run into a problem with VOMS-based user authorization in EOS

Everything works just fine with an RFC proxy generated on our UI.

Client:

-bash-4.2$ rpm -qf `which voms-proxy-info`
voms-clients-cpp-2.0.16-1.el7.x86_64
-bash-4.2$ rpm -qf `which xrdcp`
xrootd-client-5.2.0-1.el7.x86_64
-bash-4.2$ rpm -qf `which eos`
eos-client-4.8.63-20210924154237git449f2b2.el7.cern.x86_64

-bash-4.2$ voms-proxy-info --all
subject   : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=579999927
issuer    : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev
identity  : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev
type      : RFC compliant proxy
strength  : 1024 bits
path      : /tmp/x509up_u1947400056
timeleft  : 9:24:35
key usage : Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
=== VO spd.nica.jinr extension information ===
VO        : spd.nica.jinr
subject   : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev
issuer    : /C=RU/O=RDIG/OU=hosts/OU=jinr.ru/CN=lcgvoms01.jinr.ru
attribute : /spd.nica.jinr/Role=NULL/Capability=NULL
timeleft  : 9:24:35
uri       : lcgvoms01.jinr.ru:15003
-bash-4.2$    

-bash-4.2$ export EOS_MGM_URL=root://alice21.spbu.ru
-bash-4.2$ eos whoami
Virtual Identity: uid=1219200014 (1219200014) gid=7000 (7000) [authz:gsi] host=v009.pnpi.nw.ru domain=pnpi.nw.ru
-bash-4.2$

-bash-4.2$ xrdcp /etc/passwd root://alice21.spbu.ru//eos/spbcloud/spd/mainpool/file$RANDOM
[2.572kB/2.572kB][100%][==================================================][2.572kB/s]
-bash-4.2$ eos ls -l /eos/spbcloud/spd/mainpool/
-rw-r--r--   1 spd      spd              2634 Jan 24 16:36 file18225
-bash-4.2$

Server:

[root@alice21 ~]# rpm -qf `which eos`
eos-client-4.8.62-1.el7.cern.x86_64
[root@alice21 ~]#  
[root@alice21 ~]# tail -4  /etc/grid-security/grid-mapfile
"/mpd.nica.jinr/Role=NULL/Capability=NULL" mpd
"/mpd.nica.jinr" mpd
"/spd.nica.jinr/Role=NULL/Capability=NULL" spd
"/spd.nica.jinr" spd
[root@alice21 ~]#    
[root@alice21 ~]# grep gsi /etc/xrd.cf.mgm
sec.protocol gsi -gridmap:/etc/grid-security/grid-mapfile -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -d:3 -crl:0  -vomsfunparms:dbg|certfmt=x509 -gmapopt:11  -gmapto:60  -vomsat:1  -moninfo:1
sec.protbind * only krb5 gsi sss
[root@alice21 ~]#    



From log /var/log/eos/mgm/xrdlog.mgm:
……………………………………………………………………
220124 16:36:43 11795 cryptossl_X509GetVOMSAttr: ret: 1 - vat: /spd.nica.jinr/Role=NULL/Capability=NULL
220124 16:36:43 11795 cryptossl_X509GetVOMSAttr: found extension '2.5.29.15'
220124 16:36:43 11795 cryptossl_X509GetVOMSAttr: found extension '2.5.29.19'
220124 16:36:43 11795 cryptossl_X509GetVOMSAttr: found extension '2.5.29.35'
220124 16:36:43 11795 cryptossl_X509GetVOMSAttr: found extension '1.3.6.1.5.5.7.1.14'
220124 16:36:43 11795 secgsi_Authenticate: VOMS: Entity.vorg:         spd.nica.jinr
220124 16:36:43 11795 secgsi_Authenticate: VOMS: Entity.grps:         /spd.nica.jinr
220124 16:36:43 11795 secgsi_Authenticate: VOMS: Entity.role:         <none>
220124 16:36:43 11795 secgsi_Authenticate: VOMS: Entity.endorsements: /spd.nica.jinr/Role=NULL/Capability=NULL
220124 16:36:43 11795 sut_Buffer::~XrdSutBuffer: type: 3000
220124 16:36:43 11795 sut_Buffer::~XrdSutBuffer: type: 3001
…………………………………………………………………………
220124 16:36:43 11795 XrootdXeq: zar.14333:122@v009.pnpi.nw.ru pub IPv4 login as /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev
220124 16:36:43 time=1643031403.866960 func=IdMap                    level=INFO  logid=static.............................. unit=mgm@alice21.spbu.ru:1094 tid=00007f0874afa700 source=Mapping:1042                   tident= sec=(null) uid=99 gid=99 name=- geo="" sec.prot=gsi sec.name="/C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev" sec.host="v009.pnpi.nw.ru" sec.vorg="spd.nica.jinr" sec.grps="/spd.nica.jinr" sec.role="" sec.info="/C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev" sec.app="" sec.tident="zar.14333:122@v009.pnpi.nw.ru" vid.uid=1219200014 vid.gid=7000

Here we can clearly see properly filled VOMS attributes: sec.vorg=“spd.nica.jinr” sec.grps="/spd.nica.jinr"

However, if we do exactly the same from the job on the worker node, which uses a proxy certificate delegated by ARC, we face a problem:

-bash-4.2$ cat eostest.sh
#/bin/sh!
DST=$1
voms-proxy-info -all;
rpm -qf `which xrdcp`;
rpm -qa `which voms-proxy-info`
echo $DST
OUTFILE=fileb$RANDOM
xrdcp -f -p /etc/passwd ${DST}/$OUTFILE;
echo END;

-bash-4.2$ cat eostestspb_spd.xrsl
&( executable = "eostest.sh" )(runTimeEnvironment = "ENV/PROXY")(Arguments = "root://alice21.spbu.ru://eos/spbcloud/spd/mainpool/")( jobname = "eos test" )( stdout = "std.out" )( join = "yes" )( gmlog = "gmlog" )(outputFiles = ("std.out" ""))

-bash-4.2$  
-bash-4.2$ arcsub eostestspb_spd.xrsl -c v012.pnpi.nw.ru
Job submitted with jobid: gsiftp://v012.pnpi.nw.ru:2811/jobs/QgxKDm1qEW0nHpSrzpghF0noABFKDmABFKDmxEKKDmABFKDmPN9fNo
-bash-4.2$

Result:

-bash-4.2$ cat QgxKDm1qEW0nHpSrzpghF0noABFKDmABFKDmxEKKDmABFKDmPN9fNo/std.out
subject   : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=579999927/CN=1413062767
issuer    : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=579999927
identity  : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=579999927
type      : RFC compliant proxy
strength  : 1024 bits
path      : /scratch/localscratch/QgxKDm1qEW0nHpSrzpghF0noABFKDmABFKDmxEKKDmABFKDmPN9fNo/user.proxy
timeleft  : 9:12:53
key usage : Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
=== VO spd.nica.jinr extension information ===
VO        : spd.nica.jinr
subject   : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev
issuer    : /C=RU/O=RDIG/OU=hosts/OU=jinr.ru/CN=lcgvoms01.jinr.ru
attribute : /spd.nica.jinr/Role=NULL/Capability=NULL
timeleft  : 9:12:53
uri       : lcgvoms01.jinr.ru:15003
xrootd-client-5.2.0-1.el7.x86_64
root://alice21.spbu.ru://eos/spbcloud/spd/mainpool/
[0B/0B][100%][==================================================][0B/s]
Run: [ERROR] Server responded with an error: [3010] Unable to open file /eos/spbcloud/spd/mainpool/fileb30315; Operation not permitted (destination)

END
-bash-4.2$

Transfer fails with permission error, and on a server side VOMS attributes are empty.

Server:

from /var/log/eos/mgm/xrdlog.mgm:
…………………………
220124 16:46:45 15113 secgsi_XrdOucGMap::load: map information up-to-date: no need to load
220124 16:46:45 15113 secgsi_XrdOucGMap::dn2user: no valid match found for DN '/C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev'
220124 16:46:45 15113 secgsi_Authenticate: username(s) associated with this DN:
220124 16:46:45 15113 secgsi_Authenticate: WARNING: user mapping lookup failed - use DN or DN-hash as name
220124 16:46:45 15113 cryptossl_X509GetVOMSAttr: found extension '2.5.29.15'
220124 16:46:45 15113 cryptossl_X509GetVOMSAttr: found extension '1.3.6.1.5.5.7.1.14'
220124 16:46:45 15113 secgsi_ExtractVOMS: No VOMS attributes in proxy chain
220124 16:46:45 15113 secgsi_Authenticate: VOMS: Entity.vorg:         <none>
220124 16:46:45 15113 secgsi_Authenticate: VOMS: Entity.grps:         <none>
220124 16:46:45 15113 secgsi_Authenticate: VOMS: Entity.role:         <none>
220124 16:46:45 15113 secgsi_Authenticate: VOMS: Entity.endorsements: <none>
……………………………………………
220124 16:46:45 15113 XrootdXeq: nicaspd0.16881:121@v014.pnpi.nw.ru pub IPv4 login as /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev
220124 16:46:45 time=1643032005.727642 func=IdMap                    level=INFO  logid=static.............................. unit=mgm@alice21.spbu.ru:1094 tid=00007f08749f9700 source=Mapping:1042                   tident= sec=(null) uid=99 gid=99 name=- geo="" sec.prot=gsi sec.name="/C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev" sec.host="v014.pnpi.nw.ru" sec.vorg="" sec.grps="" sec.role="" sec.info="/C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev" sec.app="" sec.tident="nicaspd0.16881:121@v014.pnpi.nw.ru" vid.uid=99 vid.gid=99

voms-proxy-info does not complain, but for some reason EOS fails to locate VOMS extension in a delegated proxy. Could you please help us to resolve this issue?

2

Hi Andrey,

I suspect that fact that the identity of the delegated proxy from inside the worker node is preventing the successful mapping in this case. Just for me to better understand how you are doing the mapping, do you also have an entry for /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev in your gridmap file? Do you have any voms mapping enabled on the eos side? Can you paste the output of eos vid ls?

Do you have some steps how to get such a delegated proxy certificate where the identity is the another proxy cert? I did not manage to do this myself, I managed to have a multiple delegated proxy cert but the identity is still the original identity from the certificate. Eg:

[esindril@esdss000 build_ninja_asan]$ voms-proxy-info --file /tmp/test-proxy1 --all
subject   : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=esindril/CN=706330/CN=Elvin Alin Sindrilaru/CN=1078866282/CN=658161570
issuer    : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=esindril/CN=706330/CN=Elvin Alin Sindrilaru/CN=1078866282
identity  : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=esindril/CN=706330/CN=Elvin Alin Sindrilaru
type      : RFC3820 compliant impersonation proxy
strength  : 2048
path      : /tmp/test-proxy1
timeleft  : 11:22:24
key usage : Digital Signature, Key Encipherment

While in your second case the identity is actually a previous proxy certificate:

subject   : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=579999927/CN=1413062767
issuer    : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=579999927
identity  : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=579999927
type      : RFC compliant proxy
strength  : 1024 bits

I think this might be the reason why the authentication fails in the second case. Note that in the first case the identity of the proxy cert is as expected (at least for me):

subject   : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=579999927
issuer    : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev
identity  : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev

If you have some steps of how to get from a cert to a mutiple delegated proxy like you get, I would be interested so that I can reproduce your issue.

Cheers,
Elvin

3

Hi Elvin,

You’re right, the second certificate, as mentioned, is a delegated one. That’s what ARC CE does when it runs a job on the worker node. The same was happening with a CREAM CE back in its days. The job ends up with a proxy signed by a proxy, which is perfectly fine.

What we’re trying to achieve is an authorization based entirely on VOMS attributes, without listing individual user’s DNs in the mapping.

4

Hi Andrey,

Just to better understand your setup. For the EOS instance you are using eos-4.8.63-some-commit with XRootD 4.8.12 (eos-xrootd)? You built this version yourself?
For the client part you are using XRootD client 5.2.0 (xrdcp) both for you test and inside the worker node? Is there any difference in the voms-clients-cpp package that you use from your node and the worker node?

Thanks,
Elvin

5

Hello!

Server:

[root@alice21 ~]# rpm -qa | grep eos
eos-fuse-4.8.62-1.el7.cern.x86_64
eos-client-4.8.62-1.el7.cern.x86_64
eos-testkeytab-4.8.40-1.el7.cern.x86_64
libmicrohttpd-0.9.38-eos.yves.el7.cern.x86_64
eos-fuse-core-4.8.62-1.el7.cern.x86_64
eos-citrine-repo-1-1.noarch
eos-folly-2019.11.11.00-1.el7.cern.x86_64
eos-fuse-sysv-4.8.62-1.el7.cern.x86_64
eos-protobuf3-3.5.1-5.el7.cern.eos.x86_64
bareos-common-19.2.7-2.el7.x86_64
bareos-filedaemon-19.2.7-2.el7.x86_64
eos-xrootd-4.12.8-1.el7.cern.x86_64
eos-folly-deps-2019.11.11.00-1.el7.cern.x86_64
eos-server-4.8.62-1.el7.cern.x86_64
[root@alice21 ~]# rpm -qa | grep xrootd
xrootd-client-5.2.0-1.el7.x86_64
xrootd-client-libs-5.2.0-1.el7.x86_64
xrootd-voms-5.2.0-1.el7.x86_64
xrootd-server-libs-5.2.0-1.el7.x86_64
eos-xrootd-4.12.8-1.el7.cern.x86_64
xrootd-server-5.2.0-1.el7.x86_64
xrootd-libs-5.2.0-1.el7.x86_64
[root@alice21 ~]# ll /etc/yum.repos.d/eos-citrine.repo
-rw-r--r-- 1 root root 364 Dec  7  2017 /etc/yum.repos.d/eos-citrine.repo
[root@alice21 ~]# cat /etc/yum.repos.d/eos-citrine.repo
[eos-citrine]
name=EOS binaries from EOS project, citrine branch
baseurl=http://cern.ch/storage-ci/eos/citrine/tag/el-$releasever/$basearch/
enabled=1
gpgcheck=1
priority=10

[eos-citrine-deps]
name=EOS dependencies from EOS project, citrine branch
baseurl=http://cern.ch/storage-ci/eos/citrine-depend/el-$releasever/$basearch/
enabled=1
gpgcheck=0
priority=10

[root@alice21 ~]#

EOS from Index of /eos/citrine repository. And I have 2 versions of xrootd without conflict. Eos use Index of /eos/citrine

Client local:

-bash-4.2$ rpm -qa | grep eos
eos-folly-deps-2019.11.11.00-1.el7.cern.x86_64
libmicrohttpd-0.9.38-eos.yves.el7.cern.x86_64
eos-xrootd-4.12.8-1.el7.cern.x86_64
eos-libmicrohttpd-0.9.38-eos.el7.cern.x86_64
eos-protobuf3-3.5.1-5.el7.cern.eos.x86_64
eos-test-4.8.63-20210924154237git449f2b2.el7.cern.x86_64
eos-folly-2019.11.11.00-1.el7.cern.x86_64
eos-server-4.8.63-20210924154237git449f2b2.el7.cern.x86_64
eos-client-4.8.63-20210924154237git449f2b2.el7.cern.x86_64
-bash-4.2$ rpm -qa | grep xrootd
xrootd-client-5.2.0-1.el7.x86_64
eos-xrootd-4.12.8-1.el7.cern.x86_64
xrootd-client-libs-5.2.0-1.el7.x86_64
xrootd-libs-5.2.0-1.el7.x86_64
-bash-4.2$ rpm -qa | grep voms
voms-2.0.16-1.el7.x86_64
wlcg-voms-dteam-1.0.0-1.el7.noarch
voms-clients-cpp-2.0.16-1.el7.x86_64
wlcg-voms-atlas-1.0.0-1.el7.noarch
wlcg-voms-alice-1.0.0-1.el7.noarch
-bash-4.2$   
-bash-4.2$
-bash-4.2$ yum info eos-client
Loaded plugins: fastestmirror, langpacks, priorities, versionlock
Loading mirror speeds from cached hostfile
 * epel: mirror.datacenter.by
 * remi-php70: mirror.awanti.com
 * remi-safe: mirror.awanti.com
2700 packages excluded due to repository priority protections
Excluding 6 updates due to versionlock (use "yum versionlock status" to show them)
Installed Packages
Name        : eos-client
Arch        : x86_64
Version     : 4.8.63
Release     : 20210924154237git449f2b2.el7.cern
Size        : 105 M
Repo        : installed
From repo   : eos-citrine-storage-ci-commit
Summary     : The EOS shell client
License     : none
Description : The EOS shell client.

Available Packages
Name        : eos-client
Arch        : x86_64
Version     : 5.0.2
Release     : 1.el7.cern
Size        : 27 M
Repo        : UMD-4-updates/x86_64
Summary     : The EOS shell client
License     : none
Description : The EOS shell client.

-bash-4.2$ cat /etc/yum.repos.d/eos.repo
[eos-citrine-storage-ci]
name=EOS 4.0 Version CI
baseurl=http://storage-ci.web.cern.ch/storage-ci/eos/citrine/tag/el-7/$basearch/
gpgcheck=0

[eos-dep-storage-ci]
name=EOS Aquamarine Dependencies CI
baseurl=http://storage-ci.web.cern.ch/storage-ci/eos/citrine-depend/el-7/$basearch/
gpgcheck=0

[xrootd-cern]
name=Xrootd from cern
baseurl=http://xrootd.cern.ch/sw/repos/stable/slc/7/x86_64/
gpgcheck=0


[eos-citrine-storage-ci-commit]
name=EOS 4.0 commit
baseurl=http://storage-ci.web.cern.ch/storage-ci/eos/citrine/commit/el-7/$basearch/
gpgcheck=0


-bash-4.2$

EOS from CERN repository some time ago.
Client on WN:

[root@v014 ~]# rpm -qa | grep eos
[root@v014 ~]# rpm -qa | grep xrootd
xrootd-server-devel-5.2.0-1.el7.x86_64
xrootd-libs-5.2.0-1.el7.x86_64
xrootd-devel-5.2.0-1.el7.x86_64
xrootd-client-libs-5.2.0-1.el7.x86_64
xrootd-client-5.2.0-1.el7.x86_64
xrootd-client-devel-5.2.0-1.el7.x86_64
xrootd-server-libs-5.2.0-1.el7.x86_64
gfal2-plugin-xrootd-2.18.2-2.el7.x86_64
xrootd-server-5.2.0-1.el7.x86_64
[root@v014 ~]# rpm -qa | grep voms
lcmaps-plugins-voms-1.7.1-1.el7.x86_64
wlcg-voms-atlas-1.0.0-1.el7.noarch
voms-devel-2.0.14-1.el7.x86_64
wlcg-voms-ops-1.0.0-1.el7.noarch
wlcg-voms-dteam-1.0.0-1.el7.noarch
voms-2.0.14-1.el7.x86_64
wlcg-voms-alice-1.0.0-1.el7.noarch
voms-clients-cpp-2.0.14-1.el7.x86_64
[root@v014 ~]#
6 
[root@alice21 ~]# eos ns | grep master-rw
ALL      Replication                      mode=master-rw state=master-rw master=alice21.spbu.ru configdir=/var/eos/config/alice21.spbu.ru/ config=default
[root@alice21 ~]# eos vid ls
gsi:"/alice:":gid => alice
gsi:"/alice:":uid => alice
gsi:"<pwd>":gid => root
gsi:"<pwd>":uid => root
krb5:"<pwd>":gid => root
krb5:"<pwd>":uid => root
publicaccesslevel: => 1024
sss:"<pwd>":gid => root
sss:"<pwd>":uid => root
sudoer                 => uids()
voms:"/alice/Role=lcgadmin/Capability=NULL:":gid => alice
voms:"/alice/Role=lcgadmin/Capability=NULL:":uid => alice
voms:"/alice/Role=lcgadmin:":uid => alice
voms:"/alice/lcg1:":uid => alice
voms:"/alice:":gid => alice
voms:"/alice:":uid => alice
voms:"/mpd.nica.jinr:":gid => mpd
voms:"/mpd.nica.jinr:":uid => mpd
voms:"/spd.nica.jinr:":gid => spd
voms:"/spd.nica.jinr:":uid => spd
[root@alice21 ~]# cat /etc/grid-security/grid-mapfile
"/alice/Role=production/Capability=NULL" alice
"/alice/Role=production" alice
"/alice/Role=lcgadmin/Capability=NULL" alice
"/alice/Role=lcgadmin" alice
"/alice/Role=NULL/Capability=NULL" alice
"/alice/Role=NULL" alice
"/alice" alice
"/alice/lcg1/Role=NULL/Capability=NULL" alice
"/mpd.nica.jinr/Role=NULL/Capability=NULL" mpd
"/mpd.nica.jinr" mpd
"/spd.nica.jinr/Role=NULL/Capability=NULL" spd
"/spd.nica.jinr" spd
[root@alice21 ~]#

I can add your VO for your authorization. But what is your VO?

7

Hi Andrey,

Thanks for all the info. At this point, I think we need to involve Michal who has more experience on the XRootD side. He’s on holidays until Thu so let’s wait until then.

Thanks,
Elvin

8

Hi Andrey,

Could you provide us with a certificate fro which the server fails to extract the VOMS attributes? Alternatively, could you give us instructions on how to generate such a certificate?

Cheers,
Michal

9

Hello, Michal!
proxy
or
https://cernbox.cern.ch/index.php/s/6un22WgzEWIHyIt

password - 000

10

Or you can submit simple xrsl script on any ARC6:

-bash-4.2$ cat getproxy.xrsl
&( executable = "getproxy.sh" )(runTimeEnvironment = "ENV/PROXY" "ENV/GLITE")( jobname = "getproxy" )( stdout = "stdout" )( join = "yes" )( gmlog = "gmlog" )(outputFiles = ("proxy" ""))
-bash-4.2$ cat getproxy.sh
#!/bin/sh
cat $X509_USER_PROXY > ./proxy

-bash-4.2$

Submit as in the example:

-bash-4.2$ arcsub getproxy.xrsl -c v012.pnpi.nw.ru
ERROR: Failed to establish connection: TCP: GENERIC_ERROR (Failed to connect to v012.pnpi.nw.ru(IPv4):443)
ERROR: Failed to establish connection: TCP: GENERIC_ERROR (Failed to connect to v012.pnpi.nw.ru(IPv4):443)
Job submitted with jobid: gsiftp://v012.pnpi.nw.ru:2811/jobs/D0LKDmNLBa0nHpSrzpghF0noABFKDmABFKDmVKGKDmABFKDmFqAsVn
-bash-4.2$

Get results:

-bash-4.2$ arcstat gsiftp://v012.pnpi.nw.ru:2811/jobs/D0LKDmNLBa0nHpSrzpghF0noABFKDmABFKDmVKGKDmABFKDmFqAsVn
Job: gsiftp://v012.pnpi.nw.ru:2811/jobs/D0LKDmNLBa0nHpSrzpghF0noABFKDmABFKDmVKGKDmABFKDmFqAsVn
 Name: getproxy
 State: Finished
 Exit Code: 0

Status of 1 jobs was queried, 1 jobs returned information
-bash-4.2$ arcget gsiftp://v012.pnpi.nw.ru:2811/jobs/D0LKDmNLBa0nHpSrzpghF0noABFKDmABFKDmVKGKDmABFKDmFqAsVn
Results stored at: D0LKDmNLBa0nHpSrzpghF0noABFKDmABFKDmVKGKDmABFKDmFqAsVn
Jobs processed: 1, successfully retrieved: 1, successfully cleaned: 1
-bash-4.2$ voms-proxy-info --file D0LKDmNLBa0nHpSrzpghF0noABFKDmABFKDmVKGKDmABFKDmFqAsVn/proxy --all
subject   : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=4278166138/CN=16797790
issuer    : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=4278166138
identity  : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev/CN=4278166138
type      : RFC compliant proxy
strength  : 1024 bits
path      : D0LKDmNLBa0nHpSrzpghF0noABFKDmABFKDmVKGKDmABFKDmFqAsVn/proxy
timeleft  : 11:45:30
key usage : Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
=== VO spd.nica.jinr extension information ===
VO        : spd.nica.jinr
subject   : /C=RU/O=RDIG/OU=users/OU=spbu.ru/CN=Andrey Zarochentsev
issuer    : /C=RU/O=RDIG/OU=hosts/OU=jinr.ru/CN=lcgvoms01.jinr.ru
attribute : /spd.nica.jinr/Role=NULL/Capability=NULL
timeleft  : 11:45:30
uri       : lcgvoms01.jinr.ru:15003
-bash-4.2$

If you will tell me the name of your VO, I can add this VO to arc-CE v012.pnpi.nw.ru on a short time for your test.

11

Hi Andrey,

Thanks a lot for the proxy certs and the instructions! I will give it a try on Monday morning!

Cheers,
Michal

12

Hi Andrey,

Sorry for the delay, hmm I suppose we could use dteam but I would need to renew my membership. Could you possibly generate the proxy once again with a prolonged expiration time? If you are not comfortable with that I will get the membership in the dteam vo, let me know!

Thanks,
Michal

13

Hello, Michal!

  1. I sent you a new proxy in a private message.
  2. I added vo “dteam” to CREAM-CE v012.pnpi.nw.ru - can you check, please?
14

Just to summarise last week activity (which has been interrupted by my sick leave : / ):

  1. It took me a bit to configure a test setup, but it is working now.
  2. I tried authenticating with a proxy certificate Andrey provided (job.7XSKDmB7Kb0nHpSrzpghF0noABFKDmABFKDmlEHKDmABFKDmHMmCSo.proxy) and from what I see in the logs the voms attributes were correctly extracted:
220208 16:27:50 10107  XrdVomsFun: retrieval successful
220208 16:27:50 10107  XrdVomsFun: found VO: spd.nica.jinr
220208 16:27:50 10107  XrdVomsFun:  ---> group: '/spd.nica.jinr', role: 'NULL', cap: 'NULL'
220208 16:27:50 10107  XrdVomsFun:  ---> fqan: '/spd.nica.jinr/Role=NULL/Capability=NULL'
220208 16:27:50 10107 secgsi_Authenticate: VOMS: Entity.vorg:         spd.nica.jinr
220208 16:27:50 10107 secgsi_Authenticate: VOMS: Entity.grps:         /spd.nica.jinr
220208 16:27:50 10107 secgsi_Authenticate: VOMS: Entity.role:         NULL
220208 16:27:50 10107 secgsi_Authenticate: VOMS: Entity.endorsements: /spd.nica.jinr/Role=NULL/Capability=NULL

Just for the record this is what I have in my /etc/grid-security :slight_smile:

$ ls  /etc/grid-security/vomses/
spd.nica.jinr
$ ls  /etc/grid-security/vomsdir/spd.nica.jinr/
lcgvoms01.jinr.ru.lsc

and this is the GSI config:

xrootd.seclib default
sec.protocol  gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/xrdcert.pem -key:/etc/grid-security/xrd/xrdkey.pem -vomsfun:default -vomsat:extract -gridmap:/etc/grid-security/grid-mapfile -vomsfunparms:dbg -crl:0 -d:2 -gmapopt:11  -gmapto:60  -moninfo:1

My question now is job.7XSKDmB7Kb0nHpSrzpghF0noABFKDmABFKDmlEHKDmABFKDmHMmCSo.proxy the same proxy that gives you problems when trying to access EOS?

15

Is it from the MGM log? Fine! Can you show your MGM setting? (EOS version, gsi setting)

Yes.

16

No, this was with vanilla XRootD (5.4.0) to see if this is an XRootD or EOS problem. That said, it is strange as authentication and voms extraction is provided by Xrootd framework.

Here’s the gsi config:

xrootd.seclib default
sec.protocol  gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/xrdcert.pem -key:/etc/grid-security/xrd/xrdkey.pem -vomsfun:default -vomsat:extract -gridmap:/etc/grid-security/grid-mapfile -vomsfunparms:dbg -crl:0 -d:2 -gmapopt:11  -gmapto:60  -moninfo:1

could you please verify if you use the same one and that you have correctly set-up the

$ ls  /etc/grid-security/vomses/
spd.nica.jinr
$ ls  /etc/grid-security/vomsdir/spd.nica.jinr/
lcgvoms01.jinr.ru.lsc

In the meanwhile I will check if this problem could have been fixes between 4.12.x and 5.4.x.

17

I have slightly another configuration:

On client:

-bash-4.2$ ls -l  /etc/grid-security/vomsdir/spd.nica.jinr/*
-rw-r--r-- 1 root root 101 Jan 12 17:38 /etc/grid-security/vomsdir/spd.nica.jinr/lcgvoms01.jinr.ru.lsc
-rw-r--r-- 1 root root 101 Jan 12 17:38 /etc/grid-security/vomsdir/spd.nica.jinr/lcgvoms02.jinr.ru.lsc
-bash-4.2$ ls -l  /etc/vomses/spd.nica.jinr-lcgvoms0*
-rw-r--r-- 1 root root 116 Jan 12 18:21 /etc/vomses/spd.nica.jinr-lcgvoms01.jinr.ru
-rw-r--r-- 1 root root 116 Jan 18 00:58 /etc/vomses/spd.nica.jinr-lcgvoms02.jinr.ru
-bash-4.2$

And same on server:

dvl-eos-m01:~ # ls -l  /etc/grid-security/vomsdir/spd.nica.jinr/*
-rw-r--r-- 1 root root 101 Feb  7  2017 /etc/grid-security/vomsdir/spd.nica.jinr/lcgvoms01.jinr.ru.lsc
-rw-r--r-- 1 root root 101 May 17  2019 /etc/grid-security/vomsdir/spd.nica.jinr/lcgvoms02.jinr.ru.lsc
dvl-eos-m01:~ # ls -l  /etc/vomses/spd.nica.jinr-lcgvoms0*
-rw-r--r-- 1 root root 116 Jun  6  2019 /etc/vomses/spd.nica.jinr-lcgvoms01.jinr.ru
-rw-r--r-- 1 root root 116 Jun  6  2019 /etc/vomses/spd.nica.jinr-lcgvoms02.jinr.ru
dvl-eos-m01:~ #