0 - en to ja translation catalogue (387 entries)

en: Network Services: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN
ja: ネットワークサービス、Postfix、Apache、NFS、Samba、Squid、LDAP、SIP、XMPP、TURN

en: 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" />.
ja: ネットワークサービスはユーザが毎日の仕事で直接使用するプログラムです。ネットワークサービスは情報システムの氷山の一角で、この章ではネットワークサービスに注目します。そして、水面下に隠された部分は既に説明したインフラに依存しています。ネットワークサービスは通常、<xref linkend="sect.x509-cert" />に記述された暗号化技術を使用します。

en: Mail Server
ja: メールサーバ

en: 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.
ja: Falcot Corp の管理者は信頼性と設定の容易さから電子メールサーバに Postfix を選びました。実際、Postfix の設計によりそれぞれのタスクは必要な最低限のパーミッションを持つ単独のプロセスとして実装されることが強制されます。この制限によりセキュリティ問題を大きく軽減させることが可能です。

en: <primary>email</primary><secondary>server</secondary>
ja: <primary sortas="デンシメール">電子メール</primary><secondary>サーバ</secondary>

en: <primary>email</primary><secondary>Postfix</secondary>
ja: <primary sortas="デンシメール">電子メール</primary><secondary>Postfix</secondary>

en: <primary>server</primary><secondary>email</secondary>
ja: <primary>サーバ</primary><secondary>電子メール</secondary>

en: <primary>server</primary><secondary>SMTP</secondary>
ja: <primary>サーバ</primary><secondary>SMTP</secondary>

en: <primary>mail server</primary>
ja: <primary>メールサーバ</primary>

en: <emphasis>ALTERNATIVE</emphasis> The Exim4 server
ja: <emphasis>ALTERNATIVE</emphasis> Exim4 サーバ

en: <primary>email</primary><secondary>Exim</secondary>
ja: <primary sortas="デンシメール">電子メール</primary><secondary>Exim</secondary>

en: 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.
ja: Debian はデフォルト電子メールサーバとして Exim4 を使います (そのため Exim4 は Debian の初回インストール時に導入されます)。Exim4 の設定は別のパッケージ <emphasis role="pkg">exim4-config</emphasis> で提供され、Debconf を使った一連の質問に答えることで自動的にカスタマイズされます。この質問は <emphasis role="pkg">postfix</emphasis> パッケージの行う質問とよく似ています。

en: 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.
ja: 設定は単独の設定ファイル (<filename>/etc/exim4/exim4.conf.template</filename>) か <filename>/etc/exim4/conf.d/</filename> の下に保存された数多くの設定ファイルを通じて行われます。どちらの場合も、<command>update-exim4.conf</command> が設定ファイルをテンプレートとして利用して <filename>/var/lib/exim4/config.autogenerated</filename> を生成します。実際 Exim4 が使うファイルが <filename>/var/lib/exim4/config.autogenerated</filename> です。このメカニズムのおかげで、debconf を通じて Exim に設定した値 (<filename>/etc/exim4/update-exim4.conf.conf</filename> に保存されている値) は管理者や他のパッケージがデフォルトの Exim 設定を変更した場合でも Exim の設定ファイルに反映されます。

en: Installing Postfix
ja: Postfix のインストール

en: 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.
ja: Debconf はパッケージのインストール中にいくつかの質問を行います。これに答えることで、<filename>/etc/postfix/main.cf</filename> 設定ファイルの最初のバージョンが作成されます。

en: 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.
ja: 最初の質問はセットアップの形式に関するものです。インターネットに接続されたサーバに関連するのは提案された選択肢のうちの 2 種類だけです。「インターネットサイト」と「スマートホスト付きインターネット」です。「インターネットサイト」は入って来る電子メールを受け取り、外に出る電子メールを直接受信者に送信するサーバに適します。つまり Falcot Corp の場合にうまく適合します。「スマートホスト付きインターネット」は入って来る電子メールを通常通り受け取り、外に出る電子メールを直接受信者のサーバに送信するのではなく中間 SMTP サーバ「スマートホスト」を介して送信するサーバに適します。この選択肢は主に動的 IP アドレスを持つマシンで役に立ちます。なぜなら、多くの電子メールサーバは動的 IP アドレスを持つホストから配送されたメッセージを拒否するからです。この選択肢を選んだ場合、通常スマートホストに自分の ISP の SMTP サーバを設定します。ISP の SMTP サーバは自分の顧客からの電子メールを受け入れ、それを適切に転送するよう常に設定されています。この (スマートホストを使う) 選択肢はさらにインターネットから切断される可能性のあるサーバにも適しています。なぜなら、後から再試行する必要のある未配送メッセージのキューを管理する必要がなくなるからです。

en: 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.
ja: 2 番目の質問はマシンのフルネームに関するもので、これはローカルユーザの電子メールアドレスを生成するために使われます。従って、マシンのフルネームとはアットマーク (「@」) のすぐ後ろに付けられるものです。Falcot の場合、この質問には <literal>mail.falcot.com</literal> と答えるべきです。デフォルトで聞かれる質問は以上ですが、Falcot にとってこの状態の Postfix はまだ十分に設定されていません。このため、管理者は <command>dpkg-reconfigure postfix</command> を実行してさらに多くのパラメータをカスタマイズします。

en: 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>.
ja: <command>dpkg-reconfigure postfix</command> を実行したことで追加的に行われる質問の 1 つに、このマシンに関連するすべてのドメイン名を尋ねる質問があります。デフォルトで挙げられるドメイン名のリストには、マシンのフルネームといくつかの <literal>localhost</literal> の同義語が含まれていますが、主要なドメイン名である <literal>falcot.com</literal> を手作業で追加する必要があります。より一般的に言えば、この質問の回答には、通常 MX サーバを担当しているマシンに割り当てたすべてのドメイン名を含めるべきです。さらに言い換えれば、DNS の MX レコードを参照した際に電子メールを受け入れるサーバとして登録されているすべてのドメイン名を含めるべきです。この情報は最終的に Postfix 主要設定ファイル <filename>/etc/postfix/main.cf</filename> の <literal>mydestination</literal> 変数に設定されます。

en: <primary>server</primary><secondary>MX</secondary>
ja: <primary>サーバ</primary><secondary>MX</secondary>

en: <primary>MX</primary><secondary>server</secondary>
ja: <primary>MX</primary><secondary>サーバ</secondary>

en: Role of the DNS <emphasis>MX</emphasis> record while sending a mail
ja: メール送信における DNS <emphasis>MX</emphasis> レコードの役割

en: <emphasis>EXTRA</emphasis> Querying the MX records
ja: <emphasis>EXTRA</emphasis> MX レコードの問い合わせ

en: 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).
ja: 宛先アドレスの DNS に MX レコードが含まれない場合、電子メールサーバは宛先アドレスの A レコード (IPv6 の場合 AAAA レコード) に送信することを試みます。

en: 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.
ja: インストール中に、このサーバが電子メールの送信要求を受け入れるネットワークを尋ねられる場合があります。デフォルトの設定で、Postfix はマシン自身からの電子メールの送信要求だけを受け入れます。従って、通常はローカルネットワークからの送信要求も受け入れるように設定します。Falcot Corp の管理者はデフォルトの回答に <literal>192.168.0.0/16</literal> を追加しました。この質問が尋ねられなければ、以下の例に示す通り、設定ファイル中の関連する変数 <literal>mynetworks</literal> にローカルネットワークを追加します。

en: <primary>email</primary><secondary>filtering</secondary>
ja: <primary sortas="デンシメール">電子メール</primary><secondary>フィルタ</secondary>

en: <primary>filtering email</primary>
ja: <primary>フィルタ</primary><secondary sortas="デンシメール">電子メール</secondary>

en: 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.
ja: 最初のステップの後、以下の設定ファイルが得られます。さらに次の節では、いくつかの特別な機能を追加するための足掛かりとしてこれを使います。

en: Initial <filename>/etc/postfix/main.cf</filename> file
ja: 最初の <filename>/etc/postfix/main.cf</filename> ファイル

en: <emphasis>SECURITY</emphasis> <emphasis>Snake oil</emphasis> SSL certificates
ja: <emphasis>SECURITY</emphasis> <emphasis>Snake oil</emphasis> SSL 証明書

en: Configuring Virtual Domains
ja: 仮想ドメインの設定

en: <primary>domain</primary><secondary>virtual</secondary>
ja: <primary>ドメイン</primary><secondary sortas="カソウ">仮想</secondary>

en: <emphasis>CAUTION</emphasis> Virtual domains and canonical domains
ja: <emphasis>CAUTION</emphasis> 仮想ドメインとカノニカルドメイン

en: 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.
ja: <literal>mydestination</literal> 変数の中で仮想ドメインを参照してはいけません。すなわち <literal>mydestination</literal> 変数に指定できるのはマシンとローカルユーザに直接的に関連付けられた「カノニカル」ドメインの名前だけです。

en: Virtual Alias Domains
ja: 仮想エイリアスドメイン

en: <primary>alias</primary><secondary>virtual alias domain</secondary>
ja: <primary>エイリアス</primary><secondary sortas="カソウエイリアスドメイン">仮想エイリアスドメイン</secondary>

en: A virtual alias domain only contains aliases, i.e. addresses that only forward emails to other addresses.
ja: 仮想エイリアスドメインにはエイリアスだけが含まれます。たとえば、電子メールを他のアドレスに転送するだけのアドレスがこれに該当します。

en: 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.
ja: 仮想エイリアスドメインを有効化するには、<literal>virtual_alias_domains</literal> 変数にそのドメイン名を追加し、<literal>virtual_alias_maps</literal> 変数でアドレスマッピングファイルを参照します。

en: 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.
ja: <filename>/etc/postfix/virtual</filename> ファイルはかなり直接的な構文で対応付けを記述します。すなわち、各行には空白で分割された 2 つのフィールドが含まれます。最初のフィールドは仮想エイリアス名、2 番目のフィールドはリダイレクトする電子メールアドレスのリストです。<literal>@domain.com</literal> 特殊構文を使うことで、そのドメインに含まれるすべての残りの別名をカバーすることも可能です。

en: Virtual Mailbox Domains
ja: 仮想メールボックスドメイン

en: <primary>mailbox, virtual domain</primary>
ja: <primary>メールボックス</primary><secondary sortas="カソウドメイン">仮想ドメイン</secondary>

en: <emphasis>CAUTION</emphasis> Combined virtual domain?
ja: <emphasis>CAUTION</emphasis> 統合された仮想ドメイン?

en: 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.
ja: Postfix は <literal>virtual_alias_domains</literal> と <literal>virtual_mailbox_domains</literal> で同じドメインを使うことを許しません。しかしながら、<literal>virtual_mailbox_domains</literal> の各ドメインは明示せずとも <literal>virtual_alias_domains</literal> に含まれます。そのおかげで、仮想ドメインの中でエイリアスとメールボックスを混在させることが可能になります。

en: Messages addressed to a virtual mailbox domain are stored in mailboxes not assigned to a local system user.
ja: 仮想メールボックスドメイン宛のメッセージはローカルシステムユーザに割り当てられていないメールボックスに保存されます。

en: 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.
ja: 仮想メールボックスドメインを有効化するには、<literal>virtual_mailbox_domains</literal> 変数にそのドメイン名を追加し、<literal>virtual_mailbox_maps</literal> 変数でメールボックスマッピングファイルを参照します。<literal>virtual_mailbox_base</literal> パラメータには、メールボックスが保存されるディレクトリを指定します。

en: 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).
ja: <literal>virtual_uid_maps</literal> (および <literal>virtual_gid_maps</literal>) パラメータは電子メールアドレスとそれに対応するメールボックスを「所有する」システムユーザ (およびグループ) の対応関係を含むファイルを参照します。すべてのメールボックスを同じ所有者とグループによって所有されるようにするには <literal>static:5000</literal> 構文を使って固定された UID/GID (ここでは 5000) を割り当てるようにします。

en: 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.
ja: 繰り返しになりますが、<filename>/etc/postfix/vmailbox</filename> ファイルの構文はかなり直接的です。つまり、空白で分けられた 2 種類のフィールドで対応関係を表現します。最初のフィールドは仮想ドメインの 1 つに属する電子メールアドレスで、2 番目のフィールドは関連するメールボックスの場所です (これは <emphasis>virtual_mailbox_base</emphasis> 以下から見た相対ディレクトリパスを指定します)。メールボックスの名前がスラッシュ (<literal>/</literal>) で終わっていた場合、電子メールは <emphasis>maildir</emphasis> フォーマットで保存されます。一方、そうでなければ伝統的な <emphasis>mbox</emphasis> フォーマットで保存されます。<emphasis>maildir</emphasis> フォーマットはメールボックスを保存するためにディレクトリ全体を使い、それぞれのメッセージは 1 つのファイルとして保存されます。これに対して、<emphasis>mbox</emphasis> フォーマットでは、メールボックス全体が 1 つのファイルに保存されます。「<literal>From </literal>」(<literal>From</literal> の後に 1 つの空白) で始まる行が新しいメッセージの始まる目印です。

en: 
    # Jean's email is stored as maildir, with
    # one file per email in a dedicated directory
    jean@falcot.org falcot.org/jean/
    # Sophie's email is stored in a traditional "mbox" file,
    # with all mails concatenated into one single file
    sophie@falcot.org falcot.org/sophie
ja: 
    # Jean 宛の電子メールは専用ディレクトリ内の 1 ファイルを
    # 1 メールに対応付ける maildir フォーマットで保存されます
    jean@falcot.org falcot.org/jean/
    # Sophie 宛の電子メールは 1 ファイルにすべてのメールを
    # 連結する伝統的な "mbox" ファイルに保存されます
    sophie@falcot.org falcot.org/sophie

en: Restrictions for Receiving and Sending
ja: 受信と送信の制限

en: 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.
ja: 迷惑メール (<emphasis>スパム</emphasis>) の数が増加したことにより、サーバが受け入れる電子メールの判断基準をますます厳しくすることが要求されるようになっています。この節では Postfix が備えるいくつかの戦略を紹介します。

en: <emphasis>CULTURE</emphasis> The spam problem
ja: <emphasis>CULTURE</emphasis> スパム問題

en: <primary>spam</primary>
ja: <primary>スパム</primary>

en: 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!
ja: すべてのシステム管理者はスパムフィルタを使ってこの迷惑行為に立ち向かうことを試みます。しかし、もちろんスパマーはスパムフィルタを対処するように調整を続けます。一部のスパマーはさまざまな犯罪組織によりワームに感染させられたマシンのネットワークを借りるかもしれません。最近の統計によればインターネット上を流れるすべての電子メールの 95% 超がスパムであると推定されています!

en: IP-Based Access Restrictions
ja: IP に基づくアクセス制限

en: The <literal>smtpd_client_restrictions</literal> directive controls which machines are allowed to communicate with the email server.
ja: <literal>smtpd_client_restrictions</literal> 指示文を使うことで、電子メールサーバと通信することを許すマシンを制御することが可能です。

en: Restrictions Based on Client Address
ja: クライアントアドレスに基づく制限

en: <emphasis>TIP</emphasis> <emphasis>access</emphasis> tables
ja: <emphasis>TIP</emphasis> <emphasis>access</emphasis> テーブル

en: <emphasis>TIP</emphasis> White list and RBLs
ja: <emphasis>TIP</emphasis> ホワイトリストと RBL

en: 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>.
ja: ブラックリストには過去に異常が発生した正当なサーバが含まれることもあります。この場合、そのようなサーバからのすべての電子メールは拒否されます。これを受け入れるには <filename>/etc/postfix/access_clientip</filename> によって定義されたホワイトリストの中にそのサーバをリストするしかありません。

en: Checking the Validity of the <literal>EHLO</literal> or <literal>HELO</literal> Commands
ja: <literal>EHLO</literal> または <literal>HELO</literal> コマンドの妥当性確認

en: Restrictions on the name announced in <literal>EHLO</literal>
ja: <literal>EHLO</literal> の引数に与えられる名前の制限

en: 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.
ja: 最初の <literal>permit_mynetworks</literal> 指示文を使うことで、ローカルネットワーク上のすべてのマシンならば <literal>HELO</literal> コマンドの引数にどのような名前を使っても良いことになります。これは重要です。なぜなら、一部の電子メールプログラムは SMTP プロトコルのこの部分を十分適切に尊重せず <literal>HELO</literal> の引数に無意味な名前を使うからです。

en: <primary>email</primary><secondary>filtering on the sender</secondary>
ja: <primary sortas="デンシメール">電子メール</primary><secondary sortas="ソウシンシャアドレスニモトヅクフィルタリング">送信者アドレスに基づくフィルタリング</secondary>

en: 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.
ja: 各メッセージには送信者アドレスが必要です。送信者アドレスは SMTP プロトコルの <literal>MAIL FROM</literal> コマンドで申告されます。繰り返しになりますが、さまざまな異なる方法で送信者アドレスの有効性を判断します。

en: Sender checks
ja: 送信者アドレスの確認

en: 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.
ja: <literal>check_sender_access</literal> ルールを使うことで、<filename>/etc/postfix/access_sender</filename> テーブルで指定した一部の送信者を特別扱いすることが可能です。このルールは一部の送信者をホワイトリストやブラックリストに入れることを意味します。

en: 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>.
ja: 最後に、<literal>reject_non_fqdn_sender</literal> ルールを使うことで、完全修飾ドメイン名を持たないアドレスから送信されたと称する電子メールを拒否します。具体的には、<literal>user@machine</literal> からの電子メールを拒否します。すなわち、送信者アドレスは必ず <literal>user@machine.example.com</literal> または <literal>user@example.com</literal> の形で申告されなければいけないということです。

en: <primary>email</primary><secondary>filtering on the recipient</secondary>
ja: <primary sortas="デンシメール">電子メール</primary><secondary sortas="ジュシンシャアドレスニモトヅクフィルタリング">受信者アドレスに基づくフィルタリング</secondary>

en: 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.
ja: 各メッセージには少なくとも 1 つの受信者アドレスが必要です。受信者アドレスは SMTP プロトコルの <literal>RCPT TO</literal> コマンドで申告されます。送信者アドレスに対して行った確認よりも関係性は低いとは言うものの、受信者アドレスの正当性を確認することは当然です。

en: Recipient checks
ja: 受信者アドレスの確認

en: <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.
ja: <literal>reject_unauth_destination</literal> は基本的なルールで、受け入れ要求のあったメッセージが自分の管理するユーザ宛であることを確認します。すなわち、このサーバにないアドレス宛のメッセージを拒否するということです。このルールを指定しなかった場合、サーバがスパマーによって迷惑メールを送信するための第三者中継サーバとして使われる可能性が出てきます。このため <literal>reject_unauth_destination</literal> ルールは必須で、ルールリストの先頭に近い位置に置くのが最良です。そうすれば、メッセージの宛先をチェックする前に、他のルールがそのメッセージの受け入れを許可することを避けられます。

en: 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>.
ja: <literal>reject_unlisted_recipient</literal> ルールを使うことで、存在しないローカルユーザ宛のメッセージを拒否するようになります。これは道理に適ったルールです。最後に、<literal>reject_non_fqdn_recipient</literal> ルールを使うことで、完全修飾ドメイン名でないアドレスを拒否するようになります。さらに <literal>reject_non_fqdn_recipient</literal> ルールを使った場合、<literal>jean</literal> や <literal>jean@machine</literal> 宛の電子メールは送信できず、その代わりに <literal>jean@machine.falcot.com</literal> や <literal>jean@falcot.com</literal> などの完全なアドレスを使うことが要求されます。

en: Restrictions Associated with the <literal>DATA</literal> Command
ja: <literal>DATA</literal> コマンドに関連付けられた制限

en: 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.
ja: SMTP の <literal>DATA</literal> コマンドはメッセージ内容の前に送信されます。<literal>DATA</literal> コマンドの後に送信されるメッセージ内容はさておき、厳密な意味では <literal>DATA</literal> コマンドはいかなる情報も提供しません。とは言っても、確認することは可能です。

en: <literal>DATA</literal> checks
ja: <literal>DATA</literal> の確認

en: 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.
ja: <literal>reject_unauth_pipelining</literal> 指示文を使うことで、1 つ前に送信されたコマンドに応答する前に送信者が次のコマンドを送ったメッセージを拒否するようになります。この防御はスパマーロボットの使う一般的な最適化に対抗するものです。なぜなら、スパマーはサーバからの応答の結果を気にせず、可能な限り短い時間で可能な限り大量の電子メールを送信することだけに注目しているからです。

en: Applying Restrictions
ja: 拒否応答の送信段階

en: 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.
ja: これは不正な <literal>EHLO</literal> コマンドが原因でメッセージを拒否する場合でも、Postfix はメッセージの送信者と受信者を知った後に拒否応答を送信することを意味しています。こうすることで、すぐにトランザクションを拒否するよりも明確なログを残すことが可能です。加えて、多くの SMTP クライアントはトランザクションの最初の方の SMTP コマンドの失敗を予期していませんから、<literal>RCPT TO</literal> の後に拒否応答を返したとしても問題になることは少ないです。

en: 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.
ja: こうすることによる最後の利点は SMTP 交換のさまざまなステージの間にやり取りした情報を総合的に検討することが可能であるという点です。これにより、パーミッションをきめ細かく調整することが可能です。たとえば、ローカル送信者のふりをする外部接続を拒否することなどが可能です。

en: Filtering Based on the Message Contents
ja: メッセージ内容に基づくフィルタリング

en: <primary>email</primary><secondary>filtering on contents</secondary>
ja: <primary sortas="デンシメール">電子メール</primary><secondary sortas="ナイヨウニモトヅクフィルタリング">内容に基づくフィルタリング</secondary>

en: 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.
ja: メッセージ内容を確認することにより、妥当性確認と制限システムが完成します。Postfix は電子メール本文や電子メールヘッダの内容に対して確認を適用し、その妥当性を識別することが可能です。

en: Enabling content-based filters
ja: 内容に基づくフィルタの有効化

en: 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.
ja: どちらのファイルにも、正規表現 (<emphasis>regexp</emphasis> または <emphasis>regex</emphasis> としても知られます) のリストおよび、電子メールヘッダ (または本文) がその正規表現にマッチする場合に実行する動作の対応リストが含まれます。

en: <emphasis>QUICK LOOK</emphasis> Regexp tables
ja: <emphasis>QUICK LOOK</emphasis> 正規表現テーブル

en: Example <filename>/etc/postfix/header_checks</filename> file
ja: <filename>/etc/postfix/header_checks</filename> ファイルの例

en: <emphasis>BACK TO BASICS</emphasis> Regular expression
ja: <emphasis>BACK TO BASICS</emphasis> 正規表現

en: 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.
ja: 最初の正規表現は電子メールソフトウェアに関するヘッダを確認します。そして <literal>GOTO Sarbacane</literal> (大量の電子メールを送信するソフトウェア) が見つかったら、メッセージを拒否します。2 番目の正規表現はメッセージの件名を操作します。そしてメッセージの件名にウイルス通知が含まれる場合、そのメッセージを拒否しない代わりにすぐに捨てます。

en: 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.
ja: これらのフィルタを使うことは諸刃の剣です。なぜなら、一般的過ぎるルールを設定すれば結果的に適切なメールを失うことになるからです。そのような場合、メッセージが失われるだけでなく、送信者は望まない (そして煩い) エラーメッセージを受け取ることになるでしょう。

en: Setting Up <foreignphrase>greylisting</foreignphrase>
ja: <foreignphrase>greylisting</foreignphrase> の設定

en: 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.
ja: Postfix それ自身は greylisting 機能を提供しませんが、あるメッセージを受け入れるか拒否するかの決定を外部プログラムに委任する機能を提供します。<emphasis role="pkg">postgrey</emphasis> パッケージには greylisting 機能を提供するプログラムが含まれ、このプログラムはアクセスポリシー委任サービスへのインターフェースとして設計されています。

en: 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:
ja: <emphasis role="pkg">postgrey</emphasis> がインストールされると、<command>postgrey</command> はデーモンとして実行され、ポート 10023 番をリッスンします。この後 Postfix の設定に <literal>check_policy_service</literal> ルールを追加することで、Postfix は <command>postgrey</command> デーモンを使うようになります。

en: 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.
ja: greylisting の主な不都合は正当なメッセージの配送が遅れる点です。この欠点が許容できない場合もあります。さらに、送信するメールのほとんどが正当な場合、greylisting はサーバの負荷を増加させます。

en: <emphasis>IN PRACTICE</emphasis> Shortcomings of greylisting
ja: <emphasis>IN PRACTICE</emphasis> greylisting の欠点

