Good. That was about where I might have looked next.
You may also be interested in the attached tar file, which I use to
support ~ 30 VOs.
We use the script (and data file) to maintain our products for user
admin for torque/maui and arc/condor.
You can check if they could be of use to you. You invoke the software
like this:
./voconfig.py -c vo_data.conf
It writes out the new files and sections of file in the current dir. The
are specific to us, but they can be customised.
It stops me leaving (say) biomedsgm and biomedprd account definitions
from the users.conf file when I add a new VO.
Cheers,
Steve
On 10/13/2015 09:20 AM, Purahoo, Krishan wrote:
> Hi Steve,
> I think I might have found my problem, concerning the
> missing mappings.
> The biomedsgm and biomedprd account definitions were missing
> in our users.conf file. Definining these and re-yaiming, now
> shows the required entries in the grid-mapfile.
> I will get the biomed user to run his job and see if it works
> now.
>
> Thanks again for your help.
>
> 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
>>
>>
--
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/
|