SgmPrdPoolAccounts < LCG

LCG Web>LCGGridDeployment>LcgDocs>SgmPrdPoolAccounts (2007-08-23, MaartenLitmaath) (raw view)
---+ How to switch to pool accounts for sgm/prd users

With =glite-yaim-3.0.1-22= and later it is possible to keep mapping
=sgm= and/or =prd= users to __static__ accounts, or to map either class
of users to its own set of __pool__ accounts.  This can be decided per
VO and per user class.  There are 2 node types that still enforce
static accounts by necessity: the ==VOBOX== and the =SE_castor=.
On those nodes one should keep the old static accounts instead of the
new pool accounts.

Pool accounts are preferred for at least 2 reasons:

   * Their audit trails are better defined.

   * They allow batch systems to give fair shares to the individual users in a class.

On any service node the mappings should only be changed when the
node is in scheduled maintenance and has been drained sufficiently.
For example, a CE, RB or WMS should typically be given a week for its
unfinished jobs to drain.  The exact period depends on the number of
unfinished jobs and the agreements with the relevant VOs: sometimes
it is acceptable for a number of jobs to be lost.

---+++ YAIM users.conf format

Static sgm/prd accounts have lines like these:
<verbatim>
33333:dteamprd:2688:dteam:dteam:prd:
18946:dteamsgm:2688:dteam:dteam:sgm:
</verbatim>

Sgm/prd pool accounts have lines like these:
<verbatim>
50501:prddtm01:2689,2688:dteamprd,dteam:dteam:prd
[...]
50519:prddtm19:2689,2688:dteamprd,dteam:dteam:prd
60501:sgmdtm01:2690,2688:dteamsgm,dteam:dteam:sgm
[...]
60559:sgmdtm59:2690,2688:dteamsgm,dteam:dteam:sgm
</verbatim>

YAIM will detect the situation per VO and per user class.

*NOTE:* include __either__ static __or__ pool accounts
(per VO, per user class), __not__ both.

This is further explained in the [[LcgDocs][YAIM documentation]].

---+++ Caveats

   * A site should only switch to __sgm pool accounts__ for VOs which
   have confirmed that their software installation procedures have
   been adapted to such pool accounts.  VOs should add the following
   logic to their software installation procedures: if the account running
   the installation happens to be an __sgm pool account__, then make
   all the newly installed files and directories group-writable.  For example:
   <verbatim>
        case `whoami` in
        *[0-9])
             chmod -R g+w $new_stuff
        esac
   </verbatim>

   * Due to a bug in YAIM, =/opt/edg/var/info/$VO/$VO.list= on the CE
   will have the wrong mode, thereby preventing the =lcg-ManageVOTags=
   and =lcg-tags= commands from updating the list of VO software tags
   published in the information system.  Work-around:
   <verbatim>
        chmod 664 /opt/edg/var/info/*/*.list
   </verbatim>
   This should only be done for VOs with __sgm pool accounts__.

   * The =sgm= and =prd= pool account __prefixes__ must *not* be extensions
   of the prefix for ordinary pool accounts, otherwise the LCG-CE will
   use the new accounts also for ordinary users.
   For example, if for a VO =test= the accounts for ordinary users
   are =test001 ... test199=, the =sgm= accounts must *not* be named
   =testsgm001= etc. because =testsgm= is an extension of =test=.
   Instead, they could be named =sgmtst01 ... sgmtst99= and the =prd=
   accounts =prdtst01 ... prdtst99=.
   It is advised to keep account names at most 8 characters long,
   otherwise utilities like =ps= will print UIDs instead of names,
   which may upset other tools or daemons.

   * In principle the __number__ of =sgm= and =prd= accounts should be much
   lower than the number of ordinary accounts for a VO, but for some
   VOs the current practice is different.  The minimum number of =sgm=
   and =prd= accounts needed per VO can be determined like this:
   <verbatim>
   awk '$NF ~ /(prd|sgm)$/ { print $NF }' /etc/grid-security/grid-mapfile |
   sort | uniq -c
   </verbatim>
   This assumes the static =sgm= and =prd= accounts have names ending in
   =sgm= and =prd= respectively.
   For the LHC VOs the current numbers are:
   <verbatim>
      3 aliceprd
     38 alicesgm
     44 atlasprd
     31 atlassgm
     56 cmsprd
     33 cmssgm
     16 dteamprd
     48 dteamsgm
     22 lhcbprd
      2 lhcbsgm
   </verbatim>
   Per mapping we suggest creating more accounts than the current value,
   to be on the safe side.  Unused pool accounts will be recycled as needed,
   but ideally they should not.  It is a good idea to check (via e.g. a cron job)
   periodically what fraction of the pool accounts are used, and send a mail
   when they are almost used up, e.g.:
   <verbatim>
Group(s) running out of available pool accounts:
prlhcb  :   23/  25
   </verbatim>
   The standard cron job =/etc/cron.d/lcg-expiregridmapdir= shows the current
   state of the pool accounts in =/var/log/lcg-expiregridmapdir.log=.  For example:
   <verbatim>
VO alice: inuse / total = 9 / 199 = 0.05, thr = 0.8
VO atlas: inuse / total = 153 / 199 = 0.77, thr = 0.8
VO prdatl: inuse / total = 5 / 99 = 0.05, thr = 0.8
VO cms: inuse / total = 153 / 199 = 0.77, thr = 0.8
VO dteam: inuse / total = 73 / 99 = 0.74, thr = 0.8
VO sgmdtm: inuse / total = 19 / 99 = 0.19, thr = 0.8
VO lhcb: inuse / total = 110 / 199 = 0.55, thr = 0.8
   </verbatim>
   Ideally the usage stays far below the threshold at which the least recently used
   accounts start being recycled.

-- Main.MaartenLitmaath - 12 Aug 2007
Topic revision: r4 - 2007-08-23 - MaartenLitmaath
LCG Wikis
LCG Service Coordination
LCG Grid Deployment
LCG Applications Area
Public webs
Welcome Guest
- Cern Search
- TWiki Search
- Google Search
LCG All webs