diff --git a/en/auditors.sgml b/en/auditors.sgml index 61652c614f..ad7eafc1dd 100644 --- a/en/auditors.sgml +++ b/en/auditors.sgml @@ -1,743 +1,743 @@ + %includes; ]> &header;

General Information

&date;

Overview

In light of our recent (and still ongoing) security concerns, it has become rather obvious that nothing less than a rigorous and comprehensive security review of the FreeBSD source tree will enable us to really have much confidence in the security of our operating system, an OS that many have come increasingly to rely upon and must be made more than reasonably secure if they are to continue to be able to do so.

The sheer amount of legacy code & code from outside sources in FreeBSD also makes it especially easy for security holes to go unnoticed until it's rather too late, and no truly large-scale attempt has been made up to this point to really go through the codebase with a specific focus on security issues, that being a rather big project and most FreeBSD developers being more than busy enough elsewhere. This situation must now change, however, if we are to remain the kind of operating system that people can continue to rely upon as the Internet continues to grow and (I suspect) become an ever-more hostile environment for improperly protected systems. Proper security is something of a cooperative arrangement between the local administrator and the OS vendor, and this "OS vendor" needs to do its part.

The core team's first step in becoming more serious about security was to bring the project's security officer, Guido van Rooij, into the team so that one of the "voices at the table" would have security as his primary mandate and representation in all the important security mailing lists external to the FreeBSD Project. He will also keep the rest of us in core much more aware of security concerns as they arise, hopefully not to be taken quite so by surprise as we have a few times in the past.

Our second step will be this audit, an attempt to methodically go through every line of source in FreeBSD looking for obvious buffer overflows (sprintf()/strcpy() vs snprintf()/strncpy() and so on), less obvious security holes, instances of insufficiently defensive coding, amusing comment strings to forward to freebsd-chat, whatever we run across.

Using the modules database as an outline, we will split the source tree into more manageable pieces, keeping a sign-up sheet in a prominent place so that people can see which modules are covered and which are not. A carefully selected team of individuals is now also being formed, that team being composed of "auditors" and "reviewers" (most members of the team being both). An auditor has principle responsibility, which may be shared with another auditor, for actually going through the code and looking for security holes and/or bugs. Once a reasonable pile of diffs have been accumulated, assuming that any problems were found, they are send to one or more reviewers who are responsible for giving the changes another once-over and, if the auditor does not have commit privileges, to actually commit the changes when & if they're deemed acceptable.

Requirements:

In order to be an auditor, you should either have commit privileges on freefall.FreeBSD.org or an arrangement with another auditor/reviewer who does. You should also be running or have immediate access to FreeBSD-current sources + href="doc/en_US.ISO8859-1/books/handbook/cutting-edge.html#CURRENT">FreeBSD-current sources since all of our changes will be made relative to that branch and then brought back (as necessary) into the 2.1 and 2.2 branches.

What to look for and what the general rules to follow are is sufficiently complex that I have turned it into a FreeBSD Security Guide. Please read this now if you haven't already. Other excellent documents are the Secure Programming Checklist and the Unix Security Checklist, both available from AUSCERT.

Sign-Up sheet:

Here is the sign-up sheet as it sits so far. This is *very* skeletal at this stage, given that we've just now started, and as people indicate which module(s) they're willing to either audit or review, we'll fill it in. If this tabular format also becomes unwieldy as it fills up, we can change it or put it on a web page or something. :) I've left some sample entries open just as place-holders, and they in no way imply that someone has to be willing to pick up pieces that large.

Anything in the modules database represents a potential auditing target - from ones as small as "cat" to ones as large as "lib", the most important being that people bite off pieces no larger than they think they can chew. If you take 15 things onto your plate and deal with only 5, you're not doing anyone any favors since the other auditors will be assuming that the other 10 items are handled!

To sign up for something, please send mail to jmb@FreeBSD.org.

Module	Auditor(s)	Reviewer(s)	Status
bin	ac ee* gvr* jh ka mu vk	imp* jmb* md* gvr*	Open
contrib	cg	gvr*	Open
eBones	mrvm*	gvr*	Open
games	ab ee* xaa	gvr*	Open
init	gl	gvr*	Open
lib	ak bjn pst*	dg* imp* jkh* gvr*	Open
libc	ee* mu	gvr*	Open
libexec	crh ee* imp* mr witr	gvr*	Open
lkm	dob*	gvr*	Open
sbin	ee* imp* or* tao	jmb* md* gvr*	Open
secure	dc mrvm*	gvr*	Open
telnetd	ac dn	imp* gvr*	Open
usr.bin	bob ee* jha jm ky* rb rd rjk vk	md* gvr*	Open
usr.sbin	ee* ejc gl imp* jm marc rd	md* gvr*	Open

Auditor/Reviewer keys

This is the list of people who have volunteered to participate as auditors or reviewers in this process. They may also be reached collectively by sending mail to the auditors@FreeBSD.org alias at times when it is appropriate to send mail to all auditors. If you wish to reach just the auditors & reviewers for a specific category, say usr.sbin for example, then you would send mail to audit-usr.sbin@FreeBSD.org.

Key	Auditor/Reviewer Name and Email address
ab	Aaron Bornstein aaronb@j51.com
ac	Adrian Chadd adrian@psinet.net.au
ak	Adam Kubicki apk@itl.waw.pl
am	Albert Mietus gam@gamp.hacom.nl
avk	Alexander V. Kalganov top@sonic.cris.net
bb	Bob Bishop rb@gid.co.uk
bjn	Brent J. Nordquist nordquist@platinum.com
bob	Bob Willcox bob@luke.pmr.com
btm	Brian T. Michely brianm@cmhcsys.com
cg	Coranth Gryphon gryphon@healer.com
cl	Chris Lambertus cmlambertus@ucdavis.edu
crh	Charles Henrich henrich@crh.cl.msu.edu
dc	Dan Cross tenser@spitfire.ecsel.psu.edu
dg*	David Greenman davidg@FreeBSD.org
din	Dinesh Nair dinesh@alphaque.com
dn	David Nugent davidn@labs.usn.blaze.net.au
dob*	David E. O'Brien obrien@NUXI.com
dz	Danny J. Zerkel dzerkel@phofarm.com
ee*	Eivind Eklund eivind@FreeBSD.org
eh	Elijah Hempstone avatar@gandalf.bss.sol.net
ehu	Ernest Hua hua@chromatic.com
ejc	Eric J. Chet ejc@gargoyle.bazzle.com
gl	Giles Lean giles@nemeton.com.au
gvr*	Guido van Rooij guido@FreeBSD.org
gw	Graham Wheeler gram@oms.co.za
imp*	Warner Losh imp@FreeBSD.org
jb	Jim Bresler jfb11@inlink.com
jh	Jake Hamby jehamby@lightside.com
jha	John H. Aughey jha@cs.purdue.edu
jk	Jerry Kendall Jerry@kcis.com
jkh*	Jordan K. Hubbard jkh@FreeBSD.org
jm	Josef Moellers mollers.pad@sni.de
jmb*	Jonathan M. Bresler jmb@FreeBSD.org
joe*	Joe Greco jgreco@solaria.sol.net
ka	Kalganov Alexander top@bird.cris.net
ki	Kenneth Ingham ingham@i-pi.com
ky*	Kazutaka YOKOTA yokota@zodiac.mech.utsunomiya-u.ac.jp
marc	Marc Slemko marcs@znep.com
md*	Matt Dillon dillon@best.net
mr	Mike Romaniw msr@cuc.com
mrvm*	Mark Murray mark@grondar.za
mu	Mudge mudge@l0pht.com
or*	Ollivier Robert roberto@keltia.freenix.fr
pb	Peter Blake ppb@baloo.tcp.co.uk
peter*	Peter Wemm peter@FreeBSD.org
phk*	Poul-Henning Kamp phk@FreeBSD.org
pst*	Paul Traina pst@FreeBSD.org
rb	Reinier Bezuidenhout rbezuide@oskar.nanoteq.co.za
rd	Rajiv Dighe rajivd@sprynet.com
rel	Roger Espel Llima espel@llaic.univ-bpclermont.fr
rjk	Richard J Kuhns rjk@grauel.com
rm	Robin Melville robmel@nadt.org.uk
rs	Robert Sexton robert@kudra.com
sc	Sergei Chechetkin csl@whale.sunbay.crimea.ua
tao	Brian Tao taob@risc.org
tdr	Thomas David Rivers ponds!rivers@dg-rtp.dg.com
vk	Vadim Kolontsov vadim@tversu.ac.ru
witr	Robert Withrow witr@rwwa.com
xaa	Mark Huizer xaa@stack.nl

* = Has CVS commit privileges.

&footer; diff --git a/en/availability.sgml b/en/availability.sgml index 30a6cc6ad9..c0b8cd96ea 100644 --- a/en/availability.sgml +++ b/en/availability.sgml @@ -1,83 +1,83 @@ + %includes; ]> &header;

Availability of FreeBSD

FreeBSD is free and is available for downloading over the Internet or on CDROM for a small fee.

Hardware requirements.

FreeBSD runs on a variety of PC and Alpha hardware. Please review - the supported - configurations section of the FreeBSD + the supported + configurations section of the FreeBSD Handbook for more information.

Where to get it.

FreeBSD can be downloaded over the Internet for free, using a variety of different protocols (FTP, CVS, AFS, and more). If bandwidth is expensive for you then it can also be purchased on CDROM from a variety of vendors.

For more information on obtaining FreeBSD, please see the Handbook Chapter on obtaining + href="doc/en_US.ISO8859-1/books/handbook/mirrors.html">Handbook Chapter on obtaining FreeBSD.

For more information on installing FreeBSD, please see the Handbook Chapter on + href="doc/en_US.ISO8859-1/books/handbook/install.html">Handbook Chapter on installing FreeBSD.

About the FreeBSD Project.

FreeBSD is developed and supported by a worldwide team of programmers. Jordan Hubbard, one of the project's founders, has written a brief history + href="doc/en_US.ISO8859-1/books/handbook/history.html">brief history of the FreeBSD project. Information about who's responsible for what + href="doc/en_US.ISO8859-1/books/handbook/staff-who.html">who's responsible for what is also available. If you are curious, take a look at some pictures of the team members. A more complete listing of contributors is available in the Contributors section of the - FreeBSD Handbook. FreeBSD is + href="doc/en_US.ISO8859-1/books/handbook/contrib.html">Contributors section of the + FreeBSD Handbook. FreeBSD is an open project, and welcomes the help of individuals who have time and or skills to offer.

This "about" section was created by Sean Kelly.

Inside your PC is a daemon waiting to be unleashed. Free it with FreeBSD.

&footer; diff --git a/en/internal/about.sgml b/en/internal/about.sgml index 3e0f39b581..0d0798d48a 100644 --- a/en/internal/about.sgml +++ b/en/internal/about.sgml @@ -1,90 +1,90 @@ - + %includes; ]> &header;

The Machine

The machine www.FreeBSD.org, otherwise known as freefall.FreeBSD.org, is 800MHz Pentium III set up with 1024 megabytes of RAM and about 50 gigabytes of disk space. The mail duties for the domain are handled by hub.FreeBSD.org, a 400 MHz Pentium II with 256 megabytes RAM and about 16 gigabytes disk space.

Naturally, these systems all run FreeBSD. The hardware and network connection have been generously provided by BSDi, Yahoo!, and other contributors to the FreeBSD project. + href="../doc/en_US.ISO8859-1/books/handbook/donors.html">contributors to the FreeBSD project.

A complete list of all host names in the FreeBSD.org domain is available at the The FreeBSD.org Network page.

The Software

These pages are served up by the versatile and efficient Apache http server. In addition, there are a few locally crafted CGI scripts. Indexing of these pages and the mailing list archive are provided by freewais-sf, a derivative of the CNIDR freewais.

The Urchin web statistics package is used to provide these statistics on web server usage.

The Pages

These Web pages have been put together by John Fieber <jfieber@FreeBSD.org> with input from the FreeBSD community and you. The Webmaster is <wosch@FreeBSD.org>. The FreeBSD pages are HTML 3.2 compliant and best viewed with your browser.

See also the FreeBSD Documentation Project

Page Design

Original page design by Megan McCormack

Building and updating the FreeBSD Web Pages

&webbuild;

Update of the FreeBSD Web Pages

The FreeBSD Web Pages are updated daily at 0800 and 2000 UTC.

Mirroring the FreeBSD Web Pages

You can (and are encouraged to) mirror the FreeBSD web pages on www.FreeBSD.org.

Usage statistics for this server are updated daily.

FreeBSD Internal Home &footer; diff --git a/en/internal/mirror.sgml b/en/internal/mirror.sgml index b0f89c8c6f..61cb8493f4 100644 --- a/en/internal/mirror.sgml +++ b/en/internal/mirror.sgml @@ -1,61 +1,61 @@ - + %includes; ]> &header;

You can (and are encouraged to) mirror the FreeBSD web pages www.FreeBSD.org. To do this, you need to obtain and install a program called cvsup on your web server. -CVSup is a software package for +CVSup is a software package for distributing and updating collections of files across a network.

Installing CVSup

To build and install it, do the following:

  # cd /usr/ports/net/cvsup-bin
  # make all install clean

Running CVSup

If you keep your mirrored FreeBSD web pages in the directory /usr/FreeBSD-mirror and are owned by the user `fred', then run the following command as user `fred':

      $ cvsup supfile-www

The file supfile-www contain:

        *default host=cvsup.FreeBSD.org
        *default prefix=/usr/FreeBSD-mirror
        *default base=/usr/local/etc/cvsup
        www release=current delete use-rel-suffix compress

This will mirror the FreeBSD web pages into /usr/FreeBSD-mirror. You can install this into fred's crontab, so that it runs once a day. The pages on www.FreeBSD.org are updated daily at about 4:30am California time.

More Information on CVSup

-See the CVSup introduction in the +See the CVSup introduction in the handbook.

FreeBSD Internal Home &footer; diff --git a/en/java/docs/howtoports.sgml b/en/java/docs/howtoports.sgml index b04d4a0a43..ff35aabf4d 100644 --- a/en/java/docs/howtoports.sgml +++ b/en/java/docs/howtoports.sgml @@ -1,34 +1,34 @@ - + %includes; ]> &header;

General instructions can be found in the FreeBSD Handbook, under Porting Applications. +

General instructions can be found in the FreeBSD Handbook, under Porting Applications.

For Java ports, there are unofficial standards:

     1) If it's a library then jar files go into:
           /usr/local/share/java/classes/
 
     2) If it's a stand-alone application then jar files go into:
           /usr/local/share/java/<application-name>/
         and  scripts to run it go into:
           /usr/local/bin/
 
     3) Documentation goes into:
           /usr/local/share/doc/java/<application-name>/

The more ported applications we have, the better.

&footer; diff --git a/en/java/install.sgml b/en/java/install.sgml index 974791be01..106b4289b2 100644 --- a/en/java/install.sgml +++ b/en/java/install.sgml @@ -1,29 +1,29 @@ - + %includes; ]> &header;

Installing FreeBSD's JDK is typically straightforward:

cd /usr/ports/java/jdk make make install make clean

The JDK does not require any dependencies to install. However, if you wish to run any graphics, you will need to have X installed and running.

Many applications in Java need Java Foundation Classes (Swing) to run. JFC can be installed in: /usr/ports/java/jfc -

If you should have trouble, you can see the FreeBSD Handbook section on "installing applications" for help. +

If you should have trouble, you can see the FreeBSD Handbook section on "installing applications" for help.

&footer; diff --git a/en/mailto.sgml b/en/mailto.sgml index 2f3c318a8f..842bcdd82f 100644 --- a/en/mailto.sgml +++ b/en/mailto.sgml @@ -1,52 +1,52 @@ + %includes; ]> &header;

Questions about FreeBSD...

Questions regarding FreeBSD should be addressed to the FreeBSD Questions mailing list, freebsd-questions@FreeBSD.ORG.

Mailing lists are the primary support channel for FreeBSD users, with numerous mailing lists covering different topic areas. Several non-English mailing lists are also available.

Questions about the contents of this WWW server...

Questions or suggestions about our documentation (Handbook, FAQ, Handbook, FAQ, Tutorials) should be addressed to the FreeBSD Documentation Project mailing list, freebsd-doc@FreeBSD.ORG.

Snail mail, phone and fax

For CDROM orders: The FreeBSD Mall

For commercial support: The FreeBSD Mall

Who Is Responsible for What

Public Relations & Corporate Liaison, Security Officer, Postmaster, Webmaster etc.

&footer; diff --git a/en/news/1997/index.sgml b/en/news/1997/index.sgml index e2e70cf6bc..938573c6e0 100644 --- a/en/news/1997/index.sgml +++ b/en/news/1997/index.sgml @@ -1,272 +1,272 @@ - + %includes; News Home'> %newsincludes; ]> &header;

December 1997

26-Dec-97 A convenient front-end tool for installing and - configuring the CVSup + configuring the CVSup utility is now available. To use it, simply login or su to root and run: pkg_add &ftp;/development/CVSup/cvsupit.tgz
2-Dec-97 The "FOOF" bug has now been fixed in our 3.0-current and 2.2-stable branches and can either be incorporated - by using the CVSup + by using the CVSup utility, as described below for the LAND attack fix, or by applying these patches.
1-Dec-97 The "LAND attack" bug in TCP/IP has now been fixed in all relevant branches and can be incorporated by using the CVSup utility to track + href="../doc/en_US.ISO8859-1/books/handbook/synching.html#CVSUP">CVSup utility to track the latest 2.2 or 3.0 sources.
1-Dec-97 Team FreeBSD is a group of FreeBSD users and supporters contributing CPU idle time in an effort to crack RSA's 64-bit encryption code. For more information, visit Team FreeBSD's WWW site.

November 1997

21-Nov-97 Pentium bug -- We are aware of the "F00F" Pentium halting bug and are working with Intel on a fix. When we have a fix ready for public consumption it will be announced here, on the mailing list announce@FreeBSD.org and to the Usenet newsgroup comp.unix.bsd.freebsd.announce. Your patience is appreciated.
09-Nov-97 FreeBSD 2.2.5-RELEASE CDROMS are now in stock and shipping to customers worldwide. More information is available at http://www.wccdrom.com/titles/os/fbsd25.htm.

October 1997

22-Oct-97 FreeBSD 2.2.5 has been released. See the Release Information page for details. Also be sure to check the release errata after installation for any late-breaking issues with 2.2.5 that you should know about.

September 1997

01-Sep-97 FreeBSD performed well in an Internet Week review of WWW server platforms.

August 1997

11-Aug-97 Researchers in Duke University's Trapeze Project have developed a high-speed Myrinet driver for FreeBSD. More information about the driver, Trapeze Project, and its parent project, the Collaborative Cluster Computing Iniative, including the code for the Myrinet driver, are available from the CCCI's WWW page.
03-Aug-97 Netscape Communications has released a beta version of Netscape Communicator v4.0 for FreeBSD. It can be obtained via FTP from ftp.netscape.com or its mirrors.

July 1997

22-Jul-97 MacIP, an AppleTalk-to-IP gateway program for FreeBSD, is in beta testing. To get the latest version, see http://www.promo.de/pub/people/stefan/netatalk/ or ftp://ftp.promo.de/pub/people/stefan/netatalk/.
17-Jul-97 The first issue of the FreeBSD Newsletter is now available in Adobe PDF format (also by FTP). A help file is available to assist you in selecting and using a PDF viewer. Article submissions, advertisements, and letters to the editor should be sent to newsletter@FreeBSD.org.

June 1997

17-Jun-97 FreeBSD 2.2.2-RELEASE CD-ROM discs are now in stock; subscription customers should receive them shortly.

May 1997

16-May-97 FreeBSD 2.2.2-RELEASE has been released. The Release Notes and Errata List can provide more information.
12-May-97 A 3.0-Current SNAP-of-the-day server has been established at ftp://current.FreeBSD.org/pub/FreeBSD/. A 3.0-SNAPshot will be generated daily, and old SNAPshots will be kept for a minimum of one week.

April 1997

28-Apr-97 The 3.0-current src tree now contains support for building Symmetric MultiProcessor kernels. For details go to the SMP page.
22-Apr-97 A RELENG_2.2 snap-of-the-day server has been established at ftp://releng22.FreeBSD.org/pub/FreeBSD. The README.TXT has more information.
15-Apr-97 FreeBSD 2.2.1-RELEASE CDs are shipping. Please see http://www.wccdrom.com/titles/os/fbsd22.htm for more information.

March 1997

28-Mar-97 Sony Computer Science Laboratory, Inc. has released an alpha version of ALTQ/CBQ, an alternative queuing framework for BSD Unix. More information and the source code is available.
25-Mar-97 FreeBSD 2.2.1-RELEASE is now available, replacing 2.2-RELEASE. Read the README.TXT file or the Release Notes for more information.
16-Mar-97 FreeBSD 2.2-RELEASE is now available. Read the README.TXT file or the Release Notes for more information.

February 1997

20-Feb-1997 FreeBSD 2.1.7-RELEASE is now available. Read the README.TXT file or the Release Notes for more information.
10-Feb-1997 FreeBSD 3.0-970209-SNAP has been released. Read the README.TXT file for more information about this release.
06-Feb-1997 A serious security problem affecting FreeBSD 2.1.6 and earlier systems was found. The problem has been corrected within the -stable, -current, and RELENG_2_2 source trees. As an additional precaution, FreeBSD 2.1.6 is no longer available from the FTP distribution sites. You can read more about the problem and solution from the FreeBSD-SA-97:01.setlocale security announcement.
06-Feb-1997 The final pre-release version of FreeBSD 2.2-GAMMA, is now available. The README.TXT file has more information.
02-Feb-1997 A snap-of-the-day server has been set up for the most current snapshot release of FreeBSD 2.2. Read the README.TXT file for more information.

January 1997

25-Jan-1997 FreeBSD 3.0-970124-SNAP has been released. Please see the Release Notes for more information.

&newshome; &footer; diff --git a/en/news/1998/index.sgml b/en/news/1998/index.sgml index 46316ba04d..4546afe3ab 100644 --- a/en/news/1998/index.sgml +++ b/en/news/1998/index.sgml @@ -1,242 +1,242 @@ - + %includes; News Home'> %newsincludes; ]> &header;

December 1998

28-Dec-98 Unless circumstances dictate otherwise, FreeBSD 3.0 will depart the -CURRENT branch late in the day on 15 January 1999. The 3.1 release will follow 30 days later, on 15 February 1999. Developers should consider this as ADVANCE NOTICE of these events.
13-Dec-98 Walnut Creek CDROM has opened the FreeBSD Mall, a site devoted to the commercial aspects of FreeBSD, including add-ons, hardware, and commercial tech-support. To advertise or sell your products or services at the FreeBSD Mall, contact BSDi.

November 1998

30-Nov-98 FreeBSD 2.2.8 has been released. Please see the Release Information page for more details. Also be sure to check the release errata after installation for any late-breaking issues with 2.2.8 that you might need to be aware of.
26-Nov-98 FreeBSD Rocks is an initiative designed to provide the FreeBSD community with the latest FreeBSD news, software and resources. All areas include search facilities, making keyword searching of historical posts a breeze. The pages are updated daily and everyone is invited to sign up an post an article. If it happened today, you'll see it on FreeBSDRocks.

October 1998

