diff --git a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml index 42cb7be96b..1ccdd5b166 100644 --- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml @@ -1,3379 +1,3379 @@ Jim Mock Restructured, reorganized, and parts updated by Jordan Hubbard Original work by Poul-Henning Kamp John Polstra Nik Clayton Updating and Upgrading &os; Synopsis &os; is under constant development between releases. Some people prefer to use the officially released versions, while others prefer to keep in sync with the latest developments. However, even official releases are often updated with security and other critical fixes. Regardless of the version used, &os; provides all necessary tools to keep your system updated, and also allows for easy upgrades between versions. This chapter will help you decide if you want to track the development system, or stick with one of the released versions. The basic tools for keeping your system up to date are also presented. After reading this chapter, you will know: What utilities may be used to update the system and the Ports Collection. How to keep your system up to date with freebsd-update, Subversion, or CTM. How to compare the state of an installed system against a known pristine copy. How to keep your documentation up to date with Subversion or documentation ports. The difference between the two development branches: &os.stable; and &os.current;. How to rebuild and reinstall the entire base system with make buildworld (etc). Before reading this chapter, you should: Properly set up your network connection (). Know how to install additional third-party software (). Throughout this chapter, the svn command is used to obtain and update &os; sources. To use it, you will need to install the port or the package for devel/subversion. Tom Rhodes Written by Colin Percival Based on notes provided by FreeBSD Update Updating and Upgrading freebsd-update updating-upgrading Applying security patches is an important part of maintaining computer software, especially the operating system. For the longest time on &os; this process was not an easy one. Patches had to be applied to the source code, the code rebuilt into binaries, and then the binaries had to be re-installed. This is no longer the case as &os; now includes a utility simply called freebsd-update. This utility provides two separate functions. First, it allows for binary security and errata updates to be applied to the &os; base system without the build and install requirements. Second, the utility supports minor and major release upgrades. Binary updates are available for all architectures and releases currently supported by the security team. Before updating to a new release, the current release announcements should be reviewed as they may contain important information pertinent to the desired release. These announcements may be viewed at the following link: . If a crontab utilizing the features of freebsd-update exists, it must be disabled before the following operation is started. The Configuration File Some users may wish to tweak the default configuration file in /etc/freebsd-update.conf, allowing better control of the process. The options are very well documented, but the following few may require a bit more explanation: # Components of the base system which should be kept updated. Components src world kernel This parameter controls what parts of &os; will be kept up to date. The default is to update the source code, the entire base system, and the kernel. Components are the same as those available during the install, for instance, adding world/games here would allow game patches to be applied. Using src/bin would allow the source code in src/bin to be updated. The best option is to leave this at the default as changing it to include specific items will require the user to list every item they prefer to be updated. This could have disastrous consequences as source code and binaries may become out of sync. # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths Add paths, such as /bin or /sbin to leave these specific directories untouched during the update process. This option may be used to prevent freebsd-update from overwriting local modifications. # Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile Update configuration files in the specified directories only if they have not been modified. Any changes made by the user will invalidate the automatic updating of these files. There is another option, KeepModifiedMetadata, which will instruct freebsd-update to save the changes during the merge. # When upgrading to a new &os; release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ List of directories with configuration files that freebsd-update should attempt merges in. The file merge process is a series of &man.diff.1; patches similar to &man.mergemaster.8; with fewer options, the merges are either accepted, open an editor, or freebsd-update will abort. When in doubt, backup /etc and just accept the merges. See for more information about the mergemaster command. # Directory in which to store downloaded updates and temporary # files used by &os; Update. # WorkDir /var/db/freebsd-update This directory is where all patches and temporary files will be placed. In cases where the user is doing a version upgrade, this location should have a least a gigabyte of disk space available. # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which &os; Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no When set to yes, freebsd-update will assume that the Components list is complete and will not attempt to make changes outside of the list. Effectively, freebsd-update will attempt to update every file which belongs to the Components list. Security Patches Security patches are stored on a remote machine and may be downloaded and installed using the following command: &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install If any kernel patches have been applied the system will need a reboot. If all went well the system should be patched and freebsd-update may be run as a nightly &man.cron.8; job. An entry in /etc/crontab would be sufficient to accomplish this task: @daily root freebsd-update cron This entry states that once every day, the freebsd-update utility will be run. In this way, using the argument, freebsd-update will only check if updates exist. If patches exist, they will automatically be downloaded to the local disk but not applied. The root user will be sent an email so they may install them manually. If anything went wrong, freebsd-update has the ability to roll back the last set of changes with the following command: &prompt.root; freebsd-update rollback Once complete, the system should be restarted if the kernel or any kernel modules were modified. This will allow &os; to load the new binaries into memory. The freebsd-update utility can automatically update the GENERIC kernel only. If a custom kernel is in use, it will have to be rebuilt and reinstalled after freebsd-update finishes installing the rest of the updates. However, freebsd-update will detect and update the GENERIC kernel in /boot/GENERIC (if it exists), even if it is not the current (running) kernel of the system. It is a good idea to always keep a copy of the GENERIC kernel in /boot/GENERIC. It will be helpful in diagnosing a variety of problems, and in performing version upgrades using freebsd-update as described in . Unless the default configuration in /etc/freebsd-update.conf has been changed, freebsd-update will install the updated kernel sources along with the rest of the updates. Rebuilding and reinstalling your new custom kernel can then be performed in the usual way. The updates distributed via freebsd-update, do not always involve the kernel. It will not be necessary to rebuild your custom kernel if the kernel sources have not been modified by the execution of freebsd-update install. However, freebsd-update will always update the /usr/src/sys/conf/newvers.sh file. The current patch level (as indicated by the -p number reported by uname -r) is obtained from this file. Rebuilding your custom kernel, even if nothing else changed, will allow &man.uname.1; to accurately report the current patch level of the system. This is particularly helpful when maintaining multiple systems, as it allows for a quick assessment of the updates installed in each one. Major and Minor Version Upgrades Upgrades from one minor version of &os; to another, like from &os; 9.0 to &os; 9.1, are called minor version upgrades. Generally, installed applications will continue to work without problems after minor version upgrades. Major version upgrades are when &os; is upgraded from one major version to another, like from &os; 8.X to &os; 9.X. Major version upgrades will remove old object files and libraries which will break most third party applications. It is recommended that all installed ports either be removed and re-installed or upgraded after a major version upgrade by using the ports-mgmt/portupgrade utility. A brute-force rebuild of all installed applications can be accomplished with this command: &prompt.root; portupgrade -af This will ensure everything will be re-installed correctly. Note that setting the BATCH environment variable to yes will answer yes to any prompts during this process, removing the need for manual intervention during the build process. Dealing with Custom Kernels If a custom kernel is in use, the upgrade process is slightly more involved, and the procedure varies depending on the version of &os;. Custom Kernels with &os; 8.X and Earlier A copy of the GENERIC kernel is needed, and it should be placed in /boot/GENERIC. If the GENERIC kernel is not already present in the system, it may be obtained using one of the following methods: If a custom kernel has only been built once, the kernel in /boot/kernel.old is actually the GENERIC one. Simply rename this directory to /boot/GENERIC. Assuming physical access to the machine is possible, a copy of the GENERIC kernel can be installed from the CD-ROM media. Insert your installation disc and use the following commands: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC Replace X.Y-RELEASE with the actual version of the release you are using. The GENERIC kernel will be installed in /boot/GENERIC by default. Failing all the above, the GENERIC kernel may be rebuilt and installed from the sources: &prompt.root; cd /usr/src &prompt.root; env DESTDIR=/boot/GENERIC make kernel __MAKE_CONF=/dev/null &prompt.root; mv /boot/GENERIC/boot/kernel/* /boot/GENERIC &prompt.root; rm -rf /boot/GENERIC/boot For this kernel to be picked up as GENERIC by freebsd-update, the GENERIC configuration file must not have been modified in any way. It is also suggested that it is built without any other special options. Rebooting to the GENERIC kernel is not required at this stage. Custom Kernels with &os; 9.X and Later If a custom kernel has only been built once, the kernel in /boot/kernel.old is actually the GENERIC kernel. Rename this directory to /boot/kernel. If physical access to the machine is available, a copy of the GENERIC kernel can be installed from the CD-ROM media. Load the installation disc and use these commands: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/usr/freebsd-dist &prompt.root; tar -C/ -xvf kernel.txz boot/kernel/kernel If the options above cannot be used, the GENERIC kernel may be rebuilt and installed from the sources: &prompt.root; cd /usr/src &prompt.root; make kernel __MAKE_CONF=/dev/null For this kernel to be identified as the GENERIC kernel by freebsd-update, the GENERIC configuration file must not have been modified in any way. It is also suggested that the kernel is built without any other special options. Rebooting to the GENERIC kernel is not required at this stage. Performing the Upgrade Major and minor version upgrades may be performed by providing freebsd-update with a release version target, for example, the following command will update to &os; 8.1: &prompt.root; freebsd-update -r 8.1-RELEASE upgrade After the command has been received, freebsd-update will evaluate the configuration file and current system in an attempt to gather the information necessary to update the system. A screen listing will display what components have been detected and what components have not been detected. For example: Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 8.0-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y At this point, freebsd-update will attempt to download all files required for the upgrade. In some cases, the user may be prompted with questions regarding what to install or how to proceed. When using a custom kernel, the above step will produce a warning similar to the following: WARNING: This system is running a "MYKERNEL" kernel, which is not a kernel configuration distributed as part of FreeBSD 8.0-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" This warning may be safely ignored at this point. The updated GENERIC kernel will be used as an intermediate step in the upgrade process. After all patches have been downloaded to the local system, they will then be applied. This process may take a while depending on the speed and workload of the machine. Configuration files will then be merged — this part of the process requires some user intervention as a file may be merged or an editor may appear on screen for a manual merge. The results of every successful merge will be shown to the user as the process continues. A failed or ignored merge will cause the process to abort. Users may wish to make a backup of /etc and manually merge important files, such as master.passwd or group at a later time. The system is not being altered yet, all patching and merging is happening in another directory. When all patches have been applied successfully, all configuration files have been merged and it seems the process will go smoothly, the changes will need to be committed by the user. Once this process is complete, the upgrade may be committed to disk using the following command. &prompt.root; freebsd-update install The kernel and kernel modules will be patched first. At this point the machine must be rebooted. If the system was running with a custom kernel, use the &man.nextboot.8; command to set the kernel for the next boot to /boot/GENERIC (which was updated): &prompt.root; nextboot -k GENERIC Before rebooting with the GENERIC kernel, make sure it contains all drivers required for your system to boot properly (and connect to the network, if the machine that is being updated is accessed remotely). In particular, if the previously running custom kernel contained built-in functionality usually provided by kernel modules, make sure to temporarily load these modules into the GENERIC kernel using the /boot/loader.conf facility. You may also wish to disable non-essential services, disk and network mounts, etc. until the upgrade process is complete. The machine should now be restarted with the updated kernel: &prompt.root; shutdown -r now Once the system has come back online, freebsd-update will need to be started again. The state of the process has been saved and thus, freebsd-update will not start from the beginning, but will remove all old shared libraries and object files. To continue to this stage, issue the following command: &prompt.root; freebsd-update install Depending on whether any libraries version numbers got bumped, there may only be two install phases instead of three. Rebuilding Ports After a Major Version Upgrade After a major version upgrade, all third party software will now need to be rebuilt and re-installed. This is required as installed software may depend on libraries which have been removed during the upgrade process. The ports-mgmt/portupgrade command may be used to automate this process. The following commands may be used to begin this process: &prompt.root; portupgrade -f ruby &prompt.root; rm /var/db/pkg/pkgdb.db &prompt.root; portupgrade -f ruby18-bdb &prompt.root; rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db &prompt.root; portupgrade -af Once this has completed, finish the upgrade process with a final call to freebsd-update. Issue the following command to tie up all loose ends in the upgrade process: &prompt.root; freebsd-update install If the GENERIC kernel was temporarily used, this is the time to build and install a new custom kernel in the usual way. Reboot the machine into the new &os; version. The process is complete. System State Comparison The freebsd-update utility may be used to test the state of the installed &os; version against a known good copy. This option evaluates the current version of system utilities, libraries, and configuration files. To begin the comparison, issue the following command: &prompt.root; freebsd-update IDS >> outfile.ids While the command name is IDS it should in no way be a replacement for an intrusion detection system such as security/snort. As freebsd-update stores data on disk, the possibility of tampering is evident. While this possibility may be reduced by using the kern.securelevel setting and storing the freebsd-update data on a read only file system when not in use, a better solution would be to compare the system against a secure disk, such as a DVD or securely stored external USB disk device. The system will now be inspected, and a list of files along with their &man.sha256.1; hash values, both the known value in the release and the current installed value, will be printed. This is why the output has been sent to the outfile.ids file. It scrolls by too quickly for eye comparisons, and soon it fills up the console buffer. These lines are also extremely long, but the output format may be parsed quite easily. For instance, to obtain a list of all files different from those in the release, issue the following command: &prompt.root; cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf This output has been truncated, many more files exist. Some of these files have natural modifications, the /etc/passwd has been modified because users have been added to the system. In some cases, there may be other files, such as kernel modules, which differ as freebsd-update may have updated them. To exclude specific files or directories, add them to the IDSIgnorePaths option in /etc/freebsd-update.conf. This system may be used as part of an elaborate upgrade method, aside from the previously discussed version. Tom Rhodes Written by Colin Percival Based on notes provided by Portsnap: a Ports Collection Update Tool Updating and Upgrading Portsnap Updating and Upgrading The base system of &os; includes a utility for updating the Ports Collection too: the &man.portsnap.8; utility. Upon execution, it will connect to a remote site, verify the secure key, and download a new copy of the Ports Collection. The key is used to verify the integrity of all downloaded files, ensuring they have not been modified in-flight. To download the latest Ports Collection files, issue the following command: &prompt.root; portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 9 mirrors found. Fetching snapshot tag from geodns-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Tue May 22 02:12:15 CEST 2012 to Wed May 23 16:28:31 CEST 2012. Fetching 3 metadata patches.. done. Applying metadata patches... done. Fetching 3 metadata files... done. Fetching 90 patches.....10....20....30....40....50....60....70....80....90. done. Applying patches... done. Fetching 133 new ports or files... done. What this example shows is that &man.portsnap.8; has found and verified several patches to the current ports data. This also indicates that the utility was run previously, if it was a first time run, the collection would have simply been downloaded. When &man.portsnap.8; successfully completes a fetch operation, the Ports Collection and subsequent patches exist on the local system that have passed verification. The first time portsnap is executed, you have to use extract to install the downloaded files: &prompt.root; portsnap extract /usr/ports/.cvsignore /usr/ports/CHANGES /usr/ports/COPYRIGHT /usr/ports/GIDs /usr/ports/KNOBS /usr/ports/LEGAL /usr/ports/MOVED /usr/ports/Makefile /usr/ports/Mk/bsd.apache.mk /usr/ports/Mk/bsd.autotools.mk /usr/ports/Mk/bsd.cmake.mk ... To update an already installed Ports Collection use the command portsnap update: &prompt.root; portsnap update The process is now complete, and applications may be installed or upgraded using the updated Ports Collection. The fetch and extract or update operations may be run consecutively, as shown in the following example: &prompt.root; portsnap fetch update This command will download the latest version of the Ports Collection and update your local version under /usr/ports. Updating the Documentation Set Updating and Upgrading Documentation Updating and Upgrading Besides the base system and the Ports Collection, documentation is an integral part of the &os; operating system. While an up-to-date version of the &os; Documentation Set is always available on the &os; web site, some users might have slow or no permanent network connectivity at all. Fortunately, there are several ways to update the documentation shipped with each release by maintaining a local copy of the latest &os; Documentation Set. Using <application>Subversion</application> to Update the Documentation The &os; documentation sources can be obtained with Subversion. This section describes: How to install the documentation toolchain, the tools that are required to rebuild the &os; documentation from its source. How to download a copy of the documentation source at /usr/doc, using Subversion. How to rebuild the &os; documentation from its source, and install it under /usr/share/doc. Some of the build options that are supported by the build system of the documentation, i.e., the options that build only some of the different language translations of the documentation or the options that select a specific output format. Installing <application>Subversion</application> and the Documentation Toolchain Rebuilding the &os; documentation from source requires a fairly large collection of tools. These tools are not part of the &os; base system, because they need a large amount of disk space and they are not useful to all &os; users; they are only useful to those users that are actively writing new documentation for &os; or are frequently updating their documentation from source. All the required tools are available as part of the Ports Collection. The textproc/docproj port is a master port that has been developed by the &os; Documentation Project, to ease the initial installation and future updates of these tools. When no &postscript; or PDF documentation required, one might consider installing the textproc/docproj-nojadetex port instead. This version of the documentation toolchain includes everything except the teTeX typesetting engine. teTeX is a very large collection of tools, so it may be quite sensible to omit its installation if PDF output is not really necessary. Subversion is installed with the textproc/docproj port. Updating the Documentation Sources The Subversion program can fetch a clean copy of the documentation sources from the western US mirror using the HTTPS protocol with this command: &prompt.root; svn checkout https://svn0.us-west.FreeBSD.org/doc/head /usr/doc Please use the closest mirror from the available Subversion mirror sites. The initial download of the documentation sources may take a while. Let it run until it completes. Future updates of the documentation sources may be fetched by running: &prompt.root; svn update /usr/doc After checking out the sources, an alternative way of updating the documentation is supported by the Makefile of the /usr/doc directory by running: &prompt.root; cd /usr/doc &prompt.root; make update Tunable Options of the Documentation Sources The updating and build system of the &os; documentation supports a few options that ease the process of updating only parts of the documentation, or the build of specific translations. These options can be set either as system-wide options in the /etc/make.conf file, or as command-line options passed to the &man.make.1; utility. The following options are some of these: DOC_LANG The list of languages and encodings to build and install, e.g., en_US.ISO8859-1 for the English documentation only. FORMATS A single format or a list of output formats to be built. Currently, html, html-split, txt, ps, pdf, and rtf are supported. DOCDIR Where to install the documentation. It defaults to /usr/share/doc. For more make variables supported as system-wide options in &os;, see &man.make.conf.5;. For more make variables supported by the build system of the &os; documentation, please refer to the &os; Documentation Project Primer for New Contributors. Installing the &os; Documentation from Source When an up-to-date snapshot of the documentation sources has been fetched in /usr/doc, everything is ready for an update of the installed documentation. A full update of all the languages defined in the DOC_LANG makefile option may be done by typing: &prompt.root; cd /usr/doc &prompt.root; make install clean If an update of only a specific language is desired, &man.make.1; can be invoked in a language specific subdirectory of /usr/doc, i.e.: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean The output formats that will be installed may be specified by setting the FORMATS make variable, i.e.: &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Marc Fonvieille Based on the work of Using Documentation Ports Updating and Upgrading documentation package Updating and Upgrading In the previous section, we have presented a method for updating the &os; documentation from sources. Source based updates may not be feasible or practical for all &os; systems though. Building the documentation sources requires a fairly large collection of tools and utilities, the documentation toolchain, a certain level of familiarity with Subversion and source checkouts from a repository, and a few manual steps to build the checked out sources. In this section, we describe an alternative way of updating the installed copies of the &os; documentation; one that uses the Ports Collection and makes it possible to: Download and install pre-built snaphots of the documentation, without having to locally build anything (eliminating this way the need for an installation of the entire documentation toolchain). Download the documentation sources and build them through the ports framework (making the checkout and build steps a bit eaiser). These two methods of updating the &os; documentation are supported by a set of documentation ports, updated by the &a.doceng; on a monthly basis. These are listed in the &os; Ports Collection, under the virtual category named docs. Building and Installing Documentation Ports The documentation ports use the ports building framework to make documentation builds easier. They automate the process of checking out the documentation source, running &man.make.1; with the appropriate environment settings and command-line options, and they make the installation or deinstallation of documentation as easy as the installation of any other &os; port or package. As an extra feature, when the documentation ports are built locally, they record a dependency to the documentation toolchain ports, so the latter is automatically installed too. Organization of the documentation ports is as follows: There is a master port, misc/freebsd-doc-en, where the documentation port files can be found. It is the base of all documentation ports. By default, it builds the English documentation only. There is an all in one port, misc/freebsd-doc-all, and it builds and installs all documentation in all available languages. Finally, there is a slave port for each translation, e.g.: misc/freebsd-doc-hu for the Hungarian-language documents. All of them depend on the master port and install the translated documentation of the respective language. To install a documentation port from source, issue the following commands (as root): &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean This will build and install the English documentation in split HTML format (the same as used on ) in the /usr/local/share/doc/freebsd directory. Common Knobs and Options There are many options for modifying the default behavior of the documentation ports. The following is just a short list: WITH_HTML Allows the build of the HTML format: a single HTML file per document. The formatted documentation is saved to a file called article.html, or book.html, as appropriate, plus images. WITH_PDF Allows the build of the &adobe; Portable Document Format, for use with &adobe; &acrobat.reader;, Ghostscript or other PDF readers. The formatted documentation is saved to a file called article.pdf or book.pdf, as appropriate. DOCBASE Where to install the documentation. It defaults to /usr/local/share/doc/freebsd. Notice that the default target directory differs from the directory used by the Subversion method. This is because we are installing a port, and ports are usually installed under the /usr/local directory. This can be overridden by adding the PREFIX variable. Here is a brief example on how to use the variables mentioned above to install the Hungarian documentation in Portable Document Format: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean Using Documentation Packages Building the documentation ports from source, as described in the previous section, requires a local installation of the documentation toolchain and a bit of disk space for the build of the ports. When resources are not available to install the documentation toolchain, or because the build from sources would take too much disk space, it is still possible to install pre-built snapshots of the documentation ports. The &a.doceng; prepares monthly snapshots of the &os; documentation packages. These binary packages can be used with any of the bundled package tools, like &man.pkg.add.1;, &man.pkg.delete.1;, and so on. When binary packages are used, the &os; documentation will be installed in all available formats for the given language. For example, the following command will install the latest pre-built package of the Hungarian documentation: &prompt.root; pkg_add -r hu-freebsd-doc Packages have the following name format that differs from the corresponding port's name: lang-freebsd-doc. Here lang is the short format of the language code, i.e., hu for Hungarian, or zh_cn for Simplified Chinese. Updating Documentation Ports To update a previously installed documentation port, any tool suitable for updating ports is sufficient. For example, the following command updates the installed Hungarian documentation via the ports-mgmt/portupgrade tool by using packages only: &prompt.root; portupgrade -PP hu-freebsd-doc Pav Lucistnik Based on information provided by Using Docsnap Updating and Upgrading Docsnap Updating and Upgrading Docsnap is an &man.rsync.1; repository for updating installed &os; Documentation in a relatively easy and fast way. A Docsnap server tracks the documentation sources, and builds them in HTML format every hour. The textproc/docproj is unneeded with Docsnap as only patches to the built documentation exist. The only requirement for using this technique is the net/rsync port or package. To add it, use the following command: &prompt.root; pkg_add -r rsync Docsnap has been originally developed for updating documentation installed to /usr/share/doc, but the following examples could be adapted for other directories as well. For user directories, it does not require root privileges. To update the documentation set, issue the following command: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap /usr/share/doc There is only one Docsnap server at the moment; the docsnap.sk.FreeBSD.org shown above. Do not use the flag here as there are some items installed into /usr/share/doc during make installworld, which would accidentally be removed. To clean up, use this command instead: &prompt.root; rsync -rltvz --delete docsnap.sk.FreeBSD.org::docsnap/??_??\.\* /usr/share/doc If a subset of documentation needs to be updated, for example, the English documentation only, the following command should be used: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap/en_US.ISO8859-1 /usr/share/doc ]]> Tracking a Development Branch -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; community who are actively working on some part of the source tree and for whom keeping current is an absolute requirement. Members of the &os; community 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 are 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.svn-src-head.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.svn-src-head.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 interested in tracking changes for the whole source tree, we would recommend subscribing to the &a.svn-src-all.name; list. Grab the sources from a &os; mirror site. You can do this in one of several ways: - svn + Subversion cron -CURRENT Syncing with Subversion -CURRENT Syncing with CTM Use the svn program to check out the desired development or release branch. This is the recommended method, providing access to &os; development as it occurs. Checkout the -CURRENT code from the head branch of one of the Subversion mirror sites. Because of the size of the repository, it is recommended that only desired subtrees be checked out. -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 Subversion for any system with Internet connectivity. 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 install a new kernel and rebuild the world the first time through as part of the upgrading process. Reading the &a.current; and /usr/src/UPDATING 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. Join the relevant SVN list for the branch you are tracking. For example, if you are tracking the 9-STABLE branch, join the &a.svn-src-stable-9.name; list. This will allow you to view 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 interested in tracking changes for the whole source tree, we would recommend subscribing to the &a.svn-src-all.name; list. If you are going to install a new system and want it to run monthly snapshot built from &os.stable;, please check the Snapshots web page for more information. Alternatively, it is possible to install the most recent &os.stable; release from the mirror sites and follow the instructions below to upgrade your system to the most up to date &os.stable; source code. If you are already running a previous release of &os; and wish to upgrade via sources then you can easily do so from a &os; mirror site. This can be done in one of several ways: - svn + Subversion cron -STABLE syncing with Subversion Use the svn program to check out the desired development or release branch. This is the recommended method, providing access to &os; development as it occurs. Branch names include head for the current development head, and branches identified in the release engineering page, such as stable/9 or releng/9.0. URL prefixes for Subversion checkout of the base system are shown in Subversion mirror sites. Because of the size of the repository, it is recommended that only desired subtrees be checked out. -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 Subversion. Otherwise, use CTM. -STABLE compiling Before compiling &os.stable;, read the Makefile in /usr/src carefully. You should at least install a new kernel and rebuild the world the first time through as part of the upgrading process. Reading the &a.stable; and /usr/src/UPDATING 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 Subversion 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. Subversion Subversion uses the pull model of updating sources. The user (or a cron script) invokes the svn program, and it brings files up-to-date. Subversion is the preferred means of updating local source trees. 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. 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 Subversion, 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, Subversion 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 CTM base delta) and rebuild it all with CTM. Rebuilding <quote>world</quote> Rebuilding 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. Make a Backup It cannot be stressed enough how important it is to make 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 or bootable CD at 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. Do Not Use <command>make world</command> A lot of older documentation recommends using make world for this. Doing that skips some important steps and should only be used if you are sure of what you are doing. For almost all circumstances make world is the wrong thing to do, and the procedure described here should be used instead. The Canonical Way to Update Your System To update your system, you should check /usr/src/UPDATING for any pre-buildworld steps necessary for your version of the sources and then use the procedure outlined here. These upgrade steps assume that you are currently using an old &os; version, consisting of an old compiler, old kernel, old world and old configuration files. By world here we mean the core system binaries, libraries and programming files. The compiler is part of world, but has a few special concerns. We also assume that you have already obtained the sources to a newer system. If the sources available on the particular system are old too, see for detailed help about synchronizing them to a newer version. Updating the system from sources is a bit more subtle than it might initially seem to be, and the &os; developers have found it necessary over the years to change the recommended approach fairly dramatically as new kinds of unavoidable dependencies come to light. The rest of this section describes the rationale behind the currently recommended upgrade sequence. Any successful update sequence must deal with the following issues: The old compiler might not be able to compile the new kernel. (Old compilers sometimes have bugs.) So, the new kernel should be built with the new compiler. In particular, the new compiler must be built before the new kernel is built. This does not necessarily mean that the new compiler must be installed before building the new kernel. The new world might rely on new kernel features. So, the new kernel must be installed before the new world is installed. These first two issues are the basis for the core buildworld, buildkernel, installkernel, installworld sequence that we describe in the following paragraphs. This is not an exhaustive list of all the reasons why you should prefer the currently recommended upgrade process. Some of the less obvious ones are listed below: The old world might not run correctly on the new kernel, so you must install the new world immediately upon installing the new kernel. Some configuration changes must be done before the new world is installed, but others might break the old world. Hence, two different configuration upgrade steps are generally needed. For the most part, the update process only replaces or adds files; existing old files are not deleted. In a few cases, this can cause problems. As a result, the update procedure will sometimes specify certain files that should be manually deleted at certain steps. This may or may not be automated in the future. These concerns have led to the following recommended sequence. Note that the detailed sequence for particular updates may require additional steps, but this core process should remain unchanged for some time: make buildworld This first compiles the new compiler and a few related tools, then uses the new compiler to compile the rest of the new world. The result ends up in /usr/obj. make buildkernel Unlike the older approach, using &man.config.8; and &man.make.1;, this uses the new compiler residing in /usr/obj. This protects you against compiler-kernel mismatches. make installkernel Place the new kernel and kernel modules onto the disk, making it possible to boot with the newly updated kernel. Reboot into single user mode. Single user mode minimizes problems from updating software that is already running. It also minimizes any problems from running the old world on a new kernel. mergemaster This does some initial configuration file updates in preparation for the new world. For instance it may add new user groups to the system, or new user names to the password database. This is often necessary when new groups or special system-user accounts have been added since the last update, so that the installworld step will be able to use the newly installed system user or system group names without problems. make installworld Copies the world from /usr/obj. You now have a new kernel and new world on disk. mergemaster Now you can update the remaining configuration files, since you have a new world on disk. Reboot. A full machine reboot is needed now to load the new kernel and new world with new configuration files. Note that if you are upgrading from one release of the same &os; branch to a more recent release of the same branch, i.e., from 7.0 to 7.1, then this procedure may not be absolutely necessary, since you are unlikely to run into serious mismatches between compiler, kernel, userland and configuration files. The older approach of make world followed by building and installing a new kernel might work well enough for minor updates. But, when upgrading across major releases, people who do not follow this procedure should expect some problems. It is also worth noting that many upgrades (i.e., 4.X to 5.0) may require specific additional steps (renaming or deleting specific files prior to installworld, for instance). Read the /usr/src/UPDATING file carefully, especially at the end, where the currently recommended upgrade sequence is explicitly spelled out. This procedure has evolved over time as the developers have found it impossible to completely prevent certain kinds of mismatch problems. Hopefully, the current procedure will remain stable for a long time. To summarize, the currently recommended way of upgrading &os; from sources is: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now There are a few rare cases when an extra run of mergemaster -p is needed before the buildworld step. These are described in UPDATING. In general, though, you can safely omit this step if you are not updating across one or more major &os; versions. After installkernel finishes successfully, you should boot in single user mode (i.e., using boot -s from the loader prompt). Then run: &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; adjkerntz -i &prompt.root; mergemaster -p &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Read Further Explanations The sequence described above is only a short resume to help you getting started. You should however read the following sections to clearly understand each step, especially if you want to use a custom kernel configuration. 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 /usr/share/examples/etc/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 and uncomment the NO_PROFILE line found in /usr/share/examples/etc/make.conf to /etc/make.conf. Examine the other definitions, like NOPORTDOCS, 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 installworld 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. In some cases make buildworld will check to see if these users or groups exist. An 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 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 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, select the single user option. 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 buildworld 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 Base System 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 -DNO_PROFILE target is another way of specifying that profiled libraries should not be built, and corresponds with the NO_PROFILE= 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 Where target will be one of many build options. The first target should always be buildworld. As the names imply, buildworld builds a complete new tree under /usr/obj, and installworld, another target, installs this tree on the current machine. Having separate options is very useful for two 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 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. Timings rebuilding world timings Many factors influence the build time, but fairly recent machines may only take a one or two 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. On &os; it is important to build world before building a new kernel. 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 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. 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 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 -DNO_PROFILE buildworld you must install the results with: &prompt.root; make -DNO_PROFILE 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 installworld</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. 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 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"` 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.shutdown.8; should do it: &prompt.root; shutdown -r now 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 Subversion, 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 is 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;. signal 11 My compile failed with lots of signal 11 (or other signal number) errors. What has happened? 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 buildworld 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 2 GB). However, if you know what you are doing you can have make buildworld 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 buildworld 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 -DNO_CLEAN all This will not undo the work of the previous make buildworld. If you see the message: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- in the make buildworld 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 NO_PROFILE=true in /etc/make.conf). You almost certainly do not need it. 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! Anton Shterenlikht Based on notes provided by Deleting Obsolete Files, Directories and Libraries Deleting obsolete files, directories and libraries As a part of the &os; development lifecycle, it happens from time to time that files and their contents become obsolete. This may be because their functionality is implemented elsewhere, the version number of the library has changed or it was removed from the system entirely. This includes old files, libraries and directories, which should be removed when updating the system. The benefit for the user is that the system is not cluttered with old files which take up unnecessary space on the storage (and backup) medium. Additionally, if the old library had a security or stability issue, you should update to the newer library to keep your system safe and prevent crashes caused by the old library implementation. The files, directories, and libraries that are considered obsolete are listed in /usr/src/ObsoleteFiles.inc. The following instructions will help you removing these obsolete files during the system upgrade process. We assume you are following the steps outlined in . After the make installworld and the subsequent mergemaster commands have finished successfully, you should check for obsolete files and libraries as follows: &prompt.root; cd /usr/src &prompt.root; make check-old If any obsolete files are found, they can be deleted using the following commands: &prompt.root; make delete-old See /usr/src/Makefile for more targets of interest. A prompt is displayed before deleting each obsolete file. You can skip the prompt and let the system remove these files automatically by using the BATCH_DELETE_OLD_FILES make-variable as follows: &prompt.root; make -DBATCH_DELETE_OLD_FILES delete-old You can also achieve the same goal by piping these commands through yes like this: &prompt.root; yes|make delete-old Warning Deleting obsolete files will break applications that still depend on those obsolete files. This is especially true for old libraries. In most cases, you need to recompile the programs, ports, or libraries that used the old library before make delete-old-libs is executed. Utilities for checking shared library dependencies are available from the Ports Collection in sysutils/libchk or sysutils/bsdadminscripts. Obsolete shared libraries can conflict with newer libraries, causing messages like these: /usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5 /usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5 To solve these problems, determine which port installed the library: &prompt.root; pkg_info -W /usr/local/lib/libtiff.so /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 &prompt.root; pkg_info -W /usr/local/lib/libXext.so /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 Then deinstall, rebuild and reinstall the port. The ports-mgmt/portmaster and ports-mgmt/portupgrade utilities can be used to automate this process. After you have made sure that all ports are rebuilt and do not use the old libraries any more, you can delete them using the following command: &prompt.root; make delete-old-libs 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 buildworld and make buildkernel. 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 and /etc/src.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/introduction/chapter.xml b/en_US.ISO8859-1/books/handbook/introduction/chapter.xml index 49d369cb78..916ed30d99 100644 --- a/en_US.ISO8859-1/books/handbook/introduction/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/introduction/chapter.xml @@ -1,1050 +1,1056 @@ Jim Mock Restructured, reorganized, and parts rewritten by Introduction Synopsis Thank you for your interest in &os;! The following chapter covers various aspects of the &os; Project, such as its history, goals, development model, and so on. After reading this chapter, you will know: How &os; relates to other computer operating systems. The history of the &os; Project. The goals of the &os; Project. The basics of the &os; open-source development model. And of course: where the name &os; comes from. Welcome to &os;! 4.4BSD-Lite &os; is a 4.4BSD-Lite based operating system for Intel (x86 and &itanium;), AMD64, Sun &ultrasparc; computers. Ports to other architectures are also underway. You can also read about the history of &os;, or the current release. If you are interested in contributing something to the Project (code, hardware, funding), see the Contributing to &os; article. What Can &os; Do? &os; has many noteworthy features. Some of these are: preemptive multitasking Preemptive multitasking with dynamic priority adjustment to ensure smooth and fair sharing of the computer between applications and users, even under the heaviest of loads. multi-user facilities Multi-user facilities which allow many people to use a &os; system simultaneously for a variety of things. This means, for example, that system peripherals such as printers and tape drives are properly shared between all users on the system or the network and that individual resource limits can be placed on users or groups of users, protecting critical system resources from over-use. TCP/IP networking Strong TCP/IP networking with support for industry standards such as SCTP, DHCP, NFS, NIS, PPP, SLIP, IPsec, and IPv6. This means that your &os; machine can interoperate easily with other systems as well as act as an enterprise server, providing vital functions such as NFS (remote file access) and email services or putting your organization on the Internet with WWW, FTP, routing and firewall (security) services. memory protection Memory protection ensures that applications (or users) cannot interfere with each other. One application crashing will not affect others in any way. &os; is a 32-bit operating system (64-bit on the &itanium;, AMD64, and &ultrasparc;) and was designed as such from the ground up. X Window System The industry standard X Window System (X11R7) provides a graphical user interface (GUI) for the cost of a common VGA card and monitor and comes with full sources. binary compatibility Linux binary compatibility SCO binary compatibility SVR4 binary compatibility BSD/OS binary compatibility NetBSD Binary compatibility with many programs built for Linux, SCO, SVR4, BSDI and NetBSD. Thousands of ready-to-run applications are available from the &os; ports and packages collection. Why search the net when you can find it all right here? Thousands of additional and easy-to-port applications are available on the Internet. &os; is source code compatible with most popular commercial &unix; systems and thus most applications require few, if any, changes to compile. virtual memory Demand paged virtual memory and merged VM/buffer cache design efficiently satisfies applications with large appetites for memory while still maintaining interactive response to other users. Symmetric Multi-Processing (SMP) SMP support for machines with multiple CPUs. compilers C compilers C++ A full complement of C and C++ development tools. Many additional languages for advanced research and development are also available in the ports and packages collection. source code Source code for the entire system means you have the greatest degree of control over your environment. Why be locked into a proprietary solution at the mercy of your vendor when you can have a truly open system? Extensive online documentation. And many more! 4.4BSD-Lite Computer Systems Research Group (CSRG) U.C. Berkeley &os; is based on the 4.4BSD-Lite release from Computer Systems Research Group (CSRG) at the University of California at Berkeley, and carries on the distinguished tradition of BSD systems development. In addition to the fine work provided by CSRG, the &os; Project has put in many thousands of hours in fine tuning the system for maximum performance and reliability in real-life load situations. As many of the commercial giants struggle to field PC operating systems with such features, performance and reliability, &os; can offer them now! The applications to which &os; can be put are truly limited only by your own imagination. From software development to factory automation, inventory control to azimuth correction of remote satellite antennae; if it can be done with a commercial &unix; product then it is more than likely that you can do it with &os; too! &os; also benefits significantly from literally thousands of high quality applications developed by research centers and universities around the world, often available at little to no cost. Commercial applications are also available and appearing in greater numbers every day. Because the source code for &os; itself is generally available, the system can also be customized to an almost unheard of degree for special applications or projects, and in ways not generally possible with operating systems from most major commercial vendors. Here is just a sampling of some of the applications in which people are currently using &os;: Internet Services: The robust TCP/IP networking built into &os; makes it an ideal platform for a variety of Internet services such as: FTP servers FTP servers web servers World Wide Web servers (standard or secure [SSL]) IPv4 and IPv6 routing firewall NAT Firewalls and NAT (IP masquerading) gateways electronic mail email email Electronic Mail servers USENET USENET News or Bulletin Board Systems And more... With &os;, you can easily start out small with an inexpensive 386 class PC and upgrade all the way up to a quad-processor Xeon with RAID storage as your enterprise grows. Education: Are you a student of computer science or a related engineering field? There is no better way of learning about operating systems, computer architecture and networking than the hands on, under the hood experience that &os; can provide. A number of freely available CAD, mathematical and graphic design packages also make it highly useful to those whose primary interest in a computer is to get other work done! Research: With source code for the entire system available, &os; is an excellent platform for research in operating systems as well as other branches of computer science. &os;'s freely available nature also makes it possible for remote groups to collaborate on ideas or shared development without having to worry about special licensing agreements or limitations on what may be discussed in open forums. router DNS Server Networking: Need a new router? A name server (DNS)? A firewall to keep people out of your internal network? &os; can easily turn that unused 386 or 486 PC sitting in the corner into an advanced router with sophisticated packet-filtering capabilities. X Window System X Window System Accelerated-X X Window workstation: &os; is a fine choice for an inexpensive X terminal solution, using the freely available X11 server. Unlike an X terminal, &os; allows many applications to be run locally if desired, thus relieving the burden on a central server. &os; can even boot diskless, making individual workstations even cheaper and easier to administer. GNU Compiler Collection Software Development: The basic &os; system comes with a full complement of development tools including the renowned GNU C/C++ compiler and debugger. &os; is available in both source and binary form on CD-ROM, DVD, and via anonymous FTP. Please see for more information about obtaining &os;. Who Uses &os;? users large sites running &os; &os; is used as a platform for devices and products from many of the world's largest IT companies, including: Apple Apple Cisco Cisco Juniper NetApp NetApp &os; is also used to power some of the biggest sites on the Internet, including: Yahoo! Yahoo! Yandex Yandex Apache Apache Rambler Rambler Sina Sina Pair Networks Pair Networks Sony Japan Sony Japan Netcraft Netcraft NetEase NetEase Weathernews Weathernews TELEHOUSE America TELEHOUSE America Experts Exchange Experts Exchange and many more. About the &os; Project The following section provides some background information on the project, including a brief history, project goals, and the development model of the project. Jordan Hubbard Contributed by A Brief History of &os; 386BSD Patchkit Hubbard, Jordan Williams, Nate Grimes, Rod FreeBSD Project history The &os; Project had its genesis in the early part of 1993, partially as an outgrowth of the Unofficial 386BSD Patchkit by the patchkit's last 3 coordinators: Nate Williams, Rod Grimes and myself. 386BSD Our original goal was to produce an intermediate snapshot of 386BSD in order to fix a number of problems with it that the patchkit mechanism just was not capable of solving. Some of you may remember the early working title for the project being 386BSD 0.5 or 386BSD Interim in reference to that fact. Jolitz, Bill 386BSD was Bill Jolitz's operating system, which had been up to that point suffering rather severely from almost a year's worth of neglect. As the patchkit swelled ever more uncomfortably with each passing day, we were in unanimous agreement that something had to be done and decided to assist Bill by providing this interim cleanup snapshot. Those plans came to a rude halt when Bill Jolitz suddenly decided to withdraw his sanction from the project without any clear indication of what would be done instead. Greenman, David Walnut Creek CDROM It did not take us long to decide that the goal remained worthwhile, even without Bill's support, and so we adopted the name &os;, coined by David Greenman. Our initial objectives were set after consulting with the system's current users and, once it became clear that the project was on the road to perhaps even becoming a reality, I contacted Walnut Creek CDROM with an eye toward improving &os;'s distribution channels for those many unfortunates without easy access to the Internet. Walnut Creek CDROM not only supported the idea of distributing &os; on CD but also went so far as to provide the project with a machine to work on and a fast Internet connection. Without Walnut Creek CDROM's almost unprecedented degree of faith in what was, at the time, a completely unknown project, it is quite unlikely that &os; would have gotten as far, as fast, as it has today. 4.3BSD-Lite Net/2 U.C. Berkeley 386BSD Free Software Foundation The first CD-ROM (and general net-wide) distribution was &os; 1.0, released in December of 1993. This was based on the 4.3BSD-Lite (Net/2) tape from U.C. Berkeley, with many components also provided by 386BSD and the Free Software Foundation. It was a fairly reasonable success for a first offering, and we followed it with the highly successful &os; 1.1 release in May of 1994. Novell U.C. Berkeley Net/2 AT&T Around this time, some rather unexpected storm clouds formed on the horizon as Novell and U.C. Berkeley settled their long-running lawsuit over the legal status of the Berkeley Net/2 tape. A condition of that settlement was U.C. Berkeley's concession that large parts of Net/2 were encumbered code and the property of Novell, who had in turn acquired it from AT&T some time previously. What Berkeley got in return was Novell's blessing that the 4.4BSD-Lite release, when it was finally released, would be declared unencumbered and all existing Net/2 users would be strongly encouraged to switch. This included &os;, and the project was given until the end of July 1994 to stop shipping its own Net/2 based product. Under the terms of that agreement, the project was allowed one last release before the deadline, that release being &os; 1.1.5.1. &os; then set about the arduous task of literally re-inventing itself from a completely new and rather incomplete set of 4.4BSD-Lite bits. The Lite releases were light in part because Berkeley's CSRG had removed large chunks of code required for actually constructing a bootable running system (due to various legal requirements) and the fact that the Intel port of 4.4 was highly incomplete. It took the project until November of 1994 to make this transition, at which point it released &os; 2.0 to the net and on CD-ROM (in late December). Despite being still more than a little rough around the edges, the release was a significant success and was followed by the more robust and easier to install &os; 2.0.5 release in June of 1995. We released &os; 2.1.5 in August of 1996, and it appeared to be popular enough among the ISP and commercial communities that another release along the 2.1-STABLE branch was merited. This was &os; 2.1.7.1, released in February 1997 and capping the end of mainstream development on 2.1-STABLE. Now in maintenance mode, only security enhancements and other critical bug fixes will be done on this branch (RELENG_2_1_0). &os; 2.2 was branched from the development mainline (-CURRENT) in November 1996 as the RELENG_2_2 branch, and the first full release (2.2.1) was released in April 1997. Further releases along the 2.2 branch were done in the summer and fall of '97, the last of which (2.2.8) appeared in November 1998. The first official 3.0 release appeared in October 1998 and spelled the beginning of the end for the 2.2 branch. The tree branched again on Jan 20, 1999, leading to the 4.0-CURRENT and 3.X-STABLE branches. From 3.X-STABLE, 3.1 was released on February 15, 1999, 3.2 on May 15, 1999, 3.3 on September 16, 1999, 3.4 on December 20, 1999, and 3.5 on June 24, 2000, which was followed a few days later by a minor point release update to 3.5.1, to incorporate some last-minute security fixes to Kerberos. This will be the final release in the 3.X branch. There was another branch on March 13, 2000, which saw the emergence of the 4.X-STABLE branch. There have been several releases from it so far: 4.0-RELEASE was introduced in March 2000, and the last 4.11-RELEASE came out in January 2005. The long-awaited 5.0-RELEASE was announced on January 19, 2003. The culmination of nearly three years of work, this release started &os; on the path of advanced multiprocessor and application thread support and introduced support for the &ultrasparc; and ia64 platforms. This release was followed by 5.1 in June of 2003. The last 5.X release from the -CURRENT branch was 5.2.1-RELEASE, introduced in February 2004. The RELENG_5 branch, created in August 2004, was followed by 5.3-RELEASE, which marked the beginning of the 5-STABLE branch releases. The most recent 5.5-RELEASE release came out in May 2006. There will be no additional releases from the RELENG_5 branch. The tree was branched again in July 2005, this time for RELENG_6. 6.0-RELEASE, the first release of the 6.X branch, was released in November 2005. The most recent 6.4-RELEASE came out in November 2008. There will be no additional releases from the RELENG_6 branch. This branch is the last branch to support the Alpha architecture. The RELENG_7 branch was created in October 2007. The first release of this branch was 7.0-RELEASE, which came out in February 2008. The most recent 7.4-RELEASE came out in February 2011. There will be no additional releases from the RELENG_7 branch. The tree was branched again in August 2009, this time for RELENG_8. 8.0-RELEASE, the first release of the 8.X branch, was released in November 2009. The most recent &rel2.current;-RELEASE came out in &rel2.current.date;. There will be additional releases from the RELENG_8 branch. The RELENG_9 branch was created in September 2011. The first release of this branch was 9.0-RELEASE, which came out in January 2012. The most recent &rel.current;-RELEASE came out in &rel.current.date;. There will be additional releases from the RELENG_9 branch. For now, long-term development projects continue to take place in the 10.X-CURRENT (trunk) branch, and SNAPshot releases of 10.X on CD-ROM (and, of course, on the net) are continually made available from the snapshot server as work progresses. Jordan Hubbard Contributed by &os; Project Goals FreeBSD Project goals The goals of the &os; Project are to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we are definitely not prepared to insist on it. We believe that our first and foremost mission is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, I believe, one of the most fundamental goals of Free Software and one that we enthusiastically support. GNU General Public License (GPL) GNU Lesser General Public License (LGPL) BSD Copyright That code in our source tree which falls under the GNU General Public License (GPL) or Library General Public License (LGPL) comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software we do, however, prefer software submitted under the more relaxed BSD copyright when it is a reasonable option to do so. Satoshi Asami Contributed by The &os; Development Model FreeBSD Project development model The development of &os; is a very open and flexible process, being literally built from the contributions of hundreds of people around the world, as can be seen from our list of contributors. &os;'s development infrastructure allow these hundreds of developers to collaborate over the Internet. We are constantly on the lookout for new developers and ideas, and those interested in becoming more closely involved with the project need simply contact us at the &a.hackers;. The &a.announce; is also available to those wishing to make other &os; users aware of major areas of work. Useful things to know about the &os; Project and its development process, whether working independently or in close cooperation: The SVN and CVS repositories CVS - repository + + + + CVS Repository Concurrent Versions System CVS - SVN - repository + Subversion - Subversion - SVN + Subversion Repository + + + + SVN + Subversion For several years, the central source tree for &os; was maintained by CVS (Concurrent Versions System), a freely available source code control tool that comes bundled with &os;. In June 2008, the Project switched to using SVN (Subversion). The switch was deemed necessary, as the technical limitations imposed by CVS were becoming obvious due to the rapid expansion of the source tree and the amount of history already stored. The Documentation Project and Ports Collection repositories also moved from CVS to SVN in May 2012 and July 2012, respectively. While the src/ and ports/ repositories now use SVN, client side tools like csup that depend on the older CVS infrastructure, continue to work normally — changes in the SVN repository are backported to CVS for this purpose. Unlike src/ and ports/, the documentation SVN repository is not backported to CVS. The primary CVS repository resides on a machine in Santa Clara CA, USA from where it is replicated to numerous mirror machines throughout the world. The SVN tree, which contains the -CURRENT and -STABLE trees, can all be easily replicated to your own machine as well. Please refer to the Synchronizing your source tree section for more information on doing this. The committers list committers The committers are the people who have write access to the Subversion tree, and are authorized to make modifications to the &os; source (the term committer comes from the source control commit command, which is used to bring new changes into the repository). The best way of making submissions for review by the committers list is to use the &man.send-pr.1; command. If something appears to be jammed in the system, then you may also reach them by sending mail to the &a.committers;. The FreeBSD core team core team The &os; core team would be equivalent to the board of directors if the &os; Project were a company. The primary task of the core team is to make sure the project, as a whole, is in good shape and is heading in the right directions. Inviting dedicated and responsible developers to join our group of committers is one of the functions of the core team, as is the recruitment of new core team members as others move on. The current core team was elected from a pool of committer candidates in July 2012. Elections are held every 2 years. Some core team members also have specific areas of responsibility, meaning that they are committed to ensuring that some large portion of the system works as advertised. For a complete list of &os; developers and their areas of responsibility, please see the Contributors List Most members of the core team are volunteers when it comes to &os; development and do not benefit from the project financially, so commitment should also not be misconstrued as meaning guaranteed support. The board of directors analogy above is not very accurate, and it may be more suitable to say that these are the people who gave up their lives in favor of &os; against their better judgement! Outside contributors contributors Last, but definitely not least, the largest group of developers are the users themselves who provide feedback and bug fixes to us on an almost constant basis. The primary way of keeping in touch with &os;'s more non-centralized development is to subscribe to the &a.hackers; where such things are discussed. See for more information about the various &os; mailing lists. The &os; Contributors List is a long and growing one, so why not join it by contributing something back to &os; today? Providing code is not the only way of contributing to the project; for a more complete list of things that need doing, please refer to the &os; Project web site. In summary, our development model is organized as a loose set of concentric circles. The centralized model is designed for the convenience of the users of &os;, who are provided with an easy way of tracking one central code base, not to keep potential contributors out! Our desire is to present a stable operating system with a large set of coherent application programs that the users can easily install and use — this model works very well in accomplishing that. All we ask of those who would join us as &os; developers is some of the same dedication its current people have to its continued success! The Current &os; Release NetBSD OpenBSD 386BSD Free Software Foundation U.C. Berkeley Computer Systems Research Group (CSRG) &os; is a freely available, full source 4.4BSD-Lite based release for Intel &i386;, &i486;, &pentium;, &pentium; Pro, &celeron;, &pentium; II, &pentium; III, &pentium; 4 (or compatible), &xeon;, and Sun &ultrasparc; based computer systems. It is based primarily on software from U.C. Berkeley's CSRG group, with some enhancements from NetBSD, OpenBSD, 386BSD, and the Free Software Foundation. Since our release of &os; 2.0 in late 1994, the performance, feature set, and stability of &os; has improved dramatically. The largest change is a revamped virtual memory system with a merged VM/file buffer cache that not only increases performance, but also reduces &os;'s memory footprint, making a 5 MB configuration a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial-on-demand PPP, integrated DHCP support, an improved SCSI subsystem, ISDN support, support for ATM, FDDI, Fast and Gigabit Ethernet (1000 Mbit) adapters, improved support for the latest Adaptec controllers, and many thousands of bug fixes. In addition to the base distributions, &os; offers a ported software collection with thousands of commonly sought-after programs. At the time of this printing, there were over &os.numports; ports! The list of ports ranges from http (WWW) servers, to games, languages, editors, and almost everything in between. The entire Ports Collection requires approximately &ports.size; of storage, all ports being expressed as deltas to their original sources. This makes it much easier for us to update ports, and greatly reduces the disk space demands made by the older 1.0 Ports Collection. To compile a port, you simply change to the directory of the program you wish to install, type make install, and let the system do the rest. The full original distribution for each port you build is retrieved dynamically off the CD-ROM or a local FTP site, so you need only enough disk space to build the ports you want. Almost every port is also provided as a pre-compiled package, which can be installed with a simple command (pkg_add) by those who do not wish to compile their own ports from source. More information on packages and ports can be found in . All recent &os; versions provide an option in the installer (either &man.sysinstall.8; or &man.bsdinstall.8;) to install additional documentation under /usr/local/share/doc/freebsd during the initial system setup. Documentation may also be installed at any later time using packages as described in . You may view the locally installed manuals with any HTML capable browser using the following URLs: The FreeBSD Handbook /usr/local/share/doc/freebsd/handbook/index.html The FreeBSD FAQ /usr/local/share/doc/freebsd/faq/index.html You can also view the master (and most frequently updated) copies at . diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml index b6ec4f26e3..7f6f649d37 100644 --- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml @@ -1,3324 +1,3329 @@ Obtaining &os; CDROM and DVD Publishers Retail Boxed Products &os; is available as a boxed product (&os; CDs, additional software, and printed documentation) from several retailers:
Frys Electronics WWW:
CD and DVD Sets &os; CD and DVD sets are available from many online retailers:
&os; Mall, Inc. 2420 Sand Creek Rd C-1 #347 Brentwood, CA 94513 USA Phone: +1 925 240-6652 Fax: +1 925 674-0821 Email: info@freebsdmall.com WWW:
Dr. Hinner EDV Kochelseestr. 11 D-81371 München Germany Phone: (0177) 428 419 0 WWW:
Linux Distro UK 42 Wharfedale Road Margate CT9 2TB United Kingdom WWW:
The Linux Emporium The Techno Centre, Puma Way Parkside CV1 2TT United Kingdom Phone: +44 (0)247 615 8121 Fax: +44 1491 837016 WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Russia Phone: +7-812-3125208 Email: info@linuxcenter.ru WWW:
FTP Sites The official sources for &os; 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). Additionally, &os; is available via anonymous FTP from the following mirror sites. If you choose to obtain &os; via anonymous FTP, please try to use a site near you. The mirror sites listed as Primary Mirror Sites typically have the entire &os; archive (all the currently available versions for each of the architectures) but you will probably have faster download times from a site that is in your country or region. The regional sites carry the most recent versions for the most popular architecture(s) but might not carry the entire &os; archive. All sites provide access via anonymous FTP but some sites also provide access via other methods. The access methods available for each site are provided in parentheses after the hostname. &chap.mirrors.ftp.inc; BitTorrent BitTorrent The ISO images for the basic release CDs are available via BitTorrent. A collection of torrent files to download the images is available at http://torrents.freebsd.org:8080 The BitTorrent client software is available from the net-p2p/py-bittorrent port, or a precompiled package. After downloading the ISO image with BitTorrent, you may burn it to CD or DVD media as described in , burncd. Anonymous CVS (Deprecated) Warning CVS has been deprecated by the project, and its use is not recommended. Subversion should be used instead. Using CTM CTM CTM is a method for keeping a remote directory tree in sync with a central one. It has been developed for usage with &os;'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 contact the &a.ctm-users.name; mailing list for more information and if you wish to use CTM for other things. Why Should I Use <application>CTM</application>? CTM will give you a local copy of the &os; 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 &os;, 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 &os;. 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 &os; ever since version 2.0 was released, and lives in /usr/src/usr.sbin/ctm if you have a copy of the source available. 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-7.name; supports the 7.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/&os; 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 the &a.ctm-users.name; mailing list. 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 <application>Subversion</application> + + Subversion + + Introduction As of July 2012, &os; uses Subversion (svn) as the primary version control system for storing all of &os;'s source code, documentation, and the Ports Collection. Subversion is generally a developer tool. Most users should use FreeBSD Update to update the &os; base system, and Portsnap to update the &os; Ports Collection. In Subversion, URLs are used to designate a repository, taking the form of protocol://hostname/path. Mirrors may support different protocols as specified below. The first component of the path is the &os; repository to access. There are three different repositories, base for the &os; base system source code, ports for the Ports Collection, and doc for documentation. For example, the URL svn://svn0.us-east.FreeBSD.org/ports/head/ specifies the main branch of the ports repository on the svn0.us-east.FreeBSD.org mirror, using the svn protocol. Installation Subversion must be installed before it can be used to check out the contents of any of the repositories. If a copy of the ports tree is already present, one can install Subversion like this: &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make install clean If the ports tree is not available, Subversion can be installed as a package: &prompt.root; pkg_add -r subversion If pkgng is being used to manage packages, Subversion can be installed with it instead: &prompt.root; pkg install devel/subversion Running <application>Subversion</application> The svn command is used to fetch a clean copy of the sources into a local directory. The files in this directory are called a local working copy. If the local directory already exists but was not created by svn, rename or delete it before the checkout. Checkout over an existing non-svn directory can cause conflicts between the existing files and those brought in from the repository. A checkout from a given repository is performed with a command like this: &prompt.root; svn checkout svn-mirror/repository/branch lwcdir where: svn-mirror is a URL for one of the Subversion mirror sites. repository is one of the Project repositories, i.e., base, ports, or doc. branch depends on the repository used. ports and doc are mostly updated in the head branch, while base maintains the latest version of -CURRENT under head and the respective latest versions of the -STABLE branches under stable/8 (for 8.x) and stable/9 (9.x). lwcdir is the target directory where the contents of the specified branch should be placed. This is usually /usr/ports for ports, /usr/src for base, and /usr/doc for doc. This example checks out the Ports Collection from the western US repository using the HTTPS protocol, placing the local working copy in /usr/ports. If /usr/ports is already present but was not created by svn, remember to rename or delete it before the checkout. &prompt.root; svn checkout https://svn0.us-west.FreeBSD.org/head/ports /usr/ports Because the initial checkout has to download the full branch of the remote repository, it can take a while. Please be patient. After the initial checkout, the local working copy can be updated by running: &prompt.root; svn update lwcdir To update /usr/ports created in the example above, use: &prompt.root; svn update /usr/ports The update is much quicker than a checkout, only transferring files that have changed. An alternate way of updating the local working copy after checkout is provided by the Makefile in the /usr/ports, /usr/src, and /usr/doc directories. Set SVN_UPDATE and use the update target. For example, to update /usr/src: &prompt.root; cd /usr/src &prompt.root; make update SVN_UPDATE=yes For More Information For other information about using Subversion, please see the Subversion Book, titled Version Control with Subversion, or the Subversion Documentation. <application>Subversion</application> Sites - svn + Subversion Repository + Mirror Sites All mirrors carry all repositories. The master &os; Subversion server, svn.FreeBSD.org, is publicly accessible, read-only. That may change in the future, so users are encouraged to use one of the official mirrors. To view the &os; Subversion repositories through a browser, use http://svnweb.FreeBSD.org/. The &os; svn mirror network is still in its early days, and will likely change. Do not count on this list of mirrors being static. In particular, the SSL certificates of the servers will likely change at some point. Name Protocols Location SSL fingerprint svn0.us-west.FreeBSD.org svn, http, https USA, California SHA1 79:35:8F:CA:6D:34:D9:30:44:D1:00:AF:33:4D:E6:11:44:4D:15:EC svn0.us-east.FreeBSD.org svn, http, https USA, New Jersey SHA1 06:D1:23:DE:5E:7A:F7:2B:7A:7E:74:95:5F:54:8D:5C:B0:D6:2E:8F Using CVSup (Deprecated) Introduction cvsup has been deprecated by the project, and its use is not recommended. Subversion should be used instead. CVSup is a software package for distributing and updating source trees from a master CVS repository on a remote server host. The &os; sources are maintained in a CVS repository on a central development machine in California. With CVSup, &os; 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 &os; mirror sites. As you read the &os; 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 &os; project, because CVSup is both faster and more flexible. The csup utility is a rewrite of the CVSup software in C. Its biggest advantage is, that it is faster and does not depend on the Modula-3 language, thus you do not need to install it as a requirement. Moreover you can use it out-of-the-box, since it is included in the base system. If you decided to use csup, just skip the steps on the installation of CVSup and substitute the references of CVSup with csup while following the remainder of this article. Installation The easiest way to install CVSup is to use the precompiled net/cvsup package from the &os; 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 &xorg; installed, such as a server, be sure to use the port which does not include the CVSup GUI, net/cvsup-without-gui. 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 &os;-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 &os; 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_8 will become tag=RELENG_8). 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 &os;-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 &os; distribution site, cvsup99.FreeBSD.org: *default host=cvsup99.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, /var/db: *default base=/var/db 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 &os; 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=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *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; our defined base is /var/db, which means that by default the refuse file is /var/db/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 read the German translation of documentation, you can put the following in your refuse file: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/hu_* doc/it_* doc/ja_* doc/mn_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* and so forth for the other languages (you can find the full list by browsing the &os; 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 &os; CVS repository, including the cryptography code. distrib release=cvs Files related to the distribution and mirroring of &os;. ports-all release=cvs The &os; 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. If you are going to be building your own local copy of ports/INDEX, you must accept ports-all (the whole ports tree). Building ports/INDEX with a partial tree is not supported. See the FAQ. ports-accessibility release=cvs Software to help disabled users. ports-arabic release=cvs Arabic language support. 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 &os; 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-dns release=cvs DNS related software. 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-hebrew release=cvs Hebrew language support. 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-misc release=cvs Miscellaneous utilities. ports-multimedia release=cvs Multimedia software. ports-net release=cvs Networking software. ports-net-im release=cvs Instant messaging software. ports-net-mgmt release=cvs Network management software. ports-net-p2p release=cvs Peer to peer networking. ports-news release=cvs USENET news software. ports-palm release=cvs Software support for Palm series. ports-polish release=cvs Polish language support. ports-ports-mgmt release=cvs Utilities to manage ports and packages. ports-portuguese release=cvs Portuguese language support. ports-print release=cvs Printing software. ports-russian release=cvs Russian language support. ports-science release=cvs Science. 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-ukrainian release=cvs Ukrainian language support. 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-drivers release=cvs X11 drivers. 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 release=cvs X11 servers. ports-x11-themes release=cvs X11 themes. ports-x11-wm release=cvs X11 window managers. projects-all release=cvs Sources for the &os; projects repository. src-all release=cvs The main &os; 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-cddl release=cvs Utilities and libraries covered by the CDDL license (/usr/src/cddl). src-contrib release=cvs Utilities and libraries from outside the &os; project, used relatively unmodified (/usr/src/contrib). src-crypto release=cvs Cryptography utilities and libraries from outside the &os; project, used relatively unmodified (/usr/src/crypto). src-eBones release=cvs Kerberos and DES (/usr/src/eBones). Not used in current releases of &os;. 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 &os; release (/usr/src/release). src-rescue release=cvs Statically linked programs for emergency recovery; see &man.rescue.8; (/usr/src/rescue). 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 &os; (/usr/src/tools). src-usrbin release=cvs User utilities (/usr/src/usr.bin). src-usrsbin release=cvs System utilities (/usr/src/usr.sbin). 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 &os; mailing list archive. www release=current The pre-processed &os; 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 &os;-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;. For questions or bug reports about CVSup take a look at the CVSup FAQ. CVSup Sites CVSup servers for &os; are running at the following sites: &chap.mirrors.cvsup.inc; CVS Tags CVS has been deprecated by the project, and its use is not recommended. Subversion should be used instead. When obtaining or updating sources using cvs or CVSup, a revision tag must be specified. A revision tag refers to either a particular line of &os; development, or a specific point in time. The first type are called branch tags, and 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. HEAD Symbolic name for the main line, or &os;-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_9 The line of development for &os;-9.X, also known as &os; 9-STABLE RELENG_9_0 The release branch for &os;-9.0, used only for security advisories and other critical fixes. RELENG_8 The line of development for &os;-8.X, also known as &os; 8-STABLE RELENG_8_3 The release branch for &os;-8.3, used only for security advisories and other critical fixes. RELENG_8_2 The release branch for &os;-8.2, used only for security advisories and other critical fixes. RELENG_8_1 The release branch for &os;-8.1, used only for security advisories and other critical fixes. RELENG_8_0 The release branch for &os;-8.0, used only for security advisories and other critical fixes. RELENG_7 The line of development for &os;-7.X, also known as &os; 7-STABLE RELENG_7_4 The release branch for &os;-7.4, used only for security advisories and other critical fixes. RELENG_7_3 The release branch for &os;-7.3, used only for security advisories and other critical fixes. RELENG_7_2 The release branch for &os;-7.2, used only for security advisories and other critical fixes. RELENG_7_1 The release branch for &os;-7.1, used only for security advisories and other critical fixes. RELENG_7_0 The release branch for &os;-7.0, used only for security advisories and other critical fixes. RELENG_6 The line of development for &os;-6.X, also known as &os; 6-STABLE RELENG_6_4 The release branch for &os;-6.4, used only for security advisories and other critical fixes. RELENG_6_3 The release branch for &os;-6.3, used only for security advisories and other critical fixes. RELENG_6_2 The release branch for &os;-6.2, used only for security advisories and other critical fixes. RELENG_6_1 The release branch for &os;-6.1, used only for security advisories and other critical fixes. RELENG_6_0 The release branch for &os;-6.0, used only for security advisories and other critical fixes. RELENG_5 The line of development for &os;-5.X, also known as &os; 5-STABLE. RELENG_5_5 The release branch for &os;-5.5, used only for security advisories and other critical fixes. RELENG_5_4 The release branch for &os;-5.4, used only for security advisories and other critical fixes. RELENG_5_3 The release branch for &os;-5.3, used only for security advisories and other critical fixes. RELENG_5_2 The release branch for &os;-5.2 and &os;-5.2.1, used only for security advisories and other critical fixes. RELENG_5_1 The release branch for &os;-5.1, used only for security advisories and other critical fixes. RELENG_5_0 The release branch for &os;-5.0, used only for security advisories and other critical fixes. RELENG_4 The line of development for &os;-4.X, also known as &os; 4-STABLE. RELENG_4_11 The release branch for &os;-4.11, used only for security advisories and other critical fixes. RELENG_4_10 The release branch for &os;-4.10, used only for security advisories and other critical fixes. RELENG_4_9 The release branch for &os;-4.9, used only for security advisories and other critical fixes. RELENG_4_8 The release branch for &os;-4.8, used only for security advisories and other critical fixes. RELENG_4_7 The release branch for &os;-4.7, used only for security advisories and other critical fixes. RELENG_4_6 The release branch for &os;-4.6 and &os;-4.6.2, used only for security advisories and other critical fixes. RELENG_4_5 The release branch for &os;-4.5, used only for security advisories and other critical fixes. RELENG_4_4 The release branch for &os;-4.4, used only for security advisories and other critical fixes. RELENG_4_3 The release branch for &os;-4.3, used only for security advisories and other critical fixes. RELENG_3 The line of development for &os;-3.X, also known as 3.X-STABLE. RELENG_2_2 The line of development for &os;-2.2.X, also known as 2.2-STABLE. This branch is mostly obsolete. Release Tags These tags refer to a specific point in time when a particular version of &os; was released. The release engineering process is documented in more detail by the Release Engineering Information and Release Process documents. The src tree uses tag names that start with RELENG_ tags. The ports and doc trees use tags whose names begin with RELEASE tags. Finally, the www tree is not tagged with any special name for releases. RELENG_9_0_0_RELEASE &os; 9.0 RELENG_8_3_0_RELEASE &os; 8.3 RELENG_8_2_0_RELEASE &os; 8.2 RELENG_8_1_0_RELEASE &os; 8.1 RELENG_8_0_0_RELEASE &os; 8.0 RELENG_7_4_0_RELEASE &os; 7.4 RELENG_7_3_0_RELEASE &os; 7.3 RELENG_7_2_0_RELEASE &os; 7.2 RELENG_7_1_0_RELEASE &os; 7.1 RELENG_7_0_0_RELEASE &os; 7.0 RELENG_6_4_0_RELEASE &os; 6.4 RELENG_6_3_0_RELEASE &os; 6.3 RELENG_6_2_0_RELEASE &os; 6.2 RELENG_6_1_0_RELEASE &os; 6.1 RELENG_6_0_0_RELEASE &os; 6.0 RELENG_5_5_0_RELEASE &os; 5.5 RELENG_5_4_0_RELEASE &os; 5.4 RELENG_4_11_0_RELEASE &os; 4.11 RELENG_5_3_0_RELEASE &os; 5.3 RELENG_4_10_0_RELEASE &os; 4.10 RELENG_5_2_1_RELEASE &os; 5.2.1 RELENG_5_2_0_RELEASE &os; 5.2 RELENG_4_9_0_RELEASE &os; 4.9 RELENG_5_1_0_RELEASE &os; 5.1 RELENG_4_8_0_RELEASE &os; 4.8 RELENG_5_0_0_RELEASE &os; 5.0 RELENG_4_7_0_RELEASE &os; 4.7 RELENG_4_6_2_RELEASE &os; 4.6.2 RELENG_4_6_1_RELEASE &os; 4.6.1 RELENG_4_6_0_RELEASE &os; 4.6 RELENG_4_5_0_RELEASE &os; 4.5 RELENG_4_4_0_RELEASE &os; 4.4 RELENG_4_3_0_RELEASE &os; 4.3 RELENG_4_2_0_RELEASE &os; 4.2 RELENG_4_1_1_RELEASE &os; 4.1.1 RELENG_4_1_0_RELEASE &os; 4.1 RELENG_4_0_0_RELEASE &os; 4.0 RELENG_3_5_0_RELEASE &os;-3.5 RELENG_3_4_0_RELEASE &os;-3.4 RELENG_3_3_0_RELEASE &os;-3.3 RELENG_3_2_0_RELEASE &os;-3.2 RELENG_3_1_0_RELEASE &os;-3.1 RELENG_3_0_0_RELEASE &os;-3.0 RELENG_2_2_8_RELEASE &os;-2.2.8 RELENG_2_2_7_RELEASE &os;-2.2.7 RELENG_2_2_6_RELEASE &os;-2.2.6 RELENG_2_2_5_RELEASE &os;-2.2.5 RELENG_2_2_2_RELEASE &os;-2.2.2 RELENG_2_2_1_RELEASE &os;-2.2.1 RELENG_2_2_0_RELEASE &os;-2.2.0 <application>rsync</application> Sites The following sites make &os; 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 &os; FTP server, or the CVS repository. The rsync suite is available for many operating systems, on &os;, see the net/rsync port or use the package. Czech Republic rsync://ftp.cz.FreeBSD.org/ Available collections: ftp: A partial mirror of the &os; FTP server. &os;: A full mirror of the &os; FTP server. Netherlands rsync://ftp.nl.FreeBSD.org/ Available collections: &os;: A full mirror of the &os; FTP server. Russia rsync://ftp.mtu.ru/ Available collections: &os;: A full mirror of the &os; FTP server. &os;-gnats: The GNATS bug-tracking database. &os;-Archive: The mirror of &os; Archive FTP server. Sweden rsync://ftp4.se.freebsd.org/ Available collections: &os;: A full mirror of the &os; FTP server. Taiwan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Available collections: &os;: A full mirror of the &os; FTP server. United Kingdom rsync://rsync.mirrorservice.org/ Available collections: ftp.freebsd.org: A full mirror of the &os; FTP server. United States of America rsync://ftp-master.FreeBSD.org/ This server may only be used by &os; primary mirror sites. Available collections: &os;: The master archive of the &os; FTP server. acl: The &os; master ACL list. rsync://ftp13.FreeBSD.org/ Available collections: &os;: A full mirror of the &os; FTP server.