Hi Krishnan,
You're on the right track with what you said before. I had the exact
same problem as you, but I've "fixed" it for me, I hope it helps you to
fix yours. When I run the command now, I got this (same as you):
# lcg-tags --verbose --debug --add --vo dteam --tags VO-dteam-abc123
--ce hepgrid5.ph.liv.ac.uk
VO: dteam
Endpoint: gsiftp://hepgrid5.ph.liv.ac.uk/opt/edg/var/info/dteam
lcg-tags: remote copy from
gsiftp://hepgrid5.ph.liv.ac.uk/opt/edg/var/info/dteam/lock to
/tmp/lcg-tagsNjr5l2 failed
#
NOTE: The message about "remote copy from blah failed" is completely
bogus and misleading - the process worked perfectly. The "error" comes
about because they use a general purpose routine to copy a lock file
back. If it can't get one, it's a good thing, because nothing else is
accessing the locked resource, but the general purpose copy routine
doesn't know that so it complains that it has 'failed' when it has
actually done the exact opposite! Anyway, that's the last I'll say for
now about that bogus output, (although I should raise a ticket to be
honest.)
Moving on ... I could not get a dteam proxy with the lcgadmin resource
(I'm not allowed one) which was a bother. So I changed the entries in my
ARGUS config like this so that ALL dteam acconts map to a sgm
(prividleged) user (before there was a set of diffeent accounts, now
they all map to the .sgmdtm account, which 'has' lcgadmin). It's verging
on hacking, but it's OK for debugging.
# cat /etc/grid-security/grid-mapfile | grep dteam
"/dteam/sgm/Role=NULL/Capability=NULL" .sgmdtm
"/dteam/sgm" .sgmdtm
"/dteam/lcgprod/Role=NULL/Capability=NULL" .sgmdtm
"/dteam/lcgprod" .sgmdtm
"/dteam/Role=lcgadmin/Capability=NULL" .sgmdtm
"/dteam/Role=lcgadmin" .sgmdtm
"/dteam/Role=production/Capability=NULL" .sgmdtm
"/dteam/Role=production" .sgmdtm
"/dteam/Role=NULL/Capability=NULL" .sgmdtm
"/dteam" .sgmdtm
"/dteam/*/Role=NULL/Capability=NULL" .sgmdtm
"/dteam/*" .sgmdtm
After I did that, the lcg-tags command worked for me.
So that's what happened. If you can get a biomed proxy with
"Role=lcgadmin", check the file mentioned on your ARGUS server and make
sure it's right. You can also use CREAM to check the mappings - this
file shows it all. tail -f /var/log/globus-gridftp.log
On 10/20/2015 09:59 AM, Purahoo, Krishan wrote:
> Hi,
> It seems that the mapping problem is somewhat fixed,
> to the extent that the user can login (run the gridftp command).
> However, it seems the correct mapping is not being done, and thus
> the lgc-tags operation fails.
>
> with the following errors:-
>
> ##
> lcg-tags --verbose --debug --add --vo $VO --tags $TAG --ce
> grid002.jet.efda.org
>
> VO: biomed
>
> Endpoint: gsiftp://grid002.jet.efda.org/opt/edg/var/info/biomed
>
> lcg-tags: remote copy from
> gsiftp://grid002.jet.efda.org/opt/edg/var/info/biomed/lock to
> /tmp/lcg-tagsohsVLa failed
>
> lcg-tags: remote copy from /tmp/vZO9WHVbVc to
> gsiftp://grid002.jet.efda.org/opt/edg/var/info/biomed/lock failed
>
> lcg-tags: error: cannot create remote lockfile.
> ##
>
> The user is coming in as Role=lcgadmin, and I was expecting it to
> get mapped to the sgm account (biomedsgm), which have the correct
> permissions for /opt/edg/var/info/biomed/. However, the user is
> being mapped to a normal biomed account (bioNNN).
>
> Proxy info for user, shows the following attribute
>
> attribute : /biomed/Role=lcgadmin/Capability=NULL
>
> How do I get the biomed DN with Role=lcgadmin to be mapped
> to biomedsgm.
>
> This is what I now have in my grid-mapfile on Argus
>
> "/biomed/Role=lcgadmin/Capability=NULL" biomedsgm
> "/biomed/Role=lcgadmin" biomedsgm
> "/biomed/Role=production/Capability=NULL" biomedprd
> "/biomed/Role=production" biomedprd
> "/biomed/Role=NULL/Capability=NULL" .bio
> "/biomed" .bio
>
>
> Many Thanks
>
> krishan
--
Steve Jones [log in to unmask]
Grid System Administrator office: 220
High Energy Physics Division tel (int): 43396
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 3396
University of Liverpool http://www.liv.ac.uk/physics/hep/
|