> A while ago on -current, I posted a reference to a paper on lottery
> scheduling in FreeBSD. It allows you to provide scheduling weightings
> that (on average) share the CPU as described.
It is also used by the UC-Berkeley CSUA on their shell account machines.
http://www.csua.berkeley.edu:80/
In message <199904131325.jaa08...@kot.ne.mediaone.net>, Mikhail Teterin writes:
>Poul-Henning Kamp once stated:
>
>=>Why don't we admit this possibility exists (as well as many others,
>=>perhaps) for a local user to cause a DoS and may be someday someone
>=>will address it?
>
>=Because we have (co
Poul-Henning Kamp once stated:
=>Why don't we admit this possibility exists (as well as many others,
=>perhaps) for a local user to cause a DoS and may be someday someone
=>will address it?
=Because we have (counts for a moment, but as he flips to the third
=page of notes sighs deeply and gives u
On Sat, 10 Apr 1999, Kevin Day wrote:
> On the shell servers I run, we've got 200-300 users running tasks.
> Occasionally, through intent or misconfiguration, a user either forkbombs,
> or gets a large number of processes running sucking lots of cpu.
>
> I'd like to see an option that makes all t
In message <199904131256.iaa08...@kot.ne.mediaone.net>, Mikhail Teterin writes:
>Why don't we admit this possibility exists (as well as many others,
>perhaps) for a local user to cause a DoS and may be someday someone
>will address it?
Because we have (counts for a moment, but as he flips to the
Just review the thread:
>. Look, here is a little script, which allows any user
to perform a DoS attack!
<. Khmm, yes indeed, but you can remove any user who does
this.
>. But shouldn't the system be able to sustain/detect this
sort of att
Chris Costello once stated:
=On Sat, Apr 10, 1999, Matthew Dillon wrote:
=> :Sun has a product for this, Solaris Resource Manager.
= You don't need to tune user accounts, you need only put the
=users in a separate login class (if that hasn't already been
=done) and modify the resource limitatio
Matthew Dillon wrote:
>
> I would note that BEST.COM has been running, effectively, public shell
> systems for 5 years. The last couple of years have been using FreeBSD.
> It works just dandy. We put 2000 users on each box.
>
> Just because people aren't willing to spend thousa
:What you really mean is that "FreeBSD is not a solution for public
:shell systems", correct? Public shell systems is not a bad idea,
:it's a business opportunity and a public service. If the OS is not
:up to the task, don't blame the task.
:
:--
:Daniel C. Sobral (8-DCS)
On Tue, Apr 13, 1999, Daniel C. Sobral wrote:
> What you really mean is that "FreeBSD is not a solution for public
> shell systems", correct? Public shell systems is not a bad idea,
> it's a business opportunity and a public service. If the OS is not
> up to the task, don't blame the task.
If y
> What you really mean is that "FreeBSD is not a solution for public
> shell systems", correct? Public shell systems is not a bad idea,
> it's a business opportunity and a public service. If the OS is not
> up to the task, don't blame the task.
Any Unix OS is going to give you more or less the sam
Chris Costello wrote:
>
> > If one can't control one's users, one has no business managing them.
> > The
> > last thing FreeBSD needs is some overly complex, sophisticated scheduler
> > designed to help bozo sysops stay on their feet.
>
>I agree with you very much here. Public
On Sat, Apr 10, 1999, Matthew Dillon wrote:
> :Sun has a product for this, Solaris Resource Manager.
>
> ... and if one user is *supposed* to be running all those processes, then
> what? Oh, let me guess: Now you are supposed to tune each user's account
> independantly. For a system
: "What was their user name again?"
: *click xterm click*
: ps aux | grep ^user | wc -l
: "Hmm, you're right, fifty processes called 'cpuwaster'."
: rmuser user
: "They've been eliminated, thank you for letting us know of problems you have!"
:
: It's called "being a sysadmin". If someone's abusing
Warner Losh writes:
> In message <199904102057.paa27...@home.dragondata.com> Kevin Day writes:
> : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
> : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's
> : 40 processes get 50% cpu shared between
> -Original Message-
> From: Amancio Hasty [SMTP:ha...@rah.star-gate.com]
> Sent: Sunday, April 11, 1999 5:36 AM
> To: Matthew Dillon
> Cc: Dmitry Valdov; Brian Feldman; freebsd-current@FreeBSD.ORG
> Subject: Re: DoS from local users (fwd)
>
>
>
Mikhail Teterin wrote:
> What about a new login-class capability specifying the maximum
> percentage of CPU time a class of users can utilize? With standard
> class having 90% (or 95%)? The machine would appear (to most of
> the users) as if it had 10% slower CPU, with the remaining usable
> by th
On Sun, 11 Apr 1999, Kevin Day wrote:
> > In message <199904102057.paa27...@home.dragondata.com> Kevin Day writes:
> > : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
> > : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid
> > 1001's
> > : 40 proces
In message <37106b7d.50b2f...@rcc.on.ca> Rod Taylor writes:
: I like this, but the problem with that fork bomb program still exists.
: It was afterall system cpu that was doing all the work, not the users
: cpu.
System CPU still gets charged to the user, so this is a non-issue.
Warner
To Unsubs
In message <199904102057.paa27...@home.dragondata.com> Kevin Day writes:
: i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
: 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's
: 40 processes get 50% cpu shared between them.
I've seen some experi
> In message <199904102057.paa27...@home.dragondata.com> Kevin Day writes:
> : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
> : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's
> : 40 processes get 50% cpu shared between them.
>
> I've seen
Amancio Hasty wrote:
>
> It should be possible to prevent a user from hogging a system if the system's
> naive scheduler is improved.
I think the problem is not related to the scheduler, but to the code
path involved in running and reading the file at the same time,
multiple times.
--
Daniel C.
Mikhail Teterin wrote:
> What about a new login-class capability specifying the maximum
> percentage of CPU time a class of users can utilize? With standard
> class having 90% (or 95%)? The machine would appear (to most of
> the users) as if it had 10% slower CPU, with the remaining usable
> by th
What about a new login-class capability specifying the maximum
percentage of CPU time a class of users can utilize? With standard
class having 90% (or 95%)? The machine would appear (to most of
the users) as if it had 10% slower CPU, with the remaining usable
by the root-class. This way, if the CPU
I guess any sufficiently advance science is indeed consider magic by some.
Amancio
>
> :
> :It should be possible to prevent a user from hogging a system if the system's
> :naive scheduler is improved.
> :
> : Amancio
>
> No, it isn't. For a very simple reason: The resources
On Sat, 10 Apr 1999, Matthew Dillon wrote:
> Date: Sat, 10 Apr 1999 14:08:41 -0700 (PDT)
> From: Matthew Dillon
> To: Kevin Day
> Cc: ha...@rah.star-gate.com, d...@dv.ru, gr...@unixhelp.org,
> freebsd-current@FreeBSD.ORG
> Subject: Re: DoS from local users (fwd)
>
&g
:Matt, I agree with what you're saying, but what would you think about
:something that would take a look at the total cpu time that a process
:group had accumulated in the previous 120 seconds. That would be, I
:think, plenty long enough to catch most inadvertent things, and just
:kill the process
On Sat, 10 Apr 1999, Matthew Dillon wrote:
> :Kevin
>
> Plausable, yes. Useful: probably not as useful as you might think. I
> wouldn't even consider doing something like that for BEST, it could lead
> to cascade failures.
>
> For example, if a user is running procmail or cron
> :That has nothing to do with it. Not for cpu usage. If you have two users
> that> :are using all the CPU they can they ought to get 50% of the CPU each.
> Even if> :one of the users have 1 process and the other have 100 processes.
> :
> :Sun has a product for this, Solaris Resource Manager.
>
:On the shell servers I run, we've got 200-300 users running tasks.
:Occasionally, through intent or misconfiguration, a user either forkbombs,
:or gets a large number of processes running sucking lots of cpu.
:
:I'd like to see an option that makes all the processes run by one uid have
:the same w
>
> :
> :It should be possible to prevent a user from hogging a system if the system's
> :naive scheduler is improved.
> :
> : Amancio
>
> No, it isn't. For a very simple reason: The resources users need to do
> real work are very similar to the resources users need to hog the syste
:>
:> No, it isn't. For a very simple reason: The resources users need to do
:> real work are very similar to the resources users need to hog the system.
:
:That has nothing to do with it. Not for cpu usage. If you have two users that
:are using all the CPU they can they ought to get 50
>
> :
> :It should be possible to prevent a user from hogging a system if the system's
> :naive scheduler is improved.
> :
> : Amancio
>
> No, it isn't. For a very simple reason: The resources users need to do
> real work are very similar to the resources users need to hog the syste
Hello,
Let's remember a motto of J. Pournelle of the late Byte : one User, more
than one CPU (let people hog their workstation as much as they want ...)
And another good resolution : no shell accounts for normal users on
sensitive servers (no lusers which could want to DoS the servers
allowed)
E
:
:It should be possible to prevent a user from hogging a system if the system's
:naive scheduler is improved.
:
: Amancio
No, it isn't. For a very simple reason: The resources users need to do
real work are very similar to the resources users need to hog the system.
Saying t
It should be possible to prevent a user from hogging a system if the system's
naive scheduler is improved.
Amancio
> It is not possible to prevent a user from hogging the cpu on the system.
> What you *CAN* do is make it difficult for the user to crash the system
> by limiting
It is not possible to prevent a user from hogging the cpu on the system.
What you *CAN* do is make it difficult for the user to crash the system
by limiting the number of processes he is allowed to run, the maximum
data segment size each process is allowed to allocate, and by placi
On Sat, 10 Apr 1999, Brian Feldman wrote:
> Date: Sat, 10 Apr 1999 14:07:27 -0400 (EDT)
> From: Brian Feldman
> To: Dmitry Valdov
> Cc: freebsd-current@freebsd.org
> Subject: Re: DoS from local users (fwd)
>
> On Sat, 10 Apr 1999, Dmitry Valdov wrote:
>
> > H
Brian Feldman once stated:
=> Once again - HOW I can limit CPU usage by *kernel* ? Also, I've just
=> tried set maxprocesses 5. And it helpless. With 5 processes limit
=> user was able to slow down P2-450 computer. Switching between windows
=> in X was VERY slow. Mouse movements was slow down too.
wrote:
>
> > Date: Sat, 10 Apr 1999 09:29:19 -0400 (EDT)
> > From: Brian Feldman
> > To: Dmitry Valdov
> > Cc: ch...@calldei.com, freebsd-current@FreeBSD.ORG,
> > freebsd-questi...@freebsd.org
> > Subject: Re: DoS from local users (fwd)
> >
> >
Dmitry Valdov once stated:
=Once again - HOW I can limit CPU usage by *kernel* ? Also, I've just
=tried set maxprocesses 5. And it helpless. With 5 processes limit user
=was able to slow down P2-450 computer. Switching between windows in X
=was VERY slow. Mouse movements was slow down too.
=CPU s
uesti...@freebsd.org
> Subject: Re: DoS from local users (fwd)
>
> On Sat, 10 Apr 1999, Dmitry Valdov wrote:
>
> >
> >
> > On Sat, 10 Apr 1999, Chris Costello wrote:
> >
> > > Date: Sat, 10 Apr 1999 02:05:33 -0500
> > > From: Chris Costello
&g
freebsd-questi...@freebsd.org
> > Subject: Re: DoS from local users (fwd)
> >
> > On Sat, Apr 10, 1999, Dmitry Valdov wrote:
> > > >You typically want to set a restriction as to how many
> > > > processes a user can spawn. This is done by editing
&
On Sat, 10 Apr 1999, Chris Costello wrote:
> Date: Sat, 10 Apr 1999 02:05:33 -0500
> From: Chris Costello
> Reply-To: ch...@calldei.com
> To: Dmitry Valdov
> Cc: freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org
> Subject: Re: DoS from local users (fwd)
>
&
On Sat, Apr 10, 1999, Dmitry Valdov wrote:
> >You typically want to set a restriction as to how many
> > processes a user can spawn. This is done by editing
> > /etc/login.conf and changing the user's login class, see the man
> > page for 'login.conf'.
> >
>
> I'm about CPU usage, not about
On Fri, 9 Apr 1999, Chris Costello wrote:
> Date: Fri, 9 Apr 1999 18:30:31 -0500
> From: Chris Costello
> Reply-To: ch...@calldei.com
> To: Dmitry Valdov
> Cc: freebsd-questi...@freebsd.org
> Subject: Re: DoS from local users
>
> On Fri, Apr 9, 1999, Dmitry Valdov wrote:
> > Hi!
> >
> > Try
46 matches
Mail list logo
