diff --git a/en/copyright/daemon.sgml b/en/copyright/daemon.sgml index 257b97e1f7..8cead42449 100644 --- a/en/copyright/daemon.sgml +++ b/en/copyright/daemon.sgml @@ -1,72 +1,72 @@ - + %includes; ]> - + &header;

The little red fellow that graces many of these pages is the BSD Daemon. In the context of Unix systems, daemons are process that run in the background attending to various tasks without human intervention. In the general sense, daemon is an older form of the word demon. In the Unix System Administration Handbook, Evi Nemeth has this to say about daemons:

"Many people equate the word ``daemon'' with the word ``demon,'' implying some kind of Satanic connection between UNIX and the underworld. This is an egregious misunderstanding. ``Daemon'' is actually a much older form of ``demon''; daemons have no particular bias towards good or evil, but rather serve to help define a person's character or personality. The ancient Greeks' concept of a ``personal daemon'' was similar to the modern concept of a ``guardian angel'' --- ``eudaemonia'' is the state of being helped or protected by a kindly spirit. As a rule, UNIX systems seem to be infested with both daemons and demons." (p403)

The earliest (and most popular) renditions of the BSD Daemon were created by John Lasseter. More recent FreeBSD-specific renditions have done by Tatsumi Hosokawa, but the basic inspiration was definitely John's. The copyright holder and creator of the daemon image is Marshall Kirk McKusick. A short pictorial history is also available. There is a gallery of FreeBSD related publications that use variations of the daemon graphic.

Various size stuffed and beanie daemons are available from the FreeBSD Mall - . In europe, German-made + . In Europe, German-made stuffed daemons are also available from Liebscher & Partner.

ScotGold produce 1" case badges featuring BSD Daemon.

BSD Daemon Copyright 1988 by Marshall Kirk McKusick. All Rights Reserved.

Permission to use the daemon may be obtained from:

Marshall Kirk McKusick
1614 Oxford St
Berkeley, CA 94709-1608
USA

or via email at mckusick@mckusick.com.

Copyright Home &footer; diff --git a/en/docproj/current.sgml b/en/docproj/current.sgml index 61c179867f..ee1fe1bc14 100644 --- a/en/docproj/current.sgml +++ b/en/docproj/current.sgml @@ -1,240 +1,240 @@ - + %includes; ]> - + &header;

Here are the projects currently under way (or being actively contemplated on the freebsd-doc mailing list). I have also included some that have not really been talked about, but would probably be a good idea. Each project lists the contact person for that project (if I know who it is).

If you think you can contribute to any of these, please do not hesitate to stand up and be counted. You should talk to the person responsible for that particular project, who can then bring you up to speed on what is happening.

-

Any ommissions in this list are entirely my fault (Nik Clayton, +

Any omissions in this list are entirely my fault (Nik Clayton, <nik@FreeBSD.ORG>), sorry in advance to anyone whose project I have missed.

Open documentation problem reports

Current FreeBSD problems reports are tracked using the GNATS database. You can view - the open documenation problem reports.

+ the open documentation problem reports.

FreeBSD for Linux users

Responsible: Annelise Anderson < andrsn@andrsn.stanford.edu>

Synopsis: Linux users coming to FreeBSD can be confused by some of the differences between the systems (the different default shells, how boot time configuration is performed, and so on). Annelise is coordinating the development of a tutorial/FAQ section that will address these points.

The list of current questions is at http://freebsd.stanford.edu/FreeBSD/linux.html.

Fixup the FOO.TXT files

Responsible: Doug <studded@dal.net>

Synopsis: The "FOO.TXT" files are the README files, the INSTALL.TXTs. the ABOUT.TXTs and so on that you get with FreeBSD. Doug (and others) are going through these trying to make sure they are accurate, consistent, and easy to understand. A very worthwhile task.

Write a section in the Handbook and/or FAQ

Responsible: No one

Synopsis: Chunks of the FAQ and Handbook have empty sections in them. They need filling. If you have just had to use one of these documents to complete a task, and found them lacking, please find the time to write up your experiences as a possible replacement.

Alternatively, if you have just had to do something that had no entry in the FAQ and/or Handbook, please consider writing a new section. Then submit it as outlined above.

Write some new Papers

The New SCSI layer for FreeBSD (CAM)

Responsible: <doc@FreeBSD.org>, <scsi@FreeBSD.org>

Synopsis: See The Design and Implementation of the FreeBSD SCSI Subsystem for a first snapshot.

Write some new Tutorials

Responsible: <doc@FreeBSD.org>

Synopsis:

Write Manpages for the kernel

Responsible: <doc@FreeBSD.org>

Synopsis: Document kernel functions, section 9

CGI Scripts

Responsible: <doc@FreeBSD.org>, Wolfram Schneider <wosch@FreeBSD.org>

Synopsis:

Here are some hints how to write the ports module

A single line in /usr/ports/INDEX looks like

    xfig-3.2.2|/usr/ports/graphics/xfig|/usr/X11R6|A drawing program for X11|/usr/ports/graphics/xfig/pkg/DESCR|ports@FreeBSD.ORG|graphics x11|XFree86-3.3.2 Xaw3d-1.3 jpeg-6b xpm-3.4k|XFree86-3.3.2 Xaw3d-1.3 jpeg-6b netpbm-94.3.1 tiff-3.4 transfig-3.2 xpm-3.4k

The format is

    distribution-name|port-path|installation-prefix|comment| \
        description-file|maintainer|categories|build deps|run deps

The above INDEX line parsed into an anonymous hash object

 $port = {	
 	DISTRIBUTION_NAME   => 'xfig-3.2.2',
 	PORT_PATH           => '/usr/ports/graphics/xfig',
 	INSTALLATION_PREFIX => '/usr/X11R6',
 	COMMENT             => 'A drawing program for X11',
 	DESCRIPTION_FILE    => '/usr/ports/graphics/xfig/pkg/DESCR',
 	MAINTAINER          => 'ports@FreeBSD.ORG',
 	CATEGORIES          => ['graphics', 'x11'],
 	BUILD_DEPS          => ['XFree86-3.3.2', 'Xaw3d-1.3', 'jpeg-6b', 
 	                        'xpm-3.4k'],
 	RUN_DEPS            => ['XFree86-3.3.2',  'Xaw3d-1.3', 'jpeg-6b',
 				'netpbm-94.3.1', 'tiff-3.4', 'transfig-3.2',
 				'xpm-3.4k'] 
 };

Now we need some functions

Finally

Modify the cgi script url.cgi, ports.cgi , pds.cgi and the script portindex to use this module.

Contact Nik Clayton <nik@FreeBSD.ORG> for a first snapshot of the ports module.

Multilingual Web scripts

Responsible: <doc@FreeBSD.org>

Synopsis:

Our main Web pages are written in (American) English. The FreeBSD Translations Projects translate the web pages, Handbook and FAQ to other languages.

We must translate the cgi scripts and web build scripts too. The scripts should support multiple languages, not only one. Most scripts are written in perl.

Translations of the FreeBSD Documentation

Responsible: <doc@FreeBSD.org>

Translate the FreeBSD documentation (Web pages, FAQ, handbook, manpages) into other languages. See the FreeBSD translations projects

Search engine enhancements

Responsible: <doc@FreeBSD.org>

When searching the website, the output from the search engine includes the filename that was found, which might be something like FAQ34.html.

It would be more useful if the results included the question text, allowing the user to see whether or not the result was relevant.

FreeBSD Documentation Project Home &footer diff --git a/en/docproj/submitting.sgml b/en/docproj/submitting.sgml index 19206ec1af..3430b9b421 100644 --- a/en/docproj/submitting.sgml +++ b/en/docproj/submitting.sgml @@ -1,135 +1,135 @@ - + %includes; ]> - + &header;

I have written some documentation. How do I submit it?

First, thank you for taking the time to do this.

You should make your documentation available for review. If you can, put it on an FTP site or a website.

Then post a message to the -doc mailing list, with a brief outline of the documentation and the pointer to its location, and solicit feedback.

If, for some reason, you can not put the documentation up for FTP or on a web site somewhere you can send it directly to the -doc mailing list. If you do this, please only send plain text documents.

You should probably cc: this request for comments to other appropriate mailing lists. For example, something that relates to how to use CVSup to keep your source tree up to date would be of interest to the subscribers of the FreeBSD-current and FreeBSD-stable mailing lists.

After people have looked over your documentation, and you have had the chance to incorporate any of their suggestions, you are ready to submit it.

To do this, wrap it up into a tar file. If your documentation consists of three files, 

     % tar cf doc.tar one two three

which does just that. Then compress the tar file,

     % gzip -9 doc.tar

which will produce doc.tar.gz.

Finally, encode the file so that it will not be mangled by any e-mail programs.

     % uuencode doc.tar.gz doc.tar.gz > doc.uue

You should then let the Documentation Project know about it. The correct way to do this is to use a command called send-pr, which should be installed on your machine.

You do this so that your submission can be tracked. When you submit a PR (Problem Report) it is assigned a unique number. One of the committers can then assign the PR to themselves, and liase with you on committing the new documentation.

send-pr itself is pretty simple. All it does is send an e-mail with some special formatting to a particular address. When you run send-pr you will be put into your editor (probably vi or emacs) with a template to fill out, and some instructions on how to fill it out.

Make sure the "Category" is set to "docs" and that the "Class" is set to one of "change-request". You should include the .uue file you created earlier in to the PR.

When you come out of the editor the PR will be sent as an e-mail to the right place. You will get a notification message shortly afterwards telling you what number your PR has been given, and this number can be used to track its progress.

Alternatively, you can use the web interface at http://www.FreeBSD.org/send-pr.html.

I have made some changes to existing documentation, how do I submit them?

Again, thank you for taking the time to do this.

First off, you need to produce a special file, called a diff. This diff shows just the changes that you have made. This makes it easier - for the person doing the comitting to see what you have changed, and + for the person doing the committing to see what you have changed, and means you do not need to spend lots of time explaining what you have changed (although you should still explain why you think the change should be made).

To make a 'diff', you should;

  1. Make a copy of the file you are going to change. If you are changing 

         % cp foo.sgml foo.sgml.old

  2. Then, make your changes to foo.sgml

         % vi foo.sgml
     ... tap tap tap ...
 
     ... test the changes, read them for typos and so on ...

  3. Make the diff. The command to do this is

         % diff -c foo.sgml.old foo.sgml > foo.diff

    This looks at the difference between the two files, and writes them to the file

You can then send

FreeBSD Documentation Project Home &footer diff --git a/en/docproj/translations.sgml b/en/docproj/translations.sgml index 41909734a9..24088051e9 100644 --- a/en/docproj/translations.sgml +++ b/en/docproj/translations.sgml @@ -1,158 +1,158 @@ - + %includes; ]> - + &header;

The FreeBSD Chinese Documentation Project

Web: -
E-Mail: foxfair@FreeBSD.org
-
Mailling list available
+
Mailing list available
Send a mail to majordomo@freebsd.sinica.edu.tw with the words "subscribe freebsd-chinese-doc" in the body of the message.
Posting is allowed for the members at freebsd-chinese-doc@freebsd.sinica.edu.tw
Documents available
FAQ
Documents currently at working
Handbook

The FreeBSD Estonian Documentation Project

Web: http://www.matti.ee/~vallo/
Documents available
FreeBSD handbook userppp section

The FreeBSD French Documentation Project

