diff --git a/documentation/content/en/books/handbook/bibliography/_index.adoc b/documentation/content/en/books/handbook/bibliography/_index.adoc index 15cbd02d02..3f82a9c331 100644 --- a/documentation/content/en/books/handbook/bibliography/_index.adoc +++ b/documentation/content/en/books/handbook/bibliography/_index.adoc @@ -1,151 +1,148 @@ --- title: Appendix B. Bibliography part: Part V. Appendices prev: books/handbook/mirrors next: books/handbook/eresources --- [appendix] [[bibliography]] = Bibliography :doctype: book :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :skip-front-matter: :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :sectnumoffset: B include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/en/mailing-lists.adoc[] include::shared/en/teams.adoc[] include::shared/en/urls.adoc[] While manual pages provide a definitive reference for individual pieces of the FreeBSD operating system, they seldom illustrate how to put the pieces together to make the whole operating system run smoothly. For this, there is no substitute for a good book or users' manual on UNIX(R) system administration. [[bibliography-freebsd]] == Books Specific to FreeBSD International books: * http://jdli.tw.FreeBSD.org/publication/book/freebsd2/index.htm[Using FreeBSD] (in Traditional Chinese), published by http://www.drmaster.com.tw/[Drmaster], 1997. ISBN 9-578-39435-7. * FreeBSD Unleashed (Simplified Chinese translation), published by http://www.hzbook.com/[China Machine Press]. ISBN 7-111-10201-0. * FreeBSD From Scratch Second Edition (in Simplified Chinese), published by China Machine Press. ISBN 7-111-10286-X. * FreeBSD Handbook Second Edition (Simplified Chinese translation), published by http://www.ptpress.com.cn/[Posts & Telecom Press]. ISBN 7-115-10541-3. * FreeBSD & Windows (in Simplified Chinese), published by http://www.tdpress.com/[China Railway Publishing House]. ISBN 7-113-03845-X * FreeBSD Internet Services HOWTO (in Simplified Chinese), published by China Railway Publishing House. ISBN 7-113-03423-3 * FreeBSD (in Japanese), published by CUTT. ISBN 4-906391-22-2 C3055 P2400E. * http://www.shoeisha.com/book/Detail.asp?bid=650[Complete Introduction to FreeBSD] (in Japanese), published by http://www.shoeisha.co.jp/[Shoeisha Co., Ltd]. ISBN 4-88135-473-6 P3600E. * http://www.ascii.co.jp/pb/book1/shinkan/detail/1322785.html[Personal UNIX Starter Kit FreeBSD] (in Japanese), published by http://www.ascii.co.jp/[ASCII]. ISBN 4-7561-1733-3 P3000E. * FreeBSD Handbook (Japanese translation), published by http://www.ascii.co.jp/[ASCII]. ISBN 4-7561-1580-2 P3800E. * FreeBSD mit Methode (in German), published by http://www.cul.de[Computer und Literatur Verlag]/Vertrieb Hanser, 1998. ISBN 3-932311-31-0. * http://www.mitp.de/vmi/mitp/detail/pWert/1343/[FreeBSD de Luxe] (in German), published by http://www.mitp.de[Verlag Modere Industrie], 2003. ISBN 3-8266-1343-0. * http://www.pc.mycom.co.jp/FreeBSD/install-manual.html[FreeBSD Install and Utilization Manual] (in Japanese), published by http://www.pc.mycom.co.jp/[Mainichi Communications Inc.], 1998. ISBN 4-8399-0112-0. * Onno W Purbo, Dodi Maryanto, Syahrial Hubbany, Widjil Widodo _http://maxwell.itb.ac.id/[Building Internet Server with FreeBSD]_ (in Indonesia Language), published by http://www.elexmedia.co.id/[Elex Media Komputindo]. * Absolute BSD: The Ultimate Guide to FreeBSD (Traditional Chinese translation), published by http://www.grandtech.com.tw/[GrandTech Press], 2003. ISBN 986-7944-92-5. * http://www.twbsd.org/cht/book/[The FreeBSD 6.0 Book] (in Traditional Chinese), published by Drmaster, 2006. ISBN 9-575-27878-X. English language books: * http://www.absoluteFreeBSD.com/[Absolute FreeBSD, 2nd Edition: The Complete Guide to FreeBSD], published by http://www.nostarch.com/[No Starch Press], 2007. ISBN: 978-1-59327-151-0 * http://www.freebsdmall.com/cgi-bin/fm/bsdcomp[The Complete FreeBSD], published by http://www.oreilly.com/[O'Reilly], 2003. ISBN: 0596005164 * http://www.freebsd-corp-net-guide.com/[The FreeBSD Corporate Networker's Guide], published by http://www.awl.com/aw/[Addison-Wesley], 2000. ISBN: 0201704811 * http://andrsn.stanford.edu/FreeBSD/introbook/[FreeBSD: An Open-Source Operating System for Your Personal Computer], published by The Bit Tree Press, 2001. ISBN: 0971204500 * Teach Yourself FreeBSD in 24 Hours, published by http://www.samspublishing.com/[Sams], 2002. ISBN: 0672324245 * FreeBSD 6 Unleashed, published by http://www.samspublishing.com/[Sams], 2006. ISBN: 0672328755 * FreeBSD: The Complete Reference, published by http://books.mcgraw-hill.com[McGrawHill], 2003. ISBN: 0072224096 [[bibliography-userguides]] == Users' Guides * Ohio State University has written a http://www.cs.duke.edu/csl/docs/unix_course/[UNIX Introductory Course] which is available online in HTML and PostScript format. + An Italian https://www.FreeBSD.org/doc/it_IT.ISO8859-15/books/unix-introduction/[translation] of this document is available as part of the FreeBSD Italian Documentation Project. * http://www.jp.FreeBSD.org/[Jpman Project, Japan FreeBSD Users Group]. FreeBSD User's Reference Manual (Japanese translation). http://www.pc.mycom.co.jp/[Mainichi Communications Inc.], 1998. ISBN4-8399-0088-4 P3800E. * http://www.ed.ac.uk/[Edinburgh University] has written an http://www.ed.ac.uk/information-services/help-consultancy/is-skills/catalogue/program-op-sys-catalogue/unix1[Online Guide] for newcomers to the UNIX environment. [[bibliography-adminguides]] == Administrators' Guides * http://www.jp.FreeBSD.org/[Jpman Project, Japan FreeBSD Users Group]. FreeBSD System Administrator's Manual (Japanese translation). http://www.pc.mycom.co.jp/[Mainichi Communications Inc.], 1998. ISBN4-8399-0109-0 P3300E. * Dreyfus, Emmanuel. http://www.eyrolles.com/Informatique/Livre/9782212114638/[Cahiers de l'Admin: BSD] 2nd Ed. (in French), Eyrolles, 2004. ISBN 2-212-11463-X [[bibliography-programmers]] == Programmers' Guides * Computer Systems Research Group, UC Berkeley. _4.4BSD Programmer's Reference Manual_. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-078-3 * Computer Systems Research Group, UC Berkeley. _4.4BSD Programmer's Supplementary Documents_. O'Reilly & Associates, Inc., 1994. ISBN 1-56592-079-1 * Harbison, Samuel P. and Steele, Guy L. Jr. _C: A Reference Manual_. 4th Ed. Prentice Hall, 1995. ISBN 0-13-326224-3 * Kernighan, Brian and Dennis M. Ritchie. _The C Programming Language_. 2nd Ed. PTR Prentice Hall, 1988. ISBN 0-13-110362-8 * Lehey, Greg. _Porting UNIX Software_. O'Reilly & Associates, Inc., 1995. ISBN 1-56592-126-7 * Plauger, P. J. _The Standard C Library_. Prentice Hall, 1992. ISBN 0-13-131509-9 * Spinellis, Diomidis. http://www.spinellis.gr/codereading/[Code Reading: The Open Source Perspective]. Addison-Wesley, 2003. ISBN 0-201-79940-5 * Spinellis, Diomidis. http://www.spinellis.gr/codequality/[Code Quality: The Open Source Perspective]. Addison-Wesley, 2006. ISBN 0-321-16607-8 * Stevens, W. Richard and Stephen A. Rago. _Advanced Programming in the UNIX Environment_. 2nd Ed. Reading, Mass. : Addison-Wesley, 2005. ISBN 0-201-43307-9 * Stevens, W. Richard. _UNIX Network Programming_. 2nd Ed, PTR Prentice Hall, 1998. ISBN 0-13-490012-X [[bibliography-osinternals]] == Operating System Internals * Andleigh, Prabhat K. _UNIX System Architecture_. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5 * Jolitz, William. "Porting UNIX to the 386". _Dr. Dobb's Journal_. January 1991-July 1992. * Leffler, Samuel J., Marshall Kirk McKusick, Michael J Karels and John Quarterman _The Design and Implementation of the 4.3BSD UNIX Operating System_. Reading, Mass. : Addison-Wesley, 1989. ISBN 0-201-06196-1 * Leffler, Samuel J., Marshall Kirk McKusick, _The Design and Implementation of the 4.3BSD UNIX Operating System: Answer Book_. Reading, Mass. : Addison-Wesley, 1991. ISBN 0-201-54629-9 * McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. _The Design and Implementation of the 4.4BSD Operating System_. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-54979-4 + (Chapter 2 of this book is available link:{design-44bsd}[online] as part of the FreeBSD Documentation Project.) * Marshall Kirk McKusick, George V. Neville-Neil _The Design and Implementation of the FreeBSD Operating System_. Boston, Mass. : Addison-Wesley, 2004. ISBN 0-201-70245-2 * Marshall Kirk McKusick, George V. Neville-Neil, Robert N. M. Watson _The Design and Implementation of the FreeBSD Operating System, 2nd Ed._. Westford, Mass. : Pearson Education, Inc., 2014. ISBN 0-321-96897-2 * Stevens, W. Richard. _TCP/IP Illustrated, Volume 1: The Protocols_. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63346-9 * Schimmel, Curt. _Unix Systems for Modern Architectures_. Reading, Mass. : Addison-Wesley, 1994. ISBN 0-201-63338-8 * Stevens, W. Richard. _TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols_. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-63495-3 * Vahalia, Uresh. _UNIX Internals -- The New Frontiers_. Prentice Hall, 1996. ISBN 0-13-101908-2 * Wright, Gary R. and W. Richard Stevens. _TCP/IP Illustrated, Volume 2: The Implementation_. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63354-X [[bibliography-security]] == Security Reference * Cheswick, William R. and Steven M. Bellovin. _Firewalls and Internet Security: Repelling the Wily Hacker_. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-63357-4 * Garfinkel, Simson. _PGP Pretty Good Privacy_ O'Reilly & Associates, Inc., 1995. ISBN 1-56592-098-8 [[bibliography-hardware]] == Hardware Reference * Anderson, Don and Tom Shanley. _Pentium Processor System Architecture_. 2nd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40992-5 * Ferraro, Richard F. _Programmer's Guide to the EGA, VGA, and Super VGA Cards_. 3rd ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-62490-7 * Intel Corporation publishes documentation on their CPUs, chipsets and standards on their http://developer.intel.com/[developer web site], usually as PDF files. * Shanley, Tom. _80486 System Architecture_. 3rd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40994-1 * Shanley, Tom. _ISA System Architecture_. 3rd Ed. Reading, Mass. : Addison-Wesley, 1995. ISBN 0-201-40996-8 * Shanley, Tom. _PCI System Architecture_. 4th Ed. Reading, Mass. : Addison-Wesley, 1999. ISBN 0-201-30974-2 * Van Gilluwe, Frank. _The Undocumented PC_, 2nd Ed. Reading, Mass: Addison-Wesley Pub. Co., 1996. ISBN 0-201-47950-8 * Messmer, Hans-Peter. _The Indispensable PC Hardware Book_, 4th Ed. Reading, Mass : Addison-Wesley Pub. Co., 2002. ISBN 0-201-59616-4 [[bibliography-history]] == UNIX(R) History * Lion, John _Lion's Commentary on UNIX, 6th Ed. With Source Code_. ITP Media Group, 1996. ISBN 1573980137 * Raymond, Eric S. _The New Hacker's Dictionary, 3rd edition_. MIT Press, 1996. ISBN 0-262-68092-0. Also known as the http://www.catb.org/~esr/jargon/html/index.html[Jargon File] * Salus, Peter H. _A quarter century of UNIX_. Addison-Wesley Publishing Company, Inc., 1994. ISBN 0-201-54777-5 * Simon Garfinkel, Daniel Weise, Steven Strassmann. _The UNIX-HATERS Handbook_. IDG Books Worldwide, Inc., 1994. ISBN 1-56884-203-1. Out of print, but available http://www.simson.net/ref/ugh.pdf[online]. * Don Libes, Sandy Ressler _Life with UNIX_ - special edition. Prentice-Hall, Inc., 1989. ISBN 0-13-536657-7 -* _The BSD family tree_. https://svnweb.freebsd.org/base/head/shared/misc/bsd-family-tree?view=co[https://svnweb.freebsd.org/base/head/shared/misc/bsd-family-tree?view=co] or link:file://localhost/usr/share/misc/bsd-family-tree[/usr/share/misc/bsd-family-tree] on a FreeBSD machine. +* _The BSD family tree_. https://cgit.freebsd.org/src/tree/share/misc/bsd-family-tree[https://cgit.freebsd.org/src/tree/share/misc/bsd-family-tree] or link:file://localhost/usr/share/misc/bsd-family-tree[/usr/share/misc/bsd-family-tree] on a FreeBSD machine. * _Networked Computer Science Technical Reports Library_. * _Old BSD releases from the Computer Systems Research group (CSRG)_. http://www.mckusick.com/csrg/[http://www.mckusick.com/csrg/]: The 4CD set covers all BSD versions from 1BSD to 4.4BSD and 4.4BSD-Lite2 (but not 2.11BSD, unfortunately). The last disk also holds the final sources plus the SCCS files. * Kernighan, Brian _Unix: A History and a Memoir_. Kindle Direct Publishing, 2020. ISBN 978-169597855-3 [[bibliography-journals]] == Periodicals, Journals, and Magazines * http://www.admin-magazin.de/[Admin Magazin] (in German), published by Medialinx AG. ISSN: 2190-1066 * http://www.bsdmag.org/[BSD Magazine], published by Software Press Sp. z o.o. SK. ISSN: 1898-9144 * http://www.bsdnow.tv/[BSD Now - Video Podcast], published by Jupiter Broadcasting LLC * http://bsdtalk.blogspot.com/[BSD Talk Podcast], by Will Backman * http://freebsdjournal.com/[FreeBSD Journal], published by S&W Publishing, sponsored by The FreeBSD Foundation. ISBN: 978-0-615-88479-0 - -:sectnums: -:sectnumlevels: 6 diff --git a/documentation/content/en/books/handbook/cutting-edge/_index.adoc b/documentation/content/en/books/handbook/cutting-edge/_index.adoc index 7f86b9240e..a9512d215e 100644 --- a/documentation/content/en/books/handbook/cutting-edge/_index.adoc +++ b/documentation/content/en/books/handbook/cutting-edge/_index.adoc @@ -1,918 +1,984 @@ --- title: Chapter 24. Updating and Upgrading FreeBSD part: Part III. System Administration prev: books/handbook/l10n next: books/handbook/dtrace --- [[updating-upgrading]] = Updating and Upgrading FreeBSD :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :skip-front-matter: :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :sectnumoffset: 24 ifeval::["{backend}" == "html5"] :imagesdir: ../../../../images/books/handbook/cutting-edge/ endif::[] ifeval::["{backend}" == "pdf"] :imagesdir: ../../../../static/images/books/handbook/cutting-edge/ endif::[] ifeval::["{backend}" == "epub3"] :imagesdir: ../../../../static/images/books/handbook/cutting-edge/ endif::[] include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/en/mailing-lists.adoc[] include::shared/en/teams.adoc[] include::shared/en/urls.adoc[] toc::[] [[updating-upgrading-synopsis]] == Synopsis -FreeBSD 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, FreeBSD provides all the necessary tools to keep the system updated, and allows for easy upgrades between versions. This chapter describes how to track the development system and the basic tools for keeping a FreeBSD system up-to-date. +FreeBSD 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, FreeBSD provides all the necessary tools to keep the system updated, and allows for easy upgrades between versions. +This chapter describes how to track the development system and the basic tools for keeping a FreeBSD system up-to-date. After reading this chapter, you will know: -* How to keep a FreeBSD system up-to-date with freebsd-update or Subversion. +* How to keep a FreeBSD system up-to-date with freebsd-update or Git. * How to compare the state of an installed system against a known pristine copy. -* How to keep the installed documentation up-to-date with Subversion or documentation ports. +* How to keep the installed documentation up-to-date with Git or documentation ports. * The difference between the two development branches: FreeBSD-STABLE and FreeBSD-CURRENT. * How to rebuild and reinstall the entire base system. Before reading this chapter, you should: * Properly set up the network connection (crossref:advanced-networking[advanced-networking,Advanced Networking]). * Know how to install additional third-party software (crossref:ports[ports,Installing Applications: Packages and Ports]). [NOTE] ==== -Throughout this chapter, `svnlite` is used to obtain and update FreeBSD sources. Optionally, the package:devel/subversion[] port or package may be used. +Throughout this chapter, `git` is used to obtain and update FreeBSD sources. Optionally, the package:devel/git[] port or package may be used. ==== [[updating-upgrading-freebsdupdate]] == FreeBSD Update -Applying security patches in a timely manner and upgrading to a newer release of an operating system are important aspects of ongoing system administration. FreeBSD includes a utility called `freebsd-update` which can be used to perform both these tasks. +Applying security patches in a timely manner and upgrading to a newer release of an operating system are important aspects of ongoing system administration. +FreeBSD includes a utility called `freebsd-update` which can be used to perform both these tasks. -This utility supports binary security and errata updates to FreeBSD, without the need to manually compile and install the patch or a new kernel. Binary updates are available for all architectures and releases currently supported by the security team. The list of supported releases and their estimated end-of-life dates are listed at https://www.FreeBSD.org/security/[https://www.FreeBSD.org/security/]. +This utility supports binary security and errata updates to FreeBSD, without the need to manually compile and install the patch or a new kernel. +Binary updates are available for all architectures and releases currently supported by the security team. +The list of supported releases and their estimated end-of-life dates are listed at https://www.FreeBSD.org/security/[https://www.FreeBSD.org/security/]. -This utility also supports operating system upgrades to minor point releases as well as upgrades to another release branch. Before upgrading to a new release, review its release announcement as it contains important information pertinent to the release. Release announcements are available from https://www.FreeBSD.org/releases/[https://www.FreeBSD.org/releases/]. +This utility also supports operating system upgrades to minor point releases as well as upgrades to another release branch. +Before upgrading to a new release, review its release announcement as it contains important information pertinent to the release. +Release announcements are available from https://www.FreeBSD.org/releases/[https://www.FreeBSD.org/releases/]. [NOTE] ==== If a `crontab` utilizing the features of man:freebsd-update[8] exists, it must be disabled before upgrading the operating system. ==== This section describes the configuration file used by `freebsd-update`, demonstrates how to apply a security patch and how to upgrade to a minor or major operating system release, and discusses some of the considerations when upgrading the operating system. [[freebsdupdate-config-file]] === The Configuration File -The default configuration file for `freebsd-update` works as-is. Some users may wish to tweak the default configuration in [.filename]#/etc/freebsd-update.conf#, allowing better control of the process. The comments in this file explain the available options, but the following may require a bit more explanation: +The default configuration file for `freebsd-update` works as-is. +Some users may wish to tweak the default configuration in [.filename]#/etc/freebsd-update.conf#, allowing better control of the process. +The comments in this file explain the available options, but the following may require a bit more explanation: [.programlisting] .... # Components of the base system which should be kept updated. Components world kernel .... -This parameter controls which parts of FreeBSD will be kept up-to-date. The default is to update the entire base system and the kernel. Individual components can instead be specified, such as `src/base` or `src/sys`. However, the best option is to leave this at the default as changing it to include specific items requires every needed item to be listed. Over time, this could have disastrous consequences as source code and binaries may become out of sync. +This parameter controls which parts of FreeBSD will be kept up-to-date. +The default is to update the entire base system and the kernel. +Individual components can instead be specified, such as `src/base` or `src/sys`. +However, the best option is to leave this at the default as changing it to include specific items requires every needed item to be listed. +Over time, this could have disastrous consequences as source code and binaries may become out of sync. [.programlisting] .... # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /boot/kernel/linker.hints .... -To leave specified directories, such as [.filename]#/bin# or [.filename]#/sbin#, untouched during the update process, add their paths to this statement. This option may be used to prevent `freebsd-update` from overwriting local modifications. +To leave specified directories, such as [.filename]#/bin# or [.filename]#/sbin#, untouched during the update process, add their paths to this statement. +This option may be used to prevent `freebsd-update` from overwriting local modifications. [.programlisting] .... # 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 .... -This option will only update unmodified configuration files in the specified directories. Any changes made by the user will prevent the automatic updating of these files. There is another option, `KeepModifiedMetadata`, which will instruct `freebsd-update` to save the changes during the merge. +This option will only update unmodified configuration files in the specified directories. +Any changes made by the user will prevent the automatic updating of these files. +There is another option, `KeepModifiedMetadata`, which will instruct `freebsd-update` to save the changes during the merge. [.programlisting] .... # When upgrading to a new FreeBSD release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ /boot/device.hints .... -List of directories with configuration files that `freebsd-update` should attempt to merge. The file merge process is a series of man:diff[1] patches similar to man:mergemaster[8], but with fewer options. Merges are either accepted, open an editor, or cause `freebsd-update` to abort. When in doubt, backup [.filename]#/etc# and just accept the merges. See man:mergemaster[8] for more information about `mergemaster`. +List of directories with configuration files that `freebsd-update` should attempt to merge. +The file merge process is a series of man:diff[1] patches similar to man:mergemaster[8], but with fewer options. +Merges are either accepted, open an editor, or cause `freebsd-update` to abort. +When in doubt, backup [.filename]#/etc# and just accept the merges. +See man:mergemaster[8] for more information about `mergemaster`. [.programlisting] .... # Directory in which to store downloaded updates and temporary # files used by FreeBSD Update. # WorkDir /var/db/freebsd-update .... -This directory is where all patches and temporary files are placed. In cases where the user is doing a version upgrade, this location should have at least a gigabyte of disk space available. +This directory is where all patches and temporary files are placed. +In cases where the user is doing a version upgrade, this location should have at least a gigabyte of disk space available. [.programlisting] .... # 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 FreeBSD Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no .... -When this option is 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. +When this option is 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. [[freebsdupdate-security-patches]] === Applying Security Patches -The process of applying FreeBSD security patches has been simplified, allowing an administrator to keep a system fully patched using `freebsd-update`. More information about FreeBSD security advisories can be found in crossref:security[security-advisories,"FreeBSD Security Advisories"]. +The process of applying FreeBSD security patches has been simplified, allowing an administrator to keep a system fully patched using `freebsd-update`. +More information about FreeBSD security advisories can be found in crossref:security[security-advisories,"FreeBSD Security Advisories"]. -FreeBSD security patches may be downloaded and installed using the following commands. The first command will determine if any outstanding patches are available, and if so, will list the files that will be modifed if the patches are applied. The second command will apply the patches. +FreeBSD security patches may be downloaded and installed using the following commands. +The first command will determine if any outstanding patches are available, and if so, will list the files that will be modifed if the patches are applied. +The second command will apply the patches. [source,shell] .... # freebsd-update fetch # freebsd-update install .... -If the update applies any kernel patches, the system will need a reboot in order to boot into the patched kernel. If the patch was applied to any running binaries, the affected applications should be restarted so that the patched version of the binary is used. +If the update applies any kernel patches, the system will need a reboot in order to boot into the patched kernel. +If the patch was applied to any running binaries, the affected applications should be restarted so that the patched version of the binary is used. [NOTE] ==== -Usually, the user needs to be prepared to reboot the system. To know if a reboot is required by a kernel update, execute the commands `freebsd-version -k` and `uname -r` and if it differs a reboot is required. +Usually, the user needs to be prepared to reboot the system. +To know if a reboot is required by a kernel update, execute the commands `freebsd-version -k` and `uname -r` and if it differs a reboot is required. ==== The system can be configured to automatically check for updates once every day by adding this entry to [.filename]#/etc/crontab#: [.programlisting] .... @daily root freebsd-update cron .... -If patches exist, they will automatically be downloaded but will not be applied. The `root` user will be sent an email so that the patches may be reviewed and manually installed with `freebsd-update install`. +If patches exist, they will automatically be downloaded but will not be applied. +The `root` user will be sent an email so that the patches may be reviewed and manually installed with `freebsd-update install`. If anything goes wrong, `freebsd-update` has the ability to roll back the last set of changes with the following command: [source,shell] .... # freebsd-update rollback Uninstalling updates... done. .... Again, the system should be restarted if the kernel or any kernel modules were modified and any affected binaries should be restarted. -Only the [.filename]#GENERIC# kernel can be automatically updated by `freebsd-update`. If a custom kernel is installed, it will have to be rebuilt and reinstalled after `freebsd-update` finishes installing the updates. The default kernel name is _GENERIC_. The man:uname[1] command may be used to verify its installation. +Only the [.filename]#GENERIC# kernel can be automatically updated by `freebsd-update`. +If a custom kernel is installed, it will have to be rebuilt and reinstalled after `freebsd-update` finishes installing the updates. +The default kernel name is _GENERIC_. +The man:uname[1] command may be used to verify its installation. [NOTE] ==== -Always keep a copy of the [.filename]#GENERIC# kernel in [.filename]#/boot/GENERIC#. It will be helpful in diagnosing a variety of problems and in performing version upgrades. Refer to <> for instructions on how to get a copy of the [.filename]#GENERIC# kernel. +Always keep a copy of the [.filename]#GENERIC# kernel in [.filename]#/boot/GENERIC#. +It will be helpful in diagnosing a variety of problems and in performing version upgrades. +Refer to <> for instructions on how to get a copy of the [.filename]#GENERIC# kernel. ==== -Unless the default configuration in [.filename]#/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 a new custom kernel can then be performed in the usual way. +Unless the default configuration in [.filename]#/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 a new custom kernel can then be performed in the usual way. -The updates distributed by `freebsd-update` do not always involve the kernel. It is not necessary to rebuild a custom kernel if the kernel sources have not been modified by `freebsd-update install`. However, `freebsd-update` will always update [.filename]#/usr/src/sys/conf/newvers.sh#. The current patch level, as indicated by the `-p` number reported by `uname -r`, is obtained from this file. Rebuilding a custom kernel, even if nothing else changed, allows `uname` 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. +The updates distributed by `freebsd-update` do not always involve the kernel. +It is not necessary to rebuild a custom kernel if the kernel sources have not been modified by `freebsd-update install`. +However, `freebsd-update` will always update [.filename]#/usr/src/sys/conf/newvers.sh#. +The current patch level, as indicated by the `-p` number reported by `uname -r`, is obtained from this file. +Rebuilding a custom kernel, even if nothing else changed, allows `uname` 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. [[freebsdupdate-upgrade]] === Performing Major and Minor Version Upgrades -Upgrades from one minor version of FreeBSD to another, like from FreeBSD 9.0 to FreeBSD 9.1, are called _minor version_ upgrades. _Major version_ upgrades occur when FreeBSD is upgraded from one major version to another, like from FreeBSD 9.X to FreeBSD 10.X. Both types of upgrades can be performed by providing `freebsd-update` with a release version target. +Upgrades from one minor version of FreeBSD to another, like from FreeBSD 9.0 to FreeBSD 9.1, are called _minor version_ upgrades. +_Major version_ upgrades occur when FreeBSD is upgraded from one major version to another, like from FreeBSD 9.X to FreeBSD 10.X. +Both types of upgrades can be performed by providing `freebsd-update` with a release version target. [NOTE] ==== -If the system is running a custom kernel, make sure that a copy of the [.filename]#GENERIC# kernel exists in [.filename]#/boot/GENERIC# before starting the upgrade. Refer to <> for instructions on how to get a copy of the [.filename]#GENERIC# kernel. +If the system is running a custom kernel, make sure that a copy of the [.filename]#GENERIC# kernel exists in [.filename]#/boot/GENERIC# before starting the upgrade. +Refer to <> for instructions on how to get a copy of the [.filename]#GENERIC# kernel. ==== The following command, when run on a FreeBSD 9.0 system, will upgrade it to FreeBSD 9.1: [source,shell] .... # freebsd-update -r 9.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 perform the upgrade. A screen listing will display which components have and have not been detected. For example: +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 perform the upgrade. +A screen listing will display which components have and have not been detected. +For example: [source,shell] .... Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 9.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. +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: [source,shell] .... WARNING: This system is running a "MYKERNEL" kernel, which is not a kernel configuration distributed as part of FreeBSD 9.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 [.filename]#GENERIC# kernel will be used as an intermediate step in the upgrade process. +This warning may be safely ignored at this point. +The updated [.filename]#GENERIC# kernel will be used as an intermediate step in the upgrade process. -Once all the patches have been downloaded to the local system, they will be applied. This process may take a while, depending on the speed and workload of the machine. Configuration files will then be merged. The merging 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 [.filename]#/etc# and manually merge important files, such as [.filename]#master.passwd# or [.filename]#group# at a later time. +Once all the patches have been downloaded to the local system, they will be applied. +This process may take a while, depending on the speed and workload of the machine. +Configuration files will then be merged. +The merging 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 [.filename]#/etc# and manually merge important files, +such as [.filename]#master.passwd# or [.filename]#group# at a later time. [NOTE] ==== -The system is not being altered yet as all patching and merging is happening in another directory. Once all patches have been applied successfully, all configuration files have been merged and it seems the process will go smoothly, the changes can be committed to disk by the user using the following command: +The system is not being altered yet as all patching and merging is happening in another directory. +Once all patches have been applied successfully, +all configuration files have been merged and it seems the process will go smoothly, +the changes can be committed to disk by the user using the following command: [source,shell] .... # freebsd-update install .... ==== -The kernel and kernel modules will be patched first. If the system is running with a custom kernel, use man:nextboot[8] to set the kernel for the next boot to the updated [.filename]#/boot/GENERIC#: +The kernel and kernel modules will be patched first. +If the system is running with a custom kernel, +use man:nextboot[8] to set the kernel for the next boot to the updated [.filename]#/boot/GENERIC#: [source,shell] .... # nextboot -k GENERIC .... [WARNING] ==== - -Before rebooting with the [.filename]#GENERIC# kernel, make sure it contains all the drivers required for the system to boot properly and connect to the network, if the machine being updated is accessed remotely. In particular, if the running custom kernel contains built-in functionality usually provided by kernel modules, make sure to temporarily load these modules into the [.filename]#GENERIC# kernel using the [.filename]#/boot/loader.conf# facility. It is recommended to disable non-essential services as well as any disk and network mounts until the upgrade process is complete. +Before rebooting with the [.filename]#GENERIC# kernel, +make sure it contains all the drivers required for the system to boot properly and connect to the network, +if the machine being updated is accessed remotely. +In particular, if the running custom kernel contains built-in functionality usually provided by kernel modules, make sure to temporarily load these modules into the [.filename]#GENERIC# kernel using the [.filename]#/boot/loader.conf# facility. +It is recommended to disable non-essential services as well as any disk and network mounts until the upgrade process is complete. ==== The machine should now be restarted with the updated kernel: [source,shell] .... # shutdown -r now .... -Once the system has come back online, restart `freebsd-update` using the following command. Since the state of the process has been saved, `freebsd-update` will not start from the beginning, but will instead move on to the next phase and remove all old shared libraries and object files. +Once the system has come back online, restart `freebsd-update` using the following command. +Since the state of the process has been saved, `freebsd-update` will not start from the beginning, +but will instead move on to the next phase and remove all old shared libraries and object files. [source,shell] .... # freebsd-update install .... [NOTE] ==== Depending upon whether any library version numbers were bumped, there may only be two install phases instead of three. ==== -The upgrade is now complete. If this was a major version upgrade, reinstall all ports and packages as described in <>. +The upgrade is now complete. +If this was a major version upgrade, reinstall all ports and packages as described in <>. [[freebsd-update-custom-kernel-9x]] ==== Custom Kernels with FreeBSD 9.X and Later -Before using `freebsd-update`, ensure that a copy of the [.filename]#GENERIC# kernel exists in [.filename]#/boot/GENERIC#. If a custom kernel has only been built once, the kernel in [.filename]#/boot/kernel.old# is the `GENERIC` kernel. Simply rename this directory to [.filename]#/boot/GENERIC#. +Before using `freebsd-update`, ensure that a copy of the [.filename]#GENERIC# kernel exists in [.filename]#/boot/GENERIC#. +If a custom kernel has only been built once, the kernel in [.filename]#/boot/kernel.old# is the `GENERIC` kernel. +Simply rename this directory to [.filename]#/boot/GENERIC#. -If a custom kernel has been built more than once or if it is unknown how many times the custom kernel has been built, obtain a copy of the `GENERIC` kernel that matches the current version of the operating system. If physical access to the system is available, a copy of the `GENERIC` kernel can be installed from the installation media: +If a custom kernel has been built more than once or if it is unknown how many times the custom kernel has been built, +obtain a copy of the `GENERIC` kernel that matches the current version of the operating system. +If physical access to the system is available, a copy of the `GENERIC` kernel can be installed from the installation media: [source,shell] .... # mount /cdrom # cd /cdrom/usr/freebsd-dist # tar -C/ -xvf kernel.txz boot/kernel/kernel .... Alternately, the `GENERIC` kernel may be rebuilt and installed from source: [source,shell] .... # cd /usr/src # make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null .... -For this kernel to be identified as the `GENERIC` kernel by `freebsd-update`, the [.filename]#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. +For this kernel to be identified as the `GENERIC` kernel by `freebsd-update`, +the [.filename]#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 into the [.filename]#GENERIC# kernel is not required as `freebsd-update` only needs [.filename]#/boot/GENERIC# to exist. [[freebsdupdate-portsrebuild]] ==== Upgrading Packages After a Major Version Upgrade -Generally, installed applications will continue to work without problems after minor version upgrades. Major versions use different Application Binary Interfaces (ABIs), which will break most third-party applications. After a major version upgrade, all installed packages and ports need to be upgraded. Packages can be upgraded using `pkg upgrade`. To upgrade installed ports, use a utility such as package:ports-mgmt/portmaster[]. +Generally, installed applications will continue to work without problems after minor version upgrades. +Major versions use different Application Binary Interfaces (ABIs), which will break most third-party applications. +After a major version upgrade, all installed packages and ports need to be upgraded. +Packages can be upgraded using `pkg upgrade`. +To upgrade installed ports, use a utility such as package:ports-mgmt/portmaster[]. -A forced upgrade of all installed packages will replace the packages with fresh versions from the repository even if the version number has not increased. This is required because of the ABI version change when upgrading between major versions of FreeBSD. The forced upgrade can be accomplished by performing: +A forced upgrade of all installed packages will replace the packages with fresh versions from the repository even if the version number has not increased. +This is required because of the ABI version change when upgrading between major versions of FreeBSD. +The forced upgrade can be accomplished by performing: [source,shell] .... # pkg-static upgrade -f .... A rebuild of all installed applications can be accomplished with this command: [source,shell] .... # portmaster -af .... -This command will display the configuration screens for each application that has configurable options and wait for the user to interact with those screens. To prevent this behavior, and use only the default options, include `-G` in the above command. +This command will display the configuration screens for each application that has configurable options and wait for the user to interact with those screens. +To prevent this behavior, and use only the default options, include `-G` in the above command. -Once the software upgrades are complete, finish the upgrade process with a final call to `freebsd-update` in order to tie up all the loose ends in the upgrade process: +Once the software upgrades are complete, +finish the upgrade process with a final call to `freebsd-update` in order to tie up all the loose ends in the upgrade process: [source,shell] .... # freebsd-update install .... -If the [.filename]#GENERIC# kernel was temporarily used, this is the time to build and install a new custom kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. +If the [.filename]#GENERIC# kernel was temporarily used, +this is the time to build and install a new custom kernel using the instructions in crossref:kernelconfig[kernelconfig,Configuring the FreeBSD Kernel]. -Reboot the machine into the new FreeBSD version. The upgrade process is now complete. +Reboot the machine into the new FreeBSD version. +The upgrade process is now complete. [[freebsdupdate-system-comparison]] === System State Comparison -The state of the installed FreeBSD version against a known good copy can be tested using `freebsd-update IDS`. This command evaluates the current version of system utilities, libraries, and configuration files and can be used as a built-in Intrusion Detection System (IDS). +The state of the installed FreeBSD version against a known good copy can be tested using `freebsd-update IDS`. +This command evaluates the current version of system utilities, libraries, and configuration files and can be used as a built-in Intrusion Detection System (IDS). [WARNING] ==== - -This command is not a replacement for a real IDS such as package:security/snort[]. As `freebsd-update` stores data on disk, the possibility of tampering is evident. While this possibility may be reduced using `kern.securelevel` and by 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. An alternative method for providing IDS functionality using a built-in utility is described in crossref:security[security-ids,"Binary Verification"] +This command is not a replacement for a real IDS such as package:security/snort[]. +As `freebsd-update` stores data on disk, the possibility of tampering is evident. +While this possibility may be reduced using `kern.securelevel` and by 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. +An alternative method for providing IDS functionality using a built-in utility is described in crossref:security[security-ids,"Binary Verification"] ==== To begin the comparison, specify the output file to save the results to: [source,shell] .... # freebsd-update IDS >> outfile.ids .... The system will now be inspected and a lengthy listing of files, along with the SHA256 hash values for both the known value in the release and the current installation, will be sent to the specified output file. -The entries in the listing are extremely long, but the output format may be easily parsed. For instance, to obtain a list of all files which differ from those in the release, issue the following command: +The entries in the listing are extremely long, but the output format may be easily parsed. +For instance, to obtain a list of all files which differ from those in the release, issue the following command: [source,shell] .... # cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf .... -This sample output has been truncated as many more files exist. Some files have natural modifications. For example, [.filename]#/etc/passwd# will be modified if users have been added to the system. Kernel modules may differ as `freebsd-update` may have updated them. To exclude specific files or directories, add them to the `IDSIgnorePaths` option in [.filename]#/etc/freebsd-update.conf#. +This sample output has been truncated as many more files exist. +Some files have natural modifications. +For example, [.filename]#/etc/passwd# will be modified if users have been added to the system. +Kernel modules may differ as `freebsd-update` may have updated them. +To exclude specific files or directories, add them to the `IDSIgnorePaths` option in [.filename]#/etc/freebsd-update.conf#. [[updating-upgrading-documentation]] == Updating the Documentation Set -Documentation is an integral part of the FreeBSD operating system. While an up-to-date version of the FreeBSD documentation is always available on the FreeBSD web site (link:https://www.FreeBSD.org/doc/[https://www.freebsd.org/doc/]), it can be handy to have an up-to-date, local copy of the FreeBSD website, handbooks, FAQ, and articles. +Documentation is an integral part of the FreeBSD operating system. +While an up-to-date version of the FreeBSD documentation is always available on the FreeBSD web site (link:https://docs.FreeBSD.org[Documentation Portal]), it can be handy to have an up-to-date, local copy of the FreeBSD website, handbooks, FAQ, and articles. This section describes how to use either source or the FreeBSD Ports Collection to keep a local copy of the FreeBSD documentation up-to-date. -For information on editing and submitting corrections to the documentation, refer to the FreeBSD Documentation Project Primer for New Contributors (link:{fdp-primer}[FreeBSD Documentation Project Primer for New Contributors]). +For information on editing and submitting corrections to the documentation, +refer to the FreeBSD Documentation Project Primer for New Contributors (link:{fdp-primer}[FreeBSD Documentation Project Primer for New Contributors]). [[updating-installed-documentation]] === Updating Documentation from Source -Rebuilding the FreeBSD documentation from source requires a collection of tools which are not part of the FreeBSD base system. The required tools can be installed from the package:textproc/docproj[] package or port developed by the FreeBSD Documentation Project. +Rebuilding the FreeBSD documentation from source requires a collection of tools which are not part of the FreeBSD base system. +The required tools can be installed following link:{fdp-primer}#overview-quick-start[these steps] from the FreeBSD Documentation Project Primer. -Once installed, use svnlite to fetch a clean copy of the documentation source: +Once installed, use `git` to fetch a clean copy of the documentation source: [source,shell] .... -# svnlite checkout https://svn.FreeBSD.org/doc/head /usr/doc +# git clone https://git.FreeBSD.org/doc.git /usr/doc .... -The initial download of the documentation sources may take a while. Let it run until it completes. +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: [source,shell] .... -# svnlite update /usr/doc -.... - -Once an up-to-date snapshot of the documentation sources has been fetched to [.filename]#/usr/doc#, everything is ready for an update of the installed documentation. - -A full update of all available languages may be performed by typing: - -[source,shell] -.... -# cd /usr/doc -# make install clean -.... - -If an update of only a specific language is desired, `make` can be invoked in a language-specific subdirectory of [.filename]#/usr/doc#: - -[source,shell] -.... -# cd /usr/doc/en_US.ISO8859-1 -# make install clean +# git pull .... -An alternative way of updating the documentation is to run this command from [.filename]#/usr/doc# or the desired language-specific subdirectory: - -[source,shell] -.... -# make update -.... +Once an up-to-date snapshot of the documentation sources has been fetched to [.filename]#/usr/doc#, +everything is ready for an update of the installed documentation. -The output formats that will be installed may be specified by setting `FORMATS`: +A full update may be performed by typing: [source,shell] .... # cd /usr/doc -# make FORMATS='html html-split' install clean -.... - -Several options are available to 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 [.filename]#/etc/make.conf#, or as command-line options passed to `make`. - -The options include: - -`DOC_LANG`:: -The list of languages and encodings to build and install, such as `en_US.ISO8859-1` for English documentation. - -`FORMATS`:: -A single format or a list of output formats to be built. Currently, `html`, `html-split`, `txt`, `ps`, and `pdf` are supported. - -`DOCDIR`:: -Where to install the documentation. It defaults to [.filename]#/usr/share/doc#. - -For more `make` variables supported as system-wide options in FreeBSD, refer to man:make.conf[5]. - -[[doc-ports-install-package]] -=== Updating Documentation from Ports - -The previous section presented a method for updating the FreeBSD documentation from sources. This section describes an alternative method which uses the Ports Collection and makes it possible to: - -* Install pre-built packages of the documentation, without having to locally build anything or install the documentation toolchain. -* Build the documentation sources through the ports framework, making the checkout and build steps a bit easier. - -This method of updating the FreeBSD documentation is supported by a set of documentation ports and packages which are updated by the {doceng} on a monthly basis. These are listed in the FreeBSD Ports Collection, under the docs category (http://www.freshports.org/docs/[http://www.freshports.org/docs/]). - -Organization of the documentation ports is as follows: - -* The package:misc/freebsd-doc-en[] package or port installs all of the English documentation. -* The package:misc/freebsd-doc-all[] meta-package or port installs all documentation in all available languages. -* There is a package and port for each translation, such as package:misc/freebsd-doc-hu[] for the Hungarian documentation. - -When binary packages are used, the FreeBSD documentation will be installed in all available formats for the given language. For example, the following command will install the latest package of the Hungarian documentation: - -[source,shell] -.... -# pkg install hu-freebsd-doc -.... - -[NOTE] -==== -Packages use a format that differs from the corresponding port's name: `_lang_-freebsd-doc`, where _lang_ is the short format of the language code, such as `hu` for Hungarian, or `zh_cn` for Simplified Chinese. -==== - -To specify the format of the documentation, build the port instead of installing the package. For example, to build and install the English documentation: - -[source,shell] -.... -# cd /usr/ports/misc/freebsd-doc-en -# make install clean -.... - -The port provides a configuration menu where the format to build and install can be specified. By default, split HTML, similar to the format used on http://www.FreeBSD.org[http://www.FreeBSD.org], and PDF are selected. - -Alternately, several `make` options can be specified when building a documentation port, including: - -`WITH_HTML`:: -Builds the HTML format with a single HTML file per document. The formatted documentation is saved to a file called [.filename]#article.html#, or [.filename]#book.html#. - -`WITH_PDF`:: -The formatted documentation is saved to a file called [.filename]#article.pdf# or [.filename]#book.pdf#. - -`DOCBASE`:: -Specifies where to install the documentation. It defaults to [.filename]#/usr/local/shared/doc/freebsd#. - -This example uses variables to install the Hungarian documentation as a PDF in the specified directory: - -[source,shell] -.... -# cd /usr/ports/misc/freebsd-doc-hu -# make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean -.... - -Documentation packages or ports can be updated using the instructions in crossref:ports[ports,Installing Applications: Packages and Ports]. For example, the following command updates the installed Hungarian documentation using package:ports-mgmt/portmaster[] by using packages only: - -[source,shell] -.... -# portmaster -PP hu-freebsd-doc +# make .... [[current-stable]] == Tracking a Development Branch FreeBSD has two development branches: FreeBSD-CURRENT and FreeBSD-STABLE. This section provides an explanation of each branch and its intended audience, as well as how to keep a system up-to-date with each respective branch. [[current]] === Using FreeBSD-CURRENT -FreeBSD-CURRENT is the "bleeding edge" of FreeBSD development and FreeBSD-CURRENT users are expected to have a high degree of technical skill. Less technical users who wish to track a development branch should track FreeBSD-STABLE instead. +FreeBSD-CURRENT is the "bleeding edge" of FreeBSD development and FreeBSD-CURRENT users are expected to have a high degree of technical skill. +Less technical users who wish to track a development branch should track FreeBSD-STABLE instead. -FreeBSD-CURRENT is the very latest source code for FreeBSD and includes works in progress, experimental changes, and transitional mechanisms that might or might not be present in the next official release. While many FreeBSD developers compile the FreeBSD-CURRENT source code daily, there are short periods of time when the source may not be buildable. These problems are resolved as quickly as possible, but whether or not FreeBSD-CURRENT brings disaster or new functionality can be a matter of when the source code was synced. +FreeBSD-CURRENT is the very latest source code for FreeBSD and includes works in progress, experimental changes, and transitional mechanisms that might or might not be present in the next official release. +While many FreeBSD developers compile the FreeBSD-CURRENT source code daily, there are short periods of time when the source may not be buildable. +These problems are resolved as quickly as possible, but whether or not FreeBSD-CURRENT brings disaster or new functionality can be a matter of when the source code was synced. FreeBSD-CURRENT is made available for three primary interest groups: . Members of the FreeBSD community who are actively working on some part of the source tree. . Members of the FreeBSD community who are active testers. They are willing to spend time solving problems, making topical suggestions on changes and the general direction of FreeBSD, and submitting patches. . Users who wish to keep an eye on things, use the current source for reference purposes, or make the occasional comment or code contribution. -FreeBSD-CURRENT should _not_ be considered a fast-track to getting new features before the next release as pre-release features are not yet fully tested and most likely contain bugs. It is not a quick way of getting bug fixes as any given commit is just as likely to introduce new bugs as to fix existing ones. FreeBSD-CURRENT is not in any way "officially supported". +FreeBSD-CURRENT should _not_ be considered a fast-track to getting new features before the next release as pre-release features are not yet fully tested and most likely contain bugs. +It is not a quick way of getting bug fixes as any given commit is just as likely to introduce new bugs as to fix existing ones. +FreeBSD-CURRENT is not in any way "officially supported". To track FreeBSD-CURRENT: -. Join the {freebsd-current} and the {svn-src-head} lists. This is _essential_ in order to see the comments that people are making about the current state of the system and to receive important bulletins about the current state of FreeBSD-CURRENT. +. Join the {freebsd-current} and the {dev-commits-src-main} lists. This is _essential_ in order to see the comments that people are making about the current state of the system and to receive important bulletins about the current state of FreeBSD-CURRENT. + -The {svn-src-head} list records the commit log entry for each change as it is made, along with any pertinent information on possible side effects. +The {dev-commits-src-main} list records the commit log entry for each change as it is made, along with any pertinent information on possible side effects. + -To join these lists, go to {mailman-lists}, click on the list to subscribe to, and follow the instructions. In order to track changes to the whole source tree, not just the changes to FreeBSD-CURRENT, subscribe to the {svn-src-all}. -. Synchronize with the FreeBSD-CURRENT sources. Typically, <> is used to check out the -CURRENT code from the `head` branch of one of the Subversion mirror sites listed in crossref:mirrors[svn-mirrors,“Subversion Mirror Sites”]. +To join these lists, go to {mailman-lists}, click on the list to subscribe to, and follow the instructions. +In order to track changes to the whole source tree, not just the changes to FreeBSD-CURRENT, subscribe to the {dev-commits-src-all}. +. Synchronize with the FreeBSD-CURRENT sources. Typically, `git` is used to check out the -CURRENT code from the `main` branch of one of the Git mirror sites listed in crossref:mirrors[git-mirrors,“Git Mirror Sites”]. . Due to the size of the repository, some users choose to only synchronize the sections of source that interest them or which they are contributing patches to. However, users that plan to compile the operating system from source must download _all_ of FreeBSD-CURRENT, not just selected portions. + -Before compiling FreeBSD-CURRENT , read [.filename]#/usr/src/Makefile# very carefully and follow the instructions in <>. Read the {freebsd-current} and [.filename]#/usr/src/UPDATING# to stay up-to-date on other bootstrapping procedures that sometimes become necessary on the road to the next release. +Before compiling FreeBSD-CURRENT, read [.filename]#/usr/src/Makefile# very carefully and follow the instructions in <>. +Read the {freebsd-current} and [.filename]#/usr/src/UPDATING# to stay up-to-date on other bootstrapping procedures that sometimes become necessary on the road to the next release. . Be active! FreeBSD-CURRENT users are encouraged to submit their suggestions for enhancements or bug fixes. Suggestions with accompanying code are always welcome. [[stable]] === Using FreeBSD-STABLE -FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a slower pace and with the general assumption that they have first been tested in FreeBSD-CURRENT. This is _still_ a development branch and, at any given time, the sources for FreeBSD-STABLE may or may not be suitable for general use. It is simply another engineering development track, not a resource for end-users. Users who do not have the resources to perform testing should instead run the most recent release of FreeBSD. +FreeBSD-STABLE is the development branch from which major releases are made. +Changes go into this branch at a slower pace and with the general assumption that they have first been tested in FreeBSD-CURRENT. +This is _still_ a development branch and, at any given time, the sources for FreeBSD-STABLE may or may not be suitable for general use. +It is simply another engineering development track, not a resource for end-users. +Users who do not have the resources to perform testing should instead run the most recent release of FreeBSD. Those interested in tracking or contributing to the FreeBSD development process, especially as it relates to the next release of FreeBSD, should consider following FreeBSD-STABLE. -While the FreeBSD-STABLE branch should compile and run at all times, this cannot be guaranteed. Since more people run FreeBSD-STABLE than FreeBSD-CURRENT, it is inevitable that bugs and corner cases will sometimes be found in FreeBSD-STABLE that were not apparent in FreeBSD-CURRENT. For this reason, one should not blindly track FreeBSD-STABLE. It is particularly important _not_ to update any production servers to FreeBSD-STABLE without thoroughly testing the code in a development or testing environment. +While the FreeBSD-STABLE branch should compile and run at all times, this cannot be guaranteed. +Since more people run FreeBSD-STABLE than FreeBSD-CURRENT, it is inevitable that bugs and corner cases will sometimes be found in FreeBSD-STABLE that were not apparent in FreeBSD-CURRENT. +For this reason, one should not blindly track FreeBSD-STABLE. +It is particularly important _not_ to update any production servers to FreeBSD-STABLE without thoroughly testing the code in a development or testing environment. To track FreeBSD-STABLE: . Join the {freebsd-stable} in order to stay informed of build dependencies that may appear in FreeBSD-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 being tracked. For example, users tracking the {betarel-current-major}-STABLE branch should join the {dev-commits-src-branches}. This list records the commit log entry for each change as it is made, along with any pertinent information on possible side effects. +Join the relevant git list for the branch being tracked. +For example, users tracking the {betarel-current-major}-STABLE branch should join the {dev-commits-src-branches}. +This list records the commit log entry for each change as it is made, along with any pertinent information on possible side effects. + -To join these lists, go to {mailman-lists}, click on the list to subscribe to, and follow the instructions. In order to track changes for the whole source tree, subscribe to {svn-src-all}. +To join these lists, go to {mailman-lists}, click on the list to subscribe to, and follow the instructions. +In order to track changes for the whole source tree, subscribe to {dev-commits-src-all}. . To install a new FreeBSD-STABLE system, install the most recent FreeBSD-STABLE release from the crossref:mirrors[mirrors,FreeBSD mirror sites] or use a monthly snapshot built from FreeBSD-STABLE. Refer to link:https://www.FreeBSD.org/snapshots/[www.freebsd.org/snapshots] for more information about snapshots. + -To compile or upgrade to an existing FreeBSD system to FreeBSD-STABLE, use crossref:mirrors[svn,svn] to check out the source for the desired branch. Branch names, such as `stable/9`, are listed at link:https://www.FreeBSD.org/releng/[www.freebsd.org/releng]. +To compile or upgrade to an existing FreeBSD system to FreeBSD-STABLE, use `git` to check out the source for the desired branch. Branch names, such as `stable/9`, are listed at link:https://www.FreeBSD.org/releng/[www.freebsd.org/releng]. . Before compiling or upgrading to FreeBSD-STABLE , read [.filename]#/usr/src/Makefile# carefully and follow the instructions in <>. Read the {freebsd-stable} and [.filename]#/usr/src/UPDATING# to keep up-to-date on other bootstrapping procedures that sometimes become necessary on the road to the next release. [[makeworld]] == Updating FreeBSD from Source -Updating FreeBSD by compiling from source offers several advantages over binary updates. Code can be built with options to take advantage of specific hardware. Parts of the base system can be built with non-default settings, or left out entirely where they are not needed or desired. The build process takes longer to update a system than just installing binary updates, but allows complete customization to produce a tailored version of FreeBSD. +Updating FreeBSD by compiling from source offers several advantages over binary updates. +Code can be built with options to take advantage of specific hardware. +Parts of the base system can be built with non-default settings, or left out entirely where they are not needed or desired. +The build process takes longer to update a system than just installing binary updates, but allows complete customization to produce a tailored version of FreeBSD. [[updating-src-quick-start]] === Quick Start This is a quick reference for the typical steps used to update FreeBSD by building from source. Later sections describe the process in more detail. [.procedure] ==== * Update and Build + [source,shell] .... -# svnlite update /usr/src <.> +# git pull /usr/src <.> check /usr/src/UPDATING <.> # cd /usr/src <.> # make -j4 buildworld <.> # make -j4 kernel <.> # shutdown -r now <.> # cd /usr/src <.> # make installworld <.> # mergemaster -Ui <.> # shutdown -r now <.> .... <.> Get the latest version of the source. See <> for more information on obtaining and updating source. <.> Check [.filename]#/usr/src/UPDATING# for any manual steps required before or after building from source. <.> Go to the source directory. <.> Compile the world, everything except the kernel. <.> Compile and install the kernel. This is equivalent to `make buildkernel installkernel`. <.> Reboot the system to the new kernel. <.> Go to the source directory. <.> Install the world. <.> Update and merge configuration files in [.filename]#/etc/#. <.> Restart the system to use the newly-built world and kernel. ==== [[updating-src-preparing]] === Preparing for a Source Update Read [.filename]#/usr/src/UPDATING#. Any manual steps that must be performed before or after an update are described in this file. [[updating-src-obtaining-src]] === Updating the Source -FreeBSD source code is located in [.filename]#/usr/src/#. The preferred method of updating this source is through the Subversion version control system. Verify that the source code is under version control: +FreeBSD source code is located in [.filename]#/usr/src/#. +The preferred method of updating this source is through the Subversion version control system. +Verify that the source code is under version control: [source,shell] .... -# svnlite info /usr/src -Path: /usr/src -Working Copy Root Path: /usr/src -... +# cd /usr/src +# git remote --v +origin ssh://git@gitrepo.FreeBSD.org/doc.git (fetch) +origin ssh://git@gitrepo.FreeBSD.org/doc.git (push) .... -This indicates that [.filename]#/usr/src/# is under version control and can be updated with man:svnlite[1]: +This indicates that [.filename]#/usr/src/# is under version control and can be updated with man:git[1]: [[synching]] [source,shell] .... -# svnlite update /usr/src +# git pull /usr/src .... -The update process can take some time if the directory has not been updated recently. After it finishes, the source code is up to date and the build process described in the next section can begin. +The update process can take some time if the directory has not been updated recently. +After it finishes, the source code is up to date and the build process described in the next section can begin. [NOTE] ==== *Obtaining the Source:* + -If the output says `'/usr/src' is not a working copy`, the files there are missing or were installed with a different method. A new checkout of the source is required. +If the output says `fatal: not a git repository`, the files there are missing or were installed with a different method. +A new checkout of the source is required. [[updating-src-obtaining-src-repopath]] -.FreeBSD Versions and Repository Paths +.FreeBSD Versions and Repository Branchs [cols="10%,10%,80%", options="header"] |=== | uname -r Output | Repository Path | Description |`_X.Y_-RELEASE` -|`base/releng/_X.Y_` +|`releng/_X.Y_` |The Release version plus only critical security and bug fix patches. This branch is recommended for most users. |`_X.Y_-STABLE` -|`base/stable/_X_` +|`stable/_X_` | The Release version plus all additional development on that branch. _STABLE_ refers to the Applications Binary Interface (ABI) not changing, so software compiled for earlier versions still runs. For example, software compiled to run on FreeBSD 10.1 will still run on FreeBSD 10-STABLE compiled later. STABLE branches occasionally have bugs or incompatibilities which might affect users, although these are typically fixed quickly. |`_X_-CURRENT` -|`base/head/` +|`main/` |The latest unreleased development version of FreeBSD. The CURRENT branch can have major bugs or incompatibilities and is recommended only for advanced users. |=== Determine which version of FreeBSD is being used with man:uname[1]: [source,shell] .... # uname -r 10.3-RELEASE .... -Based on <>, the source used to update `10.3-RELEASE` has a repository path of `base/releng/10.3`. That path is used when checking out the source: +Based on <>, the source used to update `10.3-RELEASE` has a repository path of `releng/10.3`. That path is used when checking out the source: [source,shell] .... # mv /usr/src /usr/src.bak <.> -# svnlite checkout https://svn.freebsd.org/base/releng/10.3 /usr/src <.> +# git clone --branch releng/10.3 ssh://git@gitrepo.FreeBSD.org/src.git /usr/src <.> .... <.> Move the old directory out of the way. If there are no local modifications in this directory, it can be deleted. <.> The path from <> is added to the repository URL. The third parameter is the destination directory for the source code on the local system. ==== [[updating-src-building]] === Building from Source -The _world_, or all of the operating system except the kernel, is compiled. This is done first to provide up-to-date tools to build the kernel. Then the kernel itself is built: +The _world_, or all of the operating system except the kernel, is compiled. +This is done first to provide up-to-date tools to build the kernel. Then the kernel itself is built: [source,shell] .... # cd /usr/src # make buildworld # make buildkernel .... The compiled code is written to [.filename]#/usr/obj#. These are the basic steps. Additional options to control the build are described below. [[updating-src-building-clean-build]] ==== Performing a Clean Build -Some versions of the FreeBSD build system leave previously-compiled code in the temporary object directory, [.filename]#/usr/obj#. This can speed up later builds by avoiding recompiling code that has not changed. To force a clean rebuild of everything, use `cleanworld` before starting a build: +Some versions of the FreeBSD build system leave previously-compiled code in the temporary object directory, [.filename]#/usr/obj#. +This can speed up later builds by avoiding recompiling code that has not changed. +To force a clean rebuild of everything, use `cleanworld` before starting a build: [source,shell] .... # make cleanworld .... [[updating-src-building-jobs]] ==== Setting the Number of Jobs -Increasing the number of build jobs on multi-core processors can improve build speed. Determine the number of cores with `sysctl hw.ncpu`. Processors vary, as do the build systems used with different versions of FreeBSD, so testing is the only sure method to tell how a different number of jobs affects the build speed. For a starting point, consider values between half and double the number of cores. The number of jobs is specified with `-j`. +Increasing the number of build jobs on multi-core processors can improve build speed. +Determine the number of cores with `sysctl hw.ncpu`. +Processors vary, as do the build systems used with different versions of FreeBSD, so testing is the only sure method to tell how a different number of jobs affects the build speed. +For a starting point, consider values between half and double the number of cores. +The number of jobs is specified with `-j`. [[updating-src-building-jobs-example]] .Increasing the Number of Build Jobs [example] ==== Building the world and kernel with four jobs: [source,shell] .... # make -j4 buildworld buildkernel .... ==== [[updating-src-building-only-kernel]] ==== Building Only the Kernel -A `buildworld` must be completed if the source code has changed. After that, a `buildkernel` to build a kernel can be run at any time. To build just the kernel: +A `buildworld` must be completed if the source code has changed. +After that, a `buildkernel` to build a kernel can be run at any time. +To build just the kernel: [source,shell] .... # cd /usr/src # make buildkernel .... [[updating-src-building-custom-kernel]] ==== Building a Custom Kernel -The standard FreeBSD kernel is based on a _kernel config file_ called [.filename]#GENERIC#. The [.filename]#GENERIC# kernel includes the most commonly-needed device drivers and options. Sometimes it is useful or necessary to build a custom kernel, adding or removing device drivers or options to fit a specific need. +The standard FreeBSD kernel is based on a _kernel config file_ called [.filename]#GENERIC#. +The [.filename]#GENERIC# kernel includes the most commonly-needed device drivers and options. +Sometimes it is useful or necessary to build a custom kernel, adding or removing device drivers or options to fit a specific need. For example, someone developing a small embedded computer with severely limited RAM could remove unneeded device drivers or options to make the kernel slightly smaller. -Kernel config files are located in [.filename]#/usr/src/sys/arch/conf/#, where _arch_ is the output from `uname -m`. On most computers, that is `amd64`, giving a config file directory of [.filename]#/usr/src/sys/amd64/conf/#. +Kernel config files are located in [.filename]#/usr/src/sys/arch/conf/#, where _arch_ is the output from `uname -m`. +On most computers, that is `amd64`, giving a config file directory of [.filename]#/usr/src/sys/amd64/conf/#. [TIP] ==== - -[.filename]#/usr/src# can be deleted or recreated, so it is preferable to keep custom kernel config files in a separate directory, like [.filename]#/root#. Link the kernel config file into the [.filename]#conf# directory. If that directory is deleted or overwritten, the kernel config can be re-linked into the new one. +[.filename]#/usr/src# can be deleted or recreated, so it is preferable to keep custom kernel config files in a separate directory, like [.filename]#/root#. +Link the kernel config file into the [.filename]#conf# directory. +If that directory is deleted or overwritten, the kernel config can be re-linked into the new one. ==== -A custom config file can be created by copying the [.filename]#GENERIC# config file. In this example, the new custom kernel is for a storage server, so is named [.filename]#STORAGESERVER#: +A custom config file can be created by copying the [.filename]#GENERIC# config file. +In this example, the new custom kernel is for a storage server, so is named [.filename]#STORAGESERVER#: [source,shell] .... # cp /usr/src/sys/amd64/conf/GENERIC /root/STORAGESERVER # cd /usr/src/sys/amd64/conf # ln -s /root/STORAGESERVER . .... [.filename]#/root/STORAGESERVER# is then edited, adding or removing devices or options as shown in man:config[5]. The custom kernel is built by setting `KERNCONF` to the kernel config file on the command line: [source,shell] .... # make buildkernel KERNCONF=STORAGESERVER .... [[updating-src-installing]] === Installing the Compiled Code After the `buildworld` and `buildkernel` steps have been completed, the new kernel and world are installed: [source,shell] .... # cd /usr/src # make installkernel # shutdown -r now # cd /usr/src # make installworld # shutdown -r now .... If a custom kernel was built, `KERNCONF` must also be set to use the new custom kernel: [source,shell] .... # cd /usr/src # make installkernel KERNCONF=STORAGESERVER # shutdown -r now # cd /usr/src # make installworld # shutdown -r now .... [[updating-src-completing]] === Completing the Update -A few final tasks complete the update. Any modified configuration files are merged with the new versions, outdated libraries are located and removed, then the system is restarted. +A few final tasks complete the update. +Any modified configuration files are merged with the new versions, outdated libraries are located and removed, then the system is restarted. [[updating-src-completing-merge-mergemaster]] ==== Merging Configuration Files with man:mergemaster[8] man:mergemaster[8] provides an easy way to merge changes that have been made to system configuration files with new versions of those files. With `-Ui`, man:mergemaster[8] automatically updates files that have not been user-modified and installs new files that are not already present: [source,shell] .... # mergemaster -Ui .... -If a file must be manually merged, an interactive display allows the user to choose which portions of the files are kept. See man:mergemaster[8] for more information. +If a file must be manually merged, an interactive display allows the user to choose which portions of the files are kept. +See man:mergemaster[8] for more information. [[updating-src-completing-check-old]] ==== Checking for Outdated Files and Libraries -Some obsolete files or directories can remain after an update. These files can be located: +Some obsolete files or directories can remain after an update. +These files can be located: [source,shell] .... # make check-old .... and deleted: [source,shell] .... # make delete-old .... -Some obsolete libraries can also remain. These can be detected with: +Some obsolete libraries can also remain. +These can be detected with: [source,shell] .... # make check-old-libs .... and deleted with [source,shell] .... # make delete-old-libs .... -Programs which were still using those old libraries will stop working when the library has been deleted. These programs must be rebuilt or replaced after deleting the old libraries. +Programs which were still using those old libraries will stop working when the library has been deleted. +These programs must be rebuilt or replaced after deleting the old libraries. [TIP] ==== - -When all the old files or directories are known to be safe to delete, pressing kbd:[y] and kbd:[Enter] to delete each file can be avoided by setting `BATCH_DELETE_OLD_FILES` in the command. For example: +When all the old files or directories are known to be safe to delete, +pressing kbd:[y] and kbd:[Enter] to delete each file can be avoided by setting `BATCH_DELETE_OLD_FILES` in the command. +For example: [source,shell] .... # make BATCH_DELETE_OLD_FILES=yes delete-old-libs .... ==== [[updating-src-completing-restart]] ==== Restarting After the Update The last step after updating is to restart the computer so all the changes take effect: [source,shell] .... # shutdown -r now .... [[small-lan]] == Tracking for Multiple Machines -When multiple machines need to track the same source tree, it is a waste of disk space, network bandwidth, and CPU cycles to have each system download the sources and rebuild everything. 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. For more information about using NFS, refer to crossref:network-servers[network-nfs,"Network File System (NFS)"]. - -First, identify a set of machines which will run the same set of binaries, known as a _build set_. Each machine can have a custom kernel, but will run the same userland binaries. From that set, choose a machine to be the _build machine_ that the world and kernel are built on. Ideally, this is a fast machine that has sufficient spare CPU to run `make buildworld` and `make buildkernel`. - -Select a machine to be the _test machine_, which will test software updates before they are put into production. This _must_ be a machine that can afford to be 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 [.filename]#/usr/obj# and [.filename]#/usr/src# from the build machine via NFS. For multiple build sets, [.filename]#/usr/src# should be on one build machine, and NFS mounted on the rest. - -Ensure that [.filename]#/etc/make.conf# and [.filename]#/etc/src.conf# on all the machines in the build set agree 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 [.filename]#/etc/make.conf#, and the build machine should list them all in its `KERNCONF`, listing its own kernel first. The build machine must have the kernel configuration files for each machine in its [.filename]#/usr/src/sys/arch/conf#. - -On the build machine, build the kernel and world as described in <>, but do not install anything on the build machine. Instead, install the built kernel on the test machine. On the test machine, mount [.filename]#/usr/src# and [.filename]#/usr/obj# via NFS. Then, run `shutdown now` to go to single-user mode in order to install the new kernel and world and run `mergemaster` as usual. When done, reboot to return to normal multi-user operations. - -After verifying 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. - -The same methodology can be used for the ports tree. The first step is to share [.filename]#/usr/ports# via NFS to all the machines in the build set. To configure [.filename]#/etc/make.conf# to share distfiles, set `DISTDIR` to a common shared directory that is writable by whichever user `root` is mapped to by the NFS mount. Each machine should set `WRKDIRPREFIX` to a local build directory, if ports are to be built locally. Alternately, if the build system is to build and distribute packages to the machines in the build set, set `PACKAGES` on the build system to a directory similar to `DISTDIR`. +When multiple machines need to track the same source tree, +it is a waste of disk space, network bandwidth, +and CPU cycles to have each system download the sources and rebuild everything. +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. +For more information about using NFS, refer to crossref:network-servers[network-nfs,"Network File System (NFS)"]. + +First, identify a set of machines which will run the same set of binaries, known as a _build set_. +Each machine can have a custom kernel, but will run the same userland binaries. +From that set, choose a machine to be the _build machine_ that the world and kernel are built on. +Ideally, this is a fast machine that has sufficient spare CPU to run `make buildworld` and `make buildkernel`. + +Select a machine to be the _test machine_, which will test software updates before they are put into production. +This _must_ be a machine that can afford to be 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 [.filename]#/usr/obj# and [.filename]#/usr/src# from the build machine via NFS. +For multiple build sets, [.filename]#/usr/src# should be on one build machine, and NFS mounted on the rest. + +Ensure that [.filename]#/etc/make.conf# and [.filename]#/etc/src.conf# on all the machines in the build set agree 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 [.filename]#/etc/make.conf#, +and the build machine should list them all in its `KERNCONF`, listing its own kernel first. +The build machine must have the kernel configuration files for each machine in its [.filename]#/usr/src/sys/arch/conf#. + +On the build machine, build the kernel and world as described in <>, +but do not install anything on the build machine. +Instead, install the built kernel on the test machine. +On the test machine, mount [.filename]#/usr/src# and [.filename]#/usr/obj# via NFS. +Then, run `shutdown now` to go to single-user mode in order to install the new kernel and world and run `mergemaster` as usual. +When done, reboot to return to normal multi-user operations. + +After verifying 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. + +The same methodology can be used for the ports tree. +The first step is to share [.filename]#/usr/ports# via NFS to all the machines in the build set. +To configure [.filename]#/etc/make.conf# to share distfiles, +set `DISTDIR` to a common shared directory that is writable by whichever user `root` is mapped to by the NFS mount. +Each machine should set `WRKDIRPREFIX` to a local build directory, if ports are to be built locally. +Alternately, if the build system is to build and distribute packages to the machines in the build set, +set `PACKAGES` on the build system to a directory similar to `DISTDIR`. diff --git a/documentation/content/en/books/handbook/mirrors/_index.adoc b/documentation/content/en/books/handbook/mirrors/_index.adoc index 3feb119a5e..f50f683c8f 100644 --- a/documentation/content/en/books/handbook/mirrors/_index.adoc +++ b/documentation/content/en/books/handbook/mirrors/_index.adoc @@ -1,598 +1,606 @@ --- title: Appendix A. Obtaining FreeBSD part: Part V. Appendices prev: books/handbook/partv next: books/handbook/bibliography --- [appendix] [[mirrors]] = Obtaining FreeBSD :doctype: book :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :skip-front-matter: :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :sectnumoffset: A include::shared/mirrors.adoc[] include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/en/mailing-lists.adoc[] include::shared/en/teams.adoc[] include::shared/en/urls.adoc[] [[mirrors-cdrom]] == CD and DVD Sets FreeBSD CD and DVD sets are available from several online retailers: * FreeBSD Mall, Inc. + 2420 Sand Creek Rd C-1 #347 + Brentwood, CA + 94513 + USA + Phone: +1 925 240-6652 + Fax: +1 925 674-0821 + Email: + WWW: https://www.freebsdmall.com * Getlinux + 78 Rue de la Croix Rochopt + Épinay-sous-Sénart + 91860 + France + Email: + WWW: http://www.getlinux.fr/ * Dr. Hinner EDV + Kochelseestr. 11 + D-81371 München + Germany + Phone: (0177) 428 419 0 + Email: + WWW: http://www.hinner.de/linux/freebsd.html * Linux Center + Galernaya Street, 55 + Saint-Petersburg + 190000 + Russia + Phone: +7-812-309-06-86 + Email: + WWW: http://linuxcenter.ru/shop/freebsd [[mirrors-ftp]] == FTP Sites The official sources for FreeBSD are available via anonymous FTP from a worldwide set of mirror sites. The site link:ftp://ftp.FreeBSD.org/pub/FreeBSD/[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, FreeBSD is available via anonymous FTP from the following mirror sites. When obtaining FreeBSD via anonymous FTP, please try to use a nearby site. The mirror sites listed as "Primary Mirror Sites" typically have the entire FreeBSD 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 FreeBSD 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. <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>, <>. (as of UTC) [[central]] *{central}* {central-ftp} (ftp / ftpv6 / {central-http} / {central-httpv6}) [[primary]] *{mirrors-primary}* In case of problems, please contact the hostmaster `<{mirrors-primary-email}>` for this domain. * {mirrors-primary-ftp1} (ftp) * {mirrors-primary-ftp2} (ftp) * {mirrors-primary-ftp3} (ftp) * {mirrors-primary-ftp4} (ftp / ftpv6 / {mirrors-primary-ftp4-http} / {mirrors-primary-ftp4-httpv6}) * {mirrors-primary-ftp5} (ftp) * {mirrors-primary-ftp6} (ftp) * {mirrors-primary-ftp7} (ftp) * {mirrors-primary-ftp10} (ftp / ftpv6 / {mirrors-primary-ftp10-http} / {mirrors-primary-ftp10-httpv6}) * {mirrors-primary-ftp11} (ftp) * {mirrors-primary-ftp13} (ftp) * {mirrors-primary-ftp14} (ftp / {mirrors-primary-ftp14-http}) [[armenia]] *{mirrors-armenia}* In case of problems, please contact the hostmaster `<{mirrors-armenia-email}>` for this domain. * {mirrors-armenia-ftp} (ftp / {mirrors-armenia-ftp-http} / rsync) [[australia]] *{mirrors-australia}* In case of problems, please contact the hostmaster `<{mirrors-australia-email}>` for this domain. * {mirrors-australia-ftp} (ftp) * {mirrors-australia-ftp2} (ftp) * {mirrors-australia-ftp3} (ftp) [[austria]] *{mirrors-austria}* In case of problems, please contact the hostmaster `<{mirrors-austria-email}>` for this domain. * {mirrors-austria-ftp} (ftp / ftpv6 / {mirrors-austria-ftp-http} / {mirrors-austria-ftp-httpv6}) [[brazil]] *{mirrors-brazil}* In case of problems, please contact the hostmaster `<{mirrors-brazil-email}>` for this domain. * {mirrors-brazil-ftp2} (ftp / {mirrors-brazil-ftp2-http}) * {mirrors-brazil-ftp3} (ftp / rsync) * {mirrors-brazil-ftp4} (ftp) [[czech-republic]] *{mirrors-czech}* In case of problems, please contact the hostmaster `<{mirrors-czech-email}>` for this domain. * {mirrors-czech-ftp} (ftp / {mirrors-czech-ftpv6} / {mirrors-czech-ftp-http} / {mirrors-czech-ftp-httpv6} / rsync / rsyncv6) * {mirrors-czech-ftp2} (ftp / {mirrors-czech-ftp2-http}) [[denmark]] *{mirrors-denmark}* In case of problems, please contact the hostmaster `<{mirrors-denmark-email}>` for this domain. * {mirrors-denmark-ftp} (ftp / ftpv6 / {mirrors-denmark-ftp-http} / {mirrors-denmark-ftp-httpv6}) [[estonia]] *{mirrors-estonia}* In case of problems, please contact the hostmaster `<{mirrors-estonia-email}>` for this domain. * {mirrors-estonia-ftp} (ftp) [[finland]] *{mirrors-finland}* In case of problems, please contact the hostmaster `<{mirrors-finland-email}>` for this domain. * {mirrors-finland-ftp} (ftp) [[france]] *{mirrors-france}* In case of problems, please contact the hostmaster `<{mirrors-france-email}>` for this domain. * {mirrors-france-ftp} (ftp) * {mirrors-france-ftp1} (ftp / {mirrors-france-ftp1-http} / rsync) * {mirrors-france-ftp3} (ftp) * {mirrors-france-ftp5} (ftp) * {mirrors-france-ftp6} (ftp / rsync) * {mirrors-france-ftp7} (ftp) * {mirrors-france-ftp8} (ftp) [[germany]] *{mirrors-germany}* In case of problems, please contact the hostmaster `<{mirrors-germany-email}>` for this domain. * ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ (ftp) * ftp://ftp1.de.FreeBSD.org/freebsd/ (ftp / http://www1.de.FreeBSD.org/freebsd/ / rsync://rsync3.de.FreeBSD.org/freebsd/) * ftp://ftp2.de.FreeBSD.org/pub/FreeBSD/ (ftp / http://ftp2.de.FreeBSD.org/pub/FreeBSD/ / rsync) * ftp://ftp4.de.FreeBSD.org/FreeBSD/ (ftp / http://ftp4.de.FreeBSD.org/pub/FreeBSD/) * ftp://ftp5.de.FreeBSD.org/pub/FreeBSD/ (ftp) * ftp://ftp7.de.FreeBSD.org/pub/FreeBSD/ (ftp / http://ftp7.de.FreeBSD.org/pub/FreeBSD/) * ftp://ftp8.de.FreeBSD.org/pub/FreeBSD/ (ftp) [[greece]] *{mirrors-greece}* In case of problems, please contact the hostmaster `<{mirrors-greece-email}>` for this domain. * {mirrors-greece-ftp} (ftp) * {mirrors-greece-ftp2} (ftp) [[hong-kong]] *{mirrors-hongkong}* {mirrors-hongkong-ftp} (ftp) [[ireland]] *{mirrors-ireland}* In case of problems, please contact the hostmaster `<{mirrors-ireland-email}>` for this domain. * {mirrors-ireland-ftp} (ftp / rsync) [[japan]] *{mirrors-japan}* In case of problems, please contact the hostmaster `<{mirrors-japan-email}>` for this domain. * {mirrors-japan-ftp} (ftp) * {mirrors-japan-ftp2} (ftp) * {mirrors-japan-ftp3} (ftp) * {mirrors-japan-ftp4} (ftp) * {mirrors-japan-ftp5} (ftp) * {mirrors-japan-ftp6} (ftp) * {mirrors-japan-ftp7} (ftp) * {mirrors-japan-ftp8} (ftp) * {mirrors-japan-ftp9} (ftp) [[korea]] *{mirrors-korea}* In case of problems, please contact the hostmaster `<{mirrors-korea-email}>` for this domain. * {mirrors-korea-ftp} (ftp / rsync) * {mirrors-korea-ftp2} (ftp / {mirrors-korea-ftp2-http}) [[latvia]] *{mirrors-latvia}* In case of problems, please contact the hostmaster `<{mirrors-latvia-email}>` for this domain. * {mirrors-latvia-ftp} (ftp / {mirrors-latvia-ftp-http}) [[lithuania]] *{mirrors-lithuania}* In case of problems, please contact the hostmaster `<{mirrors-lithuania-email}>` for this domain. * {mirrors-lithuania-ftp} (ftp / {mirrors-lithuania-ftp-http}) [[netherlands]] *{mirrors-netherlands}* In case of problems, please contact the hostmaster `<{mirrors-netherlands-email}>` for this domain. * {mirrors-netherlands-ftp} (ftp / {mirrors-netherlands-ftp-http} / rsync) * {mirrors-netherlands-ftp2} (ftp) [[new-zealand]] *{mirrors-new-zealand}* * {mirrors-new-zealand-ftp} (ftp / {mirrors-new-zealand-ftp-http}) [[norway]] *{mirrors-norway}* In case of problems, please contact the hostmaster `<{mirrors-norway-email}>` for this domain. * {mirrors-norway-ftp} (ftp / rsync) [[poland]] *{mirrors-poland}* In case of problems, please contact the hostmaster `<{mirrors-poland-email}>` for this domain. * {mirrors-poland-ftp} (ftp) * ftp2.pl.FreeBSD.org [[russia]] *{mirrors-russia}* In case of problems, please contact the hostmaster `<{mirrors-russia-email}>` for this domain. * {mirrors-russia-ftp} (ftp / {mirrors-russia-ftp-http} / rsync) * {mirrors-russia-ftp2} (ftp / {mirrors-russia-ftp2-http} / rsync) * {mirrors-russia-ftp4} (ftp) * {mirrors-russia-ftp5} (ftp / {mirrors-russia-ftp5-http} / rsync) * {mirrors-russia-ftp6} (ftp) [[saudi-arabia]] *{mirrors-saudi-arabia}* In case of problems, please contact the hostmaster `<{mirrors-saudi-arabia-email}>` for this domain. * {mirrors-saudi-arabia-ftp} (ftp) [[slovenia]] *{mirrors-slovenia}* In case of problems, please contact the hostmaster `<{mirrors-slovenia-email}>` for this domain. * {mirrors-slovenia-ftp} (ftp) [[south-africa]] *{mirrors-south-africa}* In case of problems, please contact the hostmaster `<{mirrors-south-africa-email}>` for this domain. * {mirrors-south-africa-ftp} (ftp) * {mirrors-south-africa-ftp2} (ftp) * {mirrors-south-africa-ftp4} (ftp) [[spain]] *{mirrors-spain}* In case of problems, please contact the hostmaster `<{mirrors-spain-email}>` for this domain. * {mirrors-spain-ftp} (ftp / {mirrors-spain-ftp-http}) * {mirrors-spain-ftp3} (ftp) [[sweden]] *{mirrors-sweden}* In case of problems, please contact the hostmaster `<{mirrors-sweden-email}>` for this domain. * {mirrors-sweden-ftp} (ftp) * {mirrors-sweden-ftp2} (ftp / {mirrors-sweden-ftp2-rsync}) * {mirrors-sweden-ftp3} (ftp) * {mirrors-sweden-ftp4} (ftp / {mirrors-sweden-ftp4v6} / {mirrors-sweden-ftp4-http} / {mirrors-sweden-ftp4-httpv6} / {mirrors-sweden-ftp4-rsync} / {mirrors-sweden-ftp4-rsyncv6}) * {mirrors-sweden-ftp6} (ftp / {mirrors-sweden-ftp6-http}) [[switzerland]] *{mirrors-switzerland}* In case of problems, please contact the hostmaster `<{mirrors-switzerland-email}>` for this domain. * {mirrors-switzerland-ftp} (ftp / {mirrors-switzerland-ftp-http}) [[taiwan]] *{mirrors-taiwan}* In case of problems, please contact the hostmaster `<{mirrors-taiwan-email}>` for this domain. * {mirrors-taiwan-ftp} (ftp / {mirrors-taiwan-ftpv6} / rsync / rsyncv6) * {mirrors-taiwan-ftp2} (ftp / {mirrors-taiwan-ftp2v6} / {mirrors-taiwan-ftp2-http} / {mirrors-taiwan-ftp2-httpv6} / rsync / rsyncv6) * {mirrors-taiwan-ftp4} (ftp) * {mirrors-taiwan-ftp5} (ftp) * {mirrors-taiwan-ftp6} (ftp / {mirrors-taiwan-ftp6v6} / rsync) * {mirrors-taiwan-ftp7} (ftp) * {mirrors-taiwan-ftp8} (ftp) * {mirrors-taiwan-ftp11} (ftp / {mirrors-taiwan-ftp11-http}) * {mirrors-taiwan-ftp12} (ftp) * {mirrors-taiwan-ftp13} (ftp) * {mirrors-taiwan-ftp14} (ftp) * {mirrors-taiwan-ftp15} (ftp) [[ukraine]] *{mirrors-ukraine}* * {mirrors-ukraine-ftp} (ftp / {mirrors-ukraine-ftp-http}) * {mirrors-ukraine-ftp6} (ftp / {mirrors-ukraine-ftp6-http} / {mirrors-ukraine-ftp6-rsync}) * {mirrors-ukraine-ftp7} (ftp) [[uk]] *{mirrors-uk}* In case of problems, please contact the hostmaster `<{mirrors-uk-email}>` for this domain. * {mirrors-uk-ftp} (ftp) * {mirrors-uk-ftp2} (ftp / {mirrors-uk-ftp2-rsync}) * {mirrors-uk-ftp3} (ftp) * {mirrors-uk-ftp4} (ftp) * {mirrors-uk-ftp5} (ftp) [[usa]] *{mirrors-us}* In case of problems, please contact the hostmaster `<{mirrors-us-email}>` for this domain. * {mirrors-us-ftp} (ftp) * {mirrors-us-ftp2} (ftp) * {mirrors-us-ftp3} (ftp) * {mirrors-us-ftp4} (ftp / ftpv6 / {mirrors-us-ftp4-http} / {mirrors-us-ftp4-httpv6}) * {mirrors-us-ftp5} (ftp) * {mirrors-us-ftp6} (ftp) * {mirrors-us-ftp8} (ftp) * {mirrors-us-ftp10} (ftp) * {mirrors-us-ftp11} (ftp) * {mirrors-us-ftp13} (ftp / {mirrors-us-ftp13-http} / rsync) * {mirrors-us-ftp14} (ftp / {mirrors-us-ftp14-http}) * {mirrors-us-ftp15} (ftp) [[svn]] == Using Subversion [[svn-intro]] === Introduction As of July 2012, FreeBSD uses Subversion as the only version control system for storing all of FreeBSD's source code, documentation, and the Ports Collection. [NOTE] ==== Subversion is generally a developer tool. Users may prefer to use `freebsd-update` (crossref:cutting-edge[updating-upgrading-freebsdupdate,“FreeBSD Update”]) to update the FreeBSD base system, and `portsnap` (crossref:ports[ports-using,“Using the Ports Collection”]) to update the FreeBSD Ports Collection. ==== This section demonstrates how to install Subversion on a FreeBSD system and use it to create a local copy of a FreeBSD repository. Additional information on the use of Subversion is included. [[svn-ssl-certificates]] === Root SSL Certificates Installing package:security/ca_root_nss[] allows Subversion to verify the identity of HTTPS repository servers. The root SSL certificates can be installed from a port: [source,shell] .... # cd /usr/ports/security/ca_root_nss # make install clean .... or as a package: [source,shell] .... # pkg install ca_root_nss .... [[svn-svnlite]] === Svnlite A lightweight version of Subversion is already installed on FreeBSD 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`. [[svn-install]] === 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: [source,shell] .... # cd /usr/ports/devel/subversion # make install clean .... Subversion can also be installed as a package: [source,shell] .... # pkg install subversion .... [[svn-usage]] === Running Subversion 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_. [WARNING] ==== - 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 FreeBSD repository to access. There are three different repositories, `base` for the FreeBSD 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: [source,shell] .... # 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 [.filename]#/usr/ports# for `ports`, [.filename]#/usr/src# for `base`, and [.filename]#/usr/doc# for `doc`. This example checks out the Ports Collection from the FreeBSD repository using the HTTPS protocol, placing the local working copy in [.filename]#/usr/ports#. If [.filename]#/usr/ports# is already present but was not created by `svn`, remember to rename or delete it before the checkout. [source,shell] .... # 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: [source,shell] .... # svn update lwcdir .... To update [.filename]#/usr/ports# created in the example above, use: [source,shell] .... # 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 [.filename]#Makefile# in the [.filename]#/usr/ports#, [.filename]#/usr/src#, and [.filename]#/usr/doc# directories. Set `SVN_UPDATE` and use the `update` target. For example, to update [.filename]#/usr/src#: [source,shell] .... # cd /usr/src # make update SVN_UPDATE=yes .... +[[git-mirrors]] +=== Git Mirror Sites + +The FreeBSD Git repository is: + +[.programlisting] +.... +https://git.freebsd.org/ +.... + +This is a publicly accessible mirror network that uses GeoDNS to select an appropriate back end server. +To view the FreeBSD Subversion repositories through a browser, use https://cgit.freebsd.org[https://cgit.freebsd.org]. + [[svn-mirrors]] === Subversion Mirror Sites The FreeBSD Subversion repository is: [.programlisting] .... svn.FreeBSD.org .... This is a publicly accessible mirror network that uses GeoDNS to select an appropriate back end server. To view the FreeBSD Subversion repositories through a browser, use https://svnweb.FreeBSD.org/[https://svnweb.FreeBSD.org/]. HTTPS is the preferred protocol, but the [.filename]#security/ca_root_nss# package will need to be installed in order to automatically validate certificates. === For More Information For other information about using Subversion, please see the "Subversion Book", titled http://svnbook.red-bean.com/[Version Control with Subversion], or the http://subversion.apache.org/docs/[Subversion Documentation]. [[mirrors-rsync]] == Using rsync These sites make FreeBSD available through the rsync protocol. The rsync utility transfers only the differences between two sets of files. This is useful for mirror sites of the FreeBSD FTP server. The rsync suite is available for many operating systems, on FreeBSD, see the package:net/rsync[] port or use the package. Czech Republic:: rsync://ftp.cz.FreeBSD.org/ + Available collections: ** ftp: A partial mirror of the FreeBSD FTP server. ** FreeBSD: A full mirror of the FreeBSD FTP server. Netherlands:: rsync://ftp.nl.FreeBSD.org/ + Available collections: ** FreeBSD: A full mirror of the FreeBSD FTP server. Russia:: rsync://ftp.mtu.ru/ + Available collections: ** FreeBSD: A full mirror of the FreeBSD FTP server. ** FreeBSD-Archive: The mirror of FreeBSD Archive FTP server. Sweden:: rsync://ftp4.se.freebsd.org/ + Available collections: ** FreeBSD: A full mirror of the FreeBSD FTP server. Taiwan:: rsync://ftp.tw.FreeBSD.org/ + rsync://ftp2.tw.FreeBSD.org/ + rsync://ftp6.tw.FreeBSD.org/ + Available collections: ** FreeBSD: A full mirror of the FreeBSD FTP server. United Kingdom:: rsync://rsync.mirrorservice.org/ + Available collections: ** ftp.freebsd.org: A full mirror of the FreeBSD FTP server. United States of America:: rsync://ftp-master.FreeBSD.org/ + This server may only be used by FreeBSD primary mirror sites. + Available collections: ** FreeBSD: The master archive of the FreeBSD FTP server. ** acl: The FreeBSD master ACL list. + rsync://ftp13.FreeBSD.org/ + Available collections: ** FreeBSD: A full mirror of the FreeBSD FTP server. - -:sectnums: -:sectnumlevels: 6