15-Oct-98 FreeBSD 3.0 has been released. See the Release Information page for details. Also be sure to check the release errata after installation for any late-breaking issues with 3.0 that you might need to be aware of.

September 1998

15-Sep-98 September 15th is the scheduled date for entering BETA with the 3.0-CURRENT tree. As all of you already (should) know, 3.0 is scheduled for release on October 15th so this gives us a nice 30 day BETA period. During this time, I don't expect anyone to drop in significant new work or otherwise perturb the 3.0-CURRENT tree in such a way that violates the general idea of a BETA (you're supposed to test what you have, not move the goalposts every couple of days :).
13-Sep-98 After more than a year of development, the Common Access Method SCSI layer for FreeBSD will be integrated into 3.0-CURRENT on Sunday, September 13th. The CAM development team is currently busy ensuring that the integration process goes as smoothly as possible, so please understand that we may be slow to respond to questions about CAM during that time.
09-Sep-98 Perl5 is now imported into the 3.0-CURRENT source tree.
05-Sep-98 The BSD CD Giveaway List. If somebody has a CD to give away (recipient pays for shipping) or to lend locally, they can put their email address on the list. Hardware and literature can also be given away. We encourage people to donate CDs to local libraries and put them on the list as well.
01-Sep-98 First issue of Daemon News arrives day earlier. This ezine is by the BSD community for the BSD community. See http://www.daemonnews.org/

August 1998

31-Aug-98 FreeBSD -CURRENT branch (the future 3.0-RELEASE) has switched to ELF from a.out format. People involved did a great job; transition went smooth. Check the freebsd-current@FreeBSD.org mail archive for more information on the transition to ELF.
23-Aug-98 Suidcontrol-0.1 utility has been released. The suidcontrol is an experimental utility for managing suid/sgid policy under FreeBSD. You can get more information at http://www.watson.org/fbsd-hardening/suidcontrol.html
09-Aug-98 FreeBSD Security How-To has been published. This work is currently in beta and can be found at http://www.best.com/~jkb/howto.txt

July 1998

22-Jul-98 FreeBSD 2.2.7 has been released. See the Release Information page for details. Also be sure to check the release errata after installation for any late-breaking issues with 2.2.7 that you should know about.
16-Jul-98 A ``FreeBSD for Linux users'' documentation effort has started. Please see the list of current documentation projects for more information.
13-Jul-98 Jordan Hubbard writes an editorial on the past and future of the Unix community.
09-Jul-98 A Spanish - translation of the FAQ has been + translation of the FAQ has been completed by the Spanish Documentation Project. More information can be found at the translations page.

May 1998

30-May-98 FreeBSD and Apache are used in this very useful article on implementing a web farm using round-robin DNS in WEBTechniques.com.
23-May-98 The second issue of the FreeBSD Newsletter is now available in Adobe PDF format (also by FTP). A help file is available to assist you in selecting and using a PDF viewer. Article submissions, advertisements, and letters to the editor should be sent to newsletter@FreeBSD.org.
01-May-98 The FreeBSD Project set up Anonymous CVS for the + href="&base;/doc/en_US.ISO8859-1/books/handbook/synching.html#ANONCVS">Anonymous CVS for the FreeBSD CVS tree. Among other things, it allows users of FreeBSD to perform, with no special privileges, read-only CVS operations against one of the FreeBSD project's official anoncvs servers.

April 1998

16-Apr-98 The new 4 CD set of FreeBSD 2.2.6 is now in stock and should start shipping to subscription and back-order customers tomorrow. More information on the CD contents are available from http://www.wccdrom.com/.
11-Apr-98 The new FreeBSD project FreeBSD Mozilla Group is created. The FreeBSD Mozilla Group supports and improves the free available Netscape web browser, otherwise known as Mozilla.

March 1998

25-Mar-98 FreeBSD 2.2.6 has been released. See the Release Information page for details. Also be sure to check the release errata after installation for any late-breaking issues with 2.2.6 that you should know about.

February 1998

08-Feb-98 A page detailing the FreeBSD Year 2000 compliance statement is now available, linked through the Documentation page.

January 1998

08-Jan-98 Improved support for Plug-n-Play cards has now been integrated into both 3.0-CURRENT and 2.2-STABLE branches now. This is available in source form via the CVSup utility or in + href="&base;/doc/en_US.ISO8859-1/books/handbook/synching.html#CVSUP">CVSup utility or in binary release snapshots from current.FreeBSD.org

&newshome; &footer; diff --git a/en/news/2000/index.sgml b/en/news/2000/index.sgml index ab135f5f0b..1dc8e10c1c 100644 --- a/en/news/2000/index.sgml +++ b/en/news/2000/index.sgml @@ -1,456 +1,456 @@ - + %includes; News Home'> %newsincludes; ]> &header;

December 2000

28-Dec-2000 New committer: FUJISHIMA Satsuki (ports)
06-Dec-2000 New committer: Clive T. Lin
04-Dec-2000 New committers: Christoph Herrmann and Thomas-Henning von Kamptz (growfs)
01-Dec-2000 New committer: Ian Dowse

November 2000

30-Nov-2000 Individual porting efforts were moved into the platforms directory. Separate pages for the Alpha, IA-64, PowerPC, and SPARC porting projects can be found there.
22-Nov-2000 FreeBSD 4.2 has been released. Please see the Release Information page for more details. Also be sure to check the release errata after installation for any late-breaking issues with 4.2 that occur.
22-Nov-2000 And yet another new committer: Peter Pentchev (ports)
13-Nov-2000 Yet another new committer: OKAZAKI Tetsurou (ports)
13-Nov-2000 Another new committer: Kazuhiko Kiriyama (ports)
13-Nov-2000 New committer: Dmitry Sivachenko (Mainly ports)
12-Nov-2000 Another new committer: Issei Suzuki (Ports)
06-Nov-2000 Another new committer: Jing-Tang Keith Jang (ports, mostly in the chinese category)
02-Nov-2000 Another new committer: Benno Rice (PowerPC port and OpenFirmware /boot/loader)

October 2000

26-Oct-2000 Yet another new committer: Doug Barton (mergemaster, and whatever other trouble I can get into)
26-Oct-2000 A new committer: Garance A Drosehn (lpr and friends)
18-Oct-2000 New FreeBSD Core Team Elected! Read the official press release for more information.
16-Oct-2000 A new committer: Jonathan Chen (newcard cardbus)
03-Oct-2000 The complete track schedule for BSDCon has been released. BSDCon is the premiere annual technical conference for BSD users and will be held from October 14-20 in Monterey, CA.
02-Oct-2000 Doug Rabson has made a series of commits to -CURRENT with early IA64 support. The kernel will now reach the mountroot prompt. Please follow the ia64 mailing list for more information.
01-Oct-2000 A new committer: Trevor Johnson (sundry ports, mostly in the audio category)
01-Oct-2000 A new committer: James Housley (ports, especially RTEMS. Side interest in IPv6)
01-Oct-2000 A new committer: Mário Sérgio Fujikawa Ferreira

September 2000

29-Sep-2000 TeraSolutions, Inc. and Lightning Internet Services announced today that a popular OpenSource software archive at ftp.freesoftware.com (also known as ftp.FreeBSD.org) has surpassed the two trillion bytes (two terabytes) milestone of files downloaded per day from a single server machine.
27-Sep-2000 FreeBSD 4.1.1 has been released. Please see the Release Information page for more details. Also be sure to check the release errata after installation for any late-breaking issues with 4.1.1 that occur.
21-Sep-2000 A new committer: Bosko Milekic

August 2000

22-Aug-2000 A new committer: Bruce A. Mah (docs, pkg_version, assorted ports)
15-Aug-2000 A new committer: Rajesh Vaidheeswarran (ports/devel/cons)
05-Aug-2000 A new committer: Atsushi Onoe (awi driver)

July 2000

27-July-2000 FreeBSD 4.1 has been released. Please see the Release Information page for more details. Also be sure to check the release errata after installation for any late-breaking issues with 4.1 that occur.
12-July-2000 A new committer: Mark Ovens
11-July-2000 A new committer: Kelly Yancey
11-July-2000 A new committer: David Malone
11-July-2000 A new committer: Noriaki Mitsunaga (PC-Card)
10-July-2000 A new committer: Ben Smithurst (Docs)
08-July-2000 A new committer: Daniel Harris (Docs)
07-July-2000 A new committer: Takanori Watanabe (ACPI)
06-July-2000 A new committer: Hiroki Sato (Japanese Docs)
05-July-2000 A new committer: Kazuo Horikawa (Japanese Online Manuals)
03-July-2000 A new committer: Adrian Chadd

June 2000

30-June-2000 http://freshports.org/ has been upgraded to FreshPorts 1.1. The FreshPorts website contains the latest details of which ports have been create/updated/removed. This upgrade, the first since FreshPorts was release in early May, gives you an improved home page, which together with a commit history means you can find out about your ports faster and easier.
29-June-2000 Tucows has added a BSD section.
26-June-2000 A new committer: Shunsuke Akiyama (Optical disk driver)
24-June-2000 FreeBSD 3.5 has been released. Please see the Release Information page for more details. Also be sure to check the release errata after installation for any late-breaking issues with 3.5 that occur.
20-June-2000 A new committer: MIHIRA Sanpei Yoshiro (PC-Card)

A new committer: Coleman Kane (3dfx voodoo for glide/Mesa)
19-June-2000 A new committer: CHOI Junho (Ports)
08-June-2000 Jordan Hubbard and Warner Losh will be in Japan during the first part of June 2000. They will be giving talks at: the BSD BOF at Networld+Interop 2000 Tokyo (8th), the JUS seminor at Tokyo (9th), the NBUG event at Nagoya (10th), and, the K*BUG seminor at Osaka (10th). Please see http://www.jp.FreeBSD.org/.

A new article is available, explaining how to use PPP, natd, and ipfw to implement a firewall with a PPP dialup connection.

A new committer: Alexander Langer (Ports, Docs)
06-Jun-2000 The first FreeBSD Conspectus has been added, providing a summary of events on the -stable mailing list over the past week.

May 2000

19-May-2000 A new committer: Chuck Paterson (SMP)
18-May-2000 - A hardcopy version of the FreeBSD + A hardcopy version of the FreeBSD Handbook is now available. If you would like to order a copy, please visit the FreeBSDMall, or BSDi's web site.
15-May-2000 A new committer: Jake Burkholder (legacy drivers)
14-May-2000 Issue #04 of The FreeBSD 'zine is now available.
09-May-2000 Freshports: Similar in nature to Freshmeat, this site deals exclusively with FreeBSD ports, and allows you to create your own ``watch lists'' for your favorite ports.

April 2000

16-Apr-2000 New mailing lists available: freebsd-i18n (FreeBSD Internationalization) and freebsd-ppc (Porting FreeBSD to the PowerPC)
04-Apr-2000 A new committer: Murray Stokely (sysinstall)

March 2000

22-Mar-2000 A new committer: Akinori MUSHA (Ports)
21-Mar-2000 Bill Swingle has written an article on the Ports and Packages System for 32bitsonline.com
20-Mar-2000 A new committer: Will Andrews (Ports)
15-Mar-2000 Issue #2 of The FreeBSD 'zine is now available.
13-Mar-2000 FreeBSD 4.0 has been released. Please see the Release Information page for more details. Also be sure to check the release errata after installation for any late-breaking issues with 4.0 that occur.
09-Mar-2000 Walnut Creek CDROM and BSDI merge! Read the official press release for more information.

February 2000

26-Feb-2000 A new committer: Hajimu UMEMOTO (IPv6)
23-Feb-2000 A new committer: Paul Saab
22-Feb-2000 32BitsOnline.com has a review of FreeBSD 3.4 by Clifford Smith available on their web site. All in all, a good review.
18-Feb-2000 A new committer: Brian S Dean (Kernel support for IA32 hardware debug registers, misc fixes/feature enhancements in other areas)
17-Feb-2000 A new issue of The FreeBSD 'zine came out on the 15th. This is the first issue of the 'zine in 7 months; lots of changes have been made, and many new features have been added. Be sure to check it out.
10-Feb-2000 Michael Lucas has written an excellent article on the differences between the BSD license and the GPL. This article is definitely worth reading.

New committers: Greg Sutter and Bill Swingle (Docs)

January 2000

22-Jan-2000 The FreeBSD Diary, a chronicle of what one guy is doing with FreeBSD, has been around for almost two years. Until today, it was tucked away in a corner of his site. Following significant growth, a new-look site was launched today. The site contains a huge number of how-to guides and the readership includes NetBSD, OpenBSD, and Linux users.
13-Jan-2000 A new committer: Wilko Bulte
04-Jan-2000 The Compaq Testdrive program is now making testdrives available of the latest FreeBSD 4.0-20000101-CURRENT release running on an Alpha XP1000 EV6.7. running at 667MHz and loaded with two gigs of ram. To get a free shell account as a participant in the testdrive program, all you need to do is register at the site. These accounts aren't for playing, the goal of the program is to make brand new systems available to developers so they can test, build and port their apps to the world's fastest computer. The testdrive program also offers other systems running FreeBSD, including a Proliant 5500 dual Xeon 450MHz and a DPW500a.
03-Jan-2000 A new committer: Patrick Gardella (JDK/WWW)
02-Jan-2000 A new committer: Ade Lovett (Ports)
01-Jan-2000 A new committer: Jeremy Lea (Ports)

&newshome; &footer; diff --git a/en/news/press-rel-2.sgml b/en/news/press-rel-2.sgml index 2145f5442b..6f9970ef2f 100644 --- a/en/news/press-rel-2.sgml +++ b/en/news/press-rel-2.sgml @@ -1,89 +1,89 @@ - + %includes; %newsincludes; ]> &header;

Complete XML Development System Integrated with FreeBSD

Concord, CA, April 29, 1999: Included with FreeBSD 3.1 is a complete, integrated SGML/XML development system that installs with a simple, easy to use command sequence.

FreeBSD's Ports system and multitasking architecture makes it easy for an SGML/XML developer to download and install all the latest versions of the tools and reference material he needs to develop SGML and XML formatting languages and documents, and the online Internet mailing lists help him learn and keep up-to-date with the evolving XML implementation.

FreeBSD is a full-featured open-source operating system which runs on virtually all Intel x86-based personal computers. Its 580 page "Handbook" has recently been completely done over into DocBook format, and it is a living example of an evolving document built with SGML tools. The Handbook is available on the Internet at:

The FreeBSD Documentation Project is also making available the "FreeBSD Documentation Project Primer" to make it as painless as possible for newcomers to contribute to the FreeBSD Documentation Set. Much of the information in the primer is appropriate to all SGML/XML users, and is freely available. The primer, which is constantly being updated by the Documentation Project team, can be found at:

http://www.FreeBSD.org/tutorials/primer/

Features of the Document Project SGML/XML System include:

James Clark's Jade 1.2.1 and SP suite version 1.3.3, enabling formatting and validation of SGML and XML documents.
A complete set of 19 ISO SGML character set entities
The DocBook (v2.4.1, v3.0, v3.1), HTML (all versions), and LinuxDoc Document Type Definitions (DTD)
Norm Walsh's Modular DocBook Stylesheets, allowing fine control over the appearance and formatting of DocBook documents.
Emacs and Xemacs, in conjunction with the PSGML extension package, provide a customizable industrial-strength SGML editing solution.
The teTeX-beta package in conjunction with the JadeTeX macros make it possible to convert DocBook documents to DVI, Postscript, and PDF formats with embedded hyperlinks.
Additional SGML-aware programs and utilities can be found in the FreeBSD ports system.

The FreeBSD Documentation Project is actively migrating from the LinuxDoc DTD to the DocBook DTD, and has been providing feedback to the DocBook maintainers regarding new features and possible implementations for the past year. For more information about the FreeBSD Documentation Project, please contact the freebsd-doc@FreeBSD.org mailing list.

The FreeBSD operating system is available on the Internet from the master FreeBSD website and from various mirror systems around the world, and it can also be obtained on convenient CDROMs from Walnut Creek CDROM. Information on all of these options is available through:

&footer; diff --git a/en/projects/cvsweb.sgml b/en/projects/cvsweb.sgml index efa55091f2..883cf4bda1 100644 --- a/en/projects/cvsweb.sgml +++ b/en/projects/cvsweb.sgml @@ -1,91 +1,91 @@ - + %includes; ]> &header;

What is CVSweb?
Downloads
Resources

What is CVSweb?

CVSweb is a WWW interface for CVS repositories with which you can browse a file hierarchy on your browser to view each file's revision history in a very handy manner.

CVSweb was originally written by &a.fenner; for the FreeBSD Project, and instantly won great popularity among software developpers for its usability.

FreeBSD-CVSweb, formerly known as knu-CVSweb, is an enhanced version of CVSweb based on and has been kept in sync with Henner Zeller's CVSweb, which is an extended version of CVSweb. &a.knu; made numerous cleanups, bug-fixes, security enhancements and feature improvements over the version and brought it back where it was born. FreeBSD-CVSweb is currently maintained by &a.scop;.

CVSweb is freely available under the terms of the BSD license. It is currently used by such projects as FreeBSD, XFree86, Perl, and Ruby.

Downloads

Download the tarball from the following sites. The latest release is 2.0.3.

Resources

Project Mailinglist:: freebsd-cvsweb@FreeBSD.org is the mailing list for people discussing the development of the FreeBSD CVSweb. Patches, bug reports and feature requests are welcome. To join the list, follow the instructions - described here.
CVS repository: CVSweb is available through - anonymous CVS pserver. + anonymous CVS pserver. The module name is /projects/cvsweb.
CVSweb on CVSweb: You can browse the CVSweb source via the CVSweb itself here.

&footer; diff --git a/en/projects/newbies.sgml b/en/projects/newbies.sgml index 0aff624238..97191c2f50 100644 --- a/en/projects/newbies.sgml +++ b/en/projects/newbies.sgml @@ -1,250 +1,250 @@ - + %includes; ]> &header;

The following resources are some of those which FreeBSD newbies have found most helpful when learning to use FreeBSD. Please send corrections and additions to FreeBSD-Newbies@FreeBSD.org.

Using the FreeBSD web site
Learning about FreeBSD
Learning about UNIX
Learning about the X Window System
Helping other people

Using the FreeBSD web site

This web site is the main source of up to date information about FreeBSD. Newbies have found the following pages particularly helpful:

Search the Handbook and FAQ, or the whole web site, or the archives of the FreeBSD-Questions mailing list.
The Documentation page has links to the Handbook and FAQ, tutorials, information about contributing to the Documentation Project, documents in languages other than English, and much more.
Support page contains a wealth of information about FreeBSD, including mailing lists, user groups, web and FTP sites, release information, and links to some sources of UNIX information.

Learning about FreeBSD

If you haven't installed yet, look for the latest mainstream release. (See the Handbook for why you should not be tempted by any of the other branches.) Before you begin, carefully read the - installation instructions, + installation instructions, as well as each one of the *.TXT files in the FTP directory or on the installation CD. They are there because they contain information that you will need. Also pick up the latest errata file from the web site, in case it has been updated.

