 |
 |
Hi Graeme, It's a cool idea in concept, but realistically, it's not going to be manageable. Comments inline. On Fri, 2005-09-23 at 08:29 +0100, Graeme A Stewart wrote: > > Also running apt-get update for the VO specific repository is equivalent > > to giving root access to them. > > Well, we give that trust to a lot of people already: upstream software > developers, RedHat, the Scientific Linux rebuilders, LCG, etc. In principle, all of these people have been packaging and distributing software for quite a long time and know what they are doing. That's _why_ they are trusted. (Even then, new packages from these groups are not automatically trusted to be perfect -- sites would normally, if possible, test and validate any new configuration before deploying it as a live system.) > Yes, it > would be a priviledge for experiments, and we'd have do define carefully > the policies associated with it (e.g., mess with httpd.conf and you'll > be uninstalled). That way lies madness. I can't give superuser rights to large numbers of people I don't know and only use the "I'll revoke your access if you break something!" argument as a stick. There's an implicit assumption that breakages (or more importantly, added insecurities) would be noticed immediately which is by no means the case; by the time a problem has been discovered _massive_ damage could have occured. > But it's really quite easy to audit RPMs' post install > scripts. *splutter* > The experiments are not malevolent, but they are equally not > focussed on site security (that's not their job). And as a result they should not be trusted with it. > We're trying to find an operational procedure which can give the > experiments the missing components while maintaing proper security. The proper answer is simply "the experiments ask the sites to install the software for them." Given the software being installed is moderately mature and of production quality, the rate at which the software is changing should be sufficiently low that this is achievable. > > I would be much happier if all VO specific software was provided by an > > LCG repository and each VO had to argue that it realy needs package X > > and that it does provide some functionality not available in the middleware. > > This way will know what is lacking in the middleware (so we can fix it) and > > we will have some control over what gets installed in a VOBOX instead of > > letting each VO running wild on their own and ignoring the middleware. > > This is the ideal position, but experience has shown that the middleware > can't react quickly enough to VOs needs. It's also a very linear model > of development - we probably do need something which allows ideas to be > tried out on a VO box so see if they work. The purpose of a VOBOX is to provide a platform to run -- on a strictly temporary basis -- additional production services needed to support the VO's activity that LCG does not currently provide. It is absolutely _not_ a software development testbed. --- And thus we have, in a nutshell, a summary of reasons of why no sane site administrator is going to allow remotely managed VOBOXes in the manner you're suggesting. Cheers, David -- David McBride <[log in to unmask]> Department of Computing, Imperial College, London