en: 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.
ja: 理論上 greylisting はある送信者からある受信者に送信される最初のメールだけを対象にしており、greylisting による典型的な遅延時間はほぼ数分程度です。しかしながら、実際は少し違います。一部の大きな ISP は複数の SMTP サーバを運用します。このようなサーバ群からメッセージを送信することを考えます。1 回目の送信要求を出すサーバはその送信要求を拒否されますが、2 回目の送信要求を出すサーバは 1 回目のサーバと違う可能性があります。これが起きた場合、2 回目の送信要求を出すサーバは greylisting のおかげでもう一度一時的なエラーメッセージを受け取ります。同様に、3 回目の送信要求を出すサーバが既に受信側の greylisting データベースに登録済みのサーバに一致するのには数時間かかる可能性があります。なぜなら、通常 SMTP サーバは再試行が失敗した場合に遅延時間を増やすからです。

en: 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.
ja: その結果、同じ送信者からであっても送信要求を行う IP アドレスは毎回変わるかもしれません。もっと言えば、送信者アドレスさえも変わる可能性があります。たとえば、多くのメーリングリストサーバはエラーメッセージ (<emphasis>bounce</emphasis> として知られます) を取り扱うために送信者アドレス内の追加的な情報を符号化します。メーリングリスト宛に送信される新しいメッセージは greylisting を通過することが必要かもしれません。これは新しいメッセージが送信者のサーバに (一時的に) 保存されることを意味します。とても巨大な (数万人が登録する) メーリングリストの場合、これは問題になることがあります。

en: 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.
ja: これらの欠点を軽減するために、Postgrey は複数の SMTP サーバを運用するサイトのホワイトリストを管理しています。ホワイトリストに登録されている送信者から送信要求のあったメッセージは greylisting を通過することなしにすぐに受け入れられます。このリストを自分の要求に適用することは簡単です。なぜなら、ホワイトリストは <filename>/etc/postgrey/whitelist_clients</filename> ファイルに保存されているからです。

en: <emphasis>GOING FURTHER</emphasis> Selective greylisting with <emphasis role="pkg">milter-greylist</emphasis>
ja: <emphasis>GOING FURTHER</emphasis> <emphasis role="pkg">milter-greylist</emphasis> を使った選択的 greylisting

en: 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.
ja: メール配送の遅延時間が長くなるという greylisting の欠点を低減するには、既にスパムの発生源と考えられている (DNS ブラックリストに載せられている) サブネットのクライアントだけを対象に greylisting を使います。<emphasis role="pkg">postgrey</emphasis> ではこの機能を使うことができませんが、<emphasis role="pkg">milter-greylist</emphasis> でこの機能を使います。

en: 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>).
ja: この機能を利用する場合、DNS ブラックリストに載っていたからと言って必ず拒否されるわけではなくなるので、より広範囲におよぶブラックリスト (たとえば <literal>pbl.spamhaus.org</literal> や <literal>dul.dnsbl.sorbs.net</literal> など) を使うことが妥当です。そのようなブラックリストには、ISP クライアントからのすべての動的 IP アドレスも含まれます。

en: Customizing Filters Based On the Recipient
ja: 受信者アドレスに基づくフィルタのカスタマイズ

en: <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.
ja: <xref linkend="sect.restrictions-for-receiving-and-sending" />と<xref linkend="sect.setting-up-greylisting" />では、さまざまな制限方法を見直しました。これらの制限方法はスパムの受信量を減らすためのものですが、欠点もあります。このため、受信者ごとにフィルタのセットをカスタマイズすることが普通のやり方になりつつあります。Falcot Corp では、greylisting は多くのユーザからすると興味深いものですが、電子メールを素早く受け取りたい一部のユーザ (たとえば技術サポートサービスを担当しているユーザ) からすると仕事の妨げになります。同様に、商業サービス担当からするとブラックリストに載っているかもしれない一部のアジアプロバイダから送信された電子メールを受信できない点は問題となります。従って、商業サービス用のアドレスに対してはフィルタリングを行わず、この種の送信者と連絡が取れるようにするほうが好都合でしょう。

en: 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.
ja: Postfix は「制限クラス」の概念を使ってフィルタをカスタマイズします。制限クラスは <literal>smtpd_restriction_classes</literal> パラメータの中で宣言され、<literal>smtpd_recipient_restrictions</literal> と同じやり方で使用されます。<literal>check_recipient_access</literal> 指示文は与えられた受信者と制限の適切なセットを対応付けるテーブルを定義します。

en: Defining restriction classes in <filename>main.cf</filename>
ja: <filename>main.cf</filename> における制限クラスの定義

en: The <filename>/etc/postfix/recipient_access</filename> file
ja: <filename>/etc/postfix/recipient_access</filename> ファイル

en: 
    # Unfiltered addresses
    postmaster@falcot.com  permissive
    support@falcot.com     permissive
    sales-asia@falcot.com  permissive
    
    # Aggressive filtering for some privileged users
    joe@falcot.com         aggressive
    
    # Special rule for the mailing-list manager
    sympa@falcot.com       reject_unverified_sender
    
    # Greylisting by default
    falcot.com             greylisting
ja: 
    # 無制限に受信するアドレス
    postmaster@falcot.com  permissive
    support@falcot.com     permissive
    sales-asia@falcot.com  permissive
    
    # 特権ユーザに対する積極的なフィルタリング
    joe@falcot.com         aggressive
    
    # メーリングリスト管理者用の特別なルール
    sympa@falcot.com       reject_unverified_sender
    
    # デフォルトの greylisting 設定
    falcot.com             greylisting

en: 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.
ja: <command>clamav-milter</command> はアンチウイルスと電子メールサーバのやり取りを仲介する作業を担当します。<emphasis>milter</emphasis> (<emphasis>mail filter</emphasis> の略) は電子メールサーバに対するインターフェースとして特別に設計されたフィルタプログラムです。milter は標準的なアプリケーションプログラミングインターフェース (API) を使います。API を使うことで電子メールサーバの外にあるフィルタを使うよりも性能が向上します。milter は 最初 <emphasis>Sendmail</emphasis> に導入されましたが、すぐ後に <emphasis>Postfix</emphasis> にも導入されました。

en: <emphasis>QUICK LOOK</emphasis> A milter for Spamassassin
ja: <emphasis>QUICK LOOK</emphasis> SpamAssassin 用の milter

en: 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.
ja: <emphasis role="pkg">spamass-milter</emphasis> パッケージは有名な迷惑メール検出ソフトウェアである <emphasis>SpamAssassin</emphasis> に基づく milter を提供します。これは、(ヘッダを追加することで) スパムと思われるメッセージを注意するために使うことが可能です。さらにスパム度のスコアが指定されたしきい値を超えたらメッセージを拒否することも可能です。

en: 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>”.
ja: <emphasis role="pkg">clamav-milter</emphasis> パッケージをインストールしたら、milter をデフォルトのポートではない適当な TCP ポートで実行するように再設定するべきです。これを行うには、<command>dpkg-reconfigure clamav-milter</command> を実行します。そして「Sendmail とのコミュニケーションインターフェイス」が表示されたら「<literal>inet:10002@127.0.0.1</literal>」と答えます。

en: <emphasis>NOTE</emphasis> Real TCP port vs named socket
ja: <emphasis>NOTE</emphasis> 真の TCP ポート vs 名前付きソケット

en: 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>).
ja: 名前付きソケットではなく実在する TCP ポートを使う理由は、postfix デーモンは chroot された状態で実行されることが多く、その場合名前付きソケットの存在するディレクトリにアクセスできないからです。名前付きソケットを使い、これを chroot 中 (<filename>/var/spool/postfix/</filename>) に入れておくことも可能です。

en: The standard ClamAV configuration fits most situations, but some important parameters can still be customized with <command>dpkg-reconfigure clamav-base</command>.
ja: ClamAV の標準的な設定は多くの状況に適合しますが、<command>dpkg-reconfigure clamav-base</command> を使えばいくつかの重要なパラメータをカスタマイズすることも可能です。

en: 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>:
ja: 最後の段階で、最近設定したフィルタを使うように Postfix を設定します。これは <filename>/etc/postfix/main.cf</filename> に以下の指示文を追加するだけで簡単に設定できます。

en: 
    # Virus check with clamav-milter
    smtpd_milters = inet:[127.0.0.1]:10002
ja: 
    # clamav-milter を使ったウイルスチェック
    smtpd_milters = inet:[127.0.0.1]:10002

en: <emphasis>IN PRACTICE</emphasis> Testing the antivirus
ja: <emphasis>IN PRACTICE</emphasis> アンチウイルスのテスト

en: 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.
ja: このファイルは、本物のウイルスではなくテストファイルです。市場に出ているすべてのアンチウイルスソフトウェアはこのファイルをウイルスと判定しますから、これを使うことでインストールの正しさを確認できます。

en: All messages handled by Postfix now go through the antivirus filter.
ja: これで Postfix を介して送信されるすべてのメッセージはアンチウイルスフィルタを通過するようになります。

en: Authenticated SMTP
ja: SMTP 認証

en: 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.
ja: 電子メールを送信するには SMTP サーバにアクセスできなければいけません。さらに、電子メールを送信するには上で設定した SMTP サーバが必要です。ローミングユーザの場合、SMTP クライアントの設定を定期的に変更する必要があるかもしれません。なぜなら、Falcot の SMTP サーバは明らかに会社に所属しない IP アドレスから受け取ったメッセージを拒否するからです。これに対して 2 つの解決策が存在します。すなわち、ローミングユーザが自分のコンピュータに SMTP サーバをインストールするか、雇用者としての認証を済ませた後に会社のサーバを使うかのどちらか一方です。自分の SMTP サーバをインストールするという解決策は推奨されません。なぜなら、ローミングユーザのコンピュータは永久的にネットワークに接続されているわけではありませんし、問題の起きた際にメッセージを再送信することができないからです。ここでは認証を行うという解決策に注目します。

en: 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>).
ja: Postfix の SMTP 認証は SASL (<emphasis>Simple Authentication and Security Layer</emphasis>) を使っています。SASL を使うには、<emphasis role="pkg">libsasl2-modules</emphasis> と <emphasis role="pkg">sasl2-bin</emphasis> パッケージをインストールして、SASL データベースに SMTP サーバの認証に必要なパスワードをユーザごとに登録する必要があります。パスワードを登録するには、<command>saslpasswd2</command> コマンドを使います。<command>saslpasswd2</command> コマンドはいくつかのパラメータを取ります。<literal>-u</literal> オプションは認証するドメインを定義します。これは Postfix 設定の <literal>smtpd_sasl_local_domain</literal> パラメータと一致しなければいけません。<literal>-c</literal> オプションはユーザを作成します。<literal>-f</literal> オプションは SASL データベースをデフォルト (<filename>/etc/sasldb2</filename>) とは異なる場所に保存することが必要な場合にデータベースファイルの位置を指定します。