If you decide to download FreeBSD, check whether these illustrated and expanded download instructions for a previous version are still available before you begin. That should make the whole process a lot clearer.
A number of short articles and tutorials are available. The short tutorial, For People New to Both FreeBSD and Unix, is popular with absolute beginners. You don't have to know much about anything to enjoy this one. It can also be downloaded in postscript or RTF format for printing.
The first thing many people need to set up is ppp, and there is a lot of documentation to help. You might start with at least those parts of the Pedantic PPP Primer that are relevant to your needs, and explore the ppp page for links to the other valuable information and the latest updates.
The Complete FreeBSD by Greg Lehey, published by BSDi. This book assumes minimal UNIX experience and takes the beginner step by step through each stage from installation to everything you need to know to set up and run a FreeBSD system. You also get to understand what you're doing and why.
The FreeBSD Handbook and Frequently Asked Questions (FAQ) are the +
The FreeBSD Handbook and Frequently Asked Questions (FAQ) are the main documents for FreeBSD. Essential reading, they contain a lot of material for newbies as well as some pretty advanced stuff. Don't worry if you can't understand the advanced sections. The handbook contains the installation instructions and also provides lists of books and on line resources, and the FAQ has a troubleshooting section.
Join the FreeBSD-Questions mailing list to see the questions you were too afraid to ask, and their answers. Subscribe by sending mail to majordomo@FreeBSD.org with "subscribe freebsd-questions" on its own in the message body (the subject doesn't matter). You can look up old questions and answers via the search page.
The main newsgroup for FreeBSD is comp.unix.bsd.freebsd.misc. You might want to keep an eye on comp.unix.bsd.freebsd.announce as well.
Man pages are good for reference but not always the best introduction for a novice. The more you work with man pages the more familiar they become. Some are very good for newbies, so always check them out. The ppp man page, for example, is more like a tutorial.

Learning about UNIX

Many of the problems we have as newbies come from being unfamiliar with the UNIX commands needed to fix our FreeBSD problems. Without a UNIX background you'll be faced with two things to learn at once. Fortunately a lot of resources are available to make this easier.

There are many easy books, such as the "Dummies" guides, in any large book shop. If you want something really easy, take a look at what is available and pick one that seems to speak your language. Pretty soon you will want to move on to a book that gives more coverage.
One book mentioned frequently by newbies is UNIX for the Impatient by Paul W. Abrahams and Bruce R. Larson, published by Addison-Wesley. It is intended both as a book for learning UNIX and a reference, and includes an introduction to UNIX concepts and handy chapter on using the X Window System.
Another popular book is UNIX Power Tools by Jerry Peek, Tim O'Reilly and Mike Loukides, published by O'Reilly and Associates. It is organised as a series of short articles each of which solves a problem, and these articles are cross-referenced to other articles with related material. Though not specifically aimed at newbies, the design makes it ideal for a newbie with a burning question or the odd few minutes to browse. More elementary material is near the front of the book, but there are short easy articles throughout.
A UNIX Introductory Course from Ohio State University is available online in HTML, postscript and Acrobat PDF formats.
UNIXhelp for Users is another introductory guide which is available in HTML at a mirror site near you, or can be installed on your own system.
UNIX questions are dealt with in the newsgroup comp.unix.questions and the associated Frequently Asked Questions. You can also get a copy of the FAQ from the RMIT FTP site. Newbies are likely to be most interested in sections 1 and 2 initially.
Another interesting newsgroup is comp.unix.user-friendly which also has a FAQ. Although this newsgroup is for discussing user-friendliness, it can contain some good information for newbies. The FAQ is also available by FTP.
Many other web sites hold lists of UNIX tutorials and reference material. One of the best places to start looking is the UNIX page at Yahoo!.

Learning about the X Window System

The X Window System is used with a number of operating systems, including FreeBSD. The documentation for X can be found at The XFree86 Project, Inc. Beware, much of this documentation is reference material which is likely to be difficult for newcomers to digest.

For basic information about installing, configuring and using the X Window System, three of the books mentioned above have sections dealing with X at beginner level: The FreeBSD Handbook, The Complete FreeBSD, and UNIX for the Impatient.
There is an easy and informative section on using the X Window System in the Linux Users' Guide. Interesting material will be found elsewhere in that document too, but remember that Linux does not always work exactly the same as FreeBSD.
Before you can get X running exactly the way you like, you will need to choose a window manager. Visit the Window Managers for X page and follow the link to the introduction to find out about window managers, then return and read "The Basics". Then go back and compare the different types that are available. (Bonus: there's another beginners guide to UNIX there too.) Most if not all of these window managers are available to install from the FreeBSD ports collection.

Helping other people

Everyone has something to contribute to the FreeBSD community, even newbies! Some are busy working with the new advocacy group and some have become involved with the Documentation Project as reviewers. Other FreeBSD newbies might have particular skills and experiences to share, either computer related or not, or just want to meet new newbies and make them feel welcome. There's always people around who help others simply because they like to. Write to FreeBSD Newbies for more information.

Friends who run FreeBSD are a great resource. No book can replace chatting on the phone or across a pizza with someone who has the same interests, enjoys similar accomplishments, and faces the same challenges. If you don't have many friends who use FreeBSD, consider using your old FreeBSD CDs to create some more :-)

User groups are good places to meet other FreeBSD users. If there's not one nearby, maybe you could start one.

Before talking to real humans about your new skills, you might want to check the Pronunciation Guide and the Jargon File :-)

On line we have the FreeBSD-Newbies mailing list for non-technical discussions about matters of interest to newbies. Another mailing list, FreeBSD-Questions, answers our questions about using FreeBSD.

&footer; diff --git a/en/projects/updater.sgml b/en/projects/updater.sgml index 395c35d932..432cdc33aa 100644 --- a/en/projects/updater.sgml +++ b/en/projects/updater.sgml @@ -1,239 +1,239 @@ - + %includes; Done"> In Progress"> Not Started"> ]> &header;

Goals
Design
Implementation
Code

Goals

The FreeBSD Binary Updater Project aims to provide a secure mechanism for the distribution of binary updates for FreeBSD. This project is complementary to the Open Packages and libh projects efforts and there should be very little overlap.

This system is a client / server mechanism that allows clients to install any known "profile" or release of FreeBSD over the network. Where a specific profile might contain a specific set of FreeBSD software to install, additional packages, and configuration actions that make it more ideal for a specific environment (ie FreeBSD 4.3 Secure Web server profile)

Our current implementation aims to abstract the actual ontology of the FreeBSD software collections so that future development in the direction of a more fine grained base system can be leveraged effectively without unnecessary reimplementation.

Design

"Profiles"

What the user sees as "top level objects" in the upgrade system are canned profiles. A profile can represent a given user's system configuration or a generic system template (web server, mail server, etc) that we provide.

Each profile consists of file entries and/or collection entries. A collection entry represents a grouped set of files like a package or what sysinstall calls a "distribution." Profiles exist on the server machine, though the client can also choose to cache copies for "tripwire" types of activities. Some typical profiles and their contents might look like this:

        [mysystem]                        [web-server]
         bin  4.2                          bin	   4.2
         bash 2.02                         manpages 4.2
         src  4.2                          apache   2.1
         xblaster 1.0

A collection can also have a specific version number associated with it or have a "floating" version number, meaning that it tracks whatever's newest for that entity.

Authentication

Users will authenticate with the server via a username / password scheme which allows them to access their custom profiles as well as any system-defined ones.

Binary packages from the server are signed using public key cryptography.

Upgrade Client

The client supports connecting to an upgrade server, authenticating a user, browsing existing profiles or creating new ones and downloading file data and "actions" from the server. New file data will be created in such a way that partial updates do not cause corruption and whole transactions are committed in reasonably atomic fashion.

The client will be implemented in a 3-stage process:

A set of libraries which implement the bulk of the client<->server mutt functionality.
A command-line version of the client which supports all available library functions.
A GUI version of the client which either wraps around the client or calls the library routines directly, dependinng on whichever makes the most sense.

Since a system can also be "upgraded" from a standing start, a next-generation installation tool could take care of the disklabelling filesystem formatting, and network setup then make heavy use of the client library to actually bring up a menu of available software and perform the installation.

Upgrade Server

The server supports connections by arbitrary numbers of clients and authenticating a user (or "anonymous" if the server is configured to support anonymous connections) for determining the available profiles.

Once the server receives a manifest (e.g. a set of collections) from a client machine and a server-side profile name to match it with, it goes looking through each collection to see if a newer version of that collection exists on the server or if there are any change deltas pending against the collection which are greater than the corresponding patchlevel of the collection in the client manifest.

Deltas and/or entire collections are sent to the client for unpacking along with any before/after actions for each delta or collection which should be executed on the client. Once the client has confirmed that all before/after actions and extraction of a given collection has completed successfully, it updates the stored profile and goes on to the next. If the transfer is interrupted at any point, the process can therefore pick up where it left off.

The upgrade server provides local storage for a certain amount of profile data depending on disk space constraints and can also be used as a way of cloning machines. The user installs one machine entirely according to taste and then uploads its profile. Each subsequent machine is installed from this profile and voila, an army of clones.

The server will probably not keep any truly client-side data like /etc/master.passwd or anything else it doesn't offer out of its own collections, but we can leave this decision open for later or make it a configuration option.

Implementation Details

Update Server

The update server is for the most part in a usable state. Information about profiles, collections, and actions are stored in a SQL database. A database abstraction layer talks calls the relevant hooks (MySQL and PostgreSQL supported at the moment) to service client requests. Using a relational database has made it very easy for us to change the organization of the data without spending time rewriting code. As we finalize our data structures it might be more efficient to move to BerkeleyDB or another solution but for now SQL has saved a lot of development time.

The server can be used to successfully install or upgrade a system to FreeBSD 4.X but there is a lot of polishing up to do and many additional features are needed.

Server TODO list :

Add ability to manage packages as they are currently defined and used in FreeBSD
Add mechanism to read the ontology of the FreeBSD src tree from an XML file, instead of hard coding this into a Perl script which generates the necessary database tables. This will provide much needed flexibility in the creation of profiles and software components. There should also provide a description for packages that can obviate subsets of what sysinstall currently calls the "base system" (e.g, a profile with Postfix instead of Sendmail, and all of the configuration dependencies that go along with that)
Add checksum information and provide a "tripwire"-like service to clients.

Update Client

The update client is not currently usable. At the moment, it consists of some code to perform the actual updates, and some quick code to test the various functions of the updater. Also, the client does not currently handle packages. Once this capability has been added, and the various ugly bugs have been worked out, the existing code needs to be turned into a library.

From there, it will possible to easily create an installer as well as an end-user upgrade program, in forms of a text application, an X application, and maybe even big eye candy GNOME and KDE applications as well.

Client TODO list :

add copyright/license information to all various source files
conform to style(9)
serious bug removal
add ability to manage packages
turn into a library

Where's the Code?

This project is currently being developed in main FreeBSD CVS repository. Its sources are located under projects/binup hierarchy. You can use the usual methods of retrieving FreeBSD sources to access it. NOTE: cvsup users should use projects-all cvsup collection to access projects under projects/ hierarchy

A mailing list has been setup for this project. Please post all questions, patches, etc to the freebsd-binup@FreeBSD.org mailing list. For instructions on how to subscribe to thsi list, please see the FreeBSD + href="../doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">FreeBSD Handbook

&footer; diff --git a/en/publish.sgml b/en/publish.sgml index cd488ed2aa..60646b17da 100644 --- a/en/publish.sgml +++ b/en/publish.sgml @@ -1,580 +1,580 @@ + %includes; ]> &header;

BOOKS
CDROMS
MAGAZINES
NEWSLETTER
PRESS

Here you'll find the covers of many FreeBSD related publications. If you know of any additional FreeBSD publications/CDROMs let us know, at www@FreeBSD.org, so that they may be added to this site. -

The FreeBSD Handbook contains a +

The FreeBSD Handbook contains a considerably longer bibliography.

+ href="doc/en_US.ISO8859-1/books/handbook/bibliography.html">bibliography.

Click on any of the graphics to see a larger version.

Books

	This is a recent (May 1997) publication from Tatsumi Hosokawa and others. Among computer books, it is a top-seller in Japan and exceeded the sales of Bill Gates' "The Road Ahead" when published (it was #2, this book was #1).
	(Japanese FreeBSD book with 2.0.5, titled "FreeBSD: Fun and easy Installation")
	(Japanese FreeBSD book with 2.0.5, titled "FreeBSD Introductory Kit")
	This is BSDi's "The Complete FreeBSD" with installation guide, manual pages and installation CDs inside.
	This book was recently published (early 1997) in Taiwan. Its title is "FreeBSD: introduction and applications" and the author is Jian-Da Li.
	This is the "Getting Started with FreeBSD" from Fuki-Shuppan. Other than the standard installation guide and Japanese environment, it emphasizes system administration and low-level information (such as the boot process, etc.) FreeBSD-2.2.2R and XFree86-3.2 on CDROM. 264 pages, 3,400 yen.
	The "Personal Unix Starter Kit - FreeBSD" from ASCII. Includes history of Unix, a guide to build a Japanese documentation processing system and how to create ports. 2.1.7.1R and XFree86-3.2 in CDROM. 384 pages, 3,000 yen.
	BSD mit Methode, M. Schulze, B. Roehrig, M. Hoelzer und andere, C&L Computer und Literatur Verlag, 1998, 850 pages. 2 CDROMs, FreeBSD 2.2.6, NetBSD 1.2.1 and 1.3.2, OpenBSD 2.2 and 2.3. DM 98,-.
	This is the "FreeBSD Install and utilization manual" from Mainichi Communications. General introduction to FreeBSD from installation to utilization with troubleshooting under the supervision of the user group in Japan. 2.2.7-RELEASE FreeBSD(98)2.2.7-Rev01 PAO and distfiles in CDROM. 472 pages, 3,600yen.
	The "FreeBSD User's Reference Manual" from Mainichi Communications, under the supervision of "jpman project", the manual translation project by the user group in Japan. Japanese edition of the section 1 of the FreeBSD manual. 2.2.7-RELEASE FreeBSD(98)2.2.7-Rev01 and PAO in CDROM. 1,040 pages, 3,800yen.
	The "FreeBSD System Administrator's Manual" from Mainichi Communications, under the supervision of "jpman project", the manual translation project by the user group in Japan. Japanese edition of the section 5 and 8 of the FreeBSD manual. 756 pages, 3,300yen.
	This is "About FreeBSD" from Youngjin.com. It is first FreeBSD book in Korea, and covers several topics from installation to Korean environment. 3.5.1-RELEASE/PAO and 4.1-RELEASE in 3 CDROMs. 788 pages, 26,000 won.
	Onno W Purbo, Dodi Maryanto, Syahrial Hubbany, Widjil Widodo: Building Internet Server with FreeBSD (in Indonesia Language), published by Elex Media Komputindo, 2000.
	The FreeBSD Handbook 1st Edition is a comprehensive FreeBSD Tutorial and reference. It covers installation, day-to-day use of FreeBSD, and much more. April 2000, BSDi. ISBN 1-57176-241-8
	The Complete FreeBSD with CDs, 3rd Ed, FreeBSD 4.2. Everything you ever wanted to know about how to get your computer up and running FreeBSD. Includes 4 CDs containing the FreeBSD operating system! Released: November 2000 ISBN: 1-57176-246-9
	The FreeBSD Handbook 2nd Edition is a comprehensive FreeBSD Tutorial and reference. It covers installation, day-to-day use of FreeBSD, and much more. November 2001, Wind River Systems. ISBN 1-57176-303-1

CDROMs

For more about recent releases go to FreeBSD release information page.

	This is InfoMagic's BSDisc, containing FreeBSD 2.0 and NetBSD 1.0 on a single CD. This is the only example I have which had cover art.
	This is the original 4.4 BSD Lite2 release from UC Berkeley, the core technology behind much of FreeBSD.
	The first of Laser5's "BSD" series. Contains FreeBSD-2.0.5R, NetBSD-1.0, XFree86-3.1.1 and FreeBSD(98) kernel.
	The second of Laser5's "BSD" series. From this version, the CDs come in a standard jewel box. Contains FreeBSD-2.1R, NetBSD-1.1, XFree86-3.1.2 and 3.1.2A, and FreeBSD(98) kernel (2.0.5).
	This is the Laser5 Japanese edition of the FreeBSD CDROM. It is a 4 CD set.
	This is the only FreeBSD CD Pacific Hitech produced before merging their product line with that of Walnut Creek CDROM. PHT now also produces the FreeBSD/J (Japanese) CD product.
	This is the cover disc from the Korean magazine. Note the creative cover art! The CD contains the FreeBSD 2.2.1 release with some local additions.
	This is it - the very first FreeBSD CD published! Both the FreeBSD Project and Walnut Creek CDROM were fairly young back then, and you'll probably have little difficulty in spotting the differences in production quality between then and now.
	This was the second FreeBSD CD published by Walnut Creek CDROM and also the very last on the 1.x branch (ref USL/Novell lawsuit and settlement). The next release, FreeBSD 1.1.5, was only available on the net.
	This unusual CD is something of a collector's item now given that almost all existing examples were systematically tracked down and destroyed. An artwork mishap has this CD dated for the wrong year, and on the spine "January" is also misspelled as "Jaunary", just to increase the embarrassment factor. Ah, the perils of turning in one's artwork just hours before leaving for a trade show.
	This is the fixed-up version of the FreeBSD 2.0 CD. Note that the color scheme has even been changed in the corrected version, something unusual for a fixup and perhaps done to distance it from the earlier mistake.
	The FreeBSD 2.0.5 release CD. This was the first CD to feature Tatsumi Hosokawa's daemon artwork.
	The FreeBSD 2.1 release CD. This was the first CD release on the 2.1 branch (the last being 2.1.7).
	The FreeBSD 2.1.5 release CD.
	The FreeBSD 2.1.6 release CD.
	The Japanese version of 2.1.6. This was the first and last Japanese localized version published by WC, responsibility for that product then transitioning to a team led by Tatsumi Hosokawa and sponsored by Pacific Hitech and Laser5.
	The FreeBSD 2.1.7 release CD. Also the last CD released on the 2.1.x branch. Done primarily as a security fixup for 2.1.6
	An early release SNAPshot of 2.2 (done before 2.2.1 was released).
	The FreeBSD 2.2.1 release CD. This was the first CD on the 2.2 branch.
	The FreeBSD 2.2.2 release CD.
	The FreeBSD 3.0 snapshot CD.
	The FreeBSD mailing list and newsgroup archives, turned into HTML and semi-indexed by thread. This product ran for 2 releases and then stopped with a thud once it became obvious that there was simply too much data to deal with on one CD. Perhaps when DVD becomes more popular...
	FreeBSD Toolkit: Six disc set of resources to make your FreeBSD experience more enriching.
	FreeBSD Alpha 4.2 - The full version of the DEC Alpha 64-bit UNIX operating system.
	FreeBSD 4.2: The full version of the PC 32-bit UNIX operating system.
	FreeBSD 4.2 CD-ROM. Lehmanns CD-ROM Edition. January 2001, 4 CD-ROMs. Lehmanns Fachbuchhandlung. Germany. ISBN 3-931253-72-4.
	FreeBSD 4.3 RELEASE CDROM. April 2001, Wind River Systems. ISBN 1-57176-300-7.
	FreeBSD Toolkit: Six disc set of resources to make your FreeBSD experience more enriching. June 2001, Wind River Systems. ISBN 1-57176-301-5.
	FreeBSD 4.4 CD-ROM. Lehmanns CD-ROM Edition. November 2001, 6 CD-ROMs in Jewelcase. Lehmanns Fachbuchhandlung. Germany. ISBN 3-931253-84-8.
	FreeBSD 4.4 RELEASE CDROM. Wind River Systems. September 2001. ISBN 1-57176-304-X.
	FreeBSD 4.5 RELEASE CDROM. February 2002, FreeBSD Mall Inc. ISBN 1-57176-306-6.

Magazines

	Cover of Korean UNIX magazine, May 1997 issue. Also included FreeBSD 2.2.1 with cover CDs.
	UNIX User Magazine November 1996 issue. Also included FreeBSD 2.1.5 on cover CD.
	This is the "FreeBSD Full Course" special in April 1997's Software Design (published by Gijutsu Hyoron Sha). There are 80 pages of FreeBSD articles covering everything from installation to tracking -current.
	Quality Unix for FREE, by Brett Glass in Sm@rt Reseller Online September 1998
	This is the "BSD magazine" published by ASCII corporation, the world's first publication specialized in BSD. BSD magazine covers FreeBSD, NetBSD, OpenBSD and BSD/OS. The premiere issue features articles on the history of BSD, installation, and Ports/Packages; it also includes 4 CD-ROMs containing FreeBSD 3.2-RELEASE, NetBSD 1.4.1 and OpenBSD 2.5.

Newsletters

	This is issue #1 of the FreeBSD Newsletter, published and distributed free of charge by Walnut Creek CDROM.
	This is issue #2 of the FreeBSD Newsletter, published and distributed free of charge by Walnut Creek CDROM.

&footer; diff --git a/en/releases/index.sgml b/en/releases/index.sgml index ce3e75852d..4d2a750395 100644 --- a/en/releases/index.sgml +++ b/en/releases/index.sgml @@ -1,265 +1,265 @@ - + %includes; ]> - + &header; FreeBSD Releases

For late-breaking news about FreeBSD, please visit the Newsflash page.

Current Release(s)

Release &rel.current; (June 2002) Announcement : Release Notes : Hardware Notes : Errata

The latest daily release from our FreeBSD-stable branch is +HREF="&base;/doc/en_US.ISO8859-1/books/handbook/current-stable.html#STABLE">FreeBSD-stable branch is also available. Please see Getting FreeBSD for details.

Future Releases

We will continue to bring you new releases from both - our FreeBSD-stable and - FreeBSD-current + our FreeBSD-stable and + FreeBSD-current branches, both as developer's snapshots and as regular full releases. The next scheduled release on the -stable branch will be FreeBSD 4.7 on October 1, 2002. Subsequent releases will follow at 4 month intervals. The first release on what is now the -current branch will be FreeBSD 5.0, scheduled for November 20, 2002.

For more information about the release engineering process, or to see a comprehensive schedule of upcoming releases, please visit the Release Engineering section of this web site.

The release documentation files for FreeBSD-stable and FreeBSD-current are available for viewing in HTML format on the Release Documentation page. These files are rebuilt periodically, and reflect the changing state of FreeBSD's development.

Past Releases

4.5 (January, 2002) Announcement: Release Notes: Hardware Notes: Errata
4.4 (September, 2001) Announcement: Release Notes: Hardware Notes: Errata
4.3 (April, 2001) Announcement: Release Notes: Errata
4.2 (November, 2000) Announcement: Release Notes: Errata
4.1.1 (September, 2000) Announcement : Release Notes : Errata
4.1 (July, 2000) Announcement: Release Notes: Errata
4.0 (March, 2000) Announcement: Release Notes: Errata
3.5 (June, 2000) Announcement: Release Notes: Errata
3.4 (December, 1999) Announcement: Release Notes: Errata
3.3 (September, 1999) Announcement : Release Notes : Errata
3.2 (May, 1999) Announcement : Release Notes : Errata
3.1 (February, 1999) Announcement : Release Notes : Errata
3.0 (October, 1998) Announcement : Release Notes : Errata
2.2.8 (December, 1998) Announcement : Release Notes : Errata
2.2.7 (July, 1998) Announcement : Release Notes : Errata
2.2.6 (March, 1998) Announcement : Release Notes : Errata
2.2.5 (October, 1997) Announcement : Release Notes : Errata
2.2.2 (May, 1997) Release Notes : Errata
2.2.1 (April, 1997) Release Notes
2.2 (March, 1997) Announcement : Release Notes
2.1.7 (February, 1997) Announcement : Release Notes
2.1.6 (December, 1996) Announcement : Release Notes
2.1.5 (July, 1996) Announcement : Release Notes
2.1 (November, 1995) Announcement : Release Notes
2.0.5 (June, 1995) Announcement : Release Notes
2.0 (November, 1994) Announcement : Release Notes
1.1.5.1 (July, 1994)
1.1.5 Release Notes
1.1 (May, 1994) Release Notes
1.0 (November, 1993)

Release Usage Statistics

A snapshot of the current FreeBSD release usage is available at http://www.FreeBSD.org/statistic/release_usage/2002/.

&footer; diff --git a/en/releases/snapshots.sgml b/en/releases/snapshots.sgml index f955842530..d22a4c7903 100644 --- a/en/releases/snapshots.sgml +++ b/en/releases/snapshots.sgml @@ -1,86 +1,86 @@ - + %includes; ]> - + &header;

What are snapshots?

As part of an ongoing effort to improve the overall release process before a release actually slips out the door with problems that make folks mad, we are now periodically producing interim test releases called snapshots. These snapshots will be very similar to full releases, except that they will be somewhat more minimal. In particular, before getting and installing a snapshot release, be aware of following:

We generally will not, for example, produce new XFree86 distributions or worry much about the tools directory, unless either of those two things are affected by the changes being tested.
The major release number will not be changed in the main distribution for each snapshot. It will only be changed on the boot floppies so that you know when the snapshot was made. These are not releases, these are snapshots, and it is important that this distinction be preserved. People can and will, of course, refer to snapshots by date in mail or netnews, we just do not want them to start thinking that Christmas came early and the next release is already out!
Finally, we will not necessarily update the documentation. If a README still refers to a previous release, well, that is much less important to than getting the real bug fixes and new features out for testing. Complaints about that kind of thing will be quietly ignored. Again, these are snapshots, not releases!

Your feedback on these snapshots is, of course, greatly welcome. They are not just for our benefit - those who are coming to rely on FreeBSD for mission critical applications should welcome a chance to get at more updated bits in a structured fashion. You can also use these snapshots as tangible evidence that your feedback is getting incorporated and that you (hopefully) will not have any unpleasant surprises in the next release. On the other hand, if you do send us hate mail next release and it turns out that you never even tried the snapshots, well, it cuts both ways!

Where to find snapshots

Snapshots of FreeBSD-current +

Snapshots of FreeBSD-current are available via anonymous FTP from ftp://current.FreeBSD.org/pub/FreeBSD/. The snapshot releases are in directories named in the format REL-YYMMDD-SNAP where `REL' is the release number, `YY' is the year, `MM' is the month, and `DD' is the day the snapshot was released. Each snapshot directory contains a `README' file which outlines the changes for the particular snapshot.

By popular demand, snapshots are also now available for the - FreeBSD-stable branch via anonymous FTP from + FreeBSD-stable branch via anonymous FTP from ftp://releng4.FreeBSD.org/pub/FreeBSD/. The snapshot releases are in directories named in the same manner as -current snapshots, but ending in the keyword RELENG instead of SNAP.

Release Home &footer; diff --git a/en/search/index-site.sgml b/en/search/index-site.sgml index 335a23b306..dd443a2aab 100644 --- a/en/search/index-site.sgml +++ b/en/search/index-site.sgml @@ -1,54 +1,54 @@ - + %includes; ]> &header;

Site Map

&site;

Meta homepages

A-Z Index

&atoz; &footer; diff --git a/en/search/search.sgml b/en/search/search.sgml index a332e29ac7..7098eca1f4 100644 --- a/en/search/search.sgml +++ b/en/search/search.sgml @@ -1,463 +1,463 @@ - + %includes; ]> &header;

FreeBSD Search Services

Web pages
Mailing list archives
Message-ID
GNATS Problem Reports (Bugs) database
Manual Pages
Ports Changes
The Source Code
A cross reference of the FreeBSD kernel
BSD Usenet News Searcher
Google Search BSD
GreasyDaemon, an all-in-one BSD UNIX search engine

