Hi Stephen,
What about the situation where a user gets a proxy for
different roles. Sometimes as a normal user (default Role) and sometimes
with Role=lcgadmin. Will they have 2 different entries in
/etc/grid-security/gridmapdir/
This is what is happening in our case. The biomed users uses different
roles for different jobs, using their DN.
I can't see multiple mappings in /gridmapdir/ for them.
There is only one mapping.
E.g, I can see this only mapping for the biomed user
36664 -rw-r--r-- 2 root root 0 Oct 21 09:00 bio012
36664 -rw-r--r-- 2 root root 0 Oct 21 09:00
%2fo%3dgrid%2dfr%2fc%3dfr%2fo%3dcnrs%2fou%3di3s%2fcn%3dfranck%20michel:biomed
This would be his normal/default role mapping. But when he comes
in as role=lcgadmin, (with the same user DN) should that create a
different entry in /gridmapdir/?
Also looking in /gridmapdir/, I can't see any *sgm entries, even
for opssgm (which currently runs jobs regularly on our system).
Do you have *sgm entries in your /gridmapdir/ directoty?
Many Thanks
krishan
On 20/10/15 17:50, Stephen Jones wrote:
> 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/
>
>
|
