From owner-freebsd-doc Sun Mar 31 12: 8:52 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mail.tstonramp.com (tstonramp.com [206.55.129.9]) by hub.freebsd.org (Postfix) with ESMTP id ACE1537B41C; Sun, 31 Mar 2002 12:08:50 -0800 (PST) Received: from buckybox (dsl-206-55-130-48.tstonramp.com [206.55.130.48]) by mail.tstonramp.com (8.11.1/8.11.1) with SMTP id g2VK8kR03513; Sun, 31 Mar 2002 12:08:48 -0800 (PST) From: "Nathan Sharfi" To: , Subject: FreeBSD Documentation License; where is it? Date: Sun, 31 Mar 2002 12:09:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I followed a link from http://www.gnu.org/philosophy/license-list.html#FreeDocumentationLicenses to http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ln15.html, but there's no mention of a FreeBSD Documentation License from 1) your internal search engine 2) Google 3) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ where is it, or does it not exist? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 12:39:39 2002 Delivered-To: freebsd-doc@freebsd.org Received: from services.webwarrior.net (overlord-host99.dsl.visi.com [209.98.86.99]) by hub.freebsd.org (Postfix) with ESMTP id D52D637B400 for ; Sun, 31 Mar 2002 12:39:35 -0800 (PST) Received: from twincat.vladsempire.net (hutch-181.hutchtel.net [206.10.67.81]) by services.webwarrior.net (Postfix) with ESMTP id 077CC44C for ; Sun, 31 Mar 2002 14:39:33 -0600 (CST) Received: by twincat.vladsempire.net (Postfix, from userid 1001) id 65A913884; Sun, 31 Mar 2002 14:40:21 +0000 (GMT) Date: Sun, 31 Mar 2002 14:40:21 +0000 From: Josh Paetzel To: docs@freebsd.org Cc: darklogik@pittgoth.com, setantae@submonkey.net Subject: Re: docs/35723 Message-ID: <20020331144021.C286@twincat.vladsempire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >Well I don't think we should refer to PRs in manpages for one. > > > hmmm, Ceri, why don't we cut from the PR listing down? Well I also don't think that we should say "this driver...appears to be no longer actively maintained". Which means that I don't like two thirds of the suggested patch, which is really quite a lot for a 27 word patch. Far better would something like "This driver causes kernel panics". And I don't like that either :) Ceri My thinking was that this will be a temporary deal. Either the driver will be dropped, and there will be no need for the man page, and certainly no danger of a user hanging his system by using it, or the driver will be fixed, in which case there will be no need to say that the driver is broken. I referenced the PR on the driver because it is the most direct source of informantion on what is happening with the driver, if there's a better way of getting that info into the man page, or getting people pointed to that info by all means do it. Josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 12:51:54 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7228637B405; Sun, 31 Mar 2002 12:51:52 -0800 (PST) Received: (from keramida@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2VKpq500179; Sun, 31 Mar 2002 12:51:52 -0800 (PST) (envelope-from keramida) Date: Sun, 31 Mar 2002 12:51:52 -0800 (PST) From: Message-Id: <200203312051.g2VKpq500179@freefall.freebsd.org> To: swear@blarg.net, keramida@FreeBSD.org, freebsd-doc@FreeBSD.org, keramida@FreeBSD.org Subject: Re: docs/36461: dd(1) manual has fatal spaces after "conv=" Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: dd(1) manual has fatal spaces after "conv=" State-Changed-From-To: open->closed State-Changed-By: keramida State-Changed-When: Sun Mar 31 12:50:10 PST 2002 State-Changed-Why: This and other changes have been committed to -CURRENT. MFC coming soon... Responsible-Changed-From-To: freebsd-doc->keramida Responsible-Changed-By: keramida Responsible-Changed-When: Sun Mar 31 12:50:10 PST 2002 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=36461 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 13:54: 0 2002 Delivered-To: freebsd-doc@freebsd.org Received: from infinitive.futureperfectcorporation.com (infinitive.futureperfectcorporation.com [196.25.137.68]) by hub.freebsd.org (Postfix) with SMTP id 0455637B41D for ; Sun, 31 Mar 2002 13:53:53 -0800 (PST) Received: (qmail 1845 invoked by uid 0); 31 Mar 2002 21:53:50 -0000 Received: from unknown (HELO gerund.futureperfectcorporation.com) (196.25.137.65) by infinitive.futureperfectcorporation.com with DES-CBC3-SHA encrypted SMTP; 31 Mar 2002 21:53:50 -0000 Received: (qmail 63445 invoked by uid 1001); 31 Mar 2002 21:55:29 -0000 Date: Sun, 31 Mar 2002 23:55:29 +0200 From: Neil Blakey-Milner To: Nathan Sharfi Cc: doc@FreeBSD.org, www@freebsd.org Subject: Re: FreeBSD Documentation License; where is it? Message-ID: <20020331215528.GA63348@mithrandr.moria.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organization: iTouch Labs X-Operating-System: FreeBSD 4.3-RELEASE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun 2002-03-31 (12:09), Nathan Sharfi wrote: > I followed a link from > http://www.gnu.org/philosophy/license-list.html#FreeDocumentationLicenses to > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ln15.html, but > there's no mention of a FreeBSD Documentation License from > 1) your internal search engine > 2) Google > 3) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ > > where is it, or does it not exist? Actually, if you go to '3', and click on the first link ("Copyright") you currently go to http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ln16.html. I think this (clicking on the "Copyright") applies to almost all the documentation. If you want to link to it, rather ask us to put a page with it on to link to. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 14: 3:24 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 23B7237B419 for ; Sun, 31 Mar 2002 14:03:20 -0800 (PST) Received: from hades.hell.gr (patr530-a121.otenet.gr [212.205.215.121]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g2VM3EQA003154; Mon, 1 Apr 2002 01:03:17 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g2VM3AFp011094; Mon, 1 Apr 2002 01:03:10 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g2VLhOcu009277; Mon, 1 Apr 2002 00:43:24 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 1 Apr 2002 00:43:23 +0300 From: Giorgos Keramidas To: Nathan Sharfi Cc: doc@freebsd.org Subject: Re: FreeBSD Documentation License; where is it? Message-ID: <20020331214323.GA423@hades.hell.gr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-03-31 12:09, Nathan Sharfi wrote: > I followed a link from > http://www.gnu.org/philosophy/license-list.html#FreeDocumentationLicenses to > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ln15.html, but > there's no mention of a FreeBSD Documentation License from > 1) your internal search engine > 2) Google > 3) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ > > where is it, or does it not exist? The FreeBSD documentation set consists of many documents. The majority of these is available under the same license that you can view by following the "Copyright" link near the top of the Handbook's first page. There are however parts of the FreeBSD documentation set that are works or parts of works copyrighted by their respective authors. Those documents have their own copyright notices near their beginning. For an example of a non-BSD licensed document, see http://www.FreeBSD.org/doc/en/books/design-44bsd/ (which is "Copyright (C) 1996 by Addison-Wesley Longman, Inc"). Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 17:30:34 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 64F1637B421 for ; Sun, 31 Mar 2002 17:30:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g311U2o67756; Sun, 31 Mar 2002 17:30:02 -0800 (PST) (envelope-from gnats) Received: from mail010.syd.optusnet.com.au (mail010.syd.optusnet.com.au [203.2.75.171]) by hub.freebsd.org (Postfix) with ESMTP id 4907837B41B for ; Sun, 31 Mar 2002 17:21:37 -0800 (PST) Received: from pcuse.com (adlax2-222.dialup.optusnet.com.au [198.142.52.222]) by mail010.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g311LYf25470 for ; Mon, 1 Apr 2002 11:21:34 +1000 Received: (from shaun@localhost) by pcuse.com (8.11.6/8.11.6) id g311LbJ13375; Mon, 1 Apr 2002 10:51:37 +0930 (CST) (envelope-from shaun) Message-Id: <200204010121.g311LbJ13375@pcuse.com> Date: Mon, 1 Apr 2002 10:51:37 +0930 (CST) From: Shaun Branden Reply-To: Shaun Branden To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/36598: typos in articles/hubs Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36598 >Category: docs >Synopsis: typos in articles/hubs >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 31 17:30:02 PST 2002 >Closed-Date: >Last-Modified: >Originator: Shaun Branden >Release: FreeBSD 4.5-STABLE i386 >Organization: >Environment: System: FreeBSD sagan.tpn 4.5-STABLE FreeBSD 4.5-STABLE #1: Fri Mar 29 23:18:15 CST 2002 shaun@sagan.tpn:/usr/obj/usr/src/sys/SAGAN i386 >Description: There are several typos in: www.freebsd.org/doc/en_US.ISO8859-1/articles/hubs/mirror-howto.html >How-To-Repeat: >Fix: *** article.sgml.orig Mon Apr 1 10:27:03 2002 --- article.sgml Mon Apr 1 10:31:31 2002 *************** *** 360,366 **** the directory structure. ! In general FTP is not really good for mirroring, since it transferes each whole file, if it has changed, and does not create a single data stream, that will benefit from a large TCP congestion window. --- 360,366 ---- the directory structure. ! In general FTP is not really good for mirroring, since it transfers each whole file, if it has changed, and does not create a single data stream, that will benefit from a large TCP congestion window. *************** *** 439,445 **** Mirroring the CVS repository ! Again you have various possibilies, but the most recommended one, is to use CVSup. --- 439,445 ---- Mirroring the CVS repository ! Again you have various possibilities, but the most recommended one, is to use CVSup. *************** *** 574,580 **** Then you need to install a couple of ports. ! You are luckt, that there is a meta-port: textproc/docproj to do the work for you. You need to setup some environment variables, like --- 574,580 ---- Then you need to install a couple of ports. ! You are lucky, that there is a meta-port: textproc/docproj to do the work for you. You need to setup some environment variables, like >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 17:46:37 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0818737B41D; Sun, 31 Mar 2002 17:46:36 -0800 (PST) Received: (from keramida@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g311kZ871270; Sun, 31 Mar 2002 17:46:35 -0800 (PST) (envelope-from keramida) Date: Sun, 31 Mar 2002 17:46:35 -0800 (PST) From: Message-Id: <200204010146.g311kZ871270@freefall.freebsd.org> To: shaun@pcuse.com, keramida@FreeBSD.org, freebsd-doc@FreeBSD.org, keramida@FreeBSD.org Subject: Re: docs/36598: typos in articles/hubs Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: typos in articles/hubs State-Changed-From-To: open->closed State-Changed-By: keramida State-Changed-When: Sun Mar 31 17:45:22 PST 2002 State-Changed-Why: Fixed the typos you spotted. The changes should appear online in approximatelly 24 hours. Thanks :) Responsible-Changed-From-To: freebsd-doc->keramida Responsible-Changed-By: keramida Responsible-Changed-When: Sun Mar 31 17:45:22 PST 2002 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=36598 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 18:20:12 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 53B1F37B421 for ; Sun, 31 Mar 2002 18:20:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g312K1D81675; Sun, 31 Mar 2002 18:20:01 -0800 (PST) (envelope-from gnats) Received: from mail002.syd.optusnet.com.au (mail002.syd.optusnet.com.au [203.2.75.245]) by hub.freebsd.org (Postfix) with ESMTP id 4A21E37B417 for ; Sun, 31 Mar 2002 18:10:08 -0800 (PST) Received: from pcuse.com (adlax2-222.dialup.optusnet.com.au [198.142.52.222]) by mail002.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g312A6724079 for ; Mon, 1 Apr 2002 12:10:06 +1000 Received: (from shaun@localhost) by pcuse.com (8.11.6/8.11.6) id g312A9o13707; Mon, 1 Apr 2002 11:40:09 +0930 (CST) (envelope-from shaun) Message-Id: <200204010210.g312A9o13707@pcuse.com> Date: Mon, 1 Apr 2002 11:40:09 +0930 (CST) From: Shaun Branden Reply-To: Shaun Branden To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/36599: duplicate word in books/fdp-primer/overview Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36599 >Category: docs >Synopsis: duplicate word in books/fdp-primer/overview >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 31 18:20:01 PST 2002 >Closed-Date: >Last-Modified: >Originator: Shaun Branden >Release: FreeBSD 4.5-STABLE i386 >Organization: >Environment: System: FreeBSD sagan.tpn 4.5-STABLE FreeBSD 4.5-STABLE #1: Fri Mar 29 23:18:15 CST 2002 shaun@sagan.tpn:/usr/obj/usr/src/sys/SAGAN i386 >Description: There is a simple duplicate word in: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/x183.html .. such as the the FAQ >How-To-Repeat: >Fix: *** chapter.sgml.old Mon Apr 1 11:35:37 2002 --- chapter.sgml Mon Apr 1 11:37:49 2002 *************** *** 230,236 **** ! If you wanted to edit an existing document, such as the the FAQ, which is in doc/en_US.ISO8859-1/books/faq you would check it out of the repository like this. --- 230,236 ---- ! If you wanted to edit an existing document, such as the FAQ, which is in doc/en_US.ISO8859-1/books/faq you would check it out of the repository like this. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 18:34:46 2002 Delivered-To: freebsd-doc@freebsd.org Received: from web21102.mail.yahoo.com (web21102.mail.yahoo.com [216.136.227.104]) by hub.freebsd.org (Postfix) with SMTP id B86EB37B41A for ; Sun, 31 Mar 2002 18:34:41 -0800 (PST) Message-ID: <20020401023441.73793.qmail@web21102.mail.yahoo.com> Received: from [62.254.0.5] by web21102.mail.yahoo.com via HTTP; Sun, 31 Mar 2002 18:34:41 PST Date: Sun, 31 Mar 2002 18:34:41 -0800 (PST) From: Hiten Pandya Reply-To: hiten@uk.FreeBSD.org Subject: CURRENT man pages need to be fixed for kernel paths (patches for review) To: freebsd-doc@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, This issue is regarding what I discussed in the PR docs/36377. Quoting my PR: -- :START "Some manual pages in -current need to be changed which refer to the /kernel file patch. FreeBSD-CURRENT man pages have to make use of /boot/kernel/kernel and not /kernel. I am attaching a patch for a taster. If this patch is agreed upon, then I can submit more patches for the same change, which has to be made to say.. a _lot_ of (not) utilities not limited to: o iostat(8) o pstat(8) o getextattr(8)" -- :END I am attaching a big patch (of patches), which fixes this issue in more than 10 to 12 man pages or something like that. All this manual pages refer to /kernel when it should be /boot/kernel/kernel, and /modules should be /boot/kernel and /modules.old should be /boot/kernel.old. NOTE: This issue only applies to the -CURRENT branch of manual pages, but not to -STABLE manual pages AFAIK. Also, there is an issue (acutally, an error! or mine) with the first patch (boot_i386), but the rest are all fine according to my personal testing. Let me know if I have missed something. I am putting this patch on review so everyone gets the chance to audit this big change, and if the change in the man page is valid with the actual utility or not. :) The patch can be found at: http://www.pittgoth.com/~hiten/diffs/paths-20020329.diff Thanks, Regards, -- Hiten Pandya -- __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 19:40:21 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C40A537B425 for ; Sun, 31 Mar 2002 19:40:00 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g313e0h99404; Sun, 31 Mar 2002 19:40:00 -0800 (PST) (envelope-from gnats) Received: from green.shallow.net (c16486.smelb1.vic.optusnet.com.au [210.49.224.105]) by hub.freebsd.org (Postfix) with ESMTP id 7EAEF37B417 for ; Sun, 31 Mar 2002 19:38:08 -0800 (PST) Received: by green.shallow.net (Postfix, from userid 1001) id 5A9C23F65; Mon, 1 Apr 2002 13:30:42 +1000 (EST) Message-Id: <20020401033042.5A9C23F65@green.shallow.net> Date: Mon, 1 Apr 2002 13:30:42 +1000 (EST) From: Joshua Goodall Reply-To: Joshua Goodall To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/36601: typo in find.1 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36601 >Category: docs >Synopsis: typo in find.1 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 31 19:40:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: Joshua Goodall >Release: FreeBSD 4.5-STABLE i386 >Organization: >Environment: System: FreeBSD green.shallow.net 4.5-STABLE FreeBSD 4.5-STABLE #2: Sat Mar 30 12:55:07 EST 2002 joshua@green.shallow.net:/usr/obj/usr/src/sys/GREEN i386 >Description: typo in find.1 enures -> ensures >How-To-Repeat: >Fix: Index: usr.bin/find/find.1 =================================================================== RCS file: /cvs/src/usr.bin/find/find.1,v retrieving revision 1.41 diff -u -r1.41 find.1 --- usr.bin/find/find.1 20 Nov 2001 15:45:29 -0000 1.41 +++ usr.bin/find/find.1 1 Apr 2002 02:50:48 -0000 @@ -261,7 +261,7 @@ is used with .Xr cpio 1 to process files that are contained in directories with unusual permissions. -It enures that you have write permission while you are placing files in a +It ensures that you have write permission while you are placing files in a directory, then sets the directory's permissions as the last thing. .It Ic -empty True if the current file or directory is empty. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 20: 0:22 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0E10737B42F for ; Sun, 31 Mar 2002 20:00:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g31404f02362; Sun, 31 Mar 2002 20:00:04 -0800 (PST) (envelope-from gnats) Received: from green.shallow.net (c16486.smelb1.vic.optusnet.com.au [210.49.224.105]) by hub.freebsd.org (Postfix) with ESMTP id 978E637B416 for ; Sun, 31 Mar 2002 19:50:26 -0800 (PST) Received: by green.shallow.net (Postfix, from userid 1001) id 138C83E2C; Mon, 1 Apr 2002 13:50:25 +1000 (EST) Message-Id: <20020401035025.138C83E2C@green.shallow.net> Date: Mon, 1 Apr 2002 13:50:25 +1000 (EST) From: Joshua Goodall Reply-To: Joshua Goodall To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/36602: find.1 should encourage users to DTRT when piping to xargs Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36602 >Category: docs >Synopsis: find.1 should encourage users to DTRT when piping to xargs >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Mar 31 20:00:04 PST 2002 >Closed-Date: >Last-Modified: >Originator: Joshua Goodall >Release: FreeBSD 4.5-STABLE i386 >Organization: >Environment: System: FreeBSD green.shallow.net 4.5-STABLE FreeBSD 4.5-STABLE #2: Sat Mar 30 12:55:07 EST 2002 joshua@green.shallow.net:/usr/obj/usr/src/sys/GREEN i386 >Description: find.1 describes the -X option, great, but doesn't give the DTRT solution, that is, using -print0 and then xargs -0 on the other side of the pipe. >How-To-Repeat: >Fix: Index: find.1 =================================================================== RCS file: /cvs/src/usr.bin/find/find.1,v retrieving revision 1.41 diff -u -r1.41 find.1 --- find.1 20 Nov 2001 15:45:29 -0000 1.41 +++ find.1 1 Apr 2002 03:29:30 -0000 @@ -117,6 +117,12 @@ quotes, backslash .Pq Dq Li \e , space, tab and newline characters. +.Pp +However, you may wish to consider the +.Fl print0 +primary in conjunction with +.Ql xargs -0 +as an effective alternative. .It Fl d The .Fl d >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Mar 31 20:30: 7 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 74F3537B41A for ; Sun, 31 Mar 2002 20:30:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g314U1U09571; Sun, 31 Mar 2002 20:30:01 -0800 (PST) (envelope-from gnats) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D84D337B41A for ; Sun, 31 Mar 2002 20:28:30 -0800 (PST) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g314SUo09417; Sun, 31 Mar 2002 20:28:30 -0800 (PST) (envelope-from nobody) Message-Id: <200204010428.g314SUo09417@freefall.freebsd.org> Date: Sun, 31 Mar 2002 20:28:30 -0800 (PST) From: Chris Pepper To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: docs/36604: FYI: Mac Toast and Disk Copy burn ISOs Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36604 >Category: docs >Synopsis: FYI: Mac Toast and Disk Copy burn ISOs >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 31 20:30:01 PST 2002 >Closed-Date: >Last-Modified: >Originator: Chris Pepper >Release: 4.5-RC3 >Organization: The Rockefeller University >Environment: N/A >Description: says: Windows/Mac users: These are standard ISO images! Most windows burner software packages will deal with them just fine without having to change them in any way. Users of other operating systems will have to locate the appropriate tools for writing these kinds of images to the CDR drive. Most Mac burning software will work too -- specifically, I know Toast 4 & 5, and Apple's Disk Copy for Mac OS X will burn ISOs. >How-To-Repeat: >Fix: Change "Windows/Mac users: These are standard ISO images! Most windows burner software packages will deal with them just fine without having to change them in any way." to "Windows/Mac users: These are standard ISO images! Most Windows and Mac burner software packages will deal with them just fine without having to change them in any way." >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 0:30: 8 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2EF6437B421 for ; Mon, 1 Apr 2002 00:30:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g318U3Q62842; Mon, 1 Apr 2002 00:30:03 -0800 (PST) (envelope-from gnats) Date: Mon, 1 Apr 2002 00:30:03 -0800 (PST) Message-Id: <200204010830.g318U3Q62842@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org Cc: From: swear@blarg.net (Gary W. Swearingen) Subject: Re: docs/36602: find.1 should encourage users to DTRT when piping to xargs Reply-To: swear@blarg.net (Gary W. Swearingen) Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR docs/36602; it has been noted by GNATS. From: swear@blarg.net (Gary W. Swearingen) To: Joshua Goodall Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: docs/36602: find.1 should encourage users to DTRT when piping to xargs Date: 01 Apr 2002 00:18:51 -0800 You might want to also slip xargs(1) into the "See Also" section before someone writes a PR on it. Its seems to be common (but debated) practice to Also See all of the commands mentioned in other sections. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 1:30:58 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0AB8B37B419; Mon, 1 Apr 2002 01:30:56 -0800 (PST) Received: (from keramida@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g319Uta74855; Mon, 1 Apr 2002 01:30:55 -0800 (PST) (envelope-from keramida) Date: Mon, 1 Apr 2002 01:30:55 -0800 (PST) From: Message-Id: <200204010930.g319Uta74855@freefall.freebsd.org> To: shaun@pcuse.com, keramida@FreeBSD.org, freebsd-doc@FreeBSD.org, keramida@FreeBSD.org Subject: Re: docs/36599: duplicate word in books/fdp-primer/overview Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: duplicate word in books/fdp-primer/overview State-Changed-From-To: open->closed State-Changed-By: keramida State-Changed-When: Mon Apr 1 01:30:14 PST 2002 State-Changed-Why: Duplicate word removed. Thank you :) Responsible-Changed-From-To: freebsd-doc->keramida Responsible-Changed-By: keramida Responsible-Changed-When: Mon Apr 1 01:30:14 PST 2002 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=36599 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 1:54:40 2002 Delivered-To: freebsd-doc@freebsd.org Received: from yello.shallow.net (yello.shallow.net [203.18.243.120]) by hub.freebsd.org (Postfix) with ESMTP id 3349737B41E; Mon, 1 Apr 2002 01:54:38 -0800 (PST) Received: by yello.shallow.net (Postfix, from userid 1001) id DAD8E2A69; Mon, 1 Apr 2002 19:54:28 +1000 (EST) Date: Mon, 1 Apr 2002 19:54:28 +1000 From: Joshua Goodall To: docs@freebsd.org Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: docs/36602: find.1 should encourage users to DTRT when piping to xargs Message-ID: <20020401095428.GE30787@roughtrade.net> References: <20020401035025.138C83E2C@green.shallow.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Apr 01, 2002 at 12:18:51AM -0800, Gary W. Swearingen wrote: > You might want to also slip xargs(1) into the "See Also" section before > someone writes a PR on it. Its seems to be common (but debated) > practice to Also See all of the commands mentioned in other sections. indeed. xargs is relevant to find in any case; find | xargs is a common pattern. Index: find.1 =================================================================== RCS file: /cvs/src/usr.bin/find/find.1,v retrieving revision 1.41 diff -u -r1.41 find.1 --- find.1 20 Nov 2001 15:45:29 -0000 1.41 +++ find.1 1 Apr 2002 09:47:38 -0000 @@ -117,6 +117,12 @@ quotes, backslash .Pq Dq Li \e , space, tab and newline characters. +.Pp +However, you may wish to consider the +.Fl print0 +primary in conjunction with +.Ql xargs -0 +as an effective alternative. .It Fl d The .Fl d @@ -732,6 +738,7 @@ .Xr locate 1 , .Xr whereis 1 , .Xr which 1 , +.Xr xargs 1 , .Xr stat 2 , .Xr fts 3 , .Xr getgrent 3 , To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 2: 0:11 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0D8C337B41C for ; Mon, 1 Apr 2002 02:00:08 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g31A08J80085; Mon, 1 Apr 2002 02:00:08 -0800 (PST) (envelope-from gnats) Date: Mon, 1 Apr 2002 02:00:08 -0800 (PST) Message-Id: <200204011000.g31A08J80085@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org Cc: From: Joshua Goodall Subject: Re: docs/36602: find.1 should encourage users to DTRT when piping to xargs Reply-To: Joshua Goodall Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR docs/36602; it has been noted by GNATS. From: Joshua Goodall To: docs@freebsd.org Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: docs/36602: find.1 should encourage users to DTRT when piping to xargs Date: Mon, 1 Apr 2002 19:54:28 +1000 On Mon, Apr 01, 2002 at 12:18:51AM -0800, Gary W. Swearingen wrote: > You might want to also slip xargs(1) into the "See Also" section before > someone writes a PR on it. Its seems to be common (but debated) > practice to Also See all of the commands mentioned in other sections. indeed. xargs is relevant to find in any case; find | xargs is a common pattern. Index: find.1 =================================================================== RCS file: /cvs/src/usr.bin/find/find.1,v retrieving revision 1.41 diff -u -r1.41 find.1 --- find.1 20 Nov 2001 15:45:29 -0000 1.41 +++ find.1 1 Apr 2002 09:47:38 -0000 @@ -117,6 +117,12 @@ quotes, backslash .Pq Dq Li \e , space, tab and newline characters. +.Pp +However, you may wish to consider the +.Fl print0 +primary in conjunction with +.Ql xargs -0 +as an effective alternative. .It Fl d The .Fl d @@ -732,6 +738,7 @@ .Xr locate 1 , .Xr whereis 1 , .Xr which 1 , +.Xr xargs 1 , .Xr stat 2 , .Xr fts 3 , .Xr getgrent 3 , To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 2:28:40 2002 Delivered-To: freebsd-doc@freebsd.org Received: from nothing-going-on.demon.co.uk (host217-37-211-49.in-addr.btopenworld.com [217.37.211.49]) by hub.freebsd.org (Postfix) with ESMTP id 83BA237B400; Mon, 1 Apr 2002 02:28:31 -0800 (PST) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.3/8.11.3) id g2R7rHO15625; Wed, 27 Mar 2002 07:53:17 GMT (envelope-from nik) Date: Wed, 27 Mar 2002 07:53:17 +0000 From: Nik Clayton To: Giorgos Keramidas Cc: doc@freebsd.org Subject: Re: Fixing &entity stuff in doc/ Message-ID: <20020327075316.H30474@canyon.nothing-going-on.org> References: <20020326221449.GD17467@hades.hell.gr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BXr400anF0jyguTS" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020326221449.GD17467@hades.hell.gr>; from keramida@freebsd.org on Wed, Mar 27, 2002 at 12:14:50AM +0200 Organization: FreeBSD Project Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --BXr400anF0jyguTS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 27, 2002 at 12:14:50AM +0200, Giorgos Keramidas wrote: > Anyone with more > sgml-foo than me that can enlighten me why "make lint" doesn't catch these > (admittedly minor) sgml typos? IIRC, it's because they're not necessary if the SGML parser can disambiguate the entity's end without it. foo bar &someentity baz and foo bar &someentity; baz are equivalent. foo bar &someentitybaz and=20 foo bar&someentity;baz are not. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --BXr400anF0jyguTS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyhemwACgkQk6gHZCw343UYaQCcDRDAjvDBXxZWvvcJrOwWNZw4 /TMAoIiw49oXENeqvqcBIbCQVFL8lc2V =9otp -----END PGP SIGNATURE----- --BXr400anF0jyguTS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 3:50:10 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B276037B419 for ; Mon, 1 Apr 2002 03:50:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g31Bo3F03004; Mon, 1 Apr 2002 03:50:03 -0800 (PST) (envelope-from gnats) Date: Mon, 1 Apr 2002 03:50:03 -0800 (PST) Message-Id: <200204011150.g31Bo3F03004@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org Cc: From: Giorgos Keramidas Subject: Re: docs/36604: FYI: Mac Toast and Disk Copy burn ISOs Reply-To: Giorgos Keramidas Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR docs/36604; it has been noted by GNATS. From: Giorgos Keramidas To: Chris Pepper Cc: bug-followup@freebsd.org Subject: Re: docs/36604: FYI: Mac Toast and Disk Copy burn ISOs Date: Mon, 1 Apr 2002 14:44:33 +0300 On 2002-03-31 20:28, Chris Pepper wrote: > Change > > "Windows/Mac users: These are standard ISO images! Most windows burner > software packages will deal with them just fine without having to change > them in any way." > > to > > "Windows/Mac users: These are standard ISO images! Most Windows and Mac burner > software packages will deal with them just fine without having to change > them in any way." IMHO, something more generic is needed. Something like: "Windows/Mac or other non-FreeBSD users: These are standard ISO images! Most cdrom burner software packages (for Windows, MacOS, or your favorite OS) should be able to deal with them just fine without having to change them in any way." This way we'll avoid having to change that text snippet the next time that an OS pops out of Redmond that is not called Windows, and BeOS, AmigaOS, or whateverOS users will know that their own software can deal with the ISO images and stop worrying that they are being "left out" or something :) - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 4:41:26 2002 Delivered-To: freebsd-doc@freebsd.org Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by hub.freebsd.org (Postfix) with ESMTP id A947437B422 for ; Mon, 1 Apr 2002 04:41:17 -0800 (PST) Received: from [217.184.143.58] (helo=neo) by smtp.web.de with esmtp (WEB.DE(Exim) 4.43 #48) id 16s17c-0003LJ-00 for freebsd-doc@FreeBSD.ORG; Mon, 01 Apr 2002 14:41:16 +0200 Date: Mon, 1 Apr 2002 14:41:49 +0200 From: Frank Thies X-Mailer: The Bat! (v1.60) Reply-To: Frank Thies X-Priority: 3 (Normal) Message-ID: <67572919.20020401144149@web.de> To: freebsd-doc@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi freebsd-team, your pdf docs seem to be corrupted -- Sincerely, Frank To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 4:42:50 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C229637B41A; Mon, 1 Apr 2002 04:42:47 -0800 (PST) Received: (from keramida@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g31Cgld17923; Mon, 1 Apr 2002 04:42:47 -0800 (PST) (envelope-from keramida) Date: Mon, 1 Apr 2002 04:42:47 -0800 (PST) From: Message-Id: <200204011242.g31Cgld17923@freefall.freebsd.org> To: joshua@roughtrade.net, keramida@FreeBSD.org, freebsd-doc@FreeBSD.org, keramida@FreeBSD.org Subject: Re: docs/36601: typo in find.1 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: typo in find.1 State-Changed-From-To: open->patched State-Changed-By: keramida State-Changed-When: Mon Apr 1 04:41:26 PST 2002 State-Changed-Why: Committed to -CURRENT. I'll MFC the changes in a few days. Thank you :) Responsible-Changed-From-To: freebsd-doc->keramida Responsible-Changed-By: keramida Responsible-Changed-When: Mon Apr 1 04:41:26 PST 2002 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=36601 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 4:43:48 2002 Delivered-To: freebsd-doc@freebsd.org Received: from rhadamanth.submonkey.net (pc4-card4-0-cust162.cdf.cable.ntl.com [80.4.14.162]) by hub.freebsd.org (Postfix) with ESMTP id 0B0A137B41F for ; Mon, 1 Apr 2002 04:43:45 -0800 (PST) Received: from setantae by rhadamanth.submonkey.net with local (Exim 3.35 #1) id 16s19x-0006ub-00; Mon, 01 Apr 2002 13:43:41 +0100 Date: Mon, 1 Apr 2002 13:43:41 +0100 From: Ceri To: Frank Thies Cc: freebsd-doc@FreeBSD.ORG Subject: Re: your mail Message-ID: <20020401124340.GA23580@submonkey.net> Mail-Followup-To: Ceri , Frank Thies , freebsd-doc@FreeBSD.ORG References: <67572919.20020401144149@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67572919.20020401144149@web.de> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Apr 01, 2002 at 02:41:49PM +0200, Frank Thies wrote: > Hi freebsd-team, > > your pdf docs seem to be corrupted Hi Frank, Could you tell us where you're getting them from ? Thanks, Ceri -- keep a mild groove on To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Apr 1 6:10:28 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D392E37B42B for ; Mon, 1 Apr 2002 06:10:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g31EA4E41889; Mon, 1 Apr 2002 06:10:04 -0800 (PST) (envelope-from gnats) Received: from foo31-146.visit.se (foo31-146.visit.se [62.119.31.146]) by hub.freebsd.org (Postfix) with ESMTP id 26AFF37B416 for ; Mon, 1 Apr 2002 06:02:15 -0800 (PST) Received: (from martin@localhost) by foo31-146.visit.se (8.11.6/8.11.6) id g31E2B001316; Mon, 1 Apr 2002 16:02:11 +0200 (CEST) (envelope-from martin) Message-Id: <200204011402.g31E2B001316@foo31-146.visit.se> Date: Mon, 1 Apr 2002 16:02:11 +0200 (CEST) From: Martin Karlsson Reply-To: Martin Karlsson To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/36614: [PATCH] typos in the handbook Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36614 >Category: docs >Synopsis: [PATCH] typos in the handbook >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Apr 01 06:10:04 PST 2002 >Closed-Date: >Last-Modified: >Originator: Martin Karlsson >Release: FreeBSD 4.5-RELEASE-p2 i386 >Organization: >Environment: System: FreeBSD foo31-146.visit.se 4.5-RELEASE-p2 FreeBSD 4.5-RELEASE-p2 #0: Wed Mar 27 07:31:58 CET 2002 root@foo31-146.visit.se:/usr/obj/usr/src/sys/BERTIL i386 >Description: This patch fixes some typos in the handbook. Hopefully. Cheers, -- Martin >How-To-Repeat: Read the handbook. >Fix: Apply the following patch. --- diff.handbook begins here --- diff -ru handbook.orig/backups/chapter.sgml handbook/backups/chapter.sgml --- handbook.orig/backups/chapter.sgml Mon Apr 1 15:02:09 2002 +++ handbook/backups/chapter.sgml Mon Apr 1 15:31:13 2002 @@ -511,7 +511,7 @@ printouts and the backup tapes. You will be so distraught when restoring that the notes may prevent you from destroying your backup tapes (How? In place of tar xvf /dev/rsa0, you - might accidently type tar cvf /dev/rsa0 and + might accidentally type tar cvf /dev/rsa0 and over-write your backup tape). For an added measure of security, make bootable floppies and two diff -ru handbook.orig/config/chapter.sgml handbook/config/chapter.sgml --- handbook.orig/config/chapter.sgml Mon Apr 1 15:02:10 2002 +++ handbook/config/chapter.sgml Mon Apr 1 15:43:21 2002 @@ -975,7 +975,7 @@ during heavy operations, so these operations are quicker than synchronous updates. Additionally the complexity of the implementation is fairly - limited, so the risk of bugs being present is low. A disadvatage + limited, so the risk of bugs being present is low. A disadvantage is that all meta-data are written twice (once into the logging region and once to the proper location) so for normal work, a performance pessimization @@ -1085,7 +1085,7 @@ this number, the kernel is given most of its pre-defined limits. Even though a production machine may not actually have 256 users connected as once, the resources needed may be similar to a - high-scale webserver. + high-scale web server. As of FreeBSD 4.5, setting to 0 in your kernel configuration file will choose @@ -1107,7 +1107,7 @@ needed. If you have a web server which maxes out at 1000 simultaneous connections, and each connection eats a 16K receive and 16K send buffer, you need approximately 32MB worth of - network buffers to cover the webserver. A good rule of thumb is + network buffers to cover the web server. A good rule of thumb is to multiply by 2, so 32MBx2 = 64MB/2K = 32768. diff -ru handbook.orig/cutting-edge/chapter.sgml handbook/cutting-edge/chapter.sgml --- handbook.orig/cutting-edge/chapter.sgml Mon Apr 1 15:02:10 2002 +++ handbook/cutting-edge/chapter.sgml Mon Apr 1 15:31:32 2002 @@ -1389,7 +1389,7 @@ Congratulations. If things went slightly wrong, it is easy to rebuild a particular - piece of the system. For example, if you accidently deleted + piece of the system. For example, if you accidentally deleted /etc/magic as part of the upgrade or merge of /etc, the &man.file.1; command will stop working. In this case, the fix would be to run: diff -ru handbook.orig/disks/chapter.sgml handbook/disks/chapter.sgml --- handbook.orig/disks/chapter.sgml Mon Apr 1 15:02:10 2002 +++ handbook/disks/chapter.sgml Mon Apr 1 15:31:47 2002 @@ -1753,7 +1753,7 @@ printouts and the backup tapes. You will be so distraught when restoring that the notes may prevent you from destroying your backup tapes (How? In place of tar xvf /dev/rsa0, you - might accidently type tar cvf /dev/rsa0 and + might accidentally type tar cvf /dev/rsa0 and over-write your backup tape). For an added measure of security, make bootable floppies and two diff -ru handbook.orig/install/chapter.sgml handbook/install/chapter.sgml --- handbook.orig/install/chapter.sgml Mon Apr 1 15:02:11 2002 +++ handbook/install/chapter.sgml Mon Apr 1 15:05:57 2002 @@ -2805,7 +2805,7 @@ For detailed information on Local Area Networks and configuring FreeBSD as a gateway/router refer to the tutorial - PPP- Pendantic PPP Primer. + PPP- Pedantic PPP Primer. User Confirmation Requested Would you like to configure Ethernet or SLIP/PPP network devices? diff -ru handbook.orig/ports/chapter.sgml handbook/ports/chapter.sgml --- handbook.orig/ports/chapter.sgml Mon Apr 1 15:02:15 2002 +++ handbook/ports/chapter.sgml Mon Apr 1 15:06:41 2002 @@ -534,7 +534,7 @@ Change CHANGE_THIS.FreeBSD.org to a CVSup near you. See CVSupp Mirrors (CVSup Mirrors () for a complete listing of mirror sites. diff -ru handbook.orig/security/chapter.sgml handbook/security/chapter.sgml --- handbook.orig/security/chapter.sgml Mon Apr 1 15:02:10 2002 +++ handbook/security/chapter.sgml Mon Apr 1 15:24:26 2002 @@ -1,4 +1,4 @@ - 192.168.2.1 netmask 0xffffffff physical address inet A.B.C.D --> W.X.Y.Z As you can see, a tunnel has been created between the physical addresses A.B.C.D and W.X.Y.Z, and the traffic allowed through the tunnel is that between 192.168.1.1 and 192.168.2.1. This will also have added an entry to the routing table on both machine= s, which you can examine with "netstat -rn". This output is from the gate= way host on network #1. # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire ... 192.168.2.1 192.168.1.1 UH 0 0 gif0 ... As the "Flags" value indicates, this is a host route, which means that each gateway knows how to reach the other gateway, but they do not know how to reach the rest of their respective networks. That problem will = be fixed shortly. It is likely that you are running a firewall on both machines. This wi= ll need to be circumvented for your VPN traffic. You might want to allow = all traffic between both networks, or you might want to include firewall ru= les that protect both ends of the VPN from one another. It greatly simplifies testing if you configure the firewall to allow all traffic through the VPN. You can always tighten things up later. If y= ou are using ipfw(8) on the gateway machines then a command like ipfw add 1 allow ip from any to any via gif0 will allow all traffic between the two end points of the VPN, without affecting your other firewall rules. Obviously you will need to run th= is command on both gateway hosts. This is sufficient to allow each gateway machine to ping the other. On 192.168.1.1 you should be able to run ping 192.168.2.1 and get a response, and you should be able to do the same thing on the other gateway machine. However, you will not be able to reach internal machines on either netw= ork yet. This is because of the routing -- although the gateway machines k= now how to reach one another, they do not know how to reach the network beh= ind each one. To solve this problem you must add a static route on each gateway machine. The command to do this on the first gateway would be: route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 This says "In order to reach the hosts on the network 192.168.2.0, send the packets to the host 192.168.2.1". You will need to run a similar command on the other gateway, but with the 192.168.1.x addresses instea= d. IP traffic from hosts on one network will now be able to reach hosts on the other network.=20 That has now created two thirds of a VPN between the two networks, in as much as it's "virtual" and it's a "network". It's not private yet. You can test this using ping(8) and tcpdump(8). Log in to the gateway host and run tcpdump dst host 192.168.2.1 In another log in session on the same host run ping 192.168.2.1 You will see output that looks something like this. 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply As you can see, the ICMP messages are going back and forth unencrypted. If you had used the "-s" parameter to tcpdump(8) to grab more bytes of data from the packets you would see more information. Obviously this is unacceptable. The next section will discuss securing the link between the two networks so that it all traffic is automatical= ly encrypted. Summary: * Configure both kernels with "pseudo-device gif" * Edit /etc/rc.conf on gateway host #1 and add the following lines=20 (replacing IP addresses as necessary). gifconfig_gif0=3D"A.B.C.D W.X.Y.Z" ifconfig_gif0=3D"inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" static_routes=3D"vpn" route_vpn=3D"192.168.2.0 192.168.2.1 netmask 0xffffff00" * Edit your firewall script (/etc/rc.firewall, or similar) on both hosts, and add =20 ipfw add 1 allow ip from any to any via gif0 * Make similar changes to /etc/rc.conf on gateway host #2, reversing = the order of IP addresses. Step 2: Securing the link To secure the link we will be using IPSec. IPSec provides a mechanism = for two hosts to agree on an encryption key, and to then use this key in or= der to encrypt data between the two hosts. The are two areas of configuration to be considered here. 1. There must be a mechanism for two hosts to agree on the encryption mechanism to use. Once two hosts have agreed on this mechanism there is said to be a "security association" between them. 2. There must be a mechanism for specifying which traffic should be encrypted. Obviously, you don't want to encrypt all your outgoing traffic -- you only want to encrypt the traffic that is part of the VPN. The rules that you put in place to determine what traffic will be encrypted are called "security policies". Security associations and security policies are both maintained by the kernel, and can be modified by userland programs. However, before you = can do this you must configure the kernel to support IPSec and the Encapsulated Security Payload (ESP) protocol. This is done by configur= ing a kernel with options IPSEC options IPSEC_ESP and recompiling, reinstalling, and rebooting. As before you will need = to do this to the kernels on both of the gateway hosts. You have two choices when it comes to setting up security associations. You can configure them by hand between two hosts, which entails choosing the encryption algorithm, encryption keys, and so forth, or you can use daemons that implement the Internet Key Exchange protocol (IKE) to do t= his for you. I recommend the latter. Apart from anything else, it's easier to set u= p. Editing and displaying security policies is carred out using setkey(8). By analogy, setkey(8) is to the kernel's security policy tables as route(8) is to the kernel's routing tables. setkey(8) can also display the current security associations, and to continue the analogy further,= is akin to "netstat -r" in that respect. There are a number of choices for daemons to manage security associatio= ns with FreeBSD. This article will describe how to use one of these, raco= on. racoon is in the FreeBSD ports collection, in the security/ category, a= nd is installed in the usual way. racoon must be run on both gateway hosts. On each host it is configured with the IP address of the other end of the VPN, and a secret key (which you choose, and must be the same on both gateways). The two daemons then contact one another, confirm that they are who they say they are (by using the secret key that you configured). The daemons then generate a new secret key, and use this to encrypt the traffic over the VPN. They periodically change this secret, so that even if an attacker were to crack one of the keys (which is as theoretically close= to unfeasible as it gets) it won't do them much good -- by the time they've cracked the key the two daemons have chosen another one. racoon's configuration is stored in ${PREFIX}/etc/racoon. You should f= ind a configuration file there, which should not need to be changed too muc= h. The other component of racoon's configuration, which you will need to change, is the 'pre-shared key'. The default racoon configuration expects to find this in the file ${PREFIX}/etc/racoon/psk.txt. It is important to note that the pre-sha= red key is *not* the key that will be used to encrypt your traffic across t= he VPN link, it is simply a token that allows the key management daemons to trust one another. =20 psk.txt contains a line for each remote site you are dealing with. In this example, where there are two sites, each psk.txt file will contain one line (because each end of the VPN is only dealing with one other en= d). On gateway host #1 this line should look like this: W.X.Y.Z secret That is, the *public* IP address of the remote end, whitespace, and a t= ext string that provides the secret. Obviously, you shouldn't use "secret"= as your key -- the normal rules for choosing a password apply. On gateway host #2 the line would look like this A.B.C.D secret That is, the public IP address of the remote end, and the same secret k= ey. psk.txt must be mode 0600 (i.e., only read/write to root) before racoon will run. You must run racoon on both gateway machines. You will also need to add some firewall rules to allow the IKE traffic, which is carried over UDP= to the isakmp (kmp =3D=3D key management protocol) port. Again, this shou= ld be fairly early in your firewall ruleset. ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp Once racoon is running you can try pinging one gateway host from the other. The connection is still not encrypted, but racoon will then set= up the security associations between the two hosts -- this might take a moment, and you may see this as a short delay before the ping commands start responding. Once the security association has been set up you can view it using setkey(8). Run setkey -D on either host to view the security assocation information. That's one half of the problem. They other half is setting your securi= ty policies. =20 To create a sensible security policy, let's review what's been set up so far. This discussions hold for both ends of the link. Each IP packet that you send out has a header that contains data about = the packet. The header includes the IP addresses of both the source and destination. As we already know, private IP addresses, such as the 192.168.x.y range are not supposed to appear on the public Internet. Instead, they must first be encapsulated inside another packet. This packet must have the public source and destination IP addresses substituted for the private addresses. So if your outgoing packet started looking like this: .----------------------. | Src: 192.168.1.1 | | Dst: 192.168.2.1 | | | +----------------------+ | | `----------------------' Then it will be encapsulated inside another packet, looking something l= ike this: .--------------------------. | Src: A.B.C.D | | Dst: W.X.Y.Z | | | +--------------------------+ | .----------------------. | | | Src: 192.168.1.1 | | | | Dst: 192.168.2.1 | | | | | | | +----------------------+ | | | | | | `----------------------' | `--------------------------' This encapsulation is carried out by the gif device. As you can see, t= he packet now has real IP addresses on the outside, and our original packet has been wrapped up as data inside the packet that will be put out on t= he Internet. Obviously, we want all traffic between the VPNs to be encrypted. You might try putting this in to words, as=20 If a packet leaves from A.B.C.D, and it is destined for W.X.Y.Z, then encrypt it, using the necessary security associations. If a packet arrives from W.X.Y.Z, and it is destined for A.B.C.D, then decrypt it, using the necessary security associations. That's close, but not quite right. If you did this, all traffic to and from W.X.Y.Z, even traffic that was not part of the VPN, would be encrypted. That's not quite what you want. The correct policy is as follows If a packet leaves from A.B.C.D, and that packet is encapsulating another packet, and it is destined for W.X.Y.Z, then encrypt it, using the necessary security associations. If a packet arrives from W.X.Y.Z, and that packet is encapsulating another packet, and it is destined for A.B.C.D, then encrypt it, using the necessary security associations. A subtle change, but a necessary one. Security policies are also set using setkey(8). Unfortunately, setkey(8), and the related code, is under almost constant development. And the version of setkey(8) included in FreeBSD 4.3 does= n't quite handle this properly. If you're using a version of FreeBSD-stable built after 3rd July 2001 (that includes FreeBSD 4.4 and later) then you have the necessary fixes. If you are using an earlier version, including FreeBSD 4.3 and below th= en you need to make a very small change to the setkey(8) source code, and then recompile it and reinstall it. Without this change, setkey(8) won't allow you to specify the rule to correctly match encapsulated packets. The change is very simple. 1. Acquire a copy of the FreeBSD source code for the version of FreeBSD you are running. 2. Change to the src/usr.sbin/setkey/ directory. 3. Edit the file token.l. Find the four lines that look like this: icmp { PREPROC; yylval.num =3D IPPROTO_ICMP; return(UP_PROTO= ); } icmp6 { PREPROC; yylval.num =3D IPPROTO_ICMPV6; return(UP_PRO= TO); } tcp { PREPROC; yylval.num =3D IPPROTO_TCP; return(UP_PROTO)= ; } udp { PREPROC; yylval.num =3D IPPROTO_UDP; return(UP_PROTO)= ; } and add this line ipencap { PREPROC; yylval.num =3D IPPROTO_IPV4; return(UP_PROTO= ); } after them. 4. Rebuild and reinstall setkey(8) by running "make install". Once you have done this you can configure the security policy. setkey(= 8) features a configuration language for defining the policy. You can eit= her enter configuration instructions via stdin, or you can use the -f option to specify a filename that contains configuration instructions. =20 The configuration on gateway host #1 (which has the public IP address A.B.C.D) to force all outbound traffic to W.X.Y.Z to be encrypted is spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Put these commands in a file (e.g., /etc/ipsec.conf) and then run=20 setkey -f /etc/ipsec.conf "spdadd" tells setkey(8) that we want to add a rule to the secure policy database. The rest of this line specifies which packets will match this policy. "A.B.C.D/32" and "W.X.Y.Z/32" are the IP addresses and netmasks that identify the network or hosts that this policy will apply to. In this case, we want it to apply to traffic between these two hosts. "ipencap" tells the kernel that this policy should only apply to packets that encapsulate other packets. "-P out" says that this policy applies= to outgoing packets, and "ipsec" says that the packet will be secured. The second line specifies how this packet will be encrypted. "esp" is = the protocol that will be used, while "tunnel" indicates that the packet wi= ll be further encapsulated in an IPSec packet. The repeated use of A.B.C.D and W.X.Y.Z is used to select the security association to use, and the final "require" mandates that packets must be encrypted if they match t= his rule. This rule only matches outgoing packets. You will need a similar rule = to match incoming packets. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; Note the "in" instead of "out" in this case, and the necessary reversal= of the IP addresses. The other gateway host (which has the public IP address W.X.Y.Z) will n= eed similar rules. spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; Finally, you need to add firewall rules to allow ESP and IPENCAP packets back and forth. These rules will need to be added to both hosts. ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D Because the rules are symmetric you can use the same rules on each gate= way host. Outgoing packets will now look something like this. .------------------------------. --------------------------. | Src: A.B.C.D | | | Dst: W.X.Y.Z | | | | | Encrypt= ed +------------------------------+ | packet. | .--------------------------. | -------------. | contents | | Src: A.B.C.D | | | | are=20 | | Dst: W.X.Y.Z | | | | complet= ely | | | | | |- secure | +--------------------------+ | | Encap'd | from th= ird | | .----------------------. | | -. | packet | party | | | Src: 192.168.1.1 | | | | Original |- with real | snooping | | | Dst: 192.168.2.1 | | | | packet, | IP addr | | | | | | | |- private | | | | +----------------------+ | | | IP addr | | | | | | | | | | | | | `----------------------' | | -' | | | `--------------------------' | -------------' | `------------------------------' --------------------------' When they are received by the far end of the VPN they will first be decrypted (using the security associations that have been negotiated by racoon). Then they will enter the gif interface, which will unwrap the second layer, until you are left with the innermost packet, which can t= hen travel in to the inner network. You can check the security using the same ping(8) test from earlier. First, log in to the A.B.C.D gateway machine, and run tcpdump dst host 192.168.2.1 In another log in session on the same host run ping 192.168.2.1 This time you should see output like the following: Now, as you can see, tcpdump(8) shows the ESP packets. If you try and examine them with the -s option you will see (apparently) gibberish, because of the encryption. Congratulations. You have just set up a VPN between two remote sites. Summary: * Configure both kernels with=20 options IPSEC options IPSEC_ESP * Install ports/security/racoon. Edit ${PREFIX}/etc/racoon/psk.txt on both gateway hosts, adding an entry for the remote host's IP address and a secret key that they both know. Make sure this file is mode 0600. * If necessary, make the one line change to src/usr.sbin/setkey/token= .l, then recompile and reinstall setkey(8). * Add the following lines to /etc/rc.conf on each host ipsec_enable=3D"YES" ipsec_file=3D"/etc/ipsec.conf" * Create an /etc/ipsec.conf on each host that contains the necessary spdadd lines. On gateway host #1 this would be spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; On gateway host #2 this would be spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; * Add firewall rules to allow IKE, ESP, and IPENCAP traffic to both hosts ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D Step 3: All the horrible Windows related configuration you need to do The previous two steps should suffice to get the VPN up and running. Machines on each network will be able to refer to one another using IP addresses, and all traffic across the link will be automatically and securely encrypted. So far so good. However, you probably have hosts running various flavo= urs of Windows at each site, and you would like to have them all appear in = the "Network Neighbourhood" or equivalent. Out of the box, this won't work. This is because the SMB protocol, aro= und which Windows' file sharing and related activities are based, was not originally designed for use on more than one subnet (or, indeed, for IP networks). Over time a number of kludges have been bolted on to the protocol to correct for these deficiencies, and you will need to implem= ent them before browsing will work. You should note that you don't need FreeBSD machines to do most of what follows. I think Windows NT or Windows 2000 hosts acting as domain controllers will also do the right thing. Of course, if you don't have any NT or 2000 hosts, and you don't feel like paying for the priviledge, you can use FreeBSD to do all this for you as well. At this point our network is composed of two subnets, 192.168.1.x, and 192.168.2.x. In order for the "Network Neighbourhood" to work properly= , a number of things need to be configured. 1. All your machines need to be configured to be in the same workgroup. For the rest of the examples I will use the workgroup name "WORKGROUP". You should, of course, change this to what ever you are using. 2. Each subnet needs to have a host acting as a "local master browse= r". This a Windows term. The local master browser is responsible for maintaining a list of all the hosts on the network. When a Windo= ws machine needs to find a list of all the other hosts on the network it sends a broadcast message out saying "Who is the local master browser?". The local master then replies, and the Windows host c= an then query the local master for a list of all the hosts on the sa= me subnet. There should be one local master browser per subnet. 3. Of course, this only works within a subnet. In order for this to= =20 work across subnets, one host has to be the "domain master browser". The domain master browser maintains a complete list of all the hosts on all the subnets. This is done by having all the local master browsers send it updates periodically. Without a domain master browser your Network Neighbourhood will not show up hosts in other subnets. There should only be one domain master browser. 4. Windows network is based on the Netbios protocol. This has a concept of hostnames, but it is different from the IP concept of hostnames. Netbios name look ups do not normally work across subnets. In order to work around this, one machine (and only one) machine should be designated a "WINS Server". The WINS Server is normally the same host as the domain master browser. It is the responsibility of the WINS Server to maintain the mapping of Netbios host names to IP addresses. Without this mapping, your Network Neighbourhood will show hosts in other subnets (because of the local master browser -> domain master browser communication) but your Windows hosts in another network will not be able to communicate with them, because they will not be able to convert their Netbios names in to IP addresses. There can only be one WINS Server per network (note: not per subn= et, per network), and every other host needs to know its IP address. That's the bare minimum you need to get started. Now you need to design your network. For the sake of this example, we will assume that you have two more FreeBSD hosts, one on each subnet. Lets give these the IP addressess 192.168.1.2 and 192.168.2.2 respectively, and make them responsible for coordinating the Windows network and allowing browsing across the VPN to work. These machines might also have file shares on them, but this article will not touch on that, as it's trivial to set up, and well documented. Recall that we will need two local master browsers, one domain master browser, and one WINS server. To keep things simple, 192.168.1.2 will be a local master browser, the domain master browser, and the WINS Server. 192.168.2.2 will be the lo= cal master browser for its network, and will send updates to the domain mas= ter browser. You should install Samba, from ports/net/samba/, on both hosts. Samba's configuration file is ${PREFIX}/etc/smb.conf. Both hosts will share some configuration information, since they will b= oth be acting as a local master browser. Edit ${PREFIX}/etc/smb.conf and add the following lines: [global] ; The network workgroup workgroup =3D WORKGROUP ; The name for this server, as it will appear in the=20 ; Network Neighbourhood server string =3D Samba Server ; Hosts that will be allowed to access this server hosts allow =3D 192.168.1. 192.168.2. 127. ; Template for generating log files log file =3D /var/log/log.%M ; This host is a local master. It is the preferred master, and the ; os level is set high enough that it will be chosen in preference ; to every other host on the network, should that eventuality ; arise. local master =3D yes preferred master =3D yes os level =3D 65 The per-host configuration is as follows. 192.168.1.2 is the WINS Server and domain master. Add these lines to t= he bottom of the "[global]" section in the configuration file. ; This host is the domain master for the whole network. domain master =3D yes ; This host will act as a WINS Server. wins support =3D yes 192.168.2.2 is neither of these. The lines to add for that are ; This host will not be the domain master. domain master =3D no ; This host is not a WINS Server, but it needs to know the address ; of the WINS Server wins server =3D 192.168.1.2 Make sure that the Samba daemons (smbd(8) and nmbd(8)) are running on b= oth machines. Now you need to configure your Windows client machines. Specifically, they need to know the address of the WINS Server (192.168.1.2). There = are two ways you can do this. 1. If you are 'statically' configuring the hosts then this informati= on can be entered by doing Start -> Control Panel -> Network -> ... 2. Alternatively, if you are using DHCP then must DHCP servers can be configured to provide this information. If you use the ISC DH= CPD then the relevant line to add to the configuration file is=20 options ... --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --L0TNCHh3fkwjpuuE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyvHNAACgkQk6gHZCw343U5ogCdFF4HViejvE/Yt74SdB/2vRh9 9c8AnA8wy+JL7g35a8021HcxgFhXuVK9 =XYDt -----END PGP SIGNATURE----- --L0TNCHh3fkwjpuuE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 9: 1:10 2002 Delivered-To: freebsd-doc@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 2D73537B417; Sat, 6 Apr 2002 09:01:07 -0800 (PST) Received: from bmah.dyndns.org ([12.233.149.189]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020406170103.DWIR3676.rwcrmhc52.attbi.com@bmah.dyndns.org>; Sat, 6 Apr 2002 17:01:03 +0000 Received: from intruder.bmah.org (localhost [IPv6:::1]) by bmah.dyndns.org (8.12.2/8.12.2) with ESMTP id g36H12t2073437; Sat, 6 Apr 2002 09:01:02 -0800 (PST) (envelope-from bmah@intruder.bmah.org) Received: (from bmah@localhost) by intruder.bmah.org (8.12.2/8.12.2/Submit) id g36H115Q073436; Sat, 6 Apr 2002 09:01:01 -0800 (PST) Message-Id: <200204061701.g36H115Q073436@intruder.bmah.org> X-Mailer: exmh version 2.5+ 20020404 with nmh-1.0.4 To: Nik Clayton Cc: "Bruce A. Mah" , Gilles Kirouac , freebsd-doc@freebsd.org Subject: Re: FreeBSD Handbook unreadable in pdf format In-reply-to: <20020405081608.O30474@canyon.nothing-going-on.org> References: <3CABE2A9.1FC65ACB@riq.qc.ca> <200204041656.g34GumhB070332@intruder.bmah.org> <20020405081608.O30474@canyon.nothing-going-on.org> Comments: In-reply-to Nik Clayton message dated "Fri, 05 Apr 2002 08:16:08 +0100." From: bmah@freebsd.org (Bruce A. Mah) Reply-To: bmah@freebsd.org X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Apr 2002 09:01:01 -0800 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If memory serves me right, Nik Clayton wrote: > I've got as far as determining that ps2pdf is blowing up when it > converts the Handbook to PDF -- and it's still too big to use pdftex > directly. I haven't had a chance to do more than a cursory inspection > at the moment, I'll try to look at this in more detail over the weekend. Thanks, Nik! I'm actually able to build something close to the bits that go on the Web site, using a script I was dinking with to build doc/ ISO images (see doc/release/Makefile). Haven't noticed anything out of the ordinary for the PDF Handbook...but I'll certainly yell out if the build that I just started turns up anything strange. Bruce. PS. In theory, the ISO and its contents could be candidates for the doc area on the FTP mirrors, don't know if there's any interest in doing it this way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 9:19:14 2002 Delivered-To: freebsd-doc@freebsd.org Received: from chat.ru (di55.tara-di-1.online.kz [212.19.154.118]) by hub.freebsd.org (Postfix) with SMTP id 7B02937B400; Sat, 6 Apr 2002 09:18:31 -0800 (PST) From: Max Subject: Delovoe predlogenie!!! Organization: Procorporate Inc. Reply-To: deonis2000@taraz.kz X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Priority: 1 X-MSMail-Priority: High Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Date: Sun, 7 Apr 2002 00:17:02 +0700 Message-Id: <20020406171831.7B02937B400@hub.freebsd.org> To: undisclosed-recipients:; Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ãîñïîäà! Âû õîòèòå ðàáîòàòü ñïîêîéíî è ïëîäîòâîðíî? È ïðè ýòîì çàðàáàòûâàòü ñîîòâåòñòâåííî ñâîèì ìàòåðèàëüíûì çàïðîñàì?!!!!!!!!!!!!!!!!!!! Âàì íå íóæíî èìåòü ñïåöèàëüíîãî îáðàçîâàíèÿ! Îáëàäàòü ñëîæíûìè çíàíèÿìè èëè íàâûêàìè! Ðàñïîëàãàòü áîëüøèì êîëè÷åñòâîì ñâîáîäíîãî âðåìåíè! Âû ìîæåòå ëåãêî ñîâìåùàòü ýòîò áèçíåñ ñ ëþáîé äðóãîé äåÿòåëüíîñòüþ! Ïðè íàëè÷èè ñîîòâåòñòâóþùåé èíèöèàòèâû ñ Âàøåé ñòîðîíû, Âû ñìîæåòå çàðàáàòûâàòü îêîëî 1000 $ â íåäåëþ. È ýòî ñ ó÷åòîì òîãî, ÷òî Âû áóäåòå ðàáîòàòü â Èíòåðíåòå 1-2,íó ìàêñèìóì 3 ÷àñà!!!!!!! Âû ñòàíåòå áîãàòûì ÷åëîâåêîì! Ìîæåòå ìíå ïîâåðèòü!............. Òåïåðü ó Âàñ ïîÿâèëàñü ïðåêðàñíàÿ âîçìîæíîñòü äîñòè÷ü ôèíàíñîâîé íåçàâèñèìîñòè â òîé ñòåïåíè, êîòîðóþ Âû ñàìè äëÿ ñåáÿ îïðåäåëèòå! Åñëè ñåé÷àñ ìîå ïðåäëîæåíèå Âàñ íå Çàèíòåðåñîâàëî - íå ñïåøèòå åãî óäàëÿòü!!!!!!!! îòïðàâòå ïóñòîå ïèñüìî ïî àäðåñó deonis2000@taraz.kz ñ òåìîé ''???????????'' è ÿ âûøëþ âàì ïîäðîáíûå èíñòðóêöèè. Áûëî áû î÷åíü íåëåïî óïóñòèòü òàêîé øàíñ....!!!!!!!!!!!!!!!! Ýòî íå îáìàííûé òðþê ñ öåëüþ âûêà÷èâàíèÿ äåíåã, à ðåàëüíûé øàíñ èõ çàðàáàòûâàíèÿ! Åñëè âàñ çàèíòåðåñîâàëî ìîå ïðåäëîæåíèå, ïèøèòå: deonis2000@taraz.kz Ñ óâàæåíèåì Max. _________________________________________ P.S. Âàø ýëåêòðîííûé àäðåñ áûë âçÿò èç îòêðûòûõ èñòî÷íèêîâ. ß íå ðàññûëàþ ðåêëàìó, à èùó ïàðòíåðîâ ïî áèçíåñó. Åñëè ýòî ïèñüìî äîñòàâèëî âàì êàêèå-ëèáî íåóäîáñòâà, òî ïðèìèòå ìîè èçâèíåíèÿ. Îòïðàâüòå ïóñòîå ïèñüìî ñ òåìîé "Unsubscribe" ïî ýòîìó àäðåñó 222@au.ru è âû áîëüøå íèêîãäà íå ïîëó÷èòå ïîäîáíîãî ïðåäëîæåíèÿ. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 9:19:15 2002 Delivered-To: freebsd-doc@freebsd.org Received: from chat.ru (di55.tara-di-1.online.kz [212.19.154.118]) by hub.freebsd.org (Postfix) with SMTP id 7B02937B400; Sat, 6 Apr 2002 09:18:31 -0800 (PST) From: Max Subject: Delovoe predlogenie!!! Organization: Procorporate Inc. Reply-To: deonis2000@taraz.kz X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Priority: 1 X-MSMail-Priority: High Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Date: Sun, 7 Apr 2002 00:17:02 +0700 Message-Id: <20020406171831.7B02937B400@hub.freebsd.org> To: undisclosed-recipients:; Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ãîñïîäà! Âû õîòèòå ðàáîòàòü ñïîêîéíî è ïëîäîòâîðíî? È ïðè ýòîì çàðàáàòûâàòü ñîîòâåòñòâåííî ñâîèì ìàòåðèàëüíûì çàïðîñàì?!!!!!!!!!!!!!!!!!!! Âàì íå íóæíî èìåòü ñïåöèàëüíîãî îáðàçîâàíèÿ! Îáëàäàòü ñëîæíûìè çíàíèÿìè èëè íàâûêàìè! Ðàñïîëàãàòü áîëüøèì êîëè÷åñòâîì ñâîáîäíîãî âðåìåíè! Âû ìîæåòå ëåãêî ñîâìåùàòü ýòîò áèçíåñ ñ ëþáîé äðóãîé äåÿòåëüíîñòüþ! Ïðè íàëè÷èè ñîîòâåòñòâóþùåé èíèöèàòèâû ñ Âàøåé ñòîðîíû, Âû ñìîæåòå çàðàáàòûâàòü îêîëî 1000 $ â íåäåëþ. È ýòî ñ ó÷åòîì òîãî, ÷òî Âû áóäåòå ðàáîòàòü â Èíòåðíåòå 1-2,íó ìàêñèìóì 3 ÷àñà!!!!!!! Âû ñòàíåòå áîãàòûì ÷åëîâåêîì! Ìîæåòå ìíå ïîâåðèòü!............. Òåïåðü ó Âàñ ïîÿâèëàñü ïðåêðàñíàÿ âîçìîæíîñòü äîñòè÷ü ôèíàíñîâîé íåçàâèñèìîñòè â òîé ñòåïåíè, êîòîðóþ Âû ñàìè äëÿ ñåáÿ îïðåäåëèòå! Åñëè ñåé÷àñ ìîå ïðåäëîæåíèå Âàñ íå Çàèíòåðåñîâàëî - íå ñïåøèòå åãî óäàëÿòü!!!!!!!! îòïðàâòå ïóñòîå ïèñüìî ïî àäðåñó deonis2000@taraz.kz ñ òåìîé ''???????????'' è ÿ âûøëþ âàì ïîäðîáíûå èíñòðóêöèè. Áûëî áû î÷åíü íåëåïî óïóñòèòü òàêîé øàíñ....!!!!!!!!!!!!!!!! Ýòî íå îáìàííûé òðþê ñ öåëüþ âûêà÷èâàíèÿ äåíåã, à ðåàëüíûé øàíñ èõ çàðàáàòûâàíèÿ! Åñëè âàñ çàèíòåðåñîâàëî ìîå ïðåäëîæåíèå, ïèøèòå: deonis2000@taraz.kz Ñ óâàæåíèåì Max. _________________________________________ P.S. Âàø ýëåêòðîííûé àäðåñ áûë âçÿò èç îòêðûòûõ èñòî÷íèêîâ. ß íå ðàññûëàþ ðåêëàìó, à èùó ïàðòíåðîâ ïî áèçíåñó. Åñëè ýòî ïèñüìî äîñòàâèëî âàì êàêèå-ëèáî íåóäîáñòâà, òî ïðèìèòå ìîè èçâèíåíèÿ. Îòïðàâüòå ïóñòîå ïèñüìî ñ òåìîé "Unsubscribe" ïî ýòîìó àäðåñó 222@au.ru è âû áîëüøå íèêîãäà íå ïîëó÷èòå ïîäîáíîãî ïðåäëîæåíèÿ. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 9:36:54 2002 Delivered-To: freebsd-doc@freebsd.org Received: from pc-62-31-80-192-ll.blueyonder.co.uk (pc-62-31-80-192-ll.blueyonder.co.uk [62.31.80.192]) by hub.freebsd.org (Postfix) with SMTP id C010537B416 for ; Sat, 6 Apr 2002 09:36:51 -0800 (PST) Received: (qmail 1469 invoked from network); 6 Apr 2002 17:36:49 -0000 Received: from spatula.home (HELO cream.org) (192.168.0.4) by myriad.home with SMTP; 6 Apr 2002 17:36:49 -0000 Message-ID: <3CAF327E.6010001@cream.org> Date: Sat, 06 Apr 2002 18:38:06 +0100 From: Andrew Boothman User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ceri Davies Cc: Tom Rhodes , doc@FreeBSD.ORG Subject: Re: RFC: Change to "why does my mail to FreeBSD.org bounce" FAQ References: <20020405155943.GA25988@submonkey.net> <20020405114723.767d28c9.darklogik@pittgoth.com> <20020405164306.GA35109@submonkey.net> <20020405120838.0c274492.darklogik@pittgoth.com> <20020406142437.GA52191@submonkey.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ceri Davies wrote: > Now it's a slightly fine grained point, maybe, but there's certainly a > difference. It may be slightly easier to just say something like : > > "As required by RFC 2822, your announced hostname must resolve." I think you should mention the fact that it is the hostname announced in the HELO command that is the problem in this case. I had exactly the same problem with mail being sent from one of my systems because it was using an internal hostname in its HELO command. The fix was simple enough, but I needed to know it was the HELO command that caused the problem so that I could alter that part of my MTA's config. I got that info from my maillog in the end, but it would be helpful if it was in the FAQ. Andrew. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 9:59:56 2002 Delivered-To: freebsd-doc@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 2869837B41D; Sat, 6 Apr 2002 09:59:50 -0800 (PST) Received: from bmah.dyndns.org ([12.233.149.189]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020406175949.IASW18078.rwcrmhc51.attbi.com@bmah.dyndns.org>; Sat, 6 Apr 2002 17:59:49 +0000 Received: from intruder.bmah.org (localhost [IPv6:::1]) by bmah.dyndns.org (8.12.2/8.12.2) with ESMTP id g36Hxnt2076310; Sat, 6 Apr 2002 09:59:49 -0800 (PST) (envelope-from bmah@intruder.bmah.org) Received: (from bmah@localhost) by intruder.bmah.org (8.12.2/8.12.2/Submit) id g36HxnBA076309; Sat, 6 Apr 2002 09:59:49 -0800 (PST) Message-Id: <200204061759.g36HxnBA076309@intruder.bmah.org> X-Mailer: exmh version 2.5+ 20020404 with nmh-1.0.4 To: Nik Clayton , Gilles Kirouac , freebsd-doc@FreeBSD.ORG Cc: bmah@FreeBSD.ORG Subject: Re: FreeBSD Handbook unreadable in pdf format In-reply-to: <200204061701.g36H115Q073436@intruder.bmah.org> References: <3CABE2A9.1FC65ACB@riq.qc.ca> <200204041656.g34GumhB070332@intruder.bmah.org> <20020405081608.O30474@canyon.nothing-going-on.org> <200204061701.g36H115Q073436@intruder.bmah.org> Comments: In-reply-to bmah@FreeBSD.ORG (Bruce A. Mah) message dated "Sat, 06 Apr 2002 09:01:01 -0800." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Apr 2002 09:59:49 -0800 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I wrote: > I'm actually able to build something close to the bits that go on the > Web site, using a script I was dinking with to build doc/ ISO images (see > doc/release/Makefile). Haven't noticed anything out of the ordinary > for the PDF Handbook...but I'll certainly yell out if the build that I > just started turns up anything strange. Bleah. /usr/local/bin/epstopdf --outfile=install/adduser1.pdf install/adduser1.eps /usr/local/bin/epstopdf --outfile=install/adduser2.pdf install/adduser2.eps /usr/local/bin/epstopdf --outfile=install/adduser3.pdf install/adduser3.eps /usr/local/bin/epstopdf --outfile=install/mainexit.pdf install/mainexit.eps /usr/local/bin/epstopdf --outfile=install/edit-inetd-conf.pdf install/edit-inetd-conf.eps /usr/bin/touch book.tex-pdf /usr/local/bin/ps2pdf book.ps book.pdf *** Signal 10 Stop in /usr/doc/en_US.ISO8859-1/books/handbook. *** Error code 1 Stop in /usr/doc/en_US.ISO8859-1/books. *** Error code 1 Stop in /usr/doc/en_US.ISO8859-1. *** Error code 1 Stop in /usr/doc. *** Error code 1 Stop in /usr/doc/release. Bruce. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 10: 1:52 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 32AE937B419 for ; Sat, 6 Apr 2002 10:01:47 -0800 (PST) Received: from hades.hell.gr (patr530-b228.otenet.gr [212.205.244.236]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g36I1a2a004133; Sat, 6 Apr 2002 21:01:38 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g36I1PpY013052; Sat, 6 Apr 2002 21:01:25 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g36I1O5m013047; Sat, 6 Apr 2002 21:01:24 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 6 Apr 2002 21:01:22 +0300 From: Giorgos Keramidas To: Ceri , freebsd-doc@FreeBSD.org Subject: Re: RFC: Removing "try and " from the docs Message-ID: <20020406180122.GB8722@hades.hell.gr> References: <20020404133226.GA8872@hades.hell.gr> <20020404143819.GB8766@submonkey.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020404143819.GB8766@submonkey.net> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-04-04 15:38, Ceri wrote: > > RCS file: /home/ncvs/doc/en_US.ISO8859-1/articles/filtering-bridges/article.sgml,v > > > > - If there are any problems, you should try and sort them out now > > + If there are any problems, you should try to sort them out now > > before proceeding. > > s/try to// perhaps ? Done :) > > RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/developers-handbook/tools/chapter.sgml,v > > > > Although Emacs does have menus, it is well worth learning > > the key bindings, as it is much quicker when you are editing > > - something to press a couple of keys than to try and find the > > - mouse and then click on the right place. And, when you are > > + something to press a couple of keys than finding the > > + mouse and then clicking on the right place. And, when you are > > ...as pressing a couple of keys when you are editing is much > quicker than finding the mouse and then clicking in the right > place. This one looks better. Yes, I see your point. Either all verbs should use "to " or a gerund. > I'd like to drop the word "online" from "online on their monitor". > I do know what you mean, and it makes sense, but it looks bizarre and > could be confusing. Aye. Les confusion is good. We don't want to confuse readers. > Also, I'm not convinced that the handbook is "beautiful" :) That was meant to mean "aesthetically pleasing" so I might change it to that, if it looks better that way. > > --- en_US.ISO8859-1/books/fdp-primer/structure/chapter.sgml 26 Mar 2002 22:31:55 -0000 1.10 > > +++ en_US.ISO8859-1/books/fdp-primer/structure/chapter.sgml 3 Apr 2002 22:22:35 -0000 > Same problem here that I have with the emacs one above. Well, I'll leave this one out. This paragraph needs a rewrite to make it appear like something meaningful. Merely substituting "try and -> try to " won't solve any problems here. > > Index: en_US.ISO8859-1/books/handbook/basics/chapter.sgml > > =================================================================== > > RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/basics/chapter.sgml,v > > retrieving revision 1.59 > > diff -u -r1.59 chapter.sgml > > --- en_US.ISO8859-1/books/handbook/basics/chapter.sgml 26 Mar 2002 23:37:38 -0000 1.59 > > +++ en_US.ISO8859-1/books/handbook/basics/chapter.sgml 3 Apr 2002 22:23:39 -0000 > > @@ -890,7 +890,7 @@ > > send—some of them have a specific meaning, others are interpreted > > by the application, and the application's documentation will tell you > > how that application interprets signals. You can only send a signal to > > - a process that you own. If you try and send a signal to someone else's > > + a process that you own. If you send a signal to someone else's > > process it will be ignored. The exception to this is the > > Slightly bigger problem here. > If you try to send a signal to someone else's process your attempt will fail > with EPERM, as opposed to being ignored. > This is the only one that I'd definitely want to see fixed, the others are > just MHO. I was thinking of that too. Referring to errors like EPERM in the "basics" chapter somehow seems like an overkill though. But I guess it's ok, since kill(1) or kill(2) will fail with EPERM. So we might just refer to these two here with something like: If you send a signal to someone else's process with &man.kill.1; or &man.kill.2; it will fail with EPERM, since you are not permitted to signal processes of other users. The exception to this is the ... Thanks Ceri, a very useful review. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 10:35: 3 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mx1.datanet.hu (mx1.datanet.hu [194.149.13.160]) by hub.freebsd.org (Postfix) with ESMTP id 0E44737B416 for ; Sat, 6 Apr 2002 10:34:57 -0800 (PST) Received: from fonix.adamsfamily.xx (nilus-526.adsl.datanet.hu [195.56.50.18]) by mx1.datanet.hu (DataNet) with ESMTP id 9DE2AF97F; Sat, 6 Apr 2002 20:34:54 +0200 (CEST) Received: from fonix.adamsfamily.xx (localhost [127.0.0.1]) by fonix.adamsfamily.xx (8.12.2/8.12.2) with ESMTP id g36IZ3lY005390; Sat, 6 Apr 2002 20:35:03 +0200 (CEST) (envelope-from sziszi@bsd.hu) Received: (from cc@localhost) by fonix.adamsfamily.xx (8.12.2/8.12.2/Submit) id g36IZ2F7005389; Sat, 6 Apr 2002 20:35:02 +0200 (CEST) X-Authentication-Warning: fonix.adamsfamily.xx: cc set sender to sziszi@bsd.hu using -f Date: Sat, 6 Apr 2002 20:35:02 +0200 From: Szilveszter Adam To: darklogik@pittgoth.com Cc: freebsd-doc@freebsd.org Subject: minor nit re advocacy/myths.html Message-ID: <20020406183502.GA5126@fonix.adamsfamily.xx> Mail-Followup-To: Szilveszter Adam , darklogik@pittgoth.com, freebsd-doc@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello Tom, [Cc-d to -doc just FYI] I was just browsing the new advocacy section of the FreeBSD website, and found the following minor nit: You say that Netscape now produces a binary for FreeBSD. I do not know when you wrote this piece of text, so I do not know if it was true at the time of writing, but it is not true today. While there was a native version of NS Communicator for FreeBSD in the 4.x series, it died along with that old branch as soon as 6.x came along. Just as an aside, I am not sorry to see it go: It was in the "unsupported" section for as long as it existed, used a.out even years after FreeBSD had made the switch to ELF, necessitating a special collection of a.out X libraries to be installed (it was rumored that even if you compiled an a.out lib on your ELF-based machine it would not always work for NS, so there was a special port containing just the a.out libs for XFree86 3.3.x compiled on a 2.2.8 machine... brrrr. what a hack.) and of course there were almost no plugins for it. Today, if you want to use Netscape, you pretty much are stuck with the Linux version (the BSDi version died along with the 4.x series too, AFAIK) and, perhaps, you will be able to use the Solaris version on sparc64 some day (if such a version exists at all. I have not checked:-) Of course, if you are not fixated on the "N" logo in the throbber, Mozilla will work just as fine, and there *is* a native binary at least for each milestone build now (provided that something doesn't break it, in which case fixes tend to be slow...) built for the latest -RELEASE at the time of building. (so right now, for 4.5). Unfortunately, there is no nightly snapshot, but it should be a matter of someone donating the necessary time and resources to do it. Same goes for builds for -CURRENT. Also, plugins for Mozilla on FreeBSD start to appear: there is at least Java and Flash (although that one only for Flash 4.x which is not up-to-date and quite unstable at that too) Mozilla is both in the ports (updated for each milestone) or can be built effortlessly (at least on your part, machine may have a different opinion:-) from CVS as well. Please excuse this lenghty email, it was not my aim to tease your hard work, just wanted to make a small point and provide the background for it. I am not providing a patch because it is your choice to either skip this example altogether or to reword it as you see fit. Thanks for your attention! -- Regards: Szilveszter ADAM Szombathely, Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 11:29: 3 2002 Delivered-To: freebsd-doc@freebsd.org Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by hub.freebsd.org (Postfix) with ESMTP id 8911537B42B for ; Sat, 6 Apr 2002 11:28:33 -0800 (PST) Received: from [80.131.92.183] (helo=there) by smtp.web.de with smtp (WEB.DE(Exim) 4.43 #48) id 16tvrU-000713-00 for doc@FreeBSD.org; Sat, 06 Apr 2002 21:28:32 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Benny To: doc@FreeBSD.org Subject: Handbook NFS Date: Sat, 6 Apr 2002 21:25:49 +0000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! I'm not quite sure about this but I think there is a mistake in 17.4 NFS Documentation. "The following /etc/exports would be valid: /usr/src client /usr/ports client One filesystem, /usr, has two lines specifying exports to the same host, client. The correct format for this situation is: /usr/src /usr/ports client" Shouldn't it be "INvalid", because the state underneath is wrong?! Otherwise it doesn't make sense, does it? BYE BENNY PS If I'm wrong, sorry for bothering you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 11:34:25 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 80E2537B416 for ; Sat, 6 Apr 2002 11:34:20 -0800 (PST) Received: (from www@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g36JYKh54126 for freebsd-doc; Sat, 6 Apr 2002 11:34:20 -0800 (PST) (envelope-from www) Date: Sat, 6 Apr 2002 11:34:20 -0800 (PST) From: Message-Id: <200204061934.g36JYKh54126@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org Subject: FreeBSD web build failed on freefall.freebsd.org Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org install -C -o www -g www -m 664 /c/www/build/www/en/docproj/translations.html /usr/local/www/data/docproj install -C -o www -g www -m 664 /c/www/build/www/en/docproj/docproj.html /usr/local/www/data/docproj cd /usr/local/www/data/docproj; /bin/ln -fs docproj.html index.html ===> news install -C -o www -g www -m 664 /c/www/build/www/en/news/news.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/pressreleases.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/press-rel-1.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/press-rel-2.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/press-rel-3.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/press-rel-4.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/press-rel-5.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/sou1999.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/newsflash.html /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/news.rdf /usr/local/www/data/news install -C -o www -g www -m 664 /c/www/build/www/en/news/press.html /usr/local/www/data/news cd /usr/local/www/data/news; /bin/ln -fs news.html index.html ===> news/1996 install -C -o www -g www -m 664 /c/www/build/www/en/news/1996/index.html /usr/local/www/data/news/1996 ===> news/1997 install -C -o www -g www -m 664 /c/www/build/www/en/news/1997/index.html /usr/local/www/data/news/1997 ===> news/1998 install -C -o www -g www -m 664 /c/www/build/www/en/news/1998/index.html /usr/local/www/data/news/1998 ===> news/1999 install -C -o www -g www -m 664 /c/www/build/www/en/news/1999/index.html /usr/local/www/data/news/1999 ===> news/2000 install -C -o www -g www -m 664 /c/www/build/www/en/news/2000/index.html /usr/local/www/data/news/2000 ===> news/2001 install -C -o www -g www -m 664 /c/www/build/www/en/news/2001/index.html /usr/local/www/data/news/2001 ===> news/status install -C -o www -g www -m 664 /c/www/build/www/en/news/status/status.html /usr/local/www/data/news/status install -C -o www -g www -m 664 /c/www/build/www/en/news/status/report-june-2001.html /usr/local/www/data/news/status install -C -o www -g www -m 664 /c/www/build/www/en/news/status/report-july-2001.html /usr/local/www/data/news/status install -C -o www -g www -m 664 /c/www/build/www/en/news/status/report-august-2001.html /usr/local/www/data/news/status install -C -o www -g www -m 664 /c/www/build/www/en/news/status/report-september-2001.html /usr/local/www/data/news/status install -C -o www -g www -m 664 /c/www/build/www/en/news/status/report-november-2001.html /usr/local/www/data/news/status install -C -o www -g www -m 664 /c/www/build/www/en/news/status/report-dec-2001-jan-2002.html /usr/local/www/data/news/status install -C -o www -g www -m 664 /c/www/build/www/en/news/status/report-sample.xml /usr/local/www/data/news/status cd /usr/local/www/data/news/status; /bin/ln -fs status.html index.html ===> advocacy install -C -o www -g www -m 664 /c/www/build/www/en/advocacy/index.html /usr/local/www/data/advocacy install -C -o www -g www -m 664 /c/www/build/www/en/advocacy/myths.html /usr/local/www/data/advocacy install -C -o www -g www -m 664 /c/www/build/www/en/advocacy/letter.html /usr/local/www/data/advocacy install: /usr/local/www/data/advocacy/letter.html: chown/chgrp: Operation not permitted *** Error code 71 Stop in /c/www/build/www/en/advocacy. *** Error code 1 Stop in /c/www/build/www/en. 2.70 real 0.14 user 0.20 sys To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 12:28:15 2002 Delivered-To: freebsd-doc@freebsd.org Received: from smtp.hccnet.nl (smtp.hccnet.nl [62.251.0.13]) by hub.freebsd.org (Postfix) with ESMTP id 4825537B41A for ; Sat, 6 Apr 2002 12:28:13 -0800 (PST) Received: from there by smtp.hccnet.nl via uds104-60.dial.hccnet.nl [62.251.60.104] with SMTP for id WAA04978 (8.8.8/1.13); Sat, 6 Apr 2002 22:28:11 +0200 (MET DST) Message-Id: <200204062028.WAA04978@smtp.hccnet.nl> Content-Type: text/plain; charset="iso-8859-1" From: Ernst de Haan Organization: FreeBSD Project To: doc@FreeBSD.org Subject: Re: Hardware Notes for 4.5 Date: Sat, 6 Apr 2002 22:27:59 +0200 X-Mailer: KMail [version 1.3.2] References: <3CAA86DE.6030005@tenebras.com> In-Reply-To: <3CAA86DE.6030005@tenebras.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday 03 April 2002 06:36, Michael Sierchio wrote: > I suggest adding to the list of supported 802.11 PCMCIA devices: And to the list of ISDN cards the: Dynalink IS 64 PPH+ This card is slightly different from the Dynalink IS 64 PPH, which is already in the list of supported ISDN cards, I believe. Ernst (who used his PPH+ to send this mail ) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 13:29:17 2002 Delivered-To: freebsd-doc@freebsd.org Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by hub.freebsd.org (Postfix) with ESMTP id D5D7437B42C for ; Sat, 6 Apr 2002 13:29:00 -0800 (PST) Received: from localhost (c6.depaul-inst.pittsburgh.pa.us [192.168.1.6]) by pittgoth.com (8.11.6/8.11.6) with SMTP id g36LSu617926; Sat, 6 Apr 2002 16:28:56 -0500 (EST) (envelope-from darklogik@pittgoth.com) Date: Sat, 6 Apr 2002 16:36:54 -0500 From: Tom Rhodes To: Szilveszter Adam Cc: freebsd-doc@freebsd.org Subject: Re: minor nit re advocacy/myths.html Message-Id: <20020406163654.3bf80683.darklogik@pittgoth.com> In-Reply-To: <20020406183502.GA5126@fonix.adamsfamily.xx> References: <20020406183502.GA5126@fonix.adamsfamily.xx> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 6 Apr 2002 20:35:02 +0200 Szilveszter Adam wrote: Your fine Adam, i've cached this, and hopefully I can do something with this on Monday ;) Thanks alot though for pointing this out, if you want to, you can change it to Mozilla, otherwise, i'll grab it Monday hehe... Enjoy! > > Please excuse this lenghty email, it was not my aim to tease your > hard work, just wanted to make a small point and provide the > background for it. I am not providing a patch because it is your > choice to either skip this example altogether or to reword it as you > see fit. > > Thanks for your attention! > > -- > Regards: > > Szilveszter ADAM > Szombathely, Hungary > -- Tom (Darklogik) Rhodes www.FreeBSD.org -The Power To Serve www.Pittgoth.com -Pittgoth Discussion Portal trhodes@{Pittgoth.com, FreeBSD.org} PGP key by www: http://www.pittgoth.com/~darklogik/darklogik.key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 14:41: 6 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 1F00037B41E; Sat, 6 Apr 2002 14:40:48 -0800 (PST) Received: from hades.hell.gr (patr530-b187.otenet.gr [212.205.244.195]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g36Mee2a029297; Sun, 7 Apr 2002 01:40:42 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g36MeeGM001564; Sun, 7 Apr 2002 01:40:41 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g36MH9jF001309; Sun, 7 Apr 2002 01:17:09 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 7 Apr 2002 01:17:09 +0300 From: Giorgos Keramidas To: Murray Stokely Cc: freebsd-doc@freebsd.org Subject: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-ID: <20020406221709.GA1181@hades.hell.gr> References: <20020404062954.6607E2E827@mail.freebsdmall.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20020404062954.6607E2E827@mail.freebsdmall.com> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2002-04-03 22:29, Murray Stokely wrote: > We only include 1 paragraph on MUAs in the mail chapter of the FreeBSD > Handbook. This is very valuable information that new users need. We > should add at least 5 pages talking about installation and usage of > Mutt, Pine, fetchmail, the concepts of local Unix mailboxes vs POP3 / > IMAP. Available IMAP clients for FreeBSD. Pointer to the SSH > tunnelling section for these insecure protocols, etc.. On 2002-04-03 22:57, Murray Stokely wrote: > Chapter 18 of the Handbook only covers sendmail. Changes were > recently made to rc.conf to make it easier to install and use > alternative MTAs. We should document this configuration setting, and > describe the process of setting up Postfix and qmail to be the default > system MTA. I've putting a lot of thought, since a few months ago, to something that might sound nice regarding this and other things about our documentation set. Right now, we have the Handbook, which is a great tome of knowledge, split in parts, chapters, sections, subsections and so long and so forth. This is hard to search though. It's difficult for a newcomer to find his way around in this huge document. It is time, I think to separate the Handbook in smaller parts. The main thing that I was thinking about is how would one go about separating these parts. Putting related items together seems like a nice thing, so we shouldn't make the users dig in dozens of books to find all there is to know about using FreeBSD as (say) a dialup PPP gateway, a firewall, and a mail, web, whatever proxy. These two PRs, recently opened would be easy to handle if we had a collection of FreeBSD books, targeted to specific "functionality" aspects of FreeBSD. This is what helps in clearly separating the topics that each book or book collection will be about too. What are FreeBSD machines used for today? - Server machines. - Workstations. - (Both, but this can clearly be covered in the previous parts.) So, we need two book collections. One that talks about the administration of a FreeBSD server, and one that talks about using FreeBSD as a workstation for every day jobs. Right now, these two topics are covered in a variety of places, with some things being explained in the Handbook, other less important (?) or complicated things explained in articles, and yet more explained online at the Web site (for instance, mailings lists, subscriptions, unsubscriptions, etc.). By noting this, I do not mean to say that the existing documentation is not useful, or not organized, or that we should just throw it away. It represents the experience and work of dozens of contributors and developers, and the result of thousands of man hours of work. But what can we hope to achieve by splitting the documentation in server/workstation categories? Well, for one thing, PRs like the two quoted above will have an easy to spot place in the lot. We make a couple of new books titled "Internet Mail". The book that is part of the "System Administrator's Bookshelf" talks about MTAs, the default MTA of FreeBSD (in this case Sendmail), then alternative MTAs, their installation and configuration, about system-wide virus protection, POP or IMAP protocols, and software that needs to be installed to make them available to end-users, and other stuff that a system administrator needs to know about Internet Mail. The Internet Mail book that is part of the "FreeBSD User's Bookshelf" mentions that an MTA needs to be installed and configured by the system administrator, points to the "System Administrators's Bookshelf" for more details, and goes on to talk about MUA's like Mutt and Pine, about programs like fetchmail, procmail, or maildrop, and other things that an end-user will be interested to know regarding Internet Mail usage in his every day work. Something like this can not and will certainly not happen during a night time's hacking session. If it looks like a nice long-term goal though, perhaps we need to start splitting things off the Handbook. I'm taking this opportunity of Handbook lacking a detailed explanation of how Internet mail works, to propose making this a separate book. One part, two parts (sysadmin & user), it's not really important to have everything organized and working perfectly right from the beginning. What is important is, what do you all thing about doing this? I could start and write a small skeleton for something like this, but before going crazy about something it's nice to know if it's worth anything, if I can hope in having your help & assistance in writing those sections I'm not very good with, or if you'd prefer all this to stay in the existing Handbook, as a chapter, perhaps two. /me puts on the flame vest, and sits down waiting your comments patiently. Cheers, Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE8r3Pl1g+UGjGGA7YRArC0AJ0RYzQEYo72oBxFFtJXbhOkKbWA6QCfS/61 6yrtjGK8vZB7Fjim2n8y9mo= =aDZ0 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 14:52:40 2002 Delivered-To: freebsd-doc@freebsd.org Received: from core.radioactivedata.org (146-115-123-197.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [146.115.123.197]) by hub.freebsd.org (Postfix) with ESMTP id 4AF8037B404; Sat, 6 Apr 2002 14:52:05 -0800 (PST) Received: from radioactivedata.org (localhost [127.0.0.1]) by core.radioactivedata.org (8.12.2/8.9.3) with ESMTP id g36MnsBa091571; Sat, 6 Apr 2002 17:49:55 -0500 (EST) (envelope-from mbertsch@radioactivedata.org) Message-ID: <3CAF7B92.3060100@radioactivedata.org> Date: Sat, 06 Apr 2002 17:49:54 -0500 From: Mike DeGraw-Bertsch User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020317 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nik Clayton Cc: freebsd-doc@freebsd.org Subject: Re: docs/36723: IPSec section is unintelligible References: <200204061610.g36GA3i07554@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nik, Excellent article. My only concerns are that it doesn't cover X.509 certs, and only applies to VPNs. I'll agree that VPNs are probably the most common use for IPsec, but transport mode is still important and useful. The piece I was working on for th the handbook is more of a quick introduction to IPsec, followed by a guide to configuring racoon, and using transport and tunnel mode. I don't know which would be more useful to folks. Just wanted to share my thoughts. -Mike Nik Clayton wrote: > The following reply was made to PR docs/36723; it has been noted by GNATS. > > From: Nik Clayton > To: Murray Stokely > Cc: FreeBSD-gnats-submit@FreeBSD.org > Subject: Re: docs/36723: IPSec section is unintelligible > Date: Sat, 6 Apr 2002 17:05:41 +0100 > > --L0TNCHh3fkwjpuuE > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Wed, Apr 03, 2002 at 10:09:11PM -0800, Murray Stokely wrote: > > People often complain about the IPSec section in the FreeBSD Handbook. > > The material is in great need of clarification. > > Anyone feel like SGML'ifying this (and fleshing it out as necessary)? > It's been kicking around my hard disk for ages, and I never found the > need to finish it up. . . > > N > > /*- > * Copyright (c) 2001 Nik Clayton > * All rights reserved. > * > * Redistribution is not permitted. If you are reading this it's because t= > his > * is an early version of this article that I have put out for review. It = > is > * not finished, and I do not want copies that possibly provide incorrect > * information floating around the net. > * > * THIS DOCUMENTATION IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' = > AND > * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPO= > SE > * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTI= > AL > * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRI= > CT > * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > * SUCH DAMAGE > */ > > ToDo: > > Check the path of the racoon config file > > Talk about the racoon settings that talk about timeouts > > Talk about choosing a good value for "secret" in psk.txt > > Check that racoon without a policy still sets up security associations > > Get sample tcpdump output between encrypted networks > > Show how to configure Windows hosts with a WINS Server > > Show dhcpd.conf netbios config option. > > Creating a VPN between two networks, separated by the Internet, using FreeB= > SD > gateways. > > The Problem > > There's no standard for what constitutes a VPN. VPNs can be implemented > using a number of different technologies, each of which have their own > strengths and weaknesses. This article presents a number of scenarios, > and strategies for implementing a VPN for each scenario. > > Scenario #1: Two networks, connected to the Internet, to behave as one > > This is the scenario that caused me to first investigating VPNs. The > premise is as follows: > > * You have at least two sites > > * Both sites are using IP internally > > * Both sites are connected to the Internet, through a gateway that is > running FreeBSD. > > * The gateway on each network has at least one public IP address. > > * The internal addresses of the two networks can be public or private > IP addresses, it doesn't matter. You can be running NAT on the > gateway machine if necessary. > > * The internal IP addresses of the two networks DO NOT COLLIDE. Whi= > le > I expect it is theoretically possible to use a combination of VPN > technology and NAT to get this to work, I expect it to be a > configuration nightmare. > > If you find that you are trying to connect two networks, both of > which, internally, use the same private IP address range (e.g., both > of them use 192.168.1.x), then one of the networks will have to be > renumbered. > > I think it's now a law that every VPN article must feature some ASCII > artwork. This one is no exception. > > The network topology might look something like this: > > > Network #1 [ Internal Hosts ] Private Net, 192.168.1.2-2= > 54 > [ Win9x/NT/2K ] > [ Unix ] > | > | > .---[fxp1]---. Private IP, 192.168.1.1 > | FreeBSD | > `---[fxp0]---' Public IP, A.B.C.D > | > | > -=3D-=3D- Internet -=3D-=3D- > | > | > .---[fxp0]---. Public IP, W.X.Y.Z > | FreeBSD | > `---[fxp1]---' Private IP, 192.168.2.1 > | > | > Network #2 [ Internal Hosts ] > [ Win9x/NT/2K ] Private Net, 192.168.2.2-2= > 54 > [ Unix ] > > > Notice the two public IP addresses. I'll use the letters to refer to t= > hem > in the rest of this article. Anywhere you see those letters in this > article, replace them with your own public IP addresses. Note also that > that internally, the two gateway machines have .1 IP addresses, and that > the two networks have different private IP address (192.168.1.x and > 192.168.2.x respectively). All the machines on the private networks ha= > ve > been configured to use the .1 machine as their default gateway. > > The intention is that, from a network point of view, each network should > view the machines on the other network as though they were directly > attached the same router -- albeit a slightly slow router with an > occasional tendency to drop packets. > > This means that (for example), machine 192.168.1.20 should be able to r= > un > > ping 192.168.2.34 > > and have it work, transparently. Windows machines should be able to see > the machines on the other network, browse file shares, and so on, in > exactly the same way that they can browse machines on the local network. > > And the whole thing has to be secure. This means that traffic between = > the > two networks has to be encrypted. > > Creating a VPN between these two networks is a multi-step process. The > stages are as follows; > > 1. Create a "virtual" network link between the two networks, across > the Internet. Test it, using tools like ping(8), to make sure it > works. > > 2. Apply security policies to ensure that traffic between the two > networks is transparently encrypted and decrypted as necessary. > Test this, using toolks like tcpdump(8), to ensure that traffic is > encrypted. > > 3. Configure additional software on the FreeBSD gateways, to allow > Windows machines to see one another across the VPN. > > Step 1: Creating and testing a "virtual" network link > > Suppose that you were logged in to the gateway machine on network #1 (w= > ith > public IP address A.B.C.D, private IP address 192.168.1.1), and you ran > "ping 192.168.2.1", which is the private address of the machine with IP > address W.X.Y.Z. What needs to happen in order for this to work? > =20 > 1. The gateway machine needs to know how to reach 192.168.2.1. In > other words, it needs to have a route to 192.168.2.1. > > 2. Private IP addresses, such as those in the 192.168.x range are not > supposed to appear on the Internet at large. Instead, each packet > you send to 192.168.2.1 will need to be wrapped up inside another > packet. This packet will need to appear to be from A.B.C.D, and = > it > will have to be sent to W.X.Y.Z. This process is called > "encapsulation". > > 3. Once this packet arrives at W.X.Y.Z it will need to > "unencapsulated", and delivered to 192.168.2.1. > > You can think of this as requiring a "tunnel" between the two networks. > The two "tunnel mouths" are the IP addresses A.B.C.D and W.X.Y.Z, and t= > he > tunnel must be told the addresses of the private IP addresses that will= > be > allowed to pass through it. The tunnel is used to transfer traffic with > private IP addresses across the public Internet. > > This tunnel is created by using the generic interface, or "gif" devices= > on > FreeBSD. As you can imagine, the gif interface on each gateway host mu= > st > be configured with four IP addresses; two for the public IP addresses, = > and > two for the private IP addresses. > > Support for the gif device must be compiled in to the FreeBSD kernel on > both machines. You can do this by adding the line > > pseudo-device gif > > to the kernel configuration files on both machines, and then compile, > install, and reboot as normal. > > Configuring the tunnel is a two step process. First the tunnel must be > told what the outside (or public) IP addresses are, using gifconfig(8). > Then the private IP addresses must be configured using ifconfig(8). > > On the gateway machine on network #1 you would run the following two > commands to configure the tunnel. > > gifconfig gif0 A.B.C.D W.X.Y.Z > ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff > > On the other gateway machine you run the same commands, but with the or= > der > of the IP addresses reversed. > > gifconfig gif0 W.X.Y.Z A.B.C.D > ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff > > You can then run=20 > > gifconfig gif0 > > to see the configuration. For example, on the network #1 gateway, you > would see this > > # gifconfig gif0 > gif0: flags=3D8011 mtu 1280 > inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff > physical address inet A.B.C.D --> W.X.Y.Z > > As you can see, a tunnel has been created between the physical addresses > A.B.C.D and W.X.Y.Z, and the traffic allowed through the tunnel is that > between 192.168.1.1 and 192.168.2.1. > > This will also have added an entry to the routing table on both machine= > s, > which you can examine with "netstat -rn". This output is from the gate= > way > host on network #1. > > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > ... > 192.168.2.1 192.168.1.1 UH 0 0 gif0 > ... > > As the "Flags" value indicates, this is a host route, which means that > each gateway knows how to reach the other gateway, but they do not know > how to reach the rest of their respective networks. That problem will = > be > fixed shortly. > > It is likely that you are running a firewall on both machines. This wi= > ll > need to be circumvented for your VPN traffic. You might want to allow = > all > traffic between both networks, or you might want to include firewall ru= > les > that protect both ends of the VPN from one another. > > It greatly simplifies testing if you configure the firewall to allow all > traffic through the VPN. You can always tighten things up later. If y= > ou > are using ipfw(8) on the gateway machines then a command like > > ipfw add 1 allow ip from any to any via gif0 > > will allow all traffic between the two end points of the VPN, without > affecting your other firewall rules. Obviously you will need to run th= > is > command on both gateway hosts. > > This is sufficient to allow each gateway machine to ping the other. On > 192.168.1.1 you should be able to run > > ping 192.168.2.1 > > and get a response, and you should be able to do the same thing on the > other gateway machine. > > However, you will not be able to reach internal machines on either netw= > ork > yet. This is because of the routing -- although the gateway machines k= > now > how to reach one another, they do not know how to reach the network beh= > ind > each one. > > To solve this problem you must add a static route on each gateway > machine. The command to do this on the first gateway would be: > > route add 192.168.2.0 192.168.2.1 netmask 0xffffff00 > > This says "In order to reach the hosts on the network 192.168.2.0, send > the packets to the host 192.168.2.1". You will need to run a similar > command on the other gateway, but with the 192.168.1.x addresses instea= > d. > > IP traffic from hosts on one network will now be able to reach hosts on > the other network.=20 > > That has now created two thirds of a VPN between the two networks, in as > much as it's "virtual" and it's a "network". It's not private yet. You > can test this using ping(8) and tcpdump(8). Log in to the gateway host > and run > > tcpdump dst host 192.168.2.1 > > In another log in session on the same host run > > ping 192.168.2.1 > > You will see output that looks something like this. > > 16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request > 16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply > 16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request > 16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply > 16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request > 16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply > > As you can see, the ICMP messages are going back and forth unencrypted. > If you had used the "-s" parameter to tcpdump(8) to grab more bytes of > data from the packets you would see more information. > > Obviously this is unacceptable. The next section will discuss securing > the link between the two networks so that it all traffic is automatical= > ly > encrypted. > > Summary: > > * Configure both kernels with "pseudo-device gif" > > * Edit /etc/rc.conf on gateway host #1 and add the following lines=20 > (replacing IP addresses as necessary). > > gifconfig_gif0=3D"A.B.C.D W.X.Y.Z" > ifconfig_gif0=3D"inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" > static_routes=3D"vpn" > route_vpn=3D"192.168.2.0 192.168.2.1 netmask 0xffffff00" > > * Edit your firewall script (/etc/rc.firewall, or similar) on both > hosts, and add > =20 > ipfw add 1 allow ip from any to any via gif0 > > * Make similar changes to /etc/rc.conf on gateway host #2, reversing = > the > order of IP addresses. > > Step 2: Securing the link > > To secure the link we will be using IPSec. IPSec provides a mechanism = > for > two hosts to agree on an encryption key, and to then use this key in or= > der > to encrypt data between the two hosts. > > The are two areas of configuration to be considered here. > > 1. There must be a mechanism for two hosts to agree on the encryption > mechanism to use. Once two hosts have agreed on this mechanism > there is said to be a "security association" between them. > > 2. There must be a mechanism for specifying which traffic should be > encrypted. Obviously, you don't want to encrypt all your outgoing > traffic -- you only want to encrypt the traffic that is part of the > VPN. The rules that you put in place to determine what traffic will > be encrypted are called "security policies". > > Security associations and security policies are both maintained by the > kernel, and can be modified by userland programs. However, before you = > can > do this you must configure the kernel to support IPSec and the > Encapsulated Security Payload (ESP) protocol. This is done by configur= > ing > a kernel with > > options IPSEC > options IPSEC_ESP > > and recompiling, reinstalling, and rebooting. As before you will need = > to > do this to the kernels on both of the gateway hosts. > > You have two choices when it comes to setting up security associations. > You can configure them by hand between two hosts, which entails choosing > the encryption algorithm, encryption keys, and so forth, or you can use > daemons that implement the Internet Key Exchange protocol (IKE) to do t= > his > for you. > > I recommend the latter. Apart from anything else, it's easier to set u= > p. > > Editing and displaying security policies is carred out using setkey(8). > By analogy, setkey(8) is to the kernel's security policy tables as > route(8) is to the kernel's routing tables. setkey(8) can also display > the current security associations, and to continue the analogy further,= > is > akin to "netstat -r" in that respect. > > There are a number of choices for daemons to manage security associatio= > ns > with FreeBSD. This article will describe how to use one of these, raco= > on. > racoon is in the FreeBSD ports collection, in the security/ category, a= > nd > is installed in the usual way. > > racoon must be run on both gateway hosts. On each host it is configured > with the IP address of the other end of the VPN, and a secret key (which > you choose, and must be the same on both gateways). > > The two daemons then contact one another, confirm that they are who they > say they are (by using the secret key that you configured). The daemons > then generate a new secret key, and use this to encrypt the traffic over > the VPN. They periodically change this secret, so that even if an > attacker were to crack one of the keys (which is as theoretically close= > to > unfeasible as it gets) it won't do them much good -- by the time they've > cracked the key the two daemons have chosen another one. > > racoon's configuration is stored in ${PREFIX}/etc/racoon. You should f= > ind > a configuration file there, which should not need to be changed too muc= > h. > The other component of racoon's configuration, which you will need to > change, is the 'pre-shared key'. > > The default racoon configuration expects to find this in the file > ${PREFIX}/etc/racoon/psk.txt. It is important to note that the pre-sha= > red > key is *not* the key that will be used to encrypt your traffic across t= > he > VPN link, it is simply a token that allows the key management daemons to > trust one another. > =20 > psk.txt contains a line for each remote site you are dealing with. In > this example, where there are two sites, each psk.txt file will contain > one line (because each end of the VPN is only dealing with one other en= > d). > > On gateway host #1 this line should look like this: > > W.X.Y.Z secret > > That is, the *public* IP address of the remote end, whitespace, and a t= > ext > string that provides the secret. Obviously, you shouldn't use "secret"= > as > your key -- the normal rules for choosing a password apply. > > On gateway host #2 the line would look like this > > A.B.C.D secret > > That is, the public IP address of the remote end, and the same secret k= > ey. > psk.txt must be mode 0600 (i.e., only read/write to root) before racoon > will run. > > You must run racoon on both gateway machines. You will also need to add > some firewall rules to allow the IKE traffic, which is carried over UDP= > to > the isakmp (kmp =3D=3D key management protocol) port. Again, this shou= > ld be > fairly early in your firewall ruleset. > > ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp > ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp > > Once racoon is running you can try pinging one gateway host from the > other. The connection is still not encrypted, but racoon will then set= > up > the security associations between the two hosts -- this might take a > moment, and you may see this as a short delay before the ping commands > start responding. > > Once the security association has been set up you can view it using > setkey(8). Run > > setkey -D > > on either host to view the security assocation information. > > That's one half of the problem. They other half is setting your securi= > ty > policies. =20 > > To create a sensible security policy, let's review what's been set up so > far. This discussions hold for both ends of the link. > > Each IP packet that you send out has a header that contains data about = > the > packet. The header includes the IP addresses of both the source and > destination. As we already know, private IP addresses, such as the > 192.168.x.y range are not supposed to appear on the public Internet. > Instead, they must first be encapsulated inside another packet. This > packet must have the public source and destination IP addresses > substituted for the private addresses. > > So if your outgoing packet started looking like this: > > .----------------------. > | Src: 192.168.1.1 | > | Dst: 192.168.2.1 | > | | > +----------------------+ > | | > `----------------------' > > Then it will be encapsulated inside another packet, looking something l= > ike > this: > > .--------------------------. > | Src: A.B.C.D | > | Dst: W.X.Y.Z | > | | > +--------------------------+ > | .----------------------. | > | | Src: 192.168.1.1 | | > | | Dst: 192.168.2.1 | | > | | | | > | +----------------------+ | > | | | | > | `----------------------' | > `--------------------------' > > This encapsulation is carried out by the gif device. As you can see, t= > he > packet now has real IP addresses on the outside, and our original packet > has been wrapped up as data inside the packet that will be put out on t= > he > Internet. > > Obviously, we want all traffic between the VPNs to be encrypted. You > might try putting this in to words, as=20 > > If a packet leaves from A.B.C.D, and it is destined for W.X.Y.Z, then > encrypt it, using the necessary security associations. > > If a packet arrives from W.X.Y.Z, and it is destined for A.B.C.D, then > decrypt it, using the necessary security associations. > > That's close, but not quite right. If you did this, all traffic to > and from W.X.Y.Z, even traffic that was not part of the VPN, would be > encrypted. That's not quite what you want. The correct policy is as > follows > > If a packet leaves from A.B.C.D, and that packet is encapsulating > another packet, and it is destined for W.X.Y.Z, then encrypt it, using > the necessary security associations. > > If a packet arrives from W.X.Y.Z, and that packet is encapsulating > another packet, and it is destined for A.B.C.D, then encrypt it, using > the necessary security associations. > > A subtle change, but a necessary one. > > Security policies are also set using setkey(8). > > Unfortunately, setkey(8), and the related code, is under almost constant > development. And the version of setkey(8) included in FreeBSD 4.3 does= > n't > quite handle this properly. > > If you're using a version of FreeBSD-stable built after 3rd July 2001 > (that includes FreeBSD 4.4 and later) then you have the necessary fixes. > If you are using an earlier version, including FreeBSD 4.3 and below th= > en > you need to make a very small change to the setkey(8) source code, and > then recompile it and reinstall it. > > Without this change, setkey(8) won't allow you to specify the rule to > correctly match encapsulated packets. > > The change is very simple. > > 1. Acquire a copy of the FreeBSD source code for the version of > FreeBSD you are running. > > 2. Change to the src/usr.sbin/setkey/ directory. > > 3. Edit the file token.l. Find the four lines that look like this: > > icmp { PREPROC; yylval.num =3D IPPROTO_ICMP; return(UP_PROTO= > ); } > icmp6 { PREPROC; yylval.num =3D IPPROTO_ICMPV6; return(UP_PRO= > TO); } > tcp { PREPROC; yylval.num =3D IPPROTO_TCP; return(UP_PROTO)= > ; } > udp { PREPROC; yylval.num =3D IPPROTO_UDP; return(UP_PROTO)= > ; } > > and add this line > > ipencap { PREPROC; yylval.num =3D IPPROTO_IPV4; return(UP_PROTO= > ); } > > after them. > > 4. Rebuild and reinstall setkey(8) by running "make install". > > Once you have done this you can configure the security policy. setkey(= > 8) > features a configuration language for defining the policy. You can eit= > her > enter configuration instructions via stdin, or you can use the -f option > to specify a filename that contains configuration instructions. =20 > > The configuration on gateway host #1 (which has the public IP address > A.B.C.D) to force all outbound traffic to W.X.Y.Z to be encrypted is > > spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec > esp/tunnel/A.B.C.D-W.X.Y.Z/require; > > Put these commands in a file (e.g., /etc/ipsec.conf) and then run=20 > > setkey -f /etc/ipsec.conf > > "spdadd" tells setkey(8) that we want to add a rule to the secure policy > database. The rest of this line specifies which packets will match this > policy. "A.B.C.D/32" and "W.X.Y.Z/32" are the IP addresses and netmasks > that identify the network or hosts that this policy will apply to. In > this case, we want it to apply to traffic between these two hosts. > "ipencap" tells the kernel that this policy should only apply to packets > that encapsulate other packets. "-P out" says that this policy applies= > to > outgoing packets, and "ipsec" says that the packet will be secured. > > The second line specifies how this packet will be encrypted. "esp" is = > the > protocol that will be used, while "tunnel" indicates that the packet wi= > ll > be further encapsulated in an IPSec packet. The repeated use of A.B.C.D > and W.X.Y.Z is used to select the security association to use, and the > final "require" mandates that packets must be encrypted if they match t= > his > rule. > > This rule only matches outgoing packets. You will need a similar rule = > to > match incoming packets. > > spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec > esp/tunnel/W.X.Y.Z-A.B.C.D/require; > > Note the "in" instead of "out" in this case, and the necessary reversal= > of > the IP addresses. > > The other gateway host (which has the public IP address W.X.Y.Z) will n= > eed > similar rules. > > spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec > esp/tunnel/W.X.Y.Z-A.B.C.D/require; > spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec > esp/tunnel/A.B.C.D-W.X.Y.Z/require; > > Finally, you need to add firewall rules to allow ESP and IPENCAP packets > back and forth. These rules will need to be added to both hosts. > > ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z > ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D > ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z > ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D > > Because the rules are symmetric you can use the same rules on each gate= > way > host. > > Outgoing packets will now look something like this. > > .------------------------------. --------------------------. > | Src: A.B.C.D | | > | Dst: W.X.Y.Z | | > | | | Encrypt= > ed > +------------------------------+ | packet. > | .--------------------------. | -------------. | contents > | | Src: A.B.C.D | | | | are=20 > | | Dst: W.X.Y.Z | | | | complet= > ely > | | | | | |- secure > | +--------------------------+ | | Encap'd | from th= > ird > | | .----------------------. | | -. | packet | party > | | | Src: 192.168.1.1 | | | | Original |- with real | snooping > | | | Dst: 192.168.2.1 | | | | packet, | IP addr | > | | | | | | |- private | | > | | +----------------------+ | | | IP addr | | > | | | | | | | | | > | | `----------------------' | | -' | | > | `--------------------------' | -------------' | > `------------------------------' --------------------------' > > When they are received by the far end of the VPN they will first be > decrypted (using the security associations that have been negotiated by > racoon). Then they will enter the gif interface, which will unwrap the > second layer, until you are left with the innermost packet, which can t= > hen > travel in to the inner network. > > You can check the security using the same ping(8) test from earlier. > First, log in to the A.B.C.D gateway machine, and run > > tcpdump dst host 192.168.2.1 > > In another log in session on the same host run > > ping 192.168.2.1 > > This time you should see output like the following: > > > > Now, as you can see, tcpdump(8) shows the ESP packets. If you try and > examine them with the -s option you will see (apparently) gibberish, > because of the encryption. > > Congratulations. You have just set up a VPN between two remote sites. > > Summary: > > * Configure both kernels with=20 > > options IPSEC > options IPSEC_ESP > > * Install ports/security/racoon. Edit ${PREFIX}/etc/racoon/psk.txt on > both gateway hosts, adding an entry for the remote host's IP address > and a secret key that they both know. Make sure this file is mode > 0600. > > * If necessary, make the one line change to src/usr.sbin/setkey/token= > .l, > then recompile and reinstall setkey(8). > > * Add the following lines to /etc/rc.conf on each host > > ipsec_enable=3D"YES" > ipsec_file=3D"/etc/ipsec.conf" > > * Create an /etc/ipsec.conf on each host that contains the necessary > spdadd lines. On gateway host #1 this would be > > spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec > esp/tunnel/A.B.C.D-W.X.Y.Z/require; > spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec > esp/tunnel/W.X.Y.Z-A.B.C.D/require; > > On gateway host #2 this would be > > spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec > esp/tunnel/W.X.Y.Z-A.B.C.D/require; > spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec > esp/tunnel/A.B.C.D-W.X.Y.Z/require; > > * Add firewall rules to allow IKE, ESP, and IPENCAP traffic to both > hosts > > ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp > ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp > ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z > ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D > ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z > ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D > > Step 3: All the horrible Windows related configuration you need to do > > The previous two steps should suffice to get the VPN up and running. > Machines on each network will be able to refer to one another using IP > addresses, and all traffic across the link will be automatically and > securely encrypted. > > So far so good. However, you probably have hosts running various flavo= > urs > of Windows at each site, and you would like to have them all appear in = > the > "Network Neighbourhood" or equivalent. > > Out of the box, this won't work. This is because the SMB protocol, aro= > und > which Windows' file sharing and related activities are based, was not > originally designed for use on more than one subnet (or, indeed, for IP > networks). Over time a number of kludges have been bolted on to the > protocol to correct for these deficiencies, and you will need to implem= > ent > them before browsing will work. > > You should note that you don't need FreeBSD machines to do most of what > follows. I think Windows NT or Windows 2000 hosts acting as domain > controllers will also do the right thing. Of course, if you don't have > any NT or 2000 hosts, and you don't feel like paying for the priviledge, > you can use FreeBSD to do all this for you as well. > > At this point our network is composed of two subnets, 192.168.1.x, and > 192.168.2.x. In order for the "Network Neighbourhood" to work properly= > , a > number of things need to be configured. > > 1. All your machines need to be configured to be in the same > workgroup. For the rest of the examples I will use the workgroup > name "WORKGROUP". You should, of course, change this to what ever > you are using. > > 2. Each subnet needs to have a host acting as a "local master browse= > r". > This a Windows term. The local master browser is responsible for > maintaining a list of all the hosts on the network. When a Windo= > ws > machine needs to find a list of all the other hosts on the network > it sends a broadcast message out saying "Who is the local master > browser?". The local master then replies, and the Windows host c= > an > then query the local master for a list of all the hosts on the sa= > me > subnet. > > There should be one local master browser per subnet. > > 3. Of course, this only works within a subnet. In order for this to= > =20 > work across subnets, one host has to be the "domain master > browser". The domain master browser maintains a complete list of > all the hosts on all the subnets. This is done by having all the > local master browsers send it updates periodically. Without a > domain master browser your Network Neighbourhood will not show up > hosts in other subnets. > > There should only be one domain master browser. > > 4. Windows network is based on the Netbios protocol. This has a > concept of hostnames, but it is different from the IP concept of > hostnames. Netbios name look ups do not normally work across > subnets. > > In order to work around this, one machine (and only one) machine > should be designated a "WINS Server". The WINS Server is normally > the same host as the domain master browser. It is the > responsibility of the WINS Server to maintain the mapping of Netbios > host names to IP addresses. Without this mapping, your Network > Neighbourhood will show hosts in other subnets (because of the local > master browser -> domain master browser communication) but your > Windows hosts in another network will not be able to communicate > with them, because they will not be able to convert their Netbios > names in to IP addresses. > > There can only be one WINS Server per network (note: not per subn= > et, > per network), and every other host needs to know its IP address. > > That's the bare minimum you need to get started. Now you need to design > your network. > > For the sake of this example, we will assume that you have two more > FreeBSD hosts, one on each subnet. Lets give these the IP addressess > 192.168.1.2 and 192.168.2.2 respectively, and make them responsible for > coordinating the Windows network and allowing browsing across the VPN to > work. These machines might also have file shares on them, but this > article will not touch on that, as it's trivial to set up, and well > documented. > > Recall that we will need two local master browsers, one domain master > browser, and one WINS server. > > To keep things simple, 192.168.1.2 will be a local master browser, the > domain master browser, and the WINS Server. 192.168.2.2 will be the lo= > cal > master browser for its network, and will send updates to the domain mas= > ter > browser. > > You should install Samba, from ports/net/samba/, on both hosts. Samba's > configuration file is ${PREFIX}/etc/smb.conf. > > Both hosts will share some configuration information, since they will b= > oth > be acting as a local master browser. > > Edit ${PREFIX}/etc/smb.conf and add the following lines: > > [global] > ; The network workgroup > workgroup =3D WORKGROUP > > ; The name for this server, as it will appear in the=20 > ; Network Neighbourhood > server string =3D Samba Server > > ; Hosts that will be allowed to access this server > hosts allow =3D 192.168.1. 192.168.2. 127. > > ; Template for generating log files > log file =3D /var/log/log.%M > > ; This host is a local master. It is the preferred master, and the > ; os level is set high enough that it will be chosen in preference > ; to every other host on the network, should that eventuality > ; arise. > local master =3D yes > preferred master =3D yes > os level =3D 65 > > The per-host configuration is as follows. > > 192.168.1.2 is the WINS Server and domain master. Add these lines to t= > he > bottom of the "[global]" section in the configuration file. > > ; This host is the domain master for the whole network. > domain master =3D yes > > ; This host will act as a WINS Server. > wins support =3D yes > > 192.168.2.2 is neither of these. The lines to add for that are > > ; This host will not be the domain master. > domain master =3D no > > ; This host is not a WINS Server, but it needs to know the address > ; of the WINS Server > wins server =3D 192.168.1.2 > > Make sure that the Samba daemons (smbd(8) and nmbd(8)) are running on b= > oth > machines. > > Now you need to configure your Windows client machines. Specifically, > they need to know the address of the WINS Server (192.168.1.2). There = > are > two ways you can do this. > > 1. If you are 'statically' configuring the hosts then this informati= > on > can be entered by doing Start -> Control Panel -> Network -> ... > > 2. Alternatively, if you are using DHCP then must DHCP servers can > be configured to provide this information. If you use the ISC DH= > CPD > then the relevant line to add to the configuration file is=20 > > options ... > --=20 > FreeBSD: The Power to Serve http://www.freebsd.org/ (__) > FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) > \/ \= > ^ > --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= > _) > > --L0TNCHh3fkwjpuuE > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (FreeBSD) > Comment: For info see http://www.gnupg.org > > iEYEARECAAYFAjyvHNAACgkQk6gHZCw343U5ogCdFF4HViejvE/Yt74SdB/2vRh9 > 9c8AnA8wy+JL7g35a8021HcxgFhXuVK9 > =XYDt > -----END PGP SIGNATURE----- > > --L0TNCHh3fkwjpuuE-- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-doc" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 15:11:32 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mao.stokely.org (mao.stokely.org [65.84.64.228]) by hub.freebsd.org (Postfix) with ESMTP id 47BD437B41C; Sat, 6 Apr 2002 15:11:27 -0800 (PST) Received: by mao.stokely.org (Postfix, from userid 2074) id F278F4B669; Sat, 6 Apr 2002 15:11:26 -0800 (PST) Date: Sat, 6 Apr 2002 15:11:26 -0800 From: Murray Stokely To: Giorgos Keramidas Cc: Murray Stokely , freebsd-doc@freebsd.org Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-ID: <20020406231126.GP5732@freebsdmall.com> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <20020406221709.GA1181@hades.hell.gr> User-Agent: Mutt/1.3.25i X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Apr 07, 2002 at 01:17:09AM +0300, Giorgos Keramidas wrote: > This is hard to search though. It's difficult for a newcomer to find his > way around in this huge document. It is time, I think to separate the > Handbook in smaller parts. The main thing that I was thinking about is how It's been time for over 4 years, we've just never identified the first concrete step to move in that direction. > - Server machines. > - Workstations. > - (Both, but this can clearly be covered in the previous parts.) I think that the 3rd printed edition (which I've obviously been doing some initial planning for) should be split into two books along these lines. I was planning on a "User's Guide" and an "Administrator's Guide". If the FreeBSD Documentation Project makes further subdivisions into smaller books, they can be mapped into these two categories for print publication purposes. A collection of smaller books is not practical for U.S. retail shelves, although if done right it can make online browsing easier. > But what can we hope to achieve by splitting the documentation in > server/workstation categories? Well, for one thing, PRs like the two The model you outlined works well for docs.sun.com, where tens of thousands of pages of documentation are available. I'm definitely in favor of higher level "collections" that can contain books / articles on similar topics. For the 2nd Edition Handbook, we pulled in one of the articles to supplement a chapter of the Handbook that was lacking. We've gained many new articles since that time, so this sort of overlap will become increasingly apparent. > Internet mail works, to propose making this a separate book. One > part, two parts (sysadmin & user), it's not really important to have > everything organized and working perfectly right from the beginning. > What is important is, what do you all thing about doing this? I could I don't think splitting off one chapter of the Handbook is a good place to start. I would rather start by splitting the Handbook in two. If you just split this one chapter off, then you are stuck with a weird inconsistency for as long as it takes us to finish the work ("Everything is in the handbook, ohh except for Internet Mail, that is in a separate section"). If you start off by splitting the Handbook in two based on the existing divisions of the book ("Getting Started", and "System Administration", with the appendices split between the two as appropriate), then you don't sacrifice consistency in any way. > if I can hope in having your help & assistance in writing those > sections I'm not very good with, or if you'd prefer all this to stay > in the existing Handbook, as a chapter, perhaps two. Above all else, I'd just like to see the content available, no matter where it ends up. ;) - Murray --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE8r4CdtNcQog5FH30RAsh3AJ9H7KjcgFTkWvwnAeV/uZn5f9W5MgCgxnqi Y+hIwD66bKvbB9KIDQ0GMlE= =giav -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 15:54:11 2002 Delivered-To: freebsd-doc@freebsd.org Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by hub.freebsd.org (Postfix) with ESMTP id B4B9C37B404; Sat, 6 Apr 2002 15:54:07 -0800 (PST) Received: from localhost (c6.depaul-inst.pittsburgh.pa.us [192.168.1.6]) by pittgoth.com (8.11.6/8.11.6) with SMTP id g36Ns6618160; Sat, 6 Apr 2002 18:54:06 -0500 (EST) (envelope-from darklogik@pittgoth.com) Date: Sat, 6 Apr 2002 19:02:04 -0500 From: Tom Rhodes To: Murray Stokely Cc: keramida@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-Id: <20020406190204.21cad8a8.darklogik@pittgoth.com> In-Reply-To: <20020406231126.GP5732@freebsdmall.com> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> <20020406231126.GP5732@freebsdmall.com> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 6 Apr 2002 15:11:26 -0800 Murray Stokely wrote: Hands up from this end. The current handbook is very large, if it keeps growing (and come one everyone, we know it will) then eventually it shall become the ``big book noone likes to carry'' or some other hefty collection of information. A users section containing information on various things like: PPP for the end user Mail for the end user Installing FreeBSD (end users in mind) Configureing FreeBSD (again, end users) Ports Simple tasks Networking for the End User. And so on, each book should contain: Ports and packages installation System Installation and Configuration Rebuilding your Kernel Staying up to date *cutting edge* (some people may want this) And the back of these books (printed versions) and online listings should contain the information that is presented within, so that people know exactly what they are getting... I'll help in whatever way its needed, lets just stop talking and start doing! -- Tom (Darklogik) Rhodes www.FreeBSD.org -The Power To Serve www.Pittgoth.com -Pittgoth Discussion Portal trhodes@{Pittgoth.com, FreeBSD.org} PGP key by www: http://www.pittgoth.com/~darklogik/darklogik.key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 16:12:45 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mao.stokely.org (mao.stokely.org [65.84.64.228]) by hub.freebsd.org (Postfix) with ESMTP id 3667F37B404; Sat, 6 Apr 2002 16:11:55 -0800 (PST) Received: by mao.stokely.org (Postfix, from userid 2074) id 03AB24B669; Sat, 6 Apr 2002 16:11:49 -0800 (PST) Date: Sat, 6 Apr 2002 16:11:48 -0800 From: murray@stokely.org To: Tom Rhodes Cc: Murray Stokely , keramida@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-ID: <20020407001148.GA8008@freebsdmall.com> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> <20020406231126.GP5732@freebsdmall.com> <20020406190204.21cad8a8.darklogik@pittgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020406190204.21cad8a8.darklogik@pittgoth.com> User-Agent: Mutt/1.3.25i X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Apr 06, 2002 at 07:02:04PM -0500, Tom Rhodes wrote: > And so on, each book should contain: > > Ports and packages installation > System Installation and Configuration > Rebuilding your Kernel > Staying up to date *cutting edge* (some people may want this) That is over 130 pages of content. I do NOT think all of that material should be repeated in each book. That material should just be in the "Getting Started" guide, or other appropriately named guides. > And the back of these books (printed versions) and online listings > should contain the information that is presented within, so that > people know exactly what they are getting... Each book needs to have a preface, table of contents, and introduction, to describe the material contained therein. - Murray To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 16:44: 3 2002 Delivered-To: freebsd-doc@freebsd.org Received: from venus.sun.com (venus.Sun.COM [192.9.25.5]) by hub.freebsd.org (Postfix) with ESMTP id 7971D37B405; Sat, 6 Apr 2002 16:44:00 -0800 (PST) Received: from custmail.sun.com (custmail.sun.com [192.18.97.201]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12862; Sat, 6 Apr 2002 16:43:54 -0800 (PST) Received: from mysun.com ([192.18.97.201]) by custmail.sun.com (Netscape Messaging Server 4.15) with ESMTP id GU69X600.HH5; Sat, 6 Apr 2002 17:41:30 -0700 From: "Hiten Pandya" To: Tom Rhodes Cc: Murray Stokely , Giorgos Keramidas , freebsd-doc@FreeBSD.org Reply-To: hiten@uk.FreeBSD.org Message-ID: <365fa359a3.359a3365fa@mysun.com> Date: Sun, 07 Apr 2002 00:41:30 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) X-Accept-Language: en X-Priority: 1 (Highest) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Tom Rhodes wrote: > On Sat, 6 Apr 2002 15:11:26 -0800 > Hands up from this end. The current handbook is very large, if it > keeps growing (and come one everyone, we know it will) then eventually > it shall become the ``big book noone likes to carry'' or some other > hefty collection of information. Also, it would be great to split up the handbook into say: o User Guide - This will allow us to fill this guide with more user centric content, on various things such as "IRC on FreeBSD", and the jazz.. o Admin Guide - This will allow us to fill it with more information on the various chapters we have got on administrations, such as vinum, ccd, also performance tuning. And also to convert some articles into (admin) handbook chapters such as the java-tomcat article, which murray pointed out a short while ago, and the like. So, its a hands up from this end as well. Although this would take quite a while to accomplish. :) -- Hiten Pandya Finger hiten@storm.uk.FreeBSD.org for PGP public key --- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 17: 2:10 2002 Delivered-To: freebsd-doc@freebsd.org Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by hub.freebsd.org (Postfix) with ESMTP id EDAF537B420; Sat, 6 Apr 2002 17:01:45 -0800 (PST) Received: from localhost (c6.depaul-inst.pittsburgh.pa.us [192.168.1.6]) by pittgoth.com (8.11.6/8.11.6) with SMTP id g3711e618255; Sat, 6 Apr 2002 20:01:40 -0500 (EST) (envelope-from darklogik@pittgoth.com) Date: Sat, 6 Apr 2002 20:09:38 -0500 From: Tom Rhodes To: murray@stokely.org Cc: keramida@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-Id: <20020406200938.23dd2ef4.darklogik@pittgoth.com> In-Reply-To: <20020407001148.GA8008@freebsdmall.com> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> <20020406231126.GP5732@freebsdmall.com> <20020406190204.21cad8a8.darklogik@pittgoth.com> <20020407001148.GA8008@freebsdmall.com> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 6 Apr 2002 16:11:48 -0800 murray@stokely.org wrote: > On Sat, Apr 06, 2002 at 07:02:04PM -0500, Tom Rhodes wrote: > > And so on, each book should contain: > > > > Ports and packages installation > > System Installation and Configuration > > Rebuilding your Kernel > > Staying up to date *cutting edge* (some people may want this) > > That is over 130 pages of content. I do NOT think all of that > material should be repeated in each book. That material should just > be in the "Getting Started" guide, or other appropriately named > guides. I figured, and yes I know ``figured'' is not usually the best way to go, but anyway I figured it would probly be helpful for people. But this would need more discussing. What I mainly am getting at, is that it might not be the best idea for that information to only be in one printed book, as it could pertain to new users and competant sysadmins at the same time... Thoughts? > > > And the back of these books (printed versions) and online listings > > should contain the information that is presented within, so that > > people know exactly what they are getting... > > Each book needs to have a preface, table of contents, and > introduction, to describe the material contained therein. You are correct, this information should be in the front, but I feel strongly that some information should be on the back. I know that i'm talking of printed versions, and not online versions, and most people will agree that the back description is of importance also. I usually read that part ;) > > - Murray > -- Tom (Darklogik) Rhodes www.FreeBSD.org -The Power To Serve www.Pittgoth.com -Pittgoth Discussion Portal trhodes@{Pittgoth.com, FreeBSD.org} PGP key by www: http://www.pittgoth.com/~darklogik/darklogik.key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 17:24:41 2002 Delivered-To: freebsd-doc@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id 13F7F37B41A for ; Sat, 6 Apr 2002 17:24:30 -0800 (PST) Received: (qmail 60259 invoked by uid 3130); 7 Apr 2002 01:24:28 -0000 Date: Sat, 6 Apr 2002 20:24:28 -0500 From: Garrett Rooney To: Tom Rhodes Cc: murray@stokely.org, keramida@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-ID: <20020407012427.GB98779@electricjellyfish.net> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> <20020406231126.GP5732@freebsdmall.com> <20020406190204.21cad8a8.darklogik@pittgoth.com> <20020407001148.GA8008@freebsdmall.com> <20020406200938.23dd2ef4.darklogik@pittgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020406200938.23dd2ef4.darklogik@pittgoth.com> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Apr 06, 2002 at 08:09:38PM -0500, Tom Rhodes wrote: > On Sat, 6 Apr 2002 16:11:48 -0800 > murray@stokely.org wrote: > > > On Sat, Apr 06, 2002 at 07:02:04PM -0500, Tom Rhodes wrote: > > > And so on, each book should contain: > > > > > > Ports and packages installation > > > System Installation and Configuration > > > Rebuilding your Kernel > > > Staying up to date *cutting edge* (some people may want this) > > > > That is over 130 pages of content. I do NOT think all of that > > material should be repeated in each book. That material should just > > be in the "Getting Started" guide, or other appropriately named > > guides. > > I figured, and yes I know ``figured'' is not usually the best way to > go, but anyway I figured it would probly be helpful for people. But > this would need more discussing. What I mainly am getting at, is that > it might not be the best idea for that information to only be in one > printed book, as it could pertain to new users and competant sysadmins > at the same time... Thoughts? personally, it seems like the problem is in the definition of 'user' and 'sysadmin'. from my point of view, packages, building a kernel, staying up to date with cvsup, these are all 'sysadmin' type activities, and it's just the fact that many users happen to admin their own machines that make it useful to users. if i had to make the call, i'd say put it in the admin manual, and make the user manual something targeted toward someone who's just using the system, not running it. people who need to know how to perform the admin tasks, even the simple ones like these, are probably going to need at least some of the more complicated stuff later, so having the admin manual will probably pay off for them in the end anyway. -garrett -- garrett rooney Remember, any design flaw you're rooneg@electricjellyfish.net sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 18:43: 2 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mao.stokely.org (mao.stokely.org [65.84.64.228]) by hub.freebsd.org (Postfix) with ESMTP id 5D5CC37B400; Sat, 6 Apr 2002 18:41:38 -0800 (PST) Received: by mao.stokely.org (Postfix, from userid 2074) id 142314B669; Sat, 6 Apr 2002 18:41:33 -0800 (PST) Date: Sat, 6 Apr 2002 18:41:33 -0800 From: murray@stokely.org To: Tom Rhodes Cc: keramida@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-ID: <20020407024133.GB8008@freebsdmall.com> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> <20020406231126.GP5732@freebsdmall.com> <20020406190204.21cad8a8.darklogik@pittgoth.com> <20020407001148.GA8008@freebsdmall.com> <20020406200938.23dd2ef4.darklogik@pittgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020406200938.23dd2ef4.darklogik@pittgoth.com> User-Agent: Mutt/1.3.25i X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Apr 06, 2002 at 08:09:38PM -0500, Tom Rhodes wrote: > > Each book needs to have a preface, table of contents, and > > introduction, to describe the material contained therein. > > You are correct, this information should be in the front, but I feel > strongly that some information should be on the back. I know that i'm > talking of printed versions, and not online versions, and most people > will agree that the back description is of importance also. I usually > read that part ;) Yes, the previous two printed English versions of the Handbook have contained extensive information on the back cover, and I'm sure any future versions will as well. If you are not happy with the text on the back cover of the 2nd edition, please be more specific. - Murray To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 19:29:23 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mao.stokely.org (mao.stokely.org [65.84.64.228]) by hub.freebsd.org (Postfix) with ESMTP id 27AAF37B416; Sat, 6 Apr 2002 19:29:21 -0800 (PST) Received: by mao.stokely.org (Postfix, from userid 2074) id E0CF94B669; Sat, 6 Apr 2002 19:29:20 -0800 (PST) Date: Sat, 6 Apr 2002 19:29:20 -0800 From: murray@stokely.org To: Garrett Rooney Cc: Tom Rhodes , keramida@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-ID: <20020407032920.GC8008@freebsdmall.com> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> <20020406231126.GP5732@freebsdmall.com> <20020406190204.21cad8a8.darklogik@pittgoth.com> <20020407001148.GA8008@freebsdmall.com> <20020406200938.23dd2ef4.darklogik@pittgoth.com> <20020407012427.GB98779@electricjellyfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020407012427.GB98779@electricjellyfish.net> User-Agent: Mutt/1.3.25i X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Apr 06, 2002 at 08:24:28PM -0500, Garrett Rooney wrote: > personally, it seems like the problem is in the definition of 'user' > and 'sysadmin'. from my point of view, packages, building a kernel, > staying up to date with cvsup, these are all 'sysadmin' type I agree with 2 of the 3 items you listed. The "building a kernel" and "staying up to date with cvsup" chapters are currently in the Administration part of the Handbook, but "packages" (Chapter 4) is in the Getting Started / User's part. I mostly agree with the current separation, I just want two separate books instead of two separate parts in the same book. - Murray To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 19:33:45 2002 Delivered-To: freebsd-doc@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id 4151437B41B for ; Sat, 6 Apr 2002 19:33:40 -0800 (PST) Received: (qmail 87432 invoked by uid 3130); 7 Apr 2002 03:33:38 -0000 Date: Sat, 6 Apr 2002 22:33:38 -0500 From: Garrett Rooney To: murray@stokely.org Cc: Tom Rhodes , keramida@FreeBSD.ORG, freebsd-doc@FreeBSD.ORG Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-ID: <20020407033338.GC98779@electricjellyfish.net> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> <20020406231126.GP5732@freebsdmall.com> <20020406190204.21cad8a8.darklogik@pittgoth.com> <20020407001148.GA8008@freebsdmall.com> <20020406200938.23dd2ef4.darklogik@pittgoth.com> <20020407012427.GB98779@electricjellyfish.net> <20020407032920.GC8008@freebsdmall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020407032920.GC8008@freebsdmall.com> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Apr 06, 2002 at 07:29:20PM -0800, murray@stokely.org wrote: > On Sat, Apr 06, 2002 at 08:24:28PM -0500, Garrett Rooney wrote: > > personally, it seems like the problem is in the definition of 'user' > > and 'sysadmin'. from my point of view, packages, building a kernel, > > staying up to date with cvsup, these are all 'sysadmin' type > > I agree with 2 of the 3 items you listed. The "building a kernel" > and "staying up to date with cvsup" chapters are currently in the > Administration part of the Handbook, but "packages" (Chapter 4) is in > the Getting Started / User's part. I mostly agree with the current > separation, I just want two separate books instead of two separate > parts in the same book. i can see the argument for leaving the information on packages in the users manual. it's still an admin type thing, but it's one that you can easily see an end user who just installs FreeBSD on their own machine using. and yes, i do agree that as we move forward, the guide likely should be split into a users manual and an admin's manual, if only to keep it from becoming unweildy. -garrett -- garrett rooney Remember, any design flaw you're rooneg@electricjellyfish.net sufficiently snide about becomes http://electricjellyfish.net/ a feature. -- Dan Sugalski To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 19:46:18 2002 Delivered-To: freebsd-doc@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 2EE6C37B404 for ; Sat, 6 Apr 2002 19:46:14 -0800 (PST) Received: from hades.hell.gr (patr530-a112.otenet.gr [212.205.215.112]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g373k72a023039; Sun, 7 Apr 2002 06:46:08 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.2/8.12.2) with ESMTP id g373k7GI005357; Sun, 7 Apr 2002 06:46:07 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.2/8.12.2/Submit) id g373k3JP005352; Sun, 7 Apr 2002 06:46:04 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 7 Apr 2002 06:46:02 +0300 From: Giorgos Keramidas To: Garrett Rooney Cc: murray@stokely.org, Tom Rhodes , freebsd-doc@FreeBSD.ORG Subject: Re: Splitting the Handbook? (was: [a couple of new doc PRs]) Message-ID: <20020407034602.GA5305@hades.hell.gr> References: <20020404062954.6607E2E827@mail.freebsdmall.com> <20020406221709.GA1181@hades.hell.gr> <20020406231126.GP5732@freebsdmall.com> <20020406190204.21cad8a8.darklogik@pittgoth.com> <20020407001148.GA8008@freebsdmall.com> <20020406200938.23dd2ef4.darklogik@pittgoth.com> <20020407012427.GB98779@electricjellyfish.net> <20020407032920.GC8008@freebsdmall.com> <20020407033338.GC98779@electricjellyfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020407033338.GC98779@electricjellyfish.net> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-04-06 22:33, Garrett Rooney wrote: > and yes, i do agree that as we move forward, the guide likely should > be split into a users manual and an admin's manual, if only to keep it > from becoming unweildy. I see this as a nice long term goal to look forward to. The recent breakage of tools that build the pdf version of the Handbook because of it's large size would probably be solved if it becomes two books. I'll try to come up with a working doc/en_US.ISO8859-1/books/ tree that has two books instead of one in this week, and see if we can start working towards making this happen. Giorgos Keramidas FreeBSD Documentation Project keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 19:55: 4 2002 Delivered-To: freebsd-doc@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id CB74237B416 for ; Sat, 6 Apr 2002 19:54:58 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id 765FC3E2F; Sun, 7 Apr 2002 03:54:58 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id 726913C12E; Sun, 7 Apr 2002 03:54:58 +0000 (UTC) To: "Earl A. Killian" Cc: doc@freebsd.org Subject: Re: missing man 5 pages In-Reply-To: <200204070141.g371fbX24687@gate.killian.com>; from earl@killian.com on "Sat, 6 Apr 2002 17:41:37 -0800 (PST)" Date: Sun, 07 Apr 2002 03:54:58 +0000 From: Dima Dorfman Message-Id: <20020407035458.765FC3E2F@bazooka.trit.org> Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ Moved to -doc. ] "Earl A. Killian" wrote: > Recently, someone fixed the missing host.conf(5) man page in > freebsd-stable. (Thank you!) > > On a whim, I decided to see what else might be missing using the > following command: > > gate% strings /usr/lib/libc.so | sort -u | perl -n -e 'if (m{^/etc/(.*)$}) { > system("man 5 $1 > /dev/null"); }' > No entry for host.conf in section 5 of the manual This, as you mention above, has been fixed. > No entry for malloc.conf in section 5 of the manual malloc.conf is described fairly well in malloc(3). Perhaps we should just malloc.conf(5) to the latter? I think it's appropriate, but it seems kind of awkward to link a section 5 page to a section 3 page. What do others think? > No entry for objformat in section 5 of the manual As above for objformat(1) or getobjformat(3). > No entry for localtime in section 5 of the manual This should probably be a minimal page that describes that this is a symlink to another zone file and links to tzsetup(8) or similar. > No entry for pwd.db in section 5 of the manual > No entry for spwd.db in section 5 of the manual I don't think these need manual pages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 21:10: 5 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D3AAE37B400 for ; Sat, 6 Apr 2002 21:10:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g375A2b81889; Sat, 6 Apr 2002 21:10:02 -0800 (PST) (envelope-from gnats) Date: Sat, 6 Apr 2002 21:10:02 -0800 (PST) Message-Id: <200204070510.g375A2b81889@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org Cc: From: "Hiten Pandya" Subject: Re: docs/36728: Handbook does not document VINUM Reply-To: "Hiten Pandya" Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR docs/36728; it has been noted by GNATS. From: "Hiten Pandya" To: "Greg 'groggy' Lehey" Cc: bug-followup@FreeBSD.org, murray@FreeBSD.org Subject: Re: docs/36728: Handbook does not document VINUM Date: Sun, 07 Apr 2002 05:04:13 GMT I had a little discussion with Greg, and I am working on this. Please watch http://storm.uk.FreeBSD.org/~hiten/vinum for the doc in a week's time or so. -- Hiten Pandya Finger hiten@storm.uk.FreeBSD.org for PGP public key. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Apr 6 23:20:15 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C9BB937B417 for ; Sat, 6 Apr 2002 23:20:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g377K1Z03137; Sat, 6 Apr 2002 23:20:01 -0800 (PST) (envelope-from gnats) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6DAFA37B404 for ; Sat, 6 Apr 2002 23:12:37 -0800 (PST) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g377CbI02537; Sat, 6 Apr 2002 23:12:37 -0800 (PST) (envelope-from nobody) Message-Id: <200204070712.g377CbI02537@freefall.freebsd.org> Date: Sat, 6 Apr 2002 23:12:37 -0800 (PST) From: Murray Stokely To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: docs/36837: Handbook lacks information about setting up wireless networks Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36837 >Category: docs >Synopsis: Handbook lacks information about setting up wireless networks >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sat Apr 06 23:20:01 PST 2002 >Closed-Date: >Last-Modified: >Originator: Murray Stokely >Release: Any >Organization: FreeBSD Project >Environment: -CURRENT >Description: The FreeBSD Handbook does not contain any information about setting up a wireless network with FreeBSD. We should talk about airtools, wicontrol, ifconfig, etc.. Cards supported, interoperability with Apple AirPorts, etc... >How-To-Repeat: >Fix: Can someone write some material for this section? >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message