Web pages (including FAQ -and Handbook)

Web pages (including FAQ +and Handbook)

Mailing list archives

The mailing list archive indexes are now updated weekly!

The mailing lists (as well as many others) have also been archived by GeoCrawler.

Search for:

Note: Use the operators AND or NOT to limit your search. Look here for more hints.

Limit the number of results to sort by Search

In archive(s):

Note: Searching more than three or four archives at once may yield inaccurate results.

General Archives

Advocacy	FreeBSD Evangelism
Announce	Important events / milestones
Chat	Random topics (sometimes) related to FreeBSD
Jobs	FreeBSD related job announcements and resumes
Newbies	New FreeBSD users activities and discussion
Questions	General questions
User-Groups	A forum for FreeBSD user groups

System Use and Administration

Bugs	Reports and discussion of bugs
Cluster	Discussions related to using FreeBSD in clustered environments
Hardware	Discussions concerning hardware as it relates to FreeBSD
ISP	Discussions for ISPs using FreeBSD
Security	FreeBSD computer security issues (DES, Kerberos, etc.)
Stable	Discussion of the FreeBSD-stable branch of the development tree

Developer

Afs	Porting and using AFS (the Andrew File System) from CMU/Transarc
Alpha	Porting FreeBSD to the DEC Alpha
Arch	Architecture and design discussions
ARM	Porting FreeBSD to the StrongArm
ATM	Using ATM networking with FreeBSD
Audit	Source code audit project
Binup	Design and development of the binary update system
Commit	Changes made to the FreeBSD source tree
Config	Development of FreeBSD installation and configuration tools
Current	Use of FreeBSD-current sources
Database	Discussing database use and development under FreeBSD
Doc	Discussions concerning documentation
Emulation	Emulating other systems on FreeBSD
Firewire	Design and implementation of a Firewire (aka IEEE 1394 aka iLink) subsystem for FreeBSD
Fs	Discussions concerning FreeBSD filesystems
Hackers	General technical discussions
I18n	FreeBSD Internationalization
ia64	Porting FreeBSD to Intel's upcoming IA64 systems
ipfw	Technical discussion concerning the redesign of the IP firewall code
ISDN	Development of ISDN support for FreeBSD
Java	JDK porting and application development
libh	The second generation installation and package system
Multimedia	Discussions about FreeBSD as a multimedia platform
Mobile	Using FreeBSD in a mobile environment
Mozilla	Porting mozilla to FreeBSD
Net	Networking discussion and TCP/IP source code
New Bus	Technical discussions on Bus Architecture
Platforms	Cross-platform FreeBSD issues (non-Intel FreeBSD ports)
Policy	FreeBSD core team policy decisions.
Ports	Discussions concerning FreeBSD's ports collection
PPC	Porting FreeBSD to the PowerPC
QA	Discussion of quality assurance issues
Realtime	Development of realtime extensions to FreeBSD
SCSI	Discussions about FreeBSD's SCSI support
Small	Using FreeBSD in embedded applications
SMP	FreeBSD on multi-processor platforms
SPARC	Porting FreeBSD to the SPARC
Standards	FreeBSD Conformance to the C99 and the POSIX standards
Tokenring	Support Token Ring in FreeBSD

Limited lists

Hubs	People running mirror sites (infrastructural support)
Install	Installation system development
WWW	Web site maintainers

&footer; diff --git a/en/security/advisories.xml b/en/security/advisories.xml index 764b5f3f82..e89bed45dc 100644 --- a/en/security/advisories.xml +++ b/en/security/advisories.xml @@ -1,676 +1,676 @@ - + %includes; ]> - + &header;

Introduction

This web page is designed to assist both new and experienced users in the area of FreeBSD security. FreeBSD takes security very seriously and is constantly working on making the OS as secure as possible.

Here you will find additional information, or links to information, on how to protect your system against various types of attack, on whom to contact if you find a security-related bug, and so on. There is also a section on the various ways that the systems programmer can become more security conscious so that he is less likely to introduce vulnerabilities.

Information about the FreeBSD Security Officer Team
FreeBSD Security Advisories
FreeBSD Security Mailing Lists Information
FreeBSD Security Tips and Tricks
Secure Programming Guidelines
Other Related Security Information

The FreeBSD Security Officer Team

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security related communications: the FreeBSD Security Officer team. The position is staffed by a team of dedicated security officers, whose main tasks are to send out advisories when there are known security holes and to act on reports of possible security problems with FreeBSD.

If you need to contact someone from FreeBSD about a possible security bug, you should therefore send mail to the Security Officer team with a description of what you have found and the type of vulnerability it represents. The Security Officer team also communicates with the various CERT and FIRST teams around the world, sharing information about possible vulnerabilities in FreeBSD or utilities commonly used with FreeBSD. The Security Officers are also active members of those organizations.

If you do need to contact the Security Officer team about a particularly sensitive matter, please use their PGP key to encrypt your message before sending it.

FreeBSD Security Advisories

The FreeBSD Security Officer Team provides security advisories for the following releases of FreeBSD:

The most recent official release of FreeBSD.
FreeBSD-stable, when at least 2 releases are based on it.
The previous FreeBSD-stable when a "new stable" does not yet have 2 releases based on it.

At this time, security advisories are being released for:

FreeBSD 4.5-RELEASE
FreeBSD 4.6-RELEASE
FreeBSD 4.6-STABLE

Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.

Like all development efforts, security fixes are first brought into -the FreeBSD-current branch. +the FreeBSD-current branch. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory is then sent out.

Some statistics about advisories released during 2000:

A total of 81 advisories were released, covering both the base system (i.e. the default FreeBSD installation) and the optional third party applications included in the ports collection.
24 advisories (of various severity) were issued for the base system, with the remaining 57 relating to optional third party applications available in the ports collection.
19 vulnerabilities (8 base system and 11 ports) were discovered internally by members of the FreeBSD team during source code auditing.
9 advisories described vulnerabilities found only in FreeBSD (6 base system advisories, and 3 ports advisories), the remaining 72 advisories were problems shared with at least one other OS (often due to shared code).

Advisories are sent to the following FreeBSD mailing lists:

FreeBSD-security-notifications@FreeBSD.org
FreeBSD-security@FreeBSD.org
FreeBSD-announce@FreeBSD.org

Advisories are always signed using the FreeBSD Security Officer PGP key and are archived, along with their associated patches, at our FTP CERT repository. At the time of this writing, the following advisories are currently available (note that this list may be a few days out of date - for the very latest advisories please check the FTP site):

FreeBSD 4.6-RELEASE released.

FreeBSD 4.5-RELEASE released.

FreeBSD 4.4-RELEASE released.

FreeBSD 4.3-RELEASE released.

FreeBSD Security Mailing Lists Information

If you are administering or using any number of FreeBSD systems, you should probably be subscribed to one or more of the following lists:

 freebsd-security                General security related discussion
 freebsd-security-notifications  Security notifications (moderated mailing list)

Send mail to majordomo@FreeBSD.ORG with

      subscribe <listname>  [<optional address>]

in the body of the message in order to subscribe yourself. For example:

 % echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org

and if you would like to unsubscribe from a mailing list:

 % echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org

Secure Programming Guidelines

Never trust any source of input, i.e. command line arguments, environment variables, configuration files, incoming TCP/UDP/ICMP packets, hostname lookups, function arguments, etc. If the length of or contents of the date received is at all subject to outside control, then the program or function should watch for this when copying it around. Specific security issues to watch for in this are:
- strcpy() and sprintf() calls from unbounded data. Use strncpy and snprintf() when the length is known (or implement some other form of bounds-checking when the length is unknown). In fact, never ever use gets() or sprintf(), period. If you do - we will send evil dwarfs after you.
- If you have to check the user input so it does not contain bad characters of some sort, do NOT check for those bad characters. Instead simply verify that it consists ONLY of those characters that you do allow. In general concept is: disallow anything that is not explicitly allowed.
- Read man pages for strncpy() and strncat() calls. Be sure to understand how they work!!! While strncpy() might not append a terminating \0, strncat() on the other hand adds the \0.
- Watch for strvis() and getenv() abuse. With strvis() it is easy to get the destination string wrong, and getenv() can return strings much longer then the program might expect. These two functions are one of the key ways an attack is often made on a program, causing it to overwrite stack or variables by setting its environment variables to unexpected values. If your program reads environment variables, be paranoid. Be very paranoid!
- Ever time you use open() or stat() call - ask yourself: "What if it is a symbolic link?"
- Make sure to use mkstemp() instead of mktemp(), tempnam(), etc. Also make sure to look for races in /tmp in general, being aware that there are very few things which can be atomic in /tmp:
  - Creating a directory. This will either succeed or fail.
  - Opening a file O_CREAT | O_EXCL
  If you use mkstemp() the above cases will be properly handled for you. Hence all temp files should use mkstemp() to guarantee there is not race condition and that the permissions are correct.
- If an attacker can force packets to go/come from another arbitrary system then that attacker has complete control over the data that we get and NONE of it should be trusted.
- Never trust a configuration file is correctly formatted or that it was generated by the appropriate utility. Don't trust user input such as terminal names or language strings to be free of '/' or '../../../' if there is any chance that they can be used in a path name. Don't trust ANY paths supplied by the user when you are running setuid root.
- Look for holes or weaknesses in how data is stored. All temp files should have 600 permission in order to be protected from prying eyes.
- Do not just grep for the usual suspects in programs which run with elevated privileges. Look line by line for possible overflows in these cases since there are a lot more ways to cause buffer overflows than by abusing strcpy() and friends.
- Just because you drop privileges somewhere, it does not mean that no exploit is possible. The attacker may put the necessary code on the stack to regain the privileges before executing /bin/sh.
Do uid management. Do drop privileges as soon as possible, and really do drop them. Switching between euid and uid is NOT enough. Use setuid() when you can.
Never display configuration file contents on errors. A line number and perhaps position count is enough. This is true for all libs and for any suid/sgid program.
Tips for those reviewing existing code for security problems:
- If you are unsure of your security fixes, send them to a reviewer with whom you already have arrangements for a second glance over your code. Don't commit code you are not sure about since breaking something in the name of a security fix is rather embarrassing.
- Those without CVS commit privileges should make sure that a reviewer with such privileges is among the last to review the changes. That person will both review and incorporate the final version you would like to have go into the tree.
- When sending changes around for review, always use context or unidiff format diffs - this way diffs can be easily fed to patch(1). Do not simply send the whole files. Diffs are much easier to read and apply to local sources (especially those in which multiple, simultaneous changes may be taking place). All changes should be relative to the -current branch of development.
- Always directly test your changes (e.g. build and run the affected sources) before sending them to a reviewer. Nobody likes being sent obviously broken stuff for review, and it just makes it appear as though the submitter didn't even really look at what he was submitting (which is also hardly confidence building). If you need accounts on a machine with a specific version which you don't have available - just ask. The project has resources available for exactly such purposes.
- Note for committers: do not forget to retrofit -current patches into the -stable branch as appropriate.
- Do not needlessly rewrite code to suit your style/tastes - it only makes the reviewer's job needlessly more difficult. Do so only if there are clear reasons for it.
Look out for programs doing complex things with signal handlers. Many routines in the various libraries are not sufficiently reentrant to make this safe.
Pay special attention to realloc() usage - more often then not the function is not used correctly.
When using fixed size buffers, use sizeof() to prevent lossage when a buffer size is changed but the code which uses it isn't. For example:
```
         char buf[1024];
         struct foo { ... };
         ...
 BAD:
         xxx(buf, 1024)
         xxx(yyy, sizeof(struct foo))
 GOOD:
         xxx(buf, sizeof(buf))
         xxx(yyy, sizeof(yyy))
 
```
Be careful though with sizeof of pointers when you really want the size of where it points to!
Every time you see "char foo[###]", check every usage of foo to make sure that it can't be overflowed. If you can't avoid overflow (and cases of this have been seen), then at least malloc the buffer so that one can't walk on the stack.
Always close file descriptors as soon as you can - this makes it more likely that the stdio buffer contents will be discarded. In library routines, always set any file descriptors that you open to close-on-exec.

A useful auditing tool is the its4 port, located in /usr/ports/security/its4/. This is an automated C code auditor which highlights potential trouble-spots in the code. It is a useful first-pass tool, but should not be relied upon as being authoritative, and a complete audit should include human examination of the entire code.

For more information on secure programming techniques and resources, see the How to Write Secure Code resource center.

FreeBSD Security Tips and Tricks

There are several steps one must take to secure a FreeBSD system, or in fact any Unix system:

Disabling potentially dangerous software
A lot of software has to be run as a special privileged user to make use of specific resources, by making the executable set-uid. An example is UUCP or PPP software that makes use of a serial port, or sendmail which has to write in the mail spool and bind to a privileged network port. When you are not using UUCP, it is of little use to have software on your system and it may be wise to disable it. Of course, this requires good knowledge of what can be thrown away and what not, as well as good indication whether or not you will want the functionality in the future.
Also some utilities you may find not useful enough to have around pose a possible security risk, like swapinfo. If you remove the set-uid bit for the executable (via 'chmod ug-s filename' command) you can always keep on using swapinfo when you're root. It is however not a good idea to strip so many sbits that you have to be root all the time.
Not only remove programs that you don't use, also remove services you don't want or need to provide. This can be done by editing the /etc/inetd.conf and /etc/rc.conf files and turning off all services you don't use.
Fixing software which has security bugs (or how to stay one step ahead of crackers)
Make sure you are subscribed to various FreeBSD Security mailing lists so you get updates on security bugs and fixes. Apply the fixes immediately.
Backups - repair your system if a security breach does occur
Always have backups and a clean version of the operating system (e.g. on CD-Rom). Make sure your backups do not contain corrupted data or data modified by attackers.
Install software to watch the state of the system
Programs like the tcp wrappers and tripwire (both in packages/ports) can help you to monitor activity on your system. This makes it easier to detect break-ins. Also read outputs of the /etc/security scripts which are run daily and mailed to the root account.
Educating the people who work on the system
Users should know what they are doing. They should be told to never give out their password to anyone and to also use hard-to-guess passwords. Let them understand that the security of the system/network is partly in their hands.

There is also a FreeBSD Security How-To available which provides some advanced tips on how to improve security of your system. You can find it at http://www.FreeBSD.org/~jkb/howto.html.

Security is an ongoing process. Make sure you are following the latest developments in the security arena.

What to do when you detect a security compromise

Determine the level of the security breach
What privileges did the attacker get? Did the attacker manage to get root access? Did the attacker only manage to get user level access?
Determine if the state of system (kernel or userland) has been tampered with
What software has been tampered with? Was new kernel installed? Were any of the system binaries (such as telnetd, login, etc) modified? If you believe an attacker could have done any tampering with an OS, you may want to re-install the operating system from a safe medium.
Find out how the break-in was done
Did the break-in occur via a well-known security bug? If that is the case, make sure to install the correct patches. Was the break-in successful due to a misconfiguration? Was the break-in result of a new bug? If you believe the break-in occurred via a new bug, you should warn the FreeBSD Security Officer.
Fix the security hole
Install new software or apply patches to the old one in order to fix the problems. Disable any compromised accounts.
Other resources
CERT also offers detailed information on what steps to take in case of a system compromise.

Other Related Security Information

The COAST archive contains a huge collection of security related materials.
The COAST Security Hotlist is the place to start looking for security related materials. It contains hundreds of useful security pointers. Everything you always wanted to know about security... and more.
The various CERT teams such as http://www.cert.org and http://www.auscert.org.au.
Mailing lists such as Bugtraq and Firewall Wizards.

&footer diff --git a/en/security/security.sgml b/en/security/security.sgml index 764b5f3f82..e89bed45dc 100644 --- a/en/security/security.sgml +++ b/en/security/security.sgml @@ -1,676 +1,676 @@ - + %includes; ]> - + &header;

Introduction

Information about the FreeBSD Security Officer Team
FreeBSD Security Advisories
FreeBSD Security Mailing Lists Information
FreeBSD Security Tips and Tricks
Secure Programming Guidelines
Other Related Security Information

The FreeBSD Security Officer Team

If you do need to contact the Security Officer team about a particularly sensitive matter, please use their PGP key to encrypt your message before sending it.

FreeBSD Security Advisories

The FreeBSD Security Officer Team provides security advisories for the following releases of FreeBSD:

The most recent official release of FreeBSD.
FreeBSD-stable, when at least 2 releases are based on it.
The previous FreeBSD-stable when a "new stable" does not yet have 2 releases based on it.

At this time, security advisories are being released for:

FreeBSD 4.5-RELEASE
FreeBSD 4.6-RELEASE
FreeBSD 4.6-STABLE

Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.

Some statistics about advisories released during 2000:

A total of 81 advisories were released, covering both the base system (i.e. the default FreeBSD installation) and the optional third party applications included in the ports collection.
24 advisories (of various severity) were issued for the base system, with the remaining 57 relating to optional third party applications available in the ports collection.
19 vulnerabilities (8 base system and 11 ports) were discovered internally by members of the FreeBSD team during source code auditing.
9 advisories described vulnerabilities found only in FreeBSD (6 base system advisories, and 3 ports advisories), the remaining 72 advisories were problems shared with at least one other OS (often due to shared code).

Advisories are sent to the following FreeBSD mailing lists:

FreeBSD-security-notifications@FreeBSD.org
FreeBSD-security@FreeBSD.org
FreeBSD-announce@FreeBSD.org

FreeBSD 4.6-RELEASE released.

FreeBSD 4.5-RELEASE released.

FreeBSD 4.4-RELEASE released.

FreeBSD 4.3-RELEASE released.

FreeBSD Security Mailing Lists Information

If you are administering or using any number of FreeBSD systems, you should probably be subscribed to one or more of the following lists:

 freebsd-security                General security related discussion
 freebsd-security-notifications  Security notifications (moderated mailing list)

Send mail to majordomo@FreeBSD.ORG with

      subscribe <listname>  [<optional address>]

in the body of the message in order to subscribe yourself. For example:

 % echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org

and if you would like to unsubscribe from a mailing list:

 % echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org

Secure Programming Guidelines

Never trust any source of input, i.e. command line arguments, environment variables, configuration files, incoming TCP/UDP/ICMP packets, hostname lookups, function arguments, etc. If the length of or contents of the date received is at all subject to outside control, then the program or function should watch for this when copying it around. Specific security issues to watch for in this are:
- strcpy() and sprintf() calls from unbounded data. Use strncpy and snprintf() when the length is known (or implement some other form of bounds-checking when the length is unknown). In fact, never ever use gets() or sprintf(), period. If you do - we will send evil dwarfs after you.
- If you have to check the user input so it does not contain bad characters of some sort, do NOT check for those bad characters. Instead simply verify that it consists ONLY of those characters that you do allow. In general concept is: disallow anything that is not explicitly allowed.
- Read man pages for strncpy() and strncat() calls. Be sure to understand how they work!!! While strncpy() might not append a terminating \0, strncat() on the other hand adds the \0.
- Watch for strvis() and getenv() abuse. With strvis() it is easy to get the destination string wrong, and getenv() can return strings much longer then the program might expect. These two functions are one of the key ways an attack is often made on a program, causing it to overwrite stack or variables by setting its environment variables to unexpected values. If your program reads environment variables, be paranoid. Be very paranoid!
- Ever time you use open() or stat() call - ask yourself: "What if it is a symbolic link?"
- Make sure to use mkstemp() instead of mktemp(), tempnam(), etc. Also make sure to look for races in /tmp in general, being aware that there are very few things which can be atomic in /tmp:
  - Creating a directory. This will either succeed or fail.
  - Opening a file O_CREAT | O_EXCL
  If you use mkstemp() the above cases will be properly handled for you. Hence all temp files should use mkstemp() to guarantee there is not race condition and that the permissions are correct.
- If an attacker can force packets to go/come from another arbitrary system then that attacker has complete control over the data that we get and NONE of it should be trusted.
- Never trust a configuration file is correctly formatted or that it was generated by the appropriate utility. Don't trust user input such as terminal names or language strings to be free of '/' or '../../../' if there is any chance that they can be used in a path name. Don't trust ANY paths supplied by the user when you are running setuid root.
- Look for holes or weaknesses in how data is stored. All temp files should have 600 permission in order to be protected from prying eyes.
- Do not just grep for the usual suspects in programs which run with elevated privileges. Look line by line for possible overflows in these cases since there are a lot more ways to cause buffer overflows than by abusing strcpy() and friends.
- Just because you drop privileges somewhere, it does not mean that no exploit is possible. The attacker may put the necessary code on the stack to regain the privileges before executing /bin/sh.
Do uid management. Do drop privileges as soon as possible, and really do drop them. Switching between euid and uid is NOT enough. Use setuid() when you can.
Never display configuration file contents on errors. A line number and perhaps position count is enough. This is true for all libs and for any suid/sgid program.
Tips for those reviewing existing code for security problems:
- If you are unsure of your security fixes, send them to a reviewer with whom you already have arrangements for a second glance over your code. Don't commit code you are not sure about since breaking something in the name of a security fix is rather embarrassing.
- Those without CVS commit privileges should make sure that a reviewer with such privileges is among the last to review the changes. That person will both review and incorporate the final version you would like to have go into the tree.
- When sending changes around for review, always use context or unidiff format diffs - this way diffs can be easily fed to patch(1). Do not simply send the whole files. Diffs are much easier to read and apply to local sources (especially those in which multiple, simultaneous changes may be taking place). All changes should be relative to the -current branch of development.
- Always directly test your changes (e.g. build and run the affected sources) before sending them to a reviewer. Nobody likes being sent obviously broken stuff for review, and it just makes it appear as though the submitter didn't even really look at what he was submitting (which is also hardly confidence building). If you need accounts on a machine with a specific version which you don't have available - just ask. The project has resources available for exactly such purposes.
- Note for committers: do not forget to retrofit -current patches into the -stable branch as appropriate.
- Do not needlessly rewrite code to suit your style/tastes - it only makes the reviewer's job needlessly more difficult. Do so only if there are clear reasons for it.
Look out for programs doing complex things with signal handlers. Many routines in the various libraries are not sufficiently reentrant to make this safe.
Pay special attention to realloc() usage - more often then not the function is not used correctly.
When using fixed size buffers, use sizeof() to prevent lossage when a buffer size is changed but the code which uses it isn't. For example:
```
         char buf[1024];
         struct foo { ... };
         ...
 BAD:
         xxx(buf, 1024)
         xxx(yyy, sizeof(struct foo))
 GOOD:
         xxx(buf, sizeof(buf))
         xxx(yyy, sizeof(yyy))
 
```
Be careful though with sizeof of pointers when you really want the size of where it points to!
Every time you see "char foo[###]", check every usage of foo to make sure that it can't be overflowed. If you can't avoid overflow (and cases of this have been seen), then at least malloc the buffer so that one can't walk on the stack.
Always close file descriptors as soon as you can - this makes it more likely that the stdio buffer contents will be discarded. In library routines, always set any file descriptors that you open to close-on-exec.

For more information on secure programming techniques and resources, see the How to Write Secure Code resource center.

FreeBSD Security Tips and Tricks

There are several steps one must take to secure a FreeBSD system, or in fact any Unix system:

