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.
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 shell
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 same
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 you
: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)
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 thousands
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
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
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
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 the
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 up)
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 (counts for a
-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)
I guess any sufficiently advance
Warner Losh i...@harmony.village.org 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%
: 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 the
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
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.
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
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
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
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 processes get 50%
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 the
On Fri, 9 Apr 1999, Chris Costello wrote:
Date: Fri, 9 Apr 1999 18:30:31 -0500
From: Chris Costello ch...@holly.dyndns.org
Reply-To: ch...@calldei.com
To: Dmitry Valdov d...@dv.ru
Cc: freebsd-questi...@freebsd.org
Subject: Re: DoS from local users
On Fri, Apr 9, 1999, Dmitry Valdov
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 many
On Sat, 10 Apr 1999, Chris Costello wrote:
Date: Sat, 10 Apr 1999 02:05:33 -0500
From: Chris Costello ch...@holly.dyndns.org
Reply-To: ch...@calldei.com
To: Dmitry Valdov d...@dv.ru
Cc: freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org
Subject: Re: DoS from local users (fwd
...@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
...@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 ch...@holly.dyndns.org
Reply-To: ch...@calldei.com
To: Dmitry Valdov d
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
Feldman gr...@unixhelp.org
To: Dmitry Valdov d...@dv.ru
Cc: ch...@calldei.com, freebsd-current@FreeBSD.ORG,
freebsd-questi...@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
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.
=
On Sat, 10 Apr 1999, Brian Feldman wrote:
Date: Sat, 10 Apr 1999 14:07:27 -0400 (EDT)
From: Brian Feldman gr...@unixhelp.org
To: Dmitry Valdov d...@dv.ru
Cc: freebsd-current@freebsd.org
Subject: Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Dmitry Valdov wrote:
Hi!
Once
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
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 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
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)
:
: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.
That
:
: 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 system.
: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
: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 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 on a
: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
from local users (fwd)
A user-run CGI is another example. Say you have a web server which runs
CGI's under a user id. If the web site is loaded down and the user
happens
to run a log processing script, execs of the user's CGIs might slow down
due to the load balancing
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 users
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
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 the
46 matches
Mail list logo
