diff --git a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml index 3d12999b01..72a0f1d485 100644 --- a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml @@ -1,576 +1,576 @@ 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 5 - Installieren, Konfigurieren, Administrieren (in German), published by Computer und Literatur Verlag, 2003. ISBN 3-936546-06-1. 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 Spinellis, Diomidis. Code Reading: The Open Source Perspective. Addison-Wesley, 2003. ISBN 0-201-79940-5 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. - + or /usr/share/misc/bsd-family-tree on a modern FreeBSD machine. The BSD Release Announcements collection. 1997. Networked Computer Science Technical Reports Library. Old BSD releases from the Computer Systems Research 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 freeX — Das Magazin für Linux - BSD - UNIX (in German) Computer- und Literaturverlag GmbH, ISSN 1436-7033 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 fe0f0f552e..f075697557 100644 --- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,1851 +1,1797 @@ 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.name; and the &a.cvsall.name; lists. This is not just a good idea, it is essential. If you are not on the &a.current.name; list, 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.name; list 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, or one of the others available go to &a.mailman.lists.link; and click on the list that you wish to subscribe to. Instructions on the rest of the procedure are available there. Grab the sources from a &os; mirror - site. You can do this in one of three ways: + site. You can do this in one of two ways: cvsup cron -CURRENT Syncing with CVSup Use the cvsup program - with this - supfile. This is the most recommended + with the supfile named standard-supfile + available from /usr/share/examples/cvsup. + 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.name; list. 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.name; list 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, or one of the others available go to &a.mailman.lists.link; and click on the list that you wish to subscribe to. Instructions on the rest of the procedure are available there. 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 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: + be done in one of two ways: cvsup cron -STABLE syncing with CVSup Use the cvsup program - with this - supfile. This is the most recommended + with the supfile named stable-supfile + from the directory + /usr/share/examples/cvsup. + 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 time-zone 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/mirrors/chapter.sgml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml index d3be7defc4..6653e903e1 100644 --- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,4736 +1,4736 @@ 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:
Frys Electronics WWW:
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:
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:
FreeBSD Services Ltd 11 Lapwing Close Bicester OX26 6XR United Kingdom WWW:
Hinner EDV St. Augustinus-Str. 10 D-81825 München Germany Phone: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre France WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 USA Phone: 1 (800) 456-8000 WWW:
JMC Software Ireland Phone: 353 1 6291282 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA United Kingdom Phone: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux System Labs Australia 21 Ray Drive Balwyn North VIC - 3104 Australia Phone: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
UNIXDVD.COM LTD 57 Primrose Avenue Sheffield S5 6FS United Kingdom WWW:
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:
FreeBSD Services Ltd 11 Lapwing Close Bicester OX26 6XR United Kingdom WWW:
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:
FTP Sites The official sources for FreeBSD are available via anonymous FTP from a worldwide set of mirror sites. The site is well connected and allows a large number of connections to it, but you are probably better off finding a closer mirror site (especially if you decide to set up some sort of mirror site). 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. Australia In case of problems, please contact the hostmaster hostmaster@au.FreeBSD.org for this domain. Austria In case of problems, please contact the hostmaster hostmaster@at.FreeBSD.org for this domain. Brazil In case of problems, please contact the hostmaster hostmaster@br.FreeBSD.org for this domain. Bulgaria In case of problems, please contact the hostmaster hostmaster@bg.FreeBSD.org for this domain. Canada In case of problems, please contact the hostmaster hostmaster@ca.FreeBSD.org for this domain. China In case of problems, please contact the hostmaster phj@cn.FreeBSD.org for this domain. Czech Republic In case of problems, please contact the hostmaster hostmaster@cz.FreeBSD.org for this domain. Contact: calda@dzungle.ms.mff.cuni.cz Denmark In case of problems, please contact the hostmaster hostmaster@dk.FreeBSD.org for this domain. Estonia In case of problems, please contact the hostmaster hostmaster@ee.FreeBSD.org for this domain. Finland In case of problems, please contact the hostmaster hostmaster@fi.FreeBSD.org for this domain. France In case of problems, please contact the hostmaster hostmaster@fr.FreeBSD.org for this domain. Germany In case of problems, please contact the mirror admins de-bsd-hubs@de.FreeBSD.org for this domain. Greece In case of problems, please contact the hostmaster hostmaster@gr.FreeBSD.org for this domain. Hong Kong Hungary In case of problems, please contact the hostmaster mohacsi@ik.bme.hu for this domain. Iceland In case of problems, please contact the hostmaster hostmaster@is.FreeBSD.org for this domain. Ireland In case of problems, please contact the hostmaster hostmaster@ie.FreeBSD.org for this domain. Italy In case of problems, please contact the hostmaster hostmaster@it.FreeBSD.org for this domain. Japan In case of problems, please contact the hostmaster hostmaster@jp.FreeBSD.org for this domain. Korea In case of problems, please contact the hostmaster hostmaster@kr.FreeBSD.org for this domain. Lithuania In case of problems, please contact the hostmaster hostmaster@lt.FreeBSD.org for this domain. Netherlands In case of problems, please contact the hostmaster hostmaster@nl.FreeBSD.org for this domain. New Zealand In case of problems, please contact the hostmaster hostmaster@nz.FreeBSD.org for this domain. Norway In case of problems, please contact the hostmaster hostmaster@no.FreeBSD.org for this domain. Poland In case of problems, please contact the hostmaster hostmaster@pl.FreeBSD.org for this domain. Portugal In case of problems, please contact the hostmaster hostmaster@pt.FreeBSD.org for this domain. Romania In case of problems, please contact the hostmaster hostmaster@ro.FreeBSD.org for this domain. Russia In case of problems, please contact the hostmaster hostmaster@ru.FreeBSD.org for this domain. Saudi Arabia In case of problems, please contact ftpadmin@isu.net.sa Singapore In case of problems, please contact the hostmaster hostmaster@sg.FreeBSD.org for this domain. South Africa In case of problems, please contact the hostmaster hostmaster@za.FreeBSD.org for this domain. Slovak Republic In case of problems, please contact the hostmaster hostmaster@sk.FreeBSD.org for this domain. Slovenia In case of problems, please contact the hostmaster hostmaster@si.FreeBSD.org for this domain. Spain In case of problems, please contact the hostmaster hostmaster@es.FreeBSD.org for this domain. Sweden In case of problems, please contact the hostmaster hostmaster@se.FreeBSD.org for this domain. Switzerland In case of problems, please contact the hostmaster hostmaster@ch.FreeBSD.org for this domain. Taiwan In case of problems, please contact the hostmaster hostmaster@tw.FreeBSD.org for this domain. Thailand Contact: ftpadmin@ftp.nectec.or.th. Ukraine Contact: freebsd-mnt@lucky.net. UK In case of problems, please contact the hostmaster hostmaster@uk.FreeBSD.org for this domain. USA In case of problems, please contact the hostmaster hostmaster@FreeBSD.org for this domain. 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.) Austria: :pserver:anoncvs@anoncvs.at.FreeBSD.org:/home/ncvs (Use cvs login and enter any password 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: - + 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: 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: Subscribe to one of the CTM distribution lists. &a.ctm-cvs-cur.name; supports the entire CVS tree. &a.ctm-src-cur.name; supports the head of the development branch. &a.ctm-src-4.name; supports the 4.X release branch, etc.. (If you do not know how to subscribe yourself to a list, click on the list name above or go to &a.mailman.lists.link; and click on the list that you wish to subscribe to. The list page should contain all of the necessary subscription 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 &a.ctm-announce.name; mailing list. In the future, this will be the only place where announcements concerning the operations of the CTM system will be posted. Click on the list name above and follow the instructions to subscribe 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 South Africa, backup server for old deltas Taiwan/R.O.C. 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/. base is defined in your supfile; by default, base is /usr/local/etc/cvsup, which means that by default the refuse file is /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/hungarian ports/japanese ports/korean ports/portuguese ports/russian ports/ukrainian ports/vietnamese doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/it_* doc/ja_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/zh_* and so forth for the other languages (you can find the full list by browsing the FreeBSD - FTP server). + URL="http://www.freebsd.org/cgi/cvsweb.cgi/">FreeBSD + CVS repository). 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@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) cvsup5.nl.FreeBSD.org (maintainer vincent@nlisp.nl) Norway cvsup.no.FreeBSD.org (maintainer Per.Hove@math.ntnu.no) Poland cvsup.pl.FreeBSD.org (maintainer mariusz@provector.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 ejb@leguin.org.uk) cvsup4.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 cvsup18.FreeBSD.org (maintainer cvsup@aphix.com), Wisconsin state CVS Tags When obtaining or updating sources from cvs and CVSup a revision tag (reference to a date in time) must be specified. A revision tag refers to either a particular line of FreeBSD development, or a specific point in time. The first type are called branch tags, the second type are called release tags. Branch Tags All of these, with the exception of HEAD (which is always a valid tag), only apply to the src/ tree. The ports/, doc/, and www/ trees are not branched. Branch Tags 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_1 The release branch for FreeBSD-5.1, used only for security advisories and other seriously critical fixes. 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. Release Tags These tags correspond to the FreeBSD src/ tree (and ports/, doc/, and www/ trees) at a specific point in time, when a particular version of FreeBSD was released. RELENG_5_1_0_RELEASE FreeBSD 5.1 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 &man.rcp.1; 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.