msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2020-05-17 17:54+0200\n"
"PO-Revision-Date: 2017-05-03 13:43+0000\n"
"Last-Translator: Patrick Kox <patrick.kox@proximus.be>\n"
"Language-Team: Dutch <https://hosted.weblate.org/projects/debian-handbook/11_network-services/nl/>\n"
"Language: nl-NL\n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n != 1;\n"
"X-Generator: Weblate 2.14-dev\n"

msgid "Postfix"
msgstr ""

msgid "Apache"
msgstr ""

msgid "NFS"
msgstr ""

msgid "Samba"
msgstr ""

msgid "Squid"
msgstr ""

msgid "OpenLDAP"
msgstr ""

msgid "SIP"
msgstr ""

msgid "SSL"
msgstr ""

msgid "OpenDKIM"
msgstr ""

msgid "SPF"
msgstr ""

msgid "Network Services: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN"
msgstr ""

msgid "Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described. They usually require the encryption technology described in <xref linkend=\"sect.x509-cert\" />."
msgstr ""

msgid "Mail Server"
msgstr ""

msgid "The Falcot Corp administrators selected Postfix for the electronic mail server, due to its reliability and its ease of configuration. Indeed, its design enforces that each task is implemented in a process with the minimum set of required permissions, which is a great mitigation measure against security problems."
msgstr ""

msgid "<primary>email</primary><secondary>server</secondary>"
msgstr ""

msgid "<primary>email</primary><secondary>Postfix</secondary>"
msgstr ""

msgid "<primary>server</primary><secondary>email</secondary>"
msgstr ""

msgid "<primary>server</primary><secondary>E-Mail</secondary>"
msgstr ""

msgid "<primary>mail server</primary>"
msgstr ""

msgid "<primary>SMTP</primary>"
msgstr ""

msgid "<primary>Postfix</primary>"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">postfix</emphasis></primary>"
msgstr ""

msgid "<emphasis>ALTERNATIVE</emphasis> The Exim4 server"
msgstr ""

msgid "<primary>Exim</primary>"
msgstr ""

msgid "<primary>email</primary><secondary>Exim</secondary>"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">exim4</emphasis></primary>"
msgstr ""

msgid "Debian uses Exim4 as the default email server (which is why the initial installation includes Exim4). The configuration is provided by a separate package, <emphasis role=\"pkg\">exim4-config</emphasis>, and automatically customized based on the answers to a set of Debconf questions very similar to the questions asked by the <emphasis role=\"pkg\">postfix</emphasis> package."
msgstr ""

msgid "The configuration can be either in one single file (<filename>/etc/exim4/exim4.conf.template</filename>) or split across a number of configuration snippets stored under <filename>/etc/exim4/conf.d/</filename>. In both cases, the files are used by <command>update-exim4.conf</command> as templates to generate <filename>/var/lib/exim4/config.autogenerated</filename>. The latter is the file used by Exim4. Thanks to this mechanism, values obtained through Exim's debconf configuration — which are stored in <filename>/etc/exim4/update-exim4.conf.conf</filename> — can be injected in Exim's configuration file, even when the administrator or another package has altered the default Exim configuration."
msgstr ""

msgid "The Exim4 configuration file syntax has its peculiarities and its learning curve; however, once these peculiarities are understood, Exim4 is a very complete and powerful email server, as evidenced by the tens of pages of documentation. <ulink type=\"block\" url=\"https://www.exim.org/docs.html\" />"
msgstr ""

msgid "Installing Postfix"
msgstr ""

msgid "<primary>Postfix</primary><secondary>installation</secondary>"
msgstr ""

msgid "The <emphasis role=\"pkg\">postfix</emphasis> package includes the main <acronym>SMTP</acronym> daemon. Other packages (such as <emphasis role=\"pkg\">postfix-ldap</emphasis> and <emphasis role=\"pkg\">postfix-pgsql</emphasis>) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them."
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> SMTP"
msgstr ""

msgid "<primary>Simple Mail Transfer Protocol</primary>"
msgstr ""

msgid "<primary>server</primary><secondary>SMTP</secondary>"
msgstr ""

msgid "<acronym>SMTP</acronym> (<emphasis>Simple Mail Transfer Protocol</emphasis>, RFC 5321) is the protocol used by mail servers to exchange and route emails."
msgstr ""

msgid "Several Debconf questions are asked during the installation of the package. The answers allow generating a first version of the <filename>/etc/postfix/main.cf</filename> configuration file."
msgstr ""

msgid "<primary>Postfix</primary><secondary><filename>/etc/postfix/main.cf</filename></secondary>"
msgstr ""

msgid "The first question deals with the type of setup. Only two of the proposed answers are relevant in case of an Internet-connected server, “Internet site” and “Internet with smarthost”. The former is appropriate for a server that receives incoming email and sends outgoing email directly to its recipients, and is therefore well-adapted to the Falcot Corp case. The latter is appropriate for a server receiving incoming email normally, but that sends outgoing email through an intermediate SMTP server — the “smarthost” — rather than directly to the recipient's server. This is mostly useful for individuals with a dynamic IP address, since many email servers reject messages coming straight from such an IP address. In this case, the smarthost will usually be the ISP's SMTP server, which is always configured to accept email coming from the ISP's customers and forward it appropriately. This setup (with a smarthost) is also relevant for servers that are not permanently connected to the internet, since it avoids having to manage a queue of undeliverable messages that need to be retried later."
msgstr ""

msgid "<emphasis>VOCABULARY</emphasis> ISP"
msgstr ""

msgid "<primary>ISP, Internet Service Provider</primary>"
msgstr ""

msgid "<acronym>ISP</acronym> is the acronym for “Internet Service Provider”. It covers an entity, often a commercial company, that provides Internet connections and the associated basic services (email, news and so on)."
msgstr ""

msgid "The second question deals with the full name of the machine, used to generate email addresses from a local user name; the full name of the machine ends up as the part after the at-sign (“@”). In the case of Falcot, the answer should be <literal>mail.falcot.com</literal>. This is the only question asked by default, but the configuration it leads to is not complete enough for the needs of Falcot, which is why the administrators run <command>dpkg-reconfigure postfix</command> so as to be able to customize more parameters."
msgstr ""

msgid "One of the extra questions asks for all the domain names related to this machine. The default list includes its full name as well as a few synonyms for <literal>localhost</literal>, but the main <literal>falcot.com</literal> domain needs to be added by hand. More generally, this question should usually be answered with all the domain names for which this machine should serve as an MX server; in other words, all the domain names for which the DNS says that this machine will accept email. This information ends up in the <literal>mydestination</literal> variable of the main Postfix configuration file — <filename>/etc/postfix/main.cf</filename>."
msgstr ""

msgid "<primary>server</primary><secondary>MX</secondary>"
msgstr ""

msgid "<primary>MX</primary><secondary>server</secondary>"
msgstr ""

msgid "Role of the DNS <emphasis>MX</emphasis> record while sending a mail"
msgstr ""

msgid "<emphasis>EXTRA</emphasis> Querying the MX records"
msgstr ""

msgid "When the DNS does not have an MX record for a domain, the email server will try sending the messages to the host itself, by using the matching A record (or AAAA in IPv6)."
msgstr ""

msgid "In some cases, the installation can also ask what networks should be allowed to send email via the machine. In its default configuration, Postfix only accepts emails coming from the machine itself; the local network will usually be added. The Falcot Corp administrators added <literal>192.168.0.0/16</literal> to the default answer. If the question is not asked, the relevant variable in the configuration file is <literal>mynetworks</literal>, as seen in the example below."
msgstr ""

msgid "Local email can also be delivered through <command>procmail</command>. This tool allows users to sort their incoming email according to rules stored in their <filename>~/.procmailrc</filename> file. Both Postfix and Exim4 suggest <emphasis role=\"pkg\">procmail</emphasis> by default, but there are alternatives like <emphasis role=\"pkg\">maildrop</emphasis> or Sieve filters."
msgstr ""

msgid "<primary><command>procmail</command></primary>"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary><command>maildrop</command></primary>"
msgstr "<primary>Samba</primary>"

msgid "<primary>email</primary><secondary>filtering</secondary>"
msgstr ""

msgid "<primary>filtering email</primary>"
msgstr ""

msgid "After this first step, the administrators got the following configuration file; it will be used as a starting point for adding some extra functionality in the next sections."
msgstr ""

msgid "Initial <filename>/etc/postfix/main.cf</filename> file"
msgstr ""

msgid "<primary><filename>/etc/postfix/main.cf</filename></primary><secondary>example</secondary>"
msgstr ""

msgid "<primary>Examples</primary><secondary><filename>/etc/postfix/main.cf</filename></secondary>"
msgstr ""

msgid ""
"<![CDATA[\n"
"# See /usr/share/postfix/main.cf.dist for a commented, more complete version\n"
"\n"
"\n"
"# Debian specific:  Specifying a file name will cause the first\n"
"# line of that file to be used as the name.  The Debian default\n"
"# is /etc/mailname.\n"
"#myorigin = /etc/mailname\n"
"\n"
"smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)\n"
"biff = no\n"
"\n"
"# appending .domain is the MUA's job.\n"
"append_dot_mydomain = no\n"
"\n"
"# Uncomment the next line to generate \"delayed mail\" warnings\n"
"#delay_warning_time = 4h\n"
"\n"
"readme_directory = no\n"
"\n"
"# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on\n"
"# fresh installs.\n"
"compatibility_level = 2\n"
"\n"
"\n"
"\n"
"# TLS parameters\n"
"smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem\n"
"smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key\n"
"smtpd_use_tls=yes\n"
"smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache\n"
"smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache\n"
"\n"
"# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for\n"
"# information on enabling SSL in the smtp client.\n"
"\n"
"smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination\n"
"myhostname = mail.falcot.com\n"
"alias_maps = hash:/etc/aliases\n"
"alias_database = hash:/etc/aliases\n"
"myorigin = /etc/mailname\n"
"mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost\n"
"relayhost =\n"
"mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16\n"
"mailbox_size_limit = 0\n"
"recipient_delimiter = +\n"
"inet_interfaces = all\n"
"inet_protocols = all\n"
"]]>"
msgstr ""

msgid "<emphasis>SECURITY</emphasis> <emphasis>Snake oil</emphasis> SSL certificates"
msgstr ""

msgid "The <emphasis>snake oil</emphasis> certificates, like the <emphasis>snake oil</emphasis> “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However, they are useful to improve the privacy of the exchanges."
msgstr ""

msgid "In general they should only be used for testing purposes, and normal service must use real certificates. The <link linkend=\"sidebar.letsencrypt\">Let's encrypt</link> initiative offers free and trusted SSL/TLS certificates, which can be generated using the <emphasis role=\"pkg\">certbot</emphasis> package as described in <xref linkend=\"sect.apache-ssl\" /> and then used in <command>postfix</command> like this:"
msgstr ""

msgid "<primary>Postfix</primary><secondary><emphasis role=\"pkg\">certbot</emphasis></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary>trusted certificates</secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_tls_cert_file</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_tls_key_file</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_tls_CAfile</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_tls_CApath</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtp_tls_CApath</literal></secondary>"
msgstr ""

msgid ""
"\n"
"smtpd_tls_cert_file = /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/fullchain.pem\n"
"smtpd_tls_key_file = /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/privkey.pem\n"
"smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt\n"
"smtpd_tls_CApath = /etc/ssl/certs\n"
"smtp_tls_CApath = /etc/ssl/certs"
msgstr ""

msgid "A different way to generate own certificates is described in <xref linkend=\"sect.easy-rsa\" />."
msgstr ""

msgid "Configuring Virtual Domains"
msgstr ""

msgid "<primary>Postfix</primary><secondary>virtual domain</secondary>"
msgstr ""

msgid "<primary>domain</primary><secondary>virtual</secondary>"
msgstr ""

msgid "<primary>virtual domain</primary>"
msgstr ""

msgid "The mail server can receive emails addressed to other domains besides the main domain; these are then known as virtual domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Virtual domains and canonical domains"
msgstr ""

msgid "None of the virtual domains must be referenced in the <literal>mydestination</literal> variable; this variable only contains the names of the “canonical” domains directly associated to the machine and its local users."
msgstr ""

msgid "Virtual Alias Domains"
msgstr ""

msgid "<primary>alias</primary><secondary>virtual alias domain</secondary>"
msgstr ""

msgid "<primary>virtual domain</primary><secondary>virtual alias domain</secondary>"
msgstr ""

msgid "A virtual alias domain only contains aliases, i.e. addresses that only forward emails to other addresses."
msgstr ""

msgid "Such a domain is enabled by adding its name to the <literal>virtual_alias_domains</literal> variable, and referencing an address mapping file in the <literal>virtual_alias_maps</literal> variable."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>virtual_alias_domains</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>virtual_alias_maps</literal></secondary>"
msgstr ""

msgid ""
"\n"
"virtual_alias_domains = falcotsbrand.com\n"
"virtual_alias_maps = hash:/etc/postfix/virtual"
msgstr ""

msgid "The <filename>/etc/postfix/virtual</filename> file describes a mapping with a rather straightforward syntax: each line contains two fields separated by whitespace; the first field is the alias name, the second field is a list of email addresses where it redirects. The special <literal>@domain.com</literal> syntax covers all remaining aliases in a domain."
msgstr ""

msgid "<primary>Postfix</primary><secondary><filename>/etc/postfix/virtual</filename></secondary>"
msgstr ""

msgid ""
"\n"
"webmaster@falcotsbrand.com  jean@falcot.com\n"
"contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com\n"
"# The alias below is generic and covers all addresses within\n"
"# the falcotsbrand.com domain not otherwise covered by this file.\n"
"# These addresses forward email to the same user name in the\n"
"# falcot.com domain.\n"
"@falcotsbrand.com           @falcot.com"
msgstr ""

msgid "After changing <filename>/etc/postfix/virtual</filename> the postfix table <filename>/etc/postfix/virtual.db</filename> needs to be updated using <command>sudo postmap /etc/postfix/virtual</command>."
msgstr ""

msgid "Virtual Mailbox Domains"
msgstr ""

msgid "<primary>mailbox, virtual domain</primary>"
msgstr ""

msgid "<primary>virtual domain</primary><secondary>virtual mailbox domain</secondary>"
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Combined virtual domain?"
msgstr ""

msgid "Postfix does not allow using the same domain in both <literal>virtual_alias_domains</literal> and <literal>virtual_mailbox_domains</literal>. However, every domain of <literal>virtual_mailbox_domains</literal> is implicitly included in <literal>virtual_alias_domains</literal>, which makes it possible to mix aliases and mailboxes within a virtual domain."
msgstr ""

msgid "Messages addressed to a virtual mailbox domain are stored in mailboxes not assigned to a local system user."
msgstr ""

msgid "Enabling a virtual mailbox domain requires naming this domain in the <literal>virtual_mailbox_domains</literal> variable, and referencing a mailbox mapping file in <literal>virtual_mailbox_maps</literal>. The <literal>virtual_mailbox_base</literal> parameter contains the directory under which the mailboxes will be stored."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>virtual_mailbox_domains</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>virtual_mailbox_maps</literal></secondary>"
msgstr ""

msgid ""
"\n"
"virtual_mailbox_domains = falcot.org\n"
"virtual_mailbox_maps = hash:/etc/postfix/vmailbox\n"
"virtual_mailbox_base = /var/mail/vhosts"
msgstr ""

msgid "The <literal>virtual_uid_maps</literal> parameter (respectively <literal>virtual_gid_maps</literal>) references the file containing the mapping between the email address and the system user (respectively group) that “owns” the corresponding mailbox. To get all mailboxes owned by the same owner/group, the <literal>static:5000</literal> syntax assigns a fixed UID/GID (of value 5000 here)."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>virtual_uid_maps</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>virtual_gid_maps</literal></secondary>"
msgstr ""

msgid "Again, the syntax of the <filename>/etc/postfix/vmailbox</filename> file is quite straightforward: two fields separated with whitespace. The first field is an email address within one of the virtual domains, and the second field is the location of the associated mailbox (relative to the directory specified in <emphasis>virtual_mailbox_base</emphasis>). If the mailbox name ends with a slash (<literal>/</literal>), the emails will be stored in the <emphasis>maildir</emphasis> format; otherwise, the traditional <emphasis>mbox</emphasis> format will be used. The <emphasis>maildir</emphasis> format uses a whole directory to store a mailbox, each individual message being stored in a separate file. In the <emphasis>mbox</emphasis> format, on the other hand, the whole mailbox is stored in one file, and each line starting with “<literal>From </literal>” (<literal>From</literal> followed by a space) signals the start of a new message."
msgstr ""

msgid "<primary>Postfix</primary><secondary><filename>/etc/postfix/vmailbox</filename></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>virtual_mailbox_base</literal></secondary>"
msgstr ""

msgid ""
"\n"
"# Jean's email is stored as maildir, with\n"
"# one file per email in a dedicated directory\n"
"jean@falcot.org falcot.org/jean/\n"
"# Sophie's email is stored in a traditional \"mbox\" file,\n"
"# with all mails concatenated into one single file\n"
"sophie@falcot.org falcot.org/sophie"
msgstr ""

msgid "Restrictions for Receiving and Sending"
msgstr ""

msgid "The growing number of unsolicited bulk emails (<emphasis>spam</emphasis>) requires being increasingly strict when deciding which emails a server should accept. This section presents some of the strategies included in Postfix."
msgstr ""

msgid "If the reject-rules are too strict, it may happen that even legitimate email traffic gets locked out. It is therefor a good habit to test restrictions and prevent the permanent rejection of requests during this time using the <literal>soft_bounce = yes</literal> directive. By prepending a reject-type directive with <literal>warn_if_reject</literal> only a log message will be recorded instead of rejecting the request."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>soft_bounce</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>warn_if_reject</literal></secondary>"
msgstr ""

msgid "<emphasis>CULTURE</emphasis> The spam problem"
msgstr ""

msgid "<primary>spam</primary>"
msgstr ""

msgid "<primary>unsolicited commercial email</primary><see>spam</see>"
msgstr ""

msgid "“Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be likely discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages. Also every contact found at a compromised system is targeted."
msgstr ""

msgid "All system administrators try to face this nuisance with spam filters, but of course spammers keep adjusting to try to work around these filters. Some even rent networks of machines compromised by a worm from various crime syndicates. Recent statistics estimate that up to 95% of all emails circulating on the Internet are spam!"
msgstr ""

msgid "IP-Based Access Restrictions"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_client_restrictions</literal></secondary>"
msgstr ""

msgid "<primary>email</primary><secondary>filtering on the client host</secondary>"
msgstr ""

msgid "The <literal>smtpd_client_restrictions</literal> directive controls which machines are allowed to communicate with the email server."
msgstr ""

msgid "When a variable contains a list of rules, as in the example below, these rules are evaluated in order, from the first to the last. Each rule can accept the message, reject it, or leave the decision to a following rule. As a consequence, order matters, and simply switching two rules can lead to a widely different behavior."
msgstr ""

msgid "Restrictions Based on Client Address"
msgstr ""

msgid ""
"\n"
"smtpd_client_restrictions =\n"
"    permit_mynetworks,\n"
"    warn_if_reject reject_unknown_client_hostname,\n"
"    check_client_access hash:/etc/postfix/access_clientip,\n"
"    reject_rhsbl_reverse_client dbl.spamhaus.org,\n"
"    reject_rhsbl_reverse_client rhsbl.sorbs.net,\n"
"    reject_rbl_client zen.spamhaus.org,\n"
"    reject_rbl_client dnsbl.sorbs.net"
msgstr ""

msgid "The <literal>permit_mynetworks</literal> directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the <literal>mynetworks</literal> configuration variable)."
msgstr ""

msgid "The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the <literal>warn_if_reject</literal> modifier to the <literal>reject_unknown_client</literal> directive: this modifier <link linkend=\"postfix-safety-net\">turns the rejection into a simple warning recorded in the logs</link>. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_unknown_client_hostname</literal></secondary>"
msgstr ""

