Hi Stephen,
            Thanks for looking into this - much appreciated.
Now I understand it a bit more what is going on.

I can see in my argus server log files that the mapping is wrong,
but don't know why. My entries in the grid-mapfile for biomed
is similar to the ones for ops, and yet ops with role=lcgadmin
is being mapped correctly to opssgm, but biomed with role=lcgadmin
is being mapped to a normal biomed user (not the sgm account).

Unfortunately I don't belong to the biomed VO and can't get a proxy
with role=lcgadmin. I am currently only in the vo.southgrid.ac.uk
VO and is not allowed role=lcgadmin. My dteam membership has lapsed.
and can't seem to re-instate it.

Repeating the test, you did, of temporarily mapped all
vo.southgrid.ac.uk to an sgm account, and that works OK,
for me as well.

Thanks again.

krishan



On 20/10/15 16:18, Stephen Jones wrote:
> Hi Krishnan,
>
> I think 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 ran the command, I got  this (same as you did):
>
> # lcg-tags --verbose --debug --add --vo dteam --tags
> VO-dteam-abc123testin1212 --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-tagsD7AR42 failed
> lcg-tags: remote copy from /tmp/hKDvca4UCe to
> gsiftp://hepgrid5.ph.liv.ac.uk/opt/edg/var/info/dteam/lock failed
> lcg-tags: error: cannot create remote lockfile.
>
>
> NOTE: The _first_ message about "remote copy from blah failed" is bogus
> and misleading - the process worked OK. 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! An age old problem with software reuse. Anyway, that's the
> last I'll say 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 accounts map to a sgm
> (privileged) user (before there was a set of different accounts; now
> they all map to a .sgmdtm account, which 'has' lcgadmin.) It's reset now
> BTW.
>
> #  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.
>
> # lcg-tags --verbose --debug --add --vo dteam --tags VO-dteam-abc145
> --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-tagsRjwRaP failed
> #
>
> So that's what happened. If you can get a biomed proxy with
> "Role=lcgadmin", check the grid-mapfile on your ARGUS server and make
> sure it's right. You can also use CREAM to check the mappings as they
> occur - this file shows it all, on CREAM.
>
> # tail -f  /var/log/globus-gridftp.log
>
> If it's wrong, then fix it in grid-mapfile (perhaps using yaim.) If it's
> right, then the account the user maps to is not permitted to write the
> file. Don't know why yet - that's another bit of debugging to find out.
>
> Cheers,
>
>
> Steve
>
>
> 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/