Web: http://www.freebsd-fr.org
Mailing lists available
Send a mail to listserver@freebsd-fr.org with the words "SUB freebsd-questions" in the body of the message for subscribing to the questions mailing list in French.
Send a mail to listserver@freebsd-fr.org with the words "SUB annonces" in the body of the message for subscribing to the announce mailing list in French.
Documents available
FAQ
Some tutorials
Really Quick Newsletters
PicoBSD
Documents currently at working
Handbook
CVS repository
CVS web
Send a mail to listserver@freebsd-fr.org with the words "SUB cvs" in the body of the message for subscribing to the French CVS update mailing list in French.

The FreeBSD German Documentation Project

Web: http://www.de.FreeBSD.org/de/uebersetzung.html
E-Mail: de-bsd-translators@de.FreeBSD.org
Documents currently at working
Handbook, FAQ, WWW

The FreeBSD Italian Documentation Project

Web: http://www.gufi.org/
E-Mail: info@gufi.org
Documents currently at working
Handbook

The FreeBSD Japanese Documentation Project

Web: http://www.jp.FreeBSD.org/doc-jp/
E-Mail: doc-jp@jp.FreeBSD.org
Documents available
Handbook, FAQ, Web, FreeBSD NewsLetter Issue #2
Documents currently at working
FreeBSD Tutorials

The FreeBSD Korean Documentation Project

Web: http://www.kr.FreeBSD.org/projects/doc-kr/
E-Mail: doc@kr.FreeBSD.org
Documents currently at working
Handbook

The FreeBSD Russian Documentation Project

Web: http://www.FreeBSD.org.ua
E-Mail: ru-freebsd-doc@FreeBSD.ru
Documents available
FAQ
WWW
Q&A
Porter's handbook
Documents currently at working
Handbook

The FreeBSD Spanish Documentation Project

Web: http://www.es.FreeBSD.org/es/
E-Mail: jesusr@es.FreeBSD.org
Documents available
FAQ
Documents currently at working
Handbook

FreeBSD Documentation Project Home &footer diff --git a/en/docs.sgml b/en/docs.sgml index 7b96790ada..12ad83e1c8 100644 --- a/en/docs.sgml +++ b/en/docs.sgml @@ -1,395 +1,395 @@ + %includes; ]> - + &header;

A wide variety of documentation is available for FreeBSD, on this web site, on other web sites, and available over the counter.

On this site

All the documentation on this site can be downloaded in a variety of different formats (HTML, Postscript, PDF, and more) and compression schemes (GZip, BZip2, Zip) from the FreeBSD FTP site.

This documentation is provided and maintained by the FreeBSD Documentation Project, and we are always looking for people to contribute new documentation and maintain existing documentation.

Books

The FreeBSD FAQ
Frequently Asked Questions, and answers, covering all aspects of FreeBSD.

The FreeBSD Handbook
A constantly evolving, comprehensive resource for FreeBSD users.

The FreeBSD Developer's Handbook
For people who want to develop software for FreeBSD (and not just people who are developing FreeBSD itself).

Chapter 2 of "The Design and Implementation of the 4.4BSD Operating System"
Donated by Addison-Wesley, provides a design overview of 4.4BSD, from which FreeBSD was originally derived.

Chapter 8 of "The FreeBSD Corporate Networker's Guide"
Donated by Addison-Wesley, provides an in-depth look at using FreeBSD to provide printing services to Windows, NT, and Novell hosts.

The Pedantic PPP Primer
Everything you need to know about configuring PPP on FreeBSD.

The Porter's Handbook
Essential reading if you plan on providing a port of a third party piece of software.

The FreeBSD Documentation Project Primer for New Contributors
Everything you need to know in order to start contributing to the FreeBSD Documentation Project.

Articles

The Committer's Guide
Introductory information for FreeBSD committers.

Dialup firewalling with FreeBSD
How to set up a firewall using PPP and ipfw over a dialup link with dynamically assigned IP addresses.

Creating a diskless X server
How to create a diskless X server.

Filtering Bridges
Configuring firewalls and filtering on FreeBSD hosts acting as bridges rather than routers.

Fonts and FreeBSD
A description of the various font technologies in FreeBSD, and how to use them with different programs.

Formatting media on FreeBSD
How to slice, partition, and format fixed and removable media on FreeBSD.

How to get the best results from the FreeBSD-questions mailing list
- Tips and tricks to help you maximise the chances of getting + Tips and tricks to help you maximize the chances of getting useful information from the -questions mailing list.

An MH Primer
An introduction to using the MH mail reader on FreeBSD.

Using FreeBSD with other operating systems
How to install FreeBSD alongside one or more different operating systems on the same computer.

FreeBSD First Steps
For people coming to FreeBSD and Unix for the first time.

Programming Tools on FreeBSD
A user's guide to the various tools for software development on FreeBSD.

PXE booting FreeBSD
How to create an Intel PXE server using FreeBSD, and how to configure a FreeBSD client to boot from a PXE server.

FreeBSD and Solid State Devices
The use of solid state disk devices in FreeBSD.

Design elements of the FreeBSD VM system
An easy to follow description of the design of the FreeBSD virtual memory system.

Zip-drives and FreeBSD
How to format, mount, and use an Iomega Zip (SCSI, IDE, or parallel) Drive on FreeBSD.

Manual pages

FreeBSD
For release: 1.0, 1.1, 1.1.5.1, 2.0, 2.0.5, 2.1.0, 2.1.5, 2.1.6.1, 2.1.7.1, 2.2.1, 2.2.2, 2.2.5, 2.2.6, 2.2.7, 2.2.8, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5.1, 4.0, 4.1, 4.2, 4.3, 5.0-current, Ports.
Other Systems
Unix Seventh Edition (V7), 2.8BSD, 2.9.1BSD, 2.10BSD, 2.11BSD, 4.3BSD Reno, NET/2, 386BSD 0.1, 4.4BSD Lite2, Linux, NetBSD, OpenBSD, Darwin, Plan 9, SunOS 4.x, SunOS 5.x, ULTRIX 4.2, and XFree86.

Other documentation

4.4BSD Documents: This is a hypertext version of the 4.4BSD documents from /usr/share/doc, where you will find the documents on a FreeBSD machine (if you install the doc distribution).

Info Documents: This is a hypertext version of the Info documents from /usr/share/info, where you will find the Info documents on a FreeBSD machine (if you install the info distribution).

On other web sites

Various independent efforts have also produced a great deal of useful information about FreeBSD.

Books

  • A Comprehensive Guide to FreeBSD - an attempt at a more readable, "book-like" tutorial explaining the FreeBSD Operating System. Intended for people new to both FreeBSD and UNIX. Currently a work in progress.

Articles

Links

In the real world...

FreeBSD in the Press

Articles in the press about FreeBSD.

Additional resources

Year 2000 Compatibility

The FreeBSD project's current statement about its Year 2000 compatibility.

BSD Real-Quick (TM) Newsletter

A monthly (sometimes bi-weekly) newsletter announcing recent developments in the FreeBSD arena. Subscribe to freebsd-announce to receive this newsletter via e-mail.

The Source Code

If you like digging your fingers into source code, here is a hypertext version of the FreeBSD kernel source. This is brought to you courtesy of Warren Toomey.

Daemon News

The industry leader in BSD news.

The FreeBSD 'zine

A monthly collection of easy to read (we hope) articles written by FreeBSD users and administrators just like you.

Like FreeBSD itself, this documentation is the product of a volunteer effort. The goals of the project are outlined here, as are the procedures for submitting corrections and new material.

The FreeBSD Diary

The FreeBSD Diary is a collection of how-to entries aimed at UNIX novices. The aim is to provide a set of step-by-step guides to installing and configuring various ports.

&footer; diff --git a/en/internet.sgml b/en/internet.sgml index dcb30b261c..1206f6aa32 100644 --- a/en/internet.sgml +++ b/en/internet.sgml @@ -1,160 +1,160 @@ + %includes; ]> - + &header;

FreeBSD was designed for the Internet

FreeBSD includes what many consider the reference implementation for TCP/IP software, the 4.4 BSD TCP/IP protocol stack, thereby making it ideal for network applications and the Internet.

FreeBSD supports standard TCP/IP protocols.

Like most UNIX systems, the FreeBSD operating system enables you to

  • Share filesystems with NFS
  • Distribute network information with NIS
  • Support remote logins
  • Do remote SNMP configuration and management
  • Serve files with FTP
  • Resolve Internet hostnames with DNS/BIND
  • Route packets between multiple interfaces, including PPP and SLIP lines
  • Use IP Multicast services (the MBONE)

FreeBSD lets you to turn a PC into a World Wide Web server or Usenet news relay with included software. Using the included SAMBA software you can even share filesystems or printers with your Win95 and NT machines and, with the supplied PCNFS authentication daemon, you can support machines running PC/NFS. FreeBSD also supports Appletalk and Novell client/server networking (using an optional commercial package), making it a true "Intranet" networking solution.

FreeBSD also handles TCP extensions like the RFC-1323 high performance extension and RFC-1644 extension for transactions, plus SLIP and dial-on-demand PPP. It is an operating system suitable for a home-based net surfer as well as a corporate systems administrator.

FreeBSD's networking is stable and fast.

If you need an Internet server platform that is reliable and offers the best performance under heavy load, then consider FreeBSD. Here are just a few of the companies that make use of FreeBSD every day:

  • BSDi's Open Source Division outside of San Francisco runs one of the most popular FTP servers on the net - ftp.freesoftware.com. It is a FreeBSD machine supporting 5000 connections, and is capable of transferring more than 30 terabytes (as of June, 1999; yes that is terabytes!) worth of files every month to more than 10 million people. The configuration details are available to those interested in building - similiar systems.
    • + similar systems.
  • Yahoo Inc. runs the ultimate index of the Internet, serving scads of daily net surfers with information about the World Wide Web. Yahoo, as well the companies that advertise on Yahoo, rely on FreeBSD to run reliable and responsive web servers.
  • If that is not enough, visit our Gallery of satisfied FreeBSD users.

FreeBSD makes an ideal platform for these and other Internet services:

  • Company-wide or world-wide WWW service
  • Proxy WWW service
  • Anonymous FTP service
  • Enterprise file and print services

The FreeBSD ports collection contains ready-to-run software that makes it easy to set up your own Internet server.

High performance and security.

The FreeBSD developers are as concerned about security as they are about performance. FreeBSD includes kernel support for IP firewalling, as well other services, such as IP proxy gateways. If you put your corporate servers on the Internet, any 386 PC (or better) running FreeBSD can act as a network firewall to protect them from outside attack.

Encryption software, secure shells, Kerberos, end-to-end encryption and secure RPC facilities are also available (subject to export restrictions).

Furthermore, the FreeBSD team is proactive in detecting and disseminating security information and bug reports with a security officer and ties to the Computer Emergency Response Team (CERT).

What experts have to say . . .

``FreeBSD ... provides what is probably the most robust and capable TCP/IP stack in existence ...''

---Michael O'Brien, SunExpert August 1996 volume 7 number 8.

&footer; diff --git a/en/java/dists/12.sgml b/en/java/dists/12.sgml index 4ef0f544b7..62ebcc267a 100644 --- a/en/java/dists/12.sgml +++ b/en/java/dists/12.sgml @@ -1,74 +1,74 @@ - + %includes; ]> &header;

October 14, 2000: Greg Lewis' native FreeBSD JDK 1.2.2 is now in beta test stage and is now available in the ports directory (ports/java/jdk12-beta).
While this is only for i386 architecture at the moment, this will allow anyone running the i386 (most of you) the opportunity to build a native JDK2, and then test them out against your favorite apps and custom code. If you use something -regularly, why not make a port of it? Instructions are availible at Porters Handbook. +regularly, why not make a port of it? Instructions are available at Porters Handbook.

