diff --git a/en_US.ISO8859-1/articles/5-roadmap/article.sgml b/en_US.ISO8859-1/articles/5-roadmap/article.sgml index baea651e6b..a93135ecde 100644 --- a/en_US.ISO8859-1/articles/5-roadmap/article.sgml +++ b/en_US.ISO8859-1/articles/5-roadmap/article.sgml @@ -1,670 +1,668 @@ %man; %freebsd; %authors; %teams; %mailing-lists; RELENG_3"> RELENG_4"> RELENG_5"> RELENG_5_1"> RELENG_5_2"> HEAD"> ]>
The Roadmap for 5-STABLE The &os; Release Engineering Team $FreeBSD$ 2003 The &os; Release Engineering Team Introduction and Background After nearly three years of work, &os; 5.0 was released in January of 2003. Features like the GEOM block layer, Mandatory Access Controls, ACPI, sparc64 and ia64 platform support, and UFS snapshots, background filesystem checks, and 64-bit inode sizes make it an exciting operating system for both desktop and production users. However, some important features are not complete. The foundations for fine-grained locking and preemption in the kernel exist, but much more work is left to be done. Work on Kernel Schedulable Entities (KSE), similar to Scheduler Activations, has been ongoing but needs a push to realize its benefit. Performance compared to &os; 4.X has declined and must be restored and surpassed. This is somewhat similar to the situation that &os; faced in the 3.X series. Work on 3-CURRENT trudged along seemingly forever, and finally a cry was made to just ship it and clean up later. This decision resulted in the 3.0 and 3.1 releases being very unsatisfying for most, and it wasn't until 3.2 that the series was considered stable. To make matters worse, the &t.releng.3; branch was created along with the 3.0 release, and the &t.releng.head; branch was allowed to advance immediately towards 4-CURRENT. This resulted in a quick divergence between &t.releng.head; and &t.releng.3;, making maintenance of the &t.releng.3; branch very difficult. &os; 2.2.8 was left for quite a while as the last production-quality version of &os;. Our intent is to avoid repeating that scenario with &os; 5.x. Delaying the &t.releng.5; branch until it is stable and production quality will ensure that it stays maintainable and provides a compelling reason to upgrade from 4.X, To do this, we must identify the current areas of weakness and set clear goals for resolving them. This document contains what we as the release engineering team feel are the milestones and issues that must be resolved for the &t.releng.5; branch. It does not dictate every aspect of &os; development, and we welcome further input. Nothing that follows is meant to be a sleight against any person or group, or to trivialize any work that has been done. There are some significant issues, though, that need decisive and unbiased action. Major issues The state of SMPng and kernel lockdown is the biggest concern for 5.X. To date, few major systems have come out from under the kernel-wide mutex known as Giant. - The SMP status page at - http://www.FreeBSD.org/smp provides a comprehensive breakdown + The SMP status page at + provides a comprehensive breakdown of the overall SMPng status. Status specific to SMPng progress in device drivers can be found at at - - http://www.FreeBSD.org/projects/busdma. In summary: + . + In summary: VM: the kmem_malloc(M_NOWAIT) path no longer needs Giant held. The kmem_malloc(M_WAITOK) path is in progress and is expected to be finished in the coming weeks. Other facets of the VM system, like the VFS interface, buffer/cache, etc, are largely untouched. GEOM: The GEOM block layer was designed to run free of Giant, but at this time no block drivers can run without Giant. Additionally, it has the potential to suffer performance loss due to its upcall/downcall data paths happening in kernel threads. Lightweight context switches might help this. Network: Locking of the TCP and UDP portions of the stack is complete. Work is in progress to lock up the IP stack, including the routing tree, ARP code, raw IP, and ifaddr and inet data structures. IPv6 has been lightly touched during the inp locking but is hindered by the KAME code being significantly out of date. Work has not started on any of the other protocols such as AppleTalk, XNS, or IPX. Locking of the socket layer is in progress but has been largely untested. None of the hardware drivers or Ethernet layers have been locked. VFS: Initial pre-cleanup started. buffer/cache: Initial work complete. Proc: Work on locking the proc structure was ongoing for a while but seems to have stalled. CAM: No significant work has occurred on the CAM SCSI layer. Newbus: some work has started on locking down the device_t structure. Pipes: complete with the exception of VM-related optimizations. File descriptors: complete. Process accounting: jails, credentials, MAC labels, and scheduler are out from under Giant. MAC Framework: complete Timekeeping: complete kernel encryption: crypto drivers and core &man.crypto.4; framework are Giant-free. KAME IPsec and FAST IPSec have not been locked. Sound subsystem: complete kernel preemption: preemption for interrupt threads is enabled. However, contention due to Giant covering much of the kernel and most of the device driver interrupt routines causes excessive context switches and might actually be hurting performance. Work is underway to explore ways to make preemption be conditional. Another issue with SMPng is interrupt latency. The overhead of doing a complete context switch to a kernel interrupt thread is high and shows noticeable latency. Work is ongoing to implement lazy context switching on all platforms. Fine grained locking of drivers will also help this, as will converting drivers to be as efficient as possible in their interrupt routines. Next, the state of KSE must resolved for &t.releng.5;. Work on it has slowed noticeably in the past 6 months but appears to be picking up again. There are a number of issues that must be addressed: The userland threading library, currently called libkse, is immature and has not been used for any significant threaded application. KSE has the potential to uncover latent race conditions and create new ones. An audit needs to be performed to ensure that no obvious problems exist. According to the release schedule below, KSE kernel and userland components must be functionality complete by June 2003 in order to be included in the &t.releng.5; branch. For security and stability reasons, if KSE cannot be finished in time then, by default, all KSE-specific syscalls should be modified to return ENOSYS and all other KSE-specific interfaces disabled. Deprecating KSE from &t.releng.5; but keeping it in the &t.releng.head; branch will pose problems in porting bugfixes and features between the two branches, so every effort should be made to finish it on time. Goals for 5-STABLE The goals for the &t.releng.5; branch point are: All subsystems and interfaces must be mature enough to be maintainable for improvements and bug fixes. Equal or better stability from &os; 4.8. No functional regressions from 4.8. It is important to make sure that users do not avoid upgrading to 5.x because of lost functionality. Performance on par with &os; 4.8 for most common operations. Both UP and SMP configurations should be evaluated. SMP has the potential to perform much better than 4.X, though for the purposes of creating the &t.releng.5; branch, comparable performance between the two should be acceptable. It is unrealistic to expect that the SMPng project will be fully complete by &t.releng.5;, or that performance will be significantly better than 4.X. However, focusing on a subset of the outstanding tasks will give enough benefit for the branch to be viable and maintainable. To break it down: ABI/API/Infrastructure stability - Enough infrastructure must be in place and stable to allow fixes from &t.releng.head; to easily and safely be merged into &t.releng.5;. Also, we must draw a line as to what subsystems are to be locked down when we go into 5-STABLE. SMPng VM: Most codepaths, others than the ones that interact with VFS, should be Giant-free for &t.releng.5;. Network: Taking the network stack out from under Giant poses the risk of uncovering latent bugs and races. Locking it down but not removing Giant imposes further performance penalties. A decision on which parts of the network stack should be locked and taken out from under Giant for &t.releng.5; should be made no later than March 15. Work on the IP, TCP, UDP,raw IP, routing sockets, and Unix domain sockets stands a good chance of being complete in time for &t.releng.5;. If the decision is made to not lift Giant from the stack, then the locks in these layers could be optimized out with a kernel config option. Having a Giant-free path from the the hardware layer to the IP queues should be investigated as it could allow significant performance gains in the network benchmarks. If this can be achieved then the hardware interface layer needs to allow for drivers to incrementally become free of Giant. Locking down at least two Ethernet drivers would be highly desirable. If the semantics are too complex to have the stack free of Giant but not the hardware drivers, investigation should be done into making it configurable. Lesser-used network stacks like netatalk, netipx, etc, should not break while this work is going on. However, locking them is not a high priority. Special kernel config options might be needed in order for these layers to operate with the rest of the stack being locked and Giant free. GEOM: At least 2 block drivers should be locked in order to demonstrate that others can also be locked without changing the interface to GEOM. The ATA driver is a good candidate for this, though caution should be taken as it is also extremely high-profile and any problems with it will affect nearly all users of &os;. Lazy context switching: sparc64 is the only platform that performs lazy context switching when entering the kernel. The performance gains promised by this are significant enough to require that it be implemented for all other Tier-1 platforms. KSE: The kernel side of KSE must be functionally complete and have undergone a security audit. libkse must be complete enough to demonstrate a real-world application running correctly on it using the standard POSIX Threads API. Examples would be apache 2.0, Java, and/or mozilla. A functional regression test suite is also a requirement for &t.releng.5; and should test signal delivery, scheduling, performance, and process security/credentials for both KSE and non-KSE processes. KSE kernel and userland components must also reach the same level of functionality for all Tier-1 platforms in both UP and SMP configurations. The definition of Tier-1 - platforms can be found in - http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html. + platforms can be found in + . busdma interface and drivers: architectures like PAE/i386 and sparc64 which don't have a direct mapping between host memory address space and expansion bus address space require the elimination for vtophys() and friends. The busdma interface was created to handle exactly this problem, but many drivers do not use it yet. The busdma project at - - http://www.FreeBSD.org/projects/busdma tracks the + + tracks the progress of this and should be used to determine which drivers must be converted for &t.releng.5; and which can be left behind. Also, there has been talk by several developers and the original author to give the busdma interface a minor overhaul. If this is to happen, it needs to happen before &t.releng.5;. Otherwise, differences between the old and new API will make driver maintenance difficult. PCI resource allocation: PC2003 compliance requires that x86 systems no longer configure PCI devices from the system BIOS, leaving this task solely to the OS. &os; must gain the ability to manage and allocate PCI memory resources on its own. Implementing this should take into account cardbus, PCI-HotPlug, and laptop dockstation requirements. This feature will become increasingly critical through the lifetime of &t.releng.5;, and therefore is a requirement for the &t.releng.5; branch. Performance: most performance gains hinge on the progress of SMPng Areas that should be concentrated on are: Storage I/O: I/O performance suffers from two problems, too many expensive context switches, and too much work being done in interrupt threads. Specifically, it takes 3 context switches for most drivers to get from the hardware completion interrupt to unblocking the user process: one for the interrupt thread, one for the GEOM g_up thread, and one to get back to the user thread. Drivers that attempt to be efficient and quick in their interrupt handlers (as all should be) usually also schedule a taskqueue, which adds a context switch in between the interrupt thread and the g_up thread and brings the total up to 4. Two things need to be done to attack this: Make all drivers defer most of their processing out of their interrupt thread. Significant performance gains have been shown recently in the &man.aac.4; driver by making its interrupt handler be INTR_MPSAFE and moving all processing to a taskqueue. investigate eliminating the taskqueue context switch by adding a callback to the g_up thread that allows a driver to do its interrupt processing there instead of in the taskqueue. Network: Network drivers suffer from the interrupt latency previously mentioned as well as from the network stack being partially locked down but not free from Giant. Possible strategies for addressing this are described in the previous section. Other locking - XXX? Benchmarks and performance testing: Having a source of reliable and useful benchmarks is essential to identifying performance problems and guarding against performance regressions. A performance team that is made up of people and resources for formulating, developing, and executing benchmark tests should be put into place soon. Comparisons should be made against both &os; 4.X and Linux 2.4.x. Tests to consider are: the classic worldstone webstone: www/webstone - Fstress: - http://www.cs.duke.edu/ari/fstress + Fstress: ApacheBench: www/p5-ApacheBench netperf: benchmarks/netperf - Web Polygraph: - http://www.web-polygraph.org Note: does not compile with - gcc 3.x yet. + Web Polygraph: + Note: does not compile with gcc 3.x yet. Features: ACPI: Intel's ACPI power management and device configuration subsystem has become an integral part of &os;'s x86 and ia64 device configuration model. However, many bugs exist in Intel's vendor code, our OS-specific code, and motherboard BIOSes, causing many ACPI-enabled systems to fail to boot, misdetect drivers, and/or have many other problems. Fixing these problems seems to be an uphill battle and is often times causing a poor first-impression of &os; 5.0. Most x86 systems can function with ACPI disabled, and logic should be added to the boot loader and sysinstall to allow users to easily and intuitively turn it off. Turning off ACPI by default is prone to problems also as many newer systems rely on it to provide correct interrupt routing information. Also, a centralized resource should be created to track ACPI problems and solutions. Linux uses the same Intel vendor sources as &os;, so we should investigate how they have handled some of the known problems. NEWCARD/OLDCARD: The NEWCARD subsystem was made the default for &os; 5.0. Unfortunately, it contains no support for non-Cardbus bridges and falls victim to interrupt routine problems on some laptops. The classic 16-bit bridge support, OLDCARD, still exists and can be compiled in, but this is highly inconvenient for users of older laptops. If OLDCARD cannot be completely deprecated for &t.releng.5;, then provisions must be made to allow users to easily install an OLDCARD-enabled kernel. Documentation should be written to help transition users from OLDCARD to NEWCARD and from &man.pccardd.8; to &man.devd.8;. The power management and dumpcis functionality of &man.pccardc.8; needs to be brought forward to work with NEWCARD, along with the ability to load CIS quirk entries. Most of this functionality can be integrated into &man.devd.8; and &man.devctl.4;. New scheduler framework: The new scheduler framework is in place, and users can select between the classic 44bsd scheduler and the new ULE scheduler. A scheduler that demonstrates processor affinity, HyperThreading and KSE awareness, and no regressions in performance or interactivity characteristics must be available for &t.releng.5;. sparc64 local console: neither syscons nor vt work on sparc64, leaving it with only serial and fake OFW console support. This is a major support hole for what is a Tier-1 platform. Whether syscons can be shoe-horned in or wscons be adopted from NetBSD is up for debate. However, sparc64 must have local console support for &t.releng.5;. Having this will also enable the XFree86 server to run, which is also a requirement for &t.releng.5;. gcc/toolchain: gcc 3.3 might be available in time for &t.releng.5; and might offer some attractive benefits, but also likely to introduce ABI incompatibility with prior gcc versions. ABI compatibility should be locked down for the &t.releng.5; branch. There has also been a request to move /usr/include/g++ to /usr/include/g++-v3 to be more compliant with the stock behavior of gcc. This should also be investigated for &t.releng.5;. gdb: gdb from the base system should work for sparc64. It should also understand KSE thread semantics, assuming that KSE is included in the &t.releng.5; branch. gdb 5.3 is available and there are reports that it should address the sparc64 issue. &man.disklabel.8; regressions: The biggest casualty of the introduction of GEOM appears to be the disklabel utility. The option gives unpredictable results in most cases now and should be removed or fixed. Work is planned for a new unified interface for modifying labels and slices, however this should not preclude disklabel from being fixed. Documentation: The manual pages, Handbook, and FAQ should be free from content specific to &os; 4.X, i.e. all text should be equally applicable to &os; 5.X. The installation section of the handbook needs the most work in this area. The release documentation needs to be complete and accurate for all Tier-1 architectures. The hardware notes and installation guides need specific attention. If &os; 5.1 is not the branch point for &t.releng.5; then the Early Adopters Guide needs to be updated. This document should then be removed just before the release closest to the &t.releng.5; branch point. Schedule If branching &t.releng.5; at the 5.1 release is paramount, 5.1 will probably need to move out by at least 3 months. The schedule would be: Jun 30, 2003: KSE and SMPng feature freeze Aug 4, 2003: 5.1-BETA, general code freeze Aug 18, 2003: 5.1-RC1, &t.releng.5; and &t.releng.5.1; branched Aug 25, 2003: 5.1-RC2 Sept 1, 2003: 5.1-RELEASE Taking an incremental approach might be more beneficial. Releasing 5.1 in time for USENIX ATC 2003 will provide a wide audience for productive feedback and will keep &os; visible. In this scenario, 5.1 should offer a significant improvement over 5.0 in terms of bug fixes and performance. Lockdowns and improvements to the storage subsystem and scheduler should be expected, the NEWCARD/OLDCARD issues should be addressed, and all known bugs and regressions from the 5.0 errata list should be fixed. KSE and other SMPng tasks that cannot finish in time for 5.1 should also not reduce the stability of the release. The schedule for this would be: May 5, 2003: 5.1-BETA, general code freeze May 19, 2003: 5.1-RC1, &t.releng.5.1; branched May 27, 2003: 5.1-RC2 Jun 2, 2003: 5.1-RELEASE Jun 30, 2003: KSE and SMPng feature freeze Sept 1, 2003: 5.2-BETA, general code freeze Sept 15, 2003: 5.2-RC1, &t.releng.5; and &t.releng.5.2; branched Sept 22, 2003: 5.2-RC2 Sept 29, 2003: 5.2-RELEASE Post &t.releng.5; direction As with all -STABLE development streams, the focus should be bug fixes and incremental improvements. Just like normal, everything should be vetted through the &t.releng.head; branch first and committed to &t.releng.5; with caution. As before, new device drivers, incremental features, etc, will be welcome in the branch once they have been proven in &t.releng.head;. Further SMPng lockdowns will be divided into two categories, driver and subsystem. The only subsystem that will be sufficiently locked down for &t.releng.5; will be GEOM, so incrementally locking down device drivers under it is a worthy goal for the branch. Full subsystem lockdowns will have to be fully tested and proven in &t.releng.head; before consideration will be given to merging them into &t.releng.5;.
diff --git a/en_US.ISO8859-1/articles/committers-guide/article.sgml b/en_US.ISO8859-1/articles/committers-guide/article.sgml index e55ea5c1e8..08080604e0 100644 --- a/en_US.ISO8859-1/articles/committers-guide/article.sgml +++ b/en_US.ISO8859-1/articles/committers-guide/article.sgml @@ -1,2868 +1,2861 @@ %man; %freebsd; %authors; %teams; %mailing-lists; ]>
Committer's Guide The FreeBSD Documentation Project $FreeBSD$ 1999 2000 2001 2002 2003 The FreeBSD Documentation Project This document provides information for the FreeBSD 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. Administrative Details Main Repository Host ncvs.FreeBSD.org Login Methods &man.ssh.1;, protocol 2 only Main CVSROOT ncvs.FreeBSD.org:/home/ncvs Main &a.cvs; &a.peter; and &a.markm;, as well as &a.joe; for ports/ Mailing Lists &a.developers;, &a.committers; (Both of these are private lists; archives can be found in /home/mail/developers-archive and /home/mail/committers-archive on the FreeBSD.org cluster.) Core Team monthly reports /home/core/public/monthly-report on the FreeBSD.org cluster. Noteworthy CVS Tags RELENG_4 (4.X-STABLE), HEAD (-CURRENT) It is required that you use &man.ssh.1; or &man.telnet.1; with Kerberos 5 to connect to the project hosts and only &man.ssh.1;, protocol 2 is allowed connecting to the repository host. These are generally more secure than plain &man.telnet.1; or &man.rlogin.1; since credential negotiation will always be encrypted. All traffic is encrypted by default with &man.ssh.1;. With utilities like &man.ssh-agent.1; and &man.scp.1; also available, &man.ssh.1; is also far more convenient. If you do not know anything about &man.ssh.1;, please see . Commit Bit Types The FreeBSD CVS 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 FreeBSD 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/, www/, 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. CVS Operations It is assumed that you are already familiar with the basic operation of CVS. The CVS repository is hosted on the repository machines. The &a.cvs; are the owners of the CVS repository and are responsible for direct modification of it for the purposes of cleanup or fixing some grievous abuse of CVS by a committer. Should you cause some repository accident, say a bad cvs import or cvs tag operation, mail the &a.cvs; (or call one of them) and report the problem to one of them. The only ones able to directly fiddle the repository bits on the repository hosts are the repomeisters. There are no login shells available on ncvs.FreeBSD.org, except to the repomeisters. CVS operations are done remotely by setting the CVSROOT environment variable to ncvs.FreeBSD.org:/home/ncvs and the CVS_RSH variable to ssh and then doing the appropriate check-out/check-in operations. If you wish to add something which is wholly new (like contrib-ified sources, etc), cvs import should be used. Refer to the &man.cvs.1; manual page for usage. Please do not use cvs checkout or update with the official repository machine set as the CVS Root for keeping your source tree up to date. Remote CVS is not optimized for network distribution and requires a big work/administrative overhead on the server side. Please use our advanced cvsup distribution method for obtaining the repository bits, and only do the actual commit operation on the repository host. We provide an extensive cvsup replication network for this purpose, as well as give access to cvsup-master if you really need to stay current to the latest changes. cvsup-master has got the horsepower to deal with this, the repository master server does not. &a.jdp; is in charge of cvsup-master. Many committers define an alias fcvs which aliases to cvs -d xxx@ncvs.FreeBSD.org:/home/ncvs for this purpose. That way they do all CVS operations locally and use fcvs commit for committing to the official CVS tree. If you need to use CVS add and delete operations in a manner that is effectively a &man.mv.1; operation, then a repository copy is in order rather than using CVS add and delete. In a repository copy, a CVS Meister will copy the file(s) to their new name and/or location and let you know when it is done. The purpose of a repository copy is to preserve file change history, or logs. We in the FreeBSD Project greatly value the change history that CVS gives to the project. CVS reference information, tutorials, and FAQs can be found at: - http://www.cvshome.org/docs/. + . The information in Karl Fogel's chapters from Open Source Development with CVS is also very useful. &a.des; also supplied the following mini primer for CVS. Check out a module with the co or checkout command. &prompt.user; cvs checkout shazam This checks out a copy of the shazam module. If there is no shazam module in the modules file, it looks for a top-level directory named shazam instead. Useful <command>cvs checkout</command> options Do not create empty directories Check out a single level, no subdirectories Check out revision, branch or tag rev Check out the sources as they were on date date
Practical FreeBSD examples: Check out the miscfs module, which corresponds to src/sys/miscfs: &prompt.user; cvs co miscfs You now have a directory named miscfs with subdirectories CVS, deadfs, devfs, and so on. One of these (linprocfs) is empty. Check out the same files, but with full path: &prompt.user; cvs co src/sys/miscfs You now have a directory named src, with subdirectories CVS and sys. The src/sys directory has subdirectories CVS and miscfs, etc. Check out the same files, but prunes empty directories: &prompt.user; cvs co -P miscfs You now have a directory named miscfs with subdirectories CVS, deadfs, devfs... but note that there is no linprocfs subdirectory, because there are no files in it. Check out the directory miscfs, but none of the subdirectories: &prompt.user; cvs co -l miscfs You now have a directory named miscfs with just one subdirectory named CVS. Check out the miscfs module as it is in the 4.X branch: &prompt.user; cvs co -rRELENG_4 miscfs You can modify the sources and commit along this branch. Check out the miscfs module as it was in 3.4-RELEASE. &prompt.user; cvs co -rRELENG_3_4_0_RELEASE miscfs You will not be able to commit modifications, since RELENG_3_4_0_RELEASE is a point in time, not a branch. Check out the miscfs module as it was on Jan 15 2000. &prompt.user; cvs co -D'01/15/2000' miscfs You will not be able to commit modifications. Check out the miscfs module as it was one week ago. &prompt.user; cvs co -D'last week' miscfs You will not be able to commit modifications. Note that cvs stores metadata in subdirectories named CVS. Arguments to and are sticky, which means cvs will remember them later, e.g. when you do a cvs update. Check the status of checked-out files with the status command. &prompt.user; cvs status shazam This displays the status of the file shazam or of every file in the shazam directory. For every file, the status is given as one of: Up-to-date File is up-to-date and unmodified. Needs Patch File is unmodified, but there is a newer revision in the repository. Locally Modified File is up-to-date, but modified. Needs Merge File is modified, and there is a newer revision in the repository. File had conflicts on merge There were conflicts the last time this file was updated, and they have not been resolved yet. You will also see the local revision and date, the revision number of the newest applicable version (newest applicable because if you have a sticky date, tag or branch, it may not be the actual newest revision), and any sticky tags, dates or options. Once you have checked something out, you can update it with the update command. &prompt.user; cvs update shazam This updates the file shazam or the contents of the shazam directory to the latest version along the branch you checked out. If you checked out a point in time, does nothing unless the tags have moved in the repository or some other weird stuff is going on. Useful options, in addition to those listed above for checkout: Check out any additional missing directories. Update to head of main branch. More magic (see below). If you checked out a module with or , running cvs update with a different or argument or with will select a new branch, revision or date. The option clears all sticky tags, dates or revisions whereas and set new ones. Theoretically, specifying HEAD as the argument to will give you the same result as , but that is just theory. The option is useful if: somebody has added subdirectories to the module you have checked out after you checked it out. you checked out with , and later change your mind and want to check out the subdirectories as well. you deleted some subdirectories and want to check them all back out. Watch the output of the cvs update with care. The letter in front of each filename indicates what was done with it: U The file was updated without trouble. P The file was updated without trouble (you will only see this when working against a remote repository). M The file had been modified, and was merged without conflicts. C The file had been modified, and was merged with conflicts. Merging is what happens if you check out a copy of some source code, modify it, then someone else commits a change, and you run cvs update. CVS notices that you have made local changes, and tries to merge your changes with the changes between the version you originally checked out and the one you updated to. If the changes are to separate portions of the file, it will almost always work fine (though the result might not be syntactically or semantically correct). CVS will print an M in front of every locally modified file even if there is no newer version in the repository, so cvs update is handy for getting a summary of what you have changed locally. If you get a C, then your changes conflicted with the changes in the repository (the changes were to the same lines, or neighboring lines, or you changed the local file so much that cvs can not figure out how to apply the repository's changes). You will have to go through the file manually and resolve the conflicts; they will be marked with rows of <, = and > signs. For every conflict, there will be a marker line with seven < signs and the name of the file, followed by a chunk of what your local file contained, followed by a separator line with seven = signs, followed by the corresponding chunk in the repository version, followed by a marker line with seven > signs and the revision number you updated to. The option is slightly voodoo. It updates the local file to the specified revision as if you used , but it does not change the recorded revision number or branch of the local file. It is not really useful except when used twice, in which case it will merge the changes between the two specified versions into the working copy. For instance, say you commit a change to shazam/shazam.c in &os.current; and later want to MFC it. The change you want to MFC was revision 1.15: Check out the &os.stable; version of the shazam module: &prompt.user; cvs co -rRELENG_4 shazam Apply the changes between rev 1.14 and 1.15: &prompt.user; cvs update -j1.14 -j1.15 shazam/shazam.c You will almost certainly get a conflict because - of the $Id: article.sgml,v 1.164 2003-04-10 23:40:43 keramida Exp $ (or in FreeBSD's case, + of the $Id: article.sgml,v 1.165 2003-04-11 01:11:36 keramida Exp $ (or in FreeBSD's case, $FreeBSD$) lines, so you will have to edit the file to resolve the conflict - (remove the marker lines and the second $Id: article.sgml,v 1.164 2003-04-10 23:40:43 keramida Exp $ line, - leaving the original $Id: article.sgml,v 1.164 2003-04-10 23:40:43 keramida Exp $ line intact). + (remove the marker lines and the second $Id: article.sgml,v 1.165 2003-04-11 01:11:36 keramida Exp $ line, + leaving the original $Id: article.sgml,v 1.165 2003-04-11 01:11:36 keramida Exp $ line intact). View differences between the local version and the repository version with the diff command. &prompt.user; cvs diff shazam shows you every modification you have made to the shazam file or module. Useful <command>cvs diff</command> options Uses the unified diff format. Uses the context diff format. Shows missing or added files.
You always want to use , since unified diffs are much easier to read than almost any other diff format (in some circumstances, context diffs generated with the option may be better, but they are much bulkier). A unified diff consists of a series of hunks. Each hunk begins with a line that starts with two @ signs and specifies where in the file the differences are and how many lines they span. This is followed by a number of lines; some (preceded by a blank) are context; some (preceded by a - sign) are outtakes and some (preceded by a +) are additions. You can also diff against a different version than the one you checked out by specifying a version with or as in checkout or update, or even view the diffs between two arbitrary versions (without regard for what you have locally) by specifying two versions with or . View log entries with the log command. &prompt.user; cvs log shazam If shazam is a file, this will print a header with information about this file, such as where in the repository this file is stored, which revision is the HEAD for this file, what branches this file is in, and any tags that are valid for this file. Then, for each revision of this file, a log message is printed. This includes the date and time of the commit, who did the commit, how many lines were added and/or deleted, and finally the log message that the committer who did the change wrote. If shazam is a directory, then the log information described above is printed for each file in the directory in turn. Unless you give the to log, the log for all subdirectories of shazam is printed too, in a recursive manner. Use the log command to view the history of one or more files, as it is stored in the CVS repository. You can even use it to view the log message of a specific revision, if you add the to the log command: &prompt.user; cvs log -r1.2 shazam This will print only the log message for revision 1.2 of file shazam if it is a file, or the log message for revision 1.2 of each file under shazam if it is a directory. See who did what with the annotate command. This command shows you each line of the specified file or files, along with which user most recently changed that line. &prompt.user; cvs annotate shazam Add new files with the add command. Create the file, cvs add it, then cvs commit it. Similarly, you can add new directories by creating them and then cvs adding them. Note that you do not need to commit directories. Remove obsolete files with the remove command. Remove the file, then cvs rm it, then cvs commit it. Commit with the commit or checkin command. Useful <command>cvs commit</command> options Force a commit of an unmodified file. Specify a commit message on the command line rather than invoking an editor.
Use the option if you realize that you left out important information from the commit message. Good commit messages are important. They tell others why you did the changes you did, not just right here and now, but months or years from now when someone wonders why some seemingly illogical or inefficient piece of code snuck into your source file. It is also an invaluable aid to deciding which changes to MFC and which not to MFC. Commit messages should be clear, concise and provide a reasonable summary to give an indication of what was changed and why. Commit messages should provide enough information to enable a third party to decide if the change is relevant to them and if they need to read the change itself. Avoid committing several unrelated changes in one go. It makes merging difficult, and also makes it harder to determine which change is the culprit if a bug crops up. Avoid committing style or whitespace fixes and functionality fixes in one go. It makes merging difficult, and also makes it harder to understand just what functional changes were made. In the case of documentation files, it can make the job of the translation teams more complicated, as it becomes difficult for them to determine exactly what content changes need to be translated. Avoid committing changes to multiple files in one go with a generic, vague message. Instead, commit each file (or small, related groups of files) with tailored commit messages. Before committing, always: verify which branch you are committing to, using cvs status. review your diffs, using cvs diff Also, ALWAYS specify which files to commit explicitly on the command line, so you do not accidentally commit other files than the ones you intended - cvs commit without any arguments will commit every modification in your current working directory and every subdirectory. Additional tips and tricks: You can place commonly used options in your ~/.cvsrc, like this: cvs -z3 diff -Nu update -Pd checkout -P This example says: always use compression level 3 when talking to a remote server. This is a life-saver when working over a slow connection. always use the (show added or removed files) and (unified diff format) options to &man.diff.1;. always use the (prune empty directories) and (check out new directories) options when updating. always use the (prune empty directories) option when checking out. Use Eivind Eklund's cdiff script to view unidiffs. It is a wrapper for &man.less.1; that adds ANSI color codes to make hunk headers, outtakes and additions stand out; context and garbage are unmodified. It also expands tabs properly (tabs often look wrong in diffs because of the extra character in front of each line). - - http://people.FreeBSD.org/~eivind/cdiff + Simply use it instead of &man.more.1; or &man.less.1;: &prompt.user; cvs diff -Nu shazam | cdiff Alternatively some editors like &man.vim.1; (editors/vim5) have color support and when used as a pager with color syntax highlighting switched on will highlight many types of file, including diffs, patches, and CVS/RCS logs. &prompt.user; echo "syn on" >> ~/.vimrc &prompt.user; cvs diff -Nu shazam | vim - &prompt.user; cvs log shazam | vim - CVS is old, arcane, crufty and buggy, and sometimes exhibits non-deterministic behavior which some claim as proof that it is actually merely the Newtonian manifestation of a sentient transdimensional entity. It is not humanly possible to know its every quirk inside out, so do not be afraid to ask the resident AI (&a.cvs;) for help. Do not leave the cvs commit command in commit message editing mode for too long (more than 2–3 minutes). It locks the directory you are working with and will prevent other developers from committing into the same directory. If you have to type a long commit message, type it before executing cvs commit, and insert it into the commit message. Conventions and Traditions As a new committer there are a number of things you should do first. Add yourself to the Developers section of the Contributors List and remove yourself from the Additional Contributors section. Once you have done that, do not forget to add your author entity to doc/en_US.ISO8859-1/share/sgml/authors.ent; use the other entries as example. This is a relatively easy task, but remains a good first test of your CVS skills. Add an entry for yourself to www/en/news/news.xml. Look for the other entries that look like A new committer and follow the format. If you have a PGP or GnuPG key, you may want to add it to doc/en_US.ISO8859-1/books/handbook/pgpkeys. &a.des; has written a shell script to make this extremely simple. See the README file for more information. 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. Introduce yourself to the other committers, 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 committer in FreeBSD. 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. If you are subscribed to the &a.cvsall;, you will probably want to unsubscribe to avoid receiving duplicate copies of commit messages and their followups. All new committers also have a mentor assigned to them for the first few months. Your mentor is more or less responsible for explaining anything which is confusing to you and is also responsible for your actions during this initial period. If you make a bogus commit, it is only going to embarrass your mentor and you should probably make it a policy to pass at least your first few commits by your mentor before committing it to the repository. All 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. 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 cvs-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 output of cvs log to see who has committed changes in the past. &a.fenner; 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 proprietary 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 CVS 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 CVS 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 FreeBSD, 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 FreeBSD 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: - - http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html + http://www.FreeBSD.org/support.html &man.send-pr.1; You can run a local copy of GNATS, and then integrate the FreeBSD GNATS tree in to it using CVSup. Then you can run GNATS commands locally, or use other interfaces, such as tkgnats. This lets you query the PR database without needing to be connected to the Internet. Using a local GNATS tree If you are not already downloading the GNATS tree, add this line to your supfile, and re-sup. Note that since GNATS is not under CVS control it has no tag, so if you are adding it to your existing supfile it should appear before any tag= entry as these remain active once set. gnats release=current prefix=/usr This will place the FreeBSD GNATS tree in /usr/gnats. You can use a refuse file to control which categories to receive. For example, to only receive docs PRs, put this line in /usr/local/etc/cvsup/sup/refuse The precise path depends on the *default base setting in your supfile. . gnats/[a-ce-z]* The rest of these examples assume you have only supped the docs category. Adjust them as necessary, depending on the categories you are syncing. Install the GNATS port from ports/databases/gnats. This will place the various GNATS directories under $PREFIX/share/gnats. Symlink the GNATS directories you are supping under the version of GNATS you have installed. &prompt.root; cd /usr/local/share/gnats/gnats-db &prompt.root; ln -s /usr/gnats/docs Repeat as necessary, depending on how many GNATS categories you are syncing. Update the GNATS categories file with these categories. The file is $PREFIX/share/gnats/gnats-db/gnats-adm/categories. # This category is mandatory pending:Category for faulty PRs:gnats-admin: # # FreeBSD categories # docs:Documentation Bug:freebsd-doc: Run $PREFIX/libexec/gnats/gen-index to recreate the GNATS index. The output has to be redirected to $PREFIX/share/gnats/gnats-db/gnats-adm/index. You can do this periodically from &man.cron.8;, or run &man.cvsup.1; from a shell script that does this as well. &prompt.root; /usr/local/libexec/gnats/gen-index \ > /usr/local/share/gnats/gnats-db/gnats-adm/index Test the configuration by querying the PR database. This command shows open docs PRs. &prompt.root; query-pr -c docs -s open Other interfaces, such as that provided by the databases/tkgnats port should also work nicely. Pick a PR and close it. This procedure only works to allow you to view and query the PRs locally. To edit or close them you will still have to log in to freefall and do it from there. Who's Who Besides the repository meisters, there are other FreeBSD 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.jhb; John is the manager of the SMPng Project, and has authority over the architectural design and implementation of the move to fine-grained kernel threading and locking. He's also the editor of the SMPng Architecture Document. If you are working on fine-grained SMP and locking, please coordinate with John. You can learn more about the - SMPng Project on its home page: - http://www.FreeBSD.org/smp/ + SMPng Project on its home page: + &a.jake;, &a.tmm; Jake and Thomas are the maintainers of the sparc64 hardware port. &a.doceng; doceng is the group responsible for the documentation build infrastructure, approving new documentation committers, and ensuring that the FreeBSD 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;. Committers interested in contributing to the documentation should familiarize themselves with the Documentation Project Primer. &a.ru; 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; 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 FreeBSD. &a.gallatin; &a.mjacob; &a.dfr; &a.obrien; These are the primary developers and overseers of the DEC Alpha AXP platform. &a.dg; David is the overseer of the VM system. If you have a VM system change in mind, coordinate it with David. &a.dfr; &a.marcel; &a.peter; &a.ps; These are the primary developers and overseers of the Intel IA-64 platform, officially known as the Itanium Processor Family (IPF). &a.murray; &a.steve; &a.rwatson; &a.jhb; &a.bmah; &a.scottl; 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. Bruce 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 Bruce knows about it. Better still, send him a patch with your suggested commentary. &a.benno; Benno is the official maintainer of the PowerPC port. &a.brian; Official maintainer of /usr/sbin/ppp. &a.nectar; Jacques is the FreeBSD Security Officer and oversees the &a.security-officer;. &a.wollman; 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 FreeBSD. &a.committers; cvs-committers is the entity that CVS uses to send you all your commit messages. You should never send email directly to this list. 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. This list is not intended as a place for code reviews or a replacement for the &a.arch; or the &a.audit;. In fact using it as such hurts the FreeBSD Project as it gives a sense of a closed list where general decisions affecting all of the FreeBSD using community are made without being open. Last, but not least never, never ever, email the &a.developers; and CC:/BCC: another FreeBSD list. Never, ever email another FreeBSD email list and CC:/BCC: the &a.developers;. Doing so can greatly diminish the benefits of this list. Also, never publicly post or forward emails sent to the &a.developers;. The act of sending to the &a.developers; vs. a public list means the information in the email is not for public consumption. SSH Quick-Start Guide If you are using FreeBSD 4.0 or later, OpenSSH is included in the base system. If you are using an earlier release, update and install one of the SSH ports. In general, you will probably want to get OpenSSH from the security/openssh port. You may also wish to check out the original ssh1 in the security/ssh port, but make certain you pay attention to its license. Note that both of these ports cannot be installed at the same time. 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 file. 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/identity.pub) to the person setting you up as a committer so it can be put into your authorized_keys file in your home directory on freefall (i.e. $HOME/.ssh/authorized_keys). 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;. The FreeBSD 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, and 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 have 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 CVS 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 surprised 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 FreeBSD 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 + url="../../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 CVS logs for the file(s) in question and see if someone has been working recently or predominantly in that area. Other areas of FreeBSD fall under the control of someone who manages an overall category of FreeBSD evolution, such as internationalization or networking. See http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-who.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 CVS 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 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_4_5) 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 FreeBSD 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. Currently, this is only the x86 and the Alpha so it is pretty easy to do. If you need to test on the AXP, your account on beast.FreeBSD.org will let you compile and test Alpha binaries/kernels/etc. As other architectures are added to the FreeBSD 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 FreeBSD-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 FreeBSD has added several new arch ports during the 5.0 release cycle and is truly no longer an i386-centric operating system. In an effort to make it easier to keep FreeBSD portable across the platforms we support, core has developed the following mandate:
Our 32 bit reference platform is i386, and our 64 bit reference platform is 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 i386 and sparc64 platforms were chosen due to being more readily available to developers and as representatives of more diverse processor and system designs - big vs little endian, register file vs register stack, different DMA and cache implementations, hardware page tables vs software TLB management etc. While the Alpha is a 64 bit processor, it is a more traditional processor design and does not provide as good a testbed for many of the challenges that the other 64 bit platform ports face. The ia64 platform has many of the same complications that 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 using cvs diff, 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 FreeBSD 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 FreeBSD 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 FreeBSD "target audience". Statement of General Intent The FreeBSD 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 FreeBSD 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, as well as security officer and release engineering teams. Diversity in hardware support broadens the options for FreeBSD consumers by offering new features and usage opportunities (such as support for 64-bit CPUs, use in embedded environments), but these benefits always be carefully considered in terms of the real-world maintenance cost associated with additional platform support. The FreeBSD 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 under 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 easily available for all developers. Tier 1 architectures are expected to be Production Quality with respects to all aspects of the FreeBSD operating system, including installation and development environments. Current Tier 1 platforms are i386, sparc64, PC98, and Alpha. Tier 2: Developmental Architectures Tier 2 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. New features added to FreeBSD should be feasible to implement on these platforms, but an implementation is not required before the feature may be added to the FreeBSD source tree. The implementation of a Tier 2 architecture may be committed to the main FreeBSD 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 FreeBSD base source tree, the platform must be able to boot to at least single-user mode on real world commodity hardware. Some exceptions to these rules may be made for new hardware that is under development by hardware vendors, but not yet available to the project. 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. Current Tier 2 platforms are PowerPC, and ia64. 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 for which hardware is not or will not be available to the project in the foreseeable future, for which there are two or fewer active developers, that can not boot to at least single-user mode on real hardware (or simulator for new hardware platforms), or which are considered legacy systems unlikely to see broad future use. Tier 3 systems will not be committed to the base source tree, although support for Tier 3 systems may be worked on in the FreeBSD Perforce Repository, providing source control and easier change integration from the main FreeBSD tree. Current Tier 3 platforms are S/390 and x86-64. 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 tier by approval of the FreeBSD 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 on freefall. 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 CVSROOT/modules file and the port's category Makefile. It was written by &a.mharo; and &a.will;, but Will is the current maintainer so please send questions/patches about addport to him. 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 FreeBSD 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. 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, please send mail to the ports manager asking about it. 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. When do we not need a repository copy? When there is no history to preserve. If a port is added into a wrong category and is moved immediately, it suffices to simply cvs remove the old one and addport the new one. What do I need to do? Send mail to &a.portmgr;, listing the reasons for the repository copy request. If &a.portmgr approves it, &a.cvs; will do a repository copy from the old to the new location and/or name. Once you receive notification that everything is done, perform the following: When a port has been repo copied: Upgrade the copied port to the new version (remember to change the PORTNAME so there are not duplicate ports with the same name). 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 the new module entry. 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, the old SUBDIR entry and the old module entry. 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. How long is a ports freeze? Usually an hour or two. What does it mean to me? During the ports freeze, you are not allowed to commit anything to the tree without explicit approval from the ports manager. Explicit approval here means either of the following: You asked the ports manager and got a reply saying, Go ahead and commit it. The ports manager sent a mail to you or the mailing lists during the ports freeze pointing out that the port is broken and has to be fixed. Note that you do not have implicit permission to fix a port during the freeze just because it is broken. How do I know when the ports freeze starts? The ports manager 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 freeze has to be synchronized with the release, and it is usually not known until then when exactly the release will be rolled. When the freeze starts, there will be another announcement to the &a.committers;, of course. How do I know when the ports freeze ends? A few hours after the release, the ports manager will send out a mail to the &a.ports; and &a.committers; announcing the end of the ports freeze. Note that the release being cut does not automatically end the freeze. We have to make sure there will not be any last minute snafus that result in an immediate re-rolling of the release. Miscellaneous Questions How do I know if my port is building correctly or not? First, go check - - http://bento.FreeBSD.org/errorlogs/. - + . 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.) Here are the relevant directories on bento, so feel free to dig around. /a/asami/portbuild/<arch>/<major_version>/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. The ports manager will regenerate the INDEX and commit it every few days. 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 manager 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. 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: Direct access to cvsup-master As a committer, you may apply to &a.jdp; for direct access to cvsup-master.FreeBSD.org, providing the public key output from cvpasswd yourusername@FreeBSD.org freefall.FreeBSD.org. Please note: you must specify freefall.FreeBSD.org on the cvpasswd command line even though the actual server is cvsup-master. Access to cvsup-master should not be overused as it is a busy machine. A Free DVD Subscription FreeBSD Services Limited offer a free DVD subscription to - FreeBSD committers. To take advantage of this offer, go to - www.freebsd-services.com and fill out their customer form, + FreeBSD committers. To take advantage of this offer, go to + + and fill out their customer form, making sure that you tick the FreeBSD Committer and free subscription check-boxes. A message will be sent to your FreeBSD.org email address asking for confirmation. Just reply to the mail, quoting the message and updating the Membership Valid field with a Y. You can confirm that the reply was sent successfully by logging in to their site and checking that your Current Status is set to Associated. In addition to the free subscription, committers are also entitled to a 10% discount on all products on the site. A Free 4-CD Set Subscription FreeBSD Mall, Inc. offers a free subscription of the 4-CD set or the DVD product to all FreeBSD committers. Information about how to obtain your free media is mailed to developers@FreeBSD.org following each major release. 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. The option does not work very well. Ask &a.obrien; for horror stories. How do I add a new file to a CVS 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 cvs add as you normally would. For example, if you wanted to MFC the file src/sys/alpha/include/smp.h from HEAD to RELENG_4 and it does not exist in RELENG_4 yet, you would use the following steps: MFC'ing a New File &prompt.user; cd sys/alpha/include &prompt.user; cvs update -rRELENG_4 cvs update: Updating . U clockvar.h U console.h ... &prompt.user; cvs update -kk -Ap smp.h > smp.h =================================================================== Checking out smp.h RCS: /usr/cvs/src/sys/alpha/include/smp.h,v VERS: 1.1 *************** &prompt.user; cvs add smp.h cvs add: scheduling file `smp.h' for addition on branch `RELENG_4' cvs add: use 'cvs commit' to add this file permanently &prompt.user; cvs commit 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 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 FreeBSD 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 FreeBSD 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 FreeBSD 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. 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 people.FreeBSD.org. + 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 FreeBSD cluster.
diff --git a/en_US.ISO8859-1/articles/contributors/article.sgml b/en_US.ISO8859-1/articles/contributors/article.sgml index d46b086eaf..281f735178 100644 --- a/en_US.ISO8859-1/articles/contributors/article.sgml +++ b/en_US.ISO8859-1/articles/contributors/article.sgml @@ -1,9211 +1,9211 @@ %man; %authors; %teams; %mailing-lists; ]>
Contributors to FreeBSD $FreeBSD$ This article lists individuals and organizations who have made a contribution to FreeBSD. Donors Gallery 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, 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; Blue Mountain Arts Epilogue Technology Corporation &a.sef; Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr; 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;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de 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 ftp://ftp.tekram.com/scsi/FreeBSD/. + url="ftp://ftp.tekram.com/scsi/FreeBSD/">. 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 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 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 Core Team 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. (in alphabetical order by last name): &a.jhb; &a.kuriyama; &a.grog; &a.imp; &a.markm; &a.wes; &a.murray; &a.rwatson; &a.peter; 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): &a.akiyama; &a.jmas; &a.ambrisko; &a.will; &a.anholt; &a.babkin; &a.dbaker; &a.jhb; &a.dmlb; &a.mike; &a.dougb; &a.tobez; &a.pb; &a.abial; &a.jb; &a.nbm; &a.mbr; &a.torstenb; &a.mb; &a.harti; &a.obraun; &a.jmb; &a.brueffer; &a.wilko; &a.jake; &a.dburr; &a.adrian; &a.perky; &a.dwcjr; &a.charnier; &a.jon; &a.luoqi; &a.ache; &a.seanc; &a.kjc; &a.cjh; &a.cjc; &a.marcus; &a.nik; &a.archie; &a.chris; &a.alc; &a.cracauer; &a.dec; &a.davidc; &a.ceri; &a.brooks; &a.bsd; &a.jwd; &a.pdeuskar; &a.mdodd; &a.dd; &a.iedowse; &a.robert; &a.gad; &a.tegge; &a.deischen; &a.eivind; &a.alane; &a.julian; &a.rse; &a.ue; &a.ru; &a.se; &a.bde; &a.sef; &a.jedgar; &a.green; &a.fenner; &a.lioux; &a.fanf; &a.blackend; &a.scrappy; &a.lars; &a.petef; &a.dirk; &a.sf; &a.shige; &a.billf; &a.furuta; &a.gallatin; &a.patrick; &a.tg; &a.gibbs; &a.brandon; &a.gioria; &a.daichi; &a.cg; &a.edwin; &a.znerd; &a.hanai; &a.roger; &a.mharo; &a.dannyboy; &a.jhay; &a.sheldonh; &a.mikeh; &a.mheinen; &a.ghelmer; &a.mux; &a.cshumway; &a.chm; &a.nhibma; &a.flathill; &a.orion; &a.horikawa; &a.hosokawa; &a.cognet; &a.jeh; &a.hsu; &a.foxfair; &a.jkh; &a.tom; &a.mph; &a.iwasaki; &a.mjacob; &a.keith; &a.gj; &a.trevor; &a.kan; &a.phk; &a.tomsoft; &a.cokane; &a.johan; &a.joe; &a.kato; &a.kris; &a.keramida; &a.fjoe; &a.kiri; &a.andreas; &a.ikob; &a.lkoeller; &a.motoyuki; &a.maxim; &a.jkoshy; &a.rushani; &a.kuriyama; &a.alex; &a.njl; &a.reg; &a.chern; &a.leeym; &a.sam; &a.stephane; &a.netchild; &a.jlemon; &a.truckman; &a.glewis; &a.pat; &a.ijliao; &a.clive; &a.arved; &a.kevlo; &a.scottl; &a.ade; &a.mwlucas; &a.smace; &a.bmah; &a.mtm; &a.jmallett; &a.dwmalone; &a.nobutaka; &a.matusita; &a.mckay; &a.mckusick; &a.eric; &a.ken; &a.dinoex; &a.hm; &a.sanpei; &a.bmilekic; &a.mini; &a.mita; &a.non; &a.jim; &a.marcel; &a.emoore; &a.amorita; &a.dan; &a.tmm; &a.markm; &a.knu; &a.nakai; &a.max; &a.maho; &a.yoichi; &a.anders; &a.rnordier; &a.obrien; &a.danny; &a.okazaki; &a.olgeni; &a.onoe; &a.wpaul; &a.mp; &a.roam; &a.alfred; &a.wes; &a.gerald; &a.jdp; &a.bp; &a.rpratt; &a.steve; &a.mpp; &a.markp; &a.thomas; &a.darrenr; &a.greid; &a.mr; &a.arr; &a.trhodes; &a.benno; &a.paul; &a.luigi; &a.tjr; &a.jeff; &a.roberto; &a.chuckr; &a.jesusr; &a.guido; &a.groudier; &a.dima; &a.ps; &a.sada; &a.hrs; &a.nsayer; &a.sos; &a.wosch; &a.cy; &a.das; &a.schweikh; &a.gshapiro; &a.arun; &a.shiba; &a.nork; &a.tshiozak; &a.simokawa; &a.vanilla; &a.silby; &a.shafeeq; &a.demon; &a.jesper; &a.skv; &a.scop; &a.msmith; &a.ben; &a.des; &a.sobomax; &a.dcs; &a.brian; &a.nsouch; &a.murray; &a.sumikawa; &a.gsutter; &a.suz; &a.unfurl; &a.nyan; &a.tanimura; &a.taoka; &a.mi; &a.gordon; &a.yar; &a.cwt; &a.ume; &a.semenu; &a.rv; &a.hoek; &a.logo; &a.nectar; &a.jayanth; &a.wjv; &a.bean; &a.ticso; &a.takawata; &a.adamw; &a.naddy; &a.assar; &a.dwhite; &a.nate; &a.wollman; &a.keichii; &a.joerg; &a.kbyanc; &a.jennifer; &a.yokota; &a.andy; &a.zarzycki; &a.phantom; &a.jmz; The FreeBSD Documentation Project The FreeBSD Documentation Project is responsible for a number of different services, each service being run by an individual and his deputies (if any): Documentation Project Architect &a.nik; Handbook Editor &a.doc; FAQ Editor &a.doc; News Editor &a.jim; In the Press Editor &a.jkoshy; FreeBSD Really-Quick NewsLetter Editor Chris Coleman chrisc@vmunix.com Gallery Editor &a.phantom; Commercial Gallery Editor &a.ceri; User Groups Editor &a.grog; FreeBSD Java Project &a.patrick; LinuxDoc to DocBook conversion &a.nik; Who is Responsible for What Documentation Project Manager &a.nik; CVSup Mirror Site Coordinator &a.jdp; Internationalization &a.ache; Postmaster &a.jmb; Release Coordination &a.re; headed by &a.murray; Public Relations & Corporate Liaison Seat open Security Officers &a.security-officer; headed by &a.nectar; Source Repository Managers Principal: &a.peter; Assistants: &a.markm;, &a.joe; Website Management &a.www; Ports Manager &a.portmgr; which includes: &a.asami;, &a.knu;, &a.kris;, &a.lioux;, &a.sobomax;, &a.steve;, &a.will; Standards &a.wollman; XFree86 Project, Inc. Liaison &a.rich; GNATS Administrator &a.steve; Bugmeister &a.keramida; Donations Liaison Office &a.donations; which includes: &a.mwlucas &a.nsayer &a.obrien &a.rwatson &a.trhodes 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 chronological order: &a.dg; (1992 - 2002) &a.dfr; (1999 - 2002) &a.msmith; (2000 - 2002) &a.jkh; (1992 - 2002) &a.asami; (1993 - 2001) &a.ache; (1993 - 2000) &a.jmb; (1993 - 2000) &a.bde; (1992 - 2000) &a.gibbs; (1993 - 2000) &a.rich; (1994 - 2000) &a.phk; (1992 - 2000) &a.gpalmer; (1993 - 2000) &a.sos; (1993 - 2000) &a.wollman; (1993 - 2000) &a.joerg; (1995 - 2000) &a.jdp; (1997 - 2000) &a.guido; (1995 - 1999) John Dyson (1993 - 1998) &a.nate; (1992 - 1996) &a.rgrimes; (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr; (1993 - 1995) &a.paul; (1992 - 1995) &a.smace; (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) 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 chronological order: &a.amurai; (1995 - 2003) &a.jfitz; (1996 - 2003) &a.stb; (1994 - 2003) &a.csgr; (1994 - 2003) &a.mtaylor; (1999 - 2003) &a.pho; (1999 - 2003) &a.dufault; (1995 - 2003) &a.wsanchez; (2000 - 2003) &a.imura; (1999 - 2003) &a.cpiazza; (1999 - 2003) &a.davidn; (1996 - 2003) &a.jseger; (1997 - 2003) &a.jmg; (1997 - 2003) &a.toshi; (2000 - 2003) &a.newton; (1999 - 2003) &a.marko; (2000 - 2003) &a.lile; (1999 - 2003) &a.cp; (1999 - 2003) &a.ejc; (1999 - 2003) &a.shin; (1999 - 2003) &a.gpalmer; (1993 - 2003) &a.fsmp; (1997 - 2003) &a.rgrimes; (1992 - 2003) &a.mks; (1994 - 2003) &a.dt; (1998 - 2003) &a.jfieber; (1995 - 2003) &a.rvb; (1998 - 2003) &a.stark; (1997 - 2003) &a.helbig; (1997 - 2003) &a.thepish; (1998 - 2003) &a.adam; (1994 - 2003) &a.mbarkah; (1996 - 2003) &a.pds; (1997 - 2003) &a.smpatel; (1996 - 2003) &a.uhclem; (1997 - 2003) &a.swallace; (1994 - 2003) &a.rich; (1994 - 2003) &a.ugen; (1994 - 2003) &a.ljo; (1994 - 2003) &a.pirzyk; (2001 - 2003) &a.dillon; (1998 - 2003) &a.dick; (1999 - 2003) &a.pst; (1994 - 2003) &a.erich; (1995 - 2002) &a.jasone; (1999 - 2002) &a.martin; (1994 - 2002) &a.graichen; (1996 - 2002) &a.asmodai; (1999 - 2002) &a.uch; (2000 - 2002) &a.jmacd; (1995 - 2002) &a.issei; (2000 - 2002) &a.itojun; (1997 - 2001) Nate Johnson (1996 - 2000) MAEKAWA Masahide (1999 - 2000) &a.tedm; (???? - 2000) &a.karl; (1995 - 2000) Gary Clark II (1993 - 2000) James Raynard (1996 - 2000) Andreas Schulz (1992 - 1999) &a.jgreco; (1997 - 1999) Jamil Weatherby (1997 - 1999) Megan McCormack (1997 - 1998) John Dyson (1993 - 1998) Amancio Hasty (1997 - 1998) Drew Derbyshire (1997 - 1998) Andras Olah (1995 - 1996) Julian H. Stacey (1995) gjp (1995) Andrew L. Moore (1993 - 1995) 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): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam Herzog adam@herzogdesigns.com Adam Kranzel adam@alameda.edu Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com Adrian Colley aecolley@ois.ie Adrian Hall ahall@mirapoint.com Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex D. Chen dhchen@elearning.nsysu.edu.tw Alex Dupre sysadmin@alexdupre.com Alex G. Bulushev bag@demos.su Alex Kapranoff kappa@zombie.antar.bryansk.ru Alex Le Heux alexlh@funk.org Alex Perel veers@disturbed.net Alex Rodioukov simuran@shaw.ca Alex Semenyaka alex@rinet.ru Alex Varju varju@webct.com Alex Zepeda garbanzo@hooked.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexandre Peixoto alexandref@tcoip.com.br Alexandre Snarskii snar@paranoia.ru Alexey Dokuchaev danfe@regency.nsu.ru Alexey V. Neyman alex.neyman@auriga.ru Alexis Yushin alexis@forest.NLnetLabs.nl 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 Amy Baron amee@beer.org Anatoliy Dmytriyev tolid@plab.ku.dk Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Andersson anders@codefactory.se Anders Thulin Anders.X.Thulin@telia.se Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Goeree abgoeree@uwnet.nl Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew P. Lentvorski bsder@allcaps.org 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 Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andrey Simonenko simon@comsys.ntu-kpi.kiev.ua Andrey Sverdlichenko rblaze@users.sourceforge.net Andrey Tchoritch andy@venus.sympad.net Andy Farkas andyf@speednet.com.au Andy Sparrow spadger@best.com Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angel Todorov todorov_bg@gmx.net Angelo Turetta ATuretta@stylo.it Anthony C. Chavez acc@anthonychavez.org Anthony Yee-Hang Chan yeehang@netcom.com Antoine Beaupre anarcat@anarcat.ath.cx Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Anton Voronin anton@urc.ac.ru Antti Kaipila anttik@iki.fi Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji raja@moselle.com Arjan de Vet devet@IAEhv.nl Arnaud S. Launay asl@launay.org Arne Henrik Juul arnej@Lise.Unit.NO Ashley Penney ashp@unloved.org Ask Bjoern Hansen ask@valueclick.com Atsushi Furuta furuta@sra.co.jp Atushi Sakauchi sakauchi@yamame.to Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Walter bwalter@itachi.swcp.com Benedikt Köhler benedikt@furukama.de Benjamin Lewis bhlewis@gte.net Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd R. Faulkner faulkner@asgard.bga.com Brad Chapman chapmanb@arches.uga.edu Brad Davis so14k@so14k.com Brad Hendrickse bradh@uunet.co.za Brad Jones brad@kazrak.com Brad Karp karp@eecs.harvard.edu Brad Lanam bll@gentoo.com Bill Lloyd wlloyd@mpd.ca Bradley Dunn bradley@dunn.org Bram Moolenaar bram@moolenaar.net Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com 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 Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu 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 M Simpson bms@spc.org Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Camson Huynh chuynh@biolateral.com.au Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Carl Schmidt carl@perlpimp.codersluts.net Casper casper@acc.am Castor Fu castor@geocast.com 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 Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Pepper pepper@mail.rockefeller.edu 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 Zander zander@minion.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christophe Juniet cjuniet@entreview.com Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher K. Davis ckd-freebsd@ckdhr.com Christopher N. Harrell cnh@ivmg.net Christopher Preston rbg@gayteenresource.org Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@home.com Constantin S. Svintsoff kostik@iclub.nsu.ru Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cyrille Lefevre clefevre@citeweb.net Cyrus Rahman cr@jcmax.com Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Damien Tougas damien@tougas.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Langille dan@freebsddiary.org Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Pelleg dpelleg+unison@cs.cmu.edu Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel B. Hemmerich dan@spot.org Daniel Hagan dhagan@acm.vt.edu Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Daniel W. McRobb dwm@caimis.com Danny Egen unknown Danny Howard dannyman@toldme.com Danny J. Zerkel dzerkel@phofarm.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 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 Dawes dawes@XFree86.org David Filo unknown 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 Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Sugar dyfet@gnu.org David Wolfskill david@catwhisker.org David Yeske dyeske@yahoo.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Denis N. Peplin info@volginfo.ru Denis Shaposhnikov dsh@vlink.ru Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com Derek Inksetter derek@saidev.com Diane Bruce db@db.net Dirk Gouders gouders@et.bocholt.fh-gelsenkirchen.de Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dishanker Rajakulendren draj@oceanfree.net Dmitry A. Yanko fm@astral.ntu-kpi.kiev.ua Dmitry Karasik dmitry@karasik.eu.org Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dmitry Morozovsky marck@rinet.ru Dom Mitchell dom@myrddin.demon.co.uk Domas Mituzas midom@dammit.lt Dominic Marks dominic_marks@btinternet.com Dominik Brettnacher domi@saargate.de Dominik Rothert dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us Don Morrison dmorrisn@u.washington.edu &a.whiteside; Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Donn Miller dmmiller@cvzoom.net Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Dustin Sallings dustin@spy.net ELISA Font Project Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edgardo Garcia Hoeffler edybsd@yahoo.com.ar Edson Brandi ebrandi.home@uol.com.br 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 Eike Bernhardt eike.bernhardt@gmx.de Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eric@talesfromthereal.com Eric Anderson anderson@centtech.com Eric Blood eblood@cs.unr.edu Eric D. Futch efutch@nyct.net Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Shao-yu Cheng eric@fractal.csie.org Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erich Zigler erich@tacni.net Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Bakke erikhb@bgnett.no Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Erwin Lansing erwin@lansing.dk Espen Skoglund esk@ira.uka.de Eugene Grosbein eugen@grosbein.pp.ru Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeney Ryzhyk rzheka@users.sourceforge.net Eugeny Kuzakov CoreDumped@coredumped.null.ru Evan Champion evanc@synapse.net Evgueni Gavrilov vampiro@rootshell.ru FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp Fanying Jen fanying@fynet.com Faried Nawaz fn@Hungry.COM Filippo Natali filippo@widestore.net Flemming Jacobsen fj@batmule.dk Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Francisco Reyes fjrm@yahoo.com Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Gründer elwood@mc5sys.in-berlin.de Frank J. Lazlo laszlof@freebsdmatrix.net Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank Volf volf@oasis.IAEhv.nl Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Franz Klammer klammer@webonaut.com 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 Frederick Earl Gray fgray@rice.edu Frerich Raabe frerich.raabe@gmx.de Fuyuhiko Maruyama fuyuhik8@is.titech.ac.jp &a.stanislav; Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Gareth McCaughan gjm11@dpmms.cam.ac.uk Garrett Rooney rooneg@electricjellyfish.net Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gary W. Swearingen swear@aa.net Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gslin@ccca.nctu.edu.tw Gene Raytsin pal@paladin7.net Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com 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 Glen Foster gfoster@gfoster.com 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 Ansley gja@ansley.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 Gurkan Sengun gurkan@linuks.mine.nu Guy Harris guy@netapp.com HAMADA Naoki hamada@astec.co.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 Hammurabi Mendes hmendes_br@yahoo.com Hannes Sowa satbran@web.de Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Hans-Christian Ebke hans-christian_ebke@gmx.de Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.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 unknown Heiner Eichmann h.eichmann@gmx.de Heiner Strauss heiner@bilch.com Helmut F. Wirth hfwirth@ping.at Hendrik Scholz hendrik@scholz.net Henrik Vestergaard Draboel hvd@terry.ping.dk Henry Whincup henry@techiebod.com Herb Peyerl hpeyerl@NetBSD.org 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 Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Hiten Pandya hiten@uk.FreeBSD.org 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 Hubert Feyrer hubertf@NetBSD.ORG Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Pokrovsky tiamat@telegraph.spb.ru 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 Ilia Chipitsine ilia@jane.cgu.chel.su Ilya V. Komarov mur@lynx.ru Itsuro Saito saito@miv.t.u-tokyo.ac.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J Shoemaker shoemaker@softhome.net J.T. Conklin jtc@cygnus.com Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@anobject.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James Jegers jimj@miller.cs.uwm.edu 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 Jan Conard charly@fachschaften.tu-muenchen.de Jan Jungnickel Jan@Jungnickel.com Jan Koum jkb@FreeBSD.org Jan L. Peterson jlp@flipdog.com Jan Rochel jan.rochel@epost.de Janick Taillandier Janick.Taillandier@ratp.fr Janos Mohacsi janos.mohacsi@bsd.hu Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason DiCioccio geniusj@ods.org Jason Garman init@risen.org Jason Harris jharris@widomaker.com Jason R. Mastaler jason-freebsd@mastaler.com Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jay Krell jay.krell@cornell.edu Jaye Mathisen mrcpu@cdsnet.net Jean-Sebastien Roy js@jeannot.org Jean-Yves Lefort jylefort@brutele.be Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org 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 Wheat jeff@cetlink.net Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Karlson karlj000@unbc.ca Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse McConnell jesse@cylant.com Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Geovedi negative@toxic.magnesium.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Sloan odinn@atlantabiker.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart kuebart@mathematik.uni-ulm.de Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe Abley jabley@automagic.org Joe Halpin joe.halpin@attbi.com Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Kelsey joek@flyingcroc.net Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Johan Granlund johan@granlund.nu Johan Larsson johan@moon.campus.luth.se Johann Kois J.Kois@web.de Johann Tonsing jtonsing@mikom.csir.co.za Johann van Selst johans@stack.nl Johannes 5 Joemann joemann@beefree.free.de Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John Merryweather Cooper jmcoopr@webmail.bmi.net John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Reynolds jjreynold@home.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Johny Mattsson lonewolf@flame.org Jon Morgan morgan@terminus.trailblazer.com Jon Nistor nistor@snickers.org Jon Wilson jon@phuq.co.uk Jonathan Belson jon@witchspace.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jonathan Pennington john@coastalgeology.org Jordan DeLong fracture@allusion.net Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jos@catnook.com Jose Abelardo Martinez jamartinez@altern.org Jose Marques jose@nobody.org Josef El-Rayes j.el-rayes@daemon.li Josef Grosch jgrosch@superior.mooseriver.com Joseph Scott joseph@randomnetworks.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Joshua Goodall joshua@roughtrade.net Jostein Trondal jostein.trondal@sikkerhet.no Juan Salaverria rael@vectorstar.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Juha Ylitalo juha.ylitalo@iki.fi Jukka A. Ukkonen jau@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs; Julian Jenkins kaveman@magna.com.au Jung-uk Kim jkim@niksun.com Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv Justin Stanford jus@security.za.net KATO Tsuguru tkato@prontomail.ne.jp KIMURA Shigekazu zau50357@lion.zero.ad.jp KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kang-ming Liu gugod@gugod.org Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com Karsten W. Rohrbach karsten@rohrbach.de Kawanobe Koh kawanobe@st.rim.or.jp Kees Jan Koster kjkoster@kjkoster.org Keith Bostic bostic@bostic.com Keith E. Walker kew@icehouse.net Keith Moore unknown Keith Sklower unknown Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Ken McGlothlen mcglk@artlogix.com Ken Tom sub@mui.net Kenji Saito marukun@mx2.nisiq.net 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@gnu.ai.mit.edu 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 Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Killer killer@prosalg.no Kim Scarborough sluggo@unknown.nu Kimura Fuyuki fuyuki@hadaly.org Kiril Mitev kiril@ideaglobal.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-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Konrad Heuer kheuer@gwdu60.gwdg.de Konstantin Chuguev Konstantin.Chuguev@dante.org.uk Koop Mast einekoai@chello.nl Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk Kurt D. Zeilenga Kurt@Boolean.NET 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 Larry Altneu larry@ALR.COM Lars Bernhardsson lab@fnurt.net Laurence Lopez lopez@mv.mv.com Lauri Watts lauri@kde.org Laust S. Jespersen L@ust.dk Lee Cremeans lcremean@tidalwave.net Lefteris Chatzibarbas lefcha@hellug.gr Leo Kim leo@florida.sarang.net Lev A. Serebryakov lev@serebryakov.spb.ru Li-lun Wang llwang@infor.org Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M. L. Dodson bdodson@scms.utmb.EDU M.C. Wong unknown MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Makoto YAMAKURA makoto@pinpott.spnet.ne.jp Malte Lance malte.lance@gmx.net Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com 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 van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Marco Molteni molter@tin.it Marcus vA mva121@gmx.net Marius Strobl marius@alchemy.franken.de Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Knight markk@knigma.org Mark Krentel krentel@rice.edu Mark Linimon linimon@lonesome.com Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@thuvia.org Markus Holmberg saska@acc.umu.se Martin Birgmeier unknown Martin Hinner mhi@linux.gyarab.cz Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Karlsson martin.karlsson@visit.se Martin Klaffenboeck martin.klaffenboeck@gmx.at Martin Matuska martin@tradex.sk Martin Minkus diskiller@cnbinc.com Martin Preuss martin@libchipcard.de Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masahiro TAKEMURA mastake@msel.t.u-tokyo.ac.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Douhan matt@athame.co.uk Matt Heckaman matt@LUCIDA.QC.CA Matt Loschert loschert@servint.com Matt Peterson matt@peterson.org Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Emmerton root@gabby.gsicomp.on.ca Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@over-yonder.net Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Matthias Schündehütte msch@snafu.de Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Maxim Bolotin max@rsu.ru Maxim Tuliuk mt@primats.org.ua Maxime Romano verbophobe@hotmail.com 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 Clay mclay@weareb.org Michael Collette metrol@metrol.net Michael Ebert ebert@informatik.unibw-muenchen.de Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Handler handler@grendel.net Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Hostbaek mich@freebsdcluster.org Michael Iatrou m_iatrou@freemail.gr Michael Lyngbøl michael@lyngbol.dk Michael Nottebrock michaelnottebrock@gmx.net Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Sardo jaeger16@yahoo.com Michael Schout mschout@gkg.net Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michal Pasternak doc@lublin.t1.pl Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Miguel Mendez flynn@energyhq.homeip.net Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Bristow mike@urgle.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su 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 unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@mired.org Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.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 N.G.Smith ngs@sesame.hensa.ac.uk NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp 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 Narvi narvi@haldjas.folklore.ee Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Ned Wolpert wolpert@codeheadsystems.com Niall Smart rotel@indigo.ie Nicholas Esborn nick@netdot.net Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net Nick Leuta skynick@stu.lipetsk.ru Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su Niklas Hallqvist niklas@filippa.appli.se 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 devet@adv.IAEhv.nl No Name djv@bedford.net 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 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 roman@rpd.univ.kiev.ua 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 tamone@eig.unige.ch 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 uhlar@netlab.sk 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 Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oddbjorn Steffensen oddbjorn@tricknology.org Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Olexander Kunytsa kunia@wolf.istc.kiev.ua Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Helmling oliver.helmling@stud.uni-bayreuth.de Oliver Laumann net@informatik.uni-bremen.de Oliver Lehmann Kai_Allard_Liao@gmx.de Oliver Oberdorf oly@world.std.com Olivier Tharan olive@oban.frmug.org Olof Johansson offe@ludd.luth.se Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Paolo Flag flag@gufi.org Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Alken cosine@ellipse.mcs.drexel.edu Patrick Bihan-Faou patrick@mindstep.com Patrick Hausen unknown Patrick Powell papowell@astart.com Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown 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. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pav Lucistnik pav@oook.cz Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Per Wigren wigren@home.se Pete Bentley pete@demon.net Peter Avalos pavalos@theshell.com Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy peter.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Peter W. Schmiedeskamp pschmied@qwest.net Peter van Heusden pvh@wfeet.za.net Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Philip Paeps philip@paeps.cx Philippe Lefebvre nemesis@balistik.net Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Radoslav Vasilev rvasilev@uni-svishtov.bg Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Rasmus Kaj kaj@Raditex.se Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it 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 Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert P Ricci ricci@cs.utah.edu Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Rod Taylor rod@idiotswitch.org Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de 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 L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.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 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@inf.enst.fr 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 Sascha Blank blank@fox.uni-trier.de Sascha Holzleiter sascha@root-login.org Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp 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 Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei Kolobov sergei@kolobov.com Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey N. Vorokov serg@tmn.ru Sergey Osokin aka oZZ ozz@FreeBSD.org.ru Sergey Potapov sp@alkor.ru Sergey Samoyloff gonza@techline.ru Sergey Shkonda serg@bcs.zp.ua Sergey V. Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shell Hung shell@shellhung.org Shigio Yamaguchi shigio@tamacom.com Shinichiro Komatsu koma2@jiro.c.u-tokyo.ac.jp Shinya Esu esu@yk.rim.or.jp Shinya FUJIE fujie@tk.elec.waseda.ac.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon Dick simond@irrelevant.org Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Schubert corecode@corecode.ath.cx Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@wheel.dk SPF spf@xslt.cs.nccu.edu.tw Stefan Eggers seggers@semyam.dinoco.de Stefan Ehmann shoesoft@gmx.net Stefan Farfeleder e0026813@stud3.tuwien.ac.at Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steffen Mazanek steffen.mazanek@unibw-muenchen.de Steffen Vogelreuter Steffen@Vogelreuter.De Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Gunn csg@fedex.com Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven Enderle panic@subphase.de Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stijn Hoop stijn@win.tue.nl Stuart Henderson stuart@internationalschool.co.uk 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 Sune Stjerneby sst@vmunix.dk Sungman Cho smcho@tsp.korea.ac.kr Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Svein Skogen tds@dmnstech.net Sybolt de Boer bolt@xs4all.nl TAKAHASHI Kaoru kaoru@kaisei.org 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 Tatoku Ogaito tacha@tera.fukui-med.ac.jp Tatsuya Kudoh cdr@cosmonet.org Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Teruaki Ata PFA03027@nifty.ne.jp Tetsuro Yabu yabu@uopmu.ees.osakafu-u.ac.jp Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thierry Thomas thierry@pompo.net Thomas thomas@mathematik.uni-Bremen.de Thomas A. Stephens tas@stephens.org Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas E. Zander riggs@rrr.de Thomas G. McWilliams tgm@netcom.com Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas M. Hermann Thomas.Hermann@cox.net Thomas Ptacek unknown Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Vogt thomas.vogt@bsdunix.ch Thomas Wintergerst thomas@lemur.nord.de Thorsten Greiner thorsten.greiner@web.de Þórður Ívarsson totii@est.is Tim Bishop tim@bishnet.net Tim Daneliuk tundra@tundraware.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Timothy Jensen toast@blackened.com Tobias Reifenberger treif@mayn.de Toby Allsopp toby@mi6.gen.nz Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher tonym@biolateral.com.au 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 Trefor S. trefor@flevel.co.uk Trenton Schulz twschulz@cord.edu Trevor Blackwell tlb@viaweb.com URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de Ulrich Spoerlein q@uni.de Uwe Arndt arndt@mailhost.uni-koblenz.de Uwe Pierau uwe.pierau@tu-clausthal.de Vadim Belman voland@catpipe.net Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov 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 Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kurtikov vk@vk.pp.ru Vladimir Kushnir kushn@mail.kar.net Vladimir Savichev vlad@ariel.phys.wesleyan.edu Volker Stolz vs@lambda.foldr.org Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Walter Hop walter@binity.com Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.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 van Engen wvengen@stack.nl Willem Jan Withagen wjw@surf.IAE.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 Wouter Van Hemel wouter@pair.com Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW &a.wylie; Xavier Beaudouin kiwi@oav.net 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 Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yonatan Bokovza Yonatan@xpert.com 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 Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yusuke Nawano azuki@azkey.org 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 Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw arci vega@sophia.inria.fr der Mouse mouse@Collatz.McRCIM.McGill.EDU 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall ahall@mirapoint.com Andrey A. Chernov ache@astral.msk.su Andrew Gerweck andy@gerweck.dynup.net Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Antony Halse guy@rucus.ru.ac.za Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Konstantinos Konstantinidis kkonstan@duth.gr Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kamp phk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Seamus Venasse svenasse@polaris.ca Sean Eric Fagan sef@kithrup.com Sean McGovern sean@sfarc.net Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il
diff --git a/en_US.ISO8859-1/articles/fonts/article.sgml b/en_US.ISO8859-1/articles/fonts/article.sgml index c2a23f32ce..02ff6d89ca 100644 --- a/en_US.ISO8859-1/articles/fonts/article.sgml +++ b/en_US.ISO8859-1/articles/fonts/article.sgml @@ -1,976 +1,969 @@ %man; ]>
Fonts and FreeBSD A Tutorial Dave Bodenstab
imdave@synet.net
Wed Aug 7, 1996 This document contains a description of the various font files that may be used with FreeBSD and the syscons driver, X11, Ghostscript and Groff. Cookbook examples are provided for switching the syscons display to 80x60 mode, and for using type 1 fonts with the above application programs. Introduction There are many sources of fonts available, and one might ask how they might be used with FreeBSD. The answer can be found by carefully searching the documentation for the component that one would like to use. This is very time consuming, so this tutorial is an attempt to provide a shortcut for others who might be interested. Basic terminology There are many different font formats and associated font file suffixes. A few that will be addressed here are: .pfa, .pfb Postscript type 1 fonts. The .pfa is the Ascii form and .pfb the Binary form. .afm The font metrics associated with a type 1 font. .pfm The printer font metrics associated with a type 1 font. .ttf A TrueType font .fot An indirect reference to a TrueType font (not an actual font) .fon, .fnt Bitmapped screen fonts The .fot file is used by Windows as sort of a symbolic link to the actual TrueType font (.ttf) file. The .fon font files are also used by Windows. I know of no way to use this font format with FreeBSD. What font formats can I use? Which font file format is useful depends on the application being used. FreeBSD by itself uses no fonts. Application programs and/or drivers may make use of the font files. Here is a small cross reference of application/driver to the font type suffixes: Driver syscons .fnt Application Ghostscript .pfa, .pfb, .ttf X11 .pfa, .pfb Groff .pfa, .afm Povray .ttf The .fnt suffix is used quite frequently. I suspect that whenever someone wanted to create a specialized font file for their application, more often than not they chose this suffix. Therefore, it is likely that files with this suffix are not all the same format; specifically, the .fnt files used by syscons under FreeBSD may not be the same format as a .fnt file one encounters in the MSDOS/Windows environment. I have not made any attempt at using other .fnt files other than those provided with FreeBSD. Setting a virtual console to 80x60 line mode First, an 8x8 font must be loaded. To do this, /etc/rc.conf should contain the line (change the font name to an appropriate one for your locale): font8x8="iso-8x8" # font 8x8 from /usr/share/syscons/fonts/* (or NO). The command to actually switch the mode is &man.vidcontrol.1;: &prompt.user; vidcontrol VGA_80x60 Various screen-oriented programs, such as &man.vi.1;, must be able to determine the current screen dimensions. As this is achieved this through ioctl calls to the console driver (such as &man.syscons.4;) they will correctly determine the new screen dimensions. To make this more seamless, one can embed these commands in the startup scripts so it takes place when the system boots. To do this is add this line to /etc/rc.conf allscreens_flags="VGA_80x60" # Set this vidcontrol mode for all virtual screens References: &man.rc.conf.5;, &man.vidcontrol.1;. Using type 1 fonts with X11 X11 can use either the .pfa or the .pfb format fonts. The X11 fonts are located in various subdirectories under /usr/X11R6/lib/X11/fonts. Each font file is cross referenced to its X11 name by the contents of the fonts.dir file in each directory. There is already a directory named Type1. The most straight forward way to add a new font is to put it into this directory. A better way is to keep all new fonts in a separate directory and use a symbolic link to the additional font. This allows one to more easily keep track of ones fonts without confusing them with the fonts that were originally provided. For example: Create a directory to contain the font files &prompt.user; mkdir -p /usr/local/share/fonts/type1 &prompt.user; cd /usr/local/share/fonts/type1 Place the .pfa, .pfb and .afm files here One might want to keep readme files, and other documentation for the fonts here also &prompt.user; cp /cdrom/fonts/atm/showboat/showboat.pfb . &prompt.user; cp /cdrom/fonts/atm/showboat/showboat.afm . Maintain an index to cross reference the fonts &prompt.user; echo showboat - InfoMagic CICA, Dec 1994, /fonts/atm/showboat >>INDEX Now, to use a new font with X11, one must make the font file available and update the font name files. The X11 font names look like: -bitstream-charter-medium-r-normal-xxx-0-0-0-0-p-0-iso8859-1 | | | | | | | | | | | | \ \ | | | | | \ \ \ \ \ \ \ +----+- character set | | | | \ \ \ \ \ \ \ +- average width | | | | \ \ \ \ \ \ +- spacing | | | \ \ \ \ \ \ +- vertical res. | | | \ \ \ \ \ +- horizontal res. | | | \ \ \ \ +- points | | | \ \ \ +- pixels | | | \ \ \ foundry family weight slant width additional style A new name needs to be created for each new font. If you have some information from the documentation that accompanied the font, then it could serve as the basis for creating the name. If there is no information, then you can get some idea by using &man.strings.1; on the font file. For example: &prompt.user; strings showboat.pfb | more %!FontType1-1.0: Showboat 001.001 %%CreationDate: 1/15/91 5:16:03 PM %%VMusage: 1024 45747 % Generated by Fontographer 3.1 % Showboat 1991 by David Rakowski. Alle Rechte Vorbehalten. FontDirectory/Showboat known{/Showboat findfont dup/UniqueID known{dup /UniqueID get 4962377 eq exch/FontType get 1 eq and}{pop false}ifelse {save true}{false}ifelse}{false}ifelse 12 dict begin /FontInfo 9 dict dup begin /version (001.001) readonly def /FullName (Showboat) readonly def /FamilyName (Showboat) readonly def /Weight (Medium) readonly def /ItalicAngle 0 def /isFixedPitch false def /UnderlinePosition -106 def /UnderlineThickness 16 def /Notice (Showboat 1991 by David Rakowski. Alle Rechte Vorbehalten.) readonly def end readonly def /FontName /Showboat def --stdin-- Using this information, a possible name might be: -type1-Showboat-medium-r-normal-decorative-0-0-0-0-p-0-iso8859-1 The components of our name are: Foundry Lets just name all the new fonts type1. Family The name of the font. Weight Normal, bold, medium, semibold, etc. From the &man.strings.1; output above, it appears that this font has a weight of medium. Slant roman, italic, oblique, etc. Since the ItalicAngle is zero, roman will be used. Width Normal, wide, condensed, extended, etc. Until it can be examined, the assumption will be normal. Additional style Usually omitted, but this will indicate that the font contains decorative capital letters. Spacing proportional or monospaced. Proportional is used since isFixedPitch is false. All of these names are arbitrary, but one should strive to be compatible with the existing conventions. A font is referenced by name with possible wild cards by an X11 program, so the name chosen should make some sense. One might begin by simply using …-normal-r-normal-…-p-… as the name, and then use &man.xfontsel.1; to examine it and adjust the name based on the appearance of the font. So, to complete our example: Make the font accessible to X11 &prompt.user; cd /usr/X11R6/lib/X11/fonts/Type1 &prompt.user; ln -s /usr/local/share/fonts/type1/showboat.pfb . Edit fonts.dir and fonts.scale, adding the line describing the font and incrementing the number of fonts which is found on the first line. &prompt.user; ex fonts.dir :1p 25 :1c 26 . :$a showboat.pfb -type1-showboat-medium-r-normal-decorative-0-0-0-0-p-0-iso8859-1 . :wq fonts.scale seems to be identical to fonts.dir… &prompt.user; cp fonts.dir fonts.scale Tell X11 that things have changed &prompt.user; xset fp rehash Examine the new font &prompt.user; xfontsel -pattern -type1-* References: &man.xfontsel.1;, &man.xset.1;, The X Windows System in a Nutshell, O'Reilly & Associates. Using type 1 fonts with Ghostscript Ghostscript references a font via its Fontmap file. This must be modified in a similar way to the X11 fonts.dir file. Ghostscript can use either the .pfa or the .pfb format fonts. Using the font from the previous example, here is how to use it with Ghostscript: Put the font in Ghostscript's font directory &prompt.user; cd /usr/local/share/ghostscript/fonts &prompt.user; ln -s /usr/local/share/fonts/type1/showboat.pfb . Edit Fontmap so Ghostscript knows about the font &prompt.user; cd /usr/local/share/ghostscript/4.01 &prompt.user; ex Fontmap :$a /Showboat (showboat.pfb) ; % From CICA /fonts/atm/showboat . :wq Use Ghostscript to examine the font &prompt.user; gs prfont.ps Aladdin Ghostscript 4.01 (1996-7-10) Copyright (C) 1996 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading Times-Roman font from /usr/local/share/ghostscript/fonts/tir_____.pfb... /1899520 581354 1300084 13826 0 done. GS>Showboat DoFont Loading Showboat font from /usr/local/share/ghostscript/fonts/showboat.pfb... 1939688 565415 1300084 16901 0 done. >>showpage, press <return> to continue<< >>showpage, press <return> to continue<< >>showpage, press <return> to continue<< GS>quit References: fonts.txt in the Ghostscript 4.01 distribution Using type 1 fonts with Groff Now that the new font can be used by both X11 and Ghostscript, how can one use the new font with groff? First of all, since we are dealing with type 1 postscript fonts, the groff device that is applicable is the ps device. A font file must be created for each font that groff can use. A groff font name is just a file in /usr/share/groff_font/devps. With our example, the font file could be /usr/share/groff_font/devps/SHOWBOAT. The file must be created using tools provided by groff. The first tool is afmtodit. This is not normally installed, so it must be retrieved from the source distribution. I found I had to change the first line of the file, so I did: &prompt.user; cp /usr/src/gnu/usr.bin/groff/afmtodit/afmtodit.pl /tmp &prompt.user; ex /tmp/afmtodit.pl :1c #!/usr/bin/perl -P- . :wq This tool will create the groff font file from the metrics file (.afm suffix.) Continuing with our example: Many .afm files are in Mac format… ^M delimited lines We need to convert them to unix style ^J delimited lines &prompt.user; cd /tmp &prompt.user; cat /usr/local/share/fonts/type1/showboat.afm | tr '\015' '\012' >showboat.afm Now create the groff font file &prompt.user; cd /usr/share/groff_font/devps &prompt.user; /tmp/afmtodit.pl -d DESC -e text.enc /tmp/showboat.afm generate/textmap SHOWBOAT The font can now be referenced with the name SHOWBOAT. If ghostscript is used to drive the printers on the system, then nothing more needs to be done. However, if true postscript printers are used, then the font must be down loaded to the printer in order for the font to be used (unless the printer happens to have the showboat font built in or on an accessible font disk.) The final step is to create a down loadable font. The pfbtops tool is used to create the .pfa format of the font, and the download file is modified to reference the new font. The download file must reference the internal name of the font. This can easily be determined from the groff font file as illustrated: Create the .pfa font file &prompt.user; pfbtops /usr/local/share/fonts/type1/showboat.pfb >showboat.pfa Of course, if the .pfa file is already available, just use a symbolic link to reference it. Get the internal font name &prompt.user; fgrep internalname SHOWBOAT internalname Showboat Tell groff that the font must be down loaded &prompt.user; ex download :$a Showboat showboat.pfa . :wq To test the font: &prompt.user; cd /tmp &prompt.user; cat >example.t <<EOF .sp 5 .ps 16 This is an example of the Showboat font: .br .ps 48 .vs (\n(.s+2)p .sp .ft SHOWBOAT ABCDEFGHI .br JKLMNOPQR .br STUVWXYZ .sp .ps 16 .vs (\n(.s+2)p .fp 5 SHOWBOAT .ft R To use it for the first letter of a paragraph, it will look like: .sp 50p \s(48\f5H\s0\fRere is the first sentence of a paragraph that uses the showboat font as its first letter. Additional vertical space must be used to allow room for the larger letter. EOF &prompt.user; groff -Tps example.t >example.ps To use ghostscript/ghostview &prompt.user; ghostview example.ps To print it &prompt.user; lpr -Ppostscript example.ps References: /usr/src/gnu/usr.bin/groff/afmtodit/afmtodit.man, &man.groff.font.5;, &man.groff.char.7;, &man.pfbtops.1;. Converting TrueType fonts to a groff/postscript format for groff This potentially requires a bit of work, simply because it depends on some utilities that are not installed as part of the base system. They are: ttf2pf TrueType to postscript conversion utilities. This allows conversion of a TrueType font to an ascii font metric (.afm) file. Currently available at http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf/. + url="http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf/">. Note: These files are postscript programs and must be downloaded to disk by holding down the Shift key when clicking on the link. Otherwise, your browser may try to launch ghostview to view them. The files of interest are: GS_TTF.PS PF2AFM.PS ttf2pf.ps The funny upper/lower case is due to their being intended also for DOS shells. ttf2pf.ps makes use of the others as upper case, so any renaming must be consistent with this. (Actually, GS_TTF.PS and PFS2AFM.PS are supposedly part of the ghostscript distribution, but it is just as easy to use these as an isolated utility. FreeBSD does not seem to include the latter.) You also may want to have these installed to /usr/local/share/groff_font/devps(?). afmtodit Creates font files for use with groff from ascii font metrics file. This usually resides in the directory, /usr/src/contrib/groff/afmtodit, and requires some work to get going. If you are paranoid about working in the /usr/src tree, simply copy the contents of the above directory to a work location. In the work area, you will need to make the utility. Just type: # make -f Makefile.sub afmtodit You may also need to copy /usr/contrib/groff/devps/generate/textmap to /usr/share/groff_font/devps/generate if it does not already exist. Once all these utilities are in place, you are ready to commence: Create the .afm file by typing: % gs -dNODISPLAY -q -- ttf2pf.ps TTF_name PS_font_name AFM_name Where, TTF_name is your TrueType font file, PS_font_name is the file name for the .pfa file, AFM_name is the name you wish for the .afm file. If you do not specify output file names for the .pfa or .afm files, then default names will be generated from the TrueType font file name. This also produces a .pfa file, the ascii postscript font metrics file (.pfb is for the binary form). This will not be needed, but could (I think) be useful for a fontserver. For example, to convert the 30f9 Barcode font using the default file names, use the following command: % gs -dNODISPLAY -- ttf2pf.ps 3of9.ttf Aladdin Ghostscript 5.10 (1997-11-23) Copyright (C) 1997 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Converting 3of9.ttf to 3of9.pfa and 3of9.afm. If you want the converted fonts to be stored in A.pfa and B.afm, then use this command: % gs -dNODISPLAY -- ttf2pf.ps 3of9.ttf A B Aladdin Ghostscript 5.10 (1997-11-23) Copyright (C) 1997 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Converting 3of9.ttf to A.pfa and B.afm. Create the groff postscript file: Change directories to /usr/share/groff_font/devps so as to make the following command easier to execute. You will probably need root privileges for this. (Or, if you are paranoid about working there, make sure you reference the files DESC, text.enc and generate/textmap as being in this directory.) % afmtodit -d DESC -e text.enc file.afm \ generate/textmap PS_font_name Where, file.afm is the AFM_name created by ttf2pf.ps above, and PS_font_name is the font name used from that command, as well as the name that &man.groff.1; will use for references to this font. For example, assuming you used the first tiff2pf.ps command above, then the 3of9 Barcode font can be created using the command: % afmtodit -d DESC -e text.enc 3of9.afm \ generate/textmap 3of9 Ensure that the resulting PS_font_name file (e.g., 3of9 in the example above) is located in the directory /usr/share/groff_font/devps by copying or moving it there. Note that if ttf2pf.ps assigns a font name using the one it finds in the TrueType font file and you want to use a different name, you must edit the .afm file prior to running afmtodit. This name must also match the one used in the Fontmap file if you wish to pipe &man.groff.1; into &man.gs.1;. Can TrueType fonts be used with other programs? The TrueType font format is used by Windows, Windows 95, and Mac's. It is quite popular and there are a great number of fonts available in this format. Unfortunately, there are few applications that I am aware of that can use this format: Ghostscript and Povray come to mind. Ghostscript's support, according to the documentation, is rudimentary and the results are likely to be inferior to type 1 fonts. Povray version 3 also has the ability to use TrueType fonts, but I rather doubt many people will be creating documents as a series of raytraced pages :-). This rather dismal situation may soon change. The FreeType Project is currently developing a useful set of FreeType tools: The freetype module is included with XFree86 4.x. For more information please see the FreeBSD Handbook or the XFree86 4.0.2 Fonts page. The xfsft font server for X11 can serve TrueType fonts in addition to regular fonts. Though currently in beta, it is said to be quite usable. See Juliusz Chroboczek's page for further information. Porting instructions for FreeBSD can be found at Stephen Montgomery's software page. xfstt is another font server for X11, available under - ftp://sunsite.unc.edu/pub/Linux/X11/fonts/. + ftp://sunsite.unc.edu/pub/Linux/X11/fonts/">. A program called ttf2bdf can produce BDF files suitable for use in an X environment from TrueType files. Linux binaries are said to be available from ftp://crl.nmsu.edu/CLR/multiling/General/. + url="ftp://crl.nmsu.edu/CLR/multiling/General/">. For people requiring the use of Asian TrueType fonts, the XTT font server may be worth a look. Information about XTT can be found at URL: http://hawk.ise.chuo-u.ac.jp/student/person/tshiozak/study/freebsd-at-random/x-tt/index-en.html. + url="http://hawk.ise.chuo-u.ac.jp/student/person/tshiozak/study/freebsd-at-random/x-tt/index-en.html">. and others … The FreeType Projects page is a good starting point for information on these and other free TrueType projects. Where can additional fonts be obtained? Many fonts are available on the Internet. They are either entirely free, or are share-ware. In addition, there are many inexpensive CDROMs available that contain many fonts. Some Internet locations (as of August 1996) are: - ftp://ftp.winsite.com/ + (Formerly CICA) - http://www.simtel.net/ + - ftp://ftp.coast.net/ + - http://af-pc-plloyd.ecel.uwa.edu.au/fonts/ + - http://www.esselte.com/letraset/ + - http://www.inil.com/users/elfring/esf.htm + Additional questions What use are the .pfm files? Can one generate the .afm file from a .pfa or .pfb? How to generate the groff character mapping files for postscript fonts with non-standard character names? Can xditview and devX?? devices be setup to access all the new fonts? It would be good to have examples of using TrueType fonts with povray and ghostscript.
diff --git a/en_US.ISO8859-1/articles/releng/article.sgml b/en_US.ISO8859-1/articles/releng/article.sgml index 9baaf0741a..f51ee598e1 100644 --- a/en_US.ISO8859-1/articles/releng/article.sgml +++ b/en_US.ISO8859-1/articles/releng/article.sgml @@ -1,1019 +1,1018 @@ %authors; %teams; %mailing-lists; %man; %freebsd; The Release Engineering of Third Party Packages'> ]>
FreeBSD Release Engineering November 2001 BSDCon Europe Murray Stokely I've been involved in the development of FreeBSD based products since 1997 at Walnut Creek CDROM, BSDi, and now Wind River Systems. FreeBSD 4.4 was the first official release of FreeBSD that I played a significant part in.
murray@FreeBSD.org - http://www.FreeBSD.org/~murray +
$FreeBSD$ This paper describes the approach used by the FreeBSD release engineering team to make production quality releases of the FreeBSD Operating System. It details the methodology used for the official FreeBSD releases and describes the tools available for those interested in producing customized FreeBSD releases for corporate rollouts or commercial productization. Introduction The development of FreeBSD is a very open process. FreeBSD is comprised of contributions from thousands of people around the world. The FreeBSD Project provides anonymous CVS[1] 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 FreeBSD. However, I think everyone would agree that chaos would soon manifest if write access was opened up to everyone on the Internet. Therefore only a select group of nearly 300 people are given write access to the CVS repository. These committers[6] are responsible for the bulk of FreeBSD development. An elected core-team[7] of very senior developers provides some level of direction over the project. The rapid pace of FreeBSD development leaves little time for polishing the development system into a production quality release. To solve this dilemma, development continues on two parallel tracks. The main development branch is the HEAD or trunk of our CVS tree, known as FreeBSD-CURRENT or -CURRENT for short. A more stable branch is maintained, known as FreeBSD-STABLE or -STABLE for short. Both branches live in a master CVS repository in California and are replicated via CVSup[2] to mirrors all over the world. FreeBSD-CURRENT[8] is the bleeding-edge of FreeBSD development where all new changes first enter the system. FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a different pace, and with general assumption that they have first gone into FreeBSD-CURRENT and have been thoroughly tested by our user community. In the interim period between releases, nightly snapshots are built automatically by the FreeBSD Project build machines and made available for download from ftp://stable.FreeBSD.org/. The widespread availability of binary release snapshots, and the tendency of our user community to keep up with -STABLE development with CVSup and make world[8] helps to keep FreeBSD-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[9] database through email, the &man.send-pr.1; application, or via the web interface provided at . In addition to the multitude of different technical mailing lists about FreeBSD, the &a.qa; provides a forum for discussing the finer points of release-polishing. To service our most conservative users, individual release branches were introduced with FreeBSD 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 CVS, binary patchkits are available to keep systems on the RELENG_X_Y branches updated. discusses the different phases of the release engineering process leading up to the actual system build and describes the actual build process. describes how the base release may be extended by third parties and details some of the lessons learned through the release of FreeBSD 4.4. Finally, presents future directions of development. Release Process New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. The FreeBSD release process begins to ramp up 45 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. Code Review Thirty days before the anticipated release, the source repository enters a code slush. During this time, all commits to the -STABLE branch must be approved by the &a.re;. The kinds of changes that are allowed during this 15 day period include: Bug fixes. Documentation updates. Security-related fixes of any kind. Minor changes to device drivers, such as adding new Device IDs. Any additional change that the release engineering team feels is justified, given the potential risk. After the first 15 days of the code slush, a release candidate is released for widespread testing and the code enters a code freeze where it becomes much harder to justify new changes to the system unless a serious bug-fix or security issue is involved. During the code freeze, at least one release candidate is released per week, until the final release is ready. During the days leading to 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. Final Release Checklist When several release candidates have been made available for widespread testing and all major issues have been resolved, the final release polishing can begin. Creating the Release Branch As described in the introduction, the RELENG_X_Y release branch is a relatively new addition to our release engineering methodology. The first step in creating this branch is to ensure that you are working with the newest version of the RELENG_X sources that you want to branch from. /usr/src&prompt.root; cvs update -rRELENG_4 -P -d The next step is to create a branch point tag, so that diffs against the start of the branch are easier with CVS: /usr/src&prompt.root; cvs rtag -rRELENG_4 RELENG_4_8_BP src And then a new branch tag is created with: /usr/src&prompt.root; cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src The RELENG_* tags are restricted for use by the CVS-meisters and release engineers. A tag is CVS vernacular for a label that identifies the source at a specific point in time. By tagging the tree, we ensure that future release builders will always be able to use the same source we used to create the official FreeBSD Project releases. &branches.ascii; FreeBSD Development Branches 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 FreeBSD: doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml doc/en_US.ISO8859-1/books/porters-handbook/book.sgml doc/share/sgml/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/sgml/release.dsl src/release/doc/share/examples/Makefile.relnotesng src/release/doc/share/sgml/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.sgml 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.sgml src/release/doc/en_US.ISO8859-1/errata/article.sgml Sysinstall should be updated to note the number of available ports and the amount of disk space required for the Ports Collection. This information is currently kept in src/release/sysinstall/dist.c. After the release has been built, a number of file should be updated to announce the release to the world. www/en/includes.xsl www/en/includes.sgml www/en/releases/* src/share/misc/bsd-family-tree Creating Release Tags When the final release is ready, the following command will create the RELENG_4_8_0_RELEASE tag. /usr/src&prompt.root; cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src The Documentation and Ports managers are responsible for tagging the respective trees with the RELEASE_4_8_0 tag. Occasionally, a last minute fix may be required after the final tags have been created. In practice this isn't a problem, since CVS allows tags to be manipulated with cvs tag -d tagname filename. It is very important that any last minute changes be tagged appropriately as part of the release. FreeBSD releases must always be reproduceable. Local hacks in the release engineer's environment are not acceptable. Release Building FreeBSD releases can be built by anyone with a fast machine and access to a source repository. (That should be everyone, since we offer anonymous CVS! See The Handbook for details.) The only special requirement is that the &man.vn.4; device must be available. (On -CURRENT, this device has been replaced by the new &man.md.4; memory disk driver.) If the device is not loaded into your kernel, then the kernel module should be automatically loaded when &man.vnconfig.8; is executed during the boot media creation phase. All of the tools necessary to build a release are available from the CVS repository in src/release. These tools aim to provide a consistent way to build FreeBSD releases. A complete release can actually be built with only a single command, including the creation of ISO images suitable for burning to CDROM, installation floppies, and an FTP install directory. This command is aptly named make release. <command>make release</command> To successfully build a release, you must first populate /usr/obj by running make world or simply make buildworld. The release target requires several variables be set properly to build a release: CHROOTDIR - The directory to be used as the chroot environment for the entire release build. BUILDNAME - The name of the release to be built. CVSROOT - The location of a CVS Repository. RELEASETAG - The CVS tag corresponding to the release you would like to build. If you do not already have access to a local CVS repository, then you may mirror one with CVSup. The supplied supfile, /usr/share/examples/cvsup/cvs-supfile, is a useful starting point for mirroring the CVS repository. If RELEASETAG is omitted, then the release will be built from the HEAD (a.k.a. -CURRENT) branch. Releases built from this branch are normally referred to as -CURRENT snapshots. There are many other variables available to customize the release build. Most of these variables are documented at the top of src/release/Makefile. The exact command used to build the official FreeBSD 4.7 (x86) release was: make release CHROOTDIR=/local3/release \ BUILDNAME=4.7-RELEASE \ CVSROOT=/host/cvs/usr/home/ncvs \ RELEASETAG=RELENG_4_7_0_RELEASE 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 CVS 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.) Build of the crunched binaries used for installation floppies. Package up distribution tarballs of the binaries and sources. Create the boot media and a fixit floppy. 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;. Building <application>XFree86</application> XFree86 is an important component for many desktop users. Prior to FreeBSD 4.6-RELEASE, releases used XFree86 3.X by default. The easiest way to build these versions is to use the src/release/scripts/X11/build_x.sh script. This script requires that XFree86 and Tcl/Tk already be installed on the build host. After compiling the necessary X servers, the script will package all of the files into tarballs that &man.sysinstall.8; expects to find in the XF86336 directory of the installation media. Beginning with FreeBSD 4.6-RELEASE, &man.sysinstall.8; installs XFree86 4.X by default, as a set of normal packages. These can either be the packages generated by the package-building cluster or packages built from an appropriately tagged ports tree. 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 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 official FreeBSD 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 FreeBSD 4.4, the FreeBSD 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, XFree86, 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 an alternate version of XFree86 is to be provided, then &man.sysinstall.8; must be updated to reflect the new location and installation instructions. The relevant code is contained in src/release/sysinstall on -STABLE or src/usr.sbin/sysinstall on -CURRENT. Specifically, the files dist.c, menus.c, and config.c will need to be updated. 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 FreeBSD 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 FreeBSD. 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. Distribution FTP Sites When the release has been thoroughly tested and packaged for distribution, the master FTP site must be updated. The official FreeBSD 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/index.html A simple web page that points to the various important FTP directories for the current FreeBSD release. /pub/FreeBSD/releases/arch/X.Y-RELEASE/ The installable FTP directory as output from make release. /pub/FreeBSD/ports/arch/packages/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/i386/packages-X.Y-release. /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-*.iso The ISO images. For more information about the distribution mirror architecture of the FreeBSD FTP sites, please see the Mirroring FreeBSD article. It may take many hours after updating ftp-master before a majority of the Tier-1 FTP sites have the new software. It is imperative that the release engineers coordinate with the &a.hubs; before announcing the general availability of new software on the FTP sites. CD-ROM Replication Coming soon: Tips for sending FreeBSD ISOs to a replicator and quality assurance measures to be taken. Extensibility Although FreeBSD 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 FreeBSD with non-trivial changes, we encourage you to document your enhancements! The FreeBSD 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 can't be expected to answer questions about it. Creating Customized Boot floppies Many sites have complex requirements that may require additional kernel modules or userland tools be added to the installation floppies. The quick and dirty way to accomplish this would be to modify the staging directory of an existing make release build hierarchy: Apply patches or add additional files inside the chroot release build directory. rm ${CHROOTDIR}/usr/obj/usr/src/release/release.[48] rebuild &man.sysinstall.8;, the kernel, or whatever parts of the system your change affected. chroot ${CHROOTDIR} ./mk release.4 chroot ${CHROOTDIR} ./mk release.8 New release floppies will be located in ${CHROOTDIR}/R/stage/floppies. Alternatively, the boot.flp make target can be called, or the filesystem creating script, src/release/scripts/doFS.sh, may be invoked directly. Local patches may also be supplied to the release build by defining the LOCAL_PATCH variable in make release. Scripting <command>sysinstall</command> The FreeBSD 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's PXE[13] to bootstrap systems from the network, or via custom boot floppies with a sysinstall script. An example sysinstall script is available in the CVS tree as src/release/sysinstall/install.cfg. Lessons Learned from FreeBSD 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 FreeBSD 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 FreeBSD release should not be sacrificed for any self-imposed deadlines or target release dates. The FreeBSD 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 FreeBSD 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 FreeBSD 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 FreeBSD. 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. One of the most promising is the libh project[5] which aims to provided 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 FreeBSD 4.4 and also for all of his work throughout the years making FreeBSD what it is today. Of course the release wouldn't 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 FreeBSD development community. I would also like to thank &a.rgrimes;, &a.phk;, and others who worked on the release engineering tools in the very early days of FreeBSD. This article was influenced by release engineering documents from the CSRG[14], the NetBSD Project[11], and John Baldwin's proposed release engineering process notes[12]. References [1] CVS - Concurrent Versions System [2] CVSup - The CVS-Optimized General Purpose Network File Distribution System [3] [4] FreeBSD Ports Collection [5] The libh Project [6] FreeBSD Committers [7] FreeBSD Core-Team [8] FreeBSD Handbook [9] GNATS: The GNU Bug Tracking System [10] FreeBSD PR Statistics [11] NetBSD Developer Documentation: Release Engineering [12] John Baldwin's FreeBSD Release Engineering Proposal [13] PXE Jumpstart Guide [14] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD
diff --git a/en_US.ISO8859-1/articles/storage-devices/article.sgml b/en_US.ISO8859-1/articles/storage-devices/article.sgml index 8f6fc150b9..213ae2b311 100644 --- a/en_US.ISO8859-1/articles/storage-devices/article.sgml +++ b/en_US.ISO8859-1/articles/storage-devices/article.sgml @@ -1,2639 +1,2639 @@ %man; %authors; ]>
Storage Devices Wilko Bulte
wilko@FreeBSD.org
 $FreeBSD$ This article talks about storage devices with FreeBSD. Using ESDI hard disks Copyright © 1995, &a.wilko;. 24 September 1995. ESDI is an acronym that means Enhanced Small Device Interface. It is loosely based on the good old ST506/412 interface originally devised by Seagate Technology, the makers of the first affordable 5.25" winchester disk. The acronym says Enhanced, and rightly so. In the first place the speed of the interface is higher, 10 or 15 Mbits/second instead of the 5 Mbits/second of ST412 interfaced drives. Secondly some higher level commands are added, making the ESDI interface somewhat smarter to the operating system driver writers. It is by no means as smart as SCSI by the way. ESDI is standardized by ANSI. Capacities of the drives are boosted by putting more sectors on each track. Typical is 35 sectors per track, high capacity drives I have seen were up to 54 sectors/track. Although ESDI has been largely obsoleted by IDE and SCSI interfaces, the availability of free or cheap surplus drives makes them ideal for low (or now) budget systems. Concepts of ESDI Physical connections The ESDI interface uses two cables connected to each drive. One cable is a 34 pin flat cable edge connector that carries the command and status signals from the controller to the drive and vice-versa. The command cable is daisy chained between all the drives. So, it forms a bus onto which all drives are connected. The second cable is a 20 pin flat cable edge connector that carries the data to and from the drive. This cable is radially connected, so each drive has its own direct connection to the controller. To the best of my knowledge PC ESDI controllers are limited to using a maximum of 2 drives per controller. This is compatibility feature(?) left over from the WD1003 standard that reserves only a single bit for device addressing. Device addressing On each command cable a maximum of 7 devices and 1 controller can be present. To enable the controller to uniquely identify which drive it addresses, each ESDI device is equipped with jumpers or switches to select the devices address. On PC type controllers the first drive is set to address 0, the second disk to address 1. Always make sure you set each disk to an unique address! So, on a PC with its two drives/controller maximum the first drive is drive 0, the second is drive 1. Termination The daisy chained command cable (the 34 pin cable remember?) needs to be terminated at the last drive on the chain. For this purpose ESDI drives come with a termination resistor network that can be removed or disabled by a jumper when it is not used. So, one and only one drive, the one at the farthest end of the command cable has its terminator installed/enabled. The controller automatically terminates the other end of the cable. Please note that this implies that the controller must be at one end of the cable and not in the middle. Using ESDI disks with FreeBSD Why is ESDI such a pain to get working in the first place? People who tried ESDI disks with FreeBSD are known to have developed a profound sense of frustration. A combination of factors works against you to produce effects that are hard to understand when you have never seen them before. This has also led to the popular legend ESDI and FreeBSD is a plain NO-GO. The following sections try to list all the pitfalls and solutions. ESDI speed variants As briefly mentioned before, ESDI comes in two speed flavors. The older drives and controllers use a 10 Mbits/second data transfer rate. Newer stuff uses 15 Mbits/second. It is not hard to imagine that 15 Mbits/second drive cause problems on controllers laid out for 10 Mbits/second. As always, consult your controller and drive documentation to see if things match. Stay on track Mainstream ESDI drives use 34 to 36 sectors per track. Most (older) controllers cannot handle more than this number of sectors. Newer, higher capacity, drives use higher numbers of sectors per track. For instance, I own a 670 MB drive that has 54 sectors per track. In my case, the controller could not handle this number of sectors. It proved to work well except that it only used 35 sectors on each track. This meant losing a lot of disk space. Once again, check the documentation of your hardware for more info. Going out-of-spec like in the example might or might not work. Give it a try or get another more capable controller. Hard or soft sectoring Most ESDI drives allow hard or soft sectoring to be selected using a jumper. Hard sectoring means that the drive will produce a sector pulse on the start of each new sector. The controller uses this pulse to tell when it should start to write or read. Hard sectoring allows a selection of sector size (normally 256, 512 or 1024 bytes per formatted sector). FreeBSD uses 512 byte sectors. The number of sectors per track also varies while still using the same number of bytes per formatted sector. The number of unformatted bytes per sector varies, dependent on your controller it needs more or less overhead bytes to work correctly. Pushing more sectors on a track of course gives you more usable space, but might give problems if your controller needs more bytes than the drive offers. In case of soft sectoring, the controller itself determines where to start/stop reading or writing. For ESDI hard sectoring is the default (at least on everything I came across). I never felt the urge to try soft sectoring. In general, experiment with sector settings before you install FreeBSD because you need to re-run the low-level format after each change. Low level formatting ESDI drives need to be low level formatted before they are usable. A reformat is needed whenever you figgle with the number of sectors/track jumpers or the physical orientation of the drive (horizontal, vertical). So, first think, then format. The format time must not be underestimated, for big disks it can take hours. After a low level format, a surface scan is done to find and flag bad sectors. Most disks have a manufacturer bad block list listed on a piece of paper or adhesive sticker. In addition, on most disks the list is also written onto the disk. Please use the manufacturer's list. It is much easier to remap a defect now than after FreeBSD is installed. Stay away from low-level formatters that mark all sectors of a track as bad as soon as they find one bad sector. Not only does this waste space, it also and more importantly causes you grief with bad144 (see the section on bad144). Translations Translations, although not exclusively a ESDI-only problem, might give you real trouble. Translations come in multiple flavors. Most of them have in common that they attempt to work around the limitations posed upon disk geometries by the original IBM PC/AT design (thanks IBM!). First of all there is the (in)famous 1024 cylinder limit. For a system to be able to boot, the stuff (whatever operating system) must be in the first 1024 cylinders of a disk. Only 10 bits are available to encode the cylinder number. For the number of sectors the limit is 64 (0-63). When you combine the 1024 cylinder limit with the 16 head limit (also a design feature) you max out at fairly limited disk sizes. To work around this problem, the manufacturers of ESDI PC controllers added a BIOS prom extension on their boards. This BIOS extension handles disk I/O for booting (and for some operating systems all disk I/O) by using translation. For instance, a big drive might be presented to the system as having 32 heads and 64 sectors/track. The result is that the number of cylinders is reduced to something below 1024 and is therefore usable by the system without problems. It is noteworthy to know that FreeBSD does not use the BIOS after its kernel has started. More on this later. A second reason for translations is the fact that most older system BIOSes could only handle drives with 17 sectors per track (the old ST412 standard). Newer system BIOSes usually have a user-defined drive type (in most cases this is drive type 47). Whatever you do to translations after reading this document, keep in mind that if you have multiple operating systems on the same disk, all must use the same translation While on the subject of translations, I have seen one controller type (but there are probably more like this) offer the option to logically split a drive in multiple partitions as a BIOS option. I had select 1 drive == 1 partition because this controller wrote this info onto the disk. On power-up it read the info and presented itself to the system based on the info from the disk. Spare sectoring Most ESDI controllers offer the possibility to remap bad sectors. During/after the low-level format of the disk bad sectors are marked as such, and a replacement sector is put in place (logically of course) of the bad one. In most cases the remapping is done by using N-1 sectors on each track for actual data storage, and sector N itself is the spare sector. N is the total number of sectors physically available on the track. The idea behind this is that the operating system sees a perfect disk without bad sectors. In the case of FreeBSD this concept is not usable. The problem is that the translation from bad to good is performed by the BIOS of the ESDI controller. FreeBSD, being a true 32 bit operating system, does not use the BIOS after it has been booted. Instead, it has device drivers that talk directly to the hardware. So: do not use spare sectoring, bad block remapping or whatever it may be called by the controller manufacturer when you want to use the disk for FreeBSD. Bad block handling The preceding section leaves us with a problem. The controller's bad block handling is not usable and still FreeBSD's filesystems assume perfect media without any flaws. To solve this problem, FreeBSD use the bad144 tool. Bad144 (named after a Digital Equipment standard for bad block handling) scans a FreeBSD slice for bad blocks. Having found these bad blocks, it writes a table with the offending block numbers to the end of the FreeBSD slice. When the disk is in operation, the disk accesses are checked against the table read from the disk. Whenever a block number is requested that is in the bad144 list, a replacement block (also from the end of the FreeBSD slice) is used. In this way, the bad144 replacement scheme presents perfect media to the FreeBSD filesystems. There are a number of potential pitfalls associated with the use of bad144. First of all, the slice cannot have more than 126 bad sectors. If your drive has a high number of bad sectors, you might need to divide it into multiple FreeBSD slices each containing less than 126 bad sectors. Stay away from low-level format programs that mark every sector of a track as bad when they find a flaw on the track. As you can imagine, the 126 limit is quickly reached when the low-level format is done this way. Second, if the slice contains the root filesystem, the slice should be within the 1024 cylinder BIOS limit. During the boot process the bad144 list is read using the BIOS and this only succeeds when the list is within the 1024 cylinder limit. The restriction is not that only the root filesystem must be within the 1024 cylinder limit, but rather the entire slice that contains the root filesystem. Kernel configuration ESDI disks are handled by the same wddriver as IDE and ST412 MFM disks. The wd driver should work for all WD1003 compatible interfaces. Most hardware is jumperable for one of two different I/O address ranges and IRQ lines. This allows you to have two wd type controllers in one system. When your hardware allows non-standard strappings, you can use these with FreeBSD as long as you enter the correct info into the kernel config file. An example from the kernel config file (they live in /sys/i386/conf BTW). # First WD compatible controller controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 # Second WD compatible controller controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 Particulars on ESDI hardware Adaptec 2320 controllers I successfully installed FreeBSD onto a ESDI disk controlled by a ACB-2320. No other operating system was present on the disk. To do so I low level formatted the disk using NEFMT.EXE (ftpable from www.adaptec.com) and answered NO to the question whether the disk should be formatted with a spare sector on each track. The BIOS on the ACD-2320 was disabled. I used the free configurable option in the system BIOS to allow the BIOS to boot it. Before using NEFMT.EXE I tried to format the disk using the ACB-2320 BIOS built-in formatter. This proved to be a show stopper, because it did not give me an option to disable spare sectoring. With spare sectoring enabled the FreeBSD installation process broke down on the bad144 run. Please check carefully which ACB-232xy variant you have. The x is either 0 or 2, indicating a controller without or with a floppy controller on board. The y is more interesting. It can either be a blank, a A-8 or a D. A blank indicates a plain 10 Mbits/second controller. An A-8 indicates a 15 Mbits/second controller capable of handling 52 sectors/track. A D means a 15 Mbits/second controller that can also handle drives with > 36 sectors/track (also 52?). All variations should be capable of using 1:1 interleaving. Use 1:1, FreeBSD is fast enough to handle it. Western Digital WD1007 controllers I successfully installed FreeBSD onto a ESDI disk controlled by a WD1007 controller. To be precise, it was a WD1007-WA2. Other variations of the WD1007 do exist. To get it to work, I had to disable the sector translation and the WD1007's onboard BIOS. This implied I could not use the low-level formatter built into this BIOS. Instead, I grabbed WDFMT.EXE from www.wdc.com Running this formatted my drive just fine. Ultrastor U14F controllers According to multiple reports from the net, Ultrastor ESDI boards work OK with FreeBSD. I lack any further info on particular settings. Further reading If you intend to do some serious ESDI hacking, you might want to have the official standard at hand: The latest ANSI X3T10 committee document is: Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11] On Usenet the newsgroup comp.periphs is a noteworthy place to look for more info. The World Wide Web (WWW) also proves to be a very handy info source: For info on Adaptec ESDI controllers see http://www.adaptec.com/. For - info on Western Digital controllers see http://www.wdc.com/. + url="http://www.adaptec.com/">. For + info on Western Digital controllers see + . Thanks to... Andrew Gordon for sending me an Adaptec 2320 controller and ESDI disk for testing. What is SCSI? Copyright © 1995, &a.wilko;. July 6, 1996. SCSI is an acronym for Small Computer Systems Interface. It is an ANSI standard that has become one of the leading I/O buses in the computer industry. The foundation of the SCSI standard was laid by Shugart Associates (the same guys that gave the world the first mini floppy disks) when they introduced the SASI bus (Shugart Associates Standard Interface). After some time an industry effort was started to come to a more strict standard allowing devices from different vendors to work together. This effort was recognized in the ANSI SCSI-1 standard. The SCSI-1 standard (approximately 1985) is rapidly becoming obsolete. The current standard is SCSI-2 (see Further reading), with SCSI-3 on the drawing boards. In addition to a physical interconnection standard, SCSI defines a logical (command set) standard to which disk devices must adhere. This standard is called the Common Command Set (CCS) and was developed more or less in parallel with ANSI SCSI-1. SCSI-2 includes the (revised) CCS as part of the standard itself. The commands are dependent on the type of device at hand. It does not make much sense of course to define a Write command for a scanner. The SCSI bus is a parallel bus, which comes in a number of variants. The oldest and most used is an 8 bit wide bus, with single-ended signals, carried on 50 wires. (If you do not know what single-ended means, do not worry, that is what this document is all about.) Modern designs also use 16 bit wide buses, with differential signals. This allows transfer speeds of 20Mbytes/second, on cables lengths of up to 25 meters. SCSI-2 allows a maximum bus width of 32 bits, using an additional cable. Quickly emerging are Ultra SCSI (also called Fast-20) and Ultra2 (also called Fast-40). Fast-20 is 20 million transfers per second (20 Mbytes/sec on a 8 bit bus), Fast-40 is 40 million transfers per second (40 Mbytes/sec on a 8 bit bus). Most hard drives sold today are single-ended Ultra SCSI (8 or 16 bits). Of course the SCSI bus not only has data lines, but also a number of control signals. A very elaborate protocol is part of the standard to allow multiple devices to share the bus in an efficient manner. In SCSI-2, the data is always checked using a separate parity line. In pre-SCSI-2 designs parity was optional. In SCSI-3 even faster bus types are introduced, along with a serial SCSI busses that reduces the cabling overhead and allows a higher maximum bus length. You might see names like SSA and fibre channel in this context. None of the serial buses are currently in widespread use (especially not in the typical FreeBSD environment). For this reason the serial bus types are not discussed any further. As you could have guessed from the description above, SCSI devices are intelligent. They have to be to adhere to the SCSI standard (which is over 2 inches thick BTW). So, for a hard disk drive for instance you do not specify a head/cylinder/sector to address a particular block, but simply the number of the block you want. Elaborate caching schemes, automatic bad block replacement etc are all made possible by this intelligent device approach. On a SCSI bus, each possible pair of devices can communicate. Whether their function allows this is another matter, but the standard does not restrict it. To avoid signal contention, the 2 devices have to arbitrate for the bus before using it. The philosophy of SCSI is to have a standard that allows older-standard devices to work with newer-standard ones. So, an old SCSI-1 device should normally work on a SCSI-2 bus. I say Normally, because it is not absolutely sure that the implementation of an old device follows the (old) standard closely enough to be acceptable on a new bus. Modern devices are usually more well-behaved, because the standardization has become more strict and is better adhered to by the device manufacturers. Generally speaking, the chances of getting a working set of devices on a single bus is better when all the devices are SCSI-2 or newer. This implies that you do not have to dump all your old stuff when you get that shiny 80GB disk: I own a system on which a pre-SCSI-1 disk, a SCSI-2 QIC tape unit, a SCSI-1 helical scan tape unit and 2 SCSI-1 disks work together quite happily. From a performance standpoint you might want to separate your older and newer (=faster) devices however. This is especially advantageous if you have an Ultra160 host adapter where you should separate your U160 devices from the Fast and Wide SCSI-2 devices. Components of SCSI As said before, SCSI devices are smart. The idea is to put the knowledge about intimate hardware details onto the SCSI device itself. In this way, the host system does not have to worry about things like how many heads a hard disks has, or how many tracks there are on a specific tape device. If you are curious, the standard specifies commands with which you can query your devices on their hardware particulars. FreeBSD uses this capability during boot to check out what devices are connected and whether they need any special treatment. The advantage of intelligent devices is obvious: the device drivers on the host can be made in a much more generic fashion, there is no longer a need to change (and qualify!) drivers for every odd new device that is introduced. For cabling and connectors there is a golden rule: get good stuff. With bus speeds going up all the time you will save yourself a lot of grief by using good material. So, gold plated connectors, shielded cabling, sturdy connector hoods with strain reliefs etc are the way to go. Second golden rule: do no use cables longer than necessary. I once spent 3 days hunting down a problem with a flaky machine only to discover that shortening the SCSI bus by 1 meter solved the problem. And the original bus length was well within the SCSI specification. SCSI bus types From an electrical point of view, there are two incompatible bus types: single-ended and differential. This means that there are two different main groups of SCSI devices and controllers, which cannot be mixed on the same bus. It is possible however to use special converter hardware to transform a single-ended bus into a differential one (and vice versa). The differences between the bus types are explained in the next sections. In lots of SCSI related documentation there is a sort of jargon in use to abbreviate the different bus types. A small list: FWD: Fast Wide Differential FND: Fast Narrow Differential SE: Single Ended FN: Fast Narrow etc. With a minor amount of imagination one can usually imagine what is meant. Wide is a bit ambiguous, it can indicate 16 or 32 bit buses. As far as I know, the 32 bit variant is not (yet) in use, so wide normally means 16 bit. Fast means that the timing on the bus is somewhat different, so that on a narrow (8 bit) bus 10 Mbytes/sec are possible instead of 5 Mbytes/sec for slow SCSI. As discussed before, bus speeds of 20 and 40 million transfers/second are also emerging (Fast-20 == Ultra SCSI and Fast-40 == Ultra2 SCSI). The data lines > 8 are only used for data transfers and device addressing. The transfers of commands and status messages etc are only performed on the lowest 8 data lines. The standard allows narrow devices to operate on a wide bus. The usable bus width is negotiated between the devices. You have to watch your device addressing closely when mixing wide and narrow. Single ended buses A single-ended SCSI bus uses signals that are either 5 Volts or 0 Volts (indeed, TTL levels) and are relative to a COMMON ground reference. A singled ended 8 bit SCSI bus has approximately 25 ground lines, who are all tied to a single rail on all devices. A standard single ended bus has a maximum length of 6 meters. If the same bus is used with fast-SCSI devices, the maximum length allowed drops to 3 meters. Fast-SCSI means that instead of 5Mbytes/sec the bus allows 10Mbytes/sec transfers. Fast-20 (Ultra SCSI) and Fast-40 allow for 20 and 40 million transfers/second respectively. So, F20 is 20 Mbytes/second on a 8 bit bus, 40 Mbytes/second on a 16 bit bus etc. For F20 the max bus length is 1.5 meters, for F40 it becomes 0.75 meters. Be aware that F20 is pushing the limits quite a bit, so you will quickly find out if your SCSI bus is electrically sound. If some devices on your bus use fast to communicate your bus must adhere to the length restrictions for fast buses! It is obvious that with the newer fast-SCSI devices the bus length can become a real bottleneck. This is why the differential SCSI bus was introduced in the SCSI-2 standard. For connector pinning and connector types please refer to the SCSI-2 standard (see Further reading) itself, connectors etc are listed there in painstaking detail. Beware of devices using non-standard cabling. For instance Apple uses a 25pin D-type connecter (like the one on serial ports and parallel printers). Considering that the official SCSI bus needs 50 pins you can imagine the use of this connector needs some creative cabling. The reduction of the number of ground wires they used is a bad idea, you better stick to 50 pins cabling in accordance with the SCSI standard. For Fast-20 and 40 do not even think about buses like this. Differential buses A differential SCSI bus has a maximum length of 25 meters. Quite a difference from the 3 meters for a single-ended fast-SCSI bus. The idea behind differential signals is that each bus signal has its own return wire. So, each signal is carried on a (preferably twisted) pair of wires. The voltage difference between these two wires determines whether the signal is asserted or de-asserted. To a certain extent the voltage difference between ground and the signal wire pair is not relevant (do not try 10 kVolts though). It is beyond the scope of this document to explain why this differential idea is so much better. Just accept that electrically seen the use of differential signals gives a much better noise margin. You will normally find differential buses in use for inter-cabinet connections. Because of the lower cost single ended is mostly used for shorter buses like inside cabinets. There is nothing that stops you from using differential stuff with FreeBSD, as long as you use a controller that has device driver support in FreeBSD. As an example, Adaptec marketed the AHA1740 as a single ended board, whereas the AHA1744 was differential. The software interface to the host is identical for both. Terminators Terminators in SCSI terminology are resistor networks that are used to get a correct impedance matching. Impedance matching is important to get clean signals on the bus, without reflections or ringing. If you once made a long distance telephone call on a bad line you probably know what reflections are. With 20Mbytes/sec traveling over your SCSI bus, you do not want signals echoing back. Terminators come in various incarnations, with more or less sophisticated designs. Of course, there are internal and external variants. Many SCSI devices come with a number of sockets in which a number of resistor networks can (must be!) installed. If you remove terminators from a device, carefully store them. You will need them when you ever decide to reconfigure your SCSI bus. There is enough variation in even these simple tiny things to make finding the exact replacement a frustrating business. There are also SCSI devices that have a single jumper to enable or disable a built-in terminator. There are special terminators you can stick onto a flat cable bus. Others look like external connectors, or a connector hood without a cable. So, lots of choice as you can see. There is much debate going on if and when you should switch from simple resistor (passive) terminators to active terminators. Active terminators contain slightly more elaborate circuit to give cleaner bus signals. The general consensus seems to be that the usefulness of active termination increases when you have long buses and/or fast devices. If you ever have problems with your SCSI buses you might consider trying an active terminator. Try to borrow one first, they reputedly are quite expensive. Please keep in mind that terminators for differential and single-ended buses are not identical. You should not mix the two variants. OK, and now where should you install your terminators? This is by far the most misunderstood part of SCSI. And it is by far the simplest. The rule is: every single line on the SCSI bus has 2 (two) terminators, one at each end of the bus. So, two and not one or three or whatever. Do yourself a favor and stick to this rule. It will save you endless grief, because wrong termination has the potential to introduce highly mysterious bugs. (Note the potential here; the nastiest part is that it may or may not work.) A common pitfall is to have an internal (flat) cable in a machine and also an external cable attached to the controller. It seems almost everybody forgets to remove the terminators from the controller. The terminator must now be on the last external device, and not on the controller! In general, every reconfiguration of a SCSI bus must pay attention to this. Termination is to be done on a per-line basis. This means if you have both narrow and wide buses connected to the same host adapter, you need to enable termination on the higher 8 bits of the bus on the adapter (as well as the last devices on each bus, of course). What I did myself is remove all terminators from my SCSI devices and controllers. I own a couple of external terminators, for both the Centronics-type external cabling and for the internal flat cable connectors. This makes reconfiguration much easier. On modern devices, sometimes integrated terminators are used. These things are special purpose integrated circuits that can be enabled or disabled with a control pin. It is not necessary to physically remove them from a device. You may find them on newer host adapters, sometimes they are software configurable, using some sort of setup tool. Some will even auto-detect the cables attached to the connectors and automatically set up the termination as necessary. At any rate, consult your documentation! Terminator power The terminators discussed in the previous chapter need power to operate properly. On the SCSI bus, a line is dedicated to this purpose. So, simple huh? Not so. Each device can provide its own terminator power to the terminator sockets it has on-device. But if you have external terminators, or when the device supplying the terminator power to the SCSI bus line is switched off you are in trouble. The idea is that initiators (these are devices that initiate actions on the bus, a discussion follows) must supply terminator power. All SCSI devices are allowed (but not required) to supply terminator power. To allow for un-powered devices on a bus, the terminator power must be supplied to the bus via a diode. This prevents the backflow of current to un-powered devices. To prevent all kinds of nastiness, the terminator power is usually fused. As you can imagine, fuses might blow. This can, but does not have to, lead to a non functional bus. If multiple devices supply terminator power, a single blown fuse will not put you out of business. A single supplier with a blown fuse certainly will. Clever external terminators sometimes have a LED indication that shows whether terminator power is present. In newer designs auto-restoring fuses that reset themselves after some time are sometimes used. Device addressing Because the SCSI bus is, ehh, a bus there must be a way to distinguish or address the different devices connected to it. This is done by means of the SCSI or target ID. Each device has a unique target ID. You can select the ID to which a device must respond using a set of jumpers, or a dip switch, or something similar. Some SCSI host adapters let you change the target ID from the boot menu. (Yet some others will not let you change the ID from 7.) Consult the documentation of your device for more information. Beware of multiple devices configured to use the same ID. Chaos normally reigns in this case. A pitfall is that one of the devices sharing the same ID sometimes even manages to answer to I/O requests! For an 8 bit bus, a maximum of 8 targets is possible. The maximum is 8 because the selection is done bitwise using the 8 data lines on the bus. For wide buses this increases to the number of data lines (usually 16). A narrow SCSI device can not communicate with a SCSI device with a target ID larger than 7. This means it is generally not a good idea to move your SCSI host adapter's target ID to something higher than 7 (or your CDROM will stop working). The higher the SCSI target ID, the higher the priority the devices has. When it comes to arbitration between devices that want to use the bus at the same time, the device that has the highest SCSI ID will win. This also means that the SCSI host adapter usually uses target ID 7. Note however that the lower 8 IDs have higher priorities than the higher 8 IDs on a wide-SCSI bus. Thus, the order of target IDs is: [7 6 .. 1 0 15 14 .. 9 8] on a wide-SCSI system. (If you are wondering why the lower 8 have higher priority, read the previous paragraph for a hint.) For a further subdivision, the standard allows for Logical Units or LUNs for short. A single target ID may have multiple LUNs. For example, a tape device including a tape changer may have LUN 0 for the tape device itself, and LUN 1 for the tape changer. In this way, the host system can address each of the functional units of the tape changer as desired. Bus layout SCSI buses are linear. So, not shaped like Y-junctions, star topologies, rings, cobwebs or whatever else people might want to invent. One of the most common mistakes is for people with wide-SCSI host adapters to connect devices on all three connecters (external connector, internal wide connector, internal narrow connector). Do not do that. It may appear to work if you are really lucky, but I can almost guarantee that your system will stop functioning at the most unfortunate moment (this is also known as Murphy's law). You might notice that the terminator issue discussed earlier becomes rather hairy if your bus is not linear. Also, if you have more connectors than devices on your internal SCSI cable, make sure you attach devices on connectors on both ends instead of using the connectors in the middle and let one or both ends dangle. This will screw up the termination of the bus. The electrical characteristics, its noise margins and ultimately the reliability of it all are tightly related to linear bus rule. Stick to the linear bus rule! Using SCSI with FreeBSD About translations, BIOSes and magic... As stated before, you should first make sure that you have a electrically sound bus. When you want to use a SCSI disk on your PC as boot disk, you must aware of some quirks related to PC BIOSes. The PC BIOS in its first incarnation used a low level physical interface to the hard disk. So, you had to tell the BIOS (using a setup tool or a BIOS built-in setup) how your disk physically looked like. This involved stating number of heads, number of cylinders, number of sectors per track, obscure things like precompensation and reduced write current cylinder etc. One might be inclined to think that since SCSI disks are smart you can forget about this. Alas, the arcane setup issue is still present today. The system BIOS needs to know how to access your SCSI disk with the head/cyl/sector method in order to load the FreeBSD kernel during boot. The SCSI host adapter or SCSI controller you have put in your AT/EISA/PCI/whatever bus to connect your disk therefore has its own on-board BIOS. During system startup, the SCSI BIOS takes over the hard disk interface routines from the system BIOS. To fool the system BIOS, the system setup is normally set to No hard disk present. Obvious, is it not? The SCSI BIOS itself presents to the system a so called translated drive. This means that a fake drive table is constructed that allows the PC to boot the drive. This translation is often (but not always) done using a pseudo drive with 64 heads and 32 sectors per track. By varying the number of cylinders, the SCSI BIOS adapts to the actual drive size. It is useful to note that 32 * 64 / 2 = the size of your drive in megabytes. The division by 2 is to get from disk blocks that are normally 512 bytes in size to Kbytes. Right. All is well now?! No, it is not. The system BIOS has another quirk you might run into. The number of cylinders of a bootable hard disk cannot be greater than 1024. Using the translation above, this is a show-stopper for disks greater than 1 GB. With disk capacities going up all the time this is causing problems. Fortunately, the solution is simple: just use another translation, e.g. with 128 heads instead of 32. In most cases new SCSI BIOS versions are available to upgrade older SCSI host adapters. Some newer adapters have an option, in the form of a jumper or software setup selection, to switch the translation the SCSI BIOS uses. It is very important that all operating systems on the disk use the same translation to get the right idea about where to find the relevant partitions. So, when installing FreeBSD you must answer any questions about heads/cylinders etc using the translated values your host adapter uses. Failing to observe the translation issue might lead to un-bootable systems or operating systems overwriting each others partitions. Using fdisk you should be able to see all partitions. You might have heard some talk of lying devices? Older FreeBSD kernels used to report the geometry of SCSI disks when booting. An example from one of my systems: aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4> da0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512 Newer kernels usually do not report this information. e.g. (bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2 da0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors) Why has this changed? This info is retrieved from the SCSI disk itself. Newer disks often use a technique called zone bit recording. The idea is that on the outer cylinders of the drive there is more space so more sectors per track can be put on them. This results in disks that have more tracks on outer cylinders than on the inner cylinders and, last but not least, have more capacity. You can imagine that the value reported by the drive when inquiring about the geometry now becomes suspect at best, and nearly always misleading. When asked for a geometry, it is nearly always better to supply the geometry used by the BIOS, or if the BIOS is never going to know about this disk, (e.g. it is not a booting disk) to supply a fictitious geometry that is convenient. SCSI subsystem design FreeBSD uses a layered SCSI subsystem. For each different controller card a device driver is written. This driver knows all the intimate details about the hardware it controls. The driver has a interface to the upper layers of the SCSI subsystem through which it receives its commands and reports back any status. On top of the card drivers there are a number of more generic drivers for a class of devices. More specific: a driver for tape devices (abbreviation: sa, for serial access), magnetic disks (da, for direct access), CDROMs (cd) etc. In case you are wondering where you can find this stuff, it all lives in /sys/cam/scsi. See the man pages in section 4 for more details. The multi level design allows a decoupling of low-level bit banging and more high level stuff. Adding support for another piece of hardware is a much more manageable problem. Kernel configuration Dependent on your hardware, the kernel configuration file must contain one or more lines describing your host adapter(s). This includes I/O addresses, interrupts etc. Consult the manual page for your adapter driver to get more info. Apart from that, check out /sys/i386/conf/LINT for an overview of a kernel config file. LINT contains every possible option you can dream of. It does not imply LINT will actually get you to a working kernel at all. Although it is probably stating the obvious: the kernel config file should reflect your actual hardware setup. So, interrupts, I/O addresses etc must match the kernel config file. During system boot messages will be displayed to indicate whether the configured hardware was actually found. Note that most of the EISA/PCI drivers (namely ahb, ahc, ncr and amd will automatically obtain the correct parameters from the host adapters themselves at boot time; thus, you just need to write, for instance, controller ahc0. An example loosely based on the FreeBSD 2.2.5-Release kernel config file LINT with some added comments (between []): # SCSI host adapters: `aha', `ahb', `aic', `bt', `nca' # # aha: Adaptec 154x # ahb: Adaptec 174x # ahc: Adaptec 274x/284x/294x # aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!) # amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # [For an Adaptec AHA274x/284x/294x/394x etc controller] controller ahc0 [For an NCR/Symbios 53c875 based controller] controller ncr0 [For an Ultrastor adapter] controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr # Map SCSI buses to specific SCSI adapters controller scbus0 at ahc0 controller scbus2 at ncr0 controller scbus1 at uha0 # The actual SCSI devices disk da0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0] disk da1 at scbus0 target 1 [implicit LUN 0 if omitted] disk da2 at scbus1 target 3 [SCSI disk on the uha0] disk da3 at scbus2 target 4 [SCSI disk on the ncr0] tape sa1 at scbus0 target 6 [SCSI tape at target 6] device cd0 at scbus? [the first ever CDROM found, no wiring] The example above tells the kernel to look for a ahc (Adaptec 274x) controller, then for an NCR/Symbios board, and so on. The lines following the controller specifications tell the kernel to configure specific devices but only attach them when they match the target ID and LUN specified on the corresponding bus. Wired down devices get first shot at the unit numbers so the first non wired down device, is allocated the unit number one greater than the highest wired down unit number for that kind of device. So, if you had a SCSI tape at target ID 2 it would be configured as sa2, as the tape at target ID 6 is wired down to unit number 1. Wired down devices need not be found to get their unit number. The unit number for a wired down device is reserved for that device, even if it is turned off at boot time. This allows the device to be turned on and brought on-line at a later time, without rebooting. Notice that a device's unit number has no relationship with its target ID on the SCSI bus. Below is another example of a kernel config file as used by FreeBSD version < 2.0.5. The difference with the first example is that devices are not wired down. Wired down means that you specify which SCSI target belongs to which device. A kernel built to the config file below will attach the first SCSI disk it finds to da0, the second disk to da1 etc. If you ever removed or added a disk, all other devices of the same type (disk in this case) would move around. This implies you have to change /etc/fstab each time. Although the old style still works, you are strongly recommended to use this new feature. It will save you a lot of grief whenever you shift your hardware around on the SCSI buses. So, when you re-use your old trusty config file after upgrading from a pre-FreeBSD2.0.5.R system check this out. [driver for Adaptec 174x] controller ahb0 at isa? bio irq 11 vector ahbintr [for Adaptec 154x] controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr [for Seagate ST01/02] controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device da0 [support for 4 SCSI harddisks, da0 up da3] device sa0 [support for 2 SCSI tapes] [for the CDROM] device cd0 #Only need one of these, the code dynamically grows Both examples support SCSI disks. If during boot more devices of a specific type (e.g. da disks) are found than are configured in the booting kernel, the system will simply allocate more devices, incrementing the unit number starting at the last number wired down. If there are no wired down devices then counting starts at unit 0. Use man 4 scsi to check for the latest info on the SCSI subsystem. For more detailed info on host adapter drivers use e.g., man 4 ahc for info on the Adaptec 294x driver. Tuning your SCSI kernel setup Experience has shown that some devices are slow to respond to INQUIRY commands after a SCSI bus reset (which happens at boot time). An INQUIRY command is sent by the kernel on boot to see what kind of device (disk, tape, CDROM etc.) is connected to a specific target ID. This process is called device probing by the way. To work around the slow response problem, FreeBSD allows a tunable delay time before the SCSI devices are probed following a SCSI bus reset. You can set this delay time in your kernel configuration file using a line like: options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device This line sets the delay time to 15 seconds. On my own system I had to use 3 seconds minimum to get my trusty old CDROM drive to be recognized. Start with a high value (say 30 seconds or so) when you have problems with device recognition. If this helps, tune it back until it just stays working. Rogue SCSI devices Although the SCSI standard tries to be complete and concise, it is a complex standard and implementing things correctly is no easy task. Some vendors do a better job then others. This is exactly where the rogue devices come into view. Rogues are devices that are recognized by the FreeBSD kernel as behaving slightly (...) non-standard. Rogue devices are reported by the kernel when booting. An example for two of my cartridge tape units: Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:> Feb 25 21:03:34 yedi /kernel: sa0: Tandberg tdc3600 is a known rogue Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005> Mar 29 21:16:37 yedi /kernel: sa1: Archive Viper 150 is a known rogue For instance, there are devices that respond to all LUNs on a certain target ID, even if they are actually only one device. It is easy to see that the kernel might be fooled into believing that there are 8 LUNs at that particular target ID. The confusion this causes is left as an exercise to the reader. The SCSI subsystem of FreeBSD recognizes devices with bad habits by looking at the INQUIRY response they send when probed. Because the INQUIRY response also includes the version number of the device firmware, it is even possible that for different firmware versions different workarounds are used. See e.g. /sys/cam/scsi/scsi_sa.c and /sys/cam/scsi/scsi_all.c for more info on how this is done. This scheme works fine, but keep in mind that it of course only works for devices that are known to be weird. If you are the first to connect your bogus Mumbletech SCSI CDROM you might be the one that has to define which workaround is needed. After you got your Mumbletech working, please send the required workaround to the FreeBSD development team for inclusion in the next release of FreeBSD. Other Mumbletech owners will be grateful to you. Multiple LUN devices In some cases you come across devices that use multiple logical units (LUNs) on a single SCSI ID. In most cases FreeBSD only probes devices for LUN 0. An example are so called bridge boards that connect 2 non-SCSI hard disks to a SCSI bus (e.g. an Emulex MD21 found in old Sun systems). This means that any devices with LUNs != 0 are not normally found during device probe on system boot. To work around this problem you must add an appropriate entry in /sys/cam/scsi and rebuild your kernel. Look for a struct that is initialized like below: (FIXME: which file? Do these entries still exist in this form now that we use CAM?) { T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A", "mx1", SC_ONE_LU } For your Mumbletech BRIDGE2000 that has more than one LUN, acts as a SCSI disk and has firmware revision 123 you would add something like: { T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123", "da", SC_MORE_LUS } The kernel on boot scans the inquiry data it receives against the table and acts accordingly. See the source for more info. Tagged command queuing Modern SCSI devices, particularly magnetic disks, support what is called tagged command queuing (TCQ). In a nutshell, TCQ allows the device to have multiple I/O requests outstanding at the same time. Because the device is intelligent, it can optimize its operations (like head positioning) based on its own request queue. On SCSI devices like RAID (Redundant Array of Independent Disks) arrays the TCQ function is indispensable to take advantage of the device's inherent parallelism. Each I/O request is uniquely identified by a tag (hence the name tagged command queuing) and this tag is used by FreeBSD to see which I/O in the device drivers queue is reported as complete by the device. It should be noted however that TCQ requires device driver support and that some devices implemented it not quite right in their firmware. This problem bit me once, and it leads to highly mysterious problems. In such cases, try to disable TCQ. Bus-master host adapters Most, but not all, SCSI host adapters are bus mastering controllers. This means that they can do I/O on their own without putting load onto the host CPU for data movement. This is of course an advantage for a multitasking operating system like FreeBSD. It must be noted however that there might be some rough edges. For instance an Adaptec 1542 controller can be set to use different transfer speeds on the host bus (ISA or AT in this case). The controller is settable to different rates because not all motherboards can handle the higher speeds. Problems like hang-ups, bad data etc might be the result of using a higher data transfer rate then your motherboard can stomach. The solution is of course obvious: switch to a lower data transfer rate and try if that works better. In the case of a Adaptec 1542, there is an option that can be put into the kernel config file to allow dynamic determination of the right, read: fastest feasible, transfer rate. This option is disabled by default: options "TUNE_1542" #dynamic tune of bus DMA speed Check the manual pages for the host adapter that you use. Or better still, use the ultimate documentation (read: driver source). Tracking down problems The following list is an attempt to give a guideline for the most common SCSI problems and their solutions. It is by no means complete. Check for loose connectors and cables. Check and double check the location and number of your terminators. Check if your bus has at least one supplier of terminator power (especially with external terminators. Check if no double target IDs are used. Check if all devices to be used are powered up. Make a minimal bus config with as little devices as possible. If possible, configure your host adapter to use slow bus speeds. Disable tagged command queuing to make things as simple as possible (for a NCR host adapter based system see man ncrcontrol) If you can compile a kernel, make one with the SCSIDEBUG option, and try accessing the device with debugging turned on for that device. If your device does not even probe at startup, you may have to define the address of the device that is failing, and the desired debug level in /sys/cam/cam_debug.h. If it probes but just does not work, you can use the &man.camcontrol.8; command to dynamically set a debug level to it in a running kernel (if CAMDEBUG is defined). This will give you copious debugging output with which to confuse the gurus. See man camcontrol for more exact information. Also look at man 4 pass. Further reading If you intend to do some serious SCSI hacking, you might want to have the official standard at hand: Approved American National Standards can be purchased from ANSI at
13th Floor 11 West 42nd Street New York NY 10036 Sales Dept: (212) 642-4900
You can also buy many ANSI standards and most committee draft documents from Global Engineering Documents,
15 Inverness Way East Englewood CO, 80112-5704 Phone: (800) 854-7179 Outside USA and Canada: (303) 792-2181 Fax: (303) 792- 2192
Many X3T10 draft documents are available electronically on the SCSI BBS (719-574-0424) and on the ncrinfo.ncr.com anonymous FTP site. Latest X3T10 committee documents are: AT Attachment (ATA or IDE) [X3.221-1994] (Approved) ATA Extensions (ATA-2) [X3T10/948D Rev 2i] Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (Approved) Small Computer System Interface — 2 (SCSI-2) [X3.131-1994] (Approved) SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM) [X3T10/792D Rev 11] Other publications that might provide you with additional information are: SCSI: Understanding the Small Computer System Interface, written by NCR Corporation. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-796855-8 Basics of SCSI, a SCSI tutorial written by Ancot Corporation Contact Ancot for availability information at: Phone: (415) 322-5322 Fax: (415) 322-0455 SCSI Interconnection Guide Book, an AMP publication (dated 4/93, Catalog 65237) that lists the various SCSI connectors and suggests cabling schemes. Available from AMP at (800) 522-6752 or (717) 564-0100 Fast Track to SCSI, A Product Guide written by Fujitsu. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X The SCSI Bench Reference, The SCSI Encyclopedia, and the SCSI Tutor, ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642 Zadian SCSI Navigator (quick ref. book) and Discover the Power of SCSI (First book along with a one-hour video and tutorial book), Zadian Software, Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800 On Usenet the newsgroups comp.periphs.scsi and comp.periphs are noteworthy places to look for more info. You can also find the SCSI-FAQ there, which is posted periodically. Most major SCSI device and host adapter suppliers operate FTP sites and/or BBS systems. They may be valuable sources of information about the devices you own. * Disk/tape controllers * SCSI * IDE * Floppy Hard drives SCSI hard drives Contributed by &a.asami;. 17 February 1998. As mentioned in the SCSI section, virtually all SCSI hard drives sold today are SCSI-2 compliant and thus will work fine as long as you connect them to a supported SCSI host adapter. Most problems people encounter are either due to badly designed cabling (cable too long, star topology, etc.), insufficient termination, or defective parts. Please refer to the SCSI section first if your SCSI hard drive is not working. However, there are a couple of things you may want to take into account before you purchase SCSI hard drives for your system. Rotational speed Rotational speeds of SCSI drives sold today range from around 4,500RPM to 15,000RPM. Most of them are either 7,200RPM or 10,000RPM, with 15,000RPM becoming affordable (June 2002). Even though the 10,000RPM drives can generally transfer data faster, they run considerably hotter than their 7,200RPM counterparts. A large fraction of today's disk drive malfunctions are heat-related. If you do not have very good cooling in your PC case, you may want to stick with 7,200RPM or slower drives. Note that newer drives, with higher areal recording densities, can deliver much more bits per rotation than older ones. Today's top-of-line 7,200RPM drives can sustain a throughput comparable to 10,000RPM drives of one or two model generations ago. The number to find on the spec sheet for bandwidth is internal data (or transfer) rate. It is usually in megabits/sec so divide it by 8 and you will get the rough approximation of how much megabytes/sec you can get out of the drive. (If you are a speed maniac and want a 15,000RPM drive for your cute little PC, be my guest; however, those drives become extremely hot. Do not even think about it if you do not have a fan blowing air directly at the drive or a properly ventilated disk enclosure.) Obviously, the latest 15,000RPM drives and 10,000RPM drives can deliver more data than the latest 7,200RPM drives, so if absolute bandwidth is the necessity for your applications, you have little choice but to get the faster drives. Also, if you need low latency, faster drives are better; not only do they usually have lower average seek times, but also the rotational delay is one place where slow-spinning drives can never beat a faster one. (The average rotational latency is half the time it takes to rotate the drive once; thus, it is 2 milliseconds for 15,000RPM, 3ms for 10,000RPM drives, 4.2ms for 7,200RPM drives and 5.6ms for 5,400RPM drives.) Latency is seek time plus rotational delay. Make sure you understand whether you need low latency or more accesses per second, though; in the latter case (e.g., news servers), it may not be optimal to purchase one big fast drive. You can achieve similar or even better results by using the ccd (concatenated disk) driver to create a striped disk array out of multiple slower drives for comparable overall cost. Make sure you have adequate air flow around the drive, especially if you are going to use a fast-spinning drive. You generally need at least 1/2” (1.25cm) of spacing above and below a drive. Understand how the air flows through your PC case. Most cases have the power supply suck the air out of the back. See where the air flows in, and put the drive where it will have the largest volume of cool air flowing around it. You may need to seal some unwanted holes or add a new fan for effective cooling. Another consideration is noise. Many 10,000 or faster drives generate a high-pitched whine which is quite unpleasant to most people. That, plus the extra fans often required for cooling, may make 10,000 or faster drives unsuitable for some office and home environments. Form factor Most SCSI drives sold today are of 3.5” form factor. They come in two different heights; 1.6” (half-height) or 1” (low-profile). The half-height drive is the same height as a CDROM drive. However, do not forget the spacing rule mentioned in the previous section. If you have three standard 3.5” drive bays, you will not be able to put three half-height drives in there (without frying them, that is). Interface The majority of SCSI hard drives sold today are Ultra, Ultra-wide, or Ultra160 SCSI. As of this writing (June 2002), the first Ultra320 host adapters and devices become available. The maximum bandwidth of Ultra SCSI is 20MB/sec, and Ultra-wide SCSI is 40MB/sec. Ultra160 can transfer 160MB/sec and Ultra320 can transfer 320MB/sec. There is no difference in max cable length between Ultra and Ultra-wide; however, the more devices you have on the same bus, the sooner you will start having bus integrity problems. Unless you have a well-designed disk enclosure, it is not easy to make more than 5 or 6 Ultra SCSI drives work on a single bus. On the other hand, if you need to connect many drives, going for Fast-wide SCSI may not be a bad idea. That will have the same max bandwidth as Ultra (narrow) SCSI, while electronically it is much easier to get it right. My advice would be: if you want to connect many disks, get wide or Ultra160 SCSI drives; they usually cost a little more but it may save you down the road. (Besides, if you can not afford the cost difference, you should not be building a disk array.) There are two variant of wide SCSI drives; 68-pin and 80-pin SCA (Single Connector Attach). The SCA drives do not have a separate 4-pin power connector, and also read the SCSI ID settings through the 80-pin connector. If you are really serious about building a large storage system, get SCA drives and a good SCA enclosure (dual power supply with at least one extra fan). They are more electronically sound than 68-pin counterparts because there is no stub of the SCSI bus inside the disk canister as in arrays built from 68-pin drives. They are easier to install too (you just need to screw the drive in the canister, instead of trying to squeeze in your fingers in a tight place to hook up all the little cables (like the SCSI ID and disk activity LED lines). * IDE hard drives Tape drives Contributed by &a.jmb;. 2 July 1996. General tape access commands &man.mt.1; provides generic access to the tape drives. Some of the more common commands are rewind, erase, and status. See the &man.mt.1; manual page for a detailed description. Controller Interfaces There are several different interfaces that support tape drives. The interfaces are SCSI, IDE, Floppy and Parallel Port. A wide variety of tape drives are available for these interfaces. Controllers are discussed in Disk/tape controllers. SCSI drives The &man.st.4; driver provides support for 8mm (Exabyte), 4mm (DAT: Digital Audio Tape), QIC (Quarter-Inch Cartridge), DLT (Digital Linear Tape), QIC Mini cartridge and 9-track (remember the big reels that you see spinning in Hollywood computer rooms) tape drives. See the &man.st.4; manual page for a detailed description. The drives listed below are currently being used by members of the FreeBSD community. They are not the only drives that will work with FreeBSD. They just happen to be the ones that we use. 4mm (DAT: Digital Audio Tape) Archive Python 28454 Archive Python 04687 HP C1533A HP C1534A HP 35450A HP 35470A HP 35480A SDT-5000 Wangtek 6200 8mm (Exabyte) EXB-8200 EXB-8500 EXB-8505 QIC (Quarter-Inch Cartridge) Archive Anaconda 2750 Archive Viper 60 Archive Viper 150 Archive Viper 2525 Tandberg TDC 3600 Tandberg TDC 3620 Tandberg TDC 3800 Tandberg TDC 4222 Wangtek 5525ES DLT (Digital Linear Tape) Digital TZ87 Mini-Cartridge Conner CTMS 3200 Exabyte 2501 Autoloaders/Changers Hewlett-Packard HP C1553A Autoloading DDS2 * IDE drives Floppy drives Conner 420R * Parallel port drives Detailed Information Archive Anaconda 2750 The boot message identifier for this drive is ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 1.35GB when using QIC-1350 tapes. This drive will read and write QIC-150 (DC6150), QIC-250 (DC6250), and QIC-525 (DC6525) tapes as well. Data transfer rate is 350kB/s using &man.dump.8;. Rates of 530kB/s have been reported when using Amanda Production of this drive has been discontinued. The SCSI bus connector on this tape drive is reversed from that on most other SCSI devices. Make sure that you have enough SCSI cable to twist the cable one-half turn before and after the Archive Anaconda tape drive, or turn your other SCSI devices upside-down. Two kernel code changes are required to use this drive. This drive will not work as delivered. If you have a SCSI-2 controller, short jumper 6. Otherwise, the drive behaves are a SCSI-1 device. When operating as a SCSI-1 device, this drive, locks the SCSI bus during some tape operations, including: fsf, rewind, and rewoffl. If you are using the NCR SCSI controllers, patch the file /usr/src/sys/pci/ncr.c (as shown below). Build and install a new kernel. *** 4831,4835 **** }; ! if (np->latetime>4) { /* ** Although we tried to wake it up, --- 4831,4836 ---- }; ! if (np->latetime>1200) { /* ** Although we tried to wake it up, Reported by: &a.jmb; Archive Python 28454 The boot message identifier for this drive is ARCHIVE Python 28454-XXX4ASB type 1 removable SCSI 2 density code 0x8c, 512-byte blocks This is a DDS-1 tape drive. Native capacity is 2.5GB on 90m tapes. Data transfer rate is XXX. This drive was repackaged by Sun Microsystems as model 595-3067. Reported by: Bob Bishop rb@gid.co.uk Throughput is in the 1.5 MByte/sec range, however this will drop if the disks and tape drive are on the same SCSI controller. Reported by: Robert E. Seastrom rs@seastrom.com Archive Python 04687 The boot message identifier for this drive is ARCHIVE Python 04687-XXX 6580 Removable Sequential Access SCSI-2 device This is a DAT-DDS-2 drive. Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Switch 4 controls MRS (Media Recognition System). MRS tapes have stripes on the transparent leader. Switch 4 off enables MRS, on disables MRS. Parity is controlled by switch 5. Switch 5 on to enable parity control. Compression is enabled with Switch 6 off. It is possible to override compression with the SCSI MODE SELECT command (see &man.mt.1;). Data transfer rate is 800kB/s. Archive Viper 60 The boot message identifier for this drive is ARCHIVE VIPER 60 21116 -007 type 1 removable SCSI 1 This is a QIC tape drive. Native capacity is 60MB. Data transfer rate is XXX. Production of this drive has been discontinued. Reported by: Philippe Regnauld regnauld@hsc.fr Archive Viper 150 The boot message identifier for this drive is ARCHIVE VIPER 150 21531 -004 Archive Viper 150 is a known rogue type 1 removable SCSI 1. A multitude of firmware revisions exist for this drive. Your drive may report different numbers (e.g 21247 -005. This is a QIC tape drive. Native capacity is 150/250MB. Both 150MB (DC6150) and 250MB (DC6250) tapes have the recording format. The 250MB tapes are approximately 67% longer than the 150MB tapes. This drive can read 120MB tapes as well. It can not write 120MB tapes. Data transfer rate is 100kB/s This drive reads and writes DC6150 (150MB) and DC6250 (250MB) tapes. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;). Under FreeBSD 2.2-CURRENT, use mt blocksize 512 to set the blocksize. (The particular drive had firmware revision 21247 -005. Other firmware revisions may behave differently) Previous versions of FreeBSD did not have this problem. Production of this drive has been discontinued. Reported by: Pedro A M Vazquez vazquez@IQM.Unicamp.BR &a.msmith; Archive Viper 2525 The boot message identifier for this drive is ARCHIVE VIPER 2525 25462 -011 type 1 removable SCSI 1 This is a QIC tape drive. Native capacity is 525MB. Data transfer rate is 180kB/s at 90 inches/sec. The drive reads QIC-525, QIC-150, QIC-120 and QIC-24 tapes. Writes QIC-525, QIC-150, and QIC-120. Firmware revisions prior to 25462 -011 are bug ridden and will not function properly. Production of this drive has been discontinued. Conner 420R The boot message identifier for this drive is Conner tape. This is a floppy controller, mini cartridge tape drive. Native capacity is XXXX Data transfer rate is XXX The drive uses QIC-80 tape cartridges. Reported by: Mark Hannon mark@seeware.DIALix.oz.au Conner CTMS 3200 The boot message identifier for this drive is CONNER CTMS 3200 7.00 type 1 removable SCSI 2. This is a mini cartridge tape drive. Native capacity is XXXX Data transfer rate is XXX The drive uses QIC-3080 tape cartridges. Reported by: Thomas S. Traylor tst@titan.cs.mci.com <ulink url="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink> The boot message identifier for this drive is DEC TZ87 (C) DEC 9206 type 1 removable SCSI 2 density code 0x19 This is a DLT tape drive. Native capacity is 10GB. This drive supports hardware data compression. Data transfer rate is 1.2MB/s. This drive is identical to the Quantum DLT2000. The drive firmware can be set to emulate several well-known drives, including an Exabyte 8mm drive. Reported by: &a.wilko; <ulink url="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink> The boot message identifier for this drive is EXABYTE EXB-2501 This is a mini-cartridge tape drive. Native capacity is 1GB when using MC3000XL mini cartridges. Data transfer rate is XXX This drive can read and write DC2300 (550MB), DC2750 (750MB), MC3000 (750MB), and MC3000XL (1GB) mini cartridges. WARNING: This drive does not meet the SCSI-2 specifications. The drive locks up completely in response to a SCSI MODE_SELECT command unless there is a formatted tape in the drive. Before using this drive, set the tape blocksize with &prompt.root; mt -f /dev/st0ctl.0 blocksize 1024 Before using a mini cartridge for the first time, the mini cartridge must be formated. FreeBSD 2.1.0-RELEASE and earlier: &prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0" (Alternatively, fetch a copy of the scsiformat shell script from FreeBSD 2.1.5/2.2.) FreeBSD 2.1.5 and later: &prompt.root; /sbin/scsiformat -q -w /dev/rst0.ctl Right now, this drive cannot really be recommended for FreeBSD. Reported by: Bob Beaulieu ez@eztravel.com Exabyte EXB-8200 The boot message identifier for this drive is EXABYTE EXB-8200 252X type 1 removable SCSI 1 This is an 8mm tape drive. Native capacity is 2.3GB. Data transfer rate is 270kB/s. This drive is fairly slow in responding to the SCSI bus during boot. A custom kernel may be required (set SCSI_DELAY to 10 seconds). There are a large number of firmware configurations for this drive, some have been customized to a particular vendor's hardware. The firmware can be changed via EPROM replacement. Production of this drive has been discontinued. Reported by: &a.msmith; Exabyte EXB-8500 The boot message identifier for this drive is EXABYTE EXB-8500-85Qanx0 0415 type 1 removable SCSI 2 This is an 8mm tape drive. Native capacity is 5GB. Data transfer rate is 300kB/s. Reported by: Greg Lehey grog@lemis.de <ulink url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink> The boot message identifier for this drive is EXABYTE EXB-85058SQANXR1 05B0 type 1 removable SCSI 2 This is an 8mm tape drive which supports compression, and is upward compatible with the EXB-5200 and EXB-8500. Native capacity is 5GB. The drive supports hardware data compression. Data transfer rate is 300kB/s. Reported by: Glen Foster gfoster@gfoster.com Hewlett-Packard HP C1533A The boot message identifier for this drive is HP C1533A 9503 type 1 removable SCSI 2. This is a DDS-2 tape drive. DDS-2 means hardware data compression and narrower tracks for increased data capacity. Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is 510kB/s. This drive is used in Hewlett-Packard's SureStore 6000eU and 6000i tape drives and C1533A DDS-2 DAT drive. The drive has a block of 8 dip switches. The proper settings for FreeBSD are: 1 ON; 2 ON; 3 OFF; 4 ON; 5 ON; 6 ON; 7 ON; 8 ON. switch 1 switch 2 Result On On Compression enabled at power-on, with host control On Off Compression enabled at power-on, no host control Off On Compression disabled at power-on, with host control Off Off Compression disabled at power-on, no host control Switch 3 controls MRS (Media Recognition System). MRS tapes have stripes on the transparent leader. These identify the tape as DDS (Digital Data Storage) grade media. Tapes that do not have the stripes will be treated as write-protected. Switch 3 OFF enables MRS. Switch 3 ON disables MRS. See HP SureStore Tape Products and Hewlett-Packard Disk and Tape Technical Information for more information on configuring this drive. Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 2 of these drives. Neither lasted more than 5 months. Reported by: &a.se; Hewlett-Packard HP 1534A The boot message identifier for this drive is HP HP35470A T503 type 1 removable SCSI 2 Sequential-Access density code 0x13, variable blocks. This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. Data transfer rate is 183kB/s. The same mechanism is used in Hewlett-Packard's SureStore 2000i tape drive, C35470A DDS format DAT drive, C1534A DDS format DAT drive and HP C1536A DDS format DAT drive. The HP C1534A DDS format DAT drive has two indicator lights, one green and one amber. The green one indicates tape action: slow flash during load, steady when loaded, fast flash during read/write operations. The amber one indicates warnings: slow flash when cleaning is required or tape is nearing the end of its useful life, steady indicates an hard fault. (factory service required?) Reported by Gary Crutcher gcrutchr@nightflight.com Hewlett-Packard HP C1553A Autoloading DDS2 The boot message identifier for this drive is "". This is a DDS-2 tape drive with a tape changer. DDS-2 means hardware data compression and narrower tracks for increased data capacity. Native capacity is 24GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is 510kB/s (native). This drive is used in Hewlett-Packard's SureStore 12000e tape drive. The drive has two selectors on the rear panel. The selector closer to the fan is SCSI id. The other selector should be set to 7. There are four internal switches. These should be set: 1 ON; 2 ON; 3 ON; 4 OFF. At present the kernel drivers do not automatically change tapes at the end of a volume. This shell script can be used to change tapes: #!/bin/sh PATH="/sbin:/usr/sbin:/bin:/usr/bin"; export PATH usage() { echo "Usage: dds_changer [123456ne] raw-device-name echo "1..6 = Select cartridge" echo "next cartridge" echo "eject magazine" exit 2 } if [ $# -ne 2 ] ; then usage fi cdb3=0 cdb4=0 cdb5=0 case $1 in [123456]) cdb3=$1 cdb4=1 ;; n) ;; e) cdb5=0x80 ;; ?) usage ;; esac scsi -f $2 -s 100 -c "1b 0 0 $cdb3 $cdb4 $cdb5" Hewlett-Packard HP 35450A The boot message identifier for this drive is HP HP35450A -A C620 type 1 removable SCSI 2 Sequential-Access density code 0x13 This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 1.2GB. Data transfer rate is 160kB/s. Reported by: Mark Thompson mark.a.thompson@pobox.com Hewlett-Packard HP 35470A The boot message identifier for this drive is HP HP35470A 9 09 type 1 removable SCSI 2 This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. Data transfer rate is 183kB/s. The same mechanism is used in Hewlett-Packard's SureStore 2000i tape drive, C35470A DDS format DAT drive, C1534A DDS format DAT drive, and HP C1536A DDS format DAT drive. Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 5 of these drives. None lasted more than 9 months. Reported by: David Dawes dawes@rf900.physics.usyd.edu.au (9 09) Hewlett-Packard HP 35480A The boot message identifier for this drive is HP HP35480A 1009 type 1 removable SCSI 2 Sequential-Access density code 0x13. This is a DDS-DC tape drive. DDS-DC is DDS-1 with hardware data compression. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. It cannot handle 120m tapes. This drive supports hardware data compression. Please refer to the section on HP C1533A for the proper switch settings. Data transfer rate is 183kB/s. This drive is used in Hewlett-Packard's SureStore 5000eU and 5000i tape drives and C35480A DDS format DAT drive.. This drive will occasionally hang during a tape eject operation (mt offline). Pressing the front panel button will eject the tape and bring the tape drive back to life. WARNING: HP 35480-03110 only. On at least two occasions this tape drive when used with FreeBSD 2.1.0, an IBM Server 320 and an 2940W SCSI controller resulted in all SCSI disk partitions being lost. The problem has not be analyzed or resolved at this time. <ulink url="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink> There are at least two significantly different models: one is a DDS-1 and the other DDS-2. The DDS-1 version is SDT-5000 3.02. The DDS-2 version is SONY SDT-5000 327M. The DDS-2 version has a 1MB cache. This cache is able to keep the tape streaming in almost any circumstances. The boot message identifier for this drive is SONY SDT-5000 3.02 type 1 removable SCSI 2 Sequential-Access density code 0x13 Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is depends upon the model or the drive. The rate is 630kB/s for the SONY SDT-5000 327M while compressing the data. For the SONY SDT-5000 3.02, the data transfer rate is 225kB/s. In order to get this drive to stream, set the blocksize to 512 bytes (mt blocksize 512) reported by Kenneth Merry ken@ulc199.residence.gatech.edu. SONY SDT-5000 327M information reported by Charles Henrich henrich@msu.edu. Reported by: &a.jmz; Tandberg TDC 3600 The boot message identifier for this drive is TANDBERG TDC 3600 =08: type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 150/250MB. This drive has quirks which are known and work around code is present in the scsi tape device driver (&man.st.4;). Upgrading the firmware to XXX version will fix the quirks and provide SCSI 2 capabilities. Data transfer rate is 80kB/s. IBM and Emerald units will not work. Replacing the firmware EPROM of these units will solve the problem. Reported by: &a.msmith; Tandberg TDC 3620 This is very similar to the Tandberg TDC 3600 drive. Reported by: &a.joerg; Tandberg TDC 3800 The boot message identifier for this drive is TANDBERG TDC 3800 =04Y Removable Sequential Access SCSI-2 device This is a QIC tape drive. Native capacity is 525MB. Reported by: &a.jhs; Tandberg TDC 4222 The boot message identifier for this drive is TANDBERG TDC 4222 =07 type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 2.5GB. The drive will read all cartridges from the 60 MB (DC600A) upwards, and write 150 MB (DC6150) upwards. Hardware compression is optionally supported for the 2.5 GB cartridges. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;) beginning with FreeBSD 2.2-CURRENT. For previous versions of FreeBSD, use mt to read one block from the tape, rewind the tape, and then execute the backup program (mt fsr 1; mt rewind; dump ...) Data transfer rate is 600kB/s (vendor claim with compression), 350 KB/s can even be reached in start/stop mode. The rate decreases for smaller cartridges. Reported by: &a.joerg; Wangtek 5525ES The boot message identifier for this drive is WANGTEK 5525ES SCSI REV7 3R1 type 1 removable SCSI 1 density code 0x11, 1024-byte blocks This is a QIC tape drive. Native capacity is 525MB. Data transfer rate is 180kB/s. The drive reads 60, 120, 150, and 525MB tapes. The drive will not write 60MB (DC600 cartridge) tapes. In order to overwrite 120 and 150 tapes reliably, first erase (mt erase) the tape. 120 and 150 tapes used a wider track (fewer tracks per tape) than 525MB tapes. The extra width of the previous tracks is not overwritten, as a result the new data lies in a band surrounded on both sides by the previous data unless the tape have been erased. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;). Other firmware revisions that are known to work are: M75D Reported by: Marc van Kempen marc@bowtie.nl REV73R1 Andrew Gordon Andrew.Gordon@net-tel.co.uk M75D Wangtek 6200 The boot message identifier for this drive is WANGTEK 6200-HS 4B18 type 1 removable SCSI 2 Sequential-Access density code 0x13 This is a DDS-1 tape drive. Native capacity is 2GB using 90m tapes. Data transfer rate is 150kB/s. Reported by: Tony Kimball alk@Think.COM * Problem drives CDROM drives Contributed by &a.obrien;. 23 November 1997. Generally speaking those in The FreeBSD Project prefer SCSI CDROM drives over IDE CDROM drives. However not all SCSI CDROM drives are equal. Some feel the quality of some SCSI CDROM drives have been deteriorating to that of IDE CDROM drives. Toshiba used to be the favored stand-by, but many on the SCSI mailing list have found displeasure with the 12x speed XM-5701TA as its volume (when playing audio CDROMs) is not controllable by the various audio player software. Another area where SCSI CDROM manufacturers are cutting corners is adherence to the SCSI specification. Many SCSI CDROMs will respond to multiple LUNs for its target address. Known violators include the 6x Teac CD-56S 1.0D.
diff --git a/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.sgml index 27f0757ff0..cbf55c798d 100644 --- a/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.sgml +++ b/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.sgml @@ -1,1585 +1,1585 @@ IPv6 Internals IPv6/IPsec Implementation Contributed by &a.shin;, 5 March 2000. This section should explain IPv6 and IPsec related implementation internals. These functionalities are derived from KAME project IPv6 Conformance The IPv6 related functions conforms, or tries to conform to the latest set of IPv6 specifications. For future reference we list some of the relevant documents below (NOTE: this is not a complete list - this is too hard to maintain...). For details please refer to specific chapter in the document, RFCs, manual pages, or comments in the source code. Conformance tests have been performed on the KAME STABLE kit - at TAHI project. Results can be viewed at http://www.tahi.org/report/KAME/ - . We also attended Univ. of New Hampshire IOL tests (http://www.iol.unh.edu/) in the + at TAHI project. Results can be viewed at + . + We also attended Univ. of New Hampshire IOL tests + () in the past, with our past snapshots. RFC1639: FTP Operation Over Big Address Records (FOOBAR) RFC2428 is preferred over RFC1639. FTP clients will first try RFC2428, then RFC1639 if failed. RFC1886: DNS Extensions to support IPv6 RFC1933: Transition Mechanisms for IPv6 Hosts and Routers IPv4 compatible address is not supported. automatic tunneling (described in 4.3 of this RFC) is not supported. &man.gif.4; interface implements IPv[46]-over-IPv[46] tunnel in a generic way, and it covers "configured tunnel" described in the spec. See 23.5.1.5 in this document for details. RFC1981: Path MTU Discovery for IPv6 RFC2080: RIPng for IPv6 usr.sbin/route6d support this. RFC2292: Advanced Sockets API for IPv6 For supported library functions/kernel APIs, see sys/netinet6/ADVAPI. RFC2362: Protocol Independent Multicast-Sparse Mode (PIM-SM) RFC2362 defines packet formats for PIM-SM. draft-ietf-pim-ipv6-01.txt is written based on this. RFC2373: IPv6 Addressing Architecture supports node required addresses, and conforms to the scope requirement. RFC2374: An IPv6 Aggregatable Global Unicast Address Format supports 64-bit length of Interface ID. RFC2375: IPv6 Multicast Address Assignments Userland applications use the well-known addresses assigned in the RFC. RFC2428: FTP Extensions for IPv6 and NATs RFC2428 is preferred over RFC1639. FTP clients will first try RFC2428, then RFC1639 if failed. RFC2460: IPv6 specification RFC2461: Neighbor discovery for IPv6 See 23.5.1.2 in this document for details. RFC2462: IPv6 Stateless Address Autoconfiguration See 23.5.1.4 in this document for details. RFC2463: ICMPv6 for IPv6 specification See 23.5.1.9 in this document for details. RFC2464: Transmission of IPv6 Packets over Ethernet Networks RFC2465: MIB for IPv6: Textual Conventions and General Group Necessary statistics are gathered by the kernel. Actual IPv6 MIB support is provided as a patchkit for ucd-snmp. RFC2466: MIB for IPv6: ICMPv6 group Necessary statistics are gathered by the kernel. Actual IPv6 MIB support is provided as patchkit for ucd-snmp. RFC2467: Transmission of IPv6 Packets over FDDI Networks RFC2497: Transmission of IPv6 packet over ARCnet Networks RFC2553: Basic Socket Interface Extensions for IPv6 IPv4 mapped address (3.7) and special behavior of IPv6 wildcard bind socket (3.8) are supported. See 23.5.1.12 in this document for details. RFC2675: IPv6 Jumbograms See 23.5.1.7 in this document for details. RFC2710: Multicast Listener Discovery for IPv6 RFC2711: IPv6 router alert option draft-ietf-ipngwg-router-renum-08: Router renumbering for IPv6 draft-ietf-ipngwg-icmp-namelookups-02: IPv6 Name Lookups Through ICMP draft-ietf-ipngwg-icmp-name-lookups-03: IPv6 Name Lookups Through ICMP draft-ietf-pim-ipv6-01.txt: PIM for IPv6 &man.pim6dd.8; implements dense mode. &man.pim6sd.8; implements sparse mode. draft-itojun-ipv6-tcp-to-anycast-00: Disconnecting TCP connection toward IPv6 anycast address draft-yamamoto-wideipv6-comm-model-00 See 23.5.1.6 in this document for details. draft-ietf-ipngwg-scopedaddr-format-00.txt : An Extension of Format for IPv6 Scoped Addresses Neighbor Discovery Neighbor Discovery is fairly stable. Currently Address Resolution, Duplicated Address Detection, and Neighbor Unreachability Detection are supported. In the near future we will be adding Proxy Neighbor Advertisement support in the kernel and Unsolicited Neighbor Advertisement transmission command as admin tool. If DAD fails, the address will be marked "duplicated" and message will be generated to syslog (and usually to console). The "duplicated" mark can be checked with &man.ifconfig.8;. It is administrators' responsibility to check for and recover from DAD failures. The behavior should be improved in the near future. Some of the network driver loops multicast packets back to itself, even if instructed not to do so (especially in promiscuous mode). In such cases DAD may fail, because DAD engine sees inbound NS packet (actually from the node itself) and considers it as a sign of duplicate. You may want to look at #if condition marked "heuristics" in sys/netinet6/nd6_nbr.c:nd6_dad_timer() as workaround (note that the code fragment in "heuristics" section is not spec conformant). Neighbor Discovery specification (RFC2461) does not talk about neighbor cache handling in the following cases: when there was no neighbor cache entry, node received unsolicited RS/NS/NA/redirect packet without link-layer address neighbor cache handling on medium without link-layer address (we need a neighbor cache entry for IsRouter bit) For first case, we implemented workaround based on discussions on IETF ipngwg mailing list. For more details, see the comments in the source code and email thread started from (IPng 7155), dated Feb 6 1999. IPv6 on-link determination rule (RFC2461) is quite different from assumptions in BSD network code. At this moment, no on-link determination rule is supported where default router list is empty (RFC2461, section 5.2, last sentence in 2nd paragraph - note that the spec misuse the word "host" and "node" in several places in the section). To avoid possible DoS attacks and infinite loops, only 10 options on ND packet is accepted now. Therefore, if you have 20 prefix options attached to RA, only the first 10 prefixes will be recognized. If this troubles you, please ask it on FREEBSD-CURRENT mailing list and/or modify nd6_maxndopt in sys/netinet6/nd6.c. If there are high demands we may provide sysctl knob for the variable. Scope Index IPv6 uses scoped addresses. Therefore, it is very important to specify scope index (interface index for link-local address, or site index for site-local address) with an IPv6 address. Without scope index, scoped IPv6 address is ambiguous to the kernel, and kernel will not be able to determine the outbound interface for a packet. Ordinary userland applications should use advanced API (RFC2292) to specify scope index, or interface index. For similar purpose, sin6_scope_id member in sockaddr_in6 structure is defined in RFC2553. However, the semantics for sin6_scope_id is rather vague. If you care about portability of your application, we suggest you to use advanced API rather than sin6_scope_id. In the kernel, an interface index for link-local scoped address is embedded into 2nd 16bit-word (3rd and 4th byte) in IPv6 address. For example, you may see something like: fe80:1::200:f8ff:fe01:6317 in the routing table and interface address structure (struct in6_ifaddr). The address above is a link-local unicast address which belongs to a network interface whose interface identifier is 1. The embedded index enables us to identify IPv6 link local addresses over multiple interfaces effectively and with only a little code change. Routing daemons and configuration programs, like &man.route6d.8; and &man.ifconfig.8;, will need to manipulate the "embedded" scope index. These programs use routing sockets and ioctls (like SIOCGIFADDR_IN6) and the kernel API will return IPv6 addresses with 2nd 16bit-word filled in. The APIs are for manipulating kernel internal structure. Programs that use these APIs have to be prepared about differences in kernels anyway. When you specify scoped address to the command line, NEVER write the embedded form (such as ff02:1::1 or fe80:2::fedc). This is not supposed to work. Always use standard form, like ff02::1 or fe80::fedc, with command line option for specifying interface (like ping6 -I ne0 ff02::1). In general, if a command does not have command line option to specify outgoing interface, that command is not ready to accept scoped address. This may seem to be opposite from IPv6's premise to support "dentist office" situation. We believe that specifications need some improvements for this. Some of the userland tools support extended numeric IPv6 syntax, as documented in draft-ietf-ipngwg-scopedaddr-format-00.txt. You can specify outgoing link, by using name of the outgoing interface like "fe80::1%ne0". This way you will be able to specify link-local scoped address without much trouble. To use this extension in your program, you will need to use &man.getaddrinfo.3;, and &man.getnameinfo.3; with NI_WITHSCOPEID. The implementation currently assumes 1-to-1 relationship between a link and an interface, which is stronger than what specs say. Plug and Play Most of the IPv6 stateless address autoconfiguration is implemented in the kernel. Neighbor Discovery functions are implemented in the kernel as a whole. Router Advertisement (RA) input for hosts is implemented in the kernel. Router Solicitation (RS) output for endhosts, RS input for routers, and RA output for routers are implemented in the userland. Assignment of link-local, and special addresses IPv6 link-local address is generated from IEEE802 address (Ethernet MAC address). Each of interface is assigned an IPv6 link-local address automatically, when the interface becomes up (IFF_UP). Also, direct route for the link-local address is added to routing table. Here is an output of netstat command: Internet6: Destination Gateway Flags Netif Expire fe80:1::%ed0/64 link#1 UC ed0 fe80:2::%ep0/64 link#2 UC ep0 Interfaces that has no IEEE802 address (pseudo interfaces like tunnel interfaces, or ppp interfaces) will borrow IEEE802 address from other interfaces, such as Ethernet interfaces, whenever possible. If there is no IEEE802 hardware attached, last-resort pseudorandom value, which is from MD5(hostname), will be used as source of link-local address. If it is not suitable for your usage, you will need to configure the link-local address manually. If an interface is not capable of handling IPv6 (such as lack of multicast support), link-local address will not be assigned to that interface. See section 2 for details. Each interface joins the solicited multicast address and the link-local all-nodes multicast addresses (e.g. fe80::1:ff01:6317 and ff02::1, respectively, on the link the interface is attached). In addition to a link-local address, the loopback address (::1) will be assigned to the loopback interface. Also, ::1/128 and ff01::/32 are automatically added to routing table, and loopback interface joins node-local multicast group ff01::1. Stateless address autoconfiguration on hosts In IPv6 specification, nodes are separated into two categories: routers and hosts. Routers forward packets addressed to others, hosts does not forward the packets. net.inet6.ip6.forwarding defines whether this node is router or host (router if it is 1, host if it is 0). When a host hears Router Advertisement from the router, a host may autoconfigure itself by stateless address autoconfiguration. This behavior can be controlled by net.inet6.ip6.accept_rtadv (host autoconfigures itself if it is set to 1). By autoconfiguration, network address prefix for the receiving interface (usually global address prefix) is added. Default route is also configured. Routers periodically generate Router Advertisement packets. To request an adjacent router to generate RA packet, a host can transmit Router Solicitation. To generate a RS packet at any time, use the rtsol command. &man.rtsold.8; daemon is also available. &man.rtsold.8; generates Router Solicitation whenever necessary, and it works great for nomadic usage (notebooks/laptops). If one wishes to ignore Router Advertisements, use sysctl to set net.inet6.ip6.accept_rtadv to 0. To generate Router Advertisement from a router, use the &man.rtadvd.8; daemon. Note that, IPv6 specification assumes the following items, and nonconforming cases are left unspecified: Only hosts will listen to router advertisements Hosts have single network interface (except loopback) Therefore, this is unwise to enable net.inet6.ip6.accept_rtadv on routers, or multi-interface host. A misconfigured node can behave strange (nonconforming configuration allowed for those who would like to do some experiments). To summarize the sysctl knob: accept_rtadv forwarding role of the node --- --- --- 0 0 host (to be manually configured) 0 1 router 1 0 autoconfigured host (spec assumes that host has single interface only, autoconfigured host with multiple interface is out-of-scope) 1 1 invalid, or experimental (out-of-scope of spec) RFC2462 has validation rule against incoming RA prefix information option, in 5.5.3 (e). This is to protect hosts from malicious (or misconfigured) routers that advertise very short prefix lifetime. There was an update from Jim Bound to ipngwg mailing list (look for "(ipng 6712)" in the archive) and it is implemented Jim's update. See 23.5.1.2 in the document for relationship between DAD and autoconfiguration. Generic tunnel interface GIF (Generic InterFace) is a pseudo interface for configured tunnel. Details are described in &man.gif.4;. Currently v6 in v6 v6 in v4 v4 in v6 v4 in v4 are available. Use &man.gifconfig.8; to assign physical (outer) source and destination address to gif interfaces. Configuration that uses same address family for inner and outer IP header (v4 in v4, or v6 in v6) is dangerous. It is very easy to configure interfaces and routing tables to perform infinite level of tunneling. Please be warned. gif can be configured to be ECN-friendly. See 23.5.4.5 for ECN-friendliness of tunnels, and &man.gif.4; for how to configure. If you would like to configure an IPv4-in-IPv6 tunnel with gif interface, read &man.gif.4; carefully. You will need to remove IPv6 link-local address automatically assigned to the gif interface. Source Address Selection Current source selection rule is scope oriented (there are some exceptions - see below). For a given destination, a source IPv6 address is selected by the following rule: If the source address is explicitly specified by the user (e.g. via the advanced API), the specified address is used. If there is an address assigned to the outgoing interface (which is usually determined by looking up the routing table) that has the same scope as the destination address, the address is used. This is the most typical case. If there is no address that satisfies the above condition, choose a global address assigned to one of the interfaces on the sending node. If there is no address that satisfies the above condition, and destination address is site local scope, choose a site local address assigned to one of the interfaces on the sending node. If there is no address that satisfies the above condition, choose the address associated with the routing table entry for the destination. This is the last resort, which may cause scope violation. For instance, ::1 is selected for ff01::1, fe80:1::200:f8ff:fe01:6317 for fe80:1::2a0:24ff:feab:839b (note that embedded interface index - described in 23.5.1.3 - helps us choose the right source address. Those embedded indices will not be on the wire). If the outgoing interface has multiple address for the scope, a source is selected longest match basis (rule 3). Suppose 3ffe:501:808:1:200:f8ff:fe01:6317 and 3ffe:2001:9:124:200:f8ff:fe01:6317 are given to the outgoing interface. 3ffe:501:808:1:200:f8ff:fe01:6317 is chosen as the source for the destination 3ffe:501:800::1. Note that the above rule is not documented in the IPv6 spec. It is considered "up to implementation" item. There are some cases where we do not use the above rule. One example is connected TCP session, and we use the address kept in tcb as the source. Another example is source address for Neighbor Advertisement. Under the spec (RFC2461 7.2.2) NA's source should be the target address of the corresponding NS's target. In this case we follow the spec rather than the above longest-match rule. For new connections (when rule 1 does not apply), deprecated addresses (addresses with preferred lifetime = 0) will not be chosen as source address if other choices are available. If no other choices are available, deprecated address will be used as a last resort. If there are multiple choice of deprecated addresses, the above scope rule will be used to choose from those deprecated addresses. If you would like to prohibit the use of deprecated address for some reason, configure net.inet6.ip6.use_deprecated to 0. The issue related to deprecated address is described in RFC2462 5.5.4 (NOTE: there is some debate underway in IETF ipngwg on how to use "deprecated" address). Jumbo Payload The Jumbo Payload hop-by-hop option is implemented and can be used to send IPv6 packets with payloads longer than 65,535 octets. But currently no physical interface whose MTU is more than 65,535 is supported, so such payloads can be seen only on the loopback interface (i.e. lo0). If you want to try jumbo payloads, you first have to reconfigure the kernel so that the MTU of the loopback interface is more than 65,535 bytes; add the following to the kernel configuration file: options "LARGE_LOMTU" #To test jumbo payload and recompile the new kernel. Then you can test jumbo payloads by the &man.ping6.8; command with -b and -s options. The -b option must be specified to enlarge the size of the socket buffer and the -s option specifies the length of the packet, which should be more than 65,535. For example, type as follows: &prompt.user; ping6 -b 70000 -s 68000 ::1 The IPv6 specification requires that the Jumbo Payload option must not be used in a packet that carries a fragment header. If this condition is broken, an ICMPv6 Parameter Problem message must be sent to the sender. specification is followed, but you cannot usually see an ICMPv6 error caused by this requirement. When an IPv6 packet is received, the frame length is checked and compared to the length specified in the payload length field of the IPv6 header or in the value of the Jumbo Payload option, if any. If the former is shorter than the latter, the packet is discarded and statistics are incremented. You can see the statistics as output of &man.netstat.8; command with `-s -p ip6' option: &prompt.user; netstat -s -p ip6 ip6: (snip) 1 with data size < data length So, kernel does not send an ICMPv6 error unless the erroneous packet is an actual Jumbo Payload, that is, its packet size is more than 65,535 bytes. As described above, currently no physical interface with such a huge MTU is supported, so it rarely returns an ICMPv6 error. TCP/UDP over jumbogram is not supported at this moment. This is because we have no medium (other than loopback) to test this. Contact us if you need this. IPsec does not work on jumbograms. This is due to some specification twists in supporting AH with jumbograms (AH header size influences payload length, and this makes it real hard to authenticate inbound packet with jumbo payload option as well as AH). There are fundamental issues in *BSD support for jumbograms. We would like to address those, but we need more time to finalize these. To name a few: mbuf pkthdr.len field is typed as "int" in 4.4BSD, so it will not hold jumbogram with len > 2G on 32bit architecture CPUs. If we would like to support jumbogram properly, the field must be expanded to hold 4G + IPv6 header + link-layer header. Therefore, it must be expanded to at least int64_t (u_int32_t is NOT enough). We mistakingly use "int" to hold packet length in many places. We need to convert them into larger integral type. It needs a great care, as we may experience overflow during packet length computation. We mistakingly check for ip6_plen field of IPv6 header for packet payload length in various places. We should be checking mbuf pkthdr.len instead. ip6_input() will perform sanity check on jumbo payload option on input, and we can safely use mbuf pkthdr.len afterwards. TCP code needs a careful update in bunch of places, of course. Loop prevention in header processing IPv6 specification allows arbitrary number of extension headers to be placed onto packets. If we implement IPv6 packet processing code in the way BSD IPv4 code is implemented, kernel stack may overflow due to long function call chain. sys/netinet6 code is carefully designed to avoid kernel stack overflow. Because of this, sys/netinet6 code defines its own protocol switch structure, as "struct ip6protosw" (see netinet6/ip6protosw.h). There is no such update to IPv4 part (sys/netinet) for compatibility, but small change is added to its pr_input() prototype. So "struct ipprotosw" is also defined. Because of this, if you receive IPsec-over-IPv4 packet with massive number of IPsec headers, kernel stack may blow up. IPsec-over-IPv6 is okay. (Off-course, for those all IPsec headers to be processed, each such IPsec header must pass each IPsec check. So an anonymous attacker will not be able to do such an attack.) ICMPv6 After RFC2463 was published, IETF ipngwg has decided to disallow ICMPv6 error packet against ICMPv6 redirect, to prevent ICMPv6 storm on a network medium. This is already implemented into the kernel. Applications For userland programming, we support IPv6 socket API as specified in RFC2553, RFC2292 and upcoming Internet drafts. TCP/UDP over IPv6 is available and quite stable. You can enjoy &man.telnet.1;, &man.ftp.1;, &man.rlogin.1;, &man.rsh.1;, &man.ssh.1;, etc. These applications are protocol independent. That is, they automatically chooses IPv4 or IPv6 according to DNS. Kernel Internals While ip_forward() calls ip_output(), ip6_forward() directly calls if_output() since routers must not divide IPv6 packets into fragments. ICMPv6 should contain the original packet as long as possible up to 1280. UDP6/IP6 port unreach, for instance, should contain all extension headers and the *unchanged* UDP6 and IP6 headers. So, all IP6 functions except TCP never convert network byte order into host byte order, to save the original packet. tcp_input(), udp6_input() and icmp6_input() can not assume that IP6 header is preceding the transport headers due to extension headers. So, in6_cksum() was implemented to handle packets whose IP6 header and transport header is not continuous. TCP/IP6 nor UDP6/IP6 header structures do not exist for checksum calculation. To process IP6 header, extension headers and transport headers easily, network drivers are now required to store packets in one internal mbuf or one or more external mbufs. A typical old driver prepares two internal mbufs for 96 - 204 bytes data, however, now such packet data is stored in one external mbuf. netstat -s -p ip6 tells you whether or not your driver conforms such requirement. In the following example, "cce0" violates the requirement. (For more information, refer to Section 2.) Mbuf statistics: 317 one mbuf two or more mbuf:: lo0 = 8 cce0 = 10 3282 one ext mbuf 0 two or more ext mbuf Each input function calls IP6_EXTHDR_CHECK in the beginning to check if the region between IP6 and its header is continuous. IP6_EXTHDR_CHECK calls m_pullup() only if the mbuf has M_LOOP flag, that is, the packet comes from the loopback interface. m_pullup() is never called for packets coming from physical network interfaces. Both IP and IP6 reassemble functions never call m_pullup(). IPv4 mapped address and IPv6 wildcard socket RFC2553 describes IPv4 mapped address (3.7) and special behavior of IPv6 wildcard bind socket (3.8). The spec allows you to: Accept IPv4 connections by AF_INET6 wildcard bind socket. Transmit IPv4 packet over AF_INET6 socket by using special form of the address like ::ffff:10.1.1.1. but the spec itself is very complicated and does not specify how the socket layer should behave. Here we call the former one "listening side" and the latter one "initiating side", for reference purposes. You can perform wildcard bind on both of the address families, on the same port. The following table show the behavior of FreeBSD 4.x. listening side initiating side (AF_INET6 wildcard (connection to ::ffff:10.1.1.1) socket gets IPv4 conn.) --- --- FreeBSD 4.x configurable supported default: enabled The following sections will give you more details, and how you can configure the behavior. Comments on listening side: It looks that RFC2553 talks too little on wildcard bind issue, especially on the port space issue, failure mode and relationship between AF_INET/INET6 wildcard bind. There can be several separate interpretation for this RFC which conform to it but behaves differently. So, to implement portable application you should assume nothing about the behavior in the kernel. Using &man.getaddrinfo.3; is the safest way. Port number space and wildcard bind issues were discussed in detail on ipv6imp mailing list, in mid March 1999 and it looks that there is no concrete consensus (means, up to implementers). You may want to check the mailing list archives. If a server application would like to accept IPv4 and IPv6 connections, there will be two alternatives. One is using AF_INET and AF_INET6 socket (you will need two sockets). Use &man.getaddrinfo.3; with AI_PASSIVE into ai_flags, and &man.socket.2; and &man.bind.2; to all the addresses returned. By opening multiple sockets, you can accept connections onto the socket with proper address family. IPv4 connections will be accepted by AF_INET socket, and IPv6 connections will be accepted by AF_INET6 socket. Another way is using one AF_INET6 wildcard bind socket. Use &man.getaddrinfo.3; with AI_PASSIVE into ai_flags and with AF_INET6 into ai_family, and set the 1st argument hostname to NULL. And &man.socket.2; and &man.bind.2; to the address returned. (should be IPv6 unspecified addr). You can accept either of IPv4 and IPv6 packet via this one socket. To support only IPv6 traffic on AF_INET6 wildcard binded socket portably, always check the peer address when a connection is made toward AF_INET6 listening socket. If the address is IPv4 mapped address, you may want to reject the connection. You can check the condition by using IN6_IS_ADDR_V4MAPPED() macro. To resolve this issue more easily, there is system dependent &man.setsockopt.2; option, IPV6_BINDV6ONLY, used like below. int on; setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, (char *)&on, sizeof (on)) < 0)); When this call succeed, then this socket only receive IPv6 packets. Comments on initiating side: Advise to application implementers: to implement a portable IPv6 application (which works on multiple IPv6 kernels), we believe that the following is the key to the success: NEVER hardcode AF_INET nor AF_INET6. Use &man.getaddrinfo.3; and &man.getnameinfo.3; throughout the system. Never use gethostby*(), getaddrby*(), inet_*() or getipnodeby*(). (To update existing applications to be IPv6 aware easily, sometime getipnodeby*() will be useful. But if possible, try to rewrite the code to use &man.getaddrinfo.3; and &man.getnameinfo.3;.) If you would like to connect to destination, use &man.getaddrinfo.3; and try all the destination returned, like &man.telnet.1; does. Some of the IPv6 stack is shipped with buggy &man.getaddrinfo.3;. Ship a minimal working version with your application and use that as last resort. If you would like to use AF_INET6 socket for both IPv4 and IPv6 outgoing connection, you will need to use &man.getipnodebyname.3;. When you would like to update your existing application to be IPv6 aware with minimal effort, this approach might be chosen. But please note that it is a temporal solution, because &man.getipnodebyname.3; itself is not recommended as it does not handle scoped IPv6 addresses at all. For IPv6 name resolution, &man.getaddrinfo.3; is the preferred API. So you should rewrite your application to use &man.getaddrinfo.3;, when you get the time to do it. When writing applications that make outgoing connections, story goes much simpler if you treat AF_INET and AF_INET6 as totally separate address family. {set,get}sockopt issue goes simpler, DNS issue will be made simpler. We do not recommend you to rely upon IPv4 mapped address. unified tcp and inpcb code FreeBSD 4.x uses shared tcp code between IPv4 and IPv6 (from sys/netinet/tcp*) and separate udp4/6 code. It uses unified inpcb structure. The platform can be configured to support IPv4 mapped address. Kernel configuration is summarized as follows: By default, AF_INET6 socket will grab IPv4 connections in certain condition, and can initiate connection to IPv4 destination embedded in IPv4 mapped IPv6 address. You can disable it on entire system with sysctl like below. sysctl net.inet6.ip6.mapped_addr=0 listening side Each socket can be configured to support special AF_INET6 wildcard bind (enabled by default). You can disable it on each socket basis with &man.setsockopt.2; like below. int on; setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, (char *)&on, sizeof (on)) < 0)); Wildcard AF_INET6 socket grabs IPv4 connection if and only if the following conditions are satisfied: there is no AF_INET socket that matches the IPv4 connection the AF_INET6 socket is configured to accept IPv4 traffic, i.e. getsockopt(IPV6_BINDV6ONLY) returns 0. There is no problem with open/close ordering. initiating side FreeBSD 4.x supports outgoing connection to IPv4 mapped address (::ffff:10.1.1.1), if the node is configured to support IPv4 mapped address. sockaddr_storage When RFC2553 was about to be finalized, there was discussion on how struct sockaddr_storage members are named. One proposal is to prepend "__" to the members (like "__ss_len") as they should not be touched. The other proposal was not to prepend it (like "ss_len") as we need to touch those members directly. There was no clear consensus on it. As a result, RFC2553 defines struct sockaddr_storage as follows: struct sockaddr_storage { u_char __ss_len; /* address length */ u_char __ss_family; /* address family */ /* and bunch of padding */ }; On the contrary, XNET draft defines as follows: struct sockaddr_storage { u_char ss_len; /* address length */ u_char ss_family; /* address family */ /* and bunch of padding */ }; In December 1999, it was agreed that RFC2553bis should pick the latter (XNET) definition. Current implementation conforms to XNET definition, based on RFC2553bis discussion. If you look at multiple IPv6 implementations, you will be able to see both definitions. As an userland programmer, the most portable way of dealing with it is to: ensure ss_family and/or ss_len are available on the platform, by using GNU autoconf, have -Dss_family=__ss_family to unify all occurrences (including header file) into __ss_family, or never touch __ss_family. cast to sockaddr * and use sa_family like: struct sockaddr_storage ss; family = ((struct sockaddr *)&ss)->sa_family Network Drivers Now following two items are required to be supported by standard drivers: mbuf clustering requirement. In this stable release, we changed MINCLSIZE into MHLEN+1 for all the operating systems in order to make all the drivers behave as we expect. multicast. If &man.ifmcstat.8; yields no multicast group for a interface, that interface has to be patched. If any of the drivers do not support the requirements, then the drivers can not be used for IPv6 and/or IPsec communication. If you find any problem with your card using IPv6/IPsec, then, please report it to the &a.bugs;. (NOTE: In the past we required all PCMCIA drivers to have a call to in6_ifattach(). We have no such requirement any more) Translator We categorize IPv4/IPv6 translator into 4 types: Translator A --- It is used in the early stage of transition to make it possible to establish a connection from an IPv6 host in an IPv6 island to an IPv4 host in the IPv4 ocean. Translator B --- It is used in the early stage of transition to make it possible to establish a connection from an IPv4 host in the IPv4 ocean to an IPv6 host in an IPv6 island. Translator C --- It is used in the late stage of transition to make it possible to establish a connection from an IPv4 host in an IPv4 island to an IPv6 host in the IPv6 ocean. Translator D --- It is used in the late stage of transition to make it possible to establish a connection from an IPv6 host in the IPv6 ocean to an IPv4 host in an IPv4 island. TCP relay translator for category A is supported. This is called "FAITH". We also provide IP header translator for category A. (The latter is not yet put into FreeBSD 4.x yet.) FAITH TCP relay translator FAITH system uses TCP relay daemon called &man.faithd.8; helped by the kernel. FAITH will reserve an IPv6 address prefix, and relay TCP connection toward that prefix to IPv4 destination. For example, if the reserved IPv6 prefix is 3ffe:0501:0200:ffff::, and the IPv6 destination for TCP connection is 3ffe:0501:0200:ffff::163.221.202.12, the connection will be relayed toward IPv4 destination 163.221.202.12. destination IPv4 node (163.221.202.12) ^ | IPv4 tcp toward 163.221.202.12 FAITH-relay dual stack node ^ | IPv6 TCP toward 3ffe:0501:0200:ffff::163.221.202.12 source IPv6 node &man.faithd.8; must be invoked on FAITH-relay dual stack node. For more details, consult src/usr.sbin/faithd/README IPsec IPsec is mainly organized by three components. Policy Management Key Management AH and ESP handling Policy Management The kernel implements experimental policy management code. There are two way to manage security policy. One is to configure per-socket policy using &man.setsockopt.2;. In this cases, policy configuration is described in &man.ipsec.set.policy.3;. The other is to configure kernel packet filter-based policy using PF_KEY interface, via &man.setkey.8;. The policy entry is not re-ordered with its indexes, so the order of entry when you add is very significant. Key Management The key management code implemented in this kit (sys/netkey) is a home-brew PFKEY v2 implementation. This conforms to RFC2367. The home-brew IKE daemon, "racoon" is included in the kit (kame/kame/racoon). Basically you will need to run racoon as daemon, then setup a policy to require keys (like ping -P 'out ipsec esp/transport//use'). The kernel will contact racoon daemon as necessary to exchange keys. AH and ESP handling IPsec module is implemented as "hooks" to the standard IPv4/IPv6 processing. When sending a packet, ip{,6}_output() checks if ESP/AH processing is required by checking if a matching SPD (Security Policy Database) is found. If ESP/AH is needed, {esp,ah}{4,6}_output() will be called and mbuf will be updated accordingly. When a packet is received, {esp,ah}4_input() will be called based on protocol number, i.e. (*inetsw[proto])(). {esp,ah}4_input() will decrypt/check authenticity of the packet, and strips off daisy-chained header and padding for ESP/AH. It is safe to strip off the ESP/AH header on packet reception, since we will never use the received packet in "as is" form. By using ESP/AH, TCP4/6 effective data segment size will be affected by extra daisy-chained headers inserted by ESP/AH. Our code takes care of the case. Basic crypto functions can be found in directory "sys/crypto". ESP/AH transform are listed in {esp,ah}_core.c with wrapper functions. If you wish to add some algorithm, add wrapper function in {esp,ah}_core.c, and add your crypto algorithm code into sys/crypto. Tunnel mode is partially supported in this release, with the following restrictions: IPsec tunnel is not combined with GIF generic tunneling interface. It needs a great care because we may create an infinite loop between ip_output() and tunnelifp->if_output(). Opinion varies if it is better to unify them, or not. MTU and Don't Fragment bit (IPv4) considerations need more checking, but basically works fine. Authentication model for AH tunnel must be revisited. We will need to improve the policy management engine, eventually. Conformance to RFCs and IDs The IPsec code in the kernel conforms (or, tries to conform) to the following standards: "old IPsec" specification documented in rfc182[5-9].txt "new IPsec" specification documented in rfc240[1-6].txt, rfc241[01].txt, rfc2451.txt and draft-mcdonald-simple-ipsec-api-01.txt (draft expired, but you can take from ftp://ftp.kame.net/pub/internet-drafts/). (NOTE: IKE specifications, rfc241[7-9].txt are implemented in userland, as "racoon" IKE daemon) Currently supported algorithms are: old IPsec AH null crypto checksum (no document, just for debugging) keyed MD5 with 128bit crypto checksum (rfc1828.txt) keyed SHA1 with 128bit crypto checksum (no document) HMAC MD5 with 128bit crypto checksum (rfc2085.txt) HMAC SHA1 with 128bit crypto checksum (no document) old IPsec ESP null encryption (no document, similar to rfc2410.txt) DES-CBC mode (rfc1829.txt) new IPsec AH null crypto checksum (no document, just for debugging) keyed MD5 with 96bit crypto checksum (no document) keyed SHA1 with 96bit crypto checksum (no document) HMAC MD5 with 96bit crypto checksum (rfc2403.txt) HMAC SHA1 with 96bit crypto checksum (rfc2404.txt) new IPsec ESP null encryption (rfc2410.txt) DES-CBC with derived IV (draft-ietf-ipsec-ciph-des-derived-01.txt, draft expired) DES-CBC with explicit IV (rfc2405.txt) 3DES-CBC with explicit IV (rfc2451.txt) BLOWFISH CBC (rfc2451.txt) CAST128 CBC (rfc2451.txt) RC5 CBC (rfc2451.txt) each of the above can be combined with: ESP authentication with HMAC-MD5(96bit) ESP authentication with HMAC-SHA1(96bit) The following algorithms are NOT supported: old IPsec AH HMAC MD5 with 128bit crypto checksum + 64bit replay prevention (rfc2085.txt) keyed SHA1 with 160bit crypto checksum + 32bit padding (rfc1852.txt) IPsec (in kernel) and IKE (in userland as "racoon") has been tested at several interoperability test events, and it is known to interoperate with many other implementations well. Also, current IPsec implementation as quite wide coverage for IPsec crypto algorithms documented in RFC (we cover algorithms without intellectual property issues only). ECN consideration on IPsec tunnels ECN-friendly IPsec tunnel is supported as described in draft-ipsec-ecn-00.txt. Normal IPsec tunnel is described in RFC2401. On encapsulation, IPv4 TOS field (or, IPv6 traffic class field) will be copied from inner IP header to outer IP header. On decapsulation outer IP header will be simply dropped. The decapsulation rule is not compatible with ECN, since ECN bit on the outer IP TOS/traffic class field will be lost. To make IPsec tunnel ECN-friendly, we should modify encapsulation and decapsulation procedure. This is described in http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, chapter 3. IPsec tunnel implementation can give you three behaviors, by setting net.inet.ipsec.ecn (or net.inet6.ipsec6.ecn) to some value: RFC2401: no consideration for ECN (sysctl value -1) ECN forbidden (sysctl value 0) ECN allowed (sysctl value 1) Note that the behavior is configurable in per-node manner, not per-SA manner (draft-ipsec-ecn-00 wants per-SA configuration, but it looks too much for me). The behavior is summarized as follows (see source code for more detail): encapsulate decapsulate --- --- RFC2401 copy all TOS bits drop TOS bits on outer from inner to outer. (use inner TOS bits as is) ECN forbidden copy TOS bits except for ECN drop TOS bits on outer (masked with 0xfc) from inner (use inner TOS bits as is) to outer. set ECN bits to 0. ECN allowed copy TOS bits except for ECN use inner TOS bits with some CE (masked with 0xfe) from change. if outer ECN CE bit inner to outer. is 1, enable ECN CE bit on set ECN CE bit to 0. the inner. General strategy for configuration is as follows: if both IPsec tunnel endpoint are capable of ECN-friendly behavior, you should better configure both end to ECN allowed (sysctl value 1). if the other end is very strict about TOS bit, use "RFC2401" (sysctl value -1). in other cases, use "ECN forbidden" (sysctl value 0). The default behavior is "ECN forbidden" (sysctl value 0). For more information, please refer to: http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, RFC2481 (Explicit Congestion Notification), src/sys/netinet6/{ah,esp}_input.c (Thanks goes to Kenjiro Cho kjc@csl.sony.co.jp for detailed analysis) Interoperability Here are (some of) platforms that KAME code have tested IPsec/IKE interoperability in the past. Note that both ends may have modified their implementation, so use the following list just for reference purposes. Altiga, Ashley-laurent (vpcom.com), Data Fellows (F-Secure), Ericsson ACC, FreeS/WAN, HITACHI, IBM AIX, IIJ, Intel, Microsoft WinNT, NIST (linux IPsec + plutoplus), Netscreen, OpenBSD, RedCreek, Routerware, SSH, Secure Computing, Soliton, Toshiba, VPNet, Yamaha RT100i diff --git a/en_US.ISO8859-1/books/developers-handbook/l10n/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/l10n/chapter.sgml index 80e8686485..d9f2b323ec 100644 --- a/en_US.ISO8859-1/books/developers-handbook/l10n/chapter.sgml +++ b/en_US.ISO8859-1/books/developers-handbook/l10n/chapter.sgml @@ -1,82 +1,81 @@ Localization and Internationalization - L10N and I18N Programming I18N Compliant Applications Qt GTK To make your application more useful for speakers of other languages, we hope that you will program I18N compliant. The GNU gcc compiler and GUI libraries like QT and GTK support I18N through special handling of strings. Making a program I18N compliant is very easy. It allows contributors to port your application to other languages quickly. Refer to the library specific I18N documentation for more details. In contrast with common perception, I18N compliant code is easy to write. Usually, it only involves wrapping your strings with library specific functions. In addition, please be sure to allow for wide or multibyte character support. A Call to Unify the I18N Effort It has come to our attention that the individual I18N/L10N efforts for each country has been repeating each others' efforts. Many of us have been reinventing the wheel repeatedly and inefficiently. We hope that the various major groups in I18N could congregate into a group effort similar to the Core Team's responsibility. Currently, we hope that, when you write or port I18N programs, you would send it out to each country's related FreeBSD mailing list for testing. In the future, we hope to create applications that work in all the languages out-of-the-box without dirty hacks. The &a.i18n; has been established. If you are an I18N/L10N developer, please send your comments, ideas, questions, and anything you deem related to it. - - Michael C. Wu will be maintaining an I18N works in progress - homepage at http://www.FreeBSD.org/~keichii/i18n/index.html + + Michael C. Wu will be maintaining an I18N works in progress + homepage at . Please also read the BSDCon2000 I18N paper and presentations by Clive Lin, Chia-Liang Kao, and Michael C. Wu at http://www.FreeBSD.org/~keichii/papers/ + url="http://www.FreeBSD.org/~keichii/papers/"> Perl and Python Perl Python Perl and Python have I18N and wide character handling libraries. Please use them for I18N compliance. In older FreeBSD versions, Perl may give warnings about not having a wide character locale installed on your system. You can set the environment variable LD_PRELOAD to /usr/lib/libxpg4.so in your shell. In sh-based shells: LD_PRELOAD=/usr/lib/libxpg4.so In C-based shells: setenv LD_PRELOAD /usr/lib/libxpg4.so diff --git a/en_US.ISO8859-1/books/faq/book.sgml b/en_US.ISO8859-1/books/faq/book.sgml index 0e7aa3cfc1..7ed20895bd 100644 --- a/en_US.ISO8859-1/books/faq/book.sgml +++ b/en_US.ISO8859-1/books/faq/book.sgml @@ -1,12590 +1,12588 @@ %man; %freebsd; %authors; %teams; %bookinfo; %mailing-lists; ]> Frequently Asked Questions for FreeBSD 2.X, 3.X and 4.X The FreeBSD Documentation Project $FreeBSD$ 1995 1996 1997 1998 1999 2000 2001 2002 2003 The FreeBSD Documentation Project &bookinfo.legalnotice; This is the FAQ for FreeBSD versions 2.X, 3.X, and 4.X. All entries are assumed to be relevant to FreeBSD 2.0.5 and later, unless otherwise noted. 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 FreeBSD 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 FreeBSD FTP server. You may also want to Search the FAQ. Introduction Welcome to the FreeBSD 2.X-4.X FAQ! As is usual with Usenet FAQs, this document aims to cover the most frequently asked questions concerning the FreeBSD operating system (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. 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;. What is FreeBSD? Briefly, FreeBSD is a UN*X-like operating system for the i386, IA-64, PC-98, Alpha/AXP, and UltraSPARC platforms 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. A fuller description of what FreeBSD is and how it can work for you may be found on the FreeBSD home page. FreeBSD is used by companies, Internet Service Providers, researchers, computer professionals, students and home users all over the world in their work, education and recreation. See some of them in the FreeBSD Gallery. For more detailed information on FreeBSD, please see the FreeBSD Handbook. What is the goal of the FreeBSD Project? The goal of the FreeBSD Project is to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and 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 is, we believe, one of the most fundamental goals of Free Software and one that we enthusiastically support. That 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 FreeBSD license whenever possible. Does the FreeBSD license have any restrictions? Yes. Those restrictions do not control how you use the code, merely how you treat the FreeBSD 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. Can FreeBSD 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. FreeBSD 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 FreeBSD, however. If you want a solid office or Internet server, a reliable workstation, or just the ability to do your job without interruptions, FreeBSD will almost certainly do everything you need. Many computer users across the world, including both novices and experienced &unix; administrators, use FreeBSD as their only desktop operating system. If you are migrating to FreeBSD 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 older versions of Mac OS, expect to invest additional time learning the &unix; way of doing things. This FAQ and the FreeBSD Handbook are excellent places to start. Why is it called FreeBSD? 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 FreeBSD code, for example pretending you wrote it, you can really do whatever you like with it. What are the differences between FreeBSD 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 for DaemonNews, called The BSD Family Tree which goes a fair way to answering this question. What is the latest version of FreeBSD? At this point in FreeBSD's development, there are two parallel development branches; releases are being made from both branches. The 4.X series of releases is being made from the -STABLE branch and the 5.X series of releases is being made from -CURRENT. Version &rel.current; is the latest release from the -CURRENT branch; it was released in &rel.current.date;. Version &rel2.current; is the latest release from the -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 FreeBSD sources (see the questions on FreeBSD-CURRENT and FreeBSD-STABLE) than that, doing so is more of a commitment, as the sources are a moving target. More information on FreeBSD releases can be found on the Release Engineering page on the FreeBSD Web site. What is FreeBSD-CURRENT? FreeBSD-CURRENT is the development version of the operating system, which will in due course become 5.0-RELEASE. 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 the operating system or are not capable of identifying the difference between a real problem and a temporary problem, you should not use FreeBSD-CURRENT. This branch sometimes evolves quite quickly and can be un-buildable for a number of days at a time. People that use FreeBSD-CURRENT are expected to be able to analyze any problems and only report them if they are deemed to be mistakes rather than glitches. Questions such as make world produces some error about groups on the -CURRENT mailing list may be treated with contempt. Every day, snapshot releases are made based on the current state of the -CURRENT and -STABLE branches. Distributions of the occasional snapshot are made available. 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 CVS 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 ftp://current.FreeBSD.org/pub/FreeBSD/ for 5.0-CURRENT and releng4.FreeBSD.org for 4-STABLE snapshots. 3-STABLE snapshots are not being produced at the time of this writing (May 2000). Snapshots are generated, on the average, daily for all actively developed branches. What is the FreeBSD-STABLE concept? Back when FreeBSD 2.0.5 was released, FreeBSD development branched in two. One branch was named -STABLE, one -CURRENT. FreeBSD-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. FreeBSD-CURRENT, on the other hand, has been one unbroken line leading towards 5.0-RELEASE (and beyond) since 2.0 was released. If a little ASCII art would help, this is how it looks: 2.0 | | | [2.1-STABLE] *BRANCH* 2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1 [2.1-STABLE ends] | (Mar 1997) | | | [2.2-STABLE] *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [end] | (Mar 1997) (Oct 97) (Apr 98) (Jul 98) (Dec 98) | | 3.0-SNAPs (started Q1 1997) | | 3.0-RELEASE (Oct 1998) | | [3.0-STABLE] *BRANCH* 3.1-RELEASE (Feb 1999) -> 3.2 -> 3.3 -> 3.4 -> 3.5 -> 3.5.1 | (May 1999) (Sep 1999) (Dec 1999) (June 2000) (July 2000) | | [4.0-STABLE] *BRANCH* 4.0 (Mar 2000) -> 4.1 -> 4.1.1 -> 4.2 -> 4.3 -> 4.4 -> ... future 4.X releases ... | | (July 2000) (Sep 2000) (Nov 2000) \|/ + [5.0-CURRENT continues] The 2.2-STABLE branch was retired with the release of 2.2.8. The 3-STABLE branch has ended with the release of 3.5.1, the final 3.X release. The only changes made to either of these branches will be, for the most part, security-related bug fixes. 4-STABLE is the actively developed -STABLE branch. The latest release on the 4-STABLE is &rel.current;-RELEASE, which was released in &rel.current.date;. The 5-CURRENT branch is slowly progressing toward 5.0-RELEASE and beyond. See What is FreeBSD-CURRENT? for more information on this branch. When are FreeBSD releases made? The &a.re; releases a new version of FreeBSD about every four 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, in order 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 FreeBSD, 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 FreeBSD Web site. For people who need or want a little more excitement, binary snapshots are made daily as discussed above. Who is responsible for FreeBSD? The key decisions concerning the FreeBSD 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 200 committers who are authorized to make changes directly to the FreeBSD 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 FreeBSD? Every significant release of FreeBSD is available via anonymous FTP from the FreeBSD FTP site: For the current 3.X-STABLE release, 3.5.1-RELEASE, see the 3.5.1-RELEASE directory. The latest 5.X release, &rel.current;-RELEASE can be found in the &rel.current;-RELEASE directory. The latest 4-STABLE release, &rel2.current;-RELEASE can be found in the &rel2.current;-RELEASE directory. 4.X snapshots are usually made daily. 5.0 Snapshot releases are made daily for the -CURRENT branch, these being of service purely to bleeding-edge testers and developers. Information about obtaining FreeBSD on CD, DVD, and other media can be found in the Handbook. How do I set up a FreeBSD mirror? Information on setting up a FreeBSD mirror can be found in the Mirroring FreeBSD article. 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. The web-based problem report submission interface is currently disabled due to persistent abuse. Before submitting a problem report, please read Writing FreeBSD Problem Reports, an article on how to write good problem reports. How do I become a FreeBSD Web mirror? There are multiple ways to mirror the Web pages. You can retrieve the formatted files from a FreeBSD CVSup server using the application net/cvsup. The file /usr/share/examples/cvsup/www-supfile contains an example CVSup configuration file for web mirrors. You can download the web site source code from any FreeBSD FTP server using your favorite ftp mirror tool. Keep in mind that you have to build these sources before publishing them. Start mirroring at - ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/www. + . What other sources of information are there? Please check the Documentation list on the main FreeBSD web site. Documentation and Support What good books are there about FreeBSD? The project produces a wide range of documentation, available online from this link: - http://www.FreeBSD.org/docs.html. + . The same documents are available as packages, that you can easily install on your FreeBSD system. More details on documentation packages can be found in the next paragraphs. 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 FreeBSD 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 FreeBSD system. The current languages and encodings that we have for documentation are as follows: Name Meaning en_US.ISO8859-1 US English de_DE.ISO8859-1 German es_ES.ISO8859-1 Spanish fr_FR.ISO8859-1 French ja_JP.eucJP Japanese (EUC encoding) ru_RU.KOI8-R Russian (KOI8-R encoding) zh_TW.Big5 Chinese (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 pdb Palm Pilot database format, for use with the iSilo reader. pdf Adobe's Portable Document Format ps PostScript rtf Microsoft's Rich Text Format Page numbers are not automatically updated when loading this format into Word. Press CTRLA, CTRLEND, F9 after loading the document, to update the page numbers. txt Plain text The compression and packaging scheme. There are three of these currently in use. 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 book.format (i.e., book.pdb, book.html, and so on). These files are then compressed using three compression schemes. Scheme Description zip The Zip format. If you want to uncompress this on FreeBSD you will need to install the archivers/unzip port first. gz The GNU Zip format. Use &man.gunzip.1; to uncompress these files, which is part of FreeBSD. bz2 The BZip2 format. Less widespread than the others, but generally gives smaller files. Install the archivers/bzip2 port 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 must then decide whether or not you want to download the document as a FreeBSD package. The advantage of downloading and installing the package is that the documentation can then be managed using the normal FreeBSD package management comments, such as &man.pkg.add.1; and &man.pkg.delete.1;. If you decide to download and install the package then you must know the filename to download. The documentation-as-packages files are stored in a directory called packages. Each package file looks like document-name.lang.encoding.format.tgz. For example, the FAQ, in English, formatted as PDF, is in the package called faq.en_US.ISO8859-1.pdf.tgz. Knowing this, you can use the following command to install the English PDF FAQ package. &prompt.root; pkg_add ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/packages/faq.en_US.ISO8859-1.pdf.tgz Having done that, you can use &man.pkg.info.1; to determine where the file has been installed. &prompt.root; pkg_info -f faq.en_US.ISO8859-1.pdf Information for faq.en_US.ISO8859-1.pdf: Packing list: Package name: faq.en_US.ISO8859-1.pdf CWD to /usr/share/doc/en_US.ISO8859-1/books/faq File: book.pdf CWD to . File: +COMMENT (ignored) File: +DESC (ignored) As you can see, book.pdf will have been installed into /usr/share/doc/en_US.ISO8859-1/books/faq. If you do not want to use the packages then 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.gzip.1;, can be found in the doc/en_US.ISO8859-1/books/faq/book.html-split.tar.gz file. 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.gz &prompt.root; gzip -d book.html-split.tar.gz &prompt.root; tar xvf book.html-split.tar 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 FreeBSD mailing lists? You can find full information in the Handbook entry on mailing-lists. Where do I find the FreeBSD Y2K info? You can find full information in the FreeBSD Y2K page. What FreeBSD news groups are available? You can find full information in the Handbook entry on newsgroups. Are there FreeBSD IRC (Internet Relay Chat) channels? Yes, most major IRC networks host a FreeBSD chat channel: Channel #FreeBSD on EFNet is a FreeBSD forum, but do not go there for tech support or try to get folks there to help you avoid the pain of reading manual pages or doing your own research. It is a chat channel, first and foremost, and topics there are just as likely to involve sex, sports or nuclear weapons as they are FreeBSD. You Have Been Warned! Available at server irc.chat.org. Channel #FreeBSDhelp on EFNet is a channel dedicated to helping FreeBSD users. They are much more sympathetic to questions than #FreeBSD is. 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 HybNet. This channel is a help channel. A list of servers can be found on the HybNet web site. 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. Where can I get commercial FreeBSD training and support? DaemonNews provides commercial training and support for FreeBSD. More information can be found at their BSD Mall site. FreeBSD Services Ltd provide commercial support for FreeBSD in the UK (as well as selling FreeBSD on DVD). See their web site for more information. The FreeBSD Mall provides commercial FreeBSD support. You can get more information at their web site. Any other organizations providing training and support should contact the project in order to be listed here. Nik Clayton
nik@FreeBSD.org
 Installation Which file do I download to get FreeBSD? Prior to release 3.1, you only needed one floppy image to install FreeBSD, namely floppies/boot.flp. However, since release 3.1 the Project has added out-of-the-box support for a wide variety of hardware, which takes up more space. For 3.X and later you need two floppy images: floppies/kernel.flp and floppies/mfsroot.flp. These images need to be copied onto floppies by tools like fdimage or &man.dd.1;. If you need to download the distributions yourself (for a DOS filesystem install, for instance), below are some recommendations for distributions to grab: bin/ manpages/ compat*/ doc/ src/ssys.* Full instructions on this procedure and a little bit more about installation issues in general can be found in the Handbook entry on installing FreeBSD. What do I do if the floppy images does not fit on a single floppy? A 3.5 inch (1.44MB) floppy can accommodate 1474560 bytes of data. The boot image is exactly 1474560 bytes in size. Common mistakes when preparing the boot floppy are: Not downloading the floppy 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 size 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 FreeBSD. Where are the instructions for installing FreeBSD? Installation instructions can be found in the Handbook entry on installing FreeBSD. What do I need in order to run FreeBSD? You will need a 386 or better PC, with 5 MB or more of RAM and at least 60 MB of hard disk space. It can run with a low end MDA graphics card but to run X11R6, a VGA or better video card is needed. See also . I have only 4 MB of RAM. Can I install FreeBSD? FreeBSD 2.1.7 was the last version of FreeBSD that could be installed on a 4MB system. FreeBSD 2.2 and later needs at least 5MB to install on a new system. All versions of FreeBSD will run in 4MB of RAM, they just cannot run the installation program in 4MB. You can add extra memory for the install process, if you like, and then after the system is up and running, go back to 4MB. Or you could swap your disk into a system which has >4MB, install onto the disk and then swap it back. After the installation, if you build a custom kernel, it will run in 4 MB. Someone has even successfully booted with 2 MB, although the system was almost unusable. How can I make my own custom install floppy? Currently there is no way to just make a custom install floppy. You have to cut a whole new release, which will include your install floppy. To make a custom release, follow the instructions in the Release Engineering article. Can I have more than one operating system on my PC? Have a look at the multi-OS page. Can Windows 95/98 co-exist with FreeBSD? Install Windows 95/98 first, after that FreeBSD. FreeBSD's boot manager will then manage to boot Win95/98 and FreeBSD. If you install Windows 95/98 second, it will boorishly overwrite your boot manager without even asking. If that happens, see the next section. Windows 95/98 killed my boot manager! How do I get it back? You can reinstall the boot manager FreeBSD comes with in one of three ways: Running DOS, go into the tools/ directory of your FreeBSD distribution and look for bootinst.exe. You run it like so: ...\TOOLS> bootinst.exe boot.bin and the boot manager will be reinstalled. Boot the FreeBSD boot floppy again and go to the Custom installation menu item. Choose Partition. Select the drive which used to contain your boot manager (likely the first one) and when you come to the partition editor for it, as the very first thing (e.g. do not make any changes) select (W)rite. This will ask for confirmation, say yes, and when you get the Boot Manager selection prompt, be sure to select Boot Manager. This will re-write the boot manager to disk. Now quit out of the installation menu and reboot off the hard disk as normal. Boot the FreeBSD boot floppy (or CDROM) and choose the Fixit menu item. Select either the Fixit floppy or CDROM #2 (the live filesystem option) as appropriate and enter the fixit shell. Then execute the following command: Fixit# fdisk -B -b /boot/boot0 bootdevice substituting bootdevice for your real boot device such as ad0 (first IDE disk), ad4 (first IDE disk on auxiliary controller), da0 (first SCSI disk), etc. My A, T, or X series IBM Thinkpad locks up when I first booted up my FreeBSD installation. How can I solve this? A bug in early revisions of IBM's BIOS on these machines mistakenly identifies the FreeBSD partition as a potential FAT suspend-to-disk partition. When the BIOS tries to parse the FreeBSD partition it hangs. According to IBMIn an e-mail from Keith Frechette kfrechet@us.ibm.com., the following model/BIOS release numbers incorporate the fix. Model BIOS revision T20 IYET49WW or later T21 KZET22WW or later A20p IVET62WW or later A20m IWET54WW or later A21p KYET27WW or later A21m KXET24WW or later A21e KUET30WW It has been reported that later IBM BIOS revisions may have reintroduced the bug. This message from Jacques Vidrine to the &a.mobile; describes a procedure which may work if your newer IBM laptop does not boot FreeBSD properly, and you can upgrade or downgrade the BIOS. If you have an earlier BIOS, and upgrading is not an option a workaround is to install FreeBSD, change the partition ID FreeBSD uses, and install new boot blocks that can handle the different partition ID. First, you will need to restore the machine to a state where it can get through its self-test screen. Doing this requires powering up the machine without letting it find a FreeBSD partition on its primary disk. One way is to remove the hard disk and temporarily move it to an older ThinkPad (such as a ThinkPad 600) or a desktop PC with an appropriate conversion cable. Once it is there, you can delete the FreeBSD partition and move the hard disk back. The ThinkPad should now be in a bootable state again. With the machine functional again, you can use the workaround procedure described here to get a working FreeBSD installation. Download boot1 and boot2 from http://people.FreeBSD.org/~bmah/ThinkPad/. + url="http://people.FreeBSD.org/~bmah/ThinkPad/">. Put these files somewhere you will be able to retrieve them later. Install FreeBSD as normal on to the ThinkPad. Do not use Dangerously Dedicated mode. Do not reboot when the install has finished. Either switch to the Emergency Holographic Shell (ALT F4) or start a fixit shell. Use &man.fdisk.8; to change the FreeBSD partition ID from 165 to 166 (this is the type used by OpenBSD). Bring the boot1 and boot2 files to the local filesystem. Use &man.disklabel.8; to write boot1 and boot2 to your FreeBSD slice. &prompt.root; disklabel -B -b boot1 -s boot2 ad0sn n is the number of the slice where you installed FreeBSD. Reboot. At the boot prompt you will be given the option of booting OpenBSD. This will actually boot FreeBSD. Getting this to work in the case where you want to dual boot OpenBSD and FreeBSD on the same laptop is left as an exercise for the reader. Can I install on a disk with bad blocks? Prior to 3.0, FreeBSD included a utility known as bad144, which automatically remapped bad blocks. Because modern IDE drives perform this function themselves, bad144 has been removed from the FreeBSD source tree. If you wish to install FreeBSD 3.0 or later, we strongly suggest you purchase a newer disk drive. If you do not wish to do this, you must run FreeBSD 2.X. If you are seeing bad block errors with a modern IDE drive, chances are the drive is going to die very soon (the drive's internal remapping functions are no longer sufficient to fix the bad blocks, which means the disk is heavily corrupted); we suggest you buy a new hard drive. If you have a SCSI drive with bad blocks, see this answer. I have just upgraded from 3.X to 4.X, and my first boot failed with bad sector table not supported FreeBSD 3.X and earlier supported bad144, which automatically remapped bad blocks. FreeBSD 4.X and later do not support this, as modern IDE drives include this functionality. See this question for more information. To fix this after an upgrade, you need to physically place the drive in a working system and use &man.disklabel.8; as discussed in the following questions. How do I tell if a drive has bad144 information on it before I try to upgrade to FreeBSD 4.0 and it fails? Use &man.disklabel.8; for this. disklabel -r drive device will give you the contents of your disk label. Look for a flags field. If you see flags: badsect, this drive is using bad144. For example, the following drive has bad144 enabled.: &prompt.root; disklabel -r wd0 # /dev/rwd0c: type: ESDI disk: wd0s1 label: flags: badsect bytes/sector: 512 sectors/track: 63 How do I remove bad144 from my pre-4.X system so I can upgrade safely? Use disklabel -e -rwd0 to edit the disklabel in place. Just remove the word badsect from the flags field, save, and exit. The bad144 file will still take up some space on your drive, but the disk itself will be usable. We still recommend you purchase a new disk if you have a large number of bad blocks. Strange things happen when I boot the install floppy! What is happening? If you are seeing things like the machine grinding to a halt or spontaneously rebooting when you try to boot the install floppy, here are three questions to ask yourself:- Did you use a new, freshly-formatted, error-free floppy (preferably a brand-new one straight out of the box, as opposed to the magazine cover disk that has been lying under the bed for the last three years)? Did you download the floppy image in binary (or image) mode? (do not be embarrassed, even the best of us have accidentally downloaded a binary file in ASCII mode at least once!) If you are using Windows95 or Win98 did you run fdimage or rawrite in pure DOS mode? These operating systems can interfere with programs that write directly to hardware, which the disk creation program does; even running it inside a DOS shell in the GUI can cause this problem. There have also been reports of Netscape causing problems when downloading the boot floppy, so it is probably best to use a different FTP client if you can. I booted from my ATAPI CDROM, but the install program says no CDROM is found. Where did it go? The usual cause of this problem is a mis-configured CDROM drive. Many PCs now ship with the CDROM 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 CDROM to boot from it, but why FreeBSD cannot see it to complete the install. Reconfigure your system so that the CDROM 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. Can I install on my laptop over PLIP (Parallel Line IP)? Yes. Use a standard Laplink cable. If necessary, you can check out the PLIP section of the Handbook for details on parallel port networking. If you are running FreeBSD 3.X or earlier, also look at the Mobile Computing page. Which geometry should I use for a disk drive? By the geometry of a disk, we mean the number of cylinders, heads and sectors/track on a disk. We will refer to this as C/H/S for convenience. This is how the PC's BIOS works out which area on a disk to read/write from. This causes a lot of confusion among new system administrators. First of all, the physical geometry of a SCSI drive is totally irrelevant, as FreeBSD works in term of disk blocks. In fact, there is no such thing as the physical geometry, as the sector density varies across the disk. What manufacturers claim is the physical geometry is usually the geometry that they have determined wastes the least space. For IDE disks, FreeBSD does work in terms of C/H/S, but all modern drives internally convert this into block references. All that matters is the logical geometry. This is the answer that the BIOS gets when it asks the drive what is your geometry? It then uses this geometry to access the disk. As FreeBSD uses the BIOS when booting, it is very important to get this right. In particular, if you have more than one operating system on a disk, they must all agree on the geometry. Otherwise you will have serious problems booting! For SCSI disks, the geometry to use depends on whether extended translation support is turned on in your controller (this is often referred to as support for DOS disks >1GB or something similar). If it is turned off, then use N cylinders, 64 heads and 32 sectors/track, where N is the capacity of the disk in MB. For example, a 2GB disk should pretend to have 2048 cylinders, 64 heads and 32 sectors/track. If it is turned on (it is often supplied this way to get around certain limitations in MSDOS) and the disk capacity is more than 1GB, use M cylinders, 63 sectors per track (not 64), and 255 heads, where 'M' is the disk capacity in MB divided by 7.844238 (!). So our example 2GB drive would have 261 cylinders, 63 sectors per track and 255 heads. If you are not sure about this, or FreeBSD fails to detect the geometry correctly during installation, the simplest way around this is usually to create a small DOS partition on the disk. The BIOS should then detect the correct geometry, and you can always remove the DOS partition in the partition editor if you do not want to keep it. You might want to leave it around for programming network cards and the like, however. Alternatively, there is a freely available utility distributed with FreeBSD called pfdisk.exe. You can find it in the tools subdirectory on the FreeBSD CDROM or on the various FreeBSD FTP sites. This program can be used to work out what geometry the other operating systems on the disk are using. You can then enter this geometry in the partition editor. Are there any restrictions on how I divide the disk up? Yes. You must make sure that your root partition is below 1024 cylinders so the BIOS can boot the kernel from it. (Note that this is a limitation in the PC's BIOS, not FreeBSD). For a SCSI drive, this will normally imply that the root partition will be in the first 1024MB (or in the first 4096MB if extended translation is turned on - see previous question). For IDE, the corresponding figure is 504MB. Is FreeBSD compatible with any disk managers? FreeBSD recognizes the Ontrack Disk Manager and makes allowances for it. Other disk managers are not supported. If you just want to use the disk with FreeBSD you do not need a disk manager. Just configure the disk for as much space as the BIOS can deal with (usually 504 megabytes), and FreeBSD should figure out how much space you really have. If you are using an old disk with an MFM controller, you may need to explicitly tell FreeBSD how many cylinders to use. If you want to use the disk with FreeBSD and another operating system, you may be able to do without a disk manager: just make sure the FreeBSD boot partition and the slice for the other operating system are in the first 1024 cylinders. If you are reasonably careful, a 20 megabyte boot partition should be plenty. When I boot FreeBSD I get Missing Operating System. What is happening? This is classically a case of FreeBSD and DOS or some other OS conflicting over their ideas of disk geometry. You will have to reinstall FreeBSD, but obeying the instructions given above will almost always get you going. Why can I not get past the boot manager's F? prompt? This is another symptom of the problem described in the preceding question. Your BIOS geometry and FreeBSD geometry settings do not agree! If your controller or BIOS supports cylinder translation (often marked as >1GB drive support), try toggling its setting and reinstalling FreeBSD. Do I need to install the complete sources? In general, no. However, we would strongly recommend that you install, at a minimum, the base source kit, which includes several of the files mentioned here, and the sys (kernel) source kit, which includes sources for the kernel. There is nothing in the system which requires the presence of the sources to operate, however, except for the kernel-configuration program &man.config.8;. With the exception of the kernel sources, our build structure is set up so that you can read-only mount the sources from elsewhere via NFS and still be able to make new binaries (due to the kernel-source restriction, we recommend that you not mount this on /usr/src directly, but rather in some other location with appropriate symbolic links to duplicate the top-level structure of the source tree). Having the sources on-line and knowing how to build a system with them will make it much easier for you to upgrade to future releases of FreeBSD. To actually select a subset of the sources, use the Custom menu item when you are in the Distributions menu of the system installation tool. Do I need to build a kernel? Building a new kernel was originally pretty much a required step in a FreeBSD installation, but more recent releases have benefited from the introduction of a much friendlier kernel configuration tool. When at the FreeBSD boot prompt (boot:), use the flag and you will be dropped into a visual configuration screen which allows you to configure the kernel's settings for most common ISA cards. It is still recommended that you eventually build a new kernel containing just the drivers that you need, just to save a bit of RAM, but it is no longer a strict requirement for most systems. Should I use DES, Blowfish, or MD5 passwords and how do I specify which form my users receive? The default password format on FreeBSD is to use MD5-based passwords. 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 (they are available if you choose to install the crypto distribution in sysinstall, or by installing the crypto sources if building from source). Installing the crypto libraries will also allow you to use the Blowfish password format, which is more secure. 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. Why does the boot floppy start, but hang at the Probing Devices... screen? If you have a IDE Zip or Jaz drive installed, remove it and try again. The boot floppy can get confused by the drives. After the system is installed you can reconnect the drive. Hopefully this will be fixed in a later release. Why do I get a panic: can't mount root error when rebooting the system after installation? This error comes from confusion between the boot block's and the kernel's understanding of the disk devices. The error usually manifests on two-disk IDE systems, with the hard disks arranged as the master or single device on separate IDE controllers, with FreeBSD installed on the secondary IDE controller. The boot blocks think the system is installed on wd1 (the second BIOS disk) while the kernel assigns the first disk on the secondary controller device wd2. After the device probing, the kernel tries to mount what the boot blocks think is the boot disk, wd1, while it is really wd2, and fails. To fix the problem, do one of the following: For FreeBSD 3.3 and later, reboot the system and hit Enter at the Booting kernel in 10 seconds; hit [Enter] to interrupt prompt. This will drop you into the boot loader. Then type set root_disk_unit="disk_number" . disk_number will be 0 if FreeBSD is installed on the master drive on the first IDE controller, 1 if it is installed on the slave on the first IDE controller, 2 if it is installed on the master of the second IDE controller, and 3 if it is installed on the slave of the second IDE controller. Then type boot, and your system should boot correctly. To make this change permanent (ie so you do not have to do this every time you reboot or turn on your FreeBSD machine), put the line root_disk_unit="disk_number" in /boot/loader.conf.local . If using FreeBSD 3.2 or earlier, at the Boot: prompt, enter 1:wd(2,a)kernel and press Enter. If the system starts, then run the command echo "1:wd(2,a)kernel" > /boot.config to make it the default boot string. Move the FreeBSD disk onto the primary IDE controller, so the hard disks are consecutive. Rebuild your kernel, modify the wd configuration lines to read: controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 # disk wd1 at wdc0 drive 1 # comment out this line controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd1 at wdc1 drive 0 # change from wd2 to wd1 disk wd2 at wdc1 drive 1 # change from wd3 to wd2 Install the new kernel. If you moved your disks and wish to restore the previous configuration, replace the disks in the desired configuration and reboot. Your system should boot successfully. What are the limits for memory? For memory, the limit is 4 gigabytes. If you plan to install this much memory into a machine, you need to be careful. You will probably want to use ECC memory and to reduce capacitive loading use 9 chip memory modules versus 18 chip memory modules. What are the limits for ffs filesystems? For ffs filesystems, the maximum theoretical limit is 8 terabytes (2G blocks), or 16TB for the default block size of 8K. In practice, there is a soft limit of 1 terabyte, but with modifications filesystems with 4 terabytes are possible (and exist). The maximum size of a single ffs file is approximately 1G blocks, or 4TB with a block size of 4K. Maximum file sizes fs block size 2.2.7-stable 3.0-current works should work 4K 4T-1 4T-1 4T-1 >4T 8K >32G 8T-1 >32G 32T-1 16K >128G 16T-1 >128G 32T-1 32K >512G 32T-1 >512G 64T-1 64K >2048G 64T-1 >2048G 128T-1
When the fs block size is 4K, triple indirect blocks work and everything should be limited by the maximum fs block number that can be represented using triple indirect blocks (approx. 1K^3 + 1K^2 + 1K), but everything is limited by a (wrong) limit of 1G-1 on fs block numbers. The limit on fs block numbers should be 2G-1. There are some bugs for fs block numbers near 2G-1, but such block numbers are unreachable when the fs block size is 4K. For block sizes of 8K and larger, everything should be limited by the 2G-1 limit on fs block numbers, but is actually limited by the 1G-1 limit on fs block numbers, except under -STABLE triple indirect blocks are unreachable, so the limit is the maximum fs block number that can be represented using double indirect blocks (approx. (blocksize/4)^2 + (blocksize/4)), and under -CURRENT exceeding this limit may cause problems. Using the correct limit of 2G-1 blocks does cause problems. Why do I get an error message, archsw.readin.failed after compiling and booting a new kernel? You can boot by specifying the kernel directly at the second stage, pressing any key when the | shows up before loader is started. More specifically, you have upgraded the source for your kernel, and installed a new kernel builtin from them without making world. This is not supported. Make world. How do I upgrade from 3.X -> 4.X? We strongly recommend that you use binary snapshots to do this. 4-STABLE snapshots are available at - ftp://releng4.FreeBSD.org/. + . Because of the many changes between 3.X and 4-STABLE, a direct upgrade from source will probably fail. A source upgrade can be done, but only in stages. First, upgrade to the latest 3-STABLE (RELENG_3). Then upgrade to 4.1.1-RELEASE (RELENG_4_1_1_RELEASE). Finally, upgrade to 4-STABLE (RELENG_4). If you wish to upgrade using source, please see the FreeBSD Handbook for more information. Upgrading via source is never recommended for new users, and upgrading from 3.X to 4.X is even less so; make sure you have read the instructions carefully before attempting to upgrade via source. What are these security profiles? A security profile is a set of configuration options that attempts to achieve the desired ratio of security to convenience by enabling and disabling certain programs and other settings. For full details, see the Security Profile section of the Handbook's post-install chapter. Hardware compatibility Does FreeBSD support architectures other than the x86? Yes. FreeBSD currently runs on Intel x86 and DEC (now Compaq) Alpha architectures. As of FreeBSD 5.0, the SPARC-64 architecture will also be supported. Most recent additions to the list of upcoming platforms are IA-64, MIPS and PowerPC, join the &a.ia64;, the &a.ppc; or the &a.mips; respectively for more information about ongoing work on these platforms. For general discussion on new architectures, join the &a.platforms;. If your machine has a different architecture and you need something right now, we suggest you look at NetBSD or OpenBSD. I want to get a piece of hardware for my FreeBSD system. Which model/brand/type is best? This is discussed continually on the FreeBSD mailing lists. Since hardware changes so quickly, however, we expect this. We still strongly recommend that you read through the Hardware Notes 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 FreeBSD-mobile mailing list archives. Otherwise, you probably want the archives for FreeBSD-questions, or possibly a specific mailing list for a particular hardware type. What kind of hard drives does FreeBSD support? FreeBSD supports EIDE and SCSI 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 controllers are supported? See the complete list in the current Hardware Notes. Which CDROM drives are supported by FreeBSD? Any SCSI drive connected to a supported controller is supported. The following proprietary CDROM interfaces are also supported: Mitsumi LU002 (8bit), LU005 (16bit) and FX001D (16bit 2x Speed). Sony CDU 31/33A Sound Blaster Non-SCSI CDROM Matsushita/Panasonic CDROM ATAPI compatible IDE CDROMs All non-SCSI cards are known to be extremely slow compared to SCSI drives, and some ATAPI CDROMs may not work. As of 2.2 the FreeBSD CDROM from the FreeBSD Mall supports booting directly from the CD. Which CD-RW drives are supported by FreeBSD? FreeBSD supports any ATAPI-compatible IDE CD-R or CD-RW drive. For FreeBSD versions 4.0 and later, see the manual page for &man.burncd.8;. For earlier FreeBSD versions, see the examples in /usr/share/examples/atapi. FreeBSD also supports any SCSI CD-R or CD-RW drives. Install and use the cdrecord command from the ports or packages system, and make sure that you have the pass device compiled in your kernel. Does FreeBSD support ZIP drives? FreeBSD supports SCSI and ATAPI (IDE) ZIP drives out of the box, of course. SCSI ZIP drives can only be set to run at SCSI target IDs 5 or 6, but if your SCSI host adapter's BIOS supports it you can even boot from it. It is not clear which host adapters support booting from targets other than 0 or 1, so you will have to consult your adapter's documentation if you would like to use this feature. FreeBSD also supports Parallel Port Zip Drives. Check that your kernel contains the scbus0, da0, ppbus0, and vp0 drivers (the GENERIC kernel contains everything except vp0). With all these drivers present, the Parallel Port drive should be available as /dev/da0s4. Disks can be mounted using mount /dev/da0s4 /mnt OR (for dos disks) mount_msdos /dev/da0s4 /mnt as appropriate. Also check out the FAQ on removable drives later in this chapter, and the note on formattingin the Administration chapter. Does FreeBSD support JAZ, EZ and other removable drives? Apart from the IDE version of the EZ drive, these are all SCSI devices, so they should all look like SCSI disks to FreeBSD, and the IDE EZ should look like an IDE drive. I am not sure how well FreeBSD supports changing the media out while running. You will of course need to dismount the drive before swapping media, and make sure that any external units are powered on when you boot the system so FreeBSD can see them. See this note on formatting. Which multi-port serial cards are supported by FreeBSD? There is a list of these in the Miscellaneous devices section of the handbook. Some unnamed clone cards have also been known to work, especially those that claim to be AST compatible. Check the &man.sio.4; manual page to get more information on configuring such cards. Does FreeBSD support my USB keyboard? FreeBSD 4.X and later supports USB keyboards out-of-the-box. Preliminary USB device support appeared in FreeBSD 3.1, but might not always work as of version 3.2. If you want to experiment with the USB keyboard support in FreeBSD 3.X, follow the procedure described below. Use a version of FreeBSD 3.X later than 3.2. Add the following lines to your kernel configuration file, and rebuild the kernel. controller uhci0 controller ohci0 controller usb0 controller ukbd0 options KBD_INSTALL_CDEV Go to the /dev directory and create device nodes as follows: &prompt.root; cd /dev &prompt.root; ./MAKEDEV kbd0 kbd1 Edit /etc/rc.conf and add the following lines: usbd_enable="YES" usbd_flags="" If you want to use a USB keyboard in FreeBSD 4.X or later, you just need to enable USB support in /etc/rc.conf. Once you have USB keyboard support enabled on your system, the AT keyboard becomes /dev/kbd0 and the USB keyboard becomes /dev/kbd1, if both are connected to the system. If there is the USB keyboard only, it will be /dev/ukbd0. If you want to use the USB keyboard in the console, you have to explicitly tell the console driver to use the existing USB keyboard. This can be done by running the following command as a part of system initialization. &prompt.root; kbdcontrol -k /dev/kbd1 < /dev/ttyv0 > /dev/null Note that if the USB keyboard is the only keyboard, it is accessed as /dev/kbd0, thus, the command should look like: &prompt.root; kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null /etc/rc.i386 is a good place to add the above command. Once this is done, the USB keyboard should work in the X environment as well without any special settings. Hot-plugging and unplugging of the USB keyboard may not work quite right yet. We recommend connecting the keyboard before starting the system and leaving it connected until the system is shutdown to avoid troubles. See the &man.ukbd.4; manual page for more information. I have an unusual bus mouse. How do I set it up? FreeBSD supports the bus mouse and the InPort bus mouse from such manufactures as Microsoft, Logitech and ATI. The bus device driver is compiled in the GENERIC kernel by default in FreeBSD versions 2.X, but not included in version 3.0 or later. If you are building a custom kernel with the bus mouse driver, make sure to add the following line to the kernel config file In FreeBSD 3.0 or before, add: device mse0 at isa? port 0x23c tty irq5 vector mseintr In FreeBSD 3.X, the line should be: device mse0 at isa? port 0x23c tty irq5 And in FreeBSD 4.X and later, the line should read: device mse0 at isa? port 0x23c irq5 Bus mice usually comes with dedicated interface cards. These cards may allow you to set the port address and the IRQ number other than shown above. Refer to the manual of your mouse and the &man.mse.4; manual page for more information. How do I use my PS/2 (mouse port or keyboard) mouse? The PS/2 mouse is supported out-of-the-box in all recent versions of FreeBSD. The necessary device driver, psm, is included in the GENERIC kernel. If your custom kernel does not have this, add the appropriate following line to your kernel configuration file and compile a new kernel. In FreeBSD 3.0 or earlier, the line should be: device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr In FreeBSD 3.1 or later, the line should be: device psm0 at isa? tty irq 12 In FreeBSD 4.0 or later, the line should be: device psm0 at atkbdc? irq 12 Once the kernel detects psm0 correctly at boot time, make sure that an entry for psm0 exists in /dev. You can do this by typing: &prompt.root; cd /dev; sh MAKEDEV psm0 when logged in as root. You can omit this step if you are running FreeBSD 5.0-RELEASE or newer with &man.devfs.5; enabled, since the proper device nodes will be created automatically under /dev. 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? Once you get the mouse daemon running (see the previous section), hold down the button 1 (left button) and move the mouse to select a region of text. Then, press the 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. Does FreeBSD support any USB mice? Preliminary USB device support was added to FreeBSD 3.1. It did not always work through early versions of 3.X. As of FreeBSD 4.0, USB devices should work out of the box. If you want to experiment with the USB mouse support under FreeBSD 3.X, follow the procedure described below. Use FreeBSD 3.2 or later. Add the following lines to your kernel configuration file, and rebuild the kernel. device uhci device ohci device usb device ums In versions of FreeBSD before 4.0, use this instead: controller uhci0 controller ohci0 controller usb0 device ums0 Go to the /dev directory and create a device node as follows: &prompt.root; cd /dev &prompt.root; ./MAKEDEV ums0 You can omit this step if you are running FreeBSD 5.0-RELEASE or newer with &man.devfs.5; enabled, since the proper device nodes will be created automatically under /dev. Edit /etc/rc.conf and add the following lines: moused_enable="YES" moused_type="auto" moused_port="/dev/ums0" moused_flags="" usbd_enable="YES" usbd_flags="" See the previous section for more detailed discussion on moused. In order to use the USB mouse in the X session, edit XF86Config. If you are using XFree86 3.3.2 or later, be sure to have the following lines in the Pointer section: Device "/dev/sysmouse" Protocol "Auto" If you are using earlier versions of XFree86, be sure to have the following lines in the Pointer section: Device "/dev/sysmouse" Protocol "SysMouse" Refer to another section on the mouse support in the X environment. Hot-plugging and unplugging of the USB mouse may not work quite right yet. It is a good idea connect the mouse before you start the system and leave it connected until the system is shutdown to avoid trouble. My mouse has a fancy wheel and buttons. Can I use them in FreeBSD? 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 the mouse/trackball/touchpad on my laptop? Please refer to the answer to the previous question. Also check out the Mobile Computing page. What types of tape drives are supported? FreeBSD supports SCSI and QIC-36 (with a QIC-02 interface). This includes 8-mm (aka Exabyte) and DAT drives. Some of the early 8-mm drives are not quite compatible with SCSI-2, and may not work well with FreeBSD. Does FreeBSD support tape changers? FreeBSD 2.2 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 sound cards are supported by FreeBSD? FreeBSD supports the SoundBlaster, SoundBlaster Pro, SoundBlaster 16, Pro Audio Spectrum 16, AdLib and Gravis UltraSound sound cards. There is also limited support for MPU-401 and compatible MIDI cards. Cards conforming to the Microsoft Sound System specification are also supported through the pcm driver. This is only for sound! This driver does not support CDROMs, SCSI or joysticks on these cards, except for the SoundBlaster. The SoundBlaster SCSI interface and some non-SCSI CDROMs are supported, but you cannot boot off this device. Workarounds for no sound from es1370 with pcm driver? You can run the following command every time the machine booted up: &prompt.root; mixer pcm 100 vol 100 cd 100 Which network cards does FreeBSD support? See the Hardware Notes supplied with each release of FreeBSD for a more complete list. I do not have a math co-processor - is that bad? This will only affect 386/486SX/486SLC owners - other machines will have one built into the CPU. In general this will not cause any problems, but there are circumstances where you will take a hit, either in performance or accuracy of the math emulation code (see the section on FP emulation). In particular, drawing arcs in X will be VERY slow. It is highly recommended that you buy a math co-processor; it is well worth it. Some math co-processors are better than others. It pains us to say it, but nobody ever got fired for buying Intel. Unless you are sure it works with FreeBSD, beware of clones. What other devices does FreeBSD support? See the Handbook for the list of other devices supported. Does FreeBSD support power management on my laptop? FreeBSD supports APM on certain machines. Please look in the LINT kernel config file, searching for the APM keyword. Further information can be found in &man.apm.4;. Why does my Micron system hang at boot time? Certain Micron motherboards have a non-conforming PCI BIOS implementation that causes grief when FreeBSD boots because PCI devices do not get configured at their reported addresses. Disable the Plug and Play Operating System flag in the BIOS to work around this problem. More information can be found at http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron Why does FreeBSD not recognize my Adaptec SCSI controller card? The newer AIC789x series Adaptec chips are supported under the CAM SCSI framework which made its debut in 3.0. Patches against 2.2-STABLE are in ftp://ftp.FreeBSD.org/pub/FreeBSD/development/cam/. A CAM-enhanced boot floppy is available at http://people.FreeBSD.org/~abial/cam-boot/. In both cases read the README before beginning. Why is FreeBSD not finding my internal Plug & Play modem? You will need to add the modem's PnP ID to the PnP ID list in the serial driver. To enable Plug & Play support, compile a new kernel with controller pnp0 in the configuration file, then reboot the system. The kernel will print the PnP IDs of all the devices it finds. Copy the PnP ID from the modem to the table in /sys/i386/isa/sio.c, at about line 2777. Look for the string SUP1310 in the structure siopnp_ids[] to find the table. Build the kernel again, install, reboot, and your modem should be found. You may have to manually configure the PnP devices using the pnp command in the boot-time configuration with a command like pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8 to make the modem show. Does FreeBSD support software modems, such as Winmodems? FreeBSD supports many software modems via add-on software. The comms/ltmdm port adds support for modems based on the very popular Lucent LT chipset. The comms/mwavem port supports the modem in IBM Thinkpad 600 and 700 laptops. You cannot install FreeBSD via a software modem; this software must be installed after the OS is installed. How do I get the boot: prompt to show on the serial console? Build a kernel with options COMCONSOLE. Create /boot.config and place as the only text in the file. Unplug the keyboard from the system. See /usr/src/sys/i386/boot/biosboot/README.serial for information. Why does my 3Com PCI network card not work with my Micron computer? Certain Micron motherboards have a non-conforming PCI BIOS implementation that does not configure PCI devices at the addresses reported. This causes grief when FreeBSD boots. To work around this problem, disable the Plug and Play Operating System flag in the BIOS. More information on this problem is available at URL: - http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron + Does FreeBSD support Symmetric Multiprocessing (SMP)? SMP is supported in 3.0-STABLE and later releases only. SMP is not enabled in the GENERIC kernel, so you will have to recompile your kernel to enable SMP. Take a look at /sys/i386/conf/LINT to figure out what options to put in your kernel config file. The boot floppy hangs on a system with an ASUS K7V motherboard. How do I fix this? Go into the BIOS setup and disable the boot virus protection. Troubleshooting What do I do when I have bad blocks on my hard drive? With SCSI drives, the drive should be capable of re-mapping these automatically. However, many drives are shipped with this feature disabled, for some mysterious reason... To enable this, you will need to edit the first device page mode, which can be done on FreeBSD by giving the command (as root) &prompt.root; scsi -f /dev/rsd0c -m 1 -e -P 3 and changing the values of AWRE and ARRE from 0 to 1:- AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 The following paragraphs were submitted by Ted Mittelstaedt tedm@toybox.placo.com: For IDE drives, any bad block is usually a sign of potential trouble. All modern IDE drives come with internal bad-block remapping turned on. All IDE hard drive manufacturers today offer extensive warranties and will replace drives with bad blocks on them. If you still want to attempt to rescue an IDE drive with bad blocks, you can attempt to download the IDE drive manufacturer's IDE diagnostic program, and run this against the drive. Sometimes these programs can be set to force the drive electronics to rescan the drive for bad blocks and lock them out. For ESDI, RLL and MFM drives, bad blocks are a normal part of the drive and are no sign of trouble, generally. With a PC, the disk drive controller card and BIOS handle the task of locking out bad sectors. This is fine for operating systems like DOS that use BIOS code to access the disk. However, FreeBSD's disk driver does not go through BIOS, therefore a mechanism, bad144, exists that replaces this functionality. bad144 only works with the wd driver (which means it is not supported in FreeBSD 4.0), it is NOT able to be used with SCSI. bad144 works by entering all bad sectors found into a special file. One caveat with bad144 - the bad block special file is placed on the last track of the disk. As this file may possibly contain a listing for a bad sector that would occur near the beginning of the disk, where the /kernel file might be located, it therefore must be accessible to the bootstrap program that uses BIOS calls to read the kernel file. This means that the disk with bad144 used on it must not exceed 1024 cylinders, 16 heads, and 63 sectors. This places an effective limit of 500MB on a disk that is mapped with bad144. To use bad144, simply set the Bad Block scanning to ON in the FreeBSD fdisk screen during the initial install. This works up through FreeBSD 2.2.7. The disk must have less than 1024 cylinders. It is generally recommended that the disk drive has been in operation for at least 4 hours prior to this to allow for thermal expansion and track wandering. If the disk has more than 1024 cylinders (such as a large ESDI drive) the ESDI controller uses a special translation mode to make it work under DOS. The wd driver understands about these translation modes, IF you enter the translated geometry with the set geometry command in fdisk. You must also NOT use the dangerously dedicated mode of creating the FreeBSD partition, as this ignores the geometry. Also, even though fdisk will use your overridden geometry, it still knows the true size of the disk, and will attempt to create a too large FreeBSD partition. If the disk geometry is changed to the translated geometry, the partition MUST be manually created with the number of blocks. A quick trick to use is to set up the large ESDI disk with the ESDI controller, boot it with a DOS disk and format it with a DOS partition. Then, boot the FreeBSD install and in the fdisk screen, read off and write down the blocksize and block numbers for the DOS partition. Then, reset the geometry to the same that DOS uses, delete the DOS partition, and create a cooperative FreeBSD partition using the blocksize you recorded earlier. Then, set the partition bootable and turn on bad block scanning. During the actual install, bad144 will run first, before any filesystems are created (you can view this with an AltF2). If it has any trouble creating the badsector file, you have set too large a disk geometry - reboot the system and start all over again (including repartitioning and reformatting with DOS). If remapping is enabled and you are seeing bad blocks, consider replacing the drive. The bad blocks will only get worse as time goes on. Why does FreeBSD not recognize my Bustek 742a EISA SCSI controller? This info is specific to the 742a but may also cover other Buslogic cards. (Bustek = Buslogic) There are 2 general versions of the 742a card. They are hardware revisions A-G, and revisions H - onwards. The revision letter is located after the Assembly number on the edge of the card. The 742a has 2 ROM chips on it, one is the BIOS chip and the other is the Firmware chip. FreeBSD does not care what version of BIOS chip you have but it does care about what version of firmware chip. Buslogic will send upgrade ROMs out if you call their tech support dept. The BIOS and Firmware chips are shipped as a matched pair. You must have the most current Firmware ROM in your adapter card for your hardware revision. The REV A-G cards can only accept BIOS/Firmware sets up to 2.41/2.21. The REV H- up cards can accept the most current BIOS/Firmware sets of 4.70/3.37. The difference between the firmware sets is that the 3.37 firmware supports round robin. The Buslogic cards also have a serial number on them. If you have an old hardware revision card you can call the Buslogic RMA department and give them the serial number and attempt to exchange the card for a newer hardware revision. If the card is young enough they will do so. FreeBSD 2.1 only supports Firmware revisions 2.21 onward. If you have a Firmware revision older than this your card will not be recognized as a Buslogic card. It may be recognized as an Adaptec 1540, however. The early Buslogic firmware contains an AHA1540 emulation mode. This is not a good thing for an EISA card, however. If you have an old hardware revision card and you obtain the 2.21 firmware for it, you will need to check the position of jumper W1 to B-C, the default is A-B. Why does FreeBSD not detect my HP Netserver's SCSI controller? This is basically a known problem. The EISA on-board SCSI controller in the HP Netserver machines occupies EISA slot number 11, so all the true EISA slots are in front of it. Alas, the address space for EISA slots >= 10 collides with the address space assigned to PCI, and FreeBSD's auto-configuration currently cannot handle this situation very well. So now, the best you can do is to pretend there is no address range clash :), by bumping the kernel option EISA_SLOTS to a value of 12. Configure and compile a kernel, as described in the Handbook entry on configuring the kernel. Of course, this does present you with a chicken-and-egg problem when installing on such a machine. In order to work around this problem, a special hack is available inside UserConfig. Do not use the visual interface, but the plain command-line interface there. Simply type eisa 12 quit at the prompt, and install your system as usual. While it is recommended you compile and install a custom kernel anyway. Hopefully, future versions will have a proper fix for this problem. You cannot use a dangerously dedicated disk with an HP Netserver. See this note for more info. What is going on with my CMD640 IDE controller? It is broken. It cannot handle commands on both channels simultaneously. There is a workaround available now and it is enabled automatically if your system uses this chip. For the details refer to the manual page of the disk driver (&man.wd.4;). If you are already running FreeBSD 2.2.1 or 2.2.2 with a CMD640 IDE controller and you want to use the second channel, build a new kernel with options "CMD640" enabled. This is the default for 2.2.5 and later. I keep seeing messages like ed1: timeout. What do these messages mean? This is usually caused by an interrupt conflict (e.g., two boards using the same IRQ). FreeBSD prior to 2.0.5R used to be tolerant of this, and the network driver would still function in the presence of IRQ conflicts. However, with 2.0.5R and later, IRQ conflicts are no longer tolerated. Boot with the -c option and change the ed0/de0/... entry to match your board. If you are using the BNC connector on your network card, you may also see device timeouts because of bad termination. To check this, attach a terminator directly to the NIC (with no cable) and see if the error messages go away. Some NE2000 compatible cards will give this error if there is no link on the UTP port or if the cable is disconnected. Why did my 3COM 3C509 card stop working for no apparent reason? This card has a bad habit of losing its configuration information. Refresh your card's settings with the DOS utility 3c5x9.exe. My parallel printer is ridiculously slow. What can I do? If the only problem is that the printer is terribly slow, try changing your printer port mode as discussed in the Printer Setup section of the Handbook. 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 FreeBSD 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 FreeBSD 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. gdb 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. i.e. 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 CDROMs 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 FreeBSD, 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 FreeBSD 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 does the screen go black and lose sync when I boot? This is a known problem with the ATI Mach 64 video card. The problem is that this card uses address 2e8, and the fourth serial port does too. Due to a bug (feature?) in the &man.sio.4; driver it will touch this port even if you do not have the fourth serial port, and even if you disable sio3 (the fourth port) which normally uses this address. Until the bug has been fixed, you can use this workaround: Enter at the boot prompt. (This will put the kernel into configuration mode). Disable sio0, sio1, sio2 and sio3 (all of them). This way the sio driver does not get activated -> no problems. Type exit to continue booting. If you want to be able to use your serial ports, you will have to build a new kernel with the following modification: in /usr/src/sys/i386/isa/sio.c find the one occurrence of the string 0x2e8 and remove that string and the preceding comma (keep the trailing comma). Now follow the normal procedure of building a new kernel. Even after applying these workarounds, you may still find that the X Window System does not work properly. If this is the case, make sure that the XFree86 version you are using is at least XFree86 3.3.3 or higher. This version and upwards has built-in support for the Mach64 cards and even a dedicated X server for those cards. Why does FreeBSD only use 64 MB of RAM when my system has 128 MB of RAM installed? Due to the manner in which FreeBSD gets the memory size from the BIOS, it can only detect 16 bits worth of Kbytes in size (65535 Kbytes = 64MB) (or less... some BIOSes peg the memory size to 16M). If you have more than 64MB, FreeBSD will attempt to detect it; however, the attempt may fail. To work around this problem, you need to use the kernel option specified below. There is a way to get complete memory information from the BIOS, but we do not have room in the bootblocks to do it. Someday when lack of room in the bootblocks is fixed, we will use the extended BIOS functions to get the full memory information...but for now we are stuck with the kernel option. options "MAXMEM=n" Where n is your memory in Kilobytes. For a 128 MB machine, you would want to use 131072. Why does FreeBSD 2.0 panic with kmem_map too small!? The message may also be mb_map too small! The panic indicates that the system ran out of virtual memory for network buffers (specifically, mbuf clusters). You can increase the amount of VM available for mbuf clusters by adding: options "NMBCLUSTERS=n" to your kernel config file, where n is a number in the range 512-4096, depending on the number of concurrent TCP connections you need to support. I would recommend trying 2048 - this should get rid of the panic completely. You can monitor the number of mbuf clusters allocated/in use on the system with netstat -m (see &man.netstat.1;). The default value for NMBCLUSTERS is 512 + MAXUSERS * 16. Why do I get the error /kernel: proc: table is full? The FreeBSD kernel will only allow a certain number of processes to exist at one time. The number is based on the MAXUSERS option in the kernel configuration. MAXUSERS also affects various other in-kernel limits, such as network buffers (see this earlier question). If your machine is heavily loaded, you probably want to increase MAXUSERS. This will increase these other system limits in addition to the maximum number of processes. After FreeBSD 4.4, MAXUSERS became a tunable value that could be set with kern.maxusers in /boot/loader.conf. In earlier versions of FreeBSD, you need to adjust MAXUSERS in your kernel configuration. 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 sysctl. 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.) To make a sysctl permanent across reboots, set this in /etc/sysctl.conf in recent versions of FreeBSD, or /etc/rc.local in older versions. Why do I get an error reading CMAP busy when rebooting with a new kernel? The logic that attempts to detect an out of date /var/db/kvm_*.db files sometimes fails and using a mismatched file can sometimes lead to panics. If this happens, reboot single-user and do: &prompt.root; rm /var/db/kvm_*.db What does the message ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 mean? This is a conflict with an Ultrastor SCSI Host Adapter. During the boot process enter the kernel configuration menu and disable uha0, which is causing the problem. When I boot my system, I get the error ahc0: illegal cable configuration. My cabling is correct. What is going on? Your motherboard lacks the external logic to support automatic termination. Switch your SCSI BIOS to specify the correct termination for your configuration rather than automatic termination. The AIC7XXX driver cannot determine if the external logic for cable detection (and thus auto-termination) is available. The driver simply assumes that this support must exist if the configuration contained in the serial EEPROM is set to "automatic termination". Without the external cable detection logic the driver will often configure termination incorrectly, which can compromise the reliability of the SCSI bus. Why does Sendmail give me an error reading mail loops back to myself? This is answered in the sendmail FAQ as follows:- * I'm getting "Local configuration error" messages, such as: 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error How can I solve this problem? You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine does not recognize itself as domain.net. Add domain.net to /etc/mail/local-host-names (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" to /etc/mail/sendmail.cf. The current version of the sendmail FAQ is no longer maintained with the sendmail release. It is however regularly posted to comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers, and news.answers. You can also receive a copy via email by sending a message to mail-server@rtfm.mit.edu with the command send usenet/news.answers/mail/sendmail-faq as the body of the message. 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 FreeBSD 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 FreeBSD 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 FreeBSD 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 my machine print calcru: negative time...? This can be caused by various hardware or software ailments relating to interrupts. It may be due to bugs but can also happen by nature of certain devices. Running TCP/IP over the parallel port using a large MTU is one good way to provoke this problem. Graphics accelerators can also get you here, in which case you should check the interrupt setting of the card first. A side effect of this problem are dying processes with the message SIGXCPU exceeded cpu time limit. For FreeBSD 3.0 and later from Nov 29, 1998 forward: If the problem cannot be fixed otherwise the solution is to set this sysctl variable: &prompt.root; sysctl -w kern.timecounter.method=1 The option of &man.sysctl.8; is deprecated and silently ignored in &os; 4.4-RELEASE and all newer versions. You can safely ommit it when setting options with sysctl as shown above. This means a performance impact, but considering the cause of this problem, you probably will not notice. If the problem persists, keep the sysctl set to one and set the NTIMECOUNTER option in your kernel to increasingly large values. If by the time you have reached NTIMECOUNTER=20 the problem is not solved, interrupts are too hosed on your machine for reliable time keeping. I see pcm0 not found or my sound card is found as pcm1 but I have device pcm0 in my kernel config file. What is going on? This occurs in FreeBSD 3.X with PCI sound cards. The pcm0 device is reserved exclusively for ISA-based cards so, if you have a PCI card, then you will see this error, and your card will appear as pcm1. You cannot remove the warning by simply changing the line in the kernel config file to device pcm1 as this will result in pcm1 being reserved for ISA cards and your PCI card being found as pcm2 (along with the warning pcm1 not found). If you have a PCI sound card you will also have to make the snd1 device rather than snd0: &prompt.root; cd /dev &prompt.root; ./MAKEDEV snd1 You can omit this step if you are running FreeBSD 5.0-RELEASE or newer with &man.devfs.5; enabled, since the proper device nodes will be created automatically under /dev. This situation does not arise in FreeBSD 4.X as a lot of work has been done to make it more PnP-centric and the pcm0 device is no longer reserved exclusively for ISA cards Why is my PnP card no longer found (or found as unknown) since upgrading to FreeBSD 4.X? FreeBSD 4.X is now much more PnP-centric and this has had the side effect of some PnP devices (e.g. sound cards and internal modems) not working even though they worked under FreeBSD 3.X. The reasons for this behavior are explained by the following e-mail, posted to the freebsd-questions mailing list by Peter Wemm, in answer to a question about an internal modem that was no longer found after an upgrade to FreeBSD 4.X (the comments in [] have been added to clarify the context. The contents of this quotation has been updated from its original text.
The PNP bios preconfigured it [the modem] and left it laying around in port space, so [in 3.X] the old-style ISA probes found it there. Under 4.0, the ISA code is much more PnP-centric. It was possible [in 3.X] for an ISA probe to find a stray device and then for the PNP device id to match and then fail due to resource conflicts. So, it disables the programmable cards first so this double probing cannot happen. It also means that it needs to know the PnP id's for supported PnP hardware. Making this more user tweakable is on the TODO list.
To get the device working again requires finding its PnP id and adding it to the list that the ISA probes use to identify PnP devices. This is obtained using &man.pnpinfo.8; to probe the device, for example this is the output from &man.pnpinfo.8; for an internal modem: &prompt.root; pnpinfo Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff PnP Version 1.0, Vendor Version 0 Device Description: Pace 56 Voice Internal Plug & Play Modem Logical Device ID: PMC2430 0x3024a341 #0 Device supports I/O Range Check TAG Start DF I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8 [16-bit addr] IRQ: 4 - only one type (true/edge) [more TAG lines elided] TAG End DF End Tag Successfully got 31 resources, 1 logical fdevs -- card select # 0x0001 CSN PMC2430 (0x3024a341), Serial Number 0xffffffff Logical device #0 IO: 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 IRQ 5 0 DMA 4 0 IO range check 0x00 activate 0x01 The information you require is in the Vendor ID line at the start of the output. The hexadecimal number in parentheses (0x3024a341 in this example) is the PnP id and the string immediately before this (PMC2430) is a unique ASCII id. Alternatively, if &man.pnpinfo.8; does not list the card in question, &man.pciconf.8; can be used instead. This is part of the output from pciconf -vl for an onboard sound chip: &prompt.root; pciconf -vl chip1@pci0:31:5: class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801AA 8xx Chipset AC'97 Audio Controller' class = multimedia subclass = audio Here, you would use the chip value, 0x24158086. This information (Vendor ID or chip value) needs adding to the file /usr/src/sys/isa/sio.c. You should first make a backup of sio.c just in case things go wrong. You will also need it to make the patch to submit with your PR (you are going to submit a PR, are you not?) then edit sio.c and search for the line static struct isa_pnp_id sio_ids[] = { then scroll down to find the correct place to add the entry for your device. The entries look like this, and are sorted on the ASCII Vendor ID string which should be included in the comment to the right of the line of code along with all (if it will fit) or part of the Device Description from the output of &man.pnpinfo.8;: {0x0f804f3f, NULL}, /* OZO800f - Zoom 2812 (56k Modem) */ {0x39804f3f, NULL}, /* OZO8039 - Zoom 56k flex */ {0x3024a341, NULL}, /* PMC2430 - Pace 56 Voice Internal Modem */ {0x1000eb49, NULL}, /* ROK0010 - Rockwell ? */ {0x5002734a, NULL}, /* RSS0250 - 5614Jx3(G) Internal Modem */ Add the hexadecimal Vendor ID for your device in the correct place, save the file, rebuild your kernel, and reboot. Your device should now be found as an sio device as it was under FreeBSD 3.X Why do I get the error nlist failed when running, for example, top or systat? The problem is that the application you are trying to run is looking for a specific kernel symbol, but, for whatever reason, cannot find it; this error stems from one of two problems: Your kernel and userland are not synchronized (i.e., you built a new kernel but did not do an installworld, or vice versa), and thus the symbol table is different from what the user application thinks it is. If this is the case, simply complete the upgrade process (see /usr/src/UPDATING for the correct sequence). You are not using /boot/loader to load your kernel, but doing it directly from boot2 (see &man.boot.8;). While there is nothing wrong with bypassing /boot/loader, it generally does a better job of making the kernel symbols available to user applications. 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 FreeBSD, do this in order to, among other things, 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. What does stray IRQ mean? Stray IRQs are indications of hardware IRQ glitches, mostly from hardware that removes its interrupt request in the middle of the interrupt request acknowledge cycle. One has three options for dealing with this: Live with the warnings. All except the first 5 per irq are suppressed anyway. Break the warnings by changing 5 to 0 in isa_strayintr() so that all the warnings are suppressed. Break the warnings by installing parallel port hardware that uses irq 7 and the PPP driver for it (this happens on most systems), and install an ide drive or other hardware that uses irq 15 and a suitable driver for it. Why does file: table is full show up repeatedly in dmesg? 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 laptop keep incorrect time? Your laptop has two or more clocks, and FreeBSD has chosen to use the wrong one. Run &man.dmesg.8;, and check for lines that contain Timecounter. The last line printed is the one that FreeBSD chose, and will almost certainly be TSC. &prompt.root; dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 595573479 Hz You can confirm this by checking the kern.timecounter.hardware &man.sysctl.3;. &prompt.root; sysctl kern.timecounter.hardware kern.timecounter.hardware: TSC 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 FreeBSD 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 -w kern.timecounter.hardware=i8254 kern.timecounter.hardware: TSC -> i8254 Your laptop 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 Why did my laptop fail to correctly probe PC cards? This problem is common on laptops that boot more than one operating system. Some non-BSD operating systems leave PC card hardware in an inconsistent state. pccardd will detect the card as "(null)""(null)" instead of its actual model. You must remove all power from the PC card slot to fully reset the hardware. Completely power off the laptop. (Don't suspend it, don't let it go into standby; the power needs to be completely off.) Wait a few moments, and reboot. Your PC card should work now. Some laptop hardware lies when it claims to be off. If the above does not work shut down, remove the battery, wait a moment, replace the battery, and reboot. Why does FreeBSD's boot loader display Read error and stop after the BIOS screen? FreeBSD's boot loader is incorrectly recognizing the hard drive's geometry. This must be manually set within fdisk when creating or modifying FreeBSD's slice. The correct drive geometry values can be found within the machine's BIOS. Look for the number of cylinders, heads and sectors for the particular drive. Within &man.sysinstall.8;'s fdisk, hit G to set the drive geometry. A dialog will pop up requesting the number of cylinders, heads and sectors. Type the numbers found from the BIOS separates by forward slashes. 5000 cylinders, 250 sectors and 60 sectors would be entered as 5000/250/60 Press enter to set the values, and hit W to write the new partition table to the drive. Another operating system destroyed my Boot Manager. How do I get it back? Enter &man.sysinstall.8; and choose Configure, then Fdisk. Select the disk the Boot Manager resided on with the space key. Press W to write changes to the drive. A prompt will appear asking which boot loader to install. Select this, and it will be restored. 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 are UDMA ICRC errors, and how do I fix them? The &man.ata.4; driver reports UDMA ICRC errors when a DMA transfer to or from a drive is corrupted. The driver will retry the operation a few times. Should the retries fail, it will switch from DMA to the slower PIO mode of communication with the device. The problem can be caused by many factors, although perhaps the most common cause is faulty or incorrect cabling. Check that the ATA cables are undamaged and rated for the Ultra DMA mode in use. If you're using removable drive trays, they must also be compatible. Be sure that all connections are making good contact. Problems have also been noticed when an old drive is installed on the same ATA channel as an Ultra DMA 66 (or faster) drive. Lastly, these errors can indicate that the drive is failing. Most drive vendors provide testing software for their drives, so test your drive, and, if necessary, back up your data and replace it. The &man.atacontrol.8; utility can be used to show and select the DMA or PIO modes used for each ATA device. In particular, atacontrol mode channel will show the modes in use on a particular ATA channel, where the primary channel is numbered 0, and so on. Commercial Applications This section is still very sparse, though we are hoping, of course, that companies will add to it! :) The FreeBSD group has no financial interest in any of the companies listed here but simply lists them as a public service (and feels that commercial interest in FreeBSD can have very positive effects on FreeBSD's long-term viability). We encourage commercial software vendors to send their entries here for inclusion. See the Vendors page for a longer list. Where can I get an Office Suite for FreeBSD? The FreeBSD Mall offers a FreeBSD native version of VistaSource ApplixWare 5. ApplixWare is a rich full-featured, commercial Office Suite for FreeBSD containing a word processor, spreadsheet, presentation program, vector drawing package, and other applications. ApplixWare is offered as part of the FreeBSD Mall's BSD Desktop Edition. The Linux version of StarOffice works flawlessly on FreeBSD. The easiest way to install the Linux version of StarOffice is through the FreeBSD Ports collection. Future versions of the open-source OpenOffice suite should work as well. Where can I get Motif for FreeBSD? The Open Group has released the source code to Motif 2.1.30. You can install the open-motif package, or compile it from ports. Refer to the ports section of the Handbook for more information on how to do this. The Open Motif distribution only allows redistribution if it is running on an open source operating system. In addition, there are commercial distributions of the Motif software available. These, however, are not for free, but their license allows them to be used in closed-source software. Contact Apps2go for the least expensive ELF Motif 2.1.20 distribution for FreeBSD (either i386 or Alpha). There are two distributions, the development edition and the runtime edition (for much less). These distributions includes: OSF/Motif manager, xmbind, panner, wsm. Development kit with uil, mrm, xm, xmcxx, include and Imake files. Static and dynamic ELF libraries (for use with FreeBSD 3.0 and above). Demonstration applets. Be sure to specify that you want the FreeBSD version of Motif when ordering (do not forget to mention the architecture you want too)! Versions for NetBSD and OpenBSD are also sold by Apps2go. This is currently a FTP only download. More info Apps2go WWW page or sales@apps2go.com or support@apps2go.com or phone (817) 431 8775 or +1 817 431-8775 Contact Metro Link for an either ELF or a.out Motif 2.1 distribution for FreeBSD. This distribution includes: OSF/Motif manager, xmbind, panner, wsm. Development kit with uil, mrm, xm, xmcxx, include and Imake files. Static and dynamic libraries (specify ELF for use with FreeBSD 3.0 and later; or a.out for use with FreeBSD 2.2.8 and earlier). Demonstration applets. Preformatted manual pages. Be sure to specify that you want the FreeBSD version of Motif when ordering! Versions for Linux are also sold by Metro Link. This is available on either a CDROM or for FTP download. Contact Xi Graphics for an a.out Motif 2.0 distribution for FreeBSD. This distribution includes: OSF/Motif manager, xmbind, panner, wsm. Development kit with uil, mrm, xm, xmcxx, include and Imake files. Static and dynamic libraries (for use with FreeBSD 2.2.8 and earlier). Demonstration applets. Preformatted manual pages. Be sure to specify that you want the FreeBSD version of Motif when ordering! Versions for BSDI and Linux are also sold by Xi Graphics. This is currently a 4 diskette set... in the future this will change to a unified CD distribution like their CDE. Where can I get CDE for FreeBSD? Xi Graphics used to sell CDE for FreeBSD, but no longer do. KDE is an open source X11 desktop which is similar to CDE in many respects. You might also like the look and feel of xfce. KDE and xfce are both in the ports system. Are there any commercial high-performance X servers? Yes, Xi Graphics and Metro Link sell Accelerated-X product for FreeBSD and other Intel based systems. The Metro Link offering is a high performance X Server that offers easy configuration using the FreeBSD Package suite of tools, support for multiple concurrent video boards and is distributed in binary form only, in a convenient FTP download. Not to mention the Metro Link offering is available at the very reasonable price of $39. Metro Link also sells both ELF and a.out Motif for FreeBSD (see above). More info Metro Link WWW page or sales@metrolink.com or tech@metrolink.com or phone (954) 938-0283 or +1 954 938-0283 The Xi Graphics offering is a high performance X Server that offers easy configuration, support for multiple concurrent video boards and is distributed in binary form only, in a unified diskette distribution for FreeBSD and Linux. Xi Graphics also offers a high performance X Server tailored for laptop support. There is a free compatibility demo of version 5.0 available. Xi Graphics also sells Motif and CDE for FreeBSD (see above). More info Xi Graphics WWW page or sales@xig.com or support@xig.com or phone (800) 946 7433 or +1 303 298-7478. Are there any Database systems for FreeBSD? Yes! See the Commercial Vendors section of FreeBSD's Web site. Also see the Databases section of the Ports collection. Can I run Oracle on FreeBSD? Yes. The following pages tell you exactly how to setup Linux-Oracle on FreeBSD: http://www.scc.nl/~marcel/howto-oracle.html http://www.lf.net/lf/pi/oracle/install-linux-oracle-on-freebsd User Applications So, where are all the user applications? Please take a look at the ports page for info on software packages ported to FreeBSD. The list currently tops &os.numports; and is growing daily, so come back to check often or subscribe to the freebsd-announce mailing list for periodic updates on new entries. Most ports should be available for the 2.2, 3.X and 4.X branches, and many of them should work on 2.1.X systems as well. Each time a FreeBSD 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 gzipped 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 the package installation menu in /stand/sysinstall (under the post-configuration menu item) or invoke the &man.pkg.add.1; command on the specific package files you are interested in installing. Package files can usually be identified by their .tgz suffix and CDROM 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 FreeBSD at the following locations: for 2.2.8-RELEASE/2.2.8-STABLE ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-2.2.8/ for 3.X-RELEASE/3.X-STABLE ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/ for 4.X-RELEASE/4-STABLE ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/ for 5.X-CURRENT ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current 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. Where do I find libc.so.3.0? You are trying to run a package built on 2.2 and later on a 2.1.X system. Please take a look at the previous section and get the correct port/package for your system. Why do I get a message reading Error: can't find libc.so.4.0? You accidently downloaded packages meant for 4.X and 5.X systems and attempted to install them on your 2.X or 3.X FreeBSD system. Please download the correct version of the packages. Why does ghostscript give lots of errors with my 386/486SX? You do not have a math co-processor, right? You will need to add the alternative math emulator to your kernel; you do this by adding the following to your kernel config file and it will be compiled in. options GPL_MATH_EMULATE You will need to remove the MATH_EMULATE option when you do this. Why do SCO/iBCS2 applications bomb on socksys? (FreeBSD 3.0 and older only). You first need to edit the /etc/sysconfig (or /etc/rc.conf, see &man.rc.conf.5;) file in the last section to change the following variable to YES: # Set to YES if you want ibcs2 (SCO) emulation loaded at startup ibcs2=NO It will load the ibcs2 kernel module at startup. You will then need to set up /compat/ibcs2/dev to look like: lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 X0R@ -> /dev/null lrwxr-xr-x 1 root wheel 7 Oct 15 22:20 nfsd@ -> socksys -rw-rw-r-- 1 root wheel 0 Oct 28 12:02 null lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 socksys@ -> /dev/null crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx You just need socksys to go to /dev/null (see &man.null.4;) to fake the open & close. The code in -CURRENT will handle the rest. This is much cleaner than the way it was done before. If you want the spx driver for a local socket X connection, define SPX_HACK when you compile the system. How do I configure INN (Internet News) for my machine? After installing the news/inn package or port, an excellent place to start is Dave Barr's INN Page where you will find the INN FAQ. What version of Microsoft FrontPage should I get? Use the Port, Luke! A pre-patched version of Apache, apache13-fp, is available in the ports tree. Does FreeBSD support Java? Yes. Please see http://www.FreeBSD.org/java/. Why can I not build this port on my 3.X-STABLE machine? If you are running a FreeBSD version that lags significantly behind -CURRENT or -STABLE, you may need a ports upgrade kit from http://www.FreeBSD.org/ports/. 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. Where do I find ld.so? a.out applications like Netscape Navigator require a.out libraries. A version of FreeBSD built with ELF libraries does not install them by default. You will get complaints about not having /usr/libexec/ld.so if this is the case on your system. These libraries are available as an add-on in the compat22 distribution. Use &man.sysinstall.8; to install them. You can also install them from the FreeBSD source code: &prompt.root; cd /usr/src/lib/compat/compat22 &prompt.root; make install clean If you want to install the latest compat22 libraries whenever you run make world, edit /etc/make.conf to include COMPAT22=YES. Old compatibility libraries change rarely, if ever, so this is not generally needed. Also see the ERRATAs for 3.1-RELEASE and 3.2-RELEASE. I updated the sources, now how do I update my installed ports? FreeBSD 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. The &man.pkg.version.1; command can generate a script that will update installed ports to the latest version in the ports tree. &prompt.root; pkg_version -c > /tmp/myscript The output script must be edited by hand before you use it. Recent versions of &man.pkg.version.1; force this by inserting an &man.exit.1; at the beginning of the script. You should save the output of the script, as it will note packages that depend on the one that has been updated. These may or may not need to be updated as well. The usual case where they need to be updated is that a shared library has changed version numbers, so the ports that used that library need to be rebuilt to use the new version. Beginning with FreeBSD 5.0 (and higher revisions), &man.pkg.version.1; no longer supports the option. If you have the disk space, you can use the portupgrade tool to automate all of this. portupgrade includes various tools to simplify package handling. It is available under sysutils/portupgrade. Since it is written in Ruby, portupgrade is an unlikely candidate for integration with the main FreeBSD tree. That should not stop anyone from using it, however. If your system is up full time, the &man.periodic.8; system can be used to generate a weekly list of ports that might need updating by setting weekly_status_pkg_enable="YES" in /etc/periodic.conf. Why is /bin/sh so minimal? Why does FreeBSD not use bash or another shell? Because POSIX says that there shall be such a shell. The more complicated answer: 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, 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. In order to keep /bin/sh small, we have not provided many of the convenience features that other shells have. That is why the Ports Collection includes more featureful shells like bash, scsh, tcsh, and zsh. (You can compare for yourself the memory utilization of all these shells by looking at the VSZ and RSS columns in a ps -u listing.) Why do Netscape and Opera take so long to start? The usual answer is that DNS on your system is misconfigured. Both Netscape and Opera perform DNS checks when starting up. The browser will not appear on your desktop until the program either gets a response or determines that the system has no network connection. I updated parts of the Ports Collection using CVSup, and now many ports fail to build with mysterious error messages! What happened? Is the Ports Collection broken in some major way? If you only update parts of the Ports Collection, using one of its CVSup subcollections and not the ports-all CVSup collection, you should always update the ports-base subcollection too! The reasons are described in the Handbook. Kernel Configuration I would like to customize my kernel. Is it difficult? Not at all! Check out the kernel config section of the Handbook. We recommend that you make a dated snapshot of your new /kernel called /kernel.YYMMDD after you get it working properly. Also back up your new /modules directory to /modules.YYMMDD. That way, if you make a mistake the next time you play with your configuration you can boot the backup kernel instead of having to fall back to kernel.GENERIC. This is particularly important if you are now booting from a controller that GENERIC does not support. My kernel compiles fail because _hw_float is missing. How do I solve this problem? Let me guess. You removed npx0 (see &man.npx.4;) from your kernel configuration file because you do not have a math co-processor, right? Wrong! :-) The npx0 is MANDATORY. Even if you do not have a mathematic co-processor, you must include the npx0 device. Why is my kernel so big (over 10MB)? Chances are, you compiled your kernel in debug mode. Kernels built in debug mode contain many symbols that are used for debugging, thus greatly increasing the size of the kernel. Note that if you running a FreeBSD 3.0 or later system, there will be little or no performance decrease 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, or you simply do not want to run 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 the option. Both of the above situations 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, and you should notice a fairly large size decrease; most kernels tend to be around 1.5MB to 2MB. Why do I get interrupt conflicts with multi-port serial code? When I compile a kernel with multi-port serial code, it tells me that only the first port is probed and the rest skipped due to interrupt conflicts. How do I fix this? The problem here is that FreeBSD has code built-in to keep the kernel from getting trashed due to hardware or software conflicts. The way to fix this is to leave out the IRQ settings on all but one port. Here is an example: # # Multiport high-speed serial line - 16550 UARTS # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr 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 new 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 4.3-RELEASE on a 4.0-RELEASE system). If you are attempting an upgrade, please read the /usr/src/UPDATING file, paying particular attention to the COMMON ITEMS section at the end. You are using the new 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 FreeBSD-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 FreeBSD-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. Disks, Filesystems, and Boot Loaders How can I add my new hard disk to my FreeBSD system? See the Disk Formatting Tutorial at www.FreeBSD.org. 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. Should you decide not to do a fresh install, you need to partition and label the new disk with either /stand/sysinstall, or &man.fdisk.8; and &man.disklabel.8;. You should 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. See the formatting-media article for details on this process. 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 filesystem. 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/ad1s1a, with /mnt as the temporary mount point, it is: &prompt.root; newfs /dev/ad1s1a &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore xf - 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/ad1s1a &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore xf - &prompt.root; cd var &prompt.root; dump 0af - /var | restore xf - 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/ad1s1a &prompt.root; newfs /dev/ad1s1d &prompt.root; mount /dev/ad1s1a /mnt &prompt.root; mkdir /mnt/var &prompt.root; mount /dev/ad1s1d /mnt/var &prompt.root; cd /mnt &prompt.root; dump 0af - / | restore xf - 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. Will a dangerously dedicated disk endanger my health? The installation procedure allows you to chose two different methods in partitioning your hard disk(s). The default way makes it compatible with other operating systems on the same machine, by using fdisk table entries (called slices in FreeBSD), with a FreeBSD slice that employs partitions of its own. Optionally, one can chose to install a boot-selector to switch between the possible operating systems on the disk(s). The alternative uses the entire disk for FreeBSD, and makes no attempt to be compatible with other operating systems. So why it is called dangerous? A disk in this mode does not contain what normal PC utilities would consider a valid fdisk table. Depending on how well they have been designed, they might complain at you once they are getting in contact with such a disk, or even worse, they might damage the BSD bootstrap without even asking or notifying you. In addition, the dangerously dedicated disk's layout is known to confuse many BIOSes, including those from AWARD (e.g. as found in HP Netserver and Micronics systems as well as many others) and Symbios/NCR (for the popular 53C8xx range of SCSI controllers). This is not a complete list, there are more. Symptoms of this confusion include the read error message printed by the FreeBSD bootstrap when it cannot find itself, as well as system lockups when booting. Why have this mode at all then? It only saves a few kbytes of disk space, and it can cause real problems for a new installation. Dangerously dedicated mode's origins lie in a desire to avoid one of the most common problems plaguing new FreeBSD installers - matching the BIOS geometry numbers for a disk to the disk itself. Geometry is an outdated concept, but one still at the heart of the PC's BIOS and its interaction with disks. When the FreeBSD installer creates slices, it has to record the location of these slices on the disk in a fashion that corresponds with the way the BIOS expects to find them. If it gets it wrong, you will not be able to boot. Dangerously dedicated mode tries to work around this by making the problem simpler. In some cases, it gets it right. But it is meant to be used as a last-ditch alternative - there are better ways to solve the problem 99 times out of 100. So, how do you avoid the need for DD mode when you are installing? Start by making a note of the geometry that your BIOS claims to be using for your disks. You can arrange to have the kernel print this as it boots by specifying at the boot: prompt, or using boot -v in the loader. Just before the installer starts, the kernel will print a list of BIOS geometries. Do not panic - wait for the installer to start and then use scrollback to read the numbers. Typically the BIOS disk units will be in the same order that FreeBSD lists your disks, first IDE, then SCSI. When you are slicing up your disk, check that the disk geometry displayed in the FDISK screen is correct (ie. it matches the BIOS numbers); if it is wrong, use the g key to fix it. You may have to do this if there is absolutely nothing on the disk, or if the disk has been moved from another system. Note that this is only an issue with the disk that you are going to boot from; FreeBSD will sort itself out just fine with any other disks you may have. Once you have got the BIOS and FreeBSD agreeing about the geometry of the disk, your problems are almost guaranteed to be over, and with no need for DD mode at all. If, however, you are still greeted with the dreaded read error message when you try to boot, it is time to cross your fingers and go for it - there is nothing left to lose. To return a dangerously dedicated disk for normal PC use, there are basically two options. The first is, you write enough NULL bytes over the MBR to make any subsequent installation believe this to be a blank disk. You can do this for example with &prompt.root; dd if=/dev/zero of=/dev/rda0 count=15 Alternatively, the undocumented DOS feature C:\> fdisk /mbr will to install a new master boot record as well, thus clobbering the BSD bootstrap. Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems. Short answer: you can usually use Soft Updates safely on all partitions. Long answer: There used to be some concern over using Soft Updates on the root partition. Soft Updates has two characteristics that caused this. 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.) Also, Soft Updates can cause temporary space shortages. When using Soft Updates, the kernel can take up to thirty seconds to actually write changes to the physical disk. If you delete a large file, 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 FreeBSD filesystem, 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 or corrupted. This risk is extremely small, but generally manageable. Use of IDE write caching greatly increases this risk; it is strongly recommended that you disable IDE write caching when using Soft Updates. 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. Files such as /kernel and the contents of /etc only change during system maintenance, or when users change their passwords. 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 filesystem! / is traditionally one of the smallest partitions. By default, FreeBSD puts the /tmp directory on /. If you have a busy /tmp, you might see intermittent space problems. Symlinking /tmp to /var/tmp will solve this problem. What is inappropriate about my ccd? The symptom of this is: &prompt.root; ccdconfig -C ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format This usually happens when you are trying to concatenate the c partitions, which default to type unused. The ccd driver requires the underlying partition type to be FS_BSDFFS. Edit the disklabel of the disks you are trying to concatenate and change the types of partitions to 4.2BSD. Why can I not edit the disklabel on my ccd? The symptom of this is: &prompt.root; disklabel ccd0 (it prints something sensible here, so let us try to edit it) &prompt.root; disklabel -e ccd0 (edit, save, quit) disklabel: ioctl DIOCWDINFO: No disk label on disk; use "disklabel -r" to install initial label This is because the disklabel returned by ccd is actually a fake one that is not really on the disk. You can solve this problem by writing it back explicitly, as in: &prompt.root; disklabel ccd0 > /tmp/disklabel.tmp &prompt.root; disklabel -Rr ccd0 /tmp/disklabel.tmp &prompt.root; disklabel -e ccd0 (this will work now) Can I mount other foreign filesystems under FreeBSD? Digital UNIX UFS CDROMs can be mounted directly on FreeBSD. 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. Linux As of 2.2, FreeBSD supports ext2fs partitions. See &man.mount.ext2fs.8; for more information. NT A read-only NTFS driver was introduced in FreeBSD 3.0. For more information, see &man.mount.ntfs.8;. For older versions of FreeBSD, see the tutorial by Mark Ovens at http://ukug.uk.FreeBSD.org/~mark/ntfs_install.html. Any other information on this subject would be appreciated. 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, you need to create the special files for slice 5 in /dev, then mount /dev/da1s5: &prompt.root; cd /dev &prompt.root; sh MAKEDEV da1s5 &prompt.root; mount -t msdos /dev/da1s5 /dos/e You can omit this step if you are running FreeBSD 5.0-RELEASE or newer with &man.devfs.5; enabled. Is there a cryptographic filesystem for &os;? Yes; see the security/cfs port. How can I use the NT loader to boot FreeBSD? This procedure is slightly different for 2.2.X and 3.X (with the 3-stage boot) systems. The general idea is that you copy the first sector of your native root FreeBSD partition into a file in the DOS/NT partition. Assuming you name that file something like c:\bootsect.bsd (inspired by c:\bootsect.dos), you can then edit the c:\boot.ini file 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="FreeBSD" C:\="DOS" For 2.2.X systems this procedure assumes that DOS, NT, FreeBSD, or whatever have been installed into their respective fdisk partitions on the same disk. This example was tested on a system where DOS & NT were on the first fdisk partition, and FreeBSD on the second. FreeBSD was also set up to boot from its native partition, not the disk's MBR. Mount a DOS-formatted floppy (if you have converted to NTFS) or the FAT partition, under, say, /mnt. &prompt.root; dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1 Reboot into DOS or NT. NTFS users copy the bootsect.bsd or the bootsect.lnx file from the floppy to C:\. Modify the attributes (permissions) on boot.ini with: C:\> attrib -s -r c:\boot.ini Edit to add the appropriate entries from the example boot.ini above, and restore the attributes: C:\> attrib +s +r c:\boot.ini If FreeBSD is booting from the MBR, restore it with the DOS fdisk command after you reconfigure them to boot from their native partitions. For FreeBSD 3.X systems the procedure is somewhat simpler. If FreeBSD is installed on the same disk as the NT boot partition simply copy /boot/boot1 to C:\BOOTSECT.BSD However, if FreeBSD is installed on a different disk /boot/boot1 will not work, /boot/boot0 is needed. DO NOT SIMPLY COPY /boot/boot0 INSTEAD OF /boot/boot1, YOU WILL OVERWRITE YOUR PARTITION TABLE AND RENDER YOUR COMPUTER UN-BOOTABLE! /boot/boot0 needs to be installed using sysinstall by selecting the FreeBSD 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 sysinstall copies the partition table before copying /boot/boot0 to the MBR. When the FreeBSD 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 FreeBSD and Linux from LILO? If you have FreeBSD 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=FreeBSD (the above assumes that your FreeBSD slice is known to Linux as /dev/hda2; tailor to suit your setup). Then, run lilo as root and you should be done. If FreeBSD 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=FreeBSD In some cases you may need to specify the BIOS drive number to the FreeBSD boot loader to successfully boot off the second disk. For example, if your FreeBSD SCSI disk is probed by BIOS as BIOS disk 1, at the FreeBSD boot loader prompt you need to specify: Boot: 1:da(0,a)/kernel On FreeBSD 2.2.5 and later, you can configure &man.boot.8; to automatically do this for you at boot time. The Linux+FreeBSD mini-HOWTO is a good reference for FreeBSD and Linux interoperability issues. How do I boot FreeBSD 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 95 and Linux this is recommended anyway, to make it simpler to get Linux booting again if you should need to reinstall Windows 95 (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? Whether it is a removable drive like a ZIP or an EZ drive (or even a floppy, if you want to use it that way), or a new hard disk, once it is installed and recognized by the system, and you have your cartridge/floppy/whatever slotted in, things are pretty much the same for all devices. (this section is based on Mark Mayo's ZIP FAQ) If it is a ZIP drive or a floppy, you have already got a DOS filesystem on it, you can use a command like this: &prompt.root; mount -t msdos /dev/fd0c /floppy if it is a floppy, or this: &prompt.root; mount -t msdos /dev/da2s4 /zip for a ZIP disk with the factory configuration. For other disks, see how they are laid out using &man.fdisk.8; or &man.sysinstall.8;. The rest of the examples will be for a ZIP drive on da2, the third SCSI disk. Unless it is a floppy, or a removable you plan on sharing with other people, it is probably a better idea to stick a BSD filesystem on it. You will get long filename support, at least a 2X improvement in performance, and a lot more stability. First, you need to redo the DOS-level partitions/filesystems. You can either use &man.fdisk.8; or /stand/sysinstall, or for a small drive that you do not want to bother with multiple operating system support on, just blow away the whole FAT partition table (slices) and just use the BSD partitioning: &prompt.root; dd if=/dev/zero of=/dev/rda2 count=2 &prompt.root; disklabel -Brw da2 auto You can use disklabel or /stand/sysinstall to create multiple BSD partitions. You will certainly want to do this if you are adding swap space on a fixed disk, but it is probably irrelevant on a removable drive like a ZIP. Finally, create a new filesystem, this one is on our ZIP drive using the whole disk: &prompt.root; newfs /dev/rda2c and mount it: &prompt.root; mount /dev/da2c /zip and it is probably a good idea to add a line like this to /etc/fstab (see &man.fstab.5;) so you can just type mount /zip in the future: /dev/da2c /zip ffs rw,noauto 0 0 Why do I get Incorrect super block when mounting a CDROM? 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 CDROM? This generally means that there is no CDROM in the CDROM 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 FreeBSD? Your CDROM probably uses the Joliet extension for storing information about files and directories. This is discussed in the Handbook chapter on creating and using CDROMs, specifically the section on Using Data CDROMs. I burned a CD under FreeBSD 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 filesystem. Take a look at the Handbook chapter on creating CDROMs, 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 CDROMs, 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 filesystems. Audio CDs do not have filesystems; 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 floppies, CDROMs and other removable media? Ordinary users can be permitted to mount devices. Here is how: As root set the sysctl variable vfs.usermount to 1. &prompt.root; sysctl -w vfs.usermount=1 As root assign the appropriate permissions to the block device associated with the removable media. For example, to allow users to mount the first floppy drive, use: &prompt.root; chmod 666 /dev/fd0 To allow users in the group operator to mount the CDROM drive, use: &prompt.root; chgrp operator /dev/cd0c &prompt.root; chmod 640 /dev/cd0c Finally, add the line vfs.usermount=1 to the file /etc/sysctl.conf so that it is reset at system boot time. All users can now mount the floppy /dev/fd0 onto a directory that they own: &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t msdos /dev/fd0 ~/my-mount-point Users in group operator can now mount the CDROM /dev/cd0c onto a directory that they own: &prompt.user; mkdir ~/my-mount-point &prompt.user; mount -t cd9660 /dev/cd0c ~/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 MSDOS formatted media is to use the mtools package in the ports collection. 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 filesystem 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 filesystem 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 filesystem knows that more is still using that space. Once you end the more session, du and df will agree. 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! This situation is common on web servers. Many people set up a FreeBSD 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;. 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. 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'll 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 the option in &man.tunefs.8;. System Administration Where are the system start-up configuration files? From 2.0.5R to 2.2.1R, the primary configuration file is /etc/sysconfig. All the options are to be specified in this file and other files such as /etc/rc (see &man.rc.8;) and /etc/netstart just include it. Look in the /etc/sysconfig file and change the value to match your system. This file is filled with comments to show what to put in there. In post-2.2.1 and 3.0, /etc/sysconfig was renamed to a more self-describing &man.rc.conf.5; file and the syntax cleaned up a bit in the process. /etc/netstart was also renamed to /etc/rc.network so that all files could be copied with a cp /usr/src/etc/rc* /etc command. And, in 3.1 and later, /etc/rc.conf has been moved to /etc/defaults/rc.conf. 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 named, the DNS server included with FreeBSD in FreeBSD 3.1 or later, all you need to do is: &prompt.root; echo named_enable="YES" >> /etc/rc.conf To start up local services in FreeBSD 3.1 or later, place shell scripts in the /usr/local/etc/rc.d directory. These shell scripts should be set executable, and end with a .sh. In FreeBSD 3.0 and earlier releases, you should edit the /etc/rc.local file. The /etc/rc.serial is for serial port initialization (e.g. locking the port characteristics, and so on.). The /etc/rc.i386 is for Intel-specifics settings, such as iBCS2 emulation or the PC system console configuration. How do I add a user easily? Use the &man.adduser.8; command. For more complicated usage, the &man.pw.8; command. To remove the user again, use the &man.rmuser.8; command. Once again, &man.pw.8; will work as well. Why do I keep getting messages like root: not found after editing my crontab file? 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 FreeBSD, 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. In order 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. I made a mistake in rc.conf, or another startup file, and now I cannot edit it because the filesystem is read-only. What should I do? When you get the prompt to enter the shell pathname, simply press ENTER, and run mount / to re-mount the root filesystem in read/write mode. You may also need to run mount -a -t ufs to mount the filesystem where your favourite editor is defined. If your favourite editor is on a network filesystem, you will need to either configure the network manually before you can mount network filesystems, or use an editor which resides on a local filesystem, 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=cons25 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? Please have a look at the Handbook entry on printing. It should cover most of your problem. See the Handbook entry on printing. Some printers require a host-based driver to do any kind of printing. These so-called WinPrinters are not natively supported by FreeBSD. If your printer does not work in DOS or Windows NT 4.0, 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 do I get messages like: unknown: <PNP0303> can't assign resources on boot? The following is an excerpt from a post to the freebsd-current mailing list.
&a.wollman;, 24 April 2001 The can't assign resources messages indicate that the devices are legacy ISA devices for which a non-PnP-aware driver is compiled into the kernel. These include devices such as keyboard controllers, the programmable interrupt controller chip, and several other bits of standard infrastructure. The resources cannot be assigned because there is already a driver using those addresses.
Why can I not get user quotas to work properly? Do not turn on quotas on /, Put the quota file on the filesystem that the quotas are to be enforced on. ie: Filesystem Quota file /usr /usr/admin/quotas /home /home/admin/quotas … … Does FreeBSD support System V IPC primitives? Yes, FreeBSD supports System V-style IPC. This includes shared memory, messages and semaphores. You need to add the following lines to your kernel config to enable them. options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging In FreeBSD 3.2 and later, these options are already part of the GENERIC kernel, which means they should already be compiled into your system. Recompile and install your kernel. How do I use sendmail for mail delivery with UUCP? The sendmail configuration that ships with FreeBSD is suited for sites that connect directly to the Internet. Sites that wish to exchange their mail via UUCP must install another sendmail configuration file. Tweaking /etc/mail/sendmail.cf manually is considered something for purists. Sendmail version 8 comes with a new approach of generating config files via some &man.m4.1; preprocessing, where the actual hand-crafted configuration is on a higher abstraction level. You should use the configuration files under /usr/src/usr.sbin/sendmail/cf. If you did not install your system with full sources, the sendmail config stuff has been broken out into a separate source distribution tarball just for you. Assuming you have got your CDROM mounted, do: &prompt.root; cd /cdrom/src &prompt.root; cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail Do not panic, this is only a few hundred kilobytes in size. The file README in the cf directory can serve as a basic introduction to m4 configuration. For UUCP delivery, you are best advised to use the mailertable feature. This constitutes a database that sendmail can use to base its routing decision upon. First, you have to create your .mc file. The directory /usr/src/usr.sbin/sendmail/cf/cf is the home of these files. Look around, there are already a few examples. Assuming you have named your file foo.mc, all you need to do in order to convert it into a valid sendmail.cf is: &prompt.root; cd /usr/src/usr.sbin/sendmail/cf/cf &prompt.root; make foo.cf &prompt.root; cp foo.cf /etc/mail/sendmail.cf A typical .mc file might look like: VERSIONID(`Your version number') OSTYPE(bsd4.4) FEATURE(accept_unresolvable_domains) FEATURE(nocanonify) FEATURE(mailertable, `hash -o /etc/mail/mailertable') define(`UUCP_RELAY', your.uucp.relay) define(`UUCP_MAX_SIZE', 200000) define(`confDONT_PROBE_INTERFACES') MAILER(local) MAILER(smtp) MAILER(uucp) Cw your.alias.host.name Cw youruucpnodename.UUCP The lines containing accept_unresolvable_domains, nocanonify, and confDONT_PROBE_INTERFACES features will prevent any usage of the DNS during mail delivery. The UUCP_RELAY clause is needed for bizarre reasons, do not ask. Simply put an Internet hostname there that is able to handle .UUCP pseudo-domain addresses; most likely, you will enter the mail relay of your ISP there. Once you have got this, you need this file called /etc/mail/mailertable. If you have only one link to the outside that is used for all your mails, the following file will be enough: # # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable . uucp-dom:your.uucp.relay A more complex example might look like this: # # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom: As you can see, this is part of a real-life file. The first three lines handle special cases where domain-addressed mail should not be sent out to the default route, but instead to some UUCP neighbor in order to shortcut the delivery path. The next line handles mail to the local Ethernet domain that can be delivered using SMTP. Finally, the UUCP neighbors are mentioned in the .UUCP pseudo-domain notation, to allow for a uucp-neighbor !recipient override of the default rules. The last line is always a single dot, matching everything else, with UUCP delivery to a UUCP neighbor that serves as your universal mail gateway to the world. All of the node names behind the uucp-dom: keyword must be valid UUCP neighbors, as you can verify using the command uuname. As a reminder that this file needs to be converted into a DBM database file before being usable, the command line to accomplish this is best placed as a comment at the top of the mailertable. You always have to execute this command each time you change your mailertable. Final hint: if you are uncertain whether some particular mail routing would work, remember the option to sendmail. It starts sendmail in address test mode; simply enter 3,0, followed by the address you wish to test for the mail routing. The last line tells you the used internal mail agent, the destination host this agent will be called with, and the (possibly translated) address. Leave this mode by typing Control-D. &prompt.user; sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 foo@example.com canonify input: foo @ example . com ... parse returns: $# uucp-dom $@ your.uucp.relay $: foo < @ example . com . > > ^D How do I set up mail with a dialup connection to the 'net? If you have got a statically assigned IP number, you should not need to adjust anything from the default. Set your host name up as your assigned Internet name and sendmail will do the rest. If you have got a dynamically assigned IP number and use a dialup PPP connection to the Internet, you will probably be given a mailbox on your ISPs mail server. Lets assume your ISPs domain is example.net, and that your user name is user. Lets also assume you have called your machine bsd.home and that your ISP has told you that you may use relay.example.net as a mail relay. In order to retrieve mail from your mailbox, you will need to install a retrieval agent. Fetchmail is a good choice as it supports many different protocols. Usually, POP3 will be provided by your ISP. If you have chosen to use user-PPP, you can automatically fetch your mail when a connection to the 'net is established with the following entry in /etc/ppp/ppp.linkup: MYADDR: !bg su user -c fetchmail If you are using sendmail (as shown below) to deliver mail to non-local accounts, put the command !bg su user -c "sendmail -q" after the above shown entry. This forces sendmail to process your mailqueue as soon as the connection to the 'net is established. I am assuming that you have an account for user on bsd.home. In the home directory of user on bsd.home, create a .fetchmailrc file: poll example.net protocol pop3 fetchall pass MySecret This file should not be readable by anyone except user as it contains the password MySecret. In order to send mail with the correct from: header, you must tell sendmail to use user@example.net rather than user@bsd.home. You may also wish to tell sendmail to send all mail via relay.example.net, allowing quicker mail transmission. The following .mc file should suffice: VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home MASQUERADE_AS(`example.net')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(`SMART_HOST', `relay.example.net') Dmbsd.home define(`confDOMAIN_NAME',`bsd.home')dnl define(`confDELIVERY_MODE',`deferred')dnl Refer to the previous section for details of how to turn this .mc file into a sendmail.cf file. Also, do not forget to restart sendmail after updating sendmail.cf. What other mail-server software can I use, instead of Sendmail? Sendmail is the default mail-server software for FreeBSD, but you can easily replace it with one of the other MTA (for instance, an MTA installed from the ports). There are various alternative MTA's in the ports tree already, with mail/exim, mail/postfix, mail/qmail, 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 MTA's have already been discussed a few times. I have forgotten the root password! What do I do? Do not Panic! Simply restart the system, type boot -s at the Boot: prompt (just -s for FreeBSD releases before 3.2) 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 -u / to remount your root filesystem read/write, then run mount -a to remount all the filesystems. Run passwd root to change the root password then run &man.exit.1; to continue booting. How do I keep ControlAltDelete from rebooting the system? If you are using syscons (the default console driver) in FreeBSD 2.2.7-RELEASE or later, build and install a new kernel with the line options SC_DISABLE_REBOOT in the configuration file. If you use the PCVT console driver in FreeBSD 2.2.5-RELEASE or later, use the following kernel configuration line instead: options PCVT_CTRL_ALT_DEL For older versions of FreeBSD, edit the keymap you are using for the console and replace the boot keywords with nop. The default keymap is /usr/share/syscons/keymaps/us.iso.kbd. You may have to instruct /etc/rc.conf to load this keymap explicitly for the change to take effect. Of course if you are using an alternate keymap for your country, you should edit that one instead. How do I reformat DOS text files to Unix ones? Simply use this perl command: &prompt.user; perl -i.bak -npe 's/\r\n/\n/g' file ... file is the file(s) 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. How do I kill processes by name? Use &man.killall.1;. Why is su bugging me about not being in root's ACL? The error comes from the Kerberos distributed authentication system. The problem is not fatal but annoying. You can either run su with the -K option, or uninstall Kerberos as described in the next question. How do I uninstall Kerberos? To remove Kerberos from the system, reinstall the bin distribution for the release you are running. If you have the CDROM, you can mount the cd (we will assume on /cdrom) and run &prompt.root; cd /cdrom/bin &prompt.root; ./install.sh Alternately, you can remove all MAKE_KERBEROS options from /etc/make.conf and rebuild world. What happened to /dev/MAKEDEV? FreeBSD 5.X uses the &man.devfs.8; device-on-demand system. Device drivers automatically create new device nodes as they are needed, obsoleting /dev/MAKEDEV. If you are running FreeBSD 4.X or earlier and /dev/MAKEDEV is missing, then you really do have a problem. Grab a copy from the system source code, probably in /usr/src/etc/MAKEDEV. How do I add pseudoterminals to the system? If you have lots of telnet, ssh, X, or screen users, you will probably run out of pseudoterminals. Here is how to add more: Build and install a new kernel with the line pseudo-device pty 256 in the configuration file. Run the commands &prompt.root; cd /dev &prompt.root; sh MAKEDEV pty{1,2,3,4,5,6,7} to make 256 device nodes for the new terminals. Edit /etc/ttys and add lines for each of the 256 terminals. They should match the form of the existing entries, i.e. they look like ttyqc none network The order of the letter designations is tty[pqrsPQRS][0-9a-v], using a regular expression. Reboot the system with the new kernel and you are ready to go. Why can I not create the snd0 device? There is no snd device. The name is used as a shorthand for the various devices that make up the FreeBSD sound driver, such as mixer, sequencer, and dsp. To create these devices you should &prompt.root; cd /dev &prompt.root; sh MAKEDEV snd0 You can omit this step if you are running FreeBSD 5.0-RELEASE or newer with &man.devfs.5; enabled. 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 -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 FreeBSD, -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: FreeBSD derives its releases from one of two places. Major, dot-zero, releases, such as 3.0-RELEASE and 4.0-RELEASE, are branched from the head of the development stream, commonly referred to as -CURRENT. Minor releases, such as 3.1-RELEASE or 4.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 4.5-STABLE, its name will be changed to 4.6-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 4.6-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 (4.6-RELEASE in this example) and release branch have been made, the branch will be renamed to 4.6-STABLE. For more information on version numbers and the various CVS branches, refer to the Release Engineering article. I tried to install a new kernel, and the chflags 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: FreeBSD 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: FreeBSD 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 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 megabytes of memory? No, there is no memory leak, and it is not using 256 Mbytes of memory. It simply likes to (i.e., always does) map an obscene amount of memory into its address space for convenience. 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 256MB. 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 FreeBSD? The reason why .shosts authentication does not work by default in more recent versions of FreeBSD 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 and rebuild ssh (or run make world). As a temporary fix, change the mode on /usr/bin/ssh to 4555 by running chmod 4555 /usr/bin/ssh as root. Then add ENABLE_SUID_SSH= true to /etc/make.conf so the change takes effect the next time make world is run. 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. The X Window System and Virtual Consoles I want to run X, how do I go about it? The easiest way is to simply specify that you want to run X during the installation process. Then read and follow the documentation on the xf86config tool, which assists you in configuring XFree86 for your particular graphics card/mouse/etc. You may also wish to investigate the Xaccel server. See the section on Xi Graphics or Metro Link for more details. I tried to run X, but I get an KDENABIO failed (Operation not permitted) error when I type startx. What do I do now? Your system is running at a raised securelevel, is not it? It is, indeed, impossible to start X at a raised securelevel. To see why, look at the &man.init.8; man page. So the question is what else you should do instead, and you basically have two choices: set your securelevel back down to zero (usually from /etc/rc.conf), or run &man.xdm.1; 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 syscons (the default console driver), you can configure FreeBSD to support a mouse pointer on each virtual screen. In order to avoid conflicting with X, syscons supports a virtual device called /dev/sysmouse. All mouse events received from the real mouse device are written to the sysmouse device via moused. If you wish to use your mouse on one or more virtual consoles, and use X, see and set up moused. Then edit /etc/XF86Config and make sure you have the following lines. Section Pointer Protocol "SysMouse" Device "/dev/sysmouse" ..... The above example is for XFree86 3.3.2 or later. For earlier versions, the Protocol should be MouseSystems. 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;): &prompt.root; cd /dev &prompt.root; rm -f mouse &prompt.root; ln -s sysmouse mouse My mouse has a fancy wheel. Can I use it in X? Yes. But you need to customize X client programs. See Colas Nahaboo's web page (http://www.inria.fr/koala/colas/mouse-wheel-scroll/) . If you want to use the imwheel program, just follow these simple steps. Translate the Wheel Events The imwheel program works by translating mouse button 4 and mouse button 5 events into key events. Thus, you have to get the mouse driver to translate mouse wheel events to button 4 and 5 events. There are two ways of doing this, the first way is to have &man.moused.8; do the translation. The second way is for the X server itself to do the event translation. Using &man.moused.8; to Translate Wheel Events To have &man.moused.8; perform the event translations, simply add to the command line used to start &man.moused.8;. For example, if you normally start &man.moused.8; via moused -p /dev/psm0 you would start it by entering moused -p /dev/psm0 -z 4 instead. If you start &man.moused.8; automatically during bootup via /etc/rc.conf, you can simply add to the moused_flags variable in /etc/rc.conf. You now need to tell X that you have a 5 button mouse. To do this, simply add the line Buttons 5 to the Pointer section of /etc/XF86Config. For example, you might have the following Pointer section in /etc/XF86Config. <quote>Pointer</quote> Section for Wheeled Mouse in XFree86 3.3.x series XF86Config with moused Translation Section "Pointer" Protocol "SysMouse" Device "/dev/sysmouse" Buttons 5 EndSection <quote>InputDevice</quote> Section for Wheeled Mouse in XFree86 4.x series XF86Config with X Server Translation Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" EndSection <quote>.emacs</quote> example for naive page scrolling with Wheeled Mouse ;; wheel mouse (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) Using Your X Server to Translate the Wheel Events If you are not running &man.moused.8;, or if you do not want &man.moused.8; to translate your wheel events, you can have the X server do the event translation instead. This requires a couple of modifications to your /etc/XF86Config file. First, you need to choose the proper protocol for your mouse. Most wheeled mice use the IntelliMouse protocol. However, XFree86 does support other protocols, such as MouseManPlusPS/2 for the Logitech MouseMan+ mice. Once you have chosen the protocol you will use, you need to add a Protocol line to the Pointer section. Secondly, you need to tell the X server to remap wheel scroll events to mouse buttons 4 and 5. This is done with the ZAxisMapping option. For example, if you are not using &man.moused.8;, and you have an IntelliMouse attached to the PS/2 mouse port you would use the following in /etc/XF86Config. <quote>Pointer</quote> Section for Wheeled Mouse in <filename>XF86Config</filename> with X Server Translation Section "Pointer" Protocol "IntelliMouse" Device "/dev/psm0" ZAxisMapping 4 5 EndSection <quote>InputDevice</quote> Section for Wheeled Mouse in XFree86 4.x series XF86Config with X Server Translation Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psm0" Option "ZAxisMapping" "4 5" EndSection <quote>.emacs</quote> example for naive page scrolling with Wheeled Mouse ;; wheel mouse (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) Install imwheel Next, install imwheel from the Ports collection. It can be found in the x11 category. This program will map the wheel events from your mouse into keyboard events. For example, it might send Page Up to a program when you scroll the wheel forwards. Imwheel uses a configuration file to map the wheel events to key presses so that it can send different keys to different applications. The default imwheel configuration file is installed in /usr/X11R6/etc/imwheelrc. You can copy it to ~/.imwheelrc and then edit it if you wish to customize imwheel's configuration. The format of the configuration file is documented in &man.imwheel.1;. Configure Emacs to Work with Imwheel (optional) If you use emacs or XEmacs, then you need to add a small section to your ~/.emacs file. For emacs, add the following: <application>Emacs</application> Configuration for <application>Imwheel</application> ;;; For imwheel (setq imwheel-scroll-interval 3) (defun imwheel-scroll-down-some-lines () (interactive) (scroll-down imwheel-scroll-interval)) (defun imwheel-scroll-up-some-lines () (interactive) (scroll-up imwheel-scroll-interval)) (global-set-key [?\M-\C-\)] 'imwheel-scroll-up-some-lines) (global-set-key [?\M-\C-\(] 'imwheel-scroll-down-some-lines) ;;; end imwheel section For XEmacs, add the following to your ~/.emacs file instead: <application>XEmacs</application> Configuration for <application>Imwheel</application> ;;; For imwheel (mwheel-install) (setq mwheel-follow-mouse t) ;;; end imwheel section Run Imwheel You can just type imwheel in an xterm to start it up once it is installed. It will background itself and take effect immediately. If you want to always use imwheel, simply add it to your .xinitrc or .xsession file. You can safely ignore any warnings imwheel displays about PID files. Those warnings only apply to the Linux version of imwheel. Why do X Window menus and dialog boxes not work right? Try turning off the Num Lock key. If your Num Lock key is on by default at boot-time, you may add the following line in the Keyboard section of the XF86Config file. # Let the server do the NumLock processing. This should only be # required when using pre-R6 clients ServerNumLock 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 the Alt key and press the F2 key), 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 FreeBSD installation has three virtual consoles enabled (8 starting with 3.3-RELEASE), and AltF1, AltF2, and AltF3 will switch between these virtual consoles. To enable more of them, edit /etc/ttys (see &man.ttys.5;) and add entries for ttyv4 to ttyvc after the comment on Virtual terminals: # Edit the existing entry for ttyv3 in /etc/ttys and change # "off" to "on". ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 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 8MB RAM or less. You may also want to change the secure to insecure. 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" cons25 on secure to: ttyvb "/usr/libexec/getty Pc" cons25 off secure If your keyboard has only ten function keys, you would end up with: ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure (You could also just delete these lines.) Once you have edited /etc/ttys, the next step is to make sure that you have enough virtual terminal devices. The easiest way to do this is: &prompt.root; cd /dev &prompt.root; sh MAKEDEV vty12 On FreeBSD 5.x you do not have to create devices manually if you are using DEVFS, since the proper device nodes will be automatically created under /dev. 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/lock up after executing the kill command. How do I access the virtual consoles from X? Use Ctrl Alt Fn to switch back to a virtual console. Ctrl Alt F1 would return you to the first virtual console. Once you are back to a text console, you can then use Alt Fn 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 Alt F9 to return. How do I start XDM on boot? There are two schools of thought on how to start xdm. 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 a X.sh 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 ttys method has the advantage of documenting which vty X will start on and passing the responsibility of restarting the X server on logout to init. The rc.local method makes it easy to kill xdm if there is a problem starting the X server. If loaded from rc.local, xdm should be started without any arguments (i.e., as a daemon). xdm must start AFTER getty 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 the /usr/X11R6/lib/X11/xdm/Xservers file. :0 local /usr/X11R6/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 FreeBSD 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 /dev/ttyv0 0600 /dev/console is in /etc/fbtab (see &man.fbtab.5;) and it will ensure that whomever logs in on /dev/ttyv0 will own the console. Before, I was able to run XFree86 as a regular user. Why does it now say that I must be root? All X servers need to be run as root in order to get direct access to your video hardware. Older versions of XFree86 (<= 3.3.6) installed all bundled servers to be automatically run as root (setuid to root). This is obviously a security hazard because X servers are large, complicated programs. Newer versions of XFree86 do not install the servers setuid to root for just this reason. Obviously, running an X server as the root user is not acceptable, nor a good idea security-wise. There are two ways to be able to use X as a regular user. The first is to use xdm or another display manager (e.g., kdm); the second is to use the Xwrapper. xdm is a daemon that handles graphical logins. It is usually started at boot time, and is responsible for authenticating users and starting their sessions; it is essentially the graphical counterpart of &man.getty.8; and &man.login.1;. For more information on xdm see the XFree86 documentation, and the the FAQ entry on it. Xwrapper is the X server wrapper; it is a small utility to enable one to manually run an X server while maintaining reasonable safety. It performs some sanity checks on the command line arguments given, and if they pass, runs the appropriate X server. If you do not want to run a display manger for whatever reason, this is for you. If you have installed the complete ports collection, you can find the port in /usr/ports/x11/wrapper. Why does my PS/2 mouse misbehave under X? Your mouse and the mouse driver may have somewhat become out of synchronization. In versions 2.2.5 and earlier, switching away from X to a virtual terminal and getting back to X again may make them re-synchronized. If the problem occurs often, you may add the following option in your kernel configuration file and recompile it. options PSM_CHECKSYNC See the section on building a kernel if you have no experience with building kernels. With this option, there should be less chance of synchronization problems between the mouse and the driver. If, however, you still see the problem, click any mouse button while holding the mouse still to re-synchronize the mouse and the driver. Note that unfortunately this option may not work with all the systems and voids the tap feature of the ALPS GlidePoint device attached to the PS/2 mouse port. In versions 2.2.6 and later, synchronization check is done in a slightly better way and is standard in the PS/2 mouse driver. It should even work with GlidePoint. (As the check code has become a standard feature, PSM_CHECKSYNC option is not available in these versions.) However, 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. Enter UserConfig by giving the option at the boot prompt: boot: -c Then, in the UserConfig command line, type: UserConfig> flags psm0 0x100 UserConfig> quit Why does my PS/2 mouse from MouseSystems not work? There have been some reports that certain model of PS/2 mouse from MouseSystems works only if it is put into the high resolution mode. Otherwise, the mouse cursor may jump to the upper-left corner of the screen every so often. Unfortunately there is no workaround for versions 2.0.X and 2.1.X. In versions 2.2 through 2.2.5, apply the following patch to /sys/i386/isa/psm.c and rebuild the kernel. See the section on building a kernel if you have no experience with building kernels. @@ -766,6 +766,8 @@ if (verbose >= 2) log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n", unit, i); + set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH); + #if 0 set_mouse_scaling(sc->kbdc); /* 1:1 scaling */ set_mouse_mode(sc->kbdc); /* stream mode */ In versions 2.2.6 or later, specify the flags 0x04 to the PS/2 mouse driver to put the mouse into the high resolution mode. Enter UserConfig by giving the option at the boot prompt: boot: -c Then, in the UserConfig command line, type: UserConfig> flags psm0 0x04 UserConfig> quit See the previous section for another possible cause of mouse problems. When building an X app, imake cannot find Imake.tmpl. Where is it? Imake.tmpl is part of the Imake package, a standard X application building tool. Imake.tmpl, as well as several header files that are required to build X apps, is contained in the X prog distribution. You can install this from sysinstall or manually from the X distribution files. An X app I am building depends on XFree86 3.3.X, but I have XFree86 4.X installed. What should I do? To tell the port build to link to the XFree86 4.X libraries, add the following to /etc/make.conf, (if you do not have this file, create it): XFREE86_VERSION= 4 How do I reverse the mouse buttons? Run the command xmodmap -e "pointer = 3 2 1" from your .xinitrc or .xsession. How do I install a splash screen and where do I find them? Just prior to the release of FreeBSD 3.1, a new feature was added to allow the display of splash screens during the boot messages. The splash screens currently must be a 256 color bitmap (*.BMP) or ZSoft PCX (*.PCX) file. In addition, they must have a resolution of 320x200 or less to work on standard VGA adapters. If you compile VESA support into your kernel, then you can use larger bitmaps up to 1024x768. The actual VESA support can either be compiled directly into the kernel with the VESA kernel config option or by loading the VESA kld module during bootup. To use a splash screen, you need to modify the startup files that control the boot process for FreeBSD. The files for this changed prior to the release of FreeBSD 3.2, so there are now two ways of loading a splash screen: FreeBSD 3.1 The first step is to find a bitmap version of your splash screen. Release 3.1 only supports Windows bitmap splash screens. Once you have found your splash screen of choice copy it to /boot/splash.bmp. Next, you need to have a /boot/loader.rc file that contains the following lines: load kernel load -t splash_image_data /boot/splash.bmp load splash_bmp autoboot FreeBSD 3.2+ In addition to adding support for PCX splash screens, FreeBSD 3.2 includes a nicer way of configuring the boot process. If you wish, you can use the method listed above for FreeBSD 3.1. If you do and you want to use PCX, replace splash_bmp with splash_pcx. If, on the other hand, you want to use the newer boot configuration, you need to create a /boot/loader.rc file that contains the following lines: include /boot/loader.4th start and a /boot/loader.conf that contains the following: splash_bmp_load="YES" bitmap_load="YES" This assumes you are using /boot/splash.bmp for your splash screen. If you would rather use a PCX file, copy it to /boot/splash.pcx, create a /boot/loader.rc as instructed above, and create a /boot/loader.conf that contains: splash_pcx_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.pcx" Now all you need is a splash screen. For that you can - surf on over to the gallery at http://www.baldwin.cx/splash/. + surf on over to the gallery at + . 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 the 3 keys are 115 - Windows key, between the left-hand Ctrl and Alt keys 116 - Windows key, to the right of the AltGr key 117 - Menu key, to the left of the right-hand Ctrl key To have the left Windows key print a comma, try this. &prompt.root; xmodmap -e "keycode 115 = comma" You will probably have to re-start your window manager to see the result. To have the Windows key-mappings enabled automatically every time you start X either put the xmodmap commands in your ~/.xinitrc file or, preferably, create a file ~/.xmodmaprc and include the xmodmap options, one per line, then add the line xmodmap $HOME/.xmodmaprc to your ~/.xinitrc. 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 fvwm2, 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 XFree86 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 FreeBSD 4.7 on the Drivers section of their website. For other cards with XFree86-4, including the Matrox G200/G400, ATI Rage 128/Radeon, and 3dfx Voodoo 3, 4, 5, and Banshee, information on hardware acceleration is available on the XFree86-4 Direct Rendering on FreeBSD page. Users of XFree86 version 3.3 can use the Utah-GLX port found in graphics/utah-glx to get limited accelerated OpenGL on the Matrox Gx00, ATI Rage Pro, SiS 6326, i810, Savage, and older NVIDIA chips. Networking Where can I get information on diskless booting? Diskless booting means that the FreeBSD 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 FreeBSD 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 Win95 box to the Internet via FreeBSD? Typically, people who ask this question have two PC's at home, one with FreeBSD and one with Win95; the idea is to use the FreeBSD box to connect to the Internet and then be able to access the Internet from the Windows95 box through the FreeBSD box. This is really just a special case of the previous question. ... and the answer is yes! In FreeBSD 3.X, user-mode &man.ppp.8; contains a option. If you run &man.ppp.8; with the option, set gateway_enable to YES in /etc/rc.conf, and configure your Windows machine correctly, this should work fine. For more information, please see the &man.ppp.8; manual page. If you are using kernel-mode PPP, or have an Ethernet connection to the Internet, you will have to use &man.natd.8;. Please look at the natd section of this FAQ. Does FreeBSD support SLIP and PPP? Yes. See the manual pages for &man.slattach.8;, &man.sliplogin.8;, &man.ppp.8;, and &man.pppd.8;. &man.ppp.8; and &man.pppd.8; provide support for both incoming and outgoing connections, while &man.sliplogin.8; deals exclusively with incoming connections, and &man.slattach.8; deals exclusively with outgoing connections. For more information on how to use these, please see the Handbook chapter on PPP and SLIP. If you only have access to the Internet through a shell account, you may want to have a look at the net/slirp package. It can provide you with (limited) access to services such as ftp and http direct from your local machine. Does FreeBSD support NAT or Masquerading? If you have a local subnet (one or more local machines), but have been allocated only a single IP number from your Internet provider (or even if you receive a dynamic IP number), you may want to look at the &man.natd.8; program. &man.natd.8; allows you to connect an entire subnet to the Internet using only a single IP number. The &man.ppp.8; program has similar functionality built in via the switch. The alias library (&man.libalias.3;) is used in both cases. How do I connect two FreeBSD systems over a parallel line using PLIP? Please see the PLIP section of the Handbook. Why can I not create a /dev/ed0 device? Because they aren't necessary. In the Berkeley networking framework, network interfaces are only directly accessible by kernel code. Please see the /etc/rc.network file and the manual pages for the various network programs mentioned there for more information. If this leaves you totally confused, then you should pick up a book describing network administration on another BSD-related operating system; with few significant exceptions, administering networking on FreeBSD is basically the same as on SunOS 4.0 or Ultrix. 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 How do I get my 3C503 to use the other network port? If you want to use the other ports, you will have to specify an additional parameter on the &man.ifconfig.8; command line. The default port is link0. To use the AUI port instead of the BNC one, use link2. These flags should be specified using the ifconfig_* variables in /etc/rc.conf (see &man.rc.conf.5;). Why am I having trouble with NFS and FreeBSD? Certain PC network cards are better than others (to put it mildly) and can sometimes cause problems with network intensive applications like NFS. See the Handbook entry on NFS for more information on this topic. 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 &prompt.root; mount -o -P linuxbox:/blah /mnt Why can I not NFS-mount from a Sun box? Sun workstations running SunOS 4.X only accept mount requests from a privileged port; try &prompt.root; mount -o -P sunbox:/blah /mnt Why does mountd keep telling me it can't change attributes and that I have a bad exports list on my FreeBSD 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. Why am I having problems talking PPP to NeXTStep machines? Try disabling the TCP extensions in /etc/rc.conf (see &man.rc.conf.5;) by changing the following variable to NO: tcp_extensions=NO Xylogic's Annex boxes are also broken in this regard and you must use the above change to connect thru them. How do I enable IP multicast support? Multicast host operations are fully supported in FreeBSD 2.0 and later by default. If you want your box to run as a multicast router, you will need to recompile your kernel with the MROUTING option and run &man.mrouted.8;. FreeBSD 2.2 and later will start &man.mrouted.8; at boot time if the flag mrouted_enable is set to "YES" in /etc/rc.conf. MBONE tools are available in their own ports category, mbone. If you are looking for the conference tools vic and vat, look there! Which network cards are based on the DEC PCI chipset? Here is a list compiled by Glen Foster gfoster@driver.nsta.org, with some more modern additions: Network cards based on the DEC PCI chipset Vendor Model ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex ENET32-PCI D-Link DE-530 Dayna DP1203, DP2100 DEC DE435, DE450 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) TopWare TE-3500P Znyx (2.2.x) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348 Znyx (3.x) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd)
Why do I have to use the FQDN for hosts on my site? You will probably find that the host is actually in a different domain; for example, if you are in foo.example.org and you wish to reach a host called mumble in the example.org domain, you will have to refer to it by the fully-qualified domain name, mumble.example.org, instead of just mumble. Traditionally, this was allowed by BSD BIND resolvers. However the current version of bind (see &man.named.8;) that ships with FreeBSD no longer provides default abbreviations for non-fully qualified domain names other than the domain you are in. So an unqualified host mumble must either be found as mumble.foo.example.org, or it will be searched for in the root domain. This is different from the previous behavior, where the search continued across mumble.example.org, and mumble.edu. Have a look at RFC 1535 for why this was considered bad practice, or even a security hole. As a good workaround, you can place the line search foo.example.org example.org instead of the previous domain foo.example.org into your /etc/resolv.conf file (see &man.resolv.conf.5;). However, make sure that the search order does not go beyond the boundary between local and public administration, as RFC 1535 calls it. 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 as of 2.1.7R (this actually changed during 2.1-STABLE development) 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 FreeBSD firewall, see the Handbook section. How much overhead does IPFW incur? Please see the Handbook's Firewalls section, specifically the section on IPFW Overhead & Optimization. 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 socket package, available in the ports tree in category sysutils. 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 FreeBSD. &man.dummynet.4; is integrated into FreeBSD (or more specifically, &man.ipfw.4;); ALTQ is available for free; 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's not in your kernel. Add this to your kernel config file and build a new kernel: pseudo-device bpf # Berkeley Packet Filter After rebooting, create the device node. This can be accomplished by going to the /dev directory and running: &prompt.root; sh MAKEDEV bpf0 Please see the Handbook entry on device nodes for more information on creating devices. How do I mount a disk from a Windows machine that is on my network, like smbmount in Linux? Use the SMBFS toolset. It includes a set of kernel modifications and a set of userland programs. The programs and information are available as net/smbfs in the ports collection, or in the base system as of 4.5-RELEASE and later. What are these messages about icmp-response bandwidth limit 300/200 pps 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 -w 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 -w 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 FreeBSD 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 FreeBSD machine. I've just installed CVSup but trying to execute it produces errors. What is wrong? First, see if the error message you are receiving is like the one shown below. /usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found Errors like these are caused by installing the net/cvsup port on a machine which does not have the XFree86 suite. If you want to use the GUI included with CVSup you will need to install XFree86 now. Alternatively if you just wish to use CVSup from a command line you should delete the package previously installed. Then install the net/cvsup-without-gui port. This is covered in more detail in the CVSup section of the Handbook. 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 userid, for example. This is the definition used in the security and named man pages. Take the ntalk service, for example (see /etc/inetd.conf). This service used to run as userid root. Now it runs as userid 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. This is more hard-core. Basically 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 chroot'd (i.e. / for that process is this directory, not the real / of the system). Another common use is to mount an underlying filesystem read-only and then create a filesystem layer on top of it that gives a process a seemingly writeable view into that filesystem. 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. This is unlike Windows where a process can easily overwrite the address space of any other, leading to a crash. A Unix process is owned by a particular userid. If the userid is not the root user, it serves to firewall the process off from processes owned by other users. The userid is also used to firewall off on-disk data. What is securelevel? The securelevel is a security mechanism implemented in the kernel. Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. At the time of this writing, the securelevel mechanism is capable of, among other things, limiting 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, and alter &man.ipfirewall.4; rules. To check the status of the securelevel on a running system, simply execute the following command: &prompt.root; sysctl kern.securelevel The output will contain the name of the &man.sysctl.8; variable (in this case, kern.securelevel) and a number. The latter is 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. You cannot lower the securelevel of a running system; being able to do that 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. Some people are hopeful that securelevel will soon go away in favor of a more fine-grained mechanism, but things are still hazy in this respect. Consider yourself warned. BIND (named) is listening on port 53 and some other high-numbered port. What is going on? FreeBSD 3.0 and later use a version of BIND that uses a random high-numbered port for outgoing queries. If you want to use port 53 for outgoing queries, either to get past a firewall or to make yourself feel better, you can try the following in /etc/namedb/named.conf: options { query-source address * port 53; }; You can replace the * with a single IP address if you want to tighten things further. Congratulations, by the way. It is good practice to read your &man.sockstat.1; output and notice odd things! Sendmail 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 be to be installed in /usr/local/bin which, by default, resides on a different filesystem. If root's shell is located in /usr/local/bin and /usr (or whatever filesystem 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. Why is suidperl not working properly? For security reasons, suidperl is installed without the suid bit by default. The system administrator can enable suid behavior with the following command. &prompt.root; chmod u+s /usr/bin/suidperl If you want suidperl to be built suid during upgrades from source, edit /etc/make.conf and add ENABLE_SUIDPERL=true before you run make buildworld. 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 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 !ppp *.* /var/log/ppp.log and that the file /var/log/ppp.log exists. 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. If your version of &man.ppp.8; does not understand the set log command, you should download the latest version. It will build on FreeBSD version 2.1.5 and higher. 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 the ppp.conf.sample file. If you do not have a default route, it may be because you are running an old version of &man.ppp.8; that does not understand the word HISADDR in the ppp.conf file. If your version of &man.ppp.8; is from before FreeBSD 2.2.5, change the add 0 0 HISADDR line to one saying add 0 0 10.0.0.2 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 (this file was called /etc/sysconfig prior to release 2.2.2), and you have omitted the line saying delete ALL from ppp.conf. 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 to a missing MYADDR: delete ALL add 0 0 HISADDR section in your /etc/ppp/ppp.linkup file. 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 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 the ppp.conf file, 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. Ppp deduces that the line must therefore be bad, and disconnects. Prior to FreeBSD version 2.2.5, LQR was enabled by default. It is now disabled by default. LQR can be disabled with the line disable 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. On a USR Sportster for example, this is measured by the S10 register in tenths of a second. To make your modem more forgiving, you could add the following send-expect sequence to your dial string: set dial "...... ATS10=10 OK ......" Refer to your 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 your ppp.conf file. 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 Microsoft OS. You can enable lqr in your ppp.conf file, 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 Microsoft 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. Feel free to send the details to &a.brian;, or even to ask your ISP to contact me directly. &man.ppp.8; has hung. What can I do? Your best bet here is to rebuild &man.ppp.8; by adding CFLAGS+=-g and STRIP= to the end of the Makefile, then doing a make clean && make && make install. When &man.ppp.8; hangs, find the &man.ppp.8; process id with ps ajxww | fgrep ppp and run gdb ppp PID. From the gdb prompt, you can then use bt to get a stack trace. Send the results to &a.brian;. Why does nothing happen after the Login OK! message? Prior to FreeBSD version 2.2.5, once the link was established, &man.ppp.8; would wait for the peer to initiate the Line Control Protocol (LCP). Many ISPs will not initiate negotiations and expect the client to do so. To force &man.ppp.8; to initiate the LCP, use the following line: set openmode active It usually does no harm if both sides initiate negotiation, so openmode is now active by default. However, the next section explains when it does do some harm. 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 the 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 getty on the port, and executing &man.ppp.8; from a login script or program after login. I have also heard 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 your ppp.conf file: 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 set openmode passive command. Care should be taken with this option. You should also use the set stopped N command to limit the amount of time that &man.ppp.8; waits for the peer to begin negotiations. Alternatively, the set openmode active N command (where N is the number of seconds to wait before starting negotiations) can be used. Check the manual page for details. Why does &man.ppp.8; lock up shortly after connection? Prior to version 2.2.5 of FreeBSD, it was possible that your link was disabled shortly after connection due to &man.ppp.8; mis-handling Predictor1 compression negotiation. This would only happen if both sides tried to negotiate different Compression Control Protocols (CCP). This problem is now corrected, but if you are still running an old version of &man.ppp.8; the problem can be circumvented with the line disable pred1 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). Ppp 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. If you wish to execute commands like this, use the !bg command 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 line enable lqr LQR is accepted by default if negotiated by the peer. Why does &man.ppp.8; dial for no reason in -auto 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 Mail Configuration 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 your .mc file: define(`confDELIVERY_MODE', `d')dnl This will make sendmail queue everything until the queue is run (usually, sendmail is invoked with , telling it to run the queue every 30 minutes) or until a sendmail -q is done (perhaps from your ppp.linkup file). 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; lock up during file transfers with IO errors? Under FreeBSD 2.2.2 and before, there was a bug in the tun driver that prevents incoming packets of a size larger than the tun interface's MTU size. Receipt of a packet greater than the MTU size results in an IO error being logged via syslogd. The PPP specification says that an MTU of 1500 should always be accepted as a minimum, despite any LCP negotiations, therefore it is possible that should you decrease the MTU to less than 1500, your ISP will transmit packets of 1500 regardless, and you will tickle this non-feature - locking up your link. The problem can be circumvented by never setting an MTU of less than 1500 under FreeBSD 2.2.2 or before. Why does &man.ppp.8; not log my connection speed? In order 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? Ppp 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. In order to specify a " character, you must escape it using a backslash (\). When the chat interpreter parses each argument, it re-interprets the argument in order 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" resulting in the following sequence: ATZ OK AT\X OK or set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" resulting in the following sequence: ATZ OK ATDT1234567 Why does &man.ppp.8; get a seg-fault, but I see no ppp.core file? Ppp (or any other program for that matter) should never dump core. Because &man.ppp.8; runs with an effective user id of 0, the operating system will not write &man.ppp.8;'s core image 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 do the following: &prompt.user; tar xfz ppp-*.src.tar.gz &prompt.user; cd ppp*/ppp &prompt.user; echo STRIP= >>Makefile &prompt.user; echo CFLAGS+=-g >>Makefile &prompt.user; make clean all &prompt.user; su &prompt.root; make install &prompt.root; chmod 555 /usr/sbin/ppp 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 gdb, you may wish to find out some other bits and pieces such as what actually caused the dump and the addresses & values of the relevant variables. Why does the process that forces a dial in auto 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 auto mode. It is fixed in the latest version - search the manual page for iface. The problem was that when that initial program calls &man.connect.2;, the IP number of the tun interface is assigned to the socket endpoint. The kernel creates the first outgoing packet and writes it to the tun 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 tun 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 re-bind() 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 ioctl 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 -nat switch? The reason games and the like do not work when libalias 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 tcpdump on the tun 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 libalias. Examples of special cases can be found in /usr/src/lib/libalias/alias_*.c (alias_ftp.c is a good prototype). This usually involves reading certain recognised 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 (as in the cvsup case) 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. Has anybody made a list of useful port numbers? Not yet, but this is intended to grow into such a list (if any interest is shown). In each example, internal should be replaced with the IP number of the machine playing the game. Asheron's Call nat port udp internal :65000 65000 Manually change the port number within the game to 65000. If you have got a number of machines that you wish to play on assign a unique port number for each (i.e. 65001, 65002, etc) and add a nat port line for each one. Half Life nat port udp internal:27005 27015 PCAnywhere 8.0 nat port udp internal:5632 5632 nat port tcp internal:5631 5631 Quake nat port udp internal:6112 6112 Alternatively, you may want to take a look at www.battle.net for Quake proxy support. Quake 2 nat port udp internal:27901 27910 nat port udp internal:60021 60021 nat port udp internal:60040 60040 Red Alert nat port udp internal:8675 8675 nat port udp internal:5009 5009 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 the close lcp command (a following term command 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. Why do MacOS and Windows 98 connections freeze when running PPPoE on the gateway? Thanks to Michael Wozniak mwozniak@netcom.ca for figuring this out and Dan Flemming danflemming@mac.com for the Mac solution: This is due to what is called a Black Hole router. MacOS and Windows 98 (and maybe other Microsoft OSs) send TCP packets with a requested segment size too big to fit into a PPPoE frame (MTU is 1500 by default for Ethernet) and have the do not fragment bit set (default of TCP) and the Telco router is not sending ICMP must fragment back to the www site you are trying to load. (Alternatively, the router is sending the ICMP packet correctly, but the firewall at the www site is dropping it.) When the www server is sending you frames that do not fit into the PPPoE pipe the Telco router drops them on the floor and your page does not load (some pages/graphics do as they are smaller than a MSS.) This seems to be the default of most Telco PPPoE configurations (if only they knew how to program a router... sigh...) One fix is to use regedit on your 95/98 boxes to add the following registry entry... HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU It should be a string with a value 1436, as some ADSL routers are reported to be unable to deal with packets larger than this. This registry key has been changed to Tcpip\Parameters\Interfaces\ID for adapter\MTU in Windows 2000 and becomes a DWORD. Refer to the Microsoft Knowledge Base documents Q158474 - Windows TCPIP Registry Entries and Q120642 - TCPIP & NBT Configuration Parameters for Windows NT for more information on changing Windows MTU to work with a NAT router. Another regedit possibility under Windows 2000 is to set the Tcpip\Parameters\Interfaces\ID for adapter\EnablePMTUBHDetect DWORD to 1 as mentioned in the Microsoft document 120642 mentioned above. Unfortunately, MacOS does not provide an interface for changing TCP/IP settings. However, there is commercial software available, such as OTAdvancedTuner (OT for OpenTransport, the MacOS TCP/IP stack) by Sustainable Softworks, that will allow users to customize TCP/IP settings. MacOS NAT users should select ip_interface_MTU from the drop-down menu, enter 1450 instead of 1500 in the box, click the box next to Save as Auto Configure, and click Make Active. The latest version of &man.ppp.8; (2.3 or greater) has an enable tcpmssfixup command that will automatically adjust the MSS to an appropriate value. This facility is enabled by default. If you are stuck with an older version of &man.ppp.8;, you may want to look at the tcpmssd port. 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 the netstat -rn command (before and after connecting) to the &a.questions; or the comp.unix.bsd.freebsd.misc news group, and someone should point you in the right direction. Serial Communications This section answers common questions about serial communications with FreeBSD. PPP and SLIP are covered in the Networking section. How do I tell if FreeBSD found my serial ports? As the FreeBSD 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 the command &prompt.user; dmesg | grep sio after your system is up and running. Here is some example output from the above command: sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa 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 tell if FreeBSD found my modem cards? Refer to the answer to the previous question. I just upgraded to 2.0.5 and my tty0X are missing! How do I solve this problem? Do not worry, they have been merged with the ttydX devices. You will have to change any old configuration files you have, though. How do I access the serial ports on FreeBSD? The third serial port, sio2 (see &man.sio.4;, known as COM3 in DOS), is on /dev/cuaa2 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 cuaaX device to become inactive, and then wait for the carrier detect line to go active. When you open the cuaaX 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 cuaaX 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 kernel configuration file. But place the irq and vector 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 COM_MULTIPORT option. The following example is for an AST 4-port serial card on irq 7: options "COM_MULTIPORT" device sio4 at isa? port 0x2a0 tty flags 0x781 device sio5 at isa? port 0x2a8 tty flags 0x781 device sio6 at isa? port 0x2b0 tty flags 0x781 device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr The flags indicate that the master port has minor number 7 (0x700), diagnostics enabled during probe (0x080), and all the ports share an irq (0x001). Can FreeBSD handle multiport serial cards sharing irqs? Not yet. You will have to use a different irq for each card. Can I set the default serial parameters for a port? The ttydX (or cuaaX) device is the regular device you will want to open for your applications. When a process opens the device, it will have a default set of terminal I/O settings. You can see these settings with the command &prompt.root; stty -a -f /dev/ttyd1 When you change the settings to this device, the settings are in effect until the device is closed. When it is reopened, it goes back to the default set. To make changes to the default set, you can open and adjust the settings of the initial state device. For example, to turn on CLOCAL mode, 8 bits, and XON/XOFF flow control by default for ttyd5, do: &prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoff A good place to do this is in /etc/rc.serial. Now, an application will have these settings by default when it opens ttyd5. It can still change these settings to its liking, though. You can also prevent certain settings from being changed by an application by making adjustments to the lock state device. For example, to lock the speed of ttyd5 to 57600 bps, do &prompt.root; stty -f /dev/ttyld5 57600 Now, an application that opens ttyd5 and tries to change the speed of the port will be stuck with 57600 bps. Naturally, you should make the initial state and lock state devices writable only by root. The &man.MAKEDEV.8; script does NOT do this when it creates the device entries. How can I enable dialup logins on my modem? So you want to become an Internet service provider, eh? First, you will need one or more modems that can auto-answer. Your modem will need to assert carrier-detect when it detects a carrier and not assert it all the time. It will need to hang up the phone and reset itself when the data terminal ready (DTR) line goes from on to off. It should probably use RTS/CTS flow control or no local flow control at all. Finally, it must use a constant speed between the computer and itself, but (to be nice to your callers) it should negotiate a speed between itself and the remote modem. For many Hayes command-set--compatible modems, this command will make these settings and store them in nonvolatile memory: AT &C1 &D3 &K3 &Q6 S0=1 &W See the section on sending AT commands below for information on how to make these settings without resorting to an MS-DOS terminal program. Next, make an entry in /etc/ttys (see &man.ttys.5;) for the modem. This file lists all the ports on which the operating system will await logins. Add a line that looks something like this: ttyd1 "/usr/libexec/getty std.57600" dialup on insecure This line indicates that the second serial port (/dev/ttyd1) has a modem connected running at 57600 bps and no parity (std.57600, which comes from the file /etc/gettytab, see &man.gettytab.5;). The terminal type for this port is dialup. The port is on and is insecure---meaning root logins on the port are not allowed. For dialin ports like this one, use the ttydX entry. It is common practice to use dialup as the terminal type. Many users set up in their .profile or .login files a prompt for the actual terminal type if the starting type is dialup. The example shows the port as insecure. To become root on this port, you have to login as a regular user, then &man.su.1; to become root. If you use secure then root can login in directly. After making modifications to /etc/ttys, you need to send a hangup or HUP signal to the &man.init.8; process: &prompt.root; kill -HUP 1 This forces the &man.init.8; process to reread /etc/ttys. The init process will then start getty processes on all on ports. You can find out if logins are available for your port by typing &prompt.user; ps -ax | grep '[t]tyd1' You should see something like: 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 How can I connect a dumb terminal to my FreeBSD box? If you are using another computer as a terminal into your FreeBSD system, get a null modem cable to go between the two serial ports. If you are using an actual terminal, see its accompanying instructions. Then, modify /etc/ttys (see &man.ttys.5;), like above. For example, if you are hooking up a WYSE-50 terminal to the fifth serial port, use an entry like this: ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure This example shows that the port on /dev/ttyd4 has a wyse50 terminal connected at 38400 bps with no parity (std.38400 from /etc/gettytab, see &man.gettytab.5;) and root logins are allowed (secure). Why can I not run tip or cu? On your system, the programs &man.tip.1; and &man.cu.1; are probably executable only by 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 My stock Hayes modem is not supported---what can I do? Actually, the manual page for &man.tip.1; is out of date. There is a generic Hayes dialer already built in. Just use at=hayes in your /etc/remote (see &man.remote.5;) file. The Hayes driver is not smart enough to recognize some of the advanced features of newer modems---messages like BUSY, NO DIALTONE, or CONNECT 115200 will just confuse it. You should turn those messages off when you use &man.tip.1; (using ATX0&W). Also, the dial timeout for &man.tip.1; is 60 seconds. Your modem should use something less, or else tip will think there is a communication problem. Try ATS7=45&W. Actually, as shipped &man.tip.1; does not yet support it fully. The solution is to edit the file tipconf.h in the directory /usr/src/usr.bin/tip/tip. Obviously you need the source distribution to do this. Edit the line #define HAYES 0 to #define HAYES 1. Then make and make install. Everything works nicely after that. How am I expected to enter these AT commands? Make what is called a direct entry in your /etc/remote file (see &man.remote.5;). For example, if your modem is hooked up to the first serial port, /dev/cuaa0, then put in the following line: cuaa0:dv=/dev/cuaa0:br#19200:pa=none Use the highest bps rate your modem supports in the br capability. Then, type tip cuaa0 (see &man.tip.1;) and you will be connected to your modem. If there is no /dev/cuaa0 on your system, do this: &prompt.root; cd /dev &prompt.root; sh MAKEDEV cuaa0 Or use cu as root with the following command: &prompt.root; cu -lline -sspeed with line being the serial port (e.g. /dev/cuaa0) and speed being the speed (e.g.57600). When you are done entering the AT commands hit ~. to exit. Why does the <@> sign for the pn capability not work? The <@> sign in the phone number capability tells tip to look in /etc/phones for a phone number. But the <@> sign is also a special character in capability files like /etc/remote. Escape it with a backslash: pn=\@ How can I dial a phone number on the command line? Put what is called a generic entry in your /etc/remote file (see &man.remote.5;). For example: tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: Then you can do something like tip -115200 5551234. If you prefer &man.cu.1; over &man.tip.1;, use a generic cu entry: cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: and type cu 5551234 -s 115200. Do I have to type in the bps rate every time I do that? Put in an entry for tip1200 or cu1200, but go ahead and use whatever bps rate is appropriate with the br capability. &man.tip.1; thinks a good default is 1200 bps which is why it looks for a tip1200 entry. You do not have to use 1200 bps, though. How can I more easily access a number of hosts through a terminal server? Rather than waiting until you are connected and typing CONNECT host each time, use tip's cm capability. For example, these entries in /etc/remote (see &man.remote.5;): pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234: will let you type tip pain or tip muffin to connect to the hosts pain or muffin; and tip deep13 to get to the terminal server. Can tip try more than one line for each site? This is often a problem where a university has several modem lines and several thousand students trying to use them... Make an entry for your university in /etc/remote (see &man.remote.5;) and use <\@> for the pn capability: big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: Then, list the phone numbers for the university in /etc/phones (see &man.phones.5;): big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 &man.tip.1; will try each one in the listed order, then give up. If you want to keep retrying, run &man.tip.1; in a while loop. Why do I have to hit CTRLP twice to send CTRLP once? CTRLP is the default force character, used to tell &man.tip.1; that the next character is literal data. You can set the force character to any other character with the ~s escape, which means set a variable. Type ~sforce=single-char followed by a newline. single-char is any single character. If you leave out single-char, then the force character is the nul character, which you can get by typing CTRL2 or CTRLSPACE. A pretty good value for single-char is SHIFTCTRL6, which I have seen only used on some terminal servers. You can have the force character be whatever you want by specifying the following in your $HOME/.tiprc file: force=single-char Why is everything I type suddenly in UPPER CASE? You must have pressed CTRLA, &man.tip.1; raise character, specially designed for people with broken Caps Lock keys. Use ~s as above and set the variable raisechar to something reasonable. In fact, you can set it to the same as the force character, if you never expect to use either of these features. Here is a sample .tiprc file perfect for Emacs users who need to type CTRL2 and CTRLA a lot: force=^^ raisechar=^^ The ^^ is SHIFTCTRL6. How can I do file transfers with tip? If you are talking to another Unix system, you can send and receive files with ~p (put) and ~t (take). These commands run &man.cat.1; and &man.echo.1; on the remote system to accept and send files. The syntax is: ~p <local-file> [<remote-file>] ~t <remote-file> [<local-file>] There is no error checking, so you probably should use another protocol, like zmodem. How can I run zmodem with tip? First, install one of the zmodem programs from the ports collection (such as one of the two from the comms category, lrzsz or rzsz. To receive files, start the sending program on the remote end. Then, press enter and type ~C rz (or ~C lrz if you installed lrzsz) to begin receiving them locally. To send files, start the receiving program on the remote end. Then, press enter and type ~C sz files (or ~C lsz files) to send them to the remote system. Why does FreeBSD not find my serial ports, even when the settings are correct? Motherboards and cards with Acer UARTs do not probe properly under the FreeBSD sio probe. Obtain a patch from www.lemis.com to fix your problem. Miscellaneous Questions FreeBSD uses far more swap space than Linux. Why? FreeBSD only appears to use more swap than Linux. In actual fact, it does not. The main difference between FreeBSD and Linux in this regard is that FreeBSD will proactively move entirely idle, unused pages of main memory into swap in order to make more main memory available for active use. Linux tends to only move pages to swap as a last resort. The perceived heavier use of swap is balanced by the more efficient use of main memory. Note that while FreeBSD 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 FreeBSD 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 use (what are) a.out and ELF executable formats? To understand why FreeBSD uses the ELF format, you must first know a little about the 3 currently dominant executable formats for Unix: Prior to FreeBSD 3.X, FreeBSD used the a.out format. &man.a.out.5; The oldest and classic Unix object format. It uses a short and compact header with a magic number at the beginning that is often used to characterize the format (see &man.a.out.5; for more details). It contains three loaded segments: .text, .data, and .bss plus a symbol table and a string table. COFF The SVR3 object format. The header now comprises a section table, so you can have more than just .text, .data, and .bss sections. ELF The successor to COFF, featuring Multiple sections and 32-bit or 64-bit possible values. One major drawback: ELF was also designed with the assumption that there would be only one ABI per system architecture. That assumption is actually quite incorrect, and not even in the commercial SYSV world (which has at least three ABIs: SVR4, Solaris, SCO) does it hold true. FreeBSD tries to work around this problem somewhat by providing a utility for branding a known ELF executable with information about the ABI it is compliant with. See the manual page for &man.brandelf.1; for more information. FreeBSD comes from the classic camp and has traditionally used the &man.a.out.5; format, a technology tried and proven through many generations of BSD releases. Though it has also been possible for some time to build and run native ELF binaries (and kernels) on a FreeBSD system, FreeBSD initially resisted the push to switch to ELF as the default format. Why? Well, when the Linux camp made their painful transition to ELF, it was not so much to flee the a.out executable format as it was their inflexible jump-table based shared library mechanism, which made the construction of shared libraries very difficult for vendors and developers alike. Since the ELF tools available offered a solution to the shared library problem and were generally seen as the way forward anyway, the migration cost was accepted as necessary and the transition made. In FreeBSD's case, our shared library mechanism is based more closely on Sun's SunOS-style shared library mechanism and, as such, is very easy to use. However, starting with 3.0, FreeBSD officially supports ELF binaries as the default format. Even though the a.out executable format has served us well, the GNU people, who author the compiler tools we use, have dropped support for the a.out format. This has forced us to maintain a divergent version of the compiler and linker, and has kept us from reaping the benefits of the latest GNU development efforts. Also the demands of ISO-C++, notably constructors and destructors, has also led to native ELF support in future FreeBSD releases. Yes, but why are there so many different formats? Back in the dim, dark past, there was simple hardware. This simple hardware supported a simple, small system. a.out was completely adequate for the job of representing binaries on this simple system (a PDP-11). As people ported Unix from this simple system, they retained the a.out format because it was sufficient for the early ports of Unix to architectures like the Motorola 68k, VAXen, etc. Then some bright hardware engineer decided that if he could force software to do some sleazy tricks, then he would be able to shave a few gates off the design and allow his CPU core to run faster. While it was made to work with this new kind of hardware (known these days as RISC), a.out was ill-suited for this hardware, so many formats were developed to get to a better performance from this hardware than the limited, simple a.out format could offer. Things like COFF, ECOFF, and a few obscure others were invented and their limitations explored before things seemed to settle on ELF. In addition, program sizes were getting huge and disks (and physical memory) were still relatively small so the concept of a shared library was born. The VM system also became more sophisticated. While each one of these advancements was done using the a.out format, its usefulness was stretched more and more with each new feature. In addition, people wanted to dynamically load things at run time, or to junk parts of their program after the init code had run to save in core memory and swap space. Languages became more sophisticated and people wanted code called before main automatically. Lots of hacks were done to the a.out format to allow all of these things to happen, and they basically worked for a time. In time, a.out was not up to handling all these problems without an ever increasing overhead in code and complexity. While ELF solved many of these problems, it would be painful to switch from the system that basically worked. So ELF had to wait until it was more painful to remain with a.out than it was to migrate to ELF. However, as time passed, the build tools that FreeBSD derived their build tools from (the assembler and loader especially) evolved in two parallel trees. The FreeBSD tree added shared libraries and fixed some bugs. The GNU folks that originally write these programs rewrote them and added simpler support for building cross compilers, plugging in different formats at will, etc. Since many people wanted to build cross compilers targeting FreeBSD, they were out of luck since the older sources that FreeBSD had for as and ld were not up to the task. The new gnu tools chain (binutils) does support cross compiling, ELF, shared libraries, C++ extensions, etc. In addition, many vendors are releasing ELF binaries, and it is a good thing for FreeBSD to run them. And if it is running ELF binaries, why bother having a.out any more? It is a tired old horse that has proven useful for a long time, but it is time to turn him out to pasture for his long, faithful years of service. ELF is more expressive than a.out and will allow more extensibility in the base system. The ELF tools are better maintained, and offer cross compilation support, which is important to many people. ELF may be a little slower than a.out, but trying to measure it can be difficult. There are also numerous details that are different between the two in how they map pages, handle init code, etc. None of these are very important, but they are differences. In time support for a.out will be moved out of the GENERIC kernel, and eventually removed from the kernel once the need to run legacy a.out programs is past. Why will chmod not change the permissions on symlinks? Symlinks do not have permissions, and by default, &man.chmod.1; will not follow symlinks to change the permissions on the target file. 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 foo will not have changed. You have to use either or together with the option to make this work. See the &man.chmod.1; and &man.symlink.7; manual pages for more info. The option 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. Why are login names restricted to 8 characters or less in FreeBSD 2.2.X and earlier? You would think it would be easy enough to change UT_NAMESIZE and rebuild the whole world, and everything would just work. Unfortunately there are often scads of applications and utilities (including system tools) that have hard-coded small numbers (not always 8 or 9, but oddball ones like 15 and 20) in structures and buffers. Not only will this get you log files which are trashed (due to variable-length records getting written when fixed records were expected), but it can break Suns NIS clients and potentially cause other problems in interacting with other Unix systems. In FreeBSD 3.0 and later, the maximum name length has been increased to 16 characters and those various utilities with hard-coded name sizes have been found and fixed. The fact that this touched so many areas of the system is why, in fact, the change was not made until 3.0. If you are absolutely confident in your ability to find and fix these sorts of problems for yourself when and if they pop up, you can increase the login name length in earlier releases by editing /usr/include/utmp.h and changing UT_NAMESIZE accordingly. You must also update MAXLOGNAME in /usr/include/sys/param.h to match the UT_NAMESIZE change. Finally, if you build from sources, do not forget that /usr/include is updated each time! Change the appropriate files in /usr/src/.. instead. Can I run DOS binaries under FreeBSD? Yes, starting with version 3.0 you can use BSDI's doscmd DOS emulation which has been integrated and enhanced. Send mail to the &a.emulation; if you are interested in joining this ongoing effort! For pre-3.0 systems, there is a neat utility called pcemu in the ports collection which emulates an 8088 and enough BIOS services to run DOS text mode applications. It requires the X Window System (provided as XFree86). What do I need to do to translate a FreeBSD document into my native language? See the Translation FAQ in the FreeBSD Documentation Project Primer. Why does my email to any address at FreeBSD.org bounce? The FreeBSD.org mail system implements some of the stricter Postfix checks on incoming mail and rejects mail that is either misconfigured or is potential spam. Your mail might bounce for one of the following reasons: The email is being sent from a known spam domain or IP block. The FreeBSD mail servers reject email from known spam sources. If you have service through a company or domain who generates or relays spam, please switch to a service provider who does not. The body of the email only contains HTML. Mail should be sent in plain text only. Please configure your mail user agent to send plain text. The mailer at FreeBSD.org cannot resolve the IP address of the connecting host back to a symbolic name. Working reverse DNS is a standard requirement for accepting mail from a host. Set up reverse DNS for your mail server's IP address. Many home services (DSL, cable, dialup, etc.) will not give you this option. In this case, relay your email through your service provider's mail server. The hostname given in the EHLO/HELO part of the SMTP exchange cannot be resolved to an IP address. A fully qualified, resolvable host name is necessary in this part of the SMTP dialogue before mail will be accepted. If you do not have a host name that is registered in the DNS, then you should use your service provider's mail server to relay your mail. Your message had a message ID ending with the string localhost. Some mail user agents generate bad message IDs which will not be accepted. You will need to persuade your mail user agent to generate a valid message ID or else configure your mail transfer agent to rewrite them. Where can I find a free FreeBSD account? While FreeBSD 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 FreeBSD. M-Net can be accessed via telnet and SSH and provides basic access to the entire FreeBSD 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. Grex provides a site very similar to M-Net including the same bulletin board and interactive chat software. However, the machine is a Sun 4M and is running SunOS What is sup, and how do I use it? SUP stands for Software Update Protocol, and was developed by CMU for keeping their development trees in sync. We used it to keep remote sites in sync with our central development sources. SUP is not bandwidth friendly, and has been retired. The current recommended method to keep your sources up to date is CVSup 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 Kirk McKusick. 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/. What does MFC mean? MFC is an acronym for Merged From -CURRENT. It is used in the CVS logs to denote when a change was migrated from the CURRENT to the STABLE branches. What does BSD mean? It stands for something in a secret language that only members can know. It does not translate literally but its ok to tell you that BSD's translation is something between, Formula-1 Racing Team, Penguins are tasty snacks, and We have a better sense of humor than Linux. :-) Seriously, BSD is an acronym for Berkeley Software Distribution, which is the name the Berkeley CSRG (Computer Systems Research Group) chose for their Unix distribution way back when. What does POLA mean? Principle of Least Astonishment. It means that as FreeBSD evolves, changes visible to the user should be kept as unsurprising as possible. For example, arbitrarily rearranging system startup variables in /etc/defaults/rc.conf violates POLA. Developers consider POLA when contemplating user-visible system changes. What is a repo-copy? A repo-copy (which is a short form of repository copy) refers to the direct copying of files within the CVS repository. Without a repo-copy, if a file needed to be copied or moved to another place in the repository, the committer would run cvs add to put the file in its new location, and then cvs rm on the old file if the old copy was being removed. The disadvantage of this method is that the history (i.e. the entries in the CVS logs) of the file would not be copied to the new location. As the FreeBSD Project considers this history very useful, a repository copy is often used instead. This is a process where one of the repository meisters will copy the files directly within the repository, rather than using the &man.cvs.1; program. 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 entitled A bike shed (any colour will do) on greener grass.... The appropriate portions of that message are quoted below.
&a.phk; on freebsd-hackers, 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 FreeBSD Funnies How cool is FreeBSD? Q. Has anyone done any temperature testing while running FreeBSD? I know Linux runs cooler than DOS, but have never seen a mention of FreeBSD. 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 FreeBSD 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, both FreeBSD and Linux use the HLT (halt) instruction when the system is idle thus lowering its energy consumption and therefore the heat it generates. Also if you have APM (advanced power management) configured, then FreeBSD can also put the CPU into a low power mode. Who is scratching in my memory banks?? Q. Is there anything odd that FreeBSD 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 FreeBSD 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 cvsupped 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 FreeBSD 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 FreeBSD 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 FreeBSD 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: 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 :-) 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 practise 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 categorised by the type of hat they wear (red, green or blue) and will hide or appear (thereby showing the colour 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. Advanced Topics How can I learn more about FreeBSD's internals? At this time, there is no book on FreeBSD-specific OS internals. Much general &unix; knowledge is directly applicable to FreeBSD, however. Additionally, there are BSD-specific books that are still relevant. For a list, please check the Handbook's Operating System Internals Bibliography. How can I contribute to FreeBSD? Please see the article on Contributing to FreeBSD for specific advice on how to do this. Assistance is more than welcome! What are SNAPs and RELEASEs? There are currently three active/semi-active branches in the FreeBSD CVS Repository (the RELENG_2 branch is probably only changed twice a year, which is why there are only three active branches of development): RELENG_2_2 AKA 2.2-STABLE RELENG_3 AKA 3.X-STABLE RELENG_4 AKA 4-STABLE HEAD AKA -CURRENT AKA 5.0-CURRENT HEAD is not an actual branch tag, like the other two; 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 5.0 development stream and the 4-STABLE branch, RELENG_4, forked off from -CURRENT in Mar 2000. The 2.2-STABLE branch, RELENG_2_2, departed -CURRENT in November 1996, and has pretty much been retired. How do I make my own custom release? Please see the Release Engineering article. Why does make world clobber my existing installed binaries? Yes, this is the general idea; as its name might suggest, make world rebuilds every system binary from scratch, so you can be certain of having a clean and consistent environment at the end (which is why it takes so long). If the environment variable DESTDIR is defined while running make world or make install, the newly-created binaries will be deposited in a directory tree identical to the installed one, rooted at ${DESTDIR}. Some random combination of shared libraries modifications and program rebuilds can cause this to fail in make world however. Why does my system say (bus speed defaulted) when it boots? The Adaptec 1542 SCSI host adapters allow the user to configure their bus access speed in software. Previous versions of the 1542 driver tried to determine the fastest usable speed and set the adapter to that. We found that this breaks some users' systems, so you now have to define the TUNE_1542 kernel configuration option in order to have this take place. Using it on those systems where it works may make your disks run faster, but on those systems where it does not, your data could be corrupted. Can I follow -CURRENT with limited Internet access? Yes, you can do this without downloading the whole source tree by using the CTM facility. How did you split the distribution into 240k files? Newer BSD based systems have a option to split that allows them to split files on arbitrary byte boundaries. Here is an example from /usr/src/Makefile. bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) I have written a kernel extension, who do I send it to? Please take a look at the article on Contributing to FreeBSD to learn how to submit code. And thanks for the thought! How are Plug N Play ISA cards detected and initialized? By: Frank Durda IV uhclem@nemesis.lonestar.org In a nutshell, there a few I/O ports that all of the PnP boards respond to when the host asks if anyone is out there. So when the PnP probe routine starts, it asks if there are any PnP boards present, and all the PnP boards respond with their model # to a I/O read of the same port, so the probe routine gets a wired-OR yes to that question. At least one bit will be on in that reply. Then the probe code is able to cause boards with board model IDs (assigned by Microsoft/Intel) lower than X to go off-line. It then looks to see if any boards are still responding to the query. If the answer was 0, then there are no boards with IDs above X. Now probe asks if there are any boards below X. If so, probe knows there are boards with a model numbers below X. Probe then asks for boards greater than X-(limit/4) to go off-line. If repeats the query. By repeating this semi-binary search of IDs-in-range enough times, the probing code will eventually identify all PnP boards present in a given machine with a number of iterations that is much lower than what 2^64 would take. The IDs are two 32-bit fields (hence 2ˆ64) + 8 bit checksum. The first 32 bits are a vendor identifier. They never come out and say it, but it appears to be assumed that different types of boards from the same vendor could have different 32-bit vendor ids. The idea of needing 32 bits just for unique manufacturers is a bit excessive. The lower 32 bits are a serial #, Ethernet address, something that makes this one board unique. The vendor must never produce a second board that has the same lower 32 bits unless the upper 32 bits are also different. So you can have multiple boards of the same type in the machine and the full 64 bits will still be unique. The 32 bit groups can never be all zero. This allows the wired-OR to show non-zero bits during the initial binary search. Once the system has identified all the board IDs present, it will reactivate each board, one at a time (via the same I/O ports), and find out what resources the given board needs, what interrupt choices are available, etc. A scan is made over all the boards to collect this information. This info is then combined with info from any ECU files on the hard disk or wired into the MLB BIOS. The ECU and BIOS PnP support for hardware on the MLB is usually synthetic, and the peripherals do not really do genuine PnP. However by examining the BIOS info plus the ECU info, the probe routines can cause the devices that are PnP to avoid those devices the probe code cannot relocate. Then the PnP devices are visited once more and given their I/O, DMA, IRQ and Memory-map address assignments. The devices will then appear at those locations and remain there until the next reboot, although there is nothing that says you cannot move them around whenever you want. There is a lot of oversimplification above, but you should get the general idea. Microsoft took over some of the primary printer status ports to do PnP, on the logic that no boards decoded those addresses for the opposing I/O cycles. I found a genuine IBM printer board that did decode writes of the status port during the early PnP proposal review period, but MS said tough. So they do a write to the printer status port for setting addresses, plus that use that address + 0x800, and a third I/O port for reading that can be located anywhere between 0x200 and 0x3ff. Can you assign a major number for a device driver I have written? This depends on whether or not you plan on making the driver publicly available. If you do, then please send us a copy of the driver source code, plus the appropriate modifications to files.i386, a sample configuration file entry, and the appropriate &man.MAKEDEV.8; code to create any special files your device uses. If you do not, or are unable to because of licensing restrictions, then character major number 32 and block major number 8 have been reserved specifically for this purpose; please use them. In any case, we would appreciate hearing about your driver on &a.hackers;. What about alternative layout policies for directories? In answer to the question of alternative layout policies for directories, the scheme that is currently in use is unchanged from what I wrote in 1983. I wrote that policy for the original fast filesystem, and never revisited it. It works well at keeping cylinder groups from filling up. As several of you have noted, it works poorly for find. Most filesystems are created from archives that were created by a depth first search (aka ftw). These directories end up being striped across the cylinder groups thus creating a worst possible scenario for future depth first searches. If one knew the total number of directories to be created, the solution would be to create (total / fs_ncg) per cylinder group before moving on. Obviously, one would have to create some heuristic to guess at this number. Even using a small fixed number like say 10 would make an order of magnitude improvement. To differentiate restores from normal operation (when the current algorithm is probably more sensible), you could use the clustering of up to 10 if they were all done within a ten second window. Anyway, my conclusion is that this is an area ripe for experimentation. Kirk McKusick, September 1998 How can I make the most of the data I see when my kernel panics? [This section was extracted from a mail written by &a.wpaul; on the freebsd-current mailing list by &a.des;, who fixed a few typos and added the bracketed comments] From: Bill Paul <wpaul@skynet.ctr.columbia.edu> Subject: Re: the fs fun never stops To: Ben Rosengart Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT) Cc: current@FreeBSD.org Ben Rosengart posted the following panic message] > 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 that I highlighted up there 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 -n /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 -n /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. I see people constantly show panic messages like this but rarely do I see someone take the time to match up the instruction pointer with a function in the kernel symbol table. The best way to track down the cause of a panic is by capturing a crash dump, then using &man.gdb.1; to generate a stack trace on the crash dump. In any case, the method I normally use is this: Set up a kernel config file, optionally adding options DDB if you think you need the kernel debugger for something. (I use this mainly for setting breakpoints if I suspect an infinite loop condition of some kind.) Use config -g KERNELCONFIG to set up the build directory. cd /sys/compile/ KERNELCONFIG; make Wait for kernel to finish compiling. make install reboot The &man.make.1; process will have built two kernels. kernel and kernel.debug. kernel was installed as /kernel, while kernel.debug can be used as the source of debugging symbols for &man.gdb.1;. To make sure you capture a crash dump, you need edit /etc/rc.conf and set dumpdev to point to your swap partition. 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. FreeBSD crash dumps are usually the same size as the physical RAM size of your machine. That is, if you have 64MB of RAM, you will get a 64MB 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=(foo) to set the amount of memory the kernel will use to something a little more sensible. For example, if you have 128MB of RAM, you can limit the kernel's memory usage to 16MB so that your crash dump size will be 16MB instead of 128MB. Once you have recovered the crash dump, you can get a stack trace with &man.gdb.1; as follows: &prompt.user; gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0 (gdb) where 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 in order to trace the exact sequence of events that lead to the crash. You can also use &man.gdb.1; to print out the contents of various variables or structures in order 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.gdb.1; to do remote debugging such that you can use &man.gdb.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. I have not played with this yet as I do not often have the chance to set up two machines side by side for debugging purposes. [Bill adds: "I forgot to mention one thing: 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." -ed] 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? By default, the kernel address space is 256 MB on FreeBSD 3.X and 1 GB on FreeBSD 4.X. If you run a network-intensive server (e.g. a large FTP or HTTP server), you might find that 256 MB is not enough. So how do you increase the address space? There are two aspects to this. First, you need to tell the kernel to reserve a larger portion of the address space for itself. Second, since the kernel is loaded at the top of the address space, you need to lower the load address so it does not bump its head against the ceiling. The first goal is achieved by increasing the value of NKPDE in src/sys/i386/include/pmap.h. Here is what it looks like for a 1 GB address space: #ifndef NKPDE #ifdef SMP #define NKPDE 254 /* addressable number of page tables/pde's */ #else #define NKPDE 255 /* addressable number of page tables/pde's */ #endif /* SMP */ #endif To find the correct value of NKPDE, divide the desired address space size (in megabytes) by four, then subtract one for UP and two for SMP. To achieve the second goal, you need to compute the correct load address: simply subtract the address space size (in bytes) from 0x100100000; the result is 0xc0100000 for a 1 GB address space. Set LOAD_ADDRESS in src/sys/i386/conf/Makefile.i386 to that value; then set the location counter in the beginning of the section listing in src/sys/i386/conf/kernel.script to the same value, as follows: OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") OUTPUT_ARCH(i386) ENTRY(btext) SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib); SECTIONS { /* Read-only sections, merged into text segment: */ . = 0xc0100000 + SIZEOF_HEADERS; .interp : { *(.interp) } Then reconfig and rebuild your kernel. You will probably have problems with &man.ps.1; &man.top.1; and the like; make world should take care of it (or a manual rebuild of libkvm, &man.ps.1; and &man.top.1; after copying the patched pmap.h to /usr/include/vm/. NOTE: the size of the kernel address space must be a multiple of four megabytes. [&a.dg; adds: I think the kernel address space needs to be a power of two, but I am not certain about that. The old(er) boot code used to monkey with the high order address bits and I think expected at least 256MB granularity.] Acknowledgments
FreeBSD Core Team If you see a problem with this FAQ, or wish to submit an entry, please mail the &a.doc;. We appreciate your feedback, and cannot make this a better FAQ without your help!
&a.jkh; Occasional fits of FAQ-reshuffling and updating. &a.dwhite; Services above and beyond the call of duty on freebsd-questions &a.joerg; Services above and beyond the call of duty on Usenet &a.wollman; Networking and formatting Jim Lowe Multicast information &a.pds; FreeBSD FAQ typing machine slavey The FreeBSD Team Kvetching, moaning, submitting data And to any others we have forgotten, apologies and heartfelt thanks! &bibliography; diff --git a/en_US.ISO8859-1/books/fdp-primer/examples/appendix.sgml b/en_US.ISO8859-1/books/fdp-primer/examples/appendix.sgml index 7edda5053b..e6e3fb352d 100644 --- a/en_US.ISO8859-1/books/fdp-primer/examples/appendix.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/examples/appendix.sgml @@ -1,355 +1,355 @@ Examples This appendix contains example SGML files and command lines you can use to convert them from one output format to another. If you have successfully installed the Documentation Project tools then you should be able to use these examples directly. These examples are not exhaustive—they do not contain all the elements you might want to use, particularly in your document's front matter. For more examples of DocBook markup you should examine the SGML source for this and other documents, available in the CVSup doc collection, or - available online starting at http://www.FreeBSD.org/cgi/cvsweb.cgi/doc/. + available online starting at + . To avoid confusion, these examples use the standard DocBook 3.1 DTD rather than the FreeBSD extension. They also use the stock stylesheets distributed by Norm Walsh, rather than any customisations made to those stylesheets by the FreeBSD Documentation Project. This makes them more useful as generic DocBook examples. DocBook <sgmltag>book</sgmltag> DocBook <sgmltag>book</sgmltag> An Example Book Your first name Your surname
foo@example.com
 2000 Copyright string here If your book has an abstract then it should go here. Preface Your book may have a preface, in which case it should be placed here. My first chapter This is the first chapter in my book. My first section This is the first section in my book. ]]> DocBook <sgmltag>article</sgmltag> DocBook <sgmltag>article</sgmltag>
An example article Your first name Your surname
foo@example.com
 2000 Copyright string here If your article has an abstract then it should go here. My first section This is the first section in my article. My first sub-section This is the first sub-section in my article.
]]> Producing formatted output This section assumes that you have installed the software listed in the textproc/docproj port, either by hand, or by using the port. Further, it is assumed that your software is installed in subdirectories under /usr/local/, and the directory where binaries have been installed is in your PATH. Adjust the paths as necessary for your system. Using Jade Converting DocBook to HTML (one large file) &prompt.user; jade -V nochunks \ -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ -c /usr/local/share/sgml/docbook/catalog \ -c /usr/local/share/sgml/jade/catalog \ -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl \ -t sgml file.sgml > file.html Specifies the nochunks parameter to the stylesheets, forcing all output to be written to STDOUT (using Norm Walsh's stylesheets). Specifies the catalogs that Jade will need to process. Three catalogs are required. The first is a catalog that contains information about the DSSSL stylesheets. The second contains information about the DocBook DTD. The third contains information specific to Jade. Specifies the full path to the DSSSL stylesheet that Jade will use when processing the document. Instructs Jade to perform a transformation from one DTD to another. In this case, the input is being transformed from the DocBook DTD to the HTML DTD. Specifies the file that Jade should process, and redirects output to the specified .html file. Converting DocBook to HTML (several small files) &prompt.user; jade \ -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ -c /usr/local/share/sgml/docbook/catalog \ -c /usr/local/share/sgml/jade/catalog \ -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl \ -t sgml file.sgml Specifies the catalogs that Jade will need to process. Three catalogs are required. The first is a catalog that contains information about the DSSSL stylesheets. The second contains information about the DocBook DTD. The third contains information specific to Jade. Specifies the full path to the DSSSL stylesheet that Jade will use when processing the document. Instructs Jade to perform a transformation from one DTD to another. In this case, the input is being transformed from the DocBook DTD to the HTML DTD. Specifies the file that Jade should process. The stylesheets determine how the individual HTML files will be named, and the name of the root file (i.e., the one that contains the start of the document. This example may still only generate one HTML file, depending on the structure of the document you are processing, and the stylesheet's rules for splitting output. Converting DocBook to Postscript The source SGML file must be converted to a TeX file. &prompt.user; jade -Vtex-backend \ -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ -c /usr/local/share/sgml/docbook/catalog \ -c /usr/local/share/sgml/jade/catalog \ -d /usr/local/share/sgml/docbook/dsssl/modular/print/docbook.dsl \ -t tex file.sgml Customises the stylesheets to use various options specific to producing output for TeX. Specifies the catalogs that Jade will need to process. Three catalogs are required. The first is a catalog that contains information about the DSSSL stylesheets. The second contains information about the DocBook DTD. The third contains information specific to Jade. Specifies the full path to the DSSSL stylesheet that Jade will use when processing the document. Instructs Jade to convert the output to TeX. The generated .tex file must now be run through tex, specifying the &jadetex macro package. &prompt.user; tex "&jadetex" file.tex You have to run tex at least three times. The first run processes the document, and determines areas of the document which are referenced from other parts of the document, for use in indexing, and so on. Do not be alarmed if you see warning messages such as LaTeX Warning: Reference `136' on page 5 undefined on input line 728. at this point. The second run reprocesses the document now that certain pieces of information are known (such as the document's page length). This allows index entries and other cross-references to be fixed up. The third pass performs any final cleanup necessary. The output from this stage will be file.dvi. Finally, run dvips to convert the .dvi file to Postscript. &prompt.user; dvips -o file.ps file.dvi Converting DocBook to PDF The first part of this process is identical to that when converting DocBook to Postscript, using the same jade command line (). When the .tex file has been generated you run pdfTeX. However, use the &pdfjadetex macro package instead. &prompt.user; pdftex "&pdfjadetex" file.tex Again, run this command three times. This will generate file.pdf, which does not need to be processed any further. diff --git a/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml b/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml index 9439a7e162..810bb86fee 100644 --- a/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml +++ b/en_US.ISO8859-1/books/fdp-primer/sgml-markup/chapter.sgml @@ -1,2680 +1,2679 @@ SGML Markup This chapter describes the two markup languages you will encounter when you contribute to the FreeBSD documentation project. Each section describes the markup language, and details the markup that you are likely to want to use, or that is already in use. These markup languages contain a large number of elements, and it can be confusing sometimes to know which element to use for a particular situation. This section goes through the elements you are most likely to need, and gives examples of how you would use them. This is not an exhaustive list of elements, since that would just reiterate the documentation for each language. The aim of this section is to list those elements more likely to be useful to you. If you have a question about how best to markup a particular piece of content, please post it to the &a.doc;. Inline vs. block In the remainder of this document, when describing elements, inline means that the element can occur within a block element, and does not cause a line break. A block element, by comparison, will cause a line break (and other processing) when it is encountered. HTML HTML, the HyperText Markup Language, is the markup language of choice on the World Wide Web. More information can be found at - <URL:http://www.w3.org/>. + <URL:>. HTML is used to markup pages on the FreeBSD web site. It should not (generally) be used to mark up other documentation, since DocBook offers a far richer set of elements to choose from. Consequently, you will normally only encounter HTML pages if you are writing for the web site. HTML has gone through a number of versions, 1, 2, 3.0, 3.2, and the latest, 4.0 (available in both strict and loose variants). The HTML DTDs are available from the ports collection in the textproc/html port. They are automatically installed as part of the textproc/docproj port. Formal Public Identifier (FPI) There are a number of HTML FPIs, depending upon the version (also known as the level) of HTML that you want to declare your document to be compliant with. The majority of HTML documents on the FreeBSD web site comply with the loose version of HTML 4.0. PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" Sectional elements An HTML document is normally split into two sections. The first section, called the head, contains meta-information about the document, such as its title, the name of the author, the parent document, and so on. The second section, the body, contains the content that will be displayed to the user. These sections are indicated with head and body elements respectively. These elements are contained within the top-level html element. Normal HTML document structure <html> <head> <title>The document's title</title> </head> <body> … </body> </html> Block elements Headings HTML allows you to denote headings in your document, at up to six different levels. The largest and most prominent heading is h1, then h2, continuing down to h6. The element's content is the text of the heading. <sgmltag>h1</sgmltag>, <sgmltag>h2</sgmltag>, etc. Use: First section

This is the heading for the first section

This is the heading for the first sub-section

This is the heading for the second section

]]> Generally, an HTML page should have one first level heading (h1). This can contain many second level headings (h2), which can in turn contain many third level headings. Each hn element should have the same element, but one further up the hierarchy, preceding it. Leaving gaps in the numbering is to be avoided. Bad ordering of <sgmltag>h<replaceable>n</replaceable></sgmltag> elements Use: First section

Sub-section

]]> Paragraphs HTML supports a single paragraph element, p. <sgmltag>p</sgmltag> Use: This is a paragraph. It can contain just about any other element.

]]> Block quotations A block quotation is an extended quotation from another document that should not appear within the current paragraph. <sgmltag>blockquote</sgmltag> Use: A small excerpt from the US Constitution:

We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
]]> Lists You can present the user with three types of lists, ordered, unordered, and definition. Typically, each entry in an ordered list will be numbered, while each entry in an unordered list will be preceded by a bullet point. Definition lists are composed of two sections for each entry. The first section is the term being defined, and the second section is the definition of the term. Ordered lists are indicated by the ol element, unordered lists by the ul element, and definition lists by the dl element. Ordered and unordered lists contain listitems, indicated by the li element. A listitem can contain textual content, or it may be further wrapped in one or more p elements. Definition lists contain definition terms (dt) and definition descriptions (dd). A definition term can only contain inline elements. A definition description can contain other block elements. <sgmltag>ul</sgmltag> and <sgmltag>ol</sgmltag> Use: An unordered list. Listitems will probably be preceded by bullets.

  • First item
  • Second item
  • Third item

An ordered list, with list items consisting of multiple paragraphs. Each item (note: not each paragraph) will be numbered.

  1. This is the first item. It only has one paragraph.

  2. This is the first paragraph of the second item.

    This is the second paragraph of the second item.

  3. This is the first and only paragraph of the third item.

]]> Definition lists with <sgmltag>dl</sgmltag> Use:
Term 1

Paragraph 1 of definition 1.

Paragraph 2 of definition 1.

Term 2

Paragraph 1 of definition 2.

Term 3
Paragraph 1 of definition 3. Note that the <p> element is not required in the single paragraph case.
]]> Pre-formatted text You can indicate that text should be shown to the user exactly as it is in the file. Typically, this means that the text is shown in a fixed font, multiple spaces are not merged into one, and line breaks in the text are significant. In order to do this, wrap the content in the pre element. <sgmltag>pre</sgmltag> You could use pre to mark up an e-mail message; From: nik@FreeBSD.org To: freebsd-doc@FreeBSD.org Subject: New documentation available There is a new copy of my primer for contributors to the FreeBSD Documentation Project available at Comments appreciated. N]]> Tables Most text-mode browsers (such as Lynx) do not render tables particularly effectively. If you are relying on the tabular display of your content, you should consider using alternative markup to prevent confusion. Mark up tabular information using the table element. A table consists of one or more table rows (tr), each containing one or more cells of table data (td). Each cell can contain other block elements, such as paragraphs or lists. It can also contain another table (this nesting can repeat indefinitely). If the cell only contains one paragraph then you do not need to include the p element. Simple use of <sgmltag>table</sgmltag> Use: This is a simple 2x2 table.

Top left cell Top right cell
Bottom left cell Bottom right cell
]]> A cell can span multiple rows and columns. To indicate this, add the rowspan and/or colspan attributes, with values indicating the number of rows of columns that should be spanned. Using <literal>rowspan</literal> Use: One tall thin cell on the left, two short cells next to it on the right.

Long and thin
Top cell Bottom cell
]]> Using <literal>colspan</literal> Use: One long cell on top, two short cells below it.

Top cell
Bottom left cell Bottom right cell
]]> Using <literal>rowspan</literal> and <literal>colspan</literal> together Use: On a 3x3 grid, the top left block is a 2x2 set of cells merged into one. The other cells are normal.

Top left large cell Top right cell
Middle right cell
Bottom left cell Bottom middle cell Bottom right cell
]]> In-line elements Emphasising information You have two levels of emphasis available in HTML, em and strong. em is for a normal level of emphasis and strong indicates stronger emphasis. Typically, em is rendered in italic and strong is rendered in bold. This is not always the case, however, and you should not rely on it. <sgmltag>em</sgmltag> and <sgmltag>strong</sgmltag> Use: This has been emphasised, while this has been strongly emphasised.

]]> Bold and italics Because HTML includes presentational markup, you can also indicate that particular content should be rendered in bold or italic. The elements are b and i respectively. <sgmltag>b</sgmltag> and <sgmltag>i</sgmltag> This is in bold, while this is in italics.

]]> Indicating fixed pitch text If you have content that should be rendered in a fixed pitch (typewriter) typeface, use tt (for teletype). <sgmltag>tt</sgmltag> Use: This document was originally written by Nik Clayton, who can be reached by e-mail as nik@FreeBSD.org.

]]> Content size You can indicate that content should be shown in a larger or smaller font. There are three ways of doing this. Use big and small around the content you wish to change size. These tags can be nested, so <big><big>This is much bigger</big></big> is possible. Use font with the size attribute set to +1 or -1 respectively. This has the same effect as using big or small. However, the use of this approach is deprecated. Use font with the size attribute set to a number between 1 and 7. The default font size is 3. This approach is deprecated. <sgmltag>big</sgmltag>, <sgmltag>small</sgmltag>, and <sgmltag>font</sgmltag> The following fragments all do the same thing. This text is slightly smaller. But this text is slightly bigger.

This text is slightly smaller. But this text is slightly bigger

This text is slightly smaller. But this text is slightly bigger.

]]> Links Links are also in-line elements. Linking to other documents on the WWW In order to include a link to another document on the WWW you must know the URL of the document you want to link to. The link is indicated with a, and the href attribute contains the URL of the target document. The content of the element becomes the link, and is normally indicated to the user in some way (underlining, change of color, different mouse cursor when over the link, and so on). Using <literal><a href="..."></literal> Use: More information is available at the FreeBSD web site.

]]> These links will take the user to the top of the chosen document. Linking to other parts of documents Linking to a point within another document (or within the same document) requires that the document author include anchors that you can link to. Anchors are indicated with a and the name attribute instead of href. Using <literal><a name="..."></literal> Use: This paragraph can be referenced in other links with the name para1.

]]> To link to a named part of a document, write a normal link to that document, but include the name of the anchor after a # symbol. Linking to a named part of another document Assume that the para1 example resides in a document called foo.html. More information can be found in the first paragraph of foo.html.

]]> If you are linking to a named anchor within the same document then you can omit the document's URL, and just include the name of the anchor (with the preceding #). Linking to a named part of the same document Assume that the para1 example resides in this document More information can be found in the first paragraph of this document.

]]> DocBook DocBook was designed by the Davenport Group to be a DTD for writing technical documentation. As such, and unlike LinuxDoc and HTML, DocBook is very heavily oriented towards markup that describes what something is, rather than describing how it should be presented. <literal>formal</literal> vs. <literal>informal</literal> Some elements may exist in two forms, formal and informal. Typically, the formal version of the element will consist of a title followed by the information version of the element. The informal version will not have a title. The DocBook DTD is available from the ports collection in the textproc/docbook port. It is automatically installed as part of the textproc/docproj port. FreeBSD extensions The FreeBSD Documentation Project has extended the DocBook DTD by adding some new elements. These elements serve to make some of the markup more precise. Where a FreeBSD specific element is listed below it is clearly marked. Throughout the rest of this document, the term DocBook is used to mean the FreeBSD extended DocBook DTD. There is nothing about these extensions that is FreeBSD specific, it was just felt that they were useful enhancements for this particular project. Should anyone from any of the other *nix camps (NetBSD, OpenBSD, Linux, …) be interested in collaborating on a standard DocBook extension set, please get in touch with &a.nik;. The FreeBSD extensions are not (currently) in the ports collection. They are stored in the FreeBSD CVS tree, as doc/share/sgml/freebsd.dtd. Formal Public Identifier (FPI) In compliance with the DocBook guidelines for writing FPIs for DocBook customisations, the FPI for the FreeBSD extended DocBook DTD is; PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" Document structure DocBook allows you to structure your documentation in several ways. In the FreeBSD Documentation Project we are using two primary types of DocBook document: the book and the article. A book is organised into chapters. This is a mandatory requirement. There may be parts between the book and the chapter to provide another layer of organisation. The Handbook is arranged in this way. A chapter may (or may not) contain one or more sections. These are indicated with the sect1 element. If a section contains another section then use the sect2 element, and so on, up to sect5. Chapters and sections contain the remainder of the content. An article is simpler than a book, and does not use chapters. Instead, the content of an article is organised into one or more sections, using the same sect1 (and sect2 and so on) elements that are used in books. Obviously, you should consider the nature of the documentation you are writing in order to decide whether it is best marked up as a book or an article. Articles are well suited to information that does not need to be broken down into several chapters, and that is, relatively speaking, quite short, at up to 20-25 pages of content. Books are best suited to information that can be broken up into several chapters, possibly with appendices and similar content as well. The FreeBSD tutorials are all marked up as articles, while this document, the FreeBSD FAQ, and the FreeBSD Handbook are all marked up as books. Starting a book The content of the book is contained within the book element. As well as containing structural markup, this element can contain elements that include additional information about the book. This is either meta-information, used for reference purposes, or additional content used to produce a title page. This additional information should be contained within bookinfo. Boilerplate <sgmltag>book</sgmltag> with <sgmltag>bookinfo</sgmltag> <book> <bookinfo> <title>Your title here</title> <author> <firstname>Your first name</firstname> <surname>Your surname</surname> <affiliation> <address><email>Your e-mail address</email></address> </affiliation> </author> <copyright> <year>1998</year> <holder role="mailto:your e-mail address">Your name</holder> </copyright> <releaseinfo>$FreeBSD$</releaseinfo> <abstract> <para>Include an abstract of the book's contents here.</para> </abstract> </bookinfo> … </book> Starting an article The content of the article is contained within the article element. As well as containing structural markup, this element can contain elements that include additional information about the article. This is either meta-information, used for reference purposes, or additional content used to produce a title page. This additional information should be contained within articleinfo. Boilerplate <sgmltag>article</sgmltag> with <sgmltag>articleinfo</sgmltag> <article> <articleinfo> <title>Your title here</title> <author> <firstname>Your first name</firstname> <surname>Your surname</surname> <affiliation> <address><email>Your e-mail address</email></address> </affiliation> </author> <copyright> <year>1998</year> <holder role="mailto:your e-mail address">Your name</holder> </copyright> <releaseinfo>$FreeBSD$</releaseinfo> <abstract> <para>Include an abstract of the article's contents here.</para> </abstract> </articleinfo> … </article> Indicating chapters Use chapter to mark up your chapters. Each chapter has a mandatory title. Articles do not contain chapters, they are reserved for books. A simple chapter The chapter's title ... ]]> A chapter cannot be empty; it must contain elements in addition to title. If you need to include an empty chapter then just use an empty paragraph. Empty chapters This is an empty chapter ]]> Sections below chapters In books, chapters may (but do not need to) be broken up into sections, subsections, and so on. In articles, sections are the main structural element, and each article must contain at least one section. Use the sectn element. The n indicates the section number, which identifies the section level. The first sectn is sect1. You can have one or more of these in a chapter. They can contain one or more sect2 elements, and so on, down to sect5. Sections in chapters A sample chapter Some text in the chapter. First section (1.1) … Second section (1.2) First sub-section (1.2.1) First sub-sub-section (1.2.1.1) … Second sub-section (1.2.2) … ]]> This example includes section numbers in the section titles. You should not do this in your documents. Adding the section numbers is carried out by the stylesheets (of which more later), and you do not need to manage them yourself. Subdividing using <sgmltag>part</sgmltag>s You can introduce another layer of organisation between book and chapter with one or more parts. This cannot be done in an article. Introduction Overview ... What is FreeBSD? ... History ... ]]> Block elements Paragraphs DocBook supports three types of paragraphs: formalpara, para, and simpara. Most of the time you will only need to use para. formalpara includes a title element, and simpara disallows some elements from within para. Stick with para. <sgmltag>para</sgmltag> Use: This is a paragraph. It can contain just about any other element. ]]> Appearance: This is a paragraph. It can contain just about any other element. Block quotations A block quotation is an extended quotation from another document that should not appear within the current paragraph. You will probably only need it infrequently. Blockquotes can optionally contain a title and an attribution (or they can be left untitled and unattributed). <sgmltag>blockquote</sgmltag> Use: A small excerpt from the US Constitution;
Preamble to the Constitution of the United States Copied from a web site somewhere We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
]]> Appearance:
Preamble to the Constitution of the United States Copied from a web site somewhere We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.
Tips, notes, warnings, cautions, important information and sidebars. You may need to include extra information separate from the main body of the text. Typically this is meta information that the user should be aware of. Depending on the nature of the information, one of tip, note, warning, caution, and important should be used. Alternatively, if the information is related to the main text but is not one of the above, use sidebar. The circumstances in which to choose one of these elements over another is unclear. The DocBook documentation suggests; A Note is for information that should be heeded by all readers. An Important element is a variation on Note. A Caution is for information regarding possible data loss or software damage. A Warning is for information regarding possible hardware damage or injury to life or limb. <sgmltag>warning</sgmltag> Use: Installing FreeBSD may make you want to delete Windows from your hard disk. ]]> Installing FreeBSD may make you want to delete Windows from your hard disk. Lists and procedures You will often need to list pieces of information to the user, or present them with a number of steps that must be carried out in order to accomplish a particular goal. In order to do this, use itemizedlist, orderedlist, or procedureThere are other types of list element in DocBook, but we are not concerned with those at the moment. itemizedlist and orderedlist are similar to their counterparts in HTML, ul and ol. Each one consists of one or more listitem elements, and each listitem contains one or more block elements. The listitem elements are analogous to HTML's li tags. However, unlike HTML, they are required. procedure is slightly different. It consists of steps, which may in turn consists of more steps or substeps. Each step contains block elements. <sgmltag>itemizedlist</sgmltag>, <sgmltag>orderedlist</sgmltag>, and <sgmltag>procedure</sgmltag> Use: This is the first itemized item. This is the second itemized item. This is the first ordered item. This is the second ordered item. Do this. Then do this. And now do this. ]]> Appearance: This is the first itemized item. This is the second itemized item. This is the first ordered item. This is the second ordered item. Do this. Then do this. And now do this. Showing file samples If you want to show a fragment of a file (or perhaps a complete file) to the user, wrap it in the programlisting element. White space and line breaks within programlisting are significant. In particular, this means that the opening tag should appear on the same line as the first line of the output, and the closing tag should appear on the same line as the last line of the output, otherwise spurious blank lines may be included. <sgmltag>programlisting</sgmltag> Use: When you have finished, your program should look like this; #include <stdio.h> int main(void) { printf("hello, world\n"); }]]> Notice how the angle brackets in the #include line need to be referenced by their entities instead of being included literally. Appearance: When you have finished, your program should look like this; #include <stdio.h> int main(void) { printf("hello, world\n"); } Callouts A callout is a mechanism for referring back to an earlier piece of text or specific position within an earlier example without linking to it within the text. To do this, mark areas of interest in your example (programlisting, literallayout, or whatever) with the co element. Each element must have a unique id assigned to it. After the example include a calloutlist that refers back to the example and provides additional commentary. <sgmltag>co</sgmltag> and <sgmltag>calloutlist</sgmltag> When you have finished, your program should look like this; #include <stdio.h> int main(void) { printf("hello, world\n"); } Includes the standard IO header file. Specifies that main() returns an int. The printf() call that writes hello, world to standard output. ]]> Appearance: When you have finished, your program should look like this; #include <stdio.h> int main(void) { printf("hello, world\n"); } Includes the standard IO header file. Specifies that main() returns an int. The printf() call that writes hello, world to standard output. Tables Unlike HTML, you do not need to use tables for layout purposes, as the stylesheet handles those issues for you. Instead, just use tables for marking up tabular data. In general terms (and see the DocBook documentation for more detail) a table (which can be either formal or informal) consists of a table element. This contains at least one tgroup element, which specifies (as an attribute) the number of columns in this table group. Within the tablegroup you can then have one thead element, which contains elements for the table headings (column headings), and one tbody which contains the body of the table. Both tgroup and thead contain row elements, which in turn contain entry elements. Each entry element specifies one cell in the table. <sgmltag>informaltable</sgmltag> Use: This is column head 1 This is column head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 ]]> Appearance: This is column head 1 This is column head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 If you do not want a border around the table the frame attribute can be added to the informaltable element with a value of none (i.e., <informaltable frame="none">). Tables where <literal>frame="none"</literal> Appearance: This is column head 1 This is column head 2 Row 1, column 1 Row 1, column 2 Row 2, column 1 Row 2, column 2 Examples for the user to follow A lot of the time you need to show examples for the user to follow. Typically, these will consist of dialogs with the computer; the user types in a command, the user gets a response back, they type in another command, and so on. A number of distinct elements and entities come into play here. screen Everything the user sees in this example will be on the computer screen, so the next element is screen. Within screen, white space is significant. prompt, &prompt.root; and &prompt.user; Some of the things the user will be seeing on the screen are prompts from the computer (either from the operating system, command shell, or application). These should be marked up using prompt. As a special case, the two shell prompts for the normal user and the root user have been provided as entities. Every time you want to indicate the user is at a shell prompt, use one of &prompt.root; and &prompt.user; as necessary. They do not need to be inside prompt. &prompt.root; and &prompt.user; are FreeBSD extensions to DocBook, and are not part of the original DTD. userinput When displaying text that the user should type in, wrap it in userinput tags. It will probably be displayed differently to the user. <sgmltag>screen</sgmltag>, <sgmltag>prompt</sgmltag>, and <sgmltag>userinput</sgmltag> Use: &prompt.user; ls -1 foo1 foo2 foo3 &prompt.user; ls -1 | grep foo2 foo2 &prompt.user; su Password: &prompt.root; cat foo2 This is the file called 'foo2']]> Appearance: &prompt.user; ls -1 foo1 foo2 foo3 &prompt.user; ls -1 | grep foo2 foo2 &prompt.user; su Password: &prompt.root; cat foo2 This is the file called 'foo2' Even though we are displaying the contents of the file foo2, it is not marked up as programlisting. Reserve programlisting for showing fragments of files outside the context of user actions. In-line elements Emphasising information When you want to emphasise a particular word or phrase, use emphasis. This may be presented as italic, or bold, or might be spoken differently with a text-to-speech system. There is no way to change the presentation of the emphasis within your document, no equivalent of HTML's b and i. If the information you are presenting is important then consider presenting it in important rather than emphasis. <sgmltag>emphasis</sgmltag> Use: FreeBSD is without doubt the premiere Unix like operating system for the Intel architecture.]]> Appearance: FreeBSD is without doubt the premiere Unix like operating system for the Intel architecture. Quotations To quote text from another document or source, or to denote a phrase that is used figuratively, use quote. Within a quote tag, you may use most of the markup tags available for normal text. Quotations Use: However, make sure that the search does not go beyond the boundary between local and public administration, as RFC 1535 calls it.]]> Appearance: However, make sure that the search does not go beyond the boundary between local and public administration, as RFC 1535 calls it. Keys, mouse buttons, and combinations To refer to a specific key on the keyboard, use keycap. To refer to a mouse button, use mousebutton. And to refer to combinations of key presses or mouse clicks, wrap them all in keycombo. keycombo has an attribute called action, which may be one of click, double-click, other, press, seq, or simul. The last two values denote whether the keys or buttons should be pressed in sequence, or simultaneously. The stylesheets automatically add any connecting symbols, such as +, between the key names, when wrapped in keycombo. Keys, mouse buttons, and combinations Use: To switch to the second virtual terminal, press Alt F1. To exit vi without saving your work, type Esc: q!. My window manager is configured so that Alt right mouse button is used to move windows.]]> Appearance: To switch to the second virtual terminal, press Alt F1. To exit vi without saving your work, type Esc: q!. My window manager is configured so that Alt right mouse button is used to move windows. Applications, commands, options, and cites You will frequently want to refer to both applications and commands when writing for the Handbook. The distinction between them is simple: an application is the name for a suite (or possibly just 1) of programs that fulfil a particular task. A command is the name of a program that the user can run. In addition, you will occasionally need to list one or more of the options that a command might take. Finally, you will often want to list a command with its manual section number, in the command(number) format so common in Unix manuals. Mark up application names with application. When you want to list a command with its manual section number (which should be most of the time) the DocBook element is citerefentry. This will contain a further two elements, refentrytitle and manvolnum. The content of refentrytitle is the name of the command, and the content of manvolnum is the manual page section. This can be cumbersome to write, and so a series of general entities have been created to make this easier. Each entity takes the form &man.manual-page.manual-section;. The file that contains these entities is in doc/share/sgml/man-refs.ent, and can be referred to using this FPI: PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN" Therefore, the introduction to your documentation will probably look like this: <!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ <!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"> %man; … ]> Use command when you want to include a command name in-line but present it as something the user should type in. Use option to mark up a command's options. This can be confusing, and sometimes the choice is not always clear. Hopefully this example makes it clearer. Applications, commands, and options. Use: Sendmail is the most widely used Unix mail application. Sendmail includes the sendmail 8 , &man.mailq.8;, and &man.newaliases.8; programs. One of the command line parameters to sendmail 8 , , will display the current status of messages in the mail queue. Check this on the command line by running sendmail -bp.]]> Appearance: Sendmail is the most widely used Unix mail application. Sendmail includes the sendmail 8 , mailq 8 , and newaliases 8 programs. One of the command line parameters to sendmail 8 , , will display the current status of messages in the mail queue. Check this on the command line by running sendmail -bp. Notice how the &man.command.section; notation is easier to follow. Files, directories, extensions Whenever you wish to refer to the name of a file, a directory, or a file extension, use filename. <sgmltag>filename</sgmltag> Use: The SGML source for the Handbook in English can be found in /usr/doc/en/handbook/. The first file is called handbook.sgml in that directory. You should also see a Makefile and a number of files with a .ent extension.]]> Appearance: The SGML source for the Handbook in English can be found in /usr/doc/en/handbook/. The first file is called handbook.sgml in that directory. You should also see a Makefile and a number of files with a .ent extension. The name of ports FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. You might need to include the name of a program from the FreeBSD Ports Collection in the documentation. Use the filename tag with the role attribute set to package to identify these. Since ports can be installed in any number of locations, only include the category and the port name; do not include /usr/ports. <sgmltag>filename</sgmltag> tag with <literal>package</literal> role Use: Install the net/ethereal port to view network traffic.]]> Appearance: Install the net/ethereal port to view network traffic. Devices FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. When referring to devices you have two choices. You can either refer to the device as it appears in /dev, or you can use the name of the device as it appears in the kernel. For this latter course, use devicename. Sometimes you will not have a choice. Some devices, such as networking cards, do not have entries in /dev, or the entries are markedly different from those entries. <sgmltag>devicename</sgmltag> Use: sio is used for serial communication in FreeBSD. sio manifests through a number of entries in /dev, including /dev/ttyd0 and /dev/cuaa0. By contrast, the networking devices, such as ed0 do not appear in /dev. In MS-DOS, the first floppy drive is referred to as a:. In FreeBSD it is /dev/fd0.]]> Appearance: sio is used for serial communication in FreeBSD. sio manifests through a number of entries in /dev, including /dev/ttyd0 and /dev/cuaa0. By contrast, the networking devices, such as ed0 do not appear in /dev. In MS-DOS, the first floppy drive is referred to as a:. In FreeBSD it is /dev/fd0. Hosts, domains, IP addresses, and so forth FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. You can markup identification information for networked computers (hosts) in several ways, depending on the nature of the information. All of them use hostid as the element, with the role attribute selecting the type of the marked up information. No role attribute, or role="hostname" With no role attribute (i.e., hostid.../hostid) the marked up information is the simple hostname, such as freefall or wcarchive. You can explicitly specify this with role="hostname". role="domainname" The text is a domain name, such as FreeBSD.org or ngo.org.uk. There is no hostname component. role="fqdn" The text is a Fully Qualified Domain Name, with both hostname and domain name parts. role="ipaddr" The text is an IP address, probably expressed as a dotted quad. role="ip6addr" The text is an IPv6 address. role="netmask" The text is a network mask, which might be expressed as a dotted quad, a hexadecimal string, or as a / followed by a number. role="mac" The text is an Ethernet MAC address, expressed as a series of 2 digit hexadecimal numbers separated by colons. <sgmltag>hostid</sgmltag> and roles Use: The local machine can always be referred to by the name localhost, which will have the IP address 127.0.0.1. The FreeBSD.org domain contains a number of different hosts, including freefall.FreeBSD.org and bento.FreeBSD.org. When adding an IP alias to an interface (using ifconfig) always use a netmask of 255.255.255.255 (which can also be expressed as 0xffffffff. The MAC address uniquely identifies every network card in existence. A typical MAC address looks like 08:00:20:87:ef:d0.]]> Appearance: The local machine can always be referred to by the name localhost, which will have the IP address 127.0.0.1. The FreeBSD.org domain contains a number of different hosts, including freefall.FreeBSD.org and bento.FreeBSD.org. When adding an IP alias to an interface (using ifconfig) always use a netmask of 255.255.255.255 (which can also be expressed as 0xffffffff. The MAC address uniquely identifies every network card in existence. A typical MAC address looks like 08:00:20:87:ef:d0. Usernames FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. When you need to refer to a specific username, such as root or bin, use username. <sgmltag>username</sgmltag> Use: To carry out most system administration functions you will need to be root.]]> Appearance: To carry out most system administration functions you will need to be root. Describing <filename>Makefile</filename>s FreeBSD extension These elements are part of the FreeBSD extension to DocBook, and do not exist in the original DocBook DTD. Two elements exist to describe parts of Makefiles, maketarget and makevar. maketarget identifies a build target exported by a Makefile that can be given as a parameter to make. makevar identifies a variable that can be set (in the environment, on the make command line, or within the Makefile) to influence the process. <sgmltag>maketarget</sgmltag> and <sgmltag>makevar</sgmltag> Use: Two common targets in a Makefile are all and clean. Typically, invoking all will rebuild the application, and invoking clean will remove the temporary files (.o for example) created by the build process. clean may be controlled by a number of variables, including CLOBBER and RECURSE.]]> Appearance: Two common targets in a Makefile are all and clean. Typically, invoking all will rebuild the application, and invoking clean will remove the temporary files (.o for example) created by the build process. clean may be controlled by a number of variables, including CLOBBER and RECURSE. Literal text You will often need to include literal text in the Handbook. This is text that is excerpted from another file, or which should be copied from the Handbook into another file verbatim. Some of the time, programlisting will be sufficient to denote this text. programlisting is not always appropriate, particularly when you want to include a portion of a file in-line with the rest of the paragraph. On these occasions, use literal. <sgmltag>literal</sgmltag> Use: The maxusers 10 line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support.]]> Appearance: The maxusers 10 line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support. Showing items that the user <emphasis>must</emphasis> fill in There will often be times when you want to show the user what to do, or refer to a file, or command line, or similar, where the user cannot simply copy the examples that you provide, but must instead include some information themselves. replaceable is designed for this eventuality. Use it inside other elements to indicate parts of that element's content that the user must replace. <sgmltag>replaceable</sgmltag> Use: &prompt.user; man command ]]> Appearance: &prompt.user; man command replaceable can be used in many different elements, including literal. This example also shows that replaceable should only be wrapped around the content that the user is meant to provide. The other content should be left alone. Use: The maxusers n line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support. For a desktop workstation, 32 is a good value for n.]]> Appearance: The maxusers n line in the kernel configuration file determines the size of many system tables, and is a rough guide to how many simultaneous logins the system will support. For a desktop workstation, 32 is a good value for n. Quoting system errors You might want to show errors generated by FreeBSD. Mark these with errorname. This indicates the exact error that appears. <sgmltag>errorname</sgmltag> Use: Panic: cannot mount root ]]> Appearance: Panic: cannot mount root Images Image support in the documentation is currently extremely experimental. I think the mechanisms described here are unlikely to change, but that is not guaranteed. You will also need to install the graphics/ImageMagick port, which is used to convert between the different image formats. This is a big port, and most of it is not required. However, while we are working on the Makefiles and other infrastructure it makes things easier. This port is not in the textproc/docproj meta port, you must install it by hand. The best example of what follows in practice is the doc/en_US.ISO8859-1/articles/vm-design/ document. If you are unsure of the description that follows, take a look at the files in that directory to see how everything hangs together. Experiment with creating different formatted versions of the document to see how the image markup appears in the formatted output. Image formats We currently support two formats for images. The format you should use will depend on the nature of your image. For images that are primarily vector based, such as network diagrams, time lines, and similar, use Encapsulated Postscript, and make sure that your images have the .eps extension. For bitmaps, such as screen captures, use the Portable Network Graphic format, and make sure that your images have the .png extension. These are the only formats in which images should be committed to the CVS repository. Use the right format for the right image. It is to be expected that your documentation will have a mix of EPS and PNG images. The Makefiles ensure that the correct format image is chosen depending on the output format that you use for your documentation. Do not commit the same image to the repository in two different formats. It is anticipated that the Documentation Project will switch to using the Scalable Vector Graphic (SVG) format for vector images. However, the current state of SVG capable editing tools makes this impractical. Markup The markup for an image is relatively simple. First, markup a mediaobject. The mediaobject can contain other, more specific objects. We are concerned with two, the imageobject and the textobject. You should include one imageobject, and two textobject elements. The imageobject will point to the name of the image file that will be used (without the extension). The textobject elements contain information that will be presented to the user as well as, or instead of, the image. There are two circumstances where this can happen. When the reader is viewing the documentation in HTML. In this case, each image will need to have associated alternate text to show the user, typically whilst the image is loading, or if they hover the mouse pointer over the image. When the reader is viewing the documentation in plain text. In this case, each image should have an ASCII art equivalent to show the user. An example will probably make things easier to understand. Suppose you have an image, called fig1, that you want to include in the document. This image is of a rectangle with an A inside it. The markup for this would be as follows. <mediaobject> <imageobject> <imagedata fileref="fig1"> </imageobject> <textobject> <literallayout class="monospaced">+---------------+ | A | +---------------+</literallayout> </textobject> <textobject> <phrase>A picture</phrase> </textobject> </mediaobject> Include an imagedata element inside the imageobject element. The fileref attribute should contain the filename of the image to include, without the extension. The stylesheets will work out which extension should be added to the filename automatically. The first textobject should contain a literallayout element, where the class attribute is set to monospaced. This is your opportunity to demonstrate your ASCII art skills. This content will be used if the document is converted to plain text. Notice how the first and last lines of the content of the literallayout element butt up next to the element's tags. This ensures no extraneous white space is included. The second textobject should contain a single phrase element. The contents of this will become the alt attribute for the image when this document is converted to HTML. <filename>Makefile</filename> entries Your images must be listed in the Makefile in the IMAGES variable. This variable should contain the name of all your source images. For example, if you have created three figures, fig1.eps, fig2.png, fig3.png, then your Makefile should have lines like this in it. … IMAGES= fig1.eps fig2.png fig3.png … or … IMAGES= fig1.eps IMAGES+= fig2.png IMAGES+= fig3.png … Again, the Makefile will work out the complete list of images it needs to build your source document, you only need to list the image files you provided. Images and chapters in subdirectories You must be careful when you separate your documentation into smaller files (see ) in different directories. Suppose you have a book with three chapters, and the chapters are stored in their own directories, called chapter1/chapter.sgml, chapter2/chapter.sgml, and chapter3/chapter.sgml. If each chapter has images associated with it, I suggest you place those images in each chapter's subdirectory (chapter1/, chapter2/, and chapter3/). However, if you do this you must include the directory names in the IMAGES variable in the Makefile, and you must include the directory name in the imagedata element in your document. For example, if you have chapter1/fig1.png, then chapter1/chapter.sgml should contain <mediaobject> <imageobject> <imagedata fileref="chapter1/fig1"> </imageobject> … </mediaobject> The directory name must be included in the fileref attribute The Makefile must contain … IMAGES= chapter1/fig1.png … Then everything should just work. Links Links are also in-line elements. Linking to other parts of the same document Linking within the same document requires you to specify where you are linking from (i.e., the text the user will click, or otherwise indicate, as the source of the link) and where you are linking to (the link's destination). Each element within DocBook has an attribute called id. You can place text in this attribute to uniquely name the element it is attached to. This value will be used when you specify the link source. Normally, you will only be linking to chapters or sections, so you would add the id attribute to these elements. <literal>id on chapters and sections</literal> Introduction This is the introduction. It contains a subsection, which is identified as well. Sub-sect 1 This is the subsection. ]]> Obviously, you should use more descriptive values. The values must be unique within the document (i.e., not just the file, but the document the file might be included in as well). Notice how the id for the subsection is constructed by appending text to the id of the chapter. This helps to ensure that they are unique. If you want to allow the user to jump into a specific portion of the document (possibly in the middle of a paragraph or an example), use anchor. This element has no content, but takes an id attribute. <sgmltag>anchor</sgmltag> This paragraph has an embedded link target in it. It will not show up in the document.]]> When you want to provide the user with a link they can activate (probably by clicking) to go to a section of the document that has an id attribute, you can use either xref or link. Both of these elements have a linkend attribute. The value of this attribute should be the value that you have used in a id attribute (it does not matter if that value has not yet occurred in your document; this will work for forward links as well as backward links). If you use xref then you have no control over the text of the link. It will be generated for you. Using <sgmltag>xref</sgmltag> Assume that this fragment appears somewhere in a document that includes the id example; More information can be found in . More specific information can be found in .]]> The text of the link will be generated automatically, and will look like (emphasised text indicates the text that will be the link);
More information can be found in Chapter One. More specific information can be found in the section called Sub-sect 1.
Notice how the text from the link is derived from the section title or the chapter number. This means that you cannot use xref to link to an id attribute on an anchor element. The anchor has no content, so the xref cannot generate the text for the link. If you want to control the text of the link then use link. This element wraps content, and the content will be used for the link. Using <sgmltag>link</sgmltag> Assume that this fragment appears somewhere in a document that includes the id example. More information can be found in the first chapter. More specific information can be found in this section.]]> This will generate the following (emphasised text indicates the text that will be the link);
More information can be found in the first chapter. More specific information can be found in this section.
That last one is a bad example. Never use words like this or here as the source for the link. The reader will need to hunt around the surrounding context to see where the link is actually taking them. You can use link to include a link to an id on an anchor element, since the link content defines the text that will be used for the link. Linking to documents on the WWW Linking to external documents is much simpler, as long as you know the URL of the document you want to link to. Use ulink. The url attribute is the URL of the page that the link points to, and the content of the element is the text that will be displayed for the user to activate. <sgmltag>ulink</sgmltag> Use: Of course, you could stop reading this document and go to the FreeBSD home page instead.]]> Appearance: Of course, you could stop reading this document and go to the FreeBSD home page instead. diff --git a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml index b22fd35053..22a287a720 100644 --- a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml @@ -1,556 +1,556 @@ Bibliography While the manual pages provide the definitive reference for individual pieces of the FreeBSD operating system, they are notorious for not illustrating how to put the pieces together to make the whole operating system run smoothly. For this, there is no substitute for a good book on Unix system administration and a good users' manual. Books & Magazines Specific to FreeBSD International books & Magazines: Using FreeBSD (in Chinese). FreeBSD for PC 98'ers (in Japanese), published by SHUWA System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E. FreeBSD (in Japanese), published by CUTT. ISBN 4-906391-22-2 C3055 P2400E. Complete Introduction to FreeBSD (in Japanese), published by Shoeisha Co., Ltd. ISBN 4-88135-473-6 P3600E. Personal UNIX Starter Kit FreeBSD (in Japanese), published by ASCII. ISBN 4-7561-1733-3 P3000E. FreeBSD Handbook (Japanese translation), published by ASCII. ISBN 4-7561-1580-2 P3800E. FreeBSD mit Methode (in German), published by Computer und Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-932311-31-0. FreeBSD 4 - Installieren, Konfigurieren, Administrieren (in German), published by Computer und Literatur Verlag, 2001. ISBN 3-932311-88-4. FreeBSD Install and Utilization Manual (in Japanese), published by Mainichi Communications Inc.. Onno W Purbo, Dodi Maryanto, Syahrial Hubbany, Widjil Widodo Building Internet Server with FreeBSD (in Indonesia Language), published by Elex Media Komputindo. English language books & Magazines: Absolute BSD: The Ultimate Guide to FreeBSD, published by No Starch Press, 2002. ISBN: 1886411743 The Complete FreeBSD, published by O'Reilly, 2003. ISBN: 0596005164 The FreeBSD Corporate Networker's Guide, published by Addison-Wesley, 2000. ISBN: 0201704811 FreeBSD: An Open-Source Operating System for Your Personal Computer, published by The Bit Tree Press, 2001. ISBN: 0971204500 Teach Yourself FreeBSD in 24 Hours, published by Sams, 2002. ISBN: 0672324245 FreeBSD unleashed, published by Sams, 2002. ISBN: 0672324563 FreeBSD: The Complete Reference, published by McGrawHill, 2003. ISBN: 0072224096 Users' Guides Computer Systems Research Group, UC Berkeley. 4.4BSD User's Reference Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-075-9 Computer Systems Research Group, UC Berkeley. 4.4BSD User's Supplementary Documents. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-076-7 UNIX in a Nutshell. O'Reilly & Associates, Inc., 1990. ISBN 093717520X Mui, Linda. What You Need To Know When You Can't Find Your UNIX System Administrator. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-104-6 Ohio State University has written a UNIX Introductory Course which is available online in HTML and PostScript format. Jpman Project, Japan FreeBSD Users Group. FreeBSD User's Reference Manual (Japanese translation). Mainichi Communications Inc., 1998. ISBN4-8399-0088-4 P3800E. Edinburgh University has written an Online Guide for newcomers to the UNIX environment. Administrators' Guides Albitz, Paul and Liu, Cricket. DNS and BIND, 4th Ed. O'Reilly & Associates, Inc., 2001. ISBN 1-59600-158-4 Computer Systems Research Group, UC Berkeley. 4.4BSD System Manager's Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-080-5 Costales, Brian, et al. Sendmail, 2nd Ed. O'Reilly & Associates, Inc., 1997. ISBN 1-56592-222-0 Frisch, Æleen. Essential System Administration, 2nd Ed. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-127-5 Hunt, Craig. TCP/IP Network Administration, 2nd Ed. O'Reilly & Associates, Inc., 1997. ISBN 1-56592-322-7 Nemeth, Evi. UNIX System Administration Handbook. 3rd Ed. Prentice Hall, 2000. ISBN 0-13-020601-6 Stern, Hal Managing NFS and NIS O'Reilly & Associates, Inc., 1991. ISBN 0-937175-75-7 Jpman Project, Japan FreeBSD Users Group. FreeBSD System Administrator's Manual (Japanese translation). Mainichi Communications Inc., 1998. ISBN4-8399-0109-0 P3300E. Programmers' Guides Asente, Paul, Converse, Diana, and Swick, Ralph. X Window System Toolkit. Digital Press, 1998. ISBN 1-55558-178-1 Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Reference Manual. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-078-3 Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Supplementary Documents. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-079-1 Harbison, Samuel P. and Steele, Guy L. Jr. C: A Reference Manual. 4rd ed. Prentice Hall, 1995. ISBN 0-13-326224-3 Kernighan, Brian and Dennis M. Ritchie. The C Programming Language.. PTR Prentice Hall, 1988. ISBN 0-13-110362-9 Lehey, Greg. Porting UNIX Software. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-126-7 Plauger, P. J. The Standard C Library. Prentice Hall, 1992. ISBN 0-13-131509-9 Stevens, W. Richard. Advanced Programming in the UNIX Environment. Reading, Mass. : Addison-Wesley, 1992 ISBN 0-201-56317-7 Stevens, W. Richard. UNIX Network Programming. 2nd Ed, PTR Prentice Hall, 1998. ISBN 0-13-490012-X Wells, Bill. Writing Serial Drivers for UNIX. Dr. Dobb's Journal. 19(15), December 1994. pp68-71, 97-99. Operating System Internals Andleigh, Prabhat K. UNIX System Architecture. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5 Jolitz, William. Porting UNIX to the 386. Dr. Dobb's Journal. January 1991-July 1992. Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and John Quarterman The Design and Implementation of the 4.3BSD UNIX Operating System. Reading, Mass. : Addison-Wesley, 1989. ISBN 0-201-06196-1 Leffler, Samuel J., Marshall Kirk McKusick, The Design and Implementation of the 4.3BSD UNIX Operating System: Answer Book. Reading, Mass. : Addison-Wesley, 1991. ISBN 0-201-54629-9 McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-54979-4 (Chapter 2 of this book is available online as part of the FreeBSD Documentation Project, and chapter 9 here.) Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9 Schimmel, Curt. Unix Systems for Modern Architectures. Reading, Mass. : Addison-Wesley, 1994. ISBN 0-201-63338-8 Stevens, W. Richard. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63495-3 Vahalia, Uresh. UNIX Internals -- The New Frontiers. Prentice Hall, 1996. ISBN 0-13-101908-2 Wright, Gary R. and W. Richard Stevens. TCP/IP Illustrated, Volume 2: The Implementation. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X Security Reference Cheswick, William R. and Steven M. Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63357-4 Garfinkel, Simson and Gene Spafford. Practical UNIX & Internet Security. 2nd Ed. O'Reilly & Associates, Inc., 1996. ISBN 1-56592-148-8 Garfinkel, Simson. PGP Pretty Good Privacy O'Reilly & Associates, Inc., 1995. ISBN 1-56592-098-8 Hardware Reference Anderson, Don and Tom Shanley. Pentium Processor System Architecture. 2nd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40992-5 Ferraro, Richard F. Programmer's Guide to the EGA, VGA, and Super VGA Cards. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-62490-7 Intel Corporation publishes documentation on their CPUs, chipsets and standards on their developer web site, usually as PDF files. Shanley, Tom. 80486 System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40994-1 Shanley, Tom. ISA System Architecture. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40996-8 Shanley, Tom. PCI System Architecture. 4th ed. Reading, Mass. : Addison-Wesley, 1999. ISBN 0-201-30974-2 Van Gilluwe, Frank. The Undocumented PC, 2nd Ed. Reading, Mass: Addison-Wesley Pub. Co., 1996. ISBN 0-201-47950-8 Messmer, Hans-Peter. The Indispensable PC Hardware Book, 4th Ed. Reading, Mass: Addison-Wesley Pub. Co., 2002. ISBN 0-201-59616-4 Unix History Lion, John Lion's Commentary on UNIX, 6th Ed. With Source Code. ITP Media Group, 1996. ISBN 1573980137 Raymond, Eric S. The New Hacker's Dictionary, 3rd edition. MIT Press, 1996. ISBN 0-262-68092-0. Also known as the Jargon File Salus, Peter H. A quarter century of UNIX. Addison-Wesley Publishing Company, Inc., 1994. ISBN 0-201-54777-5 Simon Garfinkel, Daniel Weise, Steven Strassmann. The UNIX-HATERS Handbook. IDG Books Worldwide, Inc., 1994. ISBN 1-56884-203-1 Don Libes, Sandy Ressler Life with UNIX — special edition. Prentice-Hall, Inc., 1989. ISBN 0-13-536657-7 - The BSD family tree. 1997. ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree or local on a FreeBSD-current machine. + The BSD family tree. 1997. + + or local + on a FreeBSD-current machine. The BSD Release Announcements collection. - 1997. http://www.de.FreeBSD.org/de/ftp/releases/ + 1997. Networked Computer Science Technical Reports - Library. http://www.ncstrl.org/ + Library. Old BSD releases from the Computer Systems Research - group (CSRG). http://www.mckusick.com/csrg/: + group (CSRG). + : The 4CD set covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not 2.11BSD, unfortunately). As well, the last disk holds the final sources plus the SCCS files. Magazines and Journals The C/C++ Users Journal. R&D Publications Inc. ISSN 1075-2838 Sys Admin — The Journal for UNIX System Administrators Miller Freeman, Inc., ISSN 1061-2688 diff --git a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml index fae640895c..1e2b2980ce 100644 --- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,1869 +1,1869 @@ Jim Mock Restructured, reorganized, and parts updated by Jordan Hubbard Original work by Poul-Henning Kamp John Polstra Nik Clayton The Cutting Edge Synopsis &os; is under constant development between releases. For people who want to be on the cutting edge, there are several easy mechanisms for keeping your system in sync with the latest developments. Be warned—the cutting edge is not for everyone! This chapter will help you decide if you want to track the development system, or stick with one of the released versions. After reading this chapter, you will know: The difference between the two development branches: &os.stable; and &os.current;. How to keep your system up to date with CVSup, CVS, or CTM. How to rebuild and reinstall the entire base system with make world. Before reading this chapter, you should: Properly setup your network connection (). Know how to install additional third-party software (). &os.current; vs. &os.stable; -CURRENT -STABLE There are two development branches to FreeBSD: &os.current; and &os.stable;. This section will explain a bit about each and describe how to keep your system up-to-date with each respective tree. &os.current; will be discussed first, then &os.stable;. Staying Current with &os; As you read this, keep in mind that &os.current; is the bleeding edge of &os; development. &os.current; users are expected to have a high degree of technical skill, and should be capable of solving difficult system problems on their own. If you are new to &os;, think twice before installing it. What Is &os.current;? snapshot &os.current; is the latest working sources for &os;. This includes work in progress, experimental changes, and transitional mechanisms that might or might not be present in the next official release of the software. While many &os; developers compile the &os.current; source code daily, there are periods of time when the sources are not buildable. These problems are resolved as expeditiously as possible, but whether or not &os.current; brings disaster or greatly desired functionality can be a matter of which exact moment you grabbed the source code in! Who Needs &os.current;? &os.current; is made available for 3 primary interest groups: Members of the &os; group who are actively working on some part of the source tree and for whom keeping current is an absolute requirement. Members of the &os; group who are active testers, willing to spend time solving problems in order to ensure that &os.current; remains as sane as possible. These are also people who wish to make topical suggestions on changes and the general direction of &os;, and submit patches to implement them. Those who merely wish to keep an eye on things, or to use the current sources for reference purposes (e.g. for reading, not running). These people also make the occasional comment or contribute code. What Is &os.current; <emphasis>Not</emphasis>? A fast-track to getting pre-release bits because you heard there is some cool new feature in there and you want to be the first on your block to have it. Being the first on the block to get the new feature means that you're the first on the block to get the new bugs. A quick way of getting bug fixes. Any given version of &os.current; is just as likely to introduce new bugs as to fix existing ones. In any way officially supported. We do our best to help people genuinely in one of the 3 legitimate &os.current; groups, but we simply do not have the time to provide tech support. This is not because we are mean and nasty people who do not like helping people out (we would not even be doing &os; if we were). We simply cannot answer hundreds messages a day and work on FreeBSD! Given the choice between improving &os; and answering lots of questions on experimental code, the developers opt for the former. Using &os.current; -CURRENT using Join the &a.current; and the &a.cvsall;. This is not just a good idea, it is essential. If you are not on the &a.current;, you will not see the comments that people are making about the current state of the system and thus will probably end up stumbling over a lot of problems that others have already found and solved. Even more importantly, you will miss out on important bulletins which may be critical to your system's continued health. The &a.cvsall; will allow you to see the commit log entry for each change as it is made along with any pertinent information on possible side-effects. To join these lists, send mail to &a.majordomo; and specify the following in the body of your message: subscribe freebsd-current subscribe cvs-all Majordomo Optionally, you can also say help and Majordomo will send you full help on how to subscribe and unsubscribe to the various other mailing lists we support. Grab the sources from a &os; mirror site. You can do this in one of three ways: cvsup cron -CURRENT Syncing with CVSup Use the cvsup program with this supfile. This is the most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically. You have to customize the sample supfile above, and configure cvsup for your environment. If you want help doing this configuration, simply type: &prompt.root; pkg_add -f ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/All/cvsupit-3.1.tgz -CURRENT Downloading with ftp Use ftp. The source tree for &os.current; is exported on some of the FTP mirrors in the directory /pub/FreeBSD/FreeBSD-current/. Some of our FTP mirrors may also allow compressed/tarred grabbing of whole trees. For example you see: usr.bin/lex You can do the following to get the whole directory as a tar file: ftp> cd usr.bin ftp> get lex.tar If you wish to download the entire &os.current; source tree cvsup handles this much better than mirroring a FTP site. -CURRENT Syncing with CTM Use the CTM facility. If you have very bad connectivity (high price connections or only email access) CTM is an option. However, it is a lot of hassle and can give you broken files. This leads to it being rarely used, which again increases the chance of it not working for fairly long periods of time. We recommend using CVSup for anybody with a 9600 bps modem or faster connection. If you are grabbing the sources to run, and not just look at, then grab all of &os.current;, not just selected portions. The reason for this is that various parts of the source depend on updates elsewhere, and trying to compile just a subset is almost guaranteed to get you into trouble. -CURRENT compiling Before compiling &os.current;, read the Makefile in /usr/src carefully. You should at least run a make world the first time through as part of the upgrading process. Reading the &a.current; will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move toward the next release. Be active! If you are running &os.current;, we want to know what you have to say about it, especially if you have suggestions for enhancements or bug fixes. Suggestions with accompanying code are received most enthusiastically! Staying Stable with &os; What Is &os.stable;? -STABLE &os.stable; is our 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; for testing. This is still a development branch, however, and this means that at any given time, the sources for &os.stable; may or may not be suitable for any particular purpose. It is simply another engineering development track, not a resource for end-users. Who Needs &os.stable;? If you are interested in tracking or contributing to the FreeBSD development process, especially as it relates to the next point release of FreeBSD, then you should consider following &os.stable;. While it is true that security fixes also go into the &os.stable; branch, you do not need to track &os.stable; to do this. Every security advisory for FreeBSD explains how to fix the problem for the releases it affects That is not quite true. We can not continue to support old releases of FreeBSD forever, although we do support them for many years. For a complete description of the current security policy for old releases of FreeBSD, please see http://www.FreeBSD.org/security/ , and tracking an entire development branch just for security reasons is likely to bring in a lot of unwanted changes as well. Although we endeavor to ensure that the &os.stable; branch compiles and runs at all times, this cannot be guaranteed. In addition, while code is developed in &os.current; before including it in &os.stable;, more people run &os.stable; than &os.current;, so it is inevitable that bugs and corner cases will sometimes be found in &os.stable; that were not apparent in &os.current;. For these reasons, we do not recommend that you blindly track &os.stable;, and it is particularly important that you do not update any production servers to &os.stable; without first thoroughly testing the code in your development environment. If you do not have the resources to do this then we recommend that you run the most recent release of FreeBSD, and use the binary update mechanism to move from release to release. Using &os.stable; -STABLE using Join the &a.stable;. This will keep you informed of build-dependencies that may appear in &os.stable; or any other issues requiring special attention. Developers will also make announcements in this mailing list when they are contemplating some controversial fix or update, giving the users a chance to respond if they have any issues to raise concerning the proposed change. The &a.cvsall; will allow you to see the commit log entry for each change as it is made along with any pertinent information on possible side-effects. To join these lists, send mail to &a.majordomo; and specify the following in the body of your message: subscribe freebsd-stable subscribe cvs-all Majordomo Optionally, you can also say help and Majordomo will send you full help on how to subscribe and unsubscribe to the various other mailing lists we support. If you are installing a new system and want it to be as stable as possible, you can simply grab the latest dated branch snapshot from ftp://releng4.FreeBSD.org/pub/FreeBSD/ + url="ftp://releng4.FreeBSD.org/pub/FreeBSD/"> and install it like any other release. If you are already running a previous release of &os; and wish to upgrade via sources then you can easily do so from &os; mirror site. This can be done in one of three ways: cvsup cron -STABLE syncing with CVSup Use the cvsup program with this supfile. This is the most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron to keep their sources up-to-date automatically. You have to customize the sample supfile above, and configure cvsup for your environment. If you want help doing this configuration, simply type:
&prompt.root; pkg_add -f ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/All/cvsupit-3.1.tgz
 -STABLE downloading with FTP Use ftp. The source tree for &os.stable; is exported on some of the FTP mirrors in the directory /pub/FreeBSD/FreeBSD-stable/. Some of our FTP mirrors may also allow compressed/tarred grabbing of whole trees. For example you see: usr.bin/lex You can do the following to get the whole directory for you as a tar file: ftp> cd usr.bin ftp> get lex.tar If you wish to download the entire &os.stable; source tree cvsup handles this much better than mirroring a FTP site. -STABLE syncing with CTM Use the CTM facility. If you do not have a fast and inexpensive connection to the Internet, this is the method you should consider using. Essentially, if you need rapid on-demand access to the source and communications bandwidth is not a consideration, use cvsup or ftp. Otherwise, use CTM. -STABLE compiling Before compiling &os.stable;, read the Makefile in /usr/src carefully. You should at least run a make world the first time through as part of the upgrading process. Reading the &a.stable; will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move toward the next release. Synchronizing Your Source There are various ways of using an Internet (or email) connection to stay up-to-date with any given area of the &os; project sources, or all areas, depending on what interests you. The primary services we offer are Anonymous CVS, CVSup, and CTM. While it is possible to update only parts of your source tree, the only supported update procedure is to update the entire tree and recompile both userland (i.e., all the programs that run in user space, such as those in /bin and /sbin) and kernel sources. Updating only part of your source tree, only the kernel, or only userland will often result in problems. These problems may range from compile errors to kernel panics or data corruption. anonymous CVS Anonymous CVS and CVSup use the pull model of updating sources. In the case of CVSup the user (or a cron script) invokes the cvsup program, and it interacts with a cvsupd server somewhere to bring your files up-to-date. The updates you receive are up-to-the-minute and you get them when, and only when, you want them. You can easily restrict your updates to the specific files or directories that are of interest to you. Updates are generated on the fly by the server, according to what you have and what you want to have. Anonymous CVS is quite a bit more simplistic than CVSup in that it is just an extension to CVS which allows it to pull changes directly from a remote CVS repository. CVSup can do this far more efficiently, but Anonymous CVS is easier to use. CTM CTM, on the other hand, does not interactively compare the sources you have with those on the master archive or otherwise pull them across. Instead, a script which identifies changes in files since its previous run is executed several times a day on the master CTM machine, any detected changes being compressed, stamped with a sequence-number and encoded for transmission over email (in printable ASCII only). Once received, these CTM deltas can then be handed to the &man.ctm.rmail.1; utility which will automatically decode, verify and apply the changes to the user's copy of the sources. This process is far more efficient than CVSup, and places less strain on our server resources since it is a push rather than a pull model. There are other trade-offs, of course. If you inadvertently wipe out portions of your archive, CVSup will detect and rebuild the damaged portions for you. CTM will not do this, and if you wipe some portion of your source tree out (and do not have it backed up) then you will have to start from scratch (from the most recent CVS base delta) and rebuild it all with CTM or, with Anonymous CVS, simply delete the bad bits and resync. Using <command>make world</command> make world Once you have synchronized your local source tree against a particular version of &os; (&os.stable;, &os.current;, and so on) you can then use the source tree to rebuild the system. Take a Backup It cannot be stressed enough how important it is to take a backup of your system before you do this. While rebuilding the world is (as long as you follow these instructions) an easy task to do, there will inevitably be times when you make mistakes, or when mistakes made by others in the source tree render your system unbootable. Make sure you have taken a backup. And have a fixit floppy to hand. You will probably never have to use it, but it is better to be safe than sorry! Subscribe to the Right Mailing List mailing list The &os.stable; and &os.current; branches are, by their nature, in development. People that contribute to &os; are human, and mistakes occasionally happen. Sometimes these mistakes can be quite harmless, just causing your system to print a new diagnostic warning. Or the change may be catastrophic, and render your system unbootable or destroy your file systems (or worse). If problems like these occur, a heads up is posted to the appropriate mailing list, explaining the nature of the problem and which systems it affects. And an all clear announcement is posted when the problem has been solved. If you try to track &os.stable; or &os.current; and do not read the &a.stable; or the &a.current; respectively, then you are asking for trouble. Read <filename>/usr/src/UPDATING</filename> Before you do anything else, read /usr/src/UPDATING (or the equivalent file wherever you have a copy of the source code). This file should contain important information about problems you might encounter, or specify the order in which you might have to run certain commands. If UPDATING contradicts something you read here, UPDATING takes precedence. Reading UPDATING is not an acceptable substitute for subscribing to the correct mailing list, as described previously. The two requirements are complementary, not exclusive. Check <filename>/etc/make.conf</filename> make.conf Examine the files /etc/defaults/make.conf and /etc/make.conf. The first contains some default defines – most of which are commented out. To make use of them when you rebuild your system from source, add them to /etc/make.conf. Keep in mind that anything you add to /etc/make.conf is also used every time you run make, so it is a good idea to set them to something sensible for your system. A typical user will probably want to copy the CFLAGS and NOPROFILE lines found in /etc/defaults/make.conf to /etc/make.conf and uncomment them. Examine the other definitions (COPTFLAGS, NOPORTDOCS and so on) and decide if they are relevant to you. Update the files in <filename>/etc</filename> The /etc directory contains a large part of your system's configuration information, as well as scripts that are run at system startup. Some of these scripts change from version to version of FreeBSD. Some of the configuration files are also used in the day to day running of the system. In particular, /etc/group. There have been occasions when the installation part of make world has expected certain usernames or groups to exist. When performing an upgrade it is likely that these users or groups did not exist. This caused problems when upgrading. A recent example of this is when the smmsp user was added. Users had the installation process fail for them when &man.mtree.8; was trying to create /var/spool/clientmqueue. The solution is to examine /usr/src/etc/group and compare its list of groups with your own. If there are any groups in the new file that are not in your file then copy them over. Similarly, you should rename any groups in /etc/group which have the same GID but a different name to those in /usr/src/etc/group. Since 4.6-RELEASE you can run &man.mergemaster.8; in pre-buildworld mode by providing the option. This will compare only those files that are essential for the success of buildworld or installworld. If your old version of mergemaster does not support , use the new version in the source tree when running for the first time: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p If you are feeling particularly paranoid, you can check your system to see which files are owned by the group you are renaming or deleting: &prompt.root; find / -group GID -print will show all files owned by group GID (which can be either a group name or a numeric group ID). Drop to Single User Mode single-user mode You may want to compile the system in single user mode. Apart from the obvious benefit of making things go slightly faster, reinstalling the system will touch a lot of important system files, all the standard system binaries, libraries, include files and so on. Changing these on a running system (particularly if you have active users on the system at the time) is asking for trouble. multi-user mode Another method is to compile the system in multi-user mode, and then drop into single user mode for the installation. If you would like to do it this way, simply hold off on the following steps until the build has completed. You can postpone dropping to single user mode until you have to installkernel or installworld. As the superuser, you can execute: &prompt.root; shutdown now from a running system, which will drop it to single user mode. Alternatively, reboot the system, and at the boot prompt, enter the flag. The system will then boot single user. At the shell prompt you should then run: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a This checks the file systems, remounts / read/write, mounts all the other UFS file systems referenced in /etc/fstab and then turns swapping on. If your CMOS clock is set to local time and not to GMT (this is true if the output of the &man.date.1; command does not show the correct time and zone), you may also need to run the following command: &prompt.root; adjkerntz -i This will make sure that your local timezone settings get set up correctly — without this, you may later run into some problems. Remove <filename>/usr/obj</filename> As parts of the system are rebuilt they are placed in directories which (by default) go under /usr/obj. The directories shadow those under /usr/src. You can speed up the make world process, and possibly save yourself some dependency headaches by removing this directory as well. Some files below /usr/obj may have the immutable flag set (see &man.chflags.1; for more information) which must be removed first. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Recompile the Source Saving the Output It is a good idea to save the output you get from running &man.make.1; to another file. If something goes wrong you will have a copy of the error message. While this might not help you in diagnosing what has gone wrong, it can help others if you post your problem to one of the &os; mailing lists. The easiest way to do this is to use the &man.script.1; command, with a parameter that specifies the name of the file to save all output to. You would do this immediately before rebuilding the world, and then type exit when the process has finished. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … If you do this, do not save the output in /tmp. This directory may be cleared next time you reboot. A better place to store it is in /var/tmp (as in the previous example) or in root's home directory. Compile the Base System You must be in the /usr/src directory: &prompt.root; cd /usr/src (unless, of course, your source code is elsewhere, in which case change to that directory instead). make To rebuild the world you use the &man.make.1; command. This command reads instructions from the Makefile, which describes how the programs that comprise &os; should be rebuilt, the order in which they should be built, and so on. The general format of the command line you will type is as follows: &prompt.root; make -x -DVARIABLE target In this example, is an option that you would pass to &man.make.1;. See the &man.make.1; manual page for an example of the options you can pass. passes a variable to the Makefile. The behavior of the Makefile is controlled by these variables. These are the same variables as are set in /etc/make.conf, and this provides another way of setting them. &prompt.root; make -DNOPROFILE target is another way of specifying that profiled libraries should not be built, and corresponds with the NOPROFILE= true # Avoid compiling profiled libraries line in /etc/make.conf. target tells &man.make.1; what you want to do. Each Makefile defines a number of different targets, and your choice of target determines what happens. Some targets are listed in the Makefile, but are not meant for you to run. Instead, they are used by the build process to break out the steps necessary to rebuild the system into a number of sub-steps. Most of the time you will not need to pass any parameters to &man.make.1;, and so your command like will look like this: &prompt.root; make target Beginning with version 2.2.5 of &os; (actually, it was first created on the &os.current; branch, and then retrofitted to &os.stable; midway between 2.2.2 and 2.2.5) the world target has been split in two: buildworld and installworld. As the names imply, buildworld builds a complete new tree under /usr/obj, and installworld installs this tree on the current machine. This is very useful for 2 reasons. First, it allows you to do the build safe in the knowledge that no components of your running system will be affected. The build is self hosted. Because of this, you can safely run buildworld on a machine running in multi-user mode with no fear of ill-effects. It is still recommended that you run the installworld part in single user mode, though. Secondly, it allows you to use NFS mounts to upgrade multiple machines on your network. If you have three machines, A, B and C that you want to upgrade, run make buildworld and make installworld on A. B and C should then NFS mount /usr/src and /usr/obj from A, and you can then run make installworld to install the results of the build on B and C. Although the world target still exists, you are strongly encouraged not to use it. Run &prompt.root; make buildworld It is now possible to specify a option to make which will cause it to spawn several simultaneous processes. This is most useful on multi-CPU machines. However, since much of the compiling process is IO bound rather than CPU bound it is also useful on single CPU machines. On a typical single-CPU machine you would run: &prompt.root; make -j4 buildworld &man.make.1; will then have up to 4 processes running at any one time. Empirical evidence posted to the mailing lists shows this generally gives the best performance benefit. If you have a multi-CPU machine and you are using an SMP configured kernel try values between 6 and 10 and see how they speed things up. Be aware that this is still somewhat experimental, and commits to the source tree may occasionally break this feature. If the world fails to compile using this parameter try again without it before you report any problems. Timings make world timings Many factors influence the build time, but currently a 500 MHz Pentium III with 128 MB of RAM takes about 2 hours to build the &os.stable; tree, with no tricks or shortcuts used during the process. A &os.current; tree will take somewhat longer. Compile and Install a New Kernel kernel compiling To take full advantage of your new system you should recompile the kernel. This is practically a necessity, as certain memory structures may have changed, and programs like &man.ps.1; and &man.top.1; will fail to work until the kernel and source code versions are the same. The simplest, safest way to do this is to build and install a kernel based on GENERIC. While GENERIC may not have all the necessary devices for your system, it should contain everything necessary to boot your system back to single user mode. This is a good test that the new system works properly. After booting from GENERIC and verifying that your system works you can then build a new kernel based on your normal kernel configuration file. If you are upgrading to &os; 4.0 or above then the old kernel build procedure (as described in ) is deprecated. Instead, you should run these commands after you have built the world with buildworld. If you want to build a custom kernel, and already have a configuration file, just use KERNCONF=MYKERNEL like this: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MYKERNEL &prompt.root; make installkernel KERNCONF=MYKERNEL In FreeBSD 4.2 and older you must replace KERNCONF= with KERNEL=. 4.2-STABLE that was fetched before Feb 2nd, 2001 does not recognize KERNCONF=. Note that if you have raised kern.securelevel above 1 and you have set either the noschg or similar flags to your kernel binary, you might find it necessary to drop into single user mode to use installkernel. Otherwise you should be able to run both these commands from multi user mode without problems. See &man.init.8; for details about kern.securelevel and &man.chflags.1; for details about the various file flags. If you are upgrading to a version of &os; below 4.0 you should use the old kernel build procedure. However, it is recommended that you use the new version of &man.config.8;, using a command line like this. &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME Reboot into Single User Mode single-user mode You should reboot into single user mode to test the new kernel works. Do this by following the instructions in . Install the New System Binaries If you were building a version of &os; recent enough to have used make buildworld then you should now use installworld to install the new system binaries. Run &prompt.root; cd /usr/src &prompt.root; make installworld If you specified variables on the make buildworld command line, you must specify the same variables in the make installworld command line. This does not necessarily hold true for other options; for example, must never be used with installworld. For example, if you ran: &prompt.root; make -DNOPROFILE buildworld you must install the results with: &prompt.root; make -DNOPROFILE installworld otherwise it would try to install profiled libraries that had not been built during the make buildworld phase. Update Files Not Updated by <command>make world</command> Remaking the world will not update certain directories (in particular, /etc, /var and /usr) with new or changed configuration files. The simplest way to update these files is to use &man.mergemaster.8;, though it is possible to do it manually if you would prefer to do that. Regardless of which way you choose, be sure to make a backup of /etc in case anything goes wrong. Tom Rhodes Contributed by <command>mergemaster</command> mergemaster The &man.mergemaster.8; utility is a Bourne script that will aid you in determining the differences between your configuration files in /etc, and the configuration files in the source tree /usr/src/etc. This is the recommended solution for keeping the system configuration files up to date with those located in the source tree. mergemaster was integrated into the FreeBSD base system between 3.3-RELEASE and 3.4-RELEASE, which means it is present in all -STABLE and -CURRENT systems since 3.3. To begin simply type mergemaster at your prompt, and watch it start going. mergemaster will then build a temporary root environment, from / down, and populate it with various system configuration files. Those files are then compared to the ones currently installed in your system. At this point, files that differ will be shown in &man.diff.1; format, with the sign representing added or modified lines, and representing lines that will be either removed completely, or replaced with a new line. See the &man.diff.1; manual page for more information about the &man.diff.1; syntax and how file differences are shown. &man.mergemaster.8; will then show you each file that displays variances, and at this point you will have the option of either deleting the new file (referred to as the temporary file), installing the temporary file in its unmodified state, merging the temporary file with the currently installed file, or viewing the &man.diff.1; results again. Choosing to delete the temporary file will tell &man.mergemaster.8; that we wish to keep our current file unchanged, and to delete the new version. This option is not recommended, unless you see no reason to change the current file. You can get help at any time by typing ? at the &man.mergemaster.8; prompt. If the user chooses to skip a file, it will be presented again after all other files have been dealt with. Choosing to install the unmodified temporary file will replace the current file with the new one. For most unmodified files, this is the best option. Choosing to merge the file will present you with a text editor, and the contents of both files. You can now merge them by reviewing both files side by side on the screen, and choosing parts from both to create a finished product. When the files are compared side by side, the l key will select the left contents and the r key will select contents from your right. The final output will be a file consisting of both parts, which can then be installed. This option is customarily used for files where settings have been modified by the user. Choosing to view the &man.diff.1; results again will show you the file differences just like &man.mergemaster.8; did before prompting you for an option. After &man.mergemaster.8; is done with the system files you will be prompted for other options. &man.mergemaster.8; may ask if you want to rebuild the password file and/or run &man.MAKEDEV.8; if you run a FreeBSD version prior to 5.0, and will finish up with an option to remove left-over temporary files. Manual Update If you wish to do the update manually, however, you cannot just copy over the files from /usr/src/etc to /etc and have it work. Some of these files must be installed first. This is because the /usr/src/etc directory is not a copy of what your /etc directory should look like. In addition, there are files that should be in /etc that are not in /usr/src/etc. If you are using &man.mergemaster.8; (as recommended), you can skip forward to the next section. The simplest way to do this by hand is to install the files into a new directory, and then work through them looking for differences. Backup Your Existing <filename>/etc</filename> Although, in theory, nothing is going to touch this directory automatically, it is always better to be sure. So copy your existing /etc directory somewhere safe. Something like: &prompt.root; cp -Rp /etc /etc.old does a recursive copy, preserves times, ownerships on files and suchlike. You need to build a dummy set of directories to install the new /etc and other files into. /var/tmp/root is a reasonable choice, and there are a number of subdirectories required under this as well. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution This will build the necessary directory structure and install the files. A lot of the subdirectories that have been created under /var/tmp/root are empty and should be deleted. The simplest way to do this is to: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null This will remove all empty directories. (Standard error is redirected to /dev/null to prevent the warnings about the directories that are not empty.) /var/tmp/root now contains all the files that should be placed in appropriate locations below /. You now have to go through each of these files, determining how they differ with your existing files. Note that some of the files that will have been installed in /var/tmp/root have a leading .. At the time of writing the only files like this are shell startup files in /var/tmp/root/ and /var/tmp/root/root/, although there may be others (depending on when you are reading this). Make sure you use ls -a to catch them. The simplest way to do this is to use &man.diff.1; to compare the two files: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells This will show you the differences between your /etc/shells file and the new /var/tmp/root/etc/shells file. Use these to decide whether to merge in changes that you have made or whether to copy over your old file. Name the New Root Directory (<filename>/var/tmp/root</filename>) with a Time Stamp, So You Can Easily Compare Differences Between Versions Frequently rebuilding the world means that you have to update /etc frequently as well, which can be a bit of a chore. You can speed this process up by keeping a copy of the last set of changed files that you merged into /etc. The following procedure gives one idea of how to do this. Make the world as normal. When you want to update /etc and the other directories, give the target directory a name based on the current date. If you were doing this on the 14th of February 1998 you could do the following: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Merge in the changes from this directory as outlined above. Do not remove the /var/tmp/root-19980214 directory when you have finished. When you have downloaded the latest version of the source and remade it, follow step 1. This will give you a new directory, which might be called /var/tmp/root-19980221 (if you wait a week between doing updates). You can now see the differences that have been made in the intervening week using &man.diff.1; to create a recursive diff between the two directories: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Typically, this will be a much smaller set of differences than those between /var/tmp/root-19980221/etc and /etc. Because the set of differences is smaller, it is easier to migrate those changes across into your /etc directory. You can now remove the older of the two /var/tmp/root-* directories: &prompt.root; rm -rf /var/tmp/root-19980214 Repeat this process every time you need to merge in changes to /etc. You can use &man.date.1; to automate the generation of the directory names: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Update <filename>/dev</filename> DEVFS If you are running FreeBSD 5.0 or later you can safely skip this section. These versions use &man.devfs.5; to allocate device nodes transparently for the user. In most cases, the &man.mergemaster.8; tool will realize when it is necessary to update the device nodes, and offer to complete it automatically. These instructions tell how to update the device nodes manually. For safety's sake, this is a multi-step process. Copy /var/tmp/root/dev/MAKEDEV to /dev: &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev MAKEDEV If you used &man.mergemaster.8; to update /etc, then your MAKEDEV script should have been updated already, though it cannot hurt to check (with &man.diff.1;) and copy it manually if necessary. Now, take a snapshot of your current /dev. This snapshot needs to contain the permissions, ownerships, major and minor numbers of each filename, but it should not contain the time stamps. The easiest way to do this is to use &man.awk.1; to strip out some of the information: &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out Remake all the device nodes: &prompt.root; sh MAKEDEV all Write another snapshot of the directory, this time to /var/tmp/dev2.out. Now look through these two files for any device node that you missed creating. There should not be any, but it is better to be safe than sorry. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out You are most likely to notice disk slice discrepancies which will involve commands such as: &prompt.root; sh MAKEDEV sd0s1 to recreate the slice entries. Your precise circumstances may vary. Update <filename>/stand</filename> This step is included only for completeness. It can safely be omitted. For the sake of completeness, you may want to update the files in /stand as well. These files consist of hard links to the /stand/sysinstall binary. This binary should be statically linked, so that it can work when no other file systems (and in particular /usr) have been mounted. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install Rebooting You are now done. After you have verified that everything appears to be in the right place you can reboot the system. A simple &man.fastboot.8; should do it: &prompt.root; fastboot Finished You should now have successfully upgraded your &os; system. Congratulations. If things went slightly wrong, it is easy to rebuild a particular piece of the system. For example, if you accidentally deleted /etc/magic as part of the upgrade or merge of /etc, the &man.file.1; command will stop working. In this case, the fix would be to run: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Questions Do I need to re-make the world for every change? There is no easy answer to this one, as it depends on the nature of the change. For example, if you just ran CVSup, and it has shown the following files as being updated: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk it probably is not worth rebuilding the entire world. You could just go to the appropriate sub-directories and make all install, and that's about it. But if something major changed, for example src/lib/libc/stdlib then you should either re-make the world, or at least those parts of it that are statically linked (as well as anything else you might have added that is statically linked). At the end of the day, it is your call. You might be happy re-making the world every fortnight say, and let changes accumulate over that fortnight. Or you might want to re-make just those things that have changed, and be confident you can spot all the dependencies. And, of course, this all depends on how often you want to upgrade, and whether you are tracking &os.stable; or &os.current;. My compile failed with lots of signal 11 (or other signal number) errors. What has happened? signal 11 This is normally indicative of hardware problems. (Re)making the world is an effective way to stress test your hardware, and will frequently throw up memory problems. These normally manifest themselves as the compiler mysteriously dying on receipt of strange signals. A sure indicator of this is if you can restart the make and it dies at a different point in the process. In this instance there is little you can do except start swapping around the components in your machine to determine which one is failing. Can I remove /usr/obj when I have finished? The short answer is yes. /usr/obj contains all the object files that were produced during the compilation phase. Normally, one of the first steps in the make world process is to remove this directory and start afresh. In this case, keeping /usr/obj around after you have finished makes little sense, and will free up a large chunk of disk space (currently about 340 MB). However, if you know what you are doing you can have make world skip this step. This will make subsequent builds run much faster, since most of sources will not need to be recompiled. The flip side of this is that subtle dependency problems can creep in, causing your build to fail in odd ways. This frequently generates noise on the &os; mailing lists, when one person complains that their build has failed, not realizing that it is because they have tried to cut corners. Can interrupted builds be resumed? This depends on how far through the process you got before you found a problem. In general (and this is not a hard and fast rule) the make world process builds new copies of essential tools (such as &man.gcc.1;, and &man.make.1;) and the system libraries. These tools and libraries are then installed. The new tools and libraries are then used to rebuild themselves, and are installed again. The entire system (now including regular user programs, such as &man.ls.1; or &man.grep.1;) is then rebuilt with the new system files. If you are at the last stage, and you know it (because you have looked through the output that you were storing) then you can (fairly safely) do: … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNOCLEAN all This will not undo the work of the previous make world. If you see the message: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- in the make world output then it is probably fairly safe to do so. If you do not see that message, or you are not sure, then it is always better to be safe than sorry, and restart the build from scratch. How can I speed up making the world? Run in single user mode. Put the /usr/src and /usr/obj directories on separate file systems held on separate disks. If possible, put these disks on separate disk controllers. Better still, put these file systems across multiple disks using the &man.ccd.4; (concatenated disk driver) device. Turn off profiling (set NOPROFILE=true in /etc/make.conf). You almost certainly do not need it. Also in /etc/make.conf, set CFLAGS to something like . The optimization is much slower, and the optimization difference between and is normally negligible. lets the compiler use pipes rather than temporary files for communication, which saves disk access (at the expense of memory). Pass the option to &man.make.1; to run multiple processes in parallel. This usually helps regardless of whether you have a single or a multi processor machine. The file system holding /usr/src can be mounted (or remounted) with the option. This prevents the file system from recording the file access time. You probably do not need this information anyway. &prompt.root; mount -u -o noatime /usr/src The example assumes /usr/src is on its own file system. If it is not (if it is a part of /usr for example) then you will need to use that file system mount point, and not /usr/src. The file system holding /usr/obj can be mounted (or remounted) with the option. This causes disk writes to happen asynchronously. In other words, the write completes immediately, and the data is written to the disk a few seconds later. This allows writes to be clustered together, and can be a dramatic performance boost. Keep in mind that this option makes your file system more fragile. With this option there is an increased chance that, should power fail, the file system will be in an unrecoverable state when the machine restarts. If /usr/obj is the only thing on this file system then it is not a problem. If you have other, valuable data on the same file system then ensure your backups are fresh before you enable this option. &prompt.root; mount -u -o async /usr/obj As above, if /usr/obj is not on its own file system, replace it in the example with the name of the appropriate mount point. What do I do if something goes wrong? Make absolutely sure your environment has no extraneous cruft from earlier builds. This is simple enough. &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir Yes, make cleandir really should be run twice. Then restart the whole process, starting with make buildworld. If you still have problems, send the error and the output of uname -a to &a.questions;. Be prepared to answer other questions about your setup! Mike Meyer Contributed by Tracking for multiple machines NFS installing multiple machines If you have multiple machines that you want to track the same source tree, then having all of them download sources and rebuild everything seems like a waste of resources: disk space, network bandwidth, and CPU cycles. It is, and the solution is to have one machine do most of the work, while the rest of the machines mount that work via NFS. This section outlines a method of doing so. Preliminaries First, identify a set of machines that is going to run the same set of binaries, which we will call a build set. Each machine can have a custom kernel, but they will be running the same userland binaries. From that set, choose a machine to be the build machine. It is going to be the machine that the world and kernel are built on. Ideally, it should be a fast machine that has sufficient spare CPU to run make world. You will also want to choose a machine to be the test machine, which will test software updates before they are put into production. This must be a machine that you can afford to have down for an extended period of time. It can be the build machine, but need not be. All the machines in this build set need to mount /usr/obj and /usr/src from the same machine, and at the same point. Ideally, those are on two different drives on the build machine, but they can be NFS mounted on that machine as well. If you have multiple build sets, /usr/src should be on one build machine, and NFS mounted on the rest. Finally make sure that /etc/make.conf on all the machines in the build set agrees with the build machine. That means that the build machine must build all the parts of the base system that any machine in the build set is going to install. Also, each build machine should have its kernel name set with KERNCONF in /etc/make.conf, and the build machine should list them all in KERNCONF, listing its own kernel first. The build machine must have the kernel configuration files for each machine in /usr/src/sys/arch/conf if it is going to build their kernels. The base system Now that all that is done, you are ready to build everything. Build the kernel and world as described in on the build machine, but do not install anything. After the build has finished, go to the test machine, and install the kernel you just built. If this machine mounts /usr/src and /usr/obj via NFS, when you reboot to single user you will need to enable the network and mount them. The easiest way to do this is to boot to multi-user, then run shutdown now to go to single user mode. Once there, you can install the new kernel and world and run mergemaster just as you normally would. When done, reboot to return to normal multi-user operations for this machine. After you are certain that everything on the test machine is working properly, use the same procedure to install the new software on each of the other machines in the build set. Ports The same ideas can be used for the ports tree. The first critical step is mounting /usr/ports from the same machine to all the machines in the build set. You can then set up /etc/make.conf properly to share distfiles. You should set DISTDIR to a common shared directory that is writable by whichever user root is mapped to by your NFS mounts. Each machine should set WRKDIRPREFIX to a local build directory. Finally, if you are going to be building and distributing packages, you should set PACKAGES to a directory similar to DISTDIR. diff --git a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml index 9bb34e3222..aa9aac6aba 100644 --- a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,1965 +1,1863 @@ Resources on the Internet The rapid pace of FreeBSD progress makes print media impractical as a means of following the latest developments. Electronic resources are the best, if not often the only, way stay informed of the latest advances. Since FreeBSD is a volunteer effort, the user community itself also generally serves as a technical support department of sorts, with electronic mail and USENET news being the most effective way of reaching that community. The most important points of contact with the FreeBSD user community are outlined below. If you are aware of other resources not mentioned here, please send them to the &a.doc; so that they may also be included. Mailing Lists Though many of the FreeBSD development members read USENET, we cannot always guarantee that we will get to your questions in a timely fashion (or at all) if you post them only to one of the comp.unix.bsd.freebsd.* groups. By addressing your questions to the appropriate mailing list you will reach both us and a concentrated FreeBSD audience, invariably assuring a better (or at least faster) response. The charters for the various lists are given at the bottom of this document. Please read the charter before joining or sending mail to any list. Most of our list subscribers now receive many hundreds of FreeBSD related messages every day, and by setting down charters and rules for proper use we are striving to keep the signal-to-noise ratio of the lists high. To do less would see the mailing lists ultimately fail as an effective communications medium for the project. Archives are kept for all of the mailing lists and can be searched using the FreeBSD World Wide Web server. The keyword searchable archive offers an excellent way of finding answers to frequently asked questions and should be consulted before posting a question. List Summary General lists: The following are general lists which anyone is free (and encouraged) to join: List Purpose &a.cvsall.name; Changes made to the FreeBSD source tree &a.advocacy.name; FreeBSD Evangelism &a.announce.name; Important events and project milestones &a.arch.name; Architecture and design discussions &a.bugbusters.name; Discussions pertaining to the maintenance of the FreeBSD problem report database and related tools &a.bugs.name; Bug reports &a.chat.name; Non-technical items related to the FreeBSD community &a.config.name; Development of FreeBSD installation and configuration tools &a.current.name; Discussion concerning the use of &os.current; &a.isp.name; Issues for Internet Service Providers using FreeBSD &a.jobs.name; FreeBSD employment and consulting opportunities &a.newbies.name; New FreeBSD users activities and discussions &a.policy.name; FreeBSD Core team policy decisions. Low volume, and read-only &a.questions.name; User questions and technical support &a.security-notifications.name; Security notifications &a.stable.name; Discussion concerning the use of &os.stable; &a.test.name; Where to send your test messages instead of one of the actual lists Technical lists: The following lists are for technical discussion. You should read the charter for each list carefully before joining or sending mail to one as there are firm guidelines for their use and content. List Purpose &a.afs.name; Porting AFS to FreeBSD &a.aic7xxx.name; Developing drivers for the Adaptec AIC 7xxx &a.alpha.name; Porting FreeBSD to the Alpha &a.arm.name; Porting FreeBSD to ARM processors &a.atm.name; Using ATM networking with FreeBSD &a.audit.name; Source code audit project &a.binup.name; Design and development of the binary update system &a.cluster.name; Using FreeBSD in a clustered environment &a.cvsweb.name; CVSweb maintenance &a.database.name; Discussing database use and development under FreeBSD &a.doc.name; Creating FreeBSD related documents &a.emulation.name; Emulation of other systems such as Linux/DOS/Windows &a.firewire.name; FreeBSD Firewire (iLink, IEEE 1394) technical discussion &a.fs.name; File systems &a.gnome.name; Porting GNOME and GNOME applications &a.hackers.name; General technical discussion &a.hardware.name; General discussion of hardware for running FreeBSD &a.i18n.name; FreeBSD Internationalization &a.ia32.name; FreeBSD on the IA-32 (Intel x86) platform &a.ia64.name; Porting FreeBSD to Intel's upcoming IA64 systems &a.ipfw.name; Technical discussion concerning the redesign of the IP firewall code &a.isdn.name; ISDN developers &a.java.name; Java developers and people porting JDKs to FreeBSD &a.kde.name; Porting KDE and KDE applications &a.lfs.name; Porting LFS to FreeBSD &a.libh.name; The second generation installation and package system &a.mips.name; Porting FreeBSD to MIPS &a.mobile.name; Discussions about mobile computing &a.mozilla.name; Porting Mozilla to FreeBSD &a.multimedia.name; Multimedia applications &a.newbus.name; Technical discussions about bus architecture &a.net.name; Networking discussion and TCP/IP source code &a.openoffice.name; Porting OpenOffice.org and StarOffice to FreeBSD &a.performance.name; Performance tuning questions for high performance/load installations &a.platforms.name; Concerning ports to non-Intel architecture platforms &a.ports.name; Discussion of the ports collection &a.ports-bugs.name; Discussion of the ports bugs/PRs &a.ppc.name; Porting FreeBSD to the PowerPC &a.qa.name; Discussion of Quality Assurance, usually pending a release &a.realtime.name; Development of realtime extensions to FreeBSD &a.scsi.name; The SCSI subsystem &a.security.name; Security issues affecting FreeBSD &a.small.name; Using FreeBSD in embedded applications &a.smp.name; Design discussions for [A]Symmetric MultiProcessing &a.sparc.name; Porting FreeBSD to SPARC based systems &a.standards.name; FreeBSD's conformance to the C99 and the POSIX standards &a.threads.name; Threading in FreeBSD &a.testing.name; FreeBSD Performance and Stability Tests &a.tokenring.name; Support Token Ring in FreeBSD Limited lists: The following lists are for more specialized (and demanding) audiences and are probably not of interest to the general public. It is also a good idea to establish a presence in the technical lists before joining one of these limited lists so that you will understand the communications etiquette involved. List Purpose &a.core.name; FreeBSD core team &a.hubs.name; People running mirror sites (infrastructural support) &a.usergroups.name; User group coordination &a.vendors.name; Vendors pre-release coordination &a.www.name; Maintainers of www.FreeBSD.org Digest lists: All of the above lists are available in a digest format. Once subscribed to a list, you can change your digest options in your account options section. CVS lists: The following lists are for people interested in seeing the log messages for changes to various areas of the source tree. They are Read-Only lists and should not have mail sent to them. List Source area Area Description (source for) &a.cvsall.name; /usr/(CVSROOT|doc|ports|projects|src) All changes to any place in the tree (superset of other cvs commit lists) &a.cvs-doc.name; /usr/doc All changes to the doc tree &a.cvs-ports.name; /usr/ports All changes to the ports tree &a.cvs-projects.name; /usr/projects All changes to the projects tree &a.cvs-src.name; /usr/src All changes to the src tree How to Subscribe To subscribe to a list, click on the list name above or goto &a.mailman.lists.link; and click on the list that you're interested in. The list page should contain all of the necessary subscription instructions. To actually post to a given list you simply send mail to <listname@FreeBSD.org>. It will then be redistributed to mailing list members world-wide. To unsubscribe yourself from a list, click on the URL found at the bottom of every email received from the list. It is also possible to send an email to freebsd-[listname]-unsubscribe@FreeBSD.org to unsubscribe yourself. Again, we would like to request that you keep discussion in the technical mailing lists on a technical track. If you are only interested in important announcements then it is suggested that you join the &a.announce.name;, which is intended only for infrequent traffic. List Charters All FreeBSD mailing lists have certain basic rules which must be adhered to by anyone using them. Failure to comply with these guidelines will result in two (2) written warnings from the FreeBSD Postmaster postmaster@FreeBSD.org, after which, on a third offense, the poster will removed from all FreeBSD mailing lists and filtered from further posting to them. We regret that such rules and measures are necessary at all, but today's Internet is a pretty harsh environment, it would seem, and many fail to appreciate just how fragile some of its mechanisms are. Rules of the road: The topic of any posting should adhere to the basic charter of the list it is posted to, e.g. if the list is about technical issues then your posting should contain technical discussion. Ongoing irrelevant chatter or flaming only detracts from the value of the mailing list for everyone on it and will not be tolerated. For free-form discussion on no particular topic, the &a.chat; is freely available and should be used instead. No posting should be made to more than 2 mailing lists, and only to 2 when a clear and obvious need to post to both lists exists. For most lists, there is already a great deal of subscriber overlap and except for the most esoteric mixes (say -stable & -scsi), there really is no reason to post to more than one list at a time. If a message is sent to you in such a way that multiple mailing lists appear on the Cc line then the Cc line should also be trimmed before sending it out again. You are still responsible for your own cross-postings, no matter who the originator might have been. Personal attacks and profanity (in the context of an argument) are not allowed, and that includes users and developers alike. Gross breaches of netiquette, like excerpting or reposting private mail when permission to do so was not and would not be forthcoming, are frowned upon but not specifically enforced. However, there are also very few cases where such content would fit within the charter of a list and it would therefore probably rate a warning (or ban) on that basis alone. Advertising of non-FreeBSD related products or services is strictly prohibited and will result in an immediate ban if it is clear that the offender is advertising by spam. Individual list charters: &a.afs.name; Andrew File System This list is for discussion on porting and using AFS from CMU/Transarc &a.announce.name; Important events / milestones This is the mailing list for people interested only in occasional announcements of significant FreeBSD events. This includes announcements about snapshots and other releases. It contains announcements of new FreeBSD capabilities. It may contain calls for volunteers etc. This is a low volume, strictly moderated mailing list. &a.arch.name; Architecture and design discussions This list is for discussion of the FreeBSD architecture. Messages will mostly be kept strictly technical in nature. Examples of suitable topics are: How to re-vamp the build system to have several customized builds running at the same time. What needs to be fixed with VFS to make Heidemann layers work. How do we change the device driver interface to be able to use the same drivers cleanly on many buses and architectures. How to write a network driver. &a.audit.name; Source code audit project This is the mailing list for the FreeBSD source code audit project. Although this was originally intended for security-related changes, its charter has been expanded to review any code changes. This list is very heavy on patches, and is probably of no interest to the average FreeBSD user. Security discussions not related to a particular code change are held on freebsd-security. Conversely, all developers are encouraged to send their patches here for review, especially if they touch a part of the system where a bug may adversely affect the integrity of the system. &a.binup.name; FreeBSD Binary Update Project This list exists to provide discussion for the binary update system, or binup. Design issues, implementation details, patches, bug reports, status reports, feature requests, commit logs, and all other things related to binup are fair game. &a.bugbusters.name; Coordination of the Problem Report handling effort The purpose of this list is to serve as a coordination and discussion forum for the Bugmeister, his Bugbusters, and any other parties who have a genuine interest in the PR database. This list is not for discussions about specific bugs, patches or PRs. &a.bugs.name; Bug reports This is the mailing list for reporting bugs in FreeBSD. Whenever possible, bugs should be submitted using the &man.send-pr.1; command or the WEB interface to it. &a.chat.name; Non technical items related to the FreeBSD community This list contains the overflow from the other lists about non-technical, social information. It includes discussion about whether Jordan looks like a toon ferret or not, whether or not to type in capitals, who is drinking too much coffee, where the best beer is brewed, who is brewing beer in their basement, and so on. Occasional announcements of important events (such as upcoming parties, weddings, births, new jobs, etc) can be made to the technical lists, but the follow ups should be directed to this -chat list. &a.core.name; FreeBSD core team This is an internal mailing list for use by the core members. Messages can be sent to it when a serious FreeBSD-related matter requires arbitration or high-level scrutiny. &a.current.name; Discussions about the use of &os.current; This is the mailing list for users of &os.current;. It includes warnings about new features coming out in -CURRENT that will affect the users, and instructions on steps that must be taken to remain -CURRENT. Anyone running CURRENT must subscribe to this list. This is a technical mailing list for which strictly technical content is expected. &a.cvsweb.name; FreeBSD CVSweb Project Technical discussions about use, development and maintenance of FreeBSD-CVSweb. &a.doc.name; Documentation project This mailing list is for the discussion of issues and projects related to the creation of documentation for FreeBSD. The members of this mailing list are collectively referred to as The FreeBSD Documentation Project. It is an open list; feel free to join and contribute! &a.firewire.name; Firewire (iLink, IEEE 1394) This is a mailing list for discussion of the design and implementation of a Firewire (aka IEEE 1394 aka iLink) subsystem for FreeBSD. Relevant topics specifically include the standards, bus devices and their protocols, adapter boards/cards/chips sets, and the architecture and implementation of code for their proper support. &a.fs.name; File systems Discussions concerning FreeBSD file systems. This is a technical mailing list for which strictly technical content is expected. &a.gnome.name; GNOME Discussions concerning The GNOME Desktop Environment for FreeBSD systems. This is a technical mailing list for which strictly technical content is expected. &a.ipfw.name; IP Firewall This is the forum for technical discussions concerning the redesign of the IP firewall code in FreeBSD. This is a technical mailing list for which strictly technical content is expected. &a.ia64.name; Porting FreeBSD to IA64 This is a technical mailing list for individuals actively working on porting FreeBSD to the IA-64 platform from Intel, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. &a.isdn.name; ISDN Communications This is the mailing list for people discussing the development of ISDN support for FreeBSD. &a.java.name; Java Development This is the mailing list for people discussing the development of significant Java applications for FreeBSD and the porting and maintenance of JDKs. &a.kde.name; KDE Discussions concerning KDE on FreeBSD systems. This is a technical mailing list for which strictly technical content is expected. &a.hackers.name; Technical discussions This is a forum for technical discussions related to FreeBSD. This is the primary technical mailing list. It is for individuals actively working on FreeBSD, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. This is a technical mailing list for which strictly technical content is expected. &a.hardware.name; General discussion of FreeBSD hardware General discussion about the types of hardware that FreeBSD runs on, various problems and suggestions concerning what to buy or avoid. &a.hubs.name; Mirror sites Announcements and discussion for people who run FreeBSD mirror sites. &a.isp.name; Issues for Internet Service Providers This mailing list is for discussing topics relevant to Internet Service Providers (ISPs) using FreeBSD. This is a technical mailing list for which strictly technical content is expected. &a.newbies.name; Newbies activities discussion We cover any of the activities of newbies that are not already dealt with elsewhere, including: independent learning and problem solving techniques, finding and using resources and asking for help elsewhere, how to use mailing lists and which lists to use, general chat, making mistakes, boasting, sharing ideas, stories, moral (but not technical) support, and taking an active part in the FreeBSD community. We take our problems and support questions to freebsd-questions, and use freebsd-newbies to meet others who are doing the same things that we do as newbies. &a.openoffice.name; OpenOffice.org Discussions concerning the porting and maintenance of OpenOffice.org and StarOffice. &a.performance.name; Discussions about tuning or speeding up FreeBSD This mailing list exists to provide a place for hackers, administrators, and/or concerned parties to discuss performance related topics pertaining to FreeBSD. Acceptable topics includes talking about FreeBSD installations that are either under high load, are experiencing performance problems, or are pushing the limits of FreeBSD. Concerned parties that are willing to work toward improving the performance of FreeBSD are highly encouraged to subscribe to this list. This is a highly technical list ideally suited for experienced FreeBSD users, hackers, or administrators interested in keeping FreeBSD fast, robust, and scalable. This list is not a question-and-answer list that replaces reading through documentation, but it is a place to make contributions or inquire about unanswered performance related topics. &a.platforms.name; Porting to Non-Intel platforms Cross-platform FreeBSD issues, general discussion and proposals for non-Intel FreeBSD ports. This is a technical mailing list for which strictly technical content is expected. &a.policy.name; Core team policy decisions This is a low volume, read-only mailing list for FreeBSD Core Team Policy decisions. &a.ports.name; Discussion of ports Discussions concerning FreeBSD's ports collection (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected. &a.ports-bugs.name; Discussion of ports bugs Discussions concerning problem reports for FreeBSD's ports collection (/usr/ports), proposed ports, or modifications to ports. This is a technical mailing list for which strictly technical content is expected. &a.questions.name; User questions This is the mailing list for questions about FreeBSD. You should not send how to questions to the technical lists unless you consider the question to be pretty technical. &a.scsi.name; SCSI subsystem This is the mailing list for people working on the SCSI subsystem for FreeBSD. This is a technical mailing list for which strictly technical content is expected. &a.security.name; Security issues FreeBSD computer security issues (DES, Kerberos, known security holes and fixes, etc). This is a technical mailing list for which strictly technical discussion is expected. Note that this is not a question-and-answer list, but that contributions (BOTH question AND answer) to the FAQ are welcome. &a.security-notifications.name; Security Notifications Notifications of FreeBSD security problems and fixes. This is not a discussion list. The discussion list is FreeBSD-security. &a.small.name; Using FreeBSD in embedded applications This list discusses topics related to unusually small and embedded FreeBSD installations. This is a technical mailing list for which strictly technical content is expected. &a.stable.name; Discussions about the use of &os.stable; This is the mailing list for users of &os.stable;. It includes warnings about new features coming out in -STABLE that will affect the users, and instructions on steps that must be taken to remain -STABLE. Anyone running STABLE should subscribe to this list. This is a technical mailing list for which strictly technical content is expected. &a.standards.name; C99 & POSIX Conformance This is a forum for technical discussions related to FreeBSD Conformance to the C99 and the POSIX standards. &a.usergroups.name; User Group Coordination List This is the mailing list for the coordinators from each of the local area Users Groups to discuss matters with each other and a designated individual from the Core Team. This mail list should be limited to meeting synopsis and coordination of projects that span User Groups. &a.vendors.name; Vendors Coordination discussions between The FreeBSD Project and Vendors of software and hardware for FreeBSD. Usenet Newsgroups In addition to two FreeBSD specific newsgroups, there are many others in which FreeBSD is discussed or are otherwise relevant to FreeBSD users. Keyword searchable archives are available for some of these newsgroups from courtesy of Warren Toomey wkt@cs.adfa.edu.au. BSD Specific Newsgroups comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (German) fr.comp.os.bsd (French) Other Unix Newsgroups of Interest comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web Servers - http://www.FreeBSD.org/ - — Central Server. + — Central Server. - http://www.ar.FreeBSD.org/ — Armenia. + — Armenia. - http://www.au.FreeBSD.org/ — Australia/1. - + — Australia/1. + - http://www2.au.FreeBSD.org/ — Australia/2. + — Australia/2. - http://www3.au.FreeBSD.org/ — Australia/3. + — Australia/3. - http://www4.au.FreeBSD.org/ — Australia/4. + — Australia/4. - http://www5.au.FreeBSD.org/ — Australia/5. + — Australia/5. - http://www6.au.FreeBSD.org/ — Australia/6. + — Australia/6. - http://freebsd.itworks.com.au/ — Australia/7. + — Australia/7. - http://www.at.FreeBSD.org/ — Austria. + — Austria. - http://www2.at.FreeBSD.org/ — Austria/2. + — Austria/2. - http://freebsd.unixtech.be/ — Belgium. + — Belgium. - http://www.br.FreeBSD.org/www.freebsd.org/ — Brazil/1. + — Brazil/1. - http://www2.br.FreeBSD.org/www.freebsd.org/ — Brazil/2. + — Brazil/2. - http://www3.br.FreeBSD.org/ — Brazil/3. + — Brazil/3. - http://www.bg.FreeBSD.org/ — Bulgaria. + — Bulgaria. - http://www.ca.FreeBSD.org/ — Canada. + — Canada. - http://www.cn.FreeBSD.org/ — China. + — China. - http://www.cz.FreeBSD.org/ — Czech Republic. + — Czech Republic. - http://www.dk.FreeBSD.org/ — Denmark. + — Denmark. - http://www3.dk.FreeBSD.org/ — Denmark/3. + — Denmark/3. - http://www.ee.FreeBSD.org/ — Estonia. + — Estonia. - http://www.fi.FreeBSD.org/ — Finland. + — Finland. - http://www2.fi.FreeBSD.org/ — Finland/2. + — Finland/2. - http://www.fr.FreeBSD.org/ — France. + — France. - http://www.de.FreeBSD.org/ — Germany/1. + — Germany/1. - http://www1.de.FreeBSD.org/ — Germany/2. + — Germany/2. - http://www2.de.FreeBSD.org/ — Germany/3. + — Germany/3. - http://www.gr.FreeBSD.org/ — Greece. + — Greece. - http://www.hk.FreeBSD.org/ — Hong Kong. + — Hong Kong. - http://www.hu.FreeBSD.org/ — Hungary. + — Hungary. - http://www2.hu.FreeBSD.org/ — Hungary/2. + — Hungary/2. - http://www.is.FreeBSD.org/ — Iceland. + — Iceland. - http://www.ie.FreeBSD.org/ — Ireland. + — Ireland. - http://www2.ie.FreeBSD.org/ — Ireland/2. + — Ireland/2. - http://www.it.FreeBSD.org/ — Italy. + — Italy. - http://www.gufi.org/mirrors/www.freebsd.org/data/ — Italy/2. + — Italy/2. - http://www.jp.FreeBSD.org/www.FreeBSD.org/ — Japan. + — Japan. - http://www.kr.FreeBSD.org/ — Korea/1. + — Korea/1. - http://www2.kr.FreeBSD.org/ — Korea/2. + — Korea/2. - http://www3.kr.FreeBSD.org/ — Korea/3. + — Korea/3. - http://www.lv.FreeBSD.org/ — Latvia. + — Latvia. - http://www.lt.FreeBSD.org/ — Lithuania. + — Lithuania. - http://rama.asiapac.net/freebsd/ — Malaysia. + — Malaysia. - http://www.nl.FreeBSD.org/ — Netherlands/1. + — Netherlands/1. - http://www2.nl.FreeBSD.org/ — Netherlands/2. + — Netherlands/2. - http://www.no.FreeBSD.org/ — Norway. + — Norway. - http://www2.no.FreeBSD.org/ — Norway/2. + — Norway/2. - http://www.nz.FreeBSD.org/ — New Zealand. + — New Zealand. - http://www.FreeBSD.org.ph/ — Philippines. + — Philippines. - http://www.pl.FreeBSD.org/ — Poland/1. + — Poland/1. - http://www2.pl.FreeBSD.org/ — Poland/2. + — Poland/2. - http://www2.pt.FreeBSD.org/ — Portugal/2. + — Portugal/2. - http://www3.pt.FreeBSD.org/ — Portugal/3. + — Portugal/3. - http://www4.pt.FreeBSD.org/ — Portugal/4. + — Portugal/4. - http://www.ro.FreeBSD.org/ — Romania. + — Romania. - http://www2.ro.FreeBSD.org/ — Romania/2. + — Romania/2. - http://www3.ro.FreeBSD.org/ — Romania/3. + — Romania/3. - http://www4.ro.FreeBSD.org/ — Romania/4. + — Romania/4. - http://www.ru.FreeBSD.org/ — Russia/1. + — Russia/1. - http://www2.ru.FreeBSD.org/ — Russia/2. + — Russia/2. - http://www3.ru.FreeBSD.org/ — Russia/3. + — Russia/3. - http://www4.ru.FreeBSD.org/ — Russia/4. + — Russia/4. - http://www.sm.FreeBSD.org/ — San Marino. + — San Marino. - http://www2.sg.FreeBSD.org/ — Singapore. + — Singapore. - http://www.sk.FreeBSD.org/ — Slovak Republic. + — Slovak Republic. - http://www2.sk.FreeBSD.org/ — Slovak Republic/2. + — Slovak Republic/2. - http://www.si.FreeBSD.org/ — Slovenia. + — Slovenia. - http://www2.si.FreeBSD.org/ — Slovenia/2. + — Slovenia/2. - http://www.es.FreeBSD.org/ — Spain. + — Spain. - http://www2.es.FreeBSD.org/ — Spain/2. + — Spain/2. - http://www3.es.FreeBSD.org/ — Spain/3. + — Spain/3. - http://www.za.FreeBSD.org/ — South Africa/1. + — South Africa/1. - http://www2.za.FreeBSD.org/ — South Africa/2. + — South Africa/2. - http://www.se.FreeBSD.org/ — Sweden. + — Sweden. - http://www2.se.FreeBSD.org/ — Sweden/2. + — Sweden/2. - http://www.ch.FreeBSD.org/ — Switzerland. + — Switzerland. - http://www2.ch.FreeBSD.org/ — Switzerland/2. + — Switzerland/2. - http://www.tw.FreeBSD.org/ — Taiwan. + — Taiwan. - http://www2.tw.FreeBSD.org/ — Taiwan/2. + — Taiwan/2. - http://www3.tw.FreeBSD.org/ — Taiwan/3. + — Taiwan/3. - http://www4.tw.FreeBSD.org/ — Taiwan/4. + — Taiwan/4. - http://www.tr.FreeBSD.org/ — Turkey. + — Turkey. - http://www2.tr.FreeBSD.org/ — Turkey/2. + — Turkey/2. - http://www.enderunix.org/freebsd/ — Turkey/3. + — Turkey/3. - http://www.ua.FreeBSD.org/www.freebsd.org/ — Ukraine/1. + — Ukraine/1. - http://www2.ua.FreeBSD.org/ — Ukraine/2. + — Ukraine/2. - http://www4.ua.FreeBSD.org/ — Ukraine/Crimea. + — Ukraine/Crimea. - http://www5.ua.FreeBSD.org/ — Ukraine/5. + — Ukraine/5. - http://www.uk.FreeBSD.org/ — United Kingdom/1. + — United Kingdom/1. - http://www2.uk.FreeBSD.org/ — United Kingdom/2. + — United Kingdom/2. - http://www3.uk.FreeBSD.org/ — United Kingdom/3. + — United Kingdom/3. - http://www4.uk.FreeBSD.org/ — United Kingdom/4. + — United Kingdom/4. - http://www2.FreeBSD.org/ — USA/Texas. + — USA/Texas. - http://www3.FreeBSD.org/ — USA/3. + — USA/3. - http://www7.FreeBSD.org/ — USA/7. + — USA/7. Email Addresses The following user groups provide FreeBSD related email addresses for their members. The listed administrator reserves the right to revoke the address if it is abused in any way. Domain Facilities User Group Administrator ukug.uk.FreeBSD.org Forwarding only freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Shell Accounts The following user groups provide shell accounts for people who are actively supporting the FreeBSD project. The listed administrator reserves the right to cancel the account if it is abused in any way. Host Access Facilities Administrator storm.uk.FreeBSD.org SSH only Read-only cvs, personal web space, email &a.brian; dogma.freebsd-uk.eu.org Telnet/FTP/SSH Email, Web space, Anonymous FTP Lee Johnston lee@uk.FreeBSD.org diff --git a/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml b/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml index fbabd65f62..202933f2b4 100644 --- a/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml @@ -1,973 +1,973 @@ Andrey A. Chernov Contributed by Michael C. Wu Rewritten by Localization - I18N/L10N Usage and Setup Synopsis FreeBSD is a very distributed project with users and contributors located all over the world. This chapter discusses the internationalization and localization features of FreeBSD that allow non-English speaking users to get real work done. There are many aspects of the i18n implementation in both the system and application levels, so where applicable we refer the reader to more specific sources of documentation. After reading this chapter, you will know: How different languages and locales are encoded on modern operating systems. How to set the locale for your login shell. How to configure your console for non-English languages. How to use X Windows effectively with different languages. Where to find more information about writing i18n-compliant applications. Before reading this chapter, you should: Know how to install additional third-party applications (). The Basics What is I18N/L10N? internationalization localization Developers shortened internationalization into the term I18N, counting the number of letters between the first and the last letters of internationalization. L10N uses the same naming scheme, coming from localization. Combined together, I18N/L10N methods, protocols, and applications allow users to use languages of their choice. I18N applications are programmed using I18N kits under libraries. It allows for developers to write a simple file and translate displayed menus and texts to each language. We strongly encourage programmers to follow this convention. Why Should I Use I18N/L10N? I18N/L10N is used whenever you wish to either view, input, or process data in non-English languages. What Languages Are Supported in the I18N Effort? I18N and L10N are not FreeBSD specific. Currently, one can choose from most of the major languages of the World, including but not limited to: Chinese, German, Japanese, Korean, French, Russian, Vietnamese and others. Using Localization In all its splendor, I18N is not FreeBSD-specific and is a convention. We encourage you to help FreeBSD in following this convention. locale Localization settings are based on three main terms: Language Code, Country Code, and Encoding. Locale names are constructed from these parts as follows: LanguageCode_CountryCode.Encoding Language and Country Codes language codes country codes In order to localize a FreeBSD system to a specific language (or any other I18N-supporting Unixes), the user needs to find out the codes for the specify country and language (country codes tell applications what variation of given language to use). In addition, web browsers, SMTP/POP servers, web servers, etc. make decisions based on them. The following are examples of language/country codes: Language/Country Code Description en_US English - United States ru_RU Russian for Russia zh_TW Traditional Chinese for Taiwan Encodings encodings ASCII Some languages use non-ASCII encodings that are 8-bit, wide or multibyte characters, see &man.multibyte.3; for more details. Older applications do not recognize them and mistake them for control characters. Newer applications usually do recognize 8-bit characters. Depending on the implementation, users may be required to compile an application with wide or multibyte characters support, or configure it correctly. To be able to input and process wide or multibyte characters, the FreeBSD Ports collection has provided each language with different programs. Refer to the I18N documentation in the respective FreeBSD Port. Specifically, the user needs to look at the application documentation to decide on how to configure it correctly or to pass correct values into the configure/Makefile/compiler. Some things to keep in mind are: Language specific single C chars character sets (see &man.multibyte.3;), i.e., ISO-8859-1, ISO-8859-15, KOI8-R, CP437. Wide or multibyte encodings, i.e. EUC, Big5. You can check the active list of character sets at the IANA Registry. FreeBSD versions 4.5 and up use X11-compatible locale encodings instead. I18N Applications In the FreeBSD Ports and Package system, I18N applications have been named with I18N in their names for easy identification. However, they do not always support the language needed. Setting Locale Usually it is sufficient to export the value of the locale name as LANG in the login shell. This could be done in the user's ~/.login_conf file or in the startup file of the user's shell (~/.profile, ~/.bashrc, ~/.cshrc). There is no need to set the locale subsets such as LC_CTYPE, LC_CTIME. Please refer to language-specific FreeBSD documentation for more information. You should set the following two environment variables in your configuration files: POSIX LANG for POSIX &man.setlocale.3; family functions MIME MM_CHARSET for applications' MIME character set This includes the user shell configuration, the specific application configuration, and the X11 configuration. Setting Locale Methods locale login class There are two methods for setting locale, and both are described below. The first (recommended one) is by assigning the environment variables in login class, and the second is by adding the environment variable assignments to the system's shell startup file. Login Classes Method This method allows environment variables needed for locale name and MIME character sets to be assigned once for every possible shell instead of adding specific shell assignments to each shell's startup file. User Level Setup can be done by an user himself and Administrator Level Setup require superuser privileges. User Level Setup Here is a minimal example of a .login_conf file in user's home directory which has both variables set for Latin-1 encoding: me:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO8859-1: Traditional Chinese / BIG-5 encoding Here is an example of a .login_conf that sets the variables for Traditional Chinese in BIG-5 encoding. Notice the many more variables set because some software does not respect locale variables correctly for Chinese, Japanese, and Korean. #Users who do not wish to use monetary units or time formats #of Taiwan can manually change each variable me:\ lang=zh_TW.Big5:\ lc_all=zh_TW.Big:\ lc_collate=zh_TW.Big5:\ lc_ctype=zh_TW.Big5:\ lc_messages=zh_TW.Big5:\ lc_monetary=zh_TW.Big5:\ lc_numeric=zh_TW.Big5:\ lc_time=zh_TW.Big5:\ charset=big5:\ xmodifiers="@im=xcin": #Setting the XIM Input Server See Administrator Level Setup and &man.login.conf.5; for more details. Administrator Level Setup Verify that the user's login class in /etc/login.conf sets the correct language. Make sure these settings appear in /etc/login.conf: language_name:accounts_title:\ :charset=MIME_charset:\ :lang=locale_name:\ :tc=default: So sticking with our previous example using Latin-1, it would look like this: german:German Users Accounts:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO8859-1:\ :tc=default: Changing Login Classes with &man.vipw.8; vipw Use vipw to add new users, and make the entry look like this: user:password:1111:11:language:0:0:User Name:/home/user:/bin/sh Changing Login Classes with &man.adduser.8; adduser login class Use adduser to add new users, and do the following: Set defaultclass = language in /etc/adduser.conf. Keep in mind you must enter a default class for all users of other languages in this case. An alternative variant is answering the specified language each time that Enter login class: default []: appears from &man.adduser.8;. Another alternative is to use the following for each user of a different language that you wish to add: &prompt.root; adduser -class language Changing Login Classes with &man.pw.8; pw If you use &man.pw.8; for adding new users, call it in this form: &prompt.root; pw useradd user_name -L language Shell Startup File Method This method is not recommended because it requires a different setup for each possible shell program chosen. Use the Login Class Method instead. MIME locale To add the locale name and MIME character set, just set the two environment variables shown below in the /etc/profile and/or /etc/csh.login shell startup files. We will use the German language as an example below: In /etc/profile: LANG=de_DE.ISO8859-1; export LANG MM_CHARSET=ISO-8859-1; export MM_CHARSET Or in /etc/csh.login: setenv LANG de_DE.ISO8859-1 setenv MM_CHARSET ISO-8859-1 Alternatively, you can add the above instructions to /usr/share/skel/dot.profile (similar to what was used in /etc/profile above), or /usr/share/skel/dot.login (similar to what was used in /etc/csh.login above). For X11: In $HOME/.xinitrc: LANG=de_DE.ISO8859-1; export LANG Or: setenv LANG de_DE.ISO8859-1 Depending on your shell (see above). Console Setup For all single C chars character sets, set the correct console fonts in /etc/rc.conf for the language in question with: font8x16=font_name font8x14=font_name font8x8=font_name The font_name here is taken from the /usr/share/syscons/fonts directory, without the .fnt suffix. sysinstall keymap screenmap Also be sure to set the correct keymap and screenmap for your single C chars character set through /stand/sysinstall. Once inside sysinstall, choose Configure, then Console. Alternatively, you can add the following to /etc/rc.conf: scrnmap=screenmap_name keymap=keymap_name keychange="fkey_number sequence" The screenmap_name here is taken from the /usr/share/syscons/scrnmaps directory, without the .scm suffix. A screenmap with a corresponding mapped font is usually needed as a workaround for expanding bit 8 to bit 9 on a VGA adapter's font character matrix in pseudographics area, i.e., to move letters out of that area if screen font uses a bit 8 column. If you have the moused daemon enabled by setting the following in your /etc/rc.conf: moused_enable="YES" then examine the mouse cursor information in the next paragraph. moused By default the mouse cursor of the &man.syscons.4; driver occupies the 0xd0-0xd3 range in the character set. If your language uses this range, you need to move the cursor's range outside of it. To enable the workaround for FreeBSD versions before 5.0, insert the following line into your kernel configuration: options SC_MOUSE_CHAR=0x03 For the FreeBSD versions 4.4 and up insert the following line into /etc/rc.conf: mousechar_start=3 The keymap_name here is taken from the /usr/share/syscons/keymaps directory, without the .kbd suffix. If you're uncertain which keymap to use, you use can &man.kbdmap.1; to test keymaps without rebooting. The keychange is usually needed to program function keys to match the selected terminal type because function key sequences cannot be defined in the key map. Also be sure to set the correct console terminal type in /etc/ttys for all ttyv* entries. Current pre-defined correspondences are: Character Set Terminal Type ISO-8859-1 or ISO-8859-15 cons25l1 ISO-8859-2 cons25l2 ISO-8859-7 cons25l7 KOI8-R cons25r KOI8-U cons25u CP437 (VGA default) cons25 US-ASCII cons25w For wide or multibyte characters languages, use the correct FreeBSD port in your /usr/ports/language directory. Some ports appear as console while the system sees it as serial vtty's, hence you must reserve enough vtty's for both X11 and the pseudo-serial console. Here is a partial list of applications for using other languages in console: Language Location Traditional Chinese (BIG-5) chinese/big5con Japanese japanese/ja-kon2-* or japanese/Mule_Wnn Korean korean/ko-han X11 Setup Although X11 is not part of the FreeBSD Project, we have included some information here for FreeBSD users. For more details, refer to the XFree86 web site or whichever X11 Server you use. In ~/.Xresources, you can additionally tune application specific I18N settings (e.g., fonts, menus, etc.). Displaying Fonts X11 True Type font server Install the X11 True Type-Common server (x11-servers/XttXF86srv-common) and install the language truetype fonts. Setting the correct locale should allow you to view your selected language in menus and such. Inputting Non-English Characters X11 Input Method (XIM) The X11 Input Method (XIM) Protocol is a new standard for all X11 clients. All X11 applications should be written as XIM clients that take input from XIM Input servers. There are several XIM servers available for different languages. Printer Setup Some single C chars character sets are usually hardware coded into printers. Wide or multibyte character sets require special setup and we recommend using apsfilter. You may also convert the document to PostScript or PDF formats using language specific converters. Kernel and File Systems The FreeBSD fast filesystem (FFS) is 8-bit clean, so it can be used with any single C chars character set (see &man.multibyte.3;), but there is no character set name stored in the filesystem; i.e., it is raw 8-bit and does not know anything about encoding order. Officially, FFS does not support any form of wide or multibyte character sets yet. However, some wide or multibyte character sets have independent patches for FFS enabling such support. They are only temporary unportable solutions or hacks and we have decided to not include them in the source tree. Refer to respective languages' web sites for more informations and the patch files. DOS Unicode The FreeBSD MS-DOS filesystem has the configurable ability to convert between MS-DOS, Unicode character sets and chosen FreeBSD filesystem character sets. See &man.mount.msdos.8; for details. Compiling I18N Programs Many FreeBSD Ports have been ported with I18N support. Some of them are marked with -I18N in the port name. These and many other programs have built in support for I18N and need no special consideration. MySQL However, some applications such as MySQL need to be have the Makefile configured with the specific charset. This is usually done in the Makefile or done by passing a value to configure in the source. Localizing FreeBSD to Specific Languages Andrey A. Chernov Originally contributed by Russian Language (KOI8-R encoding) localization Russian For more information about KOI8-R encoding, see the KOI8-R References (Russian Net Character Set). Locale Setup Put the following lines into your ~/.login_conf file: me:My Account:\ :charset=KOI8-R:\ :lang=ru_RU.KOI8-R: See earlier in this chapter for examples of setting up the locale. Console Setup For the FreeBSD versions before 5.0 add the following line to your kernel configuration file: options SC_MOUSE_CHAR=0x03 For the FreeBSD versions 4.4 and up insert the following line into /etc/rc.conf: mousechar_start=3 Use following settings in /etc/rc.conf: keymap="ru.koi8-r" scrnmap="koi8-r2cp866" font8x16="cp866b-8x16" font8x14="cp866-8x14" font8x8="cp866-8x8" For each ttyv* entry in /etc/ttys, use cons25r as the terminal type. See earlier in this chapter for examples of setting up the console. Printer Setup printers Since most printers with Russian characters come with hardware code page CP866, a special output filter is needed to convert from KOI8-R to CP866. Such a filter is installed by default as /usr/libexec/lpr/ru/koi2alt. A Russian printer /etc/printcap entry should look like: lp|Russian local line printer:\ :sh:of=/usr/libexec/lpr/ru/koi2alt:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: See &man.printcap.5; for a detailed description. MS-DOS FS and Russian Filenames The following example &man.fstab.5; entry enables support for Russian filenames in mounted MS-DOS filesystems: /dev/ad0s2 /dos/c msdos rw,-Wkoi2dos,-Lru_RU.KOI8-R 0 0 See &man.mount.msdos.8; for a detailed description of the and options. X11 Setup Do non-X locale setup first as described. The Russian KOI8-R locale may not work with old XFree86 releases (lower than 3.3). XFree86 4.X is now the default version of the X Window System on FreeBSD. This should not be an issue unless you are using an old version of FreeBSD. Go to the russian/X.language directory and issue the following command: &prompt.root; make install The above port installs the latest version of the KOI8-R fonts. XFree86 3.3 already has some KOI8-R fonts, but these are scaled better. Check the "Files" section in your /etc/XF86Config file. The following lines must be added before any other FontPath entries: FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/misc" FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/100dpi" If you use a high resolution video mode, swap the 75 dpi and 100 dpi lines. To activate a Russian keyboard, add the following to the "Keyboard" section of your XF86Config file. For XFree86 3.X: XkbLayout "ru" XkbOptions "grp:caps_toggle" For XFree86 4.X: Option "XkbLayout" "ru" Option "XkbOptions" "grp:caps_toggle" Also make sure that XkbDisable is turned off (commented out) there. The RUS/LAT switch will be CapsLock. The old CapsLock function is still available via ShiftCapsLock (in LAT mode only). If you have Windows keys on your keyboard, and notice that some non-alphabetical keys are mapped incorrectly in RUS mode, add the following line in your XF86Config file. For XFree86 3.X: XkbVariant "winkeys" For XFree86 4.X: Option "XkbVariant" "winkeys" The Russian XKB keyboard may not work with old XFree86 versions, see the above note for more information. The Russian XKB keyboard may also not work with non-localized applications as well. Minimally localized applications should call a XtSetLanguageProc (NULL, NULL, NULL); function early in the program. See KOI8-R for X Window for more instructions on localizing X11 applications. Traditional Chinese Localization for Taiwan localization Traditional Chinese The FreeBSD-Taiwan Project has an I18N/L10N tutorial for - FreeBSD at http://freebsd.sinica.edu.tw/~ncvs/zh-l10n-tut/ + FreeBSD at using many Chinese ports. The editor for the zh-L10N-tut is Clive Lin Clive@CirX.org. You can also cvsup the following collections at freebsd.sinica.edu.tw: Collection Description outta-port tag=. Beta-quality ports collection for Chinese zh-L10N-tut tag=. Localizing FreeBSD Tutorial in BIG-5 Traditional Chinese zh-doc tag=. FreeBSD Documentation Translation to BIG-5 Traditional Chinese Chuan-Hsing Shen s874070@mail.yzu.edu.tw has created the Chinese FreeBSD Collection (CFC) using FreeBSD-Taiwan's zh-L10N-tut. The packages and the script files - are available at ftp://ftp.csie.ncu.edu.tw/OS/FreeBSD/taiwan/CFC/. + are available at . German Language Localization (For All ISO 8859-1 Languages) localization German Slaven Rezic eserte@cs.tu-berlin.de wrote a tutorial how to use umlauts on a FreeBSD machine. The tutorial - is written in German and available at http://www.de.FreeBSD.org/de/umlaute/. + is written in German and available at + . Japanese and Korean Language Localization localization Japanese localization Korean - For Japanese, refer to http://www.jp.FreeBSD.org/, - and for Korean, refer to http://www.kr.FreeBSD.org/. + For Japanese, refer to + , + and for Korean, refer to + . Non-English FreeBSD Documentation Some FreeBSD contributors have translated parts of FreeBSD to other languages. They are available through links on the main site or in /usr/share/doc. diff --git a/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml b/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml index c8bb5fd1ab..c5e59080f1 100644 --- a/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml @@ -1,3097 +1,3097 @@ Jim Mock Restructured and parts updated by Brian N. Handy Originally contributed by Rich Murphey Linux Binary Compatibility Synopsis Linux binary compatibility binary compatibility Linux FreeBSD provides binary compatibility with several other Unix-like operating systems, including Linux. At this point, you may be asking yourself why exactly, does FreeBSD need to be able to run Linux binaries? The answer to that question is quite simple. Many companies and developers develop only for Linux, since it is the latest hot thing in the computing world. That leaves the rest of us FreeBSD users bugging these same companies and developers to put out native FreeBSD versions of their applications. The problem is, that most of these companies do not really realize how many people would use their product if there were FreeBSD versions too, and most continue to only develop for Linux. So what is a FreeBSD user to do? This is where the Linux binary compatibility of FreeBSD comes into play. In a nutshell, the compatibility allows FreeBSD users to run about 90% of all Linux applications without modification. This includes applications such as Star Office, the Linux version of Netscape, Adobe Acrobat, RealPlayer 5 and 7, VMWare, Oracle, WordPerfect, Doom, Quake, and more. It is also reported that in some situations, Linux binaries perform better on FreeBSD than they do under Linux. Linux /proc file system There are, however, some Linux-specific operating system features that are not supported under FreeBSD. Linux binaries will not work on FreeBSD if they overly use the Linux /proc file system (which is different from FreeBSD's /proc file system), or i386-specific calls, such as enabling virtual 8086 mode. After reading this chapter, you will know: How to enable Linux binary compatibility on your system. How to install additional Linux shared libraries. How to install Linux applications on your FreeBSD system. The implementation details of Linux compatibility in FreeBSD. Before reading this chapter, you should: Know how to install additional third-party software (). Installation KLD (kernel loadable object) Linux binary compatibility is not turned on by default. The easiest way to enable this functionality is to load the linux KLD object (Kernel LoaDable object). You can load this module by simply typing linux at the command prompt. If you would like Linux compatibility to always be enabled, then you should add the following line to /etc/rc.conf: linux_enable="YES" The &man.kldstat.8; command can be used to verify that the KLD is loaded: &prompt.user; kldstat Id Refs Address Size Name 1 2 0xc0100000 16bdb8 kernel 7 1 0xc24db000 d000 linux.ko kernel options LINUX If for some reason you do not want to or cannot load the KLD, then you may statically link Linux binary compatibility into the kernel by adding options LINUX to your kernel configuration file. Then install your new kernel as described in . Installing Linux Runtime Libraries Linux installing Linux libraries This can be done one of two ways, either by using the linux_base port, or by installing them manually. Installing Using the linux_base Port ports collection This is by far the easiest method to use when installing the runtime libraries. It is just like installing any other port from the ports collection. Simply do the following: &prompt.root; cd /usr/ports/emulators/linux_base &prompt.root; make install distclean You should now have working Linux binary compatibility. Some programs may complain about incorrect minor versions of the system libraries. In general, however, this does not seem to be a problem. Installing Libraries Manually If you do not have the ports collection installed, you can install the libraries by hand instead. You will need the Linux shared libraries that the program depends on and the runtime linker. Also, you will need to create a shadow root directory, /compat/linux, for Linux libraries on your FreeBSD system. Any shared libraries opened by Linux programs run under FreeBSD will look in this tree first. So, if a Linux program loads, for example, /lib/libc.so, FreeBSD will first try to open /compat/linux/lib/libc.so, and if that does not exist, it will then try /lib/libc.so. Shared libraries should be installed in the shadow tree /compat/linux/lib rather than the paths that the Linux ld.so reports. Generally, you will need to look for the shared libraries that Linux binaries depend on only the first few times that you install a Linux program on your FreeBSD system. After a while, you will have a sufficient set of Linux shared libraries on your system to be able to run newly imported Linux binaries without any extra work. How to Install Additional Shared Libraries shared libraries What if you install the linux_base port and your application still complains about missing shared libraries? How do you know which shared libraries Linux binaries need, and where to get them? Basically, there are 2 possibilities (when following these instructions you will need to be root on your FreeBSD system). If you have access to a Linux system, see what shared libraries the application needs, and copy them to your FreeBSD system. Look at the following example: Let us assume you used FTP to get the Linux binary of Doom, and put it on a Linux system you have access to. You then can check which shared libraries it needs by running ldd linuxdoom, like so: &prompt.user; ldd linuxdoom libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 symbolic links You would need to get all the files from the last column, and put them under /compat/linux, with the names in the first column as symbolic links pointing to them. This means you eventually have these files on your FreeBSD system: /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3.1.0 /compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0 /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
Note that if you already have a Linux shared library with a matching major revision number to the first column of the ldd output, you will not need to copy the file named in the last column to your system, the one you already have should work. It is advisable to copy the shared library anyway if it is a newer version, though. You can remove the old one, as long as you make the symbolic link point to the new one. So, if you have these libraries on your system: /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 and you find a new binary that claims to require a later version according to the output of ldd: libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 If it is only one or two versions out of date in the in the trailing digit then do not worry about copying /lib/libc.so.4.6.29 too, because the program should work fine with the slightly older version. However, if you like, you can decide to replace the libc.so anyway, and that should leave you with: /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29
The symbolic link mechanism is only needed for Linux binaries. The FreeBSD runtime linker takes care of looking for matching major revision numbers itself and you do not need to worry about it.
Installing Linux ELF Binaries Linux ELF binaries ELF binaries sometimes require an extra step of branding. If you attempt to run an unbranded ELF binary, you will get an error message like the following: &prompt.user; ./my-linux-elf-binary ELF binary type not known Abort To help the FreeBSD kernel distinguish between a FreeBSD ELF binary from a Linux binary, use the &man.brandelf.1; utility. &prompt.user; brandelf -t Linux my-linux-elf-binary GNU toolchain The GNU toolchain now places the appropriate branding information into ELF binaries automatically, so this step should become increasingly more rare in the future. Configuring the Hostname Resolver If DNS does not work or you get this message: resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword You will need to configure a /compat/linux/etc/host.conf file containing: order hosts, bind multi on The order here specifies that /etc/hosts is searched first and DNS is searched second. When /compat/linux/etc/host.conf is not installed, Linux applications find FreeBSD's /etc/host.conf and complain about the incompatible FreeBSD syntax. You should remove bind if you have not configured a name server using the /etc/resolv.conf file. Murray Stokely Updated for Mathematica 4.X by Bojan Bistrovic Merged with work by Installing Mathematica applications Mathematica This document describes the process of installing the Linux version of Mathematica 4.X onto a FreeBSD system. The Linux version of Mathematica runs perfectly under FreeBSD however the binaries shipped by Wolfram need to be branded so that FreeBSD knows to use the Linux ABI to execute them. The Linux version of Mathematica or Mathematica for Students can - be ordered directly from Wolfram at http://www.wolfram.com/. + be ordered directly from Wolfram at + . Branding the Linux Binaries The Linux binaries are located in the Unix directory of the Mathematica CDROM distributed by Wolfram. You need to copy this directory tree to your local hard drive so that you can brand the Linux binaries with &man.brandelf.1; before running the installer: &prompt.root; mount /cdrom &prompt.root; cp -rp /cdrom/Unix/ /localdir/ &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Kernel/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/FrontEnd/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Installation/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Graphics/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/Converters/Binaries/Linux/* &prompt.root; brandelf -t Linux /localdir/Files/SystemFiles/LicenseManager/Binaries/Linux/mathlm &prompt.root; cd /localdir/Installers/Linux/ &prompt.root; ./MathInstaller Alternatively, you can simply set the default ELF brand to Linux for all unbranded binaries with the command: &prompt.root; sysctl kern.fallback_elf_brand=3 This will make FreeBSD assume that unbranded ELF binaries use the Linux ABI and so you should be able to run the installer straight from the CDROM. Obtaining Your Mathematica Password Before you can run Mathematica you will have to obtain a password from Wolfram that corresponds to your machine ID. Ethernet MAC address Once you have installed the Linux compatibility runtime libraries and unpacked Mathematica you can obtain the machine ID by running the program mathinfo in the Install directory. This machine ID is based solely on the MAC address of your first Ethernet card. &prompt.root; cd /localdir/Files/SystemFiles/Installation/Binaries/Linux &prompt.root; mathinfo disco.example.com 7115-70839-20412 When you register with Wolfram, either by email, phone or fax, you will give them the machine ID and they will respond with a corresponding password consisting of groups of numbers. You can then enter this information when you attempt to run Mathematica for the first time exactly as you would for any other Mathematica platform. Running the Mathematica Frontend over a Network Mathematica uses some special fonts to display characters not present in any of the standard font sets (integrals, sums, Greek letters, etc.). The X protocol requires these fonts to be install locally. This means you will have to copy these fonts from the CDROM or from a host with Mathematica installed to your local machine. These fonts are normally stored in /cdrom/Unix/Files/SystemFiles/Fonts on the CDROM, or /usr/local/mathematica/SystemFiles/Fonts on your hard drive. The actual fonts are in the subdirectories Type1 and X. There are several ways to use them, as described below. The first way is to copy them into one of the existing font directories in /usr/X11R6/lib/X11/fonts. This will require editing the fonts.dir file, adding the font names to it, and changing the number of fonts on the first line. Alternatively, you should also just be able to run mkfontdir in the directory you have copied them to. The second way to do this is to copy the directories to /usr/X11R6/lib/X11/fonts: &prompt.root; cd /usr/X11R6/lib/X11/fonts &prompt.root; mkdir X &prompt.root; mkdir MathType1 &prompt.root; cd /cdrom/Unix/Files/SystemFiles/Fonts &prompt.root; cp X/* /usr/X11R6/lib/X11/fonts/X &prompt.root; cp Type1/* /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; cd /usr/X11R6/lib/X11/fonts/X &prompt.root; mkfontdir &prompt.root; cd ../MathType1 &prompt.root; mkfontdir Now add the new font directories to your font path: &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/X &prompt.root; xset fp+ /usr/X11R6/lib/X11/fonts/MathType1 &prompt.root; xset fp rehash If you are using the XFree86 server, you can have these font directories loaded automatically by adding them to your XF86Config file. fonts If you do not already have a directory called /usr/X11R6/lib/X11/fonts/Type1, you can change the name of the MathType1 directory in the example above to Type1. Aaron Kaplan Contributed by Robert Getschmann Thanks to Installing Maple applications Maple Maple is a commercial mathematics program similar to Mathematica. You must purchase this software from and then register there for a license file. To install this software on FreeBSD, please follow these simple steps. Execute the INSTALL shell script from the product distribution. Choose the RedHat option when prompted by the installation program. A typical installation directory might be /usr/local/maple. If you have not done so, order a license for Maple from Maple Waterloo Software (http://register.maplesoft.com) and copy it to /usr/local/maple/license/license.dat. Install the FLEXlm license manager by running the INSTALL_LIC install shell script that comes with Maple. Specify the primary hostname for your machine for the license server. Patch the usr/local/maple/bin/maple.system.type file with the following: ----- snip ------------------ *** maple.system.type.orig Sun Jul 8 16:35:33 2001 --- maple.system.type Sun Jul 8 16:35:51 2001 *************** *** 72,77 **** --- 72,78 ---- # the IBM RS/6000 AIX case MAPLE_BIN="bin.IBM_RISC_UNIX" ;; + "FreeBSD"|\ "Linux") # the Linux/x86 case # We have two Linux implementations, one for Red Hat and ----- snip end of patch ----- Please note that after the "FreeBSD"|\ no other whitespace should be present. This patch instructs Maple to recognize FreeBSD as a type of Linux system. The bin/maple shell script calls the bin/maple.system.type shell script which in turn calls uname -a to find out the operating system name. Depending on the OS name it will find out which binaries to use. Start the license server. The following script, installed as /usr/local/etc/rc.d/lmgrd.sh is a convenient way to start up lmgrd: ----- snip ------------ #! /bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin PATH=${PATH}:/usr/local/maple/bin:/usr/local/maple/FLEXlm/UNIX/LINUX export PATH LICENSE_FILE=/usr/local/maple/license/license.dat LOG=/var/log/lmgrd.log case "$1" in start) lmgrd -c ${LICENSE_FILE} 2>> ${LOG} 1>&2 echo -n " lmgrd" ;; stop) lmgrd -c ${LICENSE_FILE} -x lmdown 2>> ${LOG} 1>&2 ;; *) echo "Usage: `basename $0` {start|stop}" 1>&2 exit 64 ;; esac exit 0 ----- snip ------------ Test-start maple: &prompt.user; cd /usr/local/maple/bin &prompt.user; ./xmaple You should be up and running. Make sure to write Maplesoft to let them know you would like a native FreeBSD version! Common Pitfalls The FLEXlm license manager can be a difficult tool to work with. Additional documentation on the subject can be found at . lmgrd is known to be very picky about the license file and to core dump if there are any problems. A correct license file should look like this: # ======================================================= # License File for UNIX Installations ("Pointer File") # ======================================================= SERVER chillig ANY #USE_SERVER VENDOR maplelmg FEATURE Maple maplelmg 2000.0831 permanent 1 XXXXXXXXXXXX \ PLATFORMS=i86_r ISSUER="Waterloo Maple Inc." \ ISSUED=11-may-2000 NOTICE=" Technische Universitat Wien" \ SN=XXXXXXXXX Serial number and key 'X''ed out. chillig is a hostname. Editing the license file works as long as you do not touch the FEATURE line (which is protected by the license key). Marcel Moolenaar Contributed by Installing Oracle applications Oracle Preface This document describes the process of installing Oracle 8.0.5 and Oracle 8.0.5.1 Enterprise Edition for Linux onto a FreeBSD machine. Installing the Linux Environment Make sure you have both linux_base and linux_devtools from the ports collection installed. These ports are added to the collection after the release of FreeBSD 3.2. If you are using FreeBSD 3.2 or an older version for that matter, update your ports collection. You may want to consider updating your FreeBSD version too. If you run into difficulties with linux_base-6.1 or linux_devtools-6.1 you may have to use version 5.2 of these packages. If you want to run the intelligent agent, you will also need to install the Red Hat Tcl package: tcl-8.0.3-20.i386.rpm. The general command for installing packages with the official RPM port is: &prompt.root; rpm -i --ignoreos --root /compat/linux --dbpath /var/lib/rpm package Installation of the package should not generate any errors. Creating the Oracle Environment Before you can install Oracle, you need to set up a proper environment. This document only describes what to do specially to run Oracle for Linux on FreeBSD, not what has been described in the Oracle installation guide. Kernel Tuning kernel tuning As described in the Oracle installation guide, you need to set the maximum size of shared memory. Do not use SHMMAX under FreeBSD. SHMMAX is merely calculated out of SHMMAXPGS and PGSIZE. Therefore define SHMMAXPGS. All other options can be used as described in the guide. For example: options SHMMAXPGS=10000 options SHMMNI=100 options SHMSEG=10 options SEMMNS=200 options SEMMNI=70 options SEMMSL=61 Set these options to suit your intended use of Oracle. Also, make sure you have the following options in your kernel config-file: options SYSVSHM #SysV shared memory options SYSVSEM #SysV semaphores options SYSVMSG #SysV interprocess communication Oracle Account Create an Oracle account just as you would create any other account. The Oracle account is special only that you need to give it a Linux shell. Add /compat/linux/bin/bash to /etc/shells and set the shell for the Oracle account to /compat/linux/bin/bash. Environment Besides the normal Oracle variables, such as ORACLE_HOME and ORACLE_SID you must set the following environment variables: Variable Value LD_LIBRARY_PATH $ORACLE_HOME/lib CLASSPATH $ORACLE_HOME/jdbc/lib/classes111.zip PATH /compat/linux/bin /compat/linux/sbin /compat/linux/usr/bin /compat/linux/usr/sbin /bin /sbin /usr/bin /usr/sbin /usr/local/bin $ORACLE_HOME/bin It is advised to set all the environment variables in .profile. A complete example is: ORACLE_BASE=/oracle; export ORACLE_BASE ORACLE_HOME=/oracle; export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/lib export LD_LIBRARY_PATH ORACLE_SID=ORCL; export ORACLE_SID ORACLE_TERM=386x; export ORACLE_TERM CLASSPATH=$ORACLE_HOME/jdbc/lib/classes111.zip export CLASSPATH PATH=/compat/linux/bin:/compat/linux/sbin:/compat/linux/usr/bin PATH=$PATH:/compat/linux/usr/sbin:/bin:/sbin:/usr/bin:/usr/sbin PATH=$PATH:/usr/local/bin:$ORACLE_HOME/bin export PATH Installing Oracle Due to a slight inconsistency in the Linux emulator, you need to create a directory named .oracle in /var/tmp before you start the installer. Either make it world writable or let it be owner by the oracle user. You should be able to install Oracle without any problems. If you have problems, check your Oracle distribution and/or configuration first! After you have installed Oracle, apply the patches described in the next two subsections. A frequent problem is that the TCP protocol adapter is not installed right. As a consequence, you cannot start any TCP listeners. The following actions help solve this problem: &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk ntcontab.o &prompt.root; cd $ORACLE_HOME/lib &prompt.root; ar r libnetwork.a ntcontab.o &prompt.root; cd $ORACLE_HOME/network/lib &prompt.root; make -f ins_network.mk install Do not forget to run root.sh again! Patching root.sh When installing Oracle, some actions, which need to be performed as root, are recorded in a shell script called root.sh. root.sh is written in the orainst directory. Apply the following patch to root.sh, to have it use to proper location of chown or alternatively run the script under a Linux native shell. *** orainst/root.sh.orig Tue Oct 6 21:57:33 1998 --- orainst/root.sh Mon Dec 28 15:58:53 1998 *************** *** 31,37 **** # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/bin/chown # # Define variables to be used in this script --- 31,37 ---- # This is the default value for CHOWN # It will redefined later in this script for those ports # which have it conditionally defined in ss_install.h ! CHOWN=/usr/sbin/chown # # Define variables to be used in this script When you do not install Oracle from CD, you can patch the source for root.sh. It is called rthd.sh and is located in the orainst directory in the source tree. Patching genclntsh The script genclntsh is used to create a single shared client library. It is used when building the demos. Apply the following patch to comment out the definition of PATH: *** bin/genclntsh.orig Wed Sep 30 07:37:19 1998 --- bin/genclntsh Tue Dec 22 15:36:49 1998 *************** *** 32,38 **** # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst --- 32,38 ---- # # Explicit path to ensure that we're using the correct commands #PATH=/usr/bin:/usr/ccs/bin export PATH ! #PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin export PATH # # each product MUST provide a $PRODUCT/admin/shrept.lst Running Oracle When you have followed the instructions, you should be able to run Oracle as if it was run on Linux itself. Holger Kipp Contributed by Valentino Vaschetto Original version converted to SGML by Installing SAP R/3 applications SAP R/3 Installations of SAP Systems using FreeBSD will not be supported by the SAP support team — they only offer support for certified platforms. Preface This document describes a possible way of installing a SAP R/3-System with Oracle Database for Linux onto a FreeBSD machine, including the installation of FreeBSD and Oracle. Two different configurations will be described: SAP R/3 4.6B (IDES) with Oracle 8.0.5 on FreeBSD 4.3-STABLE SAP R/3 4.6C with Oracle 8.1.7 on FreeBSD 4.5-STABLE Even though this document tries to describe all important steps in a greater detail, it is not intended as a replacement for the Oracle and SAP R/3 installation guides. Please see the documentation that comes with the SAP R/3 Linux edition for SAP- and Oracle-specific questions, as well as resources from Oracle and SAP OSS. Software The following CD-ROMs have been used for SAP-installations: SAP R/3 4.6B, Oracle 8.0.5 Name Number Description KERNEL 51009113 SAP Kernel Oracle / Installation / AIX, Linux, Solaris RDBMS 51007558 Oracle / RDBMS 8.0.5.X / Linux EXPORT1 51010208 IDES / DB-Export / Disc 1 of 6 EXPORT2 51010209 IDES / DB-Export / Disc 2 of 6 EXPORT3 51010210 IDES / DB-Export / Disc 3 of 6 EXPORT4 51010211 IDES / DB-Export / Disc 4 of 6 EXPORT5 51010212 IDES / DB-Export / Disc 5 of 6 EXPORT6 51010213 IDES / DB-Export / Disc 6 of 6 Additionally, I used the Oracle 8 Server (Pre-production version 8.0.5 for Linux, Kernel Version 2.0.33) CD which is not really necessary, and of course FreeBSD 4.3-STABLE (it was only a few days past 4.3 RELEASE). SAP R/3 4.6C SR2, Oracle 8.1.7 Name Number Description KERNEL 51014004 SAP Kernel Oracle / SAP Kernel Version 4.6D / DEC, Linux RDBMS 51012930 Oracle 8.1.7/ RDBMS / Linux EXPORT1 51013953 Release 4.6C SR2 / Export / Disc 1 of 4 EXPORT1 51013953 Release 4.6C SR2 / Export / Disc 2 of 4 EXPORT1 51013953 Release 4.6C SR2 / Export / Disc 3 of 4 EXPORT1 51013953 Release 4.6C SR2 / Export / Disc 4 of 4 LANG1 51013954 Release 4.6C SR2 / Language / DE, EN, FR / Disc 1 of 3 Depending on the languages you would like to install, additional language CDs might be necessary. Here we're just using DE and EN, so the first Language-CD is the only one needed. As a little note, the numbers for all four export CDs are identical. All three language CDs also have the same number (this is different from the 4.6B IDES release CD numbering). At the time of writing this installation is running on FreeBSD 4.5-STABLE (20.03.2002). SAP-Notes The following notes should be read before installing SAP R/3 or proved to be useful during installation: SAP R/3 4.6B, Oracle 8.0.5 Number Title 0171356 SAP Software on Linux: Essential Comments 0201147 INST: 4.6C R/3 Inst. on UNIX - Oracle 0373203 Update / Migration Oracle 8.0.5 --> 8.0.6/8.1.6 LINUX 0072984 Release of Digital UNIX 4.0B for Oracle 0130581 R3SETUP step DIPGNTAB terminates 0144978 Your system has not been installed correctly 0162266 Questions and tips for R3SETUP on Windows NT / W2K SAP R/3 4.6C, Oracle 8.1.7 Number Title 0015023 Initializing table TCPDB (RSXP0004) (EBCDIC) 0045619 R/3 with several languages or typefaces 0171356 SAP Software on Linux: Essential Comments 0195603 RedHat 6.1 Enterprise version: Known problems 0212876 The new archiving tool SAPCAR 0300900 Linux: Released DELL Hardware 0377187 RedHat 6.2: important remarks 0387074 INST: R/3 4.6C SR2 Installation on UNIX 0387077 INST: R/3 4.6C SR2 Inst. on UNIX - Oracle 0387078 SAP Software on UNIX: OS Dependencies 4.6C SR2 Hardware-Requirements The following equipment is sufficient for the installation of a SAP R/3 System. For production use, a more exact sizing is of course needed: Component 4.6B 4.6C Processor 2 x 800MHz Pentium III 2 x 800MHz Pentium III Memory 1GB ECC 2GB ECC Hard Disk Space 50-60GB (IDES) 50-60GB (IDES) For use in production, Xeon-Processors with large cache, high-speed disk access (SCSI, RAID hardware controller), USV and ECC-RAM is recommended. The large amount of hard disk space is due to the preconfigured IDES System, which creates 27 GB of database files during installation. This space is also sufficient for initial production systems and application data. SAP R/3 4.6B, Oracle 8.0.5 The following off-the-shelf hardware was used: a dual processor board with 2 800 MHz Pentium III processors, Adaptec 29160 Ultra160 SCSI adapter (for accessing a 40/80 GB DLT tape drive and CDROM), Mylex AcceleRAID (2 channels, firmware 6.00-1-00 with 32 MB RAM). To the Mylex Raid-controller are attached two 17 GB hard disks (mirrored) and four 36 GB hard disks (RAID level 5). SAP R/3 4.6C, Oracle 8.1.7 For this installation a DELL PowerEdge 2500 was used: a dual processor board with two 1000 MHz Pentium III processors (256 kB Cache), 2 GB PC133 ECC SDRAM, PERC/3 DC PCI Raid Controller with 128 MB, and an EIDE DVD-ROM drive. To the RAID-controller are attached two 18 GB hard disks (mirrored) and four 36 GB hard disks (RAID level 5). Installation of FreeBSD First you have to install FreeBSD. There are several ways to do this (FreeBSD 4.3 was installed via FTP, FreeBSD 4.5 directly from release-CD). Disk Layout To keep it simple, the same disk layout both for the SAP R/3 46B- and SAP R/3 46C SR2-installation was used. Only the device names changed, as the installations were on different hardware (/dev/da and /dev/amr respectively, so if using an AMI MegaRAID, one will see /dev/amr0s1a instead of /dev/da0s1a): File system Size (1k-blocks) Size (GB) Mounted on /dev/da0s1a 1.016.303 1 / /dev/da0s1b 6 swap /dev/da0s1e 2.032.623 2 /var /dev/da0s1f 8.205.339 8 /usr /dev/da1s1e 45.734.361 45 /compat/linux/oracle /dev/da1s1f 2.032.623 2 /compat/linux/sapmnt /dev/da1s1g 2.032.623 2 /compat/linux/usr/sap Configure and initialize the two logical drives with the Mylex- or PERC/3 RAID software beforehand. The software can be started during the bios boot phase. Please note that this disk layout differs slightly from the SAP recommendations, as SAP suggests mounting the oracle-subdirectories (and some others) separately - I decided to just create them as real subdirectories for simplicity. <command>make world</command> and a New Kernel Download the latest stable-sources. Rebuild world and your custom kernel after configuring your kernel configuration file. Here you should also include the kernel parameters which are required for both SAP R/3 and Oracle. Installing the Linux Environment During the first installation with FreeBSD 4.3-STABLE I had some trouble downloading the required RPM-files (for 4.3 stable, 2nd May 2001), but with FreeBSD 4.5-STABLE, everything went very smooth. Should you encounter some problems, try to download those files by hand. For a list of RPM-Mirrors and required files, see the corresponding makefile. Installing Linux Base-system First the linux_base port needs to be installed (as root). This is currently linux_base-6. &prompt.root; cd /usr/ports/emulators/linux_base &prompt.root; make package Installing Linux Development The Linux development is needed, if you want to install Oracle on FreeBSD according to the corresponding description in the handbook: &prompt.root; cd /usr/ports/devel/linux_devtools &prompt.root; make package Linux Development has only been installed for the SAP R/3 46B IDES-installation. It is not needed, if the Oracle DB is not relinked on the FreeBSD system. This is the case if you are using the Oracle tarball from a linux system. Installing Necessary RPMs RPMs To start the R3SETUP-Program, PAM support is needed. During the first SAP-Installation on FreeBSD 4.3-STABLE I tried to install PAM with all the required packages and finally forced the installation of the PAM package, which worked. For SAP R/3 4.6C SR2 I directly forced the installation of the PAM-RPM, which also works, so it seems the dependent packages are not needed: &prompt.root; rpm -i --ignoreos --nodeps --root /compat/linux --dbpath /var/lib/rpm \ pam-0.68-7.i386.rpm For Oracle 8.0.5 to run the intelligent agent, I also had to install the RedHat Tcl package tcl-8.0.5-30.i386.rpm (otherwise the relinking during Oracle install will not work). There are some other issues regarding relinking of Oracle, but that is a Oracle-Linux issue, not FreeBSD specific. Some additional hints It might also be a good idea to add linprocfs to /etc/fstab. See man linprocfs. Another parameter to set is kern.fallback_elf_brand=3 which is done in file /etc/sysctl.conf. Creating the SAP/R3 Environment Creating the Necessary File Systems and Mountpoints For a simple installation, it is sufficient to create the following file systems: mount point size in GB /compat/linux/oracle 45 GB /compat/linux/sapmnt 2 GB /compat/linux/usr/sap 2 GB It is also necessary to created some links. Otherwise the SAP-Installer will complain, as it is checking the created links: &prompt.root; ln -s /compat/linux/oracle /oracle &prompt.root; ln -s /compat/linux/sapmnt /sapmnt &prompt.root; ln -s /compat/linux/usr/sap /usr/sap Possible error message during installation (here with System PRD and the SAP R/3 4.6C SR2 installation): INFO 2002-03-19 16:45:36 R3LINKS_IND_IND SyLinkCreate:200 Checking existence of symbolic link /usr/sap/PRD/SYS/exe/dbg to /sapmnt/PRD/exe. Creating if it does not exist... WARNING 2002-03-19 16:45:36 R3LINKS_IND_IND SyLinkCreate:400 Link /usr/sap/PRD/SYS/exe/dbg exists but it points to file /compat/linux/sapmnt/PRD/exe instead of /sapmnt/PRD/exe. The program cannot go on as long as this link exists at this location. Move the link to another location. ERROR 2002-03-19 16:45:36 R3LINKS_IND_IND Ins_SetupLinks:0 can not setup link '/usr/sap/PRD/SYS/exe/dbg' with content '/sapmnt/PRD/exe' Creating Users and Directories SAP R/3 needs two users and three groups. The user names depend on the SAP system id (SID) which consists of three letters. Some of these SIDs are reserved by SAP (for example SAP and NIX. For a complete list please see the SAP documentation). For the IDES installation I used IDS, for the 4.6C SR2 installation PRD, as that system is intended for production use. We have therefore the following groups (group ids might differ, these are just the values I used with my installation): group id group name description 100 dba Data Base Administrator 101 sapsys SAP System 102 oper Data Base Operator For a default Oracle-Installation, only group dba is used. As oper-group, one also uses group dba (see Oracle- and SAP-documentation for further information). We also need the following users: user id user name generic name group additional groups description 1000 idsadm/prdadm sidadm sapsys oper SAP Administrator 1002 oraids/oraprd orasid dba oper DB Administrator Adding the users with adduser requires the following (please note shell and home directory) entries for SAP-Administrator: Name: sidadm Password: ****** Fullname: SAP Administrator SID Uid: 1000 Gid: 101 (sapsys) Class: Groups: sapsys dba HOME: /home/sidadm Shell: bash (/compat/linux/bin/bash) and for Database-Administrator: Name: orasid Password: ****** Fullname: Oracle Administrator SID Uid: 1002 Gid: 100 (dba) Class: Groups: dba HOME: /oracle/sid Shell: bash (/compat/linux/bin/bash) This should also include group oper in case you are using both groups dba and oper. Creating Directories These directories are usually created as separate file systems. This depends entirely on your requirements. I choose to create them as simple directories, as they are all located on the same RAID 5 anyway: First we will set owners and rights of some directories (as user root): &prompt.root; chmod 775 /oracle &prompt.root; chmod 777 /sapmnt &prompt.root; chown root:dba /oracle &prompt.root; chown sidadm:sapsys /compat/linux/usr/sap &prompt.root; chmod 775 /compat/linux/usr/sap Second we will create directories as user orasid. These will all be subdirectories of /oracle/SID: &prompt.root; su - orasid &prompt.root; cd /oracle/SID &prompt.root; mkdir mirrlogA mirrlogB origlogA origlogB &prompt.root; mkdir sapdata1 sapdata2 sapdata3 sapdata4 sapdata5 sapdata6 &prompt.root; mkdir saparch sapreorg &prompt.root; exit For the Oracle 8.1.7-installation some additional directories are needed: &prompt.root; su - orasid &prompt.root; cd /oracle &prompt.root; mkdir 805_32 &prompt.root; mkdir client stage &prompt.root; mkdir client/80x_32 &prompt.root; mkdir stage/817_32 &prompt.root; cd /oracle/SID &prompt.root; mkdir 817_32 The directory client/80x_32 is used with exactly this name. Don't replace the x with some number or anything. In the third step we create directories as user sidadm: &prompt.root; su - sidadm &prompt.root; cd /usr/sap &prompt.root; mkdir SID &prompt.root; mkdir trans &prompt.root; exit Entries in /etc/services SAP R/3 requires some entries in file /etc/services, which will not be set correctly during installation under FreeBSD. Please add the following entries (you need at least those entries corresponding to the instance number - in this case, 00. It will do no harm adding all entries from 00 to 99 for dp, gw, sp and ms). If you are going to use a saprouter or need to access SAP OSS, you also need 99, as port 3299 is usually used for the saprouter process on the target system: sapdp00 3200/tcp # SAP Dispatcher. 3200 + Instance-Number sapgw00 3300/tcp # SAP Gateway. 3300 + Instance-Number sapsp00 3400/tcp # 3400 + Instance-Number sapms00 3500/tcp # 3500 + Instance-Number sapmsSID 3600/tcp # SAP Message Server. 3600 + Instance-Number sapgw00s 4800/tcp # SAP Secure Gateway 4800 + Instance-Number Necessary Locales locale SAP requires at least two locales that are not part of the default RedHat installation. SAP offers the required RPMs as download from their FTP-server (which is only accessible if you are a customer with OSS-access). See note 0171356 for a list of RPMs you need. It is also possible to just create appropriate links (for example from de_DE and en_US ), but I would not recommend this for a production system (so far it worked with the IDES system without any problems, though). The following locales are needed: de_DE.ISO-8859-1 en_US.ISO-8859-1 Create the links like this: &prompt.root; cd /compat/linux/usr/share/locale &prompt.root; ln -s de_DE de_DE.ISO-8859-1 &prompt.root; ln -s en_US en_US.ISO-8859-1 If they are not present, there will be some problems during the installation. If these are then subsequently ignored (by setting the status of the offending steps to OK in file CENTRDB.R3S), it will be impossible to log onto the SAP-system without some additional effort. Kernel Tuning kernel tuning SAP R/3 Systems need a lot of resources. I therefore added the following parameters to my kernel config-file: # Set these for memory pigs (SAP and Oracle): options MAXDSIZ="(1024*1024*1024)" options DFLDSIZ="(1024*1024*1024)" # System V options needed. options SYSVSHM #SYSV-style shared memory options SHMMAXPGS=262144 #max amount of shared mem. pages #options SHMMAXPGS=393216 #use this for the 46C inst.parameters options SHMMNI=256 #max number of shared memory ident if. options SHMSEG=100 #max shared mem.segs per process options SYSVMSG #SYSV-style message queues options MSGSEG=32767 #max num. of mes.segments in system options MSGSSZ=32 #size of msg-seg. MUST be power of 2 options MSGMNB=65535 #max char. per message queue options MSGTQL=2046 #max amount of msgs in system options SYSVSEM #SYSV-style semaphores options SEMMNU=256 #number of semaphore UNDO structures options SEMMNS=1024 #number of semaphores in system options SEMMNI=520 #number of semaphore identifiers options SEMUME=100 #number of UNDO keys The minimum values are specified in the documentation that comes from SAP. As there is no description for Linux, see the HP-UX-section (32-bit) for further information. As the system for the 4.6C SR2 installation has more main memory, the shared segments can be larger both for SAP and Oracle, therefore choose a larger number of shared memory pages. With the default installation of FreeBSD 4.5 on x386, leave MAXDSIZ and DFLDSIZ at 1 GB maximum. Otherwise, strange errors like ORA-27102: out of memory and Linux Error: 12: Cannot allocate memory might happen. Installing SAP R/3 Preparing SAP CDROMs There are many CDROMs to mount and unmount during the installation. Assuming you have enough CDROM-drives, you can just mount them all. I decided to copy the CDROM contents to corresponding directories: /oracle/SID/sapreorg/cd-name where cd-name was one of KERNEL, RDBMS, EXPORT1, EXPORT2, EXPORT3, EXPORT4, EXPORT5 and EXPORT6 for the 4.6B/IDES-installation, and KERNEL, RDBMS, DISK1, DISK2, DISK3, DISK4 and LANG for the 4.6C SR2-installation. All the filenames on the mounted CDs should be in capital letters, otherwise use the option for mounting. So use the following commands: &prompt.root; mount_cd9660 -g /dev/cd0a /mnt &prompt.root; cp -R /mnt/* /oracle/SID/sapreorg/cd-name &prompt.root; umount /mnt Running the install-script First you have to prepare an install-directory: &prompt.root; cd /oracle/SID/sapreorg &prompt.root; mkdir install &prompt.root; cd install Then the install-script is started, which will copy nearly all the relevant files into the install-directory: &prompt.root; /oracle/SID/sapreorg/KERNEL/UNIX/INSTTOOL.SH The IDES-Installation (4.6B) comes with a fully customized SAP R/3 Demo-System, so there are six instead of just three EXPORT-CDs. At this point the installation template CENTRDB.R3S is for installing a standard central instance (R/3 and Database), not the IDES central instance, so one needs to copy the corresponding CENTRDB.R3S from the EXPORT1 directory, otherwise R3SETUP will only ask for three EXPORT-CDs. The newer SAP 4.6C SR2-release comes with four EXPORT-CDs. The parameter-file that controls the installation-steps is CENTRAL.R3S. Contrary to earlier releases there are no separate installation templates for a central instance with or without database. SAP is using a separate template for DB-installation. To restart the installation later it is however sufficient to restart with the original file. During and after installation, SAP requires hostname to return the computer name only, not the fully qualified domain name. So either set the hostname accordingly, or set an alias with alias hostname='hostname -s' for both orasid and sidadm (and for root at least during installation steps performed as root). It is also possible to adjust the installed profile- and login-scripts of both users that are installed during SAP-installation. Start R3SETUP 4.6B Make sure LD_LIBRARY_PATH is set correctly: &prompt.root; export LD_LIBRARY_PATH=/oracle/IDS/lib:/sapmnt/IDS/exe:/oracle/805_32/lib Start R3SETUP as root from installation directory: &prompt.root; cd /oracle/IDS/sapreorg/install &prompt.root; ./R3SETUP -f CENTRDB.R3S The script then asks some questions (defaults in brackets, followed by actual input): Question Default Input Enter SAP System ID [C11] IDSEnter Enter SAP Instance Number [00] Enter Enter SAPMOUNT Directory [/sapmnt] Enter Enter name of SAP central host [troubadix.domain.de] Enter Enter name of SAP db host [troubadix] Enter Select character set [1] (WE8DEC) Enter Enter Oracle server version (1) Oracle 8.0.5, (2) Oracle 8.0.6, (3) Oracle 8.1.5, (4) Oracle 8.1.6 1Enter Extract Oracle Client archive [1] (Yes, extract) Enter Enter path to KERNEL CD [/sapcd] /oracle/IDS/sapreorg/KERNEL Enter path to RDBMS CD [/sapcd] /oracle/IDS/sapreorg/RDBMS Enter path to EXPORT1 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT1 Directory to copy EXPORT1 CD [/oracle/IDS/sapreorg/CD4_DIR] Enter Enter path to EXPORT2 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT2 Directory to copy EXPORT2 CD [/oracle/IDS/sapreorg/CD5_DIR] Enter Enter path to EXPORT3 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT3 Directory to copy EXPORT3 CD [/oracle/IDS/sapreorg/CD6_DIR] Enter Enter path to EXPORT4 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT4 Directory to copy EXPORT4 CD [/oracle/IDS/sapreorg/CD7_DIR] Enter Enter path to EXPORT5 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT5 Directory to copy EXPORT5 CD [/oracle/IDS/sapreorg/CD8_DIR] Enter Enter path to EXPORT6 CD [/sapcd] /oracle/IDS/sapreorg/EXPORT6 Directory to copy EXPORT6 CD [/oracle/IDS/sapreorg/CD9_DIR] Enter Enter amount of RAM for SAP + DB 850Enter (in Megabytes) Service Entry Message Server [3600] Enter Enter Group-ID of sapsys [101] Enter Enter Group-ID of oper [102] Enter Enter Group-ID of dba [100] Enter Enter User-ID of sidadm [1000] Enter Enter User-ID of orasid [1002] Enter Number of parallel procs [2] Enter If you had not copied the CDs to the different locations, then the SAP-Installer cannot find the CD needed (identified by the LABEL.ASC-File on CD) and would then ask you to insert and mount the CD and confirm or enter the mount path. The CENTRDB.R3S might not be error-free. In my case, it requested EXPORT4 again (but indicated the correct key (6_LOCATION, then 7_LOCATION etc.), so one can just continue with entering the correct values. Do not get irritated. Apart from some problems mentioned below, everything should go straight through up to the point where the Oracle database software needs to be installed. Start R3SETUP 4.6C SR2 Make sure LD_LIBRARY_PATH is set correctly. This is a different value from the 4.6B installation with Oracle 8.0.5: &prompt.root; export LD_LIBRARY_PATH=/sapmnt/PRD/exe:/oracle/PRD/817_32/lib Start R3SETUP as user root from installation directory: &prompt.root; cd /oracle/PRD/sapreorg/install &prompt.root; ./R3SETUP -f CENTRAL.R3S The script then asks some questions (defaults in brackets, followed by actual input): Question Default Input Enter SAP System ID [C11] PRDEnter Enter SAP Instance Number [00] Enter Enter SAPMOUNT Directory [/sapmnt] Enter Enter name of SAP central host [majestix] Enter Enter Database System ID [PRD] PRDEnter Enter name of SAP db host [majestix] Enter Select character set [1] (WE8DEC) Enter Enter Oracle server version (2) Oracle 8.1.7 2Enter Extract Oracle Client archive [1] (Yes, extract) Enter Enter path to KERNEL CD [/sapcd] /oracle/PRD/sapreorg/KERNEL Enter amount of RAM for SAP + DB 2044 1800Enter (in Megabytes) Service Entry Message Server [3600] Enter Enter Group-ID of sapsys [100] Enter Enter Group-ID of oper [101] Enter Enter Group-ID of dba [102] Enter Enter User-ID of oraprd [1002] Enter Enter User-ID of prdadm [1000] Enter LDAP support 3Enter (no support) Installation step completed [1] (continue) Enter Choose installation service [1] (DB inst,file) Enter So far, creation of users gives an error during installation in phases OSUSERDBSID_IND_ORA (for creating user orasid) and OSUSERSIDADM_IND_ORA (creating user sidadm). Apart from some problems mentioned below, everything should go straight through up to the point where the Oracle database software needs to be installed. Installing Oracle 8.0.5 Please see the corresponding SAP-Notes and Oracle Readmes regarding Linux and Oracle DB for possible problems. Most if not all problems stem from incompatible libraries. For more information on installing Oracle, refer to the Installing Oracle chapter. Installing the Oracle 8.0.5 with orainst If Oracle 8.0.5 is to be used, some additional libraries are needed for successfully relinking, as Oracle 8.0.5 was linked with an old glibc (RedHat 6.0), but RedHat 6.1 already uses a new glibc. So you have to install the following additional packages to ensure that linking will work: compat-libs-5.2-2.i386.rpm compat-glibc-5.2-2.0.7.2.i386.rpm compat-egcs-5.2-1.0.3a.1.i386.rpm compat-egcs-c++-5.2-1.0.3a.1.i386.rpm compat-binutils-5.2-2.9.1.0.23.1.i386.rpm See the corresponding SAP-Notes or Oracle Readmes for further information. If this is no option (at the time of installation I did not have enough time to check this), one could use the original binaries, or use the relinked binaries from an original RedHat System. For compiling the intelligent agent, the RedHat Tcl package must be installed. If you cannot get tcl-8.0.3-20.i386.rpm, a newer one like tcl-8.0.5-30.i386.rpm for RedHat 6.1 should also do. Apart from relinking, the installation is straightforward: &prompt.root; su - oraids &prompt.root; export TERM=xterm &prompt.root; export ORACLE_TERM=xterm &prompt.root; export ORACLE_HOME=/oracle/IDS &prompt.root; cd /ORACLE_HOME/orainst_sap &prompt.root; ./orainst Confirm all Screens with Enter until the software is installed, except that one has to deselect the Oracle On-Line Text Viewer, as this is not currently available for Linux. Oracle then wants to relink with i386-glibc20-linux-gcc instead of the available gcc, egcs or i386-redhat-linux-gcc . Due to time constrains I decided to use the binaries from an Oracle 8.0.5 PreProduction release, after the first attempt at getting the version from the RDBMS-CD working, failed, and finding and accessing the correct RPMs was a nightmare at that time. Installing the Oracle 8.0.5 Pre-Production release for Linux (Kernel 2.0.33) This installation is quite easy. Mount the CD, start the installer. It will then ask for the location of the Oracle home directory, and copy all binaries there. I did not delete the remains of my previous RDBMS-installation tries, though. Afterwards, Oracle Database could be started with no problems. Installing the Oracle 8.1.7 linux tarball Take the tarball oracle81732.tgz you produced from the installation directory on a linux system and untar it to /oracle/SID/817_32/. Continue with SAP R/3 Installation First check the environment settings of users idsamd (sidadm) and oraids (orasid). They should now both have the files .profile, .login and .cshrc which are all using hostname. In case the system's hostname is the fully qualified name, you need to change hostname to hostname -s within all three files. Database Load Afterwards, R3SETUP can either be restarted or continued (depending on whether exit was chosen or not). R3SETUP then creates the tablespaces and loads the data (for 46B IDES, from EXPORT1 to EXPORT6, for 46C from DISK1 to DISK4) with R3load into the database. When the database load is finished (might take a few hours), some passwords are requested. For test installations, one can use the well known default passwords (use different ones if security is an issue!): Question Input Enter Password for sapr3 sapEnter Confirum Password for sapr3 sapEnter Enter Password for sys change_on_installEnter Confirm Password for sys change_on_installEnter Enter Password for system managerEnter Confirm Password for system managerEnter At this point I had a few problems with dipgntab during the 4.6B installation. Listener Start the Oracle-Listener as user orasid as follows: &prompt.user; umask 0; lsnrctl start Otherwise you might get ORA-12546 as the sockets will not have the correct permissions. See SAP note 072984. Updating MNLS Tables If you plan to import non-Latin-1 languages into the SAP-System, you have to update the Multi National Language Support tables. This is described in the SAP OSS-Notes 15023 and 45619. Otherwise, you can skip this question during SAP installation. If you don't need MNLS, it is still necessary to check table TCPDB and initializing it if this hasn't been done. See SAP note 0015023 and 0045619 for further information. Post-installation Steps Request SAP R/3 License Key You have to request your SAP R/3 License Key. This is needed, as the temporary license that was installed during installation is only valid for four weeks. First get the hardware key. Log on as user idsadm and call saplicense: &prompt.root; /sapmnt/IDS/exe/saplicense -get Calling saplicense without options gives a list of options. Upon receiving the license key, it can be installed using: &prompt.root; /sapmnt/IDS/exe/saplicense -install You are then required to enter the following values: SAP SYSTEM ID = SID, 3 chars CUSTOMER KEY = hardware key, 11 chars INSTALLATION NO = installation, 10 digits EXPIRATION DATE = yyyymmdd, usually "99991231" LICENSE KEY = license key, 24 chars Creating Users Create a user within client 000 (for some tasks required to be done within client 000, but with a user different from users sap* and ddic). As a user name, I usually choose wartung (or service in English). Profiles required are sap_new and sap_all. For additional safety the passwords of default users within all clients should be changed (this includes users sap* and ddic). Configure Transport System, Profile, Operation Modes, Etc. Within client 000, user different from ddic and sap*, do at least the following: Task Transaction Configure Transport System, eg as Stand-Alone Transport Domain Entity STMS Create / Edit Profile for System RZ10 Maintain Operation Modes and Instances RZ04 These and all the other post-installation steps are thoroughly described in SAP installation guides. Edit init<replaceable>sid</replaceable>.sap (initIDS.sap) The file /oracle/IDS/dbs/initIDS.sap contains the SAP backup profile. Here the size of the tape to be used, type of compression and so on need to be defined. To get this running with sapdba / brbackup, I changed the following values: compress = hardware archive_function = copy_delete_save cpio_flags = "-ov --format=newc --block-size=128 --quiet" cpio_in_flags = "-iuv --block-size=128 --quiet" tape_size = 38000M tape_address = /dev/nsa0 tape_address_rew = /dev/sa0 Explanations: compress The tape I use is a HP DLT1 which does hardware compression. archive_function This defines the default behavior for saving Oracle archive logs: New logfiles are saved to tape, already saved logfiles are saved again and are then deleted. This prevents lots of trouble if you need to recover the database, and one of the archive-tapes has gone bad. cpio_flags Default is to use -B which sets block size to 5120 Bytes. For DLT-Tapes, HP recommends at least 32 K block size, so I used --block-size=128 for 64 K. --format=newc is needed I have inode numbers greater than 65535. The last option --quiet is needed as otherwise brbackup complains as soon as cpio outputs the numbers of blocks saved. cpio_in_flags Flags needed for loading data back from tape. Format is recognized automatically. tape_size This usually gives the raw storage capability of the tape. For security reason (we use hardware compression), the value is slightly lower than the actual value. tape_address The non-rewindable device to be used with cpio. tape_address_rew The rewindable device to be used with cpio. Configuration Issues after Installation The following SAP-parameters should be tuned after installation (examples for IDES 46B, 1 GB memory): Name Value ztta/roll_extension 250000000 abap/heap_area_dia 300000000 abap/heap_area_nondia 400000000 em/initial_size_MB 256 em/blocksize_kB 1024 ipc/shm_psize_40 70000000 SAP-Note 0013026: Name Value ztta/dynpro_area 2500000 SAP-Note 0157246: Name Value rdisp/ROLL_MAXFS 16000 rdisp/PG_MAXFS 30000 With the above parameters, on a system with 1 gigabyte of memory, one may find memory consumption similar to: Mem: 547M Active, 305M Inact, 109M Wired, 40M Cache, 112M Buf, 3492K Free Problems During Installation Restart R3SETUP after fixing a problem R3SETUP stops if it encounters an error. If you have looked at the corresponding logfiles and fixed the error, you have to start R3SETUP again, usually selecting REPEAT as option for the last step R3SETUP complained about. To restart R3SETUP, just start it with the corresponding R3S-file: &prompt.root; ./R3SETUP -f CENTRDB.R3S for 4.6B, or with &prompt.root; ./R3SETUP -f CENTRAL.R3S for 4.6C, no matter whether the error occurred with CENTRAL.R3S or DATABASE.R3S. At some stages, R3SETUP assumes that both database- and SAP-processes are up and running (as those were steps it already completed). Should errors occur and for example the database could not be started, you have to start both database and SAP by hand after you fixed the errors and before starting R3SETUP again. Don't forget to also start the oracle listener again (as orasid with umask 0; lsnrctl start) if it was also stopped (for example due to a necessary reboot of the system). OSUSERSIDADM_IND_ORA During R3SETUP If R3SETUP complains at this stage, edit the template file R3SETUP used at that time (CENTRDB.R3S (4.6B) or either CENTRAL.R3S or DATABASE.R3S (4.6C)). Locate [OSUSERSIDADM_IND_ORA] or search for the only STATUS=ERROR-entry and edit the following values: HOME=/home/sidadm (was empty) STATUS=OK (had status ERROR) Then you can restart R3SETUP again. OSUSERDBSID_IND_ORA During R3SETUP Possibly R3SETUP also complains at this stage. The error here is similar to the one in phase OSUSERSIDADM_IND_ORA. Just edit the template file R3SETUP used at that time (CENTRDB.R3S (4.6B) or either CENTRAL.R3S or DATABASE.R3S (4.6C)). Locate [OSUSERDBSID_IND_ORA] or search for the only STATUS=ERROR-entry and edit the following value in that section: STATUS=OK Then restart R3SETUP. <errorname>oraview.vrf FILE NOT FOUND</errorname> During Oracle Installation You have not deselected Oracle On-Line Text Viewer before starting the installation. This is marked for installation even though this option is currently not available for Linux. Deselect this product inside the Oracle installation menu and restart installation. <errorname>TEXTENV_INVALID</errorname> During R3SETUP, RFC or SAPGUI Start If this error is encountered, the correct locale is missing. SAP note 0171356 lists the necessary RPMs that need be installed (eg saplocales-1.0-3, saposcheck-1.0-1 for RedHat 6.1). In case you ignored all the related errors and set the corresponding status from ERROR to OK (in CENTRDB.R3S) every time R3SETUP complained and just restarted R3SETUP, the SAP-System will not be properly configured and you will then not be able to connect to the system with a sapgui, even though the system can be started. Trying to connect with the old Linux sapgui gave the following messages: Sat May 5 14:23:14 2001 *** ERROR => no valid userarea given [trgmsgo. 0401] Sat May 5 14:23:22 2001 *** ERROR => ERROR NR 24 occured [trgmsgi. 0410] *** ERROR => Error when generating text environment. [trgmsgi. 0435] *** ERROR => function failed [trgmsgi. 0447] *** ERROR => no socket operation allowed [trxio.c 3363] Speicherzugriffsfehler This behavior is due to SAP R/3 being unable to correctly assign a locale and also not being properly configured itself (missing entries in some database tables). To be able to connect to SAP, add the following entries to file DEFAULT.PFL (see note 0043288): abap/set_etct_env_at_new_mode = 0 install/collate/active = 0 rscp/TCP0B = TCP0B Restart the SAP system. Now you can connect to the system, even though country-specific language settings might not work as expected. After correcting country-settings (and providing the correct locales), these entries can be removed from DEFAULT.PFL and the SAP system can be restarted. <errorcode>ORA-00001</errorcode> This error only happened with Oracle 8.1.7 on FreeBSD 4.5. The reason was that the Oracle database could not initialize itself properly and crashed, leaving semaphores and shared memory on the system. The next try to start the database then returned ORA-00001. Find them with ipcs -a and remove them with ipcrm. <errorcode>ORA-00445</errorcode> (background process PMON did not start) This error happened with Oracle 8.1.7. This error is reported if the Database is started with the usual startsap-script (for example startsap_majestix_00) as user prdadm. A possible workaround is to start the database as user oraprd instead with svrmgrl: &prompt.user; svrmgrl SVRMGR> connect internal; SVRMGR> startup; SVRMGR> exit <errorcode>ORA-12546</errorcode> (start Listener with Correct Permissions) Start the Oracle Listener as user oraids with the following commands: &prompt.root; umask 0; lsnrctl start Otherwise you might get ORA-12546 as the sockets will not have the correct permissions. See SAP note 0072984. <errorcode>ORA-27102</errorcode> (out of memory) This error happened whilst trying to use values for MAXDSIZ and DFLDSIZ greater than 1 GB (1024x1024x1024). Additionally, I got Linux Error 12: Cannot allocate memory. [DIPGNTAB_IND_IND] During R3SETUP In general, see SAP note 0130581 (R3SETUP step DIPGNTAB terminates). During the IDES-specific installation, for some reasons the installation process was not using the proper SAP system name IDS, but the empty string "" instead. This lead to some minor problems with accessing directories, as the paths are generated dynamically using SID (in this case IDS). So instead of accessing: /usr/sap/IDS/SYS/... /usr/sap/IDS/DVMGS00 the following paths were used: /usr/sap//SYS/... /usr/sap/D00 To continue with the installation, I created a link and an additional directory: &prompt.root; pwd /compat/linux/usr/sap &prompt.root; ls -l total 4 drwxr-xr-x 3 idsadm sapsys 512 May 5 11:20 D00 drwxr-x--x 5 idsadm sapsys 512 May 5 11:35 IDS lrwxr-xr-x 1 root sapsys 7 May 5 11:35 SYS -> IDS/SYS drwxrwxr-x 2 idsadm sapsys 512 May 5 13:00 tmp drwxrwxr-x 11 idsadm sapsys 512 May 4 14:20 trans I also found SAP notes (0029227 and 0008401) describing this behavior. I did not encounter any of these problems with the SAP 4.6C-installation. [RFCRSWBOINI_IND_IND] During R3SETUP During installation of SAP 4.6C, this error was just the result of another error happening earlier during installation. In this case, you have to look through the corresponding logfiles and correct the real problem. If after looking through the logfiles this error is indeed the correct one (check the SAP-notes), you can set STATUS of the offending step from ERROR to OK (file CENTRDB.R3S) and restart R3SETUP. After installation, you have to execute the report RSWBOINS from transaction SE38. See SAP note 0162266 for additional information about phase RFCRSWBOINI and RFCRADDBDIF. [RFCRADDBDIF_IND_IND] During R3SETUP Here the same restrictions apply: Make sure by looking through the logfiles, that this error is not caused by some previous problems. If you can confirm that SAP-Note 0162266 applies, just set STATUS of the offending step from ERROR to OK (file CENTRDB.R3S) and restart R3SETUP. After installation, you have to execute the report RADDBDIF from transaction SE38. sigaction sig31: File size limit exceeded This error occured during start of SAP-processes disp+work. If starting SAP with the startsap-script, subprocesses are then started which detach and do the dirty work of starting all other SAP processes. As a result, the script itself won't notice if something goes wrong. To check whether the SAP processes did start properly, have a look at the process status with ps ax | grep SID, which will give you a list of all Oracle- and SAP-processes. If it looks like some processes are missing or if you can't connect to the SAP-System, look at the corresponding logfiles which can be found at /usr/sap/SID/DVEBMGSnr/work/. The files to look at are dev_ms and dev_disp. Signal 31 happens here if the amount of shared memory used by Oracle and SAP exceed the one defined within the kernel configuration file and could be resolved by using a larger value: # larger value for 46C production systems: options SHMMAXPGS=393216 # smaller value sufficient for 46B: #options SHMMAXPGS=262144 Start of saposcol failed There are some problems with Program saposcol (version 4.6D). The SAP-System is using saposcol to collect data about the system performance. This program is not needed to use the SAP-System, so this problem can be considered a minor one. The older versions (4.6B) does work, but doesn't collect all the data (many calls will just return 0, for example for CPU usage). Advanced Topics If you are curious as to how the Linux binary compatibility works, this is the section you want to read. Most of what follows is based heavily on an email written to &a.chat; by Terry Lambert tlambert@primenet.com (Message ID: <199906020108.SAA07001@usr09.primenet.com>). How Does It Work? execution class loader FreeBSD has an abstraction called an execution class loader. This is a wedge into the &man.execve.2; system call. What happens is that FreeBSD has a list of loaders, instead of a single loader with a fallback to the #! loader for running any shell interpreters or shell scripts. Historically, the only loader on the Unix platform examined the magic number (generally the first 4 or 8 bytes of the file) to see if it was a binary known to the system, and if so, invoked the binary loader. If it was not the binary type for the system, the &man.execve.2; call returned a failure, and the shell attempted to start executing it as shell commands. The assumption was a default of whatever the current shell is. Later, a hack was made for &man.sh.1; to examine the first two characters, and if they were :\n, then it invoked the &man.csh.1; shell instead (we believe SCO first made this hack). What FreeBSD does now is go through a list of loaders, with a generic #! loader that knows about interpreters as the characters which follow to the next whitespace next to last, followed by a fallback to /bin/sh. ELF For the Linux ABI support, FreeBSD sees the magic number as an ELF binary (it makes no distinction between FreeBSD, Solaris, Linux, or any other OS which has an ELF image type, at this point). Solaris The ELF loader looks for a specialized brand, which is a comment section in the ELF image, and which is not present on SVR4/Solaris ELF binaries. For Linux binaries to function, they must be branded as type Linux; from &man.brandelf.1;: &prompt.root; brandelf -t Linux file When this is done, the ELF loader will see the Linux brand on the file. ELF branding When the ELF loader sees the Linux brand, the loader replaces a pointer in the proc structure. All system calls are indexed through this pointer (in a traditional Unix system, this would be the sysent[] structure array, containing the system calls). In addition, the process is flagged for special handling of the trap vector for the signal trampoline code, and several other (minor) fix-ups that are handled by the Linux kernel module. The Linux system call vector contains, among other things, a list of sysent[] entries whose addresses reside in the kernel module. When a system call is called by the Linux binary, the trap code dereferences the system call function pointer off the proc structure, and gets the Linux, not the FreeBSD, system call entry points. In addition, the Linux mode dynamically reroots lookups; this is, in effect, what the union option to FS mounts (not the unionfs!) does. First, an attempt is made to lookup the file in the /compat/linux/original-path directory, then only if that fails, the lookup is done in the /original-path directory. This makes sure that binaries that require other binaries can run (e.g., the Linux toolchain can all run under Linux ABI support). It also means that the Linux binaries can load and exec FreeBSD binaries, if there are no corresponding Linux binaries present, and that you could place a &man.uname.1; command in the /compat/linux directory tree to ensure that the Linux binaries could not tell they were not running on Linux. In effect, there is a Linux kernel in the FreeBSD kernel; the various underlying functions that implement all of the services provided by the kernel are identical to both the FreeBSD system call table entries, and the Linux system call table entries: file system operations, virtual memory operations, signal delivery, System V IPC, etc… The only difference is that FreeBSD binaries get the FreeBSD glue functions, and Linux binaries get the Linux glue functions (most older OS's only had their own glue functions: addresses of functions in a static global sysent[] structure array, instead of addresses of functions dereferenced off a dynamically initialized pointer in the proc structure of the process making the call). Which one is the native FreeBSD ABI? It does not matter. Basically the only difference is that (currently; this could easily be changed in a future release, and probably will be after this) the FreeBSD glue functions are statically linked into the kernel, and the Linux glue functions can be statically linked, or they can be accessed via a kernel module. Yeah, but is this really emulation? No. It is an ABI implementation, not an emulation. There is no emulator (or simulator, to cut off the next question) involved. So why is it sometimes called Linux emulation? To make it hard to sell FreeBSD! Really, it is because the historical implementation was done at a time when there was really no word other than that to describe what was going on; saying that FreeBSD ran Linux binaries was not true, if you did not compile the code in or load a module, and there needed to be a word to describe what was being loaded—hence the Linux emulator. diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml index c1cd7c70fd..90d65363e2 100644 --- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,4796 +1,4699 @@ Obtaining FreeBSD CDROM and DVD Publishers Retail Boxed Products FreeBSD is available as a boxed product (FreeBSD CDs, additional software, and printed documentation) from several retailers:
CompUSA WWW: http://www.compusa.com/
Frys Electronics WWW: http://www.frys.com/
CD and DVD Sets FreeBSD CD and DVD sets are available from many online retailers:
Daemon News Mall 560 South State Street, Suite A2 Orem, UT 84058 USA Phone: +1 800 407-5170 Fax: +1 1 801 765-0877 Email: sales@bsdmall.com WWW: http://www.bsdmall.com/
FreeBSD Mall, Inc. 3623 Sanford Street Concord, CA 94520-1405 USA Phone: +1 925 674-0783 Fax: +1 925 674-0821 Email: info@freebsdmall.com WWW: http://www.freebsdmall.com/
FreeBSD Services Ltd 11 Lapwing Close Bicester OX26 6XR United Kingdom WWW: http://www.freebsd-services.com/
Hinner EDV St. Augustinus-Str. 10 D-81825 München Germany Phone: (089) 428 419 WWW: http://www.hinner.de/linux/freebsd.html
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 USA Phone: 1 (800) 456-8000 WWW: http://www.ingrammicro.com/
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA United Kingdom Phone: +44 1491 837010 Fax: +44 1491 837016 WWW: http://www.linuxemporium.co.uk/bsd.html
UNIXDVD.COM LTD 57 Primrose Avenue Sheffield S5 6FS United Kingdom WWW: http://www.unixdvd.com/
Distributors If you are a reseller and want to carry FreeBSD CDROM products, please contact a distributor:
Cylogistics 2672 Bayshore Parkway, Suite 610 Mountain View, CA 94043 USA Phone: +1 650 694-4949 Fax: +1 650 694-4953 Email: sales@cylogistics.com WWW: http://www.cylogistics.com/
FreeBSD Services Ltd 11 Lapwing Close Bicester OX26 6XR United Kingdom WWW: http://www.freebsd-services.com/
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 USA Phone: +1 952 947-0822 Fax: +1 952 947-0876 Email: sales@kudzuenterprises.com
Navarre Corp 7400 49th Ave South New Hope, MN 55428 USA Phone: +1 763 535-8333 Fax: +1 763 535-0341 WWW: http://www.navarre.com/
FTP Sites The official sources for FreeBSD are available via anonymous FTP from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/.
The FreeBSD mirror sites database is more accurate than the mirror listing in the Handbook, as it gets its information from the DNS rather than relying on static lists of hosts. Additionally, FreeBSD is available via anonymous FTP from the following mirror sites. If you choose to obtain FreeBSD via anonymous FTP, please try to use a site near you. Argentina, Australia, Austria, Brazil, Bulgaria, Canada, China, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hong Kong, Hungary, Iceland, Ireland, Italy, Japan, Korea, Lithuania, Netherlands, New Zealand, Norway, Poland, Portugal, Romania, Russia, Saudi Arabia, Singapore, Slovak Republic, Slovenia, South Africa, Spain, Sweden, Switzerland, Taiwan, Thailand, UK, Ukraine, USA. Argentina In case of problems, please contact the hostmaster hostmaster@ar.FreeBSD.org for this domain. ftp://ftp.ar.FreeBSD.org/pub/FreeBSD/ Australia In case of problems, please contact the hostmaster hostmaster@au.FreeBSD.org for this domain. ftp://ftp.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.au.FreeBSD.org/pub/FreeBSD/ Austria In case of problems, please contact the hostmaster hostmaster@at.FreeBSD.org for this domain. ftp://ftp.at.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.at.FreeBSD.org/pub/FreeBSD/ Brazil In case of problems, please contact the hostmaster hostmaster@br.FreeBSD.org for this domain. ftp://ftp.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.br.FreeBSD.org/pub/FreeBSD/ Bulgaria In case of problems, please contact the hostmaster hostmaster@bg.FreeBSD.org for this domain. ftp://ftp.bg.FreeBSD.org/pub/FreeBSD/ Canada In case of problems, please contact the hostmaster hostmaster@ca.FreeBSD.org for this domain. ftp://ftp.ca.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.ca.FreeBSD.org/pub/FreeBSD/ China In case of problems, please contact the hostmaster phj@cn.FreeBSD.org for this domain. ftp://ftp.cn.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.cn.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.cn.FreeBSD.org/pub/FreeBSD/ Czech Republic In case of problems, please contact the hostmaster hostmaster@cz.FreeBSD.org for this domain. ftp://ftp.cz.FreeBSD.org/pub/FreeBSD/ Contact: calda@dzungle.ms.mff.cuni.cz Denmark In case of problems, please contact the hostmaster hostmaster@dk.FreeBSD.org for this domain. ftp://ftp.dk.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.dk.FreeBSD.org/pub/FreeBSD/ Estonia In case of problems, please contact the hostmaster hostmaster@ee.FreeBSD.org for this domain. ftp://ftp.ee.FreeBSD.org/pub/FreeBSD/ Finland In case of problems, please contact the hostmaster hostmaster@fi.FreeBSD.org for this domain. ftp://ftp.fi.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.fi.FreeBSD.org/pub/FreeBSD/ France In case of problems, please contact the hostmaster hostmaster@fr.FreeBSD.org for this domain. ftp://ftp.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp8.fr.FreeBSD.org/pub/FreeBSD/ Germany In case of problems, please contact the mirror admins de-bsd-hubs@de.FreeBSD.org for this domain. - ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.de.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.de.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp4.de.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp5.de.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp6.de.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp7.de.FreeBSD.org/pub/FreeBSD/ + Greece In case of problems, please contact the hostmaster hostmaster@gr.FreeBSD.org for this domain. - ftp://ftp.gr.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.gr.FreeBSD.org/pub/FreeBSD/ + Hong Kong - ftp://ftp.hk.FreeBSD.org/pub/FreeBSD/ + Hungary In case of problems, please contact the hostmaster mohacsi@ik.bme.hu for this domain. - ftp://ftp.hu.FreeBSD.org/pub/FreeBSD/ + Iceland In case of problems, please contact the hostmaster hostmaster@is.FreeBSD.org for this domain. - ftp://ftp.is.FreeBSD.org/pub/FreeBSD/ + Ireland In case of problems, please contact the hostmaster hostmaster@ie.FreeBSD.org for this domain. - ftp://ftp.ie.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.ie.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.ie.FreeBSD.org/pub/FreeBSD/ + Italy In case of problems, please contact the hostmaster hostmaster@it.FreeBSD.org for this domain. - ftp://ftp.it.FreeBSD.org/pub/FreeBSD/ + Japan In case of problems, please contact the hostmaster hostmaster@jp.FreeBSD.org for this domain. - ftp://ftp.jp.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.jp.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp4.jp.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp5.jp.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp6.jp.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp7.jp.FreeBSD.org/pub/FreeBSD/ + Korea In case of problems, please contact the hostmaster hostmaster@kr.FreeBSD.org for this domain. - ftp://ftp.kr.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.kr.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.kr.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp4.kr.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp5.kr.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp6.kr.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp7.kr.FreeBSD.org/pub/FreeBSD/ + Lithuania In case of problems, please contact the hostmaster hostmaster@lt.FreeBSD.org for this domain. - ftp://ftp.lt.FreeBSD.org/pub/FreeBSD/ + Netherlands In case of problems, please contact the hostmaster hostmaster@nl.FreeBSD.org for this domain. - ftp://ftp.nl.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.nl.FreeBSD.org/pub/FreeBSD/ + New Zealand In case of problems, please contact the hostmaster hostmaster@nz.FreeBSD.org for this domain. - ftp://ftp.nz.FreeBSD.org/pub/FreeBSD/ + Norway In case of problems, please contact the hostmaster hostmaster@no.FreeBSD.org for this domain. - ftp://ftp.no.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.no.FreeBSD.org/pub/FreeBSD/ + Poland In case of problems, please contact the hostmaster hostmaster@pl.FreeBSD.org for this domain. - ftp://ftp.pl.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.pl.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.pl.FreeBSD.org/pub/FreeBSD/ + Portugal In case of problems, please contact the hostmaster hostmaster@pt.FreeBSD.org for this domain. - ftp://ftp2.pt.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.pt.FreeBSD.org/pub/FreeBSD/ + Romania In case of problems, please contact the hostmaster hostmaster@ro.FreeBSD.org for this domain. - ftp://ftp.ro.FreeBSD.org/pub/FreeBSD/ + Russia In case of problems, please contact the hostmaster hostmaster@ru.FreeBSD.org for this domain. - ftp://ftp.ru.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.ru.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.ru.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp4.ru.FreeBSD.org/pub/FreeBSD/ + Saudi Arabia In case of problems, please contact ftpadmin@isu.net.sa - ftp://ftp.isu.net.sa/pub/mirrors/ftp.freebsd.org/ + Singapore In case of problems, please contact the hostmaster hostmaster@sg.FreeBSD.org for this domain. - ftp://ftp.sg.FreeBSD.org/pub/FreeBSD/ + South Africa In case of problems, please contact the hostmaster hostmaster@za.FreeBSD.org for this domain. - ftp://ftp.za.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.za.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.za.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp4.za.FreeBSD.org/pub/FreeBSD/ + Slovak Republic In case of problems, please contact the hostmaster hostmaster@sk.FreeBSD.org for this domain. - ftp://ftp.sk.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.sk.FreeBSD.org/pub/FreeBSD/ + Slovenia In case of problems, please contact the hostmaster hostmaster@si.FreeBSD.org for this domain. - ftp://ftp2.si.FreeBSD.org/pub/FreeBSD/ + Spain In case of problems, please contact the hostmaster hostmaster@es.FreeBSD.org for this domain. - ftp://ftp.es.FreeBSD.org/pub/FreeBSD/ + - + - ftp://ftp2.es.FreeBSD.org/pub/FreeBSD/ + - + - ftp://ftp3.es.FreeBSD.org/pub/FreeBSD/ + Sweden In case of problems, please contact the hostmaster hostmaster@se.FreeBSD.org for this domain. - ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.se.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.se.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp5.se.FreeBSD.org/pub/FreeBSD/ + Switzerland In case of problems, please contact the hostmaster hostmaster@ch.FreeBSD.org for this domain. - ftp://ftp.ch.FreeBSD.org/pub/FreeBSD/ + Taiwan In case of problems, please contact the hostmaster hostmaster@tw.FreeBSD.org for this domain. - ftp://ftp.tw.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.tw.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.tw.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp4.tw.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp5.tw.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp6.tw.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp7.tw.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp8.tw.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp9.tw.FreeBSD.org/pub/FreeBSD/ + Thailand - ftp://ftp.nectec.or.th/pub/FreeBSD/ Contact: ftpadmin@ftp.nectec.or.th. + + Contact: ftpadmin@ftp.nectec.or.th. Ukraine - ftp://ftp.ua.FreeBSD.org/pub/FreeBSD/ Contact: freebsd-mnt@lucky.net. + + Contact: freebsd-mnt@lucky.net. - ftp://ftp2.ua.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.ua.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp5.ua.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp6.ua.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp7.ua.FreeBSD.org/pub/FreeBSD/ + UK In case of problems, please contact the hostmaster hostmaster@uk.FreeBSD.org for this domain. - ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.uk.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.uk.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp4.uk.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp5.uk.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp6.uk.FreeBSD.org/pub/FreeBSD/ + USA In case of problems, please contact the hostmaster hostmaster@FreeBSD.org for this domain. - ftp://ftp1.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp2.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp3.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp4.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp5.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp6.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp7.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp8.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp9.FreeBSD.org/pub/os/FreeBSD/ + - ftp://ftp10.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp11.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp12.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp13.FreeBSD.org/pub/FreeBSD/ + - ftp://ftp14.FreeBSD.org/pub/FreeBSD/ + Anonymous CVS <anchor id="anoncvs-intro">Introduction Anonymous CVS (or, as it is otherwise known, anoncvs) is a feature provided by the CVS utilities bundled with FreeBSD for synchronizing with a remote CVS repository. Among other things, it allows users of FreeBSD to perform, with no special privileges, read-only CVS operations against one of the FreeBSD project's official anoncvs servers. To use it, one simply sets the CVSROOT environment variable to point at the appropriate anoncvs server, provides the well-known password anoncvs with the cvs login command, and then uses the &man.cvs.1; command to access it like any local repository. The cvs login command, stores the passwords that are used for authenticating to the CVS server in a file called .cvspass in your HOME directory. If this file does not exist, you might get an error when trying to use cvs login for the first time. Just make an empty .cvspass file, and retry to login. While it can also be said that the CVSup and anoncvs services both perform essentially the same function, there are various trade-offs which can influence the user's choice of synchronization methods. In a nutshell, CVSup is much more efficient in its usage of network resources and is by far the most technically sophisticated of the two, but at a price. To use CVSup, a special client must first be installed and configured before any bits can be grabbed, and then only in the fairly large chunks which CVSup calls collections. Anoncvs, by contrast, can be used to examine anything from an individual file to a specific program (like ls or grep) by referencing the CVS module name. Of course, anoncvs is also only good for read-only operations on the CVS repository, so if it is your intention to support local development in one repository shared with the FreeBSD project bits then CVSup is really your only option. <anchor id="anoncvs-usage">Using Anonymous CVS Configuring &man.cvs.1; to use an Anonymous CVS repository is a simple matter of setting the CVSROOT environment variable to point to one of the FreeBSD project's anoncvs servers. At the time of this writing, the following servers are available: USA: :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs (Use cvs login and enter the password anoncvs when prompted.) Germany: :pserver:anoncvs@anoncvs.de.FreeBSD.org:/home/ncvs (Use cvs login and enter the password anoncvs when prompted.) Germany: :pserver:anoncvs@anoncvs2.de.FreeBSD.org:/home/ncvs (rsh, pserver, ssh, ssh/2022) Japan: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs (Use cvs login and enter the password anoncvs when prompted.) Since CVS allows one to check out virtually any version of the FreeBSD sources that ever existed (or, in some cases, will exist), you need to be familiar with the revision () flag to &man.cvs.1; and what some of the permissible values for it in the FreeBSD Project repository are. There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today. contains revision tags that users might be interested in. Again, none of these are valid for the ports collection since the ports collection does not have multiple revisions. When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the flag. See the &man.cvs.1; manual page for more details. Examples While it really is recommended that you read the manual page for &man.cvs.1; thoroughly before doing anything, here are some quick examples which essentially show how to use Anonymous CVS: Checking Out Something from -CURRENT (&man.ls.1;) and Deleting It Again: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co ls &prompt.user; cvs release -d ls &prompt.user; cvs logout Checking Out the Version of &man.ls.1; in the 3.X-STABLE Branch: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co -rRELENG_3 ls &prompt.user; cvs release -d ls &prompt.user; cvs logout Creating a List of Changes (as unified diffs) to &man.ls.1; &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs rdiff -u -rRELENG_3_0_0_RELEASE -rRELENG_3_4_0_RELEASE ls &prompt.user; cvs logout Finding Out What Other Module Names Can Be Used: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co modules &prompt.user; more modules/modules &prompt.user; cvs release -d modules &prompt.user; cvs logout Other Resources The following additional resources may be helpful in learning CVS: - CVS Tutorial from Cal Poly. CVS Home, the CVS development and support community. CVSweb is the FreeBSD Project web interface for CVS. Using CTM CTM is a method for keeping a remote directory tree in sync with a central one. It has been developed for usage with FreeBSD's source trees, though other people may find it useful for other purposes as time goes by. Little, if any, documentation currently exists at this time on the process of creating deltas, so talk to &a.phk; for more information should you wish to use CTM for other things. Why Should I Use <application>CTM</application>? CTM will give you a local copy of the FreeBSD source trees. There are a number of flavors of the tree available. Whether you wish to track the entire CVS tree or just one of the branches, CTM can provide you the information. If you are an active developer on FreeBSD, but have lousy or non-existent TCP/IP connectivity, or simply wish to have the changes automatically sent to you, CTM was made for you. You will need to obtain up to three deltas per day for the most active branches. However, you should consider having them sent by automatic email. The sizes of the updates are always kept as small as possible. This is typically less than 5K, with an occasional (one in ten) being 10-50K and every now and then a large 100K+ or more coming around. You will also need to make yourself aware of the various caveats related to working directly from the development sources rather than a pre-packaged release. This is particularly true if you choose the current sources. It is recommended that you read Staying current with FreeBSD. What Do I Need to Use <application>CTM</application>? You will need two things: The CTM program, and the initial deltas to feed it (to get up to current levels). The CTM program has been part of FreeBSD ever since version 2.0 was released, and lives in /usr/src/usr.sbin/ctm if you have a copy of the source available. If you are running a pre-2.0 version of FreeBSD, you can fetch the current CTM sources directly from: - ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/ + The deltas you feed CTM can be had two ways, FTP or email. If you have general FTP access to the Internet then the following FTP sites support access to CTM: - ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/ + or see section mirrors. FTP the relevant directory and fetch the README file, starting from there. If you wish to get your deltas via email: Send email to &a.majordomo; to subscribe to one of the CTM distribution lists. ctm-cvs-cur supports the entire CVS tree. ctm-src-cur supports the head of the development branch. ctm-src-2_2 supports the 2.2 release branch, etc.. (If you do not know how to subscribe yourself using majordomo, send a message first containing the word help — it will send you back usage instructions.) When you begin receiving your CTM updates in the mail, you may use the ctm_rmail program to unpack and apply them. You can actually use the ctm_rmail program directly from a entry in /etc/aliases if you want to have the process run in a fully automated fashion. Check the ctm_rmail manual page for more details. No matter what method you use to get the CTM deltas, you should subscribe to the ctm-announce@FreeBSD.org mailing list. In the future, this will be the only place where announcements concerning the operations of the CTM system will be posted. Send an email to &a.majordomo; with a single line of subscribe ctm-announce to get added to the list. Using <application>CTM</application> for the First Time Before you can start using CTM deltas, you will need to get to a starting point for the deltas produced subsequently to it. First you should determine what you already have. Everyone can start from an empty directory. You must use an initial Empty delta to start off your CTM supported tree. At some point it is intended that one of these started deltas be distributed on the CD for your convenience, however, this does not currently happen. Since the trees are many tens of megabytes, you should prefer to start from something already at hand. If you have a -RELEASE CD, you can copy or extract an initial source from it. This will save a significant transfer of data. You can recognize these starter deltas by the X appended to the number (src-cur.3210XEmpty.gz for instance). The designation following the X corresponds to the origin of your initial seed. Empty is an empty directory. As a rule a base transition from Empty is produced every 100 deltas. By the way, they are large! 70 to 80 Megabytes of gzip'd data is common for the XEmpty deltas. Once you have picked a base delta to start from, you will also need all deltas with higher numbers following it. Using <application>CTM</application> in Your Daily Life To apply the deltas, simply say: &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* CTM understands deltas which have been put through gzip, so you do not need to gunzip them first, this saves disk space. Unless it feels very secure about the entire process, CTM will not touch your tree. To verify a delta you can also use the flag and CTM will not actually touch your tree; it will merely verify the integrity of the delta and see if it would apply cleanly to your current tree. There are other options to CTM as well, see the manual pages or look in the sources for more information. That is really all there is to it. Every time you get a new delta, just run it through CTM to keep your sources up to date. Do not remove the deltas if they are hard to download again. You just might want to keep them around in case something bad happens. Even if you only have floppy disks, consider using fdwrite to make a copy. Keeping Your Local Changes As a developer one would like to experiment with and change files in the source tree. CTM supports local modifications in a limited way: before checking for the presence of a file foo, it first looks for foo.ctm. If this file exists, CTM will operate on it instead of foo. This behavior gives us a simple way to maintain local changes: simply copy the files you plan to modify to the corresponding file names with a .ctm suffix. Then you can freely hack the code, while CTM keeps the .ctm file up-to-date. Other Interesting <application>CTM</application> Options Finding Out Exactly What Would Be Touched by an Update You can determine the list of changes that CTM will make on your source repository using the option to CTM. This is useful if you would like to keep logs of the changes, pre- or post- process the modified files in any manner, or just are feeling a tad paranoid. Making Backups Before Updating Sometimes you may want to backup all the files that would be changed by a CTM update. Specifying the option causes CTM to backup all files that would be touched by a given CTM delta to backup-file. Restricting the Files Touched by an Update Sometimes you would be interested in restricting the scope of a given CTM update, or may be interested in extracting just a few files from a sequence of deltas. You can control the list of files that CTM would operate on by specifying filtering regular expressions using the and options. For example, to extract an up-to-date copy of lib/libc/Makefile from your collection of saved CTM deltas, run the commands: &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* For every file specified in a CTM delta, the and options are applied in the order given on the command line. The file is processed by CTM only if it is marked as eligible after all the and options are applied to it. Future Plans for <application>CTM</application> Tons of them: Use some kind of authentication into the CTM system, so as to allow detection of spoofed CTM updates. Clean up the options to CTM, they became confusing and counter intuitive. Miscellaneous Stuff There is a sequence of deltas for the ports collection too, but interest has not been all that high yet. CTM Mirrors CTM/FreeBSD is available via anonymous FTP from the following mirror sites. If you choose to obtain CTM via anonymous FTP, please try to use a site near you. In case of problems, please contact &a.phk;. California, Bay Area, official source - ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CTM/ + South Africa, backup server for old deltas - ftp://ftp.za.FreeBSD.org/pub/FreeBSD/CTM/ + Taiwan/R.O.C. - ftp://ctm.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ + - ftp://ctm2.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ + - ftp://ctm3.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ + If you did not find a mirror near to you or the mirror is incomplete, try to use a search engine such as alltheweb. Using CVSup Introduction CVSup is a software package for distributing and updating source trees from a master CVS repository on a remote server host. The FreeBSD sources are maintained in a CVS repository on a central development machine in California. With CVSup, FreeBSD users can easily keep their own source trees up to date. CVSup uses the so-called pull model of updating. Under the pull model, each client asks the server for updates, if and when they are wanted. The server waits passively for update requests from its clients. Thus all updates are instigated by the client. The server never sends unsolicited updates. Users must either run the CVSup client manually to get an update, or they must set up a cron job to run it automatically on a regular basis. The term CVSup, capitalized just so, refers to the entire software package. Its main components are the client cvsup which runs on each user's machine, and the server cvsupd which runs at each of the FreeBSD mirror sites. As you read the FreeBSD documentation and mailing lists, you may see references to sup. Sup was the predecessor of CVSup, and it served a similar purpose. CVSup is used much in the same way as sup and, in fact, uses configuration files which are backward-compatible with sup's. Sup is no longer used in the FreeBSD project, because CVSup is both faster and more flexible. Installation The easiest way to install CVSup is to use the precompiled net/cvsup package from the FreeBSD packages collection. If you prefer to build CVSup from source, you can use the net/cvsup port instead. But be forewarned: the net/cvsup port depends on the Modula-3 system, which takes a substantial amount of time and disk space to download and build. If you are going to be using CVSup on a machine which will not have XFree86 installed, such as a server, be sure to use the port which does not include the CVSup GUI, net/cvsup-without-gui. If you do not know anything about CVSup at all and want a single package which will install it, set up the configuration file and start the transfer via a pointy-clicky type of interface, then get the net/cvsupit package. Just hand it to &man.pkg.add.1; and it will lead you through the configuration process in a menu-oriented fashion. CVSup Configuration CVSup's operation is controlled by a configuration file called the supfile. There are some sample supfiles in the directory /usr/share/examples/cvsup/. The information in a supfile answers the following questions for cvsup: Which files do you want to receive? Which versions of them do you want? Where do you want to get them from? Where do you want to put them on your own machine? Where do you want to put your status files? In the following sections, we will construct a typical supfile by answering each of these questions in turn. First, we describe the overall structure of a supfile. A supfile is a text file. Comments begin with # and extend to the end of the line. Lines that are blank and lines that contain only comments are ignored. Each remaining line describes a set of files that the user wishes to receive. The line begins with the name of a collection, a logical grouping of files defined by the server. The name of the collection tells the server which files you want. After the collection name come zero or more fields, separated by white space. These fields answer the questions listed above. There are two types of fields: flag fields and value fields. A flag field consists of a keyword standing alone, e.g., delete or compress. A value field also begins with a keyword, but the keyword is followed without intervening white space by = and a second word. For example, release=cvs is a value field. A supfile typically specifies more than one collection to receive. One way to structure a supfile is to specify all of the relevant fields explicitly for each collection. However, that tends to make the supfile lines quite long, and it is inconvenient because most fields are the same for all of the collections in a supfile. CVSup provides a defaulting mechanism to avoid these problems. Lines beginning with the special pseudo-collection name *default can be used to set flags and values which will be used as defaults for the subsequent collections in the supfile. A default value can be overridden for an individual collection, by specifying a different value with the collection itself. Defaults can also be changed or augmented in mid-supfile by additional *default lines. With this background, we will now proceed to construct a supfile for receiving and updating the main source tree of FreeBSD-CURRENT. Which files do you want to receive? The files available via CVSup are organized into named groups called collections. The collections that are available are described in the following section. In this example, we wish to receive the entire main source tree for the FreeBSD system. There is a single large collection src-all which will give us all of that. As a first step toward constructing our supfile, we simply list the collections, one per line (in this case, only one line): src-all Which version(s) of them do you want? With CVSup, you can receive virtually any version of the sources that ever existed. That is possible because the cvsupd server works directly from the CVS repository, which contains all of the versions. You specify which one of them you want using the tag= and value fields. Be very careful to specify any tag= fields correctly. Some tags are valid only for certain collections of files. If you specify an incorrect or misspelled tag, CVSup will delete files which you probably do not want deleted. In particular, use only tag=. for the ports-* collections. The tag= field names a symbolic tag in the repository. There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today. contains branch tags that users might be interested in. When specifying a tag in CVSup's configuration file, it must be preceded with tag= (RELENG_4 will become tag=RELENG_4). Keep in mind that only the tag=. is relevant for the ports collection. Be very careful to type the tag name exactly as shown. CVSup cannot distinguish between valid and invalid tags. If you misspell the tag, CVSup will behave as though you had specified a valid tag which happens to refer to no files at all. It will delete your existing sources in that case. When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the value field. The &man.cvsup.1; manual page explains how to do that. For our example, we wish to receive FreeBSD-CURRENT. We add this line at the beginning of our supfile: *default tag=. There is an important special case that comes into play if you specify neither a tag= field nor a date= field. In that case, you receive the actual RCS files directly from the server's CVS repository, rather than receiving a particular version. Developers generally prefer this mode of operation. By maintaining a copy of the repository itself on their systems, they gain the ability to browse the revision histories and examine past versions of files. This gain is achieved at a large cost in terms of disk space, however. Where do you want to get them from? We use the host= field to tell cvsup where to obtain its updates. Any of the CVSup mirror sites will do, though you should try to select one that is close to you in cyberspace. In this example we will use a fictional FreeBSD distribution site, cvsup666.FreeBSD.org: *default host=cvsup666.FreeBSD.org You will need to change the host to one that actually exists before running CVSup. On any particular run of cvsup, you can override the host setting on the command line, with . Where do you want to put them on your own machine? The prefix= field tells cvsup where to put the files it receives. In this example, we will put the source files directly into our main source tree, /usr/src. The src directory is already implicit in the collections we have chosen to receive, so this is the correct specification: *default prefix=/usr Where should cvsup maintain its status files? The CVSup client maintains certain status files in what is called the base directory. These files help CVSup to work more efficiently, by keeping track of which updates you have already received. We will use the standard base directory, /usr/local/etc/cvsup: *default base=/usr/local/etc/cvsup This setting is used by default if it is not specified in the supfile, so we actually do not need the above line. If your base directory does not already exist, now would be a good time to create it. The cvsup client will refuse to run if the base directory does not exist. Miscellaneous supfile settings: There is one more line of boiler plate that normally needs to be present in the supfile: *default release=cvs delete use-rel-suffix compress release=cvs indicates that the server should get its information out of the main FreeBSD CVS repository. This is virtually always the case, but there are other possibilities which are beyond the scope of this discussion. delete gives CVSup permission to delete files. You should always specify this, so that CVSup can keep your source tree fully up-to-date. CVSup is careful to delete only those files for which it is responsible. Any extra files you happen to have will be left strictly alone. use-rel-suffix is ... arcane. If you really want to know about it, see the &man.cvsup.1; manual page. Otherwise, just specify it and do not worry about it. compress enables the use of gzip-style compression on the communication channel. If your network link is T1 speed or faster, you probably should not use compression. Otherwise, it helps substantially. Putting it all together: Here is the entire supfile for our example: *default tag=. *default host=cvsup666.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all The <filename>refuse</filename> File As mentioned above, CVSup uses a pull method. Basically, this means that you connect to the CVSup server, and it says, Here is what you can download from me..., and your client responds OK, I will take this, this, this, and this. In the default configuration, the CVSup client will take every file associated with the collection and tag you chose in the configuration file. However, this is not always what you want, especially if you are synching the doc, ports, or www trees — most people cannot read four or five languages, and therefore they do not need to download the language-specific files. If you are CVSuping the ports collection, you can get around this by specifying each collection individually (e.g., ports-astrology, ports-biology, etc instead of simply saying ports-all). However, since the doc and www trees do not have language-specific collections, you must use one of CVSup's many nifty features; the refuse file. The refuse file essentially tells CVSup that it should not take every single file from a collection; in other words, it tells the client to refuse certain files from the server. The refuse file can be found (or, if you do not yet have one, should be placed) in base/sup/refuse. base is defined in your supfile; by default, base is /usr/local/etc/cvsup, which means that by default the refuse file is in /usr/local/etc/cvsup/sup/refuse. The refuse file has a very simple format; it simply contains the names of files or directories that you do not wish to download. For example, if you cannot speak any languages other than English and some German, and you do not feel the need to use the German applications (or applications for any other languages, except for English), you can put the following in your refuse file: ports/chinese ports/french ports/german ports/hebrew ports/japanese ports/hungarian ports/korean ports/portuguese ports/russian ports/ukrainian ports/vietnamese doc/de_DE.ISO8859-1 doc/el_GR.ISO8859-7 doc/es_ES.ISO8859-1 doc/fr_FR.ISO8859-1 doc/it_IT.ISO8859-15 doc/ja_JP.eucJP doc/nl_NL.ISO8859-1 doc/pt_BR.ISO8859-1 doc/ru_RU.KOI8-R doc/sr_YU.ISO8859-2 doc/zh_TW.Big5 and so forth for the other languages (you can find the full list by browsing the FreeBSD FTP server). Note that the name of the repository is the first directory in the refuse file. With this very useful feature, those users who are on slow links or pay by the minute for their Internet connection will be able to save valuable time as they will no longer need to download files that they will never use. For more information on refuse files and other neat features of CVSup, please view its manual page. Running <application>CVSup</application> You are now ready to try an update. The command line for doing this is quite simple: &prompt.root; cvsup supfile where supfile is of course the name of the supfile you have just created. Assuming you are running under X11, cvsup will display a GUI window with some buttons to do the usual things. Press the go button, and watch it run. Since you are updating your actual /usr/src tree in this example, you will need to run the program as root so that cvsup has the permissions it needs to update your files. Having just created your configuration file, and having never used this program before, that might understandably make you nervous. There is an easy way to do a trial run without touching your precious files. Just create an empty directory somewhere convenient, and name it as an extra argument on the command line: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest The directory you specify will be used as the destination directory for all file updates. CVSup will examine your usual files in /usr/src, but it will not modify or delete any of them. Any file updates will instead land in /var/tmp/dest/usr/src. CVSup will also leave its base directory status files untouched when run this way. The new versions of those files will be written into the specified directory. As long as you have read access to /usr/src, you do not even need to be root to perform this kind of trial run. If you are not running X11 or if you just do not like GUIs, you should add a couple of options to the command line when you run cvsup: &prompt.root; cvsup -g -L 2 supfile The tells CVSup not to use its GUI. This is automatic if you are not running X11, but otherwise you have to specify it. The tells CVSup to print out the details of all the file updates it is doing. There are three levels of verbosity, from to . The default is 0, which means total silence except for error messages. There are plenty of other options available. For a brief list of them, type cvsup -H. For more detailed descriptions, see the manual page. Once you are satisfied with the way updates are working, you can arrange for regular runs of CVSup using &man.cron.8;. Obviously, you should not let CVSup use its GUI when running it from &man.cron.8;. <application>CVSup</application> File Collections The file collections available via CVSup are organized hierarchically. There are a few large collections, and they are divided into smaller sub-collections. Receiving a large collection is equivalent to receiving each of its sub-collections. The hierarchical relationships among collections are reflected by the use of indentation in the list below. The most commonly used collections are src-all, and ports-all. The other collections are used only by small groups of people for specialized purposes, and some mirror sites may not carry all of them. cvs-all release=cvs The main FreeBSD CVS repository, including the cryptography code. distrib release=cvs Files related to the distribution and mirroring of FreeBSD. doc-all release=cvs Sources for the FreeBSD Handbook and other documentation. This does not include files for the FreeBSD web site. ports-all release=cvs The FreeBSD Ports Collection. If you do not want to update the whole of ports-all (the whole ports tree), but use one of the subcollections listed below, make sure that you always update the ports-base subcollection! Whenever something changes in the ports build infrastructure represented by ports-base, it is virtually certain that those changes will be used by real ports real soon. Thus, if you only update the real ports and they use some of the new features, there is a very high chance that their build will fail with some mysterious error message. The very first thing to do in this case is to make sure that your ports-base subcollection is up to date. ports-archivers release=cvs Archiving tools. ports-astro release=cvs Astronomical ports. ports-audio release=cvs Sound support. ports-base release=cvs The Ports Collection build infrastructure - various files located in the Mk/ and Tools/ subdirectories of /usr/ports. Please see the important warning above: you should always update this subcollection, whenever you update any part of the FreeBSD Ports Collection! ports-benchmarks release=cvs Benchmarks. ports-biology release=cvs Biology. ports-cad release=cvs Computer aided design tools. ports-chinese release=cvs Chinese language support. ports-comms release=cvs Communication software. ports-converters release=cvs character code converters. ports-databases release=cvs Databases. ports-deskutils release=cvs Things that used to be on the desktop before computers were invented. ports-devel release=cvs Development utilities. ports-editors release=cvs Editors. ports-emulators release=cvs Emulators for other operating systems. ports-finance release=cvs Monetary, financial and related applications. ports-ftp release=cvs FTP client and server utilities. ports-games release=cvs Games. ports-german release=cvs German language support. ports-graphics release=cvs Graphics utilities. ports-hungarian release=cvs Hungarian language support. ports-irc release=cvs Internet Relay Chat utilities. ports-japanese release=cvs Japanese language support. ports-java release=cvs Java utilities. ports-korean release=cvs Korean language support. ports-lang release=cvs Programming languages. ports-mail release=cvs Mail software. ports-math release=cvs Numerical computation software. ports-mbone release=cvs MBone applications. ports-misc release=cvs Miscellaneous utilities. ports-multimedia release=cvs Multimedia software. ports-net release=cvs Networking software. ports-news release=cvs USENET news software. ports-palm release=cvs Software support for Palm series. ports-portuguese release=cvs Portuguese language support. ports-print release=cvs Printing software. ports-russian release=cvs Russian language support. ports-security release=cvs Security utilities. ports-shells release=cvs Command line shells. ports-sysutils release=cvs System utilities. ports-textproc release=cvs text processing utilities (does not include desktop publishing). ports-vietnamese release=cvs Vietnamese language support. ports-www release=cvs Software related to the World Wide Web. ports-x11 release=cvs Ports to support the X window system. ports-x11-clocks release=cvs X11 clocks. ports-x11-fm release=cvs X11 file managers. ports-x11-fonts release=cvs X11 fonts and font utilities. ports-x11-toolkits release=cvs X11 toolkits. ports-x11-servers X11 servers. ports-x11-wm X11 window managers. src-all release=cvs The main FreeBSD sources, including the cryptography code. src-base release=cvs Miscellaneous files at the top of /usr/src. src-bin release=cvs User utilities that may be needed in single-user mode (/usr/src/bin). src-contrib release=cvs Utilities and libraries from outside the FreeBSD project, used relatively unmodified (/usr/src/contrib). src-crypto release=cvs Cryptography utilities and libraries from outside the FreeBSD project, used relatively unmodified (/usr/src/crypto). src-eBones release=cvs Kerberos and DES (/usr/src/eBones). Not used in current releases of FreeBSD. src-etc release=cvs System configuration files (/usr/src/etc). src-games release=cvs Games (/usr/src/games). src-gnu release=cvs Utilities covered by the GNU Public License (/usr/src/gnu). src-include release=cvs Header files (/usr/src/include). src-kerberos5 release=cvs Kerberos5 security package (/usr/src/kerberos5). src-kerberosIV release=cvs KerberosIV security package (/usr/src/kerberosIV). src-lib release=cvs Libraries (/usr/src/lib). src-libexec release=cvs System programs normally executed by other programs (/usr/src/libexec). src-release release=cvs Files required to produce a FreeBSD release (/usr/src/release). src-sbin release=cvs System utilities for single-user mode (/usr/src/sbin). src-secure release=cvs Cryptographic libraries and commands (/usr/src/secure). src-share release=cvs Files that can be shared across multiple systems (/usr/src/share). src-sys release=cvs The kernel (/usr/src/sys). src-sys-crypto release=cvs Kernel cryptography code (/usr/src/sys/crypto). src-tools release=cvs Various tools for the maintenance of FreeBSD (/usr/src/tools). src-usrbin release=cvs User utilities (/usr/src/usr.bin). src-usrsbin release=cvs System utilities (/usr/src/usr.sbin). www release=cvs The sources for the FreeBSD WWW site. distrib release=self The CVSup server's own configuration files. Used by CVSup mirror sites. gnats release=current The GNATS bug-tracking database. mail-archive release=current FreeBSD mailing list archive. www release=current The pre-processed FreeBSD WWW site files (not the source files). Used by WWW mirror sites. For More Information For the CVSup FAQ and other information about CVSup, see The CVSup Home Page. Most FreeBSD-related discussion of CVSup takes place on the &a.hackers;. New versions of the software are announced there, as well as on the &a.announce;. Questions and bug reports should be addressed to the author of the program at cvsup-bugs@polstra.com. CVSup Sites CVSup servers for FreeBSD are running at the following sites: Argentina cvsup.ar.FreeBSD.org (maintainer msagre@cactus.fi.uba.ar) Australia cvsup.au.FreeBSD.org (maintainer cvsup@ntt.net.au) cvsup2.au.FreeBSD.org (maintainer cvsup@isp.net.au) cvsup3.au.FreeBSD.org (maintainer cvsup@speednet.com.au) cvsup4.au.FreeBSD.org (maintainer cvsup@ideal.net.au) cvsup5.au.FreeBSD.org (maintainer cvsup@netlead.com.au) Austria cvsup.at.FreeBSD.org (maintainer postmaster@wu-wien.ac.at) cvsup2.at.FreeBSD.org (maintainer ftp-admin.zid@univie.ac.at) Brazil cvsup.br.FreeBSD.org (maintainer cvsup@cvsup.br.FreeBSD.org) cvsup2.br.FreeBSD.org (maintainer tps@ti.sk) cvsup3.br.FreeBSD.org (maintainer camposr@matrix.com.br) cvsup4.br.FreeBSD.org (maintainer cvsup@tcoip.com.br) cvsup5.br.FreeBSD.org (maintainer hostmaster@br.FreeBSD.org) Bulgaria cvsup.bg.FreeBSD.org (maintainer hostmaster@bg.FreeBSD.org) Canada cvsup.ca.FreeBSD.org (maintainer cvsup@ca.FreeBSD.org) China cvsup.cn.FreeBSD.org (maintainer phj@cn.FreeBSD.org) Czech Republic cvsup.cz.FreeBSD.org (maintainer cejkar@fit.vutbr.cz) Denmark cvsup.dk.FreeBSD.org (maintainer jesper@FreeBSD.org) Estonia cvsup.ee.FreeBSD.org (maintainer taavi@uninet.ee) Finland cvsup.fi.FreeBSD.org (maintainer count@key.sms.fi) cvsup2.fi.FreeBSD.org (maintainer count@key.sms.fi) France cvsup.fr.FreeBSD.org (maintainer hostmaster@fr.FreeBSD.org) cvsup2.fr.FreeBSD.org (maintainer ftpmaint@uvsq.fr) cvsup3.fr.FreeBSD.org (maintainer ftpmaint@enst.fr) cvsup4.fr.FreeBSD.org (maintainer ftpmaster@t-online.fr) cvsup5.fr.FreeBSD.org (maintainer freebsdcvsup@teaser.net) cvsup8.fr.FreeBSD.org (maintainer ftpmaint@crc.u-strasbg.fr) Germany cvsup.de.FreeBSD.org (maintainer cvsup@cosmo-project.de) cvsup2.de.FreeBSD.org (maintainer cvsup@apfel.de) cvsup3.de.FreeBSD.org (maintainer ag@leo.org) cvsup4.de.FreeBSD.org (maintainer cvsup@cosmo-project.de) cvsup5.de.FreeBSD.org (maintainer &a.rse;) cvsup6.de.FreeBSD.org (maintainer adminmail@heitec.net) cvsup7.de.FreeBSD.org (maintainer karsten@rohrbach.de) Greece cvsup.gr.FreeBSD.org (maintainer ftpadm@duth.gr) cvsup2.gr.FreeBSD.org (maintainer paschos@cs.uoi.gr) Hungary cvsup.hu.FreeBSD.org (maintainer janos.mohacsi@bsd.hu) Iceland cvsup.is.FreeBSD.org (maintainer hostmaster@is.FreeBSD.org) Ireland cvsup.ie.FreeBSD.org (maintainer dwmalone@maths.tcd.ie), Trinity College, Dublin. Japan cvsup.jp.FreeBSD.org (maintainer cvsupadm@jp.FreeBSD.org) cvsup2.jp.FreeBSD.org (maintainer &a.max;) cvsup3.jp.FreeBSD.org (maintainer shige@cin.nihon-u.ac.jp) cvsup4.jp.FreeBSD.org (maintainer cvsup-admin@ftp.media.kyoto-u.ac.jp) cvsup5.jp.FreeBSD.org (maintainer cvsup@imasy.or.jp) cvsup6.jp.FreeBSD.org (maintainer cvsupadm@jp.FreeBSD.org) Korea cvsup.kr.FreeBSD.org (maintainer cjh@kr.FreeBSD.org) cvsup2.kr.FreeBSD.org (maintainer holywar@mail.holywar.net) cvsup3.kr.FreeBSD.org (maintainer leo@florida.sarang.net) Kuwait cvsup1.kw.FreeBSD.org (maintainer sysadmin@kems.net) Latvia cvsup.lv.FreeBSD.org (maintainer system@soft.lv) Lithuania cvsup.lt.FreeBSD.org (maintainer domas.mituzas@delfi.lt) cvsup2.lt.FreeBSD.org (maintainer vaidas.damosevicius@if.lt) New Zealand cvsup.nz.FreeBSD.org (maintainer cvsup@langille.org) Netherlands cvsup.nl.FreeBSD.org (maintainer xaa@xaa.iae.nl) cvsup2.nl.FreeBSD.org (maintainer cvsup@nl.uu.net) cvsup3.nl.FreeBSD.org (maintainer cvsup@vuurwerk.nl) cvsup4.nl.FreeBSD.org (maintainer hostmaster@cvsup4.nl.FreeBSD.org) Norway cvsup.no.FreeBSD.org (maintainer Per.Hove@math.ntnu.no) Poland cvsup.pl.FreeBSD.org (maintainer Mariusz@kam.pl) cvsup2.pl.FreeBSD.org (maintainer hostmaster@cvsup2.pl.FreeBSD.org) cvsup3.pl.FreeBSD.org (maintainer hostmaster@cvsup3.pl.FreeBSD.org) Portugal cvsup.pt.FreeBSD.org (maintainer jpedras@webvolution.net) Romania cvsup.ro.FreeBSD.org (maintainer razor@ldc.ro) cvsup2.ro.FreeBSD.org (maintainer hostmaster@rofug.ro) cvsup3.ro.FreeBSD.org (maintainer veedee@c7.campus.utcluj.ro) Russia cvsup.ru.FreeBSD.org (maintainer ache@nagual.pp.ru) cvsup2.ru.FreeBSD.org (maintainer dv@dv.ru) cvsup3.ru.FreeBSD.org (maintainer fjoe@iclub.nsu.ru) cvsup4.ru.FreeBSD.org (maintainer maxim@macomnet.ru) cvsup5.ru.FreeBSD.org (maintainer maxim@macomnet.ru) cvsup6.ru.FreeBSD.org (maintainer pvr@corbina.net) San Marino cvsup.sm.FreeBSD.org (maintainer sysadmin@alexdupre.com) Singapore cvsup.sg.FreeBSD.org (maintainer mirror-maintainer@mirror.averse.net) Slovak Republic cvsup.sk.FreeBSD.org (maintainer scorp@scorp.sk) cvsup2.sk.FreeBSD.org (maintainer scorp@scorp.sk) Slovenia cvsup.si.FreeBSD.org (maintainer blaz@si.FreeBSD.org) cvsup2.si.FreeBSD.org (maintainer cuk@cuk.nu) South Africa cvsup.za.FreeBSD.org (maintainer &a.markm;) cvsup2.za.FreeBSD.org (maintainer &a.markm;) Spain cvsup.es.FreeBSD.org (maintainer &a.jesusr;) cvsup2.es.FreeBSD.org (maintainer &a.jesusr;) cvsup3.es.FreeBSD.org (maintainer jose@we.lc.ehu.es) Sweden cvsup.se.FreeBSD.org (maintainer pantzer@ludd.luth.se) cvsup2.se.FreeBSD.org (maintainer cvsup@dataphone.net) Taiwan cvsup.tw.FreeBSD.org (maintainer ijliao@FreeBSD.org) cvsup3.tw.FreeBSD.org (maintainer foxfair@FreeBSD.org) cvsup4.tw.FreeBSD.org (maintainer einstein@NHCTC.edu.tw) cvsup5.tw.FreeBSD.org (maintainer einstein@NHCTC.edu.tw) cvsup6.tw.FreeBSD.org (maintainer jason@tw.FreeBSD.org) cvsup7.tw.FreeBSD.org (maintainer cvsup@abpe.org) cvsup8.tw.FreeBSD.org (maintainer heboy@FreeBSD.tku.edu.tw) cvsup9.tw.FreeBSD.org (maintainer cs871256@csie.ncu.edu.tw) cvsup10.tw.FreeBSD.org (maintainer rafan@infor.org) cvsup11.tw.FreeBSD.org (maintainer vanilla@FreeBSD.org) cvsup12.tw.FreeBSD.org (maintainer GEO.bbs@birdnest.twbbs.org) cvsup13.tw.FreeBSD.org (maintainer cdsheen@tw.FreeBSD.org) Turkey cvsup.tr.FreeBSD.org (maintainer roots@enderunix.org) Ukraine cvsup2.ua.FreeBSD.org (maintainer freebsd-mnt@lucky.net) cvsup3.ua.FreeBSD.org (maintainer ftpmaster@ukr.net), Kiev cvsup4.ua.FreeBSD.org (maintainer phantom@cris.net) cvsup5.ua.FreeBSD.org (maintainer never@nevermind.kiev.ua) cvsup6.ua.FreeBSD.org (maintainer freebsd-cvs@colocall.net) cvsup7.ua.FreeBSD.org (maintainer never@nevermind.kiev.ua) United Kingdom cvsup.uk.FreeBSD.org (maintainer ftp-admin@plig.net) cvsup2.uk.FreeBSD.org (maintainer &a.brian;) cvsup3.uk.FreeBSD.org (maintainer ben.hughes@uk.easynet.net) cvsup4.uk.FreeBSD.org (maintainer ejb@leguin.org.uk) cvsup5.uk.FreeBSD.org (maintainer mirror@teleglobe.net) USA cvsup1.FreeBSD.org (maintainer cwt@networks.cwu.edu), Washington state cvsup2.FreeBSD.org (maintainers djs@secure.net and &a.nectar;), Virginia cvsup3.FreeBSD.org (maintainer &a.wollman;), Massachusetts cvsup5.FreeBSD.org (maintainer mjr@blackened.com), Arizona cvsup6.FreeBSD.org (maintainer cvsup@cvsup.adelphiacom.net), Illinois cvsup7.FreeBSD.org (maintainer &a.jdp;), Washington state cvsup8.FreeBSD.org (maintainer hostmaster@bigmirror.com), Washington state cvsup9.FreeBSD.org (maintainer &a.jdp;), Minnesota cvsup10.FreeBSD.org (maintainer &a.jdp;), California cvsup11.FreeBSD.org (maintainer cvsup@research.uu.net), Virginia cvsup12.FreeBSD.org (maintainer &a.will;), Indiana cvsup13.FreeBSD.org (maintainer dima@valueclick.com), California cvsup14.FreeBSD.org (maintainer freebsd-cvsup@mfnx.net), California cvsup15.FreeBSD.org (maintainer cvsup@math.uic.edu), Illinois cvsup16.FreeBSD.org (maintainer pth3k@virginia.edu), Virginia cvsup17.FreeBSD.org (maintainer cvsup@mirrortree.com), Washington state CVS Tags When obtaining or updating sources from cvs and CVSup a revision tag (reference to a date in time) must be specified. The following tags are available, each specifying different branches of FreeBSD at different points of time: The ports tree does not have any tag associated with it, it is always CURRENT. The most common tags are: HEAD Symbolic name for the main line, or FreeBSD-CURRENT. Also the default when no revision is specified. In CVSup, this tag is represented by a . (not punctuation, but a literal . character). In CVS, this is the default when no revision tag is specified. It is usually not a good idea to checkout or update to CURRENT sources on a STABLE machine, unless that is your intent. RELENG_5_0 The release branch for FreeBSD-5.0, used only for security advisories and other seriously critical fixes. RELENG_4 The line of development for FreeBSD-4.X, also known as FreeBSD-STABLE. RELENG_4_8 The release branch for FreeBSD-4.8, used only for security advisories and other seriously critical fixes. RELENG_4_7 The release branch for FreeBSD-4.7, used only for security advisories and other seriously critical fixes. RELENG_4_6 The release branch for FreeBSD-4.6 and FreeBSD-4.6.2, used only for security advisories and other seriously critical fixes. RELENG_4_5 The release branch for FreeBSD-4.5, used only for security advisories and other seriously critical fixes. RELENG_4_4 The release branch for FreeBSD-4.4, used only for security advisories and other seriously critical fixes. RELENG_4_3 The release branch for FreeBSD-4.3, used only for security advisories and other seriously critical fixes. RELENG_3 The line of development for FreeBSD-3.X, also known as 3.X-STABLE. RELENG_2_2 The line of development for FreeBSD-2.2.X, also known as 2.2-STABLE. This branch is mostly obsolete. Other revision tags that are available include: RELENG_4_8_0_RELEASE FreeBSD 4.8 RELENG_5_0_0_RELEASE FreeBSD 5.0 RELENG_4_7_0_RELEASE FreeBSD 4.7 RELENG_4_6_2_RELEASE FreeBSD 4.6.2 RELENG_4_6_1_RELEASE FreeBSD 4.6.1 RELENG_4_6_0_RELEASE FreeBSD 4.6 RELENG_4_5_0_RELEASE FreeBSD 4.5. RELENG_4_4_0_RELEASE FreeBSD 4.4. RELENG_4_3_0_RELEASE FreeBSD 4.3. RELENG_4_2_0_RELEASE FreeBSD 4.2. RELENG_4_1_1_RELEASE FreeBSD 4.1.1. RELENG_4_1_0_RELEASE FreeBSD 4.1. RELENG_4_0_0_RELEASE FreeBSD 4.0. RELENG_3_5_0_RELEASE FreeBSD-3.5. RELENG_3_4_0_RELEASE FreeBSD-3.4. RELENG_3_3_0_RELEASE FreeBSD-3.3. RELENG_3_2_0_RELEASE FreeBSD-3.2. RELENG_3_1_0_RELEASE FreeBSD-3.1. RELENG_3_0_0_RELEASE FreeBSD-3.0. RELENG_2_2_8_RELEASE FreeBSD-2.2.8. RELENG_2_2_7_RELEASE FreeBSD-2.2.7. RELENG_2_2_6_RELEASE FreeBSD-2.2.6. RELENG_2_2_5_RELEASE FreeBSD-2.2.5. RELENG_2_2_2_RELEASE FreeBSD-2.2.2. RELENG_2_2_1_RELEASE FreeBSD-2.2.1. RELENG_2_2_0_RELEASE FreeBSD-2.2.0. AFS Sites AFS servers for FreeBSD are running at the following sites: Sweden The path to the files are: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Sweden 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Maintainer ftp@stacken.kth.se rsync sites The following sites make FreeBSD available through the rsync protocol. The rsync utility works in much the same way as the rcp command, but has more options and uses the rsync remote-update protocol which transfers only the differences between two sets of files, thus greatly speeding up the synchronization over the network. This is most useful if you are a mirror site for the FreeBSD FTP server, or the CVS repository. The rsync suite is available for many operating systems, on FreeBSD, see the net/rsync port or use the package. Czech Republic rsync://ftp.cz.FreeBSD.org/ Available collections: ftp: A partial mirror of the FreeBSD FTP server. FreeBSD: A full mirror of the FreeBSD FTP server. Germany rsync://grappa.unix-ag.uni-kl.de/ Available collections: freebsd-cvs: The full FreeBSD CVS repository. This machine also mirrors the CVS repositories of the NetBSD and the OpenBSD projects, among others. Netherlands rsync://ftp.nl.FreeBSD.org/ Available collections: vol/3/freebsd-core: A full mirror of the FreeBSD FTP server. United Kingdom rsync://rsync.mirror.ac.uk/ Available collections: ftp.freebsd.org: A full mirror of the FreeBSD FTP server. United States of America rsync://ftp-master.FreeBSD.org/ This server may only be used by FreeBSD primary mirror sites. Available collections: FreeBSD: The master archive of the FreeBSD FTP server. acl: The FreeBSD master ACL list. rsync://ftp13.FreeBSD.org/ Available collections: FreeBSD: A full mirror of the FreeBSD FTP server.