msgid "<emphasis>TIP</emphasis> <emphasis>access</emphasis> tables"
msgstr ""

msgid "The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using an uncompressed copy of the <filename>/usr/share/doc/postfix/examples/access.gz</filename> file shipped with the <emphasis role=\"pkg\">postfix-doc</emphasis> package. This model is self-documented in its comments, which means each table describes its own syntax."
msgstr ""

msgid "The <filename>/etc/postfix/access_clientip</filename> table lists IP addresses and networks; <filename>/etc/postfix/access_helo</filename> lists domain names; <filename>/etc/postfix/access_sender</filename> contains sender email addresses. All these files need to be turned into hash-tables (a format optimized for fast access) after each change, with the <command>sudo postmap /etc/postfix/<replaceable>file</replaceable></command> command."
msgstr ""

msgid "The third directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the <filename>/etc/postfix/access_clientip</filename> file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>check_client_access</literal></secondary>"
msgstr ""

msgid "The last four rules reject any message coming from a server listed in one of the indicated blacklists. <acronym>RBL</acronym> is an acronym for <emphasis>Remote Black List</emphasis>, and <acronym>RHSBL</acronym> stands for <emphasis>Right-Hand Side Black List</emphasis>. The difference is, that the former lists IP addresses, whereas the latter lists domain names. There are several such services. They list domains and IP addresses with poor reputation, badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_rbl_client</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_rhsbl_client</literal></secondary>"
msgstr ""

msgid "<emphasis>TIP</emphasis> White list and RBLs"
msgstr ""

msgid "<primary>RBL</primary><see>Remote Black List</see>"
msgstr ""

msgid "<primary>Remote Black List</primary>"
msgstr ""

msgid "Blacklists sometimes include a legitimate server that has been suffering an incident. In these situations, all emails coming from one of these servers would be rejected unless the server is listed in a whitelist defined by <filename>/etc/postfix/access_clientip</filename>."
msgstr ""

msgid "Prudence therefore recommends including in the whitelist(s) all the trusted servers from which many emails are usually received."
msgstr ""

msgid "Checking the Validity of the <literal>EHLO</literal> or <literal>HELO</literal> Commands"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_helo_restrictions</literal></secondary>"
msgstr ""

msgid "<primary>email</primary><secondary>filtering on the mail host</secondary>"
msgstr ""

msgid "Each SMTP exchange starts with a <literal>HELO</literal> (or <literal>EHLO</literal>) command, followed by the name of the sending email server. Checking the validity of this name can be interesting. To fully enforce the restrictions listed in <literal>smtpd_helo_restrictions</literal> the <literal>smtpd_helo_required</literal> option needs to be enabled. Otherwise clients could skip the restrictions by not sending any <literal>HELO</literal>/<literal>EHLO</literal> command."
msgstr ""

msgid "<primary><literal>HELO</literal></primary>"
msgstr ""

msgid "<primary><literal>EHLO</literal></primary><seealso>HELO</seealso>"
msgstr ""

msgid "<primary><literal>SMTP</literal></primary><secondary>HELO</secondary>"
msgstr ""

msgid "<primary><literal>SMTP</literal></primary><secondary>EHLO</secondary>"
msgstr ""

msgid "Restrictions on the name announced in <literal>EHLO</literal>"
msgstr ""

msgid ""
"\n"
"smtpd_helo_required = yes\n"
"smtpd_helo_restrictions =\n"
"    permit_mynetworks,\n"
"    reject_invalid_helo_hostname,\n"
"    reject_non_fqdn_helo_hostname,\n"
"    warn_if_reject reject_unknown_helo_hostname,\n"
"    check_helo_access hash:/etc/postfix/access_helo,\n"
"    reject_rhsbl_helo multi.surbl.org"
msgstr ""

msgid "The first <literal>permit_mynetworks</literal> directive allows all machines on the local network to introduce themselves freely. This is important, because some email programs do not respect this part of the SMTP protocol adequately enough, and they can introduce themselves with nonsensical names."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>permit_mynetworks</literal></secondary>"
msgstr ""

msgid "The <literal>reject_invalid_helo_hostname</literal> rule rejects emails when the <literal>EHLO</literal> announce lists a syntactically incorrect hostname. The <literal>reject_non_fqdn_helo_hostname</literal> rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The <literal>reject_unknown_helo_hostname</literal> rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to too many rejections, the administrators turned its effect to a simple warning with the <literal>warn_if_reject</literal> modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_invalid_helo_hostname</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_non_fqdn_helo_hostname</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_unknown_helo_hostname</literal></secondary>"
msgstr ""

msgid "The <literal>reject_rhsbl_helo</literal> allows to specify a black list to check the hostname against an RHSBL."
msgstr ""

msgid "Using <literal>permit_mynetworks</literal> as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the <literal>falcot.com</literal> network, for instance by adding a <literal>falcot.com REJECT You are not in our network!</literal> line to the <filename>/etc/postfix/access_helo</filename> file."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>check_helo_access</literal></secondary>"
msgstr ""

msgid "Accepting or Refusing Based on the Announced Sender"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_sender_restrictions</literal></secondary>"
msgstr ""

msgid "<primary>email</primary><secondary>filtering on the sender</secondary>"
msgstr ""

msgid "Every message has a sender, announced by the <literal>MAIL FROM</literal> command of the SMTP protocol; again, this information can be validated in several different ways."
msgstr ""

msgid "<primary><literal>MAIL FROM</literal></primary>"
msgstr ""

msgid "<primary><literal>SMTP</literal></primary><secondary>MAIL FROM</secondary>"
msgstr ""

msgid "Sender checks"
msgstr ""

msgid ""
"\n"
"smtpd_sender_restrictions =\n"
"    check_sender_access hash:/etc/postfix/access_sender,\n"
"    reject_unknown_sender_domain,\n"
"    reject_unlisted_sender,\n"
"    reject_non_fqdn_sender,\n"
"    reject_rhsbl_sender rhsbl.sorbs.net"
msgstr ""

msgid "The <filename>/etc/postfix/access_sender</filename> table maps some special treatment to some senders. This usually means listing some senders into a white list or a black list."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>check_sender_access</literal></secondary>"
msgstr ""

msgid "The <literal>reject_unknown_sender_domain</literal> rule requires a valid sender domain, since it is needed for a valid address. The <literal>reject_unlisted_sender</literal> rule rejects local senders if the address does not exist; this prevents emails from being sent from an invalid address in the <literal>falcot.com</literal> domain, and messages emanating from <literal>joe.bloggs@falcot.com</literal> are only accepted if such an address really exists."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_unknown_sender_domain</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_unlisted_sender</literal></secondary>"
msgstr ""

msgid "Finally, the <literal>reject_non_fqdn_sender</literal> rule rejects emails purporting to come from addresses without a fully-qualified domain name. In practice, this means rejecting emails coming from <literal>user@machine</literal>: the address must be announced as either <literal>user@machine.example.com</literal> or <literal>user@example.com</literal>."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_non_fqdn_sender</literal></secondary>"
msgstr ""

msgid "The <literal>reject_rhsbl_sender</literal> rule reject senders based on a (domain-based) RHSBL service."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_rhsbl_sender</literal></secondary>"
msgstr ""

msgid "Accepting or Refusing Based on the Recipient"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_recipient_restrictions</literal></secondary>"
msgstr ""

msgid "<primary>email</primary><secondary>filtering on the recipient</secondary>"
msgstr ""

msgid "Each email has at least one recipient, announced with the <literal>RCPT TO</literal> command in the SMTP protocol. These addresses also warrant validation, even if that may be less relevant than the checks made on the sender address."
msgstr ""

msgid "<primary>RCPT TO</primary>"
msgstr ""

msgid "Recipient checks"
msgstr ""

msgid ""
"\n"
"smtpd_recipient_restrictions =\n"
"    permit_mynetworks,\n"
"    reject_unauth_destination,\n"
"    reject_unlisted_recipient,\n"
"    reject_non_fqdn_recipient,\n"
"    permit"
msgstr ""

msgid "<literal>reject_unauth_destination</literal> is the basic rule that requires outside messages to be addressed to us; messages sent to an address not served by this server are rejected. Without this rule, a server becomes an open relay that allows spammers to send unsolicited emails; this rule is therefore mandatory, and it will be best included near the beginning of the list, so that no other rules may authorize the message before its destination has been checked."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_unauth_destination</literal></secondary>"
msgstr ""

msgid "The <literal>reject_unlisted_recipient</literal> rule rejects messages sent to non-existing local users, which makes sense. Finally, the <literal>reject_non_fqdn_recipient</literal> rule rejects non-fully-qualified addresses; this makes it impossible to send an email to <literal>jean</literal> or <literal>jean@machine</literal>, and requires using the full address instead, such as <literal>jean@machine.falcot.com</literal> or <literal>jean@falcot.com</literal>."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_unlisted_recipient</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_non_fqdn_recipient</literal></secondary>"
msgstr ""

msgid "The <literal>permit</literal> directive at the end is not necessary. But it can be useful at the end of a restriction list to make the default policy explicit."
msgstr ""

msgid "Restrictions Associated with the <literal>DATA</literal> Command"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_data_restrictions</literal></secondary>"
msgstr ""

msgid "<primary>email</primary><secondary>filtering on SMTP commands</secondary>"
msgstr ""

msgid "The <literal>DATA</literal> command of SMTP is emitted before the contents of the message. It doesn't provide any information per se, apart from announcing what comes next. It can still be subjected to checks."
msgstr ""

msgid "<primary><literal>DATA</literal></primary>"
msgstr ""

msgid "<primary><literal>SMTP</literal></primary><secondary>DATA</secondary>"
msgstr ""

msgid "<literal>DATA</literal> checks"
msgstr ""

msgid "smtpd_data_restrictions = reject_unauth_pipelining"
msgstr ""

msgid "The <literal>reject_unauth_pipelining</literal> directives causes the message to be rejected if the sending party sends a command before the reply to the previous command has been sent. This guards against a common optimization used by spammer robots, since they usually don't care a fig about replies and only focus on sending as many emails as possible in as short a time as possible."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>reject_unauth_pipelining</literal></secondary>"
msgstr ""

msgid "Applying Restrictions"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_delay_reject</literal></secondary>"
msgstr ""

msgid "Although the above commands validate information at various stages of the SMTP exchange, Postfix sends the actual rejection as a reply to the <literal>RCPT TO</literal> command by default."
msgstr ""

msgid "This means that even if the message is rejected due to an invalid <literal>EHLO</literal> command, Postfix knows the sender and the recipient when announcing the rejection. It can then log a more explicit message than it could if the transaction had been interrupted from the start. In addition, a number of SMTP clients do not expect failures on the early SMTP commands, and these clients will be less disturbed by this late rejection."
msgstr ""

msgid "A final advantage to this choice is that the rules can accumulate information during the various stages of the SMTP exchange; this allows defining more fine-grained permissions, such as rejecting a non-local connection if it announces itself with a local sender."
msgstr ""

msgid "The default behavior is controlled by the <literal>smtpd_delay_reject</literal> rule."
msgstr ""

msgid "Filtering Based on the Message Contents"
msgstr ""

msgid "<primary>email</primary><secondary>filtering on content inspection</secondary>"
msgstr ""

msgid "<primary>email</primary><secondary>filtering on contents</secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>body_checks</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>header_checks</literal></secondary>"
msgstr ""

msgid "The validation and restriction system would not be complete without a way to apply checks to the message contents. Postfix differentiates the checks applying to the email headers from those applying to the email body."
msgstr ""

msgid "Enabling content-based filters"
msgstr ""

msgid ""
"\n"
"header_checks = regexp:/etc/postfix/header_checks\n"
"body_checks = regexp:/etc/postfix/body_checks"
msgstr ""

msgid "Both files contain a list of regular expressions (commonly known as <emphasis>regexps</emphasis> or <emphasis>regexes</emphasis>) and associated actions to be triggered when the email headers (or body) match the expression."
msgstr ""

msgid "<emphasis>QUICK LOOK</emphasis> Regexp tables"
msgstr ""

msgid "The file <filename>/usr/share/doc/postfix/examples/header_checks.gz</filename> (from the <emphasis role=\"pkg\">postfix-doc</emphasis> package) and <citerefentry><refentrytitle>header_checks</refentrytitle><manvolnum>5</manvolnum></citerefentry> contain many explanatory comments and can be used as a starting point for creating the <filename>/etc/postfix/header_checks</filename> and <filename>/etc/postfix/body_checks</filename> files."
msgstr ""

msgid "Example <filename>/etc/postfix/header_checks</filename> file"
msgstr ""

msgid ""
"\n"
"/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)\n"
"/^Subject: *Your email contains VIRUSES/ DISCARD virus notification"
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> Regular expression"
msgstr ""

#, fuzzy
#| msgid "<primary>Squid</primary>"
msgid "<primary>regular expressions</primary>"
msgstr "<primary>Squid</primary>"

msgid "<primary>regex</primary><see>regular expressions</see>"
msgstr ""

msgid "<primary>regexp</primary><see>regular expressions</see>"
msgstr ""

msgid "The <emphasis>regular expression</emphasis> term (shortened to <emphasis>regexp</emphasis> or <emphasis>regex</emphasis>) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, <literal>foo|bar</literal> matches either “foo” or “bar”), sets of allowed characters (for instance, <literal>[0-9]</literal> means \"any digit\", and <literal>.</literal> — a dot — means \"any character\"), quantification (<literal>s?</literal> matches either <literal>s</literal> or the empty string, in other words 0 or 1 occurrence of <literal>s</literal>; <literal>s+</literal> matches one or more consecutive <literal>s</literal> characters; and so on). Parentheses allow grouping search results."
msgstr ""

msgid "The precise syntax of these expressions varies across the tools using them, but the basic features are similar. <ulink type=\"block\" url=\"https://en.wikipedia.org/wiki/Regular_expression\" />"
msgstr ""

msgid "The first one checks the header mentioning the email software; if <literal>GOTO Sarbacane</literal> (a bulk email software) is found, the message is rejected. The second expression controls the message subject; if it mentions a virus notification, we can decide not to reject the message but to discard it immediately instead."
msgstr ""

msgid "Using these filters is a double-edged sword, because it is easy to make the rules too generic and to lose legitimate emails as a consequence. In these cases, not only the messages will be lost, but their senders will get unwanted (and annoying) error messages."
msgstr ""

msgid "Setting Up <foreignphrase>greylisting</foreignphrase>"
msgstr ""

msgid "<primary>greylisting</primary>"
msgstr ""

msgid "<primary>email</primary><secondary>greylisting</secondary>"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">postgrey</emphasis></primary>"
msgstr ""

msgid "“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted on a further try after some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time."
msgstr ""

msgid "Postfix doesn't provide greylisting natively, but there is a feature by which the decision to accept or reject a given message can be delegated to an external program. The <emphasis role=\"pkg\">postgrey</emphasis> package contains just such a program, designed to interface with this access policy delegation service."
msgstr ""

msgid "Once <emphasis role=\"pkg\">postgrey</emphasis> is installed, it runs as a daemon and listens on port 10023. Postfix can then be configured to use it, by adding the <literal>check_policy_service</literal> parameter as an extra restriction:"
msgstr ""

msgid ""
"\n"
"smtpd_recipient_restrictions =\n"
"    permit_mynetworks,\n"
"    [...]\n"
"    check_policy_service inet:127.0.0.1:10023"
msgstr ""

msgid "Each time Postfix reaches this rule in the ruleset, it will connect to the <command>postgrey</command> daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database."
msgstr ""

msgid "The main disadvantage of greylisting is that legitimate messages get delayed, which is not always acceptable. It also increases the burden on servers that send many legitimate emails."
msgstr ""

msgid "<emphasis>IN PRACTICE</emphasis> Shortcomings of greylisting"
msgstr ""

msgid "Theoretically, greylisting should only delay the first mail from a given sender to a given recipient, and the typical delay is in the order of minutes. Reality, however, can differ slightly. Some large ISPs use clusters of SMTP servers, and when a message is initially rejected, the server that retries the transmission may not be the same as the initial one. When that happens, the second server gets a temporary error message due to greylisting too, and so on; it may take several hours until transmission is attempted by a server that has already been involved, since SMTP servers usually increase the delay between retries at each failure."
msgstr ""

msgid "As a consequence, the incoming IP address may vary in time even for a single sender. But it goes further: even the sender address can change. For instance, many mailing-list servers encode extra information in the sender address so as to be able to handle error messages (known as <emphasis>bounces</emphasis>). Each new message sent to a mailing-list may then need to go through greylisting, which means it has to be stored (temporarily) on the sender's server. For very large mailing-lists (with tens of thousands of subscribers), this can soon become a problem."
msgstr ""

msgid "To mitigate these drawbacks, Postgrey manages a whitelist of such sites, and messages emanating from them are immediately accepted without going through greylisting. This list can easily be adapted to local needs, since it is stored in the <filename>/etc/postgrey/whitelist_clients</filename> file."
msgstr ""

msgid "<emphasis>GOING FURTHER</emphasis> Selective greylisting with <emphasis role=\"pkg\">milter-greylist</emphasis>"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">milter-greylist</emphasis></primary>"
msgstr ""

msgid "The drawbacks of greylisting can be mitigated by only using greylisting on the subset of clients that are already considered as probable sources of spam (because they are listed in a DNS blacklist). This is not possible with <emphasis role=\"pkg\">postgrey</emphasis> but <emphasis role=\"pkg\">milter-greylist</emphasis> can be used in such a way."
msgstr ""

msgid "In that scenario, since DNS blacklists never triggers a definitive rejection, it becomes reasonable to use aggressive blacklists, including those listing all dynamic IP addresses from ISP clients (such as <literal>pbl.spamhaus.org</literal> or <literal>dul.dnsbl.sorbs.net</literal>)."
msgstr ""

msgid "Since <emphasis role=\"pkg\">milter-greylist</emphasis> uses Sendmail's milter interface, the postfix side of its configuration is limited to “<literal>smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock</literal>”. The <citerefentry><refentrytitle>greylist.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> manual page documents <filename>/etc/milter-greylist/greylist.conf</filename> and the numerous ways to configure milter-greylist. You will also have to edit <filename>/etc/default/milter-greylist</filename> to actually enable the service."
msgstr ""

msgid "Customizing Filters Based On the Recipient"
msgstr ""

msgid "<primary>email</primary><secondary>custom restriction classes</secondary>"
msgstr ""

msgid "<xref linkend=\"sect.restrictions-for-receiving-and-sending\" /> and <xref linkend=\"sect.setting-up-greylisting\" /> reviewed many of the possible restrictions. They all have their use in limiting the amount of received spam, but they also all have their drawbacks. It is therefore more and more common to customize the set of filters depending on the recipient. At Falcot Corp, greylisting is interesting for most users, but it hinders the work of some users who need low latency in their emails (such as the technical support service). Similarly, the commercial service sometimes has problems receiving emails from some Asian providers who may be listed in blacklists; this service asked for a non-filtered address so as to be able to correspond."
msgstr ""

msgid "Postfix provides such a customization of filters with a “restriction class” concept. The classes are declared in the <literal>smtpd_restriction_classes</literal> parameter, and defined the same way as <literal>smtpd_recipient_restrictions</literal>. The <literal>check_recipient_access</literal> directive then defines a table mapping a given recipient to the appropriate set of restrictions."
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_restriction_classes</literal></secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>check_recipient_access</literal></secondary>"
msgstr ""

msgid "Defining restriction classes in <filename>main.cf</filename>"
msgstr ""

msgid ""
"smtpd_restriction_classes = greylisting, aggressive, permissive\n"
"\n"
"greylisting = check_policy_service inet:127.0.0.1:10023\n"
"aggressive =\n"
"        reject_rbl_client sbl-xbl.spamhaus.org,\n"
"        check_policy_service inet:127.0.0.1:10023\n"
"permissive = permit\n"
"\n"
"smtpd_recipient_restrictions =\n"
"        permit_mynetworks,\n"
"        reject_unauth_destination,\n"
"        check_recipient_access hash:/etc/postfix/recipient_access"
msgstr ""