en: 
    <computeroutput># </computeroutput><userinput>saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean</userinput>
    <computeroutput>[... type jean's password twice ...]</computeroutput>
ja: 
    <computeroutput># </computeroutput><userinput>saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean</userinput>
    <computeroutput>[... jean のパスワードを 2 回入力します ...]</computeroutput>

en: 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.
ja: SASL データベースは Postfix のディレクトリの中に作成されなければいけない点に注意してください。整合性を確保するために、<command>ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2</command> コマンドを使って <filename>/etc/sasldb2</filename> を Postfix の使うデータベースを指すシンボリックリンクにします。

en: 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.
ja: この後に Postfix が SASL を使うように設定します。<literal>postfix</literal> ユーザを <literal>sasl</literal> グループに追加して、SASL アカウントデータベースにアクセスできるようにします。Postfix で SASL を有効化するには、いくつかの新しいパラメータが必要です。また、SASL 認証されたクライアントが自由に電子メールを送信することを許可するには、<literal>smtpd_recipient_restrictions</literal> パラメータを設定します。

en: Enabling SASL in <filename>/etc/postfix/main.cf</filename>
ja: <filename>/etc/postfix/main.cf</filename> の中で SASL を有効化

en: <emphasis>EXTRA</emphasis> Authenticated SMTP client
ja: <emphasis>EXTRA</emphasis> 認証済み SMTP クライアント

en: 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:
ja: 多くの電子メールクライアントはメッセージを送信する前に SMTP サーバに対して認証依頼する機能を持っており、適切なパラメータを設定するだけで簡単に SASL 認証機能を使うことが可能です。クライアントが SASL 認証機能を持たない場合、ローカル Postfix サーバを使い、リモート SMTP サーバに電子メールを中継するようにローカル Postfix サーバを設定することが次善策です。この場合、ローカル Postfix が SASL を使って認証するクライアントになります。以下に必要なパラメータを示します。

en: 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:
ja: <filename>/etc/postfix/sasl_passwd</filename> ファイルには、<literal>mail.falcot.com</literal> サーバに認証を依頼する際に使うユーザ名とパスワードを含めます。以下に例を示します。

en: As for all Postfix maps, this file must be turned into <filename>/etc/postfix/sasl_passwd.db</filename> with the <command>postmap</command> command.
ja: すべての Postfix のマッピングファイルについて言えることですが、<command>postmap</command> コマンドを使ってこのファイルを <filename>/etc/postfix/sasl_passwd.db</filename> に変換しなければいけません。

en: Web Server (HTTP)
ja: ウェブサーバ (HTTP)

en: <primary>server</primary><secondary>web</secondary>
ja: <primary>サーバ</primary><secondary>ウェブ</secondary>

en: <primary>server</primary><secondary>HTTP</secondary>
ja: <primary>サーバ</primary><secondary>HTTP</secondary>

en: <emphasis>ALTERNATIVE</emphasis> Other web servers
ja: <emphasis>ALTERNATIVE</emphasis> 他のウェブサーバ

en: Installing Apache
ja: Apache のインストール

en: 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.
ja: MPM は Apache が同時要求を処理する方法に大きな影響をおよぼします。<emphasis>worker</emphasis> MPM を選んだ場合、<emphasis>スレッド</emphasis> (軽量プロセス) で同時要求を処理します。これに対して <emphasis>prefork</emphasis> MPM を選んだ場合、あらかじめ生成したプロセスプールで同時要求を処理します。<emphasis>event</emphasis> MPM を選んだ場合、スレッドで同時要求を処理しますが、非アクティブ接続 (特に HTTP <emphasis>keep-alive</emphasis> 機能を使ってオープン状態を維持された接続) に対しては専用の管理スレッドで処理します。

en: <emphasis>SECURITY</emphasis> Execution under the <literal>www-data</literal> user
ja: <emphasis>SECURITY</emphasis> <literal>www-data</literal> ユーザ下の実行

en: 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.
ja: もう一つの可能性はたとえば <emphasis role="pkg">libapache2-mpm-itk</emphasis> の提供する MPM などの専用 MPM を使うことです。<emphasis role="pkg">libapache2-mpm-itk</emphasis> の挙動は普通の MPM と少し異なります。すなわち、この MPM は仮想ホスト (実質的にはページ群) を「隔離」して各仮想ホストを異なるユーザの権限で実行するための MPM です。このため、あるウェブサイトの持つ脆弱性によって他のウェブサイトの所有者の持つファイルが危険にさらされることがなくなります。

en: <emphasis>QUICK LOOK</emphasis> List of modules
ja: <emphasis>QUICK LOOK</emphasis> モジュールのリスト

en: 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>).
ja: Apache はモジュール式サーバで、多くの機能が外部モジュールによって実装されており、主プログラムは初期化の際に外部モジュールを読み込みます。デフォルト設定では、最も一般的なモジュールだけが有効化されていますが、新しいモジュールの有効化は <command>a2enmod <replaceable>module</replaceable></command> を実行するだけで簡単に行うことが可能です。これに対して、モジュールを無効化するコマンドは <command>a2dismod <replaceable>module</replaceable></command> です。実際のところ、これらのプログラムは <filename>/etc/apache2/mods-enabled/</filename> 内に実際のファイル (<filename>/etc/apache2/mods-available/</filename> 内に保存されています) を指すシンボリックリンクを作成 (または削除) しているだけです。

en: 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>).
ja: Apache のデフォルト設定では、ウェブサーバはポート 80 番をリッスンし (<filename>/etc/apache2/ports.conf</filename> の中で設定されています)、<filename>/var/www/html/</filename> ディレクトリに含まれるページを公開します (<filename>/etc/apache2/sites-enabled/000-default.conf</filename> の中で設定されています)。

en: Configuring Virtual Hosts
ja: 仮想ホストの設定

en: A virtual host is an extra identity for the web server.
ja: 仮想ホスト機能を使うことで、単独のウェブサーバで複数のサイトを運用することが可能です。

en: <primary>virtual host</primary>
ja: <primary sortas="カソウホスト">仮想ホスト</primary>

en: 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).
ja: Apache は異なる 2 種類の仮想ホストを取り扱うことが可能です。具体的に言えば、IP アドレス (またはポート番号) とウェブサーバのドメイン名に基づいて仮想ホスト機能が実装されています。IP アドレスに基づく仮想ホスト機能を使う場合、各サイトに異なる IP アドレス (またはポート番号) を割り当てることが必要です。これに対して、ドメイン名に基づく仮想ホスト機能を使う場合、単一の IP アドレス (またはポート番号) で複数のサイトを運用することが可能で、HTTP クライアントの送信するホスト名によってサイトを識別します (こちらの方法は HTTP プロトコルのバージョン 1.1 で動作します。幸いなことに、HTTP バージョン 1.1 はすべてのクライアントが対応していると考えて良い程度に古いプロトコルです)。

en: 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).
ja: IPv4 アドレスの枯渇は (ますます) 進んでいるため、通常は単一の IP アドレスで複数のサイトを運用する方法が好まれます。しかしながら仮想ホストで HTTPS を提供する必要がある場合、ドメイン名に基づく仮想ホスト機能を使うには複雑な設定が必要になります。なぜなら、SSL プロトコルはドメイン名に基づく仮想ホストを必ず考慮するとは限らないからです。SNI 拡張 (<emphasis>Server Name Indication</emphasis>) を使うことで仮想ホスト上でも SSL プロトコルを使うことが可能になりますが、SNI 拡張はすべてのブラウザで正しく使えるとは限りません。1 つのサーバで複数の HTTPS サイトを運用する必要がある場合、HTTPS サイトは通常異なるポートを使うか異なる IP アドレスを使う (IPv6 が役立ちます) ことで識別されます。

en: 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.
ja: Apache 2 のデフォルト設定では、ドメイン名に基づく仮想ホスト機能が有効にされています。加えて、<literal>/etc/apache2/sites-enabled/000-default.conf</literal> ファイルの中でデフォルトの仮想ホストが定義されています。この仮想ホストはクライアントによって送信された要求に一致するホストが見つからない場合に使われます。

en: <emphasis>CAUTION</emphasis> First virtual host
ja: <emphasis>CAUTION</emphasis> 最初に定義された仮想ホスト

en: 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.
ja: 不明な仮想ホストに関する要求は最初に定義された仮想ホストへの要求として処理されます。このため管理者は <literal>www.falcot.com</literal> を最初に定義しています。

en: <emphasis>QUICK LOOK</emphasis> Apache supports SNI
ja: <emphasis>QUICK LOOK</emphasis> Apache の SNI サポート

en: 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.
ja: Apache サーバは <emphasis>Server Name Indication</emphasis> (SNI) と呼ばれる SSL プロトコル拡張をサポートします。SNI 拡張を使うことで、ブラウザは SSL 接続を確立する間の HTTP 要求よりもずっと前にウェブサーバのホスト名を送信することが可能になり、同じサーバ (同じ IP アドレスとポート番号を使うサーバ) で運用されている複数の仮想ホストから要求された仮想ホストを識別します。SNI 拡張を使うことで、Apache は以降のトランザクションで最も適切な SSL 証明書を選びます。

en: 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.
ja: Apache とクライアントの間で通信対象の仮想ホストが決定される前は、Apache は常にデフォルトの仮想ホストの定める証明書を使うでしょう。デフォルトの仮想ホスト以外の仮想ホストへのアクセスを試行するクライアントは警告を表示するかもしれません。なぜなら、クライアントが受け取った証明書はアクセスしようとしているウェブサイトと一致しないからです。幸いなことに、多くのブラウザは SNI を取り扱うことが可能です。具体的に言えば、Microsoft Internet Explorer バージョン 7.0 以降 (かつ Vista 以降)、Mozilla Firefox バージョン 2.0 以降、Apple Safari バージョン 3.2.1 以降、Google Chrome のすべてのバージョンは SNI を取り扱うことが可能です。

en: The Apache package provided in Debian is built with support for SNI; no particular configuration is therefore needed.
ja: Debian の提供する Apache パッケージは SNI サポートを有効化した状態でビルドされています。このため、特別な設定は不要です。

en: 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>.
ja: 仮想ホストを追加するには、<filename>/etc/apache2/sites-available/</filename> にファイルを追加します。<literal>falcot.org</literal> ドメインで運用されるウェブサイトをセットアップするには、以下のファイルを作成し、<command>a2ensite www.falcot.org</command> を使って仮想ホストを有効化するだけで簡単に可能です。

en: The <filename>/etc/apache2/sites-available/www.falcot.org.conf</filename> file
ja: <filename>/etc/apache2/sites-available/www.falcot.org.conf</filename> ファイル

en: 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.
ja: ここまでの設定に従うと、Apache サーバはすべての仮想ホストに対して同じログファイルを使います (仮想ホストの定義に <literal>CustomLog</literal> 指示文を追加すればこの挙動を変えることが可能です)。そのため、ログファイルのフォーマットをカスタマイズして、仮想ホストの名前を含むようにすることが道理に適っています。これを行うには、<filename>/etc/apache2/conf-available/customlog.conf</filename> ファイルを作成してすべてのログファイルに対する新しいフォーマットを定義し (<literal>LogFormat</literal> 指示文を使います)、さらに <command>a2enconf customlog</command> を有効化します。また、<filename>/etc/apache2/sites-available/000-default.conf</filename> ファイルから <literal>CustomLog</literal> 指示文を削除 (またはコメントアウト) しなければいけません。

en: 
    # New log format including (virtual) host name
    LogFormat "%v %h %l %u %t \"%r\" %&gt;s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost
    
    # Now let's use this "vhost" format by default
    CustomLog /var/log/apache2/access.log vhost
ja: 
    # (仮想) ホスト名を含む新しいログフォーマット
    LogFormat "%v %h %l %u %t \"%r\" %&gt;s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost
    
    # 上で定義した "vhost" フォーマットを使用します
    CustomLog /var/log/apache2/access.log vhost

en: Common Directives
ja: よく使われる指示文

en: This section briefly reviews some of the commonly-used Apache configuration directives.
ja: この節では、いくつかのよく使われる Apache 設定指示文を簡単に見直します。

en: <primary>directives, Apache</primary>
ja: <primary sortas="シジブン、Apache">指示文、Apache</primary>

en: 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.
ja: 主要設定ファイルにはいくつかの <literal>Directory</literal> ブロックが含まれます。<literal>Directory</literal> ブロックを使うことで、提供されるファイルの位置に従って、サーバの挙動を変えることが可能です。<literal>Directory</literal> ブロックには通常 <literal>Options</literal> と <literal>AllowOverride</literal> 指示文が含まれます。

en: Directory block
ja: Directory ブロック

en: 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.
ja: <literal>DirectoryIndex</literal> 指示文には、クライアントからディレクトリを要求された場合に応答として送信するファイルのリストを指定します。リスト内の最初に見つかったファイルが応答として使われます。

en: 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:
ja: <literal>Options</literal> 指示文には、有効化するオプションを指定します。<literal>None</literal> を指定するとすべてのオプションが無効化されます。それに対して <literal>All</literal> を指定すると <literal>MultiViews</literal> を除いたすべてのオプションが有効化されます。以下に利用できるオプションを挙げます。

en: <emphasis>BACK TO BASICS</emphasis> <filename>.htaccess</filename> file
ja: <emphasis>BACK TO BASICS</emphasis> <filename>.htaccess</filename> ファイル

en: 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.
ja: <filename>.htaccess</filename> ファイルには、Apache 設定指示文が含まれます。<filename>.htaccess</filename> ファイル内の設定は <filename>.htaccess</filename> ファイルが保存されているディレクトリに含まれる要素が要求された時に強制されます。指示文の有効範囲は <filename>.htaccess</filename> が保存されているディレクトリ以下すべてのサブディレクトリです。

en: Most of the directives that can occur in a <literal>Directory</literal> block are also legal in a <filename>.htaccess</filename> file.
ja: <literal>Directory</literal> ブロック内に書かれたほとんどの指示文は <filename>.htaccess</filename> ファイル内でも使うことが可能です。