Disabling potentially dangerous software
A lot of software has to be run as a special privileged user to make use of specific resources, by making the executable set-uid. An example is UUCP or PPP software that makes use of a serial port, or sendmail which has to write in the mail spool and bind to a privileged network port. When you are not using UUCP, it is of little use to have software on your system and it may be wise to disable it. Of course, this requires good knowledge of what can be thrown away and what not, as well as good indication whether or not you will want the functionality in the future.
Also some utilities you may find not useful enough to have around pose a possible security risk, like swapinfo. If you remove the set-uid bit for the executable (via 'chmod ug-s filename' command) you can always keep on using swapinfo when you're root. It is however not a good idea to strip so many sbits that you have to be root all the time.
Not only remove programs that you don't use, also remove services you don't want or need to provide. This can be done by editing the /etc/inetd.conf and /etc/rc.conf files and turning off all services you don't use.
Fixing software which has security bugs (or how to stay one step ahead of crackers)
Make sure you are subscribed to various FreeBSD Security mailing lists so you get updates on security bugs and fixes. Apply the fixes immediately.
Backups - repair your system if a security breach does occur
Always have backups and a clean version of the operating system (e.g. on CD-Rom). Make sure your backups do not contain corrupted data or data modified by attackers.
Install software to watch the state of the system
Programs like the tcp wrappers and tripwire (both in packages/ports) can help you to monitor activity on your system. This makes it easier to detect break-ins. Also read outputs of the /etc/security scripts which are run daily and mailed to the root account.
Educating the people who work on the system
Users should know what they are doing. They should be told to never give out their password to anyone and to also use hard-to-guess passwords. Let them understand that the security of the system/network is partly in their hands.

There is also a FreeBSD Security How-To available which provides some advanced tips on how to improve security of your system. You can find it at http://www.FreeBSD.org/~jkb/howto.html.

Security is an ongoing process. Make sure you are following the latest developments in the security arena.

What to do when you detect a security compromise

Determine the level of the security breach
What privileges did the attacker get? Did the attacker manage to get root access? Did the attacker only manage to get user level access?
Determine if the state of system (kernel or userland) has been tampered with
What software has been tampered with? Was new kernel installed? Were any of the system binaries (such as telnetd, login, etc) modified? If you believe an attacker could have done any tampering with an OS, you may want to re-install the operating system from a safe medium.
Find out how the break-in was done
Did the break-in occur via a well-known security bug? If that is the case, make sure to install the correct patches. Was the break-in successful due to a misconfiguration? Was the break-in result of a new bug? If you believe the break-in occurred via a new bug, you should warn the FreeBSD Security Officer.
Fix the security hole
Install new software or apply patches to the old one in order to fix the problems. Disable any compromised accounts.
Other resources
CERT also offers detailed information on what steps to take in case of a system compromise.

Other Related Security Information

The COAST archive contains a huge collection of security related materials.
The COAST Security Hotlist is the place to start looking for security related materials. It contains hundreds of useful security pointers. Everything you always wanted to know about security... and more.
The various CERT teams such as http://www.cert.org and http://www.auscert.org.au.
Mailing lists such as Bugtraq and Firewall Wizards.

&footer diff --git a/en/smp/index.sgml b/en/smp/index.sgml index d37639fcef..4c557c2364 100644 --- a/en/smp/index.sgml +++ b/en/smp/index.sgml @@ -1,1671 +1,1671 @@ - + %includes; Done"> In progress"> Stalled"> Not Started"> Resolved"> Unresolved"> %developers; ]> &header;

Project Goal
Project Plan
Resources and Links
Status
Known Issues
News

Project Goal

The FreeBSD SMP project, often referred to as SMPng (SMP next generation), is focused on implementing fine-grained SMP support for the FreeBSD 5.0 kernel (scheduled for November 2002). Due to FreeBSD's history, this is much like trying to fit a square peg into a round hole, and as such, the intermediate results aren't pretty in many ways. We are specifically not attempting to rewrite the kernel from scratch, nor are we on a crusade to fix all the architectural nits currently present in the kernel. In fact, we expect to leave a trail of architectural nits that will still be evident in many ways when FreeBSD 5.0 is released. This is a pragmatic project rather than a theoretical one; we need to have the kernel working and stable in under a year, so time restraints require that we be realistic about what to do when.

Project Plan

This web page contains information related to the effort to improve SMP support in FreeBSD. In general, this project uses what it can from the BSD/OS 5.0 development kernel, and re-implements what cannot be directly used due to divergence in the code bases.

As with any free software project, a detailed schedule is not possible. We expect to have significant performance and stability issues that need to be worked through over the first several months of the project, though every effort will be made to keep -current running as well as possible.

The task list below is not intended to be complete, but does represent a set of relevant and/or important components of the overall work. The "Responsible" field identifies a developer who has expressed willingness to be responsible for completing the identified task; this doesn't preclude others working on it, but suggests that coordination with the responsible party might be appropriate so as to avoid unnecessary duplication of work, and to maximize forward progress. If beginning work on a new area of substantial size, or one that appears unclaimed, it may be worth dropping an e-mail to the FreeBSD SMP mailing list to see if any progress has been made.

The definition of the date field varies depending on the status of a task. For completed tasks, it refers to the date completed or reported completed. For in-progress tasks, it refers to the date of the last update of the entry. For stalled tasks, it refers to the date that the task was declared stalled. For new tasks, it refers to the date the task was added to the list.

Tasks are sorted first by status, then by date.

Resources and Links

SMP kernel synchronization rules.
Most SMP-related discussion takes place on the freebsd-smp mailing list. You can read more about mailing lists in the - + Electronic Resources chapter of the - FreeBSD Handbook.

FreeBSD Handbook

Steve Passe has been maintaining a SMP project page that contains additional information, and goes back further in time than this web page.
&a.dillon; is maintaining a web page that documents the work he is doing on the SMP project.

Status

Following is an incomplete list of general tasks.

Task	Responsible	Last updated	Status
Convert the giant lock from spinning to blocking, add the scheduler lock, add per-CPU idle processes.	&a.dillon;	25 June 2000	&status.done;
Port the BSD/OS locking primitives (i386).	&a.jake;	3 July 2000	&status.done;
Implement heavy-weight interrupt threads (i386).	&a.grog;	3 August 2000	&status.done;
Rewrite the low level interrupt code (i386 UP).	&a.grog;	3 August 2000	&status.done;
Demonstrated reasonable stability (self-hosted buildworld) (i386 UP).	-smp developers	12 August 2000	&status.done;
Port the BSD/OS locking primitives (alpha).	&a.dfr;	24 August 2000	&status.done;
Stub out (disable) spl()s.	&a.grog;	30 August 2000	&status.done;
Port the BSD/OS ktr code.	&a.grog;, &a.jhb;	30 August 2000	&status.done;
Rewrite the low level interrupt code (i386 SMP).	&a.jhb;	1 September 2000	&status.done;
Demonstrated reasonable stability (self-hosted buildworld) (i386 SMP).	-smp developers	6 September 2000	&status.done;
Demonstrated reasonable stability (self-hosted buildworld) (alpha).	-smp developers	6 September 2000	&status.done;
Make malloc and friends thread-safe.	&a.jasone;	10 September 2000	&status.done;
Implement msleep(), make tsleep() an msleep() wrapper.	&a.jake;	11 September 2000	&status.done;
Make fxp driver thread-safe.	&a.cp;	17 September 2000	&status.done;
Make mbuf's thread-safe.	&a.bmilekic;	29 September 2000	&status.done;
Lock manager re-work.	&a.jasone;	3 October 2000	&status.done;
Implement heavy-weight interrupt threads (alpha).	&a.jhb;, &a.dfr;	5 October 2000	&status.done;
Rewrite the low level interrupt code (alpha).	&a.dfr;, &a.jhb;	5 October 2000	&status.done;
Process accounting.	&a.tegge;, &a.jhb;	5 October 2000	&status.done;
Make ethernet drivers thread-safe.	&a.wpaul;	15 October 2000	&status.done;
Make the mutex headers mostly machine-independent.	&a.jhb;	20 October 2000	&status.done;
Rename SMP_DEBUG to MUTEX_DEBUG.	&a.jhb;	20 October 2000	&status.done;
Give each soft interrupt its own thread.	&a.cp;	25 October 2000	&status.done;
Make sf_bufs (sendfile(2)) thread-safe.	&a.bmilekic;	5 November 2000	&status.done;
Make the witness code work correctly.	&a.jhb;	18 November 2000	&status.done;
Split the ktr-specific code out of db_interface.c.	&a.jhb;	15 December 2000	&status.done;
Convert the sio driver to using a spin mutex.	&a.jhb;	18 December 2000	&status.done;
Implement condition variables.	&a.jake;, &a.jasone;	15 January 2001	&status.done;
Add a flag to mtx_init() (MTX_RECURSE) that denotes whether a mutex is allowed to recurse.	&a.bmilekic;	19 January 2001	&status.done;
Make the zone allocator thread-safe.	&a.des;	21 January 2001	&status.done;
Convert simplelocks to mutexes.	&a.jasone;	24 January 2001	&status.done;
Make kernel preemptive with respect to interrupts.	&a.jake;	31 January 2001	&status.done;
Cleanup of mutex API.	&a.bmilekic;	8 February 2001	&status.done;
Remove COM_LOCK.	&a.markm;	11 February 2001	&status.done;
Merge various scheduling classes into one run queue. Modify scheduler to support preemptable kernel.	&a.jake;	11 February 2001	&status.done;
Make priority propagation work correctly.	&a.jake;	11 February 2001	&status.done;
Make most of the interrupt thread code MI and shared between hardware and software interrupts.	&a.jhb;	18 February 2001	&status.done;
Add protection to struct jail and jail-related functionality.	&a.rwatson;	20 February 2001	&status.done;
Implement sx (shared/exclusive) locks.	&a.jasone;	5 March 2001	&status.done;
Generalize/improve witness to handle more complex locking primitives (mtx, sx).	&a.jhb;	28 March 2001	&status.done;
Convert the allproc and proctree locks from lockmgr locks to sx locks.	&a.jhb;	28 March 2001	&status.done;
Make mbuf system use condition variables instead of msleep()/wakeup().	&a.bmilekic;	2 April 2001	&status.done;
Remove <sys/mutex.h> includes from other kernel headers such as <vm/vm_zone.h>, <sys/resourcevar.h>, <sys/ucred.h>, and <sys/mbuf.h>.	&a.markm;	15 May 2001	&status.done;
Cleanup the various mp_machdep.c's, unify various SMP API's such as IPI delivery, etc.	&a.jhb;	15 May 2001	&status.done;
Make most of the forward_* and forwarded_* functions MI.	&a.jhb;	15 May 2001	&status.done;
Complete the MD support for SMP on the Alpha platform.	&a.gallatin;, &a.dfr;, &a.jhb;	15 May 2001	&status.done;
Convert select() to use condition variables.	&a.tanimura;	15 May 2001	&status.done;
Add a "giant" lock around the VM subsystem.	&a.alfred;	13 June 2001	&status.done;
Introduce a modified slab allocator for the mbuf subsystem.	&a.bmilekic;	21 June 2001	&status.done;
Add a witness_assert() function to handle lock assertions.	&a.jhb;	27 June 2001	&status.done;
Extend sx locks to support try lock operations.	&a.jhb;	27 June 2001	&status.done;
Document KTR.	&a.jhb;	28 June 2001	&status.done;
Make fork_return, fork_exit, ast, and userret MI.	&a.jhb;	29 June 2001	&status.done;
Make sched_lock's savecrit a per-process property saved and restored in mi_switch and initialized in fork_exit.	&a.jhb;	30 June 2001	&status.done;
Make ast() loop.	&a.jhb;	10 August 2001	&status.done;
Add upgrade/downgrade sx lock operations.	Alexander Kabaev, &a.jasone;	13 August 2001	&status.done;
Implement semaphores.	&a.jasone;	14 August 2001	&status.done;
Add support for upgrade/downgrades in witness.	&a.jhb;	23 August 2001	&status.done;
Make most of cpu_wait() and cpu_exit() MI.	&a.peter;	9 September 2001	&status.done;
Split NFS into client and server.	&a.peter;	18 Oct 2001	&status.done;
Lock taskqueues.	&a.arr;, &a.jhb;	25 October 2001	&status.done;
Add a per-thread ucred reference.	&a.jhb;	25 October 2001	&status.done;
Make most of the per-CPU stuff MI.	&a.jhb;	11 December 2001	&status.done;
Make critical section saved state per-thread instead of per-lock so that interlocking spin locks work properly.	&a.jhb;	17 December 2001	&status.done;
Replace the APIC-specific imen_mtx with a MI-named icu_lock to protect interrupt controllers and associated data within the kernel for both i386 and alpha.	&a.jhb;	20 December 2001	&status.done;
Use the per-thread critical section nesting level in the mutex and interrupt thread code to automatically determine when to not preempt. This makes the MTX_NOSWITCH, SWI_SWITCH, and SWI_NOSWITCH flags obsolete as the kernel will be able to figure out the proper behavior on its own.	&a.jhb;	5 January 2002	&status.done;
Lock struct filedesc and struct file.	&a.tanimura;, &a.alfred;	12 January 2002	&status.done;
Lock struct pgrp, struct session, and struct sigio.	&a.tanimura;	23 February 2002	&status.done;
Lock pipe implementation, but not sigio/fown, VM interactions	&a.alfred;	27 February 2002	&status.done;
Move to explicit reference counting for soft vnode references.	&a.phk;	8 March 2002	&status.done;
Initialize mutex pools early enough that sx locks can be used for VM.	&a.green;	14 March 2002	&status.done;
Place a global lock (sellock) around selinfo structures to fix a variety of lock order reversals, and make select() MP-safe.	&a.alfred;, &a.davidc;	14 March 2002	&status.done;
Push down Giant on read, write, pread, pwrite system calls, acquiring Giant in the per-subsystem fileop layer for sockets, VFS, etc.	&a.alfred;	15 March 2002	&status.done;
Lock down kernel module structures.	&a.arr;	18 March 2002	&status.done;
Lock down kernel linker globals.	&a.arr;	18 March 2002	&status.done;
Rewrite kernel memory allocator to be a slab allocator that uses per-cpu caches.	&a.jeff;	21 March 2002	&status.done;
Replace incorrect use of MD critical section API to disable interrupts with a specific interrupt disable API.	&a.imp;, &a.dfr;, &a.benno;, &a.jhb;	21 March 2002	&status.done;
Lock down access to the shared p_args "process arguments" structure through appropriate protection of that structure and references to it.	&a.mini;	31 March 2002	&status.done;
Move from flags/tsleep lock to sx locks to protect sysctl tree from updates during sysctl operations.	&a.mini;	1 April 2002	&status.done;
Create/port userland tool to manage KTR event dumps.	&a.jake;	1 April 2002	&status.done;
Create MTX_SYSINIT and SX_SYSINIT macros that allow for initializing locks that are subsystem independent.	&a.arr;	2 April 2002	&status.done;
Lock down the global securelevel variable.	&a.arr;	2 April 2002	&status.done;
Make grow_stack() MI. Possibly even a macro or inline.	&a.alc;	6 April 2002	&status.done;
Lock use of p_fd, which otherwise can result in corrupted p_fd panics during heavy operation. Start with a global, and move to per-proc locking.	&a.alfred;, &a.tanimura;	8 April 2002	&status.done;
Lock struct pargs.	&a.mini;	9 April 2002	&status.done;
Make {o,}sigreturn() MPSAFE.	&a.alc;	11 April 2002	&status.done;
Rewrite kernel memory allocator so that Giant is not required for malloc() or free().	&a.jeff;	2 May 2002	&status.done;
Replace complex shared/exclusive locking scheme in the VM system with a purely exclusive lockmgr locking scheme, simplifying locking and removing potential livelock/deadlock scenarios.	&a.green;, &a.alc;	3 May 2002	&status.done;
Push down Giant into readv/writev system calls in style of read/write/pread/pwrite once malloc no longer requires Giant in the handling of iovec structures for uio.	&a.alc;	9 May 2002	&status.done;
Push down Giant in mprotect(), minherit(), and madvise() so that it is no longer acquired and released directly.	&a.alc;	18 May 2002	&status.done;
Update suser() and p_can*() APIs to accept threads instead of processes.	&a.jhb;	18 May 2002	&status.done;
Broadly transition to td_ucred from p_ucred once KSE dependencies are in place.	&a.jhb;	18 May 2002	&status.done;
Add a witness_sleep() check to uma_zalloc() to catch code calling malloc() or uma_zalloc() while holding non-sleepable locks.	&a.jhb;	20 May 2002	&status.done;
Optimize UP support by changing spin locks to only perform critical section enter and exits.	&a.jhb;	21 May 2002	&status.done;
Make sleep mutexes spin if the current lock holder is executing on another CPU.	&a.jhb;	21 May 2002	&status.done;
Add support for the IA32 pause instruction to spin loops in locks.	&a.jhb;	21 May 2002	&status.done;
Make KTRACE write into tracefiles asynchronously.	&a.jhb;	7 June 2002	&status.done;
Remove Giant from jail(2).	&a.arr;	25 June 2002	&status.done;
Remove Giant from modnext(2), modfnext(2), modstat(2),and modfind(2).	&a.arr;	25 June 2002	&status.done;
Lock struct proc.	&a.jhb;	20 February 2001	&status.wip;
Make the kernel fully preemptive.	&a.jhb;	7 September 2001	&status.wip;
Lock down the tty subsystem.	Dick Garner, Jeremy Scofield, &a.tmm;	2 April 2002	&status.wip;
Fix clock locking to be the same on all platforms.	&a.jhb;	16 November 2001	&status.wip;
Implement lazy interrupt thread switching (context stealing) on i386.	&a.bmilekic;	4 January 2002	&status.wip;
Fix synchronization of TLB flushes and invlpg() on x86 SMP.	&a.peter;	4 January 2002	&status.wip;
Lock pipe implementation: sigio/fown-related evil	&a.alfred;	27 February 2002	&status.wip;
Make use of process locking and process reference counting to protect debugging interfaces (and procfs).	&a.jhb;	27 February 2002	&status.wip;
Make use of process locking to protect process monitoring sysctls, including those employed by 'ps' and related tools.	&a.jhb;	27 February 2002	&status.wip;
Lock down TrustedBSD MAC implementation.	&a.rwatson;	27 February 2002	&status.wip;
Lock down newbus infrastructure to support driver fine-graining.	&a.imp;	28 February 2002	&status.wip;
Remove the MP safe syscall flag from the syscall table and add explicit mtx_lock/unlock's of Giant to all syscalls.	&a.dillon;, &a.mux;	28 February 2002	&status.wip;
SMPng architecture document.	&a.jhb;	28 February 2002	&status.wip;
Move to shared lock for VOP_GETATTR() to reduce blocking during frequent lightweight VFS operations. Modify namei() to provide a LOOKUP_SHARED flag to indicate when the lock required may be shared instead of exclusive.	&a.jeff;	11 March 2002	&status.wip;
Create mutex profiling tool for the kernel so as to measure contention and behavior of kernel mutexes.	&a.eivind;, &a.des;	31 March 2002	&status.wip;
Lock eventhandlers.	&a.msmith;, &a.mini;	8 April 2002	&status.wip;
Lock sysctl hierarchy and access methods.	&a.mini;	9 April 2002	&status.wip;
Document existing vm_map locking and verify it's correctness.	&a.alc;	18 May 2002	&status.wip;
Document existing vm_object locking and verify it's correctness.	&a.alc;	4 May 2002	&status.wip;
Implement generic turnstiles to use when blocking on non-sleepable locks.	&a.jhb;	23 May 2002	&status.wip;
Create mechanism in cdevsw structure to protect thread-unsafe drivers.	&a.jhb;	15 May 2001	&status.stalled;
Make printf() safe to call in almost any situation to avoid deadlocks.	&a.cp;	15 May 2001	&status.stalled;
Add locking to NFS.		15 May 2001	&status.new;
Remove priority argument from tsleep(), msleep(), cv_wait().		12 January 2001	&status.new;
Reimplement kqueue using condition variables.	&a.jlemon;	15 March 2001	&status.new;
Conditionalize atomic ops in the SMP code that are used for debugging statistics.	&a.peter;	15 March 2001	&status.new;
Add a new witness check for exiting processes to verify that an exiting process holds no locks.	&a.jhb;	13 June 2001	&status.new;
Make cpu_coredump MI.		13 June 2001	&status.new;
Specify priorities for condition variables, semaphores, and sx locks.		7 September 2001	&status.new;
Fix SIGXPU and other #if 0'd things in mi_switch().		7 September 2001	&status.new;
Axe schedpu() in favor of event driven priority updates as much as possible.		7 September 2001	&status.new;
Fix PHOLD() so that it blocks to guarantee PS_INMEM.		7 September 2001	&status.new;
Fix *hold (e.g. crhold) to return reference to object.		7 September 2001	&status.new;
Fix various procfs_machdep.c to use PHOLD, not sched_lock.		7 September 2001	&status.new;
Add witness checking for lockmgr locks.		7 September 2001	&status.new;
Add ICU spin locks on ia64.		4 January 2002	&status.new;
Fast-path push-down of Giant for VOP_READ() and VOP_WRITE().		25 February 2002	&status.new;
Lock contention measurement tool to measure heat of various locks, including Giant, and permit more directed performance and locking strategy optimization.		25 February 2002	&status.new;
Push the grabbing of Giant into Linux i386 ABI system calls.		25 February 2002	&status.new;
Push the grabbing of Giant into Linux AXP ABI system calls.		25 February 2002	&status.new;
Push the grabbing of Giant into SVR4 i386 ABI system calls.		25 February 2002	&status.new;
Push the grabbing of Giant into OSF/1 AXP ABI system calls.		25 February 2002	&status.new;
Push the grabbing of Giant into IBCS i386 ABI system calls.		25 February 2002	&status.new;
Lock pipe implementation: VM optimizations.		27 February 2002	&status.new;
Document in-vnode locking strategy, clean it up, remove interlock, switch to sx locks.	&a.jeff;	27 February 2002	&status.new;
Review locking strategy and correctness of VFS operations and fix up various failure modes associated with enabling VFS locking assertions.	&a.jeff;	27 February 2002	&status.new;
Switch from using lockmgr in VM to using a mutex or exclusive sxlock. Push down Giant on all VM except for vm_object/VFS and vm_page/pmap components.	&a.green;, &a.alc;	18 March 2002	&status.new;
Expand mutex profiling tool to also profile sx locks.	&a.eivind;, &a.des;	1 April 2002	&status.new;
Implement atomic_fetchadd() for int's and long's with acq and rel versions.		23 May 2002	&status.new;
Implement a simple reference count API using atomic operations and use this to replace locks that just protect a reference count.		23 May 2002	&status.new;
Implement a sleep queue abstraction to be used by both msleep() and condition variables. This new abstraction should use a hash table of sleep queues with a spin lock on each sleep queue chain similar to turnstile chain locks to make sched_lock finger grained.	&a.jhb;	23 May 2002	&status.new;
Add a witness_sleep() check to copyin/out() and s/fuword().	&a.jhb;	7 June 2002	&status.new;
Split witness_lock() into witness_checkorder() and witness_lock(). witness_checkorder() would be called before acquiring a lock to increase the changes of detecting and warning about a reversal prior to deadlocking. witness_lock() would simply update witness' internal state to note that a lock has been acquired.	&a.jhb;	7 June 2002	&status.new;
Lock down linker_file_t structures in the kernel linker.	&a.arr;	19 June 2002	&status.wip;