msgid "The <filename>/etc/postfix/recipient_access</filename> file"
msgstr ""

msgid ""
"\n"
"# Unfiltered addresses\n"
"postmaster@falcot.com  permissive\n"
"support@falcot.com     permissive\n"
"sales-asia@falcot.com  permissive\n"
"\n"
"# Aggressive filtering for some privileged users\n"
"joe@falcot.com         aggressive\n"
"\n"
"# Special rule for the mailing-list manager\n"
"sympa@falcot.com       reject_unverified_sender\n"
"\n"
"# Greylisting by default\n"
"falcot.com             greylisting"
msgstr ""

msgid "Integrating an Antivirus"
msgstr ""

msgid "<primary>antivirus</primary>"
msgstr ""

msgid "<primary>email</primary><secondary>virus scanning</secondary>"
msgstr ""

msgid "The many viruses circulating as attachments to emails make it important to set up an antivirus at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages."
msgstr ""

msgid "<emphasis>SECURITY</emphasis> Controversial Discussion of Anti-Virus Software"
msgstr ""

msgid "The usage of virus scanners, or so called antivirus software, is controversial. There is usually a gap between the release of some piece of malware and the addition of detection rules to the antivirus database. During this gap, there is no software-based protection. Further, the usage often requires to run additional software, for example, to uncompress archives and scan all kinds of executables, which drastically increases the exploit potential of the antivirus software itself. Usage of such software solutions can therefor never replace awareness campaigns and simple behavioral rules (never open unsolicited sent attachments, etc.)."
msgstr ""

msgid "<primary>antivirus</primary><secondary>controversy</secondary>"
msgstr ""

msgid "The Falcot administrators selected <command>clamav</command> for their free antivirus. The main package is <emphasis role=\"pkg\">clamav</emphasis>, but they also installed a few extra packages such as <emphasis role=\"pkg\">arj</emphasis>, <emphasis role=\"pkg\">unzoo</emphasis>, <emphasis role=\"pkg\">unrar</emphasis> and <emphasis role=\"pkg\">lha</emphasis>, since they are required for the antivirus to analyze attachments archived in one of these formats."
msgstr ""

msgid "<primary><command>clamav</command></primary>"
msgstr ""

msgid "<primary><command>clamav-milter</command></primary>"
msgstr ""

msgid "The task of interfacing between antivirus and the email server goes to <command>clamav-milter</command>. A <emphasis>milter</emphasis> (short for <emphasis>mail filter</emphasis>) is a filtering program specially designed to interface with email servers. A milter uses a standard application programming interface (API) that provides much better performance than filters external to the email servers. Milters were initially introduced by <emphasis>Sendmail</emphasis>, but <emphasis>Postfix</emphasis> soon followed suit."
msgstr ""

msgid "<emphasis>QUICK LOOK</emphasis> A milter for Spamassassin"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">spamassassin</emphasis></primary>"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">spamass-milter</emphasis></primary>"
msgstr ""

msgid "The <emphasis role=\"pkg\">spamass-milter</emphasis> package provides a milter based on <emphasis>SpamAssassin</emphasis>, the famous unsolicited email detector. It can be used to flag messages as probable spams (by adding an extra header) and/or to reject the messages altogether if their “spamminess” score goes beyond a given threshold."
msgstr ""

msgid "Once the <emphasis role=\"pkg\">clamav-milter</emphasis> package is installed, the milter should be reconfigured to run on a TCP port rather than on the default named socket. This can be achieved with <command>dpkg-reconfigure clamav-milter</command>. When prompted for the “Communication interface with Sendmail”, answer “<literal>inet:10002@127.0.0.1</literal>”."
msgstr ""

msgid "<emphasis>NOTE</emphasis> Real TCP port vs named socket"
msgstr ""

msgid "The reason why we use a real TCP port rather than the named socket is that the postfix daemons often run chrooted and do not have access to the directory hosting the named socket. You could also decide to keep using a named socket and pick a location within the chroot (<filename>/var/spool/postfix/</filename>)."
msgstr ""

msgid "The standard ClamAV configuration fits most situations, but some important parameters can still be customized with <command>dpkg-reconfigure clamav-base</command>."
msgstr ""

msgid "The last step involves telling Postfix to use the recently-configured filter. This is a simple matter of adding the following directive to <filename>/etc/postfix/main.cf</filename>:"
msgstr ""

msgid ""
"\n"
"# Virus check with clamav-milter\n"
"smtpd_milters = inet:[127.0.0.1]:10002"
msgstr ""

msgid "If the antivirus causes problems, this line can be commented out, and <command>systemctl reload postfix</command> should be run so that this change is taken into account."
msgstr ""

msgid "<emphasis>IN PRACTICE</emphasis> Testing the antivirus"
msgstr ""

msgid "Once the antivirus is set up, its correct behavior should be tested. The simplest way to do that is to send a test email with an attachment containing the <filename>eicar.com</filename> (or <filename>eicar.com.zip</filename>) file, which can be downloaded online: <ulink type=\"block\" url=\"https://2016.eicar.org/86-0-Intended-use.html\" />"
msgstr ""

msgid "This file is not a true virus, but a test file that all antivirus software on the market diagnose as a virus to allow checking installations."
msgstr ""

msgid "All messages handled by Postfix now go through the antivirus filter."
msgstr ""

msgid "Fighting Spam with SPF, DKIM and DMARC"
msgstr ""

msgid "The high number of unsolicited email sent every day led to the creation of several standards, which aim at validating, that the sending host of an email is authorized and that the email has not been tampered with. The following systems are all DNS-based and require the administrators to not only have control over the mail server, but over the DNS for the domain in question too."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Controversial Discussion"
msgstr ""

msgid "Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefor these rules are often applied as a \"soft fail\" or a \"soft reject\", which usually means, that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards \"broken by design\". Decide for yourself and be careful about how strict you choose to apply these standards."
msgstr ""

msgid "Integrating the Sender Policy Framework (SPF)"
msgstr ""

msgid "<primary>SPF</primary><see>Sender Policy Framework</see>"
msgstr ""

#, fuzzy
#| msgid "<primary>proxy cache</primary>"
msgid "<primary>Sender Policy Framework </primary>"
msgstr "<primary>proxy cache</primary>"

msgid "<primary><emphasis role=\"pkg\">postfix-policyd-spf-python</emphasis></primary>"
msgstr ""

msgid "The Sender Policy Framework (<acronym>SPF</acronym>) is used to validate if a certain mail server is allowed to send emails for a given domain. It is mostly configured through DNS. The syntax for the entry to make is explained in Detail at: <ulink type=\"block\" url=\"https://web.archive.org/web/20190224184030/http://www.openspf.org/SPF_Record_Syntax\">http://www.openspf.org/SPF_Record_Syntax<footnote> <para>The <literal>openspf.org</literal> website disappeared in February 2019 for no obvious reason. The contents are still accessible at <ulink url=\"https://web.archive.org/web/20190224184030/http://www.openspf.org/SPF_Record_Syntax\" />.</para> </footnote></ulink> <ulink type=\"block\" url=\"https://tools.ietf.org/html/rfc7208\" /> <ulink type=\"block\" url=\"https://en.wikipedia.org/wiki/Sender_Policy_Framework\" />"
msgstr ""

msgid "The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to email the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the <literal>include</literal> directive it must have one."
msgstr ""

msgid ""
"<![CDATA[\n"
"Name: example.org\n"
"Type: TXT\n"
"TTL:  3600\n"
"Data: v=spf1 a mx -all\n"
"]]>"
msgstr ""