en: 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).
ja: <literal>AllowOverride</literal> 指示文には、<filename>.htaccess</filename> ファイルを使って有効化または無効化することを許可するすべてのオプションをリストします。<literal>AllowOverride</literal> 指示文は一般に <literal>ExecCGI</literal> を制限するために使われることが多いです。こうすることで、管理者はウェブサーバ (<literal>www-data</literal> ユーザ) の権限でプログラムを実行することを許可するユーザを選択します。

en: Requiring Authentication
ja: 認証要求

en: <primary>web authentication</primary>
ja: <primary sortas="ウェブニンショウ">ウェブ認証</primary>

en: <filename>.htaccess</filename> file requiring authentication
ja: 認証要求を行う <filename>.htaccess</filename> ファイル

en: <emphasis>SECURITY</emphasis> No security
ja: <emphasis>SECURITY</emphasis> 無意味なセキュリティ

en: 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.
ja: 上の例で使われている <literal>Basic</literal> 認証システムは最低限のセキュリティを提供します。パスワードは平文で送信されます (パスワードは暗号化よりも単純な符号化である <emphasis>base64</emphasis> で符号化されるだけです)。<literal>Basic</literal> 認証システムで「保護」されている文書はネットワークを平文で送信される点も注意するべきです。セキュリティが重要な場合、HTTP 接続全体を SSL で暗号化するべきです。

en: Restricting Access
ja: アクセス制限

en: <primary>web access restriction</primary>
ja: <primary sortas="ウェブアクセスセイゲン">ウェブアクセス制限</primary>

en: 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.
ja: <literal>Require</literal> 指示文は多くの基準を基にアクセスを制限するために使われます。ここではクライアントの IP アドレスに基づいてアクセス制限の基準を定義するのではなく、特にいくつかの <literal>Require</literal> 指示文を <literal>RequireAll</literal> ブロックと組み合わせることでより強力なアクセス制限の基準を表現します。

en: Only allow from the local network
ja: ローカルネットワークからのアクセスだけを許可する例

en: <emphasis>ALTERNATIVE</emphasis> Old syntax
ja: <emphasis>ALTERNATIVE</emphasis> 古い構文

en: The <literal>Allow from</literal> and <literal>Deny from</literal> directives control access restrictions for a directory (and its subdirectories, recursively).
ja: <literal>Allow from</literal> と <literal>Deny from</literal> 指示文を使うことで、あるディレクトリへのアクセスを制御 (とサブディレクトリへのアクセスを再帰的に制御) します。

en: 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).
ja: <literal>Order</literal> 指示文を使うことで、<literal>Allow from</literal> と <literal>Deny from</literal> 指示文を評価する順番をサーバに伝えます。ここでは最後に一致したものが優先されます。具体的に言えば、<literal>Order deny,allow</literal> を使うと、<literal>Deny from</literal> に一致しないホストまたは <literal>Allow from</literal> に一致するホストからのアクセスを許可します。反対に、<literal>Order allow,deny</literal> を使うと、<literal>Allow from</literal> に一致しないホストまたは <literal>Deny from</literal> に一致するホストからのアクセスを拒否します。

en: 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.
ja: <literal>Allow from</literal> と <literal>Deny from</literal> 指示文には、IP アドレス、ネットワーク (たとえば <literal>192.168.0.0/255.255.255.0</literal>、<literal>192.168.0.0/24</literal>、<literal>192.168.0</literal> など)、ホスト名、ドメイン名、全員を意味する <literal>all</literal> キーワードを使うことが可能です。

en: For instance, to reject connections by default but allow them from the local network, you could use this:
ja: たとえば、デフォルトですべてのアクセスを拒否してローカルネットワークからのアクセスだけを許可するには以下の通り設定します。

en: Log Analyzers
ja: ログ解析ソフトウェア

en: 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.
ja: ウェブサーバには、通常ログ解析ソフトウェアがインストールされます。なぜなら、ログ解析ソフトウェアを使うことで管理者はウェブサーバの使用形態に関する正確な知見を得ることが可能だからです。

en: The Falcot Corp administrators selected <emphasis>AWStats</emphasis> (<emphasis>Advanced Web Statistics</emphasis>) to analyze their Apache log files.
ja: Falcot Corp の管理者は <emphasis>AWStats</emphasis> (<emphasis>Advanced Web Statistics</emphasis>) を使って Apache ログファイルを解析することに決めました。

en: <primary>web logs analyzer</primary>
ja: <primary sortas="ウェブログカイセキソフトウェア">ウェブログ解析ソフトウェア</primary>

en: 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:
ja: 最初に <filename>/etc/awstats/awstats.conf</filename> ファイルをカスタマイズして設定を行います。Falcot の管理者は以下のパラメータだけを修正し、他はそのままの状態にしています。

en: 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.
ja: これらのパラメータに関する説明はテンプレートファイルにコメントとして書かれています。特に、<varname>LogFile</varname> と <varname>LogFormat</varname> パラメータを使って、ログファイルの場所とログファイルに含まれる情報の書式を指定します。さらに <varname>SiteDomain</varname> と <varname>HostAliases</varname> は主要ウェブサイトに割り当てている複数の名前をリストします。

en: 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.
ja: トラフックの多いサイトでは通常 <varname>DNSLookup</varname> を <literal>1</literal> に設定するべきではありません。トラフィックの少ないサイトでは Falcot の設定と同様に <varname>DNSLookup</varname> を設定することで、解析結果に生 IP アドレスではなく完全なマシン名が含まれるようになり、解析結果を読みやすくなります。

en: <emphasis>SECURITY</emphasis> Access to statistics
ja: <emphasis>SECURITY</emphasis> 統計へのアクセス

en: 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
ja: AWStats は統計をウェブサイト上で利用できるようにしており、デフォルトでは統計へのアクセスは制限されていません。しかし、ごく少数の (おそらく内部の) IP アドレスだけが統計にアクセスできるように制限をかけることも可能です。アクセスを許可する IP アドレスのリストは <varname>AllowAccessFromWebToFollowingIPAddresses</varname> パラメータで定義する必要があります。

en: 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>.
ja: 他の仮想ホストに対して AWStats を有効化することも可能です。その場合、各仮想ホストに対して <filename>/etc/awstats/awstats.www.falcot.org.conf</filename> などの設定ファイルを作ってください。

en: AWStats configuration file for a virtual host
ja: 仮想ホスト用の AWStats 設定ファイル

en: 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" />
ja: 数分後 (スクリプトを複数回実行した後)、結果をオンラインで見ることが可能になります。<ulink type="block" url="http://www.falcot.com/cgi-bin/awstats.pl" /><ulink type="block" url="http://www.falcot.org/cgi-bin/awstats.pl" />

en: <emphasis>CAUTION</emphasis> Log file rotation
ja: <emphasis>CAUTION</emphasis> ログファイルの循環

en: FTP File Server
ja: FTP ファイルサーバ

en: <primary>server</primary><secondary>file</secondary>
ja: <primary>サーバ</primary><secondary>ファイル</secondary>

en: 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).
ja: FTP (<emphasis>File Transfer Protocol</emphasis>) はインターネットにおける最初のプロトコルの 1 つです (RFC 959 は 1985 年に発行されました!)。FTP はウェブが生まれる前にファイルを配布するために使われました (HTTP プロトコルは 1990 年に作られ、1996 年の RFC 1945 でバージョン 1.0 が正式に定義されました)。

en: 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.
ja: また、FTP サーバは主に一般のユーザがダウンロードできるファイルを配布するために使われることもあります。この用途の良い例が Debian パッケージです。サーバの内容は地理的に離れている別のサーバから取得され、サーバの近郊にいるユーザに向けて内容を提供します。これはクライアント認証が不要になることを意味します。結果的に、この挙動は「匿名 FTP」として知られています。完全に正しく言えば、クライアントは <literal>anonymous</literal> というユーザ名で認証します。パスワードは慣例的にユーザの電子メールアドレスを使いますが、サーバはこのパスワードを無視します。

en: 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.
ja: <emphasis role="pkg">vsftpd</emphasis> パッケージをインストールすると、<literal>ftp</literal> システムユーザが作成されます。<literal>ftp</literal> ユーザは匿名 FTP 接続の際に常に使われるものです。FTP サービスに接続するユーザは <literal>ftp</literal> システムユーザアカウントのホームディレクトリ (<filename>/srv/ftp/</filename>) を利用できます。巨大なファイルを誰でもダウンロード可能にするという単純な要求を満足させるにはデフォルト設定 (<filename>/etc/vsftpd.conf</filename>) に変更を加える必要があります。つまり、匿名アクセスを有効化し (<literal>anonymous_enable=YES</literal>)、ローカルユーザの読み込み専用アクセスを無効化する (<literal>local_enable=NO</literal>) 必要があります。ローカルユーザの読み込み専用アクセスを無効化するのは特に重要です。なぜなら FTP プロトコルはいかなる種類の暗号化も行わないため、デフォルト設定のままではネットワーク越しにユーザパスワードを横取りされる可能性があるからです。

en: NFS File Server
ja: NFS ファイルサーバ

en: <primary>filesystem</primary><secondary>network</secondary>
ja: <primary>ファイルシステム</primary><secondary>ネットワーク</secondary>

en: <primary>file</primary><secondary>server</secondary>
ja: <primary>ファイル</primary><secondary>サーバ</secondary>

en: 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).
ja: NFS はとても役に立つツールです。しかし、歴史的に言えば NFS には数多くの制約があり、NFS プロトコルのバージョン 4 になってほとんどの制約がなくなりました。制約がなくなったことによる欠点として、NFS の最新版では認証や暗号化などの基本的なセキュリティ機能を有効化するよう設定するのがさらに難しくなったという点が挙げられます。なぜなら、NFS の最新版ではこれらの機能は Kerberos に依存しているからです。認証や暗号化機能を有効化しない場合、NFS プロトコルを使うのは信用できるローカルネットワークだけに留めるべきです。なぜなら、ネットワークを流れるデータは暗号化されませんし (<emphasis>スニファ</emphasis>を使えば内容を傍受することが可能ですし)、アクセス権はクライアントの IP アドレスに基づいて決定されるからです (IP アドレスはなりすまし可能です)。

en: <emphasis>DOCUMENTATION</emphasis> NFS HOWTO
ja: <emphasis>DOCUMENTATION</emphasis> NFS の HOWTO 文書

en: Securing NFS
ja: NFS の安全確保

en: <primary>NFS</primary><secondary>security</secondary>
ja: <primary>NFS</primary><secondary>セキュリティ</secondary>

en: 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.
ja: Kerberos に基づくセキュリティ機能を使わない場合、NFS の利用を許可されたマシンだけが種々の要求された RPC サーバに接続できるような制限を加えることが不可欠です。なぜなら、NFS の基本的なプロトコルはネットワークから受け取った情報を信頼するからです。ファイアウォールは外部のマシンが内部のマシンのように振る舞うことを避けるために <emphasis>IP なりすまし</emphasis>をブロックし、NFS 共有にアクセスするように意図されたマシンだけが適切なポートにアクセスするように制限しなければいけません。

en: RPC (<emphasis>Remote Procedure Call</emphasis>) is a Unix standard for remote services. NFS is one such service.
ja: RPC (<emphasis>Remote Procedure Call</emphasis>) はリモートサービスに関する Unix 標準です。NFS は RPC サービスの 1 つです。

en: 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.
ja: ディレクトリに登録する RPC サービスは <emphasis>portmapper</emphasis> としても知られています。NFS 問い合わせを実行することを望むクライアントは最初に <emphasis>portmapper</emphasis> (ポート 111 番、TCP または UDP) を呼び出し、NFS サーバの情報を要求します。通常、応答には NFS サーバのポート 2049 番 (NFS のデフォルト) が含まれます。すべての RPC サービスが必ず固定されたポートで使われる必要があるわけではありません。

en: 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.
ja: NFS プロトコルの古いバージョンでは他の RPC サービスが必要で、この RPC サービスは動的に割り当てられたポートを使います。幸いなことに、NFS バージョン 4 ではポート 2049 番 (NFS 用) と 111 番 (portmapper 用) が固定されており、そのため簡単にポートにファイアウォールをかませることが可能です。

en: NFS Server
ja: NFS サーバ

en: 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.
ja: NFS サーバは Linux カーネルの一部です。そして Debian の提供するカーネルでは、NFS サーバをカーネルモジュールとしてビルドしています。NFS サーバを起動時に自動的に実行するには、<emphasis role="pkg">nfs-kernel-server</emphasis> パッケージをインストールしてください。このパッケージには、対応する起動スクリプトが含まれます。

