I've always advocated persistent pool account mappings. The point of the
pool is not to continually recycle so that you have fewer accounts than
users BUT to have a pool big enough for the number of different users
who land on your site. They should get an account mapped when they first
land and keep it forever (however forever is defined). This much more
acceptable than the alternative of creating accounts for every potential
user who may one day land on your site (the .AND. of all the VOs you
support).
John
-----Original Message-----
From: Testbed Support for GridPP member institutes
[mailto:[log in to unmask]] On Behalf Of Henry Nebrensky
Sent: 15 June 2009 20:28
To: [log in to unmask]
Subject: Re: QMUL Status 4th June 2009
>
> Surely the correct and simple solution to this (in principle - I'm not
> aware of any SRM implementation that does this) is to use a single
pool
> account mapping for a given user[1] across a whole site, so both
running
> jobs and storage access happen with the same mapped account.
I agree that this is probably the "correct" route, but it would have to
be the same mapping across the site - including multiple CEs and SEs -
AND
it would have to be permanent (otherwise you won't be able to access
your
file when you come back and get mapped to a different pool account).
The latter implies getting rid of the "pool" in pool accounts - I can't
remember where the last discussion on that finished up.
--
Scanned by iCritical.
|