If you want to try to build it by hand, due to SCSL concerns, you now have to go to http://www.eyesbeyond.com/freebsddom/java/jdk.html and agree to the SCSL before downloading. There is a mirror at http://java2.freebsd.methodsystems.com/java/jdk.html

Note: This port will take a lot of hard drive space to build (around 250 MB).

May 3, 2000: Greg Lewis has just announced that the native FreeBSD JDK 1.2.2 port has entered alpha test stage.
In its current form, the port will build and run on most FreeBSD releases (3.4, 4.0 and 5.0 on x86) and work is being done on the others (2.2.8 on x86 and 4.0 alpha). Most demo applets and applications run.
Currently we are looking for enthusiasts who are willing to spend a little time testing the new port. While this is not a trivial task, there are clear step-by-step insturctions on how to build and use the port.
The patches may be found, as usual on:
http://www.eyesbeyond.com/freebsddom/java/jdk.html
More information, open issues and step-by-step instructions may be found at:
http://www.kjkoster.org/java/index.html

March 22, 2000: Greg Lewis releases the pre-alpha patches for enterprising Java users to build their own native FreeBSD JDK 1.2.2 from. This process is not for the faint of heart, and the resulting JDK is not for production systems. Having said that, most AWT and Swing demo's have been found to run. There is plenty of work to do, and we need all the testers we can find. Patches and build instructions may be downloaded from http://www.eyesbeyond.com/freebsddom/java/jdk.html Current issues and test results may be found at http://www.kjkoster.org/java/index.html.

January 30, 2000: The Linux Blackdown Port Team has released RC4 of JDK 1.2 . It has been tested on FreeBSD 3.4-STABLE and later and runs all demo applets and jfc demos. Several people have mentioned some problems running it with Apache JServ. Until it can be added to the FreeBSD port tree, it can be found at http://www.jmcm.org/tech/ports/linux_jdk.html. (Reported by Jose Marques)

October 11, 1999: Work has re-started on the Java2/JDK1.2 port. Expect an early 'alpha' release in the coming weeks for FreeBSD 3.3-stable/ELF boxes.

For most JDK2 development issues, you can use the JDK1 release and the Swing releases provided by Sun for JDK1, which works very well under FreeBSD.

&footer; diff --git a/en/java/dists/13.sgml b/en/java/dists/13.sgml index 3a6921a023..31d5e694b2 100644 --- a/en/java/dists/13.sgml +++ b/en/java/dists/13.sgml @@ -1,148 +1,148 @@ - + %includes; ]> &header;

September 15, 2000: Andrew Gallatin and Sean O'Connell have been working on getting IBM's JDK 1.3 working. To make them work on your system, you will have to patch some of your FreeBSD sources. They have provided patches based on your version:
4.0-RELEASE
4.0-STABLE
-CURRENT (pre-SMPng)

To quote Drew's message: 

 I've finally gotten the IBM jdk 1.3 working. I haven't tested it very
 heavily    AWT stuff seems to finally work though.
 
 Here's an updated patchset to a pre-SMPng -current. The patchset
 does the following:
 
 - changes MINSIGSTKSZ from 8192  to 2048
 - implements linux_rt_sendsig() & linux_rt_sigreturn()
 - implements userland sigtramp code for linux_rt_sigreturn()
 - implements linux_to_bsd_sigaltstack & bsd_to_linux_sigaltstack() to
         fix a bug in linux_sigaltstack & to avoid lots of cut-n-paste in
         linux_rt_sigreturn().  This also fixes the "Java HotSpot(TM)
         Client VM warning: cannot uninstall alt signal stack" one sees with
         Sun's 1.3 JDK.
 - changes the MAP_STACK flag to MAP_ANON for  LINUX_MAP_GROWSDOWN
         mmaps.  This was the final step in getting it working.  Any VM gurus
-        out there want to talk about this one?  There's aparently
+        out there want to talk about this one?  There's apparently
         something wrong with autogrowing linux thread stacks[*]
 
 Patches at: http://www.cs.duke.edu/~gallatin/linux_sa_siginfo/diff
 
 [*]The "problem" is the heuristic used by vm_map_growstack() to
 determine whether the stack part of the main process stack.  We
 currently use:
 
         is_procstack = addr >= (vm_offset_t)vm->vm_maxsaddr;
 
 where vm->vm_maxsaddr comes from exec_new_vmspace():
         vmspace->vm_maxsaddr = (char *)USRSTACK - MAXSSIZ; 
 
 The IBM JDK's main thread reduces it's stack size to rlim_cur=2040*1024.
 It then creates stacks for its threads at addresses which are greater
 than vm_maxsaddr but less than the current bottom of the main process
 stack as defined by p->p_rlimit[RLIMIT_STACK].rlim_cur. The first time
 a thread accesses something requiring this region to grow, it goes
 down in flames.

And Sean's email: 

 I did a Quick&Dirty MFC of Andrew Gallatin's work on getting the 
 IBM Java SDK to work.  I was able to run the appletviewer on one
 of the demos and it worked.  I cannot say much more than that.
 
 The patches are all relative to /usr/src (or / since they are
 all in sys )
 
 The majority of the patches are for files in /sys/i386/linux.
 You should be able to apply the patch; cd to /sys/modules/linux;
 type make; kldunload linux; type make install; and kldload linux
 
-There is an additonal change which sets the MINSIGSTKSZ to 2048
+There is an additional change which sets the MINSIGSTKSZ to 2048
 in sys/sys/signal.h .. this will require a kernel rebuild to
 take effect.

July 18, 2000: Ernst de Haan has done some work getting Sun's Linux JDK 1.3.0b9 to run on 4.0-STABLE. The .java_wrapper file can be found here. (Don't forget to rename it to .java_wrapper)

Ernst's email: 

 Just one more hint: Change the jre/lib/jvm.cfg and put the last line on
 top. So you will get:
 
    -classic
    -hotspot
    -server
 
 I _do_ get one warning, BTW, when running the Swing app:
 
    Warning: Cannot convert string "MetaCtrl<Key>Insert" to type VirtualBinding 
 
 Ernst
 
 
 Ernst de Haan wrote:
 > Hi folkz,
 > 
 > I have the Sun JDK 1.3.0 for Linux, beta 9 running on my FreeBSD
 > 4.0-STABLE system. Runs pretty nicely too.
 > 
 > java -version reports:
 > 
 >    bash-2.04$ java -version
 >    expr: syntax error
 >    java version "1.3.0beta_refresh"
 >    Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0beta_refresh-b09)
 >    Classic VM (build 1.3.0beta_refresh-b09, green threads, nojit)
 > 
 > The first line with the syntax error is a small problem with
 > .java_wrapper, but it seems harmless. I had to make some modifications
 > to the .java_wrapper script to make it work on my system. I've attached
 > the version I use.
 > 
 > I haven't done much testing yet, but I have tried a single Swing
 > application. I did notice some differences in fonts, but it all seems to
 > work pretty nice and fast :)
 > 
 > Wow, soon FreeBSD will be the platform with the greatest number of
 > working JDKs on it, once we get WINE to work so we can run the Windows
 > JDKs too, and write an AS/400 emulator, and... and... ;-)
 > 
 > Ernst
 > 
 > P.S.  Thanks go to Victor Salaman how pointed me in the right direction.
 >       He has been running the Sun JDK 1.3 for Linux for quite a while.

January 29, 2000: Work has not begun on the JDK 1.3 port. It will not be until after our JDK 1.2 release is done that we will begin on JDK 1.3.

&footer; diff --git a/en/java/dists/index.sgml b/en/java/dists/index.sgml index 1d6c8940f6..f9333c57e6 100644 --- a/en/java/dists/index.sgml +++ b/en/java/dists/index.sgml @@ -1,42 +1,42 @@ - + %includes; ]> &header;
-This is the offical port of Sun's Java Development Kit for FreeBSD. No known significant bugs exist at this time, but there are no guarantees of usability. However, many commercial companies rely on this port, so it should be safe to use. +This is the official port of Sun's Java Development Kit for FreeBSD. No known significant bugs exist at this time, but there are no guarantees of usability. However, many commercial companies rely on this port, so it should be safe to use. Jump to Java

Supported

JDK 1.1.x

We currently have support for 2.2.x, 3.x and 4-CURRENT FreeBSD Systems for JDK 1.1.8. Included is support for both X and non-X systems as two separate binaries.

JDK 1.2.x

JDK2 (aka 1.2) support is forthcoming.

JDK 1.3.x

JDK 1.3 support is forthcoming (after JDK 1.2).

Unsupported

JDK 1.0.x

-

There is an old port of JDK 1.0.2 availible. It is a.out, and will run on older FreeBSD systems (2.1.x and 2.2.x). This port is not supported +

There is an old port of JDK 1.0.2 available. It is a.out, and will run on older FreeBSD systems (2.1.x and 2.2.x). This port is not supported

Anything prior to FreeBSD 2.2 (such as FreeBSD 2.1.7.1) is not supported in either JDK 1.1.8 or JDK 1.2.

&footer; diff --git a/en/java/links/development.sgml b/en/java/links/development.sgml index 193f524bb0..6c3c29c1ff 100644 --- a/en/java/links/development.sgml +++ b/en/java/links/development.sgml @@ -1,77 +1,77 @@ - + %includes; ]> &header;

Included below are links to some tools that can be used on FreeBSD. It is not intended to be a comprehensive list.

  • IDE´S
    • Visual Age for Java - Professional
      Joachim Jaeckel has put together a page on how to run Visual Age for Java Professional 3.0 (Linux) under -CURRENT: http://www.coffeebreak.de/freebsd/
    • JDE
      (X)Emacs mode for editing Java
    • visaj
      A commercial visual application builder for Java.
    • jEdit
      jEdit is a programmer's text editor written in Java with Swing and allows for plug-ins. The author is also working on jEdit-IDE.
    • NetBeans
      New IDE written completely in java, different versions available, free and commercial ones. Now part Sun Microsystems.
    • JWS - Sun´s IDE
      Will not longer be maintained since Sun acquired NetBeans to use it as their IDE from now on.
    • FreeBuilder
      Open Source IDE, nice start but seems to be slowing down in progress lately, but don´t trust all the infos on the webpages, just check out the newest CVS-sources.
    • Lemur
      An IDE that is written in Java and uses Swing.
    • ElixirIDE
      An IDE that includes a debugger. Rated a JARS top 5%.
  • JDBC
    • Sun's list of JDBC Drivers
    • Town
      A 100% Pure Java API that works in conjunction with JDBC.
    • tjFM
      A Type 4 JDBC driver for MySQL.
    • GWE
      A Type 4 JDBC driver for MySQL.
    • mm.mysql
      A Type 4 JDBC driver for MySQL.
  • UML
    • Tendril Software Structure Builder
      UML development software written in Java - commercial version and demo versions available.
      Plugin for NetBeans available.
    • TogetherJ
      UML based development environment, written in Java. Different editions available, even a free one.
  • Tools
    • Jikes
      Ultra fast java compiler from IBM (available as port)
    • Guavac
      - Guavac is a free java compiler developed under GNU Public Licence, + Guavac is a free java compiler developed under GNU Public License, and its package includes guavad, java bytecode decompiler.
