diff --git a/documentation/content/de/books/handbook/_index.adoc b/documentation/content/de/books/handbook/_index.adoc index 46ff43a924..93dd04826a 100644 --- a/documentation/content/de/books/handbook/_index.adoc +++ b/documentation/content/de/books/handbook/_index.adoc @@ -1,53 +1,53 @@ --- title: FreeBSD Handbuch authors: - author: The FreeBSD Documentation Project copyright: 1995-2020 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] next: books/handbook/preface showBookMenu: true weight: 0 path: "/books/handbook/" --- = FreeBSD Handbuch :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Zusammenfassung Willkommen bei FreeBSD! Dieses Handbuch beschreibt die Installation und den täglichen Umgang mit _FreeBSD {rel121-current}-RELEASE_, _FreeBSD {rel113-current}-RELEASE_. Das Handbuch ist das Ergebnis einer fortlaufenden Arbeit vieler Einzelpersonen. Dies kann dazu führen, dass einige Abschnitte nicht aktuell sind. Bei Unklarheiten empfiehlt es sich daher stets, die extref:{handbook}[englische Originalversion] des Handbuchs zu lesen. Wenn Sie bei der Übersetzung des Handbuchs mithelfen möchten, senden Sie bitte eine E-Mail an die Mailingliste {de-doc}. -Die aktuelle Version des Handbuchs ist immer auf dem https://www.FreeBSD.org/[FreeBSD-Webserver] verfügbar und kann in verschiedenen Formaten und in komprimierter Form vom https://download.freebsd.org/ftp/doc[FreeBSD FTP-Server] oder einem der vielen <> herunter geladen werden (ältere Versionen finden Sie hingegen unter https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]). Gedruckte Kopien können bei https://www.freebsdmall.com/[FreeBSD Mall] erworben werden. Vielleicht möchten Sie das Handbuch oder andere Dokumente auch link:https://www.FreeBSD.org/search/[durchsuchen]. +Die aktuelle Version des Handbuchs ist immer auf dem https://www.FreeBSD.org/[FreeBSD-Webserver] verfügbar und kann in verschiedenen Formaten und in komprimierter Form vom https://download.freebsd.org/doc[FreeBSD FTP-Server] oder einem der vielen <> herunter geladen werden (ältere Versionen finden Sie hingegen unter https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]). Gedruckte Kopien können bei https://www.freebsdmall.com/[FreeBSD Mall] erworben werden. Vielleicht möchten Sie das Handbuch oder andere Dokumente auch link:https://www.FreeBSD.org/search/[durchsuchen]. ''' diff --git a/documentation/content/de/books/handbook/book.adoc b/documentation/content/de/books/handbook/book.adoc index 7c8b58de45..e9e34cdddc 100644 --- a/documentation/content/de/books/handbook/book.adoc +++ b/documentation/content/de/books/handbook/book.adoc @@ -1,116 +1,116 @@ --- title: FreeBSD Handbuch authors: - author: The FreeBSD Documentation Project copyright: 1995-2020 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] add_split_page_link: true --- = FreeBSD Handbuch :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] [abstract] Zusammenfassung Willkommen bei FreeBSD! Dieses Handbuch beschreibt die Installation und den täglichen Umgang mit _FreeBSD {rel121-current}-RELEASE_, _FreeBSD {rel113-current}-RELEASE_. Das Handbuch ist das Ergebnis einer fortlaufenden Arbeit vieler Einzelpersonen. Dies kann dazu führen, dass einige Abschnitte nicht aktuell sind. Bei Unklarheiten empfiehlt es sich daher stets, die extref:{handbook}[englische Originalversion] des Handbuchs zu lesen. Wenn Sie bei der Übersetzung des Handbuchs mithelfen möchten, senden Sie bitte eine E-Mail an die Mailingliste {de-doc}. -Die aktuelle Version des Handbuchs ist immer auf dem https://www.FreeBSD.org/[FreeBSD-Webserver] verfügbar und kann in verschiedenen Formaten und in komprimierter Form vom https://download.freebsd.org/ftp/doc[FreeBSD FTP-Server] oder einem der vielen <> herunter geladen werden (ältere Versionen finden Sie hingegen unter https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]). Gedruckte Kopien können bei https://www.freebsdmall.com/[FreeBSD Mall] erworben werden. Vielleicht möchten Sie das Handbuch oder andere Dokumente auch link:https://www.FreeBSD.org/search/[durchsuchen]. +Die aktuelle Version des Handbuchs ist immer auf dem https://www.FreeBSD.org/[FreeBSD-Webserver] verfügbar und kann in verschiedenen Formaten und in komprimierter Form vom https://download.freebsd.org/doc[FreeBSD FTP-Server] oder einem der vielen <> herunter geladen werden (ältere Versionen finden Sie hingegen unter https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]). Gedruckte Kopien können bei https://www.freebsdmall.com/[FreeBSD Mall] erworben werden. Vielleicht möchten Sie das Handbuch oder andere Dokumente auch link:https://www.FreeBSD.org/search/[durchsuchen]. ''' toc::[] :sectnums!: include::{chapters-path}preface/_index.adoc[leveloffset=+1] :sectnums: // Section one include::{chapters-path}parti.adoc[lines=7..8] include::{chapters-path}introduction/_index.adoc[leveloffset=+1] include::{chapters-path}bsdinstall/_index.adoc[leveloffset=+1] include::{chapters-path}basics/_index.adoc[leveloffset=+1] include::{chapters-path}ports/_index.adoc[leveloffset=+1] include::{chapters-path}x11/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[lines=7..8] include::{chapters-path}desktop/_index.adoc[leveloffset=+1] include::{chapters-path}multimedia/_index.adoc[leveloffset=+1] include::{chapters-path}kernelconfig/_index.adoc[leveloffset=+1] include::{chapters-path}printing/_index.adoc[leveloffset=+1] include::{chapters-path}linuxemu/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[lines=7..8] include::{chapters-path}config/_index.adoc[leveloffset=+1] include::{chapters-path}boot/_index.adoc[leveloffset=+1] include::{chapters-path}security/_index.adoc[leveloffset=+1] include::{chapters-path}jails/_index.adoc[leveloffset=+1] include::{chapters-path}mac/_index.adoc[leveloffset=+1] include::{chapters-path}audit/_index.adoc[leveloffset=+1] include::{chapters-path}disks/_index.adoc[leveloffset=+1] include::{chapters-path}geom/_index.adoc[leveloffset=+1] include::{chapters-path}zfs/_index.adoc[leveloffset=+1] include::{chapters-path}filesystems/_index.adoc[leveloffset=+1] include::{chapters-path}virtualization/_index.adoc[leveloffset=+1] include::{chapters-path}l10n/_index.adoc[leveloffset=+1] include::{chapters-path}cutting-edge/_index.adoc[leveloffset=+1] include::{chapters-path}dtrace/_index.adoc[leveloffset=+1] include::{chapters-path}usb-device-mode/_index.adoc[leveloffset=+1] // Section four include::{chapters-path}partiv.adoc[lines=7..8] include::{chapters-path}serialcomms/_index.adoc[leveloffset=+1] include::{chapters-path}ppp-and-slip/_index.adoc[leveloffset=+1] include::{chapters-path}mail/_index.adoc[leveloffset=+1] include::{chapters-path}network-servers/_index.adoc[leveloffset=+1] include::{chapters-path}firewalls/_index.adoc[leveloffset=+1] include::{chapters-path}advanced-networking/_index.adoc[leveloffset=+1] // Section five include::{chapters-path}partv.adoc[lines=7..8] :sectnums!: include::{chapters-path}mirrors/_index.adoc[leveloffset=+1] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] include::{chapters-path}eresources/_index.adoc[leveloffset=+1] include::{chapters-path}pgpkeys/_index.adoc[leveloffset=+1] :sectnums: diff --git a/documentation/content/en/articles/mailing-list-faq/_index.adoc b/documentation/content/en/articles/mailing-list-faq/_index.adoc index 8ab7fcb797..99b123e332 100644 --- a/documentation/content/en/articles/mailing-list-faq/_index.adoc +++ b/documentation/content/en/articles/mailing-list-faq/_index.adoc @@ -1,210 +1,210 @@ --- title: Frequently Asked Questions About The FreeBSD Mailing Lists authors: - author: The FreeBSD Documentation Project copyright: 2004-2021 The FreeBSD Documentation Project description: How to best use the mailing lists, such as how to help avoid frequently-repeated discussions tags: ["FAQ", "Mailing Lists", "FreeBSD"] --- = Frequently Asked Questions About The FreeBSD Mailing Lists :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/mailing-list-faq/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Abstract This is the FAQ for the FreeBSD mailing lists. If you are interested in helping with this project, send email to the {freebsd-doc}. The latest version of this document is always available from the link:.[FreeBSD World Wide Web server]. -It may also be downloaded as one large link:.[HTML] file with HTTP or as plain text, PostScript, PDF, etc. from the https://download.freebsd.org/ftp/doc/[FreeBSD FTP server]. +It may also be downloaded as one large link:.[HTML] file with HTTP or as plain text, PostScript, PDF, etc. from the https://download.freebsd.org/doc/[FreeBSD FTP server]. You may also want to link:https://www.FreeBSD.org/search/[Search the FAQ]. ''' toc::[] [[introduction]] == Introduction As is usual with FAQs, this document aims to cover the most frequently asked questions concerning the FreeBSD mailing lists (and of course answer them!). Although originally intended to reduce bandwidth and avoid the same old questions being asked over and over again, FAQs have become recognized as valuable information resources. This document attempts to represent a community consensus, and as such it can never really be __authoritative__. However, if you find technical errors within this document, or have suggestions about items that should be added, please either submit a PR, or email the {freebsd-doc}. Thanks. === What is the purpose of the FreeBSD mailing lists? The FreeBSD mailing lists serve as the primary communication channels for the FreeBSD community, covering many different topic areas and communities of interest. === Who is the audience for the FreeBSD mailing lists? This depends on charter of each individual list. Some lists are more oriented to developers; some are more oriented towards the FreeBSD community as a whole. Please see link:https://lists.FreeBSD.org/[this list] for the current summary. === Are the FreeBSD mailing lists open for anyone to participate? Again, this depends on charter of each individual list. Please read the charter of a mailing list before you post to it, and respect it when you post. This will help everyone to have a better experience with the lists. If after reading the above lists, you still do not know which mailing list to post a question to, you will probably want to post to freebsd-questions (but see below, first). Also note that the mailing lists have traditionally been open to postings from non-subscribers. This has been a deliberate choice, to help make joining the FreeBSD community an easier process, and to encourage open sharing of ideas. However, due to past abuse by some individuals, certain lists now have a policy where postings from non-subscribers must be manually screened to ensure that they are appropriate. === How can I subscribe? You can use link:https://lists.FreeBSD.org/[the Mlmmj web interface] to subscribe to any of the public lists. === How can I unsubscribe? You can use the same interface as above; or, you can follow the instructions that are at the bottom of every mailing list message that is sent. Please do not send unsubscribe messages directly to the public lists themselves. First, this will not accomplish your goal, and second, it will irritate the existing subscribers, and you will probably get flamed. This is a classical mistake when using mailing lists; please try to avoid it. === Are archives available? Yes. Threaded archives are available link:https://docs.FreeBSD.org/mail/[here]. You can also access https://lists.freebsd.org/pipermail[mailman archive] and link:https://lists.freebsd.org/archives[mlmmj archive] directly. === Are mailing lists available in a digest format? Yes. See link:https://lists.FreeBSD.org/[the Mlmmj web interface]. [[etiquette]] == Mailing List Etiquette Participation in the mailing lists, like participation in any community, requires a common basis for communication. Please make only appropriate postings, and follow common rules of etiquette. === What should I do before I post? You have already taken the most important step by reading this document. However, if you are new to FreeBSD, you may first need to familiarize yourself with the software, and all the social history around it, by reading the numerous link:https://www.FreeBSD.org/docs/books/[books and articles] that are available. Items of particular interest include the extref:{faq}[FreeBSD Frequently Asked Questions (FAQ)] document, the extref:{handbook}[FreeBSD Handbook], and the articles extref:{freebsd-questions-article}[How to get best results from the FreeBSD-questions mailing list], extref:{explaining-bsd}[Explaining BSD], and extref:{new-users}[FreeBSD First Steps]. It is always considered bad form to ask a question that is already answered in the above documents. This is not because the volunteers who work on this project are particularly mean people, but after a certain number of times answering the same questions over and over again, frustration begins to set in. This is particularly true if there is an existing answer to the question that is already available. Always keep in mind that almost all of the work done on FreeBSD is done by volunteers, and that we are only human. === What constitutes an inappropriate posting? * Postings must be in accordance with the charter of the mailing list. * Personal attacks are discouraged. As good net-citizens, we should try to hold ourselves to high standards of behavior. * Spam is not allowed, ever. The mailing lists are actively processed to ban offenders to this rule. === What is considered proper etiquette when posting to the mailing lists? * Please wrap lines at 75 characters, since not everyone uses fancy GUI mail reading programs. * Please respect the fact that bandwidth is not infinite. Not everyone reads email through high-speed connections, so if your posting involves something like the content of [.filename]#config.log# or an extensive stack trace, please consider putting that information up on a website somewhere and just provide a URL to it. Remember, too, that these postings will be archived indefinitely, so huge postings will simply inflate the size of the archives long after their purpose has expired. * Format your message so that it is legible, and PLEASE DO NOT SHOUT!!!!!. Do not underestimate the effect that a poorly formatted mail message has, and not just on the FreeBSD mailing lists. Your mail message is all that people see of you, and if it is poorly formatted, badly spelled, full of errors, and/or has lots of exclamation points, it will give people a poor impression of you. * Please use an appropriate human language for a particular mailing list. Many non-English mailing lists are link:https://www.FreeBSD.org/community/mailinglists/[available]. + For the ones that are not, we do appreciate that many people do not speak English as their first language, and we try to make allowances for that. It is considered particularly poor form to criticize non-native speakers for spelling or grammatical errors. FreeBSD has an excellent track record in this regard; please, help us to uphold that tradition. * Please use a standards-compliant Mail User Agent (MUA). A lot of badly formatted messages come from http://www.lemis.com/grog/email/email.php[bad mailers or badly configured mailers]. The following mailers are known to send out badly formatted messages without you finding out about them: ** exmh ** Microsoft(R) Exchange ** Microsoft(R) Outlook(R) + Try not to use MIME: a lot of people use mailers which do not get on very well with MIME. * Make sure your time and time zone are set correctly. This may seem a little silly, since your message still gets there, but many of the people on these mailing lists get several hundred messages a day. They frequently sort the incoming messages by subject and by date, and if your message does not come before the first answer, they may assume that they missed it and not bother to look. * A lot of the information you need to supply is the output of programs, such as man:dmesg[8], or console messages, which usually appear in [.filename]#/var/log/messages#. Do not try to copy this information by typing it in again; not only it is a real pain, but you are bound to make a mistake. To send log file contents, either make a copy of the file and use an editor to trim the information to what is relevant, or cut and paste into your message. For the output of programs like `dmesg`, redirect the output to a file and include that. For example, + [source,shell] .... % dmesg > /tmp/dmesg.out .... + This redirects the information to the file [.filename]#/tmp/dmesg.out#. * When using cut-and-paste, please be aware that some such operations badly mangle their messages. This is of particular concern when posting contents of [.filename]#Makefiles#, where `tab` is a significant character. This is a very common, and very annoying, problem with submissions to the link:https://www.FreeBSD.org/support/[Problem Reports database]. [.filename]#Makefiles# with tabs changed to either spaces, or the annoying `=3B` escape sequence, create a great deal of aggravation for committers. === What are the special etiquette consideration when replying to an existing posting on the mailing lists? * Please include relevant text from the original message. Trim it to the minimum, but do not overdo it. It should still be possible for somebody who did not read the original message to understand what you are talking about. + This is especially important for postings of the type "yes, I see this too", where the initial posting was dozens or hundreds of lines. * Use some technique to identify which text came from the original message, and which text you add. A common convention is to prepend "`>`" to the original message. Leaving white space after the "`>`" and leaving empty lines between your text and the original text both make the result more readable. * Please ensure that the attributions of the text you are quoting is correct. People can become offended if you attribute words to them that they themselves did not write. * Please do not `top post`. By this, we mean that if you are replying to a message, please put your replies after the text that you copy in your reply. + ** A: Because it reverses the logical flow of conversation. ** Q: Why is top posting frowned upon? + (Thanks to Randy Bush for the joke.) [[recurring]] == Recurring Topics On The Mailing Lists Participation in the mailing lists, like participation in any community, requires a common basis for communication. Many of the mailing lists presuppose a knowledge of the Project's history. In particular, there are certain topics that seem to regularly occur to newcomers to the community. It is the responsibility of each poster to ensure that their postings do not fall into one of these categories. By doing so, you will help the mailing lists to stay on-topic, and probably save yourself being flamed in the process. The best method to avoid this is to familiarize yourself with the http://docs.FreeBSD.org/mail/[mailing list archives], to help yourself understand the background of what has gone before. In this, the https://www.FreeBSD.org/search/#mailinglists[mailing list search interface] is invaluable. (If that method does not yield useful results, please supplement it with a search with your favorite major search engine). By familiarizing yourself with the archives, not only will you learn what topics have been discussed before, but also how discussion tends to proceed on that list, who the participants are, and who the target audience is. These are always good things to know before you post to any mailing list, not just a FreeBSD mailing list. There is no doubt that the archives are quite extensive, and some questions recur more often than others, sometimes as followups where the subject line no longer accurately reflects the new content. Nevertheless, the burden is on you, the poster, to do your homework to help avoid these recurring topics. [[bikeshed]] == What Is A "Bikeshed"? Literally, a `bikeshed` is a small outdoor shelter into which one may store one's two-wheeled form of transportation. However, in FreeBSD parlance, the term refers to topics that are simple enough that (nearly) anyone can offer an opinion about, and often (nearly) everyone does. The genesis of this term is explained in more detail extref:{faq}[in this document, bikeshed-painting]. You simply must have a working knowledge of this concept before posting to any FreeBSD mailing list. More generally, a bikeshed is a topic that will tend to generate immediate meta-discussions and flames if you have not read up on their past history. Please help us to keep the mailing lists as useful for as many people as possible by avoiding bikesheds whenever you can. Thanks. [[acknowledgments]] == Acknowledgments `{grog}`:: Original author of most of the material on mailing list etiquette, taken from the article on extref:{freebsd-questions-article}[How to get best results from the FreeBSD-questions mailing list]. `{linimon}`:: Creation of the rough draft of this FAQ. diff --git a/documentation/content/en/books/arch-handbook/_index.adoc b/documentation/content/en/books/arch-handbook/_index.adoc index a04234288d..777ef437e2 100644 --- a/documentation/content/en/books/arch-handbook/_index.adoc +++ b/documentation/content/en/books/arch-handbook/_index.adoc @@ -1,55 +1,55 @@ --- title: FreeBSD Architecture Handbook authors: - author: The FreeBSD Documentation Project copyright: Copyright © 2000-2006, 2012-2021 The FreeBSD Documentation Project description: For FreeBSD system developers. This book covers the architectural details of many important FreeBSD kernel subsystems trademarks: ["freebsd", "apple", "microsoft", "unix", "general"] tags: ["Arch Handbook", "FreeBSD"] next: books/arch-handbook/parti add_single_page_link: true showBookMenu: true weight: 0 path: "/books/arch-handbook/" bookOrder: 50 --- = FreeBSD Architecture Handbook :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/arch-handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Abstract Welcome to the FreeBSD Architecture Handbook. This manual is a _work in progress_ and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the {freebsd-doc}. -The latest version of this document is always available from the link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be downloaded in a variety of formats and compression options from the https://download.freebsd.org/ftp/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp]. +The latest version of this document is always available from the link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp]. ''' diff --git a/documentation/content/en/books/arch-handbook/book.adoc b/documentation/content/en/books/arch-handbook/book.adoc index 824911c691..d8993bdf12 100644 --- a/documentation/content/en/books/arch-handbook/book.adoc +++ b/documentation/content/en/books/arch-handbook/book.adoc @@ -1,82 +1,82 @@ --- title: FreeBSD Architecture Handbook authors: - author: The FreeBSD Documentation Project copyright: Copyright © 2000-2006, 2012-2021 The FreeBSD Documentation Project description: For FreeBSD system developers. This book covers the architectural details of many important FreeBSD kernel subsystems trademarks: ["freebsd", "apple", "microsoft", "unix", "general"] tags: ["Arch Handbook", "FreeBSD"] add_split_page_link: true --- = FreeBSD Architecture Handbook :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/arch-handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Abstract Welcome to the FreeBSD Architecture Handbook. This manual is a _work in progress_ and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the {freebsd-doc}. -The latest version of this document is always available from the link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be downloaded in a variety of formats and compression options from the https://download.freebsd.org/ftp/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp]. +The latest version of this document is always available from the link:https://www.FreeBSD.org/[FreeBSD World Wide Web server]. It may also be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp]. ''' toc::[] // Section one include::{chapters-path}parti.adoc[] include::{chapters-path}boot/_index.adoc[leveloffset=+1] include::{chapters-path}locking/_index.adoc[leveloffset=+1] include::{chapters-path}kobj/_index.adoc[leveloffset=+1] include::{chapters-path}jail/_index.adoc[leveloffset=+1] include::{chapters-path}sysinit/_index.adoc[leveloffset=+1]] include::{chapters-path}mac/_index.adoc[leveloffset=+1] include::{chapters-path}vm/_index.adoc[leveloffset=+1] include::{chapters-path}smp/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[] include::{chapters-path}driverbasics/_index.adoc[leveloffset=+1] include::{chapters-path}isa/_index.adoc[leveloffset=+1] include::{chapters-path}pci/_index.adoc[leveloffset=+1] include::{chapters-path}scsi/_index.adoc[leveloffset=+1] include::{chapters-path}usb/_index.adoc[leveloffset=+1] include::{chapters-path}newbus/_index.adoc[leveloffset=+1] include::{chapters-path}sound/_index.adoc[leveloffset=+1] include::{chapters-path}pccard/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] diff --git a/documentation/content/en/books/developers-handbook/_index.adoc b/documentation/content/en/books/developers-handbook/_index.adoc index 1025d05354..add9336ec8 100644 --- a/documentation/content/en/books/developers-handbook/_index.adoc +++ b/documentation/content/en/books/developers-handbook/_index.adoc @@ -1,59 +1,59 @@ --- title: FreeBSD Developers' Handbook authors: - author: The FreeBSD Documentation Project copyright: 1995-2021 The FreeBSD Documentation Project description: For people who want to develop software for FreeBSD (and not just people who are developing FreeBSD itself) trademarks: ["freebsd", "apple", "ibm", "ieee", "intel", "linux", "microsoft", "opengroup", "sun", "general"] next: books/developers-handbook/parti bookOrder: 25 tags: ["FreeBSD Developers' Handbook"] add_single_page_link: true showBookMenu: true weight: 0 path: "/books/developers-handbook/" --- = FreeBSD Developers' Handbook :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/developers-handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Abstract Welcome to the Developers' Handbook. This manual is a _work in progress_ and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the {freebsd-doc}. The latest version of this document is always available from the link:https://www.FreeBSD.org[FreeBSD World Wide Web server]. -It may also be downloaded in a variety of formats and compression options from the link:https://download.freebsd.org/ftp/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp]. +It may also be downloaded in a variety of formats and compression options from the link:https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp]. ''' diff --git a/documentation/content/en/books/developers-handbook/book.adoc b/documentation/content/en/books/developers-handbook/book.adoc index daae55b8a2..06061218ff 100644 --- a/documentation/content/en/books/developers-handbook/book.adoc +++ b/documentation/content/en/books/developers-handbook/book.adoc @@ -1,87 +1,87 @@ --- title: FreeBSD Developers' Handbook authors: - author: The FreeBSD Documentation Project copyright: 1995-2021 The FreeBSD Documentation Project description: For people who want to develop software for FreeBSD (and not just people who are developing FreeBSD itself) trademarks: ["freebsd", "apple", "ibm", "ieee", "intel", "linux", "microsoft", "opengroup", "sun", "general"] tags: ["FreeBSD Developers' Handbook"] add_split_page_link: true --- = FreeBSD Developers' Handbook :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/developers-handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Abstract Welcome to the Developers' Handbook. This manual is a _work in progress_ and is the work of many individuals. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to the {freebsd-doc}. The latest version of this document is always available from the link:https://www.FreeBSD.org[FreeBSD World Wide Web server]. -It may also be downloaded in a variety of formats and compression options from the link:https://download.freebsd.org/ftp/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp]. +It may also be downloaded in a variety of formats and compression options from the link:https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous extref:{handbook}[mirror sites, mirrors-ftp]. ''' toc::[] // Section one include::{chapters-path}parti.adoc[] include::{chapters-path}introduction/_index.adoc[leveloffset=+1] include::{chapters-path}tools/_index.adoc[leveloffset=+1] include::{chapters-path}secure/_index.adoc[leveloffset=+1] include::{chapters-path}l10n/_index.adoc[leveloffset=+1] include::{chapters-path}policies/_index.adoc[leveloffset=+1] include::{chapters-path}testing/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[] include::{chapters-path}sockets/_index.adoc[leveloffset=+1] include::{chapters-path}ipv6/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[] include::{chapters-path}kernelbuild/_index.adoc[leveloffset=+1] include::{chapters-path}kerneldebug/_index.adoc[leveloffset=+1] // Section four include::{chapters-path}partiv.adoc[] include::{chapters-path}x86/_index.adoc[leveloffset=+1] // Appendices include::{chapters-path}partv.adoc[] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] diff --git a/documentation/content/en/books/faq/_index.adoc b/documentation/content/en/books/faq/_index.adoc index ab3ea8a9d9..b66099da8d 100644 --- a/documentation/content/en/books/faq/_index.adoc +++ b/documentation/content/en/books/faq/_index.adoc @@ -1,3208 +1,3208 @@ --- title: Frequently Asked Questions for FreeBSD 12.X and 13.X authors: - author: The FreeBSD Documentation Project copyright: 1995-2021 The FreeBSD Documentation Project description: Frequently Asked Questions, and answers, covering all aspects of FreeBSD trademarks: ["freebsd", "ibm", "ieee", "adobe", "intel", "linux", "microsoft", "opengroup", "sun", "netbsd", "general"] bookOrder: 5 tags: ["FAQ", "FreeBSD FAQ"] --- = Frequently Asked Questions for FreeBSD {rel2-relx} and {rel-relx} :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/faq/ :rel-numbranch: 4 :rel-head: 14-CURRENT :rel-head-relx: 14.X :rel-head-releng: head/ :rel-relx: 13.X :rel-stable: 13-STABLE :rel-releng: stable/13/ :rel-relengdate: December 2018 :rel2-relx: 12.X :rel2-stable: 12-STABLE :rel2-releng: stable/12/ :rel2-relengdate: December 2018 ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Abstract This is the Frequently Asked Questions (FAQ) for FreeBSD versions {rel-relx} and {rel2-relx}. Every effort has been made to make this FAQ as informative as possible; if you have any suggestions as to how it may be improved, send them to the {freebsd-doc}. The latest version of this document is always available from the extref:{faq}[FreeBSD website]. -It may also be downloaded as one large link:.[HTML] file with HTTP or as a variety of other formats from the https://download.freebsd.org/ftp/doc/[FreeBSD FTP server]. +It may also be downloaded as one large link:.[HTML] file with HTTP or as a variety of other formats from the https://download.freebsd.org/doc/[FreeBSD FTP server]. ''' toc::[] [[introduction]] == Introduction [[what-is-FreeBSD]] === What is FreeBSD? FreeBSD is a modern operating system for desktops, laptops, servers, and embedded systems with support for a large number of https://www.FreeBSD.org/platforms/[platforms]. It is based on U.C. Berkeley's "4.4BSD-Lite" release, with some "4.4BSD-Lite2" enhancements. It is also based indirectly on William Jolitz's port of U.C. Berkeley's "Net/2" to the i386(TM), known as "386BSD", though very little of the 386BSD code remains. FreeBSD is used by companies, Internet Service Providers, researchers, computer professionals, students and home users all over the world in their work, education and recreation. For more detailed information on FreeBSD, refer to the extref:{handbook}[FreeBSD Handbook]. [[FreeBSD-goals]] === What is the goal of the FreeBSD Project? The goal of the FreeBSD Project is to provide a stable and fast general purpose operating system that may be used for any purpose without strings attached. [[bsd-license-restrictions]] === Does the FreeBSD license have any restrictions? Yes. Those restrictions do not control how the code is used, but how to treat the FreeBSD Project itself. The license itself is available at https://www.FreeBSD.org/copyright/freebsd-license/[license] and can be summarized like this: * Do not claim that you wrote this. * Do not sue us if it breaks. * Do not remove or modify the license. Many of us have a significant investment in the project and would certainly not mind a little financial compensation now and then, but we definitely do not insist on it. We believe that our first and foremost "mission" is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This, we believe, is one of the most fundamental goals of Free Software and one that we enthusiastically support. Code in our source tree which falls under the https://www.FreeBSD.org/copyright/COPYING[GNU General Public License (GPL)] or https://www.FreeBSD.org/copyright/COPYING.LIB[GNU Library General Public License (LGPL)] comes with slightly more strings attached, though at least on the side of enforced access rather than the usual opposite. Due to the additional complexities that can evolve in the commercial use of GPL software, we do, however, endeavor to replace such software with submissions under the more relaxed https://www.FreeBSD.org/copyright/freebsd-license/[FreeBSD license] whenever possible. [[replace-current-OS]] === Can FreeBSD replace my current operating system? For most people, yes. But this question is not quite that cut-and-dried. Most people do not actually use an operating system. They use applications. The applications are what really use the operating system. FreeBSD is designed to provide a robust and full-featured environment for applications. It supports a wide variety of web browsers, office suites, email readers, graphics programs, programming environments, network servers, and much more. Most of these applications can be managed through the https://www.FreeBSD.org/ports/[Ports Collection]. If an application is only available on one operating system, that operating system cannot just be replaced. Chances are, there is a very similar application on FreeBSD, however. As a solid office or Internet server or a reliable workstation, FreeBSD will almost certainly do everything you need. Many computer users across the world, including both novices and experienced UNIX(R) administrators, use FreeBSD as their only desktop operating system. Users migrating to FreeBSD from another UNIX(R)-like environment will find FreeBSD to be similar. Windows(R) and Mac OS(R) users may be interested in instead using https://www.ghostbsd.org/[GhostBSD], https://www.midnightbsd.org/[MidnightBSD] or https://www.nomadbsd.org/[NomadBSD] three FreeBSD-based desktop distributions. Non-UNIX(R) users should expect to invest some additional time learning the UNIX(R) way of doing things. This FAQ and the extref:{handbook}[FreeBSD Handbook] are excellent places to start. [[why-called-FreeBSD]] === Why is it called FreeBSD? * It may be used free of charge, even by commercial users. * Full source for the operating system is freely available, and the minimum possible restrictions have been placed upon its use, distribution and incorporation into other work (commercial or non-commercial). * Anyone who has an improvement or bug fix is free to submit their code and have it added to the source tree (subject to one or two obvious provisions). It is worth pointing out that the word "free" is being used in two ways here: one meaning "at no cost" and the other meaning "do whatever you like". Apart from one or two things you _cannot_ do with the FreeBSD code, for example pretending you wrote it, you can really do whatever you like with it. [[differences-to-other-bsds]] === What are the differences between FreeBSD and NetBSD, OpenBSD, and other open source BSD operating systems? James Howard wrote a good explanation of the history and differences between the various projects, called https://jameshoward.us/archive/bsd-family-tree/[The BSD Family Tree] which goes a fair way to answering this question. Some of the information is out of date, but the history portion in particular remains accurate. Most of the BSDs share patches and code, even today. All of the BSDs have common ancestry. The design goals of FreeBSD are described in <>, above. The design goals of the other most popular BSDs may be summarized as follows: * OpenBSD aims for operating system security above all else. The OpenBSD team wrote man:ssh[1] and man:pf[4], which have both been ported to FreeBSD. * NetBSD aims to be easily ported to other hardware platforms. * DragonFly BSD is a fork of FreeBSD 4.8 that has since developed many interesting features of its own, including the HAMMER file system and support for user-mode "vkernels". [[latest-version]] === What is the latest version of FreeBSD? At any point in the development of FreeBSD, there can be multiple parallel branches. {rel-relx} releases are made from the {rel-stable} branch, and {rel2-relx} releases are made from the {rel2-stable} branch. Up until the release of 12.0, the {rel2-relx} series was the one known as _-STABLE_. However, as of {rel-head-relx}, the {rel2-relx} branch will be designated for an "extended support" status and receive only fixes for major problems, such as security-related fixes. Releases are made <>. While many people stay more up-to-date with the FreeBSD sources (see the questions on <> and <>) than that, doing so is more of a commitment, as the sources are a moving target. More information on FreeBSD releases can be found on the https://www.FreeBSD.org/releng/#release-build[Release Engineering page] and in man:release[7]. [[current]] === What is _FreeBSD-CURRENT_? extref:{handbook}[FreeBSD-CURRENT, current] is the development version of the operating system, which will in due course become the new FreeBSD-STABLE branch. As such, it is really only of interest to developers working on the system and die-hard hobbyists. See the extref:{handbook}[relevant section, current] in the extref:{handbook}[Handbook] for details on running _-CURRENT_. Users not familiar with FreeBSD should not use FreeBSD-CURRENT. This branch sometimes evolves quite quickly and due to mistake can be un-buildable at times. People that use FreeBSD-CURRENT are expected to be able to analyze, debug, and report problems. [[stable]] === What is the FreeBSD-STABLE concept? _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. However, at any given time, the sources for FreeBSD-STABLE may or may not be suitable for general use, as it may uncover bugs and corner cases that were not yet found in FreeBSD-CURRENT. Users who do not have the resources to perform testing should instead run the most recent release of FreeBSD. _FreeBSD-CURRENT_, on the other hand, has been one unbroken line since 2.0 was released. For more detailed information on branches see "extref:{releng}[FreeBSD Release Engineering: Creating the Release Branch, rel-branch]", the status of the branches and the upcoming release schedule can be found on the https://www.FreeBSD.org/releng[Release Engineering Information] page. -Version https://download.FreeBSD.org/ftp/releases/amd64/amd64/{rel121-current}-RELEASE/[{rel121-current}] is the latest release from the {rel-stable} branch; it was released in {rel121-current-date}. -Version https://download.FreeBSD.org/ftp/releases/amd64/amd64/{rel113-current}-RELEASE/[{rel113-current}] is the latest release from the {rel2-stable} branch; it was released in {rel113-current-date}. +Version https://download.FreeBSD.org/releases/amd64/amd64/{rel121-current}-RELEASE/[{rel121-current}] is the latest release from the {rel-stable} branch; it was released in {rel121-current-date}. +Version https://download.FreeBSD.org/releases/amd64/amd64/{rel113-current}-RELEASE/[{rel113-current}] is the latest release from the {rel2-stable} branch; it was released in {rel113-current-date}. [[release-freq]] === When are FreeBSD releases made? The {re} releases a new major version of FreeBSD about every 18 months and a new minor version about every 8 months, on average. Release dates are announced well in advance, so that the people working on the system know when their projects need to be finished and tested. A testing period precedes each release, to ensure that the addition of new features does not compromise the stability of the release. Many users regard this caution as one of the best things about FreeBSD, even though waiting for all the latest goodies to reach _-STABLE_ can be a little frustrating. More information on the release engineering process (including a schedule of upcoming releases) can be found on the https://www.FreeBSD.org/releng/[release engineering] pages on the FreeBSD Web site. For people who need or want a little more excitement, binary snapshots are made weekly as discussed above. [[snapshot-freq]] === When are FreeBSD snapshots made? FreeBSD link:https://www.FreeBSD.org/snapshots/[snapshot] releases are made based on the current state of the _-CURRENT_ and _-STABLE_ branches. The goals behind each snapshot release are: * To test the latest version of the installation software. * To give people who would like to run _-CURRENT_ or _-STABLE_ but who do not have the time or bandwidth to follow it on a day-to-day basis an easy way of bootstrapping it onto their systems. * To preserve a fixed reference point for the code in question, just in case we break something really badly later. (Although Subversion normally prevents anything horrible like this happening.) * To ensure that all new features and fixes in need of testing have the greatest possible number of potential testers. No claims are made that any _-CURRENT_ snapshot can be considered "production quality" for any purpose. If a stable and fully tested system is needed, stick to full releases. Snapshot releases are directly available from link:https://www.FreeBSD.org/snapshots/[snapshot]. Official snapshots are generated on a regular basis for all actively developed branches. [[responsible]] === Who is responsible for FreeBSD? The key decisions concerning the FreeBSD project, such as the overall direction of the project and who is allowed to add code to the source tree, are made by a link:https://www.FreeBSD.org/administration#t-core[core team] of 9 people. There is a much larger team of more than 350 extref:{contributors}[committers, staff-committers] who are authorized to make changes directly to the FreeBSD source tree. However, most non-trivial changes are discussed in advance in the <>, and there are no restrictions on who may take part in the discussion. [[where-get]] === Where can I get FreeBSD? -Every significant release of FreeBSD is available via anonymous FTP from the https://download.FreeBSD.org/ftp/releases/[FreeBSD FTP site]: +Every significant release of FreeBSD is available via anonymous FTP from the https://download.FreeBSD.org/releases/[FreeBSD FTP site]: -* The latest {rel-stable} release, {rel121-current}-RELEASE can be found in the https://download.FreeBSD.org/ftp/releases/amd64/amd64/{rel121-current}-RELEASE/[{rel121-current}-RELEASE directory]. +* The latest {rel-stable} release, {rel121-current}-RELEASE can be found in the https://download.FreeBSD.org/releases/amd64/amd64/{rel121-current}-RELEASE/[{rel121-current}-RELEASE directory]. * link:https://www.FreeBSD.org/snapshots/[Snapshot] releases are made monthly for the <> and <> branch, these being of service purely to bleeding-edge testers and developers. -* The latest {rel2-stable} release, {rel113-current}-RELEASE can be found in the https://download.FreeBSD.org/ftp/releases/amd64/amd64/{rel113-current}-RELEASE/[{rel113-current}-RELEASE directory]. +* The latest {rel2-stable} release, {rel113-current}-RELEASE can be found in the https://download.FreeBSD.org/releases/amd64/amd64/{rel113-current}-RELEASE/[{rel113-current}-RELEASE directory]. Information about obtaining FreeBSD on CD, DVD, and other media can be found in extref:{handbook}[the Handbook, mirrors]. [[access-pr]] === How do I access the Problem Report database? The Problem Report database of all user change requests may be queried by using our web-based PR https://bugs.FreeBSD.org/search/[query] interface. The link:https://www.FreeBSD.org/support/bugreports[web-based problem report submission interface] can be used to submit problem reports through a web browser. Before submitting a problem report, read extref:{problem-reports}[Writing FreeBSD Problem Reports], an article on how to write good problem reports. [[support]] == Documentation and Support [[books]] === What good books are there about FreeBSD? The project produces a wide range of documentation, available online from this link: https://www.FreeBSD.org/docs/[https://www.FreeBSD.org/docs/]. [[doc-formats]] === Is the documentation available in other formats, such as plain text (ASCII), or PDF? Yes. The documentation is available in a number of different formats and compression schemes on the FreeBSD FTP site, -in the https://download.freebsd.org/ftp/doc/[/ftp/doc/] directory. +in the https://download.freebsd.org/doc/[/doc/] directory. The documentation is categorized in a number of different ways. These include: * The document's name, such as `faq`, or `handbook`. * The document's language and encoding. These are based on the locale names found under [.filename]#/usr/share/locale# on a FreeBSD system. The current languages and encodings are as follows: + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Name | Meaning |`en_US.ISO8859-1` |English (United States) |`bn_BD.ISO10646-1` |Bengali or Bangla (Bangladesh) |`da_DK.ISO8859-1` |Danish (Denmark) |`de_DE.ISO8859-1` |German (Germany) |`el_GR.ISO8859-7` |Greek (Greece) |`es_ES.ISO8859-1` |Spanish (Spain) |`fr_FR.ISO8859-1` |French (France) |`hu_HU.ISO8859-2` |Hungarian (Hungary) |`it_IT.ISO8859-15` |Italian (Italy) |`ja_JP.eucJP` |Japanese (Japan, EUC encoding) |`ko_KR.UTF-8` |Korean (Korea, UTF-8 encoding) |`mn_MN.UTF-8` |Mongolian (Mongolia, UTF-8 encoding) |`nl_NL.ISO8859-1` |Dutch (Netherlands) |`pl_PL.ISO8859-2` |Polish (Poland) |`pt_BR.ISO8859-1` |Portuguese (Brazil) |`ru_RU.KOI8-R` |Russian (Russia, KOI8-R encoding) |`tr_TR.ISO8859-9` |Turkish (Turkey) |`zh_CN.UTF-8` |Simplified Chinese (China, UTF-8 encoding) |`zh_TW.UTF-8` |Traditional Chinese (Taiwan, UTF-8 encoding) |=== + [NOTE] ==== Some documents may not be available in all languages. ==== * The document's format. We produce the documentation in a number of different output formats. Each format has its own advantages and disadvantages. Some formats are better suited for online reading, while others are meant to be aesthetically pleasing when printed on paper. Having the documentation available in any of these formats ensures that our readers will be able to read the parts they are interested in, either on their monitor, or on paper after printing the documents. The currently available formats are: + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Format | Meaning |`html-split` |A collection of small, linked, HTML files. |`html` |One large HTML file containing the entire document |`pdf` |Adobe's Portable Document Format |`txt` |Plain text |=== * The compression and packaging scheme. .. Where the format is `html-split`, the files are bundled up using man:tar[1]. The resulting [.filename]#.tar# is then compressed using the compression schemes detailed in the next point. .. All the other formats generate one file. For example, [.filename]#article.pdf#, [.filename]#book.html#, and so on. + These files are then compressed using either the `zip` or `bz2` compression schemes. man:tar[1] can be used to uncompress these files. + So the PDF version of the Handbook, compressed using `bzip2` will be stored in a file called [.filename]#book.pdf.bz2# in the [.filename]#handbook/# directory. After choosing the format and compression mechanism, download the compressed files, uncompress them, and then copy the appropriate documents into place. For example, the split HTML version of the FAQ, compressed using man:bzip2[1], can be found in [.filename]#doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2# To download and uncompress that file, type: [source,shell] .... -# fetch https://download.freebsd.org/ftp/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 +# fetch https://download.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 # tar xvf book.html-split.tar.bz2 .... If the file is compressed, tar will automatically detect the appropriate format and decompress it correctly, resulting in a collection of [.filename]#.html# files. The main one is called [.filename]#index.html#, which will contain the table of contents, introductory material, and links to the other parts of the document. [[mailing]] === Where do I find info on the FreeBSD mailing lists? What FreeBSD news groups are available? Refer to the extref:{handbook}[Handbook entry on mailing-lists, eresources-mail] and the extref:{handbook}[Handbook entry on newsgroups, eresources-news]. [[irc]] === Are there FreeBSD IRC (Internet Relay Chat) channels? Yes, most major IRC networks host a FreeBSD chat channel and the FreeBSD wiki holds an up to date https://wiki.freebsd.org/IRC/Channels[list of IRC channels]. Each of these channels are distinct and are not connected to each other. Since their chat styles differ, try each to find one suited to your chat style. [[forums]] === Are there any web based forums to discuss FreeBSD? The official FreeBSD forums are located at https://forums.FreeBSD.org/[https://forums.FreeBSD.org/]. [[training]] === Where can I get commercial FreeBSD training and support? http://www.ixsystems.com[iXsystems, Inc.], parent company of the http://www.freebsdmall.com/[FreeBSD Mall], provides commercial FreeBSD and TrueOS software http://www.ixsystems.com/support[support], in addition to FreeBSD development and tuning solutions. BSD Certification Group, Inc. provides system administration certifications for DragonFly BSD, FreeBSD, NetBSD, and OpenBSD. Refer to http://www.BSDCertification.org[their site] for more information. Any other organizations providing training and support should contact the Project to be listed here. [[install]] == Installation [[which-architecture]] === Which platform should I download? I have a 64 bit capable Intel(R) CPU, but I only see amd64. amd64 is the term FreeBSD uses for 64-bit compatible x86 architectures (also known as "x86-64" or "x64"). Most modern computers should use amd64. Older hardware should use i386. When installing on a non-x86-compatible architecture, select the platform which best matches the hardware. [[floppy-download]] === Which file do I download to get FreeBSD? On the https://www.freebsd.org/where/[Getting FreeBSD] page, select `[iso]` next to the architecture that matches the hardware. Any of the following can be used: [.informaltable] [cols="1,1", frame="none", options="header"] |=== | file | description |[.filename]#disc1.iso# |Contains enough to install FreeBSD and a minimal set of packages. |[.filename]#dvd1.iso# |Similar to [.filename]#disc1.iso# but with additional packages. |[.filename]#memstick.img# |A bootable image sufficient for writing to a USB stick. |[.filename]#bootonly.iso# |A minimal image that requires network access during installation to completely install FreeBSD. |=== Full instructions on this procedure and a little bit more about installation issues in general can be found in the extref:{handbook}[Handbook entry on installing FreeBSD, bsdinstall]. [[floppy-image-too-large]] === What do I do if the install image does not boot? This can be caused by not downloading the image in _binary_ mode when using FTP. Some FTP clients default their transfer mode to _ascii_ and attempt to change any end-of-line characters received to match the conventions used by the client's system. This will almost invariably corrupt the boot image. Check the SHA-256 checksum of the downloaded boot image: if it is not _exactly_ that on the server, then the download process is suspect. When using a command line FTP client, type _binary_ at the FTP command prompt after getting connected to the server and before starting the download of the image. [[install-instructions-location]] === Where are the instructions for installing FreeBSD? Installation instructions can be found at extref:{handbook}[Handbook entry on installing FreeBSD, bsdinstall]. [[custom-boot-floppy]] === How can I make my own custom release or install disk? Customized FreeBSD installation media can be created by building a custom release. Follow the instructions in the extref:{releng}[Release Engineering] article. [[windows-coexist]] === Can Windows(R) co-exist with FreeBSD? (x86-specific) If Windows(R) is installed first, then yes. FreeBSD's boot manager will then manage to boot Windows(R) and FreeBSD. If Windows(R) is installed afterwards, it will overwrite the boot manager. If that happens, see the next section. [[bootmanager-restore]] === Another operating system destroyed my Boot Manager. How do I get it back? (x86-specific) This depends upon the boot manager. The FreeBSD boot selection menu can be reinstalled using man:boot0cfg[8]. For example, to restore the boot menu onto the disk _ada0_: [source,shell] .... # boot0cfg -B ada0 .... The non-interactive MBR bootloader can be installed using man:gpart[8]: [source,shell] .... # gpart bootcode -b /boot/mbr ada0 .... For more complex situations, including GPT disks, see man:gpart[8]. [[need-complete-sources]] === Do I need to install the source? In general, no. There is nothing in the base system which requires the presence of the source to operate. Some ports, like package:sysutils/lsof[], will not build unless the source is installed. In particular, if the port builds a kernel module or directly operates on kernel structures, the source must be installed. [[need-kernel]] === Do I need to build a kernel? Usually not. The supplied `GENERIC` kernel contains the drivers an ordinary computer will need. man:freebsd-update[8], the FreeBSD binary upgrade tool, cannot upgrade custom kernels, another reason to stick with the `GENERIC` kernel when possible. For computers with very limited RAM, such as embedded systems, it may be worthwhile to build a smaller custom kernel containing just the required drivers. [[password-encryption]] === Should I use DES, Blowfish, or MD5 passwords and how do I specify which form my users receive? FreeBSD uses _SHA512_ by default. DES passwords are still available for backwards compatibility with operating systems that still use the less secure password format. FreeBSD also supports the Blowfish and MD5 password formats. Which password format to use for new passwords is controlled by the `passwd_format` login capability in [.filename]#/etc/login.conf#, which takes values of `des`, `blf` (if these are available) or `md5`. See the man:login.conf[5] manual page for more information about login capabilities. [[ffs-limits]] === What are the limits for FFS file systems? For FFS file systems, the largest file system is practically limited by the amount of memory required to man:fsck[8] the file system. man:fsck[8] requires one bit per fragment, which with the default fragment size of 4 KB equates to 32 MB of memory per TB of disk. This does mean that on architectures which limit userland processes to 2 GB (e.g., i386(TM)), the maximum man:fsck[8]'able filesystem is ~60 TB. If there was not a man:fsck[8] memory limit the maximum filesystem size would be 2 ^ 64 (blocks) * 32 KB => 16 Exa * 32 KB => 512 ZettaBytes. The maximum size of a single FFS file is approximately 2 PB with the default block size of 32 KB. Each 32 KB block can point to 4096 blocks. With triple indirect blocks, the calculation is 32 KB * 12 + 32 KB * 4096 + 32 KB * 4096^2 + 32 KB * 4096^3. Increasing the block size to 64 KB will increase the max file size by a factor of 16. [[archsw-readin-failed-error]] === Why do I get an error message, readin failed after compiling and booting a new kernel? The world and kernel are out of sync. This is not supported. Be sure to use `make buildworld` and `make buildkernel` to update the kernel. Boot the system by specifying the kernel directly at the second stage, pressing any key when the `|` shows up before loader is started. [[general-configuration-tool]] === Is there a tool to perform post-installation configuration tasks? Yes. bsdconfig provides a nice interface to configure FreeBSD post-installation. [[hardware]] == Hardware Compatibility [[compatibility-general]] === General [[which-hardware-to-get]] ==== I want to get a piece of hardware for my FreeBSD system. Which model/brand/type is best? This is discussed continually on the FreeBSD mailing lists but is to be expected since hardware changes so quickly. Read through the Hardware Notes for FreeBSD link:{u-rel121-hardware}[{rel121-current}] or link:{u-rel113-hardware}[{rel113-current}] and search the mailing list https://www.FreeBSD.org/search/#mailinglists[archives] before asking about the latest and greatest hardware. Chances are a discussion about that type of hardware took place just last week. Before purchasing a laptop, check the archives for {freebsd-questions}, or possibly a specific mailing list for a particular hardware type. [[memory-upper-limitation]] ==== What are the limits for memory? FreeBSD as an operating system generally supports as much physical memory (RAM) as the platform it is running on does. Keep in mind that different platforms have different limits for memory; for example i386(TM) without PAE supports at most 4 GB of memory (and usually less than that because of PCI address space) and i386(TM) with PAE supports at most 64 GB memory. As of FreeBSD 10, AMD64 platforms support up to 4 TB of physical memory. [[memory-i386-over-4gb]] ==== Why does FreeBSD report less than 4 GB memory when installed on an i386(TM) machine? The total address space on i386(TM) machines is 32-bit, meaning that at most 4 GB of memory is addressable (can be accessed). Furthermore, some addresses in this range are reserved by hardware for different purposes, for example for using and controlling PCI devices, for accessing video memory, and so on. Therefore, the total amount of memory usable by the operating system for its kernel and applications is limited to significantly less than 4 GB. Usually, 3.2 GB to 3.7 GB is the maximum usable physical memory in this configuration. To access more than 3.2 GB to 3.7 GB of installed memory (meaning up to 4 GB but also more than 4 GB), a special tweak called PAE must be used. PAE stands for Physical Address Extension and is a way for 32-bit x86 CPUs to address more than 4 GB of memory. It remaps the memory that would otherwise be overlaid by address reservations for hardware devices above the 4 GB range and uses it as additional physical memory (see man:pae[4]). Using PAE has some drawbacks; this mode of memory access is a little bit slower than the normal (without PAE) mode and loadable modules (see man:kld[4]) are not supported. This means all drivers must be compiled into the kernel. The most common way to enable PAE is to build a new kernel with the special ready-provided kernel configuration file called [.filename]#PAE#, which is already configured to build a safe kernel. Note that some entries in this kernel configuration file are too conservative and some drivers marked as unready to be used with PAE are actually usable. A rule of thumb is that if the driver is usable on 64-bit architectures (like AMD64), it is also usable with PAE. When creating a custom kernel configuration file, PAE can be enabled by adding the following line: [.programlisting] .... options PAE .... PAE is not much used nowadays because most new x86 hardware also supports running in 64-bit mode, known as AMD64 or Intel(R) 64. It has a much larger address space and does not need such tweaks. FreeBSD supports AMD64 and it is recommended that this version of FreeBSD be used instead of the i386(TM) version if 4 GB or more memory is required. [[compatibility-processors]] === Architectures and Processors [[architectures]] ==== Does FreeBSD support architectures other than the x86? Yes. FreeBSD divides support into multiple tiers. Tier 1 architectures, such as i386 or amd64; are fully supported. Tiers 2 and 3 are supported on a best-effort basis. A full explanation of the tier system is available in the extref:{committers-guide}[Committer's Guide., archs] A complete list of supported architectures can be found on the https://www.FreeBSD.org/platforms/[platforms page.] [[smp-support]] ==== Does FreeBSD support Symmetric Multiprocessing (SMP)? FreeBSD supports symmetric multi-processor (SMP) on all non-embedded platforms (e.g, i386, amd64, etc.). SMP is also supported in arm and MIPS kernels, although some CPUs may not support this. FreeBSD's SMP implementation uses fine-grained locking, and performance scales nearly linearly with number of CPUs. man:smp[4] has more details. [[microcode]] ==== What is microcode? How do I install Intel(R) CPU microcode updates? Microcode is a method of programmatically implementing hardware level instructions. This allows for CPU bugs to be fixed without replacing the on board chip. Install package:sysutils/devcpu-data[], then add: [.programlisting] .... microcode_update_enable="YES" .... to [.filename]#/etc/rc.conf# [[compatibility-peripherals]] === Peripherals [[supported-peripherals]] ==== What kind of peripherals does FreeBSD support? See the complete list in the Hardware Notes for FreeBSD link:{u-rel121-hardware}[{rel121-current}] or link:{u-rel113-hardware}[{rel113-current}]. [[compatibility-kbd-mice]] === Keyboards and Mice [[moused]] ==== Is it possible to use a mouse outside the X Window system? The default console driver, man:vt[4], provides the ability to use a mouse pointer in text consoles to cut & paste text. Run the mouse daemon, man:moused[8], and turn on the mouse pointer in the virtual console: [source,shell] .... # moused -p /dev/xxxx -t yyyy # vidcontrol -m on .... Where _xxxx_ is the mouse device name and _yyyy_ is a protocol type for the mouse. The mouse daemon can automatically determine the protocol type of most mice, except old serial mice. Specify the `auto` protocol to invoke automatic detection. If automatic detection does not work, see the man:moused[8] manual page for a list of supported protocol types. For a PS/2 mouse, add `moused_enable="YES"` to [.filename]#/etc/rc.conf# to start the mouse daemon at boot time. Additionally, to use the mouse daemon on all virtual terminals instead of just the console, add `allscreens_flags="-m on"` to [.filename]#/etc/rc.conf#. When the mouse daemon is running, access to the mouse must be coordinated between the mouse daemon and other programs such as X Windows. Refer to the FAQ <> for more details on this issue. [[text-mode-cut-paste]] ==== How do I cut and paste text with a mouse in the text console? It is not possible to remove data using the mouse. However, it is possible to copy and paste. Once the mouse daemon is running as described in the <>, hold down button 1 (left button) and move the mouse to select a region of text. Then, press button 2 (middle button) to paste it at the text cursor. Pressing button 3 (right button) will "extend" the selected region of text. If the mouse does not have a middle button, it is possible to emulate one or remap buttons using mouse daemon options. See the man:moused[8] manual page for details. [[mouse-wheel-buttons]] ==== My mouse has a fancy wheel and buttons. Can I use them in FreeBSD? The answer is, unfortunately, "It depends". These mice with additional features require specialized driver in most cases. Unless the mouse device driver or the user program has specific support for the mouse, it will act just like a standard two, or three button mouse. For the possible usage of wheels in the X Window environment, refer to <>. [[keyboard-delete-key]] ==== How do I use my delete key in sh and csh? For the Bourne Shell, add the following lines to [.filename]#~/.shrc#. See man:sh[1] and man:editrc[5]. [.programlisting] .... bind ^[[3~ ed-delete-next-char # for xterm .... For the C Shell, add the following lines to [.filename]#~/.cshrc#. See man:csh[1]. [.programlisting] .... bindkey ^[[3~ delete-char # for xterm .... [[compatibility-other]] === Other Hardware [[es1370-silent-pcm]] ==== Workarounds for no sound from my man:pcm[4] sound card? Some sound cards set their output volume to 0 at every boot. Run the following command every time the machine boots: [source,shell] .... # mixer pcm 100 vol 100 cd 100 .... [[power-management-support]] ==== Does FreeBSD support power management on my laptop? FreeBSD supports the ACPI features found in modern hardware. Further information can be found in man:acpi[4]. [[troubleshoot]] == Troubleshooting [[pae]] === Why is FreeBSD finding the wrong amount of memory on i386(TM) hardware? The most likely reason is the difference between physical memory addresses and virtual addresses. The convention for most PC hardware is to use the memory area between 3.5 GB and 4 GB for a special purpose (usually for PCI). This address space is used to access PCI hardware. As a result real, physical memory cannot be accessed by that address space. What happens to the memory that should appear in that location is hardware dependent. Unfortunately, some hardware does nothing and the ability to use that last 500 MB of RAM is entirely lost. Luckily, most hardware remaps the memory to a higher location so that it can still be used. However, this can cause some confusion when watching the boot messages. On a 32-bit version of FreeBSD, the memory appears lost, since it will be remapped above 4 GB, which a 32-bit kernel is unable to access. In this case, the solution is to build a PAE enabled kernel. See the entry on memory limits for more information. On a 64-bit version of FreeBSD, or when running a PAE-enabled kernel, FreeBSD will correctly detect and remap the memory so it is usable. During boot, however, it may seem as if FreeBSD is detecting more memory than the system really has, due to the described remapping. This is normal and the available memory will be corrected as the boot process completes. [[signal11]] === Why do my programs occasionally die with Signal 11 errors? Signal 11 errors are caused when a process has attempted to access memory which the operating system has not granted it access to. If something like this is happening at seemingly random intervals, start investigating the cause. These problems can usually be attributed to either: . If the problem is occurring only in a specific custom application, it is probably a bug in the code. . If it is a problem with part of the base FreeBSD system, it may also be buggy code, but more often than not these problems are found and fixed long before us general FAQ readers get to use these bits of code (that is what -CURRENT is for). It is probably not a FreeBSD bug if the problem occurs compiling a program, but the activity that the compiler is carrying out changes each time. For example, if `make buildworld` fails while trying to compile [.filename]#ls.c# into [.filename]#ls.o# and, when run again, it fails in the same place, this is a broken build. Try updating source and try again. If the compile fails elsewhere, it is almost certainly due to hardware. In the first case, use a debugger such as man:gdb[1] to find the point in the program which is attempting to access a bogus address and fix it. In the second case, verify which piece of hardware is at fault. Common causes of this include: . The hard disks might be overheating: Check that the fans are still working, as the disk and other hardware might be overheating. . The processor running is overheating: This might be because the processor has been overclocked, or the fan on the processor might have died. In either case, ensure that the hardware is running at what it is specified to run at, at least while trying to solve this problem. If it is not, clock it back to the default settings.) + Regarding overclocking, it is far cheaper to have a slow system than a fried system that needs replacing! Also the community is not sympathetic to problems on overclocked systems. . Dodgy memory: if multiple memory SIMMS/DIMMS are installed, pull them all out and try running the machine with each SIMM or DIMM individually to narrow the problem down to either the problematic DIMM/SIMM or perhaps even a combination. . Over-optimistic motherboard settings: the BIOS settings, and some motherboard jumpers, provide options to set various timings. The defaults are often sufficient, but sometimes setting the wait states on RAM too low, or setting the "RAM Speed: Turbo" option will cause strange behavior. A possible idea is to set to BIOS defaults, after noting the current settings first. . Unclean or insufficient power to the motherboard. Remove any unused I/O boards, hard disks, or CD-ROMs, or disconnect the power cable from them, to see if the power supply can manage a smaller load. Or try another power supply, preferably one with a little more power. For instance, if the current power supply is rated at 250 Watts, try one rated at 300 Watts. Read the section on <> for a further explanation and a discussion on how memory testing software or hardware can still pass faulty memory. There is an extensive FAQ on this at http://www.bitwizard.nl/sig11/[the SIG11 problem FAQ]. Finally, if none of this has helped, it is possibly a bug in FreeBSD. Follow <> to send a problem report. [[trap-12-panic]] === My system crashes with either Fatal trap 12: page fault in kernel mode, or panic:, and spits out a bunch of information. What should I do? The FreeBSD developers are interested in these errors, but need more information than just the error message. Copy the full crash message. Then consult the FAQ section on <>, build a debugging kernel, and get a backtrace. This might sound difficult, but does not require any programming skills. Just follow the instructions. [[proc-table-full]] === What is the meaning of the error maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)? The FreeBSD kernel will only allow a certain number of processes to exist at one time. The number is based on the `kern.maxusers` man:sysctl[8] variable. `kern.maxusers` also affects various other in-kernel limits, such as network buffers. If the machine is heavily loaded, increase `kern.maxusers`. This will increase these other system limits in addition to the maximum number of processes. To adjust the `kern.maxusers` value, see the extref:{handbook}[File/Process Limits, kern-maxfiles] section of the Handbook. While that section refers to open files, the same limits apply to processes. If the machine is lightly loaded but running a very large number of processes, adjust the `kern.maxproc` tunable by defining it in [.filename]#/boot/loader.conf#. The tunable will not get adjusted until the system is rebooted. For more information about tuning tunables, see man:loader.conf[5]. If these processes are being run by a single user, adjust `kern.maxprocperuid` to be one less than the new `kern.maxproc` value. It must be at least one less because one system program, man:init[8], must always be running. [[remote-fullscreen]] === Why do full screen applications on remote machines misbehave? The remote machine may be setting the terminal type to something other than `xterm` which is required by the FreeBSD console. Alternatively the kernel may have the wrong values for the width and height of the terminal. Check the value of the `TERM` environment variable is `xterm`. If the remote machine does not support that try `vt100`. Run `stty -a` to check what the kernel thinks the terminal dimensions are. If they are incorrect, they can be changed by running `stty rows _RR_ cols _CC_`. Alternatively, if the client machine has package:x11/xterm[] installed, then running `resize` will query the terminal for the correct dimensions and set them. [[connection-delay]] === Why does it take so long to connect to my computer via ssh or telnet? The symptom: there is a long delay between the time the TCP connection is established and the time when the client software asks for a password (or, in man:telnet[1]'s case, when a login prompt appears). The problem: more likely than not, the delay is caused by the server software trying to resolve the client's IP address into a hostname. Many servers, including the Telnet and SSH servers that come with FreeBSD, do this to store the hostname in a log file for future reference by the administrator. The remedy: if the problem occurs whenever connecting the client computer to any server, the problem is with the client. If the problem only occurs when someone connects to the server computer, the problem is with the server. If the problem is with the client, the only remedy is to fix the DNS so the server can resolve it. If this is on a local network, consider it a server problem and keep reading. If this is on the Internet, contact your ISP. If the problem is with the server on a local network, configure the server to resolve address-to-hostname queries for the local address range. See man:hosts[5] and man:named[8] for more information. If this is on the Internet, the problem may be that the local server's resolver is not functioning correctly. To check, try to look up another host such as `www.yahoo.com`. If it does not work, that is the problem. Following a fresh install of FreeBSD, it is also possible that domain and name server information is missing from [.filename]#/etc/resolv.conf#. This will often cause a delay in SSH, as the option `UseDNS` is set to `yes` by default in [.filename]#/etc/ssh/sshd_config#. If this is causing the problem, either fill in the missing information in [.filename]#/etc/resolv.conf# or set `UseDNS` to `no` in [.filename]#sshd_config# as a temporary workaround. [[file-table-full]] === Why does file: table is full show up repeatedly in man:dmesg[8]? This error message indicates that the number of available file descriptors have been exhausted on the system. Refer to the extref:{handbook}[kern.maxfiles, kern-maxfiles] section of the extref:{handbook}[Tuning Kernel Limits, configtuning-kernel-limits] section of the Handbook for a discussion and solution. [[computer-clock-skew]] === Why does the clock on my computer keep incorrect time? The computer has two or more clocks, and FreeBSD has chosen to use the wrong one. Run man:dmesg[8], and check for lines that contain `Timecounter`. The one with the highest quality value that FreeBSD chose. [source,shell] .... # dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "TSC" frequency 2998570050 Hz quality 800 Timecounters tick every 1.000 msec .... Confirm this by checking the `kern.timecounter.hardware` man:sysctl[3]. [source,shell] .... # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast .... It may be a broken ACPI timer. The simplest solution is to disable the ACPI timer in [.filename]#/boot/loader.conf#: [.programlisting] .... debug.acpi.disabled="timer" .... Or the BIOS may modify the TSC clock-perhaps to change the speed of the processor when running from batteries, or going into a power saving mode, but FreeBSD is unaware of these adjustments, and appears to gain or lose time. In this example, the `i8254` clock is also available, and can be selected by writing its name to the `kern.timecounter.hardware` man:sysctl[3]. [source,shell] .... # sysctl kern.timecounter.hardware=i8254 kern.timecounter.hardware: TSC -> i8254 .... The computer should now start keeping more accurate time. To have this change automatically run at boot time, add the following line to [.filename]#/etc/sysctl.conf#: [.programlisting] .... kern.timecounter.hardware=i8254 .... [[indefinite-wait-buffer]] === What does the error swap_pager: indefinite wait buffer: mean? This means that a process is trying to page memory from disk, and the page attempt has hung trying to access the disk for more than 20 seconds. It might be caused by bad blocks on the disk drive, disk wiring, cables, or any other disk I/O-related hardware. If the drive itself is bad, disk errors will appear in [.filename]#/var/log/messages# and in the output of `dmesg`. Otherwise, check the cables and connections. [[lock-order-reversal]] === What is a lock order reversal? The FreeBSD kernel uses a number of resource locks to arbitrate contention for certain resources. When multiple kernel threads try to obtain multiple resource locks, there's always the potential for a deadlock, where two threads have each obtained one of the locks and blocks forever waiting for the other thread to release one of the other locks. This sort of locking problem can be avoided if all threads obtain the locks in the same order. A run-time lock diagnostic system called man:witness[4], enabled in FreeBSD-CURRENT and disabled by default for stable branches and releases, detects the potential for deadlocks due to locking errors, including errors caused by obtaining multiple resource locks with a different order from different parts of the kernel. The man:witness[4] framework tries to detect this problem as it happens, and reports it by printing a message to the system console about a `lock order reversal` (often referred to also as LOR). It is possible to get false positives, as man:witness[4] is conservative. A true positive report _does not_ mean that a system is dead-locked; instead it should be understood as a warning that a deadlock could have happened here. [NOTE] ==== Problematic LORs tend to get fixed quickly, so check the {freebsd-current} before posting to it. ==== [[called-with-non-sleepable-locks-held]] === What does Called ... with the following non-sleepable locks held mean? This means that a function that may sleep was called while a mutex (or other unsleepable) lock was held. The reason this is an error is because mutexes are not intended to be held for long periods of time; they are supposed to only be held to maintain short periods of synchronization. This programming contract allows device drivers to use mutexes to synchronize with the rest of the kernel during interrupts. Interrupts (under FreeBSD) may not sleep. Hence it is imperative that no subsystem in the kernel block for an extended period while holding a mutex. To catch such errors, assertions may be added to the kernel that interact with the man:witness[4] subsystem to emit a warning or fatal error (depending on the system configuration) when a potentially blocking call is made while holding a mutex. In summary, such warnings are non-fatal, however with unfortunate timing they could cause undesirable effects ranging from a minor blip in the system's responsiveness to a complete system lockup. For additional information about locking in FreeBSD see man:locking[9]. [[touch-not-found]] === Why does buildworld/installworld die with the message touch: not found? This error does not mean that the man:touch[1] utility is missing. The error is instead probably due to the dates of the files being set sometime in the future. If the CMOS clock is set to local time, run `adjkerntz -i` to adjust the kernel clock when booting into single-user mode. [[applications]] == User Applications [[user-apps]] === Where are all the user applications? Refer to link:https://www.FreeBSD.org/ports/[the ports page] for info on software packages ported to FreeBSD. Most ports should work on all supported versions of FreeBSD. Those that do not are specifically marked as such. Each time a FreeBSD release is made, a snapshot of the ports tree at the time of release is also included in the [.filename]#ports/# directory. FreeBSD supports compressed binary packages to easily install and uninstall ports. Use man:pkg[7] to control the installation of packages. [[how-do-download-ports-tree]] === How do I download the Ports tree? Should I be using Git? See crossref:handbook[ports-using-installation-methods,Installing the Ports Collection]. [[ports-4x]] === Why can I not build this port on my {rel2-relx} -, or {rel-relx} -STABLE machine? If the installed FreeBSD version lags significantly behind _-CURRENT_ or _-STABLE_, update the Ports Collection using the instructions in extref:{handbook}[Using the Ports Collection, ports-using]. If the system is up-to-date, someone might have committed a change to the port which works for _-CURRENT_ but which broke the port for _-STABLE_. https://bugs.FreeBSD.org/submit/[Submit] a bug report, since the Ports Collection is supposed to work for both the _-CURRENT_ and _-STABLE_ branches. [[make-index]] === I just tried to build INDEX using make index, and it failed. Why? First, make sure that the Ports Collection is up-to-date. Errors that affect building [.filename]#INDEX# from an up-to-date copy of the Ports Collection are high-visibility and are thus almost always fixed immediately. There are rare cases where [.filename]#INDEX# will not build due to odd cases involving `OPTIONS_SET` being set in [.filename]#make.conf#. If you suspect that this is the case, try to make [.filename]#INDEX# with those variables turned off before reporting it to {freebsd-ports}. [[ports-update]] === I updated the sources, now how do I update my installed ports? FreeBSD does not include a port upgrading tool, but it does have some tools to make the upgrade process somewhat easier. Additional tools are available to simplify port handling and are described the extref:{handbook}[Upgrading Ports, ports-using] section in the FreeBSD Handbook. [[ports-major-upgrade]] === Do I need to recompile every port each time I perform a major version update? Yes! While a recent system will run with software compiled under an older release, things will randomly crash and fail to work once other ports are installed or updated. When the system is upgraded, various shared libraries, loadable modules, and other parts of the system will be replaced with newer versions. Applications linked against the older versions may fail to start or, in other cases, fail to function properly. For more information, see extref:{handbook}[the section on upgrades, freebsdupdate-upgrade] in the FreeBSD Handbook. [[ports-minor-upgrade]] === Do I need to recompile every port each time I perform a minor version update? In general, no. FreeBSD developers do their utmost to guarantee binary compatibility across all releases with the same major version number. Any exceptions will be documented in the Release Notes, and advice given there should be followed. [[minimal-sh]] === Why is /bin/sh so minimal? Why does FreeBSD not use bash or another shell? Many people need to write shell scripts which will be portable across many systems. That is why POSIX(R) specifies the shell and utility commands in great detail. Most scripts are written in Bourne shell (man:sh[1]), and because several important programming interfaces (man:make[1], man:system[3], man:popen[3], and analogues in higher-level scripting languages like Perl and Tcl) are specified to use the Bourne shell to interpret commands. As the Bourne shell is so often and widely used, it is important for it to be quick to start, be deterministic in its behavior, and have a small memory footprint. The existing implementation is our best effort at meeting as many of these requirements simultaneously as we can. To keep `/bin/sh` small, we have not provided many of the convenience features that other shells have. That is why other more featureful shells like `bash`, `scsh`, man:tcsh[1], and `zsh` are available. Compare the memory utilization of these shells by looking at the "VSZ" and "RSS" columns in a `ps -u` listing. [[kernelconfig]] == Kernel Configuration [[make-kernel]] === I would like to customize my kernel. Is it difficult? Not at all! Check out the extref:{handbook}[kernel config section of the Handbook, kernelconfig]. [NOTE] ==== The new [.filename]#kernel# will be installed to the [.filename]#/boot/kernel# directory along with its modules, while the old kernel and its modules will be moved to the [.filename]#/boot/kernel.old# directory. If a mistake is made in the configuration, simply boot the previous version of the kernel. ==== [[why-kernel-big]] === Why is my kernel so big? `GENERIC` kernels shipped with FreeBSD are compiled in _debug mode_. Kernels built in debug mode contain debug data in separate files that are used for debugging. FreeBSD releases prior to 11.0 store these debug files in the same directory as the kernel itself, [.filename]#/boot/kernel/#. In FreeBSD 11.0 and later the debug files are stored in [.filename]#/usr/lib/debug/boot/kernel/#. Note that there will be little or no performance loss from running a debug kernel, and it is useful to keep one around in case of a system panic. When running low on disk space, there are different options to reduce the size of [.filename]#/boot/kernel/# and [.filename]#/usr/lib/debug/#. To not install the symbol files, make sure the following line exists in [.filename]#/etc/src.conf#: [.programlisting] .... WITHOUT_KERNEL_SYMBOLS=yes .... For more information see man:src.conf[5]. If you want to avoid building debug files altogether, make sure that both of the following are true: * This line does not exist in the kernel configuration file: + [.programlisting] .... makeoptions DEBUG=-g .... * Do not run man:config[8] with `-g`. Either of the above settings will cause the kernel to be built in debug mode. To build and install only the specified modules, list them in [.filename]#/etc/make.conf#: [.programlisting] .... MODULES_OVERRIDE= accf_http ipfw .... Replace _accf_httpd ipfw_ with a list of needed modules. Only the listed modules will be built. This reduces the size of the kernel directory and decreases the amount of time needed to build the kernel. For more information, read [.filename]#/usr/share/examples/etc/make.conf#. Unneeded devices can be removed from the kernel to further reduce the size. See <> for more information. To put any of these options into effect, follow the instructions to extref:{handbook}[build and install, kernelconfig-building] the new kernel. For reference, the FreeBSD 11 amd64 kernel ([.filename]#/boot/kernel/kernel#) is approximately 25 MB. [[generic-kernel-build-failure]] === Why does every kernel I try to build fail to compile, even GENERIC? There are a number of possible causes for this problem: * The source tree is different from the one used to build the currently running system. When attempting an upgrade, read [.filename]#/usr/src/UPDATING#, paying particular attention to the "COMMON ITEMS" section at the end. * The `make buildkernel` did not complete successfully. The `make buildkernel` target relies on files generated by the `make buildworld` target to complete its job correctly. * Even when building <>, it is possible that the source tree was fetched at a time when it was either being modified or it was broken. Only releases are guaranteed to be buildable, although <> builds fine the majority of the time. Try re-fetching the source tree and see if the problem goes away. Try using a different mirror in case the previous one is having problems. [[scheduler-in-use]] === Which scheduler is in use on a running system? The name of the scheduler currently being used is directly available as the value of the `kern.sched.name` sysctl: [source,shell] .... % sysctl kern.sched.name kern.sched.name: ULE .... [[scheduler-kern-quantum]] === What is kern.sched.quantum? `kern.sched.quantum` is the maximum number of ticks a process can run without being preempted in the 4BSD scheduler. [[disks]] == Disks, File Systems, and Boot Loaders [[adding-disks]] === How can I add my new hard disk to my FreeBSD system? See the extref:{handbook}[Adding Disks, disks-adding] section in the FreeBSD Handbook. [[new-huge-disk]] === How do I move my system over to my huge new disk? The best way is to reinstall the operating system on the new disk, then move the user data over. This is highly recommended when tracking _-STABLE_ for more than one release or when updating a release instead of installing a new one. Install booteasy on both disks with man:boot0cfg[8] and dual boot until you are happy with the new configuration. Skip the next paragraph to find out how to move the data after doing this. Alternatively, partition and label the new disk with either man:sade[8] or man:gpart[8]. If the disks are MBR-formatted, booteasy can be installed on both disks with man:boot0cfg[8] so that the computer can dual boot to the old or new system after the copying is done. Once the new disk set up, the data cannot just be copied. Instead, use tools that understand device files and system flags, such as man:dump[8]. Although it is recommended to move the data while in single-user mode, it is not required. When the disks are formatted with UFS, never use anything but man:dump[8] and man:restore[8] to move the root file system. These commands should also be used when moving a single partition to another empty partition. The sequence of steps to use `dump` to move the data from one UFS partitions to a new partition is: [.procedure] ==== . `newfs` the new partition. . `mount` it on a temporary mount point. . `cd` to that directory. . `dump` the old partition, piping output to the new one. ==== For example, to move [.filename]#/dev/ada1s1a# with [.filename]#/mnt# as the temporary mount point, type: [source,shell] .... # newfs /dev/ada1s1a # mount /dev/ada1s1a /mnt # cd /mnt # dump 0af - / | restore rf - .... Rearranging partitions with `dump` takes a bit more work. To merge a partition like [.filename]#/var# into its parent, create the new partition large enough for both, move the parent partition as described above, then move the child partition into the empty directory that the first move created: [source,shell] .... # newfs /dev/ada1s1a # mount /dev/ada1s1a /mnt # cd /mnt # dump 0af - / | restore rf - # cd var # dump 0af - /var | restore rf - .... To split a directory from its parent, say putting [.filename]#/var# on its own partition when it was not before, create both partitions, then mount the child partition on the appropriate directory in the temporary mount point, then move the old single partition: [source,shell] .... # newfs /dev/ada1s1a # newfs /dev/ada1s1d # mount /dev/ada1s1a /mnt # mkdir /mnt/var # mount /dev/ada1s1d /mnt/var # cd /mnt # dump 0af - / | restore rf - .... The man:cpio[1] and man:pax[1] utilities are also available for moving user data. These are known to lose file flag information, so use them with caution. [[safe-softupdates]] === Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems. What about Journaled Soft Updates? Short answer: Soft Updates can usually be safely used on all partitions. Long answer: Soft Updates has two characteristics that may be undesirable on certain partitions. First, a Soft Updates partition has a small chance of losing data during a system crash. The partition will not be corrupted as the data will simply be lost. Second, Soft Updates can cause temporary space shortages. When using Soft Updates, the kernel can take up to thirty seconds to write changes to the physical disk. When a large file is deleted the file still resides on disk until the kernel actually performs the deletion. This can cause a very simple race condition. Suppose one large file is deleted and another large file is immediately created. The first large file is not yet actually removed from the physical disk, so the disk might not have enough room for the second large file. This will produce an error that the partition does not have enough space, even though a large chunk of space has just been released. A few seconds later, the file creation works as expected. If a system should crash after the kernel accepts a chunk of data for writing to disk, but before that data is actually written out, data could be lost. This risk is extremely small, but generally manageable. These issues affect all partitions using Soft Updates. So, what does this mean for the root partition? Vital information on the root partition changes very rarely. If the system crashed during the thirty-second window after such a change is made, it is possible that data could be lost. This risk is negligible for most applications, but be aware that it exists. If the system cannot tolerate this much risk, do not use Soft Updates on the root file system! [.filename]#/# is traditionally one of the smallest partitions. If [.filename]#/tmp# is on [.filename]#/#, there may be intermittent space problems. Symlinking [.filename]#/tmp# to [.filename]#/var/tmp# will solve this problem. Finally, man:dump[8] does not work in live mode (-L) on a filesystem, with Journaled Soft Updates (SU+J). [[mount-foreign-fs]] === Can I mount other foreign file systems under FreeBSD? FreeBSD supports a variety of other file systems. UFS:: UFS CD-ROMs can be mounted directly on FreeBSD. Mounting disk partitions from Digital UNIX and other systems that support UFS may be more complex, depending on the details of the disk partitioning for the operating system in question. ext2/ext3:: FreeBSD supports `ext2fs`, `ext3fs`, and `ext4fs` partitions. See man:ext2fs[5] for more information. NTFS:: FUSE based NTFS support is available as a port (package:sysutils/fusefs-ntfs[]). For more information, see man:ntfs-3g[8]. FAT:: FreeBSD includes a read-write FAT driver. For more information, see man:mount_msdosfs[8]. ZFS:: FreeBSD includes a port of Sun(TM)'s ZFS driver. The current recommendation is to use it only on amd64 platforms with sufficient memory. For more information, see man:zfs[8]. FreeBSD includes the Network File System NFS and the FreeBSD Ports Collection provides several FUSE applications to support many other file systems. [[mount-dos]] === How do I mount a secondary DOS partition? The secondary DOS partitions are found after _all_ the primary partitions. For example, if `E` is the second DOS partition on the second SCSI drive, there will be a device file for "slice 5" in [.filename]#/dev#. To mount it: [source,shell] .... # mount -t msdosfs /dev/da1s5 /dos/e .... [[crypto-file-system]] === Is there a cryptographic file system for FreeBSD? Yes, man:gbde[8] and man:geli[8]. See the extref:{handbook}[Encrypting Disk Partitions, disks-encrypting] section of the FreeBSD Handbook. [[grub-loader]] === How do I boot FreeBSD and Linux(R) using GRUB? To boot FreeBSD using GRUB, add the following to either [.filename]#/boot/grub/menu.lst# or [.filename]#/boot/grub/grub.conf#, depending upon which is used by the Linux(R) distribution. [.programlisting] .... title FreeBSD 9.1 root (hd0,a) kernel /boot/loader .... Where _hd0,a_ points to the root partition on the first disk. To specify the slice number, use something like this _(hd0,2,a)_. By default, if the slice number is omitted, GRUB searches the first slice which has the `a` partition. [[booteasy-loader]] === How do I boot FreeBSD and Linux(R) using BootEasy? Install LILO at the start of the Linux(R) boot partition instead of in the Master Boot Record. Then boot LILO from BootEasy. This is recommended when running Windows(R) and Linux(R) as it makes it simpler to get Linux(R) booting again if Windows(R) is reinstalled. [[changing-bootprompt]] === How do I change the boot prompt from ??? to something more meaningful? This cannot be accomplished with the standard boot manager without rewriting it. There are a number of other boot managers in the [.filename]#sysutils# category of the Ports Collection. [[removable-drives]] === How do I use a new removable drive? If the drive already has a file system on it, use a command like this: [source,shell] .... # mount -t msdosfs /dev/da0s1 /mnt .... If the drive will only be used with FreeBSD systems, partition it with UFS or ZFS. This will provide long filename support, improvement in performance, and stability. If the drive will be used by other operating systems, a more portable choice, such as msdosfs, is better. [source,shell] .... # dd if=/dev/zero of=/dev/da0 count=2 # gpart create -s GPT /dev/da0 # gpart add -t freebsd-ufs /dev/da0 .... Finally, create a new file system: [source,shell] .... # newfs /dev/da0p1 .... and mount it: [source,shell] .... # mount /dev/da0s1 /mnt .... It is a good idea to add a line to [.filename]#/etc/fstab# (see man:fstab[5]) so you can just type `mount /mnt` in the future: [.programlisting] .... /dev/da0p1 /mnt ufs rw,noauto 0 0 .... [[mount-cd-superblock]] === Why do I get Incorrect super block when mounting a CD? The type of device to mount must be specified. This is described in the Handbook section on extref:{handbook}[Using Data CDs, mounting-cd]. [[cdrom-not-configured]] === Why do I get Device not configured when mounting a CD? This generally means that there is no CD in the drive, or the drive is not visible on the bus. Refer to the extref:{handbook}[Using Data CDs, mounting-cd] section of the Handbook for a detailed discussion of this issue. [[cdrom-unicode-filenames]] === Why do all non-English characters in filenames show up as ? on my CDs when mounted in FreeBSD? The CD probably uses the "Joliet" extension for storing information about files and directories. This is discussed in the Handbook section on extref:{handbook}[Using Data CD-ROMs, mounting-cd]. [[burncd-isofs]] === A CD burned under FreeBSD cannot be read under any other operating system. Why? This means a raw file was burned to the CD, rather than creating an ISO 9660 file system. Take a look at the Handbook section on extref:{handbook}[Using Data CDs]. [[copy-cd]] === How can I create an image of a data CD? This is discussed in the Handbook section on extref:{handbook}[Writing Data to an ISO File System, mkisofs]. For more on working with CD-ROMs, see the extref:{handbook}[Creating CDs Section, creating-cds] in the Storage chapter in the Handbook. [[mount-audio-CD]] === Why can I not mount an audio CD? Trying to mount an audio CD will produce an error like `cd9660: /dev/cd0: Invalid argument`. This is because `mount` only works on file systems. Audio CDs do not have file systems; they just have data. Instead, use a program that reads audio CDs, such as the package:audio/xmcd[] package or port. [[multi-session-CD]] === How do I mount a multi-session CD? By default, man:mount[8] will attempt to mount the last data track (session) of a CD. To load an earlier session, use the `-s` command line argument. Refer to man:mount_cd9660[8] for specific examples. [[user-floppymount]] === How do I let ordinary users mount CD-ROMs, DVDs, USB drives, and other removable media? As `root` set the sysctl variable `vfs.usermount` to `1`. [source,shell] .... # sysctl vfs.usermount=1 .... To make this persist across reboots, add the line `vfs.usermount=1` to [.filename]#/etc/sysctl.conf# so that it is reset at system boot time. Users can only mount devices they have read permissions to. To allow users to mount a device permissions must be set in [.filename]#/etc/devfs.conf#. For example, to allow users to mount the first USB drive add: [.programlisting] .... # Allow all users to mount a USB drive. own /dev/da0 root:operator perm /dev/da0 0666 .... All users can now mount devices they could read onto a directory that they own: [source,shell] .... % mkdir ~/my-mount-point % mount -t msdosfs /dev/da0 ~/my-mount-point .... Unmounting the device is simple: [source,shell] .... % umount ~/my-mount-point .... Enabling `vfs.usermount`, however, has negative security implications. A better way to access MS-DOS(R) formatted media is to use the package:emulators/mtools[] package in the Ports Collection. [NOTE] ==== The device name used in the previous examples must be changed according to the configuration. ==== [[du-vs-df]] === The du and df commands show different amounts of disk space available. What is going on? This is due to how these commands actually work. `du` goes through the directory tree, measures how large each file is, and presents the totals. `df` just asks the file system how much space it has left. They seem to be the same thing, but a file without a directory entry will affect `df` but not `du`. When a program is using a file, and the file is deleted, the file is not really removed from the file system until the program stops using it. The file is immediately deleted from the directory listing, however. As an example, consider a file large enough to affect the output of `du` and `df`. A file being viewed with `more` can be deleted without causing an error. The entry is removed from the directory so no other program or user can access it. However, `du` shows that it is gone as it has walked the directory tree and the file is not listed. `df` shows that it is still there, as the file system knows that `more` is still using that space. Once the `more` session ends, `du` and `df` will agree. This situation is common on web servers. Many people set up a FreeBSD web server and forget to rotate the log files. The access log fills up [.filename]#/var#. The new administrator deletes the file, but the system still complains that the partition is full. Stopping and restarting the web server program would free the file, allowing the system to release the disk space. To prevent this from happening, set up man:newsyslog[8]. Note that Soft Updates can delay the freeing of disk space and it can take up to 30 seconds for the change to be visible. [[add-swap-space]] === How can I add more swap space? This section extref:{handbook}[of the Handbook, adding-swap-space] describes how to do this. [[manufacturer-disk-size]] === Why does FreeBSD see my disk as smaller than the manufacturer says it is? Disk manufacturers calculate gigabytes as a billion bytes each, whereas FreeBSD calculates them as 1,073,741,824 bytes each. This explains why, for example, FreeBSD's boot messages will report a disk that supposedly has 80 GB as holding 76,319 MB. Also note that FreeBSD will (by default) <> 8% of the disk space. [[disk-more-than-full]] === How is it possible for a partition to be more than 100% full? A portion of each UFS partition (8%, by default) is reserved for use by the operating system and the `root` user. man:df[1] does not count that space when calculating the `Capacity` column, so it can exceed 100%. Notice that the `Blocks` column is always greater than the sum of the `Used` and `Avail` columns, usually by a factor of 8%. For more details, look up `-m` in man:tunefs[8]. [[all-about-zfs]] == ZFS [[how-much-ram-for-zfs]] === What is the minimum amount of RAM one should have to run ZFS? A minimum of 4GB of RAM is required for comfortable usage, but individual workloads can vary widely. [[what-is-zil]] === What is the ZIL and when does it get used? The ZIL (ZFS intent log) is a write log used to implement posix write commitment semantics across crashes. Normally writes are bundled up into transaction groups and written to disk when filled ("Transaction Group Commit"). However syscalls like man:fsync[2] require a commitment that the data is written to stable storage before returning. The ZIL is needed for writes that have been acknowledged as written but which are not yet on disk as part of a transaction. The transaction groups are timestamped. In the event of a crash the last valid timestamp is found and missing data is merged in from the ZIL. [[need-ssd-for-zil]] === Do I need a SSD for ZIL? By default, ZFS stores the ZIL in the pool with all the data. If an application has a heavy write load, storing the ZIL in a separate device that has very fast synchronous, sequential write performance can improve overall system performance. For other workloads, a SSD is unlikely to make much of an improvement. [[what-is-l2arc]] === What is the L2ARC? The L2ARC is a read cache stored on a fast device such as an SSD. This cache is not persistent across reboots. Note that RAM is used as the first layer of cache and the L2ARC is only needed if there is insufficient RAM. L2ARC needs space in the ARC to index it. So, perversely, a working set that fits perfectly in the ARC will not fit perfectly any more if a L2ARC is used because part of the ARC is holding the L2ARC index, pushing part of the working set into the L2ARC which is slower than RAM. [[should-enable-dedup]] === Is enabling deduplication advisable? Generally speaking, no. Deduplication takes up a significant amount of RAM and may slow down read and write disk access times. Unless one is storing data that is very heavily duplicated, such as virtual machine images or user backups, it is possible that deduplication will do more harm than good. Another consideration is the inability to revert deduplication status. If data is written when deduplication is enabled, disabling dedup will not cause those blocks which were deduplicated to be replicated until they are next modified. Deduplication can also lead to some unexpected situations. In particular, deleting files may become much slower. [[zpool-fully-full]] === I cannot delete or create files on my ZFS pool. How can I fix this? This could happen because the pool is 100% full. ZFS requires space on the disk to write transaction metadata. To restore the pool to a usable state, truncate the file to delete: [source,shell] .... % truncate -s 0 unimportant-file .... File truncation works because a new transaction is not started, new spare blocks are created instead. [NOTE] ==== On systems with additional ZFS dataset tuning, such as deduplication, the space may not be immediately available ==== [[zfs-ssd-trim]] === Does ZFS support TRIM for Solid State Drives? ZFS TRIM support was added to FreeBSD 10-CURRENT with revision link:https://svnweb.freebsd.org/changeset/base/240868[r240868]. ZFS TRIM support was added to all FreeBSD-STABLE branches in link:https://svnweb.freebsd.org/changeset/base/252162[r252162] and link:https://svnweb.freebsd.org/changeset/base/251419[r251419], respectively. ZFS TRIM is enabled by default, and can be turned off by adding this line to [.filename]#/etc/sysctl.conf#: [.programlisting] .... vfs.zfs.trim.enabled=0 .... [NOTE] ==== ZFS TRIM support was added to GELI as of link:https://svnweb.freebsd.org/changeset/base/286444[r286444]. Please see man:geli[8] and the `-T` switch. ==== [[admin]] == System Administration [[startup-config-files]] === Where are the system start-up configuration files? The primary configuration file is [.filename]#/etc/defaults/rc.conf# which is described in man:rc.conf[5]. System startup scripts such as [.filename]#/etc/rc# and [.filename]#/etc/rc.d#, which are described in man:rc[8], include this file. _Do not edit this file!_ Instead, to edit an entry in [.filename]#/etc/defaults/rc.conf#, copy the line into [.filename]#/etc/rc.conf# and change it there. For example, to start man:sshd[8], the included OpenSSH daemon: [source,shell] .... # echo 'sshd_enable="YES"' >> /etc/rc.conf .... Alternatively, use man:sysrc[8] to modify [.filename]#/etc/rc.conf#: [source,shell] .... # sysrc sshd_enable="YES" .... To start up local services, place shell scripts in the [.filename]#/usr/local/etc/rc.d# directory. These shell scripts should be set executable, the default file mode is `555`. [[adding-users]] === How do I add a user easily? Use the man:adduser[8] command, or the man:pw[8] command for more complicated situations. To remove the user, use the man:rmuser[8] command or, if necessary, man:pw[8]. [[root-not-found-cron-errors]] === Why do I keep getting messages like root: not found after editing /etc/crontab? This is normally caused by editing the system crontab. This is not the correct way to do things as the system crontab has a different format to the per-user crontabs. The system crontab has an extra field, specifying which user to run the command as. man:cron[8] assumes this user is the first word of the command to execute. Since no such command exists, this error message is displayed. To delete the extra, incorrect crontab: [source,shell] .... # crontab -r .... [[su-wheel-group]] === Why do I get the error, you are not in the correct group to su root when I try to su to root? This is a security feature. In order to `su` to `root`, or any other account with superuser privileges, the user account must be a member of the `wheel` group. If this feature were not there, anybody with an account on a system who also found out ``root``'s password would be able to gain superuser level access to the system. To allow someone to `su` to `root`, put them in the `wheel` group using `pw`: [source,shell] .... # pw groupmod wheel -m lisa .... The above example will add user `lisa` to the group `wheel`. [[rcconf-readonly]] === I made a mistake in rc.conf, or another startup file, and now I cannot edit it because the file system is read-only. What should I do? Restart the system using `boot -s` at the loader prompt to enter single-user mode. When prompted for a shell pathname, press kbd:[Enter] and run `mount -urw /` to re-mount the root file system in read/write mode. You may also need to run `mount -a -t ufs` to mount the file system where your favorite editor is defined. If that editor is on a network file system, either configure the network manually before mounting the network file systems, or use an editor which resides on a local file system, such as man:ed[1]. In order to use a full screen editor such as man:vi[1] or man:emacs[1], run `export TERM=xterm` so that these editors can load the correct data from the man:termcap[5] database. After performing these steps, edit [.filename]#/etc/rc.conf# to fix the syntax error. The error message displayed immediately after the kernel boot messages should indicate the number of the line in the file which is at fault. [[printer-setup]] === Why am I having trouble setting up my printer? See the extref:{handbook}[Handbook entry on printing, printing] for troubleshooting tips. [[keyboard-mappings]] === How can I correct the keyboard mappings for my system? Refer to the Handbook section on extref:{handbook}[using localization, using-localization], specifically the section on extref:{handbook}[console setup, setting-console]. [[user-quotas]] === Why can I not get user quotas to work properly? . It is possible that the kernel is not configured to use quotas. In this case, add the following line to the kernel configuration file and recompile the kernel: + [.programlisting] .... options QUOTA .... + Refer to the extref:{handbook}[Handbook entry on quotas, quotas] for full details. . Do not turn on quotas on [.filename]#/#. . Put the quota file on the file system that the quotas are to be enforced on: + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | File System | Quota file |[.filename]#/usr# |[.filename]#/usr/admin/quotas# |[.filename]#/home# |[.filename]#/home/admin/quotas# |... |... |=== [[sysv-ipc]] === Does FreeBSD support System V IPC primitives? Yes, FreeBSD supports System V-style IPC, including shared memory, messages and semaphores, in the [.filename]#GENERIC# kernel. With a custom kernel, support may be loaded with the [.filename]#sysvshm.ko#, [.filename]#sysvsem.ko# and [.filename]#sysvmsg.ko# kernel modules, or enabled in the custom kernel by adding the following lines to the kernel configuration file: [.programlisting] .... options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging .... Recompile and install the kernel. [[sendmail-alternative]] === What other mail-server software can I use instead of Sendmail? The http://www.sendmail.org/[Sendmail] server is the default mail-server software for FreeBSD, but it can be replaced with another MTA installed from the Ports Collection. Available ports include package:mail/exim[], package:mail/postfix[], and package:mail/qmail[]. Search the mailing lists for discussions regarding the advantages and disadvantages of the available MTAs. [[forgot-root-pw]] === I have forgotten the root password! What do I do? Do not panic! Restart the system, type `boot -s` at the `Boot:` prompt to enter single-user mode. At the question about the shell to use, hit kbd:[Enter] which will display a # prompt. Enter `mount -urw /` to remount the root file system read/write, then run `mount -a` to remount all the file systems. Run `passwd root` to change the `root` password then run man:exit[1] to continue booting. [NOTE] ==== If you are still prompted to give the `root` password when entering the single-user mode, it means that the console has been marked as `insecure` in [.filename]#/etc/ttys#. In this case, it will be required to boot from a FreeBSD installation disk, choose the [.guimenuitem]#Live CD# or [.guimenuitem]#Shell# at the beginning of the install process and issue the commands mentioned above. Mount the specific partition in this case and then chroot to it. For example, replace `mount -urw /` with `mount /dev/ada0p1 /mnt; chroot /mnt` for a system on _ada0p1_. ==== [NOTE] ==== If the root partition cannot be mounted from single-user mode, it is possible that the partitions are encrypted and it is impossible to mount them without the access keys. For more information see the section about encrypted disks in the FreeBSD extref:{handbook}[Handbook, disks-encrypting]. ==== [[CAD-reboot]] === How do I keep kbd:[Control] + kbd:[Alt] + kbd:[Delete] from rebooting the system? When using man:vt[4], the default console driver, this can be done by setting the following man:sysctl[8]: [source,shell] .... # sysctl kern.vt.kbd_reboot=0 .... [[dos-to-unix-txt]] === How do I reformat DOS text files to UNIX(R) ones? Use this man:perl[1] command: [source,shell] .... % perl -i.bak -npe 's/\r\n/\n/g' file(s) .... where _file(s)_ is one or more files to process. The modification is done in-place, with the original file stored with a [.filename]#.bak# extension. Alternatively, use man:tr[1]: [source,shell] .... % tr -d '\r' < dos-text-file > unix-file .... _dos-text-file_ is the file containing DOS text while _unix-file_ will contain the converted output. This can be quite a bit faster than using `perl`. Yet another way to reformat DOS text files is to use the package:converters/dosunix[] port from the Ports Collection. Consult its documentation about the details. [[reread-rc]] === How do I re-read [.filename]#/etc/rc.conf# and re-start [.filename]#/etc/rc# without a reboot? Go into single-user mode and then back to multi-user mode: [source,shell] .... # shutdown now # return # exit .... [[release-candidate]] === I tried to update my system to the latest _-STABLE_, but got _-BETAx_, _-RC_ or __-PRERELEASE__! What is going on? Short answer: it is just a name. _RC_ stands for "Release Candidate". It signifies that a release is imminent. In FreeBSD, _-PRERELEASE_ is typically synonymous with the code freeze before a release. (For some releases, the _-BETA_ label was used in the same way as _-PRERELEASE_.) Long answer: FreeBSD derives its releases from one of two places. Major, dot-zero, releases, such as 9.0-RELEASE are branched from the head of the development stream, commonly referred to as <>. Minor releases, such as 6.3-RELEASE or 5.2-RELEASE, have been snapshots of the active <> branch. Starting with 4.3-RELEASE, each release also now has its own branch which can be tracked by people requiring an extremely conservative rate of development (typically only security advisories). When a release is about to be made, the branch from which it will be derived from has to undergo a certain process. Part of this process is a code freeze. When a code freeze is initiated, the name of the branch is changed to reflect that it is about to become a release. For example, if the branch used to be called 6.2-STABLE, its name will be changed to 6.3-PRERELEASE to signify the code freeze and signify that extra pre-release testing should be happening. Bug fixes can still be committed to be part of the release. When the source code is in shape for the release the name will be changed to 6.3-RC to signify that a release is about to be made from it. Once in the RC stage, only the most critical bugs found can be fixed. Once the release (6.3-RELEASE in this example) and release branch have been made, the branch will be renamed to 6.3-STABLE. For more information on version numbers and the various Subversion branches, refer to the extref:{releng}[Release Engineering] article. [[kernel-chflag-failure]] === I tried to install a new kernel, and the man:chflags[1] failed. How do I get around this? Short answer: the security level is greater than 0. Reboot directly to single-user mode to install the kernel. Long answer: FreeBSD disallows changing system flags at security levels greater than 0. To check the current security level: [source,shell] .... # sysctl kern.securelevel .... The security level cannot be lowered in multi-user mode, so boot to single-user mode to install the kernel, or change the security level in [.filename]#/etc/rc.conf# then reboot. See the man:init[8] manual page for details on `securelevel`, and see [.filename]#/etc/defaults/rc.conf# and the man:rc.conf[5] manual page for more information on [.filename]#rc.conf#. [[kernel-securelevel-time]] === I cannot change the time on my system by more than one second! How do I get around this? Short answer: the system is at a security level greater than 1. Reboot directly to single-user mode to change the date. Long answer: FreeBSD disallows changing the time by more that one second at security levels greater than 1. To check the security level: [source,shell] .... # sysctl kern.securelevel .... The security level cannot be lowered in multi-user mode. Either boot to single-user mode to change the date or change the security level in [.filename]#/etc/rc.conf# and reboot. See the man:init[8] manual page for details on `securelevel`, and see [.filename]#/etc/defaults/rc.conf# and the man:rc.conf[5] manual page for more information on [.filename]#rc.conf#. [[statd-mem-leak]] === Why is rpc.statd using 256 MB of memory? No, there is no memory leak, and it is not using 256 MB of memory. For convenience, `rpc.statd` maps an obscene amount of memory into its address space. There is nothing terribly wrong with this from a technical standpoint; it just throws off things like man:top[1] and man:ps[1]. man:rpc.statd[8] maps its status file (resident on [.filename]#/var#) into its address space; to save worrying about remapping the status file later when it needs to grow, it maps the status file with a generous size. This is very evident from the source code, where one can see that the length argument to man:mmap[2] is `0x10000000`, or one sixteenth of the address space on an IA32, or exactly 256 MB. [[unsetting-schg]] === Why can I not unset the schg file flag? The system is running at securelevel greater than 0. Lower the securelevel and try again. For more information, see <> and the man:init[8] manual page. [[vnlru]] === What is vnlru? `vnlru` flushes and frees vnodes when the system hits the `kern.maxvnodes` limit. This kernel thread sits mostly idle, and only activates when there is a huge amount of RAM and users are accessing tens of thousands of tiny files. [[top-memory-states]] === What do the various memory states displayed by top mean? * `Active`: pages recently statistically used. * `Inactive`: pages recently statistically unused. * `Laundry`: pages recently statistically unused but known to be dirty, that is, whose contents needs to be paged out before they can be reused. * `Free`: pages without data content, which can be immediately reused. * `Wired`: pages that are fixed into memory, usually for kernel purposes, but also sometimes for special use in processes. Pages are most often written to disk (sort of a VM sync) when they are in the laundry state, but active or inactive pages can also be synced. This depends upon the CPU tracking of the modified bit being available, and in certain situations there can be an advantage for a block of VM pages to be synced, regardless of the queue they belong to. In most common cases, it is best to think of the laundry queue as a queue of relatively unused pages that might or might not be in the process of being written to disk. The inactive queue contains a mix of clean and dirty pages; clean pages near the head of the queue are reclaimed immediately to alleviate a free page shortage, and dirty pages are moved to the laundry queue for deferred processing. There are some other flags (e.g., busy flag or busy count) that might modify some of the described rules. [[free-memory-amount]] === How much free memory is available? There are a couple of kinds of "free memory". The most common is the amount of memory immediately available without reclaiming memory already in use. That is the size of the free pages queue plus some other reserved pages. This amount is exported by the `vm.stats.vm.v_free_count` man:sysctl[8], shown, for instance, by man:top[1]. Another kind of "free memory" is the total amount of virtual memory available to userland processes, which depends on the sum of swap space and usable memory. Other kinds of "free memory" descriptions are also possible, but it is relatively useless to define these, but rather it is important to make sure that the paging rate is kept low, and to avoid running out of swap space. [[var-empty]] === What is [.filename]#/var/empty#? [.filename]#/var/empty# is a directory that the man:sshd[8] program uses when performing privilege separation. The [.filename]#/var/empty# directory is empty, owned by `root` and has the `schg` flag set. This directory should not be deleted. [[newsyslog-expectations]] === I just changed [.filename]#/etc/newsyslog.conf#. How can I check if it does what I expect? To see what man:newsyslog[8] will do, use the following: [source,shell] .... % newsyslog -nrvv .... [[timezone]] === My time is wrong, how can I change the timezone? Use man:tzsetup[8]. [[X11]] == The X Window System and Virtual Consoles [[whatis-X]] === What is the X Window System? The X Window System (commonly `X11`) is the most widely available windowing system capable of running on UNIX(R) or UNIX(R) like systems, including FreeBSD. http://www.x.org/wiki/[The X.Org Foundation] administers the http://en.wikipedia.org/wiki/X_Window_System_core_protocol[X protocol standards], with the current reference implementation, version 11 release 7.7, so references are often shortened to `X11`. Many implementations are available for different architectures and operating systems. An implementation of the server-side code is properly known as an `X server`. [[running-X]] === I want to run Xorg, how do I go about it? To install Xorg do one of the following: Use the package:x11/xorg[] meta-port, which builds and installs every Xorg component. Use package:x11/xorg-minimal[], which builds and installs only the necessary Xorg components. Install Xorg from FreeBSD packages: [source,shell] .... # pkg install xorg .... After the installation of Xorg, follow the instructions from the extref:{handbook}[X11 Configuration, x-config] section of the FreeBSD Handbook. [[running-X-securelevels]] === I tried to run X, but I get a No devices detected. error when I type startx. What do I do now? The system is probably running at a raised `securelevel`. It is not possible to start X at a raised `securelevel` because X requires write access to man:io[4]. For more information, see at the man:init[8] manual page. There are two solutions to the problem: set the `securelevel` back down to zero or run man:xdm[1] (or an alternative display manager) at boot time before the `securelevel` is raised. See <> for more information about running man:xdm[1] at boot time. [[x-and-moused]] === Why does my mouse not work with X? When using man:vt[4], the default console driver, FreeBSD can be configured to support a mouse pointer on each virtual screen. To avoid conflicting with X, man:vt[4] supports a virtual device called [.filename]#/dev/sysmouse#. All mouse events received from the real mouse device are written to the man:sysmouse[4] device via man:moused[8]. To use the mouse on one or more virtual consoles, _and_ use X, see <> and set up man:moused[8]. Then edit [.filename]#/etc/X11/xorg.conf# and make sure the following lines exist: [.programlisting] .... Section "InputDevice" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" ..... .... Starting with Xorg version 7.4, the `InputDevice` sections in [.filename]#xorg.conf# are ignored in favor of autodetected devices. To restore the old behavior, add the following line to the `ServerLayout` or `ServerFlags` section: [.programlisting] .... Option "AutoAddDevices" "false" .... Some people prefer to use [.filename]#/dev/mouse# under X. To make this work, [.filename]#/dev/mouse# should be linked to [.filename]#/dev/sysmouse# (see man:sysmouse[4]) by adding the following line to [.filename]#/etc/devfs.conf# (see man:devfs.conf[5]): [.programlisting] .... link sysmouse mouse .... This link can be created by restarting man:devfs[5] with the following command (as `root`): [source,shell] .... # service devfs restart .... [[x-and-wheel]] === My mouse has a fancy wheel. Can I use it in X? Yes, if X is configured for a 5 button mouse. To do this, add the lines `Buttons 5` and `ZAxisMapping 4 5` to the "InputDevice" section of [.filename]#/etc/X11/xorg.conf#, as seen in this example: [.programlisting] .... Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection .... The mouse can be enabled in Emacs by adding these lines to [.filename]#~/.emacs#: [.programlisting] .... ;; wheel mouse (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) .... [[x-and-synaptic]] === My laptop has a Synaptics touchpad. Can I use it in X? Yes, after configuring a few things to make it work. In order to use the Xorg synaptics driver, first remove `moused_enable` from [.filename]#rc.conf#. To enable synaptics, add the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... hw.psm.synaptics_support="1" .... Add the following to [.filename]#/etc/X11/xorg.conf#: [.programlisting] .... Section "InputDevice" Identifier "Touchpad0" Driver "synaptics" Option "Protocol" "psm" Option "Device" "/dev/psm0" EndSection .... And be sure to add the following into the "ServerLayout" section: [.programlisting] .... InputDevice "Touchpad0" "SendCoreEvents" .... [[no-remote-x11]] === How do I use remote X displays? For security reasons, the default setting is to not allow a machine to remotely open a window. To enable this feature, start X with the optional `-listen_tcp` argument: [source,shell] .... % startx -listen_tcp .... [[virtual-console]] === What is a virtual console and how do I make more? Virtual consoles provide several simultaneous sessions on the same machine without doing anything complicated like setting up a network or running X. When the system starts, it will display a login prompt on the monitor after displaying all the boot messages. Type in your login name and password to start working on the first virtual console. To start another session, perhaps to look at documentation for a program or to read mail while waiting for an FTP transfer to finish, hold down kbd:[Alt] and press kbd:[F2]. This will display the login prompt for the second virtual console. To go back to the original session, press kbd:[Alt+F1]. The default FreeBSD installation has eight virtual consoles enabled. kbd:[Alt+F1], kbd:[Alt+F2], kbd:[Alt+F3], and so on will switch between these virtual consoles. To enable more of virtual consoles, edit [.filename]#/etc/ttys# (see man:ttys[5]) and add entries for [.filename]#ttyv8# to [.filename]#ttyvc#, after the comment on "Virtual terminals": [.programlisting] .... # Edit the existing entry for ttyv8 in /etc/ttys and change # "off" to "on". ttyv8 "/usr/libexec/getty Pc" xterm on secure ttyv9 "/usr/libexec/getty Pc" xterm on secure ttyva "/usr/libexec/getty Pc" xterm on secure ttyvb "/usr/libexec/getty Pc" xterm on secure .... The more virtual terminals, the more resources that are used. This can be problematic on systems with 8 MB RAM or less. Consider changing `secure` to `insecure`. [IMPORTANT] ==== In order to run an X server, at least one virtual terminal must be left to `off` for it to use. This means that only eleven of the Alt-function keys can be used as virtual consoles so that one is left for the X server. ==== For example, to run X and eleven virtual consoles, the setting for virtual terminal 12 should be: [.programlisting] .... ttyvb "/usr/libexec/getty Pc" xterm off secure .... The easiest way to activate the virtual consoles is to reboot. [[vty-from-x]] === How do I access the virtual consoles from X? Use kbd:[Ctrl+Alt+Fn] to switch back to a virtual console. Press kbd:[Ctrl+Alt+F1] to return to the first virtual console. Once at a text console, use kbd:[Alt+Fn] to move between them. To return to the X session, switch to the virtual console running X. If X was started from the command line using `startx`, the X session will attach to the next unused virtual console, not the text console from which it was invoked. For eight active virtual terminals, X will run on the ninth, so use kbd:[Alt+F9]. [[xdm-boot]] === How do I start XDM on boot? There are two schools of thought on how to start man:xdm[1]. One school starts `xdm` from [.filename]#/etc/ttys# (see man:ttys[5]) using the supplied example, while the other sets `xdm_enable=yes` in [.filename]#/etc/rc.conf#. Both are equally valid, and one may work in situations where the other does not. In both cases the result is the same: X will pop up a graphical login prompt. The man:ttys[5] method has the advantage of documenting which vty X will start on and passing the responsibility of restarting the X server on logout to man:init[8]. The man:rc[8] method makes it easy to `kill xdm` if there is a problem starting the X server. When using the man:rc[8] method, `xdm_tty` (default `ttyv8`) can be set in [.filename]#/etc/rc.conf# to choose which vty man:xdm[1] opens on. [[xconsole-failure]] === Why do I get Couldn't open console when I run xconsole? When X is started with `startx`, the permissions on [.filename]#/dev/console# will _not_ get changed, resulting in things like `xterm -C` and `xconsole` not working. This is because of the way console permissions are set by default. On a multi-user system, one does not necessarily want just any user to be able to write on the system console. For users who are logging directly onto a machine with a VTY, the man:fbtab[5] file exists to solve such problems. In a nutshell, make sure an uncommented line of the form is in [.filename]#/etc/fbtab# (see man:fbtab[5]): [.programlisting] .... /dev/ttyv0 0600 /dev/console .... It will ensure that whomever logs in on [.filename]#/dev/ttyv0# will own the console. [[ps2-x]] === Why does my PS/2 mouse misbehave under X? The mouse and the mouse driver may have become out of synchronization. In rare cases, the driver may also erroneously report synchronization errors: [.programlisting] .... psmintr: out of sync (xxxx != yyyy) .... If this happens, disable the synchronization check code by setting the driver flags for the PS/2 mouse driver to `0x100`. This can be easiest achieved by adding `hint.psm.0.flags="0x100"` to [.filename]#/boot/loader.conf# and rebooting. [[mouse-button-reverse]] === How do I reverse the mouse buttons? Type `xmodmap -e "pointer = 3 2 1"`. Add this command to [.filename]#~/.xinitrc# or [.filename]#~/.xsession# to make it happen automatically. [[install-splash]] === How do I install a splash screen and where do I find them? The detailed answer for this question can be found in the extref:{handbook}[Boot Time Splash Screens, boot-splash] section of the FreeBSD Handbook. [[windows-keys]] === Can I use the kbd:[Windows] keys on my keyboard in X? Yes. Use man:xmodmap[1] to define which functions the keys should perform. Assuming all Windows keyboards are standard, the keycodes for these three keys are the following: * 115 - kbd:[Windows] key, between the left-hand kbd:[Ctrl] and kbd:[Alt] keys * 116 - kbd:[Windows] key, to the right of kbd:[AltGr] * 117 - kbd:[Menu], to the left of the right-hand kbd:[Ctrl] To have the left kbd:[Windows] key print a comma, try this. [source,shell] .... # xmodmap -e "keycode 115 = comma" .... To have the kbd:[Windows] key-mappings enabled automatically every time X is started, either put the `xmodmap` commands in [.filename]#~/.xinitrc# or, preferably, create a [.filename]#~/.xmodmaprc# and include the `xmodmap` options, one per line, then add the following line to [.filename]#~/.xinitrc#: [.programlisting] .... xmodmap $HOME/.xmodmaprc .... For example, to map the 3 keys to be kbd:[F13], kbd:[F14], and kbd:[F15], respectively. This would make it easy to map them to useful functions within applications or the window manager. To do this, put the following in [.filename]#~/.xmodmaprc#. [.programlisting] .... keycode 115 = F13 keycode 116 = F14 keycode 117 = F15 .... For the package:x11-wm/fvwm2[] desktop manager, one could map the keys so that kbd:[F13] iconifies or de-iconifies the window the cursor is in, kbd:[F14] brings the window the cursor is in to the front or, if it is already at the front, pushes it to the back, and kbd:[F15] pops up the main Workplace menu even if the cursor is not on the desktop, which is useful when no part of the desktop is visible. The following entries in [.filename]#~/.fvwmrc# implement the aforementioned setup: [.programlisting] .... Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop .... [[x-3d-acceleration]] === How can I get 3D hardware acceleration for OpenGL(R)? The availability of 3D acceleration depends on the version of Xorg and the type of video chip. For an nVidia chip, use the binary drivers provided for FreeBSD by installing one of the following ports: The latest versions of nVidia cards are supported by the package:x11/nvidia-driver[] port. Older drivers are available as: * package:x11/nvidia-driver-390[] * package:x11/nvidia-driver-340[] * package:x11/nvidia-driver-304[] nVidia provides detailed information on which card is supported by which driver on their web site: http://www.nvidia.com/object/IO_32667.html[http://www.nvidia.com/object/IO_32667.html]. For Matrox G200/G400, check the package:x11-drivers/xf86-video-mga[] port. For ATI Rage 128 and Radeon see man:ati[4], man:r128[4] and man:radeon[4]. [[networking]] == Networking [[diskless-booting]] === Where can I get information on diskless booting? "Diskless booting" means that the FreeBSD box is booted over a network, and reads the necessary files from a server instead of its hard disk. For full details, see extref:{handbook}[the Handbook entry on diskless booting, network-diskless]. [[router]] === Can a FreeBSD box be used as a dedicated network router? Yes. Refer to the Handbook entry on extref:{handbook}[advanced networking, advanced-networking], specifically the section on extref:{handbook}[routing and gateways, network-routing]. [[natd]] === Does FreeBSD support NAT or Masquerading? Yes. For instructions on how to use NAT over a PPP connection, see the extref:{handbook}[Handbook entry on PPP, userppp]. To use NAT over some other sort of network connection, look at the extref:{handbook}[natd, network-natd] section of the Handbook. [[ethernet-aliases]] === How can I set up Ethernet aliases? If the alias is on the same subnet as an address already configured on the interface, add `netmask 0xffffffff` to this command: [source,shell] .... # ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff .... Otherwise, specify the network address and netmask as usual: [source,shell] .... # ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00 .... More information can be found in the FreeBSD extref:{handbook}[Handbook, configtuning-virtual-hosts]. [[nfs-linux]] === Why can I not NFS-mount from a Linux(R) box? Some versions of the Linux(R) NFS code only accept mount requests from a privileged port; try to issue the following command: [source,shell] .... # mount -o -P linuxbox:/blah /mnt .... [[exports-errors]] === Why does mountd keep telling me it can't change attributes and that I have a bad exports list on my FreeBSD NFS server? The most frequent problem is not understanding the correct format of [.filename]#/etc/exports#. Review man:exports[5] and the extref:{handbook}[NFS, network-nfs] entry in the Handbook, especially the section on extref:{handbook}[configuring NFS, configuring-nfs]. [[ip-multicast]] === How do I enable IP multicast support? Install the package:net/mrouted[] package or port and add `mrouted_enable="YES"` to [.filename]#/etc/rc.conf# start this service at boot time. [[fqdn-hosts]] === Why do I have to use the FQDN for hosts on my site? See the answer in the FreeBSD extref:{handbook}[Handbook, mail-trouble]. [[network-permission-denied]] === Why do I get an error, Permission denied, for all networking operations? If the kernel is compiled with the `IPFIREWALL` option, be aware that the default policy is to deny all packets that are not explicitly allowed. If the firewall is unintentionally misconfigured, restore network operability by typing the following as `root`: [source,shell] .... # ipfw add 65534 allow all from any to any .... Consider setting `firewall_type="open"` in [.filename]#/etc/rc.conf#. For further information on configuring this firewall, see the extref:{handbook}[Handbook chapter, firewalls-ipfw]. [[ipfw-fwd]] === Why is my `ipfw` “fwd” rule to redirect a service to another machine not working? Possibly because network address translation (NAT) is needed instead of just forwarding packets. A "fwd" rule only forwards packets, it does not actually change the data inside the packet. Consider this rule: [source,shell] .... 01000 fwd 10.0.0.1 from any to foo 21 .... When a packet with a destination address of _foo_ arrives at the machine with this rule, the packet is forwarded to _10.0.0.1_, but it still has the destination address of _foo_. The destination address of the packet is not changed to _10.0.0.1_. Most machines would probably drop a packet that they receive with a destination address that is not their own. Therefore, using a "fwd" rule does not often work the way the user expects. This behavior is a feature and not a bug. See the <>, the man:natd[8] manual, or one of the several port redirecting utilities in the link:https://www.FreeBSD.org/ports/[Ports Collection] for a correct way to do this. [[service-redirect]] === How can I redirect service requests from one machine to another? FTP and other service requests can be redirected with the package:sysutils/socket[] package or port. Replace the entry for the service in [.filename]#/etc/inetd.conf# to call `socket`, as seen in this example for ftpd: [.programlisting] .... ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp .... where _ftp.example.com_ and _ftp_ are the host and port to redirect to, respectively. [[bandwidth-mgr-tool]] === Where can I get a bandwidth management tool? There are three bandwidth management tools available for FreeBSD. man:dummynet[4] is integrated into FreeBSD as part of man:ipfw[4]. http://www.sonycsl.co.jp/person/kjc/programs.html[ALTQ] has been integrated into FreeBSD as part of man:pf[4]. Bandwidth Manager from http://www.etinc.com/[Emerging Technologies] is a commercial product. [[bpf-not-configured]] === Why do I get /dev/bpf0: device not configured? The running application requires the Berkeley Packet Filter (man:bpf[4]), but it was removed from a custom kernel. Add this to the kernel config file and build a new kernel: [.programlisting] .... device bpf # Berkeley Packet Filter .... [[mount-smb-share]] === How do I mount a disk from a Windows(R) machine that is on my network, like smbmount in Linux(R)? Use the SMBFS toolset. It includes a set of kernel modifications and a set of userland programs. The programs and information are available as man:mount_smbfs[8] in the base system. [[icmp-response-bw-limit]] === What are these messages about: Limiting icmp/open port/closed port response in my log files? This kernel message indicates that some activity is provoking it to send a large amount of ICMP or TCP reset (RST) responses. ICMP responses are often generated as a result of attempted connections to unused UDP ports. TCP resets are generated as a result of attempted connections to unopened TCP ports. Among others, these are the kinds of activities which may cause these messages: * Brute-force denial of service (DoS) attacks (as opposed to single-packet attacks which exploit a specific vulnerability). * Port scans which attempt to connect to a large number of ports (as opposed to only trying a few well-known ports). The first number in the message indicates how many packets the kernel would have sent if the limit was not in place, and the second indicates the limit. This limit is controlled using `net.inet.icmp.icmplim`. This example sets the limit to `300` packets per second: [source,shell] .... # sysctl net.inet.icmp.icmplim=300 .... To disable these messages without disabling response limiting, use `net.inet.icmp.icmplim_output` to disable the output: [source,shell] .... # sysctl net.inet.icmp.icmplim_output=0 .... Finally, to disable response limiting completely, set `net.inet.icmp.icmplim` to `0`. Disabling response limiting is discouraged for the reasons listed above. [[unknown-hw-addr-format]] === What are these arp: unknown hardware address format error messages? This means that some device on the local Ethernet is using a MAC address in a format that FreeBSD does not recognize. This is probably caused by someone experimenting with an Ethernet card somewhere else on the network. This is most commonly seen on cable modem networks. It is harmless, and should not affect the performance of the FreeBSD system. [[arp-wrong-iface]] === Why do I keep seeing messages like: 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0, and how do I disable it? A packet is coming from outside the network unexpectedly. To disable them, set `net.link.ether.inet.log_arp_wrong_iface` to `0`. [[ipv6-only]] === How do I compile an IPv6 only kernel? Configure your kernel with these settings: [source,shell] .... include GENERIC ident GENERIC-IPV6ONLY makeoptions MKMODULESENV+="WITHOUT_INET_SUPPORT=" nooptions INET nodevice gre .... [[security]] == Security [[sandbox]] === What is a sandbox? "Sandbox" is a security term. It can mean two things: * A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system. + The process is only able to run inside the walls. Since nothing the process does in regards to executing code is supposed to be able to breach the walls, a detailed audit of its code is not needed in order to be able to say certain things about its security. + The walls might be a user ID, for example. This is the definition used in the man:security[7] and man:named[8] man pages. + Take the `ntalk` service, for example (see man:inetd[8]). This service used to run as user ID `root`. Now it runs as user ID `tty`. The `tty` user is a sandbox designed to make it more difficult for someone who has successfully hacked into the system via `ntalk` from being able to hack beyond that user ID. * A process which is placed inside a simulation of the machine. It means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data. + The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chrooted so that [.filename]#/# for that process is this directory, not the real [.filename]#/# of the system). + Another common use is to mount an underlying file system read-only and then create a file system layer on top of it that gives a process a seemingly writeable view into that file system. The process may believe it is able to write to those files, but only the process sees the effects - other processes in the system do not, necessarily. + An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it. UNIX(R) implements two core sandboxes. One is at the process level, and one is at the userid level. Every UNIX(R) process is completely firewalled off from every other UNIX(R) process. One process cannot modify the address space of another. A UNIX(R) process is owned by a particular userid. If the user ID is not the `root` user, it serves to firewall the process off from processes owned by other users. The user ID is also used to firewall off on-disk data. [[securelevel]] === What is securelevel? `securelevel` is a security mechanism implemented in the kernel. When the securelevel is positive, the kernel restricts certain tasks; not even the superuser (`root`) is allowed to do them. The securelevel mechanism limits the ability to: * Unset certain file flags, such as `schg` (the system immutable flag). * Write to kernel memory via [.filename]#/dev/mem# and [.filename]#/dev/kmem#. * Load kernel modules. * Alter firewall rules. To check the status of the securelevel on a running system: [source,shell] .... # sysctl -n kern.securelevel .... The output contains the current value of the securelevel. If it is greater than 0, at least some of the securelevel's protections are enabled. The securelevel of a running system cannot be lowered as this would defeat its purpose. If a task requires that the securelevel be non-positive, change the `kern_securelevel` and `kern_securelevel_enable` variables in [.filename]#/etc/rc.conf# and reboot. For more information on securelevel and the specific things all the levels do, consult man:init[8]. [WARNING] ==== Securelevel is not a silver bullet; it has many known deficiencies. More often than not, it provides a false sense of security. One of its biggest problems is that in order for it to be at all effective, all files used in the boot process up until the securelevel is set must be protected. If an attacker can get the system to execute their code prior to the securelevel being set (which happens quite late in the boot process since some things the system must do at start-up cannot be done at an elevated securelevel), its protections are invalidated. While this task of protecting all files used in the boot process is not technically impossible, if it is achieved, system maintenance will become a nightmare since one would have to take the system down, at least to single-user mode, to modify a configuration file. This point and others are often discussed on the mailing lists, particularly the {freebsd-security}. Search the archives link:https://www.FreeBSD.org/search/[here] for an extensive discussion. A more fine-grained mechanism is preferred. ==== [[toor-account]] === What is this UID 0 toor account? Have I been compromised? Do not worry. `toor` is an "alternative" superuser account, where toor is root spelled backwards. It is intended to be used with a non-standard shell so the default shell for `root` does not need to change. This is important as shells which are not part of the base distribution, but are instead installed from ports or packages, are installed in [.filename]#/usr/local/bin# which, by default, resides on a different file system. If ``root``'s shell is located in [.filename]#/usr/local/bin# and the file system containing [.filename]#/usr/local/bin#) is not mounted, `root` will not be able to log in to fix a problem and will have to reboot into single-user mode in order to enter the path to a shell. Some people use `toor` for day-to-day `root` tasks with a non-standard shell, leaving `root`, with a standard shell, for single-user mode or emergencies. By default, a user cannot log in using `toor` as it does not have a password, so log in as `root` and set a password for `toor` before using it to login. [[serial]] == Serial Communications This section answers common questions about serial communications with FreeBSD. [[serial-console-prompt]] === How do I get the boot: prompt to show on the serial console? See extref:{handbook}[this section of the Handbook, serialconsole-setup]. [[found-serial]] === How do I tell if FreeBSD found my serial ports or modem cards? As the FreeBSD kernel boots, it will probe for the serial ports for which the kernel is configured. Either watch the boot messages closely or run this command after the system is up and running: [source,shell] .... % grep -E '^(sio|uart)[0-9]' < /var/run/dmesg.boot uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (115200,n,8,1) uart1: <16550 or compatible> port 0x2f8-2x3ff irq 3 on acpi0 .... This example shows two serial ports. The first is on IRQ4, port address `0x3f8`, and has a 16550-type UART chip. The second uses the same kind of chip but is on IRQ3 and is at port address `0x2f8`. Internal modem cards are treated just like serial ports, except that they always have a modem attached to the port. The [.filename]#GENERIC# kernel includes support for two serial ports using the same IRQ and port address settings in the above example. If these settings are not right for the system, or if there are more modem cards or serial ports than the kernel is configured for, reconfigure using the instructions in <> for more details. [[access-serial-ports]] === How do I access the serial ports on FreeBSD? (x86-specific) The third serial port, [.filename]#sio2#, or [.filename]#COM3#, is on [.filename]#/dev/cuad2# for dial-out devices, and on [.filename]#/dev/ttyd2# for dial-in devices. What is the difference between these two classes of devices? When opening [.filename]#/dev/ttydX# in blocking mode, a process will wait for the corresponding [.filename]#cuadX# device to become inactive, and then wait for the carrier detect line to go active. When the [.filename]#cuadX# device is opened, it makes sure the serial port is not already in use by the [.filename]#ttydX# device. If the port is available, it steals it from the [.filename]#ttydX# device. Also, the [.filename]#cuadX# device does not care about carrier detect. With this scheme and an auto-answer modem, remote users can log in and local users can still dial out with the same modem and the system will take care of all the conflicts. [[enable-multiport-serial]] === How do I enable support for a multi-port serial card? The section on kernel configuration provides information about configuring the kernel. For a multi-port serial card, place an man:sio[4] line for each serial port on the card in the man:device.hints[5] file. But place the IRQ specifiers on only one of the entries. All of the ports on the card should share one IRQ. For consistency, use the last serial port to specify the IRQ. Also, specify the following option in the kernel configuration file: [.programlisting] .... options COM_MULTIPORT .... The following [.filename]#/boot/device.hints# example is for an AST 4-port serial card on IRQ 12: [.programlisting] .... hint.sio.4.at="isa" hint.sio.4.port="0x2a0" hint.sio.4.flags="0x701" hint.sio.5.at="isa" hint.sio.5.port="0x2a8" hint.sio.5.flags="0x701" hint.sio.6.at="isa" hint.sio.6.port="0x2b0" hint.sio.6.flags="0x701" hint.sio.7.at="isa" hint.sio.7.port="0x2b8" hint.sio.7.flags="0x701" hint.sio.7.irq="12" .... The flags indicate that the master port has minor number `7` (`0x700`), and all the ports share an IRQ (`0x001`). [[default-serial-params]] === Can I set the default serial parameters for a port? See the extref:{handbook}serialcomms[Serial Communications, serial-hw-config] section in the FreeBSD Handbook. [[cannot-tip]] === Why can I not run tip or cu? The built-in man:tip[1] and man:cu[1] utilities can only access the [.filename]#/var/spool/lock# directory via user `uucp` and group `dialer`. Use the `dialer` group to control who has access to the modem or remote systems by adding user accounts to `dialer`. Alternatively, everyone can be configured to run man:tip[1] and man:cu[1] by typing: [source,shell] .... # chmod 4511 /usr/bin/cu # chmod 4511 /usr/bin/tip .... [[misc]] == Miscellaneous Questions [[more-swap]] === FreeBSD uses a lot of swap space even when the computer has free memory left. Why? FreeBSD will proactively move entirely idle, unused pages of main memory into swap in order to make more main memory available for active use. This heavy use of swap is balanced by using the extra free memory for caching. Note that while FreeBSD is proactive in this regard, it does not arbitrarily decide to swap pages when the system is truly idle. Thus, the system will not be all paged out after leaving it idle overnight. [[top-freemem]] === Why does top show very little free memory even when I have very few programs running? The simple answer is that free memory is wasted memory. Any memory that programs do not actively allocate is used within the FreeBSD kernel as disk cache. The values shown by man:top[1] labeled as `Inact` and `Laundry` are cached data at different aging levels. This cached data means the system does not have to access a slow disk again for data it has accessed recently, thus increasing overall performance. In general, a low value shown for `Free` memory in man:top[1] is good, provided it is not _very_ low. [[chmod-symlinks]] === Why will `chmod` not change the permissions on symlinks? Symlinks do not have permissions, and by default, man:chmod[1] will follow symlinks to change the permissions on the source file, if possible. For the file, [.filename]#foo# with a symlink named [.filename]#bar#, this command will always succeed. [source,shell] .... % chmod g-w bar .... However, the permissions on [.filename]#bar# will not have changed. When changing modes of the file hierarchies rooted in the files instead of the files themselves, use either `-H` or `-L` together with `-R` to make this work. See man:chmod[1] and man:symlink[7] for more information. [WARNING] ==== `-R` does a _recursive_ man:chmod[1]. Be careful about specifying directories or symlinks to directories to man:chmod[1]. To change the permissions of a directory referenced by a symlink, use man:chmod[1] without any options and follow the symlink with a trailing slash ([.filename]#/#). For example, if [.filename]#foo# is a symlink to directory [.filename]#bar#, to change the permissions of [.filename]#foo# (actually [.filename]#bar#), do something like: [source,shell] .... % chmod 555 foo/ .... With the trailing slash, man:chmod[1] will follow the symlink, [.filename]#foo#, to change the permissions of the directory, [.filename]#bar#. ==== [[dos-binaries]] === Can I run DOS binaries under FreeBSD? Yes. A DOS emulation program, package:emulators/doscmd[], is available in the FreeBSD Ports Collection. If doscmd will not suffice, package:emulators/pcemu[] emulates an 8088 and enough BIOS services to run many DOS text-mode applications. It requires the X Window System. The Ports Collection also has package:emulators/dosbox[]. The main focus of this application is emulating old DOS games using the local file system for files. [[translation]] === What do I need to do to translate a FreeBSD document into my native language? See the extref:{fdp-primer}[Translation FAQ, translations] in the FreeBSD Documentation Project Primer. [[freebsd-mail-bounces]] === Why does my email to any address at FreeBSD.org bounce? The `FreeBSD.org` mail system implements some Postfix checks on incoming mail and rejects mail that is either from misconfigured relays or otherwise appears likely to be spam. Some of the specific requirements are: * The IP address of the SMTP client must "reverse-resolve" to a forward confirmed hostname. * The fully-qualified hostname given in the SMTP conversation (either HELO or EHLO) must resolve to the IP address of the client. Other advice to help mail reach its destination include: * Mail should be sent in plain text, and messages sent to mailing lists should generally be no more than 200KB in length. * Avoid excessive cross posting. Choose _one_ mailing list which seems most relevant and send it there. If you still have trouble with email infrastructure at `FreeBSD.org`, send a note with the details to mailto:postmaster@freebsd.org[postmaster@freebsd.org]; Include a date/time interval so that logs may be reviewed - and note that we only keep one week's worth of mail logs. (Be sure to specify the time zone or offset from UTC.) [[free-account]] === Where can I find a free FreeBSD account? While FreeBSD does not provide open access to any of their servers, others do provide open access UNIX(R) systems. The charge varies and limited services may be available. http://www.arbornet.org/[Arbornet, Inc], also known as _M-Net_, has been providing open access to UNIX(R) systems since 1983. Starting on an Altos running System III, the site switched to BSD/OS in 1991. In June of 2000, the site switched again to FreeBSD. _M-Net_ can be accessed via telnet and SSH and provides basic access to the entire FreeBSD software suite. However, network access is limited to members and patrons who donate to the system, which is run as a non-profit organization. _M-Net_ also provides an bulletin board system and interactive chat. [[daemon-name]] === What is the cute little red guy's name? He does not have one, and is just called "the BSD daemon". If you insist upon using a name, call him "beastie". Note that "beastie" is pronounced "BSD". More about the BSD daemon is available on his http://www.mckusick.com/beastie/index.html[home page]. [[use-beastie]] === Can I use the BSD daemon image? Perhaps. The BSD daemon is copyrighted by Marshall Kirk McKusick. Check his http://www.mckusick.com/beastie/mainpage/copyright.html[Statement on the Use of the BSD Daemon Figure] for detailed usage terms. In summary, the image can be used in a tasteful manner, for personal use, so long as appropriate credit is given. Before using the logo commercially, contact {mckusick} for permission. More details are available on the http://www.mckusick.com/beastie/index.html[BSD Daemon's home page]. [[daemon-images]] === Do you have any BSD daemon images I could use? Xfig and eps drawings are available under [.filename]#/usr/share/examples/BSD_daemon/#. [[glossary]] === I have seen an acronym or other term on the mailing lists and I do not understand what it means. Where should I look? Refer to the extref:{handbook}[FreeBSD Glossary, freebsd-glossary]. [[bikeshed-painting]] === Why should I care what color the bikeshed is? The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change. The longer and more complete answer is that after a very long argument about whether man:sleep[1] should take fractional second arguments, {phk} posted a long message entitled link:http://www.bikeshed.com[A bike shed (any color will do) on greener grass...]. The appropriate portions of that message are quoted below. **** “What is it about this bike shed?” Some of you have asked me. It is a long story, or rather it is an old story, but it is quite short actually. C. Northcote Parkinson wrote a book in the early 1960s, called “Parkinson's Law”, which contains a lot of insight into the dynamics of management. [snip a bit of commentary on the book] In the specific example involving the bike shed, the other vital component is an atomic power-plant, I guess that illustrates the age of the book. Parkinson shows how you can go into the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions. Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. Richard P. Feynmann gives a couple of interesting, and very much to the point, examples relating to Los Alamos in his books. A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is here. In Denmark we call it “setting your fingerprint”. It is about personal pride and prestige, it is about being able to point somewhere and say “There! I did that.” It is a strong trait in politicians, but present in most people given the chance. Just think about footsteps in wet cement. --Poul-Henning Kamp on freebsd-hackers, October 2, 1999 **** [[funnies]] == The FreeBSD Funnies [[very-very-cool]] === How cool is FreeBSD? _Q._ Has anyone done any temperature testing while running FreeBSD? I know Linux(R) runs cooler than DOS, but have never seen a mention of FreeBSD. It seems to run really hot. _A._ No, but we have done numerous taste tests on blindfolded volunteers who have also had 250 micrograms of LSD-25 administered beforehand. 35% of the volunteers said that FreeBSD tasted sort of orange, whereas Linux(R) tasted like purple haze. Neither group mentioned any significant variances in temperature. We eventually had to throw the results of this survey out entirely anyway when we found that too many volunteers were wandering out of the room during the tests, thus skewing the results. We think most of the volunteers are at Apple now, working on their new "scratch and sniff" GUI. It is a funny old business we are in! Seriously, FreeBSD uses the HLT (halt) instruction when the system is idle thus lowering its energy consumption and therefore the heat it generates. Also if you have ACPI (Advanced Configuration and Power Interface) configured, then FreeBSD can also put the CPU into a low power mode. [[letmeoutofhere]] === Who is scratching in my memory banks?? _Q._ Is there anything "odd" that FreeBSD does when compiling the kernel which would cause the memory to make a scratchy sound? When compiling (and for a brief moment after recognizing the floppy drive upon startup, as well), a strange scratchy sound emanates from what appears to be the memory banks. _A._ Yes! You will see frequent references to "daemons" in the BSD documentation, and what most people do not know is that this refers to genuine, non-corporeal entities that now possess your computer. The scratchy sound coming from your memory is actually high-pitched whispering exchanged among the daemons as they best decide how to deal with various system administration tasks. If the noise gets to you, a good `fdisk /mbr` from DOS will get rid of them, but do not be surprised if they react adversely and try to stop you. In fact, if at any point during the exercise you hear the satanic voice of Bill Gates coming from the built-in speaker, take off running and do not ever look back! Freed from the counterbalancing influence of the BSD daemons, the twin demons of DOS and Windows(R) are often able to re-assert total control over your machine to the eternal damnation of your soul. Now that you know, given a choice you would probably prefer to get used to the scratchy noises, no? [[changing-lightbulbs]] === How many FreeBSD hackers does it take to change a lightbulb? One thousand, one hundred and sixty-nine: Twenty-three to complain to -CURRENT about the lights being out; Four to claim that it is a configuration problem, and that such matters really belong on -questions; Three to submit PRs about it, one of which is misfiled under doc and consists only of "it's dark"; One to commit an untested lightbulb which breaks buildworld, then back it out five minutes later; Eight to flame the PR originators for not including patches in their PRs; Five to complain about buildworld being broken; Thirty-one to answer that it works for them, and they must have updated at a bad time; One to post a patch for a new lightbulb to -hackers; One to complain that he had patches for this three years ago, but when he sent them to -CURRENT they were just ignored, and he has had bad experiences with the PR system; besides, the proposed new lightbulb is non-reflexive; Thirty-seven to scream that lightbulbs do not belong in the base system, that committers have no right to do things like this without consulting the Community, and WHAT IS -CORE DOING ABOUT IT!? Two hundred to complain about the color of the bicycle shed; Three to point out that the patch breaks man:style[9]; Seventeen to complain that the proposed new lightbulb is under GPL; Five hundred and eighty-six to engage in a flame war about the comparative advantages of the GPL, the BSD license, the MIT license, the NPL, and the personal hygiene of unnamed FSF founders; Seven to move various portions of the thread to -chat and -advocacy; One to commit the suggested lightbulb, even though it shines dimmer than the old one; Two to back it out with a furious flame of a commit message, arguing that FreeBSD is better off in the dark than with a dim lightbulb; Forty-six to argue vociferously about the backing out of the dim lightbulb and demanding a statement from -core; Eleven to request a smaller lightbulb so it will fit their Tamagotchi if we ever decide to port FreeBSD to that platform; Seventy-three to complain about the SNR on -hackers and -chat and unsubscribe in protest; Thirteen to post "unsubscribe", "How do I unsubscribe?", or "Please remove me from the list", followed by the usual footer; One to commit a working lightbulb while everybody is too busy flaming everybody else to notice; Thirty-one to point out that the new lightbulb would shine 0.364% brighter if compiled with TenDRA (although it will have to be reshaped into a cube), and that FreeBSD should therefore switch to TenDRA instead of GCC; One to complain that the new lightbulb lacks fairings; Nine (including the PR originators) to ask "what is MFC?"; Fifty-seven to complain about the lights being out two weeks after the bulb has been changed. _{nik} adds:_ _I was laughing quite hard at this._ _And then I thought, "Hang on, shouldn't there be '1 to document it.' in that list somewhere?"_ _And then I was enlightened :-)_ _{tabthorpe}_ says: "None, _real_ FreeBSD hackers are not afraid of the dark!" [[dev-null]] === Where does data written to [.filename]#/dev/null# go? It goes into a special data sink in the CPU where it is converted to heat which is vented through the heatsink / fan assembly. This is why CPU cooling is increasingly important; as people get used to faster processors, they become careless with their data and more and more of it ends up in [.filename]#/dev/null#, overheating their CPUs. If you delete [.filename]#/dev/null# (which effectively disables the CPU data sink) your CPU may run cooler but your system will quickly become constipated with all that excess data and start to behave erratically. If you have a fast network connection you can cool down your CPU by reading data out of [.filename]#/dev/random# and sending it off somewhere; however you run the risk of overheating your network connection and [.filename]#/# or angering your ISP, as most of the data will end up getting converted to heat by their equipment, but they generally have good cooling, so if you do not overdo it you should be OK. _Paul Robinson adds:_ There are other methods. As every good sysadmin knows, it is part of standard practice to send data to the screen of interesting variety to keep all the pixies that make up your picture happy. Screen pixies (commonly mis-typed or re-named as "pixels") are categorized by the type of hat they wear (red, green or blue) and will hide or appear (thereby showing the color of their hat) whenever they receive a little piece of food. Video cards turn data into pixie-food, and then send them to the pixies - the more expensive the card, the better the food, so the better behaved the pixies are. They also need constant stimulation - this is why screen savers exist. To take your suggestions further, you could just throw the random data to console, thereby letting the pixies consume it. This causes no heat to be produced at all, keeps the pixies happy and gets rid of your data quite quickly, even if it does make things look a bit messy on your screen. Incidentally, as an ex-admin of a large ISP who experienced many problems attempting to maintain a stable temperature in a server room, I would strongly discourage people sending the data they do not want out to the network. The fairies who do the packet switching and routing get annoyed by it as well. [[punk-my-friend]] === My colleague sits at the computer too much, how can I prank her? Install package:games/sl[] and wait for her to mistype `sl` for `ls`. [[advanced]] == Advanced Topics [[learn-advanced]] === How can I learn more about FreeBSD's internals? See the extref:{arch-handbook}[FreeBSD Architecture Handbook]. Additionally, much general UNIX(R) knowledge is directly applicable to FreeBSD. [[how-to-contribute]] === How can I contribute to FreeBSD? What can I do to help? We accept all types of contributions: documentation, code, and even art. See the article on extref:{contributing}[Contributing to FreeBSD] for specific advice on how to do this. And thanks for the thought! [[define-snap-release]] === What are snapshots and releases? There are currently {rel-numbranch} active/semi-active branches in the FreeBSD http://svnweb.FreeBSD.org/base/[Subversion Repository]. (Earlier branches are only changed very rarely, which is why there are only {rel-numbranch} active branches of development): * {rel2-releng} AKA {rel2-stable} * {rel-releng} AKA {rel-stable} * {rel-head-releng} AKA _-CURRENT_ AKA {rel-head} `HEAD` is not an actual branch tag. It is a symbolic constant for the current, non-branched development stream known as _-CURRENT_. Right now, _-CURRENT_ is the {rel-head-relx} development stream; the {rel-stable} branch, {rel-releng}, forked off from _-CURRENT_ in {rel-relengdate} and the {rel2-stable} branch, {rel2-releng}, forked off from _-CURRENT_ in {rel2-relengdate}. [[kernel-panic-troubleshooting]] === How can I make the most of the data I see when my kernel panics? Here is typical kernel panic: [.programlisting] .... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault .... This message is not enough. While the instruction pointer value is important, it is also configuration dependent as it varies depending on the kernel image. If it is a [.filename]#GENERIC# kernel image from one of the snapshots, it is possible for somebody else to track down the offending function, but for a custom kernel, only you can tell us where the fault occurred. To proceed: [.procedure] ==== . Write down the instruction pointer value. Note that the `0x8:` part at the beginning is not significant in this case: it is the `0xf0xxxxxx` part that we want. . When the system reboots, do the following: + [source,shell] .... % nm -n kernel.that.caused.the.panic | grep f0xxxxxx .... + where `f0xxxxxx` is the instruction pointer value. The odds are you will not get an exact match since the symbols in the kernel symbol table are for the entry points of functions and the instruction pointer address will be somewhere inside a function, not at the start. If you do not get an exact match, omit the last digit from the instruction pointer value and try again: + [source,shell] .... % nm -n kernel.that.caused.the.panic | grep f0xxxxx .... + If that does not yield any results, chop off another digit. Repeat until there is some sort of output. The result will be a possible list of functions which caused the panic. This is a less than exact mechanism for tracking down the point of failure, but it is better than nothing. ==== However, the best way to track down the cause of a panic is by capturing a crash dump, then using man:kgdb[1] to generate a stack trace on the crash dump. In any case, the method is this: [.procedure] ==== . Make sure that the following line is included in the kernel configuration file: + [.programlisting] .... makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols .... . Change to the [.filename]#/usr/src# directory: + [source,shell] .... # cd /usr/src .... . Compile the kernel: + [source,shell] .... # make buildkernel KERNCONF=MYKERNEL .... . Wait for man:make[1] to finish compiling. + [source,shell] .... # make installkernel KERNCONF=MYKERNEL .... . Reboot. ==== [NOTE] ==== If `KERNCONF` is not included, the [.filename]#GENERIC# kernel will instead be built and installed. ==== The man:make[1] process will have built two kernels. [.filename]#/usr/obj/usr/src/sys/MYKERNEL/kernel# and [.filename]#/usr/obj/usr/src/sys/MYKERNEL/kernel.debug#. [.filename]#kernel# was installed as [.filename]#/boot/kernel/kernel#, while [.filename]#kernel.debug# can be used as the source of debugging symbols for man:kgdb[1]. To capture a crash dump, edit [.filename]#/etc/rc.conf# and set `dumpdev` to point to either the swap partition or `AUTO`. This will cause the man:rc[8] scripts to use the man:dumpon[8] command to enable crash dumps. This command can also be run manually. After a panic, the crash dump can be recovered using man:savecore[8]; if `dumpdev` is set in [.filename]#/etc/rc.conf#, the man:rc[8] scripts will run man:savecore[8] automatically and put the crash dump in [.filename]#/var/crash#. [NOTE] ==== FreeBSD crash dumps are usually the same size as physical RAM. Therefore, make sure there is enough space in [.filename]#/var/crash# to hold the dump. Alternatively, run man:savecore[8] manually and have it recover the crash dump to another directory with more room. It is possible to limit the size of the crash dump by using `options MAXMEM=N` where _N_ is the size of kernel's memory usage in KBs. For example, for 1 GB of RAM, limit the kernel's memory usage to 128 MB, so that the crash dump size will be 128 MB instead of 1 GB. ==== Once the crash dump has been recovered , get a stack trace as follows: [source,shell] .... % kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0 (kgdb) backtrace .... Note that there may be several screens worth of information. Ideally, use man:script[1] to capture all of them. Using the unstripped kernel image with all the debug symbols should show the exact line of kernel source code where the panic occurred. The stack trace is usually read from the bottom up to trace the exact sequence of events that lead to the crash. man:kgdb[1] can also be used to print out the contents of various variables or structures to examine the system state at the time of the crash. [TIP] ==== If a second computer is available, man:kgdb[1] can be configured to do remote debugging, including setting breakpoints and single-stepping through the kernel code. ==== [NOTE] ==== If `DDB` is enabled and the kernel drops into the debugger, a panic and a crash dump can be forced by typing `panic` at the `ddb` prompt. It may stop in the debugger again during the panic phase. If it does, type `continue` and it will finish the crash dump. ==== [[dlsym-failure]] === Why has dlsym() stopped working for ELF executables? The ELF toolchain does not, by default, make the symbols defined in an executable visible to the dynamic linker. Consequently `dlsym()` searches on handles obtained from calls to `dlopen(NULL, flags)` will fail to find such symbols. To search, using `dlsym()`, for symbols present in the main executable of a process, link the executable using the `--export-dynamic` option to the ELF linker (man:ld[1]). [[change-kernel-address-space]] === How can I increase or reduce the kernel address space on i386? By default, the kernel address space is 1 GB (2 GB for PAE) for i386. When running a network-intensive server or using ZFS, this will probably not be enough. Add the following line to the kernel configuration file to increase available space and rebuild the kernel: [.programlisting] .... options KVA_PAGES=N .... To find the correct value of _N_, divide the desired address space size (in megabytes) by four. (For example, it is `512` for 2 GB.) [[acknowledgments]] == Acknowledgments This innocent little Frequently Asked Questions document has been written, rewritten, edited, folded, spindled, mutilated, eviscerated, contemplated, discombobulated, cogitated, regurgitated, rebuilt, castigated, and reinvigorated over the last decade, by a cast of hundreds if not thousands. Repeatedly. We wish to thank every one of the people responsible, and we encourage you to extref:{contributing}[join them] in making this FAQ even better. diff --git a/documentation/content/en/books/handbook/_index.adoc b/documentation/content/en/books/handbook/_index.adoc index 5ebdbb1502..3df05a9caa 100644 --- a/documentation/content/en/books/handbook/_index.adoc +++ b/documentation/content/en/books/handbook/_index.adoc @@ -1,62 +1,62 @@ --- title: FreeBSD Handbook authors: - author: The FreeBSD Documentation Project copyright: 1995-2022 The FreeBSD Documentation Project description: A constantly evolving, comprehensive resource for FreeBSD users trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] tags: ["FreeBSD Handbook", "Handbook"] next: books/handbook/preface add_single_page_link: true showBookMenu: true weight: 0 path: "/books/handbook/" bookOrder: 1 --- = FreeBSD Handbook :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Abstract Welcome to FreeBSD! This handbook covers the installation and day to day use of _FreeBSD {rel130-current}-RELEASE_ and _FreeBSD {rel122-current}-RELEASE_. This book is the result of ongoing work by many individuals. Some sections might be outdated. Those interested in helping to update and expand this document should send email to the {freebsd-doc}. The latest version of this book is available from the https://www.FreeBSD.org/[FreeBSD web site]. Previous versions can be obtained from https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]. -The book can be downloaded in a variety of formats and compression options from the https://download.freebsd.org/ftp/doc/[FreeBSD FTP server] or one of the numerous link:./mirrors#mirrors-ftp[mirror sites]. +The book can be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous link:./mirrors#mirrors-ftp[mirror sites]. Printed copies can be purchased at the https://www.freebsdmall.com/[FreeBSD Mall]. Searches can be performed on the handbook and other documents on the link:https://www.FreeBSD.org/search/[search page]. ''' diff --git a/documentation/content/en/books/handbook/book.adoc b/documentation/content/en/books/handbook/book.adoc index a72d414294..292c01ae94 100644 --- a/documentation/content/en/books/handbook/book.adoc +++ b/documentation/content/en/books/handbook/book.adoc @@ -1,161 +1,161 @@ --- title: FreeBSD Handbook authors: - author: The FreeBSD Documentation Project copyright: 1995-2022 The FreeBSD Documentation Project description: A constantly evolving, comprehensive resource for FreeBSD users trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] tags: ["FreeBSD Handbook", "Handbook"] add_split_page_link: true --- = FreeBSD Handbook :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Abstract Welcome to FreeBSD! This handbook covers the installation and day to day use of _FreeBSD {rel130-current}-RELEASE_ and _FreeBSD {rel123-current}-RELEASE_. This book is the result of ongoing work by many individuals. Some sections might be outdated. Those interested in helping to update and expand this document should send email to the {freebsd-doc}. The latest version of this book is available from the https://www.FreeBSD.org/[FreeBSD web site]. Previous versions can be obtained from https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]. -The book can be downloaded in a variety of formats and compression options from the https://download.freebsd.org/ftp/doc/[FreeBSD FTP server] or one of the numerous crossref:mirrors[mirrors-ftp,mirror sites]. +The book can be downloaded in a variety of formats and compression options from the https://download.freebsd.org/doc/[FreeBSD FTP server] or one of the numerous crossref:mirrors[mirrors-ftp,mirror sites]. Printed copies can be purchased at the https://www.freebsdmall.com/[FreeBSD Mall]. Searches can be performed on the handbook and other documents on the link:https://www.FreeBSD.org/search/[search page]. ''' toc::[] :sectnums!: include::{chapters-path}preface/_index.adoc[leveloffset=+1] :sectnums: // Section one include::{chapters-path}parti.adoc[] include::{chapters-path}introduction/_index.adoc[leveloffset=+1] include::{chapters-path}bsdinstall/_index.adoc[leveloffset=+1] include::{chapters-path}basics/_index.adoc[leveloffset=+1] include::{chapters-path}ports/_index.adoc[leveloffset=+1] include::{chapters-path}x11/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[] include::{chapters-path}desktop/_index.adoc[leveloffset=+1] include::{chapters-path}multimedia/_index.adoc[leveloffset=+1] include::{chapters-path}kernelconfig/_index.adoc[leveloffset=+1] include::{chapters-path}printing/_index.adoc[leveloffset=+1] include::{chapters-path}linuxemu/_index.adoc[leveloffset=+1] include::{chapters-path}wine/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[] include::{chapters-path}config/_index.adoc[leveloffset=+1] include::{chapters-path}boot/_index.adoc[leveloffset=+1] include::{chapters-path}security/_index.adoc[leveloffset=+1] include::{chapters-path}jails/_index.adoc[leveloffset=+1] include::{chapters-path}mac/_index.adoc[leveloffset=+1] include::{chapters-path}audit/_index.adoc[leveloffset=+1] include::{chapters-path}disks/_index.adoc[leveloffset=+1] include::{chapters-path}geom/_index.adoc[leveloffset=+1] include::{chapters-path}zfs/_index.adoc[leveloffset=+1] include::{chapters-path}filesystems/_index.adoc[leveloffset=+1] include::{chapters-path}virtualization/_index.adoc[leveloffset=+1] include::{chapters-path}l10n/_index.adoc[leveloffset=+1] include::{chapters-path}cutting-edge/_index.adoc[leveloffset=+1] include::{chapters-path}dtrace/_index.adoc[leveloffset=+1] include::{chapters-path}usb-device-mode/_index.adoc[leveloffset=+1] // Section four include::{chapters-path}partiv.adoc[] include::{chapters-path}serialcomms/_index.adoc[leveloffset=+1] include::{chapters-path}ppp-and-slip/_index.adoc[leveloffset=+1] include::{chapters-path}mail/_index.adoc[leveloffset=+1] include::{chapters-path}network-servers/_index.adoc[leveloffset=+1] include::{chapters-path}firewalls/_index.adoc[leveloffset=+1] include::{chapters-path}advanced-networking/_index.adoc[leveloffset=+1] // Section five include::{chapters-path}partv.adoc[] :sectnums!: include::{chapters-path}mirrors/_index.adoc[leveloffset=+1] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] include::{chapters-path}eresources/_index.adoc[leveloffset=+1] include::{chapters-path}pgpkeys/_index.adoc[leveloffset=+1] :sectnums: diff --git a/documentation/content/es/articles/mailing-list-faq/_index.adoc b/documentation/content/es/articles/mailing-list-faq/_index.adoc index 5f7968458d..dbf63c9a84 100644 --- a/documentation/content/es/articles/mailing-list-faq/_index.adoc +++ b/documentation/content/es/articles/mailing-list-faq/_index.adoc @@ -1,174 +1,174 @@ --- title: Preguntas más frecuentes sobre las listas de correo de FreeBSD authors: - author: The FreeBSD Documentation Project copyright: 2004-2005 The FreeBSD Documentation Project --- = Preguntas más frecuentes sobre las listas de correo de FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/mailing-list-faq/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Resumen -Estas son las FAQ de las listas de correo de FreeBSD. Si está interesado en ayudar con este proyecto, envíe un correo electrónico a la http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de correo del proyecto de documentación de FreeBSD]. La última versión de este documento está siempre disponible en el extref:{mailing-list-faq}[servidor de FreeBSD]. También se puede descargar como un único archivo link:.[HTML] con HTTP o como texto plano, PostScript, PDF, etc. desde el https://download.freebsd.org/ftp/doc/[servidor FTP de FreeBSD]. También es posible que desee https://www.FreeBSD.org/search/[Buscar en las FAQ]. +Estas son las FAQ de las listas de correo de FreeBSD. Si está interesado en ayudar con este proyecto, envíe un correo electrónico a la http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de correo del proyecto de documentación de FreeBSD]. La última versión de este documento está siempre disponible en el extref:{mailing-list-faq}[servidor de FreeBSD]. También se puede descargar como un único archivo link:.[HTML] con HTTP o como texto plano, PostScript, PDF, etc. desde el https://download.freebsd.org/doc/[servidor FTP de FreeBSD]. También es posible que desee https://www.FreeBSD.org/search/[Buscar en las FAQ]. ''' toc::[] [[introduction]] == Introducción Como es habitual en las FAQ, este documento pretende cubrir las preguntas más frecuentes relacionadas con las listas de correo de FreeBSD (¡y por supuesto, responderlas!). Aunque originalmente tenía la intención de reducir el ancho de banda y evitar que se hicieran las mismas preguntas una y otra vez, las FAQ han sido reconocidas como un recurso de información valioso. Este documento intenta representar el consenso de la comunidad y, como tal, jamás debería ser __autoritario__. Sin embargo, si encuentra errores técnicos en este documento o tiene sugerencias sobre elementos que deban añadirse, por favor envíe un PR o un correo electrónico a la http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de correo del proyecto de documentación de FreeBSD]. Gracias. === ¿Cuál es el propósito de las listas de correo de FreeBSD? Las listas de correo de FreeBSD constituyen el canal principal de comunicación de la comunidad de FreeBSD, cubriendo varias áreas y comunidades de intereses diferentes. === ¿Quién es el público de las listas de correo de FreeBSD? Esto depende del cometido oficial de cada lista en particular. Algunas listas están más orientadas a los desarrolladores; otras están más orientadas hacia la comunidad de usuarios de FreeBSD en general. Por favor, vea http://lists.FreeBSD.org/mailman/listinfo[esta lista] para un resumen actual. === ¿Las listas de correo de FreeBSD están abiertas para que cualquiera pueda participar? Una vez más, esto depende del cometido oficial de cada lista en particular. Por favor, consulte el charter (la declaración del cometido de las listas de correo) antes de enviar un correo a la lista y siga la filosofía de dicha lista en los envíos que haga. Esto ayudará al resto de usuarios a sacar más provecho de la lista. Si después de leer las listas anteriores todavía no ha podido discernir a qué lista debe enviar su pregunta, probablemente pueda enviar la consulta a la lista freebsd-questions (pero por favor lea más abajo antes de hacerlo). Tenga en cuenta también que las listas de correo tradicionalmente han estado abiertas a la recepción de correo por parte de no subscriptores. Esta ha sido una elección deliberada, para ayudar a que unirse a la comunidad de FreeBSD sea un proceso más fácil y para fomentar el intercambio abierto de ideas. No obstante, debido a los abusos de envío masivo de correos por parte de algunos individuos, ciertas listas ahora tienen una política según la cual las publicaciones de no suscriptores deben seleccionarse manualmente para asegurarse de que sean apropiadas. === ¿Cómo puedo suscribirme? Puede utilizar la http://lists.FreeBSD.org/mailman/listinfo[interfaz web de Mailman] para suscribirse a cualquiera de las listas públicas. === ¿Cómo puedo darme de baja? Puede utilizar exactamente la misma interfaz que en el caso anterior; o puede seguir las instrucciones que se añaden automáticamente al final de cualquier mensaje publicado en la lista. Por favor, no envíe mensajes de baja directamente a la lista de correo. Primero, con esto no obtendrá su objetivo, y en segundo lugar, irritará a los subscriptores y probablemente será increpado por ello. Se trata de un error bastante común cuando se comienza a utilizar listas de correo; por favor, intente evitarlo. === ¿Están los archivos históricos disponibles? Sí. Los archivos agrupados por hilo están disponibles http://docs.FreeBSD.org/mail/[aquí]. === ¿Las listas de correo están disponibles en un formato resumen (digest)? Sí. Consulte http://lists.FreeBSD.org/mailman/listinfo[la interfaz web de Mailman]. [[etiquette]] == Normas de protocolo de las listas de correo La participación en listas de correo, como la colaboración en cualquier otra comunidad, se fundamenta en unas bases o estructuras comunes sobre las cuales el proceso comunicativo tiene lugar. Por favor, recuerde enviar únicamente preguntas o respuestas adecuadas y siga las siguientes reglas de protocolo. === ¿Qué debo hacer antes de enviar un correo? Usted ha completado el paso más importante al comenzar a leer este documento. Sin embargo, si es nuevo en FreeBSD, es posible que primero deba familiarizarse con el software y toda la historia social que lo rodea, leyendo los numerosos https://www.FreeBSD.org/docs/books/[libros y artículos disponibles]. Son puntos de particular interés el documento extref:{faq}[Las preguntas más frecuentes en FreeBSD (FAQ)], el extref:{handbook}[Manual de FreeBSD] y los artículos extref:{freebsd-questions-article}[Cómo obtener los mejores resultados de la lista de correo FreeBSD-questions], extref:{explaining-bsd}[Explicando BSD], y extref:{new-users}[Primeros pasos en FreeBSD]. Enviar una consulta sobre algo que ya está respondido en los documentos anteriores se considera malas formas. Esto no ocurre porque los voluntarios que colaboran en las listas sean personas especialmente susceptibles, sino porque después de un cierto tiempo respondiendo una y otra vez las mismas preguntas las personas comienzan a sentirse frustradas. Tenga siempre en cuenta que casi todo el trabajo realizado en FreeBSD lo realizan voluntarios, y que solo somos humanos. === ¿Qué se considera un mensaje inapropiado? * Las publicaciones deben seguir el charter de la lista de correo. * Por favor, evite los ataques personales. Como buenos ciudadanos de la red, debemos tratar de mantenernos en unos altos estándares de comportamiento. * No se permite el spam, en ningún caso. Las listas de correo se procesan constantemente para asegurarse del cumplimiento de esta regla. === ¿Qué se considera como una norma de etiqueta apropiada cuando se envían correos a las listas? * Por favor ajuste todas las líneas a 75 caracteres, ya que no todo el mundo utiliza programas de correo con interfaces gráficas avanzadas. * Por favor, tenga presente el hecho de que el ancho de banda no es un recurso infinito. No todo el mundo lee el correo electrónico a través de conexiones de alta velocidad, de forma que si sus mensajes contienen adjuntos tales como el contenido del fichero [.filename]#config.log# o un amplio seguimiento de la pila, considere colocar esa información en un sitio web y proporcione solo la URL. Recuerde, también, que estas publicaciones se archivarán indefinidamente, por lo que las publicaciones enormes aumentarán el tamaño de los archivos mucho después de que su propósito haya expirado. * Formatee su mensaje de forma que sea legible, y, ¡¡¡¡¡POR FAVOR NO GRITE!!!!! No subestime el efecto que tiene un mensaje de correo mal formateado, y no solo en las listas de correo de FreeBSD. Su mensaje de correo es todo lo que la gente ve de usted, y si está mal formateado, mal escrito, lleno de errores y/o tiene muchos signos de exclamación, dará a la gente una mala impresión de usted. * Por favor utilice el idioma (y el léxico) apropiado para cada lista de correo. Existen muchas listas de habla no inglesa, consulte el siguiente https://www.FreeBSD.org/community/mailinglists/[enlace]. + Para los que no lo son, sabemos que muchas personas no hablan inglés como primer idioma, y tratamos de hacer concesiones. Criticar a hablantes de inglés no nativos por una gramática pobre o errores en su escritura se consideran (muy) malos modos. FreeBSD posee un excelente bagaje en este tema; por favor ayúdenos a mantener esta tradición. * Por favor utilice un Mail User Agent (MUA) que cumpla los estándares de correo electrónico. Muchos mensajes mal formateados provienen de http://www.lemis.com/grog/email/email.php[correos incorrectos o mal configurados]. Los siguientes agentes son tristemente conocidos por lo mal que estructuran y formatean los mensajes de correo sin que usted se de cuenta de ello: ** exmh ** Microsoft(R) Exchange ** Microsoft(R) Outlook(R) + Trate de no usar MIME: muchas personas usan correos que no se llevan muy bien con MIME. * Asegúrese de que su hora y zona horaria están configuradas correctamente. Esto puede parecer un poco estúpido a primera vista, ya que su mensaje será recibido, pero muchas de las personas en estas listas de correo reciben varios cientos de mensajes al día. Frecuentemente, ordenan los mensajes entrantes por asunto y por fecha, y si su mensaje no aparece antes de la primera respuesta, pueden asumir que lo pasaron por alto y no molestarse en mirar. * Mucha de la información que deberá proporcionar es la salida de programas, como man:dmesg[8] o mensajes de consola, que generalmente aparecen en [.filename]#/var/log/messages#. No intente copiar esta información escribiéndola nuevamente; no solo es un trabajo penoso sino que es muy probable que se cometan errores. Para enviar contenidos de ficheros de log o bien haga una copia del fichero para que sea adjuntado al mensaje previa eliminación de la información no relevante, o bien utilice el método de copiar y pegar. Para la salida de programas tales como `dmesg`, redireccione la salida a un fichero y utilice alguno de los procedimientos anteriores. Por ejemplo, + [source,shell] .... % dmesg > /tmp/dmesg.out .... + Esto redirige la información al fichero [.filename]#/tmp/dmesg.out# * Cuando utilice cortar y pegar, tenga en cuenta que algunas de estas operaciones estropean sus mensajes. Este hecho es de particular importancia cuando se trata de enviar el contenido de ficheros [.filename]#Makefiles#, donde el `tabulador` es un carácter separador muy importante. Este es uno de los problemas más comunes de los envíos https://www.FreeBSD.org/support/[a la base de datos de informes de problemas]. Los [.filename]#Makefiles# con tabuladores transformados en espacios, o transformados en la secuencia de escape `=3B`, crean exasperación entre los commiters. === ¿Cuáles son las consideraciones especiales de etiqueta cuando se responde a un mensaje en las listas de correo? * Por favor incluya el texto del mensaje original que considere relevante. Recórtelo al mínimo, pero no exagere. Cualquier otra persona que no leyó el mensaje original debería ser capaz de entender de qué se está hablando. + Esto es particularmente importante en el caso de envíos del estilo de "sí, yo también veo esto", donde el mensaje original formado por cientos de líneas no aparece. * Utilice alguna técnica para identificar entre el texto original del mensaje y el texto que usted añada. Una convención común es anteponer "`>`" al mensaje original. Dejar espacios en blanco después de "`>`" y dejar líneas en blanco entre nuestro texto y el texto original. * Asegúrese de que las atribuciones del texto que está citando son correctas. Las personas pueden ofenderse si les atribuye palabras que ellos mismos no escribieron. * Por favor, no haga `top post`. Con esto, queremos decir que si está respondiendo a un mensaje, ponga sus respuestas después del texto. + ** R: Porque invierte el flujo lógico de la conversación. ** P: ¿Por qué el top posting está mal visto? + (Gracias a Randy Bush por la broma.) [[recurring]] == Temas recurrentes en las listas de correo La participación en las listas de correo, así como la participación en cualquier otra comunidad, se basa en una serie de normas básicas para posibilitar la comunicación. Muchas de las listas de correo presuponen un conocimiento de la historia del proyecto. En particular, existen ciertos temas que suelen aparecer regularmente a los recién llegados a la comunidad. Es responsabilidad de cada participante comprobar que sus mensajes no caen en alguna de estas categorías. Al hacerlo, ayudará a mantener a la lista en el tema, y probablemente se salve de ser atacado en el proceso. El mejor método para evitar esto consiste en familiarizarse con los http://docs.FreeBSD.org/mail/[archivos de las listas], así sabrá qué temas se han tratado con anterioridad. En este aspecto resulta de gran valor https://www.FreeBSD.org/search/#mailinglists[la interfaz de búsqueda] de la lista de correo. (Si ese método no produce resultados útiles, complételo con una búsqueda en su motor de búsqueda principal favorito). Si se familiariza con los archivos históricos, no solo aprenderá sobre los temas que se han tratado anteriormente, también aprenderá cómo se produce la discusión en la lista, quiénes son los participantes y quién es el público objetivo. Estos puntos conviene conocerlos antes de preguntar en cualquier lista de correo, no solo en las de FreeBSD. No hay duda de que los archivos son bastante extensos, y algunas preguntas se repiten con más frecuencia que otras, algunas veces camufladas dentro de hilos donde la línea del asunto no refleja precisamente el nuevo contenido del mensaje. Sin embargo, es trabajo suyo, quien envía el mensaje, evitar que se produzcan temas recurrentes. [[bikeshed]] == ¿Qué es un "Bikeshed"? Literalmente, un `bikeshed` es un cobertizo exterior donde se puede almacenar un vehículo de dos ruedas. No obstante, en la jerga de FreeBSD, el término se refiere a temas que son tan simples que (casi) cualquiera puede ofrecer una opinión y, a menudo (casi), todos lo hacen. El origen de este término se explica con más detalle en extref:{faq}[este documento, bikeshed-painting]. Simplemente debe tener un conocimiento práctico de este concepto antes de publicar en cualquier lista de correo de FreeBSD. De una forma más general, un bikeshed es un asunto que tiende a generar meta-discusiones y ataques si no se han leído las discusiones anteriores. Por favor, colabore en el mantenimiento de las listas de correo evitando los bikesheds siempre que pueda. Gracias. [[acknowledgments]] == Agradecimientos Greg Lehey mailto:grog@FreeBSD.org[grog@FreeBSD.org]:: Autor original de la mayor parte del material que cubre las normas de etiqueta de las listas, tomadas del artículo extref:{freebsd-questions-article}[Cómo obtener los mejores resultados de la lista de correo FreeBSD-questions]. Mark Linimon mailto:linimon@FreeBSD.org[linimon@FreeBSD.org]:: Por la creación del borrador inicial de estas FAQ. diff --git a/documentation/content/fr/books/handbook/_index.adoc b/documentation/content/fr/books/handbook/_index.adoc index 2588c77acc..6437981c87 100644 --- a/documentation/content/fr/books/handbook/_index.adoc +++ b/documentation/content/fr/books/handbook/_index.adoc @@ -1,51 +1,51 @@ --- title: Manuel FreeBSD authors: trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] next: books/handbook/preface showBookMenu: true weight: 0 path: "/books/handbook/" --- = Manuel FreeBSD :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Résumé Bienvenue à FreeBSD! Ce manuel décrit l'installation et l'utilisation quotidienne de _FreeBSD {rel121-current}-RELEASE_, et _FreeBSD {rel113-current}-RELEASE_. Ce document est le résultat du travail toujours en cours de nombreuses personnes. Certaines sections peuvent ne pas être à jour. Les personnes qui sont intéressées pour aider à mettre à jour et à compléter ce document devraient envoyer un courrier électronique à la {freebsd-doc}. -La dernière version anglaise de ce document est disponible sur le https://www.FreeBSD.org/[site Web de FreeBSD]. Les versions antérieures peuvent être obtenues auprès de https://docs.FreeBSD.org/doc/[http://docs.FreeBSD.org/doc/]). Il peut être aussi téléchargé dans divers formats et options de compression depuis le https://download.freebsd.org/ftp/doc/[serveur FTP FreeBSD] ou l'un des nombreux crossref:mirrors[mirrors-ftp,sites miroirs]. Des versions imprimées peuvent être achetées auprès de https://www.freebsdmall.com/[FreeBSD Mall]. Des recherches dans le Manuel et les autres documents peuvent être effectuées à partir de la link:https://www.FreeBSD.org/search/[page de recherches]. +La dernière version anglaise de ce document est disponible sur le https://www.FreeBSD.org/[site Web de FreeBSD]. Les versions antérieures peuvent être obtenues auprès de https://docs.FreeBSD.org/doc/[http://docs.FreeBSD.org/doc/]). Il peut être aussi téléchargé dans divers formats et options de compression depuis le https://download.freebsd.org/doc/[serveur FTP FreeBSD] ou l'un des nombreux crossref:mirrors[mirrors-ftp,sites miroirs]. Des versions imprimées peuvent être achetées auprès de https://www.freebsdmall.com/[FreeBSD Mall]. Des recherches dans le Manuel et les autres documents peuvent être effectuées à partir de la link:https://www.FreeBSD.org/search/[page de recherches]. N.d.T.: Contactez {fonvieille} si vous voulez collaborer à la traduction. ''' diff --git a/documentation/content/fr/books/handbook/book.adoc b/documentation/content/fr/books/handbook/book.adoc index fb2d816b42..1b8886fdce 100644 --- a/documentation/content/fr/books/handbook/book.adoc +++ b/documentation/content/fr/books/handbook/book.adoc @@ -1,154 +1,154 @@ --- title: Manuel FreeBSD authors: - author: Groupe de Documentation FreeBSD copyright: 1995-2020 Groupe de Documentation FreeBSD trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] --- = Manuel FreeBSD :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] [abstract] Résumé Bienvenue à FreeBSD! Ce manuel décrit l'installation et l'utilisation quotidienne de _FreeBSD {rel121-current}-RELEASE_, et _FreeBSD {rel113-current}-RELEASE_. Ce document est le résultat du travail toujours en cours de nombreuses personnes. Certaines sections peuvent ne pas être à jour. Les personnes qui sont intéressées pour aider à mettre à jour et à compléter ce document devraient envoyer un courrier électronique à la {freebsd-doc}. -La dernière version anglaise de ce document est disponible sur le https://www.FreeBSD.org/[site Web de FreeBSD]. Les versions antérieures peuvent être obtenues auprès de https://docs.FreeBSD.org/doc/[http://docs.FreeBSD.org/doc/]). Il peut être aussi téléchargé dans divers formats et options de compression depuis le https://download.freebsd.org/ftp/doc/[serveur FTP FreeBSD] ou l'un des nombreux crossref:mirrors[mirrors-ftp,sites miroirs]. Des versions imprimées peuvent être achetées auprès de https://www.freebsdmall.com/[FreeBSD Mall]. Des recherches dans le Manuel et les autres documents peuvent être effectuées à partir de la link:https://www.FreeBSD.org/search/[page de recherches]. +La dernière version anglaise de ce document est disponible sur le https://www.FreeBSD.org/[site Web de FreeBSD]. Les versions antérieures peuvent être obtenues auprès de https://docs.FreeBSD.org/doc/[http://docs.FreeBSD.org/doc/]). Il peut être aussi téléchargé dans divers formats et options de compression depuis le https://download.freebsd.org/doc/[serveur FTP FreeBSD] ou l'un des nombreux crossref:mirrors[mirrors-ftp,sites miroirs]. Des versions imprimées peuvent être achetées auprès de https://www.freebsdmall.com/[FreeBSD Mall]. Des recherches dans le Manuel et les autres documents peuvent être effectuées à partir de la link:https://www.FreeBSD.org/search/[page de recherches]. N.d.T.: Contactez {fonvieille} si vous voulez collaborer à la traduction. ''' toc::[] :sectnums!: include::{chapters-path}preface/_index.adoc[leveloffset=+1] :sectnums: // Section one include::{chapters-path}parti.adoc[] include::{chapters-path}introduction/_index.adoc[leveloffset=+1] include::{chapters-path}bsdinstall/_index.adoc[leveloffset=+1] include::{chapters-path}basics/_index.adoc[leveloffset=+1] include::{chapters-path}ports/_index.adoc[leveloffset=+1] include::{chapters-path}x11/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[] include::{chapters-path}desktop/_index.adoc[leveloffset=+1] include::{chapters-path}multimedia/_index.adoc[leveloffset=+1] include::{chapters-path}kernelconfig/_index.adoc[leveloffset=+1] include::{chapters-path}printing/_index.adoc[leveloffset=+1] include::{chapters-path}linuxemu/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[] include::{chapters-path}config/_index.adoc[leveloffset=+1] include::{chapters-path}boot/_index.adoc[leveloffset=+1] include::{chapters-path}users/_index.adoc[leveloffset=+1] include::{chapters-path}security/_index.adoc[leveloffset=+1] include::{chapters-path}jails/_index.adoc[leveloffset=+1] include::{chapters-path}mac/_index.adoc[leveloffset=+1] include::{chapters-path}audit/_index.adoc[leveloffset=+1] include::{chapters-path}disks/_index.adoc[leveloffset=+1] include::{chapters-path}geom/_index.adoc[leveloffset=+1] include::{chapters-path}zfs/_index.adoc[leveloffset=+1] include::{chapters-path}filesystems/_index.adoc[leveloffset=+1] include::{chapters-path}vinum/_index.adoc[leveloffset=+1] include::{chapters-path}virtualization/_index.adoc[leveloffset=+1] include::{chapters-path}l10n/_index.adoc[leveloffset=+1] include::{chapters-path}cutting-edge/_index.adoc[leveloffset=+1] include::{chapters-path}dtrace/_index.adoc[leveloffset=+1] // Section four include::{chapters-path}partiv.adoc[] include::{chapters-path}serialcomms/_index.adoc[leveloffset=+1] include::{chapters-path}ppp-and-slip/_index.adoc[leveloffset=+1] include::{chapters-path}mail/_index.adoc[leveloffset=+1] include::{chapters-path}network-servers/_index.adoc[leveloffset=+1] include::{chapters-path}firewalls/_index.adoc[leveloffset=+1] include::{chapters-path}advanced-networking/_index.adoc[leveloffset=+1] // Section five include::{chapters-path}partv.adoc[] :sectnums!: include::{chapters-path}mirrors/_index.adoc[leveloffset=+1] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] include::{chapters-path}eresources/_index.adoc[leveloffset=+1] include::{chapters-path}pgpkeys/_index.adoc[leveloffset=+1] :sectnums: diff --git a/documentation/content/ja/books/handbook/_index.adoc b/documentation/content/ja/books/handbook/_index.adoc index c78775b79e..b63d0a2f31 100644 --- a/documentation/content/ja/books/handbook/_index.adoc +++ b/documentation/content/ja/books/handbook/_index.adoc @@ -1,56 +1,56 @@ --- title: FreeBSD ハンドブック authors: - author: FreeBSD ドキュメンテーションプロジェクト copyright: 1995-2021 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] next: books/handbook/preface showBookMenu: true weight: 0 path: "/books/handbook/" --- = FreeBSD ハンドブック :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] 概要 FreeBSD へようこそ! このハンドブックは __FreeBSD {rel130-current}-RELEASE__, __FreeBSD {rel122-current}-RELEASE__ および __FreeBSD {rel114-current}-RELEASE__ のインストールと日常での使い方について記述したものです。 本ハンドブックはさまざまな人々による編集の成果で、 現在も改編作業中です。 いま存在するセクションの中には情報が古くなってしまっているものがあります。 もし、この文書を新しくしたり、 新しい情報の追加に協力したいとお考えなら、 {freebsd-doc} まで電子メールを (英語で) 送ってください。 -このハンドブックの最新バージョンは、いつでも http://www.jp.FreeBSD.org/[日本国内版の FreeBSD ウェブサイト] および https://www.FreeBSD.org/ja/[FreeBSD ウェブサイト] から入手できます。 この文書の以前のバージョンは https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/] から入手できます。 また、他のさまざまな文書形式、圧縮形式のものが https://download.freebsd.org/ftp/doc/[FreeBSD FTP サーバ] や数多くの <> からダウンロードできます。 このハンドブックの書籍版 (英語版) は、 https://www.freebsdmall.com/[FreeBSD Mall] から購入できます。また、 ハンドブックおよび他の文書の検索については、link:https://www.FreeBSD.org/search/[検索ページ] で行なうことができます。 +このハンドブックの最新バージョンは、いつでも http://www.jp.FreeBSD.org/[日本国内版の FreeBSD ウェブサイト] および https://www.FreeBSD.org/ja/[FreeBSD ウェブサイト] から入手できます。 この文書の以前のバージョンは https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/] から入手できます。 また、他のさまざまな文書形式、圧縮形式のものが https://download.freebsd.org/doc/[FreeBSD FTP サーバ] や数多くの <> からダウンロードできます。 このハンドブックの書籍版 (英語版) は、 https://www.freebsdmall.com/[FreeBSD Mall] から購入できます。また、 ハンドブックおよび他の文書の検索については、link:https://www.FreeBSD.org/search/[検索ページ] で行なうことができます。 FreeBSD ハンドブック日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクト (FreeBSD doc-jp) がおこなっています。 ハンドブックの日本語訳に関することは FreeBSD {doc-jp} において日本語で議論されています。 文書の日本語訳に関するお問い合わせや、 文書の原文に関する問い合わせをしたいが英語が得意でないという方は FreeBSD {doc-jp} まで、日本語でコメントをお寄せください。 ''' diff --git a/documentation/content/ja/books/handbook/book.adoc b/documentation/content/ja/books/handbook/book.adoc index b8769d0d51..32ca1e6085 100644 --- a/documentation/content/ja/books/handbook/book.adoc +++ b/documentation/content/ja/books/handbook/book.adoc @@ -1,134 +1,134 @@ --- title: FreeBSD ハンドブック authors: - author: FreeBSD ドキュメンテーションプロジェクト copyright: 1995-2021 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] --- = FreeBSD ハンドブック :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] [abstract] 概要 FreeBSD へようこそ! このハンドブックは __FreeBSD {rel122-current}-RELEASE__, __FreeBSD {rel121-current}-RELEASE__ および __FreeBSD {rel114-current}-RELEASE__ のインストールと日常での使い方について記述したものです。 本ハンドブックはさまざまな人々による編集の成果で、 現在も改編作業中です。 いま存在するセクションの中には情報が古くなってしまっているものがあります。 もし、この文書を新しくしたり、 新しい情報の追加に協力したいとお考えなら、 {freebsd-doc} まで電子メールを (英語で) 送ってください。 -このハンドブックの最新バージョンは、いつでも http://www.jp.FreeBSD.org/[日本国内版の FreeBSD ウェブサイト] および https://www.FreeBSD.org/ja/[FreeBSD ウェブサイト] から入手できます。 この文書の以前のバージョンは https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/] から入手できます。 また、他のさまざまな文書形式、圧縮形式のものが https://download.freebsd.org/ftp/doc/[FreeBSD FTP サーバ] や数多くの <> からダウンロードできます。 このハンドブックの書籍版 (英語版) は、 https://www.freebsdmall.com/[FreeBSD Mall] から購入できます。また、 ハンドブックおよび他の文書の検索については、link:https://www.FreeBSD.org/search/[検索ページ] で行なうことができます。 +このハンドブックの最新バージョンは、いつでも http://www.jp.FreeBSD.org/[日本国内版の FreeBSD ウェブサイト] および https://www.FreeBSD.org/ja/[FreeBSD ウェブサイト] から入手できます。 この文書の以前のバージョンは https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/] から入手できます。 また、他のさまざまな文書形式、圧縮形式のものが https://download.freebsd.org/doc/[FreeBSD FTP サーバ] や数多くの <> からダウンロードできます。 このハンドブックの書籍版 (英語版) は、 https://www.freebsdmall.com/[FreeBSD Mall] から購入できます。また、 ハンドブックおよび他の文書の検索については、link:https://www.FreeBSD.org/search/[検索ページ] で行なうことができます。 FreeBSD ハンドブック日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクト (FreeBSD doc-jp) がおこなっています。 ハンドブックの日本語訳に関することは FreeBSD {doc-jp} において日本語で議論されています。 文書の日本語訳に関するお問い合わせや、 文書の原文に関する問い合わせをしたいが英語が得意でないという方は FreeBSD {doc-jp} まで、日本語でコメントをお寄せください。 ''' toc::[] :sectnums!: include::{chapters-path}preface/_index.adoc[leveloffset=+1] :sectnums: // Section one include::{chapters-path}parti.adoc[] include::{chapters-path}introduction/_index.adoc[leveloffset=+1] include::{chapters-path}bsdinstall/_index.adoc[leveloffset=+1] include::{chapters-path}basics/_index.adoc[leveloffset=+1] include::{chapters-path}ports/_index.adoc[leveloffset=+1] include::{chapters-path}x11/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[] include::{chapters-path}desktop/_index.adoc[leveloffset=+1] include::{chapters-path}multimedia/_index.adoc[leveloffset=+1] include::{chapters-path}kernelconfig/_index.adoc[leveloffset=+1] include::{chapters-path}printing/_index.adoc[leveloffset=+1] include::{chapters-path}linuxemu/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[] include::{chapters-path}config/_index.adoc[leveloffset=+1] include::{chapters-path}boot/_index.adoc[leveloffset=+1] include::{chapters-path}users/_index.adoc[leveloffset=+1] include::{chapters-path}security/_index.adoc[leveloffset=+1] include::{chapters-path}disks/_index.adoc[leveloffset=+1] include::{chapters-path}l10n/_index.adoc[leveloffset=+1] include::{chapters-path}cutting-edge/_index.adoc[leveloffset=+1] // Section four include::{chapters-path}partiv.adoc[] include::{chapters-path}serialcomms/_index.adoc[leveloffset=+1] include::{chapters-path}ppp-and-slip/_index.adoc[leveloffset=+1] include::{chapters-path}mail/_index.adoc[leveloffset=+1] include::{chapters-path}advanced-networking/_index.adoc[leveloffset=+1] // Section five include::{chapters-path}partv.adoc[] :sectnums!: include::{chapters-path}mirrors/_index.adoc[leveloffset=+1] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] include::{chapters-path}eresources/_index.adoc[leveloffset=+1] include::{chapters-path}pgpkeys/_index.adoc[leveloffset=+1] :sectnums: diff --git a/documentation/content/pt-br/articles/committers-guide/_index.adoc b/documentation/content/pt-br/articles/committers-guide/_index.adoc index 6bdd53847e..2ca12d7089 100644 --- a/documentation/content/pt-br/articles/committers-guide/_index.adoc +++ b/documentation/content/pt-br/articles/committers-guide/_index.adoc @@ -1,2156 +1,2156 @@ --- title: Guia dos Committers authors: - author: Projeto de Documentação do FreeBSD copyright: 1999-2020 Projeto de Documentação do FreeBSD trademarks: ["freebsd", "coverity", "ibm", "intel", "sparc", "general"] --- = Guia dos Committers :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/committers-guide/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Resumo Este documento fornece informações para a comunidade de committers do FreeBSD. Todos os novos committers devem ler este documento antes de começar, e os committers existentes são fortemente encorajados a revisá-lo de tempos em tempos. Quase todos os desenvolvedores do FreeBSD possuem direitos de commit para um ou mais repositórios. No entanto, alguns desenvolvedores não tem, e algumas das informações aqui se aplicam a eles também. (Por exemplo, algumas pessoas só têm direitos para trabalhar com o banco de dados do Relatório de Problemas). Por favor, veja <> para mais informações. Este documento também pode ser de interesse para os membros da comunidade FreeBSD que querem aprender mais sobre como o projeto funciona. ''' toc::[] [[admin]] == Detalhes Administrativos [.informaltable] [cols="1,1", frame="none"] |=== |_Métodos de login_ | man:ssh[1],_apenas no protocolo 2 |_Servidor Principal de Shell_ |`freefall.FreeBSD.org` |_Servidor SMTP_ |`smtp.FreeBSD.org:587` (veja também <>). |Raiz do Subversion para o `_src/_` |`svn+ssh://repo.FreeBSD.org/base` (veja também <>). |Raiz do Subversion para o `_doc/_` |`svn+ssh://repo.FreeBSD.org/doc` (veja também <>). |Raiz do Subversion para o `_ports/_` |`svn+ssh://repo.FreeBSD.org/ports` (veja também <>). |_Listas de Discussão Internas_ |developers (tecnicamente chamada de all-developers), doc-developers, doc-committers, ports-developers, ports-committers, src-developers, src-committers. (cada repositório do projeto tem as suas próprias listas de discussão -developers e -committers. Os arquivos destas listas podem ser encontrados nos arquivos [.filename]#/local/mail/repository-name-developers-archive# e [.filename]#/local/mail/repository-name-committers-archive# no cluster `FreeBSD.org`.) |_Relatórios mensais do Core Team_ |Disponíveis no diretório [.filename]#/home/core/public/monthly-reports# do cluster `FreeBSD.org`. |_Relatórios mensais da Equipe de Gestão do Ports_ |Disponíveis no diretório [.filename]#/home/portmgr/public/monthly-reports# do cluster `FreeBSD.org`. |_Branchs SVN do `src/` dignas de atenção_ |`stable/n` (`n`-STABLE), `head` (-CURRENT) |=== O man:ssh[1] é necessário para se conectar aos servidores do projeto. Para mais informações, veja <>. Links Úteis: * https://www.FreeBSD.org/internal/[Páginas Internas do Projeto FreeBSD] * https://www.FreeBSD.org/internal/machines/[Servidores do Projeto FreeBSD] * https://www.FreeBSD.org/administration/[Grupos Administrativos do Projeto FreeBSD] [[pgpkeys]] == Chaves OpenPGP para o FreeBSD O projeto FreeBSD utiliza chaves criptográficas em conformidade com o padrão OpenPGP (__Pretty Good Privacy__) para autenticar os committers. Mensagens contendo informações importantes como chaves públicas SSH podem ser assinadas com uma chave OpenPGP para provar que elas vieram realmente do committer. Veja http://www.nostarch.com/pgp_ml.htm[PGP & GPG: Email for the Practical Paranoid by Michael Lucas] e http://en.wikipedia.org/wiki/Pretty_Good_Privacy[] para maiores informações. [[pgpkeys-creating]] === Criando uma chave As chaves existentes podem ser usadas, mas elas devem ser obtidas com o [.filename]#doc/head/shared/pgpkeys/checkkey.sh# primeiro. Neste caso, certifique-se que a chave contenha um ID de usuário FreeBSD. Para quem ainda não tem uma chave OpenPGP, ou precisa de uma nova chave para atender aos requisitos de segurança do FreeBSD, nesta seção iremos mostrar como gerar uma. [[pgpkeys-create-steps]] [.procedure] . Instale o [.filename]#security/gnupg#. Digite estas linhas no [.filename]#~/.gnupg/gpg.conf# para definir padrões mínimos aceitáveis: + [.programlisting] .... fixed-list-mode keyid-format 0xlong personal-digest-preferences SHA512 SHA384 SHA256 SHA224 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed use-agent verify-options show-uid-validity list-options show-uid-validity sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g cert-digest-algo SHA512 .... . Gere uma chave: + [source,shell] .... % gpg --full-gen-key gpg (GnuPG) 2.1.8; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Warning: using insecure memory! Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 2048 <.> Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 3y <.> Key expires at Wed Nov 4 17:20:20 2015 MST Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Chucky Daemon <.> Email address: notreal@example.com Comment: You selected this USER-ID: "Chucky Daemon " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o You need a Passphrase to protect your secret key. .... <.> Chaves de 2048-bit com uma expiração de 3 anos proveem uma proteção adequada nos dias de hoje (2013-12). O artigo http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits[] descreve a situação em mais detalhes. <.> Três anos é um tempo de vida para a chave que é curto o suficiente para tornar obsoletas as chaves enfraquecidas pelo avanço do poder computacional, mas é tempo suficiente para reduzir os principais problemas de gerenciamento. <.> Use o seu nome real, preferencialmente o mesmo que consta do seu documento de identificação (ID) emitido pelo seu governo para tornar mais fácil para as outras pessoas confirmarem sua identidade. Você pode inserir um texto adicional para ajudar outras pessoas a identificar você na seção `Comment`. + Depois que o endereço de e-mail é inserido, uma senha é solicitada. Os métodos de criação de uma frase secreta segura são controversos. Em vez de sugerir um único caminho, aqui estão alguns links para sites que descrevem vários métodos: http://world.std.com/~reinhold/diceware.html[], http://www.iusmentis.com/security/passphrasefaq/[], http://xkcd.com/936/[] e http://en.wikipedia.org/wiki/Passphrase[]. Proteja a chave privada e a frase secreta. Se a chave privada ou a frase secreta pode ter sido comprometida ou exposta, notifique imediatamente mailto:accounts@FreeBSD.org[accounts@FreeBSD.org] e revogue a chave. O processo para commit da nova chave é mostrado em <>. [[kerberos-ldap]] == Kerberos e LDAP Web Password para o cluster do FreeBSD O cluster do FreeBSD requer uma senha do Kerberos para acessar certos serviços. A senha do Kerberos também serve como a senha LDAP para a web, já que o LDAP faz um proxy para o Kerberos no cluster. Alguns dos serviços que exigem isso incluem: * https://bugs.freebsd.org/bugzilla[Bugzilla] * https://ci.freebsd.org[Jenkins] Para criar uma nova conta do Kerberos no cluster do FreeBSD, ou para redefinir uma senha do Kerberos para uma conta existente usando um gerador de senha aleatória: [source,shell] .... % ssh kpasswd.freebsd.org .... [NOTE] ==== Isto deve ser feito a partir de uma máquina fora do cluster do FreeBSD.org. ==== Uma senha do Kerberos também pode ser definida manualmente, para isto logue no servidor `freefall.FreeBSD.org` e execute: [source,shell] .... % kpasswd .... [NOTE] ==== A menos que os serviços autenticados por Kerberos do cluster do FreeBSD.org tenham sido usados anteriormente, o erro `Client unknown` será exibido. Este erro significa que o método `ssh kpasswd.freebsd.org` mostrado acima deve ser usado primeiro para inicializar a conta Kerberos. ==== [[committer.types]] == Tipos de Commit Bits O repositório do FreeBSD possui um número de componentes que, quando combinados, suportam os fontes básicos do sistema operacional, a documentação, a infraestrutura de ports de aplicativos de terceiros e vários utilitários mantidos. Quando os commit bits do FreeBSD são alocados, as áreas da árvore onde o bit pode ser usado são especificadas. Geralmente, as áreas associadas a um bit refletem quem autorizou a alocação do bit de commit. Áreas adicionais de autoridade podem ser adicionadas em uma data posterior: quando isso ocorre, o committer deve seguir procedimentos normais de atribuição de bits de confirmação para essa área da árvore, buscando a aprovação da entidade apropriada e possivelmente obtendo um mentor para essa área por algum período de tempo. [.informaltable] [cols="1,1,1", frame="none"] |=== |__Tipo de Committer__ |__Responsável__ |__Componentes da Árvore__ |src |core@ |src/, doc/ sujeito a revisão apropriada |doc |doceng@ |doc/, ports/, src/ documentação |ports |portmgr@ |ports/ |=== Os commit bits alocados antes do desenvolvimento da noção de áreas de autoridade podem ser apropriados para uso em muitas partes da árvore. No entanto, o senso comum determina que um committer que não tenha trabalhado anteriormente em uma área da árvore busque alguém para realizar uma revisão antes de realizar o commit, busque a aprovação da parte responsável apropriada e/ou trabalhe com um mentor. Uma vez que as regras relativas à manutenção de código diferem por área da árvore, isso é tanto para o benefício do committer trabalhando em uma área de menos familiar quanto para as outras pessoas trabalhando na árvore. Committers são encorajados a buscar revisão do seu trabalho como parte do processo normal de desenvolvimento, independentemente da área da árvore onde o trabalho está ocorrendo. === Política para atividade de Committers em outras árvores * Todos os committers podem modificar [.filename]#base/head/shared/misc/committers-*.dot#, [.filename]#base/head/usr.bin/calendar/calendars/calendar.freebsd#, e [.filename]#ports/head/astro/xearth/files#. * os doc committers podem efetuar commits de alterações na documentação sob [.filename]#src#, tal como man pages, READMEs, banco de dados do fortune, arquivos de calendários, e comentar correções sem aprovação de um src committer, sujeito aos cuidados normais necessários para um commit seguro. * Qualquer committer pode fazer alterações em qualquer outra árvore com um "Approved by" de um committer que não esteja sob mentoria e que tenha o bit apropriado. * Os committers podem adquirir um bit adicional pelo processo usual de encontrar um mentor que os proporá ao core, doceng ou portmgr, conforme apropriado. Quando aprovados, eles serão adicionados ao 'access' e o período normal de mentoria irá ocorrer, o que envolverá a continuidade do uso do "Approved by" por um período. * O "Approved by" só é aceitável vindo de src committers que não estejam sob mentoria - os committers mentorados podem fornecer um "Reviewed by" mas não um "Approved by". [[subversion-primer]] == Subversion Primer Supõe-se que novos committers já estejam familiarizados com a operação básica do Subversion. Se não, comece lendo o http://svnbook.red-bean.com/[Subversion Book]. [[svn-intro]] === Introdução O repositório de código fonte do FreeBSD mudou do `CVS` para o Subversion em 31 de maio de 2008. O primeiro commit real no `SVN` é o __r179447__. O repositório do FreeBSD `doc/www` foi migrado do `CVS` para o Subversion em 19 de Maio de 2012. O primeiro commit real no `SVN` foi o __r38821__. O repositório da coleção de `ports` do FreeBSD foi migrado do `CVS` para o Subversion em 14 de Julho 2012. O primeiro commit real no `SVN` foi o __r300894__. O Subversion pode ser instalado a partir da Coleção de Ports do FreeBSD, executando o comando: [source,shell] .... # pkg install subversion .... [[svn-getting-started]] === Primeiros Passos Existem algumas maneiras de obter uma cópia de trabalho da árvore do Subversion. Esta seção irá explicá-las. [[svn-getting-started-direct-checkout]] ==== Checkout direto O primeiro é fazer check-out diretamente do repositório principal. Para a árvore `src`, use: [source,shell] .... % svn checkout svn+ssh://repo.freebsd.org/base/head /usr/src .... Para a árvore `doc`, use: [source,shell] .... % svn checkout svn+ssh://repo.freebsd.org/doc/head /usr/doc .... Para a árvore da coleção de `ports`, use: [source,shell] .... % svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports .... [NOTE] ==== Embora os exemplos restantes neste documento tenham sido escritos tendo o workflow de trabalho com a árvore `src` em mente, os conceitos básicos são os mesmos para se trabalhar com o `doc` e com a árvore dos `ports`. Os ports relacionados às operações do Subversion estão listados em <>. ==== O comando acima irá fazer o checkout da árvore de código-fonte `CURRENT` como [.filename]#/usr/src/#, o qual pode ser qualquer diretório de destino no sistema de arquivos local. Omitir o argumento final desse comando faz com que a cópia de trabalho, neste caso, seja nominada como "head", mas ela poderá ser renomeada com segurança. O `svn+ssh` significa que o protocolo `SVN` será tunelado sobre o SSH. O nome do servidor é `repo.freebsd.org`, e `base` é o caminho para o repositório, e `head` é o subdiretório dentro do repositório. Se seu nome de login no projeto FreeBSD for diferente do nome de login usado na sua máquina local, inclua-o na URL (por exemplo `svn+ssh://jarjar@repo.freebsd.org/base/head`) ou adicione uma entrada no arquivo [.filename]#~/.ssh/config# no formato: [.programlisting] .... Host repo.freebsd.org User jarjar .... Este é o método mais simples, mas é difícil dizer quanta carga ele irá colocar no repositório. [NOTE] ==== O `svn diff` não requer acesso ao servidor pois o `SVN` armazena uma cópia de referência de todos os arquivos na cópia de trabalho. Isto, no entanto, significa que as cópias de trabalho do Subversion são muito grandes em tamanho. ==== [[svn-getting-started-base-layout]] ==== Branches `RELENG_*` e Layout Geral No `svn+ssh://repo.freebsd.org/base`, _base_ refere-se à árvore de código fonte. Similarmente, _ports_ refere-se à árvore de ports e assim por diante. Estes são repositórios separados com suas próprias seqüências de números de mudança, controles de acesso e email de commit. Para o repositório base, HEAD refere-se a árvore -CURRENT. Por exemplo, [.filename]#head/bin/ls# é o que entraria como [.filename]#/usr/src/bin/ls# em uma release. Alguns locais importantes são: * _/head/_ que corresponde a `HEAD`, também conhecido como `-CURRENT`. * _/stable/n_ que corresponde a `RELENG_n_`. * _/releng/n.n_ que corresponde a `RELENG_n_n`. * _/release/n.n.n_ que corresponde a `RELENG_n_n_n_RELEASE`. * _/vendor*_ é uma área de trabalho para importar branches de vendors. Este diretório em si não contém branches, no entanto, os seus subdiretórios contém. Isso contrasta com os diretórios __stable__, _releng_ e __release__. * _/projects_ e _/user_ são áreas de trabalho de branch. Como acima, o diretório _/user_ não contém branches em si. [[svn-getting-started-doc-layout]] ==== Branches e Layout do Projeto de Documentação do FreeBSD no `svn+ssh://repo.freebsd.org/doc`, _doc_ refere-se à raiz do repositório da árvore de código fonte. Em geral, a maior parte do trabalho do Projeto de Documentação do FreeBSD será feito dentro do branch [.filename]#head/# da árvore com os arquivos fontes da documentação. A documentação do FreeBSD é escrita e/ou traduzida para vários idiomas, cada um em um diretório separado no branch [.filename]#head/#. Cada conjunto de tradução contém vários subdiretórios para as várias partes do Projeto de Documentação do FreeBSD. Alguns diretórios notáveis são: * _/articles/_ contém o código fonte para artigos escritos por vários colaboradores do FreeBSD. * _/books/_ contém o código fonte para os diferentes livros, como o Handbook do FreeBSD. * _/htdocs/_ contém o código-fonte do website do FreeBSD. [[svn-getting-started-ports-layout]] ==== Branches e Layout da Árvore de Ports do FreeBSD No `svn+ssh: //repo.freebsd.org/ports`, _ports_ refere-se à raiz do repositório da árvore de ports. Em geral, a maior parte do trabalho na coleção de ports do FreeBSD será feito dentro da branch [.filename]#head/# da árvore de ports, que é a árvore de ports real usada para instalar software. Alguns outros locais importantes são: * /branches/RELENG_n_n_n que corresponde a `RELENG_n_n_n` e é usado para mesclar atualizações de segurança em preparação para uma release. * /tags/RELEASE_n_n_n que corresponde a `RELEASE_n_n_n` e representa uma tag de release da árvore de ports. * /tags/RELEASE_n_EOL representa o tag de end of life de um branch específico do FreeBSD. [[svn-daily-use]] === Uso diário Esta seção explicará como realizar operações comuns do dia-a-dia com o Subversion. [[svn-daily-use-help]] ==== Ajuda O `SVN` traz em si uma documentação interna de ajuda. Ela pode ser acessada digitando: [source,shell] .... % svn help .... Informações adicionais podem ser encontradas no http://svnbook.red-bean.com/[Subversion Book]. [[svn-daily-use-checkout]] ==== Checkout Como visto anteriormente, para fazer o checkout da branch principal (head) do FreeBSD: [source,shell] .... % svn checkout svn+ssh://repo.freebsd.org/base/head /usr/src .... Em algum momento, provavelmente será útil ter uma copia de trabalho mais do que apenas do `HEAD`, por exemplo, ao mesclar as alterações para stable/7. Portanto, pode ser útil ter uma verificação parcial da árvore completa (um check-out completo seria muito doloroso). Para fazer isso, primeiro confira a raiz do repositório: [source,shell] .... % svn checkout --depth=immediates svn+ssh://repo.freebsd.org/base .... Isso vai obter o `base` com todos os arquivos que ele contém (no momento da escrita, apenas o [.filename]#ROADMAP.txt#) e subdiretórios vazios para `head`, `stable`, `vendor` e assim por diante. É possível expandir a cópia de trabalho. Basta alterar a profundidade dos vários subdiretórios: [source,shell] .... % svn up --set-depth=infinity base/head % svn up --set-depth=immediates base/release base/releng base/stable .... O comando acima irá baixar uma cópia completa do `head`, além de cópias vazias de cada tag de `release`, de cada branch de `releng`, e de cada branch `stable`. Se numa data posterior você tiver necessidade de mesclar algo, por exemplo, com a `7-STABLE`, expanda a cópia de trabalho: [source,shell] .... % svn up --set-depth=infinity base/stable/7 .... As subárvores não precisam ser expandidas completamente. Por exemplo, para expandir apenas o `stable/7/sys` e depois expandir o resto do `stable/7`: [source,shell] .... % svn up --set-depth=infinity base/stable/7/sys % svn up --set-depth=infinity base/stable/7 .... Atualizar a árvore com `svn update` irá apenas atualizar o que foi pedido anteriormente (neste caso, `head` e `stable/7`), ele não irá puxar a árvore inteira. [[svn-daily-use-anonymous-checkout]] ==== Checkout Anonimo É possível efetuar o checkout anonimo o repositório Subversion do FreeBSD. Isso dará acesso a uma árvore somente leitura que pode ser atualizada, mas que não poderá ser enviada de volta para o repositório principal por meio de um commit. Para fazer isso, use: [source,shell] .... % svn co https://svn.FreeBSD.org/base/head /usr/src .... Mais detalhes sobre o uso do Subversion podem ser encontrados em extref:{handbook}mirrors[Usando o Subversion, svn]. [[svn-daily-use-updating-the-tree]] ==== Atualizando a Árvore Para atualizar uma cópia de trabalho para a revisão mais recente ou uma revisão específica: [source,shell] .... % svn update % svn update -r12345 .... [[svn-daily-use-status]] ==== Status Para ver as alterações locais que foram feitas na cópia de trabalho: [source,shell] .... % svn status .... Para mostrar alterações locais e arquivos que estão desatualizados, execute: [source,shell] .... % svn status --show-updates .... [[svn-daily-use-editing-and-committing]] ==== Editando e efetuando o commit O `SVN` não precisa ser avisado com antecedência sobre a edição de arquivos. Para efetuar o commit de todas as alterações no diretório atual e em todos os seus subdiretórios: [source,shell] .... % svn commit .... Para efetuar o commit de todas as alterações, por exemplo, nos arquivos [.filename]#lib/libfetch/# e [.filename]#usr/bin/fetch/# em uma única operação, execute: [source,shell] .... % svn commit lib/libfetch usr/bin/fetch .... Também existe um wrapper de commit para a árvore de ports para manipular as propriedades e para verificar a sanidade das mudanças: [source,shell] .... % /usr/ports/Tools/scripts/psvn commit .... [[svn-daily-use-adding-and-removing]] ==== Adicionando e Removendo Arquivos [NOTE] ==== Antes de adicionar arquivos, obtenha uma cópia do https://people.FreeBSD.org/~peter/auto-props.txt[auto-props.txt] (há também um https://people.FreeBSD.org/~beat/cvs2svn/auto-props.txt[versão específica da árvore de ports]) e adicione-o ao [.filename]#~/.subversion/config# seguindo as instruções contidas no arquivo. Se você adicionou algo antes de ler isto, use o comando `svn rm --keep-local` para apenas os arquivos adicionados, corrija seu arquivo de configuração e adicione-os novamente. O arquivo de configuração inicial é criado quando você executa um comando svn pela primeira vez, até mesmo algo tão simples quanto `svn help`. ==== Os arquivos são adicionados a um `SVN` repositório com `svn add`. Para adicionar um arquivo chamado __foo__, edite-o e depois execute: [source,shell] .... % svn add foo .... [NOTE] ==== A maioria dos novos arquivos fonte deve incluir uma string `$FreeBSD: head/pt_BR.ISO8859-1/articles/committers-guide/article.xml 53731 2020-01-01 14:37:53Z ebrandi $` próxima ao início do arquivo. Ao efetuar o commit, o `svn` expandirá a string `$FreeBSD: head/pt_BR.ISO8859-1/articles/committers-guide/article.xml 53731 2020-01-01 14:37:53Z ebrandi $`, adicionando o caminho do arquivo, o número da revisão, a data e a hora da confirmação e o nome de usuário do committer. Arquivos que não podem ser modificados podem ser enviados sem a string `$FreeBSD: head/pt_BR.ISO8859-1/articles/committers-guide/article.xml 53731 2020-01-01 14:37:53Z ebrandi $`. ==== Os arquivos podem ser removidos com `svn remove`: [source,shell] .... % svn remove foo .... O subversion não requer a exclusão do arquivo antes de usaramos o comando `svn rm` e, de fato, ele reclama se isso acontecer. É possível adicionar diretórios com `svn add`: [source,shell] .... % mkdir bar % svn add bar .... Apesar que o `svn mkdir` torna isso mais fácil, combinando a criação do diretório e a adição dele: [source,shell] .... % svn mkdir bar .... Como arquivos, os diretórios são removidos com `svn rm`. Não existe um comando separado especificamente para remover diretórios. [source,shell] .... % svn rm bar .... [[svn-daily-use-copying-and-moving]] ==== Copiando e Movendo Arquivos Este comando cria uma cópia do arquivo [.filename]#foo.c# nomeado [.filename]#bar.c#, com o novo arquivo também sob controle de versão e com o histórico completo de [.filename]#foo.c#: [source,shell] .... % svn copy foo.c bar.c .... Geralmente é preferível copiar desta forma ao invés de copiar o arquivo com comando `cp` e adicionando-o ao repositório com `svn add` porque desta forma o novo arquivo não herda a história do original. Para mover e renomear um arquivo: [source,shell] .... % svn move foo.c bar.c .... [[svn-daily-use-log-and-annotate]] ==== Logs e Anotações O `svn log` mostra revisões e mensagens de commit, as mais recentes são exibidas primeiro, para arquivos ou diretórios. Quando usado em um diretório, todas as revisões que afetaram o diretório e os arquivos nesse diretório são mostradas. O `svn annotate` , ou igualmente o `svn praise` ou `svn blame`, mostra o número de revisão mais recente e quem fez o commit dessa revisão para cada linha de um arquivo. [[svn-daily-use-diffs]] ==== Diffs O `svn diff` exibe alterações na cópia de trabalho. Diffs gerado por `SVN` são unificados e incluem novos arquivos por padrão na saída do diff. O `svn diff` pode mostrar as mudanças entre duas revisões do mesmo arquivo: [source,shell] .... % svn diff -r179453:179454 ROADMAP.txt .... Ele também pode mostrar todas as alterações para um changeset específico. Este comando mostra quais alterações foram feitas no diretório atual e em todos os subdiretórios do changeset 179454: [source,shell] .... % svn diff -c179454 . .... [[svn-daily-use-reverting]] ==== Revertendo Mudanças locais (incluindo adições e deleções) podem ser revertidas usando `svn revert`. Ele não atualiza arquivos desatualizados, apenas os substitui por cópias originais da versão original. [[svn-daily-use-conflicts]] ==== Conflitos Se um `svn update` resultou em um conflito de mesclagem, o Subversion irá lembrar quais arquivos têm conflitos e se recusará a fazer o commit de quaisquer alterações nesses arquivos até que seja explicitamente informado que os conflitos foram resolvidos. O procedimento simples, ainda não obsoleto, é: [source,shell] .... % svn resolved foo .... No entanto, o procedimento preferido é: [source,shell] .... % svn resolve --accept=working foo .... Os dois exemplos são equivalentes. Os valores possíveis para `--accept` são: * `working`: use a versão em seu diretório de trabalho (a qual se presume que foi editada para resolver os conflitos). * `base`: usar uma cópia original da versão que você tinha antes do `svn update`, descartando suas próprias alterações, as mudanças conflitantes e possivelmente outras mudanças intervenientes também. * `mine-full`: use o que você tinha antes do `svn update`, incluindo suas próprias mudanças, mas descartando as mudanças conflitantes, e possivelmente outras mudanças intervenientes também. * `theirs-full`: use a versão que foi recuperada quando você fez o `svn update`, descartando as suas próprias mudanças. === Uso Avançado [[svn-advanced-use-sparse-checkouts]] ==== Checkouts dispersos O `SVN` permite __sparse__, ou checkouts parciais de um diretório adicionando `--depth` a um `svn checkout`. Os argumentos válidos para `--depth` são: * `empty`: o próprio diretório sem qualquer conteúdo. * `files`: o diretório e quaisquer arquivos nele contidos. * `immediates`: o diretório e quaisquer arquivos e diretórios contidos nele, mas nenhum dos conteúdos dos subdiretórios. * `infinity`: qualquer coisa. A opção `--depth` se aplica a muitos outros comandos, incluindo `svn commit`, `svn revert` e o `svn diff`. Como o parâmetro `--depth` utilizado é persistente, existe uma opção `--set-depth` para o `svn update` que irá mudar a profundidade selecionada. Assim, dada a cópia de trabalho produzida pelo exemplo anterior: [source,shell] .... % cd ~/freebsd % svn update --set-depth=immediates . .... O comando acima irá popular a cópia de trabalho em _~/freebsd_ com [.filename]#ROADMAP.txt# e subdiretórios vazios, e nada acontecerá quando `svn update` for executado nos subdiretórios. No entanto, esse comando definirá a profundidade para _head_ (nesse caso) como infinito e o populará totalmente: [source,shell] .... % svn update --set-depth=infinity head .... [[svn-advanced-use-direct-operation]] ==== Operação Direta Certas operações podem ser realizadas diretamente no repositório sem tocar na cópia de trabalho. Especificamente, isso se aplica a qualquer operação que não exija a edição de um arquivo, incluindo: * `log`, `diff` * `mkdir` * `remove`, `copy`, `rename` * `propset`, `propedit`, `propdel` * `merge` A criação de uma branch é muito rápida. Este comando seria usado para criar a branch `RELENG_8`: [source,shell] .... % svn copy svn+ssh://repo.freebsd.org/base/head svn+ssh://repo.freebsd.org/base/stable/8 .... Isso equivale a esses comandos, que levam minutos e horas, em vez de segundos, dependendo da sua conexão de rede: [source,shell] .... % svn checkout --depth=immediates svn+ssh://repo.freebsd.org/base % cd base % svn update --set-depth=infinity head % svn copy head stable/8 % svn commit stable/8 .... [[svn-advanced-use-merging]] ==== Mesclando com `SVN` Esta seção lida com o merge de código de um branch para outro (normalmente, do head para um brach stable). [NOTE] ==== Em todos os exemplos abaixo, `$FSVN` refere-se à localização do repositório Subversion do FreeBSD, `svn+ssh://repo.freebsd.org/base`. ==== ===== Sobre o acompanhamento de mesclagem Do ponto de vista do usuário, informações de acompanhamento de mesclagem (ou mergeinfo) são armazenadas em uma propriedade chamada `svn:mergeinfo`, que é uma lista separada por vírgulas de revisões e intervalos de revisões que foram mescladas. Quando definido em um arquivo, ele se aplica somente a esse arquivo. Quando definido em um diretório, ele se aplica a esse diretório e seus descendentes (arquivos e diretórios), exceto aqueles que possuem o seu próprio `svn:mergeinfo`. Ele _não_ é herdado. Por exemplo, [.filename]#stable/6/contrib/openpam/# não herda implicitamente o mergeinfo de [.filename]#stable/6/#, ou do [.filename]#stable/6/contrib/#. Isso faria com que os checkouts parciais fossem difíceis de gerenciar. Em vez disso, o mergeinfo é explicitamente propagado pela árvore. Para mesclar algo em [.filename]#branch/foo/bar/#, estas regras se aplicam: . Se [.filename]#branch/foo/bar/# ainda não tiver um registro mergeinfo, mas um ancestral direto (por exemplo, [.filename]#branch/foo/#) tem, então esse registro será propagado para abaixo até [.filename]#branch/foo/bar/# antes que as informações sobre a mesclagem atual sejam registradas. . As informações sobre a mesclagem atual _não_ serão propagadas para o ancestral. . Se um descendente direto de [.filename]#branch/foo/bar/# (por exemplo, [.filename]#branch/foo/bar/baz/#) já tiver um registro mergeinfo, as informações sobre a mesclagem atual serão propagadas para ele. Se você considerar o caso em que uma revisão altera várias partes separadas da árvore (por exemplo, [.filename]#branch/foo/bar/# e [.filename]#branch/foo/quux/#), mas você só deseja mesclar alguns deles (por exemplo, [.filename]#branch/foo/bar/#), você verá que essas regras fazem sentido. Se mergeinfo fosse propagado, pareceria que a revisão também foi mesclada com [.filename]#branch/foo/quux/#, quando na verdade não foi. [[merge-source]] ===== Selecionando a branch de origem e de destino ao mesclar Mesclagens para as branches `stable/` devem originar-se da `head/`. Por exemplo: [source,shell] .... svn merge -c r123456 ^/head/ stable/11 svn commit stable/11 .... Mesclagens para as branches `releng/` devem sempre se originar da branch `stable/` correspondente. Por exemplo: [source,shell] .... svn merge -c r123456 ^/stable/11 releng/11.0 svn commit releng/11.0 .... [NOTE] ==== Os committers só podem se efetuar um commit para as branches `releng/` durante um ciclo de release após receber aprovação da Equipe de Engenharia de Release, após o qual somente o Security Officer pode efetuar commits para o branch `releng/` para um Aviso de Segurança ou Aviso de Errata. ==== Todas as mesclagens são mescladas e enviadas por commit a partir da raiz da branch. Todas as mesclagens se parecem com: [source,shell] .... svn merge -cr123456 ^/head/checkout svn commit checkout .... Observe que _checkout_ deve ser uma verificação completa da branch na qual a mesclagem ocorre. [source,shell] .... svn merge -c r123456 ^/stable/10 releng/10.0 .... ===== Preparando o Alvo de Mesclagem (Merge Target) Devido aos problemas de propagação do mergeinfo descritos anteriormente, é muito importante nunca mesclar as alterações em uma cópia de trabalho esparsa. Sempre use um checkout completo do branch que está sendo mesclado. Por exemplo, ao mesclar de HEAD para 7, use um checkout completo de stable/7: [source,shell] .... % cd stable/7 % svn up --set-depth=infinity .... O diretório de destino também deve estar atualizado e não deve conter alterações que ainda não foram enviadas por commit ou arquivos perdidos. ===== Identificando Revisões Identificar revisões a serem mescladas é uma obrigação. Se o alvo já tiver mergeinfo completo, solicite uma lista para o `SVN`: [source,shell] .... % cd stable/6/contrib/openpam % svn mergeinfo --show-revs=eligible $FSVN/head/contrib/openpam .... Se o destino não tiver mergeinfo completo, verifique o log da origem de mesclagem. ===== Mesclando Agora vamos começar a mesclar! ====== Os princípios Por exemplo, para mesclar: * revisão `$R` * no diretório $target na branch stable $B * a partir do diretório $source no head * $FSVN é o `svn+ssh://repo.freebsd.org/base` Supondo que as revisões $P e $Q já tenham sido mescladas e que o diretório atual seja uma cópia de trabalho atualizada de stable/$B, a mergeinfo existente será semelhante a: [source,shell] .... % svn propget svn:mergeinfo -R $target $target - /head/$source:$P,$Q .... A mesclagem é feita assim: [source,shell] .... % svn merge -c$R $FSVN/head/$source $target .... É possível verificar os resultados disso com um `svn diff`. O svn:mergeinfo agora se parece com: [source,shell] .... % svn propget svn:mergeinfo -R $target $target - head/$source:$P,$Q,$R .... Se os resultados não forem exatamente como os mostrados, você pode precisar de assistência antes de efetuar o commit pois erros podem ter sido cometidos, ou pode haver algo errado com o mergeinfo existente, ou pode haver um bug no Subversion. ====== Exemplo Prático Como um exemplo prático, considere este cenário. As alterações no [.filename]#netmap.4# no r238987 devem ser mescladas do CURRENT para o 9-STABLE. O arquivo reside em [.filename]#head/shared/man/man4#. De acordo com o <>, também é onde devemos fazer a mesclagem. Note que neste exemplo todos os caminhos são relativos ao topo do repositório svn. Para obter mais informações sobre o layout do diretório, consulte <>. O primeiro passo é inspecionar o mergeinfo existente. [source,shell] .... % svn propget svn:mergeinfo -R stable/9/shared/man/man4 .... Tome uma nota rápida de como ele se parece antes de avançar para o próximo passo; fazendo a mesclagem real: [source,shell] .... % svn merge -c r238987 svn+ssh://repo.freebsd.org/base/head/shared/man/man4 stable/9/shared/man/man4 --- Merging r238987 into 'stable/9/shared/man/man4': U stable/9/shared/man/man4/netmap.4 --- Recording mergeinfo for merge of r238987 into 'stable/9/shared/man/man4': U stable/9/shared/man/man4 .... Verifique se o número de revisão da revisão mesclada foi adicionado. Quando isso for verificado, a única coisa que resta é o commit em si. [source,shell] .... % svn commit stable/9/shared/man/man4 .... ===== Precauções antes de efetuar o commit Como sempre, faça um build world (ou as partes apropriadas dele). Verifique as mudanças com o `svn diff` e `svn stat`. Certifique-se de que todos os arquivos que deveriam ter sido adicionados ou excluídos foram de fato adicionados ou excluídos. Dê uma olhada mais de perto em qualquer mudança de propriedade (marcada por um `M` na segunda coluna do `svn stat`). Normalmente, nenhuma propriedade svn:mergeinfo deve estar em qualquer lugar, exceto o diretório (ou diretórios) de destino. Se algo parecer suspeito, peça ajuda. ===== Fazendo o commit Certifique-se de efetuar o commit de um diretório de nível superior para incluir também o mergeinfo. Não especifique arquivos individuais na linha de comando. Para mais informações sobre como submeter arquivos em geral, veja a seção relevante deste manual. [[svn-advanced-use-vendor-imports]] ==== Importações de fornecedores com `SVN` [IMPORTANT] ==== Por favor, leia toda esta seção antes de iniciar uma importação de fornecedores. ==== [NOTE] ==== Os patches para o código do fornecedor se enquadram em duas categorias: * Patches do fornecedor: são patches que foram emitidos pelo fornecedor ou que foram extraídos do sistema de controle de versão do fornecedor, que abordam problemas que não podem esperar até a próxima versão do fornecedor. * Patches do FreeBSD: são patches que modificam o código do fornecedor para resolver problemas específicos do FreeBSD. A natureza de um patch determina para onde ele deve ser enviado por commit: * Os patches do fornecedor devem ser enviados por commit para o branch do fornecedor e mesclados a partir dele. Se o patch resolver um problema em uma nova versão que está sendo importada atualmente, ele _não deve_ ser enviado por commit junto com a nova versão: a versão deve ser importada e marcada primeiro, então a correção pode ser aplicada e o commit efetuado. Não há necessidade de marcar novamente as fontes do fornecedor depois de confirmar o patch. * Patches do FreeBSD são enviados diretamente para o head. ==== ===== Preparando a Árvore Se estiver importando pela primeira vez após a mudança para o Subversion, é necessário achatar e limpar a árvore do fornecedor, bem como inicializar o histórico de mesclagem na árvore principal. ====== Achatamento Durante a conversão do `CVS` para o Subversion, as branches do fornecedor foram importadas com o mesmo layout da árvore principal. Isso significa que as fontes do fornecedor `pf` foram armazenadas originalmente em [.filename]#vendor/pf/dist/contrib/pf#. O código fonte do fornecedor fica melhor se armazenado diretamente em [.filename]#vendor/pf/dist#. Para achatar a árvore do `pf`: [source,shell] .... % cd vendor/pf/dist/contrib/pf % svn mv $(svn list) ../.. % cd ../.. % svn rm contrib % svn propdel -R svn:mergeinfo . % svn commit .... O bit `propdel` é necessário porque, começando com 1.5, o Subversion adicionará `svn:mergeinfo` em qualquer diretório que seja copiado ou movido. Nesse caso, como nada está sendo mesclado da árvore excluída, eles apenas atrapalham. As tags também podem ser achatadas (3, 4, 3.5 etc.); o procedimento é exatamente o mesmo, mudando apenas `dist` para `3.5` ou similar, e aguardando para executar o `svn commit` apenas no final do processo. ====== Limpando A árvore `dist` pode ser limpa conforme necessário. A desativação da expansão de palavras-chave é recomendada, pois não faz sentido no código do fornecedor não modificado e, em alguns casos, pode até mesmo ser prejudicial. O OpenSSH, por exemplo, inclui dois arquivos que se originaram do FreeBSD e ainda contêm as tags da versão original. Para fazer isso: [source,shell] .... % svn propdel svn:keywords -R . % svn commit .... ====== Bootstrapping o historico de mesclagem Se estiver importando pela primeira vez após a mudança para o Subversion, faça o bootstrap do `svn:mergeinfo` no diretório de destino da árvore principal para a revisão que corresponde à última alteração relacionada à árvore do fornecedor, antes de importar novos fontes: [source,shell] .... % cd head/contrib/pf % svn merge --record-only svn+ssh://repo.freebsd.org/base/vendor/pf/dist@180876 . % svn commit .... ===== Importando Novas Fontes Com dois commits - um para a importação em si e outro para a tag - essa etapa pode ser opcionalmente repetida para cada release upstream entre a última importação e a importação atual. ====== Preparando os fontes do fornecedor O Subversion é capaz de armazenar uma distribuição completa na árvore do fornecedor. Portanto, importe tudo, mas mescle apenas o que é necessário. Um `svn add` é necessário para adicionar quaisquer arquivos que foram adicionados desde a última importação do fornecedor, e o `svn rm` é necessário para remover todos os que foram removidos desde então. Recomenda-se a preparação de listas ordenadas do conteúdo da árvore do fornecedor e das fontes que serão importadas, para facilitar o processo. [source,shell] .... % cd vendor/pf/dist % svn list -R | grep -v '/$' | sort >../old % cd ../pf-4.3 % find . -type f | cut -c 3- | sort >../new .... Com esses dois arquivos, o `comm -23 ../old ../new` listará os arquivos removidos (arquivos somente em [.filename]#old#), enquanto `comm -13 .. /old ../new` listará os arquivos adicionados somente no [.filename]#new#. ====== Importando para a Árvore do Fornecedor Agora, os fontes devem ser copiados para [.filename]#dist# e os comandos `svn add` e `svn rm` são usados conforme necessário: [source,shell] .... % cd vendor/pf/pf-4.3 % tar cf - . | tar xf - -C ../dist % cd ../dist % comm -23 ../old ../new | xargs svn rm % comm -13 ../old ../new | xargs svn add --parents .... Se algum diretório foi removido, ele terá que ser removido manualmente com o `svn rm`. Nada vai quebrar se eles não forem, mas eles permanecerão na árvore. Verifique as propriedades em qualquer novo arquivo. Todos os arquivos de texto devem ter o `svn:eol-style` definido como `native`. Todos os arquivos binários devem ter o `svn:mime-type` configurado para `application/octet-stream`, a menos que haja um tipo de mídia mais apropriado. Arquivos executáveis devem ter `svn:executable` definido como `*`. Nenhuma outra propriedade deve existir em qualquer arquivo da árvore. Agora é possível fazer o commit. No entanto, é uma boa prática certificar-se de que tudo está correto, usando os comandos `svn stat` e `svn diff`. ====== Marcação (Tagging) Depois de realizado o commit, as versões do fornecedor são marcadas para referência futura. A melhor e mais rápida maneira de fazer isso é diretamente no repositório: [source,shell] .... % svn cp svn+ssh://repo.freebsd.org/base/vendor/pf/dist svn+ssh://repo.freebsd.org/base/vendor/pf/4.3 .... Quando isso estiver concluído, execute o `svn up` para a cópia de trabalho do [.filename]#vendor/pf# para obter a nova tag, embora isso raramente seja necessário. Se você criar a tag na cópia de trabalho da árvore, os resultados do `svn:mergeinfo` deverão ser removidos: [source,shell] .... % cd vendor/pf % svn cp dist 4.3 % svn propdel svn:mergeinfo -R 4.3 .... ===== Mesclagem para o Head [source,shell] .... % cd head/contrib/pf % svn up % svn merge --accept=postpone svn+ssh://repo.freebsd.org/base/vendor/pf/dist . .... O `--accept=postpone` diz ao Subversion para não reclamar sobre conflitos de mesclagem, pois eles serão manipulados manualmente. [TIP] ==== A mudança do `cvs2svn` ocorreu em 3 de junho de 2008. Ao realizar mesclagens de fornecedores para pacotes que já estavam presentes e convertidos pelo processo `cvs2svn`, o comando usado para mesclar [.filename]#/vendor/package_name/dist# para [.filename]#/head/package_location# (por exemplo, [.filename]#head/contrib/sendmail#) deve usar `-c _REV_` para indicar a revisão a ser mesclada a partir da árvore [.filename]#/vendor#. Por exemplo: [source,shell] .... % svn checkout svn+ssh://repo.freebsd.org/base/head/contrib/sendmail % cd sendmail % svn merge -c r261190 '^/vendor/sendmail/dist' . .... `^` é um alias para o caminho do repositório. ==== [NOTE] ==== Se estiver usando o shell Zsh, o `^` deve ser escapado com `\` ou entre aspas. ==== É necessário resolver quaisquer conflitos de mesclagem. Certifique-se de que todos os arquivos adicionados ou removidos na árvore do fornecedor tenham sido adicionados ou removidos corretamente na árvore principal. Para verificar os diffs com relação ao branch do fornecedor: [source,shell] .... % svn diff --no-diff-deleted --old=svn+ssh://repo.freebsd.org/base/vendor/pf/dist --new=. .... O `--no-diff-deleted` diz ao Subversion para não reclamar sobre os arquivos que estão na árvore do fornecedor, mas que não estão na árvore principal. Coisas que teriam sido removidas antes da importação do fornecedor, como os makefiles do fornecedor e os scripts de configuração. Usando o `CVS`, uma vez que um arquivo estava fora do branch do fornecedor, ele não podia ser colocado de volta. Com o Subversion, não há nenhum conceito dentro ou fora do branch do fornecedor. Se um arquivo que anteriormente tinha modificações locais, para fazer com que ele não apareça em diffs na árvore do fornecedor, tudo o que tem que ser feito é remover qualquer sobra como as tags de versões do FreeBSD, o que é muito mais fácil. Se alguma mudança for necessária para o "world" compilar com os novos fontes, faça-as agora e continue testando até que tudo seja compilado e executado perfeitamente. ===== Fazendo o commit da Importação de Fornecedores Agora é possível fazer o commit! O commit deve ser feito de tudo de uma só vez. Se feito corretamente, a árvore passará de um estado consistente com o código antigo para um estado consistente com o novo código. ===== A partir do zero ====== Importando para a Árvore do Fornecedor Esta seção é um exemplo de importação e marcação do byacc no [.filename]#head#. Primeiro, prepare o diretório em [.filename]#vendor#: [source,shell] .... % svn co --depth immediates $FSVN/vendor % cd vendor % svn mkdir byacc % svn mkdir byacc/dist .... Agora, importe os fontes para o diretório [.filename]#dist#. Uma vez que os arquivos estiverem no lugar, faça o `svn add` dos novos, e então faça o `svn commit` e aplique a tag na versão importada. Para poupar tempo e largura de banda, é possível efetuar diretamente o commit e as marcações de forma remota: [source,shell] .... % svn cp -m "Tag byacc 20120115" $FSVN/vendor/byacc/dist $FSVN/vendor/byacc/20120115 .... ====== Mesclando para o `head` Devido a este ser um novo arquivo, copie-o para a mesclagem: [source,shell] .... % svn cp -m "Import byacc to contrib" $FSVN/vendor/byacc/dist $FSVN/head/contrib/byacc .... Ainda é possível trabalhar normalmente nos fontes recém importados. [[svn-advanced-use-reverting-a-commit]] ==== Revertendo um Commit A reversão de um commit para uma versão anterior é bem fácil: [source,shell] .... % svn merge -r179454:179453 ROADMAP.txt % svn commit .... Alterar a sintaxe do número, com o negativo significando a reversão de uma mudança, também pode ser usado: [source,shell] .... % svn merge -c -179454 ROADMAP.txt % svn commit .... Isso também pode ser feito diretamente no repositório: [source,shell] .... % svn merge -r179454:179453 svn+ssh://repo.freebsd.org/base/ROADMAP.txt .... [NOTE] ==== É importante assegurar que o mergeinfo esteja correto ao reverter um arquivo para permitir que o `svn mergeinfo --eligible` funcione como esperado. ==== A reversão da exclusão de um arquivo é um pouco diferente. É necessário copiar a versão do arquivo que antecede a exclusão. Por exemplo, para restaurar um arquivo que foi excluído na revisão N, restaure a versão N-1: [source,shell] .... % svn copy svn+ssh://repo.freebsd.org/base/ROADMAP.txt@179454 % svn commit .... ou, igualmente: [source,shell] .... % svn copy svn+ssh://repo.freebsd.org/base/ROADMAP.txt@179454 svn+ssh://repo.freebsd.org/base .... Simplesmente _não_ recrie o arquivo manualmente e o adicione com o `svn add` - isso fará com que o histórico seja perdido. [[svn-advanced-use-fixing-mistakes]] ==== Corrigindo Erros Por mais que possamos realizar uma cirurgia em uma emergência, não planeje ou corrija erros por baixo dos panos. Planos para erros permanecem nos registros para sempre. Certifique-se de verificar a saída do `svn status` e do `svn diff` antes de enviar o commit. Erros acontecerão, mas eles geralmente podem ser corrigidos sem perturbar. No caso de adicionar um arquivo no local errado. A coisa certa a fazer é usar o `svn move` e mover o arquivo para o local correto e fazer o commit. Isso altera apenas algumas linhas de metadados no journal do repositório, e os logs serão todos conectados corretamente. A coisa errada a fazer é apagar o arquivo e, em seguida, usar `svn add` para adicionar uma cópia independente no local correto. Em vez de algumas linhas de texto, o repositório journal cria uma nova cópia inteira do arquivo. Isso é um desperdício. [[svn-getting-started-checkout-from-a-mirror]] ==== Usando um Espelho do Subversion Há uma séria desvantagem neste método: toda vez que for feito o commit de algo, terá que executar um `svn relocate` no repositório master, não esquecendo de executar o `svn relocate` de volta para o mirror após o commit. Além disso, como o `svn relocate` só funciona entre os repositórios que possuem o mesmo UUID, algum hacking do UUID do repositório local deve ocorrer antes que seja possível começar a usá-lo. [[svn-advanced-checkout-from-mirror]] ===== Checkout a partir de um Mirror Faça o checkout de uma cópia de trabalho a partir de um mirror substituindo a URL do mirror por `svn+ssh://repo.freebsd.org/base`. Este pode ser um mirror oficial ou um mirror mantido usando o `svnsync`. [[svn-advanced-use-setting-up-svnsync]] ===== Configurando um Mirror svnsync Evite configurar um mirror svnsync a menos que haja uma boa razão para isso. Na maioria das vezes, um mirror `git` é uma alternativa melhor. Começar um novo mirror do zero leva muito tempo. Espere um mínimo de 10 horas para conectividade de alta velocidade. Se o trafego for passar por links internacionais, espere que isso leve de quatro a dez vezes mais. -Uma maneira de limitar o tempo necessário é pegar um arquivo de https://download.freebsd.org/ftp/development/subversion/[seed]. Ele é grande (~1GB), mas consome menos tráfego de rede e leva menos tempo para baixar do que o svnsync. +Uma maneira de limitar o tempo necessário é pegar um arquivo de https://download.freebsd.org/development/subversion/[seed]. Ele é grande (~1GB), mas consome menos tráfego de rede e leva menos tempo para baixar do que o svnsync. Extraia o arquivo e o atualize: [source,shell] .... % tar xf svnmirror-base-r261170.tar.xz % svnsync sync file:///home/svnmirror/base .... Agora, configure isso para executar a partir do man:cron[8], faça checkouts localmente, configure um servidor svnserve para as máquinas locais com as quais conversar, etc. O mirror seed está definido para buscar o conteúdo a partir de `svn://svn.freebsd.org/base`. A configuração para o mirror é armazenada em `revprop 0` no mirror local. Para ver a configuração, tente: [source,shell] .... % svn proplist -v --revprop -r 0 file:///home/svnmirror/base .... Use `svn propset` para mudar as coisas. [[svn-advanced-use-committing-high-ascii-data]] ==== Fazendo commit de dados High ASCII Os arquivos que possuem bits high-ASCII são considerados arquivos binários no `SVN`, portanto, as verificações de pré-commit falham e indicam que a propriedade `mime-type` deve ser definida como `application/octet-stream`. No entanto, o uso deste é desencorajado, por isso, não o defina. A melhor maneira é sempre evitar dados high-ASCII, para que possam ser lidos em qualquer lugar com qualquer editor de texto, mas se não for possivel evitar, em vez de alterar o mime-type, defina a propriedade `fbsd:notbinary` com o `propset`: [source,shell] .... % svn propset fbsd:notbinary yes foo.data .... [[svn-advanced-use-maintaining-a-project-branch]] ==== Mantendo um branch de projeto Uma branch de projeto é aquela que está sincronizada com o head (ou outra branch) e é usada para desenvolver um projeto e, em seguida, fazer o seu commit de volta para o head. No `SVN`, o branch "dolphin" é usado para isso. Uma branch "dolphin" é aquela que diverge por um tempo e é finalmente enviada de volta ao branch original. Durante a migração do código de desenvolvimento em uma direção (do head para o branch apenas). Não é feito o commit de nenhum código de volta ao head até o final. Depois que é feito o commit da branch no final, ela estará morta (embora uma nova branch com o mesmo nome possa ser criada depois que a que está morta é excluída). Como explicado em https://people.FreeBSD.org/\~peter/svn_notes.txt[https://people.FreeBSD.org/~peter/svn_notes.txt], o trabalho que destina-se a ser mesclado de volta para o HEAD deve estar em [.filename]#base/projects/#. Se o trabalho é benéfico para a comunidade do FreeBSD de alguma forma, mas não se destina a ser mesclado diretamente no HEAD, então o local apropriado é [.filename]#base/user/username/#. https://svnweb.freebsd.org/base/projects/GUIDELINES.txt[Esta página] contém mais detalhes. Para criar um branch de projeto: [source,shell] .... % svn copy svn+ssh://repo.freebsd.org/base/head svn+ssh://repo.freebsd.org/base/projects/spif .... Para mesclar as alterações do HEAD de volta ao branch de projeto: [source,shell] .... % cd copy_of_spif % svn merge svn+ssh://repo.freebsd.org/base/head % svn commit .... É importante resolver quaisquer conflitos de mesclagem antes de fazer o commit. === Algumas dicas Nos logs de commit, etc., "rev 179872" é soletrado "r179872" conforme a convenção. É possível acelerar o svn adicionando estas entradas ao [.filename]#~/.ssh/config#: [source,shell] .... Host * ControlPath ~/.ssh/sockets/master-l-r@h:p ControlMaster auto ControlPersist yes .... e depois digitando [source,shell] .... mkdir ~/.ssh/sockets .... Fazer o check-out de uma cópia de trabalho com um cliente Subversion padrão sem patches específicos do FreeBSD (`OPTIONS_SET=FREEBSD_TEMPLATE`) significará que as tags `$FreeBSD: head/pt_BR.ISO8859-1/articles/committers-guide/article.xml 53731 2020-01-01 14:37:53Z ebrandi $` não serão expandidas. Uma vez que a versão correta foi instalada, engane o Subversion para expandi-las da seguinte forma: [source,shell] .... % svn propdel -R svn:keywords . % svn revert -R . .... Isso eliminará os patches para os quais ainda não foi feito o commit. É possível preencher automaticamente os campos de log de commit "Sponsored by" e "MFC after" configurando os campos "freebsd-sponsored-by" e "freebsd-mfc-after" na seção "[miscellany]" do arquivo de configuração [.filename]#~/.subversion/config#. Por exemplo: [.programlisting] .... freebsd-sponsored-by = The FreeBSD Foundation freebsd-mfc-after = 2 weeks .... [[conventions]] == Configuração, Convenções e Tradições Existe uma série de coisas para fazer como um novo desenvolvedor. O primeiro conjunto de etapas é específico apenas para os committers. Essas etapas devem ser feitas por um mentor para aqueles que não são committers. [[conventions-committers]] === Para novos committers Aqueles que receberam direitos de commit para os repositórios do FreeBSD devem seguir estes passos. * Obtenha a aprovação do seu mentor antes de fazer o commit de cada uma dessas mudanças! * Os arquivos [.filename]#.ent# e [.filename]#.xml# mencionados abaixo existem no repositório SVN do Projeto de Documentation do FreeBSD em `svn+ssh://repo.FreeBSD.org/doc/`. * Novos arquivos que não possuem a propriedade `FreeBSD=%H svn:keywords` serão rejeitados quando você tentar fazer o commit dos mesmos para o repositório. Certifique-se de ler <> sobre como adicionar e remover arquivos. Verifique se o [.filename]#~/.subversion/config# contém as entradas necessárias de "auto-props" do [.filename]#auto-props.txt# mencionado lá. * Todos os commits do [.filename]#src# vão para o FreeBSD-CURRENT antes de serem mesclados para o FreeBSD-STABLE. A branch do FreeBSD-STABLE deve manter a compatibilidade de ABI e de API com as versões anteriores dessa branch. Não mescle as alterações que quebram essa compatibilidade. [[commit-steps]] [.procedure] .Procedure: Etapas para os novos committers . Adicione uma entidade de autor + [.filename]#doc/head/shared/xml/authors.ent# - Adicione uma entidade de autor. Etapas posteriores dependem dessa entidade, e a falta dessa etapa fará com que a compilação do [.filename]#doc/# falhe. Essa é uma tarefa relativamente fácil, mas continua sendo um bom primeiro teste de habilidades no controle de versão. . Atualize a lista de desenvolvedores e colaboradores + [.filename]#doc/head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml# - Adicione uma entrada à seção "Desenvolvedores" da extref:{contributors}[Lista de Contribuidores, staff-committers]. As entradas são classificadas pelo sobrenome. + [.filename]#doc/head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml# - _Remova_ a entrada da seção "Contribuidores Adicionais". As entradas são classificadas pelo primeiro nome. . Adicione um item de notícias + [.filename]#doc/head/shared/xml/news.xml# - Adicione uma entrada. Procure por outras entradas que anunciam novos committers e siga o formato. Use a data do email de aprovação do mailto:core@FreeBSD.org[core@FreeBSD.org] para o commit bit. . Adicione uma chave PGP + [.filename]#doc/head/shared/pgpkeys/pgpkeys.ent# e [.filename]#doc/head/shared/pgpkeys/pgpkeys-developers.xml# - Adicione a sua chave PGP ou GnuPG. Aqueles que ainda não têm uma chave devem ver <>. + O Dag-Erling Smørgrav mailto:des@FreeBSD.org[des@FreeBSD.org] escreveu um script de shell ([.filename]#doc/head/shared/pgpkeys/addkey.sh#) para tornar isto mais fácil. Consulte o arquivo http://svnweb.FreeBSD.org/doc/head/shared/pgpkeys/README[README] para obter mais informações. + Use o [.filename]#doc/head/shared/pgpkeys/checkkey.sh# para verificar se as chaves atendem aos padrões mínimos das boas práticas recomendadas. + Depois de adicionar e verificar uma chave, adicione os dois arquivos atualizados ao controle de versão do código fonte, e em seguida faça o commit. As entradas neste arquivo são classificadas pelo sobrenome. + [NOTE] ==== É muito importante ter uma chave PGP/GnuPG atualizada no repositório. A chave pode ser necessária para a identificação positiva de um committer. Por exemplo, os Administradores do FreeBSD mailto:admins@FreeBSD.org[admins@FreeBSD.org]podem precisar dela para a recuperação da conta. Um chaveiro completo dos usuários do `FreeBSD.org` está disponível para download em https://www.FreeBSD.org/doc/pgpkeyring.txt[https://www.FreeBSD.org/doc/pgpkeyring.txt]. ==== . Atualize as informações do Mentor e do Mentee + [.filename]#base/head/shared/misc/committers-repository.dot# - Adicione uma entrada à seção committers atuais, onde _repository_ é `doc`, `ports`, ou `src`, dependendo dos privilégios de commit concedidos. + Adicione uma entrada para cada relacionamento adicional de mentor/mentee na seção inferior. . Gere uma senha do Kerberos + Veja <> para gerar ou definir um Kerberos para uso com outros serviços do FreeBSD, como o banco de dados de rastreamento de bugs. . Opcional: Ative a sua conta na Wiki + https://wiki.freebsd.org[Conta no Wiki do FreeBSD] - Uma conta no wiki permite que compartilhe projetos e ideias. Aqueles que ainda não têm uma conta podem seguir as instruções da https://wiki.freebsd.org/AboutWiki[Página Sobre a Wiki] para obter uma. Entre em contato com mailto:wikiadmin@FreeBSD.org[wikiadmin@FreeBSD.org] se precisar de ajuda com sua conta no Wiki. . Opcional: Atualize informações do Wiki + Informações do Wiki - Depois de obter acesso ao wiki, algumas pessoas adicionam entradas nas páginas https://wiki.freebsd.org/HowWeGotHere[How We Got Here], https://wiki.freebsd.org/IRC/Nicknames[IRC Nicks] e https://wiki.freebsd.org/Community/Dogs[Dogs of FreeBSD] páginas. . Opcional: Atualize o Ports com as suas Informações Pessoais + [.filename]#ports/astro/xearth/files/freebsd.committers.markers# e [.filename]#src/usr.bin/calendar/calendars/calendar.freebsd# - Algumas pessoas adicionam entradas para elas nestes arquivos para mostrar onde estão localizadas ou a data de seu aniversário. . Opcional: Evite Correspondências Duplicadas + Assinantes das listas http://lists.FreeBSD.org/mailman/listinfo/svn-src-all[svn-src-all], http://lists.FreeBSD.org/mailman/listinfo/svn-ports-all[svn-ports-all] ou da http://lists.FreeBSD.org/mailman/listinfo/svn-doc-all[svn-doc-all] podem desejar cancelar a assinatura para evitar receber cópias duplicadas de mensagens de commit e de followups. [[conventions-everyone]] === Para todos [[conventions-everyone-steps]] [.procedure] . Apresente-se aos outros desenvolvedores, caso contrário, ninguém fará a menor ideia de quem você é ou no que você está trabalhando. A introdução não precisa ser uma biografia abrangente, basta escrever um parágrafo ou dois sobre quem você é, em que você planeja trabalhar como desenvolvedor no FreeBSD e quem será seu mentor. Envie os parágrafos por e-mail para a lista de discussão dos desenvolvedores do FreeBSD e você estará a caminho! . Entre na `freefall.FreeBSD.org` e crie um arquivo [.filename]#/var/forward/user# (no qual _user_ é seu nome de usuário) contendo o endereço de e-mail para o qual você deseja que o correio endereçado para _yourusername_@FreeBSD.org seja encaminhado. Isto inclui todas as mensagens de commit assim como qualquer outro email endereçado à lista de discussão dos committers do FreeBSD e à lista de discussão dos desenvolvedores do FreeBSD. Caixas de correio realmente grandes que tenham residência permanente na `freefall` podem ser truncadas sem aviso se o espaço precisar ser liberado, então encaminhe suas mensagens ou salve-as em outro lugar. + [NOTE] ==== Se o seu sistema de e-mail usa SPF com regras estritas, você deve colocar o host `mx2.FreeBSD.org` na whitelist de verificações do SPF. ==== + Devido ao load severo imposto aos servidores centrais que fazem o processamento da lista de discussão devido ao grande volume de SPAMs, o servidor de front-end faz algumas verificações básicas e descarta algumas mensagens com base nessas verificações. No momento, as informações de DNS adequadas para o host de conexão são a única verificação ativa, mas isso pode mudar. Algumas pessoas culpam estas verificações por rejeitar e-mails válidos. Para que essas verificações sejam desativadas no seu email, crie um arquivo chamado [.filename]#~/.spam_lover# no servidor `freefall.FreeBSD.org`. [NOTE] ==== Aqueles que são desenvolvedores, mas não são committers, não serão inscritos nas listas de discussão de desenvolvedores ou de committers. As assinaturas são derivadas dos direitos de acesso. ==== [[smtp-setup]] ==== Configuração de acesso SMTP Para aqueles dispostos a enviar mensagens de e-mail através da infraestrutura do FreeBSD.org, siga as instruções abaixo: [.procedure] . Aponte seu cliente de e-mail para `smtp.FreeBSD.org:587`. . Habilite o STARTTLS. . Assegure-se de que seu endereço `From:` esteja configurado para `_yourusername_@FreeBSD.org`. . Para autenticação, você pode usar o seu nome de usuário e a sua senha do Kerberos no cluster do FreeBSD (veja <>). O principal `_yourusername_/mail` é o preferido, pois é válido apenas para autenticação dos recursos de correio. + [NOTE] ==== Não inclua `@FreeBSD.org` ao digitar seu nome de usuário. ==== .Notas Adicionais [NOTE] ==== * Aceitará apenas mensagens de `_yourusername_@FreeBSD.org`. Se você for autenticado como um usuário, não terá permissão para enviar e-mails como outro. * Um cabeçalho será anexado com o nome de usuário do SASL: (`Authenticated sender: _username_`). * O host possui vários limites de taxa para reduzir as tentativas de força bruta. ==== [[smtp-setup-local-mta]] ===== Usando um MTA Local para Encaminhar Emails para o Serviço SMTP do FreeBSD.org Também é possível usar um MTA local para encaminhar emails enviados localmente para os servidores SMTP do FreeBSD.org. [[smtp-setup-local-postfix]] .Usando o Postfix [example] ==== Para dizer a uma instância local do Postfix que qualquer email de `_yourusername_@FreeBSD.org` deve ser encaminhado para os servidores do FreeBSD.org, adicione isto ao seu [.filename]#main.cf#: [.programlisting] .... sender_dependent_relayhost_maps = hash:/usr/local/etc/postfix/relayhost_maps smtp_sasl_auth_enable = yes smtp_sasl_security_options = noanonymous smtp_sasl_password_maps = hash:/usr/local/etc/postfix/sasl_passwd smtp_use_tls = yes .... Crie [.filename]#/usr/local/etc/postfix/relayhost_maps# com o seguinte conteúdo: [.programlisting] .... yourusername@FreeBSD.org [smtp.freebsd.org]:587 .... Crie [.filename]#/usr/local/etc/postfix/sasl_passwd# com o seguinte conteúdo: [.programlisting] .... [smtp.freebsd.org]:587 yourusername:yourpassword .... Se o servidor de email for usado por outras pessoas, talvez você queira impedir que elas enviem emails do seu endereço. Para configurar isso, adicione estas entradas ao seu [.filename]#main.cf#: [.programlisting] .... smtpd_sender_login_maps = hash:/usr/local/etc/postfix/sender_login_maps smtpd_sender_restrictions = reject_known_sender_login_mismatch .... Crie [.filename]#/usr/local/etc/postfix/sender_login_maps# com o seguinte conteúdo: [.programlisting] .... yourusername@FreeBSD.org yourlocalusername .... Onde _yourlocalusername_ é o usuário SASL utilizado para conectar na instância local do Postfix. ==== [[mentors]] === Mentores Todos os novos desenvolvedores têm um mentor atribuído a eles nos primeiros meses. Um mentor é responsável por ensinar ao aprendiz as regras e convenções do projeto e orientar seus primeiros passos na comunidade de desenvolvedores. O mentor também é pessoalmente responsável pelas ações do aprendiz durante este período inicial. Para committers: não faça nenhum commit sem antes obter a aprovação do seu mentor. Documente essa aprovação com uma linha `Approved by:` na mensagem de commit. Quando o mentor decide que um aprendiz já aprendeu o necessário e está pronto para fazer commits por conta própria, o mentor anuncia o fato com um commit no [.filename]#conf/mentors#. Este arquivo está na branch [.filename]#svnadmin# de cada repositório: [.informaltable] [cols="1,1", frame="none"] |=== |`src` |[.filename]#base/svnadmin/conf/mentors# |`doc` |[.filename]#doc/svnadmin/conf/mentors# |`ports` |[.filename]#ports/svnadmin/conf/mentors# |=== [NOTE] ==== Os novos committers devem ter como objetivo realizar commits o suficiente para que seu mentor se sinta confortável em liberá-los da mentoria no primeiro ano. Se eles ainda estiverem sob orientação, o corpo gerencial apropriado (core, doceng ou portmgr) deve tentar garantir que não haja barreiras que impeçam a conclusão. Se o committer não for capaz de satisfazer seu mentor de prontidão por um ano e meio, seu commit bit pode ser convertido para membro do projeto. ==== [[pre-commit-review]] == Revisão pré-commit A revisão de código é uma maneira de aumentar a qualidade do software. As seguintes diretrizes se aplicam a commits na ramificação `head` (-CURRENT) do repositório `src`. Outras ramificações e as árvores do `ports` e do `docs` têm suas próprias políticas de revisão, mas essas diretrizes geralmente se aplicam a commits que exigem revisão: * Todas as alterações não triviais devem ser revisadas antes de serem cometidas no repositório. * As revisões podem ser conduzidas por e-mail, pelo Bugzilla, pelo Phabricator ou por outro mecanismo. Sempre que possível, as revisões devem ser públicas. * O desenvolvedor responsável por uma mudança de código também é responsável por fazer todas as alterações necessárias relacionadas à revisão. * A revisão de código pode ser um processo iterativo, que continua até que o patch esteja pronto para o commit. Especificamente, uma vez que um patch é enviado para revisão, ele deve receber um explícito "looks good" antes que o commit possa ser feito. Desde que a aprovação seja explícita, ela pode ser formalizada de qualquer forma que faça sentido para o método de revisão. * Timeouts não são um substituto para revisão. Às vezes, as revisões de código demoram mais tempo do que você esperaria, especialmente para recursos maiores. As formas aceitas de acelerar os tempos de revisão dos seus patches são: * Revise os patches de outras pessoas. Se você ajudar, todos estarão mais dispostos a fazer o mesmo por você; A boa vontade é a nossa moeda. * Ping o patch. Se for urgente, forneça as razões pelas quais é importante para você finalizá-lo e faça o ping a cada dois dias. Se não for urgente, a frequência adequada de ping é de uma vez por semana. Lembre-se de que você está pedindo um tempo valioso de outros desenvolvedores profissionais. * Peça ajuda em listas de discussão, IRC, etc. Outros podem ajudá-lo diretamente ou sugerir um revisor. * Dividir seu patch em vários patches pequenos os quais se aplicam uns sobre os outros. Quanto menor o seu patch, maior a probabilidade de alguém dar uma rápida olhada nele. + Ao fazer grandes mudanças, é útil ter isso em mente desde o início do esforço, pois quebrar grandes alterações em pequenas é geralmente difícil depois que estão prontas. Os desenvolvedores devem participar de revisões de código fazendo revisões e recebendo revisões. Se alguém tiver a gentileza de revisar seu código, você deve devolver o favor a outra pessoa. Observe que, embora qualquer pessoa seja bem-vinda para revisar e dar feedback sobre um patch, apenas um especialista no assunto apropriado pode aprovar uma alteração. Geralmente, este especialista será um committer que trabalha com o código em questão regularmente. Em alguns casos, nenhum especialista no assunto pode estar disponível. Nesses casos, uma revisão por um desenvolvedor experiente é suficiente quando associada a testes apropriados. [[commit-log-message]] == Mensagens de Log de Commit Esta seção contém algumas sugestões e tradições de como os logs de commit são formatados. Além de incluir uma mensagem informativa com cada commit, algumas informações adicionais podem ser necessárias. Essas informações consistem em uma ou mais linhas contendo a palavra-chave ou frase, dois-pontos, guias para formatação e, em seguida, as informações adicionais. As palavras ou frases-chave são: [.informaltable] [cols="20%,80%", frame="none"] |=== |`PR:` |O relatório do problema (se houver) que é afetado (normalmente, por estar fechado) por este commit. Vários PRs podem ser especificados em uma linha, separados por vírgulas ou espaços. |`Submitted by:` | O nome e o endereço de e-mail da pessoa que enviou a correção; para desenvolvedores, apenas o nome de usuário no cluster do FreeBSD. Se o requisitante for o mantenedor do port que está sendo atualizado pelo commit, inclua "(maintainer)" após o endereço de e-mail. Evite ofuscar o endereço de e-mail do remetente, pois isso adiciona trabalho adicional ao pesquisar os registros. |`Reviewed by:` |O nome e o endereço de e-mail da pessoa ou pessoas que revisaram a alteração; para desenvolvedores, apenas o nome de usuário no cluster do FreeBSD. Se um patch foi submetido a uma lista de discussão para revisão e a revisão foi favorável, basta incluir o nome da lista. |`Approved by:` a| O nome e endereço de e-mail da pessoa ou pessoas que aprovaram a alteração; para desenvolvedores, apenas o nome de usuário no cluster do FreeBSD. É costume obter aprovação prévia para um commit se for para uma área da árvore na qual você normalmente não faz commit. Além disso, durante a preparação para uma nova versão, todos os commits _devem_ ser aprovados pela equipe de engenharia de release. Enquanto estiver sob orientação, obtenha aprovação do mentor antes do commit. Digite o nome de usuário do mentor neste campo e adicione uma nota de que ele é um mentor: [source,shell] .... Approved by: username-of-mentor (mentor) .... Se uma equipe aprovou esses commits, inclua o nome da equipe seguido do nome de usuário do aprovador entre parênteses. Por exemplo: [source,shell] .... Approved by: re (username) .... |`Obtained from:` |O nome do projeto (se houver) do qual o código foi obtido. Não use esta linha para o nome de uma pessoa individual. |`Sponsored by:` |Organizações patrocinadoras dessa mudança, se houver. Separe várias organizações com vírgulas. Se apenas uma parte do trabalho foi patrocinada, ou diferentes montantes de patrocínio foram fornecidos a diferentes autores, por favor, forneça os devidos créditos entre parênteses após cada nome de patrocinador. Por exemplo, `Example.com (alice, refatoração de código), Wormulon (bob), Momcorp (cindy)` mostra que Alice foi patrocinada pela Example.com para refatoração de código, enquanto Wormulon patrocinou o trabalho de Bob e a Momcorp patrocinou o trabalho de Cindy. Outros autores não foram patrocinados ou optaram por não listar o patrocínio. |`MFC after:` |Para receber um lembrete por e-mail para o MFC em uma data posterior, especifique o número de dias, semanas ou meses após os quais um MFC está planejado. |`MFC to:` |Se o commit deve ser mesclado em um subconjunto de branches estáveis, especifique os nomes das branchs. |`MFC with:` |Se o commit deve ser mesclado junto com um commit anterior em um único MFC (por exemplo, onde o commit corrige um bug da alteração anterior), especifique o número de revisão correspondente. |`Relnotes:` |Se a alteração for candidata a inclusão nas notas de lançamento da próxima versão da branch, defina como `yes`. |`Security:` |Se a alteração estiver relacionada a uma vulnerabilidade de segurança ou exposição de segurança, inclua uma ou mais referências ou uma descrição do problema. Se possível, inclua um URL VuXML ou um ID CVE. |`Evento:` |Descrição para o evento em que essa confirmação foi feita. Se este for um evento recorrente, adicione o ano ou até mesmo o mês. Por exemplo, isso pode ser `FooBSDcon 2019`. A idéia por trás dessa linha é dar reconhecimento a conferências, reuniões e outros tipos de reuniões e mostrar que elas são úteis. Por favor, não use a linha `Patrocinado por:` para isso, pois isso significa que as organizações patrocinam determinados recursos ou desenvolvedores que trabalham neles. |`Differential Revision:` |A URL completa da revisão do Phabricator. Esta linha __ deve ser a última linha __. Por exemplo: `https://reviews.freebsd.org/D1708`. |=== .Commit Log para um commit baseado em um PR [example] ==== O commit é baseado em um patch de um PR enviado por John Smith. Os campos da mensagem de commit "PR" e "Submitted by" são preenchidos. [.programlisting] .... ... PR: 12345 Submitted by: John Smith .... ==== .Commit log de um commit que precisa de revisão [example] ==== O sistema de memória virtual está sendo alterado. Depois de enviar os patches para a lista de discussão apropriada (neste caso, `freebsd-arch`) e as mudanças foram aprovadas. [.programlisting] .... ... Reviewed by: -arch .... ==== .Commit log de um commit que precisa de aprovação [example] ==== Commit um port, depois de trabalhar com o MAINTAINER, que disse para ir em frente e executar o commit. [.programlisting] .... ... Approved by: abc (maintainer) .... No qual o _abc_ é o nome da conta da pessoa que aprovou. ==== .Commit log de um commit que importa código do OpenBSD [example] ==== Efetuando o commit de códigos baseados no trabalho feito no projeto OpenBSD. [.programlisting] .... ... Obtained from: OpenBSD .... ==== .Commit Log para uma mudança no FreeBSD-CURRENT com um commit planejado para o FreeBSD-STABLE para seguir em uma data posterior. [example] ==== Efetuando o commit de códigos que serão mesclados do FreeBSD-CURRENT na branch do FreeBSD-STABLE após duas semanas. [.programlisting] .... ... MFC after: 2 weeks .... Onde _2_ é o número de dias, semanas ou meses após o qual um MFC é planejado. A opção _weeks_ pode ser `day`, `dias`, `semana`, `semanas`, `mês`, `meses`. ==== Muitas vezes é necessário combinar isso. Considere a situação em que um usuário enviou um código contendo o PR do projeto NetBSD. Olhando para o PR, o desenvolvedor vê que não é uma área da árvore na qual eles normalmente trabalham, então eles têm a mudança revisada pela lista de discussão `arch`. Como a mudança é complexa, o desenvolvedor opta pelo MFC após um mês para permitir testes adequados. A informação extra para incluir no commit seria algo como .Exemplo de log de commit combinado [example] ==== [.programlisting] .... PR: 54321 Submitted by: John Smith Reviewed by: -arch Obtained from: NetBSD MFC after: 1 month Relnotes: yes .... ==== [[pref-license]] == Licença preferida para novos arquivos A política de licença completa do Projeto FreeBSD pode ser encontrada em https://www.FreeBSD.org/internal/software-license/[https://www.FreeBSD.org/internal/software-license/]. O restante desta seção destina-se a ajudá-lo a começar. Por via de regra, quando em dúvida, pergunte. É muito mais fácil dar conselhos do que consertar a árvore de código fonte. O Projeto FreeBSD sugere e usa este texto como o esquema de licença preferencial: [.programlisting] .... /*- * SPDX-License-Identifier: BSD-2-Clause-FreeBSD * * Copyright (c) [year] [your name] * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * [id for your version control system, if any] */ .... O projeto FreeBSD desencoraja fortemente a chamada "cláusula publicitária" no novo código. Devido ao grande número de contribuidores para o projeto FreeBSD, o cumprimento desta cláusula para muitos fornecedores comerciais se tornou difícil. Se você tiver um código na árvore com a cláusula de publicidade, considere removê-lo. Na verdade, considere usar a licença acima para o seu código. O projeto FreeBSD desencoraja completamente novas licenças e variações nas licenças padrões. Novas licenças requerem a aprovação do Core Team mailto:core@FreeBSD.org[core@FreeBSD.org] para residir no repositório principal. Quanto mais licenças diferentes forem usadas na árvore, mais problemas isso causará para aqueles que desejarem utilizar esse código, geralmente de consequências não intencionais de uma licença mal formulada. A política do projeto determina que o código sob algumas licenças não-BSD deve ser colocado apenas em seções específicas do repositório e, em alguns casos, a compilação deve ser condicional ou até mesmo desativada por padrão. Por exemplo, o kernel GENERIC deve ser compilado apenas sob licenças idênticas ou substancialmente semelhantes à licença BSD. O software licenciado GPL, APSL, CDDL, etc, não deve ser compilado no GENERIC. Os desenvolvedores são lembrados de que, em código aberto, ficar "aberto" corretamente é tão importante quanto obter o "fonte" correto, já que o manuseio inadequado da propriedade intelectual tem sérias consequências. Quaisquer dúvidas ou preocupações devem imediatamente ser levadas à atenção do Core Team. [[tracking.license.grants]] == Acompanhando as Licenças Concedidas ao Projeto FreeBSD Vários softwares ou dados existem nos repositórios onde o projeto FreeBSD recebeu uma licença especial para poder usá-los. Um caso em questão são as fontes do Terminus para uso com o man:vt[4]. Aqui, o autor Dimitar Zhekov nos permitiu usar a fonte "Terminus BSD Console" sob uma licença BSD de 2 cláusulas, em vez da licença Open Font License que ele normalmente usa. É claramente sensível manter um registro de tais concessões de licença. Para esse fim, o Core Team mailto:core@FreeBSD.org[core@FreeBSD.org] decidiu manter um arquivo delas. Sempre que o projeto FreeBSD receber uma licença especial, nós exigimos que o Core Team mailto:core@FreeBSD.org[core@FreeBSD.org] seja notificado. Qualquer desenvolvedor envolvido na obtenção de tal concessão de licença, por favor envie os detalhes para o Core Team mailto:core@FreeBSD.org[core@FreeBSD.org] incluindo: * Detalhes de contato para as pessoas ou organizações que concederam a licença especial. * Quais arquivos, diretórios etc. nos repositórios são cobertos pela concessão da licença, incluindo os números de revisão dos commits nos quais qualquer material especialmente licenciado tenha sido incorporado. * A data em que a licença entra em vigor. Salvo acordo em contrário, esta será a data em que a licença foi emitida pelos autores do software em questão. * O texto da licença. * Uma nota de quaisquer restrições, limitações ou exceções que se aplicam especificamente ao uso do material licenciado pelo FreeBSD. * Qualquer outra informação relevante. Uma vez que o Core Team mailto:core@FreeBSD.org[core@FreeBSD.org] esteja satisfeito de que todos os detalhes necessários foram reunidos e estão corretos, o secretário enviará um aviso de recebimento assinado com o PGP, incluindo os detalhes da licença. Esse recibo será persistentemente arquivado e servirá como nosso registro permanente da concessão da licença. O arquivo de licença deve conter apenas detalhes das concessões de licença; este não é o lugar para qualquer discussão em torno de licenciamento ou outros assuntos. O acesso aos dados dentro do arquivo de licença estará disponível mediante solicitação para o Core Team mailto:core@FreeBSD.org[core@FreeBSD.org]. [[developer.relations]] == Relações entre os Desenvolvedores Ao trabalhar diretamente em seu próprio código ou em um código que já esteja bem estabelecido como sua responsabilidade, provavelmente haverá pouca necessidade de verificar com outros committers antes de entrar com um commit. Ao trabalhar em um bug em uma área do sistema que é claramente órfã (e existem algumas dessas áreas, para nossa vergonha), o mesmo se aplica. Ao modificar partes do sistema que são mantidas, formalmente ou informalmente, considere solicitar uma revisão exatamente como um desenvolvedor teria de fazer antes de se tornar um committer. Para os ports, entre em contato com o `MAINTAINER` listado no [.filename]#Makefile#. Para determinar se uma área da árvore é mantida, verifique o arquivo MAINTAINERS na raiz da árvore. Se ninguém estiver listado, analise o histórico de revisões para ver quem fez o commit de alterações no passado. Um script de exemplo que lista cada pessoa que já fez commit de um determinado arquivo junto com o número de commits que cada pessoa fez pode ser encontrado na `freefall` em [.filename]#~eadler/bin/whodid#. Se as consultas não forem atendidas ou se o committer indicar uma falta de interesse na área afetada, vá em frente e faça o commit. [IMPORTANT] ==== Evite enviar e-mails privados para os mantenedores. Outras pessoas podem estar interessadas na conversa, não apenas no resultado final. ==== Se houver qualquer dúvida sobre um commit por qualquer razão, submeta-o ao processo de revisão antes de faze-lo. É melhor fazer com que ele seja criticado lá e não quando ele já fizer parte do repositório. Se um commit resulta em controvérsia, pode ser aconselhável considerar a possibilidade de fazer o rollback do commit até que o assunto seja resolvido. Lembre-se, com um sistema de controle de versão, podemos sempre alterá-lo de volta. Não impugne as intenções dos outros. Se eles vêem uma solução diferente para um problema, ou até um problema diferente, provavelmente não é porque eles são estúpidos, porque eles têm parentesco questionável, ou porque eles estão tentando destruir o trabalho duro, a imagem pessoal ou o FreeBSD, mas basicamente porque eles têm uma visão diferente do mundo. Diferente é bom. Discorde honestamente. Argumente sua posição com base em seus méritos, seja honesto quanto a quaisquer deficiências que possa ter, e esteja aberto para ver a solução deles, ou mesmo a visão deles do problema, com uma mente aberta. Aceite a correção. Somos todos falíveis. Quando você cometer um erro, peça desculpas e continue com a vida. Não se bata, e certamente não espanque os outros por seu erro. Não perca tempo com constrangimentos ou recriminações, apenas conserte o problema e siga em frente. Peça por ajuda. Procure (e dê) revisões dos seus pares. Uma das maneiras pelas quais o software de código aberto deve se sobressair é no número de globos oculares aplicados a ele; isso não se aplica se ninguém revisar o código. [[if-in-doubt]] == Se em dúvida... Quando não tiver certeza sobre algo, seja um problema técnico ou uma convenção do projeto, não se esqueça de perguntar. Se você ficar em silêncio, nunca fará progressos. Se estiver relacionado a um problema técnico, pergunte nas listas públicas de discussão. Evite a tentação de enviar e-mail para a pessoa que conhece a resposta. Dessa forma, todos poderão aprender com a pergunta e a resposta. Para perguntas específicas ou administrativas do projeto, pergunte na seguinte ordem: * Seu mentor ou ex-mentor. * Um committer experiente no IRC, email, etc. * Qualquer equipe com um "hat" (chapéu), uma vez que eles podem lhe dar uma resposta definitiva. * Se ainda não tiver certeza, pergunte na lista de discussão dos desenvolvedores do FreeBSD. Uma vez que sua pergunta seja respondida, se ninguém lhe indicou a documentação que soletra a resposta para sua pergunta, documente-a, pois outros terão a mesma pergunta no futuro. [[bugzilla]] == Bugzilla O Projeto FreeBSD utiliza o Bugzilla para rastrear bugs e requisições de alteração. Certifique-se de fechar o PR caso você faça o commit de uma correção ou sugestão encontrada no banco de dados de PR. Também é considerada uma boa prática você reservar um tempo para fechar qualquer PR associado aos seus commits, se apropriado. Committers com contas não-``FreeBSD.org`` no Bugzilla podem ter a conta antiga mesclada com a conta `FreeBSD.org` seguindo estes passos: [.procedure] . Faça o login usando sua conta antiga. . Abra um novo bug. Escolha `Services` como o Produto e `Bug Tracker` como o Componente. Na descrição de erros liste as contas que você deseja mesclar. . Faça o login usando a conta do `FreeBSD.org` e poste um comentário no bug recém-aberto para confirmar a propriedade. Veja <> para mais detalhes sobre como gerar ou definir uma senha para sua conta `FreeBSD.org`. . Se houver mais de duas contas para mesclar, poste comentários de cada uma delas. Você pode descobrir mais sobre o Bugzilla em: * * https://www.FreeBSD.org/support/[https://www.FreeBSD.org/support/] [[phabricator]] == Phabricator O projeto FreeBSD utiliza o https://reviews.freebsd.org[Phabricator] para solicitações de revisão de código. Veja a página https://wiki.freebsd.org/CodeReview[CodeReview] no wiki para detalhes. Committers com contas não-`FreeBSD.org` no Phabricator podem ter a conta antiga renomeada para a conta `FreeBSD.org` seguindo estes passos: [.procedure] . Altere o email da conta do Phabricator para o seu email `FreeBSD.org`. . Abra um novo bug em nosso bug tracker usando sua conta `FreeBSD.org`, veja <> para mais informações. Escolha `Services` como o Produto e `Code Review` como o Componente. Na descrição de bugs, solicite que a sua conta do Phabricator seja renomeada e forneça um link para o usuário do Phabricator. Por exemplo, `https://reviews.freebsd.org/p/bob_example.com/` [IMPORTANT] ==== As contas do Phabricator não podem ser mescladas, por favor, não abra uma nova conta. ==== [[people]] == Quem é quem Além dos repositórios meisters, existem outros membros e equipes do projeto FreeBSD que você provavelmente conhecerá no exercício da sua função como committer. Resumidamente, e de forma alguma inclusivamente, estes são: Equipe de Engenharia de Documentação mailto:doceng@FreeBSD.org[doceng@FreeBSD.org]:: O doceng é o grupo responsável pela infraestrutura de criação de documentação, aprovando de novos committers de documentação e garantindo que o website do FreeBSD e a documentação no site FTP estão atualizados em relação à árvore subversion. Não é um corpo de resolução de conflitos. A grande maioria das discussões relacionadas à documentação ocorre na http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de discussão do projeto de documentação do FreeBSD]. Mais detalhes sobre a equipe doceng podem ser encontrados em seu https://www.FreeBSD.org/internal/doceng/[charter]. Os committers interessados em contribuir com a documentação devem se familiarizar com o extref:{fdp-primer}[Primer do Projeto de Documentação]. Glen Barber mailto:gjb@FreeBSD.org[gjb@FreeBSD.org], Konstantin Belousov mailto:kib@FreeBSD.org[kib@FreeBSD.org], Bryan Drewery mailto:[bdrewery@FreeBSD.org], Marc Fonvieille mailto:blackend@FreeBSD.org[blackend@FreeBSD.org], Xin Li mailto:delphij@FreeBSD.org[delphij@FreeBSD.org], Colin Percival mailto:cperciva@FreeBSD.org[cperciva@FreeBSD.org] Hiroki Sato mailto:hrs@FreeBSD.org[hrs@FreeBSD.org], Gleb Smirnoff mailto:glebius@FreeBSD.org[glebius@FreeBSD.org]:: Estes são os membros da Equipe de Engenharia de Release mailto:re@FreeBSD.org[re@FreeBSD.org]. Essa equipe é responsável por definir os prazos de lançamento e por controlar o processo de release. Durante o congelamento de código, os engenheiros de release têm autoridade final sobre todas as alterações no sistema para qualquer branch que esteja com status de release pendente. Se há algo que você deseja mesclar do FreeBSD-CURRENT para o FreeBSD-STABLE (quaisquer valores que eles possam ter em um dado momento), estas são as pessoas com quem conversar sobre isso. Gordon Tetlow mailto:gordon@FreeBSD.org[gordon@FreeBSD.org]:: Gordon Tetlow é o https://www.FreeBSD.org/security/[Oficial de Segurança do FreeBSD] e supervisiona a Equipe Oficial de Segurança mailto:security-officer@FreeBSD.org[security-officer@FreeBSD.org]. Garrett Wollman mailto:wollman@FreeBSD.org[wollman@FreeBSD.org]:: Se você precisar de conselhos sobre aspectos internos obscuros da rede ou não tiver certeza de alguma mudança potencial no subsistema de rede que você tem em mente, Garrett é alguém com quem conversar. Garrett também é muito conhecedor dos vários padrões aplicáveis ao FreeBSD. Lista de discussão dos committers do FreeBSD:: http://lists.FreeBSD.org/mailman/listinfo/svn-src-all[svn-src-all], http://lists.FreeBSD.org/mailman/listinfo/svn-ports-all[svn-ports-all] e http://lists.FreeBSD.org/mailman/listinfo/svn-doc-all[svn-doc-all] são as listas de discussão que o sistema de controle de versão usa para enviar mensagens de commit. _Nunca_ envie e-mail diretamente para essas listas. Apenas envie respostas para esta lista quando elas forem curtas e estiverem diretamente relacionadas a um commit. Lista de discussão dos desenvolvedores do FreeBSD:: Todos os committers estão inscritos na -developers. Esta lista foi criada para ser um fórum para os problemas da "comunidade" dos committers. Exemplos são a eleição do Core Team, anúncios, etc. + A lista de discussão dos desenvolvedores do FreeBSD é para uso exclusivo dos committers do FreeBSD. Para desenvolver o FreeBSD, os committers devem ter a capacidade de discutir abertamente assuntos que serão resolvidos antes de serem anunciados publicamente. As discussões francas sobre o trabalho em andamento não são adequadas para publicação aberta e podem prejudicar o FreeBSD. + Espera-se que todos os committers do FreeBSD não publiquem ou encaminhem mensagens da lista de discussão dos desenvolvedores do FreeBSD fora da lista de membros sem a permissão de todos os autores. Violadores serão removidos da lista de discussão dos desenvolvedores do FreeBSD, resultando em uma suspensão dos privilégios de commit. Violações repetidas ou flagrantes podem resultar na revogação permanente dos privilégios de commit. + _Não_ é a intenção desta lista ser um local para revisões de código ou para realizar qualquer discussão técnica. Na verdade, usá-lo como tal prejudica o Projeto FreeBSD, pois dá uma sensação de uma lista fechada, onde as decisões gerais que afetam toda a comunidade usando o FreeBSD são feitas sem serem "abertas". Por último, mas não menos importante, __nunca, nunca, envie por e-mail a lista de discussão dos desenvolvedores do FreeBSD e faça CC:/BCC: para outra lista do FreeBSD__. Nunca, jamais envie email para outra lista de emails do FreeBSD e faça CC:/BCC: para a lista de discussão dos desenvolvedores do FreeBSD. Fazer isso pode diminuir muito os benefícios dessa lista. [[ssh.guide]] == Guia de início rápido do SSH [.procedure] . Se você não quiser digitar sua senha toda vez que usar o man:ssh[1], e você usa chaves para autenticar, o man:ssh-agent[1] está lá para sua conveniência. Se você quiser usar o man:ssh-agent[1], certifique-se de executá-lo antes de executar os outros aplicativos. Os usuários de X, por exemplo, geralmente fazem isso a partir do [.filename]#.xsession# ou do [.filename]#.xinitrc#. Veja man:ssh-agent[1] para detalhes. . Gere um par de chaves usando man:ssh-keygen[1]. O par de chaves será colocado no diretório [.filename]#$HOME/.ssh/#. + [IMPORTANT] ==== Somente as chaves ECDSA, Ed25519 ou RSA são suportadas. ==== . Envie sua chave pública ([.filename]#$HOME/.ssh/id_ecdsa.pub#, [.filename]#$HOME/.ssh/id_ed25519.pub#, ou [.filename]#$HOME/.ssh/id_rsa.pub#) para a pessoa que está configurando você como um committer para que ela possa ser colocada em [.filename]#yourlogin# in [.filename]#/etc/ssh-keys/# na `freefall`. Agora man:ssh-add[1] pode ser usado para autenticação uma vez por sessão. Ele solicita a frase secreta da chave privada e a armazena no agente de autenticação (man:ssh-agent[1]). Use o `ssh-add -d` para remover as chaves armazenadas no agente. Teste com um simples comando remoto: `ssh freefall.FreeBSD.org ls /usr`. Para obter mais informações, consulte package:security/openssh-portable[], man:ssh[1], man:ssh-add[1], man:ssh-agent[1], man:ssh-keygen[1], e man:scp[1]. Para obter informações sobre como adicionar, alterar ou remover chaves man:ssh[1], consulte https://wiki.freebsd.org/clusteradm/ssh-keys[este artigo]. [[coverity]] == Disponibilidade do Coverity(R) para os Committers do FreeBSD Todos os desenvolvedores do FreeBSD podem obter acesso aos resultados da análise do Coverity de todo o software do Projeto FreeBSD. Todos os interessados em obter acesso aos resultados de análise das execuções automatizadas do Coverity podem se inscrever em http://scan.coverity.com/[Coverity Scan]. O wiki do FreeBSD inclui um mini-guia para desenvolvedores interessados em trabalhar com os relatórios de análise do Coverity(R): https://wiki.freebsd.org/CoverityPrevent[https://wiki.freebsd.org/CoverityPrevent]. Por favor observe que este mini-guia só pode ser lido por desenvolvedores do FreeBSD, então se você não puder acessar esta página, você terá que pedir a alguém para adicioná-lo à lista de acesso apropriada do Wiki. Finalmente, todos os desenvolvedores do FreeBSD que usarão o Coverity(R) são sempre encorajados a pedir mais detalhes e informações sobre o uso, publicando quaisquer perguntas na lista de discussão dos desenvolvedores do FreeBSD. [[rules]] == A Grande Lista de Regras dos Committers do FreeBSD Todos os envolvidos com o projeto FreeBSD devem obedecer ao _Código de Conduta_ disponível em https://www.FreeBSD.org/internal/code-of-conduct/[https://www.FreeBSD.org/internal/code-of-conduct/]. Como committers, vocês formam a face pública do projeto, e como você se comporta tem um impacto vital na percepção pública disso. Este guia expande as partes do _Código de Conduta_ específico para os committers. . Respeite outros committers. . Respeite os outros colaboradores. . Discuta qualquer mudança significativa _antes de_ fazer o commit. . Respeite os mantenedores existentes (se listado no campo `MAINTAINER` no [.filename]#Makefile# ou no [.filename]#MAINTAINER# no diretório de nível superior). . Deve ser feito o rollback de qualquer alteração contestada enquanto estiver pendente a resolução da disputa, se solicitado por um mantenedor. Alterações relacionadas à segurança podem anular os desejos de um mantenedor, a critério do Oficial de Segurança. . As alterações vão para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a menos que especificamente permitido pelo engenheiro de release ou a menos que elas não sejam aplicáveis ao FreeBSD-CURRENT. Qualquer alteração não trivial ou não urgente que seja aplicável também deve ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusão, para que tenha tempo suficiente de teste. O engenheiro de release tem a mesma autoridade sobre o branch FreeBSD-STABLE, conforme descrito para o mantenedor na regra #5. . Não brigue em público com outros committers; parece ruim. . Respeite todos os congelamentos de código e leia as listas de discussão `committers` e `developers` em tempo hábil para que você saiba quando um congelamento de código está em vigor. . Em caso de dúvida em qualquer procedimento, pergunte primeiro! . Teste suas alterações antes de fazer o commit. . Não commit em software contribuído sem a aprovação _explicita_ dos respectivos mantenedores. Conforme observado, a quebra de algumas dessas regras pode ser motivo para suspensão ou, mediante ofensa repetida, remoção permanente de privilégios de commit. Membros individuais do core têm o poder de suspender temporariamente os privilégios de commit até que o core como um todo tenha a chance de revisar o problema. No caso de uma "emergência" (um committer causando dano ao repositório), uma suspensão temporária também pode ser feita pelos meisters do repositório. Apenas uma maioria de 2/3 do core tem autoridade para suspender os privilégios de confirmação por mais de uma semana ou para removê-los permanentemente. Essa regra não existe para definir o core como um bando de ditadores cruéis que podem se livrar casualmente de committers como se fossem latas de refrigerante vazias, mas para dar ao projeto uma espécie de fusível de segurança. Se alguém está fora de controle, é importante ser capaz de lidar com isso imediatamente, em vez de ficar paralisado pelo debate. Em todos os casos, um committer cujos privilégios foram suspensos ou revogados tem direito a uma "audiência" com o core, sendo a duração total da suspensão determinada naquele momento. Um committer cujos privilégios são suspensos também pode solicitar uma revisão da decisão após 30 dias e a cada 30 dias a partir de então (a menos que o período total de suspensão seja inferior a 30 dias). Um committer cujos privilégios tenham sido revogados completamente pode solicitar uma revisão após um período de 6 meses. Esta política de revisão é _estritamente informal_ e, em todos os casos, o core reserva-se o direito de agir ou desconsiderar os pedidos de revisão se eles sentirem que a decisão original é a correta. Em todos os outros aspectos da operação do projeto, o core é um subconjunto de committers e é limitado pelas __mesmas regras__. Só porque alguém está no core isso não significa que eles têm permissão especial para sair de qualquer uma das linhas pintadas aqui; os "poderes especiais" do core só são aplicados quando ele age como um grupo, não individualmente. Como indivíduos, os membros da equipe principal são todos committers em primeiro lugar e core em segundo. === Detalhes [[respect]] . Respeite outros committers. + Isso significa que você precisa tratar outros committers como os desenvolvedores de grupos pares que eles são. Apesar de nossas tentativas ocasionais de provar o contrário, não se chega a ser um committer por ser estúpido e nada incomoda mais do que ser tratado dessa maneira por um de seus colegas. Se nós sempre sentimos respeito uns pelos outros ou não (e todo mundo tem dias difíceis), nós ainda temos que _tratar_ os outros committers com respeito em todos os momentos, em fóruns públicos e em emails privados. + Ser capaz de trabalhar juntos a longo prazo é o maior patrimônio deste projeto, muito mais importante do que qualquer conjunto de alterações no código, e transformar argumentos sobre código em problemas que afetam nossa capacidade de longo prazo de trabalhar harmoniosamente juntos não vale a pena por qualquer estiramento concebível da imaginação. + Para cumprir esta regra, não envie e-mails quando estiver com raiva ou de alguma forma se comportar de uma maneira que possa causar uma confrontação desnecessária com os outros. Primeiro acalme-se, então pense em como se comunicar da maneira mais eficaz para convencer as outras pessoas de que o seu lado do argumento está correto, não apenas gaste um pouco de vapor para que você possa se sentir melhor a curto prazo às custas de uma guerra de longa duração. Isso não só é uma "economia de energia" muito ruim, mas demonstrações repetidas de agressão pública que prejudicam nossa capacidade de trabalhar bem juntas serão tratadas severamente pela liderança do projeto e podem resultar na suspensão ou término dos seus privilégios de commit. . A liderança do projeto levará em consideração as comunicações públicas e privadas trazidas a ela. Ela não buscará a divulgação de comunicações privadas, mas levará isso em conta se for oferecida de forma voluntária pelos envolvidos na reclamação. + Tudo isso nunca é uma opção que a liderança do projeto goste nem um pouco, mas a união vem em primeiro lugar. Nenhuma quantidade de código ou de bons conselhos vale a pena se trocar desta forma. . Respeite os outros colaboradores. + Você nem sempre foi um committer. Houve uma época em que você era um colaborador. Lembre-se disso em todos os momentos. Lembre-se de como foi tentar obter ajuda e atenção. Não se esqueça de que seu trabalho como colaborador foi muito importante para você. Lembre-se de como foi. Não desencoraje, deprecie ou diminua os colaboradores. Trate-os com respeito. Eles são nossos committers em espera. Eles são tão importantes para o projeto quanto os committers. Suas contribuições são tão válidas e tão importantes quanto as suas. Afinal, você fez muitas contribuições antes de se tornar um committer. Sempre se lembre disso. + Considere os pontos levantados sob <> e aplique-os também aos contribuidores. . Discuta qualquer mudança significativa _antes de_ fazer o commit. + O repositório não é onde as alterações são inicialmente submetidas para correção ou discussão, isso acontece primeiro nas listas de discussão ou pelo uso do serviço do Phabricator. O commit só acontecerá quando algo semelhante a um consenso for alcançado. Isso não significa que a permissão seja necessária antes de corrigir todos os erros óbvios de sintaxe ou erros ortográficos na página manual, significa apenas que é bom desenvolver uma ideia de quando a mudança proposta não é tão óbvia e requer algum feedback primeiro. As pessoas realmente não se importam com mudanças radicais se o resultado for algo claramente melhor do que antes, elas simplesmente não gostam de ser _surpreendidas_ por essas mudanças. A melhor maneira de certificar-se de que as coisas estão no caminho certo é ter o código revisado por um ou mais committers. + Em caso de dúvida, peça por uma revisão! . Respeite os mantenedores existentes, se listados. + Muitas partes do FreeBSD não são "possuídas" no sentido de que qualquer indivíduo específico irá pular e gritar se você enviar uma alteração para a "sua" área, mas ainda vale a pena verificar primeiro. Uma convenção que usamos é colocar uma linha de mantenedor no [.filename]#Makefile# para qualquer pacote ou subárvore que esteja sendo mantido ativamente por uma ou mais pessoas; veja extref:{developers-handbook}[Source Tree Guidelines and Policies, policies] para documentação sobre isso. Nas seções de código para quais existirem vários mantenedores, os commits nas áreas afetadas por um mantenedor precisarão ser revisados por pelo menos um outro mantenedor. Nos casos em que o "maintainer-ship" de algo não está claro, consulte os logs do repositório para os arquivos em questão e veja se alguém está trabalhando recentemente ou predominantemente naquela área. . Deve ser feito o rollback de qualquer alteração contestada enquanto estiver pendente a resolução da disputa, se solicitado por um mantenedor. Alterações relacionadas à segurança podem anular os desejos de um mantenedor, a critério do Oficial de Segurança. + Isso pode ser difícil de engolir em momentos de conflito (quando cada lado está convencido de que eles estão certos, é claro), mas um sistema de controle de versão torna desnecessário ter uma disputa em andamento quando é muito mais fácil simplesmente reverter a mudança que gerou a disputa, faça com que todos se acalmem novamente e tente descobrir qual é a melhor maneira de proceder. Se a mudança acaba por ser a melhor coisa depois de tudo, ela pode ser facilmente trazida de volta. Se ela não for, os usuários não terão que viver com a mudança falsa na árvore enquanto todos estavam ocupados debatendo seus méritos. Pessoas _muito_ raramente pedem rollbacks no repositório, uma vez que a discussão geralmente expõe mudanças ruins ou controversas antes que o commit aconteça, mas em raras ocasiões o rollback deve ser feito sem discussão para que possamos entrar imediatamente da discussão do tópico para descobrirmos se ele era adequado ou não. . As alterações vão para o FreeBSD-CURRENT antes do FreeBSD-STABLE, a menos que especificamente permitido pelo engenheiro de release ou a menos que elas não sejam aplicáveis ao FreeBSD-CURRENT. Qualquer alteração não trivial ou não urgente que seja aplicável também deve ser permitida no FreeBSD-CURRENT por pelo menos 3 dias antes da fusão, para que possa ter tempo suficiente de teste. O engenheiro de lançamento tem a mesma autoridade sobre o branch FreeBSD-STABLE, conforme descrito na regra #5. + Este é outro problema do tipo "não discuta sobre isso", já que é o engenheiro de release quem é o responsável final (e é espancado) se uma mudança for ruim. Por favor, respeite isso e dê ao engenheiro de release a sua total cooperação quando se trata do branch FreeBSD-STABLE. O gerenciamento do FreeBSD-STABLE pode frequentemente parecer excessivamente conservador para o observador casual, mas também deve ter em mente o fato de que o conservadorismo deve ser a marca do FreeBSD-STABLE e regras diferentes aplicam-se lá do que no FreeBSD-CURRENT. Também não há sentido em fazer com que o FreeBSD-CURRENT seja um campo de testes se as alterações forem mescladas no FreeBSD-STABLE imediatamente. Mudanças precisam de uma chance de serem testadas pelos desenvolvedores do FreeBSD-CURRENT, então espere algum tempo antes da fusão, a menos que a correção do FreeBSD-STABLE seja crítica, sensível ao tempo ou óbvia a ponto de tornar desnecessário testes adicionais (correções ortográficas nas páginas de manual) correções de erros / erros de digitação, etc.) Em outras palavras, aplique o bom senso. + Mudanças nas branches de segurança (por exemplo, `releng/9.3`) devem ser aprovadas por um membro da Equipe de Segurança mailto:security-officer@FreeBSD.org[security-officer@FreeBSD.org], ou em alguns casos , por um membro da Equipe de Engenharia de Release mailto:re@FreeBSD.org[re@FreeBSD.org]. . Não brigue em público com outros committers; parece ruim. + Este projeto tem uma imagem pública a defender e essa imagem é muito importante para todos nós, especialmente se quisermos continuar a atrair novos membros. Haverá ocasiões em que, apesar das melhores tentativas de autocontrole de todos, os ânimos se perdem e palavras de raiva são trocadas. A melhor coisa que pode ser feita nesses casos é minimizar os efeitos disso até que todos tenham esfriado. Não divulgue palavras iradas em público e não encaminhe correspondências privadas ou outras comunicações privadas para listas publicas de discussão, aliases de mensagens, canais de mensagens instantâneas ou sites de mídia social. O que as pessoas dizem um-para-um é frequentemente muito menos revestido de açúcar do que o que eles diriam em público, e tais comunicações, portanto, não têm lugar lá - elas servem apenas para inflamar uma situação já ruim. Se a pessoa que enviou um flame-o-grama tiver pelo menos a elegância de enviá-lo em particular, então tenha a elegância de mantê-lo em sigilo. Se você acha que está sendo tratado injustamente por outro desenvolvedor e está lhe causando angústia, traga o assunto para o core em vez de torná-lo público. O Core fará o seu melhor para atuar como pacificadores e trazer as coisas de volta para a sanidade. Nos casos em que a disputa envolve uma alteração na base de código e os participantes não parecem estar chegando a um acordo amigável, o core pode nomear um terceiro mutuamente aceitável para resolver a disputa. Todas as partes envolvidas devem então concordar em se comprometer com a decisão tomada por este terceiro. . Respeite todos os congelamentos de código e leia atempadamente a lista de discussão `committers` e `developers` para saber quando um congelamento de código está em vigor. + Efetuar o commit de alterações não aprovadas durante um congelamento de código é um erro realmente grande e espera-se que os committers se mantenham atualizados sobre o que está acontecendo antes de entrar depois de uma longa ausência e fazer o commit de 10 megabytes de material acumulado. As pessoas que abusarem disso regularmente terão seus privilégios de commit suspensos até que eles voltem do FreeBSD Happy Reeducation Camp que mantemos na Groenlândia. . Em caso de dúvida em qualquer procedimento, pergunte primeiro! + Muitos erros são cometidos porque alguém está com pressa e apenas assume que sabe a forma certa para fazer alguma coisa. Se você não fez isso antes, é bem provável que você não conheça realmente a maneira como fazemos as coisas e realmente precise perguntar primeiro ou você vai se envergonhar completamente em público. Não há vergonha em perguntar "como diabos eu faço isso?" Já sabemos que você é uma pessoa inteligente; caso contrário, você não seria um committer. . Teste suas alterações antes de fazer o commit. + Isso pode parecer óbvio, mas se realmente fosse tão óbvio, provavelmente não veríamos tantos casos de pessoas claramente não fazendo isso. Se suas mudanças são para o kernel, certifique-se de que você ainda pode compilar o GENERIC e o LINT. Se as suas alterações estiverem em outro lugar, certifique-se de que você ainda pode fazer um "make world". Se as alterações forem feitas em uma branch, certifique-se de que seu teste ocorra com uma máquina que esteja executando esse código. Se você tiver uma alteração que também possa quebrar outra arquitetura, verifique e teste em todas as arquiteturas suportadas. Por favor, consulte a https://www.FreeBSD.org/internal/[Página Interna do FreeBSD] para obter uma lista dos recursos disponíveis. À medida que outras arquiteturas são adicionadas à lista de plataformas suportadas do FreeBSD, os recursos de teste compartilhados apropriados serão disponibilizados. . Não commit em software contribuído sem a aprovação _explicita_ dos respectivos mantenedores. + Software contribuído é qualquer código que esteja sob as árvores [.filename]#src/contrib#, [.filename]#src/crypto#, ou [.filename]#src/sys/contrib#. + As árvores mencionadas acima são para software contribuído geralmente importado para um branch de fornecedor. Fazer o commit de algo lá pode causar dores de cabeça desnecessárias quando for importado novas versões do software. Uma regra geral é considerar enviar os patches upstream diretamente para o fornecedor. Patches podem ser committados primeiramente no FreeBSD, desde que tenha a permissão do mantenedor. + As razões para modificar o software upstream variam entre querer controle estrito sobre uma dependência fortemente acoplada à falta de portabilidade na distribuição do repositório canônico do seu código. Independentemente do motivo, o esforço para minimizar a carga de manutenção do fork é útil para outros mantenedores. Evite realizar commits de alterações triviais ou cosméticas nos arquivos, pois isso dificulta cada merge: esses patches precisam ser verificados manualmente a cada importação. + Se uma parte específica do software não tiver um mantenedor, você é incentivado a assumir a propriedade. Se você não tiver certeza sobre o mantenedor atual, envie um email para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-arch[lista de email de arquitetura e design do FreeBSD] e pergunte. === Política sobre Várias Arquiteturas O FreeBSD adicionou ports para várias novas arquiteturas durante os ciclos de release recentes e realmente não é mais um sistema operacional centrado em i386(TM). Em um esforço para tornar mais fácil manter o FreeBSD portátil entre as plataformas que suportamos, o core desenvolveu este mandato: [.blockquote] Nossa plataforma de referência de 32 bits é a i386 e a nossa plataforma de referência de 64 bits é amd64. O principal trabalho de design (incluindo as principais alterações da API e da ABI) deve ser comprovado em pelo menos uma plataforma de 32 bits e pelo menos uma de 64 bits, preferencialmente nas plataformas de referência primária, antes que o seu commit possa ser feito na árvore de fontes. As plataformas i386 e amd64 foram escolhidas por estarem mais prontamente disponíveis para os desenvolvedores e como representantes dos mais diversos designs de processador e de sistema - "big versus little endian", registrador de arquivos versus pilha de registro, diferentes implementações de DMA e cache, tabelas de página de hardware versus gerenciamento de TLB de software, etc. Continuaremos a reavaliar essa política, já que o custo e a disponibilidade das plataformas de 64 bits mudam. Os desenvolvedores também devem estar cientes da nossa Política de Tier para o suporte de longo prazo das arquiteturas de hardware. As regras aqui pretendem fornecer orientação durante o processo de desenvolvimento e são diferentes dos requisitos de recursos e arquiteturas listados nessa seção. As regras de Tier para suporte de recursos em arquiteturas no momento da release são mais rigorosas do que as regras para alterações durante o processo de desenvolvimento. === Outras Sugestões Ao enviar alterações na documentação, use um verificador ortográfico antes de efetuar o commit. Para todos os documentos XML, verifique se as diretivas de formatação estão corretas executando o `make lint` e o package:textproc/igor[]. Para as páginas de manual, execute o package:sysutils/manck[] e o package:textproc/igor[] na página de manual para verificar se todas as referências cruzadas e referências de arquivo estão corretas e se a página man possui todos os `MLINKS` apropriados instalados. Não misture correções de estilo com novas funcionalidades. Uma correção de estilo é qualquer alteração que não modifique a funcionalidade do código. Misturar as alterações ofusca a mudança de funcionalidade ao solicitar a comparação das diferenças entre as revisões, o que pode ocultar quaisquer novos bugs. Não inclua alterações de espaço em branco com alterações de conteúdo nos commits para [.filename]#doc/#. A desordem extra nos diffs torna o trabalho dos tradutores muito mais difícil. Em vez disso, faça qualquer alteração de estilo ou espaço em branco em commits separados e que sejam claramente rotuladas como tal na mensagem de commit. === Recursos Obsoletos (Deprecated) Quando for necessário remover uma funcionalidade de software do sistema básico, siga estas diretrizes sempre que possível: . Uma menção é feita na página de manual e, possivelmente, nas notas de versão que a opção, o utilitário ou a interface estão obsoletos. O uso do recurso obsoleto gera um aviso. . A opção, utilitário ou interface é preservada até a próxima release principal (ponto zero). . A opção, o utilitário ou a interface são removidos e não são mais documentados. Agora está obsoleto. Também é geralmente uma boa ideia anotar sua remoção nas notas de release. === Privacidade e Confidencialidade . A maioria dos negócios do FreeBSD é feita em público. + O FreeBSD é um projeto __aberto__. O que significa que não só alguém pode usar o código-fonte, mas que a maior parte do processo de desenvolvimento está aberto ao escrutínio público. . Certos assuntos delicados devem permanecer privados ou mantidos sob embargo. + Infelizmente, não pode haver transparência completa. Como desenvolvedor do FreeBSD, você terá um certo grau de acesso privilegiado à informação. Consequentemente, espera-se que você respeite certos requisitos de confidencialidade. Às vezes, a necessidade de confidencialidade vem de colaboradores externos ou tem um limite de tempo específico. Principalmente, porém, é uma questão de não liberar comunicações privadas. . O oficial de segurança tem controle exclusivo sobre a liberação de alertas de segurança. + Onde existem problemas de segurança que afetam muitos sistemas operacionais diferentes, o FreeBSD frequentemente depende do acesso antecipado para poder preparar alertas para liberação coordenada. A menos que se possa confiar nos desenvolvedores do FreeBSD para manter a segurança, esse acesso antecipado não será disponibilizado. O Oficial de Segurança é responsável por controlar o acesso pré-lançamento às informações sobre vulnerabilidades, e por definir o momento de liberação de todos os alertas. Ele pode solicitar ajuda sob condição de confidencialidade de qualquer desenvolvedor com conhecimento relevante para preparar as correções de segurança. . As comunicações com o Core são mantidas confidenciais pelo tempo que for necessário. + As comunicações para o core serão inicialmente tratadas como confidenciais. Eventualmente, no entanto, a maioria dos negócios do Core serão resumidos nos relatórios mensais ou trimestrais do core. Cuidado será tomado para evitar a divulgação de detalhes sensíveis. Os registros de alguns assuntos particularmente sensíveis podem não ser relatados e serão mantidos apenas nos arquivos privados do Core. . Acordos de não divulgação (NDA) podem ser necessários para o acesso a determinados dados comercialmente sensíveis. + O acesso a determinados dados comercialmente sensíveis só pode estar disponível sob um Contrato de Não Divulgação. A equipe jurídica da Fundação FreeBSD deve ser consultado antes de qualquer acordo vinculativo ser firmado. . Comunicações privadas não devem ser tornadas públicas sem permissão. + Além dos requisitos específicos acima, há uma expectativa geral de não publicar comunicações privadas entre desenvolvedores sem o consentimento de todas as partes envolvidas. Peça permissão antes de encaminhar uma mensagem para uma lista de discussão pública, ou publicá-la em um fórum ou site que possa ser acessado por outros que não os correspondentes originais. . As comunicações em canais de acesso restrito ou somente do projeto devem ser mantidas em sigilo. + Semelhantemente às comunicações pessoais, certos canais de comunicação interna, incluindo as listas de discussão dos Committers do FreeBSD e os canais de IRC de acesso restrito, são considerados comunicações privadas. A permissão é necessária para publicar material dessas fontes. . O Core pode aprovar a publicação. + Quando for impraticável obter permissão devido ao número de correspondentes ou quando a permissão para publicar for injustificadamente retida, a Core poderá aprovar a liberação de tais assuntos privados que mereçam uma publicação mais geral. [[archs]] == Suporte para Várias Arquiteturas O FreeBSD é um sistema operacional altamente portátil destinado a funcionar em muitos tipos diferentes de arquiteturas de hardware. Manter uma separação clara entre o código dependente de máquina (MD) e independente de máquina (MI), além de minimizar o código MD, é uma parte importante da nossa estratégia de permanecer ágil em relação às tendências atuais de hardware. Cada nova arquitetura de hardware suportada pelo FreeBSD aumenta substancialmente o custo de manutenção de código, de suporte do toolchain e de engenharia de release. Também aumenta drasticamente o custo do teste efetivo das alterações no kernel. Como tal, há uma forte motivação para diferenciar as classes de suporte para as várias arquiteturas, permanecendo forte em algumas arquiteturas chaves que são vistas como o "público-alvo" do FreeBSD. === Declaração de Intenção Geral O projeto FreeBSD tem como objetivo a "qualidade comercial de produção off-the-shelf (COTS) para workstations, servidores e sistemas embarcados de ponta". Mantendo o foco em um conjunto restrito de arquiteturas de interesse nesses ambientes, o Projeto FreeBSD é capaz de manter altos níveis de qualidade, estabilidade e desempenho, bem como de minimizar a carga de várias equipes de suporte no projeto, como a equipe de ports, a equipe de documentação, o oficial de segurança e as equipes de engenharia de release. A diversidade no suporte de hardware amplia as opções para os consumidores do FreeBSD oferecendo novos recursos e oportunidades de uso, mas esses benefícios devem sempre ser cuidadosamente considerados em termos do custo de manutenção no mundo real associado ao suporte adicional à plataforma. O projeto FreeBSD diferencia plataforma alvos em quatro camadas. Cada camada inclui uma lista de garantias que os consumidores podem confiar , bem como as obrigações por Projeto e desenvolvedores para cumprir essas garantias. Esta lista define o mínimo de garantia por cada camada. O Projeto e desenvolvedores podem prover leveis de suporte adicionais além da garantia mínima dada a uma camada, mas tais suportes adicionais não tem garantias. Cada plataforma alvo é designada para uma camada especifica para cada ramificação stable. Como resultado, a plataforma alvo poderia ser designada para diferentes camadas em ramificações stable concorrentes. === Plataformas Alvo O suporte para uma plataforma de hardware consiste em dois componentes: suporte ao kernel e interfaces binárias de aplicativos (ABIs) do usuário. O suporte do kernel à plataforma inclui os itens necessários para executar um kernel do FreeBSD em uma plataforma de hardware, como gerenciamento de memória virtual dependente de máquina e drivers de dispositivo. Uma ABI especifica uma interface para os processos do usuário interagirem com o kernel do FreeBSD e as bibliotecas do sistema base. Uma ABI inclui interfaces de chamada do sistema, o layout e a semântica de estruturas de dados públicos e o layout e a semântica de argumentos transmitidos às sub-rotinas. Alguns componentes de uma ABI podem ser definidos por especificações tais como o layout dos objetos de exceção C ++ ou as convenções de chamada para funções C. Um kernel do FreeBSD também usa uma ABI (às vezes chamada de Interface Binária do Kernel (KBI)) que inclui a semântica e layouts de estruturas de dados públicos e o layout e semântica de argumentos para funções públicas dentro do próprio kernel. Um kernel do FreeBSD pode suportar múltiplas ABIs de usuário. Por exemplo, o kernel amd64 do FreeBSD suporta as ABIs de usuário do FreeBSD amd64 e i386, bem como as ABIs de usuário do Linux x86_64 e i386. Um kernel do FreeBSD deve suportar uma ABI "nativa" como a ABI padrão. A "ABI" nativa geralmente compartilha certas propriedades com a ABI do kernel, como a convenção de chamada C, tamanhos dos tipos básicos, etc. Os Tiers são definidos tanto para os kernels quanto para as ABIs do usuário. Normalmente, o kernel de uma plataforma e as ABIs do FreeBSD são atribuídas à mesma Tier. === Tier 1: Arquiteturas Completamente Suportadas As plataformas Tier 1 são as plataformas mais maduras do FreeBSD. Elas são suportadas pelas equipes de segurança, engenharia de release e gerenciamento de ports. Espera-se que as arquiteturas Tier 1 estejam com Qualidade de Produção em relação a todos os aspectos do sistema operacional FreeBSD, incluindo ambientes de instalação e desenvolvimento. O Projeto FreeBSD fornece as seguintes garantias aos consumidores das plataformas de Tier 1: * Imagens oficiais de Release do FreeBSD serão fornecidas pela equipe de engenharia de release. * Serão fornecidas atualizações binárias e patches no formato de código fonte para os Avisos de Segurança e Avisos de Erro das versões suportadas. * Serão fornecidos patches de código fonte para os avisos de segurança das branches suportadas. * Atualizações binárias e patches de código fonte geralmente são fornecidos para os avisos de segurança multiplataforma no momento do anúncio. * As alterações nas ABIs do usuário geralmente incluirão bibliotecas de compatibilidade para garantir a operação correta dos binários compilados a partir de qualquer branch estável de uma plataforma Tier 1. Estas bibliotecas podem não ser ativadas na instalação padrão. Se as bibliotecas de compatibilidade não forem fornecidas para uma alteração de ABI, a falta da mesma estará claramente documentada nas notas de versão. * Alterações em certas partes da ABI do kernel incluirão bibliotecas de compatibilidade para garantir a operação correta dos módulos do kernel compilados contra a versão suportada mais antiga da branch. Observe que nem todas as partes da ABI do kernel estão protegidas. * Pacotes binários oficiais para softwares de terceiros serão fornecidos pela equipe de ports. Para arquiteturas embarcadas, esses pacotes podem ser compilados de forma cruzada a partir de uma arquitetura diferente. * Os ports mais relevantes devem ou compilar ou ter filtros apropriados para prevenir a compilação dos inadequados. * Novos recursos que não são inerentemente específicos da plataforma serão totalmente funcionais em todas as arquiteturas de Tier 1. * Os recursos e bibliotecas de compatibilidade usados pelos binários compilados a partir das branchs estáveis mais antigas podem ser removidos nas versões principais mais recentes. Essas remoções serão claramente documentadas nas notas de versão. * As plataformas Tier 1 devem ser totalmente documentadas. As operações básicas serão documentadas no Handbook do FreeBSD. * As plataformas de Tier 1 serão incluídas na árvore de código fonte. * As plataformas de Tier 1 devem ser auto-hospedadas ou por meio de um toolchain disponível na árvore de código fonte ou por meio de um toolchain externo. Se um toolchain externo for necessário, serão fornecidos pacotes binários oficiais para o toolchain externo. Para manter a maturidade das plataformas de Tier 1, o Projeto FreeBSD manterá os seguintes recursos para apoiar o desenvolvimento: * Suporte à automação do processo de compilação e de testes no cluster FreeBSD.org ou em algum outro local facilmente disponível para todos os desenvolvedores. Plataformas embarcadas podem substituir um emulador disponível no cluster FreeBSD.org por hardware real. * A inclusão nos targets do `make universe` e `make tinderbox`. * Hardware dedicado em um dos clusters do FreeBSD para compilação de pacotes (nativamente ou via qemu-user). Coletivamente, os desenvolvedores devem fornecer o seguinte para manter o status de Tier 1 de uma plataforma: * Alterações na árvore de código fonte não devem quebrar conscientemente a compilação de uma plataforma de Tier 1. * As arquiteturas de Tier 1 devem ter um ecossistema maduro e saudável de usuários e desenvolvedores ativos. * Os desenvolvedores devem ser capazes de compilar pacotes em sistemas Tier 1 não-embarcados comumente disponíveis. Isso pode significar compilações nativas se sistemas não-embarcados estiverem normalmente disponíveis para a plataforma em questão, ou significar compilações cruzadas hospedadas em alguma outra arquitetura de Tier 1. * As alterações não podem quebrar a ABI do usuário. Se for necessária uma alteração da ABI, a compatibilidade da ABI com os binários existentes deve ser provida através do versionamento de símbolos ou do versionamento de bibliotecas compartilhadas. * Alterações mescladas em branchs estáveis não podem quebrar as partes protegidas da ABI do kernel. Se for necessária uma alteração da ABI do kernel, ela deverá ser modificada para preservar a funcionalidade dos módulos existentes do kernel. === Tier 2: Arquiteturas de Desenvolvimento e Nicho As plataformas de Tier 2 são funcionais, mas são plataformas FreeBSD menos maduras. Elas não são suportadas pelas equipes de segurança, engenharia de release e gerenciamento de ports. As plataformas Tier 2 podem ser candidatas à plataforma Tier 1 que ainda estão em desenvolvimento ativo. As arquiteturas que atingem o fim da vida útil também podem ser movidas do status de Tier 1 para o status de Tier 2 à medida que a disponibilidade de recursos para continuar a manter o sistema em um estado de Qualidade de Produção diminui. Arquiteturas de nicho bem suportadas também podem ser de Tier 2. O Projeto FreeBSD fornece as seguintes garantias aos consumidores das plataformas de Tier 2: * A infraestrutura de ports deve incluir suporte básico para as arquiteturas de Tier 2 suficiente para suportar a compilação de ports e pacotes. Isso inclui suporte para pacotes básicos, tais como o ports-mgmt/pkg, mas não há garantia de que ports arbitrários serão compiláveis ou funcionais. * Novos recursos que não são inerentemente específicos da plataforma devem ser viáveis em todas as arquiteturas de Tier 2 se não implementados. * As plataformas de Tier 2 serão incluídas na árvore de código fonte. * As plataformas de Tier 2 devem ser auto-hospedadas ou por meio de um toolchain disponível na árvore de código fonte ou por meio de um toolchain externo. Se um toolchain externo for necessário, serão fornecidos pacotes binários oficiais para o toolchain externo. * As plataformas de Tier 2 devem fornecer kernels e espaço de usuário funcionais, mesmo que uma release oficial não seja provida. Para manter a maturidade das plataformas de Tier 2, o Projeto FreeBSD manterá os seguintes recursos para apoiar o desenvolvimento: * A inclusão nos targets do `make universe` e `make tinderbox`. Coletivamente, os desenvolvedores devem fornecer o seguinte para manter o status de Tier 2 de uma plataforma: * Alterações na árvore de código fonte não devem quebrar conscientemente a compilação de uma plataforma de Tier 2. * As arquiteturas de Tier 2 devem ter um ecossistema ativo de usuários e desenvolvedores. * Embora sejam permitidas alterações que quebrem a ABI do usuário, a ABI não deve ser quebrada gratuitamente. Alterações significativas da ABI do usuário devem ser restritas às versões principais. * Novos recursos que ainda não foram implementados nas arquiteturas de Tier 2 devem fornecer um meio de desativá-los nessas arquiteturas. === Tier 3: Arquiteturas Experimentais As plataformas de Tier 3 têm pelo menos suporte parcial ao FreeBSD. Elas _não_ são suportadas pelas equipes de segurança, engenharia de release e de gerenciamento de ports. As plataformas de Tier 3 são arquiteturas nos estágios iniciais de desenvolvimento, para plataformas de hardware não convencionais, ou que são considerados sistemas legados improváveis de serem amplamente utilizados no futuro. O suporte inicial para plataformas de Tier 3 pode existir em um repositório separado em vez do repositório de código fonte principal. O Projeto FreeBSD não oferece garantias aos consumidores das plataformas de Tier 3 e não está comprometido em manter recursos para apoiar o seu desenvolvimento. As plataformas de Tier 3 nem sempre podem ser compiláveis, nem quaisquer ABIs do kernel ou de usuário são consideradas estáveis. === Tier 4: Arquiteturas Não Suportadas As plataformas Tier 4 não são suportadas de nenhuma forma pelo projeto. Todos os sistemas não classificados de outra forma são sistemas de Tier 4. Quando uma plataforma faz a transição para o Tier 4, todo o suporte para a plataforma é removido das árvores de código fonte e de ports. Observe que o suporte aos ports deve ser mantido enquanto a plataforma for suportada em uma branch suportada pelo ports. === Política para Alteração do Tier de uma Arquitetura Os sistemas só podem ser movidos de um Tier para outro por meio da aprovação do Core Team do FreeBSD, que deve tomar essa decisão em colaboração com as equipes de segurança, engenharia de release e gerenciamento dos ports. Para que uma plataforma seja promovida para um Tier superior, todas as garantias de suporte ausentes devem ser atendidas antes que a promoção seja concluída. [[ports]] == FAQ específico dos Ports .Adicionando um Novo Port [[ports-qa-add-new]] === Como eu adiciono um novo port? Primeiro, por favor leia a seção sobre cópias do repositório. A maneira mais fácil de adicionar um novo port é o script `addport` localizado no diretório [.filename]#ports/Tools/scripts#. Ele adiciona um port do diretório especificado, determinando a categoria automaticamente a partir do [.filename]#Makefile# do port. Também adiciona uma entrada à categoria do [.filename]#Makefile# do port. Foi escrito por Michael Haro mailto:mharo@FreeBSD.org[mharo@FreeBSD.org], Will Andrews mailto:will@FreeBSD.org[will@FreeBSD.org] e Renato Botelho mailto:garga@FreeBSD.org[garga@FreeBSD.org]. Ao enviar perguntas sobre este script para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[lista de discussão dos ports do FreeBSD], por favor também copie Chris Rees mailto:crees@FreeBSD.org[crees@FreeBSD.org], o mantenedor atual. [[ports-qa-add-new-extra]] === Existe qualquer outra coisa que preciso saber quando adiciono um novo port? Verifique o port, de preferência para garantir que ele seja compilado e empacotado corretamente. Essa é a seqüência recomendada: [source,shell] .... # make install # make package # make deinstall # pkg add package you built above # make deinstall # make reinstall # make package .... O extref:{porters-handbook}[Manual de Porters] contém instruções mais detalhadas. Use o man:portlint[1] para verificar a sintaxe do port. Você não precisa necessariamente eliminar todos os avisos, mas certifique-se de ter corrigido os mais simples. Se o port veio de um remetente que não contribuiu para o projeto antes, adicione o nome dessa pessoa a seção extref:{contributors}[Colaboradores Adicionais, contrib-additional] da Lista de Colaboradores do FreeBSD. Feche o PR se o port entrou como um PR. Para fechar um PR, mude o estado para `Issue Resolved` e a resolução como `Fixed`. [[non-committers]] == Problemas Específicos para Desenvolvedores Que Não São Committers Algumas pessoas que têm acesso às máquinas do FreeBSD não possuem commit bits. Quase todo este documento também será aplicado a esses desenvolvedores (exceto itens específicos de commits e associações de listas de discussão que os acompanham). Em particular, recomendamos que você leia: * <> * <> + [NOTE] ==== Peça ao seu mentor para adicioná-lo em "Colaboradores Adicionais" ([.filename]#doc/en_US.ISO8859-1/articles/contributors/contrib.additional.xml#), se você ainda não estiver listado há. ==== * <> * <> * <> [[google-analytics]] == Informações sobre o Google Analytics A partir de 12 de dezembro de 2012, o Google Analytics foi habilitado no site do Projeto FreeBSD para coletar estatísticas anônimas sobre o uso do site. As informações coletadas são valiosas para o Projeto de Documentação do FreeBSD, para identificar vários problemas no site do FreeBSD. [[google-analytics-policy]] === Política Geral do Google Analytics O projeto FreeBSD leva a privacidade do visitante muito a sério. Como tal, o site do Projeto FreeBSD honra o cabeçalho "Do Not Track"__antes__ de buscar o código de monitoramento do Google. Para mais informações, consulte a https://www.FreeBSD.org/privacy/[Política de Privacidade do FreeBSD]. O acesso do Google Analytics _não_ é arbitrariamente permitido - o acesso deve ser solicitado, votado pela Equipe de Engenharia de Documentação mailto:doceng@FreeBSD.org[doceng@FreeBSD.org] e explicitamente concedido. Solicitações de acesso aos dados do Google Analytics devem incluir uma finalidade específica. Por exemplo, uma razão válida para solicitar acesso seria "para ver os navegadores web usados com mais freqüência pelos visitantes do website do FreeBSD para garantir que as velocidades de renderização da página sejam aceitáveis." Por outro lado, "ver quais navegadores são usados com mais freqüência" (sem declarar __por que__) seria rejeitado. Todas as solicitações devem incluir o período de tempo para o qual os dados seriam requisitados. Por exemplo, deve ser explicitamente declarado se os dados solicitados seriam requisitados em um período de tempo que abranja um período de 3 semanas, ou se o pedido seria para acessar apenas uma vez. Qualquer pedido de dados do Google Analytics sem uma razão clara e razoável que beneficie o Projeto FreeBSD será rejeitado. [[google-analytics-data]] === Dados disponíveis por meio do Google Analytics Alguns exemplos dos tipos de dados do Google Analytics disponíveis incluem: * Navegadores Web comumente usados * Tempos de carregamento de páginas * Acesso ao site por idioma [[misc]] == Perguntas Diversas === Como adiciono um novo arquivo a uma branch? Para adicionar um arquivo a uma branch, simplesmente faça o check-out ou atualize-o na branch que você deseja adicionar e, em seguida, adicione o arquivo usando a operação add como faria normalmente. Isso funciona bem para as árvores `doc` e `ports`. A árvore `src` usa o SVN e requer mais cuidado por causa das propriedades `mergeinfo`. Veja o <> para detalhes sobre como executar um MFC. === Como eu acesso people.FreeBSD.org para colocar informações pessoais ou de projeto? O servidor `people.FreeBSD.org` é o mesmo que `freefall.FreeBSD.org`. Basta criar um diretório [.filename]#public_html#. Qualquer coisa que você colocar nesse diretório será automaticamente visível em https://people.FreeBSD.org/[https://people.FreeBSD.org/]. === Onde estão armazenados os arquivos da lista de discussão? As listas de discussão são arquivadas em [.filename]#/local/mail# na `freefall.FreeBSD.org`. === Eu gostaria de ser mentor de um novo committer. Qual processo eu preciso seguir? Consulte o documento https://www.freebsd.org/internal/new-account/[Novo Procedimento para Criação de Conta] nas páginas internas. [[benefits]] == Benefícios e vantagens para os Commiters do FreeBSD [[benefits-recognition]] === Reconhecimento O reconhecimento como engenheiro de software competente é o valor mais duradouro. Além disso, ter a chance de trabalhar com algumas das melhores pessoas que todos os engenheiros sonham em conhecer é um grande privilégio! [[benefits-freebsdmall]] === FreeBSD Mall Os committers do FreeBSD podem obter um conjunto gratuito de 4-CDs ou DVDs da http://www.freebsdmall.com[FreeBSD Mall, Inc.] em conferências. [[benefits-irc]] === IRC Além disso, os desenvolvedores podem solicitar um "cloaked hostmask" para sua conta na rede Freenode de IRC na forma de `freebsd/developer/_nome_na_freefall_` ou `freebsd/developer/_nome_no_NickServ_`. Para solicitar uma máscara, envie um e-mail para mailto:irc@FreeBSD.org[irc@FreeBSD.org] com o nome da sua hostmask solicitada e nome da conta no NickServ. [[benefits-gandi]] === `Gandi.net` A Gandi fornece hospedagem de sites, computação em nuvem, registro de domínio e serviços de certificados X.509. A Gandi oferece um desconto E-rate para todos os desenvolvedores do FreeBSD. Envie e-mail para mailto:non-profit@gandi.net[non-profit@gandi.net] usando o seu endereço de e-mail `@freebsd.org` e indique o seu identificador no Gandi. diff --git a/documentation/content/pt-br/articles/mailing-list-faq/_index.adoc b/documentation/content/pt-br/articles/mailing-list-faq/_index.adoc index c96b9311ef..70bad0359c 100644 --- a/documentation/content/pt-br/articles/mailing-list-faq/_index.adoc +++ b/documentation/content/pt-br/articles/mailing-list-faq/_index.adoc @@ -1,175 +1,175 @@ --- title: Perguntas Frequentes Sobre as Listas de Discussão do FreeBSD authors: - author: Projeto de Documentação do FreeBSD copyright: 2004-2005 Projeto de Documentação do FreeBSD trademarks: [] --- = Perguntas Frequentes Sobre as Listas de Discussão do FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/mailing-list-faq/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Resumo -Esta é a FAQ para as listas de discussão do FreeBSD. Se você está interessado em ajudar este projeto, envie um email para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de discussão do projeto de documentação do FreeBSD]. A última versão deste documento está sempre disponível no link:.[Servidor Web do Projeto FreeBSD]. Ele também poderá ser obtido como um grande e único arquivo link:.[HTML] por meio de HTTP ou como texto puro, PostScript, PDF, etc. a partir do https://download.freebsd.org/ftp/doc/[Servidor FTP do FreeBSD]. Você também poderá querer https://www.FreeBSD.org/search/[Pesquisar na FAQ]. +Esta é a FAQ para as listas de discussão do FreeBSD. Se você está interessado em ajudar este projeto, envie um email para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de discussão do projeto de documentação do FreeBSD]. A última versão deste documento está sempre disponível no link:.[Servidor Web do Projeto FreeBSD]. Ele também poderá ser obtido como um grande e único arquivo link:.[HTML] por meio de HTTP ou como texto puro, PostScript, PDF, etc. a partir do https://download.freebsd.org/doc/[Servidor FTP do FreeBSD]. Você também poderá querer https://www.FreeBSD.org/search/[Pesquisar na FAQ]. ''' toc::[] [[introduction]] == Introdução Como é comum com as FAQs, este documento objetiva cobrir as perguntas feitas com mais frequência a respeito das listas de discussão do FreeBSD (e claro responde-las!). Embora originalmente intencionada a reduzir o tráfego e evitar que as mesmas velhas perguntas fossem enviadas várias e várias vezes, as FAQs se tornaram reconhecidamente uma fonte de informações valiosas. Este documento tenta representar um consenso da comunidade, e como tal nunca poderá realmente ser __oficial__. Entretanto, se você encontrar erros técnicos neste documento, ou se tiver sugestões sobre itens que devam ser adicionados, por favor submeta um PR, ou envie um email para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de discussão de documentação do projeto FreeBSD]. Obrigado. === Qual é o propósito das listas de discussão do FreeBSD? As listas de discussão do FreeBSD servem como um canal primário de comunicação para a comunidade FreeBSD, cobrindo muitos tópicos diferentes e áreas de interesse da comunidade. === Quem é o publico das listas de discussão do FreeBSD? Isto depende da premissa de cada lista. Algumas listas são mais orientadas a desenvolvedores; outras para a comunidade FreeBSD como um todo. Por favor veja http://lists.FreeBSD.org/mailman/listinfo[esta lista] para o resumo atual. === As listas de discussão do FreeBSD são abertas para a participação de qualquer pessoa? Novamente, isto dependerá das regras de cada lista. Por favor leia o objetivo da lista antes de postar, e respeite estes objetivos quando você postar. Isto ajudará a todos os participantes a terem uma experiência melhor com as listas. Se após ler as listas acima você ainda não souber para qual delas enviar a sua pergunta, provavelmente você deverá postar na lista freebsd-questions (mas antes, veja abaixo). Note também que as listas de discussão tradicionalmente tem estado abertas para postagens de não assinantes. Isto foi uma escolha deliberada, para fazer com o engajamento na comunidade FreeBSD seja um processo mais simples, e para encorajar o compartilhamento aberto de ideias. Entretanto, devido ao abuso de alguns indivíduos, algumas listas possuem agora políticas em os posts de não assinantes devem ser aprovados manualmente para ter certeza de que são apropriados. === Como posso me inscrever? Você pode usar http://lists.FreeBSD.org/mailman/listinfo[a interface web do Mailman] para se inscrever em qualquer uma das listas públicas. === Como cancelo minha inscrição? Você pode usar a mesma interface acima; ou, você pode seguir as instruções no rodapé de cada mensagem enviada pela lista. Por favor não envie mensagens de cancelamento de inscrição diretamente para as listas públicas. Primeiro, você não alcançará seu objetivo, e segundo, você irritará os outros assinantes da lista, e provavelmente você será retaliado. Este é um erro clássico ao usar as listas de discussão; por favor tente evitar isso. === O histórico da listas está disponível? Sim. Os históricos das mensagens, agrupadas por tópicos de conversa, estão disponíveis http://docs.FreeBSD.org/mail/[aqui]. === As listas de discussão estão disponíveis em um formato sumarizado (digest)? Sim. Veja a http://lists.FreeBSD.org/mailman/listinfo[interface web do Mailman]. [[etiquette]] == Etiqueta em Listas de Discussão A participação em listas de discussão, assim como a participação em qualquer comunidade, requer uma base comum para comunicação. Por favor envie apenas postagens apropriadas, e siga regras comuns de etiqueta. === O que devo fazer antes de postar? Você já deu o passo mais importante ao ler este documento. Entretanto, se você é novo no FreeBSD, você primeiro precisa se familiarizar com o software, e a história social que o envolve lendo os numerosos https://www.FreeBSD.org/docs/books/[livros e artigos] que estão disponíveis. Itens de interesse particular incluem o documento extref:{faq}[Perguntas Frequentes do FreeBSD (FAQ)], o extref:{handbook}[Handbook do FreeBSD], e os artigos extref:{freebsd-questions-article}[Como obter melhores resultados na lista de discussão FreeBSD-questions], extref:{explaining-bsd}[Explicando o BSD], e extref:{new-users}[Primeiros passos no FreeBSD]. É sempre considerado errado fazer uma pergunta que já foi respondida nos documentos acima. Isto não é porque os voluntários que trabalham neste projeto são pessoas particularmente más, mas depois de um certo número de vezes respondendo às mesmas perguntas repetidas vezes, a frustração começa a surgir. Isto é particularmente verdadeiro se houver uma resposta existente para uma pergunta que já está disponível. Tenha sempre em mente que quase todo o trabalho feito no FreeBSD é feito por voluntários, e que somos apenas humanos. === O que constitui uma postagem inadequada? * As mensagens devem estar de acordo com as regras da lista de discussão. * Ataques pessoais são desencorajados. Como bons net-cidadãos, devemos tentar nos manter com altos padrões de comportamento. * Spam não é permitido, nunca. As listas de discussão são administradas ativamente para banir os infratores dessa regra. === O que é considerado etiqueta apropriada ao postar nas listas de discussão? * Por favor, use quebra de linha automática em 75 caracteres, pois nem todo mundo usa clientes de email em uma interface gráfica. * Por favor, respeite o fato de que a largura de banda não é infinita. Nem todo mundo lê e-mails através de conexões de alta velocidade, então se sua postagem envolve algo como o conteúdo de um arquivo como o [.filename]#config.log# ou um extenso stack trace, por favor considere colocar essas informações em algum lugar e apenas fornecer uma URL para eles. Lembre-se, também, de que essas postagens serão arquivadas indefinidamente, de modo que postagens enormes simplesmente aumentarão o tamanho dos arquivos muito depois que o propósito deles tiver expirado. * Formate a sua mensagem para que fique legível e, POR FAVOR, NÃO GRITE !!!!! Não subestime o efeito que uma mensagem de correio mal formatada tem, e não apenas nas listas de discussão do FreeBSD. Sua mensagem de e-mail é tudo o que as pessoas veem de você e, se estiver mal formatada, mal grafada, cheia de erros ou tiver muitos pontos de exclamação, isso dará às pessoas uma má impressão de você. * Por favor, use uma linguagem humana apropriada para uma lista de discussão específica. Muitas listas de discussão que não utilizam o idioma inglês estão https://www.FreeBSD.org/community/mailinglists/[disponíveis]. + Para os que não são, nós apreciamos que muitas pessoas não falam inglês como sua primeira língua, e tentamos fazer concessões para isso. Considera-se uma forma particularmente pobre criticar falantes não nativos por erros ortográficos ou gramaticais. O FreeBSD tem um excelente histórico neste aspecto; por favor, ajude-nos a manter essa tradição. * Por favor, use um Mail User Agent (MUA) compatível com os padrões. Muitas mensagens mal formatadas vêm de http://www.lemis.com/grog/email/email.php[clientes de email ruins ou mal-configurados]. Os seguintes clientes de email são conhecidos por enviar mensagens mal formatadas sem que você saiba sobre elas: ** exmh ** Microsoft(R) Exchange ** Microsoft(R) Outlook(R) + Tente não usar MIME: muitas pessoas usam clientes de email que não se dão muito bem com MIME. * Verifique se o seu horário e fuso horário estão definidos corretamente. Isso pode parecer um pouco bobo, já que sua mensagem ainda chegará na lista, mas muitas das pessoas nestas listas recebem centenas de mensagens por dia. Eles frequentemente classificam as mensagens recebidas por assunto e por data, e se sua mensagem não vier antes da primeira resposta, eles podem assumir que eles perderam a mensagem e não se darão ao trabalho de procurar. * Muitas das informações que você precisará fornecer referem-se a saída de programas, como man:dmesg[8], ou mensagens do console, que geralmente aparecem no [.filename]#/var/log/messages#. Não tente copiar essa informação digitando-a novamente; Isso será não só um sofrimento real, mas você é provavelmente irá cometer um erro. Para enviar o conteúdo do arquivo de log, faça uma cópia do arquivo e use um editor para reduzi-lo às informações relevantes ou copie e cole na sua mensagem. Para a saída de programas como `dmesg`, redirecione a saída para um arquivo e inclua-o. Por exemplo, + [source,shell] .... % dmesg > /tmp/dmesg.out .... + Isso redireciona as informações para o arquivo [.filename]#/tmp/dmesg.out#. * Ao usar o recurso de copiar e colar, lembre-se de que algumas dessas operações manipulam incorretamente suas mensagens. Isto é particularmente preocupante ao postar conteúdo de [.filename]#Makefiles#, onde o `tab` é um caractere significativo. Este é um problema muito comum, e muito chato, com envios para o https://www.FreeBSD.org/support/[banco de dados de Relatórios de Problemas]. Arquivos [.filename]#Makefiles# com tabs alterados para espaços, ou a chata sequência de escape `=3B`, cria um grande agravamento para os committers. === Qual é a consideração de etiqueta especial ao responder a uma postagem existente nas listas de discussão? * Por favor, inclua o texto relevante da mensagem original. Reduza-a ao mínimo, mas não exagere. Ela deverá permitir que alguém que não leu a mensagem original entenda do que você está falando. + Isso é especialmente importante para postagens do tipo "sim, também vejo isso", em que a postagem inicial era de dezenas ou centenas de linhas. * Use alguma técnica para identificar qual texto veio da mensagem original e qual texto você adicionou. Uma convenção comum é prefixar com "`>`" a mensagem original. Deixando espaço em branco após o "`>`" e deixando linhas vazias entre o seu texto e o texto original, ambos tornam o resultado mais legível. * Por favor, certifique-se de que as atribuições do texto que você está citando estão corretas. As pessoas podem ficar ofendidas se você atribuir palavras a elas que elas mesmas não escreveram. * Por favor não faça `top post`. Com isso, queremos dizer que, se você estiver respondendo a uma mensagem, coloque suas respostas após o texto copiado na sua resposta. + ** R: Porque inverte o fluxo lógico da conversa. ** P: Por que a publicação superior é desaprovada? + (Obrigado Randy Bush pela piada.) [[recurring]] == Tópicos recorrentes nas listas de discussão A participação nas listas de discussão, como a participação em qualquer comunidade, requer uma base comum para comunicação. Muitas das listas de discussão pressupõem um conhecimento da história do Projeto. Em particular, há certos tópicos que parecem ocorrer regularmente aos recém-chegados à comunidade. É da responsabilidade de cada usuário garantir que suas mensagens não se enquadrem em uma dessas categorias. Ao fazer isso, você ajudará as listas de discussão a permanecerem no tópico e, provavelmente, e provavelmente se salve de ser queimado no processo. O melhor método para evitar isso é familiarizar-se com os http://docs.FreeBSD.org/mail/[arquivos da lista de discussão], para ajudar você a entender o histórico do que aconteceu antes. E para isso, a https://www.FreeBSD.org/search/#mailinglists[interface de pesquisa das listas de discussões ] é inestimável. (Se esse método não produzir resultados úteis, por favor, complemente-o com uma pesquisa no seu mecanismo de busca favorito). Ao se familiarizar com os arquivos, você não apenas aprenderá os tópicos que foram discutidos anteriormente, mas também como a discussão tende a prosseguir nessa lista, quem são os participantes e quem é o público-alvo. Estas são sempre boas coisas para saber antes de postar em qualquer lista de discussão, não apenas em uma lista de discussão do FreeBSD. Não há dúvida de que os arquivos são bastante extensos e algumas questões recorrem com maior frequência do que outras, às vezes como acompanhamentos em que a linha de assunto não reflete mais precisamente o novo conteúdo. No entanto, o fardo está em você, o usuário, para fazer sua lição de casa para ajudar a evitar esses tópicos recorrentes. [[bikeshed]] == O que é um "Bikeshed" (Garagem de bicicletas)? Literalmente, uma `Bikeshed` é um pequeno abrigo ao ar livre no qual se pode armazenar o meio de transporte de duas rodas. No entanto, no jargão do FreeBSD, o termo refere-se a tópicos que são simples o suficiente para que (quase) qualquer um possa opinar sobre ele, e geralmente (quase) todos o fazem. A gênese desse termo é explicada com mais detalhes extref:{faq}[neste documento, bikeshed-painting]. Você simplesmente deve ter um conhecimento prático deste conceito antes de postar em qualquer lista de discussão do FreeBSD. Mais genericamente, um Bikeshed é um tópico que tenderá a gerar Meta-discussões imediatas e interações hostis com usuários você ainda nem conhece. Por favor, ajude-nos a manter as listas de discussão úteis para o maior numero possível de pessoas evitando Bikesheds sempre que puder. Obrigado. [[acknowledgments]] == Agradecimentos Greg Lehey mailto:grog@FreeBSD.org[grog@FreeBSD.org]:: Autor original da maior parte do material sobre etiqueta nas listas de discussão, retirada do artigo sobre extref:{freebsd-questions-article}[Como para obter os melhores resultados da lista de discussão FreeBSD-questions]. Mark Linimon mailto:linimon@FreeBSD.org[linimon@FreeBSD.org]:: Pela criação do rascunho deste FAQ. diff --git a/documentation/content/pt-br/books/faq/_index.adoc b/documentation/content/pt-br/books/faq/_index.adoc index 53200e6813..ac194b01fa 100644 --- a/documentation/content/pt-br/books/faq/_index.adoc +++ b/documentation/content/pt-br/books/faq/_index.adoc @@ -1,2428 +1,2428 @@ --- title: Perguntas freqüentes para o FreeBSD 11.X e 12.X authors: trademarks: [] isIndex: true --- = Perguntas freqüentes para o FreeBSD {rel2-relx} e {rel-relx} :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/faq/ :rel-numbranch: 4 :rel-head: 14-CURRENT :rel-head-relx: 14.X :rel-head-releng: head/ :rel-relx: 13.X :rel-stable: 13-STABLE :rel-releng: stable/13/ :rel-relengdate: December 2018 :rel2-relx: 12.X :rel2-stable: 12-STABLE :rel2-releng: stable/12/ :rel2-relengdate: December 2018 :rel3-relx: 11.X :rel3-stable: 11-STABLE :rel3-releng: stable/11/ :rel3-relengdate: October 2016 ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Resumo Estas são as Perguntas Mais Frequentes (FAQ) para as versões do FreeBSD {rel-relx} e {rel2-relx}. Todos os esforços foram feitos para tornar este FAQ o mais informativo possível; Se você tiver alguma sugestão de como ele pode ser melhorado, envie-a para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de discussão do projeto de documentação do FreeBSD]. -A versão mais recente deste documento está sempre disponível no extref:{faq}[website do FreeBSD]. Ela também pode ser baixada como um grande arquivo link:.[HTML] por HTTP ou em uma grande variedade de outros formatos a partir do https://download.freebsd.org/ftp/doc/[servidor de FTP do projeto FreeBSD]. +A versão mais recente deste documento está sempre disponível no extref:{faq}[website do FreeBSD]. Ela também pode ser baixada como um grande arquivo link:.[HTML] por HTTP ou em uma grande variedade de outros formatos a partir do https://download.freebsd.org/doc/[servidor de FTP do projeto FreeBSD]. ''' toc::[] == Introdução === O que é o FreeBSD? O FreeBSD é um sistema operacional moderno para desktops, laptops, servidores e sistemas embarcados, com suporte para um grande número de https://www.FreeBSD.org/platforms/[plataformas]. Ele é baseado no sistema "4.4BSD-Lite" da U.C. de Berkeley, com algumas melhorias oriundas do "4.4BSD-Lite2". Ele também se baseia indiretamente no port para i386(TM) feito por William Jolitz do sistema "Net/2" da U.C. Berkeley, conhecido como "386BSD", embora muito pouco do código original do 386BSD ainda esteja presente. O FreeBSD é usado por empresas, provedores de serviços de Internet, pesquisadores, profissionais da computação, estudantes e usuários domésticos em todo o mundo em seu trabalho, educação e recreação. Para informações mais detalhadas sobre o FreeBSD, consulte o extref:{handbook}[Manual do FreeBSD]. [[FreeBSD-goals]] === Qual é o objetivo do projeto FreeBSD? O objetivo do Projeto FreeBSD é fornecer um sistema operacional de propósito geral estável e rápido que possa ser usado para qualquer propósito sem restrições. === A licença do FreeBSD tem alguma restrição? Sim. Essas restrições não controlam como o código é usado, mas como tratar o próprio projeto FreeBSD. A licença em si está disponível em https://www.FreeBSD.org/copyright/freebsd-license/[licença] e pode ser resumida da seguinte forma: * Não reivindique que você escreveu o sistema. * Não nos processe se ele quebrar. * Não remova ou modifique a licença. Muitos de nós têm um investimento significativo no projeto e certamente não nos importaríamos com uma pequena compensação financeira de vez em quando, mas nós definitivamente não insistimos nisso. Acreditamos que a nossa primeira e principal "missão" é fornecer código a todos os participantes, e para qualquer finalidade, para que o código obtenha o maior uso possível e forneça o maior benefício possível. Este, acreditamos, é um dos objetivos mais fundamentais do Software Livre e um dos que apoiamos entusiasticamente. O código em nosso repositório de código-fonte que se enquadra na https://www.FreeBSD.org/copyright/COPYING[Licença Pública Geral GNU (GPL)] ou na https://www.FreeBSD.org/copyright/COPYING.LIB[Licença Pública Geral da Biblioteca GNU (LGPL)] vem com algumas restrições adicionais, ainda que sejam no sentido de forçar o acesso, em vez do habitual oposto. Devido às complexidades adicionais que podem surgir no uso comercial de um software GPL, nós nos esforçamos para substituir tais softwares por outros sob a https://www.FreeBSD.org/copyright/freebsd-license/[Licença FreeBSD] que é menos restritiva, sempre que possível. === O FreeBSD pode substituir meu sistema operacional atual? Para a maioria das pessoas, sim. Mas esta questão não é assim tão simples. A maioria das pessoas não usa um sistema operacional. Elas usam aplicativos. São os aplicativos que realmente usam o sistema operacional. O FreeBSD é projetado para fornecer um ambiente robusto e completo para aplicativos. Ele suporta uma grande variedade de navegadores da web, pacotes de escritório, leitores de e-mail, programas gráficos, ambientes de programação, servidores de rede e muito mais. A maioria destes aplicativos pode ser gerenciada através da https://www.FreeBSD.org/ports/[Coleção de Ports]. Se um aplicativo estiver disponível apenas para um determinado sistema operacional, esse sistema operacional não poderá ser substituído. No entanto é provável que exista um aplicativo muito semelhante no FreeBSD. Seja como um sólido servidor corporativo, um servidor de Internet ou ainda uma confiável estação de trabalho, o FreeBSD quase certamente fará tudo o que você precisa. Muitos usuários de computador ao redor do mundo, incluindo novatos e experientes administradores UNIX(TM), usam o FreeBSD como seu único sistema operacional de desktop. Os usuários que migrarem para o FreeBSD vindos de outro ambiente UNIX(TM)-like irão achar o FreeBSD bastante similar. Os usuários de Windows(TM) e do Mac OS(TM) podem se interessar em usar o https://www.furybsd.org/[FuryBSD], https://ghostbsd.org/[GhostBSD] ou https://www.midnightbsd.org/[MidnightBSD], três distribuições desktop baseadas no FreeBSD. Os usuários que não estão habituados ao uso de sistemas UNIX(TM) devem investir algum tempo adicional aprendendo a maneira de fazer as coisas no UNIX(TM). Este FAQ e o extref:{handbook}[Manual do FreeBSD ] são excelentes lugares para iniciar. === Por que ele é chamado de FreeBSD? * Pode ser usado gratuitamente, até mesmo por usuários comerciais. * O código fonte completo do sistema operacional está disponível gratuitamente, e foram colocadas restrições mínimas sobre seu uso, distribuição e incorporação em outro trabalho (comercial ou não comercial). * Qualquer pessoa que tenha uma melhoria ou correção de bug está livre para enviar seu código e para adicioná-lo ao repositório de código-fonte (sujeito a uma ou duas provisões óbvias). Vale ressaltar que a palavra "free" está sendo usada de duas formas aqui: uma que significa "sem custo" (grátis) e a outra que significa "faça o que quiser" (Livre). Fora uma ou duas coisas que você _não pode_ fazer com o código do FreeBSD, por exemplo, fingir que você o escreveu, você pode realmente fazer o que quiser com ele. === Quais são as diferenças entre o FreeBSD, o NetBSD, o OpenBSD e os outros sistemas operacionais BSD de código aberto? O James Howard escreveu uma boa explicação da história e das diferenças entre os vários projetos BSD, chamada https://jameshoward.us/archive/the-bsd-family-tree/[A árvore genealógica do BSD], a qual é uma boa forma de responder a esta pergunta. Algumas das informações estão desatualizadas, mas a parte da história em particular permanece precisa. A maioria dos BSDs compartilha patches e códigos, até hoje. Todos os BSDs descendem dos mesmos ancestrais. Os objetivos de design do FreeBSD estão descritos em <>, acima. Os objetivos de design dos outros BSDs mais populares podem ser resumidos da seguinte forma: * O OpenBSD visa a segurança do sistema operacional acima de tudo. A equipe do OpenBSD escreveu o man:ssh[1] e o man:pf[4], os quais foram portados para o FreeBSD. * O NetBSD pretende ser facilmente portado para outras plataformas de hardware. * O DragonFly BSD é um fork do FreeBSD 4.8 o qual desenvolveu muitas características interessantes ao longo dos anos, incluindo o sistema de arquivos HAMMER e o suporte para "vkernels" no modo de usuário. === Qual é a última versão do FreeBSD? A qualquer momento no desenvolvimento do FreeBSD, podem existir vários branches paralelos. As releases 12._X_ são geradas a partir da branch _12-STABLE_ e as releases 11._X_ são geradas a partir do branch _11-STABLE_. Até o lançamento da versão 12.0, a série 11._X_ era a conhecida como _-STABLE_. No entanto, a partir da 13._X_, a branch 11._X_ será designada para um status de "suporte estendido" e passará a receber apenas correções para problemas maiores, como as correções relacionadas à segurança. As releases são liberadas a <>. Embora muitas pessoas se mantenham mais que isso por meio do código fonte do FreeBSD (veja as perguntas em <> e <> ), esta periodicidade está mais para um compromisso, já que o código fonte é um alvo em movimento. Mais informações sobre as releases do FreeBSD podem ser encontradas na https://www.FreeBSD.org/releng/#release-build[página de Engenharia de Releases] e em man:release[7]. === O que é o FreeBSD-CURRENT? O extref:{handbook}updating-upgrading[FreeBSD-CURRENT, current] é a versão de desenvolvimento do sistema operacional, que no devido tempo se tornará o novo branch FreeBSD-STABLE. Como tal, ele é recomendado apenas para os desenvolvedores que trabalham no sistema e usuários amadores obstinados. Consulte a extref:{handbook}updating-upgrading[seção relevante, current] no extref:{handbook}[Handbook] para detalhes sobre como executar o _-CURRENT_. Usuários não familiarizados com o FreeBSD não devem usar o FreeBSD-CURRENT. Este branch às vezes evolui muito rapidamente e, devido a um erro, pode ser difícil de compilá-lo às vezes. Espera-se que as pessoas que usam o FreeBSD-CURRENT possam analisar, depurar e reportar problemas. === Qual é o conceito do FreeBSD-STABLE? O _FreeBSD-STABLE_ é o branch de desenvolvimento a partir do qual os releases principais são feitos. Mudanças entram nesta branch em um ritmo mais lento e com a suposição geral de que eles foram testados primeiro no FreeBSD-CURRENT. No entanto, a qualquer momento, o código fonte para o FreeBSD-STABLE pode ou não ser adequado para uso geral, devido a descoberta de bugs e/ou outros casos específicos que ainda não foram encontrados no FreeBSD-CURRENT. Usuários que não possuem recursos para realizar testes devem, ao invés dessa, executar a release mais recente do FreeBSD. O _FreeBSD-CURRENT_, por outro lado, tem sido uma linha ininterrupta desde que o 2.0 foi lançado. Para obter informações mais detalhadas sobre as branches, consulte "extref:{releng}[Engenharia de Releases do FreeBSD: Criando uma Release Branch, rel-branch]", o status dos branches e o cronograma para releases futuros podem ser encontrados na página https://www.FreeBSD.org/releng[Release Engineering Information]. -A versão https://download.FreeBSD.org/ftp/releases/amd64/amd64/12.1-RELEASE/[12.1] é a última release da branch _12-STABLE_; ela foi lançada em Novembro de 2019. A versão https://download.FreeBSD.org/ftp/releases/amd64/amd64/11.3-RELEASE/[11.3] é a release mais recente da branch _11-STABLE_; e foi lançada em Julho de 2019. +A versão https://download.FreeBSD.org/releases/amd64/amd64/12.1-RELEASE/[12.1] é a última release da branch _12-STABLE_; ela foi lançada em Novembro de 2019. A versão https://download.FreeBSD.org/releases/amd64/amd64/11.3-RELEASE/[11.3] é a release mais recente da branch _11-STABLE_; e foi lançada em Julho de 2019. === Quando são realizados os lançamentos de novas versões do FreeBSD? A Equipe de Engenharia de Releases (Release Engineering Team) mailto:re@FreeBSD.org[re@FreeBSD.org] lança uma nova versão principal do FreeBSD a cada 18 meses e uma nova versão secundária a cada 8 meses, em média. As datas de lançamento são anunciadas com bastante antecedência, para que as pessoas que trabalham no sistema saibam quando seus projetos precisam ser finalizados e testados. Um período de teste precede cada lançamento, para garantir que a adição de novos recursos não comprometa a estabilidade do lançamento. Muitos usuários consideram este cuidado como uma das melhores coisas do FreeBSD, apesar de que a espera para que todas as novidades mais recentes sejam disponibilizadas no _-STABLE_ possa ser um pouco frustrante. Maiores informações sobre o processo de engenharia de releases (incluindo a programação das releases futuros) podem ser encontradas na página https://www.FreeBSD.org/releng/[engenharia de release] no site do FreeBSD. Para aquelas pessoas que precisam ou querem um pouco mais de emoção, os snapshots binários são disponibilizados semanalmente, como discutido acima. === Quando são feitos os snapshots do FreeBSD? As https://www.FreeBSD.org/snapshots/[snapshot] releases do FreeBSD são disponibilizadas com base no estado atual das branchs _-CURRENT_ e _-STABLE_. Os objetivos por trás de cada release de snapshot são: * Testar a versão mais recente do software de instalação. * Para que as pessoas que gostariam de executar o _-CURRENT_ ou o _-STABLE_ mas que não têm tempo ou largura de banda para acompanhá-lo no dia-a-dia tenham uma maneira fácil de instalá-las em seus sistemas. * Para preservar um ponto de referência fixo para o código em questão, apenas no caso de quebrarmos algo de forma muito seria depois. (Embora o Subversion normalmente previna que uma coisa horrível como esta ocorra.) * Para garantir que todos os novos recursos e correções que precisam de testes tenham contato o maior número possível de testadores em potencial. Não temos a pretensão de que qualquer snapshot _-CURRENT_ possa ser considerado com "qualidade de produção" para qualquer finalidade. Se você necessita de um sistema estável e totalmente testado, limite-se ao uso das releases completas. As snapshots releases estão disponíveis em https://www.FreeBSD.org/snapshots/[snapshot]. Os snapshots oficiais são gerados regularmente para todas as branchs ativamente desenvolvidas. === Quem é responsável pelo FreeBSD? As principais decisões relativas ao projeto FreeBSD, tais como a direção geral do projeto e quem tem permissão para adicionar código ao repositório de código fonte, são feitas por meio de um https://www.FreeBSD.org/administration/#t-core[core team] de 9 pessoas. Existe uma equipe muito maior, com mais de 350 extref:{contributors}[committers, staff-committers] que estão autorizados a fazer alterações diretamente na árvore de fontes do FreeBSD. No entanto, a maioria das alterações não-triviais é discutida com antecedência nas <>, e não há restrições sobre quem pode participar da discussão. === Onde posso obter o FreeBSD? -Todas releases importantes do FreeBSD estão disponíveis via FTP anônimo no https://download.FreeBSD.org/ftp/releases/[site FTP do FreeBSD]: +Todas releases importantes do FreeBSD estão disponíveis via FTP anônimo no https://download.FreeBSD.org/releases/[site FTP do FreeBSD]: -* O último release da série _12-STABLE_, o 12.1-RELEASE, pode ser encontrado no https://download.FreeBSD.org/ftp/releases/amd64/amd64/12.1-RELEASE/[diretório 12.1-RELEASE]. +* O último release da série _12-STABLE_, o 12.1-RELEASE, pode ser encontrado no https://download.FreeBSD.org/releases/amd64/amd64/12.1-RELEASE/[diretório 12.1-RELEASE]. * Mensalmente são produzidos https://www.FreeBSD.org/snapshots/[snapshot] releases para as branchs <> e <>, as quais destinam-se primariamente ao uso por parte dos desenvolvedores e testadores. -* O último release da série _11-STABLE_, o 11.3-RELEASE, pode ser encontrado no https://download.FreeBSD.org/ftp/releases/amd64/amd64/11.3-RELEASE/[diretório 11.3-RELEASE]. +* O último release da série _11-STABLE_, o 11.3-RELEASE, pode ser encontrado no https://download.FreeBSD.org/releases/amd64/amd64/11.3-RELEASE/[diretório 11.3-RELEASE]. Informações sobre como obter o FreeBSD em CD, DVD e outras mídias podem ser encontradas no extref:{handbook}mirrors[Handbook, mirrors]. === Como acesso o banco de dados dos Relatórios de Problemas? O banco de dados com os Relatórios de Problemas contendo todas as solicitações de mudança enviadas pelos nossos usuários pode ser consultado usando nossa interface web de https://bugs.FreeBSD.org/search/[consulta] de PRs. A https://www.FreeBSD.org/support/bugreports/[interface web de envio de relatórios de problemas] pode ser usada para enviar relatórios de problemas através de um navegador. Antes de enviar um relatório de problema, leia extref:{problem-reports}[Escrevendo Relatórios de Problemas do FreeBSD], um artigo sobre como escrever bons relatórios de problemas. == Documentação e Suporte === Quais os livros existentes sobre o FreeBSD? O projeto produz uma ampla gama de documentação, disponível on-line a partir deste link:https://www.FreeBSD.org/docs/[https://www.FreeBSD.org/docs]. === A documentação está disponível em outros formatos, tais como texto simples (ASCII) ou PDF? -Sim. A documentação está disponível em vários formatos diferentes e esquemas de compressão no site FTP do FreeBSD, no diretório https://download.freebsd.org/ftp/doc/[/ftp/doc/]. +Sim. A documentação está disponível em vários formatos diferentes e esquemas de compressão no site FTP do FreeBSD, no diretório https://download.freebsd.org/doc/[/doc/]. A documentação é categorizada de várias maneiras diferentes. Que incluem: * O nome do documento, tais como como `faq` ou `handbook`. * A linguagem e codificação do documento. Estes são baseados nos nomes de local encontrados sob o diretório [.filename]#/usr/shared/locale# em um sistema FreeBSD. Os idiomas e codificações atuais são os seguintes: + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Nome | Significado |`en_US.ISO8859-1` |Inglês (Estados Unidos) |`bn_BD.ISO10646-1` |Bengali ou Bangla (Bangladesh) |`da_DK.ISO8859-1` |Dinamarquês (Dinamarca) |`de_DE.ISO8859-1` |Alemão (Alemanha) |`el_GR.ISO8859-7` |Grego (Grécia) |`es_ES.ISO8859-1` |Espanhol (Espanha) |`fr_FR.ISO8859-1` |Francês (França) |`hu_HU.ISO8859-2` |Húngaro (Hungria) |`it_IT.ISO8859-15` |Italiano (Itália) |`ja_JP.eucJP` |Japonês (Japão, codificação EUC) |`ko_KR.UTF-8` |Coreano (Coreia, codificação UTF-8) |`mn_MN.UTF-8` |Mongol (Mongólia, codificação UTF-8) |`nl_NL.ISO8859-1` |Holandês (Holanda) |`pl_PL.ISO8859-2` |Polonês (Polônia) |`pt_BR.ISO8859-1` |Português (Brasil) |`ru_RU.KOI8-R` |Russo (Rússia, codificação KOI8-R) |`tr_TR.ISO8859-9` |Turco (Turquia) |`zh_CN.UTF-8` |Chinês Simplificado (China, codificação UTF-8) |`zh_TW.UTF-8` |Chinês Tradicional (Taiwan, codificação UTF-8) |=== + [NOTE] ==== Alguns documentos podem não estar disponíveis em todos os idiomas. ==== * O formato do documento. Produzimos a documentação em vários formatos de saída diferentes. Cada formato tem suas próprias vantagens e desvantagens. Alguns formatos são mais adequados para leitura on-line, enquanto outros estão formatados para serem esteticamente agradáveis quando impressos em papel. A disponibilização da documentação em diversos formatos garante que os nossos leitores possam ler as partes nas quais estão interessados, seja em seu monitor ou em papel após imprimi-los documentos. Os formatos disponíveis atualmente são: + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Formato | Significado |`html-split` |Uma coleção de pequenos arquivos HTML vinculados. |`html` |Um grande arquivo HTML contendo o documento inteiro |`pdf` |Formato de documento portátil da Adobe |`txt` |Texto simples |=== * O esquema de compactação e empacotamento. .. Onde o formato é `html-split`, os arquivos são agrupados usando man:tar[1]. O arquivo resultante [.filename]#.tar# é então compactado usando os esquemas de compactação detalhados no próximo passo. .. Todos os outros formatos geram um único arquivo. Por exemplo, [.filename]#article.pdf#, [.filename]#book.html# e assim por diante. + Esses arquivos são então compactados usando os esquemas de compactação `zip` ou `bz2`. O comando man:tar[1] pode ser usado para descompactar esses arquivos. + Portanto, a versão PDF do Handbook, compactada usando `bzip2` será armazenada em um arquivo chamado [.filename]#book.ps.bz2# no diretório [.filename]#handbook/#. Depois de escolher o formato e o mecanismo de compactação, baixe os arquivos compactados, descompacte-os e copie os documentos para um lugar apropriado. Por exemplo, a versão split HTML do FAQ, compactada usando man:bzip2[1], pode ser encontrada em [.filename]#doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2# Para baixar e descompactar esse arquivo, digite: [source,shell] .... -# fetch https://download.freebsd.org/ftp/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 +# fetch https://download.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 # tar xvf book.html-split.tar.bz2 .... Se o arquivo estiver compactado, o tar detectará automaticamente o formato apropriado e o descompactará corretamente, resultando em uma coleção de arquivos [.filename]#.html#. O principal deles é chamado [.filename]#index.html#, que conterá o sumário, o material introdutório e os links para as outras partes do documento. === Onde encontro informações sobre as listas de discussão do FreeBSD? Quais grupos de notícias do FreeBSD estão disponíveis? Consulte as seções do Handbook sobre as extref:{handbook}eresources[listas de discussão, eresources-mail] e sobre os extref:{handbook}eresources[grupos de notícias, eresources-news]. === Existem canais de IRC (Internet Relay Chat) sobre o FreeBSD? Sim, a maioria das redes de IRC hospedam um canal de chat do FreeBSD: * Canal `#FreeBSDhelp` na http://www.efnet.org/index.php[EFNet] é um canal dedicado a ajudar usuários do FreeBSD. * Canal `#FreeBSD` na http://freenode.net/[Freenode] é um canal de ajuda geral com muitos usuários a qualquer horário. É de conhecimento que conversas off-topic acontecem em alguns momentos, mas a prioridade é dada aos usuários com perguntas sobre o FreeBSD. Outros usuários podem ajudar com o básico, consultando o Handbook sempre que possível e fornecendo links para ajudá-lo a aprender mais sobre um determinado tópico. Este é um canal em que a comunicação ocorre primariamente em inglês, embora seja frequentado por usuários de todo o mundo. As pessoas que não são falantes nativas do inglês devem tentar fazer as suas perguntas primeiro em inglês e, em seguida, tentar nos canais `## freebsd-lang` conforme apropriado. * Canal `#FreeBSD` na http://www.dal.net/[DALNET] está disponível em `irc.dal.net` nos EUA e `irc.eu.dal.net` na Europa. * O canal `#FreeBSD` na http://www.undernet.org/[UNDERNET] está disponível em `us.undernet.org` nos EUA e `eu.undernet.org` na Europa. Como é um canal de ajuda, prepare-se para ler os documentos aos quais você for direcionado. * O canal `#FreeBSD` na http://www.rusnet.org.ru/[RUSNET] é um canal de língua russa dedicado a ajudar os usuários do FreeBSD. Este também é um bom lugar para discussões não técnicas. * O canal `#bsdchat` na http://freenode.net/[Freenode] é um canal de idioma chinês tradicional (codificação UTF-8) dedicado a ajudar os usuários do FreeBSD. Este também é um bom lugar para discussões não técnicas. A wiki do FreeBSD tem uma https://wiki.freebsd.org/IRC/Channels[boa lista] dos canais de IRC. Cada um destes canais são distintos e não estão conectados entre si. Como os estilos de bate-papo diferem, experimente cada um deles para encontrar um adequado ao seu estilo de bate-papo. === Existem fóruns na web para discutir o FreeBSD? Os fóruns oficiais do FreeBSD estão localizados em https://forums.FreeBSD.org/[https://forums.FreeBSD.org/]. === Onde posso obter treinamento e suporte comercial para o FreeBSD? A http://www.ixsystems.com[ iXsystems, Inc. ], empresa controladora do http://www.freebsdmall.com/[FreeBSD Mall], fornece http://www.ixsystems.com/support[supporte] comercial para o FreeBSD e TrueOS, e também soluções de desenvolvimento e customização para o FreeBSD. A BSD Certification Group, Inc. fornece certificações de administração do sistema para o DragonFly BSD, FreeBSD, NetBSD e OpenBSD. Consulte http://www.BSDCertification.org[seu site] para maiores informações. Quaisquer outras organizações que forneçam treinamento e suporte devem entrar em contato com o Projeto FreeBSD para serem listadas aqui. == Instalação === Qual plataforma devo baixar? Eu tenho uma CPU compatível com 64 bits Intel, mas eu só encontro amd64. amd64 é o termo que o FreeBSD usa para arquiteturas x86 compatíveis com 64 bits (também conhecidas como "x86-64" ou "x64"). Para a maioria dos computadores modernos você deve usar a opção amd64. Para hardware mais antigo você deve usar o i386. Ao instalar em uma arquitetura não compatível com x86, selecione a plataforma que melhor corresponda ao hardware. === Qual arquivo eu baixo para ter o FreeBSD? Na página https://www.freebsd.org/where/[Como obter o FreeBSD], selecione `[iso]` ao lado da arquitetura que corresponde ao seu hardware. Qualquer um dos itens a seguir pode ser usado: [.informaltable] [cols="1,1", frame="none", options="header"] |=== | arquivo | descrição |[.filename]#disc1.iso# |Contém o suficiente para instalar o FreeBSD e um conjunto mínimo de pacotes. |[.filename]#dvd1.iso# |Semelhante ao [.filename]#disc1.iso#, mas com pacotes adicionais. |[.filename]#memstick.img# |Uma imagem inicializável para se gravar em um pendrive. |[.filename]#bootonly.iso# |Uma imagem mínima e que requer acesso à rede durante a instalação para que possa instalar completamente o FreeBSD. |=== Instruções completas sobre este procedimento e um pouco mais sobre problemas de instalação em geral podem ser encontradas na seção do Handbook extref:{handbook}bsdinstall[sobre instalação do FreeBSD, bsdinstall]. === O que eu faço se a imagem de instalação não inicializar? Isso pode ocorrer caso você não tenha baixado a imagem no modo _binário_ ao usar o FTP. Alguns clientes FTP padronizam seu modo de transferência para _ascii_ e tentam alterar quaisquer caracteres de end-of-line recebidos para corresponder às convenções usadas pelo sistema do cliente. Isso quase invariavelmente corromperá a imagem de inicialização. Verifique checksum SHA-256 da imagem de inicialização baixada: se não estiver _exatamente_ como no servidor, o processo de download pode ter corrompido o arquivo. Ao usar um cliente FTP de linha de comando, digite _binary_ no prompt de comando FTP depois de se conectar ao servidor e antes de iniciar o download da imagem. === Onde estão as instruções para instalar o FreeBSD? As instruções para instalação podem ser encontradas na seção do Handbook extref:{handbook}bsdinstall[sobre instalação do FreeBSD, bsdinstall]. === Como posso criar minha própria versão personalizada ou disco de instalação? Uma mídia customizada de instalação do FreeBSD pode ser criada através da construção de uma release personalizada. Siga as instruções do artigo extref:{releng}[Release Engineering]. === O Windows pode coexistir com o FreeBSD? (específico de x86) Se o Windows(TM) for instalado primeiro, então sim. O gerenciador de boot do FreeBSD irá então inicializar o Windows(TM) e o FreeBSD. Se o Windows(TM) for instalado posteriormente, ela sobrescreverá o gerenciador de inicialização. Se isso acontecer, veja a próxima seção. === Outro sistema operacional destruiu meu Gerenciador de Inicialização. Como faço para recuperá-lo? (específico de x86) Isso depende do gerenciador de inicialização. O menu de seleção de inicialização do FreeBSD pode ser reinstalado usando man:boot0cfg[8]. Por exemplo, para restaurar o menu de inicialização no disco _ada0_: [source,shell] .... # boot0cfg -B ada0 .... O gerenciador de inicialização MBR não interativo pode ser instalado usando man:gpart[8]: [source,shell] .... # gpart bootcode -b /boot/mbr ada0 .... Para situações mais complexas, incluindo discos GPT, consulte man:gpart[8]. === Preciso instalar o código fonte? Em geral, não. Não há nada no sistema base que exija a presença do código fonte para operar. Alguns ports, como o package:sysutils/lsof[], não serão compilados a menos que o código fonte esteja instalado. Em particular, se o port compila um módulo de kernel ou opera diretamente em estruturas de kernel, o código fonte deve ser instalado. === Eu preciso compilar um kernel? Geralmente não. O kernel `GENERIC` fornecido contém todos os drivers que um computador comum precisará. O man:freebsd-update[8], a ferramenta de atualização binária do FreeBSD, não pode atualizar kernels customizados, o que é uma outra razão para se manter com o kernel `GENERIC` sempre que possível. Para computadores com uma quantidade de memória RAM muito limitada, como sistemas embarcados, pode valer a pena compilar um kernel customizado menor contendo apenas os drivers necessários. === Devo usar senhas DES, Blowfish ou MD5 e como eu específico qual tipo meus usuários irão receber? O FreeBSD usa _SHA512_ por padrão. Senhas DES ainda estão disponíveis para compatibilidade com sistemas operacionais que ainda usam um formato de senha menos seguro. O FreeBSD também suporta os formatos de senha Blowfish e MD5. O formato de senha que será usado para novas senhas é controlado pelo recurso de login `passwd_format` no arquivo [.filename]#/etc/login.conf#, que recebe valores de `des`, `blf` (se estiverem disponíveis) ou `md5`. Veja a página de manual man:login.conf[5] para maiores informações sobre as capacidades de login. === Quais são os limites para sistemas de arquivos FFS? Para os sistemas de arquivos FFS, o tamanho máximo é praticamente limitado pela quantidade de memória necessária para executar o man:fsck[8] no sistema de arquivo. O man:fsck[8] requer um bit por fragmento, que com o tamanho de fragmento padrão de 4 KB equivale a 32 MB de memória por TB de disco. Isso significa que nas arquiteturas que limitam os processos userland a 2 GB (por exemplo, i386(TM)), o tamanho máximo do sistema de arquivos que o man:fsck[8] permite operar é de ~ 60 TB. Se não houvesse um limite de memória para o man:fsck[8], o tamanho máximo do sistema de arquivos seria 2 ^ 64 (blocks) * 32 KB => 16 Exa * 32 KB => 512 ZettaBytes. O tamanho máximo de um único arquivo FFS é de aproximadamente 2 PB com o tamanho de bloco padrão de 32 KB. Cada bloco de 32 KB pode apontar para 4096 blocos. Com blocos triplo indiretos, o cálculo é 32 KB * 12 + 32 KB * 4096 + 32 KB * 4096 ^ 2 + 32 KB * 4096 ^ 3. Aumentar o tamanho do bloco para 64 KB aumentará o tamanho máximo do arquivo por um fator de 16. === Por que recebo uma mensagem de erro, readin failed depois de compilar e inicializar um novo kernel? O world (aplicativos e bicliotecas do userland)e o kernel estão fora de sincronia. Isso não é suportado. Certifique-se de usar `make buildworld` e `make build-kernel` para atualizar o kernel. Inicialize o sistema especificando o kernel diretamente no segundo estágio, pressionando qualquer tecla quando o `|` aparecer antes que o utilitário de carga (loader) seja iniciado. === Existe uma ferramenta para realizar tarefas de configuração pós-instalação? Sim. O bsdconfig fornece uma boa interface para configurar o FreeBSD na pós-instalação. == Compatibilidade de Hardware [[compatibility-general]] === Geral ==== Eu quero obter um componente de hardware para o meu sistema FreeBSD. Qual modelo/marca/tipo é o melhor? Isso é discutido continuamente nas listas de discussão do FreeBSD, mas isto é de se esperar, já que o hardware muda tão rapidamente. Leia as Notas de Hardware do FreeBSD https://www.FreeBSD.org/releases/12.1r/hardware/[12.1] ou https://www.FreeBSD.org/releases/11.3r/hardware/[11.3] e pesquise os https://www.FreeBSD.org/search/#mailinglists[arquivos] da lista de discussão antes de perguntar sobre o hardware mais recente e melhor. As chances são de que uma discussão sobre esse tipo de hardware tenha acontecido na semana passada. Antes de comprar um laptop, verifique os arquivos da http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[lista de discussão de questões gerais do FreeBSD], ou possivelmente uma lista de discussão específica para um tipo específico de hardware. ==== Quais são os limites para a memória? O FreeBSD como sistema operacional geralmente suporta tanta memória física (RAM) quanto a disponível na plataforma em que está rodando. Tenha em mente que plataformas diferentes têm limites diferentes para a memória; por exemplo i386(TM) sem PAE suporta no máximo 4 GB de memória (e geralmente menos que isso por causa do espaço de endereçamento PCI) e i386(TM) com PAE suporta no máximo 64 GB de memória. A partir do FreeBSD 10, as plataformas AMD64 suportam até 4 TB de memória física. ==== Por que o FreeBSD reporta menos de 4 GB de memória quando instalado em uma máquina i386? O espaço total de endereços nas máquinas i386(TM) é de 32 bits, o que significa que no máximo 4 GB de memória são endereçáveis (podem ser acessados). Além disso, alguns endereços nesse intervalo são reservados por hardware para diferentes finalidades, por exemplo, para usar e controlar dispositivos PCI, para acessar a memória de vídeo e assim por diante. Portanto, a quantidade total de memória utilizável pelo sistema operacional para o seu kernel e aplicativos é limitada a significativamente menos de 4 GB. Normalmente, temos de 3,2 GB a 3,7 GB de memória física máxima utilizável nessa configuração. Para acessar mais de 3,2 GB a 3,7 GB de memória instalada (ou seja, até 4 GB, mas também mais de 4 GB), um ajuste especial chamado PAE deve ser usado. PAE significa Physical Address Extension e é uma maneira das CPUs x86 de 32 bits endereçarem mais de 4 GB de memória. Ele remapeia a memória que de outra forma seria sobreposta pelas reservas de endereço para dispositivos de hardware acima do intervalo de 4 GB e a usa como memória física adicional (veja man:pae[4]). Usar o PAE tem alguns inconvenientes; este modo de acesso à memória é um pouco mais lento que o modo normal (sem PAE) e módulos carregáveis (veja man:kld[4]) não são suportados. Isso significa que todos os drivers devem ser compilados estaticamente no kernel. A maneira mais comum de ativar o PAE é compilar um novo kernel com o arquivo especial de configuração do kernel, chamado [.filename]#PAE#, que já está configurado para compilar um kernel seguro. Observe que algumas entradas neste arquivo de configuração do kernel são muito conservadoras e alguns drivers marcados como não prontos para serem usados com o PAE na verdade são possíveis de serem utilizados. Uma regra básica é que, se o driver for utilizável em arquiteturas de 64 bits (como o AMD64), ele também poderá ser usado com o PAE. Ao criar um arquivo de configuração de kernel personalizado, o suporte ao PAE pode ser ativada adicionando a seguinte linha: [.programlisting] .... options PAE .... O PAE não é muito usado atualmente porque a maioria dos novos hardwares x86 também suporta a execução no modo de 64 bits, conhecido como AMD64 ou Intel(TM)64. Ele tem um espaço de endereçamento muito maior e não precisa tais ajustes. O FreeBSD suporta o AMD64 e é recomendado que esta versão do FreeBSD seja usada no lugar da versão i386(TM) se forem necessários 4 GB ou mais de memória. [[compatibility-processors]] === Arquiteturas e Processadores ==== O FreeBSD suporta arquiteturas diferentes do x86? Sim. O FreeBSD divide o suporte em vários níveis. Arquiteturas de Tier 1, como i386 ou amd64; são totalmente suportados. Tiers 2 e 3 são suportados com base no melhor esforço. Uma explicação completa do sistema de tiers está disponível no extref:{committers-guide}[Guia dos Committers., archs] Uma lista completa de arquiteturas suportadas pode ser encontrada na https://www.FreeBSD.org/platforms/[páginas de plataformas.] ==== O FreeBSD suporta o Multiprocessamento Simétrico (SMP)? O FreeBSD suporta multiprocessadores simétricos (SMP) em todas as plataformas não-embarcadas (por exemplo, i386, amd64, etc.). O SMP também é suportado em kernels arm e MIPS, embora algumas CPUs possam não suportar isso. A implementação do SMP do FreeBSD usa o bloqueio refinado, e o desempenho escala quase linearmente com o número de CPUs. A página de manual do man:smp[4] tem maiores detalhes. ==== O que é microcódigo? Como eu instalo as atualizações de microcódigo da Intel? Microcódigo é um método de implementar programaticamente instruções de nível de hardware. Isso permite que os bugs da CPU sejam corrigidos sem a necessidade de substituir fisicamente o chip. Instale o package:sysutils/devcpu-data[] e adicione: [.programlisting] .... microcode_update_enable="YES" .... no [.filename]#/etc/rc.conf# [[compatibility-peripherals]] === Periféricos ==== Que tipo de periféricos o FreeBSD suporta? Veja a lista completa nas Notas de Hardware para o FreeBSD https://www.FreeBSD.org/releases/12.1r/hardware[12.1] ou https://www.FreeBSD.org/releases/11.3r/hardware[11.3]. [[compatibility-kbd-mice]] === Teclados e Mouses [[moused]] ==== É possível usar um mouse fora do sistema X Window? O driver de console padrão, man:vt[4], fornece a capacidade de usar um ponteiro de mouse em consoles de texto para cortar & colar o texto. Execute o daemon do mouse, man:moused[8] e ative o ponteiro do mouse no console virtual: [source,shell] .... # moused -p /dev/xxxx -t yyyy # vidcontrol -m on .... No qual _xxxx_ é o nome do dispositivo de mouse e _yyyy_ é o tipo de protocolo para o mouse. O daemon do mouse pode determinar automaticamente o tipo de protocolo da maioria dos mouses, exceto antigos mouses seriais. Especifique o protocolo `auto` para invocar a detecção automática. Se a detecção automática não funcionar, consulte a página de manual man:moused[8] para obter uma lista dos tipos de protocolos suportados. Para um mouse PS/2, adicione `moused_enable="YES"` ao arquivo [.filename]#/etc/rc.conf# para iniciar o daemon do mouse no momento da inicialização. Além disso, para usar o daemon do mouse em todos os terminais virtuais em vez de apenas no console, adicione `allscreens_flags="-m on"` ao arquivo [.filename]#/etc/rc.conf#. Quando o daemon do mouse está em execução, o acesso ao mouse deve ser coordenado entre o daemon do mouse e outros programas, tais como o X Windows. Consulte o FAQ<> para obter mais detalhes sobre esse problema. ==== Como faço para cortar e colar texto com um mouse no console de texto? Não é possível remover (cortar) dados usando o mouse. No entanto, é possível copiar e colar. Quando o daemon do mouse estiver em execução, conforme descrito na <>, mantenha pressionado o botão 1 (botão esquerdo) e mova o mouse para selecionar uma região do texto. Em seguida, pressione o botão 2 (botão do meio) para colar no cursor de texto. Pressionar o botão 3 (botão direito) irá " estender " a região selecionada do texto. Se o mouse não tiver um botão do meio, é possível emular um ou remapear os botões usando as opções do daemon do mouse. Consulte a página de manual man:moused[8] para obter detalhes. ==== Meu mouse tem uma roda e botões extravagantes. Posso usá-los no FreeBSD? A resposta é, infelizmente, "Depende". Esses mouses com recursos adicionais exigem um driver especializado na maioria dos casos. A menos que o driver do dispositivo do mouse ou o programa do usuário tenha suporte específico para o mouse, ele funcionará exatamente como um mouse padrão de dois ou três botões. Para o possível uso de rodas do mouse no ambiente X Window, consulte <>. ==== Como eu uso a minha tecla de delete no sh e csh? Para o Bourne Shell, inclua as seguintes linhas no arquivo [.filename]#~/.shrc#. Veja man:sh[1] e man:editrc[5]. [.programlisting] .... bind ^[[3~ ed-delete-next-char # para o xterm .... Para o C Shell, adicione as seguintes linhas ao [.filename]#~/.cshrc#. Veja man:csh[1]. [.programlisting] .... bindkey ^[[3~ delete-char # para o xterm .... [[compatibility-other]] === Outro hardware ==== Algum workaround para o problema de não sair nenhum som da minha placa de som pcm4? Algumas placas de som definem seu volume de saída como 0 em cada inicialização. Execute o seguinte comando toda vez que a máquina inicializar: [source,shell] .... # mixer pcm 100 vol 100 cd 100 .... ==== O FreeBSD suporta o gerenciamento de energia no meu laptop? O FreeBSD suporta os recursos ACPI encontrados em componentes modernos de hardware. Maiores informações podem ser encontradas em man:acpi[4]. == Solução de problemas === Por que o FreeBSD está encontrando a quantidade errada de memória no hardware i386? O motivo mais provável é a diferença entre endereços de memória física e endereços virtuais. A convenção para a maioria dos hardwares de PC é usar a área de memória entre 3,5 GB e 4 GB para uma finalidade especial (geralmente para PCI). Este espaço de endereço é usado para acessar o hardware PCI. Como resultado real, a memória física não pode ser acessada por esse espaço de endereço. O que acontece com a memória que deveria aparecer nesse local depende do hardware. Infelizmente, alguns hardwares não fazem nada e a capacidade de usar estes últimos 500 MB de RAM é totalmente perdida. Felizmente, a maioria dos hardwares faz o remapeamento da memória para um local mais alto, para que ela ainda possa ser usada. No entanto, isso pode causar alguma confusão ao observar as mensagens de inicialização. Em uma versão de 32 bits do FreeBSD, a memória parece perdida, uma vez que ela será remapeada acima de 4 GB, uma área a qual um kernel de 32 bits não consegue acessar. Neste caso, a solução é construir um kernel habilitado para PAE. Veja a seção sobre os limites de memória para mais informações. Em uma versão de 64 bits do FreeBSD, ou quando o kernel estiver habilitado para PAE, o FreeBSD irá corretamente detectar e remapear a memória para que ela seja utilizável. Durante a inicialização, no entanto, pode parecer que o FreeBSD está detectando mais memória do que o sistema realmente possui, devido ao remapeamento descrito. Isso é normal e a memória disponível será corrigida conforme o processo de inicialização for concluído. === Por que meus programas morrem ocasionalmente com erros Signal 11 ? Os erros de sinal 11 são causados quando um processo tentou acessar a memória à qual o sistema operacional não concedeu acesso. Se algo assim está acontecendo em intervalos aparentemente aleatórios, comece a investigar a causa. Esses problemas geralmente podem ser atribuídos a: . Se o problema está ocorrendo apenas em um aplicativo customizado específico, é provavelmente um bug no código. . Se é um problema com parte do sistema base do FreeBSD, também pode ser resultado de um código com bugs, mas na maioria das vezes esses problemas são encontrados e corrigidos muito antes que o publico em geral e que normalmente lê o FAQ usem essas partes do código (é para isso que -CURRENT existe). Provavelmente não é um erro do FreeBSD se o problema ocorrer na compilação de um programa, mas sim da atividade que o compilador está realizando e que muda a cada vez. Por exemplo, se `make buildworld` falhar ao tentar compilar [.filename]#ls.c# para [.filename]#ls.o# e, quando executado novamente, ele falhar no mesmo lugar, significa que o código está quebrado. Tente atualizar o código fonte e tente compilar novamente. Se a compilação falhar em outro lugar, é quase certo que a causa é um problema de hardware. No primeiro caso, use um depurador como o man:gdb[1] para localizar o ponto no programa que está tentando acessar um endereço falso e corrija-o. No segundo caso, verifique qual peça de hardware está com defeito. As causas comuns disso incluem: . Os discos rígidos podem estar superaquecidos: Verifique se os ventiladores ainda estão funcionando, pois o disco e outros componentes de hardware podem estar superaquecendo. . O processador está superaquecendo: pode ser porque o processador sofreu overclock ou o ventilador do processador pode ter parado de funcionar. Em ambos os casos, certifique-se de que o hardware esteja sendo utilizado de acordo com as condições especificadas pelo fabricante, pelo menos ao tentar resolver esse problema. Se não estiver, volte o clock para as configurações padrão.) + Em relação ao overclocking, é muito mais barato ter um sistema lento do que um sistema frito que precisa ser substituído! Além disso, a comunidade não é simpática a problemas em sistemas com overclock. . Memória Errática: se vários módulos de memórias SIMMS/DIMMS estiverem instalados, retire-os e tente executar a máquina instalando cada SIMM ou DIMM individualmente para encontrar o modulo DIMM/SIMM problemático ou até mesmo encontrar uma combinação de módulos com problema. . Configurações over-otimizadas da placa-mãe: as configurações da BIOS e alguns jumpers da placa-mãe oferecem opções para definir vários intervalos de tempo. Os valores padrões geralmente são suficientes, mas, às vezes, a configuração dos estados de espera na RAM para valores muito baixos, ou a configuração da opção "RAM Speed: Turbo" causará um comportamento estranho. Uma ideia válida é restaurar a configuração padrão da BIOS, depois é claro de anotar as configurações atuais. . Fonte com potência insuficiente para energizar a placa-mãe: Remova qualquer placa de I/O não utilizada, discos rígidos ou CD-ROMs, desconectando o cabo de alimentação deles para ver se a fonte de alimentação pode gerenciar uma carga menor. Ou utilize outra fonte de alimentação, de preferência uma com um pouco mais de potência. Por exemplo, se a fonte de alimentação atual é recomendada para uma carga de 250 Watts, tente uma que seja recomendada para uma carga de 300 Watts. Leia a seção sobre o <> para obter maiores explicações e a discussão sobre como um software ou hardware de teste de memória ainda pode deixar passar uma memória defeituosa. Existe uma extensa FAQ sobre o problema do SIG11 disponível http://www.bitwizard.nl/sig11/[neste link]. Por fim, se nada disso ajudou, trata-se possivelmente de um bug no FreeBSD. Siga <> para enviar um relatório de problemas. === Meu sistema trava com Fatal trap 12: page fault in kernel mode ou panic:, e mostra um monte de informações. O que devo fazer? Os desenvolvedores do FreeBSD estão interessados ​​nesses erros, mas precisam de mais informações do que apenas a mensagem de erro. Copie a mensagem completa da falha. Em seguida, consulte a seção FAQ em <>, compile um kernel de depuração e obtenha um backtrace. Isso pode parecer difícil, mas não requer nenhuma habilidade de programação. Apenas siga as instruções. === Qual é o significado do erro maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)? O kernel do FreeBSD permitirá que apenas um certo número de processos exista ao mesmo tempo. O número é baseado na variável `kern.maxusers` do man:sysctl[8]. O valor da variável `kern.maxusers` também afeta vários outros limites dentro do kernel, como por exemplo os buffers de rede. Se a máquina estiver muito carregada, aumente o `kern.maxusers`. Isso aumentará esses outros limites do sistema além do número máximo de processos. Para ajustar o valor da variável `kern.maxusers`, consulte a seção extref:{handbook}config-tuning[Limites de Arquivos / Processos, kern-maxfiles] do Handbook. Apesar desta seção se referir a arquivos abertos, os mesmos limites se aplicam aos processos. Se a máquina estiver levemente carregada, mas executando um número muito grande de processos, ajuste o valor do `kern.maxproc` definindo-o no arquivo [.filename]#/boot/loader.conf#. O ajuste não terá efeito até que o sistema seja reinicializado. Para mais informações sobre o tuning de variáveis, consulte o manual do man:loader.conf[5]. Se esses processos estiverem sendo executados por um único usuário, ajuste o `kern.maxprocperuid` para que fique menor em 1 unidade do novo valor do `kern.maxproc`. Ele deve ser pelo menos uma unidade menor porque o programa do sistema, man:init[8], deve estar sempre em execução. === Por que aplicativos de tela cheia em máquinas remotas se comportam de forma errática? A máquina remota pode estar configurando o tipo de terminal para algo diferente de `xterm`, que é o tipo requerido pelo console do FreeBSD. Alternativamente, o kernel pode ter valores errados para a largura e a altura do terminal. Verifique se o valor da variável de ambiente `TERM` é `xterm`. Se a máquina remota não suportar isso, tente `vt100`. Execute o `stty -a` para verificar o que o kernel acha que são as dimensões do terminal. Se estiverem incorretos, eles podem ser alterados executando `stty rows_RR_cols_CC_`. Alternativamente, se a máquina do cliente tiver o package:x11/xterm[] instalado, a execução do `resize` consultará o terminal para as dimensões corretas e as definirá. === Por que demora tanto para conectar ao meu computador via ssh ou telnet? O sintoma: há um longo atraso entre o momento em que a conexão TCP é estabelecida e a hora em que o software cliente solicita uma senha (ou, no caso do man:telnet[1], quando um prompt de login aparece). O problema: mais provável do que não, o atraso é causado pelo software do servidor tentando resolver o endereço IP do cliente em um nome de host. Muitos servidores, incluindo os servidores Telnet e SSH que vêm com o FreeBSD, fazem isso para armazenar o nome do host em um arquivo de log para referência futura pelo administrador. A solução: se o problema ocorrer sempre, independente do servidor ao que o computador cliente se conecta, o problema está no cliente. Se o problema ocorrer apenas quando o computador cliente se conecta a um determinado servidor, o problema está no servidor. Se o problema for com o cliente, a única solução é corrigir o DNS para que o servidor possa resolvê-lo. Se isso estiver ocorrendo em uma rede local, considere um problema no servidor e continue lendo. Se isso estiver ocorrendo na Internet, entre em contato com seu ISP. Se o problema for com um servidor em uma rede local, configure o servidor para resolver as consultas de endereço para nome de host para o intervalo de endereços da rede local. Veja as páginas de manual para o man:hosts[5] e o man:named[8] para maiores informações. Se o problema for com um servidor na Internet, o problema pode ser que o resolver local do servidor não está funcionando corretamente. Para verificar se é isto, tente procurar outro host, como `www.yahoo.com`. Se isso não funcionar, este é o problema. Após uma nova instalação do FreeBSD, também é possível que as informações do domínio e do servidor de nomes estejam faltando no [.filename]#/etc/resolv.conf#. Isso geralmente causará um atraso no SSH, já que a opção `UseDNS` é definida como `yes` por padrão no [.filename]#/etc/ssh/sshd_config#. Se isso estiver causando o problema, preencha as informações ausentes no arquivo [.filename]#/etc/resolv.conf# ou configure a opção `UseDNS` para `no` no arquivo [.filename]#sshd_config# como uma solução temporária. === Por que a mensagem file: table is full aparece repetidamente no dmesg8? Essa mensagem de erro indica que o número de file descriptors disponíveis no sistema esgotaram. Consulte a informação sobre a variável extref:{handbook}config-tuning[kern.maxfiles, kern-maxfiles] na seção extref:{handbook}config-tuning[Ajustando os Limites do Kernel, configtuning-kernel-limits] do Handbook para uma discussão e solução. === Por que o relógio do meu computador mantém-se com o horário incorreto? O computador tem dois ou mais relógios e o FreeBSD escolheu usar o errado. Execute o comando man:dmesg[8] e verifique as linhas que contêm a palavra `Timecounter`. Aquele com o maior valor de quality é o que o FreeBSD escolheu. [source,shell] .... # dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "TSC" frequency 2998570050 Hz quality 800 Timecounters tick every 1.000 msec .... Confirme isso verificando o valor da variável `kern.timecounter.hardware` no man:sysctl[3]. [source,shell] .... # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast .... Pode ser um timer ACPI quebrado. A solução mais simples é desabilitar o timer ACPI no arquivo [.filename]#/boot/loader.conf#: [.programlisting] .... debug.acpi.disabled="timer" .... Ou a BIOS poderá modificar o relógio TSC - talvez para mudar a velocidade do processador quando estiver funcionando a partir de baterias, ou quando estiver entrando em modo de economia de energia, mas o FreeBSD não tem conhecimento desses ajustes e parece ganhar ou perder tempo. Neste exemplo, o relógio `i8254` também está disponível e pode ser selecionado alterando-se a variável `kern.timecounter.hardware` do man:sysctl[3]. [source,shell] .... # sysctl kern.timecounter.hardware=i8254 kern.timecounter.hardware: TSC -> i8254 .... O computador agora deve começar a manter seu relógio mais preciso. Para que essa mudança seja executada automaticamente no momento da inicialização, adicione a seguinte linha ao arquivo [.filename]#/etc/sysctl.conf#: [.programlisting] .... kern.timecounter.hardware=i8254 .... === O que significa o erro swap_pager: indefinite wait buffer:? Isso significa que um processo está tentando armazenar em memória RAM a memória do disco (swap), e que o processo foi interrompido depois de tentar sem sucesso acessar o disco por mais de 20 segundos. Isso pode ser causado por blocos defeituosos na unidade de disco, fiação de disco defeituosa, cabos ou qualquer outro hardware relacionado a I/O de disco. Se a própria unidade estiver com problemas, erros de disco aparecerão em [.filename]#/var/log/messages# e na saída do comando `dmesg`. Caso contrário, verifique os cabos e conexões. === O que é um lock order reversal (inversão de ordem de bloqueio)? O kernel do FreeBSD usa vários locks de recursos para arbitrar a contenção de certos recursos. Quando várias threads do kernel tentam obter vários locks de recursos, há sempre o potencial para um impasse (deadlock), em que duas threads obtiveram cada uma um dos locks e trava para sempre esperando que a outra thread libere um dos outros locks. Esse tipo de problema de locking pode ser evitado se todas as threads obtiverem os locks na mesma ordem. Um sistema de diagnóstico lock em tempo de execução chamado man:witness[4], ativado no FreeBSD-CURRENT e desabilitado por padrão para a branch stable e releases, detecta o potencial para deadlocks devido a erros de locking, incluindo erros causados ​​pela obtenção de vários locks de recursos com uma ordem diferente de partes diferentes do kernel. O framework man:witness[4] tenta detectar esse problema quando ele ocorre e relata isso imprimindo uma mensagem no console do sistema sobre um `lock order reversal` (geralmente também chamado de LOR). É possível obter falsos positivos, uma vez que o man:witness[4] é conservador. Um relatório positivo verdadeiro _não_ significa que um sistema está travado; em vez disso, deve ser entendido como um aviso de que um deadlock poderia ter acontecido. [NOTE] ==== Os problemas de LOR tendem a ser consertados rapidamente, então verifique a lista de discussão do http://lists.FreeBSD.org/mailman/listinfo/freebsd-current[FreeBSD-CURRENT] antes de postar sobre um. ==== === O que significa o erro Called ... with the following non-sleepable locks held? Isso significa que uma função que pode dormir foi chamada enquanto um lock mutex (ou outro unsleepable) era mantido. A razão pela qual isso é um erro é porque os mutexes não devem ser mantidos por longos períodos de tempo; eles deveriam existir apenas para manter curtos períodos de sincronização. Este contrato de programação permite que os drivers de dispositivos usem mutexes para sincronizar com o resto do kernel durante as interrupções. As interrupções (no FreeBSD) podem não dormir. Por isso, é imperativo que nenhum subsistema bloqueie o kernel por um longo período mantendo um mutex ativo. Para capturar tais erros, asserções podem ser adicionadas ao kernel que interage com o subsistema man:witness[4] para emitir um aviso ou erro fatal (dependendo a configuração do sistema) quando uma chamada potencialmente de bloqueio é feita enquanto um mutex estiver sendo mantido. Em resumo, tais avisos não são fatais, no entanto, com um timing infeliz, podem causar efeitos indesejáveis, desde um pequeno erro na capacidade de resposta do sistema até o seu travamento completo. Para obter informações adicionais sobre locking no FreeBSD, consulte man:locking[9]. === Por que o buildworld / installworld morre com a mensagem touch: not found? Este erro não significa que o utilitário man:touch[1] esteja ausente. O erro é provavelmente devido às datas dos arquivos que estão sendo definidos em algum momento no futuro. Se o relógio do CMOS estiver configurado para a hora local, execute `adjkerntz -i` para ajustar o relógio do kernel ao inicializar no modo de usuário único. == Aplicativos do Usuário === Onde estão todas as aplicações de usuário? Consulte https://www.FreeBSD.org/ports/[a página dos ports] para informações sobre pacotes de software portados para o FreeBSD. A maioria dos ports deve funcionar em todas as versões suportadas do FreeBSD. Aqueles que não funcionam, estão especificamente sinalizados como tal. Cada vez que uma release do FreeBSD é construída, um snapshot da coleção de ports no momento da construção também é incluída no diretório [.filename]#ports/#. O FreeBSD suporta pacotes binários compactados para facilitar a instalação e desinstalação dos ports. Use o comando man:pkg[7] para controlar a instalação de pacotes. === Como faço para baixar a coleção de ports? Eu deveria estar usando o Subversion? Qualquer um dos métodos listados aqui funciona: * Use o portsnap para a maioria dos casos de uso. Consulte a seção extref:{handbook}ports[Usando a coleção de ports, ports-using] para obter instruções sobre como usar essa ferramenta . * Use o Subversion se for necessário a aplicação de patches customizados na árvore de ports ou se estiver rodando FreeBSD-CURRENT. Consulte a seção extref:{handbook}mirrors[Usando o Subversion, svn] para obter detalhes. === Por que não posso compilar esse port na minha máquina 11.X - ou 12.X -STABLE? Se a versão do FreeBSD instalada estiver significativamente atrás do _-CURRENT_ ou do _-STABLE_, atualize a coleção de ports usando as instruções disponíveis na seção extref:{handbook}ports[Usando a coleção de ports, ports-using]. Se o sistema estiver atualizado, alguém pode ter feito uma alteração no port que funciona para _-CURRENT_ mas que quebrou o port para o _-STABLE_. https://bugs.FreeBSD.org/submit/[Envie] um relatório de bug, já que a Coleção de Ports deve funcionar tanto para o branch _-CURRENT_ e quanto o _-STABLE_. === Acabei de tentar compilar o INDEX usando o comando make index, e ele falhou. Por quê? Primeiro, certifique-se de que a Coleção de Ports esteja atualizada. Erros que afetam a compilação do [.filename]#INDEX# a partir de uma cópia atualizada da coleção de ports são de alta visibilidade e, portanto, quase sempre são corrigidos imediatamente. Existem casos raros em que o [.filename]#INDEX# não será compilado devido a casos estranhos envolvendo a variável `OPTIONS_SET` sendo definida em [.filename]#make.conf#. Se você suspeitar que este é o caso, tente fazer o [.filename]#INDEX# com estas variáveis desativadas antes de reportar o erro para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[Lista de discussão de ports do FreeBSD]. === Eu atualizei os fontes, agora como faço para atualizar meus ports instalados? O FreeBSD não inclui uma ferramenta de atualização de ports, mas possui algumas ferramentas para facilitar o processo de atualização. Ferramentas adicionais estão disponíveis para simplificar o manuseio dos ports e são descritas na seção extref:{handbook}ports[Atualizando Ports, ports-using] no Handbook do FreeBSD . === Preciso recompilar todos os ports sempre que realizo uma atualização de versão principal? Sim! Apesar de um sistema recente ser capaz de executar os softwares compilados em uma versão mais antiga, as coisas irão falhar aleatoriamente e deixar de funcionar quando outros ports forem instalados ou atualizados. Quando o sistema é atualizado, várias bibliotecas compartilhadas, módulos carregáveis ​​e outras partes do sistema serão substituídas por versões mais recentes. Os aplicativos vinculados às versões mais antigas podem não iniciar ou, em outros casos, não funcionar corretamente. Para obter maiores informações, consulte a extref:{handbook}updating-upgrading[seção sobre atualizações, freebsdupdate-upgrade] no Handbook do FreeBSD. === Preciso recompilar cada port toda vez que faço uma atualização de versão secundária? Em geral, não. Os desenvolvedores do FreeBSD fazem o máximo para garantir compatibilidade binária em todos os releases com o mesmo número de versão principal. Quaisquer exceções serão documentadas nas Release Notes, e os conselhos dados lá devem ser seguidos. === Por que o /bin/sh é tão pequeno? Por que o FreeBSD não usa o bash ou outro shell? Muitas pessoas precisam escrever shell scripts que serão portados para muitos sistemas. É por isso que o POSIX(TM) especifica os comandos shell e utilitários em grande detalhe. A maioria dos scripts são escritos em Bourne shell (man:sh[1]) e porque várias interfaces de programação importantes (man:make[1], man:system[3], man:popen[3] e análogos em linguagens de script de alto nível como Perl e Tcl) são especificados para usar o Bourne shell para interpretar comandos. Como o Bourne shell é usado com tanta frequência e em larga escala, é importante que ele seja iniciado rapidamente, que seja determinístico em seu comportamento e que ocupe o menor espaço possível na memória. A implementação existente é resultado do nosso melhor esforço para atender simultaneamente o quanto pudermos desses requisitos. Para manter o `/bin/sh` pequeno, não fornecemos muitos dos recursos de conveniência que os outros shells possuem. É por isso que outras shells com mais recursos, como o `bash`, o `scsh`, o man:tcsh[1], e o `zsh` estão disponíveis. Compare a utilização de memória desses shells observando as colunas " VSZ " e " RSS " em uma listagem gerada com o comando `ps -u`. == Configuração do Kernel [[make-kernel]] === Eu gostaria de customizar meu kernel. É difícil? De modo nenhum! Confira a seção extref:{handbook}kernelconfig[configuração do kernel do Handbook, kernelconfig]. [NOTE] ==== O novo [.filename]#kernel# será instalado no diretório [.filename]#/boot/kernel# junto com os seus módulos, enquanto o kernel antigo e seus módulos serão movidos para o diretório [.filename]#/boot/kernel.old#. Se um erro for cometido na configuração, basta inicializar utilizando a versão anterior do kernel. ==== === Por que meu kernel é tão grande? Os kernels `GENERIC` enviados com o FreeBSD são compilados com o _modo de depuração_ habilitado. Kernels compilados no modo de depuração contêm dados de depuração em arquivos separados que são usados ​​para depuração. Versões do FreeBSD anteriores a 11.0 armazenam esses arquivos de depuração no mesmo diretório que o próprio kernel, [.filename]#/boot/kernel/#. No FreeBSD 11.0 e posterior, os arquivos de depuração são armazenados em [.filename]#/usr/lib/debug/boot/kernel/#. Observe que haverá pouca ou nenhuma perda de desempenho ao executar um kernel com o modo de depuração habilitado, e é útil manter um por perto em caso de panic no sistema. Quando estiver com pouco espaço em disco, existem diferentes opções para reduzir o tamanho de [.filename]#/boot/kernel/# e [.filename]#/usr/lib/debug/#. Para não instalar os arquivos de símbolos, certifique-se que a seguinte linha existe em [.filename]#/etc/src.conf#: [.programlisting] .... WITHOUT_KERNEL_SYMBOLS=yes .... Para mais informações veja man:src.conf[5]. Se você quiser evitar completamente a criação de arquivos de depuração, certifique-se de que ambos os itens a seguir sejam verdadeiros: * Esta linha não existe no arquivo de configuração do kernel: + [.programlisting] .... makeoptions DEBUG=-g .... * Não execute o comando man:config[8] com a opção `-g`. Qualquer uma das configurações acima fará com que o kernel seja construído com suporte ao modo de depuração. Para construir e instalar somente os módulos desejados, liste-os em [.filename]#/etc/make.conf#: [.programlisting] .... MODULES_OVERRIDE= accf_http ipfw .... Substitua _accf_httpd ipfw_ com a lista dos módulos que precisa. Apenas os módulos listados serão compilados. Isso reduz o tamanho do diretório do kernel e diminui o tempo necessário para compilar o kernel. Para mais informações, leia [.filename]#/usr/shared/examples/etc/make.conf#. Dispositivos desnecessários podem ser removidos do kernel para reduzir ainda mais o tamanho. Veja <> para mais informações. Para colocar qualquer uma dessas opções em vigor, siga as instruções para extref:{handbook}kernelconfig/[compilar e instalar, kernelconfig-building] um novo kernel. Para referência, o kernel amd64 do FreeBSD 11 ([.filename]#/boot/kernel/kernel#) é de aproximadamente 25 MB. === Por que todo kernel que eu tento construir falha ao compilar, até mesmo o GENERIC? Há várias causas possíveis para esse problema: * A o código fonte de origem é diferente do usado para construir o sistema atualmente em execução. Ao tentar uma atualização, leia o arquivo [.filename]#/usr/src/UPDATING#, prestando atenção especial à seção "ITENS COMUNS" no final. * O comando `make buildkernel` não foi concluído com sucesso. O comando `make buildkernel` depende dos arquivos gerados pelo comando `make buildworld` para concluir seu trabalho corretamente. * Mesmo quando estiver compilando o <>, é possível que o código fonte tenha sido obtido em um momento em que estava sendo modificado ou em que estava quebrado. Somente os releases possuem a garantia de que podem ser compilados, apesar do <> compilar corretamente na maioria das vezes. Tente atualizar novamente o código fonte e veja se o problema desaparece. Tente usar um servidor de distribuição diferente, caso o anterior esteja com problemas. === Qual agendador está em uso em um sistema em execução? O nome do agendador que atualmente sendo usado está diretamente disponível como o valor da variavel `kern.sched.name` do sysctl: [source,shell] .... % sysctl kern.sched.name kern.sched.name: ULE .... === O que é o kern.sched.quantum? A variável `kern.sched.quantum` define o número máximo de pulsos que um processo pode executar sem ser "preempted" no scheduler 4BSD. == Discos, sistemas de arquivos e boot loaders === Como posso adicionar o meu novo disco rígido ao meu sistema FreeBSD? Veja a seção extref:{handbook}disks[Adicionando Discos, disks-adding] no Handbook do FreeBSD. === Como faço para mover meu sistema para o meu novo disco enorme? A melhor maneira é reinstalar o sistema operacional no novo disco e depois passar os dados do usuário. Isto é altamente recomendado ao seguir o _-STABLE_ por mais de uma release ou ao atualizar uma release ao invés de instalar uma nova. Instale o booteasy em ambos os discos com man:boot0cfg[8] e use a opção de dual boot até que esteja satisfeito com a nova configuração. Pule o próximo parágrafo para descobrir como mover os dados depois de fazer isso. Alternativamente, particione e rotule o novo disco utilizando o man:sade[8] ou o man:gpart[8]. Se os discos forem formatados com MBR, o booteasy pode ser instalado em ambos os discos utilizando-se o man:boot0cfg[8] para que o computador possa inicializar dualmente com o antigo ou novo sistema após a conclusão da cópia. Depois que o novo disco estiver configurado, os dados não podem ser simplesmente copiados. Em vez disso, use ferramentas que entendam device files e system flags, tais como o man:dump[8]. Embora seja recomendado que você mova os dados com o sistema em modo single user, isto não é necessário. Quando os discos estiverem formatados com UFS, nunca use nada além do man:dump[8] e do man:restore[8] para mover o sistema de arquivos raiz. Esses comandos também devem ser usados para mover uma única partição para uma outra partição vazia. A seqüência de etapas para usar o comando `dump` para mover os dados de uma partição UFS para uma nova partição é: [.procedure] ==== . Execute o `newfs` na nova partição. . Utilize o `mount` para disponibilizá-la em um ponto de montagem temporário. . Vá para o diretório desejado utilizando o comando `cd`. . Faça o `dump` da partição antiga e redirecione a saída para a nova. ==== Por exemplo, para mover [.filename]#/dev/ada1s1a# tendo [.filename]#/mnt# como o ponto de montagem temporário, digite: [source,shell] .... # newfs /dev/ada1s1a # mount /dev/ada1s1a /mnt # cd /mnt # dump 0af - / | restore rf - .... Reorganizar as partições com o comando `dump` requer um pouco mais de trabalho. Para mesclar uma partição como [.filename]#/var# com a partição pai, crie uma nova partição grande o suficiente para conter ambas, mova a partição pai conforme descrito acima e mova a partição filha para o diretório vazio criado pela primeira movimentação: [source,shell] .... # newfs /dev/ada1s1a # mount /dev/ada1s1a /mnt # cd /mnt # dump 0af - / | restore rf - # cd var # dump 0af - /var | restore rf - .... Para separar um diretório do seu pai, digamos colocar [.filename]#/var# em sua própria partição quando não era antes, crie as duas partições, monte a partição filho no diretório apropriado no ponto de montagem temporário e mova a antiga partição única: [source,shell] .... # newfs /dev/ada1s1a # newfs /dev/ada1s1d # mount /dev/ada1s1a /mnt # mkdir /mnt/var # mount /dev/ada1s1d /mnt/var # cd /mnt # dump 0af - / | restore rf - .... Os utilitários man:cpio[1] e man:pax[1] também estão disponíveis para mover dados do usuário. Estes comandos são conhecidos por perder as flags com as informações dos arquivo, portanto, use-os com cuidado. === Quais partições podem usar com segurança o Soft Updates? Ouvi dizer que o uso de Soft Updates no / pode causar problemas. E quanto ao Journaled Soft Updates? Resposta curta: Soft Updates geralmente podem ser usados ​​com segurança em todas as partições. Resposta longa: o Soft Updates possui duas características que podem ser indesejáveis ​​em determinadas partições. Primeiro, uma partição com Soft Updates tem uma pequena chance de perder dados durante uma falha do sistema. A partição não será corrompida, pois os dados serão simplesmente perdidos. Em segundo lugar, o uso de Soft Updates pode causar escassez temporária de espaço. Ao usar o Soft Updates, o kernel pode levar até trinta segundos para gravar alterações no disco físico. Quando um arquivo grande é excluído, o arquivo ainda reside no disco até que o kernel execute a exclusão. Isso pode causar uma "race condition" muito simples. Suponha que um arquivo grande seja excluído e outro arquivo grande seja criado imediatamente. O primeiro arquivo grande ainda não foi removido do disco físico, portanto, o disco pode não ter espaço suficiente para o segundo arquivo grande. Isso produzirá um erro de que a partição não tem espaço suficiente, mesmo que um grande espaço tenha acabado de ser liberado. Alguns segundos depois, a criação do arquivo funciona conforme o esperado. Se um sistema travar depois que o kernel tiver aceito um bloco de dados para gravar no disco, mas antes que os dados sejam realmente gravados, os dados poderão ser perdidos. Esse risco é extremamente pequeno, e geralmente gerenciável. Esses problemas afetam todas as partições usando as Soft Updates. Então, o que isso significa para a partição raiz? Informações vitais sobre a partição raiz mudam muito raramente. Se o sistema travar dentro da janela de 30 segundos depois de uma alteração ter sido feita, é possível que os dados possam ser perdidos. Esse risco é insignificante para a maioria dos aplicativos, mas esteja ciente de que existe. Se o seu sistema não puder tolerar este risco, não use as Soft Updates no sistema de arquivos raiz! O [.filename]#/# é tradicionalmente uma das menores partições. Se o [.filename]#/tmp# estiver localizado dentro do [.filename]#/#, pode haver problemas intermitentes de falta de espaço. A criação de um link simbólico apontando o [.filename]#/tmp# para [.filename]#/var/tmp# resolverá esse problema. Por fim, o man:dump[8] não funciona no modo live (-L) em um sistema de arquivos, com Journaled Soft Updates (SU + J). === Posso acessar outros sistemas de arquivos não-nativos do FreeBSD? O FreeBSD suporta uma variedade de outros sistemas de arquivos. UFS:: Os CD-ROMs UFS podem ser montados diretamente no FreeBSD. Montar partições de disco do Digital UNIX e de outros sistemas que suportam o UFS pode ser mais complexo, dependendo dos detalhes do particionamento do disco para o sistema operacional em questão. ext2/ext3:: O FreeBSD suporta partições `ext2fs` e `ext3fs`. Veja man:ext2fs[5] para mais informações. NTFS:: O suporte ao NTFS baseia-se no FUSE está disponível como um port (package:sysutils/fusefs-ntfs[]). Para mais informações, consulte http://www.tuxera.com/community/ntfs-3g-manual/[ntfs-3g]. FAT:: O FreeBSD inclui um driver FAT de leitura-gravação. Para obter mais informações, consulte man:mount_msdosfs[8]. ZFS:: O FreeBSD inclui um port do driver ZFS da Sun(TM). A recomendação atual é usá-lo apenas em plataformas amd64 com memória suficiente. Para obter mais informações, consulte man:zfs[8]. O FreeBSD inclui o sistema de arquivos de rede NFS e a Coleção de Ports do FreeBSD fornece vários aplicativos FUSE para suportar muitos outros sistemas de arquivos. === Como faço para montar uma partição secundária do DOS? As partições secundárias do DOS são encontradas depois de _todas_ as partições primárias. Por exemplo, se `E` for a segunda partição DOS na segunda unidade SCSI, haverá um arquivo de dispositivo para a "slice 5" em [.filename]#/dev#. Para montá-lo: [source,shell] .... # mount -t msdosfs /dev/da1s5 /dos/e .... === Existe um sistema de arquivos criptográficos para o FreeBSD? Sim, o man:gbde[8] e o man:geli[8]. Consulte a seção extref:{handbook}disks[Partições de Disco com Criptografia, disks-encrypting] do Handbook do FreeBSD. === Como inicializo o FreeBSD e o Linux utilizando o GRUB? Para inicializar o FreeBSD usando o GRUB, adicione o seguinte ao [.filename]#/boot/grub/menu.lst# ou ao [.filename]#/boot/grub/grub.conf#, dependendo de qual é usado pela sua distribuição Linux (TM). [.programlisting] .... title FreeBSD 9.1 root (hd0,a) kernel /boot/loader .... No qual _hd0,a_ aponta para a partição raiz no primeiro disco. Para especificar o número da slice, use algo como isto _(hd0,2,a)_. Por padrão, se o número da slice for omitido, o GRUB pesquisará a primeira slice que tiver a partição `a`. === Como inicializo o FreeBSD e o Linux usando o BootEasy? Instale o LILO no início da partição de inicialização Linux(TM) em vez de no Master Boot Record. Em seguida, inicialize o LILO a partir do BootEasy. Isto é recomendado ao executar o Windows(TM) e o Linux(TM), pois torna mais fácil fazer o Linux(TM) inicializar novamente se o Windows(TM) for reinstalado. === Como faço para alterar o prompt de inicialização de ??? para algo mais significativo? Isso não pode ser feito com o gerenciador de inicialização padrão sem reescrevê-lo. Há vários outros gerenciadores de inicialização na categoria [.filename]#sysutils# da coleção de ports. === Como faço para usar uma nova unidade removível? Se a unidade já tiver um sistema de arquivos, use um comando como este: [source,shell] .... # mount -t msdosfs /dev/da0s1 /mnt .... Se a unidade só for usada com sistemas FreeBSD, particione-a com UFS ou ZFS. Isso fornecerá suporte a nomes longos de arquivo, melhoria no desempenho e na estabilidade. Se a unidade for usada por outros sistemas operacionais, uma escolha mais portátil, como por exemplo o msdosfs, será mais apropriada. [source,shell] .... # dd if=/dev/zero of=/dev/da0 count=2 # gpart create -s GPT /dev/da0 # gpart add -t freebsd-ufs /dev/da0 .... Finalmente, crie um novo sistema de arquivos: [source,shell] .... # newfs /dev/da0p1 .... e monte-o: [source,shell] .... # mount /dev/da0s1 /mnt .... É uma boa ideia adicionar uma linha ao [.filename]#/etc/fstab# (veja man:fstab[5]) para que você possa digitar apenas `mount /mnt` no futuro: [.programlisting] .... /dev/da0p1 /mnt ufs rw,noauto 0 0 .... === Por que recebo o erro Incorrect super block ao montar um CD? O tipo de dispositivo a ser montado deve ser especificado. Isso está descrito no Handbook na seção extref:{handbook}disks[ Usando CDs de Dados, mounting-cd]. === Por que recebo o erro Device not configured ao montar um CD? Isso geralmente significa que não há CD na unidade ou a unidade não está visível no barramento. Consulte a seção extref:{handbook}disks[Usando CDs de Dados, mounting-cd] do Handbook para uma discussão detalhada desta questão. === Por que todos os caracteres não-ingleses em nomes de arquivos aparecem como ? em meus CDs quando montados no FreeBSD? O CD provavelmente usa a extensão "Joliet" para armazenar informações sobre arquivos e diretórios. Isso é discutido na seção extref:{handbook}disks[Usando CD-ROMs de Dados, mounting-cd] do Handbook. === Um CD gravado no FreeBSD não pode ser lido sob nenhum outro sistema operacional. Por quê? Isso significa que um raw file foi gravado no CD, em vez de criar um sistema de arquivos ISO 9660. Dê uma olhada na seção extref:{handbook}disks[Usando CDs de Dados, mounting-cd]. === Como posso criar uma imagem de um CD de dados? Isso é discutido na seção Handbook sobre extref:{handbook}disks[como gravar dados em um sistema de arquivos ISO, mkisofs]. Para mais informações sobre como trabalhar com CD-ROMs, consulte a extref:{handbook}disks[Seção Criando CDs, creating-cds] no capítulo sobre Armazenamento do Handbook. === Por que não consigo usar o comando mount com um CD de áudio? Tentar montar um CD de áudio produzirá um erro do tipo `cd9660: /dev/cd0: Invalid argument`. Isso ocorre porque o comando `mount` só funciona em sistemas de arquivos. CDs de áudio não possuem sistemas de arquivos; eles têm apenas dados. Em vez disso, use um programa que leia CDs de áudio, como o pacote ou port package:audio/xmcd[]. === Como eu faço para usar o comando mount com um CD multi-sessão? Por padrão, o man:mount[8] tentará montar a última trilha de dados (sessão) de um CD. Para carregar uma sessão anterior, use o argumento de linha de comando `-s`. Consulte man:mount_cd9660[8] para exemplos específicos. === Como posso permitir que usuários não privilegiados montem CD-ROMs, DVDs, unidades USB e outras mídias removíveis? Como `root`, defina a variável `vfs.usermount` do sysctl como `1`. [source,shell] .... # sysctl vfs.usermount=1 .... Para tornar o ajuste permanente, adicione a linha `vfs.usermount=1` ao arquivo [.filename]#/etc/sysctl.conf# para que a variável seja redefinids no momento da inicialização do sistema. Os usuários só podem montar dispositivos para os quais tenham permissões de leitura. Para permitir que os usuários montem um dispositivo, as permissões devem ser definidas em [.filename]#/etc/devfs.conf#. Por exemplo, para permitir que os usuários montem a primeira unidade USB, adicione: [.programlisting] .... # Allow all users to mount a USB drive. own /dev/da0 root:operator perm /dev/da0 0666 .... Todos os usuários agora podem montar dispositivos que eles podem ler em um diretório que eles possuem: [source,shell] .... % mkdir ~/my-mount-point % mount -t msdosfs /dev/da0 ~/my-mount-point .... Desmontar o dispositivo é simples: [source,shell] .... % umount ~/my-mount-point .... Ativar a variável `vfs.usermount`, no entanto, tem implicações negativas de segurança. Uma maneira melhor de acessar uma mídia formatada para o MS-DOS(TM) é usar o pacote package:emulators/mtools[] da Coleção de Ports. [NOTE] ==== O nome do dispositivo usado nos exemplos anteriores deve ser alterado de acordo com a configuração. ==== === Os comandos du e df mostram informações diferentes sobre a quantia disponível de espaço em disco. O que está acontecendo? Isso se deve ao modo como esses comandos realmente funcionam. O `du` passa pela árvore de diretórios, ele mede o tamanho de cada arquivo e apresenta os totais. O `df` apenas pergunta ao sistema de arquivos quanto espaço ainda resta. Eles parecem ser a mesma coisa, mas um arquivo sem uma entrada de diretório afetará `df` mas não `du`. Quando um programa está usando um arquivo e o arquivo é excluído, o arquivo não é realmente removido do sistema de arquivos até que o programa pare de usá-lo. O arquivo é imediatamente excluído da listagem do diretório, no entanto. Como exemplo, considere um arquivo grande o suficiente para afetar a saída de `du` e `df`. Um arquivo sendo visualizado com `more` pode ser excluído sem causar um erro. A entrada é removida do diretório para que nenhum outro programa ou usuário possa acessá-la. No entanto, o `du` mostra que ele desapareceu, já que percorreu a árvore de diretórios e o arquivo não está mais listado. Já o `df` mostra que ele ainda está lá, pois o sistema de arquivos sabe que o comando `more` ainda está usando esse espaço. Quando a sessão do `more` terminar, o `du` e `df` apresentarão o mesmo resultado. Essa situação é comum em servidores web. Muitas pessoas configuram um servidor web no FreeBSD e esquecem de rotacionar os arquivos de log. O log de acesso enche o [.filename]#/var#. O administrador novato exclui o arquivo, mas o sistema ainda reclama que a partição está cheia. Parar e reiniciar o programa do servidor Web liberaria o arquivo, permitindo que o sistema liberasse o espaço em disco. Para evitar que isso aconteça, configure o man:newsyslog[8]. Observe que o Soft Updates pode atrasar a liberação de espaço em disco e pode levar até 30 segundos para que a alteração fique visível. === Como posso adicionar mais espaço de swap? Esta seção extref:{handbook}config-tuning[do Handbook, adding-swap-space] descreve como fazer isso. === Por que o FreeBSD vê meu disco como sendo menor do que o fabricante diz que ele é? Os fabricantes de discos calculam gigabytes como um bilhão de bytes cada, enquanto o FreeBSD os calcula como 1.073.741.824 bytes cada. Isso explica por que, por exemplo, as mensagens de boot do FreeBSD reportarão um disco que supostamente tem 80 GB como contendo 76.319 MB. Observe também que o FreeBSD irá (por padrão) <> cerca de 8% do espaço em disco. === Como é possível que uma partição esteja com mais de 100% de ocupação? Uma parte de cada partição UFS (8%, por padrão) é reservada para uso pelo sistema operacional e pelo usuário `root`. O man:df[1] não contabiliza esse espaço ao calcular a coluna `Capacity`, portanto, ela pode exceder 100%. Observe que a coluna `Blocks` é sempre maior que a soma das colunas `Used` e `Avail`, geralmente por um fator de 8%. Para mais detalhes, procure prls opção `-m` em man:tunefs[8]. == ZFS === Qual é a quantidade mínima de RAM que um usuário deve ter para utilizar o ZFS? É necessário um mínimo de 4 GB de RAM para uso confortável, mas as cargas de trabalho individuais podem variar muito. === O que é o ZIL e quando ele é usado? O ZIL (log de intenção do ZFS ) é um log de gravação usado para implementar semânticas de compromisso de escrita posix entre travamentos. Normalmente, as gravações são agrupadas em grupos de transações e gravadas no disco quando preenchidas ("Transaction Group Commit "). No entanto, syscalls como man:fsync[2] requerem um compromisso de que os dados são gravados no armazenamento estável antes de retornar. O ZIL é necessário para gravações que foram reconhecidas como gravadas, mas que ainda não estão no disco como parte de uma transação. Os grupos de transações contam com registro de data e hora. No caso de uma falha, o último registro de data e hora válido é encontrado e os dados ausentes são mesclados a partir do ZIL. === Preciso de um SSD para o ZIL? Por padrão, o ZFS armazena o ZIL no pool com todos os demais dados. Se um aplicativo tiver uma carga de gravação pesada, o armazenamento do ZIL em um dispositivo separado e que tenha um desempenho de gravação sequencial síncrono muito rápido pode melhorar a performance do sistema de uma forma geral. Para outras cargas de trabalho, é improvável que um SSD consiga uma melhoria significativa. === O que é o L2ARC? O L2ARC é um cache de leitura armazenado em um dispositivo rápido, como um SSD. Esse cache não é persistente nas reinicializações. Observe que a RAM é usada como a primeira camada de cache e o L2ARC só é necessário se a quantidade de memória RAM for insuficiente. O L2ARC precisa de espaço no ARC para indexá-lo. Então, perversamente, um conjunto de trabalho que se encaixa perfeitamente no ARC não se encaixará mais perfeitamente se um L2ARC for usado porque parte do ARC estará mantendo o índice L2ARC, empurrando parte do conjunto de trabalho para o L2ARC que é mais lento que a RAM. === A ativação da funcionalidade de desduplicação é recomendável? De um modo geral, não. A deduplicação ocupa uma quantidade significativa de RAM e pode tornar mais lento os tempos de acesso ao disco para leitura e gravação. A menos que um esteja armazenando dados muito duplicados, como imagens de máquinas virtuais ou backups de usuários, é possível que a deduplicação faça mais mal do que bem. Outra consideração é a incapacidade de reverter o status da deduplicação. Se os dados forem gravados quando a deduplicação estiver ativada, desabilitar a deduplicação não fará com que os blocos deduplicados sejam replicados até que sejam modificados em novamente. A deduplicação também pode levar há algumas situações inesperadas. Em particular, a exclusão de arquivos pode se tornar muito mais lenta. === Não consigo excluir ou criar arquivos no meu pool do ZFS. Como posso consertar isso? Isso pode acontecer porque o pool está 100% cheio. O ZFS requer espaço no disco para gravar metadados de transação. Para restaurar o pool para um estado utilizável, primeiro faça o truncate do arquivo que irá excluir: [source,shell] .... % truncate -s 0 unimportant-file .... O truncamento de arquivo funciona porque uma nova transação não é iniciada, novos blocos de reserva são criados. [NOTE] ==== Em sistemas que utilizam o ZFS com um dataset customizado, por exemplo com a funcionalidade de deduplicação ativada, o espaço pode não ficar disponível imediatamente ==== === O ZFS suporta TRIM para unidades de estado sólido? O suporte ao ZFS TRIM foi adicionado ao FreeBSD 10-CURRENT com revisão rlink:https://svnweb.freebsd.org/changeset/base/240868[r240868]. O suporte ao ZFS TRIM foi adicionado a todas as branchs do FreeBSD-STABLE na revisão rlink:https://svnweb.freebsd.org/changeset/base/252162[r252162] e rlink:https://svnweb.freebsd.org/changeset/base/251419[r251419], respectivamente. O ZFS TRIM é ativado por padrão e pode ser desativado adicionando-se esta linha ao arquivo [.filename]#/etc/sysctl.conf#: [.programlisting] .... vfs.zfs.trim.enabled=0 .... [NOTE] ==== O suporte ao ZFS TRIM foi adicionado ao GELI em rlink:https://svnweb.freebsd.org/changeset/base/286444[r286444]. Por favor, veja man:geli[8] e a opção `-T`. ==== == Administração do Sistema === Onde estão os arquivos de configuração de inicialização do sistema? O arquivo de configuração principal é o [.filename]#/etc/defaults/rc.conf#, o qual está descrito em man:rc.conf[5]. Os scripts de inicialização do sistema, tais como [.filename]#/etc/rc# e [.filename]#/etc/rc.d#, que são descritos em man:rc[8], incluem este arquivo. _Não edite este arquivo!_ Em vez disso, para editar uma entrada do [.filename]#/etc/default/rc.conf#, copie a linha para o arquivo [.filename]#/etc/rc.conf# e altere-a lá. Por exemplo, se para iniciar man:named[8], o servidor DNS incluído: [source,shell] .... # echo 'named_enable="YES"' >> /etc/rc.conf .... Para iniciar serviços locais, coloque seus shell scripts no diretório [.filename]#/usr/local/etc/rc.d#. Estes shell scripts devem estar definidos como executáveis, o modo de arquivo padrão é `555`. === Como eu adiciono um usuário facilmente? Use o comando man:adduser[8], para as situações mais complexas utilize o comando man:pw[8]. Para remover o usuário, use o comando man:rmuser[8] ou, se necessário, o comando man:pw[8]. === Por que eu continuo recebendo mensagens como root: not found depois de editar o arquivo /etc/crontab? Isto normalmente é causado pela edição do crontab do sistema. Esta não é a maneira correta de fazer as coisas, pois o crontab do sistema tem um formato diferente dos crontabs por usuário. O crontab do sistema possui um campo extra, especificando qual usuário irá executar o comando. O man:cron[8] assume que este usuário é a primeira palavra do comando a ser executado. Como esse comando não existe, essa mensagem de erro é exibida. Para excluir o crontab extra incorreto: [source,shell] .... # crontab -r .... === Por que eu recebo o erro, you are not in the correct group to su root quando tento executar o comando su para o usuário root ? Este é um recurso de segurança. Para executar `su` para `root`, ou qualquer outra conta com privilégios de superusuário, a conta do usuário deve ser um membro do grupo `wheel`. Se este recurso não estivesse lá, qualquer pessoa com uma conta em um sistema e que também descobrisse a senha do `root` seria capaz de obter acesso de nível de superusuário ao sistema. Para permitir que alguém execute o comando `su root`, coloque-os no grupo `wheel` usando o comando `pw`: [source,shell] .... # pw groupmod wheel -m lisa .... O exemplo acima adicionará o usuário `lisa` ao grupo `wheel`. === Cometi um erro no rc.conf, ou outro arquivo de inicialização, e agora não posso editá-lo porque o sistema de arquivos está montado somente leitura. O que devo fazer? Reinicie o sistema usando `boot -s` no prompt do loader para entrar no modo single user. Quando o sistema solicitar o caminho do shell, apenas pressione kbd:[Enter] e execute `mount -urw /` para remontar novamente o sistema de arquivos raiz no modo de leitura e gravação. Você também pode precisar executar o comando `mount -a -t ufs` para montar o sistema de arquivos no qual seu editor favorito é mantido. Se esse editor estiver em um sistema de arquivos de rede, configure a rede manualmente antes de montar os sistemas de arquivos de rede ou use um editor que resida em um sistema de arquivos local, tal como o man:ed[1]. Para usar um editor de tela inteira, tal como o man:vi[1] ou man:emacs[1], execute `export TERM=xterm` para que esses editores possam carregar os dados corretos do banco de dados do man:termcap[5]. Depois de executar estas etapas, edite o arquivo [.filename]#/etc/rc.conf# para corrigir o erro de sintaxe. A mensagem de erro exibida imediatamente após as mensagens de inicialização do kernel deve indicar o número da linha no arquivo que está com erro. === Por que estou tendo problemas para configurar minha impressora? Consulte a seção sobre extref:{handbook}printing[impressão, printing] no Handbook do FreeBSD para dicas de soluções de problemas. === Como posso corrigir os mapeamentos de teclado para o meu sistema? Consulte a seção extref:{handbook}l10n[usando localização, using-localization] do Handbook, mais especificamente a seção sobre a extref:{handbook}l10n[configuração do console, setting-console]. === Por que não consigo colocar as quotas de usuários para funcionar corretamente? . É possível que o kernel não esteja configurado para usar quotas. Neste caso, adicione a seguinte linha ao arquivo de configuração do kernel e recompile o kernel: + [.programlisting] .... options QUOTA .... + Consulte aextref:{handbook}disks[ seção do Handbook sobre quotas, quotas] para obter detalhes completos. . Não ative o uso de quotas na partição [.filename]#/#. . Coloque o arquivo de quotas no sistema de arquivos para o qual quotas precisam ser aplicadas: + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | Sistema de arquivo | Arquivo de quota |[.filename]#/usr# |[.filename]#/usr/admin/quotas# |[.filename]#/home# |[.filename]#/home/admin/quotas# |... |... |=== === O FreeBSD suporta System V IPC primitives? Sim, o FreeBSD suporta o IPC no estilo do System V, incluindo memória compartilhada, mensagens e semáforos, no kernel [.filename]#GENERIC#. Em um kernel personalizado, o suporte pode ser por meio do carregamento dos módulos de kernel [.filename]#sysvshm.ko#, [.filename]#sysvsem.ko# e [.filename]#sysvmsg.ko#, ou habilitado de forma estática no kernel personalizado adicionando as seguintes linhas ao arquivo de configuração do mesmo: [.programlisting] .... options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging .... Recompile e instale o kernel. === Qual outro software de servidor de correio posso usar em substituição ao Sendmail? O servidor http://www.sendmail.org/[Sendmail ] é o software de servidor de email padrão do FreeBSD, mas pode ser substituído por outro MTA instalado a partir da coleção de ports. Os ports disponíveis incluem o package:mail/exim[], o package:mail/postfix[] e o package:mail/qmail[]. Procure informações nas listas de discussão sobre as vantagens e desvantagens dos MTAs disponíveis. === Esqueci a senha do root! O que eu faço? Não entre em pânico! Reinicie o sistema, digite `boot -s` no prompt `Boot:` para entrar no modo single user. Na pergunta sobre o shell a ser usado, pressione kbd:[Enter], que será exibido um prompt `#`. Insira o comando `mount -urw /` para remontar o sistema de arquivos raiz no modo de leitura e gravação e, em seguida, execute o comando `mount -a` para remontar todos os sistemas de arquivos. Execute o comando `passwd root` para alterar a senha do usuário `root` e então execute o comando man:exit[1] para continuar a inicialização. [NOTE] ==== Se você ainda for solicitado a entrar com a senha do usuário `root` ao entrar no modo single user único, isso significa que o console foi configurado como `inseguro` no arquivo [.filename]#/etc/ttys#. Neste caso, será necessário inicializar a partir de um disco de instalação do FreeBSD, escolher o [.guimenuitem]#Live CD# ou [.guimenuitem]#Shell# no início do processo de instalação e executar os comandos mencionados acima. Monte a partição específica neste caso e, em seguida, execute o chroot para ela. Por exemplo, substitua `mount -urw /` por `mount /dev/ada0p1 /mnt; chroot /mnt` para um sistema em instalado em _ada0p1_. ==== [NOTE] ==== Se a partição raiz não puder ser montada a partir do modo de usuário único, é possível que as partições estejam criptografadas e será impossível montá-las sem as chaves de acesso. Para obter mais informações, consulte a seção sobre discos criptografados no extref:{handbook}disks[Handbook, disks-encrypting] do FreeBSD. ==== === Como evito que a combinação de teclas ControlAltDelete reinicialize o sistema? Ao usar man:vt[4], o driver de console padrão, isso pode ser feito configurando o seguinte sysctl man:sysctl[8]: [source,shell] .... # sysctl kern.vt.kbd_reboot=0 .... === Como faço para converter arquivos de texto do DOS para UNIX? Use este comando man:perl[1]: [source,shell] .... % perl -i.bak -npe 's/\r\n/\n/g' file(s) .... no qual _files(s)_ trata-se de um ou mais arquivos que desejamos processar. A modificação é feita in-place, o arquivo original é preservado com uma extensão [.filename]#.bak#. Alternativamente, use o man:tr[1]: [source,shell] .... % tr -d '\r' < dos-text-file > unix-file .... O _dos-text-file_ é o arquivo que contém o texto no formato DOS, enquanto o _unix-file_ contém a saída convertida. Esta opção pode ser um pouco mais rápida do que usar o `perl`. Uma outra maneira de reformatar arquivos de texto do DOS é usar o port package:converters/dosunix[] da Coleção de Ports. Consulte a sua documentação para maiores detalhes. === Como faço para reler o arquivo /etc/rc.conf e reiniciar o /etc/rc sem dar boot? Entre no modo single user e retorne ao modo multi usuário: [source,shell] .... # shutdown now # return # exit .... === Tentei atualizar o meu sistema para a versão -STABLE mais recente, mas obtive a -BETAx, -RC ou -PRERELEASE! O que está acontecendo? Resposta curta: é apenas um nome. _RC_ significa "Release Candidate". Isso significa que uma nova release é iminente. No FreeBSD, _-PRERELEASE_ é tipicamente sinônimo do congelamento de código antes de uma release. (Para algumas versões, o rótulo _-BETA_ foi usado da mesma forma que o _-PRERELEASE_.) Resposta longa: o FreeBSD deriva suas releases de um de dois lugares. Releases principais (major) ponto-zero, como a 9.0-RELEASE são derivadas a partir do branch principal de desenvolvimento, comumente referida como <>. Releases secundárias (minor), como a 6.3-RELEASE ou a 5.2-RELEASE, foram snapshots da branch <> ativa. A partir do 4.3-RELEASE, cada release também tem sua própria branch, a qual pode ser seguida por pessoas que exigem uma taxa extremamente conservadora de desenvolvimento (geralmente apenas avisos de segurança). Quando um release está prestes a ser feito, o branch do qual ele será derivado tem que passar por um determinado processo. Parte desse processo é um congelamento de código. Quando um congelamento de código é iniciado, o nome da branch é alterado para refletir que está prestes a se tornar uma release. Por exemplo, se a ramificação costumava ser chamada de 6.2-STABLE, seu nome será alterado para 6.3-PRERELEASE para indicar o congelamento de código e indicar que testes extras de pré-release devem estar acontecendo. Correções de bugs ainda podem ser adicionadas ao repositório de código fonte para fazer parte da release. Quando o código-fonte estiver estabilizado para a release, o nome será alterado para 6.3-RC para indicar que uma release está prestes a ser feita a partir dele. Uma vez no estágio RC, somente os bugs mais críticos que forem encontrados podem ser corrigidos. Uma vez que o release (6.3-RELEASE neste exemplo) e o branch de release foram feitos, o branch será renomeado para 6.3-STABLE. Para mais informações sobre números de versão e as várias branches do Subversion, consulte o artigo extref:{releng}[Release Engineering]. === Tentei instalar um novo kernel, e o chflags1 falhou. Como faço para contornar isso? Resposta curta: o nível de segurança é maior que 0. Reinicialize diretamente para o modo de single user para instalar o kernel. Resposta longa: O FreeBSD não permite alterar os flags do sistema em níveis de segurança superiores a 0. Para verificar o nível de segurança atual: [source,shell] .... # sysctl kern.securelevel .... O nível de segurança não pode ser diminuído no modo multiusuário, portanto, inicialize no modo single user para instalar o kernel ou altere o nível de segurança em [.filename]#/etc/rc.conf# e reinicialize. Veja a página de manual man:init[8] para detalhes sobre o `securelevel`, e veja [.filename]#/etc/defaults/rc .conf# e a página de manual man:rc.conf[5] para mais informações sobre o [.filename]#rc.conf#. === Não consigo alterar a hora no meu sistema em mais de um segundo! Como faço para contornar isso? Resposta curta: o sistema está em um nível de segurança maior que 1. Reinicialize diretamente para o modo de single user para alterar a data. Resposta longa: O FreeBSD proíbe a alteração do tempo em mais de um segundo em níveis de segurança superiores a 1. Para verificar o nível de segurança: [source,shell] .... # sysctl kern.securelevel .... O nível de segurança não pode ser diminuído no modo multiusuário. Inicialize no modo single user para alterar a data ou altere o nível de segurança no arquivo [.filename]#/etc/rc.conf# e reinicialize. Veja a página de manual man:init[8] para detalhes sobre o `securelevel`, e veja [.filename]#/etc/defaults/rc .conf# e a página de manual man:rc.conf[5] para mais informações sobre o [.filename]#rc.conf#. === Por que o rpc.statd está usando 256 MB de memória? Não, não há vazamento de memória e ele não está usando 256 MB de memória. Por conveniência, o `rpc.statd` mapeia uma quantidade obscena de memória em seu espaço de endereço. Não há nada terrivelmente errado com isso do ponto de vista técnico; mas isso confunde o man:top[1] e o man:ps[1]. O man:rpc.statd[8] mapeia seu arquivo de status (residente no [.filename]#/var#) em seu espaço de endereçamento; para evitar se preocupar com o remapeamento do arquivo de status mais tarde quando ele precisar crescer, ele mapeia o arquivo de status com um tamanho generoso. Isso é muito evidente no código-fonte, onde é possível ver que o argumento length para o man:mmap[2] é `0x10000000` , ou décima sexta parte do espaço de endereço em um IA32, ou seja, exatamente 256 MB. === Por que não posso dar unset na flag schg de um arquivo? O sistema está sendo executado em um nível de segurança maior que 0. Reduza o nível de segurança e tente novamente. Para obter mais informações, consulte <> e a página de manual do man:init[8]. === O que é vnlru? O `vnlru` descarrega e libera vnodes quando o sistema atinge o limite de `kern.maxvnodes`. Essa thread do kernel fica ociosa na maior parte do tempo e só é ativada quando existe uma quantidade enorme de RAM e os usuários estiverem acessando dezenas de milhares de arquivos minúsculos. === O que os vários estados de memória exibidos pelo top significam? * `Active`: são páginas usadas recentemente. * `Inactive`: são páginas que não foram utilizadas recentemente. * `Laundry`: páginas recentemente não utilizadas estatisticamente, mas conhecidas por estarem sujas, ou seja, cujo conteúdo precisa ser paginado antes que possa ser reutilizado. * `Free`: páginas sem conteúdo, que podem ser reutilizadas imediatamente. * `Wired`: são páginas que estão fixadas na memória, geralmente para propósitos do kernel, mas também para uso especial em processos. As páginas geralmente são gravadas em disco (um tipo de sincronização de VM) quando elas estão no estado laundry, mas as páginas ativas ou inativas também podem ser sincronizadas. Isso depende do rastreamento da CPU do bit modificado estar disponível e, em determinadas situações pode haver uma vantagem para um bloco de páginas da VM serem sincronizadas, independentemente da fila a que pertencem. Na maioria dos casos, é melhor pensar na fila laundry como uma fila de páginas relativamente não usadas que podem ou não estar no processo de serem gravadas no disco. A fila inativa contém uma mistura de páginas limpas e sujas; as páginas limpas próximas ao início da fila são recuperadas imediatamente para aliviar a falta de páginas livres e as páginas sujas são movidas para a fila laundry para processamento posterior. Existem alguns outros flags (por exemplo, flag de ocupado ou de contagem ocupada) que podem modificar algumas das regras descritas. === Quanta memória livre está disponível? Existem alguns tipos de "memória livre". O mais comum é a quantidade de memória disponível imediatamente, sem recuperar a memória já em uso. Esse é o tamanho da fila de páginas livres mais algumas outras páginas reservadas. Esse valor é exportado pelo `vm.stats.vm.v_free_count` man:sysctl[8], mostrado, por exemplo, pelo man:top[1]. Outro tipo de "memória livre" é a quantidade total de memória virtual disponível para os processos da área de usuário, que depende da soma do espaço de swap e da memória utilizável. Outros tipos de descrições de "memória livre" também são possíveis, mas é relativamente inútil defini-las, mas é importante garantir que a taxa de paginação seja mantida baixa e evitar ficar sem espaço de swap. === O que é o /var/empty? O [.filename]#/var/empty# é um diretório que o programa man:sshd[8] utiliza ao executar a separação de privilégios. O diretório [.filename]#/var/empty# está vazio, pertence ao usuário `root` e possui as flags `schg` definidas. Este diretório não deve ser excluído. === Acabei de alterar o /etc/newsyslog.conf . Como posso verificar se ele faz o que eu espero? Para ver o que man:newsyslog[8] vai fazer, use o seguinte: [source,shell] .... % newsyslog -nrvv .... === Minha hora está errada, como posso mudar o fuso horário? Use o man:tzsetup[8]. == O sistema X Window e consoles virtuais === O que é o sistema X Window? O sistema de janelas X (comumente chamado de `X11`) é o sistema de janelas mais amplamente disponível capaz de executar em Sistemas UNIX(TM) e sistemas UNIX(TM)-Like, incluindo o FreeBSD. A http://www.x.org/wiki/[Fundação X.Org] administra os http://en.wikipedia.org/wiki/X_Window_System_core_protocol[ padrões de protocolo X], sendo que a implementação de referência atual é a versão 11 release 7.7, então as referências são frequentemente encurtadas para `X11`. Muitas implementações estão disponíveis para diferentes arquiteturas e sistemas operacionais. Uma implementação do código do lado do servidor é conhecida como um `Servidor X`. === Eu quero rodar o Xorg, como faço para isso? Para instalar o Xorg, siga um destes procedimentos: Use o meta-port package:x11/xorg[], que constrói e instala todos os componentes do Xorg. Use package:x11/xorg-minimal[], que constrói e instala apenas os componentes Xorg necessários. Instale o Xorg a partir de pacotes do FreeBSD: [source,shell] .... # pkg install xorg .... Após a instalação do Xorg, siga as instruções da seção extref:{handbook}x11[Configuração X11, x-config] do Handbook do FreeBSD. === Eu tentei executar o X, mas eu recebo um erro No devices detected. quando eu digito startx. O que eu faço agora? O sistema provavelmente está sendo executado em um `securelevel` alto. Não é possível iniciar o X em `securelevel` alto porque o X requer acesso de ao man:io[4]. Para obter mais informações, consulte a página de manual do man:init[8]. Existem duas soluções para o problema: definir o `securelevel` novamente a zero ou executar man:xdm[1] (ou um gerenciador de exibição alternativo) no momento da inicialização antes que o `securelevel` seja elevado. Veja <> para mais informações sobre como executar o man:xdm[1] no momento da inicialização. === Por que meu mouse não funciona com o X? Ao usar man:vt[4], o driver de console padrão, o FreeBSD pode ser configurado para suportar um ponteiro de mouse em cada tela virtual. Para evitar conflito com o X, o man:vt[4] suporta um dispositivo virtual chamado [.filename]#/dev/sysmouse#. Todos os eventos de mouse recebidos do dispositivo de mouse real são gravados no dispositivo via man:sysmouse[4]man:moused[8]. Para usar o mouse em um ou mais consoles virtuais, _e_ usar X, veja <> e configure o man:moused[8]. Em seguida, edite o arquivo [.filename]#/etc/X11/xorg.conf# e verifique se as seguintes linhas existem: [.programlisting] .... Section "InputDevice" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" ..... .... Começando com a versão 7.4 do Xorg, as seções `InputDevice` no [.filename]#xorg.conf# são ignoradas em favor dos dispositivos autodetectados. Para restaurar o comportamento antigo, adicione a seguinte linha à seção `ServerLayout` ou `ServerFlags`: [.programlisting] .... Option "AutoAddDevices" "false" .... Algumas pessoas preferem usar o [.filename]#/dev/mouse# com o X. Para fazer esse trabalho, [.filename]#/dev/mouse# deve estar vinculado a [.filename]#/dev/sysmouse# (veja man:sysmouse[4]) adicionando a seguinte linha ao [.filename]#/etc/devfs.conf# (veja man:devfs.conf[5]): [.programlisting] .... link sysmouse mouse .... Este link pode ser criado reiniciando o man:devfs[5] com o seguinte comando (executado como `root`): [source,shell] .... # service devfs restart .... === Meu mouse tem uma fancy wheel. Posso usá-lo no X? Sim, se o X estiver configurado para um mouse de 5 botões. Para fazer isso, adicione as linhas `Buttons 5` e `ZAxisMapping 4 5` na seção "InputDevice" do arquivo [.filename]#/etc/X11/xorg.conf#, como visto neste exemplo: [.programlisting] .... Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection .... O mouse pode ser habilitado no Emacs adicionando estas linhas ao [.filename]#~/.emacs#: [.programlisting] .... ;; wheel mouse (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) .... === Meu laptop tem um touchpad Synaptics. Posso usá-lo no X? Sim, depois de configurar algumas coisas para que funcione. Para usar o driver synaptics do Xorg, primeiro remova `moused_enable` do [.filename]#rc.conf#. Para habilitar a synaptics, adicione a seguinte linha ao [.filename]#/boot/loader.conf#: [.programlisting] .... hw.psm.synaptics_support="1" .... Adicione o seguinte ao [.filename]#/etc/X11/xorg.conf#: [.programlisting] .... Section "InputDevice" Identifier "Touchpad0" Driver "synaptics" Option "Protocol" "psm" Option "Device" "/dev/psm0" EndSection .... E não se esqueça de adicionar o seguinte na seção "ServerLayout": [.programlisting] .... InputDevice "Touchpad0" "SendCoreEvents" .... === Como eu uso displays X remotos? Por motivos de segurança, a configuração padrão é não permitir que uma máquina abra remotamente uma janela. Para ativar esse recurso, inicie o X com o argumento opcional `-listen_tcp`: [source,shell] .... % startx -listen_tcp .... === O que é um console virtual e como faço outros? Os consoles virtuais fornecem várias sessões simultâneas na mesma máquina sem fazer nada complicado, como configurar uma rede ou executar o X. Quando o sistema iniciar, ele exibirá um prompt de login no monitor depois de exibir todas as mensagens de inicialização. Digite seu nome de login e senha para começar a trabalhar no primeiro console virtual. Para iniciar outra sessão, talvez para examinar a documentação de um programa ou para ler mensagens enquanto aguarda a conclusão de uma transferência por FTP, pressione kbd:[Alt] e pressione kbd:[F2]. Isso exibirá o prompt de login do segundo console virtual. Para voltar à sessão original, pressione kbd:[Alt+F1]. A instalação padrão do FreeBSD possui oito consoles virtuais habilitados. A combinação de teclas kbd:[ Alt + F1 ], kbd:[ Alt + F2 ], kbd:[ Alt + F3 ], e assim por diante alternará entre esses consoles virtuais. Para habilitar mais consoles virtuais, edite [.filename]#/etc/ttys# (veja man:ttys[5]) e adicione entradas do [.filename]#ttyv8# até o [.filename]#ttyvc#, após os comentários na seção "Virtual terminals": [.programlisting] .... # Edit the existing entry for ttyv8 in /etc/ttys and change # "off" to "on". ttyv8 "/usr/libexec/getty Pc" xterm on secure ttyv9 "/usr/libexec/getty Pc" xterm on secure ttyva "/usr/libexec/getty Pc" xterm on secure ttyvb "/usr/libexec/getty Pc" xterm on secure .... Quanto mais terminais virtuais estiverem ativos, mais recursos serão usados. Isso pode ser um problema em sistemas com 8 MB de RAM ou menos. Considere mudar a opção `secure` para `insecure`. [IMPORTANT] ==== Para executar um servidor X, pelo menos um terminal virtual deverá ser deixado como `off` para ele usar. Isso significa que apenas onze das teclas de função Alt podem ser usadas como consoles virtuais, de modo que uma deverá ser deixada livre para uso do servidor X. ==== Por exemplo, para executar o X e onze consoles virtuais, a configuração para o terminal virtual 12 deve ser: [.programlisting] .... ttyvb "/usr/libexec/getty Pc" xterm off secure .... A maneira mais fácil de ativar os consoles virtuais é reinicializar. === Como eu acesso os consoles virtuais a partir do X? Utilize kbd:[Ctrl+Alt+Fn] para voltar a um console virtual. Pressione kbd:[ Ctrl + Alt + F1 ] para retornar ao primeiro console virtual. Uma vez em um console de texto, use kbd:[ Alt + F n ] para mover-se entre eles. Para retornar à sessão X, mude para o console virtual que está executando o X. Se o X foi iniciado a partir da linha de comando usando `startx`, a sessão X será anexada ao próximo console virtual não utilizado, e não ao console de texto no qual foi invocado. Para oito terminais virtuais ativos, o X será executado no nono, portanto use kbd:[ Alt + F9 ]. [[xdm-boot]] === Como faço para carregar o XDM na inicialização? Existem duas escolas de pensamento sobre como iniciar o man:xdm[1]. Uma escola inicia o `xdm` a partir do [.filename]#/etc/ttys# (veja man:ttys[5]) usando o exemplo fornecido, enquanto o outro executa o `xdm` a partir do [.filename]#rc.local# (veja man:rc[8]) ou de um script [.filename]#X# localizado em [.filename]#/usr/local/etc/rc.d#. Ambos são igualmente válidos, e um pode funcionar em situações em que o outro não funciona. Em ambos os casos, o resultado é o mesmo: O X mostrará um prompt de login gráfico. O método man:ttys[5] tem a vantagem de documentar qual vty X iniciará e passando a responsabilidade de reiniciar o servidor X no logout para o man:init[8]. O método man:rc[8] facilita o `kill xdm` se houver um problema ao iniciar o servidor X. Se carregado pelo man:rc[8], o `xdm` deve ser iniciado sem nenhum argumento. `xdm` deve iniciar _após_ o man:getty[8] ser executado, ou então `getty` e `xdm` entrarão em conflito, bloqueando o console. A melhor maneira de contornar isso é fazer com que o script espere 10 segundos ou mais e, em seguida, iniciar o `xdm`. Ao iniciar o `xdm` pelo [.filename]#/etc/ttys#, ainda há uma chance de conflito entre `xdm` e man:getty[8]. Uma maneira de evitar isso é adicionar o número `vt` no arquivo [.filename]#/usr/local/lib/X11/xdm/Xservers#: [.programlisting] .... :0 local /usr/local/bin/X vt4 .... O exemplo acima irá direcionar o servidor X para ser executado em [.filename]#/dev/ttyv3#. Observe que o número é compensado por um. O servidor X conta a vty a partir de 1, enquanto o kernel do FreeBSD numera a vty a partir de zero. === Por que eu obtenho o erro Couldn't open console quando executo o xconsole? Quando o X é iniciado com o comando `startx`, as permissões em [.filename]#/dev/console#_não_ serão alteradas, o que resultará um comportamento errático de algumas coisas tais como o não funcionamento do `xterm -C` e do `xconsole`. Isso ocorre devido à maneira como as permissões do console são definidas por padrão. Em um sistema multiusuário, não é necessário que qualquer usuário possa escrever no console do sistema. Para os usuários que estão logando diretamente em uma máquina com um VTY, existe o arquivo man:fbtab[] para resolver tais problemas. Em poucas palavras, certifique-se de que uma linha não comentada do formulário esteja no [.filename]#/etc/fbtab# (veja man:fbtab[5]): [.programlisting] .... /dev/ttyv0 0600 /dev/console .... Ele irá garantir que quem fizer o login em [.filename]#/dev/ttyv0# será o dono do console. === Por que meu mouse PS/2 não funciona direito no X? O mouse e o driver do mouse podem estar fora de sincronização. Em casos raros, o driver também pode relatar erroneamente erros de sincronização: [.programlisting] .... psmintr: out of sync (xxxx != yyyy) .... Se isso acontecer, desative o código de verificação de sincronização definindo as flags de driver para o driver de mouse PS/2 como `0x100`. Isto pode ser mais facilmente alcançado adicionando `hint.psm.0.flags="0x100"` ao arquivo [.filename]#/boot/loader.conf# e reiniciando. === Como eu inverto os botões do mouse? Digite `xmodmap -e "pointer = 3 2 1"`. Adicione este comando ao [.filename]#~/.xinitrc# ou [.filename]#~/.xsession# para que isso aconteça automaticamente. === Como faço para instalar uma splash screen e onde posso encontrá-las? A resposta detalhada para essa pergunta pode ser encontrada na seção extref:{handbook}boot[Telas de inicialização do tempo de inicialização, boot-splash] do FreeBSD Handbook. === Posso usar as teclas do Windows do meu teclado no X? Sim. Use o man:xmodmap[1] para definir quais funções as teclas devem executar. Supondo que todos os teclados Windows sigam um padrão, os códigos de teclas para essas três teclas são os seguintes: * 115 - tecla kbd:[ Windows ], entre as teclas kbd:[ Ctrl ] e kbd:[ Alt ] do lado esquerdo * 116 - tecla kbd:[ Windows ], à direita de kbd:[ AltGr ] * 117 - kbd:[ Menu ], à esquerda da tecla kbd:[Ctrl] da direita Para que a tecla kbd:[ Windows ] da esquerda imprima uma vírgula, tente isto. [source,shell] .... # xmodmap -e "keycode 115 = comma" .... Para que os mapeamentos de teclas kbd:[Windows] sejam ativados automaticamente toda vez que X for iniciado, coloque os comandos `xmodmap` em [.filename]#~/.xinitrc# ou, preferencialmente, crie um [.filename]#~/.xmodmaprc# e inclua as opções `xmodmap`, uma por linha, e adicione a seguinte linha ao [.filename]#~/.xinitrc#: [.programlisting] .... xmodmap $HOME/.xmodmaprc .... Por exemplo, para mapear as 3 chaves para serem kbd:[F13], kbd:[F14] e kbd:[F15], respectivamente. Isso facilitaria mapeá-los para funções úteis em aplicativos ou no gerenciador de janelas. Para fazer isto, coloque o seguinte em [.filename]#~/.xmodmaprc#. [.programlisting] .... keycode 115 = F13 keycode 116 = F14 keycode 117 = F15 .... Para o gerenciador da área de trabalho package:x11-wm/fvwm2[], pode-se mapear as chaves para que kbd:[F13] seja minimizada a janela em que o cursor está ou a maximize, kbd:[F14] traz a janela em que o cursor está para a frente ou, se já estiver na frente, a coloca em background kbd:[F15] aparece no menu principal do Workplace mesmo que o cursor não esteja a área de trabalho, o que é útil quando nenhuma parte da área de trabalho está visível. As seguintes entradas em [.filename]#~/.fvwmrc# implementam a configuração acima mencionada: [.programlisting] .... Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop .... === Como posso obter aceleração de hardware 3D para o OpenGL ? A disponibilidade da aceleração 3D depende da versão do Xorg e do tipo de chip de vídeo. Para um chip da nVidia, use os drivers binários fornecidos para o FreeBSD instalando um dos seguintes ports: As versões mais recentes das placas nVidia são suportadas pelo port package:x11/nvidia-driver[]. Drivers mais antigos estão disponíveis como package:x11/nvidia-driver-###[] A nVidia fornece informações detalhadas sobre qual placa é suportada por qual driver em seu site: http://www.nvidia.com/object/IO_32667.html[http://www.nvidia.com /object/IO_32667.html]. Para a Matrox G200/G400, verifique o port package:x11-drivers/xf86-video-mga[]. Para a ATI Rage 128 e Radeon, consulte man:ati[4], man:r128[4] and man:radeon[4]. == Networking === Onde posso obter informações sobre a inicialização sem disco? "Inicialização sem disco" significa que o sistema FreeBSD é inicializado através de uma rede e lê os arquivos necessários de um servidor ao invés de seu disco rígido. Para maiores detalhes, consulte a entrada do Handbook extref:{handbook}advanced-networking[Inicialização sem disco, network-diskless]. === Uma maquina FreeBSD pode ser usada como um roteador de rede dedicado? Sim. Consulte a entrada do Manual em extref:{handbook}advanced-networking[rede avançada, advanced-networking], especificamente a seção sobre extref:{handbook}advanced-networking[roteamento e gateways, network-routing]. === O FreeBSD suporta NAT ou Mascaramento de IPs? Sim. Para obter instruções sobre como usar o NAT em uma conexão PPP, consulte a seção do extref:{handbook}ppp-and-slip[PPP, userppp] no manual. Para usar o NAT em algum outro tipo de conexão de rede, consulte a seção extref:{handbook}[natd, network-natd] do manual. === Como posso configurar aliases de Ethernet? Se o alias estiver na mesma sub-rede que um endereço já configurado na interface, adicione `netmask 0xffffffff` a este comando: [source,shell] .... # ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff .... Caso contrário, especifique o endereço de rede e a máscara de rede como de costume: [source,shell] .... # ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00 .... Mais informações podem ser encontradas extref:{handbook}config-tuning[Handbook, configtuning-virtual-hosts] do FreeBSD. === Por que não posso montar o NFS de uma máquina Linux? Algumas versões do código NFS do Linux(TM) aceitam somente solicitações de montagem vindas de uma porta privilegiada; tente executar o seguinte comando: [source,shell] .... # mount -o -P linuxbox:/blah /mnt .... === Por que o comando mountd continua me dizendo que ele can't change attributes (não pode alterar os atributos) e que eu tenho uma bad exports list (lista de exports ruins) no meu servidor NFS do FreeBSD? O problema mais freqüente é não entender o formato correto de [.filename]#/etc/exports#. Revise man:exports[5] e o extref:{handbook}network-servers[NFS, network-nfs] no manual, especialmente na seção extref:{handbook}[configurando o NFS, configuring-nfs]. === Como faço para ativar o suporte a multicast IP? Instale o pacote ou port package:net/mrouted[] e adicione `mrouted_enable="YES"` ao [.filename]#/etc/rc.conf# para que o FreeBSD inicie este serviço no momento da inicialização. === Por que preciso usar o FQDN para hosts na minha rede? Veja a resposta no extref:{handbook}mail[Handbook, mail-trouble] do FreeBSD. === Por que recebo oerro, Permission denied, para todas as operações de rede? Se o kernel é compilado com a opção `IPFIREWALL`, esteja ciente de que a política padrão é negar todos os pacotes que não são explicitamente permitidos. Se o firewall foi inadvertidamente configurado de forma errada, restaure a operacionalidade da rede digitando o seguinte comando como `root`: [source,shell] .... # ipfw add 65534 allow all from any to any .... Considere configurar a opção `firewall_type="open"` no [.filename]#/etc/rc.conf#. Para obter mais informações sobre como configurar seu firewall, consulte o extref:{handbook}firewalls[Handbook, firewalls-ipfw]. === Por que minha regra ipfw fwd para redirecionar um serviço para outra máquina que não está funcionando? Possivelmente porque você precisa utilizar a conversão de endereços de rede (NAT) em vez de apenas encaminhar os pacotes. Uma regra "fwd" apenas encaminha os pacotes, ela não altera os dados dentro do pacote. Considere esta regra: [source,shell] .... 01000 fwd 10.0.0.1 from any to foo 21 .... Quando um pacote com um endereço de destino _foo_ chega à máquina com esta regra, o pacote é encaminhado para _10.0.0.1_, mas ainda tem o endereço de destino _foo_. O endereço de destino do pacote não é alterado para _10.0.0.1_. A maioria das máquinas provavelmente descartaria um pacote que recebesse com um endereço de destino que não fosse o seu. Portanto, usar uma regra "fwd" geralmente não funciona da maneira esperada pelo usuário. Esse comportamento é um recurso e não um bug. Veja o <>, o manual do man:natd[8], ou um dos vários utilitários de redirecionamento de porta na https://www.FreeBSD.org/ports/[Coleção de Portas] para uma maneira correta de fazer isso. === Como posso redirecionar as solicitações de serviço de uma máquina para outra? FTP e outras solicitações de serviço podem ser redirecionadas com o pacote ou port package:sysutils/socket[]. Substitua a entrada para o serviço em [.filename]#/etc/inetd.conf# para chamar `socket`, conforme visto neste exemplo para ftpd: [.programlisting] .... ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp .... na qual _ftp.example.com_ e _ftp_ são o host e a porta de destino do redirecionamento, respectivamente. === Onde posso obter uma ferramenta de gerenciamento de largura de banda? Existem três ferramentas de gerenciamento de largura de banda disponíveis para o FreeBSD. man:dummynet[4] é integrado ao FreeBSD como parte do man:ipfw[4]. http://www.sonycsl.co.jp/person/kjc/programs.html[ALTQ] foi integrado ao FreeBSD como parte do man:pf[4]. O Bandwidth Manager das http://www.etinc.com/[ Tecnologias Emergentes ] é um produto comercial. === Por que estou recebendo o erro /dev/bpf0: device not configured? O aplicativo em execução requer o Packet Filter da Berkeley (man:bpf[4]), mas ele foi removido de um kernel personalizado. Adicione isto ao arquivo de configuração do kernel e construa um novo kernel: [.programlisting] .... device bpf # Berkeley Packet Filter .... === Como faço para montar um disco de uma máquina Windows que esteja na minha rede, tal como o smbmount no Linux? Use o conjunto de ferramentas SMBFS. Ele inclui um conjunto de modificações do kernel e um conjunto de programas da área de usuário. Os programas e as informações necessárias estão disponíveis como man:mount_smbfs[8] no sistema base. === O que são essas mensagens sobre: ​​Limiting icmp/open port/closed port response em meus arquivos de log? Esta mensagem do kernel indica que alguma atividade está provocando o envio de uma grande quantidade de respostas de reset de ICMP ou TCP (RST). As respostas ICMP são frequentemente geradas como resultado de tentativas de conexão a portas UDP não utilizadas. Os resets TCP são geradas como resultado de tentativas de conexão a portas TCP não abertas. Entre outros, esses são os tipos de atividades que podem causar essas mensagens: * Ataques de negação de serviço (DoS) de força bruta (em oposição a ataques de pacote único que exploram uma vulnerabilidade específica). * Varreduras de porta que tentam se conectar a um grande número de portas (em oposição a apenas tentar algumas portas conhecidas). O primeiro número na mensagem indica quantos pacotes o kernel teria enviado se o limite não estivesse no lugar e o segundo indica o limite. Este limite é controlado usando `net.inet.icmp.icmplim`. Este exemplo define o limite para `300` pacotes por segundo: [source,shell] .... # sysctl net.inet.icmp.icmplim=300 .... Para desativar essas mensagens sem desativar a limitação de resposta, use o `net.inet.icmp.icmplim_output` para desativar a saída: [source,shell] .... # sysctl net.inet.icmp.icmplim_output=0 .... Finalmente, para desabilitar completamente a limitação de resposta, configure `net.inet.icmp.icmplim` para `0`. Desabilitar a limitação de resposta é desencorajado pelos motivos listados acima. === O que são essas mensagens de erro arp: unknown hardware address format? Isso significa que algum dispositivo na Ethernet local está usando um endereço MAC em um formato que o FreeBSD não reconhece. Isso provavelmente é causado por alguém que está experimentando uma placa Ethernet em algum outro lugar da rede. Isso é mais comumente visto em redes de modem a cabo. É inofensivo e não deve afetar o desempenho do sistema FreeBSD. === Por que eu continuo vendo mensagens como: 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0, e como desabilitá-lo? Porque um pacote está vindo de fora da rede inesperadamente. Para desativá-los, defina `net.link.ether.inet.log_arp_wrong_iface` como `0`. === Como faço para compilar um kernel com suporte somente ao IPv6? Configure seu kernel com estas configurações: [source,shell] .... include GENERIC ident GENERIC-IPV6ONLY makeoptions MKMODULESENV+="WITHOUT_INET_SUPPORT=" nooptions INET nodevice gre .... == Segurança === O que é uma caixa de areia (sandbox)? "Sandbox" é um termo de segurança. Isso pode significar duas coisas: * Um processo que é colocado dentro de um conjunto de paredes virtuais que são projetadas para impedir que alguém que interrompa o processo seja capaz de invadir o sistema mais amplo. + O processo só é capaz de correr dentro das barreiras. Desde que nada que o processo faça em relação à execução de código seja capaz de violar as barreiras, uma auditoria detalhada de seu código não é necessária para poder dizer certas coisas sobre sua segurança. + As barreiras podem ser um ID do usuário, por exemplo. Esta é a definição usada nas páginas de manual de man:security[7] e man:named[8]. + Veja o serviço `ntalk`, por exemplo (veja man:inetd[8]). Este serviço costumava rodar como ID de usuário `root`. Agora ele é executado como ID do usuário `tty`. O usuário `tty` é um sandbox projetado para tornar mais difícil para alguém que invadiu o sistema com sucesso através do `ntalk` ser capaz de hackear além do seu ID de usuário. * Um processo que é colocado dentro de uma simulação da máquina. Isso significa que alguém que é capaz de entrar no processo pode acreditar que ele pode invadir a máquina mais ampla, mas está, na verdade, apenas invadindo uma simulação dessa máquina e não modificando nenhum dado real. + A maneira mais comum de fazer isso é construir um ambiente simulado em um subdiretório e então executar os processos nesse diretório chrooted para que o diretório [.filename]#/# para esse processo seja este, não o diretório [.filename]#/# real do sistema). + Outro uso comum é montar um sistema de arquivos subjacente somente leitura e, em seguida, criar uma camada do sistema de arquivos sobre ele, o que dá a um processo uma visualização aparentemente gravável nesse sistema de arquivos. O processo pode acreditar que é capaz de escrever nesses arquivos, mas o processo apenas vê os efeitos - outros processos no sistema não, necessariamente. + Foi feita uma tentativa de tornar esse tipo de sandbox tão transparente que o usuário (ou hacker) não percebe que está dentro dele. O UNIX(TM) implementa dois sandboxes principais. Um está no nível do processo e o outro está no nível do usuário. Todo processo UNIX(TM) é completamente protegido contra qualquer outro processo UNIX(TM). Um processo não pode modificar o espaço de endereço de outro. Um processo UNIX(TM) é de propriedade de um determinado ID de usuário. Se o ID de usuário não for o usuário `root`, ele servirá para proteger o processo contra processos pertencentes a outros usuários. O ID do usuário também é usado para proteger os dados no disco. === O que é securelevel? `securelevel` é um mecanismo de segurança implementado no kernel. Quando o nível de segurança é positivo, o kernel restringe certas tarefas; nem mesmo o superusuário (`root`) pode executá-los. O mecanismo de securelevel limita a capacidade de: * Desativar determinados flags de arquivo, tais como `schg` (o flag de sistema imutável). * Escrever na memória do kernel através de [.filename]#/dev/mem# e [.filename]#/dev/kmem#. * Carregar módulos do kernel. * Alterar as regras do firewall. Para verificar o status do securelevel em um sistema em execução: [source,shell] .... # sysctl -n kern.securelevel .... A saída contém o valor atual do nível de segurança. Se for maior que 0, pelo menos algumas das proteções do securelevel são ativadas. O securelevel de um sistema em execução não pode ser reduzido, pois isso invalidaria seu propósito. Se uma tarefa exigir que o securelevel seja não-positivo, altere as variáveis ​​`kern_securelevel` e `kern_securelevel_enable` em [.filename]#/etc/rc.conf# e reinicialize. Para obter mais informações sobre o securelevel e as coisas específicas que todos os níveis fazem, consulte man:init[8]. [WARNING] ==== O securelevel não é uma bala de prata; tem muitas deficiências conhecidas. Mais frequentemente do que não, fornece uma falsa sensação de segurança. Um dos seus maiores problemas é que, para que seja eficaz, todos os arquivos usados ​​no processo de inicialização até que o nível de segurança seja definido devem ser protegidos. Se um invasor puder fazer o sistema executar seu código antes do nível de segurança que está sendo definido (o que acontece muito tarde no processo de inicialização, pois algumas coisas que o sistema deve fazer na inicialização não podem ser feitas em um nível elevado), suas proteções são invalidadas . Embora essa tarefa de proteger todos os arquivos usados ​​no processo de inicialização não seja tecnicamente impossível, se for obtida, a manutenção do sistema se tornará um pesadelo, já que seria necessário desativar o sistema, pelo menos no modo de usuário único, para modificar um arquivo de configuração. Este ponto e outros são frequentemente discutidos nas listas de discussão, particularmente na http://lists.FreeBSD.org/mailman/listinfo/freebsd-security[lista de discussão de segurança do FreeBSD]. Pesquise nos arquivos https://www.FreeBSD.org/search/[aqui] para uma discussão extensa. Um mecanismo mais refinado é o preferido. ==== === O que é essa conta UID 0 toor? Eu fui comprometido? Não se preocupe. `toor` é uma conta de superusuário "alternativa", onde toor é root soletrada para ao contrário. Ele deve ser usado com um shell não padrão, portanto, o shell padrão para `root` não precisa ser alterado. Isto é importante porque os shells que não fazem parte da distribuição base, mas que são instalados a partir de ports ou packages, são instalados em [.filename]#/usr/local/bin# que, por padrão, reside em um sistema de arquivos diferente . Se o shell do `root` estiver localizado em [.filename]#/usr/local/bin# e o sistema de arquivos contendo [.filename]#/usr/local/bin#) não está montado, `root` não poderá efetuar login para corrigir um problema e terá que reinicializar no modo de usuário único para inserir o caminho para um shell. Algumas pessoas usam `toor` para tarefas do dia-a-dia do `root` com um shell não padrão, deixando o `root`, com um shell padrão, para o modo de usuário único ou emergências. Por padrão, um usuário não pode logar usando `toor` porque ele não tem uma senha, então efetue login como `root` e defina um senha para `toor` antes de usá-lo para efetuar login. == Comunicações Seriais Esta seção responde a perguntas comuns sobre comunicação serial com o FreeBSD. === Como obtenho o prompt de boot: em um console serial? Veja extref:{handbook}serialcomms[ esta seção do Handbook, serialconsole-setup]. === Como sei se o FreeBSD encontrou minhas portas seriais ou placas de modem? Quando o kernel do FreeBSD for inicializado, ele irá sondar as portas seriais para as quais o kernel está configurado. Observe atentamente as mensagens de inicialização ou execute este comando após o sistema estar ativo e em execução: [source,shell] .... % grep -E '^(sio|uart)[0-9]' < /var/run/dmesg.boot sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A .... Este exemplo mostra duas portas seriais. O primeiro está no IRQ4, endereço de porta `0x3f8`, e possui um chip UART tipo 16550A. O segundo usa o mesmo tipo de chip, mas está no IRQ3 e está no endereço de porta `0x2f8`. As placas de modem internas são tratadas como portas seriais, exceto pelo fato de sempre terem um modem conectado à porta. O kernel [.filename]#GENERIC# inclui suporte para duas portas seriais usando as mesmas configurações de IRQ e endereço de porta no exemplo acima. Se estas configurações não forem adequadas para o sistema, ou se houver mais placas de modem ou portas seriais do que o kernel está configurado, reconfigure usando as instruções em <> para mais detalhes. === Como eu acesso as portas seriais no FreeBSD? (específico de x86) A terceira porta serial, [.filename]#sio2#, ou [.filename]#COM3#, está em [.filename]#/dev/cuad2# para dispositivos dial-out e em [.filename]#/dev/ttyd2# para dispositivos dial-in. Qual é a diferença entre essas duas classes de dispositivos? Ao abrir [.filename]#/dev/ttydX# no modo de bloqueio, um processo aguardará o dispositivo [.filename]#cuadX# correspondente ficar inativo e, em seguida, aguardar a ativação da linha de detecção. Quando o dispositivo [.filename]#cuadX# é aberto, ele garante que a porta serial não esteja em uso pelo dispositivo [.filename]#ttydX#. Se a porta estiver disponível, ela a rouba do dispositivo [.filename]#ttydX#. Além disso, o dispositivo [.filename]#cuadX# não se importa com a detecção da portadora. Com este esquema e um modem de resposta automática, os usuários remotos podem efetuar login e os usuários locais ainda podem discar com o mesmo modem e o sistema cuidará de todos os conflitos. === Como habilitar o suporte para uma placa serial com várias portas? A seção sobre configuração do kernel fornece informações sobre como configurar o kernel. Para uma placa serial com várias portas, coloque uma linha man:sio[4] para cada porta serial na placa no man:device.hints[5]. Mas coloque os especificadores de IRQ em apenas uma das entradas. Todas as portas no cartão devem compartilhar um IRQ. Para consistência, use a última porta serial para especificar o IRQ. Além disso, especifique a seguinte opção no arquivo de configuração do kernel: [.programlisting] .... options COM_MULTIPORT .... O exemplo a seguir [.filename]#/boot/device.hints# é para uma placa serial AST de 4 portas no IRQ 12: [.programlisting] .... hint.sio.4.at="isa" hint.sio.4.port="0x2a0" hint.sio.4.flags="0x701" hint.sio.5.at="isa" hint.sio.5.port="0x2a8" hint.sio.5.flags="0x701" hint.sio.6.at="isa" hint.sio.6.port="0x2b0" hint.sio.6.flags="0x701" hint.sio.7.at="isa" hint.sio.7.port="0x2b8" hint.sio.7.flags="0x701" hint.sio.7.irq="12" .... Os flags indicam que a porta principal possui um número menor `7` (`0x700`) e todas as portas compartilham um IRQ (`0x001`). === Posso definir os parâmetros seriais padrões para uma porta? Veja a seção extref:{handbook}serialcomms[Comunicações Seriais, serial-hw-config] no Handbook do FreeBSD . === Por que não consigo executar o comando tip ou o cu? Os utilitários man:tip[1] and man:cu[1] só podem acessar o diretório [.filename]#/var/spool/lock# via usuário `uucp` e grupo `dialer` . Use o grupo `dialer` para controlar quem tem acesso ao modem ou sistemas remotos adicionando contas de usuário ao `dialer`. Como alternativa, todos podem ser configurados para executar man:tip[1] e man:cu[1] digitando: [source,shell] .... # chmod 4511 /usr/bin/cu # chmod 4511 /usr/bin/tip .... == Perguntas Diversas === O FreeBSD usa muito espaço de swap mesmo quando o computador tem memória livre sobrando. Por quê? O FreeBSD irá proativamente mover páginas ociosas e não usadas da memória principal para swap, a fim de disponibilizar mais memória principal para uso ativo. Esse uso pesado de swap é balanceado usando a memória extra livre para armazenamento em cache. Note que enquanto o FreeBSD é proativo a esse respeito, ele não decide arbitrariamente trocar páginas quando o sistema está realmente inativo. Assim, o sistema não será todo paginado depois de deixá-lo ocioso durante a noite. === Por que top mostra pouca memória livre mesmo quando tenho poucos programas em execução? A resposta simples é que a memória livre é uma memória desperdiçada. Qualquer memória que os programas não aloquem ativamente é usada pelo kernel do FreeBSD como cache de disco. Os valores mostrados por man:top[1] rotulados como `Inactivo` e `Laundry` são todos os dados armazenados em cache em diferentes níveis de envelhecimento. Esses dados em cache significam que o sistema não precisa acessar um disco lento novamente para os dados que acessou recentemente, aumentando assim o desempenho geral. Em geral, um valor baixo mostrado para a memória `Free` no man:top[1] é considerado bom, desde que não seja _muito_ baixo. === Por que o chmod não altera as permissões nos links simbólicos? Os links simbólicos não têm permissões e, por padrão, man:chmod[1] seguirá links simbólicos para alterar as permissões no arquivo de origem, se possível. Para o arquivo, [.filename]#foo# com um link simbólico chamado [.filename]#bar#, este comando será sempre bem-sucedido. [source,shell] .... % chmod g-w bar .... No entanto, as permissões no arquivo [.filename]#bar# não serão alteradas. Ao alterar os modos das hierarquias de arquivos do usuario root em vez dos próprios arquivos, use `-H` ou `-L` junto com `-R` para este trabalho. Veja man:chmod[1] e man:symlink[7] para mais em formação. [WARNING] ==== `-R` faz um man:chmod[1] recursivo. Tenha cuidado ao especificar diretórios ou links simbólicos para diretórios para o man:chmod[1]. Para alterar as permissões de um diretório referenciado por um link simbólico, use man:chmod[1] sem nenhuma opção e siga o link simbólico com uma barra à direita ([.filename]#/#). Por exemplo, se [.filename]#foo# for um link simbólico para o diretório [.filename]#bar#, para alterar as permissões de [.filename]#foo# (na verdade [.filename]#bar#) faça algo como: [source,shell] .... % chmod 555 foo/ .... Com a barra final, man:chmod[1] seguirá o link simbólico, [.filename]#foo#, para alterar as permissões do diretório, [.filename]#bar#. ==== === Posso executar binários do DOS no FreeBSD? Sim. Um programa de emulação DOS, package:emulators/doscmd[], está disponível na Coleção de Ports do FreeBSD. Se o doscmd não for suficiente, o package:emulators/pcemu[] emulará um 8088 e serviços de BIOS suficientes para executar muitos aplicativos em modo texto do DOS. Requer o sistema de janelas X. A coleção de ports também tem o package:emulators/dosbox[]. O foco principal deste aplicativo é emular antigos jogos do DOS usando o sistema de arquivos local para os arquivos. === O que eu preciso fazer para traduzir um documento do FreeBSD para minha língua nativa? Veja a extref:{fdp-primer}[FAQ de traduções, translations] na Documentação do Primer Project do FreeBSD. === Por que os meus emails destinados a qualquer endereço no dominio FreeBSD.org são sempre rejeitados? O sistema de mensagens do `FreeBSD.org` implementa algumas verificações do Postfix nos e-mails recebidos e rejeita e-mails que são de retransmissões mal configurados ou que parecem ser spam. Alguns dos requisitos específicos são: * O endereço IP do cliente SMTP deve possuir um registro de DNS reverso para encaminhar hostnames confirmados. * O nome completo do host fornecido na conversação SMTP (HELO ou EHLO) deve ser resolvido para o endereço IP do cliente. Outros conselhos para ajudar suas mensagens a chegar ao seu destino incluem: * O email deve ser enviado em texto simples, e as mensagens enviadas para as listas de discussão geralmente não devem ter mais de 200 KB. * Evite postagem cruzadas excessivas. Escolha _uma_ lista de discussão que pareça mais relevante e envie-a para lá. Se você ainda tiver problemas com a infra-estrutura de e-mail no `FreeBSD.org`, envie uma observação com os detalhes para mailto:postmaster@freebsd.org[postmaster@freebsd.org]; Inclua um intervalo de data/hora para que os registros possam ser revisados ​​-- e observe que apenas mantemos uma semana de registros de e-mail. (Certifique-se de especificar o fuso horário ou o deslocamento de UTC.) === Onde posso conseguir uma conta gratuita FreeBSD? Embora o FreeBSD não forneça acesso aberto a nenhum de seus servidores, outros fornecem sistemas UNIX(TM) de acesso aberto. A taxa varia e serviços limitados podem estar disponíveis. http://www.arbornet.org/[ A Arbornet, Inc ], também conhecida como _M-Net_, oferece acesso livre a sistemas UNIX(TM) desde 1983. Começando num Altos rodando o System III, o site mudou para o BSD/OS em 1991. Em junho de 2000, o site mudou novamente para o FreeBSD. _M-Net_ pode ser acessado via telnet e SSH e fornece acesso básico a todo o pacote de software FreeBSD. No entanto, o acesso à rede é limitado a membros e usuários que doam para o sistema, que é executado como uma organização sem fins lucrativos. O _M-Net_ também oferece um sistema de quadro de avisos e um bate-papo interativo. === Qual é o nome do mascotinho vermelho? Ele não tem um, e é chamado apenas de "o daemon BSD". Se você insistir em usar um nome, chame-o de "beastie". Note que "beastie" é pronunciado "BSD". Mais informações sobre o daemon BSD estão disponíveis em sua http://www.mckusick.com/beastie/index.html[home page]. === Posso usar a imagem do daemon do BSD? Possivelmente. O daemon BSD tem copyright de Marshall Kirk McKusick. Verifique sua http://www.mckusick.com/beastie/mainpage/copyright.html[ Declaração sobre o Uso da Figura do Daemon do BSD] para termos de uso detalhados. Em resumo, a imagem pode ser usada com bom gosto, para uso pessoal, desde que seja dado o crédito apropriado. Antes de usar o logotipo comercialmente, entre em contato com Kirk McKusick mailto:mckusick@FreeBSD.org[mckusick@FreeBSD.org] para obter permissão. Mais detalhes estão disponíveis na http://www.mckusick.com/beastie/index.html[ Home page do BSD Daemon]. === Vocês tem alguma imagem BSD daemon que eu poderia usar? Desenhos Xfig e eps estão disponíveis em [.filename]#/usr/shared/examples/BSD_daemon/#. === Eu vi um acrônimo ou outro termo nas listas de discussão e não entendo o que isso significa. Onde devo procurar? Consulte o extref:{handbook}glossary[Glossário do FreeBSD, freebsd-glossary]. === Por que eu deveria me importar com a cor da bikeshed? A resposta realmente curta é que você não deveria. A resposta um pouco mais longa é que só porque você é capaz de construir um bikeshed não significa que você deve impedir os outros de construir um só porque você não gosta da cor na qual eles planejam pintá-lo. Esta é uma metáfora indicando que você não precisa discutir sobre cada pequena característica apenas porque você sabe o suficiente para fazê-lo. Algumas pessoas comentaram que a quantidade de ruído gerada por uma mudança é inversamente proporcional à complexidade da mudança. A resposta mais longa e completa é que depois de uma longa discussão sobre se man:sleep[1] deve receber argumentos secundários fracionários, Poul-Henning Kamp mailto:phk@FreeBSD.org[phk@FreeBSD.org] publicou uma longa mensagem intitulada "link:http://www.bikeshed.com[ Um galpão de bicicleta (qualquer cor serve) na grama mais verde...]"As partes apropriadas dessa mensagem são citadas abaixo. Poul-Henning Kamp mailto:phk@FreeBSD.org[phk@FreeBSD.org] em http://lists.FreeBSD.org/mailman/listinfo/freebsd-hackers[freebsd-hackers] 2 de outubro de 1999 "O que acontece com esse bicicletário? " Alguns de vocês me perguntaram. É uma longa história, ou melhor, é uma história antiga, mas na verdade é bem curta. C. Northcote Parkinson escreveu um livro no início dos anos 1960, chamado "Lei de Parkinson", que contém muitas informações sobre a dinâmica da administração. _[recorte um pouco o comentário sobre o livro]_ No exemplo específico envolvendo o bicicletário, o outro componente vital é uma usina atômica, acho que isso ilustra a idade do livro. Parkinson mostra como você pode entrar na diretoria e obter aprovação para a construção de uma usina de energia atômica multimilionária ou mesmo bilionária, mas se você quiser construir um galpão de bicicleta, você ficará envolvido em discussões intermináveis. Parkinson explica que isso ocorre porque uma usina atômica é tão vasta, tão cara e tão complicada que as pessoas não conseguem entendê-la e, em vez de tentar, recuam supondo que alguém tenha verificado todos os detalhes antes de chegar tão longe. Richard P. Feynmann dá alguns exemplos interessantes, e muito importantes, relacionados a Los Alamos em seus livros. Uma bicicletário por outro lado. Qualquer um pode construir um desses em um fim de semana e ainda ter tempo de assistir ao jogo na TV. Portanto, não importa o quão bem preparado, não importa o quão razoável você é com a sua proposta, alguém vai aproveitar a chance de mostrar que ele está fazendo o seu trabalho, que ele está prestando atenção, que ele está _aqui_. Na Dinamarca, chamamos de "definindo sua identidade". É sobre orgulho pessoal e prestígio, é sobre poder apontar para algum lugar e dizer "Lá! _Eu_ fiz aquilo. " É um traço forte nos políticos, mas presente na maioria das pessoas que têm chance. Basta pensar em passos em cimento molhado. == Coisas legais do FreeBSD === Quão legal é o FreeBSD? [qanda] Alguém fez algum teste de temperatura durante a execução do FreeBSD? Eu sei que o Linux(TM) é mais legal que o DOS, mas nunca vi uma menção ao FreeBSD. Parece ser muito rápido.:: Não, mas fizemos numerosos testes de gostos em voluntários vendados que também receberam 250 microgramas de LSD-25 administrados antecipadamente. 35% dos voluntários disseram que o FreeBSD tinha um gosto de um tipo de laranja, enquanto o Linux(TM) tinha gosto de névoa roxa. Nenhum dos grupos mencionou variações significativas na temperatura. Eventualmente nós tivemos que lançar os resultados desta pesquisa completamente de qualquer maneira quando descobrimos que muitos voluntários estavam vagando fora da sala durante os testes, assim distorcendo os resultados. Nós achamos que a maioria dos voluntários está na Apple agora, trabalhando em sua nova GUI "risca e arrisca". É um negócio antigo e engraçado em que estamos! Sério, o FreeBSD usa a instrução HLT (halt) quando o sistema está ocioso, reduzindo assim seu consumo de energia e, portanto, o calor gerado. Além disso, se você tiver ACPI (Configuração Avançada e Interface de Energia) configurado, então o FreeBSD também pode colocar a CPU em um modo de baixa energia. === Quem está coçando nos meus bancos de memória?? [qanda] Existe alguma coisa "estranha" que o FreeBSD faz ao compilar o kernel que faria com que a memória fizesse um som de algo coçando? Ao compilar (e por um breve momento depois de reconhecer o drive de disquete na inicialização também), um estranho som de algo coçando emana do que parecem ser os bancos de memória.:: Sim! Você verá referências freqüentes a "daemons" na documentação do BSD, e o que a maioria das pessoas não sabe é que isso se refere a entidades genuínas e não corporais que agora possuem seu computador. O som áspero vindo de sua memória é, na verdade, um sussurro agudo entre os daemons, pois eles decidem como lidar com várias tarefas de administração do sistema. Se o ruído chegar até você, um bom `fdisk/mbr` do DOS irá se livrar deles, mas não fique surpreso se eles reagirem negativamente e tentarem pará-lo. Na verdade, se em algum momento durante o exercício você ouvir a voz satânica de Bill Gates vindo do alto-falante embutido, saia correndo e não olhe para trás! Livres da influência contrabalançadora dos daemons BSD, os demônios gêmeos do DOS e Windows(TM) são frequentemente capazes de reafirmar o controle total sobre sua máquina para a danação eterna de sua alma. Agora que você sabe, dada uma escolha, você provavelmente preferiria se acostumar com os ruídos ásperos, não? === Quantos hackers do FreeBSD são necessários para trocar uma lâmpada? Mil, cento e sessenta e nove: Vinte e três para reclamar com -CURRENT sobre as luzes estarem apagadas; Quatro para afirmar que trata-se de um problema de configuração e que tais questões realmente pertencem a -questions; Três para enviar PRs sobre o assunto, uma das quais está arquivada sob doc e consiste apenas da declaração "está escuro"; Um para cometer uma lâmpada não testada que quebra o buildworld, e depois retorna cinco minutos depois; Oito para chamar os remetentes de RP por não incluir patches em seus PRs; Cinco para reclamar sobre o buildworld sendo quebrado; Trinta e um para responder que funciona para eles, e eles devem ter atualizado em um momento ruim; Um para postar um patch para uma nova luz para -hackers; Um para reclamar que ele tinha patches para isso há três anos, mas quando ele os enviou para -CURRENT eles foram ignorados, e ele teve más experiências com o sistema de PRs; além disso, a nova luz proposta não é reflexiva; Trinta e sete para gritar que essa luz não pertencem ao sistema básico, que os committers não têm o direito de fazer coisas assim sem consultar a Comunidade, e O QUE O -CORE ESTÁ FAZENDO SOBRE ISSO!? Duzentos para reclamar da cor do bicicletário; Três para salientar que o patch quebra o man:style[9]; Dezessete para reclamar que a nova luz proposta está sob a GPL; Quinhentos e oitenta e seis para iniciar uma guerra contra as vantagens comparativas da GPL, da licença da BSD, da licença do MIT, da NPL e da higiene pessoal dos fundadores da FSF, que não são nomeados; Sete para mover várias partes do segmento para -chat e -vocacy; Um para comitar a luz sugerida, mesmo que ela seja mais escura que a antiga; Dois para recuar com uma chama furiosa de uma mensagem de commit, argumentando que o FreeBSD está melhor no escuro do que com uma lâmpada fraca; Quarenta e seis para argumentar veementemente sobre o apoio da luz fraca e exigir uma declaração do alto desempenho; Onze para solicitar uma lâmpada menor para que ela caiba em seu Tamagotchi se decidirmos portar o FreeBSD para essa plataforma; Setenta e três para reclamar sobre o SNR em -chackers e -chat e cancelar a inscrição em protesto; Treze para postar "cancelar a inscrição", " Como posso cancelar a inscrição? ", ou "Por favor, remova-me da lista", seguido do rodapé habitual; Um para comitar uma lâmpada de trabalho enquanto todos estão ocupados demais chamando a atenção de todos os outros para esse commit; Trinta e um para salientar que a nova lâmpada iria brilhar 0,364% a mais se compilada com TenDRA (embora tenha que ser reformulada em um cubo), e que o FreeBSD deve, portanto, mudar para TenDRA ao invés de GCC; Um para reclamar que a nova lâmpada não tem carenagem; Nove (incluindo os criadores de PRs) para perguntar "o que é o MFC?"; Cinquenta e sete para se queixar das luzes apagadas duas semanas depois de a lâmpada ter sido trocada. _Nik Clayton_ mailto:nik@FreeBSD.org[nik@FreeBSD.org] acrescenta: _Eu estava rindo bastante disso._ _E então eu pensei, " Espere, não deveria haver '1 para documentar isso.' nessa lista em algum lugar? "_ _E então eu fui iluminado :-)_ _Thomas Abthorpe_ mailto:tabthorpe@FreeBSD.org[tabthorpe@FreeBSD.org] diz: " Nenhum, um hacker _real_ do FreeBSD não têm medo do escuro! " === Onde os dados gravados em /dev/null vão parar? Ele entra em um coletor de dados especial na CPU, onde é convertido em calor que é ventilado através do conjunto do dissipador de calor / ventilador. É por isso que o resfriamento da CPU é cada vez mais importante; À medida que as pessoas se acostumam com processadores mais rápidos, elas se tornam descuidadas com seus dados e mais e mais delas acabam no [.filename]#/dev/null#, superaquecendo suas CPUs. Se você apagar [.filename]#/dev/null# (o que efetivamente desativa o dissipador de dados da CPU) sua CPU pode ficar mais fria, mas seu sistema rapidamente ficará constipado com todos esses dados em excesso e começará a se comportar de maneira irregular. Se você tem uma conexão de rede rápida, pode resfriar sua CPU lendo dados de [.filename]#/dev/random# e enviá-los para algum lugar; No entanto, você corre o risco de superaquecer sua conexão de rede e [.filename]#/# ou irritar seu ISP, pois a maioria dos dados acabará sendo convertida em calor pelo equipamento, mas eles geralmente têm um bom resfriamento, então se você não exagere você deve estar bem. _Paul Robinson acrescenta:_ Existem outros métodos. Como todo bom administrador de sistemas sabe, é parte da prática padrão enviar dados para a tela de variedade interessante para manter todos os pixies que compõem sua imagem felizes. Os duendes de tela (comumente com erros de digitação ou renomeados como "pixels") são categorizados pelo tipo de chapéu que usam (vermelho, verde ou azul) e serão ocultados ou exibidos (mostrando a cor do chapéu ) sempre que recebem um pequeno pedaço de comida. Placas de vídeo transformam dados em comida de duende, e então os enviam para os duendes - quanto mais cara a carta, melhor a comida, então é melhor que os pixies se comportem melhor. Eles também precisam de estímulo constante - é por isso que existem proteções de tela. Para levar suas sugestões adiante, você poderia simplesmente jogar os dados aleatórios no console, permitindo que os duendes os consumam. Isso faz com que nenhum calor seja produzido, mantém os pixies felizes e se livra de seus dados rapidamente, mesmo que isso faça as coisas parecerem um pouco confusas na sua tela. Incidentalmente, como um ex-administrador de um grande ISP que teve muitos problemas ao tentar manter uma temperatura estável em uma sala de servidores, eu desencorajaria fortemente as pessoas que enviam os dados que não querem para a rede. As fadas que fazem a troca e o encaminhamento de pacotes também se irritam com isso. === Minha colega fica muito no computador, como eu posso brincar com ela? Instale o package:games/sl[] e espere ela digitar `sl` para `ls`. == Tópicos Avançados === Como posso aprender mais sobre os componentes internos do FreeBSD? Veja o extref:{arch-handbook}[ Handbook de Arquitetura do FreeBSD ]. Além disso, muito do conhecimento geral sobre o UNIX(TM) é diretamente aplicável ao FreeBSD. === Como posso contribuir para o FreeBSD? O que posso fazer para ajudar? Nós aceitamos todos os tipos de contribuições: documentação, código e até mesmo arte. Veja o artigo extref:{contributing}[Contribuindo com o FreeBSD] para obter maiores informações sobre como fazer isso. E obrigado por considerar nos ajudar! === O que são Snapshots e Releases? Atualmente existem 3 branches ativas/semi-ativas no http://svnweb.FreeBSD.org/base/[Repositório Subversion] do FreeBSD. (Os branches anteriores são alterados muito raramente, e é por isso que existem apenas 3 branches ativas de desenvolvimento): * stable/11/ AKA _11-STABLE_ * stable/12/ AKA _12-STABLE_ * head/ AKA _-CURRENT_ AKA _13-CURRENT_ `HEAD` não é uma tag de branch real. É uma constante simbólica para o fluxo de desenvolvimento atual, não ramificado, conhecido como _-CURRENT_. No momento, o _-CURRENT_ é o fluxo de desenvolvimento 13._X_; o branch _12-STABLE_, stable/12/, derivou do _-CURRENT_ em Dezembro de 2018 e o branch ​​_11-STABLE_,stable/11/, derivou do _-CURRENT_ em Outubro de 2016. === Como posso aproveitar ao máximo os dados que vejo quando meu kernel entra em panic? Aqui está um panic típico do kernel: [.programlisting] .... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault .... Esta mensagem não é suficiente. Embora o valor do ponteiro de instrução seja importante, ele também depende da configuração, pois varia dependendo da imagem do kernel. Se for uma imagem de kernel [.filename]#GENERIC# de um dos snapshots, é possível que alguém rastreie a função problemática, mas para um kernel personalizado, somente você pode nos dizer onde a falha ocorreu. Para prosseguir: [.procedure] ==== . Anote o valor do ponteiro de instrução. Note que a parte `0x8:` no começo não é relevante neste caso: é a parte `0xf0xxxxxx` que nós queremos. . Quando o sistema for reinicializado, faça o seguinte: + [source,shell] .... % nm -n kernel.that.caused.the.panic | grep f0xxxxxx .... + no qual `f0xxxxxx` é o valor do ponteiro de instrução. As probabilidades são de que você não obterá uma correspondência exata, pois os símbolos na tabela de símbolos do kernel são para os pontos de entrada das funções e o endereço do ponteiro de instrução estará em algum lugar dentro de uma função, não no início. Se você não obtiver uma correspondência exata, omita o último dígito do valor do ponteiro de instrução e tente novamente: + [source,shell] .... % nm -n kernel.that.caused.the.panic | grep f0xxxxx .... + Se isso não produzir nenhum resultado, corte outro dígito. Repita até que haja algum tipo de saída. O resultado será uma possível lista das funções que causaram o panic. Este é um mecanismo menos do que exato para rastrear o ponto de falha, mas é melhor do que nada. ==== No entanto, a melhor maneira de rastrear a causa de um panic é capturar um despejo de memória e usar o man:kgdb[1] para gerar um rastreamento de pilha no despejo de memória. Em qualquer caso, o método é este: [.procedure] ==== . Certifique-se de que a seguinte linha esteja incluída no arquivo de configuração do kernel: + [.programlisting] .... makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols .... + . Mude para o diretório [.filename]#/usr/src#: + [source,shell] .... # cd /usr/src .... + . Compile o kernel: + [source,shell] .... # make buildkernel KERNCONF=MYKERNEL .... + . Aguarde até o man:make[1] terminar a compilação. + [source,shell] .... # make installkernel KERNCONF=MYKERNEL .... + . Reinicie. ==== [NOTE] ==== Se a variável `KERNCONF` não for informada na linha de comando, o kernel [.filename]#GENERIC# será compilado e instalado. ==== O processo man:make[1] terá compilado dois kernels. O [.filename]#/usr/obj/usr/src/sys/MYKERNEL/kernel# e o [.filename]#/usr/obj/usr/src/sys/MYKERNEL/kernel.debug#. O [.filename]#kernel# foi instalado como [.filename]#/boot/kernel/kernel#, enquanto o [.filename]#kernel.debug# pode ser usado como fonte de símbolos de depuração para o man:kgdb[1]. Para capturar um despejo de memória, edite o [.filename]#/etc/rc.conf# e defina o `dumpdev` para apontar para a partição de swap ou para `AUTO`. Isso fará com que os scripts man:rc[8] usem o comando man:dumpon[8] para ativar os despejos de memória. Este comando também pode ser executado manualmente. Após um panic, o despejo de memória pode ser recuperado usando o man:savecore[8]; se o `dumpdev` estiver configurado em [.filename]#/etc/rc.conf#, os scripts man:rc[8] executarão o man:savecore[8] automaticamente e colocarão o despejo de memória em [.filename]#/var/crash#. [NOTE] ==== Os despejos de memória do FreeBSD são geralmente do mesmo tamanho que a RAM física. Portanto, verifique se há espaço suficiente em [.filename]#/var/crash# para manter o despejo. Como alternativa, execute man:savecore[8] manualmente e faça com que recupere o despejo de memória para outro diretório com mais espaço. É possível limitar o tamanho do despejo de memória usando `options MAXMEM=N` onde _N_ é o tamanho da memória utilizada do kernel em KBs. Por exemplo, para 1 GB de RAM, limite o uso de memória pelo kernel a 128 MB, para que o tamanho do despejo de memória seja de 128 MB em vez de 1 GB. ==== Depois que o despejo de memória for recuperado, obtenha um rastreamento de pilha da seguinte maneira: [source,shell] .... % kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0 (kgdb) backtrace .... Note que pode haver várias telas de informação valiosa. Idealmente, use man:script[1] para capturar todas elas. Usar a imagem do kernel unstripped com todos os símbolos de depuração deve mostrar a linha exata do código fonte do kernel onde o panic ocorreu. O rastreamento de pilha geralmente é lido de baixo para cima para rastrear a sequência exata de eventos que levam à falha. O man:kgdb[1] também pode ser usado para imprimir o conteúdo de várias variáveis ​​ou estruturas para examinar o estado do sistema no momento da falha. [TIP] ==== Se um segundo computador estiver disponível, o man:kgdb[1] pode ser configurado para fazer uma depuração remota, incluindo pontos de interrupção de configuração e passos únicos através do código do kernel. ==== [NOTE] ==== Se o `DDB` estiver habilitado e o kernel cair no depurador, um panic e um despejo de memória podem ser forçados digitando `panic` no prompt do `ddb`. O processo pode parar no depurador novamente durante a fase de panic. Se isso acontecer, digite `continue` e ele concluirá o despejo de memória. ==== === Por que dlsym() parou de funcionar para executáveis ​​ELF? A toolchain ELF não faz, por padrão, os símbolos definidos em um executável visíveis para o vinculador dinâmico. Consequentemente, a busca da função `dlsym()` por identificadores obtidos de chamadas para `dlopen(NULL, flags)` não conseguirá encontrar tais símbolos. Para pesquisar, usando a função `dlsym()`, os símbolos presentes no executável principal de um processo, vincule o executável usando a opção `- export-dynamic` ao vinculador ELF (man:ld[1]). === Como posso aumentar ou reduzir o espaço de endereçamento do kernel em uma máquina i386? Por padrão, o espaço de endereço do kernel é de 1 GB (2 GB para PAE) para a arquitetura i386. Se você estiver executando um servidor com uso intensivo de rede ou utilizando o ZFS, isso provavelmente não será suficiente. Adicione a seguinte linha ao arquivo de configuração do kernel para aumentar o espaço disponível e recompile o kernel: [.programlisting] .... options KVA_PAGES=N .... Para encontrar o valor correto de _N_, divida o tamanho do espaço de endereço desejado (em megabytes) por quatro. (Por exemplo, é `512` para 2 GB.) == Agradecimentos Este inocente documento de Perguntas Frequentes foi escrito, reescrito, editado, dobrado, fustigado, mutilado, eviscerado, contemplado, desconcertado, cogitado, regurgitado, reconstruído, castigado e revigorado na última década, por um elenco de centenas, se não milhares de voluntários. Repetidamente. Gostaríamos de agradecer a cada uma das pessoas responsáveis, e nós o encorajamos a extref:{contributing}[se juntar a eles] para tornar este FAQ ainda melhor. diff --git a/documentation/content/pt-br/books/handbook/_index.adoc b/documentation/content/pt-br/books/handbook/_index.adoc index cc6960ff60..f0f59f5cde 100644 --- a/documentation/content/pt-br/books/handbook/_index.adoc +++ b/documentation/content/pt-br/books/handbook/_index.adoc @@ -1,51 +1,51 @@ --- title: FreeBSD Handbook authors: - author: Projeto de Documentação do FreeBSD copyright: 1995-2020 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] next: books/handbook/preface showBookMenu: true weight: 0 path: "/books/handbook/" --- = FreeBSD Handbook :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Resumo Bem vindo ao FreeBSD! Este manual cobre a instalação e o uso diário do _FreeBSD 12.1-RELEASE_ e do _FreeBSD 11.4-RELEASE_. Este livro é o resultado do trabalho contínuo de muitas pessoas. Algumas seções podem estar desatualizadas. Os interessados em ajudar a atualizar e expandir este documento devem enviar e-mails para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de discussão do projeto de documentação do FreeBSD]. -A última versão deste livro está disponível no https://www.FreeBSD.org/[site do FreeBSD]. Versões anteriores podem ser obtidas em https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]. O livro pode ser baixado em uma variedade de formatos e opções de compressão do https://download.freebsd.org/ftp/doc/[servidor FTP do FreeBSD] ou de um dos inúmeros <>. Cópias impressas podem ser adquiridas da https://www.freebsdmall.com/[FreeBSD Mall]. As pesquisas podem ser realizadas no manual e em outros documentos na https://www.FreeBSD.org/search/index.html[página de busca]. +A última versão deste livro está disponível no https://www.FreeBSD.org/[site do FreeBSD]. Versões anteriores podem ser obtidas em https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]. O livro pode ser baixado em uma variedade de formatos e opções de compressão do https://download.freebsd.org/doc/[servidor FTP do FreeBSD] ou de um dos inúmeros <>. Cópias impressas podem ser adquiridas da https://www.freebsdmall.com/[FreeBSD Mall]. As pesquisas podem ser realizadas no manual e em outros documentos na https://www.FreeBSD.org/search/index.html[página de busca]. ''' diff --git a/documentation/content/pt-br/books/handbook/book.adoc b/documentation/content/pt-br/books/handbook/book.adoc index a25d4a775c..f7558e15d5 100644 --- a/documentation/content/pt-br/books/handbook/book.adoc +++ b/documentation/content/pt-br/books/handbook/book.adoc @@ -1,150 +1,150 @@ --- title: FreeBSD Handbook authors: - author: Projeto de Documentação do FreeBSD copyright: 1995-2020 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] --- = FreeBSD Handbook :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] [abstract] Resumo Bem vindo ao FreeBSD! Este manual cobre a instalação e o uso diário do _FreeBSD 12.1-RELEASE_ e do _FreeBSD 11.4-RELEASE_. Este livro é o resultado do trabalho contínuo de muitas pessoas. Algumas seções podem estar desatualizadas. Os interessados em ajudar a atualizar e expandir este documento devem enviar e-mails para a http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[lista de discussão do projeto de documentação do FreeBSD]. -A última versão deste livro está disponível no https://www.FreeBSD.org/[site do FreeBSD]. Versões anteriores podem ser obtidas em https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]. O livro pode ser baixado em uma variedade de formatos e opções de compressão do https://download.freebsd.org/ftp/doc/[servidor FTP do FreeBSD] ou de um dos inúmeros <>. Cópias impressas podem ser adquiridas da https://www.freebsdmall.com/[FreeBSD Mall]. As pesquisas podem ser realizadas no manual e em outros documentos na https://www.FreeBSD.org/search/[página de busca]. +A última versão deste livro está disponível no https://www.FreeBSD.org/[site do FreeBSD]. Versões anteriores podem ser obtidas em https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/]. O livro pode ser baixado em uma variedade de formatos e opções de compressão do https://download.freebsd.org/doc/[servidor FTP do FreeBSD] ou de um dos inúmeros <>. Cópias impressas podem ser adquiridas da https://www.freebsdmall.com/[FreeBSD Mall]. As pesquisas podem ser realizadas no manual e em outros documentos na https://www.FreeBSD.org/search/[página de busca]. ''' toc::[] :sectnums!: include::{chapters-path}preface/_index.adoc[leveloffset=+1] :sectnums: // Section one include::{chapters-path}parti.adoc[] include::{chapters-path}introduction/_index.adoc[leveloffset=+1] include::{chapters-path}bsdinstall/_index.adoc[leveloffset=+1] include::{chapters-path}basics/_index.adoc[leveloffset=+1] include::{chapters-path}ports/_index.adoc[leveloffset=+1] include::{chapters-path}x11/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[] include::{chapters-path}desktop/_index.adoc[leveloffset=+1] include::{chapters-path}multimedia/_index.adoc[leveloffset=+1] include::{chapters-path}kernelconfig/_index.adoc[leveloffset=+1] include::{chapters-path}printing/_index.adoc[leveloffset=+1] include::{chapters-path}linuxemu/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[] include::{chapters-path}config/_index.adoc[leveloffset=+1] include::{chapters-path}boot/_index.adoc[leveloffset=+1] include::{chapters-path}security/_index.adoc[leveloffset=+1] include::{chapters-path}jails/_index.adoc[leveloffset=+1] include::{chapters-path}mac/_index.adoc[leveloffset=+1] include::{chapters-path}audit/_index.adoc[leveloffset=+1] include::{chapters-path}disks/_index.adoc[leveloffset=+1] include::{chapters-path}geom/_index.adoc[leveloffset=+1] include::{chapters-path}zfs/_index.adoc[leveloffset=+1] include::{chapters-path}filesystems/_index.adoc[leveloffset=+1] include::{chapters-path}virtualization/_index.adoc[leveloffset=+1] include::{chapters-path}l10n/_index.adoc[leveloffset=+1] include::{chapters-path}cutting-edge/_index.adoc[leveloffset=+1] include::{chapters-path}dtrace/_index.adoc[leveloffset=+1] include::{chapters-path}usb-device-mode/_index.adoc[leveloffset=+1] // Section four include::{chapters-path}partiv.adoc[] include::{chapters-path}serialcomms/_index.adoc[leveloffset=+1] include::{chapters-path}ppp-and-slip/_index.adoc[leveloffset=+1] include::{chapters-path}mail/_index.adoc[leveloffset=+1] include::{chapters-path}network-servers/_index.adoc[leveloffset=+1] include::{chapters-path}firewalls/_index.adoc[leveloffset=+1] include::{chapters-path}advanced-networking/_index.adoc[leveloffset=+1] // Section five include::{chapters-path}partv.adoc[] :sectnums!: include::{chapters-path}mirrors/_index.adoc[leveloffset=+1] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] include::{chapters-path}eresources/_index.adoc[leveloffset=+1] include::{chapters-path}pgpkeys/_index.adoc[leveloffset=+1] :sectnums: diff --git a/documentation/content/zh-tw/books/faq/_index.adoc b/documentation/content/zh-tw/books/faq/_index.adoc index b1b3ae06e0..99d6ee1744 100644 --- a/documentation/content/zh-tw/books/faq/_index.adoc +++ b/documentation/content/zh-tw/books/faq/_index.adoc @@ -1,2899 +1,2899 @@ --- title: FreeBSD 11.X and 12.X 常見問答集 authors: - author: FreeBSD 文件計畫 copyright: 1995-2020 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "adobe", "intel", "linux", "microsoft", "opengroup", "sun", "netbsd", "general"] isIndex: true --- = FreeBSD {rel2-relx} and {rel-relx} 常見問答集 :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/faq/ :rel-numbranch: 4 :rel-head: 14-CURRENT :rel-head-relx: 14.X :rel-head-releng: head/ :rel-relx: 13.X :rel-stable: 13-STABLE :rel-releng: stable/13/ :rel-relengdate: December 2018 :rel2-relx: 12.X :rel2-stable: 12-STABLE :rel2-releng: stable/12/ :rel2-relengdate: December 2018 :rel3-relx: 11.X :rel3-stable: 11-STABLE :rel3-releng: stable/11/ :rel3-relengdate: October 2016 ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] 摘要 這份文件是 FreeBSD {rel-relx} 和 {rel2-relx} 常見問答集 ( (FAQ) )。我們盡可能地讓這份 FAQ 提供有用的資訊 ; 如果您有任何改善建議，請寄到 http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[FreeBSD 文件計畫郵件論壇]。 -本文件的最新版本可由 extref:{faq}[FreeBSD 網站]取得。 也可以由 https://download.freebsd.org/ftp/doc/[FreeBSD FTP 伺服器] 以 HTTP 下載單一大型 link:.[HTML] 檔或是其他格式的檔案。 +本文件的最新版本可由 extref:{faq}[FreeBSD 網站]取得。 也可以由 https://download.freebsd.org/doc/[FreeBSD FTP 伺服器] 以 HTTP 下載單一大型 link:.[HTML] 檔或是其他格式的檔案。 ''' toc::[] == 前言 === 什麼是 FreeBSD？ FreeBSD 是一個使用於桌機、筆電、伺服器與嵌入式系統平台的現代作業系統，支援多種link:https://www.FreeBSD.org/platforms/[平台]。 它是根據 U.C. Berkeley 所開發出來的 "4.4BSD-Lite" ，並加上了許多 "4.4BSD-Lite2" 的增強功能。它同時也間接使用了 U.C. Berkeley 所開發出來並由 William Jolitz 移植到 i386(TM) 的 "Net/2"，也就是 "386BSD"，不過現在 386BSD 的程式碼只剩下極少數還留 存在 FreeBSD 中。 FreeBSD 已被廣泛地被世界各地的公司行號、ISP、研究人員、電腦 專家、學生，以及家庭用戶所使用，用在工作、教育以及娛樂上。 如果想看關於 FreeBSD 更深入的資料，請看 extref:{handbook}[FreeBSD 使用手冊]。 === 發展 FreeBSD 計畫的目的是什麼？ FreeBSD 計畫的目的是提供可以任意使用且沒有限制的穩定快速與一般用途的作業系統。 === FreeBSD 版權有任何限制嗎？ 有的。但是這並不是限制你怎麼去使用這些程式碼，而是你怎麼看待 FreeBSD 這個計畫。可以在此閱讀 https://www.FreeBSD.org/copyright/freebsd-license/[ 版權本文]，簡單來說總結如下: * 請勿宣稱是您寫了這個程式。 * 如果它出問題了，不要控告我們。 * 不要移除和修改版權 我們許多人在這個計畫投入很多心血，並不會介意獲得一些財務上的報酬，但是我們並沒有堅持一定要有。我們相信我們首要的"任務"是將程式碼提供給所有使用者，無論他們有任何的目的，這麼一來，這些程式碼才能被用在最多地方，也才能發揮它們最大的利益。我們相信這就是自由軟體最基本的目標之一，而且我們會盡全力去支持它。 在我們 source tree 中有部份的程式碼是採用所謂的link:https://www.FreeBSD.org/copyright/COPYING[GNU General Public License (GPL)] 或 https://www.FreeBSD.org/copyright/COPYING.LIB[GNU Library General Public License (LGPL)]版權宣告，雖然這些版權宣告是用來保障而非限制使用者的權 利，畢竟是不那麼自由了些。由於這些 GPL 的軟體在商業使用上會引起 非常複雜的版權問題，因此只要有機會，我們會盡量以採用比較鬆的 https://www.FreeBSD.org/copyright/freebsd-license/[FreeBSD 版權] 的軟體來取代這些 GPL 版權宣告的軟體。 === FreeBSD 可以取代我現在在用的作業系統嗎？ 對大部份的人來說是這樣沒錯，但事實上這問題並沒有這麼好回答。 大部份的人並不是真正在使用一個作業系統。他們使用的是應用程式 ；而那些應用程式才是真正用到作業系統的東西。FreeBSD 是設計用來提供一個強韌且功能完整的作業環境給應用程式來執行。它支援了多種瀏覽器，辦公室套件軟體，電子郵件閱讀軟體，繪圖程式，程式設計環境，網路伺服器軟體，以及幾乎所有你想要的東西。大部份的程式都可以靠 https://www.FreeBSD.org/ports/[Ports Collection] 來管理。 但是如果你想要使用的應用程式只能在某個特定的作業系統上面執行 的話，你就不能輕易地把它換掉，或者指望在 FreeBSD 上有很相似的應用程式才有機會。如果你想要的是一個強健的辦公室或是網路伺服器，或是一部穩定的工作站，FreeBSD 無疑是您的最佳選擇。世界各地有很多使用者，包括初學或資深的 UNIX(TM) 管理人員都選用 FreeBSD 當他們唯一的桌上作業系統。 如果你是從其他的 UNIX(TM)-like 環境轉換到 FreeBSD 的話會很熟悉。 Windows(TM) 或是 Mac OS(TM) 的使用者可能會對 https://www.trueos.org[TrueOS] 有興趣，他是基於 FreeBSD 的一個桌面環境發行版，非UNIX(TM) 使用者可能就要多花一點時間來學習怎麼用 UNIX(TM) 的 方法來做事。你可以從這份 FAQ 和 extref:{handbook}[FreeBSD 使用手冊] 來入門。 === 為什麼要叫做 FreeBSD？ * 您可以免費使用它，即使是用於商業用途。 * 整個 FreeBSD 作業系統完整的原始程式都可以免費取得，而且不管是在使用，散佈或是整合進其他程式等各方面也只受到最小的限制 (不論是否用於商業用途)。 * 任何人都可以自由地把他對系統的改良或錯誤修正的程式碼加入 source tree 之中 (當然要符合幾個先決條件)。 特別值得注意的是這裡的 "`free`" 出現了兩次，而且它們 的意思是不一樣的：一種代表 "`免費`"，另一種代表 "`自由`"。您可以拿 FreeBSD 去做任何您想要做的事，除了一些例外，例如您宣稱 FreeBSD 是您寫的。 === FreeBSD 及 NetBSD, OpenBSD 以及其他 open source BSD 作業系統之間有何不同之處呢？ James Howard 寫了一篇關於不同計畫的差異和歷史淵源的好文章叫 https://jameshoward.us/archive/the-bsd-family-tree/[The BSD Family Tree] 可以回答這個問題。雖然有些資訊有點過時，但是關於歷史淵源的部份仍是相當正確的。 時至今日，大部分的 BSD 家族仍是共用修補和程式碼的。這些 BSD 家族有著共同的祖先。 FreeBSD 的設計目的如 <> 所述。其他 BSD 家族的設計目的如下所述： * OpenBSD 目標在作業系統的安全性。OpenBSD團隊寫的 man:ssh[1] 和 man:pf[4] 都移植到了 FreeBSD。 * NetBSD 目標在易於移植到其他的硬體平台。 * DragonFly BSD 是 FreeBSD 4.8 的一個分支，發展出許多有趣的特色，包括 HAMMER 檔案系統和支援 "vkernels" 使用者模式。 === 最新版的 FreeBSD 是那一版？ 在 FreeBSD 開發的任何時間點，都有多個平行的分支。12._X_ releases 是從 _12-STABLE_ 分支而來，而 11._X_ releases 是從 _11-STABLE_ 分支而來。 在 9.0 之前，11.__X__ 系列仍屬 __-STABLE__分支。 然而從13.__X__ 發行開始，11.__X__ 將只著重在重大問題上(比如：漏洞修補、安全維護)以及所謂的 "extended support" 。 Version link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/i386/12.0-RELEASE/[12.0] is the latest release from the _12-STABLE_ branch; it was released in December 2018. Version link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/10.4-RELEASE/[10.4] is the latest release from the _11-STABLE_ branch; it was released in October 2017. Releases 版 <> 才會發行一次。 雖然如此，有很多人和 FreeBSD 原始碼同步更新 (詳見 <> 和 <>的相關問題) ，但因為原始碼是一直不斷地在變動的，所以如果要這麼做的話得要花上更多的精力。 其他更多相關 FreeBSD 發行情報，可由 FreeBSD 網站上的 https://www.FreeBSD.org/releng/#release-build[Release Engineering 頁面] 和 man:release[7]得知。 === 什麼是 FreeBSD-CURRENT? extref:{handbook}updating-upgrading[FreeBSD-CURRENT, current] 指的是正在發展中的作業系統版本，它終將在適當的時機成為 FreeBSD-STABLE 分支。它實在是只適合給系統發展者以及有毅力的業餘愛好者使用 。如果想要得到有關如何使用__-CURRENT__的深入資訊，請參考extref:{handbook}[使用手冊]的extref:{handbook}updating-upgrading[相關部份, current]。 如果您對 FreeBSD 本身並不是很熟悉那麼您就不應該使用FreeBSD-CURRENT。 這個分支的程式碼有時候變動得很快，而且可能會因此 而使您有好幾天的時間無法更新您的系統。我們假設使用 FreeBSD-CURRENT 的使用者都有能力去分析他們所遇到的問題，除錯，並且回報問題。 我們每天都會根據目前 _-CURRENT_ 和 _-STABLE_ 的狀況對這兩個分支各發行一個 https://www.FreeBSD.org/snapshots/[snapshot] 版。發表這些 snapshot 的目的在於： * 測試最新版的安裝程式。 * 提供一個簡單的方法給那些喜歡使用 _-CURRENT_ 或是 _-STABLE_ 但是沒有時間和頻寬去每天昇級的使用者。 * 為了替我們發展中的程式保留一個固定的參考點，以防止我們未來不幸搞砸了。(雖然一般而言 Subversion 可以防止類似這種的可怕事件) * 為了確保所有需要測試的新功能或修正都可以得到最多的測試。 我們不對 _-CURRENT_ snapshot 做任何目的的 "品質保證" 。如果你想要的是一個穩定且經過充分測試過的系統的話， 最好選擇使用完整 releases. 您可以直接從 https://www.FreeBSD.org/snapshots/[snapshot] 取得 -CURRENT 的 snapshot release。 對每個有在活動的分支而言，都會定期產生一次 snapshots。 === 什麼是 FreeBSD-STABLE ? 回溯到 FreeBSD 2.0.5 剛發表的時候，我們決定把 FreeBSD 的發展 分成兩支。一支叫做 extref:{handbook}updating-upgrading[-STABLE, stable]，另一支叫 extref:{handbook}updating-upgrading[-CURRENT, current]。主要發行版是由__FreeBSD-STABLE__ 這個開發分支而來。他的變動較慢，而且一般來說假設他們都已經先在FreeBSD-CURRENT測試過了。然而在任何時候，FreeBSD-STABLE的原始碼仍有可能不一定適合一般用途，因為他可能包含在 FreeBSD-CURRENT 沒有發現到的錯誤。沒有能力和資源的使用者應該改使用 FreeBSD 正式發行版。_FreeBSD-CURRENT_ 從2.0開始就是另一個分支，一直到12.0-RELEASE和之後的版本都還是。更多關於開發分支的資訊請見 "extref:{handbook}[FreeBSD Release Engineering: Creating the Release Branch]" ，分支的開發狀態和接下來的發行計畫時間表可以在 https://www.FreeBSD.org/releng[Release Engineering 資訊] 找到。 12.0-STABLE 是目前正在發展中的 _-STABLE_ 分支。最新的 12.0-STABLE 是在 2018年12月發行的 12.0-RELEASE。 _12-CURRENT_ 這個分支是 FreeBSD 的 _-CURRENT_ 分支，仍然不斷地在發展當中。 如果想要知道更多關於這個分支的資訊的話，請參考 <> 。 === 每次新的 FreeBSD 將於什麼時候推出？ 一般而言，Release Engineering Team mailto:re@FreeBSD.org[re@FreeBSD.org] 約每18個月發行一次主要發行版本，約平均每8個月發行一次次要發行版本。每次新版本的發表時程都會事先公告， 相關的開發人員就會知道，什麼時候該先把手邊的計劃完成並且測試過， 此外，這些更動都已經完整地測試過，確保新功能不會影響系統的穩定度。 雖然，等這些好東西進入__-STABLE__ 的時間令人等得有些不耐煩， 但是大多數的使用者都認為這種謹慎的態度是 FreeBSD 最好的優點之一。 有關發行情報的更多細節部分(包括 release 的行程表、進度)，都可在 FreeBSD 網站上的 https://www.FreeBSD.org/releng/[發行情報] 上面獲得。 為了滿足那些需要 (或想要) 新鮮刺激感的使用者， 上面已經提到我們每周都會發行 snapshots 版可供使用。 === 誰負責 FreeBSD 的發展？ 如果是一些有關 FreeBSD 計畫的關鍵性決定，像是整個計畫的走向 或是決定誰可以改 source tree 裡的程式碼這類的事，是由一個由 9 個 人所組成的 https://www.FreeBSD.org/administration/#t-core[core team] 來決定。而有另一群超過 350 個人的 extref:{contributors}[committers, staff-committers] 有權利可以直接修改 FreeBSD 的 source tree。 無論如何，大多數的改變都會事前在 <>先討論過，而且不分角色，每個人都可以參與討論。 === 我要如何取得 FreeBSD？ Every significant release of FreeBSD is available via anonymous FTP from the link:ftp://ftp.FreeBSD.org/pub/FreeBSD/[FreeBSD FTP site]: * The latest _12-STABLE_ release, 12.0-RELEASE can be found in the link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/i386/12.0-RELEASE/[12.0-RELEASE directory]. * <> 和 <> 分支的link:https://www.FreeBSD.org/snapshots/[Snapshot]版本通常每個月會做一次， 主要是為了提供給那些熱心的測試者和開發人員。 * The latest _11-STABLE_ release, 10.4-RELEASE can be found in the link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/10.4-RELEASE/[10.4-RELEASE directory]. FreeBSD 的 CD、DVD，還有其他取得方式可以在 extref:{handbook}mirrors[the Handbook, mirrors] 中找到解答。 === 我要如何去查詢、提交問題回報(Problem Report，簡稱PR)資料庫呢？ 所有使用者的變更要求都可以經由網頁版的 PR https://bugs.FreeBSD.org/search/[查詢] 界面來察看。 可以使用瀏覽器經由link:https://www.FreeBSD.org/support/bugreports/[網頁版的 PR 界面] 來傳送問題回報 然而，在您回報問題之前，請先閱讀 extref:{problem-reports}[如何撰寫 FreeBSD 的問題回報單]，這是一篇告訴你怎樣才能寫出一篇真正有用的問題回報單。 == 文件與技術支援 === 有哪些 FreeBSD 相關的好書呢？ FreeBSD 文件計畫已陸續發表了相當廣泛範圍的文件，可在 https://www.FreeBSD.org/docs/[https://www.FreeBSD.org/docs/] 取得。除此之外，也可以參閱使用手冊的 extref:{handbook}bibliography[參考書目, bibliography]建議的其他書籍。 === 這些文件有其他格式的嗎？像是：純文字(ASCII)或 PostScript 之類的格式？ -有的。這些文件都分別以不同格式儲存以及壓縮處理並放在 FTP 上面，可以從各個 FreeBSD FTP 站的 https://download.freebsd.org/ftp/doc/[/pub/FreeBSD/doc/] 目錄內找到你要的。 +有的。這些文件都分別以不同格式儲存以及壓縮處理並放在 FTP 上面，可以從各個 FreeBSD FTP 站的 https://download.freebsd.org/doc/[/pub/FreeBSD/doc/] 目錄內找到你要的。 文件以幾種不同的方式分類。包括： * 文件名稱，例如：`faq` (常見問答集)或是 `handbook` (FreeBSD 使用手冊)等等。 * 文件的語言與編碼。他們是基於 FreeBSD 系統中 [.filename]#/usr/shared/locale# 裡所見到的語系名稱。目前包含的語言與編碼如下： + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | 語系名稱 | 說明 |`en_US.ISO8859-1` |英文 (美國) |`bn_BD.ISO10646-1` |孟加拉文 (孟加拉) |`da_DK.ISO8859-1` |丹麥文 (丹麥) |`de_DE.ISO8859-1` |德文 (德國) |`el_GR.ISO8859-7` |希臘文 (希臘) |`es_ES.ISO8859-1` |西班牙文 (西班牙) |`fr_FR.ISO8859-1` |法文 (法國) |`hu_HU.ISO8859-2` |匈牙利文 (匈牙利) |`it_IT.ISO8859-15` |義大利文 (義大利) |`ja_JP.eucJP` |日文 (日本, EUC 編碼) |`ko_KR.UTF-8` |韓文 (韓國, UTF-8 編碼) |`mn_MN.UTF-8` |蒙古文 (蒙古, UTF-8 編碼) |`nl_NL.ISO8859-1` |荷蘭文 (荷蘭) |`pl_PL.ISO8859-2` |波蘭文 (波蘭) |`pt_BR.ISO8859-1` |葡萄牙文 (巴西) |`ru_RU.KOI8-R` |俄文 (俄羅斯, KOI8-R 編碼) |`tr_TR.ISO8859-9` |土耳其文 (土耳其) |`zh_CN.UTF-8` |簡體中文 (中國, UTF-8 編碼) |`zh_TW.UTF-8` |正體中文 (台灣, UTF-8 編碼) |=== + [NOTE] ==== 上列的各國翻譯語系文件中，並非所有文件都有翻譯。 ==== * 文件的格式。我們的每份文件都提供許多不同的格式，每種格式各有利弊， 有些格式適合線上閱讀，有些則適合列印出美觀的文件。 這些不同格式的文件能夠確保我們的讀者們，無論是在螢幕上閱讀或是列印成紙本，都能夠閱讀他們感興趣的內容，目前有提供的格式如下： + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | 格式 | 說明 |`html-split` |依章節區分成多個小的、互相連結的 HTML 檔案 |`html` |所有內容包含在單一個 HTML 檔案 |`pdf` | Adobe's PDF 格式 |`ps` |PostScript(TM) |`rtf` |Microsoft(TM) 的 RTF 格式 |`txt` |純文字 |=== + [NOTE] ==== 當用 Word 讀取 RTF 格式時，頁碼並不會被自動更新。在開啟檔案後按下kbd:[Ctrl+A], kbd:[Ctrl+End], kbd:[F9] 來更新頁碼。 ==== * 壓縮和打包方式 .. 當採用 `html-split` 格式時，檔案先透過 man:tar[1] 工具來進行打包。接著再將產生出來的 [.filename]#.tar# 檔接透過第二點所述的壓縮方式壓縮。 .. 其他的格式都是單一個檔案。例如 [.filename]#article.pdf#、[.filename]#book.html# ，以此類推。 + 這些檔案接著透過 `zip` 或 `bz2` 來壓縮。 man:tar[1] 工具可用來解壓縮這些檔案。 + 因此 PostScript(TM) 版本的手冊經過 `bzip2` 壓縮後會存成一個叫做 [.filename]#book.ps.bz2# 的檔案，並位於 [.filename]#handbook/# 資料夾。 在選取格式與壓縮方式後，下載壓縮後的檔案並解壓縮，再把文件複製到想要的地方。 舉例來說，透過 man:bzip2[1] 壓縮的英文問與答的章節分割 HTML 版本，可以在 [.filename]#doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2# 中找到。若要下載並解壓縮這個檔案，請輸入 [source,shell] .... -# fetch https://download.freebsd.org/ftp/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 +# fetch https://download.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.bz2 # tar xvf book.html-split.tar.bz2 .... 如果檔案被壓縮過的話，tar 會自動偵測正確的格式並解壓縮出一堆 [.filename]#.html# 檔案。主要的檔案是 [.filename]#index.html#，包含了主目錄跟介紹以及連接到文件其他部份的連結。 === 哪裡有關於 FreeBSD 的郵遞論壇(mailing lists)呢？ 有哪些可以使用的 FreeBSD 新聞群組(news groups)呢? 請參考FreeBSD 使用手冊上的 extref:{handbook}eresources[郵件論壇 (mailing-lists), eresources-mail] 。 === 有 FreeBSD IRC (Internet Relay Chat)頻道嗎？ 有的，大部分的 IRC 主機都有 FreeBSD 聊天頻道： * http://www.efnet.org/index.php[EFNet] 上的 `#FreeBSDhelp` 頻道專門用來幫助 FreeBSD 使用著 * http://freenode.net/[Freenode] 上的 ``\#FreeBSD`` 頻道是一個有許多使用者的一般求助頻道。這個頻道時常聊一些題外話，但主要還是讓使用者問 FreeBSD 相關問題的地方。其他使用者可以協助解答一些基本的問題，並請盡量提供使用手冊的參考或是提供連結來提供更深入的資訊。雖然這個頻道有來自世界各地的使用者，但這是一個英文為主的頻道。非母語人士應該以英文提問，並在必要的時候移駕到 ``##freebsd-lang`` 頻道。 * http://www.dal.net/[DALNET] 的``#FreeBSD`` 頻道，可由 `irc.dal.net` （位於美國）及``irc.eu.dal.net`` （位於歐洲）進入。 * http://www.undernet.org/[UNDERNET] 上的 ``#FreeBSD`` 頻道可由 `us.undernet.org`（位於美國）及 `eu.undernet.org` （位於歐洲）進入。由於這是個輔助新手用的頻道， 請記得閱讀別人向你提及的連結或檔案。 * http://www.rusnet.org.ru/[RUSNET] 上的 ``#FreeBSD`` 頻道是俄語國家的 FreeBSD 使用者頻道。 這裡同時也是一般交流的討論好去處。 * http://freenode.net/[Freenode] 上的 ``#bsdchat`` 頻道是一個正體中文（UTF-8 編碼）頻道專門用來幫助 FreeBSD 使用著。這裡也歡迎一般非技術的交流討論。 The FreeBSD wiki has a https://wiki.freebsd.org/IRC/Channels[good list] of IRC channels. 每個頻道都是不同且互相獨立的。因為他們的聊天風格不同，您可以每個都試試看來找到適合您的頻道。 === 有沒有任何網頁形式的 FreeBSD 論壇呢？ 官方的 FreeBSD 論壇位於 https://forums.FreeBSD.org/[https://forums.FreeBSD.org/]。 === 可以從哪邊獲得商業化的 FreeBSD 的教育課程及技術支援呢？ http://www.ixsystems.com[iXsystems, Inc.]， http://www.freebsdmall.com/[FreeBSD 商城]的母公司，提供 FreeBSD 開發與調校解決方案與 FreeBSD 與 TrueOS 的軟體 http://www.ixsystems.com/support[支援]。 BSD Certification Group, Inc. 提供 DragonFly BSD、FreeBSD、NetBSD 與 OpenBSD 的系統管理認證。請參閱 http://www.BSDCertification.org[他們的網站] 來獲得更多資訊。 如果有其他組織提供技術訓練或技術支援，請聯絡 FreeBSD 計畫來加入以上清單。 == 安裝 === Which platform should I download? I have a 64 bit capable Intel CPU, but I only see amd64. amd64 is the term FreeBSD uses for 64-bit compatible x86 architectures (also known as "x86-64" or "x64"). Most modern computers should use amd64. Older hardware should use i386. When installing on a non-x86-compatible architecture, select the platform which best matches the hardware. === Which file do I download to get FreeBSD? On the https://www.freebsd.org/where/[Getting FreeBSD] page, select `[iso]` next to the architecture that matches the hardware. Any of the following can be used: [.informaltable] [cols="1,1", frame="none", options="header"] |=== | 檔案 | 描述 |[.filename]#disc1.iso# |Contains enough to install FreeBSD and a minimal set of packages. |[.filename]#dvd1.iso# |Similar to [.filename]#disc1.iso# but with additional packages. |[.filename]#memstick.img# |A bootable image sufficient for writing to a USB stick. |[.filename]#bootonly.iso# |A minimal image that requires network access during installation to completely install FreeBSD. |=== Full instructions on this procedure and a little bit more about installation issues in general can be found in the extref:{handbook}bsdinstall[Handbook entry on installing FreeBSD, bsdinstall]. === What do I do if the install image does not boot? This can be caused by not downloading the image in _binary_ mode when using FTP. Some FTP clients default their transfer mode to _ascii_ and attempt to change any end-of-line characters received to match the conventions used by the client's system. This will almost invariably corrupt the boot image. Check the SHA-256 checksum of the downloaded boot image: if it is not _exactly_ that on the server, then the download process is suspect. When using a command line FTP client, type _binary_ at the FTP command prompt after getting connected to the server and before starting the download of the image. === 可以在哪邊找到安裝 FreeBSD 的解說步驟呢？ 安裝說明可以在 extref:{handbook}bsdinstall[使用手冊的安裝 FreeBSD, bsdinstall] 找到。 === 要跑 FreeBSD 至少需要什麼樣的配備呢？ FreeBSD 需要 486 以上的 PC，64 MB 以上的 RAM，和至少 1.1 GB 的硬碟空間。 === 要怎樣才能自行打造專用的安裝磁片呢？ 可以透過編譯客製化發行版本來建立客製化的 FreeBSD 安裝媒體。請參閱 extref:{releng}[Release Engineering] 文章的說明。 === Windows 可以與 FreeBSD 共存嗎？ 如果 Windows(TM) 先安裝，那就可以。 FreeBSD 的開機管理程式將會管理 Windows(TM) 和 FreeBSD 的開機啟動。 如果 Windows(TM) 後安裝，它將覆蓋開機管理程式。如果發生這種情況，請見下一小節。 === Another operating system destroyed my Boot Manager. How do I get it back? This depends upon the boot manager. The FreeBSD boot selection menu can be reinstalled using man:boot0cfg[8]. For example, to restore the boot menu onto the disk _ada0_: [source,shell] .... # boot0cfg -B ada0 .... The non-interactive MBR bootloader can be installed using man:gpart[8]: [source,shell] .... # gpart bootcode -b /boot/mbr ada0 .... For more complex situations, including GPT disks, see man:gpart[8]. === 我需要安裝完整的原始碼嗎？ In general, no. There is nothing in the base system which requires the presence of the source to operate. Some ports, like package:sysutils/lsof[], will not build unless the source is installed. In particular, if the port builds a kernel module or directly operates on kernel structures, the source must be installed. === 需要重新 build kernel 嗎？ Usually not. The supplied `GENERIC` kernel contains the drivers an ordinary computer will need. man:freebsd-update[8], the FreeBSD binary upgrade tool, cannot upgrade custom kernels, another reason to stick with the `GENERIC` kernel when possible. For computers with very limited RAM, such as embedded systems, it may be worthwhile to build a smaller custom kernel containing just the required drivers. === Should I use DES, Blowfish, or MD5 passwords and how do I specify which form my users receive? FreeBSD uses _SHA512_ by default. DES passwords are still available for backwards compatibility with operating systems that still use the less secure password format. FreeBSD also supports the Blowfish and MD5 password formats. Which password format to use for new passwords is controlled by the `passwd_format` login capability in [.filename]#/etc/login.conf#, which takes values of `des`, `blf` (if these are available) or `md5`. See the man:login.conf[5] manual page for more information about login capabilities. === What are the limits for FFS file systems? For FFS file systems, the largest file system is practically limited by the amount of memory required to man:fsck[8] the file system. man:fsck[8] requires one bit per fragment, which with the default fragment size of 4 KB equates to 32 MB of memory per TB of disk. This does mean that on architectures which limit userland processes to 2 GB (e.g., i386(TM)), the maximum man:fsck[8]'able filesystem is ~60 TB. If there was not a man:fsck[8] memory limit the maximum filesystem size would be 2 ^ 64 (blocks) * 32 KB => 16 Exa * 32 KB => 512 ZettaBytes. The maximum size of a single FFS file is approximately 2 PB with the default block size of 32 KB. Each 32 KB block can point to 4096 blocks. With triple indirect blocks, the calculation is 32 KB * 12 + 32 KB * 4096 + 32 KB * 4096^2 + 32 KB * 4096^3. Increasing the block size to 64 KB will increase the max file size by a factor of 16. === Why do I get an error message, readin failed after compiling and booting a new kernel? The world and kernel are out of sync. This is not supported. Be sure to use `make buildworld` and `make buildkernel` to update the kernel. Boot the system by specifying the kernel directly at the second stage, pressing any key when the `|` shows up before loader is started. === 是否有工具可以執行安裝後的設定工作嗎？ 是的。bsdconfig 提供很棒的介面來進行 FreeBSD 安裝後設定。 [[hardware]] == 硬體相容性 [[compatibility-general]] === 一般問題 ==== I want to get a piece of hardware for my FreeBSD system. Which model/brand/type is best? This is discussed continually on the FreeBSD mailing lists but is to be expected since hardware changes so quickly. Read through the Hardware Notes for FreeBSD https://www.FreeBSD.org/releases/12.0r/hardware[12.0] or https://www.FreeBSD.org/releases/10.4r/hardware[10.4] and search the mailing list https://www.FreeBSD.org/search/#mailinglists[archives] before asking about the latest and greatest hardware. Chances are a discussion about that type of hardware took place just last week. Before purchasing a laptop, check the archives for http://lists.FreeBSD.org/mailman/listinfo/freebsd-mobile[FreeBSD laptop computer mailing list] and http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[FreeBSD general questions mailing list], or possibly a specific mailing list for a particular hardware type. ==== What are the limits for memory? Does FreeBSD support more than 4 GB of memory (RAM)? More than 16 GB? More than 48 GB? FreeBSD as an operating system generally supports as much physical memory (RAM) as the platform it is running on does. Keep in mind that different platforms have different limits for memory; for example i386(TM) without PAE supports at most 4 GB of memory (and usually less than that because of PCI address space) and i386(TM) with PAE supports at most 64 GB memory. As of FreeBSD 10, AMD64 platforms support up to 4 TB of physical memory. ==== Why does FreeBSD report less than 4 GB memory when installed on an i386 machine? The total address space on i386(TM) machines is 32-bit, meaning that at most 4 GB of memory is addressable (can be accessed). Furthermore, some addresses in this range are reserved by hardware for different purposes, for example for using and controlling PCI devices, for accessing video memory, and so on. Therefore, the total amount of memory usable by the operating system for its kernel and applications is limited to significantly less than 4 GB. Usually, 3.2 GB to 3.7 GB is the maximum usable physical memory in this configuration. To access more than 3.2 GB to 3.7 GB of installed memory (meaning up to 4 GB but also more than 4 GB), a special tweak called PAE must be used. PAE stands for Physical Address Extension and is a way for 32-bit x86 CPUs to address more than 4 GB of memory. It remaps the memory that would otherwise be overlaid by address reservations for hardware devices above the 4 GB range and uses it as additional physical memory (see man:pae[4]). Using PAE has some drawbacks; this mode of memory access is a little bit slower than the normal (without PAE) mode and loadable modules (see man:kld[4]) are not supported. This means all drivers must be compiled into the kernel. The most common way to enable PAE is to build a new kernel with the special ready-provided kernel configuration file called [.filename]#PAE#, which is already configured to build a safe kernel. Note that some entries in this kernel configuration file are too conservative and some drivers marked as unready to be used with PAE are actually usable. A rule of thumb is that if the driver is usable on 64-bit architectures (like AMD64), it is also usable with PAE. When creating a custom kernel configuration file, PAE can be enabled by adding the following line: [.programlisting] .... options PAE .... PAE is not much used nowadays because most new x86 hardware also supports running in 64-bit mode, known as AMD64 or Intel(TM) 64. It has a much larger address space and does not need such tweaks. FreeBSD supports AMD64 and it is recommended that this version of FreeBSD be used instead of the i386(TM) version if 4 GB or more memory is required. [[compatibility-processors]] === Architectures and Processors ==== Does FreeBSD support architectures other than the x86? Yes. FreeBSD divides support into multiple tiers. Tier 1 architectures, such as i386 or amd64; are fully supported. Tiers 2 and 3 are supported on a best-effort basis. A full explanation of the tier system is available in the extref:{committers-guide}[Committer's Guide., archs] A complete list of supported architectures can be found on the https://www.FreeBSD.org/platforms/[platforms page.] ==== Does FreeBSD support Symmetric Multiprocessing (SMP)? FreeBSD supports symmetric multi-processor (SMP) on all non-embedded platforms (e.g, i386, amd64, etc.). SMP is also supported in arm and MIPS kernels, although some CPUs may not support this. FreeBSD's SMP implementation uses fine-grained locking, and performance scales nearly linearly with number of CPUs. man:smp[4] has more details. ==== What is microcode? How do I install Intel CPU microcode updates? Microcode is a method of programmatically implementing hardware level instructions. This allows for CPU bugs to be fixed without replacing the on board chip. Install package:sysutils/devcpu-data[], then add: [.programlisting] .... microcode_update_enable="YES" .... to [.filename]#/etc/rc.conf# [[compatibility-drives]] === Hard Drives, Tape Drives, and CD and DVD Drives ==== What kind of hard drives does FreeBSD support? FreeBSD supports EIDE, SATA, SCSI, and SAS drives (with a compatible controller; see the next section), and all drives using the original "Western Digital" interface (MFM, RLL, ESDI, and of course IDE). A few ESDI controllers that use proprietary interfaces may not work: stick to WD1002/3/6/7 interfaces and clones. ==== Which SCSI or SAS controllers are supported? See the complete list in the Hardware Notes for FreeBSD https://www.FreeBSD.org/releases/12.0r/hardware[12.0] or https://www.FreeBSD.org/releases/10.4r/hardware[10.4]. ==== What types of tape drives are supported? FreeBSD supports all standard SCSI tape interfaces. ==== Does FreeBSD support tape changers? FreeBSD supports SCSI changers using the man:ch[4] device and the man:chio[1] command. The details of how to control the changer can be found in man:chio[1]. While AMANDA and some other products already understands changers, other applications only know how to move a tape from one point to another. In this case, keep track of which slot a tape is in and which slot the tape currently in the drive needs to go back to. ==== Which CD-ROM and CD-RW drives are supported by FreeBSD? Any SCSI drive connected to a supported controller is supported. Most ATAPI compatible IDE CD-ROMs are supported. FreeBSD supports any ATAPI-compatible IDE CD-R or CD-RW drive. FreeBSD also supports any SCSI CD-R or CD-RW drives. Install the package:sysutils/cdrtools[] port or package, then use `cdrecord`. [[compatibility-kbd-mice]] === Keyboards and Mice [[moused]] ==== Is it possible to use a mouse outside the X Window system? The default console driver, man:syscons[4], provides the ability to use a mouse pointer in text consoles to cut & paste text. Run the mouse daemon, man:moused[8], and turn on the mouse pointer in the virtual console: [source,shell] .... # moused -p /dev/xxxx -t yyyy # vidcontrol -m on .... Where _xxxx_ is the mouse device name and _yyyy_ is a protocol type for the mouse. The mouse daemon can automatically determine the protocol type of most mice, except old serial mice. Specify the `auto` protocol to invoke automatic detection. If automatic detection does not work, see the man:moused[8] manual page for a list of supported protocol types. For a PS/2 mouse, add `moused_enable="YES"` to [.filename]#/etc/rc.conf# to start the mouse daemon at boot time. Additionally, to use the mouse daemon on all virtual terminals instead of just the console, add `allscreens_flags="-m on"` to [.filename]#/etc/rc.conf#. When the mouse daemon is running, access to the mouse must be coordinated between the mouse daemon and other programs such as X Windows. Refer to the FAQ<> for more details on this issue. ==== How do I cut and paste text with a mouse in the text console? It is not possible to remove data using the mouse. However, it is possible to copy and paste. Once the mouse daemon is running as described in the <>, hold down button 1 (left button) and move the mouse to select a region of text. Then, press button 2 (middle button) to paste it at the text cursor. Pressing button 3 (right button) will "extend" the selected region of text. If the mouse does not have a middle button, it is possible to emulate one or remap buttons using mouse daemon options. See the man:moused[8] manual page for details. === My mouse has a fancy wheel and buttons. Can I use them in FreeBSD? The answer is, unfortunately, "It depends". These mice with additional features require specialized driver in most cases. Unless the mouse device driver or the user program has specific support for the mouse, it will act just like a standard two, or three button mouse. For the possible usage of wheels in the X Window environment, refer to <>. ==== How do I use my delete key in sh and csh? For the Bourne Shell, add the following lines to [.filename]#~/.shrc#. See man:sh[1] and man:editrc[5]. [.programlisting] .... bind ^? ed-delete-next-char # for console bind ^[[3~ ed-delete-next-char # for xterm .... For the C Shell, add the following lines to [.filename]#~/.cshrc#. See man:csh[1]. [.programlisting] .... bindkey ^? delete-char # for console bindkey ^[[3~ delete-char # for xterm .... For more information, see http://www.ibb.net/~anne/keyboard.html[this page]. [[compatibility-other]] === Other Hardware ==== Workarounds for no sound from my pcm4 sound card? Some sound cards set their output volume to 0 at every boot. Run the following command every time the machine boots: [source,shell] .... # mixer pcm 100 vol 100 cd 100 .... ==== Does FreeBSD support power management on my laptop? FreeBSD supports the ACPI features found in modern hardware. Further information can be found in man:acpi[4]. == Troubleshooting === Why is FreeBSD finding the wrong amount of memory on i386 hardware? The most likely reason is the difference between physical memory addresses and virtual addresses. The convention for most PC hardware is to use the memory area between 3.5 GB and 4 GB for a special purpose (usually for PCI). This address space is used to access PCI hardware. As a result real, physical memory cannot be accessed by that address space. What happens to the memory that should appear in that location is hardware dependent. Unfortunately, some hardware does nothing and the ability to use that last 500 MB of RAM is entirely lost. Luckily, most hardware remaps the memory to a higher location so that it can still be used. However, this can cause some confusion when watching the boot messages. On a 32-bit version of FreeBSD, the memory appears lost, since it will be remapped above 4 GB, which a 32-bit kernel is unable to access. In this case, the solution is to build a PAE enabled kernel. See the entry on memory limits for more information. On a 64-bit version of FreeBSD, or when running a PAE-enabled kernel, FreeBSD will correctly detect and remap the memory so it is usable. During boot, however, it may seem as if FreeBSD is detecting more memory than the system really has, due to the described remapping. This is normal and the available memory will be corrected as the boot process completes. === Why do my programs occasionally die with Signal 11 errors? Signal 11 errors are caused when a process has attempted to access memory which the operating system has not granted it access to. If something like this is happening at seemingly random intervals, start investigating the cause. These problems can usually be attributed to either: . If the problem is occurring only in a specific custom application, it is probably a bug in the code. . If it is a problem with part of the base FreeBSD system, it may also be buggy code, but more often than not these problems are found and fixed long before us general FAQ readers get to use these bits of code (that is what -CURRENT is for). It is probably not a FreeBSD bug if the problem occurs compiling a program, but the activity that the compiler is carrying out changes each time. For example, if `make buildworld` fails while trying to compile [.filename]#ls.c# into [.filename]#ls.o# and, when run again, it fails in the same place, this is a broken build. Try updating source and try again. If the compile fails elsewhere, it is almost certainly due to hardware. In the first case, use a debugger such as man:gdb[1] to find the point in the program which is attempting to access a bogus address and fix it. In the second case, verify which piece of hardware is at fault. Common causes of this include: . The hard disks might be overheating: Check that the fans are still working, as the disk and other hardware might be overheating. . The processor running is overheating: This might be because the processor has been overclocked, or the fan on the processor might have died. In either case, ensure that the hardware is running at what it is specified to run at, at least while trying to solve this problem. If it is not, clock it back to the default settings.) + Regarding overclocking, it is far cheaper to have a slow system than a fried system that needs replacing! Also the community is not sympathetic to problems on overclocked systems. . Dodgy memory: if multiple memory SIMMS/DIMMS are installed, pull them all out and try running the machine with each SIMM or DIMM individually to narrow the problem down to either the problematic DIMM/SIMM or perhaps even a combination. . Over-optimistic motherboard settings: the BIOS settings, and some motherboard jumpers, provide options to set various timings. The defaults are often sufficient, but sometimes setting the wait states on RAM too low, or setting the "RAM Speed: Turbo" option will cause strange behavior. A possible idea is to set to BIOS defaults, after noting the current settings first. . Unclean or insufficient power to the motherboard. Remove any unused I/O boards, hard disks, or CD-ROMs, or disconnect the power cable from them, to see if the power supply can manage a smaller load. Or try another power supply, preferably one with a little more power. For instance, if the current power supply is rated at 250 Watts, try one rated at 300 Watts. Read the section on <> for a further explanation and a discussion on how memory testing software or hardware can still pass faulty memory. There is an extensive FAQ on this at http://www.bitwizard.nl/sig11/[the SIG11 problem FAQ]. Finally, if none of this has helped, it is possibly a bug in FreeBSD. Follow <> to send a problem report. === My system crashes with either Fatal trap 12: page fault in kernel mode, or panic:, and spits out a bunch of information. What should I do? The FreeBSD developers are interested in these errors, but need more information than just the error message. Copy the full crash message. Then consult the FAQ section on <>, build a debugging kernel, and get a backtrace. This might sound difficult, but does not require any programming skills. Just follow the instructions. === What is the meaning of the error maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)? The FreeBSD kernel will only allow a certain number of processes to exist at one time. The number is based on the `kern.maxusers` man:sysctl[8] variable. `kern.maxusers` also affects various other in-kernel limits, such as network buffers. If the machine is heavily loaded, increase `kern.maxusers`. This will increase these other system limits in addition to the maximum number of processes. To adjust the `kern.maxusers` value, see the extref:{handbook}config-tuning[File/Process Limits, kern-maxfiles] section of the Handbook. While that section refers to open files, the same limits apply to processes. If the machine is lightly loaded but running a very large number of processes, adjust the `kern.maxproc` tunable by defining it in [.filename]#/boot/loader.conf#. The tunable will not get adjusted until the system is rebooted. For more information about tuning tunables, see man:loader.conf[5]. If these processes are being run by a single user, adjust `kern.maxprocperuid` to be one less than the new `kern.maxproc` value. It must be at least one less because one system program, man:init[8], must always be running. === Why do full screen applications on remote machines misbehave? The remote machine may be setting the terminal type to something other than `xterm` which is required by the FreeBSD console. Alternatively the kernel may have the wrong values for the width and height of the terminal. Check the value of the `TERM` environment variable is `xterm`. If the remote machine does not support that try `vt100`. Run `stty -a` to check what the kernel thinks the terminal dimensions are. If they are incorrect, they can be changed by running `stty rows _RR_ cols _CC_`. Alternatively, if the client machine has package:x11/xterm[] installed, then running `resize` will query the terminal for the correct dimensions and set them. === Why does it take so long to connect to my computer via ssh or telnet? The symptom: there is a long delay between the time the TCP connection is established and the time when the client software asks for a password (or, in man:telnet[1]'s case, when a login prompt appears). The problem: more likely than not, the delay is caused by the server software trying to resolve the client's IP address into a hostname. Many servers, including the Telnet and SSH servers that come with FreeBSD, do this to store the hostname in a log file for future reference by the administrator. The remedy: if the problem occurs whenever connecting the client computer to any server, the problem is with the client. If the problem only occurs when someone connects to the server computer, the problem is with the server. If the problem is with the client, the only remedy is to fix the DNS so the server can resolve it. If this is on a local network, consider it a server problem and keep reading. If this is on the Internet, contact your ISP. If the problem is with the server on a local network, configure the server to resolve address-to-hostname queries for the local address range. See man:hosts[5] and man:named[8] for more information. If this is on the Internet, the problem may be that the local server's resolver is not functioning correctly. To check, try to look up another host such as `www.yahoo.com`. If it does not work, that is the problem. Following a fresh install of FreeBSD, it is also possible that domain and name server information is missing from [.filename]#/etc/resolv.conf#. This will often cause a delay in SSH, as the option `UseDNS` is set to `yes` by default in [.filename]#/etc/ssh/sshd_config#. If this is causing the problem, either fill in the missing information in [.filename]#/etc/resolv.conf# or set `UseDNS` to `no` in [.filename]#sshd_config# as a temporary workaround. === Why does file: table is full show up repeatedly in dmesg8? This error message indicates that the number of available file descriptors have been exhausted on the system. Refer to the extref:{handbook}config-tuning[kern.maxfiles, kern-maxfiles] section of the extref:{handbook}config-tuning[Tuning Kernel Limits, configtuning-kernel-limits] section of the Handbook for a discussion and solution. === Why does the clock on my computer keep incorrect time? The computer has two or more clocks, and FreeBSD has chosen to use the wrong one. Run man:dmesg[8], and check for lines that contain `Timecounter`. The one with the highest quality value that FreeBSD chose. [source,shell] .... # dmesg | grep Timecounter Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Timecounter "TSC" frequency 2998570050 Hz quality 800 Timecounters tick every 1.000 msec .... Confirm this by checking the `kern.timecounter.hardware` man:sysctl[3]. [source,shell] .... # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast .... It may be a broken ACPI timer. The simplest solution is to disable the ACPI timer in [.filename]#/boot/loader.conf#: [.programlisting] .... debug.acpi.disabled="timer" .... Or the BIOS may modify the TSC clock--perhaps to change the speed of the processor when running from batteries, or going into a power saving mode, but FreeBSD is unaware of these adjustments, and appears to gain or lose time. In this example, the `i8254` clock is also available, and can be selected by writing its name to the `kern.timecounter.hardware` man:sysctl[3]. [source,shell] .... # sysctl kern.timecounter.hardware=i8254 kern.timecounter.hardware: TSC -> i8254 .... The computer should now start keeping more accurate time. To have this change automatically run at boot time, add the following line to [.filename]#/etc/sysctl.conf#: [.programlisting] .... kern.timecounter.hardware=i8254 .... === What does the error swap_pager: indefinite wait buffer: mean? This means that a process is trying to page memory from disk, and the page attempt has hung trying to access the disk for more than 20 seconds. It might be caused by bad blocks on the disk drive, disk wiring, cables, or any other disk I/O-related hardware. If the drive itself is bad, disk errors will appear in [.filename]#/var/log/messages# and in the output of `dmesg`. Otherwise, check the cables and connections. === What is a lock order reversal? The FreeBSD kernel uses a number of resource locks to arbitrate contention for certain resources. When multiple kernel threads try to obtain multiple resource locks, there's always the potential for a deadlock, where two threads have each obtained one of the locks and blocks forever waiting for the other thread to release one of the other locks. This sort of locking problem can be avoided if all threads obtain the locks in the same order. A run-time lock diagnostic system called man:witness[4], enabled in FreeBSD-CURRENT and disabled by default for stable branches and releases, detects the potential for deadlocks due to locking errors, including errors caused by obtaining multiple resource locks with a different order from different parts of the kernel. The man:witness[4] framework tries to detect this problem as it happens, and reports it by printing a message to the system console about a `lock order reversal` (often referred to also as LOR). It is possible to get false positives, as man:witness[4] is conservative. A true positive report _does not_ mean that a system is dead-locked; instead it should be understood as a warning that a deadlock could have happened here. [NOTE] ==== Problematic LORs tend to get fixed quickly, so check the http://lists.FreeBSD.org/mailman/listinfo/freebsd-current[FreeBSD-CURRENT mailing list] before posting to it. ==== === What does Called ... with the following non-sleepable locks held mean? This means that a function that may sleep was called while a mutex (or other unsleepable) lock was held. The reason this is an error is because mutexes are not intended to be held for long periods of time; they are supposed to only be held to maintain short periods of synchronization. This programming contract allows device drivers to use mutexes to synchronize with the rest of the kernel during interrupts. Interrupts (under FreeBSD) may not sleep. Hence it is imperative that no subsystem in the kernel block for an extended period while holding a mutex. To catch such errors, assertions may be added to the kernel that interact with the man:witness[4] subsystem to emit a warning or fatal error (depending on the system configuration) when a potentially blocking call is made while holding a mutex. In summary, such warnings are non-fatal, however with unfortunate timing they could cause undesirable effects ranging from a minor blip in the system's responsiveness to a complete system lockup. For additional information about locking in FreeBSD see man:locking[9]. === Why does buildworld/installworld die with the message touch: not found? This error does not mean that the man:touch[1] utility is missing. The error is instead probably due to the dates of the files being set sometime in the future. If the CMOS clock is set to local time, run `adjkerntz -i` to adjust the kernel clock when booting into single-user mode. == User Applications === Where are all the user applications? Refer to https://www.FreeBSD.org/ports/[the ports page] for info on software packages ported to FreeBSD. The list currently tops 24,000 and is growing daily, so come back to check often or subscribe to the http://lists.FreeBSD.org/mailman/listinfo/freebsd-announce[FreeBSD announcements mailing list] for periodic updates on new entries. Most ports should work on all supported versions of FreeBSD. Those that do not are specifically marked as such. Each time a FreeBSD release is made, a snapshot of the ports tree at the time of release in also included in the [.filename]#ports/# directory. FreeBSD supports compressed binary packages to easily install and uninstall ports. Use man:pkg[7] to control the installation of packages. === How do I download the Ports tree? Should I be using Subversion? Any of the methods listed here work: * Use portsnap for most use cases. Refer to extref:{handbook}ports[Using the Ports Collection, ports-using] for instructions on how to use this tool. * Use Subversion if custom patches to the ports tree are needed. Refer to extref:{handbook}mirrors[Using Subversion, svn] for details. === Does FreeBSD support Java? Yes. Refer to https://www.FreeBSD.org/java/[https://www.FreeBSD.org/java/] for more information. === Why can I not build this port on my 11.X -, or 12.X -STABLE machine? If the installed FreeBSD version lags significantly behind _-CURRENT_ or _-STABLE_, update the Ports Collection using the instructions in extref:{handbook}ports[Using the Ports Collection, ports-using]. If the system is up-to-date, someone might have committed a change to the port which works for _-CURRENT_ but which broke the port for _-STABLE_. https://bugs.FreeBSD.org/submit/[Submit] a bug report, since the Ports Collection is supposed to work for both the _-CURRENT_ and _-STABLE_ branches. === I just tried to build INDEX using make index, and it failed. Why? First, make sure that the Ports Collection is up-to-date. Errors that affect building [.filename]#INDEX# from an up-to-date copy of the Ports Collection are high-visibility and are thus almost always fixed immediately. There are rare cases where [.filename]#INDEX# will not build due to odd cases involving `OPTIONS_SET` being set in [.filename]#make.conf#. If you suspect that this is the case, try to make [.filename]#INDEX# with those variables turned off before reporting it to http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports[FreeBSD ports mailing list]. === I updated the sources, now how do I update my installed ports? FreeBSD does not include a port upgrading tool, but it does have some tools to make the upgrade process somewhat easier. Additional tools are available to simplify port handling and are described the extref:{handbook}ports[Upgrading Ports, ports-using] section in the FreeBSD Handbook. === Do I need to recompile every port each time I perform a major version update? Yes! While a recent system will run with software compiled under an older release, things will randomly crash and fail to work once other ports are installed or updated. When the system is upgraded, various shared libraries, loadable modules, and other parts of the system will be replaced with newer versions. Applications linked against the older versions may fail to start or, in other cases, fail to function properly. For more information, see extref:{handbook}updating-upgrading[the section on upgrades, freebsdupdate-upgrade] in the FreeBSD Handbook. === Do I need to recompile every port each time I perform a minor version update? In general, no. FreeBSD developers do their utmost to guarantee binary compatibility across all releases with the same major version number. Any exceptions will be documented in the Release Notes, and advice given there should be followed. === Why is /bin/sh so minimal? Why does FreeBSD not use bash or another shell? Many people need to write shell scripts which will be portable across many systems. That is why POSIX(TM) specifies the shell and utility commands in great detail. Most scripts are written in Bourne shell (man:sh[1]), and because several important programming interfaces (man:make[1], man:system[3], man:popen[3], and analogues in higher-level scripting languages like Perl and Tcl) are specified to use the Bourne shell to interpret commands. Because the Bourne shell is so often and widely used, it is important for it to be quick to start, be deterministic in its behavior, and have a small memory footprint. The existing implementation is our best effort at meeting as many of these requirements simultaneously as we can. To keep `/bin/sh` small, we have not provided many of the convenience features that other shells have. That is why other more featureful shells like `bash`, `scsh`, man:tcsh[1], and `zsh` are available. Compare the memory utilization of these shells by looking at the "VSZ" and "RSS" columns in a `ps -u` listing. === How do I create audio CDs from my MIDI files? To create audio CDs from MIDI files, first install package:audio/timidity[] from ports then install manually the GUS patches set by Eric A. Welsh, available at http://alleg.sourceforge.net/digmid.html[http://alleg.sourceforge.net/digmid.html]. After TiMidity++ has been installed properly, MIDI files may be converted to WAV files with the following command line: [source,shell] .... % timidity -Ow -s 44100 -o /tmp/juke/01.wav 01.mid .... The WAV files can then be converted to other formats or burned onto audio CDs, as described in the extref:{handbook}disks[FreeBSD Handbook, creating-cds]. == Kernel Configuration [[make-kernel]] === I would like to customize my kernel. Is it difficult? Not at all! Check out the extref:{handbook}kernelconfig[kernel config section of the Handbook, kernelconfig]. [NOTE] ==== The new [.filename]#kernel# will be installed to the [.filename]#/boot/kernel# directory along with its modules, while the old kernel and its modules will be moved to the [.filename]#/boot/kernel.old# directory. If a mistake is made in the configuration, simply boot the previous version of the kernel. ==== === Why is my kernel so big? `GENERIC` kernels shipped with FreeBSD are compiled in _debug mode_. Kernels built in debug mode contain debug data in separate files that are used for debugging. FreeBSD releases prior to 11.0 store these debug files in the same directory as the kernel itself, [.filename]#/boot/kernel/#. In FreeBSD 11.0 and later the debug files are stored in [.filename]#/usr/lib/debug/boot/kernel/#. Note that there will be little or no performance loss from running a debug kernel, and it is useful to keep one around in case of a system panic. When running low on disk space, there are different options to reduce the size of [.filename]#/boot/kernel/# and [.filename]#/usr/lib/debug/#. To not install the symbol files, make sure the following line exists in [.filename]#/etc/src.conf#: [.programlisting] .... WITHOUT_KERNEL_SYMBOLS=yes .... For more information see man:src.conf[5]. If you want to avoid building debug files altogether, make sure that both of the following are true: * This line does not exist in the kernel configuration file: + [.programlisting] .... makeoptions DEBUG=-g .... * Do not run man:config[8] with `-g`. Either of the above settings will cause the kernel to be built in debug mode. To build and install only the specified modules, list them in [.filename]#/etc/make.conf#: [.programlisting] .... MODULES_OVERRIDE= accf_http ipfw .... Replace _accf_httpd ipfw_ with a list of needed modules. Only the listed modules will be built. This reduces the size of the kernel directory and decreases the amount of time needed to build the kernel. For more information, read [.filename]#/usr/shared/examples/etc/make.conf#. Unneeded devices can be removed from the kernel to further reduce the size. See <> for more information. To put any of these options into effect, follow the instructions to extref:{handbook}kernelconfig/[build and install, kernelconfig-building] the new kernel. For reference, the FreeBSD 11 amd64 kernel ([.filename]#/boot/kernel/kernel#) is approximately 25 MB. === Why does every kernel I try to build fail to compile, even GENERIC? There are a number of possible causes for this problem: * The source tree is different from the one used to build the currently running system. When attempting an upgrade, read [.filename]#/usr/src/UPDATING#, paying particular attention to the "COMMON ITEMS" section at the end. * The `make buildkernel` did not complete successfully. The `make buildkernel` target relies on files generated by the `make buildworld` target to complete its job correctly. * Even when building <>, it is possible that the source tree was fetched at a time when it was either being modified or it was broken. Only releases are guaranteed to be buildable, although <> builds fine the majority of the time. Try re-fetching the source tree and see if the problem goes away. Try using a different mirror in case the previous one is having problems. === Which scheduler is in use on a running system? The name of the scheduler currently being used is directly available as the value of the `kern.sched.name` sysctl: [source,shell] .... % sysctl kern.sched.name kern.sched.name: ULE .... === What is kern.sched.quantum? `kern.sched.quantum` is the maximum number of ticks a process can run without being preempted in the 4BSD scheduler. == Disks, File Systems, and Boot Loaders === How can I add my new hard disk to my FreeBSD system? See the extref:{handbook}disks[Adding Disks, disks-adding] section in the FreeBSD Handbook. === How do I move my system over to my huge new disk? The best way is to reinstall the operating system on the new disk, then move the user data over. This is highly recommended when tracking _-STABLE_ for more than one release or when updating a release instead of installing a new one. Install booteasy on both disks with man:boot0cfg[8] and dual boot until you are happy with the new configuration. Skip the next paragraph to find out how to move the data after doing this. Alternatively, partition and label the new disk with either man:sade[8] or man:gpart[8]. If the disks are MBR-formatted, booteasy can be installed on both disks with man:boot0cfg[8] so that the computer can dual boot to the old or new system after the copying is done. Once the new disk set up, the data cannot just be copied. Instead, use tools that understand device files and system flags, such as man:dump[8]. Although it is recommended to move the data while in single-user mode, it is not required. When the disks are formatted with UFS, never use anything but man:dump[8] and man:restore[8] to move the root file system. These commands should also be used when moving a single partition to another empty partition. The sequence of steps to use `dump` to move the data from one UFS partitions to a new partition is: [.procedure] ==== . `newfs` the new partition. . `mount` it on a temporary mount point. . `cd` to that directory. . `dump` the old partition, piping output to the new one. ==== For example, to move [.filename]#/dev/ada1s1a# with [.filename]#/mnt# as the temporary mount point, type: [source,shell] .... # newfs /dev/ada1s1a # mount /dev/ada1s1a /mnt # cd /mnt # dump 0af - / | restore rf - .... Rearranging partitions with `dump` takes a bit more work. To merge a partition like [.filename]#/var# into its parent, create the new partition large enough for both, move the parent partition as described above, then move the child partition into the empty directory that the first move created: [source,shell] .... # newfs /dev/ada1s1a # mount /dev/ada1s1a /mnt # cd /mnt # dump 0af - / | restore rf - # cd var # dump 0af - /var | restore rf - .... To split a directory from its parent, say putting [.filename]#/var# on its own partition when it was not before, create both partitions, then mount the child partition on the appropriate directory in the temporary mount point, then move the old single partition: [source,shell] .... # newfs /dev/ada1s1a # newfs /dev/ada1s1d # mount /dev/ada1s1a /mnt # mkdir /mnt/var # mount /dev/ada1s1d /mnt/var # cd /mnt # dump 0af - / | restore rf - .... The man:cpio[1] and man:pax[1] utilities are also available for moving user data. These are known to lose file flag information, so use them with caution. === Which partitions can safely use Soft Updates? I have heard that Soft Updates on / can cause problems. What about Journaled Soft Updates? Short answer: Soft Updates can usually be safely used on all partitions. Long answer: Soft Updates has two characteristics that may be undesirable on certain partitions. First, a Soft Updates partition has a small chance of losing data during a system crash. The partition will not be corrupted as the data will simply be lost. Second, Soft Updates can cause temporary space shortages. When using Soft Updates, the kernel can take up to thirty seconds to write changes to the physical disk. When a large file is deleted the file still resides on disk until the kernel actually performs the deletion. This can cause a very simple race condition. Suppose one large file is deleted and another large file is immediately created. The first large file is not yet actually removed from the physical disk, so the disk might not have enough room for the second large file. This will produce an error that the partition does not have enough space, even though a large chunk of space has just been released. A few seconds later, the file creation works as expected. If a system should crash after the kernel accepts a chunk of data for writing to disk, but before that data is actually written out, data could be lost. This risk is extremely small, but generally manageable. These issues affect all partitions using Soft Updates. So, what does this mean for the root partition? Vital information on the root partition changes very rarely. If the system crashed during the thirty-second window after such a change is made, it is possible that data could be lost. This risk is negligible for most applications, but be aware that it exists. If the system cannot tolerate this much risk, do not use Soft Updates on the root file system! [.filename]#/# is traditionally one of the smallest partitions. If [.filename]#/tmp# is on [.filename]#/#, there may be intermittent space problems. Symlinking [.filename]#/tmp# to [.filename]#/var/tmp# will solve this problem. Finally, man:dump[8] does not work in live mode (-L) on a filesystem, with Journaled Soft Updates (SU+J). === Can I mount other foreign file systems under FreeBSD? FreeBSD supports a variety of other file systems. UFS:: UFS CD-ROMs can be mounted directly on FreeBSD. Mounting disk partitions from Digital UNIX and other systems that support UFS may be more complex, depending on the details of the disk partitioning for the operating system in question. ext2/ext3:: FreeBSD supports `ext2fs` and `ext3fs` partitions. See man:ext2fs[5] for more information. NTFS:: FUSE based NTFS support is available as a port (package:sysutils/fusefs-ntfs[]). For more information see http://www.tuxera.com/community/ntfs-3g-manual/[ntfs-3g]. FAT:: FreeBSD includes a read-write FAT driver. For more information, see man:mount_msdosfs[8]. ZFS:: FreeBSD 包含由 Sun(TM) 移植過來的 ZFS 驅動程式。 目前的建議是僅在記憶體充足的 amd64 平臺上使用它。有關更詳細資訊, 請參閱 man:zfs[8]。 FreeBSD includes the Network File System NFS and the FreeBSD Ports Collection provides several FUSE applications to support many other file systems. === How do I mount a secondary DOS partition? The secondary DOS partitions are found after _all_ the primary partitions. For example, if `E` is the second DOS partition on the second SCSI drive, there will be a device file for "slice 5" in [.filename]#/dev#. To mount it: [source,shell] .... # mount -t msdosfs /dev/da1s5 /dos/e .... === Is there a cryptographic file system for FreeBSD? Yes, man:gbde[8] and man:geli[8]. See the extref:{handbook}disks[Encrypting Disk Partitions, disks-encrypting] section of the FreeBSD Handbook. === How do I boot FreeBSD and Linux using GRUB? To boot FreeBSD using GRUB, add the following to either [.filename]#/boot/grub/menu.lst# or [.filename]#/boot/grub/grub.conf#, depending upon which is used by the Linux(TM) distribution. [.programlisting] .... title FreeBSD 9.1 root (hd0,a) kernel /boot/loader .... Where _hd0,a_ points to the root partition on the first disk. To specify the slice number, use something like this _(hd0,2,a)_. By default, if the slice number is omitted, GRUB searches the first slice which has the `a` partition. === How do I boot FreeBSD and Linux using BootEasy? Install LILO at the start of the Linux(TM) boot partition instead of in the Master Boot Record. You can then boot LILO from BootEasy. This is recommended when running Windows(TM) and Linux(TM) as it makes it simpler to get Linux(TM) booting again if Windows(TM) is reinstalled. === How do I change the boot prompt from ??? to something more meaningful? This cannot be accomplished with the standard boot manager without rewriting it. There are a number of other boot managers in the [.filename]#sysutils# category of the Ports Collection. === How do I use a new removable drive? If the drive already has a file system on it, use a command like this: [source,shell] .... # mount -t msdosfs /dev/da0s1 /mnt .... If the drive will only be used with FreeBSD systems, partition it with UFS or ZFS. This will provide long filename support, improvement in performance, and stability. If the drive will be used by other operating systems, a more portable choice, such as msdosfs, is better. [source,shell] .... # dd if=/dev/zero of=/dev/da0 count=2 # gpart create -s GPT /dev/da0 # gpart add -t freebsd-ufs /dev/da0 .... Finally, create a new file system: [source,shell] .... # newfs /dev/da0p1 .... and mount it: [source,shell] .... # mount /dev/da0s1 /mnt .... It is a good idea to add a line to [.filename]#/etc/fstab# (see man:fstab[5]) so you can just type `mount /mnt` in the future: [.programlisting] .... /dev/da0p1 /mnt ufs rw,noauto 0 0 .... === Why do I get Incorrect super block when mounting a CD? The type of device to mount must be specified. This is described in the Handbook section on extref:{handbook}disks[Using Data CDs, mounting-cd]. === Why do I get Device not configured when mounting a CD? This generally means that there is no CD in the drive, or the drive is not visible on the bus. Refer to the extref:{handbook}disks[Using Data CDs, mounting-cd] section of the Handbook for a detailed discussion of this issue. === Why do all non-English characters in filenames show up as ? on my CDs when mounted in FreeBSD? The CD probably uses the "Joliet" extension for storing information about files and directories. This is discussed in the Handbook section on extref:{handbook}disks[Using Data CD-ROMs, mounting-cd]. === A CD burned under FreeBSD cannot be read under any other operating system. Why? This means a raw file was burned to the CD, rather than creating an ISO 9660 file system. Take a look at the Handbook section on extref:{handbook}disks[Using Data CDs, mounting-cd]. === How can I create an image of a data CD? This is discussed in the Handbook section on extref:{handbook}disks[Writing Data to an ISO File System, mkisofs]. For more on working with CD-ROMs, see the extref:{handbook}disks[Creating CDs Section, creating-cds] in the Storage chapter in the Handbook. === Why can I not mount an audio CD? Trying to mount an audio CD will produce an error like `cd9660: /dev/cd0: Invalid argument`. This is because `mount` only works on file systems. Audio CDs do not have file systems; they just have data. Instead, use a program that reads audio CDs, such as the package:audio/xmcd[] package or port. === How do I mount a multi-session CD? By default, man:mount[8] will attempt to mount the last data track (session) of a CD. To load an earlier session, use the `-s` command line argument. Refer to man:mount_cd9660[8] for specific examples. === How do I let ordinary users mount CD-ROMs, DVDs, USB drives, and other removable media? As `root` set the sysctl variable `vfs.usermount` to `1`. [source,shell] .... # sysctl vfs.usermount=1 .... To make this persist across reboots, add the line `vfs.usermount=1` to [.filename]#/etc/sysctl.conf# so that it is reset at system boot time. Users can only mount devices they have read permissions to. To allow users to mount a device permissions must be set in [.filename]#/etc/devfs.conf#. For example, to allow users to mount the first USB drive add: [.programlisting] .... # Allow all users to mount a USB drive. own /dev/da0 root:operator perm /dev/da0 0666 .... All users can now mount devices they could read onto a directory that they own: [source,shell] .... % mkdir ~/my-mount-point % mount -t msdosfs /dev/da0 ~/my-mount-point .... Unmounting the device is simple: [source,shell] .... % umount ~/my-mount-point .... Enabling `vfs.usermount`, however, has negative security implications. A better way to access MS-DOS(TM) formatted media is to use the package:emulators/mtools[] package in the Ports Collection. [NOTE] ==== The device name used in the previous examples must be changed according to the configuration. ==== === The du and df commands show different amounts of disk space available. What is going on? This is due to how these commands actually work. `du` goes through the directory tree, measures how large each file is, and presents the totals. `df` just asks the file system how much space it has left. They seem to be the same thing, but a file without a directory entry will affect `df` but not `du`. When a program is using a file, and the file is deleted, the file is not really removed from the file system until the program stops using it. The file is immediately deleted from the directory listing, however. As an example, consider a file large enough to affect the output of `du` and `df`. A file being viewed with `more` can be deleted wihout causing an error. The entry is removed from the directory so no other program or user can access it. However, `du` shows that it is gone as it has walked the directory tree and the file is not listed. `df` shows that it is still there, as the file system knows that `more` is still using that space. Once the `more` session ends, `du` and `df` will agree. This situation is common on web servers. Many people set up a FreeBSD web server and forget to rotate the log files. The access log fills up [.filename]#/var#. The new administrator deletes the file, but the system still complains that the partition is full. Stopping and restarting the web server program would free the file, allowing the system to release the disk space. To prevent this from happening, set up man:newsyslog[8]. Note that Soft Updates can delay the freeing of disk space and it can take up to 30 seconds for the change to be visible. === How can I add more swap space? This section extref:{handbook}config-tuning[of the Handbook, adding-swap-space] describes how to do this. === Why does FreeBSD see my disk as smaller than the manufacturer says it is? Disk manufacturers calculate gigabytes as a billion bytes each, whereas FreeBSD calculates them as 1,073,741,824 bytes each. This explains why, for example, FreeBSD's boot messages will report a disk that supposedly has 80 GB as holding 76,319 MB. Also note that FreeBSD will (by default) <> 8% of the disk space. === How is it possible for a partition to be more than 100% full? A portion of each UFS partition (8%, by default) is reserved for use by the operating system and the `root` user. man:df[1] does not count that space when calculating the `Capacity` column, so it can exceed 100%. Notice that the `Blocks` column is always greater than the sum of the `Used` and `Avail` columns, usually by a factor of 8%. For more details, look up `-m` in man:tunefs[8]. == ZFS === 使用 ZFS 最少需要多少記憶體？ 至少需要 4GB 的記憶體才能跑得順，但不同的工作負載可能會造成相當大的差異。 === ZIL 是什麼而又何時會被使用？ The ZIL (ZFS 動向日誌) 是一個紀錄日誌，用以實現系統當機時 POSIX 寫入保證的語義，多個正常 ZFS 寫入動作會被分成多個交易處理群組，並在交易處理群組被填滿時寫入磁碟 ("Transaction Group Commit")。然而像 man:fsync[2] 這樣的系統呼叫，會要求該系統呼叫在返回前，能承諾已將資料寫入磁碟，ZIL 就是用來紀錄確認為已執行寫入的資料，但其實尚未存在於磁碟上，即尚未完成交易處理，交易處理群組具有時間戳記，在系統當機後，找到 ZIL 最後一個有效的時間戳記，即將遺失的資料再舍併至磁碟上。 === 我需要用固態硬碟 (SSD) 來存 ZIL 嗎？ ZFS 預設將 ZIL 儲存在包含所有資料的 zpool 中，如果應用程式的寫入負載很重，將 ZIL 儲存在同步速度非常快的獨立設備中，藉由循序寫入效能的提高可以改善整個系統的效能，對於其他類型的工作負載， 固態硬碟就不會有太大的助益。 === L2ARC 是什麼？ The L2ARC (Second Level Adaptive Replacement Cache) 是存於快速儲存設備 SSD 上的讀取快取，此快取在重新開機後會消失，請注意記憶體是第一層的快取，只有在記憶體不足的情況下才需要 L2ARC。 L2ARC 需要 ARC 的空間來為其製作索引，因此，有一種反常的情況，如果有一種工作集 (working set) 可以完美地剛好放入 ARC，一旦系統使用 L2ARC，該工作集的運作將不再完美，因為 ARC 需要用一部分空間來保存 L2ARC 的索引，以至於必須將工作集的一部分存入比記憶體慢的 L2ARC。 === 建議啟用去冗餘 (deduplication) 嗎？ 一般而言，不建議這麼做。 去冗餘需要相當多的記憶體，而且會讓讀寫磁碟所需的時間變長，除非磁碟上儲存了非常多重複的資料，例如：虛擬機的映像檔或者是使用者的備份資料，否則開啟去冗餘可能弊大於利。另一個需要考量的狀況是：啟用去冗餘功能之後再將其關閉，無法將磁碟上去冗餘的狀態立即逆轉，必須等到下次修改了之前被去冗餘的資料，變更的區塊才會再被複製一份。 去冗餘也可能會導致某些非預期的情況，特別是刪除檔案時可能會慢很多。 === 在我建立的 ZFS pool 中無法刪除和新增檔案，應該怎麼修復？ 這很有可能是該 pool 的空間使用率已達 100% 滿了，因 ZFS 需要儲存空間以將紀錄交易處理的輔助資料 (metadata) 寫入，為了讓該 pool 回復至可用狀態，必須用檔案切除的方法 (truncate 命令) 刪除不重要的檔案： [source,shell] .... % truncate -s 0 unimportant-file .... 因為檔案切除不需要建立交易處理紀錄，並能釋放出可使用的磁碟區塊。 [NOTE] ==== 如果系統曾進行過額外的 ZFS dataset 調校，例如：去冗餘，釋放出來的空間也許不會立即可得。 ==== === ZFS 支援固態硬碟 (SSD) 的 TRIM 功能嗎？ 自 FreeBSD 10-CURRENT 修定 rlink:https://svnweb.freebsd.org/changeset/base/240868[r240868] 開始，就支援 ZFS TRIM。ZFS TRIM 的支援分別已在 rlink:https://svnweb.freebsd.org/changeset/base/252162[r252162] 和 rlink:https://svnweb.freebsd.org/changeset/base/251419[r251419] 的修訂，加進所有 FreeBSD-STABLE 分支。 ZFS TRIM 預設就已開啟，也可以將其關閉，只要加入一行設定到 [.filename]#/etc/sysctl.conf#: [.programlisting] .... vfs.zfs.trim.enabled=0 .... [NOTE] ==== ZFS TRIM 也可能某些設定中會無效，例如：在採用 GELI 裝置上的 ZFS 檔案系統。 ==== == System Administration === Where are the system start-up configuration files? The primary configuration file is [.filename]#/etc/defaults/rc.conf# which is described in man:rc.conf[5]. System startup scripts such as [.filename]#/etc/rc# and [.filename]#/etc/rc.d#, which are described in man:rc[8], include this file. _Do not edit this file!_ Instead, to edit an entry in [.filename]#/etc/defaults/rc.conf#, copy the line into [.filename]#/etc/rc.conf# and change it there. For example, if to start man:named[8], the included DNS server: [source,shell] .... # echo 'named_enable="YES"' >> /etc/rc.conf .... To start up local services, place shell scripts in the [.filename]#/usr/local/etc/rc.d# directory. These shell scripts should be set executable, the default file mode is `555`. === How do I add a user easily? Use the man:adduser[8] command, or the man:pw[8] command for more complicated situations. To remove the user, use the man:rmuser[8] command or, if necessary, man:pw[8]. === Why do I keep getting messages like root: not found after editing /etc/crontab? This is normally caused by editing the system crontab. This is not the correct way to do things as the system crontab has a different format to the per-user crontabs. The system crontab has an extra field, specifying which user to run the command as. man:cron[8] assumes this user is the first word of the command to execute. Since no such command exists, this error message is displayed. To delete the extra, incorrect crontab: [source,shell] .... # crontab -r .... === Why do I get the error, you are not in the correct group to su root when I try to su to root? This is a security feature. In order to `su` to `root`, or any other account with superuser privileges, the user account must be a member of the `wheel` group. If this feature were not there, anybody with an account on a system who also found out ``root``'s password would be able to gain superuser level access to the system. To allow someone to `su` to `root`, put them in the `wheel` group using `pw`: [source,shell] .... # pw groupmod wheel -m lisa .... The above example will add user `lisa` to the group `wheel`. === I made a mistake in rc.conf, or another startup file, and now I cannot edit it because the file system is read-only. What should I do? Restart the system using `boot -s` at the loader prompt to enter single-user mode. When prompted for a shell pathname, press kbd:[Enter] and run `mount -urw /` to re-mount the root file system in read/write mode. You may also need to run `mount -a -t ufs` to mount the file system where your favorite editor is defined. If that editor is on a network file system, either configure the network manually before mounting the network file systems, or use an editor which resides on a local file system, such as man:ed[1]. In order to use a full screen editor such as man:vi[1] or man:emacs[1], run `export TERM=xterm` so that these editors can load the correct data from the man:termcap[5] database. After performing these steps, edit [.filename]#/etc/rc.conf# to fix the syntax error. The error message displayed immediately after the kernel boot messages should indicate the number of the line in the file which is at fault. === Why am I having trouble setting up my printer? See the extref:{handbook}printing[Handbook entry on printing, printing] for troubleshooting tips. === How can I correct the keyboard mappings for my system? Refer to the Handbook section on extref:{handbook}l10n[using localization, using-localization], specifically the section on extref:{handbook}l10n[console setup, setting-console]. === Why can I not get user quotas to work properly? . It is possible that the kernel is not configured to use quotas. In this case, add the following line to the kernel configuration file and recompile the kernel: + [.programlisting] .... options QUOTA .... + Refer to theextref:{handbook}disks[Handbook entry on quotas, quotas] for full details. . Do not turn on quotas on [.filename]#/#. . Put the quota file on the file system that the quotas are to be enforced on: + [.informaltable] [cols="1,1", frame="none", options="header"] |=== | File System | Quota file |[.filename]#/usr# |[.filename]#/usr/admin/quotas# |[.filename]#/home# |[.filename]#/home/admin/quotas# |... |... |=== === Does FreeBSD support System V IPC primitives? Yes, FreeBSD supports System V-style IPC, including shared memory, messages and semaphores, in the [.filename]#GENERIC# kernel. With a custom kernel, support may be loaded with the [.filename]#sysvshm.ko#, [.filename]#sysvsem.ko# and [.filename]#sysvmsg.ko# kernel modules, or enabled in the custom kernel by adding the following lines to the kernel configuration file: [.programlisting] .... options SYSVSHM # enable shared memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging .... Recompile and install the kernel. === What other mail-server software can I use instead of Sendmail? The http://www.sendmail.org/[Sendmail] server is the default mail-server software for FreeBSD, but it can be replaced with another MTA installed from the Ports Collection. Available ports include package:mail/exim[], package:mail/postfix[], and package:mail/qmail[]. Search the mailing lists for discussions regarding the advantages and disadvantages of the available MTAs. === I have forgotten the root password! What do I do? Do not panic! Restart the system, type `boot -s` at the `Boot:` prompt to enter single-user mode. At the question about the shell to use, hit kbd:[Enter] which will display a `#` prompt. Enter `mount -urw /` to remount the root file system read/write, then run `mount -a` to remount all the file systems. Run `passwd root` to change the `root` password then run man:exit[1] to continue booting. [NOTE] ==== If you are still prompted to give the `root` password when entering the single-user mode, it means that the console has been marked as `insecure` in [.filename]#/etc/ttys#. In this case, it will be required to boot from a FreeBSD installation disk, choose the [.guimenuitem]#Live CD# or [.guimenuitem]#Shell# at the beginning of the install process and issue the commands mentioned above. Mount the specific partition in this case and then chroot to it. For example, replace `mount -urw /` with `mount /dev/ada0p1 /mnt; chroot /mnt` for a system on _ada0p1_. ==== [NOTE] ==== If the root partition cannot be mounted from single-user mode, it is possible that the partitions are encrypted and it is impossible to mount them without the access keys. For more information see the section about encrypted disks in the FreeBSD extref:{handbook}disks[Handbook, disks-encrypting]. ==== === How do I keep ControlAltDelete from rebooting the system? When using man:syscons[4], the default console driver, build and install a new kernel with this line in the configuration file: [.programlisting] .... options SC_DISABLE_REBOOT .... This can also be done by setting the following man:sysctl[8] which does not require a reboot or kernel recompile: [source,shell] .... # sysctl hw.syscons.kbd_reboot=0 .... [NOTE] ==== The above two methods are exclusive: The man:sysctl[8] does not exist if the kernel is compiled with `SC_DISABLE_REBOOT`. ==== === How do I reformat DOS text files to UNIX ones? Use this man:perl[1] command: [source,shell] .... % perl -i.bak -npe 's/\r\n/\n/g' file(s) .... where _file(s)_ is one or more files to process. The modification is done in-place, with the original file stored with a [.filename]#.bak# extension. Alternatively, use man:tr[1]: [source,shell] .... % tr -d '\r' < dos-text-file > unix-file .... _dos-text-file_ is the file containing DOS text while _unix-file_ will contain the converted output. This can be quite a bit faster than using `perl`. Yet another way to reformat DOS text files is to use the package:converters/dosunix[] port from the Ports Collection. Consult its documentation about the details. === How do I re-read /etc/rc.conf and re-start /etc/rc without a reboot? Go into single-user mode and then back to multi-user mode: [source,shell] .... # shutdown now # return # exit .... === I tried to update my system to the latest -STABLE, but got -BETAx, -RC or -PRERELEASE! What is going on? Short answer: it is just a name. _RC_ stands for "Release Candidate". It signifies that a release is imminent. In FreeBSD, _-PRERELEASE_ is typically synonymous with the code freeze before a release. (For some releases, the _-BETA_ label was used in the same way as _-PRERELEASE_.) Long answer: FreeBSD derives its releases from one of two places. Major, dot-zero, releases, such as 9.0-RELEASE are branched from the head of the development stream, commonly referred to as <>. Minor releases, such as 6.3-RELEASE or 5.2-RELEASE, have been snapshots of the active <> branch. Starting with 4.3-RELEASE, each release also now has its own branch which can be tracked by people requiring an extremely conservative rate of development (typically only security advisories). When a release is about to be made, the branch from which it will be derived from has to undergo a certain process. Part of this process is a code freeze. When a code freeze is initiated, the name of the branch is changed to reflect that it is about to become a release. For example, if the branch used to be called 6.2-STABLE, its name will be changed to 6.3-PRERELEASE to signify the code freeze and signify that extra pre-release testing should be happening. Bug fixes can still be committed to be part of the release. When the source code is in shape for the release the name will be changed to 6.3-RC to signify that a release is about to be made from it. Once in the RC stage, only the most critical bugs found can be fixed. Once the release (6.3-RELEASE in this example) and release branch have been made, the branch will be renamed to 6.3-STABLE. For more information on version numbers and the various Subversion branches, refer to the extref:{releng}[Release Engineering] article. === I tried to install a new kernel, and the chflags1 failed. How do I get around this? Short answer: the security level is greater than 0. Reboot directly to single-user mode to install the kernel. Long answer: FreeBSD disallows changing system flags at security levels greater than 0. To check the current security level: [source,shell] .... # sysctl kern.securelevel .... The security level cannot be lowered in multi-user mode, so boot to single-user mode to install the kernel, or change the security level in [.filename]#/etc/rc.conf# then reboot. See the man:init[8] manual page for details on `securelevel`, and see [.filename]#/etc/defaults/rc.conf# and the man:rc.conf[5] manual page for more information on [.filename]#rc.conf#. === I cannot change the time on my system by more than one second! How do I get around this? Short answer: the system is at a security level greater than 1. Reboot directly to single-user mode to change the date. Long answer: FreeBSD disallows changing the time by more that one second at security levels greater than 1. To check the security level: [source,shell] .... # sysctl kern.securelevel .... The security level cannot be lowered in multi-user mode. Either boot to single-user mode to change the date or change the security level in [.filename]#/etc/rc.conf# and reboot. See the man:init[8] manual page for details on `securelevel`, and see [.filename]#/etc/defaults/rc.conf# and the man:rc.conf[5] manual page for more information on [.filename]#rc.conf#. === Why is rpc.statd using 256 MB of memory? No, there is no memory leak, and it is not using 256 MB of memory. For convenience, `rpc.statd` maps an obscene amount of memory into its address space. There is nothing terribly wrong with this from a technical standpoint; it just throws off things like man:top[1] and man:ps[1]. man:rpc.statd[8] maps its status file (resident on [.filename]#/var#) into its address space; to save worrying about remapping the status file later when it needs to grow, it maps the status file with a generous size. This is very evident from the source code, where one can see that the length argument to man:mmap[2] is `0x10000000`, or one sixteenth of the address space on an IA32, or exactly 256 MB. === Why can I not unset the schg file flag? The system is running at securelevel greater than 0. Lower the securelevel and try again. For more information, see <> and the man:init[8] manual page. === What is vnlru? `vnlru` flushes and frees vnodes when the system hits the `kern.maxvnodes` limit. This kernel thread sits mostly idle, and only activates when there is a huge amount of RAM and users are accessing tens of thousands of tiny files. === What do the various memory states displayed by top mean? * `Active`: pages recently statistically used. * `Inactive`: pages recently statistically unused. * `Cache`: (most often) pages that have percolated from inactive to a status where they maintain their data, but can often be immediately reused (either with their old association, or reused with a new association). There can be certain immediate transitions from `active` to `cache` state if the page is known to be clean (unmodified), but that transition is a matter of policy, depending upon the algorithm choice of the VM system maintainer. * `Free`: pages without data content, and can be immediately used in certain circumstances where cache pages might be ineligible. Free pages can be reused at interrupt or process state. * `Wired`: pages that are fixed into memory, usually for kernel purposes, but also sometimes for special use in processes. Pages are most often written to disk (sort of a VM sync) when they are in the inactive state, but active pages can also be synced. This depends upon the CPU tracking of the modified bit being available, and in certain situations there can be an advantage for a block of VM pages to be synced, whether they are active or inactive. In most common cases, it is best to think of the inactive queue to be a queue of relatively unused pages that might or might not be in the process of being written to disk. Cached pages are already synced, not mapped, but available for immediate process use with their old association or with a new association. Free pages are available at interrupt level, but cached or free pages can be used at process state for reuse. Cache pages are not adequately locked to be available at interrupt level. There are some other flags (e.g., busy flag or busy count) that might modify some of the described rules. === How much free memory is available? There are a couple of kinds of "free memory". One kind is the amount of memory immediately available without paging anything else out. That is approximately the size of cache queue + size of free queue (with a derating factor, depending upon system tuning). Another kind of "free memory" is the total amount of VM space. That can be complex, but is dependent upon the amount of swap space and memory. Other kinds of "free memory" descriptions are also possible, but it is relatively useless to define these, but rather it is important to make sure that the paging rate is kept low, and to avoid running out of swap space. === What is /var/empty? [.filename]#/var/empty# is a directory that the man:sshd[8] program uses when performing privilege separation. The [.filename]#/var/empty# directory is empty, owned by `root` and has the `schg` flag set. This directory should not be deleted. === I just changed /etc/newsyslog.conf. How can I check if it does what I expect? To see what man:newsyslog[8] will do, use the following: [source,shell] .... % newsyslog -nrvv .... === My time is wrong, how can I change the timezone? Use man:tzsetup[8]. == The X Window System and Virtual Consoles === What is the X Window System? The X Window System (commonly `X11`) is the most widely available windowing system capable of running on UNIX(TM) or UNIX(TM) like systems, including FreeBSD. http://www.x.org/wiki/[The X.Org Foundation] administers the http://en.wikipedia.org/wiki/X_Window_System_core_protocol[X protocol standards], with the current reference implementation, version 11 release 7.7, so references are often shortened to `X11`. Many implementations are available for different architectures and operating systems. An implementation of the server-side code is properly known as an `X server`. === I want to run Xorg, how do I go about it? To install Xorg do one of the following: Use the package:x11/xorg[] meta-port, which builds and installs every Xorg component. Use package:x11/xorg-minimal[], which builds and installs only the necessary Xorg components. Install Xorg from FreeBSD packages: [source,shell] .... # pkg install xorg .... After the installation of Xorg, follow the instructions from the extref:{handbook}x11[X11 Configuration, x-config] section of the FreeBSD Handbook. === I tried to run X, but I get a No devices detected. error when I type startx. What do I do now? The system is probably running at a raised `securelevel`. It is not possible to start X at a raised `securelevel` because X requires write access to man:io[4]. For more information, see at the man:init[8] manual page. There are two solutions to the problem: set the `securelevel` back down to zero or run man:xdm[1] (or an alternative display manager) at boot time before the `securelevel` is raised. See <> for more information about running man:xdm[1] at boot time. === Why does my mouse not work with X? When using man:syscons[4], the default console driver, FreeBSD can be configured to support a mouse pointer on each virtual screen. To avoid conflicting with X, man:syscons[4] supports a virtual device called [.filename]#/dev/sysmouse#. All mouse events received from the real mouse device are written to the man:sysmouse[4] device via man:moused[8]. To use the mouse on one or more virtual consoles, _and_ use X, see <> and set up man:moused[8]. Then edit [.filename]#/etc/X11/xorg.conf# and make sure the following lines exist: [.programlisting] .... Section "InputDevice" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" ..... .... Starting with Xorg version 7.4, the `InputDevice` sections in [.filename]#xorg.conf# are ignored in favor of autodetected devices. To restore the old behavior, add the following line to the `ServerLayout` or `ServerFlags` section: [.programlisting] .... Option "AutoAddDevices" "false" .... Some people prefer to use [.filename]#/dev/mouse# under X. To make this work, [.filename]#/dev/mouse# should be linked to [.filename]#/dev/sysmouse# (see man:sysmouse[4]) by adding the following line to [.filename]#/etc/devfs.conf# (see man:devfs.conf[5]): [.programlisting] .... link sysmouse mouse .... This link can be created by restarting man:devfs[5] with the following command (as `root`): [source,shell] .... # service devfs restart .... === My mouse has a fancy wheel. Can I use it in X? Yes, if X is configured for a 5 button mouse. To do this, add the lines `Buttons 5` and `ZAxisMapping 4 5` to the "InputDevice" section of [.filename]#/etc/X11/xorg.conf#, as seen in this example: [.programlisting] .... Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection .... The mouse can be enabled in Emacsby adding these lines to [.filename]#~/.emacs#: [.programlisting] .... ;; wheel mouse (global-set-key [mouse-4] 'scroll-down) (global-set-key [mouse-5] 'scroll-up) .... === My laptop has a Synaptics touchpad. Can I use it in X? Yes, after configuring a few things to make it work. In order to use the Xorg synaptics driver, first remove `moused_enable` from [.filename]#rc.conf#. To enable synaptics, add the following line to [.filename]#/boot/loader.conf#: [.programlisting] .... hw.psm.synaptics_support="1" .... Add the following to [.filename]#/etc/X11/xorg.conf#: [.programlisting] .... Section "InputDevice" Identifier "Touchpad0" Driver "synaptics" Option "Protocol" "psm" Option "Device" "/dev/psm0" EndSection .... And be sure to add the following into the "ServerLayout" section: [.programlisting] .... InputDevice "Touchpad0" "SendCoreEvents" .... === How do I use remote X displays? For security reasons, the default setting is to not allow a machine to remotely open a window. To enable this feature, start X with the optional `-listen_tcp` argument: [source,shell] .... % startx -listen_tcp .... === What is a virtual console and how do I make more? Virtual consoles provide several simultaneous sessions on the same machine without doing anything complicated like setting up a network or running X. When the system starts, it will display a login prompt on the monitor after displaying all the boot messages. Type in your login name and password to start working on the first virtual console. To start another session, perhaps to look at documentation for a program or to read mail while waiting for an FTP transfer to finish, hold down kbd:[Alt] and press kbd:[F2]. This will display the login prompt for the second virtual console. To go back to the original session, press kbd:[Alt+F1]. The default FreeBSD installation has eight virtual consoles enabled. kbd:[Alt+F1], kbd:[Alt+F2], kbd:[Alt+F3], and so on will switch between these virtual consoles. To enable more of virtual consoles, edit [.filename]#/etc/ttys# (see man:ttys[5]) and add entries for [.filename]#ttyv8# to [.filename]#ttyvc#, after the comment on "Virtual terminals": [.programlisting] .... # Edit the existing entry for ttyv8 in /etc/ttys and change # "off" to "on". ttyv8 "/usr/libexec/getty Pc" xterm on secure ttyv9 "/usr/libexec/getty Pc" xterm on secure ttyva "/usr/libexec/getty Pc" xterm on secure ttyvb "/usr/libexec/getty Pc" xterm on secure .... The more virtual terminals, the more resources that are used. This can be problematic on systems with 8 MB RAM or less. Consider changing `secure` to `insecure`. [IMPORTANT] ==== In order to run an X server, at least one virtual terminal must be left to `off` for it to use. This means that only eleven of the Alt-function keys can be used as virtual consoles so that one is left for the X server. ==== For example, to run X and eleven virtual consoles, the setting for virtual terminal 12 should be: [.programlisting] .... ttyvb "/usr/libexec/getty Pc" xterm off secure .... The easiest way to activate the virtual consoles is to reboot. === How do I access the virtual consoles from X? Use kbd:[Ctrl+Alt+Fn] to switch back to a virtual console. Press kbd:[Ctrl+Alt+F1] to return to the first virtual console. Once at a text console, use kbd:[Alt+Fn] to move between them. To return to the X session, switch to the virtual console running X. If X was started from the command line using `startx`, the X session will attach to the next unused virtual console, not the text console from which it was invoked. For eight active virtual terminals, X will run on the ninth, so use kbd:[Alt+F9]. [[xdm-boot]] === How do I start XDM on boot? There are two schools of thought on how to start man:xdm[1]. One school starts `xdm` from [.filename]#/etc/ttys# (see man:ttys[5]) using the supplied example, while the other runs `xdm` from [.filename]#rc.local# (see man:rc[8]) or from an [.filename]#X# script in [.filename]#/usr/local/etc/rc.d#. Both are equally valid, and one may work in situations where the other does not. In both cases the result is the same: X will pop up a graphical login prompt. The man:ttys[5] method has the advantage of documenting which vty X will start on and passing the responsibility of restarting the X server on logout to man:init[8]. The man:rc[8] method makes it easy to `kill xdm` if there is a problem starting the X server. If loaded from man:rc[8], `xdm` should be started without any arguments. `xdm` must start _after_ man:getty[8] runs, or else `getty` and `xdm` will conflict, locking out the console. The best way around this is to have the script sleep 10 seconds or so then launch `xdm`. When starting `xdm` from [.filename]#/etc/ttys#, there still is a chance of conflict between `xdm` and man:getty[8]. One way to avoid this is to add the `vt` number in [.filename]#/usr/local/lib/X11/xdm/Xservers#: [.programlisting] .... :0 local /usr/local/bin/X vt4 .... The above example will direct the X server to run in [.filename]#/dev/ttyv3#. Note the number is offset by one. The X server counts the vty from one, whereas the FreeBSD kernel numbers the vty from zero. === Why do I get Couldn't open console when I run xconsole? When X is started with `startx`, the permissions on [.filename]#/dev/console# will _not_ get changed, resulting in things like `xterm -C` and `xconsole` not working. This is because of the way console permissions are set by default. On a multi-user system, one does not necessarily want just any user to be able to write on the system console. For users who are logging directly onto a machine with a VTY, the man:fbtab[5] file exists to solve such problems. In a nutshell, make sure an uncommented line of the form is in [.filename]#/etc/fbtab# (see man:fbtab[5]): [.programlisting] .... /dev/ttyv0 0600 /dev/console .... It will ensure that whomever logs in on [.filename]#/dev/ttyv0# will own the console. === Why does my PS/2 mouse misbehave under X? The mouse and the mouse driver may have become out of synchronization. In rare cases, the driver may also erroneously report synchronization errors: [.programlisting] .... psmintr: out of sync (xxxx != yyyy) .... If this happens, disable the synchronization check code by setting the driver flags for the PS/2 mouse driver to `0x100`. This can be easiest achieved by adding `hint.psm.0.flags="0x100"` to [.filename]#/boot/loader.conf# and rebooting. === How do I reverse the mouse buttons? Type `xmodmap -e "pointer = 3 2 1"`. Add this command to [.filename]#~/.xinitrc# or [.filename]#~/.xsession# to make it happen automatically. === How do I install a splash screen and where do I find them? The detailed answer for this question can be found in the extref:{handbook}boot[Boot Time Splash Screens, boot-splash] section of the FreeBSD Handbook. === Can I use the Windows keys on my keyboard in X? Yes. Use man:xmodmap[1] to define which functions the keys should perform. Assuming all Windows keyboards are standard, the keycodes for these three keys are the following: * 115 -- kbd:[Windows] key, between the left-hand kbd:[Ctrl] and kbd:[Alt] keys * 116 -- kbd:[Windows] key, to the right of kbd:[AltGr] * 117 -- kbd:[Menu], to the left of the right-hand kbd:[Ctrl] To have the left kbd:[Windows] key print a comma, try this. [source,shell] .... # xmodmap -e "keycode 115 = comma" .... To have the kbd:[Windows] key-mappings enabled automatically every time X is started, either put the `xmodmap` commands in [.filename]#~/.xinitrc# or, preferably, create a [.filename]#~/.xmodmaprc# and include the `xmodmap` options, one per line, then add the following line to [.filename]#~/.xinitrc#: [.programlisting] .... xmodmap $HOME/.xmodmaprc .... For example, to map the 3 keys to be kbd:[F13], kbd:[F14], and kbd:[F15], respectively. This would make it easy to map them to useful functions within applications or the window manager. To do this, put the following in [.filename]#~/.xmodmaprc#. [.programlisting] .... keycode 115 = F13 keycode 116 = F14 keycode 117 = F15 .... For the package:x11-wm/fvwm2[] desktop manager, one could map the keys so that kbd:[F13] iconifies or de-iconifies the window the cursor is in, kbd:[F14] brings the window the cursor is in to the front or, if it is already at the front, pushes it to the back, and kbd:[F15] pops up the main Workplace menu even if the cursor is not on the desktop, which is useful when no part of the desktop is visible. The following entries in [.filename]#~/.fvwmrc# implement the aforementioned setup: [.programlisting] .... Key F13 FTIWS A Iconify Key F14 FTIWS A RaiseLower Key F15 A A Menu Workplace Nop .... === How can I get 3D hardware acceleration for OpenGL? The availability of 3D acceleration depends on the version of Xorg and the type of video chip. For an nVidia chip, use the binary drivers provided for FreeBSD by installing one of the following ports: The latest versions of nVidia cards are supported by the package:x11/nvidia-driver[] port. Older drivers are available as package:x11/nvidia-driver-###[] nVidia provides detailed information on which card is supported by which driver on their web site: http://www.nvidia.com/object/IO_32667.html[http://www.nvidia.com/object/IO_32667.html]. For Matrox G200/G400, check the package:x11-drivers/xf86-video-mga[] port. For ATI Rage 128 and Radeon see man:ati[4], man:r128[4] and man:radeon[4]. == Networking === Where can I get information on diskless booting? "Diskless booting" means that the FreeBSD box is booted over a network, and reads the necessary files from a server instead of its hard disk. For full details, see extref:{handbook}advanced-networking[the Handbook entry on diskless booting, network-diskless]. === Can a FreeBSD box be used as a dedicated network router? Yes. Refer to the Handbook entry on extref:{handbook}advanced-networking[advanced networking, advanced-networking], specifically the section on extref:{handbook}advanced-networking[routing and gateways, network-routing]. === Can I connect my Windows box to the Internet via FreeBSD? Typically, people who ask this question have two PCs at home, one with FreeBSD and one with some version of Windows(TM) the idea is to use the FreeBSD box to connect to the Internet and then be able to access the Internet from the Windows(TM) box through the FreeBSD box. This is really just a special case of the previous question and works perfectly well. Dialup users must use `-nat` and set `gateway_enable` to _YES_ in [.filename]#/etc/rc.conf#. For more information, refer to man:ppp[8] or the extref:{handbook}ppp-and-slip[Handbook entry on user PPP, userppp]. If the connection to the Internet is over Ethernet, use man:natd[8]. A tutorial can be found in the extref:{handbook}[natd, network-natd] section of the Handbook. === Does FreeBSD support PPP? Yes. man:ppp[8] provides support for both incoming and outgoing connections. For more information on how to use this, refer to the extref:{handbook}ppp-and-slip/[Handbook chapter on PPP, ppp-and-slip]. === Does FreeBSD support NAT or Masquerading? Yes. For instructions on how to use NAT over a PPP connection, see the extref:{handbook}ppp-and-slip[Handbook entry on PPP, userppp]. To use NAT over some other sort of network connection, look at the extref:{handbook}[natd, network-natd] section of the Handbook. === How can I set up Ethernet aliases? If the alias is on the same subnet as an address already configured on the interface, add `netmask 0xffffffff` to this command: [source,shell] .... # ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff .... Otherwise, specify the network address and netmask as usual: [source,shell] .... # ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00 .... More information can be found in the FreeBSD extref:{handbook}config-tuning/[Handbook, configtuning-virtual-hosts]. === Why can I not NFS-mount from a Linux box? Some versions of the Linux(TM) NFS code only accept mount requests from a privileged port; try to issue the following command: [source,shell] .... # mount -o -P linuxbox:/blah /mnt .... === Why does mountd keep telling me it can't change attributes and that I have a bad exports list on my FreeBSD NFS server? The most frequent problem is not understanding the correct format of [.filename]#/etc/exports#. Review man:exports[5] and the extref:{handbook}network-servers/[NFS, network-nfs] entry in the Handbook, especially the section on extref:{handbook}[configuring NFS, configuring-nfs]. === How do I enable IP multicast support? Install the package:net/mrouted[] package or port and add `mrouted_enable="YES"` to [.filename]#/etc/rc.conf# start this service at boot time. === Why do I have to use the FQDN for hosts on my site? See the answer in the FreeBSD extref:{handbook}mail[Handbook, mail-trouble]. === Why do I get an error, Permission denied, for all networking operations? If the kernel is compiled with the `IPFIREWALL` option, be aware that the default policy is to deny all packets that are not explicitly allowed. If the firewall is unintentionally misconfigured, restore network operability by typing the following as `root`: [source,shell] .... # ipfw add 65534 allow all from any to any .... Consider setting `firewall_type="open"` in [.filename]#/etc/rc.conf#. For further information on configuring this firewall, see the extref:{handbook}firewalls[Handbook chapter, firewalls-ipfw]. === Why is my ipfw fwd rule to redirect a service to another machine not working? Possibly because network address translation (NAT) is needed instead of just forwarding packets. A "fwd" rule only forwards packets, it does not actually change the data inside the packet. Consider this rule: [source,shell] .... 01000 fwd 10.0.0.1 from any to foo 21 .... When a packet with a destination address of _foo_ arrives at the machine with this rule, the packet is forwarded to _10.0.0.1_, but it still has the destination address of _foo_. The destination address of the packet is not changed to _10.0.0.1_. Most machines would probably drop a packet that they receive with a destination address that is not their own. Therefore, using a "fwd" rule does not often work the way the user expects. This behavior is a feature and not a bug. See the <>, the man:natd[8] manual, or one of the several port redirecting utilities in the https://www.FreeBSD.org/ports/[Ports Collection] for a correct way to do this. === How can I redirect service requests from one machine to another? FTP and other service requests can be redirected with the package:sysutils/socket[] package or port. Replace the entry for the service in [.filename]#/etc/inetd.conf# to call `socket`, as seen in this example for ftpd: [.programlisting] .... ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp .... where _ftp.example.com_ and _ftp_ are the host and port to redirect to, respectively. === Where can I get a bandwidth management tool? There are three bandwidth management tools available for FreeBSD. man:dummynet[4] is integrated into FreeBSD as part of man:ipfw[4]. http://www.sonycsl.co.jp/person/kjc/programs.html[ALTQ] has been integrated into FreeBSD as part of man:pf[4]. Bandwidth Manager from http://www.etinc.com/[Emerging Technologies] is a commercial product. === Why do I get /dev/bpf0: device not configured? The running application requires the Berkeley Packet Filter (man:bpf[4]), but it was removed from a custom kernel. Add this to the kernel config file and build a new kernel: [.programlisting] .... device bpf # Berkeley Packet Filter .... === How do I mount a disk from a Windows machine that is on my network, like smbmount in Linux? Use the SMBFS toolset. It includes a set of kernel modifications and a set of userland programs. The programs and information are available as man:mount_smbfs[8] in the base system. === What are these messages about: Limiting icmp/open port/closed port response in my log files? This kernel message indicates that some activity is provoking it to send a large amount of ICMP or TCP reset (RST) responses. ICMP responses are often generated as a result of attempted connections to unused UDP ports. TCP resets are generated as a result of attempted connections to unopened TCP ports. Among others, these are the kinds of activities which may cause these messages: * Brute-force denial of service (DoS) attacks (as opposed to single-packet attacks which exploit a specific vulnerability). * Port scans which attempt to connect to a large number of ports (as opposed to only trying a few well-known ports). The first number in the message indicates how many packets the kernel would have sent if the limit was not in place, and the second indicates the limit. This limit is controlled using `net.inet.icmp.icmplim`. This example sets the limit to `300` packets per second: [source,shell] .... # sysctl net.inet.icmp.icmplim=300 .... To disable these messages without disabling response limiting, use `net.inet.icmp.icmplim_output` to disable the output: [source,shell] .... # sysctl net.inet.icmp.icmplim_output=0 .... Finally, to disable response limiting completely, set `net.inet.icmp.icmplim` to `0`. Disabling response limiting is discouraged for the reasons listed above. === What are these arp: unknown hardware address format error messages? This means that some device on the local Ethernet is using a MAC address in a format that FreeBSD does not recognize. This is probably caused by someone experimenting with an Ethernet card somewhere else on the network. This is most commonly seen on cable modem networks. It is harmless, and should not affect the performance of the FreeBSD system. === Why do I keep seeing messages like: 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0, and how do I disable it? Because a packet is coming from outside the network unexpectedly. To disable them, set `net.link.ether.inet.log_arp_wrong_iface` to `0`. === How do I compile an IPv6 only kernel? Configure your kernel with these settings: [source,shell] .... include GENERIC ident GENERIC-IPV6ONLY makeoptions MKMODULESENV+="WITHOUT_INET_SUPPORT=" nooptions INET nodevice gre .... == Security === What is a sandbox? "Sandbox" is a security term. It can mean two things: * A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system. + The process is only able to run inside the walls. Since nothing the process does in regards to executing code is supposed to be able to breach the walls, a detailed audit of its code is not needed in order to be able to say certain things about its security. + The walls might be a user ID, for example. This is the definition used in the man:security[7] and man:named[8] man pages. + Take the `ntalk` service, for example (see man:inetd[8]). This service used to run as user ID `root`. Now it runs as user ID `tty`. The `tty` user is a sandbox designed to make it more difficult for someone who has successfully hacked into the system via `ntalk` from being able to hack beyond that user ID. * A process which is placed inside a simulation of the machine. It means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data. + The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chrooted so that [.filename]#/# for that process is this directory, not the real [.filename]#/# of the system). + Another common use is to mount an underlying file system read-only and then create a file system layer on top of it that gives a process a seemingly writeable view into that file system. The process may believe it is able to write to those files, but only the process sees the effects -- other processes in the system do not, necessarily. + An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it. UNIX(TM) implements two core sandboxes. One is at the process level, and one is at the userid level. Every UNIX(TM) process is completely firewalled off from every other UNIX(TM) process. One process cannot modify the address space of another. A UNIX(TM) process is owned by a particular userid. If the user ID is not the `root` user, it serves to firewall the process off from processes owned by other users. The user ID is also used to firewall off on-disk data. === What is securelevel? `securelevel` is a security mechanism implemented in the kernel. When the securelevel is positive, the kernel restricts certain tasks; not even the superuser (`root`) is allowed to do them. The securelevel mechanism limits the ability to: * Unset certain file flags, such as `schg` (the system immutable flag). * Write to kernel memory via [.filename]#/dev/mem# and [.filename]#/dev/kmem#. * Load kernel modules. * Alter firewall rules. To check the status of the securelevel on a running system: [source,shell] .... # sysctl -n kern.securelevel .... The output contains the current value of the securelevel. If it is greater than 0, at least some of the securelevel's protections are enabled. The securelevel of a running system cannot be lowered as this would defeat its purpose. If a task requires that the securelevel be non-positive, change the `kern_securelevel` and `kern_securelevel_enable` variables in [.filename]#/etc/rc.conf# and reboot. For more information on securelevel and the specific things all the levels do, consult man:init[8]. [WARNING] ==== Securelevel is not a silver bullet; it has many known deficiencies. More often than not, it provides a false sense of security. One of its biggest problems is that in order for it to be at all effective, all files used in the boot process up until the securelevel is set must be protected. If an attacker can get the system to execute their code prior to the securelevel being set (which happens quite late in the boot process since some things the system must do at start-up cannot be done at an elevated securelevel), its protections are invalidated. While this task of protecting all files used in the boot process is not technically impossible, if it is achieved, system maintenance will become a nightmare since one would have to take the system down, at least to single-user mode, to modify a configuration file. This point and others are often discussed on the mailing lists, particularly the http://lists.FreeBSD.org/mailman/listinfo/freebsd-security[FreeBSD security mailing list]. Search the archives https://www.FreeBSD.org/search/[here] for an extensive discussion. A more fine-grained mechanism is preferred. ==== === BIND9 (named) is listening on some high-numbered ports. What is going on? BIND uses a random high-numbered port for outgoing queries. Recent versions of it choose a new, random UDP port for each query. This may cause problems for some network configurations, especially if a firewall blocks incoming UDP packets on particular ports. To get past that firewall, try the `avoid-v4-udp-ports` and `avoid-v6-udp-ports` options to avoid selecting random port numbers within a blocked range. [WARNING] ==== If a port number (like 53) is specified via the `query-source` or `query-source-v6` options in [.filename]#/usr/local/etc/namedb/named.conf#, randomized port selection will not be used. It is strongly recommended that these options not be used to specify fixed port numbers. ==== Congratulations, by the way. It is good practice to read man:sockstat[1] output and notice odd things! === The Sendmail daemon is listening on port 587 as well as the standard port 25! What is going on? Recent versions of Sendmail support a mail submission feature that runs over port 587. This is not yet widely supported, but is growing in popularity. === What is this UID 0 toor account? Have I been compromised? Do not worry. `toor` is an "alternative" superuser account, where toor is root spelled backwards. It is intended to be used with a non-standard shell so the default shell for `root` does not need to change. This is important as shells which are not part of the base distribution, but are instead installed from ports or packages, are installed in [.filename]#/usr/local/bin# which, by default, resides on a different file system. If ``root``'s shell is located in [.filename]#/usr/local/bin# and the file system containing [.filename]#/usr/local/bin#) is not mounted, `root` will not be able to log in to fix a problem and will have to reboot into single-user mode in order to enter the path to a shell. Some people use `toor` for day-to-day `root` tasks with a non-standard shell, leaving `root`, with a standard shell, for single-user mode or emergencies. By default, a user cannot log in using `toor` as it does not have a password, so log in as `root` and set a password for `toor` before using it to login. == PPP === I cannot make ppp8 work. What am I doing wrong? First, read man:ppp[8] and the extref:{handbook}ppp-and-slip[PPP section of the Handbook, userppp]. To assist in troubleshooting, enable logging with the following command: [.programlisting] .... set log Phase Chat Connect Carrier lcp ipcp ccp command .... This command may be typed at the man:ppp[8] command prompt or it may be entered at the start of the `default` section in [.filename]#/etc/ppp/ppp.conf#. Make sure that [.filename]#/etc/syslog.conf# contains the lines below and the file [.filename]#/var/log/ppp.log# exists: [.programlisting] .... !ppp *.* /var/log/ppp.log .... A lot about what is going can be learned from the log file. Do not worry if it does not all make sense as it may make sense to someone else. === Why does ppp8 hang when I run it? This is usually because the hostname will not resolve. The best way to fix this is to make sure that [.filename]#/etc/hosts# is read first by the by ensuring that the `hosts` line is listed first in [.filename]#/etc/host.conf#. Then, put an entry in [.filename]#/etc/hosts# for the local machine. If there is no local network, change the `localhost` line: [.programlisting] .... 127.0.0.1 foo.example.com foo localhost .... Otherwise, add another entry for the host. Consult the relevant manual pages for more details. When finished, verify that this command is successful: `ping -c1 hostname`. === Why will ppp8 not dial in -auto mode? First, check that a default route exists. This command should display two entries: [.programlisting] .... Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 .... If a default route is not listed, make sure that the `HISADDR` line has been added to [.filename]#/etc/ppp/ppp.conf#. Another reason for the default route line being missing is that a default route has been added to [.filename]#/etc/rc.conf# and this line is missing from [.filename]#/etc/ppp/ppp.conf#: [.programlisting] .... delete ALL .... If this is the case, go back to the extref:{handbook}ppp-and-slip[Final System Configuration, userppp-final] section of the Handbook. === What does No route to host mean? This error is usually because the following section is missing in [.filename]#/etc/ppp/ppp.linkup#: [.programlisting] .... MYADDR: delete ALL add 0 0 HISADDR .... This is only necessary for a dynamic IP address or when the address of the default gateway is unknown. When using interactive mode, the following can be typed in after entering packet mode. Packet mode is indicated by the capitalized PPP in the prompt: [.programlisting] .... delete ALL add 0 0 HISADDR .... Refer to the extref:{handbook}[PPP and Dynamic IP addresses, userppp-dynamicip] section of the Handbook for further details. === Why does my connection drop after about 3 minutes? The default PPP timeout is 3 minutes. This can be adjusted with the following line: [.programlisting] .... set timeout NNN .... where _NNN_ is the number of seconds of inactivity before the connection is closed. If _NNN_ is zero, the connection is never closed due to a timeout. It is possible to put this command in [.filename]#ppp.conf#, or to type it at the prompt in interactive mode. It is also possible to adjust it on the fly while the line is active by connecting to ppp's server socket using man:telnet[1] or man:pppctl[8]. Refer to the man:ppp[8] man page for further details. === Why does my connection drop under heavy load? If Link Quality Reporting (LQR) is configured, it is possible that too many LQR packets are lost between the FreeBSD system and the peer. man:ppp[8] deduces that the line must therefore be bad, and disconnects. LQR is disabled by default and can be enabled with the following line: [.programlisting] .... enable lqr .... === Why does my connection drop after a random amount of time? Sometimes, on a noisy phone line or even on a line with call waiting enabled, the modem may hang up because it incorrectly thinks that it lost carrier. There is a setting on most modems for determining how tolerant it should be to temporary losses of carrier. Refer to the modem manual for details. === Why does my connection hang after a random amount of time? Many people experience hung connections with no apparent explanation. The first thing to establish is which side of the link is hung. When using an external modem, try using man:ping[8] to see if the TD light is flashing when data is transmitted. If it flashes but the RD light does not, the problem is with the remote end. If TD does not flash, the problem is local. With an internal modem, use the `set server` command in [.filename]#ppp.conf#. When the hang occurs, connect to man:ppp[8] using man:pppctl[8]. If the network connection suddenly revives due to the activity on the diagnostic socket, or if it will not connect but the `set socket` command succeeded at startup time, the problem is local. If it can connect but things are still hung, enable local logging with `set log local async` and use man:ping[8] from another window or terminal to make use of the link. The async logging will show the data being transmitted and received on the link. If data is going out and not coming back, the problem is remote. Having established whether the problem is local or remote, there are now two possibilities: * If the problem is remote, read on entry <>. * If the problem is local, read on entry <>. [[ppp-remote-not-responding]] === The remote end is not responding. What can I do? There is very little that can be done about this. Many ISPs will refuse to help users not running a Microsoft(TM) OS. Add `enable lqr` to [.filename]#/etc/ppp/ppp.conf#, allowing man:ppp[8] to detect the remote failure and hang up. This detection is relatively slow and therefore not that useful. First, try disabling all local compression by adding the following to the configuration: [.programlisting] .... disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj .... Then reconnect to ensure that this makes no difference. If things improve or if the problem is solved completely, determine which setting makes the difference through trial and error. This is good information for the ISP, although it may make it apparent that it is not a Microsoft(TM) system. Before contacting the ISP, enable async logging locally and wait until the connection hangs again. This may use up quite a bit of disk space. The last data read from the port may be of interest. It is usually ASCII data, and may even describe the problem (`Memory fault`, `Core dumped`). If the ISP is helpful, they should be able to enable logging on their end, then when the next link drop occurs, they may be able to tell why their side is having a problem. [[ppp-hung]] === man:ppp[8] has hung. What can I do? In this case, rebuild man:ppp[8] with debugging information, and then use man:gdb[1] to grab a stack trace from the ppp process that is stuck. To rebuild the ppp utility with debugging information, type: [source,shell] .... # cd /usr/src/usr.sbin/ppp # env DEBUG_FLAGS='-g' make clean # env DEBUG_FLAGS='-g' make install .... Then, restart ppp and wait until it hangs again. When the debug build of ppp hangs, start gdb on the stuck process by typing: [source,shell] .... # gdb ppp `pgrep ppp` .... At the gdb prompt, use the `bt` or `where` commands to get a stack trace. Save the output of the gdb session, and "detach" from the running process by typing `quit`. === I keep seeing errors about magic being the same. What does it mean? Occasionally, just after connecting, there may be messages in the log that say `Magic is same`. Sometimes, these messages are harmless, and sometimes one side or the other exits. Most PPP implementations cannot survive this problem, and even if the link seems to come up, there will be repeated configure requests and configure acknowledgments in the log file until man:ppp[8] eventually gives up and closes the connection. This normally happens on server machines with slow disks that are spawning a man:getty[8] on the port, and executing man:ppp[8] from a login script or program after login. There were reports of it happening consistently when using slirp. The reason is that in the time taken between man:getty[8] exiting and man:ppp[8] starting, the client-side man:ppp[8] starts sending Line Control Protocol (LCP) packets. Because ECHO is still switched on for the port on the server, the client man:ppp[8] sees these packets "reflect" back. One part of the LCP negotiation is to establish a magic number for each side of the link so that "reflections" can be detected. The protocol says that when the peer tries to negotiate the same magic number, a NAK should be sent and a new magic number should be chosen. During the period that the server port has ECHO turned on, the client man:ppp[8] sends LCP packets, sees the same magic in the reflected packet and NAKs it. It also sees the NAK reflect (which also means man:ppp[8] must change its magic). This produces a potentially enormous number of magic number changes, all of which are happily piling into the server's tty buffer. As soon as man:ppp[8] starts on the server, it is flooded with magic number changes and almost immediately decides it has tried enough to negotiate LCP and gives up. Meanwhile, the client, who no longer sees the reflections, becomes happy just in time to see a hangup from the server. This can be avoided by allowing the peer to start negotiating with the following line in [.filename]#ppp.conf#: [.programlisting] .... set openmode passive .... This tells man:ppp[8] to wait for the server to initiate LCP negotiations. Some servers however may never initiate negotiations. In this case, try something like: [.programlisting] .... set openmode active 3 .... This tells man:ppp[8] to be passive for 3 seconds, and then to start sending LCP requests. If the peer starts sending requests during this period, man:ppp[8] will immediately respond rather than waiting for the full 3 second period. === LCP negotiations continue until the connection is closed. What is wrong? There is currently an implementation mis-feature in man:ppp[8] where it does not associate LCP, CCP & IPCP responses with their original requests. As a result, if one PPP implementation is more than 6 seconds slower than the other side, the other side will send two additional LCP configuration requests. This is fatal. Consider two implementations, `A` and `B`. `A` starts sending LCP requests immediately after connecting and `B` takes 7 seconds to start. When `B` starts, `A` has sent 3 LCP REQs. We are assuming the line has ECHO switched off, otherwise we would see magic number problems as described in the previous section. `B` sends a REQ, then an ACK to the first of `A`'s REQs. This results in `A` entering the OPENED state and sending and ACK (the first) back to `B`. In the meantime, `B` sends back two more ACKs in response to the two additional REQs sent by `A` before `B` started up. `B` then receives the first ACK from `A` and enters the OPENED state. `A` receives the second ACK from `B` and goes back to the REQ-SENT state, sending another (forth) REQ as per the RFC. It then receives the third ACK and enters the OPENED state. In the meantime, `B` receives the forth REQ from `A`, resulting in it reverting to the ACK-SENT state and sending another (second) REQ and (forth) ACK as per the RFC. `A` gets the REQ, goes into REQ-SENT and sends another REQ. It immediately receives the following ACK and enters OPENED. This goes on until one side figures out that they are getting nowhere and gives up. The best way to avoid this is to configure one side to be `passive` -- that is, make one side wait for the other to start negotiating. This can be done with the following command: [.programlisting] .... set openmode passive .... Care should be taken with this option. This command can also be used to limit the amount of time that man:ppp[8] waits for the peer to begin negotiations: [.programlisting] .... set stopped N .... Alternatively, the following command (where _N_ is the number of seconds to wait before starting negotiations) can be used: [.programlisting] .... set openmode active N .... Check the manual page for details. === Why does ppp8 lock up when I shell out to test it? When using `shell` or `!`, man:ppp[8] executes a shell or the passed arguments. The ppp program will wait for the command to complete before continuing. Any attempt to use the PPP link while running the command will appear as a frozen link. This is because man:ppp[8] is waiting for the command to complete. To execute commands like this, use `!bg` instead. This will execute the given command in the background, and man:ppp[8] can continue to service the link. === Why does ppp8 over a null-modem cable never exit? There is no way for man:ppp[8] to automatically determine that a direct connection has been dropped. This is due to the lines that are used in a null-modem serial cable. When using this sort of connection, LQR should always be enabled with the following line: [.programlisting] .... enable lqr .... LQR is accepted by default if negotiated by the peer. === Why does ppp8 dial for no reason in -auto mode? If man:ppp[8] is dialing unexpectedly, determine the cause, and set up dial filters to prevent such dialing. To determine the cause, use the following line: [.programlisting] .... set log +tcp/ip .... This will log all traffic through the connection. The next time the line comes up unexpectedly, the reason will be logged with a convenient timestamp next to it. Next, disable dialing under these circumstances. Usually, this sort of problem arises due to DNS lookups. To prevent DNS lookups from establishing a connection (this will _not_ prevent man:ppp[8] from passing the packets through an established connection), use the following: [.programlisting] .... set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 .... This is not always suitable, as it will effectively break demand-dial capabilities. Most programs will need a DNS lookup before doing any other network related things. In the DNS case, try to determine what is actually trying to resolve a host name. A lot of the time, Sendmail is the culprit. Make sure to configure Sendmail not to do any DNS lookups in its configuration file. See the section on extref:{handbook}serialcomms[using email with a dialup connection, dialup] in the FreeBSD Handbook for details. You may also want to add the following line to [.filename]#.mc#: [.programlisting] .... define(`confDELIVERY_MODE', `d')dnl .... This will make Sendmail queue everything until the queue is run, usually, every 30 minutes, or until a `sendmail -q` is done, perhaps from [.filename]#/etc/ppp/ppp.linkup#. === What do these CCP errors mean? I keep seeing the following errors in my log file: [.programlisting] .... CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) .... This is because man:ppp[8] is trying to negotiate Predictor1 compression, but the peer does not want to negotiate any compression at all. The messages are harmless, but can be silenced by disabling the compression: [.programlisting] .... disable pred1 .... === Why does ppp8 not log my connection speed? To log all lines of the modem conversation, enable the following: [.programlisting] .... set log +connect .... This will make man:ppp[8] log everything up until the last requested "expect" string. To see the connect speed when using PAP or CHAP, make sure to configure man:ppp[8] to expect the whole CONNECT line, using something like this: [.programlisting] .... set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \ \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n" .... This gets the CONNECT, sends nothing, then expects a line-feed, forcing man:ppp[8] to read the whole CONNECT response. === Why does ppp8 ignore the \ character in my chat script? The ppp utility parses each line in its configuration files so that it can interpret strings such as `set phone "123 456 789"` correctly and realize that the number is actually only one argument. To specify a `"` character, escape it using a backslash (`\`). When the chat interpreter parses each argument, it re-interprets the argument to find any special escape sequences such as `\P` or `\T`. As a result of this double-parsing, remember to use the correct number of escapes. To actually send a `\` character, do something like: [.programlisting] .... set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" .... It will result in the following sequence: [.programlisting] .... ATZ OK AT\X OK .... Or: [.programlisting] .... set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" .... It will result in the following sequence: [.programlisting] .... ATZ OK ATDT1234567 .... === What are FCS errors? FCS stands for Frame Check Sequence. Each PPP packet has a checksum attached to ensure that the data being received is the data being sent. If the FCS of an incoming packet is incorrect, the packet is dropped and the HDLC FCS count is increased. The HDLC error values can be displayed using the `show hdlc` command. If the link is bad or if the serial driver is dropping packets, it will produce the occasional FCS error. This is not usually worth worrying about although it does slow down the compression protocols substantially. If the link freezes as soon as it connects and produces a large number of FCS errors, make sure the modem is not using software flow control (XON/XOFF). If the link must use software flow control, use `set accmap 0x000a0000` to tell man:ppp[8] to escape the `^Q` and `^S` characters. Another reason for too many FCS errors may be that the remote end has stopped talking PPP. In this case, enable `async` logging to determine if the incoming data is actually a login or shell prompt. If it is a shell prompt at the remote end, it is possible to terminate man:ppp[8] without dropping the line by using `close lcp` followed by `term`) to reconnect to the shell on the remote machine. If nothing in the log file indicates why the link was terminated, ask the remote administrator or ISP why the session was terminated. === None of this helps — I am desperate! What can I do? If all else fails, send the details of the error, the configuration files, how man:ppp[8] is being started, the relevant parts of the log file, and the output of `netstat -rn`, before and after connecting, to the http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[FreeBSD general questions mailing list]. == Serial Communications This section answers common questions about serial communications with FreeBSD. PPP is covered in the <> section. === Which multi-port serial cards are supported by FreeBSD? There is a list of these in the extref:{handbook}serialcomms[Serial Communications, serial] chapter of the Handbook. Most multi-port PCI cards that are based on 16550 or clones are supported with no extra effort. Some unnamed clone cards have also been known to work, especially those that claim to be AST compatible. Check man:uart[4] and man:sio[4] to get more information on configuring such cards. === How do I get the boot: prompt to show on the serial console? See extref:{handbook}serialcomms[this section of the Handbook, serialconsole-setup]. === How do I tell if FreeBSD found my serial ports or modem cards? As the FreeBSD kernel boots, it will probe for the serial ports for which the kernel is configured. Either watch the boot messages closely or run this command after the system is up and running: [source,shell] .... % grep -E '^(sio|uart)[0-9]' < /var/run/dmesg.boot sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A .... This example shows two serial ports. The first is on IRQ4, port address `0x3f8`, and has a 16550A-type UART chip. The second uses the same kind of chip but is on IRQ3 and is at port address `0x2f8`. Internal modem cards are treated just like serial ports, except that they always have a modem attached to the port. The [.filename]#GENERIC# kernel includes support for two serial ports using the same IRQ and port address settings in the above example. If these settings are not right for the system, or if there are more modem cards or serial ports than the kernel is configured for, reconfigure using the instructions in <> for more details. === How do I access the serial ports on FreeBSD? The third serial port, [.filename]#sio2#, or [.filename]#COM3#, is on [.filename]#/dev/cuad2# for dial-out devices, and on [.filename]#/dev/ttyd2# for dial-in devices. What is the difference between these two classes of devices? When opening [.filename]#/dev/ttydX# in blocking mode, a process will wait for the corresponding [.filename]#cuadX# device to become inactive, and then wait for the carrier detect line to go active. When the [.filename]#cuadX# device is opened, it makes sure the serial port is not already in use by the [.filename]#ttydX# device. If the port is available, it steals it from the [.filename]#ttydX# device. Also, the [.filename]#cuadX# device does not care about carrier detect. With this scheme and an auto-answer modem, remote users can log in and local users can still dial out with the same modem and the system will take care of all the conflicts. === How do I enable support for a multi-port serial card? The section on kernel configuration provides information about configuring the kernel. For a multi-port serial card, place an man:sio[4] line for each serial port on the card in the man:device.hints[5] file. But place the IRQ specifiers on only one of the entries. All of the ports on the card should share one IRQ. For consistency, use the last serial port to specify the IRQ. Also, specify the following option in the kernel configuration file: [.programlisting] .... options COM_MULTIPORT .... The following [.filename]#/boot/device.hints# example is for an AST 4-port serial card on IRQ 12: [.programlisting] .... hint.sio.4.at="isa" hint.sio.4.port="0x2a0" hint.sio.4.flags="0x701" hint.sio.5.at="isa" hint.sio.5.port="0x2a8" hint.sio.5.flags="0x701" hint.sio.6.at="isa" hint.sio.6.port="0x2b0" hint.sio.6.flags="0x701" hint.sio.7.at="isa" hint.sio.7.port="0x2b8" hint.sio.7.flags="0x701" hint.sio.7.irq="12" .... The flags indicate that the master port has minor number `7` (`0x700`), and all the ports share an IRQ (`0x001`). === Can I set the default serial parameters for a port? See the extref:{handbook}serialcomms[Serial Communications, serial-hw-config] section in the FreeBSD Handbook. === How can I enable dialup logins on my modem? Refer to the section about extref:{handbook}serialcomms[Dial-in Services, dialup] in the FreeBSD Handbook. === How can I connect a dumb terminal to my FreeBSD box? This information is in the extref:{handbook}serialcomms[Terminals, term] section of the FreeBSD Handbook. === Why can I not run tip or cu? The built-in man:tip[1] and man:cu[1] utilities can only access the [.filename]#/var/spool/lock# directory via user `uucp` and group `dialer`. Use the `dialer` group to control who has access to the modem or remote systems by adding user accounts to `dialer`. Alternatively, everyone can be configured to run man:tip[1] and man:cu[1] by typing: [source,shell] .... # chmod 4511 /usr/bin/cu # chmod 4511 /usr/bin/tip .... == Miscellaneous Questions === FreeBSD uses a lot of swap space even when the computer has free memory left. Why? FreeBSD will proactively move entirely idle, unused pages of main memory into swap in order to make more main memory available for active use. This heavy use of swap is balanced by using the extra free memory for caching. Note that while FreeBSD is proactive in this regard, it does not arbitrarily decide to swap pages when the system is truly idle. Thus, the system will not be all paged out after leaving it idle overnight. === Why does top show very little free memory even when I have very few programs running? The simple answer is that free memory is wasted memory. Any memory that programs do not actively allocate is used within the FreeBSD kernel as disk cache. The values shown by man:top[1] labeled as `Inact` and `Laundry` are cached data at different aging levels. This cached data means the system does not have to access a slow disk again for data it has accessed recently, thus increasing overall performance. In general, a low value shown for `Free` memory in man:top[1] is good, provided it is not _very_ low. === Why will chmod not change the permissions on symlinks? Symlinks do not have permissions, and by default, man:chmod[1] will follow symlinks to change the permissions on the source file, if possible. For the file, [.filename]#foo# with a symlink named [.filename]#bar#, this command will always succeed. [source,shell] .... % chmod g-w bar .... However, the permissions on [.filename]#bar# will not have changed. When changing modes of the file hierarchies rooted in the files instead of the files themselves, use either `-H` or `-L` together with `-R` to make this work. See man:chmod[1] and man:symlink[7] for more information. [WARNING] ==== `-R` does a _recursive_ man:chmod[1]. Be careful about specifying directories or symlinks to directories to man:chmod[1]. To change the permissions of a directory referenced by a symlink, use man:chmod[1] without any options and follow the symlink with a trailing slash ([.filename]#/#). For example, if [.filename]#foo# is a symlink to directory [.filename]#bar#, to change the permissions of [.filename]#foo# (actually [.filename]#bar#), do something like: [source,shell] .... % chmod 555 foo/ .... With the trailing slash, man:chmod[1] will follow the symlink, [.filename]#foo#, to change the permissions of the directory, [.filename]#bar#. ==== === Can I run DOS binaries under FreeBSD? Yes. A DOS emulation program, package:emulators/doscmd[], is available in the FreeBSD Ports Collection. If doscmd will not suffice, package:emulators/pcemu[] emulates an 8088 and enough BIOS services to run many DOS text-mode applications. It requires the X Window System. The Ports Collection also has package:emulators/dosbox[]. The main focus of this application is emulating old DOS games using the local file system for files. === What do I need to do to translate a FreeBSD document into my native language? See the extref:{fdp-primer}[Translation FAQ, translations] in the FreeBSD Documentation Project Primer. === Why does my email to any address at FreeBSD.org bounce? The `FreeBSD.org` mail system implements some Postfix checks on incoming mail and rejects mail that is either from misconfigured relays or otherwise appears likely to be spam. Some of the specific requirements are: * The IP address of the SMTP client must "reverse-resolve" to a forward confirmed hostname. * The fully-qualified hostname given in the SMTP conversation (either HELO or EHLO) must resolve to the IP address of the client. Other advice to help mail reach its destination include: * Mail should be sent in plain text, and messages sent to mailing lists should generally be no more than 200KB in length. * Avoid excessive cross posting. Choose _one_ mailing list which seems most relevant and send it there. If you still have trouble with email infrastructure at `FreeBSD.org`, send a note with the details to mailto:postmaster@freebsd.org[postmaster@freebsd.org]; Include a date/time interval so that logs may be reviewed -- and note that we only keep one week's worth of mail logs. (Be sure to specify the time zone or offset from UTC.) === Where can I find a free FreeBSD account? While FreeBSD does not provide open access to any of their servers, others do provide open access UNIX(TM) systems. The charge varies and limited services may be available. http://www.arbornet.org/[Arbornet, Inc], also known as _M-Net_, has been providing open access to UNIX(TM) systems since 1983. Starting on an Altos running System III, the site switched to BSD/OS in 1991. In June of 2000, the site switched again to FreeBSD. _M-Net_ can be accessed via telnet and SSH and provides basic access to the entire FreeBSD software suite. However, network access is limited to members and patrons who donate to the system, which is run as a non-profit organization. _M-Net_ also provides an bulletin board system and interactive chat. === What is the cute little red guy's name? He does not have one, and is just called "the BSD daemon". If you insist upon using a name, call him "beastie". Note that "beastie" is pronounced "BSD". More about the BSD daemon is available on his http://www.mckusick.com/beastie/index.html[home page]. === Can I use the BSD daemon image? Perhaps. The BSD daemon is copyrighted by Marshall Kirk McKusick. Check his http://www.mckusick.com/beastie/mainpage/copyright.html[Statement on the Use of the BSD Daemon Figure] for detailed usage terms. In summary, the image can be used in a tasteful manner, for personal use, so long as appropriate credit is given. Before using the logo commercially, contact Kirk McKusick mailto:mckusick@FreeBSD.org[mckusick@FreeBSD.org] for permission. More details are available on the http://www.mckusick.com/beastie/index.html[BSD Daemon's home page]. === Do you have any BSD daemon images I could use? Xfig and eps drawings are available under [.filename]#/usr/shared/examples/BSD_daemon/#. === I have seen an acronym or other term on the mailing lists and I do not understand what it means. Where should I look? Refer to the extref:{handbook}glossary[FreeBSD Glossary, freebsd-glossary]. === Why should I care what color the bikeshed is? The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change. The longer and more complete answer is that after a very long argument about whether man:sleep[1] should take fractional second arguments, Poul-Henning Kamp mailto:phk@FreeBSD.org[phk@FreeBSD.org] posted a long message entitled "link:http://www.bikeshed.com[A bike shed (any color will do) on greener grass...]". The appropriate portions of that message are quoted below. Poul-Henning Kamp mailto:phk@FreeBSD.org[phk@FreeBSD.org] on http://lists.FreeBSD.org/mailman/listinfo/freebsd-hackers[freebsd-hackers], October 2, 1999 "What is it about this bike shed?" Some of you have asked me. It is a long story, or rather it is an old story, but it is quite short actually. C. Northcote Parkinson wrote a book in the early 1960s, called "Parkinson's Law", which contains a lot of insight into the dynamics of management. _[snip a bit of commentary on the book]_ In the specific example involving the bike shed, the other vital component is an atomic power-plant, I guess that illustrates the age of the book. Parkinson shows how you can go into the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions. Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. Richard P. Feynmann gives a couple of interesting, and very much to the point, examples relating to Los Alamos in his books. A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is _here_. In Denmark we call it "setting your fingerprint". It is about personal pride and prestige, it is about being able to point somewhere and say "There! _I_ did that." It is a strong trait in politicians, but present in most people given the chance. Just think about footsteps in wet cement. == The FreeBSD Funnies === How cool is FreeBSD? [qanda] Has anyone done any temperature testing while running FreeBSD? I know Linux(TM) runs cooler than DOS, but have never seen a mention of FreeBSD. It seems to run really hot.:: No, but we have done numerous taste tests on blindfolded volunteers who have also had 250 micrograms of LSD-25 administered beforehand. 35% of the volunteers said that FreeBSD tasted sort of orange, whereas Linux(TM) tasted like purple haze. Neither group mentioned any significant variances in temperature. We eventually had to throw the results of this survey out entirely anyway when we found that too many volunteers were wandering out of the room during the tests, thus skewing the results. We think most of the volunteers are at Apple now, working on their new "scratch and sniff" GUI. It is a funny old business we are in! Seriously, FreeBSD uses the HLT (halt) instruction when the system is idle thus lowering its energy consumption and therefore the heat it generates. Also if you have ACPI (Advanced Configuration and Power Interface) configured, then FreeBSD can also put the CPU into a low power mode. === Who is scratching in my memory banks?? [qanda] Is there anything "odd" that FreeBSD does when compiling the kernel which would cause the memory to make a scratchy sound? When compiling (and for a brief moment after recognizing the floppy drive upon startup, as well), a strange scratchy sound emanates from what appears to be the memory banks.:: Yes! You will see frequent references to "daemons" in the BSD documentation, and what most people do not know is that this refers to genuine, non-corporeal entities that now possess your computer. The scratchy sound coming from your memory is actually high-pitched whispering exchanged among the daemons as they best decide how to deal with various system administration tasks. If the noise gets to you, a good `fdisk /mbr` from DOS will get rid of them, but do not be surprised if they react adversely and try to stop you. In fact, if at any point during the exercise you hear the satanic voice of Bill Gates coming from the built-in speaker, take off running and do not ever look back! Freed from the counterbalancing influence of the BSD daemons, the twin demons of DOS and Windows(TM) are often able to re-assert total control over your machine to the eternal damnation of your soul. Now that you know, given a choice you would probably prefer to get used to the scratchy noises, no? === How many FreeBSD hackers does it take to change a lightbulb? One thousand, one hundred and sixty-nine: Twenty-three to complain to -CURRENT about the lights being out; Four to claim that it is a configuration problem, and that such matters really belong on -questions; Three to submit PRs about it, one of which is misfiled under doc and consists only of "it's dark"; One to commit an untested lightbulb which breaks buildworld, then back it out five minutes later; Eight to flame the PR originators for not including patches in their PRs; Five to complain about buildworld being broken; Thirty-one to answer that it works for them, and they must have updated at a bad time; One to post a patch for a new lightbulb to -hackers; One to complain that he had patches for this three years ago, but when he sent them to -CURRENT they were just ignored, and he has had bad experiences with the PR system; besides, the proposed new lightbulb is non-reflexive; Thirty-seven to scream that lightbulbs do not belong in the base system, that committers have no right to do things like this without consulting the Community, and WHAT IS -CORE DOING ABOUT IT!? Two hundred to complain about the color of the bicycle shed; Three to point out that the patch breaks man:style[9]; Seventeen to complain that the proposed new lightbulb is under GPL; Five hundred and eighty-six to engage in a flame war about the comparative advantages of the GPL, the BSD license, the MIT license, the NPL, and the personal hygiene of unnamed FSF founders; Seven to move various portions of the thread to -chat and -advocacy; One to commit the suggested lightbulb, even though it shines dimmer than the old one; Two to back it out with a furious flame of a commit message, arguing that FreeBSD is better off in the dark than with a dim lightbulb; Forty-six to argue vociferously about the backing out of the dim lightbulb and demanding a statement from -core; Eleven to request a smaller lightbulb so it will fit their Tamagotchi if we ever decide to port FreeBSD to that platform; Seventy-three to complain about the SNR on -hackers and -chat and unsubscribe in protest; Thirteen to post "unsubscribe", "How do I unsubscribe?", or "Please remove me from the list", followed by the usual footer; One to commit a working lightbulb while everybody is too busy flaming everybody else to notice; Thirty-one to point out that the new lightbulb would shine 0.364% brighter if compiled with TenDRA (although it will have to be reshaped into a cube), and that FreeBSD should therefore switch to TenDRA instead of GCC; One to complain that the new lightbulb lacks fairings; Nine (including the PR originators) to ask "what is MFC?"; Fifty-seven to complain about the lights being out two weeks after the bulb has been changed. _Nik Clayton_ mailto:nik@FreeBSD.org[nik@FreeBSD.org] adds: _I was laughing quite hard at this._ _And then I thought, "Hang on, shouldn't there be '1 to document it.' in that list somewhere?"_ _And then I was enlightened :-)_ _Thomas Abthorpe_ mailto:tabthorpe@FreeBSD.org[tabthorpe@FreeBSD.org] says: "None, _real_ FreeBSD hackers are not afraid of the dark!" === Where does data written to /dev/null go? It goes into a special data sink in the CPU where it is converted to heat which is vented through the heatsink / fan assembly. This is why CPU cooling is increasingly important; as people get used to faster processors, they become careless with their data and more and more of it ends up in [.filename]#/dev/null#, overheating their CPUs. If you delete [.filename]#/dev/null# (which effectively disables the CPU data sink) your CPU may run cooler but your system will quickly become constipated with all that excess data and start to behave erratically. If you have a fast network connection you can cool down your CPU by reading data out of [.filename]#/dev/random# and sending it off somewhere; however you run the risk of overheating your network connection and [.filename]#/# or angering your ISP, as most of the data will end up getting converted to heat by their equipment, but they generally have good cooling, so if you do not overdo it you should be OK. _Paul Robinson adds:_ There are other methods. As every good sysadmin knows, it is part of standard practice to send data to the screen of interesting variety to keep all the pixies that make up your picture happy. Screen pixies (commonly mis-typed or re-named as "pixels") are categorized by the type of hat they wear (red, green or blue) and will hide or appear (thereby showing the color of their hat) whenever they receive a little piece of food. Video cards turn data into pixie-food, and then send them to the pixies -- the more expensive the card, the better the food, so the better behaved the pixies are. They also need constant stimulation -- this is why screen savers exist. To take your suggestions further, you could just throw the random data to console, thereby letting the pixies consume it. This causes no heat to be produced at all, keeps the pixies happy and gets rid of your data quite quickly, even if it does make things look a bit messy on your screen. Incidentally, as an ex-admin of a large ISP who experienced many problems attempting to maintain a stable temperature in a server room, I would strongly discourage people sending the data they do not want out to the network. The fairies who do the packet switching and routing get annoyed by it as well. === My colleague sits at the computer too much, how can I prank her? Install package:games/sl[] and wait for her to mistype `sl` for `ls`. == Advanced Topics === How can I learn more about FreeBSD's internals? See the extref:{arch-handbook}[FreeBSD Architecture Handbook]. Additionally, much general UNIX(TM) knowledge is directly applicable to FreeBSD. === How can I contribute to FreeBSD? What can I do to help? We accept all types of contributions: documentation, code, and even art. See the article on extref:{contributing}[Contributing to FreeBSD] for specific advice on how to do this. And thanks for the thought! === What are snapshots and releases? There are currently 2 active/semi-active branches in the FreeBSD http://svnweb.FreeBSD.org/base/[Subversion Repository]. (Earlier branches are only changed very rarely, which is why there are only 2 active branches of development): * stable/11/ AKA _11-STABLE_ * stable/12/ AKA _12-STABLE_ * head/ AKA _-CURRENT_ AKA _12-CURRENT_ `HEAD` is not an actual branch tag. It is a symbolic constant for the current, non-branched development stream known as _-CURRENT_. Right now, _-CURRENT_ is the 13._X_ development stream; the _12-STABLE_ branch, stable/12/, forked off from _-CURRENT_ in December 2018 and the _11-STABLE_ branch, stable/11/, forked off from _-CURRENT_ in October 2016. === How can I make the most of the data I see when my kernel panics? Here is typical kernel panic: [.programlisting] .... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault .... This message is not enough. While the instruction pointer value is important, it is also configuration dependent as it varies depending on the kernel image. If it is a [.filename]#GENERIC# kernel image from one of the snapshots, it is possible for somebody else to track down the offending function, but for a custom kernel, only you can tell us where the fault occurred. To proceed: [.procedure] ==== . Write down the instruction pointer value. Note that the `0x8:` part at the beginning is not significant in this case: it is the `0xf0xxxxxx` part that we want. . When the system reboots, do the following: + [source,shell] .... % nm -n kernel.that.caused.the.panic | grep f0xxxxxx .... + where `f0xxxxxx` is the instruction pointer value. The odds are you will not get an exact match since the symbols in the kernel symbol table are for the entry points of functions and the instruction pointer address will be somewhere inside a function, not at the start. If you do not get an exact match, omit the last digit from the instruction pointer value and try again: + [source,shell] .... % nm -n kernel.that.caused.the.panic | grep f0xxxxx .... + If that does not yield any results, chop off another digit. Repeat until there is some sort of output. The result will be a possible list of functions which caused the panic. This is a less than exact mechanism for tracking down the point of failure, but it is better than nothing. ==== However, the best way to track down the cause of a panic is by capturing a crash dump, then using man:kgdb[1] to generate a stack trace on the crash dump. In any case, the method is this: [.procedure] ==== . Make sure that the following line is included in the kernel configuration file: + [.programlisting] .... makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols .... + . Change to the [.filename]#/usr/src# directory: + [source,shell] .... # cd /usr/src .... + . Compile the kernel: + [source,shell] .... # make buildkernel KERNCONF=MYKERNEL .... + . Wait for man:make[1] to finish compiling. + [source,shell] .... # make installkernel KERNCONF=MYKERNEL .... + . Reboot. ==== [NOTE] ==== If `KERNCONF` is not included, the [.filename]#GENERIC# kernel will instead be built and installed. ==== The man:make[1] process will have built two kernels. [.filename]#/usr/obj/usr/src/sys/MYKERNEL/kernel# and [.filename]#/usr/obj/usr/src/sys/MYKERNEL/kernel.debug#. [.filename]#kernel# was installed as [.filename]#/boot/kernel/kernel#, while [.filename]#kernel.debug# can be used as the source of debugging symbols for man:kgdb[1]. To capture a crash dump, edit [.filename]#/etc/rc.conf# and set `dumpdev` to point to either the swap partition or `AUTO`. This will cause the man:rc[8] scripts to use the man:dumpon[8] command to enable crash dumps. This command can also be run manually. After a panic, the crash dump can be recovered using man:savecore[8]; if `dumpdev` is set in [.filename]#/etc/rc.conf#, the man:rc[8] scripts will run man:savecore[8] automatically and put the crash dump in [.filename]#/var/crash#. [NOTE] ==== FreeBSD crash dumps are usually the same size as physical RAM. Therefore, make sure there is enough space in [.filename]#/var/crash# to hold the dump. Alternatively, run man:savecore[8] manually and have it recover the crash dump to another directory with more room. It is possible to limit the size of the crash dump by using `options MAXMEM=N` where _N_ is the size of kernel's memory usage in KBs. For example, for 1 GB of RAM, limit the kernel's memory usage to 128 MB, so that the crash dump size will be 128 MB instead of 1 GB. ==== Once the crash dump has been recovered , get a stack trace as follows: [source,shell] .... % kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0 (kgdb) backtrace .... Note that there may be several screens worth of information. Ideally, use man:script[1] to capture all of them. Using the unstripped kernel image with all the debug symbols should show the exact line of kernel source code where the panic occurred. The stack trace is usually read from the bottom up to trace the exact sequence of events that lead to the crash. man:kgdb[1] can also be used to print out the contents of various variables or structures to examine the system state at the time of the crash. [TIP] ==== If a second computer is available, man:kgdb[1] can be configured to do remote debugging, including setting breakpoints and single-stepping through the kernel code. ==== [NOTE] ==== If `DDB` is enabled and the kernel drops into the debugger, a panic and a crash dump can be forced by typing `panic` at the `ddb` prompt. It may stop in the debugger again during the panic phase. If it does, type `continue` and it will finish the crash dump. ==== === Why has dlsym() stopped working for ELF executables? The ELF toolchain does not, by default, make the symbols defined in an executable visible to the dynamic linker. Consequently `dlsym()` searches on handles obtained from calls to `dlopen(NULL, flags)` will fail to find such symbols. To search, using `dlsym()`, for symbols present in the main executable of a process, link the executable using the `--export-dynamic` option to the ELF linker (man:ld[1]). === How can I increase or reduce the kernel address space on i386? By default, the kernel address space is 1 GB (2 GB for PAE) for i386. When running a network-intensive server or using ZFS, this will probably not be enough. Add the following line to the kernel configuration file to increase available space and rebuild the kernel: [.programlisting] .... options KVA_PAGES=N .... To find the correct value of _N_, divide the desired address space size (in megabytes) by four. (For example, it is `512` for 2 GB.) == Acknowledgments This innocent little Frequently Asked Questions document has been written, rewritten, edited, folded, spindled, mutilated, eviscerated, contemplated, discombobulated, cogitated, regurgitated, rebuilt, castigated, and reinvigorated over the last decade, by a cast of hundreds if not thousands. Repeatedly. We wish to thank every one of the people responsible, and we encourage you to extref:{contributing}[join them] in making this FAQ even better. diff --git a/documentation/content/zh-tw/books/handbook/_index.adoc b/documentation/content/zh-tw/books/handbook/_index.adoc index 1c570c9eb5..1a02a43878 100644 --- a/documentation/content/zh-tw/books/handbook/_index.adoc +++ b/documentation/content/zh-tw/books/handbook/_index.adoc @@ -1,51 +1,51 @@ --- title: FreeBSD 使用手冊 authors: - author: FreeBSD 文件計劃 copyright: 1995-2020 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] next: books/handbook/preface showBookMenu: true weight: 0 path: "/books/handbook/" --- = FreeBSD 使用手冊 :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] 摘要 歡迎使用 FreeBSD！ 本使用手冊涵蓋範圍包括了 _FreeBSD 12.0-RELEASE_ 與 _FreeBSD 11.3-RELEASE_ 的安裝與平日操作的說明。 這份使用手冊是很多人的集體創作，而且仍然『持續不斷』的進行中，因此部份章節可能尚未仍未完成，如果您有興趣協助本計畫的話，請寄電子郵件至 http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[FreeBSD 文件專案郵遞論壇]。 -在 https://www.FreeBSD.org/[FreeBSD 網站] 可以找到本手冊的最新版本，舊版文件可從 https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/] 取得。本文件也提供各種格式與不同壓縮方式的版本可自 https://download.freebsd.org/ftp/doc/[FreeBSD FTP 伺服器] 或是其中一個 <> 下載。 列印出來的實體書面資料可在 https://www.freebsdmall.com/[FreeBSD 商城] 購買。 此外，您可在 https://www.FreeBSD.org/search/[搜尋頁面] 中搜尋本文件或其他文件的資料。 +在 https://www.FreeBSD.org/[FreeBSD 網站] 可以找到本手冊的最新版本，舊版文件可從 https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/] 取得。本文件也提供各種格式與不同壓縮方式的版本可自 https://download.freebsd.org/doc/[FreeBSD FTP 伺服器] 或是其中一個 <> 下載。 列印出來的實體書面資料可在 https://www.freebsdmall.com/[FreeBSD 商城] 購買。 此外，您可在 https://www.FreeBSD.org/search/[搜尋頁面] 中搜尋本文件或其他文件的資料。 ''' diff --git a/documentation/content/zh-tw/books/handbook/book.adoc b/documentation/content/zh-tw/books/handbook/book.adoc index 004fe46b2b..784efc639c 100644 --- a/documentation/content/zh-tw/books/handbook/book.adoc +++ b/documentation/content/zh-tw/books/handbook/book.adoc @@ -1,150 +1,150 @@ --- title: FreeBSD 使用手冊 authors: - author: FreeBSD 文件計劃 copyright: 1995-2020 The FreeBSD Documentation Project trademarks: ["freebsd", "ibm", "ieee", "redhat", "3com", "adobe", "apple", "intel", "linux", "microsoft", "opengroup", "sun", "realnetworks", "oracle", "3ware", "arm", "adaptec", "google", "heidelberger", "intuit", "lsilogic", "themathworks", "thomson", "vmware", "wolframresearch", "xiph", "xfree86", "general"] --- = FreeBSD 使用手冊 :doctype: book :toc: macro :toclevels: 2 :icons: font :sectnums: :sectnumlevels: 6 :partnums: :source-highlighter: rouge :experimental: :book: true :pdf: false :images-path: books/handbook/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :chapters-path: content/{{% lang %}}/books/handbook/ endif::[] ifdef::backend-pdf,backend-epub3[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] :chapters-path: include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] [abstract] 摘要 歡迎使用 FreeBSD！ 本使用手冊涵蓋範圍包括了 _FreeBSD 12.0-RELEASE_ 與 _FreeBSD 11.3-RELEASE_ 的安裝與平日操作的說明。 這份使用手冊是很多人的集體創作，而且仍然『持續不斷』的進行中，因此部份章節可能尚未仍未完成，如果您有興趣協助本計畫的話，請寄電子郵件至 http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc[FreeBSD 文件專案郵遞論壇]。 -在 https://www.FreeBSD.org/[FreeBSD 網站] 可以找到本手冊的最新版本，舊版文件可從 https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/] 取得。本文件也提供各種格式與不同壓縮方式的版本可自 https://download.freebsd.org/ftp/doc/[FreeBSD FTP 伺服器] 或是其中一個 <> 下載。 列印出來的實體書面資料可在 https://www.freebsdmall.com/[FreeBSD 商城] 購買。 此外，您可在 https://www.FreeBSD.org/search/[搜尋頁面] 中搜尋本文件或其他文件的資料。 +在 https://www.FreeBSD.org/[FreeBSD 網站] 可以找到本手冊的最新版本，舊版文件可從 https://docs.FreeBSD.org/doc/[https://docs.FreeBSD.org/doc/] 取得。本文件也提供各種格式與不同壓縮方式的版本可自 https://download.freebsd.org/doc/[FreeBSD FTP 伺服器] 或是其中一個 <> 下載。 列印出來的實體書面資料可在 https://www.freebsdmall.com/[FreeBSD 商城] 購買。 此外，您可在 https://www.FreeBSD.org/search/[搜尋頁面] 中搜尋本文件或其他文件的資料。 ''' toc::[] :sectnums!: include::{chapters-path}preface/_index.adoc[leveloffset=+1] :sectnums: // Section one include::{chapters-path}parti.adoc[] include::{chapters-path}introduction/_index.adoc[leveloffset=+1] include::{chapters-path}bsdinstall/_index.adoc[leveloffset=+1] include::{chapters-path}basics/_index.adoc[leveloffset=+1] include::{chapters-path}ports/_index.adoc[leveloffset=+1] include::{chapters-path}x11/_index.adoc[leveloffset=+1] // Section two include::{chapters-path}partii.adoc[] include::{chapters-path}desktop/_index.adoc[leveloffset=+1] include::{chapters-path}multimedia/_index.adoc[leveloffset=+1] include::{chapters-path}kernelconfig/_index.adoc[leveloffset=+1] include::{chapters-path}printing/_index.adoc[leveloffset=+1] include::{chapters-path}linuxemu/_index.adoc[leveloffset=+1] // Section three include::{chapters-path}partiii.adoc[] include::{chapters-path}config/_index.adoc[leveloffset=+1] include::{chapters-path}boot/_index.adoc[leveloffset=+1] include::{chapters-path}security/_index.adoc[leveloffset=+1] include::{chapters-path}jails/_index.adoc[leveloffset=+1] include::{chapters-path}mac/_index.adoc[leveloffset=+1] include::{chapters-path}audit/_index.adoc[leveloffset=+1] include::{chapters-path}disks/_index.adoc[leveloffset=+1] include::{chapters-path}geom/_index.adoc[leveloffset=+1] include::{chapters-path}zfs/_index.adoc[leveloffset=+1] include::{chapters-path}filesystems/_index.adoc[leveloffset=+1] include::{chapters-path}virtualization/_index.adoc[leveloffset=+1] include::{chapters-path}l10n/_index.adoc[leveloffset=+1] include::{chapters-path}cutting-edge/_index.adoc[leveloffset=+1] include::{chapters-path}dtrace/_index.adoc[leveloffset=+1] include::{chapters-path}usb-device-mode/_index.adoc[leveloffset=+1] // Section four include::{chapters-path}partiv.adoc[] include::{chapters-path}serialcomms/_index.adoc[leveloffset=+1] include::{chapters-path}ppp-and-slip/_index.adoc[leveloffset=+1] include::{chapters-path}mail/_index.adoc[leveloffset=+1] include::{chapters-path}network-servers/_index.adoc[leveloffset=+1] include::{chapters-path}firewalls/_index.adoc[leveloffset=+1] include::{chapters-path}advanced-networking/_index.adoc[leveloffset=+1] // Section five include::{chapters-path}partv.adoc[] :sectnums!: include::{chapters-path}mirrors/_index.adoc[leveloffset=+1] include::{chapters-path}bibliography/_index.adoc[leveloffset=+1] include::{chapters-path}eresources/_index.adoc[leveloffset=+1] include::{chapters-path}pgpkeys/_index.adoc[leveloffset=+1] :sectnums: