From 8a4f86345dfc04c73786ec8015d832ee7dafbd9e Mon Sep 17 00:00:00 2001 From: Dima Dorfman Date: Tue, 17 Apr 2001 21:19:49 +0000 Subject: 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 --- en_US.ISO8859-1/books/handbook/users/chapter.sgml | 223 ++++++++++++++++++++- 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 @@ @@ -397,13 +397,222 @@ passwd: done - - Limiting and Personalizing Users + + Limiting Users + + 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. + + 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 . + + 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. + + Login classes are defined in + /etc/login.conf. 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 (default by + default), and that each login class has a set of login capabilities + associated with it. A login capability is a + name=value + pair, where name is a well-known + identifier and value 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;. + + 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 really + a special case of login capabilities). + + 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;). + + + + coredumpsize + + + 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., filesize, 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. + + + + + cputime + + + This is the maximum amount of CPU time a user's process may + consume. Offending processes will be killed by the kernel. - 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 own chapter. + + This is a limit on CPU time + 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. + + + + + + + filesize + + + This is the maximum size of a file the user may possess. + Unlike disk quotas, this limit is + enforced on individual files, not the set of all files a user + owns. + + + + + maxproc + + + 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 kern.maxproc + 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). + + + + + memorylocked + + + 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. + + + + + memoryuse + + + 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. + + + + + openfiles + + + 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 + kern.maxfiles sysctl. + + + + + sbsize + + + 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. + + + + + stacksize + + + 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. + + + + + There are a few other things to remember when setting resource + limits. Following are some general tips, suggestions, and + miscellaneous comments. + + + + Processes started at system startup by + /etc/rc are assigned to the + daemon login class. + + + + Although the /etc/login.conf 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. + + + + 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. + + + + 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 + openfiles multiplied by the value of + maxproc. This also applies to memory + consumption. + + + + 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;. + + + + Personalizing Users 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 @@ @@ -397,13 +397,222 @@ passwd: done - - Limiting and Personalizing Users + + Limiting Users + + 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. + + 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 . + + 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. + + Login classes are defined in + /etc/login.conf. 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 (default by + default), and that each login class has a set of login capabilities + associated with it. A login capability is a + name=value + pair, where name is a well-known + identifier and value 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;. + + 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 really + a special case of login capabilities). + + 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;). + + + + coredumpsize + + + 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., filesize, 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. + + + + + cputime + + + This is the maximum amount of CPU time a user's process may + consume. Offending processes will be killed by the kernel. - 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 own chapter. + + This is a limit on CPU time + 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. + + + + + + + filesize + + + This is the maximum size of a file the user may possess. + Unlike disk quotas, this limit is + enforced on individual files, not the set of all files a user + owns. + + + + + maxproc + + + 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 kern.maxproc + 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). + + + + + memorylocked + + + 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. + + + + + memoryuse + + + 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. + + + + + openfiles + + + 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 + kern.maxfiles sysctl. + + + + + sbsize + + + 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. + + + + + stacksize + + + 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. + + + + + There are a few other things to remember when setting resource + limits. Following are some general tips, suggestions, and + miscellaneous comments. + + + + Processes started at system startup by + /etc/rc are assigned to the + daemon login class. + + + + Although the /etc/login.conf 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. + + + + 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. + + + + 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 + openfiles multiplied by the value of + maxproc. This also applies to memory + consumption. + + + + 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;. + + + + Personalizing Users Localization is an environment set up by the system administrator or user to accommodate different languages, -- cgit v1.3