&footer; diff --git a/en/java/links/resources.sgml b/en/java/links/resources.sgml index 4965c2ef62..3ea6d79152 100644 --- a/en/java/links/resources.sgml +++ b/en/java/links/resources.sgml @@ -1,44 +1,44 @@ - + %includes; ]> &header;
  • Java Directory at Gamelan
    Collection of java applets, programs, tools and libraries...
  • Java World
    The Java Magazine
  • Giant Java Tree (GJT)
    Open Source Java organized in a CVS tree.
  • JOS
    Free Java Operating System (still under development but already some nice things available)
  • Javalobby
    Organization to support Java (fight for Java), sometimes nice offers
    of commercial software for free (if you are member of Javalobby)
    • JFA
      The Javalobby Application Framework, collection of different java programs.
      Also available via GJT.
  • ICE
    Offering webspace for some nice Java projects, e.g. JCVS
  • JCentral
    Search engine only for java things (searches
    - newsgroups, sourcecode archives, ... Provided by IBM + newsgroups, source code archives, ... Provided by IBM
  • Java at the Apache Group
    Different projects concerning java and web, e.g. JServ, Cocoon, etc.
&footer; diff --git a/en/java/links/servlets.sgml b/en/java/links/servlets.sgml index a363a57952..4bb6ff4317 100644 --- a/en/java/links/servlets.sgml +++ b/en/java/links/servlets.sgml @@ -1,49 +1,49 @@ - + %includes; ]> &header;

Servlets are a Java API that can be used to replace Perl CGI scripts, or more specifically, to extend the capabilities of the web server.

Servlets can also be used with XML and XSL.

  • API
  • Servlet Information
  • Servlet Engines
    • Java Web Server
      This was the reference implementation of the servlet engine implemented in Java. Sun has turned over the source code to the Apache Project and is now implemented as Tomcat.
    • Tomcat (Jakarta Project)
      - The reference implementation of Java Servlets and Java Server Pages. The code is not yet availible aside from a nightly standalone build. + The reference implementation of Java Servlets and Java Server Pages. The code is not yet available aside from a nightly standalone build.
    • Apache JServ
      A 100% Pure Java implementation of the Servlet 2.0 API specification. Works with Apache.
    • ServletExec
      A high-performance commercial servlet engine. Offers a free demo/development copy and a servlet debugger. Works with most web servers.
    • JRun
      A high-performance commercial servlet engine. Offers a free demo/development copy. JavaWorld's Best Servlet Tool for 1998 and WebTechnique's Best Java Tool for 1998. Recently acquired by Allaire. Works with most web servers.
&footer; diff --git a/en/java/newsflash.sgml b/en/java/newsflash.sgml index 1b71bb87a5..fc026df04a 100644 --- a/en/java/newsflash.sgml +++ b/en/java/newsflash.sgml @@ -1,388 +1,388 @@ - + %includes; ]> &header;

October, 2000

  • October 14, 2000:
    Maxim Sobolev has produced a port of the JDK 1.2.2 software. It can now be built from the ports directory ports/java/jdk12-beta. See JDK 1.2.x for more details.

    All the issues noted below are still in place, however.

    So anyone who has a Java2 port you've been waiting on submitting, now is your chance.

September, 2000

  • September 15, 2000: From the Java news desk:
    Sean O'Connell and Andrew Gallatin have created patches to enable FreeBSD to run IBM's JDK 1.3.
    Ernst de Haan has been able to get Sun's Linux JDK 1.3.0b9 running on 4.0-STABLE.

    Full details on both can be found here.

August, 2000

  • August 10, 2000: On August 7th, 2000, the FreeBSD JDK team -was given access to Sun's JCK (Java Compatability Kit), +was given access to Sun's JCK (Java Compatibility Kit), which will allow us to test and (hopefully!) release a binary version using the current set of patches. Unfortunately, we are unable (for legal reasons) to distribute a JDK that hasn't been run against the JCK like we were able to with the JDK1.1.* releases.

    Unfortunately, as told by Sun (we have no experience *yet*), running the JCK against the port is a difficult and time-consuming process. Hopefully it won't take us the 3 months that Sun expects it to take. :(

    Finally, there are still some issues regarding Motif that need to be resolved before a full public release can be made. Sun is working on that front, and we need to try contacting the OpenGroup to see if we can get a special exception for Motif binary distributions to use in the JDK release.

May, 2000

  • May 3, 2000: Native JDK 1.2.2 port enters alpha test phase
    Greg Lewis has just announced that the native FreeBSD JDK 1.2.2 port has entered alpha test stage.
    In its current form, the port will build and run on most FreeBSD releases (3.4, 4.0 and 5.0 on x86) and work is being done on the others (2.2.8 on x86 and 4.0 alpha). Most demo applets and applications run.
    Currently we are looking for enthusiasts who are willing to spend a little time testing the new port. While this is not a trivial task, there are clear step-by-step insturctions on how to build and use the port.
    The patches may be found, as usual on:
    http://www.eyesbeyond.com/freebsddom/java/jdk.html
    More information, open issues and step-by-step instructions may be found at:
    http://www.kjkoster.org/java/index.html
  • May 1, 2000: Request for Enhancement - Now the number 1 RFE
    We have petitioned Sun to provide an official FreeBSD JDK2 port. We are currently in 1st place in the vote count. If you are a member of the Java Developer's Connection (it's free), you can vote for it as well http://developer.java.sun.com/developer/bugParade/bugs/4288745.html

March, 2000

    -
  • March 22, 2000: Pre-Alpha JDK 1.2.2 patches availible. +
  • March 22, 2000: Pre-Alpha JDK 1.2.2 patches available.
    Greg Lewis releases the pre-alpha patches for enterprising Java users to build their own native FreeBSD JDK 1.2.2 from. This process is not for the faint of heart, and the resulting JDK is not for production systems. Having said that, most AWT and Swing demo's have been found to run. There is plenty of work to do, and we need all the testers we can find. Patches and build instructions may be downloaded from http://www.eyesbeyond.com/freebsd-jdk122-patches-latest.tar.gz. Currently open issues and test results may be found at http://www.kjkoster.org/java/index.html.

January, 2000

  • January 30, 2000: Blackdown 1.2.2RC4 JDK
    The Linux Blackdown Port Team has released RC4 of JDK 1.2. It has been tested on FreeBSD 3.4-STABLE and later and runs all demo applets and jfc demos. Several people have mentioned some problems running it with Apache JServ. Until it can be added to the FreeBSD port tree, it can be found at http://www.jmcm.org/tech/ports/linux_jdk.html. (Reported by Jose Marques)

November, 1999

  • November 28, 1999:Request for Enhancement
    We have petitioned Sun to provide an official FreeBSD JDK2 port. We are currently in 2nd place in the vote count. If you are a member of the Java Developer's Connection (it's free), you can vote for it as well http://developer.java.sun.com/developer/bugParade/bugs/4288745.html
  • November 9, 1999:Another JDK1.1.8 release to fix a separate class of multicast bugs.

October, 1999

  • October 11, 1999: Work has re-started on the Java2/JDK1.2 port. Expect an early 'alpha' release in the coming weeks for FreeBSD 3.3-stable/ELF boxes.

September, 1999

  • September 22, 1999: Re-rolled the JDK1.1.8 yet again to fixup some minor bugs that people have found, as well as to speedup the JDK. For details checkout the README.FreeBSD supplied in the releases.
    • jdk1.1.8_AOUT.V99-9-22.tar.gz. For FreeBSD versions 2.2.*, which use the A.OUT binary format.
    • jdk1.1.8_ELF.V99-9-22.tar.gz. For FreeBSD versions 3.* and 4.* which use the ELF binary format.

July, 1999

  • July 19, 1999: Re-rolled the JDK1.1.8 release to fix a couple of minor (but annoying bugs). First, the netpatch (see below) was incorporated into the build, and second an annoying Floating Point bug was found and fixed. The latter bug affected multi-threaded code that did floating point calculations and based on the code could produce completely bogus results.
    • jdk1.1.8_AOUT.V99-7-19.tar.gz. For FreeBSD versions 2.2.*, which use the A.OUT binary format.
    • jdk1.1.8_ELF.V99-7-19.tar.gz. For FreeBSD versions 3.* and 4.* which use the ELF binary format.
    -
  • July 2, 1999: Organization of FreeBSD 'CommAPI' porting team wich +
  • July 2, 1999: Organization of FreeBSD 'CommAPI' porting team which is an effort to make JAVA's CommAPI freely available to the FreeBSD community. Project is coordinated by DRICOT Jean-Michel and -will officialy be maintained in +will officially be maintained in http://student.ulb.ac.be/~jdricot/commapi/. Feel free to contact him if you want to join the project.

June, 1999

  • June 8, 1999: A small bug was found in the JDK1.1.8 release which affected people using UDP sockets. If you tried to send a packet to the broadcast address, the FreeBSD JDK refused with a permissions error. This error was fixed, and rather than re-releasing the entire release a small patchset was re-rolled for those folks who are experiencing this problem. If you experience this problem, feel free to download the gzipped tarfile and untar it wherever you installed the jdk. It will install itself over top of the old version. If you aren't experiencing the bug, there is no need to apply the patch, although it wouldn't hurt.
  • June 3, 1999: JDK1.1.8 for A.OUT and ELF releases. This release adds support for older 3.*/ELF releases (without requiring any runtime loader changes), as well as fixes bugs in LOCALE and timezone support for all FreeBSD releases.
    • jdk1.1.8_AOUT.V99-6-3.tar.gz. For FreeBSD versions 2.2.*, which use the A.OUT binary format.
    • jdk1.1.8_ELF.V99-6-3.tar.gz. For FreeBSD versions 3.* and 4.* which use the ELF binary format.
  • June 1, 1999: JDK2 status
    • Work on JDK1.2/JDK2 has been going very slow as the development team has been focusing it's effort on solid JDK1 releases. For most JDK2 development issues, you can use the JDK1 release and the Swing releases provided by Sun for JDK1, which works very well under FreeBSD.

April, 1999

  • Apr. 16, 1999: New JDK1.1.7 A.OUT release. This fixes build problems in the March release. A new ELF release will be made to support older 3.0 releases as well sometime in the near future.
    • jdk1.1.7_AOUT.V99-4-16.tar.gz. For FreeBSD versions 2.2.*, which use the A.OUT binary format.

