Index: head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml =================================================================== --- head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml (revision 47311) +++ head/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml (revision 47312) @@ -1,875 +1,918 @@ 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. 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.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 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. California, Bay Area, official source ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CTM/ ftp://ftp.FreeBSD.org/pub/FreeBSD/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 chapter demonstrates how to install Subversion on a &os; system and then use it to create a local copy of a &os; repository. It includes additional information on how to use Subversion. Svnlite A fully functional but light weight version of Subversion may be already installed on your &os; system as svnlite. You do not have to install a separate copy if svnlite is sufficient for your needs. If you wish to access HTTPS servers with svnlite then a root certificate bundle should be installed: &prompt.root; pkg install ca_root_nss Installing a certificate bundle allows svnlite to verify that it is securely communicating with the repository server without tampering. If you are using svnlite then you should adjust the examples below. Installation If the svnlite is unavailable or you wish to use the full version of Subversion then it must be installed. 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 &prompt.root; cd /usr/ports/security/ca_root_nss &prompt.root; make install clean Subversion can easily be installed as a package: &prompt.root; pkg install subversion &prompt.root; pkg install ca_root_nss 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 the local directory before using checkout. 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. 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 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 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), 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 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 <application>Subversion</application> Mirror Sites Subversion Repository Mirror Sites The &os; Subversion repository, svn.FreeBSD.org, 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 http://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 are still - available, but are now considered deprecated. + 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 + + + + + + If you are seeing one of these legacy certificate + fingerprints then it is likely you are using a deprecated + server name. 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> 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;-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.