en: 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>.
ja: NFSv4 では、すべてのエクスポートされるディレクトリは一つの基準ディレクトリの下位に属さなければいけません。また、その基準ディレクトリは必ずエクスポートされ、オプション <literal>fsid=0</literal> または <literal>fsid=root</literal> で識別されなければいけません。これらの点に注意してください。

en: 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>.
ja: 各マシンは DNS 名か IP アドレスのどちらか一方を使って識別されます。マシン群全体を指定するには、<literal>*.falcot.com</literal> などの構文を使うか <literal>192.168.0.0/255.255.255.0</literal> や <literal>192.168.0.0/24</literal> などの IP アドレス範囲を使います。

en: 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).
ja: ディレクトリはデフォルトで (または <literal>ro</literal> オプションを使えば) 読み込み専用として利用できるようにされます。<literal>rw</literal> オプションを使えば読み書きアクセスが許可されます。典型的に NFS クライアントは root だけが使えるポート (言い換えれば、1024 番よりも低い番号のポート) から接続します。高いポート番号を使うクライアントからの接続を受け入れるには、<literal>insecure</literal> オプションを使います (<literal>secure</literal> オプションは暗黙的に有効化されていますが、明示する必要があればオプションを明示することも可能です)。

en: <primary>NFS</primary><secondary>options</secondary>
ja: <primary>NFS</primary><secondary>オプション</secondary>

en: 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.
ja: デフォルトの状態では、サーバが NFS 問い合わせに応答するのは、現在のディスク操作が完了した (<literal>sync</literal> オプション) 後です。これを無効化するには、<literal>async</literal> オプションを使います。非同期書き込みを使うことで、性能はほんの少し向上しますが、信頼性は低下します。なぜなら、書き込み確認とディスクへの実際の書き込みの間にサーバがクラッシュした場合に、データを損失する危険性があるからです。デフォルト値が <literal>sync</literal> に変更されたのは最近なので (NFS バージョンによってデフォルト値が違うので)、明確に <literal>sync</literal> オプションを設定することを推奨します。

en: 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).
ja: NFSv4 では <literal>sec</literal> オプションを追加してセキュリティレベルを指定することが可能です。デフォルト設定の <literal>sec=sys</literal> は特別なセキュリティ機能を有効化しません。<literal>sec=krb5</literal> は認証機能だけを有効化します。<literal>sec=krb5i</literal> は認証と整合性保護機能を有効化します。<literal>sec=krb5p</literal> はすべての機能、すなわち認証、整合性保護、プライバシー保護機能 (データ暗号化機能を含みます) を有効化します。これらを使うには、Kerberos サービスを動作させる必要があります (Kerberos サービスについては本書で解説されていません)。

en: Other options are available; they are documented in the <citerefentry><refentrytitle>exports</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page.
ja: 他のオプションも利用できます。オプションは <citerefentry><refentrytitle>exports</refentrytitle> <manvolnum>5</manvolnum></citerefentry> マニュアルページで説明されています。

en: <emphasis>CAUTION</emphasis> First installation
ja: <emphasis>CAUTION</emphasis> 初回インストール

en: NFS Client
ja: NFS クライアント

en: <primary>client</primary><secondary>NFS</secondary>
ja: <primary>クライアント</primary><secondary>NFS</secondary>

en: <primary>NFS</primary><secondary>client</secondary>
ja: <primary>NFS</primary><secondary>クライアント</secondary>

en: Manually mounting with the <command>mount</command> command
ja: <command>mount</command> コマンドを用いた手作業によるマウント

en: NFS entry in the <filename>/etc/fstab</filename> file
ja: <filename>/etc/fstab</filename> ファイルの NFS エントリ

en: The <citerefentry><refentrytitle>nfs</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the options in some detail.
ja: <citerefentry><refentrytitle>nfs</refentrytitle> <manvolnum>5</manvolnum></citerefentry> マニュアルページでは、すべてのオプションをについて詳しく説明されています。

en: Setting Up Windows Shares with Samba
ja: Samba を使った Windows 共有のセットアップ

en: <primary>Windows share</primary>
ja: <primary sortas="Windows キョウユウ">Windows 共有</primary>

en: 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.
ja: Samba は Linux 上で SMB プロトコル (「CIFS」としても知られています) を取り扱う一連のツールを指します。Windows はネットワーク共有と共有プリンタを使うために SMB プロトコルを使います。

en: Samba Server
ja: Samba サーバ

en: The <emphasis role="pkg">samba</emphasis> package contains the main two servers of Samba 4, <command>smbd</command> and <command>nmbd</command>.
ja: <emphasis role="pkg">samba</emphasis> パッケージには、Samba 4 の主要な 2 種類のサーバ <command>smbd</command> と <command>nmbd</command> が含まれます。

en: <emphasis>DOCUMENTATION</emphasis> Going further
ja: <emphasis>DOCUMENTATION</emphasis> 詳細情報

en: <primary>domain controller</primary>
ja: <primary>ドメインコントローラ</primary>

en: <primary>Windows domain</primary>
ja: <primary>Windows ドメイン</primary>

en: <emphasis>TOOL</emphasis> Authenticating with a Windows Server
ja: <emphasis>TOOL</emphasis> 認証に Windows サーバを使う

en: 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.
ja: Winbind を使うことで、システム管理者は Windows サーバを認証サーバとして使う選択肢を与えられます。Winbind は PAM と NSS をうまく統合します。このことにより、Windows ドメインの全ユーザが自動的にアカウントを取得できる Linux マシン群をセットアップすることが可能です。

en: Configuring with <command>debconf</command>
ja: <command>debconf</command> を使った設定

en: Configuring Manually
ja: 手作業による設定

en: Changes to <filename>smb.conf</filename>
ja: <filename>smb.conf</filename> の変更

en: 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.
ja: Falcot の用途に対応させるためには、<filename>/etc/samba/smb.conf</filename> 設定ファイルに含まれる他のオプションを変更することが必要です。以下の抜粋は <literal>[global]</literal> セクションに対する変更点を要約したものです。

en: 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.
ja: これは security パラメータのデフォルト値です。しかしながら、security パラメータは Samba 設定の要ですから、明示的に指定することをお勧めします。各ユーザは、共有の種類に関わらず必ず共有にアクセスする前に認証を必要とします。

en: Adding Users
ja: ユーザの追加

en: 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).
ja: 各 Samba ユーザはサーバにアカウントを持っていなければいけません。このため管理者は最初に Unix アカウントを作成し、そのアカウントを Samba のデータベースに登録する必要があります。Unix アカウントを作成する段階は通常通り行います (たとえば <command>adduser</command> を使います)。

en: 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.
ja: 既存のユーザを Samba データベースに追加するには、<command>smbpasswd -a <replaceable>user</replaceable></command> コマンドを実行します。コマンドは対話的にパスワードを尋ねます。

en: 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>).
ja: ユーザを削除するには、<command>smbpasswd -x <replaceable>user</replaceable></command> コマンドを実行します。Samba アカウントを一時的に利用できなくしたり (<command>smbpasswd -d <replaceable>user</replaceable></command> を使います)、もう一度利用できるようにしたり (<command>smbpasswd -e <replaceable>user</replaceable></command> を使います) することも可能です。

en: Samba Client
ja: Samba クライアント

en: 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.
ja: Samba のクライアント機能を使うことで、Linux マシンは Windows 共有と共有プリンタへアクセスすることが可能になります。必要なプログラムは <emphasis role="pkg">cifs-utils</emphasis> と <emphasis role="pkg">smbclient</emphasis> パッケージに含まれます。

en: The <command>smbclient</command> Program
ja: <command>smbclient</command> プログラム

en: 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.
ja: <command>smbclient</command> プログラムは SMB サーバに問い合わせを行います。特定のユーザ名を使ってサーバに接続するには <literal>-U <replaceable>user</replaceable></literal> オプションを使います。<command>smbclient //<replaceable>server</replaceable>/<replaceable>share</replaceable></command> はコマンドライン FTP クライアントに類似した対話的方法を使って共有にアクセスします。<command>smbclient -L <replaceable>server</replaceable></command> は対象のサーバで利用できる (見える) 共有を全部リストします。

en: Mounting Windows Shares
ja: Windows 共有のマウント

en: 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>).
ja: <command>mount</command> コマンドを使うことで、Windows 共有を Linux ファイルシステム階層にマウントすることが可能になります (<emphasis role="pkg">cifs-utils</emphasis> の提供する <command>mount.cifs</command> の助けを借ります)。

en: Mounting a Windows share
ja: Windows 共有をマウントする

en: The <filename>/etc/smb-credentials</filename> file (which must not be readable by users) has the following format:
ja: <filename>/etc/smb-credentials</filename> ファイル (ユーザはこのファイルを読み込むことはできません) は以下の書式で書かれています。

en: 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.
ja: コマンドラインで指定できるオプションは他にも存在します。オプションの完全なリストは <citerefentry><refentrytitle>mount.cifs</refentrytitle> <manvolnum>8</manvolnum></citerefentry> マニュアルページに書かれています。オプションの中でも特に次の 2 種類は興味深いです。<literal>uid</literal> と <literal>gid</literal> を使うことで、マウントされたことで利用できるようになったファイルの所有者とグループを指定したものに強制することが可能になります。これを指定することで、root 以外のユーザもマウント先にアクセスできるようになります。

en: A mount of a Windows share can also be configured in <filename>/etc/fstab</filename>:
ja: <filename>/etc/fstab</filename> の中に設定を書いて、Windows 共有をマウントすることも可能です。

en: Printing on a Shared Printer
ja: 共有プリンタを用いた印刷

en: 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.
ja: CUPS は Linux ワークステーションから Windows マシンによって共有されているプリンタに印刷を行う洗練された解決策です。<emphasis role="pkg">smbclient</emphasis> がインストールされている場合、CUPS を使うことで、Windows 共有プリンタを自動的にインストールすることが可能です。

en: <primary>printing</primary><secondary>network</secondary>
ja: <primary sortas="インサツ">印刷</primary><secondary>ネットワーク</secondary>

en: Here are the required steps:
ja: 以下に必要な各段階を示します。

en: Enter the CUPS configuration interface: <literal>http://localhost:631/admin</literal>
ja: CUPS 設定インターフェース <literal>http://localhost:631/admin</literal> にアクセスします。

en: Click on “Add Printer”.
ja: 「Add Printer」をクリックします。

en: Choose the printer device, pick “Windows Printer via SAMBA”.
ja: プリンタデバイスを選択し、「Windows Printer via SAMBA」を選んでください。

en: Enter the connection URI for the network printer. It should look like the following:
ja: ネットワークプリンタの接続 URI を入力します。URI は以下の書式を使うべきです。

en: <literal>smb://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>/<replaceable>printer</replaceable></literal>.
ja: <literal>smb://<replaceable>user</replaceable>:<replaceable>password</replaceable>@<replaceable>server</replaceable>/<replaceable>printer</replaceable></literal>

en: 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.
ja: プリンタを一意に識別する名前を入力してください。その後、プリンタの説明と場所を入力してください。これらは、プリンタの利用者が印刷に使うプリンタを識別できるように、利用者に表示される文字列です。

en: Indicate the manufacturer/model of the printer, or directly provide a working printer description file (PPD).
ja: プリンタの製造者/モデルを指示するか、使用するプリンタの説明ファイル (PPD) を直接提供します。

en: Voilà, the printer is operational!
ja: これで、プリンタが利用できるようになりました!

en: HTTP/FTP Proxy
ja: HTTP/FTP プロキシ

en: An HTTP/FTP proxy acts as an intermediary for HTTP and/or FTP connections. Its role is twofold:
ja: HTTP/FTP プロキシは HTTP または FTP 接続の仲介者として機能します。HTTP/FTP プロキシの役割は 2 種類あります。

en: Caching: recently downloaded documents are copied locally, which avoids multiple downloads.
ja: キャッシュ。最近ダウンロードされた文書をローカルにコピーします。これはダウンロードを重複して行うことを避ける役割を果たします。

en: 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.
ja: サーバのフィルタリング。プロキシの利用が強制されている場合 (そしてプロキシを介さない外部への接続がブロックされる場合)、プロキシは接続要求を許可するか否かを決定することが可能です。

en: <primary>HTTP/FTP proxy</primary>
ja: <primary>HTTP/FTP プロキシ</primary>