March, 1999

  • Mar. 26, 1999: ELF support for JDK1.1.7, as well as a new A.OUT release which includes minor bugfixes.
    • jdk1.1.7_AOUT.V99-3-24.tar.gz. For FreeBSD versions 2.2.*, which use the A.OUT binary format.
    • jdk1.1.7_ELF.V99-3-25.tar.gz. For FreeBSD versions 3.x and 4 which use the ELF binary format. Note: This requires changes made to the runtime loader to support dladdr() functionality made on 1999/3/24. You will need to be running 3.1-stable or 4.0-current dated later than 1999/3/24. If you don't have the new loader binary or are not tracking -stable or -current, you can download it from here and install it as /usr/libexec/ld-elf.so.1 (you need to be root to do this): 
      # install -c -s -o bin -g bin -m 555 -C -fschg ld-elf.so.1 /usr/libexec
  • Mar. 16, 1999: Updates on current development:
    • ELF JDK1.1.7 : An ELF build of JDK1.1.7 (for use on FreeBSD 3.x and later) is currently entering it's initial internal testing phase. A beta -release should be availible in a few weeks. +release should be available in a few weeks.
    • JDK2 (aka JDK1.2): Several individuals are working on porting JDK2 to FreeBSD, but the work is progressing slowly. This is primarily due to a lack of developer time to work on this project. (The release of Blackdown's JDK2 port will assist our development when they release their source diffs.)

December, 1998

  • Dec. 21, 1998: jdk1.1.7.V98-12-21.tar.gz.
    • Bugfix version of JDK1.1.7. Thanks go to Keith White who tracked down a couple annoying (and serious) bugs in the JDK, notably the modulo bug. This release also has the 256 file-descriptor limit bumped up to 2048. The JRE should also be much more usable, again thanks to Keith.

November, 1998

  • Nov. 14, 1998: jdk1.1.7.V98-11-5.tar.gz.
    • Updated to JDK1.1.7. Thanks go to Patrick Gardella patrick@cre8tivegroup.com who provided most of the testing for this release.

September, 1998

  • Sept 23, 1998: jdk1.1.6.V98-9-23.tar.gz.
    • The August 14 build had jre incorrectly linked in both the JDK and the JRE, so a new release was rebuilt with the correct linkage. Otherwise, there were no changes from the older release.

August, 1998

  • Aug 22, 1998:
    • Updated page to list numerous sites who have agreed to mirror the JDK and provide ftp access. Thanks to all!
  • Aug 14, 1998: jdk1.1.6.V98-8-14.tar.gz.
    • The SO_REUSEADDR option is now correctly set on ServerSockets (may affect other sockets as well.)

July, 1998

  • July 21, 1998: jdk1.1.6.V98-7-21.tar.gz.
    • Updated port to JDK1.1.6. Thanks go to Keith White kwhite@site.uottawa.ca who did most of the work to make this release happen!
    • More standard 'naming' for java.version and such.
    • Fixes for UDP/Multicast sockets.
    • The signal abort error may be fixed (knock on wood).
    • Add support for the "KOI8-R" and "CP866" encodings.
    • Timezone's now work correctly under FreeBSD (this required some native code, but it is embedded in the JDK so shouldn't affect users. However, FreeBSD has one of the few (only?) VM's that correctly support Timezones now).
    • sysRmdir() now correctly removes directories.
    • Link in the xpg4 library to support CJK locales.

May, 1998

  • May 5, 1998:
    • Updated page to include instruction on how to get Sun's JWS (Java Work Shop) working under FreeBSD.

February, 1998

  • February 25, 1998: jdk1.1.5.V98-2-25.tar.gz.
    • JDK's built on 2.2.2 should now work again.
    • The AWT now correctly sets the Window name.
    • Fixed obscure bug that could cause a core dump if you hit a button in a dialog box multiple times.
    • Fixed bug where SHMEM wasn't released when using images, causing a leak.
    February 12, 1998:
    • Johan Larsson graciously provided an ftp mirror site for the JDK, so if you have an aversion to using HTTP, then feel free to grab it from his site.
    • Replaced the 'Steaming Cup of Java' logo with the 'Jump to Java' logo, which is more politically (and legally) acceptable to SUN's lawyers.
    February 9, 1998: jdk1.1.5.V98-2-8.tar.gz.
    • Fixed bugs in Process.waitFor()
    • Modified the way the Motif library was linked in. This will allow anyone with a Motif library (static or dynamic) to build their own JDK once the patchkit is released. If their Motif license allows for it, they can also make binary releases available.
    • Non blocking reads on PIPE did not work reliably on all versions of the OS.
    • Multicast now works.

January, 1998

  • January, 1998:
    • Organization of FreeBSD 'JDK' porting team, which now jointly creates new JDK releases for FreeBSD.
    • New JDK1.1.5 binary, which has Motif statically compiled in. (Unfortunately, this release was lost in a disk crash on the ftp server.)
&footer; diff --git a/en/platforms/ia64.sgml b/en/platforms/ia64.sgml index 7cc5ed5413..c000bfd658 100644 --- a/en/platforms/ia64.sgml +++ b/en/platforms/ia64.sgml @@ -1,72 +1,72 @@ - + %includes; ]> - + &header;

This page contains information about porting FreeBSD to Intel's upcoming IA64 architecture.

Latest News

  • 5-Nov-2000 Marcel Moolenaar has written a web page describing the Simulator System Calls.

  • 4-Oct-2000 Doug -Rabson has commited code to get FreeBSD as far as start_init() +Rabson has committed code to get FreeBSD as far as start_init() before it dies in the simulator.

  • 30-Sep-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 mailing list for more information.

What needs to be done

A lot of work needs to be done on the Cygnus IA64 toolchain. At the moment it looks like the various Linux camps doing IA64 development have splintered off without merging their respective changes back into Cygnus' tree. Anyone working on toolchain issues should coordinate with David Obrien.

HP's Linux IA64 simulator is currently less than ideal for FreeBSD development. Marcel Moolenaar is currently working on some of these issues.

FreeBSD/IA64 Specific Links

Other Links of Interest

IA64 Documentation

Software Tools

Related Projects

&footer; diff --git a/en/platforms/index.sgml b/en/platforms/index.sgml index 2ad8c83633..33924c59bb 100644 --- a/en/platforms/index.sgml +++ b/en/platforms/index.sgml @@ -1,54 +1,54 @@ - + %includes;]> &header;

Introduction

Here you will find a list of platforms that FreeBSD currently supports along with platforms currently being ported to (with the exception of x86, since most of the information on the remainder of the site already pertains to that platform).

Table of Contents

Comments and Feedback

If you have comments about a port, or wish to provide feedback to the developers, send it the relevant mailing list. The lists are:

&footer; diff --git a/en/platforms/x86-64.sgml b/en/platforms/x86-64.sgml index fb589d7466..d153d6059f 100644 --- a/en/platforms/x86-64.sgml +++ b/en/platforms/x86-64.sgml @@ -1,63 +1,63 @@ - + %includes; ]> - + &header; BSD Daemon swinging a sledge hammer

This page contains information about porting FreeBSD to AMD's upcoming x86-64 ``Hammer'' architecture.

Latest News

  • 13-April-2001 David O'Brien received the commercial Virtutech Simics-LE "VirtuHammer" x86-64 simulator in order to begin the port.

What needs to be done

-

David O'Brien is working on modifing the AMD sponsored x86-64 GCC for +

David O'Brien is working on modifying the AMD sponsored x86-64 GCC for FreeBSD's needs. Anyone working on toolchain issues should coordinate with David O'Brien.

AMD's SimNow! x86-64 simulator is currently less than ideal for FreeBSD development due to its slowness.

FreeBSD/x86-64 Specific Links

Other Links of Interest

x86-64 Documentation

Software Tools

Related Projects

&footer; diff --git a/en/projects/mozilla.sgml b/en/projects/mozilla.sgml index 405c8321a7..a2c249c6d6 100644 --- a/en/projects/mozilla.sgml +++ b/en/projects/mozilla.sgml @@ -1,89 +1,89 @@ - + %includes; ]> - + &header;

Overview

Following Netscape's - decision to publically release the source code for their client + decision to publicly release the source code for their client product, otherwise known as Mozilla, a number of free software groups have become actively involved in supporting and improving this technology for their own uses. The FreeBSD Mozilla Group seeks to provide a focus for such work in the FreeBSD world, providing centralized resources such as a CVS repository, a mailing list and other tools for collaborative development.

Resources

CVSup
-
CVSup provides ongoing syncronization with the central Mozilla +
CVSup provides ongoing synchronization with the central Mozilla repository, either for the CVS bits themselves (for those wishing to keep a local repository) or for a "checked out" version, suitable for directly building or editing. Fetch the CVSup binaries from ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/ and use a supfile which looks something like this: 
 *default prefix=/usr/src/mozilla base=/usr/src/mozilla host=mozilla.FreeBSD.org release=cvs delete compress use-rel-suffix tag=.
 
 ## Main Source Tree
 cvs-mozilla
anoncvs
Anonymous CVS allows anyone to check things out of the FreeBSD Mozilla repository using the standard cvs(1) commands. Simply set your CVSROOT environment variable to point to: 
       anoncvs@mozilla.FreeBSD.org:/mozilla

And you can then use cvs(1) for doing read-only operations on the Mozilla CVS repository.

freebsd-mozilla
The FreeBSD-mozilla mailing list is provided for developers and users of the FreeBSD mozilla port to discuss issues relating to building, using and managing the mozilla sources and any FreeBSD-specific changes to them. To subscribe, send mail to majordomo@FreeBSD.org and say subscribe freebsd-mozilla in the body of your message.

More information

Mozilla.ORG
The Mozilla.org project provides central control over Mozilla for all platforms, not just FreeBSD.
Cyclic Software
Cyclic Software has some good on-line tutorials on CVS
&footer; diff --git a/en/projects/projects.sgml b/en/projects/projects.sgml index 35e91e15cf..00b4c05b9e 100644 --- a/en/projects/projects.sgml +++ b/en/projects/projects.sgml @@ -1,567 +1,567 @@ - + %includes; ]> &header;

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. Follow the links below to learn more about these exciting projects.

If you miss a project please send the URL and a short description (3-10 lines) to www@FreeBSD.ORG

Documentation

  • FreeBSD Documentation Project The FreeBSD Documentation Project is a group of people who maintain and write the documentation (such as the Handbook and FAQ) for the FreeBSD project. If you want to help with the documentation project, subscribe to the freebsd-doc@FreeBSD.ORG -mailing list and partcipate.
    • +mailing list and participate.
  • FreeBSD Resources for Newbies is a list of resources to help those new to FreeBSD and UNIX in general. There is also a freebsd-newbies@FreeBSD.ORG mailing list.
  • Retail Outlets for FreeBSD is a list of worldwide retailers where FreeBSD can be purchased.
  • FreeBSD Security How-To FreeBSD is a very secure operating system. Since source code is freely available, the OS is constantly going through the review and audit. While FreeBSD comes very secure OOB (Out-Of-Box), there are many features that can make it more secure for those of you who are "paranoid". This How-To will go over some steps which will help you increase overall security of your machine.
  • RELEASE/SNAP finder for FreeBSD FTP servers. A resource that would allow anyone to find a FTP server that contains particular releases and SNAP of FreeBSD. The database is updated daily at 3am Melbourne time (10 hours ahead of UTC).
  • The FreeBSD Diary is a collection of how-to entries aimed at UNIX novices. The aim is to provide a set of step-by-step guides to installing and configuring various ports.
  • A Comprehensive Guide to FreeBSD - an attempt at a more readable, "book-like" tutorial explaining the FreeBSD Operating System. Intended for people new to both FreeBSD and UNIX. Currently a work in progress.
  • FreeBSD How-To's for the Lazy and Hopeless is another somewhat more light-hearted attempt to provide more readable "how-to" style information on setting up and configuring FreeBSD.
  • The Linux+FreeBSD mini-HOWTO describes how to use Linux and FreeBSD on the same system. It introduces FreeBSD and discusses how the two operating systems can cooperate, e.g. by sharing swap space.
  • Install Preview for FreeBSD 2.2.7 This is a guide illustrating the FreeBSD install program for those new to unix and/or FreeBSD.
  • The FreeBSD Programmer's Documentation Project
  • The FreeBSD Cook Book Ok, you got FreeBSD installed, now what? Here are some suggested solutions to common problems you can implement with the knowledge you now have. This document is styled after the electronics cook books with some recipes for some common types of installations. Each "recipe" has some recommended minimum hardware, specific software to use, and most important the configuration information required to get the system running correctly.
  • The FreeBSD Corporate Networker's Guide This Web site serves as a supplement to The FreeBSD Corporate Networker's Guide, with the principal goal of enhancing its usefulness. While books like fictional novels can be used and enjoyed for hundreds of years after initial publication, technical manuals like the Networker's Guide are obsoleted in a few years by changes in the product they are written for.