msgid "Let's take a quick look at the <literal>falcot.org</literal> entry."
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>host -t TXT falcot.org</userinput><computeroutput><![CDATA[\n"
"falcot.org descriptive text \"v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all\"]]></computeroutput>"
msgstr ""

msgid "It states, that the IP of the sender must match the A record for the sending domain, or must be listed as one of the Mail Exchange Resource Records for the current domain, or must be one of the three mentioned IP4 addresses. All other hosts should be marked as not being allowed to send email for the sender domain. The latter is called a \"soft fail\" and is intended to mark the email accordingly, but still accept it."
msgstr ""

msgid "The <command>postfix</command> mail server can check the SPF record for incoming emails using the <emphasis role=\"pkg\">postfix-policyd-spf-python</emphasis> package, a policy agent written in Python. The file <filename>/usr/share/doc/postfix-policyd-spf-python/README.Debian</filename> describes the necessary steps to integrate the agent into postfix, so we won't repeat it here."
msgstr ""

msgid "<primary>Postfix</primary><secondary>SPF</secondary>"
msgstr ""

msgid "The configuration is done in the file <filename>/etc/postfix-policyd-spf-python/policyd-spf.conf</filename>, which is fully documented in <citerefentry><refentrytitle>policyd-spf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> and <filename>/usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz</filename>. The main configuration parameters are <literal>HELO_reject</literal> and <literal>Mail_From_reject</literal>, which configure if emails should be rejected (<literal>Fail</literal>) or accepted with a header being appended (<literal>False</literal>), if checks fail. The latter is often useful, when the message is further processed by a spam filter."
msgstr ""

msgid "If the result is intended to be used by <emphasis role=\"pkg\">opendmarc</emphasis> (<xref linkend=\"sect.dmarc\" />), then <literal>Header_Type</literal> must be set to <literal>AR</literal>."
msgstr ""

msgid "Note, that <emphasis role=\"pkg\">spamassassin</emphasis> contains a plugin to check the SPF record."
msgstr ""

msgid "<primary>spamassassin</primary><secondary>SPF</secondary>"
msgstr ""

msgid "Integrating DomainKeys (DKIM) Signing and Checking"
msgstr ""

msgid "<primary>DKIM</primary><see>DomainKeys Identified Mail</see>"
msgstr ""

#, fuzzy
#| msgid "<primary>proxy cache</primary>"
msgid "<primary>DomainKeys Identified Mail</primary>"
msgstr "<primary>proxy cache</primary>"

msgid "<primary><emphasis role=\"pkg\">opendkim</emphasis></primary>"
msgstr ""

msgid "The Domain Keys Identified Mail (<acronym>DKIM</acronym>) standard is a sender authentication system. The mail transport agent, here <command>postfix</command>, adds a digital signature associated with the domain name to the header of outgoing emails. The receiving party can validate the message body and header fields by checking the signature against a public key, which is retrieved from the senders DNS records. <ulink type=\"block\" url=\"http://dkim.org/\" />"
msgstr ""

msgid "The necessary tools are shipped with the <emphasis role=\"pkg\">opendkim</emphasis> and <emphasis role=\"pkg\">opendkim-tools</emphasis> packages."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Mailing List Software and DKIM"
msgstr ""

msgid "Mailing list managers often rewrite some email headers, thus leading to invalid DKIM signatures. Even using a <literal>relaxed</literal> canonicalization does not always prevent this from happening. So the administrators must pay close attention to the mail severs log files to identify such issues. Otherwise such emails might be flagged as spam and might get rejected."
msgstr ""

msgid "<primary>DomainKeys Identified Mail</primary><secondary>mailing list problems</secondary>"
msgstr ""

msgid "First the private key must be created using the command <command>opendkim-genkey -s <replaceable>SELECTOR</replaceable> -d <replaceable>DOMAIN</replaceable></command>. <replaceable>SELECTOR</replaceable> must be a unique name for the key. It can be as simple as \"mail\" or the date of creation, if you plan to rotate keys."
msgstr ""

msgid "<primary><emphasis role=\"pkg\">opendkim</emphasis></primary><secondary>opendkim-genkey</secondary>"
msgstr ""

msgid "Create a private key for signing E-Mails from falcot.com"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys</userinput>\n"
"<computeroutput># </computeroutput><userinput>chown opendkim.opendkim /etc/dkimkeys/mail.*</userinput>"
msgstr ""

msgid "This will create the files <filename>/etc/dkimkeys/mail.private</filename> and <filename>/etc/dkimkeys/mail.txt</filename> and set the appropriate ownership. The first file contains the private key and the latter the public key, that needs to be added to the DNS:"
msgstr ""

msgid ""
"<![CDATA[\n"
"Name: mail._domainkey\n"
"Type: TXT\n"
"TTL:  3600\n"
"Data: \"v=DKIM1; h=sha256; k=rsa; s=email; p=[...]\"\n"
"]]>"
msgstr ""

msgid "The <emphasis role=\"pkg\">opendkim</emphasis> package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option <command>-b 1024</command> to chose a smaller keysize. If <command>opendkim-testkey</command> succeeds, the entry has been successfully set up. The syntax of the entry is explained here: <ulink type=\"block\" url=\"https://tools.ietf.org/html/rfc6376\" /> <ulink type=\"block\" url=\"https://en.wikipedia.org/wiki/DKIM\" />"
msgstr ""

msgid "To configure <emphasis role=\"pkg\">opendkim</emphasis>, <literal>SOCKET</literal> and <literal>RUNDIR</literal> must be chosen in <filename>/etc/default/opendkim</filename>. Please note that <literal>SOCKET</literal> must be accessible from <literal>postfix</literal> in its chrooted environment. The further configuration is done in <filename>/etc/opendkim.conf</filename>. The following is a configuration excerpt, which makes sure that the <literal>Domain</literal> \"falcot.com\" and all subdomains (<literal>SubDomain</literal>) are signed by the <literal>Selector</literal> \"mail\" and the single private key (<literal>KeyFile</literal>) <filename>/etc/dkimkeys/mail.private</filename>. The \"relaxed\" <literal>Canonicalization</literal> for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing (\"s\") and verification (\"v\") <literal>Mode</literal>. If a signature fails to validate (<literal>On-BadSignature</literal>), the mail should be quarantined (\"q\")."
msgstr ""

msgid ""
"<![CDATA[\n"
"[...]\n"
"Domain                  falcot.com\n"
"KeyFile                 /etc/dkimkeys/mail.private\n"
"Selector                mail\n"
"\n"
"[...]\n"
"Canonicalization        relaxed/relaxed\n"
"Mode                    sv\n"
"On-BadSignature         q\n"
"SubDomains              yes\n"
"\n"
"[...]\n"
"Socket                  inet:12345@localhost\n"
"\n"
"[...]\n"
"UserID                  opendkim\n"
"]]>"
msgstr ""

msgid "It is also possible to use multiple selectors/keys (<literal>KeyTable</literal>), domains (<literal>SigningTable</literal>) and to specify internal or trusted hosts (<literal>InternalHosts</literal>, <literal>ExternalIgnoreList</literal>), which may send mail through the server as one of the signing domains without credentials."
msgstr ""

msgid "The following directives in <filename>/etc/postfix/main.cf</filename> make <literal>postfix</literal> use the filter:"
msgstr ""

msgid "<primary>Postfix</primary><secondary>DKIM</secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_milters</literal></secondary><tertiary>DKIM</tertiary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>non_smtpd_milters</literal></secondary><tertiary>DKIM</tertiary>"
msgstr ""

msgid ""
"<![CDATA[\n"
"milter_default_action = accept\n"
"non_smtpd_milters = inet:localhost:12345\n"
"smtpd_milters = inet:localhost:12345\n"
"]]>"
msgstr ""

msgid "To differentiate signing and verification it is sometimes more useful to add the directives to the services in <filename>/etc/postfix/master.cf</filename> instead."
msgstr ""

msgid "More information is available in the <filename>/usr/share/doc/opendkim/</filename> directory and the manual pages <citerefentry><refentrytitle>opendkim</refentrytitle> <manvolnum>8</manvolnum></citerefentry> and <citerefentry><refentrytitle>opendkim.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>."
msgstr ""

msgid "Note that <emphasis role=\"pkg\">spamassassin</emphasis> contains a plugin to check the DKIM record."
msgstr ""

msgid "<primary>spamassassin</primary><secondary>DKIM</secondary>"
msgstr ""

msgid "Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)"
msgstr ""

msgid "<primary>DMARC</primary><see>Domain-based Message Authentication, Reporting and Conformance</see>"
msgstr ""

msgid "<primary>Domain-based Message Authentication, Reporting and Conformance</primary>"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">opendmarc</emphasis></primary>"
msgstr ""

msgid "The Domain-based Message Authentication, Reporting and Conformance (<acronym>DMARC</acronym>) standard can be used to define a DNS TXT entry with the name <literal>_dmarc</literal> and the action, that should be taken, when emails, which contain your domain as sending host, fail to validate using DKIM and SPF. <ulink type=\"block\" url=\"https://dmarc.org/overview/\" />"
msgstr ""

msgid "Let's have a look at the entries of two large providers:"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>host -t TXT _dmarc.gmail.com</userinput><computeroutput><![CDATA[\n"
"_dmarc.gmail.com descriptive text \"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com\"]]></computeroutput>\n"
"<computeroutput># </computeroutput><userinput>host -t TXT _dmarc.yahoo.com</userinput><computeroutput><![CDATA[\n"
"_dmarc.yahoo.com descriptive text \"v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;\"]]></computeroutput>"
msgstr ""

msgid "Yahoo has a strict policy to <literal>reject</literal> all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (<literal>p=none</literal>). For subdomains they should be marked as spam (<literal>sp=quarantine</literal>). The addresses given in the <literal>rua</literal> key can be used to send aggregated DMARC reports to. The full syntax is explained here: <ulink type=\"block\" url=\"https://tools.ietf.org/html/rfc7489\" /> <ulink type=\"block\" url=\"https://en.wikipedia.org/wiki/DMARC\" />"
msgstr ""

msgid "The <command>postfix</command> mail server can use this information too. The <emphasis role=\"pkg\">opendmarc</emphasis> package contains the necessary milter. Similar to <emphasis role=\"pkg\">opendkim</emphasis> <literal>SOCKET</literal> and <literal>RUNDIR</literal> must be chosen in <filename>/etc/default/opendmarc</filename> (for Unix sockets you must make sure, that they are inside the postfix chroot to be found). The configuration file <filename>/etc/opendmarc.conf</filename> contains detailed comments and is also explained in <citerefentry><refentrytitle>opendmarc.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>. By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use <literal>RejectFailures true</literal>."
msgstr ""

msgid "The milter is then added to <literal>smtpd_milters</literal> and <literal>non_smtpd_milters</literal>. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in <filename>/etc/postfix/main.cf</filename> looks like this:"
msgstr ""

msgid "<primary>Postfix</primary><secondary>DMARC</secondary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>smtpd_milters</literal></secondary><tertiary>DMARC</tertiary>"
msgstr ""

msgid "<primary>Postfix</primary><secondary><literal>non_smtpd_milters</literal></secondary><tertiary>DMARC</tertiary>"
msgstr ""

msgid ""
"<![CDATA[\n"
"non_smtpd_milters = inet:localhost:12345,inet:localhost:54321\n"
"smtpd_milters = inet:localhost:12345,inet:localhost:54321\n"
"]]>"
msgstr ""

msgid "The milter can also be selectively applied to a service in <filename>/etc/postfix/master.cf</filename> instead."
msgstr ""

msgid "Authenticated SMTP"
msgstr ""

msgid "Being able to send emails requires an SMTP server to be reachable; it also requires said SMTP server to send emails through it. For roaming users, this may need regularly changing the configuration of the SMTP client, since Falcot's SMTP server rejects messages coming from IP addresses apparently not belonging to the company. Two solutions exist: either the roaming user installs an SMTP server on their computer, or they still use the company server with some means of authenticating as an employee. The former solution is not recommended since the computer won't be permanently connected, and it won't be able to retry sending messages in case of problems; we will focus on the latter solution."
msgstr ""

msgid "SMTP authentication in Postfix relies on SASL (<emphasis>Simple Authentication and Security Layer</emphasis>). It requires installing the <emphasis role=\"pkg\">libsasl2-modules</emphasis> and <emphasis role=\"pkg\">sasl2-bin</emphasis> packages, then registering a password in the SASL database for each user that needs authenticating on the SMTP server. This is done with the <command>saslpasswd2</command> command, which takes several parameters. The <literal>-u</literal> option defines the authentication domain, which must match the <literal>smtpd_sasl_local_domain</literal> parameter in the Postfix configuration. The <literal>-c</literal> option allows creating a user, and <literal>-f</literal> allows specifying the file to use if the SASL database needs to be stored at a different location than the default (<filename>/etc/sasldb2</filename>)."
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean</userinput>\n"
"<computeroutput>[... type jean's password twice ...]</computeroutput>"
msgstr ""

msgid "Note that the SASL database was created in Postfix's directory. In order to ensure consistency, we also turn <filename>/etc/sasldb2</filename> into a symbolic link pointing at the database used by Postfix, with the <command>ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2</command> command."
msgstr ""

msgid "Now we need to configure Postfix to use SASL. First the <literal>postfix</literal> user needs to be added to the <literal>sasl</literal> group, so that it can access the SASL account database. A few new parameters are also needed to enable SASL, and the <literal>smtpd_recipient_restrictions</literal> parameter needs to be configured to allow SASL-authenticated clients to send emails freely."
msgstr ""

msgid "Enabling SASL in <filename>/etc/postfix/main.cf</filename>"
msgstr ""

msgid ""
"\n"
"# Enable SASL authentication\n"
"smtpd_sasl_auth_enable = yes\n"
"# Define the SASL authentication domain to use\n"
"smtpd_sasl_local_domain = $myhostname\n"
"[...]\n"
"# Adding permit_sasl_authenticated before reject_unauth_destination\n"
"# allows relaying mail sent by SASL-authenticated users\n"
"smtpd_recipient_restrictions =\n"
"    permit_sasl_authenticated,\n"
"    permit_mynetworks,\n"
"    reject_unauth_destination,\n"
"[...]"
msgstr ""

msgid "It is usually a good idea to not send passwords over an unencrypted connection. <emphasis>Postfix</emphasis> allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the <filename>/etc/postfix/master.cf</filename> file. To turn off authentication at all for port 25 (<literal>smtpd</literal> service) add the following directive:"
msgstr ""

msgid ""
"<![CDATA[smtp      inet  n       -       y       -       -       smtpd\n"
"    [..]\n"
"    -o smtpd_sasl_auth_enable=no\n"
"    [..]\n"
"]]>"
msgstr ""

msgid "If for some reason clients use an outdated <literal>AUTH</literal> command (some very old mail clients do), interoperability with them can be enabled using the <literal>broken_sasl_auth_clients</literal> directive."
msgstr ""

msgid "<emphasis>EXTRA</emphasis> Authenticated SMTP client"
msgstr ""

msgid "Most email clients are able to authenticate to an SMTP server before sending outgoing messages, and using that feature is a simple matter of configuring the appropriate parameters. If the client in use does not provide that feature, the workaround is to use a local Postfix server and configure it to relay email via the remote SMTP server. In this case, the local Postfix itself will be the client that authenticates with SASL. Here are the required parameters:"
msgstr ""

msgid ""
"\n"
"smtp_sasl_auth_enable = yes\n"
"smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd\n"
"relay_host = [mail.falcot.com]"
msgstr ""

msgid "The <filename>/etc/postfix/sasl_passwd</filename> file needs to contain the username and password to use for authenticating on the <literal>mail.falcot.com</literal> server. Here is an example:"
msgstr ""

msgid ""
"\n"
"[mail.falcot.com]   joe:LyinIsji"
msgstr ""

msgid "As for all Postfix maps, this file must be turned into <filename>/etc/postfix/sasl_passwd.db</filename> with the <command>postmap</command> command."
msgstr ""

msgid "Web Server (HTTP)"
msgstr ""

msgid "The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian <emphasis role=\"distribution\">Buster</emphasis> at version 2.4.38."
msgstr ""

msgid "<primary><command>apache</command></primary>"
msgstr ""

msgid "<primary>server</primary><secondary>web</secondary>"
msgstr ""

msgid "<primary>web server</primary><seealso>Apache</seealso>"
msgstr ""

msgid "<primary>server</primary><secondary>HTTP</secondary>"
msgstr ""

msgid "<primary>HTTP</primary><secondary>server</secondary><seealso>Apache</seealso>"
msgstr ""

msgid "<emphasis>ALTERNATIVE</emphasis> Other web servers"
msgstr ""

msgid "Apache is merely the most widely-known (and widely-used) web server, but there are others; they can offer better performance under certain workloads, but this has its counterpart in the smaller number of available features and modules. However, when the prospective web server is built to serve static files or to act as a proxy, the alternatives, such as <emphasis role=\"pkg\">nginx</emphasis> and <emphasis role=\"pkg\">lighttpd</emphasis>, are worth investigating."
msgstr ""

msgid "<primary><emphasis role=\"pkg\">nginx</emphasis></primary>"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">lighttpd</emphasis></primary>"
msgstr ""

msgid "Installing Apache"
msgstr ""

msgid "<primary><command>Apache</command></primary><secondary>installation</secondary>"
msgstr ""

msgid "Installing the <emphasis role=\"pkg\">apache2</emphasis> package is all that is needed. It contains all the modules, including the <emphasis>Multi-Processing Modules</emphasis> (MPMs) that affect how Apache handles parallel processing of many requests, which used to be provided in separate <emphasis role=\"pkg\">apache2-mpm-*</emphasis> packages. It will also pull <emphasis role=\"pkg\">apache2-utils</emphasis> containing the command line utilities that we will discover later."
msgstr ""

msgid "The MPM in use affects significantly the way Apache will handle concurrent requests. With the <emphasis>worker</emphasis> MPM, it uses <emphasis>threads</emphasis> (lightweight processes), whereas with the <emphasis>prefork</emphasis> MPM it uses a pool of processes created in advance. With the <emphasis>event</emphasis> MPM it also uses threads, but the inactive connections (notably those kept open by the HTTP <emphasis>keep-alive</emphasis> feature) are handed back to a dedicated management thread."
msgstr ""

msgid "The Falcot administrators also install <emphasis role=\"pkg\">libapache2-mod-php7.3</emphasis> so as to include the PHP support in Apache. This causes the default <emphasis>event</emphasis> MPM to be disabled, and <emphasis>prefork</emphasis> to be used instead. To use the <emphasis>event</emphasis> MPM one can use <emphasis role=\"pkg\">php7.3-fpm</emphasis>."
msgstr ""

msgid "<emphasis>SECURITY</emphasis> Execution under the <literal>www-data</literal> user"
msgstr ""

msgid "<primary><literal>www-data</literal></primary>"
msgstr ""

msgid "<primary>suexec</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>www-data</literal>, user</secondary>"
msgstr ""

msgid "By default, Apache handles incoming requests under the identity of the <literal>www-data</literal> user. This means that a security vulnerability in a CGI script executed by Apache (for a dynamic page) won't compromise the whole system, but only the files owned by this particular user."
msgstr ""

msgid "Using the <emphasis>suexec</emphasis> modules, provided by <emphasis role=\"pkg\">apache2-suexec-*</emphasis> packages, allows bypassing this rule so that some CGI scripts are executed under the identity of another user. This is configured with a <literal>SuexecUserGroup <replaceable>user</replaceable><replaceable>group</replaceable></literal> directive in the Apache configuration."
msgstr ""

msgid "<primary><emphasis role=\"pkg\">libapache2-mpm-itk</emphasis></primary>"
msgstr ""

msgid "Another possibility is to use a dedicated MPM, such as the one provided by <emphasis role=\"pkg\">libapache2-mpm-itk</emphasis>. This particular one has a slightly different behavior: it allows “isolating” virtual hosts (actually, sets of pages) so that they each run as a different user. A vulnerability in one website therefore cannot compromise files belonging to the owner of another website."
msgstr ""

msgid "<emphasis>QUICK LOOK</emphasis> List of modules"
msgstr ""

msgid "The full list of Apache standard modules can be found online. <ulink type=\"block\" url=\"https://httpd.apache.org/docs/2.4/mod/index.html\" />"
msgstr ""

msgid "Apache is a modular server, and many features are implemented by external modules that the main program loads during its initialization. The default configuration only enables the most common modules, but enabling new modules is a simple matter of running <command>a2enmod <replaceable>module</replaceable></command>; to disable a module, the command is <command>a2dismod <replaceable>module</replaceable></command>. These programs actually only create (or delete) symbolic links in <filename>/etc/apache2/mods-enabled/</filename>, pointing at the actual files (stored in <filename>/etc/apache2/mods-available/</filename>)."
msgstr ""

msgid "<primary>Apache</primary><secondary><filename>/etc/apache2/mods-available</filename></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><filename>/etc/apache2/mods-enabled</filename></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><command>a2enmod</command></secondary>"
msgstr ""

msgid "<emphasis>IN PRACTICE</emphasis> Checking the configuration"
msgstr ""

msgid "<primary>Apache</primary><secondary>mod_info</secondary>"
msgstr ""

msgid "The <literal>mod_info</literal> module (<command>a2enmod info</command>) allows to access the comprehensive Apache server configuration and information via browser visiting <literal>http://localhost/server-info</literal>. Because it might contain sensitive information, access is only allowed from the local host by default. <ulink type=\"block\" url=\"https://httpd.apache.org/docs/2.4/mod/mod_info.html\" />"
msgstr ""

msgid "With its default configuration, the web server listens on port 80 (as configured in <filename>/etc/apache2/ports.conf</filename>), and serves pages from the <filename>/var/www/html/</filename> directory (as configured in <filename>/etc/apache2/sites-enabled/000-default.conf</filename>)."
msgstr ""

msgid "Adding support for SSL"
msgstr ""

msgid "<primary>HTTPS</primary>"
msgstr ""

msgid "<primary>HTTP</primary><secondary>secure</secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary>SSL</secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary>mod_ssl</secondary>"
msgstr ""

msgid "Apache 2.4 includes the SSL module (<literal>mod_ssl</literal>) required for secure HTTP (HTTPS) out of the box. It just needs to be enabled with <command>a2enmod ssl</command>, then the required directives have to be added to the configuration files. A configuration example is provided in <filename>/etc/apache2/sites-available/default-ssl.conf</filename>. <ulink type=\"block\" url=\"https://httpd.apache.org/docs/2.4/mod/mod_ssl.html\" />"
msgstr ""

msgid "If you want to generate trusted certificates, you can follow section <xref linkend=\"sect.trusted-certs\" /> and then adjust the following variables:"
msgstr ""

msgid ""
"\n"
"SSLCertificateFile      /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/fullchain.pem\n"
"SSLCertificateKeyFile   /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/privkey.pem\n"
"SSLCertificateChainFile /etc/letsencrypt/live/<replaceable>DOMAIN</replaceable>/chain.pem\n"
"SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt"
msgstr ""

msgid "Some extra care must be taken if you want to favor SSL connections with <emphasis>Perfect Forward Secrecy</emphasis> (those connections use ephemeral session keys ensuring that a compromission of the server's secret key does not result in the compromission of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular: <ulink type=\"block\" url=\"https://wiki.mozilla.org/Security/Server_Side_TLS#Apache\" />"
msgstr ""

msgid "<primary><emphasis>Perfect Forward Secrecy</emphasis></primary>"
msgstr ""

msgid "As an alternative to the standard SSL module, there is an extension module called <literal>mod_gnutls</literal>, which is shipped with the <emphasis role=\"pkg\">libapache2-mod-gnutls</emphasis> package and enabled with the <command>a2enmod gnutls</command>. <ulink type=\"block\" url=\"https://mod.gnutls.org/\" />"
msgstr ""

msgid "<primary>Apache</primary><secondary>mod_gnutls</secondary>"
msgstr ""

msgid "Configuring Virtual Hosts"
msgstr ""

msgid "<primary>Apache</primary><secondary>Virtual Hosts</secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>VirtualHost</literal></secondary>"
msgstr ""

msgid "A virtual host is an extra identity for the web server."
msgstr ""

msgid "<primary>virtual host</primary>"
msgstr ""

msgid "Apache considers two different kinds of virtual hosts: those that are based on the IP address (or the port), and those that rely on the domain name of the web server. The first method requires allocating a different IP address (or port) for each site, whereas the second one can work on a single IP address (and port), and the sites are differentiated by the hostname sent by the HTTP client (which only works in version 1.1 of the HTTP protocol — fortunately that version is old enough that all clients use it already)."
msgstr ""

msgid "The (increasing) scarcity of IPv4 addresses usually favors the second method; however, it is made more complex if the virtual hosts need to provide HTTPS too, since the SSL protocol hasn't always provided for name-based virtual hosting; the SNI extension (<emphasis>Server Name Indication</emphasis>) that allows such a combination is not handled by all browsers. When several HTTPS sites need to run on the same server, they will usually be differentiated either by running on a different port or on a different IP address (IPv6 can help there)."
msgstr ""

msgid "The default configuration for Apache 2 enables name-based virtual hosts. In addition, a default virtual host is defined in the <literal>/etc/apache2/sites-enabled/000-default.conf</literal> file; this virtual host will be used if no host matching the request sent by the client is found."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> First virtual host"
msgstr ""

msgid "Requests concerning unknown virtual hosts will always be served by the first defined virtual host, which is why we defined <literal>www.falcot.com</literal> first here."
msgstr ""

msgid "<emphasis>QUICK LOOK</emphasis> Apache supports SNI"
msgstr ""

msgid "<primary>Server Name Indication</primary>"
msgstr ""

msgid "The Apache server supports an SSL protocol extension called <emphasis>Server Name Indication</emphasis> (SNI). This extension allows the browser to send the hostname of the web server during the establishment of the SSL connection, much earlier than the HTTP request itself, which was previously used to identify the requested virtual host among those hosted on the same server (with the same IP address and port). This allows Apache to select the most appropriate SSL certificate for the transaction to proceed."
msgstr ""

msgid "Before SNI, Apache would always use the certificate defined in the default virtual host. Clients trying to access another virtual host would then display warnings, since the certificate they received didn't match the website they were trying to access. Fortunately, most browsers now work with SNI; this includes Microsoft Internet Explorer starting with version 7.0 (starting on Vista), Mozilla Firefox starting with version 2.0, Apple Safari since version 3.2.1, and all versions of Google Chrome."
msgstr ""

msgid "The Apache package provided in Debian is built with support for SNI; no particular configuration is therefore needed."
msgstr ""

msgid "Care should also be taken to ensure that the configuration for the first virtual host (the one used by default) does enable TLSv1, since Apache uses the parameters of this first virtual host to establish secure connections, and they had better allow them!"
msgstr ""

msgid "Each extra virtual host is then described by a file stored in <filename>/etc/apache2/sites-available/</filename>. Setting up a website for the <literal>falcot.org</literal> domain is therefore a simple matter of creating the following file, then enabling the virtual host with <command>a2ensite www.falcot.org</command>."
msgstr ""

msgid "<primary>Apache</primary><secondary><filename>/etc/apache2/sites-available</filename></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><filename>/etc/apache2/sites-enabled</filename></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><command>a2ensite</command></secondary>"
msgstr ""

msgid "The <filename>/etc/apache2/sites-available/www.falcot.org.conf</filename> file"
msgstr ""

msgid ""
"<![CDATA[\n"
"<VirtualHost *:80>\n"
"ServerName   www.falcot.org\n"
"ServerAlias  falcot.org\n"
"DocumentRoot /srv/www/www.falcot.org\n"
"</VirtualHost>\n"
"]]>"
msgstr ""

msgid "The Apache server, as configured so far, uses the same log files for all virtual hosts (although this could be changed by adding <literal>CustomLog</literal> directives in the definitions of the virtual hosts). It therefore makes good sense to customize the format of this log file to have it include the name of the virtual host. This can be done by creating a <filename>/etc/apache2/conf-available/customlog.conf</filename> file that defines a new format for all log files (with the <literal>LogFormat</literal> directive) and by enabling it with <command>a2enconf customlog</command>. The <literal>CustomLog</literal> line must also be removed (or commented out) from the <filename>/etc/apache2/sites-available/000-default.conf</filename> file."
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>CustomLog</literal></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>LogFormat</literal></secondary>"
msgstr ""

msgid "<primary><literal>CustomLog</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary><literal>LogFormat</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><filename>/etc/apache2/conf-available</filename></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><filename>/etc/apache2/conf-enabled</filename></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><command>a2enconf</command></secondary>"
msgstr ""

msgid "The <filename>/etc/apache2/conf-available/customlog.conf</filename> file"
msgstr ""

msgid ""
"\n"
"# New log format including (virtual) host name\n"
"LogFormat \"%v %h %l %u %t \\\"%r\\\" %&gt;s %b \\\"%{Referer}i\\\" \\\"%{User-Agent}i\\\"\" vhost\n"
"\n"
"# Now let's use this \"vhost\" format by default\n"
"CustomLog /var/log/apache2/access.log vhost"
msgstr ""

msgid "Common Directives"
msgstr ""

msgid "This section briefly reviews some of the commonly-used Apache configuration directives."
msgstr ""

msgid "<primary>Apache directives</primary>"
msgstr ""

msgid "<primary>directives, Apache</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary>directives</secondary>"
msgstr ""

msgid "The main configuration file usually includes several <literal>Directory</literal> blocks; they allow specifying different behaviors for the server depending on the location of the file being served. Such a block commonly includes <literal>Options</literal> and <literal>AllowOverride</literal> directives."
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>Directory</literal></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>Options</literal></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>AllowOverride</literal></secondary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>DirectoryIndex</literal></secondary>"
msgstr ""

msgid "Directory block"
msgstr ""

msgid ""
"<![CDATA[\n"
"<Directory /var/www>\n"
"Options Includes FollowSymlinks\n"
"AllowOverride All\n"
"DirectoryIndex index.php index.html index.htm\n"
"</Directory>\n"
"]]>"
msgstr ""

msgid "The <literal>DirectoryIndex</literal> directive contains a list of files to try when the client request matches a directory. The first existing file in the list is used and sent as a response."
msgstr ""

msgid "<primary><literal>DirectoryIndex</literal>, Apache directive</primary>"
msgstr ""

msgid "The <literal>Options</literal> directive is followed by a list of options to enable. The <literal>None</literal> value disables all options; correspondingly, <literal>All</literal> enables them all except <literal>MultiViews</literal>. Available options include:"
msgstr ""

msgid "<primary><literal>Options</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary><literal>AllowOverride</literal>, Apache directive</primary>"
msgstr ""

msgid "<literal>ExecCGI</literal> indicates that CGI scripts can be executed."
msgstr ""

msgid "<primary><literal>ExecCGI</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>ExecCGI</literal></secondary>"
msgstr ""

msgid "<literal>FollowSymlinks</literal> tells the server that symbolic links can be followed, and that the response should contain the contents of the target of such links."
msgstr ""

msgid "<primary><literal>FollowSymlinks</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>FollowSymlinks</literal></secondary>"
msgstr ""

msgid "<literal>SymlinksIfOwnerMatch</literal> also tells the server to follow symbolic links, but only when the link and the its target have the same owner."
msgstr ""

msgid "<primary><literal>SymlinksIfOwnerMatch</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>SymlinksIfOwnerMatch</literal></secondary>"
msgstr ""

msgid "<literal>Includes</literal> enables <emphasis>Server Side Includes</emphasis> (<emphasis>SSI</emphasis> for short). These are directives embedded in HTML pages and executed on the fly for each request."
msgstr ""

msgid "<primary><literal>Includes</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>Includes</literal></secondary>"
msgstr ""

msgid "<literal>IncludesNOEXEC</literal> allows <emphasis>Server Side Includes</emphasis> (<emphasis>SSI</emphasis>) but disables the <literal>exec</literal> command and limits the <literal>include</literal> directive to text/markup files."
msgstr ""

msgid "<primary><literal>IncludesNOEXEC</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>IncludesNOEXEC</literal></secondary>"
msgstr ""

msgid "<literal>Indexes</literal> tells the server to list the contents of a directory if the HTTP request sent by the client points at a directory without an index file (i.e., when no files mentioned by the <literal>DirectoryIndex</literal> directive exists in this directory)."
msgstr ""

msgid "<primary><literal>Indexes</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>Indexes</literal></secondary>"
msgstr ""

msgid "<literal>MultiViews</literal> enables content negotiation; this can be used by the server to return a web page matching the preferred language as configured in the browser."
msgstr ""

msgid "<primary><literal>MultiViews</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>MultiViews</literal></secondary>"
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> <filename>.htaccess</filename> file"
msgstr ""

msgid "<primary>Apache</primary><secondary><filename>.htaccess</filename></secondary>"
msgstr ""

msgid "The <filename>.htaccess</filename> file contains Apache configuration directives enforced each time a request concerns an element of the directory where it is stored. The scope of these directives also recurses to all the subdirectories within."
msgstr ""

msgid "<primary><filename>.htaccess</filename></primary>"
msgstr ""

msgid "Most of the directives that can occur in a <literal>Directory</literal> block are also legal in a <filename>.htaccess</filename> file."
msgstr ""

msgid "The <literal>AllowOverride</literal> directive lists all the options that can be enabled or disabled by way of a <filename>.htaccess</filename> file. A common use of this option is to restrict <literal>ExecCGI</literal>, so that the administrator chooses which users are allowed to run programs under the web server's identity (the <literal>www-data</literal> user)."
msgstr ""

msgid "Requiring Authentication"
msgstr ""

msgid "<primary>web authentication</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary>password-based authentication</secondary>"
msgstr ""

msgid "In some circumstances, access to part of a website needs to be restricted, so only legitimate users who provide a username and a password are granted access to the contents."
msgstr ""

msgid "<filename>.htaccess</filename> file requiring authentication"
msgstr ""

msgid ""
"\n"
"Require valid-user\n"
"AuthName \"Private directory\"\n"
"AuthType Basic\n"
"AuthUserFile /etc/apache2/authfiles/htpasswd-private"
msgstr ""

msgid "<emphasis>SECURITY</emphasis> No security"
msgstr ""

msgid "The authentication system used in the above example (<literal>Basic</literal>) has minimal security as the password is sent in clear text (it is only encoded as <emphasis>base64</emphasis>, which is a simple encoding rather than an encryption method). It should also be noted that the documents “protected” by this mechanism also go over the network in the clear. If security is important, the whole HTTP connection should be encrypted with SSL."
msgstr ""

msgid "The <filename>/etc/apache2/authfiles/htpasswd-private</filename> file contains a list of users and passwords; it is commonly manipulated with the <command>htpasswd</command> command. For example, the following command is used to add a user or change their password:"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary><command>htpasswd</command></primary>"
msgstr "<primary>Samba</primary>"

msgid "<primary>Apache</primary><secondary><literal><command>htpasswd</command></literal></secondary>"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>htpasswd /etc/apache2/authfiles/htpasswd-private <replaceable>user</replaceable>\n"
"</userinput><computeroutput>New password:\n"
"Re-type new password:\n"
"Adding password for user <replaceable>user</replaceable>\n"
"</computeroutput>"
msgstr ""

msgid "Restricting Access"
msgstr ""

msgid "<primary>web access restriction</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary>IP-based authentication</secondary>"
msgstr ""

msgid "The <literal>Require</literal> directive controls access restrictions for a directory (and its subdirectories, recursively). <ulink type=\"block\" url=\"https://httpd.apache.org/docs/2.4/howto/access.html\" />"
msgstr ""

msgid "<primary><literal>Require</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>Require</literal></secondary>"
msgstr ""

msgid "It can be used to restrict access based on many criteria; we will stop at describing access restriction based on the IP address of the client, but it can be made much more powerful than that, especially when several <literal>Require</literal> directives are combined within a <literal>RequireAll</literal> block."
msgstr ""

msgid "Only allow from the local network"
msgstr ""

msgid "Require ip 192.168.0.0/16"
msgstr ""

msgid "<emphasis>ALTERNATIVE</emphasis> Old syntax"
msgstr ""

msgid "The <literal>Require</literal> syntax is only available in Apache 2.4 (the version shipped since <emphasis role=\"distribution\">Jessie</emphasis>). For users of <emphasis role=\"distribution\">Wheezy</emphasis>, the Apache 2.2 syntax is different, and we describe it here mainly for reference, although it can also be made available in Apache 2.4 using the <literal>mod_access_compat</literal> module."
msgstr ""

msgid "The <literal>Allow from</literal> and <literal>Deny from</literal> directives control access restrictions for a directory (and its subdirectories, recursively)."
msgstr ""

msgid "<primary><literal>Allow from</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal></literal>Allow from</secondary>"
msgstr ""

msgid "<primary><literal>Deny from</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>Deny from</literal></secondary>"
msgstr ""

msgid "<primary><literal>Order</literal>, Apache directive</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary><literal>Order</literal></secondary>"
msgstr ""

msgid "The <literal>Order</literal> directive tells the server of the order in which the <literal>Allow from</literal> and <literal>Deny from</literal> directives are applied; the last one that matches takes precedence. In concrete terms, <literal>Order deny,allow</literal> allows access if no <literal>Deny from</literal> applies, or if an <literal>Allow from</literal> directive does. Conversely, <literal>Order allow,deny</literal> rejects access if no <literal>Allow from</literal> directive matches (or if a <literal>Deny from</literal> directive applies)."
msgstr ""

msgid "The <literal>Allow from</literal> and <literal>Deny from</literal> directives can be followed by an IP address, a network (such as <literal>192.168.0.0/255.255.255.0</literal>, <literal>192.168.0.0/24</literal> or even <literal>192.168.0</literal>), a hostname or a domain name, or the <literal>all</literal> keyword, designating everyone."
msgstr ""

msgid "For instance, to reject connections by default but allow them from the local network, you could use this:"
msgstr ""

msgid ""
"\n"
"Order deny,allow\n"
"Allow from 192.168.0.0/16\n"
"Deny from all"
msgstr ""

msgid "Log Analyzers"
msgstr ""

msgid "A log analyzer is frequently installed on a web server; since the former provides the administrators with a precise idea of the usage patterns of the latter."
msgstr ""

msgid "The Falcot Corp administrators selected <emphasis>AWStats</emphasis> (<emphasis>Advanced Web Statistics</emphasis>) to analyze their Apache log files."
msgstr ""

msgid "<primary><emphasis>AWStats</emphasis></primary>"
msgstr ""

msgid "<primary>web logs analyzer</primary>"
msgstr ""

msgid "<primary>logs</primary><secondary>web logs analyzer</secondary>"
msgstr ""

msgid "<primary>analyzer of web logs</primary>"
msgstr ""

msgid "<primary>Apache</primary><secondary>log analyzer</secondary>"
msgstr ""

msgid "The first configuration step is the customization of the <filename>/etc/awstats/awstats.conf</filename> file. The Falcot administrators keep it unchanged apart from the following parameters:"
msgstr ""

msgid ""
"\n"
"LogFile=\"/var/log/apache2/access.log\"\n"
"LogFormat = \"%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot\"\n"
"SiteDomain=\"www.falcot.com\"\n"
"HostAliases=\"falcot.com REGEX[^.*\\.falcot\\.com$]\"\n"
"DNSLookup=1\n"
"LoadPlugin=\"tooltips\""
msgstr ""

msgid "All these parameters are documented by comments in the template file. In particular, the <varname>LogFile</varname> and <varname>LogFormat</varname> parameters describe the location and format of the log file and the information it contains; <varname>SiteDomain</varname> and <varname>HostAliases</varname> list the various names under which the main web site is known."
msgstr ""

msgid "For high traffic sites, <varname>DNSLookup</varname> should usually not be set to <literal>1</literal>; for smaller sites, such as the Falcot one described above, this setting allows getting more readable reports that include full machine names instead of raw IP addresses."
msgstr ""

msgid "<emphasis>SECURITY</emphasis> Access to statistics"
msgstr ""

msgid "AWStats makes its statistics available on the website with no restrictions by default, but restrictions can be set up so that only a few (probably internal) IP addresses can access them; the list of allowed IP addresses needs to be defined in the <varname>AllowAccessFromWebToFollowingIPAddresses</varname> parameter"
msgstr ""

msgid "AWStats will also be enabled for other virtual hosts; each virtual host needs its own configuration file, such as <filename>/etc/awstats/awstats.www.falcot.org.conf</filename>."
msgstr ""

msgid "AWStats configuration file for a virtual host"
msgstr ""

msgid ""
"\n"
"Include \"/etc/awstats/awstats.conf\"\n"
"SiteDomain=\"www.falcot.org\"\n"
"HostAliases=\"falcot.org\""
msgstr ""

msgid "AWStats uses many icons stored in the <filename>/usr/share/awstats/icon/</filename> directory. In order for these icons to be available on the web site, the Apache configuration needs to be adapted to include the following directive:"
msgstr ""

msgid ""
"\n"
"Alias /awstats-icon/ /usr/share/awstats/icon/"
msgstr ""

msgid "After a few minutes (and once the script has been run a few times), the results are available online: <ulink type=\"block\" url=\"http://www.falcot.com/cgi-bin/awstats.pl\" /><ulink type=\"block\" url=\"http://www.falcot.org/cgi-bin/awstats.pl\" />"
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Log file rotation"
msgstr ""

msgid "In order for the statistics to take all the logs into account, <emphasis>AWStats</emphasis> needs to be run right before the Apache log files are rotated. Looking at the <literal>prerotate</literal> directive of <filename>/etc/logrotate.d/apache2</filename> file, this can be solved by putting a symlink to <filename>/usr/share/awstats/tools/update.sh</filename> in <filename>/etc/logrotate.d/httpd-prerotate</filename>:"
msgstr ""

msgid ""
"<computeroutput>$ </computeroutput><userinput>cat /etc/logrotate.d/apache2\n"
"</userinput><computeroutput><![CDATA[/var/log/apache2/*.log {\n"
"  daily\n"
"  missingok\n"
"  rotate 14\n"
"  compress\n"
"  delaycompress\n"
"  notifempty\n"
"  create 644 root adm\n"
"  sharedscripts\n"
"  postrotate\n"
"    if invoke-rc.d apache2 status > /dev/null 2>&1; then \\\n"
"      invoke-rc.d apache2 reload > /dev/null 2>&1; \\\n"
"    fi;\n"
"  endscript\n"
"  prerotate\n"
"    if [ -d /etc/logrotate.d/httpd-prerotate ]; then \\\n"
"      run-parts /etc/logrotate.d/httpd-prerotate; \\\n"
"    fi; \\\n"
"  endscript\n"
"}\n"
"]]>\n"
"$ </computeroutput><userinput>sudo mkdir -p /etc/logrotate.d/httpd-prerotate\n"
"</userinput><computeroutput>$ </computeroutput><userinput>sudo ln -sf /usr/share/awstats/tools/update.sh \\\n"
"  /etc/logrotate.d/httpd-prerotate/awstats\n"
"</userinput>"
msgstr ""

msgid "Note also that the log files created by <command>logrotate</command> need to be readable by everyone, especially AWStats. In the above example, this is ensured by the <literal>create 644 root adm</literal> line (instead of the default <literal>640</literal> permissions)."
msgstr ""

msgid "FTP File Server"
msgstr ""

msgid "<primary>FTP</primary><see>File Transfer Protocol</see>"
msgstr ""

#, fuzzy
#| msgid "<primary>proxy cache</primary>"
msgid "<primary>File Transfer Protocol</primary>"
msgstr "<primary>proxy cache</primary>"

msgid "<primary>server</primary><secondary>file</secondary>"
msgstr ""

msgid "<primary>server</primary><secondary>FTP</secondary>"
msgstr ""

msgid "FTP (<emphasis>File Transfer Protocol</emphasis>) is one of the first protocols of the Internet (RFC 959 was issued in 1985!). It was used to distribute files before the Web was even born (the HTTP protocol was created in 1990, and formally defined in its 1.0 version by RFC 1945, issued in 1996)."
msgstr ""

msgid "This protocol allows both file uploads and file downloads; for this reason, it is still widely used to deploy updates to a website hosted by one's Internet service provider (or any other entity hosting websites). In these cases, secure access is enforced with a user identifier and password; on successful authentication, the FTP server grants read-write access to that user's home directory."
msgstr ""

msgid "Other FTP servers are mainly used to distribute files for public downloading; Debian packages are a good example. The contents of these servers is fetched from other, geographically remote, servers; it is then made available to less distant users. This means that client authentication is not required; as a consequence, this operating mode is known as “anonymous FTP”. To be perfectly correct, the clients do authenticate with the <literal>anonymous</literal> username; the password is often, by convention, the user's email address, but the server ignores it."
msgstr ""

msgid "Many FTP servers are available in Debian (<emphasis role=\"pkg\">ftpd</emphasis><footnote><para>The <emphasis role=\"pkg\">ftpd</emphasis> package is not included in Debian <emphasis role=\"distribution\">Buster</emphasis> due to a bug, which could not be solved before the release.</para></footnote>, <emphasis role=\"pkg\">proftpd-basic</emphasis>, <emphasis role=\"pkg\">pyftpd</emphasis> and so on). The Falcot Corp administrators picked <emphasis role=\"pkg\">vsftpd</emphasis> because they only use the FTP server to distribute a few files (including a Debian package repository); since they don't need advanced features, they chose to focus on the security aspects."
msgstr ""

msgid "<primary><emphasis role=\"pkg\">vsftpd</emphasis></primary>"
msgstr ""

msgid "Installing the package creates an <literal>ftp</literal> system user. This account is always used for anonymous FTP connections, and its home directory (<filename>/srv/ftp/</filename>) is the root of the tree made available to users connecting to this service. The default configuration (in <filename>/etc/vsftpd.conf</filename>) requires some changes to cater to the simple need of making big files available for public downloads: anonymous access needs to be enabled (<literal>anonymous_enable=YES</literal>) and read-only access of local users needs to be disabled (<literal>local_enable=NO</literal>). The latter is particularly important since the FTP protocol doesn't use any form of encryption and the user password could be intercepted over the wire."
msgstr ""

msgid "NFS File Server"
msgstr ""

msgid "<primary>NFS</primary><seealso>Network File System</seealso>"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>Network File System</primary>"
msgstr "<primary>Samba</primary>"

msgid "<primary>server</primary><secondary>NFS</secondary>"
msgstr ""

msgid "NFS (<emphasis>Network File System</emphasis>) is a protocol allowing remote access to a filesystem through the network. All Unix systems can work with this protocol."
msgstr ""

msgid "<emphasis>SPECIFIC CASE</emphasis> Microsoft Windows and NFS Shares"
msgstr ""

msgid "When older or (so called) \"Home\" variants of Windows are involved, usually Samba (<xref linkend=\"sect.windows-file-server-with-samba\" />) must be used instead of NFS. Modern Windows Server and \"Pro\" or \"Enterprise\" Desktop solutions however have built-in support for NFS. After installation of the \"Services for NFS\" components NFS shares can be accessed and temporarily or permanently mounted like any other network share. Be aware of possible encoding issues in file names."
msgstr ""

msgid "As an alternative Debian can be installed on Windows 10 Pro and higher. It requires the installation of the Windows Subsystem for Linux component and the Debian app from the Windows store. <ulink type=\"block\" url=\"https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?\" />"
msgstr ""

msgid "<primary>Network File System</primary><secondary>Windows client</secondary>"
msgstr ""

msgid "<primary><emphasis>Network</emphasis></primary><secondary><emphasis>File System</emphasis></secondary>"
msgstr ""

msgid "<primary>filesystem</primary><secondary>network</secondary>"
msgstr ""

msgid "<primary>file</primary><secondary>server</secondary>"
msgstr ""

msgid "NFS is a very useful tool but, historically, it has suffered from many limitations, most of which have been addressed with version 4 of the protocol. The downside is that the latest version of NFS is harder to configure when you want to make use of basic security features such as authentication and encryption since it relies on Kerberos for those parts. And without those, the NFS protocol must be restricted to a trusted local network since data goes over the network unencrypted (a <emphasis>sniffer</emphasis> can intercept it) and access rights are granted based on the client's IP address (which can be spoofed)."
msgstr ""

msgid "<emphasis>DOCUMENTATION</emphasis> NFS HOWTO"
msgstr ""

msgid "Good documentation to deploy NFSv4 is rather scarce. Here are some pointers with content of varying quality but that should at least give some hints on what should be done. <ulink type=\"block\" url=\"https://help.ubuntu.com/community/NFSv4Howto\" /> <ulink type=\"block\" url=\"https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration\" />"
msgstr ""

msgid "Securing NFS"
msgstr ""

msgid "<primary>NFS</primary><secondary>security</secondary>"
msgstr ""

msgid "If you don't use the Kerberos-based security features, it is vital to ensure that only the machines allowed to use NFS can connect to the various required RPC servers, because the basic protocol trusts the data received from the network. The firewall must also block <emphasis>IP spoofing</emphasis> so as to prevent an outside machine from acting as an inside one, and access to the appropriate ports must be restricted to the machines meant to access the NFS shares."
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> RPC"
msgstr ""

msgid "<primary>RPC</primary><see>Remote Procedure Call</see>"
msgstr ""

#, fuzzy
#| msgid "<primary>proxy cache</primary>"
msgid "<primary>Remote Procedure Call</primary>"
msgstr "<primary>proxy cache</primary>"

msgid "RPC (<emphasis>Remote Procedure Call</emphasis>) is a Unix standard for remote services. NFS is one such service."
msgstr ""

msgid "RPC services register to a directory known as the <emphasis>portmapper</emphasis>. A client wishing to perform an NFS query first addresses the <emphasis>portmapper</emphasis> (on port 111, either TCP or UDP), and asks for the NFS server; the reply usually mentions port 2049 (the default for NFS). Not all RPC services necessarily use a fixed port."
msgstr ""

msgid "<primary><command>portmapper</command></primary>"
msgstr ""

msgid "Older versions of the protocol required other RPC services which used dynamically assigned ports. Fortunately, with NFS version 4, only port 2049 (for NFS) and 111 (for the portmapper) are needed and they are thus easy to firewall."
msgstr ""

msgid "NFS Server"
msgstr ""

msgid "<primary>NFS</primary><secondary><filename>/etc/exports</filename></secondary>"
msgstr ""

msgid "<primary>NFS</primary><secondary>server</secondary>"
msgstr ""

msgid "The NFS server is part of the Linux kernel; in kernels provided by Debian it is built as a kernel module. If the NFS server is to be run automatically on boot, the <emphasis role=\"pkg\">nfs-kernel-server</emphasis> package should be installed; it contains the relevant start-up scripts."
msgstr ""

msgid "The NFS server configuration file, <filename>/etc/exports</filename>, lists the directories that are made available over the network (<emphasis>exported</emphasis>). For each NFS share, only the given list of machines is granted access. More fine-grained access control can be obtained with a few options. The syntax for this file is quite simple:"
msgstr ""

msgid "<primary><filename>exports</filename></primary>"
msgstr ""

msgid "<primary><filename>/etc/exports</filename></primary>"
msgstr ""

msgid ""
"\n"
"/directory/to/share machine1(option1,option2,...) machine2(...) ..."
msgstr ""

msgid "Note that with NFSv4, all exported directories must be part of a single hierarchy and that the root directory of that hierarchy must be exported and identified with the option <literal>fsid=0</literal> or <literal>fsid=root</literal>."
msgstr ""

msgid "Each machine can be identified either by its DNS name or its IP address. Whole sets of machines can also be specified using either a syntax such as <literal>*.falcot.com</literal> or an IP address range such as <literal>192.168.0.0/255.255.255.0</literal> or <literal>192.168.0.0/24</literal>."
msgstr ""

msgid "Directories are made available as read-only by default (or with the <literal>ro</literal> option). The <literal>rw</literal> option allows read-write access. NFS clients typically connect from a port restricted to root (in other words, below 1024); this restriction can be lifted by the <literal>insecure</literal> option (the <literal>secure</literal> option is implicit, but it can be made explicit if needed for clarity)."
msgstr ""

msgid "<primary>NFS</primary><secondary>options</secondary>"
msgstr ""

msgid "By default, the server only answers an NFS query when the current disk operation is complete (<literal>sync</literal> option); this can be disabled with the <literal>async</literal> option. Asynchronous writes increase performance a bit, but they decrease reliability since there is a data loss risk in case of the server crashing between the acknowledgment of the write and the actual write on disk. Since the default value changed recently (as compared to the historical value of NFS), an explicit setting is recommended."
msgstr ""

msgid "In order to not give root access to the filesystem to any NFS client, all queries appearing to come from a root user are considered by the server as coming from the <literal>nobody</literal> user. This behavior corresponds to the <literal>root_squash</literal> option, and is enabled by default. The <literal>no_root_squash</literal> option, which disables this behavior, is risky and should only be used in controlled environments. If all users should be mapped to the user <literal>nobody</literal>, use <literal>all_squash</literal>. The <literal>anonuid=<replaceable>uid</replaceable></literal> and <literal>anongid=<replaceable>gid</replaceable></literal> options allow specifying another fake user to be used instead of UID/GID 65534 (which corresponds to user <literal>nobody</literal> and group <literal>nogroup</literal>)."
msgstr ""

msgid "With NFSv4, you can add a <literal>sec</literal> option to indicate the security level that you want: <literal>sec=sys</literal> is the default with no special security features, <literal>sec=krb5</literal> enables authentication only, <literal>sec=krb5i</literal> adds integrity protection, and <literal>sec=krb5p</literal> is the most complete level which includes privacy protection (with data encryption). For this to work you need a working Kerberos setup (that service is not covered by this book)."
msgstr ""

msgid "Other options are available; they are documented in the <citerefentry><refentrytitle>exports</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> First installation"
msgstr ""

msgid "The <filename>/etc/init.d/nfs-kernel-server</filename> boot script only starts the server if <filename>/etc/exports</filename> lists one or more valid NFS shares. On initial configuration, once this file has been edited to contain valid entries, the NFS server must therefore be started with the following command:"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>systemctl start nfs-kernel-server</userinput>"
msgstr ""

msgid "NFS Client"
msgstr ""

msgid "<primary>client</primary><secondary>NFS</secondary>"
msgstr ""

msgid "<primary>NFS</primary><secondary>client</secondary>"
msgstr ""

msgid "As with other filesystems, integrating an NFS share into the system hierarchy requires mounting (and the <emphasis role=\"pkg\">nfs-common</emphasis> package). Since this filesystem has its peculiarities, a few adjustments were required in the syntaxes of the <command>mount</command> command and the <filename>/etc/fstab</filename> file."
msgstr ""

msgid "Manually mounting with the <command>mount</command> command"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared</userinput>\n"
"        "
msgstr ""

msgid "NFS entry in the <filename>/etc/fstab</filename> file"
msgstr ""

msgid ""
"\n"
"arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0"
msgstr ""

msgid "The entry described above mounts, at system startup, the NFS directory <filename>/shared/</filename> from the <literal>arrakis</literal> server into the local <filename>/srv/shared/</filename> directory. Read-write access is requested (hence the <literal>rw</literal> parameter). The <literal>nosuid</literal> option is a protection measure that wipes any <literal>setuid</literal> or <literal>setgid</literal> bit from programs stored on the share. If the NFS share is only meant to store documents, another recommended option is <literal>noexec</literal>, which prevents executing programs stored on the share. Note that on the server, the <filename>shared</filename> directory is below the NFSv4 root export (for example <filename>/export/shared</filename>), it is not a top-level directory."
msgstr ""

msgid "The <citerefentry><refentrytitle>nfs</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the options in some detail."
msgstr ""

msgid "Setting Up Windows Shares with Samba"
msgstr ""

msgid "<primary>Samba</primary>"
msgstr "<primary>Samba</primary>"

msgid "<primary>Windows share</primary>"
msgstr ""

msgid "<primary>server</primary><secondary>SMB</secondary>"
msgstr ""

msgid "<primary>server</primary><secondary>CIFS</secondary>"
msgstr ""

msgid "Samba is a suite of tools handling the SMB protocol (also known as “CIFS”) on Linux. This protocol is used by Windows for network shares and shared printers."
msgstr ""

msgid "<primary>SMB</primary><see>Server Message Block</see>"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>Server Message Block</primary>"
msgstr "<primary>Samba</primary>"

msgid "<primary>CIFS</primary><see>Common Internet File System</see>"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>Common Internet File System</primary>"
msgstr "<primary>Samba</primary>"

msgid "Samba can also act as a Windows domain controller. This is an outstanding tool for ensuring seamless integration of Linux servers and the office desktop machines still running Windows."
msgstr ""

msgid "Samba Server"
msgstr ""

msgid "<primary>server</primary><secondary>Samba</secondary>"
msgstr ""

msgid "<primary>Samba</primary><secondary>installation</secondary>"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>Samba</primary><secondary>server</secondary>"
msgstr "<primary>Samba</primary>"

msgid "The <emphasis role=\"pkg\">samba</emphasis> package contains the main two servers of Samba 4, <command>smbd</command> and <command>nmbd</command>."
msgstr ""

msgid "<primary><command>smbd</command></primary>"
msgstr ""

msgid "<primary><command>nmbd</command></primary>"
msgstr ""

msgid "<primary>Samba</primary><secondary><command>smbd</command></secondary>"
msgstr ""

msgid "<primary>Samba</primary><secondary><command>nmbd</command></secondary>"
msgstr ""

msgid "<emphasis>DOCUMENTATION</emphasis> Going further"
msgstr ""

msgid "The Samba server is extremely configurable and versatile, and can address a great many different use cases matching very different requirements and network architectures. This book only focuses on the use case where Samba is used as a standalone server, but it can also be a NT4 Domain Controller or a full Active Directory Domain Controller, or a simple member of an existing domain (which could be a managed by a Windows server)."
msgstr ""

msgid "<primary>domain controller</primary>"
msgstr ""

msgid "<primary>Windows domain</primary>"
msgstr ""

msgid "<primary>Samba</primary><secondary>domain controller</secondary>"
msgstr ""

msgid "The <emphasis role=\"pkg\">samba</emphasis> package contains all the necessary manual pages and in <filename>/usr/share/doc/samba/examples/</filename> a wealth of commented example files. If you are looking for a more comprehensive documentation, you may check the <emphasis>Samba</emphasis> website. <ulink type=\"block\" url=\"https://www.samba.org/samba/docs/\" />"
msgstr ""

msgid "<emphasis>TOOL</emphasis> Authenticating with a Windows Server"
msgstr ""

msgid "Winbind gives system administrators the option of using a Windows server as an authentication server. Winbind also integrates cleanly with PAM and NSS. This allows setting up Linux machines where all users of a Windows domain automatically get an account."
msgstr ""

msgid "<primary>Winbind</primary>"
msgstr ""

msgid "More information can be found in the <filename>/usr/share/doc/libpam-winbind/examples/pam_winbind/</filename> directory of the <emphasis role=\"pkg\">libpam-winbind</emphasis> package."
msgstr ""

msgid "Configuring with <command>debconf</command>"
msgstr ""

msgid "<primary>Samba</primary><secondary>configuration</secondary>"
msgstr ""

msgid "The package sets up a minimal configuration during the initial installation by plainly copying <filename>/usr/share/samba/smb.conf</filename>. So you should really run <command>dpkg-reconfigure samba-common</command> to adapt it:"
msgstr ""

msgid "On first installation the only piece of required information is the name of the workgroup where the Samba server will belong (the answer is <literal>FALCOTNET</literal> in our case)."
msgstr ""

msgid "In case of a package update (from the old stable Debian version) or if the SMB server has already been configured to use a WINS server (<literal>wins server</literal>) the package also proposes identifying the WINS server from the information provided by the DHCP daemon. The Falcot Corp administrators rejected this option, since they intend to use the Samba server itself as the WINS server."
msgstr ""

msgid "<primary>WINS</primary>"
msgstr ""

msgid "Configuring Manually"
msgstr ""

msgid "Changes to <filename>smb.conf</filename>"
msgstr ""

msgid "The requirements at Falcot require other options to be modified in the <filename>/etc/samba/smb.conf</filename> configuration file. The following excerpts summarize the changes that were effected in the <literal>[global]</literal> section."
msgstr ""

msgid "<primary>Samba</primary><secondary><filename>/etc/samba/smb.conf</filename></secondary>"
msgstr ""

msgid "<primary>Samba</primary><secondary><filename>smb.conf</filename></secondary>"
msgstr ""

msgid ""
"\n"
"[...]\n"
"\n"
"[global]\n"
"\n"
"## Browsing/Identification ###\n"
"\n"
"# Change this to the workgroup/NT-domain name your Samba server will part of\n"
"   workgroup = FALCOTNET\n"
"\n"
"# Windows Internet Name Serving Support Section:\n"
"# WINS Support - Tells the NMBD component of Samba to enable its WINS Server\n"
"   wins support = yes <co id=\"smb.conf.wins\"></co>\n"
"\n"
"[...]\n"
"\n"
"####### Authentication #######\n"
"\n"
"# Server role. Defines in which mode Samba will operate. Possible\n"
"# values are \"standalone server\", \"member server\", \"classic primary\n"
"# domain controller\", \"classic backup domain controller\", \"active\n"
"# directory domain controller\". \n"
"#\n"
"# Most people will want \"standalone server\" or \"member server\".\n"
"# Running as \"active directory domain controller\" will require first\n"
"# running \"samba-tool domain provision\" to wipe databases and create a\n"
"# new domain.\n"
"   server role = standalone server\n"
"\n"
"   obey pam restrictions = yes\n"
"\n"
"[...]\n"
"\n"
"# \"security = user\" is always a good idea. This will require a Unix account\n"
"# in this server for every user accessing the server.\n"
"   security = user <co id=\"smb.conf.security\"></co>\n"
"\n"
"[...]"
msgstr ""

msgid "Indicates that Samba should act as a Netbios name server (WINS) for the local network. This option has been removed from the default configuration in <emphasis role=\"distribution\">Buster</emphasis> and must be added manually if desired."
msgstr ""

msgid "This is the default value for this parameter; however, since it is central to the Samba configuration, filling it explicitly is recommended. Each user must authenticate before accessing any share."
msgstr ""

msgid "Adding Users"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>Samba</primary><secondary>add users</secondary>"
msgstr "<primary>Samba</primary>"

msgid "Each Samba user needs an account on the server; the Unix accounts must be created first, then the user needs to be registered in Samba's database. The Unix step is done quite normally (using <command>adduser</command> for instance)."
msgstr ""

msgid "Adding an existing user to the Samba database is a matter of running the <command>smbpasswd -a <replaceable>user</replaceable></command> command; this command asks for the password interactively."
msgstr ""

msgid "<primary>Samba</primary><secondary><command>smbpasswd</command></secondary>"
msgstr ""

msgid "A user can be deleted with the <command>smbpasswd -x <replaceable>user</replaceable></command> command. A Samba account can also be temporarily disabled (with <command>smbpasswd -d <replaceable>user</replaceable></command>) and re-enabled later (with <command>smbpasswd -e <replaceable>user</replaceable></command>)."
msgstr ""

msgid "Samba Client"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>Samba</primary><secondary>client</secondary>"
msgstr "<primary>Samba</primary>"

msgid "The client features in Samba allow a Linux machine to access Windows shares and shared printers. The required programs are available in the <emphasis role=\"pkg\">cifs-utils</emphasis> and <emphasis role=\"pkg\">smbclient</emphasis> packages."
msgstr ""

msgid "<primary><emphasis>smbclient</emphasis></primary>"
msgstr ""

msgid "<primary><emphasis>cifs-utils</emphasis></primary>"
msgstr ""

msgid "The <command>smbclient</command> Program"
msgstr ""

msgid "The <command>smbclient</command> program queries SMB servers. It accepts a <literal>-U <replaceable>user</replaceable></literal> option, for connecting to the server under a specific identity. <command>smbclient //<replaceable>server</replaceable>/<replaceable>share</replaceable></command> accesses the share in an interactive way similar to the command-line FTP client. <command>smbclient -L <replaceable>server</replaceable></command> lists all available (and visible) shares on a server."
msgstr ""

msgid "Mounting Windows Shares"
msgstr ""

msgid "The <command>mount</command> command allows mounting a Windows share into the Linux filesystem hierarchy (with the help of <command>mount.cifs</command> provided by <emphasis role=\"pkg\">cifs-utils</emphasis>)."
msgstr ""

msgid "<primary><command>mount.cifs</command></primary>"
msgstr ""

msgid "<primary>Windows share, mounting</primary>"
msgstr ""

msgid "Mounting a Windows share"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>Samba</primary><secondary>mount</secondary>"
msgstr "<primary>Samba</primary>"

msgid ""
"\n"
"mount -t cifs //arrakis/shared /shared \\\n"
"      -o credentials=/etc/smb-credentials"
msgstr ""

msgid "The <filename>/etc/smb-credentials</filename> file (which must not be readable by users) has the following format:"
msgstr ""

msgid "<primary>Samba</primary><secondary>credentials</secondary>"
msgstr ""

msgid ""
"\n"
"username = <replaceable>user</replaceable>\n"
"password = <replaceable>password</replaceable>"
msgstr ""

msgid "Other options can be specified on the command-line; their full list is available in the <citerefentry><refentrytitle>mount.cifs</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page. Two options in particular can be interesting: <literal>uid</literal> and <literal>gid</literal> allow forcing the owner and group of files available on the mount, so as not to restrict access to root."
msgstr ""

msgid "A mount of a Windows share can also be configured in <filename>/etc/fstab</filename>:"
msgstr ""

msgid ""
"\n"
"//<replaceable>server</replaceable>/shared /shared cifs credentials=/etc/smb-credentials"
msgstr ""

msgid "Unmounting a SMB/CIFS share is done with the standard <command>umount</command> command."
msgstr ""

msgid "Printing on a Shared Printer"
msgstr ""

msgid "CUPS is an elegant solution for printing from a Linux workstation to a printer shared by a Windows machine. When the <emphasis role=\"pkg\">smbclient</emphasis> is installed, CUPS allows installing Windows shared printers automatically."
msgstr ""

msgid "<primary>printing</primary><secondary>network</secondary>"
msgstr ""

msgid "<primary>Samba</primary><secondary>shared printers</secondary>"
msgstr ""

msgid "Here are the required steps:"
msgstr ""

msgid "Enter the CUPS configuration interface: <literal>http://localhost:631/admin</literal>"
msgstr ""

msgid "Click on “Add Printer”."
msgstr ""

msgid "Choose the printer device, pick “Windows Printer via SAMBA”."
msgstr ""

msgid "Enter the connection URI for the network printer. It should look like the following:"
msgstr ""

msgid "<literal>smb://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>/<replaceable>printer</replaceable></literal>."
msgstr ""

msgid "Enter the name that will uniquely identify this printer. Then enter the description and location of the printer. Those are the strings that will be shown to end users to help them identify the printers."
msgstr ""

msgid "Indicate the manufacturer/model of the printer, or directly provide a working printer description file (PPD)."
msgstr ""

msgid "Voilà, the printer is operational!"
msgstr ""

msgid "HTTP/FTP Proxy"
msgstr ""

msgid "<primary>Proxy</primary><secondary>HTTP</secondary>"
msgstr ""

msgid "<primary>Proxy</primary><secondary>FTP</secondary>"
msgstr ""

msgid "An HTTP/FTP proxy acts as an intermediary for HTTP and/or FTP connections. Its role is twofold:"
msgstr ""

msgid "Caching: recently downloaded documents are copied locally, which avoids multiple downloads."
msgstr ""

msgid "Filtering server: if use of the proxy is mandated (and outgoing connections are blocked unless they go through the proxy), then the proxy can determine whether or not the request is to be granted."
msgstr ""

msgid "<primary>HTTP/FTP proxy</primary>"
msgstr ""

msgid "<primary>proxy cache</primary>"
msgstr "<primary>proxy cache</primary>"

msgid "Falcot Corp selected Squid as their proxy server."
msgstr ""

msgid "<primary>Squid</primary>"
msgstr "<primary>Squid</primary>"

msgid "Installing"
msgstr ""

msgid "<primary>Squid</primary><secondary>installation</secondary>"
msgstr ""

msgid "The <emphasis role=\"pkg\">squid</emphasis><footnote><para>The <emphasis role=\"pkg\">squid3</emphasis> package, providing Squid until Debian <emphasis role=\"distribution\">Jessie</emphasis>, is now a transitional package and will automatically install <emphasis role=\"pkg\">squid</emphasis>.</para></footnote> Debian package only contains the modular (caching) proxy. Turning it into a filtering server requires installing the additional <emphasis role=\"pkg\">squidguard</emphasis> package. In addition, <emphasis role=\"pkg\">squid-cgi</emphasis> provides a querying and administration interface for a Squid proxy."
msgstr ""

msgid "Prior to installing, care should be taken to check that the system can identify its own complete name: the <command>hostname -f</command> must return a fully-qualified name (including a domain). If it does not, then the <filename>/etc/hosts</filename> file should be edited to contain the full name of the system (for instance, <literal>arrakis.falcot.com</literal>). The official computer name should be validated with the network administrator in order to avoid potential name conflicts."
msgstr ""

msgid "Configuring a Cache"
msgstr ""

msgid "<primary>Squid</primary><secondary><filename>squid.conf</filename></secondary>"
msgstr ""

msgid "<primary>Squid</primary><secondary><filename>/etc/squid/squid.conf</filename></secondary>"
msgstr ""

msgid "Enabling the caching server feature is a simple matter of editing the <filename>/etc/squid/squid.conf</filename> configuration file and allowing machines from the local network to run queries through the proxy. The following example shows the modifications made by the Falcot Corp administrators:"
msgstr ""

msgid "The <filename>/etc/squid/squid.conf</filename> file (excerpts)"
msgstr ""

msgid ""
"<![CDATA[\n"
"# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS\n"
"#\n"
"include /etc/squid/conf.d/*\n"
"\n"
"# Example rule allowing access from your local networks.\n"
"# Adapt localnet in the ACL section to list your (internal) IP networks\n"
"# from where browsing should be allowed\n"
"\n"
"acl our_networks src 192.168.1.0/24 192.168.2.0/24\n"
"http_access allow our_networks\n"
"http_access allow localhost\n"
"# And finally deny all other access to this proxy\n"
"http_access deny all\n"
"]]>"
msgstr ""

msgid "Configuring a Filter"
msgstr ""

msgid "<command>squid</command> itself does not perform the filtering; this action is delegated to <command>squidGuard</command>. The former must then be configured to interact with the latter. This involves adding the following directive to the <filename>/etc/squid/squid.conf</filename> file:"
msgstr ""

msgid "<primary><command>squidGuard</command></primary>"
msgstr ""

msgid "<primary><command>squidGuard</command></primary><secondary><filename>squidGuard.conf</filename></secondary>"
msgstr ""

msgid "<primary><command>squidGuard</command></primary><secondary><filename>/etc/squidguard/squidGuard.conf.default</filename></secondary>"
msgstr ""

msgid "<primary><filename>squidGuard.conf</filename></primary>"
msgstr ""

msgid "<primary><filename>/etc/squidguard/squidGuard.conf.default</filename></primary>"
msgstr ""

msgid ""
"\n"
"url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf"
msgstr ""

msgid "The <filename>/usr/lib/cgi-bin/squidGuard.cgi</filename> CGI program also needs to be installed, using <filename>/usr/share/doc/squidguard/examples/squidGuard.cgi.gz</filename> as a starting point. Required modifications to this script are the <varname>$proxy</varname> and <varname>$proxymaster</varname> variables (the name of the proxy and the administrator's contact email, respectively). The <varname>$image</varname> and <varname>$redirect</varname> variables should point to existing images representing the rejection of a query."
msgstr ""

msgid "The filter is enabled with the <command>service squid reload</command> command. However, since the <emphasis role=\"pkg\">squidguard</emphasis> package does no filtering by default, it is the administrator's task to define the policy. This can be done by creating the <filename>/etc/squid/squidGuard.conf</filename> file (using <filename>/etc/squidguard/squidGuard.conf.default</filename> as template if required)."
msgstr ""

msgid "The working database must be regenerated with <command>update-squidguard</command> after each change of the <command>squidGuard</command> configuration file (or one of the lists of domains or URLs it mentions). The configuration file syntax is documented on the following website: <ulink type=\"block\" url=\"http://www.squidguard.org/Doc/configure.html\" />"
msgstr ""

msgid "<primary><command>update-squidguard</command></primary>"
msgstr ""

msgid "<primary>Squid</primary><secondary><command>update-squidguard</command></secondary>"
msgstr ""

msgid "<primary>Squid</primary><secondary><command>squidGuard</command></secondary>"
msgstr ""

msgid "<emphasis>ALTERNATIVE</emphasis> E2guardian (a DansGuardian Fork)"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">dansguardian</emphasis></primary>"
msgstr ""

msgid "<primary><emphasis role=\"pkg\">e2guardian</emphasis></primary>"
msgstr ""

msgid "The <emphasis role=\"pkg\">e2guardian</emphasis> package, a DansGuardian fork, is an alternative to <emphasis role=\"pkg\">squidguard</emphasis>. This software does not simply handle a blacklist of forbidden URLs, but it can take advantage of the <acronym>PICS</acronym><footnote><para><acronym>PICS</acronym> has been superseded by the <emphasis>Protocol for Web Description Resources</emphasis> (<acronym>POWDER</acronym> system: <ulink url=\"https://www.w3.org/2009/08/pics_superseded.html\" />. <indexterm><primary>POWDER</primary><see>Protocol for Web Description Resources</see></indexterm> <indexterm><primary>Protocol for Web Description Resources</primary></indexterm> </para></footnote> (<emphasis>Platform for Internet Content Selection</emphasis>) to decide whether a page is acceptable by dynamic analysis of its contents."
msgstr ""

msgid "<primary>PICS</primary><see>Platform for Internet Content Selection</see>"
msgstr ""

msgid "<primary>Platform for Internet Content Selection</primary>"
msgstr ""

msgid "LDAP Directory"
msgstr ""

msgid "<primary>LDAP</primary>"
msgstr ""

msgid "<primary>OpenLDAP</primary>"
msgstr ""

msgid "<primary>directory, LDAP</primary>"
msgstr ""

msgid "OpenLDAP is an implementation of the LDAP protocol; in other words, it is a special-purpose database designed for storing directories. In the most common use case, using an LDAP server allows centralizing management of user accounts and the related permissions. Moreover, an LDAP database is easily replicated, which allows setting up multiple synchronized LDAP servers. When the network and the user base grows quickly, the load can then be balanced across several servers."
msgstr ""

msgid "LDAP data is structured and hierarchical. The structure is defined by “schemas” which describe the kind of objects that the database can store, with a list of all their possible attributes. The syntax used to refer to a particular object in the database is based on this structure, which explains its complexity."
msgstr ""

msgid "The <emphasis role=\"pkg\">slapd</emphasis> package contains the OpenLDAP server. The <emphasis role=\"pkg\">ldap-utils</emphasis> package includes command-line tools for interacting with LDAP servers."
msgstr ""

msgid "<primary><emphasis>slapd</emphasis></primary>"
msgstr ""

msgid "Installing <emphasis role=\"pkg\">slapd</emphasis> usually asks only for the administrator's password and the resulting database is unlikely to suit your needs. Fortunately a simple <command>dpkg-reconfigure slapd</command> will let you reconfigure the LDAP database with more details:"
msgstr ""

msgid "Omit OpenLDAP server configuration? No, of course, we want to configure this service."
msgstr ""

msgid "DNS domain name: “<literal>falcot.com</literal>”."
msgstr ""

msgid "Organization name: “Falcot Corp”."
msgstr ""

msgid "An administrative passwords needs to be typed in."
msgstr ""

msgid "Database backend to use: “MDB”."
msgstr ""

msgid "Do you want the database to be removed when <emphasis role=\"pkg\">slapd</emphasis> is purged? No. No point in risking losing the database in case of a mistake."
msgstr ""

msgid "Move old database? This question is only asked when the configuration is attempted while a database already exists. Only answer “yes” if you actually want to start again from a clean database, for instance if you run <command>dpkg-reconfigure slapd</command> right after the initial installation."
msgstr ""

msgid "<emphasis>BACK TO BASICS</emphasis> LDIF format"
msgstr ""

msgid "An LDIF file (<emphasis>LDAP Data Interchange Format</emphasis>) is a portable text file describing the contents of an LDAP database (or a portion thereof); this can then be used to inject the data into any other LDAP server."
msgstr ""

msgid "<primary>LDIF</primary>"
msgstr ""

msgid "A minimal database is now configured, as demonstrated by the following query:"
msgstr ""

msgid ""
"\n"
"<computeroutput>$ </computeroutput><userinput>ldapsearch -x -b dc=falcot,dc=com</userinput>\n"
"<computeroutput># extended LDIF\n"
"#\n"
"# LDAPv3\n"
"# base &lt;dc=falcot,dc=com&gt; with scope subtree\n"
"# filter: (objectclass=*)\n"
"# requesting: ALL\n"
"#\n"
"\n"
"# falcot.com\n"
"dn: dc=falcot,dc=com\n"
"objectClass: top\n"
"objectClass: dcObject\n"
"objectClass: organization\n"
"o: Falcot Corp\n"
"dc: falcot\n"
"\n"
"# admin, falcot.com\n"
"dn: cn=admin,dc=falcot,dc=com\n"
"objectClass: simpleSecurityObject\n"
"objectClass: organizationalRole\n"
"cn: admin\n"
"description: LDAP administrator\n"
"\n"
"# search result\n"
"search: 2\n"
"result: 0 Success\n"
"\n"
"# numResponses: 3\n"
"# numEntries: 2\n"
"</computeroutput>"
msgstr ""

msgid "The query returned two objects: the organization itself, and the administrative user."
msgstr ""

msgid "Filling in the Directory"
msgstr ""

msgid "Since an empty database is not particularly useful, we are going to inject into it all the existing directories; this includes the users, groups, services and hosts databases."
msgstr ""

msgid "The <emphasis role=\"pkg\">migrationtools</emphasis> package provides a set of scripts dedicated to extract data from the standard Unix directories (<filename>/etc/passwd</filename>, <filename>/etc/group</filename>, <filename>/etc/services</filename>, <filename>/etc/hosts</filename> and so on), convert this data, and inject it into the LDAP database."
msgstr ""

msgid "<primary><emphasis role=\"pkg\">migrationtools</emphasis></primary>"
msgstr ""

msgid "Once the package is installed, the <filename>/etc/migrationtools/migrate_common.ph</filename> must be edited; the <varname>IGNORE_UID_BELOW</varname> and <varname>IGNORE_GID_BELOW</varname> options need to be enabled (uncommenting them is enough), and <varname>DEFAULT_MAIL_DOMAIN</varname>/<varname>DEFAULT_BASE</varname> need to be updated."
msgstr ""

msgid "The actual migration operation is handled by the <command>migrate_all_online.sh</command> command, as follows:"
msgstr ""

msgid ""
"\n"
"<computeroutput># </computeroutput><userinput>cd /usr/share/migrationtools</userinput>\n"
"<computeroutput># </computeroutput><userinput>LDAPADD=\"/usr/bin/ldapadd -c\" ETC_ALIASES=/dev/null ./migrate_all_online.sh</userinput>"
msgstr ""

msgid "The <command>migrate_all_online.sh</command> asks a few questions about the LDAP database into which the data is to be migrated. <xref linkend=\"tab-migrate-all\" xrefstyle=\"select: label nopage\" /> summarizes the answers given in the Falcot use-case."
msgstr ""

msgid "Answers to questions asked by the <command>migrate_all_online.sh</command> script"
msgstr ""

msgid "Question"
msgstr ""

msgid "Answer"
msgstr ""

msgid "X.500 naming context"
msgstr ""

msgid "<literal>dc=falcot,dc=com</literal>"
msgstr ""

msgid "LDAP server hostname"
msgstr ""

msgid "<literal>localhost</literal>"
msgstr ""

msgid "Manager DN"
msgstr ""

msgid "<literal>cn=admin,dc=falcot,dc=com</literal>"
msgstr ""

msgid "Bind credentials"
msgstr ""

msgid "the administrative password"
msgstr ""

msgid "Create DUAConfigProfile"
msgstr ""

msgid "no"
msgstr ""

msgid "We deliberately ignore migration of the <filename>/etc/aliases</filename> file, since the standard schema as provided by Debian does not include the structures that this script uses to describe email aliases. Should we want to integrate this data into the directory, the <filename>/etc/ldap/schema/misc.schema</filename> file should be added to the standard schema."
msgstr ""

msgid "<emphasis>TOOL</emphasis> Browsing an LDAP directory"
msgstr ""

msgid "The <command>jxplorer</command> command (in the package of the same name) is a graphical tool allowing to browse and edit an LDAP database. It is an interesting tool that provides an administrator with a good overview of the hierarchical structure of the LDAP data."
msgstr ""

msgid "<primary><command>jxplorer</command></primary>"
msgstr ""

msgid "Also note the use of the <literal>-c</literal> option to the <command>ldapadd</command> command; this option requests that processing doesn't stop in case of error. Using this option is required because converting the <filename>/etc/services</filename> often generates a few errors that can safely be ignored."
msgstr ""

msgid "Managing Accounts with LDAP"
msgstr ""

msgid "Now the LDAP database contains some useful information, the time has come to make use of this data. This section focuses on how to configure a Linux system so that the various system directories use the LDAP database."
msgstr ""

msgid "Configuring NSS"
msgstr ""

msgid "The NSS system (Name Service Switch, see sidebar <xref linkend=\"sidebar.intro-nss\" />) is a modular system designed to define or fetch information for system directories. Using LDAP as a source of data for NSS requires installing the <emphasis role=\"pkg\">libnss-ldap</emphasis> package. Its installation asks a few questions; the answers are summarized in <xref linkend=\"tab-libnss-ldap\" xrefstyle=\"select: label nopage\" />."
msgstr ""

msgid "<primary><emphasis>libnss-ldap</emphasis></primary>"
msgstr ""

msgid "Configuring the <emphasis role=\"pkg\">libnss-ldap</emphasis> package"
msgstr ""

msgid "LDAP server Uniform Resource Identifier"
msgstr ""

msgid "<literal>ldapi://ldap.falcot.com</literal>"
msgstr ""

msgid "Distinguished name of the search base"
msgstr ""

msgid "LDAP version to use"
msgstr ""

msgid "<literal>3</literal>"
msgstr ""

msgid "LDAP account for root"
msgstr ""

msgid "LDAP root account password"
msgstr ""

msgid "Allow LDAP admin account behave like local root?"
msgstr ""

msgid "<literal>yes</literal>"
msgstr ""

msgid "Does the LDAP database require login?"
msgstr ""

msgid "The <filename>/etc/nsswitch.conf</filename> file then needs to be modified, so as to configure NSS to use the freshly-installed <command>ldap</command> module. You can use the example provided in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap or edit your existing configuration."
msgstr ""

msgid "The <filename>/etc/nsswitch.conf</filename> file"
msgstr ""

msgid ""
"\n"
"#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $\n"
"#\n"
"# An example file that could be copied over to /etc/nsswitch.conf; it\n"
"# uses LDAP conjunction with files.\n"
"#\n"
"# \"hosts:\" and \"services:\" in this file are used only if the\n"
"# /etc/netconfig file has a \"-\" for nametoaddr_libs of \"inet\" transports.\n"
"\n"
"# the following lines obviate the \"+\" entry in /etc/passwd and /etc/group.\n"
"passwd:                files ldap\n"
"shadow:                files ldap\n"
"group:                files ldap\n"
"\n"
"# consult DNS first, we will need it to resolve the LDAP host. (If we\n"
"# can't resolve it, we're in infinite recursion, because libldap calls\n"
"# gethostbyname(). Careful!)\n"
"hosts:                dns ldap\n"
"\n"
"# LDAP is nominally authoritative for the following maps.\n"
"services:   ldap [NOTFOUND=return] files\n"
"networks:   ldap [NOTFOUND=return] files\n"
"protocols:  ldap [NOTFOUND=return] files\n"
"rpc:        ldap [NOTFOUND=return] files\n"
"ethers:     ldap [NOTFOUND=return] files\n"
"\n"
"# no support for netmasks, bootparams, publickey yet.\n"
"netmasks:   files\n"
"bootparams: files\n"
"publickey:  files\n"
"automount:  files\n"
"\n"
"# I'm pretty sure nsswitch.conf is consulted directly by sendmail,\n"
"# here, so we can't do much here. Instead, use bbense's LDAP\n"
"# rules ofr sendmail.\n"
"aliases:    files\n"
"sendmailvars:   files\n"
"\n"
"# Note: there is no support for netgroups on Solaris (yet)\n"
"netgroup:   ldap [NOTFOUND=return] files\n"
"\n"
msgstr ""

msgid "The <command>ldap</command> module is usually inserted before others, and it will therefore be queried first. The notable exception is the <literal>hosts</literal> service since contacting the LDAP server requires consulting DNS first (to resolve <literal>ldap.falcot.com</literal>). Without this exception, a hostname query would try to ask the LDAP server; this would trigger a name resolution for the LDAP server, and so on in an infinite loop."
msgstr ""

msgid "If the LDAP server should be considered authoritative (and the local files used by the <command>files</command> module disregarded), services can be configured with the following syntax:"
msgstr ""

msgid "<literal><replaceable>service</replaceable>: ldap [NOTFOUND=return] files</literal>."
msgstr ""

msgid "If the requested entry does not exist in the LDAP database, the query will return a “not existing” reply even if the resource does exist in one of the local files; these local files will only be used when the LDAP service is down."
msgstr ""

msgid "Configuring PAM"
msgstr ""

msgid "This section describes a PAM configuration (see sidebar <xref linkend=\"sidebar.intro-pam\" />) that will allow applications to perform the required authentications against the LDAP database."
msgstr ""

msgid "<emphasis>CAUTION</emphasis> Broken authentication"
msgstr ""

msgid "Changing the standard PAM configuration used by various programs is a sensitive operation. A mistake can lead to broken authentication, which could prevent logging in. Keeping a root shell open is therefore a good precaution. If configuration errors occur, they can be then fixed and the services restarted with minimal effort."
msgstr ""

msgid "The LDAP module for PAM is provided by the <emphasis role=\"pkg\">libpam-ldap</emphasis> package. Installing this package asks a few questions very similar to those in <emphasis role=\"pkg\">libnss-ldap</emphasis>; some configuration parameters (such as the URI for the LDAP server) are even actually shared with the <emphasis role=\"pkg\">libnss-ldap</emphasis> package. Answers are summarized in <xref linkend=\"tab-libpam-ldap\" xrefstyle=\"select: label nopage\" />."
msgstr ""

msgid "<primary><emphasis>libpam-ldap</emphasis></primary>"
msgstr ""

msgid "Configuration of <emphasis>libpam-ldap</emphasis>"
msgstr ""

msgid "Allow LDAP admin account to behave like local root?"
msgstr ""

msgid "Yes. This allows using the usual <command>passwd</command> command for changing passwords stored in the LDAP database."
msgstr ""

msgid "Does the LDAP database require logging in?"
msgstr ""

msgid "the LDAP database administrative password"
msgstr ""

msgid "Local encryption algorithm to use for passwords"
msgstr ""

msgid "crypt"
msgstr ""

msgid "Installing <emphasis role=\"pkg\">libpam-ldap</emphasis> automatically adapts the default PAM configuration defined in the <filename>/etc/pam.d/common-auth</filename>, <filename>/etc/pam.d/common-password</filename> and <filename>/etc/pam.d/common-account</filename> files. This mechanism uses the dedicated <command>pam-auth-update</command> tool (provided by the <emphasis role=\"pkg\">libpam-runtime</emphasis> package). This tool can also be run by the administrator should they wish to enable or disable PAM modules."
msgstr ""

msgid "<primary><filename>common-auth</filename></primary>"
msgstr ""

msgid "<primary><filename>/etc/pam.d/common-auth</filename></primary>"
msgstr ""

msgid "<primary><filename>common-password</filename></primary>"
msgstr ""

msgid "<primary><filename>/etc/pam.d/common-password</filename></primary>"
msgstr ""

msgid "<primary><filename>common-account</filename></primary>"
msgstr ""

msgid "<primary><filename>/etc/pam.d/common-account</filename></primary>"
msgstr ""

msgid "Securing LDAP Data Exchanges"
msgstr ""

msgid "<primary>LDAP</primary><secondary>secure</secondary>"
msgstr ""

msgid "By default, the LDAP protocol transits on the network as cleartext; this includes the (encrypted) passwords. Since the encrypted passwords can be extracted from the network, they can be vulnerable to dictionary-type attacks. This can be avoided by using an extra encryption layer; enabling this layer is the topic of this section."
msgstr ""

msgid "Configuring the Server"
msgstr ""

msgid "<primary><foreignphrase>OpenSSL</foreignphrase></primary><secondary>creating keys</secondary>"
msgstr ""

msgid "<primary>key pair</primary>"
msgstr ""

msgid "The first step is to create a key pair (comprising a public key and a private key) for the LDAP server. The Falcot administrators reuse <emphasis>easy-rsa</emphasis> to generate it (see <xref linkend=\"sect.easy-rsa\" />). Running <command>./easyrsa build-server-full ldap.falcot.com nopass</command> will ask you about the “common name”. The answer to that question <emphasis>must</emphasis> be the fully-qualified hostname for the LDAP server; in our case, <literal>ldap.falcot.com</literal>."
msgstr ""

msgid "This command creates a certificate in the <filename>pki/issued/ldap.falcot.com.crt</filename> file; the corresponding private key is stored in <filename>pki/private/ldap.falcot.com.key</filename>."
msgstr ""

msgid "Now these keys have to be installed in their standard location, and we must make sure that the private file is readable by the LDAP server which runs under the <literal>openldap</literal> user identity:"
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>adduser openldap ssl-cert\n"
"</userinput><computeroutput>Adding user `openldap' to group `ssl-cert' ...\n"
"Adding user openldap to group ssl-cert\n"
"Done.\n"
"# </computeroutput><userinput>mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key\n"
"</userinput><computeroutput># </computeroutput><userinput>chown root:ssl-cert /etc/ssl/private/ldap.falcot.com.key\n"
"</userinput><computeroutput># </computeroutput><userinput>chmod 0640 /etc/ssl/private/ldap.falcot.com.key\n"
"</userinput><computeroutput># </computeroutput><userinput>./eassyrsa gen-dh\n"
"</userinput><computeroutput>\n"
"Note: using Easy-RSA configuration from: ./vars\n"
"\n"
"Using SSL: openssl OpenSSL 1.1.1c  28 May 2019\n"
"Generating DH parameters, 2048 bit long safe prime, generator 2\n"
"This is going to take a long time\n"
"........................................................+..........................................................................+...............................................................................+............\n"
"[...]\n"
"DH parameters of size 2048 created at /home/roland/pki/dh.pem\n"
"\n"
"# </computeroutput><userinput>mv pki/dh.pem /etc/ssl/certs/ldap.falcot.com.pem\n"
"</userinput>"
msgstr ""

msgid "The <command>slapd</command> daemon also needs to be told to use these keys for encryption. The LDAP server configuration is managed dynamically: the configuration can be updated with normal LDAP operations on the <literal>cn=config</literal> object hierarchy, and the server updates <filename>/etc/ldap/slapd.d</filename> in real time to make the configuration persistent. <command>ldapmodify</command> is thus the right tool to update the configuration:"
msgstr ""

msgid "Configuring <command>slapd</command> for encryption"
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>cat &gt;ssl.ldif &lt;&lt;END\n"
"dn: cn=config\n"
"changetype: modify\n"
"add: olcTLSCertificateFile\n"
"olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem\n"
"-\n"
"add: olcTLSCertificateKeyFile\n"
"olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key\n"
"-\n"
"END\n"
"</userinput><computeroutput># </computeroutput><userinput>ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif\n"
"</userinput><computeroutput>SASL/EXTERNAL authentication started\n"
"SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth\n"
"SASL SSF: 0\n"
"modifying entry \"cn=config\"\n"
"</computeroutput>"
msgstr ""

msgid "<emphasis>TOOL</emphasis> <command>ldapvi</command> to edit an LDAP directory"
msgstr ""

msgid "<primary><command>ldapvi</command></primary>"
msgstr ""

msgid "With <command>ldapvi</command>, you can display an LDIF output of any part of the LDAP directory, make some changes in the text editor, and let the tool do the corresponding LDAP operations for you."
msgstr ""

msgid "It is thus a convenient way to update the configuration of the LDAP server, simply by editing the <literal>cn=config</literal> hierarchy."
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config\n"
"</userinput>"
msgstr ""

msgid "The last step for enabling encryption involves changing the <varname>SLAPD_SERVICES</varname> variable in the <filename>/etc/default/slapd</filename> file. We'll play it safe and disable unsecured LDAP altogether."
msgstr ""

msgid "The <filename>/etc/default/slapd</filename> file"
msgstr ""

msgid ""
"\n"
"# Default location of the slapd.conf file or slapd.d cn=config directory. If\n"
"# empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to\n"
"# /etc/ldap/slapd.conf).\n"
"SLAPD_CONF=\n"
"\n"
"# System account to run the slapd server under. If empty the server\n"
"# will run as root.\n"
"SLAPD_USER=\"openldap\"\n"
"\n"
"# System group to run the slapd server under. If empty the server will\n"
"# run in the primary group of its user.\n"
"SLAPD_GROUP=\"openldap\"\n"
"\n"
"# Path to the pid file of the slapd server. If not set the init.d script\n"
"# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf by\n"
"# default)\n"
"SLAPD_PIDFILE=\n"
"\n"
"# slapd normally serves ldap only on all TCP-ports 389. slapd can also\n"
"# service requests on TCP-port 636 (ldaps) and requests via unix\n"
"# sockets.\n"
"# Example usage:\n"
"# SLAPD_SERVICES=\"ldap://127.0.0.1:389/ ldaps:/// ldapi:///\"\n"
"SLAPD_SERVICES=\"ldaps:/// ldapi:///\"\n"
"\n"
"# If SLAPD_NO_START is set, the init script will not start or restart\n"
"# slapd (but stop will still work).  Uncomment this if you are\n"
"# starting slapd via some other means or if you don't want slapd normally\n"
"# started at boot.\n"
"#SLAPD_NO_START=1\n"
"\n"
"# If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,\n"
"# the init script will not start or restart slapd (but stop will still\n"
"# work).  Use this for temporarily disabling startup of slapd (when doing\n"
"# maintenance, for example, or through a configuration management system)\n"
"# when you don't want to edit a configuration file.\n"
"SLAPD_SENTINEL_FILE=/etc/ldap/noslapd\n"
"\n"
"# For Kerberos authentication (via SASL), slapd by default uses the system\n"
"# keytab file (/etc/krb5.keytab).  To use a different keytab file,\n"
"# uncomment this line and change the path.\n"
"#export KRB5_KTNAME=/etc/krb5.keytab\n"
"\n"
"# Additional options to pass to slapd\n"
"SLAPD_OPTIONS=\"\"\n"
msgstr ""

msgid "Configuring the Client"
msgstr ""

msgid "On the client side, the configuration for the <emphasis>libpam-ldap</emphasis> and <emphasis>libnss-ldap</emphasis> modules needs to be modified to use an <literal>ldaps://</literal> URI."
msgstr ""

msgid "LDAP clients also need to be able to authenticate the server. In a X.509 public key infrastructure, public certificates are signed by the key of a certificate authority (CA). With <emphasis>easy-rsa</emphasis>, the Falcot administrators have created their own CA and they now need to configure the system to trust the signatures of Falcot's CA. This can be done by putting the CA certificate in <filename>/usr/local/share/ca-certificates</filename> and running <command>update-ca-certificates</command>."
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt\n"
"</userinput><computeroutput># </computeroutput><userinput>update-ca-certificates\n"
"</userinput><computeroutput>Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.\n"
"Running hooks in /etc/ca-certificates/update.d....\n"
"\n"
"Adding debian:falcot.pem\n"
"done.\n"
"done.\n"
"</computeroutput>"
msgstr ""

msgid "Last but not least, the default LDAP URI and default base DN used by the various command line tools can be modified in <filename>/etc/ldap/ldap.conf</filename>. This will save quite some typing."
msgstr ""

msgid "The <filename>/etc/ldap/ldap.conf</filename> file"
msgstr ""

msgid ""
"#\n"
"# LDAP Defaults\n"
"#\n"
"\n"
"# See ldap.conf(5) for details\n"
"# This file should be world readable but not world writable.\n"
"\n"
"BASE   dc=falcot,dc=com\n"
"URI    ldaps://ldap.falcot.com\n"
"\n"
"#SIZELIMIT      12\n"
"#TIMELIMIT      15\n"
"#DEREF          never\n"
"\n"
"# TLS certificates (needed for GnuTLS)\n"
"TLS_CACERT      /etc/ssl/certs/ca-certificates.crt"
msgstr ""

msgid "Real-Time Communication Services"
msgstr ""

msgid "Real-Time Communication (RTC) services include voice, video/webcam, instant messaging (IM) and desktop sharing. This chapter gives a brief introduction to three of the services required to operate RTC, including a TURN server, SIP server and XMPP server. Comprehensive details of how to plan, install and manage these services are available in the Real-Time Communications Quick Start Guide which includes examples specific to Debian. <ulink type=\"block\" url=\"https://rtcquickstart.org\" />"
msgstr ""

msgid "<primary>VoIP</primary><secondary>server</secondary>"
msgstr ""

msgid "<primary>RTC</primary><secondary>server</secondary>"
msgstr ""

msgid "<primary>Instant Messaging</primary><secondary>server</secondary>"
msgstr ""

msgid "<primary>Chat</primary><secondary>server</secondary>"
msgstr ""

msgid "Both SIP and XMPP can provide the same functionality. SIP is slightly more well known for voice and video while XMPP is traditionally regarded as an IM protocol. In fact, they can both be used for any of these purposes. To maximize connectivity options, it is recommended to run both in parallel."
msgstr ""

msgid "<primary>SIP</primary>"
msgstr ""

msgid "<primary>XMPP</primary>"
msgstr ""

msgid "These services rely on X.509 certificates both for authentication and confidentiality purposes. See <xref linkend=\"sect.x509-cert\" /> for more information."
msgstr ""

msgid "DNS settings for RTC services"
msgstr ""

msgid "RTC services require DNS SRV and NAPTR records. A sample configuration that can be placed in the zone file for <literal>falcot.com</literal>:"
msgstr ""

msgid "<primary>DNS</primary><secondary>SRV record</secondary>"
msgstr ""

msgid "<primary>DNS</primary><secondary>NAPTR record</secondary>"
msgstr ""

msgid ""
"\n"
"; the server where everything will run\n"
"server1            IN     A      198.51.100.19\n"
"server1            IN     AAAA   2001:DB8:1000:2000::19\n"
"\n"
"; IPv4 only for TURN for now, some clients are buggy with IPv6\n"
"turn-server        IN     A      198.51.100.19\n"
"\n"
"; IPv4 and IPv6 addresses for SIP\n"
"sip-proxy          IN     A      198.51.100.19\n"
"sip-proxy          IN     AAAA   2001:DB8:1000:2000::19\n"
"\n"
"; IPv4 and IPv6 addresses for XMPP\n"
"xmpp-gw            IN     A      198.51.100.19\n"
"xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19\n"
"\n"
"; DNS SRV and NAPTR for STUN / TURN\n"
"_stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.\n"
"_turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.\n"
"@           IN NAPTR  10 0 \"s\" \"RELAY:turn.udp\" \"\" _turn._udp.falcot.com.\n"
"\n"
"; DNS SRV and NAPTR records for SIP\n"
"_sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.\n"
"@           IN NAPTR  10 0 \"s\" \"SIPS+D2T\" \"\" _sips._tcp.falcot.com.\n"
"\n"
"; DNS SRV records for XMPP Server and Client modes:\n"
"_xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.\n"
"_xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com."
msgstr ""

msgid "TURN Server"
msgstr ""

msgid "TURN is a service that helps clients behind NAT routers and firewalls to discover the most efficient way to communicate with other clients and to relay the media streams if no direct media path can be found. It is highly recommended that the TURN server is installed before any of the other RTC services are offered to end users."
msgstr ""

msgid "<primary>TURN</primary><secondary>server</secondary>"
msgstr ""

msgid "TURN and the related ICE protocol are open standards. To benefit from these protocols, maximizing connectivity and minimizing user frustration, it is important to ensure that all client software supports ICE and TURN."
msgstr ""

msgid "<primary>ICE</primary>"
msgstr ""

msgid "For the ICE algorithm to work effectively, the server must have two public IPv4 addresses."
msgstr ""

msgid "Install the <emphasis role=\"pkg\">coturn</emphasis> package and edit the <filename>/etc/turnserver.conf</filename> configuration file. By default, a SQLite database is configured in /var/db/turndb for user account settings, but PostgreSQL, MySQL or Redis can be set up instead if preferred. The most important thing to do is insert the IP addresses of the server."
msgstr ""

#, fuzzy
#| msgid "<primary>Squid</primary>"
msgid "<primary>coturn</primary>"
msgstr "<primary>Squid</primary>"

msgid "The server can be started running <command>/usr/bin/turnserver</command>. We want the server to be an an automatically started system service, so we edit the <filename>/etc/default/coturn</filename> file like this:"
msgstr ""

msgid ""
"\n"
"#\n"
"# Uncomment it if you want to have the turnserver running as\n"
"# an automatic system service daemon\n"
"#\n"
"TURNSERVER_ENABLED=1"
msgstr ""

msgid "By default, the TURN server uses anonymous access. We have to add the users we want to use:"
msgstr ""

msgid ""
"<computeroutput># </computeroutput><userinput>turnadmin -a -u roland -p <replaceable>secret_password</replaceable> -r falcot.com</userinput>\n"
"<computeroutput># </computeroutput><userinput>turnadmin -A -u admin -p <replaceable>secret_password</replaceable></userinput>"
msgstr ""

msgid "We use the argument <literal>-a</literal> to add a normal user and <literal>-A</literal> to add an admin user."
msgstr ""

msgid "SIP Proxy Server"
msgstr ""

msgid "A SIP proxy server manages the incoming and outgoing SIP connections between other organizations, SIP trunking providers, SIP PBXes such as Asterisk, SIP phones, SIP-based softphones and WebRTC applications."
msgstr ""

msgid "<primary>SIP</primary><secondary>server</secondary>"
msgstr ""

msgid "<primary>SIP</primary><secondary>proxy</secondary>"
msgstr ""

msgid "<primary>SIP</primary><secondary>PBX</secondary>"
msgstr ""

msgid "<primary>SIP</primary><secondary>trunk</secondary>"
msgstr ""

msgid "It is strongly recommended to install and configure the SIP proxy before attempting a SIP PBX setup. The SIP proxy normalizes a lot of the traffic reaching the PBX and provides greater connectivity and resilience."
msgstr ""

msgid "Install the SIP proxy"
msgstr ""

msgid "Install the <emphasis role=\"pkg\">kamailio</emphasis> package and the package for the database backend, the Falcot administrators chose MySQL, so they install <emphasis role=\"pkg\">mariadb-server</emphasis>. <filename>/etc/kamailio/kamctlrc</filename> is the configuration file for the control tools <command>kamctl</command> and <command>kamdbctl</command>. You need to edit and set the <literal>SIP_DOMAIN</literal> to your SIP service domain and set the <literal>DBENGINE</literal> to MySQL, another database backend can be used."
msgstr ""

msgid ""
"\n"
"[...]\n"
"## your SIP domain\n"
"SIP_DOMAIN=sip.falcot.com\n"
"\n"
"## chrooted directory\n"
"# $CHROOT_DIR=\"/path/to/chrooted/directory\"\n"
"\n"
"## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE\n"
"# by default none is loaded\n"
"#\n"
"# If you want to setup a database with kamdbctl, you must at least specify\n"
"# this parameter.\n"
"DBENGINE=MYSQL\n"
"[...]"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>Kamailio</primary>"
msgstr "<primary>Samba</primary>"

msgid "Now we focus on the configuration file <filename>/etc/kamailio/kamailio.cfg</filename>. Falcot needs user authentication and persistent user location, so they add the following <literal>#!define</literal> directives at the top of that file:"
msgstr ""

msgid ""
"\n"
"#!KAMAILIO\n"
"#\n"
"# Kamailio (OpenSER) SIP Server v5.2 - default configuration script\n"
"#     - web: https://www.kamailio.org\n"
"#     - git: https://github.com/kamailio/kamailio\n"
"#!define WITH_MYSQL\n"
"#!define WITH_AUTH\n"
"#!define WITH_USRLOCDB\n"
"[...]\n"
"        "
msgstr ""

msgid "Kamailio needs a database structure that we can create running <command>kamdbctl create</command> as root."
msgstr ""

msgid "Finally, we can add some users with <command>kamctl</command>."
msgstr ""

msgid "<computeroutput># </computeroutput><userinput>kamctl add <replaceable>roland</replaceable> <replaceable>secret_password</replaceable></userinput>"
msgstr ""

msgid "Once everything is properly configured you can start or restart the service with <command>systemctl restart kamailio</command>, you can connect with a SIP client providing the ip address and the port (5090 is the default port). The users have the following id: <literal><replaceable>roland</replaceable>@<replaceable>sip.falcot.com</replaceable></literal>, and they can login using a client (see <xref linkend=\"sect.rtc-clients\" />)"
msgstr ""

msgid "XMPP Server"
msgstr ""

msgid "An XMPP server manages connectivity between local XMPP users and XMPP users in other domains on the public Internet."
msgstr ""

msgid "<primary>XMPP</primary><secondary>server</secondary>"
msgstr ""

msgid "<emphasis>VOCABULARY</emphasis> XMPP or Jabber?"
msgstr ""

msgid "<primary>Jabber</primary>"
msgstr ""

msgid "XMPP is sometimes referred to as Jabber. In fact, Jabber is a trademark and XMPP is the official name of the standard."
msgstr ""

msgid "Prosody is a popular XMPP server that operates reliably on Debian servers."
msgstr ""

msgid "<primary>Prosody</primary>"
msgstr ""

msgid "Install the XMPP server"
msgstr ""

msgid "Install the <emphasis role=\"pkg\">prosody</emphasis> package."
msgstr ""

msgid "Review the <filename>/etc/prosody/prosody.cfg.lua</filename> configuration file. The most important thing to do is insert JIDs of the users who are permitted to manage the server."
msgstr ""

msgid ""
"\n"
"admins = { \"joe@falcot.com\" }"
msgstr ""

msgid "An individual configuration file is also needed for each domain. Copy the sample from <filename>/etc/prosody/conf.avail/example.com.cfg.lua</filename> and use it as a starting point. Here is <literal>falcot.com.cfg.lua</literal>:"
msgstr ""

msgid ""
"\n"
"VirtualHost \"falcot.com\"\n"
"        enabled = true\n"
"        ssl = {\n"
"                key = \"/etc/ssl/private/falcot.com-key.pem\";\n"
"                certificate = \"/etc/ssl/public/falcot.com.pem\";\n"
"                }\n"
"\n"
"-- Set up a MUC (multi-user chat) room server on conference.example.com:\n"
"Component \"conference.falcot.com\" \"muc\""
msgstr ""

msgid "To enable the domain, there must be a symlink from <filename>/etc/prosody/conf.d/</filename>. Create it that way:"
msgstr ""

msgid "<computeroutput># </computeroutput><userinput>ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/</userinput>"
msgstr ""

msgid "Restart the service to use the new configuration."
msgstr ""

msgid "Managing the XMPP server"
msgstr ""

msgid "Some management operations can be performed using the <literal>prosodyctl</literal> command line utility. For example, to add the administrator account specified in <filename>/etc/prosody/prosody.cfg.lua</filename>:"
msgstr ""

msgid ""
"\n"
"# prosodyctl adduser joe@falcot.com"
msgstr ""

msgid "See the <ulink url=\"https://prosody.im/doc/configure\"> Prosody online documentation</ulink> for more details about how to customize the configuration."
msgstr ""

msgid "Running services on port 443"
msgstr ""

msgid "Some administrators prefer to run all of their RTC services on port 443. This helps users to connect from remote locations such as hotels and airports where other ports may be blocked or Internet traffic is routed through HTTP proxy servers."
msgstr ""

msgid "To use this strategy, each service (SIP, XMPP and TURN) needs a different IP address. All the services can still be on the same host as Linux supports multiple IP addresses on a single host. The port number, 443, must be specified in the configuration files for each process and also in the DNS SRV records."
msgstr ""

msgid "Adding WebRTC"
msgstr ""

msgid "Falcot wants to let customers make phone calls directly from the web site. The Falcot administrators also want to use WebRTC as part of their disaster recovery plan, so staff can use web browsers at home to log in to the company phone system and work normally in an emergency."
msgstr ""

msgid "<primary>WebRTC</primary>"
msgstr ""

msgid "<primary>SIP</primary><secondary>WebSockets</secondary>"
msgstr ""

msgid "<emphasis>IN PRACTICE</emphasis> Try WebRTC"
msgstr ""

msgid "<primary>WebRTC</primary><secondary>demonstration</secondary>"
msgstr ""

msgid "If you have not tried WebRTC before, there are various sites that give an online demonstration and test facilities. <ulink type=\"block\" url=\"https://www.sip5060.net/test-calls\" />"
msgstr ""

msgid "WebRTC is a rapidly evolving technology and it is essential to use packages from the <emphasis role=\"distribution\">Testing</emphasis> distribution. Another option is to compile the software."
msgstr ""

msgid "WebRTC uses a simple API to provide browsers and mobile applications with RTC, it is free software and it is being developed by Google. <ulink type=\"block\" url=\"https://webrtc.org\" />"
msgstr ""

msgid "A very flexible approach is using GStreamer's WebRTC implementation. It enables pipeline-based multimedia applications, which allows developing interesting and highly efficient applications. A good starting point is the following demo by Centricular, the main company that is developing it: <ulink type=\"block\" url=\"https://github.com/centricular/gstwebrtc-demos\" />"
msgstr ""

#, fuzzy
#| msgid "<primary>Samba</primary>"
msgid "<primary>GStreamer</primary>"
msgstr "<primary>Samba</primary>"

msgid "More advanced click-to-call web sites typically use server-side scripting to generate the <literal>config.js</literal> file dynamically. The <ulink url=\"https://www.drupal.org/project/drucall\">DruCall</ulink> source code demonstrates how to do this with PHP."
msgstr ""

msgid "<primary>DruCall</primary>"
msgstr ""

msgid "This chapter sampled only a fraction of the available server software; however, most of the common network services were described. Now it is time for an even more technical chapter: we'll go into deeper detail for some concepts, describe massive deployments and virtualization."
msgstr ""