en: <primary>proxy cache</primary>
ja: <primary>プロキシキャッシュ</primary>

en: Falcot Corp selected Squid as their proxy server.
ja: Falcot Corp はプロキシサーバとして Squid を選びました。

en: Installing
ja: インストール

en: 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.
ja: インストールの前に、システムが自分の完全な名前を識別できるか確認することを忘れないでください。すなわち <command>hostname -f</command> が完全修飾名 (ドメイン名を含むホスト名) を返すことを確認してください。これに失敗した場合、<filename>/etc/hosts</filename> ファイルを編集して、システムの完全な名前 (たとえば <literal>arrakis.falcot.com</literal> など) を書き込むべきです。潜在的な名前の衝突を避けるには、ネットワーク管理者に公認コンピュータ名の妥当性を確認するべきです。

en: Configuring a Cache
ja: キャッシュの設定

en: Configuring a Filter
ja: フィルタの設定

en: 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" />
ja: <command>squidGuard</command> 設定ファイル (またはその中で言及しているドメインまたは URL のリストの 1 つ) を変更したら、毎回 <command>update-squidguard</command> を使って作業データベースを再生成しなければいけません。設定ファイルの構文は以下のウェブサイトで説明されています。<ulink type="block" url="http://www.squidguard.org/Doc/configure.html" />

en: LDAP Directory
ja: LDAP ディレクトリ

en: <primary>directory, LDAP</primary>
ja: <primary>ディレクトリ、LDAP</primary>

en: 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.
ja: OpenLDAP は LDAP プロトコルの実装です。言い換えれば、OpenLDAP はディレクトリを保存するために設計された特製データベースです。OpenLDAP が最もよく使われる用途は、LDAP サーバを使ってユーザアカウントと関連するパーミッションの中央管理を行う場合です。さらに、LDAP データベースは簡単に複製できるので、複数の同期された LDAP サーバをセットアップすることが可能になります。ネットワークとユーザの数が急速に多くなった場合でも、複数のサーバ間で負荷のバランスをとることが可能です。

en: 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.
ja: LDAP データは階層的に構造化されています。LDAP データの構造は「スキーマ」によって定義され、スキーマはデータベースに保存できるオブジェクトの種類をその属性リストと一緒に説明するものです。データベース内の特定のオブジェクトを参照するために使われる構文はデータ構造に依存し、構文の複雑さはデータ構造の複雑さに対応します。

en: 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.
ja: OpenLDAP サーバは <emphasis role="pkg">slapd</emphasis> パッケージに含まれます。LDAP サーバと情報をやり取りするためのコマンドラインツールは <emphasis role="pkg">ldap-utils</emphasis> パッケージに含まれます。

en: Omit OpenLDAP server configuration? No, of course, we want to configure this service.
ja: OpenLDAP サーバの設定を省略しますか? LDAP サービスを設定するので当然「いいえ」を選びます。

en: DNS domain name: “<literal>falcot.com</literal>”.
ja: DNS ドメイン名。「<literal>falcot.com</literal>」と入力します。

en: Organization name: “Falcot Corp”.
ja: 組織名。「Falcot Corp」と入力します。

en: An administrative passwords needs to be typed in.
ja: 管理者のパスワードを入力します。

en: Database backend to use: “MDB”.
ja: 利用するデータベースバックエンド。「MDB」を選びます。

en: 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.
ja: <emphasis role="pkg">slapd</emphasis> をパージした時にデータベースを削除しますか? 間違ってデータベースを失う危険性を増やすのは得策ではありませんから「いいえ」を選びます。

en: 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.
ja: 古いデータベースを移動しますか? この質問はデータベースが既に存在するにも関わらず設定を行おうとした場合に表示されます。たとえば最初のインストールの直後に <command>dpkg-reconfigure slapd</command> を実行する場合など、空っぽのデータベースから設定を再開したい場合、「はい」を選びます。

en: <emphasis>BACK TO BASICS</emphasis> LDIF format
ja: <emphasis>BACK TO BASICS</emphasis> LDIF フォーマット

en: 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.
ja: LDIF ファイル (<emphasis>LDAP Data Interchange Format</emphasis>) は移植可能なテキストファイルで、LDAP データベース (またはデータベースの一部) の内容を説明しています。LDIF ファイルを使って、他の LDAP サーバにデータを投入することが可能です。

en: A minimal database is now configured, as demonstrated by the following query:
ja: 以下の問い合わせによって実例を示す通り、最低限のデータベースが設定されています。

en: The query returned two objects: the organization itself, and the administrative user.
ja: この問い合わせの結果 2 種類のオブジェクトが返されました。具体的に言えば、組織自身と管理ユーザが返されました。

en: Filling in the Directory
ja: ディレクトリへの書き込み

en: 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.
ja: 空っぽのデータベースは全く役に立たないので、すべての存在するディレクトリをデータベースに投入することにします。ここで存在するディレクトリとはユーザ、グループ、サービス、ホスト名データベースなどを指します。

en: 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.
ja: <emphasis role="pkg">migrationtools</emphasis> パッケージには、標準的な Unix ディレクトリ (<filename>/etc/passwd</filename>、<filename>/etc/group</filename>、<filename>/etc/services</filename>、<filename>/etc/hosts</filename> など) からのデータを展開するための一連のスクリプトが含まれます。スクリプトを使ってデータを変換し、LDAP データベースに投入します。

en: 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.
ja: <emphasis role="pkg">migrationtools</emphasis> パッケージをインストールしたら、必ず <filename>/etc/migrationtools/migrate_common.ph</filename> を編集してください。つまり、<varname>IGNORE_UID_BELOW</varname> と <varname>IGNORE_GID_BELOW</varname> オプションを編集して (コメント解除するだけで十分です)、<varname>DEFAULT_MAIL_DOMAIN</varname> と <varname>DEFAULT_BASE</varname> を更新する必要があります。

en: The actual migration operation is handled by the <command>migrate_all_online.sh</command> command, as follows:
ja: 実際の移行操作は以下の通り <command>migrate_all_online.sh</command> コマンドを使って行います。

en: 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.
ja: <command>migrate_all_online.sh</command> から LDAP データベースに移行するデータの種類に関する数個の質問を尋ねられます。<xref linkend="tab-migrate-all" xrefstyle="select: label nopage" /> には Falcot の使用例で使った回答がまとめられています。

en: Answers to questions asked by the <command>migrate_all_online.sh</command> script
ja: <command>migrate_all_online.sh</command> スクリプトからの質問に対する回答

en: Question
ja: 質問

en: Answer
ja: 回答

en: X.500 naming context
ja: X.500 命名コンテキスト

en: LDAP server hostname
ja: LDAP サーバのホスト名

en: Manager DN
ja: 管理者の識別名

en: Bind credentials
ja: 認証情報の紐付け

en: the administrative password
ja: LDAP データベース管理用パスワード

en: Create DUAConfigProfile
ja: DUAConfigProfile を作成

en: <emphasis>TOOL</emphasis> Browsing an LDAP directory
ja: <emphasis>TOOL</emphasis> LDAP ディレクトリの閲覧

en: 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.
ja: <command>jxplorer</command> コマンド (同名のパッケージに含まれます) は LDAP データベースを閲覧および編集することが可能なグラフィカルツールです。<command>jxplorer</command> コマンドは興味深いツールで、このツールを使うことで管理者は LDAP データの階層構造をわかりやすく概観することが可能です。

en: 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.
ja: <command>ldapadd</command> コマンドの <literal>-c</literal> オプションの利用について触れておきます。このオプションはエラーが起きた場合に処理を停止しないように要求するものです。このオプションを使うことが必要です。なぜなら、<filename>/etc/services</filename> を変換する際に、無視しても問題ない数個のエラーが起きることが多いからです。

en: Managing Accounts with LDAP
ja: LDAP を用いたアカウントの管理

en: 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.
ja: これで LDAP データベースにいくつかの実用的な情報が含まれるようになりましたので、このデータを使うように設定します。この節では、さまざまなシステムディレクトリが LDAP データベースを使うように Linux システムを設定する方法に注目します。

en: Configuring NSS
ja: NSS の設定

en: 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" />.
ja: NSS システム (Name Service Switch、補注<xref linkend="sidebar.intro-nss" />を参照してください) はシステムディレクトリの情報を定義したり取得したりするために設計されたモジュール式システムです。NSS 用のデータ参照元として LDAP を使うには、<emphasis role="pkg">libnss-ldap</emphasis> パッケージをインストールする必要があります。<emphasis role="pkg">libnss-ldap</emphasis> パッケージのインストール中に数個の質問が行われます。ここで使った回答は<xref linkend="tab-libnss-ldap" xrefstyle="select: label nopage" /> にまとめられています。

en: Distinguished name of the search base
ja: 検索ベースの識別名

en: LDAP version to use
ja: 使用する LDAP バージョン

en: LDAP account for root
ja: LDAP 管理用アカウント

en: LDAP root account password
ja: LDAP 管理用パスワード

en: Does the LDAP database require login?
ja: LDAP データベースはログインを必要としますか?

en: The <filename>/etc/nsswitch.conf</filename> file
ja: <filename>/etc/nsswitch.conf</filename> ファイル

en: 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.
ja: 通常 <command>ldap</command> モジュールは他のモジュールよりも前に書き込みます。こうすることで、問い合わせの際に <command>ldap</command> モジュールが優先して使われます。注目すべき除外例が <literal>hosts</literal> サービスです。なぜなら、LDAP サーバに接続するには (<literal>ldap.falcot.com</literal> の名前解決を行うためには) 先に DNS を調べる必要があるからです。<literal>hosts</literal> サービスで最初 <command>ldap</command> モジュールを使うようにすると、LDAP サーバにホスト名を問い合わせることになります。しかし、名前解決を担当している LDAP サーバに接続するには LDAP サーバの名前解決が必要なので、無限ループすることになります。

en: 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:
ja: LDAP サーバからの応答を正式な回答として取り扱う場合 (そして特殊な状況が起きない限り <command>files</command> モジュールの使うローカルファイルからの応答を無視する場合)、以下の構文を使ってサービスを設定します。

en: 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.
ja: LDAP サービスを利用して問い合わせたエントリが LDAP データベースに存在しない場合、問い合わせに対する応答は「not existing」になるでしょう。これは問い合わせたエントリがローカルファイルに存在するか否かに依存しません。しかし LDAP サービスが利用できない場合に限り、ローカルファイルにエントリを問い合わせます。

en: Configuring PAM
ja: PAM の設定

en: 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.
ja: この節では、PAM 設定 (補注<xref linkend="sidebar.intro-pam" />を参照してください) を説明します。ここで説明した PAM 設定を使うことで、アプリケーションは LDAP データベースに向けて認証を要求することが可能になります。

en: <emphasis>CAUTION</emphasis> Broken authentication
ja: <emphasis>CAUTION</emphasis> 破壊された認証

en: 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.
ja: さまざまなプログラムが使う標準的な PAM 設定の変更は慎重に行うべきです。1 つの間違いが認証を破壊し、ログインを不可能にする場合があります。このため root シェルを開いた状態を保ちながら作業を行うことが良い予防策です。こうしておけば、設定エラーが起きた場合、設定を修正して最小限の努力でサービスを再起動することが可能です。

en: 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" />.
ja: PAM 用の LDAP モジュールは <emphasis role="pkg">libpam-ldap</emphasis> パッケージに含まれます。<emphasis role="pkg">libpam-ldap</emphasis> パッケージをインストールする際に、<emphasis role="pkg">libnss-ldap</emphasis> をインストールした際にされた質問と良く似た数個の質問を尋ねられます。いくつかの設定パラメータ (LDAP サーバの URI など) は <emphasis role="pkg">libnss-ldap</emphasis> パッケージと共有されます。ここで使った回答は<xref linkend="tab-libpam-ldap" xrefstyle="select: label nopage" /> にまとめられています。

en: Configuration of <emphasis>libpam-ldap</emphasis>
ja: <emphasis>libpam-ldap</emphasis> の設定

en: Allow LDAP admin account to behave like local root?
ja: LDAP 管理アカウントがローカルの root のように振る舞うことを許しますか?

en: Yes. This allows using the usual <command>passwd</command> command for changing passwords stored in the LDAP database.
ja: はい。こうすることで、通常の <command>passwd</command> コマンドから LDAP データベースに保存されているパスワードを変更することが可能になります。

en: Does the LDAP database require logging in?
ja: LDAP データベースはログインを必要としますか?