Advocacy

  • The FreeBSD Advocacy Project The FreeBSD Advocacy Project is the group of people responsible for the promotion of FreeBSD. Our main goal is to develop a competent marketing image for the FreeBSD Project, and increase the overall user-base of FreeBSD.
  • FreeBSD vs. Linux: a bunch of comparisons between FreeBSD and -Linux, which is another publically-distributed free UNIX-like OS +Linux, which is another publicly-distributed free UNIX-like OS for PC's.
  • Daemon News is an electronic publication about the BSD operating system in general. It's aim is to be a resource for people in the FreeBSD, OpenBSD, and NetBSD communities.
  • The FreeBSD Counter Page page is the start of a project which will attempt to determine the world-wide installed base of FreeBSD users. The FreeBSD development community currently has only the vaguest idea as to how large our user base is, and this makes it all the more difficult to persuade hardware and software vendors to take it seriously.
  • 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.
  • The Free Software Bazaar is a market place designed to increase the amount of free software, to support free software developers, and to more accurately measure the demand for free software.
    • -
  • FreeBSD ezine +
  • FreeBSD 'zine The FreeBSD 'zine is a monthly collection of easy to read (we hope) articles written by FreeBSD users and administrators just like you.
  • The Open Directory Project's goal is to produce the most comprehensive directory of the web by relying on a vast army of volunteer editors.
  • FreeBSD vs. Linux vs. Windows NT A comparison between the three operating systems which includes reliability, performance, Y2K issues, support, cost of ownership, and more.
  • The Internet Operating System Counter is a survey about operating system usage on the Internet. Host addresses are collected and queried for their operating system using queso.
  • The BSD cellphone. FreeBSD daemon covers for cellphones.
  • BSDCon 2000, the second annual BSD Conference and Expo.

Applications

  • Java on FreeBSD This contains information on where to obtain the latest JDK for FreeBSD, how to install and run it, and a list of java software that you may find interesting. Please note that the JDK is unsupported on versions of FreeBSD prior to 2.2.
  • FreeBSD Mozilla Group seeks to provide a focus for work on Netscape's Mozilla project for the FreeBSD world by providing centralized resources such as a CVS repository, a mailing list, and other tools for development.
  • MultiMedia A resource of links to information and software pertaining to the world of multimedia in the UNIX world.
  • FreeBSD Ports Collection The FreeBSD Ports Collection provides an easy way to compile and install a wide range of applications with a minimum amount of effort. A list of current ports is available along with a search mechanism to see if a specific application exists in the Ports Collection.
  • FreeBSD Ports distfiles survey is a list which checks the Ports Collection for unfetchable distfiles and provides a summary for each port.
  • FreshPorts provides the most up-to-date list of ports and port changes. Add your favourite ports to your watch list and receive email notification of any changes.

Networking

File system

  • Arla is a free AFS client implementation. The main goal is to make a fully functional client with all capabilities of normal AFS. Other planned and implemented things are all the normal management tools and a server.
  • Coda is a distributed file system. Among its features are disconnected operation, good security model, server replication and persistent client side caching.
  • crossFS Virtual File System is based on FreeBSD Virtual File System and provides a framework for porting UNIX based file systems to Windows NT systems.
  • cryptfs encrypts file names and data pages using Blowfish.
  • Elephant: The File System that Never Forgets
  • Journaling versus Soft Updates: Asynchronous Meta-data Protection in File Systems
  • Mode locking
  • Make the namei interface reflexive
  • NFS client and server locking
  • The Design and Implementation of a DCD Device Driver for Unix
  • NTFS Driver for FreeBSD This driver allows Windows NTFS partitions to be mounted by FreeBSD. Currently NTFS partitions can only be accessed in read-only mode, but plans are in the works for read/write access.
  • Rio (RAM I/O): The Rio project is investigating how to implement and use reliable memory. Reliable memory enables dramatic improvements in reliability and performance.
  • Soft Updates: A Solution to the Metadata Update Problem in File Systems
  • TCFS is a Transparent Cryptographic File System that is a suitable solution to the problem of privacy for distributed file system. By a deeper integration between the encryption service and the file system, -it results in a complete trasparency of use to the user +it results in a complete transparency of use to the user applications. Files are stored in encrypted form and are decrypted before they are read. The encryption/decryption process takes place on the client machine and thus the encryption/decryption key never travels on the network.
  • Tertiary Disk is a storage system architecture to create large disk storage systems that avoid the disadvantages of custom built disk arrays. The name comes from twin goals: to have the cost per megabyte and capacity of tape libraries and the performance of magnetic disks. We use commodity, off the shelf components to develop a scalable, low cost, terabyte capacity disk system. Our target is to build a complete storage system with about 30-50% extra to the cost of the raw disk. Tertiary Disk uses PCs connected by a switched network to host a large number of disks. Our prototype consists of 20 200MHz PC PCs, which host 370 8GB disks. The PCs are connected through a 100Mbps Ethernet switch.
  • Vinum is a logical volume manager modeled after the VERITAS volume manager. However, it is not a clone of Veritas, and attempts to solve a number of problems more elegantly than Veritas. It also offers features that Veritas does not have.
  • The PathConvert project is to develop utilities which make conversion between absolute path name and relative path name. It brings benefits mainly to the users of NFS and WWW.
  • V9FS: Memory-based file system for FreeBSD It will (we hope) become the basis of private name spaces for FreeBSD in the future. It provides a file system that uses only memory for directories, inodes, and data. This is not at all like mfs, since mfs uses memory for "disk blocks", and essentially acts as the device for UFS. V9FS in contrast is a first-class citizen and is a full mountable file system. No writeup yet.
  • WAFS is a simple file system designed to act as a logging service for kernel subsystems. Reads and writes are keyed by log-sequence number (LSN). All writes to WAFS are sequential. Kernel subsystems can use this LSN service to enforce write-ahead logging and guarantee consistency.

Kernel, security

  • Drawbridge is a firewall package that was developed at Texas A&M University and was designed with a large academic environment in mind. It's greatest strength is the ability to perform high speed packet filtering for -a larget number of individual hosts within an intranetwork.
    • +a larger number of individual hosts within an intranetwork.
  • Lottery Scheduling Kernel: This work is based on Waldspurger's lottery scheduling algorithm, which implements proportional-share resource management. The primary advantages are that users have strict control over the relative execution rates of their processes, and users are load-insulated from each other, preventing one user from dominating the CPU.
  • Metacomputing
  • DHCP configuration How to set up DHCP on FreeBSD systems for use with cable modems, etc.
  • Working LDAP for FreeBSD
  • Symmetric MultiProcessor Support Documentation and other information about taking advantage of multiple processors under FreeBSD.
  • A validation suite for testing for kernel memory leaks
  • SPY allows you to monitor and/or selectively block syscalls on your system. It could be used either as a safety monitoring device, policy enforcement, or debugging tool.
  • TrustedBSD provides a set of trusted operating system extensions to the FreeBSD operating system. This includes features such as fine-grained privileges (capabilities), Access Control Lists, and Mandatory Access Control.

Device drivers

  • BSD Driver Database Just because you don't have the time to write the driver yourself doesn't mean you can't still help. The idea behind the BSD Driver Database is to help individuals with hardware that needs supporting get in touch with driver developers with the knowledge to write the support for the hardware. This is a list of drivers currently under development that could stand to gain from time or resources you may have to offer.
  • A New Device Framework for FreeBSD
  • BSD ATM: implementation of ATM internetworking under 4.4BSD: New computer applications in areas such as multimedia, imaging, and distributed computing demand high levels of performance from computer networks. ATM-based networking solutions provide one possible alternative to meeting these performance needs. However, the complexity of ATM over traditional networks such as Ethernet has proven to be a barrier to its being used. In this paper we present the design and implementation of BSD ATM, a light-weight and efficient ATM software layer for BSD-based operating systems that requires minimal changes to the operating system. BSD ATM can be used both for IP-based networking traffic and for ``native'' ATM traffic.
  • The FreeBSD NVIDIA Driver Initiative - An initiative aiming for NVIDIA supported 3D drivers for FreeBSD. This is to be accomplished with help from the FreeBSD developer community as well as NVIDIA. Please visit the web page for regular news updates and to find out how you can help.
  • High-precision timekeeping with FreeBSD How to create a NTP stratum 1 server with state of the art performance.
  • Home Automation with FreeBSD such as appliance controllers, infra-red controllers, automated telephone systems, and more.
  • i4b: ISDN for FreeBSD ISDN4BSD (or i4b for short) is a package for interfacing a computer running FreeBSD, NetBSD, OpenBSD, or BSD/OS to ISDN. The only ISDN protocol currently supported is the BRI protocol. ISDN4BSD allows you to make IP network connections by using either IP packets sent in raw HDLC frames on the B channel, or by using sychronous PPP. For telephony, ISDN4BSD can answer incoming phone calls like an answering machine.
  • CAM: New SCSI layer for FreeBSD Details about what the new CAM SCSI layer is, and how it works.
  • The FreeBSD Token-Ring Project Information, files, patches, and documentation about adding Token Ring support to FreeBSD.
  • FreeBSD USB driver development The NetBSD USB stack has been ported to FreeBSD. Together with them we have started developing the drivers for many devices using the USB bus. Have a look on the webpage if you want to join the effort or you want to have a look on the devices that are being supported.
  • Soundblaster Awe64 configuration under FreeBSD 3.1
  • A mailing list exists for further development of Scott Mitchell's Xircom CEM ethernet driver. Send subscribe freebsd-xircom to majordomo@lovett.com to join.
  • Mike Smith's list of supported RAID cards and their respective information.

Architecture

  • Porting FreeBSD to Alpha systems Contains information on the FreeBSD Alpha port such as the status, mailing list information, the hardware used, and other Alpha projects.
  • Porting FreeBSD to IA-64 systems This project is responsible for porting FreeBSD to the IA-64 architecture. Direct any questions specific to this project to the freebsd-ia64@FreeBSD.org mailing list.
  • Porting FreeBSD to PowerPC systems. Contains information on the FreeBSD PPC port, such as mailing list information and so on.
  • Porting FreeBSD to SPARC systems Contains information on the FreeBSD SPARC port including a FAQ, some early boot code, information on SPARC processors and motherboards, and other SPARC projects.
  • The SysVR4 Emulation page describes an SysVR4 emulator for FreeBSD. It is currently capable of running (or walking, in some -cases) a wide-ish variety of SysV executabls taken from Solaris/x86 +cases) a wide-ish variety of SysV executables taken from Solaris/x86 2.5.1 and 2.6 systems. I have reason to believe that it will also run SCO UnixWare and SCO OpenServer binaries.
  • The OSKit The OSKit is a framework and a set of 31 component libraries oriented to operating systems, together with extensive documentation. By providing in a modular way not only most of the infrastructure "grunge" needed by an OS, but also many higher-level components, the OSKit's goal is to lower the barrier to entry to OS R&D and to lower its costs. The OSKit makes it vastly easier to create a new OS, port an existing OS to the x86 (or in the future, to other architectures supported by the OSkit), or enhance an OS to support a wider range of devices, file system formats, executable formats, or network services. The OSKit also works well for constructing OS-related programs, such as boot loaders or OS-level servers atop a microkernel.
  • Small and embedded FreeBSD (PicoBSD) PicoBSD is a one floppy version of FreeBSD which in its different variations allows you to have secure dial-up access, small diskless router, or even a dial-in server. All of this on only one standard 1.44MB floppy disk. It runs on a minimum 386SX CPU with 8MB of RAM, and no hard drive is required!
  • BUDS: BSD Unix Distributed Simple-ly Provide a general purpose clustering system for further development into parallel-multi-processors. This system is intended to be generic in nature, but powerful. It is not intend -for computensively intensive applications, nor is it intended +for computationally intensive applications, nor is it intended for highly complex interdependent applications.
  • The Eclipse Operating System is a testbed for Quality of Service (QoS) that is being developed at Information Sciences Research Center in Bell-Labs, Lucent Technologies. Eclipse provides flexible and fine-grained QoS support for applications. Its design allows legacy or Eclipse-unaware applications to provide QoS without the need of modification or recompilation. A -simple API is provided for (new) applications to take addvantage of +simple API is provided for (new) applications to take advantage of the fine-grained QoS support. Currently, the Eclipse project targets QoS support for server applications, in particular, to differentiate the performance of different web sites hosted on the same platform (see the Apache examples).

