From owner-freebsd-doc@FreeBSD.ORG Fri Nov 20 16:07:16 2009 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F23EA106568B; Fri, 20 Nov 2009 16:07:15 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 85CFA8FC19; Fri, 20 Nov 2009 16:07:14 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 9166EEB4838; Fri, 20 Nov 2009 18:07:13 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 7543B452A4; Fri, 20 Nov 2009 18:07:13 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7ulDXVTRK3u; Fri, 20 Nov 2009 18:07:13 +0200 (EET) Received: from kobe.laptop (ppp-94-64-253-167.home.otenet.gr [94.64.253.167]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 1850D451B2; Fri, 20 Nov 2009 18:07:12 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nAKG7AZY088698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 18:07:11 +0200 (EET) (envelope-from keramida@kobe.laptop) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nAKG7AtV088693; Fri, 20 Nov 2009 18:07:10 +0200 (EET) (envelope-from keramida) From: Giorgos Keramidas To: Manolis Kiagias References: <4B05BA06.3010303@FreeBSD.org> Date: Fri, 20 Nov 2009 18:07:02 +0200 Message-ID: <87ws1luqmx.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: Tom Rhodes , "doc@FreeBSD.org" , Gabor PALI , Gabor Kovesdan , Rene Ladan Subject: Re: [RFC] Article on freebsd-update-server X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:07:16 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= On Thu, 19 Nov 2009 23:35:02 +0200, Manolis Kiagias wrote: > Hi all, > > I am sending this to my usual reviewers and the doc@ list, everyone is > welcome to comment. > > Jason Helfman (jhelfman@e-e.com) is actively involved with our > documentation set and you may have seen some of his patches. > > His initial contribution however is the article in this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=139095 > > I've been working on this article with Jason for quite some time, and > we think it's about time it gets a broader review. > > The source is here: > > http://people.freebsd.org/~manolis/patches/freebsd-update-server/article.sgml.txt Some of the changes I made locally while reading the source are shown in diff format below. They are based on the latest revision of the article source at http://mercurial.dyndns.org/mercurial/freebsd-doc-el (the last change I pulled was 6d8923ea5ca3 from 2009-11-20 10:05:02 +0200). Some of the changes I made to the article are rewording, formatting, spell checking fixes, or other tiny nits I noticed. Others are merely adding inline SGML comments. Most of them are things we can fix before committing this to CVS. There are also a few that are probably ok to fix later. : diff -r 6d8923ea5ca3 en_US.ISO8859-1/articles/freebsd-update-server/article.sgml : --- a/en_US.ISO8859-1/articles/freebsd-update-server/article.sgml Fri Nov 20 10:05:02 2009 +0200 : +++ b/en_US.ISO8859-1/articles/freebsd-update-server/article.sgml Fri Nov 20 17:47:40 2009 +0200 : @@ -80,11 +80,11 @@ : : : : - An Apache : - web server, with over half of the space required for the : - build. For instance, our test builds total 4 GB, and the : - webserver space needed to distribute updates is 2.6 GB. : + A web server, like Apache, : + with over half of the space required for the build. For instance, : + our test builds total 4 GB, and the webserver space needed to : + distribute updates is 2.6 GB. : If freebsd-update can work with other HTTP servers, it is a good idea to avoid writing Apache-specific instructions. I know a few installations of FreeBSD that prefer lighttpd or nginx, for example. : Configuration: Installation & Setup : : - Download freebsd-update-server : + Download : + the freebsd-update-server : software. A tarball may be downloaded, or use &man.csup.1; and the Tiny nit. : : - This is where the subroutine fetchiso() : - declared in scripts/build.subr will contact : - the configured source for downloading the &os; ISO. This setting : - is not limited to ftp, it may also be : - a web (httpd) address as well. : - For our purposes, ISO's are on the same server as our internal : - http server that will be serving updates. The software has been : - configured to look in that location. For this setup, we have to : - alter the routine to fetch the ISO. By copying the source : - build.subr to : - scripts/RELEASE/ARCHITECTURE/build.subr this : - file will be sourced instead of the released source for : - build.subr. : + This is the location where ISO images are downloaded from (by : + the fetchiso() subroutine : + of scripts/build.subr). The location : + configured here is not limited to FTP URIs. Any URI scheme : + supported by the standard &man.fetch.1; utility should work fine. : + In our own setup the ISO images are on the same internal http : + server that will be serving the updates. : + : + Customizations to the fetchiso() code can : + be installed by copying the : + default build.subr script to the release- and : + architecture-specific area : + at scripts/RELEASE/ARCHITECTURE/build.subr : + and applying local edits. I tried to reword the original text here. If you like the new version, please feel free to keep it. If not, we have to find a good way to simplify the large sentences of the original. : BUILDHOSTNAME : : : - Host where software will be built. Coincidentally, this : - information will be displayed on updated systems when : - issuing: : + The name of the build host. This information will be : + displayed on updated systems when issuing: "Coincidentally" seems superfluous here. : SSHKEY : : : - Key used when uploading data to an update server which will : - provide patches or upgrades to clients. A key pair may be : - created using ssh-keygen -t dsa. Alteration : - of this parameter is not required as stadnard password : - authentication through ssh will be : - used. : + The SSH key for uploading files to : + the update server. A key pair can be created by : + typing ssh-keygen -t dsa. This parameter is : + optional; standard password authentication will be used as a : + fallback authentication method when SSHKEY is : + not defined. : : - &man.ssh-keygen.1; has more detailed information in creating : - a key pair. : + &man.ssh-keygen.1; has more detailed information : + about SSH and the appropriate steps for : + creating and using one. Another suggestion for rewording the text, writing smaller sentences, and other minor wording nits. : : - Account that files are uploaded to on remote system. : + Account that files are uploaded to on the update : + server. : : : : @@ -194,54 +197,68 @@ MASTERDIR=update-master.freebsd.orgMASTERDIR : : : - Directory where files are uploaded to on remote : - system. : + Directory where files are uploaded to on the update : + server. I think I like "update server" better than "remote system" here. The update server may be the same machine that builds the snapshots. By removing the unstated assumption that it is *not*, the text sounds more accurate. : : : : - Now that build directives are set, the installation files are : - configured for a build. For this example, we will use : - RELEASE-7.2 under amd64 : - architecture. Configuration files for &i386; : - architecture are available with downloaded source. : + The default build.conf file shipped with : + the freebsd-update-server sources are : + suitable for building &i386; releases of &os;. As an example of : + building an update server for other architectures we will show in : + the following paragraphs the configuration changes needed for an : + AMD64 update server: We haven't actually described *any* installation so far. So I changed this part to describe what freebsd-update-server defaults seem to be, and switched the rest of the section from alternating text and samples to a with separate steps: : - Create build environment directory under scripts/RELEASE-7.2/amd64. : + : + : + Create a build environment for AMD64: : : - : - &prompt.user; mkdir -p /usr/local/freebsd-update-server/scripts/RELEASE-7.2/amd64 : - : + : + &prompt.user; mkdir -p /usr/local/freebsd-update-server/scripts/RELEASE-7.2/amd64 : + : + : : - This is the build.conf file that should be : - placed in the directory just created. : + : : - # SHA256 hash of RELEASE disc1.iso image. : + Install a build.conf file in the : + newly created build directory. The build configuration : + options for &os; 7.2-RELEASE on AMD64 should be similar : + to: : + : + # SHA256 hash of RELEASE disc1.iso image. : export RELH=1ea1f6f652d7c5f5eab7ef9f8edbed50cb664b08ed761850f95f48e86cc71ef5 : : # Components of the world, source, and kernels : export WORLDPARTS="base catpages dict doc games info manpages proflibs lib32" : -export SOURCEPARTS="base bin contrib crypto etc games gnu include krb5 \ : - lib libexec release rescue sbin secure share sys tools \ : - ubin usbin cddl" : +export SOURCEPARTS="base bin contrib crypto etc games gnu include krb5 \ : + lib libexec release rescue sbin secure share sys tools \ : + ubin usbin cddl" : export KERNELPARTS="generic" : : # EOL date : export EOL=1275289200 : : - : - To generate the "End of Life" number for : - build.conf, refer to the "Estimated EOL" posted : - on the &os; : - Security Website. Based on this date, you can issue : - date -j -f '%Y%m%d-%H%M%S' '20090401-000000' +%s, : - and substitute actual date parameters for those stated by : - &os;. : + : + To generate the "End of Life" number for : + build.conf, refer to the "Estimated : + EOL" posted on : + the &os; : + Security Website. You can derive the value : + of EOL from the date listed on the web : + site, using the &man.date.1; utility, e.g.: : : - The &man.sha256.1; hash key for the desired release, is : - published within the respective release announcement . : - : + &prompt.user; date -j -f '%Y%m%d-%H%M%S' '20090401-000000' '+%s' : + : + : + : + The &man.sha256.1; hash key for the desired release, is : + published within the : + respective release : + announcement. : + : + : + : NOTE: The above can probably stand on their own, outside of the element. : : @@ -273,9 +290,9 @@ enter aes-256-cbc encryption password: : Verifying - enter aes-256-cbc encryption password: : : : - Note down the generated KeyPrint; this value is entered into : - /etc/freebsd-update.conf for binary : - updates. : + Keep a note of the generated key fingerpring. This value is : + entered into /etc/freebsd-update.conf for : + binary updates. : There are various places that the article refers to "KeyPrint". I think it means "key fingerpring", but I am not sure. If that's what the real meaning should be, please use "key fingerprint". : Mon Aug 24 17:54:07 PDT 2009 Extracting world+src for FreeBSD/amd64 7.2-RELEASE : @@ -411,10 +428,7 @@ to sign the release. : file named USAGE. Execute : scripts/approve.sh, as directed. This will sign : the release, and move components into a staging area suitable for : - uploading. It is important to make sure that your key is mounted : - during this process. A simple df will show if it : - is mounted. If not mounted, mount the key with the passphrase supplied : - when creating it earlier. : + uploading. I don't know where the key mounting bits come from. It seems to refer to those FreeBSD installations where PGP keys are stored in removable media, like a USB flash disk. Why do we have to explicitly mention this here? After all, we don't describe how gpg-agent(1) works, or how seahorse(1) integrates PGP with Gnome, or any other case of the dozens of PGP setups possible... : @@ -524,9 +547,11 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning st : : When running a patch level build, we are assuming that previous : patches are in place. When a patch build is run, it will run all : - patches less than or equal to the number specified. Beyond this, : - you will have to take appropriate measures to verify authenticity : - of the patch. : + patches less than or equal to the number specified. : + : + It is up to the administrator of the freebsd-update : + server to take appropriate measures to verify the authenticity of : + every patch. I think we ought to emphasize a bit the part about patch authenticity, but I am not sure if I chose the right way to do this. : - Follow the same process as noted before for appoving a build. : + Follow the same process as noted before for approving a build: Typo. There are more changes, in the attached patch. Most of them are attempts to improve the wording of various small parts of the article. Please see the attached diff for all of them. One more important detail. We are still discussing at doceng@ how we can bring the final article into CVS. So, please hold from committing this, until we have resolved all the remaining details. I'm sure that a lot of people will love reading an article that describes in detail how to set up a local freebsd-update server. Thanks for all the work done so far on what seems to be an excellent article! :-D --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=freebsd-update.6d8923ea5ca3.diff Content-Transfer-Encoding: quoted-printable Content-Description: Proposed changes and comments for freebsd-update-server rev. 6d8923ea5ca3 diff -r 6d8923ea5ca3 en_US.ISO8859-1/articles/freebsd-update-server/article= .sgml =2D-- a/en_US.ISO8859-1/articles/freebsd-update-server/article.sgml Fri Nov= 20 10:05:02 2009 +0200 +++ b/en_US.ISO8859-1/articles/freebsd-update-server/article.sgml Fri Nov 2= 0 17:48:23 2009 +0200 @@ -80,11 +80,11 @@ =20 =2D An Apache =2D web server, with over half of the space required for the =2D build. For instance, our test builds total 4 GB, and the =2D webserver space needed to distribute updates is 2.6 GB. + A web server, like Apache, + with over half of the space required for the build. For instance, + our test builds total 4 GB, and the webserver space needed to + distribute updates is 2.6 GB. =20 @@ -97,7 +97,8 @@ Configuration: Installation & Setup =20 =2D Download freebsd-update-server + Download + the freebsd-update-server software. A tarball may be downloaded, or use &man.csup.1; and the projects-all collection. =20 @@ -138,19 +139,20 @@ MASTERDIR=3Dupdate-master.freebsd.orgFTP =20 =2D This is where the subroutine fetchiso() =2D declared in scripts/build.subr will contact =2D the configured source for downloading the &os; ISO. This setting =2D is not limited to ftp, it may also be =2D a web (httpd) address as well. =2D For our purposes, ISO's are on the same server as our internal =2D http server that will be serving updates. The software has been =2D configured to look in that location. For this setup, we have to =2D alter the routine to fetch the ISO. By copying the source =2D build.subr to =2D scripts/RELEASE/ARCHITECTURE/build.subr this =2D file will be sourced instead of the released source for =2D build.subr. + This is the location where ISO images are downloaded from (by + the fetchiso() subroutine + of scripts/build.subr). The location + configured here is not limited to FTP URIs. Any URI scheme + supported by the standard &man.fetch.1; utility should work fine. + In our own setup the ISO images are on the same internal http + server that will be serving the updates. + + Customizations to the fetchiso() code can + be installed by copying the + default build.subr script to the release- and + architecture-specific area + at scripts/RELEASE/ARCHITECTURE/build.subr + and applying local edits. =20 @@ -158,9 +160,8 @@ MASTERDIR=3Dupdate-master.freebsd.orgBUILDHOSTNAME =20 =2D Host where software will be built. Coincidentally, this =2D information will be displayed on updated systems when =2D issuing: + The name of the build host. This information will be + displayed on updated systems when issuing: =20 &prompt.user; uname -v @@ -170,15 +171,16 @@ MASTERDIR=3Dupdate-master.freebsd.orgSSHKEY =20 =2D Key used when uploading data to an update server which will =2D provide patches or upgrades to clients. A key pair may be =2D created using ssh-keygen -t dsa. Alteration =2D of this parameter is not required as stadnard password =2D authentication through ssh will be =2D used. + The SSH key for uploading files to + the update server. A key pair can be created by + typing ssh-keygen -t dsa. This parameter is + optional; standard password authentication will be used as a + fallback authentication method when SSHKEY is + not defined. =20 =2D &man.ssh-keygen.1; has more detailed information in creating =2D a key pair. + &man.ssh-keygen.1; has more detailed information + about SSH and the appropriate steps for + creating and using one. =20 @@ -186,7 +188,8 @@ MASTERDIR=3Dupdate-master.freebsd.orgMASTERACCT =20 =2D Account that files are uploaded to on remote system. + Account that files are uploaded to on the update + server. =20 @@ -194,54 +197,68 @@ MASTERDIR=3Dupdate-master.freebsd.orgMASTERDIR =20 =2D Directory where files are uploaded to on remote =2D system. + Directory where files are uploaded to on the update + server. =20 =2D Now that build directives are set, the installation files are =2D configured for a build. For this example, we will use =2D RELEASE-7.2 under amd64 =2D architecture. Configuration files for &i386; =2D architecture are available with downloaded source. + The default build.conf file shipped with + the freebsd-update-server sources are + suitable for building &i386; releases of &os;. As an example of + building an update server for other architectures we will show in + the following paragraphs the configuration changes needed for an + AMD64 update server: =20 =2D Create build environment directory under scripts/RELEASE-7.2/amd64. + + + Create a build environment for AMD64: =20 =2D =2D &prompt.user; mkdir -p /usr/local/freebsd-updat= e-server/scripts/RELEASE-7.2/amd64 =2D + + &prompt.user; mkdir -p /usr/local/freebsd-upd= ate-server/scripts/RELEASE-7.2/amd64 + + =20 =2D This is the build.conf file that should be =2D placed in the directory just created. + =20 =2D # SHA256 hash of RELEASE disc1.iso image. + Install a build.conf file in the + newly created build directory. The build configuration + options for &os; 7.2-RELEASE on AMD64 should be similar + to: + + # SHA256 hash of RELEASE disc1.iso image. export RELH=3D1ea1f6f652d7c5f5eab7ef9f8edbed50cb664b08ed761850f95f48e86cc7= 1ef5 =20 # Components of the world, source, and kernels export WORLDPARTS=3D"base catpages dict doc games info manpages proflibs l= ib32" =2Dexport SOURCEPARTS=3D"base bin contrib crypto etc games gnu include krb5= \ =2D lib libexec release rescue sbin secure share sys tools \ =2D ubin usbin cddl" +export SOURCEPARTS=3D"base bin contrib crypto etc games gnu include krb5 \ + lib libexec release rescue sbin secure share sys tools \ + ubin usbin cddl" export KERNELPARTS=3D"generic" =20 # EOL date export EOL=3D1275289200 =20 =2D =2D To generate the "End of Life" number for =2D build.conf, refer to the "Estimated EOL" posted =2D on the &os; =2D Security Website. Based on this date, you can issue =2D date -j -f '%Y%m%d-%H%M%S' '20090401-000000' +%s, =2D and substitute actual date parameters for those stated by =2D &os;. + + To generate the "End of Life" number for + build.conf, refer to the "Estimated + EOL" posted on + the &os; + Security Website. You can derive the value + of EOL from the date listed on the web + site, using the &man.date.1; utility, e.g.: =20 =2D The &man.sha256.1; hash key for the desired release, is =2D published within the respective release announcement . =2D + &prompt.user; date -j -f '%Y%m%d-%H%M%S' '200= 90401-000000' '+%s' + + + + The &man.sha256.1; hash key for the desired release, is + published within the + respective release + announcement. + + + =20 @@ -273,9 +290,9 @@ enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: =20 =2D Note down the generated KeyPrint; this value is entered into =2D /etc/freebsd-update.conf for binary =2D updates. + Keep a note of the generated key fingerpring. This value is + entered into /etc/freebsd-update.conf for + binary updates. =20 At this point, we are ready to stage a build. @@ -330,8 +347,8 @@ world|base|/usr/lib/libalias_ftp.a =20 Then the build of the world is performed again, with world =2D patches. A more detailed explanation may be found in =2D scripts/build.subr. + patches. A more detailed explanation may be found + in scripts/build.subr. =20 Mon Aug 24 17:54:07 PDT 2009 Extracting world+src for FreeBSD/= amd64 7.2-RELEASE @@ -411,10 +428,7 @@ to sign the release. file named USAGE. Execute scripts/approve.sh, as directed. This will sign the release, and move components into a staging area suitable for =2D uploading. It is important to make sure that your key is mounted =2D during this process. A simple df will show if = it =2D is mounted. If not mounted, mount the key with the passphrase sup= plied =2D when creating it earlier. + uploading. =20 &prompt.root; cd /usr/local/freebsd-update-server= @@ -436,6 +450,8 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning st &prompt.root; sh scripts/upload.sh amd64 RELEASE-7= .2 =20 + The uploaded files will need to be in the DocumentRoot of the webserver in order for updates to be distributed. For further explanation, please refer to the @@ -443,6 +459,10 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning st url=3D"&url.books.handbook;/network-apache.html">Apache documentation. =20 + Updates for the current release of the &os; system you are updating, and what you want to upgrade to need @@ -453,11 +473,14 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning st &os; 7.2-RELEASE. =20 + Update client's KeyPrint and ServerName in /etc/freebsd-update.conf, and perform updates as instructed in the &os; Update + instructions in the Handbook. =20 For reference, here is the entire run of Building a Patch =20 =2D In the event a Every time a security advisory =2D is posted, a patch update can be built. + is announced, a patch update can be built. =20 For this example, we will be using 7.1-RELEASE. =20 @@ -487,8 +510,8 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning st =20 =2D Create patch directory under =2D /usr/local/freebsd-update-server/pat= ches/ for the respective release. + Create the patch directory of the respective release + under /usr/local/freebsd-update-server= /patches/. =20 &prompt.user; mkdir -p /usr/local/freebsd-update-= server/patches/RELEASE-7.1/ @@ -507,8 +530,8 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning st we can see it is called SA-09:12.bind. After downloading the file, it is required to rename the file to an appropriate patch level. It is suggested to keep this inline with =2D official &os; patch levels, however, this is just a suggestion. =2D For this build, let us follow the brief and call this + official &os; patch levels, but you are free to choose any name you = prefer. + For this build, let us follow the currently established practice of = &os; and call this p7. Rename the file: =20 @@ -524,9 +547,11 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning st When running a patch level build, we are assuming that previous patches are in place. When a patch build is run, it will run all =2D patches less than or equal to the number specified. Beyond this, =2D you will have to take appropriate measures to verify authenticity =2D of the patch. + patches less than or equal to the number specified. + + It is up to the administrator of the freebsd-update + server to take appropriate measures to verify the authenticity of + every patch. =20 You can also add your own patches to any build. Use the number zero, or any other number. @@ -642,7 +667,7 @@ files to confirm that they look sensible # sh -e approve.sh amd64 7.1-RELEASE to sign the build. =20 =2D Follow the same process as noted before for appoving a build.<= /para> + Follow the same process as noted before for approving a build: =20 &prompt.root; sh -e scripts/approve.sh amd64 7.1-RE= LEASE Wed Aug 26 12:50:06 PDT 2009 Signing build for FreeBSD/amd64 7.1-RELEASE @@ -657,7 +682,7 @@ ready to be uploaded. Remember to run to unmount the decrypted key once you have finished signing all the new builds. =20 =2D After approving the build, upload the software. + After approving the build, upload the software: =20 &prompt.root; cd /usr/local/freebsd-update-server= @@ -671,21 +696,40 @@ the new builds. Tips =20 + + If you build your own release using the native =2D make release, + make release procedure, the freebsd-update-server code will work + from your release. As an example, you may build a release without ports or documentation and add a custom kernel. After removing functionality pertaining to the documentation subroutine and =2D altering the buildworld() subroutine in =2D scripts/build.subr the + altering the buildworld() subroutine in + scripts/build.subr, the freebsd-update-code will successfully build update code on this release. =20 + Add make -j NUMBER to scripts/build.subr to speed up processing. Adding flags to anything other than @@ -695,6 +739,10 @@ the new builds. =20 + Create a firewall rule to block outgoing RST packets. Due to a bug noted in this posting, --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAksGvq0ACgkQ1g+UGjGGA7ZWHwCcDcBO2CXgOdILU/XPsD8wsfmE m8UAoK0CDgSoic7TWEH1pcJ5c3bYrmuI =cY04 -----END PGP SIGNATURE----- --==-=-=--