David McBride wrote:
> Hi Graeme,
>
> It's a cool idea in concept,
I just love my concepts ;-)
>
> On Fri, 2005-09-23 at 08:29 +0100, Graeme A Stewart wrote:
>
>
>>Yes, it
>>would be a priviledge for experiments [installing from their
>> repository]
>>, 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.
Yes, I can't disagree. See my comments to John's mail. But sites need a
mechanism that's tested and isn't onerous, so some packaging method is a
good idea, albeit in a restricted privilege environment.
>
>
>>But it's really quite easy to audit RPMs' post install
>>scripts.
>
>
> *splutter*
Well, I meant in comparison to auditing a user's .bash_history or a
process accounting log...
>
>
>>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.
>
OK, I'm glad to hear what they want to install is "mature". This might
be true of somethings (phedex), but I'm not sure that really is true of
all the VOs. Given that VO boxes have not been deployed, thus this
infrastructure is largely untested, I'm not convinced that the software
change rate will be low.
>
> 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.
I hope they can be temporary. Can we agree a date when they get switched
off?
>
> It is absolutely _not_ a software development testbed.
Not software development, but during SC4 testing will occur of the
software's stability and scalability. That can mean rapid updates and
considerable numbers of bug fixes (c.f. FTS in SC3).
I come back to my original theme: a scheme which is manageable and
scalable. I'm far from being convinced that we have such a mechanism.
Cheers
Graeme
--
--------------------------------------------------------------------
Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
GridPP DM Wiki http://www.physics.gla.ac.uk/gridpp/datamanagement/
|