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 |
> > \---------------------------------------------------------/
>
|