Misc

  • GLOBAL is a common source code tag system that works the same way across diverse environments. Currently, it supports the shell command line, the nvi editor, web browser, the emacs editor, and the elvis editor, and the supported languages are C, Yacc, and Java.
  • PAO: Mobile Computing page, laptops running FreeBSD PAO enables FreeBSD to drive many PCMCIA (PC-card) cards and also provides you with PC-card "hotplug" on your laptop machines running FreeBSD. It also contains some improvements and bug fixes for the APM BIOS driver.
  • FreeBSD cross reference. A hypertext cross referenced presentation of the FreeBSD kernel sourecode. The version indexed is -CURRENT, and it is updated every night.
  • Enteruser: A Replacement for Adduser
  • libh. Libh is a wrapper that allows tcl scripts to run in a sort of sandbox and interface to other libraries. Some of the stock libraries that come with libh that can be called from the Tcl scripts include a generic user interface library, which uses Turbo Vision for its console backend, and Qt for its X11 backend. Libh also includes a new package system that uses Zip archives and various per-package scripts among other things. It also includes the beginnings of a new sysinstall.
&footer; diff --git a/en/publish.sgml b/en/publish.sgml index ad04cb7124..d3ffd596cf 100644 --- a/en/publish.sgml +++ b/en/publish.sgml @@ -1,525 +1,525 @@ + %includes; ]> - + &header;
FreeBSD Daemon
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 considerably longer 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 - transtation project by the user group in Japan. Japanese edition of + 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 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

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 + and on the spine "January" is also misspelled as "January", 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.

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. You can register to receive it. Submit articles/make comments by sending email to newsletter@FreeBSD.ORG.
This is issue #2 of the FreeBSD Newsletter, published and distributed free of charge by Walnut Creek CDROM. You can register to receive it. Submit articles/make comments by sending email to newsletter@FreeBSD.ORG.
&footer; diff --git a/en/search/search.sgml b/en/search/search.sgml index 34af1744fb..64c58f46b4 100644 --- a/en/search/search.sgml +++ b/en/search/search.sgml @@ -1,433 +1,433 @@ - + %includes; ]> - + &header;

FreeBSD Search Services

Web pages (including FAQ and Handbook)

Search for:

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


Limit the number of results to

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
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
Commit Changes made to the FreeBSD source tree
Config Development of FreeBSD installation and configuration tools
Current Use of FreeBSD-current sources
DatabaseDiscussing database use and developement under FreeBSDDiscussing database use and development under FreeBSD
Doc Discussions concerning documentation
Emulation Emulating other systems on 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
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
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 ad53ab6581..0f4427ac7c 100644 --- a/en/security/advisories.xml +++ b/en/security/advisories.xml @@ -1,609 +1,609 @@ - + %includes; ]> - + &header;

Introduction

This web page is designed to assist both new and experienced users in the area of security for the FreeBSD Operating System. The FreeBSD Development team 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 outside attack, whom to contact if you find a security related bug, etc. There is also a section on the various ways that the systems programmer can become more security conscious so he or she is less likely to introduce security holes in the first place.

Table of Contents

The FreeBSD Security Officer

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security related communications: The FreeBSD security officer. The position is actually staffed by a team of dedicated security officers, their main tasks being 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 the FreeBSD team about a possible security bug, you should therefore please send mail to the Security Officer with a description of what you've found and the type of vulnerability it represents. The Security Officers also communicate with the various CERT and FIRST teams around the world, sharing information about possible vulnerabilities in FreeBSD or utilities commonly used by FreeBSD. The Security Officers are also active members of those organizations.

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

FreeBSD Security Advisories

The FreeBSD Security Officers provide 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 3.5.1-STABLE
  • FreeBSD 4.2-RELEASE
  • FreeBSD 4.3-RELEASE
  • FreeBSD 4.3-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. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory 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 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 Programing Guidelines

+

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 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_EXECL
      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 -hilights potential trouble-spots in the code. It is a useful +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

&footer diff --git a/en/security/security.sgml b/en/security/security.sgml index ad53ab6581..0f4427ac7c 100644 --- a/en/security/security.sgml +++ b/en/security/security.sgml @@ -1,609 +1,609 @@ - + %includes; ]> - + &header;

Introduction

This web page is designed to assist both new and experienced users in the area of security for the FreeBSD Operating System. The FreeBSD Development team 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 outside attack, whom to contact if you find a security related bug, etc. There is also a section on the various ways that the systems programmer can become more security conscious so he or she is less likely to introduce security holes in the first place.

Table of Contents

The FreeBSD Security Officer

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security related communications: The FreeBSD security officer. The position is actually staffed by a team of dedicated security officers, their main tasks being 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 the FreeBSD team about a possible security bug, you should therefore please send mail to the Security Officer with a description of what you've found and the type of vulnerability it represents. The Security Officers also communicate with the various CERT and FIRST teams around the world, sharing information about possible vulnerabilities in FreeBSD or utilities commonly used by FreeBSD. The Security Officers are also active members of those organizations.

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

FreeBSD Security Advisories

The FreeBSD Security Officers provide 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 3.5.1-STABLE
  • FreeBSD 4.2-RELEASE
  • FreeBSD 4.3-RELEASE
  • FreeBSD 4.3-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. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory 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 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 Programing Guidelines

+

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 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_EXECL
      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 -hilights potential trouble-spots in the code. It is a useful +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

&footer diff --git a/en/support.sgml b/en/support.sgml index 116cac7b1c..930b36a1bd 100644 --- a/en/support.sgml +++ b/en/support.sgml @@ -1,945 +1,945 @@ + %includes; ]> - + &header;

Mailing lists

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:

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

Newsgroups

There are a few FreeBSD specific 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 more information.

WEB Resources

GNATS Problem Report Database

Current FreeBSD problem reports are tracked using the GNATS database.

Problem reports may also be submitted to the development team using the send-pr(1) command on a FreeBSD system 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!

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're looking for on-demand, low overhead access using a custom utility (written in Modula-3 no less).
  • anoncvs if you're looking for on-demand access that has higher overhead than - cvsup (in terms of wall time and bytes xferred) but is easier to use + 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're looking for very low overhead, batch-mode access (basically, patches through email).
  • The web interface if you're looking to simply browse the repository in search of a specific change or file revision.
  • Finally, if you've 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

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 isn't 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've grown larger, we'd 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

  • 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.

  • 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.

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 Davis-Sacramento FreeBSD User's Group (DSFUG) is devoted to the promotion and support of FreeBSD in the Davis / Sacramento area of California. More information can be found at http://www.freebsd.davis.ca.us.

  • The Houston TX Houston FreeBSD Users Group formed March 1999. Our goal is to promote and educate Houston computer users on FreeBSD Unix. We meet on the fourth Thursday of the month. The group operates a mailing list at http://www.houfug.org/mailman/listinfo/hou-freebsd Visit our website or e-mail houfug@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.

  • New York NY FUNY (FreeBSD Users of New York) had its inaugural meeting in February 1999. It is based in NYC and serves the surrounding metropolitan area.

  • 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 Shoping Center. + 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's going on visit the website or send a message to webmaster@svbug.com.

  • 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 is now forming. 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. Initial meeting to be held in May.

  • 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 availble. + 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 throught the country, and to act as + 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.

  • Sao Paulo, Brazil The FUG_SP_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. The group meets in Sao Paulo, Brazil, every month. To join FUG_SP_BR mailing list, send a blank message to fug_sp_br-subscribe@yahoogroups.com

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 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 116cac7b1c..930b36a1bd 100644 --- a/en/usergroups.sgml +++ b/en/usergroups.sgml @@ -1,945 +1,945 @@ + %includes; ]> - + &header;

Mailing lists

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:

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

Newsgroups

There are a few FreeBSD specific 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 more information.

WEB Resources

GNATS Problem Report Database

Current FreeBSD problem reports are tracked using the GNATS database.

Problem reports may also be submitted to the development team using the send-pr(1) command on a FreeBSD system 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!

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're looking for on-demand, low overhead access using a custom utility (written in Modula-3 no less).
  • anoncvs if you're looking for on-demand access that has higher overhead than - cvsup (in terms of wall time and bytes xferred) but is easier to use + 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're looking for very low overhead, batch-mode access (basically, patches through email).
  • The web interface if you're looking to simply browse the repository in search of a specific change or file revision.
  • Finally, if you've 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

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 isn't 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've grown larger, we'd 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

  • 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.

  • 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.

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 Davis-Sacramento FreeBSD User's Group (DSFUG) is devoted to the promotion and support of FreeBSD in the Davis / Sacramento area of California. More information can be found at http://www.freebsd.davis.ca.us.

  • The Houston TX Houston FreeBSD Users Group formed March 1999. Our goal is to promote and educate Houston computer users on FreeBSD Unix. We meet on the fourth Thursday of the month. The group operates a mailing list at http://www.houfug.org/mailman/listinfo/hou-freebsd Visit our website or e-mail houfug@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.

  • New York NY FUNY (FreeBSD Users of New York) had its inaugural meeting in February 1999. It is based in NYC and serves the surrounding metropolitan area.

  • 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 Shoping Center. + 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's going on visit the website or send a message to webmaster@svbug.com.

  • 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 is now forming. 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. Initial meeting to be held in May.

  • 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 availble. + 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 throught the country, and to act as + 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.

  • Sao Paulo, Brazil The FUG_SP_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. The group meets in Sao Paulo, Brazil, every month. To join FUG_SP_BR mailing list, send a blank message to fug_sp_br-subscribe@yahoogroups.com

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 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/y2kbug.sgml b/en/y2kbug.sgml index 51f4803a3b..657dd525d4 100644 --- a/en/y2kbug.sgml +++ b/en/y2kbug.sgml @@ -1,402 +1,402 @@ + %includes; ]> - + &header;

As management understanding of the Year 2000 problem (aka, "The Millennium Bug") increases, more and more companies are demanding official statements from the vendors of their hardware and software as to how their product will handle the year 2000 date rollover.

Organizations that use unix and unix like operating systems such as FreeBSD are already one step ahead of the problem. FreeBSD will properly maintain time long after year 2000 passes.

Background information

(This section based on the text from the Linux Y2K compliance page)

As with all Unix and Unixlike operating systems, time and dates in FreeBSD are represented internally as the number of seconds since the 1st of January 1970 (the Unix "epoch"). Currently, that figure is stored as a 32 bit integer, and will run out part way through 2038. By then we should (hopefully) be using a counter of 64 bits (or greater) which should be good until the end of the universe.