This table lists the todo subtasks for multithreading the network stack.

Task	Responsible	Last updated	Status
Protect network interface queues.	&a.jlemon;	24 November 2000	&status.done;
Lock down struct socket.	&a.tanimura;	21 April 2002	&status.wip;
Lock down struct inpcb.	&a.hsu;	29 April 2002	&status.wip;
Lock struct ifnet.		19 January 2001	&status.new;
Reduce contention upon locking a socket buffer by replacing tsleep() and wakeup() with a condvar.	&a.tanimura;	21 April 2002	&status.new;

Known Issues

Issue	Last updated	Status
Idle processor time is not charged to the idle processes.	20 September 2000	&status.resolved;
microuptime creeps backwards.	4 October 2000	&status.resolved;
microuptime() went backwards	4 October 2000	&status.resolved;
Process accounting is not accurate (the more CPUs, the closer to correct it is).	5 October 2000	&status.resolved;
M_DEVBUF is probably the wrong memory pool for interrupt stuff and we should think about creating a new malloc pool for that stuff.	9 February 2001	&status.resolved;
PC card eject panics due to a race condition in the interrupt thread code.	15 March 2001	&status.resolved;
SMP x86 boxes are seeing NCPU * 100 clk interrupts and NCPU * 128 rtc interrupts.	15 May 2001	&status.resolved;
Witness will infinitely recurse when it acquires Giant after sleeping with a sleepable lock.	27 June 2001	&status.resolved;
Serial gdb does not work if boot_ddb and boot_gdb options are specified.	5 September 2000	&status.unresolved;
Serial gdb does not work at 115200 baud.	5 September 2000	&status.unresolved;
Profiling is broken.	20 February 2001	&status.unresolved;
jail_sysvipc_allowed is checked in an unsafe manner in the SYSV IPC syscalls.	5 March 2002	&status.unresolved;
Serial gdb never regains control once 'cont' has been entered.	25 March 2002	&status.unresolved;

News

The remainder of this page is structured as a reverse-chronological log.

13 January 2002

A status report was sent to the -smp mailing list.

15 May 2001

&a.grog; has made his USENIX paper available, which he will present in Boston at the end of June.

22 March 2001

A status report was sent to the -smp mailing list.

5 March 2001

A status report was sent to the -smp mailing list.

24 January 2001

A status report was sent to the -smp mailing list.

12 January 2001

A status report was sent to the -smp mailing list.

11 October 2000

&a.jhb; and &a.cp; came up with a preliminary list of rules that should be followed when working on kernel synchronization.

8 September 2000

Here's a copy of an article sent to BSDtoday and linked at Daemon News.

6 September 2000

The SMP code has been committed. All further work is being done in cvs rather than with patches.
An updated patch is available for download. This patch is probably what will actually get committed.

5 September 2000

An updated patch is available for download. This patch makes rtc a fast interrupt, uses locked instructions for mutexes in MP kernels, and corrects mtx_*() linkage within modules.

1 September 2000

The code is working for the most part now on i386 (UP and MP). Some additional coding is still necessary for the alpha, which is being done now.

30 August 2000

Updated patches for i386 and alpha are available here.

12 August 2000

Updated patches for i386 are available here. Process accounting still doesn't work correctly, but a number of other improvements have been made.

3 August 2000

Patches with functional heavy-weight threads for the i386 platform are available here. There are a couple of minor issues with this patch set. Specifically, process accounting doesn't work correctly.

6 July 2000

Sheldon Hearn has prepared a mutex(9) man page based on the BSD/OS one, which is available here.

5 July 2000

&a.jake; put an updated patch here.

3 July 2000

&a.jake; has the BSD/OS lock code working now, and has incorporated the pertinent portions of &a.dillon;'s patches (idle processes, some of the schedlock changes, etc.). His patch set is available here.

26 June 2000

&a.cp; has provided the PostScript versions of his presentation slides for the first day and second day of the SMP meeting.

25 June 2000

Here's a copy of the SMP meeting summary that was posted to the -smp mailing list.

19 June 2000

Here's a copy of the SMP project announcement that was posted to the -current mailing list.

&footer; diff --git a/en/support.sgml b/en/support.sgml index 97e5d07c3d..76f0f8634d 100644 --- a/en/support.sgml +++ b/en/support.sgml @@ -1,982 +1,982 @@ + %includes; ]> &header;

Mailing lists
Newsgroups
IRC
WEB Resources
Problem Report Database
CVS Repository
User Groups
FreeBSD Development Projects
FreeBSD Security Guide
Commercial Consulting Services
General Unix Information
The X Window System
Hardware
Related Operating System Projects

Mailing lists

Mailing +

Mailing lists are the primary support channel for FreeBSD users, with numerous mailing lists covering different topic areas. When in doubt about what list to post a question to, post to freebsd-questions@FreeBSD.ORG. You can browse or search the mailing list archives at www.FreeBSD.org.

The FreeBSD Conspectus is a summary of some of the mailing lists produced each week, giving you an at-a-glance overview of recent discussions and decisions.

Several non-English mailing lists are also available:

Traditional Chinese -- WWW, Big5 encoding.
Simplified Chinese -- majordomo@cn.FreeBSD.org, GB2312 encoding.
Czech -- majordomo@FreeBSD.cz
German -- majordomo@de.FreeBSD.org or WWW.
French -- listserver@FreeBSD-fr.org or WWW.
Hungarian -- majordomo@hu.FreeBSD.org
Indonesian -- id-freebsd-subscribe@egroups.com
Italian -- minimalist@gufi.org or WWW.
Japanese -- majordomo@jp.FreeBSD.org or WWW.
Korean -- majordomo@kr.FreeBSD.org or WWW.
Netherlands -- majordomo@nl.FreeBSD.org.
Polish -- majordomo@pap.waw.pl
Portuguese -- listproc@br.FreeBSD.org or WWW.
Slovakian -- majordomo@sk.FreeBSD.org
Spanish -- majordomo@es.FreeBSD.org

If you create other FreeBSD mailing lists, let us know about them.

Newsgroups

There are a few FreeBSD specific newsgroups, along with + href="doc/en_US.ISO8859-1/books/handbook/eresources-news.html">newsgroups, along with numerous other newsgroups on topics of interest to FreeBSD users, though the mailing lists remain the most reliable way to get in touch with the FreeBSD developers. For miscellaneous FreeBSD discussion, see comp.unix.bsd.freebsd.misc. For important announcements, see comp.unix.bsd.freebsd.announce.

The BSD Usenet News Searcher have archives of all BSD-related Usenet newsgroups from June 1992 onwards.

IRC

While #freebsd channels exist on various IRC networks, the FreeBSD project does not control them or endorse IRC as a support medium. You may be ignored, insulted, or kicked out if you ask questions on any channel in IRC, though you may have slightly better luck in channels named #freebsdhelp where such exist. If you want to try these or any other channels on IRC, it is nonetheless at your own risk and any complaints about conduct on those channels should not be directed to the FreeBSD project. See also - the FAQ entry for + the FAQ entry for more information.

WEB Resources

Our WEB pages remain one of the best sources of information, and are also mirrored at many sites around the world. Try connecting to www.yourcountry.FreeBSD.org (e.g. www.de.FreeBSD.org for Germany or www.au.FreeBSD.org for Australia), or select a mirror from the list below. The same naming convention is also used for FTP servers.
For information on recent FreeBSD progress and releases, see the Newsflash page.

Problem Report Database

Current FreeBSD problem reports are tracked using the GNATS database.

A FreeBSD problem report (PR) is not necessarily a bug with FreeBSD itself. In some cases it may be reporting a mistake in the documentation (which could be a simple typo). In other cases it may be a 'wishlist' item that the submitter would like to see incorporated in to FreeBSD. In many cases a PR contains a port which has been prepared for inclusion in the FreeBSD Ports and Packages collection.

Problem reports start 'open', and are closed as the issue they report is resolved. In addition, each PR is assigned a unique tracking ID to ensure that it is not lost. Many FreeBSD changes include the tracking ID of the PR that prompted the change.

Problem reports may also be submitted to the development team using the send-pr(1) command on a FreeBSD system, using this web based submission form, or by sending an email message to freebsd-bugs@FreeBSD.ORG. Please note that send-pr is preferred since messages sent to the mailing list are not tracked as official problem reports, and may get lost in the noise!

Before submitting a problem report, you might find it useful to read the Writing FreeBSD Problem Reports article. This article describes when you should submit a problem report, what you are expected to include in one, and what the best way to submit your problem report is.

CVS Repository

CVS (the Concurrent Version System) is the tool we use for keeping our sources under control. Every change (with accompanying log message explaining its purpose) from FreeBSD 2.0 to the present is stored here, and can be easily viewed from here (click on the link). To obtain a complete copy of the FreeBSD CVS repository or any of the development branches inside it, you may choose any one of following options:

cvsup if you are looking +
cvsup if you are looking for on-demand, low overhead access using a custom utility (written in Modula-3 no less).
anoncvs +
anoncvs if you are looking for on-demand access that has higher overhead than cvsup (in terms of wall time and bytes transferred) but is easier to use for checking out small pieces of the tree and requires nothing more than the cvs tools already bundled with FreeBSD.
CTM if you are looking for +
CTM if you are looking for very low overhead, batch-mode access (basically, patches through email).
The web interface if you are looking to simply browse the repository in search of a specific change or file revision.
Finally, if you have got bandwidth to burn or you prefer / are forced to use FTP, you can simply mirror the CVS repository from ftp.FreeBSD.org.

Mirrors of the CVS Repository cgi script are available in California, Germany, Japan and Spain (English, Spanish).

User Groups

FreeBSD's widespread popularity has spawned a number of user groups around the world. If you know of a FreeBSD user group not listed here, let us know about it.

Australia

New South Wales. The BSD Users Group, Sydney (BUGS) meets in Sydney every two months and has mailing list members from all over NSW. To join the mailing list send a message to majordomo@bugs.au.FreeBSD.org with subscribe bugs in the body of the message.
Queensland. The Home Unix Users Group for Brisbane meets fortnightly at meeting rooms provided by the University of Queensland. More information, including how to join the mailing lists, is available at http://www.humbug.org.au
South Australia. BUGA, the BSD User Group of Adelaide, meets at irregular intervals. Join the mailing list by sending a message to majordomo@lemis.com with the text subscribe BUGA in the body.
Victoria. Victoria's FreeBSD Users Group (VicFUG) is based in Melbourne. You can join the mailing list by sending an empty message to general-subscribe@vicfug.au.FreeBSD.org
West Australia. Pandaemonium, the BSD Users Group for Western Australia.

Europe

Austria. The BSD User Group Austria (BUGAT) is german-language oriented user group. Visit our server for more information.
The Netherlands. The Dutch FreeBSD User Group (NLFUG) has had its first meeting on oct 2, 1999. On this day 30 years before that, the second IMP was installed in Doug Englebart's lab at SRI. This, as you all know, was the start of something that grew to be the Internet (thanks to Edwin Kremer for bringing this under our attention).
Denmark BSD-DK. The Danish BSD user group. Promotion and support of BSD derived Operating Systems in Denmark. Mailing lists, lectures and workshops. Send mail subscription requests to bsd-dk-request@bsd-dk.dk.
K�ln (Cologne), Germany The CBUG (Cologne BSD Usergroup) caters to BSD users in the K�ln area. Meetings are on the fourth Friday of each month at the ``Campi'' Italian restaurant in the Richard-Wallraff-Platz.
Duisburg, Germany The Cosmo-Project is a user group with a difference. Instead of just meeting, they actively develop projects such as robots. Most users use FreeBSD, but it is not a specifically FreeBSD-related group.
France The French FreeBSD UG. Please follow the link for details.
Frankfurt, Germany FrankfurtBSD is a user group for the Rhein-Main area. We are currently looking for new members. As soon as we have grown larger, we would like to meet monthly and maintain minor projects.
Hamburg, Germany The BSDHH (BSD User Group Hamburg) meets on the first Wednesday of the month at 7.00pm in the Chinese restaurant Lotosbl�te, L�wenstra�e 22 in Hamburg-Eppendorf. Most members are FreeBSD users, although users of all BSD flavors are welcome.
Ireland The BUGI (BSD User Group Ireland) is currently a rather grandiose term for a mailing list and super-minimal web page. All BSD users and enthusiasts are welcome.
Italia The GUFI (Gruppo Utenti FreeBSD Italia) is an "italian powered" FreeBSD User Group. It is intended to help Italian FreeBSD users to find support and articles on/about FreeBSD in the Italian language. Please follow this link to know more about us.
Lublin, Poland The Lublin BSD Users Group. Please follow the link for details.
Lund, Sweden The Lund Linux User Group (LFUG) has nearly 50 members and covers FreeBSD and Solaris in addition to Linux. To join, contact Omar Dedovic
Manchester, UK The Manchester BSD Users Group meets reasonably often in the Lass O'Gowrie, on Charles Street, Manchester. Contact Sam Smith for more information.
Mannheim, Germany The UUGRN (Unix Users Group Rhein-Neckar) provides a regional forum for users of all Unix flavors, with a stress on Linux and BSD. Meetings are held on the second Wednesday of each month at the "Eichbaum Brauhaus" in Mannheim-Käfertal and the fourth Thursday of each month at the "Vater Rhein" in Heidelberg.
M�nchen (Munich), Germany The BIM (Berkeley In Munich) group caters for users of BSD-based systems in Oberbayern.
Regensburg, Germany The Unix and Linux User Group is a general Unix users group for anyone in Regensburg (Bavaria, Germany). We meet on every first Monday of the month in the Pub ``Filmb�hne'' in Regensburg. Visit the web site or send a message to m.suess@2use.org.
Romania The ROFUG (Romanian FreeBSD Users Group/Free Unix Group) is a user group for the Romanian users of FreeBSD and open-source in general, promoting and supporting FreeBSD and open source usage. To join the mailing lists, send an email to listar@rofug.ro with subscribe rofug and/or subscribe rofug-announce in the body of the message.
Sweden The BSD Users Sweden (BUS) maintains a mailing list. To join, send mail to majordomo@stacken.kth.se with subscribe bus in the message.
Turkey The Turkish FreeBSD Users Group (T�rkiye FreeBSD Kullanicilari Grubu) was founded in September 1999. TFUG is intended to help Turkish FreeBSD users to find support and articles on and about FreeBSD in the Turkish language. Contact M. Guven Mucuk for more info.
United Kingdom The FreeBSD UKUG (FreeBSD UK User's Group) exists for the benefit of FreeBSD users in the United Kingdom. Please follow the link for details.
Yugoslavia The Yugoslavia BSD Users Group provides an open forum for all things BSD-related in the Serbian language. To join the mailing list, send an email to majordomo@bsd.org.yu with subscribe bsdyu in the body of the message.

North America

Ames, Iowa The Ames Free-Unix Group aims to promote the use of Free Unix. We meet on the campus of Iowa State University once a month and hold a presentation with an open question and answer session afterwards. You can join our mailing list by sending a blank email to aafugit-subscribe@aafugit.org.
Berkeley, CA The Berkeley Unix User Group is a general Unix users group for anyone in the San Francisco Bay Area. We meet on a weekly basis in downtown Berkeley. Visit the web site or send a message to buug-request@weak.org with subscribe in the body.
Chicago IL The Chicago FreeBSD Users Group (ChiFUG).
The Connecticut Free Unix user's Group (CFUG) is devoted to free Unix, but has resources for almost all Unixen. Their area of operation is Connecticut and Western Massachusetts. More information can be found at http://www.cfug.org.
The Houston TX Houston FreeBSD Users Group was formed March 1999. Our goal is to promote and educate Houston area computer users on FreeBSD Unix. We meet on the third Saturday of the month. The group operates a mailing list at http://www.houfug.org/mailman/listinfo/hou-freebsd Visit our website at http://www.houfug.org for more information.
Indianapolis IN Free Unix for Indianapolis is a non-profit organization dedicated to encouraging the use of Free Unix variants in and around Indianapolis. Essentially, we are a bunch of geeks who share a common passion: Unix. Visit the web site or send a message to info@fufin.org for additional information.
Kansas KULUA (Kansas Unix & Linux Users Association) is a Free Unix user group based in Lawrence, Kansas, but with users throughout eastern Kansas and western Missouri. We have about 120 members and meet biweekly. Visit the web site or email kulua@kulua.org for more information.
Kansas Wichita Area FreeBSD Users Group (WAFUG) is a free users group provided to anyone in the Wichita area for support with FreeBSD and other Unix and Unix-like operating systems. We meet twice a month, usually in a restaraunt where you can smoke or drink if you like. Please send us Email for more information or to find out how to get free shell account, www or ftp space on our system.
Las Vegas, NV The Vegas Free Unix User Group
Los Angeles CA The Yahoo Club group is a foundation for a Los Angeles based BSD user group.
New Mexico The NMLUG in Albuquerque meets once a month and supports both BSD and Linux users. To join the mailing list, send a message to majordomo@swcp.com with subscribe nmlug in the body.
New Orleans LA The New Orleans *BSD User Group meets twice a month. Contact Konrad Rzeszutek for more details. A web page will be posted soon.
New York NY D'Artagnan's FreeBSD Users Group.
Northern Arizona Yavapai Free Unix Users Group is now forming for *BSD/Linux, etc., users in Northern Arizona. Please contact Russell Carter ( rcarter@consys.com) for details.
Orlando, FL BUGO (BSD Users Group of Orlando) is a group based in Orlando, FL that aims to bring a friendly forum to all Unix users in the central Florida area, and hopefully beyond. See the BUGO web page for further details.
Phoenix AZ The Phoenix BSD Users group is fully open for business. Anyone from the Phoenix area please feel free to join in http://bsd.phoenix.az.us.
Portland, OR The Portland (Oregon) FreeBSD Users group meets on the third Thursday of each month. Mail Rick Hamell.
Reno NV RUUG (Reno Unix Users Group) meets monthly in Reno Nevada and discusses the use of FreeBSD and Linux. Contact Eric Blood or Todd Crenshaw for more information.
Research Triangle, NC The Triangle Area BSD Users Group is a users group for BSD users in the Research Triangle Park area of North Carolina, including the surrounding metropolitan areas of Raleigh, Durham, and Chapel Hill. People interested in this group may subscribe to the mailing list by sending a message to majordomo@tribug.org with subscribe tribug-members in the body.
Rhode Island The Rhode Island Free Unix Group supports every form of Unix that can be obtained freely. They can be contacted at: http://users.tmok.com/~rifug or by e-mail at: rifug@entropy.tmok.com
St. Louis, MO The St. Louis BSD User Group (STLBSD) has just formed on July 20, 2000 to promote BSD operating systems in the St. Louis area. We have strong ties to the 10 year old St. Louis Unix Users Group (SLUUG) and expect to be a positive force within our community. Our membership is open to anyone interested in learning more about BSD, several mailing lists are available through our website.
San Diego, California San Diego BSD Users Group for users of FreeBSD, OpenBSD and NetBSD. The meeting is first Thursday of every month at Borders Bookstore in Mission Valley Shopping Center. More information can be found here
North San Francisco Bay Area The BABUG (Bay Area BSD Users Group) has monthly meetings, alternating between San Francisco and Berkeley. Those interested in attending should visit the web site or send mail to the BABUG Web Master
Silicon Valley, CA The SVBUG (Silicon Valley BSD User Group), a forum for BSD and BSD embedded systems, meets on the First Thursday of the month. Meetings are held at the Carl's Jr. on First Street and Trimble Road in San Jose, California. For details on event or what is going on visit the website or send a message to webmaster@svbug.com.
East Texas The Unix Users of Deep East Texas is dedicated to all things Unix. This group is open to users of all flavors of Unix. We meet on the last Saturday of the month at the Angelina County Court House. See the web page for details, or send email to admin@uudet.org.
The Tampa Florida users group is now being formed. Interested parties can join the mailing list by sending mail to bsd-tug-request@bangheadhere.org with subscribe in the body.
Greater Toronto Area, Ontario: The GTABUG usergroup welcomes all BSD users. Monthly meetings give attendees a chance to share ideas, discussion, and information. Installathons and other events help preach the good news of BSD to the community. Come drop by for a meeting!
Tucson AZ TFUG: Tucson Free Unix Group, Arizona.
Utah SLLUG-BUG is a BSD Unix User Group affiliated with the Salt Lake Linux User Group (SLLUG). We meet in concert with SLLUG, since the BSD and Linux communities have so much in common. We meet on the third Wednesday of each month, check the web page for details.
Vancouver, BC The VanBUG (Vancouver BSD Users Group) is a group of volunteers who are passionate about FreeBSD, NetBSD, and OpenBSD. Their current goal is to raise awareness and also provide local assistance as much as we can.
Washington DC (DC Metropolitan Area) FreeBSD User Group. Please contact Richard Cramer, Sytex Access Ltd. at 703-425-2515, or preferred, email at rcramer@sytex.net to be put on a member distribution list.
Wichita, Kansas: A new FreeBSD users group has been created in Wichita, Ks. We are fairly new and working on our site, but we wanted to get it up as soon as we had it available. We do not currently meet. Visit our site http://wafug.dynip.com or E-mail the group organizer (ben177@yahoo.com) for more information!
Windsor, Ontario The Windsor Unix Users Group (Windsor, Ontario, Canada) covers BSD, Solaris, SCO, and others. This is not specifically a FreeBSD user group, but we do already have members running FreeBSD. The group operates a mailing list (wuug-list@unixpower.org). More information can be found at http://www.wuug.org/.
Wisconsin FreeBSD-Milwaukee Wisconsin meets occasionally and has a mailing list: freebsd-mke-l@ns.sol.net. send mail to freebsd-mke-l-request@ns.sol.net to subscribe.

Rest of the world

Ibaraki, Japan The Daibou East *BSD Users Group (DEBUG) is now forming for *BSD users in Tsukuba area.
Indonesia The Jogja FreeBSD Users' Group is based in Yogyakarta City, Indonesia. Send email to 22961476@students.ukdw.ac.id for more information.
Israel The Israeli BSD Users Group is an effort to promote the use of *BSD throughout the country, and to act as a center of information for all BSD users. It is currently run by FreeBSD users, but all users of bsd Variants are welcome aboard. We have a mailing list, hosted at bsd-il@osem.co.il. To subscribe, simply send mail to majordomo@osem.co.il, with the line "subscribe bsd-il" as the message body.
Kansai, Japan The Kansai *BSD User's Group, K*BUG (sorry for Japanese only), was established on November 13, 1999. It is expected to promote communication of any of the BSD variants' users. Some of its activities are to hold friendly parties of the members, and to hold seminars covering wide variety of topics. Please mail here ( kbug-admin@kbug.gr.jp ).
New Zealand The New Zealand FreeBSD User's group is located in Wellington. No meetings have been scheduled yet.
Niigata, Japan The Echigo BSD Users Group (EBUG) is the users group for BSD users around Echigo (aka Niigata). For more information on our events and mailing lists, please check the EBUG web site.
Brazil The FUG-BR (Brazilian FreeBSD User Group) is a Portuguese language oriented user group intended to help Brazilian FreeBSD users to find support and articles on and about FreeBSD in the Portuguese language. We keeps some projects such as the "FreeBSD LiveCD". Currently the group has 600 members and our maillist has an average traffic of 80 messages per day. To join FUG-BR mailing list, visit http://www2.fugspbr.org/mailman/listinfo/fugspbr.

FreeBSD Development Projects

In addition to the mainstream development path of FreeBSD, a number of developer groups are working on the cutting edge to expand FreeBSD's range of applications in new directions.

FreeBSD Security Guide

Security resources available to FreeBSD users: PGP Key for Security Officers, advisories, patches and mailing lists.

Commercial Consulting Services

Whether you are just starting out with FreeBSD, or need to complete a large project, a consultant or two might be your answer.

General Unix Information

The Unix Reference Desk by Mennifer Myers
Jeff's Unix Vault
Unix Guru Universe
O'Reilly & Associates, Inc.
Unix Power

The X Window System

The XFree86 Project provides users of a variety of Intel based Unix systems, including FreeBSD, with an excellent X Window system.
The WINE project is working to provide the ability to run MS-Windows software on Intel based Unix systems such as FreeBSD, NetBSD and Linux.

Hardware

The comp.answers pc-hardware-faq is a great reference for people building their own machines.
Laptop users looking for PCCARD (aka PCMCIA) support not already provided in the FreeBSD base distribution should see the PAO distribution page for the latest and greatest experimental laptop support.
Intel Secrets -- What Intel Doesn't Want You To Know - lots of information about Intel chips.
Aad Offerman's Chip List - reference material on chips used in PC clones.
ASUS makes motherboards that work well with FreeBSD.

Related Operating System Projects

NetBSD is another free 4.4BSD-Lite based operating system which runs on several different architectures.
OpenBSD is another 4.4BSD derivative.
Linux is another free Unix-like system.
Lites is a 4.4 BSD Lite based server and emulation library that provides free Unix functionality to a Mach based system.
xMach is a Lites and Mach4 derivative designed to be small and efficient with extended functionality.
The GNU HURD project is another effort to develop a free Unix-like operating system.

&footer; diff --git a/en/usergroups.sgml b/en/usergroups.sgml index 97e5d07c3d..76f0f8634d 100644 --- a/en/usergroups.sgml +++ b/en/usergroups.sgml @@ -1,982 +1,982 @@ + %includes; ]> &header;

