From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 00:14:27 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0B6716A415; Sun, 12 Nov 2006 00:14:27 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34AF243D68; Sun, 12 Nov 2006 00:14:19 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from freefall.freebsd.org (keramida@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAC0EAdF083608; Sun, 12 Nov 2006 00:14:10 GMT (envelope-from keramida@freefall.freebsd.org) Received: (from keramida@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAC0E9q2083604; Sun, 12 Nov 2006 00:14:09 GMT (envelope-from keramida) Date: Sun, 12 Nov 2006 00:14:09 GMT From: Giorgos Keramidas Message-Id: <200611120014.kAC0E9q2083604@freefall.freebsd.org> To: lothrandil@n00b.apagnu.se, keramida@FreeBSD.org, freebsd-doc@FreeBSD.org, keramida@FreeBSD.org Cc: Subject: Re: docs/105256: [patch] nit-picking to Securing FreeBSD (14.3) chapter of handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 00:14:27 -0000 Synopsis: [patch] nit-picking to Securing FreeBSD (14.3) chapter of handbook State-Changed-From-To: open->closed State-Changed-By: keramida State-Changed-When: Sun Nov 12 00:13:39 UTC 2006 State-Changed-Why: Committed, thanks. Responsible-Changed-From-To: freebsd-doc->keramida Responsible-Changed-By: keramida Responsible-Changed-When: Sun Nov 12 00:13:39 UTC 2006 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=105256 From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 00:30:32 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE22B16A403 for ; Sun, 12 Nov 2006 00:30:32 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 577F843D81 for ; Sun, 12 Nov 2006 00:30:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAC0UROK084501 for ; Sun, 12 Nov 2006 00:30:27 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAC0URfM084496; Sun, 12 Nov 2006 00:30:27 GMT (envelope-from gnats) Date: Sun, 12 Nov 2006 00:30:27 GMT Message-Id: <200611120030.kAC0URfM084496@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Giorgos Keramidas Cc: Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Giorgos Keramidas List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 00:30:33 -0000 The following reply was made to PR docs/104403; it has been noted by GNATS. From: Giorgos Keramidas To: "Dr. Markus Waldeck" Cc: freebsd-gnats-submit@freebsd.org Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 Date: Sun, 12 Nov 2006 01:18:11 +0100 On 2006-10-14 09:29, "Dr. Markus Waldeck" wrote: > man security should mention that the usage of the X Window Systen is > only possible with kern.securitylevel=-1. > > With kern.securitylevel=0 or higher it is not possible to start X. You can still use `xdm' or a similar way of starting X11, because it will be started by init(8) before the securelevel is raised by the `/etc/rc.d/securelevel' script. I don't think this is worth mentioning in security(7), because we can't possibly document *ALL* the possible things that can fail with a bumped securelevel. From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 09:52:05 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 101EC16A403; Sun, 12 Nov 2006 09:52:05 +0000 (UTC) (envelope-from lothrandil@n00b.apagnu.se) Received: from pne-smtpout2-sn1.fre.skanova.net (pne-smtpout2-sn1.fre.skanova.net [81.228.11.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id A02E943D45; Sun, 12 Nov 2006 09:52:04 +0000 (GMT) (envelope-from lothrandil@n00b.apagnu.se) Received: from [90.224.57.146] (90.224.57.146) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 452BAC860065EE40; Sun, 12 Nov 2006 10:52:03 +0100 Message-ID: <4556EECB.1040302@n00b.apagnu.se> Date: Sun, 12 Nov 2006 10:52:11 +0100 From: Niclas Zeising User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Giorgos Keramidas References: <200611120030.kAC0URfM084496@freefall.freebsd.org> In-Reply-To: <200611120030.kAC0URfM084496@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-doc@FreeBSD.org Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 09:52:05 -0000 Giorgos Keramidas wrote: > The following reply was made to PR docs/104403; it has been noted by GNATS. > > From: Giorgos Keramidas > To: "Dr. Markus Waldeck" > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 > Date: Sun, 12 Nov 2006 01:18:11 +0100 > > On 2006-10-14 09:29, "Dr. Markus Waldeck" wrote: > > man security should mention that the usage of the X Window Systen is > > only possible with kern.securitylevel=-1. > > > > With kern.securitylevel=0 or higher it is not possible to start X. > > You can still use `xdm' or a similar way of starting X11, because > it will be started by init(8) before the securelevel is raised by > the `/etc/rc.d/securelevel' script. > > I don't think this is worth mentioning in security(7), because > we can't possibly document *ALL* the possible things that can > fail with a bumped securelevel. > It it probably worth mentioning somewhere, as it will avoid some foot shooting from unaware users. One can discuss though that if the extra security provided by the security level is needed, maybe the system shouldn't run X in the first place. Just my SEK 0.02 //Niclas From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 13:40:43 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 900D616A5A6 for ; Sun, 12 Nov 2006 13:40:43 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3AB043D53 for ; Sun, 12 Nov 2006 13:40:37 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACDebQr063933 for ; Sun, 12 Nov 2006 13:40:37 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACDebxu063932; Sun, 12 Nov 2006 13:40:37 GMT (envelope-from gnats) Date: Sun, 12 Nov 2006 13:40:37 GMT Message-Id: <200611121340.kACDebxu063932@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Giorgos Keramidas Cc: Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Giorgos Keramidas List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 13:40:43 -0000 The following reply was made to PR docs/104403; it has been noted by GNATS. From: Giorgos Keramidas To: Niclas Zeising Cc: bug-followup@freebsd.org Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 Date: Sun, 12 Nov 2006 14:37:44 +0100 On 2006-11-12 10:52, Niclas Zeising wrote: >Giorgos Keramidas wrote: >>> With kern.securitylevel=0 or higher it is not possible to start X. >> >> You can still use `xdm' or a similar way of starting X11, because >> it will be started by init(8) before the securelevel is raised by >> the `/etc/rc.d/securelevel' script. >> >> I don't think this is worth mentioning in security(7), because >> we can't possibly document *ALL* the possible things that can >> fail with a bumped securelevel. > > It it probably worth mentioning somewhere, as it will avoid some foot > shooting from unaware users. One can discuss though that if the extra > security provided by the security level is needed, maybe the system > shouldn't run X in the first place. I'm not sure. Should we also mention that you can't "installworld" with an elevated securelevel, because chflags may fail to work and cause problems? Should we also mention that not being able to change the firewall rules can be tricky, if you are testing your new firewall ruleset, and get locked out? There are *MANY* ways in which an elevated securelevel can turn around and bite you in the ass, but do we _really_ have to enumerate them all in mind-boggingly detail? ... in a single manpage? I really don't know. From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 13:55:45 2006 Return-Path: X-Original-To: doc@freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5A4E16A40F; Sun, 12 Nov 2006 13:55:45 +0000 (UTC) (envelope-from lothrandil@n00b.apagnu.se) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 511C443D5A; Sun, 12 Nov 2006 13:55:42 +0000 (GMT) (envelope-from lothrandil@n00b.apagnu.se) Received: from [90.224.57.146] (90.224.57.146) by pne-smtpout2-sn2.hy.skanova.net (7.2.075) id 452BAB41006699FE; Sun, 12 Nov 2006 14:55:42 +0100 Message-ID: <455727DE.7090003@n00b.apagnu.se> Date: Sun, 12 Nov 2006 14:55:42 +0100 From: Niclas Zeising User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Giorgos Keramidas References: <200611120030.kAC0URfM084496@freefall.freebsd.org> <4556EECB.1040302@n00b.apagnu.se> <20061112133744.GA999@kobe.laptop> In-Reply-To: <20061112133744.GA999@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: doc@freebsd.org, bug-followup@freebsd.org Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 13:55:45 -0000 Giorgos Keramidas wrote: > On 2006-11-12 10:52, Niclas Zeising wrote: >> Giorgos Keramidas wrote: >>>> With kern.securitylevel=0 or higher it is not possible to start X. >>> You can still use `xdm' or a similar way of starting X11, because >>> it will be started by init(8) before the securelevel is raised by >>> the `/etc/rc.d/securelevel' script. >>> >>> I don't think this is worth mentioning in security(7), because >>> we can't possibly document *ALL* the possible things that can >>> fail with a bumped securelevel. >> It it probably worth mentioning somewhere, as it will avoid some foot >> shooting from unaware users. One can discuss though that if the extra >> security provided by the security level is needed, maybe the system >> shouldn't run X in the first place. > > I'm not sure. > > Should we also mention that you can't "installworld" with an elevated > securelevel, because chflags may fail to work and cause problems? > Should we also mention that not being able to change the firewall rules > can be tricky, if you are testing your new firewall ruleset, and get > locked out? > > There are *MANY* ways in which an elevated securelevel can turn around > and bite you in the ass, but do we _really_ have to enumerate them all > in mind-boggingly detail? ... in a single manpage? > > I really don't know. > I believe they should be documented somewhere, to avoid questions. But you are right in that there are numerous consequences in raising secure levels and that it might be a bit over the top to document them all. Maybe I/we have to face the fact that it's too much and/or unnecessary to document all consequences, and rely on that if a sysadmin feels the need to raise the secure-level he knows what he's doing and the consequences of doing so. Maybe the biggest issues in raising secure-level should be mentioned, but then again, who decides which those issues are? Maybe it's best to leave the documentation regarding this as it is, and give an answer whenever the issues pops up. //Niclas From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 14:01:12 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D2BC16A6F5 for ; Sun, 12 Nov 2006 14:01:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 445B843D5C for ; Sun, 12 Nov 2006 14:00:43 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACE0gvl065120 for ; Sun, 12 Nov 2006 14:00:42 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACE0g76065119; Sun, 12 Nov 2006 14:00:42 GMT (envelope-from gnats) Date: Sun, 12 Nov 2006 14:00:42 GMT Message-Id: <200611121400.kACE0g76065119@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:01:12 -0000 The following reply was made to PR docs/104403; it has been noted by GNATS. From: Niclas Zeising To: Giorgos Keramidas Cc: bug-followup@freebsd.org, doc@freebsd.org Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 Date: Sun, 12 Nov 2006 14:55:42 +0100 Giorgos Keramidas wrote: > On 2006-11-12 10:52, Niclas Zeising wrote: >> Giorgos Keramidas wrote: >>>> With kern.securitylevel=0 or higher it is not possible to start X. >>> You can still use `xdm' or a similar way of starting X11, because >>> it will be started by init(8) before the securelevel is raised by >>> the `/etc/rc.d/securelevel' script. >>> >>> I don't think this is worth mentioning in security(7), because >>> we can't possibly document *ALL* the possible things that can >>> fail with a bumped securelevel. >> It it probably worth mentioning somewhere, as it will avoid some foot >> shooting from unaware users. One can discuss though that if the extra >> security provided by the security level is needed, maybe the system >> shouldn't run X in the first place. > > I'm not sure. > > Should we also mention that you can't "installworld" with an elevated > securelevel, because chflags may fail to work and cause problems? > Should we also mention that not being able to change the firewall rules > can be tricky, if you are testing your new firewall ruleset, and get > locked out? > > There are *MANY* ways in which an elevated securelevel can turn around > and bite you in the ass, but do we _really_ have to enumerate them all > in mind-boggingly detail? ... in a single manpage? > > I really don't know. > I believe they should be documented somewhere, to avoid questions. But you are right in that there are numerous consequences in raising secure levels and that it might be a bit over the top to document them all. Maybe I/we have to face the fact that it's too much and/or unnecessary to document all consequences, and rely on that if a sysadmin feels the need to raise the secure-level he knows what he's doing and the consequences of doing so. Maybe the biggest issues in raising secure-level should be mentioned, but then again, who decides which those issues are? Maybe it's best to leave the documentation regarding this as it is, and give an answer whenever the issues pops up. //Niclas From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 14:01:19 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E068E16A756 for ; Sun, 12 Nov 2006 14:01:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1796843D72 for ; Sun, 12 Nov 2006 14:00:45 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACE0jjY065152 for ; Sun, 12 Nov 2006 14:00:45 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACE0ip7065151; Sun, 12 Nov 2006 14:00:44 GMT (envelope-from gnats) Resent-Date: Sun, 12 Nov 2006 14:00:44 GMT Resent-Message-Id: <200611121400.kACE0ip7065151@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Steve Wills Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1535B16A415 for ; Sun, 12 Nov 2006 13:58:28 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEF8143D78 for ; Sun, 12 Nov 2006 13:58:18 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id kACDwIij056776 for ; Sun, 12 Nov 2006 13:58:18 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id kACDwI8v056775; Sun, 12 Nov 2006 13:58:18 GMT (envelope-from nobody) Message-Id: <200611121358.kACDwI8v056775@www.freebsd.org> Date: Sun, 12 Nov 2006 13:58:18 GMT From: Steve Wills To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: docs/105440: Incorrect example in audit documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:01:20 -0000 >Number: 105440 >Category: docs >Synopsis: Incorrect example in audit documentation >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 Nov 12 14:00:44 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Steve Wills >Release: 6.2-PRE >Organization: >Environment: irrelevant >Description: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-administration.html contains this example: Adding the following line to /etc/crontab will force the rotation every twelve hours from cron(8): * */12 * * * root /usr/sbin/audit -n Unless I'm mistaken, that will run once a minute for an hour every twelve hours, not, not once as is implied. >How-To-Repeat: >Fix: Change example to: 0 */12 * * * root /usr/sbin/audit -n >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 14:31:06 2006 Return-Path: X-Original-To: doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66C6916A412 for ; Sun, 12 Nov 2006 14:31:06 +0000 (UTC) (envelope-from remi.sandevoir@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E23943D91 for ; Sun, 12 Nov 2006 14:30:20 +0000 (GMT) (envelope-from remi.sandevoir@gmail.com) Received: by nf-out-0910.google.com with SMTP id l23so175182nfc for ; Sun, 12 Nov 2006 06:30:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NpHUd8JZnZifLJAfmLrC7/CWdDVlgiYaYj1d2ZY/TevxnjWfV+MpeUfuasGKivWBPqdTg1t1Zzmoi40se+TGVnV7iunzc9DugL+A+uLDVV9dRgCA/PXIUd8o5VF/X2abP8FV1FjNfy4Yo/45olLENVLUOwpFU0f17gPGrCwZzEo= Received: by 10.49.107.3 with SMTP id j3mr5749369nfm.1163341819673; Sun, 12 Nov 2006 06:30:19 -0800 (PST) Received: by 10.49.63.15 with HTTP; Sun, 12 Nov 2006 06:30:19 -0800 (PST) Message-ID: <5d5432550611120630i76b75438h25f1af4bfd240979@mail.gmail.com> Date: Sun, 12 Nov 2006 15:30:19 +0100 From: "Remi Sandevoir" To: doc@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: [handbook] Erreur de frappe X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:31:06 -0000 Bonjour, Il y'a une erreur de frappe sur la page : http://www.freebsd.org/doc/fr_FR.ISO8859-1/books/faq/x1295.html [...] D=E9marrer sous Linux et ajouter les lignes suivantes au fichier /etc/lilo.= conf : other=3D/dev/hda2 table=3D/deb/hda label=3DFreeBSD [...] On devrait avoir : [...] D=E9marrer sous Linux et ajouter les lignes suivantes au fichier /etc/lilo.= conf : other=3D/dev/hda2 =3D=3D> table=3D/dev/hda label=3DFreeBSD [...] Cordialement, --=20 R=E9mi Sandevoir T=E9l: 06.88.67.25.70 -- From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 14:40:24 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63FA116A40F for ; Sun, 12 Nov 2006 14:40:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 026C143D6D for ; Sun, 12 Nov 2006 14:40:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACEeNg7068772 for ; Sun, 12 Nov 2006 14:40:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACEeNCZ068771; Sun, 12 Nov 2006 14:40:23 GMT (envelope-from gnats) Date: Sun, 12 Nov 2006 14:40:23 GMT Message-Id: <200611121440.kACEeNCZ068771@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Giorgos Keramidas Cc: Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Giorgos Keramidas List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:40:24 -0000 The following reply was made to PR docs/104403; it has been noted by GNATS. From: Giorgos Keramidas To: Niclas Zeising Cc: bug-followup@FreeBSD.org Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 Date: Sun, 12 Nov 2006 15:29:27 +0100 On 2006-11-12 14:55, Niclas Zeising wrote: >Giorgos Keramidas wrote: >> I'm not sure. >> >> Should we also mention that you can't "installworld" with an elevated >> securelevel, because chflags may fail to work and cause problems? >> Should we also mention that not being able to change the firewall >> rules can be tricky, if you are testing your new firewall ruleset, >> and get locked out? >> >> There are *MANY* ways in which an elevated securelevel can turn >> around and bite you in the ass, but do we _really_ have to enumerate >> them all in mind-boggingly detail? ... in a single manpage? >> >> I really don't know. > > I believe they should be documented somewhere, to avoid questions. I believe a manpage is not the right place for long, detailed, filled with gory details explanation of all the possible scenarios that can go wrong. I mean, there are ways to destroy a system with rm(1) too, but we don't have a list of funny, albeit dangerous "rm -fr /" scenarios in that manpage too. This sort of stuff, in my opinion, belongs to a tutorial style guide, i.e. something like a "Mini Guide for Security on FreeBSD". A manpage should be written as a 'reference' guide, but that's only *my* point of view. > But you are right in that there are numerous consequences in raising > secure levels and that it might be a bit over the top to document them > all. Maybe I/we have to face the fact that it's too much and/or > unnecessary to document all consequences, and rely on that if a > sysadmin feels the need to raise the secure-level he knows what he's > doing and the consequences of doing so. Maybe the biggest issues in > raising secure-level should be mentioned, but then again, who decides > which those issues are? EXACTLY! Picking up what level of detail we want to appear in a manpage is not easy if we let all the details about all potentially harmful scenarios go in. But if we treat manpages as 'reference' material, then the field is much much more clear. For example, we don't document all the different ways that fgets(3) can be abused in its manpage. We don't document all the potentially stupid ways to use scanf(3) in its manpage either. What we *do* write about in most manpages is a `reference guide'. > Maybe it's best to leave the documentation regarding this as it is, > and give an answer whenever the issues pops up. Or we can expand, extend and clean up the ``Security'' chapter of the Handbook, which has the potential and the purpose of being a guide which matches both a `tutorial' and `reference' styles (depending on how complete and nicely written the relevant sections are, of course). - Giorgos From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 14:50:37 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98B5916A63B for ; Sun, 12 Nov 2006 14:50:37 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBAA343D5E for ; Sun, 12 Nov 2006 14:50:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACEoPxx069301 for ; Sun, 12 Nov 2006 14:50:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACEoPhc069300; Sun, 12 Nov 2006 14:50:25 GMT (envelope-from gnats) Resent-Date: Sun, 12 Nov 2006 14:50:25 GMT Resent-Message-Id: <200611121450.kACEoPhc069300@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Alejandro Pulver" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D20516A40F for ; Sun, 12 Nov 2006 14:44:43 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 7EBE543D8A for ; Sun, 12 Nov 2006 14:44:31 +0000 (GMT) (envelope-from alepulver@FreeBSD.org) Received: (qmail 48529 invoked from network); 12 Nov 2006 14:44:30 -0000 Received: from unknown (HELO phobos.mars.bsd) (unknown) by unknown with SMTP; 12 Nov 2006 14:44:30 -0000 Message-Id: <1163342668.45244@phobos.mars.bsd> Date: Sun, 12 Nov 2006 11:44:28 -0300 From: "Alejandro Pulver" To: "FreeBSD gnats submit" X-Send-Pr-Version: gtk-send-pr 0.4.7 Cc: Subject: docs/105441: [PATCH] PH: add new Lua variables X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:50:37 -0000 >Number: 105441 >Category: docs >Synopsis: [PATCH] PH: add new Lua variables >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sun Nov 12 14:50:20 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Alejandro Pulver >Release: FreeBSD 6.1-RELEASE-p1 i386 >Organization: >Environment: System: FreeBSD 6.1-RELEASE-p1 #3: Mon Jun 19 14:49:35 ART 2006 root@phobos.mars.bsd:/usr/obj/usr/src/sys/ATHLON-PHOBOS >Description: - Add LUA_CMD, LUAC_CMD and TOLUA_CMD variables. - Fix column titles in a table. - Change example to use the new variables. >How-To-Repeat: >Fix: --- patch_lua.diff begins here --- Index: book.sgml =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/porters-handbook/book.sgml,v retrieving revision 1.765 diff -u -r1.765 book.sgml --- book.sgml 3 Nov 2006 21:04:09 -0000 1.765 +++ book.sgml 12 Nov 2006 14:17:14 -0000 @@ -6565,9 +6565,9 @@ - Name + Component - Value + Dependency type @@ -6745,6 +6745,24 @@ The package name prefix used by Lua modules + + LUA_CMD + + The path to the Lua + interpreter + + + LUAC_CMD + + The path to the Lua + compiler + + + TOLUA_CMD + + The path to the tolua + program + @@ -6794,9 +6812,11 @@ .include <bsd.port.pre.mk> -VER_STR!= lua${LUA_VER} -v +.if exists(${LUA_CMD}) +VER_STR!= ${LUA_CMD} -v -CFLAGS+= -DLUA_VERSION_STRING="${VER_STR}" +CFLAGS+= -DLUA_VERSION_STRING="${VER_STR}" +.endif --- patch_lua.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 14:50:38 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D92A16A64B for ; Sun, 12 Nov 2006 14:50:38 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8E2643D8B for ; Sun, 12 Nov 2006 14:50:29 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACEoTNN069323 for ; Sun, 12 Nov 2006 14:50:29 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACEoTa6069322; Sun, 12 Nov 2006 14:50:29 GMT (envelope-from gnats) Date: Sun, 12 Nov 2006 14:50:29 GMT Message-Id: <200611121450.kACEoTa6069322@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising Cc: Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:50:38 -0000 The following reply was made to PR docs/104403; it has been noted by GNATS. From: Niclas Zeising To: Giorgos Keramidas Cc: bug-followup@FreeBSD.org Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 Date: Sun, 12 Nov 2006 15:45:01 +0100 Giorgos Keramidas wrote: > On 2006-11-12 14:55, Niclas Zeising wrote: >> Giorgos Keramidas wrote: >>> I'm not sure. >>> >>> Should we also mention that you can't "installworld" with an elevated >>> securelevel, because chflags may fail to work and cause problems? >>> Should we also mention that not being able to change the firewall >>> rules can be tricky, if you are testing your new firewall ruleset, >>> and get locked out? >>> >>> There are *MANY* ways in which an elevated securelevel can turn >>> around and bite you in the ass, but do we _really_ have to enumerate >>> them all in mind-boggingly detail? ... in a single manpage? >>> >>> I really don't know. >> I believe they should be documented somewhere, to avoid questions. > > I believe a manpage is not the right place for long, detailed, filled > with gory details explanation of all the possible scenarios that can go > wrong. I mean, there are ways to destroy a system with rm(1) too, but > we don't have a list of funny, albeit dangerous "rm -fr /" scenarios in > that manpage too. I was not referring exclusively to a man page, rather that it should be documented somewhere. I agree with you that a man page is not the right place for this type of documentation, it is more of a reference. What the man page can have is a reference to documentation which discuss issues etc. in more detail so the user reading the man page knows where to look if the information wasn't enough. > > This sort of stuff, in my opinion, belongs to a tutorial style guide, > i.e. something like a "Mini Guide for Security on FreeBSD". A manpage > should be written as a 'reference' guide, but that's only *my* point of > view. Yup. > >> But you are right in that there are numerous consequences in raising >> secure levels and that it might be a bit over the top to document them >> all. Maybe I/we have to face the fact that it's too much and/or >> unnecessary to document all consequences, and rely on that if a >> sysadmin feels the need to raise the secure-level he knows what he's >> doing and the consequences of doing so. Maybe the biggest issues in >> raising secure-level should be mentioned, but then again, who decides >> which those issues are? > > EXACTLY! > > Picking up what level of detail we want to appear in a manpage is not > easy if we let all the details about all potentially harmful scenarios > go in. But if we treat manpages as 'reference' material, then the field > is much much more clear. True. Everybody just has to agree on that. I think it's a reasonable line to draw: Man pages are references, tutorials and other documents can go into more depth. Maybe we should state that somewhere? Or is that to overdo things? > > For example, we don't document all the different ways that fgets(3) can > be abused in its manpage. We don't document all the potentially stupid > ways to use scanf(3) in its manpage either. What we *do* write about in > most manpages is a `reference guide'. > >> Maybe it's best to leave the documentation regarding this as it is, >> and give an answer whenever the issues pops up. > > Or we can expand, extend and clean up the ``Security'' chapter of the > Handbook, which has the potential and the purpose of being a guide which > matches both a `tutorial' and `reference' styles (depending on how > complete and nicely written the relevant sections are, of course). I can see if I manage to hack some lines together regarding secure level, since I'm already in the security chapter mucking about. I just hope I realize when I'm in for too much ;) Regards! //Niclas From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 14:57:58 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67D7A16A407 for ; Sun, 12 Nov 2006 14:57:58 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 731FB43D55 for ; Sun, 12 Nov 2006 14:57:57 +0000 (GMT) (envelope-from lgusenet@be-well.ilk.org) Received: (qmail 15521 invoked from network); 12 Nov 2006 14:57:56 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Nov 2006 14:57:56 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id E3ADD28467; Sun, 12 Nov 2006 09:57:55 -0500 (EST) To: lothrandil@n00b.apagnu.se (Niclas Zeising) References: <200611121400.kACE0g76065119@freefall.freebsd.org> From: Lowell Gilbert Date: Sun, 12 Nov 2006 09:57:55 -0500 In-Reply-To: <200611121400.kACE0g76065119@freefall.freebsd.org> (Niclas Zeising's message of "Sun, 12 Nov 2006 14:00:42 GMT") Message-ID: <44lkmg7lvw.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-doc@freebsd.org Subject: Re: docs/104403: man security should mention that the usage of the X Window Systen is only possible with kern.securitylevel=-1 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-doc@freebsd.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 14:57:58 -0000 lothrandil@n00b.apagnu.se (Niclas Zeising) writes: > The following reply was made to PR docs/104403; it has been noted by GNATS. > > From: Niclas Zeising > To: Giorgos Keramidas > Cc: bug-followup@freebsd.org, doc@freebsd.org > Subject: Re: docs/104403: man security should mention that the usage of the > X Window Systen is only possible with kern.securitylevel=-1 > Date: Sun, 12 Nov 2006 14:55:42 +0100 > > Giorgos Keramidas wrote: > > On 2006-11-12 10:52, Niclas Zeising wrote: > >> Giorgos Keramidas wrote: > >>>> With kern.securitylevel=0 or higher it is not possible to start X. > >>> You can still use `xdm' or a similar way of starting X11, because > >>> it will be started by init(8) before the securelevel is raised by > >>> the `/etc/rc.d/securelevel' script. > >>> > >>> I don't think this is worth mentioning in security(7), because > >>> we can't possibly document *ALL* the possible things that can > >>> fail with a bumped securelevel. > >> It it probably worth mentioning somewhere, as it will avoid some foot > >> shooting from unaware users. One can discuss though that if the extra > >> security provided by the security level is needed, maybe the system > >> shouldn't run X in the first place. > > > > I'm not sure. > > > > Should we also mention that you can't "installworld" with an elevated > > securelevel, because chflags may fail to work and cause problems? > > Should we also mention that not being able to change the firewall rules > > can be tricky, if you are testing your new firewall ruleset, and get > > locked out? > > > > There are *MANY* ways in which an elevated securelevel can turn around > > and bite you in the ass, but do we _really_ have to enumerate them all > > in mind-boggingly detail? ... in a single manpage? > > > > I really don't know. > > > > I believe they should be documented somewhere, to avoid questions. Sure, but they already are. Given that both the X and installworld issues have been in the FAQ for years, I don't think adding MORE documentation will help. From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 17:51:41 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 699D216A417 for ; Sun, 12 Nov 2006 17:51:41 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05B3843DBB for ; Sun, 12 Nov 2006 17:50:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACHoJpb084505 for ; Sun, 12 Nov 2006 17:50:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACHoJ9V084504; Sun, 12 Nov 2006 17:50:19 GMT (envelope-from gnats) Resent-Date: Sun, 12 Nov 2006 17:50:19 GMT Resent-Message-Id: <200611121750.kACHoJ9V084504@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Bjoern A.Zeeb" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AC6316A599 for ; Sun, 12 Nov 2006 17:43:44 +0000 (UTC) (envelope-from bz@zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3A2C43D55 for ; Sun, 12 Nov 2006 17:43:43 +0000 (GMT) (envelope-from bz@zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 2C4621FFD41 for ; Sun, 12 Nov 2006 18:43:39 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 62FCC1FFD35; Sun, 12 Nov 2006 18:43:34 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 807E5444889; Sun, 12 Nov 2006 17:43:13 +0000 (UTC) Message-Id: <20061112174313.807E5444889@mail.int.zabbadoz.net> Date: Sun, 12 Nov 2006 17:43:13 +0000 (UTC) From: "Bjoern A.Zeeb" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/105447: new committers help to coverity X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 17:51:41 -0000 >Number: 105447 >Category: docs >Synopsis: new committers help to coverity >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 Nov 12 17:50:19 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Bjoern A. Zeeb >Release: FreeBSD 6.2-ISH >Organization: FreeBSD.org >Environment: way too old current >Description: the new committers guidelines (for src) don't say anything about where to find information about coverity. Some introduction about what it is and how to sign up should be in somewhere... >How-To-Repeat: a) get a src tree mentee b) go to a bsd conference c) listen to some talk with her sitting next to you d) explain to her what people were talking about so those ??? go away. >Fix: talk to some doc people and get asked to file a PR about all this. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 17:56:06 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C22616A4C8; Sun, 12 Nov 2006 17:56:06 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0F1B43D81; Sun, 12 Nov 2006 17:55:48 +0000 (GMT) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (bz@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACHtmbo085011; Sun, 12 Nov 2006 17:55:48 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACHtmFn085007; Sun, 12 Nov 2006 17:55:48 GMT (envelope-from bz) Date: Sun, 12 Nov 2006 17:55:48 GMT From: "Bjoern A. Zeeb" Message-Id: <200611121755.kACHtmFn085007@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-doc@FreeBSD.org, keramida@FreeBSD.org Cc: Subject: Re: docs/105447: new committers help to coverity X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 17:56:06 -0000 Synopsis: new committers help to coverity Responsible-Changed-From-To: freebsd-doc->keramida Responsible-Changed-By: bz Responsible-Changed-When: Sun Nov 12 17:55:14 UTC 2006 Responsible-Changed-Why: You volunteered to do it;) http://www.freebsd.org/cgi/query-pr.cgi?pr=105447 From owner-freebsd-doc@FreeBSD.ORG Sun Nov 12 21:30:20 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37DB316A40F for ; Sun, 12 Nov 2006 21:30:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8781143D53 for ; Sun, 12 Nov 2006 21:30:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kACLUJnk016674 for ; Sun, 12 Nov 2006 21:30:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kACLUJrK016672; Sun, 12 Nov 2006 21:30:19 GMT (envelope-from gnats) Resent-Date: Sun, 12 Nov 2006 21:30:19 GMT Resent-Message-Id: <200611122130.kACLUJrK016672@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Niclas Zeising Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB0CB16A415 for ; Sun, 12 Nov 2006 21:21:10 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CACF43DBB for ; Sun, 12 Nov 2006 21:20:36 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id kACLKTej015147 for ; Sun, 12 Nov 2006 21:20:29 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id kACLKTmi015146; Sun, 12 Nov 2006 21:20:29 GMT (envelope-from nobody) Message-Id: <200611122120.kACLKTmi015146@www.freebsd.org> Date: Sun, 12 Nov 2006 21:20:29 GMT From: Niclas Zeising To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: docs/105456: [patch] overhaul of the security chapter (14) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 21:30:20 -0000 >Number: 105456 >Category: docs >Synopsis: [patch] overhaul of the security chapter (14) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sun Nov 12 21:30:18 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Niclas Zeising >Release: 7-CURRENT >Organization: >Environment: >Description: A patch to make the security chapter more consistent regarding the use of acronyms etc. I've added a number of tags, as well as a couple of tags along with some small fixes (i.e. using entities instead of -- and such). As I was doing this I realized two things, firstly, should I use the on every single acronym, or just , or should I leave most of the acronyms alone altogether? The second thing is, do we need an overhaul like this on the entire handbook? >How-To-Repeat: Uhm, It's not really a problem... >Fix: Apply the following patch, or the parts you find fitting. I'm happy to rewrite the patch if there is need, just let me know. Patch attached with submission follows: --- doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml.orig 2006-11-12 11:13:08.000000000 +0100 +++ doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml 2006-11-12 19:10:20.000000000 +0100 @@ -66,17 +66,20 @@ - How to configure IPsec and create a VPN between - &os;/&windows; machines. + How to configure IPsec and create a + VPN between + &os;/&windows; machines. - How to configure and use OpenSSH, &os;'s SSH - implementation. + How to configure and use OpenSSH + , &os;'s SSH implementation. + - What file system ACLs are and how to use them. + What file system ACLs + are and how to use them. @@ -128,15 +131,14 @@ inter-networked, security becomes an even bigger issue. System security also pertains to dealing with various forms of - attack, including attacks that attempt to crash, or otherwise make a + attacks, including attacks that attempt to crash, or otherwise make a system unusable, but do not attempt to compromise the root account (break root). - Security concerns - can be split up into several categories: + Security concerns can be split up into several categories: - Denial of service attacks. + Denial of service (DoS) attacks. @@ -168,14 +170,14 @@ Denial of Service (DoS) A denial of service attack is an action that deprives the - machine of needed resources. Typically, DoS attacks are - brute-force mechanisms that attempt to crash or otherwise make a + machine of needed resources. Typically, DoS attacks + are brute-force mechanisms that attempt to crash or otherwise make a machine unusable by overwhelming its servers or network stack. Some - DoS attacks try to take advantage of bugs in the networking - stack to crash a machine with a single packet. The latter can only - be fixed by applying a bug fix to the kernel. Attacks on servers - can often be fixed by properly specifying options to limit the load - the servers incur on the system under adverse conditions. + DoS attacks try to take advantage of bugs in the + networking stack to crash a machine with a single packet. The latter + can only be fixed by applying a bug fix to the kernel. Attacks on + servers can often be fixed by properly specifying options to limit the + load the servers incur on the system under adverse conditions. Brute-force network attacks are harder to deal with. A spoofed-packet attack, for example, is nearly impossible to stop, short of cutting your system off from the Internet. It may not be @@ -187,8 +189,8 @@ account compromises - A user account compromise is even more common than a DoS - attack. Many sysadmins still run standard + A user account compromise is even more common than a + DoS attack. Many sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on their machines. @@ -226,7 +228,7 @@ a suid-root program that allows the attacker to break root once he has broken into a user's account. If an attacker has found a way to break root - on a machine, the attacker may not have a need + on a machine, the attacker may have the need to install a backdoor. Many of the root holes found and closed to date involve a considerable amount of work by the attacker to cleanup after himself, so most attackers install @@ -294,9 +296,8 @@ bold text to refer to an application, and a monospaced font to refer to specific commands. Protocols will use a normal font. This - typographical distinction is useful for instances such as ssh, - since it is - a protocol as well as command. + typographical distinction is useful for instances such as SSH, + since it is a protocol as well as command. The sections that follow will cover the methods of securing your @@ -348,8 +349,8 @@ wheel group are allowed to su to root. You should never give staff - members native wheel access by putting them in the - wheel group in their password entry. Staff + members native wheel access by putting them in + the wheel group in their password entry. Staff accounts should be placed in a staff group, and then added to the wheel group via the /etc/group file. Only those staff members @@ -565,7 +566,7 @@ have sufficient control, then you may win out and be able to secure the user accounts properly. If not, you simply have to be more vigilant in your monitoring of those accounts. Use of - ssh and Kerberos for user accounts is + SSH and Kerberos for user accounts is more problematic, due to the extra administration and technical support required, but still a very good solution compared to a encrypted password file. @@ -575,7 +576,7 @@ Securing the Password File The only sure fire way is to star out as many - passwords as you can and use ssh or + passwords as you can and use SSH or Kerberos for access to those accounts. Even though the encrypted password file (/etc/spwd.db) can only be read by root, it may be possible for an intruder @@ -663,9 +664,9 @@ have to give the limited-access box significant access to the other machines in the business, usually either by doing a read-only NFS export of the other machines to the limited-access - box, or by setting up ssh key-pairs to - allow the limited-access box to ssh to - the other machines. Except for its network traffic, NFS is the + box, or by setting up SSH key-pairs to + allow the limited-access box to use ssh to + access the other machines. Except for its network traffic, NFS is the least visible method — allowing you to monitor the file systems on each client box virtually undetected. If your limited-access server is connected to the client boxes through a @@ -674,8 +675,7 @@ hub, or through several layers of routing, the NFS method may be too insecure (network-wise) and using ssh may be the better choice even with - the audit-trail tracks that ssh - lays. + the audit-trail tracks that SSH lays. Once you have given a limited-access box at least read access to the client systems it is supposed to monitor, you must write scripts @@ -694,13 +694,13 @@ When using ssh rather than NFS, writing the security script is much more difficult. You - essentially have to scp the scripts to the client + essentially have to scp the scripts to the client box in order to run them, making them visible, and for safety you also need to scp the binaries (such as find) that those scripts use. The ssh client on the client box may already be compromised. All in all, using - ssh may be necessary when running over + SSH may be necessary when running over insecure links, but it is also a lot harder to deal with. A good security script will also check for changes to user and @@ -753,8 +753,9 @@ Denial of Service Attacks Denial of Service (DoS) - This section covers Denial of Service attacks. A DoS attack - is typically a packet attack. While there is not much you can do + This section covers Denial of Service attacks. A + DoS attack is typically + a packet attack. While there is not much you can do about modern spoofed packet attacks that saturate your network, you can generally limit the damage by ensuring that the attacks cannot take down your servers by: @@ -774,16 +775,16 @@ - A common DoS attack scenario is attacking a forking server and - making it spawning so many child processes that the host system - eventually runs out of memory, file descriptors, etc. and then - grinds to a halt. inetd - (see &man.inetd.8;) has several + A common DoS attack scenario is attacking a + forking server and making it spawning so many child processes that the + host system eventually runs out of memory, file descriptors, etc. and + then grinds to a halt. The inetd + application (see &man.inetd.8;) has several options to limit this sort of attack. It should be noted that while it is possible to prevent a machine from going down, it is not generally possible to prevent a service from being disrupted by the attack. Read the inetd manual - page carefully and pay + page &man.inetd.8; carefully and pay specific attention to the , , and options. Note that spoofed-IP attacks will circumvent the option to @@ -822,8 +823,8 @@ It is a very good idea to protect internal services from external access by firewalling them off at your border routers. The idea here is to prevent saturation attacks from outside your - LAN, not so much to protect internal services from network-based - root compromise. + LAN, not so much to protect internal services from + network-based root compromise. Always configure an exclusive firewall, i.e., firewall everything except ports A, B, C, D, and M-Z. This way you can firewall off all of your @@ -840,7 +841,7 @@ without compromising your low ports. Also take note that &os; allows you to control the range of port numbers used for dynamic binding, via the various net.inet.ip.portrange - sysctl's (sysctl -a | fgrep + sysctls (sysctl -a | fgrep portrange), which can also ease the complexity of your firewall's configuration. For example, you might use a normal first/last range of 4000 to 5000, and a hiport range of 49152 to @@ -848,9 +849,9 @@ (except for certain specific Internet-accessible ports, of course). - Another common DoS attack is called a springboard attack - — to attack a server in a manner that causes the server to - generate responses which overloads the server, the local + Another common DoS attack is called a + springboard attack — to attack a server in a manner that causes + the server to generate responses which overloads the server, the local network, or some other machine. The most common attack of this nature is the ICMP ping broadcast attack. The attacker spoofs ping packets sent to your LAN's broadcast @@ -862,13 +863,14 @@ trick on several dozen broadcast addresses over several dozen different networks at once. Broadcast attacks of over a hundred and twenty megabits have been measured. A second common - springboard attack is against the ICMP error reporting system. - By constructing packets that generate ICMP error responses, an - attacker can saturate a server's incoming network and cause the - server to saturate its outgoing network with ICMP responses. This - type of attack can also crash the server by running it out of - memory, especially if the server cannot drain the ICMP responses - it generates fast enough. + springboard attack is against the + ICMP error + reporting system. By constructing packets that generate + ICMP error responses, an attacker can saturate a + server's incoming network and cause the server to saturate its outgoing + network with ICMP responses. This type of attack can also crash the + server by running it out of memory, especially if the server cannot + drain the ICMP responses it generates fast enough. Use the sysctl variable net.inet.icmp.icmplim to limit these attacks. The last major class of springboard @@ -889,12 +891,12 @@ route cache. Refer to the net.inet.ip.rtexpire, rtminexpire, and rtmaxcache sysctl parameters. A spoofed packet attack - that uses a random source IP will cause the kernel to generate a - temporary cached route in the route table, viewable with + that uses a random source IP address will cause the kernel to generate + a temporary cached route in the route table, viewable with netstat -rna | fgrep W3. These routes typically timeout in 1600 seconds or so. If the kernel detects that the cached route table has gotten too big it will dynamically - reduce the rtexpire but will never decrease it + reduce the rtexpire but will never decrease it to less than rtminexpire. There are two problems: @@ -925,17 +927,16 @@ KerberosIV There are a few issues with both Kerberos and - ssh that need to be addressed if + SSH that need to be addressed if you intend to use them. Kerberos 5 is an excellent authentication protocol, but there are bugs in the kerberized telnet and rlogin applications that make them unsuitable for dealing with binary streams. Also, by default Kerberos does not encrypt a session unless you use the - option. ssh - encrypts everything by default. + option. SSH encrypts everything by default. - Ssh works quite well in every + SSH works quite well in every respect except that it forwards encryption keys by default. What this means is that if you have a secure workstation holding keys that give you access to the rest of the system, and you @@ -948,17 +949,16 @@ access to any other machine that your keys unlock. We recommend that you use ssh in - combination with Kerberos whenever possible for staff logins. - Ssh can be compiled with Kerberos - support. This reduces your reliance on potentially exposed - ssh keys while at the same time - protecting passwords via Kerberos. Ssh - keys should only be used for automated tasks from secure machines + combination with Kerberos whenever possible for staff logins. The + ssh client and server can be compiled with + Kerberos support. This reduces your reliance on potentially exposed + SSH keys while at the same time protecting passwords via Kerberos. + SSH keys should only be used for automated tasks from secure machines (something that Kerberos is unsuited to do). We also recommend that you either turn off key-forwarding in the - ssh configuration, or that you make use + ssh configuration, or that you make use of the from=IP/DOMAIN option that - ssh allows in its + ssh allows in its authorized_keys file to make the key only usable to entities logging in from specific machines. @@ -1000,48 +1000,52 @@ space of possible passwords. Unfortunately the only secure way to encrypt passwords when - &unix; came into being was based on DES, the Data Encryption - Standard. This was not such a problem for users resident in - the US, but since the source code for DES could not be exported - outside the US, &os; had to find a way to both comply with + &unix; came into being was based on + DES, the Data + Encryption Standard. This was not such a problem for users resident in + the US, but since the source code for DES could not be + exported outside the US, &os; had to find a way to both comply with US law and retain compatibility with all the other &unix; - variants that still used DES. + variants that still used DES. The solution was to divide up the encryption libraries - so that US users could install the DES libraries and use - DES but international users still had an encryption method - that could be exported abroad. This is how &os; came to - use MD5 as its default encryption method. MD5 is believed to - be more secure than DES, so installing DES is offered primarily - for compatibility reasons. + so that US users could install the DES libraries and + use DES but international users still had an + encryption method that could be exported abroad. This is how &os; came + to use MD5 as its default + encryption method. MD5 is believed to be more secure + than DES, so installing DES is + offered primarily for compatibility reasons. Recognizing Your Crypt Mechanism - Currently the library supports DES, MD5 and Blowfish hash - functions. By default &os; uses MD5 to encrypt + Currently the library supports DES, + MD5 and Blowfish hash + functions. By default &os; uses MD5 to encrypt passwords. It is pretty easy to identify which encryption method &os; is set up to use. Examining the encrypted passwords in the /etc/master.passwd file is one way. - Passwords encrypted with the MD5 hash are longer than those - encrypted with the DES hash and also begin with the characters - $1$. Passwords starting with - $2a$ are encrypted with the - Blowfish hash function. DES password strings do not - have any particular identifying characteristics, but they are - shorter than MD5 passwords, and are coded in a 64-character - alphabet which does not include the $ - character, so a relatively short string which does not begin with - a dollar sign is very likely a DES password. + Passwords encrypted with the MD5 hash are longer + than those encrypted with the DES hash and also + begin with the characters $1$. + Passwords starting with $2a$ are + encrypted with the Blowfish hash function. DES + password strings do not have any particular identifying characteristics, + but they are shorter than MD5 passwords, and are + coded in a 64-character alphabet which does not include the + $ character, so a relatively short string + which does not begin with a dollar sign is very likely a + DES password. The password format used for new passwords is controlled by the passwd_format login capability in /etc/login.conf, which takes values of des, md5 or blf. See the &man.login.conf.5; manual page - for more information about login capabilities. + for more information on login capabilities. @@ -1054,16 +1058,17 @@ one-time passwords - By default, &os; includes support for OPIE (One-time Passwords - In Everything), which uses the MD5 hash by default. + By default, &os; includes support for + OPIE + (One-time Passwords In Everything), which uses the + MD5 hash by default. There are three different sorts of passwords which we will discuss below. The first is your usual &unix; style or Kerberos password; we will call this a &unix; password. - The second sort is the one-time password which is generated by the OPIE - &man.opiekey.1; program and accepted by the - &man.opiepasswd.1; program - and the login prompt; we will + The second sort is the one-time password which is generated by the + OPIE &man.opiekey.1; program and accepted by the + &man.opiepasswd.1; program and the login prompt; we will call this a one-time password. The final sort of password is the secret password which you give to the opiekey program (and @@ -1075,32 +1080,33 @@ The secret password does not have anything to do with your &unix; password; they can be the same but this is not recommended. - OPIE secret passwords are not limited to 8 characters like old - &unix; passwordsUnder &os; the standard login + OPIE secret passwords are not limited to 8 characters + like old &unix; passwordsUnder &os; the standard login password may be up to 128 characters in length., they can be as long as you like. Passwords of six or seven word long phrases are fairly common. For the most part, the - OPIE system operates completely independently of the &unix; - password system. + OPIE system operates completely independently of the + &unix; password system. Besides the password, there are two other pieces of data that - are important to OPIE. One is what is known as the + are important to OPIE. One is what is known as the seed or key, consisting of two letters and five digits. The other is what is called the iteration - count, a number between 1 and 100. OPIE creates the - one-time password by concatenating the seed and the secret password, - then applying the MD5 hash as many times as specified by the - iteration count and turning the result into six short English words. - These six English words are your one-time password. The - authentication system (primarily PAM) keeps - track of the last one-time password used, and the user is + count, a number between 1 and 100. OPIE + creates the one-time password by concatenating the seed and the secret + password, then applying the MD5 hash as many times as + specified by the iteration count and turning the result into six short + English words. These six English words are your one-time password. The + authentication system (primarily + PAM) + keeps track of the last one-time password used, and the user is authenticated if the hash of the user-provided password is equal to the previous password. Because a one-way hash is used it is impossible to generate future one-time passwords if a successfully used password is captured; the iteration count is decremented after each successful login to keep the user and the login program in - sync. When the iteration count gets down to 1, OPIE must be - reinitialized. + sync. When the iteration count gets down to 1, OPIE + must be reinitialized. There are a few programs involved in each system which we will discuss below. The @@ -1108,7 +1114,7 @@ count, a seed, and a secret password, and generates a one-time password or a consecutive list of one-time passwords. The opiepasswd - program is used to initialize OPIE, + program is used to initialize OPIE, and to change passwords, iteration counts, or seeds; it takes either a secret passphrase, or an iteration count, seed, and a one-time password. The @@ -1133,8 +1139,8 @@ Secure Connection Initialization - To initialize OPIE for the first time, execute the - opiepasswd command: + To initialize OPIE for the first time, execute + the opiepasswd command: &prompt.user; opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c @@ -1210,7 +1216,7 @@ Generating a Single One-time Password - Once you have initialized OPIE and login, you will be + Once you have initialized OPIE and login, you will be presented with a prompt like this: &prompt.user; telnet example.com @@ -1224,8 +1230,8 @@ otp-md5 498 gr4269 ext Password: - As a side note, the OPIE prompts have a useful feature - (not shown here): if you press Return + As a side note, the OPIE prompts have a useful + feature (not shown here): if you press Return at the password prompt, the prompter will turn echo on, so you can see what you are typing. This can be extremely useful if you are attempting to @@ -1290,8 +1296,8 @@ Restricting Use of &unix; Passwords - OPIE can restrict the use of &unix; passwords based on the IP - address of a login session. The relevant file + OPIE can restrict the use of &unix; passwords + based on the IP address of a login session. The relevant file is /etc/opieaccess, which is present by default. Please check &man.opieaccess.5; for more information on this file and which security considerations @@ -1327,7 +1333,8 @@ TCP Wrappers Anyone familiar with &man.inetd.8; has probably heard - of TCP Wrappers at some point. But few + of TCP + Wrappers at some point. But few individuals seem to fully comprehend its usefulness in a network environment. It seems that everyone wants to install a firewall to handle network connections. While a @@ -1591,8 +1598,9 @@ during the era of restrictive export controls on cryptographic code from the USA. - Alternatively, the MIT implementation of Kerberos is - available from the Ports Collection as + Alternatively, the + MIT + implementation of Kerberos is available from the Ports Collection as security/krb5. @@ -1889,7 +1897,7 @@ Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Now try changing the password using &man.passwd.1; to - check if the kpasswd daemon can get + check if the kpasswd daemon can get authorization to the Kerberos database: &prompt.user; passwd @@ -2133,7 +2141,7 @@ programs that implement the program (Kerberos telnet, for example). The current version of the protocol is version 5, described in - RFC 1510. + RFC 1510. Several free implementations of this protocol are available, covering a wide range of operating systems. The Massachusetts @@ -2168,7 +2176,8 @@ Key Distribution Center - The Key Distribution Center (KDC) is the + The Key Distribution Center + KDC) is the centralized authentication service that Kerberos provides — it is the computer that issues Kerberos tickets. @@ -2580,8 +2589,9 @@ immediately upon running kinit — even before you type your password! The explanation is that the Kerberos server freely - transmits a TGT (Ticket Granting - Ticket) to any unauthorized request; however, every + transmits a + TGT (Ticket + Granting Ticket) to any unauthorized request; however, every TGT is encrypted in a key derived from the user's password. Therefore, when a user types their password it is not being sent to the KDC, @@ -2726,7 +2736,7 @@ - The KDC is a single point of failure + The <acronym>KDC</acronym> is a single point of failure By design, the KDC must be as secure as the master password database is contained on it. The @@ -2783,7 +2793,8 @@ - The Kerberos FAQ + The Kerberos FAQ + @@ -2792,9 +2803,10 @@ - RFC 1510, - The Kerberos Network Authentication Service - (V5) + + RFC 1510, The Kerberos + Network Authentication Service (V5) @@ -2850,9 +2862,12 @@ The version of OpenSSL included - in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3), - Transport Layer Security v1 (TLSv1) network security protocols - and can be used as a general cryptographic library. + in &os; supports Secure Sockets Layer v2/v3 ( + SSLv2/ + SSLv3), Transport Layer Security v1 + (TLSv1) network + security protocols and can be used as a general cryptographic library. + While OpenSSL supports the @@ -2869,8 +2884,9 @@ that the credentials of the company or individual are valid and not fraudulent. If the certificate in question has not been verified by one of the several Certificate Authorities, - or CAs, a warning is usually produced. A - Certificate Authority is a company, such as VeriSign, which will + or CAs, a warning is + usually produced. A Certificate Authority is a company, such as + VeriSign, which will sign certificates in order to validate credentials of individuals or companies. This process has a cost associated with it and is definitely not a requirement for using certificates; however, @@ -2961,9 +2977,9 @@ So what can these files do? A good use would be to encrypt connections to the Sendmail - MTA. This would dissolve the use of clear - text authentication for users who send mail via the local - MTA. + MTA. This would + dissolve the use of clear text authentication for users who send + mail via the local MTA. This is not the best use in the world as some @@ -3047,7 +3063,8 @@ VPN over IPsec - Creating a VPN between two networks, separated by the + Creating a VPN + between two networks, separated by the Internet, using FreeBSD gateways. @@ -3067,30 +3084,33 @@ Understanding IPsec This section will guide you through the process of setting - up IPsec, and to use it in an environment which consists of + up IPsec, and to use it in an + environment which consists of FreeBSD and µsoft.windows; 2000/XP machines, to make them communicate securely. In order to set up - IPsec, it is necessary that you are familiar with the concepts - of building a custom kernel (see + IPsec, it is necessary that you are familiar with + the concepts of building a custom kernel (see ). IPsec is a protocol which sits on top - of the Internet Protocol (IP) layer. It allows two or more - hosts to communicate in a secure manner (hence the name). The - FreeBSD IPsec network stack is based on the - KAME implementation, - which has support for both protocol families, IPv4 and - IPv6. + of the Internet Protocol + () layer. It allows two + or more hosts to communicate in a secure manner (hence the name). The + FreeBSD IPsec network stack is based + on the KAME implementation, + which has support for both protocol families, IPv4 and IPv6. FreeBSD contains a hardware - accelerated IPsec stack, known as Fast - IPsec, that was obtained from OpenBSD. It employs + accelerated IPsec stack, known as + Fast IPsec, that was obtained from OpenBSD. It employs cryptographic hardware (whenever possible) via the - &man.crypto.4; subsystem to optimize the performance of IPsec. + &man.crypto.4; subsystem to optimize the performance of + IPsec. This subsystem is new, and does not support all the features - that are available in the KAME version of IPsec. However, in - order to enable hardware-accelerated IPsec, the following + that are available in the KAME version of IPsec. + However, in order to enable hardware-accelerated + IPsec, the following kernel option has to be added to your kernel configuration file: @@ -3105,8 +3125,8 @@ Note, that it is not currently possible to use the Fast IPsec subsystem in lieu of the KAME - implementation of IPsec. Consult the &man.fast.ipsec.4; - manual page for more information. + implementation of IPsec. Consult the + &man.fast.ipsec.4; manual page for more information. @@ -3130,23 +3150,25 @@ AH - IPsec consists of two sub-protocols: + IPsec consists of two sub-protocols: Encapsulated Security Payload - (ESP), protects the IP packet data from third - party interference, by encrypting the contents using + (ESP) + , protects the IP packet data from + third party interference, by encrypting the contents using symmetric cryptography algorithms (like Blowfish, - 3DES). + 3DES). - Authentication Header (AH), - protects the IP packet header from third party interference - and spoofing, by computing a cryptographic checksum and - hashing the IP packet header fields with a secure hashing - function. This is then followed by an additional header - that contains the hash, to allow the information in the + Authentication Header + (AH), + protects the IP packet header from third party + interference and spoofing, by computing a cryptographic checksum + and hashing the IP packet header fields with a + secure hashing function. This is then followed by an additional + header that contains the hash, to allow the information in the packet to be authenticated. @@ -3164,18 +3186,19 @@ VPN - IPsec can either be used to directly encrypt the traffic - between two hosts (known as Transport - Mode); or to build virtual tunnels + IPsec can either be used to directly encrypt + the traffic between two hosts (known as Transport + Mode); or to build virtual tunnels between two subnets, which could be used for secure communication between two corporate networks (known as Tunnel Mode). The latter is more commonly - known as a Virtual Private Network (VPN). - The &man.ipsec.4; manual page should be consulted for detailed - information on the IPsec subsystem in FreeBSD. + known as a Virtual Private Network (VPN) + . The &man.ipsec.4; manual page should be consulted for + detailed information on the IPsec subsystem in + &os;. - To add IPsec support to your kernel, add the following - options to your kernel configuration file: + To add IPsec support to your kernel, add the + following options to your kernel configuration file: kernel options @@ -3208,11 +3231,12 @@ The Problem - There is no standard for what constitutes a VPN. VPNs can - be implemented using a number of different technologies, each of + There is 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 section presents a scenario, and the strategies used for implementing a - VPN for this scenario. + VPN for this scenario. @@ -3231,33 +3255,36 @@ You have at least two sites - Both sites are using IP internally + 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 gateway on each network has at least one public + IPaddress. The internal addresses of the two networks can be - public or private IP addresses, it does not matter. You can - be running NAT on the gateway machine if necessary. + public or private IP addresses, it does not + matter. You can be running + NAT on the + gateway machine if necessary. - The internal IP addresses of the two networks - do not collide. While 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 + The internal IP addresses of the two + networks do not collide. While 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 IP + address range (e.g. both of them use 192.168.1.x), then one of the networks will have to be renumbered. @@ -3293,14 +3320,16 @@ - Notice the two public IP addresses. I will use the letters to + Notice the two public IP addresses. I will use + the letters to refer to them 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 internally, the two gateway - machines have .1 IP addresses, and that the two networks have - different private IP addresses (192.168.1.x and 192.168.2.x respectively). All the + machines have .1 IP + addresses, and that the two networks have different private + IP addresses + (192.168.1.x and + 192.168.2.x respectively). All the machines on the private networks have been configured to use the .1 machine as their default gateway. @@ -3323,8 +3352,8 @@ 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: + Creating a VPN between these two networks is a + multi-step process. The stages are as follows: @@ -3343,7 +3372,7 @@ Configure additional software on the FreeBSD gateways, to allow &windows; machines to see one another across the - VPN. + VPN. @@ -3400,9 +3429,9 @@ the public IP addresses, and two for the private IP addresses. - Support for the gif device must be compiled in to the - &os; kernel on both machines. You can do this by adding the - line: + Support for the gif device must be + compiled in to the &os; kernel on both machines. You can do this by + adding the line: device gif @@ -3410,8 +3439,9 @@ 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 &man.ifconfig.8;. Then the private IP addresses must be + tunnel must be told what the outside (or public) IP + addresses are, using &man.ifconfig.8;. Then the private + IP addresses must be configured using &man.ifconfig.8;. On the gateway machine on network #1 you would run the @@ -3423,7 +3453,8 @@ On the other gateway machine you run the same commands, - but with the order of the IP addresses reversed. + but with the order of the IP addresses reversed. + &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 tunnel W.X.Y.Z A.B.C.D @@ -3471,15 +3502,16 @@ shortly. It is likely that you are running a firewall on both - machines. This will 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 rules that - protect both ends of the VPN from one another. + machines. This will 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 rules + 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 you are using &man.ipfw.8; on the - gateway machines then a command like + firewall to allow all traffic through the VPN. + You can always tighten things up later. If you are using &man.ipfw.8; + on the gateway machines then a command like ipfw add 1 allow ip from any to any via gif0 @@ -3487,9 +3519,10 @@ VPN, without affecting your other firewall rules. Obviously you will need to run this 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 + 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 @@ -3497,7 +3530,7 @@ thing on the other gateway machine. However, you will not be able to reach internal machines - on either network yet. This is because of the routing -- + on either network yet. This is because of the routing — although the gateway machines know how to reach one another, they do not know how to reach the network behind each one. @@ -3516,12 +3549,12 @@ 192.168.1.x addresses instead. - IP traffic from hosts on one network will now be able to - reach hosts on the other network. + IP traffic from hosts on one network will now + be able to reach hosts on the other network. - That has now created two thirds of a VPN between the two - networks, in as much as it is virtual and it is a - network. It is not private yet. You can test + That has now created two thirds of a VPN between + the two networks, in as much as it is virtual and it is + a network. It is not private yet. You can test this using &man.ping.8; and &man.tcpdump.1;. Log in to the gateway host and run @@ -3542,10 +3575,10 @@ 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 parameter to - &man.tcpdump.1; to grab more bytes of data from the packets you - would see more information. + As you can see, the ICMP messages are going + back and forth unencrypted. If you had used the + parameter to &man.tcpdump.1; 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 @@ -3586,7 +3619,8 @@ Step 2: Securing the link - To secure the link we will be using IPsec. IPsec provides + 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 order to encrypt data between the two hosts. @@ -3603,10 +3637,10 @@ There must be a mechanism for specifying which traffic should be encrypted. Obviously, you do not 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. + 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. @@ -3614,7 +3648,8 @@ 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 configuring a kernel with: + (ESP) protocol. This is done by configuring a + kernel with: kernel options @@ -3637,7 +3672,9 @@ 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 this for you. + Key Exchange protocol + (IKE) to do this + for you. I recommend the latter. Apart from anything else, it is easier to set up. @@ -3662,26 +3699,28 @@ There are a number of choices for daemons to manage security associations with FreeBSD. This article will describe how to use one of these, racoon — which is available from - security/ipsec-tools in the &os; Ports - collection. + security/ipsec-tools in the &os; + Ports Collection. racoon - The racoon software 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 racoon software 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 + 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 will not do them much good -- by the time they have cracked - the key the two daemons have chosen another one. + gets) it will not do them much good — by the time they have + cracked the key the two daemons have chosen another one. The configuration file for racoon is stored in ${PREFIX}/etc/racoon. You should find a @@ -3691,9 +3730,10 @@ 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-shared key is not the key that will be used to - encrypt your traffic across the VPN link, it is simply a token + the file ${PREFIX}/etc/racoon/psk.txt. It is + important to note that the pre-shared key is not + the key that will be used to encrypt your traffic across the + VPN link, it is simply a token that allows the key management daemons to trust one another. psk.txt contains a line for each @@ -3705,23 +3745,28 @@ W.X.Y.Z secret - That is, the public IP address of the remote end, - whitespace, and a text string that provides the secret. - Obviously, you should not use secret as your key -- the normal + That is, the public IP + address of the remote end, whitespace, and a text string that + provides the secret. Obviously, you should not 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 + That is, the public IP address of the remote + end, and the same secret key. 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 (Internet Security Association + also need to add some firewall rules to allow the + IKE traffic, + which is carried over UDP to the + ISAKMP (Internet Security Association Key Management Protocol) port. Again, this should be fairly early in your firewall ruleset. @@ -3732,7 +3777,7 @@ 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 + 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 @@ -3750,12 +3795,14 @@ 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 + 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 + 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: @@ -3805,11 +3852,13 @@ This encapsulation is carried out by the gif device. As - you can see, the packet now has real IP addresses on the outside, + you can see, the 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 the Internet. - Obviously, we want all traffic between the VPNs to be + Obviously, we want all traffic between the + VPNs to be encrypted. You might try putting this in to words, as: If a packet leaves from 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: + 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; @@ -3865,7 +3914,8 @@ 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 + role="ipaddr">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. tells the kernel that @@ -3893,15 +3943,16 @@ 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 need similar rules. + The other gateway host (which has the public + IP address W.X.Y.Z) + will need 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. + 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 @@ -3944,7 +3995,8 @@ - When they are received by the far end of the VPN they will + 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 @@ -3966,12 +4018,13 @@ XXX tcpdump output - Now, as you can see, &man.tcpdump.1; shows the ESP packets. If + Now, as you can see, &man.tcpdump.1; shows the + ESP packets. If you try to examine them with the option you will see (apparently) gibberish, because of the encryption. - Congratulations. You have just set up a VPN between two - remote sites. + Congratulations. You have just set up a VPN + between two remote sites. Summary @@ -3986,7 +4039,8 @@ Install security/ipsec-tools. Edit ${PREFIX}/etc/racoon/psk.txt on both - gateway hosts, adding an entry for the remote host's IP + 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. @@ -4020,7 +4074,8 @@ - Add firewall rules to allow IKE, ESP, and IPENCAP + Add firewall rules to allow IKE, + ESP, and IPENCAP traffic to both hosts: @@ -4034,10 +4089,11 @@ - The previous two steps should suffice to get the VPN up and + 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. + another using IP addresses, and all traffic across + the link will be automatically and securely encrypted. @@ -4065,14 +4121,16 @@ access remote machines securely. It can be used as a direct replacement for rlogin, rsh, rcp, and - telnet. Additionally, TCP/IP - connections can be tunneled/forwarded securely through SSH. + telnet. Additionally, TCP/IP + connections can be tunneled/forwarded securely through SSH. OpenSSH encrypts all traffic to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. - OpenSSH is maintained by the OpenBSD project, and is based + OpenSSH is maintained by the OpenBSD + project, and is based upon SSH v1.2.12 with all the recent bug fixes and updates. It - is compatible with both SSH protocols 1 and 2. + is compatible with both SSH protocols 1 and 2. Advantages of Using OpenSSH @@ -4124,12 +4182,13 @@ The login will continue just as it would have if a session was created using rlogin or - telnet. SSH utilizes a key fingerprint - system for verifying the authenticity of the server when the - client connects. The user is prompted to enter + telnet. SSH utilizes a key + fingerprint system for verifying the authenticity of the server when + the client connects. The user is prompted to enter yes only when connecting for the first time. Future attempts to login are all - verified against the saved fingerprint key. The SSH client + verified against the saved fingerprint key. The + SSH client will alert you if the saved fingerprint differs from the received fingerprint on future login attempts. The fingerprints are saved in ~/.ssh/known_hosts, or @@ -4137,7 +4196,8 @@ fingerprints. By default, recent versions of the - OpenSSH servers only accept SSH v2 + OpenSSH servers only accept + SSHv2 connections. The client will use version 2 if possible and will fall back to version 1. The client can also be forced to use one or the other by passing it the or @@ -4170,8 +4230,8 @@ The arguments passed to &man.scp.1; are similar to &man.cp.1;, with the file or files in the first argument, and the destination in the second. Since the file is - fetched over the network, through SSH, one or more of the file - arguments takes on the form + fetched over the network, through SSH, one or + more of the file arguments takes on the form . @@ -4201,7 +4261,8 @@ ssh-keygen Instead of using passwords, &man.ssh-keygen.1; can - be used to generate DSA or RSA keys to authenticate a user: + be used to generate DSA or RSA + keys to authenticate a user: &prompt.user; ssh-keygen -t dsa Generating public/private dsa key pair. @@ -4223,12 +4284,12 @@ ~/.ssh/id_rsa.pub, respectively for DSA and RSA key types. The public key must be placed in ~/.ssh/authorized_keys of the remote - machine in order for the setup to work. Similarly, RSA version - 1 public keys should be placed in + machine in order for the setup to work. Similarly, + RSA version 1 public keys should be placed in ~/.ssh/authorized_keys. This will allow connection to the remote machine based upon - SSH keys instead of passwords. + SSH keys instead of passwords. If a passphrase is used in &man.ssh-keygen.1;, the user will be prompted for a password each time in order to use the @@ -4246,7 +4307,7 @@ ssh-agent and ssh-add The &man.ssh-agent.1; and &man.ssh-add.1; utilities provide - methods for SSH keys to be loaded + methods for ssh keys to be loaded into memory for use, without needing to type the passphrase each time. @@ -4283,7 +4344,7 @@ launch XFCE, every time X11 starts. Then once that is done and X11 has been restarted so that the changes can take effect, simply run &man.ssh-add.1; to load - all of your SSH keys. + all of your SSH keys. @@ -4312,7 +4373,7 @@ Forces ssh to use version 2 of the protocol. (Do not use if you are working with older - SSH servers) + SSH servers) @@ -4349,29 +4410,33 @@ - The remote SSH server. + The remote SSH server. - An SSH tunnel works by creating a listen socket on - localhost on the specified port. + A SSH tunnel works by creating a listen socket + om localhost on the specified port. It then forwards any connection received - on the local host/port via the SSH connection to the specified - remote host and port. + on the local host/port via the SSH connection to + the specified remote host and port. In the example, port 5023 on localhost is being forwarded to port 23 on localhost - of the remote machine. Since 23 is telnet, - this would create a secure telnet session through an SSH tunnel. - - This can be used to wrap any number of insecure TCP - protocols such as SMTP, POP3, FTP, etc. + of the remote machine. Since 23 is + telnet, + this would create a secure telnet session + through an SSH tunnel. + + This can be used to wrap any number of insecure + TCP protocols such as SMTP, + POP3, FTP, etc. - Using SSH to Create a Secure Tunnel for SMTP + Using <acronym>SSH</acronym> to Create a Secure Tunnel for + <acronym>SMTP</acronym> &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** @@ -4383,52 +4448,55 @@ This can be used in conjunction with an &man.ssh-keygen.1; and additional user accounts to create a - more seamless/hassle-free SSH tunneling environment. Keys - can be used in place of typing a password, and the tunnels - can be run as a separate user. + more seamless/hassle-free SSH tunneling + environment. Keys can be used in place of typing a password, an + the tunnels can be run as a separate user. - Practical SSH Tunneling Examples + Practical <acronym>SSH</acronym> Tunneling Examples - Secure Access of a POP3 Server + Secure Access of a <acronym>POP3</acronym> Server - At work, there is an SSH server that accepts + At work, there is an SSH server that accepts connections from the outside. On the same office network - resides a mail server running a POP3 server. The network, + resides a mail server running a POP3 server. + The network, or network path between your home and office may or may not be completely trustable. Because of this, you need to check your e-mail in a secure manner. The solution is to create - an SSH connection to your office's SSH server, and tunnel + an ssh connection to your office's + SSH server, and tunnel through to the mail server. &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ****** When the tunnel is up and running, you can point your - mail client to send POP3 requests to localhost + mail client to send POP3 requests to + localhost port 2110. A connection here will be forwarded securely across the tunnel to mail.example.com. - Bypassing a Draconian Firewall + Bypassing a draconian Firewall Some network administrators impose extremely draconian firewall rules, filtering not only incoming connections, but outgoing connections. You may be only given access - to contact remote machines on ports 22 and 80 for SSH - and web surfing. + to contact remote machines on ports 22 and 80 for + SSH and web surfing. You may wish to access another (perhaps non-work related) service, such as an Ogg Vorbis server to stream music. If this Ogg Vorbis server is streaming on some other port than 22 or 80, you will not be able to access it. - The solution is to create an SSH connection to a machine - outside of your network's firewall, and use it to tunnel to - the Ogg Vorbis server. + The solution is to create an SSH connection + to a machine outside of your network's firewall, and use it to + tunnel to the Ogg Vorbis server. &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: ******* @@ -4501,7 +4569,7 @@ In conjunction with file system enhancements like snapshots, FreeBSD 5.0 and later offers the security of File System Access Control Lists - (ACLs). + (ACLs). Access Control Lists extend the standard &unix; permission model in a highly compatible (&posix;.1e) way. This feature >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Mon Nov 13 11:06:18 2006 Return-Path: X-Original-To: doc@hub.freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DD2616A403 for ; Mon, 13 Nov 2006 11:06:18 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3921B43D5C for ; Mon, 13 Nov 2006 11:06:18 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kADB6IHH090500 for ; Mon, 13 Nov 2006 11:06:18 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kADB6GFx090493 for DOC; Mon, 13 Nov 2006 11:06:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Nov 2006 11:06:16 GMT Message-Id: <200611131106.kADB6GFx090493@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: FreeBSD doc list Cc: Subject: Current unassigned doc problem reports X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 11:06:18 -0000 Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o docs/27605 doc [patch] Cross-document references () s docs/35678 doc docproj Makefiles for web are broken for paths with sp o docs/61605 doc [feature request] Improve documentation for i386 disk o docs/80843 doc [patch] psm(4): Suggested fix for psm0 / handle driver o docs/84932 doc new document: printing with an Epson ALC-3000N on Free o docs/98115 doc Missing parts after rendering handbook to RTF format 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s docs/20028 doc ASCII docs should reflect tags in the sourc o docs/24786 doc missing FILES descriptions in sa(4) o docs/26286 doc *printf(3) etc should gain format string warnings a docs/30008 doc [patch] French softupdates document should be translat s docs/33589 doc [patch] to doc.docbook.mk to post process .tex files. o docs/35222 doc [patch] getmsg.cgi: mailing list archive URL regexp su o docs/35608 doc mt(1) page uses "setmark" without explanation. o docs/35609 doc mt(1) page needs explanation of "long erase". o docs/35612 doc ps(1) page "state" description doesn't mention "spread o docs/35953 doc hosts.equiv(5) manual is confusing or wrong about host o docs/36432 doc Proposal for doc/share/mk: make folded books using psu o docs/36449 doc symlink(7) manual doesn't mention trailing slash, etc. o docs/38982 doc [patch] developers-handbook/Jail fix o docs/39348 doc diskless(8): note that kenv fetch of hostname requires o docs/39530 doc access(2) man page has unnecessarily broad warning o docs/40423 doc Keyboard(4)'s definition of parameters to GETFKEY/SETF o docs/41089 doc pax(1) -B option does not mention interaction with -z o docs/41807 doc [patch] natd(8): document natd -punch_fw "bug" o docs/43823 doc [PATCH] update to environ(7) manpage o docs/43941 doc document the Rationale for Upgrade Sequence (e.g. why o docs/44074 doc [patch] ln(1) manual clarifications o docs/46295 doc please add information to Nvi recovery email o docs/47594 doc [PATCH] passwd(5) incorrectly states allowed username o docs/47818 doc [patch] ln(1) manpage is confusing o docs/48101 doc [patch] add documentation on the fixit disk to the FAQ o docs/50211 doc [PATCH] doc.docbook.mk: fix textfile creation o docs/51891 doc DIAGNOSTICS in ed(4) driver manpage don't match realit o docs/52071 doc [PATCH] Add more information about soft updates into a o docs/53575 doc Change to Handbook Section 20.9 (SMTP Authentication) o docs/53596 doc Updates to mt(1) manual page s docs/55482 doc document the fact that DUMP has access to block device o docs/57388 doc [patch] INSTALL.TXT enhancement: mention ok prompt o docs/57926 doc [patch] amd.conf(5) poorly format as it has both man(7 o docs/59044 doc [patch] doc.docbook.mk does not properly handle a sour o docs/59477 doc Outdated Info Documents at http://docs.freebsd.org/inf o docs/59835 doc ipfw(8) man page does not warn about accepted but mean o docs/61070 doc handbook: Installation docs misleading: PResizer isn' o docs/61301 doc [patch] Manpage patch for aue(4) to enable HomePNA fun o docs/61667 doc Obsolete documentation on FreeBSD PnP o docs/62412 doc one of the diskless boot methods described in the Hand o docs/63215 doc Wrong prototypes in mi_switch(9) (ref docs/24311) o docs/64807 doc Handbook section on NAT incomplete o docs/65477 doc release notes: installation instruction fail to mentio o docs/66265 doc [patch] Document what -f and LD_TRACE_LOADED_OBJECTS_F o docs/66296 doc [patch] contrib/amd/amq/amq.8 uses log_options instead o docs/66483 doc [patch] share/man/man4/csa.4 grammar nits o docs/69861 doc [patch] usr.bin/csplit/csplit.1 does not document POSI o docs/70217 doc [patch] Suggested rewrite of docproj/sgml.sgml for cla o docs/73679 doc FreeBSD 5.3 Release notes mention new natd(8) function o docs/74612 doc [patch] updates to the glossary o docs/75865 doc comments on "backup-basics" in handbook o docs/75995 doc hcreate(3) documentation(?) bug o docs/76333 doc [patch] ferror(3): EOF indicator can be cleared by not o docs/77087 doc [patch] the bootvinum script given in the vinum articl o docs/78041 doc [patch] docs for md(4) need further explanation of typ o docs/78138 doc [patch] Error in pre-installation section of installat o docs/78240 doc [patch] handbook: replace with aroun o docs/78480 doc Networked printer setup unnecessarily complex in handb o docs/78915 doc rfork(2)'s RFTHREAD is not documented o docs/82595 doc 25.5.3 Configuring a bridge section of the handbook ne o docs/83621 doc [patch]: Minor omissions in /usr/src/UPDATING p docs/84101 doc [patch] mt(1) manpage has erroneous synopsis, etc. o docs/84154 doc Handbook somewhat off in use of /boot/kernel.old o docs/84265 doc [patch] chmod(1) manpage omits implication of setting p docs/84266 doc [patch] security(8) manpage should have init(8)'s list o docs/84267 doc [patch] chflags(1) manual doesn't say it's affected by o docs/84268 doc chmod(1) manpage's BUGS entry is either wrong or too c o docs/84317 doc fdp-primer doesn't show class=USERNAME distinctively o docs/84670 doc [patch] tput(1) manpage missing ENVIRONMENT section wi o docs/84806 doc mdoc(7) manpage has section ordering problems o docs/84956 doc [patch] intro(5) manpage doesn't mention API coverage o docs/85118 doc [PATCH] opiekey(1) references non-existing opiegen(1) o docs/85128 doc loader.conf(5) autoboot_delay incompletly described o docs/85187 doc [patch] find(1) manpage missing block info for -ls o docs/85243 doc Missing icmp related abbreviations for pf.conf(5) in i o docs/86342 doc bikeshed entry of Handbook is wrong o docs/87857 doc ifconfig(8) wireless options order matters o docs/87936 doc Handbook chapter on NIS/YP lacks good information on a o docs/88477 doc Possible addition to xl(4) manpage, Diagnostics sectio o docs/88512 doc [patch] mount_ext2fs(8) man page has no details on lar o docs/89325 doc [PATCH] Clarification of kbdmap(5), atkbd(4) and kbdco o docs/89492 doc vfs doc: some VOP_*(9) manual pages are outdated with o docs/91149 doc read(2) can return EINVAL for unaligned access to bloc o docs/91506 doc ndis(4) man page should be more specific about support o docs/92626 doc jail manpage should mention disabling some periodic sc o docs/93249 doc rewrite of handbook chapter 23 (PPP & SLIP) o docs/93363 doc Handbook 23.11. SMTP-Authentifizierung o docs/94125 doc DGE-530T doesn't work on FreeBSD v6.0 o docs/94625 doc [patch] growfs man page -- document "panic: not enough o docs/95139 doc FAQ to move filesystem to new disk fails: incorrect pe o docs/96207 doc Comments of a sockaddr_un structure could confuse one o docs/97939 doc some mistake in man of amq(8) o docs/98974 doc Missing tunables in loader(8) manpage o docs/99007 doc [patch] misleading nat configuration info o docs/99506 doc FreeBSD Handbook addition: IPv6 Server Settings o docs/99845 doc [patch] First introduce porttools to Porter's Handbook o docs/100196 doc man login.conf does explain not "unlimited" o docs/100242 doc sysctl(3) description of KERN_PROC is not correct anym o docs/101464 doc sync u_RU.KOI8-R/articles/portbuild/article.html with o docs/102148 doc The description of which Intel chips have EM64T is out o docs/102719 doc [patch] ng_bpf(4) example leads to unneeded promiscuos f docs/103730 doc [mail-archive]: duplicated file in mail archive o docs/104403 doc man security should mention that the usage of the X Wi o docs/104432 doc No mention of "let" shell builtin in manual pages. o docs/104493 doc [patch] Wrong description in ntp.conf(5) (CURRENT and o docs/104879 doc Howto: Listen to IMA ADPCM .wav files on FreeBSD box o docs/105440 doc Incorrect example in audit documentation o docs/105441 doc [PATCH] PH: add new Lua variables o docs/105456 doc [patch] overhaul of the security chapter (14) 109 problems total. From owner-freebsd-doc@FreeBSD.ORG Mon Nov 13 14:19:50 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6145E16A47B; Mon, 13 Nov 2006 14:19:50 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F95A43D69; Mon, 13 Nov 2006 14:19:50 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kADEJnou013909; Mon, 13 Nov 2006 14:19:49 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kADEJnLo013905; Mon, 13 Nov 2006 14:19:49 GMT (envelope-from maxim) Date: Mon, 13 Nov 2006 14:19:49 GMT From: Maxim Konovalov Message-Id: <200611131419.kADEJnLo013905@freefall.freebsd.org> To: steve@stevenwills.com, maxim@FreeBSD.org, freebsd-doc@FreeBSD.org Cc: Subject: Re: docs/105440: Incorrect example in audit documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 14:19:50 -0000 Synopsis: Incorrect example in audit documentation State-Changed-From-To: open->closed State-Changed-By: maxim State-Changed-When: Mon Nov 13 14:19:30 UTC 2006 State-Changed-Why: Fixed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=105440 From owner-freebsd-doc@FreeBSD.ORG Mon Nov 13 14:20:13 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6B4216A47C for ; Mon, 13 Nov 2006 14:20:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83A7C43D7E for ; Mon, 13 Nov 2006 14:20:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kADEK8c4014030 for ; Mon, 13 Nov 2006 14:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kADEK89t014028; Mon, 13 Nov 2006 14:20:08 GMT (envelope-from gnats) Date: Mon, 13 Nov 2006 14:20:08 GMT Message-Id: <200611131420.kADEK89t014028@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: docs/105440: commit references a PR X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 14:20:13 -0000 The following reply was made to PR docs/105440; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: docs/105440: commit references a PR Date: Mon, 13 Nov 2006 14:19:19 +0000 (UTC) maxim 2006-11-13 14:19:12 UTC FreeBSD doc repository Modified files: en_US.ISO8859-1/books/handbook/audit chapter.sgml Log: o Fin an incorrect crontab entry example. PR: docs/105440 Submitted by: Steve Wills Revision Changes Path 1.25 +1 -1 doc/en_US.ISO8859-1/books/handbook/audit/chapter.sgml _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-doc@FreeBSD.ORG Mon Nov 13 18:53:42 2006 Return-Path: X-Original-To: doc@freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74A3C16A49E for ; Mon, 13 Nov 2006 18:53:42 +0000 (UTC) (envelope-from greg@codeconcepts.com) Received: from gromit.codeconcepts.com (rrcs-24-153-140-106.sw.biz.rr.com [24.153.140.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 633FA44174 for ; Mon, 13 Nov 2006 18:45:07 +0000 (GMT) (envelope-from greg@codeconcepts.com) Received: from gromit.codeconcepts.com (localhost [127.0.0.1]) by gromit.codeconcepts.com (8.13.6/8.13.6) with ESMTP id kADIin5h023047 for ; Mon, 13 Nov 2006 12:44:49 -0600 (CST) (envelope-from greg@gromit.codeconcepts.com) Message-Id: <200611131844.kADIin5h023047@gromit.codeconcepts.com> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: doc@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 2006 12:44:49 -0600 From: Greg Becker Cc: Subject: My name not on additional contributors page... X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 18:53:42 -0000 Hi! I am wondering what one need do to get on the additional contributors page. I thought I would qualify as I am the creator/maintainer of the devel/dits port, but so far my name hasn't shown up on the list. Thanks! Greg http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/contrib-additi onal.html -- The comfort of a knowledge of the rise above the sky above could never parallel the challenge of an acquisition in the here and now From owner-freebsd-doc@FreeBSD.ORG Mon Nov 13 22:22:47 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AC3316A4B3 for ; Mon, 13 Nov 2006 22:22:47 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3166343D81 for ; Mon, 13 Nov 2006 22:20:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kADMK6KL057272 for ; Mon, 13 Nov 2006 22:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kADMK6Kk057271; Mon, 13 Nov 2006 22:20:06 GMT (envelope-from gnats) Resent-Date: Mon, 13 Nov 2006 22:20:06 GMT Resent-Message-Id: <200611132220.kADMK6Kk057271@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Alejandro Pulver" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7A6E16A4D8 for ; Mon, 13 Nov 2006 22:11:31 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 850A943DA1 for ; Mon, 13 Nov 2006 22:11:03 +0000 (GMT) (envelope-from alepulver@FreeBSD.org) Received: (qmail 66590 invoked from network); 13 Nov 2006 22:10:42 -0000 Received: from unknown (HELO phobos.mars.bsd) (unknown) by unknown with SMTP; 13 Nov 2006 22:10:42 -0000 Message-Id: <1163455839.24155@phobos.mars.bsd> Date: Mon, 13 Nov 2006 19:10:39 -0300 From: "Alejandro Pulver" To: "FreeBSD gnats submit" X-Send-Pr-Version: gtk-send-pr 0.4.7 Cc: Subject: docs/105494: [PATCH] PH: rewrite WxWidgets entry X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 22:22:47 -0000 >Number: 105494 >Category: docs >Synopsis: [PATCH] PH: rewrite WxWidgets entry >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Mon Nov 13 22:20:06 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Alejandro Pulver >Release: FreeBSD 6.1-RELEASE-p1 i386 >Organization: >Environment: System: FreeBSD 6.1-RELEASE-p1 #3: Mon Jun 19 14:49:35 ART 2006 root@phobos.mars.bsd:/usr/obj/usr/src/sys/ATHLON-PHOBOS >Description: - Rewrite WxWidgets entry. >How-To-Repeat: >Fix: --- patch_wx.diff begins here --- Index: book.sgml =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/porters-handbook/book.sgml,v retrieving revision 1.765 diff -u -r1.765 book.sgml --- book.sgml 3 Nov 2006 21:04:09 -0000 1.765 +++ book.sgml 12 Nov 2006 14:12:29 -0000 @@ -6182,85 +6182,580 @@ - Using wxWidgets + Using <application>WxWidgets</application> - If your port uses wxWidgets - cross-platform toolkit, define USE_WX. - A specific version must be requested by setting - USE_WX=2.6. Ranges (2.4-2.6) - and partial ranges (-2.4, 2.6+) - are also possible. - - List of required wxWidgets components can be set as - WX_COMPS. Unless specified otherwise, port will - depend on wxWidgets library (wx). Available - components are: - - - Possible values for <makevar>WX_COMPS</makevar> - - - - - Value - - Means - - - - - - wx - - wxWidget libraries - - - - contrib - - wxWidget contributed libraries - - - - python - - wxPython - - - - mozilla - - wxMozilla (only available for 2.4) - - - - svg - - wxSVG (only available for 2.6) - - - -
- - If locating wxWidget libraries needs a configure argument in - addition to the WX_CONFIG variable, define - WX_CONF_ARGS in your port. Possible values - are absolute resulting in - --with-wx-config=${WX_CONFIG}, and - relative resulting in - --with-wx=${X11BASE} --with-wx-config=${WX_CONFIG} - being added to configure script arguments. - - Define WX_UNICODE=yes if your port needs - the Unicode version of the wxWidgets libraries. - - Example of port requiring Unicode versions of wxWidgets 2.6 and - contrib libraries: - - USE_WX= 2.6 -WX_COMPS= wx contrib -WX_UNICODE= yes + This section describes the status of the + WxWidgets libraries in the ports tree and + its integration with the ports system. + + + Introduction + + There are many versions of the + WxWidgets libraries which conflict + between them (install files under the same name). In the ports tree + this problem has been solved by installing each version under a + different name using version number suffixes. + + The obvious disadvantage of this is that each application has to + be modified to found the expected version. Fortunately most of the + applications call the wx-config script to + determine the necessary compiler and linker flags, which is named + differently for all the available versions, and the majority of them + also have a variable or accept a parameter to allow modifying + it. Otherwise the applications could be modified to use one of + them. + + + + Version selection + + To make your port use a specific version of + WxWidgets there are two variables + available for defining (if only one is defined the other will be set + to a default value): + + + Variables to select <application>WxWidgets</application> + versions + + + + + Variable + + Description + + Default value + + + + + + USE_WX + + List of versions the port can use + + All available versions + + + + USE_WX_NOT + + List of versions the port can not use + + None + + + +
+ + The following is a list of available + WxWidgets versions and the corresponding + port in the tree: + + + Available <application>WxWidgets</application> + versions + + + + + Version + + Port + + + + + + 2.4 + + x11-toolkits/wxgtk24 + + + + 2.6 + + x11-toolkits/wxgtk26 + + + +
+ + + The 2.6 version also comes in Unicode and + is installed by the slave port x11-toolkits/wxgtk26-unicode, but this + can be handled with variables (see ). + + + The variables in can be set + to one or more of the following combinations separated by + spaces: + + + <application>WxWidgets</application> version + specifications + + + + + Description + + Example + + + + + + Single version + + 2.4 + + + + Ascending range + + 2.4+ + + + + Descending range + + 2.6- + + + + Full range (must be ascending) + + 2.4-2.6 + + + +
+ + There are also some variables to select the preferred versions + from the available ones. They can be set to a list of versions, the + first ones will have higher priority. + + + Variables to select preferred + <application>WxWidgets</application> versions + + + + + Name + + Designed for + + + + + + WANT_WX_VER + + the port + + + + WITH_WX_VER + + the user + + + +
+ + + Component selection + + There are other applications that, while not being + WxWidgets libraries, are related to them. + These applications can be specified in the + WX_COMPS variable. The following components are + available: + + + Available <application>WxWidgets</application> + components + + + + + Name + + Description + + Version restriction + + + + + + wx + + main library + + none + + + + contrib + + contributed libraries + + none + + + + python + + WxPython + (Python bindings) + + none + + + + mozilla + + WxMozilla + + 2.4 + + + + svg + + WxSVG + + 2.6 + + + +
+ + The dependency type added when you select each component can be + manually specified by adding a suffix separated by a + :, or a default value will be used. The available + dependency types are: + + + Available <application>WxWidgets</application> dependency + types + + + + + Name + + Description + + + + + build + + Component is required for building, equivalent to + BUILD_DEPENDS + + + + run + + Component is required for running, equivalent to + RUN_DEPENDS + + + + lib + + Component is required for building and running, + equivalent to LIB_DEPENDS + + + +
+ + The default values for the components are detailed in the + following table: + + + Default <application>WxWidgets</application> dependency + types + + + + + Component + + Dependency type + + + + + + wx + + lib + + + + contrib + + lib + + + + python + + run + + + + mozilla + + lib + + + + svg + + lib + + + +
+ + + Selecting <application>WxWidgets</application> + components + + The following fragment corresponds to a port which uses + WxWidgets version + 2.4 and its contributed libraries. + + USE_WX= 2.4 +WX_COMPS= wx contrib + + + + Unicode + + The WxWidgets library supports + Unicode since version 2.5. In the ports tree both + versions are available and can be selected with the following + variables: + + + Variables to select Unicode in + <application>WxWidgets</application> + versions + + + + + Variable + + Description + + Designed for + + + + + + WX_UNICODE + + The port works only with the + Unicode version + + the port + + + + WANT_UNICODE + + The port works with both versions but prefers the + Unicode one + + the port + + + + WITH_UNICODE + + The port will use the Unicode version + + the user + + + + WITHOUT_UNICODE + + The port will use the normal version if + supported (when WX_UNICODE is not + defined) + + the user + + + +
+ + + Do not use WX_UNICODE for ports that can + use both Unicode and normal versions. If you want the port to use + Unicode by default define WANT_UNICODE + instead. + + + + + Detecting installed versions + + To detect an installed version you have to define + WANT_WX. If you do not set it to a specific + version then the components will have a version suffix. The + HAVE_WX variable will be filled after + detection. + + + Detecting installed <application>WxWidgets</application> + versions and components + + The following fragment can be used in a port that uses + WxWidgets if it is installed, or an + option is selected. + + WANT_WX= yes + +.include <bsd.port.pre.mk> + +.if defined(WITH_WX) || ${HAVE_WX:Mwx-2.4} != "" +USE_WX= 2.4 +CONFIGURE_ARGS+=--enable-wx +.endif + + The following fragment can be used in a port that enables + WxPython support if it is installed or + if an option is selected, in addition to + WxWidgets, both version + 2.6. + + USE_WX= 2.6 +WX_COMPS= wx +WANT_WX= 2.6 + +.include <bsd.port.pre.mk> + +.if defined(WITH_WXPYTHON) || ${HAVE_WX:Mpython} != "" +WX_COMPS+= python +CONFIGURE_ARGS+=--enable-wxpython +.endif + + + + + Defined variables + + The following variables are defined after defining one of the + variables from . + + + Variables defined for ports that use + <application>WxWidgets</application> + + + + + Name + + Description + + + + + + WX_CONFIG + + The path to the WxWidgets + wx-config script (with different + name) + + + WXRC_CMD + + The path to the WxWidgets + wxrc program (with differen name) + + + WX_VERSION + + The WxWidgets version that + is going to be used (e.g., 2.6) + + + + WX_UNICODE + + If not defined but Unicode is going to be used then it + will be defined + + + +
+ + + + Processing in <filename>bsd.port.pre.mk</filename> + + If you need to use the variables for running commands right + after including bsd.port.pre.mk you need to + define WX_PREMK. + + + If you define WX_PREMK, then the version, + dependencies, components and defined variables will not change if + you modify the Lua port variables + after including + bsd.port.pre.mk. + + + + Using <application>WxWidgets</application> variables in + commands + + The following fragment illustrates the use of + WX_PREMK by running the + Lua interpreter to obtain the full + version string, assign it to a variable and pass it to the + program. + + USE_WX= 2.4 +WX_PREMK= yes + +.include <bsd.port.pre.mk> + +.if exists(${WX_CONFIG}) +VER_STR!= ${WX_CONFIG} --release + +PLIST_SUB+= VERSION="${VER_STR}" +.endif + + + + The WxWidgets variables can be + safely used in commands when they are inside targets without the + need of WX_PREMK. + + --- patch_wx.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Mon Nov 13 22:35:37 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D31A16A685; Mon, 13 Nov 2006 22:35:37 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E080043DA7; Mon, 13 Nov 2006 22:31:40 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from freefall.freebsd.org (pav@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kADMVe8J059401; Mon, 13 Nov 2006 22:31:40 GMT (envelope-from pav@freefall.freebsd.org) Received: (from pav@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kADMVevE059397; Mon, 13 Nov 2006 22:31:40 GMT (envelope-from pav) Date: Mon, 13 Nov 2006 22:31:40 GMT From: Pav Lucistnik Message-Id: <200611132231.kADMVevE059397@freefall.freebsd.org> To: alepulver@FreeBSD.org, pav@FreeBSD.org, freebsd-doc@FreeBSD.org Cc: Subject: Re: docs/105441: [PATCH] PH: add new Lua variables X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 22:35:37 -0000 Synopsis: [PATCH] PH: add new Lua variables State-Changed-From-To: open->closed State-Changed-By: pav State-Changed-When: Mon Nov 13 22:30:31 UTC 2006 State-Changed-Why: Committed, thanks http://www.freebsd.org/cgi/query-pr.cgi?pr=105441 From owner-freebsd-doc@FreeBSD.ORG Mon Nov 13 22:42:02 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0C6B16A494 for ; Mon, 13 Nov 2006 22:42:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31BEF43DDB for ; Mon, 13 Nov 2006 22:40:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kADMe92w059745 for ; Mon, 13 Nov 2006 22:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kADMe9vr059744; Mon, 13 Nov 2006 22:40:09 GMT (envelope-from gnats) Date: Mon, 13 Nov 2006 22:40:09 GMT Message-Id: <200611132240.kADMe9vr059744@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: docs/105441: commit references a PR X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 22:42:02 -0000 The following reply was made to PR docs/105441; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: docs/105441: commit references a PR Date: Mon, 13 Nov 2006 22:36:00 +0000 (UTC) pav 2006-11-13 22:31:34 UTC FreeBSD doc repository Modified files: en_US.ISO8859-1/books/porters-handbook book.sgml Log: Using Lua: - Add LUA_CMD, LUAC_CMD and TOLUA_CMD variables. - Fix column titles in a table. - Change example to use the new variables. PR: docs/105441 Submitted by: alepulver Revision Changes Path 1.767 +24 -4 doc/en_US.ISO8859-1/books/porters-handbook/book.sgml _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-doc@FreeBSD.ORG Mon Nov 13 23:00:58 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9301016A4EA for ; Mon, 13 Nov 2006 23:00:58 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 984D643D90 for ; Mon, 13 Nov 2006 23:00:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kADN0Cxs061118 for ; Mon, 13 Nov 2006 23:00:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kADN0CH6061117; Mon, 13 Nov 2006 23:00:12 GMT (envelope-from gnats) Date: Mon, 13 Nov 2006 23:00:12 GMT Message-Id: <200611132300.kADN0CH6061117@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Pav Lucistnik Cc: Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pav Lucistnik List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 23:00:58 -0000 The following reply was made to PR docs/105494; it has been noted by GNATS. From: Pav Lucistnik To: Alejandro Pulver Cc: FreeBSD gnats submit Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry Date: Mon, 13 Nov 2006 23:52:28 +0100 > >Number: 105494 > >Synopsis: [PATCH] PH: rewrite WxWidgets entry Some comments on your patch: - please keep using wxWidgets, with small first w. That's how the project is called, check http://www.wxwidgets.org/ for proof - please be consistent with double space after full stop - > + be modified to found the expected version. Fortunately most of the - to find the expected version > + applications call the wx-config script to > + determine the necessary compiler and linker flags, which is named > + differently for all the available versions, and the majority of them > + also have a variable or accept a parameter to allow modifying > + it. Otherwise the applications could be modified to use one of - this overly long sentence is confusing! It could use a split into four standalone, clear ones. What about Fortunately, most of the applications call the wx-config script to determine the necessary compiler and linker flags. The script is named differently for every available version. Majority of applications respect an environment variable, or accept a configure argument, to specify which wx-config script to call. Otherwise they have to patched. > + The following is a list of available > + WxWidgets versions and the corresponding > + port in the tree: - corresponding ports > + The 2.6 version also comes in Unicode and - also comes in Unicode - version? variant? modification? > + WxPython - wxPython > + WxMozilla - wxMozilla > + WxSVG - wxSVG > + The dependency type added when you select each component can be > + manually specified by adding a suffix separated by a > + :, or a default value will be used. The available - this is confusing, please rephrase. The dependency type can be selected for each component by adding a suffix separated by a semicolon. > + The following variables are defined after defining one of the > + variables from . - overuse of defined. What about The following variables are available in the port: > + wxrc program (with differen name) - with different name > + you modify the Lua port variables - should this really read Lua? > + Lua interpreter to obtain the full - again, should this read Lua? Awaiting corrected patch. -- Pav Lucistnik Some programmers are able to write FORTRAN in any language. From owner-freebsd-doc@FreeBSD.ORG Tue Nov 14 18:10:15 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96D7116A403 for ; Tue, 14 Nov 2006 18:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D16043D75 for ; Tue, 14 Nov 2006 18:10:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAEIAAZk083151 for ; Tue, 14 Nov 2006 18:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAEIAA6l083147; Tue, 14 Nov 2006 18:10:10 GMT (envelope-from gnats) Date: Tue, 14 Nov 2006 18:10:10 GMT Message-Id: <200611141810.kAEIAA6l083147@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Alejandro Pulver Cc: Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alejandro Pulver List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 18:10:15 -0000 The following reply was made to PR docs/105494; it has been noted by GNATS. From: Alejandro Pulver To: pav@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry Date: Tue, 14 Nov 2006 15:00:56 -0300 On Mon, 13 Nov 2006 23:52:28 +0100 Pav Lucistnik wrote: > > >Number: 105494 > > >Synopsis: [PATCH] PH: rewrite WxWidgets entry > > Some comments on your patch: > [...] > Awaiting corrected patch. > Hello. I have incorporated your corrections in the following patch, if it is fine then I will send another one for Lua. Index: book.sgml =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/porters-handbook/book.sgml,v retrieving revision 1.767 diff -u -r1.767 book.sgml --- book.sgml 13 Nov 2006 22:31:33 -0000 1.767 +++ book.sgml 14 Nov 2006 17:59:46 -0000 @@ -6182,85 +6182,580 @@ - Using wxWidgets + Using <application>wxWidgets</application> - If your port uses wxWidgets - cross-platform toolkit, define USE_WX. - A specific version must be requested by setting - USE_WX=2.6. Ranges (2.4-2.6) - and partial ranges (-2.4, 2.6+) - are also possible. - - List of required wxWidgets components can be set as - WX_COMPS. Unless specified otherwise, port will - depend on wxWidgets library (wx). Available - components are: - - - Possible values for <makevar>WX_COMPS</makevar> - - - - - Value - - Means - - - - - - wx - - wxWidget libraries - - - - contrib - - wxWidget contributed libraries - - - - python - - wxPython - - - - mozilla - - wxMozilla (only available for 2.4) - - - - svg - - wxSVG (only available for 2.6) - - - -
- - If locating wxWidget libraries needs a configure argument in - addition to the WX_CONFIG variable, define - WX_CONF_ARGS in your port. Possible values - are absolute resulting in - --with-wx-config=${WX_CONFIG}, and - relative resulting in - --with-wx=${X11BASE} --with-wx-config=${WX_CONFIG} - being added to configure script arguments. - - Define WX_UNICODE=yes if your port needs - the Unicode version of the wxWidgets libraries. - - Example of port requiring Unicode versions of wxWidgets 2.6 and - contrib libraries: - - USE_WX= 2.6 -WX_COMPS= wx contrib -WX_UNICODE= yes + This section describes the status of the + wxWidgets libraries in the ports tree and + its integration with the ports system. + + + Introduction + + There are many versions of the + wxWidgets libraries which conflict + between them (install files under the same name). In the ports tree + this problem has been solved by installing each version under a + different name using version number suffixes. + + The obvious disadvantage of this is that each application has to + be modified to find the expected version. Fortunately, most of the + applications call the wx-config script to + determine the necessary compiler and linker flags. The script is + named differently for every available version. Majority of + applications respect an environment variable, or accept a configure + argument, to specify which wx-config script to + call. Otherwise they have to patched. + + + + Version selection + + To make your port use a specific version of + wxWidgets there are two variables + available for defining (if only one is defined the other will be set + to a default value): + + + Variables to select <application>wxWidgets</application> + versions + + + + + Variable + + Description + + Default value + + + + + + USE_WX + + List of versions the port can use + + All available versions + + + + USE_WX_NOT + + List of versions the port can not use + + None + + + +
+ + The following is a list of available + wxWidgets versions and the corresponding + ports in the tree: + + + Available <application>wxWidgets</application> + versions + + + + + Version + + Port + + + + + + 2.4 + + x11-toolkits/wxgtk24 + + + + 2.6 + + x11-toolkits/wxgtk26 + + + +
+ + + The 2.6 version also comes in Unicode and + is installed by the slave port x11-toolkits/wxgtk26-unicode, but this + can be handled with variables (see ). + + + The variables in can be set + to one or more of the following combinations separated by + spaces: + + + <application>wxWidgets</application> version + specifications + + + + + Description + + Example + + + + + + Single version + + 2.4 + + + + Ascending range + + 2.4+ + + + + Descending range + + 2.6- + + + + Full range (must be ascending) + + 2.4-2.6 + + + +
+ + There are also some variables to select the preferred versions + from the available ones. They can be set to a list of versions, the + first ones will have higher priority. + + + Variables to select preferred + <application>wxWidgets</application> versions + + + + + Name + + Designed for + + + + + + WANT_WX_VER + + the port + + + + WITH_WX_VER + + the user + + + +
+ + + Component selection + + There are other applications that, while not being + wxWidgets libraries, are related to them. + These applications can be specified in the + WX_COMPS variable. The following components are + available: + + + Available <application>wxWidgets</application> + components + + + + + Name + + Description + + Version restriction + + + + + + wx + + main library + + none + + + + contrib + + contributed libraries + + none + + + + python + + wxPython + (Python bindings) + + none + + + + mozilla + wxMozilla + + 2.4 + + + + svg + + wxSVG + + 2.6 + + + +
+ + The dependency type can be selected for each component by adding + a suffix separated by a semicolon. If not present then a default + type will be used (see ). The + following types are available: + + + Available <application>wxWidgets</application> dependency + types + + + + + Name + + Description + + + + + + build + + Component is required for building, equivalent to + BUILD_DEPENDS + + + + run + + Component is required for running, equivalent to + RUN_DEPENDS + + + + lib + + Component is required for building and running, + equivalent to LIB_DEPENDS + + + +
+ + The default values for the components are detailed in the + following table: + + + Default <application>wxWidgets</application> dependency + types + + + + + Component + + Dependency type + + + + + + wx + + lib + + + + contrib + + lib + + + + python + + run + + + + mozilla + + lib + + + + svg + + lib + + + +
+ + + Selecting <application>wxWidgets</application> + components + + The following fragment corresponds to a port which uses + wxWidgets version + 2.4 and its contributed libraries. + + USE_WX= 2.4 +WX_COMPS= wx contrib + + + + Unicode + + The wxWidgets library supports + Unicode since version 2.5. In the ports tree both + versions are available and can be selected with the following + variables: + + + Variables to select Unicode in + <application>wxWidgets</application> + versions + + + + + Variable + + Description + + Designed for + + + + + + WX_UNICODE + + The port works only with the + Unicode version + + the port + + + + WANT_UNICODE + + The port works with both versions but prefers the + Unicode one + + the port + + + + WITH_UNICODE + + The port will use the Unicode version + + the user + + + + WITHOUT_UNICODE + + The port will use the normal version if + supported (when WX_UNICODE is not + defined) + + the user + + + +
+ + + Do not use WX_UNICODE for ports that can + use both Unicode and normal versions. If you want the port to use + Unicode by default define WANT_UNICODE + instead. + + + + + Detecting installed versions + + To detect an installed version you have to define + WANT_WX. If you do not set it to a specific + version then the components will have a version suffix. The + HAVE_WX variable will be filled after + detection. + + + Detecting installed <application>wxWidgets</application> + versions and components + + The following fragment can be used in a port that uses + wxWidgets if it is installed, or an + option is selected. + + WANT_WX= yes + +.include <bsd.port.pre.mk> + +.if defined(WITH_WX) || ${HAVE_WX:Mwx-2.4} != "" +USE_WX= 2.4 +CONFIGURE_ARGS+=--enable-wx +.endif + + The following fragment can be used in a port that enables + wxPython support if it is installed or + if an option is selected, in addition to + wxWidgets, both version + 2.6. + + USE_WX= 2.6 +WX_COMPS= wx +WANT_WX= 2.6 + +.include <bsd.port.pre.mk> + +.if defined(WITH_WXPYTHON) || ${HAVE_WX:Mpython} != "" +WX_COMPS+= python +CONFIGURE_ARGS+=--enable-wxpython +.endif + + + + + Defined variables + + The following variables are available in the port (after + defining one from ). + + + Variables defined for ports that use + <application>wxWidgets</application> + + + + + Name + + Description + + + + + + WX_CONFIG + + The path to the wxWidgets + wx-config script (with different + name) + + + WXRC_CMD + + The path to the wxWidgets + wxrc program (with different + name) + + + WX_VERSION + + The wxWidgets version that + is going to be used (e.g., 2.6) + + + + WX_UNICODE + + If not defined but Unicode is going to be used then it + will be defined + + + +
+ + + + Processing in <filename>bsd.port.pre.mk</filename> + + If you need to use the variables for running commands right + after including bsd.port.pre.mk you need to + define WX_PREMK. + + + If you define WX_PREMK, then the version, + dependencies, components and defined variables will not change if + you modify the wxWidgets port variables + after including + bsd.port.pre.mk. + + + + Using <application>wxWidgets</application> variables in + commands + + The following fragment illustrates the use of + WX_PREMK by running the + wx-config script to obtain the full version + string, assign it to a variable and pass it to the program. + + USE_WX= 2.4 +WX_PREMK= yes + +.include <bsd.port.pre.mk> + +.if exists(${WX_CONFIG}) +VER_STR!= ${WX_CONFIG} --release + +PLIST_SUB+= VERSION="${VER_STR}" +.endif + + + + The wxWidgets variables can be + safely used in commands when they are inside targets without the + need of WX_PREMK. + + Best Regards, Ale From owner-freebsd-doc@FreeBSD.ORG Tue Nov 14 18:41:41 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C737316A407 for ; Tue, 14 Nov 2006 18:41:41 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62F7B43D45 for ; Tue, 14 Nov 2006 18:41:41 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 0B1A978C7E for ; Tue, 14 Nov 2006 18:41:12 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id E7F2C11420; Tue, 14 Nov 2006 19:41:39 +0100 (CET) Date: Tue, 14 Nov 2006 19:41:39 +0100 From: "Simon L. Nielsen" To: freebsd-doc@freebsd.org Message-ID: <20061114184139.GB1014@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Subject: [simon@FreeBSD.org: cvs commit: www/en/ports Makefile.inc] X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 18:41:41 -0000 Hey, Could the translation teams please merge this? I'm going to merge it in a couple of weeks for the translations that hasn't done it before then. ----- Forwarded message from "Simon L. Nielsen" ----- From: "Simon L. Nielsen" Date: Tue, 14 Nov 2006 18:20:42 +0000 (UTC) To: doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: www/en/ports Makefile.inc simon 2006-11-14 18:20:42 UTC FreeBSD doc repository Modified files: en/ports Makefile.inc Log: Do not install INDEX. On www.FreeBSD.org there is are Apache config settings which overrides /ports/INDEX, so the INDEX installed here isn't even used. On mirrors it's just wasted bandwith since the file isn't used by anything (and since for /usr/ports people will need INDEX-[567], for any recent FreeBSD, people can't even use this INDEX file for anything useful). Revision Changes Path 1.10 +2 -2 www/en/ports/Makefile.inc http://cvsweb.FreeBSD.org/www/en/ports/Makefile.inc.diff?r1=1.9&r2=1.10 | =================================================================== | RCS file: /usr/local/www/cvsroot/FreeBSD/www/en/ports/Makefile.inc,v | retrieving revision 1.9 | retrieving revision 1.10 | diff -u -p -r1.9 -r1.10 | --- www/en/ports/Makefile.inc 2005/12/15 01:02:28 1.9 | +++ www/en/ports/Makefile.inc 2006/11/14 18:20:41 1.10 | @@ -1,4 +1,4 @@ | -# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/www/en/ports/Makefile.inc,v 1.9 2005/12/15 01:02:28 linimon Exp $ | +# $FreeBSD: /usr/local/www/cvsroot/FreeBSD/www/en/ports/Makefile.inc,v 1.10 2006/11/14 18:20:41 simon Exp $ | | PORTINDEX= ${PERL} ${.CURDIR}/portindex | INDEX= INDEX | @@ -12,5 +12,5 @@ CLEANFILES+= ${DYNAMIC_DOCS} | CLEANFILES+= Makefile.gen | CLEANFILES+= ports.count ports.size | | -_ALLINSTALL= packages.exists ${INDEX} categories | +_ALLINSTALL= packages.exists categories | ----- End forwarded message ----- -- Simon L. Nielsen From owner-freebsd-doc@FreeBSD.ORG Tue Nov 14 19:20:59 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E29416A4EB for ; Tue, 14 Nov 2006 19:20:59 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11A2643DC2 for ; Tue, 14 Nov 2006 19:20:13 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAEJK4Xe089450 for ; Tue, 14 Nov 2006 19:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAEJK4o0089449; Tue, 14 Nov 2006 19:20:04 GMT (envelope-from gnats) Date: Tue, 14 Nov 2006 19:20:04 GMT Message-Id: <200611141920.kAEJK4o0089449@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Pav Lucistnik Cc: Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pav Lucistnik List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 19:20:59 -0000 The following reply was made to PR docs/105494; it has been noted by GNATS. From: Pav Lucistnik To: Alejandro Pulver Cc: bug-followup@FreeBSD.org Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry Date: Tue, 14 Nov 2006 20:10:47 +0100 > I have incorporated your corrections in the following patch, > + be modified to find the expected version. Fortunately, most of the Still missing double space after full stop. > + call. Otherwise they have to patched. "they have to be patched". Sorry, I wrote it badly in my previous mail. > + The 2.6 version also comes in Unicode and > + is installed by the slave port + a suffix separated by a semicolon. If not present then a default Double space missing here, and several places elsewhere. Please double check! Otherwise it looks promising so far. -- Pav Lucistnik > Why do we need a film of "Lord of the Rings" when we have the book? Because watching a cg enhanced Legolas fire a flaming arrow into the heart of a warg is cool? - asdf@asdf.com in rec.games.roguelike.angband From owner-freebsd-doc@FreeBSD.ORG Tue Nov 14 23:12:31 2006 Return-Path: X-Original-To: doc@freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 998F116A407; Tue, 14 Nov 2006 23:12:31 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from skapet.datadok.no (skapet.datadok.no [194.54.107.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 353C543D6B; Tue, 14 Nov 2006 23:12:29 +0000 (GMT) (envelope-from peter@bsdly.net) Received: from thingy.bsdly.net ([10.168.103.11] helo=thingy.datadok.no.bsdly.net ident=peter) by skapet.datadok.no with esmtp (Exim 4.60) (envelope-from ) id 1Gk7S9-0002Ao-0o; Wed, 15 Nov 2006 00:12:29 +0100 To: doc@freebsd.org From: peter@bsdly.net (Peter N. M. Hansteen) Date: Wed, 15 Nov 2006 00:12:24 +0100 Message-ID: <87irhh62sn.fsf@thingy.datadok.no> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: brd@freebsd.org Subject: A PF touch-up of the FreeBSD Handbook firewalls chapter X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 23:12:31 -0000 My first stab at putting some further useful info about PF into the FreeBSD Handbook's firewalls chapter is available in patch form (result of diff -u) at http://www.bsdly.net/~peter/freebsd/fw.diff Apply with 'cd /usr/doc/en_US.ISO8859-1/books/handbook/firewalls ; patch X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98CC416A47C for ; Wed, 15 Nov 2006 00:10:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF7943D8E for ; Wed, 15 Nov 2006 00:10:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAF0AFqx019291 for ; Wed, 15 Nov 2006 00:10:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAF0AFln019290; Wed, 15 Nov 2006 00:10:15 GMT (envelope-from gnats) Date: Wed, 15 Nov 2006 00:10:15 GMT Message-Id: <200611150010.kAF0AFln019290@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Alejandro Pulver Cc: Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alejandro Pulver List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 00:10:30 -0000 The following reply was made to PR docs/105494; it has been noted by GNATS. From: Alejandro Pulver To: pav@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry Date: Tue, 14 Nov 2006 21:06:20 -0300 O.K., here is a new one. Index: book.sgml =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/porters-handbook/book.sgml,v retrieving revision 1.767 diff -u -r1.767 book.sgml --- book.sgml 13 Nov 2006 22:31:33 -0000 1.767 +++ book.sgml 15 Nov 2006 00:05:12 -0000 @@ -6182,85 +6182,580 @@ - Using wxWidgets + Using <application>wxWidgets</application> - If your port uses wxWidgets - cross-platform toolkit, define USE_WX. - A specific version must be requested by setting - USE_WX=2.6. Ranges (2.4-2.6) - and partial ranges (-2.4, 2.6+) - are also possible. - - List of required wxWidgets components can be set as - WX_COMPS. Unless specified otherwise, port will - depend on wxWidgets library (wx). Available - components are: - - - Possible values for <makevar>WX_COMPS</makevar> - - - - - Value - - Means - - - - - - wx - - wxWidget libraries - - - - contrib - - wxWidget contributed libraries - - - - python - - wxPython - - - - mozilla - - wxMozilla (only available for 2.4) - - - - svg - - wxSVG (only available for 2.6) - - - -
- - If locating wxWidget libraries needs a configure argument in - addition to the WX_CONFIG variable, define - WX_CONF_ARGS in your port. Possible values - are absolute resulting in - --with-wx-config=${WX_CONFIG}, and - relative resulting in - --with-wx=${X11BASE} --with-wx-config=${WX_CONFIG} - being added to configure script arguments. - - Define WX_UNICODE=yes if your port needs - the Unicode version of the wxWidgets libraries. - - Example of port requiring Unicode versions of wxWidgets 2.6 and - contrib libraries: - - USE_WX= 2.6 -WX_COMPS= wx contrib -WX_UNICODE= yes + This section describes the status of the + wxWidgets libraries in the ports tree and + its integration with the ports system. + + + Introduction + + There are many versions of the + wxWidgets libraries which conflict + between them (install files under the same name). In the ports tree + this problem has been solved by installing each version under a + different name using version number suffixes. + + The obvious disadvantage of this is that each application has to + be modified to find the expected version. Fortunately, most of the + applications call the wx-config script to + determine the necessary compiler and linker flags. The script is + named differently for every available version. Majority of + applications respect an environment variable, or accept a configure + argument, to specify which wx-config script to + call. Otherwise they have to be patched. + + + + Version selection + + To make your port use a specific version of + wxWidgets there are two variables + available for defining (if only one is defined the other will be set + to a default value): + + + Variables to select <application>wxWidgets</application> + versions + + + + + Variable + + Description + + Default value + + + + + + USE_WX + + List of versions the port can use + + All available versions + + + + USE_WX_NOT + + List of versions the port can not use + + None + + + +
+ + The following is a list of available + wxWidgets versions and the corresponding + ports in the tree: + + + Available <application>wxWidgets</application> + versions + + + + + Version + + Port + + + + + + 2.4 + + x11-toolkits/wxgtk24 + + + + 2.6 + + x11-toolkits/wxgtk26 + + + +
+ + + The 2.6 version also comes in Unicode + version and is installed by the slave port x11-toolkits/wxgtk26-unicode, but this + can be handled with variables (see ). + + + The variables in can be set + to one or more of the following combinations separated by + spaces: + + + <application>wxWidgets</application> version + specifications + + + + Description + + Example + + + + + + Single version + + 2.4 + + + + Ascending range + + 2.4+ + + + + Descending range + + 2.6- + + + + Full range (must be ascending) + + 2.4-2.6 + + + +
+ + There are also some variables to select the preferred versions + from the available ones. They can be set to a list of versions, the + first ones will have higher priority. + + + Variables to select preferred + <application>wxWidgets</application> versions + + + + + Name + + Designed for + + + + + + WANT_WX_VER + + the port + + + + WITH_WX_VER + + the user + + + +
+ + + Component selection + + There are other applications that, while not being + wxWidgets libraries, are related to them. + These applications can be specified in the + WX_COMPS variable. The following components are + available: + + + Available <application>wxWidgets</application> + components + + + + + Name + + Description + + Version restriction + + + + + + wx + + main library + + none + + + + contrib + + contributed libraries + + none + + + + python + + wxPython + (Python bindings) + + none + + + + mozilla + + wxMozilla + + 2.4 + + + + svg + + wxSVG + + 2.6 + + + +
+ + The dependency type can be selected for each component by adding + a suffix separated by a semicolon. If not present then a default + type will be used (see ). The + following types are available: + + + Available <application>wxWidgets</application> dependency + types + + + + + Name + + Description + + + + + + build + + Component is required for building, equivalent to + BUILD_DEPENDS + + + + run + + Component is required for running, equivalent to + RUN_DEPENDS + + + + lib + + Component is required for building and running, + equivalent to LIB_DEPENDS + + + +
+ + The default values for the components are detailed in the + following table: + + + Default <application>wxWidgets</application> dependency + types + + + + + Component + + Dependency type + + + + + + wx + + lib + + + + contrib + + lib + + + + python + + run + + + + mozilla + + lib + + + + svg + + lib + + + +
+ + + Selecting <application>wxWidgets</application> + components + + The following fragment corresponds to a port which uses + wxWidgets version + 2.4 and its contributed libraries. + + USE_WX= 2.4 +WX_COMPS= wx contrib + + + + Unicode + + The wxWidgets library supports + Unicode since version 2.5. In the ports tree + both versions are available and can be selected with the following + variables: + + + Variables to select Unicode in + <application>wxWidgets</application> + versions + + + + + Variable + + Description + + Designed for + + + + + + WX_UNICODE + + The port works only with the + Unicode version + + the port + + + + WANT_UNICODE + + The port works with both versions but prefers the + Unicode one + + the port + + + + WITH_UNICODE + + The port will use the Unicode version + + the user + + + + WITHOUT_UNICODE + + The port will use the normal version if + supported (when WX_UNICODE is not + defined) + + the user + + + +
+ + + Do not use WX_UNICODE for ports that can + use both Unicode and normal versions. If you want the port to use + Unicode by default define WANT_UNICODE + instead. + + + + + Detecting installed versions + + To detect an installed version you have to define + WANT_WX. If you do not set it to a specific + version then the components will have a version suffix. The + HAVE_WX variable will be filled after + detection. + + + Detecting installed <application>wxWidgets</application> + versions and components + + The following fragment can be used in a port that uses + wxWidgets if it is installed, or an + option is selected. + + WANT_WX= yes + +.include <bsd.port.pre.mk> + +.if defined(WITH_WX) || ${HAVE_WX:Mwx-2.4} != "" +USE_WX= 2.4 +CONFIGURE_ARGS+=--enable-wx +.endif + + The following fragment can be used in a port that enables + wxPython support if it is installed or + if an option is selected, in addition to + wxWidgets, both version + 2.6. + + USE_WX= 2.6 +WX_COMPS= wx +WANT_WX= 2.6 + +.include <bsd.port.pre.mk> + +.if defined(WITH_WXPYTHON) || ${HAVE_WX:Mpython} != "" +WX_COMPS+= python +CONFIGURE_ARGS+=--enable-wxpython +.endif + + + + + Defined variables + + The following variables are available in the port (after + defining one from ). + + + Variables defined for ports that use + <application>wxWidgets</application> + + + + + Name + + Description + + + + + + WX_CONFIG + + The path to the wxWidgets + wx-config script (with different + name) + + + WXRC_CMD + + The path to the wxWidgets + wxrc program (with different + name) + + + WX_VERSION + + The wxWidgets version that + is going to be used (e.g., 2.6) + + + + WX_UNICODE + + If not defined but Unicode is going to be used then it + will be defined + + + +
+ + + + Processing in <filename>bsd.port.pre.mk</filename> + + If you need to use the variables for running commands right + after including bsd.port.pre.mk you need to + define WX_PREMK. + + + If you define WX_PREMK, then the version, + dependencies, components and defined variables will not change if + you modify the wxWidgets port variables + after including + bsd.port.pre.mk. + + + + Using <application>wxWidgets</application> variables in + commands + + The following fragment illustrates the use of + WX_PREMK by running the + wx-config script to obtain the full version + string, assign it to a variable and pass it to the program. + + USE_WX= 2.4 +WX_PREMK= yes + +.include <bsd.port.pre.mk> + +.if exists(${WX_CONFIG}) +VER_STR!= ${WX_CONFIG} --release + +PLIST_SUB+= VERSION="${VER_STR}" +.endif + + + + The wxWidgets variables can be + safely used in commands when they are inside targets without the + need of WX_PREMK. + + From owner-freebsd-doc@FreeBSD.ORG Wed Nov 15 00:20:32 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81DAE16A40F for ; Wed, 15 Nov 2006 00:20:32 +0000 (UTC) (envelope-from mailer@wolfram.com) Received: from mercury.wolfram.com (mercury.wolfram.com [140.177.205.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D81B43E61 for ; Wed, 15 Nov 2006 00:17:42 +0000 (GMT) (envelope-from mailer@wolfram.com) Received: from mercury.wolfram.com (localhost.localdomain [127.0.0.1]) by mercury.wolfram.com (8.12.11.20060308/8.12.11) with ESMTP id kAF0HT0n020576 for ; Tue, 14 Nov 2006 18:17:29 -0600 Received: (from mailer@localhost) by mercury.wolfram.com (8.12.11.20060308/8.12.11/Submit) id kAF0HTh4020575; Tue, 14 Nov 2006 18:17:29 -0600 Date: Tue, 14 Nov 2006 18:17:29 -0600 Message-Id: <200611150017.kAF0HTh4020575@mercury.wolfram.com> To: freebsd-doc@freebsd.org From: Wolfram Research Sender: Wolfram Research X-wrimid: [freebsd-doc@freebsd.org][1106_746492_workbench_not_downloaded] Subject: Wolfram Workbench now available X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 00:20:32 -0000 We are pleased to announce the release of Wolfram Workbench, the new state-of-the-art integrated development environment for Mathematica technologies. As an exclusive benefit of Wolfram Premier Service, we invite you to download Workbench for free and start using it today to manage your most sophisticated Mathematica development projects and rapidly deploy them on any scale. Access your free download now by visiting our website at: http://www.wolfram.com/premiersupport/workbench.cgi?License=45441891 Key features in Workbench enable users to: * Group files, code, and other Mathematica resources into a single project * Perform source code editing with syntax highlighting, error reporting, local variable coloring, and many more options * Study code as it runs and easily detect and fix any problems * Profile the code's execution and develop and run tests, with an array of insightful reporting methods * Manage multiple versions of files and access version histories * Build and deploy Mathematica packages For more information about Workbench, please go to: http://www.wolfram.com/workbench Sincerely, Customer Service Wolfram Research info@wolfram.com From owner-freebsd-doc@FreeBSD.ORG Wed Nov 15 09:10:11 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF7F016A403 for ; Wed, 15 Nov 2006 09:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21E5E43D5F for ; Wed, 15 Nov 2006 09:10:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAF9A9ib073380 for ; Wed, 15 Nov 2006 09:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAF9A9WD073379; Wed, 15 Nov 2006 09:10:09 GMT (envelope-from gnats) Resent-Date: Wed, 15 Nov 2006 09:10:09 GMT Resent-Message-Id: <200611150910.kAF9A9WD073379@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, nick@anywi.com Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08F7C16A415 for ; Wed, 15 Nov 2006 09:06:07 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from smtp-1.orange.nl (smtp-1.orange.nl [193.252.22.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 798F443D62 for ; Wed, 15 Nov 2006 09:06:06 +0000 (GMT) (envelope-from nick@van-laarhoven.org) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf6009.orange.nl (SMTP Server) with ESMTP id 674B3700008C for ; Wed, 15 Nov 2006 10:06:05 +0100 (CET) Received: from uitsmijter.van-laarhoven.org (ap-zvhz-13f05.adsl.wanadoo.nl [81.69.93.5]) by mwinf6009.orange.nl (SMTP Server) with ESMTP id 40A367000088 for ; Wed, 15 Nov 2006 10:06:05 +0100 (CET) Received: (qmail 56227 invoked from network); 15 Nov 2006 09:06:04 -0000 Received: from 194.109.247.152 by uitsmijter.van-laarhoven.org (envelope-from , uid 82) with qmail-scanner-1.25 (clamdscan: 0.88.4/2187. f-prot: 4.6.6/3.16.14. spamassassin: 3.1.7. Clear:RC:0(194.109.247.152):SA:0(-3.9/5.0):. Processed in 3.228182 secs); 15 Nov 2006 09:06:04 -0000 Received: from unknown (HELO van-laarhoven.org) (nick@194.109.247.152) by uitsmijter.van-laarhoven.org with SMTP; 15 Nov 2006 09:06:01 -0000 Received: (nullmailer pid 1491 invoked by uid 1001); Wed, 15 Nov 2006 07:26:04 -0000 Message-Id: <1163575564.371659.1490.nullmailer@van-laarhoven.org> Date: Wed, 15 Nov 2006 08:26:04 +0100 From: nick@anywi.com To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/105556: hosts.allow is available as a man-page X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 09:10:11 -0000 >Number: 105556 >Category: docs >Synopsis: hosts.allow is available as a man-page >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: Wed Nov 15 09:10:09 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Nick Hibma >Release: FreeBSD 6.1-STABLE i386 >Organization: AnyWi Technologies >Environment: System: FreeBSD hind.van-laarhoven.org 6.1-STABLE FreeBSD 6.1-STABLE #26: Fri Nov 3 15:25:29 CET 2006 root@hind.van-laarhoven.org:/usr/src/sys/i386/compile/HIND i386 >Description: man hosts.allow does not return a man-page, which is what you'd expect. man rc.conf or man libmap.conf works. >How-To-Repeat: >Fix: Add a link to the hosts_access(5) page from hosts.allow >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Wed Nov 15 09:30:30 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4676616A407 for ; Wed, 15 Nov 2006 09:30:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD7AF43D6E for ; Wed, 15 Nov 2006 09:30:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAF9U655075646 for ; Wed, 15 Nov 2006 09:30:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAF9U61t075645; Wed, 15 Nov 2006 09:30:06 GMT (envelope-from gnats) Date: Wed, 15 Nov 2006 09:30:06 GMT Message-Id: <200611150930.kAF9U61t075645@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Pav Lucistnik Cc: Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pav Lucistnik List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 09:30:30 -0000 The following reply was made to PR docs/105494; it has been noted by GNATS. From: Pav Lucistnik To: Alejandro Pulver Cc: bug-followup@FreeBSD.org Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry Date: Wed, 15 Nov 2006 10:20:24 +0100 > O.K., here is a new one. Looks good, please test build and commit. -- Pav Lucistnik What is the airspeed velocity of an unladen swallow? From owner-freebsd-doc@FreeBSD.ORG Wed Nov 15 11:29:51 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BFE616A415; Wed, 15 Nov 2006 11:29:51 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 272BC43D62; Wed, 15 Nov 2006 11:29:51 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from freefall.freebsd.org (trhodes@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAFBTp9e086145; Wed, 15 Nov 2006 11:29:51 GMT (envelope-from trhodes@freefall.freebsd.org) Received: (from trhodes@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAFBToRh086141; Wed, 15 Nov 2006 11:29:51 GMT (envelope-from trhodes) Date: Wed, 15 Nov 2006 11:29:51 GMT From: Tom Rhodes Message-Id: <200611151129.kAFBToRh086141@freefall.freebsd.org> To: trhodes@FreeBSD.org, freebsd-doc@FreeBSD.org, trhodes@FreeBSD.org Cc: Subject: Re: docs/104432: No mention of "let" shell builtin in manual pages. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 11:29:51 -0000 Synopsis: No mention of "let" shell builtin in manual pages. Responsible-Changed-From-To: freebsd-doc->trhodes Responsible-Changed-By: trhodes Responsible-Changed-When: Wed Nov 15 11:29:26 UTC 2006 Responsible-Changed-Why: Over to me, I'm investigating. http://www.freebsd.org/cgi/query-pr.cgi?pr=104432 From owner-freebsd-doc@FreeBSD.ORG Thu Nov 16 14:28:15 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F43916A412; Thu, 16 Nov 2006 14:28:15 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE15343D53; Thu, 16 Nov 2006 14:28:14 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from freefall.freebsd.org (keramida@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAGESEhP051297; Thu, 16 Nov 2006 14:28:14 GMT (envelope-from keramida@freefall.freebsd.org) Received: (from keramida@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAGESEJY051293; Thu, 16 Nov 2006 14:28:14 GMT (envelope-from keramida) Date: Thu, 16 Nov 2006 14:28:14 GMT From: Giorgos Keramidas Message-Id: <200611161428.kAGESEJY051293@freefall.freebsd.org> To: keramida@FreeBSD.org, freebsd-doc@FreeBSD.org, keramida@FreeBSD.org Cc: Subject: Re: docs/105456: [patch] overhaul of the security chapter (14) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 14:28:15 -0000 Synopsis: [patch] overhaul of the security chapter (14) Responsible-Changed-From-To: freebsd-doc->keramida Responsible-Changed-By: keramida Responsible-Changed-When: Thu Nov 16 14:26:28 UTC 2006 Responsible-Changed-Why: I'll take care of this. http://www.freebsd.org/cgi/query-pr.cgi?pr=105456 From owner-freebsd-doc@FreeBSD.ORG Thu Nov 16 16:20:43 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59EDE16A537 for ; Thu, 16 Nov 2006 16:20:43 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD76843D7C for ; Thu, 16 Nov 2006 16:20:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAGGK616062254 for ; Thu, 16 Nov 2006 16:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAGGK6Ag062208; Thu, 16 Nov 2006 16:20:06 GMT (envelope-from gnats) Resent-Date: Thu, 16 Nov 2006 16:20:06 GMT Resent-Message-Id: <200611161620.kAGGK6Ag062208@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Eugene Grosbein Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68CAD16A4C2; Thu, 16 Nov 2006 16:15:43 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9451D43D7D; Thu, 16 Nov 2006 16:15:39 +0000 (GMT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.13.8/8.13.8) with ESMTP id kAGGFZR5002489; Thu, 16 Nov 2006 23:15:35 +0700 (KRAT) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.13.8/8.13.8/Submit) id kAGGFZMG002488; Thu, 16 Nov 2006 23:15:35 +0700 (KRAT) (envelope-from eugen) Message-Id: <200611161615.kAGGFZMG002488@grosbein.pp.ru> Date: Thu, 16 Nov 2006 23:15:35 +0700 (KRAT) From: Eugene Grosbein To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: phk@FreeBSD.org Subject: docs/105608: fdc(4) debugging description staled X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 16:20:43 -0000 >Number: 105608 >Category: docs >Synopsis: fdc(4) debugging description staled >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 16 16:20:05 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release: FreeBSD 6.2-PRERELEASE i386 >Organization: Svyaz Service JSC >Environment: System: FreeBSD grosbein.pp.ru 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #23: Tue Nov 14 20:05:28 KRAT 2006 eu@grosbein.pp.ru:/mnt/home/obj/usr/local/src/sys/DADV i386 >Description: fdc(4) manual page, NOTES and fdcontrol(8) manual page describe kernel option FDC_DEBUG that was removed by phk 2 years ago with the exception of pc98 architecture. OTOH, the kernel tunnable debug.fdc.debugflags is not documented. By the way, I think it should be made loader tunnable also to deal with boot-time problems. >How-To-Repeat: Try to find FDC_DEBUG in modern FreeBSD/i386 >Fix: Just remove FDC_DEBUG from mentioned manuals and NOTES. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Thu Nov 16 20:23:07 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 647B316A4E9 for ; Thu, 16 Nov 2006 20:23:07 +0000 (UTC) (envelope-from august.grammas@cingular.com) Received: from cingular.com (extmail06.cingular.com [170.35.209.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC42943D8F for ; Thu, 16 Nov 2006 20:22:02 +0000 (GMT) (envelope-from august.grammas@cingular.com) Received: from ([10.152.130.28]) by extmail06.cingular.com with ESMTP id KP-TRPY2.111294005; Thu, 16 Nov 2006 15:21:29 -0500 Received: from WWDCEXCH01.US.Cingular.Net ([10.152.130.38]) by wd07xsmtp002.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 15:21:29 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 16 Nov 2006 15:21:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: network cards Thread-Index: AccJvMzTmBGSrM2IQIqFvaO3WY/6FQ== To: X-OriginalArrivalTime: 16 Nov 2006 20:21:29.0123 (UTC) FILETIME=[CC682F30:01C709BC] From: "Grammas, August" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: network cards X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 20:23:07 -0000 =20 I am at the FreeeBSD site,and I am unable to find a hardware requirements document, specifically, what network cards are supported by the kernel? =20 =20 August Grammas =20 If you pick up a starving dog and make him prosperous, he will not bite you; that is the principle difference bet- ween a dog and a man. =20 Sam Clemens =20 From owner-freebsd-doc@FreeBSD.ORG Thu Nov 16 20:46:02 2006 Return-Path: X-Original-To: doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6233916A417; Thu, 16 Nov 2006 20:46:02 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4529F43D72; Thu, 16 Nov 2006 20:45:53 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kAGKjpmQ050677; Thu, 16 Nov 2006 23:45:52 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kAGKjpW8050676; Thu, 16 Nov 2006 23:45:51 +0300 (MSK) (envelope-from yar) Date: Thu, 16 Nov 2006 23:45:51 +0300 From: Yar Tikhiy To: Andrew Pantyukhin Message-ID: <20061116204551.GB49602@comp.chem.msu.su> References: <20061015173531.GB31717@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: doc@FreeBSD.org Subject: Re: New article X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 20:46:02 -0000 On Sun, Oct 29, 2006 at 08:18:50PM +0300, Andrew Pantyukhin wrote: > On 10/15/06, Yar Tikhiy wrote: > >Hi folks, > > Great article, thanks! Thank you! > How about > -eval "${rcvar}=\${${rcvar}:-'NO'}" > +eval : \${${rcvar}='NO'} > (a little more concise/readable; does not override > explicit null value, which might not be valid, but > should probably be respected all the same) The former expression agrees better with the current style of rc.subr and rc.d; in particular, null and unset values are treated the same. -- Yar From owner-freebsd-doc@FreeBSD.ORG Thu Nov 16 20:55:19 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE6E816A53F for ; Thu, 16 Nov 2006 20:55:19 +0000 (UTC) (envelope-from remko@freebsd.org) Received: from caelis.elvandar.org (caelis.elvandar.org [217.148.169.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9952443D7F for ; Thu, 16 Nov 2006 20:55:15 +0000 (GMT) (envelope-from remko@freebsd.org) Received: from localhost (caelis.elvandar.org [217.148.169.59]) by caelis.elvandar.org (Postfix) with ESMTP id 6567692FE2D; Thu, 16 Nov 2006 21:55:14 +0100 (CET) Received: from caelis.elvandar.org ([217.148.169.59]) by localhost (caelis.elvandar.org [217.148.169.59]) (amavisd-new, port 10024) with ESMTP id 01012-09; Thu, 16 Nov 2006 21:55:14 +0100 (CET) Received: from [10.0.2.125] (evilcoder.xs4all.nl [195.64.94.120]) (Authenticated sender: remko@evilcoder.org) by caelis.elvandar.org (Postfix) with ESMTP id 112ED92FDE6; Thu, 16 Nov 2006 21:55:14 +0100 (CET) Message-ID: <455CD05F.5000800@FreeBSD.org> Date: Thu, 16 Nov 2006 21:55:59 +0100 From: Remko Lodder User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Grammas, August" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by the elvandar.org maildomain Cc: freebsd-doc@FreeBSD.org Subject: Re: network cards X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remko@FreeBSD.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 20:55:20 -0000 for example; visit http://www.freebsd.org/releases/6.1R/hardware-i386.html i hope this helped! -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ From owner-freebsd-doc@FreeBSD.ORG Thu Nov 16 20:59:15 2006 Return-Path: X-Original-To: doc@freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 348D616A500 for ; Thu, 16 Nov 2006 20:59:15 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F3F743D78 for ; Thu, 16 Nov 2006 20:59:07 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so507403uge for ; Thu, 16 Nov 2006 12:59:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=S9kdhmV2hwxgUTAQmi6tsghynPn9ZSYzAYPXxdNVGKbJJuLzVF1sevY2rTzK0efDHYpJLoVKUMOqg+VrkAfBIrAHRuq/b1mFJpgWxHp5XoJIKjeFVSCp8Wltt6zBBfaVsjqibcXxPWt2Fb7PSRpNu2uCnzVBFcIkpyiiUvqjJhQ= Received: by 10.78.201.10 with SMTP id y10mr1075070huf.1163710746529; Thu, 16 Nov 2006 12:59:06 -0800 (PST) Received: by 10.78.167.16 with HTTP; Thu, 16 Nov 2006 12:59:06 -0800 (PST) Message-ID: Date: Thu, 16 Nov 2006 23:59:06 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Yar Tikhiy" In-Reply-To: <20061116204551.GB49602@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061015173531.GB31717@comp.chem.msu.su> <20061116204551.GB49602@comp.chem.msu.su> X-Google-Sender-Auth: c6716aec56d250cd Cc: doc@freebsd.org Subject: Re: New article X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 20:59:15 -0000 On 11/16/06, Yar Tikhiy wrote: > On Sun, Oct 29, 2006 at 08:18:50PM +0300, Andrew Pantyukhin wrote: > > On 10/15/06, Yar Tikhiy wrote: > > >Hi folks, > > > > Great article, thanks! > > Thank you! > > > How about > > -eval "${rcvar}=\${${rcvar}:-'NO'}" > > +eval : \${${rcvar}='NO'} > > (a little more concise/readable; does not override > > explicit null value, which might not be valid, but > > should probably be respected all the same) > > The former expression agrees better with the current > style of rc.subr and rc.d; in particular, null and > unset values are treated the same. I understand that you personally may be authoritative enough to make such statements, but it's not a matter of style. If null values were overridden, quite a lot of things would break right away. Try to "grep -h ^: *" in prefix/etc/rc.d on a box with a lot of packages installed and you'll see that only one or two percent of null variables are overridden. Sorry if I misunderstand you completely. Thanks! From owner-freebsd-doc@FreeBSD.ORG Thu Nov 16 21:45:24 2006 Return-Path: X-Original-To: doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C205D16A417; Thu, 16 Nov 2006 21:45:24 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF48343D60; Thu, 16 Nov 2006 21:45:23 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kAGLjM91051744; Fri, 17 Nov 2006 00:45:22 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kAGLjLna051743; Fri, 17 Nov 2006 00:45:21 +0300 (MSK) (envelope-from yar) Date: Fri, 17 Nov 2006 00:45:21 +0300 From: Yar Tikhiy To: Andrew Pantyukhin Message-ID: <20061116214521.GD49602@comp.chem.msu.su> References: <20061015173531.GB31717@comp.chem.msu.su> <20061116204551.GB49602@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: doc@FreeBSD.org Subject: Re: New article X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 21:45:24 -0000 On Thu, Nov 16, 2006 at 11:59:06PM +0300, Andrew Pantyukhin wrote: > On 11/16/06, Yar Tikhiy wrote: > >On Sun, Oct 29, 2006 at 08:18:50PM +0300, Andrew Pantyukhin wrote: > >> On 10/15/06, Yar Tikhiy wrote: > >> >Hi folks, > >> > >> Great article, thanks! > > > >Thank you! > > > >> How about > >> -eval "${rcvar}=\${${rcvar}:-'NO'}" > >> +eval : \${${rcvar}='NO'} > >> (a little more concise/readable; does not override > >> explicit null value, which might not be valid, but > >> should probably be respected all the same) > > > >The former expression agrees better with the current > >style of rc.subr and rc.d; in particular, null and > >unset values are treated the same. > > I understand that you personally may be authoritative > enough to make such statements, but it's not a matter > of style. If null values were overridden, quite a lot > of things would break right away. Try to "grep -h ^: *" > in prefix/etc/rc.d on a box with a lot of packages > installed and you'll see that only one or two percent > of null variables are overridden. > > Sorry if I misunderstand you completely. Note that "grep ^: *" in /etc/rc.d finds nothing. Also note that _some_ rc.d variables can be sensitive to this issue. However, /etc/rc.subr doesn't tell unset state from null state for those variables that don't need to be sensitive. Would you mind moving this thread to freebsd-rc? It's off-topic here, on freebsd-doc. -- Yar From owner-freebsd-doc@FreeBSD.ORG Thu Nov 16 23:50:20 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F3A716A412 for ; Thu, 16 Nov 2006 23:50:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50CAF43D88 for ; Thu, 16 Nov 2006 23:50:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAGNo5xp005758 for ; Thu, 16 Nov 2006 23:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAGNo5H7005757; Thu, 16 Nov 2006 23:50:05 GMT (envelope-from gnats) Date: Thu, 16 Nov 2006 23:50:05 GMT Message-Id: <200611162350.kAGNo5H7005757@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Alejandro Pulver Cc: Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alejandro Pulver List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 23:50:20 -0000 The following reply was made to PR docs/105494; it has been noted by GNATS. From: Alejandro Pulver To: pav@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: docs/105494: [PATCH] PH: rewrite WxWidgets entry Date: Thu, 16 Nov 2006 20:46:44 -0300 --Sig_LljVVEGmSy1U3BBI/ATjcuL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 15 Nov 2006 10:20:24 +0100 Pav Lucistnik wrote: > > O.K., here is a new one. >=20 > Looks good, please test build and commit. >=20 Done. Best Regards, Ale --Sig_LljVVEGmSy1U3BBI/ATjcuL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXPhqiV05EpRcP2ERAnrKAKC4f2oaLwBMk1PB0hXnrYgft/UoBACfZJSq HCUoJP0xwVyklbhKAGIMqXE= =G64T -----END PGP SIGNATURE----- --Sig_LljVVEGmSy1U3BBI/ATjcuL-- From owner-freebsd-doc@FreeBSD.ORG Fri Nov 17 03:31:07 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C79B16A412 for ; Fri, 17 Nov 2006 03:31:07 +0000 (UTC) (envelope-from kurin@delete.org) Received: from cobalt.delete.org (cobalt.delete.org [198.177.254.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87A1643D49 for ; Fri, 17 Nov 2006 03:31:06 +0000 (GMT) (envelope-from kurin@delete.org) Received: from localhost (localhost.delete.org [127.0.0.1]) by cobalt.delete.org (Postfix) with ESMTP id 839B484427 for ; Thu, 16 Nov 2006 22:30:55 -0500 (EST) X-Virus-Scanned: amavisd-new at delete.org Received: from cobalt.delete.org ([127.0.0.1]) by localhost (cobalt.delete.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDlqkVC-vxEP for ; Thu, 16 Nov 2006 22:30:38 -0500 (EST) Received: by cobalt.delete.org (Postfix, from userid 1028) id 2425B84424; Thu, 16 Nov 2006 22:30:38 -0500 (EST) Date: Thu, 16 Nov 2006 22:30:38 -0500 From: Toby Burress To: freebsd-doc@freebsd.org Message-ID: <20061117033038.GU93285@cobalt.delete.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: LDAP authentication - new article X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 03:31:07 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I was wondering if I could get someone to check/commit an article I wrote about getting FreeBSD to authenticate against an LDAP directory. It's complete and correct, to my knowledge, though some of my sgml tags may or may not be appropriate. --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="article.sgml" %articles.ent; ]>
LDAP Authentication Toby Burress
kurin@causa-sui.net
 $FreeBSD$ 2006 The FreeBSD Documentation Project &tm-attrib.freebsd; &tm-attrib.general; This document is indended to be a guide to using an LDAP server (principally an OpenLDAP server) for authentication on &os;. This is useful for situations where many servers need the same accounts, e.g. as a replacement for NIS. ldap Preface This document is intended to give the reader enough of an understanding of LDAP to configure an LDAP server, as well as an understanding of net/nss_ldap and security/pam_ldap so that they can be configured to use an LDAP server. When finished, the reader should be able to configure and deploy a &os; server that will authenticate against an LDAP directory. This article is not intended to be an exhaustive account of the security, robustness, or best practices for configuring LDAP the other related services discussed. While the author takes care not to do anything dumb, neither does he go out of his way to address security issues. This article should be considered as laying the theoretical groundwork only, and any actual implementation should be accompanied by active thought. For this article, we will have two servers, server.freebsd.org and client.freebsd.org. The LDAP base will be dc=freebsd,dc=org. Configuring LDAP LDAP stands for Lightweight Directory Access Protocol and is a subset of the X.500 DAP protocol. It is most newly codified in RFC4510 and friends. Basically it is a database that expects to be read from more often than it is written to. The LDAP server OpenLDAP will the be used in the examples in this document, however the principles here should be generally applicable among many different servers. There are (basically) two areas of the LDAP service which need configuration; the first is setting up the server to receive connections properly, and the second is adding entries to the directory that the &os; tools know how to work with. Setting Up the Server for Connections This section is specific to OpenLDAP. If you are using another server, you will need to consult that server's documentation. You will probably want to use some kind of encryption in your connections to the LDAP server; otherwise your users' passwords will be floating over the ether in what amounts to plain text. The tools we will be using support two very similar kinds of encryption, SSL and TLS. TLS stands for Transportation Layer Security. Services that employ TLS tend to connect on the same ports as those same services without TLS; thus an SMTP server which supports TLS will listen for connections on port 25, and an LDAP server will listen on 389. SSL stands for Secure Sockets Layer, and services that implement SSL do not listen on the same ports as their non-SSL counterparts. Thus SMTPS listens on port 465 (not 45), HTTPS listens on 443, and LDAPS is 636. The reason SSL uses a different port than TLS is because a TLS connection begins as plain text, and switches to encrypted traffic after the STARTTLS directive. SSL connections are encrypted from the start. Other than that there is no difference between the two. We will be configuring OpenLDAP to use SSL; this is indicated solely by the use of the -h "ldaps://" directive when starting the server. Omitted, OpenLDAP would listen for TLS connections on 389. Once OpenLDAP is installed, the following configuration parameters in slapd.conf will enable SSL: security ssf=128 TLSCertificateFile /path/to/your/cert.crt TLSCertificateKeyFile /path/to/your/cert.key TLSCACertificateFile /path/to/your/cacert.crt Here, ssf=128 tells OpenLDAP to require 128-bit encryption for all connections (search + update). This parameter can be configured more exactly to your taste. The cert.crt, cert.key, and cacert.crt are necessary for clients to authenticate you as the valid LDAP server. If you simply want a server that runs, you can create a self-signed certificate with OpenSSL: &prompt.user; openssl genrsa -out cert.key 1024 Generating RSA private key, 1024 bit long modulus ....................++++++ ...++++++ e is 65537 (0x10001) &prompt.user; openssl req -new -key cert.key -out cert.csr At this point you should be prompted for some values. You can enter whatever you like, but it is important that the Common Name value be the fully qualified domain name of the server OpenLDAP will be running on, in our case server.freebsd.org. Otherwise your clients will refuse to connect. Finally, the certificate signing request needs to be signed: &prompt.user; openssl x509 -req -in cert.csr -days 365 -signkey cert.key -out cert.crt Signature ok subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd Getting Private key This will create a self-signed certificate that can be used for the directives in slapd.conf, with cert.crt and cacert.crt being the same file. If you are going to use many OpenLDAP servers (for replication via slurpd) you will want to see to generate a CA key, and use it to sign independent certificates. Once this is done, put the following values in /etc/rc.conf: slapd_flags="-h 'ldaps://'" slapd_enable="YES" and run /usr/local/etc/rc.d/slapd start. This should start OpenLDAP. Confirm that it is listening on 636 with &prompt.user; sockstat -4 -p 636 ldap slapd 3261 7 tcp4 *:636 *:* Finally, the client machines need to be configured to talk to the LDAP server. The client machines will always have OpenLDAP libraries, since that is all security/pam_ldap and net/nss_ldap support, at least for the moment. The configuration file for the OpenLDAP libraries is /usr/local/etc/openldap/ldap.conf. Edit this file to contain the following values: base dc=freebsd,dc=org uri ldaps://server.freebsd.org/ ssl on tls_cacert /path/to/your/cacert.crt It is important that your clients have access to cacert.crt, otherwise they will not be able to connect. At this point you should be able to run ldapsearch on the client machine. If you encounter an error, then something is configured wrong; most likely it is your certificates. Use openssl s_client and openssl s_server to ensure you have them configured and signed properly. Entries in the Database Authentication against an LDAP directory is generally accomplished by trying to bind to the directory as the user in question. This is accomplished by establishing a simple bind on the directory with the dn of the username and the password in that user's userPassword attribute. Thus the first thing we have to do is figure out is where in the directory our users will live. The base entry for our database is dc=freebsd,dc=org. The default location for users that most clients seem to expect is ou=people,base, so that is what will be used here, however keep in mind that this is configurable (actually, it doesn't truly matter at all). So the ldif entry for the people organizational unit will look like: dn: ou=people,dc=freebsd,dc=org objectClass: top objectClass: organizationalUnit ou: people All users will be created as subentries of this organizational unit. Some thought might be given to the object class your users will belong to. Most tools by default will use people, which is fine if you simply want to provide entries to authenticate against. However, if you are going to store user information in the LDAP database as well, you will probably want to use inetOrgPerson. In either case, the relevant schemas need to be loaded in slapd.conf. For this example we will use the person object class. If you are using inetOrgPerson, the steps are basically identical, except that the sn attribute is required. To add a user testuser, the ldif would be: dn: uid=tuser,ou=people,dc=freebsd,dc=org objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: top uidNumber: 10000 gidNumber: 10000 homeDirectory: /home/tuser loginShell: /bin/csh uid: tuser cn: tuser I start my LDAP users' UIDs at 10000; you can configure whatever number you wish here, as long as it's less than 65536. We also need group entries. They are as configurable as user entries, but we will use the defaults below: dn: ou=groups,dc=freebsd,dc=org objectClass: top objectClass: organizationalUnit ou: groups dn: cn=tuser,ou=groups,dc=freebsd,dc=org objectClass: posixGroup objectClass: top gidNumber: 10000 cn: tuser To enter these into your database, you can use slapadd or ldapadd on a file containing these entries. Alternatively, you can use sysutils/ldapvi. An ldapsearch on the client machine should now return these entries. If it does, your database is properly configured to be used as an LDAP authentication server. Client Configuration &os; requires two services to be installed to authenticate against an LDAP server correctly, security/pam_ldap and net/nss_ldap. Once these are installed the server will be ready. Authentication security/pam_ldap is configured via /usr/local/etc/ldap.conf. Note that this is a different file than the OpenLDAP library functions' configuration file, /usr/local/etc/openldap/ldap.conf, however it takes many of the same options; in fact it is a superset of that file. For the rest of this section, references to ldap.conf will mean /usr/local/etc/ldap.conf. Thus, first we will want to copy all of our original configuration parameters from openldap/ldap.conf to the new ldap.conf. Once this is done, we want to tell security/pam_ldap what to look for on the directory server. We are identifying our users with the uid attribute. To configure this (though it is the default), set the pam_ldap_attribute directive in ldap.conf. With this set, pam_ldap will search the entire LDAP directory under base for the value uid=username. If it finds one and only one entry, and binds to it correctly, then it will allow access. Otherwise it will fail. PAM PAM, which stands for pluggable authentication modules, is the method by which &os; authenticates most of its sessions. To tell &os; we wish to use an LDAP server, we will have to add the appropriate line to the appropriate PAM file. Most of the time the appropriate PAM file is /etc/pam.d/sshd, if you want to use SSH (remember to set the appropriate options in /etc/ssh/sshd_config, otherwise SSH will not use PAM). To use PAM for authentication, add the line auth sufficient /usr/local/lib/pam_ldap.so no_warn Exactly where this line shows up in the file and which options appear in the fourth column determine the exact behavior of the authentication mechanism; see &man.pam.d.5; With this configuration you should be able to authenticate a user against an LDAP directory, however it is usually not ideal to allow every user in the directory into every client machine. Fortunately there are a few ways to restrict user access. ldap.conf supports a pam_groupdn directive; every account that connects to this machine needs to be a member of the group specified here. So, for example, if you have pam_groupdn cn=production,ou=accessgroups,dc=freebsd,dc=org in ldap.conf, then only members of that group will be able to log in. There are a few things to bear in mind, however. Members of this group are specified in one or more memberUid attributes, and each attribute must have the full distinguished name of the member. So memberUid: someuser will not work; it must be memberUid: uid=someuser,ou=people,dc=freebsd,dc=org. Additionally, this directive is not checked in PAM during authentication, it is checked during account management, so you will need a second line in your PAM files under account. This will require, in turn, cause every user to be in the group listed. You may want to take advantage of the ignore_authinfo_unavail option so that you are not locked out of every computer when the LDAP server is unavailable. Name Service Switch The net/nss_ldap port uses the same configuration file as security/pam_ldap, and should not need any extra parameters once it is installed. Instead, what is left is simply to edit /etc/nsswitch.conf to take advantage of the directory. Simply replace the following lines: group: compat passwd: compat with group: files ldap passwd: files ldap This will allow you to map usernames to UIDs and UIDs to usernames. Congratulations! You should now have working LDAP authentication. Useful Aids There are a few other programs that might be useful, particularly if you have many users and do not want to configure everything manually. security/pam_mkhomedir is a PAM module that always succeeds; its purpose is to create home directories for users which do not have them. If you have dozens of client servers and hundreds of users, it is much easier to use this and set up skeleton directories than to prepare every home directory. sysutils/cpu is a &man.pw.8;-like utility that can be used to manage users in the LDAP directory. You can call it directly, or wrap scripts around it. It can handle both TLS (with the -x flag) and SSL (directly). OpenSSL Certificates For LDAP If you are hosting two or more LDAP servers, you will probably not want to use self-signed certificates, since each client will have to be configured to work with each certificate. While this is possible, it is not nearly as simple as creating your own certificate authority, and signing your servers' certificates with that. The steps here are presented as they are with very little attempt at explaining what is going on—further explanation can be found in &man.openssl.1; and its friends. To create a certificate authority, we simply need a self-signed certificate and key. The steps for this again are &prompt.user; openssl genrsa -out root.key 1024 &prompt.user; openssl req -new -key root.key -out root.csr &prompt.user; openssl x509 -req -days 1024 -in root.csr -signkey root.key -out root.crt These will be your root CA key and certificate. You will probably want to encrypt the key and store it in a cool, dry place; anyone with access to it can masquerade as one of your LDAP servers. Next, using the first two steps above create a key ldap-server-one.key and certificate signing request ldap-server-one.csr. Once you sign the signing request with root.key, you will be able to use ldap-server-one.* on your LDAP servers. Do not forget to use the fully qualified domain name for the common name attribute when generating the certificate signing request; otherwise clients will reject a connection with you, and it can be very tricky to diagnose. To sign the key, use -CA and -CAkey instead of -signkey: &prompt.user; openssl x509 -req -days 1024 \ -in ldap-server-one.csr -CA root.crt -CAkey root.key \ -out ldap-server-one.crt The resulting file will be the certificate that you can use on your LDAP servers. Finally, for clients to trust all your servers, distribute root.crt (the certificate, not the key!) to each client, and specify it in the TLSCACertificateFile directive in ldap.conf.
--nFreZHaLTZJo0R7j-- From owner-freebsd-doc@FreeBSD.ORG Fri Nov 17 03:35:49 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC6D716A586 for ; Fri, 17 Nov 2006 03:35:49 +0000 (UTC) (envelope-from kurin@delete.org) Received: from cobalt.delete.org (cobalt.delete.org [198.177.254.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02E9C43D55 for ; Fri, 17 Nov 2006 03:35:48 +0000 (GMT) (envelope-from kurin@delete.org) Received: from localhost (localhost.delete.org [127.0.0.1]) by cobalt.delete.org (Postfix) with ESMTP id DBD0084427 for ; Thu, 16 Nov 2006 22:35:38 -0500 (EST) X-Virus-Scanned: amavisd-new at delete.org Received: from cobalt.delete.org ([127.0.0.1]) by localhost (cobalt.delete.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA8KS4Qqrlu6 for ; Thu, 16 Nov 2006 22:35:27 -0500 (EST) Received: by cobalt.delete.org (Postfix, from userid 1028) id 31CCE84424; Thu, 16 Nov 2006 22:35:27 -0500 (EST) Date: Thu, 16 Nov 2006 22:35:27 -0500 From: Toby Burress To: freebsd-doc@freebsd.org Message-ID: <20061117033527.GV93285@cobalt.delete.org> References: <20061117033038.GU93285@cobalt.delete.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061117033038.GU93285@cobalt.delete.org> User-Agent: Mutt/1.4.2.2i Subject: Re: LDAP authentication - new article X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 03:35:49 -0000 On Thu, Nov 16, 2006 at 10:30:38PM -0500, Toby Burress wrote: > I was wondering if I could get someone to check/commit an article > I wrote about getting FreeBSD to authenticate against an LDAP > directory. It's complete and correct, to my knowledge, though some > of my sgml tags may or may not be appropriate. Oops - It's not complete, I just remembered a (small) section, and I also realized this should probably be a PR. From owner-freebsd-doc@FreeBSD.ORG Fri Nov 17 04:00:04 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07AF016A47B for ; Fri, 17 Nov 2006 04:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73D4A43D49 for ; Fri, 17 Nov 2006 04:00:03 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAH403W1027185 for ; Fri, 17 Nov 2006 04:00:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAH4039r027179; Fri, 17 Nov 2006 04:00:03 GMT (envelope-from gnats) Resent-Date: Fri, 17 Nov 2006 04:00:03 GMT Resent-Message-Id: <200611170400.kAH4039r027179@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Toby Burress Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50BEF16A412 for ; Fri, 17 Nov 2006 03:55:04 +0000 (UTC) (envelope-from kurin@delete.org) Received: from cobalt.delete.org (cobalt.delete.org [198.177.254.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2F0643D55 for ; Fri, 17 Nov 2006 03:55:03 +0000 (GMT) (envelope-from kurin@delete.org) Received: from localhost (localhost.delete.org [127.0.0.1]) by cobalt.delete.org (Postfix) with ESMTP id 0DB1584427 for ; Thu, 16 Nov 2006 22:54:53 -0500 (EST) Received: from cobalt.delete.org ([127.0.0.1]) by localhost (cobalt.delete.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bV9C4hj1HfzF for ; Thu, 16 Nov 2006 22:54:36 -0500 (EST) Received: by cobalt.delete.org (Postfix, from userid 1028) id 5A58684424; Thu, 16 Nov 2006 22:54:36 -0500 (EST) Message-Id: <20061117035436.5A58684424@cobalt.delete.org> Date: Thu, 16 Nov 2006 22:54:36 -0500 (EST) From: Toby Burress To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/105620: [article] LDAP Authentication X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Toby Burress List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 04:00:04 -0000 >Number: 105620 >Category: docs >Synopsis: [article] LDAP Authentication >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Fri Nov 17 04:00:02 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Toby Burress >Release: FreeBSD 5.4-STABLE i386 >Organization: >Environment: >Description: Documentation article for authentication against an LDAP directory. >How-To-Repeat: >Fix: I named it 'ldap-auth' but I dunno whatever's good. %articles.ent; ]>
LDAP Authentication Toby Burress
kurin@causa-sui.net
 $FreeBSD$ 2006 The FreeBSD Documentation Project &tm-attrib.freebsd; &tm-attrib.general; This document is indended to be a guide to using an LDAP server (principally an OpenLDAP server) for authentication on &os;. This is useful for situations where many servers need the same accounts, e.g. as a replacement for NIS. ldap Preface This document is intended to give the reader enough of an understanding of LDAP to configure an LDAP server, as well as an understanding of net/nss_ldap and security/pam_ldap so that they can be configured to use an LDAP server. When finished, the reader should be able to configure and deploy a &os; server that will authenticate against an LDAP directory. This article is not intended to be an exhaustive account of the security, robustness, or best practices for configuring LDAP the other related services discussed. While the author takes care not to do anything dumb, neither does he go out of his way to address security issues. This article should be considered as laying the theoretical groundwork only, and any actual implementation should be accompanied by active thought. For this article, we will have two servers, server.freebsd.org and client.freebsd.org. The LDAP base will be dc=freebsd,dc=org. Configuring LDAP LDAP stands for Lightweight Directory Access Protocol and is a subset of the X.500 DAP protocol. It is most newly codified in RFC4510 and friends. Basically it is a database that expects to be read from more often than it is written to. The LDAP server OpenLDAP will the be used in the examples in this document; while the principles here should be generally applicable among many different servers, most of the concrete administration is OpenLDAP-specific. There are (basically) two areas of the LDAP service which need configuration; the first is setting up the server to receive connections properly, and the second is adding entries to the directory that the &os; tools know how to work with. Setting Up the Server for Connections This section is specific to OpenLDAP. If you are using another server, you will need to consult that server's documentation. You will probably want to use some kind of encryption in your connections to the LDAP server; otherwise your users' passwords will be floating over the ether in what amounts to plain text. The tools we will be using support two very similar kinds of encryption, SSL and TLS. TLS stands for Transportation Layer Security. Services that employ TLS tend to connect on the same ports as those same services without TLS; thus an SMTP server which supports TLS will listen for connections on port 25, and an LDAP server will listen on 389. SSL stands for Secure Sockets Layer, and services that implement SSL do not listen on the same ports as their non-SSL counterparts. Thus SMTPS listens on port 465 (not 45), HTTPS listens on 443, and LDAPS is 636. The reason SSL uses a different port than TLS is because a TLS connection begins as plain text, and switches to encrypted traffic after the STARTTLS directive. SSL connections are encrypted from the start. Other than that there is no difference between the two. We will be configuring OpenLDAP to use SSL; this is indicated solely by the use of the -h "ldaps://" directive when starting the server. Omitted, OpenLDAP would listen for TLS connections on 389. Once OpenLDAP is installed, the following configuration parameters in slapd.conf will enable SSL: security ssf=128 TLSCertificateFile /path/to/your/cert.crt TLSCertificateKeyFile /path/to/your/cert.key TLSCACertificateFile /path/to/your/cacert.crt Here, ssf=128 tells OpenLDAP to require 128-bit encryption for all connections (search + update). This parameter can be configured more exactly to your taste. The cert.crt, cert.key, and cacert.crt are necessary for clients to authenticate you as the valid LDAP server. If you simply want a server that runs, you can create a self-signed certificate with OpenSSL: &prompt.user; openssl genrsa -out cert.key 1024 Generating RSA private key, 1024 bit long modulus ....................++++++ ...++++++ e is 65537 (0x10001) &prompt.user; openssl req -new -key cert.key -out cert.csr At this point you should be prompted for some values. You can enter whatever you like, but it is important that the Common Name value be the fully qualified domain name of the server OpenLDAP will be running on, in our case server.freebsd.org. Otherwise your clients will refuse to connect. Finally, the certificate signing request needs to be signed: &prompt.user; openssl x509 -req -in cert.csr -days 365 -signkey cert.key -out cert.crt Signature ok subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd Getting Private key This will create a self-signed certificate that can be used for the directives in slapd.conf, with cert.crt and cacert.crt being the same file. If you are going to use many OpenLDAP servers (for replication via slurpd) you will want to see to generate a CA key, and use it to sign independent certificates. Once this is done, put the following values in /etc/rc.conf: slapd_flags="-h 'ldaps://'" slapd_enable="YES" and run /usr/local/etc/rc.d/slapd start. This should start OpenLDAP. Confirm that it is listening on 636 with &prompt.user; sockstat -4 -p 636 ldap slapd 3261 7 tcp4 *:636 *:* Finally, the client machines need to be configured to talk to the LDAP server. The client machines will always have OpenLDAP libraries, since that is all security/pam_ldap and net/nss_ldap support, at least for the moment. The configuration file for the OpenLDAP libraries is /usr/local/etc/openldap/ldap.conf. Edit this file to contain the following values: base dc=freebsd,dc=org uri ldaps://server.freebsd.org/ ssl on tls_cacert /path/to/your/cacert.crt It is important that your clients have access to cacert.crt, otherwise they will not be able to connect. At this point you should be able to run ldapsearch on the client machine. If you encounter an error, then something is configured wrong; most likely it is your certificates. Use openssl s_client and openssl s_server to ensure you have them configured and signed properly. Entries in the Database Authentication against an LDAP directory is generally accomplished by trying to bind to the directory as the user in question. This is accomplished by establishing a simple bind on the directory with the dn of the username and the password in that user's userPassword attribute. Thus the first thing we have to do is figure out is where in the directory our users will live. The base entry for our database is dc=freebsd,dc=org. The default location for users that most clients seem to expect is ou=people,base, so that is what will be used here, however keep in mind that this is configurable (actually, it doesn't truly matter at all). So the ldif entry for the people organizational unit will look like: dn: ou=people,dc=freebsd,dc=org objectClass: top objectClass: organizationalUnit ou: people All users will be created as subentries of this organizational unit. Some thought might be given to the object class your users will belong to. Most tools by default will use people, which is fine if you simply want to provide entries to authenticate against. However, if you are going to store user information in the LDAP database as well, you will probably want to use inetOrgPerson. In either case, the relevant schemas need to be loaded in slapd.conf. For this example we will use the person object class. If you are using inetOrgPerson, the steps are basically identical, except that the sn attribute is required. To add a user testuser, the ldif would be: dn: uid=tuser,ou=people,dc=freebsd,dc=org objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: top uidNumber: 10000 gidNumber: 10000 homeDirectory: /home/tuser loginShell: /bin/csh uid: tuser cn: tuser I start my LDAP users' UIDs at 10000; you can configure whatever number you wish here, as long as it's less than 65536. We also need group entries. They are as configurable as user entries, but we will use the defaults below: dn: ou=groups,dc=freebsd,dc=org objectClass: top objectClass: organizationalUnit ou: groups dn: cn=tuser,ou=groups,dc=freebsd,dc=org objectClass: posixGroup objectClass: top gidNumber: 10000 cn: tuser To enter these into your database, you can use slapadd or ldapadd on a file containing these entries. Alternatively, you can use sysutils/ldapvi. An ldapsearch on the client machine should now return these entries. If it does, your database is properly configured to be used as an LDAP authentication server. Client Configuration &os; requires two services to be installed to authenticate against an LDAP server correctly, security/pam_ldap and net/nss_ldap. Once these are installed the server will be ready. Authentication security/pam_ldap is configured via /usr/local/etc/ldap.conf. Note that this is a different file than the OpenLDAP library functions' configuration file, /usr/local/etc/openldap/ldap.conf, however it takes many of the same options; in fact it is a superset of that file. For the rest of this section, references to ldap.conf will mean /usr/local/etc/ldap.conf. Thus, first we will want to copy all of our original configuration parameters from openldap/ldap.conf to the new ldap.conf. Once this is done, we want to tell security/pam_ldap what to look for on the directory server. We are identifying our users with the uid attribute. To configure this (though it is the default), set the pam_ldap_attribute directive in ldap.conf. With this set, pam_ldap will search the entire LDAP directory under base for the value uid=username. If it finds one and only one entry, and binds to it correctly, then it will allow access. Otherwise it will fail. PAM PAM, which stands for pluggable authentication modules, is the method by which &os; authenticates most of its sessions. To tell &os; we wish to use an LDAP server, we will have to add the appropriate line to the appropriate PAM file. Most of the time the appropriate PAM file is /etc/pam.d/sshd, if you want to use SSH (remember to set the appropriate options in /etc/ssh/sshd_config, otherwise SSH will not use PAM). To use PAM for authentication, add the line auth sufficient /usr/local/lib/pam_ldap.so no_warn Exactly where this line shows up in the file and which options appear in the fourth column determine the exact behavior of the authentication mechanism; see &man.pam.d.5; With this configuration you should be able to authenticate a user against an LDAP directory, however it is usually not ideal to allow every user in the directory into every client machine. Fortunately there are a few ways to restrict user access. ldap.conf supports a pam_groupdn directive; every account that connects to this machine needs to be a member of the group specified here. So, for example, if you have pam_groupdn cn=production,ou=accessgroups,dc=freebsd,dc=org in ldap.conf, then only members of that group will be able to log in. There are a few things to bear in mind, however. Members of this group are specified in one or more memberUid attributes, and each attribute must have the full distinguished name of the member. So memberUid: someuser will not work; it must be memberUid: uid=someuser,ou=people,dc=freebsd,dc=org. Additionally, this directive is not checked in PAM during authentication, it is checked during account management, so you will need a second line in your PAM files under account. This will require, in turn, cause every user to be in the group listed. You may want to take advantage of the ignore_authinfo_unavail option so that you are not locked out of every computer when the LDAP server is unavailable. Name Service Switch The net/nss_ldap port uses the same configuration file as security/pam_ldap, and should not need any extra parameters once it is installed. Instead, what is left is simply to edit /etc/nsswitch.conf to take advantage of the directory. Simply replace the following lines: group: compat passwd: compat with group: files ldap passwd: files ldap This will allow you to map usernames to UIDs and UIDs to usernames. Congratulations! You should now have working LDAP authentication. Securing LDAP Accounts While it is not strictly necessary, in the sense that authentication will work without it, you will probably want to secure access to some user attributes in your LDAP server. In OpenLDAP, this is accomplished through ACLs in slapd.conf. To begin with, the userPassword attribute should not be world-readable. By default, anyone who can connect to the LDAP server can read this attribute. To disable this, put the following in slapd.conf: access to attrs=userPassword by self write by anonymous auth by * none access to * by self write by * read This will disallow reading of the userPassword attribute, while still allowing users to change their own passwords. There is still one important security hole to close, however. By default, users can change any attribute (except for those which the LDAP schemas themselves deny changes), such as uidNumber. To close this hole, modify the above to access to attrs=userPassword by self write by anonymous auth by * none access to attrs=homeDirectory,uidNumber,gidNumber by * read access to * by self write by * read This will stop users from being able to masquerade as other users. Useful Aids There are a few other programs that might be useful, particularly if you have many users and do not want to configure everything manually. security/pam_mkhomedir is a PAM module that always succeeds; its purpose is to create home directories for users which do not have them. If you have dozens of client servers and hundreds of users, it is much easier to use this and set up skeleton directories than to prepare every home directory. sysutils/cpu is a &man.pw.8;-like utility that can be used to manage users in the LDAP directory. You can call it directly, or wrap scripts around it. It can handle both TLS (with the -x flag) and SSL (directly). OpenSSL Certificates For LDAP If you are hosting two or more LDAP servers, you will probably not want to use self-signed certificates, since each client will have to be configured to work with each certificate. While this is possible, it is not nearly as simple as creating your own certificate authority, and signing your servers' certificates with that. The steps here are presented as they are with very little attempt at explaining what is going on—further explanation can be found in &man.openssl.1; and its friends. To create a certificate authority, we simply need a self-signed certificate and key. The steps for this again are &prompt.user; openssl genrsa -out root.key 1024 &prompt.user; openssl req -new -key root.key -out root.csr &prompt.user; openssl x509 -req -days 1024 -in root.csr -signkey root.key -out root.crt These will be your root CA key and certificate. You will probably want to encrypt the key and store it in a cool, dry place; anyone with access to it can masquerade as one of your LDAP servers. Next, using the first two steps above create a key ldap-server-one.key and certificate signing request ldap-server-one.csr. Once you sign the signing request with root.key, you will be able to use ldap-server-one.* on your LDAP servers. Do not forget to use the fully qualified domain name for the common name attribute when generating the certificate signing request; otherwise clients will reject a connection with you, and it can be very tricky to diagnose. To sign the key, use -CA and -CAkey instead of -signkey: &prompt.user; openssl x509 -req -days 1024 \ -in ldap-server-one.csr -CA root.crt -CAkey root.key \ -out ldap-server-one.crt The resulting file will be the certificate that you can use on your LDAP servers. Finally, for clients to trust all your servers, distribute root.crt (the certificate, not the key!) to each client, and specify it in the TLSCACertificateFile directive in ldap.conf.
>Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Fri Nov 17 04:40:02 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACF9916A416 for ; Fri, 17 Nov 2006 04:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07A2E43D5E for ; Fri, 17 Nov 2006 04:40:02 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAH4e1eM036718 for ; Fri, 17 Nov 2006 04:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAH4e1Yp036717; Fri, 17 Nov 2006 04:40:01 GMT (envelope-from gnats) Resent-Date: Fri, 17 Nov 2006 04:40:01 GMT Resent-Message-Id: <200611170440.kAH4e1Yp036717@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, John Polstra Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8E2016A415 for ; Fri, 17 Nov 2006 04:30:10 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E814643D6E for ; Fri, 17 Nov 2006 04:30:02 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.6/8.13.6) with ESMTP id kAH4U2rN058043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Nov 2006 20:30:02 -0800 (PST) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.13.6/8.13.6/Submit) id kAH4U23V025160; Thu, 16 Nov 2006 20:30:02 -0800 (PST) (envelope-from jdp) Message-Id: <200611170430.kAH4U23V025160@strings.polstra.com> Date: Thu, 16 Nov 2006 20:30:02 -0800 (PST) From: John Polstra To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/105621: Incorrect cvsup-master contact in dev-model document X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Polstra List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 04:40:02 -0000 >Number: 105621 >Category: docs >Synopsis: Incorrect cvsup-master contact in dev-model document >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Nov 17 04:40:01 GMT 2006 >Closed-Date: >Last-Modified: >Originator: John Polstra >Release: FreeBSD 4.11-STABLE i386 >Organization: Polstra & Co., Seattle, WA >Environment: System: FreeBSD strings.polstra.com 4.11-STABLE FreeBSD 4.11-STABLE #0: Mon Jul 17 10:58:25 PDT 2006 jdp@strings.polstra.com:/usr/obj/usr/src/sys/STRINGS i386 >Description: In doc/en_US.ISO8859-1/books/dev-model/book.sgml, the CVSup Mirror Site Coordinator hat is shown as currently held by me. That info is several years out-of date. The proper email address for this hat is . I have attached a patch to fix the document. >How-To-Repeat: >Fix: --- dev-model.patch begins here --- Index: book.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/dev-model/book.sgml,v retrieving revision 1.13 diff -p -u -r1.13 book.sgml --- book.sgml 11 Aug 2006 13:58:37 -0000 1.13 +++ book.sgml 17 Nov 2006 04:18:16 -0000 @@ -904,7 +904,7 @@ Hat currently held by: - John Polstra jdp@FreeBSD.org. + The CVSup-master team cvsup-master@FreeBSD.org. --- dev-model.patch ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Fri Nov 17 04:42:58 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7202016A412; Fri, 17 Nov 2006 04:42:58 +0000 (UTC) (envelope-from jkoshy@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC3B043D53; Fri, 17 Nov 2006 04:42:57 +0000 (GMT) (envelope-from jkoshy@FreeBSD.org) Received: from freefall.freebsd.org (jkoshy@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAH4gvjv037242; Fri, 17 Nov 2006 04:42:57 GMT (envelope-from jkoshy@freefall.freebsd.org) Received: (from jkoshy@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAH4gvR4037238; Fri, 17 Nov 2006 04:42:57 GMT (envelope-from jkoshy) Date: Fri, 17 Nov 2006 04:42:57 GMT From: Joseph Koshy Message-Id: <200611170442.kAH4gvR4037238@freefall.freebsd.org> To: jkoshy@FreeBSD.org, freebsd-doc@FreeBSD.org, jkoshy@FreeBSD.org Cc: Subject: Re: docs/105621: Incorrect cvsup-master contact in dev-model document X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 04:42:58 -0000 Synopsis: Incorrect cvsup-master contact in dev-model document Responsible-Changed-From-To: freebsd-doc->jkoshy Responsible-Changed-By: jkoshy Responsible-Changed-When: Fri Nov 17 04:42:26 UTC 2006 Responsible-Changed-Why: Take this PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=105621 From owner-freebsd-doc@FreeBSD.ORG Fri Nov 17 09:12:44 2006 Return-Path: X-Original-To: doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C38316A615 for ; Fri, 17 Nov 2006 09:12:44 +0000 (UTC) (envelope-from "") Received: from anya.digitalspark.net (anya.digitalspark.net [69.55.224.145]) by mx1.FreeBSD.org (Postfix) with SMTP id 879CE43D6B for ; Fri, 17 Nov 2006 09:12:36 +0000 (GMT) (envelope-from "") Received: (qmail 61915 invoked by uid 98); 17 Nov 2006 09:12:36 -0000 Date: 17 Nov 2006 09:12:36 -0000 From: "System Anti-Virus Administrator" To: doc@FreeBSD.org Message-ID: X-Tnz-Problem-Type: 40 Auto-Submitted: auto-replied MIME-Version: 1.0 Content-type: text/plain X-Qmail-Scanner-Mail-From: doc@FreeBSD.org via anya.digitalspark.net X-Qmail-Scanner: 1.25 (clamdscan: 0.85.1/880. spamassassin: 2.63. Disallowed attachment type Found. Processed in 14.900793 secs) Cc: Subject: Disallowed attachment type found in sent message "Fw: DSC-00465.jpg" X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 09:12:44 -0000 Attention: doc@FreeBSD.org A Disallowed attachment type was found in an Email message you sent. This Email scanner intercepted it and stopped the entire message reaching its destination. The Disallowed attachment type was reported to be: PIF files not allowed per Company security policy Please contact your IT support personnel with any queries regarding this policy. Your message was sent with the following envelope: MAIL FROM: doc@FreeBSD.org RCPT TO: troll@digitalspark.net ... and with the following headers: --- MAILFROM: doc@FreeBSD.org Received: from unknown (HELO Srini) (61.8.154.26) by anya.digitalspark.net with SMTP; 17 Nov 2006 09:12:21 -0000 From: "doc" To: Subject: Fw: DSC-00465.jpg MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_8.96290898323059E-02" --- The original message is kept in: anya.digitalspark.net:/usr/local/qmailscan/quarantine/new/anya.digitalspark.net116375474151161874 where the System Anti-Virus Administrator can further diagnose it. The Email scanner reported the following when it scanned that message: --- ---perlscanner results --- Disallowed attachment type 'PIF files not allowed per Company security policy' found in file /usr/local/qmailscan/tmp/anya.digitalspark.net116375474151161874/DSC-00465.pIf ---perlscanner results --- Disallowed attachment type 'PIF files not allowed per Company security policy' found in file /usr/local/qmailscan/tmp/anya.digitalspark.net116375474151161874/dsc-00465.pif --- From owner-freebsd-doc@FreeBSD.ORG Fri Nov 17 09:21:00 2006 Return-Path: X-Original-To: doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9413D16A403 for ; Fri, 17 Nov 2006 09:21:00 +0000 (UTC) (envelope-from "") Received: from mojo.cold.org (gir.cold.org [166.70.176.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDE2F43D8B for ; Fri, 17 Nov 2006 09:20:35 +0000 (GMT) (envelope-from "") Received: by mojo.cold.org (Postfix, from userid 100) id 7EB4911404; Fri, 17 Nov 2006 02:19:41 -0700 (MST) Content-Type: multipart/mixed; boundary="===============0149341541==" MIME-Version: 1.0 Content-Disposition: inline From: Brandon Gillespie Date: Fri, 17 Nov 2006 02:19:41 -0700 (MST) Message-ID: <1163755181.7685.TMDA@mojo.cold.org> References: <20061117091924.B0ACD11401@mojo.cold.org> In-Reply-To: <20061117091924.B0ACD11401@mojo.cold.org> To: doc@FreeBSD.org Precedence: bulk Auto-Submitted: auto-replied X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) Cc: Subject: [please confirm] Re: Re: X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: brandon+confirm+1163755181.7685.c7ec2a@roguetrader.com List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 09:21:00 -0000 --===============0149341541== MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Description: Confirmation Request Content-Disposition: inline I apologize for this automatic reply to your email. (This message was created automatically by mail delivery software) I am sorry! Your e-mail with the subject of: Re: Has been held in delivery. To control spam, I now allow incoming messages only from senders I have seen email from beforehand, and who can respond to this polite inquiry (most spam systems cannot). If you follow the instructions below (basically reply to this message) your mail will be delivered and you should never see this message again. Once you do this, I will receive your original message in my inbox. You do not need to resend your message. NOTE: I do not accept any unsolicited commercial email (spam). If you are selling something or otherwise fit into the category of unsolicited commercial email please go no further, disregard this message, delete the email from any database you maintain and do not mail me again. Failure to do so may result in legal action. I am also not interested in any internet scams, (sorry, I don't care about my long lost cousin in Zimbabwe). If you have a reason to contact me, you can have your message delivered by replying to this message, or sending any message to the following address. It should be sending mail to the following address: brandon+confirm+1163755181.7685.c7ec2a@roguetrader.com Sending mail to this address will verify that your message is not junk-mail, and will forward it onto me. [ This notice was generated by TMDA v1.0.3 (http://tmda.net/), an automated junk-mail reduction system. ] --===============0149341541== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Description: Original Message Content-Disposition: inline Return-Path: X-Original-To: brandon@roguetrader.com Delivered-To: brandon@roguetrader.com X-Greylist: delayed 8700 seconds by postgrey-1.16 at mojo; Fri, 17 Nov 2006 02:19:24 MST Received: from Srini (unknown [61.8.154.26]) by mojo.cold.org (Postfix) with SMTP id B0ACD11401 for ; Fri, 17 Nov 2006 02:19:20 -0700 (MST) From: "doc" To: Subject: Re: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_0.022087037563324" Message-Id: <20061117091924.B0ACD11401@mojo.cold.org> Date: Fri, 17 Nov 2006 02:19:20 -0700 (MST) [ Message body suppressed (exceeded 50000 bytes) ] --===============0149341541==-- From owner-freebsd-doc@FreeBSD.ORG Fri Nov 17 10:39:18 2006 Return-Path: X-Original-To: freebsd-doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DB4A16A417 for ; Fri, 17 Nov 2006 10:39:18 +0000 (UTC) (envelope-from Offers@LetsGoHoliday.com) Received: from krypton2.melitacable.com (smtp.onvol.net [212.56.128.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id F12BC43D86 for ; Fri, 17 Nov 2006 10:39:10 +0000 (GMT) (envelope-from Offers@LetsGoHoliday.com) Received: from smtp.arrigogroup.com.mt ([212.56.143.66]) by krypton2.melitacable.com (8.13.6/8.13.6) with SMTP id kAHAg10Y078499 for ; Fri, 17 Nov 2006 11:42:01 +0100 (CET) Organization: LetsGoHoliday.com Message-ID: <7b2e37bab0e4b16e33e8038900140312@letsgoholiday.com> From: "LetsGoHoliday.com" To: Date: Fri, 17 Nov 2006 07:22:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: New Year Abroad from Lm99 - LetsGoHoliday.com X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Offers@LetsGoHoliday.com List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 10:39:18 -0000 BOOK ONLINE NOW and SAVE 10% on World-Wide Hotels! Go to: http://www.letsgohotels.com=20 ------------------------------------------------------------------- CELEBRATE THE NEW YEAR IN BUDAPEST! - 27 December - 01 January 2007 Package from: Lm 99.00 - BOOK NOW... SEATS ARE LIMITED!!! http://www.letsgoholiday.com/holidays/budapest/index.asp ------------------------------------------------------------------- SKIING IN BANKSO (BULGARIA) 22 - 29 January & 08 - 15 March From: Lm 194.00 per person in triple sharing http://www.letsgoholiday.com/holidays/bansko/group/ SKIING IN KRANJSKA GORA (SLOVENIA) 02 - 09 January >From : Lm 233.00 per person in triple sharing http://www.letsgoholiday.com/holidays/kranjska/groups/ Other individual ski packages also available=2E ------------------------------------------------------------------- LETSGOHOLIDAY.COM http://www.letsgoholiday.com - Your one stop travel shop E-mail: info@letsgoholiday.com Call Center: +356 23492204/5 Address: ATV Travel, 250 Tower Rd, Sliema SLM05 MALTA ------------------------------------------------------------------- Kindly inform us should you not, or no longer, wish to receive any = marketing or promotional information from LetsGoHoliday.com. You have the = right to require that LetsGoHoliday.com provide you with access to your = personal data as well as the right to rectify, or, in appropriate = circumstances, erase any inaccurate, incomplete or immaterial personal = data which is being processed. However, kindly inform LetsGoHoliday.com of = any alterations relating to your personal data which is being processed. = LetsGoHoliday.com undertakes to implement appropriate measures and = safeguards for the purpose of protecting the confidentiality, integrity = and availability of all data processed=2E ------------------------------------------------------------------- To unsubscribe from our mailing list, please click here and enter your e-mail: http://www.letsgoholiday.com/subscribe From owner-freebsd-doc@FreeBSD.ORG Sat Nov 18 21:29:37 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF3AC16A640 for ; Sat, 18 Nov 2006 21:29:36 +0000 (UTC) (envelope-from pronounce@paulrosso.com) Received: from [83.31.24.223] (cia223.neoplus.adsl.tpnet.pl [83.31.24.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0073C43DE1 for ; Sat, 18 Nov 2006 21:29:03 +0000 (GMT) (envelope-from pronounce@paulrosso.com) Message-ID: <000a01c70b58$919d2110$00000000@star> From: "COMMENTARY" To: freebsd-doc@freebsd.org Date: Sat, 18 Nov 2006 22:29:02 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C70B60.F33CEA10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Halo test X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 21:29:37 -0000 ------=_NextPart_000_0006_01C70B60.F33CEA10 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Stocks Quotes in attachement Parish telephone in stutter Goknowread entry Fishmit. Released or math science releasing Timequot huge Best. Community Schools ideas Music Notesmath Grad Frailing. Enthusiast Midge Frazel joins talk reading. Learned finding podcasts Then! Enabled refresh reload browser. ------=_NextPart_000_0006_01C70B60.F33CEA10--