en: the LDAP database administrative password
ja: LDAP 管理用パスワード

en: 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.
ja: <emphasis role="pkg">libpam-ldap</emphasis> をインストールすると自動的に <filename>/etc/pam.d/common-auth</filename>、<filename>/etc/pam.d/common-password</filename>、<filename>/etc/pam.d/common-account</filename> ファイルで定義されたデフォルトの PAM 設定が適用されます。このメカニズムは専用の <command>pam-auth-update</command> ツール (<emphasis role="pkg">libpam-runtime</emphasis> パッケージから提供される) を使います。<command>pam-auth-update</command> ツールは PAM モジュールを有効化または無効化したい管理者によって実行される場合もあります。

en: Securing LDAP Data Exchanges
ja: 安全な LDAP データ交換

en: <primary>LDAP</primary><secondary>secure</secondary>
ja: <primary>LDAP</primary><secondary sortas="アンゼンナ LDAP">安全な LDAP</secondary>

en: 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.
ja: デフォルトで、LDAP プロトコルはネットワークを平文で通信します。従って、(暗号化された) パスワードがネットワーク上をそのまま流れます。暗号化されたパスワードをネットワークから抽出することが可能ですから、パスワードは辞書型攻撃に弱いということになります。暗号化層を追加することで、このような危険性を避けることが可能です。この節のテーマは暗号化層を有効化することです。

en: Configuring the Server
ja: サーバの設定

en: <primary><foreignphrase>OpenSSL</foreignphrase></primary><secondary>creating keys</secondary>
ja: <primary><foreignphrase>OpenSSL</foreignphrase></primary><secondary sortas="カギサクセイ">鍵作成</secondary>

en: <primary>key pair</primary>
ja: <primary sortas="カギペア">鍵ペア</primary>

en: 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:
ja: さらに、これらの鍵を標準的な場所にインストールし、<literal>openldap</literal> ユーザ権限で実行されている LDAP サーバが秘密鍵を読み込み可能であることを保証しなければいけません。これを行うために以下の通り実行します。

en: 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:
ja: <command>slapd</command> デーモンにこれらの鍵を暗号化に使うように伝えることも必要です。LDAP サーバの設定は動的に管理されます。つまり、設定は <literal>cn=config</literal> オブジェクト階層に対する通常の LDAP 操作によって更新され、サーバは設定を永続的なものにするために <filename>/etc/ldap/slapd.d</filename> をリアルタイムで更新します。このため、設定を更新するには <command>ldapmodify</command> ツールを使ってください。

en: Configuring <command>slapd</command> for encryption
ja: 暗号化用の <command>slapd</command> の設定

en: <emphasis>TOOL</emphasis> <command>ldapvi</command> to edit an LDAP directory
ja: <emphasis>TOOL</emphasis> <command>ldapvi</command> で LDAP ディレクトリを編集する

en: It is thus a convenient way to update the configuration of the LDAP server, simply by editing the <literal>cn=config</literal> hierarchy.
ja: このため、LDAP サーバの設定を更新するには <command>ldapvi</command> を使って <literal>cn=config</literal> 階層を編集する方法が便利です。

en: 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.
ja: 暗号化を有効化するための最後の作業が <filename>/etc/default/slapd</filename> ファイル内の <varname>SLAPD_SERVICES</varname> 変数を変更することです。ここでは慎重を期して、安全対策されていない LDAP を無効化しています。

en: The <filename>/etc/default/slapd</filename> file
ja: <filename>/etc/default/slapd</filename> ファイル

en: Configuring the Client
ja: クライアントの設定

en: 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.
ja: クライアント側では <emphasis>libpam-ldap</emphasis> と <emphasis>libnss-ldap</emphasis> モジュールの設定を修正し、<literal>ldaps://</literal> URI を使うように設定する作業が必要です。

en: 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.
ja: 最後に重要なことですが、さまざまなコマンドラインツールで使われるデフォルトの LDAP URI とデフォルトのベース識別名は <filename>/etc/ldap/ldap.conf</filename> を編集すれば変更することが可能です。こうすることで、入力する量を激減させることが可能です。

en: The <filename>/etc/ldap/ldap.conf</filename> file
ja: <filename>/etc/ldap/ldap.conf</filename> ファイル

en: Real-Time Communication Services
ja: リアルタイムコミュニケーションサービス

en: 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.
ja: SIP と XMPP はどちらも同じ機能を持っています。SIP は音声と動画用としてよく知られています。これに対して XMPP は伝統的に IM プロトコル用と考えられています。しかし実際のところ SIP と XMPP のどちらを使っても音声、動画、IM サービスを提供することが可能です。ただし、さまざまな方法で接続できるようにするためには SIP と XMPP の両方を同時に運用することを推奨します。

en: DNS settings for RTC services
ja: RTC サービス用の DNS 設定

en: 
    ; the server where everything will run
    server1            IN     A      198.51.100.19
    server1            IN     AAAA   2001:DB8:1000:2000::19
    
    ; IPv4 only for TURN for now, some clients are buggy with IPv6
    turn-server        IN     A      198.51.100.19
    
    ; IPv4 and IPv6 addresses for SIP
    sip-proxy          IN     A      198.51.100.19
    sip-proxy          IN     AAAA   2001:DB8:1000:2000::19
    
    ; IPv4 and IPv6 addresses for XMPP
    xmpp-gw            IN     A      198.51.100.19
    xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19
    
    ; DNS SRV and NAPTR for STUN / TURN
    _stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.
    _turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.
    @           IN NAPTR  10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.
    
    ; DNS SRV and NAPTR records for SIP
    _sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.
    @           IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.
    
    ; DNS SRV records for XMPP Server and Client modes:
    _xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.
    _xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com.
ja: 
    ; すべてのサービスが実行されるサーバ
    server1            IN     A      198.51.100.19
    server1            IN     AAAA   2001:DB8:1000:2000::19
    
    ; 一部の TURN クライアントは IPv6 の取り扱いにバグがあるので TURN サービスは IPv4 アドレスのみ
    turn-server        IN     A      198.51.100.19
    
    ; SIP サービス用の IPv4 と IPv6 アドレス。
    sip-proxy          IN     A      198.51.100.19
    sip-proxy          IN     AAAA   2001:DB8:1000:2000::19
    
    ; XMPP サービス用の IPv4 と IPv6 アドレス。
    xmpp-gw            IN     A      198.51.100.19
    xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19
    
    ; STUN と TURN サービス用の DNS SRV および NAPTR レコード
    _stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.
    _turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.
    @           IN NAPTR  10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.
    
    ; SIP サービス用の DNS SRV および NAPTR レコード
    _sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.
    @           IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.
    
    ; XMPP サーバとクライアント用の DNS SRV レコード
    _xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.
    _xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com.

en: TURN Server
ja: TURN サーバ

en: 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.
ja: TURN は NAT ルータの背後にいるクライアントを助けるサービスです。さらに TURN は他のクライアントと通信するための最も適切な方法、直接のメディアパスが見つからない状態でメディアストリームを中継するための最も適切な方法を発見するファイアウォールでもあります。エンドユーザに提供する RTC サービスをインストールする前に TURN サーバをインストールすることを強く推奨します。

en: <primary>TURN</primary><secondary>server</secondary>
ja: <primary>TURN</primary><secondary>サーバ</secondary>

en: 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.
ja: TURN とそれに関連する ICE プロトコルはオープン標準です。TURN および ICE プロトコルからの恩恵を受け、数多くの接続方法を提供してユーザの不満を低減するには、すべてのクライアントソフトウェアが ICE および TURN をサポートしている点を確認することが重要です。

en: For the ICE algorithm to work effectively, the server must have two public IPv4 addresses.
ja: ICE アルゴリズムを効果的に動作させるには、サーバが 2 種類の公開 IPv4 アドレスを持つ必要があります。

en: SIP Proxy Server
ja: SIP プロキシサーバ

en: 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.
ja: SIP プロキシサーバはさまざまな組織、SIP トンネルプロバイダ、Asterisk などの SIP PBX、SIP フォン、SIP を使うソフトフォン、WebRTC アプリケーションなどの間での SIP 接続の着信および発信を管理します。

en: <primary>SIP</primary><secondary>server</secondary>
ja: <primary>SIP</primary><secondary>サーバ</secondary>

en: <primary>SIP</primary><secondary>proxy</secondary>
ja: <primary>SIP</primary><secondary>プロキシ</secondary>

en: <primary>SIP</primary><secondary>trunk</secondary>
ja: <primary>SIP</primary><secondary>トランク</secondary>

en: 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.
ja: SIP PBX のセットアップを試みる前に SIP プロキシをインストールおよび設定することを強く推奨します。SIP プロキシは PBX に到達する数多くのトラフィックを正常化し、高い接続性能と復元性能をもたらします。

en: Install the SIP proxy
ja: SIP プロキシのインストール

en: XMPP Server
ja: XMPP サーバ

en: An XMPP server manages connectivity between local XMPP users and XMPP users in other domains on the public Internet.
ja: XMPP サーバはローカル XMPP ユーザと公開インターネット上の他のドメインに所属する XMPP ユーザの間の接続を管理します。

en: <emphasis>VOCABULARY</emphasis> XMPP or Jabber?
ja: <emphasis>VOCABULARY</emphasis> XMPP か Jabber か?

en: XMPP is sometimes referred to as Jabber. In fact, Jabber is a trademark and XMPP is the official name of the standard.
ja: XMPP は Jabber と呼ばれることがあります。実際のところ、Jabber とは商標であり、XMPP は標準規格の公式名です。

en: Install the XMPP server
ja: XMPP サーバのインストール

en: 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.
ja: 次に <filename>/etc/prosody/prosody.cfg.lua</filename> 設定ファイルを検査します。ここではサーバを管理することを許可するユーザの JID を書き込むことを忘れないでください。

en: 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>:
ja: また、各ドメインに対する設定ファイルも必要です。<filename>/etc/prosody/conf.avail/example.com.cfg.lua</filename> からサンプルをコピーして、これを足掛かりとして使ってください。以下は <literal>falcot.com.cfg.lua</literal> の例です。

en: To enable the domain, there must be a symlink from <filename>/etc/prosody/conf.d/</filename>. Create it that way:
ja: <literal>falcot.com</literal> ドメインを有効化するには、このファイルへのシンボリックリンクを <filename>/etc/prosody/conf.d/</filename> の中に作ってください。これを行うには以下のコマンドを実行します。

en: Restart the service to use the new configuration.
ja: その後、新しい設定を使ってサービスを再起動します。

en: Managing the XMPP server
ja: XMPP サーバの管理

en: Running services on port 443
ja: ポート 443 番でサービスを実行する

en: 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.
ja: すべての RTC サービスをポート 443 番で実行したいと思う管理者がいるかもしれません。こうすることで、他のポートがふさがれていたり HTTP プロキシサーバを通じてインターネットトラフィックをルーティングしているような、ホテルや空港などのリモート場所から接続するユーザを受け入れることが可能になります。

en: 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.
ja: この方針を採用する場合、それぞれのサービス (SIP、XMPP、TURN) に別々の IP アドレスを設定する必要があります。しかし、すべてのサービスは同じホスト上で運用することが可能です。なぜなら Linux は 1 台のホスト上で複数の IP アドレスを取り扱うことが可能だからです。この場合、それぞれのサービスに対する設定ファイルおよび DNS SRV レコードの中でポート番号 (今回の場合 443 番) を指定しなければいけません。

en: Adding WebRTC
ja: WebRTC の追加

en: 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.
ja: Falcot は顧客がウェブサイトから電話をかけることができるようしたいと思っています。また Falcot の管理者は障害復旧策の一部として WebRTC を使いたいと思っています。こうすることでスタッフは自宅からウェブブラウザを使って会社の電話システムにログインし、緊急時にも通常と同じ環境で作業を行うことが可能になります。

en: <emphasis>IN PRACTICE</emphasis> Try WebRTC
ja: <emphasis>IN PRACTICE</emphasis> WebRTC を試す

en: <primary>WebRTC</primary><secondary>demonstration</secondary>
ja: <primary>WebRTC</primary><secondary>デモ</secondary>

en: 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.
ja: この章では、利用できるサーバソフトウェアのうちのほんのわずかなソフトウェアだけに注目しました。しかしながら、ほとんどの一般的なネットワークサービスについて言及しました。今や、より技術的な章に入る準備が整ったと言えます。具体的に言えば、一部の概念に関してより詳細を解説し、大規模な配備と仮想化について説明します。