Mailing lists
Newsgroups
IRC
WEB Resources
Problem Report Database
CVS Repository
User Groups
FreeBSD Development Projects
FreeBSD Security Guide
Commercial Consulting Services
General Unix Information
The X Window System
Hardware
Related Operating System Projects

Mailing lists

Mailing +

The FreeBSD Conspectus is a summary of some of the mailing lists produced each week, giving you an at-a-glance overview of recent discussions and decisions.

Several non-English mailing lists are also available:

Traditional Chinese -- WWW, Big5 encoding.
Simplified Chinese -- majordomo@cn.FreeBSD.org, GB2312 encoding.
Czech -- majordomo@FreeBSD.cz
German -- majordomo@de.FreeBSD.org or WWW.
French -- listserver@FreeBSD-fr.org or WWW.
Hungarian -- majordomo@hu.FreeBSD.org
Indonesian -- id-freebsd-subscribe@egroups.com
Italian -- minimalist@gufi.org or WWW.
Japanese -- majordomo@jp.FreeBSD.org or WWW.
Korean -- majordomo@kr.FreeBSD.org or WWW.
Netherlands -- majordomo@nl.FreeBSD.org.
Polish -- majordomo@pap.waw.pl
Portuguese -- listproc@br.FreeBSD.org or WWW.
Slovakian -- majordomo@sk.FreeBSD.org
Spanish -- majordomo@es.FreeBSD.org

If you create other FreeBSD mailing lists, let us know about them.

Newsgroups

The BSD Usenet News Searcher have archives of all BSD-related Usenet newsgroups from June 1992 onwards.

IRC

WEB Resources

Our WEB pages remain one of the best sources of information, and are also mirrored at many sites around the world. Try connecting to www.yourcountry.FreeBSD.org (e.g. www.de.FreeBSD.org for Germany or www.au.FreeBSD.org for Australia), or select a mirror from the list below. The same naming convention is also used for FTP servers.
For information on recent FreeBSD progress and releases, see the Newsflash page.

Problem Report Database

Current FreeBSD problem reports are tracked using the GNATS database.

CVS Repository

cvsup if you are looking +
cvsup if you are looking for on-demand, low overhead access using a custom utility (written in Modula-3 no less).
anoncvs +
anoncvs if you are looking for on-demand access that has higher overhead than cvsup (in terms of wall time and bytes transferred) but is easier to use for checking out small pieces of the tree and requires nothing more than the cvs tools already bundled with FreeBSD.
CTM if you are looking for +
CTM if you are looking for very low overhead, batch-mode access (basically, patches through email).
The web interface if you are looking to simply browse the repository in search of a specific change or file revision.
Finally, if you have got bandwidth to burn or you prefer / are forced to use FTP, you can simply mirror the CVS repository from ftp.FreeBSD.org.

Mirrors of the CVS Repository cgi script are available in California, Germany, Japan and Spain (English, Spanish).

User Groups

FreeBSD's widespread popularity has spawned a number of user groups around the world. If you know of a FreeBSD user group not listed here, let us know about it.

Australia

New South Wales. The BSD Users Group, Sydney (BUGS) meets in Sydney every two months and has mailing list members from all over NSW. To join the mailing list send a message to majordomo@bugs.au.FreeBSD.org with subscribe bugs in the body of the message.
Queensland. The Home Unix Users Group for Brisbane meets fortnightly at meeting rooms provided by the University of Queensland. More information, including how to join the mailing lists, is available at http://www.humbug.org.au
South Australia. BUGA, the BSD User Group of Adelaide, meets at irregular intervals. Join the mailing list by sending a message to majordomo@lemis.com with the text subscribe BUGA in the body.
Victoria. Victoria's FreeBSD Users Group (VicFUG) is based in Melbourne. You can join the mailing list by sending an empty message to general-subscribe@vicfug.au.FreeBSD.org
West Australia. Pandaemonium, the BSD Users Group for Western Australia.

Europe

Austria. The BSD User Group Austria (BUGAT) is german-language oriented user group. Visit our server for more information.
The Netherlands. The Dutch FreeBSD User Group (NLFUG) has had its first meeting on oct 2, 1999. On this day 30 years before that, the second IMP was installed in Doug Englebart's lab at SRI. This, as you all know, was the start of something that grew to be the Internet (thanks to Edwin Kremer for bringing this under our attention).
Denmark BSD-DK. The Danish BSD user group. Promotion and support of BSD derived Operating Systems in Denmark. Mailing lists, lectures and workshops. Send mail subscription requests to bsd-dk-request@bsd-dk.dk.
K�ln (Cologne), Germany The CBUG (Cologne BSD Usergroup) caters to BSD users in the K�ln area. Meetings are on the fourth Friday of each month at the ``Campi'' Italian restaurant in the Richard-Wallraff-Platz.
Duisburg, Germany The Cosmo-Project is a user group with a difference. Instead of just meeting, they actively develop projects such as robots. Most users use FreeBSD, but it is not a specifically FreeBSD-related group.
France The French FreeBSD UG. Please follow the link for details.
Frankfurt, Germany FrankfurtBSD is a user group for the Rhein-Main area. We are currently looking for new members. As soon as we have grown larger, we would like to meet monthly and maintain minor projects.
Hamburg, Germany The BSDHH (BSD User Group Hamburg) meets on the first Wednesday of the month at 7.00pm in the Chinese restaurant Lotosbl�te, L�wenstra�e 22 in Hamburg-Eppendorf. Most members are FreeBSD users, although users of all BSD flavors are welcome.
Ireland The BUGI (BSD User Group Ireland) is currently a rather grandiose term for a mailing list and super-minimal web page. All BSD users and enthusiasts are welcome.
Italia The GUFI (Gruppo Utenti FreeBSD Italia) is an "italian powered" FreeBSD User Group. It is intended to help Italian FreeBSD users to find support and articles on/about FreeBSD in the Italian language. Please follow this link to know more about us.
Lublin, Poland The Lublin BSD Users Group. Please follow the link for details.
Lund, Sweden The Lund Linux User Group (LFUG) has nearly 50 members and covers FreeBSD and Solaris in addition to Linux. To join, contact Omar Dedovic
Manchester, UK The Manchester BSD Users Group meets reasonably often in the Lass O'Gowrie, on Charles Street, Manchester. Contact Sam Smith for more information.
Mannheim, Germany The UUGRN (Unix Users Group Rhein-Neckar) provides a regional forum for users of all Unix flavors, with a stress on Linux and BSD. Meetings are held on the second Wednesday of each month at the "Eichbaum Brauhaus" in Mannheim-Käfertal and the fourth Thursday of each month at the "Vater Rhein" in Heidelberg.
M�nchen (Munich), Germany The BIM (Berkeley In Munich) group caters for users of BSD-based systems in Oberbayern.
Regensburg, Germany The Unix and Linux User Group is a general Unix users group for anyone in Regensburg (Bavaria, Germany). We meet on every first Monday of the month in the Pub ``Filmb�hne'' in Regensburg. Visit the web site or send a message to m.suess@2use.org.
Romania The ROFUG (Romanian FreeBSD Users Group/Free Unix Group) is a user group for the Romanian users of FreeBSD and open-source in general, promoting and supporting FreeBSD and open source usage. To join the mailing lists, send an email to listar@rofug.ro with subscribe rofug and/or subscribe rofug-announce in the body of the message.
Sweden The BSD Users Sweden (BUS) maintains a mailing list. To join, send mail to majordomo@stacken.kth.se with subscribe bus in the message.
Turkey The Turkish FreeBSD Users Group (T�rkiye FreeBSD Kullanicilari Grubu) was founded in September 1999. TFUG is intended to help Turkish FreeBSD users to find support and articles on and about FreeBSD in the Turkish language. Contact M. Guven Mucuk for more info.
United Kingdom The FreeBSD UKUG (FreeBSD UK User's Group) exists for the benefit of FreeBSD users in the United Kingdom. Please follow the link for details.
Yugoslavia The Yugoslavia BSD Users Group provides an open forum for all things BSD-related in the Serbian language. To join the mailing list, send an email to majordomo@bsd.org.yu with subscribe bsdyu in the body of the message.

North America

Ames, Iowa The Ames Free-Unix Group aims to promote the use of Free Unix. We meet on the campus of Iowa State University once a month and hold a presentation with an open question and answer session afterwards. You can join our mailing list by sending a blank email to aafugit-subscribe@aafugit.org.
Berkeley, CA The Berkeley Unix User Group is a general Unix users group for anyone in the San Francisco Bay Area. We meet on a weekly basis in downtown Berkeley. Visit the web site or send a message to buug-request@weak.org with subscribe in the body.
Chicago IL The Chicago FreeBSD Users Group (ChiFUG).
The Connecticut Free Unix user's Group (CFUG) is devoted to free Unix, but has resources for almost all Unixen. Their area of operation is Connecticut and Western Massachusetts. More information can be found at http://www.cfug.org.
The Houston TX Houston FreeBSD Users Group was formed March 1999. Our goal is to promote and educate Houston area computer users on FreeBSD Unix. We meet on the third Saturday of the month. The group operates a mailing list at http://www.houfug.org/mailman/listinfo/hou-freebsd Visit our website at http://www.houfug.org for more information.
Indianapolis IN Free Unix for Indianapolis is a non-profit organization dedicated to encouraging the use of Free Unix variants in and around Indianapolis. Essentially, we are a bunch of geeks who share a common passion: Unix. Visit the web site or send a message to info@fufin.org for additional information.
Kansas KULUA (Kansas Unix & Linux Users Association) is a Free Unix user group based in Lawrence, Kansas, but with users throughout eastern Kansas and western Missouri. We have about 120 members and meet biweekly. Visit the web site or email kulua@kulua.org for more information.
Kansas Wichita Area FreeBSD Users Group (WAFUG) is a free users group provided to anyone in the Wichita area for support with FreeBSD and other Unix and Unix-like operating systems. We meet twice a month, usually in a restaraunt where you can smoke or drink if you like. Please send us Email for more information or to find out how to get free shell account, www or ftp space on our system.
Las Vegas, NV The Vegas Free Unix User Group
Los Angeles CA The Yahoo Club group is a foundation for a Los Angeles based BSD user group.
New Mexico The NMLUG in Albuquerque meets once a month and supports both BSD and Linux users. To join the mailing list, send a message to majordomo@swcp.com with subscribe nmlug in the body.
New Orleans LA The New Orleans *BSD User Group meets twice a month. Contact Konrad Rzeszutek for more details. A web page will be posted soon.
New York NY D'Artagnan's FreeBSD Users Group.
Northern Arizona Yavapai Free Unix Users Group is now forming for *BSD/Linux, etc., users in Northern Arizona. Please contact Russell Carter ( rcarter@consys.com) for details.
Orlando, FL BUGO (BSD Users Group of Orlando) is a group based in Orlando, FL that aims to bring a friendly forum to all Unix users in the central Florida area, and hopefully beyond. See the BUGO web page for further details.
Phoenix AZ The Phoenix BSD Users group is fully open for business. Anyone from the Phoenix area please feel free to join in http://bsd.phoenix.az.us.
Portland, OR The Portland (Oregon) FreeBSD Users group meets on the third Thursday of each month. Mail Rick Hamell.
Reno NV RUUG (Reno Unix Users Group) meets monthly in Reno Nevada and discusses the use of FreeBSD and Linux. Contact Eric Blood or Todd Crenshaw for more information.
Research Triangle, NC The Triangle Area BSD Users Group is a users group for BSD users in the Research Triangle Park area of North Carolina, including the surrounding metropolitan areas of Raleigh, Durham, and Chapel Hill. People interested in this group may subscribe to the mailing list by sending a message to majordomo@tribug.org with subscribe tribug-members in the body.
Rhode Island The Rhode Island Free Unix Group supports every form of Unix that can be obtained freely. They can be contacted at: http://users.tmok.com/~rifug or by e-mail at: rifug@entropy.tmok.com
St. Louis, MO The St. Louis BSD User Group (STLBSD) has just formed on July 20, 2000 to promote BSD operating systems in the St. Louis area. We have strong ties to the 10 year old St. Louis Unix Users Group (SLUUG) and expect to be a positive force within our community. Our membership is open to anyone interested in learning more about BSD, several mailing lists are available through our website.
San Diego, California San Diego BSD Users Group for users of FreeBSD, OpenBSD and NetBSD. The meeting is first Thursday of every month at Borders Bookstore in Mission Valley Shopping Center. More information can be found here
North San Francisco Bay Area The BABUG (Bay Area BSD Users Group) has monthly meetings, alternating between San Francisco and Berkeley. Those interested in attending should visit the web site or send mail to the BABUG Web Master
Silicon Valley, CA The SVBUG (Silicon Valley BSD User Group), a forum for BSD and BSD embedded systems, meets on the First Thursday of the month. Meetings are held at the Carl's Jr. on First Street and Trimble Road in San Jose, California. For details on event or what is going on visit the website or send a message to webmaster@svbug.com.
East Texas The Unix Users of Deep East Texas is dedicated to all things Unix. This group is open to users of all flavors of Unix. We meet on the last Saturday of the month at the Angelina County Court House. See the web page for details, or send email to admin@uudet.org.
The Tampa Florida users group is now being formed. Interested parties can join the mailing list by sending mail to bsd-tug-request@bangheadhere.org with subscribe in the body.
Greater Toronto Area, Ontario: The GTABUG usergroup welcomes all BSD users. Monthly meetings give attendees a chance to share ideas, discussion, and information. Installathons and other events help preach the good news of BSD to the community. Come drop by for a meeting!
Tucson AZ TFUG: Tucson Free Unix Group, Arizona.
Utah SLLUG-BUG is a BSD Unix User Group affiliated with the Salt Lake Linux User Group (SLLUG). We meet in concert with SLLUG, since the BSD and Linux communities have so much in common. We meet on the third Wednesday of each month, check the web page for details.
Vancouver, BC The VanBUG (Vancouver BSD Users Group) is a group of volunteers who are passionate about FreeBSD, NetBSD, and OpenBSD. Their current goal is to raise awareness and also provide local assistance as much as we can.
Washington DC (DC Metropolitan Area) FreeBSD User Group. Please contact Richard Cramer, Sytex Access Ltd. at 703-425-2515, or preferred, email at rcramer@sytex.net to be put on a member distribution list.
Wichita, Kansas: A new FreeBSD users group has been created in Wichita, Ks. We are fairly new and working on our site, but we wanted to get it up as soon as we had it available. We do not currently meet. Visit our site http://wafug.dynip.com or E-mail the group organizer (ben177@yahoo.com) for more information!
Windsor, Ontario The Windsor Unix Users Group (Windsor, Ontario, Canada) covers BSD, Solaris, SCO, and others. This is not specifically a FreeBSD user group, but we do already have members running FreeBSD. The group operates a mailing list (wuug-list@unixpower.org). More information can be found at http://www.wuug.org/.
Wisconsin FreeBSD-Milwaukee Wisconsin meets occasionally and has a mailing list: freebsd-mke-l@ns.sol.net. send mail to freebsd-mke-l-request@ns.sol.net to subscribe.

Rest of the world

Ibaraki, Japan The Daibou East *BSD Users Group (DEBUG) is now forming for *BSD users in Tsukuba area.
Indonesia The Jogja FreeBSD Users' Group is based in Yogyakarta City, Indonesia. Send email to 22961476@students.ukdw.ac.id for more information.
Israel The Israeli BSD Users Group is an effort to promote the use of *BSD throughout the country, and to act as a center of information for all BSD users. It is currently run by FreeBSD users, but all users of bsd Variants are welcome aboard. We have a mailing list, hosted at bsd-il@osem.co.il. To subscribe, simply send mail to majordomo@osem.co.il, with the line "subscribe bsd-il" as the message body.
Kansai, Japan The Kansai *BSD User's Group, K*BUG (sorry for Japanese only), was established on November 13, 1999. It is expected to promote communication of any of the BSD variants' users. Some of its activities are to hold friendly parties of the members, and to hold seminars covering wide variety of topics. Please mail here ( kbug-admin@kbug.gr.jp ).
New Zealand The New Zealand FreeBSD User's group is located in Wellington. No meetings have been scheduled yet.
Niigata, Japan The Echigo BSD Users Group (EBUG) is the users group for BSD users around Echigo (aka Niigata). For more information on our events and mailing lists, please check the EBUG web site.
Brazil The FUG-BR (Brazilian FreeBSD User Group) is a Portuguese language oriented user group intended to help Brazilian FreeBSD users to find support and articles on and about FreeBSD in the Portuguese language. We keeps some projects such as the "FreeBSD LiveCD". Currently the group has 600 members and our maillist has an average traffic of 80 messages per day. To join FUG-BR mailing list, visit http://www2.fugspbr.org/mailman/listinfo/fugspbr.

FreeBSD Development Projects

In addition to the mainstream development path of FreeBSD, a number of developer groups are working on the cutting edge to expand FreeBSD's range of applications in new directions.

FreeBSD Security Guide

Security resources available to FreeBSD users: PGP Key for Security Officers, advisories, patches and mailing lists.

Commercial Consulting Services

Whether you are just starting out with FreeBSD, or need to complete a large project, a consultant or two might be your answer.

General Unix Information

The Unix Reference Desk by Mennifer Myers
Jeff's Unix Vault
Unix Guru Universe
O'Reilly & Associates, Inc.
Unix Power

The X Window System

The XFree86 Project provides users of a variety of Intel based Unix systems, including FreeBSD, with an excellent X Window system.
The WINE project is working to provide the ability to run MS-Windows software on Intel based Unix systems such as FreeBSD, NetBSD and Linux.

Hardware

The comp.answers pc-hardware-faq is a great reference for people building their own machines.
Laptop users looking for PCCARD (aka PCMCIA) support not already provided in the FreeBSD base distribution should see the PAO distribution page for the latest and greatest experimental laptop support.
Intel Secrets -- What Intel Doesn't Want You To Know - lots of information about Intel chips.
Aad Offerman's Chip List - reference material on chips used in PC clones.
ASUS makes motherboards that work well with FreeBSD.

Related Operating System Projects

NetBSD is another free 4.4BSD-Lite based operating system which runs on several different architectures.
OpenBSD is another 4.4BSD derivative.
Linux is another free Unix-like system.
Lites is a 4.4 BSD Lite based server and emulation library that provides free Unix functionality to a Mach based system.
xMach is a Lites and Mach4 derivative designed to be small and efficient with extended functionality.
The GNU HURD project is another effort to develop a free Unix-like operating system.

&footer; diff --git a/en/where.sgml b/en/where.sgml index bc6d7b0bb9..63bcbce8bf 100644 --- a/en/where.sgml +++ b/en/where.sgml @@ -1,138 +1,138 @@ + %includes; ]> &header;

Release Information

Detailed descriptions of past, present, and future releases. Look here first to determine what the latest version of FreeBSD is.

Installing FreeBSD

There are many options for installing FreeBSD, including installation from CDROM, floppy disk, an MS-DOS partition, magnetic tape, anonymous ftp, and NFS. Please read through the installation guide before downloading + href="doc/en_US.ISO8859-1/books/handbook/install.html">installation guide before downloading the entire FreeBSD distribution. If you are installing on a machine connected to the Internet, you may only need to download a single installation disk image!

Distribution Sites

The official sources for FreeBSD are:

Anonymous ftp from ftp://ftp.FreeBSD.org/pub/FreeBSD:
Anonymous ftp from one of the numerous mirror sites

mirror sites

On CDROM from FreeBSD Mall

If you plan on getting FreeBSD via ftp, please check the listing of mirror sites in the + href="doc/en_US.ISO8859-1/books/handbook/mirrors.html">mirror sites in the handbook to see if there is a site closer to you. For more information about past, present and future releases in general, please visit the release information page.

If you're interested in a purely experimental snapshot release of FreeBSD-current (AKA 5.0-current), aimed at developers and bleeding-edge testers only, then please see the daily snapshot server FTP site.

Applications and Utility Software

The Packages collection

The FreeBSD packages collection is a diverse collection of utility and application software that has been ported to FreeBSD. The packages are pre-compiled binaries ready to drop into your system and run.

The Ports collection

The Ports collection is like the packages collection, but the necessary patches and makefiles to compile the source code are provided instead of compiled binaries. For software with important configuration that must be done at compile time, the "port" version may be more useful than the "package" version.

For information about how you can contribute your favorite piece of software to the port collection, have a look at The Porter's Handbook and - the Contributing to + the Contributing to FreeBSD chapter in - the FreeBSD handbook.

+ the FreeBSD handbook.

Commercial software

Beginning with FreeBSD Release 2.0.5, FreeBSD includes demo versions of some commercial as well as some shareware products. In addition to the demos available in the FreeBSD distribution, a number of other commercial vendors offer software products specifically for FreeBSD.

Commercial vendors supporting FreeBSD

&footer; diff --git a/share/sgml/advisories.xml b/share/sgml/advisories.xml index 764b5f3f82..e89bed45dc 100644 --- a/share/sgml/advisories.xml +++ b/share/sgml/advisories.xml @@ -1,676 +1,676 @@ - + %includes; ]> - + &header;
Introduction

This web page is designed to assist both new and experienced users in the area of FreeBSD security. FreeBSD takes security very seriously and is constantly working on making the OS as secure as possible.

