Hi Rich,

Yes, please lets see this at the workshop in December.  

Ian

> -----Original Message-----
> From: Rich Baker [mailto:[log in to unmask]] 
> Sent: 01 October 2003 16:22
> To: [log in to unmask]
> Subject: Re: [LCG-ROLLOUT] an issue on gridmapdir
> 
> 
> Emanuele,
> 
>     Thanks for reading our paper!  You do raise two
> important issues.  Yes, the total number of available
> UIDs on some (most?) systems is 64k, which in the
> very long term must be solved.  I don't think this
> is a problem for LHC, but it can be a problem for
> Grid in general which can be solved if operating
> systems increase the length of the UID from 16 to
> 32 bits.  A very long term issue, so we choose to
> acknowledge it without pressing for an immediate
> solution.  GUMS could also allow account recycling,
> so the problem can be solved in multiple ways if it
> does become a limit.
> 
> The information collection issue (Give me info on
> usage by all CMS users, for example) is potentially 
> troublesome, but this can be solved via relatively simple 
> procedures.  In the US Grid2003 deployment for example, all 
> ATLAS users are mapped to account that begin with a specific 
> prefix.  That allows the monitoring programs to aggregate 
> statistics for all accounts within a VO.  I don't think this 
> is the best strategy for the long term.  What needs to be 
> developed are effective site accounting tools that use the VO 
> information in the (extended) certificate to allocate the 
> usage against the correct VO.
> 
> GUMS and VOMS are actually very complimentary.  The
> current deployments of GUMS are using VOMS servers
> to obtain the list of users.  GUMS produces a different 
> grid-mapfile and logs account mapping information locally.  
> GUMS can use VOMS group membership info to maintain a local 
> user account's membership in local Unix groups.
> 
> The static one-to-one account mapping has several
> advantages.   One major consideration is that many
> sites (both in the US and Europe) have serious
> reservations about allowing group or pool account
> mapping.  The static mapping simplifies site audit
> procedures.  It also solves the file protection
> issues that started this thread.
> 
> I'll be happy to present and discuss GUMS at the
> User Registration/VO Management/AuthZ workshop
> that David Kelsey is organizing at CERN in December.
> 
> Rich Baker
> 
> Emanuele LEONARDI wrote:
> 
> > Thanks for pointing it: I managed to miss your presentation 
> at CHEP, 
> > so I was not aware of the tool.
> >
> > If I understand the way it works, the problem seems to be that one 
> > will get in any case a grid-mapfile with one entry per 
> user, something 
> > which can kill any attempt to collect info from multiple 
> CEs when the 
> > number of users grows over a few thousands (i.e. LHC scale). Maybe 
> > R-GMA could be more resistant to this effect, though.
> >
> > Also, again if I understood correctly the functioning of 
> the tool, it 
> > will use one local account per certificate, thus limiting 
> the maximum 
> > number of grid user ever to be accepted on a site to the 
> total number 
> > of available UIDs, something like 65536. This does not look 
> like a big 
> > limitation even for the LHC scale, but if one expects the 
> grid concept 
> > to grow, might be indeed too small.
> >
> > Please let me know if I misunderstood the way your tool 
> works: I just 
> > read the paper and never tried it, so I might have missed a few key 
> > points.
> >
> > My impression is that VOMS is more appropriate for the grid 
> scale, but 
> > I agree that finding the right compromise between allowing 
> grid access 
> > while respecting site security requirements is one of the most 
> > delicate points which has not been solved, yet.
> >
> > Cheers
> >
> >             Emanuele
> >
> > Rich Baker wrote:
> >
> >> Emanuele LEONARDI wrote:
> >>
> >>> The only solution to this would be certificate-driven 
> ACLs for files 
> >>> and/or finer grained VOMS access control. Un bel di' vedremo...
> >>
> >>
> >>
> >> No, another solution would be to maintain a static 
> one-to-one mapping 
> >> between DN and local account name.  This can be done automatically 
> >> with relatively simple tools such as GUMS which has been 
> developed in 
> >> the US.  Please see the following web page for a description:
> >>
> >> http://www.atlasgrid.bnl.gov/testbed/gums/
> >>
> >> Rich Baker
> >
> >
> >
> > --
> > /------------------- Emanuele Leonardi -------------------\
> > | eMail: [log in to unmask] - Tel.: +41-22-7674066 |  IT 
> > | division - Bat.31 2-012 - CERN - CH-1211 Geneva 23  |
> > \---------------------------------------------------------/
>