Hi Steve,
Thanks for your reply. Yes, we do have an Argus server.
Looking in the logs, it seems the user mappings is done correctly.
When I did my uberftp tests, it all works OK, and the Argus logs
shows correct mappings.
For the case of the biomed user,
In the Argus logs, I can see that there were some mapping problems,
trying to map user to primary FQAN (/biomed/Role=lcgadmin).
This is what Stephen Burke indicated in his post, as well.
Now, how to I enable the role '/biomed/Role=lcgadmin'?
I do already have the following, defined in my groups.conf file
"/biomed/ROLE=lcgadmin":::sgm:
"/biomed/ROLE=production":::prd:
"/biomed"::::
But for some reason, my /etc/grid-security/grid-mapfile (on CE, Argus)
doesn't have the "/biomed/ROLE=lcgadmin" definition.
All I have in 'grid-mapfile' is the following, for biomed
"/biomed/Role=NULL/Capability=NULL" .bio
"/biomed" .bio
How do I get the '/biomed/ROLE=lcgadmin' definitions propagated
to my 'grid-mapfile'?
Is the 'groups.conf' file, the only place to do such configurations,
or is there some other configs needs to be done elsewhere?
Many Thanks
krishan
On 09/10/15 15:16, Stephen Jones wrote:
> Hi Krishan,
>
> On 10/08/2015 03:54 PM, Purahoo, Krishan wrote:
>> Looking in my /etc/grid-security/grid-mapfile on the CE, shows only
>> these entries for biomed
>>
>> "/biomed/Role=NULL/Capability=NULL" .bio
>> "/biomed" .bio
>
> I'd be careful there - most sites use ARGUS for that now. The
> grid-mapfile on the CE may not be relevant. Do you have an ARGUS server?
>
> In my imagination, I believe it now works something vaguely like this.
> When a CE gets a job, it wants to make sure the user's credentials are
> OK, and if they are, it wants to map the user to a local Unix account.
> It gets ARGUS to do this centrally. It passes the credential to ARGUS.
> ARGUS examines the credential and sees if it fits one of its policies.
> If it does, it tries to map the credential to a local account. If it all
> works, the result is sent back to the CE, which does the actual
> switching of accounts and sends the job to the batch server queue.
>
> Anyway, it's something like that. So all the security work gets done on
> ARGUS. So run the command and see what shows up in the ARGUS logs.
>
> Cheers,
>
> Steve
>
> PS: If you have (or can get) the proxy, you can test it like this on a
> CE (or a WN, using an e.g. pilot account).
>
> This is copied from my own notes.
>
> ------ TESTING ARGUS WITH A PROXY and GLEXEC -----------------------
>
> As root on the CE or WN, edit /etc/glexec.conf and put in a whitelist
> (unless it has it already) in this case for dteam, e.g.
>
> user_white_list = .dteam
>
> As root, copy in the proxy with scp to (say) /tmp/x509up_u460.test
>
> Change ownership of proxy to some account that exists.
>
> chown dteam001:dteam /tmp/x509up_u460.test
>
> Change permissions.
>
> chmod 600 /tmp/x509up_u460.test
>
> Switch to the user.
>
> su - dteam001
>
> Run these commands to setup for the test.
>
> export GLEXEC_CLIENT_CERT=/tmp/x509up_u460.test
> export GLEXEC_SOURCE_PROXY=/tmp/x509up_u460.test
> export X509_USER_PROXY=/tmp/x509up_u460.test
>
> Do the test.
>
> /usr/sbin/glexec /usr/bin/id
>
> If all is well, you will see something like this:
>
> uid=24683(abc184) gid=2028(abc) groups=2028(abc)
>
> If you don't see that, something is wrong. Check the ARGUS policies if
> it says "Not Applicable". Check the logs on the ARGUS server. Check the
> local logs.
>
> Take out the whitelist, for security reasons. And the proxy.
>
> Cheers,
>
> Steve
>
>
|