From owner-freebsd-doc@FreeBSD.ORG Sun Apr 19 14:30:01 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADEAB1065673 for ; Sun, 19 Apr 2009 14:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 870C88FC18 for ; Sun, 19 Apr 2009 14:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3JEU19i029464 for ; Sun, 19 Apr 2009 14:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3JEU1r6029461; Sun, 19 Apr 2009 14:30:01 GMT (envelope-from gnats) Resent-Date: Sun, 19 Apr 2009 14:30:01 GMT Resent-Message-Id: <200904191430.n3JEU1r6029461@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, David Wolfskill Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 230B3106564A for ; Sun, 19 Apr 2009 14:22:18 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id CE1C48FC1C for ; Sun, 19 Apr 2009 14:22:17 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id n3JEAQH5026967 for ; Sun, 19 Apr 2009 07:10:26 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id n3JEAQi4026966; Sun, 19 Apr 2009 07:10:26 -0700 (PDT) (envelope-from david) Message-Id: <200904191410.n3JEAQi4026966@albert.catwhisker.org> Date: Sun, 19 Apr 2009 07:10:26 -0700 (PDT) From: David Wolfskill To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/133855: New mailing list, freebsd-gecko X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wolfskill List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 14:30:02 -0000 >Number: 133855 >Category: docs >Synopsis: New mailing list, freebsd-gecko >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sun Apr 19 14:30:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: David Wolfskill >Release: FreeBSD 7.1-STABLE i386 >Organization: Wolfskill & Dowling Residence >Environment: System: FreeBSD albert.catwhisker.org 7.1-STABLE FreeBSD 7.1-STABLE #16: Sun Jan 11 13:57:46 PST 2009 root@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/ALBERT i386 >Description: Per Martin Wilke's request, I've created a new FreeBSD mailing list, freebsd-gecko. Patch (below) is for the documentation about the FreeBSd.org mailing lists. >How-To-Repeat: n/a >Fix: Index: en_US.ISO8859-1/books/handbook/eresources/chapter.sgml =================================================================== RCS file: /cvs/freebsd/doc/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml,v retrieving revision 1.197 diff -u -r1.197 chapter.sgml --- en_US.ISO8859-1/books/handbook/eresources/chapter.sgml 22 Jan 2009 23:02:42 -0000 1.197 +++ en_US.ISO8859-1/books/handbook/eresources/chapter.sgml 19 Apr 2009 13:53:51 -0000 @@ -292,6 +292,11 @@ + &a.gecko.name; + Gecko Rendering Engine issues + + + &a.geom.name; GEOM-specific discussions and implementations @@ -1179,6 +1184,17 @@ + &a.gecko.name; + + + Gecko Rendering Engine + + This is a forum about Gecko applications using FreeBSD. + Discussion centers, around Gecko Ports applications, their installation, their development and their support within FreeBSD. + + + + &a.geom.name; Index: en_US.ISO8859-1/share/sgml/mailing-lists.ent =================================================================== RCS file: /cvs/freebsd/doc/en_US.ISO8859-1/share/sgml/mailing-lists.ent,v retrieving revision 1.67 diff -u -r1.67 mailing-lists.ent --- en_US.ISO8859-1/share/sgml/mailing-lists.ent 22 Jan 2009 23:02:42 -0000 1.67 +++ en_US.ISO8859-1/share/sgml/mailing-lists.ent 19 Apr 2009 13:55:17 -0000 @@ -179,6 +179,10 @@ FreeBSD file system project mailing list"> freebsd-fs"> + +FreeBSD gecko mailing list"> +freebsd-gecko"> + FreeBSD GEOM mailing list"> freebsd-geom"> >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sun Apr 19 14:35:47 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C88A106566C; Sun, 19 Apr 2009 14:35:47 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E6DF28FC0C; Sun, 19 Apr 2009 14:35:46 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from freefall.freebsd.org (pgj@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3JEZk35044174; Sun, 19 Apr 2009 14:35:46 GMT (envelope-from pgj@freefall.freebsd.org) Received: (from pgj@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3JEZkS5044170; Sun, 19 Apr 2009 14:35:46 GMT (envelope-from pgj) Date: Sun, 19 Apr 2009 14:35:46 GMT Message-Id: <200904191435.n3JEZkS5044170@freefall.freebsd.org> To: pgj@FreeBSD.org, freebsd-doc@FreeBSD.org, pgj@FreeBSD.org From: pgj@FreeBSD.org Cc: Subject: Re: docs/133855: New mailing list, freebsd-gecko X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 14:35:47 -0000 Synopsis: New mailing list, freebsd-gecko Responsible-Changed-From-To: freebsd-doc->pgj Responsible-Changed-By: pgj Responsible-Changed-When: Sun Apr 19 14:35:04 UTC 2009 Responsible-Changed-Why: I will take this :P http://www.freebsd.org/cgi/query-pr.cgi?pr=133855 From owner-freebsd-doc@FreeBSD.ORG Mon Apr 20 11:06:06 2009 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 185901065679 for ; Mon, 20 Apr 2009 11:06:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 059238FC2C for ; Mon, 20 Apr 2009 11:06:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3KB65vk032078 for ; Mon, 20 Apr 2009 11:06:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3KB65V2032074 for freebsd-doc@FreeBSD.org; Mon, 20 Apr 2009 11:06:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Apr 2009 11:06:05 GMT Message-Id: <200904201106.n3KB65V2032074@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: FreeBSD doc list Cc: Subject: Current unassigned doc problem reports X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 11:06:06 -0000 (Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=doc .) 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. S Tracker Resp. Description -------------------------------------------------------------------------------- o docs/133785 doc [PATCH] man pages lying about HISTORY o docs/133765 doc setfib(2) man page section o docs/133567 doc [patch] doc/Makefile switch to csup o docs/133407 doc Incorrect UK rsync mirror address in handbook o docs/133245 doc french handbook 27.3.5 amd.map amd.conf o docs/133228 doc handbook 23.3.5 screenmap section is confusing o docs/133186 doc powerd(8) man page errors o docs/133118 doc [patch] Error in getopt (1) manual EXAMPLES section o docs/133110 doc [patch] Typo corrections for /usr/src/UPDATING o docs/132959 doc description mismatches on xterm/termcap, fortune/freeb o docs/132884 doc [request] No manpage for SYSINIT and SYSUNINIT o docs/132839 doc [patch] Fix example script in ldap-auth article o docs/132718 doc [handbook] Information about adding a new mirror is ou o docs/132525 doc [PATCH] Fix documentation for atapicam(4) and umass(4) o docs/132311 doc [patch] man5/nsmb.conf.5 o docs/132260 doc dhcpd(8) pid not stored in documented location o docs/132193 doc description in the malo(4) manpage incorrect o docs/132190 doc EPERM explanation for send(2), sendto(2), and sendmsg( o docs/132113 doc [handbook] Update handbook jails creation o docs/131918 doc [patch] Fixes for the BPF(4) man page o docs/131898 doc [PATCH] removal of nonexistent manpage in SEE ALSO sec o docs/131684 doc [patch] articles/linux-comparison: replace Addenda by o docs/131590 doc [patch] whitespace-only change of developers-handbook/ o docs/131562 doc [patch] groff(1): don't corrupt man pages by replacing o docs/130895 doc No man page installed for padlock(4) on amd64 sytstem o docs/130742 doc [patch] articles/geom-class: russian translation is mi o docs/130530 doc atacontrol(8) does not mention SATA300 mode (or SATA15 o docs/130364 doc Man page for top needs explanation of CPU states o docs/130238 doc nfs.lockd man page doesn't mention NFSLOCKD option or o docs/129671 doc New TCP chapter for Developer's Handbook (from rwatson o docs/129196 doc Inconsistent errno in strtol() o docs/129095 doc ipfw(8): Can not check that packet originating/destine o docs/128524 doc No geom documentation for loading gjournal(8) o docs/128356 doc [request] add Firefox plugin for FreeBSD manual pages o docs/127908 doc [patch] readdir(3) error documentation s docs/127844 doc Example code skeleton_capture_n.c in meteor(4) manpage o docs/126590 doc [patch] Write routine called forever in Sample Echo Ps o docs/126484 doc libc function res-zonscut2 is not documented o docs/125921 doc lpd(8) talks about blocks in minfree while it is KB in o docs/125751 doc man 3 pthread_getschedparam section ERRORS incomplete f docs/122052 doc minor update on handbook section 20.7.1 o docs/121952 doc Handbook chapter on Network Address Translation wrong o docs/121871 doc ftpd does not interpret configuration files as documen o docs/121585 doc [handbook] Wrong multicast specification o docs/121565 doc dhcp-options(5) manpage incorrectly formatted omitting s docs/121541 doc [request] no man pages for wlan_scan_ap o bin/121424 doc [patch] [ipfw] Rectify ambiguous English in manual o docs/121312 doc RELNOTES_LANG breaks release if not en_US.ISO8859-1 o docs/121173 doc [patch] mq_getattr(2): mq_flags mistakenly described a s docs/120917 doc [request]: Man pages mising for thr_xxx syscalls o docs/120539 doc Inconsistent ipfw's man page o docs/120456 doc ath(4) needs to specify requirement on wlan_scan_sta o docs/120125 doc [patch] Installing FreeBSD 7.0 via serial console and o docs/120024 doc resolver(5) and hosts(5) need updated for IPv6 o docs/119545 doc books/arch-handbook/usb/chapter.sgml formatting a docs/119536 doc a few typos in French handbook (basics) o docs/118902 doc [patch] wrong signatures in d2i_RSAPublicKey man pages o docs/118332 doc man page for top does not describe STATE column wait e o docs/118214 doc close(2) error returns incomplete o docs/118020 doc ipfilter(4): man pages query for man 4 ipfilter return o docs/117747 doc 'break' system call needs a man page o docs/116480 doc sysctl(3) description of kern.file no longer applies s o docs/116116 doc mktemp (3) re/move note o docs/115065 doc [patch] sync ps.1 with p_flag and keywords o docs/114371 doc [patch] [ip6] rtadvd.con(5) should show how to adverti o docs/114184 doc [patch] [ndis]: add info to man 4 ndis o docs/114139 doc mbuf(9) has misleading comments on M_DONTWAIT and M_TR o docs/113194 doc [patch] [request] crontab.5: handling of day-in-month o docs/112804 doc groff(1) command should be called to explicitly use "p o docs/112682 doc Handbook GEOM_GPT explanation does not provide accurat o docs/111425 doc Missing chunks of text in historical manpages o docs/111265 doc [request] Clarify how to set common shell variables o docs/111147 doc hostapd.conf is not documented o docs/110999 doc carp(4) should document unsupported interface types o docs/110692 doc wi(4) man page doesn't say WPA is not supported o docs/110376 doc [patch] add some more explanations for the iwi/ipw fir o docs/110253 doc [patch] rtprio(1): remove processing starvation commen o docs/110062 doc [patch] mount_nfs(8) fails to mention a failure condit o docs/110061 doc [patch] tuning(7) missing reference to vfs.read_max o docs/109981 doc No manual entry for post-grohtml o docs/109977 doc No manual entry for ksu o docs/109973 doc No manual entry for c++filt o docs/109972 doc No manual entry for zless/bzless f docs/109226 doc [request] No manual entry for sntp o docs/109201 doc [request]: manual for callbootd a docs/108980 doc list of missing man pages o docs/108101 doc /boot/default/loader.conf contains an incorrect commen o docs/106135 doc [request] articles/vinum needs to be updated o docs/105608 doc fdc(4) debugging description staled o docs/104879 doc Howto: Listen to IMA ADPCM .wav files on FreeBSD box o docs/102719 doc [patch] ng_bpf(4) example leads to unneeded promiscuos o docs/101464 doc sync ru_RU.KOI8-R/articles/portbuild/article.html with o docs/100196 doc man login.conf does explain not "unlimited" o docs/99506 doc FreeBSD Handbook addition: IPv6 Server Settings o docs/98974 doc Missing tunables in loader(8) manpage o docs/98759 doc [patch] sbp_targ(4) man page missing reference to devi o docs/98115 doc Missing parts after rendering handbook to RTF format o docs/96207 doc Comments of a sockaddr_un structure could confuse one o docs/94625 doc [patch] growfs man page -- document "panic: not enough o docs/92626 doc jail manpage should mention disabling some periodic sc o docs/91506 doc ndis(4) man page should be more specific about support o docs/91174 doc [REQUEST] Handbook: Addition of Oracle 9i installation o docs/91149 doc read(2) can return EINVAL for unaligned access to bloc o docs/88512 doc [patch] mount_ext2fs(8) man page has no details on lar o docs/87936 doc Handbook chapter on NIS/YP lacks good information on a o docs/87857 doc ifconfig(8) wireless options order matters o docs/86342 doc bikeshed entry of Handbook is wrong o docs/85128 doc [patch] loader.conf(5) autoboot_delay incompletly desc o docs/84956 doc [patch] intro(5) manpage doesn't mention API coverage o docs/84932 doc new document: printing with an Epson ALC-3000N on Free o docs/84670 doc [patch] tput(1) manpage missing ENVIRONMENT section wi o docs/84317 doc fdp-primer doesn't show class=USERNAME distinctively o docs/84271 doc [patch] compress(1) doesn't warn about nasty link hand o docs/83820 doc getino(3) manpage not installed f docs/82595 doc 25.5.3 Configuring a bridge section of the handbook ne o docs/78480 doc Networked printer setup unnecessarily complex in handb o docs/63570 doc [patch] Language cleanup for the Handbook's DNS sectio o docs/61605 doc [request] Improve documentation for i386 disk geometry o docs/61301 doc [patch] Manpage patch for aue(4) to enable HomePNA fun o docs/59835 doc ipfw(8) man page does not warn about accepted but mean o docs/59477 doc Outdated Info Documents at http://docs.freebsd.org/inf o docs/59044 doc [patch] doc.docbook.mk does not properly handle a sour s docs/54752 doc bus_dma explained in ISA section in Handbook: should b o docs/53751 doc bus_dma(9) incorrectly documents BUS_DMA_ALLOCNOW o docs/53596 doc Updates to mt(1) manual page o docs/53271 doc bus_dma(9) fails to document alignment restrictions o docs/50211 doc [patch] doc.docbook.mk: fix textfile creation o docs/48101 doc [patch] add documentation on the fixit disk to the FAQ o docs/43823 doc [patch] update to environ(7) manpage o docs/41089 doc pax(1) -B option does not mention interaction with -z o docs/40423 doc Keyboard(4)'s definition of parameters to GETFKEY/SETF o docs/38982 doc [patch] developers-handbook/Jail fix o docs/38556 doc EPS file of beastie, as addition to existing examples s docs/35678 doc docproj Makefiles for web are broken for paths with sp s docs/33589 doc [patch] to doc.docbook.mk to post process .tex files. a docs/30008 doc [patch] French softupdates document should be translat o docs/27605 doc [patch] Cross-document references () o docs/26286 doc *printf(3) etc should gain format string warnings o docs/24786 doc missing FILES descriptions in sa(4) s docs/20028 doc ASCII docs should reflect tags in the sourc 140 problems total. From owner-freebsd-doc@FreeBSD.ORG Mon Apr 20 20:11:43 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7913310656C3 for ; Mon, 20 Apr 2009 20:11:43 +0000 (UTC) (envelope-from root@cosmosocean.gr) Received: from aiolos.otenet.gr (aiolos.otenet.gr [83.235.67.30]) by mx1.freebsd.org (Postfix) with ESMTP id 100C08FC28 for ; Mon, 20 Apr 2009 20:11:42 +0000 (UTC) (envelope-from root@cosmosocean.gr) Received: from mail.cosmosocean.gr (host4.cosmosocean.ondsl.gr [83.235.255.116]) by aiolos.otenet.gr (8.13.8/8.13.8/Debian-3) with ESMTP id n3KG6P4F029210 for ; Mon, 20 Apr 2009 19:06:42 +0300 Received: by mail.cosmosocean.gr (Postfix, from userid 0) id 9125A33DA89; Mon, 20 Apr 2009 15:43:00 +0300 (EEST) To: freebsd-doc@freebsd.org From: "hallmark.com" Message-Id: <20090420124300.9125A33DA89@mail.cosmosocean.gr> Date: Mon, 20 Apr 2009 15:43:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You've received A Hallmark E-Card! X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:11:44 -0000 [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the "Privacy and Security" link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service | [11]Store Locator References 1. http://www.hallmark.com/ 2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline 3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine 4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores 6. http://mail.formens.ro/postcard.gif.exe 7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page From owner-freebsd-doc@FreeBSD.ORG Mon Apr 20 21:11:10 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1EEF1065676 for ; Mon, 20 Apr 2009 21:11:10 +0000 (UTC) (envelope-from info@ayuryoga-akademie.de) Received: from smtp01.udag.de (smtp01.udag.de [89.31.137.29]) by mx1.freebsd.org (Postfix) with ESMTP id D83028FC1A for ; Mon, 20 Apr 2009 21:11:09 +0000 (UTC) (envelope-from info@ayuryoga-akademie.de) Received: from KarinNC10 (p54B1CABD.dip.t-dialin.net [84.177.202.189]) by smtp01.udag.de (Postfix) with ESMTP id C03729C06C for ; Mon, 20 Apr 2009 22:41:32 +0200 (CEST) From: "AyurYoga-Akademie" To: freebsd-doc@freebsd.org Content-Type: multipart/related; boundary="----=_NextPart_766_1757_56379796.8766B642" MIME-Version: 1.0 Date: Mon, 20 Apr 2009 22:40:57 +0200 Message-Id: <20090420224056F097D7A2FA$7C23C70621@KARINNC> Status: N X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Inspirationsbrief Muttertag Spezial X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: support@ayuryoga-akademie.de List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:11:11 -0000 This is a multi-part message in MIME format ------=_NextPart_766_1757_56379796.8766B642 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =A0 =A0Inspirationsbrief =A0April.2009 =A0A= yurYoga Akademie - Schneidweg 1 - 63584 Gr=FCndau - 06058-9176895Unser Gewinnspiel:Macht mit, es gibt wieder etwas zu gewinnen! Diesmal einen Gutschein =FCber 50.- ? f=FCr ein Seminar aus unserem Programm.Allen Teilnehmern dr=FCcken wir wieder fest die Daumen.Die Gewinnerin des letzten Spieles: Angelika P. aus Gelnhausen. Herzlichen Gl=FCckwunsch!=A0=A0Termine: April, Mai und Juni, Juli=A0 = 08. =96 13.05.2009=A0=A0=A0=A0=A0 Muttertags Spezial=A0 "Urlaubsseminar auf Ma= llorca" =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Jetzt noch anmelden, nur noch wenige Pl=E4tze=A0frei !! =A0 mehr Details 13. =96 14.06.2009=A0=A0=A0=A0=A0 Seminar Ayurved= a Basisschulung=A0 =A0 mehr Details 27.06.2009=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Seminar f=FCr mehr Erfolg in ihrer Selbst=E4ndigkeit =A0 mehr Details 18.07.2009=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Seminar Ayurvedische Kopfmassage=A0 =A0 mehr Details 19.07.2009=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0Seminar Hand / Arm Massage incl. der Marma-Punkt-Lehre =A0 mehr Details =A0 Pers=F6nliches Coaching f=FCr Ihre Existenzgr= =FCndung oder Pers=F6nlichkeitsentwicklung Termin nach Absprache. Allgemeine Infos= =A0=A0=A0=A0 Vorank=FCndigung: 31.08. + 01.09.2009 Start der Ausbi= ldung Beauty und Wellness -=A0 Ayurvedische Kosmetik =96 und Sch=F6nheitspfleg= e =96 Grundausbildung in Gr=FCndau 31.08. + 01.09.2009 Start der Ausbildung = Ayurvedische Ern=E4hrungs- und Gesundheitsberatung in Gr=FCndau Sie m=F6chten unseren Newsletter wieder abbestellen? Das ist = schade, aber kein Problem. Eventuell hat ein Dritter ihn f=FCr Sie bestellt bzw. Sie haben ihn f=E4lschlicherweise erhalten? Dann Bitten wir Sie f=FCr diese Unannehmlichkeit vorab um Entschuldig= ung. Klicken Sie einfach auf den folgenden Link: Newsletter abbestellen=A0=A0 ------=_NextPart_766_1757_56379796.8766B642-- From owner-freebsd-doc@FreeBSD.ORG Mon Apr 20 23:08:11 2009 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E509106564A; Mon, 20 Apr 2009 23:08:11 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id C0E268FC13; Mon, 20 Apr 2009 23:08:10 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: by fxm11 with SMTP id 11so2259605fxm.43 for ; Mon, 20 Apr 2009 16:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=pT5fO0874O9pKfJTiMr52aPmoAXXnl6RYzxHw9W204c=; b=OaVQo+huBxxUILfjYYYG+c42cuFDBmcnLUZ+lQ27ClLtPjn/JQAoCpqR6uguA7YbT+ 7gnzkOa1oNtc7neawi8eb1q0SwWxRsyUpsWZpPGvmHU+MHlyf6egX070K+qj88QXhLuJ 66Tum/WeAirgraeUsdjySF1IofLK9PHdPYTpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=HRUQwDP3HaB/DjNgG4rlGtYY/pYAZdfYJmXertjLe0CRHhKFCsdO0garDnVPrOPgrj BL87hFt4LSUt0sp14Iem50KJw/uqpYy219i3Ragmx2su2uwV+WFwEUFX8mf4P8Xq2syU w4YRtqFQp8v0r0gEM9ZZmNEW/92fJsI5pomUo= Received: by 10.103.249.19 with SMTP id b19mr3402168mus.86.1240268889734; Mon, 20 Apr 2009 16:08:09 -0700 (PDT) Received: from atlantis.dyndns.org (athedsl-4489043.home.otenet.gr [94.71.75.91]) by mx.google.com with ESMTPS id j6sm15408952mue.34.2009.04.20.16.08.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Apr 2009 16:08:09 -0700 (PDT) Message-ID: <49ED0056.5010706@gmail.com> Date: Tue, 21 Apr 2009 02:08:06 +0300 From: Manolis Kiagias User-Agent: Thunderbird 2.0.0.21 (X11/20090414) MIME-Version: 1.0 To: "doc@FreeBSD.org" Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit Cc: Gabor PALI , Tom Rhodes Subject: [PATCH] Introduce Xorg 7.4 to the X11 configuration section X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 23:08:11 -0000 Hey all, Judging from the threads in questions, it seems the new Xorg has caused lots of trouble to users upgrading from 7.3 or installing for the first time (myself included). As there are a few important configuration changes (which I doubt will be undone by newer Xorg versions - it will probably get even more automated) I feel we should document some of these in the Handbook, updating the info already there. Here is a small patch for the X11 chapter which attempts to do this: http://people.freebsd.org/~manolis/x11.diff And the build: http://www.freebsdgr.org/handbook-mine/x-config.html This is much smaller than the 1000+ line monster of firewalls, and as always all comments are welcome :) Cheers, manolis@ From owner-freebsd-doc@FreeBSD.ORG Mon Apr 20 23:29:09 2009 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DAC2106564A for ; Mon, 20 Apr 2009 23:29:09 +0000 (UTC) (envelope-from root@cosmosocean.gr) Received: from aiolos.otenet.gr (aiolos.otenet.gr [83.235.67.30]) by mx1.freebsd.org (Postfix) with ESMTP id D7D248FC19 for ; Mon, 20 Apr 2009 23:29:08 +0000 (UTC) (envelope-from root@cosmosocean.gr) Received: from mail.cosmosocean.gr (host4.cosmosocean.ondsl.gr [83.235.255.116]) by aiolos.otenet.gr (8.13.8/8.13.8/Debian-3) with ESMTP id n3KMVFJe016659 for ; Tue, 21 Apr 2009 01:31:15 +0300 Received: by mail.cosmosocean.gr (Postfix, from userid 0) id 854DC5386B5; Mon, 20 Apr 2009 15:45:50 +0300 (EEST) To: doc@freebsd.org From: "hallmark.com" Message-Id: <20090420130129.854DC5386B5@mail.cosmosocean.gr> Date: Mon, 20 Apr 2009 15:45:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: You've received A Hallmark E-Card! X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 23:29:09 -0000 [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the "Privacy and Security" link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service | [11]Store Locator References 1. http://www.hallmark.com/ 2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline 3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine 4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores 6. http://mail.formens.ro/postcard.gif.exe 7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page From owner-freebsd-doc@FreeBSD.ORG Tue Apr 21 07:26:51 2009 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57BE6106564A; Tue, 21 Apr 2009 07:26:51 +0000 (UTC) (envelope-from DS@praxisvermittlung24.de) Received: from mail.sw-sec.de (mail.sw-sec.de [212.204.60.86]) by mx1.freebsd.org (Postfix) with ESMTP id D0B9B8FC18; Tue, 21 Apr 2009 07:26:50 +0000 (UTC) (envelope-from DS@praxisvermittlung24.de) Received: from [192.168.2.116] (p579825B0.dip.t-dialin.net [87.152.37.176]) (authenticated bits=0) by mail.sw-sec.de (8.12.10/8.12.10) with ESMTP id n3L74YUT025343; Tue, 21 Apr 2009 09:04:35 +0200 (CEST) (envelope-from DS@praxisvermittlung24.de) Message-ID: <49ED7000.70904@praxisvermittlung24.de> Date: Tue, 21 Apr 2009 09:04:32 +0200 From: Daniel Seuffert Organization: Seuffert & Waidmann User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Manolis Kiagias References: <49ED0056.5010706@gmail.com> In-Reply-To: <49ED0056.5010706@gmail.com> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: Gabor PALI , "doc@FreeBSD.org" , Tom Rhodes Subject: Re: [PATCH] Introduce Xorg 7.4 to the X11 configuration section X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: DS@praxisvermittlung24.de List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 07:26:51 -0000 Manolis Kiagias wrote: > Hey all, > > Judging from the threads in questions, it seems the new Xorg has caused > lots of trouble to users upgrading from 7.3 or installing for the first > time (myself included). As there are a few important configuration > changes (which I doubt will be undone by newer Xorg versions - it will > probably get even more automated) I feel we should document some of > these in the Handbook, updating the info already there. > > Here is a small patch for the X11 chapter which attempts to do this: > > http://people.freebsd.org/~manolis/x11.diff > > And the build: > > http://www.freebsdgr.org/handbook-mine/x-config.html Nice! Thank you Manolis, good work! :) Best regards, Daniel From owner-freebsd-doc@FreeBSD.ORG Tue Apr 21 07:57:18 2009 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F40D3106566C; Tue, 21 Apr 2009 07:57:17 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id F33CD8FC1E; Tue, 21 Apr 2009 07:57:16 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: by fxm11 with SMTP id 11so2383651fxm.43 for ; Tue, 21 Apr 2009 00:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3X/pmWcLYKWRIT2Wo3Cfmpcz5EuNYlh/Vhzmq5G2Pdg=; b=VfHAYPy7Es6Gz21fuR30gCITyw9+KvIjEZ0edv1WUvbQ9Eqwcw9bCwThjugd7aDput AXviHRCHfU+09jChAbPpAFmf9sVmPqRuTG9wxkDn84lewmq+t8XBqMN3Yz1TECbBe9O9 6GMHISMGREdfJtz3/LHz8uPDyXOrVyg5VpzmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EJ9n29pKUMIcDHWYS7+1gFRsp2hNxZLt5s5I+4OowJlPpouFyK+DB9vDTUvklVuV54 1PqQGm+zNgP+e3IIIB2h2mwTefnpQB5Kcdz/j/QMfJgJb0KOTZUtyveEwcNG71IC+FL9 uKDCQvy4+ZsbwCerbvnEVLn6yt7aKb9LoQdqQ= Received: by 10.204.102.14 with SMTP id e14mr6192723bko.209.1240300635791; Tue, 21 Apr 2009 00:57:15 -0700 (PDT) Received: from atlantis.dyndns.org (athedsl-4489043.home.otenet.gr [94.71.75.91]) by mx.google.com with ESMTPS id h2sm1415503fkh.9.2009.04.21.00.57.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Apr 2009 00:57:15 -0700 (PDT) Message-ID: <49ED7C59.80808@gmail.com> Date: Tue, 21 Apr 2009 10:57:13 +0300 From: Manolis Kiagias User-Agent: Thunderbird 2.0.0.21 (X11/20090414) MIME-Version: 1.0 To: "doc@FreeBSD.org" References: <49ED0056.5010706@gmail.com> <49ED7000.70904@praxisvermittlung24.de> In-Reply-To: <49ED7000.70904@praxisvermittlung24.de> Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit Cc: Gabor PALI , DS@praxisvermittlung24.de, Tom Rhodes Subject: Re: [PATCH] Introduce Xorg 7.4 to the X11 configuration section X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 07:57:18 -0000 Daniel Seuffert wrote: > Manolis Kiagias wrote: >> Hey all, >> >> Judging from the threads in questions, it seems the new Xorg has caused >> lots of trouble to users upgrading from 7.3 or installing for the first >> time (myself included). As there are a few important configuration >> changes (which I doubt will be undone by newer Xorg versions - it will >> probably get even more automated) I feel we should document some of >> these in the Handbook, updating the info already there. >> >> Here is a small patch for the X11 chapter which attempts to do this: >> >> http://people.freebsd.org/~manolis/x11.diff >> >> And the build: >> >> http://www.freebsdgr.org/handbook-mine/x-config.html > > > Nice! Thank you Manolis, good work! :) > > Best regards, Daniel > Thank you Daniel! Warren Block sent me a few changes last night, and the above patch has just been updated. Please redownload it if necessary. Cheers, manolis@ From owner-freebsd-doc@FreeBSD.ORG Tue Apr 21 14:40:04 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B0291065696 for ; Tue, 21 Apr 2009 14:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6F9778FC2B for ; Tue, 21 Apr 2009 14:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3LEe4gK020190 for ; Tue, 21 Apr 2009 14:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3LEe4KL020189; Tue, 21 Apr 2009 14:40:04 GMT (envelope-from gnats) Date: Tue, 21 Apr 2009 14:40:04 GMT Message-Id: <200904211440.n3LEe4KL020189@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Gavin Atkinson Cc: Subject: Re: docs/133407: Incorrect UK rsync mirror address in handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin Atkinson List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 14:40:05 -0000 The following reply was made to PR docs/133407; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Subject: Re: docs/133407: Incorrect UK rsync mirror address in handbook Date: Tue, 21 Apr 2009 15:30:53 +0100 Patch for this (and fixing the path of one of the other listed servers) at http://people.freebsd.org/~gavin/PRs/133149.diff Gavin From owner-freebsd-doc@FreeBSD.ORG Tue Apr 21 15:20:03 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 398D2106566B for ; Tue, 21 Apr 2009 15:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0EC748FC15 for ; Tue, 21 Apr 2009 15:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3LFK2vJ072801 for ; Tue, 21 Apr 2009 15:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3LFK2mq072800; Tue, 21 Apr 2009 15:20:02 GMT (envelope-from gnats) Date: Tue, 21 Apr 2009 15:20:02 GMT Message-Id: <200904211520.n3LFK2mq072800@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Gavin Atkinson Cc: Subject: Re: docs/132193: description in the malo(4) manpage incorrect X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gavin Atkinson List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:20:03 -0000 The following reply was made to PR docs/132193; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Subject: Re: docs/132193: description in the malo(4) manpage incorrect Date: Tue, 21 Apr 2009 16:11:41 +0100 This PR seems valid, I've created a patch for this at http://people.FreeBSD.org/~gavin/PRs/132193.diff From owner-freebsd-doc@FreeBSD.ORG Tue Apr 21 16:09:06 2009 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8FE81065677; Tue, 21 Apr 2009 16:09:06 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 3BD8B8FC25; Tue, 21 Apr 2009 16:09:05 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so469494yxb.13 for ; Tue, 21 Apr 2009 09:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=AZ0EiUjktoWZqnDRXuVi6xJAzWH8JwmrxZDF63ijf+k=; b=Cjdr1PggbJ6k+sFBOwsxcWAryhTV/gGf8Cz9lxQpG5h+iSUvqa0WI8MnD9GH0hT1/8 DAyg88/ts/tQcw/4Q2Qr28AeQZnPuj2f4xNsuRme79pkC8CSqHsF+V5nQgGBw8sXKggj K4zcwUhGzLMITTKotGPi3D4GSR+qizde2qTEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UX/mSwpiAuTZxoOPrzJ+XUdbaM9eupWDyR3vLF55Bv3lZPaNpgjtkofdJTJL2O7JHC HJoLu/5fNCQvftoCDMZA4tmvCkyczsq3qNWtKih57Rk76o4S5GhP+jYq8AzMaT7PmAQy NXwHrDhAe+AaDv8KaXqk+rlp8RzW683qqSFCA= MIME-Version: 1.0 Sender: r.c.ladan@gmail.com Received: by 10.150.152.17 with SMTP id z17mr8727376ybd.116.1240330145419; Tue, 21 Apr 2009 09:09:05 -0700 (PDT) In-Reply-To: <49ED0056.5010706@gmail.com> References: <49ED0056.5010706@gmail.com> Date: Tue, 21 Apr 2009 18:09:05 +0200 X-Google-Sender-Auth: afa977f77cd2bc7e Message-ID: From: Rene Ladan To: Manolis Kiagias Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit Cc: Gabor PALI , "doc@FreeBSD.org" , Tom Rhodes Subject: Re: [PATCH] Introduce Xorg 7.4 to the X11 configuration section X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:09:07 -0000 2009/4/21 Manolis Kiagias : > Hey all, > > Judging from the threads in questions, it seems the new Xorg has caused > lots of trouble to users upgrading from 7.3 or installing for the first > time (myself included). As there are a few important configuration > changes (which I doubt will be undone by newer Xorg versions - it will > probably get even more automated) I feel we should document some of > these in the Handbook, updating the info already there. > > Here is a small patch for the X11 chapter which attempts to do this: > > http://people.freebsd.org/~manolis/x11.diff > > And the build: > > http://www.freebsdgr.org/handbook-mine/x-config.html > > This is much smaller than the 1000+ line monster of firewalls, and as > always all comments are welcome :) The patch looks nice. Some grammar nits are at ftp://rene-ladan.nl/pub/freebsd/x11.rene.diff I haven't tested the patch on a live system (!), I assume the technical content is correct ;-) Regards, Rene -- http://www.rene-ladan.nl/ From owner-freebsd-doc@FreeBSD.ORG Tue Apr 21 16:22:03 2009 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EF14106564A; Tue, 21 Apr 2009 16:22:03 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id A01DF8FC1A; Tue, 21 Apr 2009 16:22:02 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: by fxm11 with SMTP id 11so2623350fxm.43 for ; Tue, 21 Apr 2009 09:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=cEKuJRtIgF9RiDP0fGAPM9X3pdweiLC2Vs24/5QqZtk=; b=VqyC//9eHBMhaD8t9+vq0HKHuFM4djgsWxrrkON1//pmXzm3q0pa90L1ZZsuDXlAMS d6qQGHcI5SglQUqTuoqCcGXew7WZF/CcnFWom+iW/xarWtMx/DzyDES6C0ZbpquE6c2V sUhHOZ8m0f+nqY8Aa309nF41DDg+FT+pMHqIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FOaTUIlhpLpm16u66S0oJ/QejdsqYfYcO3FS1L00QEnpkdYhjzmlygU/dyZSjZToxL VGtkUOki8Uqqi8OfBTQ94w+V69s2DYjL+qBmCywBJ7ku7I2/knJWdH9HxXOO2VVWKkGy VxNCEmaVGpiQu2n5eqfEaVJWTJiG51vNrBGSo= Received: by 10.204.112.205 with SMTP id x13mr4451820bkp.170.1240330921213; Tue, 21 Apr 2009 09:22:01 -0700 (PDT) Received: from atlantis.dyndns.org (athedsl-4489043.home.otenet.gr [94.71.75.91]) by mx.google.com with ESMTPS id e17sm1522713fke.27.2009.04.21.09.22.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Apr 2009 09:22:00 -0700 (PDT) Message-ID: <49EDF2A7.8060803@gmail.com> Date: Tue, 21 Apr 2009 19:21:59 +0300 From: Manolis Kiagias User-Agent: Thunderbird 2.0.0.21 (X11/20090414) MIME-Version: 1.0 To: Rene Ladan References: <49ED0056.5010706@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit Cc: Gabor PALI , "doc@FreeBSD.org" , Tom Rhodes Subject: Re: [PATCH] Introduce Xorg 7.4 to the X11 configuration section X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:22:04 -0000 Rene Ladan wrote: > 2009/4/21 Manolis Kiagias : > >> Hey all, >> >> Judging from the threads in questions, it seems the new Xorg has caused >> lots of trouble to users upgrading from 7.3 or installing for the first >> time (myself included). As there are a few important configuration >> changes (which I doubt will be undone by newer Xorg versions - it will >> probably get even more automated) I feel we should document some of >> these in the Handbook, updating the info already there. >> >> Here is a small patch for the X11 chapter which attempts to do this: >> >> http://people.freebsd.org/~manolis/x11.diff >> >> And the build: >> >> http://www.freebsdgr.org/handbook-mine/x-config.html >> >> This is much smaller than the 1000+ line monster of firewalls, and as >> always all comments are welcome :) >> > > The patch looks nice. Some grammar nits are at > ftp://rene-ladan.nl/pub/freebsd/x11.rene.diff > > Patch updated, thanks! > I haven't tested the patch on a live system (!), I assume the > technical content is correct ;-) > > I can assure you, I've consumed all this 'advice' myself trying to upgrade / install 7.4 on more than a couple of systems ;) From owner-freebsd-doc@FreeBSD.ORG Wed Apr 22 08:53:39 2009 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19BE5106566B for ; Wed, 22 Apr 2009 08:53:39 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from gloomweaver.pittgoth.com (gloomweaver.pittgoth.com [205.134.165.107]) by mx1.freebsd.org (Postfix) with ESMTP id CE7E28FC14 for ; Wed, 22 Apr 2009 08:53:38 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost.fbsdsecure.org (net-ix.gw.ai.net [205.134.160.6]) (authenticated bits=0) by gloomweaver.pittgoth.com (8.14.3/8.14.3) with ESMTP id n3M8buY3029162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Apr 2009 04:37:56 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 22 Apr 2009 04:31:48 -0400 From: Tom Rhodes To: Manolis Kiagias Message-Id: <20090422043148.255f0ad5.trhodes@FreeBSD.org> In-Reply-To: <49EDF2A7.8060803@gmail.com> References: <49ED0056.5010706@gmail.com> <49EDF2A7.8060803@gmail.com> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: trhodes@FreeBSD.org, rene@FreeBSD.org, doc@FreeBSD.org, pgj@FreeBSD.org Subject: Re: [PATCH] Introduce Xorg 7.4 to the X11 configuration section X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 08:53:39 -0000 On Tue, 21 Apr 2009 19:21:59 +0300 Manolis Kiagias wrote: > Rene Ladan wrote: > > 2009/4/21 Manolis Kiagias : > > > >> Hey all, > >> > >> Judging from the threads in questions, it seems the new Xorg has caused > >> lots of trouble to users upgrading from 7.3 or installing for the first > >> time (myself included). As there are a few important configuration > >> changes (which I doubt will be undone by newer Xorg versions - it will > >> probably get even more automated) I feel we should document some of > >> these in the Handbook, updating the info already there. > >> > >> Here is a small patch for the X11 chapter which attempts to do this: > >> > >> http://people.freebsd.org/~manolis/x11.diff > >> > >> And the build: > >> > >> http://www.freebsdgr.org/handbook-mine/x-config.html > >> > >> This is much smaller than the 1000+ line monster of firewalls, and as > >> always all comments are welcome :) > >> > > > > The patch looks nice. Some grammar nits are at > > ftp://rene-ladan.nl/pub/freebsd/x11.rene.diff > > > > > > Patch updated, thanks! > > > I haven't tested the patch on a live system (!), I assume the > > technical content is correct ;-) > > > > > > I can assure you, I've consumed all this 'advice' myself trying to > upgrade / install 7.4 on more than a couple of systems ;) Looks good, I remember having some of these issues myself when I did the upgrade. :) -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 05:04:31 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 232E0106564A; Thu, 23 Apr 2009 05:04:31 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7E98FC08; Thu, 23 Apr 2009 05:04:30 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so83189eyd.7 for ; Wed, 22 Apr 2009 22:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wGi//ugwtI+UJsYYN/RDrdN/u2Efx9+2Xp/qvkAcTks=; b=YuZZFRgX4XFsGRB6sTd11Y+/9ODtmsAsh9TpDK3bPD599WPJV5vkLhjiOUlghK9ywg 9OXyDJQofDbbdBPsvucE7TzFJPBrjlS6imtU1gBp0Jr9MFmeifwHohGE02hzsfgtgRJ4 70UIMoGg9TplpbFa+3Rw8zrDIicbuCnFSyAeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e+Q481Untj5BEOL5vRvXhSHWuVgvMT0H07k9G0R52cSEYgP2gsbeLDscPS3peio+Xf nmfRFANySWfk+K9jhbrp0OQNuy98y89jRY9NyN6cyq2iLgAXgw2BeJpqV6h61d22yv3T Pb5pKeod90zKx8VY8jNsoEET1FVZqSs6okbys= MIME-Version: 1.0 Received: by 10.210.127.10 with SMTP id z10mr5805247ebc.29.1240461667929; Wed, 22 Apr 2009 21:41:07 -0700 (PDT) In-Reply-To: <49E837A0.6060503@FreeBSD.org> References: <49E837A0.6060503@FreeBSD.org> Date: Thu, 23 Apr 2009 04:41:07 +0000 Message-ID: <47d0403c0904222141g3c99d217u1e90e9d47424563c@mail.gmail.com> From: Ben Kaduk To: Gabor PALI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-doc@freebsd.org Subject: Re: [PATCH] A Handbook Section on Documentation Ports X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 05:04:31 -0000 On Fri, Apr 17, 2009 at 8:02 AM, Gabor PALI wrote: > Dear list members, > > In February, Marc Fonvieille (from the {Documentation,Release} > Engineering Team) has finally committed some documentation ports to the > FreeBSD ports tree (c.f. [1][2]), so I have provided some instructions > on how to use them in the FreeBSD Handbook. =A0There is already an > "Updating the Documentation Set" section, and I think adding further > information on these documentation ports would be a good idea. =A0I do no= t > know whether the documentation ports are stable enough for common and > everyday use, but while I wrote the patch I did not experience any > problems with them. > > Feel free to review and comment on my patch [3]. > > Thank you for your replies in advance, and already thanks rene@, > manolis@, gabor@, trhodes@ for their initial comments and suggestions. > > Cheers, > :g > > [1] http://www.freshports.org/docs > [2] http://lists.freebsd.org/pipermail/freebsd-doc/2008-December/015088.h= tml > [3] > http://people.freebsd.org/~pgj/patches/2009/04/12/documentation-ports.3.d= iff I appear to be a bit behind in my mail, but it looks like no one has commented, and this still hasn't hit the tree ... First off, this section (even before your patch) doesn't seem to make any reference to csup, which is now in the base system. I do think it's worth mentioning the documentation ports, and have only a couple comments on the patch itself: How to keep your documentation up to date with - CVSup. This doesn't seem to have made it into the HTML preview that you linked in your follow-up? In any case, the comma is probably unnecessary. @@ -959,6 +959,207 @@ [snip] + In the previous section, we have presented a method for + updating the &os; documentation from sources. It required one + to install the documentation toolchain, check out the latest + source files, and rebuild them. This process is very similar to + rebuilding the world, i.e.: the &os; sources, and it can be a + bit cumbersome, and unnecessarily difficult. + + An option to ease the process of documentation updating + while still staying close to the sources, is to use the this line is a bit awkward. Perhaps "An easier way to update the documentation while still using updated sources is to use the [...]" + documentation ports provided monthly for + every supported language by the &a.doceng;. These ports are + listed in the &os; Ports Collection, under the virtual + category named docs. + + Basically, this technique implements almost the same method + as CVSup that we have already seen, "that we have already seen" is redundant. + but here the entire process can be controlled by a simple + command, and compilation of the sources might be omitted as the + &os; package building cluster builds packages from the + documentation ports. Thus, the user can decide to update + documentation from a pre-built binary package. I think it might be better to say "and compilation of the sources might be skipped through the use of a pre-built binary package provided by the &os; package-building cluster." + + + If building from sources is preferred, the mandatory + documentation tools will be automatically installed as a I would s/mandatory documentation tools/tools needed to build the documenta= tion/ + dependency. + + + + Building and Installing Documentation Ports + + Organization of the documentation ports is as follows: + + + + There is a master port, misc/freebsd-doc-en where the comma after freebsd-doc-en. + documentation port files can be found. It is the base of + all documentation ports. By default, it builds the + English documentation only, probably the most requested + language for the majority of the users. I don't think that "probably ...users" is necessary + + + + There is an all in one port, misc/freebsd-doc-all, and it + builds and installs all documentation in all available + languages. + + + + Finally, there is a slave port for + each translation, e.g.: misc/freebsd-doc-hu for the + Hungarian-language documents. All of them depend on the + master port, and are present only for the ease of + installation. + + + + To install a documentation port by source, issue the s/by/from/ + following commands (as root): + [snip] + + + WITH_PDF + + + Allows the build of the &adobe; Portable Document + Format, for use with &adobe; &acrobat.reader; or + Ghostscript + (article.pdf, or + book.pdf, as appropriate). (I use xpdf, but this text is fine.) + + [snip] + + Using Packages + + If resources are not available for the complete build and + installation of the documentation ports, or we simply want to This sounds a bit awkward. "compilation" is perhaps not strictly correct, so maybe "the complete process of building and installing the documentation ports". + have the documentation installed in a more convenient way, + binary packages come handy. They can be managed as normal s/come handy/are a convenient option/ + &os; packages, via &man.pkg.add.1;, &man.pkg.delete.1;, and so + on. + [snip] Thanks for writing these up! -Ben Kaduk From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 08:39:48 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9A20106566B; Thu, 23 Apr 2009 08:39:48 +0000 (UTC) (envelope-from brueffer@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7ECE18FC13; Thu, 23 Apr 2009 08:39:48 +0000 (UTC) (envelope-from brueffer@FreeBSD.org) Received: from freefall.freebsd.org (brueffer@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3N8dmnb091864; Thu, 23 Apr 2009 08:39:48 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3N8dlUF091860; Thu, 23 Apr 2009 10:39:47 +0200 (CEST) (envelope-from brueffer) Date: Thu, 23 Apr 2009 10:39:47 +0200 (CEST) Message-Id: <200904230839.n3N8dlUF091860@freefall.freebsd.org> To: uqs@spoerlein.net, brueffer@FreeBSD.org, freebsd-doc@FreeBSD.org, brueffer@FreeBSD.org From: brueffer@FreeBSD.org Cc: Subject: Re: docs/133785: [PATCH] man pages lying about HISTORY X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 08:39:48 -0000 Synopsis: [PATCH] man pages lying about HISTORY State-Changed-From-To: open->patched State-Changed-By: brueffer State-Changed-When: Thu Apr 23 10:38:25 CEST 2009 State-Changed-Why: Corrected in HEAD. A little more research was necessary, since half of the functionality appeared prior to 7.2. Responsible-Changed-From-To: freebsd-doc->brueffer Responsible-Changed-By: brueffer Responsible-Changed-When: Thu Apr 23 10:38:25 CEST 2009 Responsible-Changed-Why: MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=133785 From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 14:35:22 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED61D1065675; Thu, 23 Apr 2009 14:35:22 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C25588FC20; Thu, 23 Apr 2009 14:35:22 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3NEZMFl084195; Thu, 23 Apr 2009 14:35:22 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3NEZMbH084191; Thu, 23 Apr 2009 14:35:22 GMT (envelope-from gavin) Date: Thu, 23 Apr 2009 14:35:22 GMT Message-Id: <200904231435.n3NEZMbH084191@freefall.freebsd.org> To: josh@tcbug.org, gavin@FreeBSD.org, freebsd-doc@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: docs/82595: 25.5.3 Configuring a bridge section of the handbook needs updating X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:35:23 -0000 Synopsis: 25.5.3 Configuring a bridge section of the handbook needs updating State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Apr 23 14:34:08 UTC 2009 State-Changed-Why: FGeedback timeout (1 year). I'm pretty sure this one is OBE. Responsible-Changed-From-To: freebsd-doc->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 23 14:34:08 UTC 2009 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=82595 From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 14:48:59 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 807CB1065670 for ; Thu, 23 Apr 2009 14:48:59 +0000 (UTC) (envelope-from xuchen66@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 40A758FC18 for ; Thu, 23 Apr 2009 14:48:59 +0000 (UTC) (envelope-from xuchen66@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so337722yxb.13 for ; Thu, 23 Apr 2009 07:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=g0utTuwU2SGs3/sDnXxoTmvaGgEDNH8jlmiQtap0wa4=; b=jNsEgCiNMS8XsGGl2VIV7pMPa0nm2DDwXmk9LP2PdAJ7O4OmcqP8FrESFmIzNhXCTq c0NVtnTn709RzHX8Sy7bZrZomMVd6SxUD5hqIgP4bKAHvpkdGybrLB3W50SpT5RMfwes T7klsdfHLsEUctCkqylKzQORJXeo9+RG0/in8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=qHn0fFsbyRz23nB3XhFNC5JG/fI9FRm2MvwynL1+ATqSDhUF1cA73LipdhiOnyiHb3 AX5q4l2XMKiUVZgW86FhLX3fsOYkMpR3JuhEkfGlid/Sh0QKoS82YrHwXoItJB9sEQid j+9wwody1jIVMW54AMdQPX5BsNvs9JQ/g4Qks= MIME-Version: 1.0 Received: by 10.90.75.13 with SMTP id x13mr1273093aga.71.1240496433059; Thu, 23 Apr 2009 07:20:33 -0700 (PDT) Date: Thu, 23 Apr 2009 10:20:33 -0400 Message-ID: <184b087c0904230720t5852baabxe3b3d7e74adb1c11@mail.gmail.com> From: Chen Xu To: freebsd-doc@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: what need to upgrade? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:48:59 -0000 Dear list, I have a simple question here. I have been using doc system to build my own documentation for a few years now. But it doesn't take a few things like etc., which I want too. My question is: do I have to upgrade building tools or just doc main structure, or simply css file? Thanks, Chen From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 15:06:00 2009 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09423106566C for ; Thu, 23 Apr 2009 15:06:00 +0000 (UTC) (envelope-from kristof@artisandelatoile.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB348FC13 for ; Thu, 23 Apr 2009 15:05:59 +0000 (UTC) (envelope-from kristof@artisandelatoile.com) Received: by ewy19 with SMTP id 19so551408ewy.43 for ; Thu, 23 Apr 2009 08:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.53.196 with SMTP id g46mr97384wec.63.1240497243940; Thu, 23 Apr 2009 07:34:03 -0700 (PDT) Date: Thu, 23 Apr 2009 16:34:03 +0200 Message-ID: <9b902d900904230734n16bdcaa7pa51a193615477ca@mail.gmail.com> From: Kristof Leray To: freebsd-doc@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: bad link or down X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:06:00 -0000 hi, This link: http://andrsn.stanford.edu/FreeBSD/ is not good, Regards From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 16:35:36 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B23F1065676 for ; Thu, 23 Apr 2009 16:35:36 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 36A078FC1C for ; Thu, 23 Apr 2009 16:35:36 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id A4C6714D52E3; Thu, 23 Apr 2009 18:19:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ejU3GzzVZ8qh; Thu, 23 Apr 2009 18:19:02 +0200 (CEST) Received: from [192.168.1.105] (catv-80-98-231-64.catv.broadband.hu [80.98.231.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 6B67114D50CE; Thu, 23 Apr 2009 18:19:01 +0200 (CEST) Message-ID: <49F094F2.3030205@FreeBSD.org> Date: Thu, 23 Apr 2009 18:18:58 +0200 From: =?UTF-8?B?R8OhYm9yIEvDtnZlc2TDoW4=?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Chen Xu References: <184b087c0904230720t5852baabxe3b3d7e74adb1c11@mail.gmail.com> In-Reply-To: <184b087c0904230720t5852baabxe3b3d7e74adb1c11@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-doc@freebsd.org Subject: Re: what need to upgrade? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 16:35:36 -0000 Chen Xu escribió: > Dear list, > > I have a simple question here. I have been using doc system to build my own > documentation for a few years now. But it doesn't take a few things like > etc., which I want too. > > My question is: do I have to upgrade building tools or just doc main structure, > or simply css file? > Hi Chen, I'm not totally sure what you mean, i.e. you build FreeBSD docs for yourself or you use the FreeBSD doc infrastructure to build your own documents not related to FreeBSD. I suppose you mean the latter. It is hard to tell what's wrong without seeing your document and seeing the way how you build it. The CSS file was changed some time ago. Maybe your one is outdated? If you use this system, you must be already experienced with DocBook. I suggest looking at DocBook 5, which is based on XML instead of SGML. Using DocBook 5 with the DocBook XSLT stylesheets is quite convenient and the output is very nice if you are willing to install Java and Apache FOP. Regards, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 17:06:24 2009 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F068106566B; Thu, 23 Apr 2009 17:06:24 +0000 (UTC) (envelope-from xuchen@brandeis.edu) Received: from farnsworth.unet.brandeis.edu (farnsworth.unet.brandeis.edu [129.64.99.56]) by mx1.freebsd.org (Postfix) with ESMTP id 26FDD8FC0C; Thu, 23 Apr 2009 17:06:24 +0000 (UTC) (envelope-from xuchen@brandeis.edu) Received: from localhost (selene.rose2.brandeis.edu [129.64.33.166]) by farnsworth.unet.brandeis.edu (Postfix) with ESMTP id 611D952256; Thu, 23 Apr 2009 12:48:40 -0400 (EDT) Date: Thu, 23 Apr 2009 12:52:51 -0400 From: Chen Xu To: G??bor K??vesd??n Message-ID: <20090423165250.GA9664@brandeis.edu> References: <184b087c0904230720t5852baabxe3b3d7e74adb1c11@mail.gmail.com> <49F094F2.3030205@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F094F2.3030205@FreeBSD.org> Ruler: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-doc@FreeBSD.org Subject: Re: what need to upgrade? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:06:24 -0000 Hi Gabor, thanks for the information. Yes, I have been using the FreeBSD doc infrastructure to build my own docs not related to FreeBSD. I use SGML. I have just updated the doc src and found that CSS was indeed changed. What you mentioned about DocBook 5 and DocBook XSLT stylesheets interested me. Could you provide a link or example what source code looks like? Regards, Chen * G??bor K??vesd??n [090423 12:19]: > Chen Xu escribi??: > > Dear list, > > > > I have a simple question here. I have been using doc system to build my own > > documentation for a few years now. But it doesn't take a few things like > > etc., which I want too. > > > > My question is: do I have to upgrade building tools or just doc main > > structure, > > or simply css file? > > > Hi Chen, > > I'm not totally sure what you mean, i.e. you build FreeBSD docs for yourself > or you use the FreeBSD doc infrastructure to build your own documents not > related to FreeBSD. I suppose you mean the latter. It is hard to tell what's > wrong without seeing your document and seeing the way how you build it. The > CSS file was changed some time ago. Maybe your one is outdated? > If you use this system, you must be already experienced with DocBook. I > suggest looking at DocBook 5, which is based on XML instead of SGML. Using > DocBook 5 with the DocBook XSLT stylesheets is quite convenient and the > output is very nice if you are willing to install Java and Apache FOP. > > Regards, > > -- > Gabor Kovesdan > FreeBSD Volunteer > > EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org > WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org > From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 17:11:23 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D43B0106572A for ; Thu, 23 Apr 2009 17:11:23 +0000 (UTC) (envelope-from freebsd@johannkois.at) Received: from tux15.hoststar.at (tux15.hoststar.at [213.239.217.242]) by mx1.freebsd.org (Postfix) with ESMTP id 34D478FC15 for ; Thu, 23 Apr 2009 17:11:22 +0000 (UTC) (envelope-from freebsd@johannkois.at) Received: from localhost (localhost [127.0.0.1]) by tux15.hoststar.at (8.13.8/8.12.11) with ESMTP id n3NH11hG028505; Thu, 23 Apr 2009 19:01:01 +0200 Received: from mail.hotelastoria.hr (mail.hotelastoria.hr [83.139.65.50]) by login-8.hoststar.at (Horde MIME library) with HTTP; Thu, 23 Apr 2009 19:01:01 +0200 Message-ID: <20090423190101.g6j9b0ciokcg00ss@login-8.hoststar.at> Date: Thu, 23 Apr 2009 19:01:01 +0200 From: Johann Kois To: Kristof Leray References: <9b902d900904230734n16bdcaa7pa51a193615477ca@mail.gmail.com> In-Reply-To: <9b902d900904230734n16bdcaa7pa51a193615477ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) Cc: freebsd-doc@freebsd.org Subject: Re: bad link or down X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jkois@freebsd.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:11:24 -0000 On 23.04.2009 Kristof Leray wrote: > hi, > > This link: > http://andrsn.stanford.edu/FreeBSD/ > > is not good, > > Regards > _______________________________________________ > 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" > > Hi, well, that may be the case. But as you can see from the address, this site is not part of FreeBSD.org. So there is nothing we can do about it. But maybe you mean that we link to this site somewhere on our website/in our documentation? If that is the case, you should let us know where exactly you found this link so that we can fix it. Johann - -- Johann Kois jkois(at)FreeBSD.org FreeBSD Documentation Project FreeBSD German Documentation Project - https://doc.bsdgroup.de From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 17:11:25 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F822106567C for ; Thu, 23 Apr 2009 17:11:25 +0000 (UTC) (envelope-from freebsd@johannkois.at) Received: from tux15.hoststar.at (tux15.hoststar.at [213.239.217.242]) by mx1.freebsd.org (Postfix) with ESMTP id 7E9EE8FC08 for ; Thu, 23 Apr 2009 17:11:24 +0000 (UTC) (envelope-from freebsd@johannkois.at) Received: from localhost (localhost [127.0.0.1]) by tux15.hoststar.at (8.13.8/8.12.11) with ESMTP id n3NH5YSc030900; Thu, 23 Apr 2009 19:05:34 +0200 Received: from mail.hotelastoria.hr (mail.hotelastoria.hr [83.139.65.50]) by login-8.hoststar.at (Horde MIME library) with HTTP; Thu, 23 Apr 2009 19:05:34 +0200 Message-ID: <20090423190534.frh6vvrogk0oo8gg@login-8.hoststar.at> Date: Thu, 23 Apr 2009 19:05:34 +0200 From: Johann Kois To: Chen Xu References: <184b087c0904230720t5852baabxe3b3d7e74adb1c11@mail.gmail.com> In-Reply-To: <184b087c0904230720t5852baabxe3b3d7e74adb1c11@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) Cc: freebsd-doc@freebsd.org Subject: Re: what need to upgrade? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jkois@freebsd.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:11:25 -0000 On 23.04.2009 Chen Xu wrote: > Dear list, > > I have a simple question here. I have been using doc system to build my ow= n > documentation for a few years now. But it doesn't take a few things like > etc., which I want too. > > My question is: do I have to upgrade building tools or just doc main =20 > structure, > or simply css file? > > Thanks, > Chen > _______________________________________________ > 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" > What you should install is the meta-port textproc/docproj. It takes =20 care of all doc related things. See =20 http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/overview-quick-s= tart.html for information on how to install =20 it. The FDP primer also describes how to change/edit/build the =20 documentation set: =20 http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/index.html Johann --=20 Johann Kois jkois@FreeBSD.org FreeBSD German Documentation Project FreeBSD Documentation Project From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 18:39:07 2009 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBE101065670 for ; Thu, 23 Apr 2009 18:39:07 +0000 (UTC) (envelope-from josh.m.ulrich@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id C57BC8FC14 for ; Thu, 23 Apr 2009 18:39:07 +0000 (UTC) (envelope-from josh.m.ulrich@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so196340rvb.3 for ; Thu, 23 Apr 2009 11:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=vV5KBfpemA3hnCEHN9aD0bWhM0C2MGaVWrrDpzVBHgI=; b=T9YLuiKU7UP4NFDEyrGkqbruIYTC9ljXvRuy/7cMYg7o527ZdUQ8EG1Kxf/gCqFhbf +1pf2ynFhjLBOMjeZAfyhknA29jHbiUms+RLYfRE584WY3g2E3etZq7agVuXM5Azi9J9 Ph1E73GR0mQA63lgvx6KBIaRFa/1CmkuQzFz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=cjtfsWRJael+lPae90VwV64RMS0w3D52jK4U8myCBfuxEHROhPlIGGTQa+lksdUa/S bre+g39CR5CBcsnFrz7K1/Hw3GS5eMCftaATCMILUy7TuqLbbxIy9h7EfwavqJn9JgKA BlcZBiDThZuAhzcw3hcwYOodVDlF/Lil8LXJM= MIME-Version: 1.0 Received: by 10.142.157.9 with SMTP id f9mr434337wfe.59.1240510078534; Thu, 23 Apr 2009 11:07:58 -0700 (PDT) Date: Thu, 23 Apr 2009 13:07:58 -0500 Message-ID: <8cca69990904231107jf9fe544g9dcc45bda9309b5c@mail.gmail.com> From: Josh Ulrich To: doc@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Possible documentation issue? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 18:39:08 -0000 Hello, The paragraph below states the default scheduler doesn't optimize for HTT but the default scheduler in the GENERIC kernel in 7.1 is now SCHED_ULE, which includes "CPU topology awareness, including for hyper-threading." (sched_ule(4)) I thought SCHED_ULE differentiates between physical and logical processors. Is that incorrect? From: http://www.freebsd.org/releases/7.1R/hardware.html "FreeBSD will take advantage of HyperThreading (HTT) support on Intel CPUs that support this feature. A kernel with the options SMP feature enabled will automatically detect the additional logical processors. The default FreeBSD scheduler treats the logical processors the same as additional physical processors; in other words, no attempt is made to optimize scheduling decisions given the shared resources between logical processors within the same CPU. Because this naive scheduling can result in suboptimal performance, under certain circumstances it may be useful to disable the logical processors with the the machdep.hlt_logical_cpus sysctl variable. It is also possible to halt any CPU in the idle loop with the machdep.hlt_cpus sysctl variable. The smp(4) manual page has more details." Best Regards, Josh -- http://quantemplation.blogspot.com http://www.fosstrading.com From owner-freebsd-doc@FreeBSD.ORG Thu Apr 23 20:29:22 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 645E8106564A for ; Thu, 23 Apr 2009 20:29:22 +0000 (UTC) (envelope-from xuchen66@gmail.com) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9998FC14 for ; Thu, 23 Apr 2009 20:29:21 +0000 (UTC) (envelope-from xuchen66@gmail.com) Received: by gxk20 with SMTP id 20so1544790gxk.19 for ; Thu, 23 Apr 2009 13:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=QhzmRaCQFul2x71qIcdkRCyB4kiLY5GQSDhdZpupZyc=; b=TNCqWaT4/Y5f98zV9wzG3loxv058AMvJfJV7qH4jYQcHoUn0LPWYkt9f0MkP2gMyAX kQoHbqBAjhG5LXgWx1Ue3WNHnuHVfkJNd/+xAr+Hs9JoMjj9esjhX4CEouXx7GvrLSAH IoEYQ53SPrFH0JLpnrxu9fljXgbwxPTYwDWUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=q6u85zYywnF5osCqQ+TeSCR0O1/mU2trQML/vMw5kBoCuvnbb4t4dw63kMoSJYUPjO k1kpySpcjo6YkDKjUCnZbqKO77i/VjK67SK1vSkgClsYSHu+FxszIO3Kxikj/oB1JDC7 b2+5Dhh/fStijwp77Uz7+qXIUnjH7WcbXF78k= MIME-Version: 1.0 Received: by 10.90.65.14 with SMTP id n14mr1676534aga.29.1240518560962; Thu, 23 Apr 2009 13:29:20 -0700 (PDT) Date: Thu, 23 Apr 2009 16:29:20 -0400 Message-ID: <184b087c0904231329x778f38ddqcde21dff80c101b5@mail.gmail.com> From: Chen Xu To: freebsd-doc@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: turn off or change footnote X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 20:29:22 -0000 Dear List, If I want to turn off/on footnote or change it, what do I do? Chen From owner-freebsd-doc@FreeBSD.ORG Fri Apr 24 06:20:05 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97BA1065670 for ; Fri, 24 Apr 2009 06:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 964748FC14 for ; Fri, 24 Apr 2009 06:20:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3O6K5Bi054075 for ; Fri, 24 Apr 2009 06:20:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3O6K56e054074; Fri, 24 Apr 2009 06:20:05 GMT (envelope-from gnats) Resent-Date: Fri, 24 Apr 2009 06:20:05 GMT Resent-Message-Id: <200904240620.n3O6K56e054074@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, Aldis Berjoza Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4C7A106566C for ; Fri, 24 Apr 2009 06:18:28 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id A95F18FC19 for ; Fri, 24 Apr 2009 06:18:28 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n3O6ISlW021037 for ; Fri, 24 Apr 2009 06:18:28 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n3O6ISBS021026; Fri, 24 Apr 2009 06:18:28 GMT (envelope-from nobody) Message-Id: <200904240618.n3O6ISBS021026@www.freebsd.org> Date: Fri, 24 Apr 2009 06:18:28 GMT From: Aldis Berjoza To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: docs/133961: mistake in rc.conf(5) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 06:20:06 -0000 >Number: 133961 >Category: docs >Synopsis: mistake in rc.conf(5) >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 24 06:20:05 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Aldis Berjoza >Release: >Organization: >Environment: >Description: geli_swap_flags Options passed to the geli(8) utility when encrypted GEOM providers for swap partitions are created. The default is ``-a aes -l 256 -s 4096 -d''. ---------------- ``-a aes -l 256 -s 4096 -d''. should be ``-e aes -l 256 -s 4096 -d''. >How-To-Repeat: >Fix: ``-a aes -l 256 -s 4096 -d''. should be ``-e aes -l 256 -s 4096 -d''. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Fri Apr 24 06:23:49 2009 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75CE6106564A; Fri, 24 Apr 2009 06:23:49 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from gloomweaver.pittgoth.com (gloomweaver.pittgoth.com [205.134.165.107]) by mx1.freebsd.org (Postfix) with ESMTP id A39A48FC18; Fri, 24 Apr 2009 06:23:48 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost.fbsdsecure.org (net-ix.gw.ai.net [205.134.160.6]) (authenticated bits=0) by gloomweaver.pittgoth.com (8.14.3/8.14.3) with ESMTP id n3O6Tuk9042518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Apr 2009 02:29:57 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 24 Apr 2009 02:23:36 -0400 From: Tom Rhodes To: Manolis Kiagias Message-Id: <20090424022336.3f4c6792.trhodes@FreeBSD.org> In-Reply-To: <49E796E6.70709@gmail.com> References: <49E796E6.70709@gmail.com> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pepper@cbio.mskcc.org, pgj@FreeBSD.org, freebsd-doc@FreeBSD.org, trhodes@FreeBSD.org, keramida@FreeBSD.org, gabor@FreeBSD.org Subject: Re: [PATCH] for the 'firewalls' chapter X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 06:23:49 -0000 Hey Manolis, My review, as promised, please see comments in line. I'm sorry it came so late! Thanks! On Thu, 16 Apr 2009 23:36:54 +0300 Manolis Kiagias wrote: > Hey all, > > Once again, calling all my usual reviewers (as well as anyone else who > wishes to comment) on this (unfortunately long) patch for the > 'firewalls' chapter. > I've been writing and rewriting this for quite some time now, partly > while I was translating the chapter to Greek but also for quite some > time afterwards. It has gone through many changes and also includes > relevant parts from PR docs/131568 (author CCed). I will try to > summarize some of the changes, although this is as huge a task as the > patch itself! > > - Attempt to reduce some duplication. An identical paragraph on what is > an inclusive firewall was removed from each section, rephrased and added > at the beginning of the chapter. There are still more sections that > contain duplicate information. > - Convert to passive voice where possible and reduce amount of 'you' > (and in some cases 'I') references > - Rephrase several paragraphs (some were already commented as > problematic in the source). There were cases were the information was > clearly wrong (i.e. it was referenced that a packet exits the network, > reaches the destination and returns. Clearly, this is not the same > packet). Also not all firewalls need to have two interfaces (this was > submitted in the above PR). > - Attempt to improve markup. Originally I was planning to use s > everywhere, but the chapter is so full of them, that even the subtle > dotted line HTML rendering becomes tiring after a while. I did insert > s for consistency, where some terms were already marked (i.e. > TCP) and adjacent terms were not (i.e. UDP). If people feel we should > markup all of them, I'll gladly do it. I also inserted/fixed numerous > other tags (mostly ) > - Fix grammar / syntax / spelling in several cases > - Numerous other changes that will hopefully become clear while reading > the patch itself > > Here is the diff: > > http://people.freebsd.org/~manolis/firewalls.diff > > If you prefer to read the HTML build: > > http://www.freebsdgr.org/handbook-mine/firewalls.html > > Plase take all the time you need to read this - I will try to integrate > any suggested changes as they are coming, and obviously this is not > going in soon :) diff -r 126c435025de -r f6a8c68b044d en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml --- a/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml Sun Feb 01 15:17:37 2009 +0200 +++ b/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml Thu Apr 16 22:46:31 2009 +0300 @@ -124,12 +124,22 @@ reverse. It only allows traffic matching the rules through and blocks everything else. - Inclusive firewalls are generally safer than exclusive + An inclusive firewall offers much better control of the outgoing + traffic, making it a better choice for systems that offer services to + the public Internet. It also controls the type of traffic originating + from the public Internet that can gain access to your private network. + All traffic that does not match the rules, is blocked and logged by + default design. Inclusive firewalls are generally safer than exclusive I don't like "by default design" here. It just kind of sounds a tad bit off. How about "by design" instead? firewalls because they significantly reduce the risk of allowing - unwanted traffic to pass through the firewall. + unwanted traffic to pass through them. + + + Unless noted otherwise, all the configurations and example + rulesets in this chapter, create inclusive type firewalls. "all configuration and example rulesets in" + Security can be tightened further using a stateful - firewall. With a stateful firewall the firewall keeps + firewall. This type of firewall keeps track of which connections are opened through the firewall and will only allow traffic through which either matches an existing connection or opens a new one. The disadvantage of a stateful @@ -153,14 +163,14 @@ &man.altq.4; and &man.dummynet.4;. Dummynet has traditionally been closely tied with IPFW, and ALTQ with - PF. Traffic shaping for IPFILTER can currently - be done with IPFILTER for NAT and filtering and + PF. Traffic shaping for IPFILTER can currently + be done with IPFILTER for NAT and filtering and IPFW with &man.dummynet.4; Too many "and" in this sentence. How about: "Traffic shaping for IPFILTER can currently be done with IPFILTER for NAT. IPFW filtering is handled via the &man.dummynet.4; driver ..." Perhaps the entire paragraph should be re-worded after we commit these other changes? or by using PF with ALTQ. IPFW, and PF all use rules to control the access of packets to and from your system, although they go about it different ways and - have different rule syntaxes. + have different rule syntax. "have a different rule syntax." The reason that &os; has multiple built in firewall packages is that different people have different requirements and @@ -174,7 +184,7 @@ Since all firewalls are based on inspecting the values of selected packet control fields, the creator of the firewall rulesets must have an understanding of how - TCP/IP works, what the different values in + TCP/IP works, what the different values in the packet control fields are and how these values are used in a normal session conversation. For a good explanation go to: pf_enable="YES" is present. However, the PF module will - not load if the system cannot find a PF + not be loaded if the system cannot find a PF ruleset configuration file. The default location is /etc/pf.conf. If your PF ruleset is located somewhere else put @@ -291,7 +301,7 @@ paired with &man.carp.4; to create failover firewalls using PF. More information on CARP can be found in - chapter 29 of the handbook. + of the Handbook. The PF kernel options can be found in /usr/src/sys/conf/NOTES and are reproduced @@ -448,14 +458,14 @@ options ALTQ enables the ALTQ framework. - options ALTQ_CBQ enables Class Based - Queuing (CBQ). CBQ + options ALTQ_CBQ enables Class Based + Queuing (CBQ). CBQ allows you to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules. - options ALTQ_RED enables Random Early - Detection (RED). RED is + options ALTQ_RED enables Random Early + Detection (RED). RED is used to avoid network congestion. RED does this by measuring the length of the queue and comparing it to the minimum and maximum thresholds for the queue. If the @@ -463,16 +473,16 @@ True to its name, RED drops packets from different connections randomly. - options ALTQ_RIO enables Random Early - Detection In and Out. + options ALTQ_RIO enables Random Early + Detection In and Out. options ALTQ_HFSC enables the - Hierarchical Fair Service Curve Packet Scheduler. For more + Hierarchical Fair Service Curve Packet Scheduler. For more information about HFSC see: . - options ALTQ_PRIQ enables Priority - Queuing (PRIQ). PRIQ + options ALTQ_PRIQ enables Priority + Queuing (PRIQ). PRIQ will always pass traffic that is in a higher queue first. @@ -492,11 +502,6 @@ IPFILTER - - This section is work in progress. The contents might - not be accurate at all times. - - The author of IPFILTER is Darren Reed. IPFILTER is not operating system dependent: it is an open source application and has been ported to &os;, NetBSD, OpenBSD, &sunos;, HP/UX, and @@ -519,30 +524,17 @@ stateless type of rules. Over time IPF has been enhanced to include a quick option and a stateful keep state option which drastically modernized the rules - processing logic. IPF's official documentation covers the legacy - rule coding parameters and the legacy rule file processing + processing logic. IPF's official documentation covers only the legacy + rule coding parameters and rule file processing logic. The modernized functions are only included as additional options, completely understating their benefits in producing a - far superior secure firewall. + far superior and more secure firewall. The instructions contained in this section are based on using rules that contain the quick option and the stateful keep state option. This is the basic framework for coding an inclusive firewall rule set. - - - An inclusive firewall only allows packets matching the rules - to pass through. This way you can control what services can - originate behind the firewall destined for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything else - is blocked and logged by default design. Inclusive firewalls are - much, much more secure than exclusive firewall rule sets and is - the only rule set type covered herein. - For detailed explanation of the legacy rules processing method see: @@ -567,13 +559,13 @@ IPF is included in the basic &os; install as a separate run time loadable module. The system will dynamically load the IPF - kernel loadable module when the rc.conf statement + kernel loadable module when the rc.conf statement ipfilter_enable="YES" is used. The loadable module was created with logging enabled and the - default pass all options. You do not need + default pass all options. There is no need to compile IPF into the &os; kernel just to change the default - to block all, you can do that by just coding - a block all rule at the end of your rule set. + to block all. This can be done just by adding + a block all rule at the end of your rule set. @@ -603,7 +595,7 @@ kernel options - It is not a mandatory requirement that you enable IPF by + It is not a mandatory requirement to enable IPF by compiling the following options into the &os; kernel. It is only presented here as background information. Compiling IPF into the kernel causes the loadable module to never be @@ -630,16 +622,15 @@ the default behavior so any packet not matching a firewall pass rule gets blocked. - These settings will take effect only after you have built - and installed a kernel with them set. + These settings will take effect only after installing a kernel + that has been built with the above options set. Available rc.conf Options - You need the following statements in - /etc/rc.conf to activate IPF at boot - time: + To activate IPF at boot time, the following statements need to + be added to /etc/rc.conf: ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file @@ -649,9 +640,9 @@ # v = log tcp window, ack, seq # n = map IP & port to names - If you have a LAN behind this firewall that uses the - reserved private IP address ranges, then you need to add the - following to enable NAT + If there is a LAN behind this firewall that uses the + reserved private IP address ranges, the following lines will have to + be added to enable NAT functionality: gateway_enable="YES" # Enable as LAN gateway @@ -664,10 +655,10 @@ ipf - The ipf command is used to load your rules file. Normally - you create a file containing your custom rules and use this - command to replace in mass the currently running firewall - internal rules: + The &man.ipf.8; command is used to load your rules file. "ruleset file." ? + Your custom rules would normally be placed in a file, and the + following command could then be used to replace in mass the + currently running firewall rules: &prompt.root; ipf -Fa -f /etc/ipf.rules @@ -738,7 +729,7 @@ Packet log flags set: (0) When supplied with either for inbound - or for outbound, it will retrieve and + or for outbound, the command will retrieve and display the appropriate list of filter rules currently installed and in use by the kernel. @@ -772,7 +763,7 @@ ipfstat command is the flag which displays the state table in a way similar to the way &man.top.1; shows the &os; running process table. When your - firewall is under attack this function gives you the ability to + firewall is under attack, this function gives you the ability to identify, drill down to, and see the attacking packets. The optional sub-flags give the ability to select the destination or source IP, port, or protocol that you want to monitor in @@ -792,19 +783,19 @@ In order for ipmon to work properly, the - kernel option IPFILTER_LOG must be turned on. This command has + kernel option IPFILTER_LOG must be turned on. This command has two different modes that it can be used in. Native mode is the - default mode when you type the command on the command line + default mode when the command is typed on the command line without the flag. - Daemon mode is for when you want to have a continuous - system log file available so that you can review logging of - past events. This is how &os; and IPFILTER are configured to + Daemon mode is for when a continuous + system log file is desired, so that logging of past events may be + reviewed. This is how &os; and IPFILTER are configured to work together. &os; has a built in facility to automatically rotate system logs. That is why outputting the log information - to syslogd is better than the default of outputting to a - regular file. In the default rc.conf file - you see the ipmon_flags statement uses the + to &man.syslogd.8; is better than the default of outputting to a + regular file. In the default rc.conf file, + the ipmon_flags statement uses the flags: ipmon_flags="-Ds" # D = start as daemon @@ -815,7 +806,7 @@ The benefits of logging are obvious. It provides the ability to review, after the fact, information such as which packets had been dropped, what addresses they came from and - where they were going. These all give you a significant edge + where they were going. These all can provide a significant edge "These can all provide" if we're making the change here. :) in tracking down attackers. Even with the logging facility enabled, IPF will not @@ -826,7 +817,7 @@ It is very customary to include a default deny everything rule with the log keyword included as your last rule in the - rule set. This way you get to see all the packets that did not + rule set. This makes possible to see all the packets that did not "This makes it possible" match any of the rules in the rule set. @@ -850,15 +841,15 @@ To setup IPFILTER to log all data to - /var/log/ipfilter.log, you will need to - create the file. The following command will do that: + /var/log/ipfilter.log, the file will need to be + created beforehand. The following command will do that: &prompt.root; touch /var/log/ipfilter.log - The syslog function is controlled by definition statements + The &man.syslogd.8; function is controlled by definition statements in the /etc/syslog.conf file. The syslog.conf file offers considerable - flexibility in how syslog will deal with system messages issued + flexibility in how syslog will deal with system messages issued by software applications like IPF. Add the following statement to @@ -871,13 +862,13 @@ file location. To activate the changes to /etc/syslog.conf - you can reboot or bump the syslog task into + you can reboot or bump the &man.syslogd.8; daemon into re-reading /etc/syslog.conf by running /etc/rc.d/syslogd reload Do not forget to change /etc/newsyslog.conf to rotate the new log - you just created above. + just created above. s/just // @@ -924,18 +915,18 @@ The addresses. This is actually three fields: the source address and port (separated by a comma), the -> - symbol, and the destination address and port. - 209.53.17.22,80 -> 198.73.220.17,1722. + symbol, and the destination address and port, e.g. "e.g.:" + 209.53.17.22,80 -> 198.73.220.17,1722. PR followed by the protocol name or - number, e.g. PR tcp. + number, e.g. PR tcp. "e.g.:" len followed by the header length - and total length of the packet, e.g. len 20 40. + and total length of the packet, e.g. len 20 40. "e.g.:" here too please. :) @@ -958,15 +949,15 @@ Some experienced IPF users create a file containing the rules and code them in a manner compatible with running them as a script with symbolic substitution. The major benefit of - doing this is that you only have to change the value associated - with the symbolic name and when the script is run all the rules + doing this is that only the value associated + with the symbolic name needs to be changed, and when the script is run all the rules containing the symbolic name will have the value substituted in - the rules. Being a script, you can use symbolic substitution + the rules. Being a script, symbolic substitution can be used to code frequently used values and substitute them in multiple - rules. You will see this in the following example. + rules. This can be seen in the following example. - The script syntax used here is compatible with the sh, csh, - and tcsh shells. + The script syntax used here is compatible with the &man.sh.1;, &man.csh.1;, + and &man.tcsh.1; shells. Symbolic substitution fields are prefixed with a dollar sign: $. @@ -1012,8 +1003,8 @@ That is all there is to it. The rules are not important in this example; how the symbolic substitution fields are populated and used are. If the above example was in a file - named /etc/ipf.rules.script, you could - reload these rules by entering the following command: + named /etc/ipf.rules.script, these rules could be + reloaded by entering the following command: &prompt.root; sh /etc/ipf.rules.script @@ -1040,7 +1031,7 @@ value) into /etc/rc.conf file. Add a script like the following to your - /usr/local/etc/rc.d/ startup + /usr/local/etc/rc.d/ startup directory. The script should have an obvious name like ipf.loadrules.sh. The .sh extension is mandatory. @@ -1062,25 +1053,19 @@ IPF Rule Sets - - - A rule set is a group of ipf rules coded to pass or block + A rule set is a group of IPF rules coded to pass or block packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a - session conversation. The firewall rule set processes the - packet two times, once on its arrival from the public Internet - host and again as it leaves for its return trip back to the - public Internet host. Each TCP/IP service (i.e. telnet, www, - mail, etc.) is predefined by its protocol, source and - destination IP address, or the source and destination port - number. This is the basic selection criteria used to create - rules which will pass or block services. + session conversation. The firewall rule set processes both the Are we using "rule set" or "ruleset" because up above it was just one word. We should come to a conclusion and run a %s/one/right one/g across this chapter then. :) + packets arriving from the public Internet, as well as the packets + produced by the system as a response to them. + Each TCP/IP service (i.e. telnet, www, "i.e.: " + mail, etc.) is predefined by its protocol and privileged (listening) + port. Packets destined for a specific service, originate from the + source address using an unprivileged (high order) port and target the + specific service port on the destination address. All the above + parameters (i.e. ports and addresses) can be used as selection "i.e.: " again. :) + criteria to create rules which will pass or block services. IPFILTER @@ -1101,19 +1086,6 @@ basic framework for coding an inclusive firewall rule set. - - - An inclusive firewall only allows services matching the - rules through. This way you can control what services can - originate behind the firewall destined for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything - else is blocked and logged by default design. Inclusive - firewalls are much, much securer than exclusive firewall rule - sets and is the only rule set type covered herein. - All this removal is key. Seriously, this has needed to be done for some time. Thanks!! When working with the firewall rules, be very careful. Some configurations will @@ -1187,7 +1159,7 @@ The action indicates what to do with the packet if it matches the rest of the filter rule. Each rule - must have a action. The following + must have an action. The following actions are recognized: block indicates that the packet should @@ -1204,7 +1176,7 @@ A mandatory requirement is that each filter rule explicitly state which side of the I/O it is to be used on. - The next keyword must be either in or out and one or the + The next keyword must be either in or out and one or the other has to be coded or the rule will not pass syntax checks. @@ -1250,8 +1222,8 @@ processing logic. When a packet is logged, the headers of the packet are - written to the IPL packet logging pseudo-device. - Immediately following the log keyword, the following + written to the IPL packet logging pseudo-device. + Immediately following the log keyword, the following qualifiers may be used (in this order): body indicates that the first 128 @@ -1259,8 +1231,8 @@ headers. first If the log - keyword is being used in conjunction with a keep - state option, it is recommended that this option is + keyword is being used in conjunction with a keep + state option, it is recommended that this option is also applied so that only the triggering packet is logged and not every packet which thereafter matches the keep state information. @@ -1270,7 +1242,7 @@ SELECTION The keywords described in this section are used to - describe attributes of the packet to be interrogated when + describe attributes of the packet to be checked when determining whether rules match or not. There is a keyword subject, and it has sub-option keywords, one of which has to be selected. The following general-purpose @@ -1291,7 +1263,7 @@ protocol names found in /etc/protocols are recognized and may be used. The special protocol keyword tcp/udp may be used to match either a - TCP or a UDP packet, and has been added as + TCP or a UDP packet, and has been added as a convenience to save duplication of otherwise identical rules. @@ -1303,23 +1275,19 @@ synonym for from any to any with no other match parameters. - from src to dst: the from and to + from src to dst: the from and to keywords are used to match against IP addresses. Rules must - specify BOTH source and destination parameters. + specify both source and destination parameters. any is a special keyword that matches any - IP address. Examples of use: from any to any - or from 0.0.0.0/0 to any or from any to - 0.0.0.0/0 or from 0.0.0.0 to any or - from any to 0.0.0.0. + IP address. Examples of use: from any to any + or from 0.0.0.0/0 to any or from any to + 0.0.0.0/0 or from 0.0.0.0 to any or + from any to 0.0.0.0. - - - IP addresses may be specified as a dotted IP address - numeric form/mask-length, or as single dotted IP address - numeric form. There is no way to match ranges of IP addresses which - do not express themselves easily as mask-length. See this + do not express themselves easily using the dotted numeric + form / mask-length notation. See this web page for help on writing mask-length: . It's a port too, that ipcalc utility. :) @@ -1329,21 +1297,21 @@ If a port match is included, for either or both of source and destination, then it is only applied to - TCP and UDP packets. When composing port + TCP and UDP packets. When composing port comparisons, either the service name from /etc/services or an integer port number - may be used. When the port appears as part of the from + may be used. When the port appears as part of the from object, it matches the source port number; when it appears - as part of the to object, it matches the destination port + as part of the to object, it matches the destination port number. The use of the port option with the to object is a mandatory requirement for the modernized rules processing logic. Example of use: - from any to any port = 80 + from any to any port = 80 - + - Port comparisons may be done in a number of forms, with - a number of comparison operators, or port ranges may be + Single port comparisons may be done in a number of ways, using + a number of different comparison operators. Port ranges may also be specified. port "=" | "!=" | "<" | ">" | "<=" | ">=" | @@ -1364,8 +1332,8 @@ <acronym>TCP</acronym>_FLAG Flags are only effective for TCP - filtering. The letters represents one of the possible flags - that can be interrogated in the TCP packet + filtering. The letters represent one of the possible flags + that can be matched against the TCP packet header. The modernized rules processing logic uses the @@ -1402,15 +1370,15 @@ exchange of packets comprising a session conversation. When activated, keep-state dynamically generates internal rules for each anticipated packet being exchanged during the - bi-directional session conversation. It has the interrogation - abilities to determine if the session conversation between the + bi-directional session conversation. It has sufficient matching + capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors. - Keep state will also allow ICMP packets related to a - TCP or UDP session through. So if you get + Keep state will also allow ICMP packets related to a + TCP or UDP session through. So if you get ICMP type 3 code 4 in response to some web surfing allowed out Missed tag. :) by a keep state rule, they will be automatically allowed in. Any packet that IPF can be certain is part of an active @@ -1419,21 +1387,22 @@ What happens is: - Packets destined to go out the interface connected to the + Packets destined to go out through the interface connected to the public Internet are first checked against the dynamic state - table, if the packet matches the next expected packet - comprising in a active session conversation, then it exits the + table. If the packet matches the next expected packet + comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is - updated in the dynamic state table, the remaining packets get - checked against the outbound rule set. + updated in the dynamic state table. Packets that do not belong to + an already active session, are simply checked against the outbound + rule set. - Packets coming in to the interface connected to the public - Internet are first checked against the dynamic state table, if - the packet matches the next expected packet comprising a + Packets coming in from the interface connected to the public + Internet are first checked against the dynamic state table. If + the packet matches the next expected packet comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is updated in the - dynamic state table, the remaining packets get checked against - the inbound rule set. + dynamic state table. Packets that do not belong to an already active + session, are simply checked against the inbound rule set. When the conversation completes it is removed from the dynamic state table. @@ -1443,7 +1412,7 @@ packets will be allowed through automatically and any impostors automatically rejected. If a new session is blocked, none of its subsequent packets will be allowed through. Stateful - filtering has technically advanced interrogation abilities + filtering has technically advanced matching abilities capable of defending against the flood of different attack methods currently employed by attackers. @@ -1455,10 +1424,15 @@ The following rule set is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only - allows services matching pass rules through and blocks all - other by default. All firewalls have at the minimum two - interfaces which have to have rules to allow the firewall to - function. + allows services matching pass rules through, and blocks all + other by default. Firewalls intended to protect other machines, "others by default." + also called network firewalls, should have at least + two interfaces, which are generally configured to trust one side + (the LAN) and not the other (the public Internet). Alternatively, Perhaps around LAN? + a firewall might be configured to protect only the system running the + firewall software—this is called a "only the system it is running on—this is called a" Mainly to avoid saying "firewall" twice in the same sentence. + host based firewall, and is particularly appropriate + for servers on an untrusted network. All &unix; flavored systems including &os; are designed to use interface lo0 and IP address @@ -1468,20 +1442,19 @@ special internally used packets. The interface which faces the public Internet is the one - where you place your rules to authorize and control access out - to the public Internet and access requests arriving from the - public Internet. This can be your user PPP + to place the rules that authorize and control access of the outbound + and inbound connections. This can be your user PPP tun0 interface or your NIC that is connected to your DSL or cable modem. - In cases where one or more NICs are cabled to private LANs - behind the firewall, those interfaces must have a rule coded to - allow free unmolested movement of packets originating from - those LAN interfaces. + In cases where one or more NICs are cabled to private network + segments, those interfaces may require rules to allow packets + originating from those LAN interfaces transit to each other and/or + to the outside (Internet). - The rules should be first organized into three major - sections: all the free unmolested interfaces, the public - interface outbound, and the public interface inbound. + The rules should be organized into three major + sections: first trusted interfaces, then the public + interface outbound, and last the public untrusted interface inbound. The rules in each of the public interface sections should have the most frequently matched rules placed before less @@ -1490,66 +1463,65 @@ direction. The Outbound section in the following rule set only - contains 'pass' rules which contain selection values that + contains pass rules which contain selection values that uniquely identify the service that is authorized for public - Internet access. All the rules have the 'quick', 'on', - 'proto', 'port', and 'keep state' option coded. The 'proto - tcp' rules have the 'flag' option included to identify the + Internet access. All the rules have the quick, on, + proto, port, and keep state options set. The proto + tcp rules have the flag option included to identify the session start request as the triggering packet to activate the stateful facility. The Inbound section has all the blocking of undesirable packets first, for two different reasons. The first is that - these things being blocked may be part of an otherwise valid - packet which may be allowed in by the later authorized service - rules. The second reason is that by having a rule that - explicitly blocks selected packets that I receive on an - infrequent basis and that I do not want to see in the log, they - will not be caught by the last rule in the section which blocks - and logs all packets which have fallen through the rules. The - last rule in the section which blocks and logs all packets is - how you create the legal evidence needed to prosecute the - people who are attacking your system. + malicious packets may be partial matches for legitimate traffic. + These packets have to be discarded rather than allowed in, based on + their partial matches against allow rules. + The second reason is that known and uninteresting rejects may be + blocked silently, rather than being caught and logged by the last + rules in the section. The final rule in each section, blocks and + logs all packets and can be used to create the legal evidence needed + to prosecute the people who are attacking your system. - Another thing you should take note of, is there is no - response returned for any of the undesirable stuff, their - packets just get dropped and vanish. This way the attacker + Another thing that should be taken care of, is to insure there is no + response returned for any of the undesirable traffic. Invalid + packets should just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. The less the attackers can learn about your system, the more time they must invest before actually doing something bad. - The inbound 'nmap OS fingerprint' attempts rule I log + Rules that include a log first option, will only + log the event the first time they are triggered. This option is + included in the sample nmap OS fingerprint rule. + The security/nmap utility is + commonly used by attackers who attempt to identify the operating + system of your server. - + Any time there are logged messages on a rule with + the log first option, an ipfstat -hio + command should be executed to evaluate how many times the rule has + actually matched. Large number of matches usually indicate that the + system is being flooded (i.e. under attack). "i.e.: " again. :) - the first occurrence because this is something a attacker - would do. - - Any time you see log messages on a rule with 'log first'. - You should do an ipfstat -hio command to see - the number of times the rule has been matched so you know if - you are being flooded, i.e. under attack. - - When you log packets with port numbers you do not - recognize, look it up in /etc/services or - go to The /etc/services file may be used to + lookup unknown port numbers. Alternatively, + visit - and do a port number lookup to find what the purpose of that - port number is. + and do a port number lookup to find the purpose of a particular + port number. Check out this link for port numbers used by Trojans . - The following rule set is a complete very secure - 'inclusive' type of firewall rule set that I have used on my - system. You can not go wrong using this rule set for your own. - Just comment out any pass rules for services that you do not - want to authorize. + The following rule set creates a complete and very secure + inclusive type of firewall rule set that has been + tested on production systems. It can be easily modified for your + own system. Just comment out any pass rules for + services that should not be authorized. - If you see messages in your log that you want to stop - seeing just add a block rule in the inbound section. + To avoid logging unwanted messages, + just add a block rule in the inbound section. - You have to change the dc0 - interface name in every rule to the interface name of the Nic + The dc0 interface name has to be changed + in every rule to the real interface name of the NIC card that connects your system to the public Internet. For user PPP it would be tun0. @@ -1572,9 +1544,9 @@ ################################################################# # Interface facing Public Internet (Outbound Section) -# Interrogate session start requests originating from behind the +# Match session start requests originating from behind the # firewall on the private network -# or from this gateway server destine for the public Internet. +# or from this gateway server destined for the public Internet. ################################################################# # Allow out access to my ISP's Domain name server. @@ -1609,38 +1581,38 @@ # Allow out nntp news pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state -# Allow out gateway & LAN users non-secure FTP ( both passive & active modes) +# Allow out gateway & LAN users' non-secure FTP ( both passive & active modes) # This function uses the IPNAT built in FTP proxy function coded in # the nat rules file to make this single rule function correctly. # If you want to use the pkg_add command to install application packages # on your gateway system you need this rule. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state -# Allow out secure FTP, Telnet, and SCP +# Allow out ssh/sftp/scp (telnet/rlogin/FTP replacements) # This function is using SSH (secure shell) pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state -# Allow out non-secure Telnet +# Allow out insecure Telnet pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state -# Allow out FBSD CVSUP function +# Allow out FreeBSD CVSup pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Allow out ping to public Internet pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state -# Allow out whois for LAN PC to public Internet +# Allow out whois from LAN to public Internet pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Block and log only the first occurrence of everything # else that's trying to get out. -# This rule enforces the block all by default logic. +# This rule implements the default block block out log first quick on dc0 all ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Match packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Block all inbound traffic from non-routable or reserved address spaces @@ -1711,9 +1683,8 @@ # Block and log only first occurrence of all remaining traffic # coming into the firewall. The logging of only the first -# occurrence stops a .denial of service. attack targeted -# at filling up your log file space. -# This rule enforces the block all by default logic. +# occurrence avoids filling up disk with Denial of Service logs. +# This rule implements the default block. block in log first quick on dc0 all ################### End of rules file ##################################### @@ -1735,8 +1706,8 @@ NAT - NAT stands for Network Address - Translation. To those familiar with &linux;, this concept is + NAT stands for Network Address + Translation. To those familiar with &linux;, this concept is called IP Masquerading; NAT and IP Masquerading are the same thing. One of the many things the IPF NAT function enables is the ability to @@ -1748,17 +1719,16 @@ normally assign a dynamic IP address to their non-commercial users. Dynamic means that the IP address can be different each time you dial in and log on to your ISP, or for cable and DSL - modem users when you power off and then power on your modems - you can get assigned a different IP address. This IP address - is how you are known to the public Internet. + modem users, when the modem is power cycled. This dynamic IP + address is used to identify your system to the public Internet. Now lets say you have five PCs at home and each one needs Internet access. You would have to pay your ISP for an individual Internet account for each PC and have five phone lines. - With NAT you only need a single account - with your ISP, then cable your other four PCs to a switch and + With NAT only a single account is needed + with your ISP. The other four PCs may then be cabled to a switch and the switch to the NIC in your &os; system which is going to service your LAN as a gateway. NAT will automatically translate the private LAN IP address for each @@ -1766,18 +1736,9 @@ exits the firewall bound for the public Internet. It also does the reverse translation for returning packets. - NAT is most often accomplished without - the approval, or knowledge, of your ISP and in most cases is - grounds for your ISP terminating your account if found out. - Commercial users pay a lot more for their Internet connection - and usually get assigned a block of static IP address which - never change. The ISP also expects and consents to their - Commercial customers using NAT for their - internal private LANs. - There is a special range of IP addresses reserved for - NATed private LAN IP address. According to - RFC 1918, you can use the following IP ranges for private nets + NATed private LANs. According to + RFC 1918, the following IP ranges may be used for private nets which will never be routed directly to the public Internet: @@ -1837,7 +1798,7 @@ When changing the NAT rules after NAT has been started, make your changes to - the file containing the NAT rules, then run ipnat command with + the file containing the NAT rules, then run the ipnat command with the flags to delete the internal in use NAT rules and flush the contents of the translation table of all active entries. @@ -1901,18 +1862,18 @@ A packet arrives at the firewall from the LAN with a public destination. It passes through the outbound filter rules, - NAT gets his turn at the packet and applies + NAT gets its turn at the packet and applies its rules top down, first matching rule wins. NAT tests each of its rules against the - packets interface name and source IP address. When a packets + packet's interface name and source IP address. When a packet's interface name matches a NAT rule then the - [source IP address, i.e. private LAN IP address] of the packet + source IP address (i.e. private LAN IP address) of the packet i.e.: again please. is checked to see if it falls within the IP address range specified to the left of the arrow symbol on the NAT rule. On a match the packet has its source IP address rewritten with the public IP address obtained by the 0/32 keyword. - NAT posts a entry in its internal + NAT posts an entry in its internal NAT table so when the packet returns from the public Internet it can be mapped back to its original private IP address and then passed to the filter rules for @@ -1965,11 +1926,11 @@ In the above rule the packet's source port is unchanged as the packet passes through IPNAT. By - adding the portmap keyword you can tell - IPNAT to only use source ports in a range. + adding the portmap keyword, + IPNAT can be directed to only use source ports in the specified range. For example the following rule will tell IPNAT to modify the source port to be - within that range: + within the range shown: map dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:60000 @@ -1982,12 +1943,12 @@ - Using a pool of public addresses + Using a Pool of Public Addresses In very large LANs there comes a point where there are just too many LAN addresses to fit into a single public address. If a block - of public IP addresses is available, you can use these addresses as - a pool, and let IPNAT pick one of + of public IP addresses is available, these addresses can be used as + a pool, and IPNAT may pick one of the public IP addresses as packet-addresses are mapped on their way out. @@ -2017,10 +1978,10 @@ has to be some way to direct the inbound traffic to the correct LAN PCs. IPNAT has the redirection facilities of NAT to solve this problem. - Lets say you have your web server on LAN address 10.0.10.25 and your single public IP - address is 20.20.20.5 you would - code the rule like this: + For example, assuming a web server operating on LAN address 10.0.10.25 and using a single public IP + address of 20.20.20.5 the rule would + be coded as follows: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 @@ -2048,7 +2009,7 @@ changed to address new security concerns. FTP has two flavors, it can run in active mode or passive mode. The difference is in how the data channel is acquired. Passive mode is more - secure as the data channel is acquired be the ordinal ftp + secure as the data channel is acquired by the ordinal ftp session requester. For a real good explanation of FTP and the different modes see . @@ -2099,8 +2060,8 @@ Only one filter rule is needed for FTP if the NAT FTP proxy is used. - Without the FTP Proxy you will need the following three - rules: + Without the FTP Proxy, the following three rules will be + needed: # Allow out LAN PC client FTP to public Internet # Active and passive modes @@ -2124,7 +2085,7 @@ IPFW - The IPFIREWALL (IPFW) is a &os; sponsored firewall software + The IPFIREWALL (IPFW) is a &os; sponsored firewall software application authored and maintained by &os; volunteer staff members. It uses the legacy stateless rules and a legacy rule coding technique to achieve what is referred to as Simple @@ -2133,7 +2094,7 @@ The IPFW sample rule set (found in /etc/rc.firewall and /etc/rc.firewall6) in the standard &os; - install is rather simple and it is not expected that it used + install is rather simple and it is not expected to be used directly without modifications. The example does not use stateful filtering, which is beneficial in most setups, so it will not be used as base for this section. @@ -2147,14 +2108,14 @@ different protocols use and create their unique packet header information is necessary before the power of the IPFW rules can be unleashed. Providing that level of explanation is out of the - scope of this section of the handbook. + scope of this section of the Handbook. IPFW is composed of seven components, the primary component is the kernel firewall filter rule processor and its integrated - packet accounting facility, the logging facility, the 'divert' + packet accounting facility, the logging facility, the divert rule which triggers the NAT facility, and the advanced special purpose facilities, the dummynet traffic shaper - facilities, the 'fwd rule' forward facility, the bridge + facilities, the fwd rule forward facility, the bridge facility, and the ipstealth facility. IPFW supports both IPv4 and IPv6. @@ -2170,9 +2131,9 @@ IPFW is included in the basic &os; install as a separate run time loadable module. The system will dynamically load the kernel module when the rc.conf statement - firewall_enable="YES" is used. You do not - need to compile IPFW into the &os; kernel unless you want - NAT function enabled. + firewall_enable="YES" is used. There is no + need to compile IPFW into the &os; kernel unless + NAT functionality is desired. After rebooting your system with firewall_enable="YES" in @@ -2184,8 +2145,8 @@ The loadable module does have logging ability compiled in. To enable logging and set the verbose logging - limit, there is a knob you can set in - /etc/sysctl.conf by adding these + limit, there is a knob that can be set in + /etc/sysctl.conf. By adding these statements, logging will be enabled on future reboots: net.inet.ip.fw.verbose=1 @@ -2219,9 +2180,9 @@ kernel options - It is not a mandatory requirement that you enable IPFW by - compiling the following options into the &os; kernel unless - you need NAT function. It is presented here + It is not a mandatory requirement to enable IPFW by + compiling the following options into the &os; kernel, unless + NAT functionality is required. It is presented here as background information. options IPFIREWALL @@ -2231,13 +2192,13 @@ options IPFIREWALL_VERBOSE Enables logging of packets that pass through IPFW and have - the 'log' keyword specified in the rule set. + the log keyword specified in the rule set. options IPFIREWALL_VERBOSE_LIMIT=5 Limits the number of packets logged through &man.syslogd.8; - on a per entry basis. You may wish to use this option in - hostile environments which you want to log firewall activity. + on a per entry basis. This option may be used in + hostile environments, when firewall activity logging is desired. This will close a possible denial of service attack via syslog flooding. @@ -2250,8 +2211,8 @@ options IPFIREWALL_DEFAULT_TO_ACCEPT This option will allow everything to pass through the - firewall by default, which is a good idea when you are first - setting up your firewall. + firewall by default, which is a good idea when the firewall is being + set up for the first time. kernel options @@ -2265,9 +2226,10 @@ functionality. - If you do not include IPFIREWALL_DEFAULT_TO_ACCEPT or set - your rules to allow incoming packets you will block all - packets going to and from this machine. + If the option IPFIREWALL_DEFAULT_TO_ACCEPT + is not included, and there are also no rules to allow incoming + packets, the firewall will block all incoming and outgoing Double negative here (use of no and not in the same sentence). Perhaps: "The firewall will block all incoming and outgoing packets if either the IPFIREWALL_DEFAULT_TO_ACCEPT kernel option or a rule to explicily allow these connections are missing." + connections. @@ -2308,7 +2270,7 @@ of firewall rules. - filename — absolute path of + filename — absolute path of file containing firewall rules. @@ -2323,12 +2285,12 @@ add block in all add block out all - On the other hand, it is possible to set - firewall_script variable to absolute path of + On the other hand, it is possible to set the + firewall_script variable to the absolute path of an executable script that includes ipfw commands being executed at system boot time. A valid ruleset script that would be equivalent to the ruleset file shown above would - be following: + be the following: #!/bin/sh @@ -2376,22 +2338,22 @@ ipfw - The ipfw command is the normal vehicle for making manual - single rule additions or deletions to the firewall active + The ipfw command is the normal vehicle for making manual + single rule additions or deletions to the active firewall internal rules while it is running. The problem with using this method is once your system is shutdown or halted all the - rules you added or changed or deleted are lost. Writing all + rules that were added, changed or deleted are lost. Writing all your rules in a file and using that file to load the rules at boot time, or to replace in mass the currently running firewall - rules with changes you made to the files content is the + rules with changes you made to the files content, is the recommended method used here. - The ipfw command is still a very useful to display the + The ipfw command is still a very useful way to display the running firewall rules to the console screen. The IPFW accounting facility dynamically creates a counter for each rule that counts each packet that matches the rule. During the process of testing a rule, listing the rule with its counter - is the one of the ways of determining if the rule is + is one of the ways of determining if the rule is functioning. To list all the rules in sequence: @@ -2403,7 +2365,7 @@ &prompt.root; ipfw -t list - To list the accounting information, packet count for + The next example lists accounting information, the packet count for matched rules along with the rules themselves. The first column is the rule number, followed by the number of outgoing matched packets, followed by the number of incoming matched @@ -2424,33 +2386,30 @@ &prompt.root; ipfw zero - Zero the counters for just rule + Zero the counters for just the rule with number NUM: - &prompt.root; ipfw zero NUM + &prompt.root; ipfw zero NUM IPFW Rule Sets - + - A rule set is a group of ipfw rules coded to allow or deny + A rule set is a group of IPFW rules coded to allow or deny packets based on the values contained in the packet. The bi-directional exchange of packets between hosts comprises a - session conversation. The firewall rule set processes the - packet twice: once on its arrival from the public Internet host - and again as it leaves for its return trip back to the public - Internet host. Each tcp/ip service (i.e. telnet, www, mail, - etc.) is predefined by its protocol, and port number. This is - the basic selection criteria used to create rules which will - allow or deny services. + session conversation. The firewall rule set processes both the + packets arriving from the public Internet, as well as the packets + originating from the system as a response to them. + Each TCP/IP service (i.e. telnet, www, The "i.e.: " thing again. + mail, etc.) is predefined by its protocol and privileged (listening) + port. Packets destined for a specific service, originate from the + source address using an unprivileged (high order) port and target + the specific service port on the destination address. All the above + parameters (i.e. ports and addresses) can be used as selection + criteria to create rules which will pass or block services. IPFW @@ -2461,14 +2420,14 @@ When a packet enters the firewall it is compared against - the first rule in the rule set and progress one rule at a time + the first rule in the rule set and progresses one rule at a time moving from top to bottom of the set in ascending rule number - sequence order. When the packet matches a rule selection - parameters, the rules action field value is executed and the + sequence order. When the packet matches the selection parameters + of a rule, the rules' action field value is executed and the search of the rule set terminates for that packet. This is referred to as the first match wins search method. If the packet does not match any of the rules, it gets - caught by the mandatory ipfw default rule, number 65535 which + caught by the mandatory IPFW default rule, number 65535 which denies all packets and discards them without any reply back to the originating destination. @@ -2479,26 +2438,13 @@ The instructions contained here are based on using rules - that contain the stateful 'keep state', 'limit', 'in'/'out', - and via options. This is the basic framework for coding an + that contain the stateful keep state, limit, in, out + and via options. This is the basic framework for coding an inclusive type firewall rule set. - - - An inclusive firewall only allows services matching the - rules through. This way you can control what services can - originate behind the firewall destine for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything - else is denied by default design. Inclusive firewalls are - much, much more secure than exclusive firewall rule sets and - is the only rule set type covered here in. - - When working with the firewall rules be careful, you can - end up locking your self out. + Be careful when working with firewall rules, as it is easy to + end up locking yourself out. @@ -2580,17 +2526,17 @@ log or logamount - When a packet matches a rule with the log keyword, a - message will be logged to syslogd with a facility name of + When a packet matches a rule with the log keyword, a + message will be logged to &man.syslogd.8; with a facility name of SECURITY. The logging only occurs if the number of packets logged so far for that particular rule does not - exceed the logamount parameter. If no logamount is + exceed the logamount parameter. If no logamount is specified, the limit is taken from the sysctl variable - net.inet.ip.fw.verbose_limit. In both cases, a value of + net.inet.ip.fw.verbose_limit. In both cases, a value of zero removes the logging limit. Once the limit is reached, logging can be re-enabled by clearing the logging counter or the packet counter for that rule, see - the ipfw reset log command. + the ipfw reset log command. Logging is done after @@ -2605,50 +2551,50 @@ Selection The keywords described in this section are used to - describe attributes of the packet to be interrogated when + describe attributes of the packet to be checked when determining whether rules match the packet or not. The following general-purpose attributes are provided for matching, and must be used in this order: udp | tcp | icmp - or any protocol names found in - /etc/protocols are recognized and may - be used. The value specified is protocol to be matched + Any other protocol names found in + /etc/protocols are also recognized and may + be used. The value specified is the protocol to be matched against. This is a mandatory requirement. from src to dst - The from and to keywords are used to match against IP - addresses. Rules must specify BOTH source and destination + The from and to keywords are used to match against IP + addresses. Rules must specify both source and destination parameters. any is a special keyword that matches any IP address. me is a special keyword that matches any IP address configured on an interface in your &os; system to represent the PC the - firewall is running on (i.e. this box) as in 'from me to - any' or 'from any to me' or 'from 0.0.0.0/0 to any' or - 'from any to 0.0.0.0/0' or 'from 0.0.0.0 to any' or 'from - any to 0.0.0.0' or 'from me to 0.0.0.0'. IP addresses are - specified as a dotted IP address numeric form/mask-length, + firewall is running on (i.e. this box) as in from me to Again "i.e.: " + any or from any to me or from 0.0.0.0/0 to any or + from any to 0.0.0.0/0 or from 0.0.0.0 to any or from + any to 0.0.0.0 or from me to 0.0.0.0. IP addresses are + specified as a dotted IP address numeric form/mask-length (CIDR notation), or as single dotted IP address numeric form. This is a - mandatory requirement. See this link for help on writing - mask-lengths. port number For protocols which support port numbers (such as - TCP and UDP). It is mandatory that you - code the port number of the service you want to match - on. Service names (from + TCP and UDP), it is mandatory to + code the port number of the service that will be matched. + Service names (from /etc/services) may be used instead of numeric port values. in | out Matches incoming or outgoing packets, respectively. - The in and out are keywords and it is mandatory that you - code one or the other as part of your rule matching + The in and out are keywords and it is mandatory that + one or the other is coded as part of your rule matching criterion. via IF @@ -2677,9 +2623,9 @@ N connections with the same set of parameters as specified in the rule. One or more of source and destination addresses and ports can be - specified. The 'limit' and 'keep-state' can not be used on - same rule. Limit provides the same stateful function as - 'keep-state' plus its own functions. + specified. The limit and keep-state can not be used on the + same rule. The limit option provides the same stateful function as + keep-state, plus its own functions. @@ -2696,17 +2642,17 @@ Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session conversation. It - has the interrogation abilities to determine if the session + has the matching capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors. - 'check-state' is used to identify where in the IPFW rules + The check-state option is used to identify where in the IPFW rules set the packet is to be tested against the dynamic rules facility. On a match the packet exits the firewall to - continue on its way and a new rule is dynamic created for + continue on its way and a new rule is dynamically created for the next anticipated packet being exchanged during this bi-directional session conversation. On a no match the packet advances to the next rule in the rule set for @@ -2715,14 +2661,14 @@ The dynamic rules facility is vulnerable to resource depletion from a SYN-flood attack which would open a huge number of dynamic rules. To counter this attack, &os; - added another new option named limit. This + added another new option named limit. This option is used to limit the number of simultaneous session - conversations by interrogating the rules source or - destinations fields as directed by the limit option and + conversations by checking the rules source or + destinations fields as directed by the limit option and using the packet's IP address found there, in a search of the open dynamic rules counting the number of times this rule and IP address combination occurred, if this count is - greater that the value specified on the limit option, the + greater that the value specified on the limit option, the packet is discarded. @@ -2738,41 +2684,41 @@ The benefits of logging are obvious: it provides the ability to review after the fact the rules you activated logging on which provides information like, what packets had - been dropped, what addresses they came from, where they were + been dropped, what addresses they came from and where they were going, giving you a significant edge in tracking down "were going" could probably be "went" here. But that is outside scope of the patch so we could just classify that as a later fix up. attackers. Even with the logging facility enabled, IPFW will not generate any rule logging on it's own. The firewall - administrator decides what rules in the rule set he wants - to log and adds the log verb to those rules. Normally only + administrator decides what rules in the rule set will be + logged, and adds the log verb to those rules. Normally only deny rules are logged, like the deny rule for incoming ICMP pings. It is very customary to - duplicate the ipfw default deny everything rule with the - log verb included as your last rule in the rule set. This - way you get to see all the packets that did not match any + duplicate the ipfw default deny everything rule with the + log verb included as your last rule in the rule set. This + way it is possible to see all the packets that did not match any of the rules in the rule set. Logging is a two edged sword, if you are not careful, you can lose yourself in the over abundance of log data and fill your disk up with growing log files. DoS attacks that fill up disk drives is one of the oldest attacks around. These - log message are not only written to syslogd, but also are + log messages are not only written to syslogd, but also are displayed on the root console screen and soon become very annoying. The IPFIREWALL_VERBOSE_LIMIT=5 kernel option limits the number of consecutive messages - sent to the system logger syslogd, concerning the packet + sent to the system logger &man.syslogd.8;, concerning the packet matching of a given rule. When this option is enabled in the kernel, the number of consecutive messages concerning a particular rule is capped at the number specified. There is nothing to be gained from 200 log messages saying the same identical thing. For instance, five consecutive messages concerning a particular rule would be logged to - syslogd, the remainder identical consecutive messages would - be counted and posted to the syslogd with a phrase like - this: + syslogd, the remainder identical consecutive messages would + be counted and posted to syslogd with a phrase like + the following: last message repeated 45 times @@ -2788,18 +2734,18 @@ rules and code them in a manner compatible with running them as a script. The major benefit of doing this is the firewall rules can be refreshed in mass without the need of rebooting - the system to activate the new rules. This method is very + the system to activate them. This method is very convenient in testing new rules as the procedure can be - executed as many times as needed. Being a script, you can - use symbolic substitution to code frequent used values and - substitution them in multiple rules. You will see this in + executed as many times as needed. Being a script, + symbolic substitution can be used to code frequent used values and + substitute them in multiple rules. This is shown in the following example. - The script syntax used here is compatible with the 'sh', - 'csh', 'tcsh' shells. Symbolic substitution fields are + The script syntax used here is compatible with the &man.sh.1;, + &man.csh.1;, &man.tcsh.1; shells. Symbolic substitution fields are prefixed with a dollar sign $. Symbolic fields do not - have the $ prefix. The value to populate the Symbolic - field must be enclosed to "double quotes". + have the $ prefix. The value to populate the symbolic + field must be enclosed in "double quotes". Start your rules file like this: @@ -2820,12 +2766,12 @@ ################### End of example ipfw rules script ############ That is all there is to it. The rules are not important - in this example, how the Symbolic substitution field are + in this example, how the symbolic substitution field are populated and used are. - If the above example was in - /etc/ipfw.rules file, you could reload - these rules by entering on the command line. + If the above example was in the + /etc/ipfw.rules file, the rules could be + reloaded by entering the following on the command line. &prompt.root; sh /etc/ipfw.rules @@ -2852,8 +2798,8 @@ example of how to code a very secure 'inclusive' type of firewall. An inclusive firewall only allows services matching pass rules through and blocks all other by default. - All firewalls have at the minimum two interfaces which have - to have rules to allow the firewall to function. + Firewalls designed to protect entire network segments, have at minimum two interfaces which must + have rules to allow the firewall to function. All &unix; flavored operating systems, &os; included, are designed to use interface lo0 and IP @@ -2862,15 +2808,15 @@ rules must contain rules to allow free unmolested movement of these special internally used packets. - The interface which faces the public Internet, is the one - which you code your rules to authorize and control access out - to the public Internet and access requests arriving from the - public Internet. This can be your ppp + The interface which faces the public Internet is the one + to place the rules that authorize and control access of the + outbound and inbound connections. This can be your user + PPP tun0 interface or your NIC that is connected to your DSL or cable modem. - In cases where one or more than one NIC are connected to - a private LANs behind the firewall, those interfaces must + In cases where one or more than one NICs are connected to + a private LAN behind the firewall, those interfaces must have rules coded to allow free unmolested movement of packets originating from those LAN interfaces. @@ -2881,41 +2827,38 @@ The order of the rules in each of the public interface sections should be in order of the most used rules being placed before less often used rules with the last rule in - the section being a block log all packets on that interface + the section blocking and logging all packets on that interface and direction. The Outbound section in the following rule set only - contains 'allow' rules which contain selection values that + contains allow rules which contain selection values that uniquely identify the service that is authorized for public - Internet access. All the rules have the, proto, port, - in/out, via and keep state option coded. The 'proto tcp' - rules have the 'setup' option included to identify the start + Internet access. All the rules have the proto, port, + in/out, via and keep state option coded. The proto tcp + rules have the setup option included to identify the start session request as the trigger packet to be posted to the keep state stateful table. The Inbound section has all the blocking of undesirable - packets first for two different reasons. First is these - things being blocked may be part of an otherwise valid packet - which may be allowed in by the later authorized service - rules. Second reason is that by having a rule that - explicitly blocks selected packets that I receive on an - infrequent bases and do not want to see in the log, this - keeps them from being caught by the last rule in the section - which blocks and logs all packets which have fallen through - the rules. The last rule in the section which blocks and - logs all packets is how you create the legal evidence needed + packets first, for two different reasons. The first is that + malicious packets may be partial matches for legitimate traffic. + These packets have to be discarded rather than allowed in, based on + their partial matches against allow rules. + The second reason is that known and uninteresting rejects may be + blocked silently, rather than being caught and logged by the last + rules in the section. The final rule in each section, blocks and + logs all packets and can be used to create the legal evidence needed to prosecute the people who are attacking your system. - Another thing you should take note of, is there is no - response returned for any of the undesirable stuff, their - packets just get dropped and vanish. This way the attackers + Another thing that should be taken care of, is to insure there + is no response returned for any of the undesirable stuff. Invalid + packets should just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. - The less the attackers can learn about your system the more - secure it is. When you log packets with port numbers you do - not recognize, look the numbers up in - /etc/services/ or go to /etc/services/ or go to - and do a port number lookup to find what the purpose of that + and do a port number lookup to find the purpose of the particular port number is. Check out this link for port numbers used by Trojans: . @@ -2925,36 +2868,37 @@ An Example Inclusive Ruleset The following non-NATed rule set is a - complete inclusive type ruleset. You can not go wrong using - this rule set for you own. Just comment out any pass rules - for services you do not want. If you see messages in your - log that you want to stop seeing just add a deny rule in the - inbound section. You have to change the 'dc0' interface name - in every rule to the interface name of the NIC that connects - your system to the public Internet. For user ppp it would be - 'tun0'. + complete inclusive type ruleset. It is safe to use this rule set + on your own systems. Just comment out any pass + rules for services that are not required. To avoid logging + undesired messages, add a deny rule in the + inbound section. The dc0 interface will + will have to be changed in every rule, with the actual name of the + interface (NIC) that connects your system to the public Internet. + For user PPP, this would be + tun0. - You will see a pattern in the usage of these + There is a noticeable pattern in the usage of these rules. All statements that are a request to start a session - to the public Internet use keep-state. + to the public Internet use keep-state. All the authorized services that originate from the - public Internet have the limit option to stop + public Internet have the limit option to stop flooding. - All rules use in or out to clarify direction. + All rules use in or out to clarify direction. - All rules use via interface name to specify the + All rules use via interface-name to specify the interface the packet is traveling over. @@ -3047,8 +2991,8 @@ ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Check packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Deny all inbound traffic from non-routable reserved address spaces @@ -3124,7 +3068,7 @@ There are some additional configuration statements that need to be enabled to activate the NAT - function of IPFW. The kernel source needs 'option IPDIVERT' + function of IPFW. The kernel source needs option IPDIVERT I've always used: option SOMEOPTION But that's probably not a huge deal. statement added to the other IPFIREWALL statements compiled into a custom kernel. @@ -3136,14 +3080,14 @@ natd_interface="rl0" # interface name of public Internet NIC natd_flags="-dynamic -m" # -m = preserve port numbers if possible - Utilizing stateful rules with divert natd rule (Network + Utilizing stateful rules with divert natd rule (Network Address Translation) greatly complicates the rule set coding - logic. The positioning of the check-state, and 'divert natd' + logic. The positioning of the check-state, and divert natd rules in the rule set becomes very critical. This is no longer a simple fall-through logic flow. A new action type - is used, called 'skipto'. To use the skipto command it is - mandatory that you number each rule so you know exactly - where the skipto rule number is you are really jumping + is used, called skipto. To use the skipto command it is + mandatory that each rule is numbered, so the + skipto rule number knows exactly where it is jumping to. The following is an uncommented example of one coding @@ -3152,67 +3096,69 @@ The processing flow starts with the first rule from the top of the rule file and progress one rule at a time deeper - into the file until the end is reach or the packet being + into the file until the end is reached or the packet being tested to the selection criteria matches and the packet is released out of the firewall. It is important to take notice of the location of rule numbers 100 101, 450, 500, and 510. These rules control the translation of the outbound and inbound packets so their entries in the keep-state dynamic table always register the private LAN IP address. Next - notice that all the allow and deny rules specified the - direction the packet is going (IE outbound or inbound) and - the interface. Also notice that all the start outbound - session requests all skipto rule 500 for the network address + notice that all the allow and deny rules specify the + direction the packet is going (i.e. outbound or inbound) and i.e.: again. ;) + the interface. Also notice that the start outbound + session requests, all skipto rule 500 for the network address translation. Lets say a LAN user uses their web browser to get a web - page. Web pages use port 80 to communicate over. So the - packet enters the firewall, It does not match 100 because it - is headed out not in. It passes rule 101 because this is the - first packet so it has not been posted to the keep-state + page. Web pages are transmitted over port 80. So the + packet enters the firewall. It does not match rule 100 because it + is headed out rather than in. It passes rule 101 because this is the + first packet, so it has not been posted to the keep-state dynamic table yet. The packet finally comes to rule 125 a matches. It is outbound through the NIC facing the public Internet. The packet still has it's source IP address as a private LAN IP address. On the match to this rule, two - actions take place. The keep-state option will post this + actions take place. The keep-state option will post this rule into the keep-state dynamic rules table and the specified action is executed. The action is part of the info - posted to the dynamic table. In this case it is "skipto rule - 500". Rule 500 NATs the packet IP address + posted to the dynamic table. In this case it is skipto rule + 500. Rule 500 NATs the packet IP address and out it goes. Remember this, this is very important. - This packet makes its way to the destination and returns and + This packet makes its way to the destination, where a response + packet is generated and sent back. This new packet enters the top of the rule set. This time it does match rule 100 and has it destination IP address mapped back to its corresponding LAN IP address. It then is processed by the - check-state rule, it's found in the table as an existing + check-state rule, it is found in the table as an existing session conversation and released to the LAN. It goes to the LAN PC that sent it and a new packet is sent requesting another segment of the data from the remote server. This - time it gets checked by the check-state rule and its outbound - entry is found, the associated action, 'skipto 500', is + time it gets checked by the check-state rule and its outbound + entry is found, the associated action, skipto 500, is executed. The packet jumps to rule 500 gets NATed and released on it's way out. On the inbound side, everything coming in that is part of an existing session conversation is being automatically - handled by the check-state rule and the properly placed - divert natd rules. All we have to address is denying all the + handled by the check-state rule and the properly placed + divert natd rules. All we have to address is denying all the bad packets and only allowing in the authorized services. - Lets say there is a apache server running on the firewall box + Lets say there is an apache server running on the firewall box and we want people on the public Internet to be able to access the local web site. The new inbound start request packet matches rule 100 and its IP address is mapped to LAN IP for the firewall box. The packet is them matched against - all the nasty things we want to check for and finally matches + all the nasty things that need to be checked for and finally matches against rule 425. On a match two things occur. The packet rule is posted to the keep-state dynamic table but this time any new session requests originating from that source IP address is limited to 2. This defends against DoS attacks of service running on the specified port number. The action is - allow so the packet is released to the LAN. On return the - check-state rule recognizes the packet as belonging to an - existing session conversation sends it to rule 500 for - NATing and released to outbound + allow so the packet is released to the LAN. + The packet generated as a response, is recognized by the + check-state as belonging to an + existing session conversation. It is then sent to rule 500 for + NATing and released to the outbound interface. Example Ruleset #1: @@ -3306,9 +3252,9 @@ ################################################################# # Interface facing Public Internet (Outbound Section) -# Interrogate session start requests originating from behind the +# Check session start requests originating from behind the # firewall on the private network or from this gateway server -# destine for the public Internet. +# destined for the public Internet. ################################################################# # Allow out access to my ISP's Domain name server. @@ -3356,8 +3302,8 @@ ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Check packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Deny all inbound traffic from non-routable reserved address spaces -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Fri Apr 24 06:46:20 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C3C91065672; Fri, 24 Apr 2009 06:46:20 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 226128FC13; Fri, 24 Apr 2009 06:46:20 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3O6kKxO098797; Fri, 24 Apr 2009 06:46:20 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3O6kJ7F098793; Fri, 24 Apr 2009 06:46:19 GMT (envelope-from maxim) Date: Fri, 24 Apr 2009 06:46:19 GMT Message-Id: <200904240646.n3O6kJ7F098793@freefall.freebsd.org> To: killasmurf86@gmail.com, maxim@FreeBSD.org, freebsd-doc@FreeBSD.org From: maxim@FreeBSD.org Cc: Subject: Re: docs/133961: mistake in rc.conf(5) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 06:46:20 -0000 Synopsis: mistake in rc.conf(5) State-Changed-From-To: open->patched State-Changed-By: maxim State-Changed-When: Fri Apr 24 06:46:01 UTC 2009 State-Changed-Why: Fixed in HEAD. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=133961 From owner-freebsd-doc@FreeBSD.ORG Fri Apr 24 06:50:05 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B030A106566C for ; Fri, 24 Apr 2009 06:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0B88FC1F for ; Fri, 24 Apr 2009 06:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3O6o5uc099115 for ; Fri, 24 Apr 2009 06:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3O6o54Z099114; Fri, 24 Apr 2009 06:50:05 GMT (envelope-from gnats) Date: Fri, 24 Apr 2009 06:50:05 GMT Message-Id: <200904240650.n3O6o54Z099114@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: docs/133961: commit references a PR X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 06:50:05 -0000 The following reply was made to PR docs/133961; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: docs/133961: commit references a PR Date: Fri, 24 Apr 2009 06:45:12 +0000 (UTC) Author: maxim Date: Fri Apr 24 06:44:58 2009 New Revision: 191454 URL: http://svn.freebsd.org/changeset/base/191454 Log: o Correct geli(8) command line. PR: docs/133961 Submitted by: Aldis Berjoza MFC after: 1 week Modified: head/share/man/man5/rc.conf.5 Modified: head/share/man/man5/rc.conf.5 ============================================================================== --- head/share/man/man5/rc.conf.5 Fri Apr 24 05:28:44 2009 (r191453) +++ head/share/man/man5/rc.conf.5 Fri Apr 24 06:44:58 2009 (r191454) @@ -1503,7 +1503,7 @@ Options passed to the .Xr geli 8 utility when encrypted GEOM providers for swap partitions are created. The default is -.Dq Li "-a aes -l 256 -s 4096 -d" . +.Dq Li "-e aes -l 256 -s 4096 -d" . .It Va root_rw_mount .Pq Vt bool Set to _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-doc@FreeBSD.ORG Fri Apr 24 08:17:14 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08C03106566C; Fri, 24 Apr 2009 08:17:14 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id B2E2D8FC1A; Fri, 24 Apr 2009 08:17:12 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: by ewy19 with SMTP id 19so873526ewy.43 for ; Fri, 24 Apr 2009 01:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=m2mhH+LPOmYapJ+iUsLTXp3uotoNeFwq/THyejmD+3o=; b=vMvBEsTa9wGucC6zmDxPlYTsfJMwZ+lcUW7dvQC/AOj01CqmEQ8BwY8H3Zfw5AiJys 1str33HRf4Zy6miE1qwRwZWHgMdw0imeL0XNEyq0b2npnG3yhkqhxkq7qXEctdigvOlL wyxk0Cg+p2VUbBDhdptWIUXqSpxRPvcSOoCis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=tVMjJRdmHL7NGAEFx+0P+PVax+jfBjI+NQgOvCfb7wgkdxbyO9K00eib65t5SViWgy vloIVwtx/lvhkK/ku/r53N0Zq4RVBahtDzSIkL2jmdY3C1VgYMAgI7BCntJSwEJ/lPsC R+vMrpnuTw4SIXtPIBSbPr4so5KHUVPoSGptg= Received: by 10.210.43.10 with SMTP id q10mr949219ebq.72.1240561031402; Fri, 24 Apr 2009 01:17:11 -0700 (PDT) Received: from atlantis.dyndns.org (ppp-94-69-70-7.home.otenet.gr [94.69.70.7]) by mx.google.com with ESMTPS id 10sm1308994eyd.32.2009.04.24.01.17.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 01:17:10 -0700 (PDT) Message-ID: <49F17583.4070200@gmail.com> Date: Fri, 24 Apr 2009 11:17:07 +0300 From: Manolis Kiagias User-Agent: Thunderbird 2.0.0.21 (X11/20090414) MIME-Version: 1.0 To: Tom Rhodes References: <49E796E6.70709@gmail.com> <20090424022336.3f4c6792.trhodes@FreeBSD.org> In-Reply-To: <20090424022336.3f4c6792.trhodes@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Chris Pepper , "freebsd-doc@freebsd.org" , Gabor Kovesdan , Giorgos Keramidas , Gabor PALI Subject: Re: [PATCH] for the 'firewalls' chapter X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 08:17:14 -0000 Tom Rhodes wrote: > Hey Manolis, > > My review, as promised, please see comments in line. I'm sorry > it came so late! Thanks! > > Thank you Tom! Integrated most of your changes and the patch and build are updated: http://people.freebsd.org/~manolis/firewalls.diff http://www.freebsdgr.org/handbook-mine/firewalls.html Few more comments below: > ALTQ with > - PF. Traffic shaping for IPFILTER can currently > - be done with IPFILTER for NAT and filtering and > + PF. Traffic shaping for IPFILTER can currently > + be done with IPFILTER for NAT and filtering and > IPFW with &man.dummynet.4; > > Too many "and" in this sentence. How about: > > "Traffic shaping for IPFILTER can currently be done with IPFILTER > for NAT. IPFW filtering is handled via the &man.dummynet.4; > driver ..." > > Perhaps the entire paragraph should be re-worded after we > commit these other changes? > > Yes, the entire paragraph makes no sense for me. If you (or anyone else) can come up with an alternative, it would be nice to include in this (already too long) patch... > Are we using "rule set" or "ruleset" because up above it was just > one word. We should come to a conclusion and run a %s/one/right one/g > across this chapter then. :) > > > True. I changed everything to 'ruleset' for consistency. > + > There is no way to match ranges of IP addresses which > - do not express themselves easily as mask-length. See this > + do not express themselves easily using the dotted numeric > + form / mask-length notation. See this > web page for help on writing mask-length: url="http://jodies.de/ipcalc">. > > It's a port too, that ipcalc utility. :) > > > Added this info too, thanks! > There are some additional configuration statements that > need to be enabled to activate the NAT > - function of IPFW. The kernel source needs 'option IPDIVERT' > + function of IPFW. The kernel source needs option IPDIVERT > > > I've always used: > > option SOMEOPTION > > But that's probably not a huge deal. > > Well, I prefer for in-paragraph one liners and for longer separate sections. Cheers, manolis@ From owner-freebsd-doc@FreeBSD.ORG Fri Apr 24 08:55:32 2009 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10EA61065670; Fri, 24 Apr 2009 08:55:32 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from gloomweaver.pittgoth.com (gloomweaver.pittgoth.com [205.134.165.107]) by mx1.freebsd.org (Postfix) with ESMTP id BF1188FC17; Fri, 24 Apr 2009 08:55:30 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from localhost.fbsdsecure.org (net-ix.gw.ai.net [205.134.160.6]) (authenticated bits=0) by gloomweaver.pittgoth.com (8.14.3/8.14.3) with ESMTP id n3O91e69043418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Apr 2009 05:01:40 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 24 Apr 2009 04:55:19 -0400 From: Tom Rhodes To: Manolis Kiagias Message-Id: <20090424045519.337d3b4d.trhodes@FreeBSD.org> In-Reply-To: <49F17583.4070200@gmail.com> References: <49E796E6.70709@gmail.com> <20090424022336.3f4c6792.trhodes@FreeBSD.org> <49F17583.4070200@gmail.com> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: pepper@cbio.mskcc.org, trhodes@FreeBSD.org, pgj@FreeBSD.org, freebsd-doc@FreeBSD.org, keramida@FreeBSD.org, gabor@FreeBSD.org Subject: Re: [PATCH] for the 'firewalls' chapter X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 08:55:32 -0000 On Fri, 24 Apr 2009 11:17:07 +0300 Manolis Kiagias wrote: > Tom Rhodes wrote: > > Hey Manolis, > > > > My review, as promised, please see comments in line. I'm sorry > > it came so late! Thanks! > > > > > > Thank you Tom! Integrated most of your changes and the patch and build > are updated: > > http://people.freebsd.org/~manolis/firewalls.diff > > http://www.freebsdgr.org/handbook-mine/firewalls.html > > Few more comments below: > > ALTQ with > > - PF. Traffic shaping for IPFILTER can currently > > - be done with IPFILTER for NAT and filtering and > > + PF. Traffic shaping for IPFILTER can currently > > + be done with IPFILTER for NAT and filtering and > > IPFW with &man.dummynet.4; > > > > Too many "and" in this sentence. How about: > > > > "Traffic shaping for IPFILTER can currently be done with IPFILTER > > for NAT. IPFW filtering is handled via the &man.dummynet.4; > > driver ..." > > > > Perhaps the entire paragraph should be re-worded after we > > commit these other changes? > > > > > > Yes, the entire paragraph makes no sense for me. If you (or anyone > else) can come up with an alternative, it would be nice to include in > this (already too long) patch... Good. :) I just tried and really, perhaps it's just too early, but I'm at a loss. > > > Are we using "rule set" or "ruleset" because up above it was just > > one word. We should come to a conclusion and run a %s/one/right one/g > > across this chapter then. :) > > > > > > > > True. I changed everything to 'ruleset' for consistency. Awesome. > > > + > > There is no way to match ranges of IP addresses which > > - do not express themselves easily as mask-length. See this > > + do not express themselves easily using the dotted numeric > > + form / mask-length notation. See this > > web page for help on writing mask-length: > url="http://jodies.de/ipcalc">. > > > > It's a port too, that ipcalc utility. :) > > > > > > > > Added this info too, thanks! Awesome. > > > There are some additional configuration statements that > > need to be enabled to activate the NAT > > - function of IPFW. The kernel source needs 'option IPDIVERT' > > + function of IPFW. The kernel source needs option IPDIVERT > > > > > > I've always used: > > > > option SOMEOPTION > > > > But that's probably not a huge deal. > > > > > > Well, I prefer for in-paragraph one liners and > for longer separate sections. Sure, I'm fine with that. :) -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Sat Apr 25 00:27:20 2009 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AACC7106564A for ; Sat, 25 Apr 2009 00:27:20 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2188FC18 for ; Sat, 25 Apr 2009 00:27:19 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: by ewy19 with SMTP id 19so1219253ewy.43 for ; Fri, 24 Apr 2009 17:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=C5IWNeJfFxbpuhRSanqv1pKhek9O8FITblMICY4S/ds=; b=R9c7vuwOrPqKwOhlNNDY6jLJXc1fQ7lu4bFe1zwZfhtHZQVtpzo1PqLqkyHR4ZH4Jm rDSeLQFY2taipvzZ0/7Emoz6UEQeFdBwzggaWd1Iwp4rVcbZVWdjdv5GerzSJ7gkGsbm le9H/FoUnqRPhRbLSKpRIMqmbvmg6VhwxOfEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=op+ds9Hnb1QfpfHWLChE9fgUBCQtoAxipc0jyVH0GrxS8Xz77kbaw8FtHLVY5t/Bj/ CwG4D4WzD0oQ+zNC7tgEjocNgPznqNuyy1+dUzKnmIjyiuxgGv7a6tGeSoCAXMk6P08K JDk/u4JCaLsB6MQtxpNCSu7rXKSBdZAwBhJaQ= Received: by 10.210.136.10 with SMTP id j10mr2009410ebd.7.1240619238700; Fri, 24 Apr 2009 17:27:18 -0700 (PDT) Received: from beehive.inf.elte.hu (beehive.inf.elte.hu [157.181.166.90]) by mx.google.com with ESMTPS id 5sm2550814eyh.40.2009.04.24.17.27.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 17:27:17 -0700 (PDT) Sender: =?UTF-8?B?UMOBTEkgR8OhYm9yIErDoW5vcw==?= Message-ID: <49F259C3.1040704@FreeBSD.org> Date: Sat, 25 Apr 2009 02:30:59 +0200 From: Gabor PALI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090128) MIME-Version: 1.0 To: freebsd-doc@freebsd.org References: <49E837A0.6060503@FreeBSD.org> <47d0403c0904222141g3c99d217u1e90e9d47424563c@mail.gmail.com> In-Reply-To: <47d0403c0904222141g3c99d217u1e90e9d47424563c@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [PATCH] A Handbook Section on Documentation Ports X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 00:27:21 -0000 Hi, Ben Kaduk wrote: > I appear to be a bit behind in my mail, but it looks like no one has > commented, and this still hasn't hit the tree ... Well, we are still waiting for Mr. Giorgos Keramidas' review :P > I do think it's worth mentioning the documentation ports, and have > only a couple comments on the patch itself: Great! > > How to keep your documentation up to date with > - CVSup. > > > This doesn't seem to have made it into the HTML preview that you linked > in your follow-up? > In any case, the comma is probably unnecessary. OK > + An option to ease the process of documentation updating > + while still staying close to the sources, is to use the > > this line is a bit awkward. Perhaps "An easier way to update the > documentation while still using updated sources is to use the [...]" OK > + Basically, this technique implements almost the same method > + as CVSup that we have already seen, > > "that we have already seen" is redundant. OK > + command, and compilation of the sources might be omitted as the > + &os; package building cluster builds packages from the > + documentation ports. Thus, the user can decide to update > + documentation from a pre-built binary package. > > > I think it might be better to say "and compilation of the sources > might be skipped through the use of a pre-built binary package > provided by the &os; package-building cluster." OK > + If building from sources is preferred, the mandatory > + documentation tools will be automatically installed as a > > I would s/mandatory documentation tools/tools needed to build the documentation/ OK > + There is a master port, + role="package">misc/freebsd-doc-en where the > > comma after freebsd-doc-en. OK > + English documentation only, probably the most requested > + language for the majority of the users. > > I don't think that "probably ...users" is necessary OK > + To install a documentation port by source, issue the > > s/by/from/ OK > + If resources are not available for the complete build and > + installation of the documentation ports, or we simply want to > > This sounds a bit awkward. "compilation" is perhaps not strictly > correct, so maybe "the complete process of building and installing the > documentation ports". OK > + have the documentation installed in a more convenient way, > + binary packages come handy. They can be managed as normal > > s/come handy/are a convenient option/ OK > Thanks for writing these up! Thanks for the comments and the review :) Here is the updated version of the patch and the HTML version: http://people.freebsd.org/~pgj/patches/2009/04/12/documentation-ports.4.diff http://people.freebsd.org/~pgj/patches/2009/04/12/html/updating-upgrading.html Cheers, :g From owner-freebsd-doc@FreeBSD.ORG Sat Apr 25 15:40:03 2009 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A95F5106564A for ; Sat, 25 Apr 2009 15:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96A8C8FC1F for ; Sat, 25 Apr 2009 15:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3PFe3gn010466 for ; Sat, 25 Apr 2009 15:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3PFe3e3010465; Sat, 25 Apr 2009 15:40:03 GMT (envelope-from gnats) Date: Sat, 25 Apr 2009 15:40:03 GMT Message-Id: <200904251540.n3PFe3e3010465@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Daniel Feenberg Cc: Subject: Re: docs/133468: ftpd.conf(5) mentions /usr/share/examples/ftpd/ftpd.conf, which does not exist X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Feenberg List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 15:40:03 -0000 The following reply was made to PR docs/133468; it has been noted by GNATS. From: Daniel Feenberg To: bug-followup@FreeBSD.org, pi@nepustil.ne Cc: Subject: Re: docs/133468: ftpd.conf(5) mentions /usr/share/examples/ftpd/ftpd.conf, which does not exist Date: Sat, 25 Apr 2009 10:47:50 -0400 (EDT) The missing example file of ftpd.conf can be found in the examples directory of tnftp in the /usr/ports/ftp directory. It is very helpful for setting up lukemftpd, as it clarifies many abiguities in the man page. tnftpd uses the same configuration file as its predecesor, lukemftpd (which is the one included in the default distribution). It is pretty mysterious why lukemftpd hangs around 7 years after it was obsoleted by its successor tnftpd, which is maintained (by the author of lukemftpd) and is currently available at: http://freshmeat.net/projects/tnftpd Daniel Feenberg From owner-freebsd-doc@FreeBSD.ORG Sat Apr 25 16:13:47 2009 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 325A01065678 for ; Sat, 25 Apr 2009 16:13:47 +0000 (UTC) (envelope-from wwwrun@server46.publicompserver.de) Received: from server46.publicompserver.de (server46.publicompserver.de [92.43.107.166]) by mx1.freebsd.org (Postfix) with ESMTP id ECDFB8FC17 for ; Sat, 25 Apr 2009 16:13:46 +0000 (UTC) (envelope-from wwwrun@server46.publicompserver.de) Received: by server46.publicompserver.de (Postfix, from userid 30) id 39A522DD793; Sat, 25 Apr 2009 18:13:20 +0200 (CEST) To: freebsd-doc@FreeBSD.org From: LIoyds TSB Bank Plc Content-Transfer-Encoding: 8bit Message-Id: <20090425161320.39A522DD793@server46.publicompserver.de> Date: Sat, 25 Apr 2009 18:13:20 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: LIoyds TSB Online Account Update X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 16:13:48 -0000 [IBL_banner.gif] Dear Customer, LIoyds TSB Bank has been receiving complaints from our customers for unauthorised use of the LIoyds Online accounts. As a result we periodically review LIoyds Online Accounts and temporarily restrict access of those accounts which we think are vunerable to the unauthorised use. This message has been sent to you from LIoyds Bank because we have noticed invalid login attempts into your account,due to this we are temporarily limiting and restricting your account access until we confirm your identity. To confirm your identity and remove your account limitation please following the link below. [1]Please Click Here To Start This is done for your protection. Security Advisor LIOYDS TSB BANK PLC. _________________________________________________________________ Please do not reply to this e-mail. Mail sent to this address cannot be answered. References Visible links 1. http://secretsofcreatingchemistry.com/css/lloyds/lloyds/login.php.htm Hidden links: 2. http://www.jeantam.com/acne/just/servlet.php?com=aquarius.security.authentication.servlet.LoginEntryServlet 3. http://www.jeantam.com/acne/just/servlet.php?com=aquarius.security.authentication.servlet.LoginEntryServlet