From owner-freebsd-doc@FreeBSD.ORG Sat Feb 2 15:40:48 2013 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AFBCBB98; Sat, 2 Feb 2013 15:40:48 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 69995891; Sat, 2 Feb 2013 15:40:48 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r12FelCm028284; Sat, 2 Feb 2013 08:40:47 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r12FelQH028281; Sat, 2 Feb 2013 08:40:47 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 2 Feb 2013 08:40:47 -0700 (MST) From: Warren Block To: Tom Rhodes Subject: Re: [REVIEW REQUEST]: rctl section In-Reply-To: <20130201230450.46255f5e.trhodes@FreeBSD.org> Message-ID: References: <20130201230450.46255f5e.trhodes@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 02 Feb 2013 08:40:47 -0700 (MST) Cc: doc@FreeBSD.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 15:40:48 -0000 On Fri, 1 Feb 2013, Tom Rhodes wrote: > Long time, no chat. It's been awhile, so I would like to get some > review on this section. In this case, I have used some generic > results (testing them with a forkbomb, smart, I know) and I would > like to get some pre-commit feedback. Thanks in advance to anyone > who loans me a few moments of their time! Nice to hear from you! Comments inline below. > Index: security/chapter.xml > =================================================================== > --- chapter.xml (revision 40807) > +++ chapter.xml (working copy) > @@ -97,6 +97,11 @@ > Have an idea of what Process Accounting is and how to > enable it on &os;. > > + > + > + Understand what the resource limits database and > + how to utilize it to excerpt more control over users. s/what// s/excerpt/exert/. "how to utilize it to control user resources" might be better. > + > > > Before reading this chapter, you should: > @@ -4149,4 +4154,116 @@ > pages. > > > + > + > + > + > + > + Tom > + Rhodes > + Contributed by > + > + > + > + > + Resource limits s/limits/Limits/ textproc/igor can check these. > + > + > + Resource limits > + > + > + For years, &os; has made use of a resource limits > + database controlled through a flat file s/file/file,/ > + /etc/login.conf. While it has > + been discussed previously and is still supported, it > + is not the most optimal method of controlling resources. > + The flat file requires users to be divided into various > + group labels known as classes, which require changes not > + only to this flat file but also the password database. > + Potentially, a single, more constrained user would require I want to say that the comma after "single" is not needed, but that's not quite right. Maybe if "more constrained" was hyphenated. > + an additional label added, the resource database needs to be > + built using cap_mkdb, along with edits to > + the /etc/master.passwd file. In How about just "edits to /etc/master.passwd."? textproc/igor checks for these; the FDP style guide advises avoid the redundancy. > + addition, the password database will also need rebuilt using "will also need rebuilt" could be colloquial. "Must be rebuilt" would work. > + pwd_mkdb. This multi-step process could be > + very time consuming depending on how many users must be > + singled out. For cap_mkdb and pwd_mkdb, man entities may be better. I've been trying to use when talking specifically about using the command, and man entities when talking about the whole application. Here it's a little fuzzy. The man entities give the user a link to the man page, though. > + A new command in &os;, &man.rctl.8;, allows for a more > + fine grained method of controlling resources limits for > + users. This command will support much more than users, > + it will also 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 set rules on > + system initialization using a configuration > + file. > + > + To enable this feature, add the following lines to Suggestion: "these" instead of "the following". (We have way too many of "the following" already; the reader can see that it is following, because it is.) > + GENERIC, or the custom kernel > + configuration file, and rebuild.: > + > + options RACCT > +options RCTL > + > + Due to the nature of this configuration file, the > + entire system will need rebuilt. See + linkend="kernelconfig"/>, which will provide instructions for The diff may distort it, but I think that line needs to be indented another level (still inside the xref tag). textproc/igor checks for these, too. > + this process. Once this is complete, the rctl s/the// > + may be used to set rules for the system. > + > + Rule syntax is simple, controlled through the use of > + a subject, a subject-id, resource, and action. Take the Those terms should probably be marked up. Maybe tags around them? > + following example rule: > + > + user:trhodes:maxproc:deny=10/user > + > + This rule shows a basic premise of a rule, here the > + subject is user and the subject-id > + is trhodes. The maxproc is, of course, around "maxproc" also. > + max number of processes, which is considered the action. "is considered" by what? Would just "is" be adequate? And I think it's not an action, but a resource. > + The action here is set to deny, which blocks any new around "deny". > + processes from being created. Wait, what does "10/user" mean? > + Other actions could be s/be/be to/ > + log to the console, pass a notification to &man.devd.8;, or > + send a sigterm to the process. > + > + Some care must be taken while adding rules, the one above That comma should be a full stop. > + will unfortunately block me from doing the most simple tasks > + after I have logged in and executed a screen > + session. When a resource limit has been hit, an error will > + be printed, as in this example: > + > + &prompt.user; man test > + /usr/bin/man: Cannot fork: Resource temporarily unavailable > +eval: Cannot fork: Resource temporarily unavailable > + > + For another example, &man.rctl.8; could be used to prevent s/could/can/ (active) > + a jail from exceeding a memory limit. This rule could be s/could/can/ (active) > + written as: > + > + &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail > + > + Rules may also persist across reboots if they have been > + added to the /etc/rctl.conf file. The "added to /etc/rctl.conf." > + format is a rule, without the preceding command. For example, > + the previous rule could be added like the following: > + > + # Block jail from using more than 2G memory: > +jail:httpd:memoryuse:deny=2G/jail > + > + To remove a rule, just ask rctl to > + remove it from the list: > + > + &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user > + > + The manual page shows a method for removing all rules; > + however, if removing all rules for a single user is required, > + the following command may be issued: How about "this command" instead of "the following command"? > + &prompt.root; rctl -r user:trhodes > + > + Many other resources exist which could be used to excerpt s/could/can/ (active) s/excerpt/exert/ > + additional control over subjects. Not really sure what that means. Is "subjects" a technical term, or does it just mean "things"? If so, how about "rctl can control many resources." > + See the manual page for > + rctl to learn about them. "See &man.rctl.8; to learn about them." > + > Thank you!