Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: tekbspa!tss!joe@uunet.uu.net (Joe Michel-Angelo)
Newsgroups: comp.sys.sun
Subject: Re: Securing the Server
Keywords: Networks
Message-ID: <864@tekbspa.UUCP>
Date: 5 May 89 11:52:16 GMT
References: <8903301637.AA08612@bucsf>
Sender: usenet@rice.edu
Organization: Teknekron Software Systems, San Jose, CA.
Lines: 37
Approved: Sun-Spots@rice.edu
Original-Date: 27 Apr 89 06:49:00 GMT
X-Sun-Spots-Digest: Volume 7, Issue 267, message 6 of 10

> anderer@vax1.acs.udel.edu (David G Anderer) writes: 
>>There's no reason they should run jobs on the server, and a good
>>one they shouldn't.
> 
> Do you have any statistics to back this up, or is this a impression that
> you get?  It seems to me that running a job on the workstation takes up
> just as much of the server's resources as running it on the server would.
> 
> Can anyone else comment knowledgeably on this subject?

perhaps his problem isn't one of w/s vs. server in cpu runtime, perhaps
it's more a matter of w/s vs. server RESOURCES.... ie: text table, inode
slots, proc slots, memory, swap, etc.

about once every 2 weeks we run out of text table slots on most of our
servers; always due to developers testing new daemons or something; but
instead of restricting access (which in my book is a NO NO!), i either
reboot every friday night or eval the situation and order more hardware
... another server never hurts, ya know. 

admins also have other tricks... think of a scheme that would make it less
'useful' to run something on a server... like ask your manager for
approval to tighten up system security and chmod 0 /dev/kmem ...  then
"ps" won't work and a developer without the ps command is like a nune
without her hat...

anyways, point is: you have to draw a line between productive and non-
productive environments and let everyone know what the line is. when they
tread on it, let 'em know with a nice warning & detailed explaination.
restricting machine access just creates support & maint headacks for you
and a resentment towards you -and- should be the absolute last thing you
do [to internal staff].

"The Network         Joe Angelo,  VP/Technical Support - Support Group Division
 Adminstrator        Teknekron Software Systems, Palo Alto, CA     415-325-1025
 Is the Computer"    
                     joe@tss.com - uunet!tekbspa!joe - tekbspa!joe@uunet.uu.net