Here you will find additional information, or links to information, on how to protect your system against various types of attack, on whom to contact if you find a security-related bug, and so on. There is also a section on the various ways that the systems programmer can become more security conscious so that he is less likely to introduce vulnerabilities.

Table of Contents

Information about the FreeBSD Security Officer Team

FreeBSD Security Advisories

FreeBSD Security Mailing Lists Information

FreeBSD Security Tips and Tricks

Secure Programming Guidelines

Other Related Security Information

The FreeBSD Security Officer Team

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security related communications: the FreeBSD Security Officer team. The position is staffed by a team of dedicated security officers, whose main tasks are to send out advisories when there are known security holes and to act on reports of possible security problems with FreeBSD.

If you need to contact someone from FreeBSD about a possible security bug, you should therefore send mail to the Security Officer team with a description of what you have found and the type of vulnerability it represents. The Security Officer team also communicates with the various CERT and FIRST teams around the world, sharing information about possible vulnerabilities in FreeBSD or utilities commonly used with FreeBSD. The Security Officers are also active members of those organizations.

If you do need to contact the Security Officer team about a particularly sensitive matter, please use their PGP key to encrypt your message before sending it.

FreeBSD Security Advisories

The FreeBSD Security Officer Team provides security advisories for the following releases of FreeBSD:

The most recent official release of FreeBSD.

FreeBSD-stable, when at least 2 releases are based on it.

The previous FreeBSD-stable when a "new stable" does not yet have 2 releases based on it.

At this time, security advisories are being released for:

FreeBSD 4.5-RELEASE

FreeBSD 4.6-RELEASE

FreeBSD 4.6-STABLE

Older releases are not maintained and users are strongly encouraged to upgrade to one of the supported releases mentioned above.

Like all development efforts, security fixes are first brought into -the FreeBSD-current branch. +the FreeBSD-current branch. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory is then sent out.

Some statistics about advisories released during 2000:

A total of 81 advisories were released, covering both the base system (i.e. the default FreeBSD installation) and the optional third party applications included in the ports collection.

24 advisories (of various severity) were issued for the base system, with the remaining 57 relating to optional third party applications available in the ports collection.

19 vulnerabilities (8 base system and 11 ports) were discovered internally by members of the FreeBSD team during source code auditing.

9 advisories described vulnerabilities found only in FreeBSD (6 base system advisories, and 3 ports advisories), the remaining 72 advisories were problems shared with at least one other OS (often due to shared code).

Advisories are sent to the following FreeBSD mailing lists:

FreeBSD-security-notifications@FreeBSD.org

FreeBSD-security@FreeBSD.org

FreeBSD-announce@FreeBSD.org

Advisories are always signed using the FreeBSD Security Officer PGP key and are archived, along with their associated patches, at our FTP CERT repository. At the time of this writing, the following advisories are currently available (note that this list may be a few days out of date - for the very latest advisories please check the FTP site):

FreeBSD-SA-02:28.resolv.asc

FreeBSD-SN-02:04.asc

FreeBSD 4.6-RELEASE released.

FreeBSD-SA-02:27.rc.asc

FreeBSD-SA-02:26.accept.asc

FreeBSD-SN-02:03.asc

FreeBSD-SA-02:25.bzip2.asc

FreeBSD-SA-02:24.k5su.asc

FreeBSD-SN-02:02.asc

FreeBSD-SA-02:23.stdio.asc

FreeBSD-SA-02:22.mmap.asc

FreeBSD-SA-02:21.tcpip.asc

FreeBSD-SA-02:20.syncache.asc

FreeBSD-SN-02:01.asc

FreeBSD-SA-02:19.squid.asc

FreeBSD-SA-02:18.zlib.v1.2.asc

FreeBSD-SA-02:17.mod_frontpage.asc

FreeBSD-SA-02:16.netscape.asc

FreeBSD-SA-02:15.cyrus-sasl.asc

FreeBSD-SA-02:14.pam-pgsql.asc

FreeBSD-SA-02:13.openssh.asc

FreeBSD-SA-02:12.squid.asc

FreeBSD-SA-02:11.snmp.asc

FreeBSD-SA-02:10.rsync.asc

FreeBSD 4.5-RELEASE released.

FreeBSD-SA-02:09.fstatfs.asc

FreeBSD-SA-02:08.exec.asc

FreeBSD-SA-02:07.k5su.asc

FreeBSD-SA-02:06.sudo.asc

FreeBSD-SA-02:05.pine.asc

FreeBSD-SA-02:04.mutt.asc

FreeBSD-SA-02:03.mod_auth_pgsql.asc

FreeBSD-SA-02:02.pw.asc

FreeBSD-SA-02:01.pkg_add.asc

FreeBSD-SA-01:64.wu-ftpd.asc

FreeBSD-SA-01:63.openssh.asc

FreeBSD-SA-01:62.uucp.asc

FreeBSD-SA-01:61.squid.asc

FreeBSD-SA-01:60.procmail.asc

FreeBSD 4.4-RELEASE released.

FreeBSD-SA-01:59.rmuser.v1.1.asc

FreeBSD-SA-01:58.lpd.asc

FreeBSD-SA-01:57.sendmail.v1.2.asc

FreeBSD-SA-01:56.tcp_wrappers.asc

FreeBSD-SA-01:55.procfs.asc

FreeBSD-SA-01:54.ports-telnetd.asc

FreeBSD-SA-01:53.ipfw.asc

FreeBSD-SA-01:52.fragment.asc

FreeBSD-SA-01:51.openssl.v1.1.asc

FreeBSD-SA-01:50.windowmaker.asc

FreeBSD-SA-01:49.telnetd.v1.1.asc

FreeBSD-SA-01:48.tcpdump.asc

FreeBSD-SA-01:47.xinetd.asc

FreeBSD-SA-01:46.w3m.asc

FreeBSD-SA-01:45.samba.asc

FreeBSD-SA-01:44.gnupg.asc

FreeBSD-SA-01:43.fetchmail.asc

FreeBSD-SA-01:42.signal.v1.1.asc

FreeBSD-SA-01:41.hanterm.asc

FreeBSD-SA-01:40.fts.v1.1.asc

FreeBSD 4.3-RELEASE released.

FreeBSD-SA-01:39.tcp-isn.asc

FreeBSD-SA-01:38.sudo.asc

FreeBSD-SA-01:37.slrn.asc

FreeBSD-SA-01:36.samba.asc

FreeBSD-SA-01:35.licq.asc

FreeBSD-SA-01:34.hylafax.asc

FreeBSD-SA-01:33.ftpd-glob.v1.1.asc

FreeBSD-SA-01:32.ipfilter.v1.1.asc

FreeBSD-SA-01:31.ntpd.asc

FreeBSD-SA-01:30.ufs-ext2fs.asc

FreeBSD-SA-01:29.rwhod.asc

FreeBSD-SA-01:28.timed.asc

FreeBSD-SA-01:27.cfengine.asc

FreeBSD-SA-01:26.interbase.asc

FreeBSD-SA-01:25.kerberosIV.asc

FreeBSD-SA-01:24.ssh.asc

FreeBSD-SA-01:23.icecast.asc

FreeBSD-SA-01:22.dc20ctrl.asc

FreeBSD-SA-01:21.ja-elvis.asc

FreeBSD-SA-01:20.mars_nwe.asc

FreeBSD-SA-01:19.ja-klock.asc

FreeBSD-SA-01:18.bind.asc

FreeBSD-SA-01:17.exmh.asc

FreeBSD-SA-01:16.mysql.asc

FreeBSD-SA-01:15.tinyproxy.asc

FreeBSD-SA-01:14.micq.asc

FreeBSD-SA-01:13.sort.asc

FreeBSD-SA-01:12.periodic.v1.1.asc

FreeBSD-SA-01:11.inetd.v1.1.asc

FreeBSD-SA-01:10.bind.asc

FreeBSD-SA-01:09.crontab.asc

FreeBSD-SA-01:08.ipfw.asc

FreeBSD-SA-01:07.xfree86.asc

FreeBSD-SA-01:06.zope.asc

FreeBSD-SA-01:05.stunnel.asc

FreeBSD-SA-01:04.joe.asc

FreeBSD-SA-01:03.bash1.asc

FreeBSD-SA-01:02.syslog-ng.asc

FreeBSD-SA-01:01.openssh.asc

FreeBSD-SA-00:81.ethereal.asc

FreeBSD-SA-00:80.halflifeserver.asc

FreeBSD-SA-00:79.oops.asc

FreeBSD-SA-00:78.bitchx.v1.1.asc

FreeBSD-SA-00:77.procfs.v1.1.asc

FreeBSD-SA-00:76.tcsh-csh.asc

FreeBSD-SA-00:75.php.asc

FreeBSD-SA-00:74.gaim.asc

FreeBSD-SA-00:73.thttpd.asc

FreeBSD-SA-00:72.curl.asc

FreeBSD-SA-00:71.mgetty.asc

FreeBSD-SA-00:70.ppp-nat.asc

FreeBSD-SA-00:69.telnetd.v1.1.asc

FreeBSD-SA-00:68.ncurses.v1.1.asc

FreeBSD-SA-00:67.gnupg.asc

FreeBSD-SA-00:66.netscape.asc

FreeBSD-SA-00:65.xfce.asc

FreeBSD-SA-00:64.global.asc

FreeBSD-SA-00:63.getnameinfo.asc

FreeBSD-SA-00:62.top.v1.1.asc

FreeBSD-SA-00:61.tcpdump.v1.1.asc

FreeBSD-SA-00:60.boa.asc

FreeBSD-SA-00:59.pine.asc

FreeBSD-SA-00:58.chpass.asc

FreeBSD-SA-00:57.muh.asc

FreeBSD-SA-00:56.lprng.asc

FreeBSD-SA-00:55.xpdf.asc

FreeBSD-SA-00:54.fingerd.asc

FreeBSD-SA-00:53.catopen.asc

FreeBSD-SA-00:52.tcp-iss.asc

FreeBSD-SA-00:51.mailman.asc

FreeBSD-SA-00:50.listmanager.asc

FreeBSD-SA-00:49.eject.asc

FreeBSD-SA-00:48.xchat.asc

FreeBSD-SA-00:47.pine.asc

FreeBSD-SA-00:46.screen.asc

FreeBSD-SA-00:45.esound.asc

FreeBSD-SA-00:44.xlock.asc

FreeBSD-SA-00:43.brouted.asc

FreeBSD-SA-00:42.linux.asc

FreeBSD-SA-00:41.elf.asc

FreeBSD-SA-00:40.mopd.asc

FreeBSD-SA-00:39.netscape.asc

FreeBSD-SA-00:38.zope.asc

FreeBSD-SA-00:37.cvsweb.asc

FreeBSD-SA-00:36.ntop.asc

FreeBSD-SA-00:35.proftpd.asc

FreeBSD-SA-00:34.dhclient.asc

FreeBSD-SA-00:33.kerberosIV.asc

FreeBSD-SA-00:32.bitchx.asc

FreeBSD-SA-00:31.canna.asc.v1.1

FreeBSD-SA-00:30.openssh.asc

FreeBSD-SA-00:29.wu-ftpd.asc.v1.1

FreeBSD-SA-00:28.majordomo.asc

FreeBSD-SA-00:27.XFree86-4.asc

FreeBSD-SA-00:26.popper.asc.v1.1

FreeBSD-SA-00:25.alpha-random.asc

FreeBSD-SA-00:24.libedit.asc

FreeBSD-SA-00:23.ip-options.asc.v1.1

FreeBSD-SA-00:22.apsfilter.asc

FreeBSD-SA-00:21.ssh.asc.v1.1

FreeBSD-SA-00:20.krb5.asc

FreeBSD-SA-00:19.semconfig.asc

FreeBSD-SA-00:18.gnapster.knapster.asc.v1.1

FreeBSD-SA-00:17.libmytinfo.asc

FreeBSD-SA-00:16.golddig.asc

FreeBSD-SA-00:15.imap-uw.asc

FreeBSD-SA-00:14.imap-uw.asc

FreeBSD-SA-00:13.generic-nqs.asc

FreeBSD-SA-00:12.healthd.asc

FreeBSD-SA-00:11.ircii.asc

FreeBSD-SA-00:10.orville-write.asc

FreeBSD-SA-00:09.mtr.asc

FreeBSD-SA-00:08.lynx.asc.v1.1

FreeBSD-SA-00:07.mh.asc

FreeBSD-SA-00:06.htdig.asc

FreeBSD-SA-00:05.mysql.asc

FreeBSD-SA-00:04.delegate.asc

FreeBSD-SA-00:03.asmon.asc

FreeBSD-SA-00:02.procfs.asc

FreeBSD-SA-00:01.make.asc

FreeBSD-SA-99:06.amd.asc

FreeBSD-SA-99:05.fts.asc

FreeBSD-SA-99:04.core.asc

FreeBSD-SA-99:03.ftpd.asc

FreeBSD-SA-99:02.profil.asc

FreeBSD-SA-99:01.chflags.asc

FreeBSD-SA-98:08.fragment.asc

FreeBSD-SA-98:07.rst.asc

FreeBSD-SA-98:06.icmp.asc

FreeBSD-SA-98:05.nfs.asc

FreeBSD-SA-98:04.mmap.asc

FreeBSD-SA-98:03.ttcp.asc

FreeBSD-SA-98:02.mmap.asc

FreeBSD-SA-98:01.land.asc

FreeBSD-SA-97:06.f00f.asc

FreeBSD-SA-97:05.open.asc

FreeBSD-SA-97:04.procfs.asc

FreeBSD-SA-97:03.sysinstall.asc

FreeBSD-SA-97:02.lpd.asc

FreeBSD-SA-97:01.setlocale

FreeBSD-SA-96:21.talkd.asc

FreeBSD-SA-96:20.stack-overflow.asc

FreeBSD-SA-96:19.modstat.asc

FreeBSD-SA-96:18.lpr.asc

FreeBSD-SA-96:17.rzsz.asc

FreeBSD-SA-96:16.rdist.asc

FreeBSD-SA-96:15.ppp.asc

FreeBSD-SA-96:14.ipfw.asc

FreeBSD-SA-96:13.comsat.asc

FreeBSD-SA-96:12.perl.asc

FreeBSD-SA-96:11.man.asc

FreeBSD-SA-96:10.mount_union.asc

FreeBSD-SA-96:09.vfsload.asc

FreeBSD-SA-96:08.syslog.asc

FreeBSD-SA-96:03.sendmail-suggestion.asc

FreeBSD-SA-96:02.apache.asc

FreeBSD-SA-96:01.sliplogin.asc

FreeBSD Security Mailing Lists Information

If you are administering or using any number of FreeBSD systems, you should probably be subscribed to one or more of the following lists:

freebsd-security General security related discussion freebsd-security-notifications Security notifications (moderated mailing list)
Send mail to majordomo@FreeBSD.ORG with
subscribe <listname> [<optional address>]
in the body of the message in order to subscribe yourself. For example:
% echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org
and if you would like to unsubscribe from a mailing list:
% echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org

Secure Programming Guidelines

Never trust any source of input, i.e. command line arguments, environment variables, configuration files, incoming TCP/UDP/ICMP packets, hostname lookups, function arguments, etc. If the length of or contents of the date received is at all subject to outside control, then the program or function should watch for this when copying it around. Specific security issues to watch for in this are:

strcpy() and sprintf() calls from unbounded data. Use strncpy and snprintf() when the length is known (or implement some other form of bounds-checking when the length is unknown). In fact, never ever use gets() or sprintf(), period. If you do - we will send evil dwarfs after you.

If you have to check the user input so it does not contain bad characters of some sort, do NOT check for those bad characters. Instead simply verify that it consists ONLY of those characters that you do allow. In general concept is: disallow anything that is not explicitly allowed.

Read man pages for strncpy() and strncat() calls. Be sure to understand how they work!!! While strncpy() might not append a terminating \0, strncat() on the other hand adds the \0.

Watch for strvis() and getenv() abuse. With strvis() it is easy to get the destination string wrong, and getenv() can return strings much longer then the program might expect. These two functions are one of the key ways an attack is often made on a program, causing it to overwrite stack or variables by setting its environment variables to unexpected values. If your program reads environment variables, be paranoid. Be very paranoid!

Ever time you use open() or stat() call - ask yourself: "What if it is a symbolic link?"

Make sure to use mkstemp() instead of mktemp(), tempnam(), etc. Also make sure to look for races in /tmp in general, being aware that there are very few things which can be atomic in /tmp:

Creating a directory. This will either succeed or fail.

Opening a file O_CREAT | O_EXCL

If you use mkstemp() the above cases will be properly handled for you. Hence all temp files should use mkstemp() to guarantee there is not race condition and that the permissions are correct.

If an attacker can force packets to go/come from another arbitrary system then that attacker has complete control over the data that we get and NONE of it should be trusted.

Never trust a configuration file is correctly formatted or that it was generated by the appropriate utility. Don't trust user input such as terminal names or language strings to be free of '/' or '../../../' if there is any chance that they can be used in a path name. Don't trust ANY paths supplied by the user when you are running setuid root.

Look for holes or weaknesses in how data is stored. All temp files should have 600 permission in order to be protected from prying eyes.

Do not just grep for the usual suspects in programs which run with elevated privileges. Look line by line for possible overflows in these cases since there are a lot more ways to cause buffer overflows than by abusing strcpy() and friends.

Just because you drop privileges somewhere, it does not mean that no exploit is possible. The attacker may put the necessary code on the stack to regain the privileges before executing /bin/sh.

Do uid management. Do drop privileges as soon as possible, and really do drop them. Switching between euid and uid is NOT enough. Use setuid() when you can.

Never display configuration file contents on errors. A line number and perhaps position count is enough. This is true for all libs and for any suid/sgid program.

Tips for those reviewing existing code for security problems:

If you are unsure of your security fixes, send them to a reviewer with whom you already have arrangements for a second glance over your code. Don't commit code you are not sure about since breaking something in the name of a security fix is rather embarrassing.

Those without CVS commit privileges should make sure that a reviewer with such privileges is among the last to review the changes. That person will both review and incorporate the final version you would like to have go into the tree.

When sending changes around for review, always use context or unidiff format diffs - this way diffs can be easily fed to patch(1). Do not simply send the whole files. Diffs are much easier to read and apply to local sources (especially those in which multiple, simultaneous changes may be taking place). All changes should be relative to the -current branch of development.

Always directly test your changes (e.g. build and run the affected sources) before sending them to a reviewer. Nobody likes being sent obviously broken stuff for review, and it just makes it appear as though the submitter didn't even really look at what he was submitting (which is also hardly confidence building). If you need accounts on a machine with a specific version which you don't have available - just ask. The project has resources available for exactly such purposes.

Note for committers: do not forget to retrofit -current patches into the -stable branch as appropriate.

Do not needlessly rewrite code to suit your style/tastes - it only makes the reviewer's job needlessly more difficult. Do so only if there are clear reasons for it.

Look out for programs doing complex things with signal handlers. Many routines in the various libraries are not sufficiently reentrant to make this safe.

Pay special attention to realloc() usage - more often then not the function is not used correctly.

When using fixed size buffers, use sizeof() to prevent lossage when a buffer size is changed but the code which uses it isn't. For example:
char buf[1024]; struct foo { ... }; ... BAD: xxx(buf, 1024) xxx(yyy, sizeof(struct foo)) GOOD: xxx(buf, sizeof(buf)) xxx(yyy, sizeof(yyy))
Be careful though with sizeof of pointers when you really want the size of where it points to!

Every time you see "char foo[###]", check every usage of foo to make sure that it can't be overflowed. If you can't avoid overflow (and cases of this have been seen), then at least malloc the buffer so that one can't walk on the stack.

Always close file descriptors as soon as you can - this makes it more likely that the stdio buffer contents will be discarded. In library routines, always set any file descriptors that you open to close-on-exec.

A useful auditing tool is the its4 port, located in /usr/ports/security/its4/. This is an automated C code auditor which highlights potential trouble-spots in the code. It is a useful first-pass tool, but should not be relied upon as being authoritative, and a complete audit should include human examination of the entire code.

For more information on secure programming techniques and resources, see the How to Write Secure Code resource center.

FreeBSD Security Tips and Tricks

There are several steps one must take to secure a FreeBSD system, or in fact any Unix system:

Disabling potentially dangerous software
A lot of software has to be run as a special privileged user to make use of specific resources, by making the executable set-uid. An example is UUCP or PPP software that makes use of a serial port, or sendmail which has to write in the mail spool and bind to a privileged network port. When you are not using UUCP, it is of little use to have software on your system and it may be wise to disable it. Of course, this requires good knowledge of what can be thrown away and what not, as well as good indication whether or not you will want the functionality in the future.
Also some utilities you may find not useful enough to have around pose a possible security risk, like swapinfo. If you remove the set-uid bit for the executable (via 'chmod ug-s filename' command) you can always keep on using swapinfo when you're root. It is however not a good idea to strip so many sbits that you have to be root all the time.
Not only remove programs that you don't use, also remove services you don't want or need to provide. This can be done by editing the /etc/inetd.conf and /etc/rc.conf files and turning off all services you don't use.

Fixing software which has security bugs (or how to stay one step ahead of crackers)
Make sure you are subscribed to various FreeBSD Security mailing lists so you get updates on security bugs and fixes. Apply the fixes immediately.

Backups - repair your system if a security breach does occur
Always have backups and a clean version of the operating system (e.g. on CD-Rom). Make sure your backups do not contain corrupted data or data modified by attackers.

Install software to watch the state of the system
Programs like the tcp wrappers and tripwire (both in packages/ports) can help you to monitor activity on your system. This makes it easier to detect break-ins. Also read outputs of the /etc/security scripts which are run daily and mailed to the root account.

Educating the people who work on the system
Users should know what they are doing. They should be told to never give out their password to anyone and to also use hard-to-guess passwords. Let them understand that the security of the system/network is partly in their hands.

There is also a FreeBSD Security How-To available which provides some advanced tips on how to improve security of your system. You can find it at http://www.FreeBSD.org/~jkb/howto.html.

Security is an ongoing process. Make sure you are following the latest developments in the security arena.

What to do when you detect a security compromise

Determine the level of the security breach
What privileges did the attacker get? Did the attacker manage to get root access? Did the attacker only manage to get user level access?

Determine if the state of system (kernel or userland) has been tampered with
What software has been tampered with? Was new kernel installed? Were any of the system binaries (such as telnetd, login, etc) modified? If you believe an attacker could have done any tampering with an OS, you may want to re-install the operating system from a safe medium.

Find out how the break-in was done
Did the break-in occur via a well-known security bug? If that is the case, make sure to install the correct patches. Was the break-in successful due to a misconfiguration? Was the break-in result of a new bug? If you believe the break-in occurred via a new bug, you should warn the FreeBSD Security Officer.

Fix the security hole
Install new software or apply patches to the old one in order to fix the problems. Disable any compromised accounts.

Other resources
CERT also offers detailed information on what steps to take in case of a system compromise.

Other Related Security Information

The COAST archive contains a huge collection of security related materials.

The COAST Security Hotlist is the place to start looking for security related materials. It contains hundreds of useful security pointers. Everything you always wanted to know about security... and more.

The various CERT teams such as http://www.cert.org and http://www.auscert.org.au.

Mailing lists such as Bugtraq and Firewall Wizards.

&footer