From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 00:44:25 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4133587; Sun, 16 Feb 2014 00:44:25 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF6441905; Sun, 16 Feb 2014 00:44:25 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G0iPUc004564; Sun, 16 Feb 2014 00:44:25 GMT (envelope-from pluknet@svn.freebsd.org) Received: (from pluknet@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G0iPmE004563; Sun, 16 Feb 2014 00:44:25 GMT (envelope-from pluknet@svn.freebsd.org) Message-Id: <201402160044.s1G0iPmE004563@svn.freebsd.org> From: Sergey Kandaurov Date: Sun, 16 Feb 2014 00:44:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43951 - head/en_US.ISO8859-1/books/porters-handbook/special X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 00:44:25 -0000 Author: pluknet Date: Sun Feb 16 00:44:25 2014 New Revision: 43951 URL: http://svnweb.freebsd.org/changeset/doc/43951 Log: Fix typo. Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sat Feb 15 14:30:55 2014 (r43950) +++ head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 00:44:25 2014 (r43951) @@ -255,7 +255,7 @@ above variables, the variable LEGAL_TEXT should be set to a string explaining the concern. For example, if special permission was obtained for &os; to - redistribute the binary, this variable should indiate + redistribute the binary, this variable should indicate so. From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 02:10:30 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 391BFA90; Sun, 16 Feb 2014 02:10:30 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22E611DDE; Sun, 16 Feb 2014 02:10:30 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G2AUSP041952; Sun, 16 Feb 2014 02:10:30 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G2AUQT041951; Sun, 16 Feb 2014 02:10:30 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160210.s1G2AUQT041951@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 02:10:30 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43952 - head/en_US.ISO8859-1/books/porters-handbook/quick-porting X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 02:10:30 -0000 Author: wblock Date: Sun Feb 16 02:10:29 2014 New Revision: 43952 URL: http://svnweb.freebsd.org/changeset/doc/43952 Log: Whitespace-only cleanup, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/quick-porting/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/quick-porting/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/quick-porting/chapter.xml Sun Feb 16 00:44:25 2014 (r43951) +++ head/en_US.ISO8859-1/books/porters-handbook/quick-porting/chapter.xml Sun Feb 16 02:10:29 2014 (r43952) @@ -4,45 +4,47 @@ $FreeBSD$ --> - + + + Quick Porting + + This section tells you how to quickly create a new port. In + many cases, it is not sufficient, so you will have to read + further on into the document. + + First, get the original tarball and put it into + DISTDIR, which defaults to + /usr/ports/distfiles. + + + The following assumes that the software compiled + out-of-the-box, i.e., there was absolutely no change required + for the port to work on your &os; box. If you needed to + change something, you will have to refer to the next section + too. + + + + It is recommended to set the DEVELOPER + &man.make.1; variable in /etc/make.conf + before getting into porting. + + &prompt.root; echo DEVELOPER=yes >> /etc/make.conf + + This setting enables the developer mode + that displays deprecation warnings and activates some further + quality checks on calling make. + - Quick Porting + + Writing the <filename>Makefile</filename> - This section tells you how to quickly create a new port. In - many cases, it is not sufficient, so you will have to read - further on into the document. + The minimal Makefile would look + something like this: - First, get the original tarball and put it into - DISTDIR, which defaults to - /usr/ports/distfiles. - - - The following assumes that the software compiled - out-of-the-box, i.e., there was absolutely no change required - for the port to work on your &os; box. If you needed to - change something, you will have to refer to the next section - too. - - - - It is recommended to set the DEVELOPER - &man.make.1; variable in /etc/make.conf - before getting into porting. - - &prompt.root; echo DEVELOPER=yes >> /etc/make.conf - - This setting enables the developer mode - that displays deprecation warnings and activates some further - quality checks on calling make. - - - - Writing the <filename>Makefile</filename> - - The minimal Makefile would look - something like this: - - # $FreeBSD$ + # $FreeBSD$ PORTNAME= oneko PORTVERSION= 1.1b @@ -54,101 +56,100 @@ COMMENT= Cat chasing a mouse all over th .include <bsd.port.mk> + + In some cases, the Makefile of an + existing port may contain additional lines in the header, + such as the name of the port and the date it was created. + This additional information has been declared obsolete, and + is being phased out. + + + See if you can figure it out. Do not worry about the + contents of the $FreeBSD$ + line, it will be filled in automatically by + Subversion when the port is + imported to our main ports tree. You can find a more detailed + example in the + sample Makefile + section. + + + + Writing the Description Files + + There are two description files that are required for + any port, whether they actually package or not. They are + pkg-descr and + pkg-plist. Their + pkg- prefix distinguishes them from other + files. + + + <filename>pkg-descr</filename> + + This is a longer description of the port. One to a few + paragraphs concisely explaining what the port does is + sufficient. + - In some cases, the Makefile of an - existing port may contain additional lines in the header, - such as the name of the port and the date it was created. - This additional information has been declared obsolete, and - is being phased out. + This is not a manual or an + in-depth description on how to use or compile the port! + Please be careful if you are copying from the + README or manpage; too + often they are not a concise description of the port or + are in an awkward format (e.g., manpages have justified + spacing, which looks particularly bad with monospaced + fonts). - See if you can figure it out. Do not worry about the - contents of the $FreeBSD$ - line, it will be filled in automatically by - Subversion when the port is - imported to our main ports tree. You can find a more detailed - example in the - sample Makefile - section. - - - - Writing the Description Files - - There are two description files that are required for - any port, whether they actually package or not. They are - pkg-descr and - pkg-plist. Their - pkg- prefix distinguishes them from other - files. - - - <filename>pkg-descr</filename> - - This is a longer description of the port. One to a few - paragraphs concisely explaining what the port does is - sufficient. - - - This is not a manual or an - in-depth description on how to use or compile the port! - Please be careful if you are copying from the - README or manpage; too - often they are not a concise description of the port or - are in an awkward format (e.g., manpages have justified - spacing, which looks particularly bad with monospaced - fonts). - - - A well-written pkg-descr describes - the port completely enough that users would not have to - consult the documentation or visit the website to understand - what the software does, how it can be useful, or what - particularly nice features it has. Mentioning certain - requirements like a graphical toolkit, heavy dependencies, - runtime environment, or implementation languages help users - decide whether this port will work for them. - - Include a URL to the official WWW homepage. Prepend - one of the websites (pick the most - common one) with WWW: (followed by single - space) so that automated tools will work correctly. If the - URI is the root of the website or directory, it should be - terminated with a slash. - - - If the listed webpage for a port is not available, try - to search the Internet first to see if the official site - moved, was renamed, or is hosted elsewhere. - + A well-written pkg-descr describes + the port completely enough that users would not have to + consult the documentation or visit the website to understand + what the software does, how it can be useful, or what + particularly nice features it has. Mentioning certain + requirements like a graphical toolkit, heavy dependencies, + runtime environment, or implementation languages help users + decide whether this port will work for them. + + Include a URL to the official WWW homepage. Prepend + one of the websites (pick the most + common one) with WWW: (followed by single + space) so that automated tools will work correctly. If the + URI is the root of the website or directory, it should be + terminated with a slash. - The following example shows how your - pkg-descr should look: + + If the listed webpage for a port is not available, try + to search the Internet first to see if the official site + moved, was renamed, or is hosted elsewhere. + + + The following example shows how your + pkg-descr should look: - This is a port of oneko, in which a cat chases a poor mouse all over + This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (etc.) WWW: http://www.oneko.org/ - + - - <filename>pkg-plist</filename> + + <filename>pkg-plist</filename> - This file lists all the files installed by the port. It - is also called the packing list because the - package is generated by packing the files listed here. The - pathnames are relative to the installation prefix (usually - /usr/local. - If the - port creates directories during installation, make sure to - add @dirrm lines to remove them when the - package is deleted. + This file lists all the files installed by the port. It + is also called the packing list because the + package is generated by packing the files listed here. The + pathnames are relative to the installation prefix (usually + /usr/local. If the port creates + directories during installation, make sure to add + @dirrm lines to remove them when the + package is deleted. - Here is a small example: + Here is a small example: - bin/oneko + bin/oneko man/man1/oneko.1.gz lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm @@ -156,34 +157,34 @@ lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko - Refer to the &man.pkg-create.8; manual page for details - on the packing list. + Refer to the &man.pkg-create.8; manual page for details + on the packing list. - - It is recommended that you keep all the filenames in - this file sorted alphabetically. It will make verifying - the changes when you upgrade the port much easier. - - - - Creating a packing list manually can be a very tedious - task. If the port installs a large numbers of files, - creating the packing list - automatically might save time. - - - There is only one case when - pkg-plist can be omitted from a port. - If the port installs just a handful of files, and perhaps - directories, the files and directories may be listed in the - variables PLIST_FILES and - PLIST_DIRS, respectively, within the - port's Makefile. For instance, we - could get along without pkg-plist in - the above oneko port by adding the - following lines to the Makefile: + + It is recommended that you keep all the filenames in + this file sorted alphabetically. It will make verifying + the changes when you upgrade the port much easier. + + + + Creating a packing list manually can be a very tedious + task. If the port installs a large numbers of files, + creating the packing list + automatically might save time. + - PLIST_FILES= bin/oneko \ + There is only one case when + pkg-plist can be omitted from a port. + If the port installs just a handful of files, and perhaps + directories, the files and directories may be listed in the + variables PLIST_FILES and + PLIST_DIRS, respectively, within the + port's Makefile. For instance, we + could get along without pkg-plist in + the above oneko port by adding the + following lines to the Makefile: + + PLIST_FILES= bin/oneko \ man/man1/oneko.1.gz \ lib/X11/app-defaults/Oneko \ lib/X11/oneko/cat1.xpm \ @@ -191,215 +192,211 @@ lib/X11/oneko/mouse.xpm lib/X11/oneko/mouse.xpm PLIST_DIRS= lib/X11/oneko - Of course, PLIST_DIRS should be left - unset if a port installs no directories of its own. - - - - Several ports can share a common directory. In that - case, PLIST_DIRS should be replaced by - PLIST_DIRSTRY so that the directory is - removed only if empty, otherwise it is silently ignored. - PLIST_DIRS and - PLIST_DIRSTRY are equivalent to using - @dirrm and @dirrmtry - in pkg-plist, as described in - . - - - The price for this way of listing port's files and - directories is that you cannot use command sequences - described in &man.pkg-create.8;. Therefore, it is suitable - only for simple ports and makes them even simpler. At the - same time, it has the advantage of reducing the number of - files in the ports collection. Please consider using this - technique before you resort to - pkg-plist. - - Later we will see how pkg-plist - and PLIST_FILES can be used to fulfill - more sophisticated - tasks. - - - - - Creating the Checksum File - - Just type make makesum. The ports make - rules will automatically generate the file - distinfo. - - If a file fetched has its checksum changed regularly and - you are certain the source is trusted (i.e., it comes from - manufacturer CDs or documentation generated daily), you should - specify these files in the IGNOREFILES - variable. Then the checksum is not calculated for that file - when you run make makesum, but set to - IGNORE. - - - - Testing the Port - - You should make sure that the port rules do exactly what - you want them to do, including packaging up the port. These - are the important points you need to verify. - - - - pkg-plist does not contain - anything not installed by the port. - - - - pkg-plist contains everything - that is installed by the port. - - - - The port can be installed using the - install target. This verifies - that the install script works correctly. - - - - The port can be deinstalled properly using the - deinstall target. This - verifies that the deinstall script works correctly. - - - - Make sure that make package can be - run as a normal user (that is, not as - root). If that - fails, NEED_ROOT=yes must be added to - the port Makefile. - - - - - Recommended Test Ordering - - - make stage - - - - make check-orphans - - - - make package - - - - make install - - - - make deinstall - - - - pkg add package-filename - - - - make package (as user) - - - - Make certain no warnings are shown in any of - the stages. - - Thorough automated testing can be done with - ports-mgmt/tinderbox or - ports-mgmt/poudriere from the - Ports Collection. These applications maintain - jails where all of the steps shown above - can be tested without affecting the state of the host - system. - - - - Checking Your Port with - <command>portlint</command> - - Please use portlint to see if your port - conforms to our guidelines. The - ports-mgmt/portlint - program is part of the ports collection. In particular, you - may want to check if the - Makefile is in the - right shape and the - package is named - appropriately. - - - - Submitting the New Port - - Before submitting the new port, read - the DOs and DON'Ts - section. - - Once happy with your port, the only thing remaining is to - put it in the main &os; ports tree and make everybody else - happy about it too. We do not need the - work directory or the - pkgname.tgz package, so delete them - now. - - Next, build the &man.shar.1; file. Assuming the port is - called oneko, cd to the - directory above where the oneko directory - is located, and then type: - shar `find oneko` > oneko.shar - - Include oneko.shar in a bug - report and send it with &man.send-pr.1;. See - Bug - Reports and General Commentary for more information - about &man.send-pr.1;. - - Classify the bug report as Category - ports and Class - change-request. Do - not mark the report - confidential! Add a short description of - the program to the Description field of the PR (perhaps a - short version of the COMMENT), and add the - .shar file to the Fix field. + Of course, PLIST_DIRS should be left + unset if a port installs no directories of its own. - Giving a good description in the synopsis of the problem - report makes the work of port committers a lot easier. We - prefer something like New port: - <category>/<portname> <short description of - the port> for new ports. Using this - scheme makes it easier and faster to begin the work of - committing the new port. + Several ports can share a common directory. In that + case, PLIST_DIRS should be replaced by + PLIST_DIRSTRY so that the directory is + removed only if empty, otherwise it is silently ignored. + PLIST_DIRS and + PLIST_DIRSTRY are equivalent to using + @dirrm and @dirrmtry + in pkg-plist, as described in + . - One more time, do not include the original - source distfile, the work directory, or - the package you built with - make package; and, do use - &man.shar.1; for new ports, not &man.diff.1;. - - After submitting the port, please be patient. The time - needed to include a new port in &os; can vary from a few days - to a few months. The list of pending port - PRs can be viewed at . - - After looking at the new port, we will reply if necessary, - and put it in the tree. Your name will also be added to the - list of Additional - &os; Contributors and other files. - - + The price for this way of listing port's files and + directories is that you cannot use command sequences + described in &man.pkg-create.8;. Therefore, it is suitable + only for simple ports and makes them even simpler. At the + same time, it has the advantage of reducing the number of + files in the ports collection. Please consider using this + technique before you resort to + pkg-plist. + + Later we will see how pkg-plist + and PLIST_FILES can be used to fulfill + more sophisticated + tasks. + + + + + Creating the Checksum File + + Just type make makesum. The ports make + rules will automatically generate the file + distinfo. + + If a file fetched has its checksum changed regularly and + you are certain the source is trusted (i.e., it comes from + manufacturer CDs or documentation generated daily), you should + specify these files in the IGNOREFILES + variable. Then the checksum is not calculated for that file + when you run make makesum, but set to + IGNORE. + + + + Testing the Port + + You should make sure that the port rules do exactly what + you want them to do, including packaging up the port. These + are the important points you need to verify. + + + + pkg-plist does not contain + anything not installed by the port. + + + + pkg-plist contains everything + that is installed by the port. + + + + The port can be installed using the + install target. This verifies + that the install script works correctly. + + + + The port can be deinstalled properly using the + deinstall target. This + verifies that the deinstall script works correctly. + + + + Make sure that make package can be + run as a normal user (that is, not as + root). If that + fails, NEED_ROOT=yes must be added to + the port Makefile. + + + + + Recommended Test Ordering + + + make stage + + + + make check-orphans + + + + make package + + + + make install + + + + make deinstall + + + + pkg add package-filename + + + + make package (as user) + + + + Make certain no warnings are shown in any of + the stages. + + Thorough automated testing can be done with + ports-mgmt/tinderbox or + ports-mgmt/poudriere from the + Ports Collection. These applications maintain + jails where all of the steps shown above + can be tested without affecting the state of the host + system. + + + + Checking Your Port with + <command>portlint</command> + + Please use portlint to see if your port + conforms to our guidelines. The + ports-mgmt/portlint + program is part of the ports collection. In particular, you + may want to check if the + Makefile is in the + right shape and the + package is named + appropriately. + + + + Submitting the New Port + + Before submitting the new port, read the + DOs and DON'Ts + section. + + Once happy with your port, the only thing remaining is to + put it in the main &os; ports tree and make everybody else + happy about it too. We do not need the + work directory or the + pkgname.tgz package, so delete them + now. + + Next, build the &man.shar.1; file. Assuming the port is + called oneko, cd to the + directory above where the oneko directory + is located, and then type: + shar `find oneko` > oneko.shar + + Include oneko.shar in a bug + report and send it with &man.send-pr.1;. See Bug + Reports and General Commentary for more information + about &man.send-pr.1;. + + Classify the bug report as Category + ports and Class + change-request. Do not + mark the report confidential! Add a short + description of the program to the Description field of the PR + (perhaps a short version of the COMMENT), and + add the .shar file to the Fix field. + + + Giving a good description in the synopsis of the problem + report makes the work of port committers a lot easier. We + prefer something like New port: + <category>/<portname> <short description of + the port> for new ports. Using this + scheme makes it easier and faster to begin the work of + committing the new port. + + One more time, do not include the original + source distfile, the work directory, or + the package you built with + make package; and, do use + &man.shar.1; for new ports, not &man.diff.1;. + + After submitting the port, please be patient. The time + needed to include a new port in &os; can vary from a few days + to a few months. The list of pending port + PRs can be viewed at . + + After looking at the new port, we will reply if necessary, + and put it in the tree. Your name will also be added to the + list of Additional + &os; Contributors and other files. + + From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 02:24:39 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 044CBC61; Sun, 16 Feb 2014 02:24:39 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF31E1F71; Sun, 16 Feb 2014 02:24:38 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G2OciE047741; Sun, 16 Feb 2014 02:24:38 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G2Ocar047740; Sun, 16 Feb 2014 02:24:38 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160224.s1G2Ocar047740@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 02:24:38 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43953 - head/en_US.ISO8859-1/books/porters-handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 02:24:39 -0000 Author: wblock Date: Sun Feb 16 02:24:38 2014 New Revision: 43953 URL: http://svnweb.freebsd.org/changeset/doc/43953 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Sun Feb 16 02:10:29 2014 (r43952) +++ head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Sun Feb 16 02:24:38 2014 (r43953) @@ -4,160 +4,159 @@ $FreeBSD$ --> - + + + Security + + + Why Security is So Important + + Bugs are occasionally introduced to the software. Arguably, + the most dangerous of them are those opening security + vulnerabilities. From the technical viewpoint, such + vulnerabilities are to be closed by exterminating the bugs that + caused them. However, the policies for handling mere bugs and + security vulnerabilities are very different. + + A typical small bug affects only those users who have + enabled some combination of options triggering the bug. The + developer will eventually release a patch followed by a new + version of the software, free of the bug, but the majority of + users will not take the trouble of upgrading immediately because + the bug has never vexed them. A critical bug that may cause + data loss represents a graver issue. Nevertheless, prudent + users know that a lot of possible accidents, besides software + bugs, are likely to lead to data loss, and so they make backups + of important data; in addition, a critical bug will be + discovered really soon. + + A security vulnerability is all different. First, it may + remain unnoticed for years because often it does not cause + software malfunction. Second, a malicious party can use it to + gain unauthorized access to a vulnerable system, to destroy or + alter sensitive data; and in the worst case the user will not + even notice the harm caused. Third, exposing a vulnerable + system often assists attackers to break into other systems that + could not be compromised otherwise. Therefore closing a + vulnerability alone is not enough: the audience should be + notified of it in most clear and comprehensive manner, which + will allow to evaluate the danger and take appropriate + actions. + + + + Fixing Security Vulnerabilities + + While on the subject of ports and packages, a security + vulnerability may initially appear in the original distribution + or in the port files. In the former case, the original software + developer is likely to release a patch or a new version + instantly, and you will only need to update the port promptly + with respect to the author's fix. If the fix is delayed for + some reason, you should either + mark the port as + FORBIDDEN or introduce a patch file of + your own to the port. In the case of a vulnerable port, just + fix the port as soon as possible. In either case, + the standard procedure for + submitting your change should be followed unless you have + rights to commit it directly to the ports tree. + + + Being a ports committer is not enough to commit to an + arbitrary port. Remember that ports usually have maintainers, + whom you should respect. + + + Please make sure that the port's revision is bumped as soon + as the vulnerability has been closed. That is how the users who + upgrade installed packages on a regular basis will see they need + to run an update. Besides, a new package will be built and + distributed over FTP and WWW mirrors, replacing the vulnerable + one. PORTREVISION should be bumped unless + PORTVERSION has changed in the course of + correcting the vulnerability. That is you should bump + PORTREVISION if you have added a patch file + to the port, but you should not if you have updated the port to + the latest software version and thus already touched + PORTVERSION. Please refer to the + corresponding + section for more information. + + + + Keeping the Community Informed + + + The VuXML Database + + A very important and urgent step to take as early after a + security vulnerability is discovered as possible is to notify + the community of port users about the jeopardy. Such + notification serves two purposes. First, should the danger be + really severe it will be wise to apply an instant workaround. + E.g., stop the affected network service or even deinstall the + port completely until the vulnerability is closed. Second, a + lot of users tend to upgrade installed packages only + occasionally. They will know from the notification that they + must update the package without delay as + soon as a corrected version is available. + + Given the huge number of ports in the tree, a security + advisory cannot be issued on each incident without creating a + flood and losing the attention of the audience when it comes + to really serious matters. Therefore security vulnerabilities + found in ports are recorded in + the &os; + VuXML database. The Security Officer Team members + also monitor it for issues requiring their + intervention. + + If you have committer rights you can update the VuXML + database by yourself. So you will both help the Security + Officer Team and deliver the crucial information to the + community earlier. However, if you are not a committer, or + you believe you have found an exceptionally severe + vulnerability please do not hesitate to contact the Security + Officer Team directly as described on the + &os; + Security Information page. + + The VuXML database is an XML document. + Its source file vuln.xml is kept right + inside the port security/vuxml. + Therefore the file's full pathname will be + PORTSDIR/security/vuxml/vuln.xml. Each + time you discover a security vulnerability in a port, please + add an entry for it to that file. Until you are familiar with + VuXML, the best thing you can do is to find an existing entry + fitting your case, then copy it and use it as a + template. + + + + A Short Introduction to VuXML + + The full-blown XML format is complex, + and far beyond the scope of this book. However, to gain basic + insight on the structure of a VuXML entry you need only the + notion of tags. XML tag names are enclosed in angle brackets. + Each opening <tag> must have a matching closing + </tag>. Tags may be nested. If nesting, the inner tags + must be closed before the outer ones. There is a hierarchy of + tags, i.e., more complex rules of nesting them. This is + similar to HTML. The major difference is that XML is + eXtensible, i.e., based on defining + custom tags. Due to its intrinsic structure XML puts + otherwise amorphous data into shape. VuXML is particularly + tailored to mark up descriptions of security + vulnerabilities. - Security + Now consider a realistic VuXML entry: - - Why Security is So Important - - Bugs are occasionally introduced to the software. - Arguably, the most dangerous of them are those opening - security vulnerabilities. From the technical viewpoint, such - vulnerabilities are to be closed by exterminating the bugs - that caused them. However, the policies for handling mere - bugs and security vulnerabilities are very different. - - A typical small bug affects only those users who have - enabled some combination of options triggering the bug. The - developer will eventually release a patch followed by a new - version of the software, free of the bug, but the majority of - users will not take the trouble of upgrading immediately - because the bug has never vexed them. A critical bug that may - cause data loss represents a graver issue. Nevertheless, - prudent users know that a lot of possible accidents, besides - software bugs, are likely to lead to data loss, and so they - make backups of important data; in addition, a critical bug - will be discovered really soon. - - A security vulnerability is all different. First, it may - remain unnoticed for years because often it does not cause - software malfunction. Second, a malicious party can use it to - gain unauthorized access to a vulnerable system, to destroy or - alter sensitive data; and in the worst case the user will not - even notice the harm caused. Third, exposing a vulnerable - system often assists attackers to break into other systems - that could not be compromised otherwise. Therefore closing a - vulnerability alone is not enough: the audience should be - notified of it in most clear and comprehensive manner, which - will allow to evaluate the danger and take appropriate - actions. - - - - Fixing Security Vulnerabilities - - While on the subject of ports and packages, a security - vulnerability may initially appear in the original - distribution or in the port files. In the former case, the - original software developer is likely to release a patch or a - new version instantly, and you will only need to update the - port promptly with respect to the author's fix. If the fix is - delayed for some reason, you should either - mark the port as - FORBIDDEN or introduce a patch file - of your own to the port. In the case of a vulnerable port, - just fix the port as soon as possible. In either case, - the standard procedure for - submitting your change should be followed unless you - have rights to commit it directly to the ports tree. - - - Being a ports committer is not enough to commit to - an arbitrary port. Remember that ports usually have - maintainers, whom you should respect. - - - Please make sure that the port's revision is bumped - as soon as the vulnerability has been closed. - That is how the users who upgrade installed packages - on a regular basis will see they need to run an update. - Besides, a new package will be built and distributed - over FTP and WWW mirrors, replacing the vulnerable one. - PORTREVISION should be bumped unless - PORTVERSION has changed in the course - of correcting the vulnerability. That is you should - bump PORTREVISION if you have added a - patch file to the port, but you should not if you have updated - the port to the latest software version and thus already - touched PORTVERSION. Please refer to the - corresponding - section for more information. - - - - Keeping the Community Informed - - - The VuXML Database - - A very important and urgent step to take as early after - a security vulnerability is discovered as possible is to - notify the community of port users about the jeopardy. Such - notification serves two purposes. First, should the danger - be really severe it will be wise to apply an instant - workaround. E.g., stop the affected network service or even - deinstall the port completely until the vulnerability is - closed. Second, a lot of users tend to upgrade installed - packages only occasionally. They will know from the - notification that they must update the - package without delay as soon as a corrected version is - available. - - Given the huge number of ports in the tree, a security - advisory cannot be issued on each incident without creating - a flood and losing the attention of the audience when it - comes to really serious matters. Therefore security - vulnerabilities found in ports are recorded in - the &os; - VuXML database. The Security Officer Team members - also monitor it for issues requiring their - intervention. - - If you have committer rights you can update the VuXML - database by yourself. So you will both help the Security - Officer Team and deliver the crucial information to the - community earlier. However, if you are not a committer, or - you believe you have found an exceptionally severe - vulnerability please do not hesitate to contact the Security - Officer Team directly as described on the &os; - Security Information page. - - The VuXML database is an XML - document. Its source file vuln.xml is - kept right inside the port - security/vuxml. Therefore - the file's full pathname will be - PORTSDIR/security/vuxml/vuln.xml. Each - time you discover a security vulnerability in a port, please - add an entry for it to that file. Until you are familiar - with VuXML, the best thing you can do is to find an existing - entry fitting your case, then copy it and use it as a - template. - - - - A Short Introduction to VuXML - - The full-blown XML format is complex, - and far beyond the scope of this book. However, to gain - basic insight on the structure of a VuXML entry you need - only the notion of tags. XML tag names are enclosed in - angle brackets. Each opening <tag> must have a - matching closing </tag>. Tags may be nested. If - nesting, the inner tags must be closed before the outer - ones. There is a hierarchy of tags, i.e., more complex - rules of nesting them. This is similar to HTML. The major - difference is that XML is eXtensible, - i.e., based on defining custom tags. Due to its intrinsic - structure XML puts otherwise amorphous data into shape. - VuXML is particularly tailored to mark up descriptions of - security vulnerabilities. - - Now consider a realistic VuXML entry: - - <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> + <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <topic>Several vulnerabilities found in Foo</topic> <affects> <package> @@ -206,314 +205,300 @@ </dates> </vuln> - The tag names are supposed to be self-explanatory so we - shall take a closer look only at fields you will need to - fill in by yourself: - - - - This is the top-level tag of a VuXML entry. It has - a mandatory attribute, vid, - specifying a universally unique identifier (UUID) for - this entry (in quotes). You should generate a UUID for - each new VuXML entry (and do not forget to substitute it - for the template UUID unless you are writing the entry - from scratch). You can use &man.uuidgen.1; to generate - a VuXML UUID. - - - - This is a one-line description of the issue - found. - - - - The names of packages affected are listed there. - Multiple names can be given since several packages may - be based on a single master port or software product. - This may include stable and development branches, - localized versions, and slave ports featuring different - choices of important build-time configuration - options. - - - It is your responsibility to find all such related - packages when writing a VuXML entry. Keep in mind - that make search name=foo is your - friend. The primary points to look for are as - follows: - - - - the foo-devel variant - for a foo port; - - - - other variants with a suffix like - -a4 (for print-related - packages), -without-gui (for - packages with X support disabled), or - similar; - - - - jp-, - ru-, zh-, - and other possible localized variants in the - corresponding national categories of the ports - collection. - - - - - - - Affected versions of the package(s) are specified - there as one or more ranges using a combination of - <lt>, - <le>, - <eq>, - <ge>, and - <gt> elements. The version - ranges given should not overlap. - - In a range specification, * - (asterisk) denotes the smallest version number. In - particular, 2.* is less than - 2.a. Therefore an asterisk may be - used for a range to match all possible - alpha, beta, and - RC versions. For instance, - <ge>2.*</ge><lt>3.*</lt> - will selectively match every 2.x - version while - <ge>2.0</ge><lt>3.0</lt> - will not since the latter misses - 2.r3 and matches - 3.b. - - The above example specifies that affected are - versions from 1.6 to - 1.9 inclusive, versions - 2.x before 2.4_1, - and version 3.0b1. - - - - Several related package groups (essentially, ports) - can be listed in the <affected> - section. This can be used if several software products - (say FooBar, FreeBar and OpenBar) grow from the same - code base and still share its bugs and vulnerabilities. - Note the difference from listing multiple names within a - single <package> section. - - - - The version ranges should allow for - PORTEPOCH and - PORTREVISION if applicable. Please - remember that according to the collation rules, a - version with a non-zero PORTEPOCH is - greater than any version without - PORTEPOCH, e.g., - 3.0,1 is greater than - 3.1 or even than - 8.9. - - - - This is a summary of the issue. XHTML is used in - this field. At least enclosing - <p> and - </p> should appear. More - complex mark-up may be used, but only for the sake of - accuracy and clarity: No eye candy please. - - - - This section contains references to relevant - documents. As many references as apply are - encouraged. - - - - This is a &os; - security advisory. - - - - This is a &os; - problem report. - - - - This is a - MITRE - CVE identifier. - - - - This is a SecurityFocus - Bug ID. - - - - This is a - US-CERT - security advisory. - - - - This is a - US-CERT - vulnerability note. - - - - This is a - US-CERT - Cyber Security Alert. - - - - This is a - US-CERT - Technical Cyber Security Alert. - - - - This is a URL to an archived posting in a mailing - list. The attribute msgid is - optional and may specify the message ID of the - posting. - - - - This is a generic URL. It should be used only if - none of the other reference categories apply. - - - - This is the date when the issue was disclosed - (YYYY-MM-DD). - - - - This is the date when the entry was added - (YYYY-MM-DD). - - - - This is the date when any information in the entry - was last modified - (YYYY-MM-DD). New entries - must not include this field. It should be added upon - editing an existing entry. - - - - - - Testing Your Changes to the VuXML Database - - Assume you just wrote or filled in an entry for a - vulnerability in the package clamav that - has been fixed in version 0.65_7. - - As a prerequisite, you need to - install fresh versions of the ports - ports-mgmt/portaudit, - ports-mgmt/portaudit-db, - and - security/vuxml. - - - To run packaudit you must have - permission to write to its - DATABASEDIR, - typically /var/db/portaudit. - - To use a different directory set the - DATABASEDIR - environment variable to a different location. - - If you are working in a directory other than - ${PORTSDIR}/security/vuxml set the - VUXMLDIR - environment variable to the directory where - vuln.xml is located. - - - First, check whether there already is an entry for this - vulnerability. If there were such an entry, it would match - the previous version of the package, - 0.65_6: + The tag names are supposed to be self-explanatory so we + shall take a closer look only at fields you will need to fill + in by yourself: + + + + This is the top-level tag of a VuXML entry. It has a + mandatory attribute, vid, specifying a + universally unique identifier (UUID) for this entry (in + quotes). You should generate a UUID for each new VuXML + entry (and do not forget to substitute it for the template + UUID unless you are writing the entry from scratch). You + can use &man.uuidgen.1; to generate a VuXML UUID. + + + + This is a one-line description of the issue + found. + + + + The names of packages affected are listed there. + Multiple names can be given since several packages may be + based on a single master port or software product. This + may include stable and development branches, localized + versions, and slave ports featuring different choices of + important build-time configuration options. + + + It is your responsibility to find all such related + packages when writing a VuXML entry. Keep in mind that + make search name=foo is your friend. + The primary points to look for are as follows: + + + + the foo-devel variant for a + foo port; + + + + other variants with a suffix like + -a4 (for print-related packages), + -without-gui (for packages with X + support disabled), or similar; + + + + jp-, ru-, + zh-, and other possible localized + variants in the corresponding national categories of + the ports collection. + + + + + + + Affected versions of the package(s) are specified + there as one or more ranges using a combination of + <lt>, + <le>, + <eq>, + <ge>, and + <gt> elements. The version + ranges given should not overlap. + + In a range specification, * + (asterisk) denotes the smallest version number. In + particular, 2.* is less than + 2.a. Therefore an asterisk may be used + for a range to match all possible + alpha, beta, and + RC versions. For instance, + <ge>2.*</ge><lt>3.*</lt> + will selectively match every 2.x + version while + <ge>2.0</ge><lt>3.0</lt> + will not since the latter misses 2.r3 + and matches 3.b. + + The above example specifies that affected are versions + from 1.6 to 1.9 + inclusive, versions 2.x before + 2.4_1, and version + 3.0b1. + + + + Several related package groups (essentially, ports) + can be listed in the <affected> + section. This can be used if several software products + (say FooBar, FreeBar and OpenBar) grow from the same code + base and still share its bugs and vulnerabilities. Note + the difference from listing multiple names within a single + <package> section. + + + + The version ranges should allow for + PORTEPOCH and + PORTREVISION if applicable. Please + remember that according to the collation rules, a version + with a non-zero PORTEPOCH is greater + than any version without PORTEPOCH, + e.g., 3.0,1 is greater than + 3.1 or even than + 8.9. + + + + This is a summary of the issue. XHTML is used in this + field. At least enclosing <p> + and </p> should appear. More + complex mark-up may be used, but only for the sake of + accuracy and clarity: No eye candy please. + + + + This section contains references to relevant + documents. As many references as apply are + encouraged. + + + + This is a &os; + security advisory. + + + + This is a &os; + problem report. + + + + This is a + MITRE + CVE identifier. + + + + This is a SecurityFocus + Bug ID. + + + + This is a + US-CERT + security advisory. + + + + This is a + US-CERT + vulnerability note. + + + + This is a + US-CERT + Cyber Security Alert. + + + + This is a + US-CERT + Technical Cyber Security Alert. + + + + This is a URL to an archived posting in a mailing + list. The attribute msgid is optional + and may specify the message ID of the posting. + + + + This is a generic URL. It should be used only if none + of the other reference categories apply. + + + + This is the date when the issue was disclosed + (YYYY-MM-DD). + + + + This is the date when the entry was added + (YYYY-MM-DD). + + + + This is the date when any information in the entry was + last modified (YYYY-MM-DD). + New entries must not include this field. It should be + added upon editing an existing entry. + + + + + + Testing Your Changes to the VuXML Database + + Assume you just wrote or filled in an entry for a + vulnerability in the package clamav that + has been fixed in version 0.65_7. + + As a prerequisite, you need to + install fresh versions of the ports + ports-mgmt/portaudit, + ports-mgmt/portaudit-db, and + security/vuxml. + + + To run packaudit you must have + permission to write to its DATABASEDIR, + typically /var/db/portaudit. + + To use a different directory set the + DATABASEDIR environment variable to a + different location. + + If you are working in a directory other than + ${PORTSDIR}/security/vuxml set the + VUXMLDIR environment variable to the + directory where vuln.xml is + located. + + + First, check whether there already is an entry for this + vulnerability. If there were such an entry, it would match + the previous version of the package, + 0.65_6: - &prompt.user; packaudit + &prompt.user; packaudit &prompt.user; portaudit clamav-0.65_6 - If there is none found, you have the green light to add - a new entry for this vulnerability. + If there is none found, you have the green light to add a + new entry for this vulnerability. - &prompt.user; cd ${PORTSDIR}/security/vuxml + &prompt.user; cd ${PORTSDIR}/security/vuxml &prompt.user; make newentry - When you are done verify its syntax and - formatting. + When you are done verify its syntax and formatting. - &prompt.user; make validate + &prompt.user; make validate - - You will need at least one of the following packages - installed: - textproc/libxml2, - textproc/jade. - + + You will need at least one of the following packages + installed: textproc/libxml2, + textproc/jade. + - Now rebuild the portaudit database - from the VuXML file: + Now rebuild the portaudit database from + the VuXML file: - &prompt.user; packaudit + &prompt.user; packaudit - To verify that the <affected> - section of your entry will match correct package(s), issue - the following command: + To verify that the <affected> + section of your entry will match correct package(s), issue the + following command: - &prompt.user; portaudit -f /usr/ports/INDEX -r uuid + &prompt.user; portaudit -f /usr/ports/INDEX -r uuid - - Please refer to &man.portaudit.1; for better - understanding of the command syntax. - + + Please refer to &man.portaudit.1; for better + understanding of the command syntax. + - Make sure that your entry produces no spurious matches - in the output. + Make sure that your entry produces no spurious matches in + the output. - Now check whether the right package versions are matched - by your entry: + Now check whether the right package versions are matched + by your entry: - &prompt.user; portaudit clamav-0.65_6 clamav-0.65_7 + &prompt.user; portaudit clamav-0.65_6 clamav-0.65_7 Affected package: clamav-0.65_6 (matched by clamav<0.65_7) Type of problem: clamav remote denial-of-service. Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html> 1 problem(s) found. - The former version should match while the latter one - should not. + The former version should match while the latter one + should not. - Finally, verify whether the web page generated from the - VuXML database looks like expected: + Finally, verify whether the web page generated from the + VuXML database looks like expected: - &prompt.user; mkdir -p ~/public_html/portaudit + &prompt.user; mkdir -p ~/public_html/portaudit &prompt.user; packaudit &prompt.user; lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html - - - + + + From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 02:39:13 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B447FF33; Sun, 16 Feb 2014 02:39:13 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AC621062; Sun, 16 Feb 2014 02:39:13 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G2dDYv052952; Sun, 16 Feb 2014 02:39:13 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G2dDF0052951; Sun, 16 Feb 2014 02:39:13 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160239.s1G2dDF0052951@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 02:39:13 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43954 - head/en_US.ISO8859-1/books/porters-handbook/slow-porting X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 02:39:13 -0000 Author: wblock Date: Sun Feb 16 02:39:13 2014 New Revision: 43954 URL: http://svnweb.freebsd.org/changeset/doc/43954 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml Sun Feb 16 02:24:38 2014 (r43953) +++ head/en_US.ISO8859-1/books/porters-handbook/slow-porting/chapter.xml Sun Feb 16 02:39:13 2014 (r43954) @@ -4,427 +4,414 @@ $FreeBSD$ --> - + + + Slow Porting + + Okay, so it was not that simple, and the port required some + modifications to get it to work. In this section, we will + explain, step by step, how to modify it to get it to work with the + ports paradigm. + + + How Things Work + + First, this is the sequence of events which occurs when the + user first types make in your port's + directory. You may find that having + bsd.port.mk in another window while you + read this really helps to understand it. + + But do not worry if you do not really understand what + bsd.port.mk is doing, not many people do... + :-) + + + + The fetch target is run. The + fetch target is responsible for + making sure that the tarball exists locally in + DISTDIR. If + fetch cannot find the required + files in DISTDIR it will look up the URL + MASTER_SITES, which is set in the + Makefile, as well as our FTP mirrors where we put distfiles + as backup. It will then attempt to fetch the named + distribution file with FETCH, assuming + that the requesting site has direct access to the Internet. + If that succeeds, it will save the file in + DISTDIR for future use and + proceed. + + + + The extract target is run. + It looks for your port's distribution file (typically a + gzipped tarball) in + DISTDIR and unpacks it into a temporary + subdirectory specified by WRKDIR + (defaults to work). + + + + The patch target is run. + First, any patches defined in PATCHFILES + are applied. Second, if any patch files named + patch-* are found in + PATCHDIR (defaults to the + files subdirectory), they are applied + at this time in alphabetical order. + + + + The configure target is run. + This can do any one of many different things. + + + + If it exists, scripts/configure + is run. + + + + If HAS_CONFIGURE or + GNU_CONFIGURE is set, + WRKSRC/configure is run. + + + + + + The build target is run. + This is responsible for descending into the port's private + working directory (WRKSRC) and building + it. + + + + The stage target is run. + This puts the final set of built files into a temporary + directory (STAGEDIR, see + ). The hierarchy of this directory + mirrors that of the system on which the package will be + installed. + + + + The install target is run. + This copies the files listed in the port's pkg-plist to the + host system. + + + + The above are the default actions. In addition, you can + define targets + pre-something + or + post-something, + or put scripts with those names, in the + scripts subdirectory, and they will be + run before or after the default actions are done. + + For example, if you have a + post-extract target defined in your + Makefile, and a file + pre-build in the + scripts subdirectory, the + post-extract target will be called + after the regular extraction actions, and the + pre-build script will be executed before + the default build rules are done. It is recommended that you + use Makefile targets if the actions are + simple enough, because it will be easier for someone to figure + out what kind of non-default action the port requires. + + The default actions are done by the + bsd.port.mk targets + do-something. + For example, the commands to extract a port are in the target + do-extract. If you are not happy + with the default target, you can fix it by redefining the + do-something + target in your Makefile. + + + The main targets (e.g., + extract, + configure, etc.) do nothing more + than make sure all the stages up to that one are completed and + call the real targets or scripts, and they are not intended to + be changed. If you want to fix the extraction, fix + do-extract, but never ever change + the way extract operates! + Additionally, the target + post-deinstall is invalid and is + not run by the ports infrastructure. + + + Now that you understand what goes on when the user types + make install, let us go through the + recommended steps to create the perfect port. + + + + Getting the Original Sources + + Get the original sources (normally) as a compressed tarball + (foo.tar.gz or + foo.tar.bz2) and copy it into + DISTDIR. Always use + mainstream sources when and where you + can. + + You will need to set the variable + MASTER_SITES to reflect where the original + tarball resides. You will find convenient shorthand definitions + for most mainstream sites in bsd.sites.mk. + Please use these sites—and the associated + definitions—if at all possible, to help avoid the problem + of having the same information repeated over again many times in + the source base. As these sites tend to change over time, this + becomes a maintenance nightmare for everyone involved. + + If you cannot find a FTP/HTTP site that is well-connected to + the net, or can only find sites that have irritatingly + non-standard formats, you might want to put a copy on a reliable + FTP or HTTP server that you control (e.g., your home + page). + + If you cannot find somewhere convenient and reliable to put + the distfile we can house it ourselves on + ftp.FreeBSD.org; however, this is the + least-preferred solution. The distfile must be placed into + ~/public_distfiles/ of someone's + freefall account. Ask the person who + commits your port to do this. This person will also set + MASTER_SITES to + MASTER_SITE_LOCAL and + MASTER_SITE_SUBDIR to their + freefall username. + + If your port's distfile changes all the time without any + kind of version update by the author, consider putting the + distfile on your home page and listing it as the first + MASTER_SITES. If you can, try to talk the + port author out of doing this; it really does help to establish + some kind of source code control. Hosting your own version will + prevent users from getting + checksum mismatch errors, and also reduce + the workload of maintainers of our FTP site. Also, if there is + only one master site for the port, it is recommended that you + house a backup at your site and list it as the second + MASTER_SITES. + + If your port requires some additional `patches' that are + available on the Internet, fetch them too and put them in + DISTDIR. Do not worry if they come from a + site other than where you got the main source tarball, we have a + way to handle these situations (see the description of PATCHFILES below). + + + + Modifying the Port + + Unpack a copy of the tarball in a private directory and make + whatever changes are necessary to get the port to compile + properly under the current version of &os;. Keep + careful track of everything you do, as you + will be automating the process shortly. Everything, including + the deletion, addition, or modification of files should be + doable using an automated script or patch file when your port is + finished. + + If your port requires significant user + interaction/customization to compile or install, you should take + a look at one of Larry Wall's classic + Configure scripts and perhaps do + something similar yourself. The goal of the new ports + collection is to make each port as plug-and-play + as possible for the end-user while using a minimum of disk + space. + + + Unless explicitly stated, patch files, scripts, and other + files you have created and contributed to the &os; ports + collection are assumed to be covered by the standard BSD + copyright conditions. + + + + + Patching + + In the preparation of the port, files that have been added + or changed can be recorded with &man.diff.1; for later feeding + to &man.patch.1;. Doing this with a typical file involves + saving a copy of the original file before making any + changes. + + &prompt.user; cp file file.orig + + Patches are saved into files named + patch-* where * + indicates the pathname of the file that is patched, such as + patch-Imakefile or + patch-src-config.h. + + After the file has been modified, &man.diff.1; is used to + record the differences between the original and the modified + version. causes &man.diff.1; to produce + unified diffs, the preferred form. + + &prompt.user; diff -u file.orig file > patch-pathname-file + + When generating patches for new, added files, + is added to tell &man.diff.1; to treat the + non-existent original file as if it existed but was + empty: + + &prompt.user; diff -u -N newfile.orig newfile > patch-pathname-newfile + + Patch files are stored in PATCHDIR + (usually files/, from + where they will be automatically applied. All patches must be + relative to WRKSRC (generally the directory + the port's tarball unpacks itself into, that being where the + build is done). To make fixes and upgrades easier, avoid having + more than one patch fix the same file (that is, + patch-file and + patch-file2 both changing + WRKSRC/foobar.c). Note that if the path of + a patched file contains an underscore (_) + character, the patch needs to have two underscores instead in + its name. For example, to patch a file named + src/freeglut_joystick.c, the corresponding + patch should be named + patch-src-freeglut__joystick.c. + + Please only use characters + [-+._a-zA-Z0-9] for naming patches. Do not + use any other characters besides them. Do not name patches like + patch-aa or patch-ab, + always mention the path and file name in patch names. + + There is an alternate, easier method for creating patches to + existing files. The first steps are the same, make a copy of + the unmodified file with an .orig + extension, then make modifications. Then use + make makepatch to write updated patch files + to the files directory of the port. + + Do not put RCS strings in patches. + Subversion will mangle them when we + put the files into the ports tree, and when we check them out + again, they will come out different and the patch will fail. + RCS strings are surrounded by dollar + ($) signs, and typically start with + $Id or + $RCS. + + Using the recurse () option to + &man.diff.1; to generate patches is fine, but please look at the + resulting patches to make sure there is no unnecessary junk in + there. In particular, diffs between two backup files, + Makefiles when the port uses + Imake or GNU configure, + etc., are unnecessary and should be deleted. If it was + necessary to edit configure.in and run + autoconf to regenerate + configure, do not take the diffs of + configure (it often grows to a few thousand + lines!). Instead, define + USE_AUTOTOOLS=autoconf:261 and take the diffs + of configure.in. + + Try to minimize the amount of non-functional whitespace + changes in patches. It is common in the Open Source world for + projects to share large amounts of a code base, but obey + different style and indenting rules. When taking a working + piece of functionality from one project to fix similar areas in + another, please be careful: the resulting line patch may be full + of non-functional changes. It not only increases the size of + the Subversion repository but makes + it hard to find out what exactly caused the problem and what was + changed at all. + + If a file must be deleted, do it in the + post-extract target rather than as + part of the patch. + + Simple replacements can be performed directly from the port + Makefile using the in-place mode of + &man.sed.1;. This is useful when changes use the value of a + variable: + + post-patch: + @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README + + Quite often, software being ported uses the CR/LF convention + in source files. This may cause problems with further patching, + compiler warnings, or script execution (like + /bin/sh^M not found.) To quickly convert all + files from CR/LF to just LF, add this entry to the port + Makefile: - Slow Porting + USES= dos2unix - Okay, so it was not that simple, and the port required some - modifications to get it to work. In this section, we will - explain, step by step, how to modify it to get it to work with - the ports paradigm. - - - How Things Work - - First, this is the sequence of events which occurs when - the user first types make in your port's - directory. You may find that having - bsd.port.mk in another window while you - read this really helps to understand it. - - But do not worry if you do not really understand what - bsd.port.mk is doing, not many people - do... :-) - - - - The fetch target is run. - The fetch target is responsible - for making sure that the tarball exists locally in - DISTDIR. If - fetch cannot find the required - files in DISTDIR it will look up the - URL MASTER_SITES, which is set in the - Makefile, as well as our FTP mirrors where we put - distfiles as backup. It will then attempt to fetch the - named distribution file with FETCH, - assuming that the requesting site has direct access to the - Internet. If that succeeds, it will save the file in - DISTDIR for future use and - proceed. - - - - The extract target is run. - It looks for your port's distribution file (typically a - gzipped tarball) in - DISTDIR and unpacks it into a temporary - subdirectory specified by WRKDIR - (defaults to work). - - - - The patch target is run. - First, any patches defined in - PATCHFILES are applied. Second, if any - patch files named - patch-* - are found in PATCHDIR (defaults to the - files subdirectory), they are applied - at this time in alphabetical order. - - - - The configure target is - run. This can do any one of many different things. - - - - If it exists, - scripts/configure is run. - - - - If HAS_CONFIGURE or - GNU_CONFIGURE is set, - WRKSRC/configure - is run. - - - - - - - The build target is run. - This is responsible for descending into the port's private - working directory (WRKSRC) and building - it. - - - - The stage target is run. - This puts the final set of built files into a temporary - directory (STAGEDIR, see - ). The hierarchy of this - directory mirrors that of the system on which the package - will be installed. - - - - The install target is run. - This copies the files listed in the port's pkg-plist to - the host system. - - - - The above are the default actions. In addition, you can - define targets - pre-something - or - post-something, - or put scripts with those names, in the - scripts subdirectory, and they will be - run before or after the default actions are done. - - For example, if you have a - post-extract target defined in your - Makefile, and a file - pre-build in the - scripts subdirectory, the - post-extract target will be called - after the regular extraction actions, and the - pre-build script will be executed before - the default build rules are done. It is recommended that you - use Makefile targets if the actions are - simple enough, because it will be easier for someone to figure - out what kind of non-default action the port requires. - - The default actions are done by the - bsd.port.mk targets - do-something. - For example, the commands to extract a port are in the target - do-extract. If you are not happy - with the default target, you can fix it by redefining the - do-something - target in your Makefile. - - - The main targets (e.g., - extract, - configure, etc.) do nothing more - than make sure all the stages up to that one are completed - and call the real targets or scripts, and they are not - intended to be changed. If you want to fix the extraction, - fix do-extract, but never ever - change the way extract - operates! Additionally, the target - post-deinstall is invalid and - is not run by the ports infrastructure. - - - Now that you understand what goes on when the user types - make install, let - us go through the recommended steps to create the perfect - port. - - - - Getting the Original Sources - - Get the original sources (normally) as a compressed - tarball - (foo.tar.gz or - foo.tar.bz2) - and copy it into DISTDIR. Always use - mainstream sources when and where you - can. - - You will need to set the variable - MASTER_SITES to reflect where the original - tarball resides. You will find convenient shorthand - definitions for most mainstream sites in - bsd.sites.mk. Please use these - sites—and the associated definitions—if at all - possible, to help avoid the problem of having the same - information repeated over again many times in the source base. - As these sites tend to change over time, this becomes a - maintenance nightmare for everyone involved. - - If you cannot find a FTP/HTTP site that is well-connected - to the net, or can only find sites that have irritatingly - non-standard formats, you might want to put a copy on a - reliable FTP or HTTP server that you control (e.g., your home - page). - - If you cannot find somewhere convenient and reliable to - put the distfile we can house it ourselves on - ftp.FreeBSD.org; however, this is the - least-preferred solution. The distfile must be placed into - ~/public_distfiles/ of someone's - freefall account. Ask the person who - commits your port to do this. This person will also set - MASTER_SITES to - MASTER_SITE_LOCAL and - MASTER_SITE_SUBDIR to their - freefall username. - - If your port's distfile changes all the time without any - kind of version update by the author, consider putting the - distfile on your home page and listing it as the first - MASTER_SITES. If you can, try to talk the - port author out of doing this; it really does help to - establish some kind of source code control. Hosting your own - version will prevent users from getting - checksum mismatch errors, and also - reduce the workload of maintainers of our FTP site. Also, if - there is only one master site for the port, it is recommended - that you house a backup at your site and list it as the second - MASTER_SITES. - - If your port requires some additional `patches' that are - available on the Internet, fetch them too and put them in - DISTDIR. Do not worry if they come from a - site other than where you got the main source tarball, we have - a way to handle these situations (see the description of - PATCHFILES - below). - - - - Modifying the Port - - Unpack a copy of the tarball in a private directory and - make whatever changes are necessary to get the port to compile - properly under the current version of &os;. Keep - careful track of everything you do, as - you will be automating the process shortly. Everything, - including the deletion, addition, or modification of files - should be doable using an automated script or patch file when - your port is finished. - - If your port requires significant user - interaction/customization to compile or install, you should - take a look at one of Larry Wall's classic - Configure scripts and perhaps do - something similar yourself. The goal of the new ports - collection is to make each port as - plug-and-play as possible for the end-user - while using a minimum of disk space. - - - Unless explicitly stated, patch files, scripts, and - other files you have created and contributed to the &os; - ports collection are assumed to be covered by the standard - BSD copyright conditions. - - - - - Patching - - In the preparation of the port, files that have been added - or changed can be recorded with &man.diff.1; for later - feeding to &man.patch.1;. Doing this with a typical file - involves saving a copy of the original file before making any - changes. - - &prompt.user; cp file file.orig - - Patches are saved into files named - patch-* where - * indicates the pathname of the - file that is patched, such as - patch-Imakefile or - patch-src-config.h. - - After the file has been modified, &man.diff.1; is used to - record the differences between the original and the modified - version. causes &man.diff.1; to produce - unified diffs, the preferred form. - - &prompt.user; diff -u file.orig file > patch-pathname-file - - When generating patches for new, added files, - is added to tell &man.diff.1; to treat the - non-existent original file as if it existed but was - empty: - - &prompt.user; diff -u -N newfile.orig newfile > patch-pathname-newfile - - Patch files are stored in PATCHDIR - (usually files/, from - where they will be automatically applied. All patches must be - relative to WRKSRC (generally the directory - the port's tarball unpacks itself into, that being where the - build is done). To make fixes and upgrades easier, avoid - having more than one patch fix the same file (that is, - patch-file and - patch-file2 both changing - WRKSRC/foobar.c). Note that if the path - of a patched file contains an underscore - (_) character, the patch needs to have two - underscores instead in its name. For example, to patch a file - named src/freeglut_joystick.c, the - corresponding patch should be named - patch-src-freeglut__joystick.c. - - Please only use characters - [-+._a-zA-Z0-9] for naming patches. Do not - use any other characters besides them. Do not name patches - like patch-aa or - patch-ab, always mention the path and - file name in patch names. - - There is an alternate, easier method for creating patches - to existing files. The first steps are the same, make a copy - of the unmodified file with an .orig - extension, then make modifications. Then use - make makepatch to write updated patch files - to the files directory of the - port. - - Do not put RCS strings in patches. - Subversion will mangle them when we - put the files into the ports tree, and when we check them out - again, they will come out different and the patch will fail. - RCS strings are surrounded by dollar - ($) signs, and typically start with - $Id or - $RCS. - - Using the recurse () option to - &man.diff.1; to generate patches is fine, but please - look at the resulting patches to make sure there is no - unnecessary junk in there. In particular, diffs between two - backup files, Makefiles when the port - uses Imake or GNU - configure, etc., are unnecessary and should - be deleted. If it was necessary to edit - configure.in and run - autoconf to regenerate - configure, do not take the diffs of - configure (it often grows to a few thousand - lines!). Instead, define - USE_AUTOTOOLS=autoconf:261 and take the - diffs of configure.in. - - Try to minimize the amount of non-functional whitespace - changes in patches. It is common in the Open Source world for - projects to share large amounts of a code base, but obey - different style and indenting rules. When taking a working - piece of functionality from one project to fix similar areas - in another, please be careful: the resulting line patch may be - full of non-functional changes. It not only increases the - size of the Subversion repository - but makes it hard to find out what exactly caused the problem - and what was changed at all. - - If a file must be deleted, do it in the - post-extract target rather than as - part of the patch. - - Simple replacements can be performed directly from the - port Makefile using the in-place mode of - &man.sed.1;. This is useful when changes use the value of a - variable: - - post-patch: - @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README - - Quite often, software being ported uses the CR/LF - convention in source files. This may cause problems with - further patching, compiler warnings, or script execution (like - /bin/sh^M not found.) To quickly convert - all files from CR/LF to just LF, add this entry to the port - Makefile: + A list of specific files to convert can be given: - USES= dos2unix - - A list of specific files to convert can - be given: - - USES= dos2unix + USES= dos2unix DOS2UNIX_FILES= util.c util.h - Use DOS2UNIX_REGEX to convert a group - of files across subdirectories. Its argument is a - &man.find.1;-compatible regular expression. More on the - format is in &man.re.format.7;. This option is useful for - converting all files of a given extension. For example, - convert all source code files, leaving binary files - intact: + Use DOS2UNIX_REGEX to convert a group of + files across subdirectories. Its argument is a + &man.find.1;-compatible regular expression. More on the format + is in &man.re.format.7;. This option is useful for converting + all files of a given extension. For example, convert all source + code files, leaving binary files intact: - USES= dos2unix + USES= dos2unix DOS2UNIX_REGEX= .*\.([ch]|cpp) - A similar option is DOS2UNIX_GLOB, - which invokes find for each element listed - in it. + A similar option is DOS2UNIX_GLOB, which + invokes find for each element listed in + it. - USES= dos2unix + USES= dos2unix DOS2UNIX_GLOB= *.c *.cpp *.h - - - - Configuring + - Include any additional customization commands in your - configure script and save it in the - scripts subdirectory. As mentioned - above, you can also do this with Makefile - targets and/or scripts with the name - pre-configure or - post-configure. - - - - Handling User Input - - If your port requires user input to build, configure, or - install, you must set IS_INTERACTIVE in - your Makefile. This will allow - overnight builds to skip your port if the user - sets the variable BATCH in his environment (and - if the user sets the variable INTERACTIVE, then - only those ports requiring interaction - are built). This will save a lot of wasted time on the set of - machines that continually build ports (see below). - - It is also recommended that if there are reasonable - default answers to the questions, you check the - PACKAGE_BUILDING variable and turn off the - interactive script when it is set. This will allow us to - build the packages for CDROMs and FTP. - - + + Configuring + Include any additional customization commands in your + configure script and save it in the + scripts subdirectory. As mentioned above, + you can also do this with Makefile targets + and/or scripts with the name pre-configure + or post-configure. + + + + Handling User Input + + If your port requires user input to build, configure, or + install, you must set IS_INTERACTIVE in your + Makefile. This will allow + overnight builds to skip your port if the user + sets the variable BATCH in his environment (and + if the user sets the variable INTERACTIVE, then + only those ports requiring interaction are + built). This will save a lot of wasted time on the set of + machines that continually build ports (see below). + + It is also recommended that if there are reasonable default + answers to the questions, you check the + PACKAGE_BUILDING variable and turn off the + interactive script when it is set. This will allow us to build + the packages for CDROMs and FTP. + + From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 03:09:36 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E927B749; Sun, 16 Feb 2014 03:09:35 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4EBC15CD; Sun, 16 Feb 2014 03:09:35 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G39Z3C067187; Sun, 16 Feb 2014 03:09:35 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G39ZTv067184; Sun, 16 Feb 2014 03:09:35 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160309.s1G39ZTv067184@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 03:09:35 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43955 - head/en_US.ISO8859-1/books/porters-handbook/special X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 03:09:36 -0000 Author: wblock Date: Sun Feb 16 03:09:35 2014 New Revision: 43955 URL: http://svnweb.freebsd.org/changeset/doc/43955 Log: Update and expand description of various make(1) implementations. Revised version of patch supplied. Submitted by: Alexey Dokuchaev Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 02:39:13 2014 (r43954) +++ head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 03:09:35 2014 (r43955) @@ -313,39 +313,34 @@ IGNORE= may not be redistributed because - <command>make</command>, <command>gmake</command>, and - <command>imake</command> + <command>make</command>, <command>gmake</command>, + <command>fmake</command>, and <command>imake</command> - If your port uses GNU make, - set USES= gmake. - - - Variables for Ports Related to - <application>gmake</application> - - - - - Variable - Means - - - - - - USES= gmake - The port requires gmake to - build. - - - - GMAKE - The full path for gmake if - it is not in the PATH. - - - -
+ Several differing make + implementations exist. Ported software often requires a + particular implementation, like GNU + make, known in &os; as + gmake, or fmake, the + legacy &os; make. + + If the port uses GNU make, + add gmake to USES. If + the legacy &os; make is needed, add + fmake there. + + MAKE_CMD can be used to reference the + specific command configured by the USES + setting in the port's Makefile. In + rare cases when more than one make + implementation is listed in USES, the + variables GMAKE (for the + GNU version) or FMAKE + (for the legacy &os; version) are available. Most ports + should only use MAKE_CMD within the + application Makefiles in + WRKSRC to call the + make implementation expected by the + ported software. If your port is an X application that creates Makefile files from From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 03:25:23 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A39BA6C; Sun, 16 Feb 2014 03:25:23 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 125F6171B; Sun, 16 Feb 2014 03:25:23 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G3PNVl075668; Sun, 16 Feb 2014 03:25:23 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G3PM7E075667; Sun, 16 Feb 2014 03:25:22 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160325.s1G3PM7E075667@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 03:25:22 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43956 - head/en_US.ISO8859-1/books/porters-handbook/special X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 03:25:23 -0000 Author: wblock Date: Sun Feb 16 03:25:22 2014 New Revision: 43956 URL: http://svnweb.freebsd.org/changeset/doc/43956 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 03:09:35 2014 (r43955) +++ head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml Sun Feb 16 03:25:22 2014 (r43956) @@ -4,3542 +4,3540 @@ $FreeBSD$ --> - + + + Special Considerations + + There are some more things you have to take into account + when you create a port. This section explains the most common + of those. + + + Staging + + bsd.port.mk expects ports to work + with a stage directory. This means that a port + should not install files directly to the regular destination + directories (that is, under PREFIX, for + example) but instead into a separate directory from which the + package is then built. In many cases, this does not require + root privileges, making it possible to build packages as an + unprivileged user. With staging, the port is built and + installed into the stage directory, + STAGEDIR. A package is created from the + stage directory and then installed on the system. Automake + tools refer to this concept as DESTDIR, but + in &os;, DESTDIR has a different meaning + (see ). + + When a port still requires system-wide privileges in order + to run the package target, this + line must be added to the + Makefile: + + NEED_ROOT= yes + + Meta ports, or ports that do not install files themselves + but only depend on other ports, should avoid needlessly + extracting the &man.mtree.8; to the stage directory. This is + the basic directory layout of the package, and these empty + directories will be seens as orphans. To prevent + &man.mtree.8; extraction, add this line: + + NO_MTREE= yes + + Staging is enabled by prepending the + STAGEDIR variable to paths used in the + pre-install, + do-install, and + post-install targets (see the + examples through the book). Typically, this includes + PREFIX, ETCDIR, + DATADIR, EXAMPLESDIR, + MANPREFIX, DOCSDIR, and + so on. Directories should be created as part of the + post-install target. Avoid using + absolute paths whenever possible. + + When creating a symlink, STAGEDIR + should be prepended to the target path only. For + example: + + ${LN} -sf libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so + + The source path + ${PREFIX}/lib/libfoo.so.42 looks fine but + could, in fact, be incorrect. Absolute paths can point to a + wrong location, like when a remote file system has been + mounted with NFS under a non-root mount + point. Relative paths are less fragile, and often much + shorter. + + Ports that install kernel modules must prepend the + STAGEDIR variable to + their destination, by default + /boot/modules. + + + + Shared Libraries + + If your port installs one or more shared libraries, define + a USE_LDCONFIG make variable, which will + instruct a bsd.port.mk to run + ${LDCONFIG} -m on the directory + where the new library is installed (usually + PREFIX/lib) during + post-install target to register it + into the shared library cache. This variable, when defined, + will also facilitate addition of an appropriate + @exec /sbin/ldconfig -m and + @unexec /sbin/ldconfig -R pair into your + pkg-plist file, so that a user who + installed the package can start using the shared library + immediately and de-installation will not cause the system to + still believe the library is there. + + USE_LDCONFIG= yes + + If you need, you can override the default directory by + setting the USE_LDCONFIG value to a list of + directories into which shared libraries are to be installed. + For example if your port installs shared libraries into + PREFIX/lib/foo and + PREFIX/lib/bar + directories you could use the following in your + Makefile: + + USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar + + Please double-check, often this is not necessary at all or + can be avoided through -rpath or setting + LD_RUN_PATH during linking (see + lang/moscow_ml for an + example), or through a shell-wrapper which sets + LD_LIBRARY_PATH before invoking the binary, + like www/seamonkey + does. + + When installing 32-bit libraries on 64-bit system, use + USE_LDCONFIG32 instead. + + Try to keep shared library version numbers in the + libfoo.so.0 format. Our runtime linker + only cares for the major (first) number. + + When the major library version number increments in the + update to the new port version, all other ports that link to + the affected library should have their + PORTREVISION incremented, to force + recompilation with the new library version. + + + + Ports with Distribution Restrictions or Legal + Concerns + + Licenses vary, and some of them place restrictions on how + the application can be packaged, whether it can be sold for + profit, and so on. + + + It is your responsibility as a porter to read the + licensing terms of the software and make sure that the + &os; project will not be held accountable for violating + them by redistributing the source or compiled binaries + either via FTP/HTTP or CD-ROM. If in doubt, please contact + the &a.ports;. + + + In situations like this, the variables described in the + following sections can be set. + + + <varname>NO_PACKAGE</varname> + + This variable indicates that we may not generate a + binary package of the application. For instance, the + license may disallow binary redistribution, or it may + prohibit distribution of packages created from patched + sources. + + However, the port's DISTFILES may be + freely mirrored on FTP/HTTP. They may also be distributed + on a CD-ROM (or similar media) unless + NO_CDROM is set as well. + + NO_PACKAGE should also be used if the + binary package is not generally useful, and the application + should always be compiled from the source code. For + example, if the application has configuration information + that is site specific hard coded in to it at compile time, + set NO_PACKAGE. + + NO_PACKAGE should be set to a string + describing the reason why the package should not be + generated. + + + + <varname>NO_CDROM</varname> + + This variable alone indicates that, although we are + allowed to generate binary packages, we may put neither + those packages nor the port's DISTFILES + onto a CD-ROM (or similar media) for resale. However, the + binary packages and the port's DISTFILES + will still be available via FTP/HTTP. + + If this variable is set along with + NO_PACKAGE, then only the port's + DISTFILES will be available, and only via + FTP/HTTP. + + NO_CDROM should be set to a string + describing the reason why the port cannot be redistributed + on CD-ROM. For instance, this should be used if the port's + license is for non-commercial use + only. + + + + <varname>NOFETCHFILES</varname> + + Files defined in the NOFETCHFILES + variable are not fetchable from any of the + MASTER_SITES. An example of such a file + is when the file is supplied on CD-ROM by the vendor. + + Tools which check for the availability of these files + on the MASTER_SITES should ignore these + files and not report about them. + + + + <varname>RESTRICTED</varname> + + Set this variable alone if the application's license + permits neither mirroring the application's + DISTFILES nor distributing the binary + package in any way. + + NO_CDROM or + NO_PACKAGE should not be set along with + RESTRICTED since the latter variable + implies the former ones. + + RESTRICTED should be set to a string + describing the reason why the port cannot be redistributed. + Typically, this indicates that the port contains proprietary + software and that the user will need to manually download + the DISTFILES, possibly after registering + for the software or agreeing to accept the terms of an + EULA. + + + + <varname>RESTRICTED_FILES</varname> + + When RESTRICTED or + NO_CDROM is set, this variable defaults + to ${DISTFILES} ${PATCHFILES}, otherwise + it is empty. If only some of the distribution files are + restricted, then set this variable to list them. + + + + + <varname>LEGAL_TEXT</varname> + + If the port has legal concerns not addressed by the + above variables, the variable LEGAL_TEXT + should be set to a string explaining the concern. For + example, if special permission was obtained for &os; to + redistribute the binary, this variable should indicate + so. + + + + <filename>/usr/ports/LEGAL</filename> and + <varname>LEGAL</varname> + + A port which sets any of the above variables must also + be added to /usr/ports/LEGAL. The + first column is a glob which matches the restricted + distfiles. The second column is the port's origin. The + third column is the output of + make -VLEGAL. + - Special Considerations + + Examples - There are some more things you have to take into account - when you create a port. This section explains the most common - of those. - - - Staging - - bsd.port.mk expects ports to work - with a stage directory. This means that a port - should not install files directly to the regular destination - directories (that is, under PREFIX, for - example) but instead into a separate directory from which the - package is then built. In many cases, this does not require - root privileges, making it possible to build packages as an - unprivileged user. With staging, the port is built and - installed into the stage directory, - STAGEDIR. A package is created from the - stage directory and then installed on the system. Automake - tools refer to this concept as DESTDIR, but - in &os;, DESTDIR has a different meaning - (see ). - - When a port still requires system-wide privileges in order - to run the package target, this - line must be added to the - Makefile: - - NEED_ROOT= yes - - Meta ports, or ports that do not install files themselves - but only depend on other ports, should avoid needlessly - extracting the &man.mtree.8; to the stage directory. This is - the basic directory layout of the package, and these empty - directories will be seens as orphans. To prevent - &man.mtree.8; extraction, add this line: - - NO_MTREE= yes - - Staging is enabled by prepending the - STAGEDIR variable to paths used in the - pre-install, - do-install, and - post-install targets (see the - examples through the book). Typically, this includes - PREFIX, ETCDIR, - DATADIR, EXAMPLESDIR, - MANPREFIX, DOCSDIR, and - so on. Directories should be created as part of the - post-install target. Avoid using - absolute paths whenever possible. + The preferred way to state "the distfiles for this port + must be fetched manually" is as follows: - When creating a symlink, STAGEDIR - should be prepended to the target path only. For - example: - - ${LN} -sf libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so - - The source path - ${PREFIX}/lib/libfoo.so.42 looks fine but - could, in fact, be incorrect. Absolute paths can point to a - wrong location, like when a remote file system has been - mounted with NFS under a non-root mount - point. Relative paths are less fragile, and often much - shorter. - - Ports that install kernel modules must prepend the - STAGEDIR variable to - their destination, by default - /boot/modules. - - - - Shared Libraries - - If your port installs one or more shared libraries, define - a USE_LDCONFIG make variable, which will - instruct a bsd.port.mk to run - ${LDCONFIG} -m on the directory - where the new library is installed (usually - PREFIX/lib) during - post-install target to register it - into the shared library cache. This variable, when defined, - will also facilitate addition of an appropriate - @exec /sbin/ldconfig -m and - @unexec /sbin/ldconfig -R pair into your - pkg-plist file, so that a user who - installed the package can start using the shared library - immediately and de-installation will not cause the system to - still believe the library is there. - - USE_LDCONFIG= yes - - If you need, you can override the default directory by - setting the USE_LDCONFIG value to a list of - directories into which shared libraries are to be installed. - For example if your port installs shared libraries into - PREFIX/lib/foo and - PREFIX/lib/bar - directories you could use the following in your - Makefile: - - USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar - - Please double-check, often this is not necessary at all or - can be avoided through -rpath or setting - LD_RUN_PATH during linking (see - lang/moscow_ml for an - example), or through a shell-wrapper which sets - LD_LIBRARY_PATH before invoking the binary, - like www/seamonkey - does. - - When installing 32-bit libraries on 64-bit system, use - USE_LDCONFIG32 instead. - - Try to keep shared library version numbers in the - libfoo.so.0 format. Our runtime linker - only cares for the major (first) number. - - When the major library version number increments in the - update to the new port version, all other ports that link to - the affected library should have their - PORTREVISION incremented, to force - recompilation with the new library version. - - - - Ports with Distribution Restrictions or Legal - Concerns - - Licenses vary, and some of them place restrictions on how - the application can be packaged, whether it can be sold for - profit, and so on. - - - It is your responsibility as a porter to read the - licensing terms of the software and make sure that the - &os; project will not be held accountable for violating - them by redistributing the source or compiled binaries - either via FTP/HTTP or CD-ROM. If in doubt, please contact - the &a.ports;. - - - In situations like this, the variables described in the - following sections can be set. - - - <varname>NO_PACKAGE</varname> - - This variable indicates that we may not generate a - binary package of the application. For instance, the - license may disallow binary redistribution, or it may - prohibit distribution of packages created from patched - sources. - - However, the port's DISTFILES may be - freely mirrored on FTP/HTTP. They may also be distributed - on a CD-ROM (or similar media) unless - NO_CDROM is set as well. - - NO_PACKAGE should also be used if the - binary package is not generally useful, and the application - should always be compiled from the source code. For - example, if the application has configuration information - that is site specific hard coded in to it at compile time, - set NO_PACKAGE. - - NO_PACKAGE should be set to a string - describing the reason why the package should not be - generated. - - - - <varname>NO_CDROM</varname> - - This variable alone indicates that, although we are - allowed to generate binary packages, we may put neither - those packages nor the port's DISTFILES - onto a CD-ROM (or similar media) for resale. However, the - binary packages and the port's DISTFILES - will still be available via FTP/HTTP. - - If this variable is set along with - NO_PACKAGE, then only the port's - DISTFILES will be available, and only via - FTP/HTTP. - - NO_CDROM should be set to a string - describing the reason why the port cannot be redistributed - on CD-ROM. For instance, this should be used if the port's - license is for non-commercial use - only. - - - - <varname>NOFETCHFILES</varname> - - Files defined in the NOFETCHFILES - variable are not fetchable from any of the - MASTER_SITES. An example of such a file - is when the file is supplied on CD-ROM by the vendor. - - Tools which check for the availability of these files - on the MASTER_SITES should ignore these - files and not report about them. - - - - <varname>RESTRICTED</varname> - - Set this variable alone if the application's license - permits neither mirroring the application's - DISTFILES nor distributing the binary - package in any way. - - NO_CDROM or - NO_PACKAGE should not be set along with - RESTRICTED since the latter variable - implies the former ones. - - RESTRICTED should be set to a string - describing the reason why the port cannot be redistributed. - Typically, this indicates that the port contains proprietary - software and that the user will need to manually download - the DISTFILES, possibly after registering - for the software or agreeing to accept the terms of an - EULA. - - - - <varname>RESTRICTED_FILES</varname> - - When RESTRICTED or - NO_CDROM is set, this variable defaults - to ${DISTFILES} ${PATCHFILES}, otherwise - it is empty. If only some of the distribution files are - restricted, then set this variable to list them. - - - - - <varname>LEGAL_TEXT</varname> - - If the port has legal concerns not addressed by the - above variables, the variable LEGAL_TEXT - should be set to a string explaining the concern. For - example, if special permission was obtained for &os; to - redistribute the binary, this variable should indicate - so. - - - - <filename>/usr/ports/LEGAL</filename> and - <varname>LEGAL</varname> - - A port which sets any of the above variables must also - be added to /usr/ports/LEGAL. The - first column is a glob which matches the restricted - distfiles. The second column is the port's origin. The - third column is the output of - make -VLEGAL. - - - - Examples - - The preferred way to state "the distfiles for this port - must be fetched manually" is as follows: - - .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) + .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) IGNORE= may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR} .endif - This both informs the user, and sets the proper metadata - on the user's machine for use by automated programs. - - Note that this stanza must be preceded by an inclusion - of bsd.port.pre.mk. - - - - - Building Mechanisms - - - Building Ports in Parallel - - The &os; ports framework supports parallel building - using multiple make sub-processes, which - allows SMP systems to utilize all of - their available CPU power, allowing port - builds to be faster and more effective. - - This is achieved by passing -jX flag - to &man.make.1; running on vendor code. This is the default - build behavior of ports. Unfortunately, not all ports - handle parallel building well and it may be required to - explicitly disable this feature by adding the - MAKE_JOBS_UNSAFE=yes variable. It is - used when a port is known to be broken with - -jX. - - - - - <command>make</command>, <command>gmake</command>, - <command>fmake</command>, and <command>imake</command> - - Several differing make - implementations exist. Ported software often requires a - particular implementation, like GNU - make, known in &os; as - gmake, or fmake, the - legacy &os; make. - - If the port uses GNU make, - add gmake to USES. If - the legacy &os; make is needed, add - fmake there. - - MAKE_CMD can be used to reference the - specific command configured by the USES - setting in the port's Makefile. In - rare cases when more than one make - implementation is listed in USES, the - variables GMAKE (for the - GNU version) or FMAKE - (for the legacy &os; version) are available. Most ports - should only use MAKE_CMD within the - application Makefiles in - WRKSRC to call the - make implementation expected by the - ported software. - - If your port is an X application that creates - Makefile files from - Imakefile files using - imake, then set - USES= imake. This will cause the - configure stage to automatically do an - xmkmf -a. If the - flag is a problem for your port, set - XMKMF=xmkmf. If the port uses - imake but does not understand the - install.man target, - NO_INSTALL_MANPAGES=yes should be - set. - - If your port's source Makefile has - something else than all as the - main build target, set ALL_TARGET - accordingly. Same goes for - install and - INSTALL_TARGET. - - - - <command>configure</command> Script - - If your port uses the configure - script to generate Makefile files from - Makefile.in files, set - GNU_CONFIGURE=yes. If you want to give - extra arguments to the configure script - (the default argument is --prefix=${PREFIX} - --infodir=${PREFIX}/${INFO_PATH} - --mandir=${MANPREFIX}/man - --build=${CONFIGURE_TARGET}), set those - extra arguments in CONFIGURE_ARGS. Extra - environment variables can be passed using - CONFIGURE_ENV variable. - - - Variables for Ports That Use - <command>configure</command> - - - - - Variable - Means - - - - - - GNU_CONFIGURE - The port uses configure - script to prepare build. - - - - HAS_CONFIGURE - Same as GNU_CONFIGURE, - except default configure target is not added to - CONFIGURE_ARGS. - - - - CONFIGURE_ARGS - Additional arguments passed to - configure script. - - - - CONFIGURE_ENV - Additional environment variables to be set - for configure script run. - - - - CONFIGURE_TARGET - Override default configure target. Default - value is - ${MACHINE_ARCH}-portbld-freebsd${OSREL}. - - - -
- - - - Using <command>cmake</command> - - For ports that use CMake, - define USES= cmake, or - USES= cmake:outsource to build in a - separate directory (see below). - - - Variables for Ports That Use - <command>cmake</command> - - - - - Variable - Means - - - - - - CMAKE_ARGS - Port specific CMake - flags to be passed to the cmake - binary. - - - - CMAKE_BUILD_TYPE - Type of build (CMake - predefined build profiles). Default is - Release, or - Debug if - WITH_DEBUG is set. - - - - CMAKE_ENV - Environment variables to be set for the - cmake binary. Default is - ${CONFIGURE_ENV}. - - - - CMAKE_SOURCE_PATH - Path to the source directory. Default is - ${WRKSRC}. - - - -
- - - Variables the Users can define for - <command>cmake</command> builds - - - - - Variable - Means - - - - - - CMAKE_VERBOSE - Enable verbose build output. Default not set, - unless BATCH or - PACKAGE_BUILDING are set. - - - - CMAKE_NOCOLOR - Disables colour build output. Default not set, - unless BATCH or - PACKAGE_BUILDING are set. - - - -
- - CMake supports the following - build profiles: Debug, - Release, - RelWithDebInfo and - MinSizeRel. Debug and - Release profiles respect system - *FLAGS, RelWithDebInfo - and MinSizeRel will set - CFLAGS to -O2 -g and - -Os -DNDEBUG correspondingly. The - lower-cased value of CMAKE_BUILD_TYPE is - exported to the PLIST_SUB and should be - used if port installs *.cmake files - depending on the build type (see - deskutils/strigi for an - example). Please note that some projects may define their - own build profiles and/or force particular build type by - setting CMAKE_BUILD_TYPE in - CMakeLists.txt files. In order to - make a port for such a project respect - CFLAGS and WITH_DEBUG, - the CMAKE_BUILD_TYPE definitions must be - removed from those files. - - Most CMake-based projects - support an out-of-source method of building. The - out-of-source build for a port can be requested by using the - :outsource suffix. When enabled, - CONFIGURE_WRKSRC, - BUILD_WRKSRC and - INSTALL_WRKSRC will be set to - ${WRKDIR}/.build and this - directory will be used to keep all files generated during - configuration and build stages, leaving the source directory - intact. - - - <literal>USES= cmake</literal> Example - - The following snippet demonstrates the use of - CMake for a port. - CMAKE_SOURCE_PATH is not usually - required, but can be set when the sources are not located - in the top directory, or if only a subset of the project - is intended to be built by the port. - - USES= cmake:outsource -CMAKE_SOURCE_PATH= ${WRKSRC}/subproject - - - - - Using <command>scons</command> + This both informs the user, and sets the proper metadata + on the user's machine for use by automated programs. - If your port uses SCons, - define USE_SCONS=yes. + Note that this stanza must be preceded by an inclusion + of bsd.port.pre.mk. + + + + + Building Mechanisms + + + Building Ports in Parallel + + The &os; ports framework supports parallel building + using multiple make sub-processes, which + allows SMP systems to utilize all of + their available CPU power, allowing port + builds to be faster and more effective. + + This is achieved by passing -jX flag + to &man.make.1; running on vendor code. This is the default + build behavior of ports. Unfortunately, not all ports + handle parallel building well and it may be required to + explicitly disable this feature by adding the + MAKE_JOBS_UNSAFE=yes variable. It is + used when a port is known to be broken with + -jX. + + + + <command>make</command>, <command>gmake</command>, + <command>fmake</command>, and <command>imake</command> + + Several differing make + implementations exist. Ported software often requires a + particular implementation, like GNU + make, known in &os; as + gmake, or fmake, the + legacy &os; make. + + If the port uses GNU make, + add gmake to USES. If + the legacy &os; make is needed, add + fmake there. + + MAKE_CMD can be used to reference the + specific command configured by the USES + setting in the port's Makefile. In + rare cases when more than one make + implementation is listed in USES, the + variables GMAKE (for the + GNU version) or FMAKE + (for the legacy &os; version) are available. Most ports + should only use MAKE_CMD within the + application Makefiles in + WRKSRC to call the + make implementation expected by the + ported software. + + If your port is an X application that creates + Makefile files from + Imakefile files using + imake, then set + USES= imake. This will cause the + configure stage to automatically do an + xmkmf -a. If the + flag is a problem for your port, set + XMKMF=xmkmf. If the port uses + imake but does not understand the + install.man target, + NO_INSTALL_MANPAGES=yes should be + set. + + If your port's source Makefile has + something else than all as the + main build target, set ALL_TARGET + accordingly. Same goes for + install and + INSTALL_TARGET. + + + + <command>configure</command> Script + + If your port uses the configure + script to generate Makefile files from + Makefile.in files, set + GNU_CONFIGURE=yes. If you want to give + extra arguments to the configure script + (the default argument is --prefix=${PREFIX} + --infodir=${PREFIX}/${INFO_PATH} + --mandir=${MANPREFIX}/man + --build=${CONFIGURE_TARGET}), set those + extra arguments in CONFIGURE_ARGS. Extra + environment variables can be passed using + CONFIGURE_ENV variable. - - Variables for Ports That Use - <command>scons</command> - - - - - Variable - Means - - - - - - SCONS_ARGS - Port specific SCons flags passed to the SCons - environment. - - - - SCONS_BUILDENV - Variables to be set in system - environment. - - - - SCONS_ENV - Variables to be set in SCons - environment. - - - - SCONS_TARGET - Last argument passed to SCons, similar to - MAKE_TARGET. - - - -
- - To make third party SConstruct - respect everything that is passed to SCons in - SCONS_ENV (that is, most importantly, - CC/CXX/CFLAGS/CXXFLAGS), patch the - SConstruct so build - Environment is constructed like - this: - - env = Environment(**ARGUMENTS) - - It may be then modified with - env.Append and - env.Replace. - - - - - Using GNU Autotools - - *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 03:32:26 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA33CD10; Sun, 16 Feb 2014 03:32:26 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9428B17A9; Sun, 16 Feb 2014 03:32:26 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G3WQ9G079423; Sun, 16 Feb 2014 03:32:26 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G3WQ9I079422; Sun, 16 Feb 2014 03:32:26 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160332.s1G3WQ9I079422@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 03:32:26 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43957 - head/en_US.ISO8859-1/books/porters-handbook/testing X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 03:32:26 -0000 Author: wblock Date: Sun Feb 16 03:32:26 2014 New Revision: 43957 URL: http://svnweb.freebsd.org/changeset/doc/43957 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Sun Feb 16 03:25:22 2014 (r43956) +++ head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Sun Feb 16 03:32:26 2014 (r43957) @@ -4,198 +4,192 @@ $FreeBSD$ --> - - - Testing the Port - - - Running <command>make describe</command> - - Several of the &os; port maintenance tools, such as - &man.portupgrade.1;, rely on a database called - /usr/ports/INDEX which keeps track of - such items as port dependencies. INDEX - is created by the top-level - ports/Makefile via - make index, which descends into each port - subdirectory and executes make describe - there. Thus, if make describe fails in any - port, no one can generate INDEX, and many - people will quickly become unhappy. - - - It is important to be able to generate this file no - matter what options are present in - make.conf, so please avoid doing things - such as using .error statements when (for - instance) a dependency is not satisfied. (See - .) - - - If make describe produces a string - rather than an error message, you are probably safe. See - bsd.port.mk for the meaning of the - string produced. - - Also note that running a recent version of - portlint (as specified in the next section) - will cause make describe to be run - automatically. - - - - Portlint - - Do check your work with portlint - before you submit or commit it. portlint - warns you about many common errors, both functional and - stylistic. For a new (or repocopied) port, - portlint -A is the most thorough; for an - existing port, portlint -C is - sufficient. - - Since portlint uses heuristics to - try to figure out errors, it can produce false positive - warnings. In addition, occasionally something that is - flagged as a problem really cannot be done in any other - way due to limitations in the ports framework. When in - doubt, the best thing to do is ask on &a.ports;. - - - - Port Tools - - The - ports-mgmt/porttools - program is part of the Ports Collection. - - port is the front-end script, which can - help you simplify the testing job. Whenever you want to test - a new port or update an existing one, you can use - port test to test your port, including the - portlint - checking. This command also detects and lists any files that - are not listed in pkg-plist. See the - following example: - - &prompt.root; port test /usr/ports/net/csup - - - - <varname>PREFIX</varname> and - <varname>DESTDIR</varname> - - PREFIX determines where the port will - be installed. It defaults to /usr/local, - but can be set by the user to a custom path like - /opt. Your port must respect the value - of this variable. - - DESTDIR, if set by the user, determines - the complete alternative environment, usually a jail or an - installed system mounted somewhere other than - /. A port will actually install into - DESTDIR/PREFIX, - and register with the package database in - DESTDIR/var/db/pkg. - As DESTDIR is handled automatically by the - ports infrastructure with &man.chroot.8;, you do not need any - modifications or any extra care to write - DESTDIR-compliant ports. - - The value of PREFIX will be set to - LOCALBASE (defaulting to - /usr/local). If - USE_LINUX_PREFIX is set, - PREFIX will be LINUXBASE - (defaulting to /compat/linux). - - Avoiding hard-coded /usr/local paths - in the source makes the port much more flexible and able to - cater to the needs of other sites. Often, this can be - accomplished by simply replacing occurrences of - /usr/local in the port's various - Makefiles with - ${PREFIX}. This variable is - automatically passed down to every stage of the build and - install processes. - - Make sure your application is not installing things in - /usr/local instead of - PREFIX. A quick test for such hard-coded - paths is: - - &prompt.root; make clean; make package PREFIX=/var/tmp/`make -V PORTNAME` - - If anything is installed outside of - PREFIX, the package creation process will - complain that it cannot find the files. - - In addition, it is worth checking the same with the - stage directory support (see - ): - - &prompt.root; make stage && make check-orphans && make package - - These tests will not find hard-coded paths inside the - port's files, nor will it verify that - LOCALBASE is being used to correctly refer - to files from other ports. The temporarily-installed port in - /var/tmp/`make -V PORTNAME` should be - tested for proper operation to make sure there - are no problems with paths. - - PREFIX should not be set explicitly - in a port's Makefile. Users installing - the port may have set PREFIX to a custom - location, and the port should respect that setting. - - Refer to programs and files from other ports with the - variables mentioned above, not explicit pathnames. For - instance, if your port requires a macro - PAGER to have the full pathname of - less, do not use a literal path of - /usr/local/bin/less. Instead, use - ${LOCALBASE}: - - -DPAGER=\"${LOCALBASE}/bin/less\" - - The path with LOCALBASE is more likely - to still work if the system administrator has moved the whole - /usr/local tree somewhere else. - - - - Tinderbox - - If you are an avid ports contributor, you might want to - take a look at Tinderbox. It is a - powerful system for building and testing ports. - You can - install Tinderbox using - ports-mgmt/tinderbox port. - Be sure to read supplied documentation since the configuration - is not trivial. - - Visit the - Tinderbox - website for more details. - - - - Poudriere - - As a ports contributor, consider installing - poudriere. It is a powerful - system for building and testing ports. - Poudriere can be installed with - ports-mgmt/poudriere. - - Visit the Poudriere - website for more details. - - - + + + Testing the Port + + + Running <command>make describe</command> + + Several of the &os; port maintenance tools, such as + &man.portupgrade.1;, rely on a database called + /usr/ports/INDEX which keeps track of such + items as port dependencies. INDEX is + created by the top-level ports/Makefile via + make index, which descends into each port + subdirectory and executes make describe + there. Thus, if make describe fails in any + port, no one can generate INDEX, and many + people will quickly become unhappy. + + + It is important to be able to generate this file no matter + what options are present in make.conf, so + please avoid doing things such as using + .error statements when (for instance) a + dependency is not satisfied. (See + .) + + + If make describe produces a string rather + than an error message, you are probably safe. See + bsd.port.mk for the meaning of the string + produced. + + Also note that running a recent version of + portlint (as specified in the next section) + will cause make describe to be run + automatically. + + + + Portlint + + Do check your work with portlint + before you submit or commit it. portlint + warns you about many common errors, both functional and + stylistic. For a new (or repocopied) port, + portlint -A is the most thorough; for an + existing port, portlint -C is + sufficient. + + Since portlint uses heuristics to try to + figure out errors, it can produce false positive warnings. In + addition, occasionally something that is flagged as a problem + really cannot be done in any other way due to limitations in the + ports framework. When in doubt, the best thing to do is ask on + &a.ports;. + + + + Port Tools + + The ports-mgmt/porttools + program is part of the Ports Collection. + + port is the front-end script, which can + help you simplify the testing job. Whenever you want to test a + new port or update an existing one, you can use + port test to test your port, including the + portlint + checking. This command also detects and lists any files that + are not listed in pkg-plist. See the + following example: + + &prompt.root; port test /usr/ports/net/csup + + + + <varname>PREFIX</varname> and + <varname>DESTDIR</varname> + + PREFIX determines where the port will be + installed. It defaults to /usr/local, but + can be set by the user to a custom path like + /opt. Your port must respect the value of + this variable. + + DESTDIR, if set by the user, determines + the complete alternative environment, usually a jail or an + installed system mounted somewhere other than + /. A port will actually install into + DESTDIR/PREFIX, and register with the + package database in DESTDIR/var/db/pkg. As + DESTDIR is handled automatically by the ports + infrastructure with &man.chroot.8;, you do not need any + modifications or any extra care to write + DESTDIR-compliant ports. + + The value of PREFIX will be set to + LOCALBASE (defaulting to + /usr/local). If + USE_LINUX_PREFIX is set, + PREFIX will be LINUXBASE + (defaulting to /compat/linux). + + Avoiding hard-coded /usr/local paths in + the source makes the port much more flexible and able to cater + to the needs of other sites. Often, this can be accomplished by + simply replacing occurrences of /usr/local + in the port's various Makefiles with + ${PREFIX}. This variable is + automatically passed down to every stage of the build and + install processes. + + Make sure your application is not installing things in + /usr/local instead of + PREFIX. A quick test for such hard-coded + paths is: + + &prompt.root; make clean; make package PREFIX=/var/tmp/`make -V PORTNAME` + + If anything is installed outside of + PREFIX, the package creation process will + complain that it cannot find the files. + + In addition, it is worth checking the same with the stage + directory support (see ): + + &prompt.root; make stage && make check-orphans && make package + + These tests will not find hard-coded paths inside the port's + files, nor will it verify that LOCALBASE is + being used to correctly refer to files from other ports. The + temporarily-installed port in + /var/tmp/`make -V PORTNAME` should be + tested for proper operation to make sure there are no problems + with paths. + + PREFIX should not be set explicitly in a + port's Makefile. Users installing the port + may have set PREFIX to a custom location, and + the port should respect that setting. + + Refer to programs and files from other ports with the + variables mentioned above, not explicit pathnames. For + instance, if your port requires a macro PAGER + to have the full pathname of less, do not use + a literal path of /usr/local/bin/less. + Instead, use ${LOCALBASE}: + + -DPAGER=\"${LOCALBASE}/bin/less\" + + The path with LOCALBASE is more likely to + still work if the system administrator has moved the whole + /usr/local tree somewhere else. + + + + Tinderbox + + If you are an avid ports contributor, you might want to take + a look at Tinderbox. It is a + powerful system for building and testing ports. You can install + Tinderbox using + ports-mgmt/tinderbox port. Be + sure to read supplied documentation since the configuration is + not trivial. + + Visit the + Tinderbox + website for more details. + + + + Poudriere + + As a ports contributor, consider installing + poudriere. It is a powerful + system for building and testing ports. + Poudriere can be installed with + ports-mgmt/poudriere. + + Visit the Poudriere + website for more details. + + From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 04:57:46 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F6FC946; Sun, 16 Feb 2014 04:57:46 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 68B521CC6; Sun, 16 Feb 2014 04:57:46 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G4vkFs014217; Sun, 16 Feb 2014 04:57:46 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G4vk1C014216; Sun, 16 Feb 2014 04:57:46 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160457.s1G4vk1C014216@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 04:57:46 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43958 - head/en_US.ISO8859-1/books/porters-handbook/makefiles X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 04:57:46 -0000 Author: wblock Date: Sun Feb 16 04:57:45 2014 New Revision: 43958 URL: http://svnweb.freebsd.org/changeset/doc/43958 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Sun Feb 16 03:32:26 2014 (r43957) +++ head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Sun Feb 16 04:57:45 2014 (r43958) @@ -4,2114 +4,2087 @@ $FreeBSD$ --> + + + Configuring the Makefile + + Configuring the Makefile is pretty + simple, and again we suggest that you look at existing examples + before starting. Also, there is a + sample Makefile in this + handbook, so take a look and please follow the ordering of + variables and sections in that template to make your port easier + for others to read. + + Now, consider the following problems in sequence as you + design your new Makefile: + + + The Original Source + + Does it live in DISTDIR as a standard + gzipped tarball named something like + foozolix-1.2.tar.gz? If so, you can go on + to the next step. If not, you should look at overriding any of + the DISTVERSION, DISTNAME, + EXTRACT_CMD, + EXTRACT_BEFORE_ARGS, + EXTRACT_AFTER_ARGS, + EXTRACT_SUFX, or DISTFILES + variables, depending on how alien a format your port's + distribution file is. + + In the worst case, you can simply create your own + do-extract target to override the + default, though this should be rarely, if ever, + necessary. + + + + Naming + + The first part of the port's Makefile + names the port, describes its version number, and lists it in + the correct category. + + + <varname>PORTNAME</varname> and + <varname>PORTVERSION</varname> + + You should set PORTNAME to the base + name of your port, and PORTVERSION to the + version number of the port. + + + + <varname>PORTREVISION</varname> and + <varname>PORTEPOCH</varname> + + + <varname>PORTREVISION</varname> + + The PORTREVISION variable is a + monotonically increasing value which is reset to 0 with + every increase of PORTVERSION (i.e., + every time a new official vendor release is made), and + appended to the package name if non-zero. Changes to + PORTREVISION are used by automated tools + (e.g., pkg version, see + &man.pkg-version.8;) to highlight the fact that a new + package is available. + + PORTREVISION should be increased each + time a change is made to the port that changes the generated + package in any way. That includes changes that only affect + a package built with non-default + options. - - Configuring the Makefile + Examples of when PORTREVISION + should be bumped: - Configuring the Makefile is pretty - simple, and again we suggest that you look at existing examples - before starting. Also, there is a - sample Makefile in this - handbook, so take a look and please follow the ordering of - variables and sections in that template to make your port easier - for others to read. - - Now, consider the following problems in sequence as you - design your new Makefile: - - - The Original Source - - Does it live in DISTDIR as a standard - gzipped tarball named something like - foozolix-1.2.tar.gz? If so, you can go on - to the next step. If not, you should look at overriding any - of the DISTVERSION, - DISTNAME, EXTRACT_CMD, - EXTRACT_BEFORE_ARGS, - EXTRACT_AFTER_ARGS, - EXTRACT_SUFX, or - DISTFILES variables, depending on how alien - a format your port's distribution file is. - - In the worst case, you can simply create your own - do-extract target to override the - default, though this should be rarely, if ever, - necessary. - - - - Naming - - The first part of the port's Makefile - names the port, describes its version number, and lists it - in the correct category. - - - <varname>PORTNAME</varname> and - <varname>PORTVERSION</varname> - - You should set PORTNAME to the - base name of your port, and PORTVERSION - to the version number of the port. - - - - <varname>PORTREVISION</varname> and - <varname>PORTEPOCH</varname> - - - <varname>PORTREVISION</varname> - - The PORTREVISION variable is a - monotonically increasing value which is reset to 0 with - every increase of PORTVERSION (i.e., - every time a new official vendor release is made), and - appended to the package name if non-zero. Changes to - PORTREVISION are used by automated - tools (e.g., pkg version, see - &man.pkg-version.8;) to highlight the fact that a new - package is available. - - PORTREVISION should be increased - each time a change is made to the port that changes the - generated package in any way. That includes changes that - only affect a package built with non-default options. - - Examples of when PORTREVISION - should be bumped: - - - - Addition of patches to correct security - vulnerabilities, bugs, or to add new functionality to - the port. - - - - Changes to the port Makefile - to enable or disable compile-time options in the - package. - - - - Changes in the packing list or the install-time - behavior of the package (e.g., change to a script - which generates initial data for the package, like ssh - host keys). - - - - Version bump of a port's shared library dependency - (in this case, someone trying to install the old - package after installing a newer version of the - dependency will fail since it will look for the old - libfoo.x instead of libfoo.(x+1)). - - - - Silent changes to the port distfile which have - significant functional differences, i.e., changes to - the distfile requiring a correction to - distinfo with no corresponding - change to PORTVERSION, where a - diff -ru of the old and new - versions shows non-trivial changes to the code. - - - - Examples of changes which do not require a - PORTREVISION bump: - - - - Style changes to the port skeleton with no - functional change to what appears in the resulting - package. - - - - Changes to MASTER_SITES or - other functional changes to the port which do not - affect the resulting package. - - - - Trivial patches to the distfile such as correction - of typos, which are not important enough that users of - the package should go to the trouble of - upgrading. - - - - Build fixes which cause a package to become - compilable where it was previously failing (as long as - the changes do not introduce any functional change on - any other platforms on which the port did previously - build). Since PORTREVISION - reflects the content of the package, if the package - was not previously buildable then there is no need to - increase PORTREVISION to mark a - change. - - - - A rule of thumb is to ask yourself whether a change - committed to a port is something which everyone would - benefit from having (either because of an enhancement, - fix, or by virtue that the new package will actually work - at all), and weigh that against that fact that it will - cause everyone who regularly updates their ports tree to - be compelled to update. If yes, the - PORTREVISION should be bumped. - - - - <varname>PORTEPOCH</varname> - - From time to time a software vendor or &os; porter - will do something silly and release a version of their - software which is actually numerically less than the - previous version. An example of this is a port which goes - from foo-20000801 to foo-1.0 (the former will be - incorrectly treated as a newer version since 20000801 is a - numerically greater value than 1). - - - The results of version number comparisons are not - always obvious. pkg version (see - &man.pkg-version.8;) can be used to test the comparison - of two version number strings. For example: - - &prompt.user; pkg version -t 0.031 0.29 -> - - The > output indicates that - version 0.031 is considered greater than version 0.29, - which may not have been obvious to the porter. - - - In situations such as this, the - PORTEPOCH version should be increased. - If PORTEPOCH is nonzero it is appended - to the package name as described in section 0 above. - PORTEPOCH must never be decreased or - reset to zero, because that would cause comparison to a - package from an earlier epoch to fail (i.e., the package - would not be detected as out of date): the new version - number (e.g., 1.0,1 in the above - example) is still numerically less than the previous - version (20000801), but the ,1 suffix - is treated specially by automated tools and found to be - greater than the implied suffix ,0 on - the earlier package. - - Dropping or resetting PORTEPOCH - incorrectly leads to no end of grief; if you do not - understand the above discussion, please keep after it - until you do, or ask questions on the mailing - lists. - - It is expected that PORTEPOCH will - not be used for the majority of ports, and that sensible - use of PORTVERSION can often preempt it - becoming necessary if a future release of the software - should change the version structure. However, care is - needed by &os; porters when a vendor release is made - without an official version number — such as a code - snapshot release. The temptation is to - label the release with the release date, which will cause - problems as in the example above when a new - official release is made. - - For example, if a snapshot release is made on the date - 20000917, and the previous version of the software was - version 1.2, the snapshot release should be given a - PORTVERSION of 1.2.20000917 or similar, - not 20000917, so that the succeeding release, say 1.3, is - still a numerically greater value. - - - - Example of <varname>PORTREVISION</varname> and - <varname>PORTEPOCH</varname> Usage - - The gtkmumble port, version - 0.10, is committed to the ports - collection: - - PORTNAME= gtkmumble -PORTVERSION= 0.10 - - PKGNAME becomes - gtkmumble-0.10. - - A security hole is discovered which requires a local - &os; patch. PORTREVISION is bumped - accordingly. - - PORTNAME= gtkmumble -PORTVERSION= 0.10 -PORTREVISION= 1 - - PKGNAME becomes - gtkmumble-0.10_1 - - A new version is released by the vendor, numbered - 0.2 (it turns out the author actually - intended 0.10 to actually mean - 0.1.0, not - what comes after 0.9 - oops, too late now). - Since the new minor version 2 is - numerically less than the previous version - 10, the PORTEPOCH - must be bumped to manually force the new package to be - detected as newer. Since it is a new - vendor release of the code, - PORTREVISION is reset to 0 (or removed - from the Makefile). - - PORTNAME= gtkmumble -PORTVERSION= 0.2 -PORTEPOCH= 1 - - PKGNAME becomes - gtkmumble-0.2,1 - - The next release is 0.3. Since - PORTEPOCH never decreases, the version - variables are now: - - PORTNAME= gtkmumble -PORTVERSION= 0.3 -PORTEPOCH= 1 - - PKGNAME becomes - gtkmumble-0.3,1 - - - If PORTEPOCH were reset to - 0 with this upgrade, someone who had - installed the gtkmumble-0.10_1 - package would not detect the - gtkmumble-0.3 package as newer, since - 3 is still numerically less than - 10. Remember, this is the whole - point of PORTEPOCH in the first - place. - - - - - - <varname>PKGNAMEPREFIX</varname> and - <varname>PKGNAMESUFFIX</varname> - - Two optional variables, PKGNAMEPREFIX - and PKGNAMESUFFIX, are combined with - PORTNAME and - PORTVERSION to form - PKGNAME as - ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. - Make sure this conforms to our - guidelines for a good - package name. In particular, you are - not allowed to use a hyphen - (-) in PORTVERSION. - Also, if the package name has the - language- or the - -compiled.specifics part (see - below), use PKGNAMEPREFIX and - PKGNAMESUFFIX, respectively. Do not make - them part of PORTNAME. - - - - Package Naming Conventions - - The following are the conventions you should follow in - naming your packages. This is to have our package directory - easy to scan, as there are already thousands of packages and - users are going to turn away if they hurt their eyes! - - The package name should look like - language_region-name-compiled.specifics-version.numbers. - - The package name is defined as - ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. - Make sure to set the variables to conform to that - format. - - + - &os; strives to support the native language of - its users. The language- - part should be a two letter abbreviation of the natural - language defined by ISO-639 if the port is specific to a - certain language. Examples are ja - for Japanese, ru for Russian, - vi for Vietnamese, - zh for Chinese, ko - for Korean and de for German. - - If the port is specific to a certain region within - the language area, add the two letter country code as - well. Examples are en_US for US - English and fr_CH for Swiss - French. - - The language- part should - be set in the PKGNAMEPREFIX - variable. + Addition of patches to correct security + vulnerabilities, bugs, or to add new functionality to + the port. - The first letter of the name - part should be lowercase. (The rest of the name may - contain capital letters, so use your own discretion when - you are converting a software name that has some capital - letters in it.) There is a tradition of naming - Perl 5 modules by prepending - p5- and converting the double-colon - separator to a hyphen; for example, the - Data::Dumper module becomes - p5-Data-Dumper. + Changes to the port Makefile to + enable or disable compile-time options in the + package. - Make sure that the port's name and version are - clearly separated and placed into the - PORTNAME and - PORTVERSION variables. The only - reason for PORTNAME to contain a - version part is if the upstream distribution is really - named that way, as in the - textproc/libxml2 or - japanese/kinput2-freewnn ports. - Otherwise, the PORTNAME should not - contain any version-specific information. It is quite - normal for several ports to have the same - PORTNAME, as the - www/apache* ports do; in that case, - different versions (and different index entries) are - distinguished by the PKGNAMEPREFIX - and PKGNAMESUFFIX values. + Changes in the packing list or the install-time + behavior of the package (e.g., change to a script which + generates initial data for the package, like ssh host + keys). - If the port can be built with different - hardcoded - defaults (usually part of the directory name in - a family of ports), the - -compiled.specifics part - should state the compiled-in defaults (the hyphen is - optional). Examples are paper size and font - units. - - The -compiled.specifics - part should be set in the - PKGNAMESUFFIX variable. + Version bump of a port's shared library dependency + (in this case, someone trying to install the old package + after installing a newer version of the dependency will + fail since it will look for the old libfoo.x instead of + libfoo.(x+1)). - The version string should follow a dash - (-) and be a period-separated list of - integers and single lowercase alphabetics. In - particular, it is not permissible to have another dash - inside the version string. The only exception is the - string pl (meaning - patchlevel), which can be used - only when there are no major and - minor version numbers in the software. If the software - version has strings like alpha, - beta, rc, or - pre, take the first letter and put it - immediately after a period. If the version string - continues after those names, the numbers should follow - the single alphabet without an extra period between - them. - - The idea is to make it easier to sort ports by - looking at the version string. In particular, make sure - version number components are always delimited by a - period, and if the date is part of the string, use the - 0.0.yyyy.mm.dd - format, not - dd.mm.yyyy - or the non-Y2K compliant - yy.mm.dd - format. It is important to prefix the version with - 0.0. in case a release with an actual - version number is made, which would of course be - numerically less than - yyyy. + Silent changes to the port distfile which have + significant functional differences, i.e., changes to the + distfile requiring a correction to + distinfo with no corresponding + change to PORTVERSION, where a + diff -ru of the old and new versions + shows non-trivial changes to the code. - - - Here are some (real) examples on how to convert the name - as called by the software authors to a suitable package - name: - - - - - - Distribution Name - PKGNAMEPREFIX - PORTNAME - PKGNAMESUFFIX - PORTVERSION - Reason - - - - - - mule-2.2.2 - (empty) - mule - (empty) - 2.2.2 - No changes required - - - - EmiClock-1.0.2 - (empty) - emiclock - (empty) - 1.0.2 - No uppercase names for single programs - - - - rdist-1.3alpha - (empty) - rdist - (empty) - 1.3.a - No strings like alpha - allowed - - - - es-0.9-beta1 - (empty) - es - (empty) - 0.9.b1 - No strings like beta - allowed - - - - mailman-2.0rc3 - (empty) - mailman - (empty) - 2.0.r3 - No strings like rc - allowed - - - - v3.3beta021.src - (empty) - tiff - (empty) - 3.3 - What the heck was that anyway? - - - - tvtwm - (empty) - tvtwm - (empty) - pl11 - Version string always required - - - - piewm - (empty) - piewm - (empty) - 1.0 - Version string always required - - - - xvgr-2.10pl1 - (empty) - xvgr - (empty) - 2.10.1 - pl allowed only when no - major/minor version numbers - - - - gawk-2.15.6 - ja- - gawk - (empty) - 2.15.6 - Japanese language version - - - - psutils-1.13 - (empty) - psutils - -letter - 1.13 - Paper size hardcoded at package build - time - - - - pkfonts - (empty) - pkfonts - 300 - 1.0 - Package for 300dpi fonts - - - - - - If there is absolutely no trace of version information - in the original source and it is unlikely that the original - author will ever release another version, just set the - version string to 1.0 (like the - piewm example above). Otherwise, ask the - original author or use the date string - (0.0.yyyy.mm.dd) - as the version. - - - - - Categorization - - - <varname>CATEGORIES</varname> - - When a package is created, it is put under - /usr/ports/packages/All and links are - made from one or more subdirectories of - /usr/ports/packages. The names of - these subdirectories are specified by the variable - CATEGORIES. It is intended to make life - easier for the user when he is wading through the pile of - packages on the FTP site or the CDROM. Please take a look - at the current list of - categories and pick the ones that are suitable for - your port. - - This list also determines where in the ports tree the - port is imported. If you put more than one category here, - it is assumed that the port files will be put in the - subdirectory with the name in the first category. See - below for more - discussion about how to pick the right categories. - - - - Current List of Categories - - Here is the current list of port categories. Those - marked with an asterisk (*) are - virtual categories—those that do - not have a corresponding subdirectory in the ports tree. - They are only used as secondary categories, and only for - search purposes. - - - For non-virtual categories, you will find a one-line - description in the COMMENT in that - subdirectory's Makefile. - - - - - - - Category - Description - Notes - - - - - - accessibility - Ports to help disabled users. - - - - - afterstep* - - Ports to support the AfterStep - window manager. - - - - - arabic - Arabic language support. - - - - - archivers - Archiving tools. - - - - - astro - Astronomical ports. - - - - - audio - Sound support. - - - - - benchmarks - Benchmarking utilities. - - - - - biology - Biology-related software. - - - - - cad - Computer aided design tools. - - - - - chinese - Chinese language support. - - - - - comms - Communication software. - Mostly software to talk to your serial - port. - - - - converters - Character code converters. - - - - - databases - Databases. - - - - - deskutils - Things that used to be on the desktop before - computers were invented. - - - - - devel - Development utilities. - Do not put libraries here just because they are - libraries—unless they truly do not belong - anywhere else, they should not be in this - category. - - - - dns - DNS-related software. - - - - - docs* - Meta-ports for &os; documentation. - - - - - editors - General editors. - Specialized editors go in the section for those - tools (e.g., a mathematical-formula editor will go - in math). - - - - elisp* - Emacs-lisp ports. - - - - - emulators - Emulators for other operating systems. - Terminal emulators do not - belong here—X-based ones should go to - x11 and text-based ones to - either comms or - misc, depending on the exact - functionality. - - - - finance - Monetary, financial and related - applications. - - - - - french - French language support. - - - - - ftp - FTP client and server utilities. - If your port speaks both FTP and HTTP, put it - in ftp with a secondary - category of www. - - - - games - Games. - - - - - geography* - Geography-related software. - - - - - german - German language support. - - - - - gnome* - Ports from the - GNOME - Project. - - - - - gnustep* - Software related to the GNUstep desktop - environment. - - - - - graphics - Graphics utilities. - - - - - hamradio* - Software for amateur radio. - - - - - haskell* - Software related to the Haskell - language. - - - - - hebrew - Hebrew language support. - - - - - hungarian - Hungarian language support. - - - - - ipv6* - IPv6 related software. - - - - - irc - Internet Relay Chat utilities. - - - - - japanese - Japanese language support. - - - - - java - Software related to the Java™ - language. - The java category must - not be the only one for a port. Save for ports - directly related to the Java language, porters are - also encouraged not to use java - as the main category of a port. - - - *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 05:17:25 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C714FB74; Sun, 16 Feb 2014 05:17:25 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B04B51DE8; Sun, 16 Feb 2014 05:17:25 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G5HP8u023285; Sun, 16 Feb 2014 05:17:25 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G5HPNr023284; Sun, 16 Feb 2014 05:17:25 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160517.s1G5HPNr023284@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 05:17:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43959 - head/en_US.ISO8859-1/books/porters-handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 05:17:25 -0000 Author: wblock Date: Sun Feb 16 05:17:25 2014 New Revision: 43959 URL: http://svnweb.freebsd.org/changeset/doc/43959 Log: Whitespace-only fixes missed in earlier commits, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Sun Feb 16 04:57:45 2014 (r43958) +++ head/en_US.ISO8859-1/books/porters-handbook/security/chapter.xml Sun Feb 16 05:17:25 2014 (r43959) @@ -71,11 +71,11 @@ Please make sure that the port's revision is bumped as soon - as the vulnerability has been closed. That is how the users who + as the vulnerability has been closed. That is how the users who upgrade installed packages on a regular basis will see they need - to run an update. Besides, a new package will be built and + to run an update. Besides, a new package will be built and distributed over FTP and WWW mirrors, replacing the vulnerable - one. PORTREVISION should be bumped unless + one. PORTREVISION should be bumped unless PORTVERSION has changed in the course of correcting the vulnerability. That is you should bump PORTREVISION if you have added a patch file @@ -150,7 +150,7 @@ similar to HTML. The major difference is that XML is eXtensible, i.e., based on defining custom tags. Due to its intrinsic structure XML puts - otherwise amorphous data into shape. VuXML is particularly + otherwise amorphous data into shape. VuXML is particularly tailored to mark up descriptions of security vulnerabilities. From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 05:19:20 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0372BD2; Sun, 16 Feb 2014 05:19:20 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B5841DEA; Sun, 16 Feb 2014 05:19:20 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G5JKV5023590; Sun, 16 Feb 2014 05:19:20 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G5JK8g023589; Sun, 16 Feb 2014 05:19:20 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160519.s1G5JK8g023589@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 05:19:20 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43960 - head/en_US.ISO8859-1/books/porters-handbook/testing X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 05:19:20 -0000 Author: wblock Date: Sun Feb 16 05:19:20 2014 New Revision: 43960 URL: http://svnweb.freebsd.org/changeset/doc/43960 Log: Whitespace-only fixes missed in earlier commit, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Sun Feb 16 05:17:25 2014 (r43959) +++ head/en_US.ISO8859-1/books/porters-handbook/testing/chapter.xml Sun Feb 16 05:19:20 2014 (r43960) @@ -98,7 +98,7 @@ installed system mounted somewhere other than /. A port will actually install into DESTDIR/PREFIX, and register with the - package database in DESTDIR/var/db/pkg. As + package database in DESTDIR/var/db/pkg. As DESTDIR is handled automatically by the ports infrastructure with &man.chroot.8;, you do not need any modifications or any extra care to write @@ -168,7 +168,7 @@ If you are an avid ports contributor, you might want to take a look at Tinderbox. It is a - powerful system for building and testing ports. You can install + powerful system for building and testing ports. You can install Tinderbox using ports-mgmt/tinderbox port. Be sure to read supplied documentation since the configuration is From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 05:25:19 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C4B4CAA; Sun, 16 Feb 2014 05:25:19 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 453AD1EE2; Sun, 16 Feb 2014 05:25:19 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G5PJ9Y027180; Sun, 16 Feb 2014 05:25:19 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G5PJBt027179; Sun, 16 Feb 2014 05:25:19 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402160525.s1G5PJBt027179@svn.freebsd.org> From: Warren Block Date: Sun, 16 Feb 2014 05:25:19 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43961 - head/en_US.ISO8859-1/books/porters-handbook X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 05:25:19 -0000 Author: wblock Date: Sun Feb 16 05:25:18 2014 New Revision: 43961 URL: http://svnweb.freebsd.org/changeset/doc/43961 Log: Whitespace-only fixes, translators please ignore. Modified: head/en_US.ISO8859-1/books/porters-handbook/uses.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/uses.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/uses.xml Sun Feb 16 05:19:20 2014 (r43960) +++ head/en_US.ISO8859-1/books/porters-handbook/uses.xml Sun Feb 16 05:25:18 2014 (r43961) @@ -77,11 +77,11 @@ nestedfct, features Determines which compiler to use based on any given wishes. - Use c++11-lang if the port needs a C++11-capable - compiler, and c++11-lib if the port also needs - a C++11-ready standard library. If the port needs a compiler - understanding C++0X, C11, OpenMP, or nested functions, the - corresponding parameters can be used. Use + Use c++11-lang if the port needs a + C++11-capable compiler, and c++11-lib if the + port also needs a C++11-ready standard library. If the port needs + a compiler understanding C++0X, C11, OpenMP, or nested functions, + the corresponding parameters can be used. Use features to request a list of features supported by the default compiler. After including bsd.port.pre.mk the port can inspect the From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 07:19:26 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2103887; Sun, 16 Feb 2014 07:19:25 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D986115BE; Sun, 16 Feb 2014 07:19:25 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G7JPVZ075396; Sun, 16 Feb 2014 07:19:25 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G7JPMQ075395; Sun, 16 Feb 2014 07:19:25 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402160719.s1G7JPMQ075395@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 07:19:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43962 - head/ja_JP.eucJP/books/handbook/preface X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 07:19:26 -0000 Author: ryusuke Date: Sun Feb 16 07:19:25 2014 New Revision: 43962 URL: http://svnweb.freebsd.org/changeset/doc/43962 Log: - Merge the following from the English version: r24930 -> r27853 head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/preface/preface.xml Sun Feb 16 05:25:18 2014 (r43961) +++ head/ja_JP.eucJP/books/handbook/preface/preface.xml Sun Feb 16 07:19:25 2014 (r43962) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r24930 + Original revision: r27853 $FreeBSD$ --> @@ -355,6 +355,15 @@ ╔м╔ц╔х╔О║╪╔╞╔у╔║╔╓╔К╔╥╔╧╔ф╔Ю╓й╓и╓г╓╧║ё + , цо╟Х╡╫ From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 07:34:11 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74260960; Sun, 16 Feb 2014 07:34:11 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42FDA16B7; Sun, 16 Feb 2014 07:34:11 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1G7YBxf082936; Sun, 16 Feb 2014 07:34:11 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1G7YB5C082935; Sun, 16 Feb 2014 07:34:11 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402160734.s1G7YB5C082935@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 07:34:11 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43963 - head/ja_JP.eucJP/books/handbook/preface X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 07:34:11 -0000 Author: ryusuke Date: Sun Feb 16 07:34:10 2014 New Revision: 43963 URL: http://svnweb.freebsd.org/changeset/doc/43963 Log: - Merge the following from the English version: r27853 -> r29008 head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/preface/preface.xml Sun Feb 16 07:19:25 2014 (r43962) +++ head/ja_JP.eucJP/books/handbook/preface/preface.xml Sun Feb 16 07:34:10 2014 (r43963) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r27853 + Original revision: r29008 $FreeBSD$ --> @@ -34,7 +34,7 @@ - ╓к║╒ACPI ее╦╩╢имЩ║╒╔╞║╪╔М╔С╔╥╔╧╔ф╔Ю╔Ф║╪╔ф╔ё╔Й╔ф╔ё║╒ + ╓к║╒ACPI ее╦╩╢имЩ║╒cron ╔╥╔╧╔ф╔Ю╔Ф║╪╔ф╔ё╔Й╔ф╔ё║╒ ╓╙╓Х╓с╔╚║╪╔м╔К╔а╔Е║╪╔к╔С╔╟╔╙╔в╔╥╔Г╔С╓к╢ь╓╧╓К╓Х╓Йб©╓╞╓н╬ПйС╓╛ди╡ц╓╣╓Л╓ч╓╥╓©║ё @@ -75,15 +75,19 @@ , ╓к║╒ - б╬╓н╔А║╪╔Ке╬аВ╔╗║╪╔╦╔╖╔С╔х║╒SMTP ╓нг╖╬з║╒UUCP, fetchmail, - procmail ╓Дб╬╓н╧Беы╓йоцбЙ╓к╓д╓╓╓ф╓н╬ПйС╓╛ди╡ц╓╣╓Л╓ч╓╥╓©║ё + б╬╓н╔А║╪╔Ке╬аВ╔╗║╪╔╦╔╖╔С╔х║╒SMTP г╖╬з║╒UUCP, + fetchmail, + procmail + ╓Дб╬╓н╧Беы╓йоцбЙ╓к╓д╓╓╓ф╓н╬ПйС╓╛ди╡ц╓╣╓Л╓ч╓╥╓©║ё ╔м╔ц╔х╔О║╪╔╞╔╣║╪╔с╔╧╓н╬о╓╛║╒╓Ё╓нхг╓г©╥╓╥╓╞ди╡ц╓╣╓Л╓ч╓╥╓©║ё - ╓Ё╓н╬о╓г╓о║╒Apache HTTP ╔╣║╪╔п║╒FTPd ╓╙╓Х╓с Samba ╓Рмя╓╓╓ф - Microsoft Windows + ╓Ё╓н╬о╓г╓о║╒Apache HTTP ╔╣║╪╔п║╒ + fptd ╓╙╓Х╓с + Samba ╓Рмя╓╓╓ф + µsoft; &windows; ╔╞╔И╔╓╔╒╔С╔хмя╓к╔╣║╪╔п╓РюъдЙ╓╧╓КйЩк║╓й╓и╓Р╪Х╓Й╬Е╓╡╓ф╓╓╓ч╓╧║ё ╨ф╧╫ю╝╓к╓Х╓Й╓╓╓╞╓д╓╚╓нюА╓╛║╒ @@ -92,7 +96,8 @@ ╓к║╒ - FreeBSD ╓г╓н Bluetooth ╔г╔п╔╓╔╧╓н╩хмя║╒╔О╔╓╔Д╔Л╔╧╔м╔ц╔х╔О║╪╔╞╓нюъдЙ║╒ + FreeBSD ╓г╓н &bluetooth; ╔г╔п╔╓╔╧╓н╩хмя║╒ + ╔О╔╓╔Д╔Л╔╧╔м╔ц╔х╔О║╪╔╞╓нюъдЙ║╒ Asynchronous Transfer Mode (ATM) ╔м╔ц╔х╔О║╪╔╞╓к╢ь╓╧╓К╬ПйС╓╛ди╡ц╓╣╓Л╓ч╓╥╓©║ё @@ -425,7 +430,7 @@ LAN ╬Е╓нб╬╓н╔Ё╔С╔т╔Е║╪╔©╓х╔╓╔С╔©║╪╔м╔ц╔хюэбЁ╓н╤╕м╜║╒ ╧Беы╓й╔К║╪╔ф╔ё╔С╔╟╓к╢ь╓╧╓К╔х╔т╔ц╔╞╔╧║╒╔О╔╓╔Д╔Л╔╧╔м╔ц╔х╔О║╪╔╞║╒ - bluetooth, ATM, IPv6 еЫ║╧║╒ + &bluetooth;, ATM, IPv6 еЫ║╧║╒ ╔м╔ц╔х╔О║╪╔╞╓к╢ь╓╧╓К╓╣╓ч╓╤╓ч╓йоцбЙ╓Р╪Х╓Й╟╥╓ц╓ф╓╓╓ч╓╧║ё From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 14:22:22 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3B94418; Sun, 16 Feb 2014 14:22:22 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9550711B2; Sun, 16 Feb 2014 14:22:22 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1GEMMJE064390; Sun, 16 Feb 2014 14:22:22 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1GEMMpm064386; Sun, 16 Feb 2014 14:22:22 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402161422.s1GEMMpm064386@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 14:22:22 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43964 - head/ja_JP.eucJP/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 14:22:22 -0000 Author: ryusuke Date: Sun Feb 16 14:22:21 2014 New Revision: 43964 URL: http://svnweb.freebsd.org/changeset/doc/43964 Log: - Merge the following from the English version: r25717 -> r35386 head/ja_JP.eucJP/articles/contributors/Makefile r32675 -> r35368 head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile ============================================================================== --- head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 07:34:10 2014 (r43963) +++ head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 14:22:21 2014 (r43964) @@ -3,7 +3,7 @@ # # Article: Contributors to FreeBSD # -# Original revision: 1.10 +# Original revision: r35386 DOC?= article @@ -22,6 +22,7 @@ SRCS+= ${ORGDIR}/contrib.additional.xml SRCS+= ${ORGDIR}/contrib.committers.xml SRCS+= ${ORGDIR}/contrib.corealumni.xml SRCS+= ${ORGDIR}/contrib.develalumni.xml +SRCS+= ${ORGDIR}/contrib.develinmemoriam.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. Modified: head/ja_JP.eucJP/articles/contributors/article.xml ============================================================================== --- head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 07:34:10 2014 (r43963) +++ head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 14:22:21 2014 (r43964) @@ -8,7 +8,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r32675 + Original revision: r35368 $FreeBSD$ -->
@@ -396,6 +396,20 @@ &contrib.develalumni; + + Ё╚х╞╔а║╪╔Ю : к╢╓╞╓й╓И╓Л╓©Ё╚х╞╪т╓РеИ╓С╓г + + Ё╚х╞╔а║╪╔Ю (development team) + + FreeBSD ╔в╔М╔╦╔╖╔╞╔х╓╛╔╧╔©║╪╔х╓╥╓ф╓╚╓И╓нд╧╓╓г╞╥Н╓н╢ж╓к║╒ + ╩дг╟╓й╓╛╓Ик╢╓╞╓й╓И╓Л╓©Ё╚х╞╪т╓Б╓╓╓ч╓╧║ё + ╓Ё╓Ё╓г╓охЮ╓И╓н╩в╓╓╫п╓Р╩д╓╥╓ч╓╧║ё + + ╓ш╓эк╢╓╞╓й╓И╓Л╓©╣уг╞бЕ╫Г╓к: + + &contrib.develinmemoriam; + + BSD гию╦╔╫╔у╔х╔╕╔╖╔╒╓ь╓н╧в╦╔╪т From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 15:11:26 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5596483B; Sun, 16 Feb 2014 15:11:26 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3632015AE; Sun, 16 Feb 2014 15:11:26 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1GFBQSF086136; Sun, 16 Feb 2014 15:11:26 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1GFBPpD086134; Sun, 16 Feb 2014 15:11:25 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402161511.s1GFBPpD086134@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 15:11:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43965 - head/ja_JP.eucJP/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 15:11:26 -0000 Author: ryusuke Date: Sun Feb 16 15:11:25 2014 New Revision: 43965 URL: http://svnweb.freebsd.org/changeset/doc/43965 Log: - Merge the following from the English version: r35386 -> r36665 head/ja_JP.eucJP/articles/contributors/Makefile r35368 -> r38558 head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile ============================================================================== --- head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 14:22:21 2014 (r43964) +++ head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 15:11:25 2014 (r43965) @@ -3,7 +3,7 @@ # # Article: Contributors to FreeBSD # -# Original revision: r35386 +# Original revision: r36665 DOC?= article @@ -23,6 +23,7 @@ SRCS+= ${ORGDIR}/contrib.committers.xml SRCS+= ${ORGDIR}/contrib.corealumni.xml SRCS+= ${ORGDIR}/contrib.develalumni.xml SRCS+= ${ORGDIR}/contrib.develinmemoriam.xml +SRCS+= ${ORGDIR}/contrib.portmgralumni.xml URL_RELPREFIX?= ../../../.. DOC_PREFIX?= ${.CURDIR}/../../.. Modified: head/ja_JP.eucJP/articles/contributors/article.xml ============================================================================== --- head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 14:22:21 2014 (r43964) +++ head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 15:11:25 2014 (r43965) @@ -8,7 +8,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r35368 + Original revision: r38558 $FreeBSD$ -->
@@ -34,6 +34,13 @@ ╢Сбё╪т╔╝╔Ц╔И╔Й║╪ + + 2010 г╞╦╫╨ъ║╒╓Ё╓нюА╓о╡©г╞╓Ба╟╓н╓Б╓н╓к╓й╓ц╓ф╓╓╓ч╓╧║ё + ©Тг╞а╟╓╚╓И╓н╢Сиу╓к╓д╓╓╓ф╓о║╒ + ╓Ё╓Ё + ╓к╓ч╓х╓А╓И╓Л╓ф╓╓╓ч╓╧║ё + + FreeBSD ╔в╔М╔╦╔╖╔╞╔х╓о╪║╓н╢Сбё╪т╓к╡╦╣а╓Р╪У╓╠╓ф╓╙╓Й║╒ ╓Ё╓Ё╓к╦Ьи╫╓╥╓ф╢╤╪у╓н╟у╓Ри╫╓╥╓©╓╓╓х╩в╓╓╓ч╓╧║ё @@ -268,7 +275,7 @@ - Ernst Winter ewinter@lobo.muc.de ╓о║╒ + Ernst Winter (╦н©м) ╓о║╒ ╓Ё╓н╔в╔М╔╦╔╖╔╞╔х╓ь 2.88 MB ╓н╔у╔М╔ц╔т║╪╔и╔И╔╓╔ж╓РдС╤║╓╥╓ф╓╞╓ю╓╣╓╓╓ч╓╥╓©║ё ╓╕╓ч╓╞╓╓╓╠╓п║╒ @@ -396,6 +403,20 @@ &contrib.develalumni; + + Ports Management ╔а║╪╔Ю╓нб╢╤хю╦ + + portmgr ╔а║╪╔Ю (portmgr team) + ╪║╓к╓╒╓╡╓К©м║╧╓о () ╓г╣╜╓╥╓©╢Э╢ж║╒FreeBSD + portmgr ╔а║╪╔Ю╓н╔А╔С╔п║╪╓г╓╥╓©║ёFreeBSD + ╔в╔М╔╦╔╖╔╞╔х╓к╓╙╓╠╓КхЮ╓И╓неьно╓к╢╤╪у╓н╟у╓Ри╫╓╥╓ч╓╧║ё + + + ╓ю╓╓╓©╓╓╓н╣уг╞бЕ╫Г + + &contrib.portmgralumni; + + Ё╚х╞╔а║╪╔Ю : к╢╓╞╓й╓И╓Л╓©Ё╚х╞╪т╓РеИ╓С╓г From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 15:21:33 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7397C6F; Sun, 16 Feb 2014 15:21:33 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1A6F1652; Sun, 16 Feb 2014 15:21:33 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1GFLXG3091174; Sun, 16 Feb 2014 15:21:33 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1GFLXsY091172; Sun, 16 Feb 2014 15:21:33 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402161521.s1GFLXsY091172@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sun, 16 Feb 2014 15:21:33 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43966 - head/ja_JP.eucJP/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 15:21:34 -0000 Author: ryusuke Date: Sun Feb 16 15:21:33 2014 New Revision: 43966 URL: http://svnweb.freebsd.org/changeset/doc/43966 Log: - Merge the following from the English version: r36665 -> r39631 head/ja_JP.eucJP/articles/contributors/Makefile r38558 -> r43184 head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/Makefile ============================================================================== --- head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 15:11:25 2014 (r43965) +++ head/ja_JP.eucJP/articles/contributors/Makefile Sun Feb 16 15:21:33 2014 (r43966) @@ -3,7 +3,7 @@ # # Article: Contributors to FreeBSD # -# Original revision: r36665 +# Original revision: r39631 DOC?= article Modified: head/ja_JP.eucJP/articles/contributors/article.xml ============================================================================== --- head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 15:11:25 2014 (r43965) +++ head/ja_JP.eucJP/articles/contributors/article.xml Sun Feb 16 15:21:33 2014 (r43966) @@ -8,7 +8,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r38558 + Original revision: r43184 $FreeBSD$ -->
@@ -17,7 +17,6 @@ &tm-attrib.freebsd; - &tm-attrib.cvsup; &tm-attrib.sun; &tm-attrib.general; From owner-svn-doc-head@FreeBSD.ORG Sun Feb 16 19:45:09 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D27AF4D; Sun, 16 Feb 2014 19:45:09 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7678518E3; Sun, 16 Feb 2014 19:45:09 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1GJj9mO009417; Sun, 16 Feb 2014 19:45:09 GMT (envelope-from dim@svn.freebsd.org) Received: (from dim@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1GJj9Ka009416; Sun, 16 Feb 2014 19:45:09 GMT (envelope-from dim@svn.freebsd.org) Message-Id: <201402161945.s1GJj9Ka009416@svn.freebsd.org> From: Dimitry Andric Date: Sun, 16 Feb 2014 19:45:09 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43967 - head/en_US.ISO8859-1/books/porters-handbook X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 19:45:09 -0000 Author: dim (src committer) Date: Sun Feb 16 19:45:08 2014 New Revision: 43967 URL: http://svnweb.freebsd.org/changeset/doc/43967 Log: Document __FreeBSD_version value 1100009. Modified: head/en_US.ISO8859-1/books/porters-handbook/versions.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/versions.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/versions.xml Sun Feb 16 15:21:33 2014 (r43966) +++ head/en_US.ISO8859-1/books/porters-handbook/versions.xml Sun Feb 16 19:45:08 2014 (r43967) @@ -4978,3 +4978,10 @@ it was never committed: 11.0-CURRENT after libc++ 3.4 ABI compatibility fix (rev 261801). + + + 1100009 + February 16, 2014 + 11.0-CURRENT after upgrade of llvm/clang to 3.4 release + (rev 261991). + From owner-svn-doc-head@FreeBSD.ORG Mon Feb 17 14:28:00 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23543E74; Mon, 17 Feb 2014 14:28:00 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC2B173A; Mon, 17 Feb 2014 14:28:00 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1HERxFb084437; Mon, 17 Feb 2014 14:27:59 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1HERxxK084436; Mon, 17 Feb 2014 14:27:59 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402171427.s1HERxxK084436@svn.freebsd.org> From: Ryusuke SUZUKI Date: Mon, 17 Feb 2014 14:27:59 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43968 - head/en_US.ISO8859-1/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:28:00 -0000 Author: ryusuke Date: Mon Feb 17 14:27:59 2014 New Revision: 43968 URL: http://svnweb.freebsd.org/changeset/doc/43968 Log: o was was -> was Modified: head/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml Modified: head/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml ============================================================================== --- head/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml Sun Feb 16 19:45:08 2014 (r43967) +++ head/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml Mon Feb 17 14:27:59 2014 (r43968) @@ -40,7 +40,7 @@ &a.itojun.email; (1997 - 2001; RIP 2008) Known to everyone as itojun, - Jun-ichiro Hagino was was a core researcher at the + Jun-ichiro Hagino was a core researcher at the KAME Project, which aimed to provide IPv6 and IPsec technology in freely redistributable form. Much of this code was incorporated From owner-svn-doc-head@FreeBSD.ORG Mon Feb 17 14:42:18 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3B2B521; Mon, 17 Feb 2014 14:42:18 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C06B318E7; Mon, 17 Feb 2014 14:42:18 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1HEgIKt091630; Mon, 17 Feb 2014 14:42:18 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1HEgISK091625; Mon, 17 Feb 2014 14:42:18 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402171442.s1HEgISK091625@svn.freebsd.org> From: Ryusuke SUZUKI Date: Mon, 17 Feb 2014 14:42:18 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43969 - head/ja_JP.eucJP/articles/contributors X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:42:18 -0000 Author: ryusuke Date: Mon Feb 17 14:42:18 2014 New Revision: 43969 URL: http://svnweb.freebsd.org/changeset/doc/43969 Log: o Refine translation. Modified: head/ja_JP.eucJP/articles/contributors/article.xml Modified: head/ja_JP.eucJP/articles/contributors/article.xml ============================================================================== --- head/ja_JP.eucJP/articles/contributors/article.xml Mon Feb 17 14:27:59 2014 (r43968) +++ head/ja_JP.eucJP/articles/contributors/article.xml Mon Feb 17 14:42:18 2014 (r43969) @@ -364,8 +364,8 @@ FreeBSD ╓нЁ╚х╞╪т╓©╓а - (CVS ╓н) commit╓╧╓К╦╒мЬ╓Р╩Щ╓ц╓ф╓╓╓ф║╒FreeBSD - ╓н╔╫║╪╔╧╔д╔Й║╪╓к╓д╓╓╓ф ╨Н╤х╓Р╓╙╓Ё╓й╓ц╓ф╓╓╓К©м║╧╓╛╓╓╓ч╓╧║ё + commit ╓н╦╒╦б╓Р╩Щ╓ц╓ф╓╓╓ф║╒FreeBSD + ╓н╔╫║╪╔╧╔д╔Й║╪╓к╓д╓╓╓ф╨Н╤х╓Р╓╙╓Ё╓й╓ц╓ф╓╓╓К©м║╧╓╛╓╓╓ч╓╧║ё ╓╧╓ы╓ф╓н╔Ё╔╒╔а║╪╔Ю╓н╔А╔С╔п╓о╓ч╓©Ё╚х╞╪т╓г╓Б╓╒╓Й╓ч╓╧║ё (ю╚╓г╔╒╔К╔у╔║╔ы╔ц╔х╫Г) From owner-svn-doc-head@FreeBSD.ORG Mon Feb 17 16:36:10 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9906CBAF; Mon, 17 Feb 2014 16:36:10 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84FF11535; Mon, 17 Feb 2014 16:36:10 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1HGaAad039209; Mon, 17 Feb 2014 16:36:10 GMT (envelope-from eadler@svn.freebsd.org) Received: (from eadler@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1HGaA3E039208; Mon, 17 Feb 2014 16:36:10 GMT (envelope-from eadler@svn.freebsd.org) Message-Id: <201402171636.s1HGaA3E039208@svn.freebsd.org> From: Eitan Adler Date: Mon, 17 Feb 2014 16:36:10 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43970 - head/en_US.ISO8859-1/articles/nanobsd X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:36:10 -0000 Author: eadler Date: Mon Feb 17 16:36:10 2014 New Revision: 43970 URL: http://svnweb.freebsd.org/changeset/doc/43970 Log: nanobsd article: remove NO_CVS from example CVS has been removed from the base system Modified: head/en_US.ISO8859-1/articles/nanobsd/article.xml Modified: head/en_US.ISO8859-1/articles/nanobsd/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/nanobsd/article.xml Mon Feb 17 14:42:18 2014 (r43969) +++ head/en_US.ISO8859-1/articles/nanobsd/article.xml Mon Feb 17 16:36:10 2014 (r43970) @@ -358,7 +358,6 @@ NO_PAM=YES CONF_INSTALL=' NO_ACPI=YES NO_BLUETOOTH=YES -NO_CVS=YES NO_FORTRAN=YES NO_HTML=YES NO_LPR=YES From owner-svn-doc-head@FreeBSD.ORG Mon Feb 17 16:53:48 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFB6C89D; Mon, 17 Feb 2014 16:53:48 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C85FA16D9; Mon, 17 Feb 2014 16:53:48 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1HGrmi0047288; Mon, 17 Feb 2014 16:53:48 GMT (envelope-from eadler@svn.freebsd.org) Received: (from eadler@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1HGrmMk047287; Mon, 17 Feb 2014 16:53:48 GMT (envelope-from eadler@svn.freebsd.org) Message-Id: <201402171653.s1HGrmMk047287@svn.freebsd.org> From: Eitan Adler Date: Mon, 17 Feb 2014 16:53:48 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43971 - head/en_US.ISO8859-1/articles/nanobsd X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:53:48 -0000 Author: eadler Date: Mon Feb 17 16:53:48 2014 New Revision: 43971 URL: http://svnweb.freebsd.org/changeset/doc/43971 Log: nanobsd article: change deprecated NO_ flags to WITHOUT_ versions Reviwed by: imp Modified: head/en_US.ISO8859-1/articles/nanobsd/article.xml Modified: head/en_US.ISO8859-1/articles/nanobsd/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/nanobsd/article.xml Mon Feb 17 16:36:10 2014 (r43970) +++ head/en_US.ISO8859-1/articles/nanobsd/article.xml Mon Feb 17 16:53:48 2014 (r43971) @@ -350,36 +350,36 @@ NANO_KERNEL=MYKERNEL NANO_IMAGES=2 CONF_BUILD=' -NO_KLDLOAD=YES -NO_NETGRAPH=YES -NO_PAM=YES +WITHOUT_KLDLOAD=YES +WITHOUT_NETGRAPH=YES +WITHOUT_PAM=YES ' CONF_INSTALL=' -NO_ACPI=YES -NO_BLUETOOTH=YES -NO_FORTRAN=YES -NO_HTML=YES -NO_LPR=YES -NO_MAN=YES -NO_SENDMAIL=YES -NO_SHAREDOCS=YES -NO_EXAMPLES=YES -NO_INSTALLLIB=YES -NO_CALENDAR=YES -NO_MISC=YES -NO_SHARE=YES +WITHOUT_ACPI=YES +WITHOUT_BLUETOOTH=YES +WITHOUT_FORTRAN=YES +WITHOUT_HTML=YES +WITHOUT_LPR=YES +WITHOUT_MAN=YES +WITHOUT_SENDMAIL=YES +WITHOUT_SHAREDOCS=YES +WITHOUT_EXAMPLES=YES +WITHOUT_INSTALLLIB=YES +WITHOUT_CALENDAR=YES +WITHOUT_MISC=YES +WITHOUT_SHARE=YES ' CONF_WORLD=' -NO_BIND=YES -NO_MODULES=YES -NO_KERBEROS=YES -NO_GAMES=YES -NO_RESCUE=YES -NO_LOCALES=YES -NO_SYSCONS=YES -NO_INFO=YES +WITHOUT_BIND=YES +WITHOUT_MODULES=YES +WITHOUT_KERBEROS=YES +WITHOUT_GAMES=YES +WITHOUT_RESCUE=YES +WITHOUT_LOCALES=YES +WITHOUT_SYSCONS=YES +WITHOUT_INFO=YES ' FlashDevice SanDisk 1G From owner-svn-doc-head@FreeBSD.ORG Mon Feb 17 18:33:39 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A721D58B; Mon, 17 Feb 2014 18:33:39 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92E3512B5; Mon, 17 Feb 2014 18:33:39 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1HIXdDg090947; Mon, 17 Feb 2014 18:33:39 GMT (envelope-from jgh@svn.freebsd.org) Received: (from jgh@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1HIXdx0090946; Mon, 17 Feb 2014 18:33:39 GMT (envelope-from jgh@svn.freebsd.org) Message-Id: <201402171833.s1HIXdx0090946@svn.freebsd.org> From: Jason Helfman Date: Mon, 17 Feb 2014 18:33:39 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43972 - head/share/xml X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:33:39 -0000 Author: jgh Date: Mon Feb 17 18:33:39 2014 New Revision: 43972 URL: http://svnweb.freebsd.org/changeset/doc/43972 Log: - there are no longer java news updates since r43646 Spotted by: ryusuke Approved by: bcr (mentor) Modified: head/share/xml/libcommon.xsl Modified: head/share/xml/libcommon.xsl ============================================================================== --- head/share/xml/libcommon.xsl Mon Feb 17 16:53:48 2014 (r43971) +++ head/share/xml/libcommon.xsl Mon Feb 17 18:33:39 2014 (r43972) @@ -463,7 +463,6 @@ be checked for project specific updates.

From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 00:11:34 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0D5236B; Tue, 18 Feb 2014 00:11:34 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA70C1174; Tue, 18 Feb 2014 00:11:34 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1I0BYi9025483; Tue, 18 Feb 2014 00:11:34 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1I0BYaT025482; Tue, 18 Feb 2014 00:11:34 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402180011.s1I0BYaT025482@svn.freebsd.org> From: Warren Block Date: Tue, 18 Feb 2014 00:11:34 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43973 - head/en_US.ISO8859-1/books/handbook/advanced-networking X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:11:35 -0000 Author: wblock Date: Tue Feb 18 00:11:34 2014 New Revision: 43973 URL: http://svnweb.freebsd.org/changeset/doc/43973 Log: Whitespace-only fixes. Modified version of patch from Allan Jude . Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Mon Feb 17 18:33:39 2014 (r43972) +++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Tue Feb 18 00:11:34 2014 (r43973) @@ -103,9 +103,15 @@ - routing - gateway - subnet + + routing + + + gateway + + + subnet + For one machine to be able to find another over a network, there must be a mechanism in place to describe how to get from @@ -143,12 +149,18 @@ host2 0:e0:a8:37:8:1e UHLW host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 - default route + + default route + + The first two lines specify the default route, described in more detail in , and the localhost route. - loopback device + + loopback device + + The interface (Netif column) that this routing table specifies to use for localhost is lo0, @@ -160,6 +172,7 @@ host2.example.com link#1 UC Ethernet MAC address + The addresses beginning with 0:e0: are Ethernet hardware addresses, also known as MAC @@ -175,7 +188,9 @@ host2.example.com link#1 UC calculates routes to local hosts based upon a shortest path determination. - subnet + + subnet + &os; will add subnet routes for the local subnet. 10.20.30.255 is the @@ -271,7 +286,9 @@ host2.example.com link#1 UC Default Routes - default route + + default route + When the local system needs to make a connection to a remote host, it checks the routing table to determine if a @@ -408,7 +425,9 @@ host2.example.com link#1 UC Dual Homed Hosts - dual homed hosts + + dual homed hosts + A dual-homed system is a host which resides on two different networks. @@ -436,7 +455,9 @@ host2.example.com link#1 UC Building a Router - router + + router + A network router is a system that forwards packets from one interface to another. Internet standards and good @@ -452,9 +473,16 @@ host2.example.com link#1 UC 1. To stop routing, reset this to 0. - BGP - RIP - OSPF + + BGP + + + RIP + + + OSPF + + The new router will need routes to know where to send the traffic. If the network is simple enough, static routes can be used. &os; comes with the standard BSD routing daemon @@ -649,6 +677,7 @@ route_net2="-net 192.168.1.0/24 192.168. kernel options MROUTING + &os; natively supports both multicast applications and multicast routing. Multicast applications do not require any special configuration of &os;; as applications will generally @@ -688,7 +717,9 @@ route_net2="-net 192.168.1.0/24 192.168. - wireless networking + + wireless networking + 802.11 wireless networking @@ -2247,7 +2278,9 @@ freebsdap 00:11:95:c3:0d:ac 1 USB Tethering - tether + + tether + Many cellphones provide the option to share their data connection over USB (often called "tethering"). This feature @@ -2287,7 +2320,10 @@ freebsdap 00:11:95:c3:0d:ac 1 - Bluetooth + + Bluetooth + + Introduction @@ -2359,7 +2395,9 @@ Number of SCO packets: 8 Host Controller Interface (<acronym>HCI</acronym>) - HCI + + HCI + The Host Controller Interface (HCI) provides a command interface to the baseband controller and @@ -2453,7 +2491,9 @@ Reason: Connection terminated by local h Logical Link Control and Adaptation Protocol (<acronym>L2CAP</acronym>) - L2CAP + + L2CAP + The Logical Link Control and Adaptation Protocol (L2CAP) provides connection-oriented and @@ -2627,7 +2667,9 @@ hcsecd[16484]: Sending PIN_Code_Reply to Service Discovery Protocol (<acronym>SDP</acronym>) - SDP + + SDP + The Service Discovery Protocol (SDP) provides the means for client applications to discover the @@ -2811,7 +2853,10 @@ Bluetooth Profile Descriptor List: <acronym>OBEX</acronym> Object Push (<acronym>OPUSH</acronym>) Profile - OBEX + + OBEX + + OBEX is a widely used protocol for simple file transfers between mobile devices. Its main use is in infrared communication, where it is used for generic @@ -2939,9 +2984,13 @@ rfcomm_sppd[94692]: Starting on /dev/tty Introduction - IP - subnet - bridge + + IP subnet + + + bridge + + It is sometimes useful to divide one physical network, such as an Ethernet segment, into two separate network segments without having to create IP @@ -2981,8 +3030,12 @@ rfcomm_sppd[94692]: Starting on /dev/tty Filtering/Traffic Shaping Firewall - firewall - NAT + + firewall + + + NAT + A common situation is where firewall functionality is needed without routing or Network Address Translation @@ -2996,9 +3049,16 @@ rfcomm_sppd[94692]: Starting on /dev/tty on the network. In this situation, using a router-based firewall is difficult because of subnetting issues. - router - DSL - ISDN + + router + + + DSL + + + ISDN + + A bridge-based firewall can be configured and dropped into the path just downstream of the DSL or ISDN router without any @@ -3119,7 +3179,9 @@ ifconfig_fxp1="up" Firewalling - firewall + + firewall + When packet filtering is enabled, bridged packets will pass through the filter inbound on the originating interface @@ -3406,12 +3468,24 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefault - lagg - failover - FEC - LACP - loadbalance - roundrobin + + lagg + + + failover + + + FEC + + + LACP + + + loadbalance + + + roundrobin + &os; provides the &man.lagg.4; interface which can be used to aggregate multiple network interfaces into one virtual @@ -3752,8 +3826,12 @@ ifconfig_lagg0="laggp - diskless workstation - diskless operation + + diskless workstation + + + diskless operation + A &os; machine can boot over the network and operate without a local disk, using file systems mounted from an @@ -4645,6 +4723,7 @@ Received 264951 bytes in 0.1 seconds &man.natd.8; + &os;'s Network Address Translation (NAT) daemon, &man.natd.8;, accepts incoming raw IP packets, changes the @@ -4661,6 +4740,7 @@ Received 264951 bytes in 0.1 seconds NAT + The most common use of NAT is to perform what is commonly known as Internet Connection Sharing. @@ -4766,6 +4846,7 @@ ipdivert_load="YES" kernel configuration + When modules are not an option or if it is preferable to build all the required features into a custom kernel, the following options must be in the custom kernel configuration @@ -4931,7 +5012,10 @@ redirect_port tcp 192.168.0.3:80 80 Address Redirection - address redirection + + address redirection + + Address redirection is useful if more than one IP address is available. Each LAN client can be assigned its own From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 02:26:28 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F91F7B2; Tue, 18 Feb 2014 02:26:28 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6045A1A7D; Tue, 18 Feb 2014 02:26:28 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1I2QSMG076423; Tue, 18 Feb 2014 02:26:28 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1I2QS0x076422; Tue, 18 Feb 2014 02:26:28 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402180226.s1I2QS0x076422@svn.freebsd.org> From: Warren Block Date: Tue, 18 Feb 2014 02:26:28 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:26:28 -0000 Author: wblock Date: Tue Feb 18 02:26:27 2014 New Revision: 43974 URL: http://svnweb.freebsd.org/changeset/doc/43974 Log: Whitespace-only changes, translators please ignore. Patch from Allan Jude . Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Tue Feb 18 00:11:34 2014 (r43973) +++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Tue Feb 18 02:26:27 2014 (r43974) @@ -499,8 +499,13 @@ host2.example.com link#1 UC Setting Up Static Routes - AlHoangContributed - by + + + Al + Hoang + + Contributed by + @@ -709,11 +714,23 @@ route_net2="-net 192.168.1.0/24 192.168. Wireless Networking - Loader - - MarcFonvieille - - MurrayStokely + + + Loader + + + + + Marc + Fonvieille + + + + + Murray + Stokely + + @@ -2976,8 +2993,13 @@ rfcomm_sppd[94692]: Starting on /dev/tty Bridging - AndrewThompsonWritten - by + + + Andrew + Thompson + + Written by + @@ -3463,8 +3485,13 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefault Link Aggregation and Failover - AndrewThompsonWritten - by + + + Andrew + Thompson + + Written by + @@ -3817,12 +3844,22 @@ ifconfig_lagg0="laggp Diskless Operation - Jean-FrançoisDockèsUpdated - by + + + Jean-François + Dockès + + Updated by + - AlexDupreReorganized - and enhanced by + + + Alex + Dupre + + Reorganized and enhanced by + @@ -4712,8 +4749,13 @@ Received 264951 bytes in 0.1 secondsNetwork Address Translation - ChernLeeContributed - by + + + Chern + Lee + + Contributed by + @@ -5615,10 +5657,15 @@ redirect_port tcp 192.168.0.3:80 80 Asynchronous Transfer Mode (<acronym>ATM</acronym>) - HartiBrandtContributed by + + + Harti + Brandt + + Contributed by + - Configuring Classical <acronym>IP</acronym> over <acronym>ATM</acronym> From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 02:30:24 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 409A183B; Tue, 18 Feb 2014 02:30:24 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2BF981A92; Tue, 18 Feb 2014 02:30:24 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1I2UON4077042; Tue, 18 Feb 2014 02:30:24 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1I2UOAA077041; Tue, 18 Feb 2014 02:30:24 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402180230.s1I2UOAA077041@svn.freebsd.org> From: Warren Block Date: Tue, 18 Feb 2014 02:30:24 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43975 - head/en_US.ISO8859-1/books/handbook/advanced-networking X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:30:24 -0000 Author: wblock Date: Tue Feb 18 02:30:23 2014 New Revision: 43975 URL: http://svnweb.freebsd.org/changeset/doc/43975 Log: Update a couple of author entries. Patch from Allan Jude . Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Tue Feb 18 02:26:27 2014 (r43974) +++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Tue Feb 18 02:30:23 2014 (r43975) @@ -2328,11 +2328,7 @@ freebsdap 00:11:95:c3:0d:ac 1 Lucistnik Written by - -
- pav@FreeBSD.org -
- + pav@FreeBSD.org @@ -5861,7 +5857,8 @@ route_hostD="192.168.173.4 hatm0 0 102 l Contributed by - + + Allan From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 02:38:52 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CB3A9AF; Tue, 18 Feb 2014 02:38:52 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 28BC81B2C; Tue, 18 Feb 2014 02:38:52 +0000 (UTC) Received: from delphij-macbook.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 8AC3ED062; Mon, 17 Feb 2014 18:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1392691131; bh=Jbl9CEtnoOY5nhnxi0J5qB0guPIgK/mlw8SF6gnF2Aw=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=aSlCW3/E8Iqbcx755Inrw1/VdXqSCclQDMsOXCpdqE4vSXjZA3wNlHDsIYrMCBPfE iUBnEhXmjPckFdejEH/1CGzOQYzfksw9IKQlcGihWh55GSVbVJi3xs+JQZkbj9DJ9X k1VeieO9RB7MezYbSe8D5uvQow7FZstr3eEGJobw= Message-ID: <5302C7B9.7090208@delphij.net> Date: Mon, 17 Feb 2014 18:38:49 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Warren Block , doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking References: <201402180226.s1I2QS0x076422@svn.freebsd.org> In-Reply-To: <201402180226.s1I2QS0x076422@svn.freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:38:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 (Picking a random changeset, not specific to this one). On 2/17/14, 6:26 PM, Warren Block wrote: > Author: wblock Date: Tue Feb 18 02:26:27 2014 New Revision: 43974 > URL: http://svnweb.freebsd.org/changeset/doc/43974 > > Log: Whitespace-only changes, translators please ignore. Patch > from Allan Jude . Can we stop doing this, or do it all in one time in less frequent manner? This type of changes is VERY VERY VERY painful for translators and give a great burden to us because it makes it almost impossible to use simple 'svn up' to catch up. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTAse4AAoJEJW2GBstM+nsfHEQAKMUmqZ3SzvTc45kNvWMOv2H sTubfCqScp+oahQLlXNd/yDB70QnCcAAbQk+pmV0jpsZmM/wrA5QNsRxNXG6Q7Fx FM5vF8wP+GaD1tcCprHG1LR4zIpHBS85/dfhcYCMXh9KSGU/26Qd/CsdGUqC6R8q h9AwvA95stDN2adyHD8JGi7zm0nGj4O+/pXoxCEh0Sg6nC8y44oYmI/L80iSlIed 8YXsOfegYA57FsOM1yP4ZT9ur9Oe7CMTFTZB3oqf9ys0KvxSxZnYDnbSjSt2lIw5 rWprHDb73VvPxFlAPdSCIkeSp9Fs6x8LRyKB8Ub7hncNVO1i+8b+usC2ILCgPK3L UiJCVjM7kGjToTOoQjaQVpDNrL6csPAhPmRZ7LDyWIYa/k8xzGyBkL3cjKCERXOs 9maWkOXmejHeAG/J2RQKIBiGyEg4sB9ctz314Wtj+bY1A2T1z7LrAqwo/NEZl3H5 pekOKKnMk3H/hDQrU1K30YJCTRaOX8tt30caKMucu+rvvPey+EP4NfLjD7CxFSZF SCExIJ5+SD73ZuKN5eLEr0IjqFaulN0qXfL5PzhpY44xaC6vVdXhYbTdYy5pv9/I qvkxzeCJlm/smIyaD6B1qb5cNZ50iLdYaNRByxoFvdKnTtpjJ7yRfGiTGQSeALdx OG+PkNtFv9ctkGu6uXdK =c6Do -----END PGP SIGNATURE----- From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 03:10:14 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01ACD430; Tue, 18 Feb 2014 03:10:14 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 924B411EF; Tue, 18 Feb 2014 03:10:13 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s1I3A54m043419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Feb 2014 20:10:05 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s1I3A5L7043416; Mon, 17 Feb 2014 20:10:05 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 17 Feb 2014 20:10:05 -0700 (MST) From: Warren Block To: d@delphij.net Subject: Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking In-Reply-To: <5302C7B9.7090208@delphij.net> Message-ID: References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 17 Feb 2014 20:10:05 -0700 (MST) Cc: svn-doc-head@freebsd.org, svn-doc-all@freebsd.org, doc-committers@freebsd.org, Warren Block X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:10:14 -0000 On Mon, 17 Feb 2014, Xin Li wrote: > (Picking a random changeset, not specific to this one). > > On 2/17/14, 6:26 PM, Warren Block wrote: >> Author: wblock Date: Tue Feb 18 02:26:27 2014 New Revision: 43974 >> URL: http://svnweb.freebsd.org/changeset/doc/43974 >> >> Log: Whitespace-only changes, translators please ignore. Patch >> from Allan Jude . > > Can we stop doing this, or do it all in one time in less frequent > manner? This type of changes is VERY VERY VERY painful for > translators and give a great burden to us because it makes it almost > impossible to use simple 'svn up' to catch up. I'm sorry, these multiple whitespace changes were my fault due to a mixup with Allan Jude's original patch. Normally, it would have been a single commit. I apologize for this difficulty. Would it help if these changes were reverted with a "reverse merge" of r43920, r43921, r43973, r43974, and r43975, then recommitted with the whitespace patches combined, or is it too late for that? If there is any way I or other committers can make this easier for translators, please post on the -doc mailing list or to me invididually. We are also trying to modernize the translation process, and automate some of the work that translators are currently forced to do. Anyone who would like to help with that is welcome. From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 03:59:30 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF18160B; Tue, 18 Feb 2014 03:59:30 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCB33171C; Tue, 18 Feb 2014 03:59:30 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1I3xUPE013092; Tue, 18 Feb 2014 03:59:30 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1I3xUm3013091; Tue, 18 Feb 2014 03:59:30 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402180359.s1I3xUm3013091@svn.freebsd.org> From: Warren Block Date: Tue, 18 Feb 2014 03:59:30 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43976 - head/en_US.ISO8859-1/htdocs X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:59:31 -0000 Author: wblock Date: Tue Feb 18 03:59:30 2014 New Revision: 43976 URL: http://svnweb.freebsd.org/changeset/doc/43976 Log: Update the features page. Modified version of patch supplied. PR: docs/186614 Submitted by: Allan Jude Modified: head/en_US.ISO8859-1/htdocs/features.xml Modified: head/en_US.ISO8859-1/htdocs/features.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/features.xml Tue Feb 18 02:30:23 2014 (r43975) +++ head/en_US.ISO8859-1/htdocs/features.xml Tue Feb 18 03:59:30 2014 (r43976) @@ -36,11 +36,68 @@ diverse and world-wide membership of the volunteer &os; Project.

-

&os; 9.0, brings many new features +

&os; 10.X introduced many new features + and replaces many legacy tools with updated versions.

+ +
    +
  • bhyve: + A new BSD licensed, legacy-free hypervisor has been imported + to the &os; base system. It is currently able to run all + supported versions of &os;, and with the help of the + grub-bhyve port, OpenBSD and Linux.
    • + +
  • KMS And New drm2 Video Drivers: + The new drm2 driver provides support for AMD GPUs up to the + Radeon HD 6000 series and provides partial support for + the Radeon HD 7000 family. &os; now also supports + Kernel Mode Setting for AMD and Intel GPUs.
    • + +
  • Capsicum Enabled By Default: + Capsicum has been enabled in the kernel by default, allowing + sandboxing of several programs that work within the + "capabilities mode", such as: +
      +
    • tcpdump
      • +
    • dhclient
      • +
    • hast
      • +
    • rwhod
      • +
    • kdump
      • +
    +
    • + +
  • New Binary Packaging System: + &os; now uses pkg, a vastly improved package management + system that supports multiple repositories, signed packages, + and safe upgrades. The improved system is combined with + more frequent official package builds for all supported + platforms and a new stable branch of the ports tree for + better long term support.
    • + +
  • Unmapped I/O: + The newly implemented concept of unmapped VMIO buffers + eliminates the need to perform costly TLB shootdowns for + buffer creation and reuse, reducing system CPU time by up to + 25-30% on large SMP machines under heavy I/O load.
    • +
+ +

&os; 9.X brought many new features and performance enhancements with a special focus on desktop - support and security features.

+ support and security.

    +
  • OpenZFS: + &os; 9.2 includes OpenZFS v5000 (Feature Flags), including + the feature flags: +
      +
    • async_destroy
      • +
    • empty_bpobj
      • +
    • lz4_compress
      • +
    + which allow ZFS destroy operations to happen in the + background, make snapshots consume less disk space, and + offers a better compression algorithm for compressed + datasets.
    • +
  • Capsicum Capability Mode: Capsicum is a set of features for sandboxing support, using a capability model in which the capabilities are file @@ -59,14 +116,14 @@ These allow a structured way to dynamically extend the kernel at runtime in an ABI preserving manner.
    • -
  • Accounting API: has been implemented. It can keep +
  • Accounting API has been implemented. It can keep per-process, per-jail, and per-login class resource accounting information. Note that this is neither built nor installed by default. To build and install this, specify the option RACCT in the kernel configuration file and rebuild the base system as described in the &os; Handbook.
    • -
  • Resource-limiting API: has been implemented. +
  • Resource-limiting API has been implemented. It works in conjunction with the RACCT resource accounting implementation and takes user-configurable actions based on the set of rules it maintains and the current resource @@ -74,17 +131,17 @@ rules in userland. Note that this is neither built nor installed by default.
    • -
  • USB: subsystem now supports USB packet filter. +
  • USB subsystem now supports USB packet filter. This allows capturing packets which go through each USB host. The architecture of the packet filter is similar to that of bpf. The userland program usbdump(8) has been added.
    • -
  • Infiniband support:, OFED (OpenFabrics Enterprise +
  • Infiniband support: OFED (OpenFabrics Enterprise Distribution) version 1.5.3 has been imported into the base system.
    • -
  • TCP/IP network: stack now supports the mod_cc(9) +
  • TCP/IP network stack now supports the mod_cc(9) pluggable congestion control framework. This allows TCP congestion control algorithms to be implemented as dynamically loadable kernel modules. Many kernel @@ -96,42 +153,48 @@ can be set by a new sysctl(8) variable net.inet.tcp.cc.algorithm.
    • -
  • SU+J: &os;'s Fast File System now supports soft +
  • SU+J: &os;'s Fast File System now supports soft updates with journaling. It introduces an intent log into a softupdates-enabled file system which eliminates the need for background fsck(8) even on unclean shutdowns.
-

&os; 8.X brought many new - features and performance enhancements. With special focus on - a new USB stack, &os; 8.X also shipped with experimental support - for NFSv4. A new TTY layer was introduced, which improves - scalability and resources handling in SMP enabled systems.

+

&os; includes a number of other great features:

    -
  • Netisr framework: has been reimplemented for - parallel threading support. This is a kernel network - dispatch interface which allows device drivers (and other - packet sources) to direct packets to protocols for directly - dispatched or deferred processing. The new implementation - supports up to one netisr thread per CPU, and several - benchmarks on SMP machines show substantial performance - improvement over the previous version.
    • - -
  • Jail improvements: Jails now support multiple IPv4 - and IPv6 addresses per jail, and also support SCTP. - Hierarchies of jails (jails-within-jails) are now supported, - and jails can now be restricted to subsets of available - CPUs.
    • - -
  • Linux emulation: layer has been updated to version - 2.6.16 and the default Linux infrastructure port is now - emulators/linux_base-f10 (Fedora 10).
    • +
  • Firewalls: + The base system includes IPFW and IPFilter, as well as a + modified version of the popular pf with improved SMP + performance. IPFW also includes the dummynet feature, + allowing network administrators to simular adverse network + conditions, including latency, jitter, packet loss and + limited bandwidth.
    • + +
  • Jails + are a light-weight alternative to virtualization. + Allowing processes to be restricted to a namespace with + access only to the file systems and network addresses + assigned to that namespace. Jails are also Hierarchical, + allowing jails-within-jails.
    • + +
  • Linux emulation + provides a system call translation layer that allows + unmodified Linux binaries to be run on &os; systems.
    • + +
  • DTrace + provides a comprehensive framework for tracing and + troubleshooting kernel and application performance issues + while under live load.
    • + +
  • The Ports Collection is a set of more than 23,000 third + party applications that can be easily installed and run on + &os;. The ports architecture also allows for easy + customization of the compile time options of many of the + applications.
  • Network Virtualization: A container ("vimage") has been implemented, extending the &os; kernel to maintain - multiple independent instances of networking state. - Vimage facilities can be used independently to create fully + multiple independent instances of networking state. Vimage facilities can be used independently to create fully virtualized network topologies, and jail(8) can directly take advantage of a fully virtualized network stack.
From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 17:03:49 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26970A06; Tue, 18 Feb 2014 17:03:49 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6A01C1BC7; Tue, 18 Feb 2014 17:03:48 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IH3mMH050659; Tue, 18 Feb 2014 17:03:48 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IH3mTl050658; Tue, 18 Feb 2014 17:03:48 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402181703.s1IH3mTl050658@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 17:03:48 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43977 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:03:49 -0000 Author: dru Date: Tue Feb 18 17:03:47 2014 New Revision: 43977 URL: http://svnweb.freebsd.org/changeset/doc/43977 Log: Make the section on PF NAT clearer. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 03:59:30 2014 (r43976) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 17:03:47 2014 (r43977) @@ -628,57 +628,64 @@ pass proto udp to any port $udp_services A Simple Gateway with NAT This section demonstrates how to configure a &os; system - which is running PF and also acts + running PF to act as a gateway for at least one other machine. The gateway - has at least two network interfaces, each connected to a - separate network. For example, one connection is to the - Internet and the other is to the internal network. - - It is reasonable to think that for stateful traffic to - pass from the network connected to xl1 - to hosts on the network connected to - xl0, a rule like this is needed: + needs at least two network interfaces, each connected to a + separate network. In this example, xl1 is connected to the + Internet and xl0 is connected to the internal network. + + First, enable the gateway in order to let the + machine forward the network traffic it receives on one + interface to another interface. This sysctl + setting will forward IPv4 packets: + + &prompt.root; sysctl net.inet.ip.forwarding=1 + + To forward IPv6 traffic, use: + + &prompt.root; sysctl net.inet6.ip6.forwarding=1 + + To enable these settings at system boot, add the following + to + /etc/rc.conf: + + gateway_enable="YES" #for ipv4 +ipv6_gateway_enable="YES" #for ipv6 + + Verify with ifconfig that + both of the interfaces are up and + running. + + Next, create the PF rules to + allow the gateway to pass traffic. While the following rule allows stateful traffic to + pass from the Internet + to hosts on the network, the to keyword does not + guarantee passage all the way from source to destination: pass in on xl1 from xl1:network to xl0:network port $ports keep state - However, the to keyword does not - guarantee passage all the way from source to destination. - This rule only lets the traffic pass in to the gateway on + That rule only lets the traffic pass in to the gateway on the internal interface. To let the packets go further, a matching rule is needed: pass out on xl0 from xl1:network to xl0:network port $ports keep state - These rules will work, but they will not necessarily - achieve the desired effect. - - Rules this specific are rarely needed. A better rule - says: + While these two rules will work, rules this specific are + rarely needed. For a busy network admin, a readable ruleset is a safer + ruleset. The remainder of this section demonstrates how to + keep the rules as simple as possible + for readability. For example, those two rules could be + replaced with one rule: pass from xl1:network to any port $ports keep state - This provides local network access to the Internet and - leaves the detective work to the - antispoof and - scrub code. - - For a busy network admin, a readable ruleset is a safer - ruleset. For the remainder of this section, with some - exceptions, we will keep the rules as simple as possible - for readability. - - Above, we introduced the - interface:network notation. That is a - nice piece of shorthand, but the ruleset can be made even - more readable and maintainable by taking the macro use a - tiny bit further. - - For example, a $localnet macro could - be defined as the network directly attached to your - internal interface ($xl1:network in the - examples above). - - Alternatively, the definition of + The + interface:network notation can be + replaced with a macro to make the ruleset even + more readable. For example, a $localnet macro could + be defined as the network directly attached to the + internal interface ($xl1:network). + Alternatively, the definition of $localnet could be changed to an IP address/netmask notation to denote a network, such as 192.168.100.1/24 for @@ -686,55 +693,26 @@ pass proto udp to any port $udp_services If required, $localnet could even be defined as a list of networks. Whatever the specific needs, - a sensible $localnet definition and a - typical pass rule of the type + a sensible $localnet definition could be + used in a + typical pass rule as follows: pass from $localnet to any port $ports keep state - could end up saving you a few headaches. We will stick - to that convention from here on. - - First, we need to turn on gatewaying in order to let the - machine forward the network traffic it receives on one - interface to other networks via a separate interface. - Initially we will do this on the command line with - &man.sysctl.8;, for traditional IP version - four. - - &prompt.root; sysctl net.inet.ip.forwarding=1 - - If we need to forward IP version - six traffic, the command is - - &prompt.root; sysctl net.inet6.ip6.forwarding=1 - - In order for this to continue working after the - computer has been restarted at some time in the future, - enter these settings into - /etc/rc.conf: - - gateway_enable="YES" #for ipv4 -ipv6_gateway_enable="YES" #for ipv6 - - Use ifconfig -a, or - ifconfig interface_name to find out if - both of the interfaces to be used are up and - running. - - If all traffic initiated by machines on the inside is to - be allowed, /etc/pf.conf could look - roughly like this - - For dialup users, the external interface is the - tun0 pseudo-device. Broadband - users such as ADSL subscribers tend to have an - Ethernet interface to play with, however for a - significant subset of ADSL users, specifically those - using PPP over Ethernet (PPPoE), the correct external - interface will be the tun0 - pseudo-device, not the physical Ethernet + The following sample ruleset allows all traffic initiated by + machines on the internal network. It first defines two + macros to represent the external and internal 3COM interfaces of + the gateway. + + + For dialup users, the external interface will use + tun0. For an + ADSL connection, specifically those + using PPP over Ethernet (PPPoE), the correct external + interface is tun0, + not the physical Ethernet interface. - : + ext_if = "xl0" # macro for external interface - use tun0 for PPPoE int_if = "xl1" # macro for internal interface @@ -744,77 +722,56 @@ nat on $ext_if from $localnet to any -&g block all pass from { lo0, $localnet } to any keep state - Note the use of macros to assign logical names to the - network interfaces. Here 3Com cards are used, but this is - the last time during this tutorial we will find this of - any interest whatsoever. In truly simple setups like this - one, we may not gain very much by using macros like these, - but once the rulesets grow somewhat larger, you will - learn to appreciate the readability this provides. - - Also note the nat rule. This is - where we handle the network address translation from the - non-routable address inside the local net to the sole - official address we assume has been assigned. - - The parentheses surrounding the last part of the nat - rule ($ext_if) are there to compensate - for the possibility that the IP address of the external - interface may be dynamically assigned. This detail will - ensure that network traffic runs without serious - interruptions even if the external IP address + This ruleset introduces the nat rule which is used to + handle the network address translation from the + non-routable addresses inside the internal network to the IP address + assigned to the external interface. The parentheses surrounding the last part of the nat + rule ($ext_if) is included + when the IP address of the external + interface is dynamically assigned. It + ensures that network traffic runs without serious + interruptions even if the external IP address changes. - On the other hand, this ruleset probably allows more - traffic to pass out of the network than actually desired. - One reasonable setup could contain the macro + Note that this ruleset probably allows more + traffic to pass out of the network than is needed. + One reasonable setup could create this macro: client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \ https, cvspserver, 2628, 5999, 8000, 8080 }" - and the main pass rule + to use in the main pass rule: pass inet proto tcp from $localnet to any port $client_out \ flags S/SA keep state - In addition, we have a few other pass rules. One pass - rule which is useful for administering machines remotely - is: + A few other pass rules may be needed. This one enables + SSH on the external interface:: pass in inet proto tcp to $ext_if port ssh - Lastly we need to make the name service work for our + This macro definition and rule allows + DNS and NTP for internal clients: - udp_services = "{ domain, ntp }" - - This is supplemented with a rule which passes the - traffic we want through our firewall: - - pass quick inet proto { tcp, udp } to any port $udp_services keep state + udp_services = "{ domain, ntp }" +pass quick inet proto { tcp, udp } to any port $udp_services keep state Note the quick keyword in this - rule. We have started writing rulesets which consist of - several rules, and it is time to take a look at the - relationships between the rules in a ruleset. The rules + rule. Since the ruleset consists of + several rules, it is important to understand the + relationships between the rules in a ruleset. Rules are evaluated from top to bottom, in the sequence they are - written in the configuration file. For each packet or + written. For each packet or connection evaluated by PF, - the last matching rule in the rule - set is the one which is applied. The - quick keyword offers an escape from the - ordinary sequence. When a packet matches a quick rule, - the packet is treated according to the present rule. The - rule processing stops without considering any further - rules which might have matched the packet. This is very - useful when a few isolated exceptions to the general rules - are needed. - - This rule also takes care of NTP, - which is used for time synchronization. One thing common - to both protocols is that they may under certain - circumstances communicate alternately over TCP and - UDP. + the last matching rule in the ruleset + is the one which is applied. However, + when a packet matches a rule which + contains the quick keyword, + the rule processing stops and the packet is treated + according to that rule. This is very + useful when an exception to the general rules + is needed. From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 18:04:04 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88BF8D3C; Tue, 18 Feb 2014 18:04:04 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66699125F; Tue, 18 Feb 2014 18:04:04 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1II44pX074091; Tue, 18 Feb 2014 18:04:04 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1II44rs074088; Tue, 18 Feb 2014 18:04:04 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402181804.s1II44rs074088@svn.freebsd.org> From: Glen Barber Date: Tue, 18 Feb 2014 18:04:04 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43978 - head/share/tools X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:04:04 -0000 Author: gjb Date: Tue Feb 18 18:04:03 2014 New Revision: 43978 URL: http://svnweb.freebsd.org/changeset/doc/43978 Log: Update webupdate and webupdate.wrapper scripts to always install from a clean build directory. PUBDIR is where the installed files end up for the public site. DESTDIR is now suffixed with '-clean', and always purged before a new build starts. When the build finishes, rsync populates PUBDIR from the resulting DESTDIR files. When doing a full site refresh, 'rsync --delete' is used to purge stale files. Sponsored by: The FreeBSD Foundation Modified: head/share/tools/webupdate head/share/tools/webupdate.wrapper Modified: head/share/tools/webupdate ============================================================================== --- head/share/tools/webupdate Tue Feb 18 17:03:47 2014 (r43977) +++ head/share/tools/webupdate Tue Feb 18 18:04:03 2014 (r43978) @@ -17,6 +17,7 @@ # SVNROOT - Path to the FreeBSD SVN repository. # BUILDDIR - Where the checked out copies of the files are stored. # DESTDIR - Where the rendered copies should wind up. +# PUBDIR - Where the rendered files are published. # LOGFILE - Name of the log file to use (in $BUILDDIR). # BUILDARGS - Arguments to pass to make(1) when {build,install}ing. # INSTARGS - Arguments to pass to make(1) when installing. @@ -162,6 +163,11 @@ time make ${BUILDARGS} all >> $LOGFILE 2 mail -s "FreeBSD web build failed on `hostname`" $WEBMAILTO; exit 3) || exit 3; +if [ "X${PUBDIR}" != "X" ]; then + /usr/local/bin/rsync ${RSYNC_FLAGS} ${DESTDIR}/ ${PUBDIR} \ + >> ${LOGFILE} 2>&1 +fi + # simon@ 20110116 - for now we use newsyslog... #gzip -f $LOGFILE #find $LOGDIR -mtime +60 -print0 | perl -n0e unlink Modified: head/share/tools/webupdate.wrapper ============================================================================== --- head/share/tools/webupdate.wrapper Tue Feb 18 17:03:47 2014 (r43977) +++ head/share/tools/webupdate.wrapper Tue Feb 18 18:04:03 2014 (r43978) @@ -9,11 +9,13 @@ PATH=/bin:/usr/bin:/usr/local/bin SVNROOT=svn://svn.FreeBSD.org -DESTDIR=/usr/local/www/www.freebsd.org +PUBDIR=/usr/local/www/www.freebsd.org +DESTDIR="${PUBDIR}-clean" +RSYNC_FLAGS="-avH" PINDEX_OVERRIDE=/usr/ports/INDEX-9 GEN_INDEX=yes export USER=www-data -export PATH DESTDIR PINDEX_OVERRIDE GEN_INDEX +export PATH DESTDIR PINDEX_OVERRIDE GEN_INDEX PUBDIR WEBMAILTO=freebsd-doc@FreeBSD.org export WEBMAILTO @@ -29,6 +31,7 @@ if [ -e $FLAGDIR/fullbuild-clean.flag ]; export BUILD_RELNOTES=YES # TODO - tell webupdate to do clean via env variable # webupdate will remove flag file + RSYNC_FLAGS="${RSYNC_FLAGS} --delete" elif [ -e $FLAGDIR/fullbuild-all-lang.flag ]; then export BUILD_RELNOTES=YES elif [ -e $FLAGDIR/fullbuild-en.flag ]; then @@ -37,6 +40,7 @@ elif [ -e $FLAGDIR/fullbuild-en.flag ]; else export WEB_ONLY=YES fi +rm -rf ${DESTDIR}/* rm -f $FLAGDIR/fullbuild-all-lang.flag $FLAGDIR/fullbuild-en.flag # 30m @@ -45,6 +49,8 @@ if [ "$1" = "-f" ]; then LOCKF_WAIT=0 fi +export RSYNC_FLAGS + nice -5 lockf -s -t $LOCKF_WAIT /usr/local/www/build/lock.webupdate \ sh -c "/usr/local/www/bin/webupdate ; \ /usr/sbin/newsyslog -f /home/www/etc/webupdate_newsyslog.conf -Fr -t ''" From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 18:07:00 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DABB4DD6; Tue, 18 Feb 2014 18:07:00 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9CBC1281; Tue, 18 Feb 2014 18:07:00 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1II70Tn074596; Tue, 18 Feb 2014 18:07:00 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1II700U074595; Tue, 18 Feb 2014 18:07:00 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402181807.s1II700U074595@svn.freebsd.org> From: Glen Barber Date: Tue, 18 Feb 2014 18:07:00 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43979 - head/share/tools X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:07:00 -0000 Author: gjb Date: Tue Feb 18 18:07:00 2014 New Revision: 43979 URL: http://svnweb.freebsd.org/changeset/doc/43979 Log: Set executable bit. Sponsored by: The FreeBSD Foundation Modified: Directory Properties: head/share/tools/webupdate (props changed) From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 18:08:55 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B74ADEED; Tue, 18 Feb 2014 18:08:55 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9751B12A2; Tue, 18 Feb 2014 18:08:55 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1II8tnE074895; Tue, 18 Feb 2014 18:08:55 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1II8tvq074894; Tue, 18 Feb 2014 18:08:55 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402181808.s1II8tvq074894@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 18:08:55 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43980 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:08:55 -0000 Author: dru Date: Tue Feb 18 18:08:55 2014 New Revision: 43980 URL: http://svnweb.freebsd.org/changeset/doc/43980 Log: Clarify the section on FTP proxy. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 18:07:00 2014 (r43979) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 18:08:55 2014 (r43980) @@ -777,140 +777,105 @@ pass quick inet proto { tcp, udp } to an Creating an <acronym>FTP</acronym> Proxy - The short list of real life TCP ports - above contained, among other things, FTP. - FTP is a sad old thing and a problem - child, emphatically so for anyone trying to combine - FTP and firewalls. - FTP is an old and weird protocol, with a - lot to not like. The most common points against it - are + Configuring working FTP rules can be + problematic due to the nature of the FTP + protocol. FTP pre-dates firewalls by + several decades and is insecure in its design. The most + common points against using FTP include: - Passwords are transferred in the clear + Passwords are transferred in the clear. The protocol demands the use of at least two TCP connections (control and data) on - separate ports + separate ports. When a session is established, data is communicated - via ports selected at random + using randomly selected ports. - All of these points make for challenges security-wise, - even before considering any potential weaknesses in client - or server software which may lead to security issues. These - things have tended to happen. - - Under any circumstances, other more modern and more - secure options for file transfer exist, such as &man.sftp.1; - or &man.scp.1;, which feature both authentication and data - transfer via encrypted connections. Competent - IT professionals should have a preference - for some other form of file transfer than - FTP. - - Regardless of our professionalism and preferences, we - are all too aware that at times we will need to handle - things we would prefer not to. In the case of - FTP through firewalls, the main part of - our handling consists of redirecting the traffic to a small - program which is written specifically for this - purpose. - - Enabling FTP transfers through your - gateway is amazingly simple, thanks to the - FTP proxy program (called - &man.ftp-proxy.8;) included in the base system on &os; and - other systems which offer - PF. - - The FTP protocol being what it is, - the proxy needs to dynamically insert rules in your rule - set. &man.ftp-proxy.8; interacts with your configuration - via a set of anchors where the proxy inserts and deletes - the rules it constructs to handle your + All of these points present security challenges, + even before considering any potential security weaknesses in client + or server software. More + secure alternatives for file transfer exist, such as &man.sftp.1; + or &man.scp.1;, which both feature authentication and data + transfer over encrypted connections.. + + For those situations when FTP is + required, PF provides + redirection of FTP traffic to a small + proxy program called + &man.ftp-proxy.8;, which is included in the base system of &os;. + The role of + the proxy is to dynamically insert and delete rules in the ruleset, using + a set of anchors, in order to correctly handle FTP traffic. - To enable &man.ftp-proxy.8;, add this line to + To enable the FTP proxy, add this line to /etc/rc.conf: ftpproxy_enable="YES" - Starting the proxy manually by running - /usr/sbin/ftp-proxy allows testing of - the PF configuration changes we - are about to make. + Then start the proxy by running + service ftp-proxy start. - For a basic configuration, only three elements need to + For a basic configuration, three elements need to be added to /etc/pf.conf. First, the - anchors: + anchors which the proxy will use to insert the rules it generates for the + FTP sessions: nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" - The proxy will insert the rules it generates for the - FTP sessions here. A pass rule is - needed to let FTP traffic in to the + Second, a pass rule is + needed to allow FTP traffic in to the proxy. - Now for the actual redirection. Redirection rules and - NAT rules fall into the same rule - class. These rules may be referenced directly by other - rules, and filtering rules may depend on these rules. - Logically, rdr and - nat rules need to be defined before the - filtering rules. - - We insert our rdr rule immediately - after the nat rule in - /etc/pf.conf + Third, redirection and NAT rules need + to be defined before the + filtering rules. Insert this rdr rule immediately + after the nat rule: rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 - In addition, the redirected traffic must be allowed to - pass. We achieve this with + Finally, allow the redirected traffic to + pass: pass out proto tcp from $proxy to any port ftp where $proxy expands to the address the proxy daemon is bound to. - Save pf.conf, then load the new - rules with + Save /etc/pf.conf, load the new + rules, and verify from a client that FTP + connections are working: &prompt.root; pfctl -f /etc/pf.conf - At this point, users will probably begin noticing - that FTP works before they have been - told. - This example covers a basic setup where the clients in - the local net need to contact FTP - servers elsewhere. The basic configuration here should + the local network need to contact FTP + servers elsewhere. This basic configuration should work well with most combinations of FTP - clients and servers. As shown in the man page, the + clients and servers. As shown in &man.ftp-proxy.8;, the proxy's behavior can be changed in various ways by adding options to the ftpproxy_flags= line. Some clients or servers may have specific quirks that must be compensated for in the configuration, or there may be a need to integrate the proxy in specific ways such as assigning FTP traffic to a specific - queue. For these and other finer points of - &man.ftp-proxy.8; configuration, start by studying the man - page. + queue. For ways to run an FTP server protected by PF and - &man.ftp-proxy.8;, look into running a separate - ftp-proxy in reverse mode (using - ), on a separate port with its own + &man.ftp-proxy.8;, configure a separate + ftp-proxy in reverse mode, using + , on a separate port with its own redirecting pass rule. From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 18:11:29 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BF7EF5; Tue, 18 Feb 2014 18:11:29 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86307133A; Tue, 18 Feb 2014 18:11:29 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IIBT86078028; Tue, 18 Feb 2014 18:11:29 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IIBTGg078027; Tue, 18 Feb 2014 18:11:29 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402181811.s1IIBTGg078027@svn.freebsd.org> From: Glen Barber Date: Tue, 18 Feb 2014 18:11:29 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43981 - head/en_US.ISO8859-1/books/faq X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:11:29 -0000 Author: gjb Date: Tue Feb 18 18:11:29 2014 New Revision: 43981 URL: http://svnweb.freebsd.org/changeset/doc/43981 Log: Bump copyright after r43649. Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/books/faq/book.xml Modified: head/en_US.ISO8859-1/books/faq/book.xml ============================================================================== --- head/en_US.ISO8859-1/books/faq/book.xml Tue Feb 18 18:08:55 2014 (r43980) +++ head/en_US.ISO8859-1/books/faq/book.xml Tue Feb 18 18:11:29 2014 (r43981) @@ -45,6 +45,7 @@ 2011 2012 2013 + 2014 The &os; Documentation Project From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 18:25:52 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F59E53D; Tue, 18 Feb 2014 18:25:52 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA83B1499; Tue, 18 Feb 2014 18:25:51 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IIPp9O082626; Tue, 18 Feb 2014 18:25:51 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IIPpda082625; Tue, 18 Feb 2014 18:25:51 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402181825.s1IIPpda082625@svn.freebsd.org> From: Glen Barber Date: Tue, 18 Feb 2014 18:25:51 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43982 - head/en_US.ISO8859-1/books/faq X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:25:52 -0000 Author: gjb Date: Tue Feb 18 18:25:51 2014 New Revision: 43982 URL: http://svnweb.freebsd.org/changeset/doc/43982 Log: Add corrected entries for the 10.x branch entities and update to reflect -CURRENT is now 11.0. While here, swap pkg_add(1) for pkg(7), and dereference FTP packages/ directory links. Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/books/faq/book.xml Modified: head/en_US.ISO8859-1/books/faq/book.xml ============================================================================== --- head/en_US.ISO8859-1/books/faq/book.xml Tue Feb 18 18:11:29 2014 (r43981) +++ head/en_US.ISO8859-1/books/faq/book.xml Tue Feb 18 18:25:51 2014 (r43982) @@ -2,25 +2,26 @@ - -10-CURRENT"> -X"> + +11-CURRENT"> +X"> head/"> - -X"> -9-STABLE"> -stable/9/"> - - -X"> -8-STABLE"> -stable/8/"> - - +X"> +10-STABLE"> +stable/10/"> + +X"> +9-STABLE"> +stable/9/"> + +X"> +8-STABLE"> +stable/8/"> + ]> Frequently Asked Questions for &os; - &rel2.relx;, &rel.relx; and &rel.head.relx; + &rel3.relx;, &rel2.relx; and &rel.relx; The &os; Documentation Project @@ -69,7 +70,7 @@ $FreeBSD$ - This is the FAQ for &os; versions &rel2.relx; and + This is the FAQ for &os; versions &rel3.relx;, &rel2.relx; and &rel.relx;. Every effort has been made to make this FAQ as informative as possible; if you have any suggestions as to how it may be improved, please feel free to mail them to the @@ -2382,7 +2383,7 @@ kern.timecounter.hardware: TSC -> i82 periodic updates on new entries. Most ports should work on the - &rel2.relx;, and &rel.relx; branches. + &rel3.relx;, &rel2.relx;, and &rel.relx; branches. Each time a &os; release is made, a snapshot of the ports tree at the time of release in also included in the ports/ @@ -2396,40 +2397,13 @@ kern.timecounter.hardware: TSC -> i82 to know the gory details of which files it includes. Use - &man.pkg.add.1; on the specific package files + &man.pkg.7; on the specific package files you are interested in installing. Package files can usually - be identified by their .tbz suffix and + be identified by their .txz suffix and CD-ROM distribution people will have a packages/All directory on their CD which contains such files. They can also be downloaded over - the net for various versions of &os; at the following - locations: - - - - for &rel2.relx; -RELEASE/&rel2.stable; - - - ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/&rel2.packages; - - - - - for &rel.relx; -RELEASE/&rel.stable; - - - ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/&rel.packages; - - - - - or your nearest local mirror site. - - Note that all ports may not be available as packages - since new ones are constantly being added. It is always a - good idea to check back periodically to see which packages - are available at the ftp.FreeBSD.org - master site. + the net for various versions of &os;. @@ -7654,6 +7628,11 @@ hint.sio.7.irq="12" + &rel3.releng; AKA + &rel3.stable; + + + &rel2.releng; AKA &rel2.stable; From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 19:25:17 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4167246C; Tue, 18 Feb 2014 19:25:17 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E61919FE; Tue, 18 Feb 2014 19:25:17 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IJPGCl007339; Tue, 18 Feb 2014 19:25:16 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IJPGfQ007338; Tue, 18 Feb 2014 19:25:16 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402181925.s1IJPGfQ007338@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 19:25:16 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43983 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:25:17 -0000 Author: dru Date: Tue Feb 18 19:25:16 2014 New Revision: 43983 URL: http://svnweb.freebsd.org/changeset/doc/43983 Log: Editorial pass through ICMP section. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 18:25:51 2014 (r43982) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 19:25:16 2014 (r43983) @@ -882,152 +882,79 @@ rdr-anchor "ftp-proxy/*" Managing <acronym>ICMP</acronym> - Making network troubleshooting friendly is a potentially - large subject. At most times, the debugging or - troubleshooting friendliness of a TCP/IP - network depends on treatment of the Internet protocol which - was designed specifically with debugging in mind, the - Internet Control Message Protocol, or - ICMP as it is usually abbreviated. + Many of the tools used for debugging or + troubleshooting a TCP/IP network rely on the + Internet Control Message Protocol (ICMP), which + was designed specifically with debugging in mind. - ICMP is the protocol for sending and - receiving control messages between + The ICMP protocol sends and + receives control messages between hosts and gateways, mainly to provide feedback to a sender about any unusual or difficult conditions enroute to the - target host. - - There is a lot of ICMP traffic which - usually just happens in the background while users are - surfing the web, reading mail or transferring files. + target host. Routers use ICMP to negotiate packet sizes and other transmission parameters in a process often referred to as path MTU discovery. - Some admins refer to ICMP as either - just evil, or, if their understanding runs a - little deeper, a necessary evil. The reason - for this attitude is purely historical. The reason can be - found a few years back when it was discovered that several - operating systems contained code in their networking stack - which could make a machine running one of the affected - systems crash and fall over, or in some cases just do really - strange things, with a sufficiently large - ICMP request. - - One of the companies which was hit hard was Microsoft, - and you can find rather a lot of material on the - ping of death bug by using your favorite - search engine. This all happened in the second half of the - 1990s, and all modern operating systems, at least the ones - we can read, have thoroughly sanitized their network code - since then. At least that is what we are led to - believe. - - One of the early workarounds was to simply block either - all ICMP traffic or at least - ICMP ECHO, which is what ping uses. Now - these rulesets have been around for roughly fifteen years, - and the people who put them there are still scared. - - The obvious question then becomes, if - ICMP is such a good and useful thing, - should we not let it all through, all the time? The - answer is It depends. - - Letting diagnostic traffic pass unconditionally of - course makes debugging easier, but also makes it - relatively easy for others to extract information about - your network. That means that a rule like + From a firewall perspective, some ICMP + control messages are vulnerable to known attack vectors. + Also, letting all diagnostic traffic pass unconditionally + makes debugging easier, but it also makes it + easier for others to extract information about + the network. For these reasons, the following rule may not be + optimal: pass inet proto icmp from any to any - might not be optimal if the internal workings of the - local network should be cloaked in a bit of mystery. In - all fairness it should also be said that some - ICMP traffic might be found quite - harmlessly riding piggyback on - keep state rules. - - The easiest solution could very well be to let all - ICMP traffic from the local net through - and stop probes from elsewhere at the gateway: + One solution is to let all + ICMP traffic from the local network through + while stopping all probes from outside the network: pass inet proto icmp from $localnet to any keep state pass inet proto icmp from any to $ext_if keep state - Stopping probes at the gateway might be an attractive - option anyway, but let us have a look at a few other - options which will show some of - PF's flexibility. - - - Letting <command>ping</command> Through - - The ruleset we have developed so far has one clear - disadvantage: common troubleshooting commands such as - &man.ping.8; and &man.traceroute.8; will not work. That - may not matter too much to end users, and since it was - ping which scared people into - filtering or blocking ICMP traffic in - the first place, there are apparently some people who feel - we are better off without it. If you are in my perceived - target audience, you will be rather fond of having those - troubleshooting tools avalable. With a couple of small - additions to the ruleset, they will be. &man.ping.8; - uses ICMP, and in order to keep our - ruleset tidy, we start by defining another macro: + Additional + options are available which demonstrate some of + PF's flexibility. For example, + rather than allowing all ICMP messages, + one can specify the messages used by &man.ping.8; and + &man.traceroute.8;. Start by defining a macro for + that type of message: icmp_types = "echoreq" - and a rule which uses the definition, + and a rule which uses the macro: pass inet proto icmp all icmp-type $icmp_types keep state - More or other types of ICMP packets - may need to go through, and icmp_types - can be expanded to a list of those packet types that are - allowed. - - - - Helping &man.traceroute.8; - - &man.traceroute.8; is another command which is quite - useful when users claim that the Internet is not working. - By default, Unix traceroute uses UDP - connections according to a set formula based on - destination. The rule below works with - traceroute on all Unixes I have had - access to, including GNU/Linux: + If other types of ICMP packets + are needed, expand icmp_types + to a list of those packet types. Type + more /usr/src/contrib/pf/pfctl/pfctl_parser.c + to see the list of ICMP message + types supported by PF. Refer to + http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml + for an explanation of each message type. + + Since Unix traceroute uses UDP + by default, another rule is needed to allow Unix + traceroute: # allow out the default range for traceroute(8): -# "base+nhops*nqueries-1" (33434+64*3-1) pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state - Experience so far indicates that - traceroute implementations on other - operating systems work roughly the same. Except, of - course, on Microsoft Windows. On that platform, - TRACERT.EXE uses ICMP ECHO for this - purpose. So to let Windows traceroutes through, only the - first rule is needed. Unix traceroute + Since TRACERT.EXE on Microsoft Windows systems + uses ICMP echo request messages, + only the + first rule is needed to allow network traces from those systems. Unix traceroute can be instructed to use other protocols as well, and will - behave remarkably like its Microsoft counterpart if + use ICMP echo request messages if is used. Check the &man.traceroute.8; - man page (or its source code, for that matter) for all the + man page for details. - Under any circumstances, this solution was lifted - from an openbsd-misc post. I have found that list, and - the searchable list archives (accessible among other - places from http://marc.theaimsgroup.com/), - to be a very valuable resource whenever you need OpenBSD - or PF related - information. - - Path <acronym>MTU</acronym> Discovery @@ -1035,60 +962,47 @@ pass out on $ext_if inet proto udp from independent, and one consequence of device independence is that the optimal packet size for a given connection cannot always be predicted reliably. The main constraint on - packet size is called the - Maximum Transmission Unit, or - MTU, which sets the upper limit on the - packet size for an interface. &man.ifconfig.8; shows the - MTU for the network interfaces. - - Modern TCP/IP implementations expect to be able to - determine the right packet size for a connection through a - process which, simply put, involves sending packets of + packet size is the + Maximum Transmission Unit + (MTU) which sets the upper limit on the + packet size for an interface. Type ifconfig to view the + MTUs for a system's network interfaces. + + TCP/IP uses a process known as path + MTU discovery to + determine the right packet size for a connection. This + process sends packets of varying sizes with the Do not fragment flag set, expecting an ICMP return packet - indicating type 3, code 4 when the upper - limit has been reached. Now do not dive for the RFCs - right away. Type 3 means destination - unreachable, while code 4 is short for + of type 3, code 4 when the upper + limit has been reached. Type 3 means destination + unreachable, and code 4 is short for fragmentation needed, but the do-not-fragment flag - is set. So if connections to networks which may - have other MTUs than the local network - seem sub-optimal, and there is no need to be that - specific, the list of ICMP types can be - changed slightly to let the - destination unreachable packets through, - too: + is set. To allow path MTU discovery in order + to support connections to other MTUs, add + the + destination unreachable type to the + icmp_types macro: icmp_types = "{ echoreq, unreach }" - As we can see, this means we do not need to change - the pass rule itself: + Since + the pass rule already uses that macro, it does not need to + be modified in order to support the new + ICMP type: pass inet proto icmp all icmp-type $icmp_types keep state PF allows filtering on all variations of ICMP types and codes. - For those who want to delve into what to pass (or not) of - ICMP traffic, the list of possible - types and codes are documented in the &man.icmp.4; and - &man.icmp6.4; man pages. The background information is - available in the RFCs - The main internet RFCs - describing ICMP and - some related techhiques are RFC792, RFC950, RFC1191, - RFC1256, RFC2521, rfc2765, while necessary updates for - ICMP for IPv6 are found in RFC1885, RFC2463, RFC2466. - These documents are available in a number of places on - the net, such as the - ietf.org - and - faqs.org - web sites.. + The list of possible + types and codes are documented in &man.icmp.4; and + &man.icmp6.4;. - Tables Make Life Easier + Using Tables By this time it may appear that this gets awfully static and rigid. There will after all be some kinds of data which From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 20:12:17 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C7E5EFC; Tue, 18 Feb 2014 20:12:17 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57B8F1FD2; Tue, 18 Feb 2014 20:12:17 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IKCHUE027322; Tue, 18 Feb 2014 20:12:17 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IKCHqj027321; Tue, 18 Feb 2014 20:12:17 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402182012.s1IKCHqj027321@svn.freebsd.org> From: Glen Barber Date: Tue, 18 Feb 2014 20:12:17 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43984 - head/share/xml X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 20:12:17 -0000 Author: gjb Date: Tue Feb 18 20:12:16 2014 New Revision: 43984 URL: http://svnweb.freebsd.org/changeset/doc/43984 Log: Add Dotline Infotech to the consultancy page. PR: 186582 Submitted by: Parb Jung Sponsored by: The FreeBSD Foundation Modified: head/share/xml/commercial.consult.xml Modified: head/share/xml/commercial.consult.xml ============================================================================== --- head/share/xml/commercial.consult.xml Tue Feb 18 19:25:16 2014 (r43983) +++ head/share/xml/commercial.consult.xml Tue Feb 18 20:12:16 2014 (r43984) @@ -386,6 +386,16 @@ + + Dotline Infotech IT Support + http://www.dotline.com.au/ + Dotline Infotech is based in heart of Syney CBD + providing FreeBSD, Unix, Linux IT support to all enterprises. + For all you Unix/Linux Support please do contact us on 02-8677- + 3061 or visit us on our + website. + + EscapeBox http://www.escapebox.net/en/ From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 20:17:42 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7C7A582; Tue, 18 Feb 2014 20:17:42 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 941C01021; Tue, 18 Feb 2014 20:17:42 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IKHgRl028255; Tue, 18 Feb 2014 20:17:42 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IKHggx028254; Tue, 18 Feb 2014 20:17:42 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402182017.s1IKHggx028254@svn.freebsd.org> From: Glen Barber Date: Tue, 18 Feb 2014 20:17:42 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43985 - head/share/xml X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 20:17:42 -0000 Author: gjb Date: Tue Feb 18 20:17:42 2014 New Revision: 43985 URL: http://svnweb.freebsd.org/changeset/doc/43985 Log: Add Dynode to the consultant page. PR: 185195 Submitted by: Russell Sponsored by: The FreeBSD Foundation Modified: head/share/xml/commercial.consult.xml Modified: head/share/xml/commercial.consult.xml ============================================================================== --- head/share/xml/commercial.consult.xml Tue Feb 18 20:12:16 2014 (r43984) +++ head/share/xml/commercial.consult.xml Tue Feb 18 20:17:42 2014 (r43985) @@ -396,6 +396,16 @@ website. + + Dynode Professional IT Services + http://www.dynode.net/ + With over a decade of FreeBSD experience, Dynode + offers systems administration and software development for + UNIX/BSD/Linux systems in Perth, Western Australia. Please visit our website for more + information. + + EscapeBox http://www.escapebox.net/en/ From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 21:05:37 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8345675E; Tue, 18 Feb 2014 21:05:37 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C76314DC; Tue, 18 Feb 2014 21:05:37 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IL5bmI047707; Tue, 18 Feb 2014 21:05:37 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IL5bW8047706; Tue, 18 Feb 2014 21:05:37 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402182105.s1IL5bW8047706@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 21:05:37 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43986 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:05:37 -0000 Author: dru Date: Tue Feb 18 21:05:36 2014 New Revision: 43986 URL: http://svnweb.freebsd.org/changeset/doc/43986 Log: Editorial pass through Tables section. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 20:17:42 2014 (r43985) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 21:05:36 2014 (r43986) @@ -1004,74 +1004,64 @@ pass out on $ext_if inet proto udp from Using Tables - By this time it may appear that this gets awfully static - and rigid. There will after all be some kinds of data which + Some types of data are relevant to filtering and redirection at a given time, - but do not deserve to be put into a configuration file! - Quite right, and PF offers - mechanisms for handling these situations as well. Tables - are one such feature, mainly useful as lists which can be + but their definition is too long to be included in the ruleset file. + PF supports the use of tables, + which are defined lists that can be manipulated without needing to reload the entire ruleset, - and where fast lookups are desirable. Table names are - always enclosed in < >, like + and which can provide fast lookups. Table names are + always enclosed within < >, like this: table <clients> { 192.168.2.0/24, !192.168.2.5 } - Here, the network 192.168.2.0/24 - is part of the table, except the address + In this example, the 192.168.2.0/24 network + is part of the table, except for the address 192.168.2.5, which is excluded using - the ! operator (logical NOT). It is + the ! operator. It is also possible to load tables from files where each item is - on a separate line, such as the file - /etc/clients. + on a separate line, as seen in this example + /etc/clients: 192.168.2.0/24 !192.168.2.5 - which in turn is used to initialize the table in - /etc/pf.conf: + To refer to the file, define the table like this: table <clients> persist file "/etc/clients" - Then, for example, one of our earlier rules can be - changed to read + Once the table is defined, it can be referenced by a + rule: pass inet proto tcp from <clients> to any port $client_out flags S/SA keep state - to manage outgoing traffic from client computers. With - this in hand, the table's contents can be manipulated live, - such as - - &prompt.root; pfctl -t clients -T add 192.168.1/16 - - Note that this changes the in-memory copy of the table - only, meaning that the change will not survive a power - failure or other reboot unless there are arrangements to - store the changes. + A table's contents can be manipulated live, using pfctl. + This example adds another network to the table: - One might opt to maintain the on-disk copy of the table - using a &man.cron.8; job which dumps the table content to + &prompt.root; pfctl -t clients -T add 192.168.1.0/16 + + Note that any changes made this way will take affect now, + making them ideal for testing, + but will not survive a power + failure or reboot. To make the changes permanent, modify the + definition of the table in the ruleset or edit the file that the + table refers to. One can maintain the on-disk copy of the table + using a &man.cron.8; job which dumps the table's contents to disk at regular intervals, using a command such as pfctl -t clients -T show >/etc/clients. Alternatively, - /etc/clients could be edited, replacing - the in-memory table contents with the file data: + /etc/clients can be updated with + the in-memory table contents: &prompt.root; pfctl -t clients -T replace -f /etc/clients - - For operations performed frequently, administrators will - sooner or later end up writing shell scripts for tasks - such as inserting or removing items or replacing table - contents. The only real limitations lie in individual needs - and creativity. - Overload Tables + Using Overload Tables to Protect <acronym>SSH</acronym> - Those who run a Secure Shell login service which is - accessible from the Internet have probably seen something + Those who run SSH on an external interface + have probably seen something like this in the authentication logs: Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2 @@ -1081,95 +1071,68 @@ Sep 26 03:12:44 skapet sshd[29635]: Inva Sep 26 03:12:44 skapet sshd[24703]: input_userauth_request: invalid user admin Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2 - And so on. This is what a brute force attack looks - like. Essentially somebody, or more likely, a cracked - computer somewhere, is trying by brute force to find a - combination of user name and password which will let them - into your system. - - The simplest response would be to write a - pf.conf rule which blocks all access. - This leads to another class of problems, including what to - do in order to let people with legitimate business on the - system access it anyway. Some might consider moving the - service to another port, but then again, the ones flooding - on port 22 would probably be able to scan their way to port - 22222 for a repeat performance. - - Since OpenBSD 3.7, and soon after in &os; version 6.0, - PF has offered a slightly more - elegant solution. Pass rules can be written so they - maintain certain limits on what connecting hosts can do. - For good measure, violators can be banished to a table of - addresses which are denied some or all access. If desired, - it is even possible to drop all existing connections from - machines which overreach the limits. Here is how it is - done: + This is indicative of a brute force attack where + somebody or some program + is trying to discover the + user name and password which will let them + into the system. + + If external SSH access is needed for + legitimate users, changing the default port used by + SSH can offer some protection. + However, PF provides a more + elegant solution. Pass rules can contain + limits on what connecting hosts can do and + violators can be banished to a table of + addresses which are denied some or all access. It + is even possible to drop all existing connections from + machines which overreach the limits. - First, set up the table. In the tables section, - add + To configure this, create this table in the tables section + of the ruleset: table <bruteforce> persist - Then somewhere fairly early in the ruleset, add a rule - to block the bruteforcers: - - block quick from <bruteforce> + Then, somewhere early in the ruleset, add rules + to block brute access while allowing legitimate access: - And finally, the pass rule. - - pass inet proto tcp from any to $localnet port $tcp_services \ + block quick from <bruteforce> +pass inet proto tcp from any to $localnet port $tcp_services \ flags S/SA keep state \ - (max-src-conn 100, max-src-conn-rate 15/5, \ + (max-src-conn 100, max-src-conn-rate 15/5, \ overload <bruteforce> flush global) - The first part here is identical to the main rule we - constructed earlier. The part in parentheses is the new - stuff which will ease network load even further. + The part in parentheses defines the limits and the + numbers should be changed to meet local requirements. It + can be read as follows: max-src-conn is the number of - simultaneous connections allowed from one host. In this - example, it is set at 100. Other setups may want a slightly - higher or lower value. + simultaneous connections allowed from one host. max-src-conn-rate is the rate of new - connections allowed from any single host, here 15 - connections per 5 seconds. Again, the administrator is the - one to judge what suits their setup. + connections allowed from any single host (15) + per number of seconds (5). overload <bruteforce> means that any host which exceeds these limits gets its address - added to the table bruteforce. Our rule - set blocks all traffic from addresses in the bruteforce + added to the bruteforce table. The ruleset + blocks all traffic from addresses in the bruteforce table. Finally, flush global says that when - a host reaches the limit, that host's connections will be - terminated (flushed). The global part says that for good - measure, this applies to connections which match other pass - rules too. - - The effect is dramatic. From here on, bruteforcers - more often than not will end up with - "Fatal: timeout before - authentication" messages, getting - nowhere. + a host reaches the limit, that all (global) of that host's connections will be + terminated (flush). These rules will not block slow - bruteforcers, sometimes referred to as the - Hail Mary Cloud. + bruteforcers, as described in http://home.nuug.no/~peter/hailmary2013/. - Once again, please keep in mind that this example rule - is intended mainly as an illustration. It is not unlikely - that a particular network's needs are better served by - rather different rules or combinations of rules. - - If, for example, a generous number of connections in - general are wanted, but the desire is to be a little more - tight fisted when it comes to + This example ruleset + is intended mainly as an illustration. For example, if a generous number of connections in + general are wanted, but the desire is to be more + restrictive when it comes to ssh, supplement the rule above with something like the one below, early on in the rule set: @@ -1179,87 +1142,53 @@ Sep 26 03:12:44 skapet sshd[24703]: Fail (max-src-conn 15, max-src-conn-rate 5/3, \ overload <bruteforce> flush global) - It should be possible to find the set of parameters - which is just right for individual situations by reading the - relevant man pages and the - PF User - Guide, and perhaps a bit of - experimentation. - It May Not be Necessary to Block All Overloaders - It is probably worth noting at this point that the - overload mechanism is a general - technique which does not have to apply exclusively to the - ssh service, and it is not always - optimal to block all traffic from offenders - entirely. + It is worth noting that the + overload mechanism is a general + technique which does not apply exclusively to + SSH, and it is not always + optimal to entirely block all traffic from offenders. For example, an overload rule could be used to protect a mail service or a web service, and the overload table could be used in a rule to assign offenders to a - queue with a minimal bandwidth allocation or, in the web - case, to redirect to a specific web page. + queue with a minimal bandwidth allocation or + to redirect to a specific web page. - - Expiring Table Entries with - <application>pfctl</application> - - At this point, we have tables which will be filled by - our overload rules, and since we could - reasonably expect our gateways to have months of uptime, - the tables will grow incrementally, taking up more memory - as time goes by. - - Sometimes an IP address that was blocked last week due - to a brute force attack was in fact a dynamically assigned - one, which is now assigned to a different ISP customer who - has a legitimate reason to try communicating with hosts in + Over time, tables will be filled by + overload rules and their size + will grow incrementally, taking up more memory. + Sometimes an IP address that is blocked + is a dynamically assigned + one, which has since been assigned to a host who + has a legitimate reason to communicate with hosts in the local network. - Situations like these were what caused Henning Brauer - to add to pfctl the ability to - expire table entries not referenced in a specified number - of seconds (in OpenBSD 4.1). For example, the - command + For situations like these, + pfctl provides the ability to + expire table entries. For example, this + command will remove <bruteforce> + table entries which have not been referenced for 86400 + seconds: &prompt.root; pfctl -t bruteforce -T expire 86400 - will remove <bruteforce> - table entries which have not been referenced for 86400 - seconds. - - - - The <application>expiretable</application> - Tool - - Before pfctl acquired the - ability to expire table entries, Henrik Gustafsson had - written expiretable, which + Similar functionality is provided by + security/expiretable, which removes table entries which have not been accessed for a specified period of time. - One useful example is to use the - expiretable program as a way of - removing outdated <bruteforce> - table entries. - - For example, let - expiretable remove + Once installed, + expiretable can be run to remove <bruteforce> table entries older - than 24 hours by adding an entry containing the following - to /etc/rc.local: + than a specified age. This example removes all entries + older than 24 hours: /usr/local/sbin/expiretable -v -d -t 24h bruteforce - - expiretable is in the - Ports Collection on &os; as - security/expiretable. - From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 21:30:20 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D8B3637; Tue, 18 Feb 2014 21:30:20 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 689F41703; Tue, 18 Feb 2014 21:30:20 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1ILUKFQ057823; Tue, 18 Feb 2014 21:30:20 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1ILUKKu057822; Tue, 18 Feb 2014 21:30:20 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402182130.s1ILUKKu057822@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 21:30:20 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43987 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:30:20 -0000 Author: dru Date: Tue Feb 18 21:30:19 2014 New Revision: 43987 URL: http://svnweb.freebsd.org/changeset/doc/43987 Log: Prep work for next round of edits. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 21:05:36 2014 (r43986) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 21:30:19 2014 (r43987) @@ -1191,30 +1191,8 @@ pass inet proto tcp from any to $localne /usr/local/sbin/expiretable -v -d -t 24h bruteforce - - Other <application>PF</application> Tools - - Over time, a number of tools have been developed which - interact with PF in various - ways. - - - The <application>pftop</application> Traffic - Viewer - - Can Erkin Acar's pftop - makes it possible to keep an eye on what passes into and - out of the network. pftop is - available through the ports system as - sysutils/pftop. The name is a strong - hint at what it does - pftop - shows a running snapshot of traffic in a format which is - strongly inspired by &man.top.1;. - - - - The <application>spamd</application> Spam Deferral - Daemon + + Protecting Against <acronym>SPAM</acronym> Not to be confused with the spamd daemon which comes @@ -1249,11 +1227,7 @@ pass inet proto tcp from any to $localne implementation with one byte SMTP replies is often referred to as stuttering. - - A Basic Blacklisting - <application>spamd</application> - - Here is the basic procedure for setting up + This example demonstrates the basic procedure for setting up spamd with automatically updated blacklists: @@ -1392,11 +1366,9 @@ rdr pass on $ext_if inet proto tcp from On a typical gateway in front of a mail server, hosts will start getting trapped within a few seconds to several minutes. - - - Adding Greylisting to the - <application>spamd</application> Setup + + Adding Greylisting to the Setup spamd also supports greylisting, which works by @@ -1505,20 +1477,16 @@ rdr pass on $ext_if inet proto tcp from administrator's main interface to managing the black, grey and white lists via the contents of the /var/db/spamdb database. - + - - Network Hygiene: Blocking, Scrubbing and so - On - - Our gateway does not feel quite complete without a few - more items in the configuration which will make it behave - a bit more sanely towards hosts on the wide net and our - local network. + + Network Hygiene - - <literal>block-policy</literal> + This section describes how + block-policy, scrub, + and antispoof can be used to make the + ruleset behave sanely. block-policy is an option which can be set in the options part of the @@ -1539,10 +1507,6 @@ rdr pass on $ext_if inet proto tcp from returns: set block-policy return - - - - <literal>scrub</literal> In PF versions up to OpenBSD 4.5 inclusive, scrub is a @@ -1573,10 +1537,6 @@ rdr pass on $ext_if inet proto tcp from possible, and you should be able to cater to various specific needs by consulting the man pages and some experimentation. - - - - <literal>antispoof</literal> antispoof is a common special case of filtering and blocking. This mechanism protects @@ -1591,9 +1551,9 @@ rdr pass on $ext_if inet proto tcp from antispoof for $ext_if antispoof for $int_if - + - + Handling Non-Routable Addresses from Elsewhere @@ -1643,9 +1603,24 @@ block drop out quick on $ext_if from any xlink:href="http://home.nuug.no/~peter/pf/">http://home.nuug.no/~peter/pf/, where you will also find slides from related presentations. - - + + + Viewing Traffic + + Over time, a number of tools have been developed which + interact with PF in various + ways. + + Can Erkin Acar's pftop + makes it possible to keep an eye on what passes into and + out of the network. pftop is + available through the ports system as + sysutils/pftop. The name is a strong + hint at what it does - pftop + shows a running snapshot of traffic in a format which is + strongly inspired by &man.top.1;. + From owner-svn-doc-head@FreeBSD.ORG Tue Feb 18 22:23:52 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CB0A9DD; Tue, 18 Feb 2014 22:23:52 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22E521C49; Tue, 18 Feb 2014 22:23:52 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1IMNqjg080748; Tue, 18 Feb 2014 22:23:52 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1IMNqRG080747; Tue, 18 Feb 2014 22:23:52 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402182223.s1IMNqRG080747@svn.freebsd.org> From: Dru Lavigne Date: Tue, 18 Feb 2014 22:23:52 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43988 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 22:23:52 -0000 Author: dru Date: Tue Feb 18 22:23:51 2014 New Revision: 43988 URL: http://svnweb.freebsd.org/changeset/doc/43988 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 21:30:19 2014 (r43987) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 22:23:51 2014 (r43988) @@ -143,7 +143,7 @@ in a normal session conversation. For a good introduction, refer to Daryl's - TCP/IP Primer. + TCP/IP Primer. @@ -628,15 +628,16 @@ pass proto udp to any port $udp_services A Simple Gateway with NAT This section demonstrates how to configure a &os; system - running PF to act - as a gateway for at least one other machine. The gateway - needs at least two network interfaces, each connected to a - separate network. In this example, xl1 is connected to the - Internet and xl0 is connected to the internal network. - - First, enable the gateway in order to let the - machine forward the network traffic it receives on one - interface to another interface. This sysctl + running PF to act as a gateway + for at least one other machine. The gateway needs at least + two network interfaces, each connected to a separate + network. In this example, xl1 is + connected to the Internet and xl0 is + connected to the internal network. + + First, enable the gateway in order to let the machine + forward the network traffic it receives on one interface to + another interface. This sysctl setting will forward IPv4 packets: &prompt.root; sysctl net.inet.ip.forwarding=1 @@ -645,74 +646,71 @@ pass proto udp to any port $udp_services &prompt.root; sysctl net.inet6.ip6.forwarding=1 - To enable these settings at system boot, add the following - to - /etc/rc.conf: + To enable these settings at system boot, add the + following to /etc/rc.conf: gateway_enable="YES" #for ipv4 ipv6_gateway_enable="YES" #for ipv6 - Verify with ifconfig that - both of the interfaces are up and - running. + Verify with ifconfig that both of the + interfaces are up and running. Next, create the PF rules to - allow the gateway to pass traffic. While the following rule allows stateful traffic to - pass from the Internet - to hosts on the network, the to keyword does not - guarantee passage all the way from source to destination: + allow the gateway to pass traffic. While the following rule + allows stateful traffic to pass from the Internet to hosts + on the network, the to keyword does not + guarantee passage all the way from source to + destination: pass in on xl1 from xl1:network to xl0:network port $ports keep state - That rule only lets the traffic pass in to the gateway on - the internal interface. To let the packets go further, a + That rule only lets the traffic pass in to the gateway + on the internal interface. To let the packets go further, a matching rule is needed: pass out on xl0 from xl1:network to xl0:network port $ports keep state While these two rules will work, rules this specific are - rarely needed. For a busy network admin, a readable ruleset is a safer - ruleset. The remainder of this section demonstrates how to - keep the rules as simple as possible - for readability. For example, those two rules could be + rarely needed. For a busy network admin, a readable ruleset + is a safer ruleset. The remainder of this section + demonstrates how to keep the rules as simple as possible for + readability. For example, those two rules could be replaced with one rule: pass from xl1:network to any port $ports keep state - The - interface:network notation can be - replaced with a macro to make the ruleset even - more readable. For example, a $localnet macro could - be defined as the network directly attached to the + The interface:network notation can be + replaced with a macro to make the ruleset even more + readable. For example, a $localnet macro + could be defined as the network directly attached to the internal interface ($xl1:network). Alternatively, the definition of $localnet could be changed to an IP address/netmask notation to denote - a network, such as 192.168.100.1/24 for - a subnet of private addresses. + a network, such as 192.168.100.1/24 for a + subnet of private addresses. If required, $localnet could even be defined as a list of networks. Whatever the specific needs, a sensible $localnet definition could be - used in a - typical pass rule as follows: + used in a typical pass rule as follows: pass from $localnet to any port $ports keep state - The following sample ruleset allows all traffic initiated by - machines on the internal network. It first defines two - macros to represent the external and internal 3COM interfaces of - the gateway. - - - For dialup users, the external interface will use - tun0. For an - ADSL connection, specifically those - using PPP over Ethernet (PPPoE), the correct external - interface is tun0, - not the physical Ethernet - interface. - + The following sample ruleset allows all traffic + initiated by machines on the internal network. It first + defines two macros to represent the external and internal + 3COM interfaces of the gateway. + + + For dialup users, the external interface will use + tun0. For an + ADSL connection, specifically those + using PPP over Ethernet + (PPPoE), the correct external + interface is tun0, not the physical + Ethernet interface. + ext_if = "xl0" # macro for external interface - use tun0 for PPPoE int_if = "xl1" # macro for internal interface @@ -722,20 +720,20 @@ nat on $ext_if from $localnet to any -&g block all pass from { lo0, $localnet } to any keep state - This ruleset introduces the nat rule which is used to - handle the network address translation from the - non-routable addresses inside the internal network to the IP address - assigned to the external interface. The parentheses surrounding the last part of the nat - rule ($ext_if) is included - when the IP address of the external - interface is dynamically assigned. It - ensures that network traffic runs without serious - interruptions even if the external IP address - changes. - - Note that this ruleset probably allows more - traffic to pass out of the network than is needed. - One reasonable setup could create this macro: + This ruleset introduces the nat rule + which is used to handle the network address translation from + the non-routable addresses inside the internal network to + the IP address assigned to the external + interface. The parentheses surrounding the last part of the + nat rule ($ext_if) is included when the + IP address of the external interface is + dynamically assigned. It ensures that network traffic runs + without serious interruptions even if the external + IP address changes. + + Note that this ruleset probably allows more traffic to + pass out of the network than is needed. One reasonable + setup could create this macro: client_out = "{ ftp-data, ftp, ssh, domain, pop3, auth, nntp, http, \ https, cvspserver, 2628, 5999, 8000, 8080 }" @@ -751,27 +749,24 @@ pass from { lo0, $localnet } to any keep pass in inet proto tcp to $ext_if port ssh This macro definition and rule allows - DNS and NTP for internal - clients: + DNS and NTP for + internal clients: udp_services = "{ domain, ntp }" pass quick inet proto { tcp, udp } to any port $udp_services keep state - Note the quick keyword in this - rule. Since the ruleset consists of - several rules, it is important to understand the - relationships between the rules in a ruleset. Rules - are evaluated from top to bottom, in the sequence they are - written. For each packet or - connection evaluated by PF, + Note the quick keyword in this rule. + Since the ruleset consists of several rules, it is important + to understand the relationships between the rules in a + ruleset. Rules are evaluated from top to bottom, in the + sequence they are written. For each packet or connection + evaluated by PF, the last matching rule in the ruleset - is the one which is applied. However, - when a packet matches a rule which - contains the quick keyword, - the rule processing stops and the packet is treated - according to that rule. This is very - useful when an exception to the general rules - is needed. + is the one which is applied. However, when a packet matches + a rule which contains the quick keyword, + the rule processing stops and the packet is treated + according to that rule. This is very useful when an + exception to the general rules is needed. @@ -781,7 +776,8 @@ pass quick inet proto { tcp, udp } to an problematic due to the nature of the FTP protocol. FTP pre-dates firewalls by several decades and is insecure in its design. The most - common points against using FTP include: + common points against using FTP + include: @@ -800,52 +796,49 @@ pass quick inet proto { tcp, udp } to an - All of these points present security challenges, - even before considering any potential security weaknesses in client - or server software. More - secure alternatives for file transfer exist, such as &man.sftp.1; - or &man.scp.1;, which both feature authentication and data - transfer over encrypted connections.. + All of these points present security challenges, even + before considering any potential security weaknesses in + client or server software. More secure alternatives for + file transfer exist, such as &man.sftp.1; or &man.scp.1;, + which both feature authentication and data transfer over + encrypted connections.. For those situations when FTP is required, PF provides redirection of FTP traffic to a small - proxy program called - &man.ftp-proxy.8;, which is included in the base system of &os;. - The role of - the proxy is to dynamically insert and delete rules in the ruleset, using - a set of anchors, in order to correctly handle + proxy program called &man.ftp-proxy.8;, which is included in + the base system of &os;. The role of the proxy is to + dynamically insert and delete rules in the ruleset, using a + set of anchors, in order to correctly handle FTP traffic. - To enable the FTP proxy, add this line to - /etc/rc.conf: + To enable the FTP proxy, add this + line to /etc/rc.conf: ftpproxy_enable="YES" - Then start the proxy by running - service ftp-proxy start. + Then start the proxy by running service + ftp-proxy start. - For a basic configuration, three elements need to - be added to /etc/pf.conf. First, the - anchors which the proxy will use to insert the rules it generates for the - FTP sessions: + For a basic configuration, three elements need to be + added to /etc/pf.conf. First, the + anchors which the proxy will use to insert the rules it + generates for the FTP sessions: nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" - Second, a pass rule is - needed to allow FTP traffic in to the - proxy. + Second, a pass rule is needed to allow + FTP traffic in to the proxy. Third, redirection and NAT rules need - to be defined before the - filtering rules. Insert this rdr rule immediately - after the nat rule: + to be defined before the filtering rules. Insert this + rdr rule immediately after the + nat rule: rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 - Finally, allow the redirected traffic to - pass: + Finally, allow the redirected traffic to pass: pass out proto tcp from $proxy to any port ftp @@ -882,78 +875,74 @@ rdr-anchor "ftp-proxy/*" Managing <acronym>ICMP</acronym> - Many of the tools used for debugging or - troubleshooting a TCP/IP network rely on the - Internet Control Message Protocol (ICMP), which + Many of the tools used for debugging or troubleshooting + a TCP/IP network rely on the Internet + Control Message Protocol (ICMP), which was designed specifically with debugging in mind. - The ICMP protocol sends and - receives control messages between - hosts and gateways, mainly to provide feedback to a sender - about any unusual or difficult conditions enroute to the - target host. + The ICMP protocol sends and receives + control messages between hosts and + gateways, mainly to provide feedback to a sender about any + unusual or difficult conditions enroute to the target host. Routers use ICMP to negotiate packet sizes and other transmission parameters in a process often referred to as path MTU discovery. - From a firewall perspective, some ICMP - control messages are vulnerable to known attack vectors. - Also, letting all diagnostic traffic pass unconditionally - makes debugging easier, but it also makes it - easier for others to extract information about - the network. For these reasons, the following rule may not be + From a firewall perspective, some + ICMP control messages are vulnerable to + known attack vectors. Also, letting all diagnostic traffic + pass unconditionally makes debugging easier, but it also + makes it easier for others to extract information about the + network. For these reasons, the following rule may not be optimal: pass inet proto icmp from any to any - One solution is to let all - ICMP traffic from the local network through - while stopping all probes from outside the network: + One solution is to let all ICMP + traffic from the local network through while stopping all + probes from outside the network: pass inet proto icmp from $localnet to any keep state pass inet proto icmp from any to $ext_if keep state - Additional - options are available which demonstrate some of - PF's flexibility. For example, - rather than allowing all ICMP messages, - one can specify the messages used by &man.ping.8; and - &man.traceroute.8;. Start by defining a macro for - that type of message: - - icmp_types = "echoreq" - - and a rule which uses the macro: - - pass inet proto icmp all icmp-type $icmp_types keep state - - If other types of ICMP packets - are needed, expand icmp_types - to a list of those packet types. Type - more /usr/src/contrib/pf/pfctl/pfctl_parser.c - to see the list of ICMP message - types supported by PF. Refer to - Additional options are available which demonstrate some + of PF's flexibility. For + example, rather than allowing all ICMP + messages, one can specify the messages used by &man.ping.8; + and &man.traceroute.8;. Start by defining a macro for that + type of message: + + icmp_types = "echoreq" + + and a rule which uses the macro: + + pass inet proto icmp all icmp-type $icmp_types keep state + + If other types of ICMP packets are + needed, expand icmp_types to a list of + those packet types. Type more + /usr/src/contrib/pf/pfctl/pfctl_parser.c to see + the list of ICMP message types supported + by PF. Refer to http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml - for an explanation of each message type. + for an explanation of each message type. - Since Unix traceroute uses UDP - by default, another rule is needed to allow Unix - traceroute: + Since Unix traceroute uses + UDP by default, another rule is needed to + allow Unix traceroute: - # allow out the default range for traceroute(8): + # allow out the default range for traceroute(8): pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state - Since TRACERT.EXE on Microsoft Windows systems - uses ICMP echo request messages, - only the - first rule is needed to allow network traces from those systems. Unix traceroute - can be instructed to use other protocols as well, and will - use ICMP echo request messages if - is used. Check the &man.traceroute.8; - man page for - details. + Since TRACERT.EXE on Microsoft + Windows systems uses ICMP echo request + messages, only the first rule is needed to allow network + traces from those systems. Unix + traceroute can be instructed to use other + protocols as well, and will use ICMP echo + request messages if is used. Check the + &man.traceroute.8; man page for details. Path <acronym>MTU</acronym> Discovery @@ -962,66 +951,62 @@ pass out on $ext_if inet proto udp from independent, and one consequence of device independence is that the optimal packet size for a given connection cannot always be predicted reliably. The main constraint on - packet size is the - Maximum Transmission Unit - (MTU) which sets the upper limit on the - packet size for an interface. Type ifconfig to view the - MTUs for a system's network interfaces. - - TCP/IP uses a process known as path - MTU discovery to - determine the right packet size for a connection. This - process sends packets of - varying sizes with the Do not fragment flag - set, expecting an ICMP return packet - of type 3, code 4 when the upper + packet size is the Maximum Transmission + Unit (MTU) which sets the + upper limit on the packet size for an interface. Type + ifconfig to view the + MTUs for a system's network + interfaces. + + TCP/IP uses a process known as path + MTU discovery to determine the right + packet size for a connection. This process sends packets + of varying sizes with the Do not fragment + flag set, expecting an ICMP return + packet of type 3, code 4 when the upper limit has been reached. Type 3 means destination unreachable, and code 4 is short for fragmentation needed, but the do-not-fragment flag is set. To allow path MTU discovery in order - to support connections to other MTUs, add - the - destination unreachable type to the - icmp_types macro: + to support connections to other MTUs, + add the destination unreachable type to + the icmp_types macro: icmp_types = "{ echoreq, unreach }" - Since - the pass rule already uses that macro, it does not need to - be modified in order to support the new + Since the pass rule already uses that macro, it does + not need to be modified in order to support the new ICMP type: pass inet proto icmp all icmp-type $icmp_types keep state PF allows filtering on all variations of ICMP types and codes. - The list of possible - types and codes are documented in &man.icmp.4; and - &man.icmp6.4;. + The list of possible types and codes are documented in + &man.icmp.4; and &man.icmp6.4;. Using Tables - Some types of data - are relevant to filtering and redirection at a given time, - but their definition is too long to be included in the ruleset file. + Some types of data are relevant to filtering and + redirection at a given time, but their definition is too + long to be included in the ruleset file. PF supports the use of tables, - which are defined lists that can be - manipulated without needing to reload the entire ruleset, - and which can provide fast lookups. Table names are - always enclosed within < >, like - this: + which are defined lists that can be manipulated without + needing to reload the entire ruleset, and which can provide + fast lookups. Table names are always enclosed within + < >, like this: table <clients> { 192.168.2.0/24, !192.168.2.5 } - In this example, the 192.168.2.0/24 network - is part of the table, except for the address - 192.168.2.5, which is excluded using - the ! operator. It is - also possible to load tables from files where each item is - on a separate line, as seen in this example + In this example, the 192.168.2.0/24 + network is part of the table, except for the address + 192.168.2.5, which is excluded using the + ! operator. It is also possible to load + tables from files where each item is on a separate line, as + seen in this example /etc/clients: 192.168.2.0/24 @@ -1036,33 +1021,34 @@ pass out on $ext_if inet proto udp from pass inet proto tcp from <clients> to any port $client_out flags S/SA keep state - A table's contents can be manipulated live, using pfctl. - This example adds another network to the table: + A table's contents can be manipulated live, using + pfctl. This example adds another network + to the table: &prompt.root; pfctl -t clients -T add 192.168.1.0/16 - Note that any changes made this way will take affect now, - making them ideal for testing, - but will not survive a power - failure or reboot. To make the changes permanent, modify the - definition of the table in the ruleset or edit the file that the - table refers to. One can maintain the on-disk copy of the table - using a &man.cron.8; job which dumps the table's contents to - disk at regular intervals, using a command such as - pfctl -t clients -T show + Note that any changes made this way will take affect + now, making them ideal for testing, but will not survive a + power failure or reboot. To make the changes permanent, + modify the definition of the table in the ruleset or edit + the file that the table refers to. One can maintain the + on-disk copy of the table using a &man.cron.8; job which + dumps the table's contents to disk at regular intervals, + using a command such as pfctl -t clients -T show >/etc/clients. Alternatively, - /etc/clients can be updated with - the in-memory table contents: + /etc/clients can be updated with the + in-memory table contents: &prompt.root; pfctl -t clients -T replace -f /etc/clients - Using Overload Tables to Protect <acronym>SSH</acronym> + Using Overload Tables to Protect + <acronym>SSH</acronym> - Those who run SSH on an external interface - have probably seen something - like this in the authentication logs: + Those who run SSH on an external + interface have probably seen something like this in the + authentication logs: Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2 Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200.72.41.31 port 40992 ssh2 @@ -1072,29 +1058,26 @@ Sep 26 03:12:44 skapet sshd[24703]: inpu Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2 This is indicative of a brute force attack where - somebody or some program - is trying to discover the - user name and password which will let them - into the system. + somebody or some program is trying to discover the user name + and password which will let them into the system. If external SSH access is needed for legitimate users, changing the default port used by - SSH can offer some protection. - However, PF provides a more - elegant solution. Pass rules can contain - limits on what connecting hosts can do and - violators can be banished to a table of - addresses which are denied some or all access. It - is even possible to drop all existing connections from - machines which overreach the limits. + SSH can offer some protection. However, + PF provides a more elegant + solution. Pass rules can contain limits on what connecting + hosts can do and violators can be banished to a table of + addresses which are denied some or all access. It is even + possible to drop all existing connections from machines + which overreach the limits. - To configure this, create this table in the tables section - of the ruleset: + To configure this, create this table in the tables + section of the ruleset: table <bruteforce> persist - Then, somewhere early in the ruleset, add rules - to block brute access while allowing legitimate access: + Then, somewhere early in the ruleset, add rules to block + brute access while allowing legitimate access: block quick from <bruteforce> pass inet proto tcp from any to $localnet port $tcp_services \ @@ -1110,18 +1093,20 @@ pass inet proto tcp from any to $localne simultaneous connections allowed from one host. max-src-conn-rate is the rate of new - connections allowed from any single host (15) - per number of seconds (5). + connections allowed from any single host + (15) per number of seconds + (5). overload <bruteforce> means that any host which exceeds these limits gets its address - added to the bruteforce table. The ruleset - blocks all traffic from addresses in the bruteforce - table. + added to the bruteforce table. The + ruleset blocks all traffic from addresses in the + bruteforce table. Finally, flush global says that when - a host reaches the limit, that all (global) of that host's connections will be - terminated (flush). + a host reaches the limit, that all + (global) of that host's connections will + be terminated (flush). These rules will not block slow @@ -1129,10 +1114,10 @@ pass inet proto tcp from any to $localne xlink:href="http://home.nuug.no/~peter/hailmary2013/">http://home.nuug.no/~peter/hailmary2013/. - This example ruleset - is intended mainly as an illustration. For example, if a generous number of connections in - general are wanted, but the desire is to be more - restrictive when it comes to + This example ruleset is intended mainly as an + illustration. For example, if a generous number of + connections in general are wanted, but the desire is to be + more restrictive when it comes to ssh, supplement the rule above with something like the one below, early on in the rule set: @@ -1146,481 +1131,474 @@ pass inet proto tcp from any to $localne It May Not be Necessary to Block All Overloaders - It is worth noting that the - overload mechanism is a general - technique which does not apply exclusively to - SSH, and it is not always - optimal to entirely block all traffic from offenders. + It is worth noting that the overload mechanism is a + general technique which does not apply exclusively to + SSH, and it is not always optimal to + entirely block all traffic from offenders. For example, an overload rule could be used to protect a mail service or a web service, and the overload table could be used in a rule to assign offenders to a - queue with a minimal bandwidth allocation or - to redirect to a specific web page. + queue with a minimal bandwidth allocation or to redirect + to a specific web page. - Over time, tables will be filled by - overload rules and their size - will grow incrementally, taking up more memory. - Sometimes an IP address that is blocked - is a dynamically assigned - one, which has since been assigned to a host who - has a legitimate reason to communicate with hosts in - the local network. - - For situations like these, - pfctl provides the ability to - expire table entries. For example, this - command will remove <bruteforce> - table entries which have not been referenced for 86400 - seconds: - - &prompt.root; pfctl -t bruteforce -T expire 86400 - - Similar functionality is provided by - security/expiretable, which - removes table entries which have not been accessed for a - specified period of time. - - Once installed, - expiretable can be run to remove - <bruteforce> table entries older - than a specified age. This example removes all entries - older than 24 hours: + Over time, tables will be filled by overload rules and + their size will grow incrementally, taking up more memory. + Sometimes an IP address that is blocked + is a dynamically assigned one, which has since been assigned + to a host who has a legitimate reason to communicate with + hosts in the local network. + + For situations like these, + pfctl provides the ability to + expire table entries. For example, this command will remove + <bruteforce> table entries which + have not been referenced for 86400 + seconds: + + &prompt.root; pfctl -t bruteforce -T expire 86400 + + Similar functionality is provided by + security/expiretable, which removes table + entries which have not been accessed for a specified period + of time. + + Once installed, expiretable + can be run to remove <bruteforce> + table entries older than a specified age. This example + removes all entries older than 24 hours: - /usr/local/sbin/expiretable -v -d -t 24h bruteforce + /usr/local/sbin/expiretable -v -d -t 24h bruteforce - - Protecting Against <acronym>SPAM</acronym> + + Protecting Against <acronym>SPAM</acronym> - Not to be confused with the - spamd daemon which comes - bundled with spamassassin, the - PF companion - spamd was designed to run on a - PF gateway to form part of the outer defense against spam. - spamd hooks into the - PF configuration via a set of - redirections. - - The main point underlying the - spamd design is the fact that - spammers send a large number of messages, and the - probability that you are the first person receiving a - particular message is incredibly small. In addition, - spam is mainly sent via a few spammer friendly networks - and a large number of hijacked machines. Both the - individual messages and the machines will be reported to - blacklists fairly quickly, and this is the kind of data - spamd can use to our advantage - with blacklists. - - What spamd does to SMTP - connections from addresses in the blacklist is to - present its banner and immediately switch to a mode - where it answers SMTP traffic one byte at the time. This - technique, which is intended to waste as much time as - possible on the sending end while costing the receiver - pretty much nothing, is called - tarpitting. The specific - implementation with one byte SMTP replies is often - referred to as stuttering. - - This example demonstrates the basic procedure for setting up - spamd with automatically - updated blacklists: - - - - Install the mail/spamd/ port. - In particular, be sure to read the package message - and act upon what it says. Specifically, to use - spamd's greylisting - features, a file descriptor file system (see fdescfs(5)) - must be mounted at /dev/fd/. - Do this by adding the following line to - /etc/fstab: - - fdescfs /dev/fd fdescfs rw 0 0 - - Make sure the fdescfs code - is in the kernel, either compiled in or by loading - the module with &man.kldload.8;. - + Not to be confused with the + spamd daemon which comes + bundled with spamassassin, the + PF companion + spamd was designed to run on a + PF gateway to form part of the outer defense against spam. + spamd hooks into the + PF configuration via a set of + redirections. + + The main point underlying the + spamd design is the fact that + spammers send a large number of messages, and the + probability that you are the first person receiving a + particular message is incredibly small. In addition, + spam is mainly sent via a few spammer friendly networks + and a large number of hijacked machines. Both the + individual messages and the machines will be reported to + blacklists fairly quickly, and this is the kind of data + spamd can use to our advantage + with blacklists. + + What spamd does to SMTP + connections from addresses in the blacklist is to + present its banner and immediately switch to a mode + where it answers SMTP traffic one byte at the time. This + technique, which is intended to waste as much time as + possible on the sending end while costing the receiver + pretty much nothing, is called + tarpitting. The specific + implementation with one byte SMTP replies is often + referred to as stuttering. + + This example demonstrates the basic procedure for + setting up spamd with + automatically updated blacklists: + + + + Install the mail/spamd/ port. + In particular, be sure to read the package message + and act upon what it says. Specifically, to use + spamd's greylisting + features, a file descriptor file system (see fdescfs(5)) + must be mounted at /dev/fd/. + Do this by adding the following line to + /etc/fstab: + + fdescfs /dev/fd fdescfs rw 0 0 + + Make sure the fdescfs code + is in the kernel, either compiled in or by loading + the module with &man.kldload.8;. + - - Next, edit the ruleset to include + + Next, edit the ruleset to include - table <spamd> persist + table <spamd> persist table <spamd-white> persist rdr pass on $ext_if inet proto tcp from <spamd> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 rdr pass on $ext_if inet proto tcp from !<spamd-white> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 - The two tables <spamd> and - <spamd-white> are essential. SMTP traffic - from the addresses in the first table plus the ones - which are not in the other table are redirected to a - daemon listening at port 8025. - - - - The next step is to set up - spamd's own configuration - in /usr/local/etc/spamd.conf - supplemented by rc.conf - parameters. - - The supplied sample file offers quite a bit of - explanation, and the man page offers additional - information, but we will recap the essentials - here. - - One of the first lines without a - # comment sign at the start - contains the block which defines the - all list, which specifies the - lists actually used: + The two tables <spamd> and + <spamd-white> are essential. SMTP traffic + from the addresses in the first table plus the ones + which are not in the other table are redirected to a + daemon listening at port 8025. + + + + The next step is to set up + spamd's own configuration + in /usr/local/etc/spamd.conf + supplemented by rc.conf + parameters. + + The supplied sample file offers quite a bit of + explanation, and the man page offers additional + information, but we will recap the essentials + here. + + One of the first lines without a + # comment sign at the start + contains the block which defines the + all list, which specifies the + lists actually used: - all:\ + all:\ :traplist:whitelist: - Here, all the desired black lists are added, - separated by colons (:). To use - whitelists to subtract addresses from the blacklist, - add the name of the whitelist immediately after the - name of each blacklist, i.e., - :blacklist:whitelist:. + Here, all the desired black lists are added, + separated by colons (:). To use + whitelists to subtract addresses from the blacklist, + add the name of the whitelist immediately after the + name of each blacklist, i.e., + :blacklist:whitelist:. - Next up is a blacklist definition: + Next up is a blacklist definition: - traplist:\ + traplist:\ :black:\ :msg="SPAM. Your address %A has sent spam within the last 24 hours":\ :method=http:\ :file=www.openbsd.org/spamd/traplist.gz - Following the name, the first data field - specifies the list type, in this case - black. The - msg field contains the message to - display to blacklisted senders during the SMTP - dialogue. The method field - specifies how spamd-setup fetches the list data, - here http. The other options are - fetching via ftp, from a - file in a mounted file system or - via exec of an external program. - Finally the file field specifies - the name of the file spamd expects to - receive. + Following the name, the first data field + specifies the list type, in this case + black. The + msg field contains the message to + display to blacklisted senders during the SMTP + dialogue. The method field + specifies how spamd-setup fetches the list data, + here http. The other options are + fetching via ftp, from a + file in a mounted file system or + via exec of an external program. + Finally the file field specifies + the name of the file spamd expects to receive. - The definition of a whitelist follows much the - same pattern: + The definition of a whitelist follows much the + same pattern: - whitelist:\ + whitelist:\ :white:\ :method=file:\ :file=/var/mail/whitelist.txt *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 17:05:25 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45A40614; Wed, 19 Feb 2014 17:05:24 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BACDF1C98; Wed, 19 Feb 2014 17:05:24 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JH5O2m068283; Wed, 19 Feb 2014 17:05:24 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JH5OuR068282; Wed, 19 Feb 2014 17:05:24 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402191705.s1JH5OuR068282@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 17:05:24 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43989 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:05:25 -0000 Author: dru Date: Wed Feb 19 17:05:24 2014 New Revision: 43989 URL: http://svnweb.freebsd.org/changeset/doc/43989 Log: Editorial pass through spamd section. The last step on using spamd-setup should be expanded at some point. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 18 22:23:51 2014 (r43988) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 17:05:24 2014 (r43989) @@ -1176,63 +1176,59 @@ pass inet proto tcp from any to $localne Protecting Against <acronym>SPAM</acronym> Not to be confused with the - spamd daemon which comes - bundled with spamassassin, the - PF companion - spamd was designed to run on a - PF gateway to form part of the outer defense against spam. - spamd hooks into the - PF configuration via a set of + spamd daemon which comes bundled + with spamassassin, + mail/spamd/ can be configured with + PF to provide an outer defense against SPAM. + This spamd hooks into the + PF configuration using a set of redirections. - The main point underlying the - spamd design is the fact that - spammers send a large number of messages, and the - probability that you are the first person receiving a - particular message is incredibly small. In addition, - spam is mainly sent via a few spammer friendly networks - and a large number of hijacked machines. Both the - individual messages and the machines will be reported to - blacklists fairly quickly, and this is the kind of data - spamd can use to our advantage - with blacklists. - - What spamd does to SMTP - connections from addresses in the blacklist is to - present its banner and immediately switch to a mode - where it answers SMTP traffic one byte at the time. This + Spammers tend to send a large number of messages, and + SPAM is mainly sent from a few spammer friendly networks + and a large number of hijacked machines, both of which + are reported to + blacklists fairly quickly. + + When an SMTP + connection from an address in a blacklist is received, + spamd + presents its banner and immediately switches to a mode + where it answers SMTP traffic one byte at a time. This technique, which is intended to waste as much time as - possible on the sending end while costing the receiver - pretty much nothing, is called + possible on the spammer's end, is called tarpitting. The specific - implementation with one byte SMTP replies is often + implementation which uses one byte SMTP replies is often referred to as stuttering. This example demonstrates the basic procedure for setting up spamd with - automatically updated blacklists: + automatically updated blacklists. Refer to the man pages + which are installed with mail/spamd/ for + more information. + Configuring <application>spamd</application> + - Install the mail/spamd/ port. - In particular, be sure to read the package message - and act upon what it says. Specifically, to use + Install the mail/spamd/ package or port. + In order to use spamd's greylisting - features, a file descriptor file system (see fdescfs(5)) - must be mounted at /dev/fd/. - Do this by adding the following line to + features, &man.fdescfs.5; + must be mounted at /dev/fd. + Add the following line to /etc/fstab: fdescfs /dev/fd fdescfs rw 0 0 - Make sure the fdescfs code - is in the kernel, either compiled in or by loading - the module with &man.kldload.8;. + Then, mount the filesystem: + + &prompt.root; mount fdescfs + - Next, edit the ruleset to include + Next, edit the PF ruleset to include: table <spamd> persist table <spamd-white> persist @@ -1241,42 +1237,44 @@ rdr pass on $ext_if inet proto tcp from rdr pass on $ext_if inet proto tcp from !<spamd-white> to \ { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 - The two tables <spamd> and - <spamd-white> are essential. SMTP traffic - from the addresses in the first table plus the ones - which are not in the other table are redirected to a + The two tables <spamd> and + <spamd-white> are essential. SMTP traffic + from an address listed in <spamd> but not in + <spamd-white> is redirected to the spamd daemon listening at port 8025. - The next step is to set up - spamd's own configuration - in /usr/local/etc/spamd.conf - supplemented by rc.conf + The next step is to configure + spamd + in /usr/local/etc/spamd.conf and to + add some rc.conf parameters. - The supplied sample file offers quite a bit of - explanation, and the man page offers additional - information, but we will recap the essentials - here. + The installation of mail/spamd/ + includes a sample configuration file + (/usr/local/etc/spamd.conf.sample) and a + man page for spamd.conf. Refer to + these for additional configuration options beyond those + shown in this example. - One of the first lines without a - # comment sign at the start + One of the first lines in the configuration file that does not begin with a + # comment sign contains the block which defines the all list, which specifies the - lists actually used: + lists to use: all:\ :traplist:whitelist: - Here, all the desired black lists are added, - separated by colons (:). To use - whitelists to subtract addresses from the blacklist, - add the name of the whitelist immediately after the - name of each blacklist, i.e., + This entry adds the desired blacklists, + separated by colons (:). To use a + whitelist to subtract addresses from a blacklist, + add the name of the whitelist immediately after the + name of that blacklist. For example: :blacklist:whitelist:. - Next up is a blacklist definition: + This is followed by the specified blacklist's definition: traplist:\ :black:\ @@ -1284,56 +1282,49 @@ rdr pass on $ext_if inet proto tcp from :method=http:\ :file=www.openbsd.org/spamd/traplist.gz - Following the name, the first data field - specifies the list type, in this case - black. The + where the first line is the name of the blacklist and the second line + specifies the list type. The msg field contains the message to - display to blacklisted senders during the SMTP + display to blacklisted senders during the SMTP dialogue. The method field - specifies how spamd-setup fetches the list data, - here http. The other options are - fetching via ftp, from a - file in a mounted file system or + specifies how spamd-setup fetches the list data; + supported methods are http, + ftp, from a + file in a mounted file system, and via exec of an external program. - Finally the file field specifies - the name of the file spamd expects to receive. + Finally, the file field specifies + the name of the file spamd expects to receive. - The definition of a whitelist follows much the - same pattern: + The definition of the specified whitelist is + similar, but omits the msg field since a + message is not needed: whitelist:\ :white:\ :method=file:\ :file=/var/mail/whitelist.txt - but omits the message parameters since a - message is not needed. - Choose Data Sources with Care Using all the blacklists in the sample - spamd.conf will end up - blacklisting large blocks of the Internet, - including several Asian nations. Administrators - need to edit the file to end up with an optimal - configuration. The administrator is the judge of - which data sources to use, and using lists other - than the ones suggested in the sample file is - possible. + spamd.conf will + blacklist large blocks of the Internet. Administrators + need to edit the file to create an optimal + configuration which uses applicable + data sources and, when necessary, uses custom lists. - Put the lines for spamd and any startup - parameters desired in /etc/rc.conf, - for example: - - spamd_flags="-v" # for normal use: "" and see spamd-setup(8) - - When done with editing the setup, reload the - ruleset, start spamd with the - options desired using the - /usr/local/etc/rc.d/obspamd - script, and complete the configuration using + Next, add this entry to /etc/rc.conf. + Additional flags are described in the man page specified + by the comment: + + spamd_flags="-v" # use "" and see spamd-setup(8) for flags + + When finished, reload the + ruleset, start spamd by typing + service start obspamd, + and complete the configuration using spamd-setup. Finally, create a &man.cron.8; job which calls spamd-setup to update the tables @@ -1342,7 +1333,7 @@ rdr pass on $ext_if inet proto tcp from On a typical gateway in front of a mail server, - hosts will start getting trapped within a few seconds to + hosts will soon start getting trapped within a few seconds to several minutes. From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 17:40:51 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F49D425; Wed, 19 Feb 2014 17:40:51 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E768510A1; Wed, 19 Feb 2014 17:40:50 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JHeov9081919; Wed, 19 Feb 2014 17:40:50 GMT (envelope-from blackend@svn.freebsd.org) Received: (from blackend@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JHeohO081918; Wed, 19 Feb 2014 17:40:50 GMT (envelope-from blackend@svn.freebsd.org) Message-Id: <201402191740.s1JHeohO081918@svn.freebsd.org> From: Marc Fonvieille Date: Wed, 19 Feb 2014 17:40:50 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43990 - head/en_US.ISO8859-1/books/handbook/bsdinstall X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:40:51 -0000 Author: blackend Date: Wed Feb 19 17:40:50 2014 New Revision: 43990 URL: http://svnweb.freebsd.org/changeset/doc/43990 Log: Attempt to correctly tag different items of the DNS Config screen. Modified: head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Wed Feb 19 17:05:24 2014 (r43989) +++ head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Wed Feb 19 17:40:50 2014 (r43990) @@ -1976,10 +1976,10 @@ Trying to mount root from cd9660:/dev/is DNS) Resolver converts hostnames to and from network addresses. If DHCP or SLAAC was used - to autoconfigure the network interface, the Resolver - Configuration values may already be present. Otherwise, + to autoconfigure the network interface, the Resolver + Configuration values may already be present. Otherwise, enter the local network's domain name in the Search field. - DNS #1 and DNS #2 are + DNS #1 and DNS #2 are the IP addresses for the local DNS servers. At least one DNS server is required. From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 17:45:13 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E6A8766; Wed, 19 Feb 2014 17:45:13 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A1CA112C; Wed, 19 Feb 2014 17:45:13 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JHjCSO084384; Wed, 19 Feb 2014 17:45:12 GMT (envelope-from blackend@svn.freebsd.org) Received: (from blackend@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JHjCkn084383; Wed, 19 Feb 2014 17:45:12 GMT (envelope-from blackend@svn.freebsd.org) Message-Id: <201402191745.s1JHjCkn084383@svn.freebsd.org> From: Marc Fonvieille Date: Wed, 19 Feb 2014 17:45:12 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43991 - head/en_US.ISO8859-1/books/handbook/bsdinstall X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:45:13 -0000 Author: blackend Date: Wed Feb 19 17:45:12 2014 New Revision: 43991 URL: http://svnweb.freebsd.org/changeset/doc/43991 Log: Add another missing tags. Modified: head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Wed Feb 19 17:40:50 2014 (r43990) +++ head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Wed Feb 19 17:45:12 2014 (r43991) @@ -1978,7 +1978,7 @@ Trying to mount root from cd9660:/dev/is DHCP or SLAAC was used to autoconfigure the network interface, the Resolver Configuration values may already be present. Otherwise, - enter the local network's domain name in the Search field. + enter the local network's domain name in the Search field. DNS #1 and DNS #2 are the IP addresses for the local DNS servers. At least one From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 17:51:01 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89E52844; Wed, 19 Feb 2014 17:51:01 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 75A0E11B5; Wed, 19 Feb 2014 17:51:01 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JHp1WZ086752; Wed, 19 Feb 2014 17:51:01 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JHp1xn086751; Wed, 19 Feb 2014 17:51:01 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402191751.s1JHp1xn086751@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 17:51:01 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43992 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:51:01 -0000 Author: dru Date: Wed Feb 19 17:51:00 2014 New Revision: 43992 URL: http://svnweb.freebsd.org/changeset/doc/43992 Log: Editorial pass through greylisting section. At some point, expanding on how to use spamdb would be useful. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 17:45:12 2014 (r43991) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 17:51:00 2014 (r43992) @@ -1336,117 +1336,60 @@ rdr pass on $ext_if inet proto tcp from hosts will soon start getting trapped within a few seconds to several minutes. - - Adding Greylisting to the Setup - - spamd also supports - greylisting, which works by - rejecting messages from unknown hosts temporarily with - 45n codes, letting messages - from hosts which try again within a reasonable time - through. Traffic from well behaved hosts, that is, + PF also supports + greylisting, which temporarily + rejects messages from unknown hosts with + 45n codes. Messages + from greylisted hosts which try again within a reasonable time + are let through. Traffic from senders which are set up to behave within the limits set - up in the relevant RFCs - The relevant RFCs are mainly RFC1123 - and RFC2821., will be let + by RFC 1123 + and RFC 2821 are immediately let through. - Greylisting as a technique was presented in a 2003 - paper by Evan Harris - The original - Harris paper and a number of other useful articles - and resources can be found at the More information about greylisting as a technique + can be found at the greylisting.org - web site., and a number of - implementations followed over the next few months. - OpenBSD's spamd acquired its - ability to greylist in OpenBSD 3.5, which was released - in May 2004. - - The most amazing thing about greylisting, apart + web site. The most amazing thing about greylisting, apart from its simplicity, is that it still works. Spammers - and malware writers have been very slow to adapt. + and malware writers have been very slow to adapt in order + to bypass this technique. - The basic procedure for adding greylisting to your - setup follows below. + The basic procedure for configuring greylisting is as + follows: + Configuring Greylisting - If not done already, make sure the - file descriptor file system (see &man.fdescfs.5;) is - mounted at /dev/fd/. Do this - by adding the following line to - /etc/fstab: - - fdescfs /dev/fd fdescfs rw 0 0 - - and make sure the &man.fdescfs.5; code is in the - kernel, either compiled in or by loading the module - with &man.kldload.8;. + Make sure that &man.fdescfs.5; is + mounted as described in Step 1 of the previous Procedure. To run spamd in - greylisting mode, /etc/rc.conf - must be changed slightly by adding + greylisting mode, add this line to /etc/rc.conf: spamd_grey="YES" # use spamd greylisting if YES - Several greylisting related parameters can be - fine-tuned with spamd's command - line parameters and the corresponding - /etc/rc.conf settings. Check - the spamd man page to see - what the parameters mean. + Refer to the spamd man page + for descriptions of additional related parameters. - To complete the greylisting setup, restart - spamd using the - /usr/local/etc/rc.d/obspamd - script. + To complete the greylisting setup: + + &prompt.root; service restart obspamd +&prompt.root; service start spamlogd - Behind the scenes, rarely mentioned and barely - documented are two of spamd's - helpers, the spamdb database + Behind the scenes, the spamdb database tool and the spamlogd - whitelist updater, which both perform essential - functions for the greylisting feature. Of the two - spamlogd works quietly in the - background, while spamdb has - been developed to offer some interesting - features. - - - Restart <application>spamd</application> to - Enable Greylisting - - After following all steps in the tutorial - exactly up to this point, - spamlogd has been started - automatically already. However, if the initial - spamd configuration did not - include greylisting, - spamlogd may not have been - started, and there may be strange symptoms, such as - greylists and whitelists not getting updated - properly. - - Under normal circumstances, it should not be - necessary to start spamlogd - by hand. Restarting spamd - after enabling greylisting ensures - spamlogd is loaded and - available too. - - - spamdb is the + whitelist updater perform essential + functions for the greylisting feature. spamdb is the administrator's main interface to managing the black, - grey and white lists via the contents of the + grey, and white lists via the contents of the /var/db/spamdb database. - From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 18:32:16 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 251EBFD5; Wed, 19 Feb 2014 18:32:16 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0FB0B1574; Wed, 19 Feb 2014 18:32:16 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JIWFwe003757; Wed, 19 Feb 2014 18:32:15 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JIWFhX003756; Wed, 19 Feb 2014 18:32:15 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402191832.s1JIWFhX003756@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 18:32:15 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43993 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:32:16 -0000 Author: dru Date: Wed Feb 19 18:32:15 2014 New Revision: 43993 URL: http://svnweb.freebsd.org/changeset/doc/43993 Log: Finish editorial pass through PF chapter. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 17:51:00 2014 (r43992) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 18:32:15 2014 (r43993) @@ -433,6 +433,13 @@ device pfsync privileges. It can be installed from the Ports Collection. + + To keep an eye on the traffic that passes through the + PF firewall, consider installing the + sysutils/pftop package or port. Once installed, + pftop can be run to view + a running snapshot of traffic in a format which is + similar to &man.top.1;. @@ -1400,94 +1407,80 @@ rdr pass on $ext_if inet proto tcp from and antispoof can be used to make the ruleset behave sanely. - block-policy is an option which + The block-policy is an option which can be set in the options part of the ruleset, which precedes the redirection and filtering rules. This option determines which feedback, if any, - PF will give to hosts which - try to create connections which are subsequently - blocked. The option has two possible values, - drop, which drops blocked packets - with no feedback, and return, which - returns with status codes such as - Connection refused or - similar. - - The correct strategy for block policies has been the - subject of rather a lot of discussion. We choose to - play nicely and instruct our firewall to issue - returns: + PF sends to hosts that are + blocked by a rule. The option has two possible values: + drop drops blocked packets + with no feedback, and return + returns a status code such as + Connection refused. + + If not set, the default policy is drop. To change the block-policy, specify + the desired value: set block-policy return - In PF versions up to - OpenBSD 4.5 inclusive, scrub is a - keyword which enables network packet normalization, - causing fragmented packets to be assembled and removing - ambiguity. Enabling scrub provides a + In PF, scrub is a + keyword which enables network packet normalization. This + process reassembles + fragmented packets and drops TCP packets that have invalid + flag combinations. Enabling scrub provides a measure of protection against certain kinds of attacks based on incorrect handling of packet fragments. A - number of supplementing options are available, but we - choose the simplest form which is suitable for most - configurations. + number of options are available, but the + simplest form is suitable for most + configurations: scrub in all - Some services, such as NFS, require some specific - fragment handling options. This is extensively - documented in the PF user - guide and man pages provide all the information you - could need. - - One fairly common example is this, + Some services, such as NFS, require specific + fragment handling options. Refer to + http://www.openbsd.gr/faq/pf/scrub.html + for more information. + + This example reassembles fragments, clears the + do not fragment bit, and sets the maximum + segment size to 1440 bytes: scrub in all fragment reassemble no-df max-mss 1440 - meaning, we reassemble fragments, clear the - do not fragment bit and set the maximum - segment size to 1440 bytes. Other variations are - possible, and you should be able to cater to various - specific needs by consulting the man pages and some - experimentation. - - antispoof is a common special - case of filtering and blocking. This mechanism protects - against activity from spoofed or forged IP addresses, + The antispoof mechanism protects + against activity from spoofed or forged IP addresses, mainly by blocking packets appearing on interfaces and in directions which are logically not possible. - We specify that we want to weed out spoofed traffic - coming in from the rest of the world and any spoofed - packets which, however unlikely, were to originate in - our own network: + These rules weed out spoofed traffic + coming in from the rest of the world as well as any spoofed + packets which originate in the local + network: antispoof for $ext_if antispoof for $int_if - Handling Non-Routable Addresses from - Elsewhere + Handling Non-Routable Addresses Even with a properly configured gateway to handle - network address translation for your own network, you - may find yourself in the unenviable position of having + network address translation, one may have to compensate for other people's - misconfigurations. + misconfigurations. A common misconfiguration is to + let traffic with non-routable + addresses out to the Internet. Since traffic from + non-routeable addresses can play a part in + several DoS attack techniques, + consider explicitly blocking traffic from + non-routeable addresses from entering the + network through the external interface. - One depressingly common class of misconfigurations - is the kind which lets traffic with non-routable - addresses out to the Internet. Traffic from - non-routeable addresses have also played a part in - several DOS attack techniques, so it may be worth - considering explicitly blocking traffic from - non-routeable addresses from entering your - network. - - One possible solution is the one outlined below, - which for good measure also blocks any attempt to - initiate contact to non-routable addresses through the - gateway's external interface: + In this example, a macro containing non-routable + addresses is defined, then used in blocking rules. Traffic to and from these addresses is + quietly dropped on the gateway's external + interface. martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \ @@ -1495,43 +1488,6 @@ antispoof for $int_if block drop in quick on $ext_if from $martians to any block drop out quick on $ext_if from any to $martians - - Here, the martians macro denotes - the RFC 1918 addresses and a few other ranges which are - mandated by various RFCs not to be in circulation on the - open Internet. Traffic to and from such addresses is - quietly dropped on the gateway's external - interface. - - The specific details of how to implement this kind - of protection will vary, among other things according to - your specific network configuration. Your network - design could for example dictate that you include or - exclude other address ranges than these. - - This completes our simple NATing firewall for a - small local network. A more thorough tutorial is - available at http://home.nuug.no/~peter/pf/, - where you will also find slides from related - presentations. - - - - Viewing Traffic - - Over time, a number of tools have been developed which - interact with PF in various - ways. - - Can Erkin Acar's pftop - makes it possible to keep an eye on what passes into and - out of the network. pftop is - available through the ports system as - sysutils/pftop. The name is a strong - hint at what it does - pftop - shows a running snapshot of traffic in a format which is - strongly inspired by &man.top.1;. From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 19:21:14 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 226D9EBE; Wed, 19 Feb 2014 19:21:14 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CD0A19A7; Wed, 19 Feb 2014 19:21:14 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JJLDAL024577; Wed, 19 Feb 2014 19:21:13 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JJLDS7024576; Wed, 19 Feb 2014 19:21:13 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402191921.s1JJLDS7024576@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 19:21:13 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43994 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:21:14 -0000 Author: dru Date: Wed Feb 19 19:21:13 2014 New Revision: 43994 URL: http://svnweb.freebsd.org/changeset/doc/43994 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 18:32:15 2014 (r43993) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 19:21:13 2014 (r43994) @@ -435,11 +435,11 @@ device pfsync To keep an eye on the traffic that passes through the - PF firewall, consider installing the - sysutils/pftop package or port. Once installed, - pftop can be run to view - a running snapshot of traffic in a format which is - similar to &man.top.1;. + PF firewall, consider installing + the sysutils/pftop package or port. Once + installed, pftop can be run to + view a running snapshot of traffic in a format which is + similar to &man.top.1;. @@ -1186,27 +1186,29 @@ pass inet proto tcp from any to $localne spamd daemon which comes bundled with spamassassin, mail/spamd/ can be configured with - PF to provide an outer defense against SPAM. - This spamd hooks into the + PF to provide an outer defense + against SPAM. This + spamd hooks into the PF configuration using a set of redirections. - Spammers tend to send a large number of messages, and - SPAM is mainly sent from a few spammer friendly networks - and a large number of hijacked machines, both of which - are reported to + Spammers tend to send a large number of messages, and + SPAM is mainly sent from a few spammer + friendly networks and a large number of hijacked machines, + both of which are reported to blacklists fairly quickly. - When an SMTP - connection from an address in a blacklist is received, - spamd - presents its banner and immediately switches to a mode - where it answers SMTP traffic one byte at a time. This + When an SMTP connection from an + address in a blacklist is received, + spamd presents its banner and + immediately switches to a mode where it answers + SMTP traffic one byte at a time. This technique, which is intended to waste as much time as possible on the spammer's end, is called tarpitting. The specific - implementation which uses one byte SMTP replies is often - referred to as stuttering. + implementation which uses one byte SMTP + replies is often referred to as + stuttering. This example demonstrates the basic procedure for setting up spamd with @@ -1218,12 +1220,12 @@ pass inet proto tcp from any to $localne Configuring <application>spamd</application> - Install the mail/spamd/ package or port. - In order to use + Install the mail/spamd/ package + or port. In order to use spamd's greylisting - features, &man.fdescfs.5; - must be mounted at /dev/fd. - Add the following line to + features, &man.fdescfs.5; must be mounted at /dev/fd. Add the + following line to /etc/fstab: fdescfs /dev/fd fdescfs rw 0 0 @@ -1231,11 +1233,11 @@ pass inet proto tcp from any to $localne Then, mount the filesystem: &prompt.root; mount fdescfs - - Next, edit the PF ruleset to include: + Next, edit the PF ruleset + to include: table <spamd> persist table <spamd-white> persist @@ -1245,43 +1247,45 @@ rdr pass on $ext_if inet proto tcp from { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025 The two tables <spamd> and - <spamd-white> are essential. SMTP traffic - from an address listed in <spamd> but not in - <spamd-white> is redirected to the spamd - daemon listening at port 8025. + <spamd-white> are essential. + SMTP traffic from an address listed + in <spamd> but not in + <spamd-white> is redirected to + the spamd daemon listening at + port 8025. The next step is to configure - spamd - in /usr/local/etc/spamd.conf and to - add some rc.conf - parameters. + spamd in + /usr/local/etc/spamd.conf and to + add some rc.conf parameters. The installation of mail/spamd/ includes a sample configuration file - (/usr/local/etc/spamd.conf.sample) and a - man page for spamd.conf. Refer to - these for additional configuration options beyond those - shown in this example. - - One of the first lines in the configuration file that does not begin with a - # comment sign - contains the block which defines the - all list, which specifies the - lists to use: + (/usr/local/etc/spamd.conf.sample) + and a man page for spamd.conf. + Refer to these for additional configuration options + beyond those shown in this example. + + One of the first lines in the configuration file + that does not begin with a # comment + sign contains the block which defines the + all list, which specifies the lists + to use: all:\ :traplist:whitelist: - This entry adds the desired blacklists, - separated by colons (:). To use a - whitelist to subtract addresses from a blacklist, - add the name of the whitelist immediately after the + This entry adds the desired blacklists, separated by + colons (:). To use a whitelist to + subtract addresses from a blacklist, add the name of the + whitelist immediately after the name of that blacklist. For example: :blacklist:whitelist:. - This is followed by the specified blacklist's definition: + This is followed by the specified blacklist's + definition: traplist:\ :black:\ @@ -1289,22 +1293,24 @@ rdr pass on $ext_if inet proto tcp from :method=http:\ :file=www.openbsd.org/spamd/traplist.gz - where the first line is the name of the blacklist and the second line - specifies the list type. The + where the first line is the name of the blacklist + and the second line specifies the list type. The msg field contains the message to - display to blacklisted senders during the SMTP - dialogue. The method field - specifies how spamd-setup fetches the list data; - supported methods are http, + display to blacklisted senders during the + SMTP dialogue. The + method field specifies how + spamd-setup fetches the list + data; supported methods are http, ftp, from a file in a mounted file system, and via exec of an external program. Finally, the file field specifies - the name of the file spamd expects to receive. + the name of the file spamd + expects to receive. The definition of the specified whitelist is - similar, but omits the msg field since a - message is not needed: + similar, but omits the msg field + since a message is not needed: whitelist:\ :white:\ @@ -1315,88 +1321,89 @@ rdr pass on $ext_if inet proto tcp from Choose Data Sources with Care Using all the blacklists in the sample - spamd.conf will - blacklist large blocks of the Internet. Administrators - need to edit the file to create an optimal - configuration which uses applicable - data sources and, when necessary, uses custom lists. + spamd.conf will blacklist large + blocks of the Internet. Administrators need to edit + the file to create an optimal configuration which uses + applicable data sources and, when necessary, uses + custom lists. - Next, add this entry to /etc/rc.conf. - Additional flags are described in the man page specified - by the comment: + Next, add this entry to + /etc/rc.conf. Additional flags are + described in the man page specified by the + comment: spamd_flags="-v" # use "" and see spamd-setup(8) for flags - When finished, reload the - ruleset, start spamd by typing - service start obspamd, - and complete the configuration using - spamd-setup. Finally, create a - &man.cron.8; job which calls - spamd-setup to update the tables - at reasonable intervals. + When finished, reload the ruleset, start + spamd by typing + service start obspamd, and complete + the configuration using spamd-setup. + Finally, create a &man.cron.8; job which calls + spamd-setup to update the tables at + reasonable intervals. - On a typical gateway in front of a mail server, - hosts will soon start getting trapped within a few seconds to + On a typical gateway in front of a mail server, hosts + will soon start getting trapped within a few seconds to several minutes. - PF also supports - greylisting, which temporarily - rejects messages from unknown hosts with - 45n codes. Messages - from greylisted hosts which try again within a reasonable time - are let through. Traffic from - senders which are set up to behave within the limits set - by RFC 1123 - and RFC 2821 are immediately let - through. - - More information about greylisting as a technique - can be found at the greylisting.org - web site. The most amazing thing about greylisting, apart - from its simplicity, is that it still works. Spammers - and malware writers have been very slow to adapt in order - to bypass this technique. - - The basic procedure for configuring greylisting is as - follows: - - - Configuring Greylisting - - Make sure that &man.fdescfs.5; is - mounted as described in Step 1 of the previous Procedure. - - - - To run spamd in - greylisting mode, add this line to /etc/rc.conf: - - spamd_grey="YES" # use spamd greylisting if YES - - Refer to the spamd man page - for descriptions of additional related parameters. - + PF also supports + greylisting, which temporarily + rejects messages from unknown hosts with + 45n codes. Messages from + greylisted hosts which try again within a reasonable time + are let through. Traffic from senders which are set up to + behave within the limits set by RFC 1123 and RFC 2821 are + immediately let through. + + More information about greylisting as a technique can be + found at the greylisting.org + web site. The most amazing thing about greylisting, apart + from its simplicity, is that it still works. Spammers and + malware writers have been very slow to adapt in order to + bypass this technique. + + The basic procedure for configuring greylisting is as + follows: + + + Configuring Greylisting + + + Make sure that &man.fdescfs.5; is mounted as + described in Step 1 of the previous Procedure. + + + + To run spamd in + greylisting mode, add this line to + /etc/rc.conf: - - To complete the greylisting setup: + spamd_grey="YES" # use spamd greylisting if YES - &prompt.root; service restart obspamd + Refer to the spamd man + page for descriptions of additional related + parameters. + + + + To complete the greylisting setup: + + &prompt.root; service restart obspamd &prompt.root; service start spamlogd - - + + - Behind the scenes, the spamdb database - tool and the spamlogd - whitelist updater perform essential - functions for the greylisting feature. spamdb is the - administrator's main interface to managing the black, - grey, and white lists via the contents of the - /var/db/spamdb database. + Behind the scenes, the spamdb + database tool and the spamlogd + whitelist updater perform essential functions for the + greylisting feature. spamdb is + the administrator's main interface to managing the black, + grey, and white lists via the contents of the + /var/db/spamdb database. @@ -1407,58 +1414,58 @@ rdr pass on $ext_if inet proto tcp from and antispoof can be used to make the ruleset behave sanely. - The block-policy is an option which - can be set in the options part of the - ruleset, which precedes the redirection and filtering - rules. This option determines which feedback, if any, - PF sends to hosts that are - blocked by a rule. The option has two possible values: - drop drops blocked packets - with no feedback, and return - returns a status code such as - Connection refused. - - If not set, the default policy is drop. To change the block-policy, specify - the desired value: - - set block-policy return - - In PF, scrub is a - keyword which enables network packet normalization. This - process reassembles - fragmented packets and drops TCP packets that have invalid - flag combinations. Enabling scrub provides a - measure of protection against certain kinds of attacks - based on incorrect handling of packet fragments. A - number of options are available, but the - simplest form is suitable for most - configurations: - - scrub in all - - Some services, such as NFS, require specific - fragment handling options. Refer to - The block-policy is an option which + can be set in the options part of the + ruleset, which precedes the redirection and filtering rules. + This option determines which feedback, if any, + PF sends to hosts that are + blocked by a rule. The option has two possible values: + drop drops blocked packets with no + feedback, and return returns a status + code such as + Connection refused. + + If not set, the default policy is + drop. To change the + block-policy, specify the desired + value: + + set block-policy return + + In PF, + scrub is a keyword which enables network + packet normalization. This process reassembles fragmented + packets and drops TCP packets that have invalid flag + combinations. Enabling scrub provides a + measure of protection against certain kinds of attacks + based on incorrect handling of packet fragments. A number + of options are available, but the simplest form is suitable + for most configurations: + + scrub in all + + Some services, such as NFS, require + specific fragment handling options. Refer to http://www.openbsd.gr/faq/pf/scrub.html - for more information. + for more information. - This example reassembles fragments, clears the - do not fragment bit, and sets the maximum - segment size to 1440 bytes: + This example reassembles fragments, clears the + do not fragment bit, and sets the maximum + segment size to 1440 bytes: - scrub in all fragment reassemble no-df max-mss 1440 + scrub in all fragment reassemble no-df max-mss 1440 - The antispoof mechanism protects - against activity from spoofed or forged IP addresses, - mainly by blocking packets appearing on interfaces and - in directions which are logically not possible. + The antispoof mechanism protects + against activity from spoofed or forged + IP addresses, mainly by blocking packets + appearing on interfaces and in directions which are + logically not possible. - These rules weed out spoofed traffic - coming in from the rest of the world as well as any spoofed - packets which originate in the local - network: + These rules weed out spoofed traffic coming in from the + rest of the world as well as any spoofed packets which + originate in the local network: - antispoof for $ext_if + antispoof for $ext_if antispoof for $int_if @@ -1466,20 +1473,19 @@ antispoof for $int_if Handling Non-Routable Addresses Even with a properly configured gateway to handle - network address translation, one may have - to compensate for other people's - misconfigurations. A common misconfiguration is to - let traffic with non-routable - addresses out to the Internet. Since traffic from - non-routeable addresses can play a part in - several DoS attack techniques, - consider explicitly blocking traffic from - non-routeable addresses from entering the - network through the external interface. + network address translation, one may have to compensate for + other people's misconfigurations. A common misconfiguration + is to let traffic with non-routable addresses out to the + Internet. Since traffic from non-routeable addresses can + play a part in several DoS attack + techniques, consider explicitly blocking traffic from + non-routeable addresses from entering the network through + the external interface. In this example, a macro containing non-routable - addresses is defined, then used in blocking rules. Traffic to and from these addresses is - quietly dropped on the gateway's external + addresses is defined, then used in blocking rules. Traffic + to and from these addresses is quietly dropped on the + gateway's external interface. martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \ From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 20:02:33 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABF5AA07; Wed, 19 Feb 2014 20:02:33 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 928981DE1; Wed, 19 Feb 2014 20:02:33 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JK2XeF041059; Wed, 19 Feb 2014 20:02:33 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JK2XcX041058; Wed, 19 Feb 2014 20:02:33 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402192002.s1JK2XcX041058@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 20:02:33 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43995 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:02:33 -0000 Author: dru Date: Wed Feb 19 20:02:33 2014 New Revision: 43995 URL: http://svnweb.freebsd.org/changeset/doc/43995 Log: Initial shuffle to improve the flow of this chapter. Much, much more to come. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 19:21:13 2014 (r43994) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 20:02:33 2014 (r43995) @@ -1499,33 +1499,36 @@ block drop out quick on $ext_if from any - The IPFILTER (IPF) Firewall + IPFILTER (IPF) firewall - IPFILTER + IPFILTER - IPFILTER is a cross-platform, open source firewall which - has been ported to &os;, NetBSD, OpenBSD, &sunos;, HP/UX, and + IPFILTER, also known as + IPF, is a cross-platform, open source firewall which + has been ported to &os;, NetBSD, OpenBSD, and &solaris; operating systems. - IPFILTER is based on a kernel-side firewall and + IPFILTER is a kernel-side firewall and NAT mechanism that can be controlled and - monitored by userland interface programs. The firewall rules - can be set or deleted using &man.ipf.8;. The + monitored by userland programs. Firewall rules + can be set or deleted using ipf, NAT rules can be set or deleted using - &man.ipnat.8;. Run-time statistics for the kernel parts of - IPFILTER can be printed using &man.ipfstat.8;. To log IPFILTER - actions to the system log files, use &man.ipmon.8;. + ipnat, run-time statistics for the kernel parts of + IPFILTER can be printed using + ipfstat, and + ipmon can be used to log IPFILTER + actions to the system log files. - IPF was originally written using a rule processing logic + IPF was originally written using a rule processing logic of the last matching rule wins and only used - stateless rules. Over time, IPF has been enhanced to include a + stateless rules. Over time, IPF has been enhanced to include a quick option and a stateful keep state option which modernized the rules - processing logic. IPF's official documentation covers only the + processing logic. IPF's official documentation covers only the legacy rule coding parameters and rule file processing logic and the modernized functions are only included as additional options. @@ -1541,7 +1544,7 @@ block drop out quick on $ext_if from any and http://coombs.anu.edu.au/~avalon/ip-filter.html. - The IPF FAQ is at The IPF FAQ is at http://www.phildev.net/ipf/index.html. A searchable archive of the IPFilter mailing list is @@ -1549,500 +1552,91 @@ block drop out quick on $ext_if from any xlink:href="http://marc.theaimsgroup.com/?l=ipfilter">http://marc.theaimsgroup.com/?l=ipfilter. - Enabling IPF + Enabling <application>IPF</application> - IPFILTER + IPFILTER enabling - IPF is included in the basic &os; install as a kernel - loadable module. The system will dynamically load - this module at boot time when - ipfilter_enable="YES" is added to - rc.conf. The module enables logging and - default pass all. To change the - default to block all, add a - block all rule at the end of the - ruleset. - - - - Kernel Options - - - kernel options - - IPFILTER - - - - kernel options - - IPFILTER_LOG - - - - kernel options - - IPFILTER_DEFAULT_BLOCK - - - - IPFILTER - - kernel options - - - For users who prefer to statically compile IPF support - into a custom kernel, the following IPF option statements, - listed in /usr/src/sys/conf/NOTES, are - available: - - options IPFILTER -options IPFILTER_LOG -options IPFILTER_DEFAULT_BLOCK - - options IPFILTER enables support for - the IPFILTER firewall. - - options IPFILTER_LOG enables IPF - logging using the ipl packet logging - pseudo—device for every rule that has the - log keyword. - - options IPFILTER_DEFAULT_BLOCK changes - the default behavior so that any packet not matching a - firewall pass rule gets blocked. - - These settings will take effect only after installing a - kernel that has been built with the above options set. - - - - Available <filename>rc.conf</filename> Options - - To activate IPF at boot time, the following statements - need to be added to /etc/rc.conf: - - ipfilter_enable="YES" # Start ipf firewall -ipfilter_rules="/etc/ipf.rules" # loads rules definition text file -ipmon_enable="YES" # Start IP monitor log -ipmon_flags="-Ds" # D = start as daemon - # s = log to syslog - # v = log tcp window, ack, seq - # n = map IP & port to names - - If there is a LAN behind the firewall that uses the - reserved private IP address ranges, the following lines have - to be added to enable NAT - functionality: - - gateway_enable="YES" # Enable as LAN gateway -ipnat_enable="YES" # Start ipnat function -ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat - - - - IPF - - ipf - - To load the ruleset file, use &man.ipf.8;. Custom rules - are normally placed in a file, and the following command can - be used to replace the currently running firewall - rules: - - &prompt.root; ipf -Fa -f /etc/ipf.rules - - flushes all the internal rules - tables. - - specifies the file containing the - rules to load. - - This provides the ability to make changes to a custom - rules file, run the above IPF command, and thus update the - running firewall with a fresh copy of the rules without having - to reboot the system. This method is convenient for testing - new rules as the procedure can be executed as many times as - needed. - - Refer to &man.ipf.8; for details on the other flags - available with this command. - - &man.ipf.8; expects the rules file to be a standard text - file. It will not accept a rules file written as a script - with symbolic substitution. - - There is a way to build IPF rules that utilize the power - of script symbolic substitution. For more information, see - . - - - - IPFSTAT - - ipfstat - - - IPFILTER - - statistics - - - The default behavior of &man.ipfstat.8; is to retrieve - and display the totals of the accumulated statistics gathered - by applying the rules against packets going in and out of the - firewall since it was last started, or since the last time the - accumulators were reset to zero using ipf - -Z. - - Refer to &man.ipfstat.8; for details. - - The default &man.ipfstat.8; output will look something - like this: - - input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 - output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 - input packets logged: blocked 99286 passed 0 - output packets logged: blocked 0 passed 0 - packets logged: input 0 output 0 - log failures: input 3898 output 0 - fragment state(in): kept 0 lost 0 - fragment state(out): kept 0 lost 0 - packet state(in): kept 169364 lost 0 - packet state(out): kept 431395 lost 0 - ICMP replies: 0 TCP RSTs sent: 0 - Result cache hits(in): 1215208 (out): 1098963 - IN Pullups succeeded: 2 failed: 0 - OUT Pullups succeeded: 0 failed: 0 - Fastroute successes: 0 failures: 0 - TCP cksum fails(in): 0 (out): 0 - Packet log flags set: (0) - - When supplied with either for inbound - or for outbound, the command will retrieve - and display the appropriate list of filter rules currently - installed and in use by the kernel. - - ipfstat -in displays the inbound - internal rules table with rule numbers. - - ipfstat -on displays the outbound - internal rules table with rule numbers. - - The output will look something like this: - - @1 pass out on xl0 from any to any -@2 block out on dc0 from any to any -@3 pass out quick on dc0 proto tcp/udp from any to any keep state - - ipfstat -ih displays the inbound - internal rules table, prefixing each rule with a count of how - many times the rule was matched. - - ipfstat -oh displays the outbound - internal rules table, prefixing each rule with a count of how - many times the rule was matched. - - The output will look something like this: - - 2451423 pass out on xl0 from any to any -354727 block out on dc0 from any to any -430918 pass out quick on dc0 proto tcp/udp from any to any keep state - - One of the most important options of - ipfstat is which - displays the state table in a way similar to how &man.top.1; - shows the &os; running process table. When a firewall is - under attack, this function provides the ability to identify - and see the attacking packets. The optional sub-flags give - the ability to select the destination or source IP, port, or - protocol to be monitored in real time. Refer to - &man.ipfstat.8; for details. - - - - IPMON - - ipmon - - - IPFILTER - - logging - - - In order for ipmon to work properly, - the kernel option IPFILTER_LOG must be - turned on. This command has two different modes. Native mode - is the default mode when the command is used without - . - - Daemon mode provides a continuous system log file so that - logging of past events may be reviewed. &os; has a built in - facility to automatically rotate system logs. This is why - outputting the log information to &man.syslogd.8; is better - than the default of outputting to a regular file. The default - rc.conf - ipmon_flags statement uses - : - - ipmon_flags="-Ds" # D = start as daemon - # s = log to syslog - # v = log tcp window, ack, seq - # n = map IP & port to names - - Logging provides the ability to review, after the fact, - information such as which packets were dropped, what addresses - they came from and where they were going. These can all - provide a significant edge in tracking down attackers. - - Even with the logging facility enabled, IPF will not - generate any rule logging by default. The firewall - administrator decides which rules in the ruleset should be - logged and adds the log keyword to those rules. Normally, - only deny rules are logged. - - It is customary to include a default deny - everything rule with the log keyword included as the - last rule in the ruleset. This makes it possible to see all - the packets that did not match any of the rules in the - ruleset. - - - - IPMON Logging - - &man.syslogd.8; uses its own method for segregation of log - data. It uses groupings called facility and - level. By default, IPMON in - mode uses local0 as - the facility name. The following levels can be - used to further segregate the logged data: - - LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. -LOG_NOTICE - packets logged which are also passed -LOG_WARNING - packets logged which are also blocked -LOG_ERR - packets which have been logged and which can be considered short - - - - In order to setup IPFILTER to log all data to - /var/log/ipfilter.log, first - create the empty file: - - &prompt.root; touch /var/log/ipfilter.log - - &man.syslogd.8; is controlled by definition statements in - /etc/syslog.conf. This file offers - considerable flexibility in how - syslog will deal with system - messages issued by software applications like IPF. - - To write all logged messages to the specified file, - add the following statement to - /etc/syslog.conf: - - local0.* /var/log/ipfilter.log - - To activate the changes and instruct &man.syslogd.8; - to read the modified /etc/syslog.conf, - run service syslogd reload. - - Do not forget to change - /etc/newsyslog.conf to rotate the new - log file. - - - - The Format of Logged Messages - - Messages generated by ipmon consist - of data fields separated by white space. Fields common to - all messages are: - - - - The date of packet receipt. - - - - The time of packet receipt. This is in the form - HH:MM:SS.F, for hours, minutes, seconds, and fractions - of a second. - - - - The name of the interface that processed the - packet. - - - - The group and rule number of the rule in the format - @0:17. - - - - These can be viewed with - ipfstat -in. - - - - The action: p for passed, - b for blocked, S for - a short packet, n did not match any - rules, and L for a log rule. The order - of precedence in showing flags is: S, - p, b, - n, L. A capital - P or B means that - the packet has been logged due to a global logging - setting, not a particular rule. - - - - The addresses written as three fields: the source - address and port separated by a comma, the -> symbol, - and the destination address and port. For example: - 209.53.17.22,80 -> - 198.73.220.17,1722. - - - - PR followed by the protocol name - or number: for example, PR tcp. - - - - len followed by the header length - and total length of the packet: for example, - len 20 40. - - - - If the packet is a TCP packet, there - will be an additional field starting with a hyphen followed by - letters corresponding to any flags that were set. Refer to - &man.ipf.5; for a list of letters and their flags. - - If the packet is an ICMP packet, there will be two fields - at the end: the first always being ICMP and - the next being the ICMP message and sub-message type, - separated by a slash. For example: ICMP 3/3 for a port - unreachable message. - - - - Building the Rule Script with Symbolic - Substitution - - Some experienced IPF users create a file containing the - rules and code them in a manner compatible with running them - as a script with symbolic substitution. The major benefit - of doing this is that only the value associated with the - symbolic name needs to be changed, and when the script is - run all the rules containing the symbolic name will have the - value substituted in the rules. Being a script, symbolic - substitution can be used to code frequently used values and - substitute them in multiple rules. This can be seen in the - following example. - - The script syntax used here is compatible with the - &man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells. - - Symbolic substitution fields are prefixed with a - $. - - Symbolic fields do not have the $ prefix. - - The value to populate the symbolic field must be enclosed - between double quotes ("). + is included in the basic &os; install as a kernel + loadable module, meaning that a custom kernel is not needed in + order to enable IPF. - Start the rule file with something like this: + + kernel options - ############# Start of IPF rules script ######################## + IPFILTER + -oif="dc0" # name of the outbound interface -odns="192.0.2.11" # ISP's DNS server IP address -myip="192.0.2.7" # my static IP address from ISP -ks="keep state" -fks="flags S keep state" + + kernel options -# You can choose between building /etc/ipf.rules file -# from this script or running this script "as is". -# -# Uncomment only one line and comment out another. -# -# 1) This can be used for building /etc/ipf.rules: -#cat > /etc/ipf.rules << EOF -# -# 2) This can be used to run script "as is": -/sbin/ipf -Fa -f - << EOF + IPFILTER_LOG + -# Allow out access to my ISP's Domain name server. -pass out quick on $oif proto tcp from any to $odns port = 53 $fks -pass out quick on $oif proto udp from any to $odns port = 53 $ks + + kernel options -# Allow out non-secure standard www function -pass out quick on $oif proto tcp from $myip to any port = 80 $fks + IPFILTER_DEFAULT_BLOCK + -# Allow out secure www function https over TLS SSL -pass out quick on $oif proto tcp from $myip to any port = 443 $fks -EOF -################## End of IPF rules script ######################## + + IPFILTER - The rules are not important in this example as it instead - focuses on how the symbolic substitution fields are populated. - If this example was in a file named - /etc/ipf.rules.script, these rules could - be reloaded by running: + kernel options + - &prompt.root; sh /etc/ipf.rules.script + For users who prefer to statically compile IPF support + into a custom kernel, refer to the instructions in . The following IPF option statements are + available: - There is one problem with using a rules file with embedded - symbolics: IPF does not understand symbolic substitution, and - cannot read such scripts directly. + options IPFILTER +options IPFILTER_LOG +options IPFILTER_DEFAULT_BLOCK - This script can be used in one of two ways: + where options IPFILTER enables support for + IPFILTER. - - - Uncomment the line that begins with - cat, and comment out the line that - begins with /sbin/ipf. Place - ipfilter_enable="YES" into - /etc/rc.conf, and run the script - once after each modification to create or update - /etc/ipf.rules. - + options IPFILTER_LOG enables IPF + logging using the ipl packet logging + pseudo—device for every rule that has the + log keyword. - - Disable IPFILTER in the system startup scripts by - adding ipfilter_enable="NO"to - /etc/rc.conf. + options IPFILTER_DEFAULT_BLOCK changes + the default behavior so that any packet not matching a + firewall pass rule gets blocked. - Then, add a script like the following to - /usr/local/etc/rc.d/. The script - should have an obvious name like - ipf.loadrules.sh, where the - .sh extension is mandatory. + To configure the system to enable IPF + at boot time, add + the following entries to + /etc/rc.conf. These entries will also enable logging and + default pass all. To change the + default to block all, add a + block all rule at the end of the + ruleset. - #!/bin/sh -sh /etc/ipf.rules.script + ipfilter_enable="YES" # Start ipf firewall +ipfilter_rules="/etc/ipf.rules" # loads rules definition text file +ipmon_enable="YES" # Start IP monitor log +ipmon_flags="-Ds" # D = start as daemon + # s = log to syslog + # v = log tcp window, ack, seq + # n = map IP & port to names - The permissions on this script file must be read, - write, execute for owner - root: + If NAT + functionality is needed, also add these lines: - &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh - - + gateway_enable="YES" # Enable as LAN gateway +ipnat_enable="YES" # Start ipnat function +ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat - Now, when the system boots, the IPF rules will be - loaded. + To start IPF now: + + &prompt.root; service ipfilter start + @@ -2063,7 +1657,7 @@ sh /etc/ipf.rules.script - IPFILTER + IPFILTER rule processing order @@ -2076,13 +1670,44 @@ sh /etc/ipf.rules.scriptssh. + + To load the ruleset file, use &man.ipf.8;. Custom rules + are normally placed in a file, and the following command can + be used to replace the currently running firewall + rules: + + &prompt.root; ipf -Fa -f /etc/ipf.rules + + flushes all the internal rules + tables. + + specifies the file containing the + rules to load. + + This provides the ability to make changes to a custom + rules file, run the above IPF command, and thus update the + running firewall with a fresh copy of the rules without having + to reboot the system. This method is convenient for testing + new rules as the procedure can be executed as many times as + needed. + + Refer to &man.ipf.8; for details on the other flags + available with this command. + + &man.ipf.8; expects the rules file to be a standard text + file. It will not accept a rules file written as a script + with symbolic substitution. + + There is a way to build IPF rules that utilize the power + of script symbolic substitution. For more information, see + . Rule Syntax - IPFILTER + IPFILTER rule syntax @@ -2323,7 +1948,7 @@ sh /etc/ipf.rules.scriptStateful Filtering - IPFILTER + IPFILTER stateful filtering @@ -2646,6 +2271,116 @@ block in log first quick on dc0 all ################### End of rules file ##################################### + + Building the Rule Script with Symbolic + Substitution + + Some experienced IPF users create a file containing the + rules and code them in a manner compatible with running them + as a script with symbolic substitution. The major benefit + of doing this is that only the value associated with the + symbolic name needs to be changed, and when the script is + run all the rules containing the symbolic name will have the + value substituted in the rules. Being a script, symbolic + substitution can be used to code frequently used values and + substitute them in multiple rules. This can be seen in the + following example. + + The script syntax used here is compatible with the + &man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells. + + Symbolic substitution fields are prefixed with a + $. + + Symbolic fields do not have the $ prefix. + + The value to populate the symbolic field must be enclosed + between double quotes ("). + + Start the rule file with something like this: + + ############# Start of IPF rules script ######################## + +oif="dc0" # name of the outbound interface +odns="192.0.2.11" # ISP's DNS server IP address +myip="192.0.2.7" # my static IP address from ISP +ks="keep state" +fks="flags S keep state" + +# You can choose between building /etc/ipf.rules file +# from this script or running this script "as is". +# +# Uncomment only one line and comment out another. +# +# 1) This can be used for building /etc/ipf.rules: +#cat > /etc/ipf.rules << EOF +# +# 2) This can be used to run script "as is": +/sbin/ipf -Fa -f - << EOF + +# Allow out access to my ISP's Domain name server. +pass out quick on $oif proto tcp from any to $odns port = 53 $fks +pass out quick on $oif proto udp from any to $odns port = 53 $ks + +# Allow out non-secure standard www function +pass out quick on $oif proto tcp from $myip to any port = 80 $fks + +# Allow out secure www function https over TLS SSL +pass out quick on $oif proto tcp from $myip to any port = 443 $fks +EOF +################## End of IPF rules script ######################## + + The rules are not important in this example as it instead + focuses on how the symbolic substitution fields are populated. + If this example was in a file named + /etc/ipf.rules.script, these rules could + be reloaded by running: + + &prompt.root; sh /etc/ipf.rules.script + + There is one problem with using a rules file with embedded + symbolics: IPF does not understand symbolic substitution, and + cannot read such scripts directly. + + This script can be used in one of two ways: + + + + Uncomment the line that begins with + cat, and comment out the line that + begins with /sbin/ipf. Place + ipfilter_enable="YES" into + /etc/rc.conf, and run the script + once after each modification to create or update + /etc/ipf.rules. + + + + Disable IPFILTER in the system startup scripts by + adding ipfilter_enable="NO"to + /etc/rc.conf. + + Then, add a script like the following to + /usr/local/etc/rc.d/. The script + should have an obvious name like + ipf.loadrules.sh, where the + .sh extension is mandatory. + + #!/bin/sh +sh /etc/ipf.rules.script + + The permissions on this script file must be read, + write, execute for owner + root: + + &prompt.root; chmod 700 /usr/local/etc/rc.d/ipf.loadrules.sh + + + + Now, when the system boots, the IPF rules will be + loaded. + + <acronym>NAT</acronym> @@ -2706,7 +2441,7 @@ block in log first quick on dc0 all NAT - and IPFILTER + and IPFILTER ipnat @@ -2980,6 +2715,260 @@ pass out quick on rl0 proto tcp from any pass in quick on rl0 proto tcp from any to any port = 20 flags S keep state + + + IPFSTAT + + ipfstat + + + IPFILTER + + statistics + + + The default behavior of &man.ipfstat.8; is to retrieve + and display the totals of the accumulated statistics gathered + by applying the rules against packets going in and out of the + firewall since it was last started, or since the last time the + accumulators were reset to zero using ipf + -Z. + + Refer to &man.ipfstat.8; for details. + + The default &man.ipfstat.8; output will look something + like this: + + input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 + output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 + input packets logged: blocked 99286 passed 0 + output packets logged: blocked 0 passed 0 + packets logged: input 0 output 0 + log failures: input 3898 output 0 + fragment state(in): kept 0 lost 0 + fragment state(out): kept 0 lost 0 + packet state(in): kept 169364 lost 0 + packet state(out): kept 431395 lost 0 + ICMP replies: 0 TCP RSTs sent: 0 + Result cache hits(in): 1215208 (out): 1098963 + IN Pullups succeeded: 2 failed: 0 + OUT Pullups succeeded: 0 failed: 0 + Fastroute successes: 0 failures: 0 + TCP cksum fails(in): 0 (out): 0 + Packet log flags set: (0) + + When supplied with either for inbound + or for outbound, the command will retrieve + and display the appropriate list of filter rules currently + installed and in use by the kernel. + + ipfstat -in displays the inbound + internal rules table with rule numbers. + + ipfstat -on displays the outbound + internal rules table with rule numbers. + + The output will look something like this: + + @1 pass out on xl0 from any to any +@2 block out on dc0 from any to any +@3 pass out quick on dc0 proto tcp/udp from any to any keep state + + ipfstat -ih displays the inbound + internal rules table, prefixing each rule with a count of how + many times the rule was matched. + + ipfstat -oh displays the outbound + internal rules table, prefixing each rule with a count of how + many times the rule was matched. + + The output will look something like this: + + 2451423 pass out on xl0 from any to any +354727 block out on dc0 from any to any +430918 pass out quick on dc0 proto tcp/udp from any to any keep state + + One of the most important options of + ipfstat is which + displays the state table in a way similar to how &man.top.1; + shows the &os; running process table. When a firewall is + under attack, this function provides the ability to identify + and see the attacking packets. The optional sub-flags give + the ability to select the destination or source IP, port, or + protocol to be monitored in real time. Refer to + &man.ipfstat.8; for details. + + + + IPMON + + ipmon + + + IPFILTER + + logging + + + In order for ipmon to work properly, + the kernel option IPFILTER_LOG must be + turned on. This command has two different modes. Native mode + is the default mode when the command is used without + . + + Daemon mode provides a continuous system log file so that + logging of past events may be reviewed. &os; has a built in + facility to automatically rotate system logs. This is why + outputting the log information to &man.syslogd.8; is better + than the default of outputting to a regular file. The default + rc.conf + ipmon_flags statement uses + : + + ipmon_flags="-Ds" # D = start as daemon + # s = log to syslog + # v = log tcp window, ack, seq + # n = map IP & port to names + + Logging provides the ability to review, after the fact, + information such as which packets were dropped, what addresses + they came from and where they were going. These can all + provide a significant edge in tracking down attackers. + + Even with the logging facility enabled, IPF will not + generate any rule logging by default. The firewall + administrator decides which rules in the ruleset should be + logged and adds the log keyword to those rules. Normally, + only deny rules are logged. + + It is customary to include a default deny + everything rule with the log keyword included as the + last rule in the ruleset. This makes it possible to see all + the packets that did not match any of the rules in the + ruleset. + + + + IPMON Logging + + &man.syslogd.8; uses its own method for segregation of log + data. It uses groupings called facility and + level. By default, IPMON in + mode uses local0 as + the facility name. The following levels can be + used to further segregate the logged data: + + LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. +LOG_NOTICE - packets logged which are also passed +LOG_WARNING - packets logged which are also blocked +LOG_ERR - packets which have been logged and which can be considered short + + + + In order to setup IPFILTER to log all data to + /var/log/ipfilter.log, first + create the empty file: + + &prompt.root; touch /var/log/ipfilter.log + + &man.syslogd.8; is controlled by definition statements in + /etc/syslog.conf. This file offers + considerable flexibility in how + syslog will deal with system + messages issued by software applications like IPF. + + To write all logged messages to the specified file, + add the following statement to + /etc/syslog.conf: + + local0.* /var/log/ipfilter.log + + To activate the changes and instruct &man.syslogd.8; + to read the modified /etc/syslog.conf, + run service syslogd reload. + + Do not forget to change + /etc/newsyslog.conf to rotate the new + log file. + + + + The Format of Logged Messages + + Messages generated by ipmon consist + of data fields separated by white space. Fields common to + all messages are: *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 20:38:59 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1393282A; Wed, 19 Feb 2014 20:38:59 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F27A611C0; Wed, 19 Feb 2014 20:38:58 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JKcwYW054039; Wed, 19 Feb 2014 20:38:58 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JKcw1J054038; Wed, 19 Feb 2014 20:38:58 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402192038.s1JKcw1J054038@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 20:38:58 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43996 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:38:59 -0000 Author: dru Date: Wed Feb 19 20:38:58 2014 New Revision: 43996 URL: http://svnweb.freebsd.org/changeset/doc/43996 Log: More shuffling to improve flow. To be followed by a bunch of commits which look at the actual tech content. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 20:02:33 2014 (r43995) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 20:38:58 2014 (r43996) @@ -1701,10 +1701,6 @@ ipnat_rules="/etc/ipnat.rules" # rule There is a way to build IPF rules that utilize the power of script symbolic substitution. For more information, see . - - - - Rule Syntax IPFILTER @@ -1735,35 +1731,12 @@ ipnat_rules="/etc/ipnat.rules" # rule PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG STATEFUL - ACTION = block | pass - - IN-OUT = in | out - - OPTIONS = log | quick | on - interface-name - - SELECTION = proto value | - source/destination IP | port = number | flags - flag-value - - PROTO = tcp/udp | udp | tcp | - icmp - - SRC_ADD,DST_ADDR = all | from - object to object - - OBJECT = IP address | - any - - PORT_NUM = port number - - TCP_FLAG = S - - STATEFUL = keep state - - - ACTION + Each keyword and its options are described below. + + + ACTION + The action keyword indicates what to do with the packet if it matches the rest of the filter rule. Each rule must have an action. The following @@ -1776,11 +1749,12 @@ ipnat_rules="/etc/ipnat.rules" # rule pass indicates that the packet should exit the firewall if the selection parameters match the packet. - - - - IN-OUT + + + + IN-OUT + A mandatory requirement is that each filter rule explicitly state which side of the I/O it is to be used on. The next keyword must be either in @@ -1794,11 +1768,12 @@ ipnat_rules="/etc/ipnat.rules" # rule out means this rule is being applied against an outbound packet destined for the interface facing the public Internet. - - - - OPTIONS + + + + OPTIONS + These options must be used in the order shown here. @@ -1833,11 +1808,12 @@ ipnat_rules="/etc/ipnat.rules" # rule state option, this option is recommended so that only the triggering packet is logged and not every packet which matches the stateful connection. - - - - SELECTION + + + + SELECTION + The keywords described in this section are used to describe attributes of the packet to be checked when determining whether or not rules match. There is a @@ -1845,11 +1821,12 @@ ipnat_rules="/etc/ipnat.rules" # rule which has to be selected. The following general-purpose attributes are provided for matching, and must be used in this order: - - - - PROTO + + + + PROTO + proto is the subject keyword which must include one of its corresponding keyword sub-option values. The sub-option indicates a specific protocol to be @@ -1862,11 +1839,12 @@ ipnat_rules="/etc/ipnat.rules" # rule either a TCP or a UDP packet, and has been added as a convenience to save duplication of otherwise identical rules. - - - - SRC_ADDR/DST_ADDR + + + + SRC_ADDR/DST_ADDR + The all keyword is equivalent to from any to any with no other match parameters. @@ -1890,11 +1868,12 @@ ipnat_rules="/etc/ipnat.rules" # rule the calculation. Additional information is available at the utility's web page: http://jodies.de/ipcalc. - - - - PORT + + + + PORT + If a port match is included, for either or both of source and destination, it is only applied to TCP and UDP packets. @@ -1920,11 +1899,12 @@ ipnat_rules="/etc/ipnat.rules" # rule To specify port ranges, place the two port numbers between <> or >< - - - - <acronym>TCP</acronym>_FLAG + + + + TCP_FLAG + Flags are only effective for TCP filtering. The letters represent one of the possible flags that can be matched against the TCP @@ -1933,15 +1913,18 @@ ipnat_rules="/etc/ipnat.rules" # rule The modernized rules processing logic uses the flags S parameter to identify the TCP session start request. - - - - STATEFUL + + + + STATEFUL + keep state indicates that on a pass rule, any packets that match the rules selection parameters should activate the stateful filtering facility. - + + + @@ -2382,7 +2365,7 @@ sh /etc/ipf.rules.script - <acronym>NAT</acronym> + Configuring <acronym>NAT</acronym> NAT @@ -2399,8 +2382,7 @@ sh /etc/ipf.rules.script NAT stands for Network - Address Translation. In &linux;, NAT is called - IP Masquerading. The IPF + Address Translation. The IPF NAT function enables the private LAN behind the firewall to share a single ISP-assigned IP address, even if that address is dynamically assigned. NAT allows each @@ -2408,7 +2390,26 @@ sh /etc/ipf.rules.script - NAT will automatically translate the + In IPF, when a packet arrives at the firewall from the LAN + with a public destination, it passes through the outbound + filter rules. NAT gets its turn at the + packet and applies its rules top down, where the first + matching rule wins. NAT tests each of its + rules against the packet's interface name and source IP + address. When a packet's interface name matches a + NAT rule, the packet's source IP address in + the private LAN is checked to see if it falls within the IP + address range specified to the left of the arrow symbol on the + NAT rule. On a match, the packet has its + source IP address rewritten with the public IP address + obtained by the 0/32 keyword. + NAT posts an entry in its internal + NAT table so when the packet returns from + the public Internet it can be mapped back to its original + private IP address and then passed to the filter rules for + processing. + + NAT will automatically translate the private LAN IP address for each system on the LAN to the single public IP address as packets exit the firewall bound for the public Internet. It also performs the reverse @@ -2433,18 +2434,25 @@ sh /etc/ipf.rules.script - + ipnat - - IP<acronym>NAT</acronym> + To enable IPNAT, add these statements + to /etc/rc.conf. - - NAT + To enable the machine to route traffic between + interfaces: - and IPFILTER - + gateway_enable="YES" - ipnat + To start IPNAT automatically each + time: + + ipnat_enable="YES" + + To specify where to load the IPNAT + rules from: + + ipnat_rules="/etc/ipnat.rules" NAT rules are loaded using ipnat. Typically, the @@ -2479,10 +2487,6 @@ sh /etc/ipf.rules.script &prompt.root; ipnat -v - - - - IP<acronym>NAT</acronym> Rules NAT rules are flexible and can accomplish many different things to fit the needs of @@ -2512,54 +2516,8 @@ sh /etc/ipf.rules.script0/32 which uses the IP address assigned to IF. - - - - How <acronym>NAT</acronym> Works - - In IPF, when a packet arrives at the firewall from the LAN - with a public destination, it passes through the outbound - filter rules. NAT gets its turn at the - packet and applies its rules top down, where the first - matching rule wins. NAT tests each of its - rules against the packet's interface name and source IP - address. When a packet's interface name matches a - NAT rule, the packet's source IP address in - the private LAN is checked to see if it falls within the IP - address range specified to the left of the arrow symbol on the - NAT rule. On a match, the packet has its - source IP address rewritten with the public IP address - obtained by the 0/32 keyword. - NAT posts an entry in its internal - NAT table so when the packet returns from - the public Internet it can be mapped back to its original - private IP address and then passed to the filter rules for - processing. - - - - Enabling IP<acronym>NAT</acronym> - - To enable IPNAT, add these statements - to /etc/rc.conf. - - To enable the machine to route traffic between - interfaces: - - gateway_enable="YES" - To start IPNAT automatically each - time: - - ipnat_enable="YES" - - To specify where to load the IPNAT - rules from: - - ipnat_rules="/etc/ipnat.rules" - - - + <acronym>NAT</acronym> for a Large LAN For networks that have large numbers of systems on the LAN @@ -2567,13 +2525,10 @@ sh /etc/ipf.rules.script - - Assigning Ports to Use - - A normal NAT rule would look like: + The first method is to assign ports to use. A normal NAT rule would look like: map dc0 192.168.1.0/24 -> 0/32 @@ -2592,12 +2547,8 @@ sh /etc/ipf.rules.script map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto - - - Using a Pool of Public Addresses - - In very large LANs there comes a point where there are + The second method is to use a pool of public addresses. In very large LANs there comes a point where there are just too many LAN addresses to fit into a single public address. If a block of public IP addresses is available, these addresses can be used as a pool, and @@ -2619,9 +2570,8 @@ sh /etc/ipf.rules.scriptmap dc0 192.168.1.0/24 -> 204.134.75.0/24 - - + Port Redirection A common practice is to have a web server, email server, @@ -2646,9 +2596,9 @@ sh /etc/ipf.rules.script rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp - + - + FTP and <acronym>NAT</acronym> FTP has two modes: active mode and passive mode. The @@ -2658,9 +2608,6 @@ sh /etc/ipf.rules.scripthttp://www.slacksite.com/other/ftp.html. - - IP<acronym>NAT</acronym> Rules - IPNAT has a built in FTP proxy option which can be specified on the NAT map rule. It can monitor all outbound packet traffic for FTP @@ -2693,10 +2640,6 @@ sh /etc/ipf.rules.scriptNAT. All LAN packets that are not FTP will not match the FTP rules but will undergo NAT if they match the third rule. - - - - IP<acronym>NAT</acronym> FTP Filter Rules Only one filter rule is needed for FTP if the NAT FTP proxy is used. @@ -2846,10 +2789,6 @@ pass in quick on rl0 proto tcp from any last rule in the ruleset. This makes it possible to see all the packets that did not match any of the rules in the ruleset. - - - - IPMON Logging &man.syslogd.8; uses its own method for segregation of log data. It uses groupings called facility and @@ -2890,10 +2829,6 @@ LOG_ERR - packets which have been logged Do not forget to change /etc/newsyslog.conf to rotate the new log file. - - - - The Format of Logged Messages Messages generated by ipmon consist of data fields separated by white space. Fields common to From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 21:22:41 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04592B18; Wed, 19 Feb 2014 21:22:41 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E498815FF; Wed, 19 Feb 2014 21:22:40 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JLMeWt073430; Wed, 19 Feb 2014 21:22:40 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JLMeJ5073429; Wed, 19 Feb 2014 21:22:40 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402192122.s1JLMeJ5073429@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 21:22:40 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43997 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 21:22:41 -0000 Author: dru Date: Wed Feb 19 21:22:40 2014 New Revision: 43997 URL: http://svnweb.freebsd.org/changeset/doc/43997 Log: Initial editorial pass through intro of this chapter. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 20:38:58 2014 (r43996) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 21:22:40 2014 (r43997) @@ -1509,8 +1509,8 @@ block drop out quick on $ext_if from any IPFILTER, also known as IPF, is a cross-platform, open source firewall which - has been ported to &os;, NetBSD, OpenBSD, and - &solaris; operating systems. + has been ported to several operating systems, including &os;, NetBSD, OpenBSD, and + &solaris;. IPFILTER is a kernel-side firewall and NAT mechanism that can be controlled and @@ -1525,32 +1525,25 @@ block drop out quick on $ext_if from any IPF was originally written using a rule processing logic of the last matching rule wins and only used - stateless rules. Over time, IPF has been enhanced to include a - quick option and a stateful - keep state option which modernized the rules - processing logic. IPF's official documentation covers only the - legacy rule coding parameters and rule file processing logic and - the modernized functions are only included as additional - options. - - The instructions contained in this section are based on - using rules that contain quick and - keep state as these provide the basic framework - for configuring an inclusive firewall ruleset. + stateless rules. Since then, IPF has been enhanced to include + the quick and + keep state options. For a detailed explanation of the legacy rules processing method, refer to http://www.munk.me.uk/ipf/ipf-howto.html - and http://coombs.anu.edu.au/~avalon/ip-filter.html. The IPF FAQ is at http://www.phildev.net/ipf/index.html. - - A searchable archive of the IPFilter mailing list is + xlink:href="http://www.phildev.net/ipf/index.html">http://www.phildev.net/ipf/index.html. + A searchable archive of the IPFilter mailing list is available at http://marc.theaimsgroup.com/?l=ipfilter. + xlink:href="http://marc.info/?l=ipfilter">http://marc.info/?l=ipfilter. + This section of the Handbook focuses on + IPF as it pertains to FreeBSD. + It provides examples which uses + rules that contain the quick and + keep state options. Enabling <application>IPF</application> @@ -1560,7 +1553,7 @@ block drop out quick on $ext_if from any enabling - is included in the basic &os; install as a kernel + IPF is included in the basic &os; install as a kernel loadable module, meaning that a custom kernel is not needed in order to enable IPF. @@ -1590,22 +1583,21 @@ block drop out quick on $ext_if from any For users who prefer to statically compile IPF support into a custom kernel, refer to the instructions in . The following IPF option statements are + linkend="kernelconfig"/>. The following kernel options are available: options IPFILTER options IPFILTER_LOG +options IPFILTER_LOOKUP options IPFILTER_DEFAULT_BLOCK where options IPFILTER enables support for - IPFILTER. - - options IPFILTER_LOG enables IPF + IPFILTER, options IPFILTER_LOG enables IPF logging using the ipl packet logging - pseudo—device for every rule that has the - log keyword. - - options IPFILTER_DEFAULT_BLOCK changes + pseudo device for every rule that has the + log keyword, + IPFILTER_LOOKUP enables IP pools in + order to speed up IP lookups, and options IPFILTER_DEFAULT_BLOCK changes the default behavior so that any packet not matching a firewall pass rule gets blocked. @@ -1614,7 +1606,8 @@ options IPFILTER_DEFAULT_BLOCK/etc/rc.conf. These entries will also enable logging and default pass all. To change the - default to block all, add a + default policy to block all without + compiling a custom kernel, remember to add a block all rule at the end of the ruleset. @@ -1633,7 +1626,7 @@ ipmon_flags="-Ds" # D = ipnat_enable="YES" # Start ipnat function ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat - To start IPF now: + Then, to start IPF now: &prompt.root; service ipfilter start From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 21:58:49 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F09C8860; Wed, 19 Feb 2014 21:58:48 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB16818A8; Wed, 19 Feb 2014 21:58:48 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JLwm0i086029; Wed, 19 Feb 2014 21:58:48 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JLwmfL086028; Wed, 19 Feb 2014 21:58:48 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402192158.s1JLwmfL086028@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 21:58:48 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43998 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 21:58:49 -0000 Author: dru Date: Wed Feb 19 21:58:48 2014 New Revision: 43998 URL: http://svnweb.freebsd.org/changeset/doc/43998 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 21:22:40 2014 (r43997) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 21:58:48 2014 (r43998) @@ -1508,26 +1508,28 @@ block drop out quick on $ext_if from any IPFILTER, also known as - IPF, is a cross-platform, open source firewall which - has been ported to several operating systems, including &os;, NetBSD, OpenBSD, and - &solaris;. - - IPFILTER is a kernel-side firewall and - NAT mechanism that can be controlled and - monitored by userland programs. Firewall rules + IPF, is a cross-platform, open source + firewall which has been ported to several operating systems, + including &os;, NetBSD, OpenBSD, and &solaris;. + + IPFILTER is a kernel-side + firewall and NAT mechanism that can be + controlled and monitored by userland programs. Firewall rules can be set or deleted using ipf, NAT rules can be set or deleted using - ipnat, run-time statistics for the kernel parts of - IPFILTER can be printed using - ipfstat, and - ipmon can be used to log IPFILTER - actions to the system log files. - - IPF was originally written using a rule processing logic - of the last matching rule wins and only used - stateless rules. Since then, IPF has been enhanced to include - the quick and - keep state options. + ipnat, run-time statistics for the + kernel parts of IPFILTER can be + printed using ipfstat, and + ipmon can be used to log + IPFILTER actions to the system log + files. + + IPF was originally written using + a rule processing logic of the last matching rule + wins and only used stateless rules. Since then, + IPF has been enhanced to include the + quick and keep state + options. For a detailed explanation of the legacy rules processing method, refer to The IPF FAQ is at http://www.phildev.net/ipf/index.html. - A searchable archive of the IPFilter mailing list is - available at http://marc.info/?l=ipfilter. This section of the Handbook focuses on - IPF as it pertains to FreeBSD. - It provides examples which uses - rules that contain the quick and - keep state options. + IPF as it pertains to FreeBSD. It + provides examples which uses rules that contain the + quick and keep state + options. + Enabling <application>IPF</application> @@ -1553,9 +1556,10 @@ block drop out quick on $ext_if from any enabling - IPF is included in the basic &os; install as a kernel - loadable module, meaning that a custom kernel is not needed in - order to enable IPF. + IPF is included in the basic + &os; install as a kernel loadable module, meaning that a + custom kernel is not needed in order to enable + IPF. kernel options @@ -1581,35 +1585,37 @@ block drop out quick on $ext_if from any kernel options - For users who prefer to statically compile IPF support - into a custom kernel, refer to the instructions in . The following kernel options are - available: + For users who prefer to statically compile + IPF support into a custom kernel, + refer to the instructions in . + The following kernel options are available: options IPFILTER options IPFILTER_LOG options IPFILTER_LOOKUP options IPFILTER_DEFAULT_BLOCK - where options IPFILTER enables support for - IPFILTER, options IPFILTER_LOG enables IPF - logging using the ipl packet logging - pseudo device for every rule that has the - log keyword, - IPFILTER_LOOKUP enables IP pools in - order to speed up IP lookups, and options IPFILTER_DEFAULT_BLOCK changes - the default behavior so that any packet not matching a - firewall pass rule gets blocked. - - To configure the system to enable IPF - at boot time, add - the following entries to - /etc/rc.conf. These entries will also enable logging and - default pass all. To change the - default policy to block all without - compiling a custom kernel, remember to add a - block all rule at the end of the - ruleset. + where options IPFILTER enables support + for IPFILTER, + options IPFILTER_LOG enables + IPF logging using the + ipl packet logging pseudo device for + every rule that has the log keyword, + IPFILTER_LOOKUP enables + IP pools in order to speed up + IP lookups, and options + IPFILTER_DEFAULT_BLOCK changes the default + behavior so that any packet not matching a firewall + pass rule gets blocked. + + To configure the system to enable + IPF at boot time, add the following + entries to /etc/rc.conf. These entries + will also enable logging and default pass + all. To change the default policy to + block all without compiling a custom + kernel, remember to add a block all rule at + the end of the ruleset. ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file @@ -1619,17 +1625,16 @@ ipmon_flags="-Ds" # D = # v = log tcp window, ack, seq # n = map IP & port to names - If NAT - functionality is needed, also add these lines: + If NAT functionality is needed, also + add these lines: gateway_enable="YES" # Enable as LAN gateway ipnat_enable="YES" # Start ipnat function ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat Then, to start IPF now: - + &prompt.root; service ipfilter start - @@ -1640,8 +1645,8 @@ ipnat_rules="/etc/ipnat.rules" # rule The bi-directional exchange of packets between hosts comprises a session conversation. The firewall ruleset processes both the packets arriving from the public Internet, as well as the - packets produced by the system as a response to them. - Each TCP/IP service is predefined by its + packets produced by the system as a response to them. Each + TCP/IP service is predefined by its protocol and listening port. Packets destined for a specific service originate from the source address using an unprivileged port and target the specific service port on the @@ -1693,7 +1698,7 @@ ipnat_rules="/etc/ipnat.rules" # rule There is a way to build IPF rules that utilize the power of script symbolic substitution. For more information, see - . + . IPFILTER @@ -1728,196 +1733,205 @@ ipnat_rules="/etc/ipnat.rules" # rule - ACTION - - The action keyword indicates what to do with the packet - if it matches the rest of the filter rule. Each rule - must have an action. The following - actions are recognized: - - block indicates that the packet - should be dropped if the selection parameters match the - packet. - - pass indicates that the packet should - exit the firewall if the selection parameters match the - packet. - - + ACTION + + The action keyword indicates what to do with the + packet if it matches the rest of the filter rule. Each + rule must have an action. The + following actions are recognized: + + block indicates that the packet + should be dropped if the selection parameters match the + packet. + + pass indicates that the packet + should exit the firewall if the selection parameters + match the packet. + + - - IN-OUT - - A mandatory requirement is that each filter rule - explicitly state which side of the I/O it is to be used - on. The next keyword must be either in - or out and one or the other has to be - included or the rule will not pass syntax checks. - - in means this rule is being applied - against an inbound packet which has just been received on - the interface facing the public Internet. - - out means this rule is being applied - against an outbound packet destined for the interface facing - the public Internet. - - + + IN-OUT + + A mandatory requirement is that each filter rule + explicitly state which side of the I/O it is to be used + on. The next keyword must be either + in or out and one + or the other has to be included or the rule will not + pass syntax checks. + + in means this rule is being + applied against an inbound packet which has just been + received on the interface facing the public + Internet. + + out means this rule is being + applied against an outbound packet destined for the + interface facing the public Internet. + + - - OPTIONS - - - These options must be used in the order shown - here. - - - log indicates that the packet header - will be written to the &man.ipl.4; packet log pseudo-device - if the selection parameters match the packet. - - quick indicates that if the selection - parameters match the packet, this rule will be the last - rule checked, and no further processing of any following - rules will occur for this packet. - - on indicates the interface name to - be incorporated into the selection parameters. Interface - names are as displayed by &man.ifconfig.8;. Using this - option, the rule will only match if the packet is going - through that interface in the specified direction. - - When a packet is logged, the headers of the packet are - written to the &man.ipl.4; packet logging pseudo-device. - Immediately following the log keyword, - the following qualifiers may be used in this order: - - body indicates that the first 128 - bytes of the packet contents will be logged after the - headers. - - first. If the log - keyword is being used in conjunction with a keep - state option, this option is recommended so that - only the triggering packet is logged and not every packet - which matches the stateful connection. - - + + OPTIONS + + + These options must be used in the order shown + here. + + + log indicates that the packet + header will be written to the &man.ipl.4; packet log + pseudo-device if the selection parameters match the + packet. + + quick indicates that if the + selection parameters match the packet, this rule will be + the last rule checked, and no further processing of any + following rules will occur for this packet. + + on indicates the interface name + to be incorporated into the selection parameters. + Interface names are as displayed by &man.ifconfig.8;. + Using this option, the rule will only match if the + packet is going through that interface in the specified + direction. + + When a packet is logged, the headers of the packet + are written to the &man.ipl.4; packet logging + pseudo-device. Immediately following the + log keyword, the following qualifiers + may be used in this order: + + body indicates that the first 128 + bytes of the packet contents will be logged after the + headers. + + first. If the + log keyword is being used in + conjunction with a keep state option, + this option is recommended so that only the triggering + packet is logged and not every packet which matches the + stateful connection. + + - - SELECTION - - The keywords described in this section are used to - describe attributes of the packet to be checked when - determining whether or not rules match. There is a - keyword subject, and it has sub-option keywords, one of - which has to be selected. The following general-purpose - attributes are provided for matching, and must be used in - this order: - - + + SELECTION + + The keywords described in this section are used to + describe attributes of the packet to be checked when + determining whether or not rules match. There is a + keyword subject, and it has sub-option keywords, one of + which has to be selected. The following general-purpose + attributes are provided for matching, and must be used + in this order: + + - - PROTO - - proto is the subject keyword which - must include one of its corresponding keyword sub-option - values. The sub-option indicates a specific protocol to be - matched against. - - tcp/udp | udp | tcp | icmp or any - protocol names found in /etc/protocols - are recognized and may be used. The special protocol - keyword tcp/udp may be used to match - either a TCP or a UDP - packet, and has been added as a convenience to save - duplication of otherwise identical rules. - - + + PROTO + + proto is the subject keyword + which must include one of its corresponding keyword + sub-option values. The sub-option indicates a specific + protocol to be matched against. + + tcp/udp | udp | tcp | icmp or any + protocol names found in + /etc/protocols are recognized and + may be used. The special protocol keyword + tcp/udp may be used to match either a + TCP or a UDP + packet, and has been added as a convenience to save + duplication of otherwise identical rules. + + - - SRC_ADDR/DST_ADDR - - The all keyword is equivalent to - from any to any with no other match - parameters. - - from | to src to dst: the - from and to - keywords are used to match against IP addresses. Rules - must specify both the source and - destination parameters. any is a special - keyword that matches any IP address. Examples include: - from any to any, from 0.0.0.0/0 - to any, from any to - 0.0.0.0/0, from 0.0.0.0 to - any, and from any to - 0.0.0.0. - - There is no way to match ranges of IP addresses which - do not express themselves easily using the dotted numeric - form / mask-length notation. The - net-mgmt/ipcalc port may be used to ease - the calculation. Additional information is available at the - utility's web page: http://jodies.de/ipcalc. - - + + SRC_ADDR/DST_ADDR + + The all keyword is equivalent to + from any to any with no other match + parameters. + + from | to src to dst: the + from and to + keywords are used to match against IP addresses. Rules + must specify both the source and + destination parameters. any is a + special keyword that matches any IP address. Examples + include: from any to any, + from 0.0.0.0/0 to any, from + any to 0.0.0.0/0, from 0.0.0.0 to + any, and from any to + 0.0.0.0. + + There is no way to match ranges of IP addresses + which do not express themselves easily using the dotted + numeric form / mask-length notation. The + net-mgmt/ipcalc port may be used to + ease the calculation. Additional information is + available at the utility's web page: http://jodies.de/ipcalc. + + - - PORT - - If a port match is included, for either or both of - source and destination, it is only applied to - TCP and UDP packets. - When composing port comparisons, either the service name - from /etc/services or an integer port - number may be used. When the port appears as part of the - from object, it matches the source port - number. When it appears as part of the - to object, it matches the destination - port number. An example usage is - from any to any port = 80 - - Single port comparisons may be done in a number of ways, - using a number of different comparison operators. Instead - of the = shown in the example above, - the following operators may be used: !=, - <, >, - <=, >=, - eq, ne, - lt, gt, - le, and ge. - - To specify port ranges, place the two port numbers - between <> or - >< - - + + PORT + + If a port match is included, for either or both of + source and destination, it is only applied to + TCP and UDP + packets. When composing port comparisons, either the + service name from /etc/services or + an integer port number may be used. When the port + appears as part of the from object, + it matches the source port number. When it appears as + part of the to object, it matches the + destination port number. An example usage is + from any to any port = 80 + + Single port comparisons may be done in a number of + ways, using a number of different comparison operators. + Instead of the = shown in the example + above, the following operators may be used: + !=, <, + >, <=, + >=, eq, + ne, lt, + gt, le, and + ge. + + To specify port ranges, place the two port numbers + between <> or + >< + + - - TCP_FLAG - - Flags are only effective for TCP - filtering. The letters represent one of the possible flags - that can be matched against the TCP - packet header. - - The modernized rules processing logic uses the - flags S parameter to identify the TCP - session start request. - - + + TCP_FLAG + + Flags are only effective for TCP + filtering. The letters represent one of the possible + flags that can be matched against the + TCP packet header. + + The modernized rules processing logic uses the + flags S parameter to identify the TCP + session start request. + + - - STATEFUL - - keep state indicates that on a pass - rule, any packets that match the rules selection parameters - should activate the stateful filtering facility. - - - + + STATEFUL + + keep state indicates that on a + pass rule, any packets that match the rules selection + parameters should activate the stateful filtering + facility. + + + @@ -2332,8 +2346,9 @@ EOF - Disable IPFILTER in the system startup scripts by - adding ipfilter_enable="NO"to + Disable IPFILTER in the + system startup scripts by adding + ipfilter_enable="NO"to /etc/rc.conf. Then, add a script like the following to @@ -2383,7 +2398,7 @@ sh /etc/ipf.rules.script - In IPF, when a packet arrives at the firewall from the LAN + In IPF, when a packet arrives at the firewall from the LAN with a public destination, it passes through the outbound filter rules. NAT gets its turn at the packet and applies its rules top down, where the first @@ -2402,7 +2417,7 @@ sh /etc/ipf.rules.script - NAT will automatically translate the + NAT will automatically translate the private LAN IP address for each system on the LAN to the single public IP address as packets exit the firewall bound for the public Internet. It also performs the reverse @@ -2510,18 +2525,19 @@ sh /etc/ipf.rules.script0/32 which uses the IP address assigned to IF. - - <acronym>NAT</acronym> for a Large LAN + + <acronym>NAT</acronym> for a Large LAN - For networks that have large numbers of systems on the LAN - or networks with more than a single LAN, the process of - funneling all those private IP addresses into a single public - IP address becomes a resource problem that may cause problems - with the same port numbers being used many times across many - connections, causing collisions. This section describes two ways to - relieve this resource problem. + For networks that have large numbers of systems on the + LAN or networks with more than a single LAN, the process of + funneling all those private IP addresses into a single + public IP address becomes a resource problem that may cause + problems with the same port numbers being used many times + across many connections, causing collisions. This section + describes two ways to relieve this resource problem. - The first method is to assign ports to use. A normal NAT rule would look like: + The first method is to assign ports to use. A normal + NAT rule would look like: map dc0 192.168.1.0/24 -> 0/32 @@ -2541,7 +2557,8 @@ sh /etc/ipf.rules.scriptmap dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto - The second method is to use a pool of public addresses. In very large LANs there comes a point where there are + The second method is to use a pool of public addresses. + In very large LANs there comes a point where there are just too many LAN addresses to fit into a single public address. If a block of public IP addresses is available, these addresses can be used as a pool, and @@ -2564,19 +2581,20 @@ sh /etc/ipf.rules.scriptmap dc0 192.168.1.0/24 -> 204.134.75.0/24 - - Port Redirection + + Port Redirection - A common practice is to have a web server, email server, - database server, and DNS server each segregated to a different - system on the LAN. In this case, the traffic from these - servers still has to undergo NAT, but there - has to be some way to direct the inbound traffic to the - correct server. For example, a web server operating on LAN - address 10.0.10.25 - and using a single public IP address of - 20.20.20.5, would - use this rule: + A common practice is to have a web server, email server, + database server, and DNS server each segregated to a + different system on the LAN. In this case, the traffic from + these servers still has to undergo NAT, + but there has to be some way to direct the inbound traffic + to the correct server. For example, a web server operating + on LAN address 10.0.10.25 and using a + single public IP address of 20.20.20.5, would use this + rule: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 @@ -2589,17 +2607,17 @@ sh /etc/ipf.rules.script rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp - + - - FTP and <acronym>NAT</acronym> + + FTP and <acronym>NAT</acronym> - FTP has two modes: active mode and passive mode. The - difference is in how the data channel is acquired. Passive - mode is more secure as the data channel is acquired by the - ordinal ftp session requester. For a good explanation of FTP - and the different modes, see http://www.slacksite.com/other/ftp.html. + FTP has two modes: active mode and passive mode. The + difference is in how the data channel is acquired. Passive + mode is more secure as the data channel is acquired by the + ordinal ftp session requester. For a good explanation of + FTP and the different modes, see http://www.slacksite.com/other/ftp.html. IPNAT has a built in FTP proxy option which can be specified on the NAT map @@ -2797,9 +2815,9 @@ LOG_ERR - packets which have been logged - In order to setup IPFILTER to log all data to - /var/log/ipfilter.log, first - create the empty file: + In order to setup IPFILTER to + log all data to /var/log/ipfilter.log, + first create the empty file: &prompt.root; touch /var/log/ipfilter.log @@ -2896,7 +2914,7 @@ LOG_ERR - packets which have been logged the next being the ICMP message and sub-message type, separated by a slash. For example: ICMP 3/3 for a port unreachable message. - + From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 22:05:18 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE29EB27; Wed, 19 Feb 2014 22:05:18 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 997621938; Wed, 19 Feb 2014 22:05:18 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JM5I0K089957; Wed, 19 Feb 2014 22:05:18 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JM5I4s089956; Wed, 19 Feb 2014 22:05:18 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402192205.s1JM5I4s089956@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 22:05:18 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43999 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:05:18 -0000 Author: dru Date: Wed Feb 19 22:05:18 2014 New Revision: 43999 URL: http://svnweb.freebsd.org/changeset/doc/43999 Log: Fix grammo. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 21:58:48 2014 (r43998) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 22:05:18 2014 (r43999) @@ -1543,7 +1543,7 @@ block drop out quick on $ext_if from any This section of the Handbook focuses on IPF as it pertains to FreeBSD. It - provides examples which uses rules that contain the + provides examples of rules that contain the quick and keep state options. From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 22:33:28 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 676BC67F; Wed, 19 Feb 2014 22:33:28 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 394D81BD9; Wed, 19 Feb 2014 22:33:28 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JMXSeo001897; Wed, 19 Feb 2014 22:33:28 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JMXSRO001896; Wed, 19 Feb 2014 22:33:28 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402192233.s1JMXSRO001896@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 22:33:28 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44000 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:33:28 -0000 Author: dru Date: Wed Feb 19 22:33:27 2014 New Revision: 44000 URL: http://svnweb.freebsd.org/changeset/doc/44000 Log: Fix typo. Submitted by: wblock Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 22:05:18 2014 (r43999) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 22:33:27 2014 (r44000) @@ -1185,7 +1185,7 @@ pass inet proto tcp from any to $localne Not to be confused with the spamd daemon which comes bundled with spamassassin, - mail/spamd/ can be configured with + mail/spamd can be configured with PF to provide an outer defense against SPAM. This spamd hooks into the @@ -1213,14 +1213,14 @@ pass inet proto tcp from any to $localne This example demonstrates the basic procedure for setting up spamd with automatically updated blacklists. Refer to the man pages - which are installed with mail/spamd/ for + which are installed with mail/spamd for more information. Configuring <application>spamd</application> - Install the mail/spamd/ package + Install the mail/spamd package or port. In order to use spamd's greylisting features, &man.fdescfs.5; must be mounted at /usr/local/etc/spamd.conf and to add some rc.conf parameters. - The installation of mail/spamd/ + The installation of mail/spamd includes a sample configuration file (/usr/local/etc/spamd.conf.sample) and a man page for spamd.conf. From owner-svn-doc-head@FreeBSD.ORG Wed Feb 19 23:49:19 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8DCA7F3; Wed, 19 Feb 2014 23:49:19 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2EE21236; Wed, 19 Feb 2014 23:49:19 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JNnJZD030166; Wed, 19 Feb 2014 23:49:19 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JNnJS8030165; Wed, 19 Feb 2014 23:49:19 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402192349.s1JNnJS8030165@svn.freebsd.org> From: Glen Barber Date: Wed, 19 Feb 2014 23:49:19 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44001 - head/en_US.ISO8859-1/htdocs/cgi X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 23:49:20 -0000 Author: gjb Date: Wed Feb 19 23:49:19 2014 New Revision: 44001 URL: http://svnweb.freebsd.org/changeset/doc/44001 Log: Attempt to prevent man.cgi from causing a deadlock. Provoked by: peter, zi Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/htdocs/cgi/man.cgi Modified: head/en_US.ISO8859-1/htdocs/cgi/man.cgi ============================================================================== --- head/en_US.ISO8859-1/htdocs/cgi/man.cgi Wed Feb 19 22:33:27 2014 (r44000) +++ head/en_US.ISO8859-1/htdocs/cgi/man.cgi Wed Feb 19 23:49:19 2014 (r44001) @@ -48,6 +48,8 @@ use constant HAS_FREEBSD_CGI_STYLE => ev package main; +alarm(10); + $debug = 2; $www{'title'} = 'FreeBSD Man Pages'; $www{'home'} = 'http://www.FreeBSD.org'; From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 08:53:48 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30507AEA; Thu, 20 Feb 2014 08:53:48 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 026101536; Thu, 20 Feb 2014 08:53:48 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1K8rl18054643; Thu, 20 Feb 2014 08:53:47 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1K8rldM054642; Thu, 20 Feb 2014 08:53:47 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402200853.s1K8rldM054642@svn.freebsd.org> From: Ryusuke SUZUKI Date: Thu, 20 Feb 2014 08:53:47 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44002 - head/ja_JP.eucJP/books/handbook/preface X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 08:53:48 -0000 Author: ryusuke Date: Thu Feb 20 08:53:47 2014 New Revision: 44002 URL: http://svnweb.freebsd.org/changeset/doc/44002 Log: - Merge the following from the English version: r29008 -> r29932 head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml Modified: head/ja_JP.eucJP/books/handbook/preface/preface.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/preface/preface.xml Wed Feb 19 23:49:19 2014 (r44001) +++ head/ja_JP.eucJP/books/handbook/preface/preface.xml Thu Feb 20 08:53:47 2014 (r44002) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r29008 + Original revision: r29932 $FreeBSD$ --> @@ -343,12 +343,27 @@ , ╔╧╔х╔Л║╪╔╦ From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 09:08:15 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11D191A8; Thu, 20 Feb 2014 09:08:15 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F200D1666; Thu, 20 Feb 2014 09:08:14 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1K98E6w059672; Thu, 20 Feb 2014 09:08:14 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1K98EBZ059671; Thu, 20 Feb 2014 09:08:14 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402200908.s1K98EBZ059671@svn.freebsd.org> From: Ryusuke SUZUKI Date: Thu, 20 Feb 2014 09:08:14 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44003 - head/ja_JP.eucJP/share/xml X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:08:15 -0000 Author: ryusuke Date: Thu Feb 20 09:08:14 2014 New Revision: 44003 URL: http://svnweb.freebsd.org/changeset/doc/44003 Log: - Merge the following from the English version: r39141 -> r43972 head/ja_JP.eucJP/share/xml/libcommon.xsl Modified: head/ja_JP.eucJP/share/xml/libcommon.xsl Modified: head/ja_JP.eucJP/share/xml/libcommon.xsl ============================================================================== --- head/ja_JP.eucJP/share/xml/libcommon.xsl Thu Feb 20 08:53:47 2014 (r44002) +++ head/ja_JP.eucJP/share/xml/libcommon.xsl Thu Feb 20 09:08:14 2014 (r44003) @@ -3,7 +3,7 @@ "http://www.FreeBSD.org/XML/share/xml/xslt10-freebsd.dtd"> - + ╓╫╓Л╓╬╓Л╓н╔в╔М╔╦╔╖╔╞╔х╓н╨г©╥╬ПйС╓о║╒╪║╓нЁф╔╕╔╖╔ж╔з║╪╔╦╓Р╓╢мВ╓╞╓ю╓╣╓╓║ё

From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 11:11:02 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B974A2A; Thu, 20 Feb 2014 11:11:02 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 297E412D0; Thu, 20 Feb 2014 11:11:02 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1KBB2r0012118; Thu, 20 Feb 2014 11:11:02 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1KBB2d8012117; Thu, 20 Feb 2014 11:11:02 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402201111.s1KBB2d8012117@svn.freebsd.org> From: Ryusuke SUZUKI Date: Thu, 20 Feb 2014 11:11:02 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44005 - head/ja_JP.eucJP/books/handbook/cutting-edge X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 11:11:02 -0000 Author: ryusuke Date: Thu Feb 20 11:11:01 2014 New Revision: 44005 URL: http://svnweb.freebsd.org/changeset/doc/44005 Log: - Merge the following from the English version: r43745 -> r43758 head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Thu Feb 20 11:02:53 2014 (r44004) +++ head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Thu Feb 20 11:11:01 2014 (r44005) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r43745 + Original revision: r43758 $FreeBSD$ --> ╓©╓х╓╗╓п║╒╟й╡╪╓н╔Ё╔ч╔С╔и╓Р╪б╧т╓╧╓К╓х║╒ ╔о╔С╔╛╔Й║╪╦Л╓н╔и╔╜╔Е╔А╔С╔х╓н╨г©╥ package ╓╛╔╓╔С╔╧╔х║╪╔К╓╣╓Л╓ч╓╧║ё - &prompt.root; pkg_add -r hu-freebsd-doc + &prompt.root; pkg install hu-freebsd-doc ╔и╔╜╔Е╔А╔С╔х╓н package ╓о║╒бп╠Ч╓╧╓К port л╬╓х╓о╟ш╓й╓Й║╒ @@ -2851,9 +2851,9 @@ Script done, … ╓Ё╓нлДбЙ╓Р╡Р╥Х╓╧╓К╓к╓о║╒ ╓ч╓╨╔И╔╓╔ж╔И╔Й╓╛╓и╓н port ╓к╓Х╓ц╓ф╔╓╔С╔╧╔х║╪╔К╓╣╓Л╓©╓╚╓Рд╢╓ы╓ф╡╪╓╣╓╓║ё - &prompt.root; pkg_info -W /usr/local/lib/libtiff.so + &prompt.root; pkg which /usr/local/lib/libtiff.so /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 - &prompt.root; pkg_info -W /usr/local/lib/libXext.so + &prompt.root; pkg which /usr/local/lib/libXext.so /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 ╦╚╓д╓╚╓ц╓© port ╓Р╔╒╔С╔╓╔С╔╧╔х║╪╔К╓╥║╒ From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 11:37:09 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 169BDF76; Thu, 20 Feb 2014 11:37:09 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00F371561; Thu, 20 Feb 2014 11:37:09 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1KBb8e0020772; Thu, 20 Feb 2014 11:37:08 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1KBb853020771; Thu, 20 Feb 2014 11:37:08 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402201137.s1KBb853020771@svn.freebsd.org> From: Ryusuke SUZUKI Date: Thu, 20 Feb 2014 11:37:08 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44006 - head/en_US.ISO8859-1/books/handbook/cutting-edge X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 11:37:09 -0000 Author: ryusuke Date: Thu Feb 20 11:37:08 2014 New Revision: 44006 URL: http://svnweb.freebsd.org/changeset/doc/44006 Log: o Remove white spaces before &prompt.root;. Modified: head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml Thu Feb 20 11:11:01 2014 (r44005) +++ head/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml Thu Feb 20 11:37:08 2014 (r44006) @@ -2315,7 +2315,7 @@ Script done, … &prompt.root; pkg which /usr/local/lib/libtiff.so /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 - &prompt.root; pkg which /usr/local/lib/libXext.so +&prompt.root; pkg which /usr/local/lib/libXext.so /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 Then deinstall, rebuild, and reinstall the port. From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 11:02:53 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1EFB6DD; Thu, 20 Feb 2014 11:02:53 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB6A91205; Thu, 20 Feb 2014 11:02:53 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1KB2rH1007936; Thu, 20 Feb 2014 11:02:53 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1KB2rVF007935; Thu, 20 Feb 2014 11:02:53 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402201102.s1KB2rVF007935@svn.freebsd.org> From: Ryusuke SUZUKI Date: Thu, 20 Feb 2014 11:02:53 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44004 - head/ja_JP.eucJP/books/handbook/cutting-edge X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 20 Feb 2014 12:42:43 +0000 X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 11:02:53 -0000 Author: ryusuke Date: Thu Feb 20 11:02:53 2014 New Revision: 44004 URL: http://svnweb.freebsd.org/changeset/doc/44004 Log: - Merge the following from the English version: r43685 -> r43745 head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Thu Feb 20 09:08:14 2014 (r44003) +++ head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Thu Feb 20 11:02:53 2014 (r44004) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r43685 + Original revision: r43745 $FreeBSD$ --> updating-upgrading - ╔╩╔╜╔Е╔Й╔ф╔ё╔я╔ц╔а╓Ре╛мя╓╧╓К╓Ё╓х╓о║╒╔Ё╔С╔т╔Е║╪╔©╔╫╔у╔х╔╕╔╖╔╒║╒ - фц╓к╔╙╔з╔Л║╪╔ф╔ё╔С╔╟╔╥╔╧╔ф╔Ю╓Р╢имЩ╓╧╓К╬Е╓г╫емв╓йлРЁД╓Р╡л╓©╓╥╓ч╓╧║ё - ╓╥╓╚╓╥╓й╓╛╓И║╒&os; ╓к╓╙╓╓╓ф╓о║╒ - ╓Ё╓н╔в╔М╔╩╔╧╓о╢йц╠╓й╓Б╓н╓г╓о╓╒╓Й╓ч╓╩╓С╓г╓╥╓©║ё - ╔╫║╪╔╧╔Ё║╪╔и╓к╔я╔ц╔а╓РеЖ╓ф║╒╔Ё║╪╔и╓╚╓И╔п╔╓╔й╔Й╓Р╨ф╧╫цш╓╥║╒ - ╔п╔╓╔й╔Й╓Р╨ф╓с╔╓╔С╔╧╔х║╪╔К╓╧╓Ки╛мв╓╛╓╒╓Й╓ч╓╥╓©║ё - - ╦╫╨ъ╓н &os; ╓г╓о freebsd-update - ╓х╦ф╓п╓Л╓К╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓╛ди╡ц╓╣╓Л║╒╬У╤╥╓ойя╓О╓Й╓ч╓╥╓©║ё - ╓Ё╓н╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓о 2 ╓д╓н╣║г╫╓Р╩Щ╓ц╓ф╓╓╓ч╓╧║ё - бХ╟Л╓к║╒&os; ╔ы║╪╔╧╔╥╔╧╔ф╔Ю╓н╔с╔К╔и╓Д╔╓╔С╔╧╔х║╪╔К╓Р╧т╓╕╓Ё╓х╓й╓╞║╒ - ╔п╔╓╔й╔Й╓к╓Х╓ц╓ф╔╩╔╜╔Е╔Й╔ф╔ё╓╙╓Х╓с eratta ╔╒╔ц╔в╔г║╪╔х╓г╓╜╓ч╓╧║ё - бХфС╓к║╒╓Ё╓н╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓о╔ч╔╓╔й║╪╓╙╓Х╓с╔А╔╦╔Ц║╪╔Й╔Й║╪╔╧╓н╔╒╔ц╔в╔╟╔Л║╪╔и╓кбп╠Ч╓╥╓ф╓╓╓ч╓╧║ё - - - ╔п╔╓╔й╔Й╔╒╔ц╔в╔г║╪╔х╓о║╒ + ╔╥╔╧╔ф╔Ю╢имЩ╓к╓╙╓╠╓К╫емв╓йб╕лл╓к║╒ + ╓╧╓ъ╓Д╓╚╓к╔╩╔╜╔Е╔Й╔ф╔ё╔я╔ц╔а╓Ре╛мя╓╥║╒ + ╔╙╔з╔Л║╪╔ф╔ё╔С╔╟╔╥╔╧╔ф╔Ю╓Р©╥╓╥╓╓╔Й╔Й║╪╔╧╓к╔╒╔ц╔в╔╟╔Л║╪╔и╓╧╓К╓Ё╓х╓╛╓╒╓Й╓ч╓╧║ё + &os; ╓к╓о║╒╓Ё╓Л╓И╓н╫ХмЩ╓Р╧т╓╕╓©╓А╓к + freebsd-update + ╓х╦ф╓п╓Л╓К╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓╛мя╟у╓╣╓Л╓ф╓╓╓ч╓╧║ё + + ╓Ё╓н╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓Рмя╓╓╓К╓х║╒ + &os; ╓н╔╩╔╜╔Е╔Й╔ф╔ё╓╙╓Х╓с + eratta ╔╒╔ц╔в╔г║╪╔х╓Р╔п╔╓╔й╔Й╓к╓Х╓ц╓ф╧т╓╕╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё + ╪Йф╟╓г╔я╔ц╔а╓Б╓╥╓╞╓о©╥╓╥╓╓╔╚║╪╔м╔К╓Р╔Ё╔С╔я╔╓╔К╓╥║╒ + ╔╓╔С╔╧╔х║╪╔К╓╧╓Ки╛мв╓о╓╒╓Й╓ч╓╩╓С║ё + ╔п╔╓╔й╔Й╔╒╔ц╔в╔г║╪╔х╓о║╒ ╔╩╔╜╔Е╔Й╔ф╔ё╔а║╪╔Ю╓╛╔╣╔щ║╪╔х╓╥╓ф╓╓╓К╓╧╓ы╓ф╓н╔╒║╪╔╜╔ф╔╞╔а╔Ц╓х╔Й╔Й║╪╔╧╓гмЬмя╓г╓╜╓ч╓╧║ё + http://www.FreeBSD.org/ja/security/ ╓к╓о║╒ + ╔╣╔щ║╪╔х╓╛╧т╓О╓Л╓ф╓╓╓К╔Й╔Й║╪╔╧╓Дйщ╪И╫╙н╩м╫дЙфЭ╓н╟ЛмВ╓╛╓╒╓Й╓ч╓╧║ё + + ╓Ё╓н╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓о║╒╔ч╔╓╔й║╪╔Й╔Й║╪╔╧╓г╓╒╓ц╓©╓Й║╒ + б╬╓н╔Й╔Й║╪╔╧╔ж╔И╔С╔а╓ь╓н╔╒╔ц╔в╔╟╔Л║╪╔и╓к╓Ббп╠Ч╓╥╓ф╓╓╓ч╓╧║ё ©╥╓╥╓╓╔Й╔Й║╪╔╧╓к╔╒╔ц╔в╔г║╪╔х╓╧╓Ка╟╓к║╒ ╔╒╔ц╔в╔г║╪╔х╓╥╓Х╓╕╓х╓╥╓ф╓╓╓К╔Й╔Й║╪╔╧╓н╔╒╔й╔╕╔С╔╧╓клэ╓Рдл╓╥║╒ ╫емв╓й╬ПйС╓╛╓й╓╓╓╚╓и╓╕╓╚╓РЁнг╖╓╥╓ф╓╞╓ю╓╣╓╓║ё ╔Й╔Й║╪╔╧╓н╔╒╔й╔╕╔С╔╧╓о http://www.FreeBSD.org/ja/releases/ ╓гЁнг╖╓г╓╜╓ч╓╧║ё - + ╓Б╓╥ crontab ╓нцФ╓к &man.freebsd-update.8; ╓н╣║г╫╓╛╢ч╓ч╓Л╓ф╓╓╓©╓И║╒ - ╟й╡╪╓н╨Н╤х╓Р╧т╓╕╓ч╓г╓ол╣╦З╓к╓╥╓ф╓╙╓╓╓ф╓╞╓ю╓╣╓╓║ё + ╔╙╔з╔Л║╪╔ф╔ё╔С╔╟╔╥╔╧╔ф╔Ю╓н╔╒╔ц╔в╔╟╔Л║╪╔и╨Н╤х╓Р╫╙╓╗╓К╓ч╓г╓ол╣╦З╓к╓╥╓ф╓╞╓ю╓╣╓╓║ё + + + ╓Ё╓нюА╓г╓о║╒freebsd-update + ╓г╩х╓О╓Л╓КюъдЙ╔у╔║╔╓╔К╓нюБлю║╒ + ╔╩╔╜╔Е╔Й╔ф╔ё╔я╔ц╔а╓не╛╠ЧйЩк║╓н╔г╔Б╔С╔╧╔х╔Л║╪╔╥╔Г╔С║╒ + ╔╙╔з╔Л║╪╔ф╔ё╔С╔╟╔╥╔╧╔ф╔Ю╓Р╔╒╔ц╔в╔╟╔Л║╪╔и╓╧╓К╨щ╓к╧мн╦╓╧╓ы╓╜╓Ё╓х╓к╓д╓╓╓фюБлю╓╥╓ч╓╧║ё юъдЙ╔у╔║╔╓╔К - /etc/freebsd-update.conf + freebsd-update ╓н╔г╔у╔╘╔К╔х╓нюъдЙ╔у╔║╔╓╔К╓о║╒ + ╓╫╓н╓ч╓ч╓г╓Бмя╓╓╓К╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё + /etc/freebsd-update.conf ╓нюъдЙ╓Р╔г╔у╔╘╔К╔х╓╚╓И╓╜╓А╨ы╓╚╓╞д╢ю╟╓╥╓ф║╒ ╔╒╔ц╔в╔г║╪╔х╔в╔М╔╩╔╧╓Рю╘╦Ф╓╧╓К╔Ф║╪╔╤╓Б╓╓╓ч╓╧║ё - ╓Ё╓н╨Н╤х╓они╓╞й╦╫Я╡╫╓╣╓Л╓ф╓╓╓ч╓╧╓╛║╒ - ╟й╡╪╓н╧Юлэ╓к╓д╓╓╓ф╓оюБлю╓╛и╛мв╓г╓╥╓Г╓╕║ё + ╓Ё╓н╔у╔║╔╓╔К╓н╔Ё╔А╔С╔х╓к╓╙╓╓╓фмЬмя╡дг╫╓й╔╙╔в╔╥╔Г╔С╓╛юБлю╓╣╓Л╓ф╓╓╓ч╓╧╓╛║╒ + ╟й╡╪╓н╧Юлэ╓к╓д╓╓╓ф╓ойДб╜╓╛и╛мв╓г╓╥╓Г╓╕║ё # Components of the base system which should be kept updated. -Components src world kernel +Components world kernel ╓Ё╓н╔я╔И╔А║╪╔©╓о║╒&os; ╓н╓и╓ниТй╛╓Р╨г©╥╓к╟щ╩Щ╓╧╓К╓╚╓РюъдЙ╓╥╓ч╓╧║ё - ╔г╔у╔╘╔К╔х╓г╓о╔╫║╪╔╧╔Ё║╪╔и║╒╔ы║╪╔╧╔╥╔╧╔ф╔Юа╢бн║╒╓╫╓╥╓ф╔╚║╪╔м╔К╓Р╔╒╔ц╔в╔г║╪╔х╓╥╓ч╓╧║ё - Components ╓кюъдЙ╓г╓╜╓К╧Юлэ╓о║╒╔╓╔С╔╧╔х║╪╔К╩Ч╓ка╙бР╓г╓╜╓К╓Б╓н╓хф╠╓╦╓г╓╧║ё - ╓©╓х╓╗╓п║╒╓Ё╓Ё╓г world/games ╓Рди╡ц╓╧╓К╓х║╒ - game ╓к╔я╔ц╔а╓╛еЖ╓©╓К╓Х╓╕╓к╓й╓Й╓ч╓╧║ё - src/bin ╓Рди╡ц╓╧╓К╓х║╒ - src/bin - ╔╫║╪╔╧╔Ё║╪╔и╓н╔╒╔ц╔в╔г║╪╔х╓Р╣Ж╡д╓╥╓ч╓╧║ё - - ╓Ё╓ниТй╛╓к╓д╓╓╓ф╓о╔г╔у╔╘╔К╔х╓н╓ч╓ч╓к╓╥╓ф╓╙╓╜║╒ + ╔г╔у╔╘╔К╔х╓г╓о║╒╔ы║╪╔╧╔╥╔╧╔ф╔Юа╢бн║╒╓╫╓╥╓ф╔╚║╪╔м╔К╓Р╔╒╔ц╔в╔г║╪╔х╓╥╓ч╓╧║ё + src/base ╓Д src/sys + ╓н╓Х╓╕╓к║╒╦д║╧╓н╧Юлэ╓Р╩ьдЙ╓╧╓К╓Ё╓х╓Б╓г╓╜╓ч╓╧║ё + ╓Ё╓ниТй╛╓к╓д╓╓╓ф╓о╔г╔у╔╘╔К╔х╓н╓ч╓ч╓к╓╥╓ф╓╙╓╜║╒ ╔╒╔ц╔в╔г║╪╔х╓╧╓К╧Юлэ╓Р╔Ф║╪╔╤╓╛╔Й╔╧╔х╓к╡ц╓╗╓К╥а╓к╓╧╓К╓н╓╛╔ы╔╧╔х╓г╓╥╓Г╓╕║ё ╔╫║╪╔╧╔Ё║╪╔и╓х╔п╔╓╔й╔Й╓╛ф╠╢Э╓╥╓ф╓╓╓й╓╓╓х║╒ - хА╩╢╓й╥К╡л╓Р╓Б╓©╓И╓╧╡дг╫ю╜╓╛╓╒╓Й╓ч╓╧║ё + д╧╓╓г╞╥Н╓н╢ж╓кхА╩╢╓й╥К╡л╓╛╓Б╓©╓И╓╣╓Л╓К╡дг╫ю╜╓╛╓╒╓Й╓ч╓╧║ё # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. -IgnorePaths +IgnorePaths /boot/kernel/linker.hints /bin ╓Д /sbin @@ -234,7 +239,7 @@ UpdateIfUnmodified /etc/ /var/ /root/ /. ╓Ё╓н╔╙╔в╔╥╔Г╔С╓о║╒╩ьдЙ╓╥╓©╔г╔ё╔Л╔╞╔х╔Й╓к╓╒╓КюъдЙ╔у╔║╔╓╔К╓Р║╒ ╔М║╪╔╚╔К╓гйя╧╧╓╣╓Л╓ф╓╓╓й╓╓╬Л╧Г╓н╓ъ╔╒╔ц╔в╔г║╪╔х╓╥╓ч╓╧║ё ╔Ф║╪╔╤╓╛╓Ё╓Л╓И╓н╔у╔║╔╓╔К╓Рйя╧╧╓╥╓ф╓╓╓К╓х║╒ - ╓Ё╓Л╓И╓н╔у╔║╔╓╔К╓н╪╚ф╟╔╒╔ц╔в╔г║╪╔х╓ол╣╦З╓к╓й╓Й╓ч╓╧║ё + ╓Ё╓Л╓И╓н╔у╔║╔╓╔К╓н╪╚ф╟╔╒╔ц╔в╔г║╪╔х╓ок╦╓╡╓И╓Л╓ч╓╧║ё б╬╓к║╒KeepModifiedMetadata ╓х╓╓╓╕йл╓н╔╙╔в╔╥╔Г╔С╓╛б╦╨ъ╓╥╓ч╓╧║ё ╓Ё╓н╔╙╔в╔╥╔Г╔С╓о║╒freebsd-update @@ -242,7 +247,7 @@ UpdateIfUnmodified /etc/ /var/ /root/ /. # When upgrading to a new &os; release, files which match MergeChanges # will have any local changes merged into the version from the new release. -MergeChanges /etc/ /var/named/etc/ +MergeChanges /etc/ /var/named/etc/ /boot/device.hints freebsd-update ╓╛╔ч║╪╔╦╓╧╓ы╓╜╔у╔║╔╓╔К╓╛б╦╨ъ╓╧╓К╔г╔ё╔Л╔╞╔х╔Й╓н╟ЛмВ╓г╓╧║ё From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 14:25:54 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D95A4DCA; Thu, 20 Feb 2014 14:25:54 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C477E1691; Thu, 20 Feb 2014 14:25:54 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1KEPsfq089712; Thu, 20 Feb 2014 14:25:54 GMT (envelope-from blackend@svn.freebsd.org) Received: (from blackend@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1KEPsjc089711; Thu, 20 Feb 2014 14:25:54 GMT (envelope-from blackend@svn.freebsd.org) Message-Id: <201402201425.s1KEPsjc089711@svn.freebsd.org> From: Marc Fonvieille Date: Thu, 20 Feb 2014 14:25:54 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44008 - head/en_US.ISO8859-1/books/handbook/bsdinstall X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:25:54 -0000 Author: blackend Date: Thu Feb 20 14:25:54 2014 New Revision: 44008 URL: http://svnweb.freebsd.org/changeset/doc/44008 Log: Replace some quotes with correct tags. Modified: head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Thu Feb 20 13:51:48 2014 (r44007) +++ head/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml Thu Feb 20 14:25:54 2014 (r44008) @@ -2240,17 +2240,17 @@ Trying to mount root from cd9660:/dev/is Use password-based authentication? - - Typically "yes". + - Typically yes. Use an empty password? - - Typically "no". + Typically no. Use a random password? - Typically - "no". + no. @@ -2266,7 +2266,7 @@ Trying to mount root from cd9660:/dev/is Lock out the account after - creation? - Typically "no". + creation? - Typically no. @@ -2286,8 +2286,8 @@ Trying to mount root from cd9660:/dev/is - If there are more users to add, answer the "Add another - user?" question with yes. Enter + If there are more users to add, answer the Add another + user? question with yes. Enter no to finish adding users and continue the installation. From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 13:51:49 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41844D9E; Thu, 20 Feb 2014 13:51:49 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C23C1335; Thu, 20 Feb 2014 13:51:49 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1KDpnZL076599; Thu, 20 Feb 2014 13:51:49 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1KDpn6U076598; Thu, 20 Feb 2014 13:51:49 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402201351.s1KDpn6U076598@svn.freebsd.org> From: Ryusuke SUZUKI Date: Thu, 20 Feb 2014 13:51:49 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44007 - head/ja_JP.eucJP/books/handbook/cutting-edge X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 20 Feb 2014 14:45:22 +0000 X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:51:49 -0000 Author: ryusuke Date: Thu Feb 20 13:51:48 2014 New Revision: 44007 URL: http://svnweb.freebsd.org/changeset/doc/44007 Log: - Merge the following from the English version: r43758 -> r43769 head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Thu Feb 20 11:37:08 2014 (r44006) +++ head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml Thu Feb 20 13:51:48 2014 (r44007) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r43758 + Original revision: r43769 $FreeBSD$ --> ╔╥╔╧╔ф╔Ю╢имЩ╓к╓╙╓╠╓К╫емв╓йб╕лл╓к║╒ ╓╧╓ъ╓Д╓╚╓к╔╩╔╜╔Е╔Й╔ф╔ё╔я╔ц╔а╓Ре╛мя╓╥║╒ ╔╙╔з╔Л║╪╔ф╔ё╔С╔╟╔╥╔╧╔ф╔Ю╓Р©╥╓╥╓╓╔Й╔Й║╪╔╧╓к╔╒╔ц╔в╔╟╔Л║╪╔и╓╧╓К╓Ё╓х╓╛╓╒╓Й╓ч╓╧║ё - &os; ╓к╓о║╒╓Ё╓Л╓И╓н╫ХмЩ╓Р╧т╓╕╓©╓А╓к - freebsd-update + &os; ╓к╓о║╒╓Ё╓Л╓И╓н╫ХмЩ╓Р╧т╓╕╓©╓А╓к freebsd-update ╓х╦ф╓п╓Л╓К╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓╛мя╟у╓╣╓Л╓ф╓╓╓ч╓╧║ё - ╓Ё╓н╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓Рмя╓╓╓К╓х║╒ - &os; ╓н╔╩╔╜╔Е╔Й╔ф╔ё╓╙╓Х╓с - eratta ╔╒╔ц╔в╔г║╪╔х╓Р╔п╔╓╔й╔Й╓к╓Х╓ц╓ф╧т╓╕╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё - ╪Йф╟╓г╔я╔ц╔а╓Б╓╥╓╞╓о©╥╓╥╓╓╔╚║╪╔м╔К╓Р╔Ё╔С╔я╔╓╔К╓╥║╒ - ╔╓╔С╔╧╔х║╪╔К╓╧╓Ки╛мв╓о╓╒╓Й╓ч╓╩╓С║ё - ╔п╔╓╔й╔Й╔╒╔ц╔в╔г║╪╔х╓о║╒ - ╔╩╔╜╔Е╔Й╔ф╔ё╔а║╪╔Ю╓╛╔╣╔щ║╪╔х╓╥╓ф╓╓╓К╓╧╓ы╓ф╓н╔╒║╪╔╜╔ф╔╞╔а╔Ц╓х╔Й╔Й║╪╔╧╓гмЬмя╓г╓╜╓ч╓╧║ё - http://www.FreeBSD.org/ja/security/ ╓к╓о║╒ - ╔╣╔щ║╪╔х╓╛╧т╓О╓Л╓ф╓╓╓К╔Й╔Й║╪╔╧╓Дйщ╪И╫╙н╩м╫дЙфЭ╓н╟ЛмВ╓╛╓╒╓Й╓ч╓╧║ё - - ╓Ё╓н╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓о║╒╔ч╔╓╔й║╪╔Й╔Й║╪╔╧╓г╓╒╓ц╓©╓Й║╒ - б╬╓н╔Й╔Й║╪╔╧╔ж╔И╔С╔а╓ь╓н╔╒╔ц╔в╔╟╔Л║╪╔и╓к╓Ббп╠Ч╓╥╓ф╓╓╓ч╓╧║ё - ©╥╓╥╓╓╔Й╔Й║╪╔╧╓к╔╒╔ц╔в╔г║╪╔х╓╧╓Ка╟╓к║╒ - ╔╒╔ц╔в╔г║╪╔х╓╥╓Х╓╕╓х╓╥╓ф╓╓╓К╔Й╔Й║╪╔╧╓н╔╒╔й╔╕╔С╔╧╓клэ╓Рдл╓╥║╒ - ╫емв╓й╬ПйС╓╛╓й╓╓╓╚╓и╓╕╓╚╓РЁнг╖╓╥╓ф╓╞╓ю╓╣╓╓║ё - ╔Й╔Й║╪╔╧╓н╔╒╔й╔╕╔С╔╧╓о http://www.FreeBSD.org/ja/releases/ - ╓гЁнг╖╓г╓╜╓ч╓╧║ё + ╓Ё╓н╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓Рмя╓╓╓К╓х║╒&os; ╓н╔╩╔╜╔Е╔Й╔ф╔ё╓╙╓Х╓с + eratta ╔╒╔ц╔в╔г║╪╔х╓Р╔п╔╓╔й╔Й╓к╓Х╓ц╓ф╧т╓╕╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё + ╪Йф╟╓г╔я╔ц╔а╓Б╓╥╓╞╓о©╥╓╥╓╓╔╚║╪╔м╔К╓Р╔Ё╔С╔я╔╓╔К╓╥║╒ + ╔╓╔С╔╧╔х║╪╔К╓╧╓Ки╛мв╓о╓╒╓Й╓ч╓╩╓С║ё + ╔п╔╓╔й╔Й╔╒╔ц╔в╔г║╪╔х╓о║╒ + ╔╩╔╜╔Е╔Й╔ф╔ё╔а║╪╔Ю╓╛╔╣╔щ║╪╔х╓╥╓ф╓╓╓К╓╧╓ы╓ф╓н╔╒║╪╔╜╔ф╔╞╔а╔Ц╓х╔Й╔Й║╪╔╧╓гмЬмя╓г╓╜╓ч╓╧║ё + http://www.FreeBSD.org/ja/security/ ╓к╓о║╒ + ╔╣╔щ║╪╔х╓╛╧т╓О╓Л╓ф╓╓╓К╔Й╔Й║╪╔╧╓Дйщ╪И╫╙н╩м╫дЙфЭ╓н╟ЛмВ╓╛╓╒╓Й╓ч╓╧║ё + + ╓Ё╓н╔Ф║╪╔ф╔ё╔Й╔ф╔ё╓о║╒╔ч╔╓╔й║╪╔Й╔Й║╪╔╧╓г╓╒╓ц╓©╓Й║╒ + б╬╓н╔Й╔Й║╪╔╧╔ж╔И╔С╔а╓ь╓н╔╒╔ц╔в╔╟╔Л║╪╔и╓к╓Ббп╠Ч╓╥╓ф╓╓╓ч╓╧║ё + ©╥╓╥╓╓╔Й╔Й║╪╔╧╓к╔╒╔ц╔в╔г║╪╔х╓╧╓Ка╟╓к║╒ + ╔╒╔ц╔в╔г║╪╔х╓╥╓Х╓╕╓х╓╥╓ф╓╓╓К╔Й╔Й║╪╔╧╓н╔╒╔й╔╕╔С╔╧╓клэ╓Рдл╓╥║╒ + ╫емв╓й╬ПйС╓╛╓й╓╓╓╚╓и╓╕╓╚╓РЁнг╖╓╥╓ф╓╞╓ю╓╣╓╓║ё + ╔Й╔Й║╪╔╧╓н╔╒╔й╔╕╔С╔╧╓о http://www.FreeBSD.org/ja/releases/ + ╓гЁнг╖╓г╓╜╓ч╓╧║ё - ╓Б╓╥ crontab ╓нцФ╓к - &man.freebsd-update.8; ╓н╣║г╫╓╛╢ч╓ч╓Л╓ф╓╓╓©╓И║╒ - ╔╙╔з╔Л║╪╔ф╔ё╔С╔╟╔╥╔╧╔ф╔Ю╓н╔╒╔ц╔в╔╟╔Л║╪╔и╨Н╤х╓Р╫╙╓╗╓К╓ч╓г╓ол╣╦З╓к╓╥╓ф╓╞╓ю╓╣╓╓║ё + ╓Б╓╥ crontab ╓нцФ╓к + &man.freebsd-update.8; ╓н╣║г╫╓╛╢ч╓ч╓Л╓ф╓╓╓©╓И║╒ + ╔╙╔з╔Л║╪╔ф╔ё╔С╔╟╔╥╔╧╔ф╔Ю╓н╔╒╔ц╔в╔╟╔Л║╪╔и╨Н╤х╓Р╫╙╓╗╓К╓ч╓г╓ол╣╦З╓к╓╥╓ф╓╞╓ю╓╣╓╓║ё ╓Ё╓нюА╓г╓о║╒freebsd-update @@ -212,7 +210,8 @@ Components world kernel ╓Ё╓н╔я╔И╔А║╪╔©╓о║╒&os; ╓н╓и╓ниТй╛╓Р╨г©╥╓к╟щ╩Щ╓╧╓К╓╚╓РюъдЙ╓╥╓ч╓╧║ё - ╔г╔у╔╘╔К╔х╓г╓о║╒╔ы║╪╔╧╔╥╔╧╔ф╔Юа╢бн║╒╓╫╓╥╓ф╔╚║╪╔м╔К╓Р╔╒╔ц╔в╔г║╪╔х╓╥╓ч╓╧║ё + ╔г╔у╔╘╔К╔х╓г╓о║╒╔ы║╪╔╧╔╥╔╧╔ф╔Юа╢бн║╒ + ╓╫╓╥╓ф╔╚║╪╔м╔К╓Р╔╒╔ц╔в╔г║╪╔х╓╥╓ч╓╧║ё src/base ╓Д src/sys ╓н╓Х╓╕╓к║╒╦д║╧╓н╧Юлэ╓Р╩ьдЙ╓╧╓К╓Ё╓х╓Б╓г╓╜╓ч╓╧║ё ╓Ё╓ниТй╛╓к╓д╓╓╓ф╓о╔г╔у╔╘╔К╔х╓н╓ч╓ч╓к╓╥╓ф╓╙╓╜║╒ @@ -224,8 +223,7 @@ Components world kernel # statement will be ignored. IgnorePaths /boot/kernel/linker.hints - /bin ╓Д - /sbin + /bin ╓Д /sbin еЫ╓нфцдЙ╓н╔г╔ё╔Л╔╞╔х╔Й╓Р╔╒╔ц╔в╔г║╪╔х╓гйя╧╧╓╥╓й╓╓╓Х╓╕╓к║╒ ╓Ё╓Л╓И╓н╔я╔╧╓Рди╡ц╓╥╓ф╓╞╓ю╓╣╓╓║ё ╓Ё╓н╔╙╔в╔╥╔Г╔С╓о║╒╔М║╪╔╚╔К╓нйя╧╧ею╓Р freebsd-update From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 16:03:02 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE916DEF; Thu, 20 Feb 2014 16:03:02 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA925119D; Thu, 20 Feb 2014 16:03:02 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1KG32KM030535; Thu, 20 Feb 2014 16:03:02 GMT (envelope-from gahr@svn.freebsd.org) Received: (from gahr@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1KG32MI030534; Thu, 20 Feb 2014 16:03:02 GMT (envelope-from gahr@svn.freebsd.org) Message-Id: <201402201603.s1KG32MI030534@svn.freebsd.org> From: Pietro Cerutti Date: Thu, 20 Feb 2014 16:03:02 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44009 - head/en_US.ISO8859-1/htdocs/donations X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 16:03:02 -0000 Author: gahr (ports committer) Date: Thu Feb 20 16:03:02 2014 New Revision: 44009 URL: http://svnweb.freebsd.org/changeset/doc/44009 Log: - Document the donation of a PowerMac G5 from Bob Bishop to danfe@ Modified: head/en_US.ISO8859-1/htdocs/donations/donors.xml Modified: head/en_US.ISO8859-1/htdocs/donations/donors.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/donations/donors.xml Thu Feb 20 14:25:54 2014 (r44008) +++ head/en_US.ISO8859-1/htdocs/donations/donors.xml Thu Feb 20 16:03:02 2014 (r44009) @@ -2964,6 +2964,13 @@ lstewart received + + + Bob Bishop <rb@gid.co.uk> + Power Mac G5 + danfe + received + From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 17:36:59 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DDCD8E4; Thu, 20 Feb 2014 17:36:59 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A0E81A58; Thu, 20 Feb 2014 17:36:59 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1KHaxqp067157; Thu, 20 Feb 2014 17:36:59 GMT (envelope-from truckman@svn.freebsd.org) Received: (from truckman@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1KHawUm067154; Thu, 20 Feb 2014 17:36:58 GMT (envelope-from truckman@svn.freebsd.org) Message-Id: <201402201736.s1KHawUm067154@svn.freebsd.org> From: Don Lewis Date: Thu, 20 Feb 2014 17:36:58 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44010 - head/share/pgpkeys X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:36:59 -0000 Author: truckman (src committer) Date: Thu Feb 20 17:36:58 2014 New Revision: 44010 URL: http://svnweb.freebsd.org/changeset/doc/44010 Log: Add my GnuPG key. Added: head/share/pgpkeys/truckman.key (contents, props changed) Modified: head/share/pgpkeys/pgpkeys-developers.xml head/share/pgpkeys/pgpkeys.ent Modified: head/share/pgpkeys/pgpkeys-developers.xml ============================================================================== --- head/share/pgpkeys/pgpkeys-developers.xml Thu Feb 20 16:03:02 2014 (r44009) +++ head/share/pgpkeys/pgpkeys-developers.xml Thu Feb 20 17:36:58 2014 (r44010) @@ -1086,6 +1086,11 @@ &pgpkey.cel; + + &a.truckman.email; + &pgpkey.truckman; + + &a.glewis.email; &pgpkey.glewis; Modified: head/share/pgpkeys/pgpkeys.ent ============================================================================== --- head/share/pgpkeys/pgpkeys.ent Thu Feb 20 16:03:02 2014 (r44009) +++ head/share/pgpkeys/pgpkeys.ent Thu Feb 20 17:36:58 2014 (r44010) @@ -418,6 +418,7 @@ + Added: head/share/pgpkeys/truckman.key ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/pgpkeys/truckman.key Thu Feb 20 17:36:58 2014 (r44010) @@ -0,0 +1,43 @@ + + + +sub 2048R/76F1C2A82FEBF95E 2014-02-20 [expires: 2017-02-19] + +]]> + From owner-svn-doc-head@FreeBSD.ORG Thu Feb 20 19:08:09 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F8E8801; Thu, 20 Feb 2014 19:08:09 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 013D91397; Thu, 20 Feb 2014 19:08:09 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1KJ88IU005433; Thu, 20 Feb 2014 19:08:08 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1KJ88Af005432; Thu, 20 Feb 2014 19:08:08 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402201908.s1KJ88Af005432@svn.freebsd.org> From: Warren Block Date: Thu, 20 Feb 2014 19:08:08 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44011 - head/en_US.ISO8859-1/books/handbook/advanced-networking X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:08:09 -0000 Author: wblock Date: Thu Feb 20 19:08:08 2014 New Revision: 44011 URL: http://svnweb.freebsd.org/changeset/doc/44011 Log: In the CARP section, switch command tags in screen elements to userinput. Submitted by: Allan Jude Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Thu Feb 20 17:36:58 2014 (r44010) +++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Thu Feb 20 19:08:08 2014 (r44011) @@ -5999,7 +5999,7 @@ ifconfig_em0_alias1="vhid 2 advskew 100 IP address to the master with the command: - &prompt.root; ifconfig em0 vhid 1 state backup + &prompt.root; ifconfig em0 vhid 1 state backup At this point, either networking must be restarted or the @@ -6032,7 +6032,7 @@ ifconfig_em0_alias1="vhid 2 advskew 100 The CARP devices themselves may be created using &man.ifconfig.8;: - &prompt.root; ifconfig carp0 create + &prompt.root; ifconfig carp0 create Set the hostname, configure the management IP address, then configure @@ -6097,7 +6097,7 @@ ifconfig_carp1="vhid 2 advskew 100 pass server to return the IP address to the master with the command: - &prompt.root; ifconfig carp0 down && ifconfig carp0 up + &prompt.root; ifconfig carp0 down && ifconfig carp0 up This should be done on the carp interface which corresponds to the correct host. From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 00:11:58 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 714AFC88; Fri, 21 Feb 2014 00:11:58 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CC26129C; Fri, 21 Feb 2014 00:11:58 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1L0BwgF031915; Fri, 21 Feb 2014 00:11:58 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1L0BwVt031914; Fri, 21 Feb 2014 00:11:58 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402210011.s1L0BwVt031914@svn.freebsd.org> From: Dru Lavigne Date: Fri, 21 Feb 2014 00:11:58 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44012 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 00:11:58 -0000 Author: dru Date: Fri Feb 21 00:11:57 2014 New Revision: 44012 URL: http://svnweb.freebsd.org/changeset/doc/44012 Log: Fix tags. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Thu Feb 20 19:08:08 2014 (r44011) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 00:11:57 2014 (r44012) @@ -1232,7 +1232,7 @@ pass inet proto tcp from any to $localne Then, mount the filesystem: - &prompt.root; mount fdescfs + &prompt.root; mount fdescfs @@ -1392,8 +1392,8 @@ rdr pass on $ext_if inet proto tcp from To complete the greylisting setup: - &prompt.root; service restart obspamd -&prompt.root; service start spamlogd + &prompt.root; service restart obspamd +&prompt.root; service start spamlogd @@ -1634,7 +1634,7 @@ ipnat_rules="/etc/ipnat.rules" # rule Then, to start IPF now: - &prompt.root; service ipfilter start + &prompt.root; service ipfilter start From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 13:26:42 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4E92695; Fri, 21 Feb 2014 13:26:42 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE8831C66; Fri, 21 Feb 2014 13:26:42 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LDQg8p057248; Fri, 21 Feb 2014 13:26:42 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LDQg0L057243; Fri, 21 Feb 2014 13:26:42 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402211326.s1LDQg0L057243@svn.freebsd.org> From: Ryusuke SUZUKI Date: Fri, 21 Feb 2014 13:26:42 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44013 - in head/ja_JP.eucJP: books/handbook/mirrors books/handbook/ports htdocs/ports X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 13:26:42 -0000 Author: ryusuke Date: Fri Feb 21 13:26:41 2014 New Revision: 44013 URL: http://svnweb.freebsd.org/changeset/doc/44013 Log: - Merge the following from the English version: r43087 -> r43771 head/ja_JP.eucJP/books/handbook/mirrors/chapter.xml r43757 -> r43770 head/ja_JP.eucJP/books/handbook/ports/chapter.xml r42293 -> r43770 head/ja_JP.eucJP/htdocs/ports/installing.xml Modified: head/ja_JP.eucJP/books/handbook/mirrors/chapter.xml head/ja_JP.eucJP/books/handbook/ports/chapter.xml head/ja_JP.eucJP/htdocs/ports/installing.xml Modified: head/ja_JP.eucJP/books/handbook/mirrors/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/mirrors/chapter.xml Fri Feb 21 00:11:57 2014 (r44012) +++ head/ja_JP.eucJP/books/handbook/mirrors/chapter.xml Fri Feb 21 13:26:41 2014 (r44013) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r43087 + Original revision: r43771 $FreeBSD$ --> @@ -517,7 +517,7 @@ ╟Лхле╙╓к╓о Subversion ╓оЁ╚х╞╪т╦Ч╓╠╓н╔д║╪╔К╓г╓╧║ё бГиТй╛╓н╔Ф║╪╔╤╓о║╒&os; ╓н╔ы║╪╔╧╔╥╔╧╔ф╔Ю╓н╔╒╔ц╔в╔г║╪╔х╓к FreeBSD Update║╒ - Ports Collection ╓н╔╒╔ц╔в╔г║╪╔х╓к╓о Portsnap + Ports Collection ╓н╔╒╔ц╔в╔г║╪╔х╓к╓о Portsnap ╓Р╩х╓╕╓ы╓╜╓г╓╥╓Г╓╕║ё Modified: head/ja_JP.eucJP/books/handbook/ports/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/ports/chapter.xml Fri Feb 21 00:11:57 2014 (r44012) +++ head/ja_JP.eucJP/books/handbook/ports/chapter.xml Fri Feb 21 13:26:41 2014 (r44013) @@ -1001,10 +1001,7 @@ Deinstalling ca_root_nss-3.13.5... done< Portsnap ╓о Ports Collection ╓Р╪Хфю╓╧╓К╓©╓А╓нб╝╓╞╓ф╩х╓╓╓Д╓╧╓╞║╒ - б©╓╞╓н╔Ф║╪╔╤╓к©Д╬╘╓╣╓Л╓К╔д║╪╔К╓г╓╧║ё - Portsnap ╓н╣║г╫╓к╓д╓╓╓ф╓н╬э╨ы╓о - Portsnap ╓Р╩х╓╕ - ╓нюА╓Р╩╡╬х╓╥╓ф╓╞╓ю╓╣╓╓║ё + б©╓╞╓н╔Ф║╪╔╤╓к©Д╬╘╓╣╓Л╓К╔д║╪╔К╓г╓╧║ё ╟╣╫л╓╣╓Л╓© Ports Collection ╓н╔╧╔й╔ц╔в╔╥╔Г╔ц╔х╓Р Modified: head/ja_JP.eucJP/htdocs/ports/installing.xml ============================================================================== --- head/ja_JP.eucJP/htdocs/ports/installing.xml Fri Feb 21 00:11:57 2014 (r44012) +++ head/ja_JP.eucJP/htdocs/ports/installing.xml Fri Feb 21 13:26:41 2014 (r44013) @@ -1,6 +1,6 @@ %ports.ent; @@ -8,7 +8,7 @@ %statistics.ent; ]> - + &title; @@ -32,7 +32,7 @@

╔╙╔з╔Л║╪╔ф╔ё╔С╔╟╔╥╔╧╔ф╔Ю╓н╔╓╔С╔╧╔х║╪╔К╩Ч╓к Ports Colllection ╓Р╔╓╔С╔╧╔х║╪╔К╓╥╓й╓╚╓ц╓©╓н╓г╓╒╓Л╓п║╒ - portsnap + portsnap ╓ч╓©╓о Subversion ╓Р╩х╓ц╓ф╔╓╔С╔╧╔х║╪╔К╓╥╓ф╓╞╓ю╓╣╓╓║ё From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 15:27:03 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6F4ED60; Fri, 21 Feb 2014 15:27:03 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A17541A51; Fri, 21 Feb 2014 15:27:03 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LFR3Kj019304; Fri, 21 Feb 2014 15:27:03 GMT (envelope-from mat@svn.freebsd.org) Received: (from mat@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LFR3PK019303; Fri, 21 Feb 2014 15:27:03 GMT (envelope-from mat@svn.freebsd.org) Message-Id: <201402211527.s1LFR3PK019303@svn.freebsd.org> From: Mathieu Arnold Date: Fri, 21 Feb 2014 15:27:03 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44015 - head/en_US.ISO8859-1/books/porters-handbook/plist X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:27:03 -0000 Author: mat (ports committer) Date: Fri Feb 21 15:27:03 2014 New Revision: 44015 URL: http://svnweb.freebsd.org/changeset/doc/44015 Log: Remove some obsolete bits. Sponsored by: Absolight Modified: head/en_US.ISO8859-1/books/porters-handbook/plist/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/plist/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/plist/chapter.xml Fri Feb 21 15:23:53 2014 (r44014) +++ head/en_US.ISO8859-1/books/porters-handbook/plist/chapter.xml Fri Feb 21 15:27:03 2014 (r44015) @@ -173,17 +173,8 @@ lib/X11/oneko/sounds/cat.au sample file to the real configuration file name, if it does not already exist. On deinstall delete the configuration file, but only if it is identical to the .sample - file. You need to handle this both in the port - Makefile, and in the - pkg-plist (for installation from the - package). - - Example of the Makefile part: - - post-install: - @if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \ - ${CP} -p ${PREFIX}/etc/orbit.conf.sample ${STAGEDIR}${PREFIX}/etc/orbit.conf ; \ - fi + file. You need to handle this in the + pkg-plist. For each configuration file, create the following three lines in pkg-plist: From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 17:19:20 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA4A6513; Fri, 21 Feb 2014 17:19:20 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9930A16B7; Fri, 21 Feb 2014 17:19:20 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LHJKF3065984; Fri, 21 Feb 2014 17:19:20 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LHJKmc065983; Fri, 21 Feb 2014 17:19:20 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402211719.s1LHJKmc065983@svn.freebsd.org> From: Warren Block Date: Fri, 21 Feb 2014 17:19:20 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44016 - head/en_US.ISO8859-1/books/handbook/ports X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:19:20 -0000 Author: wblock Date: Fri Feb 21 17:19:20 2014 New Revision: 44016 URL: http://svnweb.freebsd.org/changeset/doc/44016 Log: Introduction to using Poudriere supplied by Christopher J. Ruwe . Edited version of supplied file. Reviewed by: bapt Modified: head/en_US.ISO8859-1/books/handbook/ports/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/ports/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/ports/chapter.xml Fri Feb 21 15:27:03 2014 (r44015) +++ head/en_US.ISO8859-1/books/handbook/ports/chapter.xml Fri Feb 21 17:19:20 2014 (r44016) @@ -1541,6 +1541,163 @@ The deinstallation will free 229 kB + + Building Packages with + <application>Poudriere</application> + + Poudriere uses &os; jails to set + up isolated compilation environments. Inside, ports are + compiled and packaged using standard &man.make.1; targets and + &man.pkg.8;. + + + Installation and Configuration + + Install Poudriere from the + Ports Collection + (ports-mgmt/poudriere). + + Configuration files are + /usr/local/etc/poudriere.conf and + /usr/local/etc/poudriere.d/. Example + settings are shown in + /usr/local/etc/poudriere.conf.sample. + + Using ZFS is not required, + but beneficial. When ZFS is used, the + ZPOOL for + Poudriere's datasets must be + specified. Set FREEBSD_HOST to a nearby + mirror. Defaults for the other values are adequate. Defining + CCACHE_DIR enables the use of + devel/ccache to cache + compilation. This will reduce build times for + frequently-compiled code. It is convenient to put + Poudriere datasets in an isolated + tree mounted at + /poudriere. That is + not a functional modification, but a matter of taste. + + The number of processor cores detected is used to define + how many builds should run in parallel. Supply enough virtual + memory, either with RAM or swap space. If + virtual memory runs out, compiling jails will stop and be torn + down, resulting in weird error messages. + + + + Initialize Jails and Port Trees + + Initially, it is sufficient to install a &os; tree and a + ports tree. Creating a simple setup only requires supplying a + name with and a version with + . On systems running &os;/&arch.amd64;, + the architecture can be set with to + either i386 or amd64. + The default is the architecture shown by + uname. + + &prompt.root; poudriere jail -c -j 10amd64 -v 10.0-RELEASE +====>> Creating 10amd64 fs... done +====>> Fetching base.txz for FreeBSD 10.0-RELEASE amd64 +/poudriere/jails/10amd64/fromftp/base.txz 100% of 59 MB 1470 kBps 00m42s +====>> Extracting base.txz... done +====>> Fetching src.txz for FreeBSD 10.0-RELEASE amd64 +/poudriere/jails/10amd64/fromftp/src.txz 100% of 107 MB 1476 kBps 01m14s +====>> Extracting src.txz... done +====>> Fetching games.txz for FreeBSD 10.0-RELEASE amd64 +/poudriere/jails/10amd64/fromftp/games.txz 100% of 865 kB 734 kBps 00m01s +====>> Extracting games.txz... done +====>> Fetching lib32.txz for FreeBSD 10.0-RELEASE amd64 +/poudriere/jails/10amd64/fromftp/lib32.txz 100% of 14 MB 1316 kBps 00m12s +====>> Extracting lib32.txz... done +====>> Cleaning up... done +====>> Jail 10amd64 10.0-RELEASE amd64 is ready to be used + + &prompt.root; poudriere ports -c -p local +====>> Creating local fs... done +====>> Extracting portstree "local"... +Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. +Fetching public key from ec2-eu-west-1.portsnap.freebsd.org... done. +Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. +Fetching snapshot metadata... done. +Fetching snapshot generated at Tue Feb 11 01:07:15 CET 2014: +94a3431f0ce567f6452ffde4fd3d7d3c6e1da143efec76100% of 69 MB 1246 kBps 00m57s +Extracting snapshot... done. +Verifying snapshot integrity... done. +Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. +Fetching snapshot metadata... done. +Updating from Tue Feb 11 01:07:15 CET 2014 to Tue Feb 11 16:05:20 CET 2014. +Fetching 4 metadata patches... done. +Applying metadata patches... done. +Fetching 0 metadata files... done. +Fetching 48 patches. +(48/48) 100.00% done. +done. +Applying patches... +done. +Fetching 1 new ports or files... done. +/poudriere/ports/tester/CHANGES +/poudriere/ports/tester/COPYRIGHT + +[...] + +Building new INDEX files... done. + + On a single computer, Poudriere + can build ports with multiple configurations, in multiple + jails, and from different port trees. Custom configurations + for these combinations are called sets. + See the CUSTOMIZATION section of &man.poudriere.8; for + detail. + + The basic configuration shown here puts a single jail-, + port-, and set-specific make.conf in + /usr/local/etc/poudriere.d. + The filename in this example is created by combining the jail + name, port name, and set name: + 10amd64-local-workstation-make.conf. + The system make.conf and this new file + are combined at build time to create the + make.conf used by the build jail. + + Packages to be built are entered in + 10amd64-local-workstation-pkglist: + + editors/emacs +devel/git +ports-mgmt/pkg +... + + Options and dependencies for the specified ports are + configured: + + &prompt.root; poudriere options -j 10amd64 -p local -z workstation -f workstation-pkglist + + Finally, packages are built and a &man.pkg.8; repository + is created: + + &prompt.root; poudriere bulk -j 10amd64 -p local -z workstation -f workstation-pkglist + + Ctrlt + displays the current state. + Poudriere also builds files in + /poudriere/logs/bulk/jailname + that can be used with a web server to display build + information. + + Packages are now available for installation from the + Poudriere repository. + + For more information on + Poudriere, see &man.poudriere.8; + and the main web site, . + + + Post-Installation Considerations From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 17:50:52 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F88072D; Fri, 21 Feb 2014 17:50:52 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B0D719CC; Fri, 21 Feb 2014 17:50:52 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LHoqox080254; Fri, 21 Feb 2014 17:50:52 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LHoq99080229; Fri, 21 Feb 2014 17:50:52 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402211750.s1LHoq99080229@svn.freebsd.org> From: Dru Lavigne Date: Fri, 21 Feb 2014 17:50:52 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44017 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:50:52 -0000 Author: dru Date: Fri Feb 21 17:50:51 2014 New Revision: 44017 URL: http://svnweb.freebsd.org/changeset/doc/44017 Log: Prep work for edits on IPF rulesets. Move paragraphs that apply to all firewalls to Firewall Concepts section. That section will be reviewed last, to make sure it includes the concepts covered in all the firewalls. Move how to load ruleset to previous section to match layout of PF firewall section. Next up, review ruleset syntax. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 17:19:20 2014 (r44016) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 17:50:51 2014 (r44017) @@ -156,6 +156,20 @@ rulesets + A ruleset contains a group of rules which pass or + block packets based on the values contained in the packet. + The bi-directional exchange of packets between hosts comprises + a session conversation. The firewall ruleset processes both + the packets arriving from the public Internet, as well as the + packets produced by the system as a response to them. Each + TCP/IP service is predefined by its + protocol and listening port. Packets destined for a specific + service originate from the source address using an + unprivileged port and target the specific service port on the + destination address. All the above parameters can be used as + selection criteria to create rules which will pass or block + services. + A firewall ruleset can be either exclusive or inclusive. An exclusive firewall allows all traffic through except for the @@ -187,6 +201,15 @@ to Denial of Service (DoS) attacks if a lot of new connections are opened very fast. Most firewalls use a combination of stateful and non-stateful behavior. + + + When working with the firewall rules, be very + careful. Some configurations can + lock the administrator out of the server. To be + on the safe side, consider performing the initial firewall + configuration from the local console rather than doing it + remotely over ssh. + @@ -1635,55 +1658,20 @@ ipnat_rules="/etc/ipnat.rules" # rule Then, to start IPF now: &prompt.root; service ipfilter start - - - IPF Rulesets - - A ruleset contains a group of IPF rules which pass or - block packets based on the values contained in the packet. - The bi-directional exchange of packets between hosts comprises - a session conversation. The firewall ruleset processes both - the packets arriving from the public Internet, as well as the - packets produced by the system as a response to them. Each - TCP/IP service is predefined by its - protocol and listening port. Packets destined for a specific - service originate from the source address using an - unprivileged port and target the specific service port on the - destination address. All the above parameters can be used as - selection criteria to create rules which will pass or block - services. - - - IPFILTER - - rule processing order - - - - When working with the firewall rules, be very - careful. Some configurations can - lock the administrator out of the server. To be - on the safe side, consider performing the initial firewall - configuration from the local console rather than doing it - remotely over ssh. - - - To load the ruleset file, use &man.ipf.8;. Custom rules - are normally placed in a file, and the following command can + To load the ruleset file, specify the name of the file using ipf. + The following command can be used to replace the currently running firewall rules: &prompt.root; ipf -Fa -f /etc/ipf.rules - flushes all the internal rules - tables. - - specifies the file containing the + where flushes all the internal rules + tables and specifies the file containing the rules to load. This provides the ability to make changes to a custom - rules file, run the above IPF command, and thus update the + ruleset and update the running firewall with a fresh copy of the rules without having to reboot the system. This method is convenient for testing new rules as the procedure can be executed as many times as @@ -1691,14 +1679,10 @@ ipnat_rules="/etc/ipnat.rules" # rule Refer to &man.ipf.8; for details on the other flags available with this command. + - &man.ipf.8; expects the rules file to be a standard text - file. It will not accept a rules file written as a script - with symbolic substitution. - - There is a way to build IPF rules that utilize the power - of script symbolic substitution. For more information, see - . + + IPF Rulesets IPFILTER @@ -1706,21 +1690,19 @@ ipnat_rules="/etc/ipnat.rules" # rule rule syntax - The rule syntax presented here has been simplified to - only address the modern stateful rule context and first - matching rule wins logic. For the complete legacy - rule syntax, refer to &man.ipf.8;. - - A # character is used to mark the - start of a comment and may appear at the end of a rule line - or on its own line. Blank lines are ignored. - - Rules contain keywords which must be written in a specific - order from left to right on the line. Keywords are identified - in bold type. Some keywords have sub-options which may be - keywords themselves and also include more sub-options. Each - of the headings in the below syntax has a bold section header - which expands on the content. + This section describes the IPF rule syntax + used to create stateful rules where the first + matching rule wins. Refer to &man.ipf.8; for more details, including the legacy + rule syntax. + + When creating rules, a # character is used to mark the + start of a comment and may appear at the end of a rule, to explain its function, + or on its own line. Any blank lines are ignored. + + The keywords which are used in rules must be written in a specific + order, from left to right. Some keywords have sub-options which may be + keywords themselves and also include more sub-options. The + keyword order is as follows: @@ -1729,7 +1711,7 @@ ipnat_rules="/etc/ipnat.rules" # rule PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG STATEFUL - Each keyword and its options are described below. + This section describes each keyword and its options. From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 18:39:20 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED11515C; Fri, 21 Feb 2014 18:39:20 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA6E41E11; Fri, 21 Feb 2014 18:39:20 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LIdK7d098462; Fri, 21 Feb 2014 18:39:20 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LIdK7Z098461; Fri, 21 Feb 2014 18:39:20 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402211839.s1LIdK7Z098461@svn.freebsd.org> From: Dru Lavigne Date: Fri, 21 Feb 2014 18:39:20 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44018 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:39:21 -0000 Author: dru Date: Fri Feb 21 18:39:20 2014 New Revision: 44018 URL: http://svnweb.freebsd.org/changeset/doc/44018 Log: This section is reeeeeally out of date. Modernize the first few keywords. Much more to come. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 17:50:51 2014 (r44017) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 18:39:20 2014 (r44018) @@ -1659,7 +1659,7 @@ ipnat_rules="/etc/ipnat.rules" # rule &prompt.root; service ipfilter start - To load the ruleset file, specify the name of the file using ipf. + To load the firewall rules, specify the name of the ruleset file using ipf. The following command can be used to replace the currently running firewall rules: @@ -1691,9 +1691,13 @@ ipnat_rules="/etc/ipnat.rules" # rule This section describes the IPF rule syntax - used to create stateful rules where the first - matching rule wins. Refer to &man.ipf.8; for more details, including the legacy - rule syntax. + used to create stateful rules. When creating rules, keep in + mind that the default way in which filter rules are applied + is for the last matching rule to be + used. Even if the first rule to match a packet is a + pass, if there is a later matching rule + that is a block, the packet will be dropped. + Refer to &man.ipf.5; for more details about rule syntax. When creating rules, a # character is used to mark the start of a comment and may appear at the end of a rule, to explain its function, @@ -1718,38 +1722,51 @@ ipnat_rules="/etc/ipnat.rules" # rule ACTION The action keyword indicates what to do with the - packet if it matches the rest of the filter rule. Each + packet if it matches that rule. Every rule must have an action. The following actions are recognized: - block indicates that the packet - should be dropped if the selection parameters match the - packet. + block: drops the packet. + + pass: allows the packet. + + log: generates a log record. + + count: counts the number of + packets and bytes which can provide an indication of + how often a rule is used. + + auth: queues the packet for + further processing by another program. - pass indicates that the packet - should exit the firewall if the selection parameters - match the packet. + call: provides access to + functions built into IPF that + allow more complex actions. + + decapsulate: removes any headers + in order to process the contents of the packet. IN-OUT - A mandatory requirement is that each filter rule - explicitly state which side of the I/O it is to be used - on. The next keyword must be either - in or out and one - or the other has to be included or the rule will not - pass syntax checks. - - in means this rule is being - applied against an inbound packet which has just been - received on the interface facing the public - Internet. - - out means this rule is being - applied against an outbound packet destined for the - interface facing the public Internet. + Next, each rule must + explicitly state the direction of traffic using one of + these keywords: + + in: the rule is + applied against an inbound packet. + + out: the rule is + applied against an outbound packet. + + all: the rule applies to either + direction. + + If the system has multiple interfaces, the interface + can be specified along with the direction. An example would + be in on fxp0. From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 20:28:02 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C9BFC65; Fri, 21 Feb 2014 20:28:02 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 47A121908; Fri, 21 Feb 2014 20:28:02 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LKS2n8043688; Fri, 21 Feb 2014 20:28:02 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LKS2mO043687; Fri, 21 Feb 2014 20:28:02 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402212028.s1LKS2mO043687@svn.freebsd.org> From: Dru Lavigne Date: Fri, 21 Feb 2014 20:28:02 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44019 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:28:02 -0000 Author: dru Date: Fri Feb 21 20:28:01 2014 New Revision: 44019 URL: http://svnweb.freebsd.org/changeset/doc/44019 Log: Modernize the next bit of syntax. More to come. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 18:39:20 2014 (r44018) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 20:28:01 2014 (r44019) @@ -1622,7 +1622,7 @@ options IPFILTER_DEFAULT_BLOCKIPFILTER, options IPFILTER_LOG enables IPF logging using the - ipl packet logging pseudo device for + ipl packet logging pseudo-device for every rule that has the log keyword, IPFILTER_LOOKUP enables IP pools in order to speed up @@ -1711,8 +1711,8 @@ ipnat_rules="/etc/ipnat.rules" # rule - ACTION IN-OUT OPTIONS SELECTION STATEFUL - PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG + ACTION DIRECTION OPTIONS proto PROTO_TYPE + from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT OBJECT PORT_NUM TCP_FLAG STATEFUL This section describes each keyword and its options. @@ -1749,7 +1749,7 @@ ipnat_rules="/etc/ipnat.rules" # rule - IN-OUT + DIRECTION Next, each rule must explicitly state the direction of traffic using one of @@ -1773,39 +1773,35 @@ ipnat_rules="/etc/ipnat.rules" # rule OPTIONS - - These options must be used in the order shown + Options are optional. However, if multiple options + are specified, they must be used in the order shown here. - - log indicates that the packet - header will be written to the &man.ipl.4; packet log - pseudo-device if the selection parameters match the - packet. - - quick indicates that if the - selection parameters match the packet, this rule will be - the last rule checked, and no further processing of any + log: when performing the + specified ACTION, the contents of the packet's + headers will be written to the &man.ipl.4; packet log + pseudo-device. + + quick: if + a packet matches this rule, the ACTION specified by the + rule occurs and no further processing of any following rules will occur for this packet. - on indicates the interface name - to be incorporated into the selection parameters. - Interface names are as displayed by &man.ifconfig.8;. - Using this option, the rule will only match if the - packet is going through that interface in the specified + on: must be followed by the interface name + as displayed by &man.ifconfig.8;. + The rule will only match if the + packet is going through the specified interface in the specified direction. - When a packet is logged, the headers of the packet - are written to the &man.ipl.4; packet logging - pseudo-device. Immediately following the + When using the log keyword, the following qualifiers may be used in this order: - body indicates that the first 128 + body: indicates that the first 128 bytes of the packet contents will be logged after the headers. - first. If the + first: if the log keyword is being used in conjunction with a keep state option, this option is recommended so that only the triggering @@ -1815,20 +1811,36 @@ ipnat_rules="/etc/ipnat.rules" # rule - SELECTION + PROTO_TYPE - The keywords described in this section are used to - describe attributes of the packet to be checked when - determining whether or not rules match. There is a - keyword subject, and it has sub-option keywords, one of - which has to be selected. The following general-purpose - attributes are provided for matching, and must be used - in this order: + The protocol type is optional. However, it is + mandatory if the rule needs to specify a a SRC_PROTO or + a DST_PROTO as it defines the type of protocol. When + specifying the type of protocol, use the + proto keyword followed by either a + protocol number or name from + /etc/protocols. + Example keywords include tcp, + udp, or + icmp. - PROTO + SRC_ADDR + + The from keyword is mandatory and + is followed by a keyword which represents the source of + the packet. The source can be a hostname, an + IP address followed by the + CIDR mask, an address pool, or the + keyword all. Refer to &man.ipf.5; + for examples. + + + + + SRC_PORT proto is the subject keyword which must include one of its corresponding keyword @@ -1847,7 +1859,7 @@ ipnat_rules="/etc/ipnat.rules" # rule - SRC_ADDR/DST_ADDR + DST_ADDR The all keyword is equivalent to from any to any with no other match @@ -1876,7 +1888,7 @@ ipnat_rules="/etc/ipnat.rules" # rule - PORT + DST_PORT If a port match is included, for either or both of source and destination, it is only applied to From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 22:16:32 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CC86EC1; Fri, 21 Feb 2014 22:16:32 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69C4A1305; Fri, 21 Feb 2014 22:16:32 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LMGWEq089399; Fri, 21 Feb 2014 22:16:32 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LMGWZv089398; Fri, 21 Feb 2014 22:16:32 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402212216.s1LMGWZv089398@svn.freebsd.org> From: Glen Barber Date: Fri, 21 Feb 2014 22:16:32 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44020 - head/en_US.ISO8859-1/articles/committers-guide X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 22:16:32 -0000 Author: gjb Date: Fri Feb 21 22:16:31 2014 New Revision: 44020 URL: http://svnweb.freebsd.org/changeset/doc/44020 Log: Dereference the SVN->CVS exporter. Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/committers-guide/article.xml Fri Feb 21 20:28:01 2014 (r44019) +++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Fri Feb 21 22:16:31 2014 (r44020) @@ -446,18 +446,6 @@ You need a Passphrase to protect your se The first real SVN commit is r300894. - There are mechanisms in place to automatically merge - changes back from the Subversion src - repository to the CVS repository for - some &os; branches (releng/6 through - releng/9), however this is purely to - support pre-existing end-user installs and should not be - relied upon, recommended or advertised. Future branches - will not be exported to CVS at all. The - ports repository was exported to CVS - for a period of time to aid end user migration, but as of - 28th February 2013 is no longer exported. - Subversion is not that different from CVS when it comes to daily use, but there are differences. Subversion has a number of features that @@ -2118,9 +2106,6 @@ U stable/9/share/man/man4/netmap.4 In commit logs etc., rev 179872 should be spelled r179872 as per convention. - Do not remove and re-add the same file in a single commit - as this will break the CVS exporter. - Speeding up svn is possible by adding the following to ~/.ssh/config: From owner-svn-doc-head@FreeBSD.ORG Fri Feb 21 22:51:27 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 435B2AA7; Fri, 21 Feb 2014 22:51:27 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11C391696; Fri, 21 Feb 2014 22:51:27 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1LMpQAO004905; Fri, 21 Feb 2014 22:51:26 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1LMpQMa004904; Fri, 21 Feb 2014 22:51:26 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201402212251.s1LMpQMa004904@svn.freebsd.org> From: Glen Barber Date: Fri, 21 Feb 2014 22:51:26 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44021 - head/en_US.ISO8859-1/htdocs/developers X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 22:51:27 -0000 Author: gjb Date: Fri Feb 21 22:51:26 2014 New Revision: 44021 URL: http://svnweb.freebsd.org/changeset/doc/44021 Log: Remove references to CVS, SVN->CVS exporter. Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/htdocs/developers/cvs.xml Modified: head/en_US.ISO8859-1/htdocs/developers/cvs.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/developers/cvs.xml Fri Feb 21 22:16:31 2014 (r44020) +++ head/en_US.ISO8859-1/htdocs/developers/cvs.xml Fri Feb 21 22:51:26 2014 (r44021) @@ -24,15 +24,11 @@

In June 2008, development of the base system moved to a different version control system, Subversion (SVN for short). The web - interface is available for browsing the repository. All changes - to the existing live branches (stable/9 and stable/8) are - also exported back to the legacy CVS repository, however the - CVS repositories are deprecated, and so existing users of them - should move away from doing so.

+ interface is available for browsing the repository.

In May 2012, the FreeBSD Documentation Project moved from CVS - to Subversion. Unlike the base system, the documentation SVN - repository is not exported back to CVS. There is a web interface available for browsing the contents of the FreeBSD Documentation Project SVN repository.

@@ -40,21 +36,7 @@

In July 2012, the FreeBSD Ports tree moved from CVS to Subversion. There is a web interface for - browsing the repository. The Ports tree is also exported back - to the legacy CVS repository. - It will cease to be exported early 2013.

- - -

Legacy - CVS

- -

CVS (the - Concurrent Version System) was the tool that the - &os; Project used to use to keep - the sources under control.

- -

The old web interface can be accessed at the cvsweb instance - .

+ browsing the repository.

Other options

From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 01:04:39 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6149B8E7; Sat, 22 Feb 2014 01:04:39 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A3381190; Sat, 22 Feb 2014 01:04:39 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1M14dTm058793; Sat, 22 Feb 2014 01:04:39 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1M14dt6058792; Sat, 22 Feb 2014 01:04:39 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402220104.s1M14dt6058792@svn.freebsd.org> From: Dru Lavigne Date: Sat, 22 Feb 2014 01:04:39 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44022 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 01:04:39 -0000 Author: dru Date: Sat Feb 22 01:04:38 2014 New Revision: 44022 URL: http://svnweb.freebsd.org/changeset/doc/44022 Log: Move some stuff that applies to all firewalls to Concepts section. Finish modernization pass through IPF Rulesets. Next commit will look at the provided examples. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Fri Feb 21 22:51:26 2014 (r44021) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 01:04:38 2014 (r44022) @@ -196,11 +196,28 @@ Security can be tightened further using a stateful firewall. This type of firewall keeps track of open connections and only allows traffic which either matches an - existing connection or opens a new, allowed connection. The - disadvantage of a stateful firewall is that it can be vulnerable - to Denial of Service (DoS) attacks if a lot - of new connections are opened very fast. Most firewalls use a - combination of stateful and non-stateful behavior. + existing connection or opens a new, allowed connection. + + Stateful filtering treats traffic as a bi-directional + exchange of packets comprising a session. When state is specified on a matching rule + the firewall dynamically generates + internal rules for each anticipated packet being exchanged + during the session. It has sufficient matching capabilities + to determine if a packet is valid for a session. Any packets + that do not properly fit the session template are + automatically rejected. + + When the session completes, it is removed from the + dynamic state table. + + Stateful filtering allows one to focus on blocking/passing + new sessions. If the new session is passed, all its + subsequent packets are allowed automatically and any impostor + packets are automatically rejected. If a new session is + blocked, none of its subsequent packets are allowed. Stateful + filtering provides advanced matching abilities capable of + defending against the flood of different attack methods + employed by attackers. When working with the firewall rules, be very @@ -1682,7 +1699,7 @@ ipnat_rules="/etc/ipnat.rules" # rule - IPF Rulesets + <application>IPF</application> Rulesets IPFILTER @@ -1692,30 +1709,37 @@ ipnat_rules="/etc/ipnat.rules" # rule This section describes the IPF rule syntax used to create stateful rules. When creating rules, keep in - mind that the default way in which filter rules are applied - is for the last matching rule to be - used. Even if the first rule to match a packet is a + mind that unless the quick keyword appears + in a rule, every rule is read + in order, with the last matching rule + being the one that is applied. This means that even if the first rule to match a packet is a pass, if there is a later matching rule that is a block, the packet will be dropped. - Refer to &man.ipf.5; for more details about rule syntax. + Sample rulesets can be found in + /usr/share/examples/ipfilter. When creating rules, a # character is used to mark the - start of a comment and may appear at the end of a rule, to explain its function, + start of a comment and may appear at the end of a rule, to explain that rule's function, or on its own line. Any blank lines are ignored. The keywords which are used in rules must be written in a specific - order, from left to right. Some keywords have sub-options which may be + order, from left to right. Some keywords are mandatory while + others are optional. Some keywords have sub-options which may be keywords themselves and also include more sub-options. The - keyword order is as follows: - - - + keyword order is as follows, where the words shown in uppercase + represent a variable and the words shown in lowercase must + precede the variable that follows it: ACTION DIRECTION OPTIONS proto PROTO_TYPE - from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT OBJECT PORT_NUM TCP_FLAG - STATEFUL + from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT TCP_FLAG|ICMP_TYPE + keep state STATE - This section describes each keyword and its options. + This section describes each of these keywords and their options. It + is not an exhaustive list of every possible option. Refer to + &man.ipf.5; for a complete description of the rule + syntax that can be used when creating + IPF rules and examples for using + each keyword. @@ -1807,6 +1831,10 @@ ipnat_rules="/etc/ipnat.rules" # rule this option is recommended so that only the triggering packet is logged and not every packet which matches the stateful connection. + + Additional options are available to specify + error return messages. Refer to &man.ipf.5; for more details. + @@ -1814,15 +1842,17 @@ ipnat_rules="/etc/ipnat.rules" # rule PROTO_TYPE The protocol type is optional. However, it is - mandatory if the rule needs to specify a a SRC_PROTO or - a DST_PROTO as it defines the type of protocol. When + mandatory if the rule needs to specify a a SRC_PORT or + a DST_PORT as it defines the type of protocol. When specifying the type of protocol, use the proto keyword followed by either a protocol number or name from /etc/protocols. - Example keywords include tcp, + Example protocol names include tcp, udp, or - icmp. + icmp. If PROTO_TYPE is specified but + no SRC_PORT or DST_PORT is specified, all port numbers + for that protocol will match that rule. @@ -1836,173 +1866,125 @@ ipnat_rules="/etc/ipnat.rules" # rule CIDR mask, an address pool, or the keyword all. Refer to &man.ipf.5; for examples. + + There is no way to match ranges of IP addresses + which do not express themselves easily using the dotted + numeric form / mask-length notation. The + net-mgmt/ipcalc package or port may be used to + ease the calculation of the CIDR mask. Additional information is + available at the utility's web page: http://jodies.de/ipcalc. SRC_PORT - proto is the subject keyword - which must include one of its corresponding keyword - sub-option values. The sub-option indicates a specific - protocol to be matched against. - - tcp/udp | udp | tcp | icmp or any - protocol names found in - /etc/protocols are recognized and - may be used. The special protocol keyword - tcp/udp may be used to match either a - TCP or a UDP - packet, and has been added as a convenience to save - duplication of otherwise identical rules. + The port number of the source is optional. However, + if it is used, it requires PROTO_TYPE to be first defined in + the rule. The port number must also be preceded by the + proto keyword. + + A number of different comparison operators are supported: + = (equal to), + != (not equal to), + < (less than), + > (greater than), + <= (less than or equal to), and + >= (greater than or equal to). + + + To specify port ranges, place the two port numbers + between <> (less than and greater than ), + >< (greater than and less than ), or + : (greater than or equal to and + less than or equal to). DST_ADDR - The all keyword is equivalent to - from any to any with no other match - parameters. - - from | to src to dst: the - from and to - keywords are used to match against IP addresses. Rules - must specify both the source and - destination parameters. any is a - special keyword that matches any IP address. Examples - include: from any to any, - from 0.0.0.0/0 to any, from - any to 0.0.0.0/0, from 0.0.0.0 to - any, and from any to - 0.0.0.0. - - There is no way to match ranges of IP addresses - which do not express themselves easily using the dotted - numeric form / mask-length notation. The - net-mgmt/ipcalc port may be used to - ease the calculation. Additional information is - available at the utility's web page: http://jodies.de/ipcalc. + The to keyword is mandatory and + is followed by a keyword which represents the destination of + the packet. Similar to SRC_ADDR, it can be a hostname, an + IP address followed by the + CIDR mask, an address pool, or the + keyword all. DST_PORT - If a port match is included, for either or both of - source and destination, it is only applied to - TCP and UDP - packets. When composing port comparisons, either the - service name from /etc/services or - an integer port number may be used. When the port - appears as part of the from object, - it matches the source port number. When it appears as - part of the to object, it matches the - destination port number. An example usage is - from any to any port = 80 - - Single port comparisons may be done in a number of - ways, using a number of different comparison operators. - Instead of the = shown in the example - above, the following operators may be used: - !=, <, - >, <=, - >=, eq, - ne, lt, - gt, le, and - ge. - - To specify port ranges, place the two port numbers - between <> or - >< + Similar to SRC_PORT, the port number of the destination is optional. However, + if it is used, it requires PROTO_TYPE to be first defined in + the rule. The port number must also be preceded by the + proto keyword. - TCP_FLAG + TCP_FLAG|ICMP_TYPE - Flags are only effective for TCP - filtering. The letters represent one of the possible - flags that can be matched against the - TCP packet header. - - The modernized rules processing logic uses the - flags S parameter to identify the TCP - session start request. + If tcp is specifed as the PROTO_TYPE, flags + can be specified as letters, where each letter represents one of the possible + TCP flags used to determine + the state of a connection. Possible values + are: S (SYN), + A (ACK), + P (PSH), + F (FIN), + U (URG), + R (RST), + C (CWN), and + E (ECN). + + If icmp is specifed as the PROTO_TYPE, + the ICMP type to match can be + specified. Refer to &man.ipf.5; for the allowable types. - STATEFUL + STATE - keep state indicates that on a - pass rule, any packets that match the rules selection - parameters should activate the stateful filtering - facility. - - - - - - - Stateful Filtering - - - IPFILTER - - stateful filtering - - - - - Stateful filtering treats traffic as a bi-directional - exchange of packets comprising a session. When activated, - keep-state dynamically generates - internal rules for each anticipated packet being exchanged - during the session. It has sufficient matching capabilities - to determine if a packet is valid for a session. Any packets - that do not properly fit the session template are - automatically rejected. - - IPF stateful filtering will also allow - ICMP packets related to an existing - TCP or UDP session. So, - if an ICMP type 3 code 4 packet is a - response in a session started by a keep state rule, it will - automatically be allowed. Any packet that IPF can be certain + If a pass rule contains + keep state, + IPF will add an entry to its + dynamic state table and allow subsequent packets that + match the connection. + IPF can track state for + TCP, UDP, and + ICMP sessions. Any packet that IPF can be certain is part of an active session, even if it is a different protocol, will be allowed. - Packets destined to go out through the interface connected + In IPF, packets destined to go out through the interface connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet comprising an active session conversation, it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. Packets that do not - belong to an already active session, are checked against the - outbound ruleset. - - Packets coming in from the interface connected to the + belong to an already active session are checked against the + outbound ruleset. Packets coming in from the interface connected to the public Internet are first checked against the dynamic state table. If the packet matches the next expected packet comprising an active session, it exits the firewall and the state of the session conversation flow is updated in the dynamic state table. Packets that do not belong to an already - active session, are checked against the inbound + active session are checked against the inbound ruleset. - When the session completes, it is removed from the - dynamic state table. - - Stateful filtering allows one to focus on blocking/passing - new sessions. If the new session is passed, all its - subsequent packets are allowed automatically and any impostor - packets are automatically rejected. If a new session is - blocked, none of its subsequent packets are allowed. Stateful - filtering provides advanced matching abilities capable of - defending against the flood of different attack methods - employed by attackers. + Several keywords can be added after + keep state. If used, these keywords set + various options that control stateful filtering, such as + setting connection limits or connection age. Refer to + &man.ipf.5; for the list of available options and their + descriptions. + + + From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 02:43:03 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBE75FEA; Sat, 22 Feb 2014 02:43:03 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A696B1949; Sat, 22 Feb 2014 02:43:03 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1M2h3kZ099193; Sat, 22 Feb 2014 02:43:03 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1M2h3JL099191; Sat, 22 Feb 2014 02:43:03 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402220243.s1M2h3JL099191@svn.freebsd.org> From: Dru Lavigne Date: Sat, 22 Feb 2014 02:43:03 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44024 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 02:43:03 -0000 Author: dru Date: Sat Feb 22 02:43:03 2014 New Revision: 44024 URL: http://svnweb.freebsd.org/changeset/doc/44024 Log: Cleanup sample ruleset. Move stuff that applies to all firewalls to Concepts section. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 01:58:09 2014 (r44023) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 02:43:03 2014 (r44024) @@ -170,6 +170,15 @@ selection criteria to create rules which will pass or block services. + To lookup unknown port numbers, refer to + /etc/services. Alternatively, visit http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers + and do a port number lookup to find the purpose of a + particular port number. + + Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. + A firewall ruleset can be either exclusive or inclusive. An exclusive firewall allows all traffic through except for the @@ -1699,7 +1708,7 @@ ipnat_rules="/etc/ipnat.rules" # rule - <application>IPF</application> Rulesets + <application>IPF</application> Rule Syntax IPFILTER @@ -1988,198 +1997,98 @@ ipnat_rules="/etc/ipnat.rules" # rule - - - Inclusive Ruleset Example + Example Ruleset - The following ruleset is an example of an inclusive type - of firewall which only allows services matching - pass rules and blocks all others by - default. Network firewalls intended to protect other machines - should have at least two interfaces, and are generally - configured to trust the LAN and to not - trust the public Internet. Alternatively, a host based - firewall might be configured to protect only the system it is - running on, and is appropriate for servers on an untrusted - network or a desktop system not protected by firewall on the - network. + This section demonstrates how to create an example ruleset + which only allows services matching + pass rules and blocks all others. - &os; uses interface lo0 and IP + &os; uses the loopback interface (lo0) and the IP address 127.0.0.1 - for internal communication within the operating system. The - firewall rules must contain rules to allow free movement of - these internally used packets. - - The interface which faces the public Internet is the one - specified in the rules that authorize and control access of - the outbound and inbound connections. - - In cases where one or more NICs are cabled to private - network segments, those interfaces may require rules to allow - packets originating from those LAN interfaces transit to each - other or to the Internet. - - The rules should be organized into three major - sections: the trusted interfaces, then the public - interface outbound, and lastly, the public untrusted interface - inbound. + for internal communication. The + firewall ruleset must contain rules to allow free movement of + these internally used packets: - The rules in each of the public interface sections should + # no restrictions on loopback interface +pass in quick on lo0 all +pass out quick on lo0 all + + The public interface connected to the Internet is used to + authorize and control access of + all outbound and inbound connections. If one or more interfaces are cabled to private + networks, those internal interfaces may require rules to allow + packets originating from the LAN to flow between the internal networks + or to the interface attached to the Internet. The ruleset should be organized into three major + sections: any trusted internal interfaces, outbound connections through the public + interface, and inbound connections through the public interface. + + These two rules allow all traffic to pass through a trusted + LAN interface named xl0: + + # no restrictions on inside LAN interface for private network +pass out quick on xl0 all +pass in quick on xl0 all + + The rules for the public interface's outbound and inbound sections should have the most frequently matched rules placed before less commonly matched rules, with the last rule in the section - blocking and logging all packets on that interface and + blocking and logging all packets for that interface and direction. - The outbound section in the following ruleset only - contains pass rules which uniquely identify - the services that are authorized for public Internet access. - All the rules use quick, - on, proto, - port, and keep state. - The proto tcp rules include - flag to identify the session start request - as the triggering packet to activate the stateful - facility. - - The inbound section blocks undesirable packets first, for - two different reasons. The first is that malicious packets - may be partial matches for legitimate traffic. These packets - have to be discarded rather than allowed, based on their - partial matches against the allow rules. - The second reason is that known and uninteresting rejects may - be blocked silently, rather than being logged by the last rule - in the section. - - The ruleset should ensure that there is no response - returned for any undesirable traffic. Invalid packets should - be silently dropped so that the attacker has no knowledge if - the packets reached the system. Rules that include a - log first option, will only log the event - the first time they are triggered. This option is included in - the sample nmap OS fingerprint rule. The - security/nmap utility is - commonly used by attackers who attempt to identify the - operating system of the server. - - Any time there are logged messages on a rule with - the log first option, - ipfstat -hio should be executed - to evaluate how many times the rule has been matched. A - large number of matches usually indicates that the system is - being flooded or is under attack. - - To lookup unknown port numbers, refer to - /etc/services. Alternatively, visit http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers - and do a port number lookup to find the purpose of a - particular port number. - - Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. - - The following ruleset creates an - inclusive firewall ruleset which can be - easily customized by commenting out - pass rules for services that should not - be authorized. - - To avoid logging unwanted messages, add a - block rule in the inbound section. - - Change the dc0 interface name in - every rule to the interface name that connects the system to - the public Internet. - - The following statements were added to - /etc/ipf.rules: - - ################################################################# -# No restrictions on Inside LAN Interface for private network -# Not needed unless you have LAN -################################################################# - -#pass out quick on xl0 all -#pass in quick on xl0 all - -################################################################# -# No restrictions on Loopback Interface -################################################################# -pass in quick on lo0 all -pass out quick on lo0 all - -################################################################# -# Interface facing Public Internet (Outbound Section) -# Match session start requests originating from behind the -# firewall on the private network -# or from this gateway server destined for the public Internet. -################################################################# + This set of rules defines the outbound section of the + public interface named dc0. + These rules keep state and identify + the specific services that internal systems are authorized for public Internet access. + All the rules use quick and specify the + appropriate port numbers and, where applicable, destination + addresses. -# Allow out access to my ISP's Domain name server. -# xxx must be the IP address of your ISP's DNS. -# Dup these lines if your ISP has more than one DNS server -# Get the IP addresses from /etc/resolv.conf file -pass out quick on dc0 proto tcp from any to xxx port = 53 flags S keep state + # interface facing Internet (outbound) +# Matches session start requests originating from or behind the +# firewall, destined for the Internet. + +# Allow outbound access to public DNS servers. +# Replace x.x.x. with address listed in /etc/resolv.conf. +# Repeat for each DNS server. +pass out quick on dc0 proto tcp from any to x.x.x. port = 53 flags S keep state pass out quick on dc0 proto udp from any to xxx port = 53 keep state -# Allow out access to my ISP's DHCP server for cable or DSL networks. -# This rule is not needed for 'user ppp' type connection to the -# public Internet, so you can delete this whole group. -# Use the following rule and check log for IP address. -# Then put IP address in commented out rule & delete first rule +# Allow access to ISP's specified DHCP server for cable or DSL networks. +# Use the first rule, then check log for the IP address of DHCP server. +# Then, uncomment the second rule, replace z.z.z.z with the IP address, +# and comment out the first rule pass out log quick on dc0 proto udp from any to any port = 67 keep state #pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state - -# Allow out non-secure standard www function +# Allow HTTP and HTTPS pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state - -# Allow out secure www function https over TLS SSL pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state -# Allow out send & get email function +# Allow email pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state -# Allow out Time +# Allow NTP pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state -# Allow out nntp news -pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state - -# Allow out gateway & LAN users' non-secure FTP ( both passive & active modes) -# This function uses the IPNAT built in FTP proxy function coded in -# the nat rules file to make this single rule function correctly. -# If you want to use the pkg_add command to install application packages -# on your gateway system you need this rule. +# Allow FTP pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state -# Allow out ssh/sftp/scp (telnet/rlogin/FTP replacements) -# This function is using SSH (secure shell) +# Allow SSH pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state -# Allow out insecure Telnet -pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state - -# Allow out FreeBSD CVSup -pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state - -# Allow out ping to public Internet +# Allow ping pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state -# Allow out whois from LAN to public Internet -pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state - -# Block and log only the first occurrence of everything -# else that's trying to get out. -# This rule implements the default block -block out log first quick on dc0 all - -################################################################# -# Interface facing Public Internet (Inbound Section) -# Match packets originating from the public Internet -# destined for this gateway server or the private network. -################################################################# +# Block and log everything else +block out log first quick on dc0 all + + This example of the rules in the inbound section of the + public interface blocks all undesirable packets first. + This reduces the number of packets that are + logged by the last rule. + # interface facing Internet (inbound) # Block all inbound traffic from non-routable or reserved address spaces block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP @@ -2191,67 +2100,52 @@ block in quick on dc0 from 192.0.2.0/24 block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect block in quick on dc0 from 224.0.0.0/3 to any #Class D & E multicast -##### Block a bunch of different nasty things. ############ -# That I do not want to see in the log - -# Block frags +# Block fragments and too short tcp packets block in quick on dc0 all with frags - -# Block short tcp packets block in quick on dc0 proto tcp all with short # block source routed packets block in quick on dc0 all with opt lsrr block in quick on dc0 all with opt ssrr -# Block nmap OS fingerprint attempts -# Log first occurrence of these so I can get their IP address +# Block OS fingerprint attempts and log first occurrence block in log first quick on dc0 proto tcp from any to any flags FUP # Block anything with special options block in quick on dc0 all with ipopts -# Block public pings +# Block public pings and ident block in quick on dc0 proto icmp all icmp-type 8 - -# Block ident block in quick on dc0 proto tcp from any to any port = 113 -# Block all Netbios service. 137=name, 138=datagram, 139=session -# Netbios is MS/Windows sharing services. -# Block MS/Windows hosts2 name server requests 81 +# Block incoming Netbios services block in log first quick on dc0 proto tcp/udp from any to any port = 137 block in log first quick on dc0 proto tcp/udp from any to any port = 138 block in log first quick on dc0 proto tcp/udp from any to any port = 139 -block in log first quick on dc0 proto tcp/udp from any to any port = 81 +block in log first quick on dc0 proto tcp/udp from any to any port = 81 -# Allow traffic in from ISP's DHCP server. This rule must contain -# the IP address of your ISP's DHCP server as it is the only -# authorized source to send this packet type. Only necessary for -# cable or DSL configurations. This rule is not needed for -# 'user ppp' type connection to the public Internet. -# This is the same IP address you captured and -# used in the outbound section. -pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state - -# Allow in standard www function because I have apache server -pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state + Any time there are logged messages on a rule with + the log first option, run + ipfstat -hio + to evaluate how many times the rule has been matched. A + large number of matches may indicate that the system is + under attack. -# Allow in non-secure Telnet session from public Internet -# labeled non-secure because ID/PW passed over public Internet as clear text. -# Delete this sample group if you do not have telnet server enabled. -#pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state + The rest of the rules in the inbound section define which + connections are allowed to be initiated from the Internet. + The last rule denies all connections which were not explicitly + allowed by previous rules in this section. + + +# Allow traffic in from ISP's DHCP server. Replace z.z.z.z with +# the same IP address used in the outbound section. +pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state -# Allow in secure FTP, Telnet, and SCP from public Internet -# This function is using SSH (secure shell) -pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state +# Allow public connections to specified internal web server +pass in quick on dc0 proto tcp from any to x.x.x.x port = 80 flags S keep state -# Block and log only first occurrence of all remaining traffic -# coming into the firewall. The logging of only the first -# occurrence avoids filling up disk with Denial of Service logs. -# This rule implements the default block. -block in log first quick on dc0 all -################### End of rules file ##################################### +# Block and log only first occurrence of all remaining traffic. +block in log first quick on dc0 all From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 03:13:44 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4820876; Sat, 22 Feb 2014 03:13:44 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF6F81FFA; Sat, 22 Feb 2014 03:13:44 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1M3DiCE012567; Sat, 22 Feb 2014 03:13:44 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1M3Dimg012566; Sat, 22 Feb 2014 03:13:44 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402220313.s1M3Dimg012566@svn.freebsd.org> From: Dru Lavigne Date: Sat, 22 Feb 2014 03:13:44 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44025 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 03:13:44 -0000 Author: dru Date: Sat Feb 22 03:13:44 2014 New Revision: 44025 URL: http://svnweb.freebsd.org/changeset/doc/44025 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 02:43:03 2014 (r44024) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 03:13:44 2014 (r44025) @@ -156,28 +156,27 @@ rulesets - A ruleset contains a group of rules which pass or - block packets based on the values contained in the packet. - The bi-directional exchange of packets between hosts comprises - a session conversation. The firewall ruleset processes both - the packets arriving from the public Internet, as well as the - packets produced by the system as a response to them. Each - TCP/IP service is predefined by its - protocol and listening port. Packets destined for a specific - service originate from the source address using an - unprivileged port and target the specific service port on the - destination address. All the above parameters can be used as - selection criteria to create rules which will pass or block - services. - - To lookup unknown port numbers, refer to - /etc/services. Alternatively, visit http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers - and do a port number lookup to find the purpose of a - particular port number. + A ruleset contains a group of rules which pass or block + packets based on the values contained in the packet. The + bi-directional exchange of packets between hosts comprises a + session conversation. The firewall ruleset processes both the + packets arriving from the public Internet, as well as the + packets produced by the system as a response to them. Each + TCP/IP service is predefined by its protocol + and listening port. Packets destined for a specific service + originate from the source address using an unprivileged port and + target the specific service port on the destination address. + All the above parameters can be used as selection criteria to + create rules which will pass or block services. + + To lookup unknown port numbers, refer to + /etc/services. Alternatively, visit http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers + and do a port number lookup to find the purpose of a particular + port number. - Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. + Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. A firewall ruleset can be either exclusive or inclusive. An @@ -207,35 +206,34 @@ connections and only allows traffic which either matches an existing connection or opens a new, allowed connection. - Stateful filtering treats traffic as a bi-directional - exchange of packets comprising a session. When state is specified on a matching rule - the firewall dynamically generates - internal rules for each anticipated packet being exchanged - during the session. It has sufficient matching capabilities - to determine if a packet is valid for a session. Any packets - that do not properly fit the session template are - automatically rejected. - - When the session completes, it is removed from the - dynamic state table. - - Stateful filtering allows one to focus on blocking/passing - new sessions. If the new session is passed, all its - subsequent packets are allowed automatically and any impostor - packets are automatically rejected. If a new session is - blocked, none of its subsequent packets are allowed. Stateful - filtering provides advanced matching abilities capable of - defending against the flood of different attack methods - employed by attackers. + Stateful filtering treats traffic as a bi-directional + exchange of packets comprising a session. When state is + specified on a matching rule the firewall dynamically generates + internal rules for each anticipated packet being exchanged + during the session. It has sufficient matching capabilities to + determine if a packet is valid for a session. Any packets that + do not properly fit the session template are automatically + rejected. + + When the session completes, it is removed from the dynamic + state table. + + Stateful filtering allows one to focus on blocking/passing + new sessions. If the new session is passed, all its subsequent + packets are allowed automatically and any impostor packets are + automatically rejected. If a new session is blocked, none of + its subsequent packets are allowed. Stateful filtering provides + advanced matching abilities capable of defending against the + flood of different attack methods employed by attackers. - - When working with the firewall rules, be very - careful. Some configurations can + + When working with the firewall rules, be very + careful. Some configurations can lock the administrator out of the server. To be - on the safe side, consider performing the initial firewall - configuration from the local console rather than doing it - remotely over ssh. - + on the safe side, consider performing the initial firewall + configuration from the local console rather than doing it + remotely over ssh. + @@ -1685,23 +1683,22 @@ ipnat_rules="/etc/ipnat.rules" # rule &prompt.root; service ipfilter start - To load the firewall rules, specify the name of the ruleset file using ipf. - The following command can - be used to replace the currently running firewall + To load the firewall rules, specify the name of the + ruleset file using ipf. The following + command can be used to replace the currently running firewall rules: &prompt.root; ipf -Fa -f /etc/ipf.rules where flushes all the internal rules - tables and specifies the file containing the - rules to load. + tables and specifies the file containing + the rules to load. This provides the ability to make changes to a custom - ruleset and update the - running firewall with a fresh copy of the rules without having - to reboot the system. This method is convenient for testing - new rules as the procedure can be executed as many times as - needed. + ruleset and update the running firewall with a fresh copy of + the rules without having to reboot the system. This method is + convenient for testing new rules as the procedure can be + executed as many times as needed. Refer to &man.ipf.8; for details on the other flags available with this command. @@ -1716,37 +1713,40 @@ ipnat_rules="/etc/ipnat.rules" # rule rule syntax - This section describes the IPF rule syntax - used to create stateful rules. When creating rules, keep in - mind that unless the quick keyword appears - in a rule, every rule is read - in order, with the last matching rule - being the one that is applied. This means that even if the first rule to match a packet is a - pass, if there is a later matching rule - that is a block, the packet will be dropped. - Sample rulesets can be found in - /usr/share/examples/ipfilter. - - When creating rules, a # character is used to mark the - start of a comment and may appear at the end of a rule, to explain that rule's function, - or on its own line. Any blank lines are ignored. - - The keywords which are used in rules must be written in a specific - order, from left to right. Some keywords are mandatory while - others are optional. Some keywords have sub-options which may be - keywords themselves and also include more sub-options. The - keyword order is as follows, where the words shown in uppercase - represent a variable and the words shown in lowercase must - precede the variable that follows it: + This section describes the IPF + rule syntax used to create stateful rules. When creating + rules, keep in mind that unless the quick + keyword appears in a rule, every rule is read in order, with + the last matching rule being the one + that is applied. This means that even if the first rule to + match a packet is a pass, if there is a + later matching rule that is a block, the + packet will be dropped. Sample rulesets can be found in + /usr/share/examples/ipfilter. + + When creating rules, a # character is + used to mark the start of a comment and may appear at the end + of a rule, to explain that rule's function, or on its own + line. Any blank lines are ignored. + + The keywords which are used in rules must be written in a + specific order, from left to right. Some keywords are + mandatory while others are optional. Some keywords have + sub-options which may be keywords themselves and also include + more sub-options. The keyword order is as follows, where the + words shown in uppercase represent a variable and the words + shown in lowercase must precede the variable that follows + it: ACTION DIRECTION OPTIONS proto PROTO_TYPE - from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT TCP_FLAG|ICMP_TYPE - keep state STATE + from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT + TCP_FLAG|ICMP_TYPE keep state STATE - This section describes each of these keywords and their options. It - is not an exhaustive list of every possible option. Refer to - &man.ipf.5; for a complete description of the rule - syntax that can be used when creating + This section describes each of these keywords and their + options. It is not an exhaustive list of every possible + option. Refer to &man.ipf.5; for a complete description of + the rule syntax that can be used when creating IPF rules and examples for using each keyword. @@ -1755,15 +1755,16 @@ ipnat_rules="/etc/ipnat.rules" # rule ACTION The action keyword indicates what to do with the - packet if it matches that rule. Every - rule must have an action. The + packet if it matches that rule. Every rule + must have an action. The following actions are recognized: block: drops the packet. pass: allows the packet. - log: generates a log record. + log: generates a log + record. count: counts the number of packets and bytes which can provide an indication of @@ -1777,62 +1778,60 @@ ipnat_rules="/etc/ipnat.rules" # rule allow more complex actions. decapsulate: removes any headers - in order to process the contents of the packet. + in order to process the contents of the packet. DIRECTION - Next, each rule must - explicitly state the direction of traffic using one of - these keywords: + Next, each rule must explicitly state the direction + of traffic using one of these keywords: - in: the rule is - applied against an inbound packet. + in: the rule is applied against + an inbound packet. - out: the rule is - applied against an outbound packet. + out: the rule is applied against + an outbound packet. all: the rule applies to either direction. - + If the system has multiple interfaces, the interface - can be specified along with the direction. An example would - be in on fxp0. + can be specified along with the direction. An example + would be in on fxp0. OPTIONS - Options are optional. However, if multiple options - are specified, they must be used in the order shown - here. + Options are optional. However, if multiple options + are specified, they must be used in the order shown + here. log: when performing the - specified ACTION, the contents of the packet's - headers will be written to the &man.ipl.4; packet log + specified ACTION, the contents of the packet's headers + will be written to the &man.ipl.4; packet log pseudo-device. - quick: if - a packet matches this rule, the ACTION specified by the - rule occurs and no further processing of any - following rules will occur for this packet. - - on: must be followed by the interface name - as displayed by &man.ifconfig.8;. - The rule will only match if the - packet is going through the specified interface in the specified - direction. + quick: if a packet matches this + rule, the ACTION specified by the rule occurs and no + further processing of any following rules will occur for + this packet. + + on: must be followed by the + interface name as displayed by &man.ifconfig.8;. The + rule will only match if the packet is going through the + specified interface in the specified direction. When using the log keyword, the following qualifiers may be used in this order: - body: indicates that the first 128 - bytes of the packet contents will be logged after the - headers. + body: indicates that the first + 128 bytes of the packet contents will be logged after + the headers. first: if the log keyword is being used in @@ -1841,8 +1840,9 @@ ipnat_rules="/etc/ipnat.rules" # rule packet is logged and not every packet which matches the stateful connection. - Additional options are available to specify - error return messages. Refer to &man.ipf.5; for more details. + Additional options are available to specify error + return messages. Refer to &man.ipf.5; for more + details. @@ -1850,7 +1850,7 @@ ipnat_rules="/etc/ipnat.rules" # rule PROTO_TYPE - The protocol type is optional. However, it is + The protocol type is optional. However, it is mandatory if the rule needs to specify a a SRC_PORT or a DST_PORT as it defines the type of protocol. When specifying the type of protocol, use the @@ -1858,10 +1858,10 @@ ipnat_rules="/etc/ipnat.rules" # rule protocol number or name from /etc/protocols. Example protocol names include tcp, - udp, or - icmp. If PROTO_TYPE is specified but - no SRC_PORT or DST_PORT is specified, all port numbers - for that protocol will match that rule. + udp, or icmp. If + PROTO_TYPE is specified but no SRC_PORT or DST_PORT is + specified, all port numbers for that protocol will match + that rule. @@ -1870,17 +1870,19 @@ ipnat_rules="/etc/ipnat.rules" # rule The from keyword is mandatory and is followed by a keyword which represents the source of - the packet. The source can be a hostname, an + the packet. The source can be a hostname, an IP address followed by the CIDR mask, an address pool, or the keyword all. Refer to &man.ipf.5; for examples. - There is no way to match ranges of IP addresses - which do not express themselves easily using the dotted - numeric form / mask-length notation. The - net-mgmt/ipcalc package or port may be used to - ease the calculation of the CIDR mask. Additional information is + There is no way to match ranges of + IP addresses which do not express + themselves easily using the dotted numeric form / + mask-length notation. The + net-mgmt/ipcalc package or port may + be used to ease the calculation of the + CIDR mask. Additional information is available at the utility's web page: http://jodies.de/ipcalc. @@ -1890,24 +1892,24 @@ ipnat_rules="/etc/ipnat.rules" # rule SRC_PORT The port number of the source is optional. However, - if it is used, it requires PROTO_TYPE to be first defined in - the rule. The port number must also be preceded by the - proto keyword. - - A number of different comparison operators are supported: - = (equal to), - != (not equal to), + if it is used, it requires PROTO_TYPE to be first + defined in the rule. The port number must also be + preceded by the proto keyword. + + A number of different comparison operators are + supported: = (equal to), + != (not equal to), < (less than), - > (greater than), + > (greater than), <= (less than or equal to), and - >= (greater than or equal to). - + >= (greater than or equal + to). To specify port ranges, place the two port numbers - between <> (less than and greater than ), - >< (greater than and less than ), or - : (greater than or equal to and - less than or equal to). + between <> (less than and + greater than ), >< (greater + than and less than ), or : (greater + than or equal to and less than or equal to). @@ -1915,20 +1917,21 @@ ipnat_rules="/etc/ipnat.rules" # rule DST_ADDR The to keyword is mandatory and - is followed by a keyword which represents the destination of - the packet. Similar to SRC_ADDR, it can be a hostname, an - IP address followed by the - CIDR mask, an address pool, or the - keyword all. + is followed by a keyword which represents the + destination of the packet. Similar to SRC_ADDR, it can + be a hostname, an IP address + followed by the CIDR mask, an address + pool, or the keyword all. DST_PORT - Similar to SRC_PORT, the port number of the destination is optional. However, - if it is used, it requires PROTO_TYPE to be first defined in - the rule. The port number must also be preceded by the + Similar to SRC_PORT, the port number of the + destination is optional. However, if it is used, it + requires PROTO_TYPE to be first defined in the rule. + The port number must also be preceded by the proto keyword. @@ -1936,11 +1939,12 @@ ipnat_rules="/etc/ipnat.rules" # rule TCP_FLAG|ICMP_TYPE - If tcp is specifed as the PROTO_TYPE, flags - can be specified as letters, where each letter represents one of the possible - TCP flags used to determine - the state of a connection. Possible values - are: S (SYN), + If tcp is specifed as the + PROTO_TYPE, flags can be specified as letters, where + each letter represents one of the possible + TCP flags used to determine the state + of a connection. Possible values are: + S (SYN), A (ACK), P (PSH), F (FIN), @@ -1949,9 +1953,10 @@ ipnat_rules="/etc/ipnat.rules" # rule C (CWN), and E (ECN). - If icmp is specifed as the PROTO_TYPE, - the ICMP type to match can be - specified. Refer to &man.ipf.5; for the allowable types. + If icmp is specifed as the + PROTO_TYPE, the ICMP type to match + can be specified. Refer to &man.ipf.5; for the + allowable types. @@ -1959,39 +1964,42 @@ ipnat_rules="/etc/ipnat.rules" # rule STATE If a pass rule contains - keep state, - IPF will add an entry to its - dynamic state table and allow subsequent packets that - match the connection. - IPF can track state for - TCP, UDP, and - ICMP sessions. Any packet that IPF can be certain - is part of an active session, even if it is a different - protocol, will be allowed. - - In IPF, packets destined to go out through the interface connected - to the public Internet are first checked against the dynamic - state table. If the packet matches the next expected packet - comprising an active session conversation, it exits the - firewall and the state of the session conversation flow is - updated in the dynamic state table. Packets that do not - belong to an already active session are checked against the - outbound ruleset. Packets coming in from the interface connected to the - public Internet are first checked against the dynamic state - table. If the packet matches the next expected packet - comprising an active session, it exits the firewall and the - state of the session conversation flow is updated in the - dynamic state table. Packets that do not belong to an already - active session are checked against the inbound - ruleset. - - Several keywords can be added after - keep state. If used, these keywords set - various options that control stateful filtering, such as - setting connection limits or connection age. Refer to - &man.ipf.5; for the list of available options and their - descriptions. - + keep state, + IPF will add an entry to its + dynamic state table and allow subsequent packets that + match the connection. + IPF can track state for + TCP, UDP, and + ICMP sessions. Any packet that + IPF can be certain is part of + an active session, even if it is a different protocol, + will be allowed. + + In IPF, packets destined + to go out through the interface connected to the public + Internet are first checked against the dynamic state + table. If the packet matches the next expected packet + comprising an active session conversation, it exits the + firewall and the state of the session conversation flow + is updated in the dynamic state table. Packets that do + not belong to an already active session are checked + against the outbound ruleset. Packets coming in from + the interface connected to the public Internet are first + checked against the dynamic state table. If the packet + matches the next expected packet comprising an active + session, it exits the firewall and the state of the + session conversation flow is updated in the dynamic + state table. Packets that do not belong to an already + active session are checked against the inbound + ruleset. + + Several keywords can be added after + keep state. If used, these keywords + set various options that control stateful filtering, + such as setting connection limits or connection age. + Refer to &man.ipf.5; for the list of available options + and their descriptions. + @@ -2003,47 +2011,51 @@ ipnat_rules="/etc/ipnat.rules" # rule which only allows services matching pass rules and blocks all others. - &os; uses the loopback interface (lo0) and the IP + &os; uses the loopback interface + (lo0) and the IP address 127.0.0.1 - for internal communication. The - firewall ruleset must contain rules to allow free movement of - these internally used packets: + for internal communication. The firewall ruleset must contain + rules to allow free movement of these internally used + packets: # no restrictions on loopback interface pass in quick on lo0 all pass out quick on lo0 all The public interface connected to the Internet is used to - authorize and control access of - all outbound and inbound connections. If one or more interfaces are cabled to private + authorize and control access of all outbound and inbound + connections. If one or more interfaces are cabled to private networks, those internal interfaces may require rules to allow - packets originating from the LAN to flow between the internal networks - or to the interface attached to the Internet. The ruleset should be organized into three major - sections: any trusted internal interfaces, outbound connections through the public - interface, and inbound connections through the public interface. - - These two rules allow all traffic to pass through a trusted - LAN interface named xl0: + packets originating from the LAN to flow + between the internal networks or to the interface attached to + the Internet. The ruleset should be organized into three + major sections: any trusted internal interfaces, outbound + connections through the public interface, and inbound + connections through the public interface. + + These two rules allow all traffic to pass through a + trusted LAN interface named + xl0: # no restrictions on inside LAN interface for private network pass out quick on xl0 all pass in quick on xl0 all - - The rules for the public interface's outbound and inbound sections should - have the most frequently matched rules placed before less - commonly matched rules, with the last rule in the section - blocking and logging all packets for that interface and - direction. + + The rules for the public interface's outbound and inbound + sections should have the most frequently matched rules placed + before less commonly matched rules, with the last rule in the + section blocking and logging all packets for that interface + and direction. This set of rules defines the outbound section of the - public interface named dc0. - These rules keep state and identify - the specific services that internal systems are authorized for public Internet access. - All the rules use quick and specify the + public interface named dc0. These rules + keep state and identify the specific services that internal + systems are authorized for public Internet access. All the + rules use quick and specify the appropriate port numbers and, where applicable, destination addresses. - # interface facing Internet (outbound) + # interface facing Internet (outbound) # Matches session start requests originating from or behind the # firewall, destined for the Internet. @@ -2082,11 +2094,11 @@ pass out quick on dc0 proto icmp from an # Block and log everything else block out log first quick on dc0 all - + This example of the rules in the inbound section of the - public interface blocks all undesirable packets first. - This reduces the number of packets that are - logged by the last rule. + public interface blocks all undesirable packets first. This + reduces the number of packets that are logged by the last + rule. # interface facing Internet (inbound) # Block all inbound traffic from non-routable or reserved address spaces @@ -2126,18 +2138,16 @@ block in log first quick on dc0 proto tc Any time there are logged messages on a rule with the log first option, run - ipfstat -hio - to evaluate how many times the rule has been matched. A - large number of matches may indicate that the system is - under attack. + ipfstat -hio to evaluate how many times the + rule has been matched. A large number of matches may indicate + that the system is under attack. The rest of the rules in the inbound section define which connections are allowed to be initiated from the Internet. The last rule denies all connections which were not explicitly allowed by previous rules in this section. - -# Allow traffic in from ISP's DHCP server. Replace z.z.z.z with + # Allow traffic in from ISP's DHCP server. Replace z.z.z.z with # the same IP address used in the outbound section. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 03:14:52 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B3AD8EF; Sat, 22 Feb 2014 03:14:52 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87B29100B; Sat, 22 Feb 2014 03:14:52 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1M3Eq7p012938; Sat, 22 Feb 2014 03:14:52 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1M3EqC0012937; Sat, 22 Feb 2014 03:14:52 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402220314.s1M3EqC0012937@svn.freebsd.org> From: Dru Lavigne Date: Sat, 22 Feb 2014 03:14:52 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44026 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 03:14:52 -0000 Author: dru Date: Sat Feb 22 03:14:51 2014 New Revision: 44026 URL: http://svnweb.freebsd.org/changeset/doc/44026 Log: Fix grammo. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 03:13:44 2014 (r44025) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 03:14:51 2014 (r44026) @@ -1851,7 +1851,7 @@ ipnat_rules="/etc/ipnat.rules" # rule PROTO_TYPE The protocol type is optional. However, it is - mandatory if the rule needs to specify a a SRC_PORT or + mandatory if the rule needs to specify a SRC_PORT or a DST_PORT as it defines the type of protocol. When specifying the type of protocol, use the proto keyword followed by either a From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 01:58:10 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4042B904; Sat, 22 Feb 2014 01:58:10 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 111C61645; Sat, 22 Feb 2014 01:58:10 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1M1w9IC079154; Sat, 22 Feb 2014 01:58:09 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1M1w9w7079153; Sat, 22 Feb 2014 01:58:09 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402220158.s1M1w9w7079153@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sat, 22 Feb 2014 01:58:09 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44023 - head/ja_JP.eucJP/htdocs/developers X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 22 Feb 2014 05:40:17 +0000 X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 01:58:10 -0000 Author: ryusuke Date: Sat Feb 22 01:58:09 2014 New Revision: 44023 URL: http://svnweb.freebsd.org/changeset/doc/44023 Log: - Merge the following from the English version: r41253 -> r44021 head/ja_JP.eucJP/htdocs/developers/cvs.xml Modified: head/ja_JP.eucJP/htdocs/developers/cvs.xml Modified: head/ja_JP.eucJP/htdocs/developers/cvs.xml ============================================================================== --- head/ja_JP.eucJP/htdocs/developers/cvs.xml Sat Feb 22 01:04:38 2014 (r44022) +++ head/ja_JP.eucJP/htdocs/developers/cvs.xml Sat Feb 22 01:58:09 2014 (r44023) @@ -1,11 +1,11 @@ ]> - + @@ -28,15 +28,10 @@ Subversion (н╛╓╥╓ф SVN) ╓к╟э╧т╓╥╓ч╓╥╓©║ё ╔╕╔╖╔ж╔╓╔С╔©╔у╔╖║╪╔╧ - ╓РмЬмя╓╥╓ф╔Й╔щ╔╦╔х╔Й╓Р╦╚╓К╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё - ╔╣╔щ║╪╔х╓╣╓Л╓ф╓╓╓К╔ж╔И╔С╔а (stable/9 ╓╙╓Х╓с stable/8) - ╓ь╓н╓╧╓ы╓ф╓нйя╧╧ею╓о║╒CVS ╔Й╔щ╔╦╔х╔Й╓к╓Бх©╠г╓╣╓Л╓ч╓╧║ё - ╓©╓ю╓╥║╒CVS ╔Й╔щ╔╦╔х╔Й╓о©Д╬╘╓╣╓Л╓ф╓╓╓й╓╓╓н╓г║╒ - CVS ╓РмЬмя╓╥╓ф╓╓╓К╔Ф║╪╔╤╓о SVN ╓к╟э╧т╓╥╓ф╓╞╓ю╓╣╓╓║ё

+ ╓РмЬмя╓╥╓ф╔Й╔щ╔╦╔х╔Й╓Р╦╚╓К╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё

2012 г╞ 5 ╥Н╓Х╓Й║╒FreeBSD ╔и╔╜╔Е╔А╔С╔ф║╪╔╥╔Г╔С╔в╔М╔╦╔╖╔╞╔х╓о║╒CVS ╓╚╓И - Subversion ╓ь╓х╟э╧т╓╥╓ч╓╥╓©║ё╔ы║╪╔╧╔╥╔╧╔ф╔Ю╓х╓о╟ш╓й╓Й║╒ - ╔и╔╜╔Е╔А╔С╔х╓н SVN ╔Й╔щ╔╦╔х╔Й╓ь╓нйя╧╧ею╓о║╒CVS ╓к╓ох©╠г╓╣╓Л╓ч╓╩╓С║ё╔╕╔╖╔ж╔╓╔С╔©╔у╔╖║╪╔╧ ╓РмЬмя╓╥╓ф FreeBSD ╔и╔╜╔Е╔А╔С╔ф║╪╔╥╔Г╔С╔в╔М╔╦╔╖╔╞╔х╓н SVN ╔Й╔щ╔╦╔х╔Й╓нфБмф╓Р╦╚╓К╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё

@@ -44,19 +39,7 @@

2012 г╞ 6 ╥Н╓Х╓Й║╒FreeBSD Ports ╔д╔Й║╪╓о║╒CVS ╓╚╓И Subversion ╓ь╓х╟э╧т╓╥╓ч╓╥╓©║ё╔╕╔╖╔ж╔╓╔С╔©╔у╔╖║╪╔╧ - ╓РмЬмя╓╥╓ф╔Й╔щ╔╦╔х╔Й╓нфБмф╓Р╦╚╓К╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё - Ports ╔д╔Й║╪╓нйя╧╧ею╓о║╒╦╣╓н CVS ╔Й╔щ╔╦╔х╔Й╓к╓Бх©╠г╓╣╓Л╓ч╓╧╓╛║╒ - 2013 г╞╓на╟х╬╓к╓о╧т╓О╓Л╓й╓╞╓й╓Км╫дЙ╓г╓╧║ё

- -

╔Л╔╛╔╥║╪ : CVS

- -

CVS (the - Concurrent Version System) ╓о║╒&os; ╔в╔М╔╦╔╖╔╞╔х╓╛║╒ - ╔╫║╪╔╧╓Р╢имЩ╓╧╓К╓©╓А╓к╩х╓ц╓ф╓╓╓©╔д║╪╔К╓г╓╧║ё

- -

╦е╓╓╔╕╔╖╔ж╓н╔╓╔С╔©╔у╔╖║╪╔╧╓о║╒cvsweb ╔╓╔С╔╧╔©╔С╔╧ - ╓╚╓И╔╒╔╞╔╩╔╧╓г╓╜╓ч╓╧║ё

+ ╓РмЬмя╓╥╓ф╔Й╔щ╔╦╔х╔Й╓нфБмф╓Р╦╚╓К╓Ё╓х╓╛╓г╓╜╓ч╓╧║ё

╓╫╓нб╬╓на╙бР╩Х

From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 06:51:55 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ED2C1BD; Sat, 22 Feb 2014 06:51:55 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73FBC1855; Sat, 22 Feb 2014 06:51:53 +0000 (UTC) X-AuditID: 12074425-f79906d000000cf9-54-53084900912c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id F2.AB.03321.10948035; Sat, 22 Feb 2014 01:51:45 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s1M6pfCM018016; Sat, 22 Feb 2014 01:51:41 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s1M6pdDL025231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 22 Feb 2014 01:51:40 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s1M6pcvr015600; Sat, 22 Feb 2014 01:51:38 -0500 (EST) Date: Sat, 22 Feb 2014 01:51:38 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Glen Barber Subject: Re: svn commit: r44020 - head/en_US.ISO8859-1/articles/committers-guide In-Reply-To: <201402212216.s1LMGWZv089398@svn.freebsd.org> Message-ID: References: <201402212216.s1LMGWZv089398@svn.freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixCmqrcvoyRFscGKnvMWPj4eYLPY3H2Cz uLFoP5PF7v5eZgcWjxmf5rMEMEZx2aSk5mSWpRbp2yVwZTycY1LwnKNi1bVW9gbGBexdjJwc EgImEvNOzGCDsMUkLtxbD2RzcQgJzGaSuLS6nRHC2cgosWbDQ1YI5xCTxNd1H1kgnAZGid5Z m1lB+lkEtCW+TLrGAmKzCahJPN7bzAoxV1Fi86lJzCC2CJC9bO0zsN3MAlESe5Y2gtUICwRJ /Jn+GewOTgEriWkvt4LZvAIOEtP3zAOrFxKwlNjwfBdYvaiAjsTq/VNYIGoEJU7OfMICMdNS 4tyf62wTGIVmIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdCLzezRC81pXQTIyiY 2V1UdzBOOKR0iFGAg1GJh9chlT1YiDWxrLgy9xCjJAeTkijvaXeOYCG+pPyUyozE4oz4otKc 1OJDjBIczEoivCkWQDnelMTKqtSifJiUNAeLkjhvrcWvICGB9MSS1OzU1ILUIpisDAeHkgTv SzegRsGi1PTUirTMnBKENBMHJ8hwHqDhP0EW8xYXJOYWZ6ZD5E8xKkqJ82p6ACUEQBIZpXlw vbBk84pRHOgVYd4/IO08wEQF1/0KaDAT0OBCsKuLSxIRUlINjOckmuZYnn95IPX5JBnDUMuH 7VucfvSlnLtffvv8380/0yd/OTV5UsAK7iPsVW8m1H9UtHBWPysVPen49Y2tmSZP1iZ/bHMJ Dao8pi5pzfJ2be4ZpUDhfds+XOoreTfJ4kw3axbX8ym2BW2cLsqftNMEm/R+WkZt9Og9JXL6 Z/3f6JmHvpU8e6PEUpyRaKjFXFScCAAenib+EQMAAA== Cc: svn-doc-head@freebsd.org, svn-doc-all@freebsd.org, doc-committers@freebsd.org X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 06:51:55 -0000 On Fri, 21 Feb 2014, Glen Barber wrote: > Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml > ============================================================================== > --- head/en_US.ISO8859-1/articles/committers-guide/article.xml Fri Feb 21 20:28:01 2014 (r44019) > +++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Fri Feb 21 22:16:31 2014 (r44020) > @@ -2118,9 +2106,6 @@ U stable/9/share/man/man4/netmap.4 > In commit logs etc., rev 179872 should be > spelled r179872 as per convention. > > - Do not remove and re-add the same file in a single commit > - as this will break the CVS exporter. > - The last time I updated patchfiles for a new upstream release, I caught myself removing and re-adding a file of the same name, which I went and reverted because I remembered that there was a hook which rejected such commits. Do we know if such a hook is still in place? (It occurs to me that I may just be remembering the exporter breakage and maybe there never was such a hook.) -Ben From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 10:29:13 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0DC687F; Sat, 22 Feb 2014 10:29:12 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAF1218BA; Sat, 22 Feb 2014 10:29:12 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1MATCgf085890; Sat, 22 Feb 2014 10:29:12 GMT (envelope-from pluknet@svn.freebsd.org) Received: (from pluknet@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1MATCFA085888; Sat, 22 Feb 2014 10:29:12 GMT (envelope-from pluknet@svn.freebsd.org) Message-Id: <201402221029.s1MATCFA085888@svn.freebsd.org> From: Sergey Kandaurov Date: Sat, 22 Feb 2014 10:29:12 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44027 - head/ru_RU.KOI8-R/books/porters-handbook X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 10:29:13 -0000 Author: pluknet Date: Sat Feb 22 10:29:12 2014 New Revision: 44027 URL: http://svnweb.freebsd.org/changeset/doc/44027 Log: MFen up to before splitting porters-handbook. book.xml r42833 -> r43827 uses.xml r43006 -> r43793 versions.xml r42930 -> r43967 Modified: head/ru_RU.KOI8-R/books/porters-handbook/book.xml head/ru_RU.KOI8-R/books/porters-handbook/uses.xml head/ru_RU.KOI8-R/books/porters-handbook/versions.xml Modified: head/ru_RU.KOI8-R/books/porters-handbook/book.xml ============================================================================== --- head/ru_RU.KOI8-R/books/porters-handbook/book.xml Sat Feb 22 03:14:51 2014 (r44026) +++ head/ru_RU.KOI8-R/books/porters-handbook/book.xml Sat Feb 22 10:29:12 2014 (r44027) @@ -10,14 +10,20 @@ $FreeBSD$ $FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/porters-handbook/book.xml,v 1.136 2006/10/20 09:25:00 marck Exp $ - Original revision: r42833 + Original revision: r43827 --> - - Руководство FreeBSD по созданию портов - + + + + + Руководство &os; по созданию портов - The FreeBSD Documentation Project + + The &os; Documentation Project + $FreeBSD$ @@ -37,27 +43,32 @@ 2011 2012 2013 - - The FreeBSD Documentation Project + The &os; Documentation + Project - &trademarks; - &legalnotice; + + &tm-attrib.freebsd; + &tm-attrib.unix; + &tm-attrib.sun; + &tm-attrib.general; + + $FreeBSD$ Введение - Коллекция портов FreeBSD является способом, используемым - практически каждым для установки приложений ("портов") на FreeBSD. - Как и почти всё остальное во FreeBSD, эта система в основном является + Коллекция портов &os; является способом, используемым + практически каждым для установки приложений ("портов") на &os;. + Как и почти всё остальное во &os;, эта система в основном является добровольно поддерживаемым начинанием. Важно иметь это в виду при чтении данного документа. - Во FreeBSD любой может прислать новый порт либо изъявить желание + Во &os; каждый может прислать новый порт либо изъявить желание поддерживать существующий порт, если его никто ещё никто не поддерживает—вам не нужно иметь никаких особых привилегий на внесение изменений, чтобы это делать. @@ -70,7 +81,7 @@ обновить существующий? Великолепно! Ниже находятся некоторые указания по созданию нового порта для - FreeBSD. Если вы хотите обновить существующий порт, вы должны + &os;. Если вы хотите обновить существующий порт, вы должны прочесть их, а затем . Если этот документ недостаточно подробен, вы должны обратиться к @@ -114,11 +125,24 @@ Здесь предполагается, что программное обеспечение компилируется без проблем как есть, то есть для работы приложения на вашей системе - FreeBSD не потребовалось абсолютно никаких изменений. Если + &os; не потребовалось абсолютно никаких изменений. Если требовалось что-то изменить, то вам придется обратиться также и к следующему разделу. + + Перед началом портирования рекомендуется установить + переменную &man.make.1; DEVELOPER в + /etc/make.conf. + + &prompt.root; echo DEVELOPER=yes >> /etc/make.conf + + Эта настройка включает режим разработчика, + в котором отображаются предупреждения при использовании + устаревших конструкций и задействуются некоторые дополнительные + проверки при вызове команды make. + + Создание файла <filename>Makefile</filename> @@ -132,12 +156,9 @@ PORTVERSION= 1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ -MAINTAINER= asami@FreeBSD.org +MAINTAINER= youremail@example.com COMMENT= Cat chasing a mouse all over the screen -MAN1= oneko.1 -MANCOMPRESSED= yes - .include <bsd.port.mk> @@ -150,7 +171,8 @@ MANCOMPRESSED= yes Посмотрим, сможете ли вы его понять. Не обращайте внимание на содержимое строчки $FreeBSD$, она - будет заполнена автоматически системой SVN, когда порт будет + будет заполнена автоматически системой + Subversion, когда порт будет импортирован в наше дерево портов. Вы можете найти более подробный пример в разделе пример Makefile. @@ -178,8 +200,8 @@ MANCOMPRESSED= yes из README или страниц справочника; слишком часто они не являются кратким описанием порта или имеют неудобный формат (например, страницы - справочника выровнены пробелами, поскольку это выглядит в - особенности плохо с моноширинными шрифтами). + справочника выровнены пробелами, что особенно плохо + смотрится с моноширинными шрифтами). Хорошо составленный pkg-descr @@ -225,16 +247,14 @@ WWW: http://www.oneko.org//usr/local). - Если вы используете переменные - MANn (а вы должны - это делать), то указывать страницы справочника здесь не - нужно. Если порт во время установки создает каталоги, убедитесь, - что добавили строку @dirrm для удаления + Если порт во время установки создает каталоги, убедитесь, + что добавлены строки @dirrm для удаления каталогов при удалении пакета. Вот маленький пример: bin/oneko +man/man1/oneko.1.gz lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm @@ -242,7 +262,7 @@ lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko Обратитесь к странице справочной системы по команде - &man.pkg.create.1; с подробным описанием формата списка + &man.pkg-create.8; с подробным описанием формата списка упаковки. @@ -270,6 +290,7 @@ lib/X11/oneko/mouse.xpm Makefile: PLIST_FILES= bin/oneko \ + man/man1/oneko.1.gz \ lib/X11/app-defaults/Oneko \ lib/X11/oneko/cat1.xpm \ lib/X11/oneko/cat2.xpm \ @@ -293,7 +314,7 @@ PLIST_DIRS= lib/X11/onekoОбратной стороной такого способа перечисления файлов и каталогов порта является невозможность использования - последовательностей команд, описанных в &man.pkg.create.1;. + последовательностей команд, описанных в &man.pkg-create.8;. Поэтому он подходит для простых портов, что делает их ещё более простыми. Одновременно с этим положительным моментом является уменьшение количества файлов в коллекции портов. Пожалуйста, @@ -333,22 +354,34 @@ PLIST_DIRS= lib/X11/oneko pkg-plist не содержит ничего сверх того, - что устанавливается вашим портом + что устанавливается портом pkg-plist содержит абсолютно все, что - устанавливается вашим портом + устанавливается портом - Ваш порт может быть переустановлен множество раз с помощью - указания цели reinstall + Порт может быть установлен с помощью + указания цели install. Это + позволяет убедиться в правильной работе сценария + установки. - Ваш порт подчищает - за собой после своего удаления + Порт может быть правильным образом удалён с помощью + указания цели deinstall. Это + позволяет убедиться в правильной работе сценария + удаления. + + + + Следует убедиться, что make package + можно запустить из-под обычного пользователя (то есть, + не из-под root). + Если это не так, в Makefile порта + должно быть добавлено NEED_ROOT=yes. @@ -356,20 +389,19 @@ PLIST_DIRS= lib/X11/onekoРекомендуемый порядок проверки - make install + make stage - make package + make check-orphans - make deinstall + make package - pkg_add package-name - + make install @@ -377,31 +409,25 @@ PLIST_DIRS= lib/X11/oneko - make reinstall - - - - make package + pkg add package-filename - make readme + make package (из-под + пользователя) - Проверьте, что ни на шаге package, ни на - шаге deinstall не выдается никаких - предупреждений. После выполнения шага 3 проверьте, что все новые - каталоги были успешно удалены. Также попробуйте запустить - программное обеспечение после выполнения шага 4, чтобы убедиться, что - оно работает правильно при установке из пакета. - - Наиболее основательным способом автоматизации этих шагов является - установка ports tinderbox. Это - обеспечивает jails, в которых вы можете проверять - все вышеуказанные шаги без изменения состояния в вашей основной - системе. Для получения дополнительной информации смотрите - ports/ports-mgmt/tinderbox. + Убедитесь, что на любом из этапов не выдается никаких + предупреждений. + + Основательное автоматизированное тестирование может быть + выполнено при помощи + ports-mgmt/tinderbox или + ports-mgmt/poudriere из Коллекции + Портов. Эти приложения используют jails, + в которых проверяются все перечисленные выше этапы без + изменения состояния основной системы. @@ -410,7 +436,7 @@ PLIST_DIRS= lib/X11/onekoБудьте добры, пользуйтесь утилитой portlint для проверки того, что ваш порт соответствует нашим рекомендациям. - Программа ports-mgmt/portlint + Программа ports-mgmt/portlint является частью Коллекции Портов. В частности, вы можете захотеть проверить, правильно ли сформирован файл Makefile и @@ -420,38 +446,45 @@ PLIST_DIRS= lib/X11/oneko Посылка нового порта - Перед посылкой нового порта удостоверьтесь, что вы прочитали - раздел о том, что можно и нельзя делать. + Перед посылкой нового порта прочитайте раздел о том, что + можно и нельзя делать. - Теперь, когда вы счастливы от своего первого порта, единственное, + Когда вы наконец довольны своим первым портом, единственное, что осталось сделать, это включить его в основное дерево портов - &os; и осчастливить этим всех остальных. Нам не нужен ни ваш + &os; и осчастливить этим всех остальных. Нам не нужен ни каталог work, ни пакет - pkgname.tgz, так что удалите их прямо сейчас. - Затем (предположим, что ваш порт зовут oneko) перейдите в каталог - выше, там, где находится каталог oneko, и наберите - следующее: shar `find oneko` > oneko.shar - - Включите ваш файл oneko.shar - в сообщение об ошибке и пошлите - его с помощью программы &man.send-pr.1; (обратитесь к разделу - Сообщения об ошибках и общие замечания для получения подробной - информации о программе &man.send-pr.1;). Не забудьте - указать в сообщении категорию ports и класс - change-request (Не указывайте, что сообщение - имеет статус confidential!). Добавьте также - краткое описание программы, порт которой вы создали, в раздел - Description отправляемого PR (например, содержимое - COMMENT в сокращенном виде) и сам файл в виде архива - shar, поместив его в раздел Fix. + pkgname.tgz, так что удалите их прямо + сейчас. + + Затем получите файл &man.shar.1;. Предполагая, что порт + называется oneko, перейдите в каталог выше, где находится + каталог oneko, и наберите: + shar `find oneko` > oneko.shar + + Включите oneko.shar в сообщение об + ошибке и пошлите его с помощью &man.send-pr.1;. Обратитесь к + разделу + Сообщения об ошибках и общие замечания для получения + подробной информации о &man.send-pr.1;). + + Укажите в сообщении категорию ports и + класс change-request. + Не указывайте, что сообщение имеет статус + confidential! Добавьте краткое описание + программы в поле Description отправляемого PR + (например, содержимое COMMENT в сокращённом + варианте) и сам файл в виде архива .shar + в поле Fix. - Вы можете значительно облегчить нашу работу, если в тему - сообщения о проблеме поместите хорошее описание. Мы рекомендуем - нечто вроде New port: <категория>/<название - порта> <краткое описание порта> для новых портов. - Если вы следуете этой схеме, то шансы на то, что на ваше PR вскоре - кто-то взглянет, гораздо выше. + Хорошее описание в заголовке сообщения о проблеме + значительно облегчает работу коммиттеров портов. Для новых + портов мы предпочитаем нечто вроде New port: + <категория>/<название порта> <краткое + описание порта>. Следование этой схеме + упрощает и ускоряет начало работы по добавлению нового + порта. Повторим ещё раз, что не нужно включать ни оригинальный @@ -460,16 +493,17 @@ PLIST_DIRS= lib/X11/onekomake package; для новых портов используйте &man.shar.1;, но не &man.diff.1;. - После того как вы послали порт, пожалуйста, потерпите. - Иногда включение нового порта во &os; может занять до нескольких - месяцев, а иногда всего несколько дней. - Здесь вы можете найти список PR для портов ожидающих своей - очереди для включения во &os;. - - Мы рассмотрим ваш порт, при необходимости вернём его обратно, а - затем включим порт в наше дерево. Ваше имя также будет добавлено - в список - Дополнительных контрибуторов проекта FreeBSD и другие + После отправки порта, пожалуйста, потерпите. Время, + необходимое для включения нового порта во &os;, может занимать + от нескольких дней до нескольких месяцев. + Здесь можно увидеть список ожидающих PR для портов. + + После рассмотрения нового порта мы при необходимости вам + ответим, а затем включим порт в наше дерево. Ваше имя также + будет добавлено в список + Дополнительных контрибуторов проекта &os; и другие файлы. @@ -502,10 +536,9 @@ PLIST_DIRS= lib/X11/onekoDISTDIR. Если цель fetch не может найти требуемые файлы в - каталоге DISTDIR, то он будет искаться по + каталоге DISTDIR, то они будут искаться по указателю URL MASTER_SITES, который - устанавливается в Makefile, а также на нашем основном FTP-сервере - по адресу ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/, + устанавливается в Makefile, а также на наших FTP зеркалах, куда мы по возможности помещаем дистрибутивные файлы для архива. Затем она попытается сгрузить указанный файл с помощью FETCH, полагая, что запрашивающая машина имеет @@ -558,11 +591,22 @@ PLIST_DIRS= lib/X11/oneko Выполняется цель build. Она отвечает за переход в собственный рабочий каталог порта - (WRKSRC) и его построение. Если задана - переменная USES= gmake, будет использоваться - GNU-версия утилиты make, в противном случае - будет использована системная утилита - make. + (WRKSRC) и его построение. + + + + Выполняется цель stage. + Конечный набор построенных файлов помещается во временный + каталог (STAGEDIR, смотрите + ). Иерархия этого + каталога отражает иерархию каталогов системы, в которую + данный пакет будет устанавливаться. + + + + Выполняется цель install. + В систему копируются файлы, перечисленные в pkg-plist + порта. @@ -608,8 +652,9 @@ PLIST_DIRS= lib/X11/oneko - Теперь вы представляете, что происходит, когда пользователь - набирает команду make, теперь давайте пройдемся + Теперь, когда вы представляете, что происходит, когда + пользователь набирает команду make install, + давайте пройдемся через шаги, рекомендуемые для создания настоящего порта. @@ -706,22 +751,44 @@ PLIST_DIRS= lib/X11/onekoСоздание патчей Файлы, которые добавлялись или изменялись в процессе создания - порта, могут быть выявлены вызовом программы &man.diff.1;, + порта, могут быть выявлены программой &man.diff.1;, а результат работы этой программы может быть в дальнейшем передан - программе &man.patch.1;. Каждый патч, который вы собираетесь - применить, должен быть сохранен в файл с именем + программе &man.patch.1;. Такое действие с обычным файлом + подразумевает сохранение копии файла с первоначальным содержимым + перед внесением каких-либо изменений. + + &prompt.user; cp file file.orig + + Патчи сохраняются в виде файлов с именем patch-*, где - * обозначает путь к файлу, к которому - применяется патч, такой как + * обозначает путь к файлу, + к которому применяется патч, такой как patch-Imakefile или - patch-src-config.h. Эти файлы должны находиться в + patch-src-config.h. + + После того как файл был изменён, используется &man.diff.1; + для получения разницы между первоначальной и изменённой + версиями. Параметр указывает &man.diff.1; + выводить разницу в унифицированном формате, + который также является предпочтительным. + + &prompt.user; diff -u file.orig file > patch-pathname-file + + Для порождении патчей для новых добавляемых файлов + используется параметр , который заставляет + &man.diff.1; трактовать несуществующие прежде файлы как если + бы они существовали, но имели пустое содержимое: + + &prompt.user; diff -u -N newfile.orig newfile > patch-pathname-newfile + + Файлы с патчами помещаются в каталоге PATCHDIR - (как правило, это files/), + (как правило, это files/), откуда они будут взяты автоматически. Все патчи обязаны быть сделаны относительно каталога WRKSRC (как правило, это каталог, в который распаковывается исходный архив и где будет выполняться построение). Для упрощения внесения изменений и - обновлений вы должны избегать наличия более чем одного патча для + обновлений избегайте наличия более чем одного патча для одного и того же файла (например, патчей patch-file и patch-file2, оба меняющих файл WRKSRC/foobar.c). @@ -732,14 +799,23 @@ PLIST_DIRS= lib/X11/onekopatch-src-freeglut__joystick.c. - Пожалуйста, используйте для именования ваших патчей только символы + Пожалуйста, используйте для именования патчей только символы [-+._a-zA-Z0-9]. Не используйте любые другие - символы, кроме этих. Не называйте ваши патчи как - patch-aa или patch-ab и - так далее, всегда ссылайтесь на путь и название файла в названиях + символы, кроме этих. Не называйте патчи как + patch-aa или patch-ab, + всегда ссылайтесь на путь и название файла в названиях самих патчей. - Не помещайте строки RCS в патчи. SVN будет изменять их при + Существует альтернативный упрощённый способ создания + патчей для существующих файлов. Первые шаги те же самые: + создание копии неизменённого файла с расширением + .orig и внесение изменений. После этого + используйте make makepatch, чтобы обновить + файлы с патчами в каталоге files данного + порта. + + Не помещайте строки RCS в патчи. + Subversion будет изменять их при помещении файлов в дерево портов, и когда мы будем их оттуда извлекать, они будут уже другие, поэтому применение патчей окончится неудачей. Строчки RCS предваряются знаком доллара @@ -754,65 +830,72 @@ PLIST_DIRS= lib/X11/onekoMakefile, когда как порт использует Imake или GNU-версию программы configure, и так далее, - не нужны, и должны быть удалены. Если вы отредактировали файл - configure.in и запустили - autoconf для перегенерации + не нужны, и должны быть удалены. Если было необходимо + отредактировать файл configure.in и + запустить autoconf для перегенерации configure, не нужно включать файлы diff для configure (они частенько вырастают до нескольких - тысяч строк!); задайте USE_AUTOTOOLS=autoconf:261 и + тысяч строк!). Вместо этого задайте + USE_AUTOTOOLS=autoconf:261 и включите diff-файл для configure.in. - Также постарайтесь минимизировать в ваших патчах объем + Старайтесь минимизировать в патчах объём нефункциональных изменений с пустыми символами. В мире Открытого Исходного Кода является распространенным совместное использование проектами больших объемов кодовой базы, но с различными стилями - и правилами отступов. Если вы берете работающую функциональную - часть из одного проекта для исправления похожей области в другом, - то будьте аккуратны, пожалуйста: получаемый однострочный патч - может быть полон нефункциональных изменений. Это не только - увеличивает размер репозитория SVN, но также усложняет поиск того, - что конкретно вызвало проблему и что вы вообще изменили. - - Если вам нужно удалить файл, то вы можете сделать это при - выполнении цели post-extract вместо того, - чтобы оформлять это как часть патча. + и правилами отступов. При копировании работающей функциональной + части из одного проекта для исправления похожей области в другом, + будьте аккуратны, пожалуйста: получаемый однострочный патч + может указаться полон нефункциональных изменений. Это не только + увеличивает размер репозитория Subversion, + но также усложняет поиск того, + что конкретно вызвало проблему и что вообще поменялось. + + Если нужно удалить файл, сделайте это при выполнении цели + post-extract, вместо того чтобы + оформлять это как часть патча. Простые перемещения могут быть выполнены непосредственно из Makefile порта с использованием &man.sed.1; в - режиме in-place. Это очень удобно, когда вам нужно применить патч - на значение переменной. Пример: + режиме in-place. Это удобно, когда при изменении используется + значение переменной: post-patch: @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README - Довольно часто бывают ситуации, когда портируемое программное - обеспечение, особенно если основной платформой разработки является - &windows;, использует конвенцию CR/LF для большинства своих исходных - файлов. Это может быть причиной проблем с дальнейшей упаковкой, - предупреждениями компилятора, выполнением скриптов - (/bin/sh^M not found) и так далее. Для быстрой + Довольно часто в исходных файлах портируемого программного + обеспечения используется конвенция CR/LF. Это может стать + причиной проблем с дальнейшей упаковкой, предупреждениями + компилятора или выполнением скриптов (таких как + /bin/sh^M not found). Для быстрого преобразования всех файлов из CR/LF просто в LF добавьте - USE_DOS2UNIX=yes в Makefile - порта. Может быть указан перечень преобразуемых файлов: + в Makefile порта эту запись: + + USES= dos2unix - USE_DOS2UNIX= util.c util.h + Может быть задан точный список преобразуемых файлов: - Если вы хотите преобразовать группу файлов в разных подкаталогах, - то для этого можно использовать DOS2UNIX_REGEX. + USES= dos2unix +DOS2UNIX_FILES= util.c util.h + + Используйте DOS2UNIX_REGEX, чтобы + преобразовать группу файлов в разных подкаталогах. Его параметром является регулярное выражение, совместимое с - find. Подробнее о формате в &man.re.format.7;. - Эта опция используется для преобразования всех файлов заданного - расширения, к примеру всех исходных файлов, не затрагивая двоичные - файлы: - - USE_DOS2UNIX= yes -DOS2UNIX_REGEX= .*\.(c|cpp|h) - - Если вы хотите создать патч на основе существующего файла, то вы - можете его скопировать с расширением .orig, а - затем изменить исходный. Цельmakepatch - запишет соответствующий файл с патчем в каталог - files данного порта. + &man.find.1;. Подробнее о формате в &man.re.format.7;. + Такой вариант удобен для преобразования всех файлов заданного + расширения. Для примера, преобразуем все исходные файлы, + не затрагивая двоичные файлы: + + USES= dos2unix +DOS2UNIX_REGEX= .*\.([ch]|cpp) + + Другим вариантом является использование + DOS2UNIX_GLOB, который вызывает + find для каждого из перечисленных в нём + элементов. + + USES= dos2unix +DOS2UNIX_GLOB= *.c *.cpp *.h @@ -913,13 +996,16 @@ DOS2UNIX_REGEX= .*\.(c|cpp|h)PORTREVISION используются - автоматизированными инструментами (например, &man.pkg.version.1;) + автоматизированными инструментами (например, + pkg version, см. &man.pkg-version.8;) для определения факта появления нового пакета. Значение PORTREVISION должно увеличиваться каждый раз, когда в порте FreeBSD делаются изменения, которые - достаточно сильно затрагивают содержимое или структуру - соответствующего пакета. + как-либо меняют получаемый пакет. Сюда относятся только + изменения, затрагивающие построение пакета с параметрами по + умолчанию. Примеры случаев, когда значение PORTREVISION должно быть увеличено: @@ -1009,7 +1095,7 @@ DOS2UNIX_REGEX= .*\.(c|cpp|h)PORTEPOCH Время от времени разработчик программного обеспечения или - создатель порта FreeBSD делают что-то не так и выпускают версию + создатель порта &os; делают что-то не так и выпускают версию программы, номер которой меньше предыдущей версии. Примером этого является порт, название которого меняется с foo-20000801 на foo-1.0 (изначально это не считалось бы более новой версией, так как @@ -1018,9 +1104,8 @@ DOS2UNIX_REGEX= .*\.(c|cpp|h) Результат сравнения номера версии не всегда очевиден. Для выполнения сравнения двух строк с номером версии можно - использовать &man.pkg.version.1;. Эквивалентом в - pkgng является - pkg version -t. Например: + использовать pkg version + (см. &man.pkg-version.8;). Например: &prompt.user; pkg_version -t 0.031 0.29 > @@ -1060,7 +1145,7 @@ DOS2UNIX_REGEX= .*\.(c|cpp|h)PORTVERSION может появиться необходимость её иметь, если в будущих релизах программное обеспечение должно изменить структуру номера версии. - Однако создателям портов нужно быть внимательными, когда + Однако создателям портов для &os; нужно быть внимательными, когда разработчик выпускает релиз без официального номера версии — эдакие промежуточные релизы. Имеется соблазн пометить релиз датой его выхода, что может вызвать проблемы, как и @@ -1091,7 +1176,7 @@ PORTVERSION= 0.10 Обнаружена брешь в безопасности, исправление которой потребовало создания - локального патча для FreeBSD. Соответственно было увеличено + локального патча для &os;. Соответственно было увеличено значение переменной PORTREVISION. PORTNAME= gtkmumble @@ -1165,40 +1250,6 @@ PORTEPOCH= 1 частью значения переменной PORTNAME. - - <varname>LATEST_LINK</varname> - - LATEST_LINK задает в процессе построения - пакета короткое имя ссылки, которые могут использоваться при - выполнении команды pkg_add -r. Это позволяет, - к примеру, установить последнюю версию perl, используя - pkg_add -r perl, без знания точного номера - версии. Такое имя должно быть уникальным и очевидным для - пользователей. - - В некоторых случаях в коллекции портов может присутствовать - несколько версий программы одновременно. Обе системы, построения - индексов и построения пакетов, нуждаются в способности их видеть - как разные, независимые порты, хотя все они могут иметь схожее - значение для PORTNAME, - PKGNAMEPREFIX и даже - PKGNAMESUFFIX. В этих случаях для всех портов - кроме главного следует присвоить различные значения для - необязательной переменной LATEST_LINK — - чтобы получить пример ее использования, смотрите порты - lang/gcc46 и lang/gcc, - а также семейство www/apache*. При установке - NO_LATEST_LINK ссылки не создаются; эта - необязательная переменная может быть указана во всех версиях, - кроме главной. Обратите - внимание, как выбирать главную версию — - самую популярную, самую поддерживаемую, - с наименьшими изменениями и так далее — это - выходит за рамки рекомендаций этого руководства; мы всего лишь - сообщаем вам, как указывать версии других портов после того, как - вы выбрали главный. - - Соглашения по именованию пакетов @@ -1218,7 +1269,7 @@ PORTEPOCH= 1 - FreeBSD пытается поддерживать языки, на которых разговаривают + &os; пытается поддерживать языки, на которых разговаривают её пользователи. Часть language- должна быть двухсимвольным сокращением от названия языка по стандарту ISO-639, если порт специфичен для конкретного языка. @@ -1262,9 +1313,8 @@ PORTEPOCH= 1 имеют одинаковый PORTNAME, является вполне нормальным, как для портов www/apache*; в этом случае различные версии (и различные записи в индексе) - отличаются по значениям PKGNAMEPREFIX, - PKGNAMESUFFIX и - LATEST_LINK. + отличаются по значениям PKGNAMEPREFIX + и PKGNAMESUFFIX. @@ -1613,7 +1663,7 @@ PORTEPOCH= 1 docs* - Мета-порты для документации FreeBSD. + Мета-порты для документации &os;. @@ -1902,7 +1952,7 @@ PORTEPOCH= 1 ports-mgmt Порты для управления, установки и разработки - портов и пакетов FreeBSD. + портов и пакетов &os;. @@ -2158,7 +2208,9 @@ PORTEPOCH= 1 Порты, устанавливающие загружаемые модули ядра, должны содержать виртуальную категорию kld в - строке CATEGORIES. + строке CATEGORIES. Это одно из действий, + выполняемых автоматически с добавлением + kmod в строке USES. @@ -2694,7 +2746,7 @@ EXTRACT_ONLY= source.tar.gz В последующих разделах информация будет даваться вместе с - реализацией этой идеи во FreeBSD. Мы несколько улучшили концепцию + реализацией этой идеи во &os;. Мы несколько улучшили концепцию OpenBSD. @@ -3358,9 +3410,9 @@ ALWAYS_KEEP_DISTFILES= yes Старайтесь делать строку COMMENT длиной не больше, чем 70 - символов, так как эта строка будет использована программой - &man.pkg.info.1; для отображения однострочного описания - порта; + символов, так как эта строка будет использована командой + pkg info (см. &man.pkg-info.8;) для + отображения однострочного описания порта; @@ -3442,7 +3494,7 @@ ALWAYS_KEEP_DISTFILES= yes Когда URL, в которых указаны доступные версии, отличаются от URL их загрузки. Например, чтобы привязать проверку новых версий дистрибутивных файлов к странице загрузки для порта - databases/pgtune, + databases/pgtune, добавьте: PORTSCOUT= site:http://pgfoundry.org/frs/?group_id=1000416 @@ -3482,9 +3534,10 @@ ALWAYS_KEEP_DISTFILES= yes отсутствует. Зависимость проверяется дважды, один раз внутри цели - extract, а затем из цели + build, а затем из цели install. Кроме того, имя зависимости - помещается в пакет, так что &man.pkg.add.1; будет + помещается в пакет, так что pkg install + (см. &man.pkg-install.8;) будет автоматически её устанавливать, если её нет на пользовательской системе. @@ -3537,7 +3590,8 @@ ALWAYS_KEEP_DISTFILES= yes Зависимость проверяется внутри цели install. Кроме того, имя зависимости - помещается в пакет, так что программа &man.pkg.add.1; + помещается в пакет, так что pkg install + (см. &man.pkg-install.8;) будет автоматически его устанавливать, если он не будет найден в пользовательской системе. Часть target может быть опущена, если она @@ -3562,7 +3616,7 @@ ALWAYS_KEEP_DISTFILES= yes которые обрабатываются в ports/Mk/bsd.*.mk для пополнения первоначальных зависимостей построения. Например, USES= gmake добавляет - devel/gmake в + devel/gmake в BUILD_DEPENDS. Для предотвращения загрязнения RUN_DEPENDS подобными дополнительными зависимостями проявляйте осторожность с присвоением с раскрытием, @@ -3675,15 +3729,15 @@ ALWAYS_KEEP_DISTFILES= yes <varname>USES</varname> - Существует несколько параметров для определения различных - видов характерных особенностей и зависимостей, которыми - обладает рассматриваемый порт. Они могут быть указаны путём - добавления следующей строки в Makefile - порта: + Могут быть добавлены параметры для определения различных + характерных особенностей и зависимостей, которыми + обладает данный порт. Они указываются путём добавления + в Makefile этой строки: USES= feature[:arguments] - Для получения полного списка значений смотрите . + Для получения полного списка значений смотрите + . Значение USES нельзя присваивать @@ -3855,7 +3909,7 @@ ALWAYS_KEEP_DISTFILES= yes Технология построения портов не защищена от зацикленных зависимостей. Если вы создадите такую, то у кого-нибудь и - где-нибудь установка FreeBSD будет немедленно сломана, а у остальных + где-нибудь установка &os; будет немедленно сломана, а у остальных сломается несколько позже. Это на самом деле очень трудно распознать; если вы сомневаетесь, то перед внесением изменений проверьте, что выполнили следующее: cd /usr/ports; make @@ -3880,7 +3934,7 @@ ALWAYS_KEEP_DISTFILES= yes .include <bsd.port.pre.mk> .if exists(${LOCALBASE}/bin/foo) -LIB_DEPENDS= bar:${PORTSDIR}/foo/bar +LIB_DEPENDS= libbar.so:${PORTSDIR}/foo/bar .endif @@ -3904,7 +3958,7 @@ BAR_DESC= Bar support .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MBAR} -LIB_DEPENDS= bar:${PORTSDIR}/foo/bar +LIB_DEPENDS= libbar.so:${PORTSDIR}/foo/bar .endif @@ -3936,7 +3990,8 @@ LIB_DEPENDS= bar:${PORTSDIR}/foo/bar В некоторых случаях для большего контроля над зависимостями используются переменные WANT_, которые позволяют указывать требования в более точной форме. - Например, взгляните на порт mail/squirrelmail. Этому порту + Например, взгляните на порт + mail/squirrelmail. Этому порту нужны несколько модулей PHP, которые перечислены в переменной USE_PHP: @@ -3948,8 +4003,8 @@ LIB_DEPENDS= bar:${PORTSDIR}/foo/bar WANT_PHP_WEB= yes Имеющиеся переменные USE_ и - WANT_ определены в файлах - /usr/ports/Mk. + WANT_ определены в файлах в + /usr/ports/Mk. @@ -3989,7 +4044,7 @@ RESOLUTION?= 300 .endif - Порт japanese/xdvi300 содержит + Порт japanese/xdvi300 содержит также все обычные патчи, файлы для пакета и так далее. Если вы введете здесь команду make, она возьмет в качестве разрешения значение по умолчанию (300) и построит порт обычным образом. @@ -4017,98 +4072,14 @@ MASTERDIR= ${.CURDIR}/../xdvi300 Страницы Справочника - Переменные MAN[1-9LN] автоматически добавят любые - страницы Справочника к файлу pkg-plist (это - означает, что вам не нужно указывать страницы - Справочника в файле pkg-plist—обратитесь к - главе о генерации файла PLIST для - получения более подробной информации). Это также позволяет на этапе - установки автоматически упаковывать и распаковывать страницы - Справочника в зависимости от значения переменной - NO_MANCOMPRESS в файле - /etc/make.conf. - - Если ваш порт пытается задать несколько имен для страниц - Справочника при помощи символических или жестких ссылок, то вы должны - использовать переменную MLINKS, чтобы указать на - это. Ссылка, установленная вашим портом, будет уничтожена и создана - заново сценарием bsd.port.mk для проверки того, - что она указывает на правильный файл. Любые страницы Справочника, - перечисленные в переменной MLINKS, не должны фигурировать в файле - pkg-plist. - - Для указания того, что страницы Справочника нужно сжимать во - время установки, используйте переменную - MANCOMPRESSED. Эта переменная может принимать три - значения - yes, no и - maybe. yes означает, что - страницы Справочника устанавливаются уже сжатыми, no - означает, что они не сжимаются и maybe означает, что - программное обеспечение принимает во внимание значение переменной - NO_MANCOMPRESS, так что сценарию - bsd.port.mk ничего дополнительно делать не - нужно. - Если ваш порт определяет корнем для файлов Справочника каталог, отличный от PREFIX, вы можете использовать - переменную MANPREFIX, чтобы задать его явно. Кроме - того, если страницы только некоторых разделов помещаются в - нестандартное место, например, в случае портов модулей языка - perl Perl, вы можете установить маршруты к справочным - страницам индивидуально, при помощи - MANsectPREFIX (где - sect принимает значения - 1-9, L или - N). - - Если страницы Справочника помещаются в подкаталоги, соответствующие - некоторому языку, то задайте название языка языка в переменной - MANLANG. Значение этой переменной по умолчанию - равно "" (то есть только английский язык). - *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 11:36:41 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91A6975E; Sat, 22 Feb 2014 11:36:41 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7DB671E31; Sat, 22 Feb 2014 11:36:41 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1MBafMt017292; Sat, 22 Feb 2014 11:36:41 GMT (envelope-from brueffer@svn.freebsd.org) Received: (from brueffer@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1MBaf8o017291; Sat, 22 Feb 2014 11:36:41 GMT (envelope-from brueffer@svn.freebsd.org) Message-Id: <201402221136.s1MBaf8o017291@svn.freebsd.org> From: Christian Brueffer Date: Sat, 22 Feb 2014 11:36:41 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44028 - head/share/xml X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 11:36:41 -0000 Author: brueffer Date: Sat Feb 22 11:36:40 2014 New Revision: 44028 URL: http://svnweb.freebsd.org/changeset/doc/44028 Log: Add Host1.no to the ISP list. PR: 184031 Submitted by: Eivind Bulle Haanaes Modified: head/share/xml/commercial.isp.xml Modified: head/share/xml/commercial.isp.xml ============================================================================== --- head/share/xml/commercial.isp.xml Sat Feb 22 10:29:12 2014 (r44027) +++ head/share/xml/commercial.isp.xml Sat Feb 22 11:36:40 2014 (r44028) @@ -1247,4 +1247,15 @@ Foundation. + + + Host1 + https://host1.no/ + + Host1.no has been providing hosting, domains and servers from Norway + since 2009. We offer FreeBSD virtual servers and dedicated servers. + We also offer FreeBSD on VMs in our Elastic Cloud. All our servers + come with native IPv6. + + From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 12:30:12 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 158D5EA6; Sat, 22 Feb 2014 12:30:12 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F04B812CE; Sat, 22 Feb 2014 12:30:11 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1MCUB0D037864; Sat, 22 Feb 2014 12:30:11 GMT (envelope-from pluknet@svn.freebsd.org) Received: (from pluknet@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1MCUB3Z037858; Sat, 22 Feb 2014 12:30:11 GMT (envelope-from pluknet@svn.freebsd.org) Message-Id: <201402221230.s1MCUB3Z037858@svn.freebsd.org> From: Sergey Kandaurov Date: Sat, 22 Feb 2014 12:30:11 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44029 - in head/ru_RU.KOI8-R/books/porters-handbook: . appendices keeping-up makefiles new-port pkg-files plist porting-dads porting-samplem porting-why quick-porting security slow-por... X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 12:30:12 -0000 Author: pluknet Date: Sat Feb 22 12:30:10 2014 New Revision: 44029 URL: http://svnweb.freebsd.org/changeset/doc/44029 Log: MFen r43840 et al. Break the porters handbook out into individual chapters. Added: head/ru_RU.KOI8-R/books/porters-handbook/appendices/ head/ru_RU.KOI8-R/books/porters-handbook/appendices/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/appendices/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/chapters.ent (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/keeping-up/ head/ru_RU.KOI8-R/books/porters-handbook/keeping-up/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/keeping-up/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/makefiles/ head/ru_RU.KOI8-R/books/porters-handbook/makefiles/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/makefiles/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/new-port/ head/ru_RU.KOI8-R/books/porters-handbook/new-port/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/new-port/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/pkg-files/ head/ru_RU.KOI8-R/books/porters-handbook/pkg-files/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/pkg-files/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/plist/ head/ru_RU.KOI8-R/books/porters-handbook/plist/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/plist/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/porting-dads/ head/ru_RU.KOI8-R/books/porters-handbook/porting-dads/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/porting-dads/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/porting-samplem/ head/ru_RU.KOI8-R/books/porters-handbook/porting-samplem/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/porting-samplem/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/porting-why/ head/ru_RU.KOI8-R/books/porters-handbook/porting-why/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/porting-why/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/quick-porting/ head/ru_RU.KOI8-R/books/porters-handbook/quick-porting/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/quick-porting/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/security/ head/ru_RU.KOI8-R/books/porters-handbook/security/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/security/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/slow-porting/ head/ru_RU.KOI8-R/books/porters-handbook/slow-porting/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/slow-porting/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/special/ head/ru_RU.KOI8-R/books/porters-handbook/special/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/special/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/testing/ head/ru_RU.KOI8-R/books/porters-handbook/testing/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/testing/chapter.xml (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/upgrading/ head/ru_RU.KOI8-R/books/porters-handbook/upgrading/Makefile (contents, props changed) head/ru_RU.KOI8-R/books/porters-handbook/upgrading/chapter.xml (contents, props changed) Modified: head/ru_RU.KOI8-R/books/porters-handbook/Makefile head/ru_RU.KOI8-R/books/porters-handbook/book.xml head/ru_RU.KOI8-R/books/porters-handbook/uses.xml Modified: head/ru_RU.KOI8-R/books/porters-handbook/Makefile ============================================================================== --- head/ru_RU.KOI8-R/books/porters-handbook/Makefile Sat Feb 22 11:36:40 2014 (r44028) +++ head/ru_RU.KOI8-R/books/porters-handbook/Makefile Sat Feb 22 12:30:10 2014 (r44029) @@ -4,7 +4,7 @@ # $FreeBSD$ # $FreeBSDru: frdp/doc/ru_RU.KOI8-R/books/porters-handbook/Makefile,v 1.7 2003/09/26 02:34:16 andy Exp $ # -# Original revision: r42686 +# Original revision: r43849 # # @@ -27,6 +27,21 @@ INSTALL_ONLY_COMPRESSED?= # XML content SRCS= book.xml +SRCS+= porting-why/chapter.xml +SRCS+= new-port/chapter.xml +SRCS+= quick-porting/chapter.xml +SRCS+= slow-porting/chapter.xml +SRCS+= makefiles/chapter.xml +SRCS+= special/chapter.xml +SRCS+= plist/chapter.xml +SRCS+= pkg-files/chapter.xml +SRCS+= testing/chapter.xml +SRCS+= upgrading/chapter.xml +SRCS+= security/chapter.xml +SRCS+= porting-dads/chapter.xml +SRCS+= porting-samplem/chapter.xml +SRCS+= keeping-up/chapter.xml +SRCS+= appendices/chapter.xml SRCS+= uses.xml SRCS+= versions.xml @@ -55,4 +70,14 @@ IMAGES_LIB+= callouts/21.png DOC_PREFIX?= ${.CURDIR}/../../.. +# Entities +SRCS+= chapters.ent + +SYMLINKS= ${DESTDIR} index.html handbook.html + +# Turn on all the chapters. +CHAPTERS?= ${SRCS:M*chapter.xml} + +XMLFLAGS+= ${CHAPTERS:S/\/chapter.xml//:S/^/-i chap./} + .include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/ru_RU.KOI8-R/books/porters-handbook/appendices/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/ru_RU.KOI8-R/books/porters-handbook/appendices/Makefile Sat Feb 22 12:30:10 2014 (r44029) @@ -0,0 +1,17 @@ +# +# Build the Porters Handbook with just the content from this chapter. +# +# $FreeBSD$ +# +# Original revision: r43840 +# + +CHAPTERS= appendices/chapter.xml + +VPATH= .. + +MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} + +DOC_PREFIX?= ${.CURDIR}/../../../.. + +.include "../Makefile" Added: head/ru_RU.KOI8-R/books/porters-handbook/appendices/chapter.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/ru_RU.KOI8-R/books/porters-handbook/appendices/chapter.xml Sat Feb 22 12:30:10 2014 (r44029) @@ -0,0 +1,73 @@ + + + + + + Приложения + + + Значения <varname>USES</varname> + + + Значения <varname>USES</varname> + + + + + Наименование + Аргументы + Описание + + + + &values.uses; + + +
+ + + + Значения <literal>__FreeBSD_version</literal> + + Ниже для справки приводится перечень значений + __FreeBSD_version в виде, который определён в + sys/param.h: + + + Значения <literal>__FreeBSD_version</literal> + + + + + Значение + Дата + Релиз + + + + + &values.versions; + + +
+ + + Заметьте, что 2.2-STABLE иногда идентифицирует себя как + 2.2.5-STABLE после 2.2.5-RELEASE. Такой принцип + использовался год и месяц, но мы решили изменить его на более + однозначную систему нумерации старший/младший, начиная с версии + 2.2. Это объясняется тем, что параллельная разработка в нескольких + ветках делает непрактичным идентификацию релизов просто по их + реальным датам выпуска. Если вы сейчас делаете порт, вам не стоит + заботиться о старых версиях -CURRENT; они перечислены здесь просто + в информационных целях. + + + + Modified: head/ru_RU.KOI8-R/books/porters-handbook/book.xml ============================================================================== --- head/ru_RU.KOI8-R/books/porters-handbook/book.xml Sat Feb 22 11:36:40 2014 (r44028) +++ head/ru_RU.KOI8-R/books/porters-handbook/book.xml Sat Feb 22 12:30:10 2014 (r44029) @@ -3,16 +3,20 @@ "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd" [ -]> + + +%chapters; +]> + @@ -59,12671 +63,19 @@ $FreeBSD$ - - Введение - - Коллекция портов &os; является способом, используемым - практически каждым для установки приложений ("портов") на &os;. - Как и почти всё остальное во &os;, эта система в основном является - добровольно поддерживаемым начинанием. Важно иметь это в виду при - чтении данного документа. - - Во &os; каждый может прислать новый порт либо изъявить желание - поддерживать существующий порт, если его никто ещё никто не - поддерживает—вам не нужно иметь никаких особых привилегий на - внесение изменений, чтобы это делать. - - - - Как самому сделать новый порт - - Итак, вы интересуетесь, как создать собственный порт или - обновить существующий? Великолепно! - - Ниже находятся некоторые указания по созданию нового порта для - &os;. Если вы хотите обновить существующий порт, вы должны - прочесть их, а затем . - - Если этот документ недостаточно подробен, вы должны обратиться к - файлу /usr/ports/Mk/bsd.port.mk, который - включается в make-файл каждого порта. Он хорошо прокомментирован, и - даже если вы не занимаетесь хакингом make-файлов каждодневно, из него - вы сможете узнать много нового. Кроме того, конкретные вопросы можно - задать, послав письмо на адрес &a.ports;. - - - Только часть переменных - (VAR), которые могут быть - переопределены, описаны в этом документе. Большинство (если не все) - описаны в начале файла /usr/ports/Mk/bsd.port.mk; - остальные, скорее всего, тоже там описаны. Заметьте, что - в этом файле используется нестандартная настройка шага табуляции: - Emacs и Vim - должны распознать это при загрузке файла. Как &man.vi.1;, - так и &man.ex.1; могут быть настроены на использование - правильного значения выдачей команды :set tabstop=4 - после загрузки файла. - - - - Ищете, с чего бы начать попроще? Посмотрите на перечень запрошенных - портов, есть ли там такие, над которыми вы можете работать. - - - - - Быстрое портирование - - В этом разделе описано, как создать новый порт на скорую руку. - Во многих случаях этого бывает не достаточно, так что вам нужно будет - прочитать документ дальше. - - Во-первых, скачайте оригинальный tar-файл и поместите его в каталог - DISTDIR, который по умолчанию есть не что иное, как - /usr/ports/distfiles. - - - Здесь предполагается, что программное обеспечение компилируется - без проблем как есть, то есть для работы приложения на вашей системе - &os; не потребовалось абсолютно никаких изменений. Если - требовалось что-то изменить, то вам придется обратиться также и к - следующему разделу. - - - - Перед началом портирования рекомендуется установить - переменную &man.make.1; DEVELOPER в - /etc/make.conf. - - &prompt.root; echo DEVELOPER=yes >> /etc/make.conf - - Эта настройка включает режим разработчика, - в котором отображаются предупреждения при использовании - устаревших конструкций и задействуются некоторые дополнительные - проверки при вызове команды make. - - - - Создание файла <filename>Makefile</filename> - - Минимальный Makefile будет выглядеть - примерно так: - - # $FreeBSD$ - -PORTNAME= oneko -PORTVERSION= 1.1b -CATEGORIES= games -MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ - -MAINTAINER= youremail@example.com -COMMENT= Cat chasing a mouse all over the screen - -.include <bsd.port.mk> - - - В некоторых случаях в заголовке Makefile - существующего порта могут содержаться дополнительные строки, - такие как название порта и дата его создания. - Эта дополнительная информация была объявлена устаревшей - и находится в процессе удаления. - - - Посмотрим, сможете ли вы его понять. Не обращайте внимание на - содержимое строчки $FreeBSD$, она - будет заполнена автоматически системой - Subversion, когда порт будет - импортирован в наше дерево портов. Вы можете найти более подробный - пример в разделе пример - Makefile. - - - - Создание информационных файлов - - Имеется два информационных файла, которые требуются для любого - порта, вне зависимости от того, является ли он пакетом или нет. Это - pkg-descr и pkg-plist. - Префикс pkg- отличает их от других файлов. - - - <filename>pkg-descr</filename> - - Это более подробное краткое описание порта. От одного до - нескольких абзацев, кратко описывающих, что представляет собой - порт, будет достаточно. - - - Это не руководство и не подробнейшее - описание того, как использовать или компилировать порт! - Пожалуйста, будьте внимательны при копировании текста - из README или страниц - справочника; слишком часто они не являются кратким - описанием порта или имеют неудобный формат (например, страницы - справочника выровнены пробелами, что особенно плохо - смотрится с моноширинными шрифтами). - - - Хорошо составленный pkg-descr - описывает порт достаточно полно, чтобы пользователю не - приходилось сверяться с документацией или посещать вебсайт - для понимания того, что делает данное программное обеспечение, - чем оно может быть полезно или какие хорошие функции у него - имеются. Упоминание про определённые требования, такие как - используемый графический инструментарий, тяжёлые зависимости, - окружение для запуска или используемый язык программирования - помогут пользователям определиться, будет ли этот порт для - них работать. - - Включите сюда URL официальной домашней страницы Интернет. - Перед одним из сайтов (выберите основной) - добавьте WWW: (с последующим единичным - пробелом) для того, чтобы вспомогательные утилиты работали - правильно. Если URI является корнем сайта или каталогом, - то значение должно быть дополнено косой чертой. - - - Если указанная для порта веб-страница не доступна, - попытайтесь сперва поискать, был ли официальный сайт - перемещён, переименован или размещён в другом месте. - - - Следующий пример показывает, как должен выглядеть ваш - pkg-descr: - - This is a port of oneko, in which a cat chases a poor mouse all over -the screen. - : -(etc.) - -WWW: http://www.oneko.org/ - - - - <filename>pkg-plist</filename> - - Здесь перечисляются все файлы, устанавливаемые портом. Его - также называют списком для упаковки, потому что - пакет генерируется упаковкой файлов, которые здесь указаны. - Имена путей указываются относительно установочного префикса - (обычно /usr/local). - Если порт во время установки создает каталоги, убедитесь, - что добавлены строки @dirrm для удаления - каталогов при удалении пакета. - - Вот маленький пример: - - bin/oneko -man/man1/oneko.1.gz -lib/X11/app-defaults/Oneko -lib/X11/oneko/cat1.xpm -lib/X11/oneko/cat2.xpm -lib/X11/oneko/mouse.xpm -@dirrm lib/X11/oneko - - Обратитесь к странице справочной системы по команде - &man.pkg-create.8; с подробным описанием формата списка - упаковки. - - - Рекомендуется, чтобы имена файлов в этом списке были - отсортированы в алфавитном порядке. Это позволит значительно - облегчить сверку изменений при обновлении порта. - - - - Создание списка упаковки вручную может оказаться весьма - трудоёмкой задачей. Если порт устанавливает большое количество - файлов, раздел об автоматическом построении списка - упаковки может помочь сэкономить время. - - - Существует только одно исключение, когда у порта может - отсутствовать pkg-plist. Если порт - устанавливает лишь несколько файлов, а возможно, и каталогов, то - они могут быть перечислены в переменных - PLIST_FILES и PLIST_DIRS, - соответственно, внутри файла Makefile порта. - К примеру, мы можем обойтись без файла - pkg-plist у приведённого выше порта - oneko, добавив следующие строки в - Makefile: - - PLIST_FILES= bin/oneko \ - man/man1/oneko.1.gz \ - lib/X11/app-defaults/Oneko \ - lib/X11/oneko/cat1.xpm \ - lib/X11/oneko/cat2.xpm \ - lib/X11/oneko/mouse.xpm -PLIST_DIRS= lib/X11/oneko - - Конечно, переменная PLIST_DIRS не должна - задаваться, если порт не устанавливает никаких каталогов. - - - Несколько портов могут совместно использовать общий - каталог. В этом случае PLIST_DIRS - следует заменить на PLIST_DIRSTRY, так - чтобы каталог удалялся только если он пуст, а иначе - игнорировался. Использование PLIST_DIRS - и PLIST_DIRSTRY аналогично - @dirrm и @dirrmtry - в pkg-plist, описание которых - входит в . - - - Обратной стороной такого способа перечисления файлов и - каталогов порта является невозможность использования - последовательностей команд, описанных в &man.pkg-create.8;. - Поэтому он подходит для простых портов, что делает их ещё более - простыми. Одновременно с этим положительным моментом является - уменьшение количества файлов в коллекции портов. Пожалуйста, - подумайте над использованием этой техники, прежде чем создавать - pkg-plist. - - Далее мы увидим, как можно использовать файлы - pkg-plist и PLIST_FILES - выполнения более сложных - задач. - - - - - Создание файла с контрольной суммой - - Просто введите команду make makesum. - Правила утилиты make автоматически сгенерируют файл - distinfo. - - Если у извлекаемого файла регулярно меняется контрольная - сумма и вы не сомневаетесь в надежности источника (т.е. он получен - из CD производителя, либо ежедневно обновляется документация), то вы - должны указать эти файлы в переменной IGNOREFILES. - Тогда контрольная сумма при выполнении make makesum - для этого файла создаваться не будет, а вместо этого для него будет - установлено значение IGNORE. - - - - Тестирование порта - - Вы должны удостовериться, что правила построения порта выполняют - именно то, что вы хотите, включая создание пакета для порта. Вот - те важные вещи, которые вы должны проверить. - - - - pkg-plist не содержит ничего сверх того, - что устанавливается портом - - - - pkg-plist содержит абсолютно все, что - устанавливается портом - - - - Порт может быть установлен с помощью - указания цели install. Это - позволяет убедиться в правильной работе сценария - установки. - - - - Порт может быть правильным образом удалён с помощью - указания цели deinstall. Это - позволяет убедиться в правильной работе сценария - удаления. - - - - Следует убедиться, что make package - можно запустить из-под обычного пользователя (то есть, - не из-под root). - Если это не так, в Makefile порта - должно быть добавлено NEED_ROOT=yes. - - - - - Рекомендуемый порядок проверки - - - make stage - - - - make check-orphans - - - - make package - - - - make install - - - - make deinstall - - - - pkg add package-filename - - - - make package (из-под - пользователя) - - - - Убедитесь, что на любом из этапов не выдается никаких - предупреждений. - - Основательное автоматизированное тестирование может быть - выполнено при помощи - ports-mgmt/tinderbox или - ports-mgmt/poudriere из Коллекции - Портов. Эти приложения используют jails, - в которых проверяются все перечисленные выше этапы без - изменения состояния основной системы. - - - - Проверка вашего порта утилитой - <command>portlint</command> - - Будьте добры, пользуйтесь утилитой portlint - для проверки того, что ваш порт соответствует нашим рекомендациям. - Программа ports-mgmt/portlint - является частью Коллекции - Портов. В частности, вы можете захотеть проверить, правильно ли - сформирован файл Makefile и - соответствующим ли образом именован пакет. - - - - Посылка нового порта - - Перед посылкой нового порта прочитайте раздел о том, что - можно и нельзя делать. - - Когда вы наконец довольны своим первым портом, единственное, - что осталось сделать, это включить его в основное дерево портов - &os; и осчастливить этим всех остальных. Нам не нужен ни - каталог work, ни пакет - pkgname.tgz, так что удалите их прямо - сейчас. - - Затем получите файл &man.shar.1;. Предполагая, что порт - называется oneko, перейдите в каталог выше, где находится - каталог oneko, и наберите: - shar `find oneko` > oneko.shar - - Включите oneko.shar в сообщение об - ошибке и пошлите его с помощью &man.send-pr.1;. Обратитесь к - разделу - Сообщения об ошибках и общие замечания для получения - подробной информации о &man.send-pr.1;). - - Укажите в сообщении категорию ports и - класс change-request. - Не указывайте, что сообщение имеет статус - confidential! Добавьте краткое описание - программы в поле Description отправляемого PR - (например, содержимое COMMENT в сокращённом - варианте) и сам файл в виде архива .shar - в поле Fix. - - - Хорошее описание в заголовке сообщения о проблеме - значительно облегчает работу коммиттеров портов. Для новых - портов мы предпочитаем нечто вроде New port: - <категория>/<название порта> <краткое - описание порта>. Следование этой схеме - упрощает и ускоряет начало работы по добавлению нового - порта. - - - Повторим ещё раз, что не нужно включать ни оригинальный - файл с дистрибутивом, ни каталог work, - ни пакет, построенный вами командой - make package; для новых портов - используйте &man.shar.1;, но не &man.diff.1;. - - После отправки порта, пожалуйста, потерпите. Время, - необходимое для включения нового порта во &os;, может занимать - от нескольких дней до нескольких месяцев. - Здесь можно увидеть список ожидающих PR для портов. - - После рассмотрения нового порта мы при необходимости вам - ответим, а затем включим порт в наше дерево. Ваше имя также - будет добавлено в список - Дополнительных контрибуторов проекта &os; и другие - файлы. - - - - - Медленное портирование - - Итак, все оказалось не так уж и просто, и порт потребовал - некоторых модификаций для того, чтобы заставить его работать. В этом - разделе мы расскажем, шаг за шагом, как его модифицировать, чтобы он - работал с нашей системой портов. - - - Как всё это работает - - Во-первых, когда пользователь дает в своем каталоге с портом - команду make, происходит целая череда событий. - Во время чтения этого текста может оказаться полезным иметь файл - bsd.port.mk открытым в другом окне, что сильно - поможет в их понимании. - - Но не волнуйтесь сильно, если вы не до конца понимаете, что - делается в bsd.port.mk, не так уж много людей - его понимает... :-> - - - - Запускается цель fetch. Цель - fetch отвечает за то, что архив исходных - текстов имеется в наличии локально в каталоге - DISTDIR. Если цель - fetch не может найти требуемые файлы в - каталоге DISTDIR, то они будут искаться по - указателю URL MASTER_SITES, который - устанавливается в Makefile, а также на наших FTP зеркалах, - куда мы по возможности помещаем дистрибутивные файлы для архива. - Затем она попытается сгрузить указанный файл с помощью - FETCH, полагая, что запрашивающая машина имеет - прямое подключение к Интернет. Если файл скачается удачно, то - он будет помещен в каталог DISTDIR для - последующего использования и обработки. - - - - Выполняется цель extract. Она ищет - дистрибутивный файл порта (как правило, tar-архив - gzip) в - каталоге DISTDIR и распаковывает его во - временный каталог, задаваемый переменной - WRKDIR (по умолчанию - work). - - - - Выполняется цель patch. Во-первых, - применяются все патчи, заданные переменной - PATCHFILES. Во-вторых, если какие-либо файлы с - патчами, носящие имена - patch-*, имеются в - подкаталоге PATCHDIR (по умолчанию это каталог - files), то они применяются в этот момент в - алфавитном порядке. - - - - Запускается цель configure. Здесь - может выполняться любая из многих различных вещей. - - - - Если существует скрипт - scripts/configure, то он запускается. - - - - - Если задана переменная HAS_CONFIGURE - или GNU_CONFIGURE, то запускается скрипт - WRKSRC/configure. - - - - - - - Выполняется цель build. Она - отвечает за переход в собственный рабочий каталог порта - (WRKSRC) и его построение. - - - - Выполняется цель stage. - Конечный набор построенных файлов помещается во временный - каталог (STAGEDIR, смотрите - ). Иерархия этого - каталога отражает иерархию каталогов системы, в которую - данный пакет будет устанавливаться. - - - - Выполняется цель install. - В систему копируются файлы, перечисленные в pkg-plist - порта. - - - - Выше перечислены стандартные действия. Кроме того, вы сами - можете определить цели - pre-что-то или - post-что-то, - или создать скрипты с такими именами в подкаталоге - scripts, и они будут запущены до или после - выполнения действий по умолчанию. - - Например, если у вас есть цель - post-extract, определённая в вашем файле - Makefile и файл pre-build в - подкаталоге - scripts, то после выполнения обычных действий по - распаковке, будет вызвана цель post-extract - а скрипт pre-build будет выполнен перед - запуском стандартных правил построения. Рекомендуется использовать - цели из Makefile, если действия достаточно - просты, потому что в дальнейшем будет проще определить, какие - нестандартные действия требует порт. - - Действия по умолчанию выполняются целями - do-что-то из - bsd.port.mk. Например, команды для - распаковки порта находятся в цели - do-extract. Если вам не хватает цели по - умолчанию, вы можете ее исправить, переопределив цель - do-something - в вашем файле Makefile. - - - Основные цели (к примеру, - extract, configure - и так далее) не делают ничего больше, - чем проверяют успешность завершения всех предыдущих шагов и - вызывают настоящие цели или скрипты, и их не нужно менять. Если - вам нужно изменить распаковку, исправляйте - do-extract, но никогда не меняйте способ - работы extract! Кроме того, цель - post-deinstall является недействительной - и не выполняется инфраструктурой портов. - - - Теперь, когда вы представляете, что происходит, когда - пользователь набирает команду make install, - давайте пройдемся - через шаги, рекомендуемые для создания настоящего порта. - - - - Получение исходного кода - - Получите оригинальные исходные тексты (обычно) в виде - упакованного tar-архива - (foo.tar.gz или - foo.tar.bz2) - и скопируйте его в каталог DISTDIR. Всегда - используйте исходные тексты основной ветки - разработки везде, где это возможно. - - Вам потребуется задать значение переменной - MASTER_SITES так, чтобы оно указывало на - местоположение оригинального tar-архива. В файле - bsd.sites.mk вы найдёте краткие обозначения - для большинства популярных сайтов. Пожалуйста, используйте эти - сайты—и соответствующие определения—везде, где это - возможно, чтобы избежать проблем повторения одной и той же информации - в базе источников. Так как эти сайты со временем меняются, для - всех причастных поддержка становится настоящим кошмаром. - - Если вы не можете найти FTP/HTTP сайт с хорошим подключением к - сети, или находите только сайты, которые имеют раздражающе - нестандартные форматы, то можете захотеть поместить копию на надежный - сервер FTP или HTTP, который вам доступен (например, ваша домашняя - страница). - - Если вы не можете найти доступного и надёжного места для - помещения дистрибутивного файла, то мы сами сможем разместить его на - сервере ftp.FreeBSD.org; однако это наименее - рекомендуемое решение. Дистрибутивный файл должен - быть помещён в каталог ~/public_distfiles/ - одного из пользователей машины freefall. Попросите - того, кто коммиттил ваш порт, сделать это. Этот человек также задаст - переменной MASTER_SITES значение - MASTER_SITE_LOCAL, а в переменной - MASTER_SITE_SUBDIR укажет своё имя пользователя - с машины freefall. - - Если дистрибутивные файлы вашего порта постоянно меняются по - неизвестным причинам без изменения версий со стороны автора, остаётся - только поместить дистрибутив на вашу домашнюю Web-страницу и указать - её первой в списке MASTER_SITES. Если можете, - попытайтесь договориться с автором порта об этом; это действительно - помогает в достижении некоторого управления исходным кодом. - Размещение собственной версии поможет избежать появления ошибок у - пользователей типа checksum mismatch, а - также уменьшит нагрузку на людей, сопровождающих наш FTP-сервер. - Также, если у порта имеется только один основной сервер, то - рекомендуется поместить архивную копию на свой сайт и указать его в - списке MASTER_SITES вторым. - - Если вашему порту требуются дополнительные `патчи', доступные - в Интернет, скачайте также и их, поместив в каталог - DISTDIR. Не волнуйтесь, если они находятся не - на том же сайте, откуда взят дистрибутивный архив, мы умеем - обрабатывать такие ситуации (смотрите описание PATCHFILES ниже). - - - - Модификация порта - - Распакуйте копию дистрибутивного файла в отдельный каталог и - внесите изменения, которые необходимы для того, чтобы порт - компилировался нормально в текущей версии &os;. - Тщательно отслеживайте все, что вы делаете, - этот процесс вам предстоит автоматизировать. Все, включая удаление, - добавление или модификацию в файлах должны будут выполняться - автоматически с помощью скриптов или файлов патчей, когда вы - завершите работу над портом. - - Если вашему порту во время компиляции, установки и настройки - требуется довольно много взаимодействовать с пользователем, то - посмотрите на один из классических скриптов - Configure Лэрри Уолла (Larry Wall) и - сделайте сами что-либо подобное. Предназначение новой коллекции - портов - это сделать каждое приложение в стиле - plug-and-play настолько, насколько это вообще возможно - для конечного пользователя при минимальном использовании дискового - пространства. - - - Если явно не указано обратное, то патчи, скрипты и другие - файлы, которые вы создали и предоставили для Коллекции Портов - &os;, неявно подпадают под стандартные условия лицензии - BSD. - - - - - Создание патчей - - Файлы, которые добавлялись или изменялись в процессе создания - порта, могут быть выявлены программой &man.diff.1;, - а результат работы этой программы может быть в дальнейшем передан - программе &man.patch.1;. Такое действие с обычным файлом - подразумевает сохранение копии файла с первоначальным содержимым - перед внесением каких-либо изменений. - - &prompt.user; cp file file.orig - - Патчи сохраняются в виде файлов с именем - patch-*, где - * обозначает путь к файлу, - к которому применяется патч, такой как - patch-Imakefile или - patch-src-config.h. - - После того как файл был изменён, используется &man.diff.1; - для получения разницы между первоначальной и изменённой - версиями. Параметр указывает &man.diff.1; - выводить разницу в унифицированном формате, - который также является предпочтительным. - - &prompt.user; diff -u file.orig file > patch-pathname-file - - Для порождении патчей для новых добавляемых файлов - используется параметр , который заставляет - &man.diff.1; трактовать несуществующие прежде файлы как если - бы они существовали, но имели пустое содержимое: - - &prompt.user; diff -u -N newfile.orig newfile > patch-pathname-newfile - - Файлы с патчами помещаются в - каталоге PATCHDIR - (как правило, это files/), - откуда они будут взяты автоматически. Все патчи обязаны быть сделаны - относительно каталога WRKSRC (как правило, - это каталог, в который распаковывается исходный архив и где будет - выполняться построение). Для упрощения внесения изменений и - обновлений избегайте наличия более чем одного патча для - одного и того же файла (например, патчей - patch-file и patch-file2, - оба меняющих файл WRKSRC/foobar.c). - Обратите внимание, что если путь к изменяемому файлу содержит символ - подчеркивания (_), то патч должен содержать в своем - имени два подчеркивания вместо одного. Например, для применения патча - на файл с именем src/freeglut_joystick.c - соответствующий патч следует назвать - patch-src-freeglut__joystick.c. - - Пожалуйста, используйте для именования патчей только символы - [-+._a-zA-Z0-9]. Не используйте любые другие - символы, кроме этих. Не называйте патчи как - patch-aa или patch-ab, - всегда ссылайтесь на путь и название файла в названиях самих - патчей. - - Существует альтернативный упрощённый способ создания - патчей для существующих файлов. Первые шаги те же самые: - создание копии неизменённого файла с расширением - .orig и внесение изменений. После этого - используйте make makepatch, чтобы обновить - файлы с патчами в каталоге files данного - порта. - - Не помещайте строки RCS в патчи. - Subversion будет изменять их при - помещении файлов в дерево портов, и когда мы будем их оттуда - извлекать, они будут уже другие, поэтому применение патчей - окончится неудачей. Строчки RCS предваряются знаком доллара - ($), и обычно начинаются с - $Id или - $RCS. - - Использование параметра рекурсии () с командой - &man.diff.1; для генерации патчей - это хорошо, но всё же, - пожалуйста, смотрите на получающиеся патчи, чтобы убедиться в - отсутствии ненужного мусора. В частности, diff-разниц между двумя - резервными копиями файлов, файлы Makefile, когда - как порт использует Imake или - GNU-версию программы configure, и так далее, - не нужны, и должны быть удалены. Если было необходимо - отредактировать файл configure.in и - запустить autoconf для перегенерации - configure, не нужно включать файлы diff для - configure (они частенько вырастают до нескольких - тысяч строк!). Вместо этого задайте - USE_AUTOTOOLS=autoconf:261 и - включите diff-файл для configure.in. - - Старайтесь минимизировать в патчах объём - нефункциональных изменений с пустыми символами. В мире Открытого - Исходного Кода является распространенным совместное использование - проектами больших объемов кодовой базы, но с различными стилями - и правилами отступов. При копировании работающей функциональной - части из одного проекта для исправления похожей области в другом, - будьте аккуратны, пожалуйста: получаемый однострочный патч - может указаться полон нефункциональных изменений. Это не только - увеличивает размер репозитория Subversion, - но также усложняет поиск того, - что конкретно вызвало проблему и что вообще поменялось. - - Если нужно удалить файл, сделайте это при выполнении цели - post-extract, вместо того чтобы - оформлять это как часть патча. - - Простые перемещения могут быть выполнены непосредственно из - Makefile порта с использованием &man.sed.1; в - режиме in-place. Это удобно, когда при изменении используется - значение переменной: - - post-patch: - @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README - - Довольно часто в исходных файлах портируемого программного - обеспечения используется конвенция CR/LF. Это может стать - причиной проблем с дальнейшей упаковкой, предупреждениями - компилятора или выполнением скриптов (таких как - /bin/sh^M not found). Для быстрого - преобразования всех файлов из CR/LF просто в LF добавьте - в Makefile порта эту запись: - - USES= dos2unix - - Может быть задан точный список преобразуемых файлов: - - USES= dos2unix -DOS2UNIX_FILES= util.c util.h - - Используйте DOS2UNIX_REGEX, чтобы - преобразовать группу файлов в разных подкаталогах. - Его параметром является регулярное выражение, совместимое с - &man.find.1;. Подробнее о формате в &man.re.format.7;. - Такой вариант удобен для преобразования всех файлов заданного - расширения. Для примера, преобразуем все исходные файлы, - не затрагивая двоичные файлы: - *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 13:41:52 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB3A8635; Sat, 22 Feb 2014 13:41:52 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 968FA18B1; Sat, 22 Feb 2014 13:41:52 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1MDfq1k069225; Sat, 22 Feb 2014 13:41:52 GMT (envelope-from ryusuke@svn.freebsd.org) Received: (from ryusuke@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1MDfq66069224; Sat, 22 Feb 2014 13:41:52 GMT (envelope-from ryusuke@svn.freebsd.org) Message-Id: <201402221341.s1MDfq66069224@svn.freebsd.org> From: Ryusuke SUZUKI Date: Sat, 22 Feb 2014 13:41:52 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44030 - head/ja_JP.eucJP/books/fdp-primer/psgml-mode X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 13:41:52 -0000 Author: ryusuke Date: Sat Feb 22 13:41:52 2014 New Revision: 44030 URL: http://svnweb.freebsd.org/changeset/doc/44030 Log: o Fix a typo. o Add single space where appropriate. Reference: [doc-jp-work 1979] Modified: head/ja_JP.eucJP/books/fdp-primer/psgml-mode/chapter.xml Modified: head/ja_JP.eucJP/books/fdp-primer/psgml-mode/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/fdp-primer/psgml-mode/chapter.xml Sat Feb 22 12:30:10 2014 (r44029) +++ head/ja_JP.eucJP/books/fdp-primer/psgml-mode/chapter.xml Sat Feb 22 13:41:52 2014 (r44030) @@ -39,9 +39,9 @@ sgml-mode ╓РмЬмя╓╧╓К ©╥╓╥╓╓╔п║╪╔╦╔Г╔С╓н Emacs ╓Д - XEmacs (Ports Collection ╓к╓╒╓Й╓ч╓╧)╓к╓о║╒ + XEmacs (Ports Collection ╓к╓╒╓Й╓ч╓╧) ╓к╓о║╒ PSGML ╓х╦ф╓п╓Л╓КхС╬О╓кйьмЬ╓й╔я╔ц╔╠║╪╔╦╓╛иМб╟╓╥╓ф╓╓╓ч╓╧║ё - ╓Ё╓Л╓оЁхд╔╩р╓╛╓х╓й╓ц╓ф╓╓╓К .xml ╓н╔у╔║╔╓╔К╓╛фи╓ъ╧Ч╓ч╓Л╓К╓╚║╒ + ╓Ё╓Л╓оЁхд╔╩р╓╛ .xml ╓н╔у╔║╔╓╔К╓╛фи╓ъ╧Ч╓ч╓Л╓К╓╚║╒ M-x sgml-mode ╓хфЧно╓╧╓К╓Ё╓х╓г╦ф╓с╫п╓╣╓Л╓ч╓╧║ё PSGML ╓о║╒SGML ╔у╔║╔╓╔К╓Д╔╗╔Л╔А╔С╔х║╒б╟ю╜╓Р╟╥╓╕╓©╓А╓н╔А╔╦╔Ц║╪╔Б║╪╔и╓г╓╧║ё From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 16:45:59 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B939F16; Sat, 22 Feb 2014 16:45:59 +0000 (UTC) Received: from mail0.glenbarber.us (mail0.glenbarber.us [208.86.227.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 021541711; Sat, 22 Feb 2014 16:45:58 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id ECCF01EFDA; Sat, 22 Feb 2014 16:45:51 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail0.glenbarber.us ECCF01EFDA Authentication-Results: mail0.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sat, 22 Feb 2014 11:45:50 -0500 From: Glen Barber To: Benjamin Kaduk Subject: Re: svn commit: r44020 - head/en_US.ISO8859-1/articles/committers-guide Message-ID: <20140222164550.GA76814@glenbarber.us> References: <201402212216.s1LMGWZv089398@svn.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: svn-doc-head@freebsd.org, svn-doc-all@freebsd.org, doc-committers@freebsd.org X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 16:45:59 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 22, 2014 at 01:51:38AM -0500, Benjamin Kaduk wrote: > On Fri, 21 Feb 2014, Glen Barber wrote: >=20 > >Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >--- head/en_US.ISO8859-1/articles/committers-guide/article.xml Fri Feb 2= 1 20:28:01 2014 (r44019) > >+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Fri Feb 2= 1 22:16:31 2014 (r44020) > >@@ -2118,9 +2106,6 @@ U stable/9/share/man/man4/netmap.4 > > In commit logs etc., rev 179872 should be > > spelled r179872 as per convention. > > > >- Do not remove and re-add the same file in a single commit > >- as this will break the CVS exporter. > >- >=20 > The last time I updated patchfiles for a new upstream release, I caught > myself removing and re-adding a file of the same name, which I went and > reverted because I remembered that there was a hook which rejected such > commits. Do we know if such a hook is still in place? (It occurs to me > that I may just be remembering the exporter breakage and maybe there never > was such a hook.) >=20 I do not see anything in svnadmin/hooks/ to reject files that were replaced. Glen --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTCNQ+AAoJELls3eqvi17QmVYQAIsKZV6AA5wmGL0TS3+CLl8j w93g/hp4DVnfjRHAtqwrBhLP4RNnSZ7YP5RVA49fbb2srYwmNfmMI29Mg9EgU9KE D+4q7tbMYFwzo3I2QsXSjPh3dh5/hxMDtBHemNjUD7dipwV+4XigjvGE6YH5MNJA 0g2xGTA9nABlnykTqzr3817Tt28+atxLVtAp1yZwU8LDa4CqKBpZAu5Gdn7/FwWA pjs6C7LixAMqchKSdHZ0cDjXhy6tw3FjBN8gw0dJ3EqYB6X9o6GekDnKCp1WpgQH B+j1E0T9umu1/XOQnQUaCBUTIFN1S2535nIiwEcnLVe1wNlU3PbCzREaSG7CFCJC OJPxtMhsjZicZVaH2tRgMkpRPizEr0duLPi4vUNjVxyqPgwG4r01tT1E5aDtjBM3 XtBZ8/h1ELly39qlYGg9jcCiI/v6iN13FBHMBIg/YSKRK/htlJKdDPoGeJgifg98 eOr9O/3zDRrAdCvSoMjXzRbGwWUMrXdYS0ZBqCmICHPzRjL6c20IjcjwFN9885Fn XMT1F/4GOvbvJ9XNhQUXaOp6n223pKTx8QtMHwj+Pi4OsoUXQgcrUFqi9JFJ7+ZV du2PxEHizwb/HDSWuyrNBc4QKt7OZNuIt/MGPPdK5bTRtDNNgT7cnNTOu2OqDxVS SHEhXdOpIRZ9kMm91A7W =JnIP -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 19:43:30 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C42695B; Sat, 22 Feb 2014 19:43:30 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 761C616EE; Sat, 22 Feb 2014 19:43:30 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1MJhUX8016171; Sat, 22 Feb 2014 19:43:30 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1MJhUVM016170; Sat, 22 Feb 2014 19:43:30 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201402221943.s1MJhUVM016170@svn.freebsd.org> From: Warren Block Date: Sat, 22 Feb 2014 19:43:30 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44031 - head/en_US.ISO8859-1/htdocs/docs X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 19:43:30 -0000 Author: wblock Date: Sat Feb 22 19:43:29 2014 New Revision: 44031 URL: http://svnweb.freebsd.org/changeset/doc/44031 Log: Remove stale link to PXE article removed in r39261. Modified: head/en_US.ISO8859-1/htdocs/docs/books.xml Modified: head/en_US.ISO8859-1/htdocs/docs/books.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/docs/books.xml Sat Feb 22 13:41:52 2014 (r44030) +++ head/en_US.ISO8859-1/htdocs/docs/books.xml Sat Feb 22 19:43:29 2014 (r44031) @@ -275,11 +275,6 @@ How to best formulate and submit a problem report to the FreeBSD Project.

-

PXE booting - FreeBSD (pxe)
- How to create an Intel PXE server using FreeBSD, and how to - configure a FreeBSD client to boot from a PXE server.

-

Practical rc.d scripting in BSD (rc-scripting)
A guide to writing new rc.d scripts and understanding those From owner-svn-doc-head@FreeBSD.ORG Sat Feb 22 21:38:16 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F765380 for ; Sat, 22 Feb 2014 21:38:16 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C9511FCD for ; Sat, 22 Feb 2014 21:38:16 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so10968212qgd.1 for ; Sat, 22 Feb 2014 13:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bwZN/k0jN7afh4ZxmUwJWi+DPLVqcWVZ99/6X3VyeQE=; b=sO2DWvkYKO8fheHJl6kEnE7WY/iTDqfgwb3h4SKGxy4UB920QvXJyzJdDa6zcViYrp AqqozGI0add/8FQykNI8M25uv9TtcrxKqiA8Lw84zhBg88OhPBTpotj0gzGr6UjkifNh sesZlfF8tmjuc69Ed4bWEboXJlBwIbkjqwwJE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=bwZN/k0jN7afh4ZxmUwJWi+DPLVqcWVZ99/6X3VyeQE=; b=I/ZY2sDnHWLkxlHC4UEWWnZE1GaWRUAY/YSxw4HQT0Cg6QDQQPJdqeB2JlbhI37oxW VlXASidRzD7/vQR0sbHcunMbOv6Xyx4+B8r1hIapFrcM89NHYSkeCgarv5eUgT2nrdk5 GRGZgxtRCdb1anIviqlc4O873XiGvtRy9XVDN9ILWIb6W3tzb8DXJwy3CpB88bvZWGUw StxuHf3maY4v6XYhXAteHegnyZj8xenR1Twb0CKggYTRDyArPPPMX5O4YXkhGhQjBpEf 9aDOltS/jgD8oFAq3YIW2wunrBfXgCyUa5JMC1J5ijwo0mFn9DRP+kjoF3+fLkZWECfG lSPA== X-Gm-Message-State: ALoCoQnClNQlQNgEMqbdz2s3oRVHni0kdT/tSsp8tmk/vzIr/F8v2G/MT13FKz3AUOYkDfATLXbp X-Received: by 10.224.165.133 with SMTP id i5mr19834019qay.75.1393105095285; Sat, 22 Feb 2014 13:38:15 -0800 (PST) MIME-Version: 1.0 Sender: lists@eitanadler.com Received: by 10.96.109.196 with HTTP; Sat, 22 Feb 2014 13:37:45 -0800 (PST) In-Reply-To: <20140222164550.GA76814@glenbarber.us> References: <201402212216.s1LMGWZv089398@svn.freebsd.org> <20140222164550.GA76814@glenbarber.us> From: Eitan Adler Date: Sat, 22 Feb 2014 16:37:45 -0500 X-Google-Sender-Auth: IsyhQF5dIIPIxA9pTMKytzn0_rw Message-ID: Subject: Re: svn commit: r44020 - head/en_US.ISO8859-1/articles/committers-guide To: Glen Barber Content-Type: text/plain; charset=UTF-8 Cc: svn-doc-head@freebsd.org, Benjamin Kaduk , svn-doc-all@freebsd.org, doc-committers@freebsd.org X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 21:38:16 -0000 On Sat, Feb 22, 2014 at 11:45 AM, Glen Barber wrote: > On Sat, Feb 22, 2014 at 01:51:38AM -0500, Benjamin Kaduk wrote: >> On Fri, 21 Feb 2014, Glen Barber wrote: >> >> >Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml >> >============================================================================== >> >--- head/en_US.ISO8859-1/articles/committers-guide/article.xml Fri Feb 21 20:28:01 2014 (r44019) >> >+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Fri Feb 21 22:16:31 2014 (r44020) >> >@@ -2118,9 +2106,6 @@ U stable/9/share/man/man4/netmap.4 >> > In commit logs etc., rev 179872 should be >> > spelled r179872 as per convention. >> > >> >- Do not remove and re-add the same file in a single commit >> >- as this will break the CVS exporter. >> >- >> >> The last time I updated patchfiles for a new upstream release, I caught >> myself removing and re-adding a file of the same name, which I went and >> reverted because I remembered that there was a hook which rejected such >> commits. Do we know if such a hook is still in place? (It occurs to me >> that I may just be remembering the exporter breakage and maybe there never >> was such a hook.) >> > > I do not see anything in svnadmin/hooks/ to reject files that were > replaced. There is such a hook in ports. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams