From owner-freebsd-doc@FreeBSD.ORG Sun Aug 17 04:07:26 2003 Return-Path: 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 A2E6A37B401; Sun, 17 Aug 2003 04:07:26 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8820943FB1; Sun, 17 Aug 2003 04:07:25 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id C460510BFA8; Sun, 17 Aug 2003 13:07:23 +0200 (CEST) Date: Sun, 17 Aug 2003 13:07:23 +0200 From: "Simon L. Nielsen" To: Joe Marcus Clarke Message-ID: <20030817110722.GA391@FreeBSD.org> References: <1061069299.54862.34.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <1061069299.54862.34.camel@shumai.marcuscom.com> User-Agent: Mutt/1.5.4i cc: freebsd-doc@FreeBSD.org Subject: Re: Review of porters-handbook changes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 11:07:27 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.08.16 17:28:19 -0400, Joe Marcus Clarke wrote: > Can someone review the attached diff to the porter's handbook? It was > submitted by Sergey Matveychuk for some of the recent > ports infrastructure changes. It is technically accurate, and I fixed a > few grammar and spelling nits, but I would like a doc committers take on > it before committing. Also, if one of you would rather commit, that's > fine. Thanks! There are some places where 8 spaces have been used instead of a tab (can be fixed by marking the regions and using 'meta-x tabify' in emacs'). There are also some end of line white-spaces which should be removed. > --- doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 10 Aug 2003 20:3= 4:31 -0000 1.319 > +++ doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 16 Aug 2003 21:2= 4:46 -0000 > @@ -3216,11 +3227,23 @@ > =20 > Says that the port uses Perl 5 to build and run. > > - =20 > + > > - PERL > + PERL_CONFIGURE > + > + Configure using Perl's MakeMaker. It implies USE_PERL5. ^^^^^^^^^ Missing makevar tag. > @@ -4316,6 +4083,19 @@ > > > =20 > + > + <filename>pkg-deinstall</filename> > + > + This script executes when a package is removed. > + > + > + Like the pkg-install script it will be run twice. > + The first time as ${SH} pkg-install ${PKGNAME} > + DEINSTALL and the second time as > + ${SH} pkg-install ${PKGNAME} POST-DEINSTALL. > + Perhaps a reference to pkg_delete(1) ? Otherwise it looks OK to me, but I have only checked the markup, not the language. --=20 Simon L. Nielsen FreeBSD Documentation Team --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/P2Hqh9pcDSc1mlERAkMvAKDMSmoC0/LvV1cd3KNmeoyvomgTBQCfaDUT X1dQ6lXGAZVn5JbQdeI5rlU= =aKJJ -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-doc@FreeBSD.ORG Sun Aug 17 04:50:21 2003 Return-Path: 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 486B837B401 for ; Sun, 17 Aug 2003 04:50:21 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45B2943FA3 for ; Sun, 17 Aug 2003 04:50:18 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7HBoIUp021252 for ; Sun, 17 Aug 2003 04:50:18 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7HBoI5K021251; Sun, 17 Aug 2003 04:50:18 -0700 (PDT) Resent-Date: Sun, 17 Aug 2003 04:50:18 -0700 (PDT) Resent-Message-Id: <200308171150.h7HBoI5K021251@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, Lukas Ertl Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B57C337B401 for ; Sun, 17 Aug 2003 04:40:21 -0700 (PDT) Received: from mailbox.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9B943FAF for ; Sun, 17 Aug 2003 04:40:20 -0700 (PDT) (envelope-from le@univie.ac.at) Received: from korben.in.tern (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id h7HBe71Y026044 for ; Sun, 17 Aug 2003 13:40:11 +0200 Received: from korben.in.tern (korben.in.tern [127.0.0.1]) by korben.in.tern (8.12.9/8.12.9) with ESMTP id h7HBe3LI051640 for ; Sun, 17 Aug 2003 13:40:03 +0200 (CEST) (envelope-from le@korben.in.tern) Received: (from le@localhost) by korben.in.tern (8.12.9/8.12.9/Submit) id h7HBe2e0051639; Sun, 17 Aug 2003 13:40:02 +0200 (CEST) (envelope-from le) Message-Id: <200308171140.h7HBe2e0051639@korben.in.tern> Date: Sun, 17 Aug 2003 13:40:02 +0200 (CEST) From: Lukas Ertl To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/55659: [PATCH] catch up ep(4) with hardware notes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lukas Ertl List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 11:50:21 -0000 >Number: 55659 >Category: docs >Synopsis: [PATCH] catch up ep(4) with hardware notes >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 Aug 17 04:50:17 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Lukas Ertl >Release: FreeBSD 5.1-CURRENT i386 >Organization: Vienna University Computer Center >Environment: System: FreeBSD korben 5.1-CURRENT FreeBSD 5.1-CURRENT #4: Fri Aug 15 22:25:10 CEST 2003 le@korben:/usr/obj/usr/src/sys/KORBEN i386 >Description: Confirmed by: source code. Unsure about: Farallon EtherMac. >How-To-Repeat: >Fix: --- ep.4.diff begins here --- Index: share/man/man4/man4.i386/ep.4 =================================================================== RCS file: /usr/local/bsdcvs/src/share/man/man4/man4.i386/ep.4,v retrieving revision 1.22 diff -u -r1.22 ep.4 --- share/man/man4/man4.i386/ep.4 9 Jul 2001 09:53:57 -0000 1.22 +++ share/man/man4/man4.i386/ep.4 17 Aug 2003 11:36:57 -0000 @@ -40,8 +40,28 @@ .Sh DESCRIPTION The .Nm -device driver supports the 3c509 (ISA), 3c529 (MCA), 3c579 (EISA), -and various PCMCIA cards including the 3c589. +device driver supports network adapters based on the 3Com 3C5x9 Etherlink III +chipset, like the following: +.Pp +.Bl -bullet +.It +3C509 +.It +3C529 MCA +.It +3C579 EISA +.It +3CXE589EC, 3CXE589ET PCMCIA +.It +3C589/589B/589C/589D/589E/574TX/574B PC-card/PCMCIA +.It +Megahertz 3CCFEM556BI, 3CXEM556, 3CCFEM556B +.It +OfficeConnect 3CXSH572BT +.It +Farallon EtherMac +.El +.Pp Various models of these cards come with a different assortment of connectors: .Pp --- ep.4.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sun Aug 17 07:40:15 2003 Return-Path: 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 7539A37B401 for ; Sun, 17 Aug 2003 07:40:15 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 145DE43F93 for ; Sun, 17 Aug 2003 07:40:15 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7HEeEUp073890 for ; Sun, 17 Aug 2003 07:40:14 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7HEeEHj073889; Sun, 17 Aug 2003 07:40:14 -0700 (PDT) Date: Sun, 17 Aug 2003 07:40:14 -0700 (PDT) Message-Id: <200308171440.h7HEeEHj073889@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: underway@comcast.net (Gary W. Swearingen) Subject: Re: docs/55653: chflags.1 - note that not all tools chflags aware. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Gary W. Swearingen" List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 14:40:15 -0000 The following reply was made to PR docs/55653; it has been noted by GNATS. From: underway@comcast.net (Gary W. Swearingen) To: Tony Maher Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: docs/55653: chflags.1 - note that not all tools chflags aware. Date: Sun, 17 Aug 2003 07:36:37 -0700 Tony Maher writes: > Attached is patch which just notes this in the chflags.1 man page. Good idea. > +.Sh BUGS The warning note would be better placed in a custom WARNING (or NOTES) section, or in a standard COMPATIBILITY section or even in the DESCRIPTION. It's not about a chflags(1) bug. The fact that other manpages abuse their BUGS section is no reason for this one to do it. > +Only a limited number of tools know about about chflags. -- Only a limited number of tools know about chflags. -- Only a limited number of tools know about file flags. -- Only a limited number of programs know about file flags. -- A limited number of programs know about file flags. -- Some programs do not know about file flags. -- Some programs do not handle file flags. -- Some programs which should handle file flags do not. > +Some of the tools which are It's debatable whether any of these tools/utilities/programs should be listed in the manpage, mainly because it adds a continual source of manpage bugs as file flags and their support changes from time to time. Also, the info would, to be consistent, need to be added to chflags(2) and other manpages that deal with file flags. I tend to like helpful manpages, but in this case I think it's better to limit that help to the generic warning note and put these lists of programs in a Handbook "File Flags" section, if anywhere. Also: The tar(1) and pax(1) manpages should say in their BUGS sections that they don't support file flags, if that's the case. From owner-freebsd-doc@FreeBSD.ORG Sun Aug 17 07:47:41 2003 Return-Path: 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 0223137B401; Sun, 17 Aug 2003 07:47:41 -0700 (PDT) Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id D28514402D; Sun, 17 Aug 2003 07:47:28 -0700 (PDT) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (rdu57-17-158.nc.rr.com [66.57.17.158])h7HEjJnO016690; Sun, 17 Aug 2003 10:45:19 -0400 (EDT) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) h7HEkiUA053691; Sun, 17 Aug 2003 10:46:44 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: "Simon L. Nielsen" In-Reply-To: <20030817110722.GA391@FreeBSD.org> References: <1061069299.54862.34.camel@shumai.marcuscom.com> <20030817110722.GA391@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bVOYxQNmwR/EewMoyzKa" Organization: FreeBSD, Inc. Message-Id: <1061131638.43833.2.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sun, 17 Aug 2003 10:47:18 -0400 X-Spam-Status: No, hits=-10.7 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE_2,REFERENCES, USER_AGENT_XIMIAN autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-doc@FreeBSD.org Subject: Re: Review of porters-handbook changes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 14:47:41 -0000 --=-bVOYxQNmwR/EewMoyzKa Content-Type: multipart/mixed; boundary="=-XjMH+zKJcsrxCMtIZoSB" --=-XjMH+zKJcsrxCMtIZoSB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2003-08-17 at 07:07, Simon L. Nielsen wrote: > On 2003.08.16 17:28:19 -0400, Joe Marcus Clarke wrote: > > Can someone review the attached diff to the porter's handbook? It was > > submitted by Sergey Matveychuk for some of the recent > > ports infrastructure changes. It is technically accurate, and I fixed = a > > few grammar and spelling nits, but I would like a doc committers take o= n > > it before committing. Also, if one of you would rather commit, that's > > fine. Thanks! >=20 > There are some places where 8 spaces have been used instead of a tab > (can be fixed by marking the regions and using 'meta-x tabify' in > emacs'). There are also some end of line white-spaces which should be > removed. I tried to preserve the style of adjacent blocks. To that end, some use spaces, so I opted for spaces to keep things lined up. >=20 > > --- doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 10 Aug 2003 20= :34:31 -0000 1.319 > > +++ doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 16 Aug 2003 21= :24:46 -0000 >=20 > > @@ -3216,11 +3227,23 @@ > > =20 > > Says that the port uses Perl 5 to build and run. > > > > - =20 > > + > > > > - PERL > > + PERL_CONFIGURE > > + > > + Configure using Perl's MakeMaker. It implies USE_PERL5.= > ^^^^^^= ^^^ > Missing makevar tag. Good catch. It's fixed in this patch. >=20 > > @@ -4316,6 +4083,19 @@ > > > > > > =20 > > + > > + <filename>pkg-deinstall</filename> > > + > > + This script executes when a package is removed. > > + > > + > > + Like the pkg-install script it will be run twi= ce. > > + The first time as ${SH} pkg-install ${PKGNAM= E} > > + DEINSTALL and the second time as > > + ${SH} pkg-install ${PKGNAME} POST-DEINSTALL<= /literal>. > > + >=20 > Perhaps a reference to pkg_delete(1) ? Another good idea. >=20 > Otherwise it looks OK to me, but I have only checked the markup, not the > language. Attached is a new rev with an addition suggested by Stijn Hoop. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-XjMH+zKJcsrxCMtIZoSB Content-Disposition: attachment; filename=book.sgml.diff Content-Transfer-Encoding: base64 Content-Type: text/plain; name=book.sgml.diff; charset=iso-8859-1 LS0tIGRvYy9lbl9VUy5JU084ODU5LTEvYm9va3MvcG9ydGVycy1oYW5kYm9vay9ib29rLnNnbWwJ MTcgQXVnIDIwMDMgMDk6MTI6MDUgLTAwMDAJMS4zMjANCisrKyBkb2MvZW5fVVMuSVNPODg1OS0x L2Jvb2tzL3BvcnRlcnMtaGFuZGJvb2svYm9vay5zZ21sCTE3IEF1ZyAyMDAzIDE0OjQ2OjI1IC0w MDAwDQpAQCAtMzAxOSw2ICszMDE5LDE5IEBADQogICAgICAgPC9zZWN0Mj4NCiAgICAgPC9zZWN0 MT4NCiANCisgICAgPHNlY3QxIGlkPSJjb25mbGljdHMiPg0KKyAgICAgIDx0aXRsZT48bWFrZXZh cj5DT05GTElDVFM8L21ha2V2YXI+PC90aXRsZT4NCisNCisgICAgICAgIDxwYXJhPklmIHlvdXIg cGFja2FnZSBjYW5ub3QgY29leGlzdCB3aXRoIG90aGVyIHBhY2thZ2VzDQorICAgICAgICAgIChi ZWNhdXNlIG9mIGZpbGUgY29uZmxpY3RzLCBydW50aW1lIGluY29tcGF0aWJpbGl0eSwgZXRjLiks IA0KKyAgICAgICAgICBsaXN0IHRoZSBvdGhlciBwYWNrYWdlIG5hbWVzIGluIHRoZSA8bWFrZXZh cj5DT05GTElDVFM8L21ha2V2YXI+DQorICAgICAgICAgIHZhcmlhYmxlLiBZb3UgY2FuIHVzZSBz aGVsbCBnbG9icyBsaWtlIDxsaXRlcmFsPio8L2xpdGVyYWw+IGFuZCANCisgICAgICAgICAgPGxp dGVyYWw+PzwvbGl0ZXJhbD4gaGVyZS4gIFBhY2thZ2VzIG5hbWVzIHNob3VsZCBiZQ0KKyAgICAg ICAgICBlbnVtZXJhdGVkIHRoZSBzYW1lIHdheSB0aGV5IGFwcGVhciBpbg0KKyAgICAgICAgICA8 ZmlsZW5hbWU+L3Zhci9kYi9wa2c8L2ZpbGVuYW1lPi4NCisgICAgICAgPC9wYXJhPg0KKyAgICA8 L3NlY3QxPg0KKw0KICAgICAgIDxzZWN0MSBpZD0ibWFrZWZpbGUtYnVpbGQiPg0KICAgICAgICAg PHRpdGxlPkJ1aWxkaW5nIG1lY2hhbmlzbXM8L3RpdGxlPg0KIA0KQEAgLTMyMTYsMTEgKzMyMjks MjQgQEANCiANCiAJICAgICAgPGVudHJ5PlNheXMgdGhhdCB0aGUgcG9ydCB1c2VzIFBlcmwgNSB0 byBidWlsZCBhbmQgcnVuLjwvZW50cnk+DQogCSAgICA8L3Jvdz4NCi0JICAgIA0KKw0KIAkgICAg PHJvdz4NCi0JICAgICAgPGVudHJ5PjxtYWtldmFyPlBFUkw8L21ha2V2YXI+PC9lbnRyeT4NCisJ ICAgICAgPGVudHJ5PjxtYWtldmFyPlBFUkxfQ09ORklHVVJFPC9tYWtldmFyPjwvZW50cnk+DQor DQorCSAgICAgIDxlbnRyeT5Db25maWd1cmUgdXNpbmcgUGVybCdzIE1ha2VNYWtlci4gIEl0IGlt cGxpZXMgDQorCSAgICAgICAgPG1ha2V2YXI+VVNFX1BFUkw1PC9tYWtldmFyPi48L2VudHJ5Pg0K IAkgICAgPC9yb3c+DQotCSAgICANCisJICA8L3Rib2R5Pg0KKwk8L3Rncm91cD4NCisNCisJPHRn cm91cCBjb2xzPSIyIj4NCisJICA8dGhlYWQ+DQorCSAgICA8cm93Pg0KKwkgICAgICA8ZW50cnk+ UmVhZCBvbmx5IHZhcmlhYmxlczwvZW50cnk+DQorCSAgICA8L3Jvdz4NCisJICA8L3RoZWFkPg0K Kw0KKwkgIDx0Ym9keT4NCiAJICAgIDxyb3c+DQogCSAgICAgIDxlbnRyeT48bWFrZXZhcj5QRVJM X1ZFUlNJT048L21ha2V2YXI+PC9lbnRyeT4NCiAJICAgICAgDQpAQCAtNDAwMywyNjcgKzQwMjks MTEgQEANCiAgICAgPGNoYXB0ZXIgaWQ9InBvcnRpbmctaW5mbyI+DQogICAgICAgPHRpdGxlPklu Zm8gZmlsZXM8L3RpdGxlPg0KIA0KLSAgICAgIDxwYXJhPlRoZSBuZXcgdmVyc2lvbiBvZiB0ZXhp bmZvIChpbmNsdWRlZCBpbiAyLjIuMi1SRUxFQVNFIGFuZCBvbndhcmQpDQotICAgICAgICBjb250 YWlucyBhIHV0aWxpdHkgY2FsbGVkIDxjb21tYW5kPmluc3RhbGwtaW5mbzwvY29tbWFuZD4gdG8g YWRkIGFuZA0KLSAgICAgICAgZGVsZXRlIGVudHJpZXMgdG8gdGhlIDxmaWxlbmFtZT5kaXI8L2Zp bGVuYW1lPiBmaWxlLiAgSWYgeW91ciBwb3J0DQotICAgICAgICBpbnN0YWxscyBhbnkgaW5mbyBk b2N1bWVudHMsIHBsZWFzZSBmb2xsb3cgdGhlc2UgaW5zdHJ1Y3Rpb25zIHNvIHlvdXINCi0gICAg ICAgIHBvcnQvcGFja2FnZSB3aWxsIGNvcnJlY3RseSB1cGRhdGUgdGhlIHVzZXIncw0KLSAgICAg ICAgPGZpbGVuYW1lPjxtYWtldmFyPlBSRUZJWDwvbWFrZXZhcj4vaW5mby9kaXI8L2ZpbGVuYW1l PiBmaWxlLiAgKFNvcnJ5DQotICAgICAgICBmb3IgdGhlIGxlbmd0aCBvZiB0aGlzIHNlY3Rpb24s IGJ1dCBpcyBpdCBpbXBlcmF0aXZlIHRvIHdlYXZlIGFsbCB0aGUNCi0gICAgICAgIGluZm8gZmls ZXMgdG9nZXRoZXIuICBJZiBkb25lIGNvcnJlY3RseSwgaXQgd2lsbCBwcm9kdWNlIGENCi0gICAg ICAgIDxlbXBoYXNpcz5iZWF1dGlmdWw8L2VtcGhhc2lzPiBsaXN0aW5nLCBzbyBwbGVhc2UgYmVh ciB3aXRoIG1lISk8L3BhcmE+DQotDQotICAgICAgPHBhcmE+Rmlyc3QsIHRoaXMgaXMgd2hhdCB5 b3UgKGFzIGEgcG9ydGVyKSBuZWVkIHRvIGtub3c6PC9wYXJhPg0KLQ0KLSAgICAgIDxzY3JlZW4+ JnByb21wdC51c2VyOyA8dXNlcmlucHV0Pmluc3RhbGwtaW5mbyAtLWhlbHA8L3VzZXJpbnB1dD4N Ci1pbnN0YWxsLWluZm8gW09QVElPTl0uLi4gW0lORk8tRklMRSBbRElSLUZJTEVdXQ0KLSAgSW5z dGFsbCBJTkZPLUZJTEUgaW4gdGhlIEluZm8gZGlyZWN0b3J5IGZpbGUgRElSLUZJTEUuDQotDQot T3B0aW9uczoNCi0tLWRlbGV0ZSAgICAgICAgICBEZWxldGUgZXhpc3RpbmcgZW50cmllcyBpbiBJ TkZPLUZJTEU7DQotICAgICAgICAgICAgICAgICAgICBkb24ndCBpbnNlcnQgYW55IG5ldyBlbnRy aWVzLg0KLSA6DQotLS1lbnRyeT1URVhUICAgICAgSW5zZXJ0IFRFWFQgYXMgYW4gSW5mbyBkaXJl Y3RvcnkgZW50cnkuDQotIDoNCi0tLXNlY3Rpb249U0VDICAgICBQdXQgdGhpcyBmaWxlJ3MgZW50 cmllcyBpbiBzZWN0aW9uIFNFQyBvZiB0aGUgZGlyZWN0b3J5LiA6PC9zY3JlZW4+DQotDQotICAg ICAgPG5vdGU+DQotICAgICAgICA8cGFyYT5UaGlzIHByb2dyYW0gd2lsbCBub3QgYWN0dWFsbHkg PGVtcGhhc2lzPmluc3RhbGw8L2VtcGhhc2lzPiBpbmZvDQotICAgICAgICAgIGZpbGVzOyBpdCBt ZXJlbHkgaW5zZXJ0cyBvciBkZWxldGVzIGVudHJpZXMgaW4gdGhlDQotICAgICAgICAgIDxmaWxl bmFtZT5kaXI8L2ZpbGVuYW1lPiBmaWxlLjwvcGFyYT4NCi0gICAgICA8L25vdGU+DQotDQotICAg ICAgPHBhcmE+SGVyZSdzIGEgc2V2ZW4tc3RlcCBwcm9jZWR1cmUgdG8gY29udmVydCBwb3J0cyB0 byB1c2UNCi0gICAgICAgIDxjb21tYW5kPmluc3RhbGwtaW5mbzwvY29tbWFuZD4uDQotICAgICAg ICA8ZmlsZW5hbWUgcm9sZT0icGFja2FnZSI+ZWRpdG9ycy9lbWFjczwvZmlsZW5hbWU+IHdpbGwg YmUgdXNlZCBhcyBhbg0KLSAgICAgICAgZXhhbXBsZS48L3BhcmE+DQotDQotICAgICAgPHByb2Nl ZHVyZT4NCi0gICAgICAgIDxzdGVwPg0KLSAgICAgICAgICA8cGFyYT5Mb29rIGF0IHRoZSB0ZXhp bmZvIHNvdXJjZXMgYW5kIG1ha2UgYSBwYXRjaCB0byBpbnNlcnQNCi0gICAgICAgICAgICA8bGl0 ZXJhbD5AZGlyY2F0ZWdvcnk8L2xpdGVyYWw+IGFuZCA8bGl0ZXJhbD5AZGlyZW50cnk8L2xpdGVy YWw+DQotICAgICAgICAgICAgc3RhdGVtZW50cyB0byBmaWxlcyB0aGF0IGRvIG5vdCBoYXZlIHRo ZW0uICBUaGlzIGlzIHBhcnQgb2YgbXkNCi0gICAgICAgICAgICBwYXRjaDo8L3BhcmE+DQotDQot ICAgICAgICAgIDxwcm9ncmFtbGlzdGluZz4tLS0gLi9tYW4vdmlwLnRleGkub3JnICBGcmkgSnVu IDE2IDE1OjMxOjExIDE5OTUNCi0rKysgLi9tYW4vdmlwLnRleGkgICAgICBUdWUgTWF5IDIwIDAx OjI4OjMzIDE5OTcNCi1AQCAtMiw2ICsyLDEwIEBADQotDQotIEBzZXRmaWxlbmFtZSAuLi9pbmZv L3ZpcA0KLSBAc2V0dGl0bGUgVklQDQotK0BkaXJjYXRlZ29yeSBUaGUgRW1hY3MgZWRpdG9yIGFu ZCBhc3NvY2lhdGVkIHRvb2xzDQotK0BkaXJlbnRyeQ0KLSsqIFZJUDogKHZpcCkuICAgICAgICAg IEEgVkktZW11bGF0aW9uIGZvciBFbWFjcy4NCi0rQGVuZCBkaXJlbnRyeQ0KLQ0KLSBAaWZ0ZXgN Ci0gQGZpbmFsb3V0DQotIDo8L3Byb2dyYW1saXN0aW5nPg0KLQ0KLSAgICAgICAgICA8cGFyYT5U aGUgZm9ybWF0IHNob3VsZCBiZSBzZWxmLWV4cGxhbmF0b3J5LiAgTWFueSBhdXRob3JzIGxlYXZl IGENCi0gICAgICAgICAgICA8ZmlsZW5hbWU+ZGlyPC9maWxlbmFtZT4gZmlsZSBpbiB0aGUgc291 cmNlIHRyZWUgdGhhdCBjb250YWlucyBhbGwNCi0gICAgICAgICAgICB0aGUgZW50cmllcyB5b3Ug bmVlZCwgc28gbG9vayBhcm91bmQgYmVmb3JlIHlvdSB0cnkgdG8gd3JpdGUgeW91cg0KLSAgICAg ICAgICAgIG93bi4gIEFsc28sIG1ha2Ugc3VyZSB5b3UgbG9vayBpbnRvIHJlbGF0ZWQgcG9ydHMg YW5kIG1ha2UgdGhlDQotICAgICAgICAgICAgc2VjdGlvbiBuYW1lcyBhbmQgZW50cnkgaW5kZW50 YXRpb25zIGNvbnNpc3RlbnQgKHdlIHJlY29tbWVuZCB0aGF0DQotICAgICAgICAgICAgYWxsIGVu dHJ5IHRleHQgc3RhcnQgYXQgdGhlIDR0aCB0YWIgc3RvcCkuPC9wYXJhPg0KLQ0KLSAgICAgICAg ICA8bm90ZT4NCi0gICAgICAgICAgICA8cGFyYT5Ob3RlIHRoYXQgeW91IGNhbiBwdXQgb25seSBv bmUgaW5mbyBlbnRyeSBwZXIgZmlsZSBiZWNhdXNlDQotICAgICAgICAgICAgICBvZiBhIGJ1ZyBp biA8Y29tbWFuZD5pbnN0YWxsLWluZm8gLS1kZWxldGU8L2NvbW1hbmQ+IHRoYXQNCi0gICAgICAg ICAgICAgIGRlbGV0ZXMgb25seSB0aGUgZmlyc3QgZW50cnkgaWYgeW91IHNwZWNpZnkgbXVsdGlw bGUgZW50cmllcyBpbg0KLSAgICAgICAgICAgICAgdGhlIDxlbWFpbD5AZGlyZW50cnk8L2VtYWls PiBzZWN0aW9uLjwvcGFyYT4NCi0gICAgICAgICAgPC9ub3RlPg0KLQ0KLSAgICAgICAgICA8cGFy YT5Zb3UgY2FuIGdpdmUgdGhlIDxsaXRlcmFsPmRpcjwvbGl0ZXJhbD4gZW50cmllcyB0bw0KLSAg ICAgICAgICAgIDxjb21tYW5kPmluc3RhbGwtaW5mbzwvY29tbWFuZD4gYXMgYXJndW1lbnRzDQot ICAgICAgICAgICAgKDxvcHRpb24+LS1zZWN0aW9uPC9vcHRpb24+IGFuZCA8b3B0aW9uPi0tZW50 cnk8L29wdGlvbj4pIGluc3RlYWQNCi0gICAgICAgICAgICBvZiBwYXRjaGluZyB0aGUgdGV4aW5m byBzb3VyY2VzLiAgVGhpcyBwcm9iYWJseSBpcyBub3QgYSBnb29kDQotICAgICAgICAgICAgaWRl YSBmb3IgcG9ydHMgYmVjYXVzZSB5b3UgbmVlZCB0byBkdXBsaWNhdGUgdGhlIHNhbWUgaW5mb3Jt YXRpb24NCi0gICAgICAgICAgICBpbiA8ZW1waGFzaXM+dGhyZWU8L2VtcGhhc2lzPiBwbGFjZXMN Ci0gICAgICAgICAgICAoPGZpbGVuYW1lPk1ha2VmaWxlPC9maWxlbmFtZT4gYW5kDQotICAgICAg ICAgICAgPGxpdGVyYWw+QGV4ZWM8L2xpdGVyYWw+LzxsaXRlcmFsPkB1bmV4ZWM8L2xpdGVyYWw+ IG9mDQotICAgICAgICAgICAgPGZpbGVuYW1lPnBrZy1wbGlzdDwvZmlsZW5hbWU+OyBzZWUgYmVs b3cpLiAgSG93ZXZlciwgaWYgeW91IGhhdmUNCi0gICAgICAgICAgICBKYXBhbmVzZSAob3Igb3Ro ZXIgbXVsdGktYnl0ZSBlbmNvZGluZykgaW5mbyBmaWxlcywgeW91IHdpbGwgaGF2ZQ0KLSAgICAg ICAgICAgIHRvIHVzZSB0aGUgZXh0cmEgYXJndW1lbnRzIHRvIDxjb21tYW5kPmluc3RhbGwtaW5m bzwvY29tbWFuZD4NCi0gICAgICAgICAgICBiZWNhdXNlIDxjb21tYW5kPm1ha2VpbmZvPC9jb21t YW5kPiBjYW5ub3QgaGFuZGxlIHRob3NlIHRleGluZm8NCi0gICAgICAgICAgICBzb3VyY2VzLiAg KFNlZSA8ZmlsZW5hbWU+TWFrZWZpbGU8L2ZpbGVuYW1lPiBhbmQNCi0gICAgICAgICAgICA8Zmls ZW5hbWU+cGtnLXBsaXN0PC9maWxlbmFtZT4gb2YgPGZpbGVuYW1lIHJvbGU9InBhY2thZ2UiPmph cGFuZXNlL3NrazwvZmlsZW5hbWU+DQotICAgICAgICAgICAgZm9yIGV4YW1wbGVzIG9uIGhvdyB0 byBkbyB0aGlzKS48L3BhcmE+DQotICAgICAgICA8L3N0ZXA+DQotDQotICAgICAgICA8c3RlcD4N Ci0gICAgICAgICAgPHBhcmE+R28gYmFjayB0byB0aGUgcG9ydCBkaXJlY3RvcnkgYW5kIGRvIGEg PGNvbW1hbmQ+bWFrZSBjbGVhbjsNCi0gICAgICAgICAgICAgIG1ha2U8L2NvbW1hbmQ+IGFuZCB2 ZXJpZnkgdGhhdCB0aGUgaW5mbyBmaWxlcyBhcmUgcmVnZW5lcmF0ZWQNCi0gICAgICAgICAgICBm cm9tIHRoZSB0ZXhpbmZvIHNvdXJjZXMuIFNpbmNlIHRoZSB0ZXhpbmZvIHNvdXJjZXMgYXJlIG5l d2VyIHRoYW4NCi0gICAgICAgICAgICB0aGUgaW5mbyBmaWxlcywgdGhleSBzaG91bGQgYmUgcmVi dWlsdCB3aGVuIHlvdSB0eXBlDQotICAgICAgICAgICAgPGNvbW1hbmQ+bWFrZTwvY29tbWFuZD47 IGJ1dCBtYW55IDxmaWxlbmFtZT5NYWtlZmlsZTwvZmlsZW5hbWU+cw0KLSAgICAgICAgICAgIGRv IG5vdCBpbmNsdWRlIGNvcnJlY3QgZGVwZW5kZW5jaWVzIGZvciBpbmZvIGZpbGVzLiAgSW4NCi0g ICAgICAgICAgICA8YXBwbGljYXRpb24+RW1hY3M8L2FwcGxpY2F0aW9uPicgY2FzZSwgaXQgd2Fz IG5lY2Vzc2FyeSB0byBwYXRjaCB0aGUgbWFpbg0KLSAgICAgICAgICAgIDxmaWxlbmFtZT5NYWtl ZmlsZS5pbjwvZmlsZW5hbWU+IHNvIGl0IHdvdWxkIGRlc2NlbmQgaW50byB0aGUNCi0gICAgICAg ICAgICA8ZmlsZW5hbWU+bWFuPC9maWxlbmFtZT4gc3ViZGlyZWN0b3J5IHRvIHJlYnVpbGQgdGhl IGluZm8NCi0gICAgICAgICAgICBwYWdlcy48L3BhcmE+DQotDQotICAgICAgICAgIDxwcm9ncmFt bGlzdGluZz4tLS0gLi9NYWtlZmlsZS5pbi5vcmcgICBNb24gQXVnIDE5IDIxOjEyOjE5IDE5OTYN Ci0rKysgLi9NYWtlZmlsZS5pbiAgICAgICBUdWUgQXByIDE1IDAwOjE1OjI4IDE5OTcNCi1AQCAt MTg0LDcgKzE4NCw3IEBADQotICMgU3ViZGlyZWN0b3JpZXMgdG8gbWFrZSByZWN1cnNpdmVseS4g IGBsaXNwJyBpcyBub3QgaW5jbHVkZWQNCi0gIyBiZWNhdXNlIHRoZSBjb21waWxlZCBsaXNwIGZp bGVzIGFyZSBwYXJ0IG9mIHRoZSBkaXN0cmlidXRpb24NCi0gIyBhbmQgeW91IGNhbm5vdCByZW1h a2UgdGhlbSB3aXRob3V0IGluc3RhbGxpbmcgRW1hY3MgZmlyc3QuDQotLVNVQkRJUiA9IGxpYi1z cmMgc3JjDQotK1NVQkRJUiA9IGxpYi1zcmMgc3JjIG1hbg0KLQ0KLSAjIFRoZSBtYWtlZmlsZXMg b2YgdGhlIGRpcmVjdG9yaWVzIGluICRTVUJESVIuDQotIFNVQkRJUl9NQUtFRklMRVMgPSBsaWIt c3JjL01ha2VmaWxlIG1hbi9NYWtlZmlsZSBzcmMvTWFrZWZpbGUgb2xkWE1lbnUvTWFrZWZpbGUN Ci0gbHdsaWIvTWFrZWZpbGUNCi0tLS0gLi9tYW4vTWFrZWZpbGUuaW4ub3JnICAgICAgIFRodSBK dW4gMjcgMTU6Mjc6MTkgMTk5Ng0KLSsrKyAuL21hbi9NYWtlZmlsZS5pbiAgIFR1ZSBBcHIgMTUg MDA6Mjk6NTIgMTk5Nw0KLUBAIC02Niw2ICs2Niw3IEBADQotICR7c3JjZGlyfS9nbnUxLnRleGkg XA0KLSAke3NyY2Rpcn0vZ2xvc3NhcnkudGV4aQ0KLQ0KLSthbGw6IGluZm8NCi0gaW5mbzogJChJ TkZPX1RBUkdFVFMpDQotDQotIGR2aTogJChEVklfVEFSR0VUUyk8L3Byb2dyYW1saXN0aW5nPg0K LQ0KLSAgICAgICAgICA8cGFyYT5UaGUgc2Vjb25kIGh1bmsgd2FzIG5lY2Vzc2FyeSBiZWNhdXNl IHRoZSBkZWZhdWx0IHRhcmdldCBpbg0KLSAgICAgICAgICAgIHRoZSA8ZmlsZW5hbWU+bWFuPC9m aWxlbmFtZT4gc3ViZGlyIGlzIGNhbGxlZA0KLSAgICAgICAgICAgIDxtYWtldGFyZ2V0PmluZm88 L21ha2V0YXJnZXQ+LCB3aGlsZSB0aGUgbWFpbg0KLSAgICAgICAgICAgIDxmaWxlbmFtZT5NYWtl ZmlsZTwvZmlsZW5hbWU+IHdhbnRzIHRvIGNhbGwNCi0gICAgICAgICAgICA8bWFrZXRhcmdldD5h bGw8L21ha2V0YXJnZXQ+LiAgVGhlIGluc3RhbGxhdGlvbiBvZiB0aGUNCi0gICAgICAgICAgICA8 ZmlsZW5hbWU+aW5mbzwvZmlsZW5hbWU+IGluZm8gZmlsZSB3YXMgYWxzbyByZW1vdmVkIGJlY2F1 c2Ugd2UNCi0gICAgICAgICAgICBhbHJlYWR5IGhhdmUgb25lIHdpdGggdGhlIHNhbWUgbmFtZSBp bg0KLSAgICAgICAgICAgIDxmaWxlbmFtZT4vdXNyL3NoYXJlL2luZm88L2ZpbGVuYW1lPiAodGhh dCBwYXRjaCBpcyBub3Qgc2hvd24NCi0gICAgICAgICAgICBoZXJlKS48L3BhcmE+DQotICAgICAg ICA8L3N0ZXA+DQotDQotICAgICAgICA8c3RlcD4NCi0gICAgICAgICAgPHBhcmE+SWYgdGhlcmUg aXMgYSBwbGFjZSBpbiB0aGUgPGZpbGVuYW1lPk1ha2VmaWxlPC9maWxlbmFtZT4gdGhhdA0KLSAg ICAgICAgICAgIGlzIGluc3RhbGxpbmcgdGhlIDxmaWxlbmFtZT5kaXI8L2ZpbGVuYW1lPiBmaWxl LCBkZWxldGUgaXQuICBZb3VyDQotICAgICAgICAgICAgcG9ydCBtYXkgbm90IGJlIGRvaW5nIGl0 LiAgQWxzbywgcmVtb3ZlIGFueSBjb21tYW5kcyB0aGF0IGFyZQ0KLSAgICAgICAgICAgIG90aGVy d2lzZSBtdWNraW5nIGFyb3VuZCB3aXRoIHRoZSA8ZmlsZW5hbWU+ZGlyPC9maWxlbmFtZT4NCi0g ICAgICAgICAgICBmaWxlLjwvcGFyYT4NCi0NCi0gICAgICAgICAgPHByb2dyYW1saXN0aW5nPi0t LSAuL01ha2VmaWxlLmluLm9yZyAgIE1vbiBBdWcgMTkgMjE6MTI6MTkgMTk5Ng0KLSsrKyAuL01h a2VmaWxlLmluICAgICAgIE1vbiBBcHIgMTQgMjM6Mzg6MDcgMTk5Nw0KLUBAIC0zNjgsMTQgKzM2 OCw4IEBADQotICAgICAgICBpZiBbIGAoY2QgJHtzcmNkaXJ9L2luZm8gJiYgL2Jpbi9wd2QpYCAh PSBgKGNkICR7aW5mb2Rpcn0gJiYgL2Jpbi9wd2QpYCBdOyBcDQotICAgICAgICB0aGVuIFwNCi0g ICAgICAgICAgKGNkICR7aW5mb2Rpcn07ICBcDQotLSAgICAgICAgICBpZiBbIC1mIGRpciBdOyB0 aGVuIFwNCi0tICAgICAgICAgICAgaWYgWyAhIC1mIGRpci5vbGQgXTsgdGhlbiBtdiAtZiBkaXIg ZGlyLm9sZDsgXA0KLS0gICAgICAgICAgICBlbHNlIG12IC1mIGRpciBkaXIuYmFrOyBmaTsgXA0K LS0gICAgICAgICAgZmk7IFwNCi0gICAgICAgICAgIGNkICR7c3JjZGlyfS9pbmZvIDsgXA0KLS0g ICAgICAgICAgKGNkICQke3RoaXNkaXJ9OyAke0lOU1RBTExfREFUQX0gJHtzcmNkaXJ9L2luZm8v ZGlyICR7aW5mb2Rpcn0vZGlyKTsNCi1cDQotLSAgICAgICAgICAoY2QgJCR7dGhpc2Rpcn07IGNo bW9kIGErciAke2luZm9kaXJ9L2Rpcik7IFwNCi0gICAgICAgICAgIGZvciBmIGluIGNjbW9kZSog Y2wqIGRpcmVkLXgqIGVkaWZmKiBlbWFjcyogZm9ybXMqIGdudXMqIGluZm8qIG1lc3NhZ2UqIG1o LWUqIHNjKiB2aXAqOyBkbyBcDQotICAgICAgICAgICAgIChjZCAkJHt0aGlzZGlyfTsgXA0KLSAg ICAgICAgICAgICAgJHtJTlNUQUxMX0RBVEF9ICR7c3JjZGlyfS9pbmZvLyQkZiAke2luZm9kaXJ9 LyQkZjsgXA0KLSAgICAgICAgICAgICAgY2htb2QgYStyICR7aW5mb2Rpcn0vJCRmKTsgXDwvcHJv Z3JhbWxpc3Rpbmc+DQotICAgICAgICA8L3N0ZXA+DQotDQotICAgICAgICA8c3RlcD4NCi0gICAg ICAgICAgPHBhcmE+KFRoaXMgc3RlcCBpcyBvbmx5IG5lY2Vzc2FyeSBpZiB5b3UgYXJlIG1vZGlm eWluZyBhbiBleGlzdGluZw0KLSAgICAgICAgICAgIHBvcnQuKSBUYWtlIGEgbG9vayBhdCA8Zmls ZW5hbWU+cGtnLXBsaXN0PC9maWxlbmFtZT4gYW5kIGRlbGV0ZQ0KLSAgICAgICAgICAgIGFueXRo aW5nIHRoYXQgaXMgdHJ5aW5nIHRvIHBhdGNoIHVwIDxmaWxlbmFtZT5pbmZvL2RpcjwvZmlsZW5h bWU+Lg0KLSAgICAgICAgICAgIFRoZXkgbWF5IGJlIGluIDxmaWxlbmFtZT5wa2ctaW5zdGFsbDwv ZmlsZW5hbWU+IG9yIHNvbWUgb3RoZXINCi0gICAgICAgICAgICBmaWxlLCBzbyBzZWFyY2ggZXh0 ZW5zaXZlbHkuPC9wYXJhPg0KLQ0KLSAgICAgICAgICA8cHJvZ3JhbWxpc3Rpbmc+SW5kZXg6IHBr Zy1wbGlzdA0KLT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCi1SQ1MgZmlsZTogL3Vzci9jdnMvcG9ydHMvZWRpdG9ycy9l bWFjcy9wa2ctcGxpc3Qsdg0KLXJldHJpZXZpbmcgcmV2aXNpb24gMS4xNQ0KLWRpZmYgLXUgLXIx LjE1IHBrZy1wbGlzdA0KLS0tLSBwa2ctcGxpc3QgICAgICAgMTk5Ny8wMy8wNCAwODowNDowMCAg ICAgMS4xNQ0KLSsrKyBwa2ctcGxpc3QgICAgICAgMTk5Ny8wNC8xNSAwNjozMjoxMg0KLUBAIC0x NSw5ICsxNSw2IEBADQotIG1hbi9tYW4xL2VtYWNzLjEuZ3oNCi0gbWFuL21hbjEvZXRhZ3MuMS5n eg0KLSBtYW4vbWFuMS9jdGFncy4xLmd6DQotLUB1bmV4ZWMgY3AgJUQvaW5mby9kaXIgJUQvaW5m by9kaXIuYmFrDQotLWluZm8vZGlyDQotLUB1bmV4ZWMgY3AgJUQvaW5mby9kaXIuYmFrICVEL2lu Zm8vZGlyDQotIGluZm8vY2wNCi0gaW5mby9jbC0xDQotIGluZm8vY2wtMjwvcHJvZ3JhbWxpc3Rp bmc+DQotICAgICAgICA8L3N0ZXA+DQotDQotICAgICAgICA8c3RlcD4NCi0gICAgICAgICAgPHBh cmE+QWRkIGEgPG1ha2V0YXJnZXQ+cG9zdC1pbnN0YWxsPC9tYWtldGFyZ2V0PiB0YXJnZXQgdG8g dGhlDQotICAgICAgICAgICAgPGZpbGVuYW1lPk1ha2VmaWxlPC9maWxlbmFtZT4gdG8gY2FsbA0K LSAgICAgICAgICAgIDxtYWtldGFyZ2V0Pmluc3RhbGwtaW5mbzwvbWFrZXRhcmdldD4gd2l0aCB0 aGUgaW5zdGFsbGVkDQotICAgICAgICAgICAgaW5mbyBmaWxlcy4gIChJdCBpcyBubyBsb25nZXIg bmVjZXNzYXJ5IHRvIGNyZWF0ZSB0aGUNCi0gICAgICAgICAgICA8ZmlsZW5hbWU+ZGlyPC9maWxl bmFtZT4gZmlsZSB5b3Vyc2VsZjsNCi0gICAgICAgICAgICA8Y29tbWFuZD5pbnN0YWxsLWluZm88 L2NvbW1hbmQ+IGF1dG9tYXRpY2FsbHkgY3JlYXRlcyB0aGlzDQotICAgICAgICAgICAgZmlsZSBp ZiBpdCBkb2VzIG5vdCBleGlzdC4pPC9wYXJhPg0KLQ0KLSAgICAgICAgICA8cHJvZ3JhbWxpc3Rp bmc+SW5kZXg6IE1ha2VmaWxlDQotPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLVJDUyBmaWxlOiAvdXNyL2N2cy9wb3J0 cy9lZGl0b3JzL2VtYWNzL01ha2VmaWxlLHYNCi1yZXRyaWV2aW5nIHJldmlzaW9uIDEuMjYNCi1k aWZmIC11IC1yMS4yNiBNYWtlZmlsZQ0KLS0tLSBNYWtlZmlsZSAgICAxOTk2LzExLzE5IDEzOjE0 OjQwICAgICAxLjI2DQotKysrIE1ha2VmaWxlICAgIDE5OTcvMDUvMjAgMTA6MjU6MDkgICAgIDEu MjgNCi1AQCAtMjAsNSArMjAsOCBAQA0KLSBwb3N0LWluc3RhbGw6DQotIC5mb3IgZmlsZSBpbiBl bWFjcy0xOS4zNCBlbWFjc2NsaWVudCBldGFncyBjdGFncyBiMm0NCi0gICAgICAgIHN0cmlwICR7 UFJFRklYfS9iaW4vJHtmaWxlfQ0KLSAuZW5kZm9yDQotKy5mb3IgaW5mbyBpbiBlbWFjcyB2aXAg dmlwZXIgZm9ybXMgZ251cyBtaC1lIGNsIHNjIGRpcmVkLXggZWRpZmYgY2Ntb2RlDQotKyAgICAg ICBpbnN0YWxsLWluZm8gJHtQUkVGSVh9L2luZm8vJHtpbmZvfSAke1BSRUZJWH0vaW5mby9kaXIN Ci0rLmVuZGZvcg0KLQ0KLSAuaW5jbHVkZSAmbHQ7YnNkLnBvcnQubWsmZ3Q7PC9wcm9ncmFtbGlz dGluZz4NCi0gICAgICAgIDwvc3RlcD4NCi0NCi0gICAgICAgIDxzdGVwPg0KLSAgICAgICAgICA8 cGFyYT5FZGl0IDxmaWxlbmFtZT5wa2ctcGxpc3Q8L2ZpbGVuYW1lPiBhbmQgYWRkIGVxdWl2YWxl bnQNCi0gICAgICAgICAgICA8bGl0ZXJhbD5AZXhlYzwvbGl0ZXJhbD4gc3RhdGVtZW50cyBhbmQg YWxzbw0KLSAgICAgICAgICAgIDxsaXRlcmFsPkB1bmV4ZWM8L2xpdGVyYWw+IGZvcg0KLSAgICAg ICAgICAgIDxjb21tYW5kPnBrZ19kZWxldGU8L2NvbW1hbmQ+LjwvcGFyYT4NCi0NCi0gICAgICAg ICAgPHByb2dyYW1saXN0aW5nPkluZGV4OiBwa2ctcGxpc3QNCi09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotUkNTIGZp bGU6IC91c3IvY3ZzL3BvcnRzL2VkaXRvcnMvZW1hY3MvcGtnLXBsaXN0LHYNCi1yZXRyaWV2aW5n IHJldmlzaW9uIDEuMTUNCi1kaWZmIC11IC1yMS4xNSBwa2ctcGxpc3QNCi0tLS0gcGtnLXBsaXN0 ICAgICAgIDE5OTcvMDMvMDQgMDg6MDQ6MDAgICAgIDEuMTUNCi0rKysgcGtnLXBsaXN0ICAgICAg IDE5OTcvMDUvMjAgMTA6MjU6MTIgICAgIDEuMTcNCi1AQCAtMTYsNyArMTQsMTQgQEANCi0gbWFu L21hbjEvZXRhZ3MuMS5neg0KLSBtYW4vbWFuMS9jdGFncy4xLmd6DQotK0B1bmV4ZWMgaW5zdGFs bC1pbmZvIC0tZGVsZXRlICVEL2luZm8vZW1hY3MgJUQvaW5mby9kaXINCi0gOg0KLStAdW5leGVj IGluc3RhbGwtaW5mbyAtLWRlbGV0ZSAlRC9pbmZvL2NjbW9kZSAlRC9pbmZvL2Rpcg0KLSBpbmZv L2NsDQotIGluZm8vY2wtMQ0KLUBAIC04Nyw2ICs5NCwxOCBAQA0KLSBpbmZvL3ZpcGVyLTMNCi0g aW5mby92aXBlci00DQotK0BleGVjIGluc3RhbGwtaW5mbyAlRC9pbmZvL2VtYWNzICVEL2luZm8v ZGlyDQotIDoNCi0rQGV4ZWMgaW5zdGFsbC1pbmZvICVEL2luZm8vY2Ntb2RlICVEL2luZm8vZGly DQotIGxpYmV4ZWMvZW1hY3MvMTkuMzQvaTM4Ni0tZnJlZWJzZC9jdnRtYWlsDQotIGxpYmV4ZWMv ZW1hY3MvMTkuMzQvaTM4Ni0tZnJlZWJzZC9kaWdlc3QtZG9jPC9wcm9ncmFtbGlzdGluZz4NCi0N Ci0gICAgICAgICAgPG5vdGU+DQotICAgICAgICAgICAgPHBhcmE+VGhlIDxsaXRlcmFsPkB1bmV4 ZWMgaW5zdGFsbC1pbmZvIC0tZGVsZXRlPC9saXRlcmFsPg0KLSAgICAgICAgICAgICAgY29tbWFu ZHMgaGF2ZSB0byBiZSBsaXN0ZWQgYmVmb3JlIHRoZSBpbmZvIGZpbGVzIHRoZW1zZWx2ZXMgc28N Ci0gICAgICAgICAgICAgIHRoZXkgY2FuIHJlYWQgdGhlIGZpbGVzLiBBbHNvLCB0aGUgPGxpdGVy YWw+QGV4ZWMNCi0gICAgICAgICAgICAgICAgaW5zdGFsbC1pbmZvPC9saXRlcmFsPiBjb21tYW5k cyBoYXZlIHRvIGJlIGFmdGVyIHRoZSBpbmZvDQotICAgICAgICAgICAgICBmaWxlcyBhbmQgdGhl IDxsaXRlcmFsPkBleGVjPC9saXRlcmFsPiBjb21tYW5kIHRoYXQgY3JlYXRlcyB0aGUNCi0gICAg ICAgICAgICAgIHRoZSA8ZmlsZW5hbWU+ZGlyPC9maWxlbmFtZT4gZmlsZS48L3BhcmE+DQotICAg ICAgICAgIDwvbm90ZT4NCi0gICAgICAgIDwvc3RlcD4NCi0NCi0gICAgICAgIDxzdGVwPg0KLSAg ICAgICAgICA8cGFyYT48bGluayBsaW5rZW5kPSJwb3J0aW5nLXRlc3RpbmciPlRlc3Q8L2xpbms+ IGFuZCBhZG1pcmUgeW91cg0KLSAgICAgICAgICAgIHdvcmsuICA8IS0tIHNtaWxleSAtLT48ZW1w aGFzaXM+Oi0pPC9lbXBoYXNpcz4uICBDaGVjayB0aGUNCi0gICAgICAgICAgICA8ZmlsZW5hbWU+ ZGlyPC9maWxlbmFtZT4gZmlsZSBiZWZvcmUgYW5kIGFmdGVyIGVhY2ggc3RlcC48L3BhcmE+DQot ICAgICAgICA8L3N0ZXA+DQotICAgICAgPC9wcm9jZWR1cmU+DQorICAgICAgPHBhcmE+SWYgeW91 ciBwYWNrYWdlIG5lZWRzIHRvIGluc3RhbGwgR05VIGluZm8gZmlsZXMsIHRoZXkgc2hvdWxkIGJl DQorICAgICAgICBsaXN0ZWQgaW4gdGhlIDxtYWtldmFyPklORk88L21ha2V2YXI+IHZhcmlhYmxl ICh3aXRob3V0IHRoZSB0cmFpbGluZyANCisgICAgICAgIDxsaXRlcmFsPi5pbmZvPC9saXRlcmFs PiksIGFuZCBhcHByb3ByaWF0ZSBpbnN0YWxsYXRpb24vZGVpbnN0YWxsYXRpb24NCisgICAgICAg IGNvZGUgd2lsbCBiZSBhdXRvbWF0aWNhbHkgYWRkZWQgdG8gdGhlIHRlbXBvcmFyeQ0KKyAgICAg ICAgPGZpbGVuYW1lPnBrZy1wbGlzdDwvZmlsZW5hbWU+IGJlZm9yZSBwYWNrYWdlIHJlZ2lzdHJh dGlvbi48L3BhcmE+DQogICAgIDwvY2hhcHRlcj4NCiANCiAgICAgPGNoYXB0ZXIgaWQ9InBrZy1m aWxlcyI+DQpAQCAtNDMxNiw2ICs0MDg2LDE5IEBADQogICAgICAgICA8L25vdGU+DQogICAgICAg PC9zZWN0MT4NCiANCisgICAgICA8c2VjdDEgaWQ9InBrZy1kZWluc3RhbGwiPg0KKyAgICAgICAg PHRpdGxlPjxmaWxlbmFtZT5wa2ctZGVpbnN0YWxsPC9maWxlbmFtZT48L3RpdGxlPg0KKw0KKyAg ICAgICAgPHBhcmE+VGhpcyBzY3JpcHQgZXhlY3V0ZXMgd2hlbiBhIHBhY2thZ2UgaXMgcmVtb3Zl ZC48L3BhcmE+DQorDQorICAgICAgICA8cGFyYT4NCisgICAgICAgICAgVGhpcyBzY3JpcHQgd2ls bCBiZSBydW4gdHdpY2UgYnkgPGNvbW1hbmQ+cGtnX2RlbGV0ZTwvY29tbWFuZD4uDQorICAgICAg ICAgIFRoZSBmaXJzdCB0aW1lIGFzIDxsaXRlcmFsPiZkb2xsYXI7e1NIfSBwa2ctaW5zdGFsbCAm ZG9sbGFyO3tQS0dOQU1FfQ0KKyAgICAgICAgICBERUlOU1RBTEw8L2xpdGVyYWw+IGFuZCB0aGUg c2Vjb25kIHRpbWUgYXMNCisgICAgICAgICAgPGxpdGVyYWw+JmRvbGxhcjt7U0h9IHBrZy1pbnN0 YWxsICZkb2xsYXI7e1BLR05BTUV9IFBPU1QtREVJTlNUQUxMPC9saXRlcmFsPi4NCisgICAgICAg IDwvcGFyYT4NCisgICAgICA8L3NlY3QxPg0KKw0KICAgICAgIDxzZWN0MSBpZD0icGtnLXJlcSI+ DQogICAgICAgICA8dGl0bGU+PGZpbGVuYW1lPnBrZy1yZXE8L2ZpbGVuYW1lPjwvdGl0bGU+DQog DQpAQCAtNDM3MiwxMyArNDE1NSwxMyBAQA0KIA0KICAgICAgICAgPHBhcmE+VGhpcyBzdWJzdGl0 dXRpb24gKGFzIHdlbGwgYXMgYWRkaXRpb24gb2YgYW55IDxsaW5rDQogICAgICAgICAgIGxpbmtl bmQ9InBvcnRpbmctbWFucGFnZXMiPm1hbnVhbCBwYWdlczwvbGluaz4pIHdpbGwgYmUgZG9uZSBi ZXR3ZWVuDQotICAgICAgICAgIHRoZSA8bWFrZXRhcmdldD5kby1pbnN0YWxsPC9tYWtldGFyZ2V0 PiBhbmQNCi0gICAgICAgICAgPG1ha2V0YXJnZXQ+cG9zdC1pbnN0YWxsPC9tYWtldGFyZ2V0PiB0 YXJnZXRzLCBieSByZWFkaW5nIGZyb20NCisgICAgICAgICAgdGhlIDxtYWtldGFyZ2V0PnByZS1p bnN0YWxsPC9tYWtldGFyZ2V0PiBhbmQNCisgICAgICAgICAgPG1ha2V0YXJnZXQ+ZG8taW5zdGFs bDwvbWFrZXRhcmdldD4gdGFyZ2V0cywgYnkgcmVhZGluZyBmcm9tDQogICAgICAgICAgIDxtYWtl dmFyPlBMSVNUPC9tYWtldmFyPiBhbmQgd3JpdGluZyB0byA8bWFrZXZhcj5UTVBQTElTVDwvbWFr ZXZhcj4NCiAgICAgICAgICAgKGRlZmF1bHQ6DQogICAgICAgICAgIDxmaWxlbmFtZT48bWFrZXZh cj5XUktESVI8L21ha2V2YXI+Ly5QTElTVC5ta3RtcDwvZmlsZW5hbWU+KS4gIFNvIGlmDQogICAg ICAgICAgIHlvdXIgcG9ydCBidWlsZHMgPG1ha2V2YXI+UExJU1Q8L21ha2V2YXI+IG9uIHRoZSBm bHksIGRvIHNvIGluIG9yDQotICAgICAgICAgIGJlZm9yZSA8bWFrZXRhcmdldD5kby1pbnN0YWxs PC9tYWtldGFyZ2V0Pi4gIEFsc28sIGlmIHlvdXIgcG9ydA0KKyAgICAgICAgICBiZWZvcmUgPG1h a2V0YXJnZXQ+cHJlLWluc3RhbGw8L21ha2V0YXJnZXQ+LiAgQWxzbywgaWYgeW91ciBwb3J0DQog ICAgICAgICAgIG5lZWRzIHRvIGVkaXQgdGhlIHJlc3VsdGluZyBmaWxlLCBkbyBzbyBpbg0KICAg ICAgICAgICA8bWFrZXRhcmdldD5wb3N0LWluc3RhbGw8L21ha2V0YXJnZXQ+IHRvIGEgZmlsZSBu YW1lZA0KICAgICAgICAgICA8bWFrZXZhcj5UTVBQTElTVDwvbWFrZXZhcj4uPC9wYXJhPg0KQEAg LTQ0MjQsNiArNDIwNywxMSBAQA0KICAgICAgICAgICAgICAgPHJvdz4NCiAgICAgICAgICAgICAg ICAgPGVudHJ5PjxtYWtldmFyPlBLR0lOU1RBTEw8L21ha2V2YXI+PC9lbnRyeT4NCiAgICAgICAg ICAgICAgICAgPGVudHJ5PjxsaXRlcmFsPiR7UEtHRElSfS9wa2ctaW5zdGFsbDwvbGl0ZXJhbD48 L2VudHJ5Pg0KKyAgICAgICAgICAgICAgPC9yb3c+DQorDQorICAgICAgICAgICAgICA8cm93Pg0K KyAgICAgICAgICAgICAgICA8ZW50cnk+PG1ha2V2YXI+UEtHREVJTlNUQUxMPC9tYWtldmFyPjwv ZW50cnk+DQorICAgICAgICAgICAgICAgIDxlbnRyeT48bGl0ZXJhbD4ke1BLR0RJUn0vcGtnLWRl aW5zdGFsbDwvbGl0ZXJhbD48L2VudHJ5Pg0KICAgICAgICAgICAgICAgPC9yb3c+DQogDQogICAg ICAgICAgICAgICA8cm93Pg0K --=-XjMH+zKJcsrxCMtIZoSB-- --=-bVOYxQNmwR/EewMoyzKa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQA/P5V2b2iPiv4Uz4cRAhfpAJ4n2BYmmr8A7ovea17LiXu9wZNq9wCfajEW JS0pAixVfzzP7WrEfMdlpoU= =lNEV -----END PGP SIGNATURE----- --=-bVOYxQNmwR/EewMoyzKa-- From owner-freebsd-doc@FreeBSD.ORG Sun Aug 17 11:21:23 2003 Return-Path: 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 809DC37B409; Sun, 17 Aug 2003 11:21:23 -0700 (PDT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE7FA43FA3; Sun, 17 Aug 2003 11:21:22 -0700 (PDT) (envelope-from linimon@lonesome.com) Received: from lonesome.lonesome.com (cs242746-11.austin.rr.com [24.27.46.11]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.soaustin.net (Postfix) with ESMTP id 1C079142F9; Sun, 17 Aug 2003 13:21:16 -0500 (CDT) From: Mark Linimon Organization: Lonesome Dove Computing Services To: Joe Marcus Clarke , "Simon L. Nielsen" Date: Sun, 17 Aug 2003 13:26:45 -0500 User-Agent: KMail/1.5.2 References: <1061069299.54862.34.camel@shumai.marcuscom.com> <20030817110722.GA391@FreeBSD.org> <1061131638.43833.2.camel@shumai.marcuscom.com> In-Reply-To: <1061131638.43833.2.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308171326.45898.linimon@lonesome.com> cc: freebsd-doc@FreeBSD.org Subject: Re: Review of porters-handbook changes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 18:21:24 -0000 > I tried to preserve the style of adjacent blocks. To that end, some use > spaces, so I opted for spaces to keep things lined up. I did the same with my patches. At some point when all this stuff gets committed I'll volunteer to do a whitespace diff on the thing at which time we can settle on the Right Way and not confuse future contributors. mcl From owner-freebsd-doc@FreeBSD.ORG Sun Aug 17 15:26:44 2003 Return-Path: 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 3059A37B401; Sun, 17 Aug 2003 15:26:44 -0700 (PDT) Received: from hueymiccailhuitl.mtu.ru (hueytecuilhuitl.mtu.ru [195.34.32.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F2D843F93; Sun, 17 Aug 2003 15:26:43 -0700 (PDT) (envelope-from sem@ciam.ru) Received: from ciam.ru (ppp138-245.dialup.mtu-net.ru [62.118.138.245]) by hueymiccailhuitl.mtu.ru (Postfix) with ESMTP id 644E7D4AB6; Mon, 18 Aug 2003 02:26:41 +0400 (MSD) (envelope-from sem@ciam.ru) Message-ID: <3F400126.8040608@ciam.ru> Date: Mon, 18 Aug 2003 02:26:46 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.3) Gecko/20030309 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: freebsd-doc@FreeBSD.org, simon@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Review of porters-handbook changes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2003 22:26:44 -0000 Simon L. Nielsen wrote: > There are some places where 8 spaces have been used instead of a tab > (can be fixed by marking the regions and using 'meta-x tabify' in > emacs'). I use vim :) OK. I know how to do it with vim. > Otherwise it looks OK to me, but I have only checked the markup, not the > language. Could somebody to fix it and commit? Or I have to do it as submitter? If so, I'll add two variables description. The language was checked by Joe Marcus Clarke. ---- Sem. From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 02:10:09 2003 Return-Path: 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 7E0CB37B401 for ; Mon, 18 Aug 2003 02:10:09 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CCA643F3F for ; Mon, 18 Aug 2003 02:10:09 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7I9A8Up076050 for ; Mon, 18 Aug 2003 02:10:08 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7I9A8IO076049; Mon, 18 Aug 2003 02:10:08 -0700 (PDT) Date: Mon, 18 Aug 2003 02:10:08 -0700 (PDT) Message-Id: <200308180910.h7I9A8IO076049@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Tony Maher Subject: Re: docs/55653: chflags.1 - note that not all tools chflags aware. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Tony Maher List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 09:10:09 -0000 The following reply was made to PR docs/55653; it has been noted by GNATS. From: Tony Maher To: tonymaher@optushome.com.au, underway@comcast.net Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: docs/55653: chflags.1 - note that not all tools chflags aware. Date: Mon, 18 Aug 2003 19:00:45 +1000 (EST) Hello, thanks for feedback. >> +.Sh BUGS > > The warning note would be better placed in a custom WARNING (or NOTES) > section, or in a standard COMPATIBILITY section or even in the > DESCRIPTION. It's not about a chflags(1) bug. The fact that other > manpages abuse their BUGS section is no reason for this one to do it. I agree but the example man pages I looked at used bugs. But I dont care how its done, I'll leave it up to a docs person. > It's debatable whether any of these tools/utilities/programs should be > listed in the manpage, mainly because it adds a continual source of > manpage bugs as file flags and their support changes from time to > time. Also, the info would, to be consistent, need to be added to > chflags(2) and other manpages that deal with file flags. > > I tend to like helpful manpages, but in this case I think it's better > to limit that help to the generic warning note and put these lists of > programs in a Handbook "File Flags" section, if anywhere. I prefer man pages since they are more accessible. I liked the info all in the once place so that someone reading about chflags would immediately be aware that there could be problems using copy mecahnisms like tar and pax. That said I am happy for whatever the docs people decide matches best with FreeBSD docs practice. > Also: The tar(1) and pax(1) manpages should say in their BUGS sections > that they don't support file flags, if that's the case. That would be useful. cheers -- tonym From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 02:47:00 2003 Return-Path: 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 CED3B37B401; Mon, 18 Aug 2003 02:47:00 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C87743F85; Mon, 18 Aug 2003 02:47:00 -0700 (PDT) (envelope-from blackend@FreeBSD.org) Received: from freefall.freebsd.org (blackend@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7I9l0Up077582; Mon, 18 Aug 2003 02:47:00 -0700 (PDT) (envelope-from blackend@freefall.freebsd.org) Received: (from blackend@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7I9l0w4077576; Mon, 18 Aug 2003 02:47:00 -0700 (PDT) Date: Mon, 18 Aug 2003 02:47:00 -0700 (PDT) From: Marc Fonvieille Message-Id: <200308180947.h7I9l0w4077576@freefall.freebsd.org> To: blackend@FreeBSD.org, freebsd-doc@FreeBSD.org, blackend@FreeBSD.org Subject: Re: docs/55652: handbook addition: installing linux MATLAB X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 09:47:01 -0000 Synopsis: handbook addition: installing linux MATLAB Responsible-Changed-From-To: freebsd-doc->blackend Responsible-Changed-By: blackend Responsible-Changed-When: Mon Aug 18 02:45:47 PDT 2003 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=55652 From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 05:40:17 2003 Return-Path: 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 982CA37B404 for ; Mon, 18 Aug 2003 05:40:17 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7890443FA3 for ; Mon, 18 Aug 2003 05:40:16 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7ICeGUp098788 for ; Mon, 18 Aug 2003 05:40:16 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7ICeGTw098787; Mon, 18 Aug 2003 05:40:16 -0700 (PDT) Resent-Date: Mon, 18 Aug 2003 05:40:16 -0700 (PDT) Resent-Message-Id: <200308181240.h7ICeGTw098787@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, Søren Straarup Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 321EE37B401 for ; Mon, 18 Aug 2003 05:32:52 -0700 (PDT) Received: from x12.dk (xforce.dk [80.164.11.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id B61E443FAF for ; Mon, 18 Aug 2003 05:32:50 -0700 (PDT) (envelope-from xride@x12.dk) Received: from x12.dk (xride@localhost [127.0.0.1]) by x12.dk (8.12.9/8.12.9) with ESMTP id h7ICWm3Y095525 for ; Mon, 18 Aug 2003 14:32:48 +0200 (CEST) (envelope-from xride@x12.dk) Received: (from xride@localhost) by x12.dk (8.12.9/8.12.9/Submit) id h7ICWmgm095524; Mon, 18 Aug 2003 14:32:48 +0200 (CEST) Message-Id: <200308181232.h7ICWmgm095524@x12.dk> Date: Mon, 18 Aug 2003 14:32:48 +0200 (CEST) From: Søren Straarup To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/55693: Howto make a kernel module for a pseudo-device under 5.X X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Søren Straarup List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 12:40:18 -0000 >Number: 55693 >Category: docs >Synopsis: Howto make a kernel module for a pseudo-device under 5.X >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Mon Aug 18 05:40:15 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Xride >Release: FreeBSD 5.1-CURRENT i386 >Organization: >Environment: Changed the pseudo-device kernel module code, from the arch-handbook, so it will work under 5.X. --- chapter.diff begins here --- --- /usr/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics/chapter.sgml Thu Aug 7 01:48:02 2003 +++ chapter.sgml Mon Aug 18 13:42:46 2003 @@ -335,6 +335,168 @@ DEV_MODULE(echo,echo_loader,NULL); + For the 5.X serie this is how the code for the pseudo-device + should look: + +/* + * Simple `echo' pseudo-device KLD + * + * Murray Stokely + */ + +/* + * Conveted to 5.X by S&oring;ren (Xride) Straarup + */ + + +#include <sys/types.h> +#include <sys/module.h> +#include <sys/systm.h> /* uprintf */ +#include <sys/errno.h> +#include <sys/param.h> /* defines used in kernel.h */ +#include <sys/kernel.h> /* types used in module initialization */ +#include <sys/conf.h> /* cdevsw struct */ +#include <sys/uio.h> /* uio struct */ +#include <sys/malloc.h> + +#define BUFFERSIZE 256 +#define CDEV_MAJOR 33 + +/* Function prototypes */ +static d_open_t echo_open; +static d_close_t echo_close; +static d_read_t echo_read; +static d_write_t echo_write; + +/* Character device entry points */ +static struct cdevsw echo_cdevsw = { + .d_open = echo_open, + .d_close = echo_close, + .d_maj = CDEV_MAJOR, + .d_name = "echo", + .d_read = echo_read, + .d_write = echo_write +}; + +typedef struct s_echo { + char msg[BUFFERSIZE]; + int len; +} t_echo; + +/* vars */ +static dev_t echo_dev; +static int count; +static t_echo *echomsg; +static int len; + + +MALLOC_DECLARE(M_ECHOBUF); +MALLOC_DEFINE(M_ECHOBUF, "echobuffer", "buffer for echo module"); + +/* + * This function acts is called by the kld[un]load(2) system calls to + * determine what actions to take when a module is loaded or unloaded. + */ + +static int +echo_loader(struct module *m, int what, void *arg) +{ + int err = 0; + + switch (what) { + case MOD_LOAD: /* kldload */ + echo_dev = make_dev(&echo_cdevsw, + 0, + UID_ROOT, + GID_WHEEL, + 0600, + "echo"); + /* kmalloc memory for use by this driver */ + /* malloc(256,M_ECHOBUF,M_WAITOK); */ + MALLOC(echomsg, t_echo *, sizeof(t_echo), M_ECHOBUF, M_WAITOK); + printf("Echo device loaded.\n"); + break; + case MOD_UNLOAD: + destroy_dev(echo_dev); + FREE(echomsg,M_ECHOBUF); + printf("Echo device unloaded.\n"); + break; + default: + err = EINVAL; + break; + } + return(err); +} + +static int +echo_open(dev_t dev, int oflags, int devtype, struct thread *p) +{ + int err = 0; + + uprintf("Opened device \"echo\" successfully.\n"); + return(err); +} + +static int +echo_close(dev_t dev, int fflag, int devtype, struct thread *p) +{ + uprintf("Closing device \"echo.\"\n"); + return(0); +} + +/* + * The read function just takes the buf that was saved via + * echo_write() and returns it to userland for accessing. + * uio(9) + */ + +static int +echo_read(dev_t dev, struct uio *uio, int ioflag) +{ + int err = 0; + int amt; + + /* How big is this read operation? Either as big as the user wants, + or as big as the remaining data */ + amt = MIN(uio->uio_resid, (echomsg->len - uio->uio_offset > 0) ? echomsg->l +en - uio->uio_offset : 0); + if ((err = uiomove(echomsg->msg + uio->uio_offset,amt,uio)) != 0) { + uprintf("uiomove failed!\n"); + } + + return err; +} + +/* + * echo_write takes in a character string and saves it + * to buf for later accessing. + */ + +static int +echo_write(dev_t dev, struct uio *uio, int ioflag) +{ + int err = 0; + + /* Copy the string in from user memory to kernel memory */ + err = copyin(uio->uio_iov->iov_base, echomsg->msg, MIN(uio->uio_iov->iov_le +n,BUFFERSIZE)); + + /* Now we need to null terminate */ + *(echomsg->msg + MIN(uio->uio_iov->iov_len,BUFFERSIZE)) = 0; + /* Record the length */ + echomsg->len = MIN(uio->uio_iov->iov_len,BUFFERSIZE); + + if (err != 0) { + uprintf("Write failed: bad address!\n"); + } + + count++; + return(err); +} + +DEV_MODULE(echo,echo_loader,NULL); + + To install this driver you will first need to make a node on your filesystem with a command such as: --- chapter.diff ends here --- >Description: >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 06:50:28 2003 Return-Path: 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 0E6FB37B42C; Mon, 18 Aug 2003 06:50:20 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D4BC440F5; Mon, 18 Aug 2003 05:53:46 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 9D84610BFA8; Mon, 18 Aug 2003 14:53:44 +0200 (CEST) Date: Mon, 18 Aug 2003 14:53:44 +0200 From: "Simon L. Nielsen" To: Joe Marcus Clarke Message-ID: <20030818125337.GB407@FreeBSD.org> References: <1061069299.54862.34.camel@shumai.marcuscom.com> <20030817110722.GA391@FreeBSD.org> <1061131638.43833.2.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <1061131638.43833.2.camel@shumai.marcuscom.com> User-Agent: Mutt/1.5.4i cc: freebsd-doc@FreeBSD.org Subject: Re: Review of porters-handbook changes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 13:50:30 -0000 --VrqPEDrXMn8OVzN4 Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.08.17 10:47:18 -0400, Joe Marcus Clarke wrote: > On Sun, 2003-08-17 at 07:07, Simon L. Nielsen wrote: > > On 2003.08.16 17:28:19 -0400, Joe Marcus Clarke wrote: > > > Can someone review the attached diff to the porter's handbook? It was > > > submitted by Sergey Matveychuk for some of the recent > > > ports infrastructure changes. It is technically accurate, and I fixe= d a > > > few grammar and spelling nits, but I would like a doc committers take= on > > > it before committing. Also, if one of you would rather commit, that's > > > fine. Thanks! > >=20 > > There are some places where 8 spaces have been used instead of a tab > > (can be fixed by marking the regions and using 'meta-x tabify' in > > emacs'). There are also some end of line white-spaces which should be > > removed. >=20 > I tried to preserve the style of adjacent blocks. To that end, some use > spaces, so I opted for spaces to keep things lined up. OK, I didn't check the rest for the file for style, and the tab/space thing is not that important then. But the end of line whitespace still doesn't need to be there :). It's not crucial to remove it, but there is no reason to have it there. Sorry for being so pedantic about this... I have attached a patch where I have removed the end of line whitespace, and changed the pkg_deinstall reference (see below). > --- doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 17 Aug 2003 09:1= 2:05 -0000 1.320 > +++ doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 17 Aug 2003 14:4= 6:25 -0000 > @@ -4316,6 +4086,19 @@ > > > =20 > + > + <filename>pkg-deinstall</filename> > + > + This script executes when a package is removed. > + > + > + This script will be run twice by pkg_delete. It's better to use "&man.pkg.delete.1;" instead of the command tag since it will create a link to the manual page. --=20 Simon L. Nielsen FreeBSD Documentation Team --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="book.sgml-sln.diff" Content-Transfer-Encoding: quoted-printable --- doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 17 Aug 2003 09:12:= 05 -0000 1.320 +++ doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 17 Aug 2003 14:46:= 25 -0000 @@ -3019,6 +3019,19 @@ =20 + + <makevar>CONFLICTS</makevar> + + If your package cannot coexist with other packages + (because of file conflicts, runtime incompatibility, etc.), + list the other package names in the CONFLICTS + variable. You can use shell globs like * and + ? here. Packages names should be + enumerated the same way they appear in + /var/db/pkg. + + + Building mechanisms =20 @@ -3216,11 +3229,24 @@ =20 Says that the port uses Perl 5 to build and run. - =20 + - PERL + PERL_CONFIGURE + + Configure using Perl's MakeMaker. It implies + USE_PERL5. - =20 + + + + + + + Read only variables + + + + PERL_VERSION =20 @@ -4003,267 +4029,11 @@ Info files =20 - The new version of texinfo (included in 2.2.2-RELEASE and onwa= rd) - contains a utility called install-info to add a= nd - delete entries to the dir file. If your port - installs any info documents, please follow these instructions so y= our - port/package will correctly update the user's - PREFIX/info/dir file. (So= rry - for the length of this section, but is it imperative to weave all = the - info files together. If done correctly, it will produce a - beautiful listing, so please bear with me!) - - First, this is what you (as a porter) need to know: - - &prompt.user; install-info --help -install-info [OPTION]... [INFO-FILE [DIR-FILE]] - Install INFO-FILE in the Info directory file DIR-FILE. - -Options: ---delete Delete existing entries in INFO-FILE; - don't insert any new entries. - : ---entry=3DTEXT Insert TEXT as an Info directory entry. - : ---section=3DSEC Put this file's entries in section SEC of the director= y. : - - - This program will not actually install = info - files; it merely inserts or deletes entries in the - dir file. - - - Here's a seven-step procedure to convert ports to use - install-info. - editors/emacs will be used a= s an - example. - - - - Look at the texinfo sources and make a patch to insert - @dircategory and @direntry - statements to files that do not have them. This is part of my - patch: - - --- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 -+++ ./man/vip.texi Tue May 20 01:28:33 1997 -@@ -2,6 +2,10 @@ - - @setfilename ../info/vip - @settitle VIP -+@dircategory The Emacs editor and associated tools -+@direntry -+* VIP: (vip). A VI-emulation for Emacs. -+@end direntry - - @iftex - @finalout - : - - The format should be self-explanatory. Many authors leave= a - dir file in the source tree that contains= all - the entries you need, so look around before you try to write y= our - own. Also, make sure you look into related ports and make the - section names and entry indentations consistent (we recommend = that - all entry text start at the 4th tab stop). - - - Note that you can put only one info entry per file becau= se - of a bug in install-info --delete that - deletes only the first entry if you specify multiple entries= in - the @direntry section. - - - You can give the dir entries to - install-info as arguments - ( and ) inst= ead - of patching the texinfo sources. This probably is not a good - idea for ports because you need to duplicate the same informat= ion - in three places - (Makefile and - @exec/@unexec of - pkg-plist; see below). However, if you h= ave - Japanese (or other multi-byte encoding) info files, you will h= ave - to use the extra arguments to install-info - because makeinfo cannot handle those texinfo - sources. (See Makefile and - pkg-plist of j= apanese/skk - for examples on how to do this). - - - - Go back to the port directory and do a make clean; - make and verify that the info files are regenerated - from the texinfo sources. Since the texinfo sources are newer = than - the info files, they should be rebuilt when you type - make; but many Makefiles - do not include correct dependencies for info files. In - Emacs' case, it was necessary to pa= tch the main - Makefile.in so it would descend into the - man subdirectory to rebuild the info - pages. - - --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 -+++ ./Makefile.in Tue Apr 15 00:15:28 1997 -@@ -184,7 +184,7 @@ - # Subdirectories to make recursively. `lisp' is not included - # because the compiled lisp files are part of the distribution - # and you cannot remake them without installing Emacs first. --SUBDIR =3D lib-src src -+SUBDIR =3D lib-src src man - - # The makefiles of the directories in $SUBDIR. - SUBDIR_MAKEFILES =3D lib-src/Makefile man/Makefile src/Makefile oldXMenu/= Makefile - lwlib/Makefile ---- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996 -+++ ./man/Makefile.in Tue Apr 15 00:29:52 1997 -@@ -66,6 +66,7 @@ - ${srcdir}/gnu1.texi \ - ${srcdir}/glossary.texi - -+all: info - info: $(INFO_TARGETS) - - dvi: $(DVI_TARGETS) - - The second hunk was necessary because the default target in - the man subdir is called - info, while the main - Makefile wants to call - all. The installation of the - info info file was also removed because we - already have one with the same name in - /usr/share/info (that patch is not shown - here). - - - - If there is a place in the Makefile t= hat - is installing the dir file, delete it. Y= our - port may not be doing it. Also, remove any commands that are - otherwise mucking around with the dir - file. - - --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 -+++ ./Makefile.in Mon Apr 14 23:38:07 1997 -@@ -368,14 +368,8 @@ - if [ `(cd ${srcdir}/info && /bin/pwd)` !=3D `(cd ${infodir} && /bi= n/pwd)` ]; \ - then \ - (cd ${infodir}; \ -- if [ -f dir ]; then \ -- if [ ! -f dir.old ]; then mv -f dir dir.old; \ -- else mv -f dir dir.bak; fi; \ -- fi; \ - cd ${srcdir}/info ; \ -- (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/= dir); -\ -- (cd $${thisdir}; chmod a+r ${infodir}/dir); \ - for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* = message* mh-e* sc* vip*; do \ - (cd $${thisdir}; \ - ${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \ - chmod a+r ${infodir}/$$f); \ - - - - (This step is only necessary if you are modifying an exist= ing - port.) Take a look at pkg-plist and delete - anything that is trying to patch up info/dir. - They may be in pkg-install or some other - file, so search extensively. - - Index: pkg-plist -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -RCS file: /usr/cvs/ports/editors/emacs/pkg-plist,v -retrieving revision 1.15 -diff -u -r1.15 pkg-plist ---- pkg-plist 1997/03/04 08:04:00 1.15 -+++ pkg-plist 1997/04/15 06:32:12 -@@ -15,9 +15,6 @@ - man/man1/emacs.1.gz - man/man1/etags.1.gz - man/man1/ctags.1.gz --@unexec cp %D/info/dir %D/info/dir.bak --info/dir --@unexec cp %D/info/dir.bak %D/info/dir - info/cl - info/cl-1 - info/cl-2 - - - - Add a post-install target to the - Makefile to call - install-info with the installed - info files. (It is no longer necessary to create the - dir file yourself; - install-info automatically creates this - file if it does not exist.) - - Index: Makefile -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -RCS file: /usr/cvs/ports/editors/emacs/Makefile,v -retrieving revision 1.26 -diff -u -r1.26 Makefile ---- Makefile 1996/11/19 13:14:40 1.26 -+++ Makefile 1997/05/20 10:25:09 1.28 -@@ -20,5 +20,8 @@ - post-install: - .for file in emacs-19.34 emacsclient etags ctags b2m - strip ${PREFIX}/bin/${file} - .endfor -+.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode -+ install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir -+.endfor - - .include <bsd.port.mk> - - - - Edit pkg-plist and add equivalent - @exec statements and also - @unexec for - pkg_delete. - - Index: pkg-plist -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -RCS file: /usr/cvs/ports/editors/emacs/pkg-plist,v -retrieving revision 1.15 -diff -u -r1.15 pkg-plist ---- pkg-plist 1997/03/04 08:04:00 1.15 -+++ pkg-plist 1997/05/20 10:25:12 1.17 -@@ -16,7 +14,14 @@ - man/man1/etags.1.gz - man/man1/ctags.1.gz -+@unexec install-info --delete %D/info/emacs %D/info/dir - : -+@unexec install-info --delete %D/info/ccmode %D/info/dir - info/cl - info/cl-1 -@@ -87,6 +94,18 @@ - info/viper-3 - info/viper-4 -+@exec install-info %D/info/emacs %D/info/dir - : -+@exec install-info %D/info/ccmode %D/info/dir - libexec/emacs/19.34/i386--freebsd/cvtmail - libexec/emacs/19.34/i386--freebsd/digest-doc - - - The @unexec install-info --delete - commands have to be listed before the info files themselves = so - they can read the files. Also, the @exec - install-info commands have to be after the info - files and the @exec command that creates = the - the dir file. - - - - - Test and admire y= our - work. :-). Check the - dir file before and after each step. - - + If your package needs to install GNU info files, they should be + listed in the INFO variable (without the traili= ng + .info), and appropriate installation/deinstalla= tion + code will be automaticaly added to the temporary + pkg-plist before package registration. =20 @@ -4316,6 +4086,19 @@ =20 + + <filename>pkg-deinstall</filename> + + This script executes when a package is removed. + + + This script will be run twice by &man.pkg.delete.1;. + The first time as ${SH} pkg-install ${PKG= NAME} + DEINSTALL and the second time as + ${SH} pkg-install ${PKGNAME} POST-DEINSTA= LL. + + + <filename>pkg-req</filename> =20 @@ -4372,13 +4155,13 @@ =20 This substitution (as well as addition of any manual pages) will be done b= etween - the do-install and - post-install targets, by reading from + the pre-install and + do-install targets, by reading from PLIST and writing to TMPPLIST (default: WRKDIR/.PLIST.mktmp). S= o if your port builds PLIST on the fly, do so in or - before do-install. Also, if your port + before pre-install. Also, if your port needs to edit the resulting file, do so in post-install to a file named TMPPLIST. @@ -4424,6 +4207,11 @@ PKGINSTALL ${PKGDIR}/pkg-install + + + + PKGDEINSTALL + ${PKGDIR}/pkg-deinstall =20 --AqsLC8rIMeq19msA-- --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/QMxRh9pcDSc1mlERAuj3AJ43euf3bjLYZWDPEPMTWEcK52pLrwCgkGIb WEJJny31nT/rPDDpDLFt6+M= =lzkE -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 07:06:51 2003 Return-Path: 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 DC2B137B43A for ; Mon, 18 Aug 2003 07:06:47 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EC2E44226 for ; Mon, 18 Aug 2003 06:07:51 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 3ABEA10BFA8; Mon, 18 Aug 2003 15:07:50 +0200 (CEST) Date: Mon, 18 Aug 2003 15:07:50 +0200 From: "Simon L. Nielsen" To: Mark Linimon Message-ID: <20030818130749.GC407@FreeBSD.org> References: <1061069299.54862.34.camel@shumai.marcuscom.com> <20030817110722.GA391@FreeBSD.org> <1061131638.43833.2.camel@shumai.marcuscom.com> <200308171326.45898.linimon@lonesome.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NKoe5XOeduwbEQHU" Content-Disposition: inline In-Reply-To: <200308171326.45898.linimon@lonesome.com> User-Agent: Mutt/1.5.4i cc: freebsd-doc@freebsd.org Subject: Re: Review of porters-handbook changes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 14:06:51 -0000 --NKoe5XOeduwbEQHU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.08.17 13:26:45 -0500, Mark Linimon wrote: > > I tried to preserve the style of adjacent blocks. To that end, some use > > spaces, so I opted for spaces to keep things lined up. >=20 > I did the same with my patches. >=20 > At some point when all this stuff gets committed I'll volunteer to do > a whitespace diff on the thing at which time we can settle on the > Right Way and not confuse future contributors. I think it would be a good idea to do, but I'm really unsure when it's OK to do whitespace commits. A lot of articles and books could use some whitespace cleanup... --=20 Simon L. Nielsen FreeBSD Documentation Team --NKoe5XOeduwbEQHU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/QM+lh9pcDSc1mlERAvd/AJ9bVwwEtsPNW8+eN5u1pgfpMihbjwCdE5za XLuj0G2oPGzPiJXZpDFZJ58= =FE8L -----END PGP SIGNATURE----- --NKoe5XOeduwbEQHU-- From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 08:40:17 2003 Return-Path: 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 F24E237B401 for ; Mon, 18 Aug 2003 08:40:16 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E9CA43FA3 for ; Mon, 18 Aug 2003 08:40:16 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7IFeGUp048881 for ; Mon, 18 Aug 2003 08:40:16 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7IFeFaG048880; Mon, 18 Aug 2003 08:40:15 -0700 (PDT) Date: Mon, 18 Aug 2003 08:40:15 -0700 (PDT) Message-Id: <200308181540.h7IFeFaG048880@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Sergey Matveychuk Subject: Re: docs/46181: "make fetch-recursive" target description ismissing in the ports manpage. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Sergey Matveychuk List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 15:40:17 -0000 The following reply was made to PR docs/46181; it has been noted by GNATS. From: Sergey Matveychuk To: freebsd-gnats-submit@FreeBSD.org, jc@minjust.gov.ua, keramida@freebsd.org Cc: Subject: Re: docs/46181: "make fetch-recursive" target description is missing in the ports manpage. Date: Mon, 18 Aug 2003 19:31:30 +0400 This is a multi-part message in MIME format. --------------030608060508080804080103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Murray Stokely wrote: > Does anyone have a patch for this yet? It would be nice to update > ports.7. Can the original submitter at least propose some exact text > to be added if not a patch? I've wrote some little patch for new targets. Check it. ---- Sem. --------------030608060508080804080103 Content-Type: text/plain; name="ports.7.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ports.7.diff" --- ports.7.orig Mon Aug 18 18:47:00 2003 +++ ports.7 Mon Aug 18 19:24:05 2003 @@ -161,6 +161,11 @@ .Bl -tag -width ".Cm fetch-list" .It Cm fetch-list Show list of files needed to be fetched in order to build the port. +.It Cm fetch-recursive +Retrieves all of the files needed to build this port and dependencies. +.It Cm fetch-recursive-list +Show list of files that would be retrieved by +.Cm fetch-recursive . .It Cm pretty-print-run-depends-list , pretty-print-build-depends-list Print a list of all the compile and run dependencies, and dependencies of those dependencies. @@ -189,6 +194,11 @@ .It Cm deinstall Remove an installed port from the system, similar to .Xr pkg_delete 1 . +.It Cm deinstall-all +Remove an installed ports from the system with the same +.Va PKGORIGIN . +They could be a different versions or installed with different +.Va PREFIX . .It Cm package Make a binary package for the port. The port will be installed if it has not already been. @@ -204,6 +214,8 @@ .Va PKGREPOSITORY and .Va PKGFILE . +.It Cm package-recursive +Make binary packages for this port and ports it's depended. .It Cm readmes Create a port's .Pa README.html . --------------030608060508080804080103-- From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 11:00:56 2003 Return-Path: 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 4B20237B47E for ; Mon, 18 Aug 2003 11:00:54 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DE8243FE3 for ; Mon, 18 Aug 2003 11:00:51 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7II0pUp067440 for ; Mon, 18 Aug 2003 11:00:51 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7II0nYO067411 for freebsd-doc@freebsd.org; Mon, 18 Aug 2003 11:00:49 -0700 (PDT) Date: Mon, 18 Aug 2003 11:00:49 -0700 (PDT) Message-Id: <200308181800.h7II0nYO067411@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: FreeBSD doc list Subject: Current unassigned doc problem reports X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 18:00:57 -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. 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 S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/10/31] i386/31671 doc 4.4 installer hangs at " Mounting root fr 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2000/07/18] docs/20028 doc ASCII docs should reflect tags o [2001/05/23] docs/27605 doc Cross-document references () s [2002/03/08] docs/35678 doc docproj Makefiles for web are broken for o [2002/03/21] docs/36168 doc -pthread/_THREAD_SAFE docs missing in gcc o [2002/09/13] docs/42762 doc ppp.8 has no description of $env and ~use o [2002/11/14] docs/45303 doc Bug in PDF DocBook rendering f [2003/02/19] docs/48472 doc Documentation unreadable. s [1999/10/04] i386/14135 doc lpt1 nolonger exists after 3.2-RELEASE o [2002/01/15] ports/33929 doc Section 15.15 of the FreeBSD Porter's Han o [2003/08/08] docs/55391 doc plist generation instructions incorrect o [2003/08/15] docs/55613 doc su man page confusing, probably incorrect o [2003/08/18] docs/55693 doc Howto make a kernel module for a pseudo-d 12 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/02/15] bin/34955 doc [PATCH] ps(1) is out of touch with realit o [2001/02/01] docs/24786 doc missing FILES descriptions in sa(4) o [2001/07/26] docs/29245 doc top(1) manpage doesn't understand SMP a [2001/08/23] docs/30008 doc This document should be translated, comme o [2001/09/27] docs/30873 doc ``ip'' man page does not specify byte ord o [2001/10/07] docs/31109 doc replace gif images w/ png ones due to pat o [2001/11/15] docs/32020 doc loader.8 manpage missing tunables o [2002/01/05] docs/33589 doc Patch to doc.docbook.mk to post process . o [2002/01/13] docs/33852 doc split(1) man page implies that input file o [2002/01/14] docs/33877 doc Documentet behaviour of SF_flags for non- a [2002/02/16] docs/35011 doc There are no commands called "diskless" o o [2001/04/29] docs/26943 doc [patch] description of :C modifier is mis o [2002/02/22] docs/35222 doc mailing list archive URL regexp suboptima o [2002/03/06] docs/35602 doc dump(8)/restore(8) pages don't explain "a o [2002/03/06] docs/35607 doc dump(1) page needs discussion of scary er o [2002/03/06] docs/35608 doc mt(1) page uses "setmark" without explana o [2002/03/06] docs/35609 doc mt(1) page needs explanation of "long era o [2002/03/06] docs/35612 doc ps(1) page "state" description doesn't me o [2002/03/07] docs/35642 doc lo(4) page maybe should document optional o [2002/03/07] docs/35644 doc lo(4) page presumes familiarity with prin o [2002/03/07] docs/35646 doc cp(1) page needs a "Bugs" section. o [2002/03/07] docs/35647 doc www; combine query-by-number and multi-fi o [2002/03/07] docs/35648 doc rc.conf; add note about "flags" to both f o [2002/03/08] docs/35686 doc blackhole(4) page seems to contradict its o [2002/03/08] docs/35687 doc /etc/nsmb.conf missing mention of readers o [2002/03/09] docs/35711 doc the "gnats page" should move to its own s o [2002/03/10] docs/35732 doc adduser(8) page has obsolete reference an o [2002/03/28] docs/36449 doc symlink(7) manual doesn't mention trailin o [2002/03/15] docs/35943 doc at(1) config files are misplaced in /var/ o [2002/03/15] docs/35953 doc hosts.equiv(5) manual is confusing or wro o [2002/03/28] docs/36432 doc Proposal for doc/share/mk: make folded bo o [2002/05/03] docs/37719 doc Detail VOP_ naming in a relevant man-page s [2002/05/07] docs/37843 doc manual for pthread_setschedparam is wrong o [2002/05/18] docs/38225 doc change "CDROM" to "CD-ROM" o [2002/05/25] docs/38556 doc EPS file of beastie, as addition to exist o [2002/05/27] docs/38620 doc Committers Guide and CVS o [2002/05/31] docs/38772 doc firewall_type feature not mentioned on Ha o [2002/06/07] docs/38982 doc developers-hanbook/Jail fix o [2002/06/12] docs/39213 doc No rc(4) man page o [2002/06/15] docs/39348 doc kenv fetch of hostname requires dhcp/boot o [2002/06/19] docs/39530 doc access(2) man page has unnecessarily broa o [2002/06/19] docs/39532 doc 'find' man page should o [2002/06/24] docs/39824 doc Various tweaks for doc/en_US.ISO8859-1/bo o [2002/07/04] docs/40196 doc man find does not describe -follow o [2002/07/10] docs/40423 doc Keyboard(4)'s definition of parameters to o [2002/07/10] docs/40443 doc Update books/faq/book.sgml for USB .ko's o [2002/07/21] docs/40851 doc [PATCH] "mergemaster -p" in UPDATING's "C o [2002/07/28] docs/41089 doc pax -B option does not mention interactio o [2002/07/29] docs/41110 doc "apropos linux" doesn't find brandelf o [2002/08/07] docs/41423 doc Update FAQ: attrib command for windows du o [2002/08/18] docs/41761 doc Update for /ru/internal/ part of site o [2002/08/19] docs/41787 doc man page for route (Section 8) missing de o [2002/08/19] docs/41791 doc Documentation formatting error o [2002/08/02] docs/41270 doc confusing directions for kernelconfig cha o [2002/08/19] docs/41807 doc natd -punch_fw "bug" o [2002/08/20] docs/41820 doc Device driver confusion in Handbook (2.3) a [2002/08/27] docs/42058 doc Documentation: Installing Oracle 8i onto o [2002/09/27] docs/43416 doc pw(8) -u uidmin,uidmax feature is out of o [2002/10/01] docs/43569 doc src/share/examples/worm/README out-of-dat o [2002/10/04] docs/43651 doc stab(5) incorrectly states to include jus o [2002/10/09] docs/43861 doc non-trivial typo in wicontrol man page o [2002/10/11] docs/43941 doc Rationale for Upgrade Sequence o [2002/10/14] docs/44074 doc ln(1) manual clarifications [patch] o [2002/10/23] docs/44400 doc ipfw(8) has contradictions in bridged and o [2002/10/24] docs/44435 doc sysctl manpage: add example for tcsh o [2002/10/29] docs/44594 doc Handbook doesn't mention drivers.flp for o [2002/11/17] docs/45371 doc man page for exports lacks information on o [2002/12/02] docs/45940 doc burncd missing info o [2002/12/11] docs/46181 doc "make fetch-recursive" target description o [2002/12/11] docs/46196 doc Missing return value in (set_)menu_format o [2002/12/11] docs/46200 doc fix for ru_RU.KOI8-R/books/porters-handbo o [2002/12/16] docs/46291 doc correlation between HZ kernel config para o [2002/12/16] docs/46295 doc please add information to Nvi recovery em o [2003/01/02] docs/46709 doc tables in terminfo.5 are broken o [2003/01/05] docs/46793 doc DEVICE_POLLING can not be used with SMP, o [2003/01/14] docs/47085 doc boot(8) manpage is incomplete according t o [2003/01/27] docs/47575 doc Clarify requirements for IPFW2 in STABLE o [2003/01/28] docs/47594 doc [PATH] passwd(5) incorrectly states allow o [2003/01/30] docs/47690 doc builtin(1) manpage is wrong about externa o [2003/01/30] docs/47705 doc wc(1) manpage has poor explanations. f [2003/02/02] docs/47818 doc ln(1) manpage is confusing f [2003/02/07] docs/48038 doc [PATCH] add Tips and Tricks section into o [2003/02/12] docs/48210 doc make -q only does what the manpage says i o [2003/02/28] docs/48767 doc wrong key numbers for left/right windows o [2003/03/06] docs/48980 doc [PATCH] nsgmls -s errors and sect. 3.2.1 o [2003/03/14] docs/50013 doc [PATCH] add much more russian holydays o [2003/03/23] docs/50211 doc [PATCH] Fix textfile creation o [2003/03/27] docs/50349 doc make release fails with NO_OPENSSH and ! f [2003/03/28] docs/50391 doc Incorrect information in a man o [2003/04/03] docs/50573 doc return values for res_query/res_search/re f [2003/04/07] docs/50677 doc [PATCH] update doc/en_US.ISO8859-1/books/ o [2003/04/10] docs/50773 doc NFS problems by jumbo frames to mention i o [2003/05/06] docs/51875 doc atkbd(4) adjustment o [2003/05/06] docs/51891 doc DIAGNOSTICS in ed driver manpage don't ma o [2003/05/07] docs/51921 doc ls(1) manpage lacks some information abou o [2003/05/11] docs/52071 doc [PATCH] Add more information about soft u o [2003/05/25] docs/52672 doc Porter's Handbook: couple of corrections o [2003/06/02] docs/52878 doc [PATCH] security(7): small clairification o [2003/06/13] docs/53303 doc mount(2) man page error o [2003/06/14] docs/53315 doc [PATCH] remove extraneous whitespace at t o [2003/06/18] docs/53454 doc wrong sample code in manpage of wcwidth(3 o [2003/06/19] docs/53501 doc [PATCH] Handbook: update snapshots sectio o [2003/06/20] docs/53575 doc Change to Handbook Section 20.9 o [2003/06/21] docs/53596 doc Updates to mt manual page o [2003/06/25] docs/53732 doc quota output and man page do not document o [2003/06/26] docs/53751 doc bus_dma(9) incorrectly documents BUS_DMA_ o [2003/07/07] docs/54197 doc Mentioning of devfs is missing in the Ger o [2003/07/11] docs/54380 doc [PATCH] document additional perl variable o [2003/07/11] docs/54391 doc Document that glob(3) respects LC_COLLATE o [2003/07/17] docs/54574 doc [patch] fixed b0rked o [2002/01/15] misc/33926 doc Search function on website can not access o [2002/03/20] misc/36154 doc Getting USB mouse to work: usbd and mouse o [2003/07/20] docs/54678 doc [patch] add PACKAGESITE to packages chapt o [2003/07/22] docs/54752 doc bus_dma explained in ISA section: should o [2003/07/22] docs/54769 doc [patch] updates to FAQ o [2003/07/23] docs/54789 doc [PATCH] brush up the "New Users" article o [2003/07/24] docs/54806 doc [patch] adds fvwm2 to x11-wm o [2003/07/25] docs/54879 doc man 1 jot, -r description o [2003/07/28] docs/54995 doc Error in accept(2) man page o [2003/07/28] docs/54999 doc Documentation Project Primer doesn't conf o [2003/08/03] docs/55207 doc [patch] update acroread section & add loc o [2003/08/03] docs/55226 doc [PATCH] handbook: add nonbreaking spaces o [2003/08/05] docs/55276 doc [patch] Update tuning.7 to reflect phk's o [2003/08/06] docs/55306 doc [patch] adds filemanagers to desktop appl o [2003/08/10] docs/55445 doc [PATCH] off-by-one bug in example code o [2003/08/11] docs/55458 doc [patch] add useful content & hints to por o [2003/08/11] docs/55482 doc DUMP has access to block devices in a JAI o [2003/08/12] docs/55512 doc [PATCH] catch up ata(4) with hardware not o [2003/08/13] docs/55530 doc [PATCH] catch up dpt(4) with hardware not o [2003/08/13] docs/55538 doc [patch] add screenshots to desktop chapte o [2003/08/13] docs/55557 doc [PATCH] catch up sym(4) with hardware not o [2003/08/13] docs/55558 doc [PATCH] catch up isp(4) with hardware not o [2003/08/13] docs/55559 doc [PATCH] catch up rl(4) with hardware note o [2003/08/13] docs/55562 doc [PATCH] document SC_NO_SUSPEND_VTYSWITCH o [2003/08/15] docs/55605 doc stg driver lacks a man page o [2003/08/16] docs/55636 doc [PATCH] catch up fe(4) with hardware note o [2003/08/16] docs/55637 doc [PATCH] catch up ti(4) with hardware note o [2003/08/16] docs/55639 doc [PATCH] catch up vr(4) with hardware note o [2003/08/16] docs/55641 doc [PATCH] catch up tl(4) with hardware note o [2003/08/16] docs/55643 doc [PATCH] catch up aue(4) with hardware not o [2003/08/16] docs/55644 doc [PATCH] catch up cue(4) with hardware not o [2003/08/16] docs/55645 doc [PATCH] catch up kue(4) with hardware not o [2003/08/16] docs/55653 doc chflags.1 - note that not all tools chfla o [2003/08/17] docs/55659 doc [PATCH] catch up ep(4) with hardware note 144 problems total. From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 11:04:40 2003 Return-Path: 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 4827937B40C; Mon, 18 Aug 2003 11:04:38 -0700 (PDT) Received: from ms-smtp-01.southeast.rr.com (ms-smtp-01.southeast.rr.com [24.93.67.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98F8743FAF; Mon, 18 Aug 2003 11:04:37 -0700 (PDT) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (rdu57-17-158.nc.rr.com [66.57.17.158])h7IHvncs026873; Mon, 18 Aug 2003 13:57:49 -0400 (EDT) Received: from [10.2.1.4] (vpn-client-4.marcuscom.com [10.2.1.4]) h7II3qUA064052; Mon, 18 Aug 2003 14:03:52 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: "Simon L. Nielsen" In-Reply-To: <20030818125337.GB407@FreeBSD.org> References: <1061069299.54862.34.camel@shumai.marcuscom.com> <20030817110722.GA391@FreeBSD.org> <1061131638.43833.2.camel@shumai.marcuscom.com> <20030818125337.GB407@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ex7W6s0VXkUmcun888Ef" Organization: FreeBSD, Inc. Message-Id: <1061229879.730.54.camel@gyros> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Mon, 18 Aug 2003 14:04:39 -0400 X-Spam-Status: No, hits=-11.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-doc@FreeBSD.org Subject: Re: Review of porters-handbook changes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2003 18:04:40 -0000 --=-ex7W6s0VXkUmcun888Ef Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2003-08-18 at 08:53, Simon L. Nielsen wrote: > On 2003.08.17 10:47:18 -0400, Joe Marcus Clarke wrote: > > On Sun, 2003-08-17 at 07:07, Simon L. Nielsen wrote: > > > On 2003.08.16 17:28:19 -0400, Joe Marcus Clarke wrote: > > > > Can someone review the attached diff to the porter's handbook? It = was > > > > submitted by Sergey Matveychuk for some of the recent > > > > ports infrastructure changes. It is technically accurate, and I fi= xed a > > > > few grammar and spelling nits, but I would like a doc committers ta= ke on > > > > it before committing. Also, if one of you would rather commit, tha= t's > > > > fine. Thanks! > > >=20 > > > There are some places where 8 spaces have been used instead of a tab > > > (can be fixed by marking the regions and using 'meta-x tabify' in > > > emacs'). There are also some end of line white-spaces which should b= e > > > removed. > >=20 > > I tried to preserve the style of adjacent blocks. To that end, some us= e > > spaces, so I opted for spaces to keep things lined up. >=20 > OK, I didn't check the rest for the file for style, and the tab/space > thing is not that important then. >=20 > But the end of line whitespace still doesn't need to be there :). It's > not crucial to remove it, but there is no reason to have it there. >=20 > Sorry for being so pedantic about this... >=20 > I have attached a patch where I have removed the end of line whitespace, > and changed the pkg_deinstall reference (see below). >=20 > > --- doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 17 Aug 2003 09= :12:05 -0000 1.320 > > +++ doc/en_US.ISO8859-1/books/porters-handbook/book.sgml 17 Aug 2003 14= :46:25 -0000 > > @@ -4316,6 +4086,19 @@ > > > > > > =20 > > + > > + <filename>pkg-deinstall</filename> > > + > > + This script executes when a package is removed. > > + > > + > > + This script will be run twice by pkg_delete. >=20 > It's better to use "&man.pkg.delete.1;" instead of the command tag since > it will create a link to the manual page. Thanks! Committed with your suggestions after doing a full make of doc/. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: marcus@FreeBSD.org gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-ex7W6s0VXkUmcun888Ef Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQA/QRU3b2iPiv4Uz4cRAnFYAJwJa1USCJwpzuJkoVl6bn7I2/31MwCglfHg kFs7S9QNzZwzq4rYIll+Xxw= =jG1k -----END PGP SIGNATURE----- --=-ex7W6s0VXkUmcun888Ef-- From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 19:24:31 2003 Return-Path: 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 A4E9137B401 for ; Mon, 18 Aug 2003 19:24:31 -0700 (PDT) Received: from hueymiccailhuitl.mtu.ru (hueytecuilhuitl.mtu.ru [195.34.32.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15AC943FA3 for ; Mon, 18 Aug 2003 19:24:31 -0700 (PDT) (envelope-from sem@ciam.ru) Received: from ciam.ru (ppp137-110.dialup.mtu-net.ru [62.118.137.110]) by hueymiccailhuitl.mtu.ru (Postfix) with ESMTP id 8D6381C9E6F for ; Tue, 19 Aug 2003 06:24:29 +0400 (MSD) (envelope-from sem@ciam.ru) Message-ID: <3F418A65.5030306@ciam.ru> Date: Tue, 19 Aug 2003 06:24:37 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.3) Gecko/20030309 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: freebsd-doc@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Document not found - http://www.freebsd.org/releases/4.9R/schedule.html X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 02:24:32 -0000 http://www.freebsd.org/releng/index.html From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 19:46:17 2003 Return-Path: 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 2B16937B404; Mon, 18 Aug 2003 19:46:17 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B711443F75; Mon, 18 Aug 2003 19:46:16 -0700 (PDT) (envelope-from kensmith@FreeBSD.org) Received: from freefall.freebsd.org (kensmith@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7J2kGUp054246; Mon, 18 Aug 2003 19:46:16 -0700 (PDT) (envelope-from kensmith@freefall.freebsd.org) Received: (from kensmith@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7J2kGDm054242; Mon, 18 Aug 2003 19:46:16 -0700 (PDT) Date: Mon, 18 Aug 2003 19:46:16 -0700 (PDT) From: Ken Smith Message-Id: <200308190246.h7J2kGDm054242@freefall.freebsd.org> To: kensmith@FreeBSD.org, freebsd-doc@FreeBSD.org, kensmith@FreeBSD.org Subject: Re: docs/55693: Howto make a kernel module for a pseudo-device under 5.X X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 02:46:17 -0000 Synopsis: Howto make a kernel module for a pseudo-device under 5.X Responsible-Changed-From-To: freebsd-doc->kensmith Responsible-Changed-By: kensmith Responsible-Changed-When: Mon Aug 18 19:45:03 PDT 2003 Responsible-Changed-Why: I'll give this one a try. http://www.freebsd.org/cgi/query-pr.cgi?pr=55693 From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 22:06:46 2003 Return-Path: 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 1CD1F16A4DD; Mon, 18 Aug 2003 22:06:46 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E91FC441B3; Mon, 18 Aug 2003 21:38:54 -0700 (PDT) (envelope-from bmah@FreeBSD.org) Received: from freefall.freebsd.org (bmah@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7J4csUp064974; Mon, 18 Aug 2003 21:38:54 -0700 (PDT) (envelope-from bmah@freefall.freebsd.org) Received: (from bmah@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7J4cn7c064954; Mon, 18 Aug 2003 21:38:49 -0700 (PDT) Date: Mon, 18 Aug 2003 21:38:49 -0700 (PDT) From: "Bruce A. Mah" Message-Id: <200308190438.h7J4cn7c064954@freefall.freebsd.org> To: l.ertl@univie.ac.at, bmah@FreeBSD.org, freebsd-doc@FreeBSD.org, bmah@FreeBSD.org Subject: Re: docs/55530: [PATCH] catch up dpt(4) with hardware notes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 05:06:48 -0000 Synopsis: [PATCH] catch up dpt(4) with hardware notes State-Changed-From-To: open->closed State-Changed-By: bmah State-Changed-When: Mon Aug 18 21:38:01 PDT 2003 State-Changed-Why: Committed to HEAD, thanks! The version of this manpage on RELENG_4 seems to already have this information somehow, so no MFC needed. Responsible-Changed-From-To: freebsd-doc->bmah Responsible-Changed-By: bmah Responsible-Changed-When: Mon Aug 18 21:38:01 PDT 2003 Responsible-Changed-Why: I committed this. http://www.freebsd.org/cgi/query-pr.cgi?pr=55530 From owner-freebsd-doc@FreeBSD.ORG Mon Aug 18 22:23:23 2003 Return-Path: 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 E831616A4DD for ; Mon, 18 Aug 2003 22:23:22 -0700 (PDT) Received: from ns1.compugraph.net (ns1.compugraph.net [64.113.194.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 081AC44285 for ; Mon, 18 Aug 2003 22:00:51 -0700 (PDT) (envelope-from m@MarcBlake.com) Received: from [64.113.194.251] by ns1.MarcBlake.com (NTMail 3.03.0017/1.aclr) with ESMTP id ea969986 for ; Mon, 18 Aug 2003 22:07:05 -0700 Message-Id: <4.2.0.58.20030818220005.02e65948@MarcBlake.com> X-Sender: m@MarcBlake.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 18 Aug 2003 22:00:49 -0700 To: doc@FreeBSD.org From: "Marc B. Blake" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Command not found X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 05:23:24 -0000 I'm trying to run the htpasswd utility with Apache and I'm getting an=20 error: Command not found. I'm new to UNIX and not sure what I can do to resolve this. Any help? thx, Marc B. Blake Serving the Web Since the 20th Century Copyright =A9 1995 by CompuGraph International m@MarcBlake.com Ph: 559 251-5152 From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 03:55:54 2003 Return-Path: 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 A81CF16A4BF for ; Tue, 19 Aug 2003 03:55:54 -0700 (PDT) Received: from eborcom.com (dsl-62-3-122-102.zen.co.uk [62.3.122.102]) by mx1.FreeBSD.org (Postfix) with SMTP id 62D6443F75 for ; Tue, 19 Aug 2003 03:55:53 -0700 (PDT) (envelope-from tom@FreeBSD.org) Received: (qmail 26975 invoked by uid 1001); 19 Aug 2003 10:55:51 -0000 Date: Tue, 19 Aug 2003 11:55:51 +0100 From: Tom Hukins To: "Marc B. Blake" Message-ID: <20030819105551.GA26910@eborcom.com> Mail-Followup-To: Tom Hukins , "Marc B. Blake" , doc@FreeBSD.org References: <4.2.0.58.20030818220005.02e65948@MarcBlake.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.2.0.58.20030818220005.02e65948@MarcBlake.com> User-Agent: Mutt/1.4.1i cc: doc@FreeBSD.org Subject: Re: Command not found X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 10:55:54 -0000 On Mon, Aug 18, 2003 at 10:00:49PM -0700, Marc B. Blake wrote: > I'm trying to run the htpasswd utility with Apache and I'm getting an > error: Command not found. > > I'm new to UNIX and not sure what I can do to resolve this. Please post to an appropriate mailing list. This list exists to discuss FreeBSD's documentation, not problems with FreeBSD: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL Try the freebsd-questions list instead. Tom From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 06:44:28 2003 Return-Path: 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 855A216A4C3 for ; Tue, 19 Aug 2003 06:44:28 -0700 (PDT) Received: from hosting.commandprompt.com (209.commandprompt.com [207.173.200.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id A571B43FB1 for ; Tue, 19 Aug 2003 06:44:27 -0700 (PDT) (envelope-from pgsql-docs-owner@postgresql.org) Received: from postgresql.org (svr1.postgresql.org [64.117.224.193]) h7JDiQp20568 for ; Tue, 19 Aug 2003 06:44:26 -0700 Message-Id: <200308191344.h7JDiQp20568@hosting.commandprompt.com> MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Date: Tue, 19 Aug 2003 10:44:20 -0300 From: pgsql-docs-owner@postgresql.org To: Content-Type: multipart/mixed; boundary="----------=_1061300660-21122-2" Subject: Stalled post to pgsql-docs X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 13:44:28 -0000 This is a multi-part message in MIME format... ------------=_1061300660-21122-2 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Language: en Your message to pgsql-docs has been delayed, and requires the approval of the moderators, for the following reason(s): The author () is not a member of any of the restrict_post groups. Duplicate Message Checksum (Tue Aug 19 09:09:08 2003) Duplicate Partial Message Checksum (Tue Aug 19 09:09:08 2003) If you do not wish the message to be posted, or have other concerns, please send a message to the list owners at the following address: pgsql-docs-owner@postgresql.org ------------=_1061300660-21122-2 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Description: Original message Return-Path: X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org Delivered-To: pgsql-docs-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id A444DD1B8DA for ; Tue, 19 Aug 2003 10:44:15 -0300 (ADT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 58667-01 for ; Tue, 19 Aug 2003 10:44:03 -0300 (ADT) Received: from svr4.postgresql.org (svr4.postgresql.org [64.117.224.192]) by svr1.postgresql.org (Postfix) with ESMTP id 7A980D1B8E7 for ; Tue, 19 Aug 2003 10:43:59 -0300 (ADT) Received: from NEXCOM32 (unknown [212.157.49.165]) by svr4.postgresql.org (Postfix) with ESMTP id BBC161CB47B3 for ; Tue, 19 Aug 2003 13:44:02 +0000 (GMT) From: To: Subject: Re: Wicked screensaver Date: Tue, 19 Aug 2003 15:43:56 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_005F7FED" Message-Id: <20030819134402.BBC161CB47B3@svr4.postgresql.org> X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=4.7 tagged_above=0.0 required=5.0 tests=BAYES_60, FORGED_MUA_OUTLOOK, MIME_BOUND_NEXTPART, MISSING_MIMEOLE, NO_REAL_NAME X-Spam-Level: **** This is a multipart message in MIME format --_NextPart_000_005F7FED Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_005F7FED-- ------------=_1061300660-21122-2-- From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 09:05:53 2003 Return-Path: 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 5C1B616A4C0 for ; Tue, 19 Aug 2003 09:05:53 -0700 (PDT) Received: from server1.aluriasoftware.com (aluriasoftware.com [66.216.126.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 566A943FAF for ; Tue, 19 Aug 2003 09:05:51 -0700 (PDT) (envelope-from support@aluriasoftware.com) Received: from server1.aluriasoftware.com (localhost [127.0.0.1]) h7JG5oV06216 for ; Tue, 19 Aug 2003 11:05:50 -0500 Date: Tue, 19 Aug 2003 16:05:50 GMT To: doc@freebsd.org From: support@aluriasoftware.com Message-ID: <20030819120550115208support@aluriasoftware.com> In-reply-to: <200308191605.h7JG5mV06209@server1.aluriasoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Cerberus (ver. 1.4.1-rc10) by WebGroupMedia.com Subject: [Support #115208]: Re: That movie X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 16:05:53 -0000 Thank you for writing to Aluria Software! Your support request tracking ID is 115208 We appreciate your business and look forward to exceeding your expectations. We wanted to assure you that your support request or question has been received and assigned a ticket number. Our goal is 100% customer satisfaction and we will do everything to meet that goal. If you have been unable to download the product you purchased, please view your product receipt that you received in your email. Your personal download link is in it! Generally we try to answer all support requests within 24-48 hours. If your support request has been assigned during non-business hours, please know that we work on a first come, first serve basis and it WILL be answered first thing in the morning. In the meantime, please visit our various support sites by going to www.aluriasoftware.com and clicking on the product in question. On the product page you will see a link for support. Click this to visit the tutorials we have posted there for you. Our support website is http://www.aluriasoftware.com/support.html We look forward to helping you! Aluria Software Support www.aluriasoftware.com fax: 407-833-8500 From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 09:41:20 2003 Return-Path: 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 454CC16A4E5 for ; Tue, 19 Aug 2003 09:41:18 -0700 (PDT) Received: from audacious.cnchost.com (audacious.cnchost.com [207.155.252.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 976FA43FD7 for ; Tue, 19 Aug 2003 09:41:17 -0700 (PDT) (envelope-from info@tigertools.net) Received: (root@localhost) by audacious.cnchost.com (ConcentricHost SMTP MX 1.39) id MAA19586; Tue, 19 Aug 2003 12:41:17 -0400 (EDT) Date: Tue, 19 Aug 2003 12:41:17 -0400 (EDT) Message-Id: <200308191641.MAA19586@audacious.cnchost.com> Errors-To: From: "info" To: doc@FreeBSD.org Precedence: bulk Subject: Automatic response to your mail X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 16:41:20 -0000 This is an automatic response to your message. You should receive a reply to your message within 48 hours. Thank you for your patience, www@TigerTools.net From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 10:35:18 2003 Return-Path: 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 1997816A4BF for ; Tue, 19 Aug 2003 10:35:18 -0700 (PDT) Received: from malus.vmirror.com (malus.vmirror.com [198.64.148.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7301F43FB1 for ; Tue, 19 Aug 2003 10:35:17 -0700 (PDT) (envelope-from daemon@malus.vmirror.com) Received: from malus.vmirror.com (malus.vmirror.com [198.64.148.141]) by malus.vmirror.com (8.12.9/8.12.9) with ESMTP id h7JHZFnl015250 for ; Tue, 19 Aug 2003 13:35:16 -0400 Received: (from daemon@localhost) by malus.vmirror.com (8.12.9/8.12.9/Submit) id h7JHZFdG015244; Tue, 19 Aug 2003 13:35:15 -0400 Message-Id: <200308191735.h7JHZFdG015244@malus.vmirror.com> From: Mail Delivery Subsystem Date: Tue, 19 Aug 2003 13:35:15 To: Subject: Returned mail: delivery problems encountered X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 17:35:18 -0000 If you are trying to contact GardenWeb, please use the form at: http://letters.gardenweb.com/letters/ A message (from ) was received at Tue, 19 Aug 2003 18:35:28 +0100 +0000. The following addresses had delivery problems: Permanent Failure: Other address status Delivery last attempted at Tue, 19 Aug 2003 18:35:28 +0100 -0000 Reporting-MTA: dns; sccrmhc01.gardenweb.com Arrival-Date: Tue, 19 Aug 2003 18:35:28 +0100 +0000 Final-Recipient: rfc822; Action: failed Status: 5.1.0 MAIL FROM: 554 REPLY: 554_delivery_error:_dd_This_user_doesn't_have_a_gardenweb.com_account_(members@gardenweb.com)_[0]_-_mta416.mail.gardenweb.com Diagnostic-Code: smtp; Permanent Failure: Other address status Lookout: Dayr7854dFD Last-Attempt-Date: Tue, 19 Aug 2003 18:35:28 +0100 -0000 Received: from GENIE (host81-128-162-216.in-addr.btopenworld.com [81.128.162.216]) with SMTP id <20030819133515232105225oje>; Tue, 19 Aug 2003 18:35:28 +0100 +0000 Message-Id: <3.0.5.32.20030819133515232105225e0.0.0.1> X-Sender: freebsd-doc@FreeBSD.org X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Date: Tue, 19 Aug 2003 18:35:28 +0100 +0000 To: members@gardenweb.com From: Subject: Re: Wicked screensaver Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" This is a multipart message in MIME format Please see the attached file for details. From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 10:57:50 2003 Return-Path: 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 0D1CE16A4BF for ; Tue, 19 Aug 2003 10:57:50 -0700 (PDT) Received: from atlantech.net (mail3.atlantech.net [209.183.205.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E78E43FB1 for ; Tue, 19 Aug 2003 10:57:49 -0700 (PDT) (envelope-from ) From: atl-cust-request@atlantech.net (atl-cust administration) To: doc@FreeBSD.org Date: Tue, 19 Aug 2003 13:57:48 -0400 Message-ID: X-ListServer: CommuniGate Pro LIST 4.0.6 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Subject: Welcome! X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 17:57:50 -0000 This is an automated message from the mailing list manager You are subscribed to "Atlantech Online Notifications" as To Join: mailto:atl-cust-on@atlantech.net To Unsubscribe: mailto:atl-cust-off@atlantech.net Digest Mode: mailto:atl-cust-digest@atlantech.net Index Mode: mailto:atl-cust-index@atlantech.net From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 13:14:58 2003 Return-Path: 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 9814C16A4BF; Tue, 19 Aug 2003 13:14:58 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E3AB43FBF; Tue, 19 Aug 2003 13:14:57 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 57D2810BF82; Tue, 19 Aug 2003 22:14:56 +0200 (CEST) Date: Tue, 19 Aug 2003 22:14:56 +0200 From: "Simon L. Nielsen" To: Murray Stokely Message-ID: <20030819201456.GH392@FreeBSD.org> References: <200308171355.h7HDt5ii082681@repoman.freebsd.org> <20030817140406.GB391@FreeBSD.org> <20030818123221.C235@freebsdmall.com> <20030819005734.GC1489@FreeBSD.org> <20030818203453.R235@freebsdmall.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+1TulI7fc0PCHNy3" Content-Disposition: inline In-Reply-To: <20030818203453.R235@freebsdmall.com> User-Agent: Mutt/1.5.4i cc: freebsd-doc@freebsd.org Subject: Re: cvs commit: doc/en_US.ISO8859-1/books/handbook book.sgml doc/en_US.ISO8859-1/books/handbook/introduction chapter.sgml doc/en_US.ISO8859-1/books/handbook/install chapter.sgml doc/share/sgml trademarks.ent X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 20:14:58 -0000 --+1TulI7fc0PCHNy3 Content-Type: multipart/mixed; boundary="eNMatiwYGLtwo1cJ" Content-Disposition: inline --eNMatiwYGLtwo1cJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Moved to -doc] On 2003.08.18 20:34:53 -0700, Murray Stokely wrote: > On Tue, Aug 19, 2003 at 02:57:35AM +0200, Simon L. Nielsen wrote: > > I'm trying to make the stylesheet do this automatically without the need > > for an role attribute (which is the way it should really work IMO), but > > it's a bit more tricky than I thought. I though I could just make a > > list of trademarks that have been shown with trademark symbol, but it > > doesn't seem that DSSSL allow global/persistent variables, so for each > > trademark I have to go back and check if the current trademark have been > > shown with a trademark symbol before. >=20 > I only considered that for half a second before deciding it would be a > very silly things to waste tens of hours of my time on. ;) If you Hehe. It probably only took about 10 hours, but then again, I had never done any Scheme/DSSSL before :-). The patch I came up with actually works fairly well. Of course it probably needs some adjustment, but the base is there. It only display a trademark symbol for each trademark the first in a document for print/html, and the first time on each HTML page for html-split. Then we can just use the trademark entities/tags for all the referneces (or most). If somebody then add or remove a trademark reference, it will still do it right. It differentiates between trademarks references in normal text and titles so if there is a trademark in a title, the symbol will be displayed the first time in the title, and the first time in the normal text. I did some performance tests and even though the stylesheet has to go through the SGML tree quite a lot to look for trademarks, there wasn't any measurable performance hit. Anyway, patch is attached. Comments are very welcome. > really want to do this then check out the way that footnotes and > ulinks are counted inside chapters in Norm's stylesheets. There may > be some code you can use there, but I definitely think a simple > attribute is the way to go for now. Thanks for the foodnote pointer; it contained a very useable example. > > /me mumbles that it could have done in half an hour, if DSSSL had used a > > sensible language. :-) >=20 > You could probably add a pre-processing step in XSLT to add the > attributes automatically. I tried it briefly, but it complained a lot about all the SGML stuff. I might have done something wrong though. --=20 Simon L. Nielsen FreeBSD Documentation Team --eNMatiwYGLtwo1cJ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="doc-trademark-auto-dsssl.patch" Content-Transfer-Encoding: quoted-printable --- /FreeBSD/clean/doc/share/sgml/freebsd.dsl Fri Aug 15 13:40:43 2003 +++ doc/share/sgml/freebsd.dsl Tue Aug 19 16:05:47 2003 @@ -232,6 +232,26 @@ (literal "``") (process-children) (literal "''"))) + + ;; The special FreeBSD version of the trademark tag handling + ;; This function was more or less taken from the DocBook DSSSL + ;; stylesheets by Norman Walsh + (element trademark + (if (show-tm-symbol? (current-node)) + (make sequence + ($charseq$)=09 + (cond + ((equal? (attribute-string "class") (normalize "copyright")) + (make entity-ref name: "copy")) + ((equal? (attribute-string "class") (normalize "registered")) + (make entity-ref name: "reg")) + ((equal? (attribute-string "class") (normalize "service")) + (make element gi: "SUP" + (literal "SM"))) + (else + (make entity-ref name: "#8482")))) + ($charseq$))) + ]]> =20 @@ -669,6 +689,29 @@ scale: graphic-scale display?: display display-alignment: graphic-align))) + + ;; The special FreeBSD version of the trademark tag handling + ;; This function was more or less taken from the DocBook DSSSL + ;; stylesheets by Norman Walsh + (element trademark=20 + (if (show-tm-symbol? (current-node)) + (make sequence + ($charseq$) + (cond + ((equal? (attribute-string "class") (normalize "copyright")) + (literal "\copyright-sign;")) + ((equal? (attribute-string "class") (normalize "registered")) + (literal "\registered-sign;")) + ((equal? (attribute-string "class") (normalize "service")) + ($ss-seq$ + (literal "SM"))) + (else + (literal "\trade-mark-sign;")))) + ($charseq$))) + + ;; Make the trademark functions think print output has chunks + (define (chunk-parent nd) + (sgml-root-element nd)) + ]]> =20 =20 --eNMatiwYGLtwo1cJ-- --+1TulI7fc0PCHNy3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/QoU/h9pcDSc1mlERAoFdAKC+B3Xwl+tNqyeC/X8Dbcgh670EdgCgtgfl bzYBsk0gmrimdwDKCLN+qtU= =W8OV -----END PGP SIGNATURE----- --+1TulI7fc0PCHNy3-- From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 13:52:14 2003 Return-Path: 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 2310E16A4C0 for ; Tue, 19 Aug 2003 13:52:14 -0700 (PDT) Received: from adsl-63-198-56-213.dsl.snfc21.pacbell.net (adsl-63-198-56-213.dsl.snfc21.pacbell.net [63.198.56.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2A8B43F85 for ; Tue, 19 Aug 2003 13:52:12 -0700 (PDT) (envelope-from jd108@pacbell.net) Received: from pacbell.net (localhost [127.0.0.1]) ESMTP id h7JKqBLx001399 for ; Tue, 19 Aug 2003 13:52:11 -0700 (PDT) (envelope-from jd108@pacbell.net) Message-ID: <3F428DFB.9040705@pacbell.net> Date: Tue, 19 Aug 2003 13:52:11 -0700 From: "Joseph I. Davida" User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: doc@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD Architecture Handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 20:52:14 -0000 Hello, Short of having to print this myself, is it in a book I can purchase? Cheers, Joe From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 14:42:39 2003 Return-Path: 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 C3F7816A4BF for ; Tue, 19 Aug 2003 14:42:39 -0700 (PDT) Received: from server1.aluriasoftware.com (aluriasoftware.com [66.216.126.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF43C43FDD for ; Tue, 19 Aug 2003 14:42:38 -0700 (PDT) (envelope-from support@aluriasoftware.com) Received: from server1.aluriasoftware.com (localhost [127.0.0.1]) h7JLgcV29969 for ; Tue, 19 Aug 2003 16:42:38 -0500 Date: Tue, 19 Aug 2003 21:42:38 GMT To: doc@freebsd.org From: support@aluriasoftware.com Message-ID: <20030819174238116742support@aluriasoftware.com> In-reply-to: <200308192142.h7JLgaV29958@server1.aluriasoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Cerberus (ver. 1.4.1-rc10) by WebGroupMedia.com Subject: [Support #116742]: Re: Wicked screensaver X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 21:42:40 -0000 Thank you for writing to Aluria Software! Your support request tracking ID is 116742 We appreciate your business and look forward to exceeding your expectations. We wanted to assure you that your support request or question has been received and assigned a ticket number. Our goal is 100% customer satisfaction and we will do everything to meet that goal. If you have been unable to download the product you purchased, please view your product receipt that you received in your email. Your personal download link is in it! Generally we try to answer all support requests within 24-48 hours. If your support request has been assigned during non-business hours, please know that we work on a first come, first serve basis and it WILL be answered first thing in the morning. In the meantime, please visit our various support sites by going to www.aluriasoftware.com and clicking on the product in question. On the product page you will see a link for support. Click this to visit the tutorials we have posted there for you. Our support website is http://www.aluriasoftware.com/support.html We look forward to helping you! Aluria Software Support www.aluriasoftware.com fax: 407-833-8500 From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 15:07:38 2003 Return-Path: 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 9347B16A4BF for ; Tue, 19 Aug 2003 15:07:38 -0700 (PDT) Received: from basement.dartmouth.edu (basement.dartmouth.edu [129.170.17.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C24C43FD7 for ; Tue, 19 Aug 2003 15:07:35 -0700 (PDT) (envelope-from support-admin@basement.dartmouth.edu) Received: from basement.dartmouth.edu (IDENT:mailman@basement [127.0.0.1]) by basement.dartmouth.edu (8.11.6/8.11.6) with ESMTP id h7JM73806084 for ; Tue, 19 Aug 2003 18:07:03 -0400 Date: Tue, 19 Aug 2003 18:07:03 -0400 Message-Id: <200308192207.h7JM73806084@basement.dartmouth.edu> From: support-admin@basement.dartmouth.edu To: doc@freebsd.org X-Ack: no Sender: support-admin@basement.dartmouth.edu Errors-To: support-admin@basement.dartmouth.edu X-BeenThere: support@basement.dartmouth.edu X-Mailman-Version: 2.0.6 Precedence: bulk Subject: Your message to Support awaits moderator approval X-BeenThere: freebsd-doc@freebsd.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 22:07:38 -0000 Your mail to 'Support' with the subject {Virus?} Thank you! Is being held until the list moderator can review it for approval. The reason it is being held: Message has a suspicious header Either the message will get posted to the list, or you will receive notification of the moderator's decision. From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 15:25:09 2003 Return-Path: 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 CDEB116A4BF for ; Tue, 19 Aug 2003 15:25:09 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 265E243FAF for ; Tue, 19 Aug 2003 15:25:09 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 0E02110BF82; Wed, 20 Aug 2003 00:25:08 +0200 (CEST) Date: Wed, 20 Aug 2003 00:25:08 +0200 From: "Simon L. Nielsen" To: "Joseph I. Davida" Message-ID: <20030819222505.GI392@FreeBSD.org> References: <3F428DFB.9040705@pacbell.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gTtJ75FAzB1T2CN6" Content-Disposition: inline In-Reply-To: <3F428DFB.9040705@pacbell.net> User-Agent: Mutt/1.5.4i cc: freebsd-doc@freebsd.org Subject: Re: FreeBSD Architecture Handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2003 22:25:10 -0000 --gTtJ75FAzB1T2CN6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.08.19 13:52:11 -0700, Joseph I. Davida wrote: > Hello, > Short of having to print this myself, > is it in a book I can purchase? The FreeBSD Architecture Handbook was only created a few weeks ago, so I'm certain nobody has published it. I don't know if the Developers Handbook (which most of the Architecture Handbook was taken from) has ever been published, but I don't think so. It's also important to note that there are parts of the Architecture and Developers Handbook that are out of date - I have no idea how big a problem that is. --=20 Simon L. Nielsen FreeBSD Documentation Team --gTtJ75FAzB1T2CN6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/QqPBh9pcDSc1mlERAsR4AJ9tADnkaTiqK6hhLhfo0PWZXLVYUACgsOBZ 8DCFVESJQm9go4G0wvPJ7XU= =yT3S -----END PGP SIGNATURE----- --gTtJ75FAzB1T2CN6-- From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 18:45:37 2003 Return-Path: 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 174AC16A4BF for ; Tue, 19 Aug 2003 18:45:37 -0700 (PDT) Received: from pike.serverhost.net (pike.serverhost.net [216.71.32.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FDF843FBD for ; Tue, 19 Aug 2003 18:45:36 -0700 (PDT) (envelope-from dpate@pike.serverhost.net) Received: (from dpate@localhost) by pike.serverhost.net (8.11.6/8.11.6) id h7K1jZV09974; Tue, 19 Aug 2003 21:45:35 -0400 Date: Tue, 19 Aug 2003 21:45:35 -0400 Message-Id: <200308200145.h7K1jZV09974@pike.serverhost.net> To: freebsd-doc@FreeBSD.org References: <200308200145.h7K1jUO09958@pike.serverhost.net> In-Reply-To: <200308200145.h7K1jUO09958@pike.serverhost.net> From: "danchuk.com Responses will be automatically discarded" Subject: Re: **SPAM** Re: Details X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 01:45:37 -0000 Your mail has been rejected as spam. It was NOT received. If your email was not spam, please send a note to the original destination letting them know that this happened. - Thank you. (Please do not reply to this message, as it will not arrive at the original destination.) From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 18:58:38 2003 Return-Path: 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 9CE3916A4BF for ; Tue, 19 Aug 2003 18:58:38 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F5BA43F75 for ; Tue, 19 Aug 2003 18:58:38 -0700 (PDT) (envelope-from dcitconsult@earthlink.net) Received: from h-68-164-58-115.lsanca54.covad.net ([68.164.58.115] helo=babynt) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19pIF9-0000ze-00 for doc@FreeBSD.org; Tue, 19 Aug 2003 18:58:35 -0700 Message-ID: <000801c366be$4a543d80$6401a8c0@babynt> From: "David Collins" To: Date: Tue, 19 Aug 2003 18:56:36 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: freebsd install X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Collins List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 01:58:38 -0000 "Probing devices, please wait (this can take a while)... How long is "a while"? I have waited over 2 hours! David. From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 22:39:04 2003 Return-Path: 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 A4A6916A4BF; Tue, 19 Aug 2003 22:39:04 -0700 (PDT) Received: from builder.freebsdmall.com (builder.freebsdmall.com [65.86.180.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D3B43FCB; Tue, 19 Aug 2003 22:39:04 -0700 (PDT) (envelope-from murray@builder.freebsdmall.com) Received: (from root@localhost) by builder.freebsdmall.com (8.12.9/8.11.6) id h7K5d3Pk010646; Tue, 19 Aug 2003 22:39:03 -0700 (PDT) (envelope-from murray) Date: Tue, 19 Aug 2003 22:39:01 -0700 From: Murray Stokely To: "Simon L. Nielsen" Message-ID: <20030819223901.C235@freebsdmall.com> References: <200308171355.h7HDt5ii082681@repoman.freebsd.org> <20030817140406.GB391@FreeBSD.org> <20030818123221.C235@freebsdmall.com> <20030819005734.GC1489@FreeBSD.org> <20030818203453.R235@freebsdmall.com> <20030819201456.GH392@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030819201456.GH392@FreeBSD.org>; from simon@freebsd.org on Tue, Aug 19, 2003 at 10:14:56PM +0200 X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D cc: freebsd-doc@freebsd.org Subject: Re: cvs commit: doc/en_US.ISO8859-1/books/handbook book.sgml doc/en_US.ISO8859-1/books/handbook/introduction chapter.sgml doc/en_US.ISO8859-1/books/handbook/install chapter.sgml doc/share/sgml trademarks.ent X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 05:39:05 -0000 On Tue, Aug 19, 2003 at 10:14:56PM +0200, Simon L. Nielsen wrote: > The patch I came up with actually works fairly well. Of course it > probably needs some adjustment, but the base is there. Excellent. I haven't tried using this patch but it looks right on. Thanks! - Murray From owner-freebsd-doc@FreeBSD.ORG Tue Aug 19 23:31:04 2003 Return-Path: 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 3769D16A4BF for ; Tue, 19 Aug 2003 23:31:04 -0700 (PDT) Received: from bat.berlios.de (bat.berlios.de [195.37.77.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1DDC43FCB for ; Tue, 19 Aug 2003 23:31:02 -0700 (PDT) (envelope-from linuxnetmag-developers-admin@lists.berlios.de) Received: from bat.berlios.de (localhost [127.0.0.1])h7K6V0519287 for ; Wed, 20 Aug 2003 08:31:00 +0200 Date: Wed, 20 Aug 2003 08:31:00 +0200 Message-ID: <20030820063100.19281.64893.Mailman@bat.berlios.de> From: linuxnetmag-developers-admin@berlios.de To: doc@freebsd.org X-Ack: no Sender: linuxnetmag-developers-admin@berlios.de Errors-To: linuxnetmag-developers-admin@berlios.de X-BeenThere: linuxnetmag-developers@lists.berlios.de X-Mailman-Version: 2.0.11 Precedence: bulk Subject: Your message to Linuxnetmag-developers awaits moderator approval X-BeenThere: freebsd-doc@freebsd.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 06:31:04 -0000 Your mail to 'Linuxnetmag-developers' with the subject Re: Wicked screensaver Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 00:50:12 2003 Return-Path: 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 7FE4016A4C0; Wed, 20 Aug 2003 00:50:12 -0700 (PDT) Received: from abigail.blackend.org (blackend.org [212.11.35.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A68C43FA3; Wed, 20 Aug 2003 00:50:10 -0700 (PDT) (envelope-from marc@blackend.org) Received: from nosferatu.blackend.org (nosferatu.blackend.org [192.168.10.205]) by abigail.blackend.org (8.12.9/8.12.3) with ESMTP id h7K7o1SB014225; Wed, 20 Aug 2003 09:50:01 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: from nosferatu.blackend.org (localhost [127.0.0.1]) h7K7nI9v000612; Wed, 20 Aug 2003 09:49:18 +0200 (CEST) (envelope-from marc@nosferatu.blackend.org) Received: (from marc@localhost) by nosferatu.blackend.org (8.12.9/8.12.9/Submit) id h7K7nHEF000611; Wed, 20 Aug 2003 09:49:17 +0200 (CEST) (envelope-from marc) Date: Wed, 20 Aug 2003 09:49:17 +0200 From: Marc Fonvieille To: freebsd-questions@FreeBSD.org Message-ID: <20030820074917.GA560@nosferatu.blackend.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.4i X-Useless-Header: blackend.org X-Operating-System: FreeBSD 5.1-CURRENT cc: freebsd-doc@FreeBSD.org cc: dcitconsult@earthlink.net Subject: [dcitconsult@earthlink.net: freebsd install] X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 07:50:12 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [message forwarded to freebsd-questions@] Hello, freebsd-questions is the right mailing list for this sort of questions, freebsd-doc is only for documentation issues etc. About your question, we need more informations to help you. Marc --+HP7ph2BbKc20aGI Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by abigail.blackend.org (8.12.9/8.12.3) with ESMTP id h7K1wlSB099198 for ; Wed, 20 Aug 2003 03:58:47 +0200 (CEST) (envelope-from owner-freebsd-doc@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id E1630563AA for ; Tue, 19 Aug 2003 18:58:45 -0700 (PDT) (envelope-from owner-freebsd-doc@freebsd.org) Received: by hub.freebsd.org (Postfix) id A99CF16A4D7; Tue, 19 Aug 2003 18:58:45 -0700 (PDT) Delivered-To: blackend@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 87D9C16A4C2; Tue, 19 Aug 2003 18:58:45 -0700 (PDT) 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 9CE3916A4BF for ; Tue, 19 Aug 2003 18:58:38 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F5BA43F75 for ; Tue, 19 Aug 2003 18:58:38 -0700 (PDT) (envelope-from dcitconsult@earthlink.net) Received: from h-68-164-58-115.lsanca54.covad.net ([68.164.58.115] helo=babynt) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19pIF9-0000ze-00 for doc@FreeBSD.org; Tue, 19 Aug 2003 18:58:35 -0700 Message-ID: <000801c366be$4a543d80$6401a8c0@babynt> From: "David Collins" To: Date: Tue, 19 Aug 2003 18:56:36 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: freebsd install X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Collins List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-doc@freebsd.org Errors-To: owner-freebsd-doc@freebsd.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by abigail.blackend.org id h7K1wlSB099198 "Probing devices, please wait (this can take a while)... How long is "a while"? I have waited over 2 hours! David. _______________________________________________ freebsd-doc@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-doc To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" --+HP7ph2BbKc20aGI-- From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 03:14:22 2003 Return-Path: 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 98F8816A4BF for ; Wed, 20 Aug 2003 03:14:22 -0700 (PDT) Received: from morpheus.globalsources.com (morpheus.globalsources.com [202.160.251.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A2F143F93 for ; Wed, 20 Aug 2003 03:14:21 -0700 (PDT) (envelope-from itsecurity@morpheus.globalsources.com) Received: from cwns1.globalsources.com (morpheus.globalsources.com [192.168.54.91]) by morpheus.globalsources.com with SMTP id h7KA606T013493 for doc@FreeBSD.org; Wed, 20 Aug 2003 18:06:00 +0800 Date: Wed, 20 Aug 2003 18:06:00 +0800 From: IT Security Message-Id: <200308201006.h7KA606T013493@morpheus.globalsources.com> To: doc@FreeBSD.org Subject: Re: Re: Approved X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 10:14:22 -0000 *** security warning - do not reply *** Our e-mail gateway has detected your message to wilsonf@globalsources.com contains an attachment, "thank_you.pif" , which could possibly contain a virus. To avoid the spread of viruses our system will not permit the delivery of such attachments. Please remove the attachement and re-send the e-mail. We apologise if this causes any inconvenience and hope you will understand this necessary precaution. From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 03:32:17 2003 Return-Path: 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 485F016A4C0 for ; Wed, 20 Aug 2003 03:32:17 -0700 (PDT) Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D88943FF2 for ; Wed, 20 Aug 2003 03:32:03 -0700 (PDT) (envelope-from ro@TechFak.Uni-Bielefeld.DE) Received: (from ro@localhost) (8.11.7+Sun/8.11.6/TechFak/2003/04/16/pk) id h7KAW1I21017 for freebsd-doc@FreeBSD.org; Wed, 20 Aug 2003 12:32:01 +0200 (MEST) Date: Wed, 20 Aug 2003 12:32:01 +0200 (MEST) Message-Id: <200308201032.h7KAW1I21017@momotombo.TechFak.Uni-Bielefeld.DE> To: freebsd-doc@FreeBSD.org Auto-Submitted: auto-replied X-Mailer: vacation 1.46 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 From: ro@TechFak.Uni-Bielefeld.DE (Rainer Orth - via the vacation program) Subject: Re: Thank you! X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 10:32:17 -0000 Thanks for your email. I will read it once I'm back from vacation on September 1st. In case of urgent questions regarding the computer systems of the Faculty of Technology, please contact one of * postmaster@TechFak.Uni-Bielefeld.DE for email-related requests and anything not covered by the next two * hostmaster@TechFak.Uni-Bielefeld.DE for issues with the domain name system * webmaster@TechFak.Uni-Bielefeld.DE for questions about our web server With best regards. Rainer Orth From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 05:04:59 2003 Return-Path: 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 DA9C916A4BF for ; Wed, 20 Aug 2003 05:04:59 -0700 (PDT) Received: from webmail.altiris.com (webmail.altiris.com [64.90.198.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2702943FAF for ; Wed, 20 Aug 2003 05:04:59 -0700 (PDT) (envelope-from americas.support@altiris.com) Received: from OpenXDBMail ([172.16.0.39]) by webmail.altiris.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Aug 2003 06:04:57 -0600 From: Altiris Technical Support - Americas To: doc@FreeBSD.org Date: Wed, 20 Aug 2003 06:04:57 -0700 X-Mailer: OpenX DBMail 1.0 X-Priority: 3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 20 Aug 2003 12:04:58.0137 (UTC) FILETIME=[46807890:01C36713] Subject: RE: Item #41861 - Re: Wicked screensaver X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 12:05:00 -0000 Thank you for contacting Altiris Technical Support. We have received = your email and have created a work item for this issue in our Helpdesk = system. The work item number is #41861. Please include this number = (including the 'Item #' prefix) in the subject line of any = correspondence about this issue, so it will be routed properly. Emails = will be answered in the order that they are received. For critical = issues please contact our Support Team at 801-226-8500 Option 2. Thank = you for choosing Altiris products! Altiris Technical Support http://www.altiris.com/support/ From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 05:50:21 2003 Return-Path: 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 37CB616A4BF for ; Wed, 20 Aug 2003 05:50:21 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B96AD43F85 for ; Wed, 20 Aug 2003 05:50:19 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7KCoJUp015134 for ; Wed, 20 Aug 2003 05:50:19 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7KCoJBB015133; Wed, 20 Aug 2003 05:50:19 -0700 (PDT) Resent-Date: Wed, 20 Aug 2003 05:50:19 -0700 (PDT) Resent-Message-Id: <200308201250.h7KCoJBB015133@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, Igor Ahmetov Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3291416A4BF for ; Wed, 20 Aug 2003 05:43:06 -0700 (PDT) Received: from aps.mark-itt.ru (aps.mark-itt.ru [217.14.192.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6247143FE0 for ; Wed, 20 Aug 2003 05:43:03 -0700 (PDT) (envelope-from ahmetov@rain.ifmo.ru) Received: from [217.14.193.194] (HELO localhost.my.domain) by aps.mark-itt.ru (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 56137332 for FreeBSD-gnats-submit@freebsd.org; Wed, 20 Aug 2003 17:42:48 +0500 Received: from igor by localhost.my.domain with local (Exim 4.20) id 124EDE-0000de-VA for FreeBSD-gnats-submit@freebsd.org; Sat, 01 Jan 2000 05:24:12 +0300 Message-Id: From: Igor Ahmetov Sender: Igor Ahmetov To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/55805: a little correction to the arch-handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Ahmetov List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 20 Aug 2003 12:50:21 -0000 X-Original-Date: Sat, 01 Jan 2000 05:24:12 +0300 X-List-Received-Date: Wed, 20 Aug 2003 12:50:21 -0000 >Number: 55805 >Category: docs >Synopsis: a little correction to the arch-handbook >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 20 05:50:18 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Igor Ahmetov >Release: FreeBSD 5.1-CURRENT i386 >Organization: >Environment: System: FreeBSD localhost.my.domain 5.1-CURRENT FreeBSD 5.1-CURRENT #4: Mon Aug 18 22:25:50 MSD 2003 root@localhost.my.domain:/usr/obj/usr/src/sys/CUSTOM i386 >Description: Looking into the example in section 13.4 of the arch-handbook (driverbasics/chapter.sgml), we see a declaration: typedef struct s_echo { char msg[BUFFERSIZE]; int len; } t_echo; And later, in function echo_write, the following statement: *(echomsg->msg + MIN(uio->uio_iov->iov_len,BUFFERSIZE)) = 0; So isn't it more correct to declare member msg of struct s_echo as char msg[BUFFERSIZE + 1]? >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 07:41:59 2003 Return-Path: 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 68E5416A4BF for ; Wed, 20 Aug 2003 07:41:59 -0700 (PDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 860E643FB1 for ; Wed, 20 Aug 2003 07:41:58 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.237.24.175]) by out005.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030820144157.CWKW15786.out005.verizon.net@mac.com>; Wed, 20 Aug 2003 09:41:57 -0500 Message-ID: <3F43889C.8080708@mac.com> Date: Wed, 20 Aug 2003 10:41:32 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Collins References: <000801c366be$4a543d80$6401a8c0@babynt> In-Reply-To: <000801c366be$4a543d80$6401a8c0@babynt> X-Enigmail-Version: 0.76.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [68.237.24.175] at Wed, 20 Aug 2003 09:41:47 -0500 cc: doc@FreeBSD.org Subject: Re: freebsd install X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 14:41:59 -0000 David Collins wrote: > "Probing devices, please wait (this can take a while)... > > How long is "a while"? I have waited over 2 hours! Please use the freebsd-questions mailing list instead of docs for this kind of question. Anyway, to give you an answer, it should only be a few seconds: your machine may have crashed when probing the hardware. Make sure that BIOS "PNP OS" setting is set to "NO" and disable any hardware you don't need in the BIOS and in the FreeBSD initial config screen. If you still have problems, then provide more details (what version of FreeBSD, what hardware you have) to . Thanks, -- -Chuck From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 08:18:08 2003 Return-Path: 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 BF05316A4BF for ; Wed, 20 Aug 2003 08:18:08 -0700 (PDT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCC9B43FB1 for ; Wed, 20 Aug 2003 08:18:07 -0700 (PDT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (acs-24-154-229-196.zoominternet.net [24.154.229.196]) by pittgoth.com (8.12.9/8.12.9) with SMTP id h7KFI6vd040756 for ; Wed, 20 Aug 2003 11:18:06 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 20 Aug 2003 11:00:31 -0400 From: Tom Rhodes To: FreeBSD-doc@FreeBSD.org Message-Id: <20030820110031.6953360b.trhodes@FreeBSD.org> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Kerberos in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 15:18:09 -0000 Greetings, I'm pondering the following question: What exactly do we do with the kerberos information in the handbook? I have a Kerberos5 document which is nearly complete, should it: o Be a new chapter? o Be added as a second part to the current KerberosIV information? o Should I place it in the Security chapter, move the current section to KerberosIV, add a note that Kerberos5 is only in FreeBSD 5.1 and beyond? I'm leaning toward the last option but would like a few general comments first. -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 08:52:13 2003 Return-Path: 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 3CE9D16A4BF for ; Wed, 20 Aug 2003 08:52:13 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FAC443FBF for ; Wed, 20 Aug 2003 08:52:12 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id 89CB4A6 for ; Wed, 20 Aug 2003 09:52:11 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7KFqBg06092 for FreeBSD-doc@freebsd.org; Wed, 20 Aug 2003 09:52:11 -0600 Date: Wed, 20 Aug 2003 09:52:11 -0600 From: Tillman Hodgson To: FreeBSD-doc@freebsd.org Message-ID: <20030820095211.Y2526@seekingfire.com> References: <20030820110031.6953360b.trhodes@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030820110031.6953360b.trhodes@FreeBSD.org>; from trhodes@freebsd.org on Wed, Aug 20, 2003 at 11:00:31AM -0400 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: Kerberos in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 15:52:13 -0000 On Wed, Aug 20, 2003 at 11:00:31AM -0400, Tom Rhodes wrote: > Greetings, > > I'm pondering the following question: > > What exactly do we do with the kerberos information in the handbook? > I have a Kerberos5 document which is nearly complete, should it: > > o Be a new chapter? > o Be added as a second part to the current KerberosIV information? > o Should I place it in the Security chapter, move the current section > to KerberosIV, add a note that Kerberos5 is only in FreeBSD 5.1 and > beyond? > > I'm leaning toward the last option but would like a few general > comments first. If you go with option 3, I'd clarify it by saying that "Kerberos5 is the only version of Kerberos in FreeBSD 5.1 and beyond", otherwise it sounds like 4.X and newer didn't have Kerberos5. -T -- If you are not happy here and now, you never will be. Taisen Deshimaru From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 09:01:39 2003 Return-Path: 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 7140316A4C0; Wed, 20 Aug 2003 09:01:39 -0700 (PDT) Received: from Kain.sumuk.de (Kain.sumuk.de [213.221.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5810F43F3F; Wed, 20 Aug 2003 09:01:37 -0700 (PDT) (envelope-from vincent@sumuk.de) Received: from Moses.earth.sol (Moses.earth.sol [192.168.1.1]) by Kain.sumuk.de (8.12.9/8.12.8) with ESMTP id h7KG1ZZ6010519; Wed, 20 Aug 2003 18:01:35 +0200 (CEST) (envelope-from vincent@sumuk.de) Received: from Moses.earth.sol (localhost.earth.sol [127.0.0.1]) by Moses.earth.sol (8.12.5/8.12.5) with ESMTP id h7KG1YPg050686; Wed, 20 Aug 2003 18:01:34 +0200 (CEST) (envelope-from vincent@Moses.earth.sol) Received: (from vincent@localhost) by Moses.earth.sol (8.12.5/8.12.5/Submit) id h7KG1XXx050685; Wed, 20 Aug 2003 18:01:34 +0200 (CEST) Date: Wed, 20 Aug 2003 18:01:33 +0200 From: Martin Heinen To: Tom Rhodes Message-ID: <20030820180132.A44501@sumuk.de> References: <20030820110031.6953360b.trhodes@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030820110031.6953360b.trhodes@FreeBSD.org>; from trhodes@freebsd.org on Wed, Aug 20, 2003 at 11:00:31AM -0400 cc: FreeBSD-doc@freebsd.org Subject: Re: Kerberos in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 20 Aug 2003 16:01:39 -0000 On Wed, Aug 20, 2003 at 11:00:31AM -0400, Tom Rhodes wrote: > What exactly do we do with the kerberos information in the handbook? > I have a Kerberos5 document which is nearly complete, should it: > > o Be a new chapter? > o Be added as a second part to the current KerberosIV information? > o Should I place it in the Security chapter, move the current section > to KerberosIV, add a note that Kerberos5 is only in FreeBSD 5.1 and > beyond? > > I'm leaning toward the last option but would like a few general > comments first. Kerberos V5 is the recommended version nowadays. The new Kerberos V5 chapter should replace the existing chapter. We could add a subsection describing the differences to Kerberos V4 (there shouldn't be many). -- Marxpitn From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 09:20:35 2003 Return-Path: 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 0B88216A4BF for ; Wed, 20 Aug 2003 09:20:35 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20BF643FEA for ; Wed, 20 Aug 2003 09:20:34 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id 9921592 for ; Wed, 20 Aug 2003 10:20:33 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7KGKXw06215 for FreeBSD-doc@freebsd.org; Wed, 20 Aug 2003 10:20:33 -0600 Date: Wed, 20 Aug 2003 10:20:33 -0600 From: Tillman Hodgson To: FreeBSD-doc@freebsd.org Message-ID: <20030820102033.B2526@seekingfire.com> References: <20030820110031.6953360b.trhodes@FreeBSD.org> <20030820180132.A44501@sumuk.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030820180132.A44501@sumuk.de>; from martin@sumuk.de on Wed, Aug 20, 2003 at 06:01:33PM +0200 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: Kerberos in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 16:20:35 -0000 On Wed, Aug 20, 2003 at 06:01:33PM +0200, Martin Heinen wrote: > On Wed, Aug 20, 2003 at 11:00:31AM -0400, Tom Rhodes wrote: > > > What exactly do we do with the kerberos information in the handbook? > > I have a Kerberos5 document which is nearly complete, should it: > > > > o Be a new chapter? > > o Be added as a second part to the current KerberosIV information? > > o Should I place it in the Security chapter, move the current section > > to KerberosIV, add a note that Kerberos5 is only in FreeBSD 5.1 and > > beyond? > > > > I'm leaning toward the last option but would like a few general > > comments first. > > Kerberos V5 is the recommended version nowadays. True. > The new Kerberos V5 chapter should replace the > existing chapter. We could add a subsection > describing the differences to Kerberos V4 (there > shouldn't be many). I wouldn't want to maintain differences spread through the V5 chapter - once pre-5.1 versions are no longer supported it's easier to drop the existing V4 section that to re-write the V5 section. There are folks out there with existing V4 realms that they need to connect to (as opposed to building a new V5 realm from scratch), and for that the existing V4 chapter could be kept untouched. -T -- How refreshing, the whinny of a packhorse unloaded of everything! - Zen saying From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 11:28:56 2003 Return-Path: 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 1BC9B16A4C0 for ; Wed, 20 Aug 2003 11:28:56 -0700 (PDT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AC5C43F93 for ; Wed, 20 Aug 2003 11:28:54 -0700 (PDT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HJX00HT4JUQUJ@ms-dienst.rz.rwth-aachen.de> for FreeBSD-doc@freebsd.org; Wed, 20 Aug 2003 20:11:15 +0200 (MEST) Received: from relay.RWTH-Aachen.DE ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Wed, 20 Aug 2003 20:05:30 +0200 (MEST) Received: from haakonia.hitnet.rwth-aachen.de (daemon@haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) h7KI5TaW029853; Wed, 20 Aug 2003 20:05:29 +0200 (MEST) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) by haakonia.hitnet.rwth-aachen.de (Postfix) with ESMTP id 3F38633; Wed, 20 Aug 2003 18:05:29 +0000 (GMT) Received: by gondor.middleearth (Postfix, from userid 1001) id 0ED8D4534; Wed, 20 Aug 2003 20:05:27 +0200 (CEST) Date: Wed, 20 Aug 2003 20:05:26 +0200 From: Christian Brueffer In-reply-to: <20030820102033.B2526@seekingfire.com> To: Tillman Hodgson Message-id: <20030820180526.GA29763@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=tKW2IUtsqtDRztdT; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <20030820110031.6953360b.trhodes@FreeBSD.org> <20030820180132.A44501@sumuk.de> <20030820102033.B2526@seekingfire.com> cc: FreeBSD-doc@freebsd.org Subject: Re: Kerberos in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 18:28:56 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 20, 2003 at 10:20:33AM -0600, Tillman Hodgson wrote: >=20 > > The new Kerberos V5 chapter should replace the > > existing chapter. We could add a subsection > > describing the differences to Kerberos V4 (there > > shouldn't be many). >=20 > I wouldn't want to maintain differences spread through the V5 chapter - > once pre-5.1 versions are no longer supported it's easier to drop the > existing V4 section that to re-write the V5 section. >=20 > There are folks out there with existing V4 realms that they need to > connect to (as opposed to building a new V5 realm from scratch), and for > that the existing V4 chapter could be kept untouched. >=20 I agree, the V4 chapter doesn't hurt anyone. A note in the V4 chapter, mentioning that V5 is preferred, should suffice. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/Q7hmbHYXjKDtmC0RAkJeAJ4iJqcSzy6NjHVc8YWhGVz6GR4OTACfcBH0 Ac8Pm7zG6KY+le0Hk6Ch9zQ= =vHjz -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 11:34:01 2003 Return-Path: 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 DB7D216A4BF for ; Wed, 20 Aug 2003 11:34:01 -0700 (PDT) Received: from ns3.bangla.net (ns3.bangla.net [203.188.252.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id D873043FCB for ; Wed, 20 Aug 2003 11:33:56 -0700 (PDT) (envelope-from abulfazl@juniv.edu) Received: (from uucp@localhost) by ns3.bangla.net (8.10.2/8.10.2) with UUCP id h7KILSm09537; Thu, 21 Aug 2003 00:21:28 +0600 Received: from Imrashi.net.bd ([192.168.1.100]) by ju.juniv.edu (8.8.5/8.8.5) with ESMTP id XAA04843; Wed, 20 Aug 2003 23:36:26 +0600 Received: by Imrashi.net.bd (Postfix, from userid 1001) id 0EF0A580E; Wed, 20 Aug 2003 23:47:23 +0600 (BDT) Date: Wed, 20 Aug 2003 23:47:23 +0600 From: Progga To: Chuck Swiger Message-ID: <20030820234723.B407@Imrashi.net.bd> References: <000801c366be$4a543d80$6401a8c0@babynt> <3F43889C.8080708@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F43889C.8080708@mac.com>; from cswiger@mac.com on Wed, Aug 20, 2003 at 10:41:32AM -0400 X-Operating-System: FreeBSD 4.6.2-RELEASE i386 cc: David Collins cc: doc@freebsd.org Subject: Re: freebsd install X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 18:34:02 -0000 On Wed, Aug 20, 2003 at 10:41:32AM -0400, Chuck Swiger wrote: > > Make sure that BIOS "PNP OS" setting is set to "NO" Is this very important info mentioned in any FreeBSD docs ? When I installed FreeBSD 4.6.2-RELEASE a year ago, the sound card (Creative Vibra - es1371) didn't work. Compiling the Kernel did no good. After almost a year later, I came to know this info from a very old GNU/Linux newusers HOWTO. I tried it without much hope and the sound card worked! I faced a similar situation with the printer too. Fortunately the person who gave me FreeBSD CDs told me to change the parallel port's value from 'auto' to 'enable' in BIOS settings (Phonix BUOS) and the printer worked immediately after installation. The 'FAQ' doesn't address these issues AFAIK and I also forgot to send these infos earlier ;-) Khoda Hafez Progga * The motherboard is 'Intel 440 BX2'. From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 11:56:11 2003 Return-Path: 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 B766416A4BF for ; Wed, 20 Aug 2003 11:56:11 -0700 (PDT) Received: from smtp100.mail.sc5.yahoo.com (smtp100.mail.sc5.yahoo.com [216.136.174.138]) by mx1.FreeBSD.org (Postfix) with SMTP id 425D243F75 for ; Wed, 20 Aug 2003 11:56:11 -0700 (PDT) (envelope-from gregw_work@yahoo.com) Received: from ool-44c63a8c.dyn.optonline.net (HELO yahoo.com) (gregw?work@68.198.58.140 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Aug 2003 17:34:38 -0000 Message-ID: <3F43B127.2030807@yahoo.com> Date: Wed, 20 Aug 2003 13:34:31 -0400 From: Greg Weiss Organization: PlezeCall User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: doc@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: feedback, security documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gregw_work@yahoo.com List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 18:56:12 -0000 Being totally new to FreeBSD (but not Unix or BSD), I thought I'd give you a heads up to the first thing I noticed in your documentation. The FreeBSD Handbook, in the Security section, talks about setting up a system securely but seems to totally omit the security process; ie how to keep your machine patched against the exploits that constantly arrive in the wild. Where to find notifications of security patches, etc. Which is the first thing I went to look for since I received a system already setup. I did eventually find info in the "errata" portion of the release notes, but it probably is worth mentioning elsewhere for newcomers like myself. Perhaps a 10.3.10 section, titled "Check regularly for security advisories", with at a minimum, something like this:

Keeping your system updated with the latest security patches is an important aspect of system security. You may want to subscribe to various email lists for this purpose. You can find FreeBSD security advisories within the release notes of the latest version of FreeBSD, at: http://www.freebsd.org/releases/4.8R/errata.html http://www.freebsd.org/releases/5.0R/errata.html

I hope you will accept this constructive cricism in the positive light it is intended. Thanks for the fine work. Good luck, Greg Weiss From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 12:10:57 2003 Return-Path: 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 1C0C916A4BF; Wed, 20 Aug 2003 12:10:57 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 545D443F85; Wed, 20 Aug 2003 12:10:56 -0700 (PDT) (envelope-from underway@comcast.net) Received: from localhost.localdomain (12-230-74-101.client.attbi.com[12.230.74.101](untrusted sender)) by attbi.com (rwcrmhc12) with ESMTP id <20030820190635014000btsje>; Wed, 20 Aug 2003 19:06:35 +0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.9/8.12.9) with ESMTP id h7KJ6JSE069575; Wed, 20 Aug 2003 12:06:20 -0700 (PDT) (envelope-from underway@comcast.net) Received: (from jojo@localhost) by localhost.localdomain (8.12.9/8.12.9/Submit) id h7KJ6ES1069574; Wed, 20 Aug 2003 12:06:14 -0700 (PDT) (envelope-from underway@comcast.net) To: Tom Rhodes References: <20030820110031.6953360b.trhodes@FreeBSD.org> From: underway@comcast.net (Gary W. Swearingen) Date: Wed, 20 Aug 2003 12:06:14 -0700 In-Reply-To: <20030820110031.6953360b.trhodes@FreeBSD.org> (Tom Rhodes's message of "Wed, 20 Aug 2003 11:00:31 -0400") Message-ID: <98k7986teh.798@mail.comcast.net> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.1 (Cuyahoga Valley, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: FreeBSD-doc@FreeBSD.org Subject: Re: Kerberos in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 19:10:57 -0000 Tom Rhodes writes: > Greetings, > > I'm pondering the following question: > > What exactly do we do with the kerberos information in the handbook? > I have a Kerberos5 document which is nearly complete, should it: > > o Be a new chapter? > o Be added as a second part to the current KerberosIV information? > o Should I place it in the Security chapter, move the current section > to KerberosIV, add a note that Kerberos5 is only in FreeBSD 5.1 and > beyond? > > I'm leaning toward the last option but would like a few general > comments first. All of the Kerberos info should be in one sub-chapter (eg, 10.6) with "Kerberos" in the title. If krb4 is used by very few people, then it should be relegated to an article, with a note to that effect in the sub-chapter's intro. Otherwise, there should be two sub-sub-chapters (eg, 10.6.1 and .2), with the one that's expected to have the most readers comming first. (Unless krb4 is more popular only in 4.x in which case it probably should come first in keeping with the current 4.x vs. 5.x documenting style of the handbook, in which 5.x is covered by side-notes, etc.) If you expect more than a few people to need krb4 info, don't force them to mind-meld the krb5 info with "4/5 diff" info, unless the diff is really trivial or very well done. IMO, the handbook should concentrate on helping people with the software they are expected to want help with, and not use quality or availability of documentation as a means to try to influence their choice of software. It should even be careful about too much recommending and deprecating. Which reminds me of another pet peeve: the handbook often uses the weasel-words "not recommend", as in: We do not recommend modifying these values. instead of We recommend that you not modify these values. or We recommend that these values not be modified. It probably shouldn't even use "we": These values should not be modified, because [...]. From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 13:12:18 2003 Return-Path: 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 05AE816A4C1 for ; Wed, 20 Aug 2003 13:12:18 -0700 (PDT) Received: from abigail.blackend.org (blackend.org [212.11.35.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66A0443FF5 for ; Wed, 20 Aug 2003 13:12:16 -0700 (PDT) (envelope-from marc@blackend.org) Received: from nosferatu.blackend.org (nosferatu.blackend.org [192.168.10.205]) by abigail.blackend.org (8.12.9/8.12.3) with ESMTP id h7KKCESB022447; Wed, 20 Aug 2003 22:12:14 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: from nosferatu.blackend.org (localhost [127.0.0.1]) h7KKBY9v002519; Wed, 20 Aug 2003 22:11:34 +0200 (CEST) (envelope-from marc@nosferatu.blackend.org) Received: (from marc@localhost) by nosferatu.blackend.org (8.12.9/8.12.9/Submit) id h7KKBXoi002518; Wed, 20 Aug 2003 22:11:33 +0200 (CEST) (envelope-from marc) Date: Wed, 20 Aug 2003 22:11:33 +0200 From: Marc Fonvieille To: Greg Weiss Message-ID: <20030820201133.GC560@nosferatu.blackend.org> References: <3F43B127.2030807@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F43B127.2030807@yahoo.com> User-Agent: Mutt/1.4i X-Useless-Header: blackend.org X-Operating-System: FreeBSD 5.1-CURRENT cc: doc@FreeBSD.org Subject: Re: feedback, security documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 20:12:18 -0000 On Wed, Aug 20, 2003 at 01:34:31PM -0400, Greg Weiss wrote: [...] > > Perhaps a 10.3.10 section, titled "Check regularly for security advisories", > with at a minimum, something like this: > >

Keeping your system updated with the latest security patches > is an important aspect of system security. You may want to > subscribe to various email lists for this purpose. You can > find FreeBSD security advisories within the release notes > of the latest version of FreeBSD, at: > http://www.freebsd.org/releases/4.8R/errata.html > http://www.freebsd.org/releases/5.0R/errata.html >

> > I hope you will accept this constructive cricism in the positive light it > is intended. Thanks for the fine work. > It is indeed a really good idea. I will add this section with some additions in the Handbook. Marc From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 13:43:54 2003 Return-Path: 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 7746516A4BF; Wed, 20 Aug 2003 13:43:54 -0700 (PDT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id A599443FBD; Wed, 20 Aug 2003 13:43:53 -0700 (PDT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (acs-24-154-229-196.zoominternet.net [24.154.229.196]) by pittgoth.com (8.12.9/8.12.9) with SMTP id h7KKhpvd041510; Wed, 20 Aug 2003 16:43:52 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 20 Aug 2003 16:26:16 -0400 From: Tom Rhodes To: Marc Fonvieille Message-Id: <20030820162616.2e0b53a2.trhodes@FreeBSD.org> In-Reply-To: <20030820201133.GC560@nosferatu.blackend.org> References: <3F43B127.2030807@yahoo.com> <20030820201133.GC560@nosferatu.blackend.org> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Greg Weiss cc: doc@FreeBSD.org Subject: Re: feedback, security documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 20:43:54 -0000 On Wed, 20 Aug 2003 22:11:33 +0200 Marc Fonvieille wrote: > On Wed, Aug 20, 2003 at 01:34:31PM -0400, Greg Weiss wrote: > [...] > > > > Perhaps a 10.3.10 section, titled "Check regularly for security advisories", > > with at a minimum, something like this: > > > >

Keeping your system updated with the latest security patches > > is an important aspect of system security. You may want to > > subscribe to various email lists for this purpose. You can > > find FreeBSD security advisories within the release notes > > of the latest version of FreeBSD, at: > > http://www.freebsd.org/releases/4.8R/errata.html > > http://www.freebsd.org/releases/5.0R/errata.html > >

> > > > I hope you will accept this constructive cricism in the positive light it > > is intended. Thanks for the fine work. > > > > It is indeed a really good idea. I will add this section with some > additions in the Handbook. > Heh, and this was one of the issues I was planning to address while working on this chapter; during the Kerberos5 addition. -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 13:47:31 2003 Return-Path: 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 DF7B616A4BF; Wed, 20 Aug 2003 13:47:31 -0700 (PDT) Received: from abigail.blackend.org (blackend.org [212.11.35.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A79043FE5; Wed, 20 Aug 2003 13:47:29 -0700 (PDT) (envelope-from marc@blackend.org) Received: from nosferatu.blackend.org (nosferatu.blackend.org [192.168.10.205]) by abigail.blackend.org (8.12.9/8.12.3) with ESMTP id h7KKlMSB022917; Wed, 20 Aug 2003 22:47:22 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: from nosferatu.blackend.org (localhost [127.0.0.1]) h7KKkg9v002601; Wed, 20 Aug 2003 22:46:42 +0200 (CEST) (envelope-from marc@nosferatu.blackend.org) Received: (from marc@localhost) by nosferatu.blackend.org (8.12.9/8.12.9/Submit) id h7KKkevX002600; Wed, 20 Aug 2003 22:46:40 +0200 (CEST) (envelope-from marc) Date: Wed, 20 Aug 2003 22:46:40 +0200 From: Marc Fonvieille To: Tom Rhodes Message-ID: <20030820204640.GE560@nosferatu.blackend.org> References: <3F43B127.2030807@yahoo.com> <20030820201133.GC560@nosferatu.blackend.org> <20030820162616.2e0b53a2.trhodes@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030820162616.2e0b53a2.trhodes@FreeBSD.org> User-Agent: Mutt/1.4i X-Useless-Header: blackend.org X-Operating-System: FreeBSD 5.1-CURRENT cc: Greg Weiss cc: doc@FreeBSD.org Subject: Re: feedback, security documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 20:47:32 -0000 On Wed, Aug 20, 2003 at 04:26:16PM -0400, Tom Rhodes wrote: > > Heh, and this was one of the issues I was planning to address while > working on this chapter; during the Kerberos5 addition. > Ok :) I let you fix it then. Marc From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 13:50:09 2003 Return-Path: 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 0F18716A4BF; Wed, 20 Aug 2003 13:50:09 -0700 (PDT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DD4843FEA; Wed, 20 Aug 2003 13:50:06 -0700 (PDT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (acs-24-154-229-196.zoominternet.net [24.154.229.196]) by pittgoth.com (8.12.9/8.12.9) with SMTP id h7KKo5vd041534; Wed, 20 Aug 2003 16:50:05 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 20 Aug 2003 16:32:30 -0400 From: Tom Rhodes To: Marc Fonvieille Message-Id: <20030820163230.6c0a75d8.trhodes@FreeBSD.org> In-Reply-To: <20030820204640.GE560@nosferatu.blackend.org> References: <3F43B127.2030807@yahoo.com> <20030820201133.GC560@nosferatu.blackend.org> <20030820162616.2e0b53a2.trhodes@FreeBSD.org> <20030820204640.GE560@nosferatu.blackend.org> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Greg Weiss cc: doc@FreeBSD.org Subject: Re: feedback, security documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 20:50:09 -0000 On Wed, 20 Aug 2003 22:46:40 +0200 Marc Fonvieille wrote: > On Wed, Aug 20, 2003 at 04:26:16PM -0400, Tom Rhodes wrote: > > > > Heh, and this was one of the issues I was planning to address while > > working on this chapter; during the Kerberos5 addition. > > > > Ok :) I let you fix it then. > > Marc > I should have shut up when/while I had the chance... My fiance is right, I would get myself into a lot less if I would just shut up, sit down, and keep drinking... -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 15:39:29 2003 Return-Path: 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 92E5B16A4BF; Wed, 20 Aug 2003 15:39:29 -0700 (PDT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D3D543FAF; Wed, 20 Aug 2003 15:39:28 -0700 (PDT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HJX00H8BW3TUJ@ms-dienst.rz.rwth-aachen.de>; Thu, 21 Aug 2003 00:35:54 +0200 (MEST) Received: from relay.RWTH-Aachen.DE ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 21 Aug 2003 00:35:53 +0200 (MEST) Received: from haakonia.hitnet.rwth-aachen.de (daemon@haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) h7KMZqaW014002; Thu, 21 Aug 2003 00:35:53 +0200 (MEST) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) by haakonia.hitnet.rwth-aachen.de (Postfix) with ESMTP id C148629; Wed, 20 Aug 2003 22:35:52 +0000 (GMT) Received: by gondor.middleearth (Postfix, from userid 1001) id 47BD84619; Thu, 21 Aug 2003 00:35:52 +0200 (CEST) Date: Thu, 21 Aug 2003 00:35:51 +0200 From: Christian Brueffer In-reply-to: <20030820163230.6c0a75d8.trhodes@FreeBSD.org> To: Tom Rhodes Message-id: <20030820223551.GB638@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=24zk1gE8NUlDmwG9; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <3F43B127.2030807@yahoo.com> <20030820201133.GC560@nosferatu.blackend.org> <20030820162616.2e0b53a2.trhodes@FreeBSD.org> <20030820204640.GE560@nosferatu.blackend.org> <20030820163230.6c0a75d8.trhodes@FreeBSD.org> cc: Greg Weiss cc: doc@freebsd.org Subject: Re: feedback, security documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 22:39:29 -0000 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 20, 2003 at 04:32:30PM -0400, Tom Rhodes wrote: > On Wed, 20 Aug 2003 22:46:40 +0200 > Marc Fonvieille wrote: >=20 > > On Wed, Aug 20, 2003 at 04:26:16PM -0400, Tom Rhodes wrote: > > >=20 > > > Heh, and this was one of the issues I was planning to address while > > > working on this chapter; during the Kerberos5 addition. > > > > >=20 > > Ok :) I let you fix it then. > >=20 > > Marc > >=20 >=20 > I should have shut up when/while I had the chance... >=20 > My fiance is right, I would get myself into a lot less if I would > just shut up, sit down, and keep drinking... >=20 Must be a FreeBSD wedding spree :-) Any date planned yet? - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/Q/fHbHYXjKDtmC0RAkUkAJ9u+Zs2ozcYgg0SC81zM7i6+fIJFQCeNdUs ItlQdC0MFxoUi9eZLlXUTjg= =OSUS -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 17:51:42 2003 Return-Path: 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 F0D2A16A4BF for ; Wed, 20 Aug 2003 17:51:42 -0700 (PDT) Received: from hueymiccailhuitl.mtu.ru (hueytecuilhuitl.mtu.ru [195.34.32.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F26843FBF for ; Wed, 20 Aug 2003 17:51:42 -0700 (PDT) (envelope-from sem@ciam.ru) Received: from ciam.ru (ppp138-245.dialup.mtu-net.ru [62.118.138.245]) by hueymiccailhuitl.mtu.ru (Postfix) with ESMTP id CEE04D9FA3 for ; Thu, 21 Aug 2003 04:51:40 +0400 (MSD) (envelope-from sem@ciam.ru) Message-ID: <3F44179D.9020601@ciam.ru> Date: Thu, 21 Aug 2003 04:51:41 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.3) Gecko/20030309 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: freebsd-doc@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: PR/46181 ports(7) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 00:51:43 -0000 I've submitted some updates for ports(7). Take a look please. ---- Sem. From owner-freebsd-doc@FreeBSD.ORG Wed Aug 20 21:58:44 2003 Return-Path: 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 BA0BF16A4BF for ; Wed, 20 Aug 2003 21:58:44 -0700 (PDT) Received: from web10001.mail.yahoo.com (web10001.mail.yahoo.com [216.136.130.37]) by mx1.FreeBSD.org (Postfix) with SMTP id 7ACAD43FCB for ; Wed, 20 Aug 2003 21:58:44 -0700 (PDT) (envelope-from kstailey@yahoo.com) Message-ID: <20030821045844.14151.qmail@web10001.mail.yahoo.com> Received: from [68.50.141.185] by web10001.mail.yahoo.com via HTTP; Wed, 20 Aug 2003 21:58:44 PDT Date: Wed, 20 Aug 2003 21:58:44 -0700 (PDT) From: Kenneth Stailey To: doc@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: WEB HOST INDUSTRY REVIEW - FreeBSD Story X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 04:58:45 -0000 http://thewhir.com/marketwatch/netc081903.cfm __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 06:50:22 2003 Return-Path: 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 61DE416A4BF for ; Thu, 21 Aug 2003 06:50:22 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 858DD43FBD for ; Thu, 21 Aug 2003 06:50:21 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7LDoLUp034184 for ; Thu, 21 Aug 2003 06:50:21 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7LDoLWR034183; Thu, 21 Aug 2003 06:50:21 -0700 (PDT) Resent-Date: Thu, 21 Aug 2003 06:50:21 -0700 (PDT) Resent-Message-Id: <200308211350.h7LDoLWR034183@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, Christian Wittenhorst Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8B7216A4BF for ; Thu, 21 Aug 2003 06:44:08 -0700 (PDT) Received: from mta.progon.net (mta.progon.net [62.65.155.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7776943FB1 for ; Thu, 21 Aug 2003 06:44:07 -0700 (PDT) (envelope-from wiwi@progon.net) Received: from beowulf (localhost [127.0.0.1]) by mta.progon.net (8.12.9/8.12.0.Beta12) with SMTP id h7LDgKld024872 for FreeBSD-gnats-submit@freebsd.org; Thu, 21 Aug 2003 13:42:43 GMT Message-Id: <200308211342.h7LDgKld024872@mta.progon.net> Date: Thu, 21 Aug 2003 13:42:20 GMT From: Christian Wittenhorst To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/55837: nice: man pages incorrect (4.8,5.0&5.1) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Christian Wittenhorst List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 13:50:22 -0000 >Number: 55837 >Category: docs >Synopsis: nice: man pages incorrect (4.8,5.0&5.1) >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: Thu Aug 21 06:50:20 PDT 2003 >Closed-Date: >Last-Modified: >Originator: wiwi >Release: FreeBSD 4.8-STABLE i386 >Organization: progon network engineering >Environment: System: FreeBSD sauron.kanti-zug.ch 4.8-STABLE FreeBSD 4.8-STABLE #2: Wed Jun 18 17:03:18 CEST 2003 wiwi@sauron.kanti-zug.ch:/usr/sr c/sys/compile/sauron i386 >Description: Man pages for nice(1) incorrect/outdated. SYNOPSIS nice [-n increment] utility [argument ...] ... EXAMPLES Execute utility `date' at priority 5 assuming the priority of the shell is 0: nice -n 5 date nice(1) only accepts nice +n ... (to increase niceness) or nice -n (to decrease). The samples provides do not work >How-To-Repeat: yellow:/home/sysadm/wiwi% nice -n 5 date nice: Badly formed number. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 07:00:39 2003 Return-Path: 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 769C716A4BF for ; Thu, 21 Aug 2003 07:00:39 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1605943FDD for ; Thu, 21 Aug 2003 07:00:39 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7LE0cUp034684 for ; Thu, 21 Aug 2003 07:00:38 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7LE0cZd034683; Thu, 21 Aug 2003 07:00:38 -0700 (PDT) Date: Thu, 21 Aug 2003 07:00:38 -0700 (PDT) Message-Id: <200308211400.h7LE0cZd034683@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: "Simon L. Nielsen" Subject: Re: docs/55837: nice: man pages incorrect (4.8,5.0&5.1) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Simon L. Nielsen" List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 14:00:39 -0000 The following reply was made to PR docs/55837; it has been noted by GNATS. From: "Simon L. Nielsen" To: Christian Wittenhorst Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: docs/55837: nice: man pages incorrect (4.8,5.0&5.1) Date: Thu, 21 Aug 2003 15:57:39 +0200 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.08.21 13:42:20 +0000, Christian Wittenhorst wrote: >=20 > >Number: 55837 > >Category: docs > >Synopsis: nice: man pages incorrect (4.8,5.0&5.1) > >How-To-Repeat: > yellow:/home/sysadm/wiwi% nice -n 5 date > nice: Badly formed number. Which shell are you using? Most shells have their own version of nice with different syntax than nice(1). e.g. : [simon@arthur:~] nice -n 10 echo Hello nice: Badly formed number. [simon@arthur:~] /usr/bin/nice -n 10 echo Hello Hello [simon@arthur:~] nice +10 echo Hello Hello =46rom nice(1) : Some shells may provide a builtin nice command which is similar or ide= n- tical to this utility. Consult the builtin(1) manual page. It think this is what you are seeing. --=20 Simon L. Nielsen FreeBSD Documentation Team --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/RM/Rh9pcDSc1mlERAkjaAJwJqFUfK1Yy6O5vEnaUV8tYTeEfvACgxGyR 7WAYquqJWpD90Ve14Ut74Wo= =1EMi -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 07:28:13 2003 Return-Path: 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 6848D16A4BF; Thu, 21 Aug 2003 07:28:13 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02D7E43F3F; Thu, 21 Aug 2003 07:28:13 -0700 (PDT) (envelope-from simon@FreeBSD.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7LESCUp040064; Thu, 21 Aug 2003 07:28:12 -0700 (PDT) (envelope-from simon@freefall.freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7LESCu1040060; Thu, 21 Aug 2003 07:28:12 -0700 (PDT) Date: Thu, 21 Aug 2003 07:28:12 -0700 (PDT) From: "Simon L. Nielsen" Message-Id: <200308211428.h7LESCu1040060@freefall.freebsd.org> To: l.ertl@univie.ac.at, simon@FreeBSD.org, freebsd-doc@FreeBSD.org Subject: Re: docs/55644: [PATCH] catch up cue(4) with hardware notes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 14:28:13 -0000 Synopsis: [PATCH] catch up cue(4) with hardware notes State-Changed-From-To: open->patched State-Changed-By: simon State-Changed-When: Thu Aug 21 07:27:02 PDT 2003 State-Changed-Why: Committed to -CURRENT. Thanks for the submission. http://www.freebsd.org/cgi/query-pr.cgi?pr=55644 From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 07:30:14 2003 Return-Path: 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 55BC416A4BF; Thu, 21 Aug 2003 07:30:14 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E042D43FBD; Thu, 21 Aug 2003 07:30:13 -0700 (PDT) (envelope-from simon@FreeBSD.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7LEUDUp040156; Thu, 21 Aug 2003 07:30:13 -0700 (PDT) (envelope-from simon@freefall.freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7LEUD1d040152; Thu, 21 Aug 2003 07:30:13 -0700 (PDT) Date: Thu, 21 Aug 2003 07:30:13 -0700 (PDT) From: "Simon L. Nielsen" Message-Id: <200308211430.h7LEUD1d040152@freefall.freebsd.org> To: simon@FreeBSD.org, freebsd-doc@FreeBSD.org, simon@FreeBSD.org Subject: Re: docs/55644: [PATCH] catch up cue(4) with hardware notes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 14:30:14 -0000 Synopsis: [PATCH] catch up cue(4) with hardware notes Responsible-Changed-From-To: freebsd-doc->simon Responsible-Changed-By: simon Responsible-Changed-When: Thu Aug 21 07:28:19 PDT 2003 Responsible-Changed-Why: Assign to me as MFC reminder (forgotten in last edit). http://www.freebsd.org/cgi/query-pr.cgi?pr=55644 From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 07:49:30 2003 Return-Path: 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 ADEEF16A4BF; Thu, 21 Aug 2003 07:49:30 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA95243FBD; Thu, 21 Aug 2003 07:49:29 -0700 (PDT) (envelope-from simon@FreeBSD.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7LEnTUp041071; Thu, 21 Aug 2003 07:49:29 -0700 (PDT) (envelope-from simon@freefall.freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7LEnTZm041067; Thu, 21 Aug 2003 07:49:29 -0700 (PDT) Date: Thu, 21 Aug 2003 07:49:29 -0700 (PDT) From: "Simon L. Nielsen" Message-Id: <200308211449.h7LEnTZm041067@freefall.freebsd.org> To: simon@FreeBSD.org, freebsd-doc@FreeBSD.org, simon@FreeBSD.org Subject: Re: docs/55639: [PATCH] catch up vr(4) with hardware notes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 14:49:31 -0000 Synopsis: [PATCH] catch up vr(4) with hardware notes Responsible-Changed-From-To: freebsd-doc->simon Responsible-Changed-By: simon Responsible-Changed-When: Thu Aug 21 07:49:20 PDT 2003 Responsible-Changed-Why: I will handle this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=55639 From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 08:19:58 2003 Return-Path: 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 DBB6C16A4BF; Thu, 21 Aug 2003 08:19:58 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4601143F75; Thu, 21 Aug 2003 08:19:58 -0700 (PDT) (envelope-from simon@FreeBSD.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7LFJwUp045710; Thu, 21 Aug 2003 08:19:58 -0700 (PDT) (envelope-from simon@freefall.freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7LFJvG7045706; Thu, 21 Aug 2003 08:19:57 -0700 (PDT) Date: Thu, 21 Aug 2003 08:19:57 -0700 (PDT) From: "Simon L. Nielsen" Message-Id: <200308211519.h7LFJvG7045706@freefall.freebsd.org> To: l.ertl@univie.ac.at, simon@FreeBSD.org, freebsd-doc@FreeBSD.org, simon@FreeBSD.org Subject: Re: docs/55636: [PATCH] catch up fe(4) with hardware notes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 15:19:59 -0000 Synopsis: [PATCH] catch up fe(4) with hardware notes State-Changed-From-To: open->patched State-Changed-By: simon State-Changed-When: Thu Aug 21 08:18:30 PDT 2003 State-Changed-Why: Committed to -CURRENT. Thanks for the submission! Responsible-Changed-From-To: freebsd-doc->simon Responsible-Changed-By: simon Responsible-Changed-When: Thu Aug 21 08:18:30 PDT 2003 Responsible-Changed-Why: My MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=55636 From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 08:41:57 2003 Return-Path: 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 5BD5F16A4BF; Thu, 21 Aug 2003 08:41:57 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA27243F93; Thu, 21 Aug 2003 08:41:56 -0700 (PDT) (envelope-from simon@FreeBSD.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7LFfuUp046808; Thu, 21 Aug 2003 08:41:56 -0700 (PDT) (envelope-from simon@freefall.freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7LFfuDU046804; Thu, 21 Aug 2003 08:41:56 -0700 (PDT) Date: Thu, 21 Aug 2003 08:41:56 -0700 (PDT) From: "Simon L. Nielsen" Message-Id: <200308211541.h7LFfuDU046804@freefall.freebsd.org> To: l.ertl@univie.ac.at, simon@FreeBSD.org, freebsd-doc@FreeBSD.org, simon@FreeBSD.org Subject: Re: docs/55659: [PATCH] catch up ep(4) with hardware notes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 15:41:57 -0000 Synopsis: [PATCH] catch up ep(4) with hardware notes State-Changed-From-To: open->patched State-Changed-By: simon State-Changed-When: Thu Aug 21 08:41:11 PDT 2003 State-Changed-Why: Committed to -CURRENT. Thanks for the submission! Responsible-Changed-From-To: freebsd-doc->simon Responsible-Changed-By: simon Responsible-Changed-When: Thu Aug 21 08:41:11 PDT 2003 Responsible-Changed-Why: My MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=55659 From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 09:18:14 2003 Return-Path: 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 307EA16A4BF for ; Thu, 21 Aug 2003 09:18:14 -0700 (PDT) Received: from mail.y-min.or.jp (mx.y-min.or.jp [211.10.195.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 0279B43F75 for ; Thu, 21 Aug 2003 09:18:13 -0700 (PDT) (envelope-from ) Received: (qmail 9585 invoked by uid 85); 22 Aug 2003 01:17:56 +0900 Date: 22 Aug 2003 01:17:56 +0900 From: "System Anti-Virus Administrator" To: freebsd-doc@freebsd.org Message-ID: X-Tnz-Problem-Type: 40 MIME-Version: 1.0 Content-type: text/plain cc: nob@mail.y-min.or.jp Subject: Illegal attachment type found in sent message "Re: Re: My details" X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 16:18:14 -0000 Attention: . A Illegal attachment type was found in an Email message you sent. This Email scanner intercepted it and stopped the entire message reaching it's destination. The Illegal attachment type was reported to be: Windows Program Information Files Please contact your I.T support personnel with any queries regarding this policy. Your message was sent with the following envelope: MAIL FROM: freebsd-doc@freebsd.org RCPT TO: nob@makioka.y-min.or.jp ... and with the following headers: From: To: Subject: Re: Re: My details Date: Fri, 22 Aug 2003 0:16:27 --0700 The original message is kept in: mail.y-min.or.jp:/var/spool/qmailscan/quarantine where the System Anti-Virus Administrator can further diagnose it. The Email scanner reported the following when it scanned that message: --- ---perlscanner results --- Illegal attachment type ' Windows Program Information Files' found in file /var/spool/qmailscan/mail.y-min.or.jp10614826654089580/document_all.pif --- From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 09:38:12 2003 Return-Path: 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 2010316A4BF for ; Thu, 21 Aug 2003 09:38:12 -0700 (PDT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5097043FA3 for ; Thu, 21 Aug 2003 09:38:11 -0700 (PDT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (acs-24-154-229-196.zoominternet.net [24.154.229.196]) by pittgoth.com (8.12.9/8.12.9) with SMTP id h7LGc4vd044463; Thu, 21 Aug 2003 12:38:09 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Thu, 21 Aug 2003 12:18:25 -0400 From: Tom Rhodes To: Christian Brueffer Message-Id: <20030821121825.61da1596.trhodes@FreeBSD.org> In-Reply-To: <20030820223551.GB638@unixpages.org> References: <3F43B127.2030807@yahoo.com> <20030820201133.GC560@nosferatu.blackend.org> <20030820162616.2e0b53a2.trhodes@FreeBSD.org> <20030820204640.GE560@nosferatu.blackend.org> <20030820163230.6c0a75d8.trhodes@FreeBSD.org> <20030820223551.GB638@unixpages.org> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: doc@FreeBSD.org Subject: Re: feedback, security documentation X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 16:38:12 -0000 On Thu, 21 Aug 2003 00:35:51 +0200 Christian Brueffer wrote: > On Wed, Aug 20, 2003 at 04:32:30PM -0400, Tom Rhodes wrote: > > On Wed, 20 Aug 2003 22:46:40 +0200 > > Marc Fonvieille wrote: > > > > > On Wed, Aug 20, 2003 at 04:26:16PM -0400, Tom Rhodes wrote: > > > > > > > > Heh, and this was one of the issues I was planning to address while > > > > working on this chapter; during the Kerberos5 addition. > > > > > > > > > > Ok :) I let you fix it then. > > > > > > Marc > > > > > > > I should have shut up when/while I had the chance... > > > > My fiance is right, I would get myself into a lot less if I would > > just shut up, sit down, and keep drinking... > > > > Must be a FreeBSD wedding spree :-) > > Any date planned yet? At this time we do not have a specific date. It will probably be close to a year from now... We have a ton of stuff to work out before hand. I look forward to hopefully sending an email to everyone with invites. :) -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Thu Aug 21 11:23:34 2003 Return-Path: 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 AA67116A4BF; Thu, 21 Aug 2003 11:23:34 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BA7F43FBF; Thu, 21 Aug 2003 11:23:34 -0700 (PDT) (envelope-from simon@FreeBSD.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7LINYUp070698; Thu, 21 Aug 2003 11:23:34 -0700 (PDT) (envelope-from simon@freefall.freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7LINYPi070694; Thu, 21 Aug 2003 11:23:34 -0700 (PDT) Date: Thu, 21 Aug 2003 11:23:34 -0700 (PDT) From: "Simon L. Nielsen" Message-Id: <200308211823.h7LINYPi070694@freefall.freebsd.org> To: simon@FreeBSD.org, freebsd-doc@FreeBSD.org, sos@FreeBSD.org Subject: Re: docs/55512: [PATCH] catch up ata(4) with hardware notes X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 18:23:35 -0000 Synopsis: [PATCH] catch up ata(4) with hardware notes Responsible-Changed-From-To: freebsd-doc->sos Responsible-Changed-By: simon Responsible-Changed-When: Thu Aug 21 11:22:01 PDT 2003 Responsible-Changed-Why: sos said he will deal with this when he updates the ATA driver (on -current a week ago). http://www.freebsd.org/cgi/query-pr.cgi?pr=55512 From owner-freebsd-doc@FreeBSD.ORG Fri Aug 22 16:10:27 2003 Return-Path: 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 BBA1216A4BF for ; Fri, 22 Aug 2003 16:10:27 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FFBD43FD7 for ; Fri, 22 Aug 2003 16:10:16 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7MNAGUp018100 for ; Fri, 22 Aug 2003 16:10:16 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7MNAGGa018099; Fri, 22 Aug 2003 16:10:16 -0700 (PDT) Resent-Date: Fri, 22 Aug 2003 16:10:16 -0700 (PDT) Resent-Message-Id: <200308222310.h7MNAGGa018099@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, Gea-Suan Lin Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E5C16A4C2 for ; Fri, 22 Aug 2003 16:03:17 -0700 (PDT) Received: from netnews.NCTU.edu.tw (ccreader.nctu.edu.tw [140.113.54.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DD5343FBD for ; Fri, 22 Aug 2003 16:03:04 -0700 (PDT) (envelope-from gslin@netnews.NCTU.edu.tw) Received: by netnews.NCTU.edu.tw (Postfix, from userid 1000) id 0528C43; Sat, 23 Aug 2003 07:03:00 +0800 (CST) Message-Id: <20030822230300.0528C43@netnews.NCTU.edu.tw> Date: Sat, 23 Aug 2003 07:03:00 +0800 (CST) From: Gea-Suan Lin To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 X-Mailman-Approved-At: Fri, 22 Aug 2003 16:20:42 -0700 cc: gslin@netnews.NCTU.edu.tw Subject: docs/55883: advanced-networking/chapter.sgml X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Gea-Suan Lin List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2003 23:10:28 -0000 >Number: 55883 >Category: docs >Synopsis: advanced-networking/chapter.sgml >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: Fri Aug 22 16:10:15 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Gea-Suan Lin >Release: FreeBSD 4.8-RELEASE-p1 i386 >Organization: >Environment: System: FreeBSD netnews.NCTU.edu.tw 4.8-RELEASE-p1 FreeBSD 4.8-RELEASE-p1 #0: Mon Aug 4 11:58:06 CST 2003 root@netnews.NCTU.edu.tw:/da0/usr.obj/da0/usr.src/sys/NETNEWS i386 >Description: IPFIREWALL_DEFAULT_TO_ACCEPT is not undocumented now. >How-To-Repeat: >Fix: --- /usr/doc/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml Mon Jul 21 21:35:50 2003 +++ chapter.sgml Sat Aug 23 07:00:11 2003 @@ -1,6773 +0,0 @@ - - - - Advanced Networking - - - Synopsis - - This chapter will cover some of the more frequently used network - services on Unix systems. We will cover how to define, setup, test and - maintain all of the network services that FreeBSD utilizes. In addition, - there have been example configuration files included throughout this - chapter for you to benefit from. - - After reading this chapter, you will know: - - - - The basics of gateways and routes. - - - - How to make FreeBSD act as a bridge. - - - - How to setup a network filesystem. - - - - How to setup network booting on a diskless machine. - - - - How to setup a network information server for sharing user - accounts. - - - - How to setup automatic network settings using DHCP. - - - - How to setup a domain name server. - - - - How to synchronize the time and date, and setup a - time server, with the NTP protocol. - - - - How to setup network address translation. - - - - How to manage the inetd daemon. - - - - How to connect two computers via PLIP. - - - - How to setup IPv6 on a FreeBSD machine. - - - - Before reading this chapter, you should: - - - - Understand the basics of the /etc/rc scripts. - - - - Be familiar with basic network terminology. - - - - - - - - - Coranth - Gryphon - Contributed by - - - - Gateways and Routes - - routing - gateway - subnet - For one machine to be able to find another over a network, - there must be a mechanism in place to describe how to get from - one to the other. This is called - routing. A route is a - defined pair of addresses: a destination and a - gateway. The pair indicates that if you are - trying to get to this destination, - communicate through this gateway. There - are three types of destinations: individual hosts, subnets, and - default. The default route is - used if none of the other routes apply. We will talk a little - bit more about default routes later on. There are also three - types of gateways: individual hosts, interfaces (also called - links), and Ethernet hardware addresses (MAC - addresses). - - - - An Example - - To illustrate different aspects of routing, we will use the - following example from netstat: - - &prompt.user; netstat -r -Routing tables - -Destination Gateway Flags Refs Use Netif Expire - -default outside-gw UGSc 37 418 ppp0 -localhost localhost UH 0 181 lo0 -test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 -10.20.30.255 link#1 UHLW 1 2421 -example.com link#1 UC 0 0 -host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 -host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => -host2.example.com link#1 UC 0 0 -224 link#1 UC 0 0 - - default route - The first two lines specify the default route (which we - will cover in the next - section) and the localhost route. - - loopback device - The interface (Netif column) that this - routing table specifies to use for - localhost is lo0, - also known as the loopback device. This says to keep all - traffic for this destination internal, rather than sending it - out over the LAN, since it will only end up back where it - started. - - - Ethernet - MAC address - - The next thing that stands out are the addresses beginning - with 0:e0:. These are Ethernet - hardware addresses, which are also known as MAC addresses. - FreeBSD will automatically identify any hosts - (test0 in the example) on the local Ethernet - and add a route for that host, directly to it over the - Ethernet interface, ed0. There is - also a timeout (Expire column) associated - with this type of route, which is used if we fail to hear from - the host in a specific amount of time. When this happens, the - route to this host will be automatically deleted. These hosts - are identified using a mechanism known as RIP (Routing - Information Protocol), which figures out routes to local hosts - based upon a shortest path determination. - - subnet - FreeBSD will also add subnet routes for the local subnet (10.20.30.255 is the broadcast address for the - subnet 10.20.30, and example.com is the domain name associated - with that subnet). The designation link#1 refers - to the first Ethernet card in the machine. You will notice no - additional interface is specified for those. - - Both of these groups (local network hosts and local subnets) have - their routes automatically configured by a daemon called - routed. If this is not run, then only - routes which are statically defined (i.e. entered explicitly) will - exist. - - The host1 line refers to our host, which it - knows by Ethernet address. Since we are the sending host, FreeBSD - knows to use the loopback interface (lo0) - rather than sending it out over the Ethernet interface. - - The two host2 lines are an example of - what happens when we use an &man.ifconfig.8; alias (see the - section on Ethernet for reasons why we would do this). The - => symbol after the - lo0 interface says that not only are - we using the loopback (since this address also refers to the - local host), but specifically it is an alias. Such routes - only show up on the host that supports the alias; all other - hosts on the local network will simply have a - link#1 line for such routes. - - The final line (destination subnet 224) deals - with multicasting, which will be covered in another section. - - Finally, various attributes of each route can be seen in - the Flags column. Below is a short table - of some of these flags and their meanings: - - - - - - U - Up: The route is active. - - - - H - Host: The route destination is a single host. - - - - G - Gateway: Send anything for this destination on to this - remote system, which will figure out from there where to send - it. - - - - S - Static: This route was configured manually, not - automatically generated by the system. - - - - C - Clone: Generates a new route based upon this route for - machines we connect to. This type of route is normally used - for local networks. - - - - W - WasCloned: Indicated a route that was auto-configured - based upon a local area network (Clone) route. - - - - L - Link: Route involves references to Ethernet - hardware. - - - - - - - - Default Routes - - default route - When the local system needs to make a connection to a remote host, - it checks the routing table to determine if a known path exists. If - the remote host falls into a subnet that we know how to reach (Cloned - routes), then the system checks to see if it can connect along that - interface. - - If all known paths fail, the system has one last option: the - default route. This route is a special type of gateway - route (usually the only one present in the system), and is always - marked with a c in the flags field. For hosts on a - local area network, this gateway is set to whatever machine has a - direct connection to the outside world (whether via PPP link, - DSL, cable modem, T1, or another network interface). - - If you are configuring the default route for a machine which - itself is functioning as the gateway to the outside world, then the - default route will be the gateway machine at your Internet Service - Provider's (ISP) site. - - Let us look at an example of default routes. This is a common - configuration: - - -[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] - - - The hosts Local1 and - Local2 are at your site. - Local1 is connected to an ISP via a dial up - PPP connection. This PPP server computer is connected through - a local area network to another gateway computer through an - external interface to the ISPs Internet feed. - - The default routes for each of your machines will be: - - - - - - Host - Default Gateway - Interface - - - - - - Local2 - Local1 - Ethernet - - - - Local1 - T1-GW - PPP - - - - - - A common question is Why (or how) would we set - the T1-GW to be the default gateway for - Local1, rather than the ISP server it is - connected to?. - - Remember, since the PPP interface is using an address on the ISP's - local network for your side of the connection, routes for any other - machines on the ISP's local network will be automatically generated. - Hence, you will already know how to reach the T1-GW - machine, so there is no need for the intermediate step - of sending traffic to the ISP server. - - As a final note, it is common to use the address X.X.X.1 as the gateway address for your local - network. So (using the same example), if your local class-C address - space was 10.20.30 and your ISP was - using 10.9.9 then the default routes - would be: - - - - - - Host - Default Route - - - - - Local2 (10.20.30.2) - Local1 (10.20.30.1) - - - Local1 (10.20.30.1, 10.9.9.30) - T1-GW (10.9.9.1) - - - - - - - - Dual Homed Hosts - dual homed hosts - There is one other type of configuration that we should cover, and - that is a host that sits on two different networks. Technically, any - machine functioning as a gateway (in the example above, using a PPP - connection) counts as a dual-homed host. But the term is really only - used to refer to a machine that sits on two local-area - networks. - - In one case, the machine has two Ethernet cards, each - having an address on the separate subnets. Alternately, the - machine may only have one Ethernet card, and be using - &man.ifconfig.8; aliasing. The former is used if two - physically separate Ethernet networks are in use, the latter - if there is one physical network segment, but two logically - separate subnets. - - Either way, routing tables are set up so that each subnet knows - that this machine is the defined gateway (inbound route) to the other - subnet. This configuration, with the machine acting as a router - between the two subnets, is often used when we need to implement - packet filtering or firewall security in either or both - directions. - - If you want this machine to actually forward packets - between the two interfaces, you need to tell FreeBSD to enable - this ability. - - - - Building a Router - - router - - A network router is simply a system that forwards packets - from one interface to another. Internet standards and good - engineering practice prevent the FreeBSD Project from enabling - this by default in FreeBSD. You can enable this feature by - changing the following variable to YES in - &man.rc.conf.5;: - - gateway_enable=YES # Set to YES if this host will be a gateway - - This option will set the &man.sysctl.8; variable - net.inet.ip.forwarding to - 1. If you should need to stop routing - temporarily, you can reset this to 0 temporarily. - - Your new router will need routes to know where to send the - traffic. If your network is simple enough you can use static - routes. FreeBSD also comes with the standard BSD routing - daemon &man.routed.8;, which speaks RIP (both version 1 and - version 2) and IRDP. Support for BGP v4, OSPF v2, and other - sophisticated routing protocols is available with the - net/zebra package. - Commercial products such as gated are also available for more - complex network routing solutions. - -BGP -RIP -OSPF - - Even when FreeBSD is configured in this way, it does not - completely comply with the Internet standard requirements for - routers. It comes close enough for ordinary use, - however. - - - - Routing Propagation - routing propagation - We have already talked about how we define our routes to the - outside world, but not about how the outside world finds us. - - We already know that routing tables can be set up so that all - traffic for a particular address space (in our examples, a class-C - subnet) can be sent to a particular host on that network, which will - forward the packets inbound. - - When you get an address space assigned to your site, your service - provider will set up their routing tables so that all traffic for your - subnet will be sent down your PPP link to your site. But how do sites - across the country know to send to your ISP? - - There is a system (much like the distributed DNS information) that - keeps track of all assigned address-spaces, and defines their point of - connection to the Internet Backbone. The Backbone are - the main trunk lines that carry Internet traffic across the country, - and around the world. Each backbone machine has a copy of a master - set of tables, which direct traffic for a particular network to a - specific backbone carrier, and from there down the chain of service - providers until it reaches your network. - - It is the task of your service provider to advertise to the - backbone sites that they are the point of connection (and thus the - path inward) for your site. This is known as route - propagation. - - - - Troubleshooting - - traceroute - - Sometimes, there is a problem with routing propagation, and some - sites are unable to connect to you. Perhaps the most useful command - for trying to figure out where routing is breaking down is the - &man.traceroute.8; command. It is equally useful if you cannot seem - to make a connection to a remote machine (i.e. &man.ping.8; - fails). - - The &man.traceroute.8; command is run with the name of the remote - host you are trying to connect to. It will show the gateway hosts - along the path of the attempt, eventually either reaching the target - host, or terminating because of a lack of connection. - - For more information, see the manual page for - &man.traceroute.8;. - - - - Multicast Routing - - multicast - options MROUTING - - FreeBSD supports both multicast applications and multicast - routing natively. Multicast applications do not require any - special configuration of FreeBSD; applications will generally - run out of the box. Multicast routing - requires that support be compiled into the kernel: - - options MROUTING - - In addition, the multicast routing daemon, &man.mrouted.8; - must be configured to set up tunnels and DVMRP via - /etc/mrouted.conf. More details on - multicast configuration may be found in the man pages for - mrouted. - - - - - - - - Eric - Anderson - Written by - - - - Wireless Networking - - wireless networking - - 802.11 - wireless networking - - - - Introduction - It can be very useful to be able to use a computer without the - annoyance of having a network cable attached at all times. FreeBSD can - be used as a wireless client, and even as a wireless access - point. - - - - Wireless Modes of Operation - There are two different ways to configure 802.11 wireless devices: - BSS and IBSS. - - - BSS Mode - BSS mode is the mode that typically is used. BSS mode is - also called infrastructure mode. In this mode, a number of - wireless access points are connected to a wired network. Each - wireless network has its own name. This name is called the - SSID of the network. - - Wireless clients connect to these wireless access - points. The IEEE 802.11 standard defines the protocol that - wireless networks use to connect. A wireless client can be - tied to a specific network, when a SSID is set. A wireless - client can also attach to any network by not explicitly - setting a SSID. - - - - IBSS Mode - IBSS mode, also called ad-hoc mode, is designed for point - to point connections. There are actually two types of ad-hoc - mode. One is IBSS mode, also called ad-hoc or IEEE ad-hoc - mode. This mode is defined by the IEEE 802.11 standards. - The second is called demo ad-hoc mode or Lucent ad-hoc mode - (and sometimes, confusingly, ad-hoc mode). This is the old, - pre-802.11 ad-hoc mode and should only be used for legacy - installations. We will not cover either of the ad-hoc modes - further. - - - - - Infrastructure Mode - - Access Points - - Access points are wireless networking devices that allow - one or more wireless clients to use the device as a central - hub. When using an access point, all clients communicate - through the access point. Multiple access points are often - used to cover a complete area such as a house, business, or - park with a wireless network. - - Access points typically have multiple network - connections: the wireless card, and one or more wired Ethernet - adapters for connection to the rest of the network. - - - Access points can either be purchased prebuilt, or you - can build your own with FreeBSD and a supported wireless card. - Several vendors make wireless access points and wireless cards - with various features. - - - - Building a FreeBSD Access Point - wireless networking - access point - - - Requirements - - In order to set up a wireless access point with - FreeBSD, you need to have a compatible wireless card. - Currently, only cards with the Prism chipset are - supported. You will also need a wired network card that is - supported by FreeBSD (this should not be difficult to find, - FreeBSD supports a lot of different devices). For this - guide, we will assume you want to &man.bridge.4; all traffic - between the wireless device and the network attached to the - wired network card. - - The hostap functionality that FreeBSD uses to implement - the access point works best with certain versions of - firmware. Prism 2 cards should use firmware version 1.3.4 - or newer. Prism 2.5 and Prism 3 cards should use firmware - 1.4.9. Older versions of the firmware way or may not - function correctly. At this time, the only way to update - cards is with windows firmware update utilities available - from your card's manufacturer. - - - - Setting It Up - First, make sure your system can see the wireless card: - &prompt.root; ifconfig -a -wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 - inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 - ether 00:09:2d:2d:c9:50 - media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) - status: no carrier - ssid "" - stationname "FreeBSD Wireless node" - channel 10 authmode OPEN powersavemode OFF powersavesleep 100 - wepmode OFF weptxkey 1 - - Do not worry about the details now, just make sure it shows you - something to indicate you have a wireless card installed. - If you have trouble seeing the wireless interface, and you - are using a PC Card, you may want to check out - &man.pccardc.8; and &man.pccardd.8; manual pages for more - information. - - Next, you will need to load a module in order to get - the bridging part of FreeBSD ready for the access point. In - order to load the &man.bridge.4; module, simply run the - following command: - - &prompt.root; kldload bridge - - It should not have produced any errors when loading the - module. If it did, you may need to compile the - &man.bridge.4; code into your kernel. The Bridging section of the handbook - should be able to help you accomplish that task. - - Now that you have the bridging stuff done, we need to - tell the FreeBSD kernel which interfaces to bridge together. - We do that by using &man.sysctl.8;: - - &prompt.root; sysctl net.link.ether.bridge=1 -&prompt.root; sysctl net.link.ether.bridge_cfg="wi0 xl0" -&prompt.root; sysctl net.inet.ip.forwarding=1 - - Now it is time for the wireless card setup. - The following command will set the card into an access point: - - -&prompt.root; ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP" - - - The &man.ifconfig.8; line brings the - wi0 interface up, sets its SSID to - my_net, and sets the station name to - FreeBSD AP. The sets the card into 11Mbps mode and is - needed for any to take effect. - The option places the - interface into access point mode. The option sets the 802.11b channel to use. The - &man.wicontrol.8; man page has valid channel options for - your regulatory domain. - - - Now you should have a complete functioning access point - up and running. You are encouraged to read - &man.wicontrol.8;, &man.ifconfig.8;, and &man.wi.4; for - further information. - - - It is also suggested that you read the section on encryption that follows. - - - - Status Information - Once the access point is configured and operational, - operators will want to see the clients that are associated - with the access point. At any time, the operator may type: - - &prompt.root; wicontrol -l -1 station: -00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15 - - - This shows that there's one station associated, along - with its parameters. The signal indicated should be used - as a relative indication of strength only. Its - translation to dBm or other units varies between different - firmware revisions. - - - - - Clients - - A wireless client is a system that accesses an access - point or another client directly. - - Typically, wireless clients only have one network device, - the wireless networking card. - - There are a few different ways to configure a wireless - client. These are based on the different wireless modes, - generally BSS (infrastructure mode, which requires an access - point), and IBSS (ad-hoc, or peer-to-peer mode). In our - example, we will use the most popular of the two, BSS mode, to - talk to an access point. - - - Requirements - There is only one real requirement for setting up FreeBSD as a wireless client. - You will need a wireless card that is supported by FreeBSD. - - - - Setting Up a Wireless FreeBSD Client - - You will need to know a few things about the wireless - network you are joining before you start. In this example, we - are joining a network that has a name of - my_net, and encryption turned off. - - Note: In this example, we are not using encryption, which - is a dangerous situation. In the next section, you will learn - how to turn on encryption, and why it is important to do so, - and why some encryption technologies still do not completely - protect you. - - Make sure your card is recognized by FreeBSD: - - &prompt.root; ifconfig -a -wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 - inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 - ether 00:09:2d:2d:c9:50 - media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) - status: no carrier - ssid "" - stationname "FreeBSD Wireless node" - channel 10 authmode OPEN powersavemode OFF powersavesleep 100 - wepmode OFF weptxkey 1 - - Now, we will set the card to the correct settings for our - network: - - &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net - - Replace 192.168.0.20 and - 255.255.255.0 with a valid IP - address and netmask on your wired network. Remember, our - access point is bridging the data between the wireless - network, and the wired network, so it will appear to the other - devices on your network that you are on the wired network just - as they are. - - Once you have done that, you should be able to ping hosts - on the wired network just as if you were connected using a - standard wired connection. - - If you are experiencing problems with your wireless - connection, check to make sure that your are associated - (connected) to the access point: - - &prompt.root; ifconfig wi0 - - should return some information, and you should see: - status: associated - - If it does not show associated, then you may be out of - range of the access point, do not have encryption on, or - possibly have a configuration problem. - - - - - - Encryption - - wireless networking - encryption - - - Encryption on a wireless network is important because you - no longer have the ability to keep the network contained in a - well protected area. Your wireless data will be broadcast - across your entire neighborhood, so anyone who cares to read it - can. This is where encryption comes in. By encrypting the - data that is sent over the airwaves, you make it much more - difficult for any interested party to grab your data right out - of the air. - - The two most common ways to encrypt the data between your - client and the access point, are WEP, and &man.ipsec.4;. - - - WEP - WEP - - WEP is an abbreviation for Wired Equivalency Protocol. - WEP is an attempt to make wireless networks as safe and secure - as a wired network. Unfortunately, it has been cracked, and is - fairly trivial to break. This also means it is not something - to rely on when it comes to encrypting sensitive data. - - It is better than nothing, so use the following to turn on - WEP on your new FreeBSD access point: - - &prompt.root; ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap - - And you can turn on WEP on a client with this command: - - &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890 - - Note that you should replace the 0x1234567890 with a more unique key. - - - - - IPsec - - &man.ipsec.4; is a much more robust and powerful tool for - encrypting data across a network. This is definitely the - preferred way to encrypt wireless data over a network. You can - read more about &man.ipsec.4; security and how to implement it - in the IPsec section of the - handbook. - - - - - Tools - - There are a small number of tools available for use in - debugging and setting up your wireless network, and here we will - attempt to describe some of them and what they do. - - - The <application>bsd-airtools</application> Package - - The bsd-airtools package is a - complete toolset that includes wireless auditing tools for WEP - key cracking, access point detection, etc. - - The bsd-airtools utilities can be - installed from the net/bsd-airtools port. Information on - installing ports can be found in of the - handbook. - - The program dstumbler is the packaged - tool that allows for access point discovery and signal to noise - ratio graphing. If you are having a hard time getting your - access point up and running, dstumbler may - help you get started. - - To test your wireless network security, you may choose to - use dweputils (dwepcrack, - dwepdump and dwepkeygen) - to help you determine if WEP is the right solution to your - wireless security needs. - - - - - The <application>wicontrol</application>, <application>ancontrol</application> and <application>raycontrol</application> Utilities - - These are the tools you use to control how your wireless - card behaves on the wireless network. In the examples above, we - have chosen to use &man.wicontrol.8;, since our wireless card is - a wi0 interface. If you had a Cisco - wireless device, it would come up as - an0, and therefore you would use - &man.ancontrol.8;. - - - - - The <application>ifconfig</application> Command - ifconfig - - &man.ifconfig.8; can be used to do many of the same options - as &man.wicontrol.8;, however it does lack a few options. Check - &man.ifconfig.8; for command line parameters and options. - - - - - - - Supported Cards - - Access Points - - The only cards that are currently supported for BSS (as an - access point) mode are devices based on the Prism 2, 2.5, or 3 - chipsets. For a complete list, look at &man.wi.4;. - - - - - Clients - - Almost all 802.11b wireless cards are currently supported - under FreeBSD. Most cards based on Prism, Spectrum24, Hermes, - Aironet, and Raylink will work as a wireless network card in - IBSS (ad-hoc, peer-to-peer, and BSS) mode. - - - - - - - - - - - - - Steve - Peterson - Written by - - - - Bridging - - - Introduction - IP subnet - bridge - It is sometimes useful to divide one physical network - (such as an Ethernet segment) into two separate network - segments without having to create IP subnets and use a router - to connect the segments together. A device that connects two - networks together in this fashion is called a - bridge. A FreeBSD system with two network - interface cards can act as a bridge. - - The bridge works by learning the MAC layer addresses - (Ethernet addresses) of the devices on each of its network interfaces. - It forwards traffic between two networks only when its source and - destination are on different networks. - - In many respects, a bridge is like an Ethernet switch with very - few ports. - - - - Situations Where Bridging Is Appropriate - - There are two common situations in which a bridge is used - today. - - - High Traffic on a Segment - - Situation one is where your physical network segment is - overloaded with traffic, but you do not want for whatever reason to - subnet the network and interconnect the subnets with a - router. - - Let us consider an example of a newspaper where the Editorial and - Production departments are on the same subnetwork. The Editorial - users all use server A for file service, and the Production users - are on server B. An Ethernet is used to connect all users together, - and high loads on the network are slowing things down. - - If the Editorial users could be segregated on one - network segment and the Production users on another, the two - network segments could be connected with a bridge. Only the - network traffic destined for interfaces on the - other side of the bridge would be sent to the - other network, reducing congestion on each network - segment. - - - - Filtering/Traffic Shaping Firewall - firewall - IP Masquerading - - The second common situation is where firewall functionality is - needed without IP Masquerading (NAT). - - An example is a small company that is connected via DSL - or ISDN to their ISP. They have a 13 globally-accessible IP - addresses from their ISP and have 10 PCs on their network. - In this situation, using a router-based firewall is - difficult because of subnetting issues. - - router - DSL - ISDN - A bridge-based firewall can be configured and dropped into the - path just downstream of their DSL/ISDN router without any IP - numbering issues. - - - - - Configuring a Bridge - - - Network Interface Card Selection - - A bridge requires at least two network cards to function. - Unfortunately, not all network interface cards as of FreeBSD 4.0 - support bridging. Read &man.bridge.4; for details on the cards that - are supported. - - Install and test the two network cards before continuing. - - - - Kernel Configuration Changes - - kernel options - options BRIDGE - - - To enable kernel support for bridging, add the: - - options BRIDGE - - statement to your kernel configuration file, and rebuild your - kernel. - - - - Firewall Support - firewall - If you are planning to use the bridge as a firewall, you - will need to add the IPFIREWALL option as - well. Read for general - information on configuring the bridge as a firewall. - - If you need to allow non-IP packets (such as ARP) to flow - through the bridge, there is an undocumented firewall option that - must be set. This option is - IPFIREWALL_DEFAULT_TO_ACCEPT. Note that this - changes the default rule for the firewall to accept any packet. - Make sure you know how this changes the meaning of your ruleset - before you set it. - - - - Traffic Shaping Support - - If you want to use the bridge as a traffic shaper, you will need - to add the DUMMYNET option to your kernel - configuration. Read &man.dummynet.4; for further - information. - - - - - Enabling the Bridge - - Add the line: - - net.link.ether.bridge=1 - - to /etc/sysctl.conf to enable the bridge at - runtime, and the line: - - net.link.ether.bridge_cfg=if1,if2 - - to enable bridging on the specified interfaces (replace - if1 and - if2 with the names of your two - network interfaces). If you want the bridged packets to be - filtered by &man.ipfw.8;, you should add: - - net.link.ether.bridge_ipfw=1 - - as well. - - - - Other Information - - If you want to be able to telnet into the bridge from the network, - it is OK to assign one of the network cards an IP address. The - consensus is that assigning both cards an address is a bad - idea. - - If you have multiple bridges on your network, there cannot be more - than one path between any two workstations. Technically, this means - that there is no support for spanning tree link management. - - A bridge can add latency to your ping times, especially for - traffic from one segment to another. - - - - - - - - - Tom - Rhodes - Reorganized and enhanced by - - - - - Bill - Swingle - Written by - - - - NFS - - NFS - Among the many different filesystems that FreeBSD supports is - the Network File System, also known as NFS. - NFS allows a system to share directories and files - with others over a network. By using NFS, users and - programs can access files on remote systems almost as if they were local - files. - - Some of the most notable benefits that - NFS can provide are: - - - - Local workstations use less disk space because - commonly used data can be stored on a single machine and still - remain accessible to others over the network. - - - - There is no need for users to have separate home directories - on every network machine. Home directories could be setup on the - NFS server and made available throughout - the network. - - - - Storage devices such as floppy disks, CDROM drives, and - ZIP drives can be used by other machines on the network. - This may reduce the number of removable media drives - throughout the network. - - - - - How <acronym>NFS</acronym> Works - - NFS consists of at least two main parts: - a server and one or more clients. The client remotely accesses - the data that is stored - on the server machine. In order for this to function properly a few - processes have to be configured and running: - - In &os; 5.X, the portmap utility - has been replaced with the rpcbind utility. Thus, - in &os; 5.X the user is required to replace every instance of - portmap with rpcbind - in the forthcoming examples. - - The server has to be running the following daemons: - - NFS - server - - - portmap - - - mountd - - - nfsd - - - - - - - Daemon - Description - - - - - nfsd - The NFS daemon which services requests from - the NFS clients. - - - mountd - The NFS mount daemon which carries out - the requests that &man.nfsd.8; passes on to it. - - - portmap - The portmapper daemon - allows NFS clients to discover which port the NFS server - is using. - - - - - - The client can also run a daemon, known as - nfsiod. The - nfsiod daemon services the requests - from the NFS server. This is optional, and - improves performance, but is not required for normal and - correct operation. See the &man.nfsiod.8; manual page for - more information. - - - - - Configuring <acronym>NFS</acronym> - - NFS - configuration - - - NFS configuration is a relatively - straightforward process. The processes that need to be - running can all start at boot time with a few modifications to - your /etc/rc.conf file. - - On the NFS server, make sure that the - following options are configured in the - /etc/rc.conf file: - - portmap_enable="YES" -nfs_server_enable="YES" -mountd_flags="-r" - - mountd runs automatically whenever the - NFS server is enabled. - - On the client, make sure this option is present in - /etc/rc.conf: - - nfs_client_enable="YES" - - The /etc/exports file specifies which - filesystems NFS should export (sometimes - referred to as share). Each line in - /etc/exports specifies a filesystem to be - exported and which machines have access to that filesystem. - Along with what machines have access to that filesystem, - access options may also be specified. There are many such - options that can be used in this file but only a few will be - mentioned here. You can easily discover other options by - reading over the &man.exports.5; manual page. - - Here are a few example /etc/exports - entries: - - - NFS - export examples - - - The following examples give an idea of how to export filesystems, - although the settings may be different depending on - your environment and network configuration. - For instance, to export the /cdrom directory to - three example machines that have the same domain name as the server - (hence the lack of a domain name for each) or have entries in your - /etc/hosts file. The - flag makes the exported filesystem read-only. With this flag, the - remote system will not be able to write any changes to the - exported filesystem. - - /cdrom -ro host1 host2 host3 - - The following line exports /home to - three hosts by IP address. This is a useful setup if you have - a private network without a DNS server - configured. Optionally the /etc/hosts - file could be configured for internal hostnames; please review - &man.hosts.5; for more information. The - flag allows the subdirectories to be - mount points. In other words, it will not mount the - subdirectories but permit the client to mount only the - directories that are required or needed. - - /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 - - The following line exports /a so that - two clients from different domains may access the filesystem. - The flag allows the - root user on the remote system to write - data on the exported filesystem as root. - If the -maproot=root flag is not specified, - then even if a user has root access on - the remote system, they will not be able to modify files on - the exported filesystem. - - /a -maproot=root host.example.com box.example.org - - In order for a client to access an exported filesystem, - the client must have permission to do so. Make sure the - client is listed in your /etc/exports - file. - - In /etc/exports, each line represents - the export information for one filesystem to one host. A - remote host can only be specified once per filesystem, and may - only have one default entry. For example, assume that - /usr is a single filesystem. The - following /etc/exports would be - invalid: - - /usr/src client -/usr/ports client - - One filesystem, /usr, has two lines - specifying exports to the same host, client. - The correct format for this situation is: - - /usr/src /usr/ports client - - The properties of one filesystem exported to a given host - must all occur on one line. Lines without a client specified - are treated as a single host. This limits how you can export - filesystems, but for most people this is not an issue. - - The following is an example of a valid export list, where - /usr and /exports - are local filesystems: - - # Export src and ports to client01 and client02, but only -# client01 has root privileges on it -/usr/src /usr/ports -maproot=root client01 -/usr/src /usr/ports client02 -# The client machines have root and can mount anywhere -# on /exports. Anyone in the world can mount /exports/obj read-only -/exports -alldirs -maproot=root client01 client02 -/exports/obj -ro - - You must restart - mountd whenever you modify - /etc/exports so the changes can take effect. - This can be accomplished by sending the HUP signal - to the mountd process: - - &prompt.root; kill -HUP `cat /var/run/mountd.pid` - - Alternatively, a reboot will make FreeBSD set everything - up properly. A reboot is not necessary though. - Executing the following commands as root - should start everything up. - - On the NFS server: - - &prompt.root; portmap -&prompt.root; nfsd -u -t -n 4 -&prompt.root; mountd -r - - On the NFS client: - - &prompt.root; nfsiod -n 4 - - Now everything should be ready to actually mount a remote file - system. In these examples the - server's name will be server and the client's - name will be client. If you only want to - temporarily mount a remote filesystem or would rather test the - configuration, just execute a command like this as root on the - client: - - NFS - mounting - - &prompt.root; mount server:/home /mnt - - This will mount the /home directory - on the server at /mnt on the client. If - everything is set up correctly you should be able to enter - /mnt on the client and see all the files - that are on the server. - - If you want to automatically mount a remote filesystem - each time the computer boots, add the filesystem to the - /etc/fstab file. Here is an example: - - server:/home /mnt nfs rw 0 0 - - The &man.fstab.5; manual page lists all the available options. - - - - Practical Uses - - NFS has many practical uses. Some of the more common - ones are listed below: - - - NFS - uses - - - - Set several machines to share a CDROM or other media - among them. This is cheaper and often a more convenient - method to install software on multiple machines. - - - - On large networks, it might be more convenient to - configure a central NFS server in which - to store all the user home directories. These home - directories can then be exported to the network so that - users would always have the same home directory, - regardless of which workstation they log in to. - - - - Several machines could have a common - /usr/ports/distfiles directory. That - way, when you need to install a port on several machines, - you can quickly access the source without downloading it - on each machine. - - - - - - - - - Wylie - Stilwell - Contributed by - - - - - Chern - Lee - Rewritten by - - - - Automatic Mounts with <application>amd</application> - - amd - automatic mounter daemon - - &man.amd.8; (the automatic mounter daemon) - automatically mounts a - remote filesystem whenever a file or directory within that - filesystem is accessed. Filesystems that are inactive for a - period of time will also be automatically unmounted by - amd. Using - amd provides a simple alternative - to permanent mounts, as permanent mounts are usually listed in - /etc/fstab. - - amd operates by attaching - itself as an NFS server to the /host and - /net directories. When a file is accessed - within one of these directories, amd - looks up the corresponding remote mount and automatically mounts - it. /net is used to mount an exported - filesystem from an IP address, while /host - is used to mount an export from a remote hostname. - - An access to a file within - /host/foobar/usr would tell - amd to attempt to mount the - /usr export on the host - foobar. - - - Mounting an Export with <application>amd</application> - - You can view the available mounts of a remote host with - the showmount command. For example, to - view the mounts of a host named foobar, you - can use: - - &prompt.user; showmount -e foobar -Exports list on foobar: -/usr 10.10.10.0 -/a 10.10.10.0 -&prompt.user; cd /host/foobar/usr - - - As seen in the example, the showmount shows - /usr as an export. When changing directories to - /host/foobar/usr, amd - attempts to resolve the hostname foobar and - automatically mount the desired export. - - amd can be started by the - startup scripts by placing the following lines in - /etc/rc.conf: - - amd_enable="YES" - - Additionally, custom flags can be passed to - amd from the - amd_flags option. By default, - amd_flags is set to: - - amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" - - The /etc/amd.map file defines the - default options that exports are mounted with. The - /etc/amd.conf file defines some of the more - advanced features of amd. - - Consult the &man.amd.8; and &man.amd.conf.5; manual pages for more - information. - - - - - - - John - Lind - Contributed by - - - - Problems Integrating with Other Systems - - Certain Ethernet adapters for ISA PC systems have limitations - which can lead to serious network problems, particularly with NFS. - This difficulty is not specific to FreeBSD, but FreeBSD systems - are affected by it. - - The problem nearly always occurs when (FreeBSD) PC systems are - networked with high-performance workstations, such as those made - by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS - mount will work fine, and some operations may succeed, but - suddenly the server will seem to become unresponsive to the - client, even though requests to and from other systems continue to - be processed. This happens to the client system, whether the - client is the FreeBSD system or the workstation. On many systems, - there is no way to shut down the client gracefully once this - problem has manifested itself. The only solution is often to - reset the client, because the NFS situation cannot be - resolved. - - Though the correct solution is to get a higher - performance and capacity Ethernet adapter for the FreeBSD system, - there is a simple workaround that will allow satisfactory - operation. If the FreeBSD system is the - server, include the option - on the mount from the client. If the - FreeBSD system is the client, then mount the - NFS filesystem with the option . These - options may be specified using the fourth field of the - fstab entry on the client for automatic - mounts, or by using the parameter of the mount - command for manual mounts. - - It should be noted that there is a different problem, - sometimes mistaken for this one, when the NFS servers and clients - are on different networks. If that is the case, make - certain that your routers are routing the - necessary UDP information, or you will not get anywhere, no matter - what else you are doing. - - In the following examples, fastws is the host - (interface) name of a high-performance workstation, and - freebox is the host (interface) name of a FreeBSD - system with a lower-performance Ethernet adapter. Also, - /sharedfs will be the exported NFS - filesystem (see &man.exports.5;), and - /project will be the mount point on the - client for the exported filesystem. In all cases, note that - additional options, such as or - and may be desirable in - your application. - - Examples for the FreeBSD system (freebox) as - the client in /etc/fstab on freebox: - - fastws:/sharedfs /project nfs rw,-r=1024 0 0 - - As a manual mount command on freebox: - - &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project - - Examples for the FreeBSD system as the server in - /etc/fstab on fastws: - - freebox:/sharedfs /project nfs rw,-w=1024 0 0 - - As a manual mount command on fastws: - - &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project - - Nearly any 16-bit Ethernet adapter will allow operation - without the above restrictions on the read or write size. - - For anyone who cares, here is what happens when the failure - occurs, which also explains why it is unrecoverable. NFS - typically works with a block size of 8 k (though it - may do fragments of smaller sizes). Since the maximum Ethernet - packet is around 1500 bytes, the NFS block gets - split into multiple Ethernet packets, even though it is still a - single unit to the upper-level code, and must be received, - assembled, and acknowledged as a unit. The - high-performance workstations can pump out the packets which - comprise the NFS unit one right after the other, just as close - together as the standard allows. On the smaller, lower capacity - cards, the later packets overrun the earlier packets of the same - unit before they can be transferred to the host and the unit as a - whole cannot be reconstructed or acknowledged. As a result, the - workstation will time out and try again, but it will try again - with the entire 8 K unit, and the process will be repeated, ad - infinitum. - - By keeping the unit size below the Ethernet packet size - limitation, we ensure that any complete Ethernet packet received - can be acknowledged individually, avoiding the deadlock - situation. - - Overruns may still occur when a high-performance workstations - is slamming data out to a PC system, but with the better cards, - such overruns are not guaranteed on NFS units. When - an overrun occurs, the units affected will be retransmitted, and - there will be a fair chance that they will be received, assembled, - and acknowledged. - - - - - - - - Jean-François - Dockès - Updated by - - - - Diskless Operation - - diskless workstation - diskless operation - - A FreeBSD machine can boot over the network and operate without a - local disk, using filesystems mounted from an NFS server. No system - modification is necessary, beyond standard configuration files. - Such a system is easy to set up because all the necessary elements - are readily available: - - - There are at least two possible methods to load the kernel over - the network: - - - PXE: Intel's Preboot Execution - Environment system is a form of smart boot ROM built into some - networking cards or motherboards. See &man.pxeboot.8; for more - details. - - - The etherboot - port (net/etherboot) produces - ROM-able code to boot kernels over the network. The - code can be either burnt into a boot PROM on a network - card, or loaded from a local floppy (or hard) disk - drive, or from a running MS-DOS system. Many network - cards are supported. - - - - - - A sample script - (/usr/share/examples/diskless/clone_root) eases - the creation and maintenance of the workstation's root filesystem - on the server. The script will probably require a little - customization but it will get you started very quickly. - - - - Standard system startup files exist in /etc - to detect and support a diskless system startup. - - - - Swapping, if needed, can be done either to an NFS file or to - a local disk. - - - - There are many ways to set up diskless workstations. Many - elements are involved, and most can be customized to suit local - taste. The following will describe the setup of a complete system, - emphasizing simplicity and compatibility with the - standard FreeBSD startup scripts. The system described has the - following characteristics: - - - - The diskless workstations use a shared - read-only root filesystem, and a shared - read-only /usr. - The root filesystem is a copy of a - standard FreeBSD root (typically the server's), with some - configuration files overridden by ones specific to diskless - operation or, possibly, to the workstation they belong to. - The parts of the root which have to be - writable are overlaid with &man.mfs.8; filesystems. Any changes - will be lost when the system reboots. - - - The kernel is loaded by etherboot - , using DHCP (or BOOTP) and TFTP. - - - - As described, this system is insecure. It should - live in a protected area of a network, and be untrusted by - other hosts. - - - - - Setup Instructions - - - Configuring DHCP/BOOTP - - diskless operation - booting - - - There are two protocols that are commonly used to boot a - workstation that retrieves its configuration over the network: BOOTP - and DHCP. They are used at several points in the workstation - bootstrap: - - etherboot uses - DHCP (by default) or BOOTP (needs a configuration option) to - find the kernel. (PXE uses DHCP). - - The kernel uses BOOTP to locate the NFS - root. - - - - It is possible to configure a system to use only BOOTP. - The &man.bootpd.8; server program is included in the - base FreeBSD system. - - However, DHCP has a number of advantages over BOOTP (nicer - configuration files, possibility of using PXE, plus many others - not directly related to diskless operation), and we shall describe - both a pure BOOTP, and a BOOTP+DHCP configuration, with an - emphasis on the latter, which will use the ISC DHCP software - package. - - - Configuration Using ISC DHCP - - DHCP - diskless operation - - - The isc-dhcp server can answer - both BOOTP and DHCP requests. - - As of release 4.4, isc-dhcp - 3.0 is not part of the base - system. You will first need to install the - net/isc-dhcp3 port or the - corresponding package. Please refer to - for general information about ports and packages. - - Once isc-dhcp is installed, it - needs a configuration file to run, (normally named - /usr/local/etc/dhcpd.conf). Here follows - a commented example: - - - default-lease-time 600; - max-lease-time 7200; - authoritative; - - option domain-name "example.com"; - option domain-name-servers 192.168.4.1; - option routers 192.168.4.1; - - subnet 192.168.4.0 netmask 255.255.255.0 { - use-host-decl-names on; - option subnet-mask 255.255.255.0; - option broadcast-address 192.168.4.255; - - host margaux { - hardware ethernet 01:23:45:67:89:ab; - fixed-address margaux.example.com; - next-server 192.168.4.4; - filename "/tftpboot/kernel.diskless"; - option root-path "192.168.4.4:/data/misc/diskless"; - } - } - - - - This option tells - dhcpd to send the value in the - host declarations as the hostname for the - diskless host. An alternate way would be to add an - option host-name - margaux inside the - host declarations. - - - The - next-server directive designates - the TFTP server (the default is to use the same host as the - DHCP server). - - - The - filename directive defines the file that - etherboot will load as a - kernel. - PXE appears to prefer a relative file - name, and it loads pxeboot, not the - kernel (option filename - "pxeboot"). - - - - - The - root-path option defines the path to - the root filesystem, in usual NFS notation. - - - - - - Configuration Using BOOTP - - BOOTP - diskless operation - - - Here follows an equivalent bootpd - configuration. This would be found in - /etc/bootptab. - - Please note that etherboot - must be compiled with the non-default option - NO_DHCP_SUPPORT in order to use BOOTP, - and that PXE needs DHCP. The only - obvious advantage of bootpd is - that it exists in the base system. - - - .def100:\ - :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ - :sm=255.255.255.0:\ - :ds=192.168.4.1:\ - :gw=192.168.4.1:\ - :hd="/tftpboot":\ - :bf="/kernel.diskless":\ - :rp="192.168.4.4:/data/misc/diskless": - - margaux:ha=0123456789ab:tc=.def100 - - - - - - Preparing a Boot Program with - <application>Etherboot</application> - - - Etherboot - - - Etherboot's Web - site contains - - extensive documentation mainly intended for Linux - systems, but nonetheless containing useful information. The - following will just outline how you would use - etherboot on a FreeBSD - system. - - You must first install the net/etherboot package or port. - The etherboot port can normally - be found in /usr/ports/net/etherboot. - If the ports tree is installed on your system, just typing - make in this directory should take care - of everything. Else refer to for - information about ports and packages. - - For our setup, we shall use a boot floppy. For other methods - (PROM, or dos program), please refer to the - etherboot documentation. - - To make a boot floppy, insert a floppy in the drive on the - machine where you installed etherboot, - then change your current directory to the src - directory in the etherboot tree and - type: - - - &prompt.root; gmake bin32/devicetype.fd0 - - - devicetype depends on the type of - the Ethernet card in the diskless workstation. Refer to the - NIC file in the same directory to determine the - right devicetype. - - - - - - Configuring the TFTP and NFS Servers - - - TFTP - diskless operation - - - NFS - diskless operation - - - You need to enable tftpd on the TFTP - server: - - - Create a directory from which tftpd - will serve the files, i.e.: /tftpboot - - - - Add this line to your - /etc/inetd.conf: - - tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot - - It appears that at least some PXE versions want - the TCP version of TFTP. In this case, add a second line, - replacing dgram udp with stream - tcp. - - - - Tell inetd to reread its configuration - file: - &prompt.root; kill -HUP `cat /var/run/inetd.pid` - - - - You can place the tftpboot - directory anywhere on the server. Make sure that the - location is set in both inetd.conf and - dhcpd.conf. - - You also need to enable NFS and export the - appropriate filesystem on the NFS server. - - - - Add this to /etc/rc.conf: - nfs_server_enable="YES" - - - - Export the filesystem where the diskless root directory - is located by adding the following to - /etc/exports (adjust the volume mount - point and replace margaux - with the name of the diskless workstation): - - /data/misc -alldirs -ro margaux - - - Tell mountd to reread its configuration - file. If you actually needed to enable NFS in - /etc/rc.conf - at the first step, you probably want to reboot instead. - &prompt.root; kill -HUP `cat /var/run/mountd.pid` - - - - - - - Building a Diskless Kernel - - - diskless operation - kernel configuration - - - Create a kernel configuration file for the diskless client - with the following options (in addition to the usual - ones): - - - options BOOTP # Use BOOTP to obtain IP address/hostname - options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info - options BOOTP_COMPAT # Workaround for broken bootp daemons. - - - You may also want to use BOOTP_NFSV3 and - BOOTP_WIRED_TO (refer to LINT). - - Build the kernel (See ), - and copy it to the tftp directory, under the name listed - in dhcpd.conf. - - - - - - Preparing the Root Filesystem - - - root file system - diskless operation - - - You need to create a root filesystem for the diskless - workstations, in the location listed as - root-path in - dhcpd.conf. - - The easiest way to do this is to use the - /usr/share/examples/diskless/clone_root - shell script. This script needs customization, at least to adjust - the place where the filesystem will be created (the - DEST variable). - - Refer to the comments at the top of the script for - instructions. They explain how the base filesystem is built, - and how files may be selectively overridden by versions specific - to diskless operation, to a subnetwork, or to an individual - workstation. They also give examples for the diskless - /etc/fstab and - /etc/rc.conf files. - - The README files in - /usr/share/examples/diskless contain a lot - of interesting background information, but, together with the - other examples in the diskless directory, - they actually document a configuration method which is distinct - from the one used by clone_root and - /etc/rc.diskless[12], which is a little - confusing. Use them for reference only, except if you prefer - the method that they describe, in which case you will need - customized rc scripts. - - - - Configuring Swap - - If needed, a swap file located on the server can be - accessed via NFS. The exact bootptab - or dhcpd.conf options are not clearly - documented at this time. The following configuration - suggestions have been reported to work in some installations - using isc-dhcp 3.0rc11. - - Add the following lines to - dhcpd.conf: - - # Global section - option swap-path code 128 = string; - option swap-size code 129 = integer 32; - - host margaux { - ... # Standard lines, see above - option swap-path "192.168.4.4:/netswapvolume/netswap"; - option swap-size 64000; - } - - The idea is that, at least for a FreeBSD client, - DHCP/BOOTP option code 128 is the path to the NFS swap file, - and option code 129 is the swap size in kilobytes. Older - versions of dhcpd allowed a syntax of - option option-128 "..., which does not - seem to work any more. - /etc/bootptab would use the - following syntax instead: - - T128="192.168.4.4:/netswapvolume/netswap":T129=64000 - - - - - On the NFS swap file server, create the swap - file(s) - - &prompt.root; mkdir /netswapvolume/netswap - &prompt.root; cd /netswapvolume/netswap - &prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 - &prompt.root; chmod 0600 swap.192.168.4.6 - - 192.168.4.6 is the IP address - for the diskless client. - - - - On the NFS swap file server, add the following line to - /etc/exports: - - /netswapvolume -maproot=0:10 -alldirs margaux - - Then tell mountd to reread the - exports file, as above. - - - - - - - Miscellaneous Issues - - - - Running with a Read-only <filename>/usr</filename> - - - diskless operation - /usr read-only - - - If the diskless workstation is configured to run X, you - will have to adjust the xdm configuration file, which puts - the error log on /usr by default. - - - Using a Non-FreeBSD Server - - When the server for the root filesystem is not running FreeBSD, - you will have to create the root filesystem on a - FreeBSD machine, then copy it to its destination, using - tar or cpio. - In this situation, there are sometimes - problems with the special files in /dev, - due to differing major/minor integer sizes. A solution to this - problem is to export a directory from the non-FreeBSD server, - mount this directory onto a FreeBSD machine, and run - MAKEDEV on the FreeBSD machine - to create the correct device entries (FreeBSD 5.0 and later - use &man.devfs.5; to allocate device nodes transparently for - the user, running MAKEDEV on these - versions is useless). - - - - - - - - - - ISDN - - - ISDN - - - A good resource for information on ISDN technology and hardware is - Dan Kegel's ISDN - Page. - - A quick simple road map to ISDN follows: - - - - If you live in Europe you might want to investigate the ISDN card - section. - - - - If you are planning to use ISDN primarily to connect to the - Internet with an Internet Provider on a dial-up non-dedicated basis, - you might look into Terminal Adapters. This will give you the - most flexibility, with the fewest problems, if you change - providers. - - - - If you are connecting two LANs together, or connecting to the - Internet with a dedicated ISDN connection, you might consider - the stand alone router/bridge option. - - - - Cost is a significant factor in determining what solution you will - choose. The following options are listed from least expensive to most - expensive. - - - - - - Hellmuth - Michaelis - Contributed by - - - - ISDN Cards - - - ISDN - cards - - - FreeBSD's ISDN implementation supports only the DSS1/Q.931 - (or Euro-ISDN) standard using passive cards. Starting with - FreeBSD 4.4, some active cards are supported where the firmware - also supports other signaling protocols; this also includes the - first supported Primary Rate (PRI) ISDN card. - - Isdn4bsd allows you to connect - to other ISDN routers using either IP over raw HDLC or by using - synchronous PPP: either by using kernel PPP with isppp, a - modified sppp driver, or by using userland &man.ppp.8;. By using - userland &man.ppp.8;, channel bonding of two or more ISDN - B-channels is possible. A telephone answering machine - application is also available as well as many utilities such as - a software 300 Baud modem. - - Some growing number of PC ISDN cards are supported under - FreeBSD and the reports show that it is successfully used all - over Europe and in many other parts of the world. - - The passive ISDN cards supported are mostly the ones with - the Infineon (formerly Siemens) ISAC/HSCX/IPAC ISDN chipsets, - but also ISDN cards with chips from Cologne Chip (ISA bus only), - PCI cards with Winbond W6692 chips, some cards with the - Tiger300/320/ISAC chipset combinations and some vendor specific - chipset based cards such as the AVM Fritz!Card PCI V.1.0 and the - AVM Fritz!Card PnP. - - Currently the active supported ISDN cards are the AVM B1 - (ISA and PCI) BRI cards and the AVM T1 PCI PRI cards. - - For documentation on isdn4bsd, - have a look at /usr/share/examples/isdn/ - directory on your FreeBSD system or at the homepage of - isdn4bsd which also has pointers to hints, erratas and - much more documentation such as the isdn4bsd - handbook. - - In case you are interested in adding support for a - different ISDN protocol, a currently unsupported ISDN PC card or - otherwise enhancing isdn4bsd, please - get in touch with &a.hm;. - - For questions regarding the installation, configuration - and troubleshooting isdn4bsd, a - &a.isdn.name; mailing list is available. - - - - ISDN Terminal Adapters - - Terminal adapters(TA), are to ISDN what modems are to regular - phone lines. - modem - Most TA's use the standard hayes modem AT command set, and can be - used as a drop in replacement for a modem. - - A TA will operate basically the same as a modem except connection - and throughput speeds will be much faster than your old modem. You - will need to configure PPP exactly the same - as for a modem setup. Make sure you set your serial speed as high as - possible. - PPP - The main advantage of using a TA to connect to an Internet - Provider is that you can do Dynamic PPP. As IP address space becomes - more and more scarce, most providers are not willing to provide you - with a static IP anymore. Most stand-alone routers are not able to - accommodate dynamic IP allocation. - - TA's completely rely on the PPP daemon that you are running for - their features and stability of connection. This allows you to - upgrade easily from using a modem to ISDN on a FreeBSD machine, if you - already have PPP setup. However, at the same time any problems you - experienced with the PPP program and are going to persist. - - If you want maximum stability, use the kernel PPP option, not the user-land iijPPP. - - The following TA's are known to work with FreeBSD. - - - - Motorola BitSurfer and Bitsurfer Pro - - - - Adtran - - - - Most other TA's will probably work as well, TA vendors try to make - sure their product can accept most of the standard modem AT command - set. - - The real problem with external TA's is that, like modems, - you need a good serial card in your computer. - - You should read the FreeBSD Serial - Hardware tutorial for a detailed understanding of - serial devices, and the differences between asynchronous and - synchronous serial ports. - - A TA running off a standard PC serial port (asynchronous) limits - you to 115.2 Kbs, even though you have a 128 Kbs connection. - To fully utilize the 128 Kbs that ISDN is capable of, - you must move the TA to a synchronous serial card. - - Do not be fooled into buying an internal TA and thinking you have - avoided the synchronous/asynchronous issue. Internal TA's simply have - a standard PC serial port chip built into them. All this will do is - save you having to buy another serial cable and find another empty - electrical socket. - - A synchronous card with a TA is at least as fast as a stand-alone - router, and with a simple 386 FreeBSD box driving it, probably more - flexible. - - The choice of sync/TA v.s. stand-alone router is largely a - religious issue. There has been some discussion of this in - the mailing lists. I suggest you search the archives for - the complete discussion. - - - - Stand-alone ISDN Bridges/Routers - - ISDN - stand-alone bridges/routers - - ISDN bridges or routers are not at all specific to FreeBSD - or any other operating system. For a more complete - description of routing and bridging technology, please refer - to a Networking reference book. - - In the context of this page, the terms router and bridge will - be used interchangeably. - - As the cost of low end ISDN routers/bridges comes down, it - will likely become a more and more popular choice. An ISDN - router is a small box that plugs directly into your local - Ethernet network, and manages its own connection to the other - bridge/router. It has built in software to communicate via - PPP and other popular protocols. - - A router will allow you much faster throughput than a - standard TA, since it will be using a full synchronous ISDN - connection. - - The main problem with ISDN routers and bridges is that - interoperability between manufacturers can still be a problem. - If you are planning to connect to an Internet provider, you - should discuss your needs with them. - - If you are planning to connect two LAN segments together, - such as your home LAN to the office LAN, this is the simplest - lowest - maintenance solution. Since you are buying the equipment for - both sides of the connection you can be assured that the link - will work. - - For example to connect a home computer or branch office - network to a head office network the following setup could be - used. - - - Branch Office or Home Network - - 10 base 2 - Network uses a bus based topology with 10 base 2 - Ethernet (thinnet). Connect router to network cable with - AUI/10BT transceiver, if necessary. - - - - - - - - ---Sun workstation -| ----FreeBSD box -| ----Windows 95 (Do not admit to owning it) -| -Stand-alone router - | -ISDN BRI line - - - - 10 Base 2 Ethernet - - - - If your home/branch office is only one computer you can use a - twisted pair crossover cable to connect to the stand-alone router - directly. - - - - Head Office or Other LAN - - 10 base T - Network uses a star topology with 10 base T Ethernet - (Twisted Pair). - - - - - - - - -------Novell Server - | H | - | ---Sun - | | - | U ---FreeBSD - | | - | ---Windows 95 - | B | - |___---Stand-alone router - | - ISDN BRI line - - - - ISDN Network Diagram - - - - - One large advantage of most routers/bridges is that they allow you - to have 2 separate independent PPP connections to - 2 separate sites at the same time. This is not - supported on most TA's, except for specific (usually expensive) models - that - have two serial ports. Do not confuse this with channel bonding, MPP, - etc. - - This can be a very useful feature if, for example, you - have an dedicated ISDN connection at your office and would - like to tap into it, but do not want to get another ISDN line - at work. A router at the office location can manage a - dedicated B channel connection (64 Kbps) to the Internet - and use the other B channel for a separate data connection. - The second B channel can be used for dial-in, dial-out or - dynamically bonding (MPP, etc.) with the first B channel for - more bandwidth. - - IPX/SPX - An Ethernet bridge will also allow you to transmit more than just - IP traffic. You can also send IPX/SPX or whatever other protocols you - use. - - - - - - - - Bill - Swingle - Written by - - - - - Eric - Ogren - Enhanced by - - - Udo - Erdelhoff - - - - NIS/YP - - - What Is It? - NIS - Solaris - HP-UX - AIX - Linux - NetBSD - OpenBSD - NIS, which stands for Network Information Services, was - developed by Sun Microsystems to centralize administration of Unix - (originally SunOS) systems. It has now essentially become an - industry standard; all major Unix systems (Solaris, HP-UX, AIX, Linux, - NetBSD, OpenBSD, FreeBSD, etc) support NIS. - - yellow pagesNIS - NIS was formerly known as Yellow Pages, but because of - trademark issues, Sun changed the name. The old term (and yp) is - still often seen and used. - - - NIS - domains - - It is a RPC-based client/server system that allows a group - of machines within an NIS domain to share a common set of - configuration files. This permits a system administrator to set - up NIS client systems with only minimal configuration data and - add, remove or modify configuration data from a single - location. - - Windows NT - It is similar to Windows NT's domain system; although the - internal implementation of the two are not at all similar, - the basic functionality can be compared. - - - - Terms/Processes You Should Know - - There are several terms and several important user processes - that you will come across when - attempting to implement NIS on FreeBSD, whether you are trying to - create an NIS server or act as an NIS client: - - - portmap - - - - - - - Term - Description - - - - - NIS domainname - An NIS master server and all of its clients - (including its slave servers) have a NIS - domainname. Similar to an NT domain name, the NIS - domainname does not have anything to do with DNS. - - - portmap - Must be running in order to enable RPC (Remote - Procedure Call, a network protocol used by NIS). If - portmap is not running, it will be - impossible to run an NIS server, or to act as an NIS - client. - - - ypbind - - Binds an NIS client to its NIS - server. It will take the NIS domainname from the - system, and using RPC, connect to the - server. ypbind is the core of - client-server communication in an NIS environment; if - ypbind dies on a client machine, it - will not be able to access the NIS server. - - - ypserv - Should only be running on NIS servers; this is the NIS - server process itself. If &man.ypserv.8; dies, then the - server will no longer be able to respond to NIS requests - (hopefully, there is a slave server to take over for - it). There are some implementations of NIS (but not the - FreeBSD one), that do not try to reconnect to another - server if the server it used before dies. Often, the - only thing that helps in this case is to restart the - server process (or even the whole server) or the - ypbind process on the client. - - - - rpc.yppasswdd - Another process that should only be running on - NIS master servers; this is a daemon that will allow NIS - clients to change their NIS passwords. If this daemon - is not running, users will have to login to the NIS - master server and change their passwords there. - - - - - - - - - - How Does It Work? - - There are three types of hosts in an NIS environment: master - servers, slave servers, and clients. Servers act as a central - repository for host configuration information. Master servers - hold the authoritative copy of this information, while slave - servers mirror this information for redundancy. Clients rely on - the servers to provide this information to them. - - Information in many files can be shared in this manner. The - master.passwd, group, - and hosts files are commonly shared via NIS. - Whenever a process on a client needs information that would - normally be found in these files locally, it makes a query to the - NIS server that it is bound to instead. - - - Machine Types - - - - NIS - master server - - - A NIS master server. - This server, analogous to a Windows - NT primary domain controller, maintains the files used by all - of the NIS clients. The passwd, - group, and other various files used by the - NIS clients live on the master server. - - It is possible for one machine to be an NIS - master server for more than one NIS domain. However, this will - not be covered in this introduction, which assumes a relatively - small-scale NIS environment. - - - NIS - slave server - - - NIS slave servers. - Similar to NT's backup domain - controllers, NIS slave servers maintain copies of the NIS - master's data files. NIS slave servers provide the redundancy, - which is needed in important environments. They also help - to balance the load of the master server: NIS Clients always - attach to the NIS server whose response they get first, and - this includes slave-server-replies. - - - NIS - client - - - NIS clients. NIS clients, like most - NT workstations, authenticate against the NIS server (or the NT - domain controller in the NT Workstation case) to log on. - - - - - - - Using NIS/YP - - This section will deal with setting up a sample NIS - environment. - - This section assumes that you are running FreeBSD 3.3 - or later. The instructions given here will - probably work for any version of FreeBSD greater - than 3.0, but there are no guarantees that this is - true. - - - - Planning - - Let us assume that you are the administrator of a small - university lab. This lab, which consists of 15 FreeBSD machines, - currently has no centralized point of administration; each machine - has its own /etc/passwd and - /etc/master.passwd. These files are kept in - sync with each other only through manual intervention; - currently, when you add a user to the lab, you must run - adduser on all 15 machines. - Clearly, this has to change, so you have decided to convert the - lab to use NIS, using two of the machines as servers. - - Therefore, the configuration of the lab now looks something - like: - - - - - - Machine name - IP address - Machine role - - - - - ellington - 10.0.0.2 - NIS master - - - coltrane - 10.0.0.3 - NIS slave - - - basie - 10.0.0.4 - Faculty workstation - - - bird - 10.0.0.5 - Client machine - - - cli[1-11] - 10.0.0.[6-17] - Other client machines - - - - - - If you are setting up a NIS scheme for the first time, it - is a good idea to think through how you want to go about it. No - matter what the size of your network, there are a few decisions - that need to be made. - - - Choosing a NIS Domain Name - - - NIS - domainname - - This might not be the domainname that you - are used to. It is more accurately called the - NIS domainname. When a client broadcasts its - requests for info, it includes the name of the NIS domain - that it is part of. This is how multiple servers on one - network can tell which server should answer which request. - Think of the NIS domainname as the name for a group of hosts - that are related in some way. - - Some organizations choose to use their Internet - domainname for their NIS domainname. This is not - recommended as it can cause confusion when trying to debug - network problems. The NIS domainname should be unique - within your network and it is helpful if it describes the - group of machines it represents. For example, the Art - department at Acme Inc. might be in the - acme-art NIS domain. For this example, - assume you have chosen the name - test-domain. - - SunOS - However, some operating systems (notably SunOS) use their - NIS domain name as their Internet domain name. - If one or more machines on your network have this restriction, - you must use the Internet domain name as - your NIS domain name. - - - - Physical Server Requirements - - There are several things to keep in mind when choosing a - machine to use as a NIS server. One of the unfortunate things - about NIS is the level of dependency the clients have on the - server. If a client cannot contact the server for its NIS - domain, very often the machine becomes unusable. The lack of - user and group information causes most systems to temporarily - freeze up. With this in mind you should make sure to choose a - machine that will not be prone to being rebooted regularly, or - one that might be used for development. The NIS server should - ideally be a stand alone machine whose sole purpose in life is - to be an NIS server. If you have a network that is not very - heavily used, it is acceptable to put the NIS server on a - machine running other services, just keep in mind that if the - NIS server becomes unavailable, it will affect - all of your NIS clients adversely. - - - - - NIS Servers - - The canonical copies of all NIS information are stored on - a single machine called the NIS master server. The databases - used to store the information are called NIS maps. In FreeBSD, - these maps are stored in - /var/yp/[domainname] where - [domainname] is the name of the NIS domain - being served. A single NIS server can support several domains - at once, therefore it is possible to have several such - directories, one for each supported domain. Each domain will - have its own independent set of maps. - - NIS master and slave servers handle all NIS requests with - the ypserv daemon. ypserv - is responsible for receiving incoming requests from NIS clients, - translating the requested domain and map name to a path to the - corresponding database file and transmitting data from the - database back to the client. - - - Setting Up a NIS Master Server - - NIS - server configuration - - Setting up a master NIS server can be relatively straight - forward, depending on your needs. FreeBSD comes with support - for NIS out-of-the-box. All you need is to add the following - lines to /etc/rc.conf, and FreeBSD will - do the rest for you. - - - - nisdomainname="test-domain" - This line will set the NIS domainname to - test-domain - upon network setup (e.g. after reboot). - - - nis_server_enable="YES" - This will tell FreeBSD to start up the NIS server processes - when the networking is next brought up. - - - nis_yppasswdd_enable="YES" - This will enable the rpc.yppasswdd - daemon which, as mentioned above, will allow users to - change their NIS password from a client machine. - - - - - Depending on your NIS setup, you may need to add - further entries. See the section about NIS servers - that are also NIS clients, below, for - details. - - - Now, all you have to do is to run the command - /etc/netstart as superuser. It will - set up everything for you, using the values you defined in - /etc/rc.conf. - - - - Initializing the NIS Maps - - NIS - maps - - The NIS maps are database files, - that are kept in the /var/yp directory. - They are generated from configuration files in the - /etc directory of the NIS master, with one - exception: the /etc/master.passwd file. - This is for a good reason; you do not want to propagate - passwords to your root and other - administrative accounts to all the servers in the NIS domain. - Therefore, before we initialize the NIS maps, you should: - - &prompt.root; cp /etc/master.passwd /var/yp/master.passwd -&prompt.root; cd /var/yp -&prompt.root; vi master.passwd - - You should remove all entries regarding system accounts - (bin, tty, - kmem, games, etc), as - well as any accounts that you do not want to be propagated to the - NIS clients (for example root and any other - UID 0 (superuser) accounts). - - Make sure the - /var/yp/master.passwd is neither group - nor world readable (mode 600)! Use the - chmod command, if appropriate. - - Tru64 Unix - When you have finished, it is time to initialize the NIS - maps! FreeBSD includes a script named - ypinit to do this for you - (see its manual page for more information). Note that this - script is available on most Unix Operating Systems, but not on all. - On Digital Unix/Compaq Tru64 Unix it is called - ypsetup. - Because we are generating maps for an NIS master, we are - going to pass the option to - ypinit. - To generate the NIS maps, assuming you already performed - the steps above, run: - - ellington&prompt.root; ypinit -m test-domain -Server Type: MASTER Domain: test-domain -Creating an YP server will require that you answer a few questions. -Questions will all be asked at the beginning of the procedure. -Do you want this procedure to quit on non-fatal errors? [y/n: n] n -Ok, please remember to go back and redo manually whatever fails. -If you don't, something might not work. -At this point, we have to construct a list of this domains YP servers. -rod.darktech.org is already known as master server. -Please continue to add any slave servers, one per line. When you are -done with the list, type a <control D>. -master server : ellington -next host to add: coltrane -next host to add: ^D -The current list of NIS servers looks like this: -ellington -coltrane -Is this correct? [y/n: y] y - -[..output from map generation..] - -NIS Map update completed. -ellington has been setup as an YP master server without any errors. - - ypinit should have created - /var/yp/Makefile from - /var/yp/Makefile.dist. - When created, this file assumes that you are operating - in a single server NIS environment with only FreeBSD - machines. Since test-domain has - a slave server as well, you must edit - /var/yp/Makefile: - - ellington&prompt.root; vi /var/yp/Makefile - - You should comment out the line that says - - NOPUSH = "True" - - (if it is not commented out already). - - - - Setting up a NIS Slave Server - - NIS - slave server - - Setting up an NIS slave server is even more simple than - setting up the master. Log on to the slave server and edit the - file /etc/rc.conf as you did before. - The only difference is that we now must use the - option when running ypinit. - The option requires the name of the NIS - master be passed to it as well, so our command line looks - like: - - coltrane&prompt.root; ypinit -s ellington test-domain - -Server Type: SLAVE Domain: test-domain Master: ellington - -Creating an YP server will require that you answer a few questions. -Questions will all be asked at the beginning of the procedure. - -Do you want this procedure to quit on non-fatal errors? [y/n: n] n - -Ok, please remember to go back and redo manually whatever fails. -If you don't, something might not work. -There will be no further questions. The remainder of the procedure -should take a few minutes, to copy the databases from ellington. -Transferring netgroup... -ypxfr: Exiting: Map successfully transferred -Transferring netgroup.byuser... -ypxfr: Exiting: Map successfully transferred -Transferring netgroup.byhost... -ypxfr: Exiting: Map successfully transferred -Transferring master.passwd.byuid... -ypxfr: Exiting: Map successfully transferred -Transferring passwd.byuid... -ypxfr: Exiting: Map successfully transferred -Transferring passwd.byname... -ypxfr: Exiting: Map successfully transferred -Transferring group.bygid... -ypxfr: Exiting: Map successfully transferred -Transferring group.byname... -ypxfr: Exiting: Map successfully transferred -Transferring services.byname... -ypxfr: Exiting: Map successfully transferred -Transferring rpc.bynumber... -ypxfr: Exiting: Map successfully transferred -Transferring rpc.byname... -ypxfr: Exiting: Map successfully transferred -Transferring protocols.byname... -ypxfr: Exiting: Map successfully transferred -Transferring master.passwd.byname... -ypxfr: Exiting: Map successfully transferred -Transferring networks.byname... -ypxfr: Exiting: Map successfully transferred -Transferring networks.byaddr... -ypxfr: Exiting: Map successfully transferred -Transferring netid.byname... -ypxfr: Exiting: Map successfully transferred -Transferring hosts.byaddr... -ypxfr: Exiting: Map successfully transferred -Transferring protocols.bynumber... -ypxfr: Exiting: Map successfully transferred -Transferring ypservers... -ypxfr: Exiting: Map successfully transferred -Transferring hosts.byname... -ypxfr: Exiting: Map successfully transferred - -coltrane has been setup as an YP slave server without any errors. -Don't forget to update map ypservers on ellington. - - You should now have a directory called - /var/yp/test-domain. Copies of the NIS - master server's maps should be in this directory. You will - need to make sure that these stay updated. The following - /etc/crontab entries on your slave - servers should do the job: - - 20 * * * * root /usr/libexec/ypxfr passwd.byname -21 * * * * root /usr/libexec/ypxfr passwd.byuid - - These two lines force the slave to sync its maps with - the maps on the master server. Although these entries are - not mandatory, since the master server attempts to ensure - any changes to its NIS maps are communicated to its slaves - and because password information is vital to systems - depending on the server, it is a good idea to force the - updates. This is more important on busy networks where map - updates might not always complete. - - Now, run the command /etc/netstart on the - slave server as well, which again starts the NIS server. - - - - - NIS Clients - - An NIS client establishes what is called a binding to a - particular NIS server using the - ypbind daemon. - ypbind checks the system's default - domain (as set by the domainname command), - and begins broadcasting RPC requests on the local network. - These requests specify the name of the domain for which - ypbind is attempting to establish a binding. - If a server that has been configured to serve the requested - domain receives one of the broadcasts, it will respond to - ypbind, which will record the server's - address. If there are several servers available (a master and - several slaves, for example), ypbind will - use the address of the first one to respond. From that point - on, the client system will direct all of its NIS requests to - that server. ypbind will - occasionally ping the server to make sure it is - still up and running. If it fails to receive a reply to one of - its pings within a reasonable amount of time, - ypbind will mark the domain as unbound and - begin broadcasting again in the hopes of locating another - server. - - - Setting Up a NIS Client - - NIS - client configuration - - Setting up a FreeBSD machine to be a NIS client is fairly - straightforward. - - - - Edit the file /etc/rc.conf and - add the following lines in order to set the NIS domainname - and start ypbind upon network - startup: - - nisdomainname="test-domain" -nis_client_enable="YES" - - - - To import all possible password entries from the NIS - server, remove all user accounts from your - /etc/master.passwd file and use - vipw to add the following line to - the end of the file: - - +::::::::: - - - This line will afford anyone with a valid account in - the NIS server's password maps an account. There are - many ways to configure your NIS client by changing this - line. See the netgroups - section below for more information. - For more detailed reading see O'Reilly's book on - Managing NFS and NIS. - - - - You should keep at least one local account (i.e. - not imported via NIS) in your - /etc/master.passwd and this - account should also be a member of the group - wheel. If there is something - wrong with NIS, this account can be used to log in - remotely, become root, and fix things. - - - - - To import all possible group entries from the NIS - server, add this line to your - /etc/group file: - - +:*:: - - - - After completing these steps, you should be able to run - ypcat passwd and see the NIS server's - passwd map. - - - - - - NIS Security - - In general, any remote user can issue an RPC to - &man.ypserv.8; and retrieve the contents of your NIS maps, - provided the remote user knows your domainname. To prevent - such unauthorized transactions, &man.ypserv.8; supports a - feature called securenets which can be used to restrict access - to a given set of hosts. At startup, &man.ypserv.8; will - attempt to load the securenets information from a file called - /var/yp/securenets. - - - This path varies depending on the path specified with the - option. This file contains entries that - consist of a network specification and a network mask separated - by white space. Lines starting with # are - considered to be comments. A sample securenets file might look - like this: - - - # allow connections from local host -- mandatory -127.0.0.1 255.255.255.255 -# allow connections from any host -# on the 192.168.128.0 network -192.168.128.0 255.255.255.0 -# allow connections from any host -# between 10.0.0.0 to 10.0.15.255 -# this includes the machines in the testlab -10.0.0.0 255.255.240.0 - - If &man.ypserv.8; receives a request from an address that - matches one of these rules, it will process the request - normally. If the address fails to match a rule, the request - will be ignored and a warning message will be logged. If the - /var/yp/securenets file does not exist, - ypserv will allow connections from any - host. - - The ypserv program also has support for Wietse - Venema's - tcpwrapper package. This allows the - administrator to use the tcpwrapper configuration - files for access control instead of - /var/yp/securenets. - - - While both of these access control mechanisms provide some - security, they, like the privileged port test, are - vulnerable to IP spoofing attacks. All - NIS-related traffic should be blocked at your firewall. - - Servers using /var/yp/securenets - may fail to serve legitimate NIS clients with archaic TCP/IP - implementations. Some of these implementations set all - host bits to zero when doing broadcasts and/or fail to - observe the subnet mask when calculating the broadcast - address. While some of these problems can be fixed by - changing the client configuration, other problems may force - the retirement of the client systems in question or the - abandonment of /var/yp/securenets. - - Using /var/yp/securenets on a - server with such an archaic implementation of TCP/IP is a - really bad idea and will lead to loss of NIS functionality - for large parts of your network. - - tcpwrapper - The use of the tcpwrapper - package increases the latency of your NIS server. The - additional delay may be long enough to cause timeouts in - client programs, especially in busy networks or with slow - NIS servers. If one or more of your client systems - suffers from these symptoms, you should convert the client - systems in question into NIS slave servers and force them - to bind to themselves. - - - - - Barring Some Users from Logging On - - In our lab, there is a machine basie that is - supposed to be a faculty only workstation. We do not want to take this - machine out of the NIS domain, yet the passwd - file on the master NIS server contains accounts for both faculty and - students. What can we do? - - There is a way to bar specific users from logging on to a - machine, even if they are present in the NIS database. To do this, - all you must do is add - -username to the end of - the /etc/master.passwd file on the client - machine, where username is the username of - the user you wish to bar from logging in. This should preferably be - done using vipw, since vipw - will sanity check your changes to - /etc/master.passwd, as well as - automatically rebuild the password database when you - finish editing. For example, if we wanted to bar user - bill from logging on to basie - we would: - - basie&prompt.root; vipw -[add -bill to the end, exit] -vipw: rebuilding the database... -vipw: done - -basie&prompt.root; cat /etc/master.passwd - -root:[password]:0:0::0:0:The super-user:/root:/bin/csh -toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh -daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin -operator:*:2:5::0:0:System &:/:/sbin/nologin -bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin -tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin -kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin -games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin -news:*:8:8::0:0:News Subsystem:/:/sbin/nologin -man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin -bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin -uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico -xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin -pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin -nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin -+::::::::: --bill - -basie&prompt.root; - - - - - - - Udo - Erdelhoff - Contributed by - - - - - Using Netgroups - netgroups - - The method shown in the previous section works reasonably - well if you need special rules for a very small number of - users and/or machines. On larger networks, you - will forget to bar some users from logging - onto sensitive machines, or you may even have to modify each - machine separately, thus losing the main benefit of NIS, - centralized administration. - - The NIS developers' solution for this problem is called - netgroups. Their purpose and semantics - can be compared to the normal groups used by Unix file - systems. The main differences are the lack of a numeric id - and the ability to define a netgroup by including both user - accounts and other netgroups. - - Netgroups were developed to handle large, complex networks - with hundreds of users and machines. On one hand, this is - a Good Thing if you are forced to deal with such a situation. - On the other hand, this complexity makes it almost impossible to - explain netgroups with really simple examples. The example - used in the remainder of this section demonstrates this - problem. - - Let us assume that your successful introduction of NIS in - your laboratory caught your superiors' interest. Your next - job is to extend your NIS domain to cover some of the other - machines on campus. The two tables contain the names of the - new users and new machines as well as brief descriptions of - them. - - - - - - User Name(s) - Description - - - - - - alpha, beta - Normal employees of the IT department - - - - charlie, delta - The new apprentices of the IT department - - - - echo, foxtrott, golf, ... - Ordinary employees - - - - able, baker, ... - The current interns - - - - - - - - - - Machine Name(s) - Description - - - - - - - war, death, famine, pollution - Your most important servers. Only the IT - employees are allowed to log onto these - machines. - - - - pride, greed, envy, wrath, lust, sloth - Less important servers. All members of the IT - department are allowed to login onto these machines. - - - - one, two, three, four, ... - Ordinary workstations. Only the - real employees are allowed to use - these machines. - - - - trashcan - A very old machine without any critical data. - Even the intern is allowed to use this box. - - - - - - If you tried to implement these restrictions by separately - blocking each user, you would have to add one - -user line to each system's - passwd - for each user who is not allowed to login onto that system. - If you forget just one entry, you could be in trouble. It may - be feasible to do this correctly during the initial setup, - however you will eventually forget to add - the lines for new users during day-to-day operations. After - all, Murphy was an optimist. - - Handling this situation with netgroups offers several - advantages. Each user need not be handled separately; - you assign a user to one or more netgroups and allow or forbid - logins for all members of the netgroup. If you add a new - machine, you will only have to define login restrictions for - netgroups. If a new user is added, you will only have to add - the user to one or more netgroups. Those changes are - independent of each other; no more for each combination - of user and machine do... If your NIS setup is planned - carefully, you will only have to modify exactly one central - configuration file to grant or deny access to machines. - - The first step is the initialization of the NIS map - netgroup. FreeBSD's &man.ypinit.8; does not create this map by - default, but its NIS implementation will support it once it has - been created. To create an empty map, simply type - - ellington&prompt.root; vi /var/yp/netgroup - - and start adding content. For our example, we need at - least four netgroups: IT employees, IT apprentices, normal - employees and interns. - - IT_EMP (,alpha,test-domain) (,beta,test-domain) -IT_APP (,charlie,test-domain) (,delta,test-domain) -USERS (,echo,test-domain) (,foxtrott,test-domain) \ - (,golf,test-domain) -INTERNS (,able,test-domain) (,baker,test-domain) - - IT_EMP, IT_APP etc. - are the names of the netgroups. Each bracketed group adds - one or more user accounts to it. The three fields inside a - group are: - - - - The name of the host(s) where the following items are - valid. If you do not specify a hostname, the entry is - valid on all hosts. If you do specify a hostname, you - will enter a realm of darkness, horror and utter confusion. - - - - The name of the account that belongs to this - netgroup. - - - - The NIS domain for the account. You can import - accounts from other NIS domains into your netgroup if you - are one of the unlucky fellows with more than one NIS - domain. - - - - Each of these fields can contain wildcards. See - &man.netgroup.5; for details. - - - netgroups - Netgroup names longer than 8 characters should not be - used, especially if you have machines running other - operating systems within your NIS domain. The names are - case sensitive; using capital letters for your netgroup - names is an easy way to distinguish between user, machine - and netgroup names. - - Some NIS clients (other than FreeBSD) cannot handle - netgroups with a large number of entries. For example, some - older versions of SunOS start to cause trouble if a netgroup - contains more than 15 entries. You can - circumvent this limit by creating several sub-netgroups with - 15 users or less and a real netgroup that consists of the - sub-netgroups: - - BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] -BIGGRP2 (,joe16,domain) (,joe17,domain) [...] -BIGGRP3 (,joe31,domain) (,joe32,domain) -BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - - You can repeat this process if you need more than 225 - users within a single netgroup. - - - Activating and distributing your new NIS map is - easy: - - ellington&prompt.root; cd /var/yp -ellington&prompt.root; make - - This will generate the three NIS maps - netgroup, - netgroup.byhost and - netgroup.byuser. Use &man.ypcat.1; to - check if your new NIS maps are available: - - ellington&prompt.user; ypcat -k netgroup -ellington&prompt.user; ypcat -k netgroup.byhost -ellington&prompt.user; ypcat -k netgroup.byuser - - The output of the first command should resemble the - contents of /var/yp/netgroup. The second - command will not produce output if you have not specified - host-specific netgroups. The third command can be used to - get the list of netgroups for a user. - - The client setup is quite simple. To configure the server - war, you only have to start - &man.vipw.8; and replace the line - - +::::::::: - - with - - +@IT_EMP::::::::: - - Now, only the data for the users defined in the netgroup - IT_EMP is imported into - war's password database and only - these users are allowed to login. - - Unfortunately, this limitation also applies to the ~ - function of the shell and all routines converting between user - names and numerical user IDs. In other words, - cd ~user will not work, - ls -l will show the numerical id instead of - the username and find . -user joe -print will - fail with No such user. To fix this, you will - have to import all user entries without allowing them - to login onto your servers. - - This can be achieved by adding another line to - /etc/master.passwd. This line should - contain: - - +:::::::::/sbin/nologin, meaning - Import all entries but replace the shell with - /sbin/nologin in the imported - entries. You can replace any field - in the passwd entry by placing a default value in your - /etc/master.passwd. - - - - Make sure that the line - +:::::::::/sbin/nologin is placed after - +@IT_EMP:::::::::. Otherwise, all user - accounts imported from NIS will have /sbin/nologin as their - login shell. - - - After this change, you will only have to change one NIS - map if a new employee joins the IT department. You could use - a similar approach for the less important servers by replacing - the old +::::::::: in their local version - of /etc/master.passwd with something like - this: - - +@IT_EMP::::::::: -+@IT_APP::::::::: -+:::::::::/sbin/nologin - - The corresponding lines for the normal workstations - could be: - - +@IT_EMP::::::::: -+@USERS::::::::: -+:::::::::/sbin/nologin - - And everything would be fine until there is a policy - change a few weeks later: The IT department starts hiring - interns. The IT interns are allowed to use the normal - workstations and the less important servers; and the IT - apprentices are allowed to login onto the main servers. You - add a new netgroup IT_INTERN, add the new IT interns to this - netgroup and start to change the config on each and every - machine... As the old saying goes: Errors in - centralized planning lead to global mess. - - NIS' ability to create netgroups from other netgroups can - be used to prevent situations like these. One possibility - is the creation of role-based netgroups. For example, you - could create a netgroup called - BIGSRV to define the login - restrictions for the important servers, another netgroup - called SMALLSRV for the less - important servers and a third netgroup called - USERBOX for the normal - workstations. Each of these netgroups contains the netgroups - that are allowed to login onto these machines. The new - entries for your NIS map netgroup should look like this: - - BIGSRV IT_EMP IT_APP -SMALLSRV IT_EMP IT_APP ITINTERN -USERBOX IT_EMP ITINTERN USERS - - This method of defining login restrictions works - reasonably well if you can define groups of machines with - identical restrictions. Unfortunately, this is the exception - and not the rule. Most of the time, you will need the ability - to define login restrictions on a per-machine basis. - - Machine-specific netgroup definitions are the other - possibility to deal with the policy change outlined above. In - this scenario, the /etc/master.passwd of - each box contains two lines starting with +. - The first of them adds a netgroup with the accounts allowed to - login onto this machine, the second one adds all other - accounts with /sbin/nologin as shell. It - is a good idea to use the ALL-CAPS version of the machine name - as the name of the netgroup. In other words, the lines should - look like this: - - +@BOXNAME::::::::: -+:::::::::/sbin/nologin - - Once you have completed this task for all your machines, - you will not have to modify the local versions of - /etc/master.passwd ever again. All - further changes can be handled by modifying the NIS map. Here - is an example of a possible netgroup map for this - scenario with some additional goodies. - - # Define groups of users first -IT_EMP (,alpha,test-domain) (,beta,test-domain) -IT_APP (,charlie,test-domain) (,delta,test-domain) -DEPT1 (,echo,test-domain) (,foxtrott,test-domain) -DEPT2 (,golf,test-domain) (,hotel,test-domain) -DEPT3 (,india,test-domain) (,juliet,test-domain) -ITINTERN (,kilo,test-domain) (,lima,test-domain) -D_INTERNS (,able,test-domain) (,baker,test-domain) -# -# Now, define some groups based on roles -USERS DEPT1 DEPT2 DEPT3 -BIGSRV IT_EMP IT_APP -SMALLSRV IT_EMP IT_APP ITINTERN -USERBOX IT_EMP ITINTERN USERS -# -# And a groups for a special tasks -# Allow echo and golf to access our anti-virus-machine -SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) -# -# machine-based netgroups -# Our main servers -WAR BIGSRV -FAMINE BIGSRV -# User india needs access to this server -POLLUTION BIGSRV (,india,test-domain) -# -# This one is really important and needs more access restrictions -DEATH IT_EMP -# -# The anti-virus-machine mentioned above -ONE SECURITY -# -# Restrict a machine to a single user -TWO (,hotel,test-domain) -# [...more groups to follow] - - If you are using some kind of database to manage your user - accounts, you should be able to create the first part of the - map with your database's report tools. This way, new users - will automatically have access to the boxes. - - One last word of caution: It may not always be advisable - to use machine-based netgroups. If you are deploying a couple of - dozen or even hundreds of identical machines for student labs, - you should use role-based netgroups instead of machine-based - netgroups to keep the size of the NIS map within reasonable - limits. - - - - Important Things to Remember - - There are still a couple of things that you will need to do - differently now that you are in an NIS environment. - - - - Every time you wish to add a user to the lab, you - must add it to the master NIS server only, - and you must remember to rebuild the NIS - maps. If you forget to do this, the new user will - not be able to login anywhere except on the NIS master. - For example, if we needed to add a new user - jsmith to the lab, we would: - - &prompt.root; pw useradd jsmith -&prompt.root; cd /var/yp -&prompt.root; make test-domain - - You could also run adduser jsmith instead - of pw useradd jsmith. - - - Keep the administration accounts out of the NIS - maps. You do not want to be propagating administrative - accounts and passwords to machines that will have users that - should not have access to those accounts. - - - Keep the NIS master and slave - secure, and minimize their downtime. - If somebody either hacks or simply turns off - these machines, they have effectively rendered many people without - the ability to login to the lab. - - This is the chief weakness of any centralized administration - system, and it is probably the most important weakness. If you do - not protect your NIS servers, you will have a lot of angry - users! - - - - - - NIS v1 Compatibility - - FreeBSD's ypserv has some support - for serving NIS v1 clients. FreeBSD's NIS implementation only - uses the NIS v2 protocol, however other implementations include - support for the v1 protocol for backwards compatibility with older - systems. The ypbind daemons supplied - with these systems will try to establish a binding to an NIS v1 - server even though they may never actually need it (and they may - persist in broadcasting in search of one even after they receive a - response from a v2 server). Note that while support for normal - client calls is provided, this version of ypserv does not handle - v1 map transfer requests; consequently, it cannot be used as a - master or slave in conjunction with older NIS servers that only - support the v1 protocol. Fortunately, there probably are not any - such servers still in use today. - - - - NIS Servers That Are Also NIS Clients - - Care must be taken when running ypserv in a multi-server - domain where the server machines are also NIS clients. It is - generally a good idea to force the servers to bind to themselves - rather than allowing them to broadcast bind requests and possibly - become bound to each other. Strange failure modes can result if - one server goes down and others are dependent upon it. - Eventually all the clients will time out and attempt to bind to - other servers, but the delay involved can be considerable and the - failure mode is still present since the servers might bind to each - other all over again. - - You can force a host to bind to a particular server by running - ypbind with the - flag. If you do not want to do this manually each time you - reboot your NIS server, you can add the following lines to - your /etc/rc.conf: - - nis_client_enable="YES" # run client stuff as well -nis_client_flags="-S NIS domain,server" - - See &man.ypbind.8; for further information. - - - - Password Formats - - NIS - password formats - - One of the most common issues that people run into when trying - to implement NIS is password format compatibility. If your NIS - server is using DES encrypted passwords, it will only support - clients that are also using DES. For example, if you have - Solaris NIS clients in your network, then you will almost certainly - need to use DES encrypted passwords. - - To check which format your servers - and clients are using, look at /etc/login.conf. - If the host is configured to use DES encrypted passwords, then the - default class will contain an entry like this: - - default:\ - :passwd_format=des:\ - :copyright=/etc/COPYRIGHT:\ - [Further entries elided] - - Other possible values for the passwd_format - capability include blf and md5 - (for Blowfish and MD5 encrypted passwords, respectively). - - If you have made changes to /etc/login.conf, - you will also need to rebuild the login capability database, which is - achieved by running the following command as root: - - &prompt.root; cap_mkdb /etc/login.conf - - The format of passwords already in - /etc/master.passwd will not be updated until - a user changes their password for the first time after - the login capability database is rebuilt. - - Next, in order to ensure that passwords are encrypted with the - format that you have chosen, you should also check that the - crypt_default in /etc/auth.conf - gives precedence to your chosen password format. To do this, place - the format that you have chosen first in the list. For example, when - using DES encrypted passwords, the entry would be: - - crypt_default = des blf md5 - - Having followed the above steps on each of the &os; based NIS - servers and clients, you can be sure that they all agree on which - password format is used within your network. - If you have trouble authenticating on an NIS client, this - is a pretty good place to start looking for possible problems. - Remember: if you want to deploy an NIS server for a heterogenous - network, you will probably have to use DES on all systems - because it is the lowest common standard. - - - - - - - - Greg - Sutter - Written by - - - - DHCP - - - What Is DHCP? - - Dynamic Host Configuration Protocol - DHCP - - - Internet Software Consortium (ISC) - - - DHCP, the Dynamic Host Configuration Protocol, describes - the means by which a system can connect to a network and obtain the - necessary information for communication upon that network. FreeBSD - uses the ISC (Internet Software Consortium) DHCP implementation, so - all implementation-specific information here is for use with the ISC - distribution. - - - - What This Section Covers - - This section describes both the client-side and server-side - components of the ISC DHCP system. The client-side program, - dhclient, comes integrated within FreeBSD, and - the server-side portion is available from the - net/isc-dhcp3 port. The - &man.dhclient.8;, &man.dhcp-options.5;, and &man.dhclient.conf.5; - manual pages, in addition to the references below, are useful - resources. - - - - How It Works - UDP - When dhclient, the DHCP client, is - executed on the client machine, it begins broadcasting - requests for configuration information. By default, these - requests are on UDP port 68. The server replies on UDP 67, - giving the client an IP address and other relevant network - information such as netmask, router, and DNS servers. All of - this information comes in the form of a DHCP - lease and is only valid for a certain time - (configured by the DHCP server maintainer). In this manner, - stale IP addresses for clients no longer connected to the - network can be automatically reclaimed. - - DHCP clients can obtain a great deal of information from - the server. An exhaustive list may be found in - &man.dhcp-options.5;. - - - - FreeBSD Integration - - FreeBSD fully integrates the ISC DHCP client, - dhclient. DHCP client support is provided - within both the installer and the base system, obviating the need - for detailed knowledge of network configurations on any network - that runs a DHCP server. dhclient has been - included in all FreeBSD distributions since 3.2. - - sysinstall - - - DHCP is supported by - sysinstall. When configuring a - network interface within sysinstall, the first question - asked is, Do you want to try DHCP configuration of - this interface? Answering affirmatively will execute - dhclient, and if successful, will fill in - the network configuration information automatically. - - There are two things you must do to have your system use - DHCP upon startup: - - DHCP - requirements - - - - Make sure that the bpf - device is compiled into your kernel. To do this, add - pseudo-device bpf to your kernel - configuration file, and rebuild the kernel. For more - information about building kernels, see . - The bpf device is already - part of the GENERIC kernel that is - supplied with FreeBSD, so if you do not have a custom - kernel, you should not need to create one in order to get - DHCP working. - - For those who are particularly security conscious, - you should be warned that bpf - is also the device that allows packet sniffers to work - correctly (although they still have to be run as - root). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not add bpf to your - kernel in the expectation that at some point in the - future you will be using DHCP. - - - - Edit your /etc/rc.conf to - include the following: - - ifconfig_fxp0="DHCP" - - - Be sure to replace fxp0 with the - designation for the interface that you wish to dynamically - configure, as described in - . - - - If you are using a different location for - dhclient, or if you wish to pass additional - flags to dhclient, also include the - following (editing as necessary): - - dhcp_program="/sbin/dhclient" -dhcp_flags="" - - - - - DHCP - server - - The DHCP server, dhcpd, is included - as part of the net/isc-dhcp3 port in the ports - collection. This port contains the full ISC DHCP - distribution, consisting of client, server, relay agent and - documentation. - - - - - Files - - DHCP - configuration files - - - /etc/dhclient.conf - dhclient requires a configuration file, - /etc/dhclient.conf. Typically the file - contains only comments, the defaults being reasonably sane. This - configuration file is described by the &man.dhclient.conf.5; - manual page. - - - /sbin/dhclient - dhclient is statically linked and - resides in /sbin. The &man.dhclient.8; - manual page gives more information about - dhclient. - - - /sbin/dhclient-script - dhclient-script is the FreeBSD-specific - DHCP client configuration script. It is described in - &man.dhclient-script.8;, but should not need any user - modification to function properly. - - - /var/db/dhclient.leases - The DHCP client keeps a database of valid leases in this - file, which is written as a log. &man.dhclient.leases.5; - gives a slightly longer description. - - - - - - Further Reading - - The DHCP protocol is fully described in - RFC 2131. - An informational resource has also been set up at - dhcp.org. - - - - Installing and Configuring a DHCP Server - - - What This Section Covers - - This section provides information on how to configure - a FreeBSD system to act as a DHCP server using the ISC - (Internet Software Consortium) implementation of the DHCP - suite. - - The server portion of the suite is not provided as part of - FreeBSD, and so you will need to install the - net/isc-dhcp3 - port to provide this service. See for - more information on using the ports collection. - - - - DHCP Server Installation - - DHCP - installation - - In order to configure your FreeBSD system as a DHCP server, - you will need to ensure that the &man.bpf.4; - device is compiled into your kernel. To do this, add - pseudo-device bpf to your kernel - configuration file, and rebuild the kernel. For more - information about building kernels, see . - - The bpf device is already - part of the GENERIC kernel that is - supplied with FreeBSD, so you do not need to create a custom - kernel in order to get DHCP working. - - - Those who are particularly security conscious - should note that bpf - is also the device that allows packet sniffers to work - correctly (although such programs still need privileged - access). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not include bpf in your - kernel purely because you expect to use DHCP at some - point in the future. - - - The next thing that you will need to do is edit the sample - dhcpd.conf which was installed by the - net/isc-dhcp3 port. - By default, this will be - /usr/local/etc/dhcpd.conf.sample, and you - should copy this to - /usr/local/etc/dhcpd.conf before proceeding - to make changes. - - - - Configuring the DHCP Server - - DHCP - dhcpd.conf - - dhcpd.conf is - comprised of declarations regarding subnets and hosts, and is - perhaps most easily explained using an example : - - option domain-name "example.com"; -option domain-name-servers 192.168.4.100; -option subnet-mask 255.255.255.0; - -default-lease-time 3600; -max-lease-time 86400; -ddns-update-style none; - -subnet 192.168.4.0 netmask 255.255.255.0 { - range 192.168.4.129 192.168.4.254; - option routers 192.168.4.1; -} - -host mailhost { - hardware ethernet 02:03:04:05:06:07; - fixed-address mailhost.example.com; -} - - - - This option specifies the domain that will be provided - to clients as the default search domain. See - &man.resolv.conf.5; for more information on what this - means. - - - - This option specifies a comma separated list of DNS - servers that the client should use. - - - - The netmask that will be provided to clients. - - - - A client may request a specific length of time that a - lease will be valid. Otherwise the server will assign - a lease with this expiry value (in seconds). - - - - This is the maximum length of time that the server will - lease for. Should a client request a longer lease, a lease - will be issued, although it will only be valid for - max-lease-time seconds. - - - - This option specifies whether the DHCP server should - attempt to update DNS when a lease is accepted or released. - In the ISC implementation, this option is - required. - - - - This denotes which IP addresses should be used in - the pool reserved for allocating to clients. IP - addresses between, and including, the ones stated are - handed out to clients. - - - - Declares the default gateway that will be provided to - clients. - - - - The hardware MAC address of a host (so that the DHCP server - can recognize a host when it makes a request). - - - - Specifies that the host should always be given the same - IP address. Note that a hostname is OK here, since the DHCP - server will resolve the hostname itself before returning the - lease information. - - - - Once you have finished writing your - dhcpd.conf, you can proceed to start the - server by issuing the following command: - - &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start - - Should you need to make changes to the configuration of your - server in the future, it is important to note that sending a - SIGHUP signal to - dhcpd does not - result in the configuration being reloaded, as it does with most - daemons. You will need to send a SIGTERM - signal to stop the process, and then restart it using the command - above. - - - - Files - - DHCP - configuration files - - - /usr/local/sbin/dhcpd - dhcpd is statically linked and - resides in /usr/local/sbin. The - dhcpd(8) manual page installed with the - port gives more information about - dhcpd. - - - /usr/local/etc/dhcpd.conf - dhcpd requires a configuration - file, /usr/local/etc/dhcpd.conf before it - will start providing service to clients. This file needs to - contain all the information that should be provided to clients - that are being serviced, along with information regarding the - operation of the server. This configuration file is described - by the dhcpd.conf(5) manual page installed - by the port. - - - /var/db/dhcpd.leases - The DHCP server keeps a database of leases it has issued - in this file, which is written as a log. The manual page - dhcpd.leases(5), installed by the port - gives a slightly longer description. - - - /usr/local/sbin/dhcrelay - dhcrelay is used in advanced - environments where one DHCP server forwards a request from a - client to another DHCP server on a separate network. The - dhcrelay(8) manual page provided with the - port contains more detail. - - - - - - - - - - - - - Chern - Lee - Contributed by - - - - DNS - - - Overview - BIND - - FreeBSD utilizes, by default, a version of BIND (Berkeley - Internet Name Domain), which is the most common implementation of the - DNS protocol. DNS is the protocol through which names are mapped to - IP addresses, and vice versa. For example, a query for - www.FreeBSD.org - will receive a reply with the IP address of The FreeBSD Project's - web server, whereas, a query for ftp.FreeBSD.org - will return the IP - address of the corresponding FTP machine. Likewise, the opposite can - happen. A query for an IP address can resolve its hostname. It is - not necessary to run a name server to perform DNS lookups on a system. - - - DNS - DNS is coordinated across the Internet through a somewhat - complex system of authoritative root name servers, and other - smaller-scale name servers who host and cache individual domain - information. - - - - This document refers to BIND 8.x, as it is the stable version - used in FreeBSD. BIND 9.x in FreeBSD can be installed through - the net/bind9 port. - - - - RFC1034 and RFC1035 dictate the DNS protocol. - - - - Currently, BIND is maintained by the - Internet Software Consortium (www.isc.org) - - - - - Terminology - - To understand this document, some terms related to DNS must be - understood. - - - - - - Term - Definition - - - - - - forward DNS - mapping of hostnames to IP addresses - - - - origin - refers to the domain covered for the particular zone - file - - - - named, bind, name server - common names for the BIND name server package within - FreeBSD - - - resolver - - resolver - a system process through which a - machine queries a name server for zone information - - - reverse DNS - - reverse DNS - the opposite of forward DNS, mapping of IP addresses to - hostnames - - - root zone - - root zone - - literally, a ., refers to the - root, or beginning zone. All zones fall under this, as - do all files in fall under the root directory. It is - the beginning of the Internet zone hierarchy. - - - - zone - Each individual domain, subdomain, or area dictated by - DNS - - - - - - - zones - examples - - - Examples of zones: - - - - . is the root zone - - - org. is a zone under the root zone - - - example.org is a zone under the - org. zone - - - foo.example.org. is a subdomain, a - zone under the example.org. zone - - - - 1.2.3.in-addr.arpa is a zone referencing - all IP addresses which fall under the 3.2.1.* IP space. - - - - - As one can see, the more specific part of a hostname appears to - its left. For example, example.org. is more - specific than org., as org. is - more specific than the root zone. The layout of each part of - a hostname is much like a filesystem: the /dev - directory falls within the root, and so on. - - - - - - Reasons to Run a Name Server - - Name servers usually come in two forms: an authoritative - name server, and a caching name server. - - An authoritative name server is needed when: - - - - one wants to serve DNS information to the - world, replying authoritatively to queries. - - - a domain, such as example.org, is - registered and IP addresses need to be assigned to hostnames - under it. - - - an IP address block requires reverse DNS entries (IP to - hostname). - - - a backup name server, called a slave, must reply to queries - when the primary is down or inaccessible. - - - - A caching name server is needed when: - - - - a local DNS server may cache and respond more quickly - than querying an outside name server. - - - a reduction in overall network traffic is desired (DNS - traffic has been measured to account for 5% or more of total - Internet traffic). - - - - When one queries for www.FreeBSD.org, the - resolver usually queries the uplink ISP's name server, and retrieves - the reply. With a local, caching DNS server, the query only has to - be made once to the outside world by the caching DNS server. Every - additional query will not have to look to the outside of the local - network, since the information is cached locally. - - - - - How It Works - In FreeBSD, the BIND daemon is called - named for obvious reasons. - - - - - - File - Description - - - - - - named - the BIND daemon - - - - ndc - name daemon control program - - - - /etc/namedb - directory where BIND zone information resides - - - - /etc/namedb/named.conf - daemon configuration file - - - - - - - Zone files are usually contained within the - /etc/namedb - directory, and contain the DNS zone information - served by the name server. - - - - - Starting BIND - - BIND - starting - - - Since BIND is installed by default, configuring it all is - relatively simple. - - - To ensure the named daemon is started at boot, put the following - modifications in /etc/rc.conf: - - named_enable="YES" - To start the daemon manually (after configuring it) - &prompt.root; ndc start - - - - Configuration Files - - BIND - configuration files - - - Using <command>make-localhost</command> - Be sure to: - - &prompt.root; cd /etc/namedb -&prompt.root; sh make-localhost - to properly create the local reverse DNS zone file in - /etc/namedb/localhost.rev. - - - - - <filename>/etc/namedb/named.conf</filename> - - // $FreeBSD$ -// -// Refer to the named(8) manual page for details. If you are ever going -// to setup a primary server, make sure you've understood the hairy -// details of how DNS is working. Even with simple mistakes, you can -// break connectivity for affected parties, or cause huge amount of -// useless Internet traffic. - -options { - directory "/etc/namedb"; - -// In addition to the "forwarders" clause, you can force your name -// server to never initiate queries of its own, but always ask its -// forwarders only, by enabling the following line: -// -// forward only; - -// If you've got a DNS server around at your upstream provider, enter -// its IP address here, and enable the line below. This will make you -// benefit from its cache, thus reduce overall DNS traffic in the -Internet. -/* - forwarders { - 127.0.0.1; - }; -*/ - - - Just as the comment says, to benefit from an uplink's cache, - forwarders can be enabled here. Under normal - circumstances, a name server will recursively query the Internet - looking at certain name servers until it finds the answer it is - looking for. Having this enabled will have it query the uplink's - name server (or name server provided) first, taking advantage of - its cache. If the uplink name server in question is a heavily - trafficked, fast name server, enabling this may be worthwhile. - - - 127.0.0.1 - will not work here. - Change this IP address to a name server at your uplink. - - - /* - * If there is a firewall between you and name servers you want - * to talk to, you might need to uncomment the query-source - * directive below. Previous versions of BIND always asked - * questions using port 53, but BIND 8.1 uses an unprivileged - * port by default. - */ - // query-source address * port 53; - - /* - * If running in a sandbox, you may have to specify a different - * location for the dumpfile. - */ - // dump-file "s/named_dump.db"; -}; - -// Note: the following will be supported in a future release. -/* -host { any; } { - topology { - 127.0.0.0/8; - }; -}; -*/ - -// Setting up secondaries is way easier and the rough picture for this -// is explained below. -// -// If you enable a local name server, don't forget to enter 127.0.0.1 -// into your /etc/resolv.conf so this server will be queried first. -// Also, make sure to enable it in /etc/rc.conf. - -zone "." { - type hint; - file "named.root"; -}; - -zone "0.0.127.IN-ADDR.ARPA" { - type master; - file "localhost.rev"; -}; - -zone -"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { - type master; - file "localhost.rev"; -}; - -// NB: Do not use the IP addresses below, they are faked, and only -// serve demonstration/documentation purposes! -// -// Example secondary config entries. It can be convenient to become -// a secondary at least for the zone where your own domain is in. Ask -// your network administrator for the IP address of the responsible -// primary. -// -// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! -// (This is the first bytes of the respective IP address, in reverse -// order, with ".IN-ADDR.ARPA" appended.) -// -// Before starting to setup a primary zone, better make sure you fully -// understand how DNS and BIND works, however. There are sometimes -// unobvious pitfalls. Setting up a secondary is comparably simpler. -// -// NB: Don't blindly enable the examples below. :-) Use actual names -// and addresses instead. -// -// NOTE!!! FreeBSD runs bind in a sandbox (see named_flags in rc.conf). -// The directory containing the secondary zones must be write accessible -// to bind. The following sequence is suggested: -// -// mkdir /etc/namedb/s -// chown bind:bind /etc/namedb/s -// chmod 750 /etc/namedb/s - - For more information on running BIND in a sandbox, see - Running named in a sandbox. - - - /* -zone "example.com" { - type slave; - file "s/example.com.bak"; - masters { - 192.168.1.1; - }; -}; - -zone "0.168.192.in-addr.arpa" { - type slave; - file "s/0.168.192.in-addr.arpa.bak"; - masters { - 192.168.1.1; - }; -}; -*/ - In named.conf, these are examples of slave - entries for a forward and reverse zone. - - For each new zone served, a new zone entry must be added to - named.conf - - For example, the simplest zone entry for - example.org can look like: - - zone "example.org" { - type master; - file "example.org"; -}; - - The zone is a master, as indicated by the - statement, holding its zone information in - /etc/namedb/example.org indicated by - the statement. - - zone "example.org" { - type slave; - file "example.org"; -}; - - In the slave case, the zone information is transferred from - the master name server for the particular zone, and saved in the - file specified. If and when the master server dies or is - unreachable, the slave name server will have the transferred - zone information and will be able to serve it. - - - - Zone Files - - An example master zone file for example.org - (existing within /etc/namedb/example.org) - is as follows: - - - $TTL 3600 - -example.org. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh - 3600 ; Retry - 604800 ; Expire - 86400 ) ; Minimum TTL - -; DNS Servers -@ IN NS ns1.example.org. -@ IN NS ns2.example.org. - -; Machine Names -localhost IN A 127.0.0.1 -ns1 IN A 3.2.1.2 -ns2 IN A 3.2.1.3 -mail IN A 3.2.1.10 -@ IN A 3.2.1.30 - -; Aliases -www IN CNAME @ - -; MX Record -@ IN MX 10 mail.example.org. - - - Note that every hostname ending in a . is an - exact hostname, whereas everything without a trailing - . is referenced to the origin. For example, - www is translated into www + - origin. In our fictitious zone file, our origin - is example.org., so - www would translate to - www.example.org. - - - - The format of a zone file follows: - - recordname IN recordtype value - - - DNS - records - - - The most commonly used DNS records: - - - - - SOA - - start of zone authority - - - - NS - - an authoritative name server - - - - A - - A host address - - - - CNAME - - the canonical name for an alias - - - - MX - - mail exchanger - - - - PTR - - a domain name pointer (used in reverse DNS) - - - - - -example.org. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh after 3 hours - 3600 ; Retry after 1 hour - 604800 ; Expire after 1 week - 86400 ) ; Minimum TTL of 1 day - - - - - - example.org. - - the domain name, also the origin for this - zone file. - - - - ns1.example.org. - - the primary/authoritative name server for this - zone - - - - admin.example.org. - - the responsible person for this zone, - email address with @ - replaced. (admin@example.org becomes - admin.example.org) - - - - - 5 - - the serial number of the file. this - must be incremented each time the zone file is modified. - Nowadays, many admins prefer a - yyyymmddrr format for the serial - number. 2001041002 would mean last modified 04/10/2001, - the latter 02 being the second time the zone file has - been modified this day. The serial number is important - as it alerts slave name servers for a zone when it is - updated. - - - - - -@ IN NS ns1.example.org. - - - This is an NS entry. Every name server that is going to reply - authoritatively for the zone must have one of these entries. - The @ as seen here could have been - example.org. - The @ translates to the origin. - - - -localhost IN A 127.0.0.1 -ns1 IN A 3.2.1.2 -ns2 IN A 3.2.1.3 -mail IN A 3.2.1.10 -@ IN A 3.2.1.30 - - - The A record indicates machine names. As seen above, - ns1.example.org would resolve to - 3.2.1.2. Again, - the origin symbol, @, is - used here, thus meaning example.org - would resolve to 3.2.1.30. - - - -www IN CNAME @ - - - The canonical name record is usually used for giving aliases - to a machine. In the example, www is - aliased to the machine addressed to the origin, or - example.org - (3.2.1.30). - CNAMEs can be used to provide alias - hostnames, or round robin one hostname among multiple - machines. - - - -@ IN MX 10 mail.example.org. - - - The MX record indicates which mail - servers are responsible for handling incoming mail for the - zone. mail.example.org is the - hostname of the mail server, and 10 being the priority of - that mail server. - - - - One can have several mail servers, with priorities of 3, 2, - 1. A mail server attempting to deliver to example.org would first try the - highest priority MX, then the second highest, etc, until the - mail can be properly delivered. - - - - For in-addr.arpa zone files (reverse DNS), the same format is - used, except with PTR entries instead of - A or CNAME. - - - $TTL 3600 - -1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh - 3600 ; Retry - 604800 ; Expire - 3600 ) ; Minimum - -@ IN NS ns1.example.org. -@ IN NS ns2.example.org. - -2 IN PTR ns1.example.org. -3 IN PTR ns2.example.org. -10 IN PTR mail.example.org. -30 IN PTR example.org. - - This file gives the proper IP address to hostname mappings of our above - fictitious domain. - - - - - - Caching Name Server - - BIND - caching name server - - - A caching name server is a name server that is not - authoritative for any zones. It simply asks queries of its own, - and remembers them for later use. To set one up, just configure - the name server as usual, omitting any inclusions of zones. - - - - - Running <application>named</application> in a Sandbox - - BIND - running in a sandbox - - - - chroot - - For added security you may want to run &man.named.8; as an - unprivileged user, and configure it to &man.chroot.8; into a - sandbox directory. This makes everything outside of the sandbox - inaccessible to the named daemon. Should - named be compromised, this will help to - reduce the damage that can be caused. By default, FreeBSD has a user - and a group called bind, intended for this - use. - - Various people would recommend that instead of configuring - named to chroot, you - should run named inside a &man.jail.8;. - This section does not attempt to cover this situation. - - - Since named will not be able to - access anything outside of the sandbox (such as shared - libraries, log sockets, and so on), there are a number of steps - that need to be followed in order to allow - named to function correctly. In the - following checklist, it is assumed that the path to the sandbox - is /etc/namedb and that you have made no - prior modifications to the contents of this directory. Perform - the following steps as root. - - - - Create all directories that named - expects to see: - - &prompt.root; cd /etc/namedb -&prompt.root; mkdir -p bin dev etc var/tmp var/run master slave -&prompt.root; chown bind:bind slave var/* - - - - - - named only needs write access to - these directories, so that is all we give it. - - - - - - Rearrange and create basic zone and configuration files: - &prompt.root; cp /etc/localtime etc -&prompt.root; mv named.conf etc && ln -sf etc/named.conf -&prompt.root; mv named.root master - -&prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master -&prompt.root; cat > master/named.localhost -$ORIGIN localhost. -$TTL 6h -@ IN SOA localhost. postmaster.localhost. ( - 1 ; serial - 3600 ; refresh - 1800 ; retry - 604800 ; expiration - 3600 ) ; minimum - IN NS localhost. - IN A 127.0.0.1 -^D - - - - This allows named to log the - correct time to &man.syslogd.8; - - - - - - Build a statically linked copy of - named-xfer, and copy it into the sandbox: - - &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir && make cleandir && make depend && make all -&prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir && make cleandir && make depend && make all -&prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all -&prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer - - After your statically linked - named-xfer is installed some cleaning up - is required, to avoid leaving stale copies of libraries or - programs in your source tree: - - &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir -&prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir -&prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir - - - - This step has been reported to fail occasionally. If this - happens to you, then issue the command: - - &prompt.root; cd /usr/src && make cleandir && make cleandir - - and delete your /usr/obj tree: - - &prompt.root; rm -fr /usr/obj && mkdir /usr/obj - - This will clean out any cruft from your - source tree, and retrying the steps above should then work. - - - - - - Make a dev/null that - named can see and write to: - - &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 -&prompt.root; chmod 666 null - - - - Symlink /var/run/ndc to - /etc/namedb/var/run/ndc: - - &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc - - - This simply avoids having to specify the - option to &man.ndc.8; every time you - run it. Since the contents of /var/run are deleted on boot, - if this is something that you find useful you - may wish to add this command to root's crontab, making use - of the option. See - &man.crontab.5; for more information regarding - this. - - - - - - Configure &man.syslogd.8; to create an extra - log socket that - named can write to. To do this, - add -l /etc/namedb/dev/log to the - syslogd_flags variable in - /etc/rc.conf. - - - - Arrange to have named start - and chroot itself to the sandbox by - adding the following to - /etc/rc.conf: - - named_enable="YES" -named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" - - - Note that the configuration file - /etc/named.conf is denoted by a full - pathname relative to the sandbox, i.e. in - the line above, the file referred to is actually - /etc/namedb/etc/named.conf. - - - - - The next step is to edit - /etc/namedb/etc/named.conf so that - named knows which zones to load and - where to find them on the disk. There follows a commented - example (anything not specifically commented here is no - different from the setup for a DNS server not running in a - sandbox): - - options { - directory "/"; - named-xfer "/bin/named-xfer"; - version ""; // Don't reveal BIND version - query-source address * port 53; -}; -// ndc control socket -controls { - unix "/var/run/ndc" perm 0600 owner 0 group 0; -}; -// Zones follow: -zone "localhost" IN { - type master; - file "master/named.localhost"; - allow-transfer { localhost; }; - notify no; -}; -zone "0.0.127.in-addr.arpa" IN { - type master; - file "master/localhost.rev"; - allow-transfer { localhost; }; - notify no; -}; -zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { - type master; - file "master/localhost-v6.rev"; - allow-transfer { localhost; }; - notify no; -}; -zone "." IN { - type hint; - file "master/named.root"; -}; -zone "private.example.net" in { - type master; - file "master/private.example.net.db"; - allow-transfer { 192.168.10.0/24; }; -}; -zone "10.168.192.in-addr.arpa" in { - type slave; - masters { 192.168.10.2; }; - file "slave/192.168.10.db"; -}; - - - - The - directory statement is specified as - /, since all files that - named needs are within this - directory (recall that this is equivalent to a - normal user's - /etc/namedb. - - - - Specifies the full path - to the named-xfer binary (from - named's frame of reference). This - is necessary since named is - compiled to look for named-xfer in - /usr/libexec by default. - - Specifies the filename (relative - to the directory statement above) where - named can find the zonefile for this - zone. - - Specifies the filename - (relative to the directory statement above) - where named should write a copy of - the zonefile for this zone after successfully transferring it - from the master server. This is why we needed to change the - ownership of the directory slave to - bind in the setup stages above. - - - - After completing the steps above, either reboot your - server or restart &man.syslogd.8; and start &man.named.8;, making - sure to use the new options specified in - syslogd_flags and - named_flags. You should now be running a - sandboxed copy of named! - - - - - Security - - Although BIND is the most common implementation of DNS, - there is always the issue of security. Possible and - exploitable security holes are sometimes found. - - - - It is a good idea to subscribe to CERT and - freebsd-security-notifications - to stay up to date with the current Internet and FreeBSD security - issues. - - - If a problem arises, keeping sources up to date and having a - fresh build of named would not hurt. - - - - Further Reading - - BIND/named manual pages: &man.ndc.8; &man.named.8; &man.named.conf.5; - - - - - Official ISC Bind - Page - - - - - BIND FAQ - - - - O'Reilly - DNS and BIND 4th Edition - - - - RFC1034 - - Domain Names - Concepts and Facilities - - - - RFC1035 - - Domain Names - Implementation and Specification - - - - - - - - - - Tom - Hukins - Contributed by - - - - NTP - - NTP - - - Overview - - Over time, a computer's clock is prone to drift. As time - passes, the computer's clock becomes less accurate. NTP - (Network Time Protocol) is one way to ensure your clock is - right. - - Many Internet services rely on, or greatly benefit from, - computers' clocks being accurate. For example, a Web server - may receive requests to send a file if it has modified since a - certain time. Services such as &man.cron.8; run commands at a - given time. If the clock is inaccurate, these commands may - not run when expected. - - - NTP - ntpd - - FreeBSD ships with the &man.ntpd.8; NTP server which can - be used to query other NTP servers to set the clock on your - machine or provide time services to others. - - - - Choosing Appropriate NTP Servers - - - NTP - choosing servers - - - In order to synchronize your clock, you will need to find - one or more NTP servers to use. Your network administrator or - ISP may have setup an NTP server for this purpose—check - their documentation to see if this is the case. There is a - list of - publicly accessible NTP servers which you can use to - find an NTP server near to you. Make sure you are aware of - the policy for any servers you choose, and ask for permission - if required. - - Choosing several unconnected NTP servers is a good idea in - case one of the servers you are using becomes unreachable or - its clock is unreliable. &man.ntpd.8; uses the responses it - receives from other servers intelligently—it will favor - unreliable servers less than reliable ones. - - - - Configuring Your Machine - - - NTP - configuration - - - - Basic Configuration - ntpdate - - If you only wish to synchronize your clock when the - machine boots up, you can use &man.ntpdate.8;. This may be - appropriate for some desktop machines which are frequently - rebooted and only require infrequent synchronization, but - most machines should run &man.ntpd.8;. - - Using &man.ntpdate.8; at boot time is also a good idea - for machines that run &man.ntpd.8;. &man.ntpd.8; changes the - clock gradually, whereas &man.ntpdate.8; sets the clock, no - matter how great the difference between a machine's current - clock setting and the correct time. - - To enable &man.ntpdate.8; at boot time, add - ntpdate_enable="YES" to - /etc/rc.conf. You will also need to - specify all servers you wish to synchronize with and any - flags to be passed to &man.ntpdate.8; in - ntpdate_flags. - - - - - NTP - ntp.conf - - - General Configuration - - NTP is configured by the - /etc/ntp.conf file in the format - described in &man.ntp.conf.5;. Here is a simple - example: - - server ntplocal.example.com prefer -server timeserver.example.org -server ntp2a.example.net - -driftfile /var/db/ntp.drift - - The server option specifies which - servers are to be used, with one server listed on each line. - If a server is specified with the prefer - argument, as with ntplocal.example.com, that server is - preferred over other servers. A response from a preferred - server will be discarded if it differs significantly from - other servers' responses, otherwise it will be used without - any consideration to other responses. The - prefer argument is normally used for NTP - servers that are known to be highly accurate, such as those - with special time monitoring hardware. - - The driftfile option specifies which - file is used to store the system clock's frequency offset. - &man.ntpd.8; uses this to automatically compensate for the - clock's natural drift, allowing it to maintain a reasonably - correct setting even if it is cut off from all external time - sources for a period of time. - - The driftfile option specifies which - file is used to store information about previous responses - from the NTP servers you are using. This file contains - internal information for NTP. It should not be modified by - any other process. - - - - Controlling Access to Your Server - - By default, your NTP server will be accessible to all - hosts on the Internet. The restrict - option in &man.ntp.conf.5; allows you to control which - machines can access your server. - - If you want to deny all machines from accessing your NTP - server, add the following line to - /etc/ntp.conf - - restrict default ignore - - If you only want to - allow machines within your own network to synchronize their - clocks with your server, but ensure they are not allowed to - configure the server or used as peers to synchronize - against, add - - restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap - - instead, where 192.168.1.0 is - an IP address on your network and 255.255.255.0 is your network's - netmask. - - /etc/ntp.conf can contain multiple - restrict options. For more details, see - the Access Control Support subsection of - &man.ntp.conf.5;. - - - - - Running the NTP Server - - To ensure the NTP server is started at boot time, add the - line xntpd_enable="YES" to - /etc/rc.conf. If you wish to pass - additional flags to &man.ntpd.8; edit the - xntpd_flags parameter in - /etc/rc.conf. - - To start the server without rebooting your machine, run - ntpd being sure to specify any additional - parameters from xntpd_flags in - /etc/rc.conf. For example: - &prompt.root; ntpd -p /var/run/ntpd.pid - - - - Using &man.ntpd.8; with a Temporary Internet - Connection - - ntpd does not need a permanent - connection to the Internet to function properly. However, if - you have a temporary connection that is configured to dial out - on demand, it is a good idea to prevent NTP traffic from - triggering a dial out or keeping the connection alive. If you - are using user PPP, you can use filter - directives in /etc/ppp/ppp.conf. For - example: - - set filter dial 0 deny udp src eq 123 - # Prevent NTP traffic from initiating dial out - set filter dial 1 permit 0 0 - set filter alive 0 deny udp src eq 123 - # Prevent incoming NTP traffic from keeping the connection open - set filter alive 1 deny udp dst eq 123 - # Prevent outgoing NTP traffic from keeping the connection open - set filter alive 2 permit 0/0 0/0 - - For more details see the PACKET - FILTERING section in &man.ppp.8; and the examples in - /usr/share/examples/ppp/. - - - Some Internet access providers block low-numbered ports, - preventing NTP from functioning since replies never - reach your machine. - - - - - Further Information - - Documentation for the NTP server can be found in - /usr/share/doc/ntp/ in HTML - format. - - - - - - - - Chern - Lee - Contributed by - - - - Network Address Translation - - - Overview - - natd - - FreeBSD's Network Address Translation daemon, commonly known as - &man.natd.8; is a daemon that accepts incoming raw IP packets, - changes the source to the local machine and re-injects these packets - back into the outgoing IP packet stream. natd does this by changing - the source IP address and port such that when data is received back, - it is able to determine the original location of the data and forward - it back to its original requester. - Internet connection sharing - IP masquerading - The most common use of NAT is to perform what is commonly known as - Internet Connection Sharing. - - - - Setup - Due to the diminishing IP space in IPv4, and the increased number - of users on high-speed consumer lines such as cable or DSL, people are - increasingly in need of an Internet Connection Sharing solution. The - ability to connect several computers online through one connection and - IP address makes &man.natd.8; a reasonable choice. - - Most commonly, a user has a machine connected to a cable or DSL - line with one IP address and wishes to use this one connected computer to - provide Internet access to several more over a LAN. - - To do this, the FreeBSD machine on the Internet must act as a - gateway. This gateway machine must have two NICs--one for connecting - to the Internet router, the other connecting to a LAN. All the - machines on the LAN are connected through a hub or switch. - - - - - - - - _______ __________ ________ - | | | | | | - | Hub |-----| Client B |-----| Router |----- Internet - |_______| |__________| |________| - | - ____|_____ -| | -| Client A | -|__________| - - - - Network Layout - - - - A setup like this is commonly used to share an Internet - connection. One of the LAN machines is - connected to the Internet. The rest of the machines access - the Internet through that gateway - machine. - - - - - kernel - configuration - - Configuration - The following options must be in the kernel configuration - file: - options IPFIREWALL -options IPDIVERT - - Additionally, at choice, the following may also be suitable: - options IPFIREWALL_DEFAULT_TO_ACCEPT -options IPFIREWALL_VERBOSE - - The following must be in /etc/rc.conf: - - gateway_enable="YES" -firewall_enable="YES" -firewall_type="OPEN" -natd_enable="YES" -natd_interface="fxp0" -natd_flags="" - - - - - - gateway_enable="YES" - Sets up the machine to act as a gateway. Running - sysctl net.inet.ip.forwarding=1 - would have the same effect. - - firewall_enable="YES" - Enables the firewall rules in - /etc/rc.firewall at boot. - - firewall_type="OPEN" - This specifies a predefined firewall ruleset that - allows anything in. See - /etc/rc.firewall for additional - types. - - - natd_interface="fxp0" - Indicates which interface to forward packets through - (the interface connected to the Internet). - - - natd_flags="" - Any additional configuration options passed to - &man.natd.8; on boot. - - - - - - Having the previous options defined in - /etc/rc.conf would run - natd -interface fxp0 at boot. This can also - be run manually. - - Each machine and interface behind the LAN should be - assigned IP address numbers in the private network space as - defined by RFC 1918 - and have a default gateway of the natd machine's internal IP - address. - - For example, client a and - b behind the LAN have IP addresses of 192.168.0.2 and 192.168.0.3, while the natd machine's - LAN interface has an IP address of 192.168.0.1. Client a - and b's default gateway must be set to that - of the natd machine, 192.168.0.1. The natd machine's - external, or Internet interface does not require any special - modification for natd to work. - - - - Port Redirection - - The drawback with natd is that the LAN clients are not accessible - from the Internet. Clients on the LAN can make outgoing connections to - the world but cannot receive incoming ones. This presents a problem - if trying to run Internet services on one of the LAN client machines. - A simple way around this is to redirect selected Internet ports on the - natd machine to a LAN client. - - - For example, an IRC server runs on Client A, and a web server runs - on Client B. For this to work properly, connections received on ports - 6667 (IRC) and 80 (web) must be redirected to the respective machines. - - - The -redirect_port must be passed to - &man.natd.8; with the proper options. The syntax is as follows: - -redirect_port proto targetIP:targetPORT[-targetPORT] - [aliasIP:]aliasPORT[-aliasPORT] - [remoteIP[:remotePORT[-remotePORT]]] - - In the above example, the argument should be: - -redirect_port tcp 192.168.0.2:6667 6667 - -redirect_port tcp 192.168.0.3:80 80 - This will redirect the proper tcp ports to the - LAN client machines. - - - The -redirect_port argument can be used to indicate port - ranges over individual ports. For example, tcp - 192.168.0.2:2000-3000 2000-3000 would redirect - all connections received on ports 2000 to 3000 to ports 2000 - to 3000 on Client A. - - These options can be used when directly running - &man.natd.8; or placed within the - natd_flags="" option in - /etc/rc.conf. - - For further configuration options, consult &man.natd.8; - - - - Address Redirection - address redirection - Address redirection is useful if several IP addresses are - available, yet they must be on one machine. With this, - &man.natd.8; can assign each LAN client its own external IP address. - &man.natd.8; then rewrites outgoing packets from the LAN clients - with the proper external IP address and redirects - all traffic incoming on that particular IP address back to - the specific LAN client. This is also known as static NAT. - For example, the IP addresses 128.1.1.1, - 128.1.1.2, and - 128.1.1.3 belong to the natd gateway - machine. 128.1.1.1 can be used - as the natd gateway machine's external IP address, while - 128.1.1.2 and - 128.1.1.3 are forwarded back to LAN - clients A and B. - - The -redirect_address syntax is as follows: - - - - - - - - localIP - The internal IP address of the LAN client. - - - publicIP - The external IP address corresponding to the LAN client. - - - - - - In the example, this argument would read: - - - Like -redirect_port, these arguments are also placed within - natd_flags of /etc/rc.conf. With address - redirection, there is no need for port redirection since all data - received on a particular IP address is redirected. - - The external IP addresses on the natd machine must be active and aliased - to the external interface. Look at &man.rc.conf.5; to do so. - - - - - - - - - Chern - Lee - Contributed by - - - - - The <application>inetd</application> <quote>Super-Server</quote> - - - Overview - - &man.inetd.8; is referred to as the Internet - Super-Server because it manages connections for several - daemons. Programs that provide network service are commonly - known as daemons. inetd serves as a - managing server for other daemons. When a connection is - received by inetd, it determines - which daemon the connection is destined for, spawns the - particular daemon and delegates the socket to it. Running one - instance of inetd reduces the overall - system load as compared to running each daemon individually in - stand-alone mode. - - Primarily, inetd is used to - spawn other daemons, but several trivial protocols are handled - directly, such as chargen, - auth, and - daytime. - - This section will cover the basics in configuring - inetd through its command-line - options and its configuration file, - /etc/inetd.conf. - - - - Settings - - inetd is initialized through - the /etc/rc.conf system. The - inetd_enable option is set to - NO by default, but is often times turned on by - sysinstall with the medium security - profile. Placing: - inetd_enable="YES" or - inetd_enable="NO" into - /etc/rc.conf can enable or disable - inetd starting at boot time. - - Additionally, different command-line options can be passed - to inetd via the - inetd_flags option. - - - - Command-Line Options - - inetd synopsis: - - - - - - -d - - - Turn on debugging. - - - - - -l - - - Turn on logging of successful connections. - - - - - -w - - - Turn on TCP Wrapping for external services (on by - default). - - - - - -W - - - Turn on TCP Wrapping for internal services which are - built into inetd (on by - default). - - - - - -c maximum - - - Specify the default maximum number of simultaneous - invocations of each service; the default is unlimited. - May be overridden on a per-service basis with the - parameter. - - - - - -C rate - - - Specify the default maximum number of times a - service can be invoked from a single IP address in one - minute; the default is unlimited. May be overridden on a - per-service basis with the - - parameter. - - - - - -R rate - - - Specify the maximum number of times a service can be - invoked in one minute; the default is 256. A rate of 0 - allows an unlimited number of invocations. - - - - - -a - - - Specify one specific IP address to bind to. - Alternatively, a hostname can be specified, in which case - the IPv4 or IPv6 address which corresponds to that - hostname is used. Usually a hostname is specified when - inetd is run inside a - &man.jail.8;, in which case the hostname corresponds to - the &man.jail.8; environment. - - When hostname specification is used and both IPv4 - and IPv6 bindings are desired, one entry with the - appropriate protocol type for each binding is required for - each service in /etc/inetd.conf. For - example, a TCP-based service would need two entries, one - using tcp4 for the protocol and the other using - tcp6. - - - - - -p - - - Specify an alternate file in which to store the - process ID. - - - - - These options can be passed to - inetd using the - inetd_flags option in - /etc/rc.conf. By default, - inetd_flags is set to -wW, - which turns on TCP wrapping for - inetd's internal and external - services. For novice users, these parameters usually do not need - to be modified or even entered in - /etc/rc.conf. - - - An external service is a daemon outside of - inetd, which is invoked when a - connection is received for it. On the other hand, an internal - service is one that inetd has the - facility of offering within itself. - - - - - - <filename>inetd.conf</filename> - - Configuration of inetd is - controlled through the /etc/inetd.conf - file. - - When a modification is made to - /etc/inetd.conf, - inetd can be forced to re-read its - configuration file by sending a HangUP signal to the - inetd process as shown: - - - Sending <application>inetd</application> a HangUP Signal - - &prompt.root; kill -HUP `cat /var/run/inetd.pid` - - - Each line of the configuration file specifies an - individual daemon. Comments in the file are preceded by a - #. The format of - /etc/inetd.conf is as follows: - - service-name -socket-type -protocol -{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] -user[:group][/login-class] -server-program -server-program-arguments - - An example entry for the ftpd daemon - using IPv4: - - ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l - - - - service-name - - - This is the service name of the particular daemon. - It must correspond to a service listed in - /etc/services. This determines which - port inetd must listen to. If - a new service is being created, it must be placed in - /etc/services - first. - - - - - socket-type - - - Either stream, - dgram, raw, or - seqpacket. stream - must be used for connection-based, TCP daemons, while - dgram is used for daemons utilizing the - UDP transport protocol. - - - - - protocol - - - One of the following: - - - - - - Protocol - Explanation - - - - - tcp, tcp4 - TCP IPv4 - - - udp, udp4 - UDP IPv4 - - - tcp6 - TCP IPv6 - - - udp6 - UDP IPv6 - - - tcp46 - Both TCP IPv4 and v6 - - - udp46 - Both UDP IPv4 and v6 - - - - - - - - - {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] - - - indicates whether the - daemon invoked from inetd is - able to handle its own socket or not. - socket types must use the wait - option, while stream socket daemons, which are usually - multi-threaded, should use . - usually hands off multiple sockets - to a single daemon, while spawns a - child daemon for each new socket. - - The maximum number of child daemons - inetd may spawn can be set using - the option. If a limit of ten - instances of a particular daemon is needed, a - /10 would be placed after - . - - In addition to , another - option limiting the maximum connections from a single - place to a particular daemon can be enabled. - does - just this. A value of ten here would limit any particular - IP address connecting to a particular service to ten - attempts per minute. This is useful to prevent - intentional or unintentional resource consumption and - Denial of Service (DoS) attacks to a machine. - - In this field, or - is mandatory. - and - are - optional. - - A stream-type multi-threaded daemon without any - or - limits - would simply be: nowait - - The same daemon with a maximum limit of ten daemons - would read: nowait/10 - - Additionally, the same setup with a limit of twenty - connections per IP address per minute and a maximum - total limit of ten child daemons would read: - nowait/10/20 - - These options are all utilized by the default - settings of the fingerd daemon, - as seen here: - - finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s - - - - - user - - - The user is the username that the particular daemon - should run as. Most commonly, daemons run as the - root user. For security purposes, it is - common to find some servers running as the - daemon user, or the least privileged - nobody user. - - - - - server-program - - - The full path of the daemon to be executed when a - connection is received. If the daemon is a service - provided by inetd internally, - then should be - used. - - - - - server-program-arguments - - - This works in conjunction with - by specifying the - arguments, starting with argv[0], passed to the daemon on - invocation. If mydaemon -d is - the command line, mydaemon -d would be - the value of . - Again, if the daemon is an internal service, use - here. - - - - - - - Security - - Depending on the security profile chosen at install, many - of inetd's daemons may be enabled by - default. If there is no apparent need for a particular daemon, - disable it! Place a # in front of the daemon in - question, and send a hangup signal - to inetd. - Some daemons, such as fingerd, may - not be desired at all because they provide an attacker with too - much information. - - Some daemons are not security-conscious and have long, or - non-existent timeouts for connection attempts. This allows an - attacker to slowly send connections to a particular daemon, thus - saturating available resources. It may be a good idea to place - and - limitations on certain daemons. - - By default, TCP wrapping is turned on. Consult the - &man.hosts.access.5; manual page for more information on placing - TCP restrictions on various inetd - invoked daemons. - - - - Miscellaneous - - daytime, - time, - echo, - discard, - chargen, and - auth are all internally provided - services of inetd. - - The auth service provides identity - (ident, identd) network services, and is configurable to a certain - degree. - - Consult the &man.inetd.8; manual page for more in-depth - information. - - - - - Parallel Line IP (PLIP) - - PLIP - Parallel Line IP - - PLIP lets us run TCP/IP between parallel ports. It is - useful on machines without network cards, or to install on - laptops. In this section, we will discuss: - - - - Creating a parallel (laplink) cable. - - - - Connecting two computers with PLIP. - - - - - Creating a Parallel Cable - - You can purchase a parallel cable at most computer supply - stores. If you cannot do that, or you just want to know how - it is done, the following table shows how to make one out of a normal parallel - printer cable. - - - Wiring a Parallel Cable for Networking - - - - - A-name - - A-End - - B-End - - Descr. - - Post/Bit - - - - - - DATA0 --ERROR - - 2 -15 - - 15 -2 - - Data - - 0/0x01 -1/0x08 - - - - DATA1 -+SLCT - - 3 -13 - - 13 -3 - - Data - - 0/0x02 -1/0x10 - - - - DATA2 -+PE - - 4 -12 - - 12 -4 - - Data - - 0/0x04 -1/0x20 - - - - DATA3 --ACK - - 5 -10 - - 10 -5 - - Strobe - - 0/0x08 -1/0x40 - - - - DATA4 -BUSY - - 6 -11 - - 11 -6 - - Data - - 0/0x10 -1/0x80 - - - - GND - - 18-25 - - 18-25 - - GND - - - - - - -
- - - - Setting Up PLIP - - Get a laplink cable. - - Confirm that both computers have a kernel with &man.lpt.4; driver - support. - - &prompt.root; grep lp /var/run/dmesg.boot -lpt0 at 0x378-0x37f irq 7 on isa -lpt0: Interrupt-driven -lp0: TCP/IP capable interface - - Plug in the laplink cable into the parallel interface on - both computers. - - Configure the network interface parameters for lp0 on both - sites as root. For example, if you want connect - the host host1 with host2: - - host1 <-----> host2 -IP Address 10.0.0.1 10.0.0.2 - - Configure the interface on host1 by doing: - - &prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2 - - Configure the interface on host2 by doing: - - &prompt.root; ifconfig lp0 10.0.0.2 10.0.0.1 - - - You now should have a working connection. Please read the - manual pages &man.lp.4; and &man.lpt.4; for more details. - - You should also add both hosts to - /etc/hosts: - - 127.0.0.1 localhost.my.domain localhost -10.0.0.1 host1.my.domain host1 -10.0.0.2 host2.my.domain - - To confirm the connection works, go to each host and ping - the other. For example, on host1: - - &prompt.root; ifconfig lp0 -lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 -&prompt.root; netstat -r -Routing tables - -Internet: -Destination Gateway Flags Refs Use Netif Expire -host2 host1 UH 4 127592 lp0 -&prompt.root; ping -c 4 host2 -PING host2 (10.0.0.2): 56 data bytes -64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms -64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms -64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms -64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms - ---- host2 ping statistics --- -4 packets transmitted, 4 packets received, 0% packet loss -round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms - - - - - - - - - Aaron - Kaplan - Originally Written by - - - - - Tom - Rhodes - Restructured and Added by - - - - - IPv6 - IPv6 (also know as IPng IP next generation) is - the new version of the well known IP protocol (also know as - IPv4). Like the other current *BSD systems, - FreeBSD includes the KAME IPv6 reference implementation. - So your FreeBSD system comes with all you will need to experiment with IPv6. - This section focuses on getting IPv6 configured and running. - - In the early 1990s, people became aware of the rapidly - diminishing address space of IPv4. Given the expansion rate of the - Internet there were two major concerns: - - - - Running out of addresses. Today this is not so much of a concern - anymore since private address spaces - (10.0.0.0/8, - 192.168.0.0/24, - etc.) and Network Address Translation (NAT) are - being employed. - - - - Router table entries were getting too large. This is - still a concern today. - - - - IPv6 deals with these and many other issues: - - - - 128 bit address space. In other words theoretically there are - 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses - available. This means there are approximately - 6.67 * 10^27 IPv6 addresses per square meter on our planet. - - - - Routers will only store network aggregation addresses in their routing - tables thus reducing the average space of a routing table to 8192 - entries. - - - - There are also lots of other useful features of IPv6 such as: - - - - Address autoconfiguration (RFC2462) - - - - Anycast addresses (one-out-of many) - - - - Mandatory multicast addresses - - - - IPsec (IP security) - - - - Simplified header structure - - - - Mobile IP - - - - IPv4-to-IPv6 transition mechanisms - - - - - For more information see: - - - - IPv6 overview at Sun.com - - - - IPv6.org - - - - KAME.net - - - - 6bone.net - - - - - Background on IPv6 Addresses - There are different types of IPv6 addresses: Unicast, Anycast and - Multicast. - - Unicast addresses are the well known addresses. A packet sent - to a unicast address arrives exactly at the interface belonging to - the address. - - Anycast addresses are syntactically indistinguishable from unicast - addresses but they address a group of interfaces. The packet destined for - an anycast address will arrive at the nearest (in router metric) - interface. Anycast addresses may only be used by routers. - - Multicast addresses identify a group of interfaces. A packet destined - for a multicast address will arrive at all interfaces belonging to the - multicast group. - - The IPv4 broadcast address (usually xxx.xxx.xxx.255) is expressed - by multicast addresses in IPv6. - - Reserved IPv6 addresses: - -ipv6-address prefixlength(Bits) description Notes - - :: 128 Bits unspecified cf. 0.0.0.0 in IPv4 address - ::1 128 Bits loopback address cf. 127.0.0.1 in IPv4 - ::00:xx:xx:xx:xx 96 Bits embedded IPv4 The lower 32 bits are the - address IPv4 address. Also called - IPv4 compatible IPv6 - address - ::ff:xx:xx:xx:xx 96 Bits IPv4 mapped The lower 32 bits are the - IPv6 address IPv4 address. For hosts - which do not support IPv6 - fe80:: - feb:: 10 Bits link-local cf. loopback address in - IPv4 - fec0:: - fef:: 10 Bits site-local - ff:: 8 Bits multicast - 001 (base 2) 3 Bits global unicast All global unicast - addresses are assigned from - this pool. The first 3 Bits - are 001. - - - - - Reading IPv6 Addresses - The canonical form is represented as: x:x:x:x:x:x:x:x, each - x being a 16 Bit hex value. For example - FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 - - Often an address will have long substrings of all zeros - therefore each such substring can be abbreviated by ::. - For example fe80::1 - corresponds to the canonical form - fe80:0000:0000:0000:0000:0000:0000:0001 - - A third form is to write the last 32 Bit part in the - well known (decimal) IPv4 style with dots . - as separators. For example - 2002::10.0.0.1 - corresponds to the (hexadecimal) canonical representation - 2002:0000:0000:0000:0000:0000:0a00:0001 - which in turn is equivalent to - writing 2002::a00:1 - - By now the reader should be able to understand the following: - - &prompt.root; ifconfig - - rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 - inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 - inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 - ether 00:00:21:03:08:e1 - media: Ethernet autoselect (100baseTX ) - status: active - - fe80::200:21ff:fe03:8e1%rl0 - is an auto configured link-local address. It includes the - scrambled Ethernet MAC as part of the auto configuration. - - For further information on the structure of IPv6 addresses - see RFC2373. - - - - Getting Connected - - Currently there are four ways to connect to other IPv6 hosts and networks: - - - - Join the experimental 6bone - - - - Getting an IPv6 network from your upstream provider. Talk to your - Internet provider for instructions. - - - - Tunnel via 6-to-4 - - - - Use the freenet6 port if you are on a dial-up connection. - - - - Here we will talk on how to connect to the 6bone since it currently seems - to be the most popular way. - - First take a look at the 6bone site and find a 6bone connection nearest to - you. Write to the responsible person and with a little bit of luck you - will be given instructions on how to set up your connection. Usually this - involves setting up a GRE (gif) tunnel. - - Here is a typical example on setting up a &man.gif.4; tunnel: - - &prompt.root; ifconfig gif0 create -&prompt.root; ifconfig gif0 -gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 -&prompt.root; ifconfig gif0 tunnel MY_IPv4_ADDR HIS_IPv4_ADDR -&prompt.root; ifconfig gif0 inet6 alias MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR - - Replace the capitalized words by the information you received from the - upstream 6bone node. - - This establishes the tunnel. Check if the tunnel is working by &man.ping6.8; - 'ing ff02::1%gif0. You should receive two ping replies. - - In case you are intrigued by the address ff02:1%gif0, this is a - multicast address. %gif0 states that the multicast address at network - interface gif0 is to be used. Since we ping a multicast address the - other endpoint of the tunnel should reply as well). - - By now setting up a route to your 6bone uplink should be rather - straightforward: - - &prompt.root; route add -inet6 default -interface gif0 -&prompt.root; ping6 -n MY_UPLINK - - &prompt.root; traceroute6 www.jp.FreeBSD.org -(3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets - 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms - 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * - 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms - 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms - 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms - 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms - - This output will differ from machine to machine. By now you should be - able to reach the IPv6 site www.kame.net - and see the dancing tortoise - that is if you have a IPv6 enabled browser such as - mozilla. - - - - - DNS in the IPv6 World - There are two new types of DNS records for IPv6: - - - - AAAA records, - - - - A6 records - - - - Using AAAA records is straightforward. Assign your hostname to the new - IPv6 address you just got by adding: - - MYHOSTNAME AAAA MYIPv6ADDR - - To your primary zone DNS file. In case you do not serve your own - DNS zones ask your DNS provider. - Current versions of bind (version 8.3 and 9) - support AAAA records. - - - - - - >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Fri Aug 22 19:08:43 2003 Return-Path: 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 5985716A4BF for ; Fri, 22 Aug 2003 19:08:43 -0700 (PDT) Received: from smtp.netcabo.pt (smtp.netcabo.pt [212.113.174.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 589FE43FE3 for ; Fri, 22 Aug 2003 19:08:42 -0700 (PDT) (envelope-from sub_0@netcabo.pt) Received: from [192.168.1.2] ([213.22.54.110]) by smtp.netcabo.pt with Microsoft SMTPSVC(5.0.2195.5329); Sat, 23 Aug 2003 03:07:13 +0100 From: =?ISO-8859-1?Q?M=E1rio?= Freitas To: freebsd-doc@freebsd.org Content-Type: text/plain; charset=iso-8859-15 Message-Id: <1061601117.42555.0.camel@suzy.unbreakable.homeunix.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 23 Aug 2003 03:08:53 +0100 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 23 Aug 2003 02:07:13.0576 (UTC) FILETIME=[44CC0280:01C3691B] Subject: Porter's Handbook Mistake? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: sub_0@netcabo.pt List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 02:08:43 -0000 I folks, While I was reading the porter's handbook (once more) I think I've found a mistake at Chapter 12, part 3: "This script will be run twice by pkg_delete(1). The first time as ${SH} pkg-install ${PKGNAME} DEINSTALL and the second time as ${SH} pkg-install ${PKGNAME} POST-DEINSTALL." Shouldn't it be: "This script will be run twice by pkg_delete(1). The first time as ${SH} pkg-deinstall ${PKGNAME} PRE-DEINSTALL and the second time as ${SH} pkg-deinstall ${PKGNAME} POST-DEINSTALL." ? Thanks. --=20 M=E1rio Freitas (sub_0@netcabo.pt) N=FAcleo Portugu=EAs de FreeBSD (NPF) From owner-freebsd-doc@FreeBSD.ORG Sat Aug 23 02:50:07 2003 Return-Path: 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 B388216A4BF for ; Sat, 23 Aug 2003 02:50:07 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A44A43FE5 for ; Sat, 23 Aug 2003 02:50:07 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7N9o7Up070581 for ; Sat, 23 Aug 2003 02:50:07 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7N9o7jo070580; Sat, 23 Aug 2003 02:50:07 -0700 (PDT) Date: Sat, 23 Aug 2003 02:50:07 -0700 (PDT) Message-Id: <200308230950.h7N9o7jo070580@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Christian Brueffer Subject: Re: docs/55883: advanced-networking/chapter.sgml X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Christian Brueffer List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 09:50:07 -0000 The following reply was made to PR docs/55883; it has been noted by GNATS. From: Christian Brueffer To: Gea-Suan Lin Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: docs/55883: advanced-networking/chapter.sgml Date: Sat, 23 Aug 2003 09:31:40 +0200 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 23, 2003 at 07:03:00AM +0800, Gea-Suan Lin wrote: >=20 > =09 > >Description: > IPFIREWALL_DEFAULT_TO_ACCEPT is not undocumented now. > >How-To-Repeat: > =09 Uhm, was this really the patch you intended to attach? Looks a bit radical to me :-) - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/RxhbbHYXjKDtmC0RAm9YAJwO008ABMumbLAvFmYHQMbwGgca8wCgsreH WC4GqInK4d+b5385aGGtq30= =7QU8 -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-doc@FreeBSD.ORG Sat Aug 23 03:10:56 2003 Return-Path: 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 9451416A4BF for ; Sat, 23 Aug 2003 03:10:56 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7A4343FBF for ; Sat, 23 Aug 2003 03:10:53 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id B9C7510BFA8; Sat, 23 Aug 2003 12:10:51 +0200 (CEST) Date: Sat, 23 Aug 2003 12:10:51 +0200 From: "Simon L. Nielsen" To: =?iso-8859-1?Q?M=E1rio?= Freitas Message-ID: <20030823101050.GA391@FreeBSD.org> References: <1061601117.42555.0.camel@suzy.unbreakable.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <1061601117.42555.0.camel@suzy.unbreakable.homeunix.org> User-Agent: Mutt/1.5.4i cc: freebsd-doc@freebsd.org Subject: Re: Porter's Handbook Mistake? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 10:10:56 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.08.23 03:08:53 +0100, M=E1rio Freitas wrote: > I folks, > While I was reading the porter's handbook (once more) I think > I've found a mistake at Chapter 12, part 3: >=20 > "This script will be run twice by pkg_delete(1). The first time as ${SH} > pkg-install ${PKGNAME} DEINSTALL and the second time as ${SH} > pkg-install ${PKGNAME} POST-DEINSTALL." >=20 >=20 > Shouldn't it be: > "This script will be run twice by pkg_delete(1). The first time as ${SH} > pkg-deinstall ${PKGNAME} PRE-DEINSTALL and the second time as ${SH} > pkg-deinstall ${PKGNAME} POST-DEINSTALL." ? I don't think so.. From pkg_delete(1): =2E.. distribution. The deinstall script is called as: script DEINSTALL where pkg-name is the name of the package in question and DEINSTALL is= a keyword denoting this as the pre-deinstallation phase. =2E.. The post-deinstall script is called as: script POST-DEINSTALL where pkg-name is the name of the package in question and POST-DEINSTA= LL is a keyword denoting this as the post-deinstallation phase. and a quick check of the pkg_delete source code seems to confirm this. --=20 Simon L. Nielsen FreeBSD Documentation Team --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/Rz2qh9pcDSc1mlERAu79AJ9xyjP2UcybDjBUaGqbin/BXrJ9BQCgzCXq 5LsS7+NLapgt5ZYg7u/CzOU= =HkO3 -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-doc@FreeBSD.ORG Sat Aug 23 04:31:39 2003 Return-Path: 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 7A1FE16A4BF for ; Sat, 23 Aug 2003 04:31:39 -0700 (PDT) Received: from wonkity.com (wonkity.com [65.173.111.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5F3843F75 for ; Sat, 23 Aug 2003 04:31:38 -0700 (PDT) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.12.9/8.12.9) with ESMTP id h7NBVbrg017779 for ; Sat, 23 Aug 2003 05:31:37 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.12.9/8.12.9/Submit) with ESMTP id h7NBVYqJ017776; Sat, 23 Aug 2003 05:31:37 -0600 (MDT) Date: Sat, 23 Aug 2003 05:31:34 -0600 (MDT) From: Warren Block To: Gea-Suan Lin In-Reply-To: <20030822230300.0528C43@netnews.NCTU.edu.tw> Message-ID: <20030823051222.T17743@wonkity.com> References: <20030822230300.0528C43@netnews.NCTU.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-doc@freebsd.org Subject: Re: docs/55883: advanced-networking/chapter.sgml X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 11:31:39 -0000 Besides the severity of the patch Christian mentioned, there are several places like this: > - > - How to setup a network filesystem. > - "Setup" (one word) is a noun. For the verb, it should be two words. Looking at it again, I see some other things I would like to edit. For example, this paragraph: This chapter will cover some of the more frequently used network services on Unix systems. We will cover how to define, setup, test and maintain all of the network services that FreeBSD utilizes. In addition, there have been example configuration files included throughout this chapter for you to benefit from. would become: In this chapter, we will cover how to define, set up, test, and maintain the network services utilized by FreeBSD. For that matter, other than an introduction, does this paragraph serve any real need at all? -Warren Block * Rapid City, South Dakota USA From owner-freebsd-doc@FreeBSD.ORG Sat Aug 23 07:08:07 2003 Return-Path: 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 A678416A4BF; Sat, 23 Aug 2003 07:08:07 -0700 (PDT) Received: from smtp.netcabo.pt (smtp.netcabo.pt [212.113.174.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9462D43FDF; Sat, 23 Aug 2003 07:08:06 -0700 (PDT) (envelope-from sub_0@netcabo.pt) Received: from [192.168.1.2] ([213.22.54.110]) by smtp.netcabo.pt with Microsoft SMTPSVC(5.0.2195.5329); Sat, 23 Aug 2003 15:07:18 +0100 From: Mario Freitas To: "Simon L. Nielsen" In-Reply-To: <20030823101050.GA391@FreeBSD.org> References: <1061601117.42555.0.camel@suzy.unbreakable.homeunix.org> <20030823101050.GA391@FreeBSD.org> Content-Type: text/plain; charset=iso-8859-15 Message-Id: <1061647704.7607.20.camel@suzy.unbreakable.homeunix.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 23 Aug 2003 15:08:24 +0100 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 23 Aug 2003 14:07:18.0218 (UTC) FILETIME=[DCC532A0:01C3697F] cc: freebsd-doc@freebsd.org Subject: Re: Porter's Handbook Mistake? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: sub_0@netcabo.pt List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 14:08:07 -0000 On Sat, 2003-08-23 at 11:10, Simon L. Nielsen wrote: > On 2003.08.23 03:08:53 +0100, M=E1rio Freitas wrote: > > I folks, > > While I was reading the porter's handbook (once more) I think > > I've found a mistake at Chapter 12, part 3: > >=20 > > "This script will be run twice by pkg_delete(1). The first time as ${SH= } > > pkg-install ${PKGNAME} DEINSTALL and the second time as ${SH} > > pkg-install ${PKGNAME} POST-DEINSTALL." > >=20 > >=20 > > Shouldn't it be: > > "This script will be run twice by pkg_delete(1). The first time as ${SH= } > > pkg-deinstall ${PKGNAME} PRE-DEINSTALL and the second time as ${SH} > > pkg-deinstall ${PKGNAME} POST-DEINSTALL." ? >=20 > I don't think so.. From pkg_delete(1): >=20 > ... > distribution. The deinstall script is called as: > script DEINSTALL > where pkg-name is the name of the package in question and DEINSTALL = is a > keyword denoting this as the pre-deinstallation phase. > ... > The post-deinstall script is called as: > script POST-DEINSTALL > where pkg-name is the name of the package in question and POST-DEINS= TALL > is a keyword denoting this as the post-deinstallation phase. >=20 > and a quick check of the pkg_delete source code seems to confirm this. Yes you're right, wouldn't be better , "pkg-deinstall" (PRE-DEINSTALL and POST-DEINSTALL) just for a better standardization? Or is there any better reason, behind all this, not to do "pkg-deinstall"(including both "targets") the default script filename? Thanks in advance. --=20 M=E1rio Freitas (sub_0@netcabo.pt) N=FAcleo Portugu=EAs de FreeBSD (NPF) From owner-freebsd-doc@FreeBSD.ORG Sat Aug 23 07:12:13 2003 Return-Path: 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 E075816A4BF; Sat, 23 Aug 2003 07:12:13 -0700 (PDT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2072943FA3; Sat, 23 Aug 2003 07:12:13 -0700 (PDT) (envelope-from trhodes@FreeBSD.org) Received: from localhost (bay3-143.fyi.net [206.80.153.143]) by pittgoth.com (8.12.9/8.12.9) with SMTP id h7NECAvd053354; Sat, 23 Aug 2003 10:12:10 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Sat, 23 Aug 2003 09:48:17 -0400 From: Tom Rhodes To: owner-freebsd-doc@FreeBSD.org Message-Id: <20030823094817.76e3b847.trhodes@FreeBSD.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-doc@FreeBSD.org Subject: Your message to freebsd-doc awaits moderator approval X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 14:12:14 -0000 We can't send plain text emails anymore?? This was nothing more than a plain text patch, I'm at a loss to why this happened!! For those interested in reviewing this patch can get it at: http://people.FreeBSD.org/~trhodes/security.diff For those reviewing, please read the following email which was my original body: Greetings, Here I bring the kerberos5 handbook section to everyone for review. A few tidbits of pre-review information: This was done under the theory that KerberosIV is gone from 5.1 and post releases. Thus there is a history part, and some extra information; this was done so that we can fade away the other chapter with ease. If it is desired for some unknown reason, I would like to commit the entire part and then in a seperate commit: remove the history/introduction. This method would allow myself, or another doc hacker to restore that information when the old version is dissolved. I will kill my whitespace lines before the commit, these are here for 'markers' so that I would not get lost during my initial copy-paste merge. Please ignore them. This was submitted to me in plain text, thus I did 95% of the mark up. All mistakes are mine and should be pointed out to me. I plan to commit this on Monday, or even Sunday night EST if I get enough review. Thanks! -- Tom Rhodes On Sat, 23 Aug 2003 06:52:59 -0700 owner-freebsd-doc@freebsd.org wrote: > Your mail to 'freebsd-doc' with the subject > > [Review Request: Kerberos5] handbook security chapter review > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > SpamAssassin identified this message as possible spam > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > http://lists.freebsd.org/mailman/confirm/freebsd-doc/6147ca7d842b290eeb1e9b51fbc6e04b69bb64c2 > -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Sat Aug 23 06:52:26 2003 Return-Path: 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 A4ECD16A4BF for ; Sat, 23 Aug 2003 06:52:26 -0700 (PDT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01BE343FEA for ; Sat, 23 Aug 2003 06:52:24 -0700 (PDT) (envelope-from trhodes@FreeBSD.org) Received: from localhost (bay3-143.fyi.net [206.80.153.143]) by pittgoth.com (8.12.9/8.12.9) with SMTP id h7NDpvvd053310 for ; Sat, 23 Aug 2003 09:52:06 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Sat, 23 Aug 2003 09:27:54 -0400 From: Tom Rhodes To: FreeBSD-doc@FreeBSD.org Message-Id: <20030823092754.1e3dc84c.trhodes@FreeBSD.org> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 23 Aug 2003 07:46:05 -0700 Subject: [Review Request: Kerberos5] handbook security chapter review X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 13:52:26 -0000 Greetings, Here I bring the kerberos5 handbook section to everyone for review. A few tidbits of pre-review information: This was done under the theory that KerberosIV is gone from 5.1 and post releases. Thus there is a history part, and some extra information; this was done so that we can fade away the other chapter with ease. If it is desired for some unknown reason, I would like to commit the entire part and then in a seperate commit: remove the history/introduction. This method would allow myself, or another doc hacker to restore that information when the old version is dissolved. I will kill my whitespace lines before the commit, these are here for 'markers' so that I would not get lost during my initial copy-paste merge. Please ignore them. This was submitted to me in plain text, thus I did 95% of the mark up. All mistakes are mine and should be pointed out to me. I plan to commit this on Monday, or even Sunday night EST if I get enough review. Thanks! -- Tom Rhodes --- chapter.old Sat Aug 23 08:11:30 2003 +++ chapter.sgml Sat Aug 23 09:21:11 2003 @@ -106,7 +106,7 @@ servers – meaning that external entities can connect and talk to them. As yesterday's mini-computers and mainframes become today's desktops, and as computers become networked and - internetworked, security becomes an even bigger issue. + inter-networked, security becomes an even bigger issue. Security is best implemented through a layered onion approach. In a nutshell, what you want to do is @@ -1919,6 +1919,740 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 + + + + + + + + + + Tillman + Hodgson + Contributed by + + + + + Mark + Murray + Based on a contribution by + + + + + <application>Kerberos5</application> + + Every &os; release beyond &os;-5.1 includes support + only for Kerberos5. Hence + Kerberos5 is the only version + included, and its configuration is similar in many aspects + to that of KerberosIV. The following + information should only apply to + Kerberos5 in post &os;-5.0 + releases. + + Kerberos is a network add-on + system/protocol that allows users to authenticate themselves + through the services of a secure server. Services such as remote + login, remote copy, secure inter-system file copying and other + high-risk tasks are made considerably safer and more + controllable. + + Kerberos can be described as an + identity-verifying proxy system. It can also be described as a + trusted third-party authentication system. + + Note that Kerberos provides only + authentication services and nothing more. Therefore it is highly + recommended that Kerberos be used with + other security methods which authorization and audit services. + + The following instructions can be used as a guide on how to set + up Kerberos as distributed for &os;. + However, you should refer to the relevant manual pages for a complete + description. + + For purposes of demonstrating a Kerberos + installation, the various namespaceswill be handled as follows: + + + + The DNS domain (zone) will be example.prv. + + + + The Kerberos realm will be + EXAMPLE.PRV. + + + + Please refrain from the use of these namespaces in the real + world. Not only will it not be optimal for your network and + DNS server, it will make interoperating with other + Kerberos realms more difficult. + + + Background: History + + Kerberos was created by + MIT as a solution to network security problems. + The Kerberos protocol uses strong + cryptography so that a client can prove its identity to a server + (and vice versa) across an insecure network connection. + + Kerberos provides only one + function -- the secure authentication of users on the network. It + does not provide authorization functions (what those users are + able to perform) or auditing fuctions (what those users did). + After a client and server have used + Kerberos to prove their identity, they + can also encrypt all of their communications to assure privacy + and data integrity as they go about their business. + + Kerberos is both the name of a + network authentication protocol and an adjective to describe + programs that implement the program + (Kerberos telnet, for example). The + current version of the protocol is version 5, described in + RFC 1510. Kerberos + was designed to provide strong authentication for client/server + applications (such as traditional Internet services like + FTP and telnet) by using secret-key + cryptography. + + Several free implementations of this protocol are available, + covering a wide range of operating systems. The Massachusetts + Institute of Technology, where Kerberos + was originally developed, continues to develop their + Kerberos package and it is commonly used + in the US (as a cryptography product, it has + historically been affected by US export + regulations). The MIT + Kerberos is available as a port + (security/krb5). Heimdal + Kerberos is another version 5 + implementation, and was explicitly developed outside of the + US to avoid export + regulations (and is thus often included in non-commercial Unix + variants). The Heimdal Kerberos + distribution is available as a port + (security/heimdal), and a + minimal installation of it is included in the base &os; + install. + + In order to reach the widest audience, these instructions assume + the use of the Heimdal distribution included in &os;. + + + + + Background: <application>KerberosIV</application> and + <application>Kerberos</application> 5 + + Older versions of Kerberos included both + KerberosIV (eBones) and + Kerberos 5 (Heimdal). Support for + KerberosIV has been dropped as of &os; + 5.0. + + + + + Setting up a Heimdal <acronym>KDC</acronym> + + The KDC, or Key Distribution Center, is the + centralized authentication service that + Kerberos provides -- it is the computer + that issues Kerberos tickets. The + KDC is considered trusted by all + other computers in the Kerberos realm, and thus + has heightened security concerns. + + Note that while running the Kerberos + server requires very few computing resources, a dedicated machine + acting only as a KDC is recommended for security + reasons. + + To begin setting up a KDC, ensure that your + /etc/rc.conf file contains the correct + settings to act as a KDC (you may need to adjust + paths to reflect your own system): + + Kerberos5_server_enable="YES" +kadmind5_server_enable="YES" +Kerberos_stash="YES" + + Next we'll set up your Kerberos + config file, /etc/krb5.conf: + + [libdefaults] + default_realm = EXAMPLE.PRV +[realms] + EXAMPLE.PRV = { + kdc = Kerberos.example.prv + } +[domain_realm] + .example.prv = EXAMPLE.PRV + + Note that this /etc/krb5.conf file implies + that your KDC will have the fully-qualified + hostname of Kerberos.example.prv. You will need + to add a CNAME (alias) entry to your zone file to accomplish this + if your KDC has a different hostname. + + Next we will create the Kerberos + database. The keys of all the principals are stored in this + database in encrypted form with a master password. You are not + required to remember this password, it will be stored in a file + (/var/heimdal/m-key). To create the master + key, run kstash and enter a password. + + Once the master key has been created, you can initialize the + database using the kadmin program with the + -l option (standing for local). + This option instructs kadmin to modify the + database files directly rather than going through the + kadmind network service. This handles the + chicken-and-egg problem of trying to connect to the database + before it is created. Once you have the kadmin> + prompt, use the init command to create your + realms initial database. + + Lastly, while still in kadmin, create your + first principal using the add command. Stick + to the defaults options for the principal for now, you can always + change them later with the modify command. + Note that you can use the ? command at any + prompt to see the available options are. + + A sample database creation session is shown below: + + &prompt.root;kstash +Master key: xxxxxxxx +Verifying password - Master key: xxxxxxxx + +&prompt.root;kadmin -l +kadmin> init EXAMPLE.PRV +Realm max ticket life [unlimited]: +kadmin> add tillman +Max ticket life [unlimited]: +Max renewable life [unlimited]: +Attributes []: +Password: xxxxxxxx +Verifying password - Password: xxxxxxxx + + Now it's time to start up the KDC services. + Run /etc/rc.d/Kerberos start and + /etc/rc.d/kadmind start to bring up the + services. Note that you won't have any Kerberized daemons running + at this point but you should be able to confirm the that the + KDC is functioning by obtaining and listing a + ticket for the principal (user) that you just created from the + command-line of the KDC itself: + + &prompt.user;k5init tillman +tillman@EXAMPLE.PRV's Password: + +&prompt.user;k5list +Credentials cache: FILE:/tmp/krb5cc_500 + Principal: tillman@EXAMPLE.PRV + + Issued Expires Principal +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV@EXAMPLE.PRV +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV@EXAMPLE.PRV + +v4-ticket file: /tmp/tkt500 +k5list: No ticket file (tf_util) + + + + + <application>Kerberos</application> enabling a server with + Heimdal services + + First, we need a copy of the Kerberos + configuration file, /etc/krb5.conf. To do + so, simply copy it over to the client computer from the + KDC in a secure fashion (using the network, + such as scp, or physically via a + floppy). + + Next you need a /etc/krb5.keytab file. + This is the major difference between a server provide + Kerberos enabled daemons and a + workstation -- the server must have a keytab file. This file + contains the servers host key, which allows it and the + KDC to verify each others identity. It + must be transmitted to the server in a secure fashion, as the + security of the server can be broken if the key is made public. + This explicitly means that transferring it via a clear text + channel, such as FTP, is a very bad idea. + + Typically, you transfer to the keytab to the server using the + kadmin program. This is handy because you also + need to create the host principal (the KDC end + of the krb5.keytab) using + kadmin. + + Note that you must have already obtained a ticket and that this + ticket must be allowed to use the kadmin + interface in the kadmind.acl. See the section + titled Remote administration in the Heimdal info + pages (info heimdal) for details on designing + access control lists. If you do not want to enable remote + kadmin access, you can simply securely connect + to the KDC (via local console, + ssh or Kerberos + telnet) and perform administration locally + using kadmin -l. + + After installing the /etc/krb5.conf file, + you can use kadmin from the + Kerberos server. The + add --random-key command will let you add the + servers host principal, and the ext command + will allow you to extract the servers host principal to its own + keytab. For example: + + &prompt.root;kadmin +kadmin> add --random-key host/myserver.example.prv +Max ticket life [unlimited]: +Max renewable life [unlimited]: +Attributes []: +kadmin> ext host/myserver.example.prv +kadmin> exit + + Note that the ext command (short for + extract) stores the extracted key in + /etc/krb5.keytab by default, which is + handy. + + If you do not have kadmind running on the + KDC (possibly for security reasons) and thus + do not have access to kadmin remotely, you + can add the host principal + (host/myserver.example.prv) directly on the + KDC and then extract it to a temporary file + (to avoid over-writing the /etc/krb5.keytab + on the KDC) using something like this: + + &prompt.root;kadmin +kadmin> ext --keytab=/tmp/example.keytab host/myserver.smithclan.prv +kadmin> exit + + You can then securely copy the keytab to the server + computer (using scp or a floppy, for + example). Be sure to specify a non-default keytab name + to avoid over-writing the keytab on the + KDC + + At this point your server can communicate with the + KDC (due to it's krb5.conf + file) and it can prove it's own identity (due to the + krb5.keytab file). It's now ready for + you to enable some Kerberos services. + For this example we will enable the telnet + service by putting a line like this into your + /etc/inetd.conf and then restarting the + inetd service with + /etc/rc.d inetd restart: + + telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user + + The critical bit is that the -a + (for authentication) type is set to user. Consult for the + telnetd man page for more details. + + + + + <application>Kerberos</application> enabling a client with Heimdal + + Setting up a client computer is almost trivially easy. As + far as Kerberos configuration goes, + you only need the Kerberos + configuration file, located at /etc/krb5.conf. + Simply securely copy it over to the client computer from the + KDC. + + Test your client computer by attempting to use + kinit, klist and + kdestroy from the client to obtain, show, and + then delete a ticket for the principal you created above. You + should also be to use Kerberos + applications to connect to Kerberos + enabled servers, though if that doesn't work and obtaining a + ticket does the problem is likely with the server and not with + the client or the KDC. + + When testing an application like telnet, + try using a packet sniffer (such as tcpdump) + to confirm that your password is not sent in the clear. Try + using telnet with the -x + option, which encrypts the entire data stream (similar to + ssh). + + The core Kerberos client applications + (traditionally named kinit, + klist, kdestroy and + kpasswd) are installed in + the base &os; install. Note that &os; versions prior to 5.0 + renamed them to k5init, + k5list, k5destroy, + k5passwd, and kstash + (though it's typically only used once). + + Various non-core Kerberos client + applications are also installed by default. This is where the + minimal nature of the base Heimdal installation is + felt: telnet is the only + Kerberos enabled service. + + The Heimdal port adds some of the missing client applications: + Kerberos enabled versions of + ftp, rsh, + rcp, rlogin, and a few + other less common programs. The MIT port also + contains a full suite of Kerberos + client applications. + + + + + User config file: .k5login and .k5users + + Users within a realm typically have their + Kerberos principal (such as + tillman@EXAMPLE.PRV) mapped to a local + user account (such as a local account named + tillman). This well as the user account + usually does not have to be specified when using a client + application such as telnet. + + Occasionally, however, you want to grant access to a local + user account to someone who does not have a matching + Kerberos principal. For example, + tillman@EXAMPLE.PRV may need access to the + local user account webdevelopers. Other + principals may also need access to that local account. + + The .k5login and + .k5users files, placed in a users home + directory, can be used similar to a powerful combination of + .hosts and sudo, solving + this problem. For example, if a .k5login + with the following contents: + + tillman@EXAMPLE.PRV +jdoe@EXAMPLE.PRV + + Were to be placed into the home directory of the local user + webdevelopers then both principals listed + would have access to that account without requiring a shared + password. + + Reading the man pages for these commands is recommended. + Note that the ksu man page covers + .k5users. + + + + + Troubleshooting + + + + When using either the Heimdal or MIT + Kerberos ports ensure that your + PATH environment variable lists the + Kerberos versions of the client + applications before the system versions. + + + + Is your time in sync? Are you sure? If the time is not in + sync (typically within five minutes) authentication often + fails. + + + + MITand Heimdal interoperate nicely. + Except for kadmin, the protocol for + which is not standardized. + + + + If you change your hostname, you also need to change your + host/ principal and update your keytab. + This also applies to special keytab entries like the + www/ principal used for Apache's + mod_auth_kerb. + + + + All hosts in your realm must be resolvable (both forwards + and reverse) in DNS (or + /etc/hosts as a minimum). CNAMEs + will work, but the A and PTR records must be correct and in + place. The error message isn't very intuitive: + KerberosV5 refuses authentication because Read req + failed: Key table entry not found. + + + + Some operating systems that may being acting as clients + to your KDC do not set the permissions + for ksu to be setuid + root. This means that + ksu does not work, which is a good + security idea but annoying. This is not a + KDC error. + + + + With MIT + Kerberos, if you want to allow a + principal to have a ticket life longer than the default ten + hours, you must use modify_prinicpal in + kadmin to change the maxlife of both the + principal in question and the krbtgt + principal. Then the principal can use the + option with kinit + to request a ticket with a longer life. + + + + Note: If you run a packet sniffer on your + KDC to add in troubleshooting and then run + kinit from a workstation, you will notice + that your TGT is sent immediately upon + running kinit -- even before you type your + password! The explanation is that the + Kerberos server freely transmits a + TGT 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, + it's being used to decrypt the TGT that + kinit already obtained. If the decryption + process results in a valid ticket with a valid time stamp, the + user has valid Kerberos credentials. + These credentials include a session key for establishing secure + communications with the Kerberos + server in the future, as well as the actual ticket-granting + ticket, which is actually encrypted with the + Kerberos server's own key. This + second layer of encryption is unknown to the user, but it's what + allows the Kerberos server to verify + the authenticity of each TGT. + + + + + <application>Kerberos</application> Tips + + + + + You have to keep the time in sync between all the + computers in your realm. NTP is + perfect for this. + + + + If you want to use long ticket lifetimes (a week, for + example) and you are using OpenSSH + to connect to the machine where your ticket is stored, make + sure that Kerberos + is set to no + in your sshd_config or else your tickets + will be deleted when you log out. + + + + Remember that host principals can have a longer ticket + life as well. If your user principal has a lifetime of a + week but the host you're connecting to has a lifetime of nine + hours, you will have an expired host principal in your cache + and the ticket cache will not work as expected. + + + + When setting up a krb5.dict file to + prevent specific bad passwords from being used (the man page for + kadmind covers this briefly), remember that + it only applies to principals that have a password policy + assigned to them. The krb5.dict files + format is simple: one string per line. Creating a symlink to + /usr/share/dict/words might be + useful. + + + + + + + Differences with the MIT port + + The major differences between the MIT + and Heimdal installs relates to the kadmin + program which has a different (but equivalent) set of commands + and uses a different protocol. This has a large implications + if your KDC is MIT as you + will not be able to use the Heimdal kadmin + program to administer your KDC remotely + (or vice versa, for that matter). + + The client applications may also take slightly different + command line options to accomplish the same tasks. Following + the instructions on the MIT + Kerberos web site () + is recommended. Be careful of path issues: the + MIT port installs into + /usr/local/ by default, and the + normal system applications may be run instead + of MIT if your PATH + environment variable lists the system directories first. + + Important note: With the MIT krb5 port + that is provided by &os;, be sure and read the + /usr/local/share/doc/krb5/README.FreeBSD + file installed by the port if you want to understand why logins + via telnetd and klogind + behave somewhat oddly. Most importantly, correcting the + incorrect permissions on cache file behavior + requires that the login.krb5 binary be used + for authentication so that it can properly chown the forwarded + credentials. + + + + + Mitigating limitations found in <application>Kerberos</application> + + + <application>Kerberos</application> is an all-or-nothing approach + + Every service enabled on the network must be modified to + work with Kerberos (or be otherwise + secured against network attacks) or else the users credentials + could be stolen and re-used. An example of this would be + Kerberos enabling all remote shells + (via rsh and telnet, for + example) but not converting the POP3 mail + server ... which sends passwords in plaintext. + + + + + <application>Kerberos</application> is intended for single-user workstations + + In a multi-user environment, + Kerberos is less secure. This is + because it stores the tickets in the global + /tmp directory, which is readable by all + users. If a user is sharing a computer with several other + people simultaneously (i.e. multi-user), it is possible that + the user's tickets can be stolen (copied) by another + user. + + This can be overcome with the -c + filename command-line option or (preferably) the + KRB5CCNAME environment variable, but this + is rarely done. In principal, storing the ticket in the users + home directory and using simple file permissions can mitigate + this problem. + + + + + The KDC is a single point of security failure + + By design, the KDC must be secure as + the master password database is contained on it. The + KDC should have absolutely no other + services running on it and should be physically secured. The + danger is high because Kerberos + stores all passwords encrypted with the same key (the + master key), which in turn is stored as a file + on the KDC. + + As a side note, a compromised master key is not quite as + bad as one might normally fear. The master key is only used + to encrypt the Kerberos database + and as a seed for the random number generator. As long as + access to your KDC is secure, an attacker + cannot do much with the master key. + + Additionally, if the KDC is unavailable + (perhaps due to a denial of service attack or network problems) + the network services are unusable as authentication can not be + performed, a recipe for a denail-of-service attack. This can + alleviated with multiple KDCs (a single + master and one or more slaves) and with careful implementation + of secondary or fall-back authentication + (PAM is excellent for this). + + + + + <application>Kerberos</application> Shortcomings + + Kerberos allows users, hosts + and services to authenticate between themselves. It does not + have a mechanism to authenticate the KDC + to the users, hosts or services. This means that a trojaned + kinit (for example) could record all user + names and passwords. Something like + security/tripwire or + other file system integrity checking tools can alleviate + this. + + + + + + + Resources and further information + + + + + The Kerberos FAQ + + + + Designing + an Authentication System: a Dialogue in Four Scenes + + + + RFC 1510, + The Kerberos Network Authentication Service + (V5) + + + + MIT + Kerberos home page + + + + Heimdal + Kerberos home page + + + + + + + + + + From owner-freebsd-doc@FreeBSD.ORG Sat Aug 23 08:23:25 2003 Return-Path: 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 6A38E16A4BF; Sat, 23 Aug 2003 08:23:25 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E64C43FE0; Sat, 23 Aug 2003 08:23:23 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 87C2110BFA8; Sat, 23 Aug 2003 17:23:22 +0200 (CEST) Date: Sat, 23 Aug 2003 17:23:22 +0200 From: "Simon L. Nielsen" To: Tom Rhodes Message-ID: <20030823152320.GC391@FreeBSD.org> References: <20030823094817.76e3b847.trhodes@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <20030823094817.76e3b847.trhodes@FreeBSD.org> User-Agent: Mutt/1.5.4i cc: freebsd-doc@FreeBSD.org Subject: Re: Kerberos5 chapter [was: Your message to freebsd-doc awaits moderator approval] X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2003 15:23:25 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.08.23 09:48:17 -0400, Tom Rhodes wrote: > We can't send plain text emails anymore?? It normally works fine for me. Perhaps the spam filters have been set to be a bit more aggressive due to all the worm bounce mails lately (just a guess). > Here I bring the kerberos5 handbook section to everyone for review. > A few tidbits of pre-review information: >=20 > This was done under the theory that KerberosIV is gone from 5.1 and > post releases. Thus there is a history part, and some extra information; > this was done so that we can fade away the other chapter with ease. > If it is desired for some unknown reason, I would like to commit the > entire part and then in a seperate commit: remove the > history/introduction. This method would allow myself, or another > doc hacker to restore that information when the old version is > dissolved. I'm not really sure exactly which part you are talking about, but it's a part that should be enabled later, perhaps it could just be committed and "hidden" inside an SGML comment ()? --- chapter.old Sat Aug 23 08:11:30 2003 +++ chapter.sgml Sat Aug 23 09:21:11 2003 @@ -1919,6 +1919,740 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 + + + + + + + + + + Tillman + Hodgson + Contributed by + + + + + Mark + Murray + Based on a contribution by + + + + + <application>Kerberos5</application> + + Every &os; release beyond &os;-5.1 includes support + only for Kerberos5. Hence + Kerberos5 is the only version + included, and its configuration is similar in many aspects The first sentence and the first part of the second sentence seems to say the same? Perhaps a note about KerberosIV being available as a port for FreeBSD 5.1? (I think the the port is security/krb4). + to that of KerberosIV. The following + information should only apply to + Kerberos5 in post &os;-5.0 + releases. + + Kerberos is a network add-on + system/protocol that allows users to authenticate themselves + through the services of a secure server. Services such as remote + login, remote copy, secure inter-system file copying and other + high-risk tasks are made considerably safer and more + controllable. + + Kerberos can be described as an + identity-verifying proxy system. It can also be described as a + trusted third-party authentication system. + + Note that Kerberos provides only + authentication services and nothing more. Therefore it is highly + recommended that Kerberos be used with + other security methods which authorization and audit services. How about moving the note about what authorization and audit is to this paragraph since this is the first time the distinction is mentioned. + The following instructions can be used as a guide on how to set + up Kerberos as distributed for &os;. + However, you should refer to the relevant manual pages for a complete + description. + + For purposes of demonstrating a Kerberos + installation, the various namespaceswill be handled as follows: + + + + The DNS domain (zone) will be example.prv. Perhaps 'example.prv' should be marked up with ? + + + + The Kerberos realm will be + EXAMPLE.PRV. + + + + Please refrain from the use of these namespaces in the real + world. Not only will it not be optimal for your network and + DNS server, it will make interoperating with other + Kerberos realms more difficult. + + + Background: History + + Kerberos was created by + MIT as a solution to network security problems. + The Kerberos protocol uses strong + cryptography so that a client can prove its identity to a server + (and vice versa) across an insecure network connection. + + Kerberos provides only one + function -- the secure authentication of users on the network. It + does not provide authorization functions (what those users are + able to perform) or auditing fuctions (what those users did). I meant these notes about authorization and auditing which I think should be moved up in the document. + After a client and server have used + Kerberos to prove their identity, they + can also encrypt all of their communications to assure privacy + and data integrity as they go about their business. + + Kerberos is both the name of a + network authentication protocol and an adjective to describe + programs that implement the program + (Kerberos telnet, for example). The + current version of the protocol is version 5, described in + RFC 1510. Kerberos + was designed to provide strong authentication for client/server + applications (such as traditional Internet services like + FTP and telnet) by using secret-key + cryptography. + + Several free implementations of this protocol are available, + covering a wide range of operating systems. The Massachusetts + Institute of Technology, where Kerberos Perhaps insert ^ "(MIT)" I think it's a good idea to introduce acronyms, so there is no doubt what is meant when using them later. + was originally developed, continues to develop their + Kerberos package and it is commonly used + in the US (as a cryptography product, it has + historically been affected by US export + regulations). The MIT + Kerberos is available as a port + (security/krb5). Heimdal + Kerberos is another version 5 + implementation, and was explicitly developed outside of the + US to avoid export + regulations (and is thus often included in non-commercial Unix + variants). The Heimdal Kerberos + distribution is available as a port + (security/heimdal), and a + minimal installation of it is included in the base &os; + install. + + In order to reach the widest audience, these instructions assume + the use of the Heimdal distribution included in &os;. + + + + + Background: <application>KerberosIV</application> and + <application>Kerberos</application> 5 + + Older versions of Kerberos included b= oth + KerberosIV (eBones) and + Kerberos 5 (Heimdal). Support for + KerberosIV has been dropped as of &os; + 5.0. + + + + + Setting up a Heimdal <acronym>KDC</acronym> + + The KDC, or Key Distribution Center, is the + centralized authentication service that + Kerberos provides -- it is the computer + that issues Kerberos tickets. The + KDC is considered trusted by all + other computers in the Kerberos realm, and thus + has heightened security concerns. + + Note that while running the Kerberos + server requires very few computing resources, a dedicated machine + acting only as a KDC is recommended for security + reasons. + + To begin setting up a KDC, ensure that your + /etc/rc.conf file contains the correct + settings to act as a KDC (you may need to adjust + paths to reflect your own system): + + Kerberos5_server_enable=3D"YES" +kadmind5_server_enable=3D"YES" +Kerberos_stash=3D"YES" + + Next we'll set up your Kerberos + config file, /etc/krb5.conf: + + [libdefaults] + default_realm =3D EXAMPLE.PRV +[realms] + EXAMPLE.PRV =3D { + kdc =3D Kerberos.example.prv + } +[domain_realm] + .example.prv =3D EXAMPLE.PRV + + Note that this /etc/krb5.conf file implies + that your KDC will have the fully-qualified + hostname of Kerberos.example.prv. You will need For the role defaults to 'hostname', so I think role=3D"fqdn" should be added above. + to add a CNAME (alias) entry to your zone file to accomplish this + if your KDC has a different hostname. + + Next we will create the Kerberos + database. The keys of all the principals are stored in this + database in encrypted form with a master password. You are not + required to remember this password, it will be stored in a file + (/var/heimdal/m-key). To create the master + key, run kstash and enter a password. + + Once the master key has been created, you can initialize the + database using the kadmin program with the Use &man.kadmin.8; ? (Since the manual page webinterface is broken for crypto pages right now the link will probably be bogus at the moment, but I think this will be fixed at some point). + -l option (standing for local). -l ? + This option instructs kadmin to modify the + database files directly rather than going through the + kadmind network service. This handles the + chicken-and-egg problem of trying to connect to the database + before it is created. Once you have the kadmin> Typo: ^ + prompt, use the init command to create your + realms initial database. + + Lastly, while still in kadmin, create your + first principal using the add command. Stick + to the defaults options for the principal for now, you can always + change them later with the modify command. + Note that you can use the ? command at any + prompt to see the available options are. + + A sample database creation session is shown below: How about marking up all occurrences of tillman with ? I haven't tried it; it might look silly, I'm not really sure... + + &prompt.root;kstash +Master key: xxxxxxxx +Verifying password - Master key: xxxxxxxx + +&prompt.root;kadmin -l +kadmin> init EXAMPLE.PRV +Realm max ticket life [unlimited]: +kadmin> add tillman +Max ticket life [unlimited]: +Max renewable life [unlimited]: +Attributes []: +Password: xxxxxxxx +Verifying password - Password: xxxxxxxx + + Now it's time to start up the KDC services. + Run /etc/rc.d/Kerberos start and Typo ? ^ + /etc/rc.d/kadmind start to bring up the + services. Note that you won't have any Kerberized daemons running + at this point but you should be able to confirm the that the + KDC is functioning by obtaining and listing a + ticket for the principal (user) that you just created from the + command-line of the KDC itself: + + &prompt.user;k5init tillman +tillman@EXAMPLE.PRV's Password: + +&prompt.user;k5list +Credentials cache: FILE:/tmp/krb5cc_500 + Principal: tillman@EXAMPLE.PRV + + Issued Expires Principal +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV@EXAMPLE.PRV +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV@EXAMPLE.PRV + +v4-ticket file: /tmp/tkt500 +k5list: No ticket file (tf_util) + + + + + <application>Kerberos</application> enabling a server with + Heimdal services + + First, we need a copy of the Kerberos + configuration file, /etc/krb5.conf. To do + so, simply copy it over to the client computer from the + KDC in a secure fashion (using the network, + such as scp, or physically via a &man.scp.1; ? + floppy). + + Next you need a /etc/krb5.keytab file. + This is the major difference between a server provide + Kerberos enabled daemons and a + workstation -- the server must have a keytab file. This file + contains the servers host key, which allows it and the + KDC to verify each others identity. It + must be transmitted to the server in a secure fashion, as the + security of the server can be broken if the key is made public. + This explicitly means that transferring it via a clear text + channel, such as FTP, is a very bad idea. + + Typically, you transfer to the keytab to the server using the + kadmin program. This is handy because you also + need to create the host principal (the KDC end + of the krb5.keytab) using + kadmin. + + Note that you must have already obtained a ticket and that this + ticket must be allowed to use the kadmin + interface in the kadmind.acl. See the section + titled Remote administration in the Heimdal info + pages (info heimdal) for details on designing + access control lists. If you do not want to enable remote + kadmin access, you can simply securely connect + to the KDC (via local console, + ssh or Kerberos &man.ssh.1; ? + telnet) and perform administration locally &man.telnet.1; ? + using kadmin -l. + + After installing the /etc/krb5.conf file, + you can use kadmin from the + Kerberos server. The + add --random-key command will let you add the + servers host principal, and the ext command + will allow you to extract the servers host principal to its own + keytab. For example: + + &prompt.root;kadmin +kadmin> add --random-key host/myserver.example.prv +Max ticket life [unlimited]: +Max renewable life [unlimited]: +Attributes []: +kadmin> ext host/myserver.example.prv +kadmin> exit + + Note that the ext command (short for + extract) stores the extracted key in + /etc/krb5.keytab by default, which is + handy. + + If you do not have kadmind running on the + KDC (possibly for security reasons) and thus + do not have access to kadmin remotely, you + can add the host principal + (host/myserver.example.prv) directly on the + KDC and then extract it to a temporary file + (to avoid over-writing the /etc/krb5.keytab + on the KDC) using something like this: + + &prompt.root;kadmin +kadmin> ext --keytab=3D/tmp/example.keytab host/myserver.smithclan.prv +kadmin> exit + + You can then securely copy the keytab to the server + computer (using scp or a floppy, for + example). Be sure to specify a non-default keytab name + to avoid over-writing the keytab on the + KDC + + At this point your server can communicate with the + KDC (due to it's krb5.conf + file) and it can prove it's own identity (due to the + krb5.keytab file). It's now ready for + you to enable some Kerberos services. + For this example we will enable the telnet + service by putting a line like this into your + /etc/inetd.conf and then restarting the + inetd service with &man.inetd.1; ? + /etc/rc.d inetd restart: ^ Missing / + + telnet stream tcp nowait root /usr/libexec/te= lnetd telnetd -a user + + The critical bit is that the -a + (for authentication) type is set to user. Consult for the + telnetd man page for more details. + + + + + <application>Kerberos</application> enabling a client with Heimdal= + + Setting up a client computer is almost trivially easy. As + far as Kerberos configuration goes, + you only need the Kerberos + configuration file, located at /etc/krb5.conf. + Simply securely copy it over to the client computer from the + KDC. + + Test your client computer by attempting to use + kinit, klist and + kdestroy from the client to obtain, show, and + then delete a ticket for the principal you created above. You + should also be to use Kerberos + applications to connect to Kerberos + enabled servers, though if that doesn't work and obtaining a + ticket does the problem is likely with the server and not with + the client or the KDC. + + When testing an application like telnet, + try using a packet sniffer (such as tcpdump) &man.tcpdump.1; + to confirm that your password is not sent in the clear. Try + using telnet with the -x ^^ -x + option, which encrypts the entire data stream (similar to + ssh). + + The core Kerberos client applications + (traditionally named kinit, + klist, kdestroy and + kpasswd) are installed in Manual page references for the above commands? + the base &os; install. Note that &os; versions prior to 5.0 + renamed them to k5init, + k5list, k5destroy, + k5passwd, and kstash + (though it's typically only used once). + + Various non-core Kerberos client + applications are also installed by default. This is where the + minimal nature of the base Heimdal installation is + felt: telnet is the only + Kerberos enabled service. + + The Heimdal port adds some of the missing client applications: + Kerberos enabled versions of + ftp, rsh, + rcp, rlogin, and a few + other less common programs. The MIT port also + contains a full suite of Kerberos + client applications. + + + + + User config file: .k5login and .k5users Perhaps for the above files? I don't know if that's normally done in titles.. + + Users within a realm typically have their + Kerberos principal (such as + tillman@EXAMPLE.PRV) mapped to a local + user account (such as a local account named + tillman). This well as the user account + usually does not have to be specified when using a client + application such as telnet. + + Occasionally, however, you want to grant access to a local + user account to someone who does not have a matching + Kerberos principal. For example, + tillman@EXAMPLE.PRV may need access to the + local user account webdevelopers. Other + principals may also need access to that local account. + + The .k5login and + .k5users files, placed in a users home + directory, can be used similar to a powerful combination of + .hosts and sudo, solving + this problem. For example, if a .k5login + with the following contents: + + tillman@EXAMPLE.PRV +jdoe@EXAMPLE.PRV + + Were to be placed into the home directory of the local user + webdevelopers then both principals listed + would have access to that account without requiring a shared + password. + + Reading the man pages for these commands is recommended. + Note that the ksu man page covers Hmm, I don't have a ksu manual page.. Perhaps it's only in MIT Kerberos? + .k5users. + + + + + Troubleshooting + + + + When using either the Heimdal or MIT + Kerberos ports ensure that your + PATH environment variable lists the I think this should be PATH + Kerberos versions of the client + applications before the system versions. + + + + Is your time in sync? Are you sure? If the time is not in + sync (typically within five minutes) authentication often + fails. + + + + MITand Heimdal interoperate nicely. + Except for kadmin, the protocol for + which is not standardized. + + + + If you change your hostname, you also need to change your + host/ principal and update your keytab. + This also applies to special keytab entries like the + www/ principal used for Apache's + mod_auth_kerb. Perhaps a reference to the port www/mod_auth_kerb ? + + + + All hosts in your realm must be resolvable (both forwards + and reverse) in DNS (or + /etc/hosts as a minimum). CNAMEs + will work, but the A and PTR records must be correct and in + place. The error message isn't very intuitive: + KerberosV5 refuses authentication because Read req + failed: Key table entry not found. + + + + Some operating systems that may being acting as clients + to your KDC do not set the permissions + for ksu to be setuid + root. This means that + ksu does not work, which is a good + security idea but annoying. This is not a + KDC error. + + + + With MIT + Kerberos, if you want to allow a + principal to have a ticket life longer than the default ten + hours, you must use modify_prinicpal in + kadmin to change the maxlife of both the + principal in question and the krbtgt + principal. Then the principal can use the + option with kinit Hmm, here you use + + + + Note: If you run a packet sniffer on your + KDC to add in troubleshooting and then run + kinit from a workstation, you will notice + that your TGT is sent immediately upon Hmm, I don't remeber TGT being mentioned before? + running kinit -- even before you type your + password! The explanation is that the + Kerberos server freely transmits a + TGT 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, + it's being used to decrypt the TGT that + kinit already obtained. If the decryption + process results in a valid ticket with a valid time stamp, the + user has valid Kerberos credentials. + These credentials include a session key for establishing secure + communications with the Kerberos + server in the future, as well as the actual ticket-granting + ticket, which is actually encrypted with the + Kerberos server's own key. This + second layer of encryption is unknown to the user, but it's what + allows the Kerberos server to verify + the authenticity of each TGT. + + + + + <application>Kerberos</application> Tips + + + + + You have to keep the time in sync between all the + computers in your realm. NTP is + perfect for this. + Perhaps a reference to section 19.11 which describes NTP. + + + If you want to use long ticket lifetimes (a week, for + example) and you are using OpenSSH + to connect to the machine where your ticket is stored, make + sure that Kerberos + is set to no + in your sshd_config or else your tickets + will be deleted when you log out. + + + + Remember that host principals can have a longer ticket + life as well. If your user principal has a lifetime of a + week but the host you're connecting to has a lifetime of nine + hours, you will have an expired host principal in your cache + and the ticket cache will not work as expected. + + + + When setting up a krb5.dict file to + prevent specific bad passwords from being used (the man page for + kadmind covers this briefly), remember that + it only applies to principals that have a password policy + assigned to them. The krb5.dict files + format is simple: one string per line. Creating a symlink to + /usr/share/dict/words might be + useful. + + + + + + + Differences with the MIT port around MIT here? + + The major differences between the MIT + and Heimdal installs relates to the kadmin + program which has a different (but equivalent) set of commands + and uses a different protocol. This has a large implications + if your KDC is MIT as you + will not be able to use the Heimdal kadmin + program to administer your KDC remotely + (or vice versa, for that matter). + + The client applications may also take slightly different + command line options to accomplish the same tasks. Following + the instructions on the MIT + Kerberos web site () + is recommended. Be careful of path issues: the + MIT port installs into + /usr/local/ by default, and the + normal system applications may be run instead + of MIT if your PATH PATH + environment variable lists the system directories first. + + Important note: With the MIT krb5 port + that is provided by &os;, be sure and read the + /usr/local/share/doc/krb5/README.FreeBSD + file installed by the port if you want to understand why logins + via telnetd and klogind + behave somewhat oddly. Most importantly, correcting the + incorrect permissions on cache file behavior + requires that the login.krb5 binary be used + for authentication so that it can properly chown the forwarded + credentials. + + + + + Mitigating limitations found in <application>Kerberos</application= > + + + <application>Kerberos</application> is an all-or-nothing approach= + + Every service enabled on the network must be modified to + work with Kerberos (or be otherwise + secured against network attacks) or else the users credentials + could be stolen and re-used. An example of this would be + Kerberos enabling all remote shells + (via rsh and telnet, for + example) but not converting the POP3 mail + server ... which sends passwords in plaintext. + + + + + <application>Kerberos</application> is intended for single-user = workstations + + In a multi-user environment, + Kerberos is less secure. This is + because it stores the tickets in the global + /tmp directory, which is readable by all + users. If a user is sharing a computer with several other + people simultaneously (i.e. multi-user), it is possible that + the user's tickets can be stolen (copied) by another + user. + + This can be overcome with the -c