diff options
| author | Dima Dorfman <dd@FreeBSD.org> | 2001-04-17 21:19:49 +0000 |
|---|---|---|
| committer | Dima Dorfman <dd@FreeBSD.org> | 2001-04-17 21:19:49 +0000 |
| commit | 8a4f86345dfc04c73786ec8015d832ee7dafbd9e (patch) | |
| tree | 68e13a8c94bb87d3c6edf58f0f788126b450cc65 | |
| parent | 0825dcbd598dbbc6620f0dfe7205ea2ac6e1f8c2 (diff) | |
Split up the "limiting and personalizing users" section into
"limiting" and "personalizing". Talk about resource limits via
login.conf in the former, and leave the latter with a link to the
localization chapter.
Reviewed by: nik
Notes
svn path=/head/; revision=9228
| -rw-r--r-- | en_US.ISO8859-1/books/handbook/users/chapter.sgml | 223 | ||||
| -rw-r--r-- | en_US.ISO_8859-1/books/handbook/users/chapter.sgml | 223 |
2 files changed, 432 insertions, 14 deletions
diff --git a/en_US.ISO8859-1/books/handbook/users/chapter.sgml b/en_US.ISO8859-1/books/handbook/users/chapter.sgml index 880375942a..b91dbf7464 100644 --- a/en_US.ISO8859-1/books/handbook/users/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/users/chapter.sgml @@ -1,7 +1,7 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/users/chapter.sgml,v 1.4 2000/06/14 20:30:39 jim Exp $ + $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/users/chapter.sgml,v 1.5 2001/01/20 03:35:19 dannyboy Exp $ --> <chapter id="users"> @@ -397,13 +397,222 @@ passwd: done</screen> </sect2> </sect1> - <sect1 id="users-limiting-and-personalizing"> - <title>Limiting and Personalizing Users</title> + <sect1 id="users-limiting"> + <title>Limiting Users</title> - <para>Quotas allow the system administrator to set disk usage - maximums, and users to check their disk usage, if quotas are - used on the system. Quotas are discussed in their <link - linkend="quotas">own chapter</link>.</para> + <para>If you run a multi-user system, chances are that you do not trust + all of your users not to damage your system. FreeBSD provides a + number of ways a system administrator can limit the amount of system + resources an individual user can use. These limits are generally + divided into two sections: disk quotas, and other resources + limits.</para> + + <para>Disk quotas are a way for the system administrator to tell the + filesystem the amount of disk space a user may use; moreover, they + provide a way to quickly check on the disk usage of a user without + having to calculate it every time. Quotas are discussed in <xref + linkend="quotas">.</para> + + <para>The other resource limits include ways to limit the amount of + CPU, memory, and other resources a user may consume. These are + defined using login classes and are discussed here.</para> + + <para>Login classes are defined in + <filename>/etc/login.conf</filename>. The precise semantics are + beyond the scope of this section, but are described in detail in the + &man.login.conf.5; manual page. It is sufficient to say that each + user can is assigned to a login class (<literal>default</literal> by + default), and that each login class has a set of login capabilities + associated with it. A login capability is a + <literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal> + pair, where <replaceable>name</replaceable> is a well-known + identifier and <replaceable>value</replaceable> is an arbitrary + string processed accordingly depending on the name. Setting up login + classes and capabilities is rather straight-forward, and is also + described in &man.login.conf.5;.</para> + + <para>Resource limits are different from plain vanilla login + capabilities in two ways. First, for every limit, there is a soft + (current) and hard limit. A soft limit may be adjusted by the user + or application, but may be no higher than the hard limit. The latter + may be lowered by the user, but never raised. Second, most resource + limits apply per process to a specific user, not the user as a whole. + Note, however, that these differences are mandated by the specific + handling of the limits, not by the implementation of the login + capability framework (i.e., they are not <emphasis>really</emphasis> + a special case of login capabilities).</para> + + <para>And so, without further ado, below are the most commonly used + resource limits (the rest, along with all the other login + capabilities, may be found in &man.login.conf.5;).</para> + + <variablelist> + <varlistentry> + <term><literal>coredumpsize</literal></term> + + <listitem> + <para>The limit on the size of a core file generated by a program + is, for obvious reasons, subordinate to other limits on disk + usage (e.g., <literal>filesize</literal>, or disk quotas). + Nevertheless, it is often used as a less-severe method of + controlling disk space consumption: since users do not generate + core files themselves, and often do not delete them, setting this + may save them from running out of disk space should a large + program (e.g., Emacs) crash.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>cputime</literal></term> + + <listitem> + <para>This is the maximum amount of CPU time a user's process may + consume. Offending processes will be killed by the kernel. + + <note> + <para>This is a limit on CPU <emphasis>time</emphasis> + consumed, not percentage of the CPU as displayed in some + fields by &man.top.1; and &man.ps.1;. A limit on the + latter is, at the time of this writing, not possible, and + would be rather useless: a compiler—probably a + legitimate task—can easily use almost 100% of a CPU + for some time.</para> + </note> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>filesize</literal></term> + + <listitem> + <para>This is the maximum size of a file the user may possess. + Unlike <link linkend="quotas">disk quotas</link>, this limit is + enforced on individual files, not the set of all files a user + owns.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>maxproc</literal></term> + + <listitem> + <para>This is the maximum number of processes a user may be + running. This includes foreground and background processes + alike. For obvious reasons, this may not be larger than the + system limit specified by the <literal>kern.maxproc</literal> + sysctl. Also note that setting this too small may hinder a + user's productivity: it is often useful to be logged in + multiple times or execute pipelines. Some tasks, such as + compiling a large program, also spawn multiple processes (e.g., + &man.make.1;, &man.cc.1;, and other intermediate + preproccesors).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>memorylocked</literal></term> + + <listitem> + <para>This is the maximum amount a memory a process may have + requested to be locked into main memory (e.g., see + &man.mlock.2;). Some system-critical programs, such as + &man.amd.8;, do this so that their getting swapped out does not + contribute to a system's thrashing in time of trouble.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>memoryuse</literal></term> + + <listitem> + <para>This is the maximum amount of memory a process may consume + at any given time. It includes both core memory and swap + usage. This is not a catch-all limit for restricting memory + consumption, but it is a good start.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>openfiles</literal></term> + + <listitem> + <para>This is the maximum amount of files a process may have + open. In FreeBSD, files are also used to represent sockets and + IPC channels; thus, be careful not to set this too low. The + system-wide limit for this is defined by the + <literal>kern.maxfiles</literal> sysctl.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>sbsize</literal></term> + + <listitem> + <para>This is the limit on the amount of network memory, and thus + mbufs, a user may consume. This originated as a response to an + old DoS attack by creating a lot of sockets, but can be + generally used to limit network communications.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>stacksize</literal></term> + + <listitem> + <para>This is the maximum size a process' stack may grow to. + This alone is not sufficient to limit the amount of memory a + program may use; consequently, it should be used in conjunction + with other limits.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>There are a few other things to remember when setting resource + limits. Following are some general tips, suggestions, and + miscellaneous comments.</para> + + <itemizedlist> + <listitem> + <para>Processes started at system startup by + <filename>/etc/rc</filename> are assigned to the + <literal>daemon</literal> login class.</para> + </listitem> + + <listitem> + <para>Although the <filename>/etc/login.conf</filename> that comes + with the system is a good source of reasonable values for most + limits, only you, the administrator, can know what is appropriate + for your system. Setting a limit too high may open your system + up to abuse, while setting it too low may put a strain on + productivity.</para> + </listitem> + + <listitem> + <para>Users of the X Window System (X11) should probably be granted + more resources than other users. X11 by itself takes a lot of + resources, but it also encourages users to run more programs + simultaneously.</para> + </listitem> + + <listitem> + <para>Remember that many limits apply to individual processes, not + the user as a whole. For example, setting openfiles to 50 means + that each process the user runs may open up to 50 files. Thus, + the gross amount of files a user may open is the value of + <literal>openfiles</literal> multiplied by the value of + <literal>maxproc</literal>. This also applies to memory + consumption.</para> + </listitem> + </itemizedlist> + + <para>For further information on resource limits and login classes and + capabilities in general, please consult the relevant manual pages: + &man.cap.mkdb.1;, &man.getrlimit.2;, &man.login.conf.5;.</para> + </sect1> + + <sect1 id="users-personalizing"> + <title>Personalizing Users</title> <para>Localization is an environment set up by the system administrator or user to accommodate different languages, diff --git a/en_US.ISO_8859-1/books/handbook/users/chapter.sgml b/en_US.ISO_8859-1/books/handbook/users/chapter.sgml index 880375942a..b91dbf7464 100644 --- a/en_US.ISO_8859-1/books/handbook/users/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/users/chapter.sgml @@ -1,7 +1,7 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/users/chapter.sgml,v 1.4 2000/06/14 20:30:39 jim Exp $ + $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/users/chapter.sgml,v 1.5 2001/01/20 03:35:19 dannyboy Exp $ --> <chapter id="users"> @@ -397,13 +397,222 @@ passwd: done</screen> </sect2> </sect1> - <sect1 id="users-limiting-and-personalizing"> - <title>Limiting and Personalizing Users</title> + <sect1 id="users-limiting"> + <title>Limiting Users</title> - <para>Quotas allow the system administrator to set disk usage - maximums, and users to check their disk usage, if quotas are - used on the system. Quotas are discussed in their <link - linkend="quotas">own chapter</link>.</para> + <para>If you run a multi-user system, chances are that you do not trust + all of your users not to damage your system. FreeBSD provides a + number of ways a system administrator can limit the amount of system + resources an individual user can use. These limits are generally + divided into two sections: disk quotas, and other resources + limits.</para> + + <para>Disk quotas are a way for the system administrator to tell the + filesystem the amount of disk space a user may use; moreover, they + provide a way to quickly check on the disk usage of a user without + having to calculate it every time. Quotas are discussed in <xref + linkend="quotas">.</para> + + <para>The other resource limits include ways to limit the amount of + CPU, memory, and other resources a user may consume. These are + defined using login classes and are discussed here.</para> + + <para>Login classes are defined in + <filename>/etc/login.conf</filename>. The precise semantics are + beyond the scope of this section, but are described in detail in the + &man.login.conf.5; manual page. It is sufficient to say that each + user can is assigned to a login class (<literal>default</literal> by + default), and that each login class has a set of login capabilities + associated with it. A login capability is a + <literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal> + pair, where <replaceable>name</replaceable> is a well-known + identifier and <replaceable>value</replaceable> is an arbitrary + string processed accordingly depending on the name. Setting up login + classes and capabilities is rather straight-forward, and is also + described in &man.login.conf.5;.</para> + + <para>Resource limits are different from plain vanilla login + capabilities in two ways. First, for every limit, there is a soft + (current) and hard limit. A soft limit may be adjusted by the user + or application, but may be no higher than the hard limit. The latter + may be lowered by the user, but never raised. Second, most resource + limits apply per process to a specific user, not the user as a whole. + Note, however, that these differences are mandated by the specific + handling of the limits, not by the implementation of the login + capability framework (i.e., they are not <emphasis>really</emphasis> + a special case of login capabilities).</para> + + <para>And so, without further ado, below are the most commonly used + resource limits (the rest, along with all the other login + capabilities, may be found in &man.login.conf.5;).</para> + + <variablelist> + <varlistentry> + <term><literal>coredumpsize</literal></term> + + <listitem> + <para>The limit on the size of a core file generated by a program + is, for obvious reasons, subordinate to other limits on disk + usage (e.g., <literal>filesize</literal>, or disk quotas). + Nevertheless, it is often used as a less-severe method of + controlling disk space consumption: since users do not generate + core files themselves, and often do not delete them, setting this + may save them from running out of disk space should a large + program (e.g., Emacs) crash.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>cputime</literal></term> + + <listitem> + <para>This is the maximum amount of CPU time a user's process may + consume. Offending processes will be killed by the kernel. + + <note> + <para>This is a limit on CPU <emphasis>time</emphasis> + consumed, not percentage of the CPU as displayed in some + fields by &man.top.1; and &man.ps.1;. A limit on the + latter is, at the time of this writing, not possible, and + would be rather useless: a compiler—probably a + legitimate task—can easily use almost 100% of a CPU + for some time.</para> + </note> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>filesize</literal></term> + + <listitem> + <para>This is the maximum size of a file the user may possess. + Unlike <link linkend="quotas">disk quotas</link>, this limit is + enforced on individual files, not the set of all files a user + owns.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>maxproc</literal></term> + + <listitem> + <para>This is the maximum number of processes a user may be + running. This includes foreground and background processes + alike. For obvious reasons, this may not be larger than the + system limit specified by the <literal>kern.maxproc</literal> + sysctl. Also note that setting this too small may hinder a + user's productivity: it is often useful to be logged in + multiple times or execute pipelines. Some tasks, such as + compiling a large program, also spawn multiple processes (e.g., + &man.make.1;, &man.cc.1;, and other intermediate + preproccesors).</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>memorylocked</literal></term> + + <listitem> + <para>This is the maximum amount a memory a process may have + requested to be locked into main memory (e.g., see + &man.mlock.2;). Some system-critical programs, such as + &man.amd.8;, do this so that their getting swapped out does not + contribute to a system's thrashing in time of trouble.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>memoryuse</literal></term> + + <listitem> + <para>This is the maximum amount of memory a process may consume + at any given time. It includes both core memory and swap + usage. This is not a catch-all limit for restricting memory + consumption, but it is a good start.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>openfiles</literal></term> + + <listitem> + <para>This is the maximum amount of files a process may have + open. In FreeBSD, files are also used to represent sockets and + IPC channels; thus, be careful not to set this too low. The + system-wide limit for this is defined by the + <literal>kern.maxfiles</literal> sysctl.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>sbsize</literal></term> + + <listitem> + <para>This is the limit on the amount of network memory, and thus + mbufs, a user may consume. This originated as a response to an + old DoS attack by creating a lot of sockets, but can be + generally used to limit network communications.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>stacksize</literal></term> + + <listitem> + <para>This is the maximum size a process' stack may grow to. + This alone is not sufficient to limit the amount of memory a + program may use; consequently, it should be used in conjunction + with other limits.</para> + </listitem> + </varlistentry> + </variablelist> + + <para>There are a few other things to remember when setting resource + limits. Following are some general tips, suggestions, and + miscellaneous comments.</para> + + <itemizedlist> + <listitem> + <para>Processes started at system startup by + <filename>/etc/rc</filename> are assigned to the + <literal>daemon</literal> login class.</para> + </listitem> + + <listitem> + <para>Although the <filename>/etc/login.conf</filename> that comes + with the system is a good source of reasonable values for most + limits, only you, the administrator, can know what is appropriate + for your system. Setting a limit too high may open your system + up to abuse, while setting it too low may put a strain on + productivity.</para> + </listitem> + + <listitem> + <para>Users of the X Window System (X11) should probably be granted + more resources than other users. X11 by itself takes a lot of + resources, but it also encourages users to run more programs + simultaneously.</para> + </listitem> + + <listitem> + <para>Remember that many limits apply to individual processes, not + the user as a whole. For example, setting openfiles to 50 means + that each process the user runs may open up to 50 files. Thus, + the gross amount of files a user may open is the value of + <literal>openfiles</literal> multiplied by the value of + <literal>maxproc</literal>. This also applies to memory + consumption.</para> + </listitem> + </itemizedlist> + + <para>For further information on resource limits and login classes and + capabilities in general, please consult the relevant manual pages: + &man.cap.mkdb.1;, &man.getrlimit.2;, &man.login.conf.5;.</para> + </sect1> + + <sect1 id="users-personalizing"> + <title>Personalizing Users</title> <para>Localization is an environment set up by the system administrator or user to accommodate different languages, |