I seem to remember one VO running lots of jobs as lcgadmin which resulted in lots of simultaneous RW NFS sessions to the shared software area which caused performance problems.
From: Testbed Support for GridPP member institutes [mailto:[log in to unmask]] On Behalf Of Christopher J. Walker
Sent: 06 June 2011 21:47
To: [log in to unmask]
Subject: Re: lcgadmin role
On 06/06/11 15:18, Jonathan Perkin wrote:
> please can you clarify the capabilities of the lcgadmin role?
The lcgadmin role has the privileges given to it by the site admin (and
requested by the VO in the cic portal).
The LHC VOs use the lcgadmin role for managing the software area.
They use the production role as a privileged user who can write/delete
files from the SE - to prevent normal users deleting (or even worse
changing) all the data - either by design, or more likely by accident.
Other pool accounts are in principle possible - but personally, I'd
think carefully about why you want to do different from the LHC VOs.
> For instance, as an lcgadmin I can modify (read/write lfc-chown,
> lfc-set-acl etc) files produced by a user with the production role,
That's dependent on how the lfc is setup. Personally, I think you'd be
well advised to do as the LHC VOs do and use the production role for
data management, not the lcgadmin role.
> but I cannot however modify content created by another user who used
> the lcgadmin role. So one lcgadmin cannot seemingly change the permissions
> of files created by another lcgadmin - is this correct?
In the LFC, on the SE, or in the software area?
If in the software area,
may be helpful. Basically with sgm pool accounts, all sgm users are in
the same group.
The LFC is outside my knowledge and the SE - well what's wrong with the
IOW I'd suggest:
production: data management and monte carlo
normal user: normal user analysis.
 This is a prompt for other sysadmins to disagree. I can see that
there's perhaps an argument for a data management user that is slightly
more privileged than a production user.