Hi *,
My biggest worry is along the same lines as Henry but is technical
rather than administrative ... because the VO boxes can run software
that can potentially be
a) active (react to commands from the outside world)
b) dynamic (might be different software tomorrow than today)
c) less than perfect (begins to do very strange things)
and all of these things can happen without me knowing about it ... makes
operation of our site much more difficult. If all I run is generic
middleware, there are a limited number of components I have to look at
when things go wrong, and I know what most of them are called. Throw a
VO-box into the mix and I hope I am very wrong in worrying that this
might make things very different.
J "I just love being wrong" T
Henry Nebrensky wrote:
> On Wed, 14 Sep 2005, Markus Schulz wrote:
>
>
>>Dear Henry,
>>I have a few comments and a few questions.
>>
>>As you stated correctly each and every sgm can move code to any of
>>her VO's vo-boxes and
>>run the code as a mapped user.
>>I don't see a fundamental difference between this and the ability to
>>run long running jobs on a batch system through the grid.
>>In both cases the sysadmin has no effective control over what code
>>the users run and a 48h job with external network connectivity is
>>not so different from what the users can do on a VO box.
>
>
> Except that as Steve pointed out, WNs don't necessarily have inbound
> connectivity, so that even if a user sets up a server of some kind, nobody
> can access it. Our primary 64-node cluster has all the nodes on a private
> network partly to try to prevent such, er, rogue publishing - I believe
> that was actually a condition *imposed* on us to run an LCG site; as I
> said:
>
>>>Most of us directly involved with Grid *are* wanting to get it to
>>>work (and even do something useful)... but we have to remember that in
>>>order to do so we depend on others, who don't have that personal
>>>interest, and have a conflicting set of pressures.
>
>
>
> Some things that universities don't like:
>
> - VoIP and conferencing apps. (Foreign students use up all the
> site bandwidth calling home. At least one UK uni is NOT ALLOWED to
> use VRVS, for example.)
>
> - File-sharing apps. (Partly because of the network load, but also as
> below)
>
> - Externally visible servers. (In case they suddenly turn out to have
> hidden directories of music/videos/warez or worse. And it's not
> always an evil third-party that put them there... The bandwidth
> eaten up by outsiders d/ling them is just a nuisance - the real hassle
> starts when the gentlemen from the BPI[*] turn up...)
>
>
>
>>The question that I have are of practical matter:
>>You mention that you have to make sure that you are responsible that
>>people don't misuse the service (as an example you
>>mention the storage of ripped movies).
>>How do you ensure this? Are you in control of what the users store on
>>your site and what software they run?
>
>
> (Theory and practice may differ :))
>
> To some extent, yes. For example, I could look at VO AUPs and avoid VOs
> that allow doing something that might cause trouble. The SE could trigger
> an alarm if a filename ending in .avi is uploaded, and one could imagine
> the equivalent of a virus scanner looking through sandboxes and gridftp
> transfers watching for root kits. Port scanning could pick up illicit
> services added to an SE or other node.
>
> But, yes most of the "responsibility" is retrospective and would involve
> finding out who had done something nasty and yanking their certificate.
>
> I think though that I didn't make my point very clearly at 2 a.m:
> If the boys from the BPI turn up wanting to know why Britney's latest is
> available from our SE, they can be re-directed to my desk to loom over
> *me* to get an explanation.
>
> With the current proposals that administrative/management chain is
> broken/undefined - it's not clear which person is responsible for which
> aspects of the VO box. I'm not sure I can meaningfully take
> responsibility when I don't have any control (how can I tell whether a VO
> has updated its box to use the latest version of its services?). The
> obvious solution is to pass the responsibility down to those actually
> running the services, which is formalised by:
>
>
>>>---------------------------------------------------------------------
>>>Experiments/VOs wishing to operate services on hosts inside Brunel
>>>University's network and/or externally visible within the brunel.ac.uk
>>>domain must apply in writing to the head to Computer Services here.
>>>----------------------------------------------------------------------
>
>
>
> So as Steve also said, I'm worried about what the situation is if a VO box
> gets compromised, but it's not so much a technical objection as an
> administrative one.
>
> Henry
>
> [*] or whatever the UK equivalent of the RIAA is called
>
|