Hi Krishan,
On 10/20/2015 05:27 PM, Purahoo, Krishan wrote:
> 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).
Once a mapping has been made, it is stored in
/etc/grid-security/gridmapdir (different entirely to grid-mapfile etc.)
Once it is stored it is fixed. It is never removed by any normal
process. I suspect that biomed/role=lcgadmin is mapped wrongly and it
will stick that way.
You need to unmap it. To do that, cd to /etc/grid-security/gridmapdir on
your ARGUS server. Then read the
description of the mapping cache, below, and break the link.
Once you've done that, try it again.
Cheers,
Steve
------- DESCRIPTION OF HOW MAPPING CACHE WORKS -----------
The mapping cache is /etc/grid-security/gridmapdir
In that directory, an empty file exists representing every possible
local user on your cluster. One per user.
The files have names like dteam001, dteam002 .... dteam050 etc. or whatever.
When a credential is mapped to a local user, it is recorded in this
directory.
To record it, a hard link is made to one of the empty file (dteam... or
whatever).
This is done by 'sharing an inode', so that two files point to the same
place on the disk.
One of the files represents the local user. The other file link to the
same inode represents the credential of the person who is mapped to that
account.
On my system, I can see what user I am mapped to like so.
# cd /etc/grid-security/gridmapdir
# ls -lrti | grep jones
106527 -rw-r--r-- 2 root root 0 Oct 20 17:45
%2fc%3duk%2fo%3descience%2fou%3dliverpool%2fl%3dcsd%2fcn%3dstephen%20jones:dteam
# ls -lrti | grep 106527
106527 -rw-r--r-- 2 root root 0 Oct 20 17:45 dteam072
106527 -rw-r--r-- 2 root root 0 Oct 20 17:45
%2fc%3duk%2fo%3descience%2fou%3dliverpool%2fl%3dcsd%2fcn%3dstephen%20jones:dteam
So I'm dteam072. Obviously you can do the reverse operation to find what
user is mapped to which local account.
You can break the link like this:
# rm
%2fc%3duk%2fo%3descience%2fou%3dliverpool%2fl%3dcsd%2fcn%3dstephen%20jones:dteam
Next time you come in, you'll be remapped. You may end up with the same
user, or another one.
-------------------------------------------------------------------------------------
>
>
> 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/
--
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/
|