Committer's Guide

diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml index 50fcabaa57..d7a58f03d3 100644 --- a/en_US.ISO8859-1/articles/committers-guide/article.xml +++ b/en_US.ISO8859-1/articles/committers-guide/article.xml @@ -1,4662 +1,4658 @@ ]>

Committer's Guide The &os; Documentation Project 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 The &os; Documentation Project &tm-attrib.freebsd; &tm-attrib.coverity; &tm-attrib.ibm; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.general; $FreeBSD$ $FreeBSD$ This document provides information for the &os; committer community. All new committers should read this document before they start, and existing committers are strongly encouraged to review it from time to time. Almost all &os; developers have commit rights to one or more repositories. However, a few developers do not, and some of the information here applies to them as well. (For instance, some people only have rights to work with the Problem Report database). Please see for more information. This document may also be of interest to members of the &os; community who want to learn more about how the project works. Administrative Details Login Methods &man.ssh.1;, protocol 2 only Main Shell Host freefall.FreeBSD.org src/ Subversion Root svn+ssh://svn.FreeBSD.org/base (see also ). doc/ Subversion Root svn+ssh://svn.FreeBSD.org/doc (see also ). ports/ Subversion Root svn+ssh://svn.FreeBSD.org/ports (see also ). Internal Mailing Lists developers (technically called all-developers), doc-developers, doc-committers, ports-developers, ports-committers, src-developers, src-committers. (Each project repository has its own -developers and -committers mailing lists. Archives for these lists may be found in files /home/mail/repository-name-developers-archive and /home/mail/repository-name-committers-archive on the FreeBSD.org cluster.) Core Team monthly reports /home/core/public/monthly-reports on the FreeBSD.org cluster. Ports Management Team monthly reports /home/portmgr/public/monthly-reports on the FreeBSD.org cluster. Noteworthy src/ SVN Branches stable/8 (8.X-STABLE), stable/9 (9.X-STABLE), head (-CURRENT) &man.ssh.1; is required to connect to the project hosts. For more information, see . Useful links: &os; Project Internal Pages &os; Project Hosts &os; Project Administrative Groups Commit Bit Types The &os; repository has a number of components which, when combined, support the basic operating system source, documentation, third party application ports infrastructure, and various maintained utilities. When &os; commit bits are allocated, the areas of the tree where the bit may be used are specified. Generally, the areas associated with a bit reflect who authorized the allocation of the commit bit. Additional areas of authority may be added at a later date: when this occurs, the committer should follow normal commit bit allocation procedures for that area of the tree, seeking approval from the appropriate entity and possibly getting a mentor for that area for some period of time. Committer Type Responsible Tree Components src core@ src/, doc/ subject to appropriate review doc doceng@ doc/, src/ documentation ports portmgr@ ports/ Commit bits allocated prior to the development of the notion of areas of authority may be appropriate for use in many parts of the tree. However, common sense dictates that a committer who has not previously worked in an area of the tree seek review prior to committing, seek approval from the appropriate responsible party, and/or work with a mentor. Since the rules regarding code maintenance differ by area of the tree, this is as much for the benefit of the committer working in an area of less familiarity as it is for others working on the tree. Committers are encouraged to seek review for their work as part of the normal development process, regardless of the area of the tree where the work is occurring. Policy for <filename>doc/</filename> Committer Activity in <filename>src/</filename> doc committers may commit documentation changes to src files, such as man pages, READMEs, fortune databases, calendar files, and comment fixes without approval from a src committer, subject to the normal care and tending of commits. doc committers may commit minor src changes and fixes, such as build fixes, small features, etc, with an "Approved by" from a src committer. doc committers may seek an upgrade to a src commit bit by acquiring a mentor, who will propose the doc committer to core. When approved, they will be added to 'access' and the normal mentoring period will ensue, which will involve a continuing of Approved by for some period. "Approved by" is only acceptable from non-mentored src committers -- mentored committers can provide a "Reviewed by" but not an "Approved by". Subversion Primer It is assumed that you are already familiar with the basic operation of the version control systems in use. Traditionally this was CVS. Subversion is used for the src tree as of May 2008, the doc/www tree as of May 2012 and the ports tree as of July 2012. There is a list of things missing in Subversion when compared to CVS. The notes at might also be useful. Introduction The &os; source repository switched from CVS to Subversion on May 31st, 2008. The first real SVN commit is r179447. The &os; doc/www repository switched from CVS to Subversion on May 19th, 2012. The first real SVN commit is r38821. Part of the doc/www CVS to SVN conversion included an infrastructural change to the build process. The most notable change is the location of the &os; website www tree, which has been moved from www/lang/ to head/lang/htdocs/. The &os; ports repository switched from CVS to Subversion on July 14th, 2012. The first real SVN commit is r300894. There are mechanisms in place to automatically merge changes back from the Subversion src repository to the CVS repository for some &os; branches (releng/6 through releng/9), however this is purely to support pre-existing end-user installs and should not be relied upon, recommended or advertised. Future branches will not be exported to CVS at all. The ports repository was exported to CVS for a period of time to aid end user migration, but as of 28th February 2013 is no longer exported. Subversion is not that different from CVS when it comes to daily use, but there are differences. Subversion has a number of features that should make developers' lives easier. The most important advantage to Subversion (and the reason why &os; switched) is that it handles branches and merging much better than CVS does. Some of the principal differences are: Commits are atomic. Revision numbers apply across the repository—all files that were modified in the same commit have the same revision number. Branching and tagging are namespace operations. Directories are versioned. Files and directories can have arbitrary, versioned metadata attached to them. Files and directories can be copied, with full history tracking. No more contortions due to CVS weakness such as applying &man.patch.1; files at compile time in order to avoid touching vendor branch code. No more repo-copies. Subversion can be installed from the &os; Ports Collection, by issuing the following commands: &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make clean install Getting Started There are a few ways to obtain a working copy of the tree from Subversion. This section will explain them. Direct Checkout The first is to check out directly from the main repository. For the src tree, use: &prompt.user; svn checkout svn+ssh://svn.freebsd.org/base/head /usr/src For the doc tree, use: &prompt.user; svn checkout svn+ssh://svn.freebsd.org/doc/head /usr/doc For the ports tree, use: &prompt.user; svn checkout svn+ssh://svn.freebsd.org/ports/head /usr/ports Though the remaining examples in this document are written with the workflow of working with the src tree in mind, the underlying concepts are the same for working with the doc and the ports tree. Ports related Subversion operations are listed in . The above command will check out a CURRENT source tree as /usr/src/, which can be any target directory on the local filesystem. Omitting the final argument of that command causes the working copy, in this case, to be named head, but that can be renamed safely. svn+ssh means the SVN protocol tunnelled over SSH. The name of the server is svn.freebsd.org, base is the path to the repository, and head is the subdirectory within the repository. If your &os; login name is different from your login name on your local machine, you must either include it in the URL (for example svn+ssh://jarjar@svn.freebsd.org/base/head), or add an entry to your ~/.ssh/config in the form: Host svn.freebsd.org User jarjar This is the simplest method, but it's hard to tell just yet how much load it will place on the repository. Subversion is much faster than CVS, however. The svn diff does not require access to the server as SVN stores a reference copy of every file in the working copy. This, however, means that Subversion working copies are very large in size. Checkout from a Mirror Check out a working copy from a mirror by substituting the mirror's URL for svn+ssh://svn.freebsd.org/base. This can be an official mirror or a mirror maintained by using svnsync. There is a serious disadvantage to this method: every time something is to be committed, a svn relocate to the master repository has to be done, remembering to svn relocate back to the mirror after the commit. Also, since svn relocate only works between repositories that have the same UUID, some hacking of the local repository's UUID has to occur before it is possible to start using it. Unlike with CVS, the hassle of a local svnsync mirror probably is not worth it unless the network connectivity situation or other factors demand it. If it is needed, see the end of this chapter for information on how to set one up. <literal>RELENG_*</literal> Branches and General Layout In svn+ssh://svn.freebsd.org/base, base refers to the source tree. Similarly, ports refers to the ports tree, and so on. These are separate repositories with their own change number sequences, access controls and commit mail. For the base repository, HEAD refers to the -CURRENT tree. For example, head/bin/ls is what would go into /usr/src/bin/ls in a release. Some key locations are: /head/ which corresponds to HEAD, also known as -CURRENT. /stable/n which corresponds to RELENG_n. /releng/n.n which corresponds to RELENG_n_n. /release/n.n.n which corresponds to RELENG_n_n_n_RELEASE. /vendor* is the vendor branch import work area. This directory itself does not contain branches, however its subdirectories do. This contrasts with the stable, releng and release directories. /projects and /user feature a branch work area, like in Perforce. As above, the /user directory does not contain branches itself. &os; Documentation Project Branches and Layout In svn+ssh://svn.freebsd.org/doc, doc refers to the repository root of the source tree. In general, most &os; Documentation Project work will be done within the head/ branch of the documentation source tree. &os; documentation is written and/or translated to various languages, each in a separate directory in the head/ branch. Each translation set contains several subdirectories for the various parts of the &os; Documentation Project. A few noteworthy directories are: /articles/ contains the source code for articles written by various &os; contributors. /books/ contains the source code for the different books, such as the &os; Handbook. /htdocs/ contains the source code for the &os; website. &os; Ports Tree Branches and Layout In svn+ssh://svn.freebsd.org/ports, ports refers repository root of the ports tree. In general, most &os; port work will be done within the head/ branch of the ports tree which is the actual ports tree used to install software. Some other key locations are: /branches/RELENG_n_n_n which corresponds to RELENG_n_n_n is used to merge back security updates in preparation for a release. /tags/RELEASE_n_n_n which corresponds to RELEASE_n_n_n represents a release tag of the ports tree. /tags/RELEASE_n_EOL represents the end of life tag of a specific &os; branch. Daily Use This section will explain how to perform common day-to-day operations with Subversion. Help SVN has built in help documentation. It can be accessed by typing the following command: &prompt.user; svn help Additional information can be found in the Subversion Book. Checkout As seen earlier, to check out the &os; head branch: &prompt.user; svn checkout svn+ssh://svn.freebsd.org/base/head /usr/src At some point, more than just HEAD will probably be useful, for instance when merging changes to stable/7. Therefore, it may be useful to have a partial checkout of the complete tree (a full checkout would be very painful). To do this, first check out the root of the repository: &prompt.user; svn checkout --depth=immediates svn+ssh://svn.freebsd.org/base This will give base with all the files it contains (at the time of writing, just ROADMAP.txt) and empty subdirectories for head, stable, vendor and so on. Expanding the working copy is possible. Just change the depth of the various subdirectories: &prompt.user; svn up --set-depth=infinity base/head &prompt.user; svn up --set-depth=immediates base/release base/releng base/stable The above command will pull down a full copy of head, plus empty copies of every release tag, every releng branch, and every stable branch. If at a later date merging to 7-STABLE is required, expand the working copy: &prompt.user; svn up --set-depth=infinity base/stable/7 Subtrees do not have to be expanded completely. For instance, expanding only stable/7/sys and then later expand the rest of stable/7: &prompt.user; svn up --set-depth=infinity base/stable/7/sys &prompt.user; svn up --set-depth=infinity base/stable/7 Updating the tree with svn update will only update what was previously asked for (in this case, head and stable/7; it will not pull down the whole tree. Decreasing the depth of a working copy is not possible. Anonymous Checkout It is possible to anonymously check out the &os; repository with Subversion. This will give access to a read-only tree that can be updated, but not committed to. To do this, use the following command: &prompt.user; svn co https://svn0.us-west.FreeBSD.org/base/head /usr/src Select the closest mirror and verify the mirror server certificate from the list of Subversion mirror sites. Updating the Tree To update a working copy to either the latest revision, or a specific revision: &prompt.user; svn update &prompt.user; svn update -r12345 Status To view the local changes that have been made to the working copy: &prompt.user; svn status To show local changes and files that are out-of-date do: &prompt.user; svn status --show-updates Editing and Committing Unlike Perforce, SVN does not need to be told in advance about file editing. svn commit works like the equivalent CVS command. To commit all changes in the current directory and all subdirectories: &prompt.user; svn commit To commit all changes in, for example, lib/libfetch/ and usr/bin/fetch/ in a single operation: &prompt.user; svn commit lib/libfetch usr/bin/fetch There is also a commit wrapper for the ports tree to handle the properties and sanity checking your changes: &prompt.user; /usr/ports/Tools/scripts/psvn commit Adding and Removing Files Before adding files, get a copy of auto-props.txt (there is also a ports tree specific version) and add it to ~/.subversion/config according to the instructions in the file. If you added something before reading this, use svn rm --keep-local for just added files, fix your config file and re-add them again. The initial config file is created when you first run a svn command, even something as simple as svn help. Files are added to a SVN repository with svn add. To add a file named foo, edit it, then: &prompt.user; svn add foo Most new source files should include a $&os;$ string in the new file. On commit, svn will expand the $&os;$ string, adding the file path, revision number, date and time of commit, and the username of the committer. Files which cannot be modified may be committed without the $&os;$ string. Files can be removed with svn remove: &prompt.user; svn remove foo Subversion does not require deleting the file before using svn rm, and indeed complains if that happens. It is possible to add directories with svn add: &prompt.user; mkdir bar &prompt.user; svn add bar Although svn mkdir makes this easier by combining the creation of the directory and the adding of it: &prompt.user; svn mkdir bar Like files, directories are removed with svn rm. There is no separate command specifically for removing directories. &prompt.user; svn rm bar Copying and Moving Files This command creates a copy of foo.c named bar.c, with the new file also under version control: &prompt.user; svn copy foo.c bar.c The example above is equivalent to: &prompt.user; cp foo.c bar.c &prompt.user; svn add bar.c To move and rename a file: &prompt.user; svn move foo.c bar.c Log and Annotate svn log shows revisions and commit messages, most recent first, for files or directories. When used on a directory, all revisions that affected the directory and files within that directory are shown. svn annotate, or equally svn praise or svn blame, shows the most recent revision number and who committed that revision for each line of a file. Diffs svn diff displays changes to the working copy. Diffs generated by SVN are unified and include new files by default in the diff output. svn diff can show the changes between two revisions of the same file: &prompt.user; svn diff -r179453:179454 ROADMAP.txt It can also show all changes for a specific changeset. The following will show what changes were made to the current directory and all subdirectories in changeset 179454: &prompt.user; svn diff -c179454 . Reverting Local changes (including additions and deletions) can be reverted using svn revert. It does not update out-of-date files, but just replaces them with pristine copies of the original version. Conflicts If an svn update resulted in a merge conflict, Subversion will remember which files have conflicts and refuse to commit any changes to those files until explicitly told that the conflicts have been resolved. The simple, not yet deprecated procedure is the following: &prompt.user; svn resolved foo However, the preferred procedure is: &prompt.user; svn resolve --accept=working foo The two examples are equivalent. Possible values for --accept are: working: use the version in your working directory (which one presumes has been edited to resolve the conflicts). base: use a pristine copy of the version you had before svn update, discarding your own changes, the conflicting changes, and possibly other intervening changes as well. mine-full: use what you had before svn update, including your own changes, but discarding the conflicting changes, and possibly other intervening changes as well. theirs-full: use the version that was retrieved when you did svn update, discarding your own changes. Advanced Use Sparse Checkouts SVN allows sparse, or partial checkouts of a directory by adding to a svn checkout. Valid arguments to are: empty: the directory itself without any of its contents. files: the directory and any files it contains. immediates: the directory and any files and directories it contains, but none of the subdirectories' contents. infinity: anything. The --depth option applies to many other commands, including svn commit, svn revert, and svn diff. Since --depth is sticky, there is a --set-depth option for svn update that will change the selected depth. Thus, given the working copy produced by the previous example: &prompt.user; cd ~/freebsd &prompt.user; svn update --set-depth=immediates . The above command will populate the working copy in ~/freebsd with ROADMAP.txt and empty subdirectories, and nothing will happen when svn update is executed on the subdirectories. However, the following command will set the depth for head (in this case) to infinity, and fully populate it: &prompt.user; svn update --set-depth=infinity head Direct Operation Certain operations can be performed directly on the repository without touching the working copy. Specifically, this applies to any operation that does not require editing a file, including: log, diff mkdir remove, copy, rename propset, propedit, propdel merge Branching is very fast. The following command would be used to branch RELENG_8: &prompt.user; svn copy svn+ssh://svn.freebsd.org/base/head svn+ssh://svn.freebsd.org/base/stable/8 This is equivalent to the following set of commands which take minutes and hours as opposed to seconds, depending on your network connection: &prompt.user; svn checkout --depth=immediates svn+ssh://svn.freebsd.org/base &prompt.user; cd base &prompt.user; svn update --depth=infinity head &prompt.user; svn copy head stable/8 &prompt.user; svn commit stable/8 Merging with <acronym>SVN</acronym> This section deals with merging code from one branch to another (typically, from head to a stable branch). In all examples below, $FSVN refers to the location of the &os; Subversion repository, svn+ssh://svn.freebsd.org/base/. About Merge Tracking From the user's perspective, merge tracking information (or mergeinfo) is stored in a property called svn:mergeinfo, which is a comma-separated list of revisions and ranges of revisions that have been merged. When set on a file, it applies only to that file. When set on a directory, it applies to that directory and its descendants (files and directories) except for those that have their own svn:mergeinfo. It is not inherited. For instance, stable/6/contrib/openpam/ does not implicitly inherit mergeinfo from stable/6/, or stable/6/contrib/. Doing so would make partial checkouts very hard to manage. Instead, mergeinfo is explicitly propagated down the tree. For merging something into branch/foo/bar/, the following rules apply: If branch/foo/bar/ does not already have a mergeinfo record, but a direct ancestor (for instance, branch/foo/) does, then that record will be propagated down to branch/foo/bar/ before information about the current merge is recorded. Information about the current merge will not be propagated back up that ancestor. If a direct descendant of branch/foo/bar/ (for instance, branch/foo/bar/baz/) already has a mergeinfo record, information about the current merge will be propagated down to it. If you consider the case where a revision changes several separate parts of the tree (for example, branch/foo/bar/ and branch/foo/quux/), but you only want to merge some of it (for example, branch/foo/bar/), you will see that these rules make sense. If mergeinfo was propagated up, it would seem like that revision had also been merged to branch/foo/quux/, when in fact it had not been. Selecting the Source and Target Because of mergeinfo propagation, it is important to choose the source and target for the merge carefully to minimise property changes on unrelated directories. The rules for selecting the merge target (the directory that you will merge the changes to) can be summarized as follows: Never merge directly to a file. Never, ever merge directly to a file. Never, ever, ever merge directly to a file. Changes to kernel code should be merged to sys/. For instance, a change to the &man.ichwd.4; driver should be merged to sys/, not sys/dev/ichwd/. Likewise, a change to the TCP/IP stack should be merged to sys/, not sys/netinet/. Changes to code under etc/ should be merged at etc/, not below it. Changes to vendor code (code in contrib/, crypto/ and so on) should be merged to the directory where vendor imports happen. For instance, a change to crypto/openssl/util/ should be merged to crypto/openssl/. This is rarely an issue, however, since changes to vendor code are usually merged wholesale. Changes to userland programs should as a general rule be merged to the directory that contains the Makefile for that program. For instance, a change to usr.bin/xlint/arch/i386/ should be merged to usr.bin/xlint/. Changes to userland libraries should as a general rule be merged to the directory that contains the Makefile for that library. For instance, a change to lib/libc/gen/ should be merged to lib/libc/. There may be cases where it makes sense to deviate from the rules for userland programs and libraries. For instance, everything under lib/libpam/ is merged to lib/libpam/, even though the library itself and all of the modules each have their own Makefile. Changes to manual pages should be merged to share/man/manN/, for the appropriate value of N. Other changes to share/ should be merged to the appropriate subdirectory and not to share/ directly. Changes to a top-level file in the source tree such as UPDATING or Makefile.inc1 should be merged directly to that file rather than to the root of the whole tree. Yes, this is an exception to the first three rules. When in doubt, ask. If you need to merge changes to several places at once (for instance, changing a kernel interface and every userland program that uses it), merge each target separately, then commit them together. For instance, if you merge a revision that changed a kernel API and updated all the userland bits that used that API, you would merge the kernel change to sys, and the userland bits to the appropriate userland directories, then commit all of these in one go. The source will almost invariably be the same as the target. For instance, you will always merge stable/7/lib/libc/ from head/lib/libc/. The only exception would be when merging changes to code that has moved in the source branch but not in the parent branch. For instance, a change to &man.pkill.1; would be merged from bin/pkill/ in head to usr.bin/pkill/ in stable/7. Preparing the Merge Target Because of the mergeinfo propagation issues described earlier, it is very important that you never merge changes into a sparse working copy. You must always have a full checkout of the branch you will merge into. For instance, when merging from HEAD to 7, you must have a full checkout of stable/7: &prompt.user; cd stable/7 &prompt.user; svn up --set-depth=infinity The target directory must also be up-to-date and must not contain any uncommitted changes or stray files. Identifying Revisions Identifying revisions to be merged is a must. If the target already has complete mergeinfo, ask SVN for a list: &prompt.user; cd stable/6/contrib/openpam &prompt.user; svn mergeinfo --show-revs=eligible $FSVN/head/contrib/openpam If the target does not have complete mergeinfo, check the log for the merge source. Merging Now, let us start merging! The Principles Say you would like to merge: revision $R in directory $target in stable branch $B from directory $source in head $FSVN is svn+ssh://svn.freebsd.org/base Assuming that revisions $P and $Q have already been merged, and that the current directory is an up-to-date working copy of stable/$B, the existing mergeinfo looks like this: &prompt.user; svn propget svn:mergeinfo -R $target $target - /head/$source:$P,$Q Merging is done like so: &prompt.user; svn merge -c$R $FSVN/head/$source $target Checking the results of this is possible with svn diff. The svn:mergeinfo now looks like: &prompt.user; svn propget svn:mergeinfo -R $target $target - head/$source:$P,$Q,$R If the results are not exactly as shown, assistance may be required before committing as mistakes may have been made, or there may be something wrong with the existing mergeinfo, or there may be a bug in Subversion. Practical Example As a practical example, consider the following scenario: The changes to netmap.4 in r238987 is to be merged from CURRENT to 9-STABLE. The file resides in head/share/man/man4 and according to this is also where to do the merge. Note that in this example all paths are relative to the top of the svn repository. For more information on the directory layout, see . The first step is to inspect the existing mergeinfo. &prompt.user; svn propget svn:mergeinfo -R stable/9/share/man/man4 Take a quick note of how it looks before moving on to the next step; doing the actual merge: &prompt.user; svn merge -c r238987 svn+ssh://svn.freebsd.org/base/head/share/man/man4 stable/9/share/man/man4 --- Merging r238987 into 'stable/9/share/man/man4': U stable/9/share/man/man4/netmap.4 --- Recording mergeinfo for merge of r238987 into 'stable/9/share/man/man4': U stable/9/share/man/man4 Check that the revision number of the merged revision has been added. Once this is verified, the only thing left is the actual commit. &prompt.user; svn commit stable/9/share/man/man4 Merging into the Kernel (<filename class="directory">sys/</filename>) As stated above, merging into the kernel is different from merging in the rest of the tree. In many ways merging to the kernel is simpler because there is always the same merge target (sys/). Once svn merge has been executed, svn diff has to be run on the directory to check the changes. This may show some unrelated property changes, but these can be ignored. Next, build and test the kernel, and, once the tests are complete, commit the code as normal, making sure that the commit message starts with Merge r226222 from head, or similar. Precautions Before Committing As always, build world (or appropriate parts of it). Check the changes with svn diff and svn stat. Make sure all the files that should have been added or deleted were in fact added or deleted. Take a closer look at any property change (marked by a M in the second column of svn stat). Normally, no svn:mergeinfo properties should be anywhere except the target directory (or directories). If something looks fishy, ask for help. Committing Make sure to commit a top level directory to have the mergeinfo included as well. Do not specify individual files on the command line. For more information about committing files in general, see the relevant section of this primer. Vendor Imports with <acronym>SVN</acronym> Please read this entire section before starting a vendor import. Patches to vendor code fall into two categories: Vendor patches: these are patches that have been issued by the vendor, or that have been extracted from the vendor's version control system, which address issues which in your opinion cannot wait until the next vendor release. &os; patches: these are patches that modify the vendor code to address &os;-specific issues. The nature of a patch dictates where it should be committed: Vendor patches should be committed to the vendor branch, and merged from there to head. If the patch addresses an issue in a new release that is currently being imported, it must not be committed along with the new release: the release must be imported and tagged first, then the patch can be applied and committed. There is no need to re-tag the vendor sources after committing the patch. &os; patches should be committed directly to head. Preparing the Tree If importing for the first time after the switch to Subversion, flattening and cleaning up the vendor tree is necessary, as well as bootstrapping the merge history in the main tree. Flattening During the conversion from CVS to Subversion, vendor branches were imported with the same layout as the main tree. This means that the pf vendor sources ended up in vendor/pf/dist/contrib/pf. The vendor source is best directly in vendor/pf/dist. To flatten the pf tree: &prompt.user; cd vendor/pf/dist/contrib/pf &prompt.user; svn mv $(svn list) ../.. &prompt.user; cd ../.. &prompt.user; svn rm contrib &prompt.user; svn propdel -R svn:mergeinfo . &prompt.user; svn commit The propdel bit is necessary because starting with 1.5, Subversion will automatically add svn:mergeinfo to any directory that is copied or moved. In this case, as nothing is being merged from the deleted tree, they just get in the way. Tags may be flattened as well (3, 4, 3.5 etc.); the procedure is exactly the same, only changing dist to 3.5 or similar, and putting the svn commit off until the end of the process. Cleaning Up The dist tree can be cleaned up as necessary. Disabling keyword expansion is recommended, as it makes no sense on unmodified vendor code and in some cases it can even be harmful. OpenSSH, for example, includes two files that originated with &os; and still contain the original version tags. To do this: &prompt.user; svn propdel svn:keywords -R . &prompt.root; svn commit Bootstrapping Merge History If importing for the first time after the switch to Subversion, bootstrap svn:mergeinfo on the target directory in the main tree to the revision that corresponds to the last related change to the vendor tree, prior to importing new sources: &prompt.user; cd head/contrib/pf &prompt.user; svn merge --record-only svn+ssh://svn.freebsd.org/base/vendor/pf/dist@180876 . &prompt.user; svn commit Importing New Sources With two commits—one for the import itself and one for the tag—this step can optionally be repeated for every upstream release between the last import and the current import. Preparing the Vendor Sources Unlike in CVS where only the needed parts were imported into the vendor tree to avoid bloating the main tree, Subversion is able to store a full distribution in the vendor tree. So, import everything, but merge only what is required. A svn add is required to add any files that were added since the last vendor import, and svn rm is required to remove any that were removed since. Preparing sorted lists of the contents of the vendor tree and of the sources that are about to be imported is recommended, to facilitate the process. &prompt.user; cd vendor/pf/dist &prompt.user; svn list -R | grep -v '/$' | sort >../old &prompt.user; cd ../pf-4.3 &prompt.user; find . -type f | cut -c 3- | sort >../new With these two files, comm -23 ../old ../new will list removed files (files only in old), while comm -13 ../old ../new will list added files only in new. Importing into the Vendor Tree Now, the sources must be copied into dist and the svn add and svn rm commands should be used as needed: &prompt.user; cd vendor/pf/pf-4.3 &prompt.user; tar cf - . | tar xf - -C ../dist &prompt.user; cd ../dist &prompt.user; comm -23 ../old ../new | xargs svn rm &prompt.user; comm -13 ../old ../new | xargs svn --parents add If any directories were removed, they will have to be svn rmed manually. Nothing will break if they are not, but they will remain in the tree. Check properties on any new files. All text files should have svn:eol-style set to native. All binary files should have svn:mime-type set to application/octet-stream unless there is a more appropriate media type. Executable files should have svn:executable set to *. No other properties should exist on any file in the tree. Committing is now possible, however it is good practice to make sure that everything is OK by using the svn stat and svn diff commands. Tagging Once committed, vendor releases should be tagged for future reference. The best and quickest way to do this is directly in the repository: &prompt.user; svn cp svn+ssh://svn.freebsd.org/base/vendor/pf/dist svn+ssh://svn.freebsd.org/base/vendor/pf/4.3 Once that is complete, svn up the working copy of vendor/pf to get the new tag, although this is rarely needed. If creating the tag in the working copy of the tree, svn:mergeinfo results must be removed: &prompt.user; cd vendor/pf &prompt.user; svn cp dist 4.3 &prompt.user; svn propdel svn:mergeinfo -R 4.3 Merging to Head &prompt.user; cd head/contrib/pf &prompt.user; svn up &prompt.user; svn merge --accept=postpone svn+ssh://svn.freebsd.org/base/vendor/pf/dist . The --accept=postpone tells Subversion that it should not complain because merge conflicts will be taken care of manually. It is necessary to resolve any merge conflicts. This process is the same in SVN as in CVS. Make sure that any files that were added or removed in the vendor tree have been properly added or removed in the main tree. To check diffs against the vendor branch: &prompt.user; svn diff --no-diff-deleted --old=svn+ssh://svn.freebsd.org/base/vendor/pf/dist --new=. The --no-diff-deleted tells Subversion not to complain about files that are in the vendor tree but not in the main tree, i.e., things that would have previously been removed before the vendor import, like for example the vendor's makefiles and configure scripts. Using CVS, once a file was off the vendor branch, it was not able to be put back. With Subversion, there is no concept of on or off the vendor branch. If a file that previously had local modifications, to make it not show up in diffs in the vendor tree, all that has to be done is remove any left-over cruft like &os; version tags, which is much easier. If any changes are required for the world to build with the new sources, make them now, and keep testing until everything builds and runs perfectly. Committing the Vendor Import Committing is now possible! Everything must be committed in one go. If done properly, the tree will move from a consistent state with old code, to a consistent state with new code. From Scratch Importing into the Vendor Tree This section is an example of importing and tagging byacc into head. First, prepare the directory in vendor: &prompt.user; svn co --depth immediates $FSVN/vendor &prompt.user; cd vendor &prompt.user; svn mkdir byacc &prompt.user; svn mkdir byacc/dist Now, import the sources into the dist directory. Once the files are in place, svn add the new ones, then svn commit and tag the imported version. To save time and bandwidth, direct remote committing and tagging is possible: &prompt.user; svn cp -m "Tag byacc 20120115" $FSVN/vendor/byacc/dist $FSVN/vendor/byacc/20120115 Merging to <literal>head</literal> Due to this being a new file, copy it for the merge: &prompt.user; svn cp -m "Import byacc to contrib" $FSVN/vendor/byacc/dist $FSVN/head/contrib/byacc Working normally on newly imported sources is still possible. Reverting a Commit Reverting a commit to a previous version is fairly easy: &prompt.user; svn merge -r179454:179453 ROADMAP.txt &prompt.user; svn commit Change number syntax, with negative meaning a reverse change, can also be used: &prompt.user; svn merge -c -179454 ROADMAP.txt &prompt.user; svn commit This can also be done directly in the repository: &prompt.user; svn merge -r179454:179453 svn+ssh://svn.freebsd.org/base/ROADMAP.txt It is important to ensure that the mergeinfo is correct when reverting a file in order to permit svn mergeinfo --eligible to work as expected. Reverting the deletion of a file is slightly different. Copying the version of the file that predates the deletion is required. For example, to restore a file that was deleted in revision N, restore version N-1: &prompt.user; svn copy svn+ssh://svn.freebsd.org/base/ROADMAP.txt@179454 &prompt.user; svn commit or, equally: &prompt.user; svn copy svn+ssh://svn.freebsd.org/base/ROADMAP.txt@179454 svn+ssh://svn.freebsd.org/base Do not simply recreate the file manually and svn add it—this will cause history to be lost. Fixing Mistakes While we can do surgery in an emergency, do not plan on having mistakes fixed behind the scenes. Plan on mistakes remaining in the logs forever. Be sure to check the output of svn status and svn diff before committing. Mistakes will happen but, they can generally be fixed without disruption. Take a case of adding a file in the wrong location. The right thing to do is to svn move the file to the correct location and commit. This causes just a couple of lines of metadata in the repository journal, and the logs are all linked up correctly. The wrong thing to do is to delete the file and then svn add an independent copy in the correct location. Instead of a couple of lines of text, the repository journal grows an entire new copy of the file. This is a waste. Setting up a <application>svnsync</application> Mirror You probably do not want to do this unless there is a good reason for it. Such reasons might be to support many multiple local read-only client machines, or if your network bandwidth is limited. Starting a fresh mirror from empty would take a very long time. Expect a minimum of 10 hours for high speed connectivity. If you have international links, expect this to take 4 to 10 times longer. A far better option is to grab a seed file. It is large (~1GB) but will consume less network traffic and take less time to fetch than a svnsync will. This is possible in one of the following three ways: &prompt.user; rsync -va --partial --progress freefall:/home/peter/svnmirror-base-r179637.tbz2 . &prompt.user; rsync -va --partial --progress rsync://repoman.freebsd.org:50873/svnseed/svnmirror-base-r215629.tar.xz . &prompt.user; fetch ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/svnmirror-base-r221445.tar.xz Once you have the file, extract it to somewhere like home/svnmirror/base/. Then, update it, so that it fetches changes since the last revision in the archive: &prompt.user; svnsync sync file:///home/svnmirror/base You can then set that up to run from &man.cron.8;, do checkouts locally, set up a svnserve server for your local machines to talk to, etc. The seed mirror is set to fetch from svn://svn.freebsd.org/base. The configuration for the mirror is stored in revprop 0 on the local mirror. To see the configuration, try: &prompt.user; svn proplist -v --revprop -r 0 file:///home/svnmirror/base Use propset to change things. Committing High-<acronym>ASCII</acronym> Data Files that have high-ASCII bits are considered binary files in SVN, so the pre-commit checks fail and indicate that the mime-type property should be set to application/octet-stream. However, the use of this is discouraged, so please do not set it. The best way is always avoiding high-ASCII data, so that it can be read everywhere with any text editor but if it is not avoidable, instead of changing the mime-type, set the fbsd:notbinary property with propset: &prompt.user; svn propset fbsd:notbinary yes foo.data Maintaining a Project Branch A project branch is one that is synced to head (or another branch) is used to develop a project then commit it back to head. In SVN, dolphin branching is used for this. A dolphin branch is one that diverges for a while and is finally committed back to the original branch. During development code migration in one direction (from head to the branch only). No code is committed back to head until the end. Once you commit back at the end, the branch is dead (although you can have a new branch with the same name after you delete the branch if you want). As per http://people.freebsd.org/~peter/svn_notes.txt, work that is intended to be merged back into HEAD should be in base/projects/. If you are doing work that is beneficial to the &os; community in some way but not intended to be merged directly back into HEAD then the proper location is base/user/your-name/. This page contains further details. To create a project branch: &prompt.user; svn copy svn+ssh://svn.freebsd.org/base/head svn+ssh://svn.freebsd.org/base/projects/spif To merge changes from HEAD back into the project branch: &prompt.user; cd copy_of_spif &prompt.user; svn merge svn+ssh://svn.freebsd.org/base/head &prompt.user; svn commit It is important to resolve any merge conflicts before committing. Some Tips In commit logs etc., rev 179872 should be spelled r179872 as per convention. Do not remove and re-add the same file in a single commit as this will break the CVS exporter. Speeding up svn is possible by adding the following to ~/.ssh/config: Host * ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p ControlMaster auto ControlPersist yes and then typing mkdir ~/.ssh/sockets Checking out a working copy with a stock Subversion client without &os;-specific patches (OPTIONS_SET=FREEBSD_TEMPLATE) will mean that $FreeBSD$ tags will not be expanded. Once the correct version has been installed, trick Subversion into expanding them like so: &prompt.user; svn propdel -R svn:keywords . &prompt.user; svn revert -R . This will wipe out uncommitted patches. Conventions and Traditions As a new developer there are a number of things you should do first. The first set is specific to committers only. (If you are not a committer, e.g., have GNATS-only access, then your mentor needs to do these things for you.) Guidelines for Committers The .ent, .xml, and .xml files listed below exist in the &os; Documentation Project SVN repository at svn.FreeBSD.org/doc/. If you have been given commit rights to one or more of the repositories: Add your author entity to head/share/xml/authors.ent; this should be done first since an omission of this commit will cause the next commits to break the doc/ build. This is a relatively easy task, but remains a good first test of your version control skills. New files that do not have the FreeBSD=%H svn:keywords property will be rejected when attempting to commit them to the repository. Be sure to read regarding adding and removing files, in addition to verifying that ~/.subversion/config contains the necessary "auto-props" entries from auto-props.txt mentioned there. Do not forget to get mentor approval for these patches! - - Also add your author entity to - head/share/xml/developers.ent. - - Add yourself to the Developers section of the Contributors List (head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml) and remove yourself from the Additional Contributors section (head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml). Please note that entries are sorted by last name. Add an entry for yourself to head/share/xml/news.xml. Look for the other entries that look like A new committer and follow the format. You should add your PGP or GnuPG key to head/share/pgpkeys (and if you do not have a key, you should create one). Do not forget to commit the updated head/share/pgpkeys/pgpkeys.ent and head/share/pgpkeys/pgpkeys-developers.xml. Please note that entries are sorted by last name. - &a.des; has written a shell script + &a.des.email; has written a shell script (head/share/pgpkeys/addkey.sh) to make this extremely simple. See the README file for more information. It is important to have an up-to-date PGP/GnuPG key in the Handbook, since the key may be required for positive identification of a committer, e.g., by the &a.admins; for account recovery. A complete keyring of FreeBSD.org users is available for download from http://www.FreeBSD.org/doc/pgpkeyring.txt. Add an entry for yourself to src/share/misc/committers-repository.dot, where repository is either doc, ports or src, depending on the commit privileges you obtained. Some people add an entry for themselves to ports/astro/xearth/files/freebsd.committers.markers. Some people add an entry for themselves to src/usr.bin/calendar/calendars/calendar.freebsd. If you already have an account at the &os; wiki, make sure your mentor moves you from the Contributors group to the Developers group. Otherwise, consider signing up for an account so you can publish projects and ideas you are working on. Once you get access to the wiki, you may add yourself to the How We Got Here and Irc Nicks pages. If you subscribe to &a.svn-src-all.name;, &a.svn-ports-all.name; or &a.svn-doc-all.name;, you will probably want to unsubscribe to avoid receiving duplicate copies of commit messages and their followups. All src commits should go to &os.current; first before being merged to &os.stable;. No major new features or high-risk modifications should be made to the &os.stable; branch. Guidelines for Everyone Whether or not you have commit rights: Introduce yourself to the other developers, otherwise no one will have any idea who you are or what you are working on. You do not have to write a comprehensive biography, just write a paragraph or two about who you are and what you plan to be working on as a developer in &os;. (You should also mention who your mentor will be). Email this to the &a.developers; and you will be on your way! Log into hub.FreeBSD.org and create a /var/forward/user (where user is your username) file containing the e-mail address where you want mail addressed to yourusername@FreeBSD.org to be forwarded. This includes all of the commit messages as well as any other mail addressed to the &a.committers; and the &a.developers;. Really large mailboxes which have taken up permanent residence on hub often get accidentally truncated without warning, so forward it or read it and you will not lose it. Due to the severe load dealing with SPAM places on the central mail servers that do the mailing list processing the front-end server does do some basic checks and will drop some messages based on these checks. At the moment proper DNS information for the connecting host is the only check in place but that may change. Some people blame these checks for bouncing valid email. If you want these checks turned off for your email you can place a file named .spam_lover in your home directory on freefall.FreeBSD.org to disable the checks for your email. If you are a developer but not a committer, you will not be subscribed to the committers or developers mailing lists; the subscriptions are derived from the access rights. Mentors All new developers also have a mentor assigned to them for the first few months. Your mentor is responsible for teaching you the rules and conventions of the project and guiding your first steps in the developer community. Your mentor is also personally responsible for your actions during this initial period. For committers: until your mentor decides (and announces with a forced commit to access) that you have learned the ropes and are ready to commit on your own, you should not commit anything without first getting your mentor's review and approval, and you should document that approval with an Approved by: line in the commit message. Preferred License for New Files Currently the &os; Project suggests and uses the following text as the preferred license scheme: /*- * Copyright (c) [year] [your name] * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * [id for your version control system, if any] */ The &os; project strongly discourages the so-called "advertising clause" in new code. Due to the large number of contributors to the &os; project, complying with this clause for many commercial vendors has become difficult. If you have code in the tree with the advertising clause, please consider removing it. In fact, please consider using the above license for your code. The &os; project discourages completely new licenses and variations on the standard licenses. New licenses require the - approval of core@FreeBSD.org to reside in the + approval of the &a.core; to reside in the main repository. The more different licenses that are used in the tree, the more problems that this causes to those wishing to utilize this code, typically from unintended consequences from a poorly worded license. Project policy dictates that code under some non-BSD licenses must be placed only in specific sections of the repository, and in some cases, compilation must be conditional or even disabled by default. For example, the GENERIC kernel must be compiled under only licenses identical to or substantially similar to the BSD license. GPL, APSL, CDDL, etc, licensed software must not be compiled into GENERIC. Developers are reminded that in open source, getting "open" right is just as important as getting "source" right, as improper handling of intellectual property has serious consequences. Any questions or concerns should immediately be brought to the attention of the core team. Developer Relations If you are working directly on your own code or on code which is already well established as your responsibility, then there is probably little need to check with other committers before jumping in with a commit. If you see a bug in an area of the system which is clearly orphaned (and there are a few such areas, to our shame), the same applies. If, however, you are about to modify something which is clearly being actively maintained by someone else (and it is only by watching the repository-committers mailing list that you can really get a feel for just what is and is not) then consider sending the change to them instead, just as you would have before becoming a committer. For ports, you should contact the listed MAINTAINER in the Makefile. For other parts of the repository, if you are unsure who the active maintainer might be, it may help to scan the revision history to see who has - committed changes in the past. &a.fenner; has written a nice + committed changes in the past. &a.fenner.email; has written a nice shell script that can help determine who the active maintainer might be. It lists each person who has committed to a given file along with the number of commits each person has made. It can be found on freefall at ~fenner/bin/whodid. If your queries go unanswered or the committer otherwise indicates a lack of interest in the area affected, go ahead and commit it. If you are unsure about a commit for any reason at all, have it reviewed by -hackers before committing. Better to have it flamed then and there rather than when it is part of the repository. If you do happen to commit something which results in controversy erupting, you may also wish to consider backing the change out again until the matter is settled. Remember – with a version control system we can always change it back. Do not impugn the intentions of someone you disagree with. If they see a different solution to a problem than you, or even a different problem, it is not because they are stupid, because they have questionable parentage, or because they are trying to destroy your hard work, personal image, or &os;, but simply because they have a different outlook on the world. Different is good. Disagree honestly. Argue your position from its merits, be honest about any shortcomings it may have, and be open to seeing their solution, or even their vision of the problem, with an open mind. Accept correction. We are all fallible. When you have made a mistake, apologize and get on with life. Do not beat up yourself, and certainly do not beat up others for your mistake. Do not waste time on embarrassment or recrimination, just fix the problem and move on. Ask for help. Seek out (and give) peer reviews. One of the ways open source software is supposed to excel is in the number of eyeballs applied to it; this does not apply if nobody will review code. GNATS The &os; Project utilizes GNATS for tracking bugs and change requests. Be sure that if you commit a fix or suggestion found in a GNATS PR, you use edit-pr pr-number on freefall to close it. It is also considered nice if you take time to close any PRs associated with your commits, if appropriate. You can also make use of &man.send-pr.1; yourself for proposing any change which you feel should probably be made, pending a more extensive peer-review first. You can find out more about GNATS at: &os; Problem Report Handling Guidelines http://www.FreeBSD.org/support.html &man.send-pr.1; You can run a local copy of GNATS, and then integrate the &os; GNATS tree by creating an rsync mirror. Then you can run GNATS commands locally, allowing you to query the PR database without an Internet connection. Mirroring the GNATS Tree It is possible to mirror the GNATS database by installing net/rsync, and executing: &prompt.user; rsync -va rsync://bit0.us-west.freebsd.org/FreeBSD-bit/gnats . Useful Tools Other than edit-pr there are a collection of tools in ~gnats/tools/ on freefall which can make working with PRs much easier. open-pr, close-pr, take-pr, and feedback-pr take PR numbers as arguments and then ask you to select from a preexisting list of change reasons or let you type in your own. change-pr is a multi purpose tool that lets you make multiple changes at the same time with one command. For example, to assign PR 123456 to yourself type take-pr 123456. If you want to set the PR to patched awaiting an MFC at the same time use: change-pr -t -p -m "awaiting MFC" 123456 Who's Who Besides the repository meisters, there are other &os; project members and teams whom you will probably get to know in your role as a committer. Briefly, and by no means all-inclusively, these are: &a.doceng; doceng is the group responsible for the documentation build infrastructure, approving new documentation committers, and ensuring that the &os; website and documentation on the FTP site is up to date with respect to the CVS tree. It is not a conflict resolution body. The vast majority of documentation related discussion takes place on the &a.doc;. More details regarding the doceng team can be found in its charter. Committers interested in contributing to the documentation should familiarize themselves with the Documentation Project Primer. - &a.ru; + &a.ru.email; Ruslan is Mister &man.mdoc.7;. If you are writing a manual page and need some advice on the structure, or the markup, ask Ruslan. - &a.bde; + &a.bde.email; Bruce is the Style Police-Meister. When you do a commit that could have been done better, Bruce will be there to tell you. Be thankful that someone is. Bruce is also very knowledgeable on the various standards applicable to &os;. - &team.re; + &a.re.members.email; These are the members of the &a.re;. This team is responsible for setting release deadlines and controlling the release process. During code freezes, the release engineers have final authority on all changes to the system for whichever branch is pending release status. If there is something you want merged from &os.current; to &os.stable; (whatever values those may have at any given time), these are the people to talk to about it. Hiroki is also the keeper of the release documentation (src/release/doc/*). If you commit a change that you think is worthy of mention in the release notes, please make sure he knows about it. Better still, send him a patch with your suggested commentary. - &a.des; + &a.des.email; Dag-Erling is the &os; Security Officer and oversees the &a.security-officer;. - &a.wollman; + &a.wollman.email; If you need advice on obscure network internals or are not sure of some potential change to the networking subsystem you have in mind, Garrett is someone to talk to. Garrett is also very knowledgeable on the various standards applicable to &os;. &a.committers; &a.svn-src-all.name;, &a.svn-ports-all.name; and &a.svn-doc-all.name; are the mailing lists that the version control system uses to send commit messages to. You should never send email directly to these lists. You should only send replies to this list when they are short and are directly related to a commit. &a.developers; All committers are subscribed to -developers. This list was created to be a forum for the committers community issues. Examples are Core voting, announcements, etc. The &a.developers; is for the exclusive use of &os; committers. In order to develop &os;, committers must have the ability to openly discuss matters that will be resolved before they are publicly announced. Frank discussions of work in progress are not suitable for open publication and may harm &os;. All &os; committers are reminded to obey the copyright of the original author(s) of &a.developers; mail. Do not publish or forward messages from the &a.developers; outside the list membership without permission of all of the authors. Copyright violators will be removed from the &a.developers;, resulting in a suspension of commit privileges. Repeated or flagrant violations may result in permanent revocation of commit privileges. This list is not intended as a place for code reviews or a replacement for the &a.arch;. In fact using it as such hurts the &os; Project as it gives a sense of a closed list where general decisions affecting all of the &os; using community are made without being open. Last, but not least never, never ever, email the &a.developers; and CC:/BCC: another &os; list. Never, ever email another &os; email list and CC:/BCC: the &a.developers;. Doing so can greatly diminish the benefits of this list. SSH Quick-Start Guide If you do not wish to type your password in every time you use &man.ssh.1;, and you use RSA or DSA keys to authenticate, &man.ssh-agent.1; is there for your convenience. If you want to use &man.ssh-agent.1;, make sure that you run it before running other applications. X users, for example, usually do this from their .xsession or .xinitrc. See &man.ssh-agent.1; for details. Generate a key pair using &man.ssh-keygen.1;. The key pair will wind up in your $HOME/.ssh/ directory. Send your public key ($HOME/.ssh/id_dsa.pub or $HOME/.ssh/id_rsa.pub) to the person setting you up as a committer so it can be put into the yourlogin file in /etc/ssh-keys/ on freefall. Now you should be able to use &man.ssh-add.1; for authentication once per session. This will prompt you for your private key's pass phrase, and then store it in your authentication agent (&man.ssh-agent.1;). If you no longer wish to have your key stored in the agent, issuing ssh-add -d will remove it. Test by doing something such as ssh freefall.FreeBSD.org ls /usr. For more information, see security/openssh, &man.ssh.1;, &man.ssh-add.1;, &man.ssh-agent.1;, &man.ssh-keygen.1;, and &man.scp.1;. &coverity.prevent; Availability for &os; Committers In January 2006, the &os; Foundation obtained a license for &coverity.prevent; from &coverity; Ltd. With this donation, all &os; developers can obtain access to Coverity Prevent analysis results of all &os; Project software. &os; developers who are interested in obtaining access to the analysis results of the automated Coverity Prevent runs, can find out more by logging into freefall and reading the relevant bits of the files: /usr/local/coverity/coverity_license.txt The license terms to which the &os; developers will have to agree in order to use &coverity.prevent; analysis results. /usr/local/coverity/coverity_announcement.txt The announcement posted to the developers' mailing list of the &os; Project. It contains useful information about the &os; Foundation and &coverity; Ltd., as well as signup information for registering with the &coverity.prevent; installation of the &os; Cluster. After reading and understanding the license terms of coverity_license.txt, all &os; developers who are interested in using the analysis results of &coverity.prevent; should read this file. /usr/local/coverity/coverity_readme.txt A short guide about fixes which are committed to the &os; source tree after being detected by &coverity.prevent; and analyzed by a &os; developer. The &os; Wiki includes a mini-guide for developers who are interested in working with the &coverity.prevent; analysis reports: . Please note that this mini-guide is only readable by &os; developers, so if you cannot access this page, you will have to ask someone to add you to the appropriate Wiki access list. Finally, all &os; developers who are going to use &coverity.prevent; are always encouraged to ask for more details and usage information, by posting any questions to the mailing list of the &os; developers. The &os; Committers' Big List of Rules Respect other committers. Respect other contributors. Discuss any significant change before committing. Respect existing maintainers (if listed in the MAINTAINER field in Makefile or in the MAINTAINER file in the top-level directory). Any disputed change must be backed out pending resolution of the dispute if requested by a maintainer. Security related changes may override a maintainer's wishes at the Security Officer's discretion. Changes go to &os.current; before &os.stable; unless specifically permitted by the release engineer or unless they are not applicable to &os.current;. Any non-trivial or non-urgent change which is applicable should also be allowed to sit in &os.current; for at least 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the &os.stable; branch as outlined for the maintainer in rule #5. Do not fight in public with other committers; it looks bad. If you must strongly disagree about something, do so only in private. Respect all code freezes and read the committers and developers mailing lists in a timely manner so you know when a code freeze is in effect. When in doubt on any procedure, ask first! Test your changes before committing them. Do not commit to anything under the src/contrib, src/crypto, or src/sys/contrib trees without explicit approval from the respective maintainer(s). As noted, breaking some of these rules can be grounds for suspension or, upon repeated offense, permanent removal of commit privileges. Individual members of core have the power to temporarily suspend commit privileges until core as a whole has the chance to review the issue. In case of an emergency (a committer doing damage to the repository), a temporary suspension may also be done by the repository meisters. Only a 2/3 majority of core has the authority to suspend commit privileges for longer than a week or to remove them permanently. This rule does not exist to set core up as a bunch of cruel dictators who can dispose of committers as casually as empty soda cans, but to give the project a kind of safety fuse. If someone is out of control, it is important to be able to deal with this immediately rather than be paralyzed by debate. In all cases, a committer whose privileges are suspended or revoked is entitled to a hearing by core, the total duration of the suspension being determined at that time. A committer whose privileges are suspended may also request a review of the decision after 30 days and every 30 days thereafter (unless the total suspension period is less than 30 days). A committer whose privileges have been revoked entirely may request a review after a period of 6 months has elapsed. This review policy is strictly informal and, in all cases, core reserves the right to either act on or disregard requests for review if they feel their original decision to be the right one. In all other aspects of project operation, core is a subset of committers and is bound by the same rules. Just because someone is in core this does not mean that they have special dispensation to step outside any of the lines painted here; core's special powers only kick in when it acts as a group, not on an individual basis. As individuals, the core team members are all committers first and core second. Details Respect other committers. This means that you need to treat other committers as the peer-group developers that they are. Despite our occasional attempts to prove the contrary, one does not get to be a committer by being stupid and nothing rankles more than being treated that way by one of your peers. Whether we always feel respect for one another or not (and everyone has off days), we still have to treat other committers with respect at all times, on public forums and in private email. Being able to work together long term is this project's greatest asset, one far more important than any set of changes to the code, and turning arguments about code into issues that affect our long-term ability to work harmoniously together is just not worth the trade-off by any conceivable stretch of the imagination. To comply with this rule, do not send email when you are angry or otherwise behave in a manner which is likely to strike others as needlessly confrontational. First calm down, then think about how to communicate in the most effective fashion for convincing the other person(s) that your side of the argument is correct, do not just blow off some steam so you can feel better in the short term at the cost of a long-term flame war. Not only is this very bad energy economics, but repeated displays of public aggression which impair our ability to work well together will be dealt with severely by the project leadership and may result in suspension or termination of your commit privileges. The project leadership will take into account both public and private communications brought before it. It will not seek the disclosure of private communications, but it will take it into account if it is volunteered by the committers involved in the complaint. All of this is never an option which the project's leadership enjoys in the slightest, but unity comes first. No amount of code or good advice is worth trading that away. Respect other contributors. You were not always a committer. At one time you were a contributor. Remember that at all times. Remember what it was like trying to get help and attention. Do not forget that your work as a contributor was very important to you. Remember what it was like. Do not discourage, belittle, or demean contributors. Treat them with respect. They are our committers in waiting. They are every bit as important to the project as committers. Their contributions are as valid and as important as your own. After all, you made many contributions before you became a committer. Always remember that. Consider the points raised under and apply them also to contributors. Discuss any significant change before committing. The repository is not where changes should be initially submitted for correctness or argued over, that should happen first in the mailing lists and the commit should only happen once something resembling consensus has been reached. This does not mean that you have to ask permission before correcting every obvious syntax error or manual page misspelling, simply that you should try to develop a feel for when a proposed change is not quite such a no-brainer and requires some feedback first. People really do not mind sweeping changes if the result is something clearly better than what they had before, they just do not like being surprized by those changes. The very best way of making sure that you are on the right track is to have your code reviewed by one or more other committers. When in doubt, ask for review! Respect existing maintainers if listed. Many parts of &os; are not owned in the sense that any specific individual will jump up and yell if you commit a change to their area, but it still pays to check first. One convention we use is to put a maintainer line in the Makefile for any package or subtree which is being actively maintained by one or more people; see http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/policies.html for documentation on this. Where sections of code have several maintainers, commits to affected areas by one maintainer need to be reviewed by at least one other maintainer. In cases where the maintainer-ship of something is not clear, you can also look at the repository logs for the file(s) in question and see if someone has been working recently or predominantly in that area. Other areas of &os; fall under the control of someone who manages an overall category of &os; evolution, such as internationalization or networking. See http://www.FreeBSD.org/administration.html for more information on this. Any disputed change must be backed out pending resolution of the dispute if requested by a maintainer. Security related changes may override a maintainer's wishes at the Security Officer's discretion. This may be hard to swallow in times of conflict (when each side is convinced that they are in the right, of course) but a version control system makes it unnecessary to have an ongoing dispute raging when it is far easier to simply reverse the disputed change, get everyone calmed down again and then try to figure out what is the best way to proceed. If the change turns out to be the best thing after all, it can be easily brought back. If it turns out not to be, then the users did not have to live with the bogus change in the tree while everyone was busily debating its merits. People very rarely call for back-outs in the repository since discussion generally exposes bad or controversial changes before the commit even happens, but on such rare occasions the back-out should be done without argument so that we can get immediately on to the topic of figuring out whether it was bogus or not. Changes go to &os.current; before &os.stable; unless specifically permitted by the release engineer or unless they are not applicable to &os.current;. Any non-trivial or non-urgent change which is applicable should also be allowed to sit in &os.current; for at least 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the &os.stable; branch as outlined in rule #5. This is another do not argue about it issue since it is the release engineer who is ultimately responsible (and gets beaten up) if a change turns out to be bad. Please respect this and give the release engineer your full cooperation when it comes to the &os.stable; branch. The management of &os.stable; may frequently seem to be overly conservative to the casual observer, but also bear in mind the fact that conservatism is supposed to be the hallmark of &os.stable; and different rules apply there than in &os.current;. There is also really no point in having &os.current; be a testing ground if changes are merged over to &os.stable; immediately. Changes need a chance to be tested by the &os.current; developers, so allow some time to elapse before merging unless the &os.stable; fix is critical, time sensitive or so obvious as to make further testing unnecessary (spelling fixes to manual pages, obvious bug/typo fixes, etc.) In other words, apply common sense. Changes to the security branches (for example, RELENG_7_0) must be approved by a member of the &a.security-officer;, or in some cases, by a member of the &a.re;. Do not fight in public with other committers; it looks bad. If you must strongly disagree about something, do so only in private. This project has a public image to uphold and that image is very important to all of us, especially if we are to continue to attract new members. There will be occasions when, despite everyone's very best attempts at self-control, tempers are lost and angry words are exchanged. The best thing that can be done in such cases is to minimize the effects of this until everyone has cooled back down. That means that you should not air your angry words in public and you should not forward private correspondence to public mailing lists or aliases. What people say one-to-one is often much less sugar-coated than what they would say in public, and such communications therefore have no place there - they only serve to inflame an already bad situation. If the person sending you a flame-o-gram at least had the grace to send it privately, then have the grace to keep it private yourself. If you feel you are being unfairly treated by another developer, and it is causing you anguish, bring the matter up with core rather than taking it public. Core will do its best to play peace makers and get things back to sanity. In cases where the dispute involves a change to the codebase and the participants do not appear to be reaching an amicable agreement, core may appoint a mutually-agreeable 3rd party to resolve the dispute. All parties involved must then agree to be bound by the decision reached by this 3rd party. Respect all code freezes and read the committers and developers mailing list on a timely basis so you know when a code freeze is in effect. Committing unapproved changes during a code freeze is a really big mistake and committers are expected to keep up-to-date on what is going on before jumping in after a long absence and committing 10 megabytes worth of accumulated stuff. People who abuse this on a regular basis will have their commit privileges suspended until they get back from the &os; Happy Reeducation Camp we run in Greenland. When in doubt on any procedure, ask first! Many mistakes are made because someone is in a hurry and just assumes they know the right way of doing something. If you have not done it before, chances are good that you do not actually know the way we do things and really need to ask first or you are going to completely embarrass yourself in public. There is no shame in asking how in the heck do I do this? We already know you are an intelligent person; otherwise, you would not be a committer. Test your changes before committing them. This may sound obvious, but if it really were so obvious then we probably would not see so many cases of people clearly not doing this. If your changes are to the kernel, make sure you can still compile both GENERIC and LINT. If your changes are anywhere else, make sure you can still make world. If your changes are to a branch, make sure your testing occurs with a machine which is running that code. If you have a change which also may break another architecture, be sure and test on all supported architectures. Please refer to the &os; Internal Page for a list of available resources. As other architectures are added to the &os; supported platforms list, the appropriate shared testing resources will be made available. Do not commit to anything under the src/contrib, src/crypto, and src/sys/contrib trees without explicit approval from the respective maintainer(s). The trees mentioned above are for contributed software usually imported onto a vendor branch. Committing something there, even if it does not take the file off the vendor branch, may cause unnecessary headaches for those responsible for maintaining that particular piece of software. Thus, unless you have explicit approval from the maintainer (or you are the maintainer), do not commit there! Please note that this does not mean you should not try to improve the software in question; you are still more than welcome to do so. Ideally, you should submit your patches to the vendor. If your changes are &os;-specific, talk to the maintainer; they may be willing to apply them locally. But whatever you do, do not commit there by yourself! Contact the &a.core; if you wish to take up maintainership of an unmaintained part of the tree. Policy on Multiple Architectures &os; has added several new architecture ports during recent release cycles and is truly no longer an &i386; centric operating system. In an effort to make it easier to keep &os; portable across the platforms we support, core has developed the following mandate:

Our 32-bit reference platform is &arch.i386;, and our 64-bit reference platform is &arch.sparc64;. Major design work (including major API and ABI changes) must prove itself on at least one 32-bit and at least one 64-bit platform, preferably the primary reference platforms, before it may be committed to the source tree.

The &arch.i386; and &arch.sparc64; platforms were chosen due to being more readily available to developers and as representatives of more diverse processor and system designs - big versus little endian, register file versus register stack, different DMA and cache implementations, hardware page tables versus software TLB management etc. The &arch.ia64; platform has many of the same complications that &arch.sparc64; has, but is still limited in availability to developers. We will continue to re-evaluate this policy as cost and availability of the 64-bit platforms change. Developers should also be aware of our Tier Policy for the long term support of hardware architectures. The rules here are intended to provide guidance during the development process, and are distinct from the requirements for features and architectures listed in that section. The Tier rules for feature support on architectures at release-time are more strict than the rules for changes during the development process. Other Suggestions When committing documentation changes, use a spell checker before committing. For all SGML docs, you should also verify that your formatting directives are correct by running make lint. For all on-line manual pages, run manck (from ports) over the manual page to verify all of the cross references and file references are correct and that the man page has all of the appropriate MLINKs installed. Do not mix style fixes with new functionality. A style fix is any change which does not modify the functionality of the code. Mixing the changes obfuscates the functionality change when asking for differences between revisions, which can hide any new bugs. Do not include whitespace changes with content changes in commits to doc/ or www/. The extra clutter in the diffs makes the translators' job much more difficult. Instead, make any style or whitespace changes in separate commits that are clearly labeled as such in the commit message. Deprecating Features When it is necessary to remove functionality from software in the base system the following guidelines should be followed whenever possible: Mention is made in the manual page and possibly the release notes that the option, utility, or interface is deprecated. Use of the deprecated feature generates a warning. The option, utility, or interface is preserved until the next major (point zero) release. The option, utility, or interface is removed and no longer documented. It is now obsolete. It is also generally a good idea to note its removal in the release notes. Support for Multiple Architectures &os; is a highly portable operating system intended to function on many different types of hardware architectures. Maintaining clean separation of Machine Dependent (MD) and Machine Independent (MI) code, as well as minimizing MD code, is an important part of our strategy to remain agile with regards to current hardware trends. Each new hardware architecture supported by &os; adds substantially to the cost of code maintenance, toolchain support, and release engineering. It also dramatically increases the cost of effective testing of kernel changes. As such, there is strong motivation to differentiate between classes of support for various architectures while remaining strong in a few key architectures that are seen as the &os; target audience. Statement of General Intent The &os; Project targets "production quality commercial off-the-shelf (COTS) workstation, server, and high-end embedded systems". By retaining a focus on a narrow set of architectures of interest in these environments, the &os; Project is able to maintain high levels of quality, stability, and performance, as well as minimize the load on various support teams on the project, such as the ports team, documentation team, security officer, and release engineering teams. Diversity in hardware support broadens the options for &os; consumers by offering new features and usage opportunities (such as support for 64-bit CPUs, use in embedded environments, etc.), but these benefits must always be carefully considered in terms of the real-world maintenance cost associated with additional platform support. The &os; Project differentiates platform targets into four tiers. Each tier includes a specification of the requirements for an architecture to be in that tier, as well as specifying the obligations of developers with regards to the platform. In addition, a policy is defined regarding the circumstances required to change the tier of an architecture. Tier 1: Fully Supported Architectures Tier 1 platforms are fully supported by the security officer, release engineering, and toolchain maintenance staff. New features added to the operating system must be fully functional across all Tier 1 architectures for every release (features which are inherently architecture-specific, such as support for hardware device drivers, may be exempt from this requirement). In general, all Tier 1 platforms must have build and Tinderbox support either in the FreeBSD.org cluster, or be easily available for all developers. Embedded platforms may substitute an emulator available in the &os; cluster for actual hardware. Tier 1 architectures are expected to be Production Quality with respects to all aspects of the &os; operating system, including installation and development environments. Tier 1 architectures are expected to be completely integrated into the source tree and have all features necessary to produce an entire system relevant for that target architecture. Tier 1 architectures generally have at least 6 active developers. Tier 1 architectures are expected to be fully supported by the ports system. All the ports should build on a Tier 1 platform, or have the appropriate filters to prevent the inappropriate ones from building there. The packaging system must support all Tier 1 architectures. To ensure an architecture's Tier 1 status, proponents of that architecture must show that all relevant packages can be built on that platform. Tier 1 embedded architectures must be able to cross-build packages on at least one other Tier 1 architecture. The packages must be the most relevant for the platform, but may be a non-empty subset of those that build natively. Tier 1 architectures must be fully documented. All basic operations need to be covered by the handbook or other documents. All relevant integration documentation must also be integrated into the tree, or readily available. Current Tier 1 platforms are &arch.i386; and &arch.amd64;. Tier 2: Developmental Architectures Tier 2 platforms are not supported by the security officer and release engineering teams. Platform maintainers are responsible for toolchain support in the tree. The toolchain maintainer is expected to work with the platform maintainers to refine these changes. Major new toolchain components are allowed to break support for Tier 2 architectures if the &os;-local changes have not been incorporated upstream. The toolchain maintainers are expected to provide prompt review of any proposed changes and cannot block, through their inaction, changes going into the tree. New features added to &os; should be feasible to implement on these platforms, but an implementation is not required before the feature may be added to the &os; source tree. New features that may be difficult to implement on Tier 2 architectures should provide a means of disabling them on those architectures. The implementation of a Tier 2 architecture may be committed to the main &os; tree as long as it does not interfere with production work on Tier 1 platforms, or substantially with other Tier 2 platforms. Before a Tier 2 platform can be added to the &os; base source tree, the platform must be able to boot multi-user on actual hardware. Generally, there must be at least three active developers working on the platform. Tier 2 architectures are usually systems targeted at Tier 1 support, but that are still under development. Architectures reaching end of life may also be moved from Tier 1 status to Tier 2 status as the availability of resources to continue to maintain the system in a Production Quality state diminishes. Well supported niche architectures may also be Tier 2. Tier 2 architectures may have some support for them integrated into the ports infrastructure. They may have cross compilation support added, at the discretion of portmgr. Some ports must built natively into packages if the package system supports that architecture. If not integrated into the base system, some external patches for the architecture for ports must be available. Tier 2 architectures can be integrated into the &os; handbook. The basics for how to get a system running must be documented, although not necessarily for every single board or system a Tier 2 architecture supports. The supported hardware list must exist and should be no more than a couple of months old. It should be integrated into the &os; documentation. Current Tier 2 platforms are &arch.arm;, &arch.ia64;, &arch.pc98;, &arch.powerpc;, and &arch.sparc64;. Tier 3: Experimental Architectures Tier 3 platforms are not supported by the security officer and release engineering teams. At the discretion of the toolchain maintainer, they may be supported in the toolchain. Tier 3 platforms are architectures in the early stages of development, for non-mainstream hardware platforms, or which are considered legacy systems unlikely to see broad future use. New Tier 3 systems will not be committed to the base source tree. Support for Tier 3 systems may be worked on in the &os; Perforce Repository, providing source control and easier change integration from the main &os; tree. Platforms that transition to Tier 3 status may be removed from the tree if they are no longer actively supported by the &os; developer community at the discretion of the release engineer. Tier 3 platforms may have ports support, either integrated or external, but do not require it. Tier 3 platforms must have the basics documented for how to build a kernel and how to boot it on at least one target hardware or emulation environment. This documentation need not be integrated into the &os; tree. Current Tier 3 platforms are &arch.mips; and &s390;. Tier 4: Unsupported Architectures Tier 4 systems are not supported in any form by the project. All systems not otherwise classified into a support tier are Tier 4 systems. Policy on Changing the Tier of an Architecture Systems may only be moved from one tier to another by approval of the &os; Core Team, which shall make that decision in collaboration with the Security Officer, Release Engineering, and toolchain maintenance teams. Ports Specific FAQ Adding a New Port How do I add a new port? First, please read the section about repository copies. The easiest way to add a new port is to use the addport script from your machine (located in the ports/Tools/scripts directory). It will add a port from the directory you specify, determining the category automatically from the port Makefile. It will also add an entry to the port's category Makefile. It was written by - &a.mharo;, &a.will;, and &a.garga;. When sending + &a.mharo.email;, &a.will.email;, and &a.garga.email;. + When sending questions about this script to the &a.ports;, please - also CC &a.crees;, the current maintainer. + also CC &a.crees.email;, the current maintainer. Any other things I need to know when I add a new port? Check the port, preferably to make sure it compiles and packages correctly. This is the recommended sequence: &prompt.root; make install &prompt.root; make package &prompt.root; make deinstall &prompt.root; pkg_add package you built above &prompt.root; make deinstall &prompt.root; make reinstall &prompt.root; make package The Porters Handbook contains more detailed instructions. Use &man.portlint.1; to check the syntax of the port. You do not necessarily have to eliminate all warnings but make sure you have fixed the simple ones. If the port came from a submitter who has not contributed to the Project before, add that person's name to the Additional Contributors section of the &os; Contributors List. Close the PR if the port came in as a PR. To close a PR, just do edit-pr PR# on freefall and change the state from open to closed. You will be asked to enter a log message and then you are done. Removing an Existing Port How do I remove an existing port? First, please read the section about repository copies. Before you remove the port, you have to verify there are no other ports depending on it. Make sure there is no dependency on the port in the ports collection: The port's PKGNAME should appear in exactly one line in a recent INDEX file. No other ports should contain any reference to the port's directory or PKGNAME in their Makefiles Then, remove the port: Remove the port's files via svn remove. Remove the SUBDIR listing of the port in the parent directory Makefile. Add an entry to ports/MOVED. Remove the port from ports/LEGAL if it is there. Alternatively, you can use the rmport script, from ports/Tools/scripts. - This script was written by &a.vd;. When sending + This script was written by &a.vd.email;. When sending questions about this script to the &a.ports;, please - also CC &a.crees;, the current maintainer. + also CC &a.crees.email;, the current maintainer. Re-adding a Deleted Port How do I re-add a deleted port? This is essentially the reverse of deleting a port. Figure out when the port was removed. Use this list and then copy the last living revision of the port: &prompt.user; cd /usr/ports/category &prompt.user; svn cp 'svn+ssh://svn.freebsd.org/ports/category/portname/@{YYYY-MM-DD}' portname Pick a date that is before the removal but after the last true commit. Perform whatever changes are necessary to make the port work again. If it was deleted because the distfiles are no longer available you will need to volunteer to host them yourself, or find someone else to do so. svn add or svn remove any appropriate files. Restore the SUBDIR listing of the port in the parent directory Makefile, and delete the entry from ports/MOVED. If the port had an entry in ports/LEGAL, restore it. svn commit these changes, preferably in one step. addport now detects when the port to add has previously existed, and should handle all except the ports/LEGAL step automatically. Repository Copies When do we need a repository copy? When you want to add a port that is related to any port that is already in the tree in a separate directory, you have to do a repository copy. Here related means it is a different version or a slightly modified version. Examples are print/ghostscript* (different versions) and x11-wm/windowmaker* (English-only and internationalized version). Another example is when a port is moved from one subdirectory to another, or when you want to change the name of a directory because the author(s) renamed their software even though it is a descendant of a port already in a tree. What do I need to do? With Subversion, a repo copy can be done by any committer: Doing a repo copy: First make sure that you were using an up to date ports tree and the target directory does not exist. Use svn move or svn copy to do the repo copy. Upgrade the copied port to the new version. Remember to change the LATEST_LINK so there are no duplicate ports with the same name. In some rare cases it may be necessary to change the PORTNAME instead of LATEST_LINK, but this should only be done when it is really needed — e.g., using an existing port as the base for a very similar program with a different name, or upgrading a port to a new upstream version which actually changes the distribution name, like the transition from textproc/libxml to textproc/libxml2. In most cases, changing LATEST_LINK should suffice. Add the new subdirectory to the SUBDIR listing in the parent directory Makefile. You can run make checksubdirs in the parent directory to check this. If the port changed categories, modify the CATEGORIES line of the port's Makefile accordingly Add an entry to ports/MOVED, if you remove the original port. Commit all changes on one commit. A forced commit is no longer needed with Subversion. When removing a port: Perform a thorough check of the ports collection for any dependencies on the old port location/name, and update them. Running grep on INDEX is not enough because some ports have dependencies enabled by compile-time options. A full grep -r of the ports collection is recommended. Remove the old port and the old SUBDIR entry. Add an entry to ports/MOVED. After repo moves (rename operations where a port is copied and the old location is removed): Follow the same steps that are outlined in the previous two entries, to activate the new location of the port and remove the old one. Ports Freeze What is a ports freeze? Before a release, it is necessary to restrict commits to the ports tree for a short period of time while the packages and the release itself are being built. This is to ensure consistency among the various parts of the release, and is called the ports freeze. For more information on the background and policies surrounding a ports freeze, see the Portmgr Quality Assurance page. What is a ports slush or feature freeze? During a release cycle the ports tree may be in a slush state instead of in a hard freeze. The goal during a slush is to reach a stable ports tree to avoid rebuilding large sets of packages for the release and to tag the tree. During this time sweeping changes are prohibited unless specifically permitted by portmgr. Complete details about what qualifies as a sweeping change can be found on the Portmgr Implementation page. The benefit of a slush as opposed to a complete freeze is that it allows maintainers to continue adding new ports, making routine version updates, and bug fixes to most existing ports, as long as the number of affected ports is minimal. For example, updating the shared library version on a port that many other ports depend on. How long is a ports freeze or slush? A freeze only lasts long enough to tag the tree. A slush usually lasts a week or two, but may last longer. What does it mean to me? During a ports freeze, you are not allowed to commit anything to the tree without explicit approval from the Ports Management Team. Explicit approval here means that you send a patch to the Ports Management Team for review and get a reply saying, Go ahead and commit it. Not everything is allowed to be committed during a freeze. Please see the Portmgr Quality Assurance page for more information. Note that you do not have implicit permission to fix a port during the freeze just because it is broken. During a ports slush, you are still allowed to commit but you must exercise more caution in what you commit. Furthermore a special note (typically Feature Safe: yes) must be added to the commit message. How do I know when the ports slush starts? The Ports Management Team will send out warning messages to the &a.ports; and &a.committers; announcing the start of the impending release, usually two or three weeks in advance. The exact starting time will not be determined until a few days before the actual release. This is because the ports slush has to be synchronized with the release, and it is usually not known until then when exactly the release will be rolled. When the slush starts, there will be another announcement to the &a.ports; and &a.committers;, of course. How do I know when the freeze or slush ends? A few hours after the release, the Ports Management Team will send out a mail to the &a.ports; and &a.committers; announcing the end of the ports freeze or slush. Note that the release being cut does not automatically indicate the end of the freeze. We have to make sure there will be no last minute snafus that result in an immediate re-rolling of the release. Creating a New Category What is the procedure for creating a new category? Please see Proposing a New Category in the Porter's Handbook. Once that procedure has been followed and the PR has been assigned to &a.portmgr;, it is their decision whether or not to approve it. If they do, it is their responsibility to do the following: Perform any needed moves. (This only applies to physical categories.) Update the VALID_CATEGORIES definition in ports/Mk/bsd.port.mk. Assign the PR back to you. What do I need to do to implement a new physical category? Upgrade each moved port's Makefile. Do not connect the new category to the build yet. To do this, you will need to: Change the port's CATEGORIES (this was the point of the exercise, remember?) The new category should be listed first. This will help to ensure that the PKGORIGIN is correct. Run a make describe. Since the top-level make index that you will be running in a few steps is an iteration of make describe over the entire ports hierarchy, catching any errors here will save you having to re-run that step later on. If you want to be really thorough, now might be a good time to run &man.portlint.1;. Check that the PKGORIGINs are correct. The ports system uses each port's CATEGORIES entry to create its PKGORIGIN, which is used to connect installed packages to the port directory they were built from. If this entry is wrong, common port tools like &man.pkg.version.1; and &man.portupgrade.1; fail. To do this, use the chkorigin.sh tool, as follows: env PORTSDIR=/path/to/ports sh -e /path/to/ports/Tools/scripts/chkorigin.sh. This will check every port in the ports tree, even those not connected to the build, so you can run it directly after the move operation. Hint: do not forget to look at the PKGORIGINs of any slave ports of the ports you just moved! On your own local system, test the proposed changes: first, comment out the SUBDIR entries in the old ports' categories' Makefiles; then enable building the new category in ports/Makefile. Run make checksubdirs in the affected category directories to check the SUBDIR entries. Next, in the ports/ directory, run make index. This can take over 40 minutes on even modern systems; however, it is a necessary step to prevent problems for other people. Once this is done, you can commit the updated ports/Makefile to connect the new category to the build and also commit the Makefile changes for the old category or categories. Add appropriate entries to ports/MOVED. Update the documentation by modifying the following: the list of categories in the Porter's Handbook www/en/ports/categories. Note that these are now displayed by sub-groups, as specified in www/en/ports/categories.descriptions. (Note: these are in the docs, not the ports, repository). If you are not a docs committer, you will need to submit a PR for this. Only once all the above have been done, and no one is any longer reporting problems with the new ports, should the old ports be deleted from their previous locations in the repository. It is not necessary to manually update the ports web pages to reflect the new category. This is now done automatically via your change to www/en/ports/categories and the daily automated rebuild of INDEX. What do I need to do to implement a new virtual category? This is much simpler than a physical category. You only need to modify the following: the list of categories in the Porter's Handbook www/en/ports/categories Miscellaneous Questions How do I know if my port is building correctly or not? First, go check . There you will find error logs from the latest package building runs on all supported platforms for the most recent branches. However, just because the port does not show up there does not mean it is building correctly. (One of the dependencies may have failed, for instance.) The relevant directories are available on pointyhat under /a/portbuild/<arch>/<major_version> so feel free to dig around. Each architecture and version has the following subdirectories: errors error logs from latest <major_version> run on <arch> logs all logs from latest <major_version> run on <arch> packages packages from latest <major_version> run on <arch> bak/errors error logs from last complete <major_version> run on <arch> bak/logs all logs from last complete <major_version> run on <arch> bak/packages packages from last complete <major_version> run on <arch> Basically, if the port shows up in packages, or it is in logs but not in errors, it built fine. (The errors directories are what you get from the web page.) I added a new port. Do I need to add it to the INDEX? No, INDEX is no longer stored in the SVN repository. The file can either be generated by running make index, or a pre-generated version can be downloaded with make fetchindex. Are there any other files I am not allowed to touch? Any file directly under ports/, or any file under a subdirectory that starts with an uppercase letter (Mk/, Tools/, etc.). In particular, the Ports Management Team is very protective of ports/Mk/bsd.port*.mk so do not commit changes to those files unless you want to face his wra(i)th. What is the proper procedure for updating the checksum for a port's distfile when the file changes without a version change? When the checksum for a port's distfile is updated due to the author updating the file without changing the port's revision, the commit message should include a summary of the relevant diffs between the original and new distfile to ensure that the distfile has not been corrupted or maliciously altered. If the current version of the port has been in the ports tree for a while, a copy of the old distfile will usually be available on the ftp servers; otherwise the author or maintainer should be contacted to find out why the distfile has changed. Issues Specific to Developers Who Are Not Committers A few people who have access to the &os; machines do not have commit bits. For instance, the project is willing to give access to the GNATS database to contributors who have shown interest and dedication in working on Problem Reports. Almost all of this document will apply to these developers as well (except things specific to commits and the mailing list memberships that go with them). In particular, we recommend that you read: Administrative Details Conventions You should get your mentor to add you to the Additional Contributors (doc/en_US.ISO8859-1/articles/contributors/contrib.additional.xml), if you are not already listed there. Developer Relations SSH Quick-Start Guide The &os; Committers' Big List of Rules Information About &ga; As of December 12, 2012, &ga; was enabled on the &os; Project website to collect anonymized usage statistics regarding usage of the site. The information collected is valuable to the &os; Documentation Project, in order to identify various problems on the &os; website. &ga; General Policy The &os; Project takes visitor privacy very seriously. As such, the &os; Project website honors the Do Not Track header before fetching the tracking code from Google. For more information, please see the &os; Privacy Policy. &ga; access is not arbitrarily allowed — access must be requested, voted on by the &a.doceng;, and explicitly granted. Requests for &ga; data must include a specific purpose. For example, a valid reason for requesting access would be to see the most frequently used web browsers when viewing &os; web pages to ensure page rendering speeds are acceptable. Conversely, to see what web browsers are most frequently used (without stating why) would be rejected. All requests must include the timeframe for which the data would be required. For example, it must be explicitly stated if the requested data would be needed for a timeframe covering a span of 3 weeks, or if the request would be one-time only. Any request for &ga; data without a clear, reasonable reason beneficial to the &os; Project will be rejected. Data Available Through &ga; A few examples of the types of &ga; data available include: Commonly used web browsers Page load times Site access by language Perks of the Job Unfortunately, there are not many perks involved with being a committer. Recognition as a competent software engineer is probably the only thing that will be of benefit in the long run. However, there are at least some perks: Free 4-CD and DVD Sets &os; committers can get a free 4-CD or DVD set at conferences from &os; Mall, Inc.. The sets are no longer available as a subscription due to the high shipment costs to countries outside the USA. Freenode IRC Cloaks &os; developers may request a cloaked hostmask for their account on the Freenode IRC network in the form of freebsd/developer/freefall name or freebsd/developer/NickServ name. To request a cloak, send an email to - &a.eadler; with your requested hostmask and NickServ + &a.eadler.email; with your requested hostmask and NickServ account name. Miscellaneous Questions Why are trivial or cosmetic changes to files on a vendor branch a bad idea? From now on, every new vendor release of that file will need to have patches merged in by hand. From now on, every new vendor release of that file will need to have patches verified by hand. How do I add a new file to a branch? To add a file onto a branch, simply checkout or update to the branch you want to add to and then add the file using the add operation as you normally would. This works fine for the doc and ports trees. The src tree uses SVN and requires more care because of the mergeinfo properties. See section 1.4.6 of the Subversion Primer for details. Refer to SubversionPrimer/Merging for details on how to perform an MFC. What meta information should I include in a commit message? As well as including an informative message with each commit you may need to include some additional information as well. This information consists of one or more lines containing the key word or phrase, a colon, tabs for formatting, and then the additional information. The key words or phrases are: PR: The problem report (if any) which is affected (typically, by being closed) by this commit. Submitted by: The name and e-mail address of the person that submitted the fix; for committers, just the username on the &os; cluster. Reviewed by: The name and e-mail address of the person or people that reviewed the change; for committers, just the username on the &os; cluster. If a patch was submitted to a mailing list for review, and the review was favorable, then just include the list name. Approved by: The name and e-mail address of the person or people that approved the change; for committers, just the username on the &os; cluster. It is customary to get prior approval for a commit if it is to an area of the tree to which you do not usually commit. In addition, during the run up to a new release all commits must be approved by the release engineering team. If these are your first commits then you should have passed them past your mentor first, and you should list your mentor, as in ``username-of-mentor (mentor)''. Obtained from: The name of the project (if any) from which the code was obtained. MFC after: If you wish to receive an e-mail reminder to MFC at a later date, specify the number of days, weeks, or months after which an MFC is planned. Security: If the change is related to a security vulnerability or security exposure, include one or more references or a description of the issue. Commit Log for a Commit Based on a PR You want to commit a change based on a PR submitted by John Smith containing a patch. The end of the commit message should look something like this. ... PR: foo/12345 Submitted by: John Smith <John.Smith@example.com> Commit Log for a Commit Needing Review You want to change the virtual memory system. You have posted patches to the appropriate mailing list (in this case, freebsd-arch) and the changes have been approved. ... Reviewed by: -arch Commit Log for a Commit Needing Approval You want to commit a change to a section of the tree with a MAINTAINER assigned. You have collaborated with the listed MAINTAINER, who has told you to go ahead and commit. ... Approved by: abc Where abc is the account name of the person who approved. Commit Log for a Commit Bringing in Code from OpenBSD You want to commit some code based on work done in the OpenBSD project. ... Obtained from: OpenBSD Commit Log for a Change to &os.current; with a Planned Commit to &os.stable; to Follow at a Later Date. You want to commit some code which will be merged from &os.current; into the &os.stable; branch after two weeks. ... MFC after: 2 weeks Where 2 is the number of days, weeks, or months after which an MFC is planned. The weeks option may be day, days, week, weeks, month, months, or may be left off (in which case, days will be assumed). In some cases you may need to combine some of these. Consider the situation where a user has submitted a PR containing code from the NetBSD project. You are looking at the PR, but it is not an area of the tree you normally work in, so you have decided to get the change reviewed by the arch mailing list. Since the change is complex, you opt to MFC after one month to allow adequate testing. The extra information to include in the commit would look something like PR: foo/54321 Submitted by: John Smith <John.Smith@example.com> Reviewed by: -arch Obtained from: NetBSD MFC after: 1 month How do I access people.FreeBSD.org to put up personal or project information? people.FreeBSD.org is the same as freefall.FreeBSD.org. Just create a public_html directory. Anything you place in that directory will automatically be visible under . Where are the mailing list archives stored? The mailing lists are archived under /g/mail which will show up as /hub/g/mail with &man.pwd.1;. This location is accessible from any machine on the &os; cluster. I would like to mentor a new committer. What process do I need to follow? See the New Account Creation Procedure document on the internal pages.

diff --git a/en_US.ISO8859-1/articles/console-server/article.xml b/en_US.ISO8859-1/articles/console-server/article.xml index b0c78d3ef3..1360b58373 100644 --- a/en_US.ISO8859-1/articles/console-server/article.xml +++ b/en_US.ISO8859-1/articles/console-server/article.xml @@ -1,1476 +1,1476 @@

Console Server Gregory Bond

gnb@itga.com.au

&tm-attrib.freebsd; &tm-attrib.cisco; &tm-attrib.intel; &tm-attrib.lantronix; &tm-attrib.microsoft; &tm-attrib.opengroup; &tm-attrib.sun; &tm-attrib.general; $FreeBSD$ $FreeBSD$ This document describes how you can use &os; to set up a console server. A console server is a machine that you can use to monitor the consoles of many other machines, instead of a bunch of serial terminals. console-server The Problem You have a computer room with lots of &unix; server machines and lots of communications hardware. Each of these machines needs a serial console. But serial terminals are hard to find and quite expensive (especially compared to a much more capable PC). And they take up a lot of precious space in the computer room. You need access to the console because when things break, that is where error messages go. And some tasks have to be done on the console (e.g. boot problems or OS installs/upgrades). Some &unix; systems allow the console to break out to the ROM monitor which can sometimes be the only way to unstick a hung machine. This is often done with a LINE BREAK sent on the console serial port. If we are going to play about with consoles, then there are a couple of other things that would be great: Remote access. Even in the same office, it would be convenient to access all the consoles from your desk without walking into the computer room. But often the machines are off-site, perhaps even in another country. Logging. If something has gone wrong, you would like to be able to have a look at the previous console output to see what is up. Ordinary console screens give you the last 25 lines. More would be better. Network Independence. The solution needs to work even if the network is down. After all, a failed network is when you need consoles the most! Even better is network independence with remote access. No single-point failure. A console system that crashes every machine when it fails is no use. This is particularly tricky with Sun &unix; hosts as they will interpret a powered-off terminal as a BREAK, and drop back to the ROM monitor. Interface with a pager or some similar alerter device. Ability to power-cycle machines remotely. Not be too expensive. Free is even better! Possible Solutions If you use PC hardware for your servers, then a so-called KVM switch is one possible solution. A KVM switch allows the use of a single keyboard, video screen and mouse for multiple boxes. This cuts down on the space problem, but only works for PC hardware (not any communications gear you might have), and is not accessible from outside the computer room. Nor does it have much scroll-back or logging, and you have to handle alerting some other way. The big downside is that it will not work for serial-only devices, such as communications hardware. This means that even with a room full of PC-based servers, you are probably still going to need some sort of serial console solution. Actually, Doug Schache has pointed out that you can get KVM switches that also do serial consoles or Sun compatible KVM switching as well as PCs, but they are expensive. See Avocent for example.) You might be tempted to do without a console terminal, but when things go pear-shaped you really need to see what is on the console. And you have to use the console to boot the machine and do things like OS upgrades or installs. You might try having a single console terminal and switching from server to server as needed, either with a serial switch or just by patching it into the required machine. Serial switches are also hard to come by and not cheap, and may cause problems with sending BREAK when they switch. And (if your computer room is anything like ours) you never seem to have the right combination of patch leads to connect to the machine you need to, and even if the leads are there you can never work out exactly which combination of DTE/DCE headshells goes with which lead goes with which hardware. So you spend the first 10 minutes fooling around with breakout boxes and a box of leads, all while the server is down and the users are screaming. Of course this does not deal with the logging or remote access requirements. And inevitably the console is not switched to the machine you need so you lose all the console messages that might tell you what is going on. One popular solution is to use terminal server hardware. Typically, the serial ports are connected to the various machine consoles, and set up for reverse telnet access. This means a user can telnet to a given IP/port and be connected to the appropriate console. This can be very cost-effective, as suitable old terminal servers can be picked up fairly cheaply (assuming you do not have a couple lying around). And it is of course network-accessible so suitable for remote access. But it suffers from one major drawback: if the network is down, then you have no access to any console, even if you are standing right next to the machine. (This may be partially alleviated by having a suitable terminal connected to one of the terminal server ports and connecting from there, but the terminal server software may not support that.) Also there is no logging or replay of console messages. But with a bit of work, and the addition of some software such as conserver (described below), this can be made to work pretty well. A possibility suggested by Bron Gondwana is similar to the above solution. If you use servers with multiple serial ports, you can connect each spare serial port to the console port of the next server, creating a ring of console connections (in some sort of order). This can be made to work reasonably well with the aid of the conserver software, but can be a bit confusing otherwise (i.e. remembering which port is connected to which console). And you are stuck if you need to use serial ports for other things (such as modems) or you have machines without spare ports. Or, if your budget exceeds your willingness to hack, you can buy an off-the-shelf solution. These vary in price and capability. See, for example, Lightwave, Perle, Avocent or Black Box. These solutions can be quite expensive - typically $USD100 - $USD400 per port. Our Solution In light of the above requirements, we chose a solution based on a dedicated PC running &unix; with a multiport serial card, and some software designed to handle serial consoles. It includes the following elements: A surplus PC. We used a &pentium; 166, with a PCI bus, 2Gbyte hard disk and 64Mb of RAM. This is a massive overkill for this task, and P-100, 500Mb, 32Mb would be more than enough. A PC &unix; system. We used &os; 4.3 as that is used for other tasks within our office. A multi-port serial card. We chose the &easyio; PCI 8-port card from Stallion Technologies. This cost us about $AUD740, or under $100/port, from Harris Technologies (which has lots of stuff but is by no means the cheapest place in town - shop around and you might get it a lot cheaper). This card has a big DB80 connector on the back, and a cable plugs into that which has a block with 8 RJ-45 sockets on it. (We chose the RJ-45 version as our entire cable plant is RJ-45. This allows us to patch connections from the required box to the console server without any special cables.) This is the only thing we needed to buy to make this all happen. We build two servers, one for each computer room, with 8 ports in one and 16 ports (via two &easyio; PCI cards) in the other. If we needed more than 16 ports, then another of the Stallion cards would be more cost-effective. We could conceivably support 128 ports in each server (with 2 EasyConnect 8/64 host cards and 8 16 port RJ-45 modules) for about $AUD12,000. A modem for remote access to the console server host when the network is down. We have not done this yet as the computer room is next door, but when we put a server in Sydney we will add the modem. The idea is that when the network is down, you can dial up and log into the server machine and run the console program locally. For security, we will probably leave the modem powered off and ask the gopher in Sydney to turn on the well-labelled button when we need it. A program called conserver. This program does all the magic required to enable remote access to consoles, and do the replaying and logging etc. It comes in two parts: a server called conserver that runs as a daemon and connects to the serial ports, handles logging etc, and a client program called console that can connect to the server, display console messages, send keystrokes (and BREAK), etc. This design covers all the major requirements except remote power cycling: Remote access comes because the console client program works across the network. Logging is handled by the conserver program. If the network is down, then we can use the console on the PC to run the console client locally. For remote sites, we can add a modem for dial-in access to the server command line to run the client. By patching the &solaris; servers (see ), we can avoid pranging the whole computer room when the console server PC crashes (or the power supply fails, or whatever). We already have pager alerts from another system we have installed, but the console server has all the required log info so that could easily be implemented if we needed. And it even has a modem for calling the pager company! We do not currently support remote power cycling. Some versions of the conserver program support this, but it does require specialised serial-controlled power boards. We have no immediate need for remote power cycling (we have a gopher in each remote office who can do it by remote control) so this is not a major problem, and we could add it easily should we ever see the need and get the appropriate hardware. This solution was very cheap. Total cost for the 9-port server was $AUD750 for the IO card, as we re-used a surplus PC and already owned the hardware for the special cables. If we had to buy everything, then it would still only cost around $AUD1500 for the 8-port server. Setting Up The Server Checking the Stallion driver &os; has adequate support for modern Stallion cards since 4.4 release. If you are running an older version of &os;, you will need to upgrade to a more modern version of &os; (which you should do anyway, to make sure your system is not vulnerable to known security issues). See the &os; Handbook for information about updating your system. Configuring a new kernel The Stallion driver is not included in the default GENERIC kernel, so you will need to create a kernel config file with the appropriate entries. See &man.stl.4; and the appropriate section of the &os; Handbook. Making The Devices You will need to make the device notes for the Stallion card (which are not made by default). A new version of /dev/MAKEDEV with Stallion support will have been created by the mergemaster run during the above procedure. If you have a Stallion card with more than 8 ports, then you will need to edit /dev/MAKEDEV and change the definition of maxport at about line 250. By default, MAKEDEV only makes device nodes for 8 ports to keep the size of the /dev directory down. Run a command like: &prompt.root; cd /dev/ && sh MAKEDEV cuaE0 to create dial-out devices for the first Stallion card. See the comments in MAKEDEV and the &man.stl.4; man page for more details. Compiling conserver See the section on conserver versions ; the version I use is available in the &os; ports collection; however, it is not the only one.) There are two ways to install conserver. You can either compile from the source or use the &os; ports framework. Using the ports framework Using the ports is a bit cleaner, as the package system can then keep track of installed software and cleanly delete them when not being used. I recommend using the comms/conserver-com port. Change into the port directory and (as root) type: &prompt.root; make DEFAULTHOST=consolehost install where consolehost is the name of the machine running the console server. Specifying this when the binary is compiled will avoid having to either specify it each time the program is run on remote hosts or having to maintain a conserver.cf file on every host. This command will fetch, patch, configure, compile and install the conserver application. You can then run make package to create a binary package that can be installed on all the other &os; hosts with &man.pkg.add.1;. For extra style points, you can make a two versions of the package: one for the console server machine without a DEFAULTHOST argument, and one for all the other hosts with a DEFAULTHOST argument. This will mean the console client program on the console server machine will default to localhost, which will work in the absence of name servers when the network is busted, and also allow trusted (i.e. no password required) connections via the localhost IP address for users logged into the console server machine (either via the console screen or the emergency backup modem). The version for the other machines with a DEFAULTHOST argument means users can just use the console client without specifying a hostname every time, and without needing to configure the conserver.cf file on every machine. From the source tarball If you prefer, you can download conserver and compile it yourself. You might need to do this if you want to install the console client on non-&os; systems. We run the client on our &solaris; hosts and it inter-operates with the &os;-hosted server with no problems. This allows anyone in the whole company (many of whom have PCs and no &os; host access on their desk) to access the console server. Download the file from the conserver.com FTP site. Extract it into a handy directory then configure it by running &prompt.user; ./configure The argument avoids having to specify the master server every time the client is run remotely (or keeping up-to-date config files on all remote hosts). The argument avoids having to update on every machine. Then type make and, as root, make install. Configuring conserver The conserver program is configured via a file called conserver.cf. This file usually lives in /usr/local/etc and is documented in the &man.conserver.cf.5; manual page. Our config file looks like this: LOGDIR=/var/log/consoles gallows:/dev/cuaE0:9600p:&: roo:/dev/cuaE1:9600p:&: kanga:/dev/cuaE2:9600p:&: %% allow: itga.com.au trusted: 127.0.0.1 buzz The first line means all the console log files by default go into the /var/log/consoles directory. The & in each line says the log file for that machine will be /var/log/consoles/machine. The next three lines show three machines to which we need to connect. We use the cuaEx devices rather than the ttyEx devices because console ports typically do not show carrier. This means that opening ttyEx would hang and conserver would never connect. Using the cuaEx device avoids this problem. Another solution would be to use the ttyEx devices and enable soft carrier on these ports, perhaps by setting this using the ttyiEx device in the /etc/rc.serial file. See the comments in this file for more details. Also see &man.sio.4; for information on the initial-state and locked-state devices. (The Stallion driver also supports these conventions). And see the &man.stty.1; for details on setting device modes. The last section shows that any user logged into the server machine has passwordless access to all consoles. We do this because there are no user accounts on this machine and it is safely isolated from the wide world behind our firewall. The allow line allows anyone on a machine inside our organisation to access the console server if they provide their password, which is recorded in the conserver.passwd file (see next section). Setting conserver passwords The conserver.passwd file contains the encrypted version of the password that each user. The file is documented in the conserver.cf(5) manual page. The only tricky bit is loading the file with encoded passwords. It appeared in &os; that was is no obvious way to generate an encrypted password for inclusion in another file (but see below). So I put together a quick hack perl script to do this: @rands = (); foreach (0..4) { push(@rands, rand 64); } $salt = join '', ('.', '/', 0..9, 'A'..'Z', 'a'..'z')[@rands]; $salt = '$1$' . $salt . '$'; print 'Enter password: '; `stty -echo`; $cleartext = <>; `stty echo`; chop($cleartext); print crypt($cleartext, $salt), "\n"; This uses the &os; MD5-style encrypted passwords. Running this on other &unix; variants, or on &os; with DES passwords, will likely need a different style of salt. - &a.kris; has since pointed out you can get the same effect using + &a.kris.email; has since pointed out you can get the same effect using the openssl passwd command: &prompt.user; openssl passwd -1 Password: password $1$VTd27V2G$eFu23iHpLvCBM5nQtNlKj/ Starting <application>conserver</application> at system boot time There are two ways this can be done. Firstly, you could start up conserver from init by including an entry in /etc/ttys that is similar to this: cuaE0 "/usr/local/sbin/conserver" unknown on insecure This has two advantages: init will restart the master console server if it ever crashes for any reason (but we have not noticed any crashes so far), and it arranges for standard output of the conserver process to be directed to the named tty (in this case cuaE0). This is useful because you can plug a terminal into this port, and the conserver program will show all console output not otherwise captured by a client console connection. This is useful as a general monitoring tool to see if anything is going on. We set this terminal up in the computer room but visible from the main office. It is a very handy feature. The downside of running conserver from the ttys file is that it cannot run in daemon mode (else &man.init.8; would continually restart it). This means conserver will not write a PID file, which makes it hard to rotate the log files. So we start conserver from an rc.d script. If you installed conserver via the port, there will be a conserver.sh.sample file installed in /usr/local/etc/rc.d. Copy and/or rename this to conserver.sh to enable conserver to start at boot time. In fact we use a modified version of this script which also connects conserver to a terminal via a tty device so we can monitor unwatched console output. Our conserver.sh script looks like this: #!/bin/sh # # Startup for conserver # PATH=/usr/bin:/usr/local/bin case "$1" in 'start') TTY=/dev/cuaE7 conserver -d > $TTY # get NL->CR+NL mapping so msgs look right stty < /dev/cuaE7 opost onlcr echo -n ' conserver' ;; 'stop') kill `cat /var/run/conserver.pid` && echo -n ' conserver' ;; *) echo "Usage: $0 { start | stop }" ;; esac exit 0 Note the use of cuaE0 device and the need to set tty modes for proper NL-<CR handling). Keeping the log files trimmed &os; has a program called newsyslog that will automatically handle log file trimming. Just add some lines to the configuration file /etc/newsyslog.conf for the console logs: # # The log files from conserver /var/log/consoles/gallows 644 10 1000 * Z /var/run/conserver.pid /var/log/consoles/kanga 644 10 1000 * Z /var/run/conserver.pid /var/log/consoles/roo 644 10 1000 * Z /var/run/conserver.pid This tells newsyslog (which is run from cron every hour on the hour) that the console log files should be archived and compressed once they reach 1Mb, that we should keep 10 of them, and that to signal the server program you send a SIGHUP to the process whose PID is in the conserver.pid file. This is the master server, and it will arrange to signal all the child processes. Yes, this will send a HUP to all clients whenever a single log file needs rotating, but that is quite cheap. See &man.newsyslog.8; for details. Cabling This is always the hardest part of this kind of problem. We had only a dozen or so cables/headshells to build, and we already had a collection of the appropriate crimping tools and hardware, so we did it ourselves. But if you are not set up for this, or you have a large number of cables to make, then you might consider getting some cables custom made. Look in the yellow pages, there are a surprising number of places that do this! Getting custom-made cabling is good, and you can get much more professional results, but can be expensive. For example, the RJ-45 to DB-25 adapter kits described below are about $10 each; custom-made headshells are about twice that (and take a couple of weeks to arrive). Similarly, crimping custom RJ-45 to RJ-45 leads is quite cheap (say, $5 each) but it takes a fair amount of time. Custom made RJ-45 socket to RJ-45 plug converters cost about $25 each. We have settled on RJ-45 Cat-V cabling for all our office and computer room cabling needs. This included patching between racks in the computer room. For serial connections, we use patchable headshells that have RJ-45 sockets on the back. This allows us to patch whatever RJ-45–DB-25 connections we need. Which is just as well, because there are many incompatible ways to represent serial connections on the RJ-45 plug. So the cabling has to be very careful to use the right mapping. RJ-45 colors RJ-45 cables and plugs have 8 pins/conductors. These are used as 4 matched pairs. There are a couple of conventions about how the pairs are mapped onto pins, but 100baseT uses the most common (known as EIA 586B). There are three common color-coding conventions for the individual conductors in RJ-45 cables. They are:  Pin Scheme 1 Scheme 2 (EIA 568B) Scheme 3 (EIA 568A) Pair 1 Blue White+Green White+Orange 2+ 2 Orange Green Orange 2- 3 Black White+Orange White+Green 3+ 4 Red Blue Blue 1+ 5 Green White+Blue White+Blue 1- 6 Yellow Orange Green 3- 7 Brown White+Brown White+Brown 4+ 8 White or Grey Brown Brown 4-

Note EIA 468A and EIA 568B are very similar, simply swapping the colors assigned to pair 2 and pair 3. See for example the Cabletron Tech Support Site for more details. The pins in the RJ-45 plug are numbered from 1 to 8. Holding a patch lead with the cable pointing down and the clip away from you, pin 1 is at the left. Or, looking into an RJ-45 socket with the clip to the top, pin 1 is on the right. The following illustration (shamelessly lifted from the Cabletron web site above) shows it pretty well: We have four classes of equipment to deal with in our setup: Sun servers Sun servers operate as DTE (i.e. send data on TxD and read RxD, and assert DTR) with a female DB-25 socket on board. So we need to create a headshell for the Stallion that operates as DCE and has a male DB-25 plug (i.e. acts as a null modem cable as well as converts from RJ-45 to DB-25). We use headshells that have an RJ-45 socket in them and 8 short flyleads with DB-25 pins on the end. These pins can be inserted into the DB-25 plug as required. This allows us to create a custom RJ-45-DB-25 mapping. We used a couple of different sorts, including the MOD-TAP part no. 06-9888-999-00 and the FA730 series from Black Box. On our version of the headshells, these flyleads had the following colours (from Pin 1-8): Blue, Orange, Black, Red, Green, Yellow, Brown, White. (Looking into an RJ-45 socket, with the clip towards the top, pin 1 is on the right.) This is how they are connected to the DB-25 socket:  Stallion RJ-45 Pin Colour Signal Sun DB-25 Male Pin RS232 Signal 1 Blue DCD 20 DTR 2 Orange RTS 5 CTS 3 Black Chassis Gnd 1 Chassis Gnd 4 Red TxD 3 RxD 5 Green RxD 2 TxD 6 Yellow Signal Gnd 7 Signal Gnd 7 Brown CTS 4 RTS 8 White RTS 8 DCD

Note that colours may be different for your cables/headshells. In particular, pin 8 may be grey instead of white. Remember to label the headshell clearly, in a way that will not fade/fall off/rub off with time! Cisco 16xx/26xx/36xx Routers I think that all Cisco gear that has RJ-45 console ports and runs &ios; will have the same cable requirements. But best to check first. We have tried this on 1600s and 2600s only. Both the Stallion card and the 2600 have RJ-45 connections, but of course they are not compatible. So you need to crimp up a special RJ-45-RJ-45 cable. And this cable must be plugged in the right way round! We use normal RJ-45 flyleads from the router to the patch panel, then the special flylead from the patch panel to the Stallion card. We built two special Stallion-Cisco leads by cutting in half a 2m flylead and crimping an RJ-45 with the appropriate pinouts to each free end. The original connector will be the Cisco end of the cable, the new crimped connector will be the Stallion end. Holding the RJ-45 connector on the flylead with the cable pointing down and the clip pointing away, this is the order of the colours of the cables in our flylead (pins 1-8, from L to R): white/green, green, white/orange, blue, white/blue, orange, white/brown, brown. For the Stallion end, trim and discard the brown/white+brown and green/white+green pairs. Then holding the RJ-45 plug in the same manner (cable down, clip away), the connections should be (from L to R): None, None, Blue, Orange, White/Orange, White/Blue, None, None, as shown:  Cisco RJ-45 Pin Colour Cisco Signal Stallion RJ-45 Pin Stallion Signal 1 White/Green RTS N/C 2 Green DTR N/C 3 White/Orange TxD 5 RxD 4 Blue Gnd 3 Gnd 5 White/Blue Gnd 6 Gnd 6 Orange RxD 4 TxD 7 White/Brown DSR N/C 8 Brown CTS N/C

Note again that colours may be different for your cables/headshells. Carefully label the cable, and each end of the cable, and test it. If it does not work, testing is really hard as they do not make RJ-45 serial line testers! Let me state this more strongly: Be very sure that you label this cable in a way that is easily, instantly and permanently recognisable as a special cable and not easily confused with normal drop cables. Some suggestions (from Hugh Irvine): Make them out of different coloured cable. For marking the ends, clear heat-shrink tubing slipped over printed labels *before* putting on the connectors is the best way I have seen for marking what they are. You can also use Panduit or similar tags that you put on with nylon tie straps, but I find the ink wears off the tags. Cisco &catalyst; switches Astoundingly, the pinout on the console ports of the &catalyst; switches is actually different to the pinout used on the 26xx-series Cisco hardware. I think the way to tell which is which is by considering the operating software. If it uses &ios;, then the previous pinout is required. If it uses the switch software, then this pinout is required. Fortunately, while the pinouts are different, the &catalyst; pinout is simply a mirror image of the pinout for the 2600. Even more fortunately, the Ciscos (both &catalyst; switches and 2600s) seem to ship with a special rollover cable, which is exactly what is required in this case. We use the rollover cable from the &catalyst; switches to the patch panel, then the same cable as above for the 2600s from the patch panel to the Stallion card, and it all works just fine. This rollover cable is an RJ-45-RJ-45 cable and is intended to be used with the shipped (hardwired) RJ-45 - DB-25 and RJ-45–DB-9 headshells for console connections. Ours are 2m long, either light blue or black, and are quite flat. Attempts to use them for 100baseT Ethernet will fail miserably! You can tell it is a rollover cable by holding both ends with the cable pointing down and the clip pointing away from you. Check the colour of the leads in each pin in the two connectors, they should be mirror images. (In our case, one goes grey-orange-black-red-green-yellow-blue-brown, the other brown-blue-yellow-green-red-black-orange-grey). This is a rollover cable. If you do not have a rollover cable present, then you can use the same cable as for the 26xx except plug it in the other way around (i.e. original 8-pin plug goes into the Stallion, the new crimped plug with only 4 active wires goes into the &catalyst; switch). &os; servers (or any other &i386; PC systems using a serial console) We run &os; 4 on a couple of &i386; PCs for various peripheral uses. &os; usually uses a screen and keyboard for the console, but can be configured to use a serial port (usually the first serial port known as COM1 in DOS/&windows; or ttyd0 in &unix;). The cabling for these servers depends on the PC hardware. If the PC has DB-25 female socket on board (as most older PCs do), then the same headshell as works for the Sun server above will work fine. If the PC has DB-9 male plug on board (as more recent PCs tend to do), then there are two choices. Either use a DB-9 to DB-25 converter (this is not recommended as it can lead to unreliable connections over the long term as the adapter is bumped/works loose), or build an RJ-45 to DB-9 cable as follows:  Stallion RJ-45 Pin Colour Signal PC DB-9 Female Pin RS232 Signal 1 Blue DCD 4 DTR 2 Orange RTS 8 CTS 3 Black Chassis Gnd N/C 4 Red TxD 2 RxD 5 Green RxD 3 TxD 6 Yellow Signal Gnd 5 Signal Gnd 7 Brown CTS 7 RTS 8 White RTS 1 DCD

See for tips on configuring &os; to use a serial console. On Sun Systems And Break Anyone who has turned off a terminal used as a console for a Sun system will know what happens and why this is a problem. Sun hardware recognises a serial BREAK as a command to halt the OS and return to the ROM monitor prompt. A serial BREAK is an out-of-band signal on an RS-232 serial port that involves making the TX DATA line active (i.e. pulled down to less than -5V) for more than two whole character times (or about 2ms on a 9600bps line). Alas, this BREAK signal is all to easily generated by serial hardware during power-on or power-off. And the Stallion card does, in fact, generate breaks when the power to the PC fails. Unless fixed, this problem would mean that every Sun box connected to the console server would be halted whenever the power failed (due to dead power supplies, or fat-fingered operators unplugging it, or whatever). This is clearly not an acceptable situation. Fortunately, Sun have come up with a set of fixes for this. For &solaris; 2.6 and later, the kbd(1) command can be used to disable the ROM-on-BREAK behaviour. This is a good start, but leaves you out of luck in the situation where a break is needed to get into a broken machine. Starting with &solaris; 8, the kbd command can also be used to enable an alternate break sequence using the kbd -a alternate command. When this is set, the key sequence ReturnTildeCtrlB (within 5 seconds) will drop to the ROM. You can enable this permanently by editing the /etc/default/kbd file; see the kbd(1) man page. Note that this alternate break sequence is only active once the kernel has started running multiuser and processed the default file. While the ROM is active (during power-on and during the boot process) and while running single-user, you still need to use a BREAK to get to the ROM prompt. The console client can cause the server to send a BREAK using the escape sequence Esccl1. If you have a Sun software support contract, there are patches available for &solaris; 2.6 and 2.7 that add the alternate break capability integrated into &solaris; 2.8. &solaris; 2.6 requires patch 105924-10 or higher. &solaris; 2.7 requires patch 107589-02 or higher. We have added this patch to all our &solaris; 2.6 servers, and added it (and the entry in the /etc/default/kbd file) to our jumpstart configuration so it will automatically be added to every new install. We have confirmed by direct testing that neither the Cisco 16xx, 26xx, or &catalyst; hardware suffers from the BREAK sent when the Stallion card loses power. Contemporary Cisco software listens for BREAK signal only for first 30 seconds after power-on or reboot. Using a Serial Console on &os; The procedure for doing this is described in detail in the &os; Handbook. This is a quick summary. Check the kernel configuration Check that the kernel configuration file has flags 0x10 in the config line for the sio0 device. This signals this device (known as COM1 in DOS/&windows; or /dev/ttyd0 in &os;) can be used as a console. This flag is set on the GENERIC and LINT sample configs, so is likely to be set in your kernel. Create the <filename>/boot.conf</filename> file This file should be created containing a single line containing just -h (minus the quotes). This tells the &os; boot blocks to use the serial console. Edit <filename>/etc/ttys</filename> Edit this file and make the following changes. If you are not going to have any keyboard/video screen on this server at all, you should find all the lines for ttyv devices like ttyv1 "/usr/libexec/getty Pc" cons25 on secure Change the on to off. This will stop login screens being run on the useless video consoles. Find the line containing ttyd0. Change it from ttyd0 "/usr/libexec/getty std.9600" dialup off secure to ttyd0 "/usr/libexec/getty std.9600" vt100 on secure (replacing vt100 with the term type of your console. The xterms terminal type might be a good choice). This allows you to log in to the console port once the system is running multi-user. Reboot and off you go! Security Implications The client-server protocol for conserver requires the user of the console client to enter a password. This password is passed across the net in cleartext! This means conserver is not really suitable for use across untrusted networks (such as the Internet). Use of conserver-only passwords (in the conserver.passwd file) slightly mitigate this problem, but anyone sniffing a conserver connection can easily get console access, and from there prang your machine using the console break sequence. For operating across the Internet, use something secure like SSH to log into to the server machine, and run the console client there. On Conserver Versions The conserver program has fractured into a number of versions. The home page referenced below seems to be the latest and most featureful version around, and for July 2004 carries a version number of 8.1.9. This is maintained by Bryan Stansell bryan@conserver.com, who has brought together the work of many people (listed on his webpage). The &os; ports collection contains a port for version 8.5 of conserver at comms/conserver. This seems to be older and less featureful than the 8.1.9 version (in particular, it does not support consoles connected to terminal server ports and does not support a conserver.passwd file), and is written in a fairly idiosyncratic manner (using a preprocessor to generate C code). Version 8.5 is maintained by Kevin S. Braunsdorf ksb+conserver@sa.fedex.com who did most of the original work on conserver, and whose work Bryan Stansell is building on. The 8.5 version does support one feature not in the 8.1.9 version (controlling power to remote machines via a specific serial-interfaced power controller hardware). Beginning with December 2001, Brian's version (currently 8.1.9) is also presented in ports collection at comms/conserver-com. We therefore recommend you to use this version as it is much more appropriate for console server building. Links Homepage for the latest version of conserver. ftp://ftp.conserver.com/conserver/conserver-8.1.9.tar.gz The source tarball for version 8.1.9 of conserver. Homepage of Stallion Technologies. Davis Harris' Minor Scroll of Console Knowledge contains a heap of useful information on serial consoles and serial communications in general. The Greater Scroll of Console Knowledge contains even more specific information on connecting devices to various other devices. Oh the joy of standards! Doug Hughes has a similar console server, based on the screen program and an old &sunos; host. The Real Weasel company makes a ISA or PCI video card that looks like a PC video card but actually talks to a serial port. This can be used to implement serial consoles on PC hardware for operating systems that can not be forced to use serial console ports early enough. Manual Pages console(8) conserver(8) conserver.cf(5)

diff --git a/en_US.ISO8859-1/articles/contributors/article.xml b/en_US.ISO8859-1/articles/contributors/article.xml index c7c0a6fa95..6d66577526 100644 --- a/en_US.ISO8859-1/articles/contributors/article.xml +++ b/en_US.ISO8859-1/articles/contributors/article.xml @@ -1,424 +1,424 @@ %contrib.ent; ]>

Contributors to FreeBSD &tm-attrib.freebsd; &tm-attrib.sun; &tm-attrib.general; $FreeBSD$ $FreeBSD$ This article lists individuals and organizations who have made a contribution to FreeBSD. Donors Gallery As of 2010, the following section is several years out-of-date. Donations from the past several years appear here. The FreeBSD Project is indebted to the following donors and would like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine, which has replaced freefall.FreeBSD.org at one point, by donating the following items: - &a.mbarkah; and his employer, &a.mbarkah.email; and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200MHz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU - &a.dillon; + &a.dillon.email; Blue Mountain Arts Epilogue Technology Corporation - &a.sef; + &a.sef.email; Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris - &a.chuckr; + &a.chuckr.email; Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier andre.albsmeier@mchp.siemens.de Chris Silva ras@interaccess.com Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: BSDi for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. Compaq has donated a variety of Alpha systems to the FreeBSD Project. Among the many generous donations are 4 AlphaStation DS10s, an AlphaServer DS20, AlphaServer 2100s, an AlphaServer 4100, 8 500Mhz Personal Workstations, 4 433Mhz Personal Workstations, and more! These machines are used for release engineering, package building, SMP development, and general development on the Alpha architecture. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB file servers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. Chuck Robey chuckr@glue.umd.edu contributed his floppy tape streamer for experimental work. - Larry Altneu larry@ALR.COM, and &a.wilko;, + Larry Altneu larry@ALR.COM, and &a.wilko.email;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter (Deceased) contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server . Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! - Christoph Kukulies kuku@FreeBSD.org donated + &a.kuku.email; donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Mike Tancsa mike@sentex.ca donated four various ATM PCI cards in order to help increase support of these cards as well as help support the development effort of the netatm ATM stack. Special contributors: BSDi (formerly Walnut Creek CDROM) has donated almost more than we can say (see the 'About the FreeBSD Project' section of the FreeBSD Handbook for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting - &a.joerg; who has often preferred FreeBSD work over paid work, and + &a.joerg.email; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. The FreeBSD Developers These are the people who have commit privileges and do the engineering work on the FreeBSD source tree. All core team members are also developers. (in alphabetical order by last name): &contrib.committers; Core Team Alumni core team The following people were members of the FreeBSD core team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough reverse chronological order: &contrib.corealumni; Development Team Alumni development team The following people were members of the FreeBSD development team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough reverse chronological order: &contrib.develalumni; Ports Management Team Alumni portmgr team The following people were members of the FreeBSD portmgr team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough reverse chronological order: &contrib.portmgralumni; Development Team: In Memoriam development team During the many years that the FreeBSD Project has been in existence, sadly, some of our developers have passed away. Here are some remembrances. In rough reverse chronological order of their passing: &contrib.develinmemoriam; Derived Software Contributors This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially re-implemented from the 4.4BSD-Lite release provided by the Computer Science Research Group (CSRG) at the University of California, Berkeley and associated academic contributors. There are also portions of NetBSD and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): &contrib.additional; 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): &contrib.386bsd;

diff --git a/en_US.ISO8859-1/articles/contributors/contrib.additional.xml b/en_US.ISO8859-1/articles/contributors/contrib.additional.xml index 889848027c..824e8d9607 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.additional.xml +++ b/en_US.ISO8859-1/articles/contributors/contrib.additional.xml @@ -1,11165 +1,11159 @@ ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AIDA Shinra aida-s@jcom.home.ne.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Myles Landwehr aaron@snaphat.com Aaron Smith aaron@mutex.org Aaron Straup Cope ascope@cpan.org Aaron Voisine voisine@gmail.com Aaron Zauner az_mail@gmx.at Aasmund Eikli inter@o12a.com Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam C. Migus adam@migus.org Adam Glass glass@postgres.berkeley.edu Adam Herzog adam@herzogdesigns.com Adam Jette jettea46@yahoo.com Adam Kranzel adam@alameda.edu Adam McDougall mcdouga9@egr.msu.edu Adam McLaurin adam.freebsd@fastmail.fm Adam Strohl troll@digitalspark.net Adam Wight adamw@tulum.brsys.com Adoal Xu adoal@iname.com Adrian Colley aecolley@ois.ie Adrian Filipi-Martin adrian@ubergeeks.com Adrian Hall ahall@mirapoint.com Adrian Mariano adrian@cam.cornell.edu Adrian Pircalabu apircalabu@bitdefender.com Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Aftab Jahan Subedar jahan@bol-online.com Ajit Thyagarajan Akinori YAMADA yamada-a@nextcom.co.jp Akira Ikeuchi a_ikeuchi@mic.mitsumi.co.jp Akira SAWADA Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Al Hoang hoanga@mac.com Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Amesbury amesbury@indefi.net Alan Bawden alan@curry.epilogue.com Alan Snelson Alan@Wave2.co.uk Albert Graef Dr.Graef@t-online.de Aldert Nooitgedagt aldert@nooitgedagt.net Aldis Berjoza killasmurf86@gmail.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksander Fafula alex@fafula.com Aleksandr A Babaylov .@babolo.ru Aleksandr S. Goncharov mraleks@bk.ru Alex D. Chen dhchen@elearning.nsysu.edu.tw Alex Deiter tiamat@komi.mts.ru Alex G. Bulushev bag@demos.su Alex Kapranoff alex@kapranoff.ru Alex Keda admin@lissyara.su Alex Kiesel kiesel@schlund.de Alex Le Heux alexlh@funk.org Alex M alex@myzona.net Alex Miller asm@asm.kiev.ua Alex Perel veers@disturbed.net Alex Pesternikov ap@page2rss.com Alex Rodioukov simuran@shaw.ca Alex Rousskov rousskov@measurement-factory.com Alex Samorukov samm@os2.kiev.ua Alex Semenyaka alex@rinet.ru Alex Steiner ast@treibsand.com Alex Trull alexander@trull.com Alex Varju freebsd-ports@varju.ca Alex Vasylenko lxv@omut.org Alex Wilkinson alex.wilkinson@dsto.defence.gov.au Alex Zepeda garbanzo@hooked.net Alexander Bechikov goo@t72.ru - Alexander Best - arundel@FreeBSD.org + &a.arundel.email; Alexander Churanov alexanderchuranov@gmail.com Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Pereira Girald girald@etcom.ufrgs.br Alexander Grigoryev alexander.4mail@gmail.com Alexander Gromnizki gromnizki@unixdev.net Alexander Haderer alexander.haderer@charite.de Alexander Koch fbsd@meersau.de Alexander Kojevnikov alexander@kojevnikov.com Alexander Kovalenko never@nevermind.kiev.ua Alexander Novitsky alecn2002@yandex.ru Alexander Peresunko alex@freeman.org.ua Alexander Pohoyda alexander.pohoyda@gmx.net Alexander Pyhalov alp@sfedu.ru alexander smishlajev alex@ank-sia.com Alexander V. Ribchansky triosoft@triosoft.com.ua Alexander Yerenkow yerenkow@gmail.com Alexander Zagrebin alexz@visp.ru Alexander Zhuravlev zaa@zaa.pp.ru Alexandre Peixoto alexandref@tcoip.com.br Alexandre Snarskii snar@paranoia.ru Alexandros Kosiaris akosiaris+ports@gmail.com Alexey Illarionov littlesavage@rambler.ru Alexey V. Antipovsky kemm@in-line.ru Alexey V. Neyman alex.neyman@auriga.ru Alexey Y. Mikhailov karma@ez.pereslavl.ru Alexey Shuvaev shuvaev@physik.uni-wuerzburg.de Alexey Zaytsev mangoost@inetcomm.ru Alexis Yushin alexis@forest.NLnetLabs.nl Ali Mashtizadeh mashtizadeh@gmail.com Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amar Takhar verm@drunkmonk.net Amir Farah amir@comtrol.com Amir Shalem amir@boom.org.il Amarendra Godbole amarendra.godbole@gmail.com Amy Baron amee@beer.org Anthony Garcia agarcia@experts-exchange.com Anatoliy Dmytriyev tolid@plab.ku.dk Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Borodin anatoly.borodin@gmail.com Anatoly Vorobey mellon@pobox.com Anatoly Zherdev tolyar@mx.ru Anders Andersson anders@codefactory.se Anders Nor Berle debolaz@debolaz.com Anders Thulin Anders.X.Thulin@telia.se Anders Troback freebsd@troback.com Anderson S. Ferreira anderson@cnpm.embrapa.br Andi Payn andi_payn@speedymail.org Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Goeree abgoeree@uwnet.nl Andre Yelistratov andre@andre.net.ru Andrea Venturoli a.ventu@flashnet.it Andreas Berg aberg@doomnet.de Andreas Fehlner fehlner@gmx.de Andreas Fuchs asf@boinkor.net Andreas Gustafsson gson@araneus.fi Andreas Haakh ah@alman.robin.de Andreas Heil ah@linux-hq.de Andreas K Foerster akf3@akfoerster.de Andreas Kasparz andy@interface-business.de Andreas Kohn andreas@syndrom23.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Möller segfault@gmx.net Andreas Riedel rian@hrz.tu-chemnitz.de Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andrei V. Shetuhin shetuhin@corp.mail.ru Andres Vega Garcia Andrew Arensburger arensb@ooblick.com Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Greenwood greenwood.andy@gmail.com Andrew Herbert andrew@werple.apana.org.au Andrew J. Caines A.J.Caines@halplant.com Andrew J. Korty ajk@iu.edu Andrew Khlebutin andrey@hm.perm.ru Andrew Kochetkov kochetkov.andrew@gmail.com Andrew Kolchoogin andrew@rinet.ru Andrew L. Kilpatrick tiger@whitetigersd.com Andrew L. Neporada andrew@chg.ru Andrew Marks andrew@amrx.net Andrew McKay andy@openirc.co.uk Andrew McNaughton andrew@scoop.co.nz Andrew McRae amcrae@cisco.com Andrew Morton drewish@katherinehouse.com Andrew P. Lentvorski bsder@allcaps.org Andrew Predoehl predoehl@mail.kg Andrew Reilly a.reilly@lake.com Andrew Romanenko melanhit@gmail.com Andrew S. Midthune amidthune@cableone.net Andrew Shevtsov nyxo@dnuc.polyn.kiae.su Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew V. Stikheev sand@links.ru Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andrey Simonenko simon@comsys.ntu-kpi.kiev.ua Andrey Surkov nsand@sura.ru Andrey Sverdlichenko rblaze@users.sourceforge.net Andrey Tchoritch andy@venus.sympad.net Andy Farkas andyf@speednet.com.au Andy Fawcett andy@athame.co.uk Andy Gilligan andy@evo6.org Andy Kosela andy.kosela@gmail.com Andy Miller andy@trit.org Andy Newman atrn@zeta.org.au Andy Pavlo amp0928@rit.edu Andy Sparrow spadger@best.com Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Anes Muhametov anes@anes.su Angel Todorov todorov_bg@gmx.net Angelo Turetta aturetta@commit.it Anish Mistry amistry@am-productions.biz Anthony C. Chavez acc@anthonychavez.org Anthony Ginepro anthony.ginepro@laposte.net Anthony Mawer gnats@mawer.org Anthony Yee-Hang Chan yeehang@netcom.com Antoine Beaupre anarcat@anarcat.ath.cx Antoine Pelisse apelisse@gmail.com Anton Hryciuk gnixua@gmail.com Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Anton Shterenlikht mexas@bris.ac.uk Anton Voronin anton@urc.ac.ru Antonio Bonifati ant@monitor.deis.unical.it Antonio Carlos Venancio Junior antonio@php.net Antti Kaipila anttik@iki.fi Aragon Gouveia aragon@phat.za.net Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji raja@moselle.com Arjan de Vet devet@devet.nl Arnaud Berthomier oz@cyprio.net Arnaud Launay asl@launay.org Arne Henrik Juul arnej@Lise.Unit.NO Aron Schlesinger as@bsdgroup.de Aron Stansvik elvstone@gmail.com Artem Kazakov kazakov@gmail.com Artem Naluzhnyy tut@nhamon.com.ua Artem Nosov chip-set@mail.ru Ashley Penney ashp@unloved.org Ask Bjoern Hansen ask@valueclick.com Atsushi Furuta furuta@sra.co.jp Attila Nagy bra@fsn.hu Atushi Sakauchi sakauchi@yamame.to Autrijus Tang autrijus@autrijus.org Axel Gonzalez loox@e-shell.net Balázs Nagy js@iksz.hu Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Bartek Rutkowski r@robakdesign.com Bartosz Fabianowski freebsd@chillt.de Bayanzul Lodoysamba baynaa@yahoo.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson Ben Walter bwalter@itachi.swcp.com Ben Woolley ports@tautology.org Benedikt Köhler benedikt@furukama.de Beni Keller navigium@grindcore.ch Benjamin Lewis bhlewis@gte.net Benjamin Lutz benlutz@datacomm.ch Benny Kjrgaard benny@catpipe.net Benoit Calvez benoit@litchis.org Berend de Boer berend@pobox.com Bernd Luevelsmeyer bdluevel@heitec.net Bernd Rosauer br@schiele-ct.de Bill Cadwallader hurbold@yahoo.com Bill Kish kish@osf.org Bill Lloyd wlloyd@mpd.ca Bill Moran wmoran@collaborativefusion.com Bill Trost trost@cloud.rain.com Björn König bkoenig@cs.tu-berlin.de Björn Lindström bkhl@elektrubadur.se Blaz Zupan blaz@amis.net BluePex Security Solutions freebsd-ports@bluepex.com Bob Eager bob@eager.cx Bob Frazier bobf@mrp3.com Bob Van Valzah Bob@whitebarn.com Bob Willcox bob@luke.pmr.com Boris Kovalenko boris@tagnet.ru Boris Lytochkin lytboris@gmail.com Boris Staeblow balu@dva.in-berlin.de Boyd R. Faulkner faulkner@asgard.bga.com Brad Chapman chapmanb@arches.uga.edu Brad Hendrickse bradh@uunet.co.za Brad Jones brad@kazrak.com Brad Karp karp@eecs.harvard.edu Brad Lanam bll@gentoo.com Bradley Dunn bradley@dunn.org Bram Moolenaar bram@moolenaar.net Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com Brent B. Powers bbp2006@columbia.edu Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Cully shmit@kublai.com Brian Gardner brian@getsnappy.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian M. Clapper bmc@clapper.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Gaeke brg@dgate.org Brian R. Haug haug@conterra.com Brian Skrab brian@quynh-and-brian.org Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Bruno Schwander bruno@tinkerbox.org Byung-Hee HWANG bh@izb.knu.ac.kr Camson Huynh chuynh@biolateral.com.au Carey Jones mcj@acquiesce.org Carl Fongheiser kf0yn@mchsi.com Carl Makin carl@stagecraft.cx Carl Mascott cmascott@world.std.com Carl Schmidt carl@perlpimp.codersluts.net Carlos A. M. dos Santos unixmania@gmail.com Carlos Eduardo G. Carvalho cartola@openit.com.br Casper casper@acc.am Castor Fu castor@geocast.com Cédric Lamalle cedric@cedric.trix.net Cezary Morga cm@therek.net Chad Castleberry crcastle@ius.edu Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu Charles Swiger chuck@pkix.net Cheng-Tao Lin b89605222@ntu.edu.tw ChenGuang LI horus.li@gmail.com Chess Griffin chess@chessgriffin.com Chet Ramey chet@odin.INS.CWRU.Edu Chi-Feng QU chifeng@gmail.com Chia-Hsing Yu davidyu@ucsd.edu Chia-liang Kao clkao@CirX.ORG Chiang Cheng-Hsiung elvis@sslab.cs.ccu.edu.tw Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus Choe, Cheng-Dae whitekid@netian.com Chris Burkert chris@chrisburkert.de Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Howells howells@kde.org Chris Jones chris.jones@ualberta.ca Chris Knight chris@e-easy.com.au Chris Larsen darth@vader.dk Chris Laverdure dashevil@gmail.com Chris Pepper pepper@mail.rockefeller.edu Chris Petrik c.petrik.sosa@gmail.com Chris Pressey chris_pressey@yahoo.ca Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Torek torek@ee.lbl.gov Christian Gusenbauer c47g@gmx.at Christian Haury Christian.Haury@sagem.fr Christian Heckendorf heckend@bu.edu Christian Lackas delta@lackas.net Christian Laursen xi@borderworlds.dk Christian Schade christian.schade@interface-projects.de Christian Zander zander@minion.de - Christoph P. Kukulies - kuku@FreeBSD.org + &a.kuku.email; Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christophe Juniet cjuniet@entreview.com Christopher Boumenot boumenot@gmail.com Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher Illies christopher.illies@ki.se Christopher J. Ruwe cjr@cruwe.de Christopher K. Davis ckd-freebsd@ckdhr.com Christopher Key cjk32@cam.ac.uk Christopher Knaust jigboe@gmx.de Christopher N. Harrell cnh@ivmg.net Christopher Nehren apeiron@comcast.net Christopher Preston rbg@gayteenresource.org Christopher T. Johnson cjohnson@neunacht.netgsi.com Christopher Vance vance@aurema.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Clayton Rollins crollins666@hotmail.com Clement MOULIN moeti-freebsd@ouestil.com Cliff Rowley dozprompt@onsea.com Clive Crous clive@darkarts.co.za Colman Reilly careilly@tcd.ie Conor McDermottroe ports@mcdermottroe.com Conrad Sabatier conrads@cox.net Constantin S. Svintsoff kostik@iclub.nsu.ru Coranth Gryphon gryphon@healer.com Corey Smith corsmith@gmail.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cosmin Stroe cstroe1@uic.edu Cove Schneider cove@brazil.nbn.com Craig Boston craig@yekse.gank.org Craig Butler craig001@lerwick.hopto.org Craig Leres leres@ee.lbl.gov Craig Loomis Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Cristiano Rolim Pereira cristianorolim@hotmail.com Curt Mayer curt@toad.com Cyril Guibourg aragorn+ports@teaser.fr Cyrille Lefevre clefevre@citeweb.net Cyrus Rahman cr@jcmax.com Daan Vreeken Danovitsch@Vitsch.net Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Aoyama aoyama@peach.ne.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Gerow dgerow@afflictions.org Damian Hamill damian@cablenet.net Damien Tougas damien@tougas.net Dan Angelescu mrhsaacdoh@yahoo.com Dan Caescu daniel@freebsd.ro Dan Cross tenser@spitfire.ecsel.psu.edu Dan Langille dan@freebsddiary.org Dan Lukes dan@obluda.cz Dan Nelson dnelson@allantgroup.com Dan Papasian bugg@bugg.strangled.net Dan Pelleg dpelleg+unison@cs.cmu.edu Dan Piponi wmtop@tanelorn.demon.co.uk Dan Rench citric@cubicone.tmetic.com Dan Smith dan@algenta.com Dan Walters hannibal@cyberstation.net Daniel B. Hemmerich dan@spot.org Daniel Blankensteiner db@TruNet.dk Daniel Bretoi daniel@netwalk.org Daniel Bryan sisko@bsdmail.com Daniel Hagan dhagan@acm.vt.edu Daniel Levai leva@ecentrum.hu Daniel J. O'Connor darius@dons.net.au Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Daniel Roethlisberger daniel@roe.ch Daniel W. McRobb dwm@caimis.com Daniel W. Steinbrook dsteinbr@fas.harvard.edu Daniel Wijnands daniel@itxl.nl Danilo Egêa Gondolfo danilogondolfo@gmail.com Danny Braniss danny@cs.huji.ac.il Danny Egen Danny Howard dannyman@toldme.com Danny J. Zerkel dzerkel@phofarm.com Danny Pansters danny@ricin.com Dario Freni saturnero@gufi.org Darren Pilgrim ports.maintainer@evilphi.com Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com - Dave Tweten - tweten@FreeBSD.org + &a.tweten.email; David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@eece.unm.edu David Borman dab@bsdi.com David Bremner bremner@unb.ca David Bushong david+ports@bushong.net David Chaplin-Loebell direct@klatha.com David Dawes dawes@XFree86.org David Demelier markand@malikania.fr David Filo David G. Holm harbour@netfang.net David Gardner david@pinko.net David Gilbert dave@daveg.ca David H. Munro munro1@llnl.gov David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Johnson david@usermode.org David Jones dej@qpoint.torfree.net David Julien david.julien@gmail.com David K. Gerry David.K.Gerry@GMail.com David Kelly dkelly@tomcat1.tbe.com David Kirchner dpk@dpk.net David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Landgren david@landgren.net David Lay dsl@webize.com.au David Le Brun david@trucs.org David Leonard d@scry.dstc.edu.au David Magda dmagda@magda.ca David Muir Sharnoff muir@idiom.com David Otto ottodavid@gmx.net David Quattlebaum drq@drqware.com David Romano unobe@cpan.org David S. Miller davem@jenolan.rutgers.edu David Siebörger drs@rucus.ru.ac.za David Sugar dyfet@gnu.org David Syphers dsyphers@u.washington.edu David Sze dsze@alumni.uwaterloo.ca David Terry dterry@digifonica.com David Vachulka arch_dvx@users.sourceforge.net David Wolfskill david@catwhisker.org David Yeske dyeske@yahoo.com Dax Labrador semprix@bsdmail.org Dean Gaudet dgaudet@arctic.org Dean Hollister dean@odyssey.apana.org.au Dean Huxley dean@fsa.ca Denis Barov dindin@dindin.ru Denis Fortin Denis Generalov gd@rambler-co.ru> Denis Philippov for_spam@mezon.ru Denis E. Podolskiy bytestore@yandex.ru Denis Pokataev catone@cpan.org Denis Shaposhnikov dsh@vlink.ru Dennis Cabooter dennis@rootxs.org Dennis Glatting dennis.glatting@software-munitions.com Dennis S. Davidoff null@cvs.1system.ru Denton Gentry denny1@home.com Derek Inksetter derek@saidev.com Derik van Zuetphen dz@426.ch Dermot Tynan dtynan@kalopa.com Diego Depaoli trebestie@gmail.com Dikshie dikshie@lapi.itb.ac.id Dikshie dikshie@sfc.wide.ad.jp Dierk Sacher dierk@blaxxtarz.de Dirk Gouders gouders@et.bocholt.fh-gelsenkirchen.de Dirk Jagdmann doj@cubic.org Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dirk-Willem van Gulik dirkx@webweaving.org Dishanker Rajakulendren draj@oceanfree.net Ditesh Shashikant Gathani ditesh@gathani.org Dmitri Nikulin setagllib@optusnet.com.au Dmitriy Limonov earl1k@mail.ru Dmitry A. Yanko fm@astral.ntu-kpi.kiev.ua Dmitry Afanasiev KOT@MATPOCKuH.Ru Dmitry Dyomin old@old.com.ua Dmitry Karasik dmitry@karasik.eu.org Dmitry Kazarov d.y.kazarov@mail.ru Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dmitry Pryadko d.pryadko@rambler-co.ru Dmitry Semkin ds@tic-tac.ru Dmitry V. Sukhodoyev raven428@gmail.com Dmytro Rud unixoid@yahoo.com Dom Mitchell dom@myrddin.demon.co.uk Domas Mituzas midom@dammit.lt Dominic Fandrey lon_kamikaze@gmx.de Dominic Marks dominic_marks@btinternet.com Dominic Mitchell dom@happygiraffe.net Dominik Brettnacher domi@saargate.de Dominik Rothert dr@domix.de Dominique Goncalves dominique.goncalves@gmail.com Don Croyle croyle@gelemna.org Don Morrison dmorrisn@u.washington.edu Don Owens don@regexguy.com - &a.whiteside; + &a.whiteside.email; Don Yuniskis dgy@rtd.com Donald Maddox dmaddox099@yahoo.com Donn Miller dmmiller@cvzoom.net Doug Harple dharple@nycap.rr.com Doug Penner darwinsurvivor@gmail.com Douglas A. Maske maske@rungepaper.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Douglas K. Rand rand@meridian-enviro.com Douglas W. Thrift douglas@douglasthrift.net Drew Derbyshire ahd@kew.com Dustin Sallings dustin@spy.net Dylan Carlson absinthe@retrovertigo.com Dylan Simon dylan@dylex.net ELISA Font Project Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Ederson de Moura ederbs@ederbs.org Edgardo Garcia Hoeffler edybsd@yahoo.com.ar Edmondas Girkantas eg@fbsd.lt Eduard Martinescu martines@rochester.rr.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp Eijiro Shibusawa ej-sib@ice.uec.ac.jp Eike Bernhardt eike.bernhardt@gmx.de Eintisy Chuang eintisy@gmail.com Elias Mandouvalos ocean@mail.gr Elisey Savateev b3k@mail.ru Elmar Bartel bartel@informatik.tu-muenchen.de Emily Boyd emily@emilyboyd.com Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eric@talesfromthereal.com Eric Anderson anderson@centtech.com Eric Blood eblood@cs.unr.edu Eric Cronin ecronin@eecs.umich.edu Eric D. Futch efutch@nyct.net Eric F. Crist ecrist@secure-computing.net Eric Freeman freebsdports@chillibear.com Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric Kjeldergaard kjelderg@gmail.com Eric L. Hernes erich@lodgenet.com Eric Masson e-masson@kisoft-services.com Eric Ogren eogren@stanford.edu Eric P. Scott eps@sirius.com Eric S. Van Gyzen esv@vangyzen.net Eric Schnoebelen eric@cirr.com Eric Shao-yu Cheng eric@fractal.csie.org Eric Sprinkle eric@ennovatenetworks.com Eric W. Bates ericx@vineyard.net Eric Yu ericyu@mail2000.com.tw Eric van Gyzen vangyzen@stat.duke.edu Erich Stefan Boleyn erich@uruk.org Erich Zigler erich@tacni.net Erik E. Rantapaa rantapaa@math.umn.edu Erik Greenwald erik@smluc.org Erik H. Bakke erikhb@bgnett.no Erik H. Moe ehm@cris.com Erik L. Chen d9364104@mail.nchu.edu.tw Ernie Smallis esmallis@stbernard.com Ernst Winter (Deceased) Espen Skoglund esk@ira.uka.de Espen Tagestad espen@tagestad.no Eugene Grosbein eugen@grosbein.pp.ru Eugene M. Kim astralblue@usa.net Eugene Ossintsev eugos@gmx.net Eugene Radchenko genie@qsar.chem.msu.su Eugene Ray pal@paladin7.net Eugeney Ryzhyk rzheka@users.sourceforge.net Eugeny Kuzakov CoreDumped@coredumped.null.ru Evan Champion evanc@synapse.net Evan Sarmiento esarmiento@wayfair.com Evgueni V. Gavrilov aquatique@rusunix.org Ewgenij Gawrilow gawrilow@math.tu-berlin.de FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp Fabian Keil fk@fabiankeil.de Fabian M. Borschel fmb@onibox.net Fabien Devaux fab@gcu.info Fabio Tosques fabio.tosques@rz.hu-berlin.de Fanying Jen fanying@fynet.com Faried Nawaz fn@Hungry.COM Fernan Aguero fernan@iib.unsam.edu.ar Fernando Apesteguia fernando.apesteguia@gmail.com Ferruccio Vitale vitale@cs.tin.it Filipe Rocha filiperocha@gmail.com Filippo Natali filippo@widestore.net Flemming Jacobsen fj@batmule.dk Florian Unglaub usenet04@rootofallevil.net Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Francisco Cabrita include@npf.pt.freebsd.org Francisco Gomez francisco@gomezmarin.com Francisco Reyes fjrm@yahoo.com François Tamone tamone@eig.unige.ch Frank Bartels knarf@camelot.de Frank Behrens frank@pinky.sax.de Frank Börner frank-freebsd@online.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Denis j@pureftpd.org Frank Gründer elwood@mc5sys.in-berlin.de Frank MacLachlan fpm@n2.net Frank Mayhar frank@exit.com Frank Nobis fn@Radio-do.de Frank Ruell stoerte@dreamwarrior.net Frank Steinborn steinex@nognu.de Frank Volf volf@oasis.IAEhv.nl Frank Wall fw@moov.de Frank W. Josellis frank@dynamical-systems.org Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Franz Klammer klammer@webonaut.com Fraser Tweedale frase@frase.id.au Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Freddie Cash fcash@bigfoot.com Frederic Dubuy fdubuy@free.fr Frédéric Praca frederic.praca@freebsd-fr.org Frederick Earl Gray fgray@rice.edu Fredrik Lindberg fli@shapeshifter.se Frerich Raabe frerich.raabe@gmx.de Fumihiko Kimura jfkimura@yahoo.co.jp Fuyuhiko Maruyama fuyuhik8@is.titech.ac.jp - &a.stanislav; + &a.stanislav.email; Gábor Kincses gabor@acm.org Gábor Zahemszky zgabor@CoDe.hu Gasol Wu gasol.wu@gmail.com Gareth McCaughan gjm11@dpmms.cam.ac.uk Garrett Rooney rooneg@electricjellyfish.net Gary A. Browning gab10@griffcd.amdahl.com Gary Hayers gary@hayers.org Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gautam Mani execve@gmail.com Gavin Mu gavin@FreeBSDChina.org Gea-Suan Lin gslin@gslin.org Geoff Glasson g_glasson@jimali.dyndns.org Geoff Rehmet csgr@alpha.ru.ac.za Geoffrey Mainland mainland@apeiron.net Geoffroy Rivat grivat@sicfa.net Georg Graf georg@graf.priv.at Georg Wagner georg.wagner@ubs.com George Hartzell hartzell@kestrel.alerce.com George Liaskos geo.liaskos@gmail.com Gerasimos Dimitriadis gedimitr@auth.gr Geraud Continsouzas geraud@gcu.info Gerhard Gonter g.gonter@ieee.org Gerrit Beine tux@pinguru.net Giacomo Mariani giacomomariani@yahoo.it Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Gleb Sushko neuroworker@gmail.com Glen Foster gfoster@gfoster.com Giel van Schijndel me@mortis.eu Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Albrecht gregoryba@gmail.com Greg Ansley gja@ansley.com Greg Becker greg@codeconcepts.com Greg J. xcas@cox.net Greg Kennedy kennedy.greg@gmail.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Grün Christian-Rolf kiki@bsdro.org Guillaume Paquet amyfoub@videotron.ca Gurkan Sengun grknsngn@gmail.com Gustavo Fukao gustavofukao@gmail.com Guy Brand gb@isis.u-strasbg.fr Guy Coleman gtchask@mm.st Guy Harris guy@netapp.com Guy Poizat guy@device.dyndns.org H. Wade Minter minter@lunenburg.org HAMADA Naoki hamada@astec.co.jp HATANOU Tomomi hatanou@infolab.ne.jp HIYAMA Takeshi gibbon@cocoa.freemail.ne.jp HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Haesu Jeon haesu@towardex.com Hakisho Nukama nukama@gmail.com Hammurabi Mendes hmendes_br@yahoo.com Hannes Frederic Sowa hannes@stressinduktion.org Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Petter Selasky hselasky@c2i.net Hans Zuidam hans@brandinnovators.com Hans-Christian Ebke hans-christian_ebke@gmx.de Hansjoerg Pehofer hansjoerg.pehofer@uibk.ac.at Harald Schmalzbauer h.schmalzbauer@omnisec.de Harald Wille harald.wille@students.jku.at Hardy Schumacher hardy.schumacher@gmx.de Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Harry Coin harrycoin@qconline.com Harry Newton harry_newton@telinco.co.uk Havard Eidnes Havard.Eidnes@runit.sintef.no Heath Nielson heath@cs.byu.edu Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp Heiner Eichmann h.eichmann@gmx.de Heiner Strauss heiner@bilch.com Helko Glathe glathe.helko@googlemail.com Helmut F. Wirth hfwirth@ping.at Hendrik Scholz hendrik@scholz.net Henri Michelon michelon@e-cml.org Henrik Brautaset Aronsen freebsd-ports@henrik.synth.no Henrik Friedrichsen hrkfrd@googlemail.com Henrik Motakef henrik.motakef@web.de Henrik Nymann Jensen henriknj@0xmilk.org Henrik Vestergaard Draboel hvd@terry.ping.dk Henry Whincup henry@techiebod.com Herb Peyerl hpeyerl@NetBSD.org Herbert J. Skuhra herbert.skuhra@gmx.at Hernan Di Pietro hernan.di.pietro@gmail.com Hideaki Machida hido@coreblack.com Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hirohisa Yamaguchi umq@ueo.co.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroto Kagotani hiroto.kagotani@gmail.com Hiroya Tsubakimoto Holger Lamm holger@eit.uni-kl.de Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org Hr.Ladavac lada@ws2301.gud.siemens.co.at Hsin-Hsiung Chang sexbear@tmu.edu.tw Hubert Feyrer hubertf@NetBSD.ORG Hubert Tournier hubert@frbsd.org Hugh Mahon h_mahon@fc.hp.com Hugo Leisink hugo@leisink.net Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Hung-Yi Chen gaod.chen@gmail.com Hyogeol Lee hyogeollee@gmail.com IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp IWATSUKI Hiroyuki don@na.rim.or.jp Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Artemiev ai@kliksys.ru Igor Khasilev igor@jabber.paco.odessa.ua Igor Leonenko bananaz@bk.ru Igor Pokrovsky ip@doom.homeunix.org Igor Roshchin str@giganda.komkon.org Igor Serikov bt@turtle.pangeatech.com Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ildar Hizbulin hizel@vyborg.ru Ilia Chipitsine ilia@rediska.ru Ilya Bakulin webmaster@kibab.com Ilya Khamushkin ilya@space.rootshell.ru Ilya V. Komarov mur@lynx.ru Ismail Yenigul ismail@enderunix.org Itsuro Saito saito@miv.t.u-tokyo.ac.jp Ivan Klymenko fidaj@ukr.net Ivan Sharov ivan.sharov@iname.com Ivan Sviridov sin@vimcom.net J Shoemaker shoemaker@softhome.net J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J. Randolph snortsms@servangle.net J.R. Oldroyd fbsd@opal.com J.T. Conklin jtc@cygnus.com Jacek Pelka jacek@combit.com.pl Jack jack@zeus.xtalwind.net Jackson Low xxjack12xx@gmail.com Jacob Atzen jatzen@gmail.com Jacob Bohn Lorensen jacob@jblhome.ping.mk Jacques Marneweck jacques@php.net Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@anobject.com Jake Smith jake@xz.cx Jakub Klausa jacke@bofh.pl James Bailie jimmy@mammothcheese.ca James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James Jegers jimj@miller.cs.uwm.edu James McNaughton bitbucket63-it@yahoo.com James O'Gorman james@netinertia.co.uk James P. Howard, II jh@jameshoward.us James Raftery james@now.ie James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu James da Silva jds@cs.umd.edu Jamie Heckford jamie@jamiesdomain.co.uk Jamie Jones jamie@bishopston.net Jan Conard charly@fachschaften.tu-muenchen.de Jan Henrik Sylvester me@janh.de Jan Jungnickel Jan@Jungnickel.com - Jan Koum - jkb@FreeBSD.org + &a.jkb.email; Jan L. Peterson jlp@flipdog.com Jan Rochel jan.rochel@epost.de Jan Siml jsi@jules.de Jan Srzednicki w@wrzask.pl Jan Stocker jan.stocker@t-online.de Jan-Peter Koopmann j.koopmann@seceidos.de Janaka Wickramasinghe janaka@opensource.lk Janick Taillandier Janick.Taillandier@ratp.fr Janky Jay ek@purplehat.org János Mohácsi janos.mohacsi@bsd.hu Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Bacon jwbacon@tds.net Jason Burgess dev@fenux.net Jason DiCioccio geniusj@ods.org Jason Garman init@risen.org Jason Harris jharris@widomaker.com Jason R. Mastaler jason-freebsd@mastaler.com Jason Stone jason-fbsd-ports@shalott.net Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javad Kouhi javad.kouhi@gmail.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jay Krell jay.krell@cornell.edu Jaye Mathisen mrcpu@cdsnet.net Jaap Akkerhuis jaap@NLnetLabs.nl Jean-Baptiste Quenot jb.quenot@caraldi.com Jean Benoit jean@unistra.fr Jean-Sebastien Roy js@jeannot.org Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Burchell toxic@doobie.com Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer scorpio@drkshdw.org Jeffrey Evans evans@scnc.k12.mi.us Jeffrey H. Johnson CPE1704TKS@bellsouth.net Jeffrey Leung zenoss@experts-exchange.com Jeff Molofee nehe@cruzinternet.com Jeffrey Wheat jeff@cetlink.net Jens Holmqvist zparta@hispan.se Jens K. Loewe bsd@tuxproject.de Jens Rehsack rehsack@liwing.de Jeremy Allison jallison@whistle.com Jeremy C. Reed reed@pugetsoundtechnology.com Jeremy Chatfield jdc@xinside.com Jeremy Karlson karlj000@unbc.ca Jeremy Prior Jeremy Shaffner jeremy@external.org Jeroen Schot schot@a-askwadraat.nl Jerry Eriksson jerry@freebsd.se Jesper Dalberg jesper@jdn.dk Jesper Noehr jesper@noehr.org Jesse Kempf jessekempf@gmail.com Jesse McConnell jesse@cylant.com Jesse Rosenstock jmr@ugcs.caltech.edu Jesse van den Kieboom troplosti@orcaweb.cjb.net Jia-Wei Ye leafy7382@gmail.com Jian-Da Li jdli@csie.nctu.edu.tw Jie Gao gaoj@cpsc.ucalgary.ca - Jim Babb - babb@FreeBSD.org + &a.babb.email; Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Geovedi jim@corebsd.or.id Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Pirzyk pirzyk@uiuc.edu Jim Riggs ports@christianserving.org Jim Shewmaker jim@bluenotch.com Jim Sloan odinn@atlantabiker.net Jim Stapleton sjss@var-dev.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Jin-Shan Tseng tjs@cdpa.nsysu.edu.tw Jo Rhett jrhett@netconsonance.com Joachim Kuebart kuebart@mathematik.uni-ulm.de Joachim Strombergson Watchman@ludd.luth.se Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe Abley jabley@automagic.org Joe Barbish barbish@a1poweruser.com Joe Halpin joe.halpin@attbi.com Joe Holden joe@joeholden.co.uk Joe Horn joehorn@gmail.com Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Kelsey joek@flyingcroc.net Joe Orthoefer j_orthoefer@tia.net Joe Smith inwap@best.com Joe Traister traister@mojozone.org Joel Diaz joeldiaz@bellsouth.net Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Joerg Pulz Joerg.Pulz@frm2.tum.de Joerg Schilling schilling@fokus.gmd.de Johan Granlund johan@granlund.nu Johan Larsson johan@moon.campus.luth.se Johan Strom johan@stromnet.org Johann Tonsing jtonsing@mikom.csir.co.za Johannes 5 Joemann joemann@beefree.free.de Johannes Grødem johs@copyleft.no Johannes Helander Johannes Stille John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Ferrel jdferrell3@yahoo.com John Goerzen jgoerzen@alexanderwohl.complete.org John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John Marino draco@marino.st John McAree john@mcaree.org John MacFarlane jgm@berkeley.edu John Mehr jcm@visi.com John Merryweather Cooper jmcoopr@webmail.bmi.net John Nielsen john@jnielsen.net John Oxley john@yoafrica.com John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Prather john.c.prather@gmail.com John Preisler john@vapornet.com John Reynolds johnjen@reynoldsnet.org John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Von Essen john@essenz.com John Wehle john@feith.com John Woods jfw@eddie.mit.edu Johny Mattsson lonewolf@flame.org Jon Amundsen online@jamundsen.dyndns.org Jon Morgan morgan@terminus.trailblazer.com Jon Nistor nistor@snickers.org Jon Passki cykyc@yahoo.com Jon Wilson jon@phuq.co.uk Jona Joachim walkingshadow@grummel.net Jonathan Belson jon@witchspace.com Jonathan Bokovza Jonathan@afarsec.com Jonathan Chen jonc@chen.org.nz Jonathan Chu milki@rescomp.berkeley.edu Jonathan Drews j.e.drews@att.net Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jhanna@shaw.ca Jonathan Lennox lennox@cs.columbia.edu Jonathan Liu Net147@hotmail.com Jonathan McDowell noodles@earth.li Jonathan Pennington john@coastalgeology.org Jordan DeLong fracture@allusion.net Jordi Haarman jhaarman-keyword-tinyerpPort.fd583c@projects.synantics.net Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Joris Vandalon joris@vandalon.nl Jos Backus jos@catnook.com Jose Abelardo Martinez jamartinez@altern.org Jose Liang jose@jose.idv.tw Jose Marques jose@nobody.org Jose Rodriguez king@v2project.com José García Juanino jjuanino@gmail.com Josef Grosch jgrosch@superior.mooseriver.com Joseph Haga tuximus@tcsn.net Joseph Mingrone jrm@ftfl.ca Joseph Scott joseph@randomnetworks.com Joseph Stein joes@wstein.com Josh Carroll josh.carroll@gmail.com Josh Elsasser jre@vineyard.net Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Josh Tolbert hemi@puresimplicity.net Joshua D. Abraham jabra@ccs.neu.edu Joshua Goodall joshua@roughtrade.net Jostein Trondal jostein.trondal@sikkerhet.no Juan Salaverria rael@vectorstar.net Juha Inkari inkari@cc.hut.fi Juha Nygard juha.nygard1@netikka.fi Juha Ylitalo juha.ylitalo@iki.fi Jui-Nan Lin jnlin@csie.nctu.edu.tw Jukka A. Ukkonen jau@iki.fi Julian Assange proff@suburbia.net Julian C. Dunn jdunn@aquezada.com Julian Coleman j.d.coleman@ncl.ac.uk - &a.jhs; + &a.jhs.email; Julian Jenkins kaveman@magna.com.au Julian Stecklina der_julian@web.de Jun Mukai mukai@jmuk.org Junichi Satoh junichi@jp.FreeBSD.org Junji NAKANISHI jun-g@daemonfreaks.com Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv Justin Stanford jus@security.za.net Jyun-Yan You jyyou@cs.nctu.edu.tw Gergely CZUCZY gergely.czuczy@harmless.hu K.Higashino a00303@cc.hc.keio.ac.jp KANOU Hiroki kanou@khdd.net KATO Tsuguru tkato@prontomail.ne.jp KIMURA Shigekazu zau50357@lion.zero.ad.jp KIMURA Yasuhiro yasu@utahime.org KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kai Vorma vode@snakemail.hut.fi Kai Wang kaiwang27@gmail.com Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kang Liu liukang@bjut.edu.cn Kang-ming Liu gugod@gugod.org Kapil Chowksey kchowksey@hss.hns.com Karel Miklav karel@lovetemple.net Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com Karsten W. Rohrbach karsten@rohrbach.de Katalin Konkoly katalin.konkoly@gmail.com Katsura Matsumoto katsura@cc.osaka-kyoiku.ac.jp Kawanobe Koh kawanobe@st.rim.or.jp Kay Abendroth kay.abendroth@raxion.net Kay Lehmann kay_lehmann@web.de Kazami kazami@angels.vg Kazuhito HONDA kazuhito@ph.noda.tus.ac.jp Kees Jan Koster kjkoster@kjkoster.org Keith Bostic bostic@bostic.com Keith E. Walker kew@icehouse.net Keith Moore Keith Sklower Kelley Reynolds kelley@insidesystems.net Ken Hornstein Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Ken McGlothlen mcglk@artlogix.com Ken Menzel kenm@icarz.com Ken Tom subd@mui.net Kenji Saito marukun@mx2.nisiq.net Kenji Takefu takefu@airport.fm Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@yahoo.com Kenneth Vestergaard Schmidt kvs@pil.dk Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Brunelle kruptos@mlinux.org Kevin Day toasty@dragondata.com Kevin Golding kevin@caomhin.demon.co.uk Kevin Lahey kml@nas.nasa.gov Kevin Meltzer perlguy@perlguy.com Kevin Oberman oberman@es.net Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kevin Zheng kevinz5000@gmail.com Key-Teck SIN ktsin@acm.org Khairil Yusof kaeru@inigo-tech.com Killer killer@prosalg.no Kim Scarborough sluggo@unknown.nu Kimura Fuyuki fuyuki@hadaly.org Kiril Mitev kiril@ideaglobal.com Kirill Bezzubets kirill@solaris.ru Kirill A. Korinskiy catap@catap.ru Kirk Strauser kirk@strauser.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Goger klaus.goger@reflex.at Klaus Herrmann klaus.herrmann@gmx.net Klaus Klein kleink@layla.inka.de Klaus Michael Indlekofer M.Indlekofer@gmx.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Konrad Heuer kheuer@gwdu60.gwdg.de Konrad Lapsz konrad.lapsz@gmail.com Konstantin Chuguev Konstantin.Chuguev@dante.org.uk Konstantin Reznichenko kot@premierbank.dp.ua Konstantinos Mplekos mplekos@physics.upatras.gr Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk Krzysztof Kowalewski pyzmen@kam.pl Krzysztof Pawlowski msciciel@darkzone.ma.cx Kuan-Chung Chiu buganini@gmail.com Kuang-che Wu kcwu@csie.org Kuo-Feng Tseng kftseng@iyard.org Kurt D. Zeilenga Kurt@Boolean.NET Kurt Jaeger fbsd-ports@opsec.eu Kurt Olsen kurto@tiny.mcs.usu.edu Kyle Martin mkm@ieee.org L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Landon Fuller landonf@opendarwin.org Lapo Luchini lapo@lapo.it Larry Altneu larry@ALR.COM Larry P. Maloney larry@kiputers.com Larry Rosenman ler@lerctr.org Lars Bernhardsson lab@fnurt.net Lars Eggert lars.eggert@gmx.net Lars Erik Gullerud lerik@nolink.net Lasse L. Johnsen lasse@freebsdcluster.org Laurence Lopez lopez@mv.mv.com Laurent Courty lrntct@gmail.com Laurent Levier llevier@argosnet.com Lauri Watts lauri@kde.org Laust S. Jespersen L@ust.dk Lee Cremeans lcremean@tidalwave.net Lefteris Chatzibarbas lefcha@hellug.gr Leif Pedersen pedersen@meridian-enviro.com Len Sassaman rabbi@abditum.com Leo Kim leo@florida.sarang.net Leo Vandewoestijne freebsd@dns-lab.com Leonardo Silveira de A. Martins lmartins@nepe.eee.ufg.br Leonhard Wimmer leo@mediatomb.cc Leonid Zolotarev leoz.2005@gmail.com Lev Walkin vlm@lionet.info Levent Kayan levent@corehack.org Lewis Thompson purple@lewiz.net Li-lun Wang llwang@infor.org Liam Foy liamfoy@sepulcrum.org Linh Pham question+freebsdpr@closedsrc.org Lon Willett lon%softt.uucp@math.utah.edu Loren J. Rittle ljrittle@acm.org Loren M. Lang lorenl@alzatex.com Louis A. Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lubomir Metodiev Marinov lubomir.marinov@gmail.com Lucas James Lucas.James@ldjpc.apana.org.au Lucio Costa lucio@zetasolucoes.com.br Luiz Eduardo Roncato Cordeiro cordeiro@nic.br Lukasz Stelmach lukasz.stelmach@iem.pw.edu.pl Lupe Christoph lupe@lupe-christoph.de Lutz Boehne lboehne@damogran.de Lyndon Nerenberg lyndon@orthanc.ab.ca M Rothwell freebsd-ports@coreland.ath.cx M. L. Dodson bdodson@scms.utmb.EDU M.C. Wong MOROHOSHI Akihiko moro@remus.dti.ne.jp Machiel Mastenbroek machiel_mastenbroek@hotmail.com Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Mahlon E. Smith mahlon@martini.nu Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Makoto YAMAKURA makoto@pinpott.spnet.ne.jp Malte Lance malte.lance@gmx.net Mantas Kaulakys stone@tainet.lt Manu Iyengar iyengar@grunthos.pscwa.psca.com Manuel Creach manuel.creach@me.com Manuel Rabade Garcia mig@mig-29.net Marc Blanchet marc.blanchet@viagenie.qc.ca Marc Frajola marc@dev.com Marc Olzheim marcolz@stack.nl Marc Ramirez mrami@mramirez.sy.yale.edu Marc Recht marc@informatik.uni-bremen.de Marc Silver marcs@draenor.org Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom marc.vanwoerkom@fernuni-hagen.de Marcello Silva Coutinho marcellocoutinho@gmail.com Marcelo/Porks Rossi marcelorossi@gmail.com Marcin Cieslak saper@system.pl Marcin Gondek drixter@e-utp.net Marcin Jessa yazzy@yazzy.org Marcin Wisnicki mwisnicki@gmail.com Marco Molteni molter@tin.it Marco van de Voort marcov@stack.nl Marin Atanasov dnaeon@gmail.com Marius Nünnerich marius@nuenneri.ch Mark A. Wicks mwicks@kettering.edu Mark Andrews Mark Blackman freebsd-ports@blackmans.org Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Daniel Reidel ports@mark.reidel.info Mark Diekhans markd@grizzly.com Mark Foster mark@foster.cc Mark Hannon markhannon@optusnet.com.au Mark Huizer xaa+freebsd@timewasters.nl Mark J. Miller joup@bigfoot.com Mark J. Taylor mtaylor@cybernet.com Mark Johnston mjohnston@skyweb.ca Mark Kane mark@mkproductions.org Mark Knight markk@knigma.org Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Starovoytov mark_sf@kikg.ifmo.ru Mark Stosberg mark@summersault.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy Mark Valentine mark@thuvia.org Markus Holmberg saska@acc.umu.se Markus Niemistö markus.niemisto@gmx.net Martijn Lina martijn@pacno.net Martin Dieringer martin.dieringer@gmx.de Martin Hinner mhi@linux.gyarab.cz Martin Ibert mib@ppe.bb-data.de Martin Jackson mhjacks@swbell.net Martin Kammerhofer mkamm@gmx.net Martin Karlsson martin.karlsson@visit.se Martin Klaffenboeck martin.klaffenboeck@gmx.at Martin Kraft martin.kraft@fal.de Martin Kropfinger freebsd@rakor-net.de> Martin Mersberger gremlin@portal-to-web.de Martin Minkus diskiller@cnbinc.com Martin Neubauer m.ne@gmx.net Martin Otto gamato@users.sf.net Martin Preuss martin@libchipcard.de Martin Sugioarto martin.sugioarto@udo.edu Martin Tournoij carpetsmoker@gmail.com Martti Kuparinen martti.kuparinen@ericsson.com Marwan Burelle marwan.burelle@lri.fr Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masafumi Otsune info@otsune.com Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masahiro TAKEMURA mastake@msel.t.u-tokyo.ac.jp Masahiro Teramoto markun@onohara.to Masakazu HIGAKI higamasa@dream.com Masaki TAGAWA masaki@club.kyutech.ac.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masanori OZAWA ozawa@ongs.co.jp Masashi CHIBA chiba.masashi@gmail.com Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mathias Monnerville mathias@monnerville.com Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Dawson matt@mattsnetwork.co.uk Matt Douhan matt@athame.co.uk Matt Emmerton matt@gsicomp.on.ca Matt Heckaman matt@LUCIDA.QC.CA Matt Jibson dolmant@dolmant.net Matt Lancereau matt@bsdfly.org Matt Loschert loschert@servint.com Matt Mills matt_mills@btopenworld.com Matt Peterson matt@peterson.org Matt Smith matt@xtaz.net Matt Stofko matt@mjslabs.com Matt Thomas matt@3am-software.com Matt Tosto datahead4@gmail.com Matt White mwhite+@CMU.EDU Matthew Braithwaite mab@red-bean.com Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Donovan kitchetech@gmail.com Matthew Emmerton root@gabby.gsicomp.on.ca Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@over-yonder.net Matthew George mdg@secureworks.net Matthew Gibson mdg583@hotmail.com Matthew Grooms mgrooms@shrew.net Matthew Holder sixxgate@hotmail.com Matthew Luckie mjl@luckie.org.nz Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthew Will mwill@spingen.com Matthew X. Economou xenophon+fbsdports@irtnog.org Matthias Fechner idefix@fechner.net Matthias Petermann matthias@d2ux.net Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Matthias Schmidt schmidtm@mathematik.uni-marburg.de Matthias Sund m.sund@arcor.de Matthias Schündehütte msch@snafu.de Matthias Teege mteege.de Matthieu Guegan matt.guegan@free.fr Matthias Teege mteege.de Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Matus Uhlar uhlar@fantomas.sk Maurice Castro maurice@planet.serc.rmit.edu.au Mauricio Herrera Cuadra mauricio@arareko.net Max Campos mcampos@bpsw.biz Max E. Kuznecov mek@mek.uz.ua Max Euston meuston@jmrodgers.com Max N. Boyarov m.boyarov@bsd.by Maxim Bolotin max@rsu.ru Maxim Dounin mdounin@mdounin.ru Maxim Ignatenko gelraen.ua@gmail.com Maxim Loginov zeliboba@mail.ru Maxim Samsonov xors@sendmail.ru Maxim Tuliuk mt@primats.org.ua Maxime Romano verbophobe@hotmail.com Meikel Brandmeyer Brandels_Mikesh@web.de Mel Flynn rflynn@acsalaska.net Meno Abels meno.abels@adviser.com Meyer Wolfsheim wolf@priori.net Micha Class michael_class@hpbbse.bbn.hp.com Michael A. Kohn naken@naken.cc Michael Alyn Miller malyn@strangeGizmo.com Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael C. Shultz ringworm@inbox.lv Michael Clay mclay@weareb.org Michael Collette metrol@metrol.net Michael Ebert ebert@informatik.unibw-muenchen.de Michael Edenfield kutulu@kutulu.org Michael Galassi nerd@percival.rain.com Michael Gmelin freebsd@grem.de Michael Hancock michaelh@cet.co.jp Michael Handler handler@grendel.net Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Iatrou m_iatrou@freemail.gr Michael Lyngbøl michael@lyngbol.dk Michael Neumann mneumann@ntecs.de Michael O. Boev mike@tric.tomsk.gov.ru Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Ranner mranner@inode.at Michael Sanders mike@topcat.hypermart.net Michael Sardo jaeger16@yahoo.com Michael Schout mschout@gkg.net Michael Searle searle@longacre.demon.co.uk Michael Seyfert michaels@sdf.lonestar.org Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michal Pasternak dotz@irc.pl Michel Lavondés fox@vader.aacc.cc.md.us Michele Possamai possamai@xs4all.nl Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Micho Durdevich micho@math.unam.mx Mickael Maillot mickael.maillot@gmail.com Miguel Angel Sagreras msagre@cactus.fi.uba.ar Miguel Mendez flynn@energyhq.es.eu.org Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mij mij@bitchx.it Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Andrews mandrews@bit0.com Mike Bowie mbowie@buzmo.com Mike Bristow mike@urgle.com Mike Del repenting@hotmail.com Mike Durian durian@boogie.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Edenfield kutulu@kutulu.org Mike Erickson mee@quidquam.com Mike Evans mevans@candle.com Mike Futerko mike@LITech.lviv.ua Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels Mike Krutov neko@takino.org Mike Lockwood mike@mikelockwood.com Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@mired.org Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Patterson mike.patterson@unb.ca Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mike Tancsa mike@sentex.net Mikhail A. Sokolov mishania@demos.su Mikhail T. michael@fun-box.ru Mikhail Zakharov zmey20000@yahoo.com Mikolaj Rydzewski miki@ceti.pl Mikolaj Golub to.my.trociny@gmail.com Miks Mikelsons miks@cubesystems.lv Milan Obuch bsd@dino.sk Milosz Galazka milosz.galazka@gmail.com Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Mooneer Salem mooneer@translator.cx Morgan Davis root@io.cts.com Morten Slot Kristensen ontherenth@gmail.com Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp Munish Chopra munish@engmail.uwaterloo.ca Murilo Opsfelder mopsfelder@gmail.com Mustafa Arif ma499@doc.ic.ac.uk Mykola Dzham i@levsha.me Mykola Khotyaintsev ko@irfu.se Mykola Marzhan delgod@portaone.com N.G.Smith ngs@sesame.hensa.ac.uk NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@jp.freebsd.org NAKAMURA Kazushi kaz@kobe1995.net NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp NIIMI Satoshi sa2c@and.or.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Nadav Eiron nadav@barcode.co.il Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Naram Qashat cyberbotx@cyberbotx.com Narayan Namdev Newton narayannewton@gmail.com Narvi narvi@haldjas.folklore.ee Nate Eldredge neldredge@math.ucsd.edu Nathan Dorfman nathan@rtfm.net Nathaniel Roark robb_force@holybuffalo.net Natsagdorj Shagdar natsag2000@yahoo.com Neal Fachan kneel@ishiboo.com Necati Ersen Siseci siseci@enderunix.org Ned Wolpert wolpert@codeheadsystems.com Nguyen Tam Chinh chinhngt@sectorb.msk.ru Niall Smart rotel@indigo.ie Nicholas Esborn nick@netdot.net Nick Barnes Nick.Barnes@pobox.com Nick Dewing nickdewing@gmail.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net Nicole Reid root@cooltrainer.org Nikolai Lifanov lifanov@mail.lifanov.com Nikos Kokkalis nickkokkalis@gmail.com Nick Leuta skynick@mail.sc.ru Nick Rogness nick@rogness.net Nick Williams njw@cs.city.ac.uk Nick Withers nick@nickwithers.com Nicko Dehaine nicko@stbernard.com Nickolay N. Dudorov nnd@itfs.nsk.su Nicolas Jombart ecu@ipv42.net Niklas Hallqvist niklas@filippa.appli.se Nikola Lecic nikola.lecic@anthesphoria.net Nikola Kolev koue@chaosophia.net Nikos Ntarmos ntarmos@ceid.upatras.gr Nils M. Holm nmh@t3x.org Nisha Talagala nisha@cs.berkeley.edu No Name ZW6T-KND@j.asahi-net.or.jp No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name nemysis@gmx.ch No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name salexanov@gmail.com Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp Norberto Lopes nlopes.ml@gmail.com Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noritoshi Demizu demizu@dd.iij4u.or.jp Noriyuki Soda soda@sra.co.jp Oddbjorn Steffensen oddbjorn@tricknology.org Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Olafur Osvaldsson oli@isnic.is Oleg Alexeenkov proler@gmail.com Oleg Ginzburg olevole@olevole.ru Oleg Kiselyov oleg@pobox.com Oleg A. Mamontov oleg@mamontov.net Oleg M. Golovanov olmi@rentech.ru Oleg Moskalenko mom040267@gmail.com Oleg R. Muhutdinov mor@whiteluna.com Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg Ukraincev oleg@ht-systems.ru Oleg V. Volkov rover@lglobus.ru Oleksandr Lystopad laa@laa.zp.ua Olexander Kunytsa kunia@wolf.istc.kiev.ua Oliver Breuninger ob@seicom.NET Oliver Dunkl odunkl@gmx.net Oliver Fischer plexus@snafu.de Oliver Friedrichs oliver@secnet.com Oliver Hartmann ohartman@zedat.fu-berlin.de Oliver Heesakkers dev2@heesakkers.info Oliver Helmling oliver.helmling@stud.uni-bayreuth.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Oliver Peter hoschi@mouhaha.de Olivier Beyssac obld@r14.freenix.org Olivier Cochard-Labbé olivier@cochard.me Olivier Tharan olive@oban.frmug.org Olof Johansson offe@ludd.luth.se Omer Faruk Sen ofsen@enderunix.org Oscar Bonilla obonilla@galileo.edu Otacílio de Araújo Ramos Neto otacilio.neto@ee.ufcg.edu.br Otávio Fernandes otaviof@gmail.com Ozkan KIRIK ozkan@enderunix.org Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Panagiotis Astithas past@noc.ntua.gr Panagiotis Kritikakos panoskrt@googlemail.com Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pascal Vizeli pvizeli@yahoo.de Pasi Hirvonen psh@iki.fi Pasvorn Boonmark boonmark@juniper.net Patrick Alken cosine@ellipse.mcs.drexel.edu Patrick Atamaniuk atamaniuk-ports@frobs.net Patrick Bihan-Faou patrick@mindstep.com Patrick Dung patrick_dkt@yahoo.com.hk Patrick Hausen Patrick MARIE mycroft@virgaria.org Patrick Powell papowell@astart.com Patrick Rinke patrick@rinke-bochum.de Patrick Seal patseal@hyperhost.net Patrick Tracanelli eksffa@freebsdbrasil.com.br Paul onemda@gmail.com Paul A. Hoadley paulh@logicsquad.net Paul Antonov apg@demos.su Paul Chvostek paul@it.ca Paul Dlug paul@aps.org Paul F. Werkowski Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. Paul Sandys myj@nyct.net Paul Schmehl pauls@utdallas.edu Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Fragoso paulo@nlink.com.br Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pavel Janik Pavel@Janik.cz Pavel Novikov pavel@ext.by Pavel Pankov pankov_p@mail.ru Pavel Veretennikov vermut@kid.lv Pavel I Volkov pavelivolkov@googlemail.com Pawel Worach pawel.worach@gmail.com Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pengfei JU jupengfei@gmail.com Per Wigren wigren@home.se Pete Bentley pete@demon.net Peter Ankerstål peter@pean.org Peter Avalos pavalos@theshell.com Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Pete French pete@twisted.org.uk Peter Haight peterh@prognet.com Peter Holub hopet@ics.muni.cz Peter Klatt glocke@bsdstammtisch.at Peter Kolmisoppi growspd@brokep.com Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson Peter Philipp pjp@bsd-daemon.net Peter S. Housel housel@acm.org Peter Schuller peter.schuller@infidyne.com Peter Stubbs PETERS@staidan.qld.edu.au Péter Terbe sncdev@gmail.com Peter Thoenen peter.thoenen@yahoo.com Peter Vereshagin peter@vereshagin.org Peter W. Schmiedeskamp pschmied@qwest.net Peter van Dijk peter@dataloss.nl Peter van Heusden pvh@wfeet.za.net Petr Macek pm@kostax.cz Petr Rehor prehor@gmail.com Phil Budne phil@ultimate.com Phil Maker pjm@gnu.org Phil Oleson oz@nixil.net Phil Phillips pphillips@experts-exchange.com Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci p.musumeci@ieee.org Philip Reynolds philip.reynolds@rfc-networks.ie Philip Schulz phs@deadc0.de Philippe Lefebvre nemesis@balistik.net Philippe Pepiot phil@philpep.org Philippe Rocques phil@teaser.fr Pierre David pdagog@gmail.com Pierre Y. Dampure pierre.dampure@k2c.co.uk Pierre-Paul Lavoie ppl@nbnet.nb.ca Pieter Danhieux opr@bsdaemon.be Piotr Florczyk p.florczyk@adminworkshop.pl Piotr Rybicki meritus@innervision.pl Piotr Smyrak piotr.smyrak@heron.pl Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Pontus Stenetorp ninjin@kth.se Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee Prudhvi Krishna prudhvikrishna@gmail.com Qing Feng qingfeng@me.com Quentin Stievenart acieroid@awesom.eu Quinton Dolan q@onthenet.com.au R Joseph Wright rjoseph@mammalia.org R. Kym Horsell R Skinner port_maintainer@herveybayaustralia.com.au Radek Kozlowski radek@raadradd.com Radim Kolar hsn@netmag.cz Radoslav Vasilev rvasilev@uni-svishtov.bg Rafal Lesniak fbsd@grid.einherjar.de Raffaele De Lorenzo raffaele.delorenzo@libero.it Rainer Duffer rainer@ultra-secure.de Rainer Hurling rhurlin@gwdg.de Ralf Friedl friedl@informatik.uni-kl.de Ralf Gebhart gebhart@secnetix.de Ralf van Dooren r.vdooren@snow.nl Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Rashid N. Achilov shelton@sentry.granch.ru Rasmus Kaj rasmus@kaj.se Raul Pollicino email-ports@def-defying.com Razi Khaja razi@genet.sickkids.on.ca Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remington Lang MrL0L@charter.net Remy Card Remy.Card@masi.ibp.fr Revis Zinkov rzinkov@gmail.com Ricardas Cepas rch@richard.eu.org Ricardo A. Reis ricardo.areis@gmail.com Riccardo Veraldi veraldi@cs.unibo.it Rich Morin rdm@cfcl.com Rich Wood rich@FreeBSD.org.uk Richard Arends richard@unixguru.nl Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard J Kuhns rjk@watson.grauel.com Richard Kiss richard@homemail.com Richard M. Neswold rneswold@enteract.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Fournier rick@help-desk.ca Rick Macklin Rick van der Zwet rick@wzoeterwoude.net Roar Pettersen roar.pettersen@it.uib.no Rob Austein sra@epilogue.com Rob Evers rob@debank.tv Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crossfield robcrossfield@gmail.com Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Felber robtone@ek-muc.de Robert P Ricci ricci@cs.utah.edu Robert Sanders rsanders@mindspring.com Robert Schlotterbeck robert@rs.tarrant.tx.us Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Simmons rsimmons0@gmail.com Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder Robin Carey robin@mailgate.dtc.rankxerox.co.uk Robin Elfrink elfrink@introweb.nl Robin Schilham co9@xs4all.nl Robin Schoonover robin.schoonover@gmail.google.com Rod Taylor ports@rbt.ca Rodrigo Graeff delphus@gmail.com Rodrigo Osorio rodrigo@bebik.net Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roland Smith rsmith@xs4all.nl Dr. Rolf Jansen cyclaero@gmail.com Roman Neuhauser neuhauser@chello.cz Roman Shterenzon roman@xpert.com Roman Synyuk roman@univ.kiev.ua Roman V. Palagin romanp@unshadow.net Roman Y. Bogdanov sam@brj.pp.ru Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ron van Daal ronvdaal@n1x.nl Ronald F. Guilmette rfg@monkeys.com Ronald Klop ronald@echteman.nl Ronald Kuehn kuehn@rz.tu-clausthal.de Roselyn Lee rosel@verniernetworks.com Ross West freebsd@linepoint.com Rostislav Krasny rosti.bsd@gmail.com Roy Maples roy@marples.name Ruben chromium@hybridsource.org Rudolf Cejka cejkar@fit.vutbr.cz Rui Lopes rui@ruilopes.com Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell Jackson rjackson@cserv62.csub.edu Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Rusty Nejdl rnejdl@ringofsaturn.com Ryan Grove ryan@wonko.com Ryan Moe ryan@transaeris.com Ryan T. Dean rtdean@cytherianage.net Ryan Thompson ryan@sasknow.com Ryan Younce ryany@pobox.com Ryo MIYAMOTO rmiya@cc.hirosaki-u.ac.jp Ryo Okamoto ryo@aquahill.net RyoTa SimaMoto liangtai.s4@gmail.com Ryuichiro IMURA imura@af.airnet.ne.jp SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp SAWADA Mizuki miz@qb3.so-net.ne.jp SPF spf@xslt.cs.nccu.edu.tw SUGIMURA Takashi sugimura@jp.FreeBSD.org SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@rfc1149.net Samuele Zannoli zannoli@cs.unibo.it Samy Al Bahra samy@kerneled.com Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it Sarod Yatawatta sarod@users.sf.net Sascha Blank blank@fox.uni-trier.de Sascha Holzleiter sascha@root-login.org Sascha Klauder sklauder@trimind.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp Saulius Menkevicius bob@nulis.lt Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Flatman sf@slappy.org Scott Hazen Mueller scott@zorch.sf-bay.org Scott Kleihege scott-ports@tummy.com Scott Lambert lambert@lambertfam.org Scott Michel scottm@cs.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Scott Ullrich sullrich@gmail.com SeaD sead@mail.ru Sean McLaughlin sigma.zx@gmail.com Seamus Venasse svenasse@polaris.ca Sébastian Santoro dereckson@gmail.com Sebastian Strollo seb@erix.ericsson.se Sebastian Yepes esn@x123.info Seiya Yanagita s_yanagita@ybb.ne.jp Serge Gagnon gagnon_s@sympatico.ca Serge Negodyuck petr@petrovich.kiev.ua Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergei Vyshenski svysh.fbsd@gmail.com Sergey Akifyev asa@gascom.ru Sergey V. Dyatko sergey.dyatko@gmail.com Sergey Gershtein sg@mplik.ru Sergey Glushchenko deen@smz.com.ua Sergey Kosyakov ks@itp.ac.ru Sergey Lyubka valenok@gmail.com Sergey N. Vorokov serg@tmn.ru Sergey Potapov sp@alkor.ru Sergey Samoyloff gonza@techline.ru Sergey Shkonda serg@bcs.zp.ua Sergey V. Dorokhov svd@kbtelecom.nalnet.ru Sergey Velichkevych serg@cad.kiev.ua Sergio Lenzi lenzi@bsi.com.br Sevan Janiyan venture37@geeklan.co.uk Shane Ambler freebsd@shaneware.biz Shane Kinney mod6@freebsdhackers.net Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shell Hung shell@shellhung.org Shen Chuan-Hsing statue@freebsd.sinica.edu.tw Shigeru Yamamoto shigeru@iij.ad.jp Shigio Yamaguchi shigio@tamacom.com Shin'ya Murakami murakami@ahs.scitec.kobe-u.ac.jp Shinichiro Komatsu koma2@ms.u-tokyo.ac.jp Shinsuke Matsui smatsui@karashi.org Shinya Esu esu@yk.rim.or.jp Shinya FUJIE fujie@tk.elec.waseda.ac.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Siebrand Mazeland s.mazeland@xs4all.nl Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon Cornelius P. Umacob simoncpu@infoweapons.com Simon Dick simond@irrelevant.org Simon Lang simon@lang-clan.de Simon Marlow simonmar@microsoft.com Simon Olofsson simon@olofsson.de Simon Schubert corecode@corecode.ath.cx Simon Shapiro shimon@simon-shapiro.org Simun Mikecin sime@logos.hr Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic slaven@rezic.de Snow Chyld snowchyld+freebsdports@gmail.com Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Debois debois@diku.dk Soren Dossing sauber@netcom.com Soren S. Jorvang soren@wheel.dk Stan Barber sob@academ.com Stanislav A. Svirid count@riss-telecom.ru Stanislav Grozev tacho@daemonz.org Stanislaw Halik sthalik@tehran.lain.pl Stanislav Shalunov shalunov@internet2.edu Stas Timokhin devel@stasyan.com Stefan A. Deutscher sad@mailaps.org Stefan Eggers seggers@semyam.dinoco.de Stefan Ehmann shoesoft@gmx.net Stefan Grundmann sg-sendpr@waset.de Stefan Jahn stefan.jahn@nemesis-sektor.de Stefan Moeding s.moeding@ndh.net Stefan Petri Stefan Rumetshofer sterum@overrider.at Stefan Schmidt stefan.schmidt@twest.de Stefan Schwarzer sschwarzer@sschwarzer.net Stefan Tell stefan.tell@crashmail.de Stefan `Sec` Zehl sec@42.org Steffen Mazanek steffen.mazanek@unibw-muenchen.de Steffen Vogelreuter Steffen@Vogelreuter.De Steinar Haug sthaug@nethelp.no Sten Poldma exile@chamber.ee Sten Spans sten@blinkenlights.nl Stepan Zastupov redchrom@gmail.com Stephane Lapie stephane.lapie@darkbsd.org Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Fisher stephentfisher@yahoo.com Stephen Gunn csg@fedex.com Stephen Hocking sysseh@devetir.qld.gov.au Stephen Hurd admin@nix.synchro.net Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Stephen Weeks sweeks@sweeks.com Stephon Chen stephon@gmail.com Steve Ames steve@energistic.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering Steve Franks bahamasfranks@gmail.com Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve O'Hara-Smith steve@sohara.org Steve Piette steve@simon.chi.il.US Steve Roome steve@pepcross.com Steve Schwarz schwarz@alpharel.com Steve Wills steve@mouf.net Steven Enderle panic@subphase.de Steven H. Samorodin samorodi@NUXI.com Steven Hartland steven.hartland@multiplay.co.uk Steven Honson steven@honson.org Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace Stijn Hoop stijn@win.tue.nl Stuart Henderson stuart@internationalschool.co.uk Stylianos Sideridis siderste@yahoo.gr Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sulev-Madis Silber madis555@hot.ee Sune Stjerneby sst@vmunix.dk Sungman Cho smcho@tsp.korea.ac.kr Sutra Zhou zhoushuqun@gmail.com Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Svein Skogen tds@dmnstech.net Sven Klose pixel@hugbox.org Sven Mohr svmohr@rm6.net Svyatoslav Lempert svyatoslav.lempert@gmail.com Sybolt de Boer bolt@xs4all.nl TAKAHASHI Kaoru kaoru@kaisei.org TERAMOTO Masahiro markun@onohara.to Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp Takahiro Yugawa yugawa@orleans.rim.or.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takayuki Nakao t@nakao.org Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tanja Wittke tawi@gruft.de Tarasov Alexey master@preved.cn Tassilo Philipp tphilipp@potion-studios.com Tatoku Ogaito tacha@tera.fukui-med.ac.jp Tatsuki Makino tatsuki_makino@hotmail.com Tatsuya Kudoh cdr@cosmonet.org Tatsuya Ueda ml+freebsd@tatsuya.info Taylor Dondich tdondich@majiknetworks.com Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Ted Stodgell trs137@psu.edu Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Terry Sposato terry@sucked-in.com Teruaki Ata PFA03027@nifty.ne.jp Tetsuro Yabu yabu@uopmu.ees.osakafu-u.ac.jp Tetsuya Furukawa tetsuya@secom-sis.co.jp Thaddeus Covert tcovert+ports@sahuagin.net Theo de Raadt deraadt@OpenBSD.org Thierry Dussuet thierry@dussuet.lugs.ch Thomas thomas@mathematik.uni-Bremen.de Thomas A. Stephens tas@stephens.org Thomas BRETON tom@h-inventory.com Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas Dreibholz dreibh@iem.uni-due.de Thomas E. Zander riggs@rrr.de Thomas G. McWilliams tgm@netcom.com Thomas Hurst tom@hur.st Thomas Kempka t.kempka@web.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas M. Hermann Thomas.Hermann@cox.net Thomas Melzer tmelzer@tomesoft.de Thomas Ptacek Thomas Spreng spreng@socket.ch Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Vogt thomas.vogt@bsdunix.ch Thorsten Greiner thorsten@tgreiner.net Þórður Ívarsson totii@est.is Tillman Hodgson tillman@seekingfire.com Tim Daneliuk tundra@tundraware.com Tim Hemel tim@n2it.net Tim Niemueller tim@niemueller.de Tim Pozar pozar@lns.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Welch ports@thepentagon.org Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Timofeev Vladimir vovkasm@gmail.com Timothy Beyer beyert@cs.ucr.edu Timothy Bourke timbob@bigpond.com Timothy Jensen toast@blackened.com Timothy Redaelli drizzt@drizzt.ath.cx Tobias Begalke tobega@spyz.org Tobias Reifenberger treif@mayn.de Tobias Roth ports@fsck.ch Toby Allsopp toby@mi6.gen.nz Todd Miller millert@openbsd.org Todd Mortensen todd@thisisa.com Tofig Suleymanov tofig@freebsd.az Tom root@majestix.cmr.no Tom Carrick knyghtmare@knyghtmare.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Mortensen tom@tavrasm.org Tom Mueller-Kortkamp tmueko@kommunity.net Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomas Verbaitis tomasv@megalogika.lt Tomasz Walaszek tmwalaszek@gmail.com Tomaz Muraus kami@k5-storitve.net Tomek Cedro tomek.cedro@gmail.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tomoyuki Sakurai cherry@trombik.org Toni Andjelkovic toni@soth.at Toni Gundogdu legatvs@gmail.com Toni Viemero toni.viemero@iki.fi Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher tonym@biolateral.com.au Tony Shadwick numbski@hksilver.net Tor Halvard "Squat" Furulund squat@squat.no Torbjorn Granlund tege@matematik.su.se Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Toshiya SAITOH toshiya@saitoh.nu Travis Campbell hcoyote@ghostar.org Travis Poppe tlp@liquidx.org Trefor S. trefor@flevel.co.uk Trenton Schulz twschulz@cord.edu Trevor Blackwell tlb@viaweb.com Trevor Cornpropst tcornpropst@cox.net Troels Kofoed Jacobsen tkjacobsen@gmail.com Tsung-Han Yeh snowfly@yuntech.edu.tw Tz-Huan Huang tzhuan@gmail.com Tzanetos Balitsaris tzabal@it.teithe.gr UMENO Takashi umeno@rr.iij4u.or.jp URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Udo Schweigert udo.schweigert@siemens.com Uffe Jakobsen uffe@uffe.org Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de Ullrich Franke trash.esiac@googlemail.com Uwe Arndt arndt@mailhost.uni-koblenz.de Uwe Pierau uwe.pierau@tu-clausthal.de Vaggelis Typaldos frances@mylannet.gr Vadim Belman voland@catpipe.net Vadim Chekan vadim@gc.lviv.ua Vadim Goncharov vadim_nuclight@mail.ru Vadim Kolontsov vadim@tversu.ac.ru Vadim Kurland vadim@fwbuilder.org Vadim Mikhailov mvp@braz.ru Vaida Bogdan vaida.bogdan@gmail.com Vaidas Zlotkus r2@music.lt Valentin Nechayev netch@lucky.net Valentin Zahariev curly@e-card.bg Valery Komarov komarov@valerka.net Van Jacobson van@ee.lbl.gov Vany Serezhkin ivan@serezhkin.com Vaclav Haisman v.haisman@sh.cvut.cz Vasek Balcar vasek@ti.cz Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vassili Tchersky vt@bsd-fr.org Vernon J. Schryver vjs@mica.denver.sgi.com Veselin Slavov vess@btc.net Vic Abell abe@cc.purdue.edu Victor Cruceru victor.cruceru@gmail.com Victor Popov v.a.popov@gmail.com Victor Semionov semionov@mail.bg Viktor Fomichev vfom@narod.ru Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@DNALOGIC.NET Vincent Tantardini vinc@freebsd-fr.org Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vitaly Magerya vmagerya@gmail.com Vivek Khera vivek@khera.org Vlad GALU dudu@dudu.ro Vlad V. Teterya vlad@vlad.uz.ua Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Gorelov virtual.lark@gmail.com Vladimir Kurtikov vk@vk.pp.ru Vladimir Kushnir kushn@mail.kar.net Vladimir Osintsev oc@nm.ru Vladimir Savichev vlad@ariel.phys.wesleyan.edu Volker Theile votdev@gmx.de Volker Quetschke quetschke@scytek.de Volodymyr Kostyrko c.kworr@gmail.com Vsevolod Lobko seva@ip.net.ua Vyacheslav Anikin ghos@mail.ru Vyacheslav Ivanchenko ivi@dhs.net.ru W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Waitman Gobble waitman@waitman.net Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Walter Hop walter@binity.com Walter Venable weaseal@hotmail.com Warren Toomey wkt@csadfa.cs.adfa.oz.au Watanabe Kazuhiro CQG00620@nifty.ne.jp Wayne Scott wscott@ichips.intel.com Wei-Hao Syu whsyu@arbor.ee.ntu.edu.tw Wei-Yu Chen weiyu.csie@gmail.com Wei Guo darcsis@gmail.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@withagen.nl Willem van Engen wvengen@stack.nl William Jolitz withheld William Josephson wkj-freebsd@honk.eecs.harvard.edu William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de - Wolfgang Stanglmeier - wolf@FreeBSD.org + &a.wolf.email; Woodchuck Dave djv@bedford.net Woody Carey woodycarey@hotmail.com Wouter Van Hemel wouter@pair.com Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW - &a.wylie; + &a.wylie.email; Xavier Beaudouin kiwi@oav.net Yamagi Burmeister yamagi@yamagi.org Yanhui Shen shen.elf@gmail.com Yann Berthier yb@bachibouzouk.org Yannis Kotsinos zookie@med.auth.gr Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yi-Feng Tzeng yftzeng@gmail.com Yi-Hsuan Hsin mhsin@mhsin.org Ying-Chieh Chen yinjieh@csie.nctu.edu.tw Yinghong Liu relaxbsd@gmail.com Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko SARUMRU mistral@imasy.or.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yu-Shun Wang yushunwa@isi.edu Yuan-Chung Hsiao ychsiao@ychsiao.idv.tw Yuan Jue yuanjue@yuanjue.net Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yuichiro AIZAWA yaizawa@mdbl.sfc.keio.ac.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yuki SHIMAZU y.shimazu@nifty.com Yuri Kurenkov y.kurenkov@init.ru Yuriy N. Shkandybin jura@netams.com Yuriy Tsibizov Yuriy.Tsibizov@gfk.ru Yusuke Nawano azuki@azkey.org Yu-Xi Lim yuxi@gmx.net Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuukis Ys@PixyGarden.net Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Garner zach@neurosoft.org Zach Heilig zach@gaffaneys.com Zach Thompson hideo@lastamericanempire.com Zach Zurflu zach@pabst.bendnet.com Zachariah Thompson lin-chi@lastamericanempire.com Zak Johnson zakj@nox.cx Zane C. Bowers vvelox@vvelox.net Zhen REN bg1tpt@gmail.com Zhihao Yuan lichray@gmail.com Zhixiang JIANG luckrill@yahoo.com.cn Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw appleboy appleboy.tw@gmail.com arci vega@sophia.inria.fr ayunyan ayunyan@gmail.com Bartoletti coder@tuxfamily.org der Mouse mouse@Collatz.McRCIM.McGill.EDU Piotr Szerman pmsz@tlen.pl rossiya rossiya@gmail.com diff --git a/en_US.ISO8859-1/articles/contributors/contrib.committers.xml b/en_US.ISO8859-1/articles/contributors/contrib.committers.xml index 3fcedcc145..22cdc7253c 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.committers.xml +++ b/en_US.ISO8859-1/articles/contributors/contrib.committers.xml @@ -1,1689 +1,1689 @@ - &a.ariff; + &a.ariff.email; - &a.tabthorpe; + &a.tabthorpe.email; - &a.eadler; + &a.eadler.email; - &a.akiyama; + &a.akiyama.email; - &a.monthadar; + &a.monthadar.email; - &a.ambrisko; + &a.ambrisko.email; - &a.shaun; + &a.shaun.email; - &a.brix; + &a.brix.email; - &a.jonathan; + &a.jonathan.email; - &a.mandree; + &a.mandree.email; - &a.will; + &a.will.email; - &a.dim; + &a.dim.email; - &a.mva; + &a.mva.email; - &a.araujo; + &a.araujo.email; - &a.mat; + &a.mat.email; - &a.syuu; + &a.syuu.email; - &a.gavin; + &a.gavin.email; - &a.jsa; + &a.jsa.email; - &a.jadawin; + &a.jadawin.email; - &a.timur; + &a.timur.email; - &a.jhb; + &a.jhb.email; - &a.gjb; + &a.gjb.email; - &a.art; + &a.art.email; - &a.kib; + &a.kib.email; - &a.tobez; + &a.tobez.email; - &a.gber; + &a.gber.email; - &a.pb; + &a.pb.email; - &a.tdb; + &a.tdb.email; - &a.gblach; + &a.gblach.email; - &a.mbr; + &a.mbr.email; - &a.wblock; + &a.wblock.email; - &a.novel; + &a.novel.email; - &a.garga; + &a.garga.email; - &a.sbz; + &a.sbz.email; - &a.ebrandi; + &a.ebrandi.email; - &a.harti; + &a.harti.email; - &a.makc; + &a.makc.email; - &a.antoine; + &a.antoine.email; - &a.db; + &a.db.email; - &a.sbruno; + &a.sbruno.email; - &a.brueffer; + &a.brueffer.email; - &a.markus; + &a.markus.email; - &a.oleg; + &a.oleg.email; - &a.jchandra; + &a.jchandra.email; - &a.acm; + &a.acm.email; - &a.gahr; + &a.gahr.email; - &a.adrian; + &a.adrian.email; - &a.dchagin; + &a.dchagin.email; - &a.charnier; + &a.charnier.email; - &a.jon; + &a.jon.email; - &a.loader; + &a.loader.email; - &a.luoqi; + &a.luoqi.email; - &a.ache; + &a.ache.email; - &a.melifaro; + &a.melifaro.email; - &a.theraven; + &a.theraven.email; - &a.davidch; + &a.davidch.email; - &a.marcus; + &a.marcus.email; - &a.tijl; + &a.tijl.email; - &a.rakuco; + &a.rakuco.email; - &a.alc; + &a.alc.email; - &a.cracauer; + &a.cracauer.email; - &a.brucec; + &a.brucec.email; - &a.culot; + &a.culot.email; - &a.joel; + &a.joel.email; - &a.bapt; + &a.bapt.email; - &a.davidc; + &a.davidc.email; - &a.brd; + &a.brd.email; - &a.brooks; + &a.brooks.email; - &a.pjd; + &a.pjd.email; - &a.jwd; + &a.jwd.email; - &a.carl; + &a.carl.email; - &a.vd; + &a.vd.email; - &a.rdivacky; + &a.rdivacky.email; - &a.mdodd; + &a.mdodd.email; - &a.danfe; + &a.danfe.email; - &a.dd; + &a.dd.email; - &a.iedowse; + &a.iedowse.email; - &a.bdrewery; + &a.bdrewery.email; - &a.gad; + &a.gad.email; - &a.olivierd; + &a.olivierd.email; - &a.bruno; + &a.bruno.email; - &a.ale; + &a.ale.email; - &a.peadar; + &a.peadar.email; - &a.deischen; + &a.deischen.email; - &a.eivind; + &a.eivind.email; - &a.julian; + &a.julian.email; - &a.ae; + &a.ae.email; - &a.lme; + &a.lme.email; - &a.rse; + &a.rse.email; - &a.ru; + &a.ru.email; - &a.le; + &a.le.email; - &a.se; + &a.se.email; - &a.bde; + &a.bde.email; - &a.jasone; + &a.jasone.email; - &a.bf; + &a.bf.email; - &a.madpilot; + &a.madpilot.email; - &a.rafan; + &a.rafan.email; - &a.stefanf; + &a.stefanf.email; - &a.scf; + &a.scf.email; - &a.feld; + &a.feld.email; - &a.green; + &a.green.email; - &a.lioux; + &a.lioux.email; - &a.fanf; + &a.fanf.email; - &a.mdf; + &a.mdf.email; - &a.blackend; + &a.blackend.email; - &a.olli; + &a.olli.email; - &a.decke; + &a.decke.email; - &a.gallatin; + &a.gallatin.email; - &a.avg; + &a.avg.email; - &a.beat; + &a.beat.email; - &a.danger; + &a.danger.email; - &a.sjg; + &a.sjg.email; - &a.gibbs; + &a.gibbs.email; - &a.pfg; + &a.pfg.email; - &a.girgen; + &a.girgen.email; - &a.pgollucci; + &a.pgollucci.email; - &a.trociny; + &a.trociny.email; - &a.daichi; + &a.daichi.email; - &a.bgray; + &a.bgray.email; - &a.dg; + &a.dg.email; - &a.grehan; + &a.grehan.email; - &a.jamie; + &a.jamie.email; - &a.edwin; + &a.edwin.email; - &a.wg; + &a.wg.email; - &a.bar; + &a.bar.email; - &a.jmg; + &a.jmg.email; - &a.mjg; + &a.mjg.email; - &a.vg; + &a.vg.email; - &a.jhale; + &a.jhale.email; - &a.smh; + &a.smh.email; - &a.ehaupt; + &a.ehaupt.email; - &a.jhay; + &a.jhay.email; - &a.jh; + &a.jh.email; - &a.jgh; + &a.jgh.email; - &a.ghelmer; + &a.ghelmer.email; - &a.wen; + &a.wen.email; - &a.dhn; + &a.dhn.email; - &a.jhibbits; + &a.jhibbits.email; - &a.nhibma; + &a.nhibma.email; - &a.pho; + &a.pho.email; - &a.mich; + &a.mich.email; - &a.cognet; + &a.cognet.email; - &a.sunpoet; + &a.sunpoet.email; - &a.lwhsu; + &a.lwhsu.email; - &a.chinsan; + &a.chinsan.email; - &a.davide; + &a.davide.email; - &a.iwasaki; + &a.iwasaki.email; - &a.mjacob; + &a.mjacob.email; - &a.versus; + &a.versus.email; - &a.raj; + &a.raj.email; - &a.gj; + &a.gj.email; - &a.weongyo; + &a.weongyo.email; - &a.peterj; + &a.peterj.email; - &a.jinmei; + &a.jinmei.email; - &a.ahze; + &a.ahze.email; - &a.markj; + &a.markj.email; - &a.tj; + &a.tj.email; - &a.kan; + &a.kan.email; - &a.bjk; + &a.bjk.email; - &a.phk; + &a.phk.email; - &a.pluknet; + &a.pluknet.email; - &a.cokane; + &a.cokane.email; - &a.kargl; + &a.kargl.email; - &a.kato; + &a.kato.email; - &a.kris; + &a.kris.email; - &a.keramida; + &a.keramida.email; - &a.arved; + &a.arved.email; - &a.fjoe; + &a.fjoe.email; - &a.manolis; + &a.manolis.email; - &a.kientzle; + &a.kientzle.email; - &a.jkim; + &a.jkim.email; - &a.jceel; + &a.jceel.email; - &a.koobs; + &a.koobs.email; - &a.jkois; + &a.jkois.email; - &a.motoyuki; + &a.motoyuki.email; - &a.maxim; + &a.maxim.email; - &a.taras; + &a.taras.email; - &a.jkoshy; + &a.jkoshy.email; - &a.wkoszek; + &a.wkoszek.email; - &a.ak; + &a.ak.email; - &a.skreuzer; + &a.skreuzer.email; - &a.gabor; + &a.gabor.email; - &a.anchie; + &a.anchie.email; - &a.rik; + &a.rik.email; - &a.kuriyama; + &a.kuriyama.email; - &a.gleb; + &a.gleb.email; - &a.rene; + &a.rene.email; - &a.jlaffaye; + &a.jlaffaye.email; - &a.clement; + &a.clement.email; - &a.mlaier; + &a.mlaier.email; - &a.erwin; + &a.erwin.email; - &a.martymac; + &a.martymac.email; - &a.glarkin; + &a.glarkin.email; - &a.benl; + &a.benl.email; - &a.dru; + &a.dru.email; - &a.jlh; + &a.jlh.email; - &a.leeym; + &a.leeym.email; - &a.sam; + &a.sam.email; - &a.oliver; + &a.oliver.email; - &a.grog; + &a.grog.email; - &a.netchild; + &a.netchild.email; - &a.ian; + &a.ian.email; - &a.achim; + &a.achim.email; - &a.truckman; + &a.truckman.email; - &a.glewis; + &a.glewis.email; - &a.qingli; + &a.qingli.email; - &a.delphij; + &a.delphij.email; - &a.avatar; + &a.avatar.email; - &a.pclin; + &a.pclin.email; - &a.yzlin; + &a.yzlin.email; - &a.linimon; + &a.linimon.email; - &a.dryice; + &a.dryice.email; - &a.kevlo; + &a.kevlo.email; - &a.zml; + &a.zml.email; - &a.nox; + &a.nox.email; - &a.remko; + &a.remko.email; - &a.avl; + &a.avl.email; - &a.issyl0; + &a.issyl0.email; - &a.scottl; + &a.scottl.email; - &a.imp; + &a.imp.email; - &a.ade; + &a.ade.email; - &a.eri; + &a.eri.email; - &a.pav; + &a.pav.email; - &a.rmacklem; + &a.rmacklem.email; - &a.kmacy; + &a.kmacy.email; - &a.rm; + &a.rm.email; - &a.mtm; + &a.mtm.email; - &a.jmallett; + &a.jmallett.email; - &a.dwmalone; + &a.dwmalone.email; - &a.nobutaka; + &a.nobutaka.email; - &a.amdmi3; + &a.amdmi3.email; - &a.dmarion; + &a.dmarion.email; - &a.kwm; + &a.kwm.email; - &a.emaste; + &a.emaste.email; - &a.cherry; + &a.cherry.email; - &a.matusita; + &a.matusita.email; - &a.mm; + &a.mm.email; - &a.sem; + &a.sem.email; - &a.mckay; + &a.mckay.email; - &a.mckusick; + &a.mckusick.email; - &a.jmelo; + &a.jmelo.email; - &a.ken; + &a.ken.email; - &a.mezz; + &a.mezz.email; - &a.dinoex; + &a.dinoex.email; - &a.sanpei; + &a.sanpei.email; - &a.rmh; + &a.rmh.email; - &a.stephen; + &a.stephen.email; - &a.marcel; + &a.marcel.email; - &a.kmoore; + &a.kmoore.email; - &a.marck; + &a.marck.email; - &a.mav; + &a.mav.email; - &a.lippe; + &a.lippe.email; - &a.markm; + &a.markm.email; - &a.knu; + &a.knu.email; - &a.max; + &a.max.email; - &a.maho; + &a.maho.email; - &a.trasz; + &a.trasz.email; - &a.neel; + &a.neel.email; - &a.dbn; + &a.dbn.email; - &a.bland; + &a.bland.email; - &a.gnn; + &a.gnn.email; - &a.simon; + &a.simon.email; - &a.rnoland; + &a.rnoland.email; - &a.anders; + &a.anders.email; - &a.obrien; + &a.obrien.email; - &a.ohauer; + &a.ohauer.email; - &a.olgeni; + &a.olgeni.email; - &a.andre; + &a.andre.email; - &a.osa; + &a.osa.email; - &a.philip; + &a.philip.email; - &a.jpaetzel; + &a.jpaetzel.email; - &a.pgj; + &a.pgj.email; - &a.hiren; + &a.hiren.email; - &a.hmp; + &a.hmp.email; - &a.fluffy; + &a.fluffy.email; - &a.np; + &a.np.email; - &a.wpaul; + &a.wpaul.email; - &a.rpaulo; + &a.rpaulo.email; - &a.dumbbell; + &a.dumbbell.email; - &a.mp; + &a.mp.email; - &a.pawel; + &a.pawel.email; - &a.roam; + &a.roam.email; - &a.cperciva; + &a.cperciva.email; - &a.alfred; + &a.alfred.email; - &a.csjp; + &a.csjp.email; - &a.wes; + &a.wes.email; - &a.gerald; + &a.gerald.email; - &a.sperber; + &a.sperber.email; - &a.sepotvin; + &a.sepotvin.email; - &a.mpp; + &a.mpp.email; - &a.thomas; + &a.thomas.email; - &a.hq; + &a.hq.email; - &a.dfr; + &a.dfr.email; - &a.attilio; + &a.attilio.email; - &a.lbr; + &a.lbr.email; - &a.darrenr; + &a.darrenr.email; - &a.crees; + &a.crees.email; - &a.mr; + &a.mr.email; - &a.bcr; + &a.bcr.email; - &a.trhodes; + &a.trhodes.email; - &a.benno; + &a.benno.email; - &a.beech; + &a.beech.email; - &a.matteo; + &a.matteo.email; - &a.luigi; + &a.luigi.email; - &a.jeff; + &a.jeff.email; - &a.roberto; + &a.roberto.email; - &a.rodrigc; + &a.rodrigc.email; - &a.guido; + &a.guido.email; - &a.rea; + &a.rea.email; - &a.ray; + &a.ray.email; - &a.ps; + &a.ps.email; - &a.wsalamon; + &a.wsalamon.email; - &a.bsam; + &a.bsam.email; - &a.hrs; + &a.hrs.email; - &a.bschmidt; + &a.bschmidt.email; - &a.sos; + &a.sos.email; - &a.wosch; + &a.wosch.email; - &a.ed; + &a.ed.email; - &a.cy; + &a.cy.email; - &a.das; + &a.das.email; - &a.scheidell; + &a.scheidell.email; - &a.schweikh; + &a.schweikh.email; - &a.matthew; + &a.matthew.email; - &a.tmseck; + &a.tmseck.email; - &a.stas; + &a.stas.email; - &a.hselasky; + &a.hselasky.email; - &a.johans; + &a.johans.email; - &a.lev; + &a.lev.email; - &a.gshapiro; + &a.gshapiro.email; - &a.wxs; + &a.wxs.email; - &a.nork; + &a.nork.email; - &a.simokawa; + &a.simokawa.email; - &a.syrinx; + &a.syrinx.email; - &a.vanilla; + &a.vanilla.email; - &a.ashish; + &a.ashish.email; - &a.silby; + &a.silby.email; - &a.bms; + &a.bms.email; - &a.jls; + &a.jls.email; - &a.demon; + &a.demon.email; - &a.skv; + &a.skv.email; - &a.flo; + &a.flo.email; - &a.glebius; + &a.glebius.email; - &a.kensmith; + &a.kensmith.email; - &a.des; + &a.des.email; - &a.sobomax; + &a.sobomax.email; - &a.asomers; + &a.asomers.email; - &a.brian; + &a.brian.email; - &a.sson; + &a.sson.email; - &a.ssouhlal; + &a.ssouhlal.email; - &a.loos; + &a.loos.email; - &a.uqs; + &a.uqs.email; - &a.mohans; + &a.mohans.email; - &a.vsevolod; + &a.vsevolod.email; - &a.zi; + &a.zi.email; - &a.lstewart; + &a.lstewart.email; - &a.rrs; + &a.rrs.email; - &a.rstone; + &a.rstone.email; - &a.xride; + &a.xride.email; - &a.marius; + &a.marius.email; - &a.cs; + &a.cs.email; - &a.sumikawa; + &a.sumikawa.email; - &a.clsung; + &a.clsung.email; - &a.ryusuke; + &a.ryusuke.email; - &a.suz; + &a.suz.email; - &a.nyan; + &a.nyan.email; - &a.sahil; + &a.sahil.email; - &a.tota; + &a.tota.email; - &a.tanimura; + &a.tanimura.email; - &a.romain; + &a.romain.email; - &a.sylvio; + &a.sylvio.email; - &a.dteske; + &a.dteske.email; - &a.itetcu; + &a.itetcu.email; - &a.mi; + &a.mi.email; - &a.gordon; + &a.gordon.email; - &a.lth; + &a.lth.email; - &a.jase; + &a.jase.email; - &a.lx; + &a.lx.email; - &a.fabient; + &a.fabient.email; - &a.thierry; + &a.thierry.email; - &a.thompsa; + &a.thompsa.email; - &a.flz; + &a.flz.email; - &a.yar; + &a.yar.email; - &a.jilles; + &a.jilles.email; - &a.andreast; + &a.andreast.email; - &a.ganbold; + &a.ganbold.email; - &a.tuexen; + &a.tuexen.email; - &a.andrew; + &a.andrew.email; - &a.gonzo; + &a.gonzo.email; - &a.ume; + &a.ume.email; - &a.ups; + &a.ups.email; - &a.vanhu; + &a.vanhu.email; - &a.bryanv; + &a.bryanv.email; - &a.avilla; + &a.avilla.email; - &a.nivit; + &a.nivit.email; - &a.jfv; + &a.jfv.email; - &a.ivoras; + &a.ivoras.email; - &a.ticso; + &a.ticso.email; - &a.stefan; + &a.stefan.email; - &a.kaiw; + &a.kaiw.email; - &a.takawata; + &a.takawata.email; - &a.rwatson; + &a.rwatson.email; - &a.adamw; + &a.adamw.email; - &a.naddy; + &a.naddy.email; - &a.peter; + &a.peter.email; - &a.dwhite; + &a.dwhite.email; - &a.nwhitehorn; + &a.nwhitehorn.email; - &a.miwi; + &a.miwi.email; - &a.swills; + &a.swills.email; - &a.wollman; + &a.wollman.email; - &a.joerg; + &a.joerg.email; - &a.davidxu; + &a.davidxu.email; - &a.emax; + &a.emax.email; - &a.yongari; + &a.yongari.email; - &a.zec; + &a.zec.email; - &a.bz; + &a.bz.email; - &a.zeising; + &a.zeising.email; - &a.phantom; + &a.phantom.email; - &a.sephe; + &a.sephe.email; - &a.zont; + &a.zont.email; - &a.az; + &a.az.email; diff --git a/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml b/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml index 45028ce029..e2a4163d48 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml +++ b/en_US.ISO8859-1/articles/contributors/contrib.corealumni.xml @@ -1,188 +1,188 @@ - &a.attilio; (2012) + &a.attilio.email; (2012) - &a.wilko; (2006 - 2012) + &a.wilko.email; (2006 - 2012) - &a.brooks; (2006 - 2012) + &a.brooks.email; (2006 - 2012) - &a.pav; (2010 - 2012) + &a.pav.email; (2010 - 2012) - &a.cperciva; (2010 - 2012) + &a.cperciva.email; (2010 - 2012) - &a.rwatson; (2000 - 2012) + &a.rwatson.email; (2000 - 2012) - &a.keramida; (2006 - 2010) + &a.keramida.email; (2006 - 2010) - &a.kris; (2008 - 2010) + &a.kris.email; (2008 - 2010) - &a.gnn; (2006 - 2010) + &a.gnn.email; (2006 - 2010) - &a.murray; (2002 - 2010) + &a.murray.email; (2002 - 2010) - &a.wes; (2002 - 2008) + &a.wes.email; (2002 - 2008) - &a.imp; (2000 - 2008, 2010 - 2012) + &a.imp.email; (2000 - 2008, 2010 - 2012) - &a.markm; (2002 - 2006) + &a.markm.email; (2002 - 2006) - &a.kuriyama; (2002 - 2006) + &a.kuriyama.email; (2002 - 2006) - &a.scottl; (2004 - 2005) + &a.scottl.email; (2004 - 2005) - &a.grog; (2000 - 2004) + &a.grog.email; (2000 - 2004) - &a.dg; (1992 - 2002) + &a.dg.email; (1992 - 2002) - &a.dfr; (1999 - 2002) + &a.dfr.email; (1999 - 2002) - &a.msmith; (2000 - 2002) + &a.msmith.email; (2000 - 2002) - &a.jkh; (1992 - 2002) + &a.jkh.email; (1992 - 2002) - &a.asami; (1993 - 2001) + &a.asami.email; (1993 - 2001) - &a.ache; (1993 - 2000) + &a.ache.email; (1993 - 2000) - &a.jmb; (1993 - 2000) + &a.jmb.email; (1993 - 2000) - &a.bde; (1992 - 2000) + &a.bde.email; (1992 - 2000) - &a.gibbs; (1993 - 2000) + &a.gibbs.email; (1993 - 2000) - &a.rich; (1994 - 2000) + &a.rich.email; (1994 - 2000) - &a.phk; (1992 - 2000) + &a.phk.email; (1992 - 2000) - &a.gpalmer; (1993 - 2000) + &a.gpalmer.email; (1993 - 2000) - &a.sos; (1993 - 2000) + &a.sos.email; (1993 - 2000) - &a.wollman; (1993 - 2000) + &a.wollman.email; (1993 - 2000) - &a.joerg; (1995 - 2000) + &a.joerg.email; (1995 - 2000) - &a.jdp; (1997 - 2000) + &a.jdp.email; (1997 - 2000) - &a.guido; (1995 - 1999) + &a.guido.email; (1995 - 1999) - &a.dyson; (1993 - 1998) + &a.dyson.email; (1993 - 1998) - &a.nate; (1992 - 1996) + &a.nate.email; (1992 - 1996) - &a.rgrimes; (1992 - 1995) + &a.rgrimes.email; (1992 - 1995) - &a.ats; (1992 - 1995) + &a.ats.email; (1992 - 1995) - &a.csgr; (1993 - 1995) + &a.csgr.email; (1993 - 1995) - &a.paul; (1992 - 1995) + &a.paul.email; (1992 - 1995) - &a.smace; (1993 - 1994) + &a.smace.email; (1993 - 1994) - &a.alm; (1993 - 1994) + &a.alm.email; (1993 - 1994) - &a.chmr; (1993 - 1994) + &a.chmr.email; (1993 - 1994) - &a.jtc; (1992 - 1993) + &a.jtc.email; (1992 - 1993) diff --git a/en_US.ISO8859-1/articles/contributors/contrib.develalumni.xml b/en_US.ISO8859-1/articles/contributors/contrib.develalumni.xml index 319651d9d9..5ef408d38e 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.develalumni.xml +++ b/en_US.ISO8859-1/articles/contributors/contrib.develalumni.xml @@ -1,1125 +1,1125 @@ - &a.randi; (2010 - 2012) + &a.randi.email; (2010 - 2012) - &a.zack; (2010 - 2012) + &a.zack.email; (2010 - 2012) - &a.erik; (2008 - 2012) + &a.erik.email; (2008 - 2012) - &a.carvay; (2008 - 2012) + &a.carvay.email; (2008 - 2012) - &a.lulf; (2007 - 2012) + &a.lulf.email; (2007 - 2012) - &a.mnag; (2005 - 2012) + &a.mnag.email; (2005 - 2012) - &a.ceri; (2002 - 2012) + &a.ceri.email; (2002 - 2012) Doug Barton (2000 - 2012) - &a.wilko; (2000 - 2012) + &a.wilko.email; (2000 - 2012) - &a.murray; (2000 - 2012) + &a.murray.email; (2000 - 2012) - &a.steve; (1996 - 2012) + &a.steve.email; (1996 - 2012) - &a.jacula; (2010 - 2011) + &a.jacula.email; (2010 - 2011) - &a.nemoliu; (2007 - 2011) + &a.nemoliu.email; (2007 - 2011) - &a.alexbl; (2006 - 2011) + &a.alexbl.email; (2006 - 2011) - &a.alepulver; (2006 - 2011) + &a.alepulver.email; (2006 - 2011) - &a.tmclaugh; (2005 - 2011) + &a.tmclaugh.email; (2005 - 2011) - &a.anray; (2005 - 2011) + &a.anray.email; (2005 - 2011) - &a.niels; (2004 - 2011) + &a.niels.email; (2004 - 2011) - &a.sergei; (2003 - 2011) + &a.sergei.email; (2003 - 2011) - &a.krion; (2003 - 2011) + &a.krion.email; (2003 - 2011) - &a.mux; (2002 - 2011) + &a.mux.email; (2002 - 2011) - &a.hm; (1998 - 2011) + &a.hm.email; (1998 - 2011) - &a.ijliao; (2001 - 2011) + &a.ijliao.email; (2001 - 2011) - &a.scrappy; (1996 - 2011) + &a.scrappy.email; (1996 - 2011) - &a.snb; (2009 - 2010) + &a.snb.email; (2009 - 2010) - &a.cbzimmer; (2009 - 2010) + &a.cbzimmer.email; (2009 - 2010) - &a.bushman; (2007 - 2010) + &a.bushman.email; (2007 - 2010) - &a.benjsc; (2007 - 2010) + &a.benjsc.email; (2007 - 2010) - &a.rink; (2006 - 2010) + &a.rink.email; (2006 - 2010) - &a.piso; (2006 - 2010) + &a.piso.email; (2006 - 2010) - &a.laszlof; (2006 - 2010) + &a.laszlof.email; (2006 - 2010) - &a.bvs; (2005 - 2010) + &a.bvs.email; (2005 - 2010) - &a.barner; (2005 - 2010) + &a.barner.email; (2005 - 2010) - &a.vs; (2004 - 2010) + &a.vs.email; (2004 - 2010) - &a.dds; (2003 - 2010) + &a.dds.email; (2003 - 2010) - &a.perky; (2002 - 2010) + &a.perky.email; (2002 - 2010) - &a.yoichi; (2001 - 2010) + &a.yoichi.email; (2001 - 2010) - &a.okazaki; (2000 - 2010) + &a.okazaki.email; (2000 - 2010) - &a.cjh; (2000 - 2010) + &a.cjh.email; (2000 - 2010) - &a.jesusr; (1998 - 2010) + &a.jesusr.email; (1998 - 2010) - &a.sat; (2006 - 2009) + &a.sat.email; (2006 - 2009) - &a.jcamou; (2005 - 2009) + &a.jcamou.email; (2005 - 2009) - &a.rushani; (2003 - 2009) + &a.rushani.email; (2003 - 2009) - &a.nik; (1998 - 2009) + &a.nik.email; (1998 - 2009) - &a.lofi; (2003 - 2009) + &a.lofi.email; (2003 - 2009) - &a.den; (2003 - 2009) + &a.den.email; (2003 - 2009) - &a.obraun; (2002 - 2009) + &a.obraun.email; (2002 - 2009) - &a.anholt; (2002 - 2009) + &a.anholt.email; (2002 - 2009) - &a.mwlucas; (2001 - 2009) + &a.mwlucas.email; (2001 - 2009) - &a.chern; (2001 - 2009) + &a.chern.email; (2001 - 2009) - &a.mita; (2000 - 2009) + &a.mita.email; (2000 - 2009) - &a.horikawa; (2000 - 2009) + &a.horikawa.email; (2000 - 2009) - &a.clive; (2000 - 2009) + &a.clive.email; (2000 - 2009) - &a.bmah; (2000 - 2009) + &a.bmah.email; (2000 - 2009) - &a.gioria; (1999 - 2009) + &a.gioria.email; (1999 - 2009) - &a.tg; (1995 - 2009) + &a.tg.email; (1995 - 2009) - &a.kishore; (2007 - 2008) + &a.kishore.email; (2007 - 2008) - &a.twinterg; (2006 - 2008) + &a.twinterg.email; (2006 - 2008) - &a.koitsu; (2006 - 2008) + &a.koitsu.email; (2006 - 2008) - &a.bakul; (2006 - 2008) + &a.bakul.email; (2006 - 2008) - &a.jylefort; (2005 - 2008) + &a.jylefort.email; (2005 - 2008) - &a.garys; (2005 - 2008) + &a.garys.email; (2005 - 2008) - &a.damien; (2005 - 2008) + &a.damien.email; (2005 - 2008) - &a.aaron; (2005 - 2008) + &a.aaron.email; (2005 - 2008) - &a.tackerman; (2004 - 2008) + &a.tackerman.email; (2004 - 2008) - &a.metal; (2004 - 2008) + &a.metal.email; (2004 - 2008) - &a.marks; (2004 - 2008) + &a.marks.email; (2004 - 2008) - &a.lesi; (2004 - 2008) + &a.lesi.email; (2004 - 2008) - &a.josef; (2004 - 2008) + &a.josef.email; (2004 - 2008) - &a.dhartmei; (2004 - 2008) + &a.dhartmei.email; (2004 - 2008) - &a.sah; (2004 - 2008) + &a.sah.email; (2004 - 2008) - &a.rsm; (2003 - 2008) + &a.rsm.email; (2003 - 2008) - &a.hoek; (2003 - 2008) + &a.hoek.email; (2003 - 2008) - &a.eik; (2003 - 2008) + &a.eik.email; (2003 - 2008) - &a.matk; (2003 - 2008) + &a.matk.email; (2003 - 2008) - &a.seanc; (2002 - 2008) + &a.seanc.email; (2002 - 2008) - &a.njl; (2002 - 2008) + &a.njl.email; (2002 - 2008) - &a.ikob; (2002 - 2008) + &a.ikob.email; (2002 - 2008) - &a.pdeuskar; (2001 - 2008) + &a.pdeuskar.email; (2001 - 2008) - &a.mikeh; (2001 - 2008) + &a.mikeh.email; (2001 - 2008) - &a.shiba; (2000 - 2008) + &a.shiba.email; (2000 - 2008) - &a.pat; (2000 - 2008) + &a.pat.email; (2000 - 2008) - &a.onoe; (2000 - 2008) + &a.onoe.email; (2000 - 2008) - &a.lkoeller; (2000 - 2008) + &a.lkoeller.email; (2000 - 2008) - &a.jayanth; (2000 - 2008) + &a.jayanth.email; (2000 - 2008) - &a.jake; (2000 - 2008) + &a.jake.email; (2000 - 2008) - &a.dmlb; (2000 - 2008) + &a.dmlb.email; (2000 - 2008) - &a.bmilekic; (2000 - 2008) + &a.bmilekic.email; (2000 - 2008) - &a.babkin; (2000 - 2008) + &a.babkin.email; (2000 - 2008) - &a.joe; (1999 - 2008) + &a.joe.email; (1999 - 2008) - &a.imura; (1999 - 2008) + &a.imura.email; (1999 - 2008) - &a.andy; (1999 - 2008) + &a.andy.email; (1999 - 2008) - &a.shige; (1999 - 2008) + &a.shige.email; (1999 - 2008) - &a.hosokawa; (1998 - 2008) + &a.hosokawa.email; (1998 - 2008) - &a.foxfair; (1998 - 2008) + &a.foxfair.email; (1998 - 2008) - &a.billf; (1998 - 2008) + &a.billf.email; (1998 - 2008) - &a.tegge; (1997 - 2008) + &a.tegge.email; (1997 - 2008) - &a.jlemon; (1997 - 2008) + &a.jlemon.email; (1997 - 2008) - &a.fenner; (1996 - 2008) + &a.fenner.email; (1996 - 2008) - &a.andreas; (1996 - 2008) + &a.andreas.email; (1996 - 2008) - &a.jkh; (1993 - 2008) + &a.jkh.email; (1993 - 2008) - &a.jdp; ( - 2008) + &a.jdp.email; ( - 2008) - &a.hsu; ( - 2008) + &a.hsu.email; ( - 2008) - &a.farrokhi; (2006 - 2007) + &a.farrokhi.email; (2006 - 2007) - &a.cel; (2006 - 2007) + &a.cel.email; (2006 - 2007) - &a.vsevolod; (2005 - 2007) + &a.vsevolod.email; (2005 - 2007) - &a.lawrance; (2005 - 2007) + &a.lawrance.email; (2005 - 2007) - &a.rees; (2004 - 2007) + &a.rees.email; (2004 - 2007) - &a.tjr; (2002 - 2007) + &a.tjr.email; (2002 - 2007) - &a.johan; (2002 - 2007) + &a.johan.email; (2002 - 2007) - &a.markp; (2001 - 2007) + &a.markp.email; (2001 - 2007) - &a.jesper; (2001 - 2007) + &a.jesper.email; (2001 - 2007) - &a.eric; (2001 - 2007) + &a.eric.email; (2001 - 2007) - &a.trevor; (2000 - 2007) + &a.trevor.email; (2000 - 2007) - &a.non; (2000 - 2007) + &a.non.email; (2000 - 2007) - &a.kbyanc; (2000 - 2007) + &a.kbyanc.email; (2000 - 2007) - &a.jeh; (2000 - 2007) + &a.jeh.email; (2000 - 2007) - &a.gsutter; (2000 - 2007) + &a.gsutter.email; (2000 - 2007) - &a.bsd; (2000 - 2007) + &a.bsd.email; (2000 - 2007) - &a.tom; (1999 - 2007) + &a.tom.email; (1999 - 2007) - &a.mharo; (1999 - 2007) + &a.mharo.email; (1999 - 2007) - &a.chris; (1999 - 2007) + &a.chris.email; (1999 - 2007) - &a.bp; (1999 - 2007) + &a.bp.email; (1999 - 2007) - &a.archie; (1998 - 2007) + &a.archie.email; (1998 - 2007) - &a.vkashyap; (2004 - 2006) + &a.vkashyap.email; (2004 - 2006) - &a.niklas; (2004 - 2006) + &a.niklas.email; (2004 - 2006) - &a.smkelly; (2003 - 2006) + &a.smkelly.email; (2003 - 2006) - &a.arun; (2003 - 2006) + &a.arun.email; (2003 - 2006) - &a.am; (2003 - 2006) + &a.am.email; (2003 - 2006) - &a.scop; (2002 - 2006) + &a.scop.email; (2002 - 2006) - &a.mheinen; (2002 - 2006) + &a.mheinen.email; (2002 - 2006) - &a.jennifer; (2002 - 2006) + &a.jennifer.email; (2002 - 2006) - &a.adamw; (2002 - 2006) + &a.adamw.email; (2002 - 2006) - &a.znerd; (2001 - 2006) + &a.znerd.email; (2001 - 2006) - &a.keichii; (2001 - 2006) + &a.keichii.email; (2001 - 2006) - &a.ue; (2001 - 2006) + &a.ue.email; (2001 - 2006) - &a.tmm; (2001 - 2006) + &a.tmm.email; (2001 - 2006) - &a.robert; (2001 - 2006) + &a.robert.email; (2001 - 2006) - &a.petef; (2001 - 2006) + &a.petef.email; (2001 - 2006) - &a.mike; (2001 - 2006) + &a.mike.email; (2001 - 2006) - &a.greid; (2001 - 2006) + &a.greid.email; (2001 - 2006) - &a.cjc; (2001 - 2006) + &a.cjc.email; (2001 - 2006) - &a.bbraun; (2001 - 2006) + &a.bbraun.email; (2001 - 2006) - &a.sf; (2000 - 2006) + &a.sf.email; (2000 - 2006) - &a.kiri; (2000 - 2006) + &a.kiri.email; (2000 - 2006) - &a.dannyboy; (2000 - 2006) + &a.dannyboy.email; (2000 - 2006) - &a.ben; (2000 - 2006) + &a.ben.email; (2000 - 2006) - &a.sheldonh; (1999 - 2006) + &a.sheldonh.email; (1999 - 2006) - &a.roger; (1999 - 2006) + &a.roger.email; (1999 - 2006) - &a.nsayer; (1999 - 2006) + &a.nsayer.email; (1999 - 2006) - &a.nbm; (1999 - 2006) + &a.nbm.email; (1999 - 2006) - &a.jedgar; (1999 - 2006) + &a.jedgar.email; (1999 - 2006) - &a.nsouch; (1998 - 2006) + &a.nsouch.email; (1998 - 2006) - &a.nectar; (1998 - 2006) + &a.nectar.email; (1998 - 2006) - &a.mph; (1998 - 2006) + &a.mph.email; (1998 - 2006) - &a.kjc; (1997 - 2006) + &a.kjc.email; (1997 - 2006) - &a.hanai; (1997 - 2006) + &a.hanai.email; (1997 - 2006) - &a.viny; (2004 - 2005) + &a.viny.email; (2004 - 2005) - &a.stephane; (2002 - 2005) + &a.stephane.email; (2002 - 2005) - &a.arr; (2001 - 2005) + &a.arr.email; (2001 - 2005) - &a.sada; (1998 - 2005) + &a.sada.email; (1998 - 2005) - &a.flathill; (1998 - 2005) + &a.flathill.email; (1998 - 2005) - &a.paul; (1993 - 2005) + &a.paul.email; (1993 - 2005) - &a.mini; (2002 - 2004) + &a.mini.email; (2002 - 2004) - &a.emoore; (2002 - 2004) + &a.emoore.email; (2002 - 2004) - &a.wjv; (2001 - 2004) + &a.wjv.email; (2001 - 2004) - &a.rpratt; (2001 - 2004) + &a.rpratt.email; (2001 - 2004) - &a.orion; (2001 - 2004) + &a.orion.email; (2001 - 2004) - &a.logo; (2001 - 2004) + &a.logo.email; (2001 - 2004) - &a.tomsoft; (2000 - 2004) + &a.tomsoft.email; (2000 - 2004) - &a.patrick; (2000 - 2004) + &a.patrick.email; (2000 - 2004) - &a.chm; (2000 - 2004) + &a.chm.email; (2000 - 2004) - &a.taoka; (1999 - 2004) + &a.taoka.email; (1999 - 2004) - &a.jmas; (1999 - 2004) + &a.jmas.email; (1999 - 2004) - &a.dcs; (1999 - 2004) + &a.dcs.email; (1999 - 2004) - &a.dan; (1999 - 2004) + &a.dan.email; (1999 - 2004) - &a.smace; (1993 - 2004) + &a.smace.email; (1993 - 2004) - &a.alex; ( - 2004) + &a.alex.email; ( - 2004) - &a.dwcjr; (2002 - 2003) + &a.dwcjr.email; (2002 - 2003) - &a.zarzycki; (2001 - 2003) + &a.zarzycki.email; (2001 - 2003) - &a.tshiozak; (2001 - 2003) + &a.tshiozak.email; (2001 - 2003) - &a.pirzyk; (2001 - 2003) + &a.pirzyk.email; (2001 - 2003) - &a.wsanchez; (2000 - 2003) + &a.wsanchez.email; (2000 - 2003) - &a.toshi; (2000 - 2003) + &a.toshi.email; (2000 - 2003) - &a.mb; (2000 - 2003) + &a.mb.email; (2000 - 2003) - &a.marko; (2000 - 2003) + &a.marko.email; (2000 - 2003) - &a.furuta; (2000 - 2003) + &a.furuta.email; (2000 - 2003) - &a.bean; (2000 - 2003) + &a.bean.email; (2000 - 2003) - &a.shin; (1999 - 2003) + &a.shin.email; (1999 - 2003) - &a.pho; (1999 - 2003) + &a.pho.email; (1999 - 2003) - &a.newton; (1999 - 2003) + &a.newton.email; (1999 - 2003) - &a.mtaylor; (1999 - 2003) + &a.mtaylor.email; (1999 - 2003) - &a.lile; (1999 - 2003) + &a.lile.email; (1999 - 2003) - &a.jim; (1999 - 2003) + &a.jim.email; (1999 - 2003) - &a.ejc; (1999 - 2003) + &a.ejc.email; (1999 - 2003) - &a.dick; (1999 - 2003) + &a.dick.email; (1999 - 2003) - &a.dbaker; (1999 - 2003) + &a.dbaker.email; (1999 - 2003) - &a.cpiazza; (1999 - 2003) + &a.cpiazza.email; (1999 - 2003) - &a.cp; (1999 - 2003) + &a.cp.email; (1999 - 2003) - &a.thepish; (1998 - 2003) + &a.thepish.email; (1998 - 2003) - &a.semenu; (1998 - 2003) + &a.semenu.email; (1998 - 2003) - &a.rvb; (1998 - 2003) + &a.rvb.email; (1998 - 2003) - &a.rnordier; (1998 - 2003) + &a.rnordier.email; (1998 - 2003) - &a.dt; (1998 - 2003) + &a.dt.email; (1998 - 2003) - &a.dirk; (1998 - 2003) + &a.dirk.email; (1998 - 2003) - &a.dillon; (1998 - 2003) + &a.dillon.email; (1998 - 2003) - &a.stark; (1997 - 2003) + &a.stark.email; (1997 - 2003) - &a.pds; (1997 - 2003) + &a.pds.email; (1997 - 2003) - &a.jseger; (1997 - 2003) + &a.jseger.email; (1997 - 2003) - &a.helbig; (1997 - 2003) + &a.helbig.email; (1997 - 2003) - &a.fsmp; (1997 - 2003) + &a.fsmp.email; (1997 - 2003) - &a.cwt; (1997 - 2003) + &a.cwt.email; (1997 - 2003) - &a.brandon; (1997 - 2003) + &a.brandon.email; (1997 - 2003) - &a.smpatel; (1996 - 2003) + &a.smpatel.email; (1996 - 2003) - &a.msmith; (1996 - 2003) + &a.msmith.email; (1996 - 2003) - &a.mbarkah; (1996 - 2003) + &a.mbarkah.email; (1996 - 2003) - &a.jfitz; (1996 - 2003) + &a.jfitz.email; (1996 - 2003) - &a.davidn; (1996 - 2003) + &a.davidn.email; (1996 - 2003) - &a.uhclem; (1995 - 2003) + &a.uhclem.email; (1995 - 2003) - &a.lars; (1995 - 2003) + &a.lars.email; (1995 - 2003) - &a.jfieber; (1995 - 2003) + &a.jfieber.email; (1995 - 2003) - &a.dufault; (1995 - 2003) + &a.dufault.email; (1995 - 2003) - &a.amurai; (1995 - 2003) + &a.amurai.email; (1995 - 2003) - &a.ugen; (1994 - 2003) + &a.ugen.email; (1994 - 2003) - &a.swallace; (1994 - 2003) + &a.swallace.email; (1994 - 2003) - &a.stb; (1994 - 2003) + &a.stb.email; (1994 - 2003) - &a.rich; (1994 - 2003) + &a.rich.email; (1994 - 2003) - &a.pst; (1994 - 2003) + &a.pst.email; (1994 - 2003) - &a.mks; (1994 - 2003) + &a.mks.email; (1994 - 2003) - &a.ljo; (1994 - 2003) + &a.ljo.email; (1994 - 2003) - &a.csgr; (1994 - 2003) + &a.csgr.email; (1994 - 2003) - &a.adam; (1994 - 2003) + &a.adam.email; (1994 - 2003) - &a.nate; (1993 - 2003) + &a.nate.email; (1993 - 2003) - &a.gpalmer; (1993 - 2003) + &a.gpalmer.email; (1993 - 2003) - &a.rgrimes; (1992 - 2003) + &a.rgrimes.email; (1992 - 2003) - &a.amorita; (2001 - 2002) + &a.amorita.email; (2001 - 2002) - &a.uch; (2000 - 2002) + &a.uch.email; (2000 - 2002) - &a.shafeeq; (2000 - 2002) + &a.shafeeq.email; (2000 - 2002) - &a.reg; (2000 - 2002) + &a.reg.email; (2000 - 2002) - &a.keith; (2000 - 2002) + &a.keith.email; (2000 - 2002) - &a.issei; (2000 - 2002) + &a.issei.email; (2000 - 2002) - &a.cshumway; (2000 - 2002) + &a.cshumway.email; (2000 - 2002) - &a.assar; (2000 - 2002) + &a.assar.email; (2000 - 2002) - &a.nakai; (1999 - 2002) + &a.nakai.email; (1999 - 2002) - &a.asmodai; (1999 - 2002) + &a.asmodai.email; (1999 - 2002) - &a.dburr; (1998 - 2002) + &a.dburr.email; (1998 - 2002) - &a.abial; (1998 - 2002) + &a.abial.email; (1998 - 2002) - &a.jmb; (1997 - 2002) + &a.jmb.email; (1997 - 2002) - &a.danny; (1997 - 2002) + &a.danny.email; (1997 - 2002) - &a.graichen; (1996 - 2002) + &a.graichen.email; (1996 - 2002) - &a.torstenb; (1995 - 2002) + &a.torstenb.email; (1995 - 2002) - &a.jmacd; (1995 - 2002) + &a.jmacd.email; (1995 - 2002) - &a.erich; (1995 - 2002) + &a.erich.email; (1995 - 2002) - &a.martin; (1994 - 2002) + &a.martin.email; (1994 - 2002) - &a.unfurl; (2000 - 2001) + &a.unfurl.email; (2000 - 2001) - &a.rv; (2000 - 2001) + &a.rv.email; (2000 - 2001) - &a.dec; (2000 - 2001) + &a.dec.email; (2000 - 2001) - &a.groudier; (1999 - 2001) + &a.groudier.email; (1999 - 2001) - &a.yokota; (1997 - 2001) + &a.yokota.email; (1997 - 2001) - &a.dima; (1995 - 2001) + &a.dima.email; (1995 - 2001) - &a.sef; (1993 - 2001) + &a.sef.email; (1993 - 2001) - &a.asami; (1993 - 2001) + &a.asami.email; (1993 - 2001) - &a.gehenna; (1999 - 2000) + &a.gehenna.email; (1999 - 2000) - &a.tedm; (1997 - 2000) + &a.tedm.email; (1997 - 2000) - &a.nsj; (1996 - 2000) + &a.nsj.email; (1996 - 2000) - &a.jraynard; (1996 - 2000) + &a.jraynard.email; (1996 - 2000) - &a.chuckr; (1996 - 2000) + &a.chuckr.email; (1996 - 2000) - &a.karl; (1995 - 2000) + &a.karl.email; (1995 - 2000) - &a.gclarkii; (1993 - 2000) + &a.gclarkii.email; (1993 - 2000) - &a.jgreco; (1997 - 1999) + &a.jgreco.email; (1997 - 1999) - &a.jamil; (1997 - 1999) + &a.jamil.email; (1997 - 1999) - &a.ats; (1992 - 1999) + &a.ats.email; (1992 - 1999) - &a.meganm; (1997 - 1998) + &a.meganm.email; (1997 - 1998) - &a.ahd; (1997 - 1998) + &a.ahd.email; (1997 - 1998) - &a.ahasty; (1997 - 1998) + &a.ahasty.email; (1997 - 1998) - &a.dyson; (1993 - 1998) + &a.dyson.email; (1993 - 1998) - &a.olah; (1995 - 1996) + &a.olah.email; (1995 - 1996) - &a.jhs; (1995 - 1995) + &a.jhs.email; (1995 - 1995) gjp (1995 - 1995) - &a.alm; (1993 - 1995) + &a.alm.email; (1993 - 1995) diff --git a/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml b/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml index 4c7d03fe7c..52c4849be6 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml +++ b/en_US.ISO8859-1/articles/contributors/contrib.develinmemoriam.xml @@ -1,66 +1,66 @@ - &a.jb; (1997 - 2009; RIP 2009) + &a.jb.email; (1997 - 2009; RIP 2009) John made major contributions to FreeBSD, the best known of which is the import of the &man.dtrace.1; code. John's unique sense of humor and plain-spokenness either ruffled feathers or made him quick friends. At the end of his life, he had moved to a rural area and was attempting to live with as minimal impact to the planet as possible, while at the same time still working in the high-tech area. - &a.jmz; (1994 - 2009; RIP 2009) + &a.jmz.email; (1994 - 2009; RIP 2009) Jean-Marc was an astrophysicist who made important contributions to the modeling of the atmospheres of both planets and comets at l'Observatoire de Besançon in Besançon, France. While there, he participated in the conception and construction of the Vega tricanal spectrometer that studied Halley's Comet. He had also been a long-time contributor to FreeBSD. - &a.itojun; (1997 - 2001; RIP 2008) + &a.itojun.email; (1997 - 2001; RIP 2008) Known to everyone as itojun, Jun-ichiro Hagino was was a core researcher at the KAME Project, which aimed to provide IPv6 and IPsec technology in freely redistributable form. Much of this code was incorporated into FreeBSD. Without his efforts, the state of IPv6 on the Internet would be much different. - &a.cg; (1999 - 2005; RIP 2005) + &a.cg.email; (1999 - 2005; RIP 2005) Cameron was a unique individual who contributed to the project despite serious physical disabilities. He was responsible for a complete rewrite of our sound system during the late 1990s. Many of those who corresponded with him had no idea of his limited mobility, due to his cheerful spirit and willingness to help others. - &a.alane; (2002 - 2003; RIP 2003) + &a.alane.email; (2002 - 2003; RIP 2003) Alan was a major contributor to the KDE on FreeBSD group. In addition, he maintained many other difficult and time-consuming ports such as autoconf, CUPS, and python. Alan's path was not an easy one but his passion for FreeBSD, and dedication to programming excellence, won him many friends. diff --git a/en_US.ISO8859-1/articles/contributors/contrib.portmgralumni.xml b/en_US.ISO8859-1/articles/contributors/contrib.portmgralumni.xml index 9cb8441e21..d422aa16c2 100644 --- a/en_US.ISO8859-1/articles/contributors/contrib.portmgralumni.xml +++ b/en_US.ISO8859-1/articles/contributors/contrib.portmgralumni.xml @@ -1,64 +1,64 @@ - &a.beat; (2011 - 2013) + &a.beat.email; (2011 - 2013) - &a.linimon; (2004 - 2013) + &a.linimon.email; (2004 - 2013) - &a.pav; (2006 - 2012) + &a.pav.email; (2006 - 2012) - &a.flz; (2008 - 2012) + &a.flz.email; (2008 - 2012) - &a.kris; (2001 - 2010) + &a.kris.email; (2001 - 2010) - &a.krion; (2004 - 2009) + &a.krion.email; (2004 - 2009) - &a.clement; (2005 - 2007) + &a.clement.email; (2005 - 2007) - &a.eik; (2004 - 2005) + &a.eik.email; (2004 - 2005) - &a.will; (2001 - 2004) + &a.will.email; (2001 - 2004) - &a.knu; (2001 - 2004) + &a.knu.email; (2001 - 2004) - &a.lioux; (2001 - 2004) + &a.lioux.email; (2001 - 2004) - &a.sobomax; (2001 - 2004) + &a.sobomax.email; (2001 - 2004) - &a.steve; (2001 - 2004) + &a.steve.email; (2001 - 2004) - &a.ade; (2001 - 2002) + &a.ade.email; (2001 - 2002) - &a.asami; ( - 2001) + &a.asami.email; ( - 2001) diff --git a/en_US.ISO8859-1/articles/cvs-freebsd/article.xml b/en_US.ISO8859-1/articles/cvs-freebsd/article.xml index ddf0d2845b..234a19f0a9 100644 --- a/en_US.ISO8859-1/articles/cvs-freebsd/article.xml +++ b/en_US.ISO8859-1/articles/cvs-freebsd/article.xml @@ -1,685 +1,685 @@

Setting up a CVS repository - the FreeBSD way Stijn Hoop

stijn@win.tue.nl

2001 2002 2003 Stijn Hoop $FreeBSD$ $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; This article describes the steps I took to set up a CVS repository that uses the same scripts the FreeBSD project uses in their setup. This has several advantages over a stock CVS setup, including more granular access control to the source tree and generation of readable email of every commit. Introduction Most of the open source software projects use CVS as their source code control system. While CVS is pretty good at this, it has its share of flaws and weaknesses. One of these is that sharing a source tree with other developers can quickly lead to a system administration nightmare, especially if one wishes to protect parts of the tree from general access. FreeBSD is one of the projects using CVS. It also has a large base of developers located around the world. They developed some scripts to make management of the repository easier. - Recently, these scripts were revisited and normalized by &a.joe; + Recently, these scripts were revisited and normalized by &a.joe.email; to make it easier to reuse them in other projects. This article describes one method of using the new scripts. To make the most use of the information in this article, you need to be familiar with the basic method of operation of CVS. First setup It might be best to first perform this procedure with an empty test repository, to make sure you understand all consequences. As always, make sure you have recent, readable backups! Initializing the repository The first thing to do when setting up a new repository is to tell CVS to initialize it: &prompt.user; cvs -d path-to-repository init This tells CVS to create the CVSROOT administrative directory, where all the customization takes place. The repository group Now we will create the group which will own the repository. All committers need to be in this group, so that they can write to the repository. We will assume the FreeBSD default of ncvs for this group. &prompt.root; pw groupadd ncvs Next, you should &man.chown.8; the directory to the group you just added: &prompt.root; chown -R :ncvs path-to-your-repository This ensures that no one can write to the repository without proper group permissions. Getting the sources Now you need to obtain the CVSROOT directory from the FreeBSD repository. This is most easily done by checking it out from a FreeBSD anonymous CVS mirror. See the relevant chapter in the handbook for more information. Let us assume that the sources are stored in CVSROOT-freebsd in the current directory. Copying the FreeBSD scripts Next, we will copy the FreeBSD CVSROOT sources into your own repository. If you are accustomed to CVS, you might be thinking that you can just import the scripts, in an attempt to make synchronizing with later versions easier. However, it turns out that CVS has a deficiency in this area: when importing sources into the CVSROOT directory, it will not update the needed administrative files. In order to make it recognize those, you will need to checkin each file after importing them, losing the value of cvs import. Therefore, the recommended method is to simply copy over the scripts. It does not matter if the above paragraph did not make sense to you—the end result is the same. Simply check out your CVSROOT and copy the FreeBSD files over your local (untouched) copies: &prompt.user; cvs -d path-to-your-repository checkout CVSROOT &prompt.user; cd CVSROOT &prompt.user; cp ../CVSROOT-freebsd/* . &prompt.user; cvs add * Note that you will probably get a few warnings about some directories not being copied; this is normal, you do not need those. The scripts Now you have in your working directory an exact copy of the scripts that the FreeBSD project itself uses for their repository. A summary of what each file is used for is included below. access - this file is not used in the default setup. It is used in the FreeBSD project specific setup, where it controls access to the repository. You can remove this file if you do not wish to use this setup. avail - this file controls access to the repository. In this, you can specify groups of people that are allowed access to the repository, as well as disallow commits on a per-directory or per-file basis. You should tailor it to contain the groups and directories that will be in your repository. cfg.pm - this file parses your configuration, and provides the default configuration. You should not make changes to this file. Instead, put your configuration changes in cfg_local.pm. cfg_local.pm - this file contains all configurable parameters of the system. You should configure all sorts of settings here, such as where commit mail is send, on what hosts people can commit, and others. More information on this below. checkoutlist - this files lists all files under control of CVS in this directory, apart from the standard ones created by cvs init. You should edit this to remove some FreeBSD-specific files. commit_prep.pl - this script performs various pre-commit checks, based on whether you enabled them in your cfg_local.pm. You should not have to touch this. commitcheck - this script is invoked directly from CVS. It first checks if the committer has access to the specified part of the tree using cvs_acls.pl, and then runs commit_prep.pl for the various pre-commit checks. If those are OK, CVS will allow the commit to proceed. You should not have to touch this file. commitinfo - this file is used by CVS to determine which script to run before a commit—in this case commitcheck. You should not have to touch this file. config - the configuration file for this repository. You should change this as needed, but most administrators can probably leave the defaults. More information on the options that can be set here can be found in the CVS manual. cvs_acls.pl - this script determines the committers identity, and whether he/she is allowed access to the tree. It does this based on the avail file. You should not have to touch this file. cvsignore - this file specifies files that CVS should not checkin in the repository. You can edit this as you wish. More information about this file is available in the CVS manual. cvswrappers - this file is used by CVS to enable or disable keyword expansion, or whether a file should be considered binary. You can edit this as you wish. More information about this file is available in the CVS manual. Note that the -t and -f options do not work correctly with client/server CVS. edithook - this file is not used any more, but kept for historic reasons. You can safely remove this file. editinfo - CVS uses this file for editor overrides. FreeBSD does not use this functionality, as parsing the log message is done by verifymsg and logcheck. This is because the editinfo functionality does not work properly with remote commits, or ones that use the -m or -F options. You should not have to touch this file. exclude - this file lists regular expressions that are used by commit_prep.pl to determine files which cannot contain a revision header. In the FreeBSD setup, all files under revision control need to have a revision header (like $FreeBSD$). All filenames that match one of the lines in this file are exempted from this check. You should add expressions to this file as you checkin files that cannot have a revision header. For the purpose of installing the scripts, it may be best to exclude CVSROOT/ from header checks. log_accum.pl - this is a script that takes the log message as provided by the logcheck script, and appends it to a log file in the repository for backup purposes. It also handles mailing out a message to an email address you provide (in cfg_local.pm). It hooks into CVS via loginfo. You should not have to touch this file. logcheck - this file parses the commit log message that committers provide, and attempts to sanitize it somewhat. It hooks into CVS via verifymsg. You should not have to touch this file. This script depends on a local FreeBSD hack of CVS: this version reads the log message back in after this script has modified it. The stock version of CVS does not do this which makes logcheck unable to clean up the log message, although it is still able to check that it is syntactically OK. CVS 1.11.2 can be configured to have the same behaviour as FreeBSD's version by setting RereadLogAfterVerify=always in the config file. loginfo - this file is used by CVS to control where log information is sent; log_accum.pl hooks in here. You should not have to touch this file. modules - this file retains its traditional meaning in CVS. You should remove the FreeBSD modules from the stock version. You can edit this as you wish. More information about this file is available in the CVS manual. notify - this file is used by CVS in case someone sets a watch on a file. It is not used in the FreeBSD repository. You can edit this as you wish. More information about this file is available in the CVS manual. options - this file is specific to the FreeBSD version of CVS, and is also supported by the Debian version. It contains the keyword to expand in revision headers. You should alter this to match the keyword you specified in cfg_local.pm (if you use that feature, which is FreeBSD specific for now). rcsinfo - this file maps directories in the repository to template files such as rcstemplate. By default, FreeBSD uses one template for the whole repository. You can add others to this file if you wish. rcstemplate - this file is the actual template committers will see when they make a checkin. You should edit this to describe the various extra parameters you defined in cfg_local.pm. tagcheck - this files controls access to tagging in the repository. The stock FreeBSD version disallows tags with names of RELENG*, because of the release engineering process. You should edit this file as desired. taginfo - this file maps tag operations on repository directories to access control scripts such as tagcheck. You should not have to touch this file. unwrap - this script can be used to automatically unwrap binary files (see cvswrappers) on checkout. It is not used in the current FreeBSD setup because the functionality it hooks into does not work well with remote commits. You should not have to touch this file. verifymsg - this file maps repository directories to post processor scripts of log messages such as logcheck. You should not have to touch this file. wrap - this script can be used to automatically wrap binary files (see cvswrappers) on checkin. It is not used in the current FreeBSD setup because the functionality it hooks into does not work well with remote commits. You should not have to touch this file. Customizing the scripts The next step is to set up the scripts so that they work in your environment. You should go over all files in the directory and make your customizations. In particular, you might want to do edit the following files: If you do not wish to use the FreeBSD specific features of the scripts, you can safely remove the access file: &prompt.user; cvs rm -f access Edit avail to contain the various repository directories in which you want to control access. Make sure you retain the avail||CVSROOT line, otherwise you will lock yourself out in the next step. The other thing you can add in this file are committer groups. By default, FreeBSD uses the access file to list all its committers in, but you can use any file you wish. You can also add groups if you want (the syntax is specified at the top of cvs_acls.pl). Edit cfg_local.pm to contain the options you want. In particular, you should take a look at the following configurable items: %TEMPLATE_HEADERS - these get processed by the log scripts, and inserted below the commit mail if present and non-empty in the commit message. You can probably remove the PR and MFC after entries. And of course you can add your own. $MAIL_BRANCH_HDR - if you want to insert a header into each commit mail describing the branch on which the commit was made, define this to match your setup. Or leave it empty if you do not want such a header. @COMMIT_HOSTS - define this to be a list of hosts on which people can commit. $MAILADDRS - set this to the admin or list address that should receive commit mail. @LOG_FILE_MAP - change this array as you wish - each regexp is matched on the directory of the commit, and the commit log message gets stored in the commitlogs subdirectory in the filename mentioned. $COMMITCHECK_EXTRA - if you do not want to use the FreeBSD specific access checks, you should remove the definition of $COMMITCHECK_EXTRA from this file. Changing the $IDHEADER parameter is only guaranteed to work on FreeBSD platforms; it depends on FreeBSD specific modifications to CVS. You can check cfg.pm to see which other options can be changed, but the above is a reasonable subset. Edit exclude to remove the FreeBSD specific entries (such as all lines beginning with ^ports/ etc.). Furthermore, comment out the lines beginning with ^CVSROOT/, and add one line with only ^CVSROOT/ on it. After the wrapper is installed, you can add your header to the files in the CVSROOT directory and restore these lines, but for now they will only be in the way when you try to commit later on. Edit modules, and delete all FreeBSD stuff. Add your own modules if you wish. This step is only necessary if you specified a value for $IDHEADER in cfg_local.pm (which only works using a FreeBSD modified CVS). Edit options to match the tag you specified in cfg_local.pm. A global search and replace of FreeBSD with your tag should suffice. Edit rcstemplate to contain the same keywords as specified in cfg_local.pm. Optionally remove the FreeBSD checks from tagcheck. You can simply add exit 0 to the top of the file to disable all checks on tagging. The last thing to do before you are finished, is to make sure the commitlogs can be stored. By default these are stored in the repository, in the commitlogs subdirectory of the CVSROOT directory. This directory needs to be created, so do the following: &prompt.user; mkdir commitlogs &prompt.user; cvs add commitlogs Now, after careful review, you should commit your changes. Be sure that you have granted yourself access to the CVSROOT directory in your avail before you do this, because otherwise you will lock yourself out. So make sure everything is as you intend, and then do the following: &prompt.user; cvs commit -m '- Initial FreeBSD scripts commit' Testing the setup You are ready for the first test: a forced commit to the avail file, to make sure everything works as expected. &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' avail If everything works, congratulations! You now have a working setup of the FreeBSD scripts for your repository. If CVS still complains about something, go back and recheck if all of the above steps have been performed correctly. FreeBSD specific setup The FreeBSD project itself uses a slightly different setup, which also uses files from the freebsd subdirectory of the FreeBSD CVSROOT. The project uses this because of the large number of committers, which all would have to be in the same group. So, a simple wrapper was written which ensures that people have the correct credentials to commit, and then sets the group id to that of the repository. If your repository also needs this, the steps to set this up are documented below. But first an overview of the files involved. Files used in the FreeBSD setup access - this file controls access information. You should edit this file to include all members of your project. freebsd/commitmail.pl - this file is not used any more, but kept for historic reasons. You should not have to touch this file. freebsd/cvswrap.c - this is the source to the CVS wrapper that you will need to install to make all access checks actually work. More information on this below. You should edit the paths in the ACCESS and REALCVS macros to match your setup. freebsd/mailsend.c - this file is needed by the FreeBSD setup of the mailing lists. You should not have to touch this file. The procedure Edit the access file to contain only your username. Edit cvswrap.c to contain the correct path for your setup. This is defined in a macro named ACCESS. You should also change the location of the real cvs binary if it is not appropriate to your situation. The stock cvswrap.c expects to be a replacement for the systemwide cvs command, which will be moved to /usr/bin/ncvs. My copy of cvswrap.c has this: #define ACCESS "/local/cvsroot/CVSROOT/access" #define REALCVS "/usr/bin/ncvs" Next up is installing the wrapper to ensure you become the correct group when committing. The sources for this live in cvswrap.c in your CVSROOT. Compile the sources that you edited to include the correct paths: &prompt.user; cc -o cvs cvswrap.c And then install them (you have to be root for this step): &prompt.root; mv /usr/bin/cvs /usr/bin/ncvs &prompt.root; mv cvs /usr/bin/cvs &prompt.root; chown root:ncvs /usr/bin/cvs /usr/bin/ncvs &prompt.root; chmod o-rx /usr/bin/ncvs &prompt.root; chmod u-w,g+s /usr/bin/cvs This installs the wrapper as the default cvs command, making sure that anyone who wants to use the repository has to have the correct access levels. You can now remove everyone from your repository group. All access control is done by your wrapper, and this wrapper will set the correct group for access. Testing the setup Your wrapper should now be setup. You can of course test this by making a forced commit to the access file: &prompt.user; cvs commit -f -m 'Forced commit to test the new CVSROOT scripts' access Again, if this fails, check to see whether all of the above steps have been executed correctly.

diff --git a/en_US.ISO8859-1/articles/freebsd-update-server/article.xml b/en_US.ISO8859-1/articles/freebsd-update-server/article.xml index 3eb9bec50b..0a760f67ca 100644 --- a/en_US.ISO8859-1/articles/freebsd-update-server/article.xml +++ b/en_US.ISO8859-1/articles/freebsd-update-server/article.xml @@ -1,815 +1,815 @@ FreeBSD Update Server"> ]>

Build Your Own &os; Update Server Jason Helfman -

&a.jgh;

&a.jgh.email;

2009 2010 2011 2013 Jason Helfman &tm-attrib.freebsd; &tm-attrib.general; &tm-attrib.intel; &tm-attrib.amd; $FreeBSD$ $FreeBSD$ This article describes building an internal &fbus.ap;. The freebsd-update-server - software is written by &a.cperciva;, Security Officer Emeritus of &os;. + is written by &a.cperciva.email;, Security Officer Emeritus of &os;. For users that think it is convenient to update their systems against an official update server, building their own &fbus.ap; may help to extend its functionality by supporting manually-tweaked &os; releases or by providing a local mirror that will allow faster updates for a number of machines. Acknowledgments This article was subsequently printed at BSD Magazine. Introduction Experienced users or administrators are often responsible for several machines or environments. They understand the difficult demands and challenges of maintaining such an infrastructure. Running a &fbus.ap; makes it easier to deploy security and software patches to selected test machines before rolling them out to production. It also means a number of systems can be updated from the local network rather than a potentially slower Internet connection. This article outlines the steps involved in creating an internal &fbus.ap;. Prerequisites To build an internal &fbus.ap; some requirements should be met. A running &os; system. At a minimum, updates require building on a &os; release greater than or equal to the target release version for distribution. A user account with at least 4 GB of available space. This will allow the creation of updates for 7.1 and 7.2, but the exact space requirements may change from version to version. An &man.ssh.1; account on a remote machine to upload distributed updates. A web server, like Apache, with over half of the space required for the build. For instance, test builds for 7.1 and 7.2 consume a total amount of 4 GB, and the webserver space needed to distribute these updates is 2.6 GB. Basic knowledge of shell scripting with Bourne shell, &man.sh.1;. Configuration: Installation & Setup Download the freebsd-update-server software by installing devel/subversion , and execute: &prompt.user; svn co http://svn.freebsd.org/base/user/cperciva/freebsd-update-build freebsd-update-server Update scripts/build.conf appropriately. It is sourced during all build operations. Here is the default build.conf, which should be modified to suit your environment. # Main configuration file for FreeBSD Update builds. The # release-specific configuration data is lower down in # the scripts tree. # Location from which to fetch releases export FTP=ftp://ftp2.freebsd.org/pub/FreeBSD/releases # Host platform export HOSTPLATFORM=`uname -m` # Host name to use inside jails export BUILDHOSTNAME=${HOSTPLATFORM}-builder.daemonology.net # Location of SSH key export SSHKEY=/root/.ssh/id_dsa # SSH account into which files are uploaded MASTERACCT=builder@wadham.daemonology.net # Directory into which files are uploaded MASTERDIR=update-master.freebsd.org Parameters for consideration would be: This is the location where ISO images are downloaded from (by the fetchiso() subroutine of scripts/build.subr). The location configured is not limited to FTP URIs. Any URI scheme supported by standard &man.fetch.1; utility should work fine. Customizations to the fetchiso() code can be installed by copying the default build.subr script to the release and architecture-specific area at scripts/RELEASE/ARCHITECTURE/build.subr and applying local changes. The name of the build host. This information will be displayed on updated systems when issuing: &prompt.user; uname -v The SSH key for uploading files to the update server. A key pair can be created by typing ssh-keygen -t dsa. This parameter is optional; standard password authentication will be used as a fallback authentication method when SSHKEY is not defined. The &man.ssh-keygen.1; manual page has more detailed information about SSH and the appropriate steps for creating and using one. Account for uploading files to the update server. Directory on the update server where files are uploaded to. The default build.conf file shipped with the freebsd-update-server sources is suitable for building &arch.i386; releases of &os;. As an example of building an update server for other architectures, the following steps outline the configuration changes needed for &arch.amd64;: Create a build environment for &arch.amd64;: &prompt.user; mkdir -p /usr/local/freebsd-update-server/scripts/7.2-RELEASE/amd64 Install a build.conf file in the newly created build directory. The build configuration options for &os; 7.2-RELEASE on &arch.amd64; should be similar to: # SHA256 hash of RELEASE disc1.iso image. export RELH=1ea1f6f652d7c5f5eab7ef9f8edbed50cb664b08ed761850f95f48e86cc71ef5 # Components of the world, source, and kernels export WORLDPARTS="base catpages dict doc games info manpages proflibs lib32" export SOURCEPARTS="base bin contrib crypto etc games gnu include krb5 \ lib libexec release rescue sbin secure share sys tools \ ubin usbin cddl" export KERNELPARTS="generic" # EOL date export EOL=1275289200 The &man.sha256.1; hash key for the desired release, is published within the respective release announcement. To generate the "End of Life" number for build.conf, refer to the "Estimated EOL" posted on the &os; Security Website. The value of EOL can be derived from the date listed on the web site, using the &man.date.1; utility, for example: &prompt.user; date -j -f '%Y%m%d-%H%M%S' '20090401-000000' '+%s' Building Update Code The first step is to run scripts/make.sh. This will build some binaries, create directories, and generate an RSA signing key used for approving builds. In this step, a passphrase will have to be supplied for the final creation of the signing key. &prompt.root; sh scripts/make.sh cc -O2 -fno-strict-aliasing -pipe findstamps.c -o findstamps findstamps.c: In function 'usage': findstamps.c:45: warning: incompatible implicit declaration of built-in function 'exit' cc -O2 -fno-strict-aliasing -pipe unstamp.c -o unstamp install findstamps ../bin install unstamp ../bin rm -f findstamps unstamp Generating RSA private key, 4096 bit long modulus ................................................................................++ ...................++ e is 65537 (0x10001) Public key fingerprint: 27ef53e48dc869eea6c3136091cc6ab8589f967559824779e855d58a2294de9e Encrypting signing key for root enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: Keep a note of the generated key fingerprint. This value is required in /etc/freebsd-update.conf for binary updates. At this point, we are ready to stage a build. &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/init.sh amd64 7.2-RELEASE What follows is a sample of an initial build run. &prompt.root; sh scripts/init.sh amd64 7.2-RELEASE Mon Aug 24 16:04:36 PDT 2009 Starting fetch for FreeBSD/amd64 7.2-RELEASE /usr/local/freebsd-update-server/work/7.2-RELE100% of 588 MB 359 kBps 00m00s Mon Aug 24 16:32:38 PDT 2009 Verifying disc1 hash for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 16:32:44 PDT 2009 Extracting components for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 16:34:05 PDT 2009 Constructing world+src image for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 16:35:57 PDT 2009 Extracting world+src for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 23:36:24 UTC 2009 Building world for FreeBSD/amd64 7.2-RELEASE Tue Aug 25 00:31:29 UTC 2009 Distributing world for FreeBSD/amd64 7.2-RELEASE Tue Aug 25 00:32:36 UTC 2009 Building and distributing kernels for FreeBSD/amd64 7.2-RELEASE Tue Aug 25 00:44:44 UTC 2009 Constructing world components for FreeBSD/amd64 7.2-RELEASE Tue Aug 25 00:44:56 UTC 2009 Distributing source for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:46:18 PDT 2009 Moving components into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:46:33 PDT 2009 Identifying extra documentation for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:47:13 PDT 2009 Extracting extra docs for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:47:18 PDT 2009 Indexing release for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 17:50:44 PDT 2009 Indexing world0 for FreeBSD/amd64 7.2-RELEASE Files built but not released: Files released but not built: Files which differ by more than contents: Files which differ between release and build: kernel|generic|/GENERIC/hptrr.ko kernel|generic|/GENERIC/kernel src|sys|/sys/conf/newvers.sh world|base|/boot/loader world|base|/boot/pxeboot world|base|/etc/mail/freebsd.cf world|base|/etc/mail/freebsd.submit.cf world|base|/etc/mail/sendmail.cf world|base|/etc/mail/submit.cf world|base|/lib/libcrypto.so.5 world|base|/usr/bin/ntpq world|base|/usr/lib/libalias.a world|base|/usr/lib/libalias_cuseeme.a world|base|/usr/lib/libalias_dummy.a world|base|/usr/lib/libalias_ftp.a ... Then the build of the world is performed again, with world patches. A more detailed explanation may be found in scripts/build.subr. During this second build cycle, the network time protocol - daemon, &man.ntpd.8;, is turned off. Per &a.cperciva;, + daemon, &man.ntpd.8;, is turned off. Per &a.cperciva.email;, Security Officer Emeritus of &os;, "the freebsd-update-server build code needs to identify timestamps which are stored in files so that they can be ignored when comparing builds to determine which files need to be updated. This timestamp-finding works by doing two builds 400 days apart and comparing the results." Mon Aug 24 17:54:07 PDT 2009 Extracting world+src for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 00:54:34 UTC 2010 Building world for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 01:49:42 UTC 2010 Distributing world for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 01:50:50 UTC 2010 Building and distributing kernels for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 02:02:56 UTC 2010 Constructing world components for FreeBSD/amd64 7.2-RELEASE Wed Sep 29 02:03:08 UTC 2010 Distributing source for FreeBSD/amd64 7.2-RELEASE Tue Sep 28 19:04:31 PDT 2010 Moving components into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:04:46 PDT 2009 Extracting extra docs for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:04:51 PDT 2009 Indexing world1 for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:08:04 PDT 2009 Locating build stamps for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:10:19 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:10:19 PDT 2009 Preparing to copy files into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 19:10:20 PDT 2009 Copying data files into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 12:16:57 PDT 2009 Copying metadata files into staging area for FreeBSD/amd64 7.2-RELEASE Mon Aug 24 12:16:59 PDT 2009 Constructing metadata index and tag for FreeBSD/amd64 7.2-RELEASE Files found which include build stamps: kernel|generic|/GENERIC/hptrr.ko kernel|generic|/GENERIC/kernel world|base|/boot/loader world|base|/boot/pxeboot world|base|/etc/mail/freebsd.cf world|base|/etc/mail/freebsd.submit.cf world|base|/etc/mail/sendmail.cf world|base|/etc/mail/submit.cf world|base|/lib/libcrypto.so.5 world|base|/usr/bin/ntpq world|base|/usr/include/osreldate.h world|base|/usr/lib/libalias.a world|base|/usr/lib/libalias_cuseeme.a world|base|/usr/lib/libalias_dummy.a world|base|/usr/lib/libalias_ftp.a ... Finally, the build completes. Values of build stamps, excluding library archive headers: v1.2 (Aug 25 2009 00:40:36) v1.2 (Aug 25 2009 00:38:22) @(#)FreeBSD 7.2-RELEASE #0: Tue Aug 25 00:38:29 UTC 2009 FreeBSD 7.2-RELEASE #0: Tue Aug 25 00:38:29 UTC 2009 root@server.myhost.com:/usr/obj/usr/src/sys/GENERIC 7.2-RELEASE Mon Aug 24 23:55:25 UTC 2009 Mon Aug 24 23:55:25 UTC 2009 ##### built by root@server.myhost.com on Tue Aug 25 00:16:15 UTC 2009 ##### built by root@server.myhost.com on Tue Aug 25 00:16:15 UTC 2009 ##### built by root@server.myhost.com on Tue Aug 25 00:16:15 UTC 2009 ##### built by root@server.myhost.com on Tue Aug 25 00:16:15 UTC 2009 Mon Aug 24 23:46:47 UTC 2009 ntpq 4.2.4p5-a Mon Aug 24 23:55:53 UTC 2009 (1) * Copyright (c) 1992-2009 The FreeBSD Project. Mon Aug 24 23:46:47 UTC 2009 Mon Aug 24 23:55:40 UTC 2009 Aug 25 2009 ntpd 4.2.4p5-a Mon Aug 24 23:55:52 UTC 2009 (1) ntpdate 4.2.4p5-a Mon Aug 24 23:55:53 UTC 2009 (1) ntpdc 4.2.4p5-a Mon Aug 24 23:55:53 UTC 2009 (1) Tue Aug 25 00:21:21 UTC 2009 Tue Aug 25 00:21:21 UTC 2009 Tue Aug 25 00:21:21 UTC 2009 Mon Aug 24 23:46:47 UTC 2009 FreeBSD/amd64 7.2-RELEASE initialization build complete. Please review the list of build stamps printed above to confirm that they look sensible, then run # sh -e approve.sh amd64 7.2-RELEASE to sign the release. Approve the build if everything is correct. More information on determining this can be found in the distributed source file named USAGE. Execute scripts/approve.sh, as directed. This will sign the release, and move components into a staging area suitable for uploading. &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/mountkey.sh &prompt.root; sh -e scripts/approve.sh amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Signing build for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to patch source directories for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to upload staging area for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:07 PDT 2009 Updating databases for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE After the approval process is complete, the upload procedure may be started. &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/upload.sh amd64 7.2-RELEASE In the event update code needs to be re-uploaded, this may be done by changing to the public distributions directory for the target release and updating attributes of the uploaded file. &prompt.root; cd /usr/local/freebsd-update-server/pub/7.2-RELEASE/amd64 &prompt.root; touch -t 200801010101.01 uploaded The uploaded files will need to be in the document root of the webserver in order for updates to be distributed. The exact configuration will vary depending on the web server used. For the Apache web server, please refer to the Configuration of Apache servers section in the Handbook. Update client's KeyPrint and ServerName in /etc/freebsd-update.conf, and perform updates as instructed in the &os; Update section of the Handbook. In order for &fbus.ap; to work properly, updates for both the current release and the release one wants to upgrade to need to be built. This is necessary for determining the differences of files between releases. For example, when upgrading a &os; system from 7.1-RELEASE to 7.2-RELEASE, updates will need to be built and uploaded to your distribution server for both versions. For reference, the entire run of init.sh is attached. Building a Patch Every time a security advisory or security notice is announced, a patch update can be built. For this example, 7.1-RELEASE will be used. A couple of assumptions are made for a different release build: Setup the correct directory structure for the initial build. Perform an initial build for 7.1-RELEASE. Create the patch directory of the respective release under /usr/local/freebsd-update-server/patches/. &prompt.user; mkdir -p /usr/local/freebsd-update-server/patches/7.1-RELEASE/ &prompt.user; cd /usr/local/freebsd-update-server/patches/7.1-RELEASE As an example, take the patch for &man.named.8;. Read the advisory, and grab the necessary file from &os; Security Advisories. More information on interpreting the advisory, can be found in the &os; Handbook. In the security brief, this advisory is called SA-09:12.bind. After downloading the file, it is required to rename the file to an appropriate patch level. It is suggested to keep this consistent with official &os; patch levels, but its name may be freely chosen. For this build, let us follow the currently established practice of &os; and call this p7. Rename the file: &prompt.user; cd /usr/local/freebsd-update-server/patches/7.1-RELEASE/; mv bind.patch 7-SA-09:12.bind When running a patch level build, it is assumed that previous patches are in place. When a patch build is run, it will run all patches contained in the patch directory. There can be custom patches added to any build. Use the number zero, or any other number. It is up to the administrator of the &fbus.ap; to take appropriate measures to verify the authenticity of every patch. At this point, a diff is ready to be built. The software checks first to see if a scripts/init.sh has been run on the respective release prior to running the diff build. &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/diff.sh amd64 7.1-RELEASE 7 What follows is a sample of a differential build run. &prompt.root; sh -e scripts/diff.sh amd64 7.1-RELEASE 7 Wed Aug 26 10:09:59 PDT 2009 Extracting world+src for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 17:10:25 UTC 2009 Building world for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:05:11 UTC 2009 Distributing world for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:06:16 UTC 2009 Building and distributing kernels for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:17:50 UTC 2009 Constructing world components for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:18:02 UTC 2009 Distributing source for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 11:19:23 PDT 2009 Moving components into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 11:19:37 PDT 2009 Extracting extra docs for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 11:19:42 PDT 2009 Indexing world0 for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 11:23:02 PDT 2009 Extracting world+src for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 18:23:29 UTC 2010 Building world for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 19:18:15 UTC 2010 Distributing world for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 19:19:18 UTC 2010 Building and distributing kernels for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 19:30:52 UTC 2010 Constructing world components for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 19:31:03 UTC 2010 Distributing source for FreeBSD/amd64 7.1-RELEASE-p7 Thu Sep 30 12:32:25 PDT 2010 Moving components into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:32:39 PDT 2009 Extracting extra docs for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:32:43 PDT 2009 Indexing world1 for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:35:54 PDT 2009 Locating build stamps for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:36:58 PDT 2009 Reverting changes due to build stamps for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:37:14 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:37:14 PDT 2009 Preparing to copy files into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:37:15 PDT 2009 Copying data files into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:43:23 PDT 2009 Copying metadata files into staging area for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 12:43:25 PDT 2009 Constructing metadata index and tag for FreeBSD/amd64 7.1-RELEASE-p7 ... Files found which include build stamps: kernel|generic|/GENERIC/hptrr.ko kernel|generic|/GENERIC/kernel world|base|/boot/loader world|base|/boot/pxeboot world|base|/etc/mail/freebsd.cf world|base|/etc/mail/freebsd.submit.cf world|base|/etc/mail/sendmail.cf world|base|/etc/mail/submit.cf world|base|/lib/libcrypto.so.5 world|base|/usr/bin/ntpq world|base|/usr/include/osreldate.h world|base|/usr/lib/libalias.a world|base|/usr/lib/libalias_cuseeme.a world|base|/usr/lib/libalias_dummy.a world|base|/usr/lib/libalias_ftp.a ... Values of build stamps, excluding library archive headers: v1.2 (Aug 26 2009 18:13:46) v1.2 (Aug 26 2009 18:11:44) @(#)FreeBSD 7.1-RELEASE-p7 #0: Wed Aug 26 18:11:50 UTC 2009 FreeBSD 7.1-RELEASE-p7 #0: Wed Aug 26 18:11:50 UTC 2009 root@server.myhost.com:/usr/obj/usr/src/sys/GENERIC 7.1-RELEASE-p7 Wed Aug 26 17:29:15 UTC 2009 Wed Aug 26 17:29:15 UTC 2009 ##### built by root@server.myhost.com on Wed Aug 26 17:49:58 UTC 2009 ##### built by root@server.myhost.com on Wed Aug 26 17:49:58 UTC 2009 ##### built by root@server.myhost.com on Wed Aug 26 17:49:58 UTC 2009 ##### built by root@server.myhost.com on Wed Aug 26 17:49:58 UTC 2009 Wed Aug 26 17:20:39 UTC 2009 ntpq 4.2.4p5-a Wed Aug 26 17:29:42 UTC 2009 (1) * Copyright (c) 1992-2009 The FreeBSD Project. Wed Aug 26 17:20:39 UTC 2009 Wed Aug 26 17:29:30 UTC 2009 Aug 26 2009 ntpd 4.2.4p5-a Wed Aug 26 17:29:41 UTC 2009 (1) ntpdate 4.2.4p5-a Wed Aug 26 17:29:42 UTC 2009 (1) ntpdc 4.2.4p5-a Wed Aug 26 17:29:42 UTC 2009 (1) Wed Aug 26 17:55:02 UTC 2009 Wed Aug 26 17:55:02 UTC 2009 Wed Aug 26 17:55:02 UTC 2009 Wed Aug 26 17:20:39 UTC 2009 ... Updates are printed, and approval is requested. New updates: kernel|generic|/GENERIC/kernel.symbols|f|0|0|0555|0|7c8dc176763f96ced0a57fc04e7c1b8d793f27e006dd13e0b499e1474ac47e10| kernel|generic|/GENERIC/kernel|f|0|0|0555|0|33197e8cf15bbbac263d17f39c153c9d489348c2c534f7ca1120a1183dec67b1| kernel|generic|/|d|0|0|0755|0|| src|base|/|d|0|0|0755|0|| src|bin|/|d|0|0|0755|0|| src|cddl|/|d|0|0|0755|0|| src|contrib|/contrib/bind9/bin/named/update.c|f|0|10000|0644|0|4d434abf0983df9bc47435670d307fa882ef4b348ed8ca90928d250f42ea0757| src|contrib|/contrib/bind9/lib/dns/openssldsa_link.c|f|0|10000|0644|0|c6805c39f3da2a06dd3f163f26c314a4692d4cd9a2d929c0acc88d736324f550| src|contrib|/contrib/bind9/lib/dns/opensslrsa_link.c|f|0|10000|0644|0|fa0f7417ee9da42cc8d0fd96ad24e7a34125e05b5ae075bd6e3238f1c022a712| ... FreeBSD/amd64 7.1-RELEASE update build complete. Please review the list of build stamps printed above and the list of updated files to confirm that they look sensible, then run # sh -e approve.sh amd64 7.1-RELEASE to sign the build. Follow the same process as noted before for approving a build: &prompt.root; sh -e scripts/approve.sh amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Signing build for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to patch source directories for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to upload staging area for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:07 PDT 2009 Updating databases for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.1-RELEASE The FreeBSD/amd64 7.1-RELEASE update build has been signed and is ready to be uploaded. Remember to run # sh -e umountkey.sh to unmount the decrypted key once you have finished signing all the new builds. After approving the build, upload the software: &prompt.root; cd /usr/local/freebsd-update-server &prompt.root; sh scripts/upload.sh amd64 7.1-RELEASE For reference, the entire run of diff.sh is attached. Tips If a custom release is built using the native make release procedure, freebsd-update-server code will work from your release. As an example, a release without ports or documentation can be built by clearing functionality pertaining to documentation subroutines findextradocs (), addextradocs () and altering the download location in fetchiso (), respectively, in scripts/build.subr. As a last step, change the &man.sha256.1; hash in build.conf under your respective release and architecture and you are ready to build off your custom release. # Compare ${WORKDIR}/release and ${WORKDIR}/$1, identify which parts # of the world|doc subcomponent are missing from the latter, and # build a tarball out of them. findextradocs () { } # Add extra docs to ${WORKDIR}/$1 addextradocs () { } Adding flags to buildworld and obj targets in the scripts/build.subr script may speed up processing depending on the hardware used, however it is not necessary. Using these flags in other targets is not recommended, as it may cause the build to become unreliable. # Build the world log "Building world" cd /usr/src && make -j 2 ${COMPATFLAGS} buildworld 2>&1 # Distribute the world log "Distributing world" cd /usr/src/release && make -j 2 obj && make ${COMPATFLAGS} release.1 release.2 2>&1 Create an appropriate DNS SRV record for the update server, and put others behind it with variable weights. Using this facility will provide update mirrors, however this tip is not necessary unless you wish to provide a redundant service. _http._tcp.update.myserver.com. IN SRV 0 2 80 host1.myserver.com. SRV 0 1 80 host2.myserver.com. SRV 0 0 80 host3.myserver.com.

diff --git a/en_US.ISO8859-1/articles/gjournal-desktop/article.xml b/en_US.ISO8859-1/articles/gjournal-desktop/article.xml index 1b0566cba2..aadd5cf22c 100644 --- a/en_US.ISO8859-1/articles/gjournal-desktop/article.xml +++ b/en_US.ISO8859-1/articles/gjournal-desktop/article.xml @@ -1,670 +1,670 @@

Implementing UFS Journaling on a Desktop PC Manolis Kiagias

manolis@FreeBSD.org

2008 Manolis Kiagias $FreeBSD$ $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; A journaling file system uses a log to record all transactions that take place in the file system, and preserves its integrity in the event of a system crash or power failure. Although it is still possible to lose unsaved changes to files, journaling almost completely eliminates the possibility of file system corruption caused by an unclean shutdown. It also shortens to a minimum the time required for after-failure file system checking. Although the UFS file system employed by &os; does not implement journaling itself, the new journal class of the GEOM framework in &os; 7.X can be used to provide file system independent journaling. This article explains how to implement UFS journaling on a typical desktop PC scenario. Introduction While professional servers are usually well protected from unforeseen shutdowns, the typical desktop is at the mercy of power failures, accidental resets, and other user related incidents that can lead to unclean shutdowns. Soft Updates usually protect the file system efficiently in such cases, although most of the times a lengthy background check is required. On rare occasions, file system corruption reaches a point where user intervention is required and data may be lost. The new journaling capability provided by GEOM can greatly assist in such scenarios, by virtually eliminating the time required for file system checking, and ensuring that the file system is quickly restored to a consistent state. This article describes a procedure for implementing UFS journaling on a typical desktop PC scenario (one hard disk used for both operating system and data). It should be followed during a fresh installation of &os;. The steps are simple enough and do not require overly complex interaction with the command line. After reading this article, you will know: How to reserve space for journaling during a new installation of &os;. How to load and enable the geom_journal module (or build support for it in your custom kernel). How to convert your existing file systems to utilize journaling, and what options to use in /etc/fstab to mount them. How to implement journaling in new (empty) partitions. How to troubleshoot common problems associated with journaling. Before reading this article, you should be able to: Understand basic &unix; and &os; concepts. Be familiar with the installation procedure of &os; and the sysinstall utility. The procedure described here is intended for preparing a new installation where no actual user data is stored on the disk yet. While it is possible to modify and extend this procedure for systems already in production, you should backup all important data before doing so. Messing around with disks and partitions at a low level can lead to fatal mistakes and data loss. Understanding Journaling in &os; The journaling provided by GEOM in &os; 7.X is not file system specific (unlike for example the ext3 file system in &linux;) but is functioning at the block level. Though this means it can be applied to different file systems, for &os; 7.0-RELEASE, it can only be used on UFS2. This functionality is provided by loading the geom_journal.ko module into the kernel (or building it into a custom kernel) and using the gjournal command to configure the file systems. In general, you would like to journal large file systems, like /usr. You will need however (see the following section) to reserve some free disk space. When a file system is journaled, some disk space is needed to keep the journal itself. The disk space that holds the actual data is referred to as the data provider, while the one that holds the journal is referred to as the journal provider. The data and journal providers need to be on different partitions when journaling an existing (non-empty) partition. When journaling a new partition, you have the option to use a single provider for both data and journal. In any case, the gjournal command combines both providers to create the final journaled file system. For example: You wish to journal your /usr file system, stored in /dev/ad0s1f (which already contains data). You reserved some free disk space in a partition in /dev/ad0s1g. Using gjournal, a new /dev/ad0s1f.journal device is created where /dev/ad0s1f is the data provider, and /dev/ad0s1g is the journal provider. This new device is then used for all subsequent file operations. The amount of disk space you need to reserve for the journal provider depends on the usage load of the file system and not on the size of the data provider. For example on a typical office desktop, a 1 GB journal provider for the /usr file system will suffice, while a machine that deals with heavy disk I/O (i.e. video editing) may need more. A kernel panic will occur if the journal space is exhausted before it has a chance to be committed. The journal sizes suggested here, are highly unlikely to cause problems in typical desktop use (such as web browsing, word processing and playback of media files). If your workload includes intense disk activity, use the following rule for maximum reliability: Your RAM size should fit in 30% of the journal provider's space. For example, if your system has 1 GB RAM, create an approximately 3.3 GB journal provider. (Multiply your RAM size with 3.3 to obtain the size of the journal). For more information about journaling, please read the manual page of &man.gjournal.8;. Steps During the Installation of &os; Reserving Space for Journaling A typical desktop machine usually has one hard disk that stores both the OS and user data. Arguably, the default partitioning scheme selected by sysinstall is more or less suitable: A desktop machine does not need a large /var partition, while /usr is allocated the bulk of the disk space, since user data and a lot of packages are installed into its subdirectories. The default partitioning (the one obtained by pressing A at the &os; partition editor, called Disklabel) does not leave any unallocated space. Each partition that will be journaled, requires another partition for the journal. Since the /usr partition is the largest, it makes sense to shrink this partition slightly, to obtain the space required for journaling. In our example, an 80 GB disk is used. The following screenshot shows the default partitions created by Disklabel during installation: If this is more or less what you need, it is very easy to adjust for journaling. Simply use the arrow keys to move the highlight to the /usr partition and press D to delete it. Now, move the highlight to the disk name at the top of the screen and press C to create a new partition for /usr. This new partition should be smaller by 1 GB (if you intend to journal /usr only), or 2 GB (if you intend to journal both /usr and /var). From the pop-up that appears, opt to create a file system, and type /usr as the mount point. Should you journal the /var partition? Normally, journaling makes sense on quite large partitions. You may decide not to journal /var, although doing so on a typical desktop will cause no harm. If the file system is lightly used (quite probable for a desktop) you may wish to allocate less disk space for its journal. In our example, we journal both /usr and /var. You may of course adjust the procedure to your own needs. To keep things as easy going as possible, we are going to use sysinstall to create the partitions required for journaling. However, during installation, sysinstall insists on asking a mount point for each partition you create. At this point, you do not have any mount points for the partitions that will hold the journals, and in reality you do not even need them. These are not partitions that we are ever going to mount somewhere. To avoid these problems with sysinstall, we are going to create the journal partitions as swap space. Swap is never mounted, and sysinstall has no problem creating as many swap partitions as needed. After the first reboot, /etc/fstab will have to be edited, and the extra swap space entries removed. To create the swap, again use the arrow keys to move the highlight to the top of Disklabel screen, so that the disk name itself is highlighted. Then press N, enter the desired size (1024M), and select swap space from the pop-up menu that appears. Repeat for every journal you wish to create. In our example, we create two partitions to provide for the journals of /usr and /var. The final result is shown in the following screenshot: When you have completed creating the partitions, we suggest you write down the partition names, and mount points, so you can easily refer to this information during the configuration phase. This will help alleviate mistakes that may damage your installation. The following table shows our notes for the sample configuration: Partitions and Journals Partition Mount Point Journal ad0s1d /var ad0s1h ad0s1f /usr ad0s1g

Continue the installation as you would normally do. We would however suggest you postpone installation of third party software (packages) until you have completely setup journaling. Booting for the first time Your system will come up normally, but you will need to edit /etc/fstab and remove the extra swap partitions you created for the journals. Normally, the swap partition you will actually use is the one with the b suffix (i.e. ad0s1b in our example). Remove all other swap space entries and reboot so that &os; will stop using them. When the system comes up again, we will be ready to configure journaling. Setting Up Journaling Executing <command>gjournal</command> Having prepared all the required partitions, it is quite easy to configure journaling. We will need to switch to single user mode, so login as root and type: &prompt.root; shutdown now Press Enter to get the default shell. We will need to unmount the partitions that will be journaled, in our example /usr and /var: &prompt.root; umount /usr /var Load the module required for journaling: &prompt.root; gjournal load Now, use your notes to determine which partition will be used for each journal. In our example, /usr is ad0s1f and its journal will be ad0s1g, while /var is ad0s1d and will be journaled to ad0s1h. The following commands are required: &prompt.root; gjournal label ad0s1f ad0s1g GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. &prompt.root; gjournal label ad0s1d ad0s1h GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. If the last sector of either partition is used, gjournal will return an error. You will have to run the command using the flag to force an overwrite, i.e.: &prompt.root; gjournal label -f ad0s1d ad0s1h Since this is a new installation, it is highly unlikely that anything will be actually overwritten. At this point, two new devices are created, namely ad0s1d.journal and ad0s1f.journal. These represent the /var and /usr partitions we have to mount. Before mounting, we must however set the journal flag on them and clear the Soft Updates flag: &prompt.root; tunefs -J enable -n disable ad0s1d.journal tunefs: gjournal set tunefs: soft updates cleared &prompt.root; tunefs -J enable -n disable ad0s1f.journal tunefs: gjournal set tunefs: soft updates cleared Now, mount the new devices manually at their respective places (note that we can now use the mount option): &prompt.root; mount -o async /dev/ad0s1d.journal /var &prompt.root; mount -o async /dev/ad0s1f.journal /usr Edit /etc/fstab and update the entries for /usr and /var: /dev/ad0s1f.journal /usr ufs rw,async 2 2 /dev/ad0s1d.journal /var ufs rw,async 2 2 Make sure the above entries are correct, or you will have trouble starting up normally after you reboot! Finally, edit /boot/loader.conf and add the following line so the &man.gjournal.8; module is loaded at every boot: geom_journal_load="YES" Congratulations! Your system is now set for journaling. You can either type exit to return to multi-user mode, or reboot to test your configuration (recommended). During the boot you will see messages like the following: ad0: 76293MB XEC XE800JD-00HBC0 08.02D08 at ata0-master SATA150 GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal ad0s1d clean. GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal ad0s1f clean. After an unclean shutdown, the messages will vary slightly, i.e.: GEOM_JOURNAL: Journal ad0s1d consistent. This usually means that &man.gjournal.8; used the information in the journal provider to return the file system to a consistent state. Journaling Newly Created Partitions While the above procedure is necessary for journaling partitions that already contain data, journaling an empty partition is somewhat easier, since both the data and the journal provider can be stored in the same partition. For example, assume a new disk was installed, and a new partition /dev/ad1s1d was created. Creating the journal would be as simple as: &prompt.root; gjournal label ad1s1d The journal size will be 1 GB by default. You may adjust it by using the option. The value can be given in bytes, or appended by K, M or G to denote Kilobytes, Megabytes or Gigabytes respectively. Note that gjournal will not allow you to create unsuitably small journal sizes. For example, to create a 2 GB journal, you could use the following command: &prompt.root; gjournal label -s 2G ad1s1d You can then create a file system on your new partition, and enable journaling using the option: &prompt.root; newfs -J /dev/ad1s1d.journal Building Journaling into Your Custom Kernel If you do not wish to load geom_journal as a module, you can build its functions right into your kernel. Edit your custom kernel configuration file, and make sure it includes these two lines: options UFS_GJOURNAL # Note: This is already in GENERIC options GEOM_JOURNAL # You will have to add this one Rebuild and reinstall your kernel following the relevant instructions in the &os; Handbook. Do not forget to remove the relevant load entry from /boot/loader.conf if you have previously used it. Troubleshooting Journaling The following section covers frequently asked questions regarding problems related to journaling. I am getting kernel panics during periods of high disk activity. How is this related to journaling? The journal probably fills up before it has a chance to get committed (flushed) to disk. Keep in mind the size of the journal depends on the usage load, and not the size of the data provider. If your disk activity is high, you need a larger partition for the journal. See the note in the Understanding Journaling section. I made some mistake during configuration, and I cannot boot normally now. Can this be fixed some way? You either forgot (or misspelled) the entry in /boot/loader.conf, or there are errors in your /etc/fstab file. These are usually easy to fix. Press Enter to get to the default single user shell. Then locate the root of the problem: &prompt.root; cat /boot/loader.conf If the geom_journal_load entry is missing or misspelled, the journaled devices are never created. Load the module manually, mount all partitions, and continue with multi-user boot: &prompt.root; gjournal load GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. GEOM_JOURNAL: Journal ad0s1d clean. GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. GEOM_JOURNAL: Journal ad0s1f clean. &prompt.root; mount -a &prompt.root; exit (boot continues) If, on the other hand, this entry is correct, have a look at /etc/fstab. You will probably find a misspelled or missing entry. In this case, mount all remaining partitions by hand and continue with the multi-user boot. Can I remove journaling and return to my standard file system with Soft Updates? Sure. Use the following procedure, which reverses the changes. The partitions you created for the journal providers can then be used for other purposes, if you so wish. Login as root and switch to single user mode: &prompt.root; shutdown now Unmount the journaled partitions: &prompt.root; umount /usr /var Synchronize the journals: &prompt.root; gjournal sync Stop the journaling providers: &prompt.root; gjournal stop ad0s1d.journal &prompt.root; gjournal stop ad0s1f.journal Clear journaling metadata from all the devices used: &prompt.root; gjournal clear ad0s1d &prompt.root; gjournal clear ad0s1f &prompt.root; gjournal clear ad0s1g &prompt.root; gjournal clear ad0s1h Clear the file system journaling flag, and restore the Soft Updates flag: &prompt.root; tunefs -J disable -n enable ad0s1d tunefs: gjournal cleared tunefs: soft updates set &prompt.root; tunefs -J disable -n enable ad0s1f tunefs: gjournal cleared tunefs: soft updates set Remount the old devices by hand: &prompt.root; mount -o rw /dev/ad0s1d /var &prompt.root; mount -o rw /dev/ad0s1f /usr Edit /etc/fstab and restore it to its original state: /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1d /var ufs rw 2 2 Finally, edit /boot/loader.conf, remove the entry that loads the geom_journal module and reboot. Further Reading Journaling is a fairly new feature of &os;, and as such, it is not very well documented yet. You may however find the following additional references useful: A new section on journaling is now part of the &os; Handbook. This post - in &a.current.name; by &man.gjournal.8;'s developer, &a.pjd;. + in &a.current.name; by &man.gjournal.8;'s developer, &a.pjd.email;. This post - in &a.questions.name; by &a.ivoras;. + in &a.questions.name; by &a.ivoras.email;. The manual pages of &man.gjournal.8; and &man.geom.8;.

diff --git a/en_US.ISO8859-1/articles/hubs/article.xml b/en_US.ISO8859-1/articles/hubs/article.xml index 7fdcbabe7f..0408d9b70e 100644 --- a/en_US.ISO8859-1/articles/hubs/article.xml +++ b/en_US.ISO8859-1/articles/hubs/article.xml @@ -1,1066 +1,1066 @@

Mirroring FreeBSD Jun Kuriyama

kuriyama@FreeBSD.org

Valentino Vaschetto

logo@FreeBSD.org

Daniel Lang

dl@leo.org

Ken Smith

kensmith@FreeBSD.org

&tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.general; $FreeBSD$ $FreeBSD$ An in-progress article on how to mirror FreeBSD, aimed at hub administrators. We are not accepting new mirrors at this time. Contact Information The Mirror System Coordinators can be reached through email at mirror-admin@FreeBSD.org. There is also a &a.hubs;. Requirements for FreeBSD mirrors Disk Space Disk space is one of the most important requirements. Depending on the set of releases, architectures, and degree of completeness you want to mirror, a huge amount of disk space may be consumed. Also keep in mind that official mirrors are probably required to be complete. The CVS repository and the web pages should always be mirrored completely. Also note that the numbers stated here are reflecting the current state (at &rel2.current;-RELEASE/&rel.current;-RELEASE). Further development and releases will only increase the required amount. Also make sure to keep some (ca. 10-20%) extra space around just to be sure. Here are some approximate figures: Full FTP Distribution: 1.0 TB CVS repository: 5.4 GB CTM deltas: 3.2 GB Web pages: 463 MB The current disk usage of FTP Distribution can be found at ftp://ftp.FreeBSD.org/pub/FreeBSD/dir.sizes. Network Connection/Bandwidth Of course, you need to be connected to the Internet. The required bandwidth depends on your intended use of the mirror. If you just want to mirror some parts of FreeBSD for local use at your site/intranet, the demand may be much smaller than if you want to make the files publicly available. If you intend to become an official mirror, the bandwidth required will be even higher. We can only give rough estimates here: Local site, no public access: basically no minimum, but < 2 Mbps could make syncing too slow. Unofficial public site: 34 Mbps is probably a good start. Official site: > 100 Mbps is recommended, and your host should be connected as close as possible to your border router. System Requirements, CPU, RAM One thing this depends on the expected number of clients, which is determined by the server's policy. It is also affected by the types of services you want to offer. Plain FTP or HTTP services may not require a huge amount of resources. Watch out if you provide rsync. This can have a huge impact on CPU and memory requirements as it is considered a memory hog. The following are just examples to give you a very rough hint. For a moderately visited site that offers Rsync, you might consider a current CPU with around 800MHz - 1 GHz, and at least 512MB RAM. This is probably the minimum you want for an official site. For a frequently used site you definitely need more RAM (consider 2GB as a good start) and possibly more CPU, which could also mean that you need to go for a SMP system. You also want to consider a fast disk subsystem. Operations on the CVS repository require a fast disk subsystem (RAID is highly advised). A SCSI controller that has a cache of its own can also speed up things since most of these services incur a large number of small modifications to the disk. Services to offer Every mirror site is required to have a set of core services available. In addition to these required services, there are a number of optional services that server administrators may choose to offer. This section explains which services you can provide and how to go about implementing them. FTP (required for FTP fileset) This is one of the most basic services, and it is required for each mirror offering public FTP distributions. FTP access must be anonymous, and no upload/download ratios are allowed (a ridiculous thing anyway). Upload capability is not required (and must never be allowed for the FreeBSD file space). Also the FreeBSD archive should be available under the path /pub/FreeBSD. There is a lot of software available which can be set up to allow anonymous FTP (in alphabetical order). /usr/libexec/ftpd: FreeBSD's own ftpd can be used. Be sure to read &man.ftpd.8;. ftp/ncftpd: A commercial package, free for educational use. ftp/oftpd: An ftpd designed with security as a main focus. ftp/proftpd: A modular and very flexible ftpd. ftp/pure-ftpd: Another ftpd developed with security in mind. ftp/twoftpd: As above. ftp/vsftpd: The very secure ftpd. ftp/wu-ftpd: The ftpd from Washington University. It has become infamous, because of the huge amount of security issues that have been found in it. If you do choose to use this software be sure to keep it up to date. FreeBSD's ftpd, proftpd, wu-ftpd and maybe ncftpd are among the most commonly used FTPds. The others do not have a large userbase among mirror sites. One thing to consider is that you may need flexibility in limiting how many simultaneous connections are allowed, thus limiting how much network bandwidth and system resources are consumed. Rsync (optional for FTP fileset) Rsync is often offered for access to the contents of the FTP area of FreeBSD, so other mirror sites can use your system as their source. The protocol is different from FTP in many ways. It is much more bandwidth friendly, as only differences between files are transferred instead of whole files when they change. Rsync does require a significant amount of memory for each instance. The size depends on the size of the synced module in terms of the number of directories and files. Rsync can use rsh and ssh (now default) as a transport, or use its own protocol for stand-alone access (this is the preferred method for public rsync servers). Authentication, connection limits, and other restrictions may be applied. There is just one software package available: net/rsync HTTP (required for web pages, optional for FTP fileset) If you want to offer the FreeBSD web pages, you will need to install a web server. You may optionally offer the FTP fileset via HTTP. The choice of web server software is left up to the mirror administrator. Some of the most popular choices are: www/apache22: Apache is the most widely deployed web server on the Internet. It is used extensively by the FreeBSD Project. www/thttpd: If you are going to be serving a large amount of static content you may find that using an application such as thttpd is more efficient than Apache. It is optimized for excellent performance on FreeBSD. www/boa: Boa is another alternative to thttpd and Apache. It should provide considerably better performance than Apache for purely static content. It does not, at the time of this writing, contain the same set of optimizations for FreeBSD that are found in thttpd. CVSup (desired for CVS repository) CVSup is a very efficient way of distributing files. It works similar to rsync, but was specially designed for use with CVS repositories. If you want to offer the FreeBSD CVS repository, you really want to consider offering it via CVSup. It is possible to offer the CVS repository via AnonCVS, FTP, rsync or HTTP, but people would benefit much more from CVSup access. - CVSup was developed by &a.jdp;. + CVSup was developed by &a.jdp.email;. It is a bit tricky to install on non-FreeBSD platforms, since it is written in Modula-3 and therefore requires - a Modula-3 environment. John Polstra has built a + a Modula-3 environment. &a.jdp; has built a stripped down version of M3 that is sufficient to run CVSup, and can be installed much easier. See Ezm3 for details. Related ports are: net/cvsup: The native CVSup port (client and server) which requires lang/ezm3 now. net/cvsup-mirror: The CVSup mirror kit, which requires net/cvsup-without-gui, and configures it mirror-ready. Some site administrators may want a different setup though. There are a few more like net/cvsup-without-gui you might want to have a look at. If you prefer a static binary package, take a look here. This page still refers to the S1G bug that was present in CVSup. Maybe John will set up a generic download-site to get static binaries for various platforms. It is possible to use CVSup to offer any kind of fileset, not just CVS repositories, but configuration can be complex. CVSup is known to eat some CPU on both the server and the client, since it needs to compare lots of files. AnonCVS (optional for CVS repository) If you have the CVS repository, you may want to offer anonymous CVS access. A short warning first: There is not much demand for it, it requires some experience, and you need to know what you are doing. Generally there are two ways to access a CVS repository remotely: via pserver or via ssh (we do not consider rsh). For anonymous access, pserver is very well suited, but some still offer ssh access as well. There is a custom crafted wrapper in the CVS repository, to be used as a login-shell for the anonymous ssh account. It does a chroot, and therefore requires the CVS repository to be available under the anonymous user's home-directory. This may not be possible for all sites. If you just offer pserver this restriction does not apply, but you may run with more security risks. You do not need to install any special software, since &man.cvs.1; comes with FreeBSD. You need to enable access via inetd, so add an entry into your /etc/inetd.conf like this: cvspserver stream tcp nowait root /usr/bin/cvs cvs -f -l -R -T /anoncvstmp --allow-root=/home/ncvs pserver See the manpage for details of the options. Also see the CVS info page about additional ways to make sure access is read-only. It is advised that you create an unprivileged account, preferably called anoncvs. Also you need to create a file passwd in your /home/ncvs/CVSROOT and assign a CVS password (empty or anoncvs) to that user. The directory /anoncvstmp is a special purpose memory based file system. It is not required but advised since &man.cvs.1; creates a shadow directory structure in your /tmp which is not used after the operation but slows things dramatically if real disk operations are required. Here is an excerpt from /etc/fstab, how to set up such a MFS: /dev/da0s1b /anoncvstmp mfs rw,-s=786432,-b=4096,-f=512,-i=560,-c=3,-m=0,nosuid 0 0 - This is (of course) tuned a lot, and was suggested by &a.jdp;. + This is (of course) tuned a lot, and was suggested by &a.jdp.email;. How to Mirror FreeBSD Ok, now you know the requirements and how to offer the services, but not how to get it. :-) This section explains how to actually mirror the various parts of FreeBSD, what tools to use, and where to mirror from. FTP The FTP area is the largest amount of data that needs to be mirrored. It includes the distribution sets required for network installation, the branches which are actually snapshots of checked-out source trees, the ISO Images to write CD-ROMs with the installation distribution, a live file system, lots of packages, the ports tree, distfiles, and a huge amount of packages. All of course for various FreeBSD versions, and various architectures. With FTP mirror You can use a FTP mirror program to get the files. Some of the most commonly used are: ftp/mirror ftp/ftpmirror ftp/emirror ftp/spegla ftp/omi ftp/wget ftp/mirror was very popular, but seemed to have some drawbacks, as it is written in &man.perl.1;, and had real problems with mirroring large directories like a FreeBSD site. There are rumors that the current version has fixed this by allowing a different algorithm for comparing the directory structure to be specified. In general FTP is not really good for mirroring. It transfers the whole file if it has changed, and does not create a single data stream which would benefit from a large TCP congestion window. With rsync A better way to mirror the FTP area is rsync. You can install the port net/rsync and then use rsync to sync with your upstream host. rsync is already mentioned in . Since rsync access is not required, your preferred upstream site may not allow it. You may need to hunt around a little bit to find a site that allows rsync access. Since the number of rsync clients will have a significant impact on the server machine, most admins impose limitations on their server. For a mirror, you should ask the site maintainer you are syncing from about their policy, and maybe an exception for your host (since you are a mirror). A command line to mirror FreeBSD might look like: &prompt.user; rsync -vaz --delete ftp4.de.FreeBSD.org::FreeBSD/ /pub/FreeBSD/ Consult the documentation for rsync, which is also available at http://rsync.samba.org/, about the various options to be used with rsync. If you sync the whole module (unlike subdirectories), be aware that the module-directory (here "FreeBSD") will not be created, so you cannot omit the target directory. Also you might want to set up a script framework that calls such a command via &man.cron.8;. With CVSup A few sites, including the one-and-only ftp-master.FreeBSD.org even offer CVSup to mirror the contents of the FTP space. You need to install a CVSup client, preferably from the port net/cvsup. (Also reread .) A sample supfile suitable for ftp-master.FreeBSD.org looks like this: # # FreeBSD archive supfile from master server # *default host=ftp-master.FreeBSD.org *default base=/usr *default prefix=/pub #*default release=all *default delete use-rel-suffix *default umask=002 # If your network link is a T1 or faster, comment out the following line. #*default compress FreeBSD-archive release=all preserve It seems CVSup would be the best way to mirror the archive in terms of efficiency, but it is only available from few sites. Please have look at the CVSup documentation like &man.cvsup.1; and consider using the option. This reduces I/O operations by assuming the recorded information about each file is correct. Mirroring the CVS repository There are various ways to mirror the CVS repository. CVSup is the most common method. Using CVSup CVSup is described in some detail in and . It is very easy to setup a CVSup mirror. Installing net/cvsup-mirror will make sure all of the needed programs are installed and then gather all the needed information to configure the mirror. Please do not forget to consider the hint mentioned in this note above. Using other methods Using other methods than CVSup is generally not recommended. We describe them in short here anyway. Since most sites offer the CVS repository as part of the FTP fileset under the path /pub/FreeBSD/development/FreeBSD-CVS, the following methods could be used. FTP Rsync HTTP AnonCVS cannot be used to mirror the CVS repository since CVS does not allow you to access the repository itself, only checked out versions of the modules. Mirroring the WWW pages The best way is to check out the www distribution from CVS. If you have a local mirror of the CVS repository, it is as easy as: &prompt.user; cvs -d /home/ncvs co www and a cronjob, that calls cvs up -d -P on a regular basis, maybe just after your repository was updated. Of course, the files need to remain in a directory available for public WWW access. The installation and configuration of a web server is not discussed here. If you do not have a local repository, you can use CVSup to maintain an up to date copy of the www pages. A sample supfile can be found in /usr/share/examples/cvsup/www-supfile and could look like this: # # WWW module supfile for FreeBSD # *default host=cvsup3.de.FreeBSD.org *default base=/usr *default prefix=/usr/local *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. *default compress # This collection retrieves the www/ tree of the FreeBSD repository www Using ftp/wget or other web-mirror tools is not recommended. Mirroring the FreeBSD documentation Since the documentation is referenced a lot from the web pages, it is recommended that you mirror the FreeBSD documentation as well. However, this is not as trivial as the www-pages alone. First of all, you should get the doc sources, again preferably via CVSup. Here is a corresponding sample supfile: # # FreeBSD documentation supfile # *default host=cvsup3.de.FreeBSD.org *default base=/usr *default prefix=/usr/share *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. #*default compress # This will retrieve the entire doc branch of the FreeBSD repository. # This includes the handbook, FAQ, and translations thereof. doc-all Then you need to install a couple of ports. You are lucky, there is a meta-port: textproc/docproj to do the work for you. You need to set up some environment variables, like SGML_CATALOG_FILES. Also have a look at your /etc/make.conf (copy /usr/share/examples/etc/make.conf if you do not have one), and look at the DOC_LANG variable. Now you are probably ready to run make in your doc directory (/usr/share/doc by default) and build the documentation. Again you need to make it accessible for your web server and make sure the links point to the right location. The building of the documentation, as well as lots of side issues, is documented itself in the &os; Documentation Project Primer. Please read this piece of documentation, especially if you have problems building the documentation. How often should I mirror? Every mirror should be updated on a regular basis. You will certainly need some script framework for it that will be called by &man.cron.8;. Since nearly every admin does this his own way, we cannot give specific instructions. It could work like this: Put the command to run your mirroring application in a script. Use of a plain /bin/sh script is recommended. Add some output redirections so diagnostic messages are logged to a file. Test if your script works. Check the logs. Use &man.crontab.1; to add the script to the appropriate user's &man.crontab.5;. This should be a different user than what your FTP daemon runs as so that if file permissions inside your FTP area are not world-readable those files can not be accessed by anonymous FTP. This is used to stage releases — making sure all of the official mirror sites have all of the necessary release files on release day. Here are some recommended schedules: FTP fileset: daily CVS repository: hourly WWW pages: daily Where to mirror from This is an important issue. So this section will spend some effort to explain the backgrounds. We will say this several times: under no circumstances should you mirror from ftp.FreeBSD.org. A few words about the organization Mirrors are organized by country. All official mirrors have a DNS entry of the form ftpN.CC.FreeBSD.org. CC (i.e. country code) is the top level domain (TLD) of the country where this mirror is located. N is a number, telling that the host would be the Nth mirror in that country. (Same applies to cvsupN.CC.FreeBSD.org, wwwN.CC.FreeBSD.org, etc.) There are mirrors with no CC part. These are the mirror sites that are very well connected and allow a large number of concurrent users. ftp.FreeBSD.org is actually two machines, one currently located in Denmark and the other in the United States. It is NOT a master site and should never be used to mirror from. Lots of online documentation leads interactiveusers to ftp.FreeBSD.org so automated mirroring systems should find a different machine to mirror from. Additionally there exists a hierarchy of mirrors, which is described in terms of tiers. The master sites are not referred to but can be described as Tier-0. Mirrors that mirror from these sites can be considered Tier-1, mirrors of Tier-1-mirrors, are Tier-2, etc. Official sites are encouraged to be of a low tier, but the lower the tier the higher the requirements in terms as described in . Also access to low-tier-mirrors may be restricted, and access to master sites is definitely restricted. The tier-hierarchy is not reflected by DNS and generally not documented anywhere except for the master sites. However, official mirrors with low numbers like 1-4, are usually Tier-1 (this is just a rough hint, and there is no rule). Ok, but where should I get the stuff now? Under no circumstances should you mirror from ftp.FreeBSD.org. The short answer is: from the site that is closest to you in Internet terms, or gives you the fastest access. I just want to mirror from somewhere! If you have no special intentions or requirements, the statement in applies. This means: Check for those which provide fastest access (number of hops, round-trip-times) and offer the services you intend to use (like rsync or CVSup). Contact the administrators of your chosen site stating your request, and asking about their terms and policies. Set up your mirror as described above. I am an official mirror, what is the right site for me? In general the description in still applies. Of course you may want to put some weight on the fact that your upstream should be of a low tier. There are some other considerations about official mirrors that are described in . I want to access the master sites! If you have good reasons and good prerequisites, you may want and get access to one of the master sites. Access to these sites is generally restricted, and there are special policies for access. If you are already an official mirror, this certainly helps you getting access. In any other case make sure your country really needs another mirror. If it already has three or more, ask the zone administrator (hostmaster@CC.FreeBSD.org) or &a.hubs; first. Whoever helped you become, an official should have helped you gain access to an appropriate upstream host, either one of the master sites or a suitable Tier-1 site. If not, you can send email to mirror-admin@FreeBSD.org to request help with that. There are three master sites for the FTP fileset and one for the CVS repository (the web pages and docs are obtained from CVS, so there is no need for master). ftp-master.FreeBSD.org This is the master site for the FTP fileset. ftp-master.FreeBSD.org provides rsync and CVSup access, in addition to FTP. Refer to and how to access via these protocols. Mirrors are also encouraged to allow rsync access for the FTP contents, since they are Tier-1-mirrors. cvsup-master.FreeBSD.org This is the master site for the CVS repository. cvsup-master.FreeBSD.org provides CVSup access only. See for details. To get access, you need to contact the &a.cvsup-master;. Make sure you read the FreeBSD CVSup Access Policy first! Set up the required authentication by following these instructions. Make sure you specify the server as freefall.FreeBSD.org on the cvpasswd command line, as described in this document, even when you are contacting cvsup-master.FreeBSD.org Official Mirrors Official mirrors are mirrors that a) have a FreeBSD.org DNS entry (usually a CNAME). b) are listed as an official mirror in the FreeBSD documentation (like handbook). So far to distinguish official mirrors. Official mirrors are not necessarily Tier-1-mirrors. However you probably will not find a Tier-1-mirror, that is not also official. Special Requirements for official (tier-1) mirrors It is not so easy to state requirements for all official mirrors, since the project is sort of tolerant here. It is more easy to say, what official tier-1 mirrors are required to. All other official mirrors can consider this a big should. The following applies mainly to the FTP fileset, since a CVS repository should always be mirrored completely, and the web pages are a case of its own. Tier-1 mirrors are required to: carry the complete fileset allow access to other mirror sites provide FTP and rsync access Furthermore, admins should be subscribed to the &a.hubs;. See this link for details, how to subscribe. It is very important for a hub administrator, especially Tier-1 hub admins, to check the release schedule for the next FreeBSD release. This is important because it will tell you when the next release is scheduled to come out, and thus giving you time to prepare for the big spike of traffic which follows it. It is also important that hub administrators try to keep their mirrors as up-to-date as possible (again, even more crucial for Tier-1 mirrors). If Mirror1 does not update for a while, lower tier mirrors will begin to mirror old data from Mirror1 and thus begins a downward spiral... Keep your mirrors up to date! How to become official then? We are not accepting any new mirrors at this time. Some statistics from mirror sites Here are links to the stat pages of your favorite mirrors (a.k.a. the only ones who feel like providing stats). FTP site statistics ftp.is.FreeBSD.org - hostmaster@is.FreeBSD.org - (Bandwidth) (FTP processes) (HTTP processes) ftp.cz.FreeBSD.org - cejkar@fit.vutbr.cz - (Bandwidth) (FTP processes) (rsync processes) ftp2.ru.FreeBSD.org - mirror@macomnet.ru - (Bandwidth) (HTTP and FTP users) CVSup site stats cvsup[23456].jp.FreeBSD.org - kuriyama@FreeBSD.org - (CVSup processes) cvsup.cz.FreeBSD.org - cejkar@fit.vutbr.cz - (CVSup processes) cvsup4.ru.FreeBSD.org - maxim@FreeBSD.org - (CVSup processes)

diff --git a/en_US.ISO8859-1/articles/linux-emulation/article.xml b/en_US.ISO8859-1/articles/linux-emulation/article.xml index 0f7b4e9ee6..eec01db036 100644 --- a/en_US.ISO8859-1/articles/linux-emulation/article.xml +++ b/en_US.ISO8859-1/articles/linux-emulation/article.xml @@ -1,2373 +1,2373 @@

&linux; emulation in &os; Roman Divacky

rdivacky@FreeBSD.org

&tm-attrib.adobe; &tm-attrib.ibm; &tm-attrib.freebsd; &tm-attrib.linux; &tm-attrib.netbsd; &tm-attrib.realnetworks; &tm-attrib.oracle; &tm-attrib.sun; &tm-attrib.general; $FreeBSD$ $FreeBSD$ This masters thesis deals with updating the &linux; emulation layer (the so called Linuxulator). The task was to update the layer to match the functionality of &linux; 2.6. As a reference implementation, the &linux; 2.6.16 kernel was chosen. The concept is loosely based on the NetBSD implementation. Most of the work was done in the summer of 2006 as a part of the Google Summer of Code students program. The focus was on bringing the NPTL (new &posix; thread library) support into the emulation layer, including TLS (thread local storage), futexes (fast user space mutexes), PID mangling, and some other minor things. Many small problems were identified and fixed in the process. My work was integrated into the main &os; source repository and will be shipped in the upcoming 7.0R release. We, the emulation development team, are working on making the &linux; 2.6 emulation the default emulation layer in &os;. Introduction In the last few years the open source &unix; based operating systems started to be widely deployed on server and client machines. Among these operating systems I would like to point out two: &os;, for its BSD heritage, time proven code base and many interesting features and &linux; for its wide user base, enthusiastic open developer community and support from large companies. &os; tends to be used on server class machines serving heavy duty networking tasks with less usage on desktop class machines for ordinary users. While &linux; has the same usage on servers, but it is used much more by home based users. This leads to a situation where there are many binary only programs available for &linux; that lack support for &os;. Naturally, a need for the ability to run &linux; binaries on a &os; system arises and this is what this thesis deals with: the emulation of the &linux; kernel in the &os; operating system. During the Summer of 2006 Google Inc. sponsored a project which focused on extending the &linux; emulation layer (the so called Linuxulator) in &os; to include &linux; 2.6 facilities. This thesis is written as a part of this project. A look inside… In this section we are going to describe every operating system in question. How they deal with syscalls, trapframes etc., all the low-level stuff. We also describe the way they understand common &unix; primitives like what a PID is, what a thread is, etc. In the third subsection we talk about how &unix; on &unix; emulation could be done in general. What is &unix; &unix; is an operating system with a long history that has influenced almost every other operating system currently in use. Starting in the 1960s, its development continues to this day (although in different projects). &unix; development soon forked into two main ways: the BSDs and System III/V families. They mutually influenced themselves by growing a common &unix; standard. Among the contributions originated in BSD we can name virtual memory, TCP/IP networking, FFS, and many others. The System V branch contributed to SysV interprocess communication primitives, copy-on-write, etc. &unix; itself does not exist any more but its ideas have been used by many other operating systems world wide thus forming the so called &unix;-like operating systems. These days the most influential ones are &linux;, Solaris, and possibly (to some extent) &os;. There are in-company &unix; derivatives (AIX, HP-UX etc.), but these have been more and more migrated to the aforementioned systems. Let us summarize typical &unix; characteristics. Technical details Every running program constitutes a process that represents a state of the computation. Running process is divided between kernel-space and user-space. Some operations can be done only from kernel space (dealing with hardware etc.), but the process should spend most of its lifetime in the user space. The kernel is where the management of the processes, hardware, and low-level details take place. The kernel provides a standard unified &unix; API to the user space. The most important ones are covered below. Communication between kernel and user space process Common &unix; API defines a syscall as a way to issue commands from a user space process to the kernel. The most common implementation is either by using an interrupt or specialized instruction (think of SYSENTER/SYSCALL instructions for ia32). Syscalls are defined by a number. For example in &os;, the syscall number 85 is the &man.swapon.2; syscall and the syscall number 132 is &man.mkfifo.2;. Some syscalls need parameters, which are passed from the user-space to the kernel-space in various ways (implementation dependant). Syscalls are synchronous. Another possible way to communicate is by using a trap. Traps occur asynchronously after some event occurs (division by zero, page fault etc.). A trap can be transparent for a process (page fault) or can result in a reaction like sending a signal (division by zero). Communication between processes There are other APIs (System V IPC, shared memory etc.) but the single most important API is signal. Signals are sent by processes or by the kernel and received by processes. Some signals can be ignored or handled by a user supplied routine, some result in a predefined action that cannot be altered or ignored. Process management Kernel instances are processed first in the system (so called init). Every running process can create its identical copy using the &man.fork.2; syscall. Some slightly modified versions of this syscall were introduced but the basic semantic is the same. Every running process can morph into some other process using the &man.exec.3; syscall. Some modifications of this syscall were introduced but all serve the same basic purpose. Processes end their lives by calling the &man.exit.2; syscall. Every process is identified by a unique number called PID. Every process has a defined parent (identified by its PID). Thread management Traditional &unix; does not define any API nor implementation for threading, while &posix; defines its threading API but the implementation is undefined. Traditionally there were two ways of implementing threads. Handling them as separate processes (1:1 threading) or envelope the whole thread group in one process and managing the threading in userspace (1:N threading). Comparing main features of each approach: 1:1 threading - heavyweight threads - the scheduling cannot be altered by the user (slightly mitigated by the &posix; API) + no syscall wrapping necessary + can utilize multiple CPUs 1:N threading + lightweight threads + scheduling can be easily altered by the user - syscalls must be wrapped - cannot utilize more than one CPU What is &os;? The &os; project is one of the oldest open source operating systems currently available for daily use. It is a direct descendant of the genuine &unix; so it could be claimed that it is a true &unix; although licensing issues do not permit that. The start of the project dates back to the early 1990's when a crew of fellow BSD users patched the 386BSD operating system. Based on this patchkit a new operating system arose named &os; for its liberal license. Another group created the NetBSD operating system with different goals in mind. We will focus on &os;. &os; is a modern &unix;-based operating system with all the features of &unix;. Preemptive multitasking, multiuser facilities, TCP/IP networking, memory protection, symmetric multiprocessing support, virtual memory with merged VM and buffer cache, they are all there. One of the interesting and extremely useful features is the ability to emulate other &unix;-like operating systems. As of December 2006 and 7-CURRENT development, the following emulation functionalities are supported: &os;/i386 emulation on &os;/amd64 &os;/i386 emulation on &os;/ia64 &linux;-emulation of &linux; operating system on &os; NDIS-emulation of Windows networking drivers interface NetBSD-emulation of NetBSD operating system PECoff-support for PECoff &os; executables SVR4-emulation of System V revision 4 &unix; Actively developed emulations are the &linux; layer and various &os;-on-&os; layers. Others are not supposed to work properly nor be usable these days. &os; development happens in a central CVS repository where only a selected team of so called committers can write. This repository possesses several branches; the most interesting are the HEAD branch, in &os; nomenclature called -CURRENT, and RELENG_X branches, where X stands for a number indicating a major version of &os;. As of December 2006, there are development branches for 6.X development (RELENG_6) and for the 5.X development (RELENG_5). Other branches are closed and not actively maintained or only fed with security patches by the Security Officer of the &os; project. Historically the active development was done in the HEAD branch so it was considered extremely unstable and supposed to happen to break at any time. This is not true any more as the Perforce (commercial version control system) repository was introduced so that active development happen there. There are many branches in Perforce where development of certain parts of the system happens and these branches are from time to time merged back to the main CVS repository thus effectively putting the given feature to the &os; operating system. The same happened with the rdivacky_linuxolator branch where development of this thesis code was going on. More info about the &os; operating system can be found at [2]. Technical details &os; is traditional flavor of &unix; in the sense of dividing the run of processes into two halves: kernel space and user space run. There are two types of process entry to the kernel: a syscall and a trap. There is only one way to return. In the subsequent sections we will describe the three gates to/from the kernel. The whole description applies to the i386 architecture as the Linuxulator only exists there but the concept is similar on other architectures. The information was taken from [1] and the source code. System entries &os; has an abstraction called an execution class loader, which is a wedge into the &man.execve.2; syscall. This employs a structure sysentvec, which describes an executable ABI. It contains things like errno translation table, signal translation table, various functions to serve syscall needs (stack fixup, coredumping, etc.). Every ABI the &os; kernel wants to support must define this structure, as it is used later in the syscall processing code and at some other places. System entries are handled by trap handlers, where we can access both the kernel-space and the user-space at once. Syscalls Syscalls on &os; are issued by executing interrupt 0x80 with register %eax set to a desired syscall number with arguments passed on the stack. When a process issues an interrupt 0x80, the int0x80 syscall trap handler is issued (defined in sys/i386/i386/exception.s), which prepares arguments (i.e. copies them on to the stack) for a call to a C function &man.syscall.2; (defined in sys/i386/i386/trap.c), which processes the passed in trapframe. The processing consists of preparing the syscall (depending on the sysvec entry), determining if the syscall is 32-bit or 64-bit one (changes size of the parameters), then the parameters are copied, including the syscall. Next, the actual syscall function is executed with processing of the return code (special cases for ERESTART and EJUSTRETURN errors). Finally an userret() is scheduled, switching the process back to the users-pace. The parameters to the actual syscall handler are passed in the form of struct thread *td, struct syscall args * arguments where the second parameter is a pointer to the copied in structure of parameters. Traps Handling of traps in &os; is similar to the handling of syscalls. Whenever a trap occurs, an assembler handler is called. It is chosen between alltraps, alltraps with regs pushed or calltrap depending on the type of the trap. This handler prepares arguments for a call to a C function trap() (defined in sys/i386/i386/trap.c), which then processes the occurred trap. After the processing it might send a signal to the process and/or exit to userland using userret(). Exits Exits from kernel to userspace happen using the assembler routine doreti regardless of whether the kernel was entered via a trap or via a syscall. This restores the program status from the stack and returns to the userspace. &unix; primitives &os; operating system adheres to the traditional &unix; scheme, where every process has a unique identification number, the so called PID (Process ID). PID numbers are allocated either linearly or randomly ranging from 0 to PID_MAX. The allocation of PID numbers is done using linear searching of PID space. Every thread in a process receives the same PID number as result of the &man.getpid.2; call. There are currently two ways to implement threading in &os;. The first way is M:N threading followed by the 1:1 threading model. The default library used is M:N threading (libpthread) and you can switch at runtime to 1:1 threading (libthr). The plan is to switch to 1:1 library by default soon. Although those two libraries use the same kernel primitives, they are accessed through different API(es). The M:N library uses the kse_* family of syscalls while the 1:1 library uses the thr_* family of syscalls. Because of this, there is no general concept of thread ID shared between kernel and userspace. Of course, both threading libraries implement the pthread thread ID API. Every kernel thread (as described by struct thread) has td tid identifier but this is not directly accessible from userland and solely serves the kernel's needs. It is also used for 1:1 threading library as pthread's thread ID but handling of this is internal to the library and cannot be relied on. As stated previously there are two implementations of threading in &os;. The M:N library divides the work between kernel space and userspace. Thread is an entity that gets scheduled in the kernel but it can represent various number of userspace threads. M userspace threads get mapped to N kernel threads thus saving resources while keeping the ability to exploit multiprocessor parallelism. Further information about the implementation can be obtained from the man page or [1]. The 1:1 library directly maps a userland thread to a kernel thread thus greatly simplifying the scheme. None of these designs implement a fairness mechanism (such a mechanism was implemented but it was removed recently because it caused serious slowdown and made the code more difficult to deal with). What is &linux; &linux; is a &unix;-like kernel originally developed by Linus Torvalds, and now being contributed to by a massive crowd of programmers all around the world. From its mere beginnings to todays, with wide support from companies such as IBM or Google, &linux; is being associated with its fast development pace, full hardware support and benevolent dictator model of organization. &linux; development started in 1991 as a hobbyist project at University of Helsinki in Finland. Since then it has obtained all the features of a modern &unix;-like OS: multiprocessing, multiuser support, virtual memory, networking, basically everything is there. There are also highly advanced features like virtualization etc. As of 2006 &linux; seems to be the most widely used open source operating system with support from independent software vendors like Oracle, RealNetworks, Adobe, etc. Most of the commercial software distributed for &linux; can only be obtained in a binary form so recompilation for other operating systems is impossible. Most of the &linux; development happens in a Git version control system. Git is a distributed system so there is no central source of the &linux; code, but some branches are considered prominent and official. The version number scheme implemented by &linux; consists of four numbers A.B.C.D. Currently development happens in 2.6.C.D, where C represents major version, where new features are added or changed while D is a minor version for bugfixes only. More information can be obtained from [4]. Technical details &linux; follows the traditional &unix; scheme of dividing the run of a process in two halves: the kernel and user space. The kernel can be entered in two ways: via a trap or via a syscall. The return is handled only in one way. The further description applies to &linux; 2.6 on the &i386; architecture. This information was taken from [3]. Syscalls Syscalls in &linux; are performed (in userspace) using syscallX macros where X substitutes a number representing the number of parameters of the given syscall. This macro translates to a code that loads %eax register with a number of the syscall and executes interrupt 0x80. After this syscall return is called, which translates negative return values to positive errno values and sets res to -1 in case of an error. Whenever the interrupt 0x80 is called the process enters the kernel in system call trap handler. This routine saves all registers on the stack and calls the selected syscall entry. Note that the &linux; calling convention expects parameters to the syscall to be passed via registers as shown here: parameter -> %ebx parameter -> %ecx parameter -> %edx parameter -> %esi parameter -> %edi parameter -> %ebp There are some exceptions to this, where &linux; uses different calling convention (most notably the clone syscall). Traps The trap handlers are introduced in arch/i386/kernel/traps.c and most of these handlers live in arch/i386/kernel/entry.S, where handling of the traps happens. Exits Return from the syscall is managed by syscall &man.exit.3;, which checks for the process having unfinished work, then checks whether we used user-supplied selectors. If this happens stack fixing is applied and finally the registers are restored from the stack and the process returns to the userspace. &unix; primitives In the 2.6 version, the &linux; operating system redefined some of the traditional &unix; primitives, notably PID, TID and thread. PID is defined not to be unique for every process, so for some processes (threads) &man.getppid.2; returns the same value. Unique identification of process is provided by TID. This is because NPTL (New &posix; Thread Library) defines threads to be normal processes (so called 1:1 threading). Spawning a new process in &linux; 2.6 happens using the clone syscall (fork variants are reimplemented using it). This clone syscall defines a set of flags that affect behaviour of the cloning process regarding thread implementation. The semantic is a bit fuzzy as there is no single flag telling the syscall to create a thread. Implemented clone flags are: CLONE_VM - processes share their memory space CLONE_FS - share umask, cwd and namespace CLONE_FILES - share open files CLONE_SIGHAND - share signal handlers and blocked signals CLONE_PARENT - share parent CLONE_THREAD - be thread (further explanation below) CLONE_NEWNS - new namespace CLONE_SYSVSEM - share SysV undo structures CLONE_SETTLS - setup TLS at supplied address CLONE_PARENT_SETTID - set TID in the parent CLONE_CHILD_CLEARTID - clear TID in the child CLONE_CHILD_SETTID - set TID in the child CLONE_PARENT sets the real parent to the parent of the caller. This is useful for threads because if thread A creates thread B we want thread B to be parented to the parent of the whole thread group. CLONE_THREAD does exactly the same thing as CLONE_PARENT, CLONE_VM and CLONE_SIGHAND, rewrites PID to be the same as PID of the caller, sets exit signal to be none and enters the thread group. CLONE_SETTLS sets up GDT entries for TLS handling. The CLONE_*_*TID set of flags sets/clears user supplied address to TID or 0. As you can see the CLONE_THREAD does most of the work and does not seem to fit the scheme very well. The original intention is unclear (even for authors, according to comments in the code) but I think originally there was one threading flag, which was then parcelled among many other flags but this separation was never fully finished. It is also unclear what this partition is good for as glibc does not use that so only hand-written use of the clone permits a programmer to access this features. For non-threaded programs the PID and TID are the same. For threaded programs the first thread PID and TID are the same and every created thread shares the same PID and gets assigned a unique TID (because CLONE_THREAD is passed in) also parent is shared for all processes forming this threaded program. The code that implements &man.pthread.create.3; in NPTL defines the clone flags like this: int clone_flags = (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGNAL | CLONE_SETTLS | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID | CLONE_SYSVSEM #if __ASSUME_NO_CLONE_DETACHED == 0 | CLONE_DETACHED #endif | 0); The CLONE_SIGNAL is defined like #define CLONE_SIGNAL (CLONE_SIGHAND | CLONE_THREAD) the last 0 means no signal is sent when any of the threads exits. What is emulation According to a dictionary definition, emulation is the ability of a program or device to imitate another program or device. This is achieved by providing the same reaction to a given stimulus as the emulated object. In practice, the software world mostly sees three types of emulation - a program used to emulate a machine (QEMU, various game console emulators etc.), software emulation of a hardware facility (OpenGL emulators, floating point units emulation etc.) and operating system emulation (either in kernel of the operating system or as a userspace program). Emulation is usually used in a place, where using the original component is not feasible nor possible at all. For example someone might want to use a program developed for a different operating system than he uses. Then emulation comes in handy. Sometimes there is no other way but to use emulation - e.g. when the hardware device you try to use does not exist (yet/anymore) then there is no other way but emulation. This happens often when porting an operating system to a new (non-existent) platform. Sometimes it is just cheaper to emulate. Looking from an implementation point of view, there are two main approaches to the implementation of emulation. You can either emulate the whole thing - accepting possible inputs of the original object, maintaining inner state and emitting correct output based on the state and/or input. This kind of emulation does not require any special conditions and basically can be implemented anywhere for any device/program. The drawback is that implementing such emulation is quite difficult, time-consuming and error-prone. In some cases we can use a simpler approach. Imagine you want to emulate a printer that prints from left to right on a printer that prints from right to left. It is obvious that there is no need for a complex emulation layer but simply reversing of the printed text is sufficient. Sometimes the emulating environment is very similar to the emulated one so just a thin layer of some translation is necessary to provide fully working emulation! As you can see this is much less demanding to implement, so less time-consuming and error-prone than the previous approach. But the necessary condition is that the two environments must be similar enough. The third approach combines the two previous. Most of the time the objects do not provide the same capabilities so in a case of emulating the more powerful one on the less powerful we have to emulate the missing features with full emulation described above. This master thesis deals with emulation of &unix; on &unix;, which is exactly the case, where only a thin layer of translation is sufficient to provide full emulation. The &unix; API consists of a set of syscalls, which are usually self contained and do not affect some global kernel state. There are a few syscalls that affect inner state but this can be dealt with by providing some structures that maintain the extra state. No emulation is perfect and emulations tend to lack some parts but this usually does not cause any serious drawbacks. Imagine a game console emulator that emulates everything but music output. No doubt that the games are playable and one can use the emulator. It might not be that comfortable as the original game console but its an acceptable compromise between price and comfort. The same goes with the &unix; API. Most programs can live with a very limited set of syscalls working. Those syscalls tend to be the oldest ones (&man.read.2;/&man.write.2;, &man.fork.2; family, &man.signal.3; handling, &man.exit.3;, &man.socket.2; API) hence it is easy to emulate because their semantics is shared among all &unix;es, which exist todays. Emulation How emulation works in &os; As stated earlier, &os; supports running binaries from several other &unix;es. This works because &os; has an abstraction called the execution class loader. This wedges into the &man.execve.2; syscall, so when &man.execve.2; is about to execute a binary it examines its type. There are basically two types of binaries in &os;. Shell-like text scripts which are identified by #! as their first two characters and normal (typically ELF) binaries, which are a representation of a compiled executable object. The vast majority (one could say all of them) of binaries in &os; are from type ELF. ELF files contain a header, which specifies the OS ABI for this ELF file. By reading this information, the operating system can accurately determine what type of binary the given file is. Every OS ABI must be registered in the &os; kernel. This applies to the &os; native OS ABI, as well. So when &man.execve.2; executes a binary it iterates through the list of registered APIs and when it finds the right one it starts to use the information contained in the OS ABI description (its syscall table, errno translation table, etc.). So every time the process calls a syscall, it uses its own set of syscalls instead of some global one. This effectively provides a very elegant and easy way of supporting execution of various binary formats. The nature of emulation of different OSes (and also some other subsystems) led developers to invite a handler event mechanism. There are various places in the kernel, where a list of event handlers are called. Every subsystem can register an event handler and they are called accordingly. For example, when a process exits there is a handler called that possibly cleans up whatever the subsystem needs to be cleaned. Those simple facilities provide basically everything that is needed for the emulation infrastructure and in fact these are basically the only things necessary to implement the &linux; emulation layer. Common primitives in the &os; kernel Emulation layers need some support from the operating system. I am going to describe some of the supported primitives in the &os; operating system. Locking primitives - Contributed by: &a.attilio; + Contributed by: &a.attilio.email; The &os; synchronization primitive set is based on the idea to supply a rather huge number of different primitives in a way that the better one can be used for every particular, appropriate situation. To a high level point of view you can consider three kinds of synchronization primitives in the &os; kernel: atomic operations and memory barriers locks scheduling barriers Below there are descriptions for the 3 families. For every lock, you should really check the linked manpage (where possible) for more detailed explanations. Atomic operations and memory barriers Atomic operations are implemented through a set of functions performing simple arithmetics on memory operands in an atomic way with respect to external events (interrupts, preemption, etc.). Atomic operations can guarantee atomicity just on small data types (in the magnitude order of the .long. architecture C data type), so should be rarely used directly in the end-level code, if not only for very simple operations (like flag setting in a bitmap, for example). In fact, it is rather simple and common to write down a wrong semantic based on just atomic operations (usually referred as lock-less). The &os; kernel offers a way to perform atomic operations in conjunction with a memory barrier. The memory barriers will guarantee that an atomic operation will happen following some specified ordering with respect to other memory accesses. For example, if we need that an atomic operation happen just after all other pending writes (in terms of instructions reordering buffers activities) are completed, we need to explicitly use a memory barrier in conjunction to this atomic operation. So it is simple to understand why memory barriers play a key role for higher-level locks building (just as refcounts, mutexes, etc.). For a detailed explanatory on atomic operations, please refer to &man.atomic.9;. It is far, however, noting that atomic operations (and memory barriers as well) should ideally only be used for building front-ending locks (as mutexes). Refcounts Refcounts are interfaces for handling reference counters. They are implemented through atomic operations and are intended to be used just for cases, where the reference counter is the only one thing to be protected, so even something like a spin-mutex is deprecated. Using the refcount interface for structures, where a mutex is already used is often wrong since we should probably close the reference counter in some already protected paths. A manpage discussing refcount does not exist currently, just check sys/refcount.h for an overview of the existing API. Locks &os; kernel has huge classes of locks. Every lock is defined by some peculiar properties, but probably the most important is the event linked to contesting holders (or in other terms, the behaviour of threads unable to acquire the lock). &os;'s locking scheme presents three different behaviours for contenders: spinning blocking sleeping numbers are not casual Spinning locks Spin locks let waiters to spin until they cannot acquire the lock. An important matter do deal with is when a thread contests on a spin lock if it is not descheduled. Since the &os; kernel is preemptive, this exposes spin lock at the risk of deadlocks that can be solved just disabling interrupts while they are acquired. For this and other reasons (like lack of priority propagation support, poorness in load balancing schemes between CPUs, etc.), spin locks are intended to protect very small paths of code, or ideally not to be used at all if not explicitly requested (explained later). Blocking Block locks let waiters to be descheduled and blocked until the lock owner does not drop it and wakes up one or more contenders. In order to avoid starvation issues, blocking locks do priority propagation from the waiters to the owner. Block locks must be implemented through the turnstile interface and are intended to be the most used kind of locks in the kernel, if no particular conditions are met. Sleeping Sleep locks let waiters to be descheduled and fall asleep until the lock holder does not drop it and wakes up one or more waiters. Since sleep locks are intended to protect large paths of code and to cater asynchronous events, they do not do any form of priority propagation. They must be implemented through the &man.sleepqueue.9; interface. The order used to acquire locks is very important, not only for the possibility to deadlock due at lock order reversals, but even because lock acquisition should follow specific rules linked to locks natures. If you give a look at the table above, the practical rule is that if a thread holds a lock of level n (where the level is the number listed close to the kind of lock) it is not allowed to acquire a lock of superior levels, since this would break the specified semantic for a path. For example, if a thread holds a block lock (level 2), it is allowed to acquire a spin lock (level 1) but not a sleep lock (level 3), since block locks are intended to protect smaller paths than sleep lock (these rules are not about atomic operations or scheduling barriers, however). This is a list of lock with their respective behaviours: spin mutex - spinning - &man.mutex.9; sleep mutex - blocking - &man.mutex.9; pool mutex - blocking - &man.mtx.pool.9; sleep family - sleeping - &man.sleep.9; pause tsleep msleep msleep spin msleep rw msleep sx condvar - sleeping - &man.condvar.9; rwlock - blocking - &man.rwlock.9; sxlock - sleeping - &man.sx.9; lockmgr - sleeping - &man.lockmgr.9; semaphores - sleeping - &man.sema.9; Among these locks only mutexes, sxlocks, rwlocks and lockmgrs are intended to handle recursion, but currently recursion is only supported by mutexes and lockmgrs. Scheduling barriers Scheduling barriers are intended to be used in order to drive scheduling of threading. They consist mainly of three different stubs: critical sections (and preemption) sched_bind sched_pin Generally, these should be used only in a particular context and even if they can often replace locks, they should be avoided because they do not let the diagnose of simple eventual problems with locking debugging tools (as &man.witness.4;). Critical sections The &os; kernel has been made preemptive basically to deal with interrupt threads. In fact, in order to avoid high interrupt latency, time-sharing priority threads can be preempted by interrupt threads (in this way, they do not need to wait to be scheduled as the normal path previews). Preemption, however, introduces new racing points that need to be handled, as well. Often, in order to deal with preemption, the simplest thing to do is to completely disable it. A critical section defines a piece of code (borderlined by the pair of functions &man.critical.enter.9; and &man.critical.exit.9;, where preemption is guaranteed to not happen (until the protected code is fully executed). This can often replace a lock effectively but should be used carefully in order to not lose the whole advantage that preemption brings. sched_pin/sched_unpin Another way to deal with preemption is the sched_pin() interface. If a piece of code is closed in the sched_pin() and sched_unpin() pair of functions it is guaranteed that the respective thread, even if it can be preempted, it will always be executed on the same CPU. Pinning is very effective in the particular case when we have to access at per-cpu datas and we assume other threads will not change those data. The latter condition will determine a critical section as a too strong condition for our code. sched_bind/sched_unbind sched_bind is an API used in order to bind a thread to a particular CPU for all the time it executes the code, until a sched_unbind function call does not unbind it. This feature has a key role in situations where you cannot trust the current state of CPUs (for example, at very early stages of boot), as you want to avoid your thread to migrate on inactive CPUs. Since sched_bind and sched_unbind manipulate internal scheduler structures, they need to be enclosed in sched_lock acquisition/releasing when used. Proc structure Various emulation layers sometimes require some additional per-process data. It can manage separate structures (a list, a tree etc.) containing these data for every process but this tends to be slow and memory consuming. To solve this problem the &os; proc structure contains p_emuldata, which is a void pointer to some emulation layer specific data. This proc entry is protected by the proc mutex. The &os; proc structure contains a p_sysent entry that identifies, which ABI this process is running. In fact, it is a pointer to the sysentvec described above. So by comparing this pointer to the address where the sysentvec structure for the given ABI is stored we can effectively determine whether the process belongs to our emulation layer. The code typically looks like: if (__predict_true(p->p_sysent != &elf_&linux;_sysvec)) return; As you can see, we effectively use the __predict_true modifier to collapse the most common case (&os; process) to a simple return operation thus preserving high performance. This code should be turned into a macro because currently it is not very flexible, i.e. we do not support &linux;64 emulation nor A.OUT &linux; processes on i386. VFS The &os; VFS subsystem is very complex but the &linux; emulation layer uses just a small subset via a well defined API. It can either operate on vnodes or file handlers. Vnode represents a virtual vnode, i.e. representation of a node in VFS. Another representation is a file handler, which represents an opened file from the perspective of a process. A file handler can represent a socket or an ordinary file. A file handler contains a pointer to its vnode. More then one file handler can point to the same vnode. namei The &man.namei.9; routine is a central entry point to pathname lookup and translation. It traverses the path point by point from the starting point to the end point using lookup function, which is internal to VFS. The &man.namei.9; syscall can cope with symlinks, absolute and relative paths. When a path is looked up using &man.namei.9; it is inputed to the name cache. This behaviour can be suppressed. This routine is used all over the kernel and its performance is very critical. vn_fullpath The &man.vn.fullpath.9; function takes the best effort to traverse VFS name cache and returns a path for a given (locked) vnode. This process is unreliable but works just fine for the most common cases. The unreliability is because it relies on VFS cache (it does not traverse the on medium structures), it does not work with hardlinks, etc. This routine is used in several places in the Linuxulator. Vnode operations fgetvp - given a thread and a file descriptor number it returns the associated vnode &man.vn.lock.9; - locks a vnode vn_unlock - unlocks a vnode &man.VOP.READDIR.9; - reads a directory referenced by a vnode &man.VOP.GETATTR.9; - gets attributes of a file or a directory referenced by a vnode &man.VOP.LOOKUP.9; - looks up a path to a given directory &man.VOP.OPEN.9; - opens a file referenced by a vnode &man.VOP.CLOSE.9; - closes a file referenced by a vnode &man.vput.9; - decrements the use count for a vnode and unlocks it &man.vrele.9; - decrements the use count for a vnode &man.vref.9; - increments the use count for a vnode File handler operations fget - given a thread and a file descriptor number it returns associated file handler and references it fdrop - drops a reference to a file handler fhold - references a file handler &linux; emulation layer -MD part This section deals with implementation of &linux; emulation layer in &os; operating system. It first describes the machine dependent part talking about how and where interaction between userland and kernel is implemented. It talks about syscalls, signals, ptrace, traps, stack fixup. This part discusses i386 but it is written generally so other architectures should not differ very much. The next part is the machine independent part of the Linuxulator. This section only covers i386 and ELF handling. A.OUT is obsolete and untested. Syscall handling Syscall handling is mostly written in linux_sysvec.c, which covers most of the routines pointed out in the sysentvec structure. When a &linux; process running on &os; issues a syscall, the general syscall routine calls linux prepsyscall routine for the &linux; ABI. &linux; prepsyscall &linux; passes arguments to syscalls via registers (that is why it is limited to 6 parameters on i386) while &os; uses the stack. The &linux; prepsyscall routine must copy parameters from registers to the stack. The order of the registers is: %ebx, %ecx, %edx, %esi, %edi, %ebp. The catch is that this is true for only most of the syscalls. Some (most notably clone) uses a different order but it is luckily easy to fix by inserting a dummy parameter in the linux_clone prototype. Syscall writing Every syscall implemented in the Linuxulator must have its prototype with various flags in syscalls.master. The form of the file is: ... AUE_FORK STD { int linux_fork(void); } ... AUE_CLOSE NOPROTO { int close(int fd); } ... The first column represents the syscall number. The second column is for auditing support. The third column represents the syscall type. It is either STD, OBSOL, NOPROTO and UNIMPL. STD is a standard syscall with full prototype and implementation. OBSOL is obsolete and defines just the prototype. NOPROTO means that the syscall is implemented elsewhere so do not prepend ABI prefix, etc. UNIMPL means that the syscall will be substituted with the nosys syscall (a syscall just printing out a message about the syscall not being implemented and returning ENOSYS). From syscalls.master a script generates three files: linux_syscall.h, linux_proto.h and linux_sysent.c. The linux_syscall.h contains definitions of syscall names and their numerical value, e.g.: ... #define LINUX_SYS_linux_fork 2 ... #define LINUX_SYS_close 6 ... The linux_proto.h contains structure definitions of arguments to every syscall, e.g.: struct linux_fork_args { register_t dummy; }; And finally, linux_sysent.c contains structure describing the system entry table, used to actually dispatch a syscall, e.g.: { 0, (sy_call_t *)linux_fork, AUE_FORK, NULL, 0, 0 }, /* 2 = linux_fork */ { AS(close_args), (sy_call_t *)close, AUE_CLOSE, NULL, 0, 0 }, /* 6 = close */ As you can see linux_fork is implemented in Linuxulator itself so the definition is of STD type and has no argument, which is exhibited by the dummy argument structure. On the other hand close is just an alias for real &os; &man.close.2; so it has no linux arguments structure associated and in the system entry table it is not prefixed with linux as it calls the real &man.close.2; in the kernel. Dummy syscalls The &linux; emulation layer is not complete, as some syscalls are not implemented properly and some are not implemented at all. The emulation layer employs a facility to mark unimplemented syscalls with the DUMMY macro. These dummy definitions reside in linux_dummy.c in a form of DUMMY(syscall);, which is then translated to various syscall auxiliary files and the implementation consists of printing a message saying that this syscall is not implemented. The UNIMPL prototype is not used because we want to be able to identify the name of the syscall that was called in order to know what syscalls are more important to implement. Signal handling Signal handling is done generally in the &os; kernel for all binary compatibilities with a call to a compat-dependent layer. &linux; compatibility layer defines linux_sendsig routine for this purpose. &linux; sendsig This routine first checks whether the signal has been installed with a SA_SIGINFO in which case it calls linux_rt_sendsig routine instead. Furthermore, it allocates (or reuses an already existing) signal handle context, then it builds a list of arguments for the signal handler. It translates the signal number based on the signal translation table, assigns a handler, translates sigset. Then it saves context for the sigreturn routine (various registers, translated trap number and signal mask). Finally, it copies out the signal context to the userspace and prepares context for the actual signal handler to run. linux_rt_sendsig This routine is similar to linux_sendsig just the signal context preparation is different. It adds siginfo, ucontext, and some &posix; parts. It might be worth considering whether those two functions could not be merged with a benefit of less code duplication and possibly even faster execution. linux_sigreturn This syscall is used for return from the signal handler. It does some security checks and restores the original process context. It also unmasks the signal in process signal mask. Ptrace Many &unix; derivates implement the &man.ptrace.2; syscall in order to allow various tracking and debugging features. This facility enables the tracing process to obtain various information about the traced process, like register dumps, any memory from the process address space, etc. and also to trace the process like in stepping an instruction or between system entries (syscalls and traps). &man.ptrace.2; also lets you set various information in the traced process (registers etc.). &man.ptrace.2; is a &unix;-wide standard implemented in most &unix;es around the world. &linux; emulation in &os; implements the &man.ptrace.2; facility in linux_ptrace.c. The routines for converting registers between &linux; and &os; and the actual &man.ptrace.2; syscall emulation syscall. The syscall is a long switch block that implements its counterpart in &os; for every &man.ptrace.2; command. The &man.ptrace.2; commands are mostly equal between &linux; and &os; so usually just a small modification is needed. For example, PT_GETREGS in &linux; operates on direct data while &os; uses a pointer to the data so after performing a (native) &man.ptrace.2; syscall, a copyout must be done to preserve &linux; semantics. The &man.ptrace.2; implementation in Linuxulator has some known weaknesses. There have been panics seen when using strace (which is a &man.ptrace.2; consumer) in the Linuxulator environment. Also PT_SYSCALL is not implemented. Traps Whenever a &linux; process running in the emulation layer traps the trap itself is handled transparently with the only exception of the trap translation. &linux; and &os; differs in opinion on what a trap is so this is dealt with here. The code is actually very short: static int translate_traps(int signal, int trap_code) { if (signal != SIGBUS) return signal; switch (trap_code) { case T_PROTFLT: case T_TSSFLT: case T_DOUBLEFLT: case T_PAGEFLT: return SIGSEGV; default: return signal; } } Stack fixup The RTLD run-time link-editor expects so called AUX tags on stack during an execve so a fixup must be done to ensure this. Of course, every RTLD system is different so the emulation layer must provide its own stack fixup routine to do this. So does Linuxulator. The elf_linux_fixup simply copies out AUX tags to the stack and adjusts the stack of the user space process to point right after those tags. So RTLD works in a smart way. A.OUT support The &linux; emulation layer on i386 also supports &linux; A.OUT binaries. Pretty much everything described in the previous sections must be implemented for A.OUT support (beside traps translation and signals sending). The support for A.OUT binaries is no longer maintained, especially the 2.6 emulation does not work with it but this does not cause any problem, as the linux-base in ports probably do not support A.OUT binaries at all. This support will probably be removed in future. Most of the stuff necessary for loading &linux; A.OUT binaries is in imgact_linux.c file. &linux; emulation layer -MI part This section talks about machine independent part of the Linuxulator. It covers the emulation infrastructure needed for &linux; 2.6 emulation, the thread local storage (TLS) implementation (on i386) and futexes. Then we talk briefly about some syscalls. Description of NPTL One of the major areas of progress in development of &linux; 2.6 was threading. Prior to 2.6, the &linux; threading support was implemented in the linuxthreads library. The library was a partial implementation of &posix; threading. The threading was implemented using separate processes for each thread using the clone syscall to let them share the address space (and other things). The main weaknesses of this approach was that every thread had a different PID, signal handling was broken (from the pthreads perspective), etc. Also the performance was not very good (use of SIGUSR signals for threads synchronization, kernel resource consumption, etc.) so to overcome these problems a new threading system was developed and named NPTL. The NPTL library focused on two things but a third thing came along so it is usually considered a part of NPTL. Those two things were embedding of threads into a process structure and futexes. The additional third thing was TLS, which is not directly required by NPTL but the whole NPTL userland library depends on it. Those improvements yielded in much improved performance and standards conformance. NPTL is a standard threading library in &linux; systems these days. The &os; Linuxulator implementation approaches the NPTL in three main areas. The TLS, futexes and PID mangling, which is meant to simulate the &linux; threads. Further sections describe each of these areas. &linux; 2.6 emulation infrastructure These sections deal with the way &linux; threads are managed and how we simulate that in &os;. Runtime determining of 2.6 emulation The &linux; emulation layer in &os; supports runtime setting of the emulated version. This is done via &man.sysctl.8;, namely compat.linux.osrelease, which is set to 2.4.2 by default (as of April 2007) and with all &linux; versions up to 2.6 it just determined what &man.uname.1; outputs. It is different with 2.6 emulation where setting this &man.sysctl.8; affects runtime behaviour of the emulation layer. When set to 2.6.x it sets the value of linux_use_linux26 while setting to something else keeps it unset. This variable (plus per-prison variables of the very same kind) determines whether 2.6 infrastructure (mainly PID mangling) is used in the code or not. The version setting is done system-wide and this affects all &linux; processes. The &man.sysctl.8; should not be changed when running any &linux; binary as it might harm things. &linux; processes and thread identifiers The semantics of &linux; threading are a little confusing and uses entirely different nomenclature to &os;. A process in &linux; consists of a struct task embedding two identifier fields - PID and TGID. PID is not a process ID but it is a thread ID. The TGID identifies a thread group in other words a process. For single-threaded process the PID equals the TGID. The thread in NPTL is just an ordinary process that happens to have TGID not equal to PID and have a group leader not equal to itself (and shared VM etc. of course). Everything else happens in the same way as to an ordinary process. There is no separation of a shared status to some external structure like in &os;. This creates some duplication of information and possible data inconsistency. The &linux; kernel seems to use task -> group information in some places and task information elsewhere and it is really not very consistent and looks error-prone. Every NPTL thread is created by a call to the clone syscall with a specific set of flags (more in the next subsection). The NPTL implements strict 1:1 threading. In &os; we emulate NPTL threads with ordinary &os; processes that share VM space, etc. and the PID gymnastic is just mimicked in the emulation specific structure attached to the process. The structure attached to the process looks like: struct linux_emuldata { pid_t pid; int *child_set_tid; /* in clone(): Child.s TID to set on clone */ int *child_clear_tid;/* in clone(): Child.s TID to clear on exit */ struct linux_emuldata_shared *shared; int pdeath_signal; /* parent death signal */ LIST_ENTRY(linux_emuldata) threads; /* list of linux threads */ }; The PID is used to identify the &os; process that attaches this structure. The child_se_tid and child_clear_tid are used for TID address copyout when a process exits and is created. The shared pointer points to a structure shared among threads. The pdeath_signal variable identifies the parent death signal and the threads pointer is used to link this structure to the list of threads. The linux_emuldata_shared structure looks like: struct linux_emuldata_shared { int refs; pid_t group_pid; LIST_HEAD(, linux_emuldata) threads; /* head of list of linux threads */ }; The refs is a reference counter being used to determine when we can free the structure to avoid memory leaks. The group_pid is to identify PID ( = TGID) of the whole process ( = thread group). The threads pointer is the head of the list of threads in the process. The linux_emuldata structure can be obtained from the process using em_find. The prototype of the function is: struct linux_emuldata *em_find(struct proc *, int locked); Here, proc is the process we want the emuldata structure from and the locked parameter determines whether we want to lock or not. The accepted values are EMUL_DOLOCK and EMUL_DOUNLOCK. More about locking later. PID mangling Because of the described different view knowing what a process ID and thread ID is between &os; and &linux; we have to translate the view somehow. We do it by PID mangling. This means that we fake what a PID (=TGID) and TID (=PID) is between kernel and userland. The rule of thumb is that in kernel (in Linuxulator) PID = PID and TGID = shared -> group pid and to userland we present PID = shared -> group_pid and TID = proc -> p_pid. The PID member of linux_emuldata structure is a &os; PID. The above affects mainly getpid, getppid, gettid syscalls. Where we use PID/TGID respectively. In copyout of TIDs in child_clear_tid and child_set_tid we copy out &os; PID. Clone syscall The clone syscall is the way threads are created in &linux;. The syscall prototype looks like this: int linux_clone(l_int flags, void *stack, void *parent_tidptr, int dummy, void * child_tidptr); The flags parameter tells the syscall how exactly the processes should be cloned. As described above, &linux; can create processes sharing various things independently, for example two processes can share file descriptors but not VM, etc. Last byte of the flags parameter is the exit signal of the newly created process. The stack parameter if non-NULL tells, where the thread stack is and if it is NULL we are supposed to copy-on-write the calling process stack (i.e. do what normal &man.fork.2; routine does). The parent_tidptr parameter is used as an address for copying out process PID (i.e. thread id) once the process is sufficiently instantiated but is not runnable yet. The dummy parameter is here because of the very strange calling convention of this syscall on i386. It uses the registers directly and does not let the compiler do it what results in the need of a dummy syscall. The child_tidptr parameter is used as an address for copying out PID once the process has finished forking and when the process exits. The syscall itself proceeds by setting corresponding flags depending on the flags passed in. For example, CLONE_VM maps to RFMEM (sharing of VM), etc. The only nit here is CLONE_FS and CLONE_FILES because &os; does not allow setting this separately so we fake it by not setting RFFDG (copying of fd table and other fs information) if either of these is defined. This does not cause any problems, because those flags are always set together. After setting the flags the process is forked using the internal fork1 routine, the process is instrumented not to be put on a run queue, i.e. not to be set runnable. After the forking is done we possibly reparent the newly created process to emulate CLONE_PARENT semantics. Next part is creating the emulation data. Threads in &linux; does not signal their parents so we set exit signal to be 0 to disable this. After that setting of child_set_tid and child_clear_tid is performed enabling the functionality later in the code. At this point we copy out the PID to the address specified by parent_tidptr. The setting of process stack is done by simply rewriting thread frame %esp register (%rsp on amd64). Next part is setting up TLS for the newly created process. After this &man.vfork.2; semantics might be emulated and finally the newly created process is put on a run queue and copying out its PID to the parent process via clone return value is done. The clone syscall is able and in fact is used for emulating classic &man.fork.2; and &man.vfork.2; syscalls. Newer glibc in a case of 2.6 kernel uses clone to implement &man.fork.2; and &man.vfork.2; syscalls. Locking The locking is implemented to be per-subsystem because we do not expect a lot of contention on these. There are two locks: emul_lock used to protect manipulating of linux_emuldata and emul_shared_lock used to manipulate linux_emuldata_shared. The emul_lock is a nonsleepable blocking mutex while emul_shared_lock is a sleepable blocking sx_lock. Because of the per-subsystem locking we can coalesce some locks and that is why the em find offers the non-locking access. TLS This section deals with TLS also known as thread local storage. Introduction to threading Threads in computer science are entities within a process that can be scheduled independently from each other. The threads in the process share process wide data (file descriptors, etc.) but also have their own stack for their own data. Sometimes there is a need for process-wide data specific to a given thread. Imagine a name of the thread in execution or something like that. The traditional &unix; threading API, pthreads provides a way to do it via &man.pthread.key.create.3;, &man.pthread.setspecific.3; and &man.pthread.getspecific.3; where a thread can create a key to the thread local data and using &man.pthread.getspecific.3; or &man.pthread.getspecific.3; to manipulate those data. You can easily see that this is not the most comfortable way this could be accomplished. So various producers of C/C++ compilers introduced a better way. They defined a new modifier keyword thread that specifies that a variable is thread specific. A new method of accessing such variables was developed as well (at least on i386). The pthreads method tends to be implemented in userspace as a trivial lookup table. The performance of such a solution is not very good. So the new method uses (on i386) segment registers to address a segment, where TLS area is stored so the actual accessing of a thread variable is just appending the segment register to the address thus addressing via it. The segment registers are usually %gs and %fs acting like segment selectors. Every thread has its own area where the thread local data are stored and the segment must be loaded on every context switch. This method is very fast and used almost exclusively in the whole i386 &unix; world. Both &os; and &linux; implement this approach and it yields very good results. The only drawback is the need to reload the segment on every context switch which can slowdown context switches. &os; tries to avoid this overhead by using only 1 segment descriptor for this while &linux; uses 3. Interesting thing is that almost nothing uses more than 1 descriptor (only Wine seems to use 2) so &linux; pays this unnecessary price for context switches. Segments on i386 The i386 architecture implements the so called segments. A segment is a description of an area of memory. The base address (bottom) of the memory area, the end of it (ceiling), type, protection, etc. The memory described by a segment can be accessed using segment selector registers (%cs, %ds, %ss, %es, %fs, %gs). For example let us suppose we have a segment which base address is 0x1234 and length and this code: mov %edx,%gs:0x10 This will load the content of the %edx register into memory location 0x1244. Some segment registers have a special use, for example %cs is used for code segment and %ss is used for stack segment but %fs and %gs are generally unused. Segments are either stored in a global GDT table or in a local LDT table. LDT is accessed via an entry in the GDT. The LDT can store more types of segments. LDT can be per process. Both tables define up to 8191 entries. Implementation on &linux; i386 There are two main ways of setting up TLS in &linux;. It can be set when cloning a process using the clone syscall or it can call set_thread_area. When a process passes CLONE_SETTLS flag to clone, the kernel expects the memory pointed to by the %esi register a &linux; user space representation of a segment, which gets translated to the machine representation of a segment and loaded into a GDT slot. The GDT slot can be specified with a number or -1 can be used meaning that the system itself should choose the first free slot. In practice, the vast majority of programs use only one TLS entry and does not care about the number of the entry. We exploit this in the emulation and in fact depend on it. Emulation of &linux; TLS i386 Loading of TLS for the current thread happens by calling set_thread_area while loading TLS for a second process in clone is done in the separate block in clone. Those two functions are very similar. The only difference being the actual loading of the GDT segment, which happens on the next context switch for the newly created process while set_thread_area must load this directly. The code basically does this. It copies the &linux; form segment descriptor from the userland. The code checks for the number of the descriptor but because this differs between &os; and &linux; we fake it a little. We only support indexes of 6, 3 and -1. The 6 is genuine &linux; number, 3 is genuine &os; one and -1 means autoselection. Then we set the descriptor number to constant 3 and copy out this to the userspace. We rely on the userspace process using the number from the descriptor but this works most of the time (have never seen a case where this did not work) as the userspace process typically passes in 1. Then we convert the descriptor from the &linux; form to a machine dependant form (i.e. operating system independent form) and copy this to the &os; defined segment descriptor. Finally we can load it. We assign the descriptor to threads PCB (process control block) and load the %gs segment using load_gs. This loading must be done in a critical section so that nothing can interrupt us. The CLONE_SETTLS case works exactly like this just the loading using load_gs is not performed. The segment used for this (segment number 3) is shared for this use between &os; processes and &linux; processes so the &linux; emulation layer does not add any overhead over plain &os;. amd64 The amd64 implementation is similar to the i386 one but there was initially no 32bit segment descriptor used for this purpose (hence not even native 32bit TLS users worked) so we had to add such a segment and implement its loading on every context switch (when a flag signaling use of 32bit is set). Apart from this the TLS loading is exactly the same just the segment numbers are different and the descriptor format and the loading differs slightly. Futexes Introduction to synchronization Threads need some kind of synchronization and &posix; provides some of them: mutexes for mutual exclusion, read-write locks for mutual exclusion with biased ratio of reads and writes and condition variables for signaling a status change. It is interesting to note that &posix; threading API lacks support for semaphores. Those synchronization routines implementations are heavily dependant on the type threading support we have. In pure 1:M (userspace) model the implementation can be solely done in userspace and thus be very fast (the condition variables will probably end up being implemented using signals, i.e. not fast) and simple. In 1:1 model, the situation is also quite clear - the threads must be synchronized using kernel facilities (which is very slow because a syscall must be performed). The mixed M:N scenario just combines the first and second approach or rely solely on kernel. Threads synchronization is a vital part of thread-enabled programming and its performance can affect resulting program a lot. Recent benchmarks on &os; operating system showed that an improved sx_lock implementation yielded 40% speedup in ZFS (a heavy sx user), this is in-kernel stuff but it shows clearly how important the performance of synchronization primitives is. Threaded programs should be written with as little contention on locks as possible. Otherwise, instead of doing useful work the thread just waits on a lock. Because of this, the most well written threaded programs show little locks contention. Futexes introduction &linux; implements 1:1 threading, i.e. it has to use in-kernel synchronization primitives. As stated earlier, well written threaded programs have little lock contention. So a typical sequence could be performed as two atomic increase/decrease mutex reference counter, which is very fast, as presented by the following example: pthread_mutex_lock(&mutex); .... pthread_mutex_unlock(&mutex); 1:1 threading forces us to perform two syscalls for those mutex calls, which is very slow. The solution &linux; 2.6 implements is called futexes. Futexes implement the check for contention in userspace and call kernel primitives only in a case of contention. Thus the typical case takes place without any kernel intervention. This yields reasonably fast and flexible synchronization primitives implementation. Futex API The futex syscall looks like this: int futex(void *uaddr, int op, int val, struct timespec *timeout, void *uaddr2, int val3); In this example uaddr is an address of the mutex in userspace, op is an operation we are about to perform and the other parameters have per-operation meaning. Futexes implement the following operations: FUTEX_WAIT FUTEX_WAKE FUTEX_FD FUTEX_REQUEUE FUTEX_CMP_REQUEUE FUTEX_WAKE_OP FUTEX_WAIT This operation verifies that on address uaddr the value val is written. If not, EWOULDBLOCK is returned, otherwise the thread is queued on the futex and gets suspended. If the argument timeout is non-zero it specifies the maximum time for the sleeping, otherwise the sleeping is infinite. FUTEX_WAKE This operation takes a futex at uaddr and wakes up val first futexes queued on this futex. FUTEX_FD This operations associates a file descriptor with a given futex. FUTEX_REQUEUE This operation takes val threads queued on futex at uaddr, wakes them up, and takes val2 next threads and requeues them on futex at uaddr2. FUTEX_CMP_REQUEUE This operation does the same as FUTEX_REQUEUE but it checks that val3 equals to val first. FUTEX_WAKE_OP This operation performs an atomic operation on val3 (which contains coded some other value) and uaddr. Then it wakes up val threads on futex at uaddr and if the atomic operation returned a positive number it wakes up val2 threads on futex at uaddr2. The operations implemented in FUTEX_WAKE_OP: FUTEX_OP_SET FUTEX_OP_ADD FUTEX_OP_OR FUTEX_OP_AND FUTEX_OP_XOR There is no val2 parameter in the futex prototype. The val2 is taken from the struct timespec *timeout parameter for operations FUTEX_REQUEUE, FUTEX_CMP_REQUEUE and FUTEX_WAKE_OP. Futex emulation in &os; The futex emulation in &os; is taken from NetBSD and further extended by us. It is placed in linux_futex.c and linux_futex.h files. The futex structure looks like: struct futex { void *f_uaddr; int f_refcount; LIST_ENTRY(futex) f_list; TAILQ_HEAD(lf_waiting_paroc, waiting_proc) f_waiting_proc; }; And the structure waiting_proc is: struct waiting_proc { struct thread *wp_t; struct futex *wp_new_futex; TAILQ_ENTRY(waiting_proc) wp_list; }; futex_get / futex_put A futex is obtained using the futex_get function, which searches a linear list of futexes and returns the found one or creates a new futex. When releasing a futex from the use we call the futex_put function, which decreases a reference counter of the futex and if the refcount reaches zero it is released. futex_sleep When a futex queues a thread for sleeping it creates a working_proc structure and puts this structure to the list inside the futex structure then it just performs a &man.tsleep.9; to suspend the thread. The sleep can be timed out. After &man.tsleep.9; returns (the thread was woken up or it timed out) the working_proc structure is removed from the list and is destroyed. All this is done in the futex_sleep function. If we got woken up from futex_wake we have wp_new_futex set so we sleep on it. This way the actual requeueing is done in this function. futex_wake Waking up a thread sleeping on a futex is performed in the futex_wake function. First in this function we mimic the strange &linux; behaviour, where it wakes up N threads for all operations, the only exception is that the REQUEUE operations are performed on N+1 threads. But this usually does not make any difference as we are waking up all threads. Next in the function in the loop we wake up n threads, after this we check if there is a new futex for requeueing. If so, we requeue up to n2 threads on the new futex. This cooperates with futex_sleep. futex_wake_op The FUTEX_WAKE_OP operation is quite complicated. First we obtain two futexes at addresses uaddr and uaddr2 then we perform the atomic operation using val3 and uaddr2. Then val waiters on the first futex is woken up and if the atomic operation condition holds we wake up val2 (i.e. timeout) waiter on the second futex. futex atomic operation The atomic operation takes two parameters encoded_op and uaddr. The encoded operation encodes the operation itself, comparing value, operation argument, and comparing argument. The pseudocode for the operation is like this one: oldval = *uaddr2 *uaddr2 = oldval OP oparg And this is done atomically. First a copying in of the number at uaddr is performed and the operation is done. The code handles page faults and if no page fault occurs oldval is compared to cmparg argument with cmp comparator. Futex locking Futex implementation uses two lock lists protecting sx_lock and global locks (either Giant or another sx_lock). Every operation is performed locked from the start to the very end. Various syscalls implementation In this section I am going to describe some smaller syscalls that are worth mentioning because their implementation is not obvious or those syscalls are interesting from other point of view. *at family of syscalls During development of &linux; 2.6.16 kernel, the *at syscalls were added. Those syscalls (openat for example) work exactly like their at-less counterparts with the slight exception of the dirfd parameter. This parameter changes where the given file, on which the syscall is to be performed, is. When the filename parameter is absolute dirfd is ignored but when the path to the file is relative, it comes to the play. The dirfd parameter is a directory relative to which the relative pathname is checked. The dirfd parameter is a file descriptor of some directory or AT_FDCWD. So for example the openat syscall can be like this: file descriptor 123 = /tmp/foo/, current working directory = /tmp/ openat(123, /tmp/bah\, flags, mode) /* opens /tmp/bah */ openat(123, bah\, flags, mode) /* opens /tmp/foo/bah */ openat(AT_FDWCWD, bah\, flags, mode) /* opens /tmp/bah */ openat(stdio, bah\, flags, mode) /* returns error because stdio is not a directory */ This infrastructure is necessary to avoid races when opening files outside the working directory. Imagine that a process consists of two threads, thread A and thread B. Thread A issues open(./tmp/foo/bah., flags, mode) and before returning it gets preempted and thread B runs. Thread B does not care about the needs of thread A and renames or removes /tmp/foo/. We got a race. To avoid this we can open /tmp/foo and use it as dirfd for openat syscall. This also enables user to implement per-thread working directories. &linux; family of *at syscalls contains: linux_openat, linux_mkdirat, linux_mknodat, linux_fchownat, linux_futimesat, linux_fstatat64, linux_unlinkat, linux_renameat, linux_linkat, linux_symlinkat, linux_readlinkat, linux_fchmodat and linux_faccessat. All these are implemented using the modified &man.namei.9; routine and simple wrapping layer. Implementation The implementation is done by altering the &man.namei.9; routine (described above) to take additional parameter dirfd in its nameidata structure, which specifies the starting point of the pathname lookup instead of using the current working directory every time. The resolution of dirfd from file descriptor number to a vnode is done in native *at syscalls. When dirfd is AT_FDCWD the dvp entry in nameidata structure is NULL but when dirfd is a different number we obtain a file for this file descriptor, check whether this file is valid and if there is vnode attached to it then we get a vnode. Then we check this vnode for being a directory. In the actual &man.namei.9; routine we simply substitute the dvp vnode for dp variable in the &man.namei.9; function, which determines the starting point. The &man.namei.9; is not used directly but via a trace of different functions on various levels. For example the openat goes like this: openat() --> kern_openat() --> vn_open() -> namei() For this reason kern_open and vn_open must be altered to incorporate the additional dirfd parameter. No compat layer is created for those because there are not many users of this and the users can be easily converted. This general implementation enables &os; to implement their own *at syscalls. This is being discussed right now. Ioctl The ioctl interface is quite fragile due to its generality. We have to bear in mind that devices differ between &linux; and &os; so some care must be applied to do ioctl emulation work right. The ioctl handling is implemented in linux_ioctl.c, where linux_ioctl function is defined. This function simply iterates over sets of ioctl handlers to find a handler that implements a given command. The ioctl syscall has three parameters, the file descriptor, command and an argument. The command is a 16-bit number, which in theory is divided into high 8 bits determining class of the ioctl command and low 8 bits, which are the actual command within the given set. The emulation takes advantage of this division. We implement handlers for each set, like sound_handler or disk_handler. Each handler has a maximum command and a minimum command defined, which is used for determining what handler is used. There are slight problems with this approach because &linux; does not use the set division consistently so sometimes ioctls for a different set are inside a set they should not belong to (SCSI generic ioctls inside cdrom set, etc.). &os; currently does not implement many &linux; ioctls (compared to NetBSD, for example) but the plan is to port those from NetBSD. The trend is to use &linux; ioctls even in the native &os; drivers because of the easy porting of applications. Debugging Every syscall should be debuggable. For this purpose we introduce a small infrastructure. We have the ldebug facility, which tells whether a given syscall should be debugged (settable via a sysctl). For printing we have LMSG and ARGS macros. Those are used for altering a printable string for uniform debugging messages. Conclusion Results As of April 2007 the &linux; emulation layer is capable of emulating the &linux; 2.6.16 kernel quite well. The remaining problems concern futexes, unfinished *at family of syscalls, problematic signals delivery, missing epoll and inotify and probably some bugs we have not discovered yet. Despite this we are capable of running basically all the &linux; programs included in &os; Ports Collection with Fedora Core 4 at 2.6.16 and there are some rudimentary reports of success with Fedora Core 6 at 2.6.16. The Fedora Core 6 linux_base was recently committed enabling some further testing of the emulation layer and giving us some more hints where we should put our effort in implementing missing stuff. We are able to run the most used applications like www/linux-firefox, www/linux-opera, net-im/skype and some games from the Ports Collection. Some of the programs exhibit bad behaviour under 2.6 emulation but this is currently under investigation and hopefully will be fixed soon. The only big application that is known not to work is the &linux; &java; Development Kit and this is because of the requirement of epoll facility which is not directly related to the &linux; kernel 2.6. We hope to enable 2.6.16 emulation by default some time after &os; 7.0 is released at least to expose the 2.6 emulation parts for some wider testing. Once this is done we can switch to Fedora Core 6 linux_base, which is the ultimate plan. Future work Future work should focus on fixing the remaining issues with futexes, implement the rest of the *at family of syscalls, fix the signal delivery and possibly implement the epoll and inotify facilities. We hope to be able to run the most important programs flawlessly soon, so we will be able to switch to the 2.6 emulation by default and make the Fedora Core 6 the default linux_base because our currently used Fedora Core 4 is not supported any more. The other possible goal is to share our code with NetBSD and DragonflyBSD. NetBSD has some support for 2.6 emulation but its far from finished and not really tested. DragonflyBSD has expressed some interest in porting the 2.6 improvements. Generally, as &linux; develops we would like to keep up with their development, implementing newly added syscalls. Splice comes to mind first. Some already implemented syscalls are also heavily crippled, for example mremap and others. Some performance improvements can also be made, finer grained locking and others. Team I cooperated on this project with (in alphabetical order): - &a.jhb; + &a.jhb.email; - &a.kib; + &a.kib.email; Emmanuel Dreyfus Scot Hetzel - &a.jkim; + &a.jkim.email; - &a.netchild; + &a.netchild.email; - &a.ssouhlal; + &a.ssouhlal.email; Li Xiao - &a.davidxu; + &a.davidxu.email; I would like to thank all those people for their advice, code reviews and general support. Literatures Marshall Kirk McKusick - George V. Nevile-Neil. Design and Implementation of the &os; operating system. Addison-Wesley, 2005.

diff --git a/en_US.ISO8859-1/articles/mailing-list-faq/article.xml b/en_US.ISO8859-1/articles/mailing-list-faq/article.xml index 4f839f52cc..d1423db9ca 100644 --- a/en_US.ISO8859-1/articles/mailing-list-faq/article.xml +++ b/en_US.ISO8859-1/articles/mailing-list-faq/article.xml @@ -1,517 +1,517 @@

Frequently Asked Questions About The &os; Mailing Lists The &os; Documentation Project 2004 2005 The &os; Documentation Project $FreeBSD$ $FreeBSD$ This is the FAQ for the &os; mailing lists. If you are interested in helping with this project, send email to the &a.doc;. The latest version of this document is always available from the &os; World Wide Web server. It may also be downloaded as one large HTML file with HTTP or as plain text, PostScript, PDF, etc. from the &os; FTP server. You may also want to Search the FAQ. Introduction As is usual with FAQs, this document aims to cover the most frequently asked questions concerning the &os; mailing lists (and of course answer them!). Although originally intended to reduce bandwidth and avoid the same old questions being asked over and over again, FAQs have become recognized as valuable information resources. This document attempts to represent a community consensus, and as such it can never really be authoritative. However, if you find technical errors within this document, or have suggestions about items that should be added, please either submit a PR, or email the &a.doc;. Thanks. What is the purpose of the &os; mailing lists? The &os; mailing lists serve as the primary communication channels for the &os; community, covering many different topic areas and communities of interest. Who is the audience for the &os; mailing lists? This depends on charter of each individual list. Some lists are more oriented to developers; some are more oriented towards the &os; community as a whole. Please see this list for the current summary. Are the &os; mailing lists open for anyone to participate? Again, this depends on charter of each individual list. Please read the charter of a mailing list before you post to it, and respect it when you post. This will help everyone to have a better experience with the lists. If after reading the above lists, you still do not know which mailing list to post a question to, you will probably want to post to freebsd-questions (but see below, first). Also note that the mailing lists have traditionally been open to postings from non-subscribers. This has been a deliberate choice, to help make joining the &os; community an easier process, and to encourage open sharing of ideas. However, due to past abuse by some individuals, certain lists now have a policy where postings from non-subscribers must be manually screened to ensure that they are appropriate. You can use the Mailman web interface to subscribe to any of the public lists. How can I unsubscribe? You can use the same interface as above; or, you can follow the instructions that are at the bottom of every mailing list message that is sent. Please do not send unsubscribe messages directly to the public lists themselves. First, this will not accomplish your goal, and second, it will irritate the existing subscribers, and you will probably get flamed. This is a classical mistake when using mailing lists; please try to avoid it. Are archives available? Yes. Threaded archives are available here. Are mailing lists available in a digest format? Yes. See the Mailman web interface. Mailing List Etiquette Participation in the mailing lists, like participation in any community, requires a common basis for communication. Please make only appropriate postings, and follow common rules of etiquette. What should I do before I post? You have already taken the most important step by reading this document. However, if you are new to &os;, you may first need to familiarize yourself with the software, and all the social history around it, by reading the numerous books and articles that are available. Items of particular interest include the &os; Frequently Asked Questions (FAQ) document, the &os; Handbook, and the articles How to get best results from the FreeBSD-questions mailing list, Explaining BSD, and &os; First Steps. It is always considered bad form to ask a question that is already answered in the above documents. This is not because the volunteers who work on this project are particularly mean people, but after a certain number of times answering the same questions over and over again, frustration begins to set in. This is particularly true if there is an existing answer to the question that is already available. Always keep in mind that almost all of the work done on &os; is done by volunteers, and that we are only human. What constitutes an inappropriate posting? Postings must be in accordance with the charter of the mailing list. Personal attacks are discouraged. As good net-citizens, we should try to hold ourselves to high standards of behavior. Spam is not allowed, ever. The mailing lists are actively processed to ban offenders to this rule. What is considered proper etiquette when posting to the mailing lists? Please wrap lines at 75 characters, since not everyone uses fancy GUI mail reading programs. Please respect the fact that bandwidth is not infinite. Not everyone reads email through high-speed connections, so if your posting involves something like the content of config.log or an extensive stack trace, please consider putting that information up on a website somewhere and just provide a URL to it. Remember, too, that these postings will be archived indefinitely, so huge postings will simply inflate the size of the archives long after their purpose has expired. Format your message so that it is legible, and PLEASE DO NOT SHOUT!!!!!. Do not underestimate the effect that a poorly formatted mail message has, and not just on the &os; mailing lists. Your mail message is all that people see of you, and if it is poorly formatted, badly spelled, full of errors, and/or has lots of exclamation points, it will give people a poor impression of you. Please use an appropriate human language for a particular mailing list. Many non-English mailing lists are available. For the ones that are not, we do appreciate that many people do not speak English as their first language, and we try to make allowances for that. It is considered particularly poor form to criticize non-native speakers for spelling or grammatical errors. &os; has an excellent track record in this regard; please, help us to uphold that tradition. Please use a standards-compliant Mail User Agent (MUA). A lot of badly formatted messages come from bad mailers or badly configured mailers. The following mailers are known to send out badly formatted messages without you finding out about them: exmh µsoft; Exchange µsoft; &outlook; Try not to use MIME: a lot of people use mailers which do not get on very well with MIME. Make sure your time and time zone are set correctly. This may seem a little silly, since your message still gets there, but many of the people on these mailing lists get several hundred messages a day. They frequently sort the incoming messages by subject and by date, and if your message does not come before the first answer, they may assume that they missed it and not bother to look. A lot of the information you need to supply is the output of programs, such as &man.dmesg.8;, or console messages, which usually appear in /var/log/messages. Do not try to copy this information by typing it in again; not only it is a real pain, but you are bound to make a mistake. To send log file contents, either make a copy of the file and use an editor to trim the information to what is relevant, or cut and paste into your message. For the output of programs like dmesg, redirect the output to a file and include that. For example, &prompt.user; dmesg > /tmp/dmesg.out This redirects the information to the file /tmp/dmesg.out. When using cut-and-paste, please be aware that some such operations badly mangle their messages. This is of particular concern when posting contents of Makefiles, where tab is a significant character. This is a very common, and very annoying, problem with submissions to the GNATS Problem Reports database. Makefiles with tabs changed to either spaces, or the annoying =3B escape sequence, create a great deal of aggravation for committers. What are the special etiquette consideration when replying to an existing posting on the mailing lists? Please include relevant text from the original message. Trim it to the minimum, but do not overdo it. It should still be possible for somebody who did not read the original message to understand what you are talking about. This is especially important for postings of the type "yes, I see this too", where the initial posting was dozens or hundreds of lines. Use some technique to identify which text came from the original message, and which text you add. A common convention is to prepend > to the original message. Leaving white space after the > and leaving empty lines between your text and the original text both make the result more readable. Please ensure that the attributions of the text you are quoting is correct. People can become offended if you attribute words to them that they themselves did not write. Please do not top post. By this, we mean that if you are replying to a message, please put your replies after the text that you copy in your reply. A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? (Thanks to Randy Bush for the joke.) Recurring Topics On The Mailing Lists Participation in the mailing lists, like participation in any community, requires a common basis for communication. Many of the mailing lists presuppose a knowledge of the Project's history. In particular, there are certain topics that seem to regularly occur to newcomers to the community. It is the responsibility of each poster to ensure that their postings do not fall into one of these categories. By doing so, you will help the mailing lists to stay on-topic, and probably save yourself being flamed in the process. The best method to avoid this is to familiarize yourself with the mailing list archives, to help yourself understand the background of what has gone before. In this, the mailing list search interface is invaluable. (If that method does not yield useful results, please supplement it with a search with your favorite major search engine). By familiarizing yourself with the archives, not only will you learn what topics have been discussed before, but also how discussion tends to proceed on that list, who the participants are, and who the target audience is. These are always good things to know before you post to any mailing list, not just a &os; mailing list. There is no doubt that the archives are quite extensive, and some questions recur more often than others, sometimes as followups where the subject line no longer accurately reflects the new content. Nevertheless, the burden is on you, the poster, to do your homework to help avoid these recurring topics. What Is A "Bikeshed"? Literally, a bikeshed is a small outdoor shelter into which one may store one's two-wheeled form of transportation. However, in &os; parlance, the term refers to topics that are simple enough that (nearly) anyone can offer an opinion about, and often (nearly) everyone does. The genesis of this term is explained in more detail in this document. You simply must have a working knowledge of this concept before posting to any &os; mailing list. More generally, a bikeshed is a topic that will tend to generate immediate meta-discussions and flames if you have not read up on their past history. Please help us to keep the mailing lists as useful for as many people as possible by avoiding bikesheds whenever you can. Thanks. Acknowledgments - &a.grog; + &a.grog.email; Original author of most of the material on mailing list etiquette, taken from the article on How to get best results from the FreeBSD-questions mailing list. - &a.linimon; + &a.linimon.email; Creation of the rough draft of this FAQ.

diff --git a/en_US.ISO8859-1/articles/nanobsd/article.xml b/en_US.ISO8859-1/articles/nanobsd/article.xml index a126f2f99f..a12c10305d 100644 --- a/en_US.ISO8859-1/articles/nanobsd/article.xml +++ b/en_US.ISO8859-1/articles/nanobsd/article.xml @@ -1,507 +1,507 @@

Introduction to NanoBSD Daniel Gerzo 2006 The FreeBSD Documentation Project &tm-attrib.freebsd; &tm-attrib.general; $FreeBSD$ $FreeBSD$ This document provides information about the NanoBSD tools, which can be used to create &os; system images for embedded applications, suitable for use on a Compact Flash card (or other mass storage medium). Introduction to NanoBSD NanoBSD NanoBSD is a tool currently - developed by &a.phk;. It creates a &os; system image for embedded + developed by &a.phk.email;. It creates a &os; system image for embedded applications, suitable for use on a Compact Flash card (or other mass storage medium). It can be used to build specialized install images, designed for easy installation and maintenance of systems commonly called computer appliances. Computer appliances have their hardware and software bundled in the product, which means all applications are pre-installed. The appliance is plugged into an existing network and can begin working (almost) immediately. The features of NanoBSD include: Ports and packages work as in &os; — Every single application can be installed and used in a NanoBSD image, the same way as in &os;. No missing functionality — If it is possible to do something with &os;, it is possible to do the same thing with NanoBSD, unless the specific feature or features were explicitly removed from the NanoBSD image when it was created. Everything is read-only at run-time — It is safe to pull the power-plug. There is no necessity to run &man.fsck.8; after a non-graceful shutdown of the system. Easy to build and customize — Making use of just one shell script and one configuration file it is possible to build reduced and customized images satisfying any arbitrary set of requirements. NanoBSD Howto The design of NanoBSD Once the image is present on the medium, it is possible to boot NanoBSD. The mass storage medium is divided into three parts by default: Two image partitions: code#1 and code#2. The configuration file partition, which can be mounted under the /cfg directory at run time. These partitions are normally mounted read-only. The /etc and /var directories are &man.md.4; (malloc) disks. The configuration file partition persists under the /cfg directory. It contains files for /etc directory and is briefly mounted read-only right after the system boot, therefore it is required to copy modified files from /etc back to the /cfg directory if changes are expected to persist after the system restarts. Making persistent changes to <filename>/etc/resolv.conf</filename> &prompt.root; vi /etc/resolv.conf [...] &prompt.root; mount /cfg &prompt.root; cp /etc/resolv.conf /cfg &prompt.root; umount /cfg The partition containing /cfg should be mounted only at boot time and while overriding the configuration files. Keeping /cfg mounted at all times is not a good idea, especially if the NanoBSD system runs off a mass storage medium that may be adversely affected by a large number of writes to the partition (i.e. when the filesystem syncer flushes data to the system disks). Building a NanoBSD image A NanoBSD image is built using a simple nanobsd.sh shell script, which can be found in the /usr/src/tools/tools/nanobsd directory. This script creates an image, which can be copied on the storage medium using the &man.dd.1; utility. The necessary commands to build a NanoBSD image are: &prompt.root; cd /usr/src/tools/tools/nanobsd &prompt.root; sh nanobsd.sh &prompt.root; cd /usr/obj/nanobsd.full &prompt.root; dd if=_.disk.full of=/dev/da0 bs=64k Change the current directory to the base directory of the NanoBSD build script. Start the build process. Change the current directory to the place where the built images are located. Install NanoBSD onto the storage medium. Customizing a NanoBSD image This is probably the most important and most interesting feature of NanoBSD. This is also where you will be spending most of the time when developing with NanoBSD. Invocation of the following command will force the nanobsd.sh to read its configuration from the myconf.nano file located in the current directory: &prompt.root; sh nanobsd.sh -c myconf.nano Customization is done in two ways: Configuration options Custom functions Configuration options With configuration settings, it is possible to configure options passed to both the buildworld and installworld stages of the NanoBSD build process, as well as internal options passed to the main build process of NanoBSD. Through these options it is possible to cut the system down, so it will fit on as little as 64MB. You can use the configuration options to trim down &os; even more, until it will consists of just the kernel and two or three files in the userland. The configuration file consists of configuration options, which override the default values. The most important directives are: NANO_NAME — Name of build (used to construct the workdir names). NANO_SRC — Path to the source tree used to build the image. NANO_KERNEL — Name of kernel configuration file used to build kernel. CONF_BUILD — Options passed to the buildworld stage of the build. CONF_INSTALL — Options passed to the installworld stage of the build. CONF_WORLD — Options passed to both the buildworld and the installworld stage of the build. FlashDevice — Defines what type of media to use. Check the FlashDevice.sub file for more details. Custom functions It is possible to fine-tune NanoBSD using shell functions in the configuration file. The following example illustrates the basic model of custom functions: cust_foo () ( echo "bar=baz" > \ ${NANO_WORLDDIR}/etc/foo ) customize_cmd cust_foo A more useful example of a customization function is the following, which changes the default size of the /etc directory from 5MB to 30MB: cust_etc_size () ( cd ${NANO_WORLDDIR}/conf echo 30000 > default/etc/md_size ) customize_cmd cust_etc_size There are a few default pre-defined customization functions ready for use: cust_comconsole — Disables &man.getty.8; on the VGA devices (the /dev/ttyv* device nodes) and enables the use of the COM1 serial port as the system console. cust_allow_ssh_root — Allow root to login via &man.sshd.8;. cust_install_files — Installs files from the nanobsd/Files directory, which contains some useful scripts for system administration. Adding packages Packages can be added to a NanoBSD image using a custom function. The following function will install all the packages located in /usr/src/tools/tools/nanobsd/packages: install_packages () ( mkdir -p ${NANO_WORLDDIR}/packages cp /usr/src/tools/tools/nanobsd/packages/* ${NANO_WORLDDIR}/packages chroot ${NANO_WORLDDIR} sh -c 'cd packages; pkg_add -v *;cd ..;' rm -rf ${NANO_WORLDDIR}/packages ) customize_cmd install_packages Configuration file example A complete example of a configuration file for building a custom NanoBSD image can be: NANO_NAME=custom NANO_SRC=/usr/src NANO_KERNEL=MYKERNEL NANO_IMAGES=2 CONF_BUILD=' NO_KLDLOAD=YES NO_NETGRAPH=YES NO_PAM=YES ' CONF_INSTALL=' NO_ACPI=YES NO_BLUETOOTH=YES NO_CVS=YES NO_FORTRAN=YES NO_HTML=YES NO_LPR=YES NO_MAN=YES NO_SENDMAIL=YES NO_SHAREDOCS=YES NO_EXAMPLES=YES NO_INSTALLLIB=YES NO_CALENDAR=YES NO_MISC=YES NO_SHARE=YES ' CONF_WORLD=' NO_BIND=YES NO_MODULES=YES NO_KERBEROS=YES NO_GAMES=YES NO_RESCUE=YES NO_LOCALES=YES NO_SYSCONS=YES NO_INFO=YES ' FlashDevice SanDisk 1G cust_nobeastie() ( touch ${NANO_WORLDDIR}/boot/loader.conf echo "beastie_disable=\"YES\"" >> ${NANO_WORLDDIR}/boot/loader.conf ) customize_cmd cust_comconsole customize_cmd cust_install_files customize_cmd cust_allow_ssh_root customize_cmd cust_nobeastie Updating NanoBSD The update process of NanoBSD is relatively simple: Build a new NanoBSD image, as usual. Upload the new image into an unused partition of a running NanoBSD appliance. The most important difference of this step from the initial NanoBSD installation is that now instead of using the _.disk.full file (which contains an image of the entire disk), the _.disk.image image is installed (which contains an image of a single system partition). Reboot, and start the system from the newly installed partition. If all goes well, the upgrade is finished. If anything goes wrong, reboot back into the previous partition (which contains the old, working image), to restore system functionality as fast as possible. Fix any problems of the new build, and repeat the process. To install new image onto the running NanoBSD system, it is possible to use either the updatep1 or updatep2 script located in the /root directory, depending from which partition is running the current system. According to which services are available on host serving new NanoBSD image and what type of transfer is preferred, it is possible to examine one of these three ways: Using &man.ftp.1; If the transfer speed is in first place, use this example: &prompt.root; ftp myhost get _.disk.image "| sh updatep1" Using &man.ssh.1; If a secure transfer is preferred, consider using this example: &prompt.root; ssh myhost cat _.disk.image.gz | zcat | sh updatep1 Using &man.nc.1; Try this example if the remote host is not running neither &man.ftpd.8; or &man.sshd.8; service: At first, open a TCP listener on host serving the image and make it send the image to client: myhost&prompt.root; nc -l 2222 < _.disk.image Make sure that the used port is not blocked to receive incoming connections from NanoBSD host by firewall. Connect to the host serving new image and execute updatep1 script: &prompt.root; nc myhost 2222 | sh updatep1

diff --git a/en_US.ISO8859-1/articles/releng-packages/article.xml b/en_US.ISO8859-1/articles/releng-packages/article.xml index cfcef421c2..ff665828cd 100644 --- a/en_US.ISO8859-1/articles/releng-packages/article.xml +++ b/en_US.ISO8859-1/articles/releng-packages/article.xml @@ -1,364 +1,364 @@

FreeBSD Release Engineering for Third Party Software Packages Steve Price

steve@FreeBSD.org

&tm-attrib.freebsd; &tm-attrib.intel; &tm-attrib.xfree86; &tm-attrib.general; $FreeBSD$ $FreeBSD$ This paper describes the approach used by the FreeBSD ports management team to produce a high quality package set suitable for official FreeBSD release media. This document is a work in progress, but eventually it will cover the process used to build a clean package set on the FreeBSD.org Ports Cluster, how to configure any other set of machines as a ports cluster, how to split up the packages for the release media, and how to verify that a package set is consistent. Building packages from the Ports Collection The FreeBSD Ports collection is a collection of over &os.numports; third-party software packages available for FreeBSD. The &a.portmgr; is responsible for maintaining a consistent ports tree that can be used to create the binary packages that accompany a given FreeBSD release. The Ports Cluster In order to provide a consistent set of third-party packages for FreeBSD releases, every port is built in a separate chroot environment, starting with an empty /usr/local and /usr/X11R6. The requisite dependencies are installed as packages before the build proceeds. This enforces consistency in the package build process. By starting the package build in a pristine environment, we can assure that the package metadata (such as required dependencies) is accurate. This way, we will never generate packages that might work on some systems and not on others depending on what software was previously installed. The Ports Cluster for the x86 architecture currently consists of a master node (Dual &pentium; III 733MHz) and 8 slave nodes (&pentium; III 800MHz) to do the actual package builds. With this configuration, a complete package build takes over 24 hours. These machines are co-located with the other FreeBSD Project equipment at Yahoo's corner of Exodus in Santa Clara, CA. The Ports Cluster for the Alpha architecture consists of 7 PWS 500A machines donated by Compaq and also co-located with Yahoo's facilities. The Package Split For FreeBSD 4.4 over 4.1 gigabytes of packages were created. This causes a problem for CDROM distributions because we would like to ship as many packages as possible without making the user insert another disc to satisfy dependencies. The solution is to create clusters of like packages with similar dependencies and group these onto specific discs. This section describes the software and methodology used to create those package sets for the official FreeBSD release discs. The scripts and other files needed to produce a package split can be found in the CVS tree in ports/Tools/scripts/release. Copy this directory to a machine that has enough free disk space to hold 2 to 3 times the size of the package set that you wish to split. The following scripts are present in this directory: config This file contains the free space on each disc and whether packages, distfiles, or both are allowed on any given disc. The first column is the disc name. It must be of the form disc[0-9a-z]. Currently it is set up to allow for 10 discs (4 for the release set and 6 for the toolkit). There is an implied extra disc called scratch where all of the remaining distfiles/packages land if they do not fit elsewhere. The second column can be either a 1 or 0, where 1 says that it is okay to place packages on this disc. The third column works the same way, but it controls whether distfiles are placed on this disc. The last column denotes the number of bytes of free space on a disc. doit.sh This is the workhorse. Once you have all the files in place and things properly configured this script directs the process of splitting packages. Beware it is interactive so you need to keep an eye on it as it runs. More details on what happens in this script will follow. checkdeps.pl Makes sure all packages dependencies are satisfied given an INDEX file and a directory of packages. oneshot.pl This is where all the magic (and I use that term loosely as it is mostly just a brute force approach) happens. Given a list of required packages for each disc and a set of packages/distfiles this is the script that places a package or distfile on a disc along with all of its dependencies. print-cdrom-packages.sh This file is a copy of src/release/scripts/print-cdrom-packages.sh from the release you are working on. scrubindex.pl This script removes lines from an INDEX file for packages that are not present. It also removes the &xfree86; dependencies. NOTE: you will need to tweak the value of the xdep variable to make sure the version number is correct. setup.sh This is a helper script that I use on the ports building cluster to grab a copy of the ports tree and the matching set of the packages/distfiles. Here is a checklist of things you will need to check or configure before going any further. Edit config to denote the number of discs you have, their sizes, and whether you want them want to contain packages, distfiles, both, or neither. Make sure you remove the gen directory if there is an old one laying around. This directory contains working files that will only be valid for the current split. On your first pass through a split it is best to fake the copying of packages and distfiles. This will save both time and disk space while you do a couple of trial runs to make sure things fit, etc. In the oneshot.pl set the fake variable to 1 and instead of actually copying the files it will &man.touch.1; them. Be sure you turn this off or set fake to 0 before you give the resultant discs to the person that will be mastering the discs otherwise they will get a directory full of zero-sized files. Make sure you have a recent copy of the print-cdrom-packages.sh and that it is from the correct release. Check to make sure the &xfree86; dependency in scrubindex.pl has the correct version number. You will also need to make sure this value is correct in doit.sh as well. Next you will need to get a copy of the ports tree, packages, and distfiles from a recent build on the package cluster. See the setup.sh for a working example but essentially here is what needs to be done. Grab a copy of ports.tar.gz and extract it into the ports directory alongside doit.sh and the scripts directory. Remove the packages/distfiles directories or symlinks. Bento has these as symlinks and you will have mixed results if you do not get rid of them before proceeding. Create a new ports/packages directory and copy the package set from the package building cluster. Create a new ports/distfiles directory and copy the distfiles from the package building cluster. NOTE: if you do not want any distfiles simply create the directory and leave it empty. This directory must be present even if it does not contain anything. Now we are finally ready for the fun task of actually splitting the packages. You start the processing by running ./doit.sh. Here is what it does the first time you run it. Create a list of the restricted (can not be on the master FTP site) ports. Asks you if you would like to remove the restricted ports. Most of the time you will want to answer (y)es here. Create a list of the packages/distfiles that can not be put on the discs. Asks you if you would like to remove the non-cdromable packages/distfiles. Most of the time you will want to answer (y)es here. Copies the INDEX from the ports directory to the gen directory. In doing so it removes the lines for ports where the packages do not exist. It also checks to make sure that all of the required dependency packages are present. Create a list of packages that are required on each disc. Asks you if you would like to populate the discs. After populating each disc it will check for missing dependencies, scrub the INDEX file, and create the CHECKSUM.MD5 file. Check to make sure the required packages made it on each disc and gives you a summary of the sizes of each disc. After going through this the first time if you are lucky enough that all of the required packages built and fit on each disc. All you need to do is set fake to 0 in oneshot.pl and re-run ./doit.sh. The second and subsequent times around it will skip steps 1-5 above. If you want to re-run any of those steps refer to doit.sh for which files need to be removed to not short-circuit those steps. If you want to repeat all of these steps then the easiest way is to rm -rf gen. Upon successful completion the packages/distfiles will be in the disc* directories and the leftover will be in the scratch directory. What to do if things go wrong? Here is some common gotchas and workarounds. Missing required packages This is a pretty common occurrence. You will either need to wait for a new set of packages where the missing packages were built or get someone to re-start the package build for you. Do not attempt to build the missing packages on your own machine and add them into the fray. While you might be able to get away with this if you are extremely careful the vast majority of the time you will miss some little detail and the simple process of adding a package could make hundreds of others come up mysteriously broken. Required packages will not fit This happens on occasion too and is relatively easy to fix. Simply edit print-cdrom-packages.sh to move packages around until they fit. Yes this is an iterative process and one of the reasons why you should enable fake in oneshot.pl until you have gotten things the way you want them. Re-run ./doit.sh after you made your adjustments. Required packages not on the right (or any) disc This usually means you did not add them to print-cdrom-packages.sh or you put them on the wrong disc. This script is the gospel by which this whole process determines where a package must be. If you want to force a package to land on a particular disc this is the only way to ensure that it will happen. If you get completely stuck and can not figure out why things - are borked or how to fix them then email &a.steve; for + are borked or how to fix them then email &a.steve.email; for assistance.

diff --git a/en_US.ISO8859-1/articles/releng/article.xml b/en_US.ISO8859-1/articles/releng/article.xml index 0e7ecd2bf1..ced95bf67e 100644 --- a/en_US.ISO8859-1/articles/releng/article.xml +++ b/en_US.ISO8859-1/articles/releng/article.xml @@ -1,1078 +1,1078 @@ The Release Engineering of Third Party Packages'> ]>

&os; Release Engineering November 2001 BSDCon Europe Murray Stokely I've been involved in the development of &os; based products since 1997 at Walnut Creek CDROM, BSDi, and now Wind River Systems. &os; 4.4 was the first official release of &os; that I played a significant part in.

murray@FreeBSD.org

&tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.intel; &tm-attrib.general; $FreeBSD$ 2013/02/26: This document is partially outdated and does not accurately describe the current release procedures of the &os; Release Engineering team. The &os; Release Engineering team is currently reviewing this document and will publish updated content soon. This paper describes the approach used by the &os; release engineering team to make production quality releases of the &os; Operating System. It details the methodology used for the official &os; releases and describes the tools available for those interested in producing customized &os; releases for corporate rollouts or commercial productization. Introduction The development of &os; is a very open process. &os; is comprised of contributions from thousands of people around the world. The &os; Project provides Subversion Subversion, access to the general public so that others can have access to log messages, diffs (patches) between development branches, and other productivity enhancements that formal source code management provides. This has been a huge help in attracting more talented developers to &os;. However, I think everyone would agree that chaos would soon manifest if write access to the main repository was opened up to everyone on the Internet. Therefore only a select group of nearly 300 people are given write access to the Subversion repository. These committers FreeBSD committers are usually the people who do the bulk of &os; development. An elected Core Team &os; Core Team of developers provide some level of direction over the project. The rapid pace of &os; development makes the main development branch unsuitable for the everyday use by the general public. In particular, stabilizing efforts are required for polishing the development system into a production quality release. To solve this conflict, development continues on several parallel tracks. The main development branch is the HEAD or trunk of our Subversion tree, known as &os;-CURRENT or -CURRENT for short. A set of more stable branches are maintained, known as &os;-STABLE or -STABLE for short. All branches live in a master Subversion repository maintained by the &os; Project. &os;-CURRENT is the bleeding-edge of &os; development where all new changes first enter the system. &os;-STABLE is the development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into &os;-CURRENT and have been thoroughly tested by our user community. The term stable in the name of the branch refers to the presumed Application Binary Interface stability, which is promised by the project. This means that a user application compiled on an older version of the system from the same branch works on a newer system from the same branch. The ABI stability has improved greatly from the compared to previous releases. In most cases, binaries from the older STABLE systems run unmodified on newer systems, including HEAD, assuming that the system management interfaces are not used. In the interim period between releases, monthly snapshots are built automatically by the &os; Project build machines and made available for download from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/. The widespread availability of binary release snapshots, and the tendency of our user community to keep up with -STABLE development with Subversion and make buildworld Rebuilding "world" helps to keep &os;-STABLE in a very reliable condition even before the quality assurance activities ramp up pending a major release. Bug reports and feature requests are continuously submitted by users throughout the release cycle. Problems reports are entered into our GNATS database GNATS: The GNU Bug Tracking System through email, the &man.send-pr.1; application, or via the web interface provided at . To service our most conservative users, individual release branches were introduced with &os; 4.3. These release branches are created shortly before a final release is made. After the release goes out, only the most critical security fixes and additions are merged onto the release branch. In addition to source updates via Subversion, binary patchkits are available to keep systems on the RELENG_X_Y branches updated. What this article describes The following sections of this article describe: The different phases of the release engineering process leading up to the actual system build. The actual build process. How the base release may be extended by third parties. Some of the lessons learned through the release of &os; 4.4. Future directions of development. Release Process New releases of &os; are released from the -STABLE branch at approximately four month intervals. The &os; release process begins to ramp up 70-80 days before the anticipated release date when the release engineer sends an email to the development mailing lists to remind developers that they only have 15 days to integrate new changes before the code freeze. During this time, many developers perform what have become known as MFC sweeps. MFC stands for Merge From CURRENT and it describes the process of merging a tested change from our -CURRENT development branch to our -STABLE branch. Project policy requires any change to be first applied to trunk, and merged to the -STABLE branches after sufficient external testing was done by -CURRENT users (developers are expected to extensively test the change before committing to -CURRENT, but it is impossible for a person to exercise all usages of the general-purpose operating system). Minimal MFC period is 3 days, which is typically used only for trivial or critical bugfixes. Code Review Sixty days before the anticipated release, the source repository enters a code freeze. During this time, all commits to the -STABLE branch must be approved by the &a.re;, the approval process is technically enforced by the pre-commit hook. The kinds of changes that are allowed during this period include: Bug fixes. Documentation updates. Security-related fixes of any kind. Minor changes to device drivers, such as adding new Device IDs. Driver updates from the vendors. Any additional change that the release engineering team feels is justified, given the potential risk. Shortly after the code freeze is started, a BETA1 image is built and released for widespread testing. During the code freeze, at least one beta image or release candidate is released every two weeks until the final release is ready. During the days preceeding the final release, the release engineering team is in constant communication with the security-officer team, the documentation maintainers, and the port maintainers to ensure that all of the different components required for a successful release are available. After the quality of the BETA images is satisfying enough, and no large and potentially risky changes are planned, the release branch is created and Release Candidate (RC) images are built from the release branch, instead of the BETA images from the STABLE branch. Also, the freeze on the STABLE branch is lifted and release branch enters a hard code freeze where it becomes much harder to justify new changes to the system unless a serious bug-fix or security issue is involved. Final Release Checklist When several BETA images have been made available for widespread testing and all major issues have been resolved, the final release polishing can begin. Creating the Release Branch In all examples below, $FSVN refers to the location of the &os; Subversion repository, svn+ssh://svn.freebsd.org/base/. The layout of &os; branches in Subversion is described in the Committer's Guide. The first step in creating a branch is to identify the revision of the stable/X sources that you want to branch from. &prompt.root; svn log -v $FSVN/stable/9 The next step is to create the release branch &prompt.root; svn cp $FSVN/stable/9@REVISION $FSVN/releng/9.2 This branch can be checked out: &prompt.root; svn co $FSVN/releng/9.2 src Creating the releng branch and release tags is done by the Release Engineering Team. &os; Development Branch &os; 3.x STABLE Branch &os; 4.x STABLE Branch &os; 5.x STABLE Branch &os; 6.x STABLE Branch &os; 7.x STABLE Branch &os; 8.x STABLE Branch &os; 9.x STABLE Branch Bumping up the Version Number Before the final release can be tagged, built, and released, the following files need to be modified to reflect the correct version of &os;: doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml doc/en_US.ISO8859-1/books/porters-handbook/book.xml doc/share/xml/freebsd.ent src/Makefile.inc1 src/UPDATING src/gnu/usr.bin/groff/tmac/mdoc.local src/release/Makefile src/release/doc/en_US.ISO8859-1/share/xml/release.dsl src/release/doc/share/examples/Makefile.relnotesng src/release/doc/share/xml/release.ent src/share/examples/cvsup/standard-supfile src/sys/conf/newvers.sh src/sys/sys/param.h src/usr.sbin/pkg_install/add/main.c www/en/docs/man.xml www/en/cgi/ports.cgi ports/Tools/scripts/release/config The release notes and errata files also need to be adjusted for the new release (on the release branch) and truncated appropriately (on the stable/current branch): src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml src/release/doc/en_US.ISO8859-1/errata/article.xml Sysinstall should be updated to note the number of available ports and the amount of disk space required for the Ports Collection. &os; Ports Collection This information is currently kept in src/usr.sbin/sysinstall/dist.c. After the release has been built, a number of file should be updated to announce the release to the world. doc/share/images/articles/releng/branches-relengX.pic www/share/xml/advisories.xml www/share/xml/includes.release.xml www/share/xml/includes.release.xsl www/en/releases/* www/en/releng/index.xml www/en/news/news.xml www/en/search/web.atoz src/share/misc/bsd-family-tree Creating the Release Tag When the final release is ready, the following command will create the release/9.2.0 tag. &prompt.root; svn cp $FSVN/releng/9.2 $FSVN/release/9.2.0 The Documentation and Ports managers are responsible for tagging their respective trees with the tags/RELEASE_9_2_0 tag. When the Subversion svn cp command is used to create a release tag, this identifies the source at a specific point in time. By creating tags, we ensure that future release builders will always be able to use the exact same source we used to create the official &os; Project releases. Release Building &os; releases can be built by anyone with a fast machine and access to a source repository. (That should be everyone, since we offer Subversion access ! See the Subversion section in the Handbook for details.) The only special requirement is that the &man.md.4; device must be available. If the device is not loaded into your kernel, then the kernel module should be automatically loaded when &man.mdconfig.8; is executed during the boot media creation phase. All of the tools necessary to build a release are available from the Subversion repository in src/release. These tools aim to provide a consistent way to build &os; releases. A complete release can actually be built with only a single command, including the creation of ISO images suitable for burning to CDROM or DVD, and an FTP install directory. &man.release.7; fully documents the src/release/generate-release.sh script which is used to build a release. generate-release.sh is a wrapper around the Makefile target: make release. Building a Release &man.release.7; documents the exact commands required to build a &os; release. The following sequences of commands can build an 9.2.0 release: &prompt.root; cd /usr/src/release &prompt.root; sh generate-release.sh release/9.2.0 /local3/release After running these commands, all prepared release files are available in /local3/release/R directory. The release Makefile can be broken down into several distinct steps. Creation of a sanitized system environment in a separate directory hierarchy with make installworld. Checkout from Subversion of a clean version of the system source, documentation, and ports into the release build hierarchy. Population of /etc and /dev in the chrooted environment. chroot into the release build hierarchy, to make it harder for the outside environment to taint this build. make world in the chrooted environment. Build of Kerberos-related binaries. Build GENERIC kernel. Creation of a staging directory tree where the binary distributions will be built and packaged. Build and installation of the documentation toolchain needed to convert the documentation source (SGML) into HTML and text documents that will accompany the release. Build and installation of the actual documentation (user manuals, tutorials, release notes, hardware compatibility lists, and so on.) Package up distribution tarballs of the binaries and sources. Create FTP installation hierarchy. (optionally) Create ISO images for CDROM/DVD media. For more information about the release build infrastructure, please see &man.release.7;. It is important to remove any site-specific settings from /etc/make.conf. For example, it would be unwise to distribute binaries that were built on a system with CPUTYPE set to a specific processor. Contributed Software (<quote>ports</quote>) The &os; Ports collection is a collection of over &os.numports; third-party software packages available for &os;. The &a.portmgr; is responsible for maintaining a consistent ports tree that can be used to create the binary packages that accompany official &os; releases. The release engineering activities for our collection of third-party packages is beyond the scope of this document. A separate article, &art.re.pkgs;, covers this topic in depth. Release ISOs Starting with &os; 4.4, the &os; Project decided to release all four ISO images that were previously sold on the BSDi/Wind River Systems/FreeBSD Mall official CDROM distributions. Each of the four discs must contain a README.TXT file that explains the contents of the disc, a CDROM.INF file that provides meta-data for the disc so that &man.sysinstall.8; can validate and use the contents, and a filename.txt file that provides a manifest for the disc. This manifest can be created with a simple command: /stage/cdrom&prompt.root; find . -type f | sed -e 's/^\.\///' | sort > filename.txt The specific requirements of each CD are outlined below. Disc 1 The first disc is almost completely created by make release. The only changes that should be made to the disc1 directory are the addition of a tools directory, and as many popular third party software packages as will fit on the disc. The tools directory contains software that allow users to create installation floppies from other operating systems. This disc should be made bootable so that users of modern PCs do not need to create installation floppy disks. If a custom kernel of &os; is to be included, then &man.sysinstall.8; and &man.release.7; must be updated to include installation instructions. The relevant code is contained in src/release and src/usr.sbin/sysinstall. Specifically, the file src/release/Makefile, and dist.c, dist.h, menus.c, install.c, and Makefile will need to be updated under src/usr.sbin/sysinstall. Optionally, you may choose to update sysinstall.8. Disc 2 The second disc is also largely created by make release. This disc contains a live filesystem that can be used from &man.sysinstall.8; to troubleshoot a &os; installation. This disc should be bootable and should also contain a compressed copy of the CVS repository in the CVSROOT directory and commercial software demos in the commerce directory. Discs 3 and 4 The remaining two discs contain additional software packages for &os;. The packages should be clustered so that a package and all of its dependencies are included on the same disc. More information about the creation of these discs is provided in the &art.re.pkgs; article. Multi-volume support Sysinstall supports multiple volume package installations. This requires that each disc have an INDEX file containing all of the packages on all volumes of a set, along with an extra field that indicates which volume that particular package is on. Each volume in the set must also have the CD_VOLUME variable set in the cdrom.inf file so that sysinstall can tell which volume is which. When a user attempts to install a package that is not on the current disc, sysinstall will prompt the user to insert the appropriate one. Distribution FTP Sites When the release has been thoroughly tested and packaged for distribution, the master FTP site must be updated. The official &os; public FTP sites are all mirrors of a master server that is open only to other FTP sites. This site is known as ftp-master. When the release is ready, the following files must be modified on ftp-master: /pub/FreeBSD/releases/arch/X.Y-RELEASE/ The installable FTP directory as output from make release. /pub/FreeBSD/ports/arch/packages-X.Y-release/ The complete package build for this release. /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools A symlink to ../../../tools. /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages A symlink to ../../../ports/arch/packages-X.Y-release. /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso The ISO images. The * is disc1, disc2, etc. Only if there is a disc1 and there is an alternative first installation CD (for example a stripped-down install with no windowing system) there may be a mini as well. For more information about the distribution mirror architecture of the &os; FTP sites, please see the Mirroring &os; article. It may take many hours to two days after updating ftp-master before a majority of the Tier-1 FTP sites have the new software depending on whether or not a package set got loaded at the same time. It is imperative that the release engineers coordinate with the &a.mirror-announce; before announcing the general availability of new software on the FTP sites. Ideally the release package set should be loaded at least four days prior to release day. The release bits should be loaded between 24 and 48 hours before the planned release time with other file permissions turned off. This will allow the mirror sites to download it but the general public will not be able to download it from the mirror sites. Mail should be sent to &a.mirror-announce; at the time the release bits get posted saying the release has been staged and giving the time that the mirror sites should begin allowing access. Be sure to include a time zone with the time, for example make it relative to GMT. CD-ROM Replication Coming soon: Tips for sending &os; ISOs to a replicator and quality assurance measures to be taken. Extensibility Although &os; forms a complete operating system, there is nothing that forces you to use the system exactly as we have packaged it up for distribution. We have tried to design the system to be as extensible as possible so that it can serve as a platform that other commercial products can be built on top of. The only rule we have about this is that if you are going to distribute &os; with non-trivial changes, we encourage you to document your enhancements! The &os; community can only help support users of the software we provide. We certainly encourage innovation in the form of advanced installation and administration tools, for example, but we cannot be expected to answer questions about it. Scripting <command>sysinstall</command> The &os; system installation and configuration tool, &man.sysinstall.8;, can be scripted to provide automated installs for large sites. This functionality can be used in conjunction with &intel; PXE to bootstrap systems from the network. Lessons Learned from &os; 4.4 The release engineering process for 4.4 formally began on August 1st, 2001. After that date all commits to the RELENG_4 branch of &os; had to be explicitly approved by the &a.re;. The first release candidate for the x86 architecture was released on August 16, followed by 4 more release candidates leading up to the final release on September 18th. The security officer was very involved in the last week of the process as several security issues were found in the earlier release candidates. A total of over 500 emails were sent to the &a.re; in little over a month. Our user community has made it very clear that the security and stability of a &os; release should not be sacrificed for any self-imposed deadlines or target release dates. The &os; Project has grown tremendously over its lifetime and the need for standardized release engineering procedures has never been more apparent. This will become even more important as &os; is ported to new platforms. Future Directions It is imperative for our release engineering activities to scale with our growing userbase. Along these lines we are working very hard to document the procedures involved in producing &os; releases. Parallelism - Certain portions of the release build are actually embarrassingly parallel. Most of the tasks are very I/O intensive, so having multiple high-speed disk drives is actually more important than using multiple processors in speeding up the make release process. If multiple disks are used for different hierarchies in the &man.chroot.2; environment, then the CVS checkout of the ports and doc trees can be happening simultaneously as the make world on another disk. Using a RAID solution (hardware or software) can significantly decrease the overall build time. Cross-building releases - Building IA-64 or Alpha release on x86 hardware? make TARGET=ia64 release. Regression Testing - We need better automated correctness testing for &os;. Installation Tools - Our installation program has long since outlived its intended life span. Several projects are under development to provide a more advanced installation mechanism. The libh project was one such project that aimed to provide an intelligent new package framework and GUI installation program. Acknowledgements I would like to thank Jordan Hubbard for giving me the opportunity to take on some of the release engineering responsibilities for &os; 4.4 and also for all of his work throughout the years making &os; what it is today. Of course the release would not have been possible without all of the - release-related work done by &a.asami;, &a.steve;, &a.bmah;, &a.nik;, - &a.obrien;, &a.kris;, &a.jhb; and the rest of the &os; development - community. I would also like to thank &a.rgrimes;, &a.phk;, and others + release-related work done by &a.asami.email;, &a.steve.email;, &a.bmah.email;, &a.nik.email;, + &a.obrien.email;, &a.kris.email;, &a.jhb.email; and the rest of the &os; development + community. I would also like to thank &a.rgrimes.email;, &a.phk.email;, and others who worked on the release engineering tools in the very early days of &os;. This article was influenced by release engineering documents from the CSRG Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD , the NetBSD Project , NetBSD Developer Documentation: Release Engineering , and John Baldwin's proposed release engineering process notes. John Baldwin's &os; Release Engineering Proposal

diff --git a/en_US.ISO8859-1/articles/remote-install/article.xml b/en_US.ISO8859-1/articles/remote-install/article.xml index 8907656c4a..8c520bfa30 100644 --- a/en_US.ISO8859-1/articles/remote-install/article.xml +++ b/en_US.ISO8859-1/articles/remote-install/article.xml @@ -1,563 +1,563 @@

Remote Installation of the &os; Operating System without a Remote Console Daniel Gerzo

danger@FreeBSD.org

&tm-attrib.freebsd; &tm-attrib.general; 2008 The &os; Documentation Project $FreeBSD$ $FreeBSD$ This article documents the remote installation of the &os; operating system when the console of the remote system is unavailable. The main idea behind this article is the result of - a collaboration with &a.mm; with valuable input provided by - &a.pjd;. + a collaboration with &a.mm.email; with valuable input provided by + &a.pjd.email;. Background There are many server hosting providers in the world, but very few of them are officially supporting &os;. They usually provide support for a &linux; distribution to be installed on the servers they offer. In some cases, these companies will install your preferred &linux; distribution if you request it. Using this option, we will attempt to install &os;. In other cases, they may offer a rescue system which would be used in an emergency. It's possible to use this for our purposes as well. This article covers the basic installation and configuration steps required to bootstrap a remote installation of &os; with RAID-1 and ZFS capabilities. Introduction This section will summarize the purpose of this article and better explain what is covered herein. The instructions included in this article will benefit those using services provided by colocation facilities not supporting &os;. As we have mentioned in the Background section, many of the reputable server hosting companies provide some kind of rescue system, which is booted from their LAN and accessible over SSH. They usually provide this support in order to help their customers fix broken operating systems. As this article will explain, it is possible to install &os; with the help of these rescue systems. The next section of this article will describe how to configure, and build minimalistic &os; on the local machine. That version will eventually be running on the remote machine from a ramdisk, which will allow us to install a complete &os; operating system from an FTP mirror using the sysinstall utility. The rest of this article will describe the installation procedure itself, as well as the configuration of the ZFS file system. Requirements To continue successfully, you must: Have a network accessible operating system with SSH access Understand the &os; installation process Be familiar with the &man.sysinstall.8; utility Have the &os; installation ISO image or CD handy Preparation - <application>mfsBSD</application> Before &os; may be installed on the target system, it is necessary to build the minimal &os; operating system image which will boot from the hard drive. This way the new system can be accessed from the network, and the rest of the installation can be done without remote access to the system console. The mfsBSD tool-set can be used to build a tiny &os; image. As the name of mfsBSD suggests (mfs means memory file system), the resulting image runs entirely from a ramdisk. Thanks to this feature, the manipulation of hard drives will not be limited, therefore it will be possible to install a complete &os; operating system. The home page of mfsBSD, at , includes pointers to the latest release of the toolset. Please note that the internals of mfsBSD and how it all fits together is beyond the scope of this article. The interested reader should consult the original documentation of mfsBSD for more details. Download and extract the latest mfsBSD release and change your working directory to the directory where the mfsBSD scripts will reside: &prompt.root; fetch http://people.freebsd.org/~mm/mfsbsd/mfsbsd-latest.tar.gz &prompt.root; tar xvzf mfsbsd-1.0-beta1.tar.gz &prompt.root; cd mfsbsd-1.0-beta1/ Configuration of <application>mfsBSD</application> Before booting mfsBSD, a few important configuration options have to be set. The most important that we have to get right is, naturally, the network setup. The most suitable method to configure networking options depends on whether we know beforehand the type of the network interface we will use, and the network interface driver to be loaded for our hardware. We will see how mfsBSD can be configured in either case. Another important thing to set is the root password. This can be done by editing the conf/rootpw.conf file. Please keep in mind that the file will contain your password in the plain text, thus we do not recommend to use real password here. Nevertheless, this is just a temporary one-time password which can be later changed in a live system. The <filename>conf/interfaces.conf</filename> method When the installed network interface card is unknown, we can use the auto-detection features of mfsBSD. The startup scripts of mfsBSD can detect the correct driver to use, based on the MAC address of the interface, if we set the following options in conf/interfaces.conf: initconf_interfaces="ext1" initconf_mac_ext1="00:00:00:00:00:00" initconf_ip_ext1="192.168.0.2" initconf_netmask_ext1="255.255.255.0" Do not forget to add the defaultrouter information to the conf/rc.conf file: defaultrouter="192.168.0.1" The <filename>conf/rc.conf</filename> method When the network interface driver is known, it is more convenient to use the conf/rc.conf file for networking options. The syntax of this file is the same as the one used in the standard &man.rc.conf.5; file of &os;. For example, if you know that a &man.re.4; network interface is going to be available, you can set the following options in conf/rc.conf: defaultrouter="192.168.0.1" ifconfig_re0="inet 192.168.0.2 netmask 255.255.255.0" Building an <application>mfsBSD</application> image The process of building an mfsBSD image is pretty straightforward. The first step is to mount the &os; installation CD, or the installation ISO image to /cdrom. For the sake of example, in this article we will assume that you have downloaded the &os; 7.0-RELEASE ISO. Mounting this ISO image to the /cdrom directory is easy with the &man.mdconfig.8; utility: &prompt.root; mdconfig -a -t vnode -u 10 -f 7.0-RELEASE-amd64-disc1.iso &prompt.root; mount_cd9660 /dev/md10 /cdrom Next, build the bootable mfsBSD image: &prompt.root; make BASE=/cdrom/7.0-RELEASE The above make command has to be run from the top level of the mfsBSD directory tree, i.e. ~/mfsbsd-1.0-beta1/. Booting <application>mfsBSD</application> Now that the mfsBSD image is ready, it must be uploaded to the remote system running a live rescue system or pre-installed &linux; distribution. The most suitable tool for this task is scp: &prompt.root; scp disk.img root@192.168.0.2:. To boot mfsBSD image properly, it must be placed on the first (bootable) device of the given machine. This may be accomplished using this example providing that sda is the first bootable disk device: &prompt.root; dd if=/root/disk.img of=/dev/sda bs=1m If all went well, the image should now be in the MBR of the first device and the machine can be rebooted. Watch for the machine to boot up properly with the &man.ping.8; tool. Once it has came back on-line, it should be possible to access it over &man.ssh.1; as user root with the configured password. Installation of The &os; Operating System The mfsBSD has been successfully booted and it should be possible to log in through &man.ssh.1;. This section will describe how to create and label slices, set up gmirror for RAID-1, and how to use sysinstall to install a minimal distribution of the &os; operating system. Preparation of Hard Drives The first task is to allocate disk space for &os;, i.e.: to create slices and partitions. Obviously, the currently running system is fully loaded in system memory and therefore there will be no problems with manipulating hard drives. To complete this task, it is possible to use either sysinstall or &man.fdisk.8; in conjunction to &man.bsdlabel.8;. At the start, mark all system disks as empty. Repeat the following command for each hard drive: &prompt.root; dd if=/dev/zero of=/dev/ad0 count=2 Next, create slices and label them with your preferred tool. While it is considered easier to use sysinstall, a powerful and also probably less buggy method will be to use standard text-based &unix; tools, such as &man.fdisk.8; and &man.bsdlabel.8;, which will also be covered in this section. The former option is well documented in the Installing &os; chapter of the &os; Handbook. As it was mentioned in the introduction, this article will present how to set up a system with RAID-1 and ZFS capabilities. Our set up will consist of a small &man.gmirror.8; mirrored / (root), /usr and /var file systems, and the rest of the disk space will be allocated for a &man.zpool.8; mirrored ZFS file system. Please note, that the ZFS file system will be configured after the &os; operating system is successfully installed and booted. The following example will describe how to create slices and labels, initialize &man.gmirror.8; on each partition and how to create a UFS2 file system in each mirrored partition: &prompt.root; fdisk -BI /dev/ad0 &prompt.root; fdisk -BI /dev/ad1 &prompt.root; bsdlabel -wB /dev/ad0s1 &prompt.root; bsdlabel -wB /dev/ad1s1 &prompt.root; bsdlabel -e /dev/ad0s1 &prompt.root; bsdlabel /dev/ad0s1 > /tmp/bsdlabel.txt && bsdlabel -R /dev/ad1s1 /tmp/bsdlabel.txt &prompt.root; gmirror label root /dev/ad[01]s1a &prompt.root; gmirror label var /dev/ad[01]s1d &prompt.root; gmirror label usr /dev/ad[01]s1e &prompt.root; gmirror label -F swap /dev/ad[01]s1b &prompt.root; newfs /dev/mirror/root &prompt.root; newfs /dev/mirror/var &prompt.root; newfs /dev/mirror/usr Create a slice covering the entire disk and initialize the boot code contained in sector 0 of the given disk. Repeat this command for all hard drives in the system. Write a standard label for each disk including the bootstrap code. Now, manually edit the label of the given disk. Refer to the &man.bsdlabel.8; manual page in order to find out how to create partitions. Create partitions a for / (root) file system, b for swap, d for /var, e for /usr and finally f which will later be used for ZFS. Import the recently created label for the second hard drive, so both hard drives will be labeled in the same way. Initialize &man.gmirror.8; on each partition. Note the option used for swap partition. This instructs &man.gmirror.8; to assume that the device is in the consistent state after the power/system failure. Create a UFS2 file system on each mirrored partition. System Installation This is the most important part. This section will describe how to actually install the minimal distribution of &os; on the hard drives that we have prepared in the previous section. To accomplish this goal, all file systems need to be mounted so sysinstall may write the contents of &os; to the hard drives: &prompt.root; mount /dev/mirror/root /mnt &prompt.root; mkdir /mnt/var /mnt/usr &prompt.root; mount /dev/mirror/var /mnt/var &prompt.root; mount /dev/mirror/usr /mnt/usr When you are done, start &man.sysinstall.8;. Select the Custom installation from the main menu. Select Options and press Enter. With the help of arrow keys, move the cursor on the Install Root item, press Space and change it to /mnt. Press Enter to submit your changes and exit the Options menu by pressing q. Note that this step is very important and if skipped, sysinstall will be unable to install &os;. Go to the Distributions menu, move the cursor with the arrow keys on the option, and check it by pressing Space. This article uses the Minimal distribution in order to save network traffic, because the system itself will be installed over ftp. Exit this menu by choosing option. The Partition and Label menus will be skipped, as these are useless now. In the Media menu, select . Select the nearest mirror and let sysinstall assume that the network is already configured. You will be returned back to the Custom menu. Finally, perform the system installation by selecting the last option, Commit. Exit sysinstall when it finishes the installation. Post Installation Steps The &os; operating system should be installed now; however, the process is not finished yet. It is necessary to perform some post installation steps in order to allow &os; to boot in the future and to be able to log in to the system. You must now &man.chroot.8; into the freshly installed system in order to finish the installation. Use the following command: &prompt.root; chroot /mnt To complete our goal, perform these steps: Copy the GENERIC kernel to the /boot/kernel directory: &prompt.root; cp -Rp /boot/GENERIC/* /boot/kernel Create the /etc/rc.conf, /etc/resolv.conf and /etc/fstab files. Do not forget to properly set the network information and to enable sshd in the /etc/rc.conf file. The contents of the /etc/fstab file will be similar to the following: # Device Mountpoint FStype Options Dump Pass# /dev/mirror/swap none swap sw 0 0 /dev/mirror/root / ufs rw 1 1 /dev/mirror/usr /usr ufs rw 2 2 /dev/mirror/var /var ufs rw 2 2 /dev/cd0 /cdrom cd9660 ro,noauto 0 0 Create the /boot/loader.conf file, with the following contents: geom_mirror_load="YES" zfs_load="YES" Perform the following command, which will make ZFS available on the next boot: &prompt.root; echo 'zfs_enable="YES"' >> /etc/rc.conf Add additional users to the system using the &man.adduser.8; tool. Do not forget to add a user to the wheel group so you may obtain root access after the reboot. Double-check all your settings. The system should now be ready for the next boot. Use the &man.reboot.8; command to reboot your system. ZFS If your system survived the reboot, it should now be possible to log in. Welcome to the fresh &os; installation, performed remotely without the use of a remote console! The only remaining step is to configure &man.zpool.8; and create some &man.zfs.8; file systems. Creating and administering ZFS is very straightforward. First, create a mirrored pool: &prompt.root; zpool create tank mirror /dev/ad[01]s1f Next, create some file systems: &prompt.root; zfs create tank/ports &prompt.root; zfs create tank/src &prompt.root; zfs set compression=gzip tank/ports &prompt.root; zfs set compression=on tank/src &prompt.root; zfs set mountpoint=/usr/ports tank/ports &prompt.root; zfs set mountpoint=/usr/src tank/src That's all. If you are interested in more details about ZFS on &os;, please refer to the ZFS section of the &os; Wiki.

diff --git a/en_US.ISO8859-1/articles/serial-uart/article.xml b/en_US.ISO8859-1/articles/serial-uart/article.xml index 74ed08d7aa..81686f5758 100644 --- a/en_US.ISO8859-1/articles/serial-uart/article.xml +++ b/en_US.ISO8859-1/articles/serial-uart/article.xml @@ -1,2440 +1,2440 @@

Serial and UART Tutorial Frank Durda

uhclem@FreeBSD.org

&tm-attrib.freebsd; &tm-attrib.microsoft; &tm-attrib.general; $FreeBSD$ $FreeBSD$ This article talks about using serial hardware with FreeBSD. The UART: What it is and how it works - Copyright © 1996 &a.uhclem;, All Rights + Copyright © 1996 &a.uhclem.email;, All Rights Reserved. 13 January 1996. The Universal Asynchronous Receiver/Transmitter (UART) controller is the key component of the serial communications subsystem of a computer. The UART takes bytes of data and transmits the individual bits in a sequential fashion. At the destination, a second UART re-assembles the bits into complete bytes. Serial transmission is commonly used with modems and for non-networked communication between computers, terminals and other devices. There are two primary forms of serial transmission: Synchronous and Asynchronous. Depending on the modes that are supported by the hardware, the name of the communication sub-system will usually include a A if it supports Asynchronous communications, and a S if it supports Synchronous communications. Both forms are described below. Some common acronyms are:

UART Universal Asynchronous Receiver/Transmitter

USART Universal Synchronous-Asynchronous Receiver/Transmitter

Synchronous Serial Transmission Synchronous serial transmission requires that the sender and receiver share a clock with one another, or that the sender provide a strobe or other timing signal so that the receiver knows when to read the next bit of the data. In most forms of serial Synchronous communication, if there is no data available at a given instant to transmit, a fill character must be sent instead so that data is always being transmitted. Synchronous communication is usually more efficient because only data bits are transmitted between sender and receiver, and synchronous communication can be more costly if extra wiring and circuits are required to share a clock signal between the sender and receiver. A form of Synchronous transmission is used with printers and fixed disk devices in that the data is sent on one set of wires while a clock or strobe is sent on a different wire. Printers and fixed disk devices are not normally serial devices because most fixed disk interface standards send an entire word of data for each clock or strobe signal by using a separate wire for each bit of the word. In the PC industry, these are known as Parallel devices. The standard serial communications hardware in the PC does not support Synchronous operations. This mode is described here for comparison purposes only. Asynchronous Serial Transmission Asynchronous transmission allows data to be transmitted without the sender having to send a clock signal to the receiver. Instead, the sender and receiver must agree on timing parameters in advance and special bits are added to each word which are used to synchronize the sending and receiving units. When a word is given to the UART for Asynchronous transmissions, a bit called the "Start Bit" is added to the beginning of each word that is to be transmitted. The Start Bit is used to alert the receiver that a word of data is about to be sent, and to force the clock in the receiver into synchronization with the clock in the transmitter. These two clocks must be accurate enough to not have the frequency drift by more than 10% during the transmission of the remaining bits in the word. (This requirement was set in the days of mechanical teleprinters and is easily met by modern electronic equipment.) After the Start Bit, the individual bits of the word of data are sent, with the Least Significant Bit (LSB) being sent first. Each bit in the transmission is transmitted for exactly the same amount of time as all of the other bits, and the receiver looks at the wire at approximately halfway through the period assigned to each bit to determine if the bit is a 1 or a 0. For example, if it takes two seconds to send each bit, the receiver will examine the signal to determine if it is a 1 or a 0 after one second has passed, then it will wait two seconds and then examine the value of the next bit, and so on. The sender does not know when the receiver has looked at the value of the bit. The sender only knows when the clock says to begin transmitting the next bit of the word. When the entire data word has been sent, the transmitter may add a Parity Bit that the transmitter generates. The Parity Bit may be used by the receiver to perform simple error checking. Then at least one Stop Bit is sent by the transmitter. When the receiver has received all of the bits in the data word, it may check for the Parity Bits (both sender and receiver must agree on whether a Parity Bit is to be used), and then the receiver looks for a Stop Bit. If the Stop Bit does not appear when it is supposed to, the UART considers the entire word to be garbled and will report a Framing Error to the host processor when the data word is read. The usual cause of a Framing Error is that the sender and receiver clocks were not running at the same speed, or that the signal was interrupted. Regardless of whether the data was received correctly or not, the UART automatically discards the Start, Parity and Stop bits. If the sender and receiver are configured identically, these bits are not passed to the host. If another word is ready for transmission, the Start Bit for the new word can be sent as soon as the Stop Bit for the previous word has been sent. Because asynchronous data is self synchronizing, if there is no data to transmit, the transmission line can be idle. Other UART Functions In addition to the basic job of converting data from parallel to serial for transmission and from serial to parallel on reception, a UART will usually provide additional circuits for signals that can be used to indicate the state of the transmission media, and to regulate the flow of data in the event that the remote device is not prepared to accept more data. For example, when the device connected to the UART is a modem, the modem may report the presence of a carrier on the phone line while the computer may be able to instruct the modem to reset itself or to not take calls by raising or lowering one more of these extra signals. The function of each of these additional signals is defined in the EIA RS232-C standard. The RS232-C and V.24 Standards In most computer systems, the UART is connected to circuitry that generates signals that comply with the EIA RS232-C specification. There is also a CCITT standard named V.24 that mirrors the specifications included in RS232-C. RS232-C Bit Assignments (Marks and Spaces) In RS232-C, a value of 1 is called a Mark and a value of 0 is called a Space. When a communication line is idle, the line is said to be Marking, or transmitting continuous 1 values. The Start bit always has a value of 0 (a Space). The Stop Bit always has a value of 1 (a Mark). This means that there will always be a Mark (1) to Space (0) transition on the line at the start of every word, even when multiple word are transmitted back to back. This guarantees that sender and receiver can resynchronize their clocks regardless of the content of the data bits that are being transmitted. The idle time between Stop and Start bits does not have to be an exact multiple (including zero) of the bit rate of the communication link, but most UARTs are designed this way for simplicity. In RS232-C, the "Marking" signal (a 1) is represented by a voltage between -2 VDC and -12 VDC, and a "Spacing" signal (a 0) is represented by a voltage between 0 and +12 VDC. The transmitter is supposed to send +12 VDC or -12 VDC, and the receiver is supposed to allow for some voltage loss in long cables. Some transmitters in low power devices (like portable computers) sometimes use only +5 VDC and -5 VDC, but these values are still acceptable to a RS232-C receiver, provided that the cable lengths are short. RS232-C Break Signal RS232-C also specifies a signal called a Break, which is caused by sending continuous Spacing values (no Start or Stop bits). When there is no electricity present on the data circuit, the line is considered to be sending Break. The Break signal must be of a duration longer than the time it takes to send a complete byte plus Start, Stop and Parity bits. Most UARTs can distinguish between a Framing Error and a Break, but if the UART cannot do this, the Framing Error detection can be used to identify Breaks. In the days of teleprinters, when numerous printers around the country were wired in series (such as news services), any unit could cause a Break by temporarily opening the entire circuit so that no current flowed. This was used to allow a location with urgent news to interrupt some other location that was currently sending information. In modern systems there are two types of Break signals. If the Break is longer than 1.6 seconds, it is considered a "Modem Break", and some modems can be programmed to terminate the conversation and go on-hook or enter the modems' command mode when the modem detects this signal. If the Break is smaller than 1.6 seconds, it signifies a Data Break and it is up to the remote computer to respond to this signal. Sometimes this form of Break is used as an Attention or Interrupt signal and sometimes is accepted as a substitute for the ASCII CONTROL-C character. Marks and Spaces are also equivalent to Holes and No Holes in paper tape systems. Breaks cannot be generated from paper tape or from any other byte value, since bytes are always sent with Start and Stop bit. The UART is usually capable of generating the continuous Spacing signal in response to a special command from the host processor. RS232-C DTE and DCE Devices The RS232-C specification defines two types of equipment: the Data Terminal Equipment (DTE) and the Data Carrier Equipment (DCE). Usually, the DTE device is the terminal (or computer), and the DCE is a modem. Across the phone line at the other end of a conversation, the receiving modem is also a DCE device and the computer that is connected to that modem is a DTE device. The DCE device receives signals on the pins that the DTE device transmits on, and vice versa. When two devices that are both DTE or both DCE must be connected together without a modem or a similar media translator between them, a NULL modem must be used. The NULL modem electrically re-arranges the cabling so that the transmitter output is connected to the receiver input on the other device, and vice versa. Similar translations are performed on all of the control signals so that each device will see what it thinks are DCE (or DTE) signals from the other device. The number of signals generated by the DTE and DCE devices are not symmetrical. The DTE device generates fewer signals for the DCE device than the DTE device receives from the DCE. RS232-C Pin Assignments The EIA RS232-C specification (and the ITU equivalent, V.24) calls for a twenty-five pin connector (usually a DB25) and defines the purpose of most of the pins in that connector. In the IBM Personal Computer and similar systems, a subset of RS232-C signals are provided via nine pin connectors (DB9). The signals that are not included on the PC connector deal mainly with synchronous operation, and this transmission mode is not supported by the UART that IBM selected for use in the IBM PC. Depending on the computer manufacturer, a DB25, a DB9, or both types of connector may be used for RS232-C communications. (The IBM PC also uses a DB25 connector for the parallel printer interface which causes some confusion.) Below is a table of the RS232-C signal assignments in the DB25 and DB9 connectors. DB25 RS232-C Pin DB9 IBM PC Pin EIA Circuit Symbol CCITT Circuit Symbol Common Name Signal Source Description 1 - AA 101 PG/FG - Frame/Protective Ground 2 3 BA 103 TD DTE Transmit Data 3 2 BB 104 RD DCE Receive Data 4 7 CA 105 RTS DTE Request to Send 5 8 CB 106 CTS DCE Clear to Send 6 6 CC 107 DSR DCE Data Set Ready 7 5 AV 102 SG/GND - Signal Ground 8 1 CF 109 DCD/CD DCE Data Carrier Detect 9 - - - - - Reserved for Test 10 - - - - - Reserved for Test 11 - - - - - Reserved for Test 12 - CI 122 SRLSD DCE Sec. Recv. Line Signal Detector 13 - SCB 121 SCTS DCE Secondary Clear to Send 14 - SBA 118 STD DTE Secondary Transmit Data 15 - DB 114 TSET DCE Trans. Sig. Element Timing 16 - SBB 119 SRD DCE Secondary Received Data 17 - DD 115 RSET DCE Receiver Signal Element Timing 18 - - 141 LOOP DTE Local Loopback 19 - SCA 120 SRS DTE Secondary Request to Send 20 4 CD 108.2 DTR DTE Data Terminal Ready 21 - - - RDL DTE Remote Digital Loopback 22 9 CE 125 RI DCE Ring Indicator 23 - CH 111 DSRS DTE Data Signal Rate Selector 24 - DA 113 TSET DTE Trans. Sig. Element Timing 25 - - 142 - DCE Test Mode Bits, Baud and Symbols Baud is a measurement of transmission speed in asynchronous communication. Because of advances in modem communication technology, this term is frequently misused when describing the data rates in newer devices. Traditionally, a Baud Rate represents the number of bits that are actually being sent over the media, not the amount of data that is actually moved from one DTE device to the other. The Baud count includes the overhead bits Start, Stop and Parity that are generated by the sending UART and removed by the receiving UART. This means that seven-bit words of data actually take 10 bits to be completely transmitted. Therefore, a modem capable of moving 300 bits per second from one place to another can normally only move 30 7-bit words if Parity is used and one Start and Stop bit are present. If 8-bit data words are used and Parity bits are also used, the data rate falls to 27.27 words per second, because it now takes 11 bits to send the eight-bit words, and the modem still only sends 300 bits per second. The formula for converting bytes per second into a baud rate and vice versa was simple until error-correcting modems came along. These modems receive the serial stream of bits from the UART in the host computer (even when internal modems are used the data is still frequently serialized) and converts the bits back into bytes. These bytes are then combined into packets and sent over the phone line using a Synchronous transmission method. This means that the Stop, Start, and Parity bits added by the UART in the DTE (the computer) were removed by the modem before transmission by the sending modem. When these bytes are received by the remote modem, the remote modem adds Start, Stop and Parity bits to the words, converts them to a serial format and then sends them to the receiving UART in the remote computer, who then strips the Start, Stop and Parity bits. The reason all these extra conversions are done is so that the two modems can perform error correction, which means that the receiving modem is able to ask the sending modem to resend a block of data that was not received with the correct checksum. This checking is handled by the modems, and the DTE devices are usually unaware that the process is occurring. By striping the Start, Stop and Parity bits, the additional bits of data that the two modems must share between themselves to perform error-correction are mostly concealed from the effective transmission rate seen by the sending and receiving DTE equipment. For example, if a modem sends ten 7-bit words to another modem without including the Start, Stop and Parity bits, the sending modem will be able to add 30 bits of its own information that the receiving modem can use to do error-correction without impacting the transmission speed of the real data. The use of the term Baud is further confused by modems that perform compression. A single 8-bit word passed over the telephone line might represent a dozen words that were transmitted to the sending modem. The receiving modem will expand the data back to its original content and pass that data to the receiving DTE. Modern modems also include buffers that allow the rate that bits move across the phone line (DCE to DCE) to be a different speed than the speed that the bits move between the DTE and DCE on both ends of the conversation. Normally the speed between the DTE and DCE is higher than the DCE to DCE speed because of the use of compression by the modems. Because the number of bits needed to describe a byte varied during the trip between the two machines plus the differing bits-per-seconds speeds that are used present on the DTE-DCE and DCE-DCE links, the usage of the term Baud to describe the overall communication speed causes problems and can misrepresent the true transmission speed. So Bits Per Second (bps) is the correct term to use to describe the transmission rate seen at the DCE to DCE interface and Baud or Bits Per Second are acceptable terms to use when a connection is made between two systems with a wired connection, or if a modem is in use that is not performing error-correction or compression. Modern high speed modems (2400, 9600, 14,400, and 19,200bps) in reality still operate at or below 2400 baud, or more accurately, 2400 Symbols per second. High speed modem are able to encode more bits of data into each Symbol using a technique called Constellation Stuffing, which is why the effective bits per second rate of the modem is higher, but the modem continues to operate within the limited audio bandwidth that the telephone system provides. Modems operating at 28,800 and higher speeds have variable Symbol rates, but the technique is the same. The IBM Personal Computer UART Starting with the original IBM Personal Computer, IBM selected the National Semiconductor INS8250 UART for use in the IBM PC Parallel/Serial Adapter. Subsequent generations of compatible computers from IBM and other vendors continued to use the INS8250 or improved versions of the National Semiconductor UART family. National Semiconductor UART Family Tree There have been several versions and subsequent generations of the INS8250 UART. Each major version is described below. INS8250 -> INS8250B \ \ \-> INS8250A -> INS82C50A \ \ \-> NS16450 -> NS16C450 \ \ \-> NS16550 -> NS16550A -> PC16550D INS8250 This part was used in the original IBM PC and IBM PC/XT. The original name for this part was the INS8250 ACE (Asynchronous Communications Element) and it is made from NMOS technology. The 8250 uses eight I/O ports and has a one-byte send and a one-byte receive buffer. This original UART has several race conditions and other flaws. The original IBM BIOS includes code to work around these flaws, but this made the BIOS dependent on the flaws being present, so subsequent parts like the 8250A, 16450 or 16550 could not be used in the original IBM PC or IBM PC/XT. INS8250-B This is the slower speed of the INS8250 made from NMOS technology. It contains the same problems as the original INS8250. INS8250A An improved version of the INS8250 using XMOS technology with various functional flaws corrected. The INS8250A was used initially in PC clone computers by vendors who used clean BIOS designs. Because of the corrections in the chip, this part could not be used with a BIOS compatible with the INS8250 or INS8250B. INS82C50A This is a CMOS version (low power consumption) of the INS8250A and has similar functional characteristics. NS16450 Same as NS8250A with improvements so it can be used with faster CPU bus designs. IBM used this part in the IBM AT and updated the IBM BIOS to no longer rely on the bugs in the INS8250. NS16C450 This is a CMOS version (low power consumption) of the NS16450. NS16550 Same as NS16450 with a 16-byte send and receive buffer but the buffer design was flawed and could not be reliably be used. NS16550A Same as NS16550 with the buffer flaws corrected. The 16550A and its successors have become the most popular UART design in the PC industry, mainly due to its ability to reliably handle higher data rates on operating systems with sluggish interrupt response times. NS16C552 This component consists of two NS16C550A CMOS UARTs in a single package. PC16550D Same as NS16550A with subtle flaws corrected. This is revision D of the 16550 family and is the latest design available from National Semiconductor. The NS16550AF and the PC16550D are the same thing National reorganized their part numbering system a few years ago, and the NS16550AFN no longer exists by that name. (If you have a NS16550AFN, look at the date code on the part, which is a four digit number that usually starts with a nine. The first two digits of the number are the year, and the last two digits are the week in that year when the part was packaged. If you have a NS16550AFN, it is probably a few years old.) The new numbers are like PC16550DV, with minor differences in the suffix letters depending on the package material and its shape. (A description of the numbering system can be found below.) It is important to understand that in some stores, you may pay $15(US) for a NS16550AFN made in 1990 and in the next bin are the new PC16550DN parts with minor fixes that National has made since the AFN part was in production, the PC16550DN was probably made in the past six months and it costs half (as low as $5(US) in volume) as much as the NS16550AFN because they are readily available. As the supply of NS16550AFN chips continues to shrink, the price will probably continue to increase until more people discover and accept that the PC16550DN really has the same function as the old part number. National Semiconductor Part Numbering System The older NSnnnnnrqp part numbers are now of the format PCnnnnnrgp. The r is the revision field. The current revision of the 16550 from National Semiconductor is D. The p is the package-type field. The types are: "F" QFP (quad flat pack) L lead type "N" DIP (dual inline package) through hole straight lead type "V" LPCC (lead plastic chip carrier) J lead type The g is the product grade field. If an I precedes the package-type letter, it indicates an industrial grade part, which has higher specs than a standard part but not as high as Military Specification (Milspec) component. This is an optional field. So what we used to call a NS16550AFN (DIP Package) is now called a PC16550DN or PC16550DIN. Other Vendors and Similar UARTs Over the years, the 8250, 8250A, 16450 and 16550 have been licensed or copied by other chip vendors. In the case of the 8250, 8250A and 16450, the exact circuit (the megacell) was licensed to many vendors, including Western Digital and Intel. Other vendors reverse-engineered the part or produced emulations that had similar behavior. In internal modems, the modem designer will frequently emulate the 8250A/16450 with the modem microprocessor, and the emulated UART will frequently have a hidden buffer consisting of several hundred bytes. Because of the size of the buffer, these emulations can be as reliable as a 16550A in their ability to handle high speed data. However, most operating systems will still report that the UART is only a 8250A or 16450, and may not make effective use of the extra buffering present in the emulated UART unless special drivers are used. Some modem makers are driven by market forces to abandon a design that has hundreds of bytes of buffer and instead use a 16550A UART so that the product will compare favorably in market comparisons even though the effective performance may be lowered by this action. A common misconception is that all parts with 16550A written on them are identical in performance. There are differences, and in some cases, outright flaws in most of these 16550A clones. When the NS16550 was developed, the National Semiconductor obtained several patents on the design and they also limited licensing, making it harder for other vendors to provide a chip with similar features. Because of the patents, reverse-engineered designs and emulations had to avoid infringing the claims covered by the patents. Subsequently, these copies almost never perform exactly the same as the NS16550A or PC16550D, which are the parts most computer and modem makers want to buy but are sometimes unwilling to pay the price required to get the genuine part. Some of the differences in the clone 16550A parts are unimportant, while others can prevent the device from being used at all with a given operating system or driver. These differences may show up when using other drivers, or when particular combinations of events occur that were not well tested or considered in the &windows; driver. This is because most modem vendors and 16550-clone makers use the Microsoft drivers from &windows; for Workgroups 3.11 and the µsoft; &ms-dos; utility as the primary tests for compatibility with the NS16550A. This over-simplistic criteria means that if a different operating system is used, problems could appear due to subtle differences between the clones and genuine components. National Semiconductor has made available a program named COMTEST that performs compatibility tests independent of any OS drivers. It should be remembered that the purpose of this type of program is to demonstrate the flaws in the products of the competition, so the program will report major as well as extremely subtle differences in behavior in the part being tested. In a series of tests performed by the author of this document in 1994, components made by National Semiconductor, TI, StarTech, and CMD as well as megacells and emulations embedded in internal modems were tested with COMTEST. A difference count for some of these components is listed below. Because these tests were performed in 1994, they may not reflect the current performance of the given product from a vendor. It should be noted that COMTEST normally aborts when an excessive number or certain types of problems have been detected. As part of this testing, COMTEST was modified so that it would not abort no matter how many differences were encountered. Vendor Part Number Errors (aka "differences" reported) National (PC16550DV) 0 National (NS16550AFN) 0 National (NS16C552V) 0 TI (TL16550AFN) 3 CMD (16C550PE) 19 StarTech (ST16C550J) 23 Rockwell Reference modem with internal 16550 or an emulation (RC144DPi/C3000-25) 117 Sierra Modem with an internal 16550 (SC11951/SC11351) 91 To date, the author of this document has not found any non-National parts that report zero differences using the COMTEST program. It should also be noted that National has had five versions of the 16550 over the years and the newest parts behave a bit differently than the classic NS16550AFN that is considered the benchmark for functionality. COMTEST appears to turn a blind eye to the differences within the National product line and reports no errors on the National parts (except for the original 16550) even when there are official erratas that describe bugs in the A, B and C revisions of the parts, so this bias in COMTEST must be taken into account. It is important to understand that a simple count of differences from COMTEST does not reveal a lot about what differences are important and which are not. For example, about half of the differences reported in the two modems listed above that have internal UARTs were caused by the clone UARTs not supporting five- and six-bit character modes. The real 16550, 16450, and 8250 UARTs all support these modes and COMTEST checks the functionality of these modes so over fifty differences are reported. However, almost no modern modem supports five- or six-bit characters, particularly those with error-correction and compression capabilities. This means that the differences related to five- and six-bit character modes can be discounted. Many of the differences COMTEST reports have to do with timing. In many of the clone designs, when the host reads from one port, the status bits in some other port may not update in the same amount of time (some faster, some slower) as a real NS16550AFN and COMTEST looks for these differences. This means that the number of differences can be misleading in that one device may only have one or two differences but they are extremely serious, and some other device that updates the status registers faster or slower than the reference part (that would probably never affect the operation of a properly written driver) could have dozens of differences reported. COMTEST can be used as a screening tool to alert the administrator to the presence of potentially incompatible components that might cause problems or have to be handled as a special case. If you run COMTEST on a 16550 that is in a modem or a modem is attached to the serial port, you need to first issue a ATE0&W command to the modem so that the modem will not echo any of the test characters. If you forget to do this, COMTEST will report at least this one difference: Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61 8250/16450/16550 Registers The 8250/16450/16550 UART occupies eight contiguous I/O port addresses. In the IBM PC, there are two defined locations for these eight ports and they are known collectively as COM1 and COM2. The makers of PC-clones and add-on cards have created two additional areas known as COM3 and COM4, but these extra COM ports conflict with other hardware on some systems. The most common conflict is with video adapters that provide IBM 8514 emulation. COM1 is located from 0x3f8 to 0x3ff and normally uses IRQ 4. COM2 is located from 0x2f8 to 0x2ff and normally uses IRQ 3. COM3 is located from 0x3e8 to 0x3ef and has no standardized IRQ. COM4 is located from 0x2e8 to 0x2ef and has no standardized IRQ. A description of the I/O ports of the 8250/16450/16550 UART is provided below. I/O Port Access Allowed Description +0x00 write (DLAB==0) Transmit Holding Register (THR).Information written to this port are treated as data words and will be transmitted by the UART. +0x00 read (DLAB==0) Receive Buffer Register (RBR).Any data words received by the UART form the serial link are accessed by the host by reading this port. +0x00 write/read (DLAB==1) Divisor Latch LSB (DLL)This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 0 thru 7 of the divisor. +0x01 write/read (DLAB==1) Divisor Latch MSB (DLH)This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 8 thru 15 of the divisor. +0x01 write/read (DLAB==0) Interrupt Enable Register (IER)The 8250/16450/16550 UART classifies events into one of four categories. Each category can be configured to generate an interrupt when any of the events occurs. The 8250/16450/16550 UART generates a single external interrupt signal regardless of how many events in the enabled categories have occurred. It is up to the host processor to respond to the interrupt and then poll the enabled interrupt categories (usually all categories have interrupts enabled) to determine the true cause(s) of the interrupt. Bit 7 Reserved, always 0. Bit 6 Reserved, always 0. Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 Enable Modem Status Interrupt (EDSSI). Setting this bit to "1" allows the UART to generate an interrupt when a change occurs on one or more of the status lines. Bit 2 Enable Receiver Line Status Interrupt (ELSI) Setting this bit to "1" causes the UART to generate an interrupt when the an error (or a BREAK signal) has been detected in the incoming data. Bit 1 Enable Transmitter Holding Register Empty Interrupt (ETBEI) Setting this bit to "1" causes the UART to generate an interrupt when the UART has room for one or more additional characters that are to be transmitted. Bit 0 Enable Received Data Available Interrupt (ERBFI) Setting this bit to "1" causes the UART to generate an interrupt when the UART has received enough characters to exceed the trigger level of the FIFO, or the FIFO timer has expired (stale data), or a single character has been received when the FIFO is disabled. +0x02 write FIFO Control Register (FCR) (This port does not exist on the 8250 and 16450 UART.) Bit 7 Receiver Trigger Bit #1 Bit 6 Receiver Trigger Bit #0These two bits control at what point the receiver is to generate an interrupt when the FIFO is active. 7 6 How many words are received before an interrupt is generated 0 0 1 0 1 4 1 0 8 1 1 14 Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 DMA Mode Select. If Bit 0 is set to "1" (FIFOs enabled), setting this bit changes the operation of the -RXRDY and -TXRDY signals from Mode 0 to Mode 1. Bit 2 Transmit FIFO Reset. When a "1" is written to this bit, the contents of the FIFO are discarded. Any word currently being transmitted will be sent intact. This function is useful in aborting transfers. Bit 1 Receiver FIFO Reset. When a "1" is written to this bit, the contents of the FIFO are discarded. Any word currently being assembled in the shift register will be received intact. Bit 0 16550 FIFO Enable. When set, both the transmit and receive FIFOs are enabled. Any contents in the holding register, shift registers or FIFOs are lost when FIFOs are enabled or disabled. +0x02 read Interrupt Identification Register Bit 7 FIFOs enabled. On the 8250/16450 UART, this bit is zero. Bit 6 FIFOs enabled. On the 8250/16450 UART, this bit is zero. Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 Interrupt ID Bit #2. On the 8250/16450 UART, this bit is zero. Bit 2 Interrupt ID Bit #1 Bit 1 Interrupt ID Bit #0.These three bits combine to report the category of event that caused the interrupt that is in progress. These categories have priorities, so if multiple categories of events occur at the same time, the UART will report the more important events first and the host must resolve the events in the order they are reported. All events that caused the current interrupt must be resolved before any new interrupts will be generated. (This is a limitation of the PC architecture.) 2 1 0 Priority Description 0 1 1 First Received Error (OE, PE, BI, or FE) 0 1 0 Second Received Data Available 1 1 0 Second Trigger level identification (Stale data in receive buffer) 0 0 1 Third Transmitter has room for more words (THRE) 0 0 0 Fourth Modem Status Change (-CTS, -DSR, -RI, or -DCD) Bit 0 Interrupt Pending Bit. If this bit is set to "0", then at least one interrupt is pending. +0x03 write/read Line Control Register (LCR) Bit 7 Divisor Latch Access Bit (DLAB). When set, access to the data transmit/receive register (THR/RBR) and the Interrupt Enable Register (IER) is disabled. Any access to these ports is now redirected to the Divisor Latch Registers. Setting this bit, loading the Divisor Registers, and clearing DLAB should be done with interrupts disabled. Bit 6 Set Break. When set to "1", the transmitter begins to transmit continuous Spacing until this bit is set to "0". This overrides any bits of characters that are being transmitted. Bit 5 Stick Parity. When parity is enabled, setting this bit causes parity to always be "1" or "0", based on the value of Bit 4. Bit 4 Even Parity Select (EPS). When parity is enabled and Bit 5 is "0", setting this bit causes even parity to be transmitted and expected. Otherwise, odd parity is used. Bit 3 Parity Enable (PEN). When set to "1", a parity bit is inserted between the last bit of the data and the Stop Bit. The UART will also expect parity to be present in the received data. Bit 2 Number of Stop Bits (STB). If set to "1" and using 5-bit data words, 1.5 Stop Bits are transmitted and expected in each data word. For 6, 7 and 8-bit data words, 2 Stop Bits are transmitted and expected. When this bit is set to "0", one Stop Bit is used on each data word. Bit 1 Word Length Select Bit #1 (WLSB1) Bit 0 Word Length Select Bit #0 (WLSB0) Together these bits specify the number of bits in each data word. 1 0 Word Length 0 0 5 Data Bits 0 1 6 Data Bits 1 0 7 Data Bits 1 1 8 Data Bits +0x04 write/read Modem Control Register (MCR) Bit 7 Reserved, always 0. Bit 6 Reserved, always 0. Bit 5 Reserved, always 0. Bit 4 Loop-Back Enable. When set to "1", the UART transmitter and receiver are internally connected together to allow diagnostic operations. In addition, the UART modem control outputs are connected to the UART modem control inputs. CTS is connected to RTS, DTR is connected to DSR, OUT1 is connected to RI, and OUT 2 is connected to DCD. Bit 3 OUT 2. An auxiliary output that the host processor may set high or low. In the IBM PC serial adapter (and most clones), OUT 2 is used to tri-state (disable) the interrupt signal from the 8250/16450/16550 UART. Bit 2 OUT 1. An auxiliary output that the host processor may set high or low. This output is not used on the IBM PC serial adapter. Bit 1 Request to Send (RTS). When set to "1", the output of the UART -RTS line is Low (Active). Bit 0 Data Terminal Ready (DTR). When set to "1", the output of the UART -DTR line is Low (Active). +0x05 write/read Line Status Register (LSR) Bit 7 Error in Receiver FIFO. On the 8250/16450 UART, this bit is zero. This bit is set to "1" when any of the bytes in the FIFO have one or more of the following error conditions: PE, FE, or BI. Bit 6 Transmitter Empty (TEMT). When set to "1", there are no words remaining in the transmit FIFO or the transmit shift register. The transmitter is completely idle. Bit 5 Transmitter Holding Register Empty (THRE). When set to "1", the FIFO (or holding register) now has room for at least one additional word to transmit. The transmitter may still be transmitting when this bit is set to "1". Bit 4 Break Interrupt (BI). The receiver has detected a Break signal. Bit 3 Framing Error (FE). A Start Bit was detected but the Stop Bit did not appear at the expected time. The received word is probably garbled. Bit 2 Parity Error (PE). The parity bit was incorrect for the word received. Bit 1 Overrun Error (OE). A new word was received and there was no room in the receive buffer. The newly-arrived word in the shift register is discarded. On 8250/16450 UARTs, the word in the holding register is discarded and the newly- arrived word is put in the holding register. Bit 0 Data Ready (DR) One or more words are in the receive FIFO that the host may read. A word must be completely received and moved from the shift register into the FIFO (or holding register for 8250/16450 designs) before this bit is set. +0x06 write/read Modem Status Register (MSR) Bit 7 Data Carrier Detect (DCD). Reflects the state of the DCD line on the UART. Bit 6 Ring Indicator (RI). Reflects the state of the RI line on the UART. Bit 5 Data Set Ready (DSR). Reflects the state of the DSR line on the UART. Bit 4 Clear To Send (CTS). Reflects the state of the CTS line on the UART. Bit 3 Delta Data Carrier Detect (DDCD). Set to "1" if the -DCD line has changed state one more time since the last time the MSR was read by the host. Bit 2 Trailing Edge Ring Indicator (TERI). Set to "1" if the -RI line has had a low to high transition since the last time the MSR was read by the host. Bit 1 Delta Data Set Ready (DDSR). Set to "1" if the -DSR line has changed state one more time since the last time the MSR was read by the host. Bit 0 Delta Clear To Send (DCTS). Set to "1" if the -CTS line has changed state one more time since the last time the MSR was read by the host. +0x07 write/read Scratch Register (SCR). This register performs no function in the UART. Any value can be written by the host to this location and read by the host later on. Beyond the 16550A UART Although National Semiconductor has not offered any components compatible with the 16550 that provide additional features, various other vendors have. Some of these components are described below. It should be understood that to effectively utilize these improvements, drivers may have to be provided by the chip vendor since most of the popular operating systems do not support features beyond those provided by the 16550. ST16650 By default this part is similar to the NS16550A, but an extended 32-byte send and receive buffer can be optionally enabled. Made by StarTech. TIL16660 By default this part behaves similar to the NS16550A, but an extended 64-byte send and receive buffer can be optionally enabled. Made by Texas Instruments. Hayes ESP This proprietary plug-in card contains a 2048-byte send and receive buffer, and supports data rates to 230.4Kbit/sec. Made by Hayes. In addition to these dumb UARTs, many vendors produce intelligent serial communication boards. This type of design usually provides a microprocessor that interfaces with several UARTs, processes and buffers the data, and then alerts the main PC processor when necessary. Because the UARTs are not directly accessed by the PC processor in this type of communication system, it is not necessary for the vendor to use UARTs that are compatible with the 8250, 16450, or the 16550 UART. This leaves the designer free to components that may have better performance characteristics. Configuring the <devicename>sio</devicename> driver The sio driver provides support for NS8250-, NS16450-, NS16550 and NS16550A-based EIA RS-232C (CCITT V.24) communications interfaces. Several multiport cards are supported as well. See the &man.sio.4; manual page for detailed technical documentation. Digi International (DigiBoard) PC/8 - Contributed by &a.awebster;. 26 August + Contributed by &a.awebster.email;. 26 August 1995. Here is a config snippet from a machine with a Digi International PC/8 with 16550. It has 8 modems connected to these 8 lines, and they work just great. Do not forget to add options COM_MULTIPORT or it will not work very well! device sio4 at isa? port 0x100 flags 0xb05 device sio5 at isa? port 0x108 flags 0xb05 device sio6 at isa? port 0x110 flags 0xb05 device sio7 at isa? port 0x118 flags 0xb05 device sio8 at isa? port 0x120 flags 0xb05 device sio9 at isa? port 0x128 flags 0xb05 device sio10 at isa? port 0x130 flags 0xb05 device sio11 at isa? port 0x138 flags 0xb05 irq 9 The trick in setting this up is that the MSB of the flags represent the last SIO port, in this case 11 so flags are 0xb05. Boca 16 - Contributed by &a.whiteside;. 26 August + Contributed by &a.whiteside.email;. 26 August 1995. The procedures to make a Boca 16 port board with FreeBSD are pretty straightforward, but you will need a couple things to make it work: You either need the kernel sources installed so you can recompile the necessary options or you will need someone else to compile it for you. The 2.0.5 default kernel does not come with multiport support enabled and you will need to add a device entry for each port anyways. Two, you will need to know the interrupt and IO setting for your Boca Board so you can set these options properly in the kernel. One important note — the actual UART chips for the Boca 16 are in the connector box, not on the internal board itself. So if you have it unplugged, probes of those ports will fail. I have never tested booting with the box unplugged and plugging it back in, and I suggest you do not either. If you do not already have a custom kernel configuration file set up, refer to Kernel Configuration chapter of the FreeBSD Handbook for general procedures. The following are the specifics for the Boca 16 board and assume you are using the kernel name MYKERNEL and editing with vi. Add the line options COM_MULTIPORT to the config file. Where the current device sion lines are, you will need to add 16 more devices. The following example is for a Boca Board with an interrupt of 3, and a base IO address 100h. The IO address for Each port is +8 hexadecimal from the previous port, thus the 100h, 108h, 110h... addresses. device sio1 at isa? port 0x100 flags 0x1005 device sio2 at isa? port 0x108 flags 0x1005 device sio3 at isa? port 0x110 flags 0x1005 device sio4 at isa? port 0x118 flags 0x1005 … device sio15 at isa? port 0x170 flags 0x1005 device sio16 at isa? port 0x178 flags 0x1005 irq 3 The flags entry must be changed from this example unless you are using the exact same sio assignments. Flags are set according to 0xMYY where M indicates the minor number of the master port (the last port on a Boca 16) and YY indicates if FIFO is enabled or disabled(enabled), IRQ sharing is used(yes) and if there is an AST/4 compatible IRQ control register(no). In this example, flags 0x1005 indicates that the master port is sio16. If I added another board and assigned sio17 through sio28, the flags for all 16 ports on that board would be 0x1C05, where 1C indicates the minor number of the master port. Do not change the 05 setting. Save and complete the kernel configuration, recompile, install and reboot. Presuming you have successfully installed the recompiled kernel and have it set to the correct address and IRQ, your boot message should indicate the successful probe of the Boca ports as follows: (obviously the sio numbers, IO and IRQ could be different) sio1 at 0x100-0x107 flags 0x1005 on isa sio1: type 16550A (multiport) sio2 at 0x108-0x10f flags 0x1005 on isa sio2: type 16550A (multiport) sio3 at 0x110-0x117 flags 0x1005 on isa sio3: type 16550A (multiport) sio4 at 0x118-0x11f flags 0x1005 on isa sio4: type 16550A (multiport) sio5 at 0x120-0x127 flags 0x1005 on isa sio5: type 16550A (multiport) sio6 at 0x128-0x12f flags 0x1005 on isa sio6: type 16550A (multiport) sio7 at 0x130-0x137 flags 0x1005 on isa sio7: type 16550A (multiport) sio8 at 0x138-0x13f flags 0x1005 on isa sio8: type 16550A (multiport) sio9 at 0x140-0x147 flags 0x1005 on isa sio9: type 16550A (multiport) sio10 at 0x148-0x14f flags 0x1005 on isa sio10: type 16550A (multiport) sio11 at 0x150-0x157 flags 0x1005 on isa sio11: type 16550A (multiport) sio12 at 0x158-0x15f flags 0x1005 on isa sio12: type 16550A (multiport) sio13 at 0x160-0x167 flags 0x1005 on isa sio13: type 16550A (multiport) sio14 at 0x168-0x16f flags 0x1005 on isa sio14: type 16550A (multiport) sio15 at 0x170-0x177 flags 0x1005 on isa sio15: type 16550A (multiport) sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa sio16: type 16550A (multiport master) If the messages go by too fast to see, &prompt.root; dmesg | more will show you the boot messages. Next, appropriate entries in /dev for the devices must be made using the /dev/MAKEDEV script. This step can be omitted if you are running FreeBSD 5.X with a kernel that has &man.devfs.5; support compiled in. If you do need to create the /dev entries, run the following as root: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tty1 &prompt.root; ./MAKEDEV cua1 (everything in between) &prompt.root; ./MAKEDEV ttyg &prompt.root; ./MAKEDEV cuag If you do not want or need call-out devices for some reason, you can dispense with making the cua* devices. If you want a quick and sloppy way to make sure the devices are working, you can simply plug a modem into each port and (as root) &prompt.root; echo at > ttyd* for each device you have made. You should see the RX lights flash for each working port. Support for Cheap Multi-UART Cards Contributed by Helge Oldach hmo@sep.hamburg.com, September 1999 Ever wondered about FreeBSD support for your 20$ multi-I/O card with two (or more) COM ports, sharing IRQs? Here is how: Usually the only option to support these kind of boards is to use a distinct IRQ for each port. For example, if your CPU board has an on-board COM1 port (aka sio0–I/O address 0x3F8 and IRQ 4) and you have an extension board with two UARTs, you will commonly need to configure them as COM2 (aka sio1–I/O address 0x2F8 and IRQ 3), and the third port (aka sio2) as I/O 0x3E8 and IRQ 5. Obviously this is a waste of IRQ resources, as it should be basically possible to run both extension board ports using a single IRQ with the COM_MULTIPORT configuration described in the previous sections. Such cheap I/O boards commonly have a 4 by 3 jumper matrix for the COM ports, similar to the following: o o o * Port A | o * o * Port B | o * o o IRQ 2 3 4 5 Shown here is port A wired for IRQ 5 and port B wired for IRQ 3. The IRQ columns on your specific board may vary—other boards may supply jumpers for IRQs 3, 4, 5, and 7 instead. One could conclude that wiring both ports for IRQ 3 using a handcrafted wire-made jumper covering all three connection points in the IRQ 3 column would solve the issue, but no. You cannot duplicate IRQ 3 because the output drivers of each UART are wired in a totem pole fashion, so if one of the UARTs drives IRQ 3, the output signal will not be what you would expect. Depending on the implementation of the extension board or your motherboard, the IRQ 3 line will continuously stay up, or always stay low. You need to decouple the IRQ drivers for the two UARTs, so that the IRQ line of the board only goes up if (and only if) one of the UARTs asserts a IRQ, and stays low otherwise. The solution was proposed by Joerg Wunsch j@ida.interface-business.de: To solder up a wired-or consisting of two diodes (Germanium or Schottky-types strongly preferred) and a 1 kOhm resistor. Here is the schematic, starting from the 4 by 3 jumper field above: Diode +---------->|-------+ / | o * o o | 1 kOhm Port A +----|######|-------+ o * o o | | Port B `-------------------+ ==+== o * o o | Ground \ | +--------->|-------+ IRQ 2 3 4 5 Diode The cathodes of the diodes are connected to a common point, together with a 1 kOhm pull-down resistor. It is essential to connect the resistor to ground to avoid floating of the IRQ line on the bus. Now we are ready to configure a kernel. Staying with this example, we would configure: # standard on-board COM1 port device sio0 at isa? port "IO_COM1" flags 0x10 # patched-up multi-I/O extension board options COM_MULTIPORT device sio1 at isa? port "IO_COM2" flags 0x205 device sio2 at isa? port "IO_COM3" flags 0x205 irq 3 Note that the flags setting for sio1 and sio2 is truly essential; refer to &man.sio.4; for details. (Generally, the 2 in the "flags" attribute refers to sio2 which holds the IRQ, and you surely want a 5 low nibble.) With kernel verbose mode turned on this should yield something similar to this: sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff flags 0x205 on isa sio1: type 16550A (multiport) sio2: irq maps: 0x1 0x9 0x1 0x1 sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa sio2: type 16550A (multiport master) Though /sys/i386/isa/sio.c is somewhat cryptic with its use of the irq maps array above, the basic idea is that you observe 0x1 in the first, third, and fourth place. This means that the corresponding IRQ was set upon output and cleared after, which is just what we would expect. If your kernel does not display this behavior, most likely there is something wrong with your wiring. Configuring the <devicename>cy</devicename> driver Contributed by Alex Nash. 6 June 1996. The Cyclades multiport cards are based on the cy driver instead of the usual sio driver used by other multiport cards. Configuration is a simple matter of: Add the cy device to your kernel configuration (note that your irq and iomem settings may differ). device cy0 at isa? irq 10 iomem 0xd4000 iosiz 0x2000 Rebuild and install the new kernel. Make the device nodes by typing (the following example assumes an 8-port board) You can omit this part if you are running FreeBSD 5.X with &man.devfs.5;. : &prompt.root; cd /dev &prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done If appropriate, add dialup entries to /etc/ttys by duplicating serial device (ttyd) entries and using ttyc in place of ttyd. For example: ttyc0 "/usr/libexec/getty std.38400" unknown on insecure ttyc1 "/usr/libexec/getty std.38400" unknown on insecure ttyc2 "/usr/libexec/getty std.38400" unknown on insecure … ttyc7 "/usr/libexec/getty std.38400" unknown on insecure Reboot with the new kernel. Configuring the <devicename>si</devicename> driver - Contributed by &a.nsayer;. 25 March + Contributed by &a.nsayer.email;. 25 March 1998. The Specialix SI/XIO and SX multiport cards use the si driver. A single machine can have up to 4 host cards. The following host cards are supported: ISA SI/XIO host card (2 versions) EISA SI/XIO host card PCI SI/XIO host card ISA SX host card PCI SX host card Although the SX and SI/XIO host cards look markedly different, their functionality are basically the same. The host cards do not use I/O locations, but instead require a 32K chunk of memory. The factory configuration for ISA cards places this at 0xd0000-0xd7fff. They also require an IRQ. PCI cards will, of course, auto-configure themselves. You can attach up to 4 external modules to each host card. The external modules contain either 4 or 8 serial ports. They come in the following varieties: SI 4 or 8 port modules. Up to 57600 bps on each port supported. XIO 8 port modules. Up to 115200 bps on each port supported. One type of XIO module has 7 serial and 1 parallel port. SXDC 8 port modules. Up to 921600 bps on each port supported. Like XIO, a module is available with one parallel port as well. To configure an ISA host card, add the following line to your kernel configuration file, changing the numbers as appropriate: device si0 at isa? iomem 0xd0000 irq 11 Valid IRQ numbers are 9, 10, 11, 12 and 15 for SX ISA host cards and 11, 12 and 15 for SI/XIO ISA host cards. To configure an EISA or PCI host card, use this line: device si0 After adding the configuration entry, rebuild and install your new kernel. The following step, is not necessary if you are using &man.devfs.5; in FreeBSD 5.X. After rebooting with the new kernel, you need to make the device nodes in /dev. The MAKEDEV script will take care of this for you. Count how many total ports you have and type: &prompt.root; cd /dev &prompt.root; ./MAKEDEV ttyAnn cuaAnn (where nn is the number of ports) If you want login prompts to appear on these ports, you will need to add lines like this to /etc/ttys: ttyA01 "/usr/libexec/getty std.9600" vt100 on insecure Change the terminal type as appropriate. For modems, dialup or unknown is fine.

diff --git a/en_US.ISO8859-1/books/dev-model/book.xml b/en_US.ISO8859-1/books/dev-model/book.xml index 97213996fd..607d0f2b8d 100644 --- a/en_US.ISO8859-1/books/dev-model/book.xml +++ b/en_US.ISO8859-1/books/dev-model/book.xml @@ -1,2658 +1,2658 @@ %chapters; ]> A project model for the FreeBSD Project Niklas Saers 2002-2005 Niklas Saers 1.3 October, 2012 Remove hats held by specific people, these are documented elsewhere. 1.2 April, 2005 Update one year of changes, replace statistics with those of 2004 1.1 July, 2004 First update within the FreeBSD tree 1.0 December 4th, 2003 Ready for commit to FreeBSD Documentation 0.7 April 7th, 2003 Release for review by the Documentation team 0.6 March 1st, 2003 Incorporated corrections noted by interviewees and reviewers 0.5 February 1st, 2003 Initial review by interviewees $FreeBSD$ Foreword Up until now, the FreeBSD project has released a number of described techniques to do different parts of work. However, a project model summarising how the project is structured is needed because of the increasing amount of project members. This goes hand-in-hand with Brooks' law that adding another person to a late project will make it later since it will increase the communication needs . A project model is a tool to reduce the communication needs. This paper will provide such a project model and is donated to the FreeBSD Documentation project where it can evolve together with the project so that it can at any point in time reflect the way the project works. It is based on . I would like to thank the following people for taking the time to explain things that were unclear to me and for proofreading the document. Andrey A. Chernov ache@freebsd.org Bruce A. Mah bmah@freebsd.org Dag-Erling Smørgrav des@freebsd.org Giorgos Keramidaskeramida@freebsd.org Ingvil Hovig ingvil.hovig@skatteetaten.no Jesper Holckjeh.inf@cbs.dk John Baldwin jhb@freebsd.org John Polstra jdp@freebsd.org Kirk McKusick mckusick@freebsd.org Mark Linimon linimon@freebsd.org Marleen Devos Niels Jørgenssennielsj@ruc.dk Nik Clayton nik@freebsd.org Poul-Henning Kamp phk@freebsd.org Simon L. Nielsen simon@freebsd.org Overview A project model is a means to reduce the communications overhead in a project. As shown by , increasing the number of project participants increases the communication in the project exponentionally. FreeBSD has during the past few years increased both its mass of active users and committers, and the communication in the project has risen accordingly. This project model will serve to reduce this overhead by providing an up-to-date description of the project. During the Core elections in 2002, Mark Murray stated I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs. . This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination. It is meant as a description of the project, with an overview of how the different processes are executed. It is an introduction to how the FreeBSD project works. The FreeBSD project model will be described as of July 1st, 2004. It is based on the Niels Jørgensen's paper , FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers. After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes. Finally it will outline major sub-projects of the FreeBSD project. , Section 1.2 and 1.3 give the vision and the architectural guidelines for the project. The vision is To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability. The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project Definitions

Activity An activity is an element of work performed during the course of a project . It has an output and leads towards an outcome. Such an output can either be an input to another activity or a part of the process' delivery.

Process A process is a series of activities that lead towards a particular outcome. A process can consist of one or more sub-processes. An example of a process is software design.

Hat A hat is synonymous with role. A hat has certain responsibilities in a process and for the process outcome. The hat executes activities. It is well defined what issues the hat should be contacted about by the project members and people outside the project.

Outcome An outcome is the final output of the process. This is synonymous with deliverable, that is defined as any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer by . Examples of outcomes are a piece of software, a decision made or a report written.

FreeBSD When saying FreeBSD we will mean the BSD derivative UNIX-like operating system FreeBSD, whereas when saying the FreeBSD Project we will mean the project organisation.

Organisational structure While no-one takes ownership of FreeBSD, the FreeBSD organisation is divided into core, committers and contributors and is part of the FreeBSD community that lives around it.

The FreeBSD Project's structure Number of committers has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004 and contributors by going through the list of contributions and problem reports. The main resource in the FreeBSD community is its developers: the committers and contributors. It is with their contributions that the project can move forward. Regular developers are referred to as contributors. As by January 1st, 2003, there are an estimated 5500 contributors on the project. Committers are developers with the privilege of being able to commit changes. These are usually the most active developers who are willing to spend their time not only integrating their own code but integrating code submitted by the developers who do not have this privilege. They are also the developers who elect the core team, and they have access to closed discussions. The project can be grouped into four distinct separate parts, and most developers will focus their involvement in one part of FreeBSD. The four parts are kernel development, userland development, ports and documentation. When referring to the base system, both kernel and userland is meant. This split changes our triangle to look like this:

The FreeBSD Project's structure with committers in categories Number of committers per area has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004. Note that many committers work in multiple areas, making the total number higher than the real number of committers. The total number of committers at that time was 269. Committers fall into three groups: committers who are only concerned with one area of the project (for instance file systems), committers who are involved only with one sub-project and committers who commit to different parts of the code, including sub-projects. Because some committers work on different parts, the total number in the committers section of the triangle is higher than in the above triangle. The kernel is the main building block of FreeBSD. While the userland applications are protected against faults in other userland applications, the entire system is vulnerable to errors in the kernel. This, combined with the vast amount of dependencies in the kernel and that it is not easy to see all the consequences of a kernel change, demands developers with a relative full understanding of the kernel. Multiple development efforts in the kernel also requires a closer coordination than userland applications do. The core utilities, known as userland, provide the interface that identifies FreeBSD, both user interface, shared libraries and external interfaces to connecting clients. Currently, 162 people are involved in userland development and maintenance, many being maintainers for their own part of the code. Maintainership will be discussed in the section. Documentation is handled by and includes all documents surrounding the FreeBSD project, including the web pages. There were during 2004 101 people making commits to the FreeBSD Documentation Project. Ports is the collection of meta-data that is needed to make software packages build correctly on FreeBSD. An example of a port is the port for the web-browser Mozilla. It contains information about where to fetch the source, what patches to apply and how, and how the package should be installed on the system. This allows automated tools to fetch, build and install the package. As of this writing, there are more than 12600 ports available. Statistics are generated by counting the number of entries in the file fetched by portsdb by April 1st, 2005. portsdb is a part of the port sysutils/portupgrade. , ranging from web servers to games, programming languages and most of the application types that are in use on modern computers. Ports will be discussed further in the section . Methodology model

Development model There is no defined model for how people write code in FreeBSD. However, Niels Jørgenssen has suggested a model of how written code is integrated into the project.

Jørgenssen's model for change integration The development release is the FreeBSD-CURRENT ("-CURRENT") branch and the production release is the FreeBSD-STABLE branch ("-STABLE") . This is a model for one change, and shows that after coding, developers seek community review and try integrating it with their own systems. After integrating the change into the development release, called FreeBSD-CURRENT, it is tested by many users and developers in the FreeBSD community. After it has gone through enough testing, it is merged into the production release, called FreeBSD-STABLE. Unless each stage is finished successfully, the developer needs to go back and make modifications in the code and restart the process. To integrate a change with either -CURRENT or -STABLE is called making a commit. Jørgensen found that most FreeBSD developers work individually, meaning that this model is used in parallel by many developers on the different ongoing development efforts. A developer can also be working on multiple changes, so that while he is waiting for review or people to test one or more of his changes, he may be writing another change. As each commit represents an increment, this is a massively incremental model. The commits are in fact so frequent that during one year The period from January 1st, 2004 to December 31st, 2004 was examined to find this number. , 85427 commits were made, making a daily average of 233 commits. Within the code bracket in Jørgensen's figure, each programmer has his own working style and follows his own development models. The bracket could very well have been called development as it includes requirements gathering and analysis, system and detailed design, implementation and verification. However, the only output from these stages is the source code or system documentation. From a stepwise model's perspective (such as the waterfall model), the other brackets can be seen as further verification and system integration. This system integration is also important to see if a change is accepted by the community. Up until the code is committed, the developer is free to choose how much to communicate about it to the rest of the project. In order for -CURRENT to work as a buffer (so that bright ideas that had some undiscovered drawbacks can be backed out) the minimum time a commit should be in -CURRENT before merging it to -STABLE is 3 days. Such a merge is referred to as an MFC (Merge From Current). It is important to notice the word change. Most commits do not contain radical new features, but are maintenance updates. The only exceptions from this model are security fixes and changes to features that are deprecated in the -CURRENT branch. In these cases, changes can be committed directly to the -STABLE branch. In addition to many people working on the project, there are many related projects to the FreeBSD Project. These are either projects developing brand new features, sub-projects or projects whose outcome is incorporated into FreeBSD For instance, the development of the Bluetooth stack started as a sub-project until it was deemed stable enough to be merged into the -CURRENT branch. Now it is a part of the core FreeBSD system. . These projects fit into the FreeBSD Project just like regular development efforts: they produce code that is integrated with the FreeBSD Project. However, some of them (like Ports and Documentation) have the privilege of being applicable to both branches or commit directly to both -CURRENT and -STABLE. There is no standards to how design should be done, nor is design collected in a centralised repository. The main design is that of 4.4BSD. According to Kirk McKusick, after 20 years of developing UNIX operating systems, the interfaces are for the most part figured out. There is therefore no need for much design. However, new applications of the system and new hardware leads to some implementations being more beneficial than those that used to be preferred. One example is the introduction of web browsing that made the normal TCP/IP connection a short burst of data rather than a steady stream over a longer period of time. As design is a part of the Code bracket in Jørgenssen's model, it is up to every developer or sub-project how this should be done. Even if the design should be stored in a central repository, the output from the design stages would be of limited use as the differences of methodologies would make them poorly if at all interoperable. For the overall design of the project, the project relies on the sub-projects to negotiate fit interfaces between each other rather than to dictate interfacing.

Release branches The releases of FreeBSD is best illustrated by a tree with many branches where each major branch represents a major version. Minor versions are represented by branches of the major branches. In the following release tree, arrows that follow one-another in a particular direction represent a branch. Boxes with full lines and diamonds represent official releases. Boxes with dotted lines represent the development branch at that time. Security branches are represented by ovals. Diamonds differ from boxes in that they represent a fork, meaning a place where a branch splits into two branches where one of the branches becomes a sub-branch. For example, at 4.0-RELEASE the 4.0-CURRENT branch split into 4-STABLE and 5.0-CURRENT. At 4.5-RELEASE, the branch forked off a security branch called RELENG_4_5.

The FreeBSD release tree The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE. In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. A major release is always made from the -CURRENT branch. However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising. An example of this is that following 3.0-RELEASE, 3.1-RELEASE was also a continuation of the -CURRENT-branch, and -CURRENT did not become a true development branch until this version was released and the 3-STABLE branch was forked. When -CURRENT returns to becoming a development branch, it can only be followed by a major release. 5-STABLE is predicted to be forked off 5.0-CURRENT at around 5.3-RELEASE. It is not until 5-STABLE is forked that the development branch will be branded 6.0-CURRENT. A minor release is made from the -CURRENT branch following a major release, or from the -STABLE branch. Following and including, 4.3-RELEASE The first release this actually happened for was 4.5-RELEASE, but security branches were at the same time created for 4.3-RELEASE and 4.4-RELEASE. , when a minor release has been made, it becomes a security branch. This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. There is a terminology overlap with respect to the word "stable", which leads to some confusion. The -STABLE branch is still a development branch, whose goal is to be useful for most people. If it is never acceptable for a system to get changes that are not announced at the time it is deployed, that system should run a security branch. Each update to a security branch is called a patchlevel. For every security enhancement that is done, the patchlevel number is increased, making it easy for people tracking the branch to see what security enhancements they have implemented. In cases where there have been especially serious security flaws, an entire new release can be made from a security branch. An example of this is 4.6.2-RELEASE.

Model summary To summarise, the development model of FreeBSD can be seen as the following tree:

The overall development model The tree of the FreeBSD development with ongoing development efforts and continuous integration. The tree symbolises the release versions with major versions spawning new main branches and minor versions being versions of the main branch. The top branch is the -CURRENT branch where all new development is integrated, and the -STABLE branch is the branch directly below it. Clouds of development efforts hang over the project where developers use the development models they see fit. The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. Security fixes are merged from -STABLE to the security branches.

Hats Many committers have a special area of responsibility. These roles are called hats. These hats can be either project roles, such as public relations officer, or maintainer for a certain area of the code. Because this is a project where people give voluntarily of their spare time, people with assigned hats are not always available. They must therefore appoint a deputy that can perform the hat's role in his or her absence. The other option is to have the role held by a group. Many of these hats are not formalised. Formalised hats have a charter stating the exact purpose of the hat along with its privileges and responsibilities. The writing of such charters is a new part of the project, and has thus yet to be completed for all hats. These hat descriptions are not such a formalisation, rather a summary of the role with links to the charter where available and contact addresses.

General Hats

Contributor A Contributor contributes to the FreeBSD project either as a developer, as an author, by sending problem reports, or in other ways contributing to the progress of the project. A contributor has no special privileges in the FreeBSD project.

Committer A person who has the required privileges to add his code or documentation to the repository. A committer has made a commit within the past 12 months. An active committer is a committer who has made an average of one commit per month during that time. It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify. However, when wanting to make modifications to parts a committer has not been involved in before, he/she should read the logs to see what has happened in this area before, and also read the MAINTAINER file to see if the maintainer of this part has any special requests on how changes in the code should be made

Core Team The core team is elected by the committers from the pool of committers and serves as the board of directors of the FreeBSD project. It promotes active contributors to committers, assigns people to well-defined hats, and is the final arbiter of decisions involving which way the project should be heading. As by July 1st, 2004, core consisted of 9 members. Elections are held every two years.

Maintainership Maintainership means that that person is responsible for what is allowed to go into that area of the code and has the final say should disagreements over the code occur. This involves proactive work aimed at stimulating contributions and reactive work in reviewing commits. With the FreeBSD source comes the MAINTAINERS file that contains a one-line summary of how each maintainer would like contributions to be made. Having this notice and contact information enables developers to focus on the development effort rather than being stuck in a slow correspondence should the maintainer be unavailable for some time. If the maintainer is unavailable for an unreasonably long period of time, and other people do a significant amount of work, maintainership may be switched without the maintainer's approval. This is based on the stance that maintainership should be demonstrated, not declared. Maintainership of a particular piece of code is a hat that is not held as a group.

Official Hats The official hats in the FreeBSD Project are hats that are more or less formalised and mainly administrative roles. They have the authority and responsibility for their area. The following illustration shows the responsibility lines. After this follows a description of each hat, including who it is held by.

Overview of official hats All boxes consist of groups of committers, except for the dotted boxes where the holders are not necessarily committers. The flattened circles are sub-projects and consist of both committers and non-committers of the main project.

Documentation project manager architect is responsible for defining and following up documentation goals for the committers in the Documentation project. Hat held by: The DocEng team doceng@FreeBSD.org. The DocEng Charter.

CVSup Mirror Site Coordinator The CVSup Mirror Site Coordinator coordinates all the s to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest CVSup mirror. Hat currently held by: The CVSup-master team cvsup-master@FreeBSD.org.

Postmaster The Postmaster is responsible for mail being correctly delivered to the committers' email address. He is also responsible for ensuring that the mailing lists work and should take measures against possible disruptions of mail such as having troll-, spam- and virus-filters. Hat currently held by: the Postmaster Team postmaster@FreeBSD.org.

Release Coordination The responsibilities of the Release Engineering Team are Setting, publishing and following a release schedule for official releases Documenting and formalising release engineering procedures Creation and maintenance of code branches Coordinating with the Ports and Documentation teams to have an updated set of packages and documentation released with the new releases Coordinating with the Security team so that pending releases are not affected by recently disclosed vulnerabilities. Further information about the development process is available in the section. Hat held by: the Release Engineering team re@FreeBSD.org. The Release Engineering Charter.

Public Relations & Corporate Liaison The Public Relations & Corporate Liaison's responsibilities are: Making press statements when happenings that are important to the FreeBSD Project happen. Being the official contact person for corporations that are working close with the FreeBSD Project. Take steps to promote FreeBSD within both the Open Source community and the corporate world. Handle the freebsd-advocacy mailing list. This hat is currently not occupied.

Security Officer The Security Officer's main responsibility is to coordinate information exchange with others in the security community and in the FreeBSD project. The Security Officer is also responsible for taking action when security problems are reported and promoting proactive development behaviour when it comes to security. Because of the fear that information about vulnerabilities may leak out to people with malicious intent before a patch is available, only the Security Officer, consisting of an officer, a deputy and two members, receive sensitive information about security issues. However, to create or implement a patch, the Security Officer has the Security Officer Team security-team@FreeBSD.org to help do the work.

Source Repository Manager The Source Repository Manager is the only one who is allowed to directly modify the repository without using the tool. It is his/her responsibility to ensure that technical problems that arise in the repository are resolved quickly. The source repository manager has the authority to back out commits if this is necessary to resolve a CVS technical problem. Hat held by: the Source Repository Manager cvs@FreeBSD.org.

Election Manager The Election Manager is responsible for the process. The manager is responsible for running and maintaining the election system, and is the final authority should minor unforeseen events happen in the election process. Major unforeseen events have to be discussed with the Hat held only during elections.

Web site Management The Web site Management hat is responsible for coordinating the rollout of updated web pages on mirrors around the world, for the overall structure of the primary web site and the system it is running upon. The management needs to coordinate the content with and acts as maintainer for the www tree. Hat held by: the FreeBSD Webmasters www@FreeBSD.org.

Ports Manager The Ports Manager acts as a liaison between and the core project, and all requests from the project should go to the ports manager. Hat held by: the Ports Management Team portmgr@FreeBSD.org. The Portmgr charter.

Standards The Standards hat is responsible for ensuring that FreeBSD complies with the standards it is committed to , keeping up to date on the development of these standards and notifying FreeBSD developers of important changes that allows them to take a proactive role and decrease the time between a standards update and FreeBSD's compliancy. Hat currently held by: Garrett Wollman wollman@FreeBSD.org.

Core Secretary The Core Secretary's main responsibility is to write drafts to and publish the final Core Reports. The secretary also keeps the core agenda, thus ensuring that no balls are dropped unresolved. - Hat currently held by: &a.pgj;. + Hat currently held by: &a.pgj.email;.

GNATS Administrator The GNATS Administrator is responsible for ensuring that the maintenance database is in working order, that the entries are correctly categorised and that there are no invalid entries. Hat currently held by: the Bugmeister Team bugmeister@FreeBSD.org.

Bugmeister The Bugmeister is the person in charge of the problem report group. Hat currently held by: the Bugmeister Team bugmeister@FreeBSD.org,

Donations Liaison Officer The task of the donations liaison officer is to match the developers with needs with people or organisations willing to make a donation. The Donations Liaison Charter is available here Hat held by: the Donations Liaison Office donations@FreeBSD.org.

Admin (Also called FreeBSD Cluster Admin) The admin team consists of the people responsible for administrating the computers that the project relies on for its distributed work and communication to be synchronised. It consists mainly of those people who have physical access to the servers. Hat held by: the Admin team admin@FreeBSD.org.

Process dependent hats

Report originator The person originally responsible for filing a Problem Report.

Bugbuster A person who will either find the right person to solve the problem, or close the PR if it is a duplicate or otherwise not an interesting one.

Mentor A mentor is a committer who takes it upon him/her to introduce a new committer to the project, both in terms of ensuring the new committers setup is valid, that the new committer knows the available tools required in his/her work and that the new committer knows what is expected of him/her in terms of behaviour.

Vendor The person(s) or organisation whom external code comes from and whom patches are sent to.

Reviewers People on the mailing list where the request for review is posted.

CVSup Mirror Site Admin A CVSup Mirror Site Admin has accesses to a server that he/she uses to mirror the CVS repository. The admin works with the to ensure the site remains up-to-date and is following the general policy of official mirror sites.

Processes The following section will describe the defined project processes. Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases.

Adding new and removing old committers The Core team has the responsibility of giving and removing commit privileges to contributors. This can only be done through a vote on the core mailing list. The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges. Normally a contributor is recommended to core by a committer. For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected. If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. However, it is frequently this committer that recommends the developer. When a contributor is given committer status, he is assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon himself to be the new committers mentor. When a contributor is given his commit bit, a -signed email is sent from either , or nik@freebsd.org to both admins@freebsd.org, the assigned mentor, the new committer and core confirming the approval of a new account. The mentor then gathers a password line, public key and PGP key from the new committer and sends them to . When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process.

Process summary: adding a new committer When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If he recommends this to core, they will vote on this recommendation. If they vote in favour, a mentor is assigned the new committer and the new committer has to email his details to the administrators for an account to be created. After this, the new committer is all set to make his first commit. By tradition, this is by adding his name to the committers list. Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see section 1.5.8.

Process summary: removing a committer When Core decides to clean up the committers list, they check who has not made a commit for the past 18 months. Committers who have not done so have their commit bits revoked. It is also possible for committers to request that their commit bit be retired if for some reason they are no longer going to be actively committing to the project. In this case, it can also be restored at a later time by core, should the committer ask. Roles in this process:

Adding/Removing an official CVSup Mirror A mirror is a replica of the official CVSup master that contains all the up-to-date source code for all the branches in the FreeBSD project, ports and documentation. Adding an official CVSup mirror starts with the potential installing the cvsup-mirror package. Having done this and updated the source code with a mirror site, he now runs a fairly recent unofficial CVSup mirror. Deciding he has a stable environment, the processing power, the network capacity and the storage capacity to run an official mirror, he mails the who decides whether the mirror should become an official mirror or not. In making this decision, the has to determine whether that geographical area needs another mirror site, if the mirror administrator has the skills to run it reliably, if the network bandwidth is adequate and if the master server has the capacity to server another mirror. If decides that the mirror should become an official mirror, he obtains an authentication key from the mirror admin that he installs so the mirror admin can update the mirror from the master server.

Process summary: adding a CVSup mirror When a CVSup mirror administrator of an unofficial mirror offers to become an official mirror site, the CVSup coordinator decides if another mirror is needed and if there is sufficient capacity to accommodate it. If so, an authorisation key is requested and the mirror is given access to the main distribution site and added to the list of official mirrors. Tools used in this process: Hats involved in this process:

Committing code The committing of new or modified code is one of the most frequent processes in the FreeBSD project and will usually happen many times a day. Committing of code can only be done by a committer. Committers commit either code written by themselves, code submitted to them or code submitted through a problem report. When code is written by the developer that is non-trivial, he should seek a code review from the community. This is done by sending mail to the relevant list asking for review. Before submitting the code for review, he should ensure it compiles correctly with the entire tree and that all relevant tests run. This is called pre-commit test. When contributed code is received, it should be reviewed by the committer and tested the same way. When a change is committed to a part of the source that has been contributed from an outside , the maintainer should ensure that the patch is contributed back to the vendor. This is in line with the open source philosophy and makes it easier to stay in sync with outside projects as the patches do not have to be reapplied every time a new release is made. After the code has been available for review and no further changes are necessary, the code is committed into the development branch, -CURRENT. If the change applies for the -STABLE branch or the other branches as well, a Merge From Current ("MFC") countdown is set by the committer. After the number of days the committer chose when setting the MFC have passed, an email will automatically be sent to the committer reminding him to commit it to the -STABLE branch (and possibly security branches as well). Only security critical changes should be merged to security branches. Delaying the commit to -STABLE and other branches allows for parallel debugging where the committed code is tested on a wide range of configurations. This makes changes to -STABLE to contain fewer faults and thus giving the branch its name.

Process summary: A committer commits code When a committer has written a piece of code and wants to commit it, he first needs to determine if it is trivial enough to go in without prior review or if it should first be reviewed by the developer community. If the code is trivial or has been reviewed and the committer is not the maintainer, he should consult the maintainer before proceeding. If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the vendor. The code is then committed and the deployed by the users. Should they find problems with the code, this will be reported and the committer can go back to writing a patch. If a vendor is affected, he can choose to implement or ignore the patch.

Process summary: A contributor commits code The difference when a contributor makes a code contribution is that he submits the code through the send-pr program. This report is picked up by the maintainer who reviews the code and commits it. Hats included in this process are:

Core election Core elections are held at least every two years. The first Core election was held September 2000 Nine core members are elected. New elections are held if the number of core members drops below seven. New elections can also be held should at least 1/3 of the active committers demand this. When an election is to take place, core announces this at least 6 weeks in advance, and appoints an election manager to run the elections. Only committers can be elected into core. The candidates need to submit their candidacy at least one week before the election starts, but can refine their statements until the voting starts. They are presented in the candidates list. When writing their election statements, the candidates must answer a few standard questions submitted by the election manager. During elections, the rule that a committer must have committed during the 12 past months is followed strictly. Only these committers are eligible to vote. When voting, the committer may vote once in support of up to nine nominees. The voting is done over a period of four weeks with reminders being posted on developers mailing list that is available to all committers. The election results are released one week after the election ends, and the new core team takes office one week after the results have been posted. Should there be a voting tie, this will be resolved by the new, unambiguously elected core members. Votes and candidate statements are archived, but the archives are not publicly available.

Process summary: Core elections Core announces the election and selects an election manager. He prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are announced and the new core team takes office. Hats in core elections are:

Development of new features Within the project there are sub-projects that are working on new features. These projects are generally done by one person . Every project is free to organise development as it sees fit. However, when the project is merged to the -CURRENT branch it must follow the project guidelines. When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch. The requirements of the project are given by developer wishes, requests from the community in terms of direct requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. The wishes that come within the responsibility of a developer are given to that developer who prioritises his time between the request and his wishes. A common way to do this is maintain a TODO-list maintained by the project. Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. All requests, their distribution and follow-up are handled by the tool. Requirements analysis happens in two ways. The requests that come in are discussed on mailing lists, both within the main project and in the sub-project that the request belongs to or is spawned by the request. Furthermore, individual developers on the sub-project will evaluate the feasibility of the requests and determine the prioritisation between them. Other than archives of the discussions that have taken place, no outcome is created by this phase that is merged into the main project. As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary or are funded to do, there is no overall strategy or priorisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team. The verification phase of the project is two-fold. Before committing code to the current-branch, developers request their code to be reviewed by their peers. This review is for the most part done by functional testing, but also code review is important. When the code is committed to the branch, a broader functional testing will happen, that may trigger further code review and debugging should the code not behave as expected. This second verification form may be regarded as structural verification. Although the sub-projects themselves may write formal tests such as unit tests, these are usually not collected by the main project and are usually removed before the code is committed to the current branch. More and more tests are however performed when building the system (make world). These tests are however a very new addition and no systematic framework for these tests have yet been created.

Maintenance It is an advantage to the project to for each area of the source have at least one person that knows this area well. Some parts of the code have designated maintainers. Others have de-facto maintainers, and some parts of the system do not have maintainers. The maintainer is usually a person from the sub-project that wrote and integrated the code, or someone who has ported it from the platform it was written for. sendmail and named are examples of code that has been merged from other platforms. The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered. The main bulk of work that is put into the FreeBSD project is maintenance. has made a figure showing the life cycle of changes.

Jørgenssen's model for change integration Here development release refers to the -CURRENT branch while production release refers to the -STABLE branch. The pre-commit test is the functional testing by peer developers when asked to do so or trying out the code to determine the status of the sub-project. Parallel debugging is the functional testing that can trigger more review, and debugging when the code is included in the -CURRENT branch. As of this writing, there were 269 committers in the project. When they commit a change to a branch, that constitutes a new release. It is very common for users in the community to track a particular branch. The immediate existence of a new release makes the changes widely available right away and allows for rapid feedback from the community. This also gives the community the response time they expect on issues that are of importance to them. This makes the community more engaged, and thus allows for more and better feedback that again spurs more maintenance and ultimately should create a better product. Before making changes to code in parts of the tree that has a history unknown to the committer, the committer is required to read the commit logs to see why certain features are implemented the way they are in order not to make mistakes that have previously either been thought through or resolved.

Problem reporting FreeBSD comes with a problem reporting tool called send-pr that is a part of the GNATS package. All users and developers are encouraged to use this tool for reporting problems in software they do not maintain. Problems include bug reports, feature requests, features that should be enhanced and notices of new versions of external software that is included in the project. Problem reports are sent to an email address where it is inserted into the GNATS maintenance database. A classifies the problem and sends it to the correct group or maintainer within the project. After someone has taken responsibility for the report, the report is being analysed. This analysis includes verifying the problem and thinking out a solution for the problem. Often feedback is required from the report originator or even from the FreeBSD community. Once a patch for the problem is made, the originator may be asked to try it out. Finally, the working patch is integrated into the project, and documented if applicable. It there goes through the regular maintenance cycle as described in section . These are the states a problem report can be in: open, analyzed, feedback, patched, suspended and closed. The suspended state is for when further progress is not possible due to the lack of information or for when the task would require so much work that nobody is working on it at the moment.

Process summary: problem reporting A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct maintainer. He verifies the problem and discusses the problem with the originator until he has enough information to create a working patch. This patch is then committed and the problem report is closed. The roles included in this process are: .

Reacting to misbehaviour has a number of rules that committers should follow. However, it happens that these rules are broken. The following rules exist in order to be able to react to misbehaviour. They specify what actions will result in how long a suspension the committer's commit privileges. Committing during code freezes without the approval of the Release Engineering team - 2 days Committing to a security branch without approval - 2 days Commit wars - 5 days to all participating parties Impolite or inappropriate behaviour - 5 days For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the core mailing list. Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges. (However, the latter is always viewed as a last resort, due to its inherent tendency to create controversy). All suspensions are posted to the developers mailing list, a list available to committers only. It is important that you cannot be suspended for making technical errors. All penalties come from breaking social etiquette. Hats involved in this process:

Release engineering The FreeBSD project has a Release Engineering team with a principal release engineer that is responsible for creating releases of FreeBSD that can be brought out to the user community via the net or sold in retail outlets. Since FreeBSD is available on multiple platforms and releases for the different architectures are made available at the same time, the team has one person in charge of each architecture. Also, there are roles in the team responsible for coordinating quality assurance efforts, building a package set and for having an updated set of documents. When referring to the release engineer, a representative for the release engineering team is meant. When a release is coming, the FreeBSD project changes shape somewhat. A release schedule is made containing feature- and code-freezes, release of interim releases and the final release. A feature-freeze means no new features are allowed to be committed to the branch without the release engineers' explicit consent. Code-freeze means no changes to the code (like bugs-fixes) are allowed to be committed without the release engineers explicit consent. This feature- and code-freeze is known as stabilising. During the release process, the release engineer has the full authority to revert to older versions of code and thus "back out" changes should he find that the changes are not suitable to be included in the release. There are three different kinds of releases: .0 releases are the first release of a major version. These are branched of the -CURRENT branch and have a significantly longer release engineering cycle due to the unstable nature of the -CURRENT branch .X releases are releases of the -STABLE branch. They are scheduled to come out every 4 months. .X.Y releases are security releases that follow the .X branch. These come out only when sufficient security fixes have been merged since the last release on that branch. New features are rarely included, and the security team is far more involved in these than in regular releases. For releases of the -STABLE-branch, the release process starts 45 days before the anticipated release date. During the first phase, the first 15 days, the developers merge what changes they have had in -CURRENT that they want to have in the release to the release branch. When this period is over, the code enters a 15 day code freeze in which only bug fixes, documentation updates, security-related fixes and minor device driver changes are allowed. These changes must be approved by the release engineer in advance. At the beginning of the last 15 day period a release candidate is created for widespread testing. Updates are less likely to be allowed during this period, except for important bug fixes and security updates. In this final period, all releases are considered release candidates. At the end of the release process, a release is created with the new version number, including binary distributions on web sites and the creation of a CD-ROM images. However, the release is not considered "really released" until a -signed message stating exactly that, is sent to the mailing list freebsd-announce; anything labelled as a "release" before that may well be in-process and subject to change before the PGP-signed message is sent. Many commercial vendors use these images to create CD-ROMs that are sold in retail outlets. . The releases of the -CURRENT-branch (that is, all releases that end with .0) are very similar, but with twice as long timeframe. It starts 8 weeks prior to the release with announcement of the release time line. Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. Four weeks prior to the release, an official beta version is made available. Two weeks prior to release, the code is officially branched into a new version. This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. However, development on the main development branch can continue. Other than these differences, the release engineering processes are alike. .0 releases go into their own branch and are aimed mainly at early adopters. The branch then goes through a period of stabilisation, and it is not until the decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with .1 versions, this is not a demand. Most releases are made when a given date that has been deemed a long enough time since the previous release comes. A target is set for having major releases every 18 months and minor releases every 4 months. The user community has made it very clear that security and stability cannot be sacrificed by self-imposed deadlines and target release dates. For slips of time not to become too long with regards to security and stability issues, extra discipline is required when committing changes to -STABLE.

Process summary: release engineering These are the stages in the release engineering process. Multiple release candidates may be created until the release is deemed stable enough to be released.

Tools The major support tools for supporting the development process are CVS, CVSup, Perforce, GNATS, Mailman and OpenSSH. Except for CVSup, these are externally developed tools. These tools are commonly used in the open source world.

Subversion (SVN) Subversion (SVN) is a system to handle multiple versions of text files and tracking who committed what changes and why. A project lives within a repository and different versions are considered different branches.

CVSup CVSup is a software package for distributing and updating collections of files across a network. It consists of a client program, cvsup, and a server program, cvsupd. The package is tailored specifically for distributing CVS repositories, and by taking advantage of CVS' properties, it performs updates much faster than traditional systems.

GNATS GNATS is a maintenance database consisting of a set of tools to track bugs at a central site. It supports the bug tracking process for sending and handling bugs as well as querying and updating the database and editing bug reports. The project uses one of its many client interfaces, send-pr, to send Problem Reports by email to the projects central GNATS server. The committers have also web and command-line clients available.

Mailman Mailman is a program that automates the management of mailing lists. The FreeBSD Project uses it to run 16 general lists, 60 technical lists, 4 limited lists and 5 lists with CVS commit logs. It is also used for many mailing lists set up and used by other people and projects in the FreeBSD community. General lists are lists for the general public, technical lists are mainly for the development of specific areas of interest, and closed lists are for internal communication not intended for the general public. The majority of all the communication in the project goes through these 85 lists , Appendix C.

Perforce Perforce is a commercial software configuration management system developed by Perforce Systems that is available on over 50 operating systems. It is a collection of clients built around the Perforce server that contains the central file repository and tracks the operations done upon it. The clients are both clients for accessing the repository and administration of its configuration.

Pretty Good Privacy Pretty Good Privacy, better known as PGP, is a cryptosystem using a public key architecture to allow people to digitally sign and/or encrypt information in order to ensure secure communication between two parties. A signature is used when sending information out many recipients, enabling them to verify that the information has not been tampered with before they received it. In the FreeBSD Project this is the primary means of ensuring that information has been written by the person who claims to have written it, and not altered in transit.

Secure Shell Secure Shell is a standard for securely logging into a remote system and for executing commands on the remote system. It allows other connections, called tunnels, to be established and protected between the two involved systems. This standard exists in two primary versions, and only version two is used for the FreeBSD Project. The most common implementation of the standard is OpenSSH that is a part of the project's main distribution. Since its source is updated more often than FreeBSD releases, the latest version is also available in the ports tree.

Sub-projects Sub-projects are formed to reduce the amount of communication needed to coordinate the group of developers. When a problem area is sufficiently isolated, most communication would be within the group focusing on the problem, requiring less communication with the groups they communicate with than were the group not isolated.

The Ports Subproject A port is a set of meta-data and patches that are needed to fetch, compile and install correctly an external piece of software on a FreeBSD system. The amount of ports have grown at a tremendous rate, as shown by the following figure.

Number of ports added between 1996 and 2005 is taken from the FreeBSD web site. It shows the number of ports available to FreeBSD in the period 1995 to 2005. It looks like the curve has first grown exponentionally, and then since the middle of 2001 grown linearly. As the external software described by the port often is under continued development, the amount of work required to maintain the ports is already large, and increasing. This has led to the ports part of the FreeBSD project gaining a more empowered structure, and is more and more becoming a sub-project of the FreeBSD project. Ports has its own core team with the as its leader, and this team can appoint committers without FreeBSD Core's approval. Unlike in the FreeBSD Project, where a lot of maintenance frequently is rewarded with a commit bit, the ports sub-project contains many active maintainers that are not committers. Unlike the main project, the ports tree is not branched. Every release of FreeBSD follows the current ports collection and has thus available updated information on where to find programs and how to build them. This, however, means that a port that makes dependencies on the system may need to have variations depending on what version of FreeBSD it runs on. With an unbranched ports repository it is not possible to guarantee that any port will run on anything other than -CURRENT and -STABLE, in particular older, minor releases. There is neither the infrastructure nor volunteer time needed to guarantee this. For efficiency of communication, teams depending on Ports, such as the release engineering team, have their own ports liaisons.

The FreeBSD Documentation Project The FreeBSD Documentation project was started January 1995. From the initial group of a project leader, four team leaders and 16 members, they are now a total of 44 committers. The documentation mailing list has just under 300 members, indicating that there is quite a large community around it. The goal of the Documentation project is to provide good and useful documentation of the FreeBSD project, thus making it easier for new users to get familiar with the system and detailing advanced features for the users. The main tasks in the Documentation project are to work on current projects in the FreeBSD Documentation Set, and translate the documentation to other languages. Like the FreeBSD Project, documentation is split in the same branches. This is done so that there is always an updated version of the documentation for each version. Only documentation errors are corrected in the security branches. Like the ports sub-project, the Documentation project can appoint documentation committers without FreeBSD Core's approval. . The Documentation project has a primer. This is used both to introduce new project members to the standard tools and syntaxes and acts as a reference when working on the project.

References Frederick P.Brooks 19751995 Pearson Education Limited 0201835959 Addison-Wesley Pub Co The Mythical Man-Month Essays on Software Engineering, Anniversary Edition (2nd Edition) NiklasSaers 2003 A project model for the FreeBSD Project Candidatus Scientiarum thesis NielsJørgensen 2001 Putting it All in the Trunk Incremental Software Development in the FreeBSD Open Source Project Project Management Institute 19962000 Project Management Institute 1-880410-23-0 Project Management Institute

Newtown Square Pennsylvania USA

PMBOK Guide A Guide to the Project Management Body of Knowledge, 2000 Edition 2002 The FreeBSD Project Core Bylaws 2002 The FreeBSD Documentation Project FreeBSD Developer's Handbook 2002 The FreeBSD Project Core team election 2002 Dag-ErlingSmørgrav HitenPandya 2002 The FreeBSD Documentation Project The FreeBSD Documentation Project Problem Report Handling Guidelines Dag-ErlingSmørgrav 2002 The FreeBSD Documentation Project The FreeBSD Documentation Project Writing FreeBSD Problem Reports 2001 The FreeBSD Documentation Project The FreeBSD Documentation Project Committers Guide MurrayStokely 2002 The FreeBSD Documentation Project The FreeBSD Documentation Project FreeBSD Release Engineering The FreeBSD Documentation Project FreeBSD Handbook 2002 The FreeBSD Documentation Project The FreeBSD Documentation Project Contributors to FreeBSD 2002 The FreeBSD Project The FreeBSD Project Core team elections 2002 2002 The FreeBSD Project The FreeBSD Project Commit Bit Expiration Policy 2002/04/06 15:35:30 2002 The FreeBSD Project The FreeBSD Project New Account Creation Procedure 2002/08/19 17:11:27 2002 The FreeBSD Documentation Project The FreeBSD Documentation Project FreeBSD DocEng Team Charter 2003/03/16 12:17 GregLehey 2002 Greg Lehey Greg Lehey Two years in the trenches The evolution of a software project diff --git a/en_US.ISO8859-1/books/developers-handbook/testing/chapter.xml b/en_US.ISO8859-1/books/developers-handbook/testing/chapter.xml index 080ed93b10..1f0150ea6f 100644 --- a/en_US.ISO8859-1/books/developers-handbook/testing/chapter.xml +++ b/en_US.ISO8859-1/books/developers-handbook/testing/chapter.xml @@ -1,488 +1,488 @@ Regression and Performance Testing Regression tests are used to exercise a particular bit of the system to check that it works as expected, and to make sure that old bugs are not reintroduced. The &os; regression testing tools can be found in the &os; source tree in the directory src/tools/regression.

Micro Benchmark Checklist This section contains hints for doing proper micro-benchmarking on &os; or of &os; itself. It is not possible to use all of the suggestions below every single time, but the more used, the better the benchmark's ability to test small differences will be. Disable APM and any other kind of clock fiddling (ACPI ?). Run in single user mode. E.g., &man.cron.8;, and other daemons only add noise. The &man.sshd.8; daemon can also cause problems. If ssh access is required during testing either disable the SSHv1 key regeneration, or kill the parent sshd daemon during the tests. Do not run &man.ntpd.8;. If &man.syslog.3; events are generated, run &man.syslogd.8; with an empty /etc/syslogd.conf, otherwise, do not run it. Minimize disk-I/O, avoid it entirely if possible. Do not mount file systems that are not needed. Mount /, /usr, and any other file system as read-only if possible. This removes atime updates to disk (etc.) from the I/O picture. Reinitialize the read/write test file system with &man.newfs.8; and populate it from a &man.tar.1; or &man.dump.8; file before every run. Unmount and mount it before starting the test. This results in a consistent file system layout. For a worldstone test this would apply to /usr/obj (just reinitialize with newfs and mount). To get 100% reproducibility, populate the file system from a &man.dd.1; file (i.e.: dd if=myimage of=/dev/ad0s1h bs=1m) Use malloc backed or preloaded &man.md.4; partitions. Reboot between individual iterations of the test, this gives a more consistent state. Remove all non-essential device drivers from the kernel. For instance if USB is not needed for the test, do not put USB in the kernel. Drivers which attach often have timeouts ticking away. Unconfigure hardware that are not in use. Detach disks with &man.atacontrol.8; and &man.camcontrol.8; if the disks are not used for the test. Do not configure the network unless it is being tested, or wait until after the test has been performed to ship the results off to another computer. If the system must be connected to a public network, watch out for spikes of broadcast traffic. Even though it is hardly noticeable, it will take up CPU cycles. Multicast has similar caveats. Put each file system on its own disk. This minimizes jitter from head-seek optimizations. Minimize output to serial or VGA consoles. Running output into files gives less jitter. (Serial consoles easily become a bottleneck.) Do not touch keyboard while the test is running, even space or back-space shows up in the numbers. Make sure the test is long enough, but not too long. If the test is too short, timestamping is a problem. If it is too long temperature changes and drift will affect the frequency of the quartz crystals in the computer. Rule of thumb: more than a minute, less than an hour. Try to keep the temperature as stable as possible around the machine. This affects both quartz crystals and disk drive algorithms. To get real stable clock, consider stabilized clock injection. E.g., get a OCXO + PLL, inject output into clock circuits instead of motherboard xtal. - Contact &a.phk; for more information about this. + Contact &a.phk.email; for more information about this. Run the test at least 3 times but it is better to run more than 20 times both for before and after code. Try to interleave if possible (i.e.: do not run 20 times before then 20 times after), this makes it possible to spot environmental effects. Do not interleave 1:1, but 3:3, this makes it possible to spot interaction effects. A good pattern is: bababa{bbbaaa}*. This gives hint after the first 1+1 runs (so it is possible to stop the test if it goes entirely the wrong way), a standard deviation after the first 3+3 (gives a good indication if it is going to be worth a long run) and trending and interaction numbers later on. Use &man.ministat.1; to see if the numbers are significant. Consider buying Cartoon guide to statistics ISBN: 0062731025, highly recommended, if you have forgotten or never learned about standard deviation and Student's T. Do not use background &man.fsck.8; unless the test is a benchmark of background fsck. Also, disable background_fsck in /etc/rc.conf unless the benchmark is not started at least 60+fsck runtime seconds after the boot, as &man.rc.8; wakes up and checks if fsck needs to run on any file systems when background fsck is enabled. Likewise, make sure there are no snapshots lying around unless the benchmark is a test with snapshots. If the benchmark show unexpected bad performance, check for things like high interrupt volume from an unexpected source. Some versions of ACPI have been reported to misbehave and generate excess interrupts. To help diagnose odd test results, take a few snapshots of vmstat -i and look for anything unusual. Make sure to be careful about optimization parameters for kernel and userspace, likewise debugging. It is easy to let something slip through and realize later the test was not comparing the same thing. Do not ever benchmark with the WITNESS and INVARIANTS kernel options enabled unless the test is interested to benchmarking those features. WITNESS can cause 400%+ drops in performance. Likewise, userspace &man.malloc.3; parameters default differently in -CURRENT from the way they ship in production releases.

The &os; Source Tinderbox The source Tinderbox consists of: A build script, tinderbox, that automates checking out a specific version of the &os; source tree and building it. A supervisor script, tbmaster, that monitors individual Tinderbox instances, logs their output, and emails failure notices. A CGI script named index.cgi that reads a set of tbmaster logs and presents an easy-to-read HTML summary of them. A set of build servers that continually test the tip of the most important &os; code branches. A webserver that keeps a complete set of Tinderbox logs and displays an up-to-date summary. - The scripts are maintained and were developed by &a.des;, + The scripts are maintained and were developed by &a.des.email;, and are now written in Perl, a move on from their original incarnation as shell scripts. All scripts and configuration files are kept in /projects/tinderbox/. For more information about the tinderbox and tbmaster scripts at this stage, see their respective man pages: tinderbox(1) and tbmaster(1).

The <filename>index.cgi</filename> Script The index.cgi script generates the HTML summary of tinderbox and tbmaster logs. Although originally intended to be used as a CGI script, as indicated by its name, this script can also be run from the command line or from a &man.cron.8; job, in which case it will look for logs in the directory where the script is located. It will automatically detect context, generating HTTP headers when it is run as a CGI script. It conforms to XHTML standards and is styled using CSS. The script starts in the main() block by attempting to verify that it is running on the official Tinderbox website. If it is not, a page indicating it is not an official website is produced, and a URL to the official site is provided. Next, it scans the log directory to get an inventory of configurations, branches and architectures for which log files exist, to avoid hard-coding a list into the script and potentially ending up with blank rows or columns. This information is derived from the names of the log files matching the following pattern: tinderbox-$config-$branch-$arch-$machine.{brief,full} The configurations used on the official Tinderbox build servers are named for the branches they build. For example, the releng_8 configuration is used to build RELENG_8 as well as all still-supported release branches. Once all of this startup procedure has been successfully completed, do_config() is called for each configuration. The do_config() function generates HTML for a single Tinderbox configuration. It works by first generating a header row, then iterating over each branch build with the specified configuration, producing a single row of results for each in the following manner: For each item: For each machine within that architecture: If a brief log file exists, then: Call success() to determine the outcome of the build. Output the modification size. Output the size of the brief log file with a link to the log file itself. If a full log file also exists, then: Output the size of the full log file with a link to the log file itself. Otherwise: No output. The success() function mentioned above scans a brief log file for the string tinderbox run completed in order to determine whether the build was successful. Configurations and branches are sorted according to their branch rank. This is computed as follows: HEAD and CURRENT have rank 9999. RELENG_x has rank xx99. RELENG_x_y has rank xxyy. This means that HEAD always ranks highest, and RELENG branches are ranked in numerical order, with each STABLE branch ranking higher than the release branches forked off of it. For instance, for &os; 8, the order from highest to lowest would be: RELENG_8 (branch rank 899). RELENG_8_3 (branch rank 803). RELENG_8_2 (branch rank 802). RELENG_8_1 (branch rank 801). RELENG_8_0 (branch rank 800). The colors that Tinderbox uses for each cell in the table are defined by CSS. Successful builds are displayed with green text; unsuccessful builds are displayed with red text. The color fades as time passes since the corresponding build, with every half an hour bringing the color closer to grey.

Official Build Servers The official Tinderbox build servers are hosted by Sentex Data Communications, who also host the &os; Netperf Cluster. Three build servers currently exist: freebsd-current.sentex.ca builds: HEAD for amd64, arm, i386, i386/pc98, ia64, mips, powerpc, powerpc64, and sparc64. RELENG_9 and supported 9.X branches for amd64, arm, i386, i386/pc98, ia64, mips, powerpc, powerpc64, and sparc64. freebsd-stable.sentex.ca builds: RELENG_8 and supported 8.X branches for amd64, i386, i386/pc98, ia64, mips, powerpc and sparc64. freebsd-legacy.sentex.ca builds: RELENG_7 and supported 7.X branches for amd64, i386, i386/pc98, ia64, powerpc, and sparc64.

Official Summary Site Summaries and logs from the official build servers are available online at http://tinderbox.FreeBSD.org, - hosted by &a.des; and set up as follows: + hosted by &a.des.email; and set up as follows: A &man.cron.8; job checks the build servers at regular intervals and downloads any new log files using &man.rsync.1;. Apache is set up to use index.cgi as DirectoryIndex.

diff --git a/en_US.ISO8859-1/books/developers-handbook/x86/chapter.xml b/en_US.ISO8859-1/books/developers-handbook/x86/chapter.xml index dafbb31103..5f682a8a16 100644 --- a/en_US.ISO8859-1/books/developers-handbook/x86/chapter.xml +++ b/en_US.ISO8859-1/books/developers-handbook/x86/chapter.xml @@ -1,6487 +1,6487 @@ x86 Assembly Language Programming -This chapter was written by &a.stanislav;. +This chapter was written by &a.stanislav.email;. Synopsis Assembly language programming under &unix; is highly undocumented. It is generally assumed that no one would ever want to use it because various &unix; systems run on different microprocessors, so everything should be written in C for portability. In reality, C portability is quite a myth. Even C programs need to be modified when ported from one &unix; to another, regardless of what processor each runs on. Typically, such a program is full of conditional statements depending on the system it is compiled for. Even if we believe that all of &unix; software should be written in C, or some other high-level language, we still need assembly language programmers: Who else would write the section of C library that accesses the kernel? In this chapter I will attempt to show you how you can use assembly language writing &unix; programs, specifically under FreeBSD. This chapter does not explain the basics of assembly language. There are enough resources about that (for a complete online course in assembly language, see Randall Hyde's Art of Assembly Language; or if you prefer a printed book, take a look at Jeff Duntemann's Assembly Language Step-by-Step). However, once the chapter is finished, any assembly language programmer will be able to write programs for FreeBSD quickly and efficiently. Copyright © 2000-2001 G. Adam Stanislav. All rights reserved. The Tools The Assembler The most important tool for assembly language programming is the assembler, the software that converts assembly language code into machine language. Two very different assemblers are available for FreeBSD. One is as1, which uses the traditional &unix; assembly language syntax. It comes with the system. The other is /usr/ports/devel/nasm. It uses the Intel syntax. Its main advantage is that it can assemble code for many operating systems. It needs to be installed separately, but is completely free. This chapter uses nasm syntax because most assembly language programmers coming to FreeBSD from other operating systems will find it easier to understand. And, because, quite frankly, that is what I am used to. The Linker The output of the assembler, like that of any compiler, needs to be linked to form an executable file. The standard ld1 linker comes with FreeBSD. It works with the code assembled with either assembler. System Calls Default Calling Convention By default, the FreeBSD kernel uses the C calling convention. Further, although the kernel is accessed using int 80h, it is assumed the program will call a function that issues int 80h, rather than issuing int 80h directly. This convention is very convenient, and quite superior to the µsoft; convention used by &ms-dos;. Why? Because the &unix; convention allows any program written in any language to access the kernel. An assembly language program can do that as well. For example, we could open a file: kernel: int 80h ; Call kernel ret open: push dword mode push dword flags push dword path mov eax, 5 call kernel add esp, byte 12 ret This is a very clean and portable way of coding. If you need to port the code to a &unix; system which uses a different interrupt, or a different way of passing parameters, all you need to change is the kernel procedure. But assembly language programmers like to shave off cycles. The above example requires a call/ret combination. We can eliminate it by pushing an extra dword: open: push dword mode push dword flags push dword path mov eax, 5 push eax ; Or any other dword int 80h add esp, byte 16 The 5 that we have placed in EAX identifies the kernel function, in this case open. Alternate Calling Convention FreeBSD is an extremely flexible system. It offers other ways of calling the kernel. For it to work, however, the system must have Linux emulation installed. Linux is a &unix; like system. However, its kernel uses the same system-call convention of passing parameters in registers &ms-dos; does. As with the &unix; convention, the function number is placed in EAX. The parameters, however, are not passed on the stack but in EBX, ECX, EDX, ESI, EDI, EBP: open: mov eax, 5 mov ebx, path mov ecx, flags mov edx, mode int 80h This convention has a great disadvantage over the &unix; way, at least as far as assembly language programming is concerned: Every time you make a kernel call you must push the registers, then pop them later. This makes your code bulkier and slower. Nevertheless, FreeBSD gives you a choice. If you do choose the Linux convention, you must let the system know about it. After your program is assembled and linked, you need to brand the executable: &prompt.user; brandelf -t Linux filename Which Convention Should You Use? If you are coding specifically for FreeBSD, you should always use the &unix; convention: It is faster, you can store global variables in registers, you do not have to brand the executable, and you do not impose the installation of the Linux emulation package on the target system. If you want to create portable code that can also run on Linux, you will probably still want to give the FreeBSD users as efficient a code as possible. I will show you how you can accomplish that after I have explained the basics. Call Numbers To tell the kernel which system service you are calling, place its number in EAX. Of course, you need to know what the number is. The <filename>syscalls</filename> File The numbers are listed in syscalls. locate syscalls finds this file in several different formats, all produced automatically from syscalls.master. You can find the master file for the default &unix; calling convention in /usr/src/sys/kern/syscalls.master. If you need to use the other convention implemented in the Linux emulation mode, read /usr/src/sys/i386/linux/syscalls.master. Not only do FreeBSD and Linux use different calling conventions, they sometimes use different numbers for the same functions. syscalls.master describes how the call is to be made: 0 STD NOHIDE { int nosys(void); } syscall nosys_args int 1 STD NOHIDE { void exit(int rval); } exit rexit_args void 2 STD POSIX { int fork(void); } 3 STD POSIX { ssize_t read(int fd, void *buf, size_t nbyte); } 4 STD POSIX { ssize_t write(int fd, const void *buf, size_t nbyte); } 5 STD POSIX { int open(char *path, int flags, int mode); } 6 STD POSIX { int close(int fd); } etc... It is the leftmost column that tells us the number to place in EAX. The rightmost column tells us what parameters to push. They are pushed from right to left. For example, to open a file, we need to push the mode first, then flags, then the address at which the path is stored. Return Values A system call would not be useful most of the time if it did not return some kind of a value: The file descriptor of an open file, the number of bytes read to a buffer, the system time, etc. Additionally, the system needs to inform us if an error occurs: A file does not exist, system resources are exhausted, we passed an invalid parameter, etc. Man Pages The traditional place to look for information about various system calls under &unix; systems are the manual pages. FreeBSD describes its system calls in section 2, sometimes in section 3. For example, open2 says:

If successful, open() returns a non-negative integer, termed a file descriptor. It returns -1 on failure, and sets errno to indicate the error.

The assembly language programmer new to &unix; and FreeBSD will immediately ask the puzzling question: Where is errno and how do I get to it? The information presented in the manual pages applies to C programs. The assembly language programmer needs additional information. Where Are the Return Values? Unfortunately, it depends... For most system calls it is in EAX, but not for all. A good rule of thumb, when working with a system call for the first time, is to look for the return value in EAX. If it is not there, you need further research. I am aware of one system call that returns the value in EDX: SYS_fork. All others I have worked with use EAX. But I have not worked with them all yet. If you cannot find the answer here or anywhere else, study libc source code and see how it interfaces with the kernel. Where Is <varname>errno</varname>? Actually, nowhere... errno is part of the C language, not the &unix; kernel. When accessing kernel services directly, the error code is returned in EAX, the same register the proper return value generally ends up in. This makes perfect sense. If there is no error, there is no error code. If there is an error, there is no return value. One register can contain either. Determining an Error Occurred When using the standard FreeBSD calling convention, the carry flag is cleared upon success, set upon failure. When using the Linux emulation mode, the signed value in EAX is non-negative upon success, and contains the return value. In case of an error, the value is negative, i.e., -errno. Creating Portable Code Portability is generally not one of the strengths of assembly language. Yet, writing assembly language programs for different platforms is possible, especially with nasm. I have written assembly language libraries that can be assembled for such different operating systems as &windows; and FreeBSD. It is all the more possible when you want your code to run on two platforms which, while different, are based on similar architectures. For example, FreeBSD is &unix;, Linux is &unix; like. I only mentioned three differences between them (from an assembly language programmer's perspective): The calling convention, the function numbers, and the way of returning values. Dealing with Function Numbers In many cases the function numbers are the same. However, even when they are not, the problem is easy to deal with: Instead of using numbers in your code, use constants which you have declared differently depending on the target architecture: %ifdef LINUX %define SYS_execve 11 %else %define SYS_execve 59 %endif Dealing with Conventions Both, the calling convention, and the return value (the errno problem) can be resolved with macros: %ifdef LINUX %macro system 0 call kernel %endmacro align 4 kernel: push ebx push ecx push edx push esi push edi push ebp mov ebx, [esp+32] mov ecx, [esp+36] mov edx, [esp+40] mov esi, [esp+44] mov ebp, [esp+48] int 80h pop ebp pop edi pop esi pop edx pop ecx pop ebx or eax, eax js .errno clc ret .errno: neg eax stc ret %else %macro system 0 int 80h %endmacro %endif Dealing with Other Portability Issues The above solutions can handle most cases of writing code portable between FreeBSD and Linux. Nevertheless, with some kernel services the differences are deeper. In that case, you need to write two different handlers for those particular system calls, and use conditional assembly. Luckily, most of your code does something other than calling the kernel, so usually you will only need a few such conditional sections in your code. Using a Library You can avoid portability issues in your main code altogether by writing a library of system calls. Create a separate library for FreeBSD, a different one for Linux, and yet other libraries for more operating systems. In your library, write a separate function (or procedure, if you prefer the traditional assembly language terminology) for each system call. Use the C calling convention of passing parameters. But still use EAX to pass the call number in. In that case, your FreeBSD library can be very simple, as many seemingly different functions can be just labels to the same code: sys.open: sys.close: [etc...] int 80h ret Your Linux library will require more different functions. But even here you can group system calls using the same number of parameters: sys.exit: sys.close: [etc... one-parameter functions] push ebx mov ebx, [esp+12] int 80h pop ebx jmp sys.return ... sys.return: or eax, eax js sys.err clc ret sys.err: neg eax stc ret The library approach may seem inconvenient at first because it requires you to produce a separate file your code depends on. But it has many advantages: For one, you only need to write it once and can use it for all your programs. You can even let other assembly language programmers use it, or perhaps use one written by someone else. But perhaps the greatest advantage of the library is that your code can be ported to other systems, even by other programmers, by simply writing a new library without any changes to your code. If you do not like the idea of having a library, you can at least place all your system calls in a separate assembly language file and link it with your main program. Here, again, all porters have to do is create a new object file to link with your main program. Using an Include File If you are releasing your software as (or with) source code, you can use macros and place them in a separate file, which you include in your code. Porters of your software will simply write a new include file. No library or external object file is necessary, yet your code is portable without any need to edit the code. This is the approach we will use throughout this chapter. We will name our include file system.inc, and add to it whenever we deal with a new system call. We can start our system.inc by declaring the standard file descriptors: %define stdin 0 %define stdout 1 %define stderr 2 Next, we create a symbolic name for each system call: %define SYS_nosys 0 %define SYS_exit 1 %define SYS_fork 2 %define SYS_read 3 %define SYS_write 4 ; [etc...] We add a short, non-global procedure with a long name, so we do not accidentally reuse the name in our code: section .text align 4 access.the.bsd.kernel: int 80h ret We create a macro which takes one argument, the syscall number: %macro system 1 mov eax, %1 call access.the.bsd.kernel %endmacro Finally, we create macros for each syscall. These macros take no arguments. %macro sys.exit 0 system SYS_exit %endmacro %macro sys.fork 0 system SYS_fork %endmacro %macro sys.read 0 system SYS_read %endmacro %macro sys.write 0 system SYS_write %endmacro ; [etc...] Go ahead, enter it into your editor and save it as system.inc. We will add more to it as we discuss more syscalls. Our First Program We are now ready for our first program, the mandatory Hello, World! 1: %include 'system.inc' 2: 3: section .data 4: hello db 'Hello, World!', 0Ah 5: hbytes equ $-hello 6: 7: section .text 8: global _start 9: _start: 10: push dword hbytes 11: push dword hello 12: push dword stdout 13: sys.write 14: 15: push dword 0 16: sys.exit Here is what it does: Line 1 includes the defines, the macros, and the code from system.inc. Lines 3-5 are the data: Line 3 starts the data section/segment. Line 4 contains the string "Hello, World!" followed by a new line (0Ah). Line 5 creates a constant that contains the length of the string from line 4 in bytes. Lines 7-16 contain the code. Note that FreeBSD uses the elf file format for its executables, which requires every program to start at the point labeled _start (or, more precisely, the linker expects that). This label has to be global. Lines 10-13 ask the system to write hbytes bytes of the hello string to stdout. Lines 15-16 ask the system to end the program with the return value of 0. The SYS_exit syscall never returns, so the code ends there. If you have come to &unix; from &ms-dos; assembly language background, you may be used to writing directly to the video hardware. You will never have to worry about this in FreeBSD, or any other flavor of &unix;. As far as you are concerned, you are writing to a file known as stdout. This can be the video screen, or a telnet terminal, or an actual file, or even the input of another program. Which one it is, is for the system to figure out. Assembling the Code Type the code (except the line numbers) in an editor, and save it in a file named hello.asm. You need nasm to assemble it. Installing <application>nasm</application> If you do not have nasm, type: &prompt.user; su Password:your root password &prompt.root; cd /usr/ports/devel/nasm &prompt.root; make install &prompt.root; exit &prompt.user; You may type make install clean instead of just make install if you do not want to keep nasm source code. Either way, FreeBSD will automatically download nasm from the Internet, compile it, and install it on your system. If your system is not FreeBSD, you need to get nasm from its home page. You can still use it to assemble FreeBSD code. Now you can assemble, link, and run the code: &prompt.user; nasm -f elf hello.asm &prompt.user; ld -s -o hello hello.o &prompt.user; ./hello Hello, World! &prompt.user; Writing &unix; Filters A common type of &unix; application is a filter—a program that reads data from the stdin, processes it somehow, then writes the result to stdout. In this chapter, we shall develop a simple filter, and learn how to read from stdin and write to stdout. This filter will convert each byte of its input into a hexadecimal number followed by a blank space. %include 'system.inc' section .data hex db '0123456789ABCDEF' buffer db 0, 0, ' ' section .text global _start _start: ; read a byte from stdin push dword 1 push dword buffer push dword stdin sys.read add esp, byte 12 or eax, eax je .done ; convert it to hex movzx eax, byte [buffer] mov edx, eax shr dl, 4 mov dl, [hex+edx] mov [buffer], dl and al, 0Fh mov al, [hex+eax] mov [buffer+1], al ; print it push dword 3 push dword buffer push dword stdout sys.write add esp, byte 12 jmp short _start .done: push dword 0 sys.exit In the data section we create an array called hex. It contains the 16 hexadecimal digits in ascending order. The array is followed by a buffer which we will use for both input and output. The first two bytes of the buffer are initially set to 0. This is where we will write the two hexadecimal digits (the first byte also is where we will read the input). The third byte is a space. The code section consists of four parts: Reading the byte, converting it to a hexadecimal number, writing the result, and eventually exiting the program. To read the byte, we ask the system to read one byte from stdin, and store it in the first byte of the buffer. The system returns the number of bytes read in EAX. This will be 1 while data is coming, or 0, when no more input data is available. Therefore, we check the value of EAX. If it is 0, we jump to .done, otherwise we continue. For simplicity sake, we are ignoring the possibility of an error condition at this time. The hexadecimal conversion reads the byte from the buffer into EAX, or actually just AL, while clearing the remaining bits of EAX to zeros. We also copy the byte to EDX because we need to convert the upper four bits (nibble) separately from the lower four bits. We store the result in the first two bytes of the buffer. Next, we ask the system to write the three bytes of the buffer, i.e., the two hexadecimal digits and the blank space, to stdout. We then jump back to the beginning of the program and process the next byte. Once there is no more input left, we ask the system to exit our program, returning a zero, which is the traditional value meaning the program was successful. Go ahead, and save the code in a file named hex.asm, then type the following (the ^D means press the control key and type D while holding the control key down): &prompt.user; nasm -f elf hex.asm &prompt.user; ld -s -o hex hex.o &prompt.user; ./hex Hello, World! 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A Here I come! 48 65 72 65 20 49 20 63 6F 6D 65 21 0A ^D &prompt.user; If you are migrating to &unix; from &ms-dos;, you may be wondering why each line ends with 0A instead of 0D 0A. This is because &unix; does not use the cr/lf convention, but a "new line" convention, which is 0A in hexadecimal. Can we improve this? Well, for one, it is a bit confusing because once we have converted a line of text, our input no longer starts at the beginning of the line. We can modify it to print a new line instead of a space after each 0A: %include 'system.inc' section .data hex db '0123456789ABCDEF' buffer db 0, 0, ' ' section .text global _start _start: mov cl, ' ' .loop: ; read a byte from stdin push dword 1 push dword buffer push dword stdin sys.read add esp, byte 12 or eax, eax je .done ; convert it to hex movzx eax, byte [buffer] mov [buffer+2], cl cmp al, 0Ah jne .hex mov [buffer+2], al .hex: mov edx, eax shr dl, 4 mov dl, [hex+edx] mov [buffer], dl and al, 0Fh mov al, [hex+eax] mov [buffer+1], al ; print it push dword 3 push dword buffer push dword stdout sys.write add esp, byte 12 jmp short .loop .done: push dword 0 sys.exit We have stored the space in the CL register. We can do this safely because, unlike µsoft.windows;, &unix; system calls do not modify the value of any register they do not use to return a value in. That means we only need to set CL once. We have, therefore, added a new label .loop and jump to it for the next byte instead of jumping at _start. We have also added the .hex label so we can either have a blank space or a new line as the third byte of the buffer. Once you have changed hex.asm to reflect these changes, type: &prompt.user; nasm -f elf hex.asm &prompt.user; ld -s -o hex hex.o &prompt.user; ./hex Hello, World! 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A Here I come! 48 65 72 65 20 49 20 63 6F 6D 65 21 0A ^D &prompt.user; That looks better. But this code is quite inefficient! We are making a system call for every single byte twice (once to read it, another time to write the output). Buffered Input and Output We can improve the efficiency of our code by buffering our input and output. We create an input buffer and read a whole sequence of bytes at one time. Then we fetch them one by one from the buffer. We also create an output buffer. We store our output in it until it is full. At that time we ask the kernel to write the contents of the buffer to stdout. The program ends when there is no more input. But we still need to ask the kernel to write the contents of our output buffer to stdout one last time, otherwise some of our output would make it to the output buffer, but never be sent out. Do not forget that, or you will be wondering why some of your output is missing. %include 'system.inc' %define BUFSIZE 2048 section .data hex db '0123456789ABCDEF' section .bss ibuffer resb BUFSIZE obuffer resb BUFSIZE section .text global _start _start: sub eax, eax sub ebx, ebx sub ecx, ecx mov edi, obuffer .loop: ; read a byte from stdin call getchar ; convert it to hex mov dl, al shr al, 4 mov al, [hex+eax] call putchar mov al, dl and al, 0Fh mov al, [hex+eax] call putchar mov al, ' ' cmp dl, 0Ah jne .put mov al, dl .put: call putchar jmp short .loop align 4 getchar: or ebx, ebx jne .fetch call read .fetch: lodsb dec ebx ret read: push dword BUFSIZE mov esi, ibuffer push esi push dword stdin sys.read add esp, byte 12 mov ebx, eax or eax, eax je .done sub eax, eax ret align 4 .done: call write ; flush output buffer push dword 0 sys.exit align 4 putchar: stosb inc ecx cmp ecx, BUFSIZE je write ret align 4 write: sub edi, ecx ; start of buffer push ecx push edi push dword stdout sys.write add esp, byte 12 sub eax, eax sub ecx, ecx ; buffer is empty now ret We now have a third section in the source code, named .bss. This section is not included in our executable file, and, therefore, cannot be initialized. We use resb instead of db. It simply reserves the requested size of uninitialized memory for our use. We take advantage of the fact that the system does not modify the registers: We use registers for what, otherwise, would have to be global variables stored in the .data section. This is also why the &unix; convention of passing parameters to system calls on the stack is superior to the Microsoft convention of passing them in the registers: We can keep the registers for our own use. We use EDI and ESI as pointers to the next byte to be read from or written to. We use EBX and ECX to keep count of the number of bytes in the two buffers, so we know when to dump the output to, or read more input from, the system. Let us see how it works now: &prompt.user; nasm -f elf hex.asm &prompt.user; ld -s -o hex hex.o &prompt.user; ./hex Hello, World! Here I come! 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A 48 65 72 65 20 49 20 63 6F 6D 65 21 0A ^D &prompt.user; Not what you expected? The program did not print the output until we pressed ^D. That is easy to fix by inserting three lines of code to write the output every time we have converted a new line to 0A. I have marked the three lines with > (do not copy the > in your hex.asm). %include 'system.inc' %define BUFSIZE 2048 section .data hex db '0123456789ABCDEF' section .bss ibuffer resb BUFSIZE obuffer resb BUFSIZE section .text global _start _start: sub eax, eax sub ebx, ebx sub ecx, ecx mov edi, obuffer .loop: ; read a byte from stdin call getchar ; convert it to hex mov dl, al shr al, 4 mov al, [hex+eax] call putchar mov al, dl and al, 0Fh mov al, [hex+eax] call putchar mov al, ' ' cmp dl, 0Ah jne .put mov al, dl .put: call putchar > cmp al, 0Ah > jne .loop > call write jmp short .loop align 4 getchar: or ebx, ebx jne .fetch call read .fetch: lodsb dec ebx ret read: push dword BUFSIZE mov esi, ibuffer push esi push dword stdin sys.read add esp, byte 12 mov ebx, eax or eax, eax je .done sub eax, eax ret align 4 .done: call write ; flush output buffer push dword 0 sys.exit align 4 putchar: stosb inc ecx cmp ecx, BUFSIZE je write ret align 4 write: sub edi, ecx ; start of buffer push ecx push edi push dword stdout sys.write add esp, byte 12 sub eax, eax sub ecx, ecx ; buffer is empty now ret Now, let us see how it works: &prompt.user; nasm -f elf hex.asm &prompt.user; ld -s -o hex hex.o &prompt.user; ./hex Hello, World! 48 65 6C 6C 6F 2C 20 57 6F 72 6C 64 21 0A Here I come! 48 65 72 65 20 49 20 63 6F 6D 65 21 0A ^D &prompt.user; Not bad for a 644-byte executable, is it! This approach to buffered input/output still contains a hidden danger. I will discuss—and fix—it later, when I talk about the dark side of buffering. How to Unread a Character This may be a somewhat advanced topic, mostly of interest to programmers familiar with the theory of compilers. If you wish, you may skip to the next section, and perhaps read this later. While our sample program does not require it, more sophisticated filters often need to look ahead. In other words, they may need to see what the next character is (or even several characters). If the next character is of a certain value, it is part of the token currently being processed. Otherwise, it is not. For example, you may be parsing the input stream for a textual string (e.g., when implementing a language compiler): If a character is followed by another character, or perhaps a digit, it is part of the token you are processing. If it is followed by white space, or some other value, then it is not part of the current token. This presents an interesting problem: How to return the next character back to the input stream, so it can be read again later? One possible solution is to store it in a character variable, then set a flag. We can modify getchar to check the flag, and if it is set, fetch the byte from that variable instead of the input buffer, and reset the flag. But, of course, that slows us down. The C language has an ungetc() function, just for that purpose. Is there a quick way to implement it in our code? I would like you to scroll back up and take a look at the getchar procedure and see if you can find a nice and fast solution before reading the next paragraph. Then come back here and see my own solution. The key to returning a character back to the stream is in how we are getting the characters to start with: First we check if the buffer is empty by testing the value of EBX. If it is zero, we call the read procedure. If we do have a character available, we use lodsb, then decrease the value of EBX. The lodsb instruction is effectively identical to: mov al, [esi] inc esi The byte we have fetched remains in the buffer until the next time read is called. We do not know when that happens, but we do know it will not happen until the next call to getchar. Hence, to "return" the last-read byte back to the stream, all we have to do is decrease the value of ESI and increase the value of EBX: ungetc: dec esi inc ebx ret But, be careful! We are perfectly safe doing this if our look-ahead is at most one character at a time. If we are examining more than one upcoming character and call ungetc several times in a row, it will work most of the time, but not all the time (and will be tough to debug). Why? Because as long as getchar does not have to call read, all of the pre-read bytes are still in the buffer, and our ungetc works without a glitch. But the moment getchar calls read, the contents of the buffer change. We can always rely on ungetc working properly on the last character we have read with getchar, but not on anything we have read before that. If your program reads more than one byte ahead, you have at least two choices: If possible, modify the program so it only reads one byte ahead. This is the simplest solution. If that option is not available, first of all determine the maximum number of characters your program needs to return to the input stream at one time. Increase that number slightly, just to be sure, preferably to a multiple of 16—so it aligns nicely. Then modify the .bss section of your code, and create a small "spare" buffer right before your input buffer, something like this: section .bss resb 16 ; or whatever the value you came up with ibuffer resb BUFSIZE obuffer resb BUFSIZE You also need to modify your ungetc to pass the value of the byte to unget in AL: ungetc: dec esi inc ebx mov [esi], al ret With this modification, you can call ungetc up to 17 times in a row safely (the first call will still be within the buffer, the remaining 16 may be either within the buffer or within the "spare"). Command Line Arguments Our hex program will be more useful if it can read the names of an input and output file from its command line, i.e., if it can process the command line arguments. But... Where are they? Before a &unix; system starts a program, it pushes some data on the stack, then jumps at the _start label of the program. Yes, I said jumps, not calls. That means the data can be accessed by reading [esp+offset], or by simply popping it. The value at the top of the stack contains the number of command line arguments. It is traditionally called argc, for "argument count." Command line arguments follow next, all argc of them. These are typically referred to as argv, for "argument value(s)." That is, we get argv[0], argv[1], ..., argv[argc-1]. These are not the actual arguments, but pointers to arguments, i.e., memory addresses of the actual arguments. The arguments themselves are NUL-terminated character strings. The argv list is followed by a NULL pointer, which is simply a 0. There is more, but this is enough for our purposes right now. If you have come from the &ms-dos; programming environment, the main difference is that each argument is in a separate string. The second difference is that there is no practical limit on how many arguments there can be. Armed with this knowledge, we are almost ready for the next version of hex.asm. First, however, we need to add a few lines to system.inc: First, we need to add two new entries to our list of system call numbers: %define SYS_open 5 %define SYS_close 6 Then we add two new macros at the end of the file: %macro sys.open 0 system SYS_open %endmacro %macro sys.close 0 system SYS_close %endmacro Here, then, is our modified source code: %include 'system.inc' %define BUFSIZE 2048 section .data fd.in dd stdin fd.out dd stdout hex db '0123456789ABCDEF' section .bss ibuffer resb BUFSIZE obuffer resb BUFSIZE section .text align 4 err: push dword 1 ; return failure sys.exit align 4 global _start _start: add esp, byte 8 ; discard argc and argv[0] pop ecx jecxz .init ; no more arguments ; ECX contains the path to input file push dword 0 ; O_RDONLY push ecx sys.open jc err ; open failed add esp, byte 8 mov [fd.in], eax pop ecx jecxz .init ; no more arguments ; ECX contains the path to output file push dword 420 ; file mode (644 octal) push dword 0200h | 0400h | 01h ; O_CREAT | O_TRUNC | O_WRONLY push ecx sys.open jc err add esp, byte 12 mov [fd.out], eax .init: sub eax, eax sub ebx, ebx sub ecx, ecx mov edi, obuffer .loop: ; read a byte from input file or stdin call getchar ; convert it to hex mov dl, al shr al, 4 mov al, [hex+eax] call putchar mov al, dl and al, 0Fh mov al, [hex+eax] call putchar mov al, ' ' cmp dl, 0Ah jne .put mov al, dl .put: call putchar cmp al, dl jne .loop call write jmp short .loop align 4 getchar: or ebx, ebx jne .fetch call read .fetch: lodsb dec ebx ret read: push dword BUFSIZE mov esi, ibuffer push esi push dword [fd.in] sys.read add esp, byte 12 mov ebx, eax or eax, eax je .done sub eax, eax ret align 4 .done: call write ; flush output buffer ; close files push dword [fd.in] sys.close push dword [fd.out] sys.close ; return success push dword 0 sys.exit align 4 putchar: stosb inc ecx cmp ecx, BUFSIZE je write ret align 4 write: sub edi, ecx ; start of buffer push ecx push edi push dword [fd.out] sys.write add esp, byte 12 sub eax, eax sub ecx, ecx ; buffer is empty now ret In our .data section we now have two new variables, fd.in and fd.out. We store the input and output file descriptors here. In the .text section we have replaced the references to stdin and stdout with [fd.in] and [fd.out]. The .text section now starts with a simple error handler, which does nothing but exit the program with a return value of 1. The error handler is before _start so we are within a short distance from where the errors occur. Naturally, the program execution still begins at _start. First, we remove argc and argv[0] from the stack: They are of no interest to us (in this program, that is). We pop argv[1] to ECX. This register is particularly suited for pointers, as we can handle NULL pointers with jecxz. If argv[1] is not NULL, we try to open the file named in the first argument. Otherwise, we continue the program as before: Reading from stdin, writing to stdout. If we fail to open the input file (e.g., it does not exist), we jump to the error handler and quit. If all went well, we now check for the second argument. If it is there, we open the output file. Otherwise, we send the output to stdout. If we fail to open the output file (e.g., it exists and we do not have the write permission), we, again, jump to the error handler. The rest of the code is the same as before, except we close the input and output files before exiting, and, as mentioned, we use [fd.in] and [fd.out]. Our executable is now a whopping 768 bytes long. Can we still improve it? Of course! Every program can be improved. Here are a few ideas of what we could do: Have our error handler print a message to stderr. Add error handlers to the read and write functions. Close stdin when we open an input file, stdout when we open an output file. Add command line switches, such as -i and -o, so we can list the input and output files in any order, or perhaps read from stdin and write to a file. Print a usage message if command line arguments are incorrect. I shall leave these enhancements as an exercise to the reader: You already know everything you need to know to implement them. &unix; Environment An important &unix; concept is the environment, which is defined by environment variables. Some are set by the system, others by you, yet others by the shell, or any program that loads another program. How to Find Environment Variables I said earlier that when a program starts executing, the stack contains argc followed by the NULL-terminated argv array, followed by something else. The "something else" is the environment, or, to be more precise, a NULL-terminated array of pointers to environment variables. This is often referred to as env. The structure of env is the same as that of argv, a list of memory addresses followed by a NULL (0). In this case, there is no "envc"—we figure out where the array ends by searching for the final NULL. The variables usually come in the name=value format, but sometimes the =value part may be missing. We need to account for that possibility. webvars I could just show you some code that prints the environment the same way the &unix; env command does. But I thought it would be more interesting to write a simple assembly language CGI utility. CGI: A Quick Overview I have a detailed CGI tutorial on my web site, but here is a very quick overview of CGI: The web server communicates with the CGI program by setting environment variables. The CGI program sends its output to stdout. The web server reads it from there. It must start with an HTTP header followed by two blank lines. It then prints the HTML code, or whatever other type of data it is producing. While certain environment variables use standard names, others vary, depending on the web server. That makes webvars quite a useful diagnostic tool. The Code Our webvars program, then, must send out the HTTP header followed by some HTML mark-up. It then must read the environment variables one by one and send them out as part of the HTML page. The code follows. I placed comments and explanations right inside the code: ;;;;;;; webvars.asm ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Copyright (c) 2000 G. Adam Stanislav ; All rights reserved. ; ; Redistribution and use in source and binary forms, with or without ; modification, are permitted provided that the following conditions ; are met: ; 1. Redistributions of source code must retain the above copyright ; notice, this list of conditions and the following disclaimer. ; 2. Redistributions in binary form must reproduce the above copyright ; notice, this list of conditions and the following disclaimer in the ; documentation and/or other materials provided with the distribution. ; ; THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ; ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE ; IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ; ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE ; FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL ; DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS ; OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) ; HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT ; LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY ; OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF ; SUCH DAMAGE. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Version 1.0 ; ; Started: 8-Dec-2000 ; Updated: 8-Dec-2000 ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; %include 'system.inc' section .data http db 'Content-type: text/html', 0Ah, 0Ah db '<?xml version="1.0" encoding="utf-8"?>', 0Ah db '<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Strict//EN" ' db '"DTD/xhtml1-strict.dtd">', 0Ah db '<html xmlns="http://www.w3.org/1999/xhtml" ' db 'xml.lang="en" lang="en">', 0Ah db '<head>', 0Ah db '<title>Web Environment</title>', 0Ah db '<meta name="author" content="G. Adam Stanislav" />', 0Ah db '</head>', 0Ah, 0Ah db '<body bgcolor="#ffffff" text="#000000" link="#0000ff" ' db 'vlink="#840084" alink="#0000ff">', 0Ah db '<div class="webvars">', 0Ah db '<h1>Web Environment</h1>', 0Ah db '<p>The following <b>environment variables</b> are defined ' db 'on this web server:</p>', 0Ah, 0Ah db '<table align="center" width="80" border="0" cellpadding="10" ' db 'cellspacing="0" class="webvars">', 0Ah httplen equ $-http left db '<tr>', 0Ah db '<td class="name"><tt>' leftlen equ $-left middle db '</tt></td>', 0Ah db '<td class="value"><tt><b>' midlen equ $-middle undef db '<i>(undefined)</i>' undeflen equ $-undef right db '</b></tt></td>', 0Ah db '</tr>', 0Ah rightlen equ $-right wrap db '</table>', 0Ah db '</div>', 0Ah db '</body>', 0Ah db '</html>', 0Ah, 0Ah wraplen equ $-wrap section .text global _start _start: ; First, send out all the http and xhtml stuff that is ; needed before we start showing the environment push dword httplen push dword http push dword stdout sys.write ; Now find how far on the stack the environment pointers ; are. We have 12 bytes we have pushed before "argc" mov eax, [esp+12] ; We need to remove the following from the stack: ; ; The 12 bytes we pushed for sys.write ; The 4 bytes of argc ; The EAX*4 bytes of argv ; The 4 bytes of the NULL after argv ; ; Total: ; 20 + eax * 4 ; ; Because stack grows down, we need to ADD that many bytes ; to ESP. lea esp, [esp+20+eax*4] cld ; This should already be the case, but let's be sure. ; Loop through the environment, printing it out .loop: pop edi or edi, edi ; Done yet? je near .wrap ; Print the left part of HTML push dword leftlen push dword left push dword stdout sys.write ; It may be tempting to search for the '=' in the env string next. ; But it is possible there is no '=', so we search for the ; terminating NUL first. mov esi, edi ; Save start of string sub ecx, ecx not ecx ; ECX = FFFFFFFF sub eax, eax repne scasb not ecx ; ECX = string length + 1 mov ebx, ecx ; Save it in EBX ; Now is the time to find '=' mov edi, esi ; Start of string mov al, '=' repne scasb not ecx add ecx, ebx ; Length of name push ecx push esi push dword stdout sys.write ; Print the middle part of HTML table code push dword midlen push dword middle push dword stdout sys.write ; Find the length of the value not ecx lea ebx, [ebx+ecx-1] ; Print "undefined" if 0 or ebx, ebx jne .value mov ebx, undeflen mov edi, undef .value: push ebx push edi push dword stdout sys.write ; Print the right part of the table row push dword rightlen push dword right push dword stdout sys.write ; Get rid of the 60 bytes we have pushed add esp, byte 60 ; Get the next variable jmp .loop .wrap: ; Print the rest of HTML push dword wraplen push dword wrap push dword stdout sys.write ; Return success push dword 0 sys.exit This code produces a 1,396-byte executable. Most of it is data, i.e., the HTML mark-up we need to send out. Assemble and link it as usual: &prompt.user; nasm -f elf webvars.asm &prompt.user; ld -s -o webvars webvars.o To use it, you need to upload webvars to your web server. Depending on how your web server is set up, you may have to store it in a special cgi-bin directory, or perhaps rename it with a .cgi extension. Then you need to use your browser to view its output. To see its output on my web server, please go to http://www.int80h.org/webvars/. If curious about the additional environment variables present in a password protected web directory, go to http://www.int80h.org/private/, using the name asm and password programmer. Working with Files We have already done some basic file work: We know how to open and close them, how to read and write them using buffers. But &unix; offers much more functionality when it comes to files. We will examine some of it in this section, and end up with a nice file conversion utility. Indeed, let us start at the end, that is, with the file conversion utility. It always makes programming easier when we know from the start what the end product is supposed to do. One of the first programs I wrote for &unix; was tuc, a text-to-&unix; file converter. It converts a text file from other operating systems to a &unix; text file. In other words, it changes from different kind of line endings to the newline convention of &unix;. It saves the output in a different file. Optionally, it converts a &unix; text file to a DOS text file. I have used tuc extensively, but always only to convert from some other OS to &unix;, never the other way. I have always wished it would just overwrite the file instead of me having to send the output to a different file. Most of the time, I end up using it like this: &prompt.user; tuc myfile tempfile &prompt.user; mv tempfile myfile It would be nice to have a ftuc, i.e., fast tuc, and use it like this: &prompt.user; ftuc myfile In this chapter, then, we will write ftuc in assembly language (the original tuc is in C), and study various file-oriented kernel services in the process. At first sight, such a file conversion is very simple: All you have to do is strip the carriage returns, right? If you answered yes, think again: That approach will work most of the time (at least with MS DOS text files), but will fail occasionally. The problem is that not all non &unix; text files end their line with the carriage return / line feed sequence. Some use carriage returns without line feeds. Others combine several blank lines into a single carriage return followed by several line feeds. And so on. A text file converter, then, must be able to handle any possible line endings: carriage return / line feed carriage return line feed / carriage return line feed It should also handle files that use some kind of a combination of the above (e.g., carriage return followed by several line feeds). Finite State Machine The problem is easily solved by the use of a technique called finite state machine, originally developed by the designers of digital electronic circuits. A finite state machine is a digital circuit whose output is dependent not only on its input but on its previous input, i.e., on its state. The microprocessor is an example of a finite state machine: Our assembly language code is assembled to machine language in which some assembly language code produces a single byte of machine language, while others produce several bytes. As the microprocessor fetches the bytes from the memory one by one, some of them simply change its state rather than produce some output. When all the bytes of the op code are fetched, the microprocessor produces some output, or changes the value of a register, etc. Because of that, all software is essentially a sequence of state instructions for the microprocessor. Nevertheless, the concept of finite state machine is useful in software design as well. Our text file converter can be designed as a finite state machine with three possible states. We could call them states 0-2, but it will make our life easier if we give them symbolic names: ordinary cr lf Our program will start in the ordinary state. During this state, the program action depends on its input as follows: If the input is anything other than a carriage return or line feed, the input is simply passed on to the output. The state remains unchanged. If the input is a carriage return, the state is changed to cr. The input is then discarded, i.e., no output is made. If the input is a line feed, the state is changed to lf. The input is then discarded. Whenever we are in the cr state, it is because the last input was a carriage return, which was unprocessed. What our software does in this state again depends on the current input: If the input is anything other than a carriage return or line feed, output a line feed, then output the input, then change the state to ordinary. If the input is a carriage return, we have received two (or more) carriage returns in a row. We discard the input, we output a line feed, and leave the state unchanged. If the input is a line feed, we output the line feed and change the state to ordinary. Note that this is not the same as the first case above – if we tried to combine them, we would be outputting two line feeds instead of one. Finally, we are in the lf state after we have received a line feed that was not preceded by a carriage return. This will happen when our file already is in &unix; format, or whenever several lines in a row are expressed by a single carriage return followed by several line feeds, or when line ends with a line feed / carriage return sequence. Here is how we need to handle our input in this state: If the input is anything other than a carriage return or line feed, we output a line feed, then output the input, then change the state to ordinary. This is exactly the same action as in the cr state upon receiving the same kind of input. If the input is a carriage return, we discard the input, we output a line feed, then change the state to ordinary. If the input is a line feed, we output the line feed, and leave the state unchanged. The Final State The above finite state machine works for the entire file, but leaves the possibility that the final line end will be ignored. That will happen whenever the file ends with a single carriage return or a single line feed. I did not think of it when I wrote tuc, just to discover that occasionally it strips the last line ending. This problem is easily fixed by checking the state after the entire file was processed. If the state is not ordinary, we simply need to output one last line feed. Now that we have expressed our algorithm as a finite state machine, we could easily design a dedicated digital electronic circuit (a "chip") to do the conversion for us. Of course, doing so would be considerably more expensive than writing an assembly language program. The Output Counter Because our file conversion program may be combining two characters into one, we need to use an output counter. We initialize it to 0, and increase it every time we send a character to the output. At the end of the program, the counter will tell us what size we need to set the file to. Implementing FSM in Software The hardest part of working with a finite state machine is analyzing the problem and expressing it as a finite state machine. That accomplished, the software almost writes itself. In a high-level language, such as C, there are several main approaches. One is to use a switch statement which chooses what function should be run. For example, switch (state) { default: case REGULAR: regular(inputchar); break; case CR: cr(inputchar); break; case LF: lf(inputchar); break; } Another approach is by using an array of function pointers, something like this: (output[state])(inputchar); Yet another is to have state be a function pointer, set to point at the appropriate function: (*state)(inputchar); This is the approach we will use in our program because it is very easy to do in assembly language, and very fast, too. We will simply keep the address of the right procedure in EBX, and then just issue: call ebx This is possibly faster than hardcoding the address in the code because the microprocessor does not have to fetch the address from the memory—it is already stored in one of its registers. I said possibly because with the caching modern microprocessors do, either way may be equally fast. Memory Mapped Files Because our program works on a single file, we cannot use the approach that worked for us before, i.e., to read from an input file and to write to an output file. &unix; allows us to map a file, or a section of a file, into memory. To do that, we first need to open the file with the appropriate read/write flags. Then we use the mmap system call to map it into the memory. One nice thing about mmap is that it automatically works with virtual memory: We can map more of the file into the memory than we have physical memory available, yet still access it through regular memory op codes, such as mov, lods, and stos. Whatever changes we make to the memory image of the file will be written to the file by the system. We do not even have to keep the file open: As long as it stays mapped, we can read from it and write to it. The 32-bit Intel microprocessors can access up to four gigabytes of memory – physical or virtual. The FreeBSD system allows us to use up to a half of it for file mapping. For simplicity sake, in this tutorial we will only convert files that can be mapped into the memory in their entirety. There are probably not too many text files that exceed two gigabytes in size. If our program encounters one, it will simply display a message suggesting we use the original tuc instead. If you examine your copy of syscalls.master, you will find two separate syscalls named mmap. This is because of evolution of &unix;: There was the traditional BSD mmap, syscall 71. That one was superseded by the &posix; mmap, syscall 197. The FreeBSD system supports both because older programs were written by using the original BSD version. But new software uses the &posix; version, which is what we will use. The syscalls.master file lists the &posix; version like this: 197 STD BSD { caddr_t mmap(caddr_t addr, size_t len, int prot, \ int flags, int fd, long pad, off_t pos); } This differs slightly from what mmap2 says. That is because mmap2 describes the C version. The difference is in the long pad argument, which is not present in the C version. However, the FreeBSD syscalls add a 32-bit pad after pushing a 64-bit argument. In this case, off_t is a 64-bit value. When we are finished working with a memory-mapped file, we unmap it with the munmap syscall: For an in-depth treatment of mmap, see W. Richard Stevens' Unix Network Programming, Volume 2, Chapter 12. Determining File Size Because we need to tell mmap how many bytes of the file to map into the memory, and because we want to map the entire file, we need to determine the size of the file. We can use the fstat syscall to get all the information about an open file that the system can give us. That includes the file size. Again, syscalls.master lists two versions of fstat, a traditional one (syscall 62), and a &posix; one (syscall 189). Naturally, we will use the &posix; version: 189 STD POSIX { int fstat(int fd, struct stat *sb); } This is a very straightforward call: We pass to it the address of a stat structure and the descriptor of an open file. It will fill out the contents of the stat structure. I do, however, have to say that I tried to declare the stat structure in the .bss section, and fstat did not like it: It set the carry flag indicating an error. After I changed the code to allocate the structure on the stack, everything was working fine. Changing the File Size Because our program may combine carriage return / line feed sequences into straight line feeds, our output may be smaller than our input. However, since we are placing our output into the same file we read the input from, we may have to change the size of the file. The ftruncate system call allows us to do just that. Despite its somewhat misleading name, the ftruncate system call can be used to both truncate the file (make it smaller) and to grow it. And yes, we will find two versions of ftruncate in syscalls.master, an older one (130), and a newer one (201). We will use the newer one: 201 STD BSD { int ftruncate(int fd, int pad, off_t length); } Please note that this one contains a int pad again. ftuc We now know everything we need to write ftuc. We start by adding some new lines in system.inc. First, we define some constants and structures, somewhere at or near the beginning of the file: ;;;;;;; open flags %define O_RDONLY 0 %define O_WRONLY 1 %define O_RDWR 2 ;;;;;;; mmap flags %define PROT_NONE 0 %define PROT_READ 1 %define PROT_WRITE 2 %define PROT_EXEC 4 ;; %define MAP_SHARED 0001h %define MAP_PRIVATE 0002h ;;;;;;; stat structure struc stat st_dev resd 1 ; = 0 st_ino resd 1 ; = 4 st_mode resw 1 ; = 8, size is 16 bits st_nlink resw 1 ; = 10, ditto st_uid resd 1 ; = 12 st_gid resd 1 ; = 16 st_rdev resd 1 ; = 20 st_atime resd 1 ; = 24 st_atimensec resd 1 ; = 28 st_mtime resd 1 ; = 32 st_mtimensec resd 1 ; = 36 st_ctime resd 1 ; = 40 st_ctimensec resd 1 ; = 44 st_size resd 2 ; = 48, size is 64 bits st_blocks resd 2 ; = 56, ditto st_blksize resd 1 ; = 64 st_flags resd 1 ; = 68 st_gen resd 1 ; = 72 st_lspare resd 1 ; = 76 st_qspare resd 4 ; = 80 endstruc We define the new syscalls: %define SYS_mmap 197 %define SYS_munmap 73 %define SYS_fstat 189 %define SYS_ftruncate 201 We add the macros for their use: %macro sys.mmap 0 system SYS_mmap %endmacro %macro sys.munmap 0 system SYS_munmap %endmacro %macro sys.ftruncate 0 system SYS_ftruncate %endmacro %macro sys.fstat 0 system SYS_fstat %endmacro And here is our code: ;;;;;;; Fast Text-to-Unix Conversion (ftuc.asm) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Started: 21-Dec-2000 ;; Updated: 22-Dec-2000 ;; ;; Copyright 2000 G. Adam Stanislav. ;; All rights reserved. ;; ;;;;;;; v.1 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; %include 'system.inc' section .data db 'Copyright 2000 G. Adam Stanislav.', 0Ah db 'All rights reserved.', 0Ah usg db 'Usage: ftuc filename', 0Ah usglen equ $-usg co db "ftuc: Can't open file.", 0Ah colen equ $-co fae db 'ftuc: File access error.', 0Ah faelen equ $-fae ftl db 'ftuc: File too long, use regular tuc instead.', 0Ah ftllen equ $-ftl mae db 'ftuc: Memory allocation error.', 0Ah maelen equ $-mae section .text align 4 memerr: push dword maelen push dword mae jmp short error align 4 toolong: push dword ftllen push dword ftl jmp short error align 4 facerr: push dword faelen push dword fae jmp short error align 4 cantopen: push dword colen push dword co jmp short error align 4 usage: push dword usglen push dword usg error: push dword stderr sys.write push dword 1 sys.exit align 4 global _start _start: pop eax ; argc pop eax ; program name pop ecx ; file to convert jecxz usage pop eax or eax, eax ; Too many arguments? jne usage ; Open the file push dword O_RDWR push ecx sys.open jc cantopen mov ebp, eax ; Save fd sub esp, byte stat_size mov ebx, esp ; Find file size push ebx push ebp ; fd sys.fstat jc facerr mov edx, [ebx + st_size + 4] ; File is too long if EDX != 0 ... or edx, edx jne near toolong mov ecx, [ebx + st_size] ; ... or if it is above 2 GB or ecx, ecx js near toolong ; Do nothing if the file is 0 bytes in size jecxz .quit ; Map the entire file in memory push edx push edx ; starting at offset 0 push edx ; pad push ebp ; fd push dword MAP_SHARED push dword PROT_READ | PROT_WRITE push ecx ; entire file size push edx ; let system decide on the address sys.mmap jc near memerr mov edi, eax mov esi, eax push ecx ; for SYS_munmap push edi ; Use EBX for state machine mov ebx, ordinary mov ah, 0Ah cld .loop: lodsb call ebx loop .loop cmp ebx, ordinary je .filesize ; Output final lf mov al, ah stosb inc edx .filesize: ; truncate file to new size push dword 0 ; high dword push edx ; low dword push eax ; pad push ebp sys.ftruncate ; close it (ebp still pushed) sys.close add esp, byte 16 sys.munmap .quit: push dword 0 sys.exit align 4 ordinary: cmp al, 0Dh je .cr cmp al, ah je .lf stosb inc edx ret align 4 .cr: mov ebx, cr ret align 4 .lf: mov ebx, lf ret align 4 cr: cmp al, 0Dh je .cr cmp al, ah je .lf xchg al, ah stosb inc edx xchg al, ah ; fall through .lf: stosb inc edx mov ebx, ordinary ret align 4 .cr: mov al, ah stosb inc edx ret align 4 lf: cmp al, ah je .lf cmp al, 0Dh je .cr xchg al, ah stosb inc edx xchg al, ah stosb inc edx mov ebx, ordinary ret align 4 .cr: mov ebx, ordinary mov al, ah ; fall through .lf: stosb inc edx ret Do not use this program on files stored on a disk formatted by &ms-dos; or &windows;. There seems to be a subtle bug in the FreeBSD code when using mmap on these drives mounted under FreeBSD: If the file is over a certain size, mmap will just fill the memory with zeros, and then copy them to the file overwriting its contents. One-Pointed Mind As a student of Zen, I like the idea of a one-pointed mind: Do one thing at a time, and do it well. This, indeed, is very much how &unix; works as well. While a typical &windows; application is attempting to do everything imaginable (and is, therefore, riddled with bugs), a typical &unix; program does only one thing, and it does it well. The typical &unix; user then essentially assembles his own applications by writing a shell script which combines the various existing programs by piping the output of one program to the input of another. When writing your own &unix; software, it is generally a good idea to see what parts of the problem you need to solve can be handled by existing programs, and only write your own programs for that part of the problem that you do not have an existing solution for. CSV I will illustrate this principle with a specific real-life example I was faced with recently: I needed to extract the 11th field of each record from a database I downloaded from a web site. The database was a CSV file, i.e., a list of comma-separated values. That is quite a standard format for sharing data among people who may be using different database software. The first line of the file contains the list of various fields separated by commas. The rest of the file contains the data listed line by line, with values separated by commas. I tried awk, using the comma as a separator. But because several lines contained a quoted comma, awk was extracting the wrong field from those lines. Therefore, I needed to write my own software to extract the 11th field from the CSV file. However, going with the &unix; spirit, I only needed to write a simple filter that would do the following: Remove the first line from the file; Change all unquoted commas to a different character; Remove all quotation marks. Strictly speaking, I could use sed to remove the first line from the file, but doing so in my own program was very easy, so I decided to do it and reduce the size of the pipeline. At any rate, writing a program like this took me about 20 minutes. Writing a program that extracts the 11th field from the CSV file would take a lot longer, and I could not reuse it to extract some other field from some other database. This time I decided to let it do a little more work than a typical tutorial program would: It parses its command line for options; It displays proper usage if it finds wrong arguments; It produces meaningful error messages. Here is its usage message: Usage: csv [-t<delim>] [-c<comma>] [-p] [-o <outfile>] [-i <infile>] All parameters are optional, and can appear in any order. The -t parameter declares what to replace the commas with. The tab is the default here. For example, -t; will replace all unquoted commas with semicolons. I did not need the -c option, but it may come in handy in the future. It lets me declare that I want a character other than a comma replaced with something else. For example, -c@ will replace all at signs (useful if you want to split a list of email addresses to their user names and domains). The -p option preserves the first line, i.e., it does not delete it. By default, we delete the first line because in a CSV file it contains the field names rather than data. The -i and -o options let me specify the input and the output files. Defaults are stdin and stdout, so this is a regular &unix; filter. I made sure that both -i filename and -ifilename are accepted. I also made sure that only one input and one output files may be specified. To get the 11th field of each record, I can now do: &prompt.user; csv '-t;' data.csv | awk '-F;' '{print $11}' The code stores the options (except for the file descriptors) in EDX: The comma in DH, the new separator in DL, and the flag for the -p option in the highest bit of EDX, so a check for its sign will give us a quick decision what to do. Here is the code: ;;;;;;; csv.asm ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Convert a comma-separated file to a something-else separated file. ; ; Started: 31-May-2001 ; Updated: 1-Jun-2001 ; ; Copyright (c) 2001 G. Adam Stanislav ; All rights reserved. ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; %include 'system.inc' %define BUFSIZE 2048 section .data fd.in dd stdin fd.out dd stdout usg db 'Usage: csv [-t<delim>] [-c<comma>] [-p] [-o <outfile>] [-i <infile>]', 0Ah usglen equ $-usg iemsg db "csv: Can't open input file", 0Ah iemlen equ $-iemsg oemsg db "csv: Can't create output file", 0Ah oemlen equ $-oemsg section .bss ibuffer resb BUFSIZE obuffer resb BUFSIZE section .text align 4 ierr: push dword iemlen push dword iemsg push dword stderr sys.write push dword 1 ; return failure sys.exit align 4 oerr: push dword oemlen push dword oemsg push dword stderr sys.write push dword 2 sys.exit align 4 usage: push dword usglen push dword usg push dword stderr sys.write push dword 3 sys.exit align 4 global _start _start: add esp, byte 8 ; discard argc and argv[0] mov edx, (',' << 8) | 9 .arg: pop ecx or ecx, ecx je near .init ; no more arguments ; ECX contains the pointer to an argument cmp byte [ecx], '-' jne usage inc ecx mov ax, [ecx] .o: cmp al, 'o' jne .i ; Make sure we are not asked for the output file twice cmp dword [fd.out], stdout jne usage ; Find the path to output file - it is either at [ECX+1], ; i.e., -ofile -- ; or in the next argument, ; i.e., -o file inc ecx or ah, ah jne .openoutput pop ecx jecxz usage .openoutput: push dword 420 ; file mode (644 octal) push dword 0200h | 0400h | 01h ; O_CREAT | O_TRUNC | O_WRONLY push ecx sys.open jc near oerr add esp, byte 12 mov [fd.out], eax jmp short .arg .i: cmp al, 'i' jne .p ; Make sure we are not asked twice cmp dword [fd.in], stdin jne near usage ; Find the path to the input file inc ecx or ah, ah jne .openinput pop ecx or ecx, ecx je near usage .openinput: push dword 0 ; O_RDONLY push ecx sys.open jc near ierr ; open failed add esp, byte 8 mov [fd.in], eax jmp .arg .p: cmp al, 'p' jne .t or ah, ah jne near usage or edx, 1 << 31 jmp .arg .t: cmp al, 't' ; redefine output delimiter jne .c or ah, ah je near usage mov dl, ah jmp .arg .c: cmp al, 'c' jne near usage or ah, ah je near usage mov dh, ah jmp .arg align 4 .init: sub eax, eax sub ebx, ebx sub ecx, ecx mov edi, obuffer ; See if we are to preserve the first line or edx, edx js .loop .firstline: ; get rid of the first line call getchar cmp al, 0Ah jne .firstline .loop: ; read a byte from stdin call getchar ; is it a comma (or whatever the user asked for)? cmp al, dh jne .quote ; Replace the comma with a tab (or whatever the user wants) mov al, dl .put: call putchar jmp short .loop .quote: cmp al, '"' jne .put ; Print everything until you get another quote or EOL. If it ; is a quote, skip it. If it is EOL, print it. .qloop: call getchar cmp al, '"' je .loop cmp al, 0Ah je .put call putchar jmp short .qloop align 4 getchar: or ebx, ebx jne .fetch call read .fetch: lodsb dec ebx ret read: jecxz .read call write .read: push dword BUFSIZE mov esi, ibuffer push esi push dword [fd.in] sys.read add esp, byte 12 mov ebx, eax or eax, eax je .done sub eax, eax ret align 4 .done: call write ; flush output buffer ; close files push dword [fd.in] sys.close push dword [fd.out] sys.close ; return success push dword 0 sys.exit align 4 putchar: stosb inc ecx cmp ecx, BUFSIZE je write ret align 4 write: jecxz .ret ; nothing to write sub edi, ecx ; start of buffer push ecx push edi push dword [fd.out] sys.write add esp, byte 12 sub eax, eax sub ecx, ecx ; buffer is empty now .ret: ret Much of it is taken from hex.asm above. But there is one important difference: I no longer call write whenever I am outputting a line feed. Yet, the code can be used interactively. I have found a better solution for the interactive problem since I first started writing this chapter. I wanted to make sure each line is printed out separately only when needed. After all, there is no need to flush out every line when used non-interactively. The new solution I use now is to call write every time I find the input buffer empty. That way, when running in the interactive mode, the program reads one line from the user's keyboard, processes it, and sees its input buffer is empty. It flushes its output and reads the next line. The Dark Side of Buffering This change prevents a mysterious lockup in a very specific case. I refer to it as the dark side of buffering, mostly because it presents a danger that is not quite obvious. It is unlikely to happen with a program like the csv above, so let us consider yet another filter: In this case we expect our input to be raw data representing color values, such as the red, green, and blue intensities of a pixel. Our output will be the negative of our input. Such a filter would be very simple to write. Most of it would look just like all the other filters we have written so far, so I am only going to show you its inner loop: .loop: call getchar not al ; Create a negative call putchar jmp short .loop Because this filter works with raw data, it is unlikely to be used interactively. But it could be called by image manipulation software. And, unless it calls write before each call to read, chances are it will lock up. Here is what might happen: The image editor will load our filter using the C function popen(). It will read the first row of pixels from a bitmap or pixmap. It will write the first row of pixels to the pipe leading to the fd.in of our filter. Our filter will read each pixel from its input, turn it to a negative, and write it to its output buffer. Our filter will call getchar to fetch the next pixel. getchar will find an empty input buffer, so it will call read. read will call the SYS_read system call. The kernel will suspend our filter until the image editor sends more data to the pipe. The image editor will read from the other pipe, connected to the fd.out of our filter so it can set the first row of the output image before it sends us the second row of the input. The kernel suspends the image editor until it receives some output from our filter, so it can pass it on to the image editor. At this point our filter waits for the image editor to send it more data to process, while the image editor is waiting for our filter to send it the result of the processing of the first row. But the result sits in our output buffer. The filter and the image editor will continue waiting for each other forever (or, at least, until they are killed). Our software has just entered a race condition. This problem does not exist if our filter flushes its output buffer before asking the kernel for more input data. Using the <acronym>FPU</acronym> Strangely enough, most of assembly language literature does not even mention the existence of the FPU, or floating point unit, let alone discuss programming it. Yet, never does assembly language shine more than when we create highly optimized FPU code by doing things that can be done only in assembly language. Organization of the <acronym>FPU</acronym> The FPU consists of 8 80–bit floating–point registers. These are organized in a stack fashion—you can push a value on TOS (top of stack) and you can pop it. That said, the assembly language op codes are not push and pop because those are already taken. You can push a value on TOS by using fld, fild, and fbld. Several other op codes let you push many common constants—such as pi—on the TOS. Similarly, you can pop a value by using fst, fstp, fist, fistp, and fbstp. Actually, only the op codes that end with a p will literally pop the value, the rest will store it somewhere else without removing it from the TOS. We can transfer the data between the TOS and the computer memory either as a 32–bit, 64–bit, or 80–bit real, a 16–bit, 32–bit, or 64–bit integer, or an 80–bit packed decimal. The 80–bit packed decimal is a special case of binary coded decimal which is very convenient when converting between the ASCII representation of data and the internal data of the FPU. It allows us to use 18 significant digits. No matter how we represent data in the memory, the FPU always stores it in the 80–bit real format in its registers. Its internal precision is at least 19 decimal digits, so even if we choose to display results as ASCII in the full 18–digit precision, we are still showing correct results. We can perform mathematical operations on the TOS: We can calculate its sine, we can scale it (i.e., we can multiply or divide it by a power of 2), we can calculate its base–2 logarithm, and many other things. We can also multiply or divide it by, add it to, or subtract it from, any of the FPU registers (including itself). The official Intel op code for the TOS is st, and for the registers st(0)–st(7). st and st(0), then, refer to the same register. For whatever reasons, the original author of nasm has decided to use different op codes, namely st0–st7. In other words, there are no parentheses, and the TOS is always st0, never just st. The Packed Decimal Format The packed decimal format uses 10 bytes (80 bits) of memory to represent 18 digits. The number represented there is always an integer. You can use it to get decimal places by multiplying the TOS by a power of 10 first. The highest bit of the highest byte (byte 9) is the sign bit: If it is set, the number is negative, otherwise, it is positive. The rest of the bits of this byte are unused/ignored. The remaining 9 bytes store the 18 digits of the number: 2 digits per byte. The more significant digit is stored in the high nibble (4 bits), the less significant digit in the low nibble. That said, you might think that -1234567 would be stored in the memory like this (using hexadecimal notation): 80 00 00 00 00 00 01 23 45 67 Alas it is not! As with everything else of Intel make, even the packed decimal is little–endian. That means our -1234567 is stored like this: 67 45 23 01 00 00 00 00 00 80 Remember that, or you will be pulling your hair out in desperation! The book to read—if you can find it—is Richard Startz' 8087/80287/80387 for the IBM PC & Compatibles. Though it does seem to take the fact about the little–endian storage of the packed decimal for granted. I kid you not about the desperation of trying to figure out what was wrong with the filter I show below before it occurred to me I should try the little–endian order even for this type of data. Excursion to Pinhole Photography To write meaningful software, we must not only understand our programming tools, but also the field we are creating software for. Our next filter will help us whenever we want to build a pinhole camera, so, we need some background in pinhole photography before we can continue. The Camera The easiest way to describe any camera ever built is as some empty space enclosed in some lightproof material, with a small hole in the enclosure. The enclosure is usually sturdy (e.g., a box), though sometimes it is flexible (the bellows). It is quite dark inside the camera. However, the hole lets light rays in through a single point (though in some cases there may be several). These light rays form an image, a representation of whatever is outside the camera, in front of the hole. If some light sensitive material (such as film) is placed inside the camera, it can capture the image. The hole often contains a lens, or a lens assembly, often called the objective. The Pinhole But, strictly speaking, the lens is not necessary: The original cameras did not use a lens but a pinhole. Even today, pinholes are used, both as a tool to study how cameras work, and to achieve a special kind of image. The image produced by the pinhole is all equally sharp. Or blurred. There is an ideal size for a pinhole: If it is either larger or smaller, the image loses its sharpness. Focal Length This ideal pinhole diameter is a function of the square root of focal length, which is the distance of the pinhole from the film. D = PC * sqrt(FL) In here, D is the ideal diameter of the pinhole, FL is the focal length, and PC is a pinhole constant. According to Jay Bender, its value is 0.04, while Kenneth Connors has determined it to be 0.037. Others have proposed other values. Plus, this value is for the daylight only: Other types of light will require a different constant, whose value can only be determined by experimentation. The F–Number The f–number is a very useful measure of how much light reaches the film. A light meter can determine that, for example, to expose a film of specific sensitivity with f5.6 may require the exposure to last 1/1000 sec. It does not matter whether it is a 35–mm camera, or a 6x9cm camera, etc. As long as we know the f–number, we can determine the proper exposure. The f–number is easy to calculate: F = FL / D In other words, the f–number equals the focal length divided by the diameter of the pinhole. It also means a higher f–number either implies a smaller pinhole or a larger focal distance, or both. That, in turn, implies, the higher the f–number, the longer the exposure has to be. Furthermore, while pinhole diameter and focal distance are one–dimensional measurements, both, the film and the pinhole, are two–dimensional. That means that if you have measured the exposure at f–number A as t, then the exposure at f–number B is: t * (B / A)² Normalized F–Number While many modern cameras can change the diameter of their pinhole, and thus their f–number, quite smoothly and gradually, such was not always the case. To allow for different f–numbers, cameras typically contained a metal plate with several holes of different sizes drilled to them. Their sizes were chosen according to the above formula in such a way that the resultant f–number was one of standard f–numbers used on all cameras everywhere. For example, a very old Kodak Duaflex IV camera in my possession has three such holes for f–numbers 8, 11, and 16. A more recently made camera may offer f–numbers of 2.8, 4, 5.6, 8, 11, 16, 22, and 32 (as well as others). These numbers were not chosen arbitrarily: They all are powers of the square root of 2, though they may be rounded somewhat. The F–Stop A typical camera is designed in such a way that setting any of the normalized f–numbers changes the feel of the dial. It will naturally stop in that position. Because of that, these positions of the dial are called f–stops. Since the f–numbers at each stop are powers of the square root of 2, moving the dial by 1 stop will double the amount of light required for proper exposure. Moving it by 2 stops will quadruple the required exposure. Moving the dial by 3 stops will require the increase in exposure 8 times, etc. Designing the Pinhole Software We are now ready to decide what exactly we want our pinhole software to do. Processing Program Input Since its main purpose is to help us design a working pinhole camera, we will use the focal length as the input to the program. This is something we can determine without software: Proper focal length is determined by the size of the film and by the need to shoot "regular" pictures, wide angle pictures, or telephoto pictures. Most of the programs we have written so far worked with individual characters, or bytes, as their input: The hex program converted individual bytes into a hexadecimal number, the csv program either let a character through, or deleted it, or changed it to a different character, etc. One program, ftuc used the state machine to consider at most two input bytes at a time. But our pinhole program cannot just work with individual characters, it has to deal with larger syntactic units. For example, if we want the program to calculate the pinhole diameter (and other values we will discuss later) at the focal lengths of 100 mm, 150 mm, and 210 mm, we may want to enter something like this: 100, 150, 210 Our program needs to consider more than a single byte of input at a time. When it sees the first 1, it must understand it is seeing the first digit of a decimal number. When it sees the 0 and the other 0, it must know it is seeing more digits of the same number. When it encounters the first comma, it must know it is no longer receiving the digits of the first number. It must be able to convert the digits of the first number into the value of 100. And the digits of the second number into the value of 150. And, of course, the digits of the third number into the numeric value of 210. We need to decide what delimiters to accept: Do the input numbers have to be separated by a comma? If so, how do we treat two numbers separated by something else? Personally, I like to keep it simple. Something either is a number, so I process it. Or it is not a number, so I discard it. I do not like the computer complaining about me typing in an extra character when it is obvious that it is an extra character. Duh! Plus, it allows me to break up the monotony of computing and type in a query instead of just a number: What is the best pinhole diameter for the focal length of 150? There is no reason for the computer to spit out a number of complaints: Syntax error: What Syntax error: is Syntax error: the Syntax error: best Et cetera, et cetera, et cetera. Secondly, I like the # character to denote the start of a comment which extends to the end of the line. This does not take too much effort to code, and lets me treat input files for my software as executable scripts. In our case, we also need to decide what units the input should come in: We choose millimeters because that is how most photographers measure the focus length. Finally, we need to decide whether to allow the use of the decimal point (in which case we must also consider the fact that much of the world uses a decimal comma). In our case allowing for the decimal point/comma would offer a false sense of precision: There is little if any noticeable difference between the focus lengths of 50 and 51, so allowing the user to input something like 50.5 is not a good idea. This is my opinion, mind you, but I am the one writing this program. You can make other choices in yours, of course. Offering Options The most important thing we need to know when building a pinhole camera is the diameter of the pinhole. Since we want to shoot sharp images, we will use the above formula to calculate the pinhole diameter from focal length. As experts are offering several different values for the PC constant, we will need to have the choice. It is traditional in &unix; programming to have two main ways of choosing program parameters, plus to have a default for the time the user does not make a choice. Why have two ways of choosing? One is to allow a (relatively) permanent choice that applies automatically each time the software is run without us having to tell it over and over what we want it to do. The permanent choices may be stored in a configuration file, typically found in the user's home directory. The file usually has the same name as the application but is started with a dot. Often "rc" is added to the file name. So, ours could be ~/.pinhole or ~/.pinholerc. (The ~/ means current user's home directory.) The configuration file is used mostly by programs that have many configurable parameters. Those that have only one (or a few) often use a different method: They expect to find the parameter in an environment variable. In our case, we might look at an environment variable named PINHOLE. Usually, a program uses one or the other of the above methods. Otherwise, if a configuration file said one thing, but an environment variable another, the program might get confused (or just too complicated). Because we only need to choose one such parameter, we will go with the second method and search the environment for a variable named PINHOLE. The other way allows us to make ad hoc decisions: "Though I usually want you to use 0.039, this time I want 0.03872." In other words, it allows us to override the permanent choice. This type of choice is usually done with command line parameters. Finally, a program always needs a default. The user may not make any choices. Perhaps he does not know what to choose. Perhaps he is "just browsing." Preferably, the default will be the value most users would choose anyway. That way they do not need to choose. Or, rather, they can choose the default without an additional effort. Given this system, the program may find conflicting options, and handle them this way: If it finds an ad hoc choice (e.g., command line parameter), it should accept that choice. It must ignore any permanent choice and any default. Otherwise, if it finds a permanent option (e.g., an environment variable), it should accept it, and ignore the default. Otherwise, it should use the default. We also need to decide what format our PC option should have. At first site, it seems obvious to use the PINHOLE=0.04 format for the environment variable, and -p0.04 for the command line. Allowing that is actually a security risk. The PC constant is a very small number. Naturally, we will test our software using various small values of PC. But what will happen if someone runs the program choosing a huge value? It may crash the program because we have not designed it to handle huge numbers. Or, we may spend more time on the program so it can handle huge numbers. We might do that if we were writing commercial software for computer illiterate audience. Or, we might say, "Tough! The user should know better."" Or, we just may make it impossible for the user to enter a huge number. This is the approach we will take: We will use an implied 0. prefix. In other words, if the user wants 0.04, we will expect him to type -p04, or set PINHOLE=04 in his environment. So, if he says -p9999999, we will interpret it as 0.9999999—still ridiculous but at least safer. Secondly, many users will just want to go with either Bender's constant or Connors' constant. To make it easier on them, we will interpret -b as identical to -p04, and -c as identical to -p037. The Output We need to decide what we want our software to send to the output, and in what format. Since our input allows for an unspecified number of focal length entries, it makes sense to use a traditional database–style output of showing the result of the calculation for each focal length on a separate line, while separating all values on one line by a tab character. Optionally, we should also allow the user to specify the use of the CSV format we have studied earlier. In this case, we will print out a line of comma–separated names describing each field of every line, then show our results as before, but substituting a comma for the tab. We need a command line option for the CSV format. We cannot use -c because that already means use Connors' constant. For some strange reason, many web sites refer to CSV files as "Excel spreadsheet" (though the CSV format predates Excel). We will, therefore, use the -e switch to inform our software we want the output in the CSV format. We will start each line of the output with the focal length. This may sound repetitious at first, especially in the interactive mode: The user types in the focal length, and we are repeating it. But the user can type several focal lengths on one line. The input can also come in from a file or from the output of another program. In that case the user does not see the input at all. By the same token, the output can go to a file which we will want to examine later, or it could go to the printer, or become the input of another program. So, it makes perfect sense to start each line with the focal length as entered by the user. No, wait! Not as entered by the user. What if the user types in something like this: 00000000150 Clearly, we need to strip those leading zeros. So, we might consider reading the user input as is, converting it to binary inside the FPU, and printing it out from there. But... What if the user types something like this: 17459765723452353453534535353530530534563507309676764423 Ha! The packed decimal FPU format lets us input 18–digit numbers. But the user has entered more than 18 digits. How do we handle that? Well, we could modify our code to read the first 18 digits, enter it to the FPU, then read more, multiply what we already have on the TOS by 10 raised to the number of additional digits, then add to it. Yes, we could do that. But in this program it would be ridiculous (in a different one it may be just the thing to do): Even the circumference of the Earth expressed in millimeters only takes 11 digits. Clearly, we cannot build a camera that large (not yet, anyway). So, if the user enters such a huge number, he is either bored, or testing us, or trying to break into the system, or playing games—doing anything but designing a pinhole camera. What will we do? We will slap him in the face, in a manner of speaking: 17459765723452353453534535353530530534563507309676764423 ??? ??? ??? ??? ??? To achieve that, we will simply ignore any leading zeros. Once we find a non–zero digit, we will initialize a counter to 0 and start taking three steps: Send the digit to the output. Append the digit to a buffer we will use later to produce the packed decimal we can send to the FPU. Increase the counter. Now, while we are taking these three steps, we also need to watch out for one of two conditions: If the counter grows above 18, we stop appending to the buffer. We continue reading the digits and sending them to the output. If, or rather when, the next input character is not a digit, we are done inputting for now. Incidentally, we can simply discard the non–digit, unless it is a #, which we must return to the input stream. It starts a comment, so we must see it after we are done producing output and start looking for more input. That still leaves one possibility uncovered: If all the user enters is a zero (or several zeros), we will never find a non–zero to display. We can determine this has happened whenever our counter stays at 0. In that case we need to send 0 to the output, and perform another "slap in the face": 0 ??? ??? ??? ??? ??? Once we have displayed the focal length and determined it is valid (greater than 0 but not exceeding 18 digits), we can calculate the pinhole diameter. It is not by coincidence that pinhole contains the word pin. Indeed, many a pinhole literally is a pin hole, a hole carefully punched with the tip of a pin. That is because a typical pinhole is very small. Our formula gets the result in millimeters. We will multiply it by 1000, so we can output the result in microns. At this point we have yet another trap to face: Too much precision. Yes, the FPU was designed for high precision mathematics. But we are not dealing with high precision mathematics. We are dealing with physics (optics, specifically). Suppose we want to convert a truck into a pinhole camera (we would not be the first ones to do that!). Suppose its box is 12 meters long, so we have the focal length of 12000. Well, using Bender's constant, it gives us square root of 12000 multiplied by 0.04, which is 4.381780460 millimeters, or 4381.780460 microns. Put either way, the result is absurdly precise. Our truck is not exactly 12000 millimeters long. We did not measure its length with such a precision, so stating we need a pinhole with the diameter of 4.381780460 millimeters is, well, deceiving. 4.4 millimeters would do just fine. I "only" used ten digits in the above example. Imagine the absurdity of going for all 18! We need to limit the number of significant digits of our result. One way of doing it is by using an integer representing microns. So, our truck would need a pinhole with the diameter of 4382 microns. Looking at that number, we still decide that 4400 microns, or 4.4 millimeters is close enough. Additionally, we can decide that no matter how big a result we get, we only want to display four significant digits (or any other number of them, of course). Alas, the FPU does not offer rounding to a specific number of digits (after all, it does not view the numbers as decimal but as binary). We, therefore, must devise an algorithm to reduce the number of significant digits. Here is mine (I think it is awkward—if you know a better one, please, let me know): Initialize a counter to 0. While the number is greater than or equal to 10000, divide it by 10 and increase the counter. Output the result. While the counter is greater than 0, output 0 and decrease the counter. The 10000 is only good if you want four significant digits. For any other number of significant digits, replace 10000 with 10 raised to the number of significant digits. We will, then, output the pinhole diameter in microns, rounded off to four significant digits. At this point, we know the focal length and the pinhole diameter. That means we have enough information to also calculate the f–number. We will display the f–number, rounded to four significant digits. Chances are the f–number will tell us very little. To make it more meaningful, we can find the nearest normalized f–number, i.e., the nearest power of the square root of 2. We do that by multiplying the actual f–number by itself, which, of course, will give us its square. We will then calculate its base–2 logarithm, which is much easier to do than calculating the base–square–root–of–2 logarithm! We will round the result to the nearest integer. Next, we will raise 2 to the result. Actually, the FPU gives us a good shortcut to do that: We can use the fscale op code to "scale" 1, which is analogous to shifting an integer left. Finally, we calculate the square root of it all, and we have the nearest normalized f–number. If all that sounds overwhelming—or too much work, perhaps—it may become much clearer if you see the code. It takes 9 op codes altogether: fmul st0, st0 fld1 fld st1 fyl2x frndint fld1 fscale fsqrt fstp st1 The first line, fmul st0, st0, squares the contents of the TOS (top of the stack, same as st, called st0 by nasm). The fld1 pushes 1 on the TOS. The next line, fld st1, pushes the square back to the TOS. At this point the square is both in st and st(2) (it will become clear why we leave a second copy on the stack in a moment). st(1) contains 1. Next, fyl2x calculates base–2 logarithm of st multiplied by st(1). That is why we placed 1 on st(1) before. At this point, st contains the logarithm we have just calculated, st(1) contains the square of the actual f–number we saved for later. frndint rounds the TOS to the nearest integer. fld1 pushes a 1. fscale shifts the 1 we have on the TOS by the value in st(1), effectively raising 2 to st(1). Finally, fsqrt calculates the square root of the result, i.e., the nearest normalized f–number. We now have the nearest normalized f–number on the TOS, the base–2 logarithm rounded to the nearest integer in st(1), and the square of the actual f–number in st(2). We are saving the value in st(2) for later. But we do not need the contents of st(1) anymore. The last line, fstp st1, places the contents of st to st(1), and pops. As a result, what was st(1) is now st, what was st(2) is now st(1), etc. The new st contains the normalized f–number. The new st(1) contains the square of the actual f–number we have stored there for posterity. At this point, we are ready to output the normalized f–number. Because it is normalized, we will not round it off to four significant digits, but will send it out in its full precision. The normalized f-number is useful as long as it is reasonably small and can be found on our light meter. Otherwise we need a different method of determining proper exposure. Earlier we have figured out the formula of calculating proper exposure at an arbitrary f–number from that measured at a different f–number. Every light meter I have ever seen can determine proper exposure at f5.6. We will, therefore, calculate an "f5.6 multiplier," i.e., by how much we need to multiply the exposure measured at f5.6 to determine the proper exposure for our pinhole camera. From the above formula we know this factor can be calculated by dividing our f–number (the actual one, not the normalized one) by 5.6, and squaring the result. Mathematically, dividing the square of our f–number by the square of 5.6 will give us the same result. Computationally, we do not want to square two numbers when we can only square one. So, the first solution seems better at first. But... 5.6 is a constant. We do not have to have our FPU waste precious cycles. We can just tell it to divide the square of the f–number by whatever 5.6² equals to. Or we can divide the f–number by 5.6, and then square the result. The two ways now seem equal. But, they are not! Having studied the principles of photography above, we remember that the 5.6 is actually square root of 2 raised to the fifth power. An irrational number. The square of this number is exactly 32. Not only is 32 an integer, it is a power of 2. We do not need to divide the square of the f–number by 32. We only need to use fscale to shift it right by five positions. In the FPU lingo it means we will fscale it with st(1) equal to -5. That is much faster than a division. So, now it has become clear why we have saved the square of the f–number on the top of the FPU stack. The calculation of the f5.6 multiplier is the easiest calculation of this entire program! We will output it rounded to four significant digits. There is one more useful number we can calculate: The number of stops our f–number is from f5.6. This may help us if our f–number is just outside the range of our light meter, but we have a shutter which lets us set various speeds, and this shutter uses stops. Say, our f–number is 5 stops from f5.6, and the light meter says we should use 1/1000 sec. Then we can set our shutter speed to 1/1000 first, then move the dial by 5 stops. This calculation is quite easy as well. All we have to do is to calculate the base-2 logarithm of the f5.6 multiplier we had just calculated (though we need its value from before we rounded it off). We then output the result rounded to the nearest integer. We do not need to worry about having more than four significant digits in this one: The result is most likely to have only one or two digits anyway. FPU Optimizations In assembly language we can optimize the FPU code in ways impossible in high languages, including C. Whenever a C function needs to calculate a floating–point value, it loads all necessary variables and constants into FPU registers. It then does whatever calculation is required to get the correct result. Good C compilers can optimize that part of the code really well. It "returns" the value by leaving the result on the TOS. However, before it returns, it cleans up. Any variables and constants it used in its calculation are now gone from the FPU. It cannot do what we just did above: We calculated the square of the f–number and kept it on the stack for later use by another function. We knew we would need that value later on. We also knew we had enough room on the stack (which only has room for 8 numbers) to store it there. A C compiler has no way of knowing that a value it has on the stack will be required again in the very near future. Of course, the C programmer may know it. But the only recourse he has is to store the value in a memory variable. That means, for one, the value will be changed from the 80-bit precision used internally by the FPU to a C double (64 bits) or even single (32 bits). That also means that the value must be moved from the TOS into the memory, and then back again. Alas, of all FPU operations, the ones that access the computer memory are the slowest. So, whenever programming the FPU in assembly language, look for the ways of keeping intermediate results on the FPU stack. We can take that idea even further! In our program we are using a constant (the one we named PC). It does not matter how many pinhole diameters we are calculating: 1, 10, 20, 1000, we are always using the same constant. Therefore, we can optimize our program by keeping the constant on the stack all the time. Early on in our program, we are calculating the value of the above constant. We need to divide our input by 10 for every digit in the constant. It is much faster to multiply than to divide. So, at the start of our program, we divide 10 into 1 to obtain 0.1, which we then keep on the stack: Instead of dividing the input by 10 for every digit, we multiply it by 0.1. By the way, we do not input 0.1 directly, even though we could. We have a reason for that: While 0.1 can be expressed with just one decimal place, we do not know how many binary places it takes. We, therefore, let the FPU calculate its binary value to its own high precision. We are using other constants: We multiply the pinhole diameter by 1000 to convert it from millimeters to microns. We compare numbers to 10000 when we are rounding them off to four significant digits. So, we keep both, 1000 and 10000, on the stack. And, of course, we reuse the 0.1 when rounding off numbers to four digits. Last but not least, we keep -5 on the stack. We need it to scale the square of the f–number, instead of dividing it by 32. It is not by coincidence we load this constant last. That makes it the top of the stack when only the constants are on it. So, when the square of the f–number is being scaled, the -5 is at st(1), precisely where fscale expects it to be. It is common to create certain constants from scratch instead of loading them from the memory. That is what we are doing with -5: fld1 ; TOS = 1 fadd st0, st0 ; TOS = 2 fadd st0, st0 ; TOS = 4 fld1 ; TOS = 1 faddp st1, st0 ; TOS = 5 fchs ; TOS = -5 We can generalize all these optimizations into one rule: Keep repeat values on the stack! &postscript; is a stack–oriented programming language. There are many more books available about &postscript; than about the FPU assembly language: Mastering &postscript; will help you master the FPU. <application>pinhole</application>—The Code ;;;;;;; pinhole.asm ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Find various parameters of a pinhole camera construction and use ; ; Started: 9-Jun-2001 ; Updated: 10-Jun-2001 ; ; Copyright (c) 2001 G. Adam Stanislav ; All rights reserved. ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; %include 'system.inc' %define BUFSIZE 2048 section .data align 4 ten dd 10 thousand dd 1000 tthou dd 10000 fd.in dd stdin fd.out dd stdout envar db 'PINHOLE=' ; Exactly 8 bytes, or 2 dwords long pinhole db '04,', ; Bender's constant (0.04) connors db '037', 0Ah ; Connors' constant usg db 'Usage: pinhole [-b] [-c] [-e] [-p <value>] [-o <outfile>] [-i <infile>]', 0Ah usglen equ $-usg iemsg db "pinhole: Can't open input file", 0Ah iemlen equ $-iemsg oemsg db "pinhole: Can't create output file", 0Ah oemlen equ $-oemsg pinmsg db "pinhole: The PINHOLE constant must not be 0", 0Ah pinlen equ $-pinmsg toobig db "pinhole: The PINHOLE constant may not exceed 18 decimal places", 0Ah biglen equ $-toobig huhmsg db 9, '???' separ db 9, '???' sep2 db 9, '???' sep3 db 9, '???' sep4 db 9, '???', 0Ah huhlen equ $-huhmsg header db 'focal length in millimeters,pinhole diameter in microns,' db 'F-number,normalized F-number,F-5.6 multiplier,stops ' db 'from F-5.6', 0Ah headlen equ $-header section .bss ibuffer resb BUFSIZE obuffer resb BUFSIZE dbuffer resb 20 ; decimal input buffer bbuffer resb 10 ; BCD buffer section .text align 4 huh: call write push dword huhlen push dword huhmsg push dword [fd.out] sys.write add esp, byte 12 ret align 4 perr: push dword pinlen push dword pinmsg push dword stderr sys.write push dword 4 ; return failure sys.exit align 4 consttoobig: push dword biglen push dword toobig push dword stderr sys.write push dword 5 ; return failure sys.exit align 4 ierr: push dword iemlen push dword iemsg push dword stderr sys.write push dword 1 ; return failure sys.exit align 4 oerr: push dword oemlen push dword oemsg push dword stderr sys.write push dword 2 sys.exit align 4 usage: push dword usglen push dword usg push dword stderr sys.write push dword 3 sys.exit align 4 global _start _start: add esp, byte 8 ; discard argc and argv[0] sub esi, esi .arg: pop ecx or ecx, ecx je near .getenv ; no more arguments ; ECX contains the pointer to an argument cmp byte [ecx], '-' jne usage inc ecx mov ax, [ecx] inc ecx .o: cmp al, 'o' jne .i ; Make sure we are not asked for the output file twice cmp dword [fd.out], stdout jne usage ; Find the path to output file - it is either at [ECX+1], ; i.e., -ofile -- ; or in the next argument, ; i.e., -o file or ah, ah jne .openoutput pop ecx jecxz usage .openoutput: push dword 420 ; file mode (644 octal) push dword 0200h | 0400h | 01h ; O_CREAT | O_TRUNC | O_WRONLY push ecx sys.open jc near oerr add esp, byte 12 mov [fd.out], eax jmp short .arg .i: cmp al, 'i' jne .p ; Make sure we are not asked twice cmp dword [fd.in], stdin jne near usage ; Find the path to the input file or ah, ah jne .openinput pop ecx or ecx, ecx je near usage .openinput: push dword 0 ; O_RDONLY push ecx sys.open jc near ierr ; open failed add esp, byte 8 mov [fd.in], eax jmp .arg .p: cmp al, 'p' jne .c or ah, ah jne .pcheck pop ecx or ecx, ecx je near usage mov ah, [ecx] .pcheck: cmp ah, '0' jl near usage cmp ah, '9' ja near usage mov esi, ecx jmp .arg .c: cmp al, 'c' jne .b or ah, ah jne near usage mov esi, connors jmp .arg .b: cmp al, 'b' jne .e or ah, ah jne near usage mov esi, pinhole jmp .arg .e: cmp al, 'e' jne near usage or ah, ah jne near usage mov al, ',' mov [huhmsg], al mov [separ], al mov [sep2], al mov [sep3], al mov [sep4], al jmp .arg align 4 .getenv: ; If ESI = 0, we did not have a -p argument, ; and need to check the environment for "PINHOLE=" or esi, esi jne .init sub ecx, ecx .nextenv: pop esi or esi, esi je .default ; no PINHOLE envar found ; check if this envar starts with 'PINHOLE=' mov edi, envar mov cl, 2 ; 'PINHOLE=' is 2 dwords long rep cmpsd jne .nextenv ; Check if it is followed by a digit mov al, [esi] cmp al, '0' jl .default cmp al, '9' jbe .init ; fall through align 4 .default: ; We got here because we had no -p argument, ; and did not find the PINHOLE envar. mov esi, pinhole ; fall through align 4 .init: sub eax, eax sub ebx, ebx sub ecx, ecx sub edx, edx mov edi, dbuffer+1 mov byte [dbuffer], '0' ; Convert the pinhole constant to real .constloop: lodsb cmp al, '9' ja .setconst cmp al, '0' je .processconst jb .setconst inc dl .processconst: inc cl cmp cl, 18 ja near consttoobig stosb jmp short .constloop align 4 .setconst: or dl, dl je near perr finit fild dword [tthou] fld1 fild dword [ten] fdivp st1, st0 fild dword [thousand] mov edi, obuffer mov ebp, ecx call bcdload .constdiv: fmul st0, st2 loop .constdiv fld1 fadd st0, st0 fadd st0, st0 fld1 faddp st1, st0 fchs ; If we are creating a CSV file, ; print header cmp byte [separ], ',' jne .bigloop push dword headlen push dword header push dword [fd.out] sys.write .bigloop: call getchar jc near done ; Skip to the end of the line if you got '#' cmp al, '#' jne .num call skiptoeol jmp short .bigloop .num: ; See if you got a number cmp al, '0' jl .bigloop cmp al, '9' ja .bigloop ; Yes, we have a number sub ebp, ebp sub edx, edx .number: cmp al, '0' je .number0 mov dl, 1 .number0: or dl, dl ; Skip leading 0's je .nextnumber push eax call putchar pop eax inc ebp cmp ebp, 19 jae .nextnumber mov [dbuffer+ebp], al .nextnumber: call getchar jc .work cmp al, '#' je .ungetc cmp al, '0' jl .work cmp al, '9' ja .work jmp short .number .ungetc: dec esi inc ebx .work: ; Now, do all the work or dl, dl je near .work0 cmp ebp, 19 jae near .toobig call bcdload ; Calculate pinhole diameter fld st0 ; save it fsqrt fmul st0, st3 fld st0 fmul st5 sub ebp, ebp ; Round off to 4 significant digits .diameter: fcom st0, st7 fstsw ax sahf jb .printdiameter fmul st0, st6 inc ebp jmp short .diameter .printdiameter: call printnumber ; pinhole diameter ; Calculate F-number fdivp st1, st0 fld st0 sub ebp, ebp .fnumber: fcom st0, st6 fstsw ax sahf jb .printfnumber fmul st0, st5 inc ebp jmp short .fnumber .printfnumber: call printnumber ; F number ; Calculate normalized F-number fmul st0, st0 fld1 fld st1 fyl2x frndint fld1 fscale fsqrt fstp st1 sub ebp, ebp call printnumber ; Calculate time multiplier from F-5.6 fscale fld st0 ; Round off to 4 significant digits .fmul: fcom st0, st6 fstsw ax sahf jb .printfmul inc ebp fmul st0, st5 jmp short .fmul .printfmul: call printnumber ; F multiplier ; Calculate F-stops from 5.6 fld1 fxch st1 fyl2x sub ebp, ebp call printnumber mov al, 0Ah call putchar jmp .bigloop .work0: mov al, '0' call putchar align 4 .toobig: call huh jmp .bigloop align 4 done: call write ; flush output buffer ; close files push dword [fd.in] sys.close push dword [fd.out] sys.close finit ; return success push dword 0 sys.exit align 4 skiptoeol: ; Keep reading until you come to cr, lf, or eof call getchar jc done cmp al, 0Ah jne .cr ret .cr: cmp al, 0Dh jne skiptoeol ret align 4 getchar: or ebx, ebx jne .fetch call read .fetch: lodsb dec ebx clc ret read: jecxz .read call write .read: push dword BUFSIZE mov esi, ibuffer push esi push dword [fd.in] sys.read add esp, byte 12 mov ebx, eax or eax, eax je .empty sub eax, eax ret align 4 .empty: add esp, byte 4 stc ret align 4 putchar: stosb inc ecx cmp ecx, BUFSIZE je write ret align 4 write: jecxz .ret ; nothing to write sub edi, ecx ; start of buffer push ecx push edi push dword [fd.out] sys.write add esp, byte 12 sub eax, eax sub ecx, ecx ; buffer is empty now .ret: ret align 4 bcdload: ; EBP contains the number of chars in dbuffer push ecx push esi push edi lea ecx, [ebp+1] lea esi, [dbuffer+ebp-1] shr ecx, 1 std mov edi, bbuffer sub eax, eax mov [edi], eax mov [edi+4], eax mov [edi+2], ax .loop: lodsw sub ax, 3030h shl al, 4 or al, ah mov [edi], al inc edi loop .loop fbld [bbuffer] cld pop edi pop esi pop ecx sub eax, eax ret align 4 printnumber: push ebp mov al, [separ] call putchar ; Print the integer at the TOS mov ebp, bbuffer+9 fbstp [bbuffer] ; Check the sign mov al, [ebp] dec ebp or al, al jns .leading ; We got a negative number (should never happen) mov al, '-' call putchar .leading: ; Skip leading zeros mov al, [ebp] dec ebp or al, al jne .first cmp ebp, bbuffer jae .leading ; We are here because the result was 0. ; Print '0' and return mov al, '0' jmp putchar .first: ; We have found the first non-zero. ; But it is still packed test al, 0F0h jz .second push eax shr al, 4 add al, '0' call putchar pop eax and al, 0Fh .second: add al, '0' call putchar .next: cmp ebp, bbuffer jb .done mov al, [ebp] push eax shr al, 4 add al, '0' call putchar pop eax and al, 0Fh add al, '0' call putchar dec ebp jmp short .next .done: pop ebp or ebp, ebp je .ret .zeros: mov al, '0' call putchar dec ebp jne .zeros .ret: ret The code follows the same format as all the other filters we have seen before, with one subtle exception:

We are no longer assuming that the end of input implies the end of things to do, something we took for granted in the character–oriented filters. This filter does not process characters. It processes a language (albeit a very simple one, consisting only of numbers). When we have no more input, it can mean one of two things: We are done and can quit. This is the same as before. The last character we have read was a digit. We have stored it at the end of our ASCII–to–float conversion buffer. We now need to convert the contents of that buffer into a number and write the last line of our output. For that reason, we have modified our getchar and our read routines to return with the carry flag clear whenever we are fetching another character from the input, or the carry flag set whenever there is no more input. Of course, we are still using assembly language magic to do that! Take a good look at getchar. It always returns with the carry flag clear. Yet, our main code relies on the carry flag to tell it when to quit—and it works. The magic is in read. Whenever it receives more input from the system, it just returns to getchar, which fetches a character from the input buffer, clears the carry flag and returns. But when read receives no more input from the system, it does not return to getchar at all. Instead, the add esp, byte 4 op code adds 4 to ESP, sets the carry flag, and returns. So, where does it return to? Whenever a program uses the call op code, the microprocessor pushes the return address, i.e., it stores it on the top of the stack (not the FPU stack, the system stack, which is in the memory). When a program uses the ret op code, the microprocessor pops the return value from the stack, and jumps to the address that was stored there. But since we added 4 to ESP (which is the stack pointer register), we have effectively given the microprocessor a minor case of amnesia: It no longer remembers it was getchar that called read. And since getchar never pushed anything before calling read, the top of the stack now contains the return address to whatever or whoever called getchar. As far as that caller is concerned, he called getchar, which returned with the carry flag set!

Other than that, the bcdload routine is caught up in the middle of a Lilliputian conflict between the Big–Endians and the Little–Endians. It is converting the text representation of a number into that number: The text is stored in the big–endian order, but the packed decimal is little–endian. To solve the conflict, we use the std op code early on. We cancel it with cld later on: It is quite important we do not call anything that may depend on the default setting of the direction flag while std is active. Everything else in this code should be quite clear, providing you have read the entire chapter that precedes it. It is a classical example of the adage that programming requires a lot of thought and only a little coding. Once we have thought through every tiny detail, the code almost writes itself. Using <application>pinhole</application> Because we have decided to make the program ignore any input except for numbers (and even those inside a comment), we can actually perform textual queries. We do not have to, but we can. In my humble opinion, forming a textual query, instead of having to follow a very strict syntax, makes software much more user friendly. Suppose we want to build a pinhole camera to use the 4x5 inch film. The standard focal length for that film is about 150mm. We want to fine–tune our focal length so the pinhole diameter is as round a number as possible. Let us also suppose we are quite comfortable with cameras but somewhat intimidated by computers. Rather than just have to type in a bunch of numbers, we want to ask a couple of questions. Our session might look like this: &prompt.user; pinhole Computer, What size pinhole do I need for the focal length of 150? 150 490 306 362 2930 12 Hmmm... How about 160? 160 506 316 362 3125 12 Let's make it 155, please. 155 498 311 362 3027 12 Ah, let's try 157... 157 501 313 362 3066 12 156? 156 500 312 362 3047 12 That's it! Perfect! Thank you very much! ^D We have found that while for the focal length of 150, our pinhole diameter should be 490 microns, or 0.49 mm, if we go with the almost identical focal length of 156 mm, we can get away with a pinhole diameter of exactly one half of a millimeter. Scripting Because we have chosen the # character to denote the start of a comment, we can treat our pinhole software as a scripting language. You have probably seen shell scripts that start with: #! /bin/sh ...or... #!/bin/sh ...because the blank space after the #! is optional. Whenever &unix; is asked to run an executable file which starts with the #!, it assumes the file is a script. It adds the command to the rest of the first line of the script, and tries to execute that. Suppose now that we have installed pinhole in /usr/local/bin/, we can now write a script to calculate various pinhole diameters suitable for various focal lengths commonly used with the 120 film. The script might look something like this: #! /usr/local/bin/pinhole -b -i # Find the best pinhole diameter # for the 120 film ### Standard 80 ### Wide angle 30, 40, 50, 60, 70 ### Telephoto 100, 120, 140 Because 120 is a medium size film, we may name this file medium. We can set its permissions to execute, and run it as if it were a program: &prompt.user; chmod 755 medium &prompt.user; ./medium &unix; will interpret that last command as: &prompt.user; /usr/local/bin/pinhole -b -i ./medium It will run that command and display: 80 358 224 256 1562 11 30 219 137 128 586 9 40 253 158 181 781 10 50 283 177 181 977 10 60 310 194 181 1172 10 70 335 209 181 1367 10 100 400 250 256 1953 11 120 438 274 256 2344 11 140 473 296 256 2734 11 Now, let us enter: &prompt.user; ./medium -c &unix; will treat that as: &prompt.user; /usr/local/bin/pinhole -b -i ./medium -c That gives it two conflicting options: -b and -c (Use Bender's constant and use Connors' constant). We have programmed it so later options override early ones—our program will calculate everything using Connors' constant: 80 331 242 256 1826 11 30 203 148 128 685 9 40 234 171 181 913 10 50 262 191 181 1141 10 60 287 209 181 1370 10 70 310 226 256 1598 11 100 370 270 256 2283 11 120 405 296 256 2739 11 140 438 320 362 3196 12 We decide we want to go with Bender's constant after all. We want to save its values as a comma–separated file: &prompt.user; ./medium -b -e > bender &prompt.user; cat bender focal length in millimeters,pinhole diameter in microns,F-number,normalized F-number,F-5.6 multiplier,stops from F-5.6 80,358,224,256,1562,11 30,219,137,128,586,9 40,253,158,181,781,10 50,283,177,181,977,10 60,310,194,181,1172,10 70,335,209,181,1367,10 100,400,250,256,1953,11 120,438,274,256,2344,11 140,473,296,256,2734,11 &prompt.user; Caveats Assembly language programmers who "grew up" under &ms-dos; and &windows; often tend to take shortcuts. Reading the keyboard scan codes and writing directly to video memory are two classical examples of practices which, under &ms-dos; are not frowned upon but considered the right thing to do. The reason? Both the PC BIOS and &ms-dos; are notoriously slow when performing these operations. You may be tempted to continue similar practices in the &unix; environment. For example, I have seen a web site which explains how to access the keyboard scan codes on a popular &unix; clone. That is generally a very bad idea in &unix; environment! Let me explain why. &unix; Is Protected For one thing, it may simply not be possible. &unix; runs in protected mode. Only the kernel and device drivers are allowed to access hardware directly. Perhaps a particular &unix; clone will let you read the keyboard scan codes, but chances are a real &unix; operating system will not. And even if one version may let you do it, the next one may not, so your carefully crafted software may become a dinosaur overnight. &unix; Is an Abstraction But there is a much more important reason not to try accessing the hardware directly (unless, of course, you are writing a device driver), even on the &unix; like systems that let you do it: &unix; is an abstraction! There is a major difference in the philosophy of design between &ms-dos; and &unix;. &ms-dos; was designed as a single-user system. It is run on a computer with a keyboard and a video screen attached directly to that computer. User input is almost guaranteed to come from that keyboard. Your program's output virtually always ends up on that screen. This is NEVER guaranteed under &unix;. It is quite common for a &unix; user to pipe and redirect program input and output: &prompt.user; program1 | program2 | program3 > file1 If you have written program2, your input does not come from the keyboard but from the output of program1. Similarly, your output does not go to the screen but becomes the input for program3 whose output, in turn, goes to file1. But there is more! Even if you made sure that your input comes from, and your output goes to, the terminal, there is no guarantee the terminal is a PC: It may not have its video memory where you expect it, nor may its keyboard be producing PC-style scan codes. It may be a &macintosh;, or any other computer. Now you may be shaking your head: My software is in PC assembly language, how can it run on a &macintosh;? But I did not say your software would be running on a &macintosh;, only that its terminal may be a &macintosh;. Under &unix;, the terminal does not have to be directly attached to the computer that runs your software, it can even be on another continent, or, for that matter, on another planet. It is perfectly possible that a &macintosh; user in Australia connects to a &unix; system in North America (or anywhere else) via telnet. The software then runs on one computer, while the terminal is on a different computer: If you try to read the scan codes, you will get the wrong input! Same holds true about any other hardware: A file you are reading may be on a disk you have no direct access to. A camera you are reading images from may be on a space shuttle, connected to you via satellites. That is why under &unix; you must never make any assumptions about where your data is coming from and going to. Always let the system handle the physical access to the hardware. These are caveats, not absolute rules. Exceptions are possible. For example, if a text editor has determined it is running on a local machine, it may want to read the scan codes directly for improved control. I am not mentioning these caveats to tell you what to do or what not to do, just to make you aware of certain pitfalls that await you if you have just arrived to &unix; form &ms-dos;. Of course, creative people often break rules, and it is OK as long as they know they are breaking them and why. Acknowledgements This tutorial would never have been possible without the help of many experienced FreeBSD programmers from the &a.hackers;, many of whom have patiently answered my questions, and pointed me in the right direction in my attempts to explore the inner workings of &unix; system programming in general and FreeBSD in particular. Thomas M. Sommers opened the door for me. His How do I write "Hello, world" in FreeBSD assembler? web page was my first encounter with an example of assembly language programming under FreeBSD. Jake Burkholder has kept the door open by willingly answering all of my questions and supplying me with example assembly language source code. Copyright © 2000-2001 G. Adam Stanislav. All rights reserved. diff --git a/en_US.ISO8859-1/books/faq/book.xml b/en_US.ISO8859-1/books/faq/book.xml index a2cd624cac..3c5739b094 100644 --- a/en_US.ISO8859-1/books/faq/book.xml +++ b/en_US.ISO8859-1/books/faq/book.xml @@ -1,8220 +1,8220 @@ 10-CURRENT"> X"> HEAD"> X"> 9-STABLE"> RELENG_9"> X"> 8-STABLE"> RELENG_8"> ]> Frequently Asked Questions for &os; &rel2.relx;, and &rel.relx; The &os; Documentation Project 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 The &os; Documentation Project &legalnotice; &tm-attrib.freebsd; &tm-attrib.adobe; &tm-attrib.ibm; &tm-attrib.ieee; &tm-attrib.intel; &tm-attrib.linux; &tm-attrib.microsoft; &tm-attrib.netbsd; &tm-attrib.opengroup; &tm-attrib.sgi; &tm-attrib.sun; &tm-attrib.general; $FreeBSD$ This is the FAQ for &os; versions &rel2.relx; and &rel.relx;. Every effort has been made to make this FAQ as informative as possible; if you have any suggestions as to how it may be improved, please feel free to mail them to the &a.doc;. The latest version of this document is always available from the &os; website. It may also be downloaded as one large HTML file with HTTP or as a variety of other formats from the &os; FTP server. Introduction What is &os;? &os; is a modern operating system for desktops, laptops, servers, and embedded systems with support for a large number of platforms. It is based on U.C. Berkeley's 4.4BSD-Lite release, with some 4.4BSD-Lite2 enhancements. It is also based indirectly on William Jolitz's port of U.C. Berkeley's Net/2 to the &i386;, known as 386BSD, though very little of the 386BSD code remains. &os; is used by companies, Internet Service Providers, researchers, computer professionals, students and home users all over the world in their work, education and recreation. For more detailed information on &os;, please see the &os; Handbook. What is the goal of the &os; Project? The goal of the &os; Project is to provide a stable and fast general purpose operating system that may be used for any purpose without strings attached. Does the &os; license have any restrictions? Yes. Those restrictions do not control how you use the code, merely how you treat the &os; Project itself. If you have serious license concerns, read the actual license. For the simply curious, the license can be summarized like this. Do not claim that you wrote this. Do not sue us if it breaks. Do not remove or modify the license. Many of us have a significant investment in the project and would certainly not mind a little financial compensation now and then, but we definitely do not insist on it. We believe that our first and foremost mission is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This, we believe, is one of the most fundamental goals of Free Software and one that we enthusiastically support. Code in our source tree which falls under the GNU General Public License (GPL) or GNU Library General Public License (LGPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed &os; license whenever possible. Can &os; replace my current operating system? For most people, yes. But this question is not quite that cut-and-dried. Most people do not actually use an operating system. They use applications. The applications are what really use the operating system. &os; is designed to provide a robust and full-featured environment for applications. It supports a wide variety of web browsers, office suites, email readers, graphics programs, programming environments, network servers, and just about everything else you might want. Most of these applications can be managed through the Ports Collection. If you need to use an application that is only available on one operating system, you simply cannot replace that operating system. Chances are there is a very similar application on &os;, however. If you want a solid office or Internet server, a reliable workstation, or just the ability to do your job without interruptions, &os; will almost certainly do everything you need. Many computer users across the world, including both novices and experienced &unix; administrators, use &os; as their only desktop operating system. If you are migrating to &os; from some other &unix; environment, you already know most of what you need to. If your background is in graphic-driven operating systems such as &windows; and &macos;, you may be interested in using PC-BSD, a &os; based distribution, instead. If you have not used &unix; before expect to invest additional time learning the &unix; way of doing things. This FAQ and the &os; Handbook are excellent places to start. Why is it called &os;? It may be used free of charge, even by commercial users. Full source for the operating system is freely available, and the minimum possible restrictions have been placed upon its use, distribution and incorporation into other work (commercial or non-commercial). Anyone who has an improvement or bug fix is free to submit their code and have it added to the source tree (subject to one or two obvious provisions). It is worth pointing out that the word free is being used in two ways here, one meaning at no cost, the other meaning you can do whatever you like. Apart from one or two things you cannot do with the &os; code, for example pretending you wrote it, you can really do whatever you like with it. What are the differences between &os; and NetBSD, OpenBSD, and other open source BSD operating systems? James Howard wrote a good explanation of the history and differences between the various projects, called The BSD Family Tree which goes a fair way to answering this question. Some of the information is out of date, but the history portion in particular remains accurate. Most of the BSDs share patches and code, even today. All of the BSDs have common ancestry. The design goals of &os; are described in , above. The design goals of the other most popular BSDs may be summarized as follows: OpenBSD aims for operating system security above all else. The OpenBSD team wrote &man.ssh.1; and &man.pf.4;, which have both been ported to &os;. NetBSD aims to be easily ported to other hardware platforms. DragonFly BSD is a fork of &os; 4.8 that has since developed many interesting features of its own, including the HAMMER file system and support for user-mode vkernels. What is the latest version of &os;? At any point in the development of &os;, there can be multiple parallel branches. &rel.relx; releases are made from the &rel.stable; branch, and &rel2.relx; releases are made from the &rel2.stable; branch. Up until the release of 9.0, the &rel2.relx; series was the one known as -STABLE. However, as of &rel.head.relx;, the &rel2.relx; branch will be designated for an extended support status and receive only fixes for major problems, such as security-related fixes. Version &rel.current; is the latest release from the &rel.stable; branch; it was released in &rel.current.date;. Version &rel2.current; is the latest release from the &rel2.stable; branch; it was released in &rel2.current.date;. Briefly, -STABLE is aimed at the ISP, corporate user, or any user who wants stability and a minimal number of changes compared to the new (and possibly unstable) features of the latest -CURRENT snapshot. Releases can come from either branch, but -CURRENT should only be used if you are prepared for its increased volatility (relative to -STABLE, that is). Releases are made every few months. While many people stay more up-to-date with the &os; sources (see the questions on &os.current; and &os.stable;) than that, doing so is more of a commitment, as the sources are a moving target. More information on &os; releases can be found on the Release Engineering page and in &man.release.7;. What is &os;-CURRENT? &os.current; is the development version of the operating system, which will in due course become the new &os.stable; branch. As such, it is really only of interest to developers working on the system and die-hard hobbyists. See the relevant section in the Handbook for details on running -CURRENT. If you are not familiar with &os; you should not use &os.current;. This branch sometimes evolves quite quickly and due to mistake can be un-buildable at times. People that use &os.current; are expected to be able to analyze, debug, and report problems. &os; snapshot releases are made based on the current state of the -CURRENT and -STABLE branches. The goals behind each snapshot release are: To test the latest version of the installation software. To give people who would like to run -CURRENT or -STABLE but who do not have the time or bandwidth to follow it on a day-to-day basis an easy way of bootstrapping it onto their systems. To preserve a fixed reference point for the code in question, just in case we break something really badly later. (Although Subversion normally prevents anything horrible like this happening.) To ensure that all new features and fixes in need of testing have the greatest possible number of potential testers. No claims are made that any -CURRENT snapshot can be considered production quality for any purpose. If you want to run a stable and fully tested system, you will have to stick to full releases, or use the -STABLE snapshots. Snapshot releases are directly available from snapshot. Official snapshots are generated on a regular basis for all actively developed branches. What is the &os;-STABLE concept? Back when &os; 2.0.5 was released, &os; development branched in two. One branch was named -STABLE, one -CURRENT. &os;-STABLE is intended for Internet Service Providers and other commercial enterprises for whom sudden shifts or experimental features are quite undesirable. It receives only well-tested bug fixes and other small incremental enhancements. &os;-CURRENT, on the other hand, has been one unbroken line since 2.0 was released, leading towards &rel.current;-RELEASE and beyond. For more detailed information on branches see &os; Release Engineering: Creating the Release Branch, the status of the branches and the upcoming release schedule can be found on the Release Engineering Information page. &rel.current;-STABLE is the actively developed -STABLE branch. The latest release on the &rel.current;-STABLE branch is &rel.current;-RELEASE, which was released in &rel.current.date;. The &rel.head; branch is the actively developed -CURRENT branch toward the next generation of &os;. See What is &os;-CURRENT? for more information on this branch. When are &os; releases made? The &a.re; releases a new major version of &os; about every 18 months and a new minor version about every 8 months, on average. Release dates are announced well in advance, so that the people working on the system know when their projects need to be finished and tested. A testing period precedes each release, to ensure that the addition of new features does not compromise the stability of the release. Many users regard this caution as one of the best things about &os;, even though waiting for all the latest goodies to reach -STABLE can be a little frustrating. More information on the release engineering process (including a schedule of upcoming releases) can be found on the release engineering pages on the &os; Web site. For people who need or want a little more excitement, binary snapshots are made weekly as discussed above. Who is responsible for &os;? The key decisions concerning the &os; project, such as the overall direction of the project and who is allowed to add code to the source tree, are made by a core team of 9 people. There is a much larger team of more than 350 committers who are authorized to make changes directly to the &os; source tree. However, most non-trivial changes are discussed in advance in the mailing lists, and there are no restrictions on who may take part in the discussion. Where can I get &os;? Every significant release of &os; is available via anonymous FTP from the &os; FTP site: The latest &rel.stable; release, &rel.current;-RELEASE can be found in the &rel.current;-RELEASE directory. Snapshot releases are made monthly for the -CURRENT and -STABLE branch, these being of service purely to bleeding-edge testers and developers. The latest &rel2.stable; release, &rel2.current;-RELEASE can be found in the &rel2.current;-RELEASE directory. Information about obtaining &os; on CD, DVD, and other media can be found in the Handbook. How do I access the Problem Report database? The Problem Report database of all user change requests may be queried by using our web-based PR query interface. The &man.send-pr.1; command can be used to submit problem reports and change requests via electronic mail. Alternatively, the web-based problem report submission interface can be used to submit problem reports through a web browser. Before submitting a problem report, please read Writing &os; Problem Reports, an article on how to write good problem reports. Documentation and Support What good books are there about &os;? The project produces a wide range of documentation, available online from this link: . In addition, the Bibliography at the end of this FAQ, and the one in the Handbook reference other recommended books. Is the documentation available in other formats, such as plain text (ASCII), or &postscript;? Yes. The documentation is available in a number of different formats and compression schemes on the &os; FTP site, in the /pub/FreeBSD/doc/ directory. The documentation is categorized in a number of different ways. These include: The document's name, such as faq, or handbook. The document's language and encoding. These are based on the locale names you will find under /usr/share/locale on your &os; system. The current languages and encodings that we have for documentation are as follows: Name Meaning en_US.ISO8859-1 English (United States) bn_BD.ISO10646-1 Bengali or Bangla (Bangladesh) da_DK.ISO8859-1 Danish (Denmark) de_DE.ISO8859-1 German (Germany) el_GR.ISO8859-7 Greek (Greece) es_ES.ISO8859-1 Spanish (Spain) fr_FR.ISO8859-1 French (France) hu_HU.ISO8859-2 Hungarian (Hungary) it_IT.ISO8859-15 Italian (Italy) ja_JP.eucJP Japanese (Japan, EUC encoding) mn_MN.UTF-8 Mongolian (Mongolia, UTF-8 encoding) nl_NL.ISO8859-1 Dutch (Netherlands) no_NO.ISO8859-1 Norwegian (Norway) pl_PL.ISO8859-2 Polish (Poland) pt_BR.ISO8859-1 Portuguese (Brazil) ru_RU.KOI8-R Russian (Russia, KOI8-R encoding) sr_YU.ISO8859-2 Serbian (Serbia) tr_TR.ISO8859-9 Turkish (Turkey) zh_CN.GB2312 Simplified Chinese (China, GB2312 encoding) zh_TW.Big5 Traditional Chinese (Taiwan, Big5 encoding) Some documents may not be available in all languages. The document's format. We produce the documentation in a number of different output formats. Each format has its own advantages and disadvantages. Some formats are better suited for online reading, while others are meant to be aesthetically pleasing when printed on paper. Having the documentation available in any of these formats ensures that our readers will be able to read the parts they are interested in, either on their monitor, or on paper after printing the documents. The currently available formats are: Format Meaning html-split A collection of small, linked, HTML files. html One large HTML file containing the entire document pdf Adobe's Portable Document Format ps &postscript; rtf Microsoft's Rich Text Format txt Plain text Page numbers are not automatically updated when loading Rich Text Format into Word. Press CtrlA, CtrlEnd, F9 after loading the document, to update the page numbers. The compression and packaging scheme. Where the format is html-split, the files are bundled up using &man.tar.1;. The resulting .tar file is then compressed using the compression schemes detailed in the next point. All the other formats generate one file, called type.format (i.e., article.pdf, book.html, and so on). These files are then compressed using either the zip or bz2 compression schemes. &man.tar.1; can be used to uncompress these files. So the &postscript; version of the Handbook, compressed using bzip2 will be stored in a file called book.ps.bz2 in the handbook/ directory. After choosing the format and compression mechanism that you want to download, you will have to download the compressed files yourself, uncompress them, and then copy the appropriate documents into place. For example, the split HTML version of the FAQ, compressed using &man.bzip2.1;, can be found in doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 To download and uncompress that file you would have to do this: &prompt.root; fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 &prompt.root; tar xvf book.html-split.tar.bz2 If the file is compressed, tar will automatically detect the appropriate format and decompress it correctly. You will be left with a collection of .html files. The main one is called index.html, which will contain the table of contents, introductory material, and links to the other parts of the document. You can then copy or move these to their final location as necessary. Where do I find info on the &os; mailing lists? What &os; news groups are available? You can find full information in the Handbook entry on mailing-lists and the Handbook entry on newsgroups. Are there &os; IRC (Internet Relay Chat) channels? Yes, most major IRC networks host a &os; chat channel: Channel #FreeBSDhelp on EFNet is a channel dedicated to helping &os; users. They are much more sympathetic to questions than #FreeBSD is. Channel ##FreeBSD on Freenode is a general help channel with many users at any time. The conversations have been known to run off-topic for a while, but priority is given to users with &os; questions. We are good about helping you understand the basics, referring to the Handbook whenever possible, and directing you where to learn more about the topic you need help with. We are a primarily English speaking channel, though we have users from all over the world. If you would like to speak in your native language, try to ask the question in English and then relocate to another channel ##freebsd-lang as appropriate. Channel #FreeBSD on DALNET is available at irc.dal.net in the US and irc.eu.dal.net in Europe. Channel #FreeBSD on UNDERNET is available at us.undernet.org in the US and eu.undernet.org in Europe. Since it is a help channel, be prepared to read the documents you are referred to. Channel #FreeBSD on RUSNET is a russian-language oriented channel dedicated to helping &os; users. This is also good place for non-technical discussions. Channel #bsdchat on Freenode is a Traditional-Chinese (UTF-8 encoding) language oriented channel dedicated to helping &os; users. This is also good place for non-technical discussions. The &os; wiki has a good list of IRC channels. Each of these channels are distinct and are not connected to each other. Their chat styles also differ, so you may need to try each to find one suited to your chat style. As with all types of IRC traffic, if you are easily offended or cannot deal with lots of young people (and more than a few older ones) doing the verbal equivalent of jello wrestling, do not even bother with it. Are there any web based forums to discuss &os;? The official &os; forums are located at http://forums.FreeBSD.org/. Where can I get commercial &os; training and support? iXsystems, Inc., parent company of the &os; Mall, provides commercial &os; and PC-BSD software support, in addition to &os; development and tuning solutions. BSD Certification Group, Inc. provides system administration certifications for DragonFly BSD, &os;, NetBSD, OpenBSD. If you are interested in them, visit their site. Any other organizations providing training and support should contact the Project to be listed here. Nik Clayton

nik@FreeBSD.org

Installation Which platform should I download? I have a 64 bit capable &intel; CPU, but I only see amd64. &arch.amd64; is the term &os; uses for 64-bit compatible x86 architectures (also known as "x86-64" or "x64"). Most modern computers should use &arch.amd64;. Older hardware should use &arch.i386;. If you are installing on a non-x86-compatible architecture select the platform which best matches the architecture you are using. Which file do I download to get &os;? On the Getting &os; page select [iso] next to the architecture you want to use. Any of the following can be used: file description disc1.iso Contains enough to install &os; and a minimal set of packages. dvd1.iso Similar to disc1.iso but with additional packages. memstick.img A bootable image sufficient for writing to a USB stick. bootonly.iso A minimal image that requires network access during installation to completely install &os;. &arch.pc98; users require these floppy images: floppies/boot.flp, floppies/kern1.flp, floppies/kern2.flp, and floppies/mfsroot1.flp. These images need to be written onto floppies by tools like &man.dd.1;. Full instructions on this procedure and a little bit more about installation issues in general can be found in the Handbook entry on installing &os;. What do I do if the images do not fit on a single disk? Common mistakes when preparing the boot media are: Not downloading the image in binary mode when using FTP. Some FTP clients default their transfer mode to ascii and attempt to change any end-of-line characters received to match the conventions used by the client's system. This will almost invariably corrupt the boot image. Check the SHA-256 of the downloaded boot image: if it is not exactly that on the server, then the download process is suspect. To workaround: type binary at the FTP command prompt after getting connected to the server and before starting the download of the image. Using the DOS copy command (or equivalent GUI tool) to transfer the boot image to floppy. Programs like copy will not work as the boot image has been created to be booted into directly. The image has the complete content of the floppy, track for track, and is not meant to be placed on the floppy as a regular file. You have to transfer it to the floppy raw, using the low-level tools (e.g., fdimage or rawrite) described in the installation guide to &os;. Where are the instructions for installing &os;? Installation instructions for versions since &os; 9.0 can be found at Handbook entry on installing &os;. Older instructions can be found in the legacy entry on installing &os;. What do I need to run &os;? For &os; you will need a 486 or better PC, with 64 MB or more of RAM and at least 1 GB of hard disk space. See also . How can I make my own custom release or install disk? Customized &os; installation media can be created by building a custom release. Follow the instructions in the Release Engineering article. Can &windows; co-exist with &os;? If &windows; is installed first, then yes. &os;'s boot manager will then manage to boot &windows; and &os;. If you install &windows; second, it will boorishly overwrite your boot manager without even asking. If that happens, see the next section. Another operating system destroyed my Boot Manager. How do I get it back? This depends on what boot manager you have installed. The &os; boot selection menu (likely what you are using if you end up in this situation) can be reinstalled using &man.boot0cfg.8;. For example, to restore the boot menu onto the disk ada0: &prompt.root; boot0cfg -B ada0 The non-interactive MBR bootloader can be installed using &man.gpart.8;: &prompt.root; gpart bootcode -b /boot/mbr ada0 For more complex situations, including GPT disks, see &man.gpart.8;. I booted from my ATAPI CD-ROM, but the install program says no CD-ROM is found. Where did it go? The usual cause of this problem is a mis-configured CD-ROM drive. Many PCs now ship with the CD-ROM as the slave device on the secondary IDE controller, with no master device on that controller. This is illegal according to the ATAPI specification, but &windows; plays fast and loose with the specification, and the BIOS ignores it when booting. This is why the BIOS was able to see the CD-ROM to boot from it, but why &os; cannot see it to complete the install. Reconfigure your system so that the CD-ROM is either the master device on the IDE controller it is attached to, or make sure that it is the slave on an IDE controller that also has a master device. Do I need to install the source? In general, no. There is nothing in the base system which requires the presence of the source to operate. Some ports, like sysutils/lsof, will not build unless the source is installed. In particular, if the port builds a kernel module or directly operates on kernel structures, the source must be installed. Do I need to build a kernel? Usually not. The supplied GENERIC kernel contains the drivers an ordinary computer will need. &man.freebsd-update.8;, the &os; binary upgrade tool, cannot upgrade custom kernels, another reason to stick with the GENERIC kernel when possible. For computers with very limited RAM, such as embedded systems, it may be worthwhile to build a smaller custom kernel containing just the required drivers. Should I use DES, Blowfish, or MD5 passwords and how do I specify which form my users receive? &os; 7 and 8 use MD5 password hashing by default. Recent versions of &os; use SHA512 by default. These are believed to be more secure than the traditional &unix; password format, which used a scheme based on the DES algorithm. DES passwords are still available if you need to share your password file with legacy operating systems which still use the less secure password format. &os; also allows you to use the Blowfish and MD5 password formats. Which password format to use for new passwords is controlled by the passwd_format login capability in /etc/login.conf, which takes values of des, blf (if these are available) or md5. See the &man.login.conf.5; manual page for more information about login capabilities. What are the limits for memory? Memory limits depend on the platform used. On a standard &i386; install, the limit is 4 GB but more memory can be supported through &man.pae.4;. See instructions for using 4 GB or more memory on &i386;. &os;/pc98 has a limit of 4 GB memory, and PAE can not be used with it. Other architectures supported by &os; have much higher theoretical limits on maximum memory (many terabytes). What are the limits for FFS file systems? For FFS file systems, the maximum theoretical limit is 8 TB (2 G blocks), or 16 TB for the default block size of 8 KB. In practice, there is a soft limit of 1 TB, but with modifications file systems with 4 TB are possible (and exist). The maximum size of a single FFS file is approximately 1 G blocks, or 4 TB with a block size of 4 KB. Maximum File Sizes FS Block Size Works Should Work 4 KB > 4 GB 4 TB - 1 8 KB > 32 GB 32 TB - 1 16 KB > 128 GB 32 TB - 1 32 KB > 512 GB 64 TB - 1 64 KB > 2048 GB 128 TB - 1

When the FS block size is 4 KB, triple indirect blocks work and everything should be limited by the maximum FS block number that can be represented using triple indirect blocks (approx. 10243 + 10242 + 1024), but everything is limited by a (wrong) limit of 1 G - 1 on FS block numbers. The limit on FS block numbers should be 2 G - 1. There are some bugs for FS block numbers near 2 G - 1, but such block numbers are unreachable when the FS block size is 4 KB. For block sizes of 8 KB and larger, everything should be limited by the 2 G - 1 limit on FS block numbers, but is actually limited by the 1 G - 1 limit on FS block numbers. Using the correct limit of 2 G - 1 blocks does cause problems. Why do I get an error message, readin failed after compiling and booting a new kernel? Because your world and kernel are out of sync. This is not supported. Be sure you use make buildworld and make buildkernel to update your kernel. You can boot by specifying the kernel directly at the second stage, pressing any key when the | shows up before loader is started. Is there a tool to perform post-installation configuration tasks? Yes, &rel.head.releng; users can set WITH_BSDCONFIG in /etc/src.conf. Users of &rel.relx; and higher may also install sysutils/bsdconfig. Hardware Compatibility General I want to get a piece of hardware for my &os; system. Which model/brand/type is best? This is discussed continually on the &os; mailing lists. Since hardware changes so quickly, however, we expect this. We still strongly recommend that you read through the Hardware Notes for &os; &rel.current; or &rel2.current; and search the mailing list archives before asking about the latest and greatest hardware. Chances are a discussion about the type of hardware you are looking for took place just last week. If you are looking for a laptop, check the &a.mobile; archives. Otherwise, you probably want the archives for the &a.questions;, or possibly a specific mailing list for a particular hardware type. Does &os; support more than 4 GB of memory (RAM)? More than 16 GB? More than 48 GB? Yes. &os; as an operating system generally supports as much physical memory (RAM) as the platform it is running on does. Keep in mind that different platforms have different limits for memory; for example &i386; without PAE supports at most 4 GB of memory (and usually less than that because of PCI address space) and &i386; with PAE supports at most 64 GB memory. AMD64 platforms currently deployed support up to 1 TB of physical memory. Why does &os; report less than 4 GB memory when installed on an &i386; machine? The total address space on &i386; machines is 32-bit, meaning that at most 4 GB of memory is addressable (can be accessed). Furthermore, some addresses in this range are reserved by hardware for different purposes, for example for using and controlling PCI devices, for accessing video memory, and so on. Therefore, the total amount of memory usable by the operating system for its kernel and applications is limited to significantly less than 4 GB. Usually, 3.2 GB to 3.7 GB is the maximum usable physical memory in this configuration. To access more than 3.2 GB to 3.7 GB of installed memory (meaning up to 4 GB but also more than 4 GB), a special tweak called PAE must be used. PAE stands for Physical Address Extension and is a way for 32-bit x86 CPUs to address more than 4 GB of memory. It remaps the memory that would otherwise be overlaid by address reservations for hardware devices above the 4 GB range and uses it as additional physical memory (see &man.pae.4;). Using PAE has some drawbacks; this mode of memory access is a little bit slower than the normal (without PAE) mode and loadable modules (see &man.kld.4;) are not supported. This means all drivers must be compiled into the kernel. The most common way to enable PAE is to build a new kernel with the special ready-provided kernel configuration file called PAE, which is already configured to build a safe kernel. Note that some entries in this kernel configuration file are too conservative and some drivers marked as unready to be used with PAE are actually usable. A rule of thumb is that if the driver is usable on 64-bit architectures (like AMD64), it is also usable with PAE. If you wish to create your own kernel configuration file, you can enable PAE by adding the following line to your configuration: options PAE PAE is not much used nowadays because most new x86 hardware also supports running in 64-bit mode, known as AMD64 or &intel; 64. It has a much larger address space and does not need such tweaks. &os; supports AMD64 and it is recommended that this version of &os; be used instead of the &i386; version if 4 GB or more memory is required. Architectures and Processors Does &os; support architectures other than the x86? Yes. &os; divides support into multiple tiers. Tier 1 architectures, such as i386 or amd64; are fully supported. Tiers 2 and 3 are supported on an if-possible basis. A full explanation of the tier system is available in the Committer's Guide. A complete list of supported architectures can be found on the platforms page. Does &os; support Symmetric Multiprocessing (SMP)? &os; supports symmetric multi-processor (SMP) on all non-embedded platforms (e.g, &arch.i386;, &arch.amd64;, etc.). SMP is also supported in arm and MIPS kernels, although some CPUs may not support this. &os;'s SMP implementation uses fine-grained locking, and performance scales nearly linearly with number of CPUs. &man.smp.4; has more details. What is microcode? How do I install &intel; CPU microcode updates? Microcode is a method of programmatically implementating hardware level instructions. This allows for CPU bugs to be fixed without replacing the on board chip. Install sysutils/devcpu-data, then add: microcode_update_enable="YES" to /etc/rc.conf Hard Drives, Tape Drives, and CD and DVD Drives What kind of hard drives does &os; support? &os; supports EIDE, SATA, SCSI, and SAS drives (with a compatible controller; see the next section), and all drives using the original Western Digital interface (MFM, RLL, ESDI, and of course IDE). A few ESDI controllers that use proprietary interfaces may not work: stick to WD1002/3/6/7 interfaces and clones. Which SCSI or SAS controllers are supported? See the complete list in the Hardware Notes for &os; &rel.current; or &rel2.current;. What types of tape drives are supported? &os; supports all standard SCSI tape interfaces. Does &os; support tape changers? &os; supports SCSI changers using the &man.ch.4; device and the &man.chio.1; command. The details of how you actually control the changer can be found in the &man.chio.1; manual page. If you are not using AMANDA or some other product that already understands changers, remember that they only know how to move a tape from one point to another, so you need to keep track of which slot a tape is in, and which slot the tape currently in the drive needs to go back to. Which CD-ROM drives are supported by &os;? Any SCSI drive connected to a supported controller is supported. Most ATAPI compatible IDE CD-ROMs are supported. Which CD-RW drives are supported by &os;? &os; supports any ATAPI-compatible IDE CD-R or CD-RW drive. See &man.burncd.8; for details. &os; also supports any SCSI CD-R or CD-RW drives. Install and use cdrecord from the ports or packages system, and make sure that you have the pass device compiled in your kernel. Keyboards and Mice Is it possible to use a mouse in any way outside the X Window system? If you are using the default console driver, &man.syscons.4;, you can use a mouse pointer in text consoles to cut & paste text. Run the mouse daemon, &man.moused.8;, and turn on the mouse pointer in the virtual console: &prompt.root; moused -p /dev/xxxx -t yyyy &prompt.root; vidcontrol -m on Where xxxx is the mouse device name and yyyy is a protocol type for the mouse. The mouse daemon can automatically determine the protocol type of most mice, except old serial mice. Specify the auto protocol to invoke automatic detection. If automatic detection does not work, see the &man.moused.8; manual page for a list of supported protocol types. If you have a PS/2 mouse, just add moused_enable="YES" to /etc/rc.conf to start the mouse daemon at boot-time. Additionally, if you would like to use the mouse daemon on all virtual terminals instead of just the console, add allscreens_flags="-m on" to /etc/rc.conf. When the mouse daemon is running, access to the mouse must be coordinated between the mouse daemon and other programs such as X Windows. Refer to the FAQ Why does my mouse not work with X? for more details on this issue. How do I cut and paste text with a mouse in the text console? It is not possible to remove data using the mouse. However, it is possible to copy and paste. Once you get the mouse daemon running (see the previous question) hold down button 1 (left button) and move the mouse to select a region of text. Then, press button 2 (middle button) to paste it at the text cursor. Pressing button 3 (right button) will extend the selected region of text. If your mouse does not have a middle button, you may wish to emulate one or remap buttons using mouse daemon options. See the &man.moused.8; manual page for details. My mouse has a fancy wheel and buttons. Can I use them in &os;? The answer is, unfortunately, It depends. These mice with additional features require specialized driver in most cases. Unless the mouse device driver or the user program has specific support for the mouse, it will act just like a standard two, or three button mouse. For the possible usage of wheels in the X Window environment, refer to that section. How do I use my delete key in sh and csh? For the Bourne Shell, add the following lines to your .shrc. See &man.sh.1; and &man.editrc.5;. bind ^? ed-delete-next-char # for console bind ^[[3~ ed-delete-next-char # for xterm For the C Shell, add the following lines to your .cshrc. See &man.csh.1;. bindkey ^? delete-char # for console bindkey ^[[3~ delete-char # for xterm For more information, see this page. Other Hardware Workarounds for no sound from my &man.pcm.4; sound card? Some sound cards set their output volume to 0 at every boot. Run the following command every time the machine boots: &prompt.root; mixer pcm 100 vol 100 cd 100 Does &os; support power management on my laptop? &os; supports the ACPI features found in modern hardware. Further information can be found in &man.acpi.4;. Troubleshooting Why is &os; finding the wrong amount of memory on &i386; hardware? The most likely reason is the difference between physical memory addresses and virtual addresses. The convention for most PC hardware is to use the memory area between 3.5 GB and 4 GB for a special purpose (usually for PCI). This address space is used to access PCI hardware. As a result real, physical memory can not be accessed by that address space. What happens to the memory that should appear in that location is dependent on your hardware. Unfortunately, some hardware does nothing and the ability to use that last 500 MB of RAM is entirely lost. Luckily, most hardware remaps the memory to a higher location so that it can still be used. However, this can cause some confusion if you watch the boot messages. On a 32-bit version of &os;, the memory appears lost, since it will be remapped above 4 GB, which a 32-bit kernel is unable to access. In this case, the solution is to build a PAE enabled kernel. See the entry on memory limits and about different memory limits on different platforms for more information. On a 64-bit version of &os;, or when running a PAE-enabled kernel, &os; will correctly detect and remap the memory so it is usable. During boot, however, it may seem as if &os; is detecting more memory than the system really has, due to the described remapping. This is normal and the available memory will be corrected as the boot process completes. Why do my programs occasionally die with Signal 11 errors? Signal 11 errors are caused when your process has attempted to access memory which the operating system has not granted it access to. If something like this is happening at seemingly random intervals then you need to start investigating things very carefully. These problems can usually be attributed to either: If the problem is occurring only in a specific application that you are developing yourself it is probably a bug in your code. If it is a problem with part of the base &os; system, it may also be buggy code, but more often than not these problems are found and fixed long before us general FAQ readers get to use these bits of code (that is what -CURRENT is for). In particular, a dead giveaway that this is not a &os; bug is if you see the problem when you are compiling a program, but the activity that the compiler is carrying out changes each time. For example, suppose you are running make buildworld, and the compile fails while trying to compile ls.c into ls.o. If you then run make buildworld again, and the compile fails in the same place then this is a broken build — try updating your sources and try again. If the compile fails elsewhere then this is almost certainly hardware. What you should do: In the first case you can use a debugger e.g., &man.gdb.1; to find the point in the program which is attempting to access a bogus address and then fix it. In the second case you need to verify that it is not your hardware at fault. Common causes of this include: Your hard disks might be overheating: Check the fans in your case are still working, as your disk (and perhaps other hardware might be overheating). The processor running is overheating: This might be because the processor has been overclocked, or the fan on the processor might have died. In either case you need to ensure that you have hardware running at what it is specified to run at, at least while trying to solve this problem (in other words, clock it back to the default settings.) If you are overclocking then note that it is far cheaper to have a slow system than a fried system that needs replacing! Also the wider community is not often sympathetic to problems on overclocked systems, whether you believe it is safe or not. Dodgy memory: If you have multiple memory SIMMS/DIMMS installed then pull them all out and try running the machine with each SIMM or DIMM individually and narrow the problem down to either the problematic DIMM/SIMM or perhaps even a combination. Over-optimistic Motherboard settings: In your BIOS settings, and some motherboard jumpers you have options to set various timings, mostly the defaults will be sufficient, but sometimes, setting the wait states on RAM too low, or setting the RAM Speed: Turbo option, or similar in the BIOS will cause strange behavior. A possible idea is to set to BIOS defaults, but it might be worth noting down your settings first! Unclean or insufficient power to the motherboard. If you have any unused I/O boards, hard disks, or CD-ROMs in your system, try temporarily removing them or disconnecting the power cable from them, to see if your power supply can manage a smaller load. Or try another power supply, preferably one with a little more power (for instance, if your current power supply is rated at 250 Watts try one rated at 300 Watts). You should also read the SIG11 FAQ (listed below) which has excellent explanations of all these problems, albeit from a &linux; viewpoint. It also discusses how memory testing software or hardware can still pass faulty memory. Finally, if none of this has helped it is possible that you have just found a bug in &os;, and you should follow the instructions to send a problem report. There is an extensive FAQ on this at the SIG11 problem FAQ. My system crashes with either Fatal trap 12: page fault in kernel mode, or panic:, and spits out a bunch of information. What should I do? The &os; developers are very interested in these errors, but need some more information than just the error you see. Copy your full crash message. Then consult the FAQ section on kernel panics, build a debugging kernel, and get a backtrace. This might sound difficult, but you do not need any programming skills; you just have to follow the instructions. Why do I get the error maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)? The &os; kernel will only allow a certain number of processes to exist at one time. The number is based on the kern.maxusers &man.sysctl.8; variable. kern.maxusers also affects various other in-kernel limits, such as network buffers. If your machine is heavily loaded, you probably want to increase kern.maxusers. This will increase these other system limits in addition to the maximum number of processes. To adjust your kern.maxusers value, see the File/Process Limits section of the Handbook. (While that section refers to open files, the same limits apply to processes.) If your machine is lightly loaded, and you are simply running a very large number of processes, you can adjust this with the kern.maxproc tunable. If this tunable needs adjustment it needs to be defined in /boot/loader.conf. The tunable will not get adjusted until the system is rebooted. For more information about tuning tunables, see &man.loader.conf.5;. If these processes are being run by a single user, you will also need to adjust kern.maxprocperuid to be one less than your new kern.maxproc value. (It must be at least one less because one system program, &man.init.8;, must always be running.) Why does sendmail give me an error reading mail loops back to myself? You can find a detailed answer for this question in the Handbook. Why do full screen applications on remote machines misbehave? The remote machine may be setting your terminal type to something other than the cons25 terminal type required by the &os; console. There are a number of possible work-arounds for this problem: After logging on to the remote machine, set your TERM shell variable to ansi or sco if the remote machine knows about these terminal types. Use a VT100 emulator like screen at the &os; console. screen offers you the ability to run multiple concurrent sessions from one terminal, and is a neat program in its own right. Each screen window behaves like a VT100 terminal, so the TERM variable at the remote end should be set to vt100. Install the cons25 terminal database entry on the remote machine. The way to do this depends on the operating system on the remote machine. The system administration manuals for the remote system should be able to help you here. Fire up an X server at the &os; end and login to the remote machine using an X based terminal emulator such as xterm or rxvt. The TERM variable at the remote host should be set to xterm or vt100. Why does it take so long to connect to my computer via ssh or telnet? The symptom: there is a long delay between the time the TCP connection is established and the time when the client software asks for a password (or, in &man.telnet.1;'s case, when a login prompt appears). The problem: more likely than not, the delay is caused by the server software trying to resolve the client's IP address into a hostname. Many servers, including the Telnet and SSH servers that come with &os;, do this to store the hostname in a log file for future reference by the administrator. The remedy: if the problem occurs whenever you connect from your computer (the client) to any server, the problem is with the client; likewise, if the problem only occurs when someone connects to your computer (the server) the problem is with the server. If the problem is with the client, the only remedy is to fix the DNS so the server can resolve it. If this is on a local network, consider it a server problem and keep reading; conversely, if this is on the global Internet, you will most likely need to contact your ISP and ask them to fix it for you. If the problem is with the server, and this is on a local network, you need to configure the server to be able to resolve address-to-hostname queries for your local address range. See the &man.hosts.5; and &man.named.8; manual pages for more information. If this is on the global Internet, the problem may be that your server's resolver is not functioning correctly. To check, try to look up another host — say, www.yahoo.com. If it does not work, that is your problem. Following a fresh install of &os;, it is also possible that domain and name server information is missing from /etc/resolv.conf. This will often cause a delay in SSH, as the option UseDNS is set to yes by default in /etc/ssh/sshd_config. If this is causing the problem, you will either need to fill in the missing information in /etc/resolv.conf or set UseDNS to no in sshd_config as a temporary workaround. Why does file: table is full show up repeatedly in &man.dmesg.8;? This error message indicates you have exhausted the number of available file descriptors on your system. Please see the kern.maxfiles section of the Tuning Kernel Limits section of the Handbook for a discussion and solution. Why does the clock on my computer keep incorrect time? Your computer has two or more clocks, and &os; has chosen to use the wrong one. Run &man.dmesg.8;, and check for lines that contain Timecounter. The one with the highest quality value that &os; chose. &prompt.root; dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "TSC" frequency 2998570050 Hz quality 800 Timecounters tick every 1.000 msec You can confirm this by checking the kern.timecounter.hardware &man.sysctl.3;. &prompt.root; sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast It may be a broken ACPI timer. The simplest solution is to disable the ACPI timer in /boot/loader.conf: debug.acpi.disabled="timer" Or the BIOS may modify the TSC clock—perhaps to change the speed of the processor when running from batteries, or going into a power saving mode, but &os; is unaware of these adjustments, and appears to gain or lose time. In this example, the i8254 clock is also available, and can be selected by writing its name to the kern.timecounter.hardware &man.sysctl.3;. &prompt.root; sysctl kern.timecounter.hardware=i8254 kern.timecounter.hardware: TSC -> i8254 Your computer should now start keeping more accurate time. To have this change automatically run at boot time, add the following line to /etc/sysctl.conf: kern.timecounter.hardware=i8254 What does the error swap_pager: indefinite wait buffer: mean? This means that a process is trying to page memory to disk, and the page attempt has hung trying to access the disk for more than 20 seconds. It might be caused by bad blocks on the disk drive, disk wiring, cables, or any other disk I/O-related hardware. If the drive itself is actually bad, you will also see disk errors in /var/log/messages and in the output of dmesg. Otherwise, check your cables and connections. What is a lock order reversal? The &os; kernel uses a number of resource locks to arbitrate contention for certain resources. When multiple kernel threads try to obtain multiple resource locks, there's always the potential for a deadlock, where two threads have each obtained one of the locks and blocks forever waiting for the other thread to release one of the other locks. This sort of locking problem can be avoided if all threads obtain the locks in the same order. A run-time lock diagnostic system called &man.witness.4;, enabled in &os.current; and disabled by default for stable branches and releases, detects the potential for deadlocks due to locking errors, including errors caused by obtaining multiple resource locks with a different order from different parts of the kernel. The &man.witness.4; framework tries to detect this problem as it happens, and reports it by printing a message to the system console about a lock order reversal (often referred to also as LOR). It is possible to get false positives, as &man.witness.4; is conservative. A true positive report does not mean that a system is dead-locked; instead it should be understood as a warning of the form if you were unlucky, a deadlock would have happened here. Problematic LORs tend to get fixed quickly, so check &a.current.url; before posting to the mailing lists. What does Called ... with the following non-sleepable locks held mean? This means that a function that may sleep was called while a mutex (or other unsleepable) lock was held. The reason this is an error is because mutexes are not intended to be held for long periods of time; they are supposed to only be held to maintain short periods of synchronization. This programming contract allows device drivers to use mutexes to synchronize with the rest of the kernel during interrupts. Interrupts (under &os;) may not sleep. Hence it is imperative that no subsystem in the kernel block for an extended period while holding a mutex. To catch such errors, assertions may be added to the kernel that interact with the &man.witness.4; subsystem to emit a warning or fatal error (depending on the system configuration) when a potentially blocking call is made while holding a mutex. In summary, such warnings are non-fatal, however with unfortunate timing they could cause undesirable effects ranging from a minor blip in the system's responsiveness to a complete system lockup. For additional information about locking in &os; see &man.locking.9;. Why does buildworld/installworld die with the message touch: not found? This error does not mean that the &man.touch.1; utility is missing. The error is instead probably due to the dates of the files being set sometime in the future. If your CMOS-clock is set to local time you need to run the command adjkerntz -i to adjust the kernel clock when booting into single user mode. User Applications So, where are all the user applications? Please take a look at the ports page for info on software packages ported to &os;. The list currently tops &os.numports; and is growing daily, so come back to check often or subscribe to the &a.announce; for periodic updates on new entries. Most ports should work on the &rel2.relx;, and &rel.relx; branches. Each time a &os; release is made, a snapshot of the ports tree at the time of release in also included in the ports/ directory. We also support the concept of a package, essentially no more than a compressed binary distribution with a little extra intelligence embedded in it for doing whatever custom installation work is required. A package can be installed and uninstalled again easily without having to know the gory details of which files it includes. Use &man.pkg.add.1; on the specific package files you are interested in installing. Package files can usually be identified by their .tbz suffix and CD-ROM distribution people will have a packages/All directory on their CD which contains such files. They can also be downloaded over the net for various versions of &os; at the following locations: for &rel2.relx; -RELEASE/&rel2.stable; ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/&rel2.packages; for &rel.relx; -RELEASE/&rel.stable; ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/&rel.packages; or your nearest local mirror site. Note that all ports may not be available as packages since new ones are constantly being added. It is always a good idea to check back periodically to see which packages are available at the ftp.FreeBSD.org master site. How do I download the Ports tree? Should I be using SVN? Any of the methods listed here work: Use portsnap for most use cases. Use SVN directly if you need custom patches to the ports tree. Use CTM if you prefer getting patches by email (this is a rarer use case). Any other method should be considered a legacy method. If you do not already use them, do not start. Does &os; support &java;? Yes. Please see http://www.FreeBSD.org/java/. Why can I not build this port on my &rel2.relx; -, or &rel.relx; -STABLE machine? If you are running a &os; version that lags significantly behind -CURRENT or -STABLE, you may need to update your Ports Collection; see the Keeping Up section of the Porter's Handbook for further information on how to do this. If you are up to date, then someone might have committed a change to the port which works for -CURRENT but which broke the port for -STABLE. Please submit a bug report on this with the &man.send-pr.1; command, since the Ports Collection is supposed to work for both the -CURRENT and -STABLE branches. I just tried to build INDEX using make index, and it failed. Why? First, always make sure that you have a complete up-to-date Ports Collection. Errors that affect building INDEX from an up-to-date copy of the Ports Collection are high-visibility and are thus almost always fixed immediately. There are rare cases where INDEX will not build due to odd cases involving WITH_* or WITHOUT_* variables being set in make.conf. If you suspect that this is the case, please try to make INDEX with those make variables turned off before reporting it to &a.ports;. I updated the sources, now how do I update my installed ports? &os; does not include a port upgrading tool, but it does have some tools to make the upgrade process somewhat easier. You can also install additional tools to simplify port handling, see the Upgrading Ports section in the &os; Handbook. Do I need to recompile every port each time I perform a major version update? By all means! While a recent system will run with software compiled under an older release, you will end up with things randomly crashing and failing to work once you start installing other ports or updating a portion of what you already have. When the system is upgraded, various shared libraries, loadable modules, and other parts of the system will be replaced with newer versions. Applications linked against the older versions may fail to start or, in other cases, fail to function properly. For more information, see the section on upgrades in the &os; Handbook. Do I need to recompile every port each time I perform a minor version update? In general, no. &os; developers do their utmost to guarantee binary compatibility across all releases with the same major version number. Any exceptions will be documented in the Release Notes, and advice given there should be followed. Why is /bin/sh so minimal? Why does &os; not use bash or another shell? Many people need to write shell scripts which will be portable across many systems. That is why &posix; specifies the shell and utility commands in great detail. Most scripts are written in Bourne shell (&man.sh.1;), and because several important programming interfaces (&man.make.1;, &man.system.3;, &man.popen.3;, and analogues in higher-level scripting languages like Perl and Tcl) are specified to use the Bourne shell to interpret commands. Because the Bourne shell is so often and widely used, it is important for it to be quick to start, be deterministic in its behavior, and have a small memory footprint. The existing implementation is our best effort at meeting as many of these requirements simultaneously as we can. To keep /bin/sh small, we have not provided many of the convenience features that other shells have. That is why other more featureful shells like bash, scsh, &man.tcsh.1;, and zsh are available. (You can compare for yourself the memory utilization of all these shells by looking at the VSZ and RSS columns in a ps listing.) How do I create audio CDs from my MIDI files? To create audio CDs from MIDI files, first install audio/timidity++ from ports then install manually the GUS patches set by Eric A. Welsh, available at . After TiMidity++ has been installed properly, MIDI files may be converted to WAV files with the following command line: &prompt.user; timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid The WAV files can then be converted to other formats or burned onto audio CDs, as described in the &os; Handbook. Where can I get an Office Suite for &os;? The open-source Apache OpenOffice and LibreOffice office suites work natively on &os;. &os; also includes a variety of text editors, spreadsheets, and drawing programs in the Ports Collection. How can I convert from pkgng to the old package tools? Short answer: it is not possible. Longer answer: if you have made any changes using pkg converting back is non-trivial and requires lots of manual editing of internal package database files. However, if you have just run pkg2ng then you may remove /var/db/pkg/local.sqlite and extract /var/backups/pkgdb.bak.tbz. Kernel Configuration I would like to customize my kernel. Is it difficult? Not at all! Check out the kernel config section of the Handbook. The new kernel will be installed to the /boot/kernel directory along with its modules, while the old kernel and its modules will be moved to the /boot/kernel.old directory, so if you make a mistake the next time you play with your configuration you can boot the previous version of your kernel. Why is my kernel so big? GENERIC kernels shipped with &os; and later are compiled in debug mode. Kernels built in debug mode contain many symbols in separate files that are used for debugging, thus greatly increasing the size of /boot/kernel/. Note that there will be little or no performance loss from running a debug kernel, and it is useful to keep one around in case of a system panic. However, if you are running low on disk space, there are different options to reduce the size of /boot/kernel/. If you do not want the symbol files to be installed, make sure you have the following line present in /etc/src.conf: WITHOUT_KERNEL_SYMBOLS=yes For more information see &man.src.conf.5;. If you do not want to build a debug kernel, make sure that both of the following are true: You do not have a line in your kernel configuration file that reads: makeoptions DEBUG=-g You are not running &man.config.8; with . Either of the above settings will cause your kernel to be built in debug mode. As long as you make sure you follow the steps above, you can build your kernel normally. If you want only the modules you use to be built and installed, make sure you have a line like below in /etc/make.conf: MODULES_OVERRIDE= accf_http ipfw Replace accf_httpd ipfw with a list of modules you need. Only these modules will be built. This does not only reduce the size of the kernel directory but also decreases the amount of time needed to build your kernel. For more information see /usr/share/examples/etc/make.conf. You can also remove unneeded devices from your kernel to further reduce the size. See for more information. To put any of these options into effect you will have to build and install your new kernel. Most kernels (/boot/kernel/kernel) tend to be around 12 MB to 16 MB. Why does every kernel I try to build fail to compile, even GENERIC? There are a number of possible causes for this problem. They are, in no particular order: You are not using the make buildkernel and make installkernel targets, and your source tree is different from the one used to build the currently running system (e.g., you are compiling &rel.current;-RELEASE on a &rel2.current;-RELEASE system). If you are attempting an upgrade, please read /usr/src/UPDATING, paying particular attention to the COMMON ITEMS section at the end. You are using the make buildkernel and make installkernel targets, but you failed to assert the completion of the make buildworld target. The make buildkernel target relies on files generated by the make buildworld target to complete its job correctly. Even if you are trying to build &os;-STABLE, it is possible that you fetched the source tree at a time when it was either being modified, or broken for other reasons; only releases are absolutely guaranteed to be buildable, although &os;-STABLE builds fine the majority of the time. If you have not already done so, try re-fetching the source tree and see if the problem goes away. Try using a different server in case the one you are using is having problems. How can I verify which scheduler is in use on a running system? The name of the scheduler currently being used is directly available as the value of the kern.sched.name sysctl: &prompt.user; sysctl kern.sched.name kern.sched.name: ULE What is kern.sched.quantum? kern.sched.quantum is the maximum number of ticks a process can run without being preempted in the 4BSD scheduler. Disks, File Systems, and Boot Loaders How can I add my new hard disk to my &os; system? See the Adding Disks section in the &os; Handbook. How do I move my system over to my huge new disk? The best way is to reinstall the OS on the new disk, then move the user data over. This is highly recommended if you have been tracking -STABLE for more than one release, or have updated a release instead of installing a new one. You can install booteasy on both disks with &man.boot0cfg.8;, and dual boot them until you are happy with the new configuration. Skip the next paragraph to find out how to move the data after doing this. Alternatively, partition and label the new disk with either &man.sade.8; or &man.gpart.8;. If the disks are MBR-formatted, you can also install booteasy on both disks with &man.boot0cfg.8;, so that you can dual boot to the old or new system after the copying is done. Now you have the new disk set up, and are ready to move the data. Unfortunately, you cannot just blindly copy the data. Things like device files (in /dev), flags, and links tend to screw that up. You need to use tools that understand these things, which means &man.dump.8;. Although it is suggested that you move the data in single user mode, it is not required. You should never use anything but &man.dump.8; and &man.restore.8; to move the root file system. The &man.tar.1; command may work — then again, it may not. You should also use &man.dump.8; and &man.restore.8; if you are moving a single partition to another empty partition. The sequence of steps to use dump to move a partitions data to a new partition is: newfs the new partition. mount it on a temporary mount point. cd to that directory. dump the old partition, piping output to the new one. For example, if you are going to move root to /dev/ada1s1a, with /mnt as the temporary mount point, it is: &prompt.root; newfs /dev/ada1s1a &prompt.root; mount /dev/ada1s1a /mnt &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - Rearranging your partitions with dump takes a bit more work. To merge a partition like /var into its parent, create the new partition large enough for both, move the parent partition as described above, then move the child partition into the empty directory that the first move created: &prompt.root; newfs /dev/ada1s1a &prompt.root; mount /dev/ada1s1a /mnt &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - &prompt.root; cd var &prompt.root; dump 0af - /var | restore rf - To split a directory from its parent, say putting /var on its own partition when it was not before, create both partitions, then mount the child partition on the appropriate directory in the temporary mount point, then move the old single partition: &prompt.root; newfs /dev/ada1s1a &prompt.root; newfs /dev/ada1s1d &prompt.root; mount /dev/ada1s1a /mnt &prompt.root; mkdir /mnt/var &prompt.root; mount /dev/ada1s1d /mnt/var &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore rf - You might prefer &man.cpio.1;, &man.pax.1;, &man.tar.1; to &man.dump.8; for user data. At the time of this writing, these are known to lose file flag information, so use them with caution. Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems. What about Journaled Soft Updates? Short answer: you can usually use Soft Updates safely on all partitions. Long answer: Soft Updates has two characteristics that may be undesirable on certain paritions. First, a Soft Updates partition has a small chance of losing data during a system crash. (The partition will not be corrupted; the data will simply be lost.) Second, Soft Updates can cause temporary space shortages. When using Soft Updates, the kernel can take up to thirty seconds to write changes to the physical disk. When a large file is deleted the file still resides on disk until the kernel actually performs the deletion. This can cause a very simple race condition. Suppose you delete one large file and immediately create another large file. The first large file is not yet actually removed from the physical disk, so the disk might not have enough room for the second large file. You get an error that the partition does not have enough space, although you know perfectly well that you just released a large chunk of space! When you try again mere seconds later, the file creation works as you expect. This has left more than one user scratching his head and doubting his sanity, the &os; file system, or both. If a system should crash after the kernel accepts a chunk of data for writing to disk, but before that data is actually written out, data could be lost. This risk is extremely small, but generally manageable. These issues affect all partitions using Soft Updates. So, what does this mean for the root partition? Vital information on the root partition changes very rarely. If the system crashed during the thirty-second window after such a change is made, it is possible that data could be lost. This risk is negligible for most applications, but you should be aware that it exists. If your system cannot tolerate this much risk, do not use Soft Updates on the root file system! / is traditionally one of the smallest partitions. If you put the /tmp directory on / and you have a busy /tmp, you might see intermittent space problems. Symlinking /tmp to /var/tmp will solve this problem. Finally, &man.dump.8; does not work in live mode (-L) on a filesystem, with Journaled Soft Updates (SU+J). Can I mount other foreign file systems under &os;? &os; supports a variety of other file systems. UFS UFS CD-ROMs can be mounted directly on &os;. Mounting disk partitions from Digital UNIX and other systems that support UFS may be more complex, depending on the details of the disk partitioning for the operating system in question. ext2/ext3 &os; supports ext2fs and ext3fs partitions. See &man.ext2fs.5; for more information. NTFS FUSE based NTFS support is available as a port (sysutils/fusefs-ntfs). For more information see ntfs-3g. FAT &os; includes a read-write FAT driver. For more information, see &man.mount.msdosfs.8;. ZFS &os; includes a port of &sun;'s ZFS driver. The current recommendation is to use it only on &arch.amd64; platforms with sufficient memory. For more information, see &man.zfs.8;. &os; also supports network file systems such as NFS (see &man.mount.nfs.8;), NetWare (see &man.mount.nwfs.8;), and Microsoft-style SMB file systems (see &man.mount.smbfs.8;). You can find ports based on FUSE (sysutils/fusefs-kmod) for many other file systems. How do I mount a secondary DOS partition? The secondary DOS partitions are found after all the primary partitions. For example, if you have an E partition as the second DOS partition on the second SCSI drive, there will be a device file for slice 5 in /dev, so simply mount it: &prompt.root; mount -t msdosfs /dev/da1s5 /dos/e Is there a cryptographic file system for &os;? Yes. You can use either &man.gbde.8; or &man.geli.8;, see the Encrypting Disk Partitions section of the &os; Handbook. How can I use the &windowsnt; loader to boot &os;? The general idea is that you copy the first sector of your native root &os; partition into a file in the DOS/&windowsnt; partition. Assuming you name that file something like c:\bootsect.bsd (inspired by c:\bootsect.dos), you can then edit c:\boot.ini to come up with something like this: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" C:\BOOTSECT.BSD="&os;" C:\="DOS" If &os; is installed on the same disk as the &windowsnt; boot partition simply copy /boot/boot1 to C:\BOOTSECT.BSD. However, if &os; is installed on a different disk /boot/boot1 will not work, /boot/boot0 is needed. /boot/boot0 needs to be installed using &man.sysinstall.8; by selecting the &os; boot manager on the screen which asks if you wish to use a boot manager. This is because /boot/boot0 has the partition table area filled with NULL characters but &man.sysinstall.8; copies the partition table before copying /boot/boot0 to the MBR. Do not simply copy /boot/boot0 instead of /boot/boot1; you will overwrite your partition table and render your computer un-bootable! When the &os; boot manager runs it records the last OS booted by setting the active flag on the partition table entry for that OS and then writes the whole 512-bytes of itself back to the MBR so if you just copy /boot/boot0 to C:\BOOTSECT.BSD then it writes an empty partition table, with the active flag set on one entry, to the MBR. How do I boot &os; and &linux; from LILO? If you have &os; and &linux; on the same disk, just follow LILO's installation instructions for booting a non-&linux; operating system. Very briefly, these are: Boot &linux;, and add the following lines to /etc/lilo.conf: other=/dev/hda2 table=/dev/hda label=&os; (the above assumes that your &os; slice is known to &linux; as /dev/hda2; tailor to suit your setup). Then, run lilo as root and you should be done. If &os; resides on another disk, you need to add loader=/boot/chain.b to the LILO entry. For example: other=/dev/dab4 table=/dev/dab loader=/boot/chain.b label=&os; In some cases you may need to specify the BIOS drive number to the &os; boot loader to successfully boot off the second disk. For example, if your &os; SCSI disk is probed by BIOS as BIOS disk 1, at the &os; boot loader prompt you need to specify: Boot: 1:da(0,a)/boot/kernel/kernel You can configure &man.boot.8; to automatically do this for you at boot time. The &linux;+&os; mini-HOWTO is a good reference for &os; and &linux; interoperability issues. How do I boot &os; and &linux; using GRUB? Booting &os; using GRUB is very simple. Just add the following to your configuration file /boot/grub/menu.lst (or /boot/grub/grub.conf in some systems, e.g., Red Hat Linux and its derivatives). title &os; 6.1 root (hd0,a) kernel /boot/loader Where hd0,a points to your root partition on the first disk. If you need to specify which slice number should be used, use something like this (hd0,2,a). By default, if the slice number is omitted, GRUB searches the first slice which has a partition. How do I boot &os; and &linux; using BootEasy? Install LILO at the start of your &linux; boot partition instead of in the Master Boot Record. You can then boot LILO from BootEasy. If you are running &windows; and &linux; this is recommended anyway, to make it simpler to get &linux; booting again if you should need to reinstall &windows; (which is a Jealous Operating System, and will bear no other Operating Systems in the Master Boot Record). How do I change the boot prompt from ??? to something more meaningful? You can not do that with the standard boot manager without rewriting it. There are a number of other boot managers in the sysutils ports category that provide this functionality. I have a new removable drive, how do I use it? If the drive already has a file system on it, you can use a command like this: &prompt.root; mount -t msdosfs /dev/da0s1 /mnt If the drive will only be used with &os; systems it is better idea to stick a BSD file system on it, like UFS or ZFS. You will get long filename support, at least a 2X improvement in performance, and a lot more stability. If the drive will be used by other operating systems a more portable choice, such as msdosfs, is better. &prompt.root; dd if=/dev/zero of=/dev/da0 count=2 &prompt.root; gpart create -s GPT /dev/da0 &prompt.root; gpart add -t freebsd-ufs /dev/da0 Finally, create a new file system: &prompt.root; newfs /dev/da0p1 and mount it: &prompt.root; mount /dev/da0s1 /mnt It is a good idea to add a line to /etc/fstab (see &man.fstab.5;) so you can just type mount /mnt in the future: /dev/da0p1 /mnt ufs rw,noauto 0 0 Why do I get Incorrect super block when mounting a CD-ROM? You have to tell &man.mount.8; the type of the device that you want to mount. This is described in the Handbook section on optical media, specifically the section Using Data CDs. Why do I get Device not configured when mounting a CD-ROM? This generally means that there is no CD-ROM in the CD-ROM drive, or the drive is not visible on the bus. Please see the Using Data CDs section of the Handbook for a detailed discussion of this issue. Why do all non-English characters in filenames show up as ? on my CDs when mounted in &os;? Your CD-ROM probably uses the Joliet extension for storing information about files and directories. This is discussed in the Handbook chapter on creating and using CD-ROMs, specifically the section on Using Data CD-ROMs. I burned a CD under &os; and now I can not read it under any other operating system. Why? You most likely burned a raw file to your CD, rather than creating an ISO 9660 file system. Take a look at the Handbook chapter on creating CD-ROMs, particularly the section on burning raw data CDs. How can I create an image of a data CD? This is discussed in the Handbook section on duplicating data CDs. For more on working with CD-ROMs, see the Creating CDs Section in the Storage chapter in the Handbook. Why can I not mount an audio CD? If you try to mount an audio CD, you will get an error like cd9660: /dev/acd0c: Invalid argument. This is because mount only works on file systems. Audio CDs do not have file systems; they just have data. You need a program that reads audio CDs, such as the audio/xmcd port. How do I mount a multi-session CD? By default, &man.mount.8; will attempt to mount the last data track (session) of a CD. If you would like to load an earlier session, you must use the command line argument. Please see &man.mount.cd9660.8; for specific examples. How do I let ordinary users mount CD-ROMs, DVDs, USB drives, and other removable media? As root set the sysctl variable vfs.usermount to 1. &prompt.root; sysctl vfs.usermount=1 To make this persist across reboots, add the line vfs.usermount=1 to /etc/sysctl.conf so that it is reset at system boot time. Users can only mount devices they have read permissions to. To allow users to mount a device permissions must be set in /etc/devfs.conf. For example, to allow users to mount the first USB drive add: # Allow all users to mount a USB drive. own /dev/da0 root:operator perm /dev/da00 0666 All users can now mount devices they could read onto a directory that they own: &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t msdosfs /dev/da0~/my-mount-point Unmounting the device is simple: &prompt.user; umount ~/my-mount-point Enabling vfs.usermount, however, has negative security implications. A better way to access &ms-dos; formatted media is to use the emulators/mtools package in the Ports Collection. The device name used in the previous examples must be changed according to your configuration. The du and df commands show different amounts of disk space available. What is going on? You need to understand what du and df really do. du goes through the directory tree, measures how large each file is, and presents the totals. df just asks the file system how much space it has left. They seem to be the same thing, but a file without a directory entry will affect df but not du. When a program is using a file, and you delete the file, the file is not really removed from the file system until the program stops using it. The file is immediately deleted from the directory listing, however. You can see this easily enough with a program such as more. Assume you have a file large enough that its presence affects the output of du and df. (Since disks can be so large today, this might be a very large file!) If you delete this file while using more on it, more does not immediately choke and complain that it cannot view the file. The entry is simply removed from the directory so no other program or user can access it. du shows that it is gone — it has walked the directory tree and the file is not listed. df shows that it is still there, as the file system knows that more is still using that space. Once you end the more session, du and df will agree. This situation is common on web servers. Many people set up a &os; web server and forget to rotate the log files. The access log fills up /var. The new administrator deletes the file, but the system still complains that the partition is full. Stopping and restarting the web server program would free the file, allowing the system to release the disk space. To prevent this from happening, set up &man.newsyslog.8;. Note that Soft Updates can delay the freeing of disk space; you might need to wait up to 30 seconds for the change to be visible! How can I add more swap space? In the Configuration and Tuning section of the Handbook, you will find a section describing how to do this. Why does &os; see my disk as smaller than the manufacturer says it is? Disk manufacturers calculate gigabytes as a billion bytes each, whereas &os; calculates them as 1,073,741,824 bytes each. This explains why, for example, &os;'s boot messages will report a disk that supposedly has 80 GB as holding 76,319 MB. Also note that &os; will (by default) reserve 8% of the disk space. How is it possible for a partition to be more than 100% full? A portion of each UFS partition (8%, by default) is reserved for use by the operating system and the root user. &man.df.1; does not count that space when calculating the Capacity column, so it can exceed 100%. Also, you will notice that the Blocks column is always greater than the sum of the Used and Avail columns, usually by a factor of 8%. For more details, look up in &man.tunefs.8;. ZFS What is the minimum amount of RAM one should have to run ZFS? A minimum of 4GB of RAM is required for comfortable usage, but individual workloads can vary widely. What is the ZIL and when does it get used? The ZIL ((ZFS intent log) is a write log used to implement posix write commitment semantics across crashes. Normally writes are bundled up into transaction groups and written to disk when filled (Transaction Group Commit). However syscalls like &man.fsync.2; require a commitment that the data is written to stable storage before returning. The ZIL is needed for writes that have been acknowledged as written but which are not yet on disk as part of a transaction. The transaction groups are timestamped. In the event of a crash the last valid timestamp is found and missing data is merged in from the ZIL. Do I need a SSD for ZIL? By default, ZFS stores the ZIL in the pool with all the data. If your application has a heavy write load, storing the ZIL in a separate device that has very fast synchronous, sequential write performance can improve overall system. For other workloads, a SSD is unlikely to make much of an improvement. What is the L2ARC? The L2ARC is a read cache stored on a fast device such as an SSD. This cache is not persisent across reboots. Note that RAM is used as the first layer of cache and the L2ARC is only needed if there is insufficient RAM. L2ARC needs space in the ARC to index it. So, perversely, a working set that fits perfectly in the ARC will not fit perfectly any more if a L2ARC is used because part of the ARC is holding the L2ARC index, pushing part of the working set into the L2ARC which is slower than RAM. Is enabling deduplication advisable? Generally speaking, no. Deduplication takes up a significant amount of RAM and may slow down read and write disk access times. Unless one is storing data that is very heavily duplicated (such as virtual machine images, or user backups) it is possible that deduplication will do more harm than good. Another consideration is the inability to revert deduplication status. If data is written when deduplication is enabled, disabling dedup will not cause those blocks which were deduplicated to be replicated until they are next modified. Deduplication can also lead to some unexpected situations. In particular deleting files may become much slower. I can not delete or create files on my ZFS pool. How can I fix this? This could happen because the pool is 100% full. ZFS requires space on the disk to write transaction metadata. To restore the pool to a usable state, truncate a file you want to delete. &prompt.user; truncate -s 0 unimportant-file File truncation works because a new transaction is not started, new spare blocks are created instead. On systems with additional ZFS dataset tuning, such as deduplication, the space may not be immediately available Does ZFS support TRIM for Solid State Drives? ZFS TRIM support was added to &os; 10-CURRENT with revision r240868. ZFS TRIM support is not yet available on the -STABLE branches. ZFS TRIM is enabled by default, and can be turned off by adding this line to /etc/sysctl.conf: vfs.zfs.trim_disable=1 ZFS TRIM may not work with all configurations, such as a ZFS filesystem on a GELI-backed device. System Administration Where are the system start-up configuration files? The primary configuration file is /etc/defaults/rc.conf (see &man.rc.conf.5;). System startup scripts such as /etc/rc and /etc/rc.d (see &man.rc.8;) just include this file. Do not edit this file! Instead, if there is any entry in /etc/defaults/rc.conf that you want to change, you should copy the line into /etc/rc.conf and change it there. For example, if you wish to start &man.named.8;, the included DNS server, all you need to do is: &prompt.root; echo 'named_enable="YES"' >> /etc/rc.conf To start up local services, place shell scripts in the /usr/local/etc/rc.d directory. These shell scripts should be set executable, the default file mode is 555. How do I add a user easily? Use the &man.adduser.8; command, or the &man.pw.8; command for more complicated situations. To remove the user, use the &man.rmuser.8; command or, if necessary, &man.pw.8;. Why do I keep getting messages like root: not found after editing /etc/crontab This is normally caused by editing the system crontab (/etc/crontab) and then using &man.crontab.1; to install it: &prompt.root; crontab /etc/crontab This is not the correct way to do things. The system crontab has a different format to the per-user crontabs which &man.crontab.1; updates (the &man.crontab.5; manual page explains the differences in more detail). If this is what you did, the extra crontab is simply a copy of /etc/crontab in the wrong format it. Delete it with the command: &prompt.root; crontab -r Next time, when you edit /etc/crontab, you should not do anything to inform &man.cron.8; of the changes, since it will notice them automatically. If you want something to be run once per day, week, or month, it is probably better to add shell scripts /usr/local/etc/periodic, and let the &man.periodic.8; command run from the system cron schedule it with the other periodic system tasks. The actual reason for the error is that the system crontab has an extra field, specifying which user to run the command as. In the default system crontab provided with &os;, this is root for all entries. When this crontab is used as the root user's crontab (which is not the same as the system crontab), &man.cron.8; assumes the string root is the first word of the command to execute, but no such command exists. Why do I get the error, you are not in the correct group to su root when I try to su to root? This is a security feature. To su to root (or any other account with superuser privileges), you must be in the wheel group. If this feature were not there, anybody with an account on a system who also found out root's password would be able to gain superuser level access to the system. With this feature, this is not strictly true; &man.su.1; will prevent them from even trying to enter the password if they are not in wheel. To allow someone to su to root, simply put them in the wheel group. Use &man.pw.8; for this purpose. &prompt.root; pw groupmod wheel -m lisa The above example will add user lisa to the group wheel. I made a mistake in rc.conf, or another startup file, and now I cannot edit it because the file system is read-only. What should I do? Restart the system using boot -s at the loader prompt to enter Single User mode. When prompted for a shell pathname, simply press Enter, and run mount -urw / to re-mount the root file system in read/write mode. You may also need to run mount -a -t ufs to mount the file system where your favorite editor is defined. If your favorite editor is on a network file system, you will need to either configure the network manually before you can mount network file systems, or use an editor which resides on a local file system, such as &man.ed.1;. If you intend to use a full screen editor such as &man.vi.1; or &man.emacs.1;, you may also need to run export TERM=xterm on &os; 9.0+, or export TERM=cons25 on &os; 8.X so that these editors can load the correct data from the &man.termcap.5; database. Once you have performed these steps, you can edit /etc/rc.conf as you usually would to fix the syntax error. The error message displayed immediately after the kernel boot messages should tell you the number of the line in the file which is at fault. Why am I having trouble setting up my printer? See the Handbook entry on printing. It should cover most of your problem. Some printers require a host-based driver to do any kind of printing. These so-called WinPrinters are not natively supported by &os;. If your printer does not work in DOS or &windows;, it is probably a WinPrinter. Your only hope of getting one of these to work is to check if the print/pnm2ppa port supports it. How can I correct the keyboard mappings for my system? Please see the Handbook section on using localization, specifically the section on console setup. Why can I not get user quotas to work properly? It is possible that your kernel is not configured to use quotas. If this is the case, you will need to add the following line to your kernel configuration file and recompile: options QUOTA Please read the Handbook entry on quotas for full details. Do not turn on quotas on /. Put the quota file on the file system that the quotas are to be enforced on, i.e.: File System Quota file /usr /usr/admin/quotas /home /home/admin/quotas … … Does &os; support System V IPC primitives? Yes, &os; supports System V-style IPC, including shared memory, messages and semaphores, in the GENERIC kernel. With a custom kernel, support may be loaded with the sysvshm.ko, sysvsem.ko and sysvmsg.ko kernel modules, or enabled in the custom kernel by adding the following lines to your kernel config: options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging Recompile and install your kernel. What other mail-server software can I use instead of sendmail? The sendmail server is the default mail-server software for &os;, but you can easily replace it with one of the other MTA (for instance, an MTA installed from the ports). There are various alternative MTAs in the ports tree already, with mail/exim, mail/postfix, mail/qmail, and mail/zmailer being some of the most popular choices. Diversity is nice, and the fact that you have many different mail-servers to chose from is considered a good thing; therefore try to avoid asking questions like Is sendmail better than qmail? in the mailing lists. If you do feel like asking, first check the mailing list archives. The advantages and disadvantages of each and every one of the available MTAs have already been discussed a few times. I have forgotten the root password! What do I do? Do not panic! Restart the system, type boot -s at the Boot: prompt to enter Single User mode. At the question about the shell to use, hit Enter. You will be dropped to a &prompt.root; prompt. Enter mount -urw / to remount your root file system read/write, then run mount -a to remount all the file systems. Run passwd root to change the root password then run &man.exit.1; to continue booting. If you are still prompted to give the root password when entering the Single User mode, it means that the console has been marked as insecure in /etc/ttys. In this case it will be required to boot from a &os; installation disk, choose the Live CD or Shell at the beginning of the install process and issue the commands mentioned above. You will need to mount the specific partition in this case and then chroot to it, i.e., replace mount -urw / by mount /dev/ada0p1 /mnt; chroot /mnt for a system on ada0p1. If you cannot mount your root partition from Single User mode, it is possible that the partitions are encrypted and it is impossible to mount them without the access keys. Your chances depend on the chosen implementation. For more information see the section about encrypted disks in the &os; Handbook. How do I keep ControlAltDelete from rebooting the system? If you are using &man.syscons.4; (the default console driver) build and install a new kernel with the line in the configuration file: options SC_DISABLE_REBOOT This can also be done by setting the following &man.sysctl.8; which does not require a reboot or kernel recompile: &prompt.root; sysctl hw.syscons.kbd_reboot=0 The above two methods are exclusive: The &man.sysctl.8; does not exist if you compile your kernel with the SC_DISABLE_REBOOT option. How do I reformat DOS text files to &unix; ones? Use this &man.perl.1; command: &prompt.user; perl -i.bak -npe 's/\r\n/\n/g' file(s) where file(s) is one or more files to process. The modification is done in-place, with the original file stored with a .bak extension. Alternatively you can use the &man.tr.1; command: &prompt.user; tr -d '\r' < dos-text-file > unix-file dos-text-file is the file containing DOS text while unix-file will contain the converted output. This can be quite a bit faster than using perl. Yet another way to reformat DOS text files is to use the converters/dosunix port from the Ports Collection. Consult its documentation about the details. How do I kill processes by name? Use &man.pkill.1;. How do I re-read /etc/rc.conf and re-start /etc/rc without a reboot? Go into single user mode and then back to multi user mode. On the console do: &prompt.root; shutdown now (Note: without -r or -h) &prompt.root; return &prompt.root; exit I tried to update my system to the latest -STABLE, but got -BETAx, -RC or -PRERELEASE! What is going on? Short answer: it is just a name. RC stands for Release Candidate. It signifies that a release is imminent. In &os;, -PRERELEASE is typically synonymous with the code freeze before a release. (For some releases, the -BETA label was used in the same way as -PRERELEASE.) Long answer: &os; derives its releases from one of two places. Major, dot-zero, releases, such as 9.0-RELEASE are branched from the head of the development stream, commonly referred to as -CURRENT. Minor releases, such as 6.3-RELEASE or 5.2-RELEASE, have been snapshots of the active -STABLE branch. Starting with 4.3-RELEASE, each release also now has its own branch which can be tracked by people requiring an extremely conservative rate of development (typically only security advisories). When a release is about to be made, the branch from which it will be derived from has to undergo a certain process. Part of this process is a code freeze. When a code freeze is initiated, the name of the branch is changed to reflect that it is about to become a release. For example, if the branch used to be called 6.2-STABLE, its name will be changed to 6.3-PRERELEASE to signify the code freeze and signify that extra pre-release testing should be happening. Bug fixes can still be committed to be part of the release. When the source code is in shape for the release the name will be changed to 6.3-RC to signify that a release is about to be made from it. Once in the RC stage, only the most critical bugs found can be fixed. Once the release (6.3-RELEASE in this example) and release branch have been made, the branch will be renamed to 6.3-STABLE. For more information on version numbers and the various Subversion branches, refer to the Release Engineering article. I tried to install a new kernel, and the &man.chflags.1; failed. How do I get around this? Short answer: You are probably at security level greater than 0. Reboot directly to Single User mode to install the kernel. Long answer: &os; disallows changing system flags at security levels greater than 0. You can check your security level with the command: &prompt.root; sysctl kern.securelevel You cannot lower the security level; you have to boot to Single Mode to install the kernel, or change the security level in /etc/rc.conf then reboot. See the &man.init.8; manual page for details on securelevel, and see /etc/defaults/rc.conf and the &man.rc.conf.5; manual page for more information on rc.conf. I cannot change the time on my system by more than one second! How do I get around this? Short answer: You are probably at security level greater than 1. Reboot directly to Single User mode to change the date. Long answer: &os; disallows changing the time by more that one second at security levels greater than 1. You can check your security level with the command: &prompt.root; sysctl kern.securelevel You cannot lower the security level; you have to boot to Single User mode to change the date, or change the security level in /etc/rc.conf then reboot. See the &man.init.8; manual page for details on securelevel, and see /etc/defaults/rc.conf and the &man.rc.conf.5; manual page for more information on rc.conf. Why is rpc.statd using 256 MB of memory? No, there is no memory leak, and it is not using 256 MB of memory. For convenience, rpc.statd maps an obscene amount of memory into its address space. There is nothing terribly wrong with this from a technical standpoint; it just throws off things like &man.top.1; and &man.ps.1;. &man.rpc.statd.8; maps its status file (resident on /var) into its address space; to save worrying about remapping it later when it needs to grow, it maps it with a generous size. This is very evident from the source code, where one can see that the length argument to &man.mmap.2; is 0x10000000, or one sixteenth of the address space on an IA32, or exactly 256 MB. Why can I not unset the schg file flag? You are running at an elevated (i.e., greater than 0) securelevel. Lower the securelevel and try again. For more information, see the FAQ entry on securelevel and the &man.init.8; manual page. Why does SSH authentication through .shosts not work by default in recent versions of &os;? The reason why .shosts authentication does not work by default in more recent versions of &os; is because &man.ssh.1; is not installed suid root by default. To fix this, you can do one of the following: As a permanent fix, set ENABLE_SUID_SSH to true in /etc/make.conf then rebuild and reinstall &man.ssh.1;. As a temporary fix, change the mode on /usr/bin/ssh to 4555 by running chmod 4555 /usr/bin/ssh as root. What is vnlru? vnlru flushes and frees vnodes when the system hits the kern.maxvnodes limit. This kernel thread sits mostly idle, and only activates if you have a huge amount of RAM and are accessing tens of thousands of tiny files. What do the various memory states displayed by top mean? Active: pages recently statistically used. Inactive: pages recently statistically unused. Cache: (most often) pages that have percolated from inactive to a status where they maintain their data, but can often be immediately reused (either with their old association, or reused with a new association). There can be certain immediate transitions from active to cache state if the page is known to be clean (unmodified), but that transition is a matter of policy, depending upon the algorithm choice of the VM system maintainer. Free: pages without data content, and can be immediately used in certain circumstances where cache pages might be ineligible. Free pages can be reused at interrupt or process state. Wired: pages that are fixed into memory, usually for kernel purposes, but also sometimes for special use in processes. Pages are most often written to disk (sort of a VM sync) when they are in the inactive state, but active pages can also be synced. This depends upon the CPU tracking of the modified bit being available, and in certain situations there can be an advantage for a block of VM pages to be synced, whether they are active or inactive. In most common cases, it is best to think of the inactive queue to be a queue of relatively unused pages that might or might not be in the process of being written to disk. Cached pages are already synced, not mapped, but available for immediate process use with their old association or with a new association. Free pages are available at interrupt level, but cached or free pages can be used at process state for reuse. Cache pages are not adequately locked to be available at interrupt level. There are some other flags (e.g., busy flag or busy count) that might modify some of the described rules. How much free memory is available? There are a couple of kinds of free memory. One kind is the amount of memory immediately available without paging anything else out. That is approximately the size of cache queue + size of free queue (with a derating factor, depending upon system tuning). Another kind of free memory is the total amount of VM space. That can be complex, but is dependent upon the amount of swap space and memory. Other kinds of free memory descriptions are also possible, but it is relatively useless to define these, but rather it is important to make sure that the paging rate is kept low, and to avoid running out of swap space. What is /var/empty? I can not delete it! /var/empty is a directory that the &man.sshd.8; program uses when performing privilege separation. The /var/empty directory is empty, owned by root and has the schg flag set. Although it is not recommended to delete this directory, to do so you will need to unset the schg flag first. See the &man.chflags.1; manual page for more information (and bear in mind the answer to the question on unsetting the schg flag). I just changed /etc/newsyslog.conf. How can I check if it does what I expect? To see what &man.newsyslog.8; will do use the following: &prompt.user; newsyslog -nrvv My time is wrong, how can I change the timezone? Use &man.tzsetup.8;. The X Window System and Virtual Consoles What is the X Window System? The X Window System (commonly X11) is the most widely available windowing system capable of running on &unix; or &unix; like systems, including &os;. The X.Org Foundation administers the X protocol standards, with the current reference implementation, version 11 release &xorg.version;, so you will often see references shortened to X11. Many implementations are available for different architectures and operating systems. An implementation of the server-side code is properly known as an X server. I want to run &xorg;, how do I go about it? To install &xorg; do one of the following: Use the x11/xorg meta-port, which builds and installs every &xorg; component. Use x11/xorg-minimal, which builds and installs only the necessary &xorg; components. Install &xorg; from &os; packages: &prompt.root; pkg_add -r xorg or on systems using pkg: &prompt.root; pkg install xorg After the installation of &xorg;, follow the instructions from the X11 Configuration section of the &os; Handbook. I tried to run X, but I get a No devices detected. error when I type startx. What do I do now? Your system is probably running at a raised securelevel. It is not possible to start X at a raised securelevel because X requires write access to &man.io.4;. For more information, see at the &man.init.8; manual page. There are two solutions to the problem: Set your securelevel back down to zero (usually in /etc/rc.conf), or run &man.xdm.1; (or an alternative display manager) at boot time (before the securelevel is raised). See for more information about running &man.xdm.1; at boot time. Why does my mouse not work with X? If you are using &man.syscons.4; (the default console driver), you can configure &os; to support a mouse pointer on each virtual screen. To avoid conflicting with X, &man.syscons.4; supports a virtual device called /dev/sysmouse. All mouse events received from the real mouse device are written to the &man.sysmouse.4; device via &man.moused.8;. To use your mouse on one or more virtual consoles, and use X, see and set up &man.moused.8;. Then edit /etc/X11/xorg.conf and make sure you have the following lines: Section "InputDevice" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" ..... Starting with &xorg; version 7.4, the InputDevice sections in xorg.conf are ignored in favor of autodetected devices. To restore the old behavior, add the following line to the ServerLayout or ServerFlags section: Option "AutoAddDevices" "false" Some people prefer to use /dev/mouse under X. To make this work, /dev/mouse should be linked to /dev/sysmouse (see &man.sysmouse.4;) by adding the following line to /etc/devfs.conf (see &man.devfs.conf.5;): link sysmouse mouse This link can be created by restarting &man.devfs.5; with the following command (as root): &prompt.root; service devfs restart My mouse has a fancy wheel. Can I use it in X? Yes. You need to tell X that you have a 5 button mouse. To do this, simply add the lines Buttons 5 and ZAxisMapping 4 5 to the InputDevice section of /etc/X11/xorg.conf. For example, you might have the following InputDevice section in /etc/X11/xorg.conf. <quote>InputDevice</quote> Section for Wheeled Mouse in &xorg; Configuration File Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection <quote>.emacs</quote> Example for Naive Page Scrolling with Wheeled Mouse (optional) ;; wheel mouse (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) My laptop has a Synaptics touchpad. Can I use it in X? Yes, you will have to configure a few things to make it work. If you plan to use the Xorg synaptics driver you must remove moused_enable from rc.conf. Xorg can not use the synaptics mouse if the moused already sits on /dev/psm0. To enable synaptics in the &man.psm.4; driver you need to add the following into /boot/loader.conf: hw.psm.synaptics_support="1" You also need the following into xorg.conf: Section "InputDevice" Identifier "Touchpad0" Driver "synaptics" Option "Protocol" "psm" Option "Device" "/dev/psm0" EndSection And be sure to add the following into the ServerLayout section: InputDevice "Touchpad0" "SendCoreEvents" How do I use remote X displays? For security reasons, the default setting is to not allow a machine to remotely open a window. To enable this feature, simply start X with the optional argument: &prompt.user; startx -listen_tcp What is a virtual console and how do I make more? Virtual consoles, put simply, enable you to have several simultaneous sessions on the same machine without doing anything complicated like setting up a network or running X. When the system starts, it will display a login prompt on the monitor after displaying all the boot messages. You can then type in your login name and password and start working (or playing!) on the first virtual console. At some point, you will probably wish to start another session, perhaps to look at documentation for a program you are running or to read your mail while waiting for an FTP transfer to finish. Just do AltF2 (hold down Alt and press F2), and you will find a login prompt waiting for you on the second virtual console! When you want to go back to the original session, do AltF1. The default &os; installation has eight virtual consoles enabled. AltF1, AltF2, AltF3, and so on will switch between these virtual consoles. To enable more of them, edit /etc/ttys (see &man.ttys.5;) and add entries for ttyv8 to ttyvc after the comment on Virtual terminals: # Edit the existing entry for ttyv8 in /etc/ttys and change # "off" to "on". ttyv8 "/usr/libexec/getty Pc" xterm on secure ttyv9 "/usr/libexec/getty Pc" xterm on secure ttyva "/usr/libexec/getty Pc" xterm on secure ttyvb "/usr/libexec/getty Pc" xterm on secure Use as many or as few as you want. The more virtual terminals you have, the more resources that are used; this can be important if you have 8 MB RAM or less. You may also want to change the secure to insecure. Versions of &os; prior to 9.0 used the cons25 terminal type, and not xterm. Existing entries in /etc/ttys can be used on which to base new additions. If you want to run an X server you must leave at least one virtual terminal unused (or turned off) for it to use. That is to say that if you want to have a login prompt pop up for all twelve of your Alt-function keys, you are out of luck — you can only do this for eleven of them if you also want to run an X server on the same machine. The easiest way to disable a console is by turning it off. For example, if you had the full 12 terminal allocation mentioned above and you wanted to run X, you would change settings for virtual terminal 12 from: ttyvb "/usr/libexec/getty Pc" xterm on secure to: ttyvb "/usr/libexec/getty Pc" xterm off secure If your keyboard has only ten function keys, you would end up with: ttyv9 "/usr/libexec/getty Pc" xterm off secure ttyva "/usr/libexec/getty Pc" xterm off secure ttyvb "/usr/libexec/getty Pc" xterm off secure (You could also just delete these lines.) Next, the easiest (and cleanest) way to activate the virtual consoles is to reboot. However, if you really do not want to reboot, you can just shut down the X Window system and execute (as root): &prompt.root; kill -HUP 1 It is imperative that you completely shut down X Window if it is running, before running this command. If you do not, your system will probably appear to hang or lock up after executing kill. How do I access the virtual consoles from X? Use CtrlAltFn to switch back to a virtual console. CtrlAltF1 would return you to the first virtual console. Once you are back to a text console, you can then use AltFn as normal to move between them. To return to the X session, you must switch to the virtual console running X. If you invoked X from the command line, (e.g., using startx) then the X session will attach to the next unused virtual console, not the text console from which it was invoked. If you have eight active virtual terminals then X will be running on the ninth, and you would use AltF9 to return. How do I start XDM on boot? There are two schools of thought on how to start &man.xdm.1;. One school starts xdm from /etc/ttys (see &man.ttys.5;) using the supplied example, while the other simply runs xdm from rc.local (see &man.rc.8;) or from an X script in /usr/local/etc/rc.d. Both are equally valid, and one may work in situations where the other does not. In both cases the result is the same: X will pop up a graphical login prompt. The &man.ttys.5; method has the advantage of documenting which vty X will start on and passing the responsibility of restarting the X server on logout to &man.init.8;. The &man.rc.8; method makes it easy to kill xdm if there is a problem starting the X server. If loaded from &man.rc.8;, xdm should be started without any arguments (i.e., as a daemon). xdm must start after &man.getty.8; runs, or else getty and xdm will conflict, locking out the console. The best way around this is to have the script sleep 10 seconds or so then launch xdm. If you are to start xdm from /etc/ttys, there still is a chance of conflict between xdm and &man.getty.8;. One way to avoid this is to add the vt number in /usr/local/lib/X11/xdm/Xservers :0 local /usr/local/bin/X vt4 The above example will direct the X server to run in /dev/ttyv3. Note the number is offset by one. The X server counts the vty from one, whereas the &os; kernel numbers the vty from zero. Why do I get Couldn't open console when I run xconsole? If you start X with startx, the permissions on /dev/console will not get changed, resulting in things like xterm -C and xconsole not working. This is because of the way console permissions are set by default. On a multi-user system, one does not necessarily want just any user to be able to write on the system console. For users who are logging directly onto a machine with a VTY, the &man.fbtab.5; file exists to solve such problems. In a nutshell, make sure an uncommented line of the form is in /etc/fbtab (see &man.fbtab.5;): /dev/ttyv0 0600 /dev/console It will ensure that whomever logs in on /dev/ttyv0 will own the console. Why does my PS/2 mouse misbehave under X? Your mouse and the mouse driver may have somewhat become out of synchronization. In rare cases the driver may erroneously report synchronization problem and you may see the kernel message: psmintr: out of sync (xxxx != yyyy) and notice that your mouse does not work properly. If this happens, disable the synchronization check code by setting the driver flags for the PS/2 mouse driver to 0x100. This can be easiest achieved by adding hint.psm.0.flags="0x100" to /boot/loader.conf and rebooting. How do I reverse the mouse buttons? Run the command xmodmap -e "pointer = 3 2 1" from .xinitrc or .xsession. How do I install a splash screen and where do I find them? The detailed answer for this question can be found in the Boot Time Splash Screens section of the &os; Handbook. Can I use the Windows keys on my keyboard in X? Yes. All you need to do is use &man.xmodmap.1; to define what function you wish them to perform. Assuming all Windows keyboards are standard then the keycodes for these three keys are the following: 115 — Windows key, between the left-hand Ctrl and Alt keys 116 — Windows key, to the right of AltGr 117 — Menu, to the left of the right-hand Ctrl To have the left Windows key print a comma, try this. &prompt.root; xmodmap -e "keycode 115 = comma" To have the Windows key-mappings enabled automatically every time you start X either put the xmodmap commands in ~/.xinitrc or, preferably, create a ~/.xmodmaprc and include the xmodmap options, one per line, then add the following line to ~/.xinitrc: xmodmap $HOME/.xmodmaprc For example, you could map the 3 keys to be F13, F14, and F15, respectively. This would make it easy to map them to useful functions within applications or your window manager, as demonstrated further down. To do this put the following in ~/.xmodmaprc. keycode 115 = F13 keycode 116 = F14 keycode 117 = F15 If you use the x11-wm/fvwm2 port, for example, you could map the keys so that F13 iconifies (or de-iconifies) the window the cursor is in, F14 brings the window the cursor is in to the front or, if it is already at the front, pushes it to the back, and F15 pops up the main Workplace (application) menu even if the cursor is not on the desktop, which is useful if you do not have any part of the desktop visible (and the logo on the key matches its functionality). The following entries in ~/.fvwmrc implement the aforementioned setup: Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop How can I get 3D hardware acceleration for &opengl;? The availability of 3D acceleration depends on the version of &xorg; that you are using and the type of video chip you have. If you have an nVidia chip, you can use the binary drivers provided for &os; by installing one of the following ports: The latest versions of nVidia cards are supported by the x11/nvidia-driver port. nVidia cards like the GeForce2 MX/3/4 series are supported by the 96XX series of drivers, available in the x11/nvidia-driver-96xx port. Even older cards, like GeForce and RIVA TNT are supported by the 71XX series of drivers, available in the x11/nvidia-driver-71xx port. nVidia provides detailed information on which card is supported by which driver on their web site: . For Matrox G200/G400, check the x11-servers/mga_hal port. For ATI Rage 128 and Radeon see &man.ati.4x;, &man.r128.4x; and &man.radeon.4x;. Networking Where can I get information on diskless booting? Diskless booting means that the &os; box is booted over a network, and reads the necessary files from a server instead of its hard disk. For full details, please read the Handbook entry on diskless booting. Can a &os; box be used as a dedicated network router? Yes. Please see the Handbook entry on advanced networking, specifically the section on routing and gateways. Can I connect my &windows; box to the Internet via &os;? Typically, people who ask this question have two PCs at home, one with &os; and one with some version of &windows; the idea is to use the &os; box to connect to the Internet and then be able to access the Internet from the &windows; box through the &os; box. This is really just a special case of the previous question and works perfectly well. Dialup users must use and set gateway_enable to YES in /etc/rc.conf. For more information, please see the &man.ppp.8; manual page or the Handbook entry on user PPP. If you are using kernel-mode PPP or have an Ethernet connection to the Internet, you need to use &man.natd.8;. Please look at the natd section of the Handbook for a tutorial. Does &os; support PPP? Yes. &man.ppp.8; provides support for both incoming and outgoing connections. For more information on how to use this, please see the Handbook chapter on PPP. Does &os; support NAT or Masquerading? Yes. If you want to use NAT over a user PPP connection, please see the Handbook entry on user PPP. If you want to use NAT over some other sort of network connection, please look at the natd section of the Handbook. How can I set up Ethernet aliases? If the alias is on the same subnet as an address already configured on the interface, then add netmask 0xffffffff to your &man.ifconfig.8; command-line, as in the following: &prompt.root; ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff Otherwise, just specify the network address and netmask as usual: &prompt.root; ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00 You can read more about this in the &os; Handbook. Why can I not NFS-mount from a &linux; box? Some versions of the &linux; NFS code only accept mount requests from a privileged port; try to issue the following command: &prompt.root; mount -o -P linuxbox:/blah /mnt Why does mountd keep telling me it can't change attributes and that I have a bad exports list on my &os; NFS server? The most frequent problem is not understanding the correct format of /etc/exports. Please review &man.exports.5; and the NFS entry in the Handbook, especially the section on configuring NFS. How do I enable IP multicast support? &os; supports multicast host operations by default. If you want your box to run as a multicast router, you need to recompile your kernel with the MROUTING option and run &man.mrouted.8;. &os; will start &man.mrouted.8; at boot time if the flag mrouted_enable is set to YES in /etc/rc.conf. In recent &os; releases, the &man.mrouted.8; multicast routing daemon, the &man.map-mbone.8; and &man.mrinfo.8; utilities have been removed from the base system. These programs are now available in the &os; Ports Collection as net/mrouted. Why do I have to use the FQDN for hosts on my site? See the answer in the &os; Handbook. Why do I get an error, Permission denied, for all networking operations? If you have compiled your kernel with the IPFIREWALL option, you need to be aware that the default policy is to deny all packets that are not explicitly allowed. If you had unintentionally misconfigured your system for firewalling, you can restore network operability by typing the following while logged in as root: &prompt.root; ipfw add 65534 allow all from any to any You can also set firewall_type="open" in /etc/rc.conf. For further information on configuring a &os; firewall, see the Handbook chapter. Why is my ipfw fwd rule to redirect a service to another machine not working? Possibly because you want to do network address translation (NAT) and not just forward packets. A fwd rule does exactly what it says; it forwards packets. It does not actually change the data inside the packet. Say we have a rule like: 01000 fwd 10.0.0.1 from any to foo 21 When a packet with a destination address of foo arrives at the machine with this rule, the packet is forwarded to 10.0.0.1, but it still has the destination address of foo! The destination address of the packet is not changed to 10.0.0.1. Most machines would probably drop a packet that they receive with a destination address that is not their own. Therefore, using a fwd rule does not often work the way the user expects. This behavior is a feature and not a bug. See the FAQ about redirecting services, the &man.natd.8; manual, or one of the several port redirecting utilities in the Ports Collection for a correct way to do this. How can I redirect service requests from one machine to another? You can redirect FTP (and other service) request with the sysutils/socket port. Simply replace the service's command line to call socket instead, like so: ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp where ftp.example.com and ftp are the host and port to redirect to, respectively. Where can I get a bandwidth management tool? There are three bandwidth management tools available for &os;. &man.dummynet.4; is integrated into &os; as part of &man.ipfw.4;. ALTQ has been integrated into &os; as part of &man.pf.4;. Bandwidth Manager from Emerging Technologies is a commercial product. Why do I get /dev/bpf0: device not configured? You are running a program that requires the Berkeley Packet Filter (&man.bpf.4;), but it is not in your kernel. Add this to your kernel config file and build a new kernel: device bpf # Berkeley Packet Filter Use the SMBFS toolset. It includes a set of kernel modifications and a set of userland programs. The programs and information are available as &man.mount.smbfs.8; in the base system. What are these messages about: Limiting icmp/open port/closed port response in my log files? This is the kernel telling you that some activity is provoking it to send more ICMP or TCP reset (RST) responses than it thinks it should. ICMP responses are often generated as a result of attempted connections to unused UDP ports. TCP resets are generated as a result of attempted connections to unopened TCP ports. Among others, these are the kinds of activities which may cause these messages: Brute-force denial of service (DoS) attacks (as opposed to single-packet attacks which exploit a specific vulnerability). Port scans which attempt to connect to a large number of ports (as opposed to only trying a few well-known ports). The first number in the message tells you how many packets the kernel would have sent if the limit was not in place, and the second number tells you the limit. You can control the limit using the net.inet.icmp.icmplim sysctl variable like this, where 300 is the limit in packets per second: &prompt.root; sysctl net.inet.icmp.icmplim=300 If you do not want to see messages about this in your log files, but you still want the kernel to do response limiting, you can use the net.inet.icmp.icmplim_output sysctl variable to disable the output like this: &prompt.root; sysctl net.inet.icmp.icmplim_output=0 Finally, if you want to disable response limiting, you can set the net.inet.icmp.icmplim sysctl variable (see above for an example) to 0. Disabling response limiting is discouraged for the reasons listed above. What are these arp: unknown hardware address format error messages? This means that some device on your local Ethernet is using a MAC address in a format that &os; does not recognize. This is probably caused by someone experimenting with an Ethernet card somewhere else on the network. You will see this most commonly on cable modem networks. It is harmless, and should not affect the performance of your &os; machine. Why do I keep seeing messages like: 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0, and how do I disable it? Because a packet is coming from outside the network unexpectedly. To disable them, set net.link.ether.inet.log_arp_wrong_iface to 0. Security What is a sandbox? Sandbox is a security term. It can mean two things: A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system. The process is said to be able to play inside the walls. That is, nothing the process does in regards to executing code is supposed to be able to breech the walls so you do not have to do a detailed audit of its code to be able to say certain things about its security. The walls might be a user ID, for example. This is the definition used in the &man.security.7; and &man.named.8; man pages. Take the ntalk service, for example (see &man.inetd.8;). This service used to run as user ID root. Now it runs as user ID tty. The tty user is a sandbox designed to make it more difficult for someone who has successfully hacked into the system via ntalk from being able to hack beyond that user ID. A process which is placed inside a simulation of the machine. It means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data. The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chrooted (i.e., / for that process is this directory, not the real / of the system). Another common use is to mount an underlying file system read-only and then create a file system layer on top of it that gives a process a seemingly writeable view into that file system. The process may believe it is able to write to those files, but only the process sees the effects — other processes in the system do not, necessarily. An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it. &unix; implements two core sandboxes. One is at the process level, and one is at the userid level. Every &unix; process is completely firewalled off from every other &unix; process. One process cannot modify the address space of another. A &unix; process is owned by a particular userid. If the user ID is not the root user, it serves to firewall the process off from processes owned by other users. The user ID is also used to firewall off on-disk data. What is securelevel? securelevel is a security mechanism implemented in the kernel. When the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. The securelevel mechanism limits the ability to: Unset certain file flags, such as schg (the system immutable flag). Write to kernel memory via /dev/mem and /dev/kmem. Load kernel modules. Alter firewall rules. To check the status of the securelevel on a running system, simply execute the following command: &prompt.root; sysctl -n kern.securelevel The output contains the current value of the securelevel. If it is positive (i.e., greater than 0), at least some of the securelevel's protections are enabled. The securelevel of a running system can not be lowered as this would defeat its purpose. If you need to do a task that requires that the securelevel be non-positive (e.g., an installworld or changing the date), you will have to change the securelevel setting in /etc/rc.conf (you want to look for the kern_securelevel and kern_securelevel_enable variables) and reboot. For more information on securelevel and the specific things all the levels do, please consult the &man.init.8; manual page. Securelevel is not a silver bullet; it has many known deficiencies. More often than not, it provides a false sense of security. One of its biggest problems is that in order for it to be at all effective, all files used in the boot process up until the securelevel is set must be protected. If an attacker can get the system to execute their code prior to the securelevel being set (which happens quite late in the boot process since some things the system must do at start-up cannot be done at an elevated securelevel), its protections are invalidated. While this task of protecting all files used in the boot process is not technically impossible, if it is achieved, system maintenance will become a nightmare since one would have to take the system down, at least to single-user mode, to modify a configuration file. This point and others are often discussed on the mailing lists, particularly the &a.security;. Please search the archives here for an extensive discussion. A more fine-grained mechanism is preferred. BIND (named) is listening on some high-numbered ports. What is going on? BIND uses a random high-numbered port for outgoing queries. Recent versions of it choose a new, random UDP port for each query. This may cause problems for some network configurations, especially if a firewall blocks incoming UDP packets on particular ports. If you want to get past that firewall, you can try the avoid-v4-udp-ports and avoid-v6-udp-ports options to avoid selecting random port numbers within a blocked range. If a port number (like 53) is specified via the query-source or query-source-v6 options in /etc/namedb/named.conf, randomized port selection will not be used. It is strongly recommended that these options not be used to specify fixed port numbers. Congratulations, by the way. It is good practice to read your &man.sockstat.1; output and notice odd things! The sendmail daemon is listening on port 587 as well as the standard port 25! What is going on? Recent versions of sendmail support a mail submission feature that runs over port 587. This is not yet widely supported, but is growing in popularity. What is this UID 0 toor account? Have I been compromised? Do not worry. toor is an alternative superuser account (toor is root spelt backwards). Previously it was created when the &man.bash.1; shell was installed but now it is created by default. It is intended to be used with a non-standard shell so you do not have to change root's default shell. This is important as shells which are not part of the base distribution (for example a shell installed from ports or packages) are likely to be installed in /usr/local/bin which, by default, resides on a different file system. If root's shell is located in /usr/local/bin and /usr (or whatever file system contains /usr/local/bin) is not mounted for some reason, root will not be able to log in to fix a problem (although if you reboot into single user mode you will be prompted for the path to a shell). Some people use toor for day-to-day root tasks with a non-standard shell, leaving root, with a standard shell, for single user mode or emergencies. By default you cannot log in using toor as it does not have a password, so log in as root and set a password for toor if you want to use it. PPP I cannot make &man.ppp.8; work. What am I doing wrong? You should first read the &man.ppp.8; manual page and the PPP section of the handbook. Enable logging with the following command: set log Phase Chat Connect Carrier lcp ipcp ccp command This command may be typed at the &man.ppp.8; command prompt or it may be entered in the /etc/ppp/ppp.conf configuration file (the start of the default section is the best place to put it). Make sure that /etc/syslog.conf (see &man.syslog.conf.5;) contains the lines below and the file /var/log/ppp.log exists: !ppp *.* /var/log/ppp.log You can now find out a lot about what is going on from the log file. Do not worry if it does not all make sense. If you need to get help from someone, it may make sense to them. Why does &man.ppp.8; hang when I run it? This is usually because your hostname will not resolve. The best way to fix this is to make sure that /etc/hosts is consulted by your resolver first by editing /etc/host.conf and putting the hosts line first. Then, simply put an entry in /etc/hosts for your local machine. If you have no local network, change your localhost line: 127.0.0.1 foo.example.com foo localhost Otherwise, simply add another entry for your host. Consult the relevant manual pages for more details. You should be able to successfully ping -c1 `hostname` when you are done. Why will &man.ppp.8; not dial in -auto mode? First, check that you have got a default route. By running netstat -rn (see &man.netstat.1;), you should see two entries like this: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 This is assuming that you have used the addresses from the handbook, the manual page, or from ppp.conf.sample. If you do not have a default route, it may be because you forgot to add the HISADDR line to ppp.conf. Another reason for the default route line being missing is that you have mistakenly set up a default router in your /etc/rc.conf (see &man.rc.conf.5;) file and you have omitted the line below from ppp.conf: delete ALL If this is the case, go back to the Final System Configuration section of the handbook. What does No route to host mean? This error is usually due that the following section is missing in your /etc/ppp/ppp.linkup: MYADDR: delete ALL add 0 0 HISADDR This is only necessary if you have a dynamic IP address or do not know the address of your gateway. If you are using interactive mode, you can type the following after entering packet mode (packet mode is indicated by the capitalized PPP in the prompt): delete ALL add 0 0 HISADDR Refer to the PPP and Dynamic IP addresses section of the handbook for further details. Why does my connection drop after about 3 minutes? The default PPP timeout is 3 minutes. This can be adjusted with the following line: set timeout NNN where NNN is the number of seconds of inactivity before the connection is closed. If NNN is zero, the connection is never closed due to a timeout. It is possible to put this command in ppp.conf, or to type it at the prompt in interactive mode. It is also possible to adjust it on the fly while the line is active by connecting to ppp's server socket using &man.telnet.1; or &man.pppctl.8;. Refer to the &man.ppp.8; man page for further details. Why does my connection drop under heavy load? If you have Link Quality Reporting (LQR) configured, it is possible that too many LQR packets are lost between your machine and the peer. &man.ppp.8; deduces that the line must therefore be bad, and disconnects. LQR is disabled by default and can be enabled with the following line: enable lqr Why does my connection drop after a random amount of time? Sometimes, on a noisy phone line or even on a line with call waiting enabled, your modem may hang up because it thinks (incorrectly) that it lost carrier. There is a setting on most modems for determining how tolerant it should be to temporary losses of carrier. Refer to the modem manual for details. Why does my connection hang after a random amount of time? Many people experience hung connections with no apparent explanation. The first thing to establish is which side of the link is hung. If you are using an external modem, you can simply try using &man.ping.8; to see if the TD light is flashing when you transmit data. If it flashes (and the RD light does not), the problem is with the remote end. If TD does not flash, the problem is local. With an internal modem, you will need to use the set server command in ppp.conf. When the hang occurs, connect to &man.ppp.8; using &man.pppctl.8;. If your network connection suddenly revives (PPP was revived due to the activity on the diagnostic socket) or if you cannot connect (assuming the set socket command succeeded at startup time), the problem is local. If you can connect and things are still hung, enable local async logging with set log local async and use &man.ping.8; from another window or terminal to make use of the link. The async logging will show you the data being transmitted and received on the link. If data is going out and not coming back, the problem is remote. Having established whether the problem is local or remote, you now have two possibilities: If the problem is remote, read on entry . If the problem is local, read on entry . The remote end is not responding. What can I do? There is very little you can do about this. Most ISPs will refuse to help if you are not running a µsoft; OS. You can enable lqr in your ppp.conf, allowing &man.ppp.8; to detect the remote failure and hang up, but this detection is relatively slow and therefore not that useful. You may want to avoid telling your ISP that you are running user-PPP. First, try disabling all local compression by adding the following to your configuration: disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Then reconnect to ensure that this makes no difference. If things improve or if the problem is solved completely, determine which setting makes the difference through trial and error. This will provide good ammunition when you contact your ISP (although it may make it apparent that you are not running a µsoft; product). Before contacting your ISP, enable async logging locally and wait until the connection hangs again. This may use up quite a bit of disk space. The last data read from the port may be of interest. It is usually ASCII data, and may even describe the problem (Memory fault, Core dumped). If your ISP is helpful, they should be able to enable logging on their end, then when the next link drop occurs, they may be able to tell you why their side is having a problem. &man.ppp.8; has hung. What can I do? Your best bet here is to rebuild &man.ppp.8; with debugging information, and then use &man.gdb.1; to grab a stack trace from the ppp process that is stuck. To rebuild the ppp utility with debugging information, you can type: &prompt.root; cd /usr/src/usr.sbin/ppp &prompt.root; env DEBUG_FLAGS='-g' make clean &prompt.root; env DEBUG_FLAGS='-g' make install Then you should restart ppp and wait until it hangs again. When the debug build of ppp hangs, start gdb on the stuck process by typing: &prompt.root; gdb ppp `pgrep ppp` At the gdb prompt, you can use the bt or where commands to get a stack trace. Save the output of your gdb session, and detach from the running process by typing quit. I keep seeing errors about magic being the same. What does it mean? Occasionally, just after connecting, you may see messages in the log that say Magic is same. Sometimes, these messages are harmless, and sometimes one side or the other exits. Most PPP implementations cannot survive this problem, and even if the link seems to come up, you will see repeated configure requests and configure acknowledgments in the log file until &man.ppp.8; eventually gives up and closes the connection. This normally happens on server machines with slow disks that are spawning a &man.getty.8; on the port, and executing &man.ppp.8; from a login script or program after login. There were reports of it happening consistently when using slirp. The reason is that in the time taken between &man.getty.8; exiting and &man.ppp.8; starting, the client-side &man.ppp.8; starts sending Line Control Protocol (LCP) packets. Because ECHO is still switched on for the port on the server, the client &man.ppp.8; sees these packets reflect back. One part of the LCP negotiation is to establish a magic number for each side of the link so that reflections can be detected. The protocol says that when the peer tries to negotiate the same magic number, a NAK should be sent and a new magic number should be chosen. During the period that the server port has ECHO turned on, the client &man.ppp.8; sends LCP packets, sees the same magic in the reflected packet and NAKs it. It also sees the NAK reflect (which also means &man.ppp.8; must change its magic). This produces a potentially enormous number of magic number changes, all of which are happily piling into the server's tty buffer. As soon as &man.ppp.8; starts on the server, it is flooded with magic number changes and almost immediately decides it has tried enough to negotiate LCP and gives up. Meanwhile, the client, who no longer sees the reflections, becomes happy just in time to see a hangup from the server. This can be avoided by allowing the peer to start negotiating with the following line in ppp.conf: set openmode passive This tells &man.ppp.8; to wait for the server to initiate LCP negotiations. Some servers however may never initiate negotiations. If this is the case, you can do something like: set openmode active 3 This tells &man.ppp.8; to be passive for 3 seconds, and then to start sending LCP requests. If the peer starts sending requests during this period, &man.ppp.8; will immediately respond rather than waiting for the full 3 second period. LCP negotiations continue until the connection is closed. What is wrong? There is currently an implementation mis-feature in &man.ppp.8; where it does not associate LCP, CCP & IPCP responses with their original requests. As a result, if one PPP implementation is more than 6 seconds slower than the other side, the other side will send two additional LCP configuration requests. This is fatal. Consider two implementations, A and B. A starts sending LCP requests immediately after connecting and B takes 7 seconds to start. When B starts, A has sent 3 LCP REQs. We are assuming the line has ECHO switched off, otherwise we would see magic number problems as described in the previous section. B sends a REQ, then an ACK to the first of A's REQs. This results in A entering the OPENED state and sending and ACK (the first) back to B. In the meantime, B sends back two more ACKs in response to the two additional REQs sent by A before B started up. B then receives the first ACK from A and enters the OPENED state. A receives the second ACK from B and goes back to the REQ-SENT state, sending another (forth) REQ as per the RFC. It then receives the third ACK and enters the OPENED state. In the meantime, B receives the forth REQ from A, resulting in it reverting to the ACK-SENT state and sending another (second) REQ and (forth) ACK as per the RFC. A gets the REQ, goes into REQ-SENT and sends another REQ. It immediately receives the following ACK and enters OPENED. This goes on until one side figures out that they are getting nowhere and gives up. The best way to avoid this is to configure one side to be passive — that is, make one side wait for the other to start negotiating. This can be done with the following command: set openmode passive Care should be taken with this option. You should also use this command to limit the amount of time that &man.ppp.8; waits for the peer to begin negotiations: set stopped N Alternatively, the following command (where N is the number of seconds to wait before starting negotiations) can be used: set openmode active N Check the manual page for details. Why does &man.ppp.8; lock up when I shell out to test it? When you execute the shell or ! command, &man.ppp.8; executes a shell (or if you have passed any arguments, &man.ppp.8; will execute those arguments). The ppp program will wait for the command to complete before continuing. If you attempt to use the PPP link while running the command, the link will appear to have frozen. This is because &man.ppp.8; is waiting for the command to complete. To execute commands like this, use !bg instead. This will execute the given command in the background, and &man.ppp.8; can continue to service the link. Why does &man.ppp.8; over a null-modem cable never exit? There is no way for &man.ppp.8; to automatically determine that a direct connection has been dropped. This is due to the lines that are used in a null-modem serial cable. When using this sort of connection, LQR should always be enabled with the following line: enable lqr LQR is accepted by default if negotiated by the peer. Why does &man.ppp.8; dial for no reason in mode? If &man.ppp.8; is dialing unexpectedly, you must determine the cause, and set up Dial filters (dfilters) to prevent such dialing. To determine the cause, use the following line: set log +tcp/ip This will log all traffic through the connection. The next time the line comes up unexpectedly, you will see the reason logged with a convenient timestamp next to it. You can now disable dialing under these circumstances. Usually, this sort of problem arises due to DNS lookups. To prevent DNS lookups from establishing a connection (this will not prevent &man.ppp.8; from passing the packets through an established connection), use the following: set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 This is not always suitable, as it will effectively break your demand-dial capabilities — most programs will need a DNS lookup before doing any other network related things. In the DNS case, you should try to determine what is actually trying to resolve a host name. A lot of the time, &man.sendmail.8; is the culprit. You should make sure that you tell sendmail not to do any DNS lookups in its configuration file. See the section on using email with a dialup connection in the &os; Handbook for details on how to create your own configuration file and what should go into it. You may also want to add the following line to .mc: define(`confDELIVERY_MODE', `d')dnl This will make sendmail queue everything until the queue is run (usually, sendmail is run with , telling it to run the queue every 30 minutes) or until a sendmail is done (perhaps from your ppp.linkup). What do these CCP errors mean? I keep seeing the following errors in my log file: CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) This is because &man.ppp.8; is trying to negotiate Predictor1 compression, and the peer does not want to negotiate any compression at all. The messages are harmless, but if you wish to remove them, you can disable Predictor1 compression locally too: disable pred1 Why does &man.ppp.8; not log my connection speed? To log all lines of your modem conversation, you must enable the following: set log +connect This will make &man.ppp.8; log everything up until the last requested expect string. If you wish to see your connect speed and are using PAP or CHAP (and therefore do not have anything to chat after the CONNECT in the dial script — no set login script), you must make sure that you instruct &man.ppp.8; to expect the whole CONNECT line, something like this: set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" Here, we get our CONNECT, send nothing, then expect a line-feed, forcing &man.ppp.8; to read the whole CONNECT response. Why does &man.ppp.8; ignore the \ character in my chat script? The ppp utility parses each line in your config files so that it can interpret strings such as set phone "123 456 789" correctly and realize that the number is actually only one argument. To specify a " character, you must escape it using a backslash (\). When the chat interpreter parses each argument, it re-interprets the argument to find any special escape sequences such as \P or \T (see the manual page). As a result of this double-parsing, you must remember to use the correct number of escapes. If you wish to actually send a \ character to (say) your modem, you would need something like: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" It will result in the following sequence: ATZ OK AT\X OK Or: set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" It will result in the following sequence: ATZ OK ATDT1234567 Why does &man.ppp.8; get a Segmentation fault, but I see no ppp.core The ppp utility (or any other program for that matter) should never dump core. Because &man.ppp.8; runs setuid (with an effective user ID of 0), the operating system will not write core image of &man.ppp.8; to disk before terminating it. If, however &man.ppp.8; is actually terminating due to a segmentation violation or some other signal that normally causes core to be dumped, and you are sure you are using the latest version (see the start of this section), then you should install the system sources and do the following: &prompt.root; cd /usr/src/usr.sbin/ppp &prompt.root; echo STRIP= >> /etc/make.conf &prompt.root; echo CFLAGS+= >> /etc/make.conf &prompt.root; make install clean You will now have a debuggable version of &man.ppp.8; installed. You will have to be root to run &man.ppp.8; as all of its privileges have been revoked. When you start &man.ppp.8;, take a careful note of what your current directory was at the time. Now, if and when &man.ppp.8; receives the segmentation violation, it will dump a core file called ppp.core. You should then do the following: &prompt.user; su &prompt.root; gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 .... (gdb) i args .... (gdb) l ..... All of this information should be given alongside your question, making it possible to diagnose the problem. If you are familiar with &man.gdb.1;, you may wish to find out some other bits and pieces such as what actually caused the dump or the addresses and values of the relevant variables. Why does the process that forces a dial in mode never connect? This was a known problem with &man.ppp.8; set up to negotiate a dynamic local IP number with the peer in mode. It has been fixed a long time ago — search the manual page for iface. The problem was that when that initial program calls &man.connect.2;, the IP number of the &man.tun.4; interface is assigned to the socket endpoint. The kernel creates the first outgoing packet and writes it to the &man.tun.4; device. &man.ppp.8; then reads the packet and establishes a connection. If, as a result of &man.ppp.8;'s dynamic IP assignment, the interface address is changed, the original socket endpoint will be invalid. Any subsequent packets sent to the peer will usually be dropped. Even if they are not, any responses will not route back to the originating machine as the IP number is no longer owned by that machine. There are several theoretical ways to approach this problem. It would be nicest if the peer would re-assign the same IP number if possible. The current version of &man.ppp.8; does this, but most other implementations do not. The easiest method from our side would be to never change the &man.tun.4; interface IP number, but instead to change all outgoing packets so that the source IP number is changed from the interface IP to the negotiated IP on the fly. This is essentially what the iface-alias option in the latest version of &man.ppp.8; is doing (with the help of &man.libalias.3; and &man.ppp.8;'s switch) — it is maintaining all previous interface addresses and NATing them to the last negotiated address. Another alternative (and probably the most reliable) would be to implement a system call that changes all bound sockets from one IP to another. &man.ppp.8; would use this call to modify the sockets of all existing programs when a new IP number is negotiated. The same system call could be used by DHCP clients when they are forced to call the bind() function for their sockets. Yet another possibility is to allow an interface to be brought up without an IP number. Outgoing packets would be given an IP number of 255.255.255.255 up until the first SIOCAIFADDR &man.ioctl.2; is done. This would result in fully binding the socket. It would be up to &man.ppp.8; to change the source IP number, but only if it is set to 255.255.255.255, and only the IP number and IP checksum would need to change. This, however is a bit of a hack as the kernel would be sending bad packets to an improperly configured interface, on the assumption that some other mechanism is capable of fixing things retrospectively. Why do most games not work with the switch? The reason games and the like do not work when &man.libalias.3; is in use is that the machine on the outside will try to open a connection or send (unsolicited) UDP packets to the machine on the inside. The NAT software does not know that it should send these packets to the interior machine. To make things work, make sure that the only thing running is the software that you are having problems with, then either run &man.tcpdump.1; on the &man.tun.4; interface of the gateway or enable &man.ppp.8; TCP/IP logging (set log +tcp/ip) on the gateway. When you start the offending software, you should see packets passing through the gateway machine. When something comes back from the outside, it will be dropped (that is the problem). Note the port number of these packets then shut down the offending software. Do this a few times to see if the port numbers are consistent. If they are, then the following line in the relevant section of /etc/ppp/ppp.conf will make the software functional: nat port proto internalmachine:port port where proto is either tcp or udp, internalmachine is the machine that you want the packets to be sent to and port is the destination port number of the packets. You will not be able to use the software on other machines without changing the above command, and running the software on two internal machines at the same time is out of the question — after all, the outside world is seeing your entire internal network as being just a single machine. If the port numbers are not consistent, there are three more options: Submit support in &man.libalias.3;. Examples of special cases can be found in /usr/src/sys/netinet/libalias/alias_*.c (alias_ftp.c is a good prototype). This usually involves reading certain recognized outgoing packets, identifying the instruction that tells the outside machine to initiate a connection back to the internal machine on a specific (random) port and setting up a route in the alias table so that the subsequent packets know where to go. This is the most difficult solution, but it is the best and will make the software work with multiple machines. Use a proxy. The application may support socks5 for example, or may have a passive option that avoids ever requesting that the peer open connections back to the local machine. Redirect everything to the internal machine using nat addr. This is the sledge-hammer approach. What are FCS errors? FCS stands for Frame Check Sequence. Each PPP packet has a checksum attached to ensure that the data being received is the data being sent. If the FCS of an incoming packet is incorrect, the packet is dropped and the HDLC FCS count is increased. The HDLC error values can be displayed using the show hdlc command. If your link is bad (or if your serial driver is dropping packets), you will see the occasional FCS error. This is not usually worth worrying about although it does slow down the compression protocols substantially. If you have an external modem, make sure your cable is properly shielded from interference — this may eradicate the problem. If your link freezes as soon as you have connected and you see a large number of FCS errors, this may be because your link is not 8-bit clean. Make sure your modem is not using software flow control (XON/XOFF). If your datalink must use software flow control, use the command set accmap 0x000a0000 to tell &man.ppp.8; to escape the ^Q and ^S characters. Another reason for seeing too many FCS errors may be that the remote end has stopped talking PPP. You may want to enable async logging at this point to determine if the incoming data is actually a login or shell prompt. If you have a shell prompt at the remote end, it is possible to terminate &man.ppp.8; without dropping the line by using close lcp (a following term) will reconnect you to the shell on the remote machine. If nothing in your log file indicates why the link might have been terminated, you should ask the remote administrator (your ISP?) why the session was terminated. None of this helps — I am desperate! What can I do? If all else fails, send as much information as you can, including your config files, how you are starting &man.ppp.8;, the relevant parts of your log file and the output of netstat -rn (before and after connecting) to the &a.questions; and someone should point you in the right direction. Serial Communications This section answers common questions about serial communications with &os;. PPP is covered in the Networking section. Which multi-port serial cards are supported by &os;? There is a list of these in the Serial Communications chapter of the handbook. Most multi-port PCI cards that are based on 16550 or clones are supported with no extra effort. Some unnamed clone cards have also been known to work, especially those that claim to be AST compatible. Check &man.uart.4; and &man.sio.4; to get more information on configuring such cards. How do I get the boot: prompt to show on the serial console? See this section of the handbook. How do I tell if &os; found my serial ports or modem cards? As the &os; kernel boots, it will probe for the serial ports in your system for which the kernel was configured. You can either watch your system closely for the messages it prints or run this command after your system is up and running: &prompt.user; dmesg | grep -E "^sio[0-9]" Here is some example output from the above command: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A This shows two serial ports. The first is on IRQ 4, is using port address 0x3f8, and has a 16550A-type UART chip. The second uses the same kind of chip but is on IRQ 3 and is at port address 0x2f8. Internal modem cards are treated just like serial ports — except that they always have a modem attached to the port. The GENERIC kernel includes support for two serial ports using the same IRQ and port address settings in the above example. If these settings are not right for your system, or if you have added modem cards or have more serial ports than your kernel is configured for, just reconfigure your kernel. See section about building a kernel for more details. How do I access the serial ports on &os;? The third serial port, sio2 (see &man.sio.4;, known as COM3 in DOS), is on /dev/cuad2 for dial-out devices, and on /dev/ttyd2 for dial-in devices. What is the difference between these two classes of devices? You use ttydX for dial-ins. When opening /dev/ttydX in blocking mode, a process will wait for the corresponding cuadX device to become inactive, and then wait for the carrier detect line to go active. When you open the cuadX device, it makes sure the serial port is not already in use by the ttydX device. If the port is available, it steals it from the ttydX device. Also, the cuadX device does not care about carrier detect. With this scheme and an auto-answer modem, you can have remote users log in and you can still dial out with the same modem and the system will take care of all the conflicts. How do I enable support for a multiport serial card? Again, the section on kernel configuration provides information about configuring your kernel. For a multiport serial card, place an &man.sio.4; line for each serial port on the card in the &man.device.hints.5; file. But place the IRQ specifiers on only one of the entries. All of the ports on the card should share one IRQ. For consistency, use the last serial port to specify the IRQ. Also, specify the following option in the kernel configuration file: options COM_MULTIPORT The following /boot/device.hints example is for an AST 4-port serial card on IRQ 12: hint.sio.4.at="isa" hint.sio.4.port="0x2a0" hint.sio.4.flags="0x701" hint.sio.5.at="isa" hint.sio.5.port="0x2a8" hint.sio.5.flags="0x701" hint.sio.6.at="isa" hint.sio.6.port="0x2b0" hint.sio.6.flags="0x701" hint.sio.7.at="isa" hint.sio.7.port="0x2b8" hint.sio.7.flags="0x701" hint.sio.7.irq="12" The flags indicate that the master port has minor number 7 (0x700), and all the ports share an IRQ (0x001). Can I set the default serial parameters for a port? See the Serial Communications section in the &os; Handbook. How can I enable dialup logins on my modem? Please read the section about Dial-in Services in the &os; Handbook. How can I connect a dumb terminal to my &os; box? You can find this information in the Terminals section of the &os; Handbook. Why can I not run tip or cu? On your system, the programs &man.tip.1; and &man.cu.1; can only access the /var/spool/lock directory via user uucp and group dialer. You can use the group dialer to control who has access to your modem or remote systems. Just add yourself to group dialer. Alternatively, you can let everyone on your system run &man.tip.1; and &man.cu.1; by typing: &prompt.root; chmod 4511 /usr/bin/cu &prompt.root; chmod 4511 /usr/bin/tip Miscellaneous Questions &os; a lot of swap space even when the computer has free memory left. Why? &os; will proactively move entirely idle, unused pages of main memory into swap in order to make more main memory available for active use. This heavy use of swap is balanced by using the extra free memory for cacheing. Note that while &os; is proactive in this regard, it does not arbitrarily decide to swap pages when the system is truly idle. Thus you will not find your system all paged out when you get up in the morning after leaving it idle overnight. Why does top show very little free memory even when I have very few programs running? The simple answer is that free memory is wasted memory. Any memory that your programs do not actively allocate is used within the &os; kernel as disk cache. The values shown by &man.top.1; labeled as Inact, Cache, and Buf are all cached data at different aging levels. This cached data means the system does not have to access a slow disk again for data it has accessed recently, thus increasing overall performance. In general, a low value shown for Free memory in &man.top.1; is good, provided it is not very low. Why will chmod not change the permissions on symlinks? Symlinks do not have permissions, and by default, &man.chmod.1; will follow symlinks to change the permissions on the source file, if possible. So if you have a file, foo, and a symlink to that file, bar, then this command will always succeed. &prompt.user; chmod g-w bar However, the permissions on bar will not have changed. When changing modes of the file hierarchies rooted in the files instead of the files themselves, you have to use either or together with to make this work. See &man.chmod.1; and &man.symlink.7; for more information. does a recursive &man.chmod.1;. Be careful about specifying directories or symlinks to directories to &man.chmod.1;. If you want to change the permissions of a directory referenced by a symlink, use &man.chmod.1; without any options and follow the symlink with a trailing slash (/). For example, if foo is a symlink to directory bar, and you want to change the permissions of foo (actually bar), you would do something like: &prompt.user; chmod 555 foo/ With the trailing slash, &man.chmod.1; will follow the symlink, foo, to change the permissions of the directory, bar. Can I run DOS binaries under &os;? Yes, you can use emulators/doscmd, a DOS emulation program, available in the &os; Ports Collection. If doscmd will not suffice, the add-on utility emulators/pcemu emulates an 8088 and enough BIOS services to run many DOS text mode applications. It requires the X Window System. You may also try emulators/dosbox from the &os; Ports Collection. The main focus of this application is emulating old DOS games using the local file system for files. What do I need to do to translate a &os; document into my native language? See the Translation FAQ in the &os; Documentation Project Primer. Why does my email to any address at FreeBSD.org bounce? The FreeBSD.org mail system implements some Postfix checks on incoming mail and rejects mail that is either from misconfigured relays or otherwise appears likely to be spam. Some of the specific requirements are: The IP address of the SMTP client must "reverse-resolve" to a forward confirmed hostname. The fully-qualified hostname given in the SMTP conversation (either HELO or EHLO) must resolve to the IP address of the client. Other advice to help your mail reach its destination include: Mail should be sent in plain text, and messages sent to mailing lists should generally be no more than 200KB in length. Avoid excessive cross posting. Choose one mailing list which seems most relevant and send it there. If you still have trouble with email infrastructure at FreeBSD.org send a note with the details to postmaster@freebsd.org; Include a date/time interval so that logs may be reviewed — and note that we only keep one week's worth of mail logs. (Be sure to specify the time zone or offset from UTC.) Where can I find a free &os; account? While &os; does not provide open access to any of their servers, others do provide open access &unix; systems. The charge varies and limited services may be available. Arbornet, Inc, also known as M-Net, has been providing open access to &unix; systems since 1983. Starting on an Altos running System III, the site switched to BSD/OS in 1991. In June of 2000, the site switched again to &os;. M-Net can be accessed via telnet and SSH and provides basic access to the entire &os; software suite. However, network access is limited to members and patrons who donate to the system, which is run as a non-profit organization. M-Net also provides an bulletin board system and interactive chat. What is the cute little red guy's name? He does not have one, and is just called the BSD daemon. If you insist upon using a name, call him beastie. Note that beastie is pronounced BSD. You can learn more about the BSD daemon on his home page. Can I use the BSD daemon image? Perhaps. The BSD daemon is copyrighted by Marshall Kirk McKusick. You will want to check his Statement on the Use of the BSD Daemon Figure for detailed usage terms. In summary, you are free to use the image in a tasteful manner, for personal use, so long as appropriate credit is given. If you want to use him commercially, you must - contact &a.mckusick;. More details are available on the + contact &a.mckusick.email;. More details are available on the BSD Daemon's home page. Do you have any BSD daemon images I could use? You will find eps and Xfig drawings under /usr/share/examples/BSD_daemon/. I have seen an acronym or other term on the mailing lists and I do not understand what it means. Where should I look? Please see the &os; Glossary. Why should I care what color the bikeshed is? The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change. The longer and more complete answer is that after a very long argument about whether &man.sleep.1; should take - fractional second arguments, &a.phk; posted a long message + fractional second arguments, &a.phk.email; posted a long message entitled A bike shed (any color will do) on greener grass.... The appropriate portions of that message are quoted below.

- &a.phk; on &a.hackers.name;, October 2, + &a.phk.email; on &a.hackers.name;, October 2, 1999 What is it about this bike shed? Some of you have asked me. It is a long story, or rather it is an old story, but it is quite short actually. C. Northcote Parkinson wrote a book in the early 1960s, called Parkinson's Law, which contains a lot of insight into the dynamics of management. [snip a bit of commentary on the book] In the specific example involving the bike shed, the other vital component is an atomic power-plant, I guess that illustrates the age of the book. Parkinson shows how you can go into the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions. Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. Richard P. Feynmann gives a couple of interesting, and very much to the point, examples relating to Los Alamos in his books. A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is here. In Denmark we call it setting your fingerprint. It is about personal pride and prestige, it is about being able to point somewhere and say There! I did that. It is a strong trait in politicians, but present in most people given the chance. Just think about footsteps in wet cement.

The &os; Funnies How cool is &os;? Q. Has anyone done any temperature testing while running &os;? I know &linux; runs cooler than DOS, but have never seen a mention of &os;. It seems to run really hot. A. No, but we have done numerous taste tests on blindfolded volunteers who have also had 250 micrograms of LSD-25 administered beforehand. 35% of the volunteers said that &os; tasted sort of orange, whereas &linux; tasted like purple haze. Neither group mentioned any significant variances in temperature. We eventually had to throw the results of this survey out entirely anyway when we found that too many volunteers were wandering out of the room during the tests, thus skewing the results. We think most of the volunteers are at Apple now, working on their new scratch and sniff GUI. It is a funny old business we are in! Seriously, &os; uses the HLT (halt) instruction when the system is idle thus lowering its energy consumption and therefore the heat it generates. Also if you have ACPI (Advanced Configuration and Power Interface) configured, then &os; can also put the CPU into a low power mode. Who is scratching in my memory banks?? Q. Is there anything odd that &os; does when compiling the kernel which would cause the memory to make a scratchy sound? When compiling (and for a brief moment after recognizing the floppy drive upon startup, as well), a strange scratchy sound emanates from what appears to be the memory banks. A. Yes! You will see frequent references to daemons in the BSD documentation, and what most people do not know is that this refers to genuine, non-corporeal entities that now possess your computer. The scratchy sound coming from your memory is actually high-pitched whispering exchanged among the daemons as they best decide how to deal with various system administration tasks. If the noise gets to you, a good fdisk /mbr from DOS will get rid of them, but do not be surprised if they react adversely and try to stop you. In fact, if at any point during the exercise you hear the satanic voice of Bill Gates coming from the built-in speaker, take off running and do not ever look back! Freed from the counterbalancing influence of the BSD daemons, the twin demons of DOS and &windows; are often able to re-assert total control over your machine to the eternal damnation of your soul. Now that you know, given a choice you would probably prefer to get used to the scratchy noises, no? How many &os; hackers does it take to change a lightbulb? One thousand, one hundred and sixty-nine: Twenty-three to complain to -CURRENT about the lights being out; Four to claim that it is a configuration problem, and that such matters really belong on -questions; Three to submit PRs about it, one of which is misfiled under doc and consists only of it's dark; One to commit an untested lightbulb which breaks buildworld, then back it out five minutes later; Eight to flame the PR originators for not including patches in their PRs; Five to complain about buildworld being broken; Thirty-one to answer that it works for them, and they must have updated at a bad time; One to post a patch for a new lightbulb to -hackers; One to complain that he had patches for this three years ago, but when he sent them to -CURRENT they were just ignored, and he has had bad experiences with the PR system; besides, the proposed new lightbulb is non-reflexive; Thirty-seven to scream that lightbulbs do not belong in the base system, that committers have no right to do things like this without consulting the Community, and WHAT IS -CORE DOING ABOUT IT!? Two hundred to complain about the color of the bicycle shed; Three to point out that the patch breaks &man.style.9;; Seventeen to complain that the proposed new lightbulb is under GPL; Five hundred and eighty-six to engage in a flame war about the comparative advantages of the GPL, the BSD license, the MIT license, the NPL, and the personal hygiene of unnamed FSF founders; Seven to move various portions of the thread to -chat and -advocacy; One to commit the suggested lightbulb, even though it shines dimmer than the old one; Two to back it out with a furious flame of a commit message, arguing that &os; is better off in the dark than with a dim lightbulb; Forty-six to argue vociferously about the backing out of the dim lightbulb and demanding a statement from -core; Eleven to request a smaller lightbulb so it will fit their Tamagotchi if we ever decide to port &os; to that platform; Seventy-three to complain about the SNR on -hackers and -chat and unsubscribe in protest; Thirteen to post unsubscribe, How do I unsubscribe?, or Please remove me from the list, followed by the usual footer; One to commit a working lightbulb while everybody is too busy flaming everybody else to notice; Thirty-one to point out that the new lightbulb would shine 0.364% brighter if compiled with TenDRA (although it will have to be reshaped into a cube), and that &os; should therefore switch to TenDRA instead of GCC; One to complain that the new lightbulb lacks fairings; Nine (including the PR originators) to ask what is MFC?; Fifty-seven to complain about the lights being out two weeks after the bulb has been changed. - &a.nik; adds: + &a.nik.email; adds: I was laughing quite hard at this. And then I thought, Hang on, shouldn't there be '1 to document it.' in that list somewhere? And then I was enlightened :-) - &a.tabthorpe; says: None, + &a.tabthorpe.email; says: None, real &os; hackers are not afraid of the dark! Where does data written to /dev/null go? It goes into a special data sink in the CPU where it is converted to heat which is vented through the heatsink / fan assembly. This is why CPU cooling is increasingly important; as people get used to faster processors, they become careless with their data and more and more of it ends up in /dev/null, overheating their CPUs. If you delete /dev/null (which effectively disables the CPU data sink) your CPU may run cooler but your system will quickly become constipated with all that excess data and start to behave erratically. If you have a fast network connection you can cool down your CPU by reading data out of /dev/random and sending it off somewhere; however you run the risk of overheating your network connection and / or angering your ISP, as most of the data will end up getting converted to heat by their equipment, but they generally have good cooling, so if you do not overdo it you should be OK. Paul Robinson adds: There are other methods. As every good sysadmin knows, it is part of standard practice to send data to the screen of interesting variety to keep all the pixies that make up your picture happy. Screen pixies (commonly mis-typed or re-named as pixels) are categorized by the type of hat they wear (red, green or blue) and will hide or appear (thereby showing the color of their hat) whenever they receive a little piece of food. Video cards turn data into pixie-food, and then send them to the pixies — the more expensive the card, the better the food, so the better behaved the pixies are. They also need constant stimulation — this is why screen savers exist. To take your suggestions further, you could just throw the random data to console, thereby letting the pixies consume it. This causes no heat to be produced at all, keeps the pixies happy and gets rid of your data quite quickly, even if it does make things look a bit messy on your screen. Incidentally, as an ex-admin of a large ISP who experienced many problems attempting to maintain a stable temperature in a server room, I would strongly discourage people sending the data they do not want out to the network. The fairies who do the packet switching and routing get annoyed by it as well. My colleague sits at the computer too much, how can I prank her? Install games/sl and wait for her to mistype sl for ls. Advanced Topics How can I learn more about &os;'s internals? See the &os; Architecture Handbook. Additionally, much general &unix; knowledge is directly applicable to &os;. How can I contribute to &os;? Please see the article on Contributing to &os; for specific advice on how to do this. Assistance is more than welcome! What are snapshots and releases? There are currently four active/semi-active branches in the &os; Subversion Repository. (Earlier branches are only changed very rarely, which is why there are only four active branches of development): &rel2.releng; AKA &rel2.stable; &rel.releng; AKA &rel.stable; &rel.head.releng; AKA -CURRENT AKA &rel.head; HEAD is not an actual branch tag, like the others; it is simply a symbolic constant for the current, non-branched development stream which we simply refer to as -CURRENT. Right now, -CURRENT is the &rel.head.relx; development stream; the &rel.stable; branch, &rel.releng;, forked off from -CURRENT in &rel.relengdate; and the &rel2.stable; branch, &rel2.releng;, forked off from -CURRENT in &rel2.relengdate;. Can I follow -CURRENT with limited Internet access? Yes, you can do this without downloading the whole source tree by using the CTM facility. I have written a kernel extension, who do I send it to? Please take a look at the article on Contributing to &os; to learn how to submit code. And thanks for the thought! How can I make the most of the data I see when my kernel panics? Here is typical kernel panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault When you see a message like this, it is not enough to just reproduce it and send it in. The instruction pointer value is important; unfortunately, it is also configuration dependent. In other words, the value varies depending on the exact kernel image that you are using. If you are using a GENERIC kernel image from one of the snapshots, then it is possible for somebody else to track down the offending function, but if you are running a custom kernel then only you can tell us where the fault occurred. What you should do is this: Write down the instruction pointer value. Note that the 0x8: part at the beginning is not significant in this case: it is the 0xf0xxxxxx part that we want. When the system reboots, do the following: &prompt.user; nm kernel.that.caused.the.panic | grep f0xxxxxx where f0xxxxxx is the instruction pointer value. The odds are you will not get an exact match since the symbols in the kernel symbol table are for the entry points of functions and the instruction pointer address will be somewhere inside a function, not at the start. If you do not get an exact match, omit the last digit from the instruction pointer value and try again, i.e.: &prompt.user; nm kernel.that.caused.the.panic | grep f0xxxxx If that does not yield any results, chop off another digit. Repeat until you get some sort of output. The result will be a possible list of functions which caused the panic. This is a less than exact mechanism for tracking down the point of failure, but it is better than nothing. However, the best way to track down the cause of a panic is by capturing a crash dump, then using &man.kgdb.1; to generate a stack trace on the crash dump. In any case, the method is this: Make sure that the following line is included in your kernel configuration file (/usr/src/sys/arch/conf/MYKERNEL): makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols Change to the /usr/src directory: &prompt.root; cd /usr/src Compile the kernel: &prompt.root; make buildkernel KERNCONF=MYKERNEL Wait for &man.make.1; to finish compiling. &prompt.root; make installkernel KERNCONF=MYKERNEL Reboot. If you do not use the KERNCONF make variable a GENERIC kernel will be built and installed. The &man.make.1; process will have built two kernels. /usr/obj/usr/src/sys/MYKERNEL/kernel and /usr/obj/usr/src/sys/MYKERNEL/kernel.debug. kernel was installed as /boot/kernel/kernel, while kernel.debug can be used as the source of debugging symbols for &man.kgdb.1;. To make sure you capture a crash dump, you need edit /etc/rc.conf and set dumpdev to point to your swap partition (or AUTO). This will cause the &man.rc.8; scripts to use the &man.dumpon.8; command to enable crash dumps. You can also run &man.dumpon.8; manually. After a panic, the crash dump can be recovered using &man.savecore.8;; if dumpdev is set in /etc/rc.conf, the &man.rc.8; scripts will run &man.savecore.8; automatically and put the crash dump in /var/crash. &os; crash dumps are usually the same size as the physical RAM size of your machine. That is, if you have 512 MB of RAM, you will get a 512 MB crash dump. Therefore you must make sure there is enough space in /var/crash to hold the dump. Alternatively, you run &man.savecore.8; manually and have it recover the crash dump to another directory where you have more room. It is possible to limit the size of the crash dump by using options MAXMEM=N where N is the size of kernel's memory usage in KBs. For example, if you have 1 GB of RAM, you can limit the kernel's memory usage to 128 MB by this way, so that your crash dump size will be 128 MB instead of 1 GB. Once you have recovered the crash dump, you can get a stack trace with &man.kgdb.1; as follows: &prompt.user; kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0 (kgdb) backtrace Note that there may be several screens worth of information; ideally you should use &man.script.1; to capture all of them. Using the unstripped kernel image with all the debug symbols should show the exact line of kernel source code where the panic occurred. Usually you have to read the stack trace from the bottom up to trace the exact sequence of events that lead to the crash. You can also use &man.kgdb.1; to print out the contents of various variables or structures to examine the system state at the time of the crash. Now, if you are really insane and have a second computer, you can also configure &man.kgdb.1; to do remote debugging such that you can use &man.kgdb.1; on one system to debug the kernel on another system, including setting breakpoints, single-stepping through the kernel code, just like you can do with a normal user-mode program. If you have DDB enabled and the kernel drops into the debugger, you can force a panic (and a crash dump) just by typing panic at the ddb prompt. It may stop in the debugger again during the panic phase. If it does, type continue and it will finish the crash dump. Why has dlsym() stopped working for ELF executables? The ELF toolchain does not, by default, make the symbols defined in an executable visible to the dynamic linker. Consequently dlsym() searches on handles obtained from calls to dlopen(NULL, flags) will fail to find such symbols. If you want to search, using dlsym(), for symbols present in the main executable of a process, you need to link the executable using the option to the ELF linker (&man.ld.1;). How can I increase or reduce the kernel address space on i386? By default, the kernel address space is 1 GB (2 GB for PAE) for i386. If you run a network-intensive server (e.g., a FTP or HTTP server), or you want to use ZFS, you might find that is not enough. Add the following line to your kernel configuration file to increase available space and rebuild your kernel: options KVA_PAGES=N To find the correct value of N, divide the desired address space size (in megabytes) by four. (For example, it is 512 for 2 GB.) Acknowledgments This innocent little Frequently Asked Questions document has been written, rewritten, edited, folded, spindled, mutilated, eviscerated, contemplated, discombobulated, cogitated, regurgitated, rebuilt, castigated, and reinvigorated over the last decade, by a cast of hundreds if not thousands. Repeatedly. We wish to thank every one of the people responsible, and we encourage you to join them in making this FAQ even better. &bibliography; diff --git a/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml b/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml index 1fed435480..818dc7c981 100644 --- a/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/bsdinstall/chapter.xml @@ -1,2753 +1,2753 @@ Jim Mock Restructured, reorganized, and parts rewritten by Randy Pratt The sysinstall walkthrough, screenshots, and general copy by Gavin Atkinson Updated for bsdinstall by Warren Block Installing &os; 9.<replaceable>X</replaceable> and Later Synopsis installation &os; comes with a text-based, easy to use installation program. &os; 9.0-RELEASE and later use an installation program called bsdinstall, while releases prior to &os; 9.0-RELEASE using sysinstall for installation. This chapter describes the use of bsdinstall. The use of sysinstall is covered in . After reading this chapter, you will know: How to create the &os; installation media. How &os; subdivides and refers to hard disks. How to start bsdinstall. The questions bsdinstall will ask you, what they mean, and how to answer them. Before reading this chapter, you should: Read the supported hardware list that shipped with the version of &os; you are installing, and verify that your hardware is supported. In general, these installation instructions are written for &i386; (PC compatible) architecture computers. Where applicable, instructions specific to other platforms will be listed. There may be minor differences between the installer and what is shown here, so use this chapter as a general guide rather than as exact literal instructions. Hardware Requirements Minimal Configuration The minimal configuration to install &os; varies with the &os; version and the hardware architecture. A summary of this information is given in the following sections. Depending on the method you choose to install &os;, you may also need a supported CDROM drive, and in some cases a network adapter. This will be covered by . &os;/&arch.i386; &os;/&arch.i386; requires a 486 or better processor and at least 64 MB of RAM. At least 1.1 GB of free hard drive space is needed for the most minimal installation. On old computers, increasing RAM and hard drive space is usually more effective at improving performance than installing a faster processor. &os;/&arch.amd64; There are two classes of processors capable of running &os;/&arch.amd64;. The first are AMD64 processors, including the &amd.athlon;64, &amd.athlon;64-FX, &amd.opteron; or better processors. The second class of processors that can use &os;/&arch.amd64; includes those using the &intel; EM64T architecture. Examples of these processors include the &intel; &core; 2 Duo, Quad, Extreme processor families, the &intel; &xeon; 3000, 5000, and 7000 sequences of processors, and the &intel; &core; i3, i5 and i7 processors. If you have a machine based on an nVidia nForce3 Pro-150, you must use the BIOS setup to disable the IO APIC. If you do not have an option to do this, you will likely have to disable ACPI instead. There are bugs in the Pro-150 chipset for which we have not yet found a workaround. &os;/&arch.powerpc; &apple; &macintosh; All New World &apple; &macintosh; systems with built-in USB are supported. SMP is supported on machines with multiple CPUs. A 32-bit kernel can only use the first 2 GB of RAM. &firewire; is not supported on the Blue & White PowerMac G3. &os;/&arch.sparc64; Systems supported by &os;/&arch.sparc64; are listed at the FreeBSD/sparc64 Project. A dedicated disk is required for &os;/&arch.sparc64;. It is not possible to share a disk with another operating system at this time. Supported Hardware Hardware architectures and devices supported by a &os; release are listed in the Hardware Notes file. Usually named HARDWARE.TXT, the file is located in the root directory of the release media. Copies of the supported hardware list are also available on the Release Information page of the &os; web site. Pre-Installation Tasks Back Up Your Data Back up all important data on the target computer where &os; will be installed. Test the backups before continuing. The &os; installer will ask before making changes to the disk, but once the process has started it cannot be undone. Decide Where to Install &os; If &os; will be the only operating system installed, and will be allowed to use the entire hard disk, the rest of this section can be skipped. But if &os; will share the disk with other operating systems, an understanding of disk layout is useful during the installation. Disk Layouts for &os;/&arch.i386; and &os;/&arch.amd64; Hard disks can be divided into multiple sections. These sections are called partitions. There are two ways of dividing a disk into partitions. A traditional Master Boot Record (MBR) holds a partition table defining up to four primary partitions. (For historical reasons, &os; calls primary partitions slices.) A limit of only four partitions is restrictive for large disks, so one of these primary partitions can be made into an extended partition. Multiple logical partitions may then be created inside the extended partition. This may sound a little unwieldy, and it is. The GUID Partition Table (GPT) is a newer and simpler method of partitioning a disk. GPT is far more versatile than the traditional MBR partition table. Common GPT implementations allow up to 128 partitions per disk, eliminating the need for inconvenient workarounds like logical partitions. Some older operating systems like &windows; XP are not compatible with the GPT partition scheme. If &os; will be sharing a disk with such an operating system, MBR partitioning is required. &os;'s standard boot loader requires either a primary or GPT partition. (See for more information about the &os; booting process.) If all of the primary or GPT partitions are already in use, one must be freed for &os;. A minimal installation of &os; takes as little as 1 GB of disk space. However, that is a very minimal install, leaving almost no free space. A more realistic minimum is 3 GB without a graphical environment, and 5 GB or more if a graphical user interface will be used. Third-party application software requires more space. A variety of free and commercial partition resizing tools are available. GParted Live is a free Live CD which includes the GParted partition editor. GParted is also included with many other Linux Live CD distributions. Disk partition applications can destroy data. Make a full backup and verify its integrity before modifying disk partitions. Resizing µsoft; Vista partitions can be difficult. A Vista installation CDROM can be useful when attempting such an operation. Using an Existing Partition A &windows; computer has a single 40 GB disk that has been split into two 20 GB partitions. &windows; calls them C: and D:. The C: partition contains 10 GB of data, and the D: partition contains 5 GB of data. Moving the data from D: to C: frees up the second partition to be used for &os;. Shrinking an Existing Partition A &windows; computer has a single 40 GB disk and one large partition using the whole disk. &windows; shows this 40 GB partition as a single C:. 15 GB of space is being used. The goal is to end up with &windows; in a 20 GB partition, and have another 20 GB partition for &os;. There are two ways to do this: Back up your &windows; data. Then reinstall &windows;, creating a 20 GB partition during the install. Use a partition resizing tool like GParted to shrink the &windows; partition and create a new partition in the freed space for &os;. Disk partitions containing different operating systems make it possible to run any one of those operating systems at a time. An alternative method that allows running multiple operating systems at the same time is covered in . Collect Network Information Some &os; installation methods need a network connection to download files. To connect to an Ethernet network (or cable or DSL modem with an Ethernet interface), the installer will request some information about the network. DHCP is commonly used to provide automatic network configuration. If DHCP is not available, this network information must be obtained from the local network administrator or service provider: Network Information IP address Subnet mask Default router IP address Domain name of the local network DNS server IP address(es) Check for &os; Errata Although the &os; Project strives to ensure that each release of &os; is as stable as possible, bugs occasionally creep into the process. On very rare occasions those bugs affect the installation process. As these problems are discovered and fixed, they are noted in the FreeBSD Errata on the &os; web site. Check the errata before installing to make sure that there are no problems that might affect the installation. Information and errata for all the releases can be found on the release information section of the &os; web site. Prepare the Installation Media A &os; installation is started by booting the computer with a &os; installation CD, DVD, or USB memory stick. The installer is not a program that can be run from within another operating system. In addition to the standard installation media which contains copies of all the &os; installation files, there is a bootonly variant. Bootonly install media does not have copies of the installation files, but downloads them from the network during an install. The bootonly install CD is consequently much smaller, and reduces bandwidth usage during the install by only downloading required files. Copies of &os; installation media are available at the &os; web site. If you already have a copy of &os; on CDROM, DVD, or USB memory stick, this section can be skipped. &os; CD and DVD images are bootable ISO files. Only one CD or DVD is needed for an install. Burn the ISO image to a bootable CD or DVD using the CD recording applications available with your current operating system. To create a bootable memory stick, follow these steps: Acquire the Memory Stick Image Memory stick images for &os; 9.0-RELEASE and later can be downloaded from the ISO-IMAGES/ directory at ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/arch/arch/ISO-IMAGES/version/&os;-version-RELEASE-arch-memstick.img. Replace arch and version with the architecture and the version number which you want to install, respectively. For example, the memory stick images for &os;/&arch.i386; 9.0-RELEASE are available from . A different directory path is used for &os; 8.X and earlier versions. Details of download and installation of &os; 8.X and earlier is covered in . The memory stick image has a .img extension. The ISO-IMAGES/ directory contains a number of different images, and the one needed depends on the version of &os; being installed, and in some cases, the target hardware. Before proceeding, back up the data on the USB stick, as this procedure will erase it. Write the Image File to the Memory Stick Using &os; to Write the Image The example below shows /dev/da0 as the target device where the image will be written. Be very careful that the correct device is used as the output target, or you may destroy existing data. Writing the Image with &man.dd.1; The .img file is not a regular file. It is an image of the complete contents of the memory stick. It cannot simply be copied like a regular file, but must be written directly to the target device with &man.dd.1;: &prompt.root; dd if=&os;-9.0-RELEASE-&arch.i386;-memstick.img of=/dev/da0 bs=64k Using &windows; to Write the Image Be sure to give the correct drive letter as the output target, or you may overwrite and destroy existing data. Obtaining <application>Image Writer for &windows;</application> Image Writer for &windows; is a free application that can correctly write an image file to a memory stick. Download it from and extract it into a folder. Writing the Image with Image Writer Double-click the Win32DiskImager icon to start the program. Verify that the drive letter shown under Device is the drive with the memory stick. Click the folder icon and select the image to be written to the memory stick. Click [ Save ] to accept the image file name. Verify that everything is correct, and that no folders on the memory stick are open in other windows. When everything is ready, click [ Write ] to write the image file to the memory stick. Installation from floppy disks is no longer supported. You are now ready to start installing &os;. Starting the Installation By default, the installation will not make any changes to your disk(s) until you see the following message: Your changes will now be written to disk. If you have chosen to overwrite existing data, it will be PERMANENTLY ERASED. Are you sure you want to commit your changes? The install can be exited at any time prior to this warning without changing the contents of the hard drive. If you are concerned that you have configured something incorrectly you can just turn the computer off before this point, and no damage will be done. Booting Booting on &i386; and &arch.amd64; If you prepared a bootable USB stick, as described in , then plug in your USB stick before turning on the computer. If you are booting from CDROM, then you will need to turn on the computer, and insert the CDROM at the first opportunity. Configure your machine to boot from either the CDROM or from USB, depending on the media being used for the installation. BIOS configurations allow the selection of a specific boot device. Most systems also provide for selecting a boot device during startup, typically by pressing F10, F11, F12, or Escape. If your computer starts up as normal and loads your existing operating system, then either: The disks were not inserted early enough in the boot process. Leave them in, and try restarting your computer. The BIOS changes earlier did not work correctly. You should redo that step until you get the right option. Your particular BIOS does not support booting from the desired media. The Plop Boot Manager can be used to boot older computers from CD or USB media. &os; will start to boot. If you are booting from CDROM you will see a display similar to this (version information omitted): Booting from CD-ROM... 645MB medium detected CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS CD is cd0 BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 636kB/261056kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x64daa0 data=0xa4e80+0xa9e40 syms=[0x4+0x6cac0+0x4+0x88e9d] \ The &os; boot loader is displayed: Either wait ten seconds, or press Enter. Booting for &macintosh; &powerpc; On most machines, holding C on the keyboard during boot will boot from the CD. Otherwise, hold Command Option O F , or Windows Alt O F on non-&apple; keyboards. At the 0 > prompt, enter boot cd:,\ppc\loader cd:0 For Xserves without keyboards, see &apple;'s support web site about booting into Open Firmware. Booting for &sparc64; Most &sparc64; systems are set up to boot automatically from disk. To install &os;, you need to boot over the network or from a CDROM, which requires you to break into the PROM (OpenFirmware). To do this, reboot the system, and wait until the boot message appears. It depends on the model, but should look about like: Sun Blade 100 (UltraSPARC-IIe), Keyboard Present Copyright 1998-2001 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.2, 128 MB memory installed, Serial #51090132. Ethernet address 0:3:ba:b:92:d4, Host ID: 830b92d4. If your system proceeds to boot from disk at this point, you need to press L1A or StopA on the keyboard, or send a BREAK over the serial console (using for example ~# in &man.tip.1; or &man.cu.1;) to get to the PROM prompt. It looks like this: ok ok {0} This is the prompt used on systems with just one CPU. This is the prompt used on SMP systems, the digit indicates the number of the active CPU. At this point, place the CDROM into your drive, and from the PROM prompt, type boot cdrom. Reviewing the Device Probe Results The last few hundred lines that have been displayed on screen are stored and can be reviewed. To review the buffer, press Scroll Lock. This turns on scrolling in the display. You can then use the arrow keys, or PageUp and PageDown to view the results. Press Scroll Lock again to stop scrolling. Do this now, to review the text that scrolled off the screen when the kernel was carrying out the device probes. You will see text similar to , although the precise text will differ depending on the devices that you have in your computer.

Typical Device Probe Results Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0 r225473M: Sun Sep 11 16:07:30 BST 2011 root@psi:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz (2527.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x8e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 2926649344 (2791 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <TOSHIB A0064 > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 <Version 2.0> irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <TOSHIB A0064> on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, b6690000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 cpu0: <ACPI CPU> on acpi0 ACPI Warning: Incorrect checksum in table [ASF!] - 0xFE, should be 0x9A (20110527/tbutils-282) cpu1: <ACPI CPU> on acpi0 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0 vgapci0: <VGA-compatible display> port 0xcff8-0xcfff mem 0xff400000-0xff7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: <Intel GM45 SVGA controller> on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory vgapci1: <VGA-compatible display> mem 0xffc00000-0xffcfffff at device 2.1 on pci0 pci0: <simple comms> at device 3.0 (no driver attached) em0: <Intel(R) PRO/1000 Network Connection 7.2.3> port 0xcf80-0xcf9f mem 0xff9c0000-0xff9dffff,0xff9fe000-0xff9fefff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:1c:7e:6a:ca:b0 uhci0: <Intel 82801I (ICH9) USB controller> port 0xcf60-0xcf7f irq 16 at device 26.0 on pci0 usbus0: <Intel 82801I (ICH9) USB controller> on uhci0 uhci1: <Intel 82801I (ICH9) USB controller> port 0xcf40-0xcf5f irq 21 at device 26.1 on pci0 usbus1: <Intel 82801I (ICH9) USB controller> on uhci1 uhci2: <Intel 82801I (ICH9) USB controller> port 0xcf20-0xcf3f irq 19 at device 26.2 on pci0 usbus2: <Intel 82801I (ICH9) USB controller> on uhci2 ehci0: <Intel 82801I (ICH9) USB 2.0 controller> mem 0xff9ff800-0xff9ffbff irq 19 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: <Intel 82801I (ICH9) USB 2.0 controller> on ehci0 hdac0: <Intel 82801I High Definition Audio Controller> mem 0xff9f8000-0xff9fbfff irq 22 at device 27.0 on pci0 pcib1: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0 pci1: <ACPI PCI bus> on pcib1 iwn0: <Intel(R) WiFi Link 5100> mem 0xff8fe000-0xff8fffff irq 16 at device 0.0 on pci1 pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0 pci2: <ACPI PCI bus> on pcib2 pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0 pci4: <ACPI PCI bus> on pcib3 pcib4: <ACPI PCI-PCI bridge> at device 30.0 on pci0 pci5: <ACPI PCI bus> on pcib4 cbb0: <RF5C476 PCI-CardBus Bridge> at device 11.0 on pci5 cardbus0: <CardBus bus> on cbb0 pccard0: <16-bit PCCard bus> on cbb0 isab0: <PCI-ISA bridge> at device 31.0 on pci0 isa0: <ISA bus> on isab0 ahci0: <Intel ICH9M AHCI SATA controller> port 0x8f58-0x8f5f,0x8f54-0x8f57,0x8f48-0x8f4f,0x8f44-0x8f47,0x8f20-0x8f3f mem 0xff9fd800-0xff9fdfff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported ahcich0: <AHCI channel> at channel 0 on ahci0 ahcich1: <AHCI channel> at channel 1 on ahci0 ahcich2: <AHCI channel> at channel 4 on ahci0 acpi_lid0: <Control Method Lid Switch> on acpi0 battery0: <ACPI Control Method Battery> on acpi0 acpi_button0: <Power Button> on acpi0 acpi_acad0: <AC Adapter> on acpi0 acpi_toshiba0: <Toshiba HCI Extras> on acpi0 acpi_tz0: <Thermal Zone> on acpi0 attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range est0: <Enhanced SpeedStep Frequency Control> on cpu0 p4tcc0: <CPU Frequency Thermal Control> on cpu0 est1: <Enhanced SpeedStep Frequency Control> on cpu1 p4tcc1: <CPU Frequency Thermal Control> on cpu1 Timecounters tick every 1.000 msec hdac0: HDA Codec #0: Realtek ALC268 hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown) pcm0: <HDA Realtek ALC268 PCM #0 Analog> at cad 0 nid 1 on hdac0 pcm1: <HDA Realtek ALC268 PCM #1 Analog> at cad 0 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: <Intel> at usbus0 uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 ugen1.1: <Intel> at usbus1 uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 ugen2.1: <Intel> at usbus2 uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2 ugen3.1: <Intel> at usbus3 uhub3: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered ugen2.2: <vendor 0x0b97> at usbus2 uhub8: <vendor 0x0b97 product 0x7761, class 9/0, rev 1.10/1.10, addr 2> on usbus2 ugen1.2: <Microsoft> at usbus1 ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: <Hitachi HTS543225L9SA00 FBEOC43C> ATA-8 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ums0: <Microsoft Microsoft 3-Button Mouse with IntelliEyeTM, class 0/0, rev 1.10/3.00, addr 2> on usbus1 SMP: AP CPU #1 Launched! cd0 at ahcich1 bus 0 scbus2 target 0 lun 0 cd0: <TEAC DV-W28S-RT 7.0C> Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, ums0: 3 buttons and [XYZ] coordinates ID=0 UDMA2, ATAPI 12bytes, PIO 8192bytes) cd0: cd present [1 x 2048 byte records] ugen0.2: <Microsoft> at usbus0 ukbd0: <Microsoft Natural Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2> on usbus0 kbd2 at ukbd0 uhid0: <Microsoft Natural Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 2> on usbus0 Trying to mount root from cd9660:/dev/iso9660/FREEBSD_INSTALL [ro]... Check the probe results carefully to make sure that &os; found all the devices you expected. If a device was not found, then it will not be listed. Kernel modules allows you to add in support for devices which are not in the GENERIC kernel. After the procedure of device probing, you will see . The install media can be used in three ways: to install &os;, as a live CD, or to simply access a &os; shell. Use the arrow keys to choose an option, and Enter to select.

Selecting Installation Media Mode Selecting [ Install ] here will enter the installer. Introducing <application>bsdinstall</application> bsdinstall is a text-based &os; - installer program written by &a.nwhitehorn; and introduced in + installer program written by &a.nwhitehorn.email; and introduced in 2011 for &os; 9.0. - &a.kmoore;'s pc-sysinstall is + &a.kmoore.email;'s pc-sysinstall is included with PC-BSD, and can also be used to install &os;. Although sometimes confused with bsdinstall, the two are not related. The bsdinstall menu system is controlled by the arrow keys, Enter, Tab, Space, and other keys. Selecting the Keymap Menu Depending on the system console being used, bsdinstall may initially prompt to select a non-default keyboard layout.

Keymap Selection If [ YES ] is selected, the following keyboard selection screen will be displayed. Otherwise, this selection menu will not be displayed, and a default keyboard mapping will be used.

Selecting Keyboard Menu Select the keymap that most closely represents the mapping of the keyboard attached to the system, using the up/down arrow keys and pressing Enter. Pressing Esc will use the default keymap. United States of America ISO-8859-1 is also a safe option if the choice of keymap is not clear. Setting the Hostname Next, bsdinstall will prompt for the hostname to be given to the newly installed system.

Setting the Hostname The entered hostname should be a fully-qualified hostname, such as machine3.example.com Selecting Components to Install Next, bsdinstall will prompt to select optional components to install.

Selecting Components to Install Deciding which components to install will depend largely on the intended use of the system and the amount of disk space available. The &os; Kernel and userland (collectively the base system) are always installed. Depending on the type of installation, some of these components may not appear. Optional Components doc - Additional documentation, mostly of historical interest. Documentation provided by the &os; Documentation Project may be installed later. games - Several traditional BSD games, including fortune, rot13, and others. lib32 - Compatibility libraries for running 32-bit applications on a 64-bit version of &os;. ports - The &os; Ports Collection. The ports collection is an easy and convenient way to install software. The Ports Collection does not contain the source code necessary to compile the software. Instead, it is a collection of files which automates the downloading, compiling and installation of third-party software packages. discusses how to use the ports collection. The installation program does not check to see if you have adequate space. Select this option only if you have adequate hard disk space. As of &os; 9.0, the &os; Ports Collection takes up about &ports.size; of disk space. You can safely assume a larger value for more recent versions of &os;. src - System source code. &os; comes with full source code for both the kernel and the userland. Although not required for the majority of applications, it may be required to build certain software supplied as source (for example, device drivers or kernel modules), or for developing &os; itself. The full source tree requires 1 GB of disk space, and recompiling the entire &os; system requires an additional 5 GB of space. Installing from the Network The bootonly installation media does not hold copies of the installation files. When a bootonly installation method is used, the files must be retrieved over a network connection as they are needed.

Installing from the Network After the network connection has been configured as shown in , a mirror site is selected. Mirror sites cache copies of the &os; files. Choose a mirror site located in the same region of the world as the computer on which &os; is being installed. Files can be retrieved more quickly when the mirror is close to the target computer, and installation time will be reduced.

Choosing a Mirror Installation will continue as if the installation files were located on local media. Allocating Disk Space There are three ways to allocate disk space for &os;. Guided partitioning automatically sets up disk partitions, while Manual partitioning allows advanced users to create customized partitions. Finally, there's the option of starting a shell where command-line programs like &man.gpart.8;, &man.fdisk.8;, and &man.bsdlabel.8; can be used directly.

Selecting Guided or Manual Partitioning Guided Partitioning If multiple disks are connected, choose the one where &os; is to be installed.

Selecting from Multiple Disks The entire disk can be allocated to &os;, or just a portion of it. If [ Entire Disk ] is chosen, a general partition layout filling the whole disk is created. Selecting [ Partition ] creates a partition layout in unused space on the disk.

Selecting Entire Disk or Partition After the partition layout has been created, review it carefully for accuracy. If a mistake has been made, selecting [ Revert ] will reset the partitions as they were previously, or [ Auto ] will recreate the automatic &os; partitions. Partitions can be manually created, modified, or deleted. When the partitioning is correct, select [ Finish ] to continue with the installation.

Review Created Partitions Manual Partitioning Manual partitioning goes straight to the partition editor.

Manually Create Partitions Highlighting a drive (ada0 in this example) and selecting [ Create ] displays a menu for choosing the type of partitioning scheme.

Manually Create Partitions GPT partitioning is usually the most appropriate choice for PC-compatible computers. Older PC operating systems that are not compatible with GPT may require MBR partitioning instead. The other partitioning schemes are generally used for uncommon or older computer systems. Partitioning Schemes Abbreviation Description APM Apple Partition Map, used by &powerpc; &macintosh;. BSD BSD Labels without an MBR, sometimes called "dangerously dedicated mode". See &man.bsdlabel.8;. GPT GUID Partition Table. MBR Master Boot Record. PC98 MBR variant, used by NEC PC-98 computers. VTOC8 Volume Table Of Contents, used by Sun SPARC64 and UltraSPARC computers.

After the partitioning scheme has been selected and created, selecting [ Create ] again will create new partitions.

Manually Create Partitions A standard &os; GPT installation uses at least three partitions: Standard &os; <acronym>GPT</acronym> Partitions freebsd-boot - &os; boot code. freebsd-ufs - A &os; UFS filesystem. freebsd-swap - &os; swap space. Another partition type worth noting is freebsd-zfs, used for partitions that will contain a &os; ZFS filesystem. See . &man.gpart.8; shows more of the available GPT partition types. Multiple filesystem partitions can be used, and some people may prefer a traditional layout with separate partitions for the /, /var, /tmp, and /usr filesystems. See for an example. Size may be entered with common abbreviations: K for kilobytes, M for megabytes, or G for gigabytes. Proper sector alignment provides the best performance, and making partition sizes even multiples of 4K bytes helps to ensure alignment on drives with either 512-byte or 4K-byte sectors. Generally, using partition sizes that are even multiples of 1M or 1G is the easiest way to make sure every partition starts at an even multiple of 4K. One exception: at present, the freebsd-boot partition should be no larger than 512K due to boot code limitations. A mountpoint is needed if this partition will contain a filesystem. If only a single UFS partition will be created, the mountpoint should be /. A label is also requested. A label is a name by which this partition will be known. Drive names or numbers can change if the drive is connected to a different controller or port, but the partition label does not change. Referring to labels instead of drive names and partition numbers in files like /etc/fstab makes the system more tolerant of changing hardware. GPT labels appear in /dev/gpt/ when a disk is attached. Other partitioning schemes have different label capabilities, and their labels appear in different directories in /dev/. Use a unique label on every filesystem to avoid conflicts from identical labels. A few letters from the computer's name, use, or location can be added to the label. "labroot" or "rootfs-lab" for the UFS root partition on the lab's computer, for example. Creating Traditional Split Filesystem Partitions For a traditional partition layout where the /, /var, /tmp, and /usr directories are separate filesystems on their own partitions, create a GPT partitioning scheme, then create the partitions as shown. Partition sizes shown are typical for a 20G target disk. If more space is available on the target disk, larger swap or /var partitions may be useful. Labels shown here are prefixed with ex for "example", but readers should use other unique label values as described above. By default, &os;'s gptboot expects the first UFS partition found to be the / partition. Partition Type Size Mountpoint Label freebsd-boot 512K freebsd-ufs 2G / exrootfs freebsd-swap 4G exswap freebsd-ufs 2G /var exvarfs freebsd-ufs 1G /tmp extmpfs freebsd-ufs accept the default (remainder of the disk) /usr exusrfs After the custom partitions have been created, select [ Finish ] to continue with the installation. Committing to the Installation This is the last chance for aborting the installation to prevent changes to the hard drive.

Final Confirmation Select [ Commit ] and press Enter to proceed. If changes need to be made, select [ Back ] to return to the partition editor. [ Revert & Exit ] will exit the installer without making any changes to the hard drive. Installation time will vary depending on the distributions chosen, installation media, and speed of the computer. There will be a series of messages displayed indicating progress. Firstly, the installer will write the partitions to the disk, and perform a newfs to initialise the partitions. If doing a network install, bsdinstall will then proceed to download the required distribution files.

Fetching Distribution Files Next, the integrity of the distribution files is verified, to ensure they have not been corrupted during download or misread from the installation media.

Verifying Distribution Files Finally, the verified distribution files are extracted to the disk.

Extracting Distribution Files Once all requested distribution files have been extracted, bsdinstall will then drop straight into the post-installation configuration tasks (see ). Post-Installation Configuration of various options follows a successful installation of &os;. An option can be configured by re-entering the configuration options from the final menu before booting into the newly installed &os; system. Setting the <username>root</username> Password The root password must be set. Note that while entering the password, the characters being typed are not displayed on the screen. After the password has been entered, it must be entered again. This helps prevent typing errors.

Setting the <username>root</username> Password After the password has been successfully entered, the installation will continue. Configuring Network Interfaces Network configuration will be skipped if it has already been done as part of a bootonly installation. A list of all the network interfaces found on the computer is shown next. Select one to be configured.

Choose a Network Interface Configuring a Wireless Network Interface If a wireless network interface is chosen, wireless identification and security parameters must be entered to allow it to connect to the network. Wireless networks are identified by a Service Set Identifier, or SSID. The SSID is a short, unique name given to each network. Most wireless networks encrypt transmitted data to protect information from unauthorized viewing. WPA2 encryption is strongly recommended. Older encryption types, like WEP, offer very little security. The first step in connecting to a wireless network is to scan for wireless access points.

Scanning for Wireless Access Points SSIDs found during the scan are listed, followed by a description of the encryption types available for that network. If the desired SSID does not appear in the list, select [ Rescan ] to scan again. If the desired network still does not appear, check for problems with antenna connections or try moving the computer closer to the access point. Rescan after each change is made.

Choosing a Wireless Network The encryption information for connecting to the selected wireless network is entered after selecting the network. With WPA2, only a password (also known as the Pre-Shared Key, or PSK) is needed. Characters typed into the input box are shown as asterisks for security.

WPA2 Setup Network configuration continues after selection of the wireless network and entry of the connection information. Configuring IPv4 Networking Choose whether IPv4 networking is to be used. This is the most common type of network connection.

Choose IPv4 Networking There are two methods of IPv4 configuration. DHCP will automatically configure the network interface correctly, and is the preferred method. Static configuration requires manual entry of network information. Do not enter random network information, as it will not work. Obtain the information shown in from the network administrator or service provider. IPv4 DHCP Network Configuration If a DHCP server is available, select [ Yes ] to automatically configure the network interface.

Choose IPv4 DHCP Configuration IPv4 Static Network Configuration Static configuration of the network interface requires entry of some IPv4 information.

IPv4 Static Configuration IP Address - The manually-assigned IPv4 address to be assigned to this computer. This address must be unique and not already in use by another piece of equipment on the local network. Subnet Mask - The subnet mask used for the local network. Typically, this is 255.255.255.0. Default Router - The IP address of the default router on this network. Usually this is the address of the router or other network equipment that connects the local network to the Internet. Also known as the default gateway. Configuring IPv6 Networking IPv6 is a newer method of network configuration. If IPv6 is available and desired, choose [ Yes ] to select it.

Choose IPv6 Networking IPv6 also has two methods of configuration. SLAAC , or StateLess Address AutoConfiguration, will automatically configure the network interface correctly. Static configuration requires manual entry of network information. IPv6 Stateless Address Autoconfiguration SLAAC allows an IPv6 network component to request autoconfiguration information from a local router. See RFC4862 for more information.

Choose IPv6 SLAAC Configuration IPv6 Static Network Configuration Static configuration of the network interface requires entry of the IPv6 configuration information.

IPv6 Static Configuration IPv6 Address - The manually-assigned IP address to be assigned to this computer. This address must be unique and not already in use by another piece of equipment on the local network. Default Router - The IPv6 address of the default router on this network. Usually this is the address of the router or other network equipment that connects the local network to the Internet. Also known as the default gateway. Configuring <acronym role="Domain Name System">DNS</acronym> The Domain Name System (or DNS) Resolver converts hostnames to and from network addresses. If DHCP or SLAAC was used to autoconfigure the network interface, the Resolver Configuration values may already be present. Otherwise, enter the local network's domain name in the Search field. DNS #1 and DNS #2 are the IP addresses for the local DNS servers. At least one DNS server is required.

DNS Configuration Setting the Time Zone Setting the time zone for your machine will allow it to automatically correct for any regional time changes and perform other time zone related functions properly. The example shown is for a machine located in the Eastern time zone of the United States. Your selections will vary according to your geographical location.

Select Local or UTC Clock Select [ Yes ] or [ No ] according to how the machine's clock is configured and press Enter. If you do not know whether the system uses UTC or local time, select [ No ] to choose the more commonly-used local time.

Select a Region The appropriate region is selected using the arrow keys and then pressing Enter.

Select a Country Select the appropriate country using the arrow keys and press Enter.

Select a Time Zone The appropriate time zone is selected using the arrow keys and pressing Enter.

Confirm Time Zone Confirm the abbreviation for the time zone is correct. If it looks okay, press Enter to continue with the post-installation configuration. Selecting Services to Enable Additional system services which will be started at boot can be enabled. All of these services are optional.

Selecting Additional Services to Enable Additional Services sshd - Secure Shell (SSH) daemon for secure remote access. moused - Provides mouse usage within the system console. ntpd - Network Time Protocol (NTP) daemon for automatic clock synchronization. powerd - System power control utility for power control and energy saving. Enabling Crash Dumps bsdinstall will prompt if crash dumps should be enabled on the target system. Enabling crash dumps can be very useful in debugging issues with the system, so users are encouraged to enable crash dumps whenever possible. Select [ Yes ] to enable crash dumps, or [ No ] to proceed without crash dumps enabled.

Enabling Crash Dumps Add Users Adding at least one user during the installation allows the system to be used without being logged in as root. When logged in as root, there are essentially no limits or protection on what can be done. Logging in as a normal user is safer and more secure. Select [ Yes ] to add new users.

Add User Accounts Enter the information for the user to be added.

Enter User Information User Information Username - The name the user will enter to log in. Typically the first letter of their first name combined with their last name. Full name - The user's full name. Uid - User ID. Typically, this is left blank so the system will assign a value. Login group - The user's group. Typically left blank to accept the default. Invite user into other groups? - Additional groups to which the user will be added as a member. Login class - Typically left blank for the default. Shell - The interactive shell for this user. In the example, &man.csh.1; has been chosen. Home directory - The user's home directory. The default is usually correct. Home directory permissions - Permissions on the user's home directory. The default is usually correct. Use password-based authentication? - Typically "yes". Use an empty password? - Typically "no". Use a random password? - Typically "no". Enter password - The actual password for this user. Characters typed will not show on the screen. Enter password again - The password must be typed again for verification. Lock out the account after creation? - Typically "no". After entering everything, a summary is shown, and the system asks if it is correct. If a mistake was made during entry, enter no and try again. If everything is correct, enter yes to create the new user.

Exit User and Group Management If there are more users to add, answer the "Add another user?" question with yes. Enter no to finish adding users and continue the installation. For more information on adding users and user management, see . Final Configuration After everything has been installed and configured, a final chance is provided to modify settings.

Final Configuration Use this menu to make any changes or do any additional configuration before completing the installation. Final Configuration Options Add User - Described in . Root Password - Described in . Hostname - Described in . Network - Described in . Services - Described in . Time Zone - Described in . Handbook - Download and install the &os; Handbook (which is what you are reading now). After any final configuration is complete, select Exit to leave the installation.

Manual Configuration bsdinstall will prompt if there are any additional configuration that needs to be done before rebooting into the new system. Select [ Yes ] to exit to a shell within the new system, or [ No ] to proceed to the last step of the installation.

Complete the Installation If further configuration or special setup is needed, selecting [ Live CD ] will boot the install media into Live CD mode. When the installation is complete, select [ Reboot ] to reboot the computer and start the new &os; system. Do not forget to remove the &os; install CD, DVD, or USB memory stick, or the computer may boot from it again. &os; Booting and Shutdown &os;/&arch.i386; Booting As &os; boots, many informational messages are displayed. Most will scroll off the screen; this is normal. After the system finishes booting, a login prompt is displayed. Messages that scrolled off the screen can be reviewed by pressing Scroll-Lock to turn on the scroll-back buffer. The PgUp, PgDn, and arrow keys can be used to scroll back through the messages. Pressing Scroll-Lock again unlocks the display and returns to the normal screen. At the login: prompt, enter the username added during the installation, asample in the example. Avoid logging in as root except when necessary. The scroll-back buffer examined above is limited in size, so not all of the messages may have been visible. After logging in, most of them can be seen from the command line by typing dmesg | less at the prompt. Press q to return to the command line after viewing. Typical boot messages (version information omitted): Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (3007.77-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0x783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2> Features2=0x209<SSE3,MON,SSSE3> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> real memory = 536805376 (511 MB) avail memory = 491819008 (469 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <VBOX VBOXAPIC> ioapic0: Changing APIC ID to 1 ioapic0 <Version 1.1> irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <VBOX VBOXXSDT> on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: <ACPI CPU> on acpi0 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0 isab0: <PCI-ISA bridge> at device 1.0 on pci0 isa0: <ISA bus> on isab0 atapci0: <Intel PIIX4 UDMA33 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 1.1 on pci0 ata0: <ATA channel 0> on atapci0 ata1: <ATA channel 1> on atapci0 vgapci0: <VGA-compatible display> mem 0xe0000000-0xe0ffffff irq 18 at device 2.0 on pci0 em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.3> port 0xd010-0xd017 mem 0xf0000000-0xf001ffff irq 19 at device 3.0 on pci0 em0: Ethernet address: 08:00:27:9f:e0:92 pci0: <base peripheral> at device 4.0 (no driver attached) pcm0: <Intel ICH (82801AA)> port 0xd100-0xd1ff,0xd200-0xd23f irq 21 at device 5.0 on pci0 pcm0: <SigmaTel STAC9700/83/84 AC97 Codec> ohci0: <OHCI (generic) USB controller> mem 0xf0804000-0xf0804fff irq 22 at device 6.0 on pci0 usbus0: <OHCI (generic) USB controller> on ohci0 pci0: <bridge> at device 7.0 (no driver attached) acpi_acad0: <AC Adapter> on acpi0 atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 attimer0: <AT timer> port 0x40-0x43,0x50-0x53 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 sc0: <System console> at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: <AT realtime clock> at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 ppc0: cannot reserve I/O port range Timecounters tick every 10.000 msec pcm0: measured ac97 link rate at 485193 Hz em0: link state changed to UP usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: <Apple> at usbus0 uhub0: <Apple OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: <VBOX CD-ROM 1.0> Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: <VBOX HARDDISK 1.0> ATA-6 device ada0: 33.300MB/s transfers (UDMA2, PIO 65536bytes) ada0: 12546MB (25694208 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 Timecounter "TSC" frequency 3007772192 Hz quality 800 Root mount waiting for: usbus0 uhub0: 8 ports with 8 removable, self powered Trying to mount root from ufs:/dev/ada0p2 [rw]... Setting hostuuid: 1848d7bf-e6a4-4ed4-b782-bd3f1685d551. Setting hostid: 0xa03479b2. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0p2: clean, 2620402 free (714 frags, 327461 blocks, 0.0% fragmentation) Mounting local file systems:. vboxguest0 port 0xd020-0xd03f mem 0xf0400000-0xf07fffff,0xf0800000-0xf0803fff irq 20 at device 4.0 on pci0 vboxguest: loaded successfully Setting hostname: machine3.example.com. Starting Network: lo0 em0. lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> ether 08:00:27:9f:e0:92 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active Starting devd. Starting Network: usbus0. DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 10.0.2.2 bound to 192.168.1.142 -- renewal in 43200 seconds. add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 32-bit compatibility ldconfig path: /usr/lib32 Creating and/or trimming log files. Starting syslogd. No core dumps found. Clearing /tmp (X related). Updating motd:. Configuring syscons: blanktime. Generating public/private rsa1 key pair. Your identification has been saved in /etc/ssh/ssh_host_key. Your public key has been saved in /etc/ssh/ssh_host_key.pub. The key fingerprint is: 10:a0:f5:af:93:ae:a3:1a:b2:bb:3c:35:d9:5a:b3:f3 root@machine3.example.com The key's randomart image is: +--[RSA1 1024]----+ | o.. | | o . . | | . o | | o | | o S | | + + o | |o . + * | |o+ ..+ . | |==o..o+E | +-----------------+ Generating public/private dsa key pair. Your identification has been saved in /etc/ssh/ssh_host_dsa_key. Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub. The key fingerprint is: 7e:1c:ce:dc:8a:3a:18:13:5b:34:b5:cf:d9:d1:47:b2 root@machine3.example.com The key's randomart image is: +--[ DSA 1024]----+ | .. . .| | o . . + | | . .. . E .| | . . o o . . | | + S = . | | + . = o | | + . * . | | . . o . | | .o. . | +-----------------+ Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Thu Oct 6 19:15:31 MDT 2011 FreeBSD/amd64 (machine3.example.com) (ttyv0) login: Generating the RSA and DSA keys may take some time on slower machines. This happens only on the initial boot-up of a new installation, and only if sshd is set to start automatically. Subsequent boots will be faster. &os; does not install graphical environments by default, but many are available. See for more information. &os; Shutdown Proper shutdown of a &os; computer helps protect data and even hardware from damage. Do not just turn off the power. If the user is a member of the wheel group, become the superuser by typing su at the command line and entering the root password. Otherwise, log in as root and use shutdown -p now. The system will close down cleanly and turn itself off. The Ctrl Alt Del key combination can be used to reboot the system, but is not recommended during normal operation. Troubleshooting installation troubleshooting The following section covers basic installation troubleshooting, such as common problems people have reported. What to Do If Something Goes Wrong Due to various limitations of the PC architecture, it is impossible for probing to be 100% reliable, however, there are a few things you can do if it fails. Check the Hardware Notes document for your version of &os; to make sure your hardware is supported. If your hardware is supported and you still experience lock-ups or other problems, you will need to build a custom kernel. This will allow you to add in support for devices which are not present in the GENERIC kernel. The kernel on the boot disks is configured assuming that most hardware devices are in their factory default configuration in terms of IRQs, IO addresses, and DMA channels. If your hardware has been reconfigured, you will most likely need to edit the kernel configuration and recompile to tell &os; where to find things. It is also possible that a probe for a device not present will cause a later probe for another device that is present to fail. In that case, the probes for the conflicting driver(s) should be disabled. Some installation problems can be avoided or alleviated by updating the firmware on various hardware components, most notably the motherboard. Motherboard firmware is usually referred to as the BIOS. Most motherboard and computer manufacturers have a website for upgrades and upgrade information. Manufacturers generally advise against upgrading the motherboard BIOS unless there is a good reason for doing so, like a critical update. The upgrade process can go wrong, leaving the BIOS incomplete and the computer inoperative. Troubleshooting Questions and Answers My system hangs while probing hardware during boot, or it behaves strangely during install. &os; makes extensive use of the system ACPI service on the i386, amd64, and ia64 platforms to aid in system configuration if it is detected during boot. Unfortunately, some bugs still exist in both the ACPI driver and within system motherboards and BIOS firmware. ACPI can be disabled by setting the hint.acpi.0.disabled hint in the third stage boot loader: set hint.acpi.0.disabled="1" This is reset each time the system is booted, so it is necessary to add hint.acpi.0.disabled="1" to the file /boot/loader.conf. More information about the boot loader can be found in . Using the Live CD A live CD of &os; is available on the same CD as the main installation program. This is useful for those who are still wondering whether &os; is the right operating system for them and want to test some of the features before installing. The following points should be noted while using the live CD: To gain access to the system, authentication is required. The username is root, and the password is blank. As the system runs directly from the CD, performance will be significantly slower than that of a system installed on a hard disk. The live CD provides a command prompt and not a graphical interface. diff --git a/en_US.ISO8859-1/books/handbook/disks/chapter.xml b/en_US.ISO8859-1/books/handbook/disks/chapter.xml index 10cfa6f943..59b56fbbaa 100644 --- a/en_US.ISO8859-1/books/handbook/disks/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/disks/chapter.xml @@ -1,3989 +1,3989 @@ Storage Synopsis This chapter covers the use of disks in &os;. This includes memory-backed disks, network-attached disks, standard SCSI/IDE storage devices, and devices using the USB interface. After reading this chapter, you will know: The terminology &os; uses to describe the organization of data on a physical disk. How to add additional hard disks to a &os; system. How to configure &os; to use USB storage devices. How to set up virtual file systems, such as memory disks. How to use quotas to limit disk space usage. How to encrypt disks to secure them against attackers. How to create and burn CDs and DVDs on &os;. How to use the backup programs available under &os;. What file system snapshots are and how to use them efficiently. Before reading this chapter, you should: Know how to configure and install a new &os; kernel. Device Names The following is a list of physical storage devices supported in &os; and their associated device names. Physical Disk Naming Conventions Drive type Drive device name IDE hard drives ad or ada IDE CD-ROM drives acd or cd SATA hard drives ad or ada SATA CD-ROM drives acd or cd SCSI hard drives and USB Mass storage devices da SCSI CD-ROM drives cd Assorted non-standard CD-ROM drives mcd for Mitsumi CD-ROM and scd for Sony CD-ROM devices Floppy drives fd SCSI tape drives sa IDE tape drives ast Flash drives fla for &diskonchip; Flash device RAID drives aacd for &adaptec; AdvancedRAID, mlxd and mlyd for &mylex;, amrd for AMI &megaraid;, idad for Compaq Smart RAID, twed for &tm.3ware; RAID.

David O'Brien Originally contributed by Adding Disks disks adding This section describes how to add a new SATA disk to a machine that currently only has a single drive. First, turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturers. Reboot the system and become root. Inspect /var/run/dmesg.boot to ensure the new disk was found. In this example, the newly added SATA drive will appear as ada1. partitions gpart For this example, a single large partition will be created on the new disk. The GPT partitioning scheme will be used in preference to the older and less versatile MBR scheme. If the disk to be added is not blank, old partition information can be removed with gpart delete. See &man.gpart.8; for details. The partition scheme is created, and then a single partition is added: &prompt.root; gpart create -s GPT ada1 &prompt.root; gpart add -t freebsd-ufs ada1 Depending on use, several smaller partitions may be desired. See &man.gpart.8; for options to create partitions smaller than a whole disk. A file system is created on the new blank disk: &prompt.root; newfs -U /dev/ada1p1 An empty directory is created as a mountpoint, a location for mounting the new disk in the original disk's file system: &prompt.root; mkdir /newdisk Finally, an entry is added to /etc/fstab so the new disk will be mounted automatically at startup: /dev/ada1p1 /newdisk ufs rw 2 2 The new disk can be mounted manually, without restarting the system: &prompt.root; mount /newdisk Marc Fonvieille Contributed by USB Storage Devices USB disks Many external storage solutions, such as hard drives, USB thumbdrives, and CD/DVD burners, use the Universal Serial Bus (USB). &os; provides support for these devices. Configuration The USB mass storage devices driver, &man.umass.4;, is built into the GENERIC kernel and provides support for USB storage devices. For a custom kernel, be sure that the following lines are present in the kernel configuration file: device scbus device da device pass device uhci device ohci device ehci device usb device umass Since the &man.umass.4; driver uses the SCSI subsystem to access the USB storage devices, any USB device will be seen as a SCSI device by the system. Depending on the USB chipset on the motherboard, device uhci or device ohci is used to provide USB 1.X support. Support for USB 2.0 controllers is provided by device ehci. If the USB device is a CD or DVD burner, &man.cd.4;, must be added to the kernel via the line: device cd Since the burner is seen as a SCSI drive, the driver &man.atapicam.4; should not be used in the kernel configuration. Testing the Configuration To test the USB configuration, plug in the USB device. In the system message buffer, &man.dmesg.8;, the drive should appear as something like: umass0: USB Solid state disk, rev 1.10/1.00, addr 2 GEOM: create disk da0 dp=0xc2d74850 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <Generic Traveling Disk 1.11> Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C) The brand, device node (da0), and other details will differ according to the device. Since the USB device is seen as a SCSI one, camcontrol can be used to list the USB storage devices attached to the system: &prompt.root; camcontrol devlist <Generic Traveling Disk 1.11> at scbus0 target 0 lun 0 (da0,pass0) If the drive comes with a file system, it can be mounted. Refer to for instructions on how to format and create partitions on the USB drive. Allowing untrusted users to mount arbitrary media, by enabling vfs.usermount as described below, should not be considered safe from a security point of view. Most file systems in &os; were not built to safeguard against malicious devices. To make the device mountable as a normal user, one solution is to make all users of the device a member of the operator group using &man.pw.8;. Next, ensure that the operator group is able to read and write the device by adding these lines to /etc/devfs.rules: [localrules=5] add path 'da*' mode 0660 group operator If SCSI disks are installed in the system, change the second line as follows: add path 'da[3-9]*' mode 0660 group operator This will exclude the first three SCSI disks (da0 to da2)from belonging to the operator group. Next, enable the &man.devfs.rules.5; ruleset in /etc/rc.conf: devfs_system_ruleset="localrules" Next, instruct the running kernel to allow regular users to mount file systems. The easiest way is to add the following line to /etc/sysctl.conf: vfs.usermount=1 Since this only takes effect after the next reboot use &man.sysctl.8; to set this variable now. The final step is to create a directory where the file system is to be mounted. This directory needs to be owned by the user that is to mount the file system. One way to do that is for root to create a subdirectory owned by that user as /mnt/username. In the following example, replace username with the login name of the user and usergroup with the user's primary group: &prompt.root; mkdir /mnt/username &prompt.root; chown username:usergroup /mnt/username Suppose a USB thumbdrive is plugged in, and a device /dev/da0s1 appears. If the device is preformatted with a FAT file system, it can be mounted using: &prompt.user; mount -t msdosfs -o -m=644,-M=755 /dev/da0s1 /mnt/username Before the device can be unplugged, it must be unmounted first. After device removal, the system message buffer will show messages similar to the following: umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry GEOM: destroy disk da0 dp=0xc2d74850 umass0: detached Further Reading Beside the Adding Disks and Mounting and Unmounting File Systems sections, reading various manual pages may be also useful: &man.umass.4;, &man.camcontrol.8;, and &man.usbconfig.8; under &os; 8.X or &man.usbdevs.8; under earlier versions of &os;. Mike Meyer Contributed by Creating and Using CD Media CD-ROMs creating Introduction CD media provide a number of features that differentiate them from conventional disks. Initially, they were not writable by the user. They are designed so that they can be read continuously without delays to move the head between tracks. They are also much easier to transport between systems. CD media do have tracks, but this refers to a section of data to be read continuously and not a physical property of the disk. For example, to produce a CD on &os;, prepare the data files that are going to make up the tracks on the CD, then write the tracks to the CD. ISO 9660 file systems ISO 9660 The ISO 9660 file system was designed to deal with these differences. To overcome the original file system limits, it provides an extension mechanism that allows properly written CDs to exceed those limits while still working with systems that do not support those extensions. sysutils/cdrtools The sysutils/cdrtools port includes &man.mkisofs.8;, a program that can be used to produce a data file containing an ISO 9660 file system. It has options that support various extensions, and is described below. CD burner ATAPI Which tool to use to burn the CD depends on whether the CD burner is ATAPI or something else. ATAPI CD burners use burncd which is part of the base system. SCSI and USB CD burners should use cdrecord from the sysutils/cdrtools port. It is also possible to use cdrecord and other tools for SCSI drives on ATAPI hardware with the ATAPI/CAM module. For CD burning software with a graphical user interface, consider X-CD-Roast or K3b. These tools are available as packages or from the sysutils/xcdroast and sysutils/k3b ports. X-CD-Roast and K3b require the ATAPI/CAM module with ATAPI hardware. <application>mkisofs</application> The sysutils/cdrtools port also installs &man.mkisofs.8;, which produces an ISO 9660 file system that is an image of a directory tree in the &unix; file system name space. The simplest usage is: &prompt.root; mkisofs -o imagefile.iso /path/to/tree file systems ISO 9660 This command creates an imagefile.iso containing an ISO 9660 file system that is a copy of the tree at /path/to/tree. In the process, it maps the file names to names that fit the limitations of the standard ISO 9660 file system, and will exclude files that have names uncharacteristic of ISO file systems. file systems HFS file systems Joliet A number of options are available to overcome these restrictions. In particular, enables the Rock Ridge extensions common to &unix; systems, enables Joliet extensions used by Microsoft systems, and can be used to create HFS file systems used by &macos;. For CDs that are going to be used only on &os; systems, can be used to disable all filename restrictions. When used with , it produces a file system image that is identical to the specified &os; tree, though it may violate the ISO 9660 standard in a number of ways. CD-ROMs creating bootable The last option of general use is . This is used to specify the location of the boot image for use in producing an El Torito bootable CD. This option takes an argument which is the path to a boot image from the top of the tree being written to the CD. By default, &man.mkisofs.8; creates an ISO image in floppy disk emulation mode, and thus expects the boot image to be exactly 1200, 1440 or 2880 KB in size. Some boot loaders, like the one used by the &os; distribution disks, do not use emulation mode. In this case, should be used. So, if /tmp/myboot holds a bootable &os; system with the boot image in /tmp/myboot/boot/cdboot, this command would produce the image of an ISO 9660 file system as /tmp/bootable.iso: &prompt.root; mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot If md is configured in the kernel, the file system can be mounted as a memory disk with: &prompt.root; mdconfig -a -t vnode -f /tmp/bootable.iso -u 0 &prompt.root; mount -t cd9660 /dev/md0 /mnt One can then verify that /mnt and /tmp/myboot are identical. There are many other options available for &man.mkisofs.8; to fine-tune its behavior. Refer to &man.mkisofs.8; for details. <application>burncd</application> CD-ROMs burning For an ATAPI CD burner, burncd can be used to burn an ISO image onto a CD. burncd is part of the base system, installed as /usr/sbin/burncd. Usage is very simple, as it has few options: &prompt.root; burncd -f cddevice data imagefile.iso fixate This command will burn a copy of imagefile.iso on cddevice. The default device is /dev/acd0. See &man.burncd.8; for options to set the write speed, eject the CD after burning, and write audio data. <application>cdrecord</application> For systems without an ATAPI CD burner, cdrecord can be used to burn CDs. cdrecord is not part of the base system and must be installed from either the sysutils/cdrtools package or port. Changes to the base system can cause binary versions of this program to fail, possibly resulting in a coaster. It is recommended to either upgrade the port when the system is upgraded, or for users tracking -STABLE, to upgrade the port when a new version becomes available. While cdrecord has many options, basic usage is simple. Burning an ISO 9660 image is done with: &prompt.root; cdrecord dev=device imagefile.iso The tricky part of using cdrecord is finding the to use. To find the proper setting, use which might produce results like this: CD-ROMs burning &prompt.root; cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd7.0) Copyright (C) 1995-2004 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * This lists the appropriate value for the devices on the list. Locate the CD burner, and use the three numbers separated by commas as the value for . In this case, the CRW device is 1,5,0, so the appropriate input is . Refer to &man.cdrecord.1; for easier ways to specify this value and for information on writing audio tracks and controlling the write speed. Duplicating Audio CDs To duplicate an audio CD, extract the audio data from the CD to a series of files, then write these files to a blank CD. The process is slightly different for ATAPI and SCSI drives. SCSI Drives Use cdda2wav to extract the audio: &prompt.user; cdda2wav -vall -D2,0 -B -Owav Use cdrecord to write the .wav files: &prompt.user; cdrecord -v dev=2,0 -dao -useinfo *.wav Make sure that 2,0 is set appropriately, as described in . ATAPI Drives With the help of the ATAPI/CAM module, cdda2wav can also be used on ATAPI drives. This tool is usually a better choice for most of users, as it supports jitter correction and endianness, than the method proposed below. The ATAPI CD driver makes each track available as /dev/acddtnn, where d is the drive number, and nn is the track number written with two decimal digits, prefixed with zero as needed. So the first track on the first disk is /dev/acd0t01, the second is /dev/acd0t02, the third is /dev/acd0t03, and so on. Make sure the appropriate files exist in /dev. If the entries are missing, force the system to retaste the media: &prompt.root; dd if=/dev/acd0 of=/dev/null count=1 Extract each track using &man.dd.1;, making sure to specify a block size when extracting the files: &prompt.root; dd if=/dev/acd0t01 of=track1.cdr bs=2352 &prompt.root; dd if=/dev/acd0t02 of=track2.cdr bs=2352 ... Burn the extracted files to disk using burncd. Specify that these are audio files, and that burncd should fixate the disk when finished: &prompt.root; burncd -f /dev/acd0 audio track1.cdr track2.cdr ... fixate Duplicating Data CDs It is possible to copy a data CD to an image file that is functionally equivalent to the image file created with &man.mkisofs.8;, and then use it to duplicate any data CD. The example given here assumes that the CD-ROM device is acd0. Substitute the correct CD-ROM device. &prompt.root; dd if=/dev/acd0 of=file.iso bs=2048 Now that there is an image, it can be burned to CD as described above. Using Data CDs It is possible to mount and read the data on a standard data CD. By default, &man.mount.8; assumes that a file system is of type ufs. Running this command: &prompt.root; mount /dev/cd0 /mnt will generate an error about Incorrect super block, and will fail to mount the CD. The CD does not use the UFS file system, so attempts to mount it as such will fail. Instead, tell &man.mount.8; that the file system is of type ISO9660 by specifying to &man.mount.8;. For example, to mount the CD-ROM device, /dev/cd0, under /mnt, use: &prompt.root; mount -t cd9660 /dev/cd0 /mnt Replace /dev/cd0 with the device name for the CD device. Also, executes &man.mount.cd9660.8;, meaning the above command is equivalent to: &prompt.root; mount_cd9660 /dev/cd0 /mnt While data CD-ROMs from any vendor can be mounted this way, disks with certain ISO 9660 extensions might behave oddly. For example, Joliet disks store all filenames in two-byte Unicode characters. The &os; kernel does not speak Unicode, but the &os; CD9660 driver is able to convert Unicode characters on the fly. If some non-English characters show up as question marks, specify the local charset with . For more information, refer to &man.mount.cd9660.8;. In order to do this character conversion with the help of , the kernel requires the cd9660_iconv.ko module to be loaded. This can be done either by adding this line to loader.conf: cd9660_iconv_load="YES" and then rebooting the machine, or by directly loading the module with &man.kldload.8;. Occasionally, Device not configured will be displayed when trying to mount a CD-ROM. This usually means that the CD-ROM drive thinks that there is no disk in the tray, or that the drive is not visible on the bus. It can take a couple of seconds for a CD-ROM drive to realize that a media is present, so be patient. Sometimes, a SCSI CD-ROM may be missed because it did not have enough time to answer the bus reset. To resolve this,add the following option to the kernel configuration and rebuild the kernel. options SCSI_DELAY=15000 This tells the SCSI bus to pause 15 seconds during boot, to give the CD-ROM drive every possible chance to answer the bus reset. Burning Raw Data CDs It is possible to burn a file directly to CD, without creating an ISO 9660 file system. Some people do this for backup purposes. This command runs more quickly than burning a standard CD: &prompt.root; burncd -f /dev/acd1 -s 12 data archive.tar.gz fixate In order to retrieve the data burned to such a CD, the data must be read from the raw device node: &prompt.root; tar xzvf /dev/acd1 This type of disk can not be mounted as a normal CD-ROM and the data cannot be read under any operating system except &os;. In order to mount the CD, or to share the data with another operating system, &man.mkisofs.8; must be used as described above. Marc Fonvieille Contributed by Using the ATAPI/CAM Driver CD burner ATAPI/CAM driver This driver allows ATAPI devices, such as CD/DVD drives, to be accessed through the SCSI subsystem, and so allows the use of applications like sysutils/cdrdao or &man.cdrecord.1;. To use this driver, add the following line to /boot/loader.conf: atapicam_load="YES" then, reboot the system. Users who prefer to statically compile &man.atapicam.4; support into the kernel, should add this line to the kernel configuration file: device atapicam Ensure the following lines are still in the kernel configuration file: device ata device scbus device cd device pass Then rebuild, install the new kernel, and reboot the machine. During the boot process, the burner should show up, like so: acd0: CD-RW <MATSHITA CD-RW/DVD-ROM UJDA740> at ata1-master PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: <MATSHITA CDRW/DVD UJDA740 1.00> Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed The drive can now be accessed via the /dev/cd0 device name. For example, to mount a CD-ROM on /mnt, type the following: &prompt.root; mount -t cd9660 /dev/cd0 /mnt As root, run the following command to get the SCSI address of the burner: &prompt.root; camcontrol devlist <MATSHITA CDRW/DVD UJDA740 1.00> at scbus1 target 0 lun 0 (pass0,cd0) In this example, 1,0,0 is the SCSI address to use with &man.cdrecord.1; and other SCSI applications. For more information about ATAPI/CAM and SCSI system, refer to &man.atapicam.4; and &man.cam.4;. Marc Fonvieille Contributed by Andy Polyakov With inputs from Creating and Using DVD Media DVD burning Introduction Compared to the CD, the DVD is the next generation of optical media storage technology. The DVD can hold more data than any CD and is the standard for video publishing. Five physical recordable formats can be defined for a recordable DVD: DVD-R: This was the first DVD recordable format available. The DVD-R standard is defined by the DVD Forum. This format is write once. DVD-RW: This is the rewritable version of the DVD-R standard. A DVD-RW can be rewritten about 1000 times. DVD-RAM: This is a rewritable format which can be seen as a removable hard drive. However, this media is not compatible with most DVD-ROM drives and DVD-Video players as only a few DVD writers support the DVD-RAM format. Refer to for more information on DVD-RAM use. DVD+RW: This is a rewritable format defined by the DVD+RW Alliance. A DVD+RW can be rewritten about 1000 times. DVD+R: This format is the write once variation of the DVD+RW format. A single layer recordable DVD can hold up to 4,700,000,000 bytes which is actually 4.38 GB or 4485 MB as 1 kilobyte is 1024 bytes. A distinction must be made between the physical media and the application. For example, a DVD-Video is a specific file layout that can be written on any recordable DVD physical media such as DVD-R, DVD+R, or DVD-RW. Before choosing the type of media, ensure that both the burner and the DVD-Video player are compatible with the media under consideration. Configuration To perform DVD recording, use &man.growisofs.1;. This command is part of the sysutils/dvd+rw-tools utilities which support all DVD media types. These tools use the SCSI subsystem to access the devices, therefore ATAPI/CAM support must be loaded or statically compiled into the kernel. This support is not needed if the burner uses the USB interface. Refer to for more details on USB device configuration. DMA access must also be enabled for ATAPI devices, by adding the following line to /boot/loader.conf: hw.ata.atapi_dma="1" Before attempting to use dvd+rw-tools, consult the Hardware Compatibility Notes. For a graphical user interface, consider using sysutils/k3b which provides a user friendly interface to &man.growisofs.1; and many other burning tools. Burning Data DVDs Since &man.growisofs.1; is a front-end to mkisofs, it will invoke &man.mkisofs.8; to create the file system layout and perform the write on the DVD. This means that an image of the data does not need to be created before the burning process. To burn to a DVD+R or a DVD-R the data in /path/to/data, use the following command: &prompt.root; growisofs -dvd-compat -Z /dev/cd0 -J -R /path/to/data In this example, is passed to &man.mkisofs.8; to create an ISO 9660 file system with Joliet and Rock Ridge extensions. Refer to &man.mkisofs.8; for more details. For the initial session recording, is used for both single and multiple sessions. Replace /dev/cd0, with the name of the DVD device. Using indicates that the disk will be closed and that the recording will be unappendable. This should also provide better media compatibility with DVD-ROM drives. To burn a pre-mastered image, such as imagefile.iso, use: &prompt.root; growisofs -dvd-compat -Z /dev/cd0=imagefile.iso The write speed should be detected and automatically set according to the media and the drive being used. To force the write speed, use . Refer to &man.growisofs.1; for example usage. In order to support working files larger than 4.38GB, an UDF/ISO-9660 hybrid filesystem must be created by passing to &man.mkisofs.8; and all related programs, such as &man.growisofs.1;. This is required only when creating an ISO image file or when writing files directly to a disk. Since a disk created this way must be mounted as an UDF filesystem with &man.mount.udf.8;, it will be usable only on an UDF aware operating system. Otherwise it will look as if it contains corrupted files. To create this type of ISO file: &prompt.user; mkisofs -R -J -udf -iso-level 3 -o imagefile.iso /path/to/data To burn files directly to a disk: &prompt.root; growisofs -dvd-compat -udf -iso-level 3 -Z /dev/cd0 -J -R /path/to/data When an ISO image already contains large files, no additional options are required for &man.growisofs.1; to burn that image on a disk. Be sure to use an up-to-date version of sysutils/cdrtools, which contains &man.mkisofs.8;, as an older version may not contain large files support. If the latest version does not work, install sysutils/cdrtools-devel and read its &man.mkisofs.8;. Burning a DVD-Video DVD DVD-Video A DVD-Video is a specific file layout based on the ISO 9660 and micro-UDF (M-UDF) specifications. Since DVD-Video presents a specific data structure hierarchy, a particular program such as multimedia/dvdauthor is needed to author the DVD. If an image of the DVD-Video file system already exists, it can be burned in the same way as any other image. If dvdauthor was used to make the DVD and the result is in /path/to/video, the following command should be used to burn the DVD-Video: &prompt.root; growisofs -Z /dev/cd0 -dvd-video /path/to/video is passed to &man.mkisofs.8; to instruct it to create a DVD-Video file system layout. This option implies the &man.growisofs.1; option. Using a DVD+RW DVD DVD+RW Unlike CD-RW, a virgin DVD+RW needs to be formatted before first use. It is recommended to let &man.growisofs.1; take care of this automatically whenever appropriate. However, it is possible to use dvd+rw-format to format the DVD+RW: &prompt.root; dvd+rw-format /dev/cd0 Only perform this operation once and keep in mind that only virgin DVD+RW medias need to be formatted. Once formatted, the DVD+RW can be burned as usual. To burn a totally new file system and not just append some data onto a DVD+RW, the media does not need to be blanked first. Instead, write over the previous recording like this: &prompt.root; growisofs -Z /dev/cd0 -J -R /path/to/newdata The DVD+RW format supports appending data to a previous recording. This operation consists of merging a new session to the existing one as it is not considered to be multi-session writing. &man.growisofs.1; will grow the ISO 9660 file system present on the media. For example, to append data to a DVD+RW, use the following: &prompt.root; growisofs -M /dev/cd0 -J -R /path/to/nextdata The same &man.mkisofs.8; options used to burn the initial session should be used during next writes. Use for better media compatibility with DVD-ROM drives. When using DVD+RW, this option will not prevent the addition of data. To blank the media, use: &prompt.root; growisofs -Z /dev/cd0=/dev/zero Using a DVD-RW DVD DVD-RW A DVD-RW accepts two disc formats: incremental sequential and restricted overwrite. By default, DVD-RW discs are in sequential format. A virgin DVD-RW can be directly written without being formatted. However, a non-virgin DVD-RW in sequential format needs to be blanked before writing a new initial session. To blank a DVD-RW in sequential mode: &prompt.root; dvd+rw-format -blank=full /dev/cd0 A full blanking using will take about one hour on a 1x media. A fast blanking can be performed using , if the DVD-RW will be recorded in Disk-At-Once (DAO) mode. To burn the DVD-RW in DAO mode, use the command: &prompt.root; growisofs -use-the-force-luke=dao -Z /dev/cd0=imagefile.iso Since &man.growisofs.1; automatically attempts to detect fast blanked media and engage DAO write, should not be required. One should instead use restricted overwrite mode with any DVD-RW as this format is more flexible than the default of incremental sequential. To write data on a sequential DVD-RW, use the same instructions as for the other DVD formats: &prompt.root; growisofs -Z /dev/cd0 -J -R /path/to/data To append some data to a previous recording, use with &man.growisofs.1;. However, if data is appended on a DVD-RW in incremental sequential mode, a new session will be created on the disc and the result will be a multi-session disc. A DVD-RW in restricted overwrite format does not need to be blanked before a new initial session. Instead, overwrite the disc with . It is also possible to grow an existing ISO 9660 file system written on the disc with . The result will be a one-session DVD. To put a DVD-RW in restricted overwrite format, the following command must be used: &prompt.root; dvd+rw-format /dev/cd0 To change back to sequential format, use: &prompt.root; dvd+rw-format -blank=full /dev/cd0 Multi-Session Few DVD-ROM drives support multi-session DVDs and most of the time only read the first session. DVD+R, DVD-R and DVD-RW in sequential format can accept multiple sessions. The notion of multiple sessions does not exist for the DVD+RW and the DVD-RW restricted overwrite formats. Using the following command after an initial non-closed session on a DVD+R, DVD-R, or DVD-RW in sequential format, will add a new session to the disc: &prompt.root; growisofs -M /dev/cd0 -J -R /path/to/nextdata Using this command with a DVD+RW or a DVD-RW in restricted overwrite mode will append data while merging the new session to the existing one. The result will be a single-session disc. Use this method to add data after an initial write on these types of media. Since some space on the media is used between each session to mark the end and start of sessions, one should add sessions with a large amount of data to optimize media space. The number of sessions is limited to 154 for a DVD+R, about 2000 for a DVD-R, and 127 for a DVD+R Double Layer. For More Information To obtain more information about a DVD, use dvd+rw-mediainfo /dev/cd0 while the disc in the specified drive. More information about dvd+rw-tools can be found in &man.growisofs.1;, on the dvd+rw-tools web site, and in the cdwrite mailing list archives. When creating a problem report related to the use of dvd+rw-tools, always include the output of dvd+rw-mediainfo. Using a DVD-RAM DVD DVD-RAM Configuration DVD-RAM writers can use either a SCSI or ATAPI interface. For ATAPI devices, DMA access has to be enabled by adding the following line to /boot/loader.conf: hw.ata.atapi_dma="1" Preparing the Media A DVD-RAM can be seen as a removable hard drive. Like any other hard drive, the DVD-RAM must be formatted before it can be used. In this example, the whole disk space will be formatted with a standard UFS2 file system: &prompt.root; dd if=/dev/zero of=/dev/acd0 bs=2k count=1 &prompt.root; bsdlabel -Bw acd0 &prompt.root; newfs /dev/acd0 The DVD device, acd0, must be changed according to the configuration. Using the Media Once the DVD-RAM has been formatted, it can be mounted as a normal hard drive: &prompt.root; mount /dev/acd0 /mnt Once mounted, the DVD-RAM will be both readable and writeable. Julio Merino Original work by Martin Karlsson Rewritten by Creating and Using Floppy Disks Storing data on floppy disks is sometimes useful, for example when one does not have any other removable storage media or when one needs to transfer small amounts of data to another computer. This section explains how to use floppy disks in &os;. It covers formatting and usage of 3.5inch DOS floppies, but the concepts are similar for other floppy disk formats. Formatting Floppies The Device Floppy disks are accessed through entries in /dev, just like other devices. To access the raw floppy disk, simply use /dev/fdN. Formatting A floppy disk needs to be low-level formatted before it can be used. This is usually done by the vendor, but formatting is a good way to check media integrity. Although it is possible to force other disk sizes, 1440kB is what most floppy disks are designed for. To low-level format the floppy disk, use &man.fdformat.1;. This utility expects the device name as an argument. Make note of any error messages, as these can help determine if the disk is good or bad. Formatting Floppy Disks To format the floppy, insert a new 3.5inch floppy disk into the first floppy drive and issue: &prompt.root; /usr/sbin/fdformat -f 1440 /dev/fd0 The Disk Label After low-level formatting the disk, a disk label needs to placed on it. This disk label will be destroyed later, but it is needed by the system to determine the size of the disk and its geometry. The new disk label will take over the whole disk and will contain all the proper information about the geometry of the floppy. The geometry values for the disk label are listed in /etc/disktab. To write the disk label, use &man.bsdlabel.8;: &prompt.root; /sbin/bsdlabel -B -w /dev/fd0 fd1440 The File System The floppy is now ready to be high-level formatted. This will place a new file system on it so that &os; can read and write to the disk. Since creating the new file system destroys the disk label, the disk label needs to be recreated whenever the disk is reformatted. The floppy's file system can be either UFS or FAT. FAT is generally a better choice for floppies. To put a new file system on the floppy, issue: &prompt.root; /sbin/newfs_msdos /dev/fd0 The disk is now ready for use. Using the Floppy To use the floppy, mount it with &man.mount.msdosfs.8;. One can also use emulators/mtools from the Ports Collection. Creating and Using Data Tapes tape media Tape technology has continued to evolve but is less likely to be used in a modern system. Modern backup systems tend to use off site combined with local removable disk drive technologies. Still, &os; will support any tape drive that uses SCSI, such as LTO and older devices such as DAT. There is limited support for SATA and USB tape drives. Serial Access with &man.sa.4; tape drives &os; uses the &man.sa.4; driver, providing /dev/sa0, /dev/nsa0, and /dev/esa0. In normal use, only /dev/sa0 is needed. /dev/nsa0 is the same physical drive as /dev/sa0 but does not rewind the tape after writing a file. This allows writing more than one file to a tape. Using /dev/esa0 ejects the tape after the device is closed, if applicable. Controlling the Tape Drive with &man.mt.1; tape media mt &man.mt.1; is the &os; utility for controlling other operations of the tape drive, such as seeking through files on a tape or writing tape control marks to the tape. For example, the first three files on a tape can be preserved by skipping past them before writing a new file: &prompt.root; mt -f /dev/nsa0 fsf 3 Using &man.tar.1; to Read and Write Tape Backups An example of writing a single file to tape using &man.tar.1;: &prompt.root; tar cvf /dev/sa0 file Recovering files from a &man.tar.1; archive on tape into the current directory: &prompt.root; tar xvf /dev/sa0 Using &man.dump.8; and &man.restore.8; to Create and Restore Backups A simple backup of /usr with &man.dump.8;: &prompt.root; dump -0aL -b64 -f /dev/nsa0 /usr Interactively restoring files from a &man.dump.8; file on tape into the current directory: &prompt.root; restore -i -f /dev/nsa0 Other Tape Software Higher-level programs are available to simplify tape backup. The most popular are Amanda and Bacula. These programs aim to make backups easier and more convenient, or to automate complex backups of multiple machines. The Ports Collection contains both these and other tape utility applications. Lowell Gilbert Original work by Backup Strategies The first requirement in devising a backup plan is to make sure that all of the following problems are covered: Disk failure. Accidental file deletion. Random file corruption. Complete machine destruction, say by fire, including destruction of any on-site backups. Some systems will be best served by having each of these problems covered by a completely different technique. Except for strictly personal systems with low-value data, it is unlikely that one technique will cover all of them. Some possible techniques include: Archives of the whole system, backed up onto permanent, off-site media. This provides protection against all of the problems listed above, but is slow and inconvenient to restore from. Copies of the backups can be stored on site or online, but there will still be inconveniences in restoring files, especially for non-privileged users. Filesystem snapshots, which are really only helpful in the accidental file deletion scenario, but can be very helpful in that case, as well as quick and easy to deal with. Copies of whole file systems or disks which can be created with a periodic net/rsync of the whole machine. This is generally most useful in networks with unique requirements. For general protection against disk failure, this is usually inferior to RAID. For restoring accidentally deleted files, it can be comparable to UFS snapshots. RAID, which minimizes or avoids downtime when a disk fails at the expense of having to deal with disk failures more often, because there are more disks, albeit at a much lower urgency. Checking fingerprints of files using &man.mtree.8;. Although this is not a backup, this technique indicates when one needs to resort to backups. This is particularly important for offline backups, and should be checked periodically. It is quite easy to come up with more techniques, many of them variations on the ones listed above. Specialized requirements usually lead to specialized techniques. For example, backing up a live database usually requires a method particular to the database software as an intermediate step. The important thing is to know which dangers should be protected against, and how each will be handled. Backup Basics The major backup programs built into &os; are &man.dump.8;, &man.tar.1;, &man.cpio.1;, and &man.pax.1;. Dump and Restore backup software dump / restore dump restore The traditional &unix; backup programs are dump and restore. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the file systems. Unlike other backup software, dump backs up an entire file system on a device. It is unable to backup only part of a file system or a directory tree that spans more than one file system. dump does not write files and directories, but rather writes the raw data blocks that comprise files and directories. When used to extract data, restore stores temporary files in /tmp/ by default. When using a recovery disk with a small /tmp, set TMPDIR to a directory with more free space in order for the restore to succeed. If dump is used on the root directory, it will not back up /home, /usr or many other directories since these are typically mount points for other file systems or symbolic links into those file systems. dump has quirks that remain from its early days in Version 6 of AT&T &unix;,circa 1975. The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives. .rhosts It is also possible to backup data across the network to a tape drive attached to another computer with rdump and rrestore. Both programs rely upon &man.rcmd.3; and &man.ruserok.3; to access the remote tape drive. Therefore, the user performing the backup must be listed in .rhosts on the remote computer. The arguments to rdump and rrestore must be suitable to use on the remote computer. For example, to rdump from a &os; computer to an Exabyte tape drive connected to a host called komodo, use: &prompt.root; /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1 There are security implications to allowing .rhosts authentication, so use with caution. It is also possible to use dump and restore in a more secure fashion over ssh. Using <command>dump</command> over <application>ssh</application> &prompt.root; /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \ targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz Or, use the built-in RSH: Using <command>dump</command> over <application>ssh</application> with <envar>RSH</envar> Set &prompt.root; env RSH=/usr/bin/ssh /sbin/dump -0uan -f targetuser@targetmachine.example.com:/dev/sa0 /usr <command>tar</command> backup software tar &man.tar.1; also dates back to Version 6 of AT&T &unix;, circa 1975. tar operates in cooperation with the file system and writes files and directories to tape. tar does not support the full range of options that are available from &man.cpio.1;, but it does not require the unusual command pipeline that cpio uses. tar To tar to an Exabyte tape drive connected to a host called komodo: &prompt.root; tar cf - . | rsh komodo dd of=tape-device obs=20b When backing up over an insecure network, instead use ssh. <command>cpio</command> backup software cpio &man.cpio.1; is the original &unix; file interchange tape program for magnetic media. cpio includes options to perform byte-swapping, write a number of different archive formats, and pipe the data to other programs. This last feature makes cpio an excellent choice for installation media. cpio does not know how to walk the directory tree and a list of files must be provided through stdin. cpio Since cpio does not support backups across the network, use a pipeline and ssh to send the data to a remote tape drive. &prompt.root; for f in directory_list; do find $f >> backup.list done &prompt.root; cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device" Where directory_list is the list of directories to back up, user@host is the user/hostname combination that will be performing the backups, and backup_device is where the backups should be written to, such as /dev/nsa0). <command>pax</command> backup software pax pax POSIX IEEE &man.pax.1; is the IEEE/&posix; answer to tar and cpio. Over the years the various versions of tar and cpio have become slightly incompatible. So rather than fight it out to fully standardize them, &posix; created a new archive utility. pax attempts to read and write many of the various cpio and tar formats, plus new formats of its own. Its command set more resembles cpio than tar. <application>Amanda</application> backup software Amanda Amanda Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and a network connection to the Amanda server. A common problem at sites with a number of large disks is that the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem by using a holding disk to backup several file systems at the same time. Amanda creates archive sets: a group of tapes used over a period of time to create full backups of all the file systems listed in Amanda's configuration file. The archive set also contains nightly incremental, or differential, backups of all the file systems. Restoring a damaged file system requires the most recent full backup and the incremental backups. The configuration file provides fine grained control of backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is not installed by but is available as either a port or package. Do Nothing Do nothing is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it! If your time and data is worth little to nothing, then Do nothing is the most suitable backup program for the computer. But beware, &os; is a useful tool and over time it can be used to create a valuable collection of files. Do nothing is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by the computer. An example is the files that comprise the HTML or &postscript; version of this Handbook. These document formats have been created from XML input files. Creating backups of the HTML or &postscript; files is not necessary if the XML files are backed up regularly. Which Backup Program Is Best? LISA &man.dump.8; Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of &unix; file systems is dump. Elizabeth created file systems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by doing a backup and restore of those file systems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See torture-testing Backup and Archive Programs. Emergency Restore Procedure Before the Disaster There are four steps which should be performed in preparation for any disaster that may occur. bsdlabel First, print the bsdlabel of each disk using a command such as bsdlabel da0 | lpr. Also print a copy of /etc/fstab and all boot messages. livefs CD Second, burn a livefs CD. This CD contains support for booting into a &os; livefs rescue mode, allowing the user to perform many tasks like running &man.dump.8;, &man.restore.8;, &man.fdisk.8;, &man.bsdlabel.8;, &man.newfs.8;, &man.mount.8;, and more. The livefs CD image for &os;/&arch.i386; &rel2.current;-RELEASE is available from . Livefs CD images are not available for &os; &rel.current;-RELEASE and later. In addition to the CD-ROM installation images, flash drive installation images may be used to recover a system. The memstick image for &os;/&arch.i386; &rel.current;-RELEASE is available from . Third, create backup tapes regularly. Any changes that made after the last backup may be irretrievably lost. Write-protect the backup media. Fourth, test the livefs CD and the backups. Make notes of the procedure. Store these notes with the CD, the printouts, and the backups. These notes may prevent the inadvertent destruction of the backups while under the stress of performing an emergency recovery. For an added measure of security, store an extra livefs CD and the latest backup at a remote location, where a remote location is not the basement of the same building. A remote location should be physically separated from the computers and disk drives by a significant distance. After the Disaster First, determine if the hardware survived. Thanks to regular, off-site backups, there is no need to worry about the software. If the hardware has been damaged, the parts should be replaced before attempting to use the computer. If the hardware is okay, insert the livefs CD and boot the computer. The original install menu will be displayed on the screen. Select the correct country, then choose Fixit -- Repair mode with CD-ROM/DVD/floppy or start a shell. then select CD-ROM/DVD -- Use the live filesystem CD-ROM/DVD. restore and the other needed programs are located in /mnt2/rescue. Recover each file system separately. mount root partition bsdlabel newfs Try to mount the root partition of the first disk using mount /dev/da0a /mnt. If the bsdlabel was damaged, use bsdlabel to re-partition and label the disk to match the label that was printed and saved. Use newfs to re-create the file systems. Re-mount the root partition of the disk read-write using mount -u -o rw /mnt. Use the backups to recover the data for this file system. Unmount the file system with umount /mnt. Repeat for each file system that was damaged. Once the system is running, backup the data onto new media as whatever caused the crash or data loss may strike again. Another hour spent now may save further distress later. Marc Fonvieille Reorganized and enhanced by Network, Memory, and File-Backed File Systems virtual disks disks virtual In addition to physical disks such as floppies, CDs, and hard drives, &os; also supports virtual disks. NFS Coda disks memory These include network file systems such as the Network File System and Coda, memory-based file systems, and file-backed file systems. According to the &os; version, the tools used for the creation and use of file-backed and memory-based file systems differ. Use &man.devfs.5; to allocate device nodes transparently for the user. File-Backed File System disks file-backed &man.mdconfig.8; is used to configure and enable memory disks, &man.md.4;, under &os;. To use &man.mdconfig.8;, &man.md.4; must be first loaded. When using a custom kernel configuration file, ensure it includes this line: device md &man.mdconfig.8; supports several types of memory backed virtual disks: memory disks allocated with &man.malloc.9; and memory disks using a file or swap space as backing. One possible use is the mounting of CD images. To mount an existing file system image: Using <command>mdconfig</command> to Mount an Existing File System Image &prompt.root; mdconfig -a -t vnode -f diskimage -u 0 &prompt.root; mount /dev/md0 /mnt To create a new file system image with &man.mdconfig.8;: Creating a New File-Backed Disk with <command>mdconfig</command> &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdconfig -a -t vnode -f newimage -u 0 &prompt.root; bsdlabel -w md0 auto &prompt.root; newfs md0a /dev/md0a: 5.0MB (10224 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.25MB, 80 blks, 192 inodes. super-block backups (for fsck -b #) at: 160, 2720, 5280, 7840 &prompt.root; mount /dev/md0a /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0a 4710 4 4330 0% /mnt If unit number is not specified with , &man.mdconfig.8; uses the &man.md.4; automatic allocation to select an unused device. The name of the allocated unit will be output to stdout, such as md4. Refer to &man.mdconfig.8; for more details about. While &man.mdconfig.8; is useful, it takes several command lines to create a file-backed file system. &os; also comes with &man.mdmfs.8; which automatically configures a &man.md.4; disk using &man.mdconfig.8;, puts a UFS file system on it using &man.newfs.8;, and mounts it using &man.mount.8;. For example, to create and mount the same file system image as above, type the following: Configure and Mount a File-Backed Disk with <command>mdmfs</command> &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; mdmfs -F newimage -s 5m md0 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0 4718 4 4338 0% /mnt When is used without a unit number, &man.mdmfs.8; uses the &man.md.4; auto-unit feature to automatically select an unused device. For more details about &man.mdmfs.8;, refer to its manual page. Memory-Based File System disks memory file system For a memory-based file system, swap backing should normally be used. This does not mean that the memory disk will be swapped out to disk by default, but rather that the memory disk will be allocated from a memory pool which can be swapped out to disk if needed. It is also possible to create memory-based disks which are &man.malloc.9; backed, but using large malloc backed memory disks can result in a system panic if the kernel runs out of memory. Creating a New Memory-Based Disk with <command>mdconfig</command> &prompt.root; mdconfig -a -t swap -s 5m -u 1 &prompt.root; newfs -U md1 /dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.27MB, 81 blks, 192 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 2752, 5344, 7936 &prompt.root; mount /dev/md1 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1 4718 4 4338 0% /mnt Creating a New Memory-Based Disk with <command>mdmfs</command> &prompt.root; mdmfs -s 5m md2 /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md2 4846 2 4458 0% /mnt Detaching a Memory Disk from the System disks detaching a memory disk When a memory-based or file-based file system is no longer in use, its resources should be released back to the system. First, unmount the file system, then use &man.mdconfig.8; to detach the disk from the system and release the resources. For example, to detach and free all resources used by /dev/md4: &prompt.root; mdconfig -d -u 4 It is possible to list information about configured &man.md.4; devices by running mdconfig -l. Tom Rhodes Contributed by File System Snapshots file systems snapshots &os; offers a feature in conjunction with Soft Updates: file system snapshots. UFS snapshots allow a user to create images of specified file systems, and treat them as a file. Snapshot files must be created in the file system that the action is performed on, and a user may create no more than 20 snapshots per file system. Active snapshots are recorded in the superblock so they are persistent across unmount and remount operations along with system reboots. When a snapshot is no longer required, it can be removed using &man.rm.1;. While snapshots may be removed in any order, all the used space may not be acquired because another snapshot will possibly claim some of the released blocks. The un-alterable file flag is set by &man.mksnap.ffs.8; after initial creation of a snapshot file. &man.unlink.1; makes an exception for snapshot files since it allows them to be removed. Snapshots are created using &man.mount.8;. To place a snapshot of /var in the file /var/snapshot/snap, use the following command: &prompt.root; mount -u -o snapshot /var/snapshot/snap /var Alternatively, use &man.mksnap.ffs.8; to create the snapshot: &prompt.root; mksnap_ffs /var /var/snapshot/snap One can find snapshot files on a file system, such as /var, using &man.find.1;: &prompt.root; find /var -flags snapshot Once a snapshot has been created, it has several uses: Some administrators will use a snapshot file for backup purposes, because the snapshot can be transferred to CDs or tape. The file system integrity checker, &man.fsck.8;, may be run on the snapshot. Assuming that the file system was clean when it was mounted, this should always provide a clean and unchanging result. Running &man.dump.8; on the snapshot will produce a dump file that is consistent with the file system and the timestamp of the snapshot. &man.dump.8; can also take a snapshot, create a dump image, and then remove the snapshot in one command by using . The snapshot can be mounted as a frozen image of the file system. To &man.mount.8; the snapshot /var/snapshot/snap run: &prompt.root; mdconfig -a -t vnode -f /var/snapshot/snap -u 4 &prompt.root; mount -r /dev/md4 /mnt The frozen /var is now available through /mnt. Everything will initially be in the same state it was during the snapshot creation time. The only exception is that any earlier snapshots will appear as zero length files. To unmount the snapshot, use: &prompt.root; umount /mnt &prompt.root; mdconfig -d -u 4 For more information about and file system snapshots, including technical papers, visit Marshall Kirk McKusick's website at . File System Quotas accounting disk space disk quotas Quotas are an optional feature of the operating system that can be used to limit the amount of disk space or the number of files a user or members of a group may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This prevents one user or group of users from consuming all of the available disk space. Configuring the System to Enable Disk Quotas Before using disk quotas, quota support must be added to the kernel by adding the following line to the kernel configuration file: options QUOTA The GENERIC kernel does not have this enabled by default, so a custom kernel must be compiled in order to use disk quotas. Refer to for more information on kernel configuration. Next, enable disk quotas in /etc/rc.conf: quota_enable="YES" disk quotas checking For finer control over quota startup, an additional configuration variable is available. Normally on bootup, the quota integrity of each file system is checked by &man.quotacheck.8;. This program insures that the data in the quota database properly reflects the data on the file system. This is a time consuming process that will significantly affect the time the system takes to boot. To skip this step, add this variable to /etc/rc.conf: check_quotas="NO" Finally, edit /etc/fstab to enable disk quotas on a per-file system basis. This is when user or group quotas can be enabled on the file systems. To enable per-user quotas on a file system, add to the options field in the /etc/fstab entry for the file system to enable quotas on. For example: /dev/da1s2g /home ufs rw,userquota 1 2 To enable group quotas, instead use . To enable both user and group quotas, change the entry as follows: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 By default, the quota files are stored in the root directory of the file system as quota.user and quota.group. Refer to &man.fstab.5; for more information. Even though an alternate location for the quota files can be specified, this is not recommended because the various quota utilities do not seem to handle this properly. Once the configuration is complete, reboot the system with the new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas enabled in /etc/fstab. There is no need to manually create any zero length quota files. In the normal course of operations, there should be no need to manually run &man.quotacheck.8;, &man.quotaon.8;, or &man.quotaoff.8;. However, one should read their manual pages to be familiar with their operation. Setting Quota Limits disk quotas limits Once the system has been configured to enable quotas, verify they really are enabled by running: &prompt.root; quota -v There should be a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. The system is now ready to be assigned quota limits with &man.edquota.8;. Several options are available to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. Allocations can be limited based on disk space (block quotas), number of files (inode quotas), or a combination of both. Each limits is further broken down into two categories: hard and soft limits. hard limit A hard limit may not be exceeded. Once a user reaches a hard limit, no further allocations can be made on that file system by that user. For example, if the user has a hard limit of 500 kbytes on a file system and is currently using 490 kbytes, the user can only allocate an additional 10 kbytes. Attempting to allocate an additional 11 kbytes will fail. soft limit Soft limits can be exceeded for a limited amount of time, known as the grace period, which is one week by default. If a user stays over their limit longer than the grace period, the soft limit turns into a hard limit and no further allocations are allowed. When the user drops back below the soft limit, the grace period is reset. The following is an example output from &man.edquota.8;. When &man.edquota.8; is invoked, the editor specified by EDITOR is opened in order to edit the quota limits. The default editor is set to vi. &prompt.root; edquota -u test Quotas for user test: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: kbytes in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) There are normally two lines for each file system that has quotas enabled. One line represents the block limits and the other represents the inode limits. Change the value to modify the quota limit. For example, to raise this user's block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: /usr: kbytes in use: 65, limits (soft = 50, hard = 75) to: /usr: kbytes in use: 65, limits (soft = 500, hard = 600) The new quota limits take affect upon exiting the editor. Sometimes it is desirable to set quota limits on a range of UIDs. This can be done by passing to &man.edquota.8;. First, assign the desired quota limit to a user, then run edquota -p protouser startuid-enduid. For example, if test has the desired quota limits, the following command will duplicate those quota limits for UIDs 10,000 through 19,999: &prompt.root; edquota -p test 10000-19999 For more information, refer to &man.edquota.8;. Checking Quota Limits and Disk Usage disk quotas checking Either &man.quota.1; or &man.repquota.8; can be used to check quota limits and disk usage. To check individual user or group quotas and disk usage, use &man.quota.1;. A user may only examine their own quota and the quota of a group they are a member of. Only the superuser may view all user and group quotas. To get a summary of all quotas and disk usage for file systems with quotas enabled, use &man.repquota.8;. The following is sample output from quota -v for a user that has quota limits on two file systems. Disk quotas for user test (uid 1002): Filesystem usage quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 grace period In this example, the user is currently 15 kbytes over the soft limit of 50 kbytes on /usr and has 5 days of grace period left. The asterisk * indicates that the user is currently over the quota limit. Normally, file systems that the user is not using any disk space on will not show in the output of &man.quota.1;, even if the user has a quota limit assigned for that file system. Use to display those file systems, such as /usr/var in the above example. Quotas over NFS NFS Quotas are enforced by the quota subsystem on the NFS server. The &man.rpc.rquotad.8; daemon makes quota information available to &man.quota.1; on NFS clients, allowing users on those machines to see their quota statistics. Enable rpc.rquotad in /etc/inetd.conf like so: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Now restart inetd: &prompt.root; service inetd restart Lucky Green Contributed by

shamrock@cypherpunks.to

Encrypting Disk Partitions disks encrypting &os; offers excellent online protections against unauthorized data access. File permissions and Mandatory Access Control (MAC) help prevent unauthorized users from accessing data while the operating system is active and the computer is powered up. However, the permissions enforced by the operating system are irrelevant if an attacker has physical access to a computer and can move the computer's hard drive to another system to copy and analyze the data. Regardless of how an attacker may have come into possession of a hard drive or powered-down computer, both the GEOM Based Disk Encryption (gbde) and geli cryptographic subsystems in &os; are able to protect the data on the computer's file systems against even highly-motivated attackers with significant resources. Unlike cumbersome encryption methods that encrypt only individual files, gbde and geli transparently encrypt entire file systems. No cleartext ever touches the hard drive's platter. Disk Encryption with <application>gbde</application> Configuring gbde requires superuser privileges. &prompt.user; su - Password: If using a custom kernel configuration file, ensure it contains this line: options GEOM_BDE If the kernel already contains this support, use kldload to load &man.gbde.4;: &prompt.root; kldload geom_bde Preparing the Encrypted Hard Drive The following example demonstrates adding a new hard drive to a system that will hold a single encrypted partition. This partition will be mounted as /private. gbde can also be used to encrypt /home and /var/mail, but this requires more complex instructions which exceed the scope of this introduction. Add the New Hard Drive Install the new drive to the system as explained in . For the purposes of this example, a new hard drive partition has been added as /dev/ad4s1c and /dev/ad0s1* represents the existing standard &os; partitions. &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 Create a Directory to Hold <command>gbde</command> Lock Files &prompt.root; mkdir /etc/gbde The gbde lock file contains information that gbde requires to access encrypted partitions. Without access to the lock file, gbde will not be able to decrypt the data contained in the encrypted partition without significant manual intervention which is not supported by the software. Each encrypted partition uses a separate lock file. Initialize the <command>gbde</command> Partition A gbde partition must be initialized before it can be used. This initialization needs to be performed only once: &prompt.root; gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c.lock &man.gbde.8; will open the default editor, in order to set various configuration options in a template. For use with UFS1 or UFS2, set the sector_size to 2048: # $FreeBSD: src/sbin/gbde/template.txt,v 1.1.36.1 2009/08/03 08:13:06 kensmith Exp $ # # Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 2048 [...] &man.gbde.8; will ask the user twice to type the passphrase used to secure the data. The passphrase must be the same both times. The ability of gbde to protect data depends entirely on the quality of the passphrase. For tips on how to select a secure passphrase that is easy to remember, see the Diceware Passphrase website. gbde initcreates a lock file for the gbde partition. In this example, it is stored as /etc/gbde/ad4s1c.lock. gbde lock files must end in .lock in order to be correctly detected by the /etc/rc.d/gbde start up script. gbde lock files must be backed up together with the contents of any encrypted partitions. While deleting a lock file alone cannot prevent a determined attacker from decrypting a gbde partition, without the lock file, the legitimate owner will be unable to access the data on the encrypted partition without a significant amount of work that is totally unsupported by &man.gbde.8;. Attach the Encrypted Partition to the Kernel &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock This command will prompt to input the passphrase that was selected during the initialization of the encrypted partition. The new encrypted device will appear in /dev as /dev/device_name.bde: &prompt.root; ls /dev/ad* /dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1 /dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c /dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde Create a File System on the Encrypted Device Once the encrypted device has been attached to the kernel, a file system can be created on the device using &man.newfs.8;. This example creates a UFS2 file system with soft updates enabled. &prompt.root; newfs -U /dev/ad4s1c.bde &man.newfs.8; must be performed on an attached gbde partition which is identified by a *.bde extension to the device name. Mount the Encrypted Partition Create a mount point for the encrypted file system: &prompt.root; mkdir /private Mount the encrypted file system: &prompt.root; mount /dev/ad4s1c.bde /private Verify That the Encrypted File System is Available The encrypted file system should now be visible to &man.df.1; and be available for use. &prompt.user; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 1037M 72M 883M 8% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 8.1G 55K 7.5G 0% /home /dev/ad0s1e 1037M 1.1M 953M 0% /tmp /dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr /dev/ad4s1c.bde 150G 4.1K 138G 0% /private Mounting Existing Encrypted File Systems After each boot, any encrypted file systems must be re-attached to the kernel, checked for errors, and mounted, before the file systems can be used. The required commands must be executed as root. Attach the <command>gbde</command> Partition to the Kernel &prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock This command will prompt for the passphrase that was selected during initialization of the encrypted gbde partition. Check the File System for Errors Since encrypted file systems cannot yet be listed in /etc/fstab for automatic mounting, the file systems must be checked for errors by running &man.fsck.8; manually before mounting: &prompt.root; fsck -p -t ffs /dev/ad4s1c.bde Mount the Encrypted File System &prompt.root; mount /dev/ad4s1c.bde /private The encrypted file system is now available for use. Automatically Mounting Encrypted Partitions It is possible to create a script to automatically attach, check, and mount an encrypted partition, but for security reasons the script should not contain the &man.gbde.8; password. Instead, it is recommended that such scripts be run manually while providing the password via the console or &man.ssh.1;. As an alternative, an rc.d script is provided. Arguments for this script can be passed via &man.rc.conf.5;: gbde_autoattach_all="YES" gbde_devices="ad4s1c" gbde_lockdir="/etc/gbde" This requires that the gbde passphrase be entered at boot time. After typing the correct passphrase, the gbde encrypted partition will be mounted automatically. This can be useful when using gbde on laptops. Cryptographic Protections Employed by <command>gbde</command> &man.gbde.8; encrypts the sector payload using 128-bit AES in CBC mode. Each sector on the disk is encrypted with a different AES key. For more information on the cryptographic design, including how the sector keys are derived from the user-supplied passphrase, refer to &man.gbde.4;. Compatibility Issues &man.sysinstall.8; is incompatible with gbde-encrypted devices. All *.bde devices must be detached from the kernel before starting &man.sysinstall.8; or it will crash during its initial probing for devices. To detach the encrypted device used in the example, use the following command: &prompt.root; gbde detach /dev/ad4s1c Daniel Gerzo Contributed by Disk Encryption with <command>geli</command> An alternative cryptographic GEOM class is available through &man.geli.8;. geli differs from gbde; offers different features, and uses a different scheme for doing cryptographic work. &man.geli.8; provides the following features: Utilizes the &man.crypto.9; framework and, when cryptographic hardware is available, geli uses it automatically. Supports multiple cryptographic algorithms such as AES, Blowfish, and 3DES. Allows the root partition to be encrypted. The passphrase used to access the encrypted root partition will be requested during system boot. Allows the use of two independent keys such as a key and a company key. geli is fast as it performs simple sector-to-sector encryption. Allows backup and restore of master keys. If a user destroys their keys, it is still possible to get access to the data by restoring keys from the backup. Allows a disk to attach with a random, one-time key which is useful for swap partitions and temporary file systems. More geli features can be found in &man.geli.8;. This section describes how to enable support for geli in the &os; kernel and explains how to create and use a geli encryption provider. Superuser privileges are required since modifications to the kernel are necessary. Adding <command>geli</command> Support to the Kernel For a custom kernel, ensure the kernel configuration file contains these lines: options GEOM_ELI device crypto Alternatively, the geli module can be loaded at boot time by adding the following line to /boot/loader.conf: geom_eli_load="YES" &man.geli.8; should now be supported by the kernel. Generating the Master Key The following example describes how to generate a key file which will be used as part of the master key for the encrypted provider mounted under /private. The key file will provide some random data used to encrypt the master key. The master key will also be protected by a passphrase. The provider's sector size will be 4kB. The example will describe how to attach to the geli provider, create a file system on it, mount it, work with it, and finally, how to detach it. It is recommended to use a bigger sector size, such as 4kB, for better performance. The master key will be protected with a passphrase and the data source for the key file will be /dev/random. The sector size of the provider /dev/da2.eli will be 4kB. &prompt.root; dd if=/dev/random of=/root/da2.key bs=64 count=1 &prompt.root; geli init -s 4096 -K /root/da2.key /dev/da2 Enter new passphrase: Reenter new passphrase: It is not mandatory to use both a passphrase and a key file as either method of securing the master key can be used in isolation. If the key file is given as -, standard input will be used. This example shows how more than one key file can be used: &prompt.root; cat keyfile1 keyfile2 keyfile3 | geli init -K - /dev/da2 Attaching the Provider with the Generated Key &prompt.root; geli attach -k /root/da2.key /dev/da2 Enter passphrase: The new plaintext device will be named /dev/da2.eli. &prompt.root; ls /dev/da2* /dev/da2 /dev/da2.eli Creating the New File System &prompt.root; dd if=/dev/random of=/dev/da2.eli bs=1m &prompt.root; newfs /dev/da2.eli &prompt.root; mount /dev/da2.eli /private The encrypted file system should now be visible to &man.df.1; and be available for use: &prompt.root; df -H Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 248M 89M 139M 38% / /devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1f 7.7G 2.3G 4.9G 32% /usr /dev/ad0s1d 989M 1.5M 909M 0% /tmp /dev/ad0s1e 3.9G 1.3G 2.3G 35% /var /dev/da2.eli 150G 4.1K 138G 0% /private Unmounting and Detaching the Provider Once the work on the encrypted partition is done, and the /private partition is no longer needed, it is prudent to consider unmounting and detaching the geli encrypted partition from the kernel: &prompt.root; umount /private &prompt.root; geli detach da2.eli More information about the use of &man.geli.8; can be found in its manual page. Using the <filename>geli</filename> <filename>rc.d</filename> Script geli comes with a rc.d script which can be used to simplify the usage of geli. An example of configuring geli through &man.rc.conf.5; follows: geli_devices="da2" geli_da2_flags="-p -k /root/da2.key" This configures /dev/da2 as a geli provider of which the master key file is located in /root/da2.key. geli will not use a passphrase when attaching to the provider if was given during the geli init phase. The system will detach the geli provider from the kernel before the system shuts down. More information about configuring rc.d is provided in the rc.d section of the Handbook. Christian Brüffer Written by Encrypting Swap Space swap encrypting Like the encryption of disk partitions, encryption of swap space is used to protect sensitive information. Consider an application that deals with passwords. As long as these passwords stay in physical memory, these passwords will not be written to disk and be cleared after a reboot. If &os; starts swapping out memory pages to free space for other applications, the passwords may be written to the disk platters unencrypted. Encrypting swap space can be a solution for this scenario. The &man.gbde.8; or &man.geli.8; encryption systems may be used for swap encryption. Both systems use the encswap rc.d script. For the remainder of this section, ad0s1b will be the swap partition. Swap partitions are not encrypted by default and should be cleared of any sensitive data before continuing. To overwrite the current swap parition with random garbage, execute the following command: &prompt.root; dd if=/dev/random of=/dev/ad0s1b bs=1m Swap Encryption with &man.gbde.8; The .bde suffix should be added to the device in the respective /etc/fstab swap line: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.bde none swap sw 0 0 Swap Encryption with &man.geli.8; The procedure for instead using &man.geli.8; for swap encryption is similar to that of using &man.gbde.8;. The .eli suffix should be added to the device in the respective /etc/fstab swap line: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b.eli none swap sw 0 0 &man.geli.8; uses the AES algorithm with a key length of 128 bit by default. These defaults can be altered by using geli_swap_flags in /etc/rc.conf. The following line tells the encswap rc.d script to create &man.geli.8; swap partitions using the Blowfish algorithm with a key length of 128 bits and a sectorsize of 4 kilobytes, and sets detach on last close: geli_swap_flags="-e blowfish -l 128 -s 4096 -d" Refer to the description of onetime in &man.geli.8; for a list of possible options. Encrypted Swap Verification Once the system has rebooted, proper operation of the encrypted swap can be verified using swapinfo. If &man.gbde.8; is being used: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.bde 542720 0 542720 0% If &man.geli.8; is being used: &prompt.user; swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b.eli 542720 0 542720 0% Daniel Gerzo Contributed by Freddie Cash With inputs from Pawel Jakub Dawidek Michael W. Lucas Viktor Petersson Highly Available Storage (HAST) HAST high availability Synopsis High availability is one of the main requirements in serious business applications and highly-available storage is a key component in such environments. Highly Available STorage, or HASTHighly Available STorage, was developed by - &a.pjd; as a framework which allows transparent storage of the + &a.pjd.email; as a framework which allows transparent storage of the same data across several physically separated machines connected by a TCP/IP network. HAST can be understood as a network-based RAID1 (mirror), and is similar to the DRBD® storage system known from the GNU/&linux; platform. In combination with other high-availability features of &os; like CARP, HAST makes it possible to build a highly-available storage cluster that is resistant to hardware failures. After reading this section, you will know: What HAST is, how it works and which features it provides. How to set up and use HAST on &os;. How to integrate CARP and &man.devd.8; to build a robust storage system. Before reading this section, you should: Understand &unix; and &os; basics. Know how to configure network interfaces and other core &os; subsystems. Have a good understanding of &os; networking. The HAST project was sponsored by The &os; Foundation with support from OMCnet Internet Service GmbH and TransIP BV. HAST Features The main features of the HAST system are: Can be used to mask I/O errors on local hard drives. File system agnostic as it works with any file system supported by &os;. Efficient and quick resynchronization, synchronizing only blocks that were modified during the downtime of a node. Can be used in an already deployed environment to add additional redundancy. Together with CARP, Heartbeat, or other tools, it can be used to build a robust and durable storage system. HAST Operation As HAST provides a synchronous block-level replication of any storage media to several machines, it requires at least two physical machines: the primary, also known as the master node, and the secondary or slave node. These two machines together are referred to as a cluster. HAST is currently limited to two cluster nodes in total. Since HAST works in a primary-secondary configuration, it allows only one of the cluster nodes to be active at any given time. The primary node, also called active, is the one which will handle all the I/O requests to HAST-managed devices. The secondary node is automatically synchronized from the primary node. The physical components of the HAST system are: local disk on primary node, and disk on remote, secondary node. HAST operates synchronously on a block level, making it transparent to file systems and applications. HAST provides regular GEOM providers in /dev/hast/ for use by other tools or applications, thus there is no difference between using HAST-provided devices and raw disks or partitions. Each write, delete, or flush operation is sent to the local disk and to the remote disk over TCP/IP. Each read operation is served from the local disk, unless the local disk is not up-to-date or an I/O error occurs. In such case, the read operation is sent to the secondary node. Synchronization and Replication Modes HAST tries to provide fast failure recovery. For this reason, it is very important to reduce synchronization time after a node's outage. To provide fast synchronization, HAST manages an on-disk bitmap of dirty extents and only synchronizes those during a regular synchronization, with an exception of the initial sync. There are many ways to handle synchronization. HAST implements several replication modes to handle different synchronization methods: memsync: report write operation as completed when the local write operation is finished and when the remote node acknowledges data arrival, but before actually storing the data. The data on the remote node will be stored directly after sending the acknowledgement. This mode is intended to reduce latency, but still provides very good reliability. fullsync: report write operation as completed when local write completes and when remote write completes. This is the safest and the slowest replication mode. This mode is the default. async: report write operation as completed when local write completes. This is the fastest and the most dangerous replication mode. It should be used when replicating to a distant node where latency is too high for other modes. HAST Configuration HAST requires GEOM_GATE support which is not present in the default GENERIC kernel. However, the geom_gate.ko loadable module is available in the default &os; installation. Alternatively, to build GEOM_GATE support into the kernel statically, add this line to the custom kernel configuration file: options GEOM_GATE The HAST framework consists of several parts from the operating system's point of view: the &man.hastd.8; daemon responsible for data synchronization, the &man.hastctl.8; userland management utility, and the &man.hast.conf.5; configuration file. The following example describes how to configure two nodes in master-slave / primary-secondary operation using HAST to replicate the data between the two. The nodes will be called hasta with an IP address of 172.16.0.1 and hastb with an IP of address 172.16.0.2. Both nodes will have a dedicated hard drive /dev/ad6 of the same size for HAST operation. The HAST pool, sometimes also referred to as a resource or the GEOM provider in /dev/hast/, will be called test. Configuration of HAST is done using /etc/hast.conf. This file should be the same on both nodes. The simplest configuration possible is: resource test { on hasta { local /dev/ad6 remote 172.16.0.2 } on hastb { local /dev/ad6 remote 172.16.0.1 } } For more advanced configuration, refer to &man.hast.conf.5;. It is also possible to use host names in the remote statements. In such a case, make sure that these hosts are resolvable and are defined in /etc/hosts or in the local DNS. Now that the configuration exists on both nodes, the HAST pool can be created. Run these commands on both nodes to place the initial metadata onto the local disk and to start &man.hastd.8;: &prompt.root; hastctl create test &prompt.root; service hastd onestart It is not possible to use GEOM providers with an existing file system or to convert an existing storage to a HAST-managed pool. This procedure needs to store some metadata on the provider and there will not be enough required space available on an existing provider. A HAST node's primary or secondary role is selected by an administrator, or software like Heartbeat, using &man.hastctl.8;. On the primary node, hasta, issue this command: &prompt.root; hastctl role primary test Similarly, run this command on the secondary node, hastb: &prompt.root; hastctl role secondary test When the nodes are unable to communicate with each other, and both are configured as primary nodes, the condition is called split-brain. To troubleshoot this situation, follow the steps described in . Verify the result by running &man.hastctl.8; on each node: &prompt.root; hastctl status test The important text is the status line, which should say complete on each of the nodes. If it says degraded, something went wrong. At this point, the synchronization between the nodes has already started. The synchronization completes when hastctl status reports 0 bytes of dirty extents. The next step is to create a filesystem on the /dev/hast/test GEOM provider and mount it. This must be done on the primary node, as /dev/hast/test appears only on the primary node. Creating the filesystem can take a few minutes, depending on the size of the hard drive: &prompt.root; newfs -U /dev/hast/test &prompt.root; mkdir /hast/test &prompt.root; mount /dev/hast/test /hast/test Once the HAST framework is configured properly, the final step is to make sure that HAST is started automatically during system boot. Add this line to /etc/rc.conf: hastd_enable="YES" Failover Configuration The goal of this example is to build a robust storage system which is resistant to the failure of any given node. The scenario is that a primary node of the cluster fails. If this happens, the secondary node is there to take over seamlessly, check and mount the file system, and continue to work without missing a single bit of data. To accomplish this task, another &os; feature, CARP, provides for automatic failover on the IP layer. CARP (Common Address Redundancy Protocol) allows multiple hosts on the same network segment to share an IP address. Set up CARP on both nodes of the cluster according to the documentation available in . After setup, each node will have its own carp0 interface with a shared IP address of 172.16.0.254. The primary HAST node of the cluster must be the master CARP node. The HAST pool created in the previous section is now ready to be exported to the other hosts on the network. This can be accomplished by exporting it through NFS or Samba, using the shared IP address 172.16.0.254. The only problem which remains unresolved is an automatic failover should the primary node fail. In the event of CARP interfaces going up or down, the &os; operating system generates a &man.devd.8; event, making it possible to watch for state changes on the CARP interfaces. A state change on the CARP interface is an indication that one of the nodes failed or came back online. These state change events make it possible to run a script which will automatically handle the HAST failover. To be able to catch state changes on the CARP interfaces, add this configuration to /etc/devd.conf on each node: notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_UP"; action "/usr/local/sbin/carp-hast-switch master"; }; notify 30 { match "system" "IFNET"; match "subsystem" "carp0"; match "type" "LINK_DOWN"; action "/usr/local/sbin/carp-hast-switch slave"; }; Restart &man.devd.8; on both nodes to put the new configuration into effect: &prompt.root; service devd restart When the carp0 interface state changes by going up or down , the system generates a notification, allowing the &man.devd.8; subsystem to run an arbitrary script, in this case /usr/local/sbin/carp-hast-switch. This script handles the automatic failover. For further clarification about the above &man.devd.8; configuration, refer to &man.devd.conf.5;. An example of such a script could be: #!/bin/sh # Original script by Freddie Cash <fjwcash@gmail.com> # Modified by Michael W. Lucas <mwlucas@BlackHelicopters.org> # and Viktor Petersson <vpetersson@wireload.net> # The names of the HAST resources, as listed in /etc/hast.conf resources="test" # delay in mounting HAST resource after becoming master # make your best guess delay=3 # logging log="local0.debug" name="carp-hast" # end of user configurable stuff case "$1" in master) logger -p $log -t $name "Switching to primary provider for ${resources}." sleep ${delay} # Wait for any "hastd secondary" processes to stop for disk in ${resources}; do while $( pgrep -lf "hastd: ${disk} $secondary$" > /dev/null 2>&1 ); do sleep 1 done # Switch role for each disk hastctl role primary ${disk} if [ $? -ne 0 ]; then logger -p $log -t $name "Unable to change role to primary for resource ${disk}." exit 1 fi done # Wait for the /dev/hast/* devices to appear for disk in ${resources}; do for I in $( jot 60 ); do [ -c "/dev/hast/${disk}" ] && break sleep 0.5 done if [ ! -c "/dev/hast/${disk}" ]; then logger -p $log -t $name "GEOM provider /dev/hast/${disk} did not appear." exit 1 fi done logger -p $log -t $name "Role for HAST resources ${resources} switched to primary." logger -p $log -t $name "Mounting disks." for disk in ${resources}; do mkdir -p /hast/${disk} fsck -p -y -t ufs /dev/hast/${disk} mount /dev/hast/${disk} /hast/${disk} done ;; slave) logger -p $log -t $name "Switching to secondary provider for ${resources}." # Switch roles for the HAST resources for disk in ${resources}; do if ! mount | grep -q "^/dev/hast/${disk} on " then else umount -f /hast/${disk} fi sleep $delay hastctl role secondary ${disk} 2>&1 if [ $? -ne 0 ]; then logger -p $log -t $name "Unable to switch role to secondary for resource ${disk}." exit 1 fi logger -p $log -t $name "Role switched to secondary for resource ${disk}." done ;; esac In a nutshell, the script takes these actions when a node becomes master / primary: Promotes the HAST pools to primary on a given node. Checks the file system under the HAST pool. Mounts the pools at an appropriate place. When a node becomes backup / secondary: Unmounts the HAST pools. Degrades the HAST pools to secondary. Keep in mind that this is just an example script which serves as a proof of concept. It does not handle all the possible scenarios and can be extended or altered in any way, for example, to start/stop required services. For this example, a standard UFS file system was used. To reduce the time needed for recovery, a journal-enabled UFS or ZFS file system can be used instead. More detailed information with additional examples can be found in the HAST Wiki page. Troubleshooting General Troubleshooting Tips HAST should generally work without issues. However, as with any other software product, there may be times when it does not work as supposed. The sources of the problems may be different, but the rule of thumb is to ensure that the time is synchronized between all nodes of the cluster. When troubleshooting HAST problems, the debugging level of &man.hastd.8; should be increased by starting &man.hastd.8; with -d. This argument may be specified multiple times to further increase the debugging level. A lot of useful information may be obtained this way. Consider also using -F, which starts &man.hastd.8; in the foreground. Recovering from the Split-brain Condition Split-brain is when the nodes of the cluster are unable to communicate with each other, and both are configured as primary. This is a dangerous condition because it allows both nodes to make incompatible changes to the data. This problem must be corrected manually by the system administrator. The administrator must decide which node has more important changes (or merge them manually) and let HAST perform full synchronization of the node which has the broken data. To do this, issue these commands on the node which needs to be resynchronized: &prompt.root; hastctl role init <resource> &prompt.root; hastctl create <resource> &prompt.root; hastctl role secondary <resource> diff --git a/en_US.ISO8859-1/books/handbook/filesystems/chapter.xml b/en_US.ISO8859-1/books/handbook/filesystems/chapter.xml index 8797a46e57..f47cdeee09 100644 --- a/en_US.ISO8859-1/books/handbook/filesystems/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/filesystems/chapter.xml @@ -1,874 +1,874 @@ Tom Rhodes Written by File Systems Support Synopsis File Systems File Systems Support File Systems File systems are an integral part of any operating system. They allow users to upload and store files, provide access to data, and make hard drives useful. Different operating systems differ in their native file system. Traditionally, the native &os; file system has been the Unix File System UFS which has been modernized as UFS2. Since &os; 7.0, the Z File System ZFS is also available as a native file system. In addition to its native file systems, &os; supports a multitude of other file systems so that data from other operating systems can be accessed locally, such as data stored on locally attached USB storage devices, flash drives, and hard disks. This includes support for the &linux; Extended File System (EXT) and the µsoft; New Technology File System (NTFS). There are different levels of &os; support for the various file systems. Some require a kernel module to be loaded and others may require a toolset to be installed. Some non-native file system support is full read-write while others are read-only. After reading this chapter, you will know: The difference between native and supported file systems. Which file systems are supported by &os;. How to enable, configure, access, and make use of non-native file systems. Before reading this chapter, you should: Understand &unix; and &os; basics. Be familiar with the basics of kernel configuration and compilation. Feel comfortable installing software in &os;. Have some familiarity with disks, storage, and device names in &os;. The Z File System (ZFS) The Z file system, originally developed by &sun;, is designed to use a pooled storage method in that space is only used as it is needed for data storage. It is also designed for maximum data integrity, supporting data snapshots, multiple copies, and data checksums. It uses a software data replication model, known as RAID-Z. RAID-Z provides redundancy similar to hardware RAID, but is designed to prevent data write corruption and to overcome some of the limitations of hardware RAID. ZFS Tuning Some of the features provided by ZFS are RAM-intensive, so some tuning may be required to provide maximum efficiency on systems with limited RAM. Memory At a bare minimum, the total system memory should be at least one gigabyte. The amount of recommended RAM depends upon the size of the pool and the ZFS features which are used. A general rule of thumb is 1GB of RAM for every 1TB of storage. If the deduplication feature is used, a general rule of thumb is 5GB of RAM per TB of storage to be deduplicated. While some users successfully use ZFS with less RAM, it is possible that when the system is under heavy load, it may panic due to memory exhaustion. Further tuning may be required for systems with less than the recommended RAM requirements. Kernel Configuration Due to the RAM limitations of the &i386; platform, users using ZFS on the &i386; architecture should add the following option to a custom kernel configuration file, rebuild the kernel, and reboot: options KVA_PAGES=512 This option expands the kernel address space, allowing the vm.kvm_size tunable to be pushed beyond the currently imposed limit of 1 GB, or the limit of 2 GB for PAE. To find the most suitable value for this option, divide the desired address space in megabytes by four (4). In this example, it is 512 for 2 GB. Loader Tunables The kmem address space can be increased on all &os; architectures. On a test system with one gigabyte of physical memory, success was achieved with the following options added to /boot/loader.conf, and the system restarted: vm.kmem_size="330M" vm.kmem_size_max="330M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" For a more detailed list of recommendations for ZFS-related tuning, see . Using <acronym>ZFS</acronym> There is a start up mechanism that allows &os; to mount ZFS pools during system initialization. To set it, issue the following commands: &prompt.root; echo 'zfs_enable="YES"' >> /etc/rc.conf &prompt.root; service zfs start The examples in this section assume three SCSI disks with the device names da0, da1, and da2. Users of IDE hardware should instead use ad device names. Single Disk Pool To create a simple, non-redundant ZFS pool using a single disk device, use zpool: &prompt.root; zpool create example /dev/da0 To view the new pool, review the output of df: &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235230 1628718 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032846 48737598 2% /usr example 17547136 0 17547136 0% /example This output shows that the example pool has been created and mounted. It is now accessible as a file system. Files may be created on it and users can browse it, as seen in the following example: &prompt.root; cd /example &prompt.root; ls &prompt.root; touch testfile &prompt.root; ls -al total 4 drwxr-xr-x 2 root wheel 3 Aug 29 23:15 . drwxr-xr-x 21 root wheel 512 Aug 29 23:12 .. -rw-r--r-- 1 root wheel 0 Aug 29 23:15 testfile However, this pool is not taking advantage of any ZFS features. To create a dataset on this pool with compression enabled: &prompt.root; zfs create example/compressed &prompt.root; zfs set compression=gzip example/compressed The example/compressed dataset is now a ZFS compressed file system. Try copying some large files to /example/compressed. Compression can be disabled with: &prompt.root; zfs set compression=off example/compressed To unmount a file system, issue the following command and then verify by using df: &prompt.root; zfs umount example/compressed &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235232 1628716 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032864 48737580 2% /usr example 17547008 0 17547008 0% /example To re-mount the file system to make it accessible again, and verify with df: &prompt.root; zfs mount example/compressed &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235234 1628714 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032864 48737580 2% /usr example 17547008 0 17547008 0% /example example/compressed 17547008 0 17547008 0% /example/compressed The pool and file system may also be observed by viewing the output from mount: &prompt.root; mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, local, soft-updates) example on /example (zfs, local) example/data on /example/data (zfs, local) example/compressed on /example/compressed (zfs, local) ZFS datasets, after creation, may be used like any file systems. However, many other features are available which can be set on a per-dataset basis. In the following example, a new file system, data is created. Important files will be stored here, the file system is set to keep two copies of each data block: &prompt.root; zfs create example/data &prompt.root; zfs set copies=2 example/data It is now possible to see the data and space utilization by issuing df: &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235234 1628714 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032864 48737580 2% /usr example 17547008 0 17547008 0% /example example/compressed 17547008 0 17547008 0% /example/compressed example/data 17547008 0 17547008 0% /example/data Notice that each file system on the pool has the same amount of available space. This is the reason for using df in these examples, to show that the file systems use only the amount of space they need and all draw from the same pool. The ZFS file system does away with concepts such as volumes and partitions, and allows for several file systems to occupy the same pool. To destroy the file systems and then destroy the pool as they are no longer needed: &prompt.root; zfs destroy example/compressed &prompt.root; zfs destroy example/data &prompt.root; zpool destroy example <acronym>ZFS</acronym> RAID-Z There is no way to prevent a disk from failing. One method of avoiding data loss due to a failed hard disk is to implement RAID. ZFS supports this feature in its pool design. To create a RAID-Z pool, issue the following command and specify the disks to add to the pool: &prompt.root; zpool create storage raidz da0 da1 da2 &sun; recommends that the amount of devices used in a RAID-Z configuration is between three and nine. For environments requiring a single pool consisting of 10 disks or more, consider breaking it up into smaller RAID-Z groups. If only two disks are available and redundancy is a requirement, consider using a ZFS mirror. Refer to &man.zpool.8; for more details. This command creates the storage zpool. This may be verified using &man.mount.8; and &man.df.1;. This command makes a new file system in the pool called home: &prompt.root; zfs create storage/home It is now possible to enable compression and keep extra copies of directories and files using the following commands: &prompt.root; zfs set copies=2 storage/home &prompt.root; zfs set compression=gzip storage/home To make this the new home directory for users, copy the user data to this directory, and create the appropriate symbolic links: &prompt.root; cp -rp /home/* /storage/home &prompt.root; rm -rf /home /usr/home &prompt.root; ln -s /storage/home /home &prompt.root; ln -s /storage/home /usr/home Users should now have their data stored on the freshly created /storage/home. Test by adding a new user and logging in as that user. Try creating a snapshot which may be rolled back later: &prompt.root; zfs snapshot storage/home@08-30-08 Note that the snapshot option will only capture a real file system, not a home directory or a file. The @ character is a delimiter used between the file system name or the volume name. When a user's home directory gets trashed, restore it with: &prompt.root; zfs rollback storage/home@08-30-08 To get a list of all available snapshots, run ls in the file system's .zfs/snapshot directory. For example, to see the previously taken snapshot: &prompt.root; ls /storage/home/.zfs/snapshot It is possible to write a script to perform regular snapshots on user data. However, over time, snapshots may consume a great deal of disk space. The previous snapshot may be removed using the following command: &prompt.root; zfs destroy storage/home@08-30-08 After testing, /storage/home can be made the real /home using this command: &prompt.root; zfs set mountpoint=/home storage/home Run df and mount to confirm that the system now treats the file system as the real /home: &prompt.root; mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /usr (ufs, local, soft-updates) storage on /storage (zfs, local) storage/home on /home (zfs, local) &prompt.root; df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 2026030 235240 1628708 13% / devfs 1 1 0 100% /dev /dev/ad0s1d 54098308 1032826 48737618 2% /usr storage 26320512 0 26320512 0% /storage storage/home 26320512 0 26320512 0% /home This completes the RAID-Z configuration. To get status updates about the file systems created during the nightly &man.periodic.8; runs, issue the following command: &prompt.root; echo 'daily_status_zfs_enable="YES"' >> /etc/periodic.conf Recovering <acronym>RAID</acronym>-Z Every software RAID has a method of monitoring its state. The status of RAID-Z devices may be viewed with the following command: &prompt.root; zpool status -x If all pools are healthy and everything is normal, the following message will be returned: all pools are healthy If there is an issue, perhaps a disk has gone offline, the pool state will look similar to: pool: storage state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: none requested config: NAME STATE READ WRITE CKSUM storage DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 da0 ONLINE 0 0 0 da1 OFFLINE 0 0 0 da2 ONLINE 0 0 0 errors: No known data errors This indicates that the device was previously taken offline by the administrator using the following command: &prompt.root; zpool offline storage da1 It is now possible to replace da1 after the system has been powered down. When the system is back online, the following command may issued to replace the disk: &prompt.root; zpool replace storage da1 From here, the status may be checked again, this time without the flag to get state information: &prompt.root; zpool status storage pool: storage state: ONLINE scrub: resilver completed with 0 errors on Sat Aug 30 19:44:11 2008 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 errors: No known data errors As shown from this example, everything appears to be normal. Data Verification ZFS uses checksums to verify the integrity of stored data. These are enabled automatically upon creation of file systems and may be disabled using the following command: &prompt.root; zfs set checksum=off storage/home Doing so is not recommended as checksums take very little storage space and are used to check data integrity using checksum verification in a process is known as scrubbing. To verify the data integrity of the storage pool, issue this command: &prompt.root; zpool scrub storage This process may take considerable time depending on the amount of data stored. It is also very I/O intensive, so much so that only one scrub may be run at any given time. After the scrub has completed, the status is updated and may be viewed by issuing a status request: &prompt.root; zpool status storage pool: storage state: ONLINE scrub: scrub completed with 0 errors on Sat Jan 26 19:57:37 2013 config: NAME STATE READ WRITE CKSUM storage ONLINE 0 0 0 raidz1 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 errors: No known data errors The completion time is displayed and helps to ensure data integrity over a long period of time. Refer to &man.zfs.8; and &man.zpool.8; for other ZFS options. ZFS Quotas ZFS supports different types of quotas: the refquota, the general quota, the user quota, and the group quota. This section explains the basics of each type and includes some usage instructions. Quotas limit the amount of space that a dataset and its descendants can consume, and enforce a limit on the amount of space used by filesystems and snapshots for the descendants. Quotas are useful to limit the amount of space a particular user can use. Quotas cannot be set on volumes, as the volsize property acts as an implicit quota. The refquota=size limits the amount of space a dataset can consume by enforcing a hard limit on the space used. However, this hard limit does not include space used by descendants, such as file systems or snapshots. To enforce a general quota of 10 GB for storage/home/bob, use the following: &prompt.root; zfs set quota=10G storage/home/bob User quotas limit the amount of space that can be used by the specified user. The general format is userquota@user=size, and the user's name must be in one of the following formats: POSIX compatible name such as joe. POSIX numeric ID such as 789. SID name such as joe.bloggs@example.com. SID numeric ID such as S-1-123-456-789. For example, to enforce a quota of 50 GB for a user named joe, use the following: &prompt.root; zfs set userquota@joe=50G To remove the quota or make sure that one is not set, instead use: &prompt.root; zfs set userquota@joe=none User quota properties are not displayed by zfs get all. Non-root users can only see their own quotas unless they have been granted the userquota privilege. Users with this privilege are able to view and set everyone's quota. The group quota limits the amount of space that a specified group can consume. The general format is groupquota@group=size. To set the quota for the group firstgroup to 50 GB, use: &prompt.root; zfs set groupquota@firstgroup=50G To remove the quota for the group firstgroup, or to make sure that one is not set, instead use: &prompt.root; zfs set groupquota@firstgroup=none As with the user quota property, non-root users can only see the quotas associated with the groups that they belong to. However, root or a user with the groupquota privilege can view and set all quotas for all groups. To display the amount of space consumed by each user on the specified filesystem or snapshot, along with any specified quotas, use zfs userspace. For group information, use zfs groupspace. For more information about supported options or how to display only specific options, refer to &man.zfs.1;. Users with sufficient privileges and root can list the quota for storage/home/bob using: &prompt.root; zfs get quota storage/home/bob ZFS Reservations ZFS supports two types of space reservations. This section explains the basics of each and includes some usage instructions. The reservation property makes it possible to reserve a minimum amount of space guaranteed for a dataset and its descendants. This means that if a 10 GB reservation is set on storage/home/bob, if disk space gets low, at least 10 GB of space is reserved for this dataset. The refreservation property sets or indicates the minimum amount of space guaranteed to a dataset excluding descendants, such as snapshots. As an example, if a snapshot was taken of storage/home/bob, enough disk space would have to exist outside of the refreservation amount for the operation to succeed because descendants of the main data set are not counted by the refreservation amount and so do not encroach on the space set. Reservations of any sort are useful in many situations, such as planning and testing the suitability of disk space allocation in a new system, or ensuring that enough space is available on file systems for system recovery procedures and files. The general format of the reservation property is reservation=size, so to set a reservation of 10 GB on storage/home/bob, use: &prompt.root; zfs set reservation=10G storage/home/bob To make sure that no reservation is set, or to remove a reservation, use: &prompt.root; zfs set reservation=none storage/home/bob The same principle can be applied to the refreservation property for setting a refreservation, with the general format refreservation=size. To check if any reservations or refreservations exist on storage/home/bob, execute one of the following commands: &prompt.root; zfs get reservation storage/home/bob &prompt.root; zfs get refreservation storage/home/bob &linux; Filesystems This section describes some of the &linux; filesystems supported by &os;. <acronym>ext2</acronym> The &man.ext2fs.5; file system kernel implementation has been available since &os; 2.2. In &os; 8.x and earlier, the code is licensed under the GPL. Since &os; 9.0, the code has been rewritten and is now BSD licensed. The &man.ext2fs.5; driver allows the &os; kernel to both read and write to ext2 file systems. To access an ext2 file system, first load the kernel loadable module: &prompt.root; kldload ext2fs Then, to mount an &man.ext2fs.5; volume located on /dev/ad1s1: &prompt.root; mount -t ext2fs /dev/ad1s1 /mnt XFS XFS was originally written by SGI for the IRIX operating system and was then ported to &linux; and released under the GPL. See this page for more details. The &os; port was started by Russel - Cattelan, &a.kan;, and &a.rodrigc;. + Cattelan, &a.kan.email;, and &a.rodrigc.email;. To load XFS as a kernel-loadable module: &prompt.root; kldload xfs The &man.xfs.5; driver lets the &os; kernel access XFS filesystems. However, only read-only access is supported and writing to a volume is not possible. To mount a &man.xfs.5; volume located on /dev/ad1s1: &prompt.root; mount -t xfs /dev/ad1s1 /mnt The sysutils/xfsprogs port includes the mkfs.xfs which enables the creation of XFS filesystems, plus utilities for analyzing and repairing them. The -p flag to mkfs.xfs can be used to create an &man.xfs.5; filesystem which is populated with files and other metadata. This can be used to quickly create a read-only filesystem which can be tested on &os;. ReiserFS The Reiser file system, ReiserFS, was ported to - &os; by &a.dumbbell;, and has been released under the + &os; by &a.dumbbell.email;, and has been released under the GPL . The ReiserFS driver permits the &os; kernel to access ReiserFS file systems and read their contents, but not write to them. First, the kernel-loadable module needs to be loaded: &prompt.root; kldload reiserfs Then, to mount a ReiserFS volume located on /dev/ad1s1: &prompt.root; mount -t reiserfs /dev/ad1s1 /mnt diff --git a/en_US.ISO8859-1/books/handbook/jails/chapter.xml b/en_US.ISO8859-1/books/handbook/jails/chapter.xml index 9f928a9264..06e09b74c9 100644 --- a/en_US.ISO8859-1/books/handbook/jails/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/jails/chapter.xml @@ -1,1038 +1,1038 @@ Matteo Riondato Contributed by Jails jails Synopsis This chapter will provide an explanation of what &os; jails are and how to use them. Jails, sometimes referred to as an enhanced replacement of chroot environments, are a very powerful tool for system administrators, but their basic usage can also be useful for advanced users. Jails are a powerful tool, but they are not a security panacea. It is particularly important to note that while it is not possible for a jailed process to break out on its own, there are several ways in which an unprivileged user outside the jail can cooperate with a privileged user inside the jail and thereby obtain elevated privileges in the host environment. Most of these attacks can be mitigated by ensuring that the jail root is not accessible to unprivileged users in the host environment. Regardless, as a general rule, untrusted users with privileged access to a jail should not be given access to the host environment. After reading this chapter, you will know: What a jail is, and what purpose it may serve in &os; installations. How to build, start, and stop a jail. The basics of jail administration, both from inside and outside the jail. Other sources of useful information about jails are: The &man.jail.8; manual page. This is the full reference of the jail utility — the administrative tool which can be used in &os; to start, stop, and control &os; jails. The mailing lists and their archives. The archives of the &a.questions; and other mailing lists hosted by the &a.mailman.lists; already contain a wealth of material for jails. It should always be engaging to search the archives, or post a new question to the &a.questions.name; mailing list. Terms Related to Jails To facilitate better understanding of parts of the &os; system related to jails, their internals and the way they interact with the rest of &os;, the following terms are used further in this chapter: &man.chroot.8; (command) Utility, which uses &man.chroot.2; &os; system call to change the root directory of a process and all its descendants. &man.chroot.2; (environment) The environment of processes running in a chroot. This includes resources such as the part of the file system which is visible, user and group IDs which are available, network interfaces and other IPC mechanisms, etc. &man.jail.8; (command) The system administration utility which allows launching of processes within a jail environment. host (system, process, user, etc.) The controlling system of a jail environment. The host system has access to all the hardware resources available, and can control processes both outside of and inside a jail environment. One of the important differences of the host system from a jail is that the limitations which apply to superuser processes inside a jail are not enforced for processes of the host system. hosted (system, process, user, etc.) A process, user or other entity, whose access to resources is restricted by a &os; jail. Introduction Since system administration is a difficult and perplexing task, many powerful tools were developed to make life easier for the administrator. These tools mostly provide enhancements of some sort to the way systems are installed, configured and maintained. Part of the tasks which an administrator is expected to do is to properly configure the security of a system, so that it can continue serving its real purpose, without allowing security violations. One of the tools which can be used to enhance the security of a &os; system are jails. Jails were - introduced in &os; 4.X by &a.phk;, but were greatly + introduced in &os; 4.X by &a.phk.email;, but were greatly improved in &os; 5.X to make them a powerful and flexible subsystem. Their development still goes on, enhancing their usefulness, performance, reliability, and security. What is a Jail BSD-like operating systems have had &man.chroot.2; since the time of 4.2BSD. The &man.chroot.8; utility can be used to change the root directory of a set of processes, creating a safe environment, separate from the rest of the system. Processes created in the chrooted environment can not access files or resources outside of it. For that reason, compromising a service running in a chrooted environment should not allow the attacker to compromise the entire system. The &man.chroot.8; utility is good for easy tasks which do not require much flexibility or complex, advanced features. Since the inception of the chroot concept, however, many ways have been found to escape from a chrooted environment and, although they have been fixed in modern versions of the &os; kernel, it was clear that &man.chroot.2; was not the ideal solution for securing services. A new subsystem had to be implemented. This is one of the main reasons why jails were developed. Jails improve on the concept of the traditional &man.chroot.2; environment in several ways. In a traditional &man.chroot.2; environment, processes are only limited in the part of the file system they can access. The rest of the system resources (like the set of system users, the running processes, or the networking subsystem) are shared by the chrooted processes and the processes of the host system. Jails expand this model by virtualizing not only access to the file system, but also the set of users, the networking subsystem of the &os; kernel and a few other things. A more complete set of fine-grained controls available for tuning the access of a jailed environment is described in . A jail is characterized by four elements: A directory subtree — the starting point from which a jail is entered. Once inside the jail, a process is not permitted to escape outside of this subtree. Traditional security issues which plagued the original &man.chroot.2; design will not affect &os; jails. A hostname — the hostname which will be used within the jail. Jails are mainly used for hosting network services, therefore having a descriptive hostname for each jail can really help the system administrator. An IP address — this will be assigned to the jail and cannot be changed in any way during the jail's life span. The IP address of a jail is usually an alias address for an existing network interface, but this is not strictly necessary. A command — the path name of an executable to run inside the jail. The path is relative to the root directory of the jail environment. Apart from these, jails can have their own set of users and their own root user. Naturally, the powers of the root user are limited within the jail environment and, from the point of view of the host system, the jail root user is not an omnipotent user. In addition, the root user of a jail is not allowed to perform critical operations to the system outside of the associated &man.jail.8; environment. More information about capabilities and restrictions of the root user will be discussed in below. Creating and Controlling Jails Some administrators divide jails into the following two types: complete jails, which resemble a real &os; system, and service jails, dedicated to one application or service, possibly running with privileges. This is only a conceptual division and the process of building a jail is not affected by it. The &man.jail.8; manual page is quite clear about the procedure for building a jail: &prompt.root; setenv D /here/is/the/jail &prompt.root; mkdir -p $D &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make installworld DESTDIR=$D &prompt.root; make distribution DESTDIR=$D &prompt.root; mount -t devfs devfs $D/dev Selecting a location for a jail is the best starting point. This is where the jail will physically reside within the file system of the jail's host. A good choice can be /usr/jail/jailname, where jailname is the hostname identifying the jail. The /usr/ file system usually has enough space for the jail file system, which for complete jails is, essentially, a replication of every file present in a default installation of the &os; base system. If you have already rebuilt your userland using make world or make buildworld, you can skip this step and install your existing userland into the new jail. This command will populate the directory subtree chosen as jail's physical location on the file system with the necessary binaries, libraries, manual pages and so on. The distribution target for make installs every needed configuration file. In simple words, it installs every installable file of /usr/src/etc/ to the /etc directory of the jail environment: $D/etc/. Mounting the &man.devfs.8; file system inside a jail is not required. On the other hand, any, or almost any application requires access to at least one device, depending on the purpose of the given application. It is very important to control access to devices from inside a jail, as improper settings could permit an attacker to do nasty things in the jail. Control over &man.devfs.8; is managed through rulesets which are described in the &man.devfs.8; and &man.devfs.conf.5; manual pages. Once a jail is installed, it can be started by using the &man.jail.8; utility. The &man.jail.8; utility takes four mandatory arguments which are described in the . Other arguments may be specified too, e.g., to run the jailed process with the credentials of a specific user. The argument depends on the type of the jail; for a virtual system, /etc/rc is a good choice, since it will replicate the startup sequence of a real &os; system. For a service jail, it depends on the service or application that will run within the jail. Jails are often started at boot time and the &os; rc mechanism provides an easy way to do this. A list of the jails which are enabled to start at boot time should be added to the &man.rc.conf.5; file: jail_enable="YES" # Set to NO to disable starting of any jails jail_list="www" # Space separated list of names of jails Jail names in jail_list should contain alphanumeric characters only. For each jail listed in jail_list, a group of &man.rc.conf.5; settings, which describe the particular jail, should be added: jail_www_rootdir="/usr/jail/www" # jail's root directory jail_www_hostname="www.example.org" # jail's hostname jail_www_ip="192.168.0.10" # jail's IP address jail_www_devfs_enable="YES" # mount devfs in the jail jail_www_devfs_ruleset="www_ruleset" # devfs ruleset to apply to jail The default startup of jails configured in &man.rc.conf.5;, will run the /etc/rc script of the jail, which assumes the jail is a complete virtual system. For service jails, the default startup command of the jail should be changed, by setting the jail_jailname_exec_start option appropriately. For a full list of available options, please see the &man.rc.conf.5; manual page. &man.service.8; can be used to start or stop a jail by hand, if an entry for it exists in rc.conf: &prompt.root; service jail start www &prompt.root; service jail stop www A clean way to shut down a &man.jail.8; is not available at the moment. This is because commands normally used to accomplish a clean system shutdown cannot be used inside a jail. The best way to shut down a jail is to run the following command from within the jail itself or using the &man.jexec.8; utility from outside the jail: &prompt.root; sh /etc/rc.shutdown More information about this can be found in the &man.jail.8; manual page. Fine Tuning and Administration There are several options which can be set for any jail, and various ways of combining a host &os; system with jails, to produce higher level applications. This section presents: Some of the options available for tuning the behavior and security restrictions implemented by a jail installation. Some of the high-level applications for jail management, which are available through the &os; Ports Collection, and can be used to implement overall jail-based solutions. System Tools for Jail Tuning in &os; Fine tuning of a jail's configuration is mostly done by setting &man.sysctl.8; variables. A special subtree of sysctl exists as a basis for organizing all the relevant options: the security.jail.* hierarchy of &os; kernel options. Here is a list of the main jail-related sysctls, complete with their default value. Names should be self-explanatory, but for more information about them, please refer to the &man.jail.8; and &man.sysctl.8; manual pages. security.jail.set_hostname_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.sysvipc_allowed: 0 security.jail.enforce_statfs: 2 security.jail.allow_raw_sockets: 0 security.jail.chflags_allowed: 0 security.jail.jailed: 0 These variables can be used by the system administrator of the host system to add or remove some of the limitations imposed by default on the root user. Note that there are some limitations which cannot be removed. The root user is not allowed to mount or unmount file systems from within a &man.jail.8;. The root inside a jail may not load or unload &man.devfs.8; rulesets, set firewall rules, or do many other administrative tasks which require modifications of in-kernel data, such as setting the securelevel of the kernel. The base system of &os; contains a basic set of tools for viewing information about the active jails, and attaching to a jail to run administrative commands. The &man.jls.8; and &man.jexec.8; commands are part of the base &os; system, and can be used to perform the following simple tasks: Print a list of active jails and their corresponding jail identifier (JID), IP address, hostname and path. Attach to a running jail, from its host system, and run a command inside the jail or perform administrative tasks inside the jail itself. This is especially useful when the root user wants to cleanly shut down a jail. The &man.jexec.8; utility can also be used to start a shell in a jail to do administration in it; for example: &prompt.root; jexec 1 tcsh High-Level Administrative Tools in the &os; Ports Collection Among the many third-party utilities for jail administration, one of the most complete and useful is sysutils/jailutils. It is a set of small applications that contribute to &man.jail.8; management. Please refer to its web page for more information. Application of Jails Daniel Gerzo Contributed by Service Jails This section is based upon an idea originally presented by - &a.simon; at , and an updated article written by Ken Tom locals@gmail.com. This section illustrates how to set up a &os; system that adds an additional layer of security, using the &man.jail.8; feature. It is also assumed that the given system is at least running RELENG_6_0 and the information provided earlier in this chapter has been well understood. Design One of the major problems with jails is the management of their upgrade process. This tends to be a problem because every jail has to be rebuilt from scratch whenever it is updated. This is usually not a problem for a single jail, since the update process is fairly simple, but can be quite time consuming and tedious if a lot of jails are created. This setup requires advanced experience with &os; and usage of its features. If the presented steps below look too complicated, it is advised to take a look at a simpler system such as sysutils/ezjail, which provides an easier method of administering &os; jails and is not as sophisticated as this setup. This idea has been presented to resolve such issues by sharing as much as is possible between jails, in a safe way — using read-only &man.mount.nullfs.8; mounts, so that updating will be simpler, and putting single services into individual jails will become more attractive. Additionally, it provides a simple way to add or remove jails as well as a way to upgrade them. Examples of services in this context are: an HTTP server, a DNS server, a SMTP server, and so forth. The goals of the setup described in this section are: Create a simple and easy to understand jail structure. This implies not having to run a full installworld on each and every jail. Make it easy to add new jails or remove existing ones. Make it easy to update or upgrade existing jails. Make it possible to run a customized &os; branch. Be paranoid about security, reducing as much as possible the possibility of compromise. Save space and inodes, as much as possible. As it has been already mentioned, this design relies heavily on having a single master template which is read-only (known as nullfs) mounted into each jail and one read-write device per jail. A device can be a separate physical disc, a partition, or a vnode backed &man.md.4; device. In this example, we will use read-write nullfs mounts. The file system layout is described in the following list: Each jail will be mounted under the /home/j directory. /home/j/mroot is the template for each jail and the read-only partition for all of the jails. A blank directory will be created for each jail under the /home/j directory. Each jail will have a /s directory, that will be linked to the read-write portion of the system. Each jail shall have its own read-write system that is based upon /home/j/skel. Each jailspace (read-write portion of each jail) shall be created in /home/js. This assumes that the jails are based under the /home partition. This can, of course, be changed to anything else, but this change will have to be reflected in each of the examples below. Creating the Template This section will describe the steps needed to create the master template that will be the read-only portion for the jails to use. It is always a good idea to update the &os; system to the latest -RELEASE branch. Check the corresponding Handbook Chapter to accomplish this task. In the case the update is not feasible, the buildworld will be required in order to be able to proceed. Additionally, the sysutils/cpdup package will be required. We will use the &man.portsnap.8; utility to download the &os; Ports Collection. The Handbook Portsnap Chapter is always good reading for newcomers. First, create a directory structure for the read-only file system which will contain the &os; binaries for our jails, then change directory to the &os; source tree and install the read-only file system to the jail template: &prompt.root; mkdir /home/j /home/j/mroot &prompt.root; cd /usr/src &prompt.root; make installworld DESTDIR=/home/j/mroot Next, prepare a &os; Ports Collection for the jails as well as a &os; source tree, which is required for mergemaster: &prompt.root; cd /home/j/mroot &prompt.root; mkdir usr/ports &prompt.root; portsnap -p /home/j/mroot/usr/ports fetch extract &prompt.root; cpdup /usr/src /home/j/mroot/usr/src Create a skeleton for the read-write portion of the system: &prompt.root; mkdir /home/j/skel /home/j/skel/home /home/j/skel/usr-X11R6 /home/j/skel/distfiles &prompt.root; mv etc /home/j/skel &prompt.root; mv usr/local /home/j/skel/usr-local &prompt.root; mv tmp /home/j/skel &prompt.root; mv var /home/j/skel &prompt.root; mv root /home/j/skel Use mergemaster to install missing configuration files. Then get rid of the extra directories that mergemaster creates: &prompt.root; mergemaster -t /home/j/skel/var/tmp/temproot -D /home/j/skel -i &prompt.root; cd /home/j/skel &prompt.root; rm -R bin boot lib libexec mnt proc rescue sbin sys usr dev Now, symlink the read-write file system to the read-only file system. Please make sure that the symlinks are created in the correct s/ locations. Real directories or the creation of directories in the wrong locations will cause the installation to fail. &prompt.root; cd /home/j/mroot &prompt.root; mkdir s &prompt.root; ln -s s/etc etc &prompt.root; ln -s s/home home &prompt.root; ln -s s/root root &prompt.root; ln -s ../s/usr-local usr/local &prompt.root; ln -s ../s/usr-X11R6 usr/X11R6 &prompt.root; ln -s ../../s/distfiles usr/ports/distfiles &prompt.root; ln -s s/tmp tmp &prompt.root; ln -s s/var var As a last step, create a generic /home/j/skel/etc/make.conf with its contents as shown below: WRKDIRPREFIX?= /s/portbuild Having WRKDIRPREFIX set up this way will make it possible to compile &os; ports inside each jail. Remember that the ports directory is part of the read-only system. The custom path for WRKDIRPREFIX allows builds to be done in the read-write portion of every jail. Creating Jails Now that we have a complete &os; jail template, we can setup and configure the jails in /etc/rc.conf. This example demonstrates the creation of 3 jails: NS, MAIL and WWW. Put the following lines into the /etc/fstab file, so that the read-only template for the jails and the read-write space will be available in the respective jails: /home/j/mroot /home/j/ns nullfs ro 0 0 /home/j/mroot /home/j/mail nullfs ro 0 0 /home/j/mroot /home/j/www nullfs ro 0 0 /home/js/ns /home/j/ns/s nullfs rw 0 0 /home/js/mail /home/j/mail/s nullfs rw 0 0 /home/js/www /home/j/www/s nullfs rw 0 0 Partitions marked with a 0 pass number are not checked by &man.fsck.8; during boot, and partitions marked with a 0 dump number are not backed up by &man.dump.8;. We do not want fsck to check nullfs mounts or dump to back up the read-only nullfs mounts of the jails. This is why they are marked with 0 0 in the last two columns of each fstab entry above. Configure the jails in /etc/rc.conf: jail_enable="YES" jail_set_hostname_allow="NO" jail_list="ns mail www" jail_ns_hostname="ns.example.org" jail_ns_ip="192.168.3.17" jail_ns_rootdir="/usr/home/j/ns" jail_ns_devfs_enable="YES" jail_mail_hostname="mail.example.org" jail_mail_ip="192.168.3.18" jail_mail_rootdir="/usr/home/j/mail" jail_mail_devfs_enable="YES" jail_www_hostname="www.example.org" jail_www_ip="62.123.43.14" jail_www_rootdir="/usr/home/j/www" jail_www_devfs_enable="YES" The reason why the jail_name_rootdir variable is set to /usr/home instead of /home is that the physical path of the /home directory on a default &os; installation is /usr/home. The jail_name_rootdir variable must not be set to a path which includes a symbolic link, otherwise the jails will refuse to start. Use the &man.realpath.1; utility to determine a value which should be set to this variable. Please see the &os;-SA-07:01.jail Security Advisory for more information. Create the required mount points for the read-only file system of each jail: &prompt.root; mkdir /home/j/ns /home/j/mail /home/j/www Install the read-write template into each jail. Note the use of sysutils/cpdup, which helps to ensure that a correct copy is done of each directory: &prompt.root; mkdir /home/js &prompt.root; cpdup /home/j/skel /home/js/ns &prompt.root; cpdup /home/j/skel /home/js/mail &prompt.root; cpdup /home/j/skel /home/js/www In this phase, the jails are built and prepared to run. First, mount the required file systems for each jail, and then start them using the jail rc script. &prompt.root; mount -a &prompt.root; service jail start The jails should be running now. To check if they have started correctly, use the &man.jls.8; command. Its output should be similar to the following: &prompt.root; jls JID IP Address Hostname Path 3 192.168.3.17 ns.example.org /home/j/ns 2 192.168.3.18 mail.example.org /home/j/mail 1 62.123.43.14 www.example.org /home/j/www At this point, it should be possible to log onto each jail, add new users or configure daemons. The JID column indicates the jail identification number of each running jail. Use the following command in order to perform administrative tasks in the jail whose JID is 3: &prompt.root; jexec 3 tcsh Upgrading In time, there will be a need to upgrade the system to a newer version of &os;, either because of a security issue, or because new features have been implemented which are useful for the existing jails. The design of this setup provides an easy way to upgrade existing jails. Additionally, it minimizes their downtime, as the jails will be brought down only in the very last minute. Also, it provides a way to roll back to the older versions should any problems occur. The first step is to upgrade the host system in the usual manner. Then create a new temporary read-only template in /home/j/mroot2. &prompt.root; mkdir /home/j/mroot2 &prompt.root; cd /usr/src &prompt.root; make installworld DESTDIR=/home/j/mroot2 &prompt.root; cd /home/j/mroot2 &prompt.root; cpdup /usr/src usr/src &prompt.root; mkdir s The installworld run creates a few unnecessary directories, which should be removed: &prompt.root; chflags -R 0 var &prompt.root; rm -R etc var root usr/local tmp Recreate the read-write symlinks for the master file system: &prompt.root; ln -s s/etc etc &prompt.root; ln -s s/root root &prompt.root; ln -s s/home home &prompt.root; ln -s ../s/usr-local usr/local &prompt.root; ln -s ../s/usr-X11R6 usr/X11R6 &prompt.root; ln -s s/tmp tmp &prompt.root; ln -s s/var var The right time to stop the jails is now: &prompt.root; service jail stop Unmount the original file systems: &prompt.root; umount /home/j/ns/s &prompt.root; umount /home/j/ns &prompt.root; umount /home/j/mail/s &prompt.root; umount /home/j/mail &prompt.root; umount /home/j/www/s &prompt.root; umount /home/j/www The read-write systems are attached to the read-only system (/s) and must be unmounted first. Move the old read-only file system and replace it with the new one. This will serve as a backup and archive of the old read-only file system should something go wrong. The naming convention used here corresponds to when a new read-only file system has been created. Move the original &os; Ports Collection over to the new file system to save some space and inodes: &prompt.root; cd /home/j &prompt.root; mv mroot mroot.20060601 &prompt.root; mv mroot2 mroot &prompt.root; mv mroot.20060601/usr/ports mroot/usr At this point the new read-only template is ready, so the only remaining task is to remount the file systems and start the jails: &prompt.root; mount -a &prompt.root; service jail start Use &man.jls.8; to check if the jails started correctly. Do not forget to run mergemaster in each jail. The configuration files will need to be updated as well as the rc.d scripts. diff --git a/en_US.ISO8859-1/htdocs/administration.xml b/en_US.ISO8859-1/htdocs/administration.xml index e7d7c11794..fec8808939 100644 --- a/en_US.ISO8859-1/htdocs/administration.xml +++ b/en_US.ISO8859-1/htdocs/administration.xml @@ -1,495 +1,489 @@ ]> &title; $FreeBSD$

Introduction

This page lists teams, groups and individuals within the FreeBSD project with designated project roles and areas of responsibility, along with brief descriptions and contact information.

Project Management
Release Engineering
- Primary Release Engineering Team
- Builders Release Engineering Team
Teams
Secretaries
Internal Administration

FreeBSD Core Team <core@FreeBSD.org>

The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. The Core Team is elected by the active developers in the project.

&a.tabthorpe; <tabthorpe@FreeBSD.org>
&a.gavin; <gavin@FreeBSD.org>
&a.jhb; <jhb@FreeBSD.org>
&a.kib; <kib@FreeBSD.org>
&a.theraven; <theraven@FreeBSD.org>
&a.hrs; <hrs@FreeBSD.org>
&a.peter; <peter@FreeBSD.org>
&a.miwi; <miwi@FreeBSD.org>
&a.tabthorpe.email;
&a.gavin.email;
&a.jhb.email;
&a.kib.email;
&a.theraven.email;
&a.hrs.email;
&a.peter.email;
&a.miwi.email;

FreeBSD Documentation Engineering Team <doceng@FreeBSD.org>

The FreeBSD Documentation Engineering Team is responsible for defining and following up documentation goals for the committers in the Documentation project. The doceng team charter describes the duties and responsibilities of the Documentation Engineering Team in greater detail.

&a.gjb; <gjb@FreeBSD.org>
&a.blackend; <blackend@FreeBSD.org>
&a.gabor; <gabor@FreeBSD.org>
&a.hrs; <hrs@FreeBSD.org>
&a.gjb.email;
&a.blackend.email;
&a.gabor.email;
&a.hrs.email;

FreeBSD Port Management Team <portmgr@FreeBSD.org>

The primary responsibility of the FreeBSD Port Management Team is to ensure that the FreeBSD Ports Developer community provides a ports collection that is functional, stable, up-to-date and full-featured. Its secondary responsibility is to coordinate among the committers and developers who work on it. The portmgr team charter describes the duties and responsibilities of the Port Management Team in greater detail.

&a.tabthorpe; <tabthorpe@FreeBSD.org>
&a.marcus; <marcus@FreeBSD.org>
&a.bapt; <bapt@FreeBSD.org>
&a.bdrewery; <bdrewery@FreeBSD.org> - (Release Engineering Team Liaison)
&a.decke; <decke@FreeBSD.org>
&a.erwin; <erwin@FreeBSD.org> - (Cluster Administration Team Liaison)
&a.itetcu; <itetcu@FreeBSD.org>
&a.miwi; <miwi@FreeBSD.org>
&a.tabthorpe.email;
&a.marcus.email;
&a.bapt.email;
&a.bdrewery.email; (Release Engineering Team Liaison)
&a.decke.email;
&a.erwin.email; (Cluster Administration Team Liaison)
&a.itetcu.email;
&a.miwi.email;

Primary Release Engineering Team <re@FreeBSD.org>

The Primary Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining releng/* branches, among other things. The release engineering team charter describes the duties and responsibilities of the Primary Release Engineering Team in greater detail.

&a.mva; <mva@FreeBSD.org>
&a.gjb; <gjb@FreeBSD.org>
&a.kib; <kib@FreeBSD.org>
&a.joel; <joel@FreeBSD.org>
&a.blackend; <blackend@FreeBSD.org>
&a.skreuzer; <skreuzer@FreeBSD.org>
&a.delphij; <delphij@FreeBSD.org>
&a.jpaetzel; <jpaetzel@FreeBSD.org>
&a.rodrigc; <rodrigc@FreeBSD.org>
&a.hrs; <hrs@FreeBSD.org>
&a.glebius; <glebius@FreeBSD.org>
&a.kensmith; <kensmith@FreeBSD.org> - (Lead)
&a.marius; <marius@FreeBSD.org>
&a.mva.email;
&a.gjb.email;
&a.kib.email;
&a.joel.email;
&a.blackend.email;
&a.skreuzer.email;
&a.delphij.email;
&a.jpaetzel.email;
&a.rodrigc.email;
&a.hrs.email;
&a.glebius.email;
&a.kensmith.email; (Lead)
&a.marius.email;

Builders Release Engineering Team <re-builders@FreeBSD.org>

The builders release engineering team is responsible for building and packaging FreeBSD releases on the various supported platforms.

&a.marcel; <marcel@FreeBSD.org>
&a.nyan; <nyan@FreeBSD.org>
&a.nwhitehorn; <nwhitehorn@FreeBSD.org>
&a.marcel.email;
&a.nyan.email;
&a.nwhitehorn.email;

Donations Team <donations@FreeBSD.org>

The FreeBSD Donations Team is responsible for responding to donations offers, establishing donation guidelines and procedures, and coordinating donation offers with the FreeBSD developer community. A more detailed description of the duties of the Donations Team is available on the FreeBSD Donations Liaison page.

&a.tabthorpe; <tabthorpe@FreeBSD.org>
&a.gjb; <gjb@FreeBSD.org>
&a.gahr; <gahr@FreeBSD.org>
&a.pgollucci; <pgolluci@FreeBSD.org>
&a.skreuzer; <skreuzer@FreeBSD.org>
&a.obrien; <obrien@FreeBSD.org>
&a.trhodes; <trhodes@FreeBSD.org>
Daniel Seuffert <ds@FreeBSD.org>
&a.rwatson; <rwatson@FreeBSD.org>
&a.tabthorpe.email;
&a.gjb.email;
&a.gahr.email;
&a.pgollucci.email;
&a.skreuzer.email;
&a.obrien.email;
&a.trhodes.email;
&a.ds.email;
&a.rwatson.email;

Marketing Team <marketing@FreeBSD.org>

Press contact, marketing, interviews, information.

Steven Beedle <steven@zna.com>
Denise Ebery <denise@ixsystems.com>
Deb Goodkin <deb@FreeBSD.org>
&a.jkoshy; <jkoshy@FreeBSD.org>
&a.dru; <dru@FreeBSD.org>
&a.mwlucas; <mwlucas@FreeBSD.org>
&a.imp; <imp@FreeBSD.org>
&a.kmoore; <kmoore@FreeBSD.org>
&a.murray; <murray@FreeBSD.org>
Matt Olander <matt@FreeBSD.org>
&a.deb.email;
&a.jkoshy.email;
&a.dru.email; <
&a.mwlucas.email;
&a.imp.email;
&a.kmoore.email;
&a.murray.email;
&a.matt.email;
Jeremy C. Reed <reed@reedmedia.net>
&a.rwatson; <rwatson@FreeBSD.org>
&a.rwatson.email;

Security Team <secteam@FreeBSD.org>

The FreeBSD Security Team (headed by the Security Officer) is responsible for keeping the community aware of bugs, exploits and security risks affecting the FreeBSD src and ports trees, and to promote and distribute information needed to safely run FreeBSD systems. Furthermore, it is responsible for resolving software bugs affecting the security of FreeBSD and issuing security advisories. The FreeBSD Security Officer Charter describes the duties and responsibilities of the Security Officer in greater detail.

&a.benl; <benl@FreeBSD.org>
&a.cperciva; <cperciva@FreeBSD.org> (Officer Emeritus)
&a.csjp; <csjp@FreeBSD.org>
&a.delphij; <delphij@FreeBSD.org> (Officer Deputy)
&a.des; <des@FreeBSD.org> (Officer)
&a.gavin; <gavin@FreeBSD.org> (Core Team Liaison)
&a.gnn; <gnn@FreeBSD.org> (Secretary)
&a.jonathan; <jonathan@FreeBSD.org>
&a.philip; <philip@FreeBSD.org>
&a.qingli; <qingli@FreeBSD.org>
&a.remko; <remko@FreeBSD.org>
&a.rwatson; <rwatson@FreeBSD.org>
&a.simon; <simon@FreeBSD.org> - (Officer Emeritus)
&a.stas; <stas@FreeBSD.org>
&a.trasz; <trasz@FreeBSD.org>
&a.benl.email;
&a.cperciva.email; (Officer Emeritus)
&a.csjp.email;
&a.delphij.email; (Officer Deputy)
&a.des.email; (Officer)
&a.gavin.email; (Core Team Liaison)
&a.gnn.email; (Secretary)
&a.jonathan.email;
&a.philip.email;
&a.qingli.email;
&a.remko.email;
&a.rwatson.email;
&a.simon.email; (Officer Emeritus)
&a.stas.email;
&a.trasz.email;

Vendor Relations <vendor-relations@FreeBSD.org>

Vendor Relations is responsible for handling email from hardware and software vendors. Email sent to Vendor Relations is forwarded to the &os; Core Team in addition to the &os; Foundation.

Core Team Secretary <core-secretary@FreeBSD.org>

The FreeBSD Core Team Secretary is a non-voting member of the Core Team, responsible for documenting the work done by core, keeping track of the core agenda, direct contact with non-core members sending mail to core and to be an the interface to the admin team for committer/account approval. The Core Team Secretary is also responsible for writing and sending out monthly status reports to the FreeBSD Developer community, containing a summary of core's latest decisions and actions.

&a.pgj; <pgj@FreeBSD.org>
&a.pgj.email;

Port Management Team Secretary <portmgr-secretary@FreeBSD.org>

The FreeBSD Port Management Team Secretary is a non-voting member of the Port Management Team, responsible for documenting the work done by portmgr, keeping track of voting procedures, and to be an interface to the other teams, especially the admin and Core teams. The Port Management Team Secretary is also responsible for writing and sending out monthly status reports to the FreeBSD Developer community, containing a summary of portmgr's latest decisions and actions.

&a.tabthorpe; <tabthorpe@FreeBSD.org>
&a.tabthorpe.email;

Security Team Secretary <secteam-secretary@FreeBSD.org>

The FreeBSD Security Team Secretary will make sure someone responds to incoming emails towards the Security Team. He will acknowledge receipt and keep track of the progress within the Security Team. If needed the Secretary will contact members of the Security Team to let them provide an update on ongoing items. Currently the Security Team Secretary does not handle Security Officer Team items.

&a.gnn; <gnn@FreeBSD.org>
&a.gnn.email;

Accounts Team <accounts@>

The Accounts Team is responsible for setting up accounts for new committers in the project. Requests for new accounts will not be acted upon without the proper approval from the appropriate entity.

&a.simon; <simon@FreeBSD.org>
&a.dhw; <dhw@FreeBSD.org>
&a.simon.email;
&a.dhw.email;

Backups Administrators <backups@>

The Backups Administrators handle all backups on the FreeBSD cluster.

&a.simon; <simon@FreeBSD.org>
&a.dhw; <dhw@FreeBSD.org>
&a.simon;
&a.dhw;

Bugmeisters & GNATS Administrators <bugmeister@FreeBSD.org>

The Bugmeisters and GNATS Administrators are responsible for ensuring that the maintenance database is in working order, that the entries are correctly categorised and that there are no invalid entries. They are also responsible for the problem report group.

&a.eadler; <eadler@FreeBSD.org>
&a.gavin; <gavin@FreeBSD.org>
&a.gonzo; <gonzo@FreeBSD.org>
&a.eadler.email;
&a.gavin.email;
&a.gonzo.email;

Cluster Administrators <admins@>

The Cluster Administrators consists of the people responsible for administrating the machines that the project relies on for its distributed work and communication to be synchronised. It consists mainly of those people who have physical access to the servers. Issues concerning the projects infrastructure or setting up new machines should be directed to the cluster administrators. This team is led by the lead cluster administrator whose duties and responsbilities are described in the cluster administration charter in greater detail.

&a.bhaga; <bhaga@FreeBSD.org>
&a.brd; <brd@FreeBSD.org>
&a.bz; <bz@FreeBSD.org>
&a.gjb; <gjb@FreeBSD.org>
&a.kensmith; <kensmith@FreeBSD.org>
&a.peter; <peter@FreeBSD.org> (Lead)
&a.sbruno; <sbruno@FreeBSD.org>
&a.simon; <simon@FreeBSD.org>
&a.zi; <zi@FreeBSD.org>
&a.bhaga.email;
&a.brd.email;
&a.bz.email;
&a.gjb.email;
&a.kensmith.email;
&a.peter.email; (Lead)
&a.sbruno.email;
&a.simon.email;
&a.zi.email;

CVSup Mirror Site Coordinators <cvsup-master@FreeBSD.org>

The CVSup Mirror Site Coordinators coordinates all the CVSup mirror site adminstrators to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest CVSup mirror.

&a.kuriyama; <kuriyama@FreeBSD.org>
&a.kensmith; <kensmith@FreeBSD.org>
&a.kuriyama.email;
&a.kensmith.email;

DNS Administrators <dnsadm@>

The DNS Administrators are responsible for managing DNS and related services.

&a.brd; <brd@FreeBSD.org>
&a.simon; <simon@FreeBSD.org>
&a.peter; <peter@FreeBSD.org>
&a.bz; <bz@FreeBSD.org>
&a.brd;
&a.simon;
&a.peter;
&a.bz;

FTP/WWW Mirror Site Coordinators <mirror-admin@FreeBSD.org>

The FTP/WWW Mirror Site Coordinators coordinate all the FTP/WWW mirror site adminstrators to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest FTP/WWW mirror.

&a.brd; <brd@FreeBSD.org>
&a.kuriyama; <kuriyama@FreeBSD.org>
&a.simon; <simon@FreeBSD.org>
&a.kensmith; <kensmith@FreeBSD.org>
&a.bz; <bz@FreeBSD.org>
&a.brd.email;
&a.kuriyama.email;
&a.simon.email;
&a.kensmith.email;
&a.bz.email;

Perforce Repository Administrators <perforce-admin@FreeBSD.org>

The Perforce Repository Administrators are responsible for administrating the FreeBSD perforce source repository and setting up new perforce accounts. All requests concerning new perforce accounts for non-committers should be directed to the perforce administrators.

&a.gibbs; <gibbs@FreeBSD.org>
&a.kensmith; <kensmith@FreeBSD.org>
&a.gordon; <gordon@FreeBSD.org>
&a.rwatson; <rwatson@FreeBSD.org>
&a.peter; <peter@FreeBSD.org>
&a.gibbs.email;
&a.kensmith.email;
&a.gordon.email;
&a.rwatson.email;
&a.peter.email;

Postmaster Team <postmaster@FreeBSD.org>

The Postmaster Team is responsible for mail being correctly delivered to the committers' email address, ensuring that the mailing lists work, and should take measures against possible disruptions of project mail services, such as having troll-, spam- and virus-filters.

&a.jmb; <jmb@FreeBSD.org>
&a.brd; <brd@FreeBSD.org>
&a.flo; <flo@FreeBSD.org>
&a.sahil; <sahil@FreeBSD.org>
&a.dhw; <dhw@FreeBSD.org>
&a.jmb.email;
&a.brd.email;
&a.flo.email;
&a.sahil.email;
&a.dhw.email;

Subversion Administrators <svnadm@>

The FreeBSD Subversion team is responsible for maintaining the health of the Subversion Repositories.

&a.bz; <bz@FreeBSD.org>
&a.peter; <peter@FreeBSD.org>
&a.simon; <simon@FreeBSD.org>

Webmaster Team <webmaster@FreeBSD.org>

The FreeBSD Webmaster Team is responsible for keeping the main FreeBSD web sites up and running. This means web server configuration, CGI scripts, fulltext and mailing list search. Anything web related, technical stuff belongs to the scope of the Webmaster Team, excluding bugs in the documentation.

&a.nik; <nik@FreeBSD.org>
&a.kuriyama; <kuriyama@FreeBSD.org>
&a.simon; <simon@FreeBSD.org>
&a.jesusr; <jesusr@FreeBSD.org>
&a.wosch; <wosch@FreeBSD.org>
&a.don; <don@FreeBSD.org>
&a.nik.email;
&a.kuriyama.email;
&a.simon.email;
&a.jesusr.email;
&a.wosch.email;
&a.don.email;

diff --git a/en_US.ISO8859-1/htdocs/internal/doceng.xml b/en_US.ISO8859-1/htdocs/internal/doceng.xml index 2d1ecbd609..638d1edfd0 100644 --- a/en_US.ISO8859-1/htdocs/internal/doceng.xml +++ b/en_US.ISO8859-1/htdocs/internal/doceng.xml @@ -1,87 +1,87 @@ ]> &title; $FreeBSD$

The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project. The main responsibilities of this team are:

To grant approval for new documentation committers. Documentation includes articles and books, website pages, manual pages, release notes and translations of the above. There are two kinds of doc commit bits: translator commit bit, which is limited to translations in a particular language and full commit bit, which is only granted to aspirants, who have shown enough English writing skills.
To maintain the doc project primer, which documents best practices for the FreeBSD Documentation Project.
To manage the doc/ release process. This includes coordinating the release documentation updates with the various translation teams, coordinating with the release engineering team to tag the doc/ tree during the release cycle, and documenting these procedures.
To ensure that the generated documentation (PDF, HTML, etc.) on the Web site and FTP site are up to date with respect to the versions of the documents in the SVN tree. This includes making sure the Web site build is functioning correctly, and also involves working with the admin team to ensure that the primary Web server has all of the requisite software installed (including build scripts).
To act as MAINTAINER (when necessary) or to work in coordination with existing MAINTAINERs, to ensure that the documentation toolchains (DocBook, groff, etc.) are in good working order.
To maintain the sanctity of the FreeBSD doc/ tree. Due to the visibility of these files and documents to the outside world, doceng@ reserves the right to immediately backout (or fix without waiting for response from the original committer) changes that introduce broken links, cause the Web site build to break, or otherwise degrade the accessibility of the FreeBSD Web site and documentation.

It is specifically noted here that doceng@ is not a conflict resolution body for the FreeBSD Documentation Project. Discussion and consensus on the freebsd-doc mailing list is how the project has conducted itself, and how it is expected to conduct itself in the future.

Current Membership

-The current members of this team are &a.doceng;. +The current members of this team are &a.doceng.members;.

New Doc Committers

New doc committers are approved by doceng@ with a vote through email and a two week timeout. A committer is approved if at least one doceng@ member votes yes, and no doceng@ members vote no. When a commit bit proposal is accepted, doceng@ sends out an acceptance email to the mentor and the new committer with core@ and accounts@ CC'ed.

Idle Doc Committers

Doc Committers that have not made a commit in 12 months will be contacted by a doceng@ member and without a response after a delay of 2 weeks, these committers will be automatically removed from the access file. In case of no response, doceng@ will also contact core@ about the idle committers. diff --git a/en_US.ISO8859-1/htdocs/platforms/arm.xml b/en_US.ISO8859-1/htdocs/platforms/arm.xml index 2ad1f0af81..a865bba349 100644 --- a/en_US.ISO8859-1/htdocs/platforms/arm.xml +++ b/en_US.ISO8859-1/htdocs/platforms/arm.xml @@ -1,117 +1,117 @@ ]> &title; $FreeBSD$

Introduction

This page contains information about the FreeBSD port to the ARM architecture and hardware. Discussion of the ARM port takes place on the freebsd-arm mailing list.

Status
Hardware List
What Needs To Be Done
FreeBSD/ARM Related Links
Mini-Install Guide
FreeBSD/ARM mailing list

Status

ARM is officially a Tier 2 architecture, as the FreeBSD project does not provide official releases or pre-built packages for this platform due to it primarily targeting the embedded arena. However, FreeBSD/ARM is being actively developed and maintained, is well supported, and provides an excellent framework for building ARM-based systems.

FreeBSD/ARM Hardware Notes

FreeBSD should work on the i80321 based Intel XScale® devboards, which includes the IQ31244 and IQ80321 boards. Support is still minimal, covering only the CPU, PCI-X bus, em(4) Ethernet adapters, the UART and timer devices.

The i80219 XScale processor is supported, as is the EP80219 devboard.

The IXP425 is supported, as is the Avila GW2348-4 devboard.

The Atmel AT91RM9200 CPU/Microcontroller range is supported. Support is provided for the Kwikbyte KB9202 devboard range, the BWCT board and the Hot-e HL200 thin client device.

Minimal support for the StrongARM 1100 CPU is provided, but only within the limits of what Simics emulate: CPU, UART and clock. It is theoretically possible to boot on the Assabet board, the one Simics emulates; no attempts, successful or unsuccessful, have been reported.

Additionally, support for the Technologic Systems TS-7200 devboard is in the works, as is support for the Atmel AT91SAM926x CPU and the Marvell Orion ARM SoC, the Samsung S3C2XX0 range, and Cirrus Logic EP93XX CPUs.

What Needs To Be Done

SATA support needs to be added.
Other devices, such as watchdog, i2c and bus should be merged from NetBSD.

FreeBSD/ARM Related Links

Mini-Install guide

&a.cognet; (cognet@FreeBSD.org) has written a mini-install guide for the +

&a.cognet.email; has written a mini-install guide for the current FreeBSD source. It is available here.

FreeBSD/ARM mailing list

To subscribe to this list, send mail to <freebsd-arm-subscribe@FreeBSD.org> or visit mailman interface.

What musicians say about FreeBSD/ARM

With FreeBSD/ARM, you can enjoy the silence from running your (embedded) computer. There's even a song of that name, "Enjoy The Silence", by Depeche Mode:

All I ever wanted
 All I ever needed
 Is here in my ARMs
 Words are very unnecessary
 They can only do harm

diff --git a/en_US.ISO8859-1/htdocs/platforms/sparc.xml b/en_US.ISO8859-1/htdocs/platforms/sparc.xml index 87c3faf382..746801a9bb 100644 --- a/en_US.ISO8859-1/htdocs/platforms/sparc.xml +++ b/en_US.ISO8859-1/htdocs/platforms/sparc.xml @@ -1,186 +1,186 @@ ]> &title; $FreeBSD$

Introduction

This page contains information about the FreeBSD port to Fujitsu's SPARC64® and Oracle's UltraSPARC® architectures. Discussion of this port takes place on the freebsd-sparc mailing list.

Status
Hardware List
Credits
FreeBSD/sparc64 mailing list
Points of Interest

Status

UltraSPARC is a Tier 2 architecture, and as such is not fully supported by the FreeBSD project. Although fully functional, the port is not as mature as the existing i386 or amd64 ports.

Hardware List

A summary of supported systems follows. SMP is supported on all supported systems that contain more than 1 processor. For full details please see the hardware notes of the release you are using.

Naturetech GENIALstation 777S
Sun Blade 100
Sun Blade 150
Sun Enterprise 150
Sun Enterprise 220R
Sun Enterprise 250
Sun Enterprise 420R
Sun Enterprise 450
Sun Fire B100s (support for the on-board NICs first appeared in 8.1-RELEASE)
Sun Fire V100
Sun Fire V120
Sun Netra™ T1 100/105
Sun Netra T1 AC200/DC200
Sun Netra t 1100
Sun Netra t 1120
Sun Netra t 1125
Sun Netra t 1400/1405
Sun Netra 120
Sun Netra X1
Sun SPARCEngine® Ultra AX1105
Sun SPARCEngine Ultra AXe
Sun SPARCEngine Ultra AXi
Sun SPARCEngine Ultra AXmp
Sun SPARCEngine CP1500
Sun Ultra™ 1
Sun Ultra 1E
Sun Ultra 2
Sun Ultra 5
Sun Ultra 10
Sun Ultra 30
Sun Ultra 60
Sun Ultra 80
Sun Ultra 450

The following systems are partially supported by FreeBSD. In particular the fibre channel controllers in SBus-based systems are not supported. However, it is possible to use these with a SCSI controller supported by the esp(4) driver (Sun ESP SCSI, Sun FAS Fast-SCSI and Sun FAS366 Fast-Wide SCSI controllers).

Sun Enterprise 3500
Sun Enterprise 4500

Starting with 7.2-RELEASE, sparc64 systems based on Sun UltraSPARC III and beyond are also supported by FreeBSD, which includes the following known working systems:

Sun Blade 1000
Sun Blade 1500
Sun Blade 2000
Sun Blade 2500
Sun Fire 280R
Sun Fire V210
Sun Fire V215 (support first appeared in 7.3-RELEASE and 8.1-RELEASE)
Sun Fire V240
Sun Fire V245 (support first appeared in 7.3-RELEASE and 8.1-RELEASE)
Sun Fire V250
Sun Fire V440 (support for the on-board NICs first appeared in 7.3-RELEASE and 8.0-RELEASE)
Sun Fire V480 (501-6780 and 501-6790 centerplanes only, for which support first appeared in 7.3-RELEASE and 8.1-RELEASE, other centerplanes might work beginning with 8.3-RELEASE and 9.0-RELEASE)
Sun Fire V880
Sun Fire V890 (support first appeared in 7.4-RELEASE and 8.1-RELEASE, non-mixed Ultrasparc IV/IV+ CPU-configurations only)
Sun Netra 20/Netra T4

The following Sun UltraSPARC systems are not tested but believed to be also supported by FreeBSD:

Sun Fire V125
Sun Fire V490 (support first appeared in 7.4-RELEASE and 8.1-RELEASE, non-mixed Ultrasparc IV/IV+ CPU-configurations only)

Starting with 7.4-RELEASE and 8.1-RELEASE, sparc64 systems based on Fujitsu SPARC64 V are also supported by FreeBSD, which includes the following known working systems:

Fujitsu PRIMEPOWER® 250

The following Fujitsu SPARC64 systems are not tested but believed to be also supported by FreeBSD:

Fujitsu PRIMEPOWER 450
Fujitsu PRIMEPOWER 650
Fujitsu PRIMEPOWER 850

If you have a system that is not listed here please try it, and let us know about it.

Credits

The following people have been working either in the spotlights or behind the scenes to get the FreeBSD port off the ground:

&a.jake;
&a.tmm;
&a.obrien;
&a.jake.email;
&a.tmm.email;
&a.obrien.email;

FreeBSD/sparc64 mailing list

To subscribe to this list, send an email to <freebsd-sparc64-subscribe@FreeBSD.org> or visit the mailman interface.

Pointers Of Interest

diff --git a/en_US.ISO8859-1/htdocs/platforms/xbox.xml b/en_US.ISO8859-1/htdocs/platforms/xbox.xml index 77f3b89d26..5d7273a546 100644 --- a/en_US.ISO8859-1/htdocs/platforms/xbox.xml +++ b/en_US.ISO8859-1/htdocs/platforms/xbox.xml @@ -1,59 +1,59 @@ ]> &title; $FreeBSD$

Introduction

FreeBSD/xbox is a port of FreeBSD which aims to run on Microsoft® - Xbox® systems. This project was started by &a.rink;, who did most of the patching - and coding. Ed Schouten helped with + Xbox® systems. This project was started by &a.rink.email;, + who did most of the patching + and coding. &a.ed.email; helped with reviewing patches and he also provided details on certain Xbox internals.

Status

&os;/xbox has been supported since FreeBSD 6-STABLE. The framebuffer, Ethernet, sound and USB devices (such as an USB keyboard for the console) are all supported.

In order to aid people in installing the FreeBSD/xbox port, a combined install/livecd has been created. It is available here.

Booting &os; kernels

In order to boot &os; you must have an up-to-date version of the Linux/xbox BIOS, called Cromwell (failure will result in your kernel crashing immediately after loading). A Cromwell with FreeBSD UFS patches (this will make it able to load a kernel directly from an UFS file system) is available in the ports tree at /usr/ports/sysutils/cromwell; it can be flashed to the EEPROM using the /usr/ports/sysutils/raincoat port (as long as your Xbox is below version 1.6).

Note: Several Xbox drives are known to reject certain types of media. Should you experience random hangs, panics or corruption during installation, try a different known-working DVD/CD-ROM.

Installing on the hard drive

You can do an installation using the Live CD's, but you will need to do everything manually. It is suggested to prepare your disk using an FreeBSD/i386 installation and set up the /boot/xboxlinux.cfg configuration file yourself, so Cromwell can determine which kernel to load.

diff --git a/en_US.ISO8859-1/htdocs/portmgr/index.xml b/en_US.ISO8859-1/htdocs/portmgr/index.xml index 87ef720926..21a009e0ed 100644 --- a/en_US.ISO8859-1/htdocs/portmgr/index.xml +++ b/en_US.ISO8859-1/htdocs/portmgr/index.xml @@ -1,163 +1,163 @@ re@FreeBSD.org'> security-officer@FreeBSD.org'> portmgr@FreeBSD.org'> ]> &title; $FreeBSD$

The FreeBSD Ports Management Team (also known as portmgr due to its email alias) is responsible for issues relating to the FreeBSD Ports Collection.

Charter

Discusses the goals, rights, and responsibilities of the team. The contents of this document are approved by the FreeBSD Core Team.

Policies

Discusses current policies that the team has adopted to meet its goals, such as timeouts for inactivity and when commits are allowed. Also contains the policy for supported releases and branches.

Implementation Issues

Discusses how that the way that the Ports Collection is implemented affects the above policies, and, in particular, such concepts as changes that require regression tests and sweeping changes.

Quality Assurance Activities

A behind-the-scenes look at the efforts that are made to ensure that the Ports Collection works as well as it possibly can.

Team Members

portmgr@FreeBSD.org: - &a.portmgr;

+ &a.portmgr.members;

Secretary: &a.tabthorpe; (portmgr-secretary@FreeBSD.org)

Resources Of Interest To FreeBSD Contributors and Developers

Contributing to the FreeBSD Ports Collection
An introduction to how you can help contribute to the Ports Collection, by either contributing new ports or helping to fix problems in existing ports. Included is detailed information on what the community will expect from you if you volunteer to maintain one or more ports. Also includes a list of further resources.
FreeBSD Porter's Handbook
The central reference book for FreeBSD ports submitters, maintainers, and committers, mostly technically oriented. It includes both mandatory requirements and recommendations of what portmgr believes are the best approaches to common problems. one or more ports. Also includes information about keeping with changes as well.
FreeBSD Ports Build Cluster
These machines continually build packages on all possible combinations of OS release and CPU architecture (in our terminology, build environments), and produce error logs of problems that are encountered along the way.
FreeBSD Package Building Procedures
Describes the technical operation of the build cluster.
FreeBSD Release Engineering for Third Party Packages
Describes the approach used by the FreeBSD release engineering team to produce a high quality package set suitable for official FreeBSD release media, with specific emphasis on how to split up the packages for the release media, and how to verify that a package set is consistent.
FreeBSD Committer's Guide
Includes a discussion of policies and issues that are of particular interest to committers to the ports tree.
Problem Report Handling Guidelines
While primarily aimed at FreeBSD committers, this should also be read by users interested in how best to attract attention to their PRs.

Resources Of General Interest

FreshPorts
A site maintained by Dan Langille that lets you browse the state of the entire Ports Collection or any individual port within it. Includes cross-references, links, charts and graphs, and many other things. Of interest to users and developers alike.

diff --git a/en_US.ISO8859-1/htdocs/projects/summerofcode-2005.xml b/en_US.ISO8859-1/htdocs/projects/summerofcode-2005.xml index 0c14cfdf84..7594baa866 100644 --- a/en_US.ISO8859-1/htdocs/projects/summerofcode-2005.xml +++ b/en_US.ISO8859-1/htdocs/projects/summerofcode-2005.xml @@ -1,134 +1,134 @@ ]> &title; $FreeBSD$

The FreeBSD Project is proud to have taken part in the Google Summer of Code 2005. By all accounts, the FreeBSD participation in this program was an unqualified success. We received over 350 applications for student projects, amongst which 19 were selected for funding. These student projects included improved installation tools, filesystem enhancements, new utilities, and more. Many of the students have continued working on their FreeBSD projects even after the official close of the program. We are happy to see continued development in our source code repository by these talented young programmers and we look forward to working with more students in the future.

2005 Student Projects

- + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Student:	Anders Persson
Summary:	FreeBSD userland/kernel interface cleanups
Mentor:	&a.brooks; <brooks@FreeBSD.org>
Mentor:	&a.brooks.email;

Student:	Andrew Turner
Summary:	BSD Installer integration
Mentor:	&a.re;, &a.ru; <ru@FreeBSD.org>, &a.jhb; <jhb@FreeBSD.org>
Mentor:	&a.re;, &a.ru.email;, &a.jhb.email;

Student:	Brian Wilson
Summary:	UFS Journalling
Mentor:	&a.scottl; <scottl@FreeBSD.org>
Mentor:	&a.scottl.email;

Student:	Chris Jones
Summary:	Gvinum 'move', 'rename', etc..
Mentor:	&a.le; <le@FreeBSD.org>, &a.phk; <phk@FreeBSD.org>
Mentor:	&a.le.email;, &a.phk.email;

Student:	Christoph Mathys
Summary:	Rewriting CVSup in C, the Csup project
Mentor:	&a.mux; <mux@FreeBSD.org>
Mentor:	&a.mux.email;

Student:	Csaba Henk
Summary:	SSH based networking filesystem
Mentor:	&a.scottl; <scottl@FreeBSD.org>
Mentor:	&a.scottl.email;

Student:	Dario Freni
Summary:	FreeSBIE integration
Mentor:	&a.murray; <murray@FreeBSD.org> / &a.re;
Mentor:	&a.murray.email; / &a.re;

Student:	Emiliano Mennucci
Summary:	pluggable disk scheduler
Mentor:	&a.luigi; <luigi@FreeBSD.org>
Mentor:	&a.luigi.email;

Student:	Ivan Voras
Summary:	GEOM Journaling Layer (gjournal),
Mentor:	&a.phk; <phk@FreeBSD.org>, &a.pjd; <pjd@FreeBSD.org>
Mentor:	&a.phk.email;, &a.pjd.email;

Student:	Michael Bushkov
Summary:	nsswitch / caching daemon
Mentor:	&a.brooks; <brooks@FreeBSD.org>, &a.nectar; <nectar@FreeBSD.org>
Mentor:	&a.brooks.email;, &a.nectar.email;

Student:	Paolo Pisati
Summary:	libalias improvements
Mentor:	&a.luigi; <luigi@FreeBSD.org>
Mentor:	&a.luigi.email;

Student:	R. Tyler Ballance
Summary:	Implement MacOS launchd(8) for FreeBSD
Mentor:	&a.murray; <murray@FreeBSD.org>
Mentor:	&a.murray.email;

Student:	RuGang Xu
Summary:	K kernel meta-language project
Mentor:	&a.gnn; <gnn@FreeBSD.org>, &a.phk; <phk@FreeBSD.org>
Mentor:	&a.gnn.email;, &a.phk.email;

Student:	Samy Al Bahra
Summary:	Mandatory Access Control (MAC)
Mentor:	&a.rwatson; <rwatson@FreeBSD.org>
Mentor:	&a.rwatson.email;

Student:	Victor Cruceru
Summary:	SNMP monitoring
Mentor:	&a.harti; <harti@FreeBSD.org>
Mentor:	&a.harti.email;

Student:	Yanjun Wu
Summary:	SEBSD
Mentor:	&a.rwatson; <rwatson@FreeBSD.org>
Mentor:	&a.rwatson.email;

Student:	Emily Boyd
Summary:	Website improvements
Mentor:	&a.murray; <murray@FreeBSD.org>
Mentor:	&a.murray.email;

Student:	Shteryana Shopova
Summary:	bsnmp
Mentor:	&a.philip; <philip@FreeBSD.org>
Mentor:	&a.philip.email;

FreeBSD Summer of Code 2005 in the Press

FreeBSD Foundation December 2005 Newsletter
FreeBSD Summer of Code 2005 Wiki - with links to student project pages.
Dr. Dobbs Journal - Google's Summer of Code

diff --git a/en_US.ISO8859-1/htdocs/projects/summerofcode-2006.xml b/en_US.ISO8859-1/htdocs/projects/summerofcode-2006.xml index 534e5a9e56..a7a4f1cd91 100644 --- a/en_US.ISO8859-1/htdocs/projects/summerofcode-2006.xml +++ b/en_US.ISO8859-1/htdocs/projects/summerofcode-2006.xml @@ -1,389 +1,388 @@ ]> &title; $FreeBSD$

The FreeBSD Project is proud to have taken part in the Google Summer of Code again in 2006. By all accounts, the FreeBSD participation in this program was an unqualified success. We received over 150 applications for student projects, amongst which 14 were selected for funding. These student projects included security research, improved installation tools, new utilities, and more. Many of the students have continued working on their FreeBSD projects even after the official close of the program.

We are happy to report than all 14 of our students this year successfully completed the program. There were many other strong applications which we unfortunately couldn't fund and many of these students also spent the summer working on FreeBSD. We are happy to see continued development in our source code repository by these talented young programmers and we look forward to working with more students in the future.

Information about the student projects is available from our Summer of Code wiki and all of the code is checked into Perforce. The summaries below were submitted by the individual students and their mentors.

2006 Student Projects

- + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

Student:	Clement Lecigne
Summary:	IPv6 stack vulnerabilities
Mentor:	&a.gnn; <gnn@FreeBSD.org>
Mentor:	&a.gnn.email;
Summary:	The focus of this project was to review past vulnerabilities, create vulnerability testing tools and to discover new vulnerabilities in the FreeBSD IPv6 stack which is derived from the KAME project code. During the summer Clement took two libraries, the popular libnet, and his mentor's Packet Construction Set (PCS) and created tools to find security problems in the IPv6 code. Several issues were found, bugs filed, and patches created. At the moment Clement and George are editing a 50 page paper that describes the project which will be submitted for conference publication. All of the code from the project, including the tools, is on line and is described in the paper. By all measures, this was a successful project. Both student and mentor gained valuable insight into a previously externally maintained set of code. In addition to the new tools development in this effort, the FreeBSD Project now also has a new engineer to help work on the code.

Student:	Chris Jones
Summary:	Jail Resource Limits
Mentor:	&a.kmacy; <kmacy@FreeBSD.org>
Mentor:	&a.kmacy.email;
Summary:	Chris added support for limiting CPU and memory use by jails. This allows fairer sharing of systems' resources between divergent uses by preventing one jail from monopolizing the available memory and CPU time, if other users and jails have processes to run. The code is currently available as patches against `RELENG_6`, and Chris is in the process of applying it to -CURRENT. More details can be found at JailResourceLimits.

Student:	Ivan Voras
Summary:	GEOM storage virtualization (gvirstor)
Mentor:	&a.pjd; <pjd@FreeBSD.org>
Mentor:	&a.pjd.email;
Summary:	The goal of this project was to create a virtual storage class for the GEOM framework in FreeBSD that would allow creating "overcommitted" storage devices, with a size larger than that of available physical storage (e.g. hard drives). The project was completed successfully, and the result is available on the project's home page. It's expected the project will be included in FreeBSD CVS after it gets more testing or after FreeBSD 6.2 is released, whichever comes first. Working on the project was very pleasant, there was enough documentation and the mentor was very helpful and responsive. Google's team was apt and provided ample support to the participants of the project. The project will help both OEMs of embedded devices (such as NAS devices) and big users to make use of FreeBSD for large storage projects.

Student:	Paolo Pisati
Summary:	Study analyze and improve the interrupt handling infrastructure
Mentor:	&a.jhb; <jhb@FreeBSD.org>
Mentor:	&a.jhb.email;
Summary:	This project consisted in the improvement of the interrupt handling system in FreeBSD: while retaining backward compatibility with the previous models (FAST and ITHREAD), a new method called 'Interrupt filtering' was added. With interrupt filtering, the interrupt handler is divided into 2 parts: the filter (that checks if the actual interrupt belong to this device) and the ithread (that is scheduled in case some blocking work has to be done). The main benefits of interrupt filtering are: feedback from filters (the system finally knows if any handler has serviced an interrupt or not, and can react consequently). lower latency/overhead for shared interrupt line. previous experiments with interrupt filtering showed an increase in performance against the plain ithread model Moreover, during the development of interrupt filtering, some MD dependent code was converted into MI code, PPC was fixed to support multiple FAST handlers per line and an interrupt stray storm detection logic was added. While the framework is done, there are still machine dependent bits to be written (the support for ppc, sparc64, arm and itanium has to be written/reviewed) and a serious analysis of the performance of this model against the previous one is a WIP.

Student:	Yuan Jue
Summary:	Porting Xen to FreeBSD.
Mentor:	&a.kmacy; <kmacy@FreeBSD.org>
Mentor:	&a.kmacy.email;
Summary:	Successfully got a domU kernel usable for installation. dom0 support still in progress. Kip and Yuan Jue are continuing to work together on this project after the official end of SoC. Yuan Jue has published a more comprehensive FreeBSD/Xen howto here.

Student:	Adam David Alan Martin
Summary:	AutoFS - An Automounting Filesystem implementation for FreeBSD
Mentor:	&a.benno; <benno@FreeBSD.org>
Mentor:	&a.benno.email;
Summary:	Adam used PseudoFS as a starting point for an in-memory representation of an Automounter Filesystem. This involved making a few tweaks to PseudoFS to allow AutoFS to detect lookups. At this time, the filesystem works and sends signals up to a userland program. Adam plans to continue working on this, with Benno and Erez, to get AutoFS working with Erez Zadok's AMD. The goal is to merge this work into -CURRENT.

Student:	Ryan Beasley
Summary:	OSSV4 Sound support
Mentor:	&a.ariff; <ariff@FreeBSD.org>, -&a.netchild; <netchild@FreeBSD.org>
Mentor:	&a.ariff.email;, &a.netchild.email;
Summary:	This summer was spent adding support for 4Front's OSSV4 API to FreeBSD. A large number of audio ioctls were added, with a few pending, and there is still work left to do with mixers/mixer extensions (4Front's specs are still in flux) and MIDI (low priority because, IIRC, MIDI still needs maintainership). Ryan plans to continue work related to the mixer extensions as best he can while attending university full-time. All of the code is committed to FreeBSD-current.

Student:	Markus Boelter
Summary:	Bundled PXE Installer
Mentor:	&a.ps; <ps@FreeBSD.org>
Mentor:	&a.ps.email;
Summary:	For me, Google Summer of Code was a new and very exciting experience. I got actively involved in doing Open Source Software and giving something back to the community. Facing to some challenges within the project forced me to look behind the scenery of FreeBSD. The result was a better understanding of the overall system. Getting in touch with a lot of developers directly also gave a very special spirit to the Summer of Code. I really enjoyed the time and will continue to work on the project also after the deadline. For me, it was a great chance to get involved in active development and not just doing some scripts and hacks at home. Getting paid for the work was just a small part of the overall feeling. Thanks people at FreeBSD and Google for the really, really great time!

Student:	Shteryana Sotirova Shopova
Summary:	Integrated SNMP monitoring
Mentor:	&a.bz; <bz@FreeBSD.org>
Mentor:	&a.bz.email;
Summary:	After working on bsnmptools last year, Shteryana concentrated on the server side this year. An implementation for if_vlan(4) monitoring was dropped from the original proposal in favor of extended support for the new if_bridge(4) network bridge device monitoring module. In addition to RFC 4188 single bridge support and extending the kernel to get access to all the information a private MIB was designed. This was needed to be able to monitor multiple bridges supported by FreeBSD and adding an extended bridge management interface and definitely was the greatest technical challenge of the project. The project was successfully completed - including code review - and the kernel part has already been committed to CURRENT. User space part will follow soon. For STABLE a patch is available too (see wiki). Shteryana is going to continue her work on bsnmpd and is already planning support for if_vlan(4) and jails monitoring modules. We are happy that she will stay with the FreeBSD project and continue to work on bsnmp and FreeBSD after SoC. See also ShteryanaShopova and SnmpBridgeModule.

Student:	Michael Bushkov
Summary:	Nss-LDAP importing and nsswitch subsystem improvement
Mentor:	&a.ume; <ume@FreeBSD.org>
Mentor:	&a.ume.email;
Summary:	The project consisted of 5 parts: Nsswitch modules and libc separation. The idea was to move the source code for different nsswitch sources (such as "files", "dns", "nis") out of the libc into the separate shared libraries. This task was successfully finished (the patch is available). Regression tests for nsswitch. A set of regression tests to test the correctness of all nsswitch-related functions and the invariance of their behavior between system upgrades. I think that task can be considered successfully completed (the patch is available). nss_ldap rewriting. Though, this task was not clearly mentioned in the original proposal, during the SoC we found reasonable not to simply import PADL's nss_ldap, but to rewrite it from scratch (licensing issues were among the basic reasons for this). The resulting nss_ldap nsswitch module, though, behaves mostly similar to the PADL's one, has different (I believe - more flexible) architecture. Though it's basically finished, several useful features from the PADL's nss_ldap still need to be implemented. But, despite the lack of some features, I believe, that this task can be considered to be successfully completed. (Missing features will be implemented ASAP - hopefully during the September). nss_ldap importing into the base. The task was to prepare a patch, that will allow users to use nss_ldap from the base system. The task was successfully completed (the patch is available), but required to import OpenLDAP into the base in order for nss_ldap to work properly, and it had led to a long discussion in the mailing list. This discussion, however, have concluded with mostly positive opinions about nss_ldap and OpenLDAP importing. cached performance optimization. The caching daemon performance needs to be as high as possible in order for cached to be as close (in terms of speed) to "files" nsswitch source as possible. Cached's performance analysis was made and nsswitch database precaching was introduced as the optimization. This task was completed (the patch is available). However there is an area for improvements - more precise and extensive performance analysis should be made and more optimizations need to be introduces. This will be done in the nearest future. Though none of the code was committed yet into the main, official FreeBSD tree, my experience from the previous year makes me think that this situation is normal. I hope, that the code will be reviewed and committed in the coming months. More detailed information about the project can be found at LdapCachedDetailedDescription.

Student:	Roman Divacky
Summary:	Linux emulation layer update
Mentor:	&a.netchild; <netchild@FreeBSD.org>
Mentor:	&a.netchild.email;
Summary:	The goal was to implement the basics of 2.6.16 support. This has been implemented, and several programs from Fedora Core 4 work now with osrelease="2".6.16. More complex applications do expose some bugs, however. All of Roman's SoC work is in FreeBSD-current (the default compatibility is still 2.4.2) and his current focus is to fix the remaining bugs as time permits while attending university full-time. A more detailed status of what is supported and what is not can be found in the linux kernel project wiki.

Student:	Spencer Whitman
Summary:	K Kernel Meta-Language
Mentor:	&a.phk; <phk@FreeBSD.org>
Mentor:	&a.phk.email;
Summary:	Spencer investigated implementing CPP macros in the first stage of the prototype 'K' compiler. Spencer has expressed interest to continue working with us on the 'K' project.

Student:	Dongmei Liu
Summary:	Porting the seref policy and setools to SEBSD
Mentor:	&a.csjp; <csjp@FreeBSD.org>
Mentor:	&a.csjp.email;
Summary:	Dongmei Liu spent the summer working on the basic footwork required to port the SEREF policy to SEBSD. This work has been submitted and can be viewed in the soc2006/dongmei_sebsd Perforce branch. This work was originated from the sebsd branch: //depot/projects/trustedbsd/sebsd. Additionally setools-2.3 was ported from Linux and can be found in contrib/sebsd/setools directory. It is hoped that this work will be merged into the main SEBSD development branch.

Student:	Gábor Kövesdán
Student:	&a.gabor;
Summary:	Improving FreeBSD Ports Collection Infrastructure
Mentor:	&a.erwin; <erwin@FreeBSD.org>
Mentor:	&a.erwin.email;
Summary:	This project consists of the following tasks: New handling for i386 binary ports Cleanup: use ECHO_CMD and ECHO_MSG in bsd.port.mk properly Add a basic infrastructure support for debugging Installing ports with different destination (DESTDIR macro) Cleanup: Move fetch shell scripts out of bsd.port.mk Make ports respect CC and CFLAGS Cross-compiling Ports Plist generator tool The first three items are completed and the next two items are being worked on. The DESTDIR support was more complicated than presumed, so it took more time and the student didn't have time to finish the other items. Gábor will continue working on these and other ports related tasks and FreeBSD is happy to have interested him to keep working on ports and ports infrastructure. More details can be found at Gábor's Wiki page.

diff --git a/en_US.ISO8859-1/htdocs/releng/index.xml b/en_US.ISO8859-1/htdocs/releng/index.xml index b9c58a4d82..66f79e1424 100644 --- a/en_US.ISO8859-1/htdocs/releng/index.xml +++ b/en_US.ISO8859-1/htdocs/releng/index.xml @@ -1,467 +1,467 @@ re@FreeBSD.org'> security-officer@FreeBSD.org'> portmgr@FreeBSD.org'> freebsd-doc@FreeBSD.org'> doceng@FreeBSD.org'> freebsd-www@FreeBSD.org'> ]> &title; $FreeBSD$

This page contains documentation about the FreeBSD release engineering process.

Upcoming Release Schedule
Code Freeze Status
Charter for the Release Engineering Team
Release Engineering Documentation
Current Release Engineering Team
Frequently Asked Questions

Upcoming Release Schedule

NOTE: Release dates are approximate and may be subject to schedule slippage.

Date	Event	Information
June 7 2013	&os; 8.4	Released
TBD	&os; 9.2

Code-Freeze Status

The following table lists the code freeze status for the major branches of the src/ subtree of the FreeBSD Subversion repository. Commits to any branch listed as "frozen" must first be reviewed and approved by the relevant contact party. The status of other subtrees such as ports/ and doc/, is also provided below.

Branch	Status	Contact	Notes
`head`	Open	committers	Active development branch for 10-CURRENT.
`stable/9`	Open	committers	Development branch for FreeBSD 9-STABLE.
`releng/9.1`	Frozen	&contact.so;	FreeBSD 9.1 supported errata fix branch.
`releng/9.0`	Frozen	&contact.so;	FreeBSD 9.0 errata fix branch (not officially supported).
`stable/8`	Open	committers	Development branch for 8-STABLE.
`releng/8.4`	Frozen	&contact.so;	FreeBSD 8.4 supported errata fix branch.
`RELENG_8_3`	Frozen	&contact.so;	FreeBSD 8.3 supported errata fix branch.
`RELENG_8_2`	Frozen	&contact.so;	FreeBSD 8.2 errata fix branch (not officially supported).
`RELENG_8_1`	Frozen	&contact.so;	FreeBSD 8.1 errata fix branch (not officially supported).
`RELENG_8_0`	Frozen	&contact.so;	FreeBSD 8.0 errata fix branch (not officially supported).
`RELENG_7`	Open	committers	Maintenance branch for 7-STABLE (not officially supported).
`RELENG_7_4`	Frozen	&contact.so;	FreeBSD 7.4 errata fix branch (not officially supported).
`RELENG_7_3`	Frozen	&contact.so;	FreeBSD 7.3 errata fix branch (not officially supported).
`RELENG_7_2`	Frozen	&contact.so;	FreeBSD 7.2 errata fix branch (not officially supported).
`RELENG_7_1`	Frozen	&contact.so;	FreeBSD 7.1 errata fix branch (not officially supported).
`RELENG_7_0`	Frozen	&contact.so;	FreeBSD 7.0 errata fix branch (not officially supported).
`RELENG_6`	Open	committers	Maintenance branch for 6-STABLE (not officially supported).
`RELENG_6_4`	Frozen	&contact.so;	FreeBSD 6.4 errata fix branch (not officially supported).
`RELENG_6_3`	Frozen	&contact.so;	FreeBSD 6.3 errata fix branch (not officially supported).
`RELENG_6_2`	Frozen	&contact.so;	FreeBSD 6.2 errata fix branch (not officially supported).
`RELENG_6_1`	Frozen	&contact.so;	FreeBSD 6.1 errata fix branch (not officially supported).
`RELENG_6_0`	Frozen	&contact.so;	FreeBSD 6.0 errata fix branch (not officially supported).
`RELENG_5`	Open	committers	Maintenance branch for 5-STABLE (not officially supported).
`RELENG_5_5`	Frozen	&contact.so;	FreeBSD 5.5 errata fix branch (not officially supported).
`RELENG_5_4`	Frozen	&contact.so;	FreeBSD 5.4 errata fix branch (not officially supported).
`RELENG_5_3`	Frozen	&contact.so;	FreeBSD 5.3 errata fix branch (not officially supported).
`RELENG_5_2`	Frozen	&contact.so;	FreeBSD 5.2 / 5.2.1 security fix branch (not officially supported).
`RELENG_5_1`	Frozen	&contact.so;	FreeBSD 5.1 security fix branch (not officially supported).
`RELENG_5_0`	Frozen	&contact.so;	FreeBSD 5.0 security fix branch (not officially supported).
`RELENG_4`	Open	committers	Maintenance branch for 4-STABLE (not officially supported).
`RELENG_4_11`	Frozen	&contact.so;	FreeBSD 4.11 errata fix branch (not officially supported).
`RELENG_4_10`	Frozen	&contact.so;	FreeBSD 4.10 security fix branch (not officially supported).
`RELENG_4_9`	Frozen	&contact.so;	FreeBSD 4.9 security fix branch (not officially supported).
`RELENG_4_8`	Frozen	&contact.so;	FreeBSD 4.8 security fix branch (not officially supported).
`RELENG_4_7`	Frozen	&contact.so;	FreeBSD 4.7 security fix branch (not officially supported).
`RELENG_4_6`	Frozen	&contact.so;	FreeBSD 4.6 security fix branch (not officially supported).
`RELENG_4_5`	Frozen	&contact.so;	FreeBSD 4.5 security fix branch (not officially supported).
`RELENG_4_4`	Frozen	&contact.so;	FreeBSD 4.4 security fix branch (not officially supported).
`RELENG_4_3`	Frozen	&contact.so;	FreeBSD 4.3 security fix branch (not officially supported).
`RELENG_3`	Open	committers	Maintenance branch for 3-STABLE (not officially supported).
`RELENG_2_2`	Open	committers	Maintenance branch for 2.2-STABLE (not officially supported).
Subtree	Status	Contact	Notes
`ports/`	Open	&contact.portmgr;	FreeBSD Ports Collection.
`doc/`	Open	&contact.doc;	SGML/XML based documentation set.

Release Engineering Documentation

FreeBSD Release Engineering
Describes the approach used by the FreeBSD release engineering team to make production quality releases of the FreeBSD Operating System. It describes the tools available for those interested in producing customized FreeBSD releases for corporate rollouts or commercial productization.
FreeBSD Release Engineering for Third Party Packages
Describes the approach used by the FreeBSD release engineering team to produce a high quality package set suitable for official FreeBSD release media. This document is a work in progress, but eventually it will cover the process used to build a clean package set on the FreeBSD.org "Ports Cluster", how to configure any other set of machines as a ports cluster, how to split up the packages for the release media, and how to verify that a package set is consistent.

Release Engineering Team

The primary release engineering team is responsible for approving MFC requests during code freezes, setting release schedules, and all of the other responsibilities laid out in our charter.

Primary RE Team (re@FreeBSD.org) : &a.re.members; form the primary release engineering decision-making group.

The builders release engineering team is responsible for building and packaging FreeBSD releases on the various supported platforms.

Builders REs (re-builders@FreeBSD.org) : &a.re-builders;

The third party packages in the Ports Collection are managed by the portmgr@ team. Among many other responsibilities, the port managers keep the ports cluster running smoothly to produce binary packages.

Package Builders (&contact.portmgr;) : - &a.portmgr;

+ &a.portmgr.members;

Frequently Asked Questions

Where can I find the release directory or ISO images for older FreeBSD releases?

The FreeBSD Project does not maintain a centralized historical archive of old release ISO images, but there are still many options. A large collection of the old releases (many complete with the package sets) is at ftp://ftp-archive.FreeBSD.org/pub/FreeBSD-Archive/old-releases/. If you are unable to find an FTP mirror that still contains the release you are looking for, then you can email CD-ROM vendors to see if they have any old releases available. In September 2003, we know of a case where FreeBSD 1.1 was used in a court of law to invalidate a bogus software patent. Clearly, older releases can be very important in some situations.

diff --git a/en_US.ISO8859-1/htdocs/security/reporting.xml b/en_US.ISO8859-1/htdocs/security/reporting.xml index b7c16bc779..f3088e4a07 100644 --- a/en_US.ISO8859-1/htdocs/security/reporting.xml +++ b/en_US.ISO8859-1/htdocs/security/reporting.xml @@ -1,170 +1,165 @@ ]> &title; $FreeBSD$

How and where to report a FreeBSD security issue
Information about the FreeBSD Security Officer
Information handling policies
Supported FreeBSD Releases
Unsupported FreeBSD Releases

How and where to report a FreeBSD security issue

All FreeBSD security issues should be reported to the FreeBSD Security Team or, if a higher level of confidentiality is required, PGP encrypted to the Security Officer Team using the Security Officer PGP key. All reports should at least contain:

A description of the vulnerability.
What versions of FreeBSD seem to be affected if possible.
Any plausible workaround.
Example code if possible.

After this information has been reported the Security Officer or a Security Team delegate will get back to you.

Spam filters

Due to high volume of spam the main security contact mail addresses are subject to spam filtering. If you cannot contact the FreeBSD Security Officers or Security Team due to spam filters (or suspect your mail has been filtered), please send mail to security-officer-XXXX@FreeBSD.org with XXXX replaced with 3432 instead of the normal addresses. Note that this address will be changed periodically so check back here for the latest address. Mails to this address will go to the FreeBSD Security Officer Team.

The FreeBSD Security Officer Team and the FreeBSD Security Team

In order that the FreeBSD Project may respond to vulnerability reports in a timely manner, emails sent to the <security-officer@FreeBSD.org> mail alias are currently delivered to the following people:

- + - + - + - + - +

&a.des; <des@FreeBSD.org>	&a.des.email;	Security Officer
&a.delphij; <delphij@FreeBSD.org>	&a.delphij.email;	Deputy Security Officer
&a.simon; <simon@FreeBSD.org>	&a.simon.email;	Security Officer Emeritus
&a.cperciva; <cperciva@FreeBSD.org>	&a.cperciva.email;	Security Officer Emeritus
&a.rwatson; <rwatson@FreeBSD.org>	&a.rwatson.email;	Release Engineering liaison, TrustedBSD Project liaison, system security architecture expert

The Security Officer is supported by the FreeBSD Security Team, <secteam@FreeBSD.org>, a small group of committers vetted by the Security Officer.

Information handling policies

As a general policy, the FreeBSD Security Officer favors full disclosure of vulnerability information after a reasonable delay to permit safe analysis and correction of a vulnerability, as well as appropriate testing of the correction, and appropriate coordination with other affected parties.

The Security Officer will notify one or more of the FreeBSD Cluster Admins of vulnerabilities that put the FreeBSD Project's resources under immediate danger.

The Security Officer may bring additional FreeBSD developers or outside developers into discussion of a submitted security vulnerability if their expertise is required to fully understand or correct the problem. Appropriate discretion will be exercised to minimize unnecessary distribution of information about the submitted vulnerability, and any experts brought in will act in accordance of Security Officer policies. In the past, experts have been brought in based on extensive experience with highly complex components of the operating system, including FFS, the VM system, and the network stack.

If a FreeBSD release process is underway, the FreeBSD Release Engineer may also be notified that a vulnerability exists, and its severity, so that informed decisions may be made regarding the release cycle and any serious security bugs present in software associated with an up-coming release. If requested, the Security Officer will not share information regarding the nature of the vulnerability with the Release Engineer, limiting information flow to existence and severity.

The FreeBSD Security Officer has close working relationships with a number of other organizations, including third-party vendors that share code with FreeBSD (the OpenBSD, NetBSD and DragonFlyBSD projects, Apple, and other vendors deriving software from FreeBSD, as well as the Linux vendor security list), as well as organizations that track vulnerabilities and security incidents, such as CERT. Frequently vulnerabilities may extend beyond the scope of the FreeBSD implementation, and (perhaps less frequently) may have broad implications for the global networking community. Under such circumstances, the Security Officer may wish to disclose vulnerability information to these other organizations: if you do not wish the Security Officer to do this, please indicate so explicitly in any submissions.

Submitters should be careful to explicitly document any special information handling requirements.

If the submitter of a vulnerability is interested in a coordinated disclosure process with the submitter and/or other vendors, this should be indicated explicitly in any submissions. In the absence of explicit requests, the FreeBSD Security Officer will select a disclosure schedule that reflects both a desire for timely disclosure and appropriate testing of any solutions. Submitters should be aware that if the vulnerability is being actively discussed in public forums (such as bugtraq), and actively exploited, the Security Officer may choose not to follow a proposed disclosure timeline in order to provide maximum protection for the user community.

Submissions may be protected using PGP. If desired, responses will also be protected using PGP.

diff --git a/en_US.ISO8859-1/share/xml/mailing-lists.ent b/en_US.ISO8859-1/share/xml/mailing-lists.ent index 702b344988..5f3bea757d 100644 --- a/en_US.ISO8859-1/share/xml/mailing-lists.ent +++ b/en_US.ISO8859-1/share/xml/mailing-lists.ent @@ -1,623 +1,622 @@ FreeBSD list server"> &a.mailman.listinfo;"> FreeBSD ACPI mailing list"> freebsd-acpi"> FreeBSD advocacy mailing list"> freebsd-advocacy"> FreeBSD AFS porting mailing list"> freebsd-afs"> FreeBSD Adaptec AIC7xxx discussions mailing list"> freebsd-aic7xxx"> Porting FreeBSD to AMD64 systems"> freebsd-amd64"> FreeBSD announcements mailing list"> freebsd-announce"> FreeBSD Apache mailing list"> freebsd-apache"> FreeBSD architecture and design mailing list"> freebsd-arch"> FreeBSD ARM porting mailing list"> freebsd-arm"> FreeBSD ATM networking mailing list"> freebsd-atm"> FreeBSD Bluetooth mailing list"> freebsd-bluetooth"> FreeBSD bugbusters mailing list"> freebsd-bugbusters"> FreeBSD problem reports mailing list"> freebsd-bugs"> FreeBSD chat mailing list"> freebsd-chat"> FreeBSD-specific Chromium issues"> freebsd-chromium"> FreeBSD clustering mailing list"> freebsd-cluster"> - &os.current; mailing list"> freebsd-current"> CTM announcements"> ctm-announce"> CTM 4-STABLE src branch distribution mailing list"> ctm-src-4"> CTM 5-STABLE src branch distribution mailing list"> ctm-src-5"> CTM 6-STABLE src branch distribution mailing list"> ctm-src-6"> CTM 7-STABLE src branch distribution mailing list"> ctm-src-7"> CTM 8-STABLE src branch distribution mailing list"> ctm-src-8"> CTM 9-STABLE src branch distribution mailing list"> ctm-src-9"> CTM -CURRENT src branch distribution mailing list"> ctm-src-cur"> CTM user discussion mailing list"> ctm-users"> FreeBSD CVS commit message mailing list"> cvs-all"> FreeBSD CVS doc commit list"> cvs-doc"> FreeBSD CVS ports commit list"> cvs-ports"> FreeBSD CVS projects commit list"> cvs-projects"> FreeBSD CVS src commit list"> cvs-src"> FreeBSD CVSweb maintenance mailing list"> freebsd-cvsweb"> FreeBSD based Databases mailing list"> freebsd-database"> Using and improving &os; on the desktop"> freebsd-desktop"> FreeBSD documentation project mailing list"> freebsd-doc"> Writing device drivers for FreeBSD"> freebsd-drivers"> Using and working on DTrace in &os;."> freebsd-dtrace"> FreeBSD users of Eclipse IDE, tools, rich client applications and ports"> freebsd-eclipse"> FreeBSD-embedded mailing list"> freebsd-embedded"> FreeBSD-emulation mailing list"> freebsd-emulation"> FreeBSD-eol mailing list"> freebsd-eol"> FreeBSD FireWire (IEEE 1394) discussion mailing list"> freebsd-firewire"> Fortran on FreeBSD mailing list"> freebsd-fortran"> FreeBSD file system project mailing list"> freebsd-fs"> FreeBSD gecko mailing list"> freebsd-gecko"> FreeBSD GEOM mailing list"> freebsd-geom"> FreeBSD GNOME and GNOME applications mailing list"> freebsd-gnome"> FreeBSD technical discussions mailing list"> freebsd-hackers"> FreeBSD hardware and equipment mailing list"> freebsd-hardware"> FreeBSD mirror sites mailing lists"> freebsd-hubs"> FreeBSD internationalization mailing list"> freebsd-i18n"> FreeBSD i386-specific issues mailing list"> freebsd-i386"> FreeBSD IA32 porting mailing list"> freebsd-ia32"> FreeBSD IA64 porting mailing list"> freebsd-ia64"> Infiniband on FreeBSD"> freebsd-infiniband"> FreeBSD IPFW code mailing list"> freebsd-ipfw"> FreeBSD ISDN mailing list"> freebsd-isdn"> FreeBSD Internet service provider's mailing list"> freebsd-isp"> FreeBSD jails mailing list"> freebsd-jail"> FreeBSD Java Language mailing list"> freebsd-java"> FreeBSD related employment mailing list"> freebsd-jobs"> FreeBSD KDE/Qt and KDE applications mailing list"> freebsd-kde"> FreeBSD LFS porting mailing list"> freebsd-lfs"> FreeBSD MIPS porting mailing list"> freebsd-mips"> FreeBSD mirror site administrators"> mirror-announce"> FreeBSD laptop computer mailing list"> freebsd-mobile"> Mono and C# applications on FreeBSD"> freebsd-mono"> FreeBSD port of the Mozilla browser mailing list"> freebsd-mozilla"> FreeBSD multimedia mailing list"> freebsd-multimedia"> FreeBSD networking mailing list"> freebsd-net"> FreeBSD new users mailing list"> freebsd-newbies"> FreeBSD new-bus mailing list"> freebsd-new-bus"> Discussions of high quality implementation of libm functions"> freebsd-numerics"> Office applications on FreeBSD"> freebsd-office"> Project Infrastructure Announcements"> freebsd-ops-announce"> FreeBSD performance mailing list"> freebsd-performance"> FreeBSD Perl mailing list"> freebsd-perl"> FreeBSD packet filter mailing list"> freebsd-pf"> Binary package management and package tools discussion"> freebsd-pkg"> FreeBSD non-Intel platforms porting mailing list"> freebsd-platforms"> FreeBSD ports mailing list"> freebsd-ports"> FreeBSD ports announce mailing list"> freebsd-ports-announce"> FreeBSD ports bugs mailing list"> freebsd-ports-bugs"> FreeBSD PowerPC porting mailing list"> freebsd-ppc"> Technical discussion of FreeBSD on HP ProLiant server platforms"> freebsd-proliant"> FreeBSD Python mailing list"> freebsd-python"> FreeBSD general questions mailing list"> freebsd-questions"> FreeBSD boot script system mailing list"> freebsd-rc"> FreeBSD realtime extensions mailing list"> freebsd-realtime"> FreeBSD Ruby mailing list"> freebsd-ruby"> FreeBSD SCSI subsystem mailing list"> freebsd-scsi"> FreeBSD security mailing list"> freebsd-security"> FreeBSD security notifications mailing list"> freebsd-security-notifications"> FreeBSD-small mailing list"> freebsd-small"> FreeBSD Development Snapshot Announcements"> freebsd-snapshots"> FreeBSD SPARC porting mailing list"> freebsd-sparc64"> &os.stable; mailing list"> freebsd-stable"> FreeBSD C99 and POSIX compliance mailing list"> freebsd-standards"> FreeBSD sun4v porting mailing list"> freebsd-sun4v"> SVN commit messages for the entire doc tree (except for user, projects and translations)"> svn-doc-all"> SVN commit messages for the doc tree for head/"> svn-doc-head"> SVN commit messages for the doc projects tree"> svn-doc-projects"> SVN commit messages for the doc admin / configuration tree"> svn-doc-svnadmin"> SVN commit messages for the entire ports tree"> svn-ports-all"> SVN commit messages for the ports tree for head/"> svn-ports-head"> SVN commit messages for the ports admin / configuration tree"> svn-ports-svnadmin"> SVN commit messages for the entire src tree (except for user and projects)"> svn-src-all"> SVN commit messages for the src tree for head/-current"> svn-src-head"> SVN commit messages for the src projects tree"> svn-src-projects"> SVN commit messages for releases in the src tree"> svn-src-release"> SVN commit messages for the release engineering / security commits to the src tree"> svn-src-releng"> SVN commit messages for all the -stable branches of the src tree"> svn-src-stable"> SVN commit messages for only the 6-stable src tree"> svn-src-stable-6"> SVN commit messages for only the 7-stable src tree"> svn-src-stable-7"> SVN commit messages for only the 8-stable src tree"> svn-src-stable-8"> SVN commit messages for only the 9-stable src tree"> svn-src-stable-9"> SVN commit messages for the old stable src trees"> svn-src-stable-other"> SVN commit messages for the admin / configuration tree"> svn-src-svnadmin"> SVN commit messages for the experimental user src tree"> svn-src-user"> SVN commit messages for the vendor work area tree"> svn-src-vendor"> Sysinstall development mailing list"> freebsd-sysinstall"> FreeBSD-specific Tcl/Tk discussions"> freebsd-tcltk"> FreeBSD test mailing list"> freebsd-test"> Testing on &os;"> freebsd-testing"> Porting TeX and its applications to &os;"> freebsd-tex"> FreeBSD threads mailing list"> freebsd-threads"> Porting FreeBSD to the Tilera family of CPUs"> freebsd-tilera"> FreeBSD tokenring mailing list"> freebsd-tokenring"> FreeBSD integrated toolchain mailing list"> freebsd-toolchain"> FreeBSD USB mailing list"> freebsd-usb"> FreeBSD user group coordination mailing list"> freebsd-user-groups"> FreeBSD vendors pre-release coordination mailing list"> freebsd-vendors"> Discussion of various virtualization techniques supported by FreeBSD"> freebsd-virtualization"> Discussion on the VuXML infrastructure"> freebsd-vuxml"> FreeBSD Work-In-Progress Status"> freebsd-wip-status"> Discussions of 802.11 stack, tools, device driver development"> freebsd-wireless"> FreeBSD Webmaster mailing list"> freebsd-www"> FreeBSD X11 mailing list"> freebsd-x11"> FreeBSD port to Xen mailing list"> freebsd-xen"> XFCE for FreeBSD mailing list"> freebsd-xfce"> Zope for FreeBSD mailing list"> freebsd-zope"> bug-followup@FreeBSD.org"> majordomo@FreeBSD.org"> FreeBSD Alpha porting mailing list"> freebsd-alpha"> FreeBSD Quality Assurance mailing list"> freebsd-qa"> FreeBSD symmetric multiprocessing mailing list"> freebsd-smp"> diff --git a/en_US.ISO8859-1/share/xml/teams.ent b/en_US.ISO8859-1/share/xml/teams.ent index 9459a02d6a..8b308e2f0f 100644 --- a/en_US.ISO8859-1/share/xml/teams.ent +++ b/en_US.ISO8859-1/share/xml/teams.ent @@ -1,52 +1,54 @@ admins@FreeBSD.org"> bugmeister@FreeBSD.org"> +core@FreeBSD.org"> + core-secretary@FreeBSD.org"> cvsadm@FreeBSD.org"> cvsup-master@FreeBSD.org"> doceng@FreeBSD.org"> donations@FreeBSD.org"> faq@FreeBSD.org"> ftp-master@FreeBSD.org"> mirror-admin@FreeBSD.org"> ncvs@FreeBSD.org"> perforce-admin@FreeBSD.org"> pcvs@FreeBSD.org"> portmgr@FreeBSD.org"> portmgr-secretary@FreeBSD.org"> projcvs@FreeBSD.org"> re@FreeBSD.org"> security-officer@FreeBSD.org"> diff --git a/fr_FR.ISO8859-1/htdocs/releng/index.xml b/fr_FR.ISO8859-1/htdocs/releng/index.xml index c93400c082..c939f4fedf 100644 --- a/fr_FR.ISO8859-1/htdocs/releng/index.xml +++ b/fr_FR.ISO8859-1/htdocs/releng/index.xml @@ -1,335 +1,335 @@ re@FreeBSD.org'> security-officer@FreeBSD.org'> portmgr@FreeBSD.org'> ]> &title; $FreeBSD$

Cette page contient de la documentation sur le processus de sortie des versions de FreeBSD.

Programme de sortie des prochaines versions
Statut du gel du code source
Charte pour l'équipe de développement
Documentation à propos de la sortie de nouvelles versions
Equipe de développement actuelle
Foire aux questions

Programme de sortie des prochaines versions

NOTE : Les dates de sorties sont approximatives et peuvent être sujettes à modification.

30 Janvier 2006: Gel de RELENG_5 et RELENG_6
20 Mars 2006: FreeBSD 6.1
3 Avril 2006: FreeBSD 5.5
12 Juin 2006: Gel de RELENG_6
31 Juillet 2006: FreeBSD 6.2
23 Octobre 2006: Gel de RELENG_6
11 Décembre 2006: FreeBSD 6.3

Statut du gel du code source

Le tableau suivant recense la liste des statuts du gel du code source pour les principales branches du répertoire src/ du dépôt CVS FreeBSD. Toute demande de participation dans une branche marquée comme "gelée" doit d'abord être examinée et approuvée par le contact de l'équipe correspondante. Le statut des autres arborescences comme ports/, doc/ et www/ est également fourni ci-dessous.

Branche	Statut	Contact	Notes
`HEAD`	Ouvert	committers	Branche active de développement -CURRENT.
`RELENG_6`	Ouvert	committers	Branche de développement 6-STABLE.
`RELENG_6_0`	Gelé	&contact.so;	Branche supportée pour les correctifs de FreeBSD 6.0
`RELENG_5`	Ouvert	committers	Branche de développement 5-STABLE.
`RELENG_5_4`	Gelé	&contact.so;	Branche supportée pour les correctifs de FreeBSD 5.4 (politique sur les correctifs)
`RELENG_5_3`	Gelé	&contact.so;	Branche supportée pour les correctifs de FreeBSD 5.3 (politique sur les correctifs)
`RELENG_5_2`	Gelé	&contact.so;	Branche pour les corrections liées à la sécurité de FreeBSD 5.2 / 5.2.1 (n'est pas supportée officiellement).
`RELENG_5_1`	Gelé	&contact.so;	Branche avec corrections liées à la sécurité de FreeBSD 5.1 (n'est pas supportée officiellement).
`RELENG_5_0`	Gelé	&contact.so;	Branche avec corrections liées à la sécurité de FreeBSD 5.0 (n'est pas supportée officiellement).
`RELENG_4`	Ouvert	committers	Branche de développement de 4-STABLE.
`RELENG_4_11`	Gelé	&contact.so;	Branche supportée pour les correctifs de FreeBSD 4.11 (politique sur les correctifs)
`RELENG_4_10`	Gelé	&contact.so;	Branche supportée pour les correctifs de FreeBSD 4.10.
`RELENG_4_9`	Gelé	&contact.so;	Branche pour les corrections liées à la sécurité de FreeBSD 4.9 (n'est pas supportée officiellement).
`RELENG_4_8`	Gelé	&contact.so;	Branche pour les corrections liées à la sécurité de FreeBSD 4.8 (n'est pas supportée officiellement).
`RELENG_4_7`	Gelé	&contact.so;	Branche pour les corrections liées à la sécurité de FreeBSD 4.7 (n'est pas supportée officiellement).
`RELENG_4_6`	Gelé	&contact.so;	Branche les corrections liées à la sécurité de FreeBSD 4.6 (n'est pas supportée officiellement).
`RELENG_4_5`	Gelé	&contact.so;	Branche pour les corrections liées à la sécurité de FreeBSD 4.5 (n'est pas supportée officiellement).
`RELENG_4_4`	Gelé	&contact.so;	Branche pour les corrections liées à la sécurité de FreeBSD 4.4 (n'est pas supportée officiellement).
`RELENG_4_3`	Gelé	&contact.so;	Branche pour les corrections liées à la sécurité de FreeBSD 4.3 (n'est pas supportée officiellement).
`RELENG_3`	Ouvert	committers	Branche de maintenance pour 3-STABLE (n'est pas supportée officiellement).
`RELENG_2_2`	Ouvert	committers	Branche de maintenance pour 2.2-STABLE (n'est pas supportée officiellement).
Arborescence	Statut	Contact	Notes
`ports/`	Ouvert	&contact.portmgr;	Collection des Ports FreeBSD.
`doc/`	Ouvert	freebsd-doc	Ensemble de documentation SGML/XML.
`www/`	Ouvert	freebsd-doc	Sources du site web FreeBSD.

Documentation à propos de la sortie de nouvelles versions

Processus de création des versions de FreeBSD
Décrit l'approche utilisée par l'équipe chargée de la création des versions de FreeBSD pour que ces nouvelles versions soient toujours de la même qualité. Il décrit les outils disponibles pour les personnes intéressées par la création d'une version personnalisée de FreeBSD dans le cadre d'une entreprise ou pour une production commerciale.
Versions de FreeBSD / Logiciels tiers (paquetages)
Décrit l'approche utilisée par l'équipe chargée de la création des versions de FreeBSD pour proposer un ensemble de paquetages de grande qualité adapté au cd-rom de la version officielle de FreeBSD. Ce document est en cours d'élaboration et, à terme, couvrira le processus utilisé pour compiler l'ensemble des paquetages sur le "Cluster de Ports" de FreeBSD.org, comment configurer un groupe de machines pour en faire un "cluster de ports", comment regrouper les paquetages pour le media utilisé et comment vérifier la cohérence d'un ensemble de paquetages.

Equipe chargée de la sortie des nouvelles versions

L'équipe principale est chargée d'accepter ou non les requêtes MFC pendant les périodes où le code source ne doit plus être modifié, d'établir le calendrier des sorties et de toutes les autres responsabilités décrites dans notre charte.

Equipe principale (re@FreeBSD.org) : &a.re.members; forment le groupe décisionnaire.

L'équipe de compilation des nouvelles versions est responsable de la compilation du système et de la génération des nouvelles versions pour les plate-formes supportées.

Développeurs de l'équipe de compilation (re-builders@FreeBSD.org): &a.re-builders;

Les logiciels tiers (paquetages) de la collection des ports sont gérés par l'équipe portmgr@. Les responsables des ports sont notamment chargés de vérifier que le cluster de ports peut générer les paquetages binaires sans problème.

Génération des paquetages (portmgr@FreeBSD.org) : -&a.portmgr;

+&a.portmgr.members;

Foire aux Questions

Où puis-je trouver le répertoire de la version actuelle ou les images ISO des versions plus anciennes de FreeBSD ?

Le projet FreeBSD ne maintient pas une archive centralisée des images ISO de précédentes versions mais il existe cependant plusieurs possibilités : une collection importante d'anciennes versions (dont certaines incluant des collections complètes de paquetages) se trouve à ftp://ftp-archive.FreeBSD.org/pub/FreeBSD-Archive/old-releases/. Ensuite, explorez http://mirrorlist.FreeBSD.org. Si vous ne trouvez pas un miroir FTP qui contient encore la version que vous recherchez, vous pouvez envoyer un courrier électronique aux distributeurs de cédéroms pour savoir s'ils disposent toujours d'anciennes versions. En septembre 2003, nous avons entendu parler d'un cas où FreeBSD 1.1 a été utilisé dans un tribunal pour invalider un brevet logiciel bidon. Les vieilles versions peuvent être clairement très importantes dans certaines situations.

diff --git a/ru_RU.KOI8-R/htdocs/portmgr/index.xml b/ru_RU.KOI8-R/htdocs/portmgr/index.xml index aa527fb94a..fb0d63bacf 100644 --- a/ru_RU.KOI8-R/htdocs/portmgr/index.xml +++ b/ru_RU.KOI8-R/htdocs/portmgr/index.xml @@ -1,126 +1,126 @@ re@FreeBSD.org'> security-officer@FreeBSD.org'> portmgr@FreeBSD.org'> ]> &title; $FreeBSD$

çÒÕÐÐÁ ÕÐÒÁ×ÌÅÎÉÑ ÐÏÒÔÁÍÉ FreeBSD (ËÏÔÏÒÕÀ ÔÁËÖÅ ÎÁÚÙ×ÁÀÔ ËÒÁÔËÏ portmgr ÉÚ-ÚÁ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÇÏ ÁÄÒÅÓÁ ÜÌÅËÔÒÏÎÎÏÊ ÐÏÞÔÙ) ÏÔ×ÅÞÁÅÔ ÚÁ ×ÏÐÒÏÓÙ, ÉÍÅÀÝÉÅ ÏÔÎÏÛÅÎÉÅ Ë ëÏÌÌÅËÃÉÉ ðÏÒÔÏ× FreeBSD.

õÓÔÁ×

ïÐÉÓÁÎÙ ÃÅÌÉ, ÐÒÁ×Á É ÏÔ×ÅÔÓÔ×ÅÎÎÏÓÔØ ÜÔÏÊ ÇÒÕÐÐÙ. óÏÄÅÒÖÁÎÉÅ ÜÔÏÇÏ ÄÏËÕÍÅÎÔÁ ÓÏÇÌÁÓÏ×ÁÎÏ Ó õÐÒÁ×ÌÑÀÝÉÍ ÓÏ×ÅÔÏÍ FreeBSD.

ðÒÁ×ÉÌÁ

ïÐÉÓÁÎÙ ÔÅËÕÝÉÅ ÐÒÁ×ÉÌÁ, ËÏÔÏÒÙÍ ÓÌÅÄÕÅÔ ÇÒÕÐÐÁ ÄÌÑ ÒÅÁÌÉÚÁÃÉÉ Ó×ÏÉÈ ÚÁÄÁÞ.

òÁÂÏÔÙ ÐÏ ËÏÎÔÒÏÌÀ ËÁÞÅÓÔ×Á

÷ÚÇÌÑÄ ÉÚÎÕÔÒÉ ÎÁ ÔÅ ÕÓÉÌÉÑ, ËÏÔÏÒÙÅ ÐÒÅÄÐÒÉÎÉÍÁÀÔÓÑ ÄÌÑ ÏÂÅÓÐÅÞÅÎÉÑ ÍÁËÓÉÍÁÌØÎÏ ËÁÞÅÓÔ×ÅÎÎÏÊ ÒÁÂÏÔÙ ëÏÌÌÅËÃÉÉ ðÏÒÔÏ×.

õÞÁÓÔÎÉËÉ ÇÒÕÐÐÙ

portmgr@FreeBSD.org: - &a.portmgr;

+ &a.portmgr.members;

óÅËÒÅÔÁÒØ: &a.erwin;

äÏËÕÍÅÎÔÁÃÉÑ, ÉÍÅÀÝÁÑ ÏÔÎÏÛÅÎÉÅ Ë ÄÅÌÕ

òÕËÏ×ÏÄÓÔ×Ï ÐÏ ÓÏÚÄÁÎÉÀ ÐÏÒÔÏ× FreeBSD
ïÂÝÅÅ ÒÕËÏ×ÏÄÓÔ×Ï ÄÌÑ ËÏÍÍÉÔÔÅÒÏ× ÐÏÒÔÏ× FreeBSD, × ËÏÔÏÒÏÍ ÐÒÉÓÕÔÓÔ×ÕÅÔ ËÁË ÔÅÈÎÉÞÅÓËÁÑ ÉÎÆÏÒÍÁÃÉÑ, ÔÁË É ÒÅËÏÍÅÎÄÁÃÉÉ ÐÏ ÏÒÇÁÎÉÚÁÃÉÉ ÒÁÂÏÔ.
ëÌÁÓÔÅÒ ÐÏÓÔÒÏÅÎÉÑ ÐÏÒÔÏ× FreeBSD
üÔÉ ÍÁÛÉÎÙ ÐÏÓÔÏÑÎÎÏ ÓÔÒÏÑÔ ÐÁËÁÄÖÉ ÄÌÑ ×ÓÅÈ ×ÏÚÍÏÖÎÙÈ ËÏÍÂÉÎÁÃÉÊ ÒÅÌÉÚÏ× ïó É ÐÒÏÃÅÓÓÏÒÎÙÈ ÁÒÈÉÔÅËÔÕÒ (ÐÏ ÎÁÛÅÊ ÔÅÒÍÉÎÏÌÏÇÉÉ, ÓÒÅÄ ÐÏÓÔÒÏÅÎÉÑ) É ÇÅÎÅÒÉÒÕÀÔ ÐÒÏÔÏËÏÌÙ ÏÛÉÂÏË, ÏÔÒÁÖÁÀÝÉÅ ÐÒÏÂÌÅÍÙ, ËÏÔÏÒÙÅ ×ÓÔÒÅÔÉÌÉÓØ × ÐÒÏÃÅÓÓÅ ÐÏÓÔÒÏÅÎÉÑ.
ðÒÏÃÅÄÕÒÙ ÐÏÓÔÒÏÅÎÉÑ ÐÁËÁÄÖÅÊ FreeBSD
ïÐÉÓÙ×ÁÅÔ ÔÅÈÎÉÞÅÓËÕÀ ÏÒÇÁÎÉÚÁÃÉÀ ËÌÁÓÔÅÒÁ ÐÏÓÔÒÏÅÎÉÑ.
ðÏÄÇÏÔÏ×ËÁ ÒÅÌÉÚÏ× FreeBSD ÄÌÑ ÐÁËÁÄÖÅÊ ÓÔÏÒÏÎÎÉÈ ÒÁÚÒÁÂÏÔÞÉËÏ×
ïÐÉÓÙ×ÁÅÔ ÐÏÄÈÏÄÙ, ÉÓÐÏÌØÚÕÅÍÙÅ ÇÒÕÐÐÏÊ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ× FreeBSD ÄÌÑ ÓÏÚÄÁÎÉÑ ×ÙÓÏËÏËÁÞÅÓÔ×ÅÎÎÏÇÏ ÎÁÂÏÒÁ ÐÁËÁÄÖÅÊ, ÐÏÄÈÏÄÑÝÅÇÏ ÄÌÑ ÒÁÚÍÅÝÅÎÉÑ ÎÁ ÎÏÓÉÔÅÌÑÈ Ó ÏÆÉÃÉÁÌØÎÙÍÉ ÒÅÌÉÚÁÍÉ. ïÓÏÂÏÅ ×ÎÉÍÁÎÉÅ ÕÄÅÌÅÎÏ ÔÏÍÕ, ËÁË ÐÏÄÇÏÔÏ×ÉÔØ ÐÁËÁÄÖÉ ÄÌÑ ÒÁÚÍÅÝÅÎÉÑ ÎÁ ÎÏÓÉÔÅÌÑÈ É ËÁË ÐÒÏ×ÅÒÉÔØ ÃÅÌÏÓÔÎÏÓÔØ ÎÁÂÏÒÁ ÐÁËÁÄÖÅÊ.
òÕËÏ×ÏÄÓÔ×Ï ËÏÍÍÉÔÔÅÒÁ FreeBSD
÷ËÌÀÞÁÅÔ ÏÐÉÓÁÎÉÅ ÐÒÁ×ÉÌ É ÐÒÏÂÌÅÍ, ËÏÔÏÒÙÅ ÐÒÅÄÓÔÁ×ÌÑÀÔ ÏÓÏÂÙÊ ÉÎÔÅÒÅÓ ÄÌÑ ËÏÍÍÉÔÔÅÒÏ×, ÚÁÎÉÍÁÀÝÉÈÓÑ ÄÅÒÅ×ÏÍ ÐÏÒÔÏ×.
òÅËÏÍÅÎÄÁÃÉÉ ÐÏ ÒÁÂÏÔÅ Ó ÓÏÏÂÝÅÎÉÑÍÉ Ï ÐÒÏÂÌÅÍÁÈ
èÏÔÑ ÜÔÏÔ ÄÏËÕÍÅÎÔ × ÐÅÒ×ÕÀ ÏÞÅÒÅÄØ ÁÄÒÅÓÏ×ÁÎ ËÏÍÍÉÔÔÅÒÁÍ FreeBSD, ÏÎ ÄÏÌÖÅÎ ÂÙÔØ ÐÒÏÞÉÔÁÎ ÐÏÌØÚÏ×ÁÔÅÌÑÍÉ, ÉÎÔÅÒÅÓÕÀÝÉÍÉÓÑ ÔÅÍ, ËÁË ÜÆÆÅËÔÉ×ÎÅÅ ×ÓÅÇÏ ÐÒÉ×ÌÅÞØ ×ÎÉÍÁÎÉÅ Ë Ó×ÏÉÍ PR.

diff --git a/ru_RU.KOI8-R/htdocs/releng/index.xml b/ru_RU.KOI8-R/htdocs/releng/index.xml index ecbcc51c6a..54acf2086a 100644 --- a/ru_RU.KOI8-R/htdocs/releng/index.xml +++ b/ru_RU.KOI8-R/htdocs/releng/index.xml @@ -1,499 +1,499 @@ re@FreeBSD.org'> security-officer@FreeBSD.org'> portmgr@FreeBSD.org'> freebsd-doc@FreeBSD.org'> doceng@FreeBSD.org'> freebsd-www@FreeBSD.org'> ]> &title; $FreeBSD$

îÁ ÜÔÏÊ ÓÔÒÁÎÉÃÅ ÎÁÈÏÄÉÔÓÑ ÉÎÆÏÒÍÁÃÉÑ Ï ÐÒÏÃÅÓÓÅ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ× FreeBSD.

çÒÁÆÉË ÐÒÅÄÓÔÏÑÝÉÈ ÒÅÌÉÚÏ×
óÏÓÔÏÑÎÉÅ ÚÁÍÏÒÏÚËÉ ËÏÄÁ
ïÂÑÚÁÎÎÏÓÔÉ ÕÞÁÓÔÎÉËÏ× çÒÕÐÐÙ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ×
äÏËÕÍÅÎÔÁÃÉÑ ÐÏ ÐÏÄÇÏÔÏ×ËÅ ÒÅÌÉÚÏ×
ëÏÍÁÎÄÁ ÐÏÄÇÏÔÏ×ËÉ ÔÅËÕÝÅÇÏ ÒÅÌÉÚÁ
þÁÓÔÏ ÚÁÄÁ×ÁÅÍÙÅ ×ÏÐÒÏÓÙ

çÒÁÆÉË ÐÒÅÄÓÔÏÑÝÉÈ ÒÅÌÉÚÏ×

ðòéíåþáîéå: äÁÔÙ ÐÒÅÄÓÔÏÑÝÉÈ ÒÅÌÉÚÏ× ÄÁÎÙ ÐÒÉÂÌÉÚÉÔÅÌØÎÏ É ÍÏÇÕÔ ÉÚÍÅÎÑÔØÓÑ ÐÏ ÈÏÄÕ ÒÁÂÏÔ.

äÁÔÁ	óÏÂÙÔÉÅ	éÎÆÏÒÍÁÃÉÑ
TBD	&os; 8.4	òÁÓÐÉÓÁÎÉÅ ×ÙÐÕÓËÁ
TBD	&os; 9.2

óÏÓÔÏÑÎÉÅ ÚÁÍÏÒÏÚËÉ ËÏÄÁ

÷ ÓÌÅÄÕÀÝÅÊ ÔÁÂÌÉÃÅ ÄÁÎÏ ÓÏÓÔÏÑÎÉÅ ÚÁÍÏÒÏÚËÉ ËÏÄÁ ÄÌÑ ÏÓÎÏ×ÎÙÈ ×ÅÔÏË ÐÏÄÄÅÒÅ×Á src/ CVS-ÈÒÁÎÉÌÉÝÁ FreeBSD. ÷ÓÅ ÉÚÍÅÎÅÎÉÑ × ÌÀÂÕÀ ÉÚ ×ÅÔÏË, ÐÏÍÅÞÅÎÎÙÈ ËÁË "ÚÁÍÏÒÏÖÅÎÏ", ÓÎÁÞÁÌÁ ÄÏÌÖÎÙ ÂÙÔØ ÐÒÏÓÍÏÔÒÅÎÙ É ÐÏÄÔ×ÅÒÖÄÅÎÙ ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÊ ËÏÎÔÁËÔÎÏÊ ÐÅÒÓÏÎÏÊ. óÏÓÔÏÑÎÉÑ ÄÒÕÇÉÈ ÐÏÄÄÅÒÅ×ØÅ×, ÔÁËÉÈ ËÁË ports/ É doc/, ÔÁËÖÅ ÄÁÎÙ ÎÉÖÅ.

÷ÅÔËÁ	óÏÓÔÏÑÎÉÅ	ëÏÎÔÁËÔ	úÁÍÅÞÁÎÉÑ
`HEAD`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	áËÔÉ×ÎÁÑ ×ÅÔËÁ ÒÁÚÒÁÂÏÔËÉ 10-CURRENT.
`stable/9`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	÷ÅÔËÁ ÒÁÚÒÁÂÏÔËÉ 9-STABLE.
`releng/9.1`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	ðÏÄÄÅÒÖÉ×ÁÅÍÁÑ ×ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 9.1.
`releng/9.0`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	ðÏÄÄÅÒÖÉ×ÁÅÍÁÑ ×ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 9.0.
`RELENG_8`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	÷ÅÔËÁ ÒÁÚÒÁÂÏÔËÉ 8-STABLE.
`RELENG_8_3`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	ðÏÄÄÅÒÖÉ×ÁÅÍÁÑ ×ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 8.3.
`RELENG_8_2`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 8.2 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_8_1`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 8.1 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_8_0`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 8.0 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_7`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	÷ÅÔËÁ ÓÏÐÒÏ×ÏÖÄÅÎÉÑ 7-STABLE (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_7_4`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 7.4 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_7_3`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 7.3 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_7_2`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 7.2 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_7_1`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 7.1 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_7_0`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 7.0 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_6`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	÷ÅÔËÁ ÓÏÐÒÏ×ÏÖÄÅÎÉÑ 6-STABLE (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_6_4`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 6.4 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_6_3`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 6.3 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_6_2`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 6.2 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_6_1`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 6.1 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_6_0`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 6.0 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_5`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	÷ÅÔËÁ ÄÌÑ ÐÏÄÄÅÒÖËÉ 5-STABLE (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_5_5`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 5.5 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_5_4`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 5.4 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_5_3`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 5.3 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_5_2`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 5.2 / 5.2.1 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_5_1`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 5.1 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_5_0`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 5.0 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	÷ÅÔËÁ ÄÌÑ ÐÏÄÄÅÒÖËÉ 4-STABLE (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_11`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÑ ÏÛÉÂÏË FreeBSD 4.11 (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_10`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 4.10 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_9`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 4.9 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_8`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 4.8 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_7`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 4.7 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_6`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 4.6 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_5`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 4.5 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_4`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 4.4 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_4_3`	úÁÍÏÒÏÖÅÎÁ	&contact.so;	÷ÅÔËÁ FreeBSD 4.3 ÄÌÑ ÉÓÐÒÁ×ÌÅÎÉÊ, ËÁÓÁÀÝÉÈÓÑ ÂÅÚÏÐÁÓÎÏÓÔÉ (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_3`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	÷ÅÔËÁ ÄÌÑ ÐÏÄÄÅÒÖËÉ 3-STABLE (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
`RELENG_2_2`	ïÔËÒÙÔÁ	ÒÁÚÒÁÂÏÔÞÉËÉ	÷ÅÔËÁ ÄÌÑ ÐÏÄÄÅÒÖËÉ 2.2-STABLE (ÏÆÉÃÉÁÌØÎÏ ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔÓÑ).
ðÏÄÄÅÒÅ×Ï	óÏÓÔÏÑÎÉÅ	ëÏÎÔÁËÔ	ðÒÉÍÅÞÁÎÉÑ
`ports/`	ïÔËÒÙÔÏ	&contact.portmgr;	ëÏÌÌÅËÃÉÑ ðÏÒÔÏ× FreeBSD.
`doc/`	ïÔËÒÙÔÏ	&contact.doc;	îÁÂÏÒ ÄÏËÕÍÅÎÔÁÃÉÉ ÎÁ ÏÓÎÏ×Å SGML/XML.

äÏËÕÍÅÎÔÁÃÉÑ ÐÏ ÐÏÄÇÏÔÏ×ËÅ ÒÅÌÉÚÏ×

ðÏÄÇÏÔÏ×ËÁ ÒÅÌÉÚÏ× FreeBSD
ïÐÉÓÙ×ÁÅÔ ÐÏÄÈÏÄ, ÉÓÐÏÌØÚÕÅÍÙÊ ËÏÍÁÎÄÏÊ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ× FreeBSD ÄÌÑ ÓÏÚÄÁÎÉÑ ÒÅÌÉÚÏ×, ËÁÞÅÓÔ×Ï ËÏÔÏÒÙÈ ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ ÇÏÔÏ×ÎÏÓÔÉ Ë ÐÒÏÍÙÛÌÅÎÎÏÊ ÜËÓÐÌÕÁÔÁÃÉÉ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÙ FreeBSD. ÷ ÜÔÏÍ ÄÏËÕÍÅÎÔÅ ÒÁÓÓËÁÚÁÎÏ ÏÂ ÉÎÓÔÒÕÍÅÎÔÁÈ, ÄÏÓÔÕÐÎÙÈ ÔÏÍÕ, ËÔÏ ÚÁÉÎÔÅÒÅÓÏ×ÁÎ × ÓÏÚÄÁÎÉÉ ÓÏÂÓÔ×ÅÎÎÙÈ ÒÅÌÉÚÏ× FreeBSD ÄÌÑ ÉÓÐÏÌØÚÏ×ÁÎÉÑ × ËÏÒÐÏÒÁÔÉ×ÎÏÊ ÓÒÅÄÅ ÉÌÉ × ËÏÍÍÅÒÞÅÓËÉÈ ÃÅÌÑÈ.
ðÏÄÇÏÔÏ×ËÁ ÒÅÌÉÚÏ× FreeBSD ÄÌÑ ÐÁËÅÔÏ× ÓÔÏÒÏÎÎÉÈ ÒÁÚÒÁÂÏÔÞÉËÏ×
ïÐÉÓÙ×ÁÅÔ ÐÏÄÈÏÄ, ÉÓÐÏÌØÚÕÅÍÙÊ ËÏÍÁÎÄÏÊ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ× FreeBSD ÐÒÉ ÓÏÚÄÁÎÉÉ ËÁÞÅÓÔ×ÅÎÎÙÈ ÎÁÂÏÒÏ× ÐÁËÅÔÏ×, ÐÒÅÄÎÁÚÎÁÞÅÎÎÙÈ ÄÌÑ ÎÏÓÉÔÅÌÅÊ Ó ÏÆÉÃÉÁÌØÎÙÍÉ ÒÅÌÉÚÁÍÉ FreeBSD. üÔÏÔ ÄÏËÕÍÅÎÔ ÎÁÈÏÄÉÔÓÑ × ÒÁÚÒÁÂÏÔËÅ, ÎÏ ÐÏÓÔÅÐÅÎÎÏ × ÎÅÇÏ ÐÏÐÁÄÕÔ ÏÐÉÓÁÎÉÑ ÐÒÏÃÅÓÓÁ ÐÏÓÔÒÏÅÎÉÑ ÐÏÌÎÏÇÏ ÎÁÂÏÒÁ ÐÁËÅÔÏ× × "ËÌÁÓÔÅÒÅ ÐÏÒÔÏ×" FreeBSD.org, ËÁË ÓËÏÎÆÉÇÕÒÉÒÏ×ÁÔØ ÌÀÂÏÊ ÎÁÂÏÒ ÍÁÛÉÎ ÐÏÄ ËÌÁÓÔÅÒ ÐÏÒÔÏ×, ËÁË ÒÁÚÂÉÔØ ÐÁËÅÔÙ ÎÁ ÎÏÓÉÔÅÌÉ ÄÌÑ ÒÅÌÉÚÁ É ËÁË ÐÒÏ×ÅÒÉÔØ ÃÅÌÏÓÔÎÏÓÔØ ÎÁÂÏÒÁ ÐÁËÅÔÏ×.

ëÏÍÁÎÄÁ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ×

ïÓÎÏ×ÎÁÑ ÇÒÕÐÐÁ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ× ÏÔ×ÅÞÁÅÔ ÚÁ ÐÏÄÔ×ÅÒÖÄÅÎÉÅ ÚÁÐÒÏÓÏ× MFC × ÐÅÒÉÏÄÙ ÚÁÍÏÒÁÖÉ×ÁÎÉÑ ËÏÄÁ, ÓÏÚÄÁÎÉÅ ÐÌÁÎÏ× ×ÙÐÕÓËÁ É ÏÓÔÁÌØÎÙÅ ÒÁÂÏÔÙ, ÏÐÉÓÁÎÎÙÅ × ÎÁÛÉÈ ÏÂÑÚÁÎÎÏÓÔÑÈ.

ïÓÎÏ×ÎÁÑ ÇÒÕÐÐÁ ÐÏÄÇÏÔÏ×ËÉ ÒÅÌÉÚÏ× (Primary RE Team) re@FreeBSD.org) : &a.re.members; ÆÏÒÍÉÒÕÅÔ ÏÓÎÏ×ÎÕÀ ÇÒÕÐÐÕ ÐÏÄÇÏÔÏ×ËÉ, ÐÒÉÎÉÍÁÀÝÕÀ ÒÅÛÅÎÉÑ.

çÒÕÐÐÁ ÐÏÓÔÒÏÅÎÉÑ ÒÅÌÉÚÏ× ÏÔ×ÅÞÁÅÔ ÚÁ ÐÏÓÔÒÏÅÎÉÅ É ÓÏÚÄÁÎÉÅ ÄÉÓÔÒÉÂÕÔÉ×Ï× ÒÅÌÉÚÏ× FreeBSD ÄÌÑ ÒÁÚÌÉÞÎÙÈ ÐÏÄÄÅÒÖÉ×ÁÅÍÙÈ ÐÌÁÔÆÏÒÍ.

çÒÕÐÐÁ ÐÏÓÔÒÏÅÎÉÑ ÒÅÌÉÚÏ×(re-builders@FreeBSD.org) : &a.re-builders;

ðÁËÅÔÙ ÓÔÏÒÏÎÎÉÈ ÐÒÏÉÚ×ÏÄÉÔÅÌÅÊ × ëÏÌÌÅËÃÉÉ ðÏÒÔÏ× ÕÐÒÁ×ÌÑÀÔÓÑ ÇÒÕÐÐÏÊ portmgr@. ëÒÏÍÅ ÐÒÏÞÉÈ ÏÂÑÚÁÎÎÏÓÔÅÊ, ÏÔ×ÅÔÓÔ×ÅÎÎÙÅ ÚÁ ÐÏÒÔÙ ÏÔ×ÅÞÁÀÔ ÚÁ ÇÌÁÄËÕÀ ÒÁÂÏÔÕ ËÌÁÓÔÅÒÁ ÐÏÒÔÏ× × ÐÒÏÃÅÓÓÅ ÓÏÚÄÁÎÉÑ Ä×ÏÉÞÎÙÈ ÐÁËÁÄÖÅÊ.

óÏÚÄÁÔÅÌÉ ÐÁËÁÄÖÅÊ (&contact.portmgr;) : - &a.portmgr;

+ &a.portmgr.members;

þÁÓÔÏ ÚÁÄÁ×ÁÅÍÙÅ ×ÏÐÒÏÓÙ

çÄÅ ÍÏÖÎÏ ÎÁÊÔÉ ËÁÔÁÌÏÇ Ó ÒÅÌÉÚÏÍ ÉÌÉ ÏÂÒÁÚÙ ISO ÐÒÏÛÌÙÈ ÒÅÌÉÚÏ× FreeBSD?

ðÒÏÅËÔ FreeBSD ÎÅ ÐÏÄÄÅÒÖÉ×ÁÅÔ ÃÅÎÔÒÁÌÉÚÏ×ÁÎÎÙÊ ÉÓÔÏÒÉÞÅÓËÉÊ ÁÒÈÉ× ÏÂÒÁÚÏ× ISO ÓÔÁÒÙÈ ÒÅÌÉÚÏ×, ÏÄÎÁËÏ ÅÓÔØ ÅÝ£ ÍÎÏÇÏ ×ÁÒÉÁÎÔÏ×. âÏÌØÛÁÑ ËÏÌÌÅËÃÉÑ ÓÔÁÒÙÈ ÒÅÌÉÚÏ× (ÍÎÏÇÉÅ ÄÏÐÏÌÎÅÎÙ ÎÁÂÏÒÏÍ ÐÁËÅÔÏ×) ÎÁÈÏÄÉÔÓÑ ÐÏ ÜÔÏÍÕ ÁÄÒÅÓÕ: ftp://ftp-archive.FreeBSD.org/pub/FreeBSD-Archive/old-releases/. åÓÌÉ ×Ù ÎÅ ÍÏÖÅÔÅ ÎÁÊÔÉ ÚÅÒËÁÌÏ FTP, ÎÁ ËÏÔÏÒÏÍ ×Ó£ ÅÝ£ ÈÒÁÎÉÔÓÑ ÉÓËÏÍÙÊ ÒÅÌÉÚ, ÔÏ ÍÏÖÅÔÅ ÎÁÐÉÓÁÔØ ÐÏÓÔÁ×ÝÉËÁÍ ËÏÍÐÁËÔ-ÄÉÓËÏ×, ÅÓÔØ ÌÉ Õ ÎÉÈ ÓÔÁÒÙÅ ÒÅÌÉÚÙ. ÷ ÓÅÎÔÑÂÒÅ 2002 ÇÏÄÁ ÎÁÍ ÂÙÌ ÉÚ×ÅÓÔÅÎ ÓÌÕÞÁÊ ÉÓÐÏÌØÚÏ×ÁÎÉÑ FreeBSD 1.1 × ÓÕÄÅÂÎÏÍ ÓÌÕÛÁÎÉÉ ÄÌÑ ÄÏËÁÚÁÔÅÌØÓÔ× ÎÁÒÕÛÅÎÉÑ ÐÁÔÅÎÔÁ ÎÁ ÐÒÏÇÒÁÍÍÎÏÅ ÏÂÅÓÐÅÞÅÎÉÅ. ÷ ÓÁÍÏÍ ÄÅÌÅ, ÐÒÏÛÌÙÅ ÒÅÌÉÚÙ × ÎÅËÏÔÏÒÙÈ ÓÉÔÕÁÃÉÑÈ ÍÏÇÕÔ ÏËÁÚÁÔØÓÑ ÏÞÅÎØ ÎÕÖÎÙÍÉ.

diff --git a/share/pgpkeys/README b/share/pgpkeys/README index 64752557c7..7e7888e52f 100644 --- a/share/pgpkeys/README +++ b/share/pgpkeys/README @@ -1,101 +1,101 @@ How to add your key to the list =============================== The addkey.sh script will export your key and generate the correct SGML incantations to have your key listed in the "PGP Keys" chapter. It was written for GnuPG, but shouldn't be difficult to modify to use PGP if you absolutely won't use GnuPG. For addkey.sh to perform its magic, gpg must be in your path, and the key(s) you wish to export must be present in the default keyring or in a keyring listed in your ~/.gnupg/options file. The simplest case is when your login name (as reported by 'id -nu') is the same as your freefall login name, and all the keys you wish to add (and only those keys) have a UID that contains your FreeBSD.org email address. For instance, in my case: | % sh addkey.sh | Retrieving key... | pub 1024D/27848427 2000-10-13 Dag-Erling Smørgrav (low security key) | pub 1024D/0512E49A 2001-06-26 Dag-Erling Smørgrav (FreeBSD) | WARNING: Multiple keys; exporting all. If this is not what you want, | WARNING: you should specify a key ID on the command line. | Generating des.key... | Adding key to entity list... | | Unless you are already listed there, you should now add the | following text to pgpkeys-developers.xml (unless this is a role key | or you are a core member. In that case add to pgpkeys-officers.xml | or pgpkeys-core.xml). Remember to keep the list sorted by last name! | | -| &a.des; +| &a.des.email; | &pgpkey.des; | | | Don't forget to 'svn add des.key' if this is a new entry, | and check your diffs before committing! If your login name is different from your freefall login name, specify your freefall login name as the first argument to addkey.sh: | % sh addkey.sh des If you want to tune what keys are to be exported, specify the key IDs, or strings to look for in the UID, just like you would to gpg: | % sh addkey.sh des 0512E49A You can specify as few or as many IDs as you want, and addkey.sh will export all matching keys, and those only. If you didn't specify any key IDs on the command line, addkey.sh will look for a key that matches your FreeBSD.org email address. The script will generate a file named .key (des.key in my case) that with programlisting elements: one that contains the fingerprints of all the keys you exported, and one that contains an ASCII dump of those keys, as produced by 'gpg --armor --export'. It will also add a line to pgpkeys.ent defining an external entity named pgpkey. (pgpkey.des in my case) that refers to the key file. As you can see from the example above, addkey.sh will also tell you what keys it exported (check this carefully before committing!) and provide instructions for actually adding the key to the handbook. Beware that the keys are supposed to be ordered by surname; if you're unsure where to add your entry, use finger(1) to check the surnames of those around you. Once you've successfully run addkey.sh, 'svn add' your key file, check the diffs, and commit. How to update your key ====================== There are two ways to update your key. The first is to follow the above instructions as if you were adding your key for the first time - except that you don't need to edit chapter.xml, because you're already listed there. The addkey.sh script will snarf the RCS Id from the old key file and generate a new one with whatever keys you specified. The second method, which you can use if you're not adding or removing any keys, but just updating the ones that are already there (because you've had your key signed, or you've added or removed UIDs), is to execute the third line of your key file, which is a pre-cooked addkey.sh command line with your freefall login and the numeric key IDs of the keys contained in the file. Just do the equivalent of: | % eval $(grep addkey des.key) The exact command, of course, will depend on your shell, and on your freefall login name. -- des@freebsd.org $FreeBSD$ diff --git a/share/pgpkeys/addkey.sh b/share/pgpkeys/addkey.sh index 9ebaf9038f..d3d6504deb 100644 --- a/share/pgpkeys/addkey.sh +++ b/share/pgpkeys/addkey.sh @@ -1,89 +1,89 @@ #!/bin/sh # # $FreeBSD$ # LANG=C; export LANG unset LC_ALL unset LC_MESSAGES me="$1" if [ -z "${me}" ]; then me=$(id -nu) else shift fi id="$@" if [ -z "${id}" ]; then id="${me}@freebsd.org" fi gpg=$(which gpg) if [ ! -x "${gpg}" ]; then echo "GnuPG does not seem to be installed" >/dev/stderr exit 1 fi echo "Retrieving key..." keylist=$(gpg --list-keys ${id}) echo "${keylist}" | grep '^pub' id=$(echo "${keylist}" | awk '/^pub/ { print $2 }' | sed 's%.*/%%' | sort -u) id=$(echo $id) if [ "${#id}" -lt 8 ]; then echo "Invalid key ID." >/dev/stderr exit 1 elif [ "${#id}" -gt 8 ]; then echo "WARNING: Multiple keys; exporting all. If this is not what you want," >/dev/stderr echo "WARNING: you should specify a key ID on the command line." >/dev/stderr fi fp=$(gpg --fingerprint ${id}) [ $? -eq 0 ] || exit 1 key=$(gpg --no-version --armor --export ${id}) [ $? -eq 0 ] || exit 1 keyfile="${me}.key" if [ -f "${keyfile}" ]; then rcsid=$(grep '^$' "${keyfile}") fi if [ -z "${rcsid}" ]; then rcsid='' fi echo "Generating ${keyfile}..." ( echo "${rcsid}" echo '' echo '' echo '' ) >"${keyfile}" echo "Adding key to entity list..." mv pgpkeys.ent pgpkeys.ent.orig || exit 1 ( cat pgpkeys.ent.orig printf '' 16 "${me}" "${keyfile}" ) | sort -u >pgpkeys.ent echo echo "Unless you are already listed there, you should now add the" echo "following text to pgpkeys-developers.xml (unless this is a" echo "role key or you are a core member. In that case add to" echo "pgpkeys-officers.xml or pgpkeys-core.xml)." echo "Remember to keep the list sorted by last name!" echo echo " " -echo " &a.${me};" +echo " &a.${me}.email;" echo " &pgpkey.${me};" echo " " echo echo "If this is a new entry, don't forget to 'svn add ${keyfile}'" echo "and 'svn propset svn:keywords \"FreeBSD=%H\" ${keyfile}'" echo "and commit each of ${keyfile}, pgpkeys.ent and" echo "pgpkeys-developers.xml, pgpkeys-officers.xml, or" echo "pgpkeys-core.xml as required." diff --git a/share/pgpkeys/pgpkeys-core.xml b/share/pgpkeys/pgpkeys-core.xml index d249d11d91..65fa5552ca 100644 --- a/share/pgpkeys/pgpkeys-core.xml +++ b/share/pgpkeys/pgpkeys-core.xml @@ -1,45 +1,45 @@ - &a.tabthorpe; + &a.tabthorpe.email; &pgpkey.tabthorpe; - &a.gavin; + &a.gavin.email; &pgpkey.gavin; - &a.jhb; + &a.jhb.email; &pgpkey.jhb; - &a.kib; + &a.kib.email; &pgpkey.kib; - &a.theraven; + &a.theraven.email; &pgpkey.theraven; - &a.hrs; + &a.hrs.email; &pgpkey.hrs; - &a.peter; + &a.peter.email; &pgpkey.peter; - &a.miwi; + &a.miwi.email; &pgpkey.miwi; diff --git a/share/pgpkeys/pgpkeys-developers.xml b/share/pgpkeys/pgpkeys-developers.xml index 62c8f2dcb5..461d5a9f15 100644 --- a/share/pgpkeys/pgpkeys-developers.xml +++ b/share/pgpkeys/pgpkeys-developers.xml @@ -1,1993 +1,1992 @@ - &a.ariff; + &a.ariff.email; &pgpkey.ariff; - &a.tabthorpe; + &a.tabthorpe.email; &pgpkey.tabthorpe; - &a.eadler; + &a.eadler.email; &pgpkey.eadler; - &a.shaun; + &a.shaun.email; &pgpkey.shaun; - &a.brix; + &a.brix.email; &pgpkey.brix; - &a.mandree; + &a.mandree.email; &pgpkey.mandree; - &a.will; + &a.will.email; &pgpkey.will; - &a.dim; + &a.dim.email; &pgpkey.dim; - &a.anholt; + &a.anholt.email; &pgpkey.anholt; - &a.mva; + &a.mva.email; &pgpkey.mva; - &a.araujo; + &a.araujo.email; &pgpkey.araujo; - &a.mat; + &a.mat.email; &pgpkey.mat; - &a.syuu; + &a.syuu.email; &pgpkey.syuu; - &a.asami; + &a.asami.email; &pgpkey.asami; - &a.gavin; + &a.gavin.email; &pgpkey.gavin; - &a.jsa; + &a.jsa.email; &pgpkey.jsa; - &a.jadawin; + &a.jadawin.email; &pgpkey.jadawin; - &a.timur; + &a.timur.email; &pgpkey.timur; - &a.gjb; + &a.gjb.email; &pgpkey.gjb; - &a.snb; + &a.snb.email; &pgpkey.snb; - &a.barner; + &a.barner.email; &pgpkey.barner; - &a.art; + &a.art.email; &pgpkey.art; - &a.tobez; + &a.tobez.email; &pgpkey.tobez; - &a.damien; + &a.damien.email; &pgpkey.damien; - &a.tdb; + &a.tdb.email; &pgpkey.tdb; - &a.gblach; + &a.gblach.email; &pgpkey.gblach; - &a.mbr; + &a.mbr.email; &pgpkey.mbr; - &a.wblock; + &a.wblock.email; &pgpkey.wblock; - &a.bvs; + &a.bvs.email; &pgpkey.bvs; - &a.novel; + &a.novel.email; &pgpkey.novel; - &a.garga; + &a.garga.email; &pgpkey.garga; - &a.alexbl; + &a.alexbl.email; &pgpkey.alexbl; - &a.sbz; + &a.sbz.email; &pgpkey.sbz; - &a.ebrandi; + &a.ebrandi.email; &pgpkey.ebrandi; - &a.harti; + &a.harti.email; &pgpkey.harti; - &a.obraun; + &a.obraun.email; &pgpkey.obraun; - &a.makc; + &a.makc.email; &pgpkey.makc; - &a.jmb; + &a.jmb.email; &pgpkey.jmb; - &a.antoine; + &a.antoine.email; &pgpkey.antoine; - &a.db; + &a.db.email; &pgpkey.db; - &a.brueffer; + &a.brueffer.email; &pgpkey.brueffer; - &a.markus; + &a.markus.email; &pgpkey.markus; - &a.sbruno; + &a.sbruno.email; &pgpkey.sbruno; - &a.oleg; + &a.oleg.email; &pgpkey.oleg; - &a.bushman; + &a.bushman.email; &pgpkey.bushman; - &a.jchandra; + &a.jchandra.email; &pgpkey.jchandra; - &a.jcamou; + &a.jcamou.email; &pgpkey.jcamou; - &a.acm; + &a.acm.email; &pgpkey.acm; - &a.gahr; + &a.gahr.email; &pgpkey.gahr; - &a.dchagin; + &a.dchagin.email; &pgpkey.dchagin; - &a.perky; + &a.perky.email; &pgpkey.perky; - &a.jon; + &a.jon.email; &pgpkey.jon; - &a.jonathan; + &a.jonathan.email; &pgpkey.jonathan; - &a.loader; + &a.loader.email; &pgpkey.loader; - &a.luoqi; + &a.luoqi.email; &pgpkey.luoqi; - &a.ache; + &a.ache.email; &pgpkey.ache; - &a.melifaro; + &a.melifaro.email; &pgpkey.melifaro; - &a.seanc; + &a.seanc.email; &pgpkey.seanc; - &a.cjh; + &a.cjh.email; &pgpkey.cjh; - &a.cjc; + &a.cjc.email; &pgpkey.cjc; - &a.marcus; + &a.marcus.email; &pgpkey.marcus; - &a.nik; + &a.nik.email; &pgpkey.nik; - &a.benjsc; + &a.benjsc.email; &pgpkey.benjsc; - &a.tijl; + &a.tijl.email; &pgpkey.tijl; - &a.rakuco; + &a.rakuco.email; &pgpkey.rakuco; - &a.alc; + &a.alc.email; &pgpkey.alc; - &a.brucec; + &a.brucec.email; &pgpkey.brucec; - &a.culot; + &a.culot.email; &pgpkey.culot; - &a.aaron; + &a.aaron.email; &pgpkey.aaron; - &a.bapt; + &a.bapt.email; &pgpkey.bapt; - &a.ceri; + &a.ceri.email; &pgpkey.ceri; - &a.brd; + &a.brd.email; &pgpkey.brd; - &a.pjd; + &a.pjd.email; &pgpkey.pjd; - &a.bsd; + &a.bsd.email; &pgpkey.bsd; - &a.carl; + &a.carl.email; &pgpkey.carl; - &a.vd; + &a.vd.email; &pgpkey.vd; - &a.rdivacky; + &a.rdivacky.email; &pgpkey.rdivacky; - &a.danfe; + &a.danfe.email; &pgpkey.danfe; - &a.dd; + &a.dd.email; &pgpkey.dd; - &a.bdrewery; + &a.bdrewery.email; &pgpkey.bdrewery; - &a.olivierd; + &a.olivierd.email; &pgpkey.olivierd; - &a.bruno; + &a.bruno.email; &pgpkey.bruno; - &a.ale; + &a.ale.email; &pgpkey.ale; - &a.peadar; + &a.peadar.email; &pgpkey.peadar; - &a.deischen; + &a.deischen.email; &pgpkey.deischen; - &a.josef; + &a.josef.email; &pgpkey.josef; - &a.lme; + &a.lme.email; &pgpkey.lme; - &a.ue; + &a.ue.email; &pgpkey.ue; - &a.ru; + &a.ru.email; &pgpkey.ru; - &a.le; + &a.le.email; &pgpkey.le; - &a.bf; + &a.bf.email; &pgpkey.bf; - &a.madpilot; + &a.madpilot.email; &pgpkey.madpilot; - &a.rafan; + &a.rafan.email; &pgpkey.rafan; - &a.stefanf; + &a.stefanf.email; &pgpkey.stefanf; - &a.farrokhi; + &a.farrokhi.email; &pgpkey.farrokhi; - &a.jedgar; + &a.jedgar.email; &pgpkey.jedgar; - &a.feld; + &a.feld.email; &pgpkey.feld; - &a.green; + &a.green.email; &pgpkey.green; - &a.lioux; + &a.lioux.email; &pgpkey.lioux; - &a.mdf; + &a.mdf.email; &pgpkey.mdf; - &a.fanf; + &a.fanf.email; &pgpkey.fanf; - &a.blackend; + &a.blackend.email; &pgpkey.blackend; - &a.petef; + &a.petef.email; &pgpkey.petef; - &a.decke; + &a.decke.email; &pgpkey.decke; - &a.billf; + &a.billf.email; &pgpkey.billf; - &a.avg; + &a.avg.email; &pgpkey.avg; - &a.beat; + &a.beat.email; &pgpkey.beat; - &a.danger; + &a.danger.email; &pgpkey.danger; - &a.sjg; + &a.sjg.email; &pgpkey.sjg; - &a.gibbs; + &a.gibbs.email; &pgpkey.gibbs; - &a.pfg; + &a.pfg.email; &pgpkey.pfg; - &a.girgen; + &a.girgen.email; &pgpkey.girgen; - &a.pgollucci; + &a.pgollucci.email; &pgpkey.pgollucci; - &a.daichi; + &a.daichi.email; &pgpkey.daichi; - &a.mnag; + &a.mnag.email; &pgpkey.mnag; - &a.grehan; + &a.grehan.email; &pgpkey.grehan; - &a.jamie; + &a.jamie.email; &pgpkey.jamie; - &a.wg; + &a.wg.email; &pgpkey.wg; - &a.bar; + &a.bar.email; &pgpkey.bar; - &a.jmg; + &a.jmg.email; &pgpkey.jmg; - &a.mjg; + &a.mjg.email; &pgpkey.mjg; - &a.jhale; + &a.jhale.email; &pgpkey.jhale; - &a.dannyboy; + &a.dannyboy.email; &pgpkey.dannyboy; - &a.dhartmei; + &a.dhartmei.email; &pgpkey.dhartmei; - &a.ohauer; + &a.ohauer.email; &pgpkey.ohauer; - &a.ehaupt; + &a.ehaupt.email; &pgpkey.ehaupt; - &a.jhay; + &a.jhay.email; &pgpkey.jhay; - &a.sheldonh; + &a.sheldonh.email; &pgpkey.sheldonh; - &a.mikeh; + &a.mikeh.email; &pgpkey.mikeh; - &a.mheinen; + &a.mheinen.email; &pgpkey.mheinen; - &a.niels; + &a.niels.email; &pgpkey.niels; - &a.jh; + &a.jh.email; &pgpkey.jh; - &a.jgh; + &a.jgh.email; &pgpkey.jgh; - &a.ghelmer; + &a.ghelmer.email; &pgpkey.ghelmer; - &a.mux; + &a.mux.email; &pgpkey.mux; - &a.wen; + &a.wen.email; &pgpkey.wen; - &a.dhn; + &a.dhn.email; &pgpkey.dhn; - &a.jhibbits; + &a.jhibbits.email; &pgpkey.jhibbits; - &a.pho; + &a.pho.email; &pgpkey.pho; - &a.mich; + &a.mich.email; &pgpkey.mich; - &a.sunpoet; + &a.sunpoet.email; &pgpkey.sunpoet; - &a.lwhsu; + &a.lwhsu.email; &pgpkey.lwhsu; - &a.foxfair; + &a.foxfair.email; &pgpkey.foxfair; - &a.chinsan; + &a.chinsan.email; &pgpkey.chinsan; - &a.davide; + &a.davide.email; &pgpkey.davide; - &a.jkh; + &a.jkh.email; &pgpkey.jkh; - &a.versus; + &a.versus.email; &pgpkey.versus; - &a.weongyo; + &a.weongyo.email; &pgpkey.weongyo; - &a.peterj; + &a.peterj.email; &pgpkey.peterj; - &a.jinmei; + &a.jinmei.email; &pgpkey.jinmei; - &a.ahze; + &a.ahze.email; &pgpkey.ahze; - &a.markj; + &a.markj.email; &pgpkey.markj; - &a.trevor; + &a.trevor.email; &pgpkey.trevor; - &a.tj; + &a.tj.email; &pgpkey.tj; - &a.kan; + &a.kan.email; &pgpkey.kan; - &a.bjk; + &a.bjk.email; &pgpkey.bjk; - &a.phk; + &a.phk.email; &pgpkey.phk; - &a.pluknet; + &a.pluknet.email; &pgpkey.pluknet; - &a.cokane; + &a.cokane.email; &pgpkey.cokane; - &a.kato; + &a.kato.email; &pgpkey.kato; - &a.joe; + &a.joe.email; &pgpkey.joe; - &a.vkashyap; + &a.vkashyap.email; &pgpkey.vkashyap; - &a.kris; + &a.kris.email; &pgpkey.kris; - &a.keramida; + &a.keramida.email; &pgpkey.keramida; - &a.fjoe; + &a.fjoe.email; &pgpkey.fjoe; - &a.manolis; + &a.manolis.email; &pgpkey.manolis; - &a.jkim; + &a.jkim.email; &pgpkey.jkim; - &a.zack; + &a.zack.email; &pgpkey.zack; - &a.jceel; + &a.jceel.email; &pgpkey.jceel; - &a.andreas; + &a.andreas.email; &pgpkey.andreas; - &a.jkois; + &a.jkois.email; &pgpkey.jkois; - &a.sergei; + &a.sergei.email; &pgpkey.sergei; - &a.maxim; + &a.maxim.email; &pgpkey.maxim; - &a.taras; + &a.taras.email; &pgpkey.taras; - &a.jkoshy; + &a.jkoshy.email; &pgpkey.jkoshy; - &a.wkoszek; + &a.wkoszek.email; &pgpkey.wkoszek; - &a.ak; + &a.ak.email; &pgpkey.ak; - &a.skreuzer; + &a.skreuzer.email; &pgpkey.skreuzer; - &a.gabor; + &a.gabor.email; &pgpkey.gabor; - &a.anchie; + &a.anchie.email; &pgpkey.anchie; - &a.rik; + &a.rik.email; &pgpkey.rik; - &a.rushani; + &a.rushani.email; &pgpkey.rushani; - &a.kuriyama; + &a.kuriyama.email; &pgpkey.kuriyama; - &a.rene; + &a.rene.email; &pgpkey.rene; - &a.jlaffaye; + &a.jlaffaye.email; &pgpkey.jlaffaye; - &a.clement; + &a.clement.email; &pgpkey.clement; - &a.mlaier; + &a.mlaier.email; &pgpkey.mlaier; - &a.erwin; + &a.erwin.email; &pgpkey.erwin; - &a.martymac; + &a.martymac.email; &pgpkey.martymac; - &a.glarkin; + &a.glarkin.email; &pgpkey.glarkin; - &a.laszlof; + &a.laszlof.email; &pgpkey.laszlof; - &a.dru; + &a.dru.email; &pgpkey.dru; - &a.lawrance; + &a.lawrance.email; &pgpkey.lawrance; - &a.njl; + &a.njl.email; &pgpkey.njl; - &a.jlh; + &a.jlh.email; &pgpkey.jlh; - &a.leeym; + &a.leeym.email; &pgpkey.leeym; - &a.sam; + &a.sam.email; &pgpkey.sam; - &a.jylefort; + &a.jylefort.email; &pgpkey.jylefort; - &a.netchild; + &a.netchild.email; &pgpkey.netchild; - &a.ae; + &a.ae.email; &pgpkey.ae; - &a.lesi; + &a.lesi.email; &pgpkey.lesi; - &a.achim; + &a.achim.email; &pgpkey.achim; - &a.cel; + &a.cel.email; &pgpkey.cel; - &a.glewis; + &a.glewis.email; &pgpkey.glewis; - &a.qingli; + &a.qingli.email; &pgpkey.qingli; - &a.delphij; + &a.delphij.email; &pgpkey.delphij; - &a.avatar; + &a.avatar.email; &pgpkey.avatar; - &a.ijliao; + &a.ijliao.email; &pgpkey.ijliao; - &a.lulf; + &a.lulf.email; &pgpkey.lulf; - &a.clive; + &a.clive.email; &pgpkey.clive; - &a.pclin; + &a.pclin.email; &pgpkey.pclin; - &a.yzlin; + &a.yzlin.email; &pgpkey.yzlin; - &a.linimon; + &a.linimon.email; &pgpkey.linimon; - &a.arved; + &a.arved.email; &pgpkey.arved; - &a.dryice; + &a.dryice.email; &pgpkey.dryice; - &a.nemoliu; + &a.nemoliu.email; &pgpkey.nemoliu; - &a.zml; + &a.zml.email; &pgpkey.zml; - &a.nox; + &a.nox.email; &pgpkey.nox; - &a.remko; + &a.remko.email; &pgpkey.remko; - &a.avl; + &a.avl.email; &pgpkey.avl; - &a.issyl0; + &a.issyl0.email; &pgpkey.issyl0; - &a.scottl; + &a.scottl.email; &pgpkey.scottl; - &a.rmacklem; + &a.rmacklem.email; &pgpkey.rmacklem; - &a.bmah; + &a.bmah.email; &pgpkey.bmah; - &a.rm; + &a.rm.email; &pgpkey.rm; - &a.mtm; + &a.mtm.email; &pgpkey.mtm; - &a.dwmalone; + &a.dwmalone.email; &pgpkey.dwmalone; - &a.amdmi3; + &a.amdmi3.email; &pgpkey.amdmi3; - &a.kwm; + &a.kwm.email; &pgpkey.kwm; - &a.emaste; + &a.emaste.email; &pgpkey.emaste; - &a.cherry; + &a.cherry.email; &pgpkey.cherry; - &a.matusita; + &a.matusita.email; &pgpkey.matusita; - &a.mm; + &a.mm.email; &pgpkey.mm; - &a.sem; + &a.sem.email; &pgpkey.sem; - &a.tmclaugh; + &a.tmclaugh.email; &pgpkey.tmclaugh; - &a.jmelo; + &a.jmelo.email; &pgpkey.jmelo; - &a.ken; + &a.ken.email; &pgpkey.ken; - &a.dinoex; + &a.dinoex.email; &pgpkey.dinoex; - &a.sanpei; + &a.sanpei.email; &pgpkey.sanpei; - &a.rmh; + &a.rmh.email; &pgpkey.rmh; - &a.stephen; + &a.stephen.email; &pgpkey.stephen; - &a.marcel; + &a.marcel.email; &pgpkey.marcel; - &a.kmoore; + &a.kmoore.email; &pgpkey.kmoore; - &a.marck; + &a.marck.email; &pgpkey.marck; - &a.mav; + &a.mav.email; &pgpkey.mav; - &a.lippe; + &a.lippe.email; &pgpkey.lippe; - &a.rich; + &a.rich.email; &pgpkey.rich; - &a.knu; + &a.knu.email; &pgpkey.knu; - &a.tmm; + &a.tmm.email; &pgpkey.tmm; - &a.max; + &a.max.email; &pgpkey.max; - &a.maho; + &a.maho.email; &pgpkey.maho; - &a.yoichi; + &a.yoichi.email; &pgpkey.yoichi; - &a.trasz; + &a.trasz.email; &pgpkey.trasz; - &a.dbn; + &a.dbn.email; &pgpkey.dbn; - &a.bland; + &a.bland.email; &pgpkey.bland; - &a.gnn; + &a.gnn.email; &pgpkey.gnn; - &a.simon; + &a.simon.email; &pgpkey.simon; - &a.rnoland; + &a.rnoland.email; &pgpkey.rnoland; - &a.anders; + &a.anders.email; &pgpkey.anders; - &a.lofi; + &a.lofi.email; &pgpkey.lofi; - &a.obrien; + &a.obrien.email; &pgpkey.obrien; - &a.olgeni; + &a.olgeni.email; &pgpkey.olgeni; - &a.philip; + &a.philip.email; &pgpkey.philip; - &a.jpaetzel; + &a.jpaetzel.email; &pgpkey.jpaetzel; - &a.pgj; + &a.pgj.email; &pgpkey.pgj; - &a.hiren; + &a.hiren.email; &pgpkey.hiren; - &a.hmp; + &a.hmp.email; &pgpkey.hmp; - &a.fluffy; + &a.fluffy.email; &pgpkey.fluffy; - &a.sat; + &a.sat.email; &pgpkey.sat; - &a.np; + &a.np.email; &pgpkey.np; - &a.rpaulo; + &a.rpaulo.email; &pgpkey.rpaulo; - &a.mp; + &a.mp.email; &pgpkey.mp; - &a.roam; + &a.roam.email; &pgpkey.roam; - &a.den; + &a.den.email; &pgpkey.den; - &a.csjp; + &a.csjp.email; &pgpkey.csjp; - &a.gerald; + &a.gerald.email; &pgpkey.gerald; - &a.jacula; + &a.jacula.email; &pgpkey.jacula; - &a.jdp; + &a.jdp.email; &pgpkey.jdp; - &a.krion; + &a.krion.email; &pgpkey.krion; - &a.sepotvin; + &a.sepotvin.email; &pgpkey.sepotvin; - &a.markp; + &a.markp.email; &pgpkey.markp; - &a.alepulver; + &a.alepulver.email; &pgpkey.alepulver; - &a.thomas; + &a.thomas.email; &pgpkey.thomas; - &a.hq; + &a.hq.email; &pgpkey.hq; - &a.dfr; + &a.dfr.email; &pgpkey.dfr; - &a.lbr; + &a.lbr.email; &pgpkey.lbr; - &a.crees; + &a.crees.email; &pgpkey.crees; - &a.rees; + &a.rees.email; &pgpkey.rees; - &a.bcr; + &a.bcr.email; &pgpkey.bcr; - &a.trhodes; + &a.trhodes.email; &pgpkey.trhodes; - &a.benno; + &a.benno.email; &pgpkey.benno; - &a.beech; + &a.beech.email; &pgpkey.beech; - &a.matteo; + &a.matteo.email; &pgpkey.matteo; - &a.roberto; + &a.roberto.email; &pgpkey.roberto; - &a.rodrigc; + &a.rodrigc.email; &pgpkey.rodrigc; - &a.guido; + &a.guido.email; &pgpkey.guido; - &a.rea; + &a.rea.email; &pgpkey.rea; - &a.ray; + &a.ray.email; &pgpkey.ray; - &a.niklas; + &a.niklas.email; &pgpkey.niklas; - &a.bsam; + &a.bsam.email; &pgpkey.bsam; - &a.marks; + &a.marks.email; &pgpkey.marks; - &a.bschmidt; + &a.bschmidt.email; &pgpkey.bschmidt; - &a.wosch; + &a.wosch.email; &pgpkey.wosch; - &a.ed; + &a.ed.email; &pgpkey.ed; - &a.das; + &a.das.email; &pgpkey.das; - &a.scheidell; + &a.scheidell.email; &pgpkey.scheidell; - &a.schweikh; + &a.schweikh.email; &pgpkey.schweikh; - &a.matthew; + &a.matthew.email; &pgpkey.matthew; - &a.tmseck; + &a.tmseck.email; &pgpkey.tmseck; - &a.stas; + &a.stas.email; &pgpkey.stas; - &a.johans; + &a.johans.email; &pgpkey.johans; - &a.bakul; + &a.bakul.email; &pgpkey.bakul; - &a.gshapiro; + &a.gshapiro.email; &pgpkey.gshapiro; - &a.arun; + &a.arun.email; &pgpkey.arun; - &a.wxs; + &a.wxs.email; &pgpkey.wxs; - &a.nork; + &a.nork.email; &pgpkey.nork; - &a.syrinx; + &a.syrinx.email; &pgpkey.syrinx; - &a.vanilla; + &a.vanilla.email; &pgpkey.vanilla; - &a.ashish; + &a.ashish.email; &pgpkey.ashish; - &a.bms; + &a.bms.email; &pgpkey.bms; - &a.demon; + &a.demon.email; &pgpkey.demon; - &a.jesper; + &a.jesper.email; &pgpkey.jesper; - &a.scop; + &a.scop.email; &pgpkey.scop; - &a.anray; + &a.anray.email; &pgpkey.anray; - &a.flo; + &a.flo.email; &pgpkey.flo; - &a.glebius; + &a.glebius.email; &pgpkey.glebius; - &a.kensmith; + &a.kensmith.email; &pgpkey.kensmith; - &a.ben; + &a.ben.email; &pgpkey.ben; - &a.des; + &a.des.email; &pgpkey.des; - &a.sobomax; + &a.sobomax.email; &pgpkey.sobomax; - &a.asomers; + &a.asomers.email; &pgpkey.asomers; - &a.brian; + &a.brian.email; &pgpkey.brian; - &a.sson; + &a.sson.email; &pgpkey.sson; - &a.nsouch; + &a.nsouch.email; &pgpkey.nsouch; - &a.ssouhlal; + &a.ssouhlal.email; &pgpkey.ssouhlal; - &a.loos; + &a.loos.email; &pgpkey.loos; - &a.uqs; + &a.uqs.email; &pgpkey.uqs; - &a.rink; + &a.rink.email; &pgpkey.rink; - &a.vsevolod; + &a.vsevolod.email; &pgpkey.vsevolod; - &a.zi; + &a.zi.email; &pgpkey.zi; - &a.rrs; + &a.rrs.email; &pgpkey.rrs; - &a.murray; + &a.murray.email; &pgpkey.murray; - &a.vs; + &a.vs.email; &pgpkey.vs; - &a.rstone; + &a.rstone.email; &pgpkey.rstone; - &a.xride; + &a.xride.email; &pgpkey.xride; - &a.marius; + &a.marius.email; &pgpkey.marius; - &a.cs; + &a.cs.email; &pgpkey.cs; - &a.clsung; + &a.clsung.email; &pgpkey.clsung; - &a.gsutter; + &a.gsutter.email; &pgpkey.gsutter; - &a.metal; + &a.metal.email; &pgpkey.metal; - &a.ryusuke; + &a.ryusuke.email; &pgpkey.ryusuke; - &a.garys; + &a.garys.email; &pgpkey.garys; - &a.nyan; + &a.nyan.email; &pgpkey.nyan; - &a.sahil; + &a.sahil.email; &pgpkey.sahil; - &a.tota; + &a.tota.email; &pgpkey.tota; - &a.romain; + &a.romain.email; &pgpkey.romain; - &a.sylvio; + &a.sylvio.email; &pgpkey.sylvio; - &a.itetcu; + &a.itetcu.email; &pgpkey.itetcu; - &a.mi; + &a.mi.email; &pgpkey.mi; - &a.gordon; + &a.gordon.email; &pgpkey.gordon; - &a.lth; + &a.lth.email; &pgpkey.lth; - &a.jase; + &a.jase.email; &pgpkey.jase; - &a.lx; + &a.lx.email; &pgpkey.lx; - &a.fabient; + &a.fabient.email; &pgpkey.fabient; - &a.thierry; + &a.thierry.email; &pgpkey.thierry; - &a.thompsa; + &a.thompsa.email; &pgpkey.thompsa; - &a.flz; + &a.flz.email; &pgpkey.flz; - &a.jilles; + &a.jilles.email; &pgpkey.jilles; - &a.ganbold; + &a.ganbold.email; &pgpkey.ganbold; - &a.tuexen; + &a.tuexen.email; &pgpkey.tuexen; - &a.andrew; + &a.andrew.email; &pgpkey.andrew; - &a.ume; + &a.ume.email; &pgpkey.ume; - &a.ups; + &a.ups.email; &pgpkey.ups; - &a.bryanv; + &a.bryanv.email; &pgpkey.bryanv; - &a.nectar; + &a.nectar.email; &pgpkey.nectar; - &a.avilla; + &a.avilla.email; &pgpkey.avilla; - &a.nivit; + &a.nivit.email; &pgpkey.nivit; - &a.ivoras; + &a.ivoras.email; &pgpkey.ivoras; - &a.stefan; + &a.stefan.email; &pgpkey.stefan; - &a.kaiw; + &a.kaiw.email; &pgpkey.kaiw; - &a.adamw; + &a.adamw.email; &pgpkey.adamw; - &a.peter; + &a.peter.email; &pgpkey.peter; - &a.nwhitehorn; + &a.nwhitehorn.email; &pgpkey.nwhitehorn; - &a.miwi; + &a.miwi.email; &pgpkey.miwi; - &a.nate; + &a.nate.email; &pgpkey.nate; - &a.swills; + &a.swills.email; &pgpkey.swills; - &a.twinterg; + &a.twinterg.email; &pgpkey.twinterg; - &a.wollman; + &a.wollman.email; &pgpkey.wollman; - &a.joerg; + &a.joerg.email; &pgpkey.joerg; - &a.davidxu; + &a.davidxu.email; &pgpkey.davidxu; - &a.emax; + &a.emax.email; &pgpkey.emax; - &a.bz; + &a.bz.email; &pgpkey.bz; - &a.zeising; + &a.zeising.email; &pgpkey.zeising; - &a.phantom; + &a.phantom.email; &pgpkey.phantom; - &a.sephe; + &a.sephe.email; &pgpkey.sephe; - &a.zont; + &a.zont.email; &pgpkey.zont; - diff --git a/share/xml/authors.ent b/share/xml/authors.ent index b9c7c45d6e..425ab2b6e1 100644 --- a/share/xml/authors.ent +++ b/share/xml/authors.ent @@ -1,1471 +1,2271 @@ -aaron@FreeBSD.org"> + -abial@FreeBSD.org"> + +aaron@FreeBSD.org"> -ache@FreeBSD.org"> + +abial@FreeBSD.org"> -achim@FreeBSD.org"> + +ache@FreeBSD.org"> -acm@FreeBSD.org"> + +achim@FreeBSD.org"> -adam@FreeBSD.org"> + +acm@FreeBSD.org"> -adamw@FreeBSD.org"> + +adam@FreeBSD.org"> -ade@FreeBSD.org"> + +adamw@FreeBSD.org"> -adrian@FreeBSD.org"> + +ade@FreeBSD.org"> -ae@FreeBSD.org"> + +adrian@FreeBSD.org"> -ahasty@FreeBSD.org"> + +ae@FreeBSD.org"> -ahd@FreeBSD.org"> + +ahasty@FreeBSD.org"> -ahze@FreeBSD.org"> + +ahd@FreeBSD.org"> -ak@FreeBSD.org"> + +ahze@FreeBSD.org"> -akiyama@FreeBSD.org"> + +ak@FreeBSD.org"> -alane@FreeBSD.org"> + +akiyama@FreeBSD.org"> -alc@FreeBSD.org"> + +alane@FreeBSD.org"> -ale@FreeBSD.org"> + +alc@FreeBSD.org"> -alepulver@FreeBSD.org"> + +ale@FreeBSD.org"> -alex@FreeBSD.org"> + +alepulver@FreeBSD.org"> -alexbl@FreeBSD.org"> + +alex@FreeBSD.org"> -alfred@FreeBSD.org"> + +alexbl@FreeBSD.org"> -alm@FreeBSD.org"> + +alfred@FreeBSD.org"> -am@FreeBSD.org"> + +alm@FreeBSD.org"> -ambrisko@FreeBSD.org"> + +am@FreeBSD.org"> -amdmi3@FreeBSD.org"> + +ambrisko@FreeBSD.org"> -amorita@FreeBSD.org"> + +amdmi3@FreeBSD.org"> -amurai@FreeBSD.org"> + +amorita@FreeBSD.org"> -anchie@FreeBSD.org"> + +amurai@FreeBSD.org"> -anders@FreeBSD.org"> + +anchie@FreeBSD.org"> -andre@FreeBSD.org"> + +anders@FreeBSD.org"> -andreas@FreeBSD.org"> + +andre@FreeBSD.org"> -andreast@FreeBSD.org"> + +andreas@FreeBSD.org"> -andrew@FreeBSD.org"> + +andreast@FreeBSD.org"> -andy@FreeBSD.org"> + +andrew@FreeBSD.org"> -anholt@FreeBSD.org"> + +andy@FreeBSD.org"> -anray@FreeBSD.org"> + +anholt@FreeBSD.org"> -antoine@FreeBSD.org"> + +anray@FreeBSD.org"> -araujo@FreeBSD.org"> + +antoine@FreeBSD.org"> -archie@FreeBSD.org"> + +araujo@FreeBSD.org"> -ariff@FreeBSD.org"> + +archie@FreeBSD.org"> -arr@FreeBSD.org"> + +ariff@FreeBSD.org"> -art@FreeBSD.org"> + +arr@FreeBSD.org"> -arun@FreeBSD.org"> + +art@FreeBSD.org"> -arved@FreeBSD.org"> + +arun@FreeBSD.org"> -asami@FreeBSD.org"> + +arundel@FreeBSD.org"> -ashish@FreeBSD.org"> + +arved@FreeBSD.org"> -asmodai@FreeBSD.org"> + +asami@FreeBSD.org"> -assar@FreeBSD.org"> + +ashish@FreeBSD.org"> -asomers@FreeBSD.org"> + +asmodai@FreeBSD.org"> -ats@FreeBSD.org"> + +assar@FreeBSD.org"> -attilio@FreeBSD.org"> + +asomers@FreeBSD.org"> -avatar@FreeBSD.org"> + +ats@FreeBSD.org"> -avg@FreeBSD.org"> + +attilio@FreeBSD.org"> -avilla@FreeBSD.org"> + +avatar@FreeBSD.org"> -avl@FreeBSD.org"> + +avg@FreeBSD.org"> -awebster@pubnix.net"> + +avilla@FreeBSD.org"> -az@FreeBSD.org"> + +avl@FreeBSD.org"> -babkin@FreeBSD.org"> + +awebster@pubnix.net"> -bakul@FreeBSD.org"> + +az@FreeBSD.org"> -bapt@FreeBSD.org"> + +babb@FreeBSD.org"> -bar@FreeBSD.org"> + +babkin@FreeBSD.org"> -barner@FreeBSD.org"> + +bakul@FreeBSD.org"> -bbraun@FreeBSD.org"> + +bapt@FreeBSD.org"> -bcr@FreeBSD.org"> + +bar@FreeBSD.org"> -bde@FreeBSD.org"> + +barner@FreeBSD.org"> -bdrewery@FreeBSD.org"> + +bbraun@FreeBSD.org"> -bean@FreeBSD.org"> + +bcr@FreeBSD.org"> -beat@FreeBSD.org"> + +bde@FreeBSD.org"> -beech@FreeBSD.org"> + +bdrewery@FreeBSD.org"> -ben@FreeBSD.org"> + +bean@FreeBSD.org"> -benjsc@FreeBSD.org"> + +beat@FreeBSD.org"> -benl@FreeBSD.org"> + +beech@FreeBSD.org"> -benno@FreeBSD.org"> + +ben@FreeBSD.org"> -bf@FreeBSD.org"> + +benjsc@FreeBSD.org"> -bgray@FreeBSD.org"> + +benl@FreeBSD.org"> -bhaga@FreeBSD.org"> + +benno@FreeBSD.org"> -billf@FreeBSD.org"> + +bf@FreeBSD.org"> -bjk@FreeBSD.org"> + +bgray@FreeBSD.org"> -bk@FreeBSD.org"> + +bhaga@FreeBSD.org"> -blackend@FreeBSD.org"> + +billf@FreeBSD.org"> -bland@FreeBSD.org"> + +bjk@FreeBSD.org"> -bmah@FreeBSD.org"> + +bk@FreeBSD.org"> -bmilekic@FreeBSD.org"> + +blackend@FreeBSD.org"> -bms@FreeBSD.org"> + +bland@FreeBSD.org"> -bp@FreeBSD.org"> + +bmah@FreeBSD.org"> -brandon@FreeBSD.org"> + +bmilekic@FreeBSD.org"> -brd@FreeBSD.org"> + +bms@FreeBSD.org"> -brian@FreeBSD.org"> + +bp@FreeBSD.org"> -brix@FreeBSD.org"> + +brandon@FreeBSD.org"> -brooks@FreeBSD.org"> + +brd@FreeBSD.org"> -brucec@FreeBSD.org"> + +brian@FreeBSD.org"> -brueffer@FreeBSD.org"> + +brix@FreeBSD.org"> -bruno@FreeBSD.org"> + +brooks@FreeBSD.org"> -bryanv@FreeBSD.org"> + +brucec@FreeBSD.org"> -bsam@FreeBSD.org"> + +brueffer@FreeBSD.org"> -bschmidt@FreeBSD.org"> + +bruno@FreeBSD.org"> -bsd@FreeBSD.org"> + +bryanv@FreeBSD.org"> -bushman@FreeBSD.org"> + +bsam@FreeBSD.org"> -bvs@FreeBSD.org"> + +bschmidt@FreeBSD.org"> -bz@FreeBSD.org"> + +bsd@FreeBSD.org"> -carl@FreeBSD.org"> + +bushman@FreeBSD.org"> -carvay@FreeBSD.org"> + +bvs@FreeBSD.org"> -cawimm@FreeBSD.org"> + +bz@FreeBSD.org"> -cbzimmer@FreeBSD.org"> + +carl@FreeBSD.org"> -cel@FreeBSD.org"> + +carvay@FreeBSD.org"> -ceri@FreeBSD.org"> + +cawimm@FreeBSD.org"> -cg@FreeBSD.org"> + +cbzimmer@FreeBSD.org"> -charnier@FreeBSD.org"> + +cel@FreeBSD.org"> -chern@FreeBSD.org"> + +ceri@FreeBSD.org"> -cherry@FreeBSD.org"> + +cg@FreeBSD.org"> -chinsan@FreeBSD.org"> + +charnier@FreeBSD.org"> -chm@FreeBSD.org"> + +chern@FreeBSD.org"> -chmr@FreeBSD.org"> + +cherry@FreeBSD.org"> -chris@FreeBSD.org"> + +chinsan@FreeBSD.org"> -chuckr@FreeBSD.org"> + +chm@FreeBSD.org"> -cjc@FreeBSD.org"> + +chmr@FreeBSD.org"> -cjh@FreeBSD.org"> + +chris@FreeBSD.org"> -clement@FreeBSD.org"> + +chuckr@FreeBSD.org"> -clive@FreeBSD.org"> + +cjc@FreeBSD.org"> -clsung@FreeBSD.org"> + +cjh@FreeBSD.org"> -cognet@FreeBSD.org"> + +clement@FreeBSD.org"> -cokane@FreeBSD.org"> + +clive@FreeBSD.org"> -conklin@FreeBSD.org"> + +clsung@FreeBSD.org"> -cp@FreeBSD.org"> + +cognet@FreeBSD.org"> -cperciva@FreeBSD.org"> + +cokane@FreeBSD.org"> -cpiazza@FreeBSD.org"> + +conklin@FreeBSD.org"> -cracauer@FreeBSD.org"> + +cp@FreeBSD.org"> -crees@FreeBSD.org"> + +cperciva@FreeBSD.org"> -cs@FreeBSD.org"> + +cpiazza@FreeBSD.org"> -csgr@FreeBSD.org"> + +cracauer@FreeBSD.org"> -cshumway@FreeBSD.org"> + +crees@FreeBSD.org"> -csjp@FreeBSD.org"> + +cs@FreeBSD.org"> -culot@FreeBSD.org"> + +csgr@FreeBSD.org"> -cwt@FreeBSD.org"> + +cshumway@FreeBSD.org"> -cy@FreeBSD.org"> + +csjp@FreeBSD.org"> -daichi@FreeBSD.org"> + +culot@FreeBSD.org"> -damien@FreeBSD.org"> + +cwt@FreeBSD.org"> -dan@FreeBSD.org"> + +cy@FreeBSD.org"> -danfe@FreeBSD.org"> + +daichi@FreeBSD.org"> -danger@FreeBSD.org"> + +damien@FreeBSD.org"> -danny@FreeBSD.org"> + +dan@FreeBSD.org"> -dannyboy@FreeBSD.org"> + +danfe@FreeBSD.org"> -darrenr@FreeBSD.org"> + +danger@FreeBSD.org"> -das@FreeBSD.org"> + +danny@FreeBSD.org"> -davidc@FreeBSD.org"> + +dannyboy@FreeBSD.org"> -davidch@FreeBSD.org"> + +darrenr@FreeBSD.org"> -davide@FreeBSD.org"> + +das@FreeBSD.org"> -davidn@FreeBSD.org"> + +davidc@FreeBSD.org"> -davidxu@FreeBSD.org"> + +davidch@FreeBSD.org"> -db@FreeBSD.org"> + +davide@FreeBSD.org"> -dbaker@FreeBSD.org"> + +davidn@FreeBSD.org"> -dbn@FreeBSD.org"> + +davidxu@FreeBSD.org"> -dburr@FreeBSD.org"> + +db@FreeBSD.org"> -dchagin@FreeBSD.org"> + +dbaker@FreeBSD.org"> -dcs@FreeBSD.org"> + +dbn@FreeBSD.org"> -dd@FreeBSD.org"> + +dburr@FreeBSD.org"> -dds@FreeBSD.org"> + +dchagin@FreeBSD.org"> -deb@FreeBSD.org"> + +dcs@FreeBSD.org"> -dec@FreeBSD.org"> + +dd@FreeBSD.org"> -decke@FreeBSD.org"> + +dds@FreeBSD.org"> -deischen@FreeBSD.org"> + +ds@FreeBSD.org"> -delphij@FreeBSD.org"> + +deb@FreeBSD.org"> -demon@FreeBSD.org"> + +dec@FreeBSD.org"> -den@FreeBSD.org"> + +decke@FreeBSD.org"> -des@FreeBSD.org"> + +deischen@FreeBSD.org"> -dfr@FreeBSD.org"> + +delphij@FreeBSD.org"> -dg@FreeBSD.org"> + +demon@FreeBSD.org"> -dhartmei@FreeBSD.org"> + +den@FreeBSD.org"> -dhn@FreeBSD.org"> + +des@FreeBSD.org"> -dhw@FreeBSD.org"> + +dfr@FreeBSD.org"> -dick@FreeBSD.org"> + +dg@FreeBSD.org"> -dillon@FreeBSD.org"> + +dhartmei@FreeBSD.org"> -dim@FreeBSD.org"> + +dhn@FreeBSD.org"> -dima@FreeBSD.org"> + +dhw@FreeBSD.org"> -dinoex@FreeBSD.org"> + +dick@FreeBSD.org"> -dirk@FreeBSD.org"> + +dillon@FreeBSD.org"> -dmarion@FreeBSD.org"> + +dim@FreeBSD.org"> -dmlb@FreeBSD.org"> + +dima@FreeBSD.org"> -dougb@FreeBSD.org"> + +dinoex@FreeBSD.org"> -dru@FreeBSD.org"> + +dirk@FreeBSD.org"> -dryice@FreeBSD.org"> + +dmarion@FreeBSD.org"> -dt@FreeBSD.org"> + +dmlb@FreeBSD.org"> -dteske@FreeBSD.org"> + +don@FreeBSD.org"> -dufault@FreeBSD.org"> + +dougb@FreeBSD.org"> -dumbbell@FreeBSD.org"> + +dru@FreeBSD.org"> -dutchdaemon@FreeBSD.org"> + +dryice@FreeBSD.org"> -dvl@FreeBSD.org"> + +dt@FreeBSD.org"> -dwcjr@FreeBSD.org"> + +dteske@FreeBSD.org"> -dwhite@FreeBSD.org"> + +dufault@FreeBSD.org"> -dwmalone@FreeBSD.org"> + +dumbbell@FreeBSD.org"> -dyson@FreeBSD.org"> + +dutchdaemon@FreeBSD.org"> -eadler@FreeBSD.org"> + +dvl@FreeBSD.org"> -ebrandi@FreeBSD.org"> + +dwcjr@FreeBSD.org"> -ed@FreeBSD.org"> + +dwhite@FreeBSD.org"> -edwin@FreeBSD.org"> + +dwmalone@FreeBSD.org"> -ehaupt@FreeBSD.org"> + +dyson@FreeBSD.org"> -eik@FreeBSD.org"> + +eadler@FreeBSD.org"> -eivind@FreeBSD.org"> + +ebrandi@FreeBSD.org"> -ejc@FreeBSD.org"> + +ed@FreeBSD.org"> -emaste@FreeBSD.org"> + +edwin@FreeBSD.org"> -emax@FreeBSD.org"> + +ehaupt@FreeBSD.org"> -emoore@FreeBSD.org"> + +eik@FreeBSD.org"> -eri@FreeBSD.org"> + +eivind@FreeBSD.org"> -eric@FreeBSD.org"> + +ejc@FreeBSD.org"> -erich@FreeBSD.org"> + +emaste@FreeBSD.org"> -erik@FreeBSD.org"> + +emax@FreeBSD.org"> -erwin@FreeBSD.org"> + +emoore@FreeBSD.org"> -fabient@FreeBSD.org"> + +eri@FreeBSD.org"> -fanf@FreeBSD.org"> + +eric@FreeBSD.org"> -farrokhi@FreeBSD.org"> + +erich@FreeBSD.org"> -feld@FreeBSD.org"> + +erik@FreeBSD.org"> -fenner@FreeBSD.org"> + +erwin@FreeBSD.org"> -fjoe@FreeBSD.org"> + +fabient@FreeBSD.org"> -flathill@FreeBSD.org"> + +fanf@FreeBSD.org"> -flo@FreeBSD.org"> + +farrokhi@FreeBSD.org"> -fluffy@FreeBSD.org"> + +feld@FreeBSD.org"> -flz@FreeBSD.org"> + +fenner@FreeBSD.org"> -foxfair@FreeBSD.org"> + +fjoe@FreeBSD.org"> -fsmp@FreeBSD.org"> + +flathill@FreeBSD.org"> -furuta@FreeBSD.org"> + +flo@FreeBSD.org"> -gabor@FreeBSD.org"> + +fluffy@FreeBSD.org"> -gad@FreeBSD.org"> + +flz@FreeBSD.org"> -gahr@FreeBSD.org"> + +foxfair@FreeBSD.org"> -gallatin@FreeBSD.org"> + +fsmp@FreeBSD.org"> -ganbold@FreeBSD.org"> + +furuta@FreeBSD.org"> -garga@FreeBSD.org"> + +gabor@FreeBSD.org"> -garys@FreeBSD.org"> + +gad@FreeBSD.org"> -gavin@FreeBSD.org"> + +gahr@FreeBSD.org"> -gber@FreeBSD.org"> + +gallatin@FreeBSD.org"> -gblach@FreeBSD.org"> + +ganbold@FreeBSD.org"> -gclarkii@FreeBSD.org"> + +garga@FreeBSD.org"> -gehenna@FreeBSD.org"> + +garys@FreeBSD.org"> -gerald@FreeBSD.org"> + +gavin@FreeBSD.org"> -ghelmer@FreeBSD.org"> + +gber@FreeBSD.org"> -gibbs@FreeBSD.org"> + +gblach@FreeBSD.org"> -gioria@FreeBSD.org"> + +gclarkii@FreeBSD.org"> -girgen@FreeBSD.org"> + +gehenna@FreeBSD.org"> -gj@FreeBSD.org"> + +gerald@FreeBSD.org"> -gjb@FreeBSD.org"> + +ghelmer@FreeBSD.org"> -glarkin@FreeBSD.org"> + +gibbs@FreeBSD.org"> -gleb@FreeBSD.org"> + +gioria@FreeBSD.org"> -glebius@FreeBSD.org"> + +girgen@FreeBSD.org"> -glewis@FreeBSD.org"> + +gj@FreeBSD.org"> -gnn@FreeBSD.org"> + +gjb@FreeBSD.org"> -gonzo@FreeBSD.org"> + +glarkin@FreeBSD.org"> -gordon@FreeBSD.org"> + +gleb@FreeBSD.org"> -gpalmer@FreeBSD.org"> + +glebius@FreeBSD.org"> -graichen@FreeBSD.org"> + +glewis@FreeBSD.org"> -green@FreeBSD.org"> + +gnn@FreeBSD.org"> -grehan@FreeBSD.org"> + +gonzo@FreeBSD.org"> -greid@FreeBSD.org"> + +gordon@FreeBSD.org"> -grog@FreeBSD.org"> + +gpalmer@FreeBSD.org"> -groudier@FreeBSD.org"> + +graichen@FreeBSD.org"> -gryphon@FreeBSD.org"> + +green@FreeBSD.org"> -gshapiro@FreeBSD.org"> + +grehan@FreeBSD.org"> -gsutter@FreeBSD.org"> + +greid@FreeBSD.org"> -guido@FreeBSD.org"> + +grog@FreeBSD.org"> -hanai@FreeBSD.org"> + +groudier@FreeBSD.org"> -harti@FreeBSD.org"> + +gryphon@FreeBSD.org"> -helbig@FreeBSD.org"> + +gshapiro@FreeBSD.org"> -hiren@FreeBSD.org"> + +gsutter@FreeBSD.org"> -hm@FreeBSD.org"> + +guido@FreeBSD.org"> -hmp@FreeBSD.org"> + +hanai@FreeBSD.org"> -hoek@FreeBSD.org"> + +harti@FreeBSD.org"> -horikawa@FreeBSD.org"> + +helbig@FreeBSD.org"> -hosokawa@FreeBSD.org"> + +hm@FreeBSD.org"> -hq@FreeBSD.org"> + +hiren@FreeBSD.org"> -hrs@FreeBSD.org"> + +hmp@FreeBSD.org"> -hselasky@FreeBSD.org"> + +hoek@FreeBSD.org"> -hsu@FreeBSD.org"> + +horikawa@FreeBSD.org"> -ian@FreeBSD.org"> + +hosokawa@FreeBSD.org"> -iedowse@FreeBSD.org"> + +hq@FreeBSD.org"> -ijliao@FreeBSD.org"> + +hrs@FreeBSD.org"> -ikob@FreeBSD.org"> + +hselasky@FreeBSD.org"> -imp@FreeBSD.org"> + +hsu@FreeBSD.org"> -imura@FreeBSD.org"> + +ian@FreeBSD.org"> -issei@FreeBSD.org"> + +iedowse@FreeBSD.org"> -issyl0@FreeBSD.org"> + +ijliao@FreeBSD.org"> -itetcu@FreeBSD.org"> + +ikob@FreeBSD.org"> -itojun@FreeBSD.org"> + +imp@FreeBSD.org"> -ivoras@FreeBSD.org"> + +imura@FreeBSD.org"> -iwasaki@FreeBSD.org"> + +issei@FreeBSD.org"> -jacula@FreeBSD.org"> + +issyl0@FreeBSD.org"> -jadawin@FreeBSD.org"> + +itetcu@FreeBSD.org"> -jake@FreeBSD.org"> + +itojun@FreeBSD.org"> -jamie@FreeBSD.org"> + +ivoras@FreeBSD.org"> -jamil@FreeBSD.org"> + +iwasaki@FreeBSD.org"> -jase@FreeBSD.org"> + +jacula@FreeBSD.org"> -jasone@FreeBSD.org"> + +jadawin@FreeBSD.org"> -jayanth@FreeBSD.org"> + +jake@FreeBSD.org"> -jb@FreeBSD.org"> + +jamie@FreeBSD.org"> -jcamou@FreeBSD.org"> + +jamil@FreeBSD.org"> -jceel@FreeBSD.org"> + +jase@FreeBSD.org"> -jchandra@FreeBSD.org"> + +jasone@FreeBSD.org"> -jdp@FreeBSD.org"> + +jayanth@FreeBSD.org"> -jedgar@FreeBSD.org"> + +jb@FreeBSD.org"> -jeff@FreeBSD.org"> + +jcamou@FreeBSD.org"> -jeh@FreeBSD.org"> + +jceel@FreeBSD.org"> -jehamby@FreeBSD.org"> + +jchandra@FreeBSD.org"> -jennifer@FreeBSD.org"> + +jdp@FreeBSD.org"> -jesper@FreeBSD.org"> + +jedgar@FreeBSD.org"> -jesusr@FreeBSD.org"> + +jeff@FreeBSD.org"> -jfieber@FreeBSD.org"> + +jeh@FreeBSD.org"> -jfitz@FreeBSD.org"> + +jehamby@FreeBSD.org"> -jfv@FreeBSD.org"> + +jennifer@FreeBSD.org"> -jgh@FreeBSD.org"> + +jesper@FreeBSD.org"> -jgreco@FreeBSD.org"> + +jesusr@FreeBSD.org"> -jh@FreeBSD.org"> + +jfieber@FreeBSD.org"> -jhale@FreeBSD.org"> + +jfitz@FreeBSD.org"> -jhay@FreeBSD.org"> + +jfv@FreeBSD.org"> -jhb@FreeBSD.org"> + +jgh@FreeBSD.org"> -jhibbits@FreeBSD.org"> + +jgreco@FreeBSD.org"> -jhs@FreeBSD.org"> + +jh@FreeBSD.org"> -jilles@FreeBSD.org"> + +jhale@FreeBSD.org"> -jim@FreeBSD.org"> + +jhay@FreeBSD.org"> -jimharris@FreeBSD.org"> + +jhb@FreeBSD.org"> -jinmei@FreeBSD.org"> + +jhibbits@FreeBSD.org"> -jkh@FreeBSD.org"> + +jhs@FreeBSD.org"> -jkim@FreeBSD.org"> + +jilles@FreeBSD.org"> -jkois@FreeBSD.org"> + +jim@FreeBSD.org"> -jkoshy@FreeBSD.org"> + +jimharris@FreeBSD.org"> -jlaffaye@FreeBSD.org"> + +jinmei@FreeBSD.org"> -jlemon@FreeBSD.org"> + +jkb@FreeBSD.org"> -jlh@FreeBSD.org"> + +jkh@FreeBSD.org"> -jlrobin@FreeBSD.org"> + +jkim@FreeBSD.org"> -jls@FreeBSD.org"> + +jkois@FreeBSD.org"> -jmacd@FreeBSD.org"> + +jkoshy@FreeBSD.org"> -jmallett@FreeBSD.org"> + +jlaffaye@FreeBSD.org"> -jmas@FreeBSD.org"> + +jlemon@FreeBSD.org"> -jmb@FreeBSD.org"> + +jlh@FreeBSD.org"> -jmelo@FreeBSD.org"> + +jlrobin@FreeBSD.org"> -jmg@FreeBSD.org"> + +jls@FreeBSD.org"> -jmz@FreeBSD.org"> + +jmacd@FreeBSD.org"> -joe@FreeBSD.org"> + +jmallett@FreeBSD.org"> -joel@FreeBSD.org"> + +jmas@FreeBSD.org"> -joerg@FreeBSD.org"> + +jmb@FreeBSD.org"> -johan@FreeBSD.org"> + +jmelo@FreeBSD.org"> -johans@FreeBSD.org"> + +jmg@FreeBSD.org"> -john@FreeBSD.org"> + +jmz@FreeBSD.org"> -jon@FreeBSD.org"> + +joe@FreeBSD.org"> -jonathan@FreeBSD.org"> + +joel@FreeBSD.org"> -josef@FreeBSD.org"> + +joerg@FreeBSD.org"> -jpaetzel@FreeBSD.org"> + +johan@FreeBSD.org"> -jraynard@FreeBSD.org"> + +johans@FreeBSD.org"> -jsa@FreeBSD.org"> + +john@FreeBSD.org"> -jseger@FreeBSD.org"> + +jon@FreeBSD.org"> -jtc@FreeBSD.org"> + +jonathan@FreeBSD.org"> -julian@FreeBSD.org"> + +josef@FreeBSD.org"> -jvh@FreeBSD.org"> + +jpaetzel@FreeBSD.org"> -jwd@FreeBSD.org"> + +jraynard@FreeBSD.org"> -jylefort@FreeBSD.org"> + +jsa@FreeBSD.org"> -kaiw@FreeBSD.org"> + +jseger@FreeBSD.org"> -kan@FreeBSD.org"> + +jtc@FreeBSD.org"> -kargl@FreeBSD.org"> + +julian@FreeBSD.org"> -karl@FreeBSD.org"> + +jvh@FreeBSD.org"> -kato@FreeBSD.org"> + +jwd@FreeBSD.org"> -kbyanc@FreeBSD.org"> + +jylefort@FreeBSD.org"> -keichii@FreeBSD.org"> + +kaiw@FreeBSD.org"> -keith@FreeBSD.org"> + +kan@FreeBSD.org"> -ken@FreeBSD.org"> + +kargl@FreeBSD.org"> -kensmith@FreeBSD.org"> + +karl@FreeBSD.org"> -keramida@FreeBSD.org"> + +kato@FreeBSD.org"> -kevlo@FreeBSD.org"> + +kbyanc@FreeBSD.org"> -kib@FreeBSD.org"> + +keichii@FreeBSD.org"> -kientzle@FreeBSD.org"> + +keith@FreeBSD.org"> -kiri@FreeBSD.org"> + +ken@FreeBSD.org"> -kishore@FreeBSD.org"> + +kensmith@FreeBSD.org"> -kjc@FreeBSD.org"> + +keramida@FreeBSD.org"> -kmacy@FreeBSD.org"> + +kevlo@FreeBSD.org"> -kmoore@FreeBSD.org"> + +kib@FreeBSD.org"> -koobs@FreeBSD.org"> + +kientzle@FreeBSD.org"> -knu@FreeBSD.org"> + +kiri@FreeBSD.org"> -koitsu@FreeBSD.org"> + +kishore@FreeBSD.org"> -krion@FreeBSD.org"> + +kjc@FreeBSD.org"> -kris@FreeBSD.org"> + +kmacy@FreeBSD.org"> -kuriyama@FreeBSD.org"> + +kmoore@FreeBSD.org"> -kwm@FreeBSD.org"> + +knu@FreeBSD.org"> -lars@FreeBSD.org"> + +koitsu@FreeBSD.org"> -laszlof@FreeBSD.org"> + +koobs@FreeBSD.org"> -lawrance@FreeBSD.org"> + +krion@FreeBSD.org"> -lbr@FreeBSD.org"> + +kris@FreeBSD.org"> -le@FreeBSD.org"> + +kuku@FreeBSD.org"> -leeym@FreeBSD.org"> + +kuriyama@FreeBSD.org"> -lesi@FreeBSD.org"> + +kwm@FreeBSD.org"> -lev@FreeBSD.org"> + +lars@FreeBSD.org"> -lile@FreeBSD.org"> + +laszlof@FreeBSD.org"> -linimon@FreeBSD.org"> + +lawrance@FreeBSD.org"> -lioux@FreeBSD.org"> + +lbr@FreeBSD.org"> -lippe@FreeBSD.org"> + +le@FreeBSD.org"> -ljo@FreeBSD.org"> + +leeym@FreeBSD.org"> -lkoeller@FreeBSD.org"> + +lesi@FreeBSD.org"> -lme@FreeBSD.org"> + +lev@FreeBSD.org"> -loader@FreeBSD.org"> + +lile@FreeBSD.org"> -lofi@FreeBSD.org"> + +linimon@FreeBSD.org"> -logo@FreeBSD.org"> + +lioux@FreeBSD.org"> -loos@FreeBSD.org"> + +lippe@FreeBSD.org"> -lstewart@FreeBSD.org"> + +ljo@FreeBSD.org"> -lth@FreeBSD.org"> + +lkoeller@FreeBSD.org"> -luigi@FreeBSD.org"> + +lme@FreeBSD.org"> -lulf@FreeBSD.org"> + +loader@FreeBSD.org"> -luoqi@FreeBSD.org"> + +lofi@FreeBSD.org"> -lwhsu@FreeBSD.org"> + +logo@FreeBSD.org"> -lx@FreeBSD.org"> + +loos@FreeBSD.org"> -madpilot@FreeBSD.org"> + +lstewart@FreeBSD.org"> -maho@FreeBSD.org"> + +lth@FreeBSD.org"> -makc@FreeBSD.org"> + +luigi@FreeBSD.org"> -mandree@FreeBSD.org"> + +lulf@FreeBSD.org"> -manolis@FreeBSD.org"> + +luoqi@FreeBSD.org"> -marcel@FreeBSD.org"> + +lwhsu@FreeBSD.org"> -marck@FreeBSD.org"> + +lx@FreeBSD.org"> -marcus@FreeBSD.org"> + +madpilot@FreeBSD.org"> -marius@FreeBSD.org"> + +maho@FreeBSD.org"> -markj@FreeBSD.org"> + +markj@FreeBSD.org"> -markm@FreeBSD.org"> + +markm@FreeBSD.org"> -marko@FreeBSD.org"> + +makc@FreeBSD.org"> -markp@FreeBSD.org"> + +mandree@FreeBSD.org"> -marks@FreeBSD.org"> + +manolis@FreeBSD.org"> -markus@FreeBSD.org"> + +marcel@FreeBSD.org"> -martin@FreeBSD.org"> + +marck@FreeBSD.org"> -martymac@FreeBSD.org"> + +marcus@FreeBSD.org"> -mat@FreeBSD.org"> + +marius@FreeBSD.org"> -matk@FreeBSD.org"> + +markm@FreeBSD.org"> -matteo@FreeBSD.org"> + +marko@FreeBSD.org"> -matthew@FreeBSD.org"> + +markp@FreeBSD.org"> -matusita@FreeBSD.org"> + +marks@FreeBSD.org"> -mav@FreeBSD.org"> + +markus@FreeBSD.org"> -max@FreeBSD.org"> + +martin@FreeBSD.org"> -maxim@FreeBSD.org"> + +martymac@FreeBSD.org"> -mb@FreeBSD.org"> + +mat@FreeBSD.org"> -mbarkah@FreeBSD.org"> + +matk@FreeBSD.org"> -mbr@FreeBSD.org"> + +matt@FreeBSD.org"> -mckay@FreeBSD.org"> + +matteo@FreeBSD.org"> -mckusick@FreeBSD.org"> + +matthew@FreeBSD.org"> -mdf@FreeBSD.org"> + +matusita@FreeBSD.org"> -mdodd@FreeBSD.org"> + +mav@FreeBSD.org"> -meganm@FreeBSD.rgo"> + +max@FreeBSD.org"> -melifaro@FreeBSD.org"> + +maxim@FreeBSD.org"> -metal@FreeBSD.org"> + +mb@FreeBSD.org"> -mezz@FreeBSD.org"> + +mbarkah@FreeBSD.org"> -mharo@FreeBSD.org"> + +mbr@FreeBSD.org"> -mheinen@FreeBSD.org"> + +mckay@FreeBSD.org"> -mi@FreeBSD.org"> + +mckusick@FreeBSD.org"> -mich@FreeBSD.org"> + +mdf@FreeBSD.org"> -mike@FreeBSD.org"> + +mdodd@FreeBSD.org"> -mikeh@FreeBSD.org"> + +meganm@FreeBSD.rgo"> -mini@FreeBSD.org"> + +melifaro@FreeBSD.org"> -mita@FreeBSD.org"> + +metal@FreeBSD.org"> -miwi@FreeBSD.org"> + +mezz@FreeBSD.org"> -mjacob@FreeBSD.org"> + +mharo@FreeBSD.org"> -mjg@FreeBSD.org"> + +mheinen@FreeBSD.org"> -mks@FreeBSD.org"> + +mi@FreeBSD.org"> -mlaier@FreeBSD.org"> + +mich@FreeBSD.org"> -mm@FreeBSD.org"> + +mike@FreeBSD.org"> -mnag@FreeBSD.org"> + +mikeh@FreeBSD.org"> -mohans@FreeBSD.org"> + +mini@FreeBSD.org"> -monthadar@FreeBSD.org"> + +mita@FreeBSD.org"> -motoyuki@FreeBSD.org"> + +miwi@FreeBSD.org"> -mp@FreeBSD.org"> + +mjacob@FreeBSD.org"> -mph@FreeBSD.org"> + +mjg@FreeBSD.org"> -mpp@FreeBSD.org"> + +mks@FreeBSD.org"> -mr@FreeBSD.org"> + +mlaier@FreeBSD.org"> -msmith@FreeBSD.org"> + +mm@FreeBSD.org"> -mtaylor@FreeBSD.org"> + +mnag@FreeBSD.org"> -mtm@FreeBSD.org"> + +mohans@FreeBSD.org"> -murray@FreeBSD.org"> + +monthadar@FreeBSD.org"> -mux@FreeBSD.org"> + +motoyuki@FreeBSD.org"> -mva@FreeBSD.org"> + +mp@FreeBSD.org"> -mwlucas@FreeBSD.org"> + +mph@FreeBSD.org"> -naddy@FreeBSD.org"> + +mpp@FreeBSD.org"> -nakai@FreeBSD.org"> + +mr@FreeBSD.org"> -nate@FreeBSD.org"> + +msmith@FreeBSD.org"> -nbm@FreeBSD.org"> + +mtaylor@FreeBSD.org"> -nectar@FreeBSD.org"> + +mtm@FreeBSD.org"> -neel@FreeBSD.org"> + +murray@FreeBSD.org"> -nemoliu@FreeBSD.org"> + +mux@FreeBSD.org"> -netchild@FreeBSD.org"> + +mva@FreeBSD.org"> -newton@FreeBSD.org"> + +mwlucas@FreeBSD.org"> -n_hibma@FreeBSD.org"> + +naddy@FreeBSD.org"> -niels@FreeBSD.org"> + +nakai@FreeBSD.org"> -nik@FreeBSD.org"> + +nate@FreeBSD.org"> -niklas@FreeBSD.org"> + +nbm@FreeBSD.org"> -nivit@FreeBSD.org"> + +nectar@FreeBSD.org"> -njl@FreeBSD.org"> + +neel@FreeBSD.org"> -nobutaka@FreeBSD.org"> + +nemoliu@FreeBSD.org"> -non@FreeBSD.org"> + +netchild@FreeBSD.org"> -nork@FreeBSD.org"> + +newton@FreeBSD.org"> -novel@FreeBSD.org"> + +n_hibma@FreeBSD.org"> -nox@FreeBSD.org"> + +niels@FreeBSD.org"> -np@FreeBSD.org"> + +nik@FreeBSD.org"> -nsayer@FreeBSD.org"> + +niklas@FreeBSD.org"> -nsj@FreeBSD.org"> + +nivit@FreeBSD.org"> -nsouch@FreeBSD.org"> + +njl@FreeBSD.org"> -nwhitehorn@FreeBSD.org"> + +nobutaka@FreeBSD.org"> -nyan@FreeBSD.org"> + +non@FreeBSD.org"> -obraun@FreeBSD.org"> + +nork@FreeBSD.org"> -obrien@FreeBSD.org"> + +novel@FreeBSD.org"> -ohauer@FreeBSD.org"> + +nox@FreeBSD.org"> -okazaki@FreeBSD.org"> + +np@FreeBSD.org"> -olah@FreeBSD.org"> + +nra@FreeBSD.org"> -oleg@FreeBSD.org"> + +nsayer@FreeBSD.org"> -olgeni@FreeBSD.org"> + +nsj@FreeBSD.org"> -oliver@FreeBSD.org"> + +nsouch@FreeBSD.org"> -olivierd@FreeBSD.org"> + +nwhitehorn@FreeBSD.org"> -olli@FreeBSD.org"> + +nyan@FreeBSD.org"> -onoe@FreeBSD.org"> + +obraun@FreeBSD.org"> -orion@FreeBSD.org"> + +obrien@FreeBSD.org"> -osa@FreeBSD.org"> + +ohauer@FreeBSD.org"> -pat@FreeBSD.org"> + +okazaki@FreeBSD.org"> -patrick@FreeBSD.org"> + +olah@FreeBSD.org"> -paul@FreeBSD.org"> + +oleg@FreeBSD.org"> -pav@FreeBSD.org"> + +olgeni@FreeBSD.org"> -pawel@FreeBSD.org"> + +oliver@FreeBSD.org"> -pb@FreeBSD.org"> + +olivierd@FreeBSD.org"> -pclin@FreeBSD.org"> + +olli@FreeBSD.org"> -pdeuskar@FreeBSD.org"> + +onoe@FreeBSD.org"> -pds@FreeBSD.org"> + +orion@FreeBSD.org"> -peadar@FreeBSD.org"> + +osa@FreeBSD.org"> -perky@FreeBSD.org"> + +pat@FreeBSD.org"> -petef@FreeBSD.org"> + +patrick@FreeBSD.org"> -peter@FreeBSD.org"> + +paul@FreeBSD.org"> -peterj@FreeBSD.org"> + +pav@FreeBSD.org"> -pfg@FreeBSD.org"> + +pawel@FreeBSD.org"> -pgj@FreeBSD.org"> + +pb@FreeBSD.org"> -pgollucci@FreeBSD.org"> + +pclin@FreeBSD.org"> -phantom@FreeBSD.org"> + +pdeuskar@FreeBSD.org"> -philip@FreeBSD.org"> + +pds@FreeBSD.org"> -phk@FreeBSD.org"> + +peadar@FreeBSD.org"> -pho@FreeBSD.org"> + +perky@FreeBSD.org"> -piero@FreeBSD.org"> + +petef@FreeBSD.org"> -pirzyk@FreeBSD.org"> + +peter@FreeBSD.org"> -piso@FreeBSD.org"> + +peterj@FreeBSD.org"> -pjd@FreeBSD.org"> + +pfg@FreeBSD.org"> -pluknet@FreeBSD.org"> + +pgj@FreeBSD.org"> -proven@FreeBSD.org"> + +pgollucci@FreeBSD.org"> -ps@FreeBSD.org"> + +phantom@FreeBSD.org"> -pst@FreeBSD.org"> + +philip@FreeBSD.org"> -qingli@FreeBSD.org"> + +phk@FreeBSD.org"> -rafan@FreeBSD.org"> + +pho@FreeBSD.org"> -raj@FreeBSD.org"> + +piero@FreeBSD.org"> -rakuco@FreeBSD.org"> + +pirzyk@FreeBSD.org"> -randi@FreeBSD.org"> + +piso@FreeBSD.org"> -ray@FreeBSD.org"> + +pjd@FreeBSD.org"> -rdivacky@FreeBSD.org"> + +pluknet@FreeBSD.org"> -rea@FreeBSD.org"> + +proven@FreeBSD.org"> -rees@FreeBSD.org"> + +ps@FreeBSD.org"> -reg@FreeBSD.org"> + +pst@FreeBSD.org"> -remko@FreeBSD.org"> + +qingli@FreeBSD.org"> -rene@FreeBSD.org"> + +rafan@FreeBSD.org"> -rgrimes@FreeBSD.org"> + +raj@FreeBSD.org"> -ricardag@FreeBSD.org"> + +rakuco@FreeBSD.org"> -rich@FreeBSD.org"> + +randi@FreeBSD.org"> -rik@FreeBSD.org"> + +ray@FreeBSD.org"> -rink@FreeBSD.org"> + +rdivacky@FreeBSD.org"> -rm@FreeBSD.org"> + +rea@FreeBSD.org"> -rmacklem@FreeBSD.org"> + +rees@FreeBSD.org"> -rmh@FreeBSD.org"> + +reg@FreeBSD.org"> -rnoland@FreeBSD.org"> + +remko@FreeBSD.org"> -rnordier@FreeBSD.org"> + +rene@FreeBSD.org"> -roam@FreeBSD.org"> + +rgrimes@FreeBSD.org"> -robert@FreeBSD.org"> + +ricardag@FreeBSD.org"> -roberto@FreeBSD.org"> + +rich@FreeBSD.org"> -rodrigc@FreeBSD.org"> + +rik@FreeBSD.org"> -roger@FreeBSD.org"> + +rink@FreeBSD.org"> -romain@FreeBSD.org"> + +rm@FreeBSD.org"> -rpaulo@FreeBSD.org"> + +rmacklem@FreeBSD.org"> -rpratt@FreeBSD.org"> + +rmh@FreeBSD.org"> -rrs@FreeBSD.org"> + +rnoland@FreeBSD.org"> -rse@FreeBSD.org"> + +rnordier@FreeBSD.org"> -rsm@FreeBSD.org"> + +roam@FreeBSD.org"> -rstone@FreeBSD.org"> + +robert@FreeBSD.org"> -ru@FreeBSD.org"> + +roberto@FreeBSD.org"> -rushani@FreeBSD.org"> + +rodrigc@FreeBSD.org"> -rv@FreeBSD.org"> + +roger@FreeBSD.org"> -rvb@FreeBSD.org"> + +romain@FreeBSD.org"> -rwatson@FreeBSD.org"> + +rpaulo@FreeBSD.org"> -ryusuke@FreeBSD.org"> + +rpratt@FreeBSD.org"> -sada@FreeBSD.org"> + +rrs@FreeBSD.org"> -sah@FreeBSD.org"> + +rse@FreeBSD.org"> -sahil@FreeBSD.org"> + +rsm@FreeBSD.org"> -sam@FreeBSD.org"> + +rstone@FreeBSD.org"> -sanpei@FreeBSD.org"> + +ru@FreeBSD.org"> -sat@FreeBSD.org"> + +rushani@FreeBSD.org"> -sbruno@FreeBSD.org"> + +rv@FreeBSD.org"> -sbz@FreeBSD.org"> + +rvb@FreeBSD.org"> -scf@FreeBSD.org"> + +rwatson@FreeBSD.org"> -scheidell@FreeBSD.org"> + +ryusuke@FreeBSD.org"> -schweikh@FreeBSD.org"> + +sada@FreeBSD.org"> -scop@FreeBSD.org"> + +sah@FreeBSD.org"> -scottl@FreeBSD.org"> + +sahil@FreeBSD.org"> -scrappy@FreeBSD.org"> + +sam@FreeBSD.org"> -se@FreeBSD.org"> + +sanpei@FreeBSD.org"> -sean@FreeBSD.org"> + +sat@FreeBSD.org"> -seanc@FreeBSD.org"> + +sbruno@FreeBSD.org"> -sef@FreeBSD.org"> + +sbz@FreeBSD.org"> -sem@FreeBSD.org"> + +scf@FreeBSD.org"> -semenu@FreeBSD.org"> + +scheidell@FreeBSD.org"> -sephe@FreeBSD.org"> + +schweikh@FreeBSD.org"> -sepotvin@FreeBSD.org"> + +scop@FreeBSD.org"> -sergei@FreeBSD.org"> + +scottl@FreeBSD.org"> -sf@FreeBSD.org"> + +scrappy@FreeBSD.org"> -shafeeq@FreeBSD.org"> + +se@FreeBSD.org"> -shaun@FreeBSD.org"> + +sean@FreeBSD.org"> -sheldonh@FreeBSD.org"> + +seanc@FreeBSD.org"> -shiba@FreeBSD.org"> + +sef@FreeBSD.org"> -shige@FreeBSD.org"> + +sem@FreeBSD.org"> -shin@FreeBSD.org"> + +semenu@FreeBSD.org"> -silby@FreeBSD.org"> + +sephe@FreeBSD.org"> -simokawa@FreeBSD.org"> + +sepotvin@FreeBSD.org"> -simon@FreeBSD.org"> + +sergei@FreeBSD.org"> -sjg@FreeBSD.org"> + +sf@FreeBSD.org"> -skreuzer@FreeBSD.org"> + +shafeeq@FreeBSD.org"> -skv@FreeBSD.org"> + +shaun@FreeBSD.org"> -smace@FreeBSD.org"> + +sheldonh@FreeBSD.org"> -smh@FreeBSD.org"> + +shiba@FreeBSD.org"> -smkelly@FreeBSD.org"> + +shige@FreeBSD.org"> -smpatel@FreeBSD.org"> + +shin@FreeBSD.org"> -snb@FreeBSD.org"> + +silby@FreeBSD.org"> -sobomax@FreeBSD.org"> + +simokawa@FreeBSD.org"> -sos@FreeBSD.org"> + +simon@FreeBSD.org"> -sperber@FreeBSD.org"> + +sjg@FreeBSD.org"> -sson@FreeBSD.org"> + +skreuzer@FreeBSD.org"> -ssouhlal@FreeBSD.org"> + +skv@FreeBSD.org"> -adam@redprince.net"> + +smace@FreeBSD.org"> -stark@FreeBSD.org"> + +smh@FreeBSD.org"> -stas@FreeBSD.org"> + +smkelly@FreeBSD.org"> -stb@FreeBSD.org"> + +smpatel@FreeBSD.org"> -stefan@FreeBSD.org"> + +snb@FreeBSD.org"> -stefanf@FreeBSD.org"> + +sobomax@FreeBSD.org"> -stephane@FreeBSD.org"> + +sos@FreeBSD.org"> -stephen@FreeBSD.org"> + +sperber@FreeBSD.org"> -steve@FreeBSD.org"> + +sson@FreeBSD.org"> -sumikawa@FreeBSD.org"> + +ssouhlal@FreeBSD.org"> -sunpoet@FreeBSD.org"> + +adam@redprince.net"> -suz@FreeBSD.org"> + +stark@FreeBSD.org"> -swallace@FreeBSD.org"> + +stas@FreeBSD.org"> -swills@FreeBSD.org"> + +stb@FreeBSD.org"> -sylvio@FreeBSD.org"> + +stefan@FreeBSD.org"> -syrinx@FreeBSD.org"> + +stefanf@FreeBSD.org"> -syuu@FreeBSD.org"> + +stephane@FreeBSD.org"> -tabthorpe@FreeBSD.org"> + +stephen@FreeBSD.org"> -tackerman@FreeBSD.org"> + +steve@FreeBSD.org"> -takawata@FreeBSD.org"> + +syuu@FreeBSD.org"> -tanimura@FreeBSD.org"> + +sumikawa@FreeBSD.org"> -taoka@FreeBSD.org"> + +sunpoet@FreeBSD.org"> -taras@FreeBSD.org"> + +suz@FreeBSD.org"> -tdb@FreeBSD.org"> + +swallace@FreeBSD.org"> -tedm@FreeBSD.org"> + +swills@FreeBSD.org"> -tegge@FreeBSD.org"> + +sylvio@FreeBSD.org"> -tg@FreeBSD.org"> + +syrinx@FreeBSD.org"> -thepish@FreeBSD.org"> + +tabthorpe@FreeBSD.org"> -theraven@FreeBSD.org"> + +tackerman@FreeBSD.org"> -thierry@FreeBSD.org"> + +takawata@FreeBSD.org"> -thomas@FreeBSD.org"> + +tanimura@FreeBSD.org"> -thompsa@FreeBSD.org"> + +taoka@FreeBSD.org"> -ticso@FreeBSD.org"> + +taras@FreeBSD.org"> -tijl@FreeBSD.org"> + +tdb@FreeBSD.org"> -timur@FreeBSD.org"> + +tedm@FreeBSD.org"> -tj@FreeBSD.org"> + +tegge@FreeBSD.org"> -tjr@FreeBSD.org"> + +tg@FreeBSD.org"> -tmclaugh@FreeBSD.org"> + +thepish@FreeBSD.org"> -tmm@FreeBSD.org"> + +theraven@FreeBSD.org"> -tmseck@FreeBSD.org"> + +thierry@FreeBSD.org"> -tobez@FreeBSD.org"> + +thomas@FreeBSD.org"> -tom@FreeBSD.org"> + +thompsa@FreeBSD.org"> -tomsoft@FreeBSD.org"> + +ticso@FreeBSD.org"> -torstenb@FreeBSD.org"> + +tijl@FreeBSD.org"> -toshi@FreeBSD.org"> + +timur@FreeBSD.org"> -tota@FreeBSD.org"> + +tj@FreeBSD.org"> -trasz@FreeBSD.org"> + +tjr@FreeBSD.org"> -trevor@FreeBSD.org"> + +tmclaugh@FreeBSD.org"> -trhodes@FreeBSD.org"> + +tmm@FreeBSD.org"> -trociny@FreeBSD.org"> + +tmseck@FreeBSD.org"> -truckman@FreeBSD.org"> + +tobez@FreeBSD.org"> -tshiozak@FreeBSD.org"> + +tom@FreeBSD.org"> -tuexen@FreeBSD.org"> + +tomsoft@FreeBSD.org"> -twinterg@FreeBSD.org"> + +torstenb@FreeBSD.org"> -uch@FreeBSD.org"> + +toshi@FreeBSD.org"> -ue@FreeBSD.org"> + +tota@FreeBSD.org"> -ugen@FreeBSD.org"> + +trasz@FreeBSD.org"> -uhclem@FreeBSD.org"> + +trevor@FreeBSD.org"> -ulf@FreeBSD.org"> + +trhodes@FreeBSD.org"> -ume@FreeBSD.org"> + +trociny@FreeBSD.org"> -unfurl@FreeBSD.org"> + +truckman@FreeBSD.org"> -ups@FreeBSD.org"> + +tshiozak@FreeBSD.org"> -uqs@FreeBSD.org"> + +tuexen@FreeBSD.org"> -vanhu@FreeBSD.org"> + +tweten@FreeBSD.org"> -vanilla@FreeBSD.org"> + +twinterg@FreeBSD.org"> -vd@FreeBSD.org"> + +uch@FreeBSD.org"> -versus@FreeBSD.org"> + +ue@FreeBSD.org"> -vg@FreeBSD.org"> + +ugen@FreeBSD.org"> -viny@FreeBSD.org"> + +uhclem@FreeBSD.org"> -vkashyap@FreeBSD.org"> + +ulf@FreeBSD.org"> -vs@FreeBSD.org"> + +ume@FreeBSD.org"> -vsevolod@FreeBSD.org"> + +unfurl@FreeBSD.org"> -vwe@FreeBSD.org"> + +ups@FreeBSD.org"> -wblock@FreeBSD.org"> + +uqs@FreeBSD.org"> -wen@FreeBSD.org"> + +vanhu@FreeBSD.org"> -weongyo@FreeBSD.org"> + +vanilla@FreeBSD.org"> -wes@FreeBSD.org"> + +vd@FreeBSD.org"> -wg@FreeBSD.org"> + +versus@FreeBSD.org"> -whiteside@acm.org"> + +vg@FreeBSD.org"> -wilko@FreeBSD.org"> + +viny@FreeBSD.org"> -will@FreeBSD.org"> + +vkashyap@FreeBSD.org"> -wjv@FreeBSD.org"> + +vs@FreeBSD.org"> -wkoszek@FreeBSD.org"> + +vsevolod@FreeBSD.org"> -wollman@FreeBSD.org"> + +vwe@FreeBSD.org"> -wosch@FreeBSD.org"> + +wblock@FreeBSD.org"> -wpaul@FreeBSD.org"> + +wen@FreeBSD.org"> -wsalamon@FreeBSD.org"> + +weongyo@FreeBSD.org"> -wsanchez@FreeBSD.org"> + +wes@FreeBSD.org"> -wxs@FreeBSD.org"> + +wg@FreeBSD.org"> -wylie@magnesium.net"> + +whiteside@acm.org"> -xride@FreeBSD.org"> + +wilko@FreeBSD.org"> -yar@FreeBSD.org"> + +will@FreeBSD.org"> -yoichi@FreeBSD.org"> + +wjv@FreeBSD.org"> -yokota@FreeBSD.org"> + +wkoszek@FreeBSD.org"> -yongari@FreeBSD.org"> + +wolf@FreeBSD.org"> -yzlin@FreeBSD.org"> + +wollman@FreeBSD.org"> -zack@FreeBSD.org"> + +wosch@FreeBSD.org"> -zarzycki@FreeBSD.org"> + +wpaul@FreeBSD.org"> -zec@FreeBSD.org"> + +wsalamon@FreeBSD.org"> -zeising@FreeBSD.org"> + +wsanchez@FreeBSD.org"> -zi@FreeBSD.org"> + +wxs@FreeBSD.org"> -zml@FreeBSD.org"> + +wylie@magnesium.net"> -znerd@FreeBSD.org"> + +xride@FreeBSD.org"> -zont@FreeBSD.org"> + +yar@FreeBSD.org"> + + +yoichi@FreeBSD.org"> + + +yokota@FreeBSD.org"> + + +yongari@FreeBSD.org"> + + +yzlin@FreeBSD.org"> + + +zack@FreeBSD.org"> + + +zarzycki@FreeBSD.org"> + + +zec@FreeBSD.org"> + + +zeising@FreeBSD.org"> + + +zi@FreeBSD.org"> + + +zml@FreeBSD.org"> + + +znerd@FreeBSD.org"> + + +zont@FreeBSD.org"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/share/xml/catalog.xml b/share/xml/catalog.xml index 178fe9fe4a..dce4f7cc75 100644 --- a/share/xml/catalog.xml +++ b/share/xml/catalog.xml @@ -1,110 +1,110 @@ + uri="authors.ent" /> diff --git a/share/xml/developers.ent b/share/xml/developers.ent deleted file mode 100644 index f2b528f015..0000000000 --- a/share/xml/developers.ent +++ /dev/null @@ -1,745 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/share/xml/freebsd.ent b/share/xml/freebsd.ent index c37ac7c99a..7e71a25862 100644 --- a/share/xml/freebsd.ent +++ b/share/xml/freebsd.ent @@ -1,108 +1,105 @@ #"> %"> UNIX"> NIS"> TeX'> LaTeX'> - - - [ OK ]"> [ Cancel ]"> [ Yes ]"> [ No ]"> diff --git a/share/xml/xhtml.xsl b/share/xml/xhtml.xsl index 3475bde690..fabedf276c 100644 --- a/share/xml/xhtml.xsl +++ b/share/xml/xhtml.xsl @@ -1,169 +1,199 @@

<xsl:value-of select="$title" />

&header1.googlejs;

&header2.skipnav;

&header2.topnav.label; &header2.topnav;

&nav.about; &nav.community; &nav.developers; &nav.docs; &nav.download; &nav.gnome; &nav.ports; &nav.support;

- + + + + + + + < + + + + + + + + mailto: + + + + + + + > + + + + + + + + + ©right;
&lastmod; diff --git a/share/xml/xhtml10-freebsd.dtd b/share/xml/xhtml10-freebsd.dtd index 4318ac5d52..dc6b573f98 100644 --- a/share/xml/xhtml10-freebsd.dtd +++ b/share/xml/xhtml10-freebsd.dtd @@ -1,63 +1,69 @@ %autogen.ent; %l10n.ent; %common.ent; %release.ent; %release.l10n.ent; %navibar.l10n.ent; %navibar.ent; %header.l10n.ent; %header.ent; - -%developers; + +%authors; %cvs; %html.orig; + + + diff --git a/share/xml/xslt10-freebsd.dtd b/share/xml/xslt10-freebsd.dtd index 635738aa23..28cb0d6b7b 100644 --- a/share/xml/xslt10-freebsd.dtd +++ b/share/xml/xslt10-freebsd.dtd @@ -1,77 +1,77 @@ %autogen.ent; %l10n.ent; %l10n-common.ent; %common.ent; %release.ent; %release.l10n.ent; %navibar.l10n.ent; %navibar.ent; %header.l10n.ent; %header.ent; %xslt10-orig.dtd; %iso8879.ent; diff --git a/share/xsl/freebsd-xhtml-common.xsl b/share/xsl/freebsd-xhtml-common.xsl index b8fbe90777..0a3db4ec30 100644 --- a/share/xsl/freebsd-xhtml-common.xsl +++ b/share/xsl/freebsd-xhtml-common.xsl @@ -1,311 +1,341 @@

This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.

book.html article.html

[ Split HTML / Single HTML ]

+ + + + + + < + + + + + + + + + + + mailto: + + + + + + + + > + + + + + 1

1 2 3 4 5 6

title

http://www.FreeBSD.org/cgi/man.cgi?query=

&sektion=

Introduction

FreeBSD Core Team <core@FreeBSD.org>

FreeBSD Documentation Engineering Team <doceng@FreeBSD.org>

FreeBSD Port Management Team <portmgr@FreeBSD.org>

Primary Release Engineering Team <re@FreeBSD.org>

Builders Release Engineering Team <re-builders@FreeBSD.org>

Donations Team <donations@FreeBSD.org>

Marketing Team <marketing@FreeBSD.org>

Security Team <secteam@FreeBSD.org>

Vendor Relations <vendor-relations@FreeBSD.org>

Core Team Secretary <core-secretary@FreeBSD.org>

Port Management Team Secretary <portmgr-secretary@FreeBSD.org>

Security Team Secretary <secteam-secretary@FreeBSD.org>

Accounts Team <accounts@>

Backups Administrators <backups@>

Bugmeisters & GNATS Administrators <bugmeister@FreeBSD.org>

Cluster Administrators <admins@>

CVSup Mirror Site Coordinators <cvsup-master@FreeBSD.org>

DNS Administrators <dnsadm@>

FTP/WWW Mirror Site Coordinators <mirror-admin@FreeBSD.org>

Perforce Repository Administrators <perforce-admin@FreeBSD.org>

Postmaster Team <postmaster@FreeBSD.org>

Subversion Administrators <svnadm@>

Webmaster Team <webmaster@FreeBSD.org>

Current Membership

New Doc Committers

Idle Doc Committers

Introduction

Table Of Contents

What musicians say about FreeBSD/ARM

Table Of Contents

Introduction

Status

Booting &os; kernels

Installing on the hard drive

Team Members

Resources Of Interest To FreeBSD Contributors and Developers

Resources Of General Interest

2005 Student Projects

FreeBSD Summer of Code 2005 in the Press

2006 Student Projects

Table of contents

How and where to report a FreeBSD security issue

Spam filters

The FreeBSD Security Officer Team and the FreeBSD Security Team

Information handling policies

Programme de sortie des prochaines versions

Statut du gel du code source

Documentation à propos de la sortie de nouvelles versions

Equipe chargée de la sortie des nouvelles versions

Foire aux Questions

õÞÁÓÔÎÉËÉ ÇÒÕÐÐÙ

äÏËÕÍÅÎÔÁÃÉÑ, ÉÍÅÀÝÁÑ ÏÔÎÏÛÅÎÉÅ Ë ÄÅÌÕ

&header2.word.search;

: