From owner-freebsd-doc@FreeBSD.ORG Sun May 22 09:40:09 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1732106564A for ; Sun, 22 May 2011 09:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BA9388FC0C for ; Sun, 22 May 2011 09:40:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4M9e8Gb016685 for ; Sun, 22 May 2011 09:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4M9e8fi016684; Sun, 22 May 2011 09:40:08 GMT (envelope-from gnats) Resent-Date: Sun, 22 May 2011 09:40:08 GMT Resent-Message-Id: <201105220940.p4M9e8fi016684@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Niclas Zeising Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C721B1065674 for ; Sun, 22 May 2011 09:34:16 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id C823D8FC0A for ; Sun, 22 May 2011 09:34:14 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 47E7540002 for ; Sun, 22 May 2011 11:34:13 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 3994940006; Sun, 22 May 2011 11:34:13 +0200 (CEST) Received: from mx.daemonic.se (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id C869940002 for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 53392119C04 for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: from vincent.daemonic.se (login.daemonic.se [IPv6:2001:470:dca9:0:1::10]) by mail.daemonic.se (Postfix) with ESMTPS id 2011012B2DA for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: (from zeising@localhost) by vincent.daemonic.se (8.14.4/8.14.4/Submit) id p4M9Y9JL041108; Sun, 22 May 2011 11:34:09 +0200 (CEST) (envelope-from zeising) Message-Id: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> Date: Sun, 22 May 2011 11:34:09 +0200 (CEST) From: Niclas Zeising To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 09:40:09 -0000 >Number: 157245 >Category: docs >Synopsis: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sun May 22 09:40:08 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Niclas Zeising >Release: FreeBSD 8.2-RELEASE amd64 >Organization: >Environment: System: FreeBSD vincent.daemonic.se 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Wed Apr 20 17:22:47 CEST 2011 root@vincent.daemonic.se:/usr/obj/usr/src/sys/VINCENT amd64 >Description: DNSSEC is deemd to be very important in order to secure the Internet as a whole I have written a section about what DNSSEC is and how to configure BIND to use it, intended for the FreeBSD handbook. As a first step, I would like some review on my work, both from a technical and a linguistic point of view. >How-To-Repeat: >Fix: Attached patch contains my changes to the handbook to include information about DNSSEC. Please review it as a first step, so that I can work on getting it into the handbook. --- network-servers.chapter.sgml.diff begins here --- Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ chapter.sgml 21 May 2011 19:13:24 -0000 @@ -3872,6 +3872,293 @@ + DNSSEC + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or DNSSEC + for short, is a suite of specifications to protect the + DNS clients, i.e. Internet resolvers, from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity and authenticity of the record. It is worth noticing that + DNSSEC does only provide integrity, it does not + provide either confidentiality nor protection against false assumptions, + meaning that it cannot protect against people going to + example.com instead of + example.net and similar. The only + thing DNSSEC does is authenticate that the data is + from the domain owner and that it has not been compromised in transit. + The security of DNS is believed to be an important + step in securing the Internet in general. For a more in-depth + knowledge of how DNSSEC works, the relevant + RFCs is a good place to start. See the list at the + end of this chapter. + + The next two sections will demonstrate how to enable + DNSSEC for an authorative DNS + server and a recursive (or cashing) DNS server + running BIND9. While all versions of + BIND9 supports DNSSEC, it is + necessary to have at least version 9.6.2 in order to be able to use the + signed root zone when validating DNS queries. This is + because earlier versions lack the required algorithms to enable + validation using the root zone key. It is strongly recommended to use + BIND 9.7 or later, to take advantage of the automatic + key updating function for the root key, as well as other functions to + automatically keep zones signed and signatures up to date. Where + configurations differ between 9.6.2 and 9.7 and later, differences will + be pointed out. + + + Recursive <acronym>DNS</acronym> server configuration + + To enable DNSSEC validation of queries done by + a recursive DNS server, a few changes to + named.conf are needed. However, before changing + named.conf the root zone key, or trust anchor, + must be aquired. Currently the root zone key is not available in a + file format BIND understands, so this has to be + manually generated. The key itself can be obtained by querying the + root zone for it, using dig. By running + &prompt.user; dig +multi +noall +answer DNSKEY . + > root.dnskey the key will end up in + root.dnskey. The contents should look something + like this: +. 93910 IN DNSKEY 257 3 8 ( + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= + ) ; key id = 19036 +. 93910 IN DNSKEY 256 3 8 ( + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt + ) ; key id = 34525 + Do not be alarmed if the keys differ, they might + have changed since this was last updated. This output actually + contains two keys. The first key in the listing, with the value 257 + behind the DNSKEY record type, is the one needed. The value + indicates that this is a Secure Entry Point, more commonly known as + a Key Signing Key (KSK). + The second key, with value 256, is a subordinate key, commonly + called a Zone Signing Key + (ZSK). More on the + different key types later in the section . + + Now that the key is obtained, it has to be verified to be + correct, and then made into a format BIND can + use. The next step is to generate a + DS + RR set. This is done by + running &propmt.user; dnssec-dsfromkey -f + root-dnskey . > root.ds, which will emit two + RRs into root.ds. These + records are using SHA-1 and SHA-256 respectively, and should look + similar to this, where the longer is using SHA-256. +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + The SHA-256 RR can now be + compared to the digest in + https://data.iana.org/root-anchors/root-anchors.xml. To be + absolutely sure that the key has not been tampered with, the data in + the XML file can be verified using the + PGP signature in + https://data.iana.org/root-anchors/root-anchors.asc. + + The last step is to format the key to a format + BIND understand. This differs a little between + version 9.6.2 and 9.7 and later. Both uses a + managed-keys clause, but support for + initial-key was added in 9.7. + initial-key tells BIND + automatic tracking of the key. With BIND 9.6.2 + it is necessary to update the key manually when it is changed. The + format should look like, for BIND 9.6.2: + +managed-keys { + "." 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + For 9.7 the format will instead be: + +managed-keys { + "." initial-key 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + The managed-keys directive can + now be added to named.conf either directly or + by including a file containing the key. After all this is done it + is just to tell BIND to do + DNSSEC validation on queries. This is achieved by + editing named.conf and add the following to the + options directive: +dnssec-enable yes; +dnssec-validation yes; + + + To verify that it is actually working, use + dig to make a query for a signed zone + using the resolver just set up. A successful reply will contain + the AD + flag to indicate the data was authenticated. Running a + query such as &prompt.user; dig @resolver +dnssec + se ds should return the DS + RR for the .se zone. In the + flags: section the + AD flag should be set, as seen + in: +... +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 +... + . This means that the resolver is now capable of + authenticate made DNSqueries. + + + + Authorative <acronym>DNS</acronym> server configuration + In order to get an authorative nameserver to serve a + DNSSEC signed zone, a little more work is + required. To sign a zone, two cryptographic keys for that zone must + be generated. These two keys are usually called the Key Signing Key + (KSK) and Zone Signing Key + (ZSK) respectively. The + KSK is used to build a chain + of authority to the data in need of validation and as such also called + a Secure Entry Point (SEP) key. This key needs to be published in the + parent zone as well, to establish the trust chain. How this is + accomplished depends on the parent zone owner. The ZSK is used to sign the zone, and only needs to + be published there. + + To enable DNSSEC for the example.com zone depicted in previous + examples, the first step is to use + dnssec-keygen to generate the + KSK and ZSK keypair. This keypair + can utilize different cryptograhic algorithms. Currently the mandatory + algorithm is RSA/SHA-1. In the examples the key + length used is 2048 bits for the KSK and 1024 bits + for the ZSK. To generate the + KSK for example.com, run &promt.user; + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE + example.com and to generate the + ZSK, run &promt.user; + dnssec-keygen -a RSASHA1 -b 1024 -n ZONE + example.com. + dnssec-keygen outputs two files, the public + and the private keys in files named similar to + Kexample.com.+005+nnnnn.key (public) and + Kexample.com.+005+nnnnn.private (private). The + nnnnn part of the file name is a five digit key ID. + Keep track of which key ID belongs to which key. This is especially + important when having more than one key in a zone. The public key + files can now be included in the zone file, using the + $include statement. It should look something like + this: +$include Kexample.net.+005+nnnnn.key ; ZSK +$include Kexample.net.+005+nnnnn.key ; KSK + + + The only steps left is to sign the zone and tell + BIND to use the signed zonefile. To sign a zone + dnssec-signzone is used. The command to + sign the zone example.com, located in + example.com.db would look similar to + &promt.user; dnssec-signzone -o example.com -k + Kexample.com+005+nnnnn example.com.db + Kexample.com+005+nnnnn.key. The key supplied to + the -k argument is the KSK and + the other key file is the ZSK that should be used + in the signing. It is possible to supply more than one + KSK and ZSK, which will result + in the zone being signed with all supplied keys. This can be needed + to supply zone data signed using more than one algorithm. The output + of dnssec-signzone is a zone file with all + RRs signed. This output will end up in a file with + the extension .signed, such as + example.com.db.signed. To use this signed zone + just modify the zone directive in named.conf to + use this file. By default, the signatures are only valid 30 days, + meaning that the zone needs to be resigned within this time. It is + possible to make a script and a cron job to do this. See relevant + manuals for details. + Some cautionary words at the end. Be sure to keep private keys + confidential, as with all cryptographic keys. When changing a key it + is best to include the new key into the zone, while still signing with + the old key, and then move over to using the new key to sign. After + these steps are done the old key can be removed from the zone. + Failiure to do this might render the DNS data + unavailable for a time, untill the new key has propagated through the + DNS hierarchy. For more information on key + rollovers and other DNSSEC operational issues, see + RFC 4641: + DNSSEC Operational practices. + + + + Automation using <acronym>BIND</acronym>9.7 or later + Beginning with BIND version 9.7, a new feature + called Smart Signing was introduced. This + feature aims to make the key management and signing process simpler by + automating parts of the task. By putting the keys into a directory, + from now on called a key repository, and using the new option + auto-dnssec it is possible to create a dynamic zone + which will be resigned as needed. To update this zone the tool + nsupdate with the new option + -l is used. rndc has + also grown the ability to sign zones with keys in the key repository, + using the option sign. To make this work, put + something similar to what is shown below into + named.conf. +zone example.com { + type master; + key-directory "keys"; + update-policy local; + auto-dnssec maintain; + file "dynamic/example.com.zone"; +}; + This will tell named to use automatic signing and + updating of the zone example.com. + After this is done just generate keys for the zone as explained in + , put these in the key repository + denoted by key-directory in the zone configuration + and sign the zone using rndc. Updates to + the zone is done using nsupdate which will + take care of resigning the zone with the new data added. For further + details, see and the + BIND documentation. + + + + + Security Although BIND is the most common implementation of DNS, @@ -3897,7 +4184,7 @@ - + Further Reading BIND/named manual pages: @@ -3932,6 +4219,38 @@ url="http://tools.ietf.org/html/rfc1035">RFC1035 - Domain Names - Implementation and Specification + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Recource Records for the DNS Security Extensions + + + + RFC4035 + - Protocol Modifications for the DNS Security Extensions + + + + RFC4641 + - DNSSEC Operational Practices + + + + RFC 5011 + - Automated Updates of DNS Security (DNSSEC + Trust Anchors + + --- network-servers.chapter.sgml.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sun May 22 10:41:38 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0CF6106566C; Sun, 22 May 2011 10:41:38 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 998938FC12; Sun, 22 May 2011 10:41:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4MAfcTa079909; Sun, 22 May 2011 10:41:38 GMT (envelope-from ryusuke@freefall.freebsd.org) Received: (from ryusuke@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4MAfcPw079905; Sun, 22 May 2011 10:41:38 GMT (envelope-from ryusuke) Date: Sun, 22 May 2011 10:41:38 GMT Message-Id: <201105221041.p4MAfcPw079905@freefall.freebsd.org> To: ryusuke@FreeBSD.org, freebsd-doc@FreeBSD.org, ryusuke@FreeBSD.org From: ryusuke@FreeBSD.org Cc: Subject: Re: docs/156724: [PATCH] Porter's Handbook uses shism $() X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 10:41:38 -0000 Synopsis: [PATCH] Porter's Handbook uses shism $() Responsible-Changed-From-To: freebsd-doc->ryusuke Responsible-Changed-By: ryusuke Responsible-Changed-When: Sun May 22 10:40:40 UTC 2011 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=156724 From owner-freebsd-doc@FreeBSD.ORG Sun May 22 18:41:57 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA5C0106566C; Sun, 22 May 2011 18:41:57 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABAD8FC08; Sun, 22 May 2011 18:41:56 +0000 (UTC) X-AuditID: 12074425-b7b78ae000007e02-ba-4dd955702f08 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 29.1A.32258.07559DD4; Sun, 22 May 2011 14:26:56 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p4MIQs3D013966; Sun, 22 May 2011 14:26:54 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p4MIQphX029803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 May 2011 14:26:53 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p4MIQpbr017112; Sun, 22 May 2011 14:26:51 -0400 (EDT) Date: Sun, 22 May 2011 14:26:50 -0400 (EDT) From: Benjamin Kaduk To: Niclas Zeising In-Reply-To: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> Message-ID: References: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6nrlsQetPX4NZjZYtTZ7pYLVqerGa3 eNN3mNGB2WPGp/ksHjtn3WUPYIrisklJzcksSy3St0vgyrh+5CpTwYZ1jBW97RuZGxi3dDB2 MXJySAiYSEw5cRHKFpO4cG89WxcjF4eQwD5GiYuTj0I5Gxglln+cxQThHGCS6N34FcppYJR4 u3wvWD+LgLbEwvXT2EBsNgEViZlvNoLZIgK6Eiuu3gGzmQVsJRbffgxkc3AIC6RL3F4kCRLm FLCTuNVyCCzMK+Ag8e4ID0hYCKi6ee15VhBbVEBHYvX+KSwgNq+AoMTJmU9YICZaSvxb+4t1 AqPgLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFula6OVmluilppRuYgSHrYvqDsYJ h5QOMQpwMCrx8C7WvOkrxJpYVlyZe4hRkoNJSZTXPxgoxJeUn1KZkVicEV9UmpNafIhRgoNZ SYS3QfuGrxBvSmJlVWpRPkxKmoNFSZx3vqS6r5BAemJJanZqakFqEUxWhoNDSYJ3ZwjQUMGi 1PTUirTMnBKENBMHJ8hwHqDhfiCLeYsLEnOLM9Mh8qcYdTk6H/w4wCjEkpeflyolztsLMkgA pCijNA9uDizdvGIUB3pLmHc7SBUPMFXBTXoFtIQJaMnHvGsgS0oSEVJSDYwlaTNM9R8eOL2+ L3D+1MQs7QbdbZd/8/335wqZuv3TmRfHG2YvZhXuFPyT9bv50YpfGh1bRaWlP1Q2rlVscJpQ OFlutcrmI8uuNl5cIswqVz4lznPZeqkYIe9jJwwLdpzzigmyq2Tw7PlgmC47J+vJO7uv7cvC U/nXaVx8m/9ze+itLwlGaU5KLMUZiYZazEXFiQCrxXteEgMAAA== Cc: freebsd-doc@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 18:41:57 -0000 On Sun, 22 May 2011, Niclas Zeising wrote: > > >> Description: > DNSSEC is deemd to be very important in order to secure the Internet as a whole I have written a section about what DNSSEC is and how to configure BIND to use it, intended for the FreeBSD handbook. > As a first step, I would like some review on my work, both from a technical and a linguistic point of view. I can't do a technical review, but found a few language nits. > > --- network-servers.chapter.sgml.diff begins here --- > Index: chapter.sgml > =================================================================== > RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v > retrieving revision 1.130 > diff -u -d -r1.130 chapter.sgml > --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 > +++ chapter.sgml 21 May 2011 19:13:24 -0000 > @@ -3872,6 +3872,293 @@ > > > > + DNSSEC > + > + BIND > + DNS security extensions > + > + > + Domain Name System Security Extensions, or DNSSEC > + for short, is a suite of specifications to protect the s/ the$// > + DNS clients, i.e. Internet resolvers, from forged > + DNS data, such as spoofed DNS > + records. By using digital signatures, a resolver can verify the > + integrity and authenticity of the record. It is worth noticing that > + DNSSEC does only provide integrity, it does not This phrasing is a rather uncommon usage; "DNSSEC only provides integrity" is what would more commonly be seen. > + provide either confidentiality nor protection against false assumptions, I believe that "nor" should be "or" here, but I don't have a good reference with me at the moment to check. > + meaning that it cannot protect against people going to > + example.com instead of > + example.net and similar. The only > + thing DNSSEC does is authenticate that the data is > + from the domain owner and that it has not been compromised in transit. > + The security of DNS is believed to be an important > + step in securing the Internet in general. For a more in-depth > + knowledge of how DNSSEC works, the relevant > + RFCs is a good place to start. See the list at the s/is/are/ > + end of this chapter. > + > + The next two sections will demonstrate how to enable > + DNSSEC for an authorative DNS "authoritative" > + server and a recursive (or cashing) DNS server "caching" > + running BIND9. While all versions of > + BIND9 supports DNSSEC, it is s/supports/support/ > + necessary to have at least version 9.6.2 in order to be able to use the > + signed root zone when validating DNS queries. This is > + because earlier versions lack the required algorithms to enable > + validation using the root zone key. It is strongly recommended to use > + BIND 9.7 or later, to take advantage of the automatic > + key updating function for the root key, as well as other functions to > + automatically keep zones signed and signatures up to date. Where > + configurations differ between 9.6.2 and 9.7 and later, differences will > + be pointed out. > + > + > + Recursive <acronym>DNS</acronym> server configuration > + > + To enable DNSSEC validation of queries done by > + a recursive DNS server, a few changes to > + named.conf are needed. However, before changing > + named.conf the root zone key, or trust anchor, > + must be aquired. Currently the root zone key is not available in a > + file format BIND understands, so this has to be > + manually generated. The key itself can be obtained by querying the I guess the point is that IANA doesn't distribute the key in this form? This sentence ("Currently...generated.") could probably be reworked to make it more clear that we need to get the root zone key and then convert it to a format that BIND understands. > + root zone for it, using dig. By running > + &prompt.user; dig +multi +noall +answer DNSKEY . > + > root.dnskey the key will end up in > + root.dnskey. The contents should look something > + like this: > +. 93910 IN DNSKEY 257 3 8 ( > + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ > + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh > + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA > + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp > + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 > + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO > + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc > + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= > + ) ; key id = 19036 > +. 93910 IN DNSKEY 256 3 8 ( > + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf > + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE > + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V > + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt > + ) ; key id = 34525 > + Do not be alarmed if the keys differ, they might "the keys" is ambiguous. What we care about is the keys the reader gets as compared to the ones listed here, since the root key currently in use might have changed since our document was last updated. > + have changed since this was last updated. This output actually > + contains two keys. The first key in the listing, with the value 257 > + behind the DNSKEY record type, is the one needed. The value > + indicates that this is a Secure Entry Point, more commonly known as > + a Key Signing Key (KSK). > + The second key, with value 256, is a subordinate key, commonly > + called a Zone Signing Key > + (ZSK). More on the > + different key types later in the section + linkend="dns-dnssec-auth">. > + > + Now that the key is obtained, it has to be verified to be > + correct, and then made into a format BIND can > + use. The next step is to generate a > + DS > + RR set. This is done by > + running &propmt.user; dnssec-dsfromkey -f > + root-dnskey . > root.ds, which will emit two > + RRs into root.ds. These > + records are using SHA-1 and SHA-256 respectively, and should look > + similar to this, where the longer is using SHA-256. > +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E > +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 > + The SHA-256 RR can now be > + compared to the digest in + url="https://data.iana.org/root-anchors/root-anchors.xml"> > + https://data.iana.org/root-anchors/root-anchors.xml. To be > + absolutely sure that the key has not been tampered with, the data in > + the XML file can be verified using the > + PGP signature in + url="https://data.iana.org/root-anchors/root-anchors.asc"> > + https://data.iana.org/root-anchors/root-anchors.asc. > + > + The last step is to format the key to a format > + BIND understand. This differs a little between "understands" > + version 9.6.2 and 9.7 and later. Both uses a "versions 9.6.2 and 9.7+", perhaps? Certainly "versions" should be plural. Also, s/uses/use/ > + managed-keys clause, but support for > + initial-key was added in 9.7. > + initial-key tells BIND > + automatic tracking of the key. With BIND 9.6.2 "initial-key tells BIND automatic tracking of the key" is not a complete sentence. If I had to guess, I'd say that the initial-key directive tells BIND to automatically track the key, but I'm not entirely sure that's the correct meaning. > + it is necessary to update the key manually when it is changed. The > + format should look like, for BIND 9.6.2: > + > +managed-keys { > + "." 257 3 8 > + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF > + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX > + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD > + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz > + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS > + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq > + QxA+Uk1ihz0="; > +}; > + For 9.7 the format will instead be: > + > +managed-keys { > + "." initial-key 257 3 8 > + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF > + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX > + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD > + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz > + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS > + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq > + QxA+Uk1ihz0="; > +}; > + The managed-keys directive can > + now be added to named.conf either directly or s/now//, I think. > + by including a file containing the key. After all this is done it > + is just to tell BIND to do s/is just/only remains/ > + DNSSEC validation on queries. This is achieved by > + editing named.conf and add the following to the "adding", for consistency with "editing" > + options directive: > +dnssec-enable yes; > +dnssec-validation yes; > + > + > + To verify that it is actually working, use > + dig to make a query for a signed zone > + using the resolver just set up. A successful reply will contain s/just set up/as just configured/ would be less informal. > + the AD > + flag to indicate the data was authenticated. Running a > + query such as &prompt.user; dig @resolver +dnssec Is this "@resolver" supposed to be "@[IP address or hostname of resolver just configured]"? I suspect there is markup for this, if so. > + se ds should return the DS > + RR for the .se zone. In the > + flags: section the > + AD flag should be set, as seen > + in: > +... > +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > +... > + . This means that the resolver is now capable of > + authenticate made DNSqueries. The clause "now capable of authenticate made" doesn't make any sense to me. > + > + > + > + Authorative <acronym>DNS</acronym> server configuration "Authoritative", again. > + In order to get an authorative nameserver to serve a and here. > + DNSSEC signed zone, a little more work is > + required. To sign a zone, two cryptographic keys for that zone must > + be generated. These two keys are usually called the Key Signing Key > + (KSK) and Zone Signing Key > + (ZSK) respectively. The > + KSK is used to build a chain > + of authority to the data in need of validation and as such also called put an "is" in "and as such also called"; there's a couple of places to choose from. > + a Secure Entry Point (SEP) key. This key needs to be published in the > + parent zone as well, to establish the trust chain. How this is > + accomplished depends on the parent zone owner. The ZSK is used to sign the zone, and only needs to > + be published there. > + > + To enable DNSSEC for the + role="domainname">example.com zone depicted in previous > + examples, the first step is to use > + dnssec-keygen to generate the > + KSK and ZSK keypair. This keypair > + can utilize different cryptograhic algorithms. Currently the mandatory > + algorithm is RSA/SHA-1. In the examples the key > + length used is 2048 bits for the KSK and 1024 bits > + for the ZSK. To generate the > + KSK for + role="domainname">example.com, run &promt.user; > + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE > + example.com and to generate the > + ZSK, run &promt.user; > + dnssec-keygen -a RSASHA1 -b 1024 -n ZONE > + example.com. > + dnssec-keygen outputs two files, the public > + and the private keys in files named similar to > + Kexample.com.+005+nnnnn.key (public) and > + Kexample.com.+005+nnnnn.private (private). The > + nnnnn part of the file name is a five digit key ID. > + Keep track of which key ID belongs to which key. This is especially > + important when having more than one key in a zone. The public key > + files can now be included in the zone file, using the > + $include statement. It should look something like > + this: > +$include Kexample.net.+005+nnnnn.key ; ZSK > +$include Kexample.net.+005+nnnnn.key ; KSK > + > + > + The only steps left is to sign the zone and tell s/is/are/ > + BIND to use the signed zonefile. To sign a zone > + dnssec-signzone is used. The command to > + sign the zone example.com, located in > + example.com.db would look similar to > + &promt.user; dnssec-signzone -o example.com -k > + Kexample.com+005+nnnnn example.com.db > + Kexample.com+005+nnnnn.key. The key supplied to > + the -k argument is the KSK and > + the other key file is the ZSK that should be used > + in the signing. It is possible to supply more than one > + KSK and ZSK, which will result > + in the zone being signed with all supplied keys. This can be needed > + to supply zone data signed using more than one algorithm. The output > + of dnssec-signzone is a zone file with all > + RRs signed. This output will end up in a file with > + the extension .signed, such as > + example.com.db.signed. To use this signed zone > + just modify the zone directive in named.conf to > + use this file. By default, the signatures are only valid 30 days, > + meaning that the zone needs to be resigned within this time. It is > + possible to make a script and a cron job to do this. See relevant > + manuals for details. > + Some cautionary words at the end. Be sure to keep private keys > + confidential, as with all cryptographic keys. When changing a key it > + is best to include the new key into the zone, while still signing with > + the old key, and then move over to using the new key to sign. After > + these steps are done the old key can be removed from the zone. > + Failiure to do this might render the DNS data > + unavailable for a time, untill the new key has propagated through the > + DNS hierarchy. For more information on key > + rollovers and other DNSSEC operational issues, see > + + url="http://www.ietf.org/rfc/rfc4641.txt">RFC 4641: > + DNSSEC Operational practices. > + > + > + > + Automation using <acronym>BIND</acronym>9.7 or later > + Beginning with BIND version 9.7, a new feature > + called Smart Signing was introduced. This > + feature aims to make the key management and signing process simpler by > + automating parts of the task. By putting the keys into a directory, > + from now on called a key repository, and using the new option > + auto-dnssec it is possible to create a dynamic zone > + which will be resigned as needed. To update this zone the tool > + nsupdate with the new option > + -l is used. rndc has > + also grown the ability to sign zones with keys in the key repository, > + using the option sign. To make this work, put > + something similar to what is shown below into > + named.conf. > +zone example.com { > + type master; > + key-directory "keys"; > + update-policy local; > + auto-dnssec maintain; > + file "dynamic/example.com.zone"; > +}; > + This will tell named to use automatic signing and > + updating of the zone example.com. > + After this is done just generate keys for the zone as explained in > + , put these in the key repository > + denoted by key-directory in the zone configuration "denoted by" could be ambiguous -- "given as the argument to the key-directory directive" might be better. > + and sign the zone using rndc. Updates to > + the zone is done using nsupdate which will I'm not sure what is intended, here. Is it trying to say that further updates to the zone must only be done using nsupdate, which will automatically re-sign the zone? > + take care of resigning the zone with the new data added. For further > + details, see and the > + BIND documentation. > + > + > + > + > + > Security > > Although BIND is the most common implementation of DNS, > @@ -3897,7 +4184,7 @@ > > > > - > + > Further Reading > > BIND/named manual pages: > @@ -3932,6 +4219,38 @@ > url="http://tools.ietf.org/html/rfc1035">RFC1035 > - Domain Names - Implementation and Specification > Hmm, I kind of want all of these to be —es. Thanks for putting together this DNSSEC section -- it will be really great to have it more widely deployed! -Ben Kaduk > + > + > + + url="http://tools.ietf.org/html/rfc4033">RFC4033 > + - DNS Security Introduction and Requirements > + > + > + > + + url="http://tools.ietf.org/html/rfc4034">RFC4034 > + - Recource Records for the DNS Security Extensions > + > + > + > + + url="http://tools.ietf.org/html/rfc4035">RFC4035 > + - Protocol Modifications for the DNS Security Extensions > + > + > + > + + url="http://tools.ietf.org/html/rfc4641">RFC4641 > + - DNSSEC Operational Practices > + > + > + > + + url="http://tools.ietf.org/html/rfc5011">RFC 5011 > + - Automated Updates of DNS Security (DNSSEC > + Trust Anchors > + > + > > > > --- network-servers.chapter.sgml.diff ends here --- > > >> Release-Note: >> Audit-Trail: >> Unformatted: > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" > From owner-freebsd-doc@FreeBSD.ORG Sun May 22 18:50:07 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F862106564A for ; Sun, 22 May 2011 18:50:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 19DC58FC08 for ; Sun, 22 May 2011 18:50:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4MIo6NZ023224 for ; Sun, 22 May 2011 18:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4MIo6jN023223; Sun, 22 May 2011 18:50:06 GMT (envelope-from gnats) Date: Sun, 22 May 2011 18:50:06 GMT Message-Id: <201105221850.p4MIo6jN023223@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Benjamin Kaduk Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benjamin Kaduk List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 18:50:07 -0000 The following reply was made to PR docs/157245; it has been noted by GNATS. From: Benjamin Kaduk To: Niclas Zeising Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-doc@freebsd.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Sun, 22 May 2011 14:26:50 -0400 (EDT) On Sun, 22 May 2011, Niclas Zeising wrote: > > >> Description: > DNSSEC is deemd to be very important in order to secure the Internet as a whole I have written a section about what DNSSEC is and how to configure BIND to use it, intended for the FreeBSD handbook. > As a first step, I would like some review on my work, both from a technical and a linguistic point of view. I can't do a technical review, but found a few language nits. > > --- network-servers.chapter.sgml.diff begins here --- > Index: chapter.sgml > =================================================================== > RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v > retrieving revision 1.130 > diff -u -d -r1.130 chapter.sgml > --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 > +++ chapter.sgml 21 May 2011 19:13:24 -0000 > @@ -3872,6 +3872,293 @@ > > > > + DNSSEC > + > + BIND > + DNS security extensions > + > + > + Domain Name System Security Extensions, or DNSSEC > + for short, is a suite of specifications to protect the s/ the$// > + DNS clients, i.e. Internet resolvers, from forged > + DNS data, such as spoofed DNS > + records. By using digital signatures, a resolver can verify the > + integrity and authenticity of the record. It is worth noticing that > + DNSSEC does only provide integrity, it does not This phrasing is a rather uncommon usage; "DNSSEC only provides integrity" is what would more commonly be seen. > + provide either confidentiality nor protection against false assumptions, I believe that "nor" should be "or" here, but I don't have a good reference with me at the moment to check. > + meaning that it cannot protect against people going to > + example.com instead of > + example.net and similar. The only > + thing DNSSEC does is authenticate that the data is > + from the domain owner and that it has not been compromised in transit. > + The security of DNS is believed to be an important > + step in securing the Internet in general. For a more in-depth > + knowledge of how DNSSEC works, the relevant > + RFCs is a good place to start. See the list at the s/is/are/ > + end of this chapter. > + > + The next two sections will demonstrate how to enable > + DNSSEC for an authorative DNS "authoritative" > + server and a recursive (or cashing) DNS server "caching" > + running BIND9. While all versions of > + BIND9 supports DNSSEC, it is s/supports/support/ > + necessary to have at least version 9.6.2 in order to be able to use the > + signed root zone when validating DNS queries. This is > + because earlier versions lack the required algorithms to enable > + validation using the root zone key. It is strongly recommended to use > + BIND 9.7 or later, to take advantage of the automatic > + key updating function for the root key, as well as other functions to > + automatically keep zones signed and signatures up to date. Where > + configurations differ between 9.6.2 and 9.7 and later, differences will > + be pointed out. > + > + > + Recursive <acronym>DNS</acronym> server configuration > + > + To enable DNSSEC validation of queries done by > + a recursive DNS server, a few changes to > + named.conf are needed. However, before changing > + named.conf the root zone key, or trust anchor, > + must be aquired. Currently the root zone key is not available in a > + file format BIND understands, so this has to be > + manually generated. The key itself can be obtained by querying the I guess the point is that IANA doesn't distribute the key in this form? This sentence ("Currently...generated.") could probably be reworked to make it more clear that we need to get the root zone key and then convert it to a format that BIND understands. > + root zone for it, using dig. By running > + &prompt.user; dig +multi +noall +answer DNSKEY . > + > root.dnskey the key will end up in > + root.dnskey. The contents should look something > + like this: > +. 93910 IN DNSKEY 257 3 8 ( > + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ > + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh > + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA > + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp > + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 > + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO > + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc > + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= > + ) ; key id = 19036 > +. 93910 IN DNSKEY 256 3 8 ( > + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf > + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE > + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V > + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt > + ) ; key id = 34525 > + Do not be alarmed if the keys differ, they might "the keys" is ambiguous. What we care about is the keys the reader gets as compared to the ones listed here, since the root key currently in use might have changed since our document was last updated. > + have changed since this was last updated. This output actually > + contains two keys. The first key in the listing, with the value 257 > + behind the DNSKEY record type, is the one needed. The value > + indicates that this is a Secure Entry Point, more commonly known as > + a Key Signing Key (KSK). > + The second key, with value 256, is a subordinate key, commonly > + called a Zone Signing Key > + (ZSK). More on the > + different key types later in the section + linkend="dns-dnssec-auth">. > + > + Now that the key is obtained, it has to be verified to be > + correct, and then made into a format BIND can > + use. The next step is to generate a > + DS > + RR set. This is done by > + running &propmt.user; dnssec-dsfromkey -f > + root-dnskey . > root.ds, which will emit two > + RRs into root.ds. These > + records are using SHA-1 and SHA-256 respectively, and should look > + similar to this, where the longer is using SHA-256. > +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E > +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 > + The SHA-256 RR can now be > + compared to the digest in + url="https://data.iana.org/root-anchors/root-anchors.xml"> > + https://data.iana.org/root-anchors/root-anchors.xml. To be > + absolutely sure that the key has not been tampered with, the data in > + the XML file can be verified using the > + PGP signature in + url="https://data.iana.org/root-anchors/root-anchors.asc"> > + https://data.iana.org/root-anchors/root-anchors.asc. > + > + The last step is to format the key to a format > + BIND understand. This differs a little between "understands" > + version 9.6.2 and 9.7 and later. Both uses a "versions 9.6.2 and 9.7+", perhaps? Certainly "versions" should be plural. Also, s/uses/use/ > + managed-keys clause, but support for > + initial-key was added in 9.7. > + initial-key tells BIND > + automatic tracking of the key. With BIND 9.6.2 "initial-key tells BIND automatic tracking of the key" is not a complete sentence. If I had to guess, I'd say that the initial-key directive tells BIND to automatically track the key, but I'm not entirely sure that's the correct meaning. > + it is necessary to update the key manually when it is changed. The > + format should look like, for BIND 9.6.2: > + > +managed-keys { > + "." 257 3 8 > + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF > + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX > + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD > + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz > + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS > + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq > + QxA+Uk1ihz0="; > +}; > + For 9.7 the format will instead be: > + > +managed-keys { > + "." initial-key 257 3 8 > + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF > + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX > + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD > + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz > + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS > + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq > + QxA+Uk1ihz0="; > +}; > + The managed-keys directive can > + now be added to named.conf either directly or s/now//, I think. > + by including a file containing the key. After all this is done it > + is just to tell BIND to do s/is just/only remains/ > + DNSSEC validation on queries. This is achieved by > + editing named.conf and add the following to the "adding", for consistency with "editing" > + options directive: > +dnssec-enable yes; > +dnssec-validation yes; > + > + > + To verify that it is actually working, use > + dig to make a query for a signed zone > + using the resolver just set up. A successful reply will contain s/just set up/as just configured/ would be less informal. > + the AD > + flag to indicate the data was authenticated. Running a > + query such as &prompt.user; dig @resolver +dnssec Is this "@resolver" supposed to be "@[IP address or hostname of resolver just configured]"? I suspect there is markup for this, if so. > + se ds should return the DS > + RR for the .se zone. In the > + flags: section the > + AD flag should be set, as seen > + in: > +... > +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > +... > + . This means that the resolver is now capable of > + authenticate made DNSqueries. The clause "now capable of authenticate made" doesn't make any sense to me. > + > + > + > + Authorative <acronym>DNS</acronym> server configuration "Authoritative", again. > + In order to get an authorative nameserver to serve a and here. > + DNSSEC signed zone, a little more work is > + required. To sign a zone, two cryptographic keys for that zone must > + be generated. These two keys are usually called the Key Signing Key > + (KSK) and Zone Signing Key > + (ZSK) respectively. The > + KSK is used to build a chain > + of authority to the data in need of validation and as such also called put an "is" in "and as such also called"; there's a couple of places to choose from. > + a Secure Entry Point (SEP) key. This key needs to be published in the > + parent zone as well, to establish the trust chain. How this is > + accomplished depends on the parent zone owner. The ZSK is used to sign the zone, and only needs to > + be published there. > + > + To enable DNSSEC for the + role="domainname">example.com zone depicted in previous > + examples, the first step is to use > + dnssec-keygen to generate the > + KSK and ZSK keypair. This keypair > + can utilize different cryptograhic algorithms. Currently the mandatory > + algorithm is RSA/SHA-1. In the examples the key > + length used is 2048 bits for the KSK and 1024 bits > + for the ZSK. To generate the > + KSK for + role="domainname">example.com, run &promt.user; > + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE > + example.com and to generate the > + ZSK, run &promt.user; > + dnssec-keygen -a RSASHA1 -b 1024 -n ZONE > + example.com. > + dnssec-keygen outputs two files, the public > + and the private keys in files named similar to > + Kexample.com.+005+nnnnn.key (public) and > + Kexample.com.+005+nnnnn.private (private). The > + nnnnn part of the file name is a five digit key ID. > + Keep track of which key ID belongs to which key. This is especially > + important when having more than one key in a zone. The public key > + files can now be included in the zone file, using the > + $include statement. It should look something like > + this: > +$include Kexample.net.+005+nnnnn.key ; ZSK > +$include Kexample.net.+005+nnnnn.key ; KSK > + > + > + The only steps left is to sign the zone and tell s/is/are/ > + BIND to use the signed zonefile. To sign a zone > + dnssec-signzone is used. The command to > + sign the zone example.com, located in > + example.com.db would look similar to > + &promt.user; dnssec-signzone -o example.com -k > + Kexample.com+005+nnnnn example.com.db > + Kexample.com+005+nnnnn.key. The key supplied to > + the -k argument is the KSK and > + the other key file is the ZSK that should be used > + in the signing. It is possible to supply more than one > + KSK and ZSK, which will result > + in the zone being signed with all supplied keys. This can be needed > + to supply zone data signed using more than one algorithm. The output > + of dnssec-signzone is a zone file with all > + RRs signed. This output will end up in a file with > + the extension .signed, such as > + example.com.db.signed. To use this signed zone > + just modify the zone directive in named.conf to > + use this file. By default, the signatures are only valid 30 days, > + meaning that the zone needs to be resigned within this time. It is > + possible to make a script and a cron job to do this. See relevant > + manuals for details. > + Some cautionary words at the end. Be sure to keep private keys > + confidential, as with all cryptographic keys. When changing a key it > + is best to include the new key into the zone, while still signing with > + the old key, and then move over to using the new key to sign. After > + these steps are done the old key can be removed from the zone. > + Failiure to do this might render the DNS data > + unavailable for a time, untill the new key has propagated through the > + DNS hierarchy. For more information on key > + rollovers and other DNSSEC operational issues, see > + + url="http://www.ietf.org/rfc/rfc4641.txt">RFC 4641: > + DNSSEC Operational practices. > + > + > + > + Automation using <acronym>BIND</acronym>9.7 or later > + Beginning with BIND version 9.7, a new feature > + called Smart Signing was introduced. This > + feature aims to make the key management and signing process simpler by > + automating parts of the task. By putting the keys into a directory, > + from now on called a key repository, and using the new option > + auto-dnssec it is possible to create a dynamic zone > + which will be resigned as needed. To update this zone the tool > + nsupdate with the new option > + -l is used. rndc has > + also grown the ability to sign zones with keys in the key repository, > + using the option sign. To make this work, put > + something similar to what is shown below into > + named.conf. > +zone example.com { > + type master; > + key-directory "keys"; > + update-policy local; > + auto-dnssec maintain; > + file "dynamic/example.com.zone"; > +}; > + This will tell named to use automatic signing and > + updating of the zone example.com. > + After this is done just generate keys for the zone as explained in > + , put these in the key repository > + denoted by key-directory in the zone configuration "denoted by" could be ambiguous -- "given as the argument to the key-directory directive" might be better. > + and sign the zone using rndc. Updates to > + the zone is done using nsupdate which will I'm not sure what is intended, here. Is it trying to say that further updates to the zone must only be done using nsupdate, which will automatically re-sign the zone? > + take care of resigning the zone with the new data added. For further > + details, see and the > + BIND documentation. > + > + > + > + > + > Security > > Although BIND is the most common implementation of DNS, > @@ -3897,7 +4184,7 @@ > > > > - > + > Further Reading > > BIND/named manual pages: > @@ -3932,6 +4219,38 @@ > url="http://tools.ietf.org/html/rfc1035">RFC1035 > - Domain Names - Implementation and Specification > Hmm, I kind of want all of these to be —es. Thanks for putting together this DNSSEC section -- it will be really great to have it more widely deployed! -Ben Kaduk > + > + > + + url="http://tools.ietf.org/html/rfc4033">RFC4033 > + - DNS Security Introduction and Requirements > + > + > + > + + url="http://tools.ietf.org/html/rfc4034">RFC4034 > + - Recource Records for the DNS Security Extensions > + > + > + > + + url="http://tools.ietf.org/html/rfc4035">RFC4035 > + - Protocol Modifications for the DNS Security Extensions > + > + > + > + + url="http://tools.ietf.org/html/rfc4641">RFC4641 > + - DNSSEC Operational Practices > + > + > + > + + url="http://tools.ietf.org/html/rfc5011">RFC 5011 > + - Automated Updates of DNS Security (DNSSEC > + Trust Anchors > + > + > > > > --- network-servers.chapter.sgml.diff ends here --- > > >> Release-Note: >> Audit-Trail: >> Unformatted: > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" > From owner-freebsd-doc@FreeBSD.ORG Sun May 22 19:58:06 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E151065670; Sun, 22 May 2011 19:58:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id E54568FC13; Sun, 22 May 2011 19:58:05 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.1.2.146] ([173.200.178.70]) by asmtp023.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LLM00B2V1Z6TY80@asmtp023.mac.com>; Sun, 22 May 2011 11:57:07 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.148,0.0.0000 definitions=2011-05-22_02:2011-05-20, 2011-05-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105220063 From: Chuck Swiger In-reply-to: Date: Sun, 22 May 2011 11:57:06 -0700 Message-id: <51A7C865-898E-4EF4-9DFA-8F2CF53D016F@mac.com> References: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1084) Cc: Niclas Zeising , FreeBSD-gnats-submit@freebsd.org, freebsd-doc@freebsd.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 19:58:06 -0000 On May 22, 2011, at 11:26 AM, Benjamin Kaduk wrote: >> + provide either confidentiality nor protection against false assumptions, > > I believe that "nor" should be "or" here, but I don't have a good reference with me at the moment to check. Agreed. One uses "either" and "or" together, or "neither" and "nor". Regards, -- -Chuck From owner-freebsd-doc@FreeBSD.ORG Sun May 22 20:00:26 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E4EA1065686 for ; Sun, 22 May 2011 20:00:26 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6338FC4A for ; Sun, 22 May 2011 20:00:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4MK0Qxx085302 for ; Sun, 22 May 2011 20:00:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4MK0QXS085301; Sun, 22 May 2011 20:00:26 GMT (envelope-from gnats) Date: Sun, 22 May 2011 20:00:26 GMT Message-Id: <201105222000.p4MK0QXS085301@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Chuck Swiger Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chuck Swiger List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 20:00:26 -0000 The following reply was made to PR docs/157245; it has been noted by GNATS. From: Chuck Swiger To: Benjamin Kaduk Cc: Niclas Zeising , freebsd-doc@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Sun, 22 May 2011 11:57:06 -0700 On May 22, 2011, at 11:26 AM, Benjamin Kaduk wrote: >> + provide either confidentiality nor protection against false assumptions, > > I believe that "nor" should be "or" here, but I don't have a good reference with me at the moment to check. Agreed. One uses "either" and "or" together, or "neither" and "nor". Regards, -- -Chuck From owner-freebsd-doc@FreeBSD.ORG Sun May 22 20:39:00 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10BBC106566C; Sun, 22 May 2011 20:39:00 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 41D4B8FC17; Sun, 22 May 2011 20:38:59 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 8F65119031; Sun, 22 May 2011 22:20:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id oWBfJCfGU2aV; Sun, 22 May 2011 22:20:04 +0200 (CEST) Received: from danger-mbp.local (adsl-dyn230.91-127-165.t-com.sk [91.127.165.230]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id F263219017; Sun, 22 May 2011 22:20:03 +0200 (CEST) Message-ID: <4DD96FF3.8080101@FreeBSD.org> Date: Sun, 22 May 2011 22:20:03 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18pre) Gecko/20110427 Lanikai/3.1.11pre MIME-Version: 1.0 To: freebsd-doc@freebsd.org, Doug Barton References: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 20:39:00 -0000 On 22.5.2011 20:26, Benjamin Kaduk wrote: > On Sun, 22 May 2011, Niclas Zeising wrote: > >> >> >>> Description: >> DNSSEC is deemd to be very important in order to secure the Internet >> as a whole I have written a section about what DNSSEC is and how to >> configure BIND to use it, intended for the FreeBSD handbook. >> As a first step, I would like some review on my work, both from a >> technical and a linguistic point of view. > > I can't do a technical review, but found a few language nits. I believe the right person for the tech review is dougb@ (cc:ing him) >> >> --- network-servers.chapter.sgml.diff begins here --- >> Index: chapter.sgml >> =================================================================== >> RCS file: >> /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v >> >> retrieving revision 1.130 >> diff -u -d -r1.130 chapter.sgml >> --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 >> +++ chapter.sgml 21 May 2011 19:13:24 -0000 >> @@ -3872,6 +3872,293 @@ >> >> >> >> + DNSSEC >> + >> + BIND >> + DNS security extensions >> + >> + >> + Domain Name System Security Extensions, or >> DNSSEC >> + for short, is a suite of specifications to protect the > > s/ the$// > >> + DNS clients, i.e. Internet resolvers, from forged >> + DNS data, such as spoofed DNS >> + records. By using digital signatures, a resolver can verify the >> + integrity and authenticity of the record. It is worth noticing that >> + DNSSEC does only provide integrity, it does not > > This phrasing is a rather uncommon usage; "DNSSEC only provides > integrity" is what would more commonly be seen. > >> + provide either confidentiality nor protection against false >> assumptions, > > I believe that "nor" should be "or" here, but I don't have a good > reference with me at the moment to check. > >> + meaning that it cannot protect against people going to >> + example.com instead of >> + example.net and similar. The only >> + thing DNSSEC does is authenticate that the data is >> + from the domain owner and that it has not been compromised in transit. >> + The security of DNS is believed to be an important >> + step in securing the Internet in general. For a more in-depth >> + knowledge of how DNSSEC works, the relevant >> + RFCs is a good place to start. See the list at the > > s/is/are/ > >> + end of this chapter. >> + >> + The next two sections will demonstrate how to enable >> + DNSSEC for an authorative DNS > > "authoritative" > >> + server and a recursive (or cashing) DNS server > > "caching" > >> + running BIND9. While all versions of >> + BIND9 supports DNSSEC, it is > > s/supports/support/ > >> + necessary to have at least version 9.6.2 in order to be able to use the >> + signed root zone when validating DNS queries. >> This is >> + because earlier versions lack the required algorithms to enable >> + validation using the root zone key. It is strongly recommended to use >> + BIND 9.7 or later, to take advantage of the >> automatic >> + key updating function for the root key, as well as other functions to >> + automatically keep zones signed and signatures up to date. Where >> + configurations differ between 9.6.2 and 9.7 and later, differences will >> + be pointed out. >> + >> + >> + Recursive <acronym>DNS</acronym> server configuration >> + >> + To enable DNSSEC validation of queries done by >> + a recursive DNS server, a few changes to >> + named.conf are needed. However, before changing >> + named.conf the root zone key, or trust anchor, >> + must be aquired. Currently the root zone key is not available in a >> + file format BIND understands, so this has to be >> + manually generated. The key itself can be obtained by querying the > > I guess the point is that IANA doesn't distribute the key in this form? > This sentence ("Currently...generated.") could probably be reworked to > make it more clear that we need to get the root zone key and then > convert it to a format that BIND understands. > >> + root zone for it, using dig. By running >> + &prompt.user; dig +multi +noall +answer DNSKEY . >> + > root.dnskey the key will end up in >> + root.dnskey. The contents should look something >> + like this: >> +. 93910 IN DNSKEY 257 3 8 ( >> + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ >> + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh >> + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA >> + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp >> + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 >> + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO >> + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc >> + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= >> + ) ; key id = 19036 >> +. 93910 IN DNSKEY 256 3 8 ( >> + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf >> + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE >> + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V >> + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt >> + ) ; key id = 34525 >> + Do not be alarmed if the keys differ, they might > > "the keys" is ambiguous. What we care about is the keys the reader gets > as compared to the ones listed here, since the root key currently in use > might have changed since our document was last updated. > >> + have changed since this was last updated. This output actually >> + contains two keys. The first key in the listing, with the value 257 >> + behind the DNSKEY record type, is the one needed. The value >> + indicates that this is a Secure Entry Point, more commonly known as >> + a Key Signing Key (KSK). >> + The second key, with value 256, is a subordinate key, commonly >> + called a Zone Signing Key >> + (ZSK). More on the >> + different key types later in the section > + linkend="dns-dnssec-auth">. >> + >> + Now that the key is obtained, it has to be verified to be >> + correct, and then made into a format BIND can >> + use. The next step is to generate a >> + DS >> + RR set. This is done by >> + running &propmt.user; dnssec-dsfromkey -f >> + root-dnskey . > root.ds, which will emit two >> + RRs into root.ds. These >> + records are using SHA-1 and SHA-256 respectively, and should look >> + similar to this, where the longer is using SHA-256. >> +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E >> +. IN DS 19036 8 2 >> 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 >> + The SHA-256 RR can now be >> + compared to the digest in > + url="https://data.iana.org/root-anchors/root-anchors.xml"> >> + https://data.iana.org/root-anchors/root-anchors.xml. To be >> + absolutely sure that the key has not been tampered with, the data in >> + the XML file can be verified using the >> + PGP signature in > + url="https://data.iana.org/root-anchors/root-anchors.asc"> >> + https://data.iana.org/root-anchors/root-anchors.asc. >> + >> + The last step is to format the key to a format >> + BIND understand. This differs a little between > > "understands" > >> + version 9.6.2 and 9.7 and later. Both uses a > > "versions 9.6.2 and 9.7+", perhaps? Certainly "versions" should be plural. > Also, s/uses/use/ > >> + managed-keys clause, but support for >> + initial-key was added in 9.7. >> + initial-key tells BIND >> + automatic tracking of the key. With BIND 9.6.2 > > "initial-key tells BIND automatic tracking of the key" is not a complete > sentence. If I had to guess, I'd say that the initial-key directive > tells BIND to automatically track the key, but I'm not entirely sure > that's the correct meaning. > >> + it is necessary to update the key manually when it is changed. The >> + format should look like, for BIND 9.6.2: >> + >> +managed-keys { >> + "." 257 3 8 >> + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF >> + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX >> + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD >> + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz >> + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS >> + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq >> + QxA+Uk1ihz0="; >> +}; >> + For 9.7 the format will instead be: >> + >> +managed-keys { >> + "." initial-key 257 3 8 >> + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF >> + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX >> + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD >> + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz >> + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS >> + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq >> + QxA+Uk1ihz0="; >> +}; >> + The managed-keys directive can >> + now be added to named.conf either directly or > > s/now//, I think. > >> + by including a file containing the key. After all this is done it >> + is just to tell BIND to do > > s/is just/only remains/ > >> + DNSSEC validation on queries. This is achieved by >> + editing named.conf and add the following to the > > "adding", for consistency with "editing" > >> + options directive: >> +dnssec-enable yes; >> +dnssec-validation yes; >> + >> + >> + To verify that it is actually working, use >> + dig to make a query for a signed zone >> + using the resolver just set up. A successful reply will contain > > s/just set up/as just configured/ would be less informal. > >> + the AD >> + flag to indicate the data was authenticated. Running a >> + query such as &prompt.user; dig @resolver +dnssec > > Is this "@resolver" supposed to be "@[IP address or hostname of resolver > just configured]"? I suspect there is markup for this, if so. > >> + se ds should return the DS >> + RR for the .se zone. In the >> + flags: section the >> + AD flag should be set, as seen >> + in: >> +... >> +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 >> +... >> + . This means that the resolver is now capable of >> + authenticate made DNSqueries. > > The clause "now capable of authenticate made" doesn't make any sense to me. > >> + >> + >> + >> + Authorative <acronym>DNS</acronym> server configuration > > "Authoritative", again. > >> + In order to get an authorative nameserver to serve a > > and here. > >> + DNSSEC signed zone, a little more work is >> + required. To sign a zone, two cryptographic keys for that zone must >> + be generated. These two keys are usually called the Key Signing Key >> + (KSK) and Zone Signing Key >> + (ZSK) respectively. The >> + KSK is used to build a chain >> + of authority to the data in need of validation and as such also called > > put an "is" in "and as such also called"; there's a couple of places to > choose from. > >> + a Secure Entry Point (SEP) key. This key needs to be published in the >> + parent zone as well, to establish the trust chain. How this is >> + accomplished depends on the parent zone owner. The ZSK is used to sign the zone, and only needs to >> + be published there. >> + >> + To enable DNSSEC for the > + role="domainname">example.com zone depicted in previous >> + examples, the first step is to use >> + dnssec-keygen to generate the >> + KSK and ZSK keypair. This keypair >> + can utilize different cryptograhic algorithms. Currently the mandatory >> + algorithm is RSA/SHA-1. In the examples the key >> + length used is 2048 bits for the KSK and 1024 bits >> + for the ZSK. To generate the >> + KSK for > + role="domainname">example.com, run &promt.user; >> + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE >> + example.com and to generate the >> + ZSK, run &promt.user; >> + dnssec-keygen -a RSASHA1 -b 1024 -n ZONE >> + example.com. >> + dnssec-keygen outputs two files, the public >> + and the private keys in files named similar to >> + Kexample.com.+005+nnnnn.key (public) and >> + Kexample.com.+005+nnnnn.private (private). The >> + nnnnn part of the file name is a five digit key ID. >> + Keep track of which key ID belongs to which key. This is especially >> + important when having more than one key in a zone. The public key >> + files can now be included in the zone file, using the >> + $include statement. It should look something like >> + this: >> +$include Kexample.net.+005+nnnnn.key ; ZSK >> +$include Kexample.net.+005+nnnnn.key ; KSK >> + >> + >> + The only steps left is to sign the zone and tell > > s/is/are/ > >> + BIND to use the signed zonefile. To sign a zone >> + dnssec-signzone is used. The command to >> + sign the zone example.com, >> located in >> + example.com.db would look similar to >> + &promt.user; dnssec-signzone -o example.com -k >> + Kexample.com+005+nnnnn example.com.db >> + Kexample.com+005+nnnnn.key. The key supplied to >> + the -k argument is the KSK and >> + the other key file is the ZSK that should be used >> + in the signing. It is possible to supply more than one >> + KSK and ZSK, which will result >> + in the zone being signed with all supplied keys. This can be needed >> + to supply zone data signed using more than one algorithm. The output >> + of dnssec-signzone is a zone file with all >> + RRs signed. This output will end up in a file with >> + the extension .signed, such as >> + example.com.db.signed. To use this signed zone >> + just modify the zone directive in named.conf to >> + use this file. By default, the signatures are only valid 30 days, >> + meaning that the zone needs to be resigned within this time. It is >> + possible to make a script and a cron job to do this. See relevant >> + manuals for details. >> + Some cautionary words at the end. Be sure to keep private keys >> + confidential, as with all cryptographic keys. When changing a key it >> + is best to include the new key into the zone, while still signing with >> + the old key, and then move over to using the new key to sign. After >> + these steps are done the old key can be removed from the zone. >> + Failiure to do this might render the DNS data >> + unavailable for a time, untill the new key has propagated through the >> + DNS hierarchy. For more information on key >> + rollovers and other DNSSEC operational issues, see >> + > + url="http://www.ietf.org/rfc/rfc4641.txt">RFC 4641: >> + DNSSEC Operational practices. >> + >> + >> + >> + Automation using <acronym>BIND</acronym>9.7 or later >> + Beginning with BIND version 9.7, a new feature >> + called Smart Signing was introduced. This >> + feature aims to make the key management and signing process simpler by >> + automating parts of the task. By putting the keys into a directory, >> + from now on called a key repository, and using the new option >> + auto-dnssec it is possible to create a dynamic zone >> + which will be resigned as needed. To update this zone the tool >> + nsupdate with the new option >> + -l is used. rndc has >> + also grown the ability to sign zones with keys in the key repository, >> + using the option sign. To make this work, put >> + something similar to what is shown below into >> + named.conf. >> +zone example.com { >> + type master; >> + key-directory "keys"; >> + update-policy local; >> + auto-dnssec maintain; >> + file "dynamic/example.com.zone"; >> +}; >> + This will tell named to use automatic signing and >> + updating of the zone example.com. >> + After this is done just generate keys for the zone as explained in >> + , put these in the key repository >> + denoted by key-directory in the zone configuration > > "denoted by" could be ambiguous -- "given as the argument to the > key-directory directive" might be better. > >> + and sign the zone using rndc. Updates to >> + the zone is done using nsupdate which will > > I'm not sure what is intended, here. Is it trying to say that further > updates to the zone must only be done using nsupdate, which will > automatically re-sign the zone? > >> + take care of resigning the zone with the new data added. For further >> + details, see and the >> + BIND documentation. >> + >> + >> + >> + >> + >> Security >> >> Although BIND is the most common implementation of DNS, >> @@ -3897,7 +4184,7 @@ >> >> >> >> - >> + >> Further Reading >> >> BIND/named manual pages: >> @@ -3932,6 +4219,38 @@ >> url="http://tools.ietf.org/html/rfc1035">RFC1035 >> - Domain Names - Implementation and Specification >> > > Hmm, I kind of want all of these to be —es. > > Thanks for putting together this DNSSEC section -- it will be really > great to have it more widely deployed! > > -Ben Kaduk > >> + >> + >> + > + url="http://tools.ietf.org/html/rfc4033">RFC4033 >> + - DNS Security Introduction and Requirements >> + >> + >> + >> + > + url="http://tools.ietf.org/html/rfc4034">RFC4034 >> + - Recource Records for the DNS Security Extensions >> + >> + >> + >> + > + url="http://tools.ietf.org/html/rfc4035">RFC4035 >> + - Protocol Modifications for the DNS Security Extensions >> + >> + >> + >> + > + url="http://tools.ietf.org/html/rfc4641">RFC4641 >> + - DNSSEC Operational Practices >> + >> + >> + >> + > + url="http://tools.ietf.org/html/rfc5011">RFC 5011 >> + - Automated Updates of DNS Security (DNSSEC >> + Trust Anchors >> + >> + >> >> >> >> --- network-servers.chapter.sgml.diff ends here --- >> >> >>> Release-Note: >>> Audit-Trail: >>> Unformatted: >> _______________________________________________ >> freebsd-doc@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-doc >> To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-doc@FreeBSD.ORG Sun May 22 20:42:42 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9D434106566B; Sun, 22 May 2011 20:42:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9F86014E25B; Sun, 22 May 2011 20:42:41 +0000 (UTC) Message-ID: <4DD97540.8090705@FreeBSD.org> Date: Sun, 22 May 2011 13:42:40 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Daniel Gerzo References: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> <4DD96FF3.8080101@FreeBSD.org> In-Reply-To: <4DD96FF3.8080101@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-doc@freebsd.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 20:42:42 -0000 On 05/22/2011 13:20, Daniel Gerzo wrote: > I believe the right person for the tech review is dougb@ (cc:ing him) Thanks for your confidence in me. :) Niclas actually contacted me privately so I'll definitely be taking a look. However that shouldn't prevent other knowledgeable people from chiming in. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-doc@FreeBSD.ORG Sun May 22 21:50:10 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E1F2106566C for ; Sun, 22 May 2011 21:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3F78FC0C for ; Sun, 22 May 2011 21:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4MLoARe086490 for ; Sun, 22 May 2011 21:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4MLoAQx086489; Sun, 22 May 2011 21:50:10 GMT (envelope-from gnats) Date: Sun, 22 May 2011 21:50:10 GMT Message-Id: <201105222150.p4MLoAQx086489@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 21:50:10 -0000 The following reply was made to PR docs/157245; it has been noted by GNATS. From: Niclas Zeising To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Sun, 22 May 2011 23:45:05 +0200 This is a multi-part message in MIME format. --------------020301000301000000020306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi! Here is an updated patch with changes based on suggestions from Ben Kaduk and Warren Block. Thank you very much for your help! -- Niclas --------------020301000301000000020306 Content-Type: text/plain; name="network-servers.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network-servers.chapter.sgml.diff" Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ chapter.sgml 22 May 2011 20:40:32 -0000 @@ -3872,6 +3872,293 @@ + DNSSEC + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or DNSSEC + for short, is a suite of specifications to protect + DNS clients, i.e. Internet resolvers, from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity and authenticity of the record. Note that + DNSSEC only provides integrity, it does not + provide neither confidentiality nor protection against false + assumptions. This meanins that it cannot protect against people going + to example.net instead of + example.com. The only + thing DNSSEC does is authenticate that the data is + from the domain owner and that it has not been compromised in transit. + The security of DNS is believed to be an important + step in securing the Internet in general. For a more in-depth + details of how DNSSEC works, the relevant + RFCs are a good place to start. See the list in + . + + The next two sections will demonstrate how to enable + DNSSEC for an authoritative DNS + server and a recursive (or caching) DNS server + running BIND9. While all versions of + BIND9 support DNSSEC, it is + necessary to have at least version 9.6.2 in order to be able to use the + signed root zone when validating DNS queries. This is + because earlier versions lack the required algorithms to enable + validation using the root zone key. It is strongly recommended to use + BIND 9.7 or later to take advantage of automatic + key updating for the root key, as well as other features to + automatically keep zones signed and signatures up to date. Where + configurations differ between 9.6.2 and 9.7 and later, differences + will be pointed out. + + + Recursive <acronym>DNS</acronym> server configuration + + Enabling DNSSEC validation of queries done by + a recursive DNS server reqires a few changes to + named.conf. Before making these changes + the root zone key, or trust anchor, must be aquired. Currently the + root zone key is not available in a file format + BIND understands, so it has to be manually + converted into the proper format. The key itself can be obtained by + querying the root zone for it, using dig. + By running &prompt.user; dig +multi +noall + +answer DNSKEY . > root.dnskey the key will + end up in root.dnskey. The contents should look + something like this: +. 93910 IN DNSKEY 257 3 8 ( + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= + ) ; key id = 19036 +. 93910 IN DNSKEY 256 3 8 ( + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt + ) ; key id = 34525 + Do not be alarmed if the obtained keys differ from + this example, they might have changed since these instructions were + last updated. This output actually contains two keys. The first + key in the listing, with the value 257 behind the DNSKEY record + type, is the one needed. This value indicates that this is a + Secure Entry Point (SEP, + more commonly known as a Key Signing Key + (KSK). The second key, + with value 256, is a subordinate key, commonly called a Zone Signing + Key (ZSK). More on the + different key types later in the section . + + Now the key must be verified verified and formatted so that + BIND can use it. To verify the key, generate a + DS + RR set. Create a file + containing these RRs with + &prompt.user; dnssec-dsfromkey -f root-dnskey . + > root.ds. These records use SHA-1 and + SHA-256 respectively, and should look similar to the following + example, where the longer is using SHA-256. +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + The SHA-256 RR can now be + compared to the digest in + https://data.iana.org/root-anchors/root-anchors.xml. To be + absolutely sure that the key has not been tampered with, the data in + the XML file can be verified using the + PGP signature in + https://data.iana.org/root-anchors/root-anchors.asc. + + Next, the key must be formatted properly. This differs a + little between BIND versions 9.6.2 and 9.7 and + later. Both use a managed-keys clause, but + support for initial-key was added in 9.7. + initial-key makes BIND + automatically track changes to the key and update it as necesarry. + Users of BIND 9.6.2 must do this manually. + For BIND 9.6.2 the format should look like: + +managed-keys { + "." 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + For 9.7 the format will instead be: + +managed-keys { + "." initial-key 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + The managed-keys directive can + now be added to named.conf either directly or + by including a file containing the key. After these steps, tell + BIND to do DNSSEC validation + on queries by editing named.conf and adding the + following to the options directive: + +dnssec-enable yes; +dnssec-validation yes; + + + To verify that it is actually working, use + dig to make a query for a signed zone + using the resolver just configured. A successful reply will contain + the AD + flag to indicate the data was authenticated. Running a + query such as &prompt.user; dig + @resolver +dnssec se ds + should return the DS + RR for the .se zone. In the + flags: section the + AD flag should be set, as seen + in: +... +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 +... + . This means that the resolver is now capable of + authenticating DNSqueries. + + + + Authoritative <acronym>DNS</acronym> server configuration + In order to get an authoritative nameserver to serve a + DNSSEC signed zone, a little more work is + required. To sign a zone, two cryptographic keys for that zone must + be generated. These two keys are usually called the Key Signing Key + (KSK) and Zone Signing Key + (ZSK) respectively. The + KSK is used to build a chain + of authority to the data in need of validation and as such is also + called a Secure Entry Point + (SEP) key. This key + needs to be published in the parent zone as well, to establish the + trust chain. How this is accomplished depends on the parent zone + owner. The ZSK is used + to sign the zone, and only needs to be published there. + + To enable DNSSEC for the example.com zone depicted in previous + examples, the first step is to use + dnssec-keygen to generate the + KSK and ZSK keypair. This keypair + can utilize different cryptograhic algorithms. Currently the mandatory + algorithm is RSA/SHA-1. In the examples the key + length used is 2048 bits for the KSK and 1024 bits + for the ZSK. To generate the + KSK for example.com, run &prompt.user; + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE + example.com and to generate the + ZSK, run &prompt.user; + dnssec-keygen -a RSASHA1 -b 1024 -n ZONE + example.com. + dnssec-keygen outputs two files, the public + and the private keys in files named similar to + Kexample.com.+005+nnnnn.key (public) and + Kexample.com.+005+nnnnn.private (private). The + nnnnn part of the file name is a five digit key ID. + Keep track of which key ID belongs to which key. This is especially + important when having more than one key in a zone. The public key + files can now be included in the zone file, using the + $include statement. It should look something like + this: +$include Kexample.net.+005+nnnnn.key ; ZSK +$include Kexample.net.+005+nnnnn.key ; KSK + + + Finally, sign the zone and tell BIND to use + the signed zonefile. To sign a zone + dnssec-signzone is used. The command to + sign the zone example.com, located in + example.com.db would look similar to + &prompt.user; dnssec-signzone -o example.com -k + Kexample.com+005+nnnnn example.com.db + Kexample.com+005+nnnnn.key. The key supplied to + the -k argument is the KSK and + the other key file is the ZSK that should be used + in the signing. It is possible to supply more than one + KSK and ZSK, which will result + in the zone being signed with all supplied keys. This can be needed + to supply zone data signed using more than one algorithm. The output + of dnssec-signzone is a zone file with all + RRs signed. This output will end up in a file with + the extension .signed, such as + example.com.db.signed. To use this signed zone + just modify the zone directive in named.conf to + use this file. By default, the signatures are only valid 30 days, + meaning that the zone needs to be resigned within this time. It is + possible to make a script and a cron job to do this. See relevant + manuals for details. + Some cautionary words at the end. Be sure to keep private keys + confidential, as with all cryptographic keys. When changing a key it + is best to include the new key into the zone, while still signing with + the old key, and then move over to using the new key to sign. After + these steps are done the old key can be removed from the zone. + Failiure to do this might render the DNS data + unavailable for a time, until the new key has propagated through the + DNS hierarchy. For more information on key + rollovers and other DNSSEC operational issues, see + RFC 4641: + DNSSEC Operational practices. + + + + Automation using <acronym>BIND</acronym>9.7 or later + Beginning with BIND version 9.7, a new feature + called Smart Signing was introduced. This + feature aims to make the key management and signing process simpler by + automating parts of the task. By putting the keys into a directory + called a key repository, and using the new option + auto-dnssec, it is possible to create a dynamic zone + which will be resigned as needed. To update this zone use + nsupdate with the new option + . rndc has + also grown the ability to sign zones with keys in the key repository, + using the option . To tell + BIND to use this automatic signing and zone + updating for exanple.com, add the + following to named.conf: +zone example.com { + type master; + key-directory "keys"; + update-policy local; + auto-dnssec maintain; + file "dynamic/example.com.zone"; +}; + After making these changes, generate keys for the zone as explained in + , put those keys in the key repository + given as the argument to the key-directory in the + zone configuration and sign the zone using + rndc. Updates to a zone configured this + way must be done using nsupdate, which will + take care of re-signing the zone with the new data added. For further + details, see and the + BIND documentation. + + + + + Security Although BIND is the most common implementation of DNS, @@ -3897,11 +4184,12 @@ - + Further Reading BIND/named manual pages: - &man.rndc.8; &man.named.8; &man.named.conf.5; + &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8; + &man.dnssec-signzone.8; &man.dnssec-keygen.8; @@ -3932,6 +4220,38 @@ url="http://tools.ietf.org/html/rfc1035">RFC1035 - Domain Names - Implementation and Specification + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Recource Records for the DNS Security Extensions + + + + RFC4035 + - Protocol Modifications for the DNS Security Extensions + + + + RFC4641 + - DNSSEC Operational Practices + + + + RFC 5011 + - Automated Updates of DNS Security (DNSSEC + Trust Anchors + + --------------020301000301000000020306-- From owner-freebsd-doc@FreeBSD.ORG Sun May 22 23:30:15 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA738106566B for ; Sun, 22 May 2011 23:30:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 97B418FC0A for ; Sun, 22 May 2011 23:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4MNUFk0075826 for ; Sun, 22 May 2011 23:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4MNUFpb075821; Sun, 22 May 2011 23:30:15 GMT (envelope-from gnats) Date: Sun, 22 May 2011 23:30:15 GMT Message-Id: <201105222330.p4MNUFpb075821@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 23:30:15 -0000 The following reply was made to PR docs/157245; it has been noted by GNATS. From: Niclas Zeising To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Mon, 23 May 2011 01:25:55 +0200 This is a multi-part message in MIME format. --------------040500050509000704050409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is a further updated patch. It fixes some typos and other similar stuff. It also adds manual pages to man-refs.ent. Regards! -- Niclas --------------040500050509000704050409 Content-Type: text/plain; name="network-servers.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network-servers.chapter.sgml.diff" Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 22 May 2011 22:49:58 -0000 @@ -3872,6 +3872,292 @@ + DNSSEC + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or DNSSEC + for short, is a suite of specifications to protect + DNS clients, i.e. Internet resolvers, from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity and authenticity of the record. Note that + DNSSEC only provides integrity, it does not + provide neither confidentiality nor protection against false + assumptions. This meanins that it cannot protect against people going + to example.net instead of + example.com. The only + thing DNSSEC does is authenticate that the data is + from the domain owner and that it has not been compromised in transit. + The security of DNS is believed to be an important + step in securing the Internet in general. For a more in-depth + details of how DNSSEC works, the relevant + RFCs are a good place to start. See the list in + . + + The next two sections will demonstrate how to enable + DNSSEC for an authoritative DNS + server and a recursive (or caching) DNS server + running BIND9. While all versions of + BIND9 support DNSSEC, it is + necessary to have at least version 9.6.2 in order to be able to use the + signed root zone when validating DNS queries. This is + because earlier versions lack the required algorithms to enable + validation using the root zone key. It is strongly recommended to use + BIND 9.7 or later to take advantage of automatic + key updating for the root key, as well as other features to + automatically keep zones signed and signatures up to date. Where + configurations differ between 9.6.2 and 9.7 and later, differences + will be pointed out. + + + Recursive <acronym>DNS</acronym> server configuration + + Enabling DNSSEC validation of queries done by + a recursive DNS server reqires a few changes to + named.conf. Before making these changes + the root zone key, or trust anchor, must be aquired. Currently the + root zone key is not available in a file format + BIND understands, so it has to be manually + converted into the proper format. The key itself can be obtained by + querying the root zone for it, using dig. + By running + &prompt.user; dig +multi +noall +answer DNSKEY . > root.dnskey + the key will end up in root.dnskey. The + contents should look something like this: +. 93910 IN DNSKEY 257 3 8 ( + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= + ) ; key id = 19036 +. 93910 IN DNSKEY 256 3 8 ( + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt + ) ; key id = 34525 + Do not be alarmed if the obtained keys differ from + this example, they might have changed since these instructions were + last updated. This output actually contains two keys. The first + key in the listing, with the value 257 behind the DNSKEY record + type, is the one needed. This value indicates that this is a + Secure Entry Point + (SEP), + more commonly known as a Key Signing Key + (KSK). The second key, + with value 256, is a subordinate key, commonly called a Zone Signing + Key (ZSK). More on the + different key types later in the . + + + Now the key must be verified verified and formatted so that + BIND can use it. To verify the key, generate a + DS + RR set. Create a file + containing these RRs with + &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds + These records use SHA-1 and SHA-256 respectively, and should look + similar to the following example, where the longer is using SHA-256. + +. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + The SHA-256 RR can now be + compared to the digest in + https://data.iana.org/root-anchors/root-anchors.xml. To be + absolutely sure that the key has not been tampered with, the data in + the XML file can be verified using the + PGP signature in + https://data.iana.org/root-anchors/root-anchors.asc. + + Next, the key must be formatted properly. This differs a + little between BIND versions 9.6.2 and 9.7 and + later. Both use a managed-keys clause, but + support for initial-key was added in 9.7. + initial-key makes BIND + automatically track changes to the key and update it as necesarry. + Users of BIND 9.6.2 must do this manually. + For BIND 9.6.2 the format should look like: + +managed-keys { + "." 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + For 9.7 the format will instead be: + +managed-keys { + "." initial-key 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + The managed-keys directive can + now be added to named.conf either directly or + by including a file containing the key. After these steps, tell + BIND to do DNSSEC validation + on queries by editing named.conf and adding the + following to the options directive: + +dnssec-enable yes; +dnssec-validation yes; + + + To verify that it is actually working, use + dig to make a query for a signed zone + using the resolver just configured. A successful reply will contain + the AD flag to indicate the data was + authenticated. Running a query such as + &prompt.user; dig @resolver +dnssec se ds + should return the DS RR for + the .se zone. In the flags: section the + AD flag should be set, as seen + in: +... +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 +... + This means that the resolver is now capable of + authenticating DNS queries. + + + + Authoritative <acronym>DNS</acronym> server configuration + In order to get an authoritative nameserver to serve a + DNSSEC signed zone, a little more work is + required. To sign a zone, two cryptographic keys for that zone must + be generated. These two keys are usually called the Key Signing Key + (KSK) and Zone Signing Key + (ZSK) respectively. The + KSK is used to build a chain + of authority to the data in need of validation and as such is also + called a Secure Entry Point + (SEP) key. This key + needs to be published in the parent zone as well, to establish the + trust chain. How this is accomplished depends on the parent zone + owner. The ZSK is used + to sign the zone, and only needs to be published there. + + To enable DNSSEC for the example.com zone depicted in previous + examples, the first step is to use + dnssec-keygen to generate the + KSK and ZSK keypair. This keypair + can utilize different cryptograhic algorithms. Currently the mandatory + algorithm is RSA/SHA-1. In the examples the key + length used is 2048 bits for the KSK and 1024 bits + for the ZSK. To generate the + KSK for example.com, run + &prompt.user; dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE example.com + and to generate the + ZSK, run + &prompt.user; dnssec-keygen -a RSASHA1 -b 1024 -n ZONE example.com + dnssec-keygen outputs two files, the public + and the private keys in files named similar to + Kexample.com.+005+nnnnn.key (public) and + Kexample.com.+005+nnnnn.private (private). The + nnnnn part of the file name is a five digit key ID. + Keep track of which key ID belongs to which key. This is especially + important when having more than one key in a zone. The public key + files can now be included in the zone file, using the + $include statement. It should look something like + this: +$include Kexample.net.+005+nnnnn.key ; ZSK +$include Kexample.net.+005+nnnnn.key ; KSK + + + Finally, sign the zone and tell BIND to use + the signed zonefile. To sign a zone + dnssec-signzone is used. The command to + sign the zone example.com, located in + example.com.db would look similar to + &prompt.user; dnssec-signzone -o example.com -k Kexample.com+005+nnnnn example.com.db Kexample.com+005+nnnnn.key + The key supplied to + the argument is the KSK and + the other key file is the ZSK that should be used + in the signing. It is possible to supply more than one + KSK and ZSK, which will result + in the zone being signed with all supplied keys. This can be needed + to supply zone data signed using more than one algorithm. The output + of dnssec-signzone is a zone file with all + RRs signed. This output will end up in a file with + the extension .signed, such as + example.com.db.signed. To use this signed zone + just modify the zone directive in named.conf to + use this file. By default, the signatures are only valid 30 days, + meaning that the zone needs to be resigned within this time. It is + possible to make a script and a cron job to do this. See relevant + manuals for details. + + Some cautionary words at the end. Be sure to keep private keys + confidential, as with all cryptographic keys. When changing a key it + is best to include the new key into the zone, while still signing with + the old key, and then move over to using the new key to sign. After + these steps are done the old key can be removed from the zone. + Failiure to do this might render the DNS data + unavailable for a time, until the new key has propagated through the + DNS hierarchy. For more information on key + rollovers and other DNSSEC operational issues, see + RFC 4641: + DNSSEC Operational practices. + + + + Automation using <acronym>BIND</acronym> 9.7 or later + Beginning with BIND version 9.7, a new feature + called Smart Signing was introduced. This + feature aims to make the key management and signing process simpler by + automating parts of the task. By putting the keys into a directory + called a key repository, and using the new option + auto-dnssec, it is possible to create a dynamic zone + which will be resigned as needed. To update this zone use + nsupdate with the new option + . rndc has + also grown the ability to sign zones with keys in the key repository, + using the option . To tell + BIND to use this automatic signing and zone + updating for exanple.com, add the + following to named.conf: +zone example.com { + type master; + key-directory "keys"; + update-policy local; + auto-dnssec maintain; + file "dynamic/example.com.zone"; +}; + After making these changes, generate keys for the + zone as explained in , put those keys + in the key repository given as the argument to the + key-directory in the zone configuration and sign + the zone using rndc. Updates to a zone + configured this way must be done using + nsupdate, which will take care of + re-signing the zone with the new data added. For further details, + see and the BIND + documentation. + + + + + Security Although BIND is the most common implementation of DNS, @@ -3897,11 +4183,12 @@ - + Further Reading BIND/named manual pages: - &man.rndc.8; &man.named.8; &man.named.conf.5; + &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8; + &man.dnssec-signzone.8; &man.dnssec-keygen.8; @@ -3932,6 +4219,38 @@ url="http://tools.ietf.org/html/rfc1035">RFC1035 - Domain Names - Implementation and Specification + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Recource Records for the DNS Security Extensions + + + + RFC4035 + - Protocol Modifications for the DNS Security Extensions + + + + RFC4641 + - DNSSEC Operational Practices + + + + RFC 5011 + - Automated Updates of DNS Security (DNSSEC + Trust Anchors + + Index: share/sgml/man-refs.ent =================================================================== RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v retrieving revision 1.511 diff -u -d -r1.511 man-refs.ent --- share/sgml/man-refs.ent 11 Feb 2011 16:15:44 -0000 1.511 +++ share/sgml/man-refs.ent 22 May 2011 22:50:40 -0000 @@ -4257,6 +4257,8 @@ + + --------------040500050509000704050409-- From owner-freebsd-doc@FreeBSD.ORG Mon May 23 11:06:06 2011 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85C99106564A for ; Mon, 23 May 2011 11:06:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 756A88FC19 for ; Mon, 23 May 2011 11:06:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NB66U9050916 for ; Mon, 23 May 2011 11:06:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NB65fI050914 for freebsd-doc@FreeBSD.org; Mon, 23 May 2011 11:06:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 May 2011 11:06:05 GMT Message-Id: <201105231106.p4NB65fI050914@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: FreeBSD doc list Cc: Subject: Current unassigned doc problem reports X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 11:06:06 -0000 (Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=doc .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o docs/157245 doc [PATCH] [RFC] Add a section about DNSSEC to the DNS ch o docs/157234 doc [patch] nullfs(5): //proc/curproc/file returns "unknow o docs/157116 doc Mention dovecot as a pop/imap server o docs/157091 doc [handbook] FreeBSD Handbook needs to be updated to ref o docs/157078 doc [patch] su.1: clarify use of -c as shell argument o docs/157075 doc [patch] Use correct device names in gpioctl(8) man pag o docs/157049 doc FreeBSD Handbook: Chapter 14 (Security) Inaccuracy o docs/156955 doc bug in share/man/man2/setsockopt.2 o docs/156920 doc isspecial(3) is not helpful o docs/156868 doc [patch] Typos and grammar in Spanish translation of ar o docs/156815 doc chmod(1): manpage should describe that chmod kicks +t o docs/156742 doc vge(4) manpage states support of jumbo frames o docs/156689 doc stf(4) output-only documentation gives bad configurati p docs/156593 doc [patch] tcpdrop.8: remove incomplete sentence o docs/156222 doc syslog.conf(5): multiple typos in syslog-ng.conf manpa o docs/156187 doc [handbook] [patch] Add bsnmpd to handbook o docs/156081 doc troff falls with troff.core with UTF-8 man with incorr o docs/155989 doc [patch] Fix offset in boot.config(5) s docs/155982 doc [handbook] remove reference to floppy installations o docs/155980 doc [patch] no NO_CHECKSUM in section ENVIRONMENT in man p o docs/155773 doc dialog(1): dialog manpages not updated o docs/155264 doc [handbook] Extend "7.2.2.1 Common Problems" with hw.sn o docs/155149 doc [patch] don't encourage using xorg.conf outside of PRE o docs/154838 doc update cvs-tags information on releng_* to reflect sup o docs/154502 doc xdm authorization failure when used with E17 window ma o docs/154494 doc rcorder(8) not quite accurate o docs/153958 doc ksu man-page documented, but not installed o docs/153738 doc [patch] Docuement requirement to alter some sysctls wh a docs/153012 doc [patch] iostat(8) requires an argument to -c option o docs/151752 doc pw.conf(5) doesn't define format for file clearly o docs/151478 doc [patch] Russian porters-handbook: MFen 1.440 -> 1.1077 o docs/151367 doc [patch] Update for puc.4 man page o docs/150991 doc [patch] Install upgtfw using pkg_add as advised in upg o docs/150917 doc [patch] icmp.4, wrong description of icmplim and icmpl o docs/150877 doc ambiguity in newsyslog(8) man page about zfs with comp o docs/150365 doc [make.conf] [patch] remove BDECFLAGS from make.conf(5) o docs/150255 doc dtrace description should mention makeoptions DEBUG=-g o docs/150244 doc [patch] DRIVER_MODULE(9): MULTI_DRIVER_MODULE is only o docs/150219 doc zfs(8) manual page misses jail/unjail o docs/149845 doc unify spelling of blocksize, block-size and block size o docs/149574 doc [patch] update mi_switch(9) man page o docs/149522 doc Russian network article: incorrect translation about n o docs/149051 doc [request] No document for clang or clang++ o docs/149047 doc [patch] tcsh(1) bears no mention of brace expansion in o docs/148987 doc [patch] {MD[245]|SHA_|SHA1_|SHA256_}{End|File|FileChun o docs/148984 doc [handbook] Mistake in section 16.15.4 of the handbook o docs/148680 doc [sysctl][patch] Document some sys/kern sysctls o docs/148071 doc Failover mode between wired and wireless interfaces o docs/148037 doc bge(4) does not list all devices in if_bge.c / if_bger o docs/147995 doc elf.5 man page has has missing reference o docs/146958 doc bad link to "XaQti XMAC II datasheet" in sk(4) manual o docs/146521 doc [handbook] Update IPv6 system handbook section to ment o docs/145719 doc [patch] 7.3 relnotes erroneously describes new getpage o docs/145699 doc hexdump(1) mutes all format qualifier output following o docs/145644 doc Add artical about creating manpage from scratch o docs/145069 doc Dialup firewalling with FreeBSD article out dated. o docs/145067 doc Remove all reference to floppy installs o docs/145066 doc Update for new uart dev names for serial port. s docs/144818 doc all mailinglist archives dated 19970101 contain traili o docs/144630 doc [patch] domainname(1) manpage contains old information o docs/144537 doc Missing _mdconfig_list and _mdconfig2_list explanation o docs/144515 doc [handbook] Expand handbook Table of contents o docs/144488 doc share/examples/etc/make.conf: contains dangerous examp o docs/144408 doc [patch] update makefs(8) (remove device option) o docs/143850 doc procfs(5) manpage for status > controlling terminal is o docs/143416 doc [handbook] IPFW handbook page issues o docs/143408 doc man filedesc(9) is missing o docs/142917 doc top(1) man page does not include information about VCS a docs/142341 doc jail(8): Jail escape when cwd is moved from the host s o docs/142168 doc [patch] ld(1): ldd(1) not mentioned in ld(1) manpage o docs/141032 doc misleading documentation for rtadvd.conf(5) raflags se s docs/140847 doc [request] add documentation on ECMP and new route args o docs/140457 doc [patch] Grammar fix for isspace(3) o docs/140444 doc [patch] New Traditional Chinese translation of custom- o docs/140375 doc [UPDATE] Updated zh_TW.Big5/articles/nanobsd o docs/140369 doc [patch] src/contrib/pf/man/pf.4 o docs/139336 doc [request] ZFS documentation suggestion o docs/139165 doc gssapi.3 man page out of sync with between crypto and o docs/139018 doc translation of submitting.sgml from docproj/submitting o docs/138887 doc manpage ports(7) incorrect o docs/138845 doc Exceeding kern.ipc.maxpipekva refers to tuning(7) whic o docs/138663 doc system(3) man page confuses users about "return value o docs/138485 doc bpf(4) and ip(4) man pages missing important corner ca o docs/136712 doc [handbook] [patch] draft new section on gmirror per pa o docs/136666 doc [handbook] Configure serial port for remote kernel deb o docs/136035 doc ftpchroot(5) omits an important option p docs/136029 doc MALLOC_PRODUCTION knob should be mentioned somewhere, o docs/135516 doc [patch] pax(1) manual not mentioning chflags unawarene o docs/135475 doc [patch] jot(1) manpage and behaviour differ o docs/134123 doc The RUNQUEUE(9) man page is out of date o docs/132839 doc [patch] Fix example script in ldap-auth article o docs/132718 doc [handbook] Information about adding a new mirror is ou o docs/132260 doc dhcpd(8) pid not stored in documented location o docs/132190 doc EPERM explanation for send(2), sendto(2), and sendmsg( o docs/131918 doc [patch] Fixes for the BPF(4) man page o docs/131684 doc [patch] articles/linux-comparison: replace Addenda by o docs/131626 doc [patch] dump(8) "recommended" cache option confusing o docs/130364 doc Man page for top needs explanation of CPU states o docs/130238 doc nfs.lockd man page doesn't mention NFSLOCKD option or o docs/129671 doc New TCP chapter for Developer's Handbook (from rwatson o docs/129464 doc using packages system o docs/129095 doc ipfw(8): Can not check that packet originating/destine s docs/128356 doc [request] add Firefox plugin for FreeBSD manual pages o docs/127908 doc [patch] readdir(3) error documentation s docs/127844 doc Example code skeleton_capture_n.c in meteor(4) manpage o docs/126590 doc [patch] Write routine called forever in Sample Echo Ps o docs/126484 doc libc function res-zonscut2 is not documented o docs/125921 doc lpd(8) talks about blocks in minfree while it is KB in f docs/122052 doc minor update on handbook section 20.7.1 o docs/121952 doc Handbook chapter on Network Address Translation wrong o docs/121585 doc [handbook] Wrong multicast specification o docs/121565 doc dhcp-options(5) manpage incorrectly formatted omitting s docs/121541 doc [request] no man pages for wlan_scan_ap o docs/121312 doc RELNOTES_LANG breaks release if not en_US.ISO8859-1 o docs/121173 doc [patch] mq_getattr(2): mq_flags mistakenly described a s docs/120917 doc [request]: Man pages mising for thr_xxx syscalls o docs/120539 doc Inconsistent ipfw's man page o docs/120125 doc [patch] Installing FreeBSD 7.0 via serial console and o docs/120024 doc resolver(5) and hosts(5) need updated for IPv6 o docs/119545 doc books/arch-handbook/usb/chapter.sgml formatting o docs/118902 doc [patch] wrong signatures in d2i_RSAPublicKey man pages o docs/118332 doc man page for top does not describe STATE column wait e o docs/118214 doc close(2) error returns incomplete o docs/118020 doc ipfilter(4): man pages query for man 4 ipfilter return o docs/117747 doc 'break' system call needs a man page o docs/116116 doc mktemp (3) re/move note o docs/116080 doc PREFIX is documented, but not the more important LOCAL o docs/115065 doc [patch] sync ps.1 with p_flag and keywords o docs/114371 doc [patch] [ip6] rtadvd.con(5) should show how to adverti o docs/114139 doc mbuf(9) has misleading comments on M_DONTWAIT and M_TR o docs/113194 doc [patch] [request] crontab.5: handling of day-in-month o docs/112804 doc groff(1) command should be called to explicitly use "p o docs/112682 doc Handbook GEOM_GPT explanation does not provide accurat o docs/111425 doc Missing chunks of text in historical manpages o docs/111265 doc [request] Clarify how to set common shell variables o docs/111147 doc hostapd.conf is not documented o docs/110999 doc carp(4) should document unsupported interface types o docs/110692 doc wi(4) man page doesn't say WPA is not supported o docs/110376 doc [patch] add some more explanations for the iwi/ipw fir o docs/110253 doc [patch] rtprio(1): remove processing starvation commen o docs/110062 doc [patch] mount_nfs(8) fails to mention a failure condit p docs/110061 doc [patch] tuning(7) missing reference to vfs.read_max o docs/109981 doc No manual entry for post-grohtml o docs/109977 doc No manual entry for ksu o docs/109973 doc No manual entry for c++filt o docs/109972 doc No manual entry for zless/bzless f docs/109226 doc [request] No manual entry for sntp o docs/109201 doc [request]: manual for callbootd a docs/108980 doc list of missing man pages o docs/106135 doc [request] articles/vinum needs to be updated o docs/105608 doc fdc(4) debugging description staled o docs/104879 doc Howto: Listen to IMA ADPCM .wav files on FreeBSD box o docs/102719 doc [patch] ng_bpf(4) example leads to unneeded promiscuos o docs/100196 doc man login.conf does explain not "unlimited" o docs/99506 doc FreeBSD Handbook addition: IPv6 Server Settings o docs/98974 doc Missing tunables in loader(8) manpage o docs/98115 doc Missing parts after rendering handbook to RTF format o docs/96207 doc Comments of a sockaddr_un structure could confuse one o docs/94625 doc [patch] growfs man page -- document "panic: not enough o docs/92626 doc jail manpage should mention disabling some periodic sc o docs/91506 doc ndis(4) man page should be more specific about support o docs/91174 doc [REQUEST] Handbook: Addition of Oracle 9i installation o docs/91149 doc read(2) can return EINVAL for unaligned access to bloc o docs/88512 doc [patch] mount_ext2fs(8) man page has no details on lar o docs/87936 doc Handbook chapter on NIS/YP lacks good information on a o docs/87857 doc ifconfig(8) wireless options order matters o docs/85128 doc [patch] loader.conf(5) autoboot_delay incompletly desc o docs/84956 doc [patch] intro(5) manpage doesn't mention API coverage o docs/84932 doc new document: printing with an Epson ALC-3000N on Free o docs/84670 doc [patch] tput(1) manpage missing ENVIRONMENT section wi o docs/84317 doc fdp-primer doesn't show class=USERNAME distinctively o docs/84271 doc [patch] compress(1) doesn't warn about nasty link hand o docs/83820 doc getino(3) manpage not installed o docs/81611 doc [patch] natd runs with -same_ports by default o docs/78480 doc Networked printer setup unnecessarily complex in handb o docs/61605 doc [request] Improve documentation for i386 disk geometry o docs/61301 doc [patch] Manpage patch for aue(4) to enable HomePNA fun o docs/59835 doc ipfw(8) man page does not warn about accepted but mean o docs/59477 doc Outdated Info Documents at http://docs.freebsd.org/inf o docs/59044 doc [patch] doc.docbook.mk does not properly handle a sour s docs/54752 doc bus_dma explained in ISA section in Handbook: should b o docs/53751 doc bus_dma(9) incorrectly documents BUS_DMA_ALLOCNOW o docs/53596 doc Updates to mt(1) manual page o docs/53271 doc bus_dma(9) fails to document alignment restrictions o docs/51480 doc Multiple undefined references in the FreeBSD manual pa o docs/50211 doc [patch] doc.docbook.mk: fix textfile creation o docs/48101 doc [patch] Add documentation on the fixit disk o docs/43823 doc [patch] update to environ(7) manpage o docs/41089 doc pax(1) -B option does not mention interaction with -z o docs/40423 doc Keyboard(4)'s definition of parameters to GETFKEY/SETF o docs/38982 doc [patch] developers-handbook/Jail fix o docs/38556 doc EPS file of beastie, as addition to existing examples s docs/35678 doc docproj Makefiles for web are broken for paths with sp s docs/33589 doc [patch] to doc.docbook.mk to post process .tex files. a docs/30008 doc [patch] French softupdates document should be translat o docs/27605 doc [patch] Cross-document references () o docs/26286 doc *printf(3) etc should gain format string warnings o docs/24786 doc missing FILES descriptions in sa(4) s docs/20028 doc ASCII docs should reflect tags in the sourc 199 problems total. From owner-freebsd-doc@FreeBSD.ORG Mon May 23 11:19:21 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C8CF1065672; Mon, 23 May 2011 11:19:21 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA81F8FC1F; Mon, 23 May 2011 11:19:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NBJKXp064247; Mon, 23 May 2011 11:19:20 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NBJKhY064243; Mon, 23 May 2011 11:19:20 GMT (envelope-from bcr) Date: Mon, 23 May 2011 11:19:20 GMT Message-Id: <201105231119.p4NBJKhY064243@freefall.freebsd.org> To: remko@FreeBSD.org, bcr@FreeBSD.org, freebsd-doc@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/91174: [REQUEST] Handbook: Addition of Oracle 9i installation documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 11:19:21 -0000 Synopsis: [REQUEST] Handbook: Addition of Oracle 9i installation documentation State-Changed-From-To: open->closed State-Changed-By: bcr State-Changed-When: Mon May 23 11:16:43 UTC 2011 State-Changed-Why: Close this PR as no progress has been made on it. If someone wants to contribute newer instructions for running recent Oracle versions, it is probably better to file a new PR rather than finding and attaching it to this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=91174 From owner-freebsd-doc@FreeBSD.ORG Mon May 23 11:33:55 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D72C61065674; Mon, 23 May 2011 11:33:55 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B12BD8FC21; Mon, 23 May 2011 11:33:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NBXtSs082473; Mon, 23 May 2011 11:33:55 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NBXtfb082468; Mon, 23 May 2011 11:33:55 GMT (envelope-from bcr) Date: Mon, 23 May 2011 11:33:55 GMT Message-Id: <201105231133.p4NBXtfb082468@freefall.freebsd.org> To: ohauer@gmx.de, bcr@FreeBSD.org, freebsd-doc@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/140369: [patch] src/contrib/pf/man/pf.4 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 11:33:55 -0000 Synopsis: [patch] src/contrib/pf/man/pf.4 State-Changed-From-To: open->closed State-Changed-By: bcr State-Changed-When: Mon May 23 11:29:31 UTC 2011 State-Changed-Why: The proposed fix is included in OpenBSD's pf man page. It will be available in FreeBSD once we import their latest version that also includes that man page. Close this PR, knowing full well that it might take some time before this fix will be available in FreeBSD as well. http://www.freebsd.org/cgi/query-pr.cgi?pr=140369 From owner-freebsd-doc@FreeBSD.ORG Mon May 23 12:34:00 2011 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90381106564A; Mon, 23 May 2011 12:34:00 +0000 (UTC) (envelope-from ohauer@FreeBSD.org) Received: from u18-124.dslaccess.de (unknown [194.231.39.124]) by mx1.freebsd.org (Postfix) with ESMTP id 425428FC16; Mon, 23 May 2011 12:34:00 +0000 (UTC) Received: from [10.6.25.100] (cde1100.uni.vrs [10.6.25.100]) (Authenticated sender: ohauer) by u18-124.dslaccess.de (Postfix) with ESMTPSA id 9D70420404; Mon, 23 May 2011 14:33:55 +0200 (CEST) Message-ID: <4DDA5430.6070306@FreeBSD.org> Date: Mon, 23 May 2011 14:33:52 +0200 From: Olli Hauer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: bcr@FreeBSD.org References: <201105231133.p4NBXtfb082468@freefall.freebsd.org> In-Reply-To: <201105231133.p4NBXtfb082468@freefall.freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-doc@FreeBSD.org Subject: Re: docs/140369: [patch] src/contrib/pf/man/pf.4 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ohauer@FreeBSD.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 12:34:00 -0000 On 2011-05-23 13:33, bcr@FreeBSD.org wrote: > Synopsis: [patch] src/contrib/pf/man/pf.4 > > State-Changed-From-To: open->closed > State-Changed-By: bcr > State-Changed-When: Mon May 23 11:29:31 UTC 2011 > State-Changed-Why: > The proposed fix is included in OpenBSD's pf man page. > It will be available in FreeBSD once we import their > latest version that also includes that man page. Close > this PR, knowing full well that it might take some time > before this fix will be available in FreeBSD as well. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=140369 Hm, whats the reason to not fix simple manpage? The API is implemented in FreeBSD and I have used DIOCKILLSTATES for example in the snortsam ssp_pf2.c module. The OpenBSD documentation is really good, but even the older one does not match the FreeBSD implementation in some places. I guess the next 7.x/ 8.x release will not include a never pf version, so why not fix existing documentation? Anyway thanks for looking into this Regards, olli From owner-freebsd-doc@FreeBSD.ORG Mon May 23 12:50:17 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FFD8106568F for ; Mon, 23 May 2011 12:50:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 58D778FC22 for ; Mon, 23 May 2011 12:50:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NCoED2050384 for ; Mon, 23 May 2011 12:50:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NCoEId050383; Mon, 23 May 2011 12:50:14 GMT (envelope-from gnats) Date: Mon, 23 May 2011 12:50:14 GMT Message-Id: <201105231250.p4NCoEId050383@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 12:50:17 -0000 The following reply was made to PR docs/157245; it has been noted by GNATS. From: Niclas Zeising To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Mon, 23 May 2011 14:46:30 +0200 This is a multi-part message in MIME format. --------------090906090406000801020902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After comments from Doug Barton and more comments from Warren Block, here is a further refined patch with some changes and spelling fixes. It also contains the necessary changes to man-refs.ent. Thank you for the help and review! -- Niclas --------------090906090406000801020902 Content-Type: text/plain; name="network-servers.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network-servers.chapter.sgml.diff" Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 23 May 2011 12:10:10 -0000 @@ -3872,6 +3872,325 @@ + <acronym role="Doman Name Security Extensions">DNSSEC</acronym> + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or + DNSSEC + for short, is a suite of specifications to protect + resolving name servers from forged DNS data, + such as spoofed DNS records. By using digital + signatures, a resolver can verify the integrity of the record. Note + that DNSSEC + only provides integrity via digitally signing the Resource Records + (RRs). It provides neither + confidentiality nor protection against false end-user assumptions. + This means that it cannot protect against people going to + example.net instead of + example.com. The only + thing DNSSEC does is authenticate that the data + has not been compromised in transit. + The security of DNS is an important step in + securing the Internet in general. For more in-depth details of how + DNSSEC works, the relevant + RFCs are a good place to start. See the list in + . + + The following sections will demonstrate how to enable + DNSSEC for an authoritative DNS + server and a recursive (or caching) DNS server + running BIND 9. While all versions of + BIND 9 support DNSSEC, it is + necessary to have at least version 9.6.2 in order to be able to use + the signed root zone when validating DNS queries. + This is because earlier versions lack the required algorithms to enable + validation using the root zone key. It is strongly recommended to use + the latest version of BIND 9.7 or later to take + advantage of automatic key updating for the root key, as well as other + features to automatically keep zones signed and signatures up to date. + Where configurations differ between 9.6.2 and 9.7 and later, + differences will be pointed out. + + + Recursive <acronym>DNS</acronym> server configuration + + Enabling DNSSEC validation of queries + performed by a recursive DNS server requires a + few changes to named.conf. Before making these + changes the root zone key, or trust anchor, must be acquired. + Currently the root zone key is not available in a file format + BIND understands, so it has to be manually + converted into the proper format. The key itself can be obtained by + querying the root zone for it using dig. + By running + &prompt.user; dig +multi +noall +answer DNSKEY . > root.dnskey + the key will end up in root.dnskey. The + contents should look something like this: + + . 93910 IN DNSKEY 257 3 8 ( + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= + ) ; key id = 19036 +. 93910 IN DNSKEY 256 3 8 ( + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt + ) ; key id = 34525 + + Do not be alarmed if the obtained keys differ from this example. + They might have changed since these instructions were last updated. + This output actually contains two keys. The first key in the + listing, with the value 257 after the DNSKEY record type, is the one + needed. This value indicates that this is a Secure Entry Point + (SEP), + commonly known as a Key Signing Key + (KSK). The second key, + with value 256, is a subordinate key, commonly called a Zone Signing + Key (ZSK). More on the + different key types later in the . + + + Now the key must be verified and formatted so that + BIND can use it. To verify the key, generate a + DS + RR set. Create a file + containing these RRs with + &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds + These records use SHA-1 and SHA-256 respectively, and should look + similar to the following example, where the longer is using SHA-256. + + + . IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + + The SHA-256 RR can now be compared to the + digest in + https://data.iana.org/root-anchors/root-anchors.xml. To be + absolutely sure that the key has not been tampered with the data in + the XML file can be verified using the + PGP signature in + https://data.iana.org/root-anchors/root-anchors.asc. + + Next, the key must be formatted properly. This differs a + little between BIND versions 9.6.2 and 9.7 and + later. In version 9.7 support was added to automatically track + changes to the key and update it as necessary. This is done using + managed-keys as seen in the example below. + When using the older version, the key is added using a + trusted-keys statement and updates must be done + manually. For BIND 9.6.2 the format should look + like: + + trusted-keys { + "." 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + + For 9.7 the format will instead be: + + managed-keys { + "." initial-key 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + + The root key can now be added to named.conf + either directly or by including a file containing the key. After + these steps, configure BIND to do + DNSSEC validation on queries by editing + named.conf and adding the following to the + options directive: + + dnssec-enable yes; +dnssec-validation yes; + + To verify that it is actually working use + dig to make a query for a signed zone + using the resolver just configured. A successful reply will contain + the AD flag to indicate the data was + authenticated. Running a query such as + &prompt.user; dig @resolver +dnssec se ds + should return the DS RR for + the .se zone. In the flags: + section the AD flag should be set, as seen in: + + + ... +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 +... + + The resolver is now capable of authenticating + DNS queries. + + + + Authoritative <acronym>DNS</acronym> server configuration + + In order to get an authoritative name server to serve a + DNSSEC signed zone a little more work is + required. A zone is signed using cryptographic keys which must be + generated. It is possible to use only one key for this. The + preferred method however is to have a strong well-protected Key Signing Key + (KSK) that is not rotated + very often and a Zone Signing Key + (ZSK) that is rotated more + frequently. Information on recommended operational practices can be + found in + RFC 4641: DNSSEC Operational + Practices. Practices regarding the root zone can be found in + + DNSSEC Practice Statement for the Root Zone + KSK operator and + + DNSSEC Practice Statement for the Root Zone + ZSK operator. The + KSK is used to build a chain + of authority to the data in need of validation and as such is also + called a Secure Entry Point + (SEP) key. A message + digest of this key, called a Delegation Signer + (DS) record, must be + published in the parent zone to establish the trust chain. How + this is accomplished depends on the parent zone owner. The + ZSK is used + to sign the zone, and only needs to be published there. + + To enable DNSSEC for the example.com zone depicted in previous + examples, the first step is to use + dnssec-keygen to generate the + KSK and ZSK key pair. This + key pair can utilize different cryptographic algorithms. It is + recommended to use RSA/SHA256 for the keys and 2048 bits key length + should be enough. To generate the KSK for + example.com, run + &prompt.user; dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com + and to generate the + ZSK, run + &prompt.user; dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com + dnssec-keygen outputs two files, the public + and the private keys in files named similar to + Kexample.com.+005+nnnnn.key (public) and + Kexample.com.+005+nnnnn.private (private). The + nnnnn part of the file name is a five digit key ID. + Keep track of which key ID belongs to which key. This is especially + important when having more than one key in a zone. It is also + possible to rename the keys. For each KSK file do: + &prompt.user; mv Kexample.com+005+nnnnn.key Kexample.com+005+nnnnn.KSK.key + &prompt.user; mv Kexample.com+005+nnnnn.private Kexample.com+005+nnnnn.KSK.private + For the ZSK files, substitute + KSK for ZSK as necessary. The + files can now be included in the zone file, using the + $include statement. It should look something like + this: + + $include Kexample.com.+005+nnnnn.KSK.key ; ZSK +$include Kexample.com.+005+nnnnn.ZSK.key ; KSK + + Finally, sign the zone and tell BIND to use + the signed zone file. To sign a zone + dnssec-signzone is used. The command to + sign the zone example.com, located in + example.com.db would look similar to + &prompt.user; dnssec-signzone -o example.com -k Kexample.com+005+nnnnn.KSK example.com.db Kexample.com+005+nnnnn.ZSK.key + The key supplied to + the argument is the KSK and + the other key file is the ZSK that should be used + in the signing. It is possible to supply more than one + KSK and ZSK, which will result + in the zone being signed with all supplied keys. This can be needed + to supply zone data signed using more than one algorithm. The output + of dnssec-signzone is a zone file with all + RRs signed. This output will end up in a file with + the extension .signed, such as + example.com.db.signed. The + DS records will also be + written to a separate file dsset-example.com. + To use this signed zone just modify the zone directive in + named.conf to use + example.com.db.signed. By default, the + signatures are only valid 30 days, meaning that the zone needs to + be resigned in about 15 days to be sure that resolvers are not + caching records with stale signatures. It is possible to make a + script and a cron job to do this. See relevant manuals for details. + + + Be sure to keep private keys confidential, as with all + cryptographic keys. When changing a key it is best to include the + new key into the zone, while still signing with + the old one, and then move over to using the new key to sign. After + these steps are done the old key can be removed from the zone. + Failure to do this might render the DNS data + unavailable for a time, until the new key has propagated through the + DNS hierarchy. For more information on key + rollovers and other DNSSEC operational issues, see + + RFC 4641: DNSSEC Operational + practices. + + + + Automation using <acronym>BIND</acronym> 9.7 or later + Beginning with BIND version 9.7 a new feature + called Smart Signing was introduced. This + feature aims to make the key management and signing process simpler by + automating parts of the task. By putting the keys into a directory + called a key repository, and using the new option + auto-dnssec, it is possible to create a dynamic zone + which will be resigned as needed. To update this zone use + nsupdate with the new option + . rndc has + also grown the ability to sign zones with keys in the key repository, + using the option . To tell + BIND to use this automatic signing and zone + updating for example.com, add the + following to named.conf: + + zone example.com { + type master; + key-directory "/etc/named/keys"; + update-policy local; + auto-dnssec maintain; + file "/etc/named/dynamic/example.com.zone"; +}; + + After making these changes, generate keys for the zone as + explained in , put those keys + in the key repository given as the argument to the + key-directory in the zone configuration and the + zone will be signed automatically. Updates to a zone configured + this way must be done using + nsupdate, which will take care of + re-signing the zone with the new data added. For further details, + see and the BIND + documentation. + + + + + Security Although BIND is the most common implementation of DNS, @@ -3897,11 +4216,12 @@ - + Further Reading BIND/named manual pages: - &man.rndc.8; &man.named.8; &man.named.conf.5; + &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8; + &man.dnssec-signzone.8; &man.dnssec-keygen.8; @@ -3922,6 +4242,17 @@ + Root + DNSSEC + + + + + DNSSEC Trust Anchor Publication for the Root + Zone + + + RFC1034 - Domain Names - Concepts and Facilities @@ -3932,6 +4263,38 @@ url="http://tools.ietf.org/html/rfc1035">RFC1035 - Domain Names - Implementation and Specification + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Resource Records for the DNS Security Extensions + + + + RFC4035 + - Protocol Modifications for the DNS Security Extensions + + + + RFC4641 + - DNSSEC Operational Practices + + + + RFC 5011 + - Automated Updates of DNS Security (DNSSEC + Trust Anchors + + Index: share/sgml/man-refs.ent =================================================================== RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v retrieving revision 1.511 diff -u -d -r1.511 man-refs.ent --- share/sgml/man-refs.ent 11 Feb 2011 16:15:44 -0000 1.511 +++ share/sgml/man-refs.ent 23 May 2011 12:10:56 -0000 @@ -4257,6 +4257,8 @@ + + --------------090906090406000801020902-- From owner-freebsd-doc@FreeBSD.ORG Mon May 23 14:00:25 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3FFB106566C for ; Mon, 23 May 2011 14:00:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CAD488FC15 for ; Mon, 23 May 2011 14:00:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NE0PBb012981 for ; Mon, 23 May 2011 14:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NE0PGZ012980; Mon, 23 May 2011 14:00:25 GMT (envelope-from gnats) Date: Mon, 23 May 2011 14:00:25 GMT Message-Id: <201105231400.p4NE0PGZ012980@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: docs/155264: [handbook] Extend "7.2.2.1 Common Problems" with hw.snd.default_unit=n X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 14:00:26 -0000 The following reply was made to PR docs/155264; it has been noted by GNATS. From: Niclas Zeising To: bug-followup@FreeBSD.org, martin.ziegler@ziegi.ch Cc: Subject: Re: docs/155264: [handbook] Extend "7.2.2.1 Common Problems" with hw.snd.default_unit=n Date: Mon, 23 May 2011 15:58:18 +0200 This is a multi-part message in MIME format. --------------010301040701020801080000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi! Here is a patch to add a section about this to 7.2.2.1. Regards! -- Niclas --------------010301040701020801080000 Content-Type: text/plain; name="multimedia.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="multimedia.chapter.sgml.diff" Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml,v retrieving revision 1.141 diff -u -d -r1.141 chapter.sgml --- chapter.sgml 3 Mar 2011 16:21:59 -0000 1.141 +++ chapter.sgml 23 May 2011 13:29:32 -0000 @@ -353,6 +353,38 @@ + Another issue is that modern graphics cards often comes with their + own sound driver, for use with HDMI and similar. This + sound device will sometimes be enumerated before the actual soundcard + and the soundcard will subsequently not be used as the default playback + device. To check if this is the case, run + dmesg and look for pcm. + The output looks something like this: + ... +hdac0: HDA Driver Revision: 20100226_0142 +hdac1: HDA Driver Revision: 20100226_0142 +hdac0: HDA Codec #0: NVidia (Unknown) +hdac0: HDA Codec #1: NVidia (Unknown) +hdac0: HDA Codec #2: NVidia (Unknown) +hdac0: HDA Codec #3: NVidia (Unknown) +pcm0: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 0 nid 1 on hdac0 +pcm1: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 1 nid 1 on hdac0 +pcm2: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 2 nid 1 on hdac0 +pcm3: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 3 nid 1 on hdac0 +hdac1: HDA Codec #2: Realtek ALC889 +pcm4: <HDA Realtek ALC889 PCM #0 Analog> at cad 2 nid 1 on hdac1 +pcm5: <HDA Realtek ALC889 PCM #1 Analog> at cad 2 nid 1 on hdac1 +pcm6: <HDA Realtek ALC889 PCM #2 Digital> at cad 2 nid 1 on hdac1 +pcm7: <HDA Realtek ALC889 PCM #3 Digital> at cad 2 nid 1 on hdac1 +... + Here the graphics card (NVidia) has been + enumerated before the sound card (Realtek ALC889). + To use the sound card as default playback device, change + hw.snd.default_unit to the unit that should be used + for playback, using + &prompt.root; sysctl hw.snd.default_unit=n + where n is the number of the sound device to use, in + this example 4. --------------010301040701020801080000-- From owner-freebsd-doc@FreeBSD.ORG Mon May 23 15:06:23 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF4A2106566C; Mon, 23 May 2011 15:06:23 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 97D5A8FC0C; Mon, 23 May 2011 15:06:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NF6NZk076091; Mon, 23 May 2011 15:06:23 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NF6Mbq076087; Mon, 23 May 2011 15:06:22 GMT (envelope-from bcr) Date: Mon, 23 May 2011 15:06:22 GMT Message-Id: <201105231506.p4NF6Mbq076087@freefall.freebsd.org> To: martin.ziegler@ziegi.ch, bcr@FreeBSD.org, freebsd-doc@FreeBSD.org, bcr@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/155264: [handbook] Extend "7.2.2.1 Common Problems" with hw.snd.default_unit=n X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 15:06:23 -0000 Synopsis: [handbook] Extend "7.2.2.1 Common Problems" with hw.snd.default_unit=n State-Changed-From-To: open->feedback State-Changed-By: bcr State-Changed-When: Mon May 23 15:03:37 UTC 2011 State-Changed-Why: Take this one and wait for feedback from submitter whether the submitted patch from Niclas (thanks for that!) fits his intention. Responsible-Changed-From-To: freebsd-doc->bcr Responsible-Changed-By: bcr Responsible-Changed-When: Mon May 23 15:03:37 UTC 2011 Responsible-Changed-Why: Take this one and wait for feedback from submitter whether the submitted patch from Niclas (thanks for that!) fits his intention. http://www.freebsd.org/cgi/query-pr.cgi?pr=155264 From owner-freebsd-doc@FreeBSD.ORG Tue May 24 09:27:55 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2FC7106566C; Tue, 24 May 2011 09:27:55 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9D1168FC1F; Tue, 24 May 2011 09:27:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4O9Rtf5014921; Tue, 24 May 2011 09:27:55 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4O9RtV2014917; Tue, 24 May 2011 09:27:55 GMT (envelope-from bcr) Date: Tue, 24 May 2011 09:27:55 GMT Message-Id: <201105240927.p4O9RtV2014917@freefall.freebsd.org> To: bcr@FreeBSD.org, freebsd-doc@FreeBSD.org, bcr@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 09:27:55 -0000 Synopsis: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Responsible-Changed-From-To: freebsd-doc->bcr Responsible-Changed-By: bcr Responsible-Changed-When: Tue May 24 09:27:27 UTC 2011 Responsible-Changed-Why: Grab this PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=157245 From owner-freebsd-doc@FreeBSD.ORG Tue May 24 09:50:10 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2FCE106566B for ; Tue, 24 May 2011 09:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA3B78FC12 for ; Tue, 24 May 2011 09:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4O9oALZ034293 for ; Tue, 24 May 2011 09:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4O9oARM034292; Tue, 24 May 2011 09:50:10 GMT (envelope-from gnats) Date: Tue, 24 May 2011 09:50:10 GMT Message-Id: <201105240950.p4O9oARM034292@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: docs/145644: Add artical about creating manpage from scratch X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 09:50:11 -0000 The following reply was made to PR docs/145644; it has been noted by GNATS. From: Niclas Zeising To: bug-followup@FreeBSD.org, fbsd1@a1poweruser.com Cc: Subject: Re: docs/145644: Add artical about creating manpage from scratch Date: Tue, 24 May 2011 11:44:04 +0200 Hi! I'll work on converting this to SGML. Regards! -- Niclas From owner-freebsd-doc@FreeBSD.ORG Tue May 24 20:08:18 2011 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 320C5106566C; Tue, 24 May 2011 20:08:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B3ED614EDA0; Tue, 24 May 2011 20:08:16 +0000 (UTC) Message-ID: <4DDC102D.4090307@FreeBSD.org> Date: Tue, 24 May 2011 13:08:13 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Niclas Zeising References: <201105231250.p4NCoEId050383@freefall.freebsd.org> In-Reply-To: <201105231250.p4NCoEId050383@freefall.freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-doc@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:08:18 -0000 Excellent work! :) 2 small nits remain, otherwise this looks good to go. On 05/23/2011 05:50, Niclas Zeising wrote: > + found in The href should be http://tools.ietf.org/html/rfc4641 as they are in 29.6.10. The tools site has a much better overall viewing experience, and more importantly gives clear indications if an RFC has been obsoleted. > + $include Kexample.com.+005+nnnnn.KSK.key ; ZSK > +$include Kexample.com.+005+nnnnn.ZSK.key ; KSK The labels after the ;comment are reversed. The first should be KSK. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-doc@FreeBSD.ORG Wed May 25 08:33:28 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13BF106564A; Wed, 25 May 2011 08:33:28 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BAC478FC0C; Wed, 25 May 2011 08:33:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4P8XSsp022977; Wed, 25 May 2011 08:33:28 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4P8XS2H022973; Wed, 25 May 2011 08:33:28 GMT (envelope-from bcr) Date: Wed, 25 May 2011 08:33:28 GMT Message-Id: <201105250833.p4P8XS2H022973@freefall.freebsd.org> To: bcr@FreeBSD.org, freebsd-doc@FreeBSD.org, bcr@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/138887: manpage ports(7) incorrect X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:33:29 -0000 Synopsis: manpage ports(7) incorrect Responsible-Changed-From-To: freebsd-doc->bcr Responsible-Changed-By: bcr Responsible-Changed-When: Wed May 25 08:33:02 UTC 2011 Responsible-Changed-Why: I will fix this. http://www.freebsd.org/cgi/query-pr.cgi?pr=138887 From owner-freebsd-doc@FreeBSD.ORG Wed May 25 09:10:14 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057D71065670 for ; Wed, 25 May 2011 09:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA7658FC14 for ; Wed, 25 May 2011 09:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4P9ADQa049854 for ; Wed, 25 May 2011 09:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4P9ADa1049853; Wed, 25 May 2011 09:10:13 GMT (envelope-from gnats) Date: Wed, 25 May 2011 09:10:13 GMT Message-Id: <201105250910.p4P9ADa1049853@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Benedict Reuschling Cc: Subject: Re: docs/144408: [patch] update makefs(8) (remove device option) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benedict Reuschling List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:10:14 -0000 The following reply was made to PR docs/144408; it has been noted by GNATS. From: Benedict Reuschling To: bug-followup@FreeBSD.org, gcooper@FreeBSD.org Cc: Subject: Re: docs/144408: [patch] update makefs(8) (remove device option) Date: Wed, 25 May 2011 10:57:07 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I checked with NetBSD whether they have to fix that issue in their tree as well. Apparently, their mtree has the 'device' definition: http://netbsd.gw.com/cgi-bin/man-cgi?mtree++NetBSD-current Question is: does it make sense to add it to our mtree as well? Benedict Reuschling -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3cxGMACgkQTSZQLkqBk0gSlACeIHoWrF8GgWa58K9JWe23RlbR /pwAoJ+NyetacCf0yfywVC5YiASPikBc =+bSs -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Wed May 25 12:50:09 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7DC0106566C for ; Wed, 25 May 2011 12:50:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 841168FC12 for ; Wed, 25 May 2011 12:50:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4PCo9GP054562 for ; Wed, 25 May 2011 12:50:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PCo9GN054561; Wed, 25 May 2011 12:50:09 GMT (envelope-from gnats) Resent-Date: Wed, 25 May 2011 12:50:09 GMT Resent-Message-Id: <201105251250.p4PCo9GN054561@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Roman Bogorodskiy Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAD1C106566C for ; Wed, 25 May 2011 12:41:41 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BA4A08FC08 for ; Wed, 25 May 2011 12:41:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4PCfft9053779 for ; Wed, 25 May 2011 12:41:41 GMT (envelope-from novel@freefall.freebsd.org) Received: (from novel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PCffiO053778; Wed, 25 May 2011 12:41:41 GMT (envelope-from novel) Message-Id: <201105251241.p4PCffiO053778@freefall.freebsd.org> Date: Wed, 25 May 2011 12:41:41 GMT From: Roman Bogorodskiy To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/157316: [patch] update devstat(9) man page X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Roman Bogorodskiy List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:50:09 -0000 >Number: 157316 >Category: docs >Synopsis: [patch] update devstat(9) man page >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed May 25 12:50:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Roman Bogorodskiy >Release: FreeBSD 8.2-STABLE i386 >Organization: >Environment: System: FreeBSD freefall.freebsd.org 8.2-STABLE FreeBSD 8.2-STABLE #4 r220774: Mon Apr 18 13:56:14 UTC 2011 simon@freefall.freebsd.org:/usr/obj/usr/src/sys/FREEFALL i386 >Description: devstat(9) manual page is out of date: it mentions devstat_add_entry() which was deprecated long around (in 5.x times IIRC) and now it's not even defined in sys/devicestat.h. I made some changes to devstat(9) manual page: * replaced devstat_add_entry with devstat_new_entry * fixed other function prototypes * added documentation for devstat_start_transaction_bio() * synced MLINKS with currently available functions * Removed some fields from 'struct devstat' description Note: 'struct devstat' description in manual page now misses a number of fields defined in the original struct. I don't have enough devstat(9) subsystem knowledge to provide a meaningful description for those fields. >How-To-Repeat: >Fix: --- devstat_9.diff begins here --- Index: Makefile =================================================================== RCS file: /home/ncvs/src/share/man/man9/Makefile,v retrieving revision 1.390 diff -u -r1.390 Makefile --- Makefile 5 May 2011 14:13:08 -0000 1.390 +++ Makefile 25 May 2011 11:14:36 -0000 @@ -592,10 +592,12 @@ device_set_desc.9 device_set_desc_copy.9 MLINKS+=device_set_flags.9 device_get_flags.9 MLINKS+=devstat.9 devicestat.9 \ - devstat.9 devstat_add_entry.9 \ + devstat.9 devstat_new_entry.9 \ devstat.9 devstat_end_transaction.9 \ + devstat.9 devstat_end_transaction_bio.9 \ devstat.9 devstat_remove_entry.9 \ - devstat.9 devstat_start_transaction.9 + devstat.9 devstat_start_transaction.9 \ + devstat.9 devstat_start_transaction_bio.9 MLINKS+=disk.9 disk_alloc.9 \ disk.9 disk_create.9 \ disk.9 disk_destroy.9 \ Index: devstat.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/devstat.9,v retrieving revision 1.23 diff -u -r1.23 devstat.9 --- devstat.9 28 Aug 2010 16:32:01 -0000 1.23 +++ devstat.9 25 May 2011 11:14:36 -0000 @@ -40,10 +40,9 @@ .Nd kernel interface for keeping device statistics .Sh SYNOPSIS .In sys/devicestat.h -.Ft void -.Fo devstat_add_entry -.Fa "struct devstat *ds" -.Fa "const char *dev_name" +.Ft struct devstat * +.Fo devstat_new_entry +.Fa "const void *dev_name" .Fa "int unit_number" .Fa "u_int32_t block_size" .Fa "devstat_support_flags flags" @@ -53,13 +52,23 @@ .Ft void .Fn devstat_remove_entry "struct devstat *ds" .Ft void -.Fn devstat_start_transaction "struct devstat *ds" +.Fo devstat_start_transaction +.Fa "struct devstat *ds" +.Fa "struct bintime *now" +.Fc +.Ft void +.Fo devstat_start_transaction_bio +.Fa "struct devstat *ds" +.Fa "struct bio *bp" +.Fc .Ft void .Fo devstat_end_transaction .Fa "struct devstat *ds" .Fa "u_int32_t bytes" .Fa "devstat_tag_type tag_type" .Fa "devstat_trans_flags flags" +.Fa "struct bintime *now" +.Fa "struct bintime *then" .Fc .Ft void .Fo devstat_end_transaction_bio @@ -77,19 +86,13 @@ code. Instead, that is left for user programs to handle. .Pp -.Fn devstat_add_entry -registers a device with the -.Nm -subsystem. -The caller is expected to have already allocated \fBand zeroed\fR -the devstat structure before calling this function. -.Fn devstat_add_entry +.Fn devstat_new_entry +allocates and initializes +.Va devstat +structure and returns a pointer to it. +.Fn devstat_new_entry takes several arguments: .Bl -tag -width device_type -.It ds -The -.Va devstat -structure, allocated and zeroed by the client. .It dev_name The device name, e.g.\& da, cd, sa. .It unit_number @@ -147,7 +150,7 @@ registers the end of a transaction with the .Nm subsystem. -It takes four arguments: +It takes six arguments: .Bl -tag -width tag_type .It ds The @@ -161,12 +164,20 @@ .It flags Transaction flags indicating whether the transaction was a read, write, or whether no data was transferred. +.It now +Time when transaction started. +.It then +Time when transation ended. .El .Pp +.Fn devstat_start_transaction_bio +and .Fn devstat_end_transaction_bio -is a wrapper for +are wrappers for +.Fn devstart_start_transaction +and .Fn devstat_end_transaction -which pulls all the information from a +respectively, which pull all the information from a .Va "struct bio" which is ready for biodone(). .Pp @@ -207,62 +218,20 @@ This will hopefully eliminate the counter wrap that would come very quickly on some systems if 32 bit integers were used. -.It bytes_read -This is the number of bytes that have been read from the device. -.It bytes_freed -This is the number of bytes that have been freed/erased on the device. -.It num_reads -This is the number of reads from the device. -.It num_writes -This is the number of writes to the device. -.It num_frees -This is the number of free/erase operations on the device. -.It num_other -This is the number of transactions to the device which are neither reads or -writes. -For instance, -.Tn SCSI -drivers often send a test unit ready command to -.Tn SCSI -devices. -The test unit ready command does not read or write any data. -It merely causes the device to return its status. -.It busy_count -This is the current number of outstanding transactions for the device. -This should never go below zero, and on an idle device it should be zero. -If either one of these conditions is not true, it indicates a problem in -the way -.Fn devstat_start_transaction -and -.Fn devstat_end_transaction -are being called in client code. -There should be one and only one -transaction start event and one transaction end event for each transaction. .It block_size This is the block size of the device, if the device has a block size. .It tag_types This is an array of counters to record the number of various tag types that are sent to a device. See below for a list of tag types. -.It dev_creation_time +.It creation_time This is the time, as reported by .Fn getmicrotime -that the device was registered. +that the device was created. .It busy_time This is the amount of time that the device busy count has been greater than zero. This is only updated when the busy count returns to zero. -.It start_time -This is the time, as reported by -.Fn getmicrouptime -that the device busy count went from zero to one. -.It last_comp_time -This is the time as reported by -.Fn getmicrouptime -that a transaction last completed. -It is used along with -.Va start_time -to calculate the device busy time. .It flags These flags indicate which statistics measurements are supported by a particular device. @@ -284,6 +253,8 @@ The second parameter is attach order. See below for a list of available priorities. +.It id +Identification for GEOM nodes. .El .Pp Each device is given a device type. --- devstat_9.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Wed May 25 13:10:08 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29B42106566B for ; Wed, 25 May 2011 13:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1341D8FC0A for ; Wed, 25 May 2011 13:10:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4PDA7lS071486 for ; Wed, 25 May 2011 13:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PDA78M071485; Wed, 25 May 2011 13:10:07 GMT (envelope-from gnats) Date: Wed, 25 May 2011 13:10:07 GMT Message-Id: <201105251310.p4PDA78M071485@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Sergey Kandaurov Cc: Subject: Re: docs/157316: [patch] update devstat(9) man page X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Kandaurov List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:10:08 -0000 The following reply was made to PR docs/157316; it has been noted by GNATS. From: Sergey Kandaurov To: bug-followup@FreeBSD.org, novel@freebsd.org Cc: Subject: Re: docs/157316: [patch] update devstat(9) man page Date: Wed, 25 May 2011 17:04:15 +0400 --0016e64988f67bdb7a04a419575f Content-Type: text/plain; charset=ISO-8859-1 Hi, it so happened that I have pending changes to devstat(9) too :) waiting for someone's review (attached). Let it be there as well. -- wbr, pluknet --0016e64988f67bdb7a04a419575f Content-Type: text/x-patch; charset=US-ASCII; name="devstat.9.diff" Content-Disposition: attachment; filename="devstat.9.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_go4a7svh0 SW5kZXg6IGRldnN0YXQuOQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBkZXZzdGF0LjkJKHJldmlzaW9uIDIyMjAz MikKKysrIGRldnN0YXQuOQkod29ya2luZyBjb3B5KQpAQCAtMjcsMjMgKzI3LDIzIEBACiAuXCIK IC5cIiAkRnJlZUJTRCQKIC5cIgotLkRkIE1heSAyMiwgMTk5OAorLkRkIE1heSAyMiwgMjAxMQog LkR0IERFVlNUQVQgOQogLk9zCiAuU2ggTkFNRQogLk5tIGRldnN0YXQgLAotLk5tIGRldnN0YXRf YWRkX2VudHJ5ICwKIC5ObSBkZXZzdGF0X2VuZF90cmFuc2FjdGlvbiAsCiAuTm0gZGV2c3RhdF9l bmRfdHJhbnNhY3Rpb25fYmlvICwKKy5ObSBkZXZzdGF0X25ld19lbnRyeSAsCiAuTm0gZGV2c3Rh dF9yZW1vdmVfZW50cnkgLAotLk5tIGRldnN0YXRfc3RhcnRfdHJhbnNhY3Rpb24KKy5ObSBkZXZz dGF0X3N0YXJ0X3RyYW5zYWN0aW9uICwKKy5ObSBkZXZzdGF0X3N0YXJ0X3RyYW5zYWN0aW9uX2Jp bwogLk5kIGtlcm5lbCBpbnRlcmZhY2UgZm9yIGtlZXBpbmcgZGV2aWNlIHN0YXRpc3RpY3MKIC5T aCBTWU5PUFNJUwogLkluIHN5cy9kZXZpY2VzdGF0LmgKLS5GdCB2b2lkCi0uRm8gZGV2c3RhdF9h ZGRfZW50cnkKLS5GYSAic3RydWN0IGRldnN0YXQgKmRzIgotLkZhICJjb25zdCBjaGFyICpkZXZf bmFtZSIKKy5GdCAic3RydWN0IGRldnN0YXQgKiIKKy5GbyBkZXZzdGF0X25ld19lbnRyeQorLkZh ICJjb25zdCB2b2lkICpkZXZfbmFtZSIKIC5GYSAiaW50IHVuaXRfbnVtYmVyIgogLkZhICJ1X2lu dDMyX3QgYmxvY2tfc2l6ZSIKIC5GYSAiZGV2c3RhdF9zdXBwb3J0X2ZsYWdzIGZsYWdzIgpAQCAt NTMsMTMgKzUzLDE3IEBACiAuRnQgdm9pZAogLkZuIGRldnN0YXRfcmVtb3ZlX2VudHJ5ICJzdHJ1 Y3QgZGV2c3RhdCAqZHMiCiAuRnQgdm9pZAotLkZuIGRldnN0YXRfc3RhcnRfdHJhbnNhY3Rpb24g InN0cnVjdCBkZXZzdGF0ICpkcyIKKy5GbiBkZXZzdGF0X3N0YXJ0X3RyYW5zYWN0aW9uICJzdHJ1 Y3QgZGV2c3RhdCAqZHMiICJzdHJ1Y3QgYmludGltZSAqbm93IgogLkZ0IHZvaWQKKy5GbiBkZXZz dGF0X3N0YXJ0X3RyYW5zYWN0aW9uX2JpbyAic3RydWN0IGRldnN0YXQgKmRzIiAic3RydWN0IGJp byAqYnAiCisuRnQgdm9pZAogLkZvIGRldnN0YXRfZW5kX3RyYW5zYWN0aW9uCiAuRmEgInN0cnVj dCBkZXZzdGF0ICpkcyIKIC5GYSAidV9pbnQzMl90IGJ5dGVzIgogLkZhICJkZXZzdGF0X3RhZ190 eXBlIHRhZ190eXBlIgogLkZhICJkZXZzdGF0X3RyYW5zX2ZsYWdzIGZsYWdzIgorLkZhICJzdHJ1 Y3QgYmludGltZSAqbm93IgorLkZhICJzdHJ1Y3QgYmludGltZSAqdGhlbiIKIC5GYwogLkZ0IHZv aWQKIC5GbyBkZXZzdGF0X2VuZF90cmFuc2FjdGlvbl9iaW8KQEAgLTc3LDE5ICs4MSwxNCBAQAog Y29kZS4KIEluc3RlYWQsIHRoYXQgaXMgbGVmdCBmb3IgdXNlciBwcm9ncmFtcyB0byBoYW5kbGUu CiAuUHAKLS5GbiBkZXZzdGF0X2FkZF9lbnRyeQorLkZuIGRldnN0YXRfbmV3X2VudHJ5CiByZWdp c3RlcnMgYSBkZXZpY2Ugd2l0aCB0aGUKIC5ObQotc3Vic3lzdGVtLgotVGhlIGNhbGxlciBpcyBl eHBlY3RlZCB0byBoYXZlIGFscmVhZHkgYWxsb2NhdGVkIFxmQmFuZCB6ZXJvZWRcZlIKLXRoZSBk ZXZzdGF0IHN0cnVjdHVyZSBiZWZvcmUgY2FsbGluZyB0aGlzIGZ1bmN0aW9uLgotLkZuIGRldnN0 YXRfYWRkX2VudHJ5Ci10YWtlcyBzZXZlcmFsIGFyZ3VtZW50czoKK3N1YnN5c3RlbSBhbmQgcmV0 dXJucyBhIHBvaW50ZXIgdG8gdGhlIGFsbG9jYXRlZCBhbmQgaW5pdGlhbGl6ZWQKKy5WYSBkZXZz dGF0CitzdHJ1Y3R1cmUuCitJdCB0YWtlcyBzZXZlcmFsIGFyZ3VtZW50czoKIC5CbCAtdGFnIC13 aWR0aCBkZXZpY2VfdHlwZQotLkl0IGRzCi1UaGUKLS5WYSBkZXZzdGF0Ci1zdHJ1Y3R1cmUsIGFs bG9jYXRlZCBhbmQgemVyb2VkIGJ5IHRoZSBjbGllbnQuCiAuSXQgZGV2X25hbWUKIFRoZSBkZXZp Y2UgbmFtZSwgZS5nLlwmIGRhLCBjZCwgc2EuCiAuSXQgdW5pdF9udW1iZXIKQEAgLTEyNyw3ICsx MjYsNyBAQAogLk5tCiBzdWJzeXN0ZW0uCiBJdCB0YWtlcyB0aGUgZGV2c3RhdCBzdHJ1Y3R1cmUg Zm9yIHRoZSBkZXZpY2UgaW4gcXVlc3Rpb24gYXMKLWFuIGFyZ3VtZW50LgorYW4gYXJndW1lbnQg YW5kIGZyZWVzIHVzZWQgbWVtb3J5IGJhY2sgdG8gdGhlIHN5c3RlbS4KIFRoZQogLk5tCiBnZW5l cmF0aW9uIG51bWJlciBpcyBpbmNyZW1lbnRlZCBhbmQgdGhlIG51bWJlciBvZiBkZXZpY2VzIGlz IGRlY3JlbWVudGVkLgpAQCAtMTM2LDE4ICsxMzUsMjMgQEAKIHJlZ2lzdGVycyB0aGUgc3RhcnQg b2YgYSB0cmFuc2FjdGlvbiB3aXRoIHRoZQogLk5tCiBzdWJzeXN0ZW0uCi1UaGUgYnVzeSBjb3Vu dCBpcyBpbmNyZW1lbnRlZCB3aXRoIGVhY2ggdHJhbnNhY3Rpb24gc3RhcnQuCitUaGUgc3RhcnQg Y291bnQgaXMgaW5jcmVtZW50ZWQgd2l0aCBlYWNoIHRyYW5zYWN0aW9uIHN0YXJ0LgogV2hlbiBh IGRldmljZSBnb2VzIGZyb20gaWRsZSB0byBidXN5LCB0aGUgc3lzdGVtIHVwdGltZSBpcyByZWNv cmRlZCBpbiB0aGUKLS5WYSBzdGFydF90aW1lCisuVmEgYnVzeV9mcm9tCiBmaWVsZCBvZiB0aGUK IC5WYSBkZXZzdGF0CiBzdHJ1Y3R1cmUuCitUaGUgY2FsbGVyIGNhbiBvdmVycmlkZSB0aGUgdGlt ZSB2YWx1ZSBieSBzcGVjaWZ5aW5nIGEgbm9uLU5VTEwKK3RpbWVzdGFtcCBhcmd1bWVudAorLlZh IG5vdwordG8gdGhlIGZ1bmN0aW9uLgogLlBwCiAuRm4gZGV2c3RhdF9lbmRfdHJhbnNhY3Rpb24K IHJlZ2lzdGVycyB0aGUgZW5kIG9mIGEgdHJhbnNhY3Rpb24gd2l0aCB0aGUKIC5ObQogc3Vic3lz dGVtLgotSXQgdGFrZXMgZm91ciBhcmd1bWVudHM6CitUaGUgZW5kIGNvdW50IGlzIGluY3JlbWVu dGVkIHdpdGggZWFjaCB0cmFuc2FjdGlvbiBlbmQuCitJdCB0YWtlcyBzZXZlcmFsIGFyZ3VtZW50 czoKIC5CbCAtdGFnIC13aWR0aCB0YWdfdHlwZQogLkl0IGRzCiBUaGUKQEAgLTE2MSwxMiArMTY1 LDIxIEBACiAuSXQgZmxhZ3MKIFRyYW5zYWN0aW9uIGZsYWdzIGluZGljYXRpbmcgd2hldGhlciB0 aGUgdHJhbnNhY3Rpb24gd2FzIGEgcmVhZCwgd3JpdGUsIG9yCiB3aGV0aGVyIG5vIGRhdGEgd2Fz IHRyYW5zZmVycmVkLgorLkl0IG5vdworVGhlIGN1cnJlbnQgdGltZXN0YW1wLgorLkl0IHRoZW4K K1RoZSB0aW1lc3RhbXAgb2Ygd2hlbiB0aGlzIHRyYW5zYWN0aW9uIHN0YXJ0ZWQuCiAuRWwKIC5Q cAorLkZuIGRldnN0YXRfc3RhcnRfdHJhbnNhY3Rpb25fYmlvCithbmQKIC5GbiBkZXZzdGF0X2Vu ZF90cmFuc2FjdGlvbl9iaW8KLWlzIGEgd3JhcHBlciBmb3IKK2FyZSB3cmFwcGVycyBmb3IKKy5G biBkZXZzdGF0X3N0YXJ0X3RyYW5zYWN0aW9uCithbmQKIC5GbiBkZXZzdGF0X2VuZF90cmFuc2Fj dGlvbgotd2hpY2ggcHVsbHMgYWxsIHRoZSBpbmZvcm1hdGlvbiBmcm9tIGEKK3Jlc3BlY3RpdmVs eQord2hpY2ggcHVsbCBhbGwgdGhlIGluZm9ybWF0aW9uIGZyb20gYQogLlZhICJzdHJ1Y3QgYmlv Igogd2hpY2ggaXMgcmVhZHkgZm9yIGJpb2RvbmUoKS4KIC5QcApAQCAtMjAxLDY4ICsyMTQsNDUg QEAKIC5JdCB1bml0X251bWJlcgogVGhlIHVuaXQgbnVtYmVyIGlkZW50aWZpZXMgdGhlIHBhcnRp Y3VsYXIgaW5zdGFuY2Ugb2YgdGhlIHBlcmlwaGVyYWwgZHJpdmVyCiBpbiBxdWVzdGlvbi4KLS5J dCBieXRlc193cml0dGVuCi1UaGlzIGlzIHRoZSBudW1iZXIgb2YgYnl0ZXMgdGhhdCBoYXZlIGJl ZW4gd3JpdHRlbiB0byB0aGUgZGV2aWNlLgorLkl0IGJ5dGVzW2ZsYWdzXQorVGhpcyBpcyB0aGUg bnVtYmVyIG9mIGJ5dGVzIHRoYXQgaGF2ZSBiZWVuIHdyaXR0ZW4sIHJlYWQgb3IgZnJlZWQvZXJh c2VkIG9uCit0aGUgZGV2aWNlIGFjY29yZGluZyB0byBhIHRyYW5zYWN0aW9uIHR5cGUgc3BlY2lm aWVkIGluIGZsYWdzIGluZGV4LgorU2VlIGJlbG93IGZvciB0cmFuc2FjdGlvbiB0eXBlcy4KIFRo aXMgbnVtYmVyIGlzIGN1cnJlbnRseSBhbiB1bnNpZ25lZCA2NCBiaXQgaW50ZWdlci4KIFRoaXMg d2lsbCBob3BlZnVsbHkKIGVsaW1pbmF0ZSB0aGUgY291bnRlciB3cmFwIHRoYXQgd291bGQgY29t ZSB2ZXJ5IHF1aWNrbHkgb24gc29tZSBzeXN0ZW1zIGlmCiAzMiBiaXQgaW50ZWdlcnMgd2VyZSB1 c2VkLgotLkl0IGJ5dGVzX3JlYWQKLVRoaXMgaXMgdGhlIG51bWJlciBvZiBieXRlcyB0aGF0IGhh dmUgYmVlbiByZWFkIGZyb20gdGhlIGRldmljZS4KLS5JdCBieXRlc19mcmVlZAotVGhpcyBpcyB0 aGUgbnVtYmVyIG9mIGJ5dGVzIHRoYXQgaGF2ZSBiZWVuIGZyZWVkL2VyYXNlZCBvbiB0aGUgZGV2 aWNlLgotLkl0IG51bV9yZWFkcwotVGhpcyBpcyB0aGUgbnVtYmVyIG9mIHJlYWRzIGZyb20gdGhl IGRldmljZS4KLS5JdCBudW1fd3JpdGVzCi1UaGlzIGlzIHRoZSBudW1iZXIgb2Ygd3JpdGVzIHRv IHRoZSBkZXZpY2UuCi0uSXQgbnVtX2ZyZWVzCi1UaGlzIGlzIHRoZSBudW1iZXIgb2YgZnJlZS9l cmFzZSBvcGVyYXRpb25zIG9uIHRoZSBkZXZpY2UuCi0uSXQgbnVtX290aGVyCi1UaGlzIGlzIHRo ZSBudW1iZXIgb2YgdHJhbnNhY3Rpb25zIHRvIHRoZSBkZXZpY2Ugd2hpY2ggYXJlIG5laXRoZXIg cmVhZHMgb3IKLXdyaXRlcy4KLUZvciBpbnN0YW5jZSwKLS5UbiBTQ1NJCi1kcml2ZXJzIG9mdGVu IHNlbmQgYSB0ZXN0IHVuaXQgcmVhZHkgY29tbWFuZCB0bwotLlRuIFNDU0kKLWRldmljZXMuCi1U aGUgdGVzdCB1bml0IHJlYWR5IGNvbW1hbmQgZG9lcyBub3QgcmVhZCBvciB3cml0ZSBhbnkgZGF0 YS4KLUl0IG1lcmVseSBjYXVzZXMgdGhlIGRldmljZSB0byByZXR1cm4gaXRzIHN0YXR1cy4KLS5J dCBidXN5X2NvdW50Ci1UaGlzIGlzIHRoZSBjdXJyZW50IG51bWJlciBvZiBvdXRzdGFuZGluZyB0 cmFuc2FjdGlvbnMgZm9yIHRoZSBkZXZpY2UuCi1UaGlzIHNob3VsZCBuZXZlciBnbyBiZWxvdyB6 ZXJvLCBhbmQgb24gYW4gaWRsZSBkZXZpY2UgaXQgc2hvdWxkIGJlIHplcm8uCi1JZiBlaXRoZXIg b25lIG9mIHRoZXNlIGNvbmRpdGlvbnMgaXMgbm90IHRydWUsIGl0IGluZGljYXRlcyBhIHByb2Js ZW0gaW4KLXRoZSB3YXkKKy5JdCBvcGVyYXRpb25zW2ZsYWdzXQorVGhpcyBpcyB0aGUgbnVtYmVy IG9mIHJlYWQsIHdyaXRlIG9yIGZyZWUvZXJhc2Ugb3BlcmF0aW9ucyBvbiB0aGUgZGV2aWNlCith Y2NvcmRpbmcgdG8gYSB0cmFuc2FjdGlvbiB0eXBlIHNwZWNpZmllZCBpbiBmbGFncyBpbmRleC4K Ky5JdCBkdXJhdGlvbltbZmxhZ3NdCitUaGUgZHVyYXRpb24gb2YgcmVhZCwgd3JpdGUgb3IgZnJl ZS9lcmFzZSBvcGVyYXRpb25zIG9uIHRoZSBkZXZpY2UKK2FjY29yZGluZyB0byBhIHRyYW5zYWN0 aW9uIHR5cGUgc3BlY2lmaWVkIGluIGZsYWdzIGluZGV4LgorLkl0IHN0YXJ0X2NvdW50ICwgZW5k X2NvdW50CitUaGlzIGFyZSBudW1iZXJzIG9mIHN0YXJ0ZWQgYW5kIGNvbXBsZXRlZCB0cmFuc2Fj dGlvbnMgZm9yIHRoZSBkZXZpY2UsCit3aGljaCBhcmUgdXBkYXRlZCBpbiB0aGUKIC5GbiBkZXZz dGF0X3N0YXJ0X3RyYW5zYWN0aW9uCiBhbmQKIC5GbiBkZXZzdGF0X2VuZF90cmFuc2FjdGlvbgot YXJlIGJlaW5nIGNhbGxlZCBpbiBjbGllbnQgY29kZS4KLVRoZXJlIHNob3VsZCBiZSBvbmUgYW5k IG9ubHkgb25lCi10cmFuc2FjdGlvbiBzdGFydCBldmVudCBhbmQgb25lIHRyYW5zYWN0aW9uIGVu ZCBldmVudCBmb3IgZWFjaCB0cmFuc2FjdGlvbi4KK3BhdGhzIHJlc3BlY3RpdmVseS4KK09uIGFu IGlkbGUgZGV2aWNlIHRoZWlyIHZhbHVlcyBzaG91bGQgYmUgZXF1YWwuCiAuSXQgYmxvY2tfc2l6 ZQogVGhpcyBpcyB0aGUgYmxvY2sgc2l6ZSBvZiB0aGUgZGV2aWNlLCBpZiB0aGUgZGV2aWNlIGhh cyBhIGJsb2NrIHNpemUuCiAuSXQgdGFnX3R5cGVzCiBUaGlzIGlzIGFuIGFycmF5IG9mIGNvdW50 ZXJzIHRvIHJlY29yZCB0aGUgbnVtYmVyIG9mIHZhcmlvdXMgdGFnIHR5cGVzIHRoYXQKIGFyZSBz ZW50IHRvIGEgZGV2aWNlLgogU2VlIGJlbG93IGZvciBhIGxpc3Qgb2YgdGFnIHR5cGVzLgotLkl0 IGRldl9jcmVhdGlvbl90aW1lCisuSXQgY3JlYXRpb25fdGltZQogVGhpcyBpcyB0aGUgdGltZSwg YXMgcmVwb3J0ZWQgYnkKLS5GbiBnZXRtaWNyb3RpbWUKKy5GbiBiaW51cHRpbWUKIHRoYXQgdGhl IGRldmljZSB3YXMgcmVnaXN0ZXJlZC4KIC5JdCBidXN5X3RpbWUKLVRoaXMgaXMgdGhlIGFtb3Vu dCBvZiB0aW1lIHRoYXQgdGhlIGRldmljZSBidXN5IGNvdW50IGhhcyBiZWVuIGdyZWF0ZXIgdGhh bgotemVyby4KLVRoaXMgaXMgb25seSB1cGRhdGVkIHdoZW4gdGhlIGJ1c3kgY291bnQgcmV0dXJu cyB0byB6ZXJvLgotLkl0IHN0YXJ0X3RpbWUKLVRoaXMgaXMgdGhlIHRpbWUsIGFzIHJlcG9ydGVk IGJ5Ci0uRm4gZ2V0bWljcm91cHRpbWUKLXRoYXQgdGhlIGRldmljZSBidXN5IGNvdW50IHdlbnQg ZnJvbSB6ZXJvIHRvIG9uZS4KLS5JdCBsYXN0X2NvbXBfdGltZQotVGhpcyBpcyB0aGUgdGltZSBh cyByZXBvcnRlZCBieQotLkZuIGdldG1pY3JvdXB0aW1lCi10aGF0IGEgdHJhbnNhY3Rpb24gbGFz dCBjb21wbGV0ZWQuCi1JdCBpcyB1c2VkIGFsb25nIHdpdGgKLS5WYSBzdGFydF90aW1lCi10byBj YWxjdWxhdGUgdGhlIGRldmljZSBidXN5IHRpbWUuCitUaGlzIGlzIHRoZSBhbW91bnQgb2YgdGlt ZSB0aGF0IHRoZSBkZXZpY2Ugd2FzIGJ1c3kuCitUaGlzIGlzIG9ubHkgdXBkYXRlZCBkdXJpbmcg dGhlIGVuZGluZyBvZiBhIHRyYW5zYWN0aW9uLgorLkl0IGJ1c3lfZnJvbQorVGhpcyBpcyB0aGUg c3lzdGVtIHRpbWUsIGFzIHJlcG9ydGVkIGJ5CisuWHIgYmludXB0aW1lCit3aGVuIHN0YXJ0aW5n IGEgdHJhbnNhY3Rpb24gb2YgYSBkZXZpY2UgdGhhdCBnb2VzIGZyb20gaWRsZSB0byBidXN5Lgog Lkl0IGZsYWdzCiBUaGVzZSBmbGFncyBpbmRpY2F0ZSB3aGljaCBzdGF0aXN0aWNzIG1lYXN1cmVt ZW50cyBhcmUgc3VwcG9ydGVkIGJ5IGEKIHBhcnRpY3VsYXIgZGV2aWNlLgpAQCAtMzc4LDggKzM2 OCwxOSBAQAogCURFVlNUQVRfV1JJVEUJPSAweDAyLAogCURFVlNUQVRfRlJFRQk9IDB4MDMKIH0g ZGV2c3RhdF90cmFuc19mbGFnczsKKyNkZWZpbmUJREVWU1RBVF9OX1RSQU5TX0ZMQUdTCTQKIC5F ZAogLlBwCitERVZTVEFUX05PX0RBVEEgaXMgYSB0eXBlIG9mIHRyYW5zYWN0aW9ucyB0byB0aGUg ZGV2aWNlIHdoaWNoIGFyZSBuZWl0aGVyCityZWFkcyBvciB3cml0ZXMuCitGb3IgaW5zdGFuY2Us CisuVG4gU0NTSQorZHJpdmVycyBvZnRlbiBzZW5kIGEgdGVzdCB1bml0IHJlYWR5IGNvbW1hbmQg dG8KKy5UbiBTQ1NJCitkZXZpY2VzLgorVGhlIHRlc3QgdW5pdCByZWFkeSBjb21tYW5kIGRvZXMg bm90IHJlYWQgb3Igd3JpdGUgYW55IGRhdGEuCitJdCBtZXJlbHkgY2F1c2VzIHRoZSBkZXZpY2Ug dG8gcmV0dXJuIGl0cyBzdGF0dXMuCisuUHAKIFRoZXJlIGFyZSBmb3VyIHBvc3NpYmxlIHZhbHVl cyBmb3IgdGhlCiAuVmEgdGFnX3R5cGUKIGFyZ3VtZW50IHRvCg== --0016e64988f67bdb7a04a419575f-- From owner-freebsd-doc@FreeBSD.ORG Wed May 25 13:50:09 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 844F2106566C for ; Wed, 25 May 2011 13:50:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 43B9F8FC18 for ; Wed, 25 May 2011 13:50:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4PDo9Yh008682 for ; Wed, 25 May 2011 13:50:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PDo9kG008681; Wed, 25 May 2011 13:50:09 GMT (envelope-from gnats) Resent-Date: Wed, 25 May 2011 13:50:09 GMT Resent-Message-Id: <201105251350.p4PDo9kG008681@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Warren Block Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 929D110656A3 for ; Wed, 25 May 2011 13:47:00 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 830DE8FC0C for ; Wed, 25 May 2011 13:47:00 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p4PDl0FJ095040 for ; Wed, 25 May 2011 13:47:00 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p4PDl03x095039; Wed, 25 May 2011 13:47:00 GMT (envelope-from nobody) Message-Id: <201105251347.p4PDl03x095039@red.freebsd.org> Date: Wed, 25 May 2011 13:47:00 GMT From: Warren Block To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: docs/157317: [patch] wording adjustments to usbdump.8 man page X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:50:09 -0000 >Number: 157317 >Category: docs >Synopsis: [patch] wording adjustments to usbdump.8 man page >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed May 25 13:50:08 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Warren Block >Release: 8-stable >Organization: >Environment: FreeBSD lightning 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat May 21 15:01:13 MDT 2011 root@lightning:/usr/obj/usr/src/sys/LIGHTNING i386 >Description: Small changes to usbdump.8 wording to improve consistency and clarity. >How-To-Repeat: >Fix: Apply patch. Patch attached with submission follows: --- /usr/src/usr.sbin/usbdump/usbdump.8.orig 2011-05-25 07:32:56.000000000 -0600 +++ /usr/src/usr.sbin/usbdump/usbdump.8 2011-05-25 07:43:19.000000000 -0600 @@ -53,21 +53,21 @@ Snapshot bytes from each packet. .It Fl v Enable debugging messages. -When it defined multiple times the verbose level increases. +When given multiple times, the verbosity level increases. .It Fl w Ar file Write the raw packets to file. .El .Sh EXAMPLES -Captures the USB raw packets alive on usbus2: +Capture the USB raw packets alive on usbus2: .Pp .Dl "usbdump -i usbus2 -s 256 -v" .Pp -Dumps the USB raw packets of usbus2 into the file without packet +Dump the USB raw packets of usbus2 into the file without packet size limit: .Pp .Dl "usbdump -i usbus2 -s 0 -w /tmp/dump_pkts" .Pp -Read the USB raw packets from the file: +Read and display the USB raw packets from the file: .Pp .Dl "usbdump -r /tmp/dump_pkts -v" .Sh SEE ALSO >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Wed May 25 17:32:50 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A12106566B; Wed, 25 May 2011 17:32:50 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA2C8FC1A; Wed, 25 May 2011 17:32:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4PHWo4B018279; Wed, 25 May 2011 17:32:50 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PHWoac018275; Wed, 25 May 2011 17:32:50 GMT (envelope-from bcr) Date: Wed, 25 May 2011 17:32:50 GMT Message-Id: <201105251732.p4PHWoac018275@freefall.freebsd.org> To: bcr@FreeBSD.org, freebsd-doc@FreeBSD.org, bcr@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/155980: [patch] no NO_CHECKSUM in section ENVIRONMENT in man ports(7) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:32:50 -0000 Synopsis: [patch] no NO_CHECKSUM in section ENVIRONMENT in man ports(7) Responsible-Changed-From-To: freebsd-doc->bcr Responsible-Changed-By: bcr Responsible-Changed-When: Wed May 25 17:32:15 UTC 2011 Responsible-Changed-Why: Grab this one from the pool. http://www.freebsd.org/cgi/query-pr.cgi?pr=155980 From owner-freebsd-doc@FreeBSD.ORG Wed May 25 20:17:29 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61D2B1065673; Wed, 25 May 2011 20:17:29 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC4A8FC0C; Wed, 25 May 2011 20:17:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4PKHTDO062566; Wed, 25 May 2011 20:17:29 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PKHTo3062562; Wed, 25 May 2011 20:17:29 GMT (envelope-from bcr) Date: Wed, 25 May 2011 20:17:29 GMT Message-Id: <201105252017.p4PKHTo3062562@freefall.freebsd.org> To: bcr@FreeBSD.org, freebsd-doc@FreeBSD.org, bcf@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/157075: [patch] Use correct device names in gpioctl(8) man page X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:17:29 -0000 Synopsis: [patch] Use correct device names in gpioctl(8) man page Responsible-Changed-From-To: freebsd-doc->bcf Responsible-Changed-By: bcr Responsible-Changed-When: Wed May 25 20:16:39 UTC 2011 Responsible-Changed-Why: Take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=157075 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 07:40:08 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4344E106566B for ; Thu, 26 May 2011 07:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF518FC14 for ; Thu, 26 May 2011 07:40:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4Q7e89b014856 for ; Thu, 26 May 2011 07:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4Q7e7IE014854; Thu, 26 May 2011 07:40:07 GMT (envelope-from gnats) Date: Thu, 26 May 2011 07:40:07 GMT Message-Id: <201105260740.p4Q7e7IE014854@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Benedict Reuschling Cc: Subject: Re: docs/156187: [handbook] [patch] Add bsnmpd to handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benedict Reuschling List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 07:40:08 -0000 The following reply was made to PR docs/156187; it has been noted by GNATS. From: Benedict Reuschling To: bug-followup@FreeBSD.org, ofosos@gmail.com Cc: Subject: Re: docs/156187: [handbook] [patch] Add bsnmpd to handbook Date: Thu, 26 May 2011 09:39:29 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, this looks like a good addition to our handbook. Can you work on a new patch that includes the latest feedback form Ben Kaduk? I would be willing to help bring this into the handbook. Thanks! Benedict Reuschling FreeBSD Doc Committer The FreeBSD Documentation Project FreeBSD German Documentation Project - https://doc.bsdgroup.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3eA6sACgkQTSZQLkqBk0hgTwCgizmK6EfISlH6Mn8qO+93ODBA t5YAnRckZhQg4kp2OVBKBYCXUI6DjTSp =2Ldx -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Thu May 26 09:20:07 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BFB0106566C for ; Thu, 26 May 2011 09:20:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 105A38FC12 for ; Thu, 26 May 2011 09:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4Q9K6RK011112 for ; Thu, 26 May 2011 09:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4Q9K6H1011111; Thu, 26 May 2011 09:20:06 GMT (envelope-from gnats) Resent-Date: Thu, 26 May 2011 09:20:06 GMT Resent-Message-Id: <201105260920.p4Q9K6H1011111@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Niclas Zeising Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 456D4106566B for ; Thu, 26 May 2011 09:18:30 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 640328FC16 for ; Thu, 26 May 2011 09:18:27 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 140794001A for ; Thu, 26 May 2011 11:18:26 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id DF7D440007; Thu, 26 May 2011 11:18:25 +0200 (CEST) Received: from mx.daemonic.se (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id A3BDC4001A for ; Thu, 26 May 2011 11:18:15 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 5B95F119C04 for ; Thu, 26 May 2011 11:18:15 +0200 (CEST) Received: from vincent.daemonic.se (login.daemonic.se [IPv6:2001:470:dca9:0:1::10]) by mail.daemonic.se (Postfix) with ESMTPS id 2160A12B2DA for ; Thu, 26 May 2011 11:18:15 +0200 (CEST) Received: (from zeising@localhost) by vincent.daemonic.se (8.14.4/8.14.4/Submit) id p4Q9IEG9079073; Thu, 26 May 2011 11:18:14 +0200 (CEST) (envelope-from zeising) Message-Id: <201105260918.p4Q9IEG9079073@vincent.daemonic.se> Date: Thu, 26 May 2011 11:18:14 +0200 (CEST) From: Niclas Zeising To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/157337: [PATCH] Indentation changes to network servers chapter. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 09:20:07 -0000 >Number: 157337 >Category: docs >Synopsis: [PATCH] Indentation changes to network servers chapter. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Thu May 26 09:20:06 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Niclas Zeising >Release: FreeBSD 8.2-RELEASE amd64 >Organization: >Environment: System: FreeBSD vincent.daemonic.se 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Wed Apr 20 17:22:47 CEST 2011 root@vincent.daemonic.se:/usr/obj/usr/src/sys/VINCENT amd64 >Description: A huge patch to make whitespace and indentation consistent throughout the networks chapter. >How-To-Repeat: N/A >Fix: Attached patch makes indentation consistent. It changes spaces->tabs where appropriate, and makes stuff on the same level have the same indentation. --- network-servers.chapter.sgml-whitespace.diff begins here --- Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.133 diff -u -d -r1.133 chapter.sgml --- chapter.sgml 25 May 2011 16:55:01 -0000 1.133 +++ chapter.sgml 26 May 2011 08:52:39 -0000 @@ -8,7 +8,7 @@ - Murray + Murray Stokely Reorganized by @@ -92,8 +92,8 @@ - Know how to install additional third-party - software (). + Know how to install additional third-party + software (). @@ -102,11 +102,11 @@ - - Chern - Lee - Contributed by - + + Chern + Lee + Contributed by + @@ -185,7 +185,7 @@ modify its behaviour. The full list of options reads: inetd + [-p filename] [-R rate] [-s maximum] [configuration file] Options can be passed to inetd using the inetd_flags option in @@ -396,7 +396,7 @@ limits the number of children that can be started on behalf on any single IP address at any moment. These options are useful to prevent intentional or unintentional - excessive resource consumption and Denial of Service (DoS) + excessive resource consumption and Denial of Service (DoS) attacks to a machine. In this field, either of or @@ -528,18 +528,18 @@ - - Tom - Rhodes - Reorganized and enhanced by - + + Tom + Rhodes + Reorganized and enhanced by + - - Bill - Swingle + + Bill + Swingle Written by - + Network File System (NFS) @@ -583,29 +583,29 @@ How <acronym>NFS</acronym> Works NFS consists of at least two main - parts: a server and one or more clients. The client remotely - accesses the data that is stored on the server machine. In - order for this to function properly a few processes have to be - configured and running. + parts: a server and one or more clients. The client remotely + accesses the data that is stored on the server machine. In + order for this to function properly a few processes have to be + configured and running. The server has to be running the following daemons: - NFS - server + NFS + server - file server - UNIX clients + file server + UNIX clients rpcbind - mountd + mountd - nfsd + nfsd @@ -623,8 +623,8 @@ nfsd The NFS daemon which services - requests from the NFS - clients. + requests from the NFS + clients. mountd @@ -635,79 +635,79 @@ rpcbind This daemon allows NFS clients to discover which port - the NFS server is using. + the NFS server is using. The client can also run a daemon, known as - nfsiod. The - nfsiod daemon services the requests - from the NFS server. This is optional, and - improves performance, but is not required for normal and - correct operation. See the &man.nfsiod.8; manual page for - more information. + nfsiod. The + nfsiod daemon services the requests + from the NFS server. This is optional, and + improves performance, but is not required for normal and + correct operation. See the &man.nfsiod.8; manual page for + more information. Configuring <acronym>NFS</acronym> - NFS - configuration + NFS + configuration NFS configuration is a relatively - straightforward process. The processes that need to be - running can all start at boot time with a few modifications to - your /etc/rc.conf file. + straightforward process. The processes that need to be + running can all start at boot time with a few modifications to + your /etc/rc.conf file. On the NFS server, make sure that the - following options are configured in the - /etc/rc.conf file: + following options are configured in the + /etc/rc.conf file: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd runs automatically - whenever the NFS server is enabled. + whenever the NFS server is enabled. On the client, make sure this option is present in - /etc/rc.conf: + /etc/rc.conf: nfs_client_enable="YES" The /etc/exports file specifies which - file systems NFS should export (sometimes - referred to as share). Each line in - /etc/exports specifies a file system to be - exported and which machines have access to that file system. - Along with what machines have access to that file system, - access options may also be specified. There are many such - options that can be used in this file but only a few will be - mentioned here. You can easily discover other options by - reading over the &man.exports.5; manual page. + file systems NFS should export (sometimes + referred to as share). Each line in + /etc/exports specifies a file system to be + exported and which machines have access to that file system. + Along with what machines have access to that file system, + access options may also be specified. There are many such + options that can be used in this file but only a few will be + mentioned here. You can easily discover other options by + reading over the &man.exports.5; manual page. Here are a few example /etc/exports entries: - NFS - export examples + NFS + export examples The following examples give an idea of how to export - file systems, although the settings may be different depending - on your environment and network configuration. For instance, - to export the /cdrom directory to three - example machines that have the same domain name as the server - (hence the lack of a domain name for each) or have entries in - your /etc/hosts file. The - flag makes the exported file system - read-only. With this flag, the remote system will not be able - to write any changes to the exported file system. + file systems, although the settings may be different depending + on your environment and network configuration. For instance, + to export the /cdrom directory to three + example machines that have the same domain name as the server + (hence the lack of a domain name for each) or have entries in + your /etc/hosts file. The + flag makes the exported file system + read-only. With this flag, the remote system will not be able + to write any changes to the exported file system. /cdrom -ro host1 host2 host3 @@ -755,7 +755,7 @@ One file system, /usr, has two lines specifying exports to the same host, client. - The correct format for this situation is: + The correct format for this situation is: /usr/src /usr/ports client @@ -785,7 +785,7 @@ &prompt.root; kill -HUP `cat /var/run/mountd.pid` or by invoking the mountd &man.rc.8; script - with the appropriate parameter: + with the appropriate parameter: &prompt.root; /etc/rc.d/mountd onereload @@ -793,9 +793,9 @@ information about using rc scripts. Alternatively, a reboot will make FreeBSD set everything - up properly. A reboot is not necessary though. - Executing the following commands as root - should start everything up. + up properly. A reboot is not necessary though. + Executing the following commands as root + should start everything up. On the NFS server: @@ -813,10 +813,10 @@ name will be client. If you only want to temporarily mount a remote file system or would rather test the configuration, just execute a command like this as root on the - client: + client: - NFS - mounting + NFS + mounting &prompt.root; mount server:/home /mnt @@ -824,7 +824,7 @@ on the server at /mnt on the client. If everything is set up correctly you should be able to enter /mnt on the client and see all the files - that are on the server. + that are on the server. If you want to automatically mount a remote file system each time the computer boots, add the file system to the @@ -833,7 +833,7 @@ server:/home /mnt nfs rw 0 0 The &man.fstab.5; manual page lists all the available - options. + options. @@ -867,14 +867,14 @@ Practical Uses NFS has many practical uses. Some of - the more common ones are listed below: + the more common ones are listed below: - NFS - uses + NFS + uses - + Set several machines to share a CDROM or other media among them. This is cheaper and often a more convenient method to install software on multiple machines. @@ -891,10 +891,10 @@ Several machines could have a common - /usr/ports/distfiles directory. That - way, when you need to install a port on several machines, - you can quickly access the source without downloading it - on each machine. + /usr/ports/distfiles directory. That + way, when you need to install a port on several machines, + you can quickly access the source without downloading it + on each machine. @@ -918,8 +918,12 @@ Automatic Mounts with <application>amd</application> - amd - automatic mounter daemon + + amd + + + automatic mounter daemon + &man.amd.8; (the automatic mounter daemon) automatically mounts a @@ -929,7 +933,7 @@ amd. Using amd provides a simple alternative to permanent mounts, as permanent mounts are usually listed in - /etc/fstab. + /etc/fstab. amd operates by attaching itself as an NFS server to the /host and @@ -974,9 +978,9 @@ amd_enable="YES" Additionally, custom flags can be passed to - amd from the - amd_flags option. By default, - amd_flags is set to: + amd from the + amd_flags option. By default, + amd_flags is set to: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" @@ -991,13 +995,13 @@ - - - John - Lind - Contributed by - - + + + John + Lind + Contributed by + + Problems Integrating with Other Systems @@ -1111,11 +1115,11 @@ - - Bill - Swingle + + Bill + Swingle Written by - + @@ -1133,24 +1137,41 @@ What Is It? - NIS - Solaris - HP-UX - AIX - Linux - NetBSD - OpenBSD + + NIS + + + Solaris + + + HP-UX + + + AIX + + + Linux + + + NetBSD + + + OpenBSD + NIS, - which stands for Network Information Services, was developed - by Sun Microsystems to centralize administration of &unix; - (originally &sunos;) systems. It has now essentially become - an industry standard; all major &unix; like systems - (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, FreeBSD, - etc) support NIS. + which stands for Network Information Services, was developed + by Sun Microsystems to centralize administration of &unix; + (originally &sunos;) systems. It has now essentially become + an industry standard; all major &unix; like systems + (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, FreeBSD, + etc) support NIS. - yellow pagesNIS + + yellow pages + NIS + NIS was formerly known as Yellow Pages, but because of trademark @@ -1158,8 +1179,8 @@ often seen and used. - NIS - domains + NIS + domains It is a RPC-based client/server system that allows a group @@ -1169,20 +1190,22 @@ and add, remove or modify configuration data from a single location. - Windows NT + + Windows NT + It is similar to the &windowsnt; domain system; although - the internal implementation of the two are not at all similar, - the basic functionality can be compared. + the internal implementation of the two are not at all similar, + the basic functionality can be compared. Terms/Processes You Should Know There are several terms and several important user - processes that you will come across when attempting to - implement NIS on FreeBSD, whether you are trying to create an - NIS server or act as an NIS client: + processes that you will come across when attempting to + implement NIS on FreeBSD, whether you are trying to create an + NIS server or act as an NIS client: rpcbind @@ -1236,6 +1259,7 @@ ypserv + Should only be running on NIS servers; this is the NIS server process itself. If &man.ypserv.8; dies, then the server will no longer be able to @@ -1252,6 +1276,7 @@ rpc.yppasswdd + Another process that should only be running on NIS master servers; this is a daemon that will allow NIS clients to change their NIS passwords. If this daemon @@ -1286,52 +1311,52 @@ bound to instead. - Machine Types + Machine Types - + NIS master server - - A NIS master server. This - server, analogous to a &windowsnt; primary domain - controller, maintains the files used by all of the NIS - clients. The passwd, - group, and other various files used - by the NIS clients live on the master server. + + A NIS master server. This + server, analogous to a &windowsnt; primary domain + controller, maintains the files used by all of the NIS + clients. The passwd, + group, and other various files used + by the NIS clients live on the master server. - It is possible for one machine to be an NIS - master server for more than one NIS domain. However, - this will not be covered in this introduction, which - assumes a relatively small-scale NIS - environment. - + It is possible for one machine to be an NIS + master server for more than one NIS domain. However, + this will not be covered in this introduction, which + assumes a relatively small-scale NIS + environment. + NIS slave server - - NIS slave servers. Similar to - the &windowsnt; backup domain controllers, NIS slave - servers maintain copies of the NIS master's data files. - NIS slave servers provide the redundancy, which is - needed in important environments. They also help to - balance the load of the master server: NIS Clients - always attach to the NIS server whose response they get - first, and this includes slave-server-replies. - + + NIS slave servers. Similar to + the &windowsnt; backup domain controllers, NIS slave + servers maintain copies of the NIS master's data files. + NIS slave servers provide the redundancy, which is + needed in important environments. They also help to + balance the load of the master server: NIS Clients + always attach to the NIS server whose response they get + first, and this includes slave-server-replies. + NIS client - - NIS clients. NIS clients, like - most &windowsnt; workstations, authenticate against the - NIS server (or the &windowsnt; domain controller in the - &windowsnt; workstations case) to log on. - - + + NIS clients. NIS clients, like + most &windowsnt; workstations, authenticate against the + NIS server (or the &windowsnt; domain controller in the + &windowsnt; workstations case) to log on. + + @@ -1339,79 +1364,79 @@ Using NIS/YP This section will deal with setting up a sample NIS - environment. + environment. - Planning + Planning - Let us assume that you are the administrator of a small - university lab. This lab, which consists of 15 FreeBSD - machines, currently has no centralized point of - administration; each machine has its own - /etc/passwd and - /etc/master.passwd. These files are - kept in sync with each other only through manual - intervention; currently, when you add a user to the lab, you - must run adduser on all 15 machines. - Clearly, this has to change, so you have decided to convert - the lab to use NIS, using two of the machines as - servers. + Let us assume that you are the administrator of a small + university lab. This lab, which consists of 15 FreeBSD + machines, currently has no centralized point of + administration; each machine has its own + /etc/passwd and + /etc/master.passwd. These files are + kept in sync with each other only through manual + intervention; currently, when you add a user to the lab, you + must run adduser on all 15 machines. + Clearly, this has to change, so you have decided to convert + the lab to use NIS, using two of the machines as + servers. - Therefore, the configuration of the lab now looks something - like: + Therefore, the configuration of the lab now looks something + like: - - - - - Machine name - IP address - Machine role - - - - - ellington - 10.0.0.2 - NIS master - - - coltrane - 10.0.0.3 - NIS slave - - - basie - 10.0.0.4 - Faculty workstation - - - bird - 10.0.0.5 - Client machine - - - cli[1-11] - 10.0.0.[6-17] - Other client machines - - - - + + + + + Machine name + IP address + Machine role + + + + + ellington + 10.0.0.2 + NIS master + + + coltrane + 10.0.0.3 + NIS slave + + + basie + 10.0.0.4 + Faculty workstation + + + bird + 10.0.0.5 + Client machine + + + cli[1-11] + 10.0.0.[6-17] + Other client machines + + + + - If you are setting up a NIS scheme for the first time, it + If you are setting up a NIS scheme for the first time, it is a good idea to think through how you want to go about it. No matter what the size of your network, there are a few decisions that need to be made. - - Choosing a NIS Domain Name + + Choosing a NIS Domain Name NIS domainname - This might not be the domainname that + This might not be the domainname that you are used to. It is more accurately called the NIS domainname. When a client broadcasts its requests for info, it includes the name of the NIS @@ -1431,16 +1456,18 @@ assume you have chosen the name test-domain. - SunOS - However, some operating systems (notably &sunos;) use - their NIS domain name as their Internet domain name. If one - or more machines on your network have this restriction, you - must use the Internet domain name as - your NIS domain name. - + + SunOS + + However, some operating systems (notably &sunos;) use + their NIS domain name as their Internet domain name. If one + or more machines on your network have this restriction, you + must use the Internet domain name as + your NIS domain name. + - - Physical Server Requirements + + Physical Server Requirements There are several things to keep in mind when choosing a machine to use as a NIS server. One of the unfortunate @@ -1459,11 +1486,11 @@ the NIS server becomes unavailable, it will affect all of your NIS clients adversely. - + - NIS Servers + NIS Servers The canonical copies of all NIS information are stored on a single machine called the NIS master server. The @@ -1485,7 +1512,7 @@ database file and transmitting data from the database back to the client. - + Setting Up a NIS Master Server NIS @@ -1498,93 +1525,95 @@ /etc/rc.conf, and FreeBSD will do the rest for you. - - - nisdomainname="test-domain" - This line will set the NIS domainname to - test-domain - upon network setup (e.g. after reboot). - - - nis_server_enable="YES" - This will tell FreeBSD to start up the NIS server processes - when the networking is next brought up. - - - nis_yppasswdd_enable="YES" - This will enable the rpc.yppasswdd - daemon which, as mentioned above, will allow users to - change their NIS password from a client machine. - - + + + nisdomainname="test-domain" + This line will set the NIS domainname to + test-domain + upon network setup (e.g. after reboot). + + + nis_server_enable="YES" + This will tell FreeBSD to start up the NIS server processes + when the networking is next brought up. + + + nis_yppasswdd_enable="YES" + This will enable the rpc.yppasswdd + daemon which, as mentioned above, will allow users to + change their NIS password from a client machine. + + - - Depending on your NIS setup, you may need to add - further entries. See the section about NIS - servers that are also NIS clients, below, for - details. - + + Depending on your NIS setup, you may need to add + further entries. See the section about NIS + servers that are also NIS clients, below, for + details. + - After setting up the above entries, run the command - /etc/netstart as superuser. It will - set up everything for you, using the values you defined in - /etc/rc.conf. As a last step, before + After setting up the above entries, run the command + /etc/netstart as superuser. It will + set up everything for you, using the values you defined in + /etc/rc.conf. As a last step, before initializing the NIS maps, start the ypserv daemon manually: &prompt.root; /etc/rc.d/ypserv start - + - - Initializing the NIS Maps - - NIS - maps - - The NIS maps are database files, - that are kept in the /var/yp - directory. They are generated from configuration files in - the /etc directory of the NIS master, - with one exception: the - /etc/master.passwd file. This is for - a good reason, you do not want to propagate passwords to - your root and other administrative - accounts to all the servers in the NIS domain. Therefore, - before we initialize the NIS maps, you should: + + Initializing the NIS Maps + + NIS + maps + + The NIS maps are database files, + that are kept in the /var/yp + directory. They are generated from configuration files in + the /etc directory of the NIS master, + with one exception: the + /etc/master.passwd file. This is for + a good reason, you do not want to propagate passwords to + your root and other administrative + accounts to all the servers in the NIS domain. Therefore, + before we initialize the NIS maps, you should: - &prompt.root; cp /etc/master.passwd /var/yp/master.passwd + &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd - You should remove all entries regarding system - accounts (bin, - tty, kmem, - games, etc), as well as any accounts - that you do not want to be propagated to the NIS clients - (for example root and any other UID 0 - (superuser) accounts). + You should remove all entries regarding system + accounts (bin, + tty, kmem, + games, etc), as well as any accounts + that you do not want to be propagated to the NIS clients + (for example root and any other UID 0 + (superuser) accounts). - Make sure the - /var/yp/master.passwd is neither group - nor world readable (mode 600)! Use the - chmod command, if appropriate. + Make sure the + /var/yp/master.passwd is neither group + nor world readable (mode 600)! Use the + chmod command, if appropriate. - Tru64 UNIX + + Tru64 UNIX + - When you have finished, it is time to initialize the - NIS maps! FreeBSD includes a script named - ypinit to do this for you (see its - manual page for more information). Note that this script - is available on most &unix; Operating Systems, but not on - all. On Digital UNIX/Compaq Tru64 UNIX it is called - ypsetup. Because we are generating - maps for an NIS master, we are going to pass the - option to ypinit. - To generate the NIS maps, assuming you already performed - the steps above, run: + When you have finished, it is time to initialize the + NIS maps! FreeBSD includes a script named + ypinit to do this for you (see its + manual page for more information). Note that this script + is available on most &unix; Operating Systems, but not on + all. On Digital UNIX/Compaq Tru64 UNIX it is called + ypsetup. Because we are generating + maps for an NIS master, we are going to pass the + option to ypinit. + To generate the NIS maps, assuming you already performed + the steps above, run: - ellington&prompt.root; ypinit -m test-domain + ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. @@ -1608,25 +1637,25 @@ NIS Map update completed. ellington has been setup as an YP master server without any errors. - ypinit should have created - /var/yp/Makefile from - /var/yp/Makefile.dist. - When created, this file assumes that you are operating - in a single server NIS environment with only FreeBSD - machines. Since test-domain has - a slave server as well, you must edit - /var/yp/Makefile: + ypinit should have created + /var/yp/Makefile from + /var/yp/Makefile.dist. + When created, this file assumes that you are operating + in a single server NIS environment with only FreeBSD + machines. Since test-domain has + a slave server as well, you must edit + /var/yp/Makefile: - ellington&prompt.root; vi /var/yp/Makefile + ellington&prompt.root; vi /var/yp/Makefile You should comment out the line that says NOPUSH = "True" (if it is not commented out already). - + - + Setting up a NIS Slave Server NIS @@ -1634,14 +1663,14 @@ Setting up an NIS slave server is even more simple than setting up the master. Log on to the slave server and edit the - file /etc/rc.conf as you did before. - The only difference is that we now must use the - option when running ypinit. - The option requires the name of the NIS - master be passed to it as well, so our command line looks - like: + file /etc/rc.conf as you did before. + The only difference is that we now must use the + option when running ypinit. + The option requires the name of the NIS + master be passed to it as well, so our command line looks + like: - coltrane&prompt.root; ypinit -s ellington test-domain + coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington @@ -1718,13 +1747,13 @@ is especially important on busy networks where map updates might not always complete. - Now, run the command /etc/netstart on the - slave server as well, which again starts the NIS server. + Now, run the command /etc/netstart on the + slave server as well, which again starts the NIS server. - NIS Clients + NIS Clients An NIS client establishes what is called a binding to a particular NIS server using the @@ -1761,9 +1790,9 @@ Edit the file /etc/rc.conf and - add the following lines in order to set the NIS domainname - and start ypbind upon network - startup: + add the following lines in order to set the NIS domainname + and start ypbind upon network + startup: nisdomainname="test-domain" nis_client_enable="YES" @@ -1774,7 +1803,7 @@ server, remove all user accounts from your /etc/master.passwd file and use vipw to add the following line to - the end of the file: + the end of the file: +::::::::: @@ -1784,20 +1813,20 @@ many ways to configure your NIS client by changing this line. See the netgroups section below for more information. - For more detailed reading see O'Reilly's book on + For more detailed reading see O'Reilly's book on Managing NFS and NIS. - - You should keep at least one local account (i.e. - not imported via NIS) in your - /etc/master.passwd and this - account should also be a member of the group - wheel. If there is something - wrong with NIS, this account can be used to log in - remotely, become root, and fix things. - - + + You should keep at least one local account (i.e. + not imported via NIS) in your + /etc/master.passwd and this + account should also be a member of the group + wheel. If there is something + wrong with NIS, this account can be used to log in + remotely, become root, and fix things. + + To import all possible group entries from the NIS @@ -1869,35 +1898,37 @@ /var/yp/securenets. - While both of these access control mechanisms provide some - security, they, like the privileged port test, are - vulnerable to IP spoofing attacks. All - NIS-related traffic should be blocked at your firewall. + While both of these access control mechanisms provide some + security, they, like the privileged port test, are + vulnerable to IP spoofing attacks. All + NIS-related traffic should be blocked at your firewall. - Servers using /var/yp/securenets - may fail to serve legitimate NIS clients with archaic TCP/IP - implementations. Some of these implementations set all - host bits to zero when doing broadcasts and/or fail to - observe the subnet mask when calculating the broadcast - address. While some of these problems can be fixed by - changing the client configuration, other problems may force - the retirement of the client systems in question or the - abandonment of /var/yp/securenets. + Servers using /var/yp/securenets + may fail to serve legitimate NIS clients with archaic TCP/IP + implementations. Some of these implementations set all + host bits to zero when doing broadcasts and/or fail to + observe the subnet mask when calculating the broadcast + address. While some of these problems can be fixed by + changing the client configuration, other problems may force + the retirement of the client systems in question or the + abandonment of /var/yp/securenets. - Using /var/yp/securenets on a - server with such an archaic implementation of TCP/IP is a - really bad idea and will lead to loss of NIS functionality - for large parts of your network. + Using /var/yp/securenets on a + server with such an archaic implementation of TCP/IP is a + really bad idea and will lead to loss of NIS functionality + for large parts of your network. - TCP Wrappers - The use of the TCP Wrapper - package increases the latency of your NIS server. The - additional delay may be long enough to cause timeouts in - client programs, especially in busy networks or with slow - NIS servers. If one or more of your client systems - suffers from these symptoms, you should convert the client - systems in question into NIS slave servers and force them - to bind to themselves. + + TCP Wrappers + + The use of the TCP Wrapper + package increases the latency of your NIS server. The + additional delay may be long enough to cause timeouts in + client programs, especially in busy networks or with slow + NIS servers. If one or more of your client systems + suffers from these symptoms, you should convert the client + systems in question into NIS slave servers and force them + to bind to themselves. @@ -1905,28 +1936,28 @@ Barring Some Users from Logging On In our lab, there is a machine basie that - is supposed to be a faculty only workstation. We do not want - to take this machine out of the NIS domain, yet the - passwd file on the master NIS server - contains accounts for both faculty and students. What can we - do? + is supposed to be a faculty only workstation. We do not want + to take this machine out of the NIS domain, yet the + passwd file on the master NIS server + contains accounts for both faculty and students. What can we + do? There is a way to bar specific users from logging on to a - machine, even if they are present in the NIS database. To do - this, all you must do is add - -username to the - end of the /etc/master.passwd file on the - client machine, where username is - the username of the user you wish to bar from logging in. - This should preferably be done using vipw, - since vipw will sanity check your changes - to /etc/master.passwd, as well as - automatically rebuild the password database when you finish - editing. For example, if we wanted to bar user - bill from logging on to - basie we would: + machine, even if they are present in the NIS database. To do + this, all you must do is add + -username to the + end of the /etc/master.passwd file on the + client machine, where username is + the username of the user you wish to bar from logging in. + This should preferably be done using vipw, + since vipw will sanity check your changes + to /etc/master.passwd, as well as + automatically rebuild the password database when you finish + editing. For example, if we wanted to bar user + bill from logging on to + basie we would: - basie&prompt.root; vipw + basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done @@ -1956,165 +1987,167 @@ - - - Udo - Erdelhoff - Contributed by - - + + + Udo + Erdelhoff + Contributed by + + Using Netgroups - netgroups + + netgroups + The method shown in the previous section works reasonably - well if you need special rules for a very small number of - users and/or machines. On larger networks, you - will forget to bar some users from logging - onto sensitive machines, or you may even have to modify each - machine separately, thus losing the main benefit of NIS: - centralized administration. + well if you need special rules for a very small number of + users and/or machines. On larger networks, you + will forget to bar some users from logging + onto sensitive machines, or you may even have to modify each + machine separately, thus losing the main benefit of NIS: + centralized administration. The NIS developers' solution for this problem is called - netgroups. Their purpose and semantics - can be compared to the normal groups used by &unix; file - systems. The main differences are the lack of a numeric ID - and the ability to define a netgroup by including both user - accounts and other netgroups. + netgroups. Their purpose and semantics + can be compared to the normal groups used by &unix; file + systems. The main differences are the lack of a numeric ID + and the ability to define a netgroup by including both user + accounts and other netgroups. Netgroups were developed to handle large, complex networks - with hundreds of users and machines. On one hand, this is - a Good Thing if you are forced to deal with such a situation. - On the other hand, this complexity makes it almost impossible to - explain netgroups with really simple examples. The example - used in the remainder of this section demonstrates this - problem. + with hundreds of users and machines. On one hand, this is + a Good Thing if you are forced to deal with such a situation. + On the other hand, this complexity makes it almost impossible to + explain netgroups with really simple examples. The example + used in the remainder of this section demonstrates this + problem. Let us assume that your successful introduction of NIS in - your laboratory caught your superiors' interest. Your next - job is to extend your NIS domain to cover some of the other - machines on campus. The two tables contain the names of the - new users and new machines as well as brief descriptions of - them. + your laboratory caught your superiors' interest. Your next + job is to extend your NIS domain to cover some of the other + machines on campus. The two tables contain the names of the + new users and new machines as well as brief descriptions of + them. - - - - User Name(s) - Description - - + + + + User Name(s) + Description + + - - - alpha, beta - Normal employees of the IT department - + + + alpha, beta + Normal employees of the IT department + - - charlie, delta - The new apprentices of the IT department - + + charlie, delta + The new apprentices of the IT department + - - echo, foxtrott, golf, ... - Ordinary employees - + + echo, foxtrott, golf, ... + Ordinary employees + - - able, baker, ... - The current interns - - - + + able, baker, ... + The current interns + + + - - - - Machine Name(s) - Description - - + + + + Machine Name(s) + Description + + - - - + + + - war, death, - famine, - pollution - Your most important servers. Only the IT - employees are allowed to log onto these - machines. - - + war, death, + famine, + pollution + Your most important servers. Only the IT + employees are allowed to log onto these + machines. + + - pride, greed, - envy, wrath, - lust, sloth - Less important servers. All members of the IT - department are allowed to login onto these - machines. - + pride, greed, + envy, wrath, + lust, sloth + Less important servers. All members of the IT + department are allowed to login onto these + machines. + - - one, two, - three, four, - ... + + one, two, + three, four, + ... - Ordinary workstations. Only the - real employees are allowed to use - these machines. - + Ordinary workstations. Only the + real employees are allowed to use + these machines. + - - trashcan - A very old machine without any critical data. - Even the intern is allowed to use this box. - - - + + trashcan + A very old machine without any critical data. + Even the intern is allowed to use this box. + + + If you tried to implement these restrictions by separately - blocking each user, you would have to add one - -user line to - each system's passwd for each user who is - not allowed to login onto that system. If you forget just one - entry, you could be in trouble. It may be feasible to do this - correctly during the initial setup, however you - will eventually forget to add the lines - for new users during day-to-day operations. After all, Murphy - was an optimist. + blocking each user, you would have to add one + -user line to + each system's passwd for each user who is + not allowed to login onto that system. If you forget just one + entry, you could be in trouble. It may be feasible to do this + correctly during the initial setup, however you + will eventually forget to add the lines + for new users during day-to-day operations. After all, Murphy + was an optimist. Handling this situation with netgroups offers several - advantages. Each user need not be handled separately; you - assign a user to one or more netgroups and allow or forbid - logins for all members of the netgroup. If you add a new - machine, you will only have to define login restrictions for - netgroups. If a new user is added, you will only have to add - the user to one or more netgroups. Those changes are - independent of each other: no more for each combination - of user and machine do... If your NIS setup is planned - carefully, you will only have to modify exactly one central - configuration file to grant or deny access to machines. + advantages. Each user need not be handled separately; you + assign a user to one or more netgroups and allow or forbid + logins for all members of the netgroup. If you add a new + machine, you will only have to define login restrictions for + netgroups. If a new user is added, you will only have to add + the user to one or more netgroups. Those changes are + independent of each other: no more for each combination + of user and machine do... If your NIS setup is planned + carefully, you will only have to modify exactly one central + configuration file to grant or deny access to machines. The first step is the initialization of the NIS map - netgroup. FreeBSD's &man.ypinit.8; does not create this map by - default, but its NIS implementation will support it once it has - been created. To create an empty map, simply type + netgroup. FreeBSD's &man.ypinit.8; does not create this map by + default, but its NIS implementation will support it once it has + been created. To create an empty map, simply type ellington&prompt.root; vi /var/yp/netgroup and start adding content. For our example, we need at - least four netgroups: IT employees, IT apprentices, normal - employees and interns. + least four netgroups: IT employees, IT apprentices, normal + employees and interns. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) @@ -2123,85 +2156,87 @@ INTERNS (,able,test-domain) (,baker,test-domain) IT_EMP, IT_APP etc. - are the names of the netgroups. Each bracketed group adds - one or more user accounts to it. The three fields inside a - group are: + are the names of the netgroups. Each bracketed group adds + one or more user accounts to it. The three fields inside a + group are: - - The name of the host(s) where the following items are - valid. If you do not specify a hostname, the entry is - valid on all hosts. If you do specify a hostname, you - will enter a realm of darkness, horror and utter confusion. - + + The name of the host(s) where the following items are + valid. If you do not specify a hostname, the entry is + valid on all hosts. If you do specify a hostname, you + will enter a realm of darkness, horror and utter confusion. + - - The name of the account that belongs to this - netgroup. - + + The name of the account that belongs to this + netgroup. + - - The NIS domain for the account. You can import - accounts from other NIS domains into your netgroup if you - are one of the unlucky fellows with more than one NIS - domain. - + + The NIS domain for the account. You can import + accounts from other NIS domains into your netgroup if you + are one of the unlucky fellows with more than one NIS + domain. + Each of these fields can contain wildcards. See - &man.netgroup.5; for details. + &man.netgroup.5; for details. - netgroups - Netgroup names longer than 8 characters should not be - used, especially if you have machines running other - operating systems within your NIS domain. The names are - case sensitive; using capital letters for your netgroup - names is an easy way to distinguish between user, machine - and netgroup names. + + netgroups + + Netgroup names longer than 8 characters should not be + used, especially if you have machines running other + operating systems within your NIS domain. The names are + case sensitive; using capital letters for your netgroup + names is an easy way to distinguish between user, machine + and netgroup names. - Some NIS clients (other than FreeBSD) cannot handle - netgroups with a large number of entries. For example, some - older versions of &sunos; start to cause trouble if a netgroup - contains more than 15 entries. You can - circumvent this limit by creating several sub-netgroups with - 15 users or less and a real netgroup that consists of the - sub-netgroups: + Some NIS clients (other than FreeBSD) cannot handle + netgroups with a large number of entries. For example, some + older versions of &sunos; start to cause trouble if a netgroup + contains more than 15 entries. You can + circumvent this limit by creating several sub-netgroups with + 15 users or less and a real netgroup that consists of the + sub-netgroups: - BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] + BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - You can repeat this process if you need more than 225 - users within a single netgroup. + You can repeat this process if you need more than 225 + users within a single netgroup. Activating and distributing your new NIS map is - easy: + easy: ellington&prompt.root; cd /var/yp ellington&prompt.root; make This will generate the three NIS maps - netgroup, - netgroup.byhost and - netgroup.byuser. Use &man.ypcat.1; to - check if your new NIS maps are available: + netgroup, + netgroup.byhost and + netgroup.byuser. Use &man.ypcat.1; to + check if your new NIS maps are available: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser The output of the first command should resemble the - contents of /var/yp/netgroup. The second - command will not produce output if you have not specified - host-specific netgroups. The third command can be used to - get the list of netgroups for a user. + contents of /var/yp/netgroup. The second + command will not produce output if you have not specified + host-specific netgroups. The third command can be used to + get the list of netgroups for a user. The client setup is quite simple. To configure the server - war, you only have to start - &man.vipw.8; and replace the line + war, you only have to start + &man.vipw.8; and replace the line +::::::::: @@ -2210,9 +2245,9 @@ +@IT_EMP::::::::: Now, only the data for the users defined in the netgroup - IT_EMP is imported into - war's password database and only - these users are allowed to login. + IT_EMP is imported into + war's password database and only + these users are allowed to login. Unfortunately, this limitation also applies to the ~ function of the shell and all routines @@ -2227,97 +2262,97 @@ servers. This can be achieved by adding another line to - /etc/master.passwd. This line should - contain: + /etc/master.passwd. This line should + contain: +:::::::::/sbin/nologin, meaning - Import all entries but replace the shell with - /sbin/nologin in the imported - entries. You can replace any field in the - passwd entry by placing a default value in - your /etc/master.passwd. + Import all entries but replace the shell with + /sbin/nologin in the imported + entries. You can replace any field in the + passwd entry by placing a default value in + your /etc/master.passwd. - Make sure that the line - +:::::::::/sbin/nologin is placed after - +@IT_EMP:::::::::. Otherwise, all user - accounts imported from NIS will have /sbin/nologin as their - login shell. + Make sure that the line + +:::::::::/sbin/nologin is placed after + +@IT_EMP:::::::::. Otherwise, all user + accounts imported from NIS will have /sbin/nologin as their + login shell. After this change, you will only have to change one NIS - map if a new employee joins the IT department. You could use - a similar approach for the less important servers by replacing - the old +::::::::: in their local version - of /etc/master.passwd with something like - this: + map if a new employee joins the IT department. You could use + a similar approach for the less important servers by replacing + the old +::::::::: in their local version + of /etc/master.passwd with something like + this: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin The corresponding lines for the normal workstations - could be: + could be: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin And everything would be fine until there is a policy - change a few weeks later: The IT department starts hiring - interns. The IT interns are allowed to use the normal - workstations and the less important servers; and the IT - apprentices are allowed to login onto the main servers. You - add a new netgroup IT_INTERN, add the new - IT interns to this netgroup and start to change the - configuration on each and every machine... As the old saying - goes: Errors in centralized planning lead to global - mess. + change a few weeks later: The IT department starts hiring + interns. The IT interns are allowed to use the normal + workstations and the less important servers; and the IT + apprentices are allowed to login onto the main servers. You + add a new netgroup IT_INTERN, add the new + IT interns to this netgroup and start to change the + configuration on each and every machine... As the old saying + goes: Errors in centralized planning lead to global + mess. NIS' ability to create netgroups from other netgroups can - be used to prevent situations like these. One possibility - is the creation of role-based netgroups. For example, you - could create a netgroup called - BIGSRV to define the login - restrictions for the important servers, another netgroup - called SMALLSRV for the less - important servers and a third netgroup called - USERBOX for the normal - workstations. Each of these netgroups contains the netgroups - that are allowed to login onto these machines. The new - entries for your NIS map netgroup should look like this: + be used to prevent situations like these. One possibility + is the creation of role-based netgroups. For example, you + could create a netgroup called + BIGSRV to define the login + restrictions for the important servers, another netgroup + called SMALLSRV for the less + important servers and a third netgroup called + USERBOX for the normal + workstations. Each of these netgroups contains the netgroups + that are allowed to login onto these machines. The new + entries for your NIS map netgroup should look like this: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS This method of defining login restrictions works - reasonably well if you can define groups of machines with - identical restrictions. Unfortunately, this is the exception - and not the rule. Most of the time, you will need the ability - to define login restrictions on a per-machine basis. + reasonably well if you can define groups of machines with + identical restrictions. Unfortunately, this is the exception + and not the rule. Most of the time, you will need the ability + to define login restrictions on a per-machine basis. Machine-specific netgroup definitions are the other - possibility to deal with the policy change outlined above. In - this scenario, the /etc/master.passwd of - each box contains two lines starting with +. - The first of them adds a netgroup with the accounts allowed to - login onto this machine, the second one adds all other - accounts with /sbin/nologin as shell. It - is a good idea to use the ALL-CAPS version of - the machine name as the name of the netgroup. In other words, - the lines should look like this: + possibility to deal with the policy change outlined above. In + this scenario, the /etc/master.passwd of + each box contains two lines starting with +. + The first of them adds a netgroup with the accounts allowed to + login onto this machine, the second one adds all other + accounts with /sbin/nologin as shell. It + is a good idea to use the ALL-CAPS version of + the machine name as the name of the netgroup. In other words, + the lines should look like this: +@BOXNAME::::::::: +:::::::::/sbin/nologin Once you have completed this task for all your machines, - you will not have to modify the local versions of - /etc/master.passwd ever again. All - further changes can be handled by modifying the NIS map. Here - is an example of a possible netgroup map for this - scenario with some additional goodies: + you will not have to modify the local versions of + /etc/master.passwd ever again. All + further changes can be handled by modifying the NIS map. Here + is an example of a possible netgroup map for this + scenario with some additional goodies: # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) @@ -2356,60 +2391,60 @@ # [...more groups to follow] If you are using some kind of database to manage your user - accounts, you should be able to create the first part of the - map with your database's report tools. This way, new users - will automatically have access to the boxes. + accounts, you should be able to create the first part of the + map with your database's report tools. This way, new users + will automatically have access to the boxes. One last word of caution: It may not always be advisable - to use machine-based netgroups. If you are deploying a couple of - dozen or even hundreds of identical machines for student labs, - you should use role-based netgroups instead of machine-based - netgroups to keep the size of the NIS map within reasonable - limits. + to use machine-based netgroups. If you are deploying a couple of + dozen or even hundreds of identical machines for student labs, + you should use role-based netgroups instead of machine-based + netgroups to keep the size of the NIS map within reasonable + limits. Important Things to Remember There are still a couple of things that you will need to do - differently now that you are in an NIS environment. + differently now that you are in an NIS environment. - - Every time you wish to add a user to the lab, you - must add it to the master NIS server only, - and you must remember to rebuild the NIS - maps. If you forget to do this, the new user will - not be able to login anywhere except on the NIS master. - For example, if we needed to add a new user - jsmith to the lab, we would: + + Every time you wish to add a user to the lab, you + must add it to the master NIS server only, + and you must remember to rebuild the NIS + maps. If you forget to do this, the new user will + not be able to login anywhere except on the NIS master. + For example, if we needed to add a new user + jsmith to the lab, we would: - &prompt.root; pw useradd jsmith + &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain - You could also run adduser jsmith instead - of pw useradd jsmith. - - - Keep the administration accounts out of the - NIS maps. You do not want to be propagating - administrative accounts and passwords to machines that - will have users that should not have access to those - accounts. - - - Keep the NIS master and slave secure, and - minimize their downtime. If somebody either - hacks or simply turns off these machines, they have - effectively rendered many people without the ability to - login to the lab. + You could also run adduser jsmith instead + of pw useradd jsmith. + + + Keep the administration accounts out of the + NIS maps. You do not want to be propagating + administrative accounts and passwords to machines that + will have users that should not have access to those + accounts. + + + Keep the NIS master and slave secure, and + minimize their downtime. If somebody either + hacks or simply turns off these machines, they have + effectively rendered many people without the ability to + login to the lab. - This is the chief weakness of any centralized administration - system. If you do - not protect your NIS servers, you will have a lot of angry - users! - + This is the chief weakness of any centralized administration + system. If you do + not protect your NIS servers, you will have a lot of angry + users! + @@ -2453,8 +2488,8 @@ You can force a host to bind to a particular server by running ypbind with the flag. If you do not want to do this manually each time you - reboot your NIS server, you can add the following lines to - your /etc/rc.conf: + reboot your NIS server, you can add the following lines to + your /etc/rc.conf: nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" @@ -2465,7 +2500,7 @@ Password Formats - NIS + NIS password formats One of the most common issues that people run into when trying @@ -2497,11 +2532,13 @@ &prompt.root; cap_mkdb /etc/login.conf - The format of passwords already in - /etc/master.passwd will not be updated - until a user changes his password for the first time - after the login capability database is - rebuilt. + + The format of passwords already in + /etc/master.passwd will not be updated + until a user changes his password for the first time + after the login capability database is + rebuilt. + Next, in order to ensure that passwords are encrypted with the format that you have chosen, you should also check that @@ -2527,11 +2564,11 @@ - - Greg - Sutter + + Greg + Sutter Written by - + Automatic Network Configuration (DHCP) @@ -2539,16 +2576,16 @@ What Is DHCP? - Dynamic Host Configuration Protocol - DHCP + Dynamic Host Configuration Protocol + DHCP - Internet Systems Consortium (ISC) + Internet Systems Consortium (ISC) DHCP, the Dynamic Host Configuration Protocol, describes - the means by which a system can connect to a network and obtain the - necessary information for communication upon that network. FreeBSD + the means by which a system can connect to a network and obtain the + necessary information for communication upon that network. FreeBSD uses the OpenBSD dhclient taken from OpenBSD 3.7. All information here regarding dhclient is for @@ -2559,20 +2596,23 @@ What This Section Covers - This section describes both the client-side components of the ISC and OpenBSD DHCP client and - server-side components of the ISC DHCP system. The - client-side program, dhclient, comes - integrated within FreeBSD, and the server-side portion is - available from the net/isc-dhcp31-server port. The - &man.dhclient.8;, &man.dhcp-options.5;, and - &man.dhclient.conf.5; manual pages, in addition to the - references below, are useful resources. + This section describes both the client-side components + of the ISC and OpenBSD DHCP client and + server-side components of the ISC DHCP system. The + client-side program, dhclient, comes + integrated within FreeBSD, and the server-side portion is + available from the net/isc-dhcp31-server port. The + &man.dhclient.8;, &man.dhcp-options.5;, and + &man.dhclient.conf.5; manual pages, in addition to the + references below, are useful resources. How It Works - UDP + + UDP + When dhclient, the DHCP client, is executed on the client machine, it begins broadcasting requests for configuration information. By default, these @@ -2586,132 +2626,136 @@ network can be automatically reclaimed. DHCP clients can obtain a great deal of information from - the server. An exhaustive list may be found in - &man.dhcp-options.5;. + the server. An exhaustive list may be found in + &man.dhcp-options.5;. FreeBSD Integration &os; fully integrates the OpenBSD DHCP client, - dhclient. DHCP client support is provided - within both the installer and the base system, obviating the need - for detailed knowledge of network configurations on any network - that runs a DHCP server. - - sysinstall - + dhclient. DHCP client support is provided + within both the installer and the base system, obviating the need + for detailed knowledge of network configurations on any network + that runs a DHCP server. + + sysinstall + - DHCP is supported by - sysinstall. When configuring a - network interface within - sysinstall, the second question - asked is: Do you want to try DHCP configuration of - the interface?. Answering affirmatively will - execute dhclient, and if successful, will - fill in the network configuration information - automatically. + DHCP is supported by + sysinstall. When configuring a + network interface within + sysinstall, the second question + asked is: Do you want to try DHCP configuration of + the interface?. Answering affirmatively will + execute dhclient, and if successful, will + fill in the network configuration information + automatically. - There are two things you must do to have your system use - DHCP upon startup: - - DHCP - requirements - - - - Make sure that the bpf - device is compiled into your kernel. To do this, add - device bpf to your kernel - configuration file, and rebuild the kernel. For more - information about building kernels, see . The - bpf device is already part of - the GENERIC kernel that is supplied - with FreeBSD, so if you do not have a custom kernel, you - should not need to create one in order to get DHCP - working. - - For those who are particularly security conscious, - you should be warned that bpf - is also the device that allows packet sniffers to work - correctly (although they still have to be run as - root). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not add bpf to your - kernel in the expectation that at some point in the - future you will be using DHCP. - - - - Edit your /etc/rc.conf to - include the following: + There are two things you must do to have your system use + DHCP upon startup: + + DHCP + requirements + + + + Make sure that the bpf + device is compiled into your kernel. To do this, add + device bpf to your kernel + configuration file, and rebuild the kernel. For more + information about building kernels, see . The + bpf device is already part of + the GENERIC kernel that is supplied + with FreeBSD, so if you do not have a custom kernel, you + should not need to create one in order to get DHCP + working. + + For those who are particularly security conscious, + you should be warned that bpf + is also the device that allows packet sniffers to work + correctly (although they still have to be run as + root). bpf + is required to use DHCP, but if + you are very sensitive about security, you probably + should not add bpf to your + kernel in the expectation that at some point in the + future you will be using DHCP. + + + + Edit your /etc/rc.conf to + include the following: - ifconfig_fxp0="DHCP" + ifconfig_fxp0="DHCP" - - Be sure to replace fxp0 with the - designation for the interface that you wish to dynamically - configure, as described in - . - + + Be sure to replace fxp0 with the + designation for the interface that you wish to dynamically + configure, as described in + . + - If you are using a different location for - dhclient, or if you wish to pass additional - flags to dhclient, also include the - following (editing as necessary): + If you are using a different location for + dhclient, or if you wish to pass additional + flags to dhclient, also include the + following (editing as necessary): - dhclient_program="/sbin/dhclient" + dhclient_program="/sbin/dhclient" dhclient_flags="" - - + + - - DHCP - server - - The DHCP server, dhcpd, is included - as part of the net/isc-dhcp31-server port in the ports - collection. This port contains the ISC DHCP server and - documentation. + + DHCP + server + + The DHCP server, dhcpd, is included + as part of the net/isc-dhcp31-server port in the ports + collection. This port contains the ISC DHCP server and + documentation. Files - DHCP - configuration files + DHCP + configuration files - /etc/dhclient.conf - dhclient requires a configuration file, - /etc/dhclient.conf. Typically the file - contains only comments, the defaults being reasonably sane. This - configuration file is described by the &man.dhclient.conf.5; - manual page. - + + /etc/dhclient.conf + dhclient requires a configuration file, + /etc/dhclient.conf. Typically the file + contains only comments, the defaults being reasonably sane. This + configuration file is described by the &man.dhclient.conf.5; + manual page. + - /sbin/dhclient - dhclient is statically linked and - resides in /sbin. The &man.dhclient.8; - manual page gives more information about - dhclient. - + + /sbin/dhclient + dhclient is statically linked and + resides in /sbin. The &man.dhclient.8; + manual page gives more information about + dhclient. + - /sbin/dhclient-script - dhclient-script is the FreeBSD-specific - DHCP client configuration script. It is described in - &man.dhclient-script.8;, but should not need any user - modification to function properly. - + + /sbin/dhclient-script + dhclient-script is the FreeBSD-specific + DHCP client configuration script. It is described in + &man.dhclient-script.8;, but should not need any user + modification to function properly. + - /var/db/dhclient.leases - The DHCP client keeps a database of valid leases in this - file, which is written as a log. &man.dhclient.leases.5; - gives a slightly longer description. - + + /var/db/dhclient.leases + The DHCP client keeps a database of valid leases in this + file, which is written as a log. &man.dhclient.leases.5; + gives a slightly longer description. + @@ -2719,9 +2763,9 @@ Further Reading The DHCP protocol is fully described in - RFC 2131. - An informational resource has also been set up at - . + RFC 2131. + An informational resource has also been set up at + . @@ -2761,18 +2805,18 @@ supplied with FreeBSD, so you do not need to create a custom kernel in order to get DHCP working. - - Those who are particularly security conscious - should note that bpf - is also the device that allows packet sniffers to work - correctly (although such programs still need privileged - access). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not include bpf in your - kernel purely because you expect to use DHCP at some - point in the future. - + + Those who are particularly security conscious + should note that bpf + is also the device that allows packet sniffers to work + correctly (although such programs still need privileged + access). bpf + is required to use DHCP, but if + you are very sensitive about security, you probably + should not include bpf in your + kernel purely because you expect to use DHCP at some + point in the future. + The next thing that you will need to do is edit the sample dhcpd.conf which was installed by the @@ -2909,7 +2953,8 @@ configuration files - /usr/local/sbin/dhcpd + + /usr/local/sbin/dhcpd dhcpd is statically linked and resides in /usr/local/sbin. The &man.dhcpd.8; manual page installed with the @@ -2917,7 +2962,8 @@ dhcpd. - /usr/local/etc/dhcpd.conf + + /usr/local/etc/dhcpd.conf dhcpd requires a configuration file, /usr/local/etc/dhcpd.conf before it will start providing service to clients. This file needs to @@ -2928,14 +2974,16 @@ by the port. - /var/db/dhcpd.leases + + /var/db/dhcpd.leases The DHCP server keeps a database of leases it has issued in this file, which is written as a log. The manual page &man.dhcpd.leases.5;, installed by the port gives a slightly longer description. - /usr/local/sbin/dhcrelay + + /usr/local/sbin/dhcrelay dhcrelay is used in advanced environments where one DHCP server forwards a request from a client to another DHCP server on a separate network. If you @@ -2954,11 +3002,11 @@ - - Chern - Lee - Contributed by - + + Chern + Lee + Contributed by + Tom @@ -2975,7 +3023,9 @@ Overview - BIND + + BIND + &os; utilizes, by default, a version of BIND (Berkeley Internet Name Domain), which is the most common implementation @@ -2997,7 +3047,9 @@ installation provides enhanced security features, a new file system layout and automated &man.chroot.8; configuration. - DNS + + DNS + DNS is coordinated across the Internet through a somewhat complex system of authoritative root, Top Level Domain (TLD), and other smaller-scale @@ -3015,9 +3067,15 @@ To understand this document, some terms related to DNS must be understood. - resolver - reverse DNS - root zone + + resolver + + + reverse DNS + + + root zone + @@ -3246,8 +3304,8 @@ &prompt.root; /etc/rc.d/named onestart To ensure the named daemon is - started at boot each time, put the following line into the - /etc/rc.conf: + started at boot each time, put the following line into the + /etc/rc.conf: named_enable="YES" @@ -3666,63 +3724,74 @@ ; Aliases www IN CNAME example.org. - Note that every hostname ending in a . is an - exact hostname, whereas everything without a trailing - . is relative to the origin. For example, - ns1 is translated into - ns1.example.org. + Note that every hostname ending in a . is an + exact hostname, whereas everything without a trailing + . is relative to the origin. For example, + ns1 is translated into + ns1.example.org. - The format of a zone file follows: + The format of a zone file follows: - recordname IN recordtype value + recordname IN recordtype value DNS records - The most commonly used DNS records: + The most commonly used DNS records: SOA - start of zone authority + + start of zone authority + NS - an authoritative name server + + an authoritative name server + A - a host address + + a host address + CNAME - the canonical name for an alias + + the canonical name for an alias + MX - mail exchanger + + mail exchanger + PTR - a domain name pointer (used in reverse DNS) - + + a domain name pointer (used in reverse DNS) + - example.org. IN SOA ns1.example.org. admin.example.org. ( + example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour @@ -3777,62 +3846,61 @@ - IN NS ns1.example.org. + IN NS ns1.example.org. - This is an NS entry. Every name server that is going to reply - authoritatively for the zone must have one of these entries. + This is an NS entry. Every name server that is going to reply + authoritatively for the zone must have one of these entries. - localhost IN A 127.0.0.1 + localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 - The A record indicates machine names. As seen above, - ns1.example.org would resolve - to 192.168.1.2. + The A record indicates machine names. As seen above, + ns1.example.org would resolve + to 192.168.1.2. - IN A 192.168.1.1 + IN A 192.168.1.1 This line assigns IP address 192.168.1.1 to the current origin, in this case example.org. - www IN CNAME @ + www IN CNAME @ - The canonical name record is usually used for giving aliases - to a machine. In the example, www is - aliased to the master machine whose name happens - to be the same as the domain name - example.org - (192.168.1.1). - CNAMEs can never be used together with another kind of record + The canonical name record is usually used for giving aliases + to a machine. In the example, www is + aliased to the master machine whose name happens + to be the same as the domain name + example.org + (192.168.1.1). + CNAMEs can never be used together with another kind of record for the same hostname. MX record - IN MX 10 mail.example.org. + IN MX 10 mail.example.org. - The MX record indicates which mail - servers are responsible for handling incoming mail for the - zone. mail.example.org is the - hostname of a mail server, and 10 is the priority of - that mail server. + The MX record indicates which mail + servers are responsible for handling incoming mail for the + zone. mail.example.org is the + hostname of a mail server, and 10 is the priority of + that mail server. - One can have several mail servers, with priorities of 10, - 20 and so on. A mail server attempting to deliver to example.org would first try the - highest priority MX (the record with the lowest priority + One can have several mail servers, with priorities of 10, + 20 and so on. A mail server attempting to deliver to example.org would first try the + highest priority MX (the record with the lowest priority number), then the second highest, etc, until the mail can be properly delivered. - For in-addr.arpa zone files (reverse DNS), the same format is - used, except with PTR entries instead of - A or CNAME. + For in-addr.arpa zone files (reverse DNS), the same format is + used, except with PTR entries instead of A or CNAME. - $TTL 3600 + $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial @@ -3850,8 +3918,8 @@ 4 IN PTR mx.example.org. 5 IN PTR mail.example.org. - This file gives the proper IP address to hostname - mappings for the above fictitious domain. + This file gives the proper IP address to hostname + mappings for the above fictitious domain. It is worth noting that all names on the right side of a PTR record need to be fully qualified (i.e., end in @@ -3862,60 +3930,60 @@ Caching Name Server - BIND - caching name server + BIND + caching name server A caching name server is a name server whose primary role is to resolve recursive queries. It simply asks queries of its - own, and remembers the answers for later use. + own, and remembers the answers for later use. <acronym - role="Doman Name Security Extensions">DNSSEC</acronym> + role="Doman Name Security Extensions">DNSSEC - BIND - DNS security extensions + BIND + DNS security extensions Domain Name System Security Extensions, or DNSSEC for short, is a - suite of specifications to protect resolving name servers from forged - DNS data, such as spoofed DNS - records. By using digital signatures, a resolver can verify the - integrity of the record. Note that DNSSEC only provides - integrity via digitally signing the Resource Records (RRs). It provides neither - confidentiality nor protection against false end-user assumptions. - This means that it cannot protect against people going to example.net instead of example.com. The only thing - DNSSEC does is authenticate that the data has not - been compromised in transit. The security of DNS is - an important step in securing the Internet in general. For more - in-depth details of how DNSSEC works, the relevant - RFCs are a good place to start. See the list in - . + role="Domain Name Security Extensions">DNSSEC for short, is a + suite of specifications to protect resolving name servers from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity of the record. Note that DNSSEC only provides + integrity via digitally signing the Resource Records (RRs). It provides neither + confidentiality nor protection against false end-user assumptions. + This means that it cannot protect against people going to example.net instead of example.com. The only thing + DNSSEC does is authenticate that the data has not + been compromised in transit. The security of DNS is + an important step in securing the Internet in general. For more + in-depth details of how DNSSEC works, the relevant + RFCs are a good place to start. See the list in + . The following sections will demonstrate how to enable - DNSSEC for an authoritative DNS - server and a recursive (or caching) DNS server - running BIND 9. While all versions of - BIND 9 support DNSSEC, it is - necessary to have at least version 9.6.2 in order to be able to use the - signed root zone when validating DNS queries. This - is because earlier versions lack the required algorithms to enable - validation using the root zone key. It is strongly recommended to use - the latest version of BIND 9.7 or later to take - advantage of automatic key updating for the root key, as well as other - features to automatically keep zones signed and signatures up to date. - Where configurations differ between 9.6.2 and 9.7 and later, - differences will be pointed out. + DNSSEC for an authoritative DNS + server and a recursive (or caching) DNS server + running BIND 9. While all versions of + BIND 9 support DNSSEC, it is + necessary to have at least version 9.6.2 in order to be able to use the + signed root zone when validating DNS queries. This + is because earlier versions lack the required algorithms to enable + validation using the root zone key. It is strongly recommended to use + the latest version of BIND 9.7 or later to take + advantage of automatic key updating for the root key, as well as other + features to automatically keep zones signed and signatures up to date. + Where configurations differ between 9.6.2 and 9.7 and later, + differences will be pointed out. - Recursive <acronym>DNS</acronym> server configuration + Recursive <acronym>DNS</acronym> server configuration Enabling DNSSEC validation of queries performed by a recursive DNS server requires a few @@ -3959,8 +4027,7 @@ role="Key Signing Key">KSK). The second key, with value 256, is a subordinate key, commonly called a Zone Signing Key (ZSK). More on the - different key types later in the . + different key types later in . Now the key must be verified and formatted so that BIND can use it. To verify the key, generate a @@ -4202,8 +4269,8 @@ Security Although BIND is the most common implementation of DNS, - there is always the issue of security. Possible and - exploitable security holes are sometimes found. + there is always the issue of security. Possible and + exploitable security holes are sometimes found. While &os; automatically drops @@ -4228,8 +4295,8 @@ Further Reading BIND/named manual pages: - &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8; - &man.dnssec-signzone.8; &man.dnssec-keygen.8; + &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8; + &man.dnssec-signzone.8; &man.dnssec-keygen.8; @@ -4243,8 +4310,8 @@ - O'Reilly - DNS and BIND 5th Edition + O'Reilly + DNS and BIND 5th Edition @@ -4290,9 +4357,9 @@ - RFC 5011 - - Automated Updates of DNS Security (DNSSEC - Trust Anchors + RFC 5011 + - Automated Updates of DNS Security (DNSSEC + Trust Anchors @@ -4310,40 +4377,48 @@ Apache HTTP Server - web servers - setting up - Apache + + web servers + setting up + + + Apache + Overview &os; is used to run some of the busiest web sites in the - world. The majority of web servers on the Internet are using - the Apache HTTP Server. - Apache software packages should be - included on your FreeBSD installation media. If you did not - install Apache when you first - installed FreeBSD, then you can install it from the www/apache13 or www/apache22 port. + world. The majority of web servers on the Internet are using + the Apache HTTP Server. + Apache software packages should be + included on your FreeBSD installation media. If you did not + install Apache when you first + installed FreeBSD, then you can install it from the www/apache13 or www/apache22 port. Once Apache has been installed - successfully, it must be configured. + successfully, it must be configured. - This section covers version 1.3.X of the - Apache HTTP Server as that is the - most widely used version for &os;. Apache 2.X introduces many - new technologies but they are not discussed here. For more - information about Apache 2.X, please see . + + This section covers version 1.3.X of the + Apache HTTP Server as that is the + most widely used version for &os;. Apache 2.X introduces many + new technologies but they are not discussed here. For more + information about Apache 2.X, please see . + Configuration - Apache - configuration file + + Apache + configuration file + The main Apache HTTP Server configuration file is installed as @@ -4421,17 +4496,19 @@ Running <application>Apache</application> - Apache - starting or stopping + + Apache + starting or stopping + Apache does not run from the - inetd super server as many other - network servers do. It is configured to run standalone for - better performance for incoming HTTP requests from client web - browsers. A shell script wrapper is included to make - starting, stopping, and restarting the server as simple as - possible. To start up Apache for - the first time, just run: + inetd super server as many other + network servers do. It is configured to run standalone for + better performance for incoming HTTP requests from client web + browsers. A shell script wrapper is included to make + starting, stopping, and restarting the server as simple as + possible. To start up Apache for + the first time, just run: &prompt.root; /usr/local/sbin/apachectl start @@ -4440,7 +4517,7 @@ &prompt.root; /usr/local/sbin/apachectl stop After making changes to the configuration file for any - reason, you will need to restart the server: + reason, you will need to restart the server: &prompt.root; /usr/local/sbin/apachectl restart @@ -4453,8 +4530,8 @@ &man.apachectl.8; manual page. To launch Apache at system - startup, add the following line to - /etc/rc.conf: + startup, add the following line to + /etc/rc.conf: apache_enable="YES" @@ -4471,10 +4548,10 @@ apache_flags="" Now that the web server is running, you can view your web - site by pointing a web browser to - http://localhost/. The default web page - that is displayed is - /usr/local/www/data/index.html. + site by pointing a web browser to + http://localhost/. The default web page + that is displayed is + /usr/local/www/data/index.html. @@ -4488,16 +4565,16 @@ different domains to share the same IP address. To setup Apache to use - Name-based Virtual Hosting add an entry like the following to - your httpd.conf: + Name-based Virtual Hosting add an entry like the following to + your httpd.conf: NameVirtualHost * - If your webserver was named www.domain.tld and - you wanted to setup a virtual domain for - www.someotherdomain.tld then you would add - the following entries to - httpd.conf: + If your webserver was named www.domain.tld + and you wanted to setup a virtual domain for + www.someotherdomain.tld then you would add + the following entries to + httpd.conf: <VirtualHost *> ServerName www.domain.tld @@ -4510,41 +4587,50 @@ </VirtualHost> Replace the addresses with the addresses you want to use - and the path to the documents with what you are using. + and the path to the documents with what you are using. For more information about setting up virtual hosts, - please consult the official Apache - documentation at: . + please consult the official Apache + documentation at: . Apache Modules - Apache - modules + + Apache + modules + - There are many different Apache modules available to add - functionality to the basic server. The FreeBSD Ports - Collection provides an easy way to install - Apache together with some of the - more popular add-on modules. + There are many different Apache + modules available to add + functionality to the basic server. The FreeBSD Ports + Collection provides an easy way to install + Apache together with some of the + more popular add-on modules. - mod_ssl + mod_ssl - web servers - secure - SSL - cryptography + + web servers + secure + + + SSL + + + cryptography + - The mod_ssl module uses the OpenSSL library to provide - strong cryptography via the Secure Sockets Layer (SSL v2/v3) - and Transport Layer Security (TLS v1) protocols. This - module provides everything necessary to request a signed - certificate from a trusted certificate signing authority so - that you can run a secure web server on &os;. + The mod_ssl module uses the OpenSSL library to provide + strong cryptography via the Secure Sockets Layer (SSL v2/v3) + and Transport Layer Security (TLS v1) protocols. This + module provides everything necessary to request a signed + certificate from a trusted certificate signing authority so + that you can run a secure web server on &os;. If you have not yet installed Apache, then a version of Apache @@ -4560,61 +4646,67 @@ - Language Bindings + Language Bindings - There are Apache modules for most major scripting - languages. These modules typically make it possible to - write Apache modules entirely in - a scripting language. They are also often used as a - persistent interpreter embedded into the server that avoids - the overhead of starting an external interpreter and the - startup-time penalty for dynamic websites, as described in - the next section. + There are Apache modules for most major scripting + languages. These modules typically make it possible to + write Apache modules entirely in + a scripting language. They are also often used as a + persistent interpreter embedded into the server that avoids + the overhead of starting an external interpreter and the + startup-time penalty for dynamic websites, as described in + the next section. Dynamic Websites - web servers - dynamic + + web servers + dynamic + In the last decade, more businesses have turned to the - Internet in order to enhance their revenue and increase - exposure. This has also increased the need for interactive - web content. While some companies, such as µsoft;, - have introduced solutions into their proprietary products, - the open source community answered the call. Modern options - for dynamic web content include Django, Ruby on Rails, - mod_perl, and - mod_php. + Internet in order to enhance their revenue and increase + exposure. This has also increased the need for interactive + web content. While some companies, such as µsoft;, + have introduced solutions into their proprietary products, + the open source community answered the call. Modern options + for dynamic web content include Django, Ruby on Rails, + mod_perl, and + mod_php. - Django + Django - Python - Django + + Python + + + Django + - Django is a BSD licensed framework designed to allow - developers to write high performance, elegant web - applications quickly. It provides an object-relational - mapper so that data types are developed as Python objects, - and a rich dynamic database-access API is provided for those - objects without the developer ever having to write SQL. It - also provides an extensible template system so that the - logic of the application is separated from the HTML - presentation. + Django is a BSD licensed framework designed to allow + developers to write high performance, elegant web + applications quickly. It provides an object-relational + mapper so that data types are developed as Python objects, + and a rich dynamic database-access API is provided for those + objects without the developer ever having to write SQL. It + also provides an extensible template system so that the + logic of the application is separated from the HTML + presentation. - Django depends on mod_python, - Apache, and an SQL database - engine of your choice. The FreeBSD Port will install all of - these pre-requisites for you with the appropriate flags. + Django depends on mod_python, + Apache, and an SQL database + engine of your choice. The FreeBSD Port will install all of + these pre-requisites for you with the appropriate flags. Installing Django with Apache2, mod_python3, and PostgreSQL &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL - + Once Django and these pre-requisites are installed, you will need to create a Django project directory and then @@ -4624,12 +4716,12 @@ Apache Configuration for Django/mod_python - You will need to add a line to the apache - httpd.conf file to configure Apache - to pass requests for certain URLs to your web - application: + You will need to add a line to the apache + httpd.conf file to configure Apache + to pass requests for certain URLs to your web + application: - <Location "/"> + <Location "/"> SetHandler python-program PythonPath "['/dir/to/your/django/packages/'] + sys.path" PythonHandler django.core.handlers.modpython @@ -4641,9 +4733,11 @@ - Ruby on Rails + Ruby on Rails - Ruby on Rails + + Ruby on Rails + Ruby on Rails is another open source web framework that provides a full development stack and is optimized to make @@ -4651,18 +4745,18 @@ powerful applications quickly. It can be installed easily from the ports system. - &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean + &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean - mod_perl + mod_perl - mod_perl - Perl - + mod_perl + Perl + - The Apache/Perl integration project brings together the + The Apache/Perl integration project brings together the full power of the Perl programming language and the Apache HTTP Server. With the mod_perl module it is possible to write Apache modules entirely in Perl. In addition, the @@ -4670,22 +4764,22 @@ overhead of starting an external interpreter and the penalty of Perl start-up time. - mod_perl is available a few - different ways. To use mod_perl - remember that mod_perl 1.0 only - works with Apache 1.3 and - mod_perl 2.0 only works with - Apache 2.X. - mod_perl 1.0 is available in - www/mod_perl and a - statically compiled version is available in - www/apache13-modperl. - mod_perl 2.0 is available in - www/mod_perl2. - + mod_perl is available a few + different ways. To use mod_perl + remember that mod_perl 1.0 only + works with Apache 1.3 and + mod_perl 2.0 only works with + Apache 2.X. + mod_perl 1.0 is available in + www/mod_perl and a + statically compiled version is available in + www/apache13-modperl. + mod_perl 2.0 is available in + www/mod_perl2. + - - + + Tom @@ -4693,21 +4787,21 @@ Written by - - mod_php + + mod_php - mod_php - PHP - + mod_php + PHP + PHP, also known as PHP: - Hypertext Preprocessor is a general-purpose scripting - language that is especially suited for Web development. - Capable of being embedded into HTML its - syntax draws upon C, &java;, and Perl with the intention of - allowing web developers to write dynamically generated - webpages quickly. + Hypertext Preprocessor is a general-purpose scripting + language that is especially suited for Web development. + Capable of being embedded into HTML its + syntax draws upon C, &java;, and Perl with the intention of + allowing web developers to write dynamically generated + webpages quickly. To gain support for PHP5 for the Apache web server, begin by @@ -4745,13 +4839,13 @@ This will install and configure the modules required - to support dynamic PHP applications. Check - to ensure the following sections have been added to + to support dynamic PHP applications. Check + to ensure the following sections have been added to /usr/local/etc/apache/httpd.conf: LoadModule php5_module libexec/apache/libphp5.so - AddModule mod_php5.c + AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> @@ -4760,10 +4854,10 @@ AddType application/x-httpd-php-source .phps </IfModule> - Once completed, a simple call to the - apachectl command for a graceful - restart is needed to load the PHP - module: + Once completed, a simple call to the + apachectl command for a graceful + restart is needed to load the PHP + module: &prompt.root; apachectl graceful @@ -4772,27 +4866,24 @@ the selected OPTIONS are saved automatically by the &os; Ports framework. - The PHP support in &os; is extremely - modular so the base install is very limited. It is very easy - to add support using the - lang/php5-extensions port. - This port provides a menu driven interface to - PHP extension installation. - Alternatively, individual extensions can be installed using - the appropriate port. + The PHP support in &os; is extremely + modular so the base install is very limited. It is very easy + to add support using the + lang/php5-extensions port. + This port provides a menu driven interface to + PHP extension installation. + Alternatively, individual extensions can be installed using + the appropriate port. For instance, to add support for the MySQL database server to PHP5, simply install the port databases/php5-mysql. - - After installing an extension, the - Apache server must be reloaded to - pick up the new configuration changes: + + After installing an extension, the + Apache server must be reloaded to + pick up the new configuration changes: &prompt.root; apachectl graceful @@ -4811,7 +4902,9 @@ File Transfer Protocol (FTP) - FTP servers + + FTP servers + Overview @@ -4874,16 +4967,16 @@ for anonymous users. Once the FTP server has been configured properly, it must - be enabled in /etc/inetd.conf. All that - is required here is to remove the comment symbol - # from in front of the existing - ftpd line : + be enabled in /etc/inetd.conf. All that + is required here is to remove the comment symbol + # from in front of the existing + ftpd line : ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l As explained in , - the inetd configuration must be reloaded - after this configuration file is changed. Please refer to + the inetd configuration must be reloaded + after this configuration file is changed. Please refer to for details on enabling inetd on your system. @@ -4909,16 +5002,20 @@ Maintaining - syslog - log files - FTP + + syslog + + + log files + FTP + The ftpd daemon uses - &man.syslog.3; to log messages. By default, the system log - daemon will put messages related to FTP in the - /var/log/xferlog file. The location of - the FTP log can be modified by changing the following line in - /etc/syslog.conf: + &man.syslog.3; to log messages. By default, the system log + daemon will put messages related to FTP in the + /var/log/xferlog file. The location of + the FTP log can be modified by changing the following line in + /etc/syslog.conf: ftp.info /var/log/xferlog @@ -4928,13 +5025,13 @@ Be aware of the potential problems involved with running - an anonymous FTP server. In particular, you should think - twice about allowing anonymous users to upload files. You may - find that your FTP site becomes a forum for the trade of - unlicensed commercial software or worse. If you do need to - allow anonymous FTP uploads, then you should set up the - permissions so that these files can not be read by other - anonymous users until they have been reviewed. + an anonymous FTP server. In particular, you should think + twice about allowing anonymous users to upload files. You may + find that your FTP site becomes a forum for the trade of + unlicensed commercial software or worse. If you do need to + allow anonymous FTP uploads, then you should set up the + permissions so that these files can not be read by other + anonymous users until they have been reviewed. @@ -4951,8 +5048,12 @@ File and Print Services for µsoft.windows; clients (Samba) - Samba server - Microsoft Windows + + Samba server + + + Microsoft Windows + file server Windows clients @@ -4966,16 +5067,16 @@ Overview Samba is a popular open source - software package that provides file and print services for - µsoft.windows; clients. Such clients can connect to and - use FreeBSD filespace as if it was a local disk drive, or - FreeBSD printers as if they were local printers. + software package that provides file and print services for + µsoft.windows; clients. Such clients can connect to and + use FreeBSD filespace as if it was a local disk drive, or + FreeBSD printers as if they were local printers. Samba software packages should - be included on your FreeBSD installation media. If you did - not install Samba when you first - installed FreeBSD, then you can install it from the net/samba34 port or package. + be included on your FreeBSD installation media. If you did + not install Samba when you first + installed FreeBSD, then you can install it from the net/samba34 port or package. @@ -4985,21 +5086,21 @@ Configuration A default Samba configuration - file is installed as - /usr/local/share/examples/samba34/smb.conf.default. This - file must be copied to - /usr/local/etc/smb.conf and customized - before Samba can be used. + file is installed as + /usr/local/share/examples/samba34/smb.conf.default. + This file must be copied to + /usr/local/etc/smb.conf and customized + before Samba can be used. The smb.conf file contains runtime - configuration information for - Samba, such as definitions of the - printers and file system shares that you would - like to share with &windows; clients. The - Samba package includes a web based - tool called swat which provides a - simple way of configuring the smb.conf - file. + configuration information for + Samba, such as definitions of the + printers and file system shares that you would + like to share with &windows; clients. The + Samba package includes a web based + tool called swat which provides a + simple way of configuring the smb.conf + file. Using the Samba Web Administration Tool (SWAT) @@ -5011,9 +5112,9 @@ used to configure Samba: swat stream tcp nowait/400 root /usr/local/sbin/swat swat - As explained in , - the inetd configuration must be reloaded after this configuration - file is changed. + As explained in , + the inetd configuration must be reloaded after this configuration + file is changed. Once swat has been enabled in inetd.conf, you can use a browser to @@ -5052,7 +5153,9 @@ netbios name - NetBIOS + + NetBIOS + This sets the NetBIOS name by which a Samba server @@ -5089,35 +5192,41 @@ The two most common options here are - security = share and security - = user. If your clients use usernames that - are the same as their usernames on your &os; machine - then you will want to use user level security. This - is the default security policy and it requires clients - to first log on before they can access shared - resources. + security = share and security + = user. If your clients use usernames that + are the same as their usernames on your &os; machine + then you will want to use user level security. This + is the default security policy and it requires clients + to first log on before they can access shared + resources. In share level security, client do not need to log - onto the server with a valid username and password - before attempting to connect to a shared resource. - This was the default security model for older versions - of Samba. + onto the server with a valid username and password + before attempting to connect to a shared resource. + This was the default security model for older versions + of Samba. passdb backend - NIS+ - LDAP - SQL database + + NIS+ + + + LDAP + + + SQL database + Samba has several - different backend authentication models. You can - authenticate clients with LDAP, NIS+, a SQL database, - or a modified password file. The default - authentication method is smbpasswd, + different backend authentication models. You can + authenticate clients with LDAP, NIS+, a SQL database, + or a modified password file. The default + authentication method is smbpasswd, and that is all that will be covered here. @@ -5183,23 +5292,23 @@ information about using rc scripts. Samba actually consists of - three separate daemons. You should see that both the - nmbd and smbd daemons - are started by the samba script. If - you enabled winbind name resolution services in - smb.conf, then you will also see that - the winbindd daemon is started. + three separate daemons. You should see that both the + nmbd and smbd daemons + are started by the samba script. If + you enabled winbind name resolution services in + smb.conf, then you will also see that + the winbindd daemon is started. You can stop Samba at any time - by typing : + by typing : &prompt.root; /usr/local/etc/rc.d/samba stop Samba is a complex software - suite with functionality that allows broad integration with - µsoft.windows; networks. For more information about - functionality beyond the basic installation described here, - please see . + suite with functionality that allows broad integration with + µsoft.windows; networks. For more information about + functionality beyond the basic installation described here, + please see . @@ -5216,7 +5325,9 @@ Clock Synchronization with NTP - NTP + + NTP + Overview @@ -5283,7 +5394,9 @@ Basic Configuration - ntpdate + + ntpdate + If you only wish to synchronize your clock when the machine boots up, you can use &man.ntpdate.8;. This may be @@ -5363,7 +5476,7 @@ server, add the following line to /etc/ntp.conf: - restrict default ignore + restrict default ignore This will also prevent access from your server to @@ -5373,12 +5486,12 @@ &man.ntp.conf.5; manual for more information. - If you only want to allow machines within your own + If you only want to allow machines within your own network to synchronize their clocks with your server, but ensure they are not allowed to configure the server or used as peers to synchronize against, add - restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap + restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap instead, where 192.168.1.0 is an IP address on your network and - - Tom - Rhodes - Contributed by - + + Tom + Rhodes + Contributed by + @@ -5535,7 +5648,7 @@ Once added, all facility messages will - be logged to the file specified previously, + be logged to the file specified previously, /var/log/logclient.log. The server machine must also have the following listing --- network-servers.chapter.sgml-whitespace.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Thu May 26 10:10:09 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A024106566C for ; Thu, 26 May 2011 10:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 17DC88FC15 for ; Thu, 26 May 2011 10:10:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QAA8vv055368 for ; Thu, 26 May 2011 10:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QAA8TB055367; Thu, 26 May 2011 10:10:08 GMT (envelope-from gnats) Date: Thu, 26 May 2011 10:10:08 GMT Message-Id: <201105261010.p4QAA8TB055367@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: docs/157091: [handbook] FreeBSD Handbook needs to be updated to reflect gpart rather than obsolete gpt X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 10:10:09 -0000 The following reply was made to PR docs/157091; it has been noted by GNATS. From: Niclas Zeising To: bug-followup@FreeBSD.org, rsimmons0@gmail.com Cc: Subject: Re: docs/157091: [handbook] FreeBSD Handbook needs to be updated to reflect gpart rather than obsolete gpt Date: Thu, 26 May 2011 12:00:31 +0200 This is a multi-part message in MIME format. --------------070207050607090205050303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi! Here is a patch that does just that. Regards! -- Niclas --------------070207050607090205050303 Content-Type: text/plain; name="disks.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="disks.chapter.sgml.diff" Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/disks/chapter.sgml,v retrieving revision 1.307 diff -u -d -r1.307 chapter.sgml --- chapter.sgml 21 Mar 2011 14:04:13 -0000 1.307 +++ chapter.sgml 26 May 2011 09:24:09 -0000 @@ -200,8 +200,9 @@ 2^32-1 and a length of no more than 2^32-1, limiting partitions to 2TB and disks to 4TB in most cases. The &man.sunlabel.8; format is limited to 2^32-1 sectors per partition and 8 partitions for - a total of 16TB. For larger disks, &man.gpt.8; partitions may be - used. + a total of 16TB. For larger disks, &man.gpart.8; may be used to create + GPT partitions. GPT has the added + benefit of not being limited to 4 slices. Using &man.sysinstall.8; --------------070207050607090205050303-- From owner-freebsd-doc@FreeBSD.ORG Thu May 26 10:24:52 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 829831065672; Thu, 26 May 2011 10:24:52 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 592418FC08; Thu, 26 May 2011 10:24:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QAOqoj073542; Thu, 26 May 2011 10:24:52 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QAOq9b073538; Thu, 26 May 2011 10:24:52 GMT (envelope-from bcr) Date: Thu, 26 May 2011 10:24:52 GMT Message-Id: <201105261024.p4QAOq9b073538@freefall.freebsd.org> To: rsimmons0@gmail.com, bcr@FreeBSD.org, freebsd-doc@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/157091: [handbook] FreeBSD Handbook needs to be updated to reflect gpart rather than obsolete gpt X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 10:24:52 -0000 Synopsis: [handbook] FreeBSD Handbook needs to be updated to reflect gpart rather than obsolete gpt State-Changed-From-To: open->feedback State-Changed-By: bcr State-Changed-When: Thu May 26 10:23:12 UTC 2011 State-Changed-Why: Set to feedback until we get a response from the submitter about whether the submitted patch fits what he intended with the change. http://www.freebsd.org/cgi/query-pr.cgi?pr=157091 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 14:03:54 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 656B8106566C; Thu, 26 May 2011 14:03:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3BFF78FC12; Thu, 26 May 2011 14:03:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QE3sPC082759; Thu, 26 May 2011 14:03:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QE3roX082754; Thu, 26 May 2011 14:03:53 GMT (envelope-from linimon) Date: Thu, 26 May 2011 14:03:53 GMT Message-Id: <201105261403.p4QE3roX082754@freefall.freebsd.org> To: utisoft@gmail.com, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-doc@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: docs/157321: Re: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:03:54 -0000 Old Synopsis: Re: Fwd: docs/156853: [patch] Update docs: jail(8) security issues New Synopsis: Re: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Thu May 26 14:03:09 UTC 2011 State-Changed-Why: Misfiled followup to docs/156853; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-doc Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 26 14:03:09 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=157321 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 14:04:37 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F6E0106564A; Thu, 26 May 2011 14:04:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA9118FC1C; Thu, 26 May 2011 14:04:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QE4aH7082893; Thu, 26 May 2011 14:04:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QE4aOi082889; Thu, 26 May 2011 14:04:36 GMT (envelope-from linimon) Date: Thu, 26 May 2011 14:04:36 GMT Message-Id: <201105261404.p4QE4aOi082889@freefall.freebsd.org> To: cperciva@freebsd.org, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-doc@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: docs/157327: Re: Fwd: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:04:37 -0000 Old Synopsis: Re: Fwd: docs/156853: [patch] Update docs: jail(8) security issues New Synopsis: Re: Fwd: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Thu May 26 14:03:09 UTC 2011 State-Changed-Why: Misfiled followup to docs/156853; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-doc Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 26 14:03:09 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=157327 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 14:05:46 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D82106566C; Thu, 26 May 2011 14:05:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E4E1D8FC18; Thu, 26 May 2011 14:05:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QE5jLg083105; Thu, 26 May 2011 14:05:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QE5j17083101; Thu, 26 May 2011 14:05:45 GMT (envelope-from linimon) Date: Thu, 26 May 2011 14:05:45 GMT Message-Id: <201105261405.p4QE5j17083101@freefall.freebsd.org> To: kostikbel@gmail.com, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-doc@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: docs/157328: Re: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:05:46 -0000 Old Synopsis: Re: Fwd: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root New Synopsis: Re: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Thu May 26 14:03:09 UTC 2011 State-Changed-Why: Misfiled followup to docs/156853; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-doc Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 26 14:03:09 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=157328 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 14:06:35 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6217106566C; Thu, 26 May 2011 14:06:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BCF6D8FC12; Thu, 26 May 2011 14:06:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QE6ZuH083163; Thu, 26 May 2011 14:06:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QE6Zcr083159; Thu, 26 May 2011 14:06:35 GMT (envelope-from linimon) Date: Thu, 26 May 2011 14:06:35 GMT Message-Id: <201105261406.p4QE6Zcr083159@freefall.freebsd.org> To: utisoft@gmail.com, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-doc@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: docs/157335: Re: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:06:36 -0000 Old Synopsis: Re: Fwd: docs/156853: [patch] Update docs: jail(8) security issues New Synopsis: Re: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Thu May 26 14:03:09 UTC 2011 State-Changed-Why: Misfiled followup to docs/156853; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-doc Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 26 14:03:09 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=157335 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 14:07:41 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 904BF1065673; Thu, 26 May 2011 14:07:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 67CEC8FC12; Thu, 26 May 2011 14:07:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QE7fSh083211; Thu, 26 May 2011 14:07:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QE7fLa083207; Thu, 26 May 2011 14:07:41 GMT (envelope-from linimon) Date: Thu, 26 May 2011 14:07:41 GMT Message-Id: <201105261407.p4QE7fLa083207@freefall.freebsd.org> To: linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-doc@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: docs/157345: Re: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:07:41 -0000 Old Synopsis: Re: Fwd: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root New Synopsis: Re: docs/156853: [patch] Update docs: jail(8) security issues with world-readable jail root State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Thu May 26 14:03:09 UTC 2011 State-Changed-Why: Misfiled followup to docs/156853; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-doc Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 26 14:03:09 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=157345 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 14:30:16 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21EF110656A8 for ; Thu, 26 May 2011 14:30:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EC1508FC25 for ; Thu, 26 May 2011 14:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QEUFGR001812 for ; Thu, 26 May 2011 14:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QEUFoR001807; Thu, 26 May 2011 14:30:15 GMT (envelope-from gnats) Date: Thu, 26 May 2011 14:30:15 GMT Message-Id: <201105261430.p4QEUFoR001807@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Robert Simmons Cc: Subject: Re: docs/157091: [handbook] FreeBSD Handbook needs to be updated to reflect gpart rather than obsolete gpt X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Simmons List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:30:16 -0000 The following reply was made to PR docs/157091; it has been noted by GNATS. From: Robert Simmons To: bug-followup@freebsd.org, rsimmons0@gmail.com Cc: Subject: Re: docs/157091: [handbook] FreeBSD Handbook needs to be updated to reflect gpart rather than obsolete gpt Date: Thu, 26 May 2011 10:01:04 -0400 That patch looks good. Thanks! From owner-freebsd-doc@FreeBSD.ORG Thu May 26 17:13:36 2011 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15B05106566C for ; Thu, 26 May 2011 17:13:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 604968FC08 for ; Thu, 26 May 2011 17:13:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23599; Thu, 26 May 2011 19:54:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4DDE85BC.40407@FreeBSD.org> Date: Thu, 26 May 2011 19:54:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110504 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Martin Simmons References: <201105261620.p4QGKC1j002084@freefall.freebsd.org> <4DDE8191.6080503@FreeBSD.org> In-Reply-To: <4DDE8191.6080503@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-doc@FreeBSD.org Subject: Re: kern/153804: boot from zfs kernel.old recovery undocumented/impossible X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 17:13:36 -0000 on 26/05/2011 19:36 Andriy Gapon said the following: > on 26/05/2011 19:20 Martin Simmons said the following: >> I think it should be >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-trouble.html >> >> where it currently tells you to do unload and boot with arguments that don't >> work for zfs... > > Oh, yes, thanks for the pointer - we should fix that. I would change it like this: Index: kernelconfig/chapter.sgml =================================================================== RCS file: /usr/devel/fcvs/doc/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml,v retrieving revision 1.196 diff -u -r1.196 chapter.sgml --- kernelconfig/chapter.sgml 8 Mar 2011 17:46:12 -0000 1.196 +++ kernelconfig/chapter.sgml 26 May 2011 16:50:19 -0000 @@ -1494,10 +1494,8 @@ the &os; boot loader. You can access this when the system boot menu appears. Select the Escape to a loader prompt option, number six. At the prompt, type - unload kernel - and then type - boot /boot/kernel.old/kernel, - or the filename of any other kernel that will boot properly. + boot kernel.old, + or the name of any other kernel that will boot properly. When reconfiguring a kernel, it is always a good idea to keep a kernel that is known to work on hand. -- Andriy Gapon From owner-freebsd-doc@FreeBSD.ORG Thu May 26 17:45:25 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C12B106564A; Thu, 26 May 2011 17:45:25 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 465108FC14; Thu, 26 May 2011 17:45:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QHjPPf084841; Thu, 26 May 2011 17:45:25 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QHjP0B084837; Thu, 26 May 2011 17:45:25 GMT (envelope-from bcr) Date: Thu, 26 May 2011 17:45:25 GMT Message-Id: <201105261745.p4QHjP0B084837@freefall.freebsd.org> To: bcr@FreeBSD.org, freebsd-doc@FreeBSD.org, bcr@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/157091: [handbook] FreeBSD Handbook needs to be updated to reflect gpart rather than obsolete gpt X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 17:45:25 -0000 Synopsis: [handbook] FreeBSD Handbook needs to be updated to reflect gpart rather than obsolete gpt Responsible-Changed-From-To: freebsd-doc->bcr Responsible-Changed-By: bcr Responsible-Changed-When: Thu May 26 17:44:47 UTC 2011 Responsible-Changed-Why: I will finish the work on this. http://www.freebsd.org/cgi/query-pr.cgi?pr=157091 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 19:17:56 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DE521065673; Thu, 26 May 2011 19:17:56 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 37A368FC16; Thu, 26 May 2011 19:17:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QJHu0s066449; Thu, 26 May 2011 19:17:56 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QJHuvD066445; Thu, 26 May 2011 19:17:56 GMT (envelope-from eadler) Date: Thu, 26 May 2011 19:17:56 GMT Message-Id: <201105261917.p4QJHuvD066445@freefall.freebsd.org> To: lists@eitanadler.com, eadler@FreeBSD.org, freebsd-doc@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: docs/155982: [handbook] remove reference to floppy installations X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 19:17:56 -0000 Synopsis: [handbook] remove reference to floppy installations State-Changed-From-To: suspended->open State-Changed-By: eadler State-Changed-When: Thu May 26 19:17:55 UTC 2011 State-Changed-Why: Open this PR because I'm going to be submitting a patch soon. http://www.freebsd.org/cgi/query-pr.cgi?pr=155982 From owner-freebsd-doc@FreeBSD.ORG Thu May 26 20:10:05 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D45106564A for ; Thu, 26 May 2011 20:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DC7C78FC12 for ; Thu, 26 May 2011 20:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QKA4SZ012307 for ; Thu, 26 May 2011 20:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QKA420012306; Thu, 26 May 2011 20:10:04 GMT (envelope-from gnats) Resent-Date: Thu, 26 May 2011 20:10:04 GMT Resent-Message-Id: <201105262010.p4QKA420012306@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Niclas Zeising Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6DDC106564A; Thu, 26 May 2011 20:09:24 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 23F5D8FC13; Thu, 26 May 2011 20:09:23 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E465E40020; Thu, 26 May 2011 22:09:22 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id D9A5C40021; Thu, 26 May 2011 22:09:22 +0200 (CEST) Received: from mx.daemonic.se (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id E757A40020; Thu, 26 May 2011 22:09:21 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id A7410119C04; Thu, 26 May 2011 22:09:21 +0200 (CEST) Received: from vincent.daemonic.se (login.daemonic.se [IPv6:2001:470:dca9:0:1::10]) by mail.daemonic.se (Postfix) with ESMTPS id 7DD7B12B2DA; Thu, 26 May 2011 22:09:21 +0200 (CEST) Received: (from zeising@localhost) by vincent.daemonic.se (8.14.4/8.14.4/Submit) id p4QK9LUg080794; Thu, 26 May 2011 22:09:21 +0200 (CEST) (envelope-from zeising) Message-Id: <201105262009.p4QK9LUg080794@vincent.daemonic.se> Date: Thu, 26 May 2011 22:09:21 +0200 (CEST) From: Niclas Zeising To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: mckusick@FreeBSD.org Subject: docs/157354: [PATCH] update newfs(8) man page after changed defaults X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 20:10:05 -0000 >Number: 157354 >Category: docs >Synopsis: [PATCH] update newfs(8) man page after changed defaults >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Thu May 26 20:10:04 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Niclas Zeising >Release: FreeBSD 8.2-RELEASE amd64 >Organization: >Environment: System: FreeBSD vincent.daemonic.se 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Wed Apr 20 17:22:47 CEST 2011 root@vincent.daemonic.se:/usr/obj/usr/src/sys/VINCENT amd64 >Description: The default sizes for blocksize and fragment size when using newfs was recently changed. Documentation needs to be updated to reflect this. >How-To-Repeat: >Fix: Attached patch updates the manual page to mention the new defaults. --- sbin.newfs.8.diff begins here --- Index: newfs.8 =================================================================== --- newfs.8 (revision 222288) +++ newfs.8 (working copy) @@ -28,7 +28,7 @@ .\" @(#)newfs.8 8.6 (Berkeley) 5/3/95 .\" $FreeBSD$ .\" -.Dd February 22, 2011 +.Dd May 26, 2011 .Dt NEWFS 8 .Os .Sh NAME @@ -112,7 +112,7 @@ The block size of the file system, in bytes. It must be a power of 2. The -default size is 16384 bytes, and the smallest allowable size is 4096 bytes. +default size is 32768 bytes, and the smallest allowable size is 4096 bytes. The optimal block:fragment ratio is 8:1. Other ratios are possible, but are not recommended, and may produce poor results. @@ -143,7 +143,9 @@ .Ar blocksize Ns /8 and .Ar blocksize . -The default is 2048 bytes. +The default is 4096 bytes. +Having a lower size will result in poor performance with modern disks utilizing +4096 byte sectors. .It Fl g Ar avgfilesize The expected average file size for the file system. .It Fl h Ar avgfpdir @@ -279,11 +281,8 @@ .Pa ad3s1a . The .Nm -utility will use a block size of 16384 bytes, a fragment size of 2048 bytes +utility will use a block size of 32768 bytes, a fragment size of 4096 bytes and the largest possible number of blocks per cylinders group. -These values tend to produce better performance for most applications -than the historical defaults -(8192 byte block size and 1024 byte fragment size). This large fragment size may lead to much wasted space on file systems that contain many small files. .Sh SEE ALSO --- sbin.newfs.8.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Thu May 26 20:20:14 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736BE106564A for ; Thu, 26 May 2011 20:20:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 64AB48FC14 for ; Thu, 26 May 2011 20:20:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4QKKEec022331 for ; Thu, 26 May 2011 20:20:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QKKEbm022330; Thu, 26 May 2011 20:20:14 GMT (envelope-from gnats) Date: Thu, 26 May 2011 20:20:14 GMT Message-Id: <201105262020.p4QKKEbm022330@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Eitan Adler Cc: Subject: Re: docs/155982: [handbook] remove reference to floppy installations X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eitan Adler List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 20:20:14 -0000 The following reply was made to PR docs/155982; it has been noted by GNATS. From: Eitan Adler To: bug-followup@freebsd.org Cc: Subject: Re: docs/155982: [handbook] remove reference to floppy installations Date: Thu, 26 May 2011 15:42:40 -0400 --20cf3071cc72ef0d3e04a43307d3 Content-Type: text/plain; charset=UTF-8 Attached is an updated patch that removes some outdated references to floppies. It also makes the floppy installation section specific to PC98. -- Eitan Adler --20cf3071cc72ef0d3e04a43307d3 Content-Type: application/octet-stream; name="make-floppy-slightly-more-sane.patch" Content-Disposition: attachment; filename="make-floppy-slightly-more-sane.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_go640gdd0 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9kb2MvZW5fVVMuSVNPODg1OS0xL2Jvb2tz L2hhbmRib29rL2N1dHRpbmctZWRnZS9jaGFwdGVyLnNnbWwsdgpyZXRyaWV2aW5nIHJldmlzaW9u IDEuMjU0CiAJd2hlbiB5b3UgbWFrZSBtaXN0YWtlcywgb3Igd2hlbiBtaXN0YWtlcyBtYWRlIGJ5 IG90aGVycyBpbiB0aGUKIAlzb3VyY2UgdHJlZSByZW5kZXIgeW91ciBzeXN0ZW0gdW5ib290YWJs ZS48L3BhcmE+CiAKLSAgICAgIDxwYXJhPk1ha2Ugc3VyZSB5b3UgaGF2ZSB0YWtlbiBhIGJhY2t1 cC4gIEFuZCBoYXZlIGEgZml4aXQgZmxvcHB5IG9yCi0JYm9vdGFibGUgQ0QgYXQgaGFuZC4gIFlv dSB3aWxsIHByb2JhYmx5IG5ldmVyIGhhdmUgdG8gdXNlIGl0LCBidXQgaXQKKyAgICAgIDxwYXJh Pk1ha2Ugc3VyZSB5b3UgaGF2ZSB0YWtlbiBhIGJhY2t1cC4gIEFuZCBoYXZlIGEgVVNCIERyaXZl CisgICAgICAgIG9yIGJvb3RhYmxlIENEIGF0IGhhbmQuICBZb3Ugd2lsbCBwcm9iYWJseSBuZXZl ciBoYXZlIHRvIHVzZSBpdCwgYnV0IGl0CiAJaXMgYmV0dGVyIHRvIGJlIHNhZmUgdGhhbiBzb3Jy eSE8L3BhcmE+CiAgICAgPC93YXJuaW5nPgogCkluZGV4OiBkaXNrcy9jaGFwdGVyLnNnbWwKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9kb2MvZW5fVVMuSVNPODg1OS0xL2Jvb2tzL2hh bmRib29rL2Rpc2tzL2NoYXB0ZXIuc2dtbCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zMDcKZGlm ZiAtdSAtcjEuMzA3IGNoYXB0ZXIuc2dtbAotLS0gZGlza3MvY2hhcHRlci5zZ21sCTIxIE1hciAy MDExIDE0OjA0OjEzIC0wMDAwCTEuMzA3CisrKyBkaXNrcy9jaGFwdGVyLnNnbWwJMjYgTWF5IDIw MTEgMTg6NTc6NDMgLTAwMDAKQEAgLTQ0LDkgKzQ0LDYgQEAKICAgICAgICAgPHBhcmE+SG93IHRv IHVzZSBiYWNrdXAgcHJvZ3JhbXMgYXZhaWxhYmxlIHVuZGVyIEZyZWVCU0QuPC9wYXJhPgogICAg ICAgPC9saXN0aXRlbT4KICAgICAgIDxsaXN0aXRlbT4KLSAgICAgICAgPHBhcmE+SG93IHRvIGJh Y2t1cCB0byBmbG9wcHkgZGlza3MuPC9wYXJhPgotICAgICAgPC9saXN0aXRlbT4KLSAgICAgIDxs aXN0aXRlbT4KICAgICAgICAgPHBhcmE+V2hhdCBmaWxlIHN5c3RlbSBzbmFwc2hvdHMgYXJlIGFu ZCBob3cgdG8gdXNlIHRoZW0gZWZmaWNpZW50bHkuPC9wYXJhPgogICAgICAgPC9saXN0aXRlbT4K ICAgICA8L2l0ZW1pemVkbGlzdD4KQEAgLTIyMTIsMTA3ICsyMjA5LDYgQEAKICAgICA8L3NlY3Qy PgogICA8L3NlY3QxPgogCi0gIDxzZWN0MSBpZD0iYmFja3Vwcy1mbG9wcHliYWNrdXBzIj4KLSAg ICA8dGl0bGU+QmFja3VwcyB0byBGbG9wcGllczwvdGl0bGU+Ci0KLSAgICA8c2VjdDIgaWQ9ImZs b3BwaWVzLXVzaW5nIj4KLSAgICAgIDx0aXRsZT5DYW4gSSBVc2UgRmxvcHBpZXMgZm9yIEJhY2tp bmcgVXAgTXkgRGF0YT88L3RpdGxlPgotICAgICAgPGluZGV4dGVybT48cHJpbWFyeT5iYWNrdXAg ZmxvcHBpZXM8L3ByaW1hcnk+PC9pbmRleHRlcm0+Ci0gICAgICA8aW5kZXh0ZXJtPjxwcmltYXJ5 PmZsb3BweSBkaXNrczwvcHJpbWFyeT48L2luZGV4dGVybT4KLQotICAgICAgPHBhcmE+RmxvcHB5 IGRpc2tzIGFyZSBub3QgcmVhbGx5IGEgc3VpdGFibGUgbWVkaWEgZm9yCi0gICAgICAgIG1ha2lu ZyBiYWNrdXBzIGFzOjwvcGFyYT4KLQotICAgICAgPGl0ZW1pemVkbGlzdD4KLQk8bGlzdGl0ZW0+ Ci0JICA8cGFyYT5UaGUgbWVkaWEgaXMgdW5yZWxpYWJsZSwgZXNwZWNpYWxseSBvdmVyIGxvbmcg cGVyaW9kcyBvZgotCSAgICB0aW1lLjwvcGFyYT4KLQk8L2xpc3RpdGVtPgotCi0JPGxpc3RpdGVt PgotCSAgPHBhcmE+QmFja2luZyB1cCBhbmQgcmVzdG9yaW5nIGlzIHZlcnkgc2xvdy48L3BhcmE+ Ci0JPC9saXN0aXRlbT4KLQotCTxsaXN0aXRlbT4KLQkgIDxwYXJhPlRoZXkgaGF2ZSBhIHZlcnkg bGltaXRlZCBjYXBhY2l0eSAodGhlIGRheXMgb2YgYmFja2luZyB1cAotCSAgICBhbiBlbnRpcmUg aGFyZCBkaXNrIG9udG8gYSBkb3plbiBvciBzbyBmbG9wcGllcyBoYXMgbG9uZyBzaW5jZQotCSAg ICBwYXNzZWQpLjwvcGFyYT4KLQk8L2xpc3RpdGVtPgotICAgICAgPC9pdGVtaXplZGxpc3Q+Ci0K LSAgICAgIDxwYXJhPkhvd2V2ZXIsIGlmIHlvdSBoYXZlIG5vIG90aGVyIG1ldGhvZCBvZiBiYWNr aW5nIHVwIHlvdXIgZGF0YSB0aGVuCi0JZmxvcHB5IGRpc2tzIGFyZSBiZXR0ZXIgdGhhbiBubyBi YWNrdXAgYXQgYWxsLjwvcGFyYT4KLQotICAgICAgPHBhcmE+SWYgeW91IGRvIGhhdmUgdG8gdXNl IGZsb3BweSBkaXNrcyB0aGVuIGVuc3VyZSB0aGF0IHlvdSB1c2UgZ29vZAotCXF1YWxpdHkgb25l cy4gRmxvcHBpZXMgdGhhdCBoYXZlIGJlZW4gbHlpbmcgYXJvdW5kIHRoZSBvZmZpY2UgZm9yIGEK LQljb3VwbGUgb2YgeWVhcnMgYXJlIGEgYmFkIGNob2ljZS4gSWRlYWxseSB1c2UgbmV3IG9uZXMg ZnJvbSBhCi0JcmVwdXRhYmxlIG1hbnVmYWN0dXJlci48L3BhcmE+Ci0gICAgPC9zZWN0Mj4KLQot ICAgIDxzZWN0MiBpZD0iZmxvcHBpZXMtY3JlYXRpbmciPgotICAgICAgPHRpdGxlPlNvIEhvdyBE byBJIEJhY2t1cCBNeSBEYXRhIHRvIEZsb3BwaWVzPzwvdGl0bGU+Ci0KLSAgICAgIDxwYXJhPlRo ZSBiZXN0IHdheSB0byBiYWNrdXAgdG8gZmxvcHB5IGRpc2sgaXMgdG8gdXNlCi0JJm1hbi50YXIu MTsgd2l0aCB0aGUgPG9wdGlvbj4tTTwvb3B0aW9uPiAobXVsdGkKLQl2b2x1bWUpIG9wdGlvbiwg d2hpY2ggYWxsb3dzIGJhY2t1cHMgdG8gc3BhbiBtdWx0aXBsZQotCWZsb3BwaWVzLjwvcGFyYT4K LQotICAgICAgPHBhcmE+VG8gYmFja3VwIGFsbCB0aGUgZmlsZXMgaW4gdGhlIGN1cnJlbnQgZGly ZWN0b3J5IGFuZCBzdWItZGlyZWN0b3J5Ci0JdXNlIHRoaXMgKGFzIDx1c2VybmFtZT5yb290PC91 c2VybmFtZT4pOjwvcGFyYT4KLQotICAgICAgPHNjcmVlbj4mcHJvbXB0LnJvb3Q7IDx1c2VyaW5w dXQ+dGFyIE1jdmYgL2Rldi9mZDAgKjwvdXNlcmlucHV0Pjwvc2NyZWVuPgotCi0gICAgICA8cGFy YT5XaGVuIHRoZSBmaXJzdCBmbG9wcHkgaXMgZnVsbCAmbWFuLnRhci4xOyB3aWxsIHByb21wdCB5 b3UgdG8KLQlpbnNlcnQgdGhlIG5leHQgdm9sdW1lIChiZWNhdXNlICZtYW4udGFyLjE7IGlzIG1l ZGlhIGluZGVwZW5kZW50IGl0Ci0JcmVmZXJzIHRvIHZvbHVtZXM7IGluIHRoaXMgY29udGV4dCBp dCBtZWFucyBmbG9wcHkgZGlzaykuPC9wYXJhPgotCi0gICAgICA8c2NyZWVuPlByZXBhcmUgdm9s dW1lICMyIGZvciAvZGV2L2ZkMCBhbmQgaGl0IHJldHVybjo8L3NjcmVlbj4KLQotICAgICAgPHBh cmE+VGhpcyBpcyByZXBlYXRlZCAod2l0aCB0aGUgdm9sdW1lIG51bWJlciBpbmNyZW1lbnRpbmcp IHVudGlsIGFsbAotCXRoZSBzcGVjaWZpZWQgZmlsZXMgaGF2ZSBiZWVuIGFyY2hpdmVkLjwvcGFy YT4KLSAgICA8L3NlY3QyPgotCi0gICAgPHNlY3QyIGlkPSJmbG9wcGllcy1jb21wcmVzcyI+Ci0g ICAgICA8dGl0bGU+Q2FuIEkgQ29tcHJlc3MgTXkgQmFja3Vwcz88L3RpdGxlPgotICAgICAgPGlu ZGV4dGVybT4KLSAgICAgICAgPHByaW1hcnk+PGNvbW1hbmQ+dGFyPC9jb21tYW5kPjwvcHJpbWFy eT4KLSAgICAgIDwvaW5kZXh0ZXJtPgotICAgICAgPGluZGV4dGVybT4KLSAgICAgICAgPHByaW1h cnk+PGNvbW1hbmQ+Z3ppcDwvY29tbWFuZD48L3ByaW1hcnk+Ci0gICAgICA8L2luZGV4dGVybT4K LSAgICAgIDxpbmRleHRlcm0+PHByaW1hcnk+Y29tcHJlc3Npb248L3ByaW1hcnk+PC9pbmRleHRl cm0+Ci0KLSAgICAgIDxwYXJhPlVuZm9ydHVuYXRlbHksICZtYW4udGFyLjE7IHdpbGwgbm90IGFs bG93IHRoZQotCTxvcHRpb24+LXo8L29wdGlvbj4gb3B0aW9uIHRvIGJlIHVzZWQgZm9yIG11bHRp LXZvbHVtZSBhcmNoaXZlcy4KLQlZb3UgY291bGQsIG9mIGNvdXJzZSwgJm1hbi5nemlwLjE7IGFs bCB0aGUgZmlsZXMsCi0JJm1hbi50YXIuMTsgdGhlbSB0byB0aGUgZmxvcHBpZXMsIHRoZW4KLQkm bWFuLmd1bnppcC4xOyB0aGUgZmlsZXMgYWdhaW4hPC9wYXJhPgotICAgIDwvc2VjdDI+Ci0KLSAg ICA8c2VjdDIgaWQ9ImZsb3BwaWVzLXJlc3RvcmluZyI+Ci0gICAgICA8dGl0bGU+SG93IERvIEkg UmVzdG9yZSBNeSBCYWNrdXBzPzwvdGl0bGU+Ci0KLSAgICAgIDxwYXJhPlRvIHJlc3RvcmUgdGhl IGVudGlyZSBhcmNoaXZlIHVzZTo8L3BhcmE+Ci0KLSAgICAgIDxzY3JlZW4+JnByb21wdC5yb290 OyA8dXNlcmlucHV0PnRhciBNeHZmIC9kZXYvZmQwPC91c2VyaW5wdXQ+PC9zY3JlZW4+Ci0KLSAg ICAgIDxwYXJhPlRoZXJlIGFyZSB0d28gd2F5cyB0aGF0IHlvdSBjYW4gdXNlIHRvIHJlc3RvcmUg b25seQotCXNwZWNpZmljIGZpbGVzLiAgRmlyc3QsIHlvdSBjYW4gc3RhcnQgd2l0aCB0aGUgZmly c3QgZmxvcHB5Ci0JYW5kIHVzZTo8L3BhcmE+Ci0KLSAgICAgIDxzY3JlZW4+JnByb21wdC5yb290 OyA8dXNlcmlucHV0PnRhciBNeHZmIC9kZXYvZmQwIDxyZXBsYWNlYWJsZT5maWxlbmFtZTwvcmVw bGFjZWFibGU+PC91c2VyaW5wdXQ+PC9zY3JlZW4+Ci0KLSAgICAgIDxwYXJhPlRoZSB1dGlsaXR5 ICZtYW4udGFyLjE7IHdpbGwgcHJvbXB0IHlvdSB0byBpbnNlcnQgc3Vic2VxdWVudCBmbG9wcGll cyB1bnRpbCBpdAotCWZpbmRzIHRoZSByZXF1aXJlZCBmaWxlLjwvcGFyYT4KLQotICAgICAgPHBh cmE+QWx0ZXJuYXRpdmVseSwgaWYgeW91IGtub3cgd2hpY2ggZmxvcHB5IHRoZSBmaWxlIGlzIG9u IHRoZW4geW91Ci0JY2FuIHNpbXBseSBpbnNlcnQgdGhhdCBmbG9wcHkgYW5kIHVzZSB0aGUgc2Ft ZSBjb21tYW5kIGFzIGFib3ZlLiBOb3RlCi0JdGhhdCBpZiB0aGUgZmlyc3QgZmlsZSBvbiB0aGUg ZmxvcHB5IGlzIGEgY29udGludWF0aW9uIGZyb20gdGhlCi0JcHJldmlvdXMgb25lIHRoZW4gJm1h bi50YXIuMTsgd2lsbCB3YXJuIHlvdSB0aGF0IGl0IGNhbm5vdAotCXJlc3RvcmUgaXQsIGV2ZW4g aWYgeW91IGhhdmUgbm90IGFza2VkIGl0IHRvITwvcGFyYT4KLSAgICA8L3NlY3QyPgotICA8L3Nl Y3QxPgotCiAgIDxzZWN0MSBpZD0iYmFja3VwLXN0cmF0ZWdpZXMiPgogICAgIDxzZWN0MWluZm8+ CiAgICAgICA8YXV0aG9yZ3JvdXA+CkluZGV4OiBpbnN0YWxsL2NoYXB0ZXIuc2dtbAo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL2RvYy9lbl9VUy5JU084ODU5LTEvYm9va3MvaGFuZGJv b2svaW5zdGFsbC9jaGFwdGVyLnNnbWwsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNDI1CmRpZmYg LXUgLXIxLjQyNSBjaGFwdGVyLnNnbWwKLS0tIGluc3RhbGwvY2hhcHRlci5zZ21sCTIwIEFwciAy MDExIDEyOjE4OjI4IC0wMDAwCTEuNDI1CisrKyBpbnN0YWxsL2NoYXB0ZXIuc2dtbAkyNiBNYXkg MjAxMSAxODo1Nzo0NCAtMDAwMApAQCAtNzA5LDIxICs3MDksMTggQEAKIAkgIAogCSAgPGltcG9y dGFudD4KIAkgICAgPHBhcmE+UGxlYXNlIG5vdGUsIGFzIG9mICZvczsmbmJzcDs4LjxyZXBsYWNl YWJsZT5YPC9yZXBsYWNlYWJsZT4sIGZsb3BweSBkaXNrIGltYWdlcyBhcmUKLQkgICAgICBubyBs b25nZXIgYXZhaWxhYmxlLiAgUGxlYXNlIHNlZSBhYm92ZSBmb3IgaW5zdHJ1Y3Rpb25zCisJICAg ICAgb25seSBhdmFpbGFibGUgZm9yIHRoZSBQQzk4IGFyY2hpdGVjdHVyZS4gUGxlYXNlIHNlZSBh Ym92ZSBmb3IgaW5zdHJ1Y3Rpb25zCiAJICAgICAgb24gaG93IHRvIGluc3RhbGwgJm9zOyB1c2lu ZyBhIFVTQiBtZW1vcnkgc3RpY2sgb3IganVzdAogCSAgICAgIHVzZSBhIENEUk9NIG9yIGEgRFZE LjwvcGFyYT4KIAkgIDwvaW1wb3J0YW50PgogCi0JICA8cGFyYT5UaGUgYm9vdCBkaXNrcyBhcmUg YXZhaWxhYmxlIG9uIHlvdXIgaW5zdGFsbGF0aW9uIG1lZGlhCi0JICAgIGluIHRoZSA8ZmlsZW5h bWU+ZmxvcHBpZXMvPC9maWxlbmFtZT4gZGlyZWN0b3J5LCBhbmQKLQkgICAgY2FuIGFsc28gYmUg ZG93bmxvYWRlZCBmcm9tIHRoZSBmbG9wcGllcyBkaXJlY3RvcnksIDxsaXRlcmFsPmZ0cDovL2Z0 cC5GcmVlQlNELm9yZy9wdWIvRnJlZUJTRC9yZWxlYXNlcy88cmVwbGFjZWFibGU+YXJjaDwvcmVw bGFjZWFibGU+LzxyZXBsYWNlYWJsZT52ZXJzaW9uPC9yZXBsYWNlYWJsZT4tUkVMRUFTRS9mbG9w cGllcy88L2xpdGVyYWw+LgotCSAgICBSZXBsYWNlIDxyZXBsYWNlYWJsZT5hcmNoPC9yZXBsYWNl YWJsZT4gYW5kCi0JICAgIDxyZXBsYWNlYWJsZT52ZXJzaW9uPC9yZXBsYWNlYWJsZT4KLQkgICAg d2l0aCB0aGUgYXJjaGl0ZWN0dXJlIGFuZCB0aGUgdmVyc2lvbiBudW1iZXIKLQkgICAgd2hpY2gg eW91IHdhbnQgdG8gaW5zdGFsbCwgcmVzcGVjdGl2ZWx5LgorCSAgPHBhcmE+VGhlIFBDOTggYm9v dCBmbG9wcGllcyBhcmUgYXZhaWxhYmxlCisJICAgIGFuZCBjYW4gYmUgZG93bmxvYWRlZCBmcm9t IHRoZSBmbG9wcGllcyBkaXJlY3RvcnksIDxsaXRlcmFsPmZ0cDovL2Z0cC5GcmVlQlNELm9yZy9w dWIvRnJlZUJTRC9yZWxlYXNlcy9wYzk4LzxyZXBsYWNlYWJsZT52ZXJzaW9uPC9yZXBsYWNlYWJs ZT4tUkVMRUFTRS9mbG9wcGllcy88L2xpdGVyYWw+LgorCSAgICBSZXBsYWNlIDxyZXBsYWNlYWJs ZT52ZXJzaW9uPC9yZXBsYWNlYWJsZT4KKwkgICAgd2l0aCB2ZXJzaW9uIG51bWJlciB3aGljaCB5 b3Ugd2FudCB0byBpbnN0YWxsLgogCSAgICBGb3IgZXhhbXBsZSwgdGhlIGJvb3QgZmxvcHB5IGlt YWdlcyBmb3IKLQkgICAgJm9zOy8mYXJjaC5pMzg2OyZuYnNwOyZyZWwyLmN1cnJlbnQ7LVJFTEVB U0UgYXJlIGF2YWlsYWJsZQotCSAgICBmcm9tIDx1bGluayB1cmw9ImZ0cDovL2Z0cC5GcmVlQlNE Lm9yZy9wdWIvRnJlZUJTRC9yZWxlYXNlcy9pMzg2LyZyZWwyLmN1cnJlbnQ7LVJFTEVBU0UvZmxv cHBpZXMvIj48L3VsaW5rPi48L3BhcmE+CisJICAgICZyZWwyLmN1cnJlbnQ7LVJFTEVBU0UgYXJl IGF2YWlsYWJsZQorCSAgICBmcm9tIDx1bGluayB1cmw9ImZ0cDovL2Z0cC5GcmVlQlNELm9yZy9w dWIvRnJlZUJTRC9yZWxlYXNlcy9wYzk4LyZyZWwyLmN1cnJlbnQ7LVJFTEVBU0UvZmxvcHBpZXMv Ij48L3VsaW5rPi48L3BhcmE+CiAKIAkgIDxwYXJhPlRoZSBmbG9wcHkgaW1hZ2VzIGhhdmUgYSA8 ZmlsZW5hbWU+LmZscDwvZmlsZW5hbWU+IGV4dGVuc2lvbi4KIAkgICAgVGhlIDxmaWxlbmFtZT5m bG9wcGllcy88L2ZpbGVuYW1lPiBkaXJlY3RvcnkgY29udGFpbnMgYSBudW1iZXIgb2YKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9kb2MvZW5fVVMuSVNPODg1OS0xL2Jvb2tzL2hhbmRi b29rL25ldHdvcmstc2VydmVycy9jaGFwdGVyLnNnbWwsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEu MTMxCmRpZmYgLXUgLXIxLjEzMSBjaGFwdGVyLnNnbWwKLS0tIG5ldHdvcmstc2VydmVycy9jaGFw dGVyLnNnbWwJMjMgTWF5IDIwMTEgMTU6MzI6MzQgLTAwMDAJMS4xMzEKKysrIG5ldHdvcmstc2Vy dmVycy9jaGFwdGVyLnNnbWwJMjYgTWF5IDIwMTEgMTg6NTc6NDcgLTAwMDAKQEAgLTU3Miw3ICs1 NzIsNyBAQAogICAgICAgPC9saXN0aXRlbT4KIAogICAgICAgPGxpc3RpdGVtPgotCTxwYXJhPlN0 b3JhZ2UgZGV2aWNlcyBzdWNoIGFzIGZsb3BweSBkaXNrcywgQ0RST00gZHJpdmVzLCBhbmQKKwk8 cGFyYT5TdG9yYWdlIGRldmljZXMgc3VjaCBhcyBDRFJPTSBkcml2ZXMsIGFuZAogCSAgJmlvbWVn YXppcDsgZHJpdmVzIGNhbiBiZSB1c2VkIGJ5IG90aGVyIG1hY2hpbmVzIG9uIHRoZSBuZXR3b3Jr LgogCSAgVGhpcyBtYXkgcmVkdWNlIHRoZSBudW1iZXIgb2YgcmVtb3ZhYmxlIG1lZGlhIGRyaXZl cwogCSAgdGhyb3VnaG91dCB0aGUgbmV0d29yay48L3BhcmE+CkluZGV4OiBzZWN1cml0eS9jaGFw dGVyLnNnbWwKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9kb2MvZW5fVVMuSVNPODg1 OS0xL2Jvb2tzL2hhbmRib29rL3NlY3VyaXR5L2NoYXB0ZXIuc2dtbCx2CnJldHJpZXZpbmcgcmV2 aXNpb24gMS4zMzkKZGlmZiAtdSAtcjEuMzM5IGNoYXB0ZXIuc2dtbAotLS0gc2VjdXJpdHkvY2hh cHRlci5zZ21sCTE1IE1heSAyMDExIDIwOjQxOjMwIC0wMDAwCTEuMzM5CisrKyBzZWN1cml0eS9j aGFwdGVyLnNnbWwJMjYgTWF5IDIwMTEgMTg6NTc6NDggLTAwMDAKQEAgLTE4MjksNyArMTgyOSw3 IEBACiAJICBzbywgc2ltcGx5IGNvcHkgaXQgb3ZlciB0byB0aGUgY2xpZW50IGNvbXB1dGVyIGZy b20gdGhlCiAJICA8YWNyb255bT5LREM8L2Fjcm9ueW0+IGluIGEgc2VjdXJlIGZhc2hpb24gKHVz aW5nIG5ldHdvcmsgdXRpbGl0aWVzLAogCSAgc3VjaCBhcyAmbWFuLnNjcC4xOywgb3IgcGh5c2lj YWxseSB2aWEgYQotCSAgZmxvcHB5IGRpc2spLjwvcGFyYT4KKwkgIFVTQiBkcml2ZSkuPC9wYXJh PgogCiAJPHBhcmE+TmV4dCB5b3UgbmVlZCBhIDxmaWxlbmFtZT4vZXRjL2tyYjUua2V5dGFiPC9m aWxlbmFtZT4gZmlsZS4KIAkgIFRoaXMgaXMgdGhlIG1ham9yIGRpZmZlcmVuY2UgYmV0d2VlbiBh IHNlcnZlciBwcm92aWRpbmcKQEAgLTE4OTYsNyArMTg5Niw3IEBACiBrYWRtaW4+PHVzZXJpbnB1 dD4gZXhpdDwvdXNlcmlucHV0Pjwvc2NyZWVuPgogCiAJPHBhcmE+WW91IGNhbiB0aGVuIHNlY3Vy ZWx5IGNvcHkgdGhlIGtleXRhYiB0byB0aGUgc2VydmVyCi0JICBjb21wdXRlciAodXNpbmcgPGNv bW1hbmQ+c2NwPC9jb21tYW5kPiBvciBhIGZsb3BweSwgZm9yCisJICBjb21wdXRlciAodXNpbmcg PGNvbW1hbmQ+c2NwPC9jb21tYW5kPiBvciBhIFVTQiB0aHVtYiBkcml2ZSwgZm9yCiAJICBleGFt cGxlKS4gIEJlIHN1cmUgdG8gc3BlY2lmeSBhIG5vbi1kZWZhdWx0IGtleXRhYiBuYW1lCiAJICB0 byBhdm9pZCBvdmVyLXdyaXRpbmcgdGhlIGtleXRhYiBvbiB0aGUKIAkgIDxhY3JvbnltPktEQzwv YWNyb255bT4uPC9wYXJhPgo= --20cf3071cc72ef0d3e04a43307d3-- From owner-freebsd-doc@FreeBSD.ORG Fri May 27 10:17:09 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D23561065670; Fri, 27 May 2011 10:17:09 +0000 (UTC) Date: Fri, 27 May 2011 10:17:09 +0000 From: Alexander Best To: freebsd-doc@freebsd.org Message-ID: <20110527101709.GA59691@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline Subject: correcting a small doc bug for WITHOUT_SSP X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 10:17:09 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, WITHOUT_SSP does not only affect world, but also the kernel and kernel modules. the following patch should take care of that (please remember to regen src.conf(5) after applying the patch). cheers. alex -- a13x --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="WITHOUT_SSP.patch" diff --git a/tools/build/options/WITHOUT_SSP b/tools/build/options/WITHOUT_SSP index 9e7d9c1..dc9f350 100644 --- a/tools/build/options/WITHOUT_SSP +++ b/tools/build/options/WITHOUT_SSP @@ -1,2 +1,3 @@ .\" $FreeBSD$ -Set to not build world with propolice stack smashing protection. +Set to not build the kernel, kernel modules and world with propolice stack +smashing protection. --azLHFNyN32YCQGCU-- From owner-freebsd-doc@FreeBSD.ORG Fri May 27 11:38:17 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA6B2106566C; Fri, 27 May 2011 11:38:17 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9392F8FC15; Fri, 27 May 2011 11:38:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4RBcHxA013895; Fri, 27 May 2011 11:38:17 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4RBcHsg013891; Fri, 27 May 2011 11:38:17 GMT (envelope-from bcr) Date: Fri, 27 May 2011 11:38:17 GMT Message-Id: <201105271138.p4RBcHsg013891@freefall.freebsd.org> To: bcr@FreeBSD.org, freebsd-doc@FreeBSD.org, bcr@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/157116: Mention dovecot as a pop/imap server X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 11:38:17 -0000 Synopsis: Mention dovecot as a pop/imap server Responsible-Changed-From-To: freebsd-doc->bcr Responsible-Changed-By: bcr Responsible-Changed-When: Fri May 27 11:37:52 UTC 2011 Responsible-Changed-Why: I will work on it. http://www.freebsd.org/cgi/query-pr.cgi?pr=157116 From owner-freebsd-doc@FreeBSD.ORG Fri May 27 14:30:22 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C91E610657B9 for ; Fri, 27 May 2011 14:30:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B856F8FC1C for ; Fri, 27 May 2011 14:30:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4REUMPu077941 for ; Fri, 27 May 2011 14:30:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4REUMYm077929; Fri, 27 May 2011 14:30:22 GMT (envelope-from gnats) Date: Fri, 27 May 2011 14:30:22 GMT Message-Id: <201105271430.p4REUMYm077929@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Benedict Reuschling Cc: Subject: Re: docs/156955: bug in share/man/man2/setsockopt.2 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benedict Reuschling List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 14:30:22 -0000 The following reply was made to PR docs/156955; it has been noted by GNATS. From: Benedict Reuschling To: bug-followup@FreeBSD.org, mandree@FreeBSD.org Cc: Subject: Re: docs/156955: bug in share/man/man2/setsockopt.2 Date: Fri, 27 May 2011 16:24:56 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is this still an issue? The man page looks fine on the two systems I checked. The SO_KEEPALIVE text is on its own line. The file in question is lib/libc/sys/getsockopt.2 and has the correct formatting as far as I can see. Benedict Reuschling FreeBSD Doc Committer The FreeBSD Documentation Project FreeBSD German Documentation Project - https://doc.bsdgroup.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ftDIACgkQTSZQLkqBk0iBWACfZcm71wOuahNBcE2WMqZp35Ta 7y0AniPh8VTFTvxvd9dtIEWzmCLa0hJC =0zGA -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Fri May 27 14:47:28 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E4351065673; Fri, 27 May 2011 14:47:28 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 662B88FC0C; Fri, 27 May 2011 14:47:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4RElSQJ096708; Fri, 27 May 2011 14:47:28 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4RElQKV096701; Fri, 27 May 2011 14:47:26 GMT (envelope-from bcr) Date: Fri, 27 May 2011 14:47:26 GMT Message-Id: <201105271447.p4RElQKV096701@freefall.freebsd.org> To: a.spinella@rfc1925.net, bcr@FreeBSD.org, freebsd-doc@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/156222: syslog.conf(5): multiple typos in syslog-ng.conf manpage X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 14:47:28 -0000 Synopsis: syslog.conf(5): multiple typos in syslog-ng.conf manpage State-Changed-From-To: open->closed State-Changed-By: bcr State-Changed-When: Fri May 27 14:45:19 UTC 2011 State-Changed-Why: The typos existed in syslog-ng version 3.0, newer versions do not (the FILTERS section seems to have been restructured). The latest version of siyslog-ng is available in the ports collection. No action necessary on our side. PR closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=156222 From owner-freebsd-doc@FreeBSD.ORG Fri May 27 15:28:16 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D84681065673 for ; Fri, 27 May 2011 15:28:16 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 62E468FC1B for ; Fri, 27 May 2011 15:28:15 +0000 (UTC) Received: from park.js.berklix.net (p5DCBECB5.dip.t-dialin.net [93.203.236.181]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p4REw8xS051172; Fri, 27 May 2011 14:58:09 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id p4REw6jf015919; Fri, 27 May 2011 16:58:06 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id p4REvpl3098495; Fri, 27 May 2011 16:57:56 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201105271457.p4REvpl3098495@fire.js.berklix.net> To: doc@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Fri, 27 May 2011 16:57:51 +0200 Sender: jhs@berklix.com Cc: Ramu Chakravadhanula , "Julian H. Stacey" Subject: Supplementing 2.3 Pre-installation Tasks & 2.6 Allocating Disk Space X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 15:28:16 -0000 Hi Doc developers Ramu Chakravadhanula (cc'd) asked on here http://docs.FreeBSD.org/cgi/mid.cgi?BANLkTinQ0Y-wKWJ7RZrqH08HUVQuVv_Mbg for help installing FreeBSD as a 2nd OS after another OS already installed. A frequent desire, not so well covered in docs. I wrote a new page How To Install BSD On A PC With Another OS Already Present http://www.berklix.com/~jhs/txt/install_bsd.html & linked it to freebsd.org pages for 2.3 Pre-installation Tasks 2.6 Allocating Disk Space Ramu kindly wrote he found it useful, so would you consider: Linking to it ?, Or Absorbing material from it into your other pages ? I'll later improve it, & add a section re. ntfsresize for emigrants from MS/XP/W7. I did not send a send-pr, as I guess its better to discuss how/ where etc. PS I'm not sub'ed to this list (just to about 30 other FreeBSD lists though ;-) ) , so if you will, leave me on CC line. Thanks. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; indent with "> "; cumulative like a play script. Mail plain text format; Not quoted-printable, Not HTML, Not base 64. UK: Some MPs assert some injunctions obstruct constituent communication & are contempt of parliament. Parliament once sent a judge to the tower. From owner-freebsd-doc@FreeBSD.ORG Fri May 27 15:50:12 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FEE71065674 for ; Fri, 27 May 2011 15:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7F47A8FC12 for ; Fri, 27 May 2011 15:50:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4RFoCFE051085 for ; Fri, 27 May 2011 15:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4RFoCcc051084; Fri, 27 May 2011 15:50:12 GMT (envelope-from gnats) Date: Fri, 27 May 2011 15:50:12 GMT Message-Id: <201105271550.p4RFoCcc051084@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Matthias Andree Cc: Subject: Re: docs/156955: bug in share/man/man2/setsockopt.2 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Andree List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 15:50:12 -0000 The following reply was made to PR docs/156955; it has been noted by GNATS. From: Matthias Andree To: bcr@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: docs/156955: bug in share/man/man2/setsockopt.2 Date: Fri, 27 May 2011 17:41:29 +0200 Am 27.05.2011 16:24, schrieb Benedict Reuschling: > Is this still an issue? The man page looks fine on the two systems I > checked. The SO_KEEPALIVE text is on its own line. The file in question > is lib/libc/sys/getsockopt.2 and has the correct formatting as far as I > can see. > > Benedict Reuschling > FreeBSD Doc Committer > > The FreeBSD Documentation Project > FreeBSD German Documentation Project - https://doc.bsdgroup.de Yup, still broken on RELENG_8: ... SO_DEBUG enables debugging in the underlying protocol modules. SO_REUSEADDR indicates that the rules used in validating addresses sup- plied in a bind(2) system call should allow reuse of local addresses. SO_REUSEPORT allows completely duplicate bindings by multiple processes if they all set SO_REUSEPORT before binding the port. This option per- mits multiple instances of a program to each receive UDP/IP multicast or broadcast datagrams destined for the bound port. SO_KEEPALIVE enables the periodic transmission of messages on a connected socket. Should the connected party fail to respond to these messages, the connection is con- sidered broken and processes using the socket are notified via a SIGPIPE signal when attempting to send data. SO_DONTROUTE indicates that outgo- ing messages should bypass the standard routing facilities. Instead, messages are directed to the appropriate network interface according to the network portion of the destination address. ... So missing paragraphs befrore SO_REUSEPORT, SO_KEEPALIVE, SO_DONTROUTE, SO_RCVTIMEO, possibly more. From owner-freebsd-doc@FreeBSD.ORG Fri May 27 15:50:14 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DD081065672 for ; Fri, 27 May 2011 15:50:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8D93B8FC14 for ; Fri, 27 May 2011 15:50:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4RFoE9f051101 for ; Fri, 27 May 2011 15:50:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4RFoEO7051100; Fri, 27 May 2011 15:50:14 GMT (envelope-from gnats) Date: Fri, 27 May 2011 15:50:14 GMT Message-Id: <201105271550.p4RFoEO7051100@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Matthias Andree Cc: Subject: Re: docs/156955: bug in share/man/man2/setsockopt.2 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Andree List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 15:50:14 -0000 The following reply was made to PR docs/156955; it has been noted by GNATS. From: Matthias Andree To: bcr@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: docs/156955: bug in share/man/man2/setsockopt.2 Date: Fri, 27 May 2011 17:45:50 +0200 Am 27.05.2011 16:24, schrieb Benedict Reuschling: > Is this still an issue? The man page looks fine on the two systems I > checked. The SO_KEEPALIVE text is on its own line. The file in question > is lib/libc/sys/getsockopt.2 and has the correct formatting as far as I > can see. Source-level view, looking at /usr/src/lib/libc/sys/getsockopt.2: Lots of .Dv SO_MUMBLE options, few with a precding .Pp. I'm not talking about the listing, but about the run-down text further down. From owner-freebsd-doc@FreeBSD.ORG Sat May 28 17:20:01 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2BF5106566B; Sat, 28 May 2011 17:20:01 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A70748FC16; Sat, 28 May 2011 17:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4SHK1Wi083449; Sat, 28 May 2011 17:20:01 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4SHK1Rl083445; Sat, 28 May 2011 17:20:01 GMT (envelope-from bcr) Date: Sat, 28 May 2011 17:20:01 GMT Message-Id: <201105281720.p4SHK1Rl083445@freefall.freebsd.org> To: niclas.zeising@gmail.com, bcr@FreeBSD.org, freebsd-doc@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/157354: [PATCH] update newfs(8) man page after changed defaults X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 17:20:01 -0000 Synopsis: [PATCH] update newfs(8) man page after changed defaults State-Changed-From-To: open->feedback State-Changed-By: bcr State-Changed-When: Sat May 28 17:17:26 UTC 2011 State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=157354 From owner-freebsd-doc@FreeBSD.ORG Sat May 28 17:22:19 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D9631065670; Sat, 28 May 2011 17:22:19 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 170158FC08; Sat, 28 May 2011 17:22:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4SHMIFg091549; Sat, 28 May 2011 17:22:18 GMT (envelope-from bcr@freefall.freebsd.org) Received: (from bcr@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4SHMIGT091545; Sat, 28 May 2011 17:22:18 GMT (envelope-from bcr) Date: Sat, 28 May 2011 17:22:18 GMT Message-Id: <201105281722.p4SHMIGT091545@freefall.freebsd.org> To: niclas.zeising@gmail.com, bcr@FreeBSD.org, freebsd-doc@FreeBSD.org From: bcr@FreeBSD.org Cc: Subject: Re: docs/157354: [PATCH] update newfs(8) man page after changed defaults X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 17:22:19 -0000 Synopsis: [PATCH] update newfs(8) man page after changed defaults State-Changed-From-To: feedback->closed State-Changed-By: bcr State-Changed-When: Sat May 28 17:20:06 UTC 2011 State-Changed-Why: Close this PR, as the commit in r222423 changed the relevant bits. http://www.freebsd.org/cgi/query-pr.cgi?pr=157354