Note that the OS being Y2K compliant will not fix errant applications that are not Y2K compliant.

Note also that the OS expects to read the current date and time from the CMOS clock of your computer. Not all of these devices correctly handle the year 2000. You are advised to test each platform individually to ensure that your hardware clock behaves correctly when going from 1999 to 2000, and that it correctly interprets the year 2000 as a leap year.

What you can do

FreeBSD will continue to properly maintain time well into the next century. Third party applications, however, might not. Your best defense against year 2000 issues is a good offense. Listening to stories claiming the coming meltdown of the world as we know it are not the way to solve the millennium bug. Nor is waiting until the last minute. The FreeBSD Project recommends that your organization apply sound system administration principles as the millennium approaches.

There are tests that you can perform to see how your system will respond. Set your clock to a few minutes before midnight on New Year's Eve and watch the system time. Your system should display the year as 2000 and not 1900. If the year is displayed incorrectly, then you will have plenty of time to update your hardware. Operating your organizations information systems under their normal daily load with the - clock set forward can provide valuable insight into your vulnerablility + clock set forward can provide valuable insight into your vulnerability to year 2000 issues.

Important: Do not do this on a live production system. You may confuse any applications you have which rely on dates (billing systems, backup regimes, and so on). Always conduct tests like this on development systems which can not affect any live data you may have.

FreeBSD Year 2000 Statement

"After extensive analysis and testing, we believe that FreeBSD is 100% Y2K compliant. In the unlikely event that something has been overlooked, we will do our best to fix it as soon as possible."

David Greenman
Principal Architect, The FreeBSD project

Fixed problems

The following Y2K problems have been identified and fixed in FreeBSD.

misc/1380
Several programs have a hardcoded 19%d in responses for the year. Affected programs include: yacc, ftpd, and make. [Fixed: yacc v1.2 1999/01/18; ftpd v1.7 1996/08/05; make v1.4 1996/10/06; fixes in FreeBSD-2.2 and above]
conf/1382
The sed script in /etc/rc.local that builds the host/kernel ID line for the message of the day relies on the year not going past 1999. [Fixed v1.21 1996/10/24; fixes in FreeBSD-2.2 and above]
misc/3465
The etc/namedb/make-localhost command generates the DNS serial number as YYMMDD. In the year 2000, this will be generated as 1YYMMDD. [Fixed v1.2 1997/08/11; fixes in FreeBSD-2.2.5 and above]
gnu/4930 and gnu/8321
groff tmac macros have hardcoded 19 for generating some dates. [Fixed: tmac.e v1.3 1998/12/06; doc-common v1.10 1999/01/19; fixes in FreeBSD-3.1 and above]
bin/9323
In its obsolescent form, touch doesn't treat the two digit year year specification correctly. Years in the range 00-68 are treated as 1900-1968 instead of 2000-2068. [Fixed v1.7 1999/01/05; fixes in FreeBSD-3.1 and above]
xntpd/parse/util/dcfd.c
The leap year calculations for the number of days in a year, and the conversion of DCF77 time to seconds since the Epoch were wrong. These errors affected all years. [Fixed v1.6 1999/01/12; fixes in FreeBSD-3.1 and above]
tar/getdate.y
Function Convert() was hard-coded for two digit years in range 70-99. Now adjusted to allow two digit years for 1970-2069. The function does not allow for century non-leap years - y2k1 alert! [Fixed v1.4 1999/01/12; fixes in FreeBSD-3.1 and above]
fetch/http.c
The HTTP protocol includes an obsolete date format which uses a two-digit year. Previous versions of fetch would interpret all such dates in the 1900s; subsequent to this revision, the pivot described in RFC 2068 is employed, which causes two-digit years to be interpreted as always belonging to the current century unless they would be 50 or more years in the future. Since the HTTP servers which use this obsolete format are no longer widespread, this is not expected to have a significant impact. [Fixed v1.24 1999/01/15; fixes in FreeBSD-3.1 and above]
misc/9500
The `edithook' script in the CVSROOT directory uses a raw tm_year and will therefore display 01/01/100 for 2000-JAN-01. [Fixed v1.2 1999/01/17; not relevant to FreeBSD releases]
bin/9501
Several cvs contrib files are not Y2K compliant. The log.pl and sccs2rcs.csh scripts prepend `19' to the year resulting in a display of 19100 for 2000. The log_accum.pl script uses a two digit year in one place and in another place assumes that the tm_year is year within century rather than years since 1900. [Fixed: log.pl v1.2 1999/01/15; sccs2rcs.csh v1.3 1999/01/15; fixes in FreeBSD-3.1 and above]
bin/9502
The groff number register `yr' is assigned from a (struct tm).tm_year and therefore represents the number of years since 1900, not the year within the century (see definition in troff/input.cc). [Fixed, now set mod 100, troff/input.cc V1.2 1999/06/03; fixed in FreeBSD-3.3]
bin/9503
PicoBSD's simple_httpd uses a raw tm_year and will therefore display 01/01/100 for 2000-JAN-01. [Fixed v1.2 1999/01/16; fixes in FreeBSD-3.1 and above]
bin/9505
Adduser uses a raw tm_year and will therefore display 100/01/01 for 2000-JAN-01. [Fixed v1.42 1999/01/15; fixes in FreeBSD-3.1 and above]
bin/9506
Cron uses a raw tm_year and will therefore display 100 for 2000. [Fixed v1.7 1999/01/16; fixes in FreeBSD-3.1 and above]
bin/9507
tcpslice(8) uses a raw tm_year and will therefore display 100y01m01d... for 2000-JAN-01. For compatibility, use a two-digit year until 2000.[Fixed v1.8 1999/01/20; fixes in FreeBSD-3.1 and above]
bin/14472
Date command does not take thousand/hundred digits. [Fixed v1.31 1999/11/10]
misc/14511
Chpass has a problem using 00 for expiration year.
bin/15852 and gnu/16045 and bin/16207
Groff predefined \*(DT [\*(td] string has Y2K bug. [Fixed with import of version 1.15 2000/01/12]
bin/15872
at(1) has a problem with valid time specifications if tm_year is 100, reports `garbled time'.
misc/16238
KerberosIV install does not work properly because there is a hard-wired expiration date of 12/31/99 in the Kerberos source for the ticket granter. [Fixed v1.24 1999/09/19]

Problematic applications

ports/7681
TkDesk 1.0 uses a hardcoded 19 in the file listing window. A file with a date > 2000 is displayed with a year looking like "191xx" where xx is the last two numbers of the real date. This bug has been fixed in version 1.1. [Port updated 1998/10/10; fixes in FreeBSD-3.0 and above]
ports/9295
INN 1.7.2 suffers from 2 Y2K related problems. One occurs when pulling news (-f option to nntpget) and the other relates to the Expire header with relative dates past 2000. [Both INN ports upgraded to INN 2.2 1999/05/02; fixes in FreeBSD-3.2 and above]
ports/9298
Knews suffers from 2 Y2K related problems. One occurs during the generation of the NNTP NEWGROUPS command. The other occurs because knews doesn't think that 2000 is a leap year. Both are fixed in knews-1.0b.1. [Port updated 1999/01/07; fixes in FreeBSD-3.1 and above]
ports/9300
Nntp-t5 suffers from a Y2K problem during the generation of the NEWNEWS command. [Port patched 1999/01/05; fixes in FreeBSD-3.1 and above]
ports/11144
The tiff port has a hardcoded 19xx. While this is in the contrib section (for converting Sun rasterfile format to TIFF), and not installed by default, this should be patched. [Port patched 1999/04/18, followed by upgrade 1999/05/11; fixes in FreeBSD-3.2 and above]
ports/11145
The dgs port suffers from the same TIFF related problem as the tiff port. [contrib routine for converting Sun rasterfiles to TIFF] [Port patched 1999/04/18; fixes in FreeBSD-3.2 and above]
ports/13694
The slurp port has a problem generating a correctly formatted host file name when tm_year is greater than 100. [Port patched 1999/10/27; fixes in FreeBSD-3.3-STABLE and above]
ports/15477
wwwstat port has a hardcoded 19.
ports/15789
proftpd has a minor Y2K problem. [Port patched 1999/12/22]
ports/15820
sendfile has a problem not setting the atime and mtime properly for files sent after year 1999.
ports/15854
dclock uses localtime and in particular the references to tm_year do not take into account the year 2000. [Port patched 2000/01/04]
ports/15868
The reporting function of hylafax (xferstats) is not y2k compatible. [Port patched 2000/01/24]
ports/15926
A y2k bug in leafnode+ 2.9 considers incoming news articles with the (arguably bogus) Date: header like `Wed, 05 Jan 00 15:01:40 GMT' to be too old, so these incoming articles are dropped. [Fixed by upgrading port to version 2.10 2000/01/24]
ports/16062
Japanese e2ps port has hardcoded 19. [Port patched 2000/01/24]
ports/16073
nntp port 1.5.11.5 has Y2K related problems. [Port upgraded to version 1.5.12.2 2000/01/12]
ports/16167
This is a bug-fix release that corrects a y2k bug in INN 2.2.1 that will show up in the NEWNEWS and NEWGROUPS commands after 2000-01-01 00:00:00 when the date specified to the command is before 2000-01-01 00:00:00. [Port upgraded to version 2.2.2 2000/01/28]
NetHack 3.2.2 and earlier versions are not Y2K compliant (the score file used 2 digit years and will be corrupted if added to in the year 2000). [Port updated to version 3.2.3 2000/01/05]
Japanese mnews port has Y2K problems. [Port updated to version 1.22 1999/12/26]

More information

If you have further questions about FreeBSD's year 2000 compliance, or you have discovered an application running under FreeBSD that is not Y2K compliant, please contact the project at freebsd-bugs@FreeBSD.ORG.

&footer; diff --git a/share/sgml/advisories.xml b/share/sgml/advisories.xml index ad53ab6581..0f4427ac7c 100644 --- a/share/sgml/advisories.xml +++ b/share/sgml/advisories.xml @@ -1,609 +1,609 @@ - + %includes; ]> - + &header;

Introduction

This web page is designed to assist both new and experienced users in the area of security for the FreeBSD Operating System. The FreeBSD Development team 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 outside attack, whom to contact if you find a security related bug, etc. There is also a section on the various ways that the systems programmer can become more security conscious so he or she is less likely to introduce security holes in the first place.

Table of Contents

The FreeBSD Security Officer

To better coordinate information exchange with others in the security community, FreeBSD has a focal point for security related communications: The FreeBSD security officer. The position is actually staffed by a team of dedicated security officers, their main tasks being 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 the FreeBSD team about a possible security bug, you should therefore please send mail to the Security Officer with a description of what you've found and the type of vulnerability it represents. The Security Officers also communicate with the various CERT and FIRST teams around the world, sharing information about possible vulnerabilities in FreeBSD or utilities commonly used by FreeBSD. The Security Officers are also active members of those organizations.

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

FreeBSD Security Advisories

The FreeBSD Security Officers provide 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 3.5.1-STABLE
  • FreeBSD 4.2-RELEASE
  • FreeBSD 4.3-RELEASE
  • FreeBSD 4.3-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. After a couple of days and some testing, the fix is retrofitted into the supported FreeBSD-stable branch(es) and an advisory 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 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 Programing Guidelines

+

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 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_EXECL
      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 -hilights potential trouble-spots in the code. It is a useful +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

&footer