Hi Kai,
The default (at least in YAIM's examples and in YAIM Guide) is that prd/sgm
accounts has as a primary group their own group (e.g. for atlas it can be
prdatlas, remembering Maarten's warning that we should use prefix rule due to
possible problems with LCMAPS otherwise). Only the second group is VO group...
Best regards, Antun
-----
Antun Balaz
Research Assistant
E-mail: [log in to unmask]
Web: http://scl.phy.bg.ac.yu/
Phone: +381 11 3713152
Fax: +381 11 3162190
Scientific Computing Laboratory
Institute of Physics, Belgrade, Serbia
-----
---------- Original Message -----------
From: Kai Neuffer <[log in to unmask]>
To: [log in to unmask]
Sent: Tue, 14 Aug 2007 15:14:19 +0200
Subject: Re: [LCG-ROLLOUT] decision taken in ops meeting
> Hi,
>
> I have another question related to this:
>
> What should be the primary group (the one in /etc/passwd) of the prd/sgm
pool user accounts (e.g. sgmat001/prdat001)?
>
> Should it be the group of the VO (e.g. atlas ) or the group sgmVO/prdVO (
eg. sgmat/prdat ), because in the first case some of the older storage systems
can continue the mapping to the 1st VO account, but in the second case not.
>
> Regards,
>
> Kai
>
> P.D.: Shorter
>
> /etc/group:
> atlas:x:1307:sgmat001,sgmat002,....,prdat001,prdat002....
> sgmat:x:1308:
> prdat:x:1309:
>
> /etc/passwd:
>
> prdat001:x:2001:1307:"VO ops pool account":/home/prdat001:/bin/bash ?
>
> OR
>
> prdat001:x:2001:1308:"VO ops pool account":/home/prdat001:/bin/bash ?
>
>
> El 14/08/2007, a las 13:59, Paul Trepka escribió:
> Hi,
>
> Liverpool is already prepared for taking jobs over groups pool account
> one thing is like we dont know which group will remained under the old
> mapping schema within the systems?
>
> Is there an obligation to VOs to take adequate actions for this matter
> to came to a similar to two major VOs?
>
> Thanks
>
> Cheers
> Paul
>
> On Tue, 14 Aug 2007, Jeff Templon wrote:
>
>
> Hi
>
> The move to pool accounts for the SGM and prod roles has been
> requested directly via the various security groups, who were acting on
> the sites' behalf. Typically the larger the site, the more they worried
> about this kind of stuff; it boils down to a traceability issue in case
> of a security incident.
>
> The move from "single accounts" to pool groups for these roles did
> not go smoothly, I agree.
>
> The SE is a completely different story. On most SEs, pool accounts
> are not used like this. For example DPM has its own internal mapping
> tables. There are a number of unresolved issues with SE access (NIKHEF
> just submitted a new one yesterday to GGUS!), the GSSD group (contact
> Flavia or Maarten) or the TCG (you have a representative) are following
> the SE access issues.
>
> JT
>
> Joel Closier wrote:
> Hello,
>
> Is it possible to know who request this ? and what is the motivation to
> move into this direction.
>
> I spend one month to figth with sites when the SGM account for LHCb
> became a pool account (problem of permissions, essentially) because site
> forget to consider that the permission for writing should be different
> and more open when you have a pool account than when you have a single
> account. So if it is really the direction that you want to follow, what
> are the plan for the Storage Element ??? Because if we move to pool
> account, it means hat you need to have at least WRITE permission to the
> group of pool account on each SE ... and it should be done by all the
> sites and not that the users has to discover that the permission are not
> anymore correct and complain through GGUS.
>
> Regards.
>
> Joel.
>
> ----------------------------------------------------------------
> CLOSIER Joel \|/
> (o o)
> -------------------oOO**(_)**OOo--------------------------------
> Phone : (+41 22 767) 71 72 Fax : +41 22 766 99 78
> GSM : (+41 76 487) 03 81 E-mail : [log in to unmask]
> <mailto:[log in to unmask]>
> ----------------------------------------------------------------
> CERN | ("`-''-/").___..--''"`-._
> Bg 2-R-001 | `6_ 6 ) `-. ( ).`-.__.`)
> ch 1211 | (_Y_.)' ._ ) `._ `. ``-..-'
> Geneva 23 | _..`--'_..-_/ /--'_.' ,'
> Switzerland /|\ (il),-'' (li),' ((!.-'
> ----------------=====oooooooooo=====----------------------------
>
> Le 9 août 07 à 09:41, Jeff Templon a écrit :
>
>
> Hi *,
>
> I saw this message about a decision taken in the ops meeting:
>
> At the Grid Operations meeting of Monday 6th August (agenda:
> http://indico.cern.ch/conferenceDisplay.py?confId=19740), a decision
> was reached by the attending ROCs, sites and VOs which will
> potentially effect all VOs.
> The decision was that by default all sites will configure themselves
> such that all VOs will be provided with pool accounts for the PRD and
> SGM roles.
>
> I was not at that meeting (still on vacation) but I hope this is what
> was meant:
>
> "by default, all sites will configure themselves such that all VOs
> *requesting SGM and PRD functionality* will get pools of accounts for
> these roles. "
>
> Not all VOs want or need SGM/PRD functionality and if they do not need
> it, we prefer not to create and configure the accounts.
>
> The message went further to state that if a VO wished to have a
> *single* account for PRD or SGM instead of pools, they should specify
> this. Note that there is no guarantee that this request will be
> respected by all sites.
>
> JT
>
>
>
>
>
> --
>
> Dr. Paul A. Trepka ;Intl:+44(0)151 794 2137
> Oliver Lodge Laboratory ;Fax: +44(0)151 794 3444
> Dept. of Physics ;e-mail: [log in to unmask]
> The University of Liverpool
> Liverpool L69 7ZE
> England, UK
>
>
> ----------------------------------------------------------------------
> Dr. Kai Neuffer
>
> EGEE II Federation ROC Manager SW
>
> Port d'Informació Científica
> Campus UAB
> Edifici D
> E-08193 Bellaterra, Spain
>
> Tel: (+34) 93 581 3773
> Tel Mov: (+34) 676 408 741
> Fax: (+34) 93 581 41 10e-mail: [log in to unmask], [log in to unmask]
>
> -----------------------------------------------------------------------
> IFAE provides the e-mail service used by PIC and
> requires the following notice:
>
> http://www.ifae.es/legal.html
>
> ----------------------------------------------------------------------
------- End of Original Message -------
|
