Editorial review of Login Classes section.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
01ae222db4
commit
4cc400e20d
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44719
1 changed files with 155 additions and 223 deletions
|
|
@ -3517,46 +3517,11 @@ UWWemqWuz3lAZuORQ9KX
|
|||
<primary>Resource limits</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Traditionally, &os; used a resource limits database
|
||||
controlled through a flat file,
|
||||
<filename>/etc/login.conf</filename>. While this method
|
||||
is still supported, any changes require a multi-step process of
|
||||
editing this file in order to divide users into various group
|
||||
labels known as classes, rebuilding the resource database using
|
||||
<command>cap_mkdb</command>, making necessary changes to
|
||||
<filename>/etc/master.passwd</filename>, and rebuilding the
|
||||
password database using <command>pwd_mkdb</command>. This
|
||||
could be time consuming, depending upon the number of users to
|
||||
configure.</para>
|
||||
|
||||
<para>Beginning with &os; 9.0-RELEASE,
|
||||
<command>rctl</command> can be used to provide a more
|
||||
fine-grained method of controlling resources limits for users.
|
||||
This command supports much more than users as it can be used to
|
||||
set resource constraints on processes, jails, and the original
|
||||
login class. These advanced features provide administrators and
|
||||
users with methods to control resources through the command line
|
||||
and to set rules on system initialization using a configuration
|
||||
file.</para>
|
||||
|
||||
<para>This section demonstrates both methods for controlling
|
||||
resources.</para>
|
||||
|
||||
<sect2 xml:id="users-limiting">
|
||||
<title>Login Classes</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>accounts</primary>
|
||||
<secondary>limiting</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>&os; provides several methods for an administrator to
|
||||
limit the amount of system resources an individual may use.
|
||||
These limits are discussed in two sections: disk quotas and
|
||||
other resource limits.</para>
|
||||
Disk quotas limit the amount of disk space available to
|
||||
users. Quotas are discussed in
|
||||
<xref linkend="quotas"/>.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>quotas</primary>
|
||||
|
|
@ -3569,38 +3534,55 @@ UWWemqWuz3lAZuORQ9KX
|
|||
<primary>disk quotas</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Disk quotas limit the amount of disk space available to
|
||||
users and provide a way to quickly check that usage without
|
||||
calculating it every time. Quotas are discussed in
|
||||
<xref linkend="quotas"/>.</para>
|
||||
<para>Limits to other resources, such as <acronym>CPU</acronym>
|
||||
and memory, can be set using either a flat
|
||||
file or a command to configure a resource limits database. The
|
||||
traditional method defines login classes by editing
|
||||
<filename>/etc/login.conf</filename>. While this method
|
||||
is still supported, any changes require a multi-step process of
|
||||
editing this file, rebuilding the resource database, making necessary changes to
|
||||
<filename>/etc/master.passwd</filename>, and rebuilding the
|
||||
password database. This
|
||||
can become time consuming, depending upon the number of users to
|
||||
configure.</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>Beginning with &os; 9.0-RELEASE,
|
||||
<command>rctl</command> can be used to provide a more
|
||||
fine-grained method for controlling resource limits.
|
||||
This command supports more than user limits as it can also be used to
|
||||
set resource constraints on processes and jails.</para>
|
||||
|
||||
<para>This section demonstrates both methods for controlling
|
||||
resources, beginning with the traditional method.</para>
|
||||
|
||||
<sect2 xml:id="users-limiting">
|
||||
<title>Configuring Login Classes</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>accounts</primary>
|
||||
<secondary>limiting</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary><filename>/etc/login.conf</filename></primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Login classes are defined in
|
||||
<filename>/etc/login.conf</filename> and are described in
|
||||
detail in &man.login.conf.5;. Each user account is assigned
|
||||
to a login class, <literal>default</literal> by default, and
|
||||
each login class has a set of login capabilities associated
|
||||
<para>In the traditional method, login classes and the resource
|
||||
limits to apply to a login class are defined in
|
||||
<filename>/etc/login.conf</filename>. Each user account can be assigned
|
||||
to a login class, where <literal>default</literal> is the default
|
||||
login class. 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 which is processed accordingly depending on
|
||||
the <replaceable>name</replaceable>. Setting up login classes
|
||||
and capabilities is rather straightforward and is also
|
||||
described in &man.login.conf.5;.</para>
|
||||
the <replaceable>name</replaceable>.</para>
|
||||
|
||||
<note>
|
||||
<para>&os; does not normally read the configuration in
|
||||
<filename>/etc/login.conf</filename> directly, but instead
|
||||
reads the <filename>/etc/login.conf.db</filename> database
|
||||
which provides faster lookups. Whenever
|
||||
<para>Whenever
|
||||
<filename>/etc/login.conf</filename> is edited, the
|
||||
<filename>/etc/login.conf.db</filename> must be updated by
|
||||
executing the following command:</para>
|
||||
|
|
@ -3609,207 +3591,159 @@ UWWemqWuz3lAZuORQ9KX
|
|||
</note>
|
||||
|
||||
<para>Resource limits differ from the default 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
|
||||
in two ways. First, for every limit, there is a <firstterm>soft</firstterm>
|
||||
and <firstterm>hard</firstterm> limit. A soft limit may be adjusted by the
|
||||
user or application, but may not be set higher than the hard
|
||||
limit. The hard limit may be lowered by the user, but can
|
||||
only be raised by the superuser. Second, most resource limits
|
||||
apply per process to a specific user, not to the user as a
|
||||
whole. These differences are mandated by the specific
|
||||
handling of the limits, not by the implementation of the login
|
||||
capability framework.</para>
|
||||
apply per process to a specific user.</para>
|
||||
|
||||
<para>Below are the most commonly used resource limits. The
|
||||
rest of the limits, along with all the other login
|
||||
capabilities, can be found in &man.login.conf.5;.</para>
|
||||
<para><xref linkend="resource-limits"/> lists the most commonly
|
||||
used resource limits. All of the available
|
||||
resource limits and capabilities are described in
|
||||
detail in &man.login.conf.5;.</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><literal>coredumpsize</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>The limit on the size of a core file
|
||||
<indexterm>
|
||||
<primary>coredumpsize</primary>
|
||||
</indexterm>
|
||||
generated by a program is subordinate to other limits
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>coredumpsize</secondary>
|
||||
</indexterm>
|
||||
on disk usage, such as <literal>filesize</literal>, or
|
||||
disk quotas. This limit 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
|
||||
crash.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>cputime</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>The maximum amount of CPU
|
||||
<indexterm>
|
||||
<primary>cputime</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>cputime</secondary>
|
||||
</indexterm>
|
||||
time a user's process may consume. Offending processes
|
||||
will be killed by the kernel.</para>
|
||||
|
||||
<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;.</para>
|
||||
</note>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>filesize</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>The maximum size of a file
|
||||
<indexterm>
|
||||
<primary>filesize</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>filesize</secondary>
|
||||
</indexterm>
|
||||
the user may own. 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>The maximum number of processes
|
||||
<indexterm>
|
||||
<primary>maxproc</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>maxproc</secondary>
|
||||
</indexterm>
|
||||
a user can run. This includes foreground and background
|
||||
processes. This limit may not be larger than the system
|
||||
limit specified by the <varname>kern.maxproc</varname>
|
||||
&man.sysctl.8;. Setting this limit too small may hinder
|
||||
a user's productivity as it is often useful to be logged
|
||||
in multiple times or to execute pipelines. Some tasks,
|
||||
such as compiling a large program, start lots of
|
||||
processes.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>memorylocked</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>The maximum amount of memory
|
||||
<indexterm>
|
||||
<primary>memorylocked</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>memorylocked</secondary>
|
||||
</indexterm>
|
||||
a process may request to be locked into main memory
|
||||
using &man.mlock.2;. Some system-critical programs,
|
||||
such as &man.amd.8;, lock into main memory so that if
|
||||
the system begins to swap, they do not contribute to
|
||||
disk thrashing.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>memoryuse</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>The maximum amount of memory
|
||||
<indexterm>
|
||||
<primary>memoryuse</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>memoryuse</secondary>
|
||||
</indexterm>
|
||||
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
|
||||
is a good start.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>openfiles</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>The maximum number of files a process may have open
|
||||
<indexterm>
|
||||
<primary>openfiles</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>openfiles</secondary>
|
||||
</indexterm>.
|
||||
In &os;, files are used to represent sockets and IPC
|
||||
channels, so be careful not to set this too low. The
|
||||
system-wide limit for this is defined by the
|
||||
<varname>kern.maxfiles</varname> &man.sysctl.8;.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>sbsize</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>The limit on the amount of network memory, and
|
||||
thus mbufs
|
||||
<indexterm>
|
||||
<primary>sbsize</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>sbsize</secondary>
|
||||
</indexterm>,
|
||||
a user may consume. This can be generally used to limit
|
||||
network communications.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>stacksize</literal></term>
|
||||
|
||||
<listitem>
|
||||
<para>The maximum size of a process stack
|
||||
<indexterm>
|
||||
<primary>stacksize</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>stacksize</secondary>
|
||||
</indexterm>.
|
||||
</indexterm>
|
||||
|
||||
<table xml:id="resource-limits" frame="none" pgwide="1">
|
||||
<title>Login Class Resource Limits</title>
|
||||
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Resource Limit</entry>
|
||||
<entry>Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>coredumpsize</entry>
|
||||
<entry>The limit on the size of a core file
|
||||
generated by a program is subordinate to other limits
|
||||
on disk usage, such as <literal>filesize</literal> or
|
||||
disk quotas. This limit is often used as a less severe
|
||||
method of controlling disk space consumption. Since
|
||||
users do not generate core files and often
|
||||
do not delete them, this setting may save them from
|
||||
running out of disk space should a large program
|
||||
crash.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>cputime</entry>
|
||||
<entry>The maximum amount of <acronym>CPU</acronym>
|
||||
time a user's process may consume. Offending processes
|
||||
will be killed by the kernel. This is a limit on
|
||||
<acronym>CPU</acronym> <emphasis>time</emphasis>
|
||||
consumed, not the percentage of the <acronym>CPU</acronym> as displayed in
|
||||
some of the fields generated by <command>top</command>
|
||||
and <command>ps</command>.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>filesize</entry>
|
||||
<entry>The maximum size of a file
|
||||
the user may own. Unlike disk quotas
|
||||
(<xref linkend="quotas"/>), this limit is
|
||||
enforced on individual files, not the set of all files a
|
||||
user owns.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>maxproc</entry>
|
||||
<entry>The maximum number of foreground and background processes
|
||||
a user can run. This limit may not be larger than the system
|
||||
limit specified by <varname>kern.maxproc</varname>.
|
||||
Setting this limit too small may hinder
|
||||
a user's productivity as some tasks,
|
||||
such as compiling a large program, start lots of
|
||||
processes.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>memorylocked</entry>
|
||||
<entry>The maximum amount of memory
|
||||
a process may request to be locked into main memory
|
||||
using &man.mlock.2;. Some system-critical programs,
|
||||
such as &man.amd.8;, lock into main memory so that if
|
||||
the system begins to swap, they do not contribute to
|
||||
disk thrashing.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>memoryuse</entry>
|
||||
<entry>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
|
||||
is a good start.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>openfiles</entry>
|
||||
<entry>The maximum number of files a process may have open.
|
||||
In &os;, files are used to represent sockets and <acronym>IPC</acronym>
|
||||
channels, so be careful not to set this too low. The
|
||||
system-wide limit for this is defined by
|
||||
<varname>kern.maxfiles</varname>.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>sbsize</entry>
|
||||
<entry>The limit on the amount of network memory
|
||||
a user may consume. This can be generally used to limit
|
||||
network communications.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>stacksize</entry>
|
||||
<entry>The maximum size of a process stack.
|
||||
This alone is not sufficient to limit the amount of
|
||||
memory a program may use so it should be used in
|
||||
conjunction with other limits.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
memory a program may use, so it should be used in
|
||||
conjunction with other limits.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>There are a few other things to remember when setting
|
||||
resource limits. Following are some general tips,
|
||||
suggestions, and miscellaneous comments.</para>
|
||||
resource limits:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
@ -3819,8 +3753,8 @@ UWWemqWuz3lAZuORQ9KX
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Although the <filename>/etc/login.conf</filename> that
|
||||
comes with the system is a good source of reasonable
|
||||
<para>Although the default <filename>/etc/login.conf</filename>
|
||||
is a good source of reasonable
|
||||
values for most limits, they may not be appropriate for
|
||||
every system. Setting a limit too high may open the
|
||||
system up to abuse, while setting it too low may put a
|
||||
|
|
@ -3828,18 +3762,16 @@ UWWemqWuz3lAZuORQ9KX
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Users of <application>&xorg;</application> should
|
||||
probably be granted more resources than other users.
|
||||
<application>&xorg;</application> by itself takes a lot of
|
||||
resources, but it also encourages users to run more
|
||||
<para><application>&xorg;</application> takes a lot of
|
||||
resources and encourages users to run more
|
||||
programs simultaneously.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Many limits apply to individual processes, not the
|
||||
user as a whole. For example, setting
|
||||
<varname>openfiles</varname> to 50 means that each process
|
||||
the user runs may open up to 50 files. The total amount
|
||||
<varname>openfiles</varname> to <literal>50</literal> means that each process
|
||||
the user runs may open up to <literal>50</literal> files. The total 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
|
||||
|
|
|
|||
Loading…
Reference in a new issue