Index: head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml (revision 47745) +++ head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml (revision 47746) @@ -1,914 +1,914 @@ Obtaining &os; <acronym>CD</acronym> and <acronym>DVD</acronym> Sets &os; CD and DVD sets are available from several 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: http://www.freebsdmall.com/
Getlinux 78 Rue de la Croix Rochopt Épinay-sous-Sénart 91860 France Email: contact@getlinux.fr WWW: http://www.getlinux.fr/
Dr. Hinner EDV Kochelseestr. 11 D-81371 München Germany Phone: (0177) 428 419 0 Email: infow@hinner.de WWW: http://www.hinner.de/linux/freebsd.html
Linux Center Galernaya Street, 55 Saint-Petersburg 190000 Russia Phone: +7-812-309-06-86 Email: info@linuxcenter.ru WWW: http://linuxcenter.ru/shop/freebsd
<acronym>FTP</acronym> Sites The official sources for &os; are available via anonymous FTP from a worldwide set of mirror sites. The site ftp://ftp.FreeBSD.org/pub/FreeBSD/ is available via HTTP and FTP. It is made up of many machines operated by the project cluster administrators and behind GeoDNS to direct users to the closest available mirror. Additionally, &os; is available via anonymous FTP from the following mirror sites. When obtaining &os; via anonymous FTP, please try to use a nearby site. 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 faster download speeds are probably available 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.index.inc; &chap.mirrors.lastmod.inc; &chap.mirrors.ftp.inc; Using CTM CTM CTM is a method for keeping a remote directory tree in sync with a central one. It is built into &os; and can be used to synchronize a system with &os;'s source repositories. It supports synchronization of an entire repository or just a specified set of branches. CTM is specifically designed for use on lousy or non-existent TCP/IP connections and provides the ability for changes to be automatically sent by email. It requires the user to obtain up to three deltas per day for the most active branches. Update sizes are always kept as small as - possible and are typically less than 5K. About one in very ten + possible and are typically less than 5K. About one in every ten updates is 10-50K in size, and there will occasionally be an update larger than 100K+. When using CTM to track &os; development, refer to the caveats related to working directly from the development sources rather than a pre-packaged release. These are discussed in Tracking a Development Branch. Little documentation exists on the process of creating deltas or using CTM for other purposes. Contact the &a.ctm-users.name; mailing list for answers to questions on using CTM. Getting Deltas The deltas used by CTM can be obtained either through anonymous FTP or email. FTP deltas can be obtained from the following mirror sites. When using anonymous FTP to obtain CTM deltas, select a mirror that is geographically nearby. In case of problems, contact the &a.ctm-users.name; mailing list. Global mirror ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CTM/ South Africa, backup server for old deltas ftp://ftp.za.FreeBSD.org/pub/FreeBSD/CTM/ Taiwan/R.O.C. ftp://ctm.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ ftp://ctm2.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ ftp://ctm3.tw.FreeBSD.org/pub/FreeBSD/development/CTM/ To instead receive deltas through email, subscribe to one of the ctm-src distribution lists available from http://lists.freebsd.org/mailman/listinfo. For example, &a.ctm-src-cur.name; supports the head development branch and &a.ctm-src-9.name; supports the 9.X release branch. As CTM updates arrive through email, use ctm_rmail to unpack and apply them. This command can be run directly from an entry in /etc/aliases in order to automate this process. Refer to &man.ctm.rmail.1; for more details. Regardless of the method which is used to get deltas, CTM users should subscribe to the &a.ctm-announce.name; mailing list as this is the only mechanism by which CTM announcements are posted. <application>CTM</application> Usage Before CTM deltas can be used for the first time, a starting point must be produced. One method is to apply a starter delta to an empty directory. A starter delta can be recognized by the XEmpty in its name, such as src-cur.3210XEmpty.gz. The designation following the X corresponds to the origin of the initial seed, where Empty is an empty directory. As a rule, a base transition from Empty is produced every 100 deltas. Be aware that starter deltas are large and 70 to 80 Megabytes of gzip'd data is common for the XEmpty deltas. Another method is to copy or extract an initial source from a RELEASE media as this can save a significant transfer of data from the Internet. Once a base delta has been created, apply all deltas with higher numbers. To apply the deltas: &prompt.root; cd /directory/to/store/the/stuff &prompt.root; ctm -v -v /directory/which/stores/the/deltas/src-xxx.* Multiple deltas can be applied with a single command as they will be processed one at a time and any deltas that are already applied will be ignored. CTM understands gzip compressed deltas, which saves disk space. To verify a delta without applying it, include in the command line. CTM will not actually modify the local tree but will instead verify the integrity of the delta to see if it would apply cleanly. Refer to &man.ctm.1; for more information about available options and an overview of the process CTM uses when applying deltas. To keep the local source tree up-to-date, every time a new delta becomes available, apply it through CTM. Once applied, it is recommended to not delete the deltas if it is a burden to download them again. This way, a local copy is available in case it is needed for future disaster recovery. Keeping Local Changes Developers often experiment with and change files in their local source tree. CTM supports local modifications in a limited way: before checking for the presence of a file, it first looks for a file with the same name and a .ctm extension. If this file exists, CTM will operate on it instead of the original filename. This behavior provides a simple way to maintain local changes. Before modifying a file, make a copy with a .ctm suffix. Make any changes to the original filename, knowing that CTM will only apply updates to the file with the .ctm suffix. Other <application>CTM</application> Options Finding Out Exactly What Would Be Touched by an Update To determine the list of changes that CTM will make to the local source repository, use . This option is useful for creating logs of the changes or when performing pre- or post-processing on any of the modified files. Making Backups Before Updating To backup all of the files that would be changed by a CTM update, specify . This option tells CTM to backup all files touched by the applied CTM delta to backup-file. Restricting the Files Touched by an Update To restrict the scope of a given CTM update, or to extract just a few files from a sequence of deltas, filtering regular expressions can be specified using , which specifies which files to process, or , which specifies which files to ignore. For example, to extract an up-to-date copy of lib/libc/Makefile from a collection of saved CTM deltas: &prompt.root; cd /directory/to/extract/to/ &prompt.root; ctm -e '^lib/libc/Makefile' /directory/which/stores/the/deltas/src-xxx.* For every file specified in a CTM delta, and are applied in the order given on the command line. A file is processed by CTM only if it is marked as eligible after all and options are applied. Using <application>Subversion</application> Subversion Introduction As of July 2012, &os; uses Subversion as the only version control system for storing all of &os;'s source code, documentation, and the Ports Collection. Subversion is generally a developer tool. Users may prefer to use freebsd-update () to update the &os; base system, and portsnap () to update the &os; Ports Collection. This section demonstrates how to install Subversion on a &os; system and use it to create a local copy of a &os; repository. Additional information on the use of Subversion is included. Root <acronym>SSL</acronym> Certificates Installing security/ca_root_nss allows Subversion to verify the identity of HTTPS repository servers. The root SSL certificates can be installed from a port: &prompt.root; cd /usr/ports/security/ca_root_nss &prompt.root; make install clean or as a package: &prompt.root; pkg install ca_root_nss <application>Svnlite</application> A lightweight version of Subversion is already installed on &os; as svnlite. The port or package version of Subversion is only needed if the Python or Perl API is needed, or if a later version of Subversion is desired. The only difference from normal Subversion use is that the command name is svnlite. Installation If svnlite is unavailable or the full version of Subversion is needed, then it must be installed. Subversion can be installed from the Ports Collection: &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make install clean Subversion can also be installed as a package: &prompt.root; pkg install subversion Running <application>Subversion</application> To fetch a clean copy of the sources into a local directory, use svn. The files in this directory are called a local working copy. Move or delete an existing destination directory before using checkout for the first time. Checkout over an existing non-svn directory can cause conflicts between the existing files and those brought in from the repository. Subversion uses URLs to designate a repository, taking the form of protocol://hostname/path. 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 https://svn.FreeBSD.org/ports/head/ specifies the main branch of the ports repository, using the https protocol. A checkout from a given repository is performed with a command like this: &prompt.root; svn checkout https://svn.FreeBSD.org/repository/branch lwcdir where: repository is one of the Project repositories: 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/9 (9.x) and stable/10 (10.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 &os; 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://svn.FreeBSD.org/ports/head /usr/ports Because the initial checkout must 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 <application>Subversion</application> Mirror Sites Subversion Repository Mirror Sites The &os; Subversion repository is: svn.FreeBSD.org This is a publicly accessible mirror network that uses GeoDNS to select an appropriate back end server. To view the &os; Subversion repositories through a browser, use https://svnweb.FreeBSD.org/. The &os; Subversion mirrors previously used self-signed SSL certificates documented in this chapter. As of July 14, 2015, all mirrors now use an official SSL certificate that will be recognized by Subversion if the security/ca_root_nss port is installed. The legacy self-signed certificates and server names are still available but are deprecated and no longer supported. For those without the security/ca_root_nss port installed, the SHA1 and SHA256 fingerprints are: Hash Fingerprint SHA1 E9:37:73:80:B5:32:1B:93:92:94:98:17:59:F0:FA:A2:5F:1E:DE:B9 SHA256 D5:27:1C:B6:55:E6:A8:7D:48:D5:0C:F0:DA:9D:51:60:D7:42:6A:F2:05:F1:8A:47:BE:78:A1:3A:72:06:92:60 HTTPS is the preferred protocol, providing protection against another computer pretending to be the &os; mirror (commonly known as a man in the middle attack) or otherwise trying to send bad content to the end user. If https cannot be used due to firewall or other problems, svn is the next choice, with slightly faster transfers. When neither can be used, use http. For those still using deprecated server names, the SHA1 and SHA256 fingerprints will be one of: Hash Fingerprint Legacy-SHA1 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 Legacy-SHA1 F6:44:AA:B9:03:89:0E:3E:8C:4D:4D:14:F0:27:E6:C7:C1:8B:17:C5 Legacy-SHA256 47:35:A9:09:A3:AB:FA:20:33:36:43:C5:1A:D6:E6:FB:EB:C0:C0:83:37:D4:46:9C:A0:AB:89:7F:C2:9C:4C:A3 Legacy-SHA256 48:3C:84:DB:7C:27:1B:FA:D5:0B:A0:D7:E0:4C:79:AA:A3:8E:A3:FA:84:E6:32:34:7D:EB:30:E6:11:01:CF:BE Seeing one of these legacy certificate fingerprints means it is likely that a deprecated server name is being used. For More Information For other information about using Subversion, please see the Subversion Book, titled Version Control with Subversion, or the Subversion Documentation. Using <application>rsync</application> These 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 for mirror sites of the &os; FTP server. 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;-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.