さまざまな種類のサーバーのデプロイメント

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8 にさまざまな種類のサーバーをデプロイするためのガイド

Red Hat Customer Content Services

概要

本書では、Apache HTTP Web サーバー、Samba サーバー、NFS サーバー、利用可能なデータベースサーバー、CUPS サーバーなど、Red Hat Enterprise Linux 8 でさまざまな種類のサーバーを設定して実行する方法を説明します。

Red Hat ドキュメントへのフィードバック (英語のみ)

ご意見ご要望をお聞かせください。ドキュメントの改善点ございませんか。改善点を報告する場合は、以下のように行います。

特定の文章に簡単なコメントを記入する場合は、ドキュメントが Multi-page HTML 形式であることを確認してください。コメントを追加する部分を強調表示し、そのテキストの下に表示される Add Feedback ポップアップをクリックし、表示された手順に従ってください。
より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。
1. Bugzilla の Web サイトにアクセスします。
2. Component で Documentation を選択します。
3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
4. Submit Bug をクリックします。

第1章 Apache HTTP Web サーバーの設定

1.1. Apache HTTP Web サーバーの概要

Web サーバー は、Web 経由でクライアントにコンテンツを提供するネットワークサービスです。これは通常 Web ページを指しますが、他のドキュメントも当てはまります。Web サーバーは、ハイパーテキスト転送プロトコル (HTTP) を使用するため、HTTP サーバーとも呼ばれます。

Red Hat Enterprise Linux 8 で利用可能な Web サーバーは以下のとおりです。

Apache HTTP Server
nginx

Apache HTTP Server (httpd) は、Apache Software Foundation が開発したオープンソースの Web サーバーです。

Red Hat Enterprise Linux の以前のリリースからアップグレードする場合は、適切に httpd サービス設定を更新する必要があります。本セクションでは、新たに追加された機能の一部と、以前の設定ファイルの更新を説明します。

1.2. Apache HTTP Server への主な変更点

RHEL 8 では、Apache HTTP Server が、RHEL 7 のバージョン 2.4.6 から、バージョン 2.4.37 に更新しました。この更新バージョンには新機能がいくつか含まれていますが、外部モジュールの設定および Application Binary Interface (ABI) のレベルでは、RHEL 7 バージョンとの後方互換性を維持します。

新機能は次のとおりです。

httpd モジュール含まれる mod_http2 パッケージにより、HTTP/2 に対応するようになりました。
systemd ソケットのアクティベーションが対応します。詳細は、man ページの httpd.socket(8) を参照してください。

新しいモジュールが複数追加されています。
- mod_proxy_hcheck - プロキシーのヘルスチェックモジュール
- mod_proxy_uwsgi - Web Server Gateway Interface (WSGI) プロキシー
- mod_proxy_fdpass - クライアントのソケットを別のプロセスに渡す
- mod_cache_socache - HTTP キャッシュ (例: memcache バックエンドを使用)
- mod_md - ACME プロトコルの SSL/TLS 証明書サービス
以下のモジュールはデフォルトで読み込まれるようになりました。
- mod_request
- mod_macro
- mod_watchdog
新しいサブパッケージ httpd-filesystem が追加されています。これには、Apache HTTP Server の基本的なディレクトリーレイアウト (ディレクトリーの適切な権限を含む) が含まれます。
インスタンス化されたサービスのサポート httpd@.service が導入されました。詳細は、man ページの httpd.service を参照してください。

新しい httpd-init.service が %post script に置き換わり、自己署名の鍵ペア mod_ssl を作成します。

(Let’s Encrypt などの証明書プロバイダーで使用するため) 自動証明書管理環境 (ACME) プロトコルを使用した、TLS 証明書の自動プロビジョニングおよび更新に、mod_md パッケージで対応するようになりました。
Apache HTTP Server が、PKCS#11 モジュールを利用して、ハードウェアのセキュリティートークンから、TLS 証明書および秘密鍵を直接読み込むようになりました。これにより、mod_ssl 設定で、PKCS#11 URL を使用して、SSLCertificateKeyFile ディレクティブおよび SSLCertificateFile ディレクティブに、TLS 秘密鍵と、必要に応じて TLS 証明書をそれぞれ指定できるようになりました。

/etc/httpd/conf/httpd.conf ファイルの新しい ListenFree ディレクティブに対応するようになりました。

Listen ディレクティブと同様、ListenFree は、サーバーがリッスンする IP アドレス、ポート、または IP アドレスとポートの組み合わせに関する情報を提供します。ただし、ListenFree を使用すると、IP_FREEBIND ソケットオプションがデフォルトで有効になります。したがって、httpd は、ローカルではない IP アドレス、または今はまだ存在していない IP アドレスにバインドすることもできます。これにより、httpd がソケットをリッスンできるようになり、httpd がバインドしようとするときに、基になるネットワークインターフェースまたは指定した動的 IP アドレスを起動する必要がなくなります。

ListenFree ディレクティブは、現在 RHEL 8 でのみ利用できます。

ListenFree の詳細は、以下の表を参照してください。

表1.1 ListenFree ディレクティブの構文、状態、およびモジュール

構文	状態	モジュール
ListenFree [IP-address:]portnumber [protocol]	MPM	event、worker、prefork、mpm_winnt、mpm_netware、mpmt_os2

その他の主な変更点は次の通りです。

以下のモジュールが削除されました。
- mod_file_cache
- mod_nss
- mod_perl
RHEL 8 の Apache HTTP Server が使用するデフォルトの DBM 認証データベースのデフォルトタイプが、SDBM から db5 に変更になりました。
Apache HTTP Server の mod_wsgi モジュールが Python 3 に更新されました。WSGI アプリケーションは Python 3 でしか対応されないため、Python 2 から移行する必要があります。
Apache HTTP Server を使用してデフォルトで設定されたマルチプロセッシングモジュール (MPM) は、マルチプロセスのフォークモデル (prefork として知られています) から、高パフォーマンスのマルチスレッドモデル event に変更しました。
スレッドセーフではないサードパーティーのモジュールは、交換または削除する必要があります。設定した MPM を変更するには、/etc/httpd/conf.modules.d/00-mpm.conf ファイルを編集します。詳細は、man ページの httpd.service(8) を参照してください。
suEXEC によりユーザーに許可される最小 UID および GID はそれぞれ 1000 および 500 です (以前は 100 および 100 でした)。
/etc/sysconfig/httpd ファイルは、httpd サービスへの環境変数の設定に対応するインターフェースではなくなりました。systemd サービスに、httpd.service(8) の man ページが追加されています。
httpd サービスを停止すると、デフォルトで「自動停止」が使用されます。
mod_auth_kerb モジュールが、mod_auth_gssapi モジュールに置き換わりました。

1.3. 設定の更新

Red Hat Enterprise Linux 7 で使用されている Apache HTTP Server バージョンから設定ファイルを更新するには、以下のいずれかのオプションを選択します。

/etc/sysconfig/httpd を使用して環境変数を設定する場合は、代わりに systemd ドロップインファイルを作成します。
サードパーティーのモジュールを使用する場合は、そのモジュールがスレッド化 MPM と互換性があることを確認してください。
suexec を使用する場合は、ユーザーおよびグループの ID が新しい最小値に合致していることを確認します。

以下のコマンドを使用すると、設定に誤りがないかどうかを確認できます。

~]# apachectl configtest
Syntax OK

1.4. httpd サービスの実行

本セクションでは、Apache HTTP Server の起動、停止、再起動、および現在のステータスの確認を行う方法を説明します。httpd サービスを使用するには、httpd パッケージがインストールされていることを確認します。

~]# yum install httpd

Red Hat Enterprise Linux 8 の Apache HTTP Server は、アプリケーションストリームで利用可能な httpd モジュールからもインストールできます。

httpd モジュールをインストールするには、root で以下のコマンドを実行します。

~]# yum module install httpd

このコマンドでは、SSL/TLS サポートを提供する mod_ssl モジュールもインストールされます。

1.4.1. サービスの起動

httpd サービスを実行する場合は、root で次のコマンドを実行します。

~]# systemctl start httpd.service

システムの起動時にサービスを自動的に起動するようにするには、以下のコマンドを使用します。

~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

注記

Apache HTTP Server を安全なサーバーとして実行して、暗号化された SSL 秘密鍵を使用する場合は、システムの起動後にパスワードが必要になります。

1.4.2. サービスの停止

実行中の httpd サービスを停止するには、root で次のコマンドを実行します。

~]# systemctl stop httpd.service

システムの起動時にサービスが自動的に起動しないようにするには、以下を入力します。

~]# systemctl disable httpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.

1.4.3. サービスの再起動

実行中の httpd サービスを再起動する方法は 2 つあります。

サービスを完全に再起動するには、root で次のコマンドを入力します。
```
~]# systemctl restart httpd.service
```
これにより、稼働中の httpd サービスが停止し、すぐに再起動します。このコマンドは、PHP など、動的に読み込んだモジュールをインストールまたは削除した後に使用します。
アクティブな要求に影響を与えずに設定を再読み込みするには、root で次のコマンドを入力します。
```
~]# systemctl reload httpd.service
```
これにより、実行中の httpd サービスが、設定ファイルを再読み込みします。現在処理中のリクエストは、引き続き古い設定を使用します。

1.4.4. サービスステータスの確認

httpd サービスが実行していることを確認するには、シェルプロンプトで以下を入力します。

~]# systemctl is-active httpd.service
active

1.5. 設定ファイルの編集

httpd サービスが起動すると、デフォルトでは、表1.2「httpd サービスの設定ファイル」に一覧表示されている場所から設定が読み込まれます。

表1.2 httpd サービスの設定ファイル

パス	説明
`/etc/httpd/conf/httpd.conf`	主要設定ファイル。
`/etc/httpd/conf.d/`	主要設定ファイル内に含まれている設定ファイル用の補助ディレクトリー。
`/etc/httpd/conf.modules.d/`	Red Hat Enterprise Linux にパッケージ化されたインストール済みの動的モジュールを読み込む設定ファイルの補助ディレクトリー。デフォルト設定では、この設定ファイルが最初に処理されます。

デフォルト設定はほとんどの状況に適していますが、その他の設定オプションを使用することもできます。変更を有効にするには、まず Web サーバーを再起動します。httpd サービスを再起動する方法は、「サービスの再起動」を参照してください。

設定に誤りがないことを確認するには、シェルプロンプトで以下のコマンドを実行します。

~]# apachectl configtest
Syntax OK

間違いからの復元を容易にするため、編集する前にオリジナルファイルのコピーを作成します。

1.6. モジュールの使用

httpd サービスは、モジュールアプリケーションであるため、多数の Dynamic Shared Objects (DSO) と一緒に配布されます。これは、必要に応じてランタイム時に、動的に読み込まれたり、読み込みが破棄されたりします。このモジュールは、/usr/lib64/httpd/modules/ ディレクトリーにあります。

1.6.1. モジュールの読み込み

特定の DSO モジュールを読み込むには、LoadModule ディレクティブを使用します。別のパッケージが提供するモジュールは、多くの場合、/etc/httpd/conf.modules.d/ ディレクトリーに独自の設定ファイルがあることに注意してください。

例1.1 mod_ssl DSO の読み込み

LoadModule ssl_module modules/mod_ssl.so

モジュールの読み込み後、Web サーバーを再起動して設定を再読み込みします。httpd サービスを再起動する方法は、「サービスの再起動」を参照してください。

1.6.2. モジュールの作成

新しい DSO モジュールを作成するには、httpd-devel パッケージがインストールされていることを確認します。これを行うには、root で以下のコマンドを実行します。

~]# yum install httpd-devel

このパッケージには、モジュールをコンパイルするために必要なインクルードファイル、ヘッダーファイル、および APache eXtenSion (apxs) ユーティリティーが含まれます。

作成したら、以下のコマンドでモジュールを構築できます。

~]# apxs -i -a -c module_name.c

ビルドが成功すると、Apache HTTP Server で配布されるその他のモジュールと同じ方法でモジュールを読み込むことができます。

1.7. 仮想ホストの設定

Apache HTTP Server に組み込まれている仮想ホストを使用すると、どの IP アドレス、ホスト名、またはポートが要求されているかに基づいて、サーバーが異なる情報を提供できます。

名前ベースの仮想ホストを作成するには、/usr/share/doc/httpd/httpd-vhosts.conf 設定ファイルを /etc/httpd/conf.d/ ディレクトリーにコピーします。例1.2「仮想ホストの設定例」に従って、要件に応じてオプションをカスタマイズします。

例1.2 仮想ホストの設定例

<VirtualHost *:80>
    ServerAdmin webmaster@penguin.example.com
    DocumentRoot "/www/docs/penguin.example.com"
    ServerName penguin.example.com
    ServerAlias www.penguin.example.com
    ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
    CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common
</VirtualHost>

ServerName は、マシンに割り当てられた有効な DNS 名を指定する必要があることに注意してください。<VirtualHost> コンテナーは高度なカスタマイズが可能で、メインサーバーの設定で利用可能なディレクティブのほとんどを使用できます。このコンテナーで対応して いない ディレクティブには、SuexecUserGroup に置き換えられた ユーザー および グループ が含まれます。

注記

仮想ホストがデフォルト以外のポートをリッスンするように設定している場合は、それに応じて /etc/httpd/conf/httpd.conf ファイルのグローバル設定セクションの Listen ディレクティブを必ず更新してください。

新しく作成された仮想ホストを有効にするには、最初に Web サーバーを再起動します。httpd サービスを再起動する方法は、「サービスの再起動」を参照してください。

1.8. SSL サーバーの設定

Secure Sockets Layer (SSL) は、サーバーとクライアントが安全に接続できるようにする暗号化プロトコルです。Transport Layer Security (TLS) と呼ばれる拡張され改善されたバージョンとともに、プライバシーとデータの整合性の両方が確保されます。Apache HTTP Server を mod_ssl と組み合わせて、OpenSSL ツールキットを使用して SSL/TLS サポートを提供するモジュールは、SSL サーバー と呼ばれます。

傍受できる人であればだれでも読み取りや修正が可能な HTTP 接続とは異なり、HTTPS と呼ばれる SSL/TLS over HTTP の使用により、送信したコンテンツの検査や修正が阻止されます。本セクションでは、Apache HTTP Server 設定でこのモジュールを有効にする方法の基本情報を提供し、秘密鍵と自己署名証明書の生成プロセスを説明します。

1.8.1. 証明書およびセキュリティーの概要

通信の安全性は、鍵の使用により確保されます。従来の暗号または 対称暗号 では、トランザクションの両端に、相互に送信をデコードするのに使用する鍵と同じ鍵があります。一方、公開暗号または 非対称暗号 では、秘密鍵 (秘密を保持する) と 公開鍵 (通常は公共と共有) が共存します。公開鍵でエンコードされたデータは秘密鍵でしかデコードできませんが、秘密鍵でエンコードされたデータは公開鍵でしかデコードできません。

SSL を使用した安全な通信を提供するには、SSL サーバーが 認証機関 (CA) が署名したデジタル証明書を使用する必要があります。証明書は、サーバーの各種属性 (サーバーのホスト名、会社名、会社の場所など) と、CA の秘密鍵を使用して生成した署名を一覧表示します。この署名は、特定の認証局が証明書を署名し、証明書がいかなる方法でも変更されていないことを確認するものです。

1.8.2. Web サーバーの証明書およびセキュリティー

Web ブラウザーが新しい SSL 接続を確立すると、Web サーバーが提供する証明書が確認されます。証明書に、信頼できる CA からの署名がない場合や、証明書に一覧表示されているホスト名が、接続の確立に使用されたホスト名と一致しない場合は、サーバーとの通信が拒否され、通常は、ユーザーに適切なエラーメッセージが表示されます。

デフォルトでは、ほとんどの Web ブラウザーは、幅広く使用されている一連の証明書局を信頼するように設定されています。このため、安全なサーバーを設定する際には、適切な CA を選択して、ターゲットユーザーが接続を信頼できる状態にする必要があります。適切な CA を選択しないとエラーメッセージが表示され、証明書を手動で指定することが必要になります。ユーザーが証明書エラーを上書きするようにすると、攻撃者が接続を傍受できるため、可能な場合は信頼できる CA を使用する必要があります。詳細は表1.3「一般的な Web ブラウザーが使用する CA リストに関する情報」を参照してください。

表1.3 一般的な Web ブラウザーが使用する CA リストに関する情報

Web ブラウザー	リンク
Mozilla Firefox	Mozilla root CA の一覧
Opera	Opera で使用されるルート証明書に関する情報
Internet Explorer	Microsoft Windows で使用されるルート証明書に関する情報
Chromium	Chromium プロジェクトが使用するルート証明書に関する情報。

SSL サーバーを設定する場合は、証明書の要求と秘密鍵を生成し、証明書の要求、会社の ID の証明、および認証機関への支払いを送信します。CA が証明書の要求および ID を確認すると、サーバーで使用できる署名付きの証明書が送信されます。また、CA 署名を含まない自己署名証明書を作成することもできるため、テスト目的でのみ使用してください。

1.9. mod_ssl モジュールの有効化

mod_ssl を使用して TLS (SSL) サーバーを設定する場合は、別のアプリケーションやモジュールが同じポートを使用するように設定することは できません 。ポート 443 は、HTTPS のデフォルトポートです。

mod_ssl モジュールおよび OpenSSL ツールキットを使用して SSL サーバーを設定するには、mod_ssl パッケージと openssl パッケージをインストールします。root で以下のコマンドを実行します。

~]# yum install mod_ssl openssl

これにより、/etc/httpd/conf.d/ssl.conf に mod_ssl 設定ファイルが作成されます。このファイルは、デフォルトでメインとなる Apache HTTP Server 設定ファイルに含まれています。モジュールを読み込むには、「サービスの再起動」の説明どおりに httpd サービスを再起動します。

重要

SSLv2 プロトコルおよび SSLv3 プロトコルのバージョンは、安全と見なされなくなったため、OpenSSL (および mod_ssl) から削除されました。

1.9.1. mod_ssl で異なるバージョンの TLS の有効化

RHEL 8 のデフォルトの httpd インストールには、SSLProtocol ディレクティブがコメントアウトされています。したがって、httpd はシステム全体の暗号化ポリシーに従い、TLS 1.2 および TLS 1.3 の接続のみが許可されます。詳細は「システム全体の暗号化ポリシーの使用」を参照してください。

TLS プロトコルの特定バージョンは、グローバルまたはサイトごとに有効または無効にできます。

プロトコルバージョンをグローバルに指定するには、設定ファイルの SSL Global Context セクションに SSLProtocol ディレクティブを追加し、その他の場所から削除します。
あるサイトのプロトコルバージョンを指定するには、該当する VirtualHost セクションの SSL Protocol support の下にあるデフォルトのエントリーを編集します。各サイトの VirtualHost セクションでプロトコルバージョンを指定しないと、サイトはグローバルセクションから設定を継承します。

特定のプロトコルバージョンが有効になっていることを確認するには、管理者が、SSL Global Context セクションのみ、もしくは各サイトの VirtualHost セクションに SSLProtocol を指定する必要があります。

TLSv1.x の特定のバージョンの有効化

特定バージョンの TLSv1.x プロトコルのみを有効にするには、以下の手順に従います。

root で /etc/httpd/conf.d/ssl.conf ファイルを開き、 SSLProtocol ディレクティブの すべて のインスタンスを検索します。デフォルトでは、このファイルには以下のようなセクションが含まれます。

~]# vi /etc/httpd/conf.d/ssl.conf
#   List the protocol versions which clients are allowed to connect with.
#   The OpenSSL system profile is used by default.  See
#   update-crypto-policies(8) for more details.
#SSLProtocol all -SSLv3
#SSLProxyProtocol all -SSLv3

たとえば、TLS プロトコルをバージョン 1.3 に設定するには、以下のように SSLProtocol 行を編集します。
```
SSLProtocol -all +TLSv1.3
```
ファイルを保存してから閉じます。

以下のように変更を確認します。

~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf
SSLProtocol -all +TLSv1.3

以下のように Apache デーモンを再起動します。
```
~]# systemctl restart httpd
```
セッションが中断されることに注意してください。

TLS プロトコルのステータスのテスト

有効または無効になっている TLS のバージョンを確認するには、openssl s_client -connect コマンドを使用します。このコマンドの形式は以下のとおりです。

openssl s_client -connect hostname:port -protocol

port は、テストするポートで、protocol は、テストするプロトコルバージョンです。ローカルで稼働している SSL サーバーをテストする場合は、localhost をホスト名として使用します。

openssl s_client コマンドのオプションは、man ページの s_client (1) に記載されています。

1.9.2. TLS 証明書の自動プロビジョニングおよび更新

(Let’s Encrypt などの証明書プロバイダーで使用するため) 自動証明書管理環境 (ACME) プロトコルを使用した、TLS 証明書の自動プロビジョニングおよび更新に、mod_md パッケージで対応するようになりました。

1.10. 既存の鍵および証明書の使用

以前に作成した鍵と証明書がある場合は、新しいファイルを生成する代わりに、SSL サーバーを設定してこのファイルを使用できます。これが可能ではない状況は 2 つしかありません。

IP アドレスまたはドメイン名を変更している。
証明書が、特定の IP アドレスとドメイン名のペアに対して発行されます。この値のいずれかが変更すると、証明書が無効になります。
VeriSign からの証明書があり、サーバーソフトウェアを変更している。
Verivsftpd は、幅広く使用されている認証局で、特定のソフトウェア製品、IP アドレス、およびドメイン名の証明書を発行します。ソフトウェア製品を変更すると、証明書が無効になります。

上記のいずれの場合も、新しい証明書を入手する必要があります。

既存の鍵と証明書を使用する場合は、root で以下のコマンドを実行し、関連ファイルを /etc/pki/tls/private/ ディレクトリーおよび /etc/pki/tls/certs/ ディレクトリーに移動します。

~]# mv key_file.key /etc/pki/tls/private/hostname.key
~]# mv certificate.crt /etc/pki/tls/certs/hostname.crt

次に、以下の行を /etc/httpd/conf.d/ssl.conf 設定ファイルに追加します。

SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key

更新した設定を読み込むには、「サービスの再起動」の説明に従って、httpd サービスを再起動します。

1.11. コマンドラインを使用して HTTP 用および HTTPS 用にファイアウォールを設定

Red Hat Enterprise Linux は、デフォルトで HTTP トラフィックおよび HTTPS トラフィックを許可しません。システムが Web サーバーとして機能するようにするには、firewalld がサポートするサービスを使用して、必要に応じて HTTP および HTTPS のトラフィックがファイアウォールを通過するようにします。

コマンドラインで HTTP を有効にするには、root で以下のコマンドを実行します。

~]# firewall-cmd --add-service http
 success

コマンドラインで HTTPS を有効にするには、root で以下のコマンドを実行します。

~]# firewall-cmd --add-service https
 success

この変更は、次回システムを起動すると元に戻ることに注意してください。ファイアウォールを永続的に変更するには、コマンドに --permanent オプションを繰り返し追加してください。

1.11.1. コマンドラインを使用した着信 HTTPS および HTTPS のネットワークアクセスの確認

ファイアウォールが許可するサービスを確認するには、root で以下のコマンドを実行します。

~]# firewall-cmd --list-all
public (default, active)
  interfaces: em1
  sources:
  services: dhcpv6-client ssh
output truncated

この例では、デフォルトのインストールでファイアウォールは有効になっていますが、HTTP と HTTPS は通過できません。

HTTP および HTTP のファイアウォールサービスが有効になると、services 行は以下のようになります。

services: dhcpv6-client http https ssh

1.12. 関連情報

Apache HTTP Server の詳細は、以下のリソースを参照してください。

1.12.1. インストールされているドキュメント

httpd(8) - httpd サービスの man ページで、コマンドラインオプションの一覧が記載されます。
httpd.service(8) - httpd.service ユニットファイルの man ページです。サービスのカスタマイズおよび機能強化の方法を説明します。
httpd.conf (5) - httpd 設定ファイルの構造と場所を説明する httpd 設定用の man ページです。
apachectl (8) - Apache HTTP Server の制御インターフェースの man ページです。

1.12.2. インストール可能なドキュメント

http://localhost/manual/ - Apache HTTP Server の公式ドキュメントで、そのディレクティブおよび利用可能なモジュールの詳細を説明します。本書にアクセスするには、httpd-manual パッケージがインストールされ、Web サーバーが稼働している必要があることに注意してください。
ドキュメントにアクセスする前に、root で次のコマンドを実行します。
```
~]# yum install httpd-manual
~]# apachectl graceful
```

1.12.3. オンラインドキュメント

http://httpd.apache.org/ - Apache HTTP Server の公式 Web サイトです。すべてのディレクティブおよびデフォルトモジュールの説明が記載されています。
OpenSSL Home Page - その他のドキュメント、FAQ、メーリングリストへのリンクなどの役に立つリソースを掲載した OpenSSL のホームページです。

第2章 Samba をサーバーとして使用

Samba は、Red Hat Enterprise Linux にサーバーメッセージブロック (SMB) プロトコルを実装します。SMB プロトコルは、ファイル共有、共有プリンターなど、サーバーのリソースにアクセスするのに使用されます。また、Samba は、Microsoft Windows が使用する分散コンピューティング環境のリモートプロシージャコール (DCE RPC) のプロトコルを実装します。

Samba は以下のように実行できます。

Active Directory (AD) または NT4 ドメインメンバー
スタンドアロンサーバー
NT4 プライマリドメインコントローラー (PDC) またはバックアップドメインコントローラー (BDC)
注記
Red Hat は、NT4 ドメインに対応する Windows バージョンの既存のインストールでのみ、PDC モードおよび BDC モードをサポートします。Red Hat では、新しい Samba NT4 ドメインを設定しないことを推奨します。これは、Windows 7 および Windows Server 2008 R2 以降の Microsoft オペレーティングシステムが NT4 ドメインに対応していないためです。
Red Hat は、Samba を AD ドメインコントローラー (DC) として実行することはサポートしていません。

インストールモードとは関係なく、必要に応じてディレクトリーやプリンターを共有できます。これにより、Samba がファイルサーバーおよびプリントサーバーとして機能できるようになります。

前提条件

Red Hat Enterprise Linux 8 がサーバーにインストールされている。

2.1. Samba サービス

Samba は以下のサービスを提供します。

smbd

このサービスは、SMB プロトコルを使用してファイル共有およびプリントサービスを提供します。また、サービスは、リソースのロックと、接続ユーザーの認証を担当します。smb systemd サービスが起動し、smbd デーモンが停止します。

smbd サービスを使用するには、samba パッケージをインストールします。

nmbd

このサービスは、NetBIOS over IPv4 プロトコルを使用してホスト名および IP 解決を提供します。名前解決に加え、nmbd サービスで SMB ネットワークを参照して、ドメイン、作業グループ、ホスト、ファイル共有、およびプリンターを探すことができます。このため、サービスはこの情報をブロードキャストクライアントに直接報告するか、ローカルまたはマスターのブラウザーに転送します。nmb systemd サービスは、nmbd デーモンを起動し、停止します。

最近の SMB ネットワークは、クライアントおよび IP アドレスの解決に DNS を使用することに注意してください。

nmbd サービスを使用するには、samba パッケージをインストールします。

winbindd

このサービスは、ローカルシステムの AD または NT4 のドメインユーザーおよびグループを使用する Name Service Switch (NSS) のインターフェースを提供します。これにより、たとえばドメインユーザーを、Samba サーバーにホストされるサービスや他のローカルサービスに認証できます。winbind systemd サービスは、winbindd デーモンを開始および停止します。

Samba をドメインメンバーとして設定する場合は、smbd サービスの前に winbindd を起動する必要があります。そうしないと、ドメインユーザーおよびグループはローカルシステムで使用できなくなります。

winbindd サービスを使用するには、samba-winbind パッケージをインストールします。

重要

Red Hat は、ドメインユーザーおよびグループをローカルシステムに提供するために、Samba を、winbindd サービスを使用するサーバーとして実行することのみをサポートします。Windows アクセス制御リスト (ACL) のサポート、NT LAN Manager (NTLM) のフォールバックがないなど、特定の制限により、SSSD に対応しません。

2.2. testparm ユーティリティーを使用した smb.conf ファイルの検証

testparm ユーティリティーは、/etc/samba/smb.conf ファイルの Samba 設定が正しいことを確認します。このユーティリティーは、無効なパラメーターおよび値を検出しますが、ID マッピングなどの間違った設定も検出します。testparm が問題を報告しないと、Samba サービスは /etc/samba/smb.conf ファイルを正常に読み込みます。testparm は、設定されたサービスが利用可能であること、または期待通りに機能するかを確認できないことに注意してください。

重要

Red Hat では、このファイルの変更後に毎回 testparm を使用して、/etc/samba/smb.conf ファイルを検証することが推奨されます。

手順

root ユーザーで testparm ユーティリティーを実行します。

# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Unknown parameter encountered: "log levell"
Processing section "[example_share]"
Loaded services file OK.
ERROR: The idmap range for the domain * (tdb) overlaps with the range of DOMAIN (ad)!

Server role: ROLE_DOMAIN_MEMBER

Press enter to see a dump of your service definitions

# Global parameters
[global]
	...

[example_share]
	...

上記の出力例では、存在しないパラメーターと間違った ID マッピングの設定が報告されます。

testparm が設定内の間違ったパラメーター、値、またはその他のエラーを報告する場合は、問題を修正してから再度ユーティリティーを実行してください。

2.3. Samba セキュリティーサービス

/etc/samba/smb.conf ファイルの [global] セクションの security パラメーターは、Samba がサービスに接続しているユーザーを認証する方法を管理します。Samba をインストールするモードに応じて、パラメーターは異なる値に設定する必要があります。

AD ドメインメンバーに、security = ads を設定する。

このモードでは、Samba は Kerberos を使用して AD ユーザーを認証します。

Samba をドメインメンバーとして設定する方法は、「Samba をドメインメンバーサーバーとして設定」を参照してください。

スタンドアロンサーバーで、security = user を設定する。

このモードでは、Samba がローカルデータベースを使用して接続ユーザーを認証します。

Samba をスタンドアロンサーバーとして設定する方法は、「Samba をスタンドアロンサーバーとして設定」を参照してください。

NT4 PDC または BDC に security = user を設定する。

Samba は、このモードでは、ユーザーをローカルまたは LDAP データベースに認証します。

NT4 ドメインメンバーで、security = domain を設定する。

Samba は、このモードでは、NT4 PDC または BDC にユーザーを接続する認証を行います。このモードは、AD ドメインメンバーには使用できません。

Samba をドメインメンバーとして設定する方法は、「Samba をドメインメンバーサーバーとして設定」を参照してください。

2.4. Samba をスタンドアロンサーバーとして設定

Samba は、ドメインのメンバーではないサーバーとして設定できます。このインストールモードでは、Samba はユーザーを中央 DC ではなくローカルデータベースに認証します。また、ゲストアクセスを有効にして、ユーザーが、認証なしで 1 つまたは複数のサービスに接続できるようにすることもできます。

2.4.1. スタンドアロンサーバーのサーバー構成の設定

本セクションでは、Samba スタンドアロンサーバーにサーバー構成を設定する方法を説明します。

手順

samba パッケージをインストールします。
```
# yum install samba
```
/etc/samba/smb.conf ファイルを編集して、以下のパラメーターを設定します。
```
[global]
	workgroup = Example-WG
	netbios name = Server
	security = user

	log file = /var/log/samba/%m.log
	log level = 1
```
この構成では、Example-WG ワークグループに、スタンドアロンサーバー (Server) を定義します。また、この設定により最小レベル (1) でのログ記録が可能になり、ログファイルは /var/log/samba/ ディレクトリーに保存されます。Samba は、log file パラメーターの %m マクロを、接続しているクライアントの NetBIOS 名まで展開します。これにより、クライアントごとに個別のログファイルが有効になります。
ファイルまたはプリンターの共有を構成します。以下を参照してください。
- 「Samba サーバーでのファイル共有の設定」
- 「プリントサーバーとしての Samba の設定」
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
認証が必要な共有を設定する場合は、ユーザーアカウントを作成します。「ローカルユーザーアカウントの作成および有効化」を参照してください。
firewall-cmd ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。
```
# firewall-cmd --permanent --add-port={139/tcp,445/tcp}
# firewall-cmd --reload
```
smb サービスを起動します。
```
# systemctl start smb
```
必要に応じて、smb サービスがシステムの起動時に自動的に起動するようにします。
```
# systemctl enable smb
```

2.4.2. ローカルユーザーアカウントの作成および有効化

共有への接続時にユーザーが認証を行えるようにするには、オペレーティングシステムと Samba データベースの両方で Samba ホストにアカウントを作成する必要があります。Samba では、ファイルシステムオブジェクトでアクセス制御リスト (ACL) を検証するオペレーティングシステムアカウントと、接続ユーザーの認証を行う Samba アカウントが必要です。

passdb backend = tdbsam のデフォルト設定を使用すると、Samba はユーザーアカウントを /var/lib/samba/private/passdb.tdb データベースに保存します。

このセクションの手順では、ローカル Samba ユーザー (example) を作成する方法を説明します。

前提条件

Samba が、スタンドアロンサーバーとしてインストールされている。

手順

オペレーティングシステムアカウントを作成します。
```
# useradd -M -s /sbin/nologin example
```
このコマンドは、ホームディレクトリーを作成せずに、example アカウントを追加します。アカウントが Samba への認証のみに使用される場合は、/sbin/nologin コマンドをシェルとして割り当て、アカウントがローカルでログインしないようにします。
オペレーティングシステムのアカウントにパスワードを設定して、これを有効にします。
```
# passwd example
Enter new UNIX password: password
Retype new UNIX password: password
passwd: password updated successfully
```
Samba は、オペレーティングシステムのアカウントに設定されたパスワードを使用して認証を行いません。ただし、アカウントを有効にするには、パスワードを設定する必要があります。アカウントが無効になると、そのユーザーが接続した時に Samba がアクセスを拒否します。
Samba データベースにユーザーを追加し、そのアカウントにパスワードを設定します。
```
# smbpasswd -a example
New SMB password: password
Retype new SMB password: password
Added user example.
```
このアカウントを使用して Samba 共有に接続する場合に、このパスワードを使用して認証を行います。
Samba アカウントを有効にします。
```
# smbpasswd -e example
Enabled user example.
```

2.5. Samba をドメインメンバーサーバーとして設定

AD または NT4 のドメインを実行している場合は、Samba を使用して Red Hat Enterprise Linux サーバーをメンバーとしてドメインに追加し、以下を取得します。

その他のドメインメンバーのドメインリソースにアクセスする
sshd などのローカルサービスに対してドメインユーザーを認証する
サーバーにホストされているディレクトリーおよびプリンターを共有して、ファイルサーバーおよびプリントサーバーとして動作する

2.5.1. Samba のドメインへの参加

本セクションでは、Red Hat Enterprise Linux システムをドメインに参加させる方法を説明します。

手順

以下のパッケージをインストールします。

# yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients \
       samba-winbind samba-common-tools samba

ドメインメンバーでディレクトリーまたはプリンターを共有するには、samba パッケージをインストールします。
```
# yum install samba
```
AD に参加する場合は、Winbind Kerberos ロケータープラグインもインストールします。
```
# yum install samba-winbind-krb5-locator
```
このプラグインを使用すると、Kerberos は DNS サービスレコードを使用して、AD サイトに基づいて鍵配布センター (KDC) を探すことができます。
必要に応じて、既存の Samba 設定ファイル (/etc/samba/smb.conf) の名前を変更して、バックアップを作成します。
```
# mv /etc/samba/smb.conf /etc/samba/smb.conf.old
```
ドメインに参加します。たとえば、ドメイン ad.example.com に参加するには、以下のコマンドを実行します。
```
# realm join --client-software=winbind ad.example.com
```
上記のコマンドを使用すると、realm ユーティリティーが自動的に以下を実行します。
- ad.example.com ドメインのメンバーシップに /etc/samba/smb.conf ファイルを作成します。
- ユーザーおよびグループの検索用の winbind モジュールを、/etc/nsswitch.conf ファイルに追加します。
- /etc/pam.d/ ディレクトリーの PAM (プラグ可能な認証モジュール) 設定ファイルを更新します。
- winbind サービスを起動し、システムの起動時にサービスを起動できるようにします。
必要に応じて、/etc/samba/smb.conf ファイルの別の ID マッピングバックエンド、またはカスタマイズした ID マッピングを設定します。詳細は「Samba ID マッピング」を参照してください。
必要に応じて設定を検証します。「Samba がドメインメンバーとして正しく参加されたことを確認」を参照してください。
winbind サービスが稼働していることを確認します。
```
# systemctl status winbind
...
   Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago
```
重要
Samba がドメインのユーザーおよびグループの情報をクエリーできるようにするには、smb を起動する前に winbind サービスを実行する必要があります。
samba パッケージをインストールしてディレクトリーおよびプリンターを共有している場合は、smb サービスを開始します。
```
# systemctl start smb
```
必要に応じて、Active Directory へのローカルログインを認証する場合は、winbind_krb5_localauth プラグインを有効にします。「MIT Kerberos 用のローカル承認プラグインの使用」を参照してください。

2.5.2. Samba がドメインメンバーとして正しく参加されたことを確認

ドメインに正しく Red Hat Enterprise Linux を追加したことを確認するには、ドメインメンバーに、本セクションで説明しているテストを実行します。

2.5.2.1. オペレーティングシステムが、ドメインのユーザーアカウントおよびグループを取得できるかどうかの検証

getent ユーティリティーおよび chown ユーティリティーを使用して、オペレーティングシステムがドメインのユーザーおよびグループを取得できることを確認します。

手順

AD ドメインの 管理者 アカウントをクエリーするには、以下を実行します。

# getent passwd "AD\administrator"
AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash

AD ドメイン内の Domain Users グループのメンバーにクエリーするには、以下を実行します。
```
# getent group "AD\Domain Users"
AD\domain users:x:10000:user1,user2
```
ファイルやディレクトリーに権限を設定する際に、ドメインのユーザーおよびグループを使用できることを確認します。たとえば、/srv/samba/example.txt ファイルの所有者を AD\administrator に設定し、グループを AD\Domain Users に設定するには、以下のコマンドを実行します。
```
# chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt
```

2.5.2.2. AD ドメインユーザーが Kerberos チケットを取得できるかどうかの確認

AD 環境では、DC から Kerberos チケットを取得できます。

本セクションの手順では、管理者 ユーザーが、Kerberos チケットを取得できるかどうかを検証する方法を説明します。

前提条件

Samba ドメインメンバーに krb5-workstation パッケージをインストールします。

手順

AD ドメインメンバーで、administrator@AD.EXAMPLE.COM プリンシパルのチケットを取得します。
```
# kinit administrator@AD.EXAMPLE.COM
```

キャッシュされた Kerberos チケットを表示します。

# klist
Ticket cache: KCM:0
Default principal: administrator@AD.EXAMPLE.COM

Valid starting       Expires              Service principal
01.11.2018 10:00:00  01.11.2018 20:00:00  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
        renew until 08.11.2018 05:00:00

2.5.2.3. 利用可能なドメインの一覧表示

wbinfo ユーティリティーを使用して、winbindd サービスを介して利用可能なドメインを一覧表示します。

手順

# wbinfo --all-domains

Samba がドメインメンバーとして適切に参加すると、このコマンドは組み込みおよびローカルのホスト名を表示し、ドメインの Samba は信頼されるドメインを含むメンバーとなります。

例2.1 利用可能なドメインの表示

以下は、wbinfo --all-domains コマンドの出力例です。

# wbinfo --all-domains
BUILTIN
SAMBA-SERVER
AD

2.5.3. MIT Kerberos 用のローカル承認プラグインの使用

winbind サービスは、Active Directory ユーザーをドメインメンバーに提供します。特定の状況では、管理者が、ドメインメンバーで実行している SSH サーバーなどのローカルサービスに対して、ドメインユーザーが認証を行えるようにします。Kerberos を使用してドメインユーザーを認証している場合は、winbind サービスを介して、winbind_krb5_localauth プラグインが Kerberos プリンシパルを Active Directory アカウントに正しくマッピングできるようにします。

たとえば、Active Directory ユーザーの sAMAccountName 属性を EXAMPLE に設定し、小文字のユーザー名でユーザーがログインしようとすると、Kerberos はユーザー名を大文字で返します。その結果、エントリーは認証の失敗に一致しません。

winbind_krb5_localauth プラグインを使用すると、アカウント名が正しくマッピングされます。これは GSSAPI 認証にのみ適用され、初期のチケット付与チケット (TGT) の取得には該当しません。

前提条件

Samba が Active Directory のメンバーとして設定されている。
Red Hat Enterprise Linux が、Active Directory に対してログイン試行を認証している。
winbind サービスが実行している。

手順

/etc/krb5.conf ファイルを編集し、以下のセクションを追加します。

[plugins]
localauth = {
     module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
     enable_only = winbind
}

2.5.4. Samba ID マッピング

Windows ドメインは、ユーザーおよびグループを一意のセキュリティ識別子 (SID) で区別します。ただし、Linux では、ユーザーおよびグループごとに一意の UID と GID が必要です。Samba をドメインメンバーとして実行する場合は、winbindd サービスが、ドメインユーザーおよびグループに関する情報をオペレーティングシステムに提供します。

winbindd サービスが、ユーザーおよびグループの一意の ID を Linux に提供するようにするには、/etc/samba/smb.conf ファイルで ID マッピングを設定する必要があります。

ローカルデータベース (デフォルトドメイン)
Samba サーバーがメンバーになっている AD または NT4 のドメイン
ユーザーがこの Samba サーバーのリソースにアクセスする必要のある信頼ドメイン

2.5.4.1. Samba ID 範囲の計画

Linux の UID および GID を AD に保存するか、Samba がそれを生成するように設定するかに関係なく、各ドメイン設定には、他のドメインと重複しない一意の ID 範囲が必要です。

警告

重複する ID 範囲を設定すると、Samba が正常に機能しなくなります。

例2.2 一意の ID 範囲

以下は、デフォルト (*)、AD-DOM、および TRUST-DOM のドメインの非オーバーランディングの ID マッピング範囲を示しています。

[global]
...
idmap config * : backend = tdb
idmap config * : range = 10000-999999

idmap config AD-DOM:backend = rid
idmap config AD-DOM:range = 2000000-2999999

idmap config TRUST-DOM:backend = rid
idmap config TRUST-DOM:range = 4000000-4999999

重要

1 つのドメインに割り当てられるのは 1 つの範囲だけです。したがって、ドメイン範囲間で十分な容量を残しておきます。これにより、ドメインが拡大した場合に、後で範囲を拡張できます。

後で別の範囲をドメインに割り当てると、このユーザーおよびグループが作成したファイルおよびディレクトリーの所有権が失われます。

2.5.4.2. * デフォルトドメイン

ドメイン環境では、以下の各 ID マッピング設定を追加します。

Samba サーバーがメンバーとなっているドメイン
Samba サーバーにアクセスできる信頼された各ドメイン

ただし、Samba が、その他のすべてのオブジェクトに、デフォルトドメインから ID を割り当てます。これには以下が含まれます。

ローカルの Samba ユーザーおよびグループ
Samba の組み込みアカウントおよびグループ (BUILTIN\Administrators など)

重要

Samba が正常に機能できるようにするには、このセクションで説明されているデフォルトのドメインを設定する必要があります。

割り当てられた ID を永続的に格納するには、デフォルトのドメインバックエンドを書き込み可能にする必要があります。

デフォルトドメインには、以下のいずれかのバックエンドを使用できます。

tdb

デフォルトのドメインを、tdb バックエンドを使用するように設定する場合は、ID 範囲を設定します。この ID 範囲には、将来作成されるオブジェクトや、定義されたドメイン ID マッピング設定には含まれないオブジェクトを追加できます。

たとえば、/etc/samba/smb.conf ファイルの [global] セクションで以下を設定します。

idmap config * : backend = tdb
idmap config * : range = 10000-999999

詳細は「tdb ID マッピングバックエンドの使用」を参照してください。

autorid

autorid バックエンドを使用するように、デフォルトのドメインを設定する場合、ドメイン用の ID マッピング設定を追加するかどうかは任意になります。

たとえば、/etc/samba/smb.conf ファイルの [global] セクションで以下を設定します。

idmap config * : backend = autorid
idmap config * : range = 10000-999999

詳細は「autorid ID マッピングバックエンドの使用」を参照してください。

2.5.5. 異なる Samba ID マッピングバックエンド

Samba は、特定の設定に対して異なる ID マッピングバックエンドを提供します。最も頻繁に使用されるバックエンドは、以下の通りです。

バックエンド	ユースケース
`tdb`	`*` デフォルトドメインのみ
`ad`	AD ドメインのみ
`rid`	AD ドメインおよび NT4 ドメイン
`autorid`	AD、NT4、および `*` デフォルトのドメイン

以下のセクションでは、利点、バックエンドを使用する際の推奨シナリオ、および設定方法を説明します。

2.5.5.1. tdb ID マッピングバックエンドの使用

winbindd サービスは、デフォルトで書き込み可能な tdb ID マッピングバックエンドを使用して、セキュリティー識別子 (SID)、UID、および GID のマッピングテーブルを格納します。これには、ローカルユーザー、グループ、組み込みプリンシパルが含まれます。

このバックエンドは、* デフォルトドメインにのみ使用してください。以下に例を示します。

idmap config * : backend = tdb
idmap config * : range = 10000-999999

2.5.5.2. ad ID マッピングバックエンドの使用

本セクションでは、ad ID マッピングバックエンドを使用するように Samba AD メンバーを設定する方法を説明します。

ad ID マッピングバックエンドは、読み取り専用 API を実装し、AD からアカウントおよびグループの情報を読み取ります。これには、以下の利点があります。

ユーザーとグループの全設定は、AD に集中的に保存されます。
ユーザーおよびグループの ID は、このバックエンドを使用するすべての Samba サーバーで一貫しています。
ID は、破損する可能性のあるローカルデータベースには保存されないため、ファイルの所有権は失われません。

注記

ad ID マッピングバックエンドは、一方向の信頼を使用する Active Directory ドメインに対応していません。一方向の信頼で Active Directory のドメインメンバーを設定する場合は、tdb、 rid、または autorid のいずれかの ID マッピングバックエンドを使用します。

ad バックエンドは、AD から以下の属性を読み込みます。

AD 属性名	オブジェクトの種類	マッピング先
`sAMAccountName`	ユーザーおよびグループ	オブジェクトのユーザー名またはグループ名
`uidNumber`	ユーザー	ユーザー ID (UID)
`gidNumber`	グループ	グループ ID (GID)
`loginShell` ^[a]	ユーザー	ユーザーのシェルのパス
`unixHomeDirectory` ^[a]	ユーザー	ユーザーのホームディレクトリーのパス
`primaryGroupID` ^[b]	ユーザー	プライマリグループ ID
^[a] `idmap config DOMAIN:unix_nss_info = yes` を設定している場合に限り、Samba がこの属性を読み込みます。 ^[b] `idmap config DOMAIN:unix_primary_group = yes` を設定している場合に限り、Samba がこの属性を読み込みます。

前提条件

ad ID マッピングバックエンドを使用する場合は、以下を実行している。

ユーザーおよびグループはいずれも、AD で一意の ID が設定され、ID が、/etc/samba/smb.conf ファイルで設定されている範囲内にある。ID が範囲外にあるオブジェクトは、Samba サーバーでは利用できません。
ユーザーおよびグループには、AD ですべての必須属性が設定されている。必要な属性がないと、ユーザーまたはグループは Samba サーバーで使用できなくなります。必要な属性は、設定によって異なります。

手順

/etc/samba/smb.conf ファイルの [global] セクションを編集します。
1. デフォルトドメイン (*) に ID マッピング設定が存在しない場合は追加します。以下に例を示します。
```
idmap config * : backend = tdb
idmap config * : range = 10000-999999
```
2. AD ドメインの ad ID マッピングバックエンドを有効にします。
```
idmap config DOMAIN : backend = ad
```
3. AD ドメインのユーザーおよびグループに割り当てられている ID の範囲を設定します。以下に例を示します。
```
idmap config DOMAIN : range = 2000000-2999999
```
  重要
  この範囲は、このサーバーの他のドメイン構成と重複させることはできません。また、この範囲には、今後割り当てられる ID がすべて収まる大きさを設定する必要があります。詳細は「Samba ID 範囲の計画」を参照してください。
4. Samba が AD から属性を読み取る際に RFC 2307 スキーマを使用するように設定します。
```
idmap config DOMAIN : schema_mode = rfc2307
```
5. Samba が、対応する AD 属性からログインシェルおよびユーザーホームディレクトリーのパスを読み取るようにする場合は、以下を設定します。
```
idmap config DOMAIN : unix_nss_info = yes
```
  または、すべてのユーザーに適用される、ドメイン全体のホームディレクトリーのパスおよびログインシェルを統一して設定できます。以下に例を示します。
```
template shell = /bin/bash
template homedir = /home/%U
```
6. デフォルトでは、Samba は、ユーザーオブジェクトの primaryGroupID 属性を、Linux のユーザーのプライマリーグループとして使用します。または、代わりに gidNumber 属性に設定されている値を使用するように Samba を設定できます。
```
idmap config DOMAIN : unix_primary_group = yes
```
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
Samba 設定を再読み込みします。
```
# smbcontrol all reload-config
```
設定が期待どおりに機能することを確認します。「オペレーティングシステムが、ドメインのユーザーアカウントおよびグループを取得できるかどうかの検証」を参照してください。

2.5.5.3. rid ID マッピングバックエンドの使用

本セクションでは、rid ID マッピングバックエンドを使用するように Samba ドメインメンバーを設定する方法を説明します。

Samba は、Windows SID の相対識別子 (RID) を使用して、Red Hat Enterprise Linux で ID を生成できます。

注記

RID は、SID の最後の部分です。たとえば、ユーザーの SID が S-1-5-21-5421822485-1151247151-421485315-30014 の場合、対応する RID は 30014 になります。

rid ID マッピングバックエンドは、AD ドメインおよび NT4 ドメインのアルゴリズムマッピングスキームに基づいてアカウントおよびグループの情報を計算する読み取り専用 API を実装します。バックエンドを設定する場合は、idmap config DOMAIN : range パラメーターで、RID の最小値および最大値を設定する必要があります。Samba は、このパラメーターで設定される RID の最小値および最大値を超えるユーザーまたはグループをマッピングしません。

重要

読み取り専用のバックエンドとして、rid は、BUILTIN グループなど、新しい ID を割り当てることができません。したがって、* デフォルトドメインにはこのバックエンドを使用しないでください。

rid バックエンドを使用した利点

設定された範囲内の RID があるドメインユーザーとグループはすべて、自動的にドメインメンバーで利用可能になります。
ID、ホームディレクトリー、およびログインシェルを手動で割り当てる必要はありません。

rid バックエンドを使用した場合の短所

すべてのドメインユーザーは、割り当てられた同じログインシェルとホームディレクトリーを取得します。ただし、変数を使用できます。
同じ ID 範囲設定で rid バックエンドを使用している Samba ドメインメンバーでは、ユーザー ID とグループ ID が同じになります。
ドメインメンバーで個々のユーザーまたはグループを除外して、利用できないようにすることはできません。設定されている範囲外にあるユーザーとグループのみが除外されます。
異なるドメインのオブジェクトの RID が同じ場合は、winbindd サービスが ID の計算に使用する式に基づき、複数ドメインの環境で重複する ID が発生する場合があります。

手順

/etc/samba/smb.conf ファイルの [global] セクションを編集します。
1. デフォルトドメイン (*) に ID マッピング設定が存在しない場合は追加します。以下に例を示します。
```
idmap config * : backend = tdb
idmap config * : range = 10000-999999
```
2. ドメインの rid ID マッピングバックエンドを有効にします。
```
idmap config DOMAIN : backend = rid
```
3. 今後割り当てられるすべての RID が収まる大きさの範囲を設定します。以下に例を示します。
```
idmap config DOMAIN : range = 2000000-2999999
```
  Samba は、そのドメインの RID がその範囲内にないユーザーおよびグループを無視します。
  重要
  この範囲は、このサーバーの他のドメイン構成と重複させることはできません。詳細は「Samba ID 範囲の計画」を参照してください。
4. すべてのマッピングユーザーに割り当てられるシェルおよびホームディレクトリーのパスを設定します。以下に例を示します。
```
template shell = /bin/bash
template homedir = /home/%U
```
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
Samba 設定を再読み込みします。
```
# smbcontrol all reload-config
```
設定が期待どおりに機能することを確認します。「オペレーティングシステムが、ドメインのユーザーアカウントおよびグループを取得できるかどうかの検証」を参照してください。

2.5.5.4. autorid ID マッピングバックエンドの使用

本セクションでは、Samba ドメインメンバーを設定して、autorid ID マッピングバックエンドを使用する方法を説明します。

autorid バックエンドは、rid ID マッピングバックエンドと同様の動作をしますが、異なるドメインに対して自動的に ID を割り当てることができます。これにより、以下の状況で autorid バックエンドを使用できます。

* デフォルトドメインのみ
* デフォルトドメインと追加のドメインでは、追加のドメインごとに ID マッピング設定を作成する必要はありません。
特定のドメインのみ

注記

デフォルトドメインに autorid を使用する場合は、ドメイン用の ID マッピング設定を追加するかどうかは任意です。

このセクションの一部は、Samba Wiki に公開されているドキュメント「idmap config autorid」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。

autorid バックエンドを使用した利点

設定された範囲内に計算した UID と GID があるすべてのドメインユーザーおよびグループは、ドメインメンバーで自動的に利用可能になります。
ID、ホームディレクトリー、およびログインシェルを手動で割り当てる必要はありません。
複数ドメイン環境内の複数のオブジェクトが同じ RID を持つ場合でも、重複する ID はありません。

短所

Samba ドメインメンバー間では、ユーザー ID とグループ ID は同じではありません。
すべてのドメインユーザーは、割り当てられた同じログインシェルとホームディレクトリーを取得します。ただし、変数を使用できます。
ドメインメンバーで個々のユーザーまたはグループを除外して、利用できないようにすることはできません。計算された UID または GID が、設定された範囲外にあるユーザーとグループのみが除外されます。

手順

/etc/samba/smb.conf ファイルの [global] セクションを編集します。
1. * デフォルトドメインの autorid ID マッピングバックエンドを有効にします。
```
idmap config * : backend = autorid
```
2. 既存および将来の全オブジェクトに ID を割り当てられる大きさの範囲を設定します。以下に例を示します。
```
idmap config * : range = 10000-999999
```
  Samba は、このドメインで計算した ID が範囲内にないユーザーおよびグループを無視します。
  警告
  範囲を設定し、Samba がそれを使用して開始してからは、範囲の上限を小さくすることはできません。範囲にその他の変更を加えると、新しい ID 割り当てが発生し、ファイルの所有権が失われる可能性があります。
3. 必要に応じて、範囲サイズを設定します。以下に例を示します。
```
idmap config * : rangesize = 200000
```
  Samba は、idmap config * : range パラメーターに設定されている範囲からすべての ID を取得するまで、各ドメインのオブジェクトにこの数の連続 ID を割り当てます。
4. すべてのマッピングユーザーに割り当てられるシェルおよびホームディレクトリーのパスを設定します。以下に例を示します。
```
template shell = /bin/bash
template homedir = /home/%U
```
5. 必要に応じて、ドメイン用の ID マッピング設定を追加します。個別のドメインの設定が利用できない場合、Samba は以前に設定した * デフォルトドメインの autorid バックエンド設定を使用して ID を計算します。
  重要
  各ドメインに追加のバックエンドを設定する場合は、すべての ID マッピング設定の範囲がオーバーラップしないようにしてください。詳細は「Samba ID 範囲の計画」を参照してください。
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
Samba 設定を再読み込みします。
```
# smbcontrol all reload-config
```
設定が期待どおりに機能することを確認します。「オペレーティングシステムが、ドメインのユーザーアカウントおよびグループを取得できるかどうかの検証」を参照してください。

2.6. Samba サーバーでのファイル共有の設定

Samba をファイルサーバーとして使用する場合は、スタンドアロンサーバーまたはドメインメンバー設定の /etc/samba/smb.conf ファイルに共有を追加します。

以下のいずれかを使用する共有を追加できます。

POSIX ACL。「POSIX ACL を使用する共有の設定」を参照してください。
きめ細かな Windows ACL。「Windows ACL を使用する共有の設定」を参照してください。

前提条件

Samba が、以下のいずれかのモードで設定されている。

スタンドアロンサーバー
ドメインメンバー

2.6.1. POSIX ACL を使用する共有の設定

Samba は、Linux サービスとして、POSIX ACL との共有に対応します。chmod などのユーティリティーを使用して、Samba サーバーの権限をローカルに管理できます。拡張属性に対応するファイルシステムに共有が保存されている場合は、複数のユーザーおよびグループで ACL を定義できます。

注記

代わりにきめ細かな Windows ACL を使用する必要がある場合は、「Windows ACL を使用する共有の設定」を参照してください。

このセクションの一部は、Samba Wiki に公開されているドキュメント「Setting up a Share Using POSIX ACLs」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。

2.6.1.2. POSIX ACL を使用する共有で ACL の設定

本セクションでは、POSIX ACL を使用する共有に ACL を設定する方法を説明します。

POSIX ACL を使用する共有は、以下に対応します。

標準的な Linux ACL。詳細は「標準の Linux ACL の設定」を参照してください。
拡張 ACL。詳細は「拡張 ACL の設定」を参照してください。

POSIX ACL の共有が、「POSIX ACL を使用する共有の追加」に従って更新されている。

2.6.1.2.1. 標準の Linux ACL の設定

Linux の標準 ACL は、所有者、グループ、その他の未定義ユーザーの権限の設定に対応します。ユーティリティーの chown、chgrp、および chmod を使用して ACL を更新できます。正確な制御が必要な場合は、より複雑な POSIX ACL を使用します。「拡張 ACL の設定」を参照してください。

以下の手順では、/srv/samba/example/ ディレクトリーの所有者を root ユーザーに設定し、Domain Users グループに読み取りおよび書き込みの権限を付与して、他のすべてのユーザーのアクセスを拒否します。

手順

# chown root:"Domain Users" /srv/samba/example/
# chmod 2770 /srv/samba/example/

注記

ディレクトリーで set-group-ID (SGID) ビットを有効にすると、新しいディレクトリーエントリーを作成したユーザーのプライマリーグループに設定する通常の動作の代わりに、すべての新しいファイルとサブディレクトリーのデフォルトグループが、そのディレクトリーグループのデフォルトグループに自動的に設定されます。

2.6.1.2.2. 拡張 ACL の設定

共有ディレクトリーが保存されているファイルシステムが拡張 ACL に対応している場合は、それを使用して複雑な権限を設定できます。拡張 ACL には、複数のユーザーおよびグループの権限を指定できます。

拡張 POSIX ACL を使用すると、複数のユーザーおよびグループで複雑な ACL を設定できます。ただし、設定できるのは以下の権限のみです。

アクセスなし
読み取りアクセス
書き込みアクセス
完全な制御

フォルダーの作成やデータの追加 など、詳細な Windows 権限が必要な場合は、Windows ACL を使用するように共有を設定します。「Windows ACL を使用する共有の設定」を参照してください。

以下の手順では、共有で拡張 ACL を有効にする方法を説明します。また、拡張 ACL の設定例も含まれています。

手順

/etc/samba/smb.conf ファイルの共有セクションで以下のパラメーターを有効にして、拡張 ACL の ACL 継承を有効にします。
```
inherit acls = yes
```
詳細は、man ページの smb.conf(5) のパラメーターの説明を参照してください。
smb サービスを再起動します。
```
# systemctl restart smb
```

ディレクトリーの ACL を設定します。以下に例を示します。

例2.3 拡張 ACL の設定

以下の手順は、/srv/samba/example/ ディレクトリーに対して、Domain Admins グループに読み取り、書き込み、および実行の権限、Domain Users グループに対する読み取りおよび実行の権限を設定し、その他の全員のアクセスを拒否します。

ユーザーアカウントのプライマリーグループへの自動許可権限を無効にします。
```
# setfacl -m group::--- /srv/samba/example/
# setfacl -m default:group::--- /srv/samba/example/
```
ディレクトリーのプライマリーグループは、さらに動的な CREATOR GROUP プリンシパルにマッピングされます。Samba 共有で拡張 POSIX ACL を使用すると、このプリンシパルは自動的に追加され、削除できません。
ディレクトリーに権限を設定します。
1. Domain Admins グループに読み取り、書き込み、および実行の権限を付与します。
```
# setfacl -m group:"DOMAIN\Domain Admins":rwx /srv/samba/example/
```
2. Domain Users グループに読み取りおよび実行の権限を付与します。
```
# setfacl -m group:"DOMAIN\Domain Users":r-x /srv/samba/example/
```
3. その他 の ACL エントリーに権限を設定し、その他の ACL エントリーに一致しないユーザーへのアクセスを拒否します。
```
# setfacl -R -m other::--- /srv/samba/example/
```
この設定は、このディレクトリーにのみ適用されます。Windows では、これらの ACL は このフォルダーのみ のモードにマッピングされます。
前の手順で設定した権限を、このディレクトリーに作成した新規ファイルシステムのオブジェクトから継承できるようにするには、以下のコマンドを実行します。
```
# setfacl -m default:group:"DOMAIN\Domain Admins":rwx /srv/samba/example/
# setfacl -m default:group:"DOMAIN\Domain Users":r-x /srv/samba/example/
# setfacl -m default:other::--- /srv/samba/example/
```
この設定では、プリンシパルの このフォルダーのみ モードが、このフォルダー、サブフォルダー、およびファイル に設定されます。

Samba は、手順に設定されている権限を、以下の Windows ACL にマッピングします。

プリンシパル	アクセス	適用先
Domain\Domain Admins	完全な制御	このフォルダー、サブフォルダー、およびファイル
Domain\Domain Users	読み取りおよび実行	このフォルダー、サブフォルダー、およびファイル
`Everyone` ^[a]	なし	このフォルダー、サブフォルダー、およびファイル
owner (Unix User\owner) ^[b]	完全な制御	このフォルダーのみ
primary_group (Unix User\primary_group) ^[c]	なし	このフォルダーのみ
`CREATOR OWNER` ^[d] ^[e]	完全な制御	サブフォルダーおよびファイルのみ
`CREATOR GROUP` ^[e] ^[f]	なし	サブフォルダーおよびファイルのみ
^[a] Samba は、このプリンシパルの権限を `その他` の ACL エントリーからマッピングします。 ^[b] Samba は、ディレクトリーの所有者をこのエントリーにマッピングします。 ^[c] Samba は、ディレクトリーのプライマリーグループをこのエントリーにマッピングします。 ^[d] 新規ファイルシステムオブジェクトでは、作成者はこのプリンシパルの権限を自動的に継承します。 ^[e] POSIX ACL を使用する共有では、このプリンシパルの設定または削除には対応していません。 ^[f] 新規ファイルシステムオブジェクトの場合、作成者のプライマリーグループは、自動的にこのプリンシパルの権限を継承します。

2.6.1.3. POSIX ACL を使用する共有への権限の設定

必要に応じて、Samba 共有へのアクセスを制限または許可するには、/etc/samba/smb.conf ファイルの共有のセクションに特定のパラメーターを設定します。

注記

共有ベースの権限は、ユーザー、グループ、またはホストが共有にアクセスできるかどうかを管理します。この設定は、ファイルシステムの ACL には影響しません。

共有ベースの設定を使用して共有へのアクセスを制限します。たとえば、特定のホストからのアクセスを拒否します。

POSIX ACL の共有が、「POSIX ACL を使用する共有の追加」に従って更新されている。

2.6.3. smbcacls を使用した SMB 共有上の ACL の管理

smbcacls ユーティリティーは、SMB 共有に保存されたファイルおよびディレクトリーの ACL を一覧表示、設定、および削除できます。smbcacls を使用して、ファイルシステムの ACL を管理できます。

高度な Windows ACL または POSIX ACL を使用するローカルまたはリモートの Samba サーバー
Red Hat Enterprise Linux で、Windows でホストされる共有の ACL をリモートで管理

2.6.3.1. アクセス制御エントリー

ファイルシステムオブジェクトの各 ACL エントリーには、以下の形式のアクセス制御エントリー (ACE) が含まれます。

security_principal:access_right/inheritance_information/permissions

例2.4 アクセス制御エントリー

AD\Domain Users グループに、Windows 上の このフォルダー、サブフォルダー、およびファイル に適用される 変更 権限がある場合、ACL には以下の ACE が含まれます。

AD\Domain Users:ALLOWED/OI|CI/CHANGE

ACE には、以下が含まれます。

セキュリティープリンシパル

セキュリティープリンシパルは、ACL の権限が適用されるユーザー、グループ、または SID です。

アクセス権

オブジェクトへのアクセスが許可または拒否されるかどうかを定義します。値は ALLOWED または DENIED です。

継承情報

次の値を取ります。

表2.1 継承の設定

値	説明	マップ先
`OI`	オブジェクトの継承	このフォルダーおよびファイル
`CI`	コンテナーの継承	このフォルダーおよびサブフォルダー
`IO`	継承のみ	ACE は、現在のファイルまたはディレクトリーには適用されません。
`ID`	継承済	親ディレクトリーから ACE が継承されました。

また、値は以下のように組み合わせることができます。

表2.2 継承設定の組み合わせ

値の組み合わせ	Windows の `適用先` 設定にマップします。
`OI\|CI`	このフォルダー、サブフォルダー、およびファイル
`OI\|CI\|IO`	サブフォルダーおよびファイルのみ
`CI\|IO`	サブディレクトリーのみ
`OI\|IO`	ファイルのみ

権限

この値は、Windows の権限または smbcacls エイリアスを表す 16 進値になります。

1 つ以上の Windows の権限を表す 16 進値。

次の表に、Windows の高度な権限とそれに対応する値を 16 進法で表示します。

表2.3 Windows の権限とそれに対応する smbcacls 値を 16 進法で設定

Windows の権限	16 進値
完全な制御	`0x001F01FF`
フォルダーのスキャンおよびファイルの実行	`0x00100020`
フォルダーの一覧表示 / データの読み取り	`0x00100001`
属性の読み取り	`0x00100080`
拡張属性の読み取り	`0x00100008`
ファイルの作成/データの書き込み	`0x00100002`
フォルダーの作成/データの追加	`0x00100004`
属性の書き込み	`0x00100100`
拡張属性の書き込み	`0x00100010`
サブフォルダーおよびファイルの削除	`0x00100040`
削除	`0x00110000`
権限の読み取り	`0x00120000`
権限の変更	`0x00140000`
所有権の取得	`0x00180000`

ビット単位の OR 演算を使用すると、複数の権限を 1 つの 16 進値として組み合わせることができます。詳細は「ACE マスク計算」を参照してください。

smbcacls エイリアス。以下の表には、利用可能なエイリアスが表示されます。

表2.4 既存の smbcacls エイリアスとそれに対応する Windows の権限

`smbcacls` エイリアス	Windows の権限へのマッピング
`-R`	読み取り
`READ`	読み取りおよび実行
`W`	主な機能: ファイルの作成/データの書き込みフォルダーの作成/データの追加属性の書き込み拡張属性の書き込み権限の読み取り
`D`	削除
`%P`	権限の変更
`O`	所有権の取得
`X`	スキャン / 実行
`CHANGE`	修正
`FULL`	完全な制御

注記

権限を設定する際に、1 文字のエイリアスを組み合わせることができます。たとえば、Windows の権限の Read および Delete を適用するように RD を設定できます。ただし、1 文字以外のエイリアスを複数組み合わせたり、エイリアスと 16 進値を組み合わせることはできません。

2.6.3.2. smbcacls を使用した ACL の表示

SMB 共有で ACL を表示するには、smbcacls ユーティリティーを使用します。--add などの操作パラメーターを付けずに smbcacls を実行すると、ユーティリティーは、ファイルシステムオブジェクトの ACL を表示します。

手順

たとえば、//server/example 共有のルートディレクトリーの ACL を一覧表示するには、以下のコマンドを実行します。

# smbcacls //server/example / -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
REVISION:1
CONTROL:SR|PD|DI|DP
OWNER:AD\Administrators
GROUP:AD\Domain Users
ACL:AD\Administrator:ALLOWED/OI|CI/FULL
ACL:AD\Domain Users:ALLOWED/OI|CI/CHANGE
ACL:AD\Domain Guests:ALLOWED/OI|CI/0x00100021

コマンドの出力は以下のようになります。

REVISION - セキュリティー記述子の内部 Windows NT ACL リビジョン
CONTROL - セキュリティー記述子の制御
OWNER - セキュリティー記述子の所有者の名前または SID
GROUP - セキュリティー記述子のグループの名前または SID
ACL エントリー。詳細は「アクセス制御エントリー」を参照してください。

2.6.3.3. ACE マスク計算

ほとんどの場合、ACE を追加または更新する場合は、表2.4「既存の smbcacls エイリアスとそれに対応する Windows の権限」に記載されている smbcacls エイリアスを使用します。

ただし、表2.3「Windows の権限とそれに対応する smbcacls 値を 16 進法で設定」にあるように高度な Windows の権限を設定する場合は、ビット単位の OR 演算を使用して、正しい値を計算する必要があります。以下のシェルコマンドを使用して値を計算できます。

# echo $(printf '0x%X' $(( hex_value_1 | hex_value_2 | ... )))

例2.5 ACE マスクの計算

以下の権限を設定します。

フォルダーのスキャン / ファイルの実行 (0x00100020)
フォルダーの一覧表示 / データの読み取り (0x00100001)
属性の読み取り (0x00100080)

以前の権限の 16 進値を計算するには、以下を入力します。

# echo $(printf '0x%X' $(( 0x00100020 | 0x00100001 | 0x00100080 )))
0x1000A1

ACE を設定または更新する場合は、戻り値を使用します。

2.6.3.4. smbcacls を使用した ACL の追加、更新、および削除

smbcacls ユーティリティーに渡すパラメーターに応じて、ファイルまたはディレクトリーから ACL を追加、更新、および削除できます。

ACL の追加

このフォルダー、サブフォルダー、およびファイル の CHANGE 権限を AD\Domain Users グループに付与する //server/example 共有のルートに ACL を追加するには、以下のコマンドを実行します。

# smbcacls //server/example / -U "DOMAIN\administrator \
       --add ACL:"AD\Domain Users":ALLOWED/OI|CI/CHANGE

ACL の更新

ACL の更新は、新しい ACL の追加に似ています。ACL を更新する場合は、--modify パラメーターと既存のセキュリティープリンシパルを使用して ACL を上書きします。smbcacls が ACL 一覧内でセキュリティープリンシパルを検出すると、ユーティリティーは権限を更新します。これを行わないと、以下のエラーでコマンドが失敗します。

ACL for SID principal_name not found

たとえば、AD\Domain Users グループの権限を更新し、このフォルダー、サブフォルダー、およびファイル の READ に設定するには、以下のコマンドを実行します。

# smbcacls //server/example / -U "DOMAIN\administrator \
       --modify ACL:"AD\Domain Users":ALLOWED/OI|CI/READ

ACL の削除

ACL を削除するには、正確な ACL を持つ --delete パラメーターを smbcacls ユーティリティーに渡します。以下に例を示します。

# smbcacls //server/example / -U "DOMAIN\administrator \
       --delete ACL:"AD\Domain Users":ALLOWED/OI|CI/READ

2.6.5. 共有へのゲストアクセスの有効化

特定の状況では、認証なしでユーザーが接続できるディレクトリーを共有します。これを設定するには、共有でゲストアクセスを有効にします。

警告

共有に認証を使用しないと、セキュリティーリスクとなる場合があります。

共有でゲストアクセスが有効になっている場合、Samba はゲスト接続を、guest account パラメーターで設定したオペレーティングシステムアカウントにマッピングします。少なくとも以下のいずれかの条件が満たされると、ゲストユーザーはこの共有のファイルにアクセスできます。

アカウントがファイルシステムの ACL に一覧表示されます。
その他 のユーザーの POSIX 権限はこれを許可します。

例2.7 ゲスト共有の権限

ゲストアカウントを nobody (デフォルト) にマッピングするように Samba を設定している場合は、下記の例の ACL が、以下を行うようになります。

ゲストユーザーが file1.txt の読み込みを許可する
ゲストユーザーによる file2.txt の読み込みおよび修正を許可する
ゲストユーザーが file3.txt を読み込んだり修正しないようにする

-rw-r--r--. 1 root       root      1024 1. Sep 10:00 file1.txt
-rw-r-----. 1 nobody     root      1024 1. Sep 10:00 file2.txt
-rw-r-----. 1 root       root      1024 1. Sep 10:00 file3.txt

手順

/etc/samba/smb.conf ファイルを編集します。
1. これが、このサーバーで設定した最初のゲスト共有である場合は、以下を行います。
  1. [global] セクションに map to guest = Bad User を設定します。
    [global] ... map to guest = Bad User
    この設定により、ユーザー名が存在しない限り、Samba は間違ったパスワードを使用したログイン試行を拒否します。指定したユーザー名がなく、ゲストアクセスが共有で有効になっている場合、Samba は接続をゲストのログインとして処理します。
  2. デフォルトでは、Samba は、Red Hat Enterprise Linux の nobody アカウントにゲストアカウントをマッピングします。または、別のアカウントを設定することもできます。以下に例を示します。
    [global] ... guest account = user_name
    このパラメーターに設定するアカウントは、Samba サーバーにローカルに存在する必要があります。セキュリティー上の理由から、Red Hat は有効なシェルを割り当てていないアカウントを使用することを推奨しています。
2. guest ok = yes の設定を、[example] 共有セクションに追加します。
```
[example]
        ...
        guest ok = yes
```
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
Samba 設定を再読み込みします。
```
# smbcontrol all reload-config
```

2.7. プリントサーバーとしての Samba の設定

Samba をプリントサーバーとして設定すると、ネットワーク上のクライアントが Samba を使用して印刷できます。さらに、Windows クライアントは、(Samba サーバーが設定されている場合は) Samba サーバーからドライバーをダウンロードすることもできます。

このセクションの一部は、Samba Wiki に公開されているドキュメント「Setting up Samba as a Print Server」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。

2.7.1. 前提条件

Samba が、以下のいずれかのモードで設定されている。

スタンドアロンサーバー
ドメインメンバー

2.7.2. Samba の spoolssd サービス

Samba の spoolssd は、smbd サービスに統合されるサービスです。Samba 設定の spoolssd を有効にすると、大量のジョブまたはプリンターがあるプリントサーバーのパフォーマンスが大幅に向上します。

spoolssd がないと、Samba は smbd プロセスをフォークし、各プリントジョブの printcap キャッシュを初期化します。プリンターが多数あると、キャッシュの初期化中に smbd サービスが数秒間応答しなくなることがあります。spoolssd サービスを使用すると、遅延なしでプリントジョブを処理している、プレフォークされた smbd プロセスを開始することができます。主な spoolssd smbd プロセスは、少ないメモリーを使用し、子プロセスをフォークして終了します。

以下の手順では、spoolssd サービスを有効にする方法を説明します。

手順

/etc/samba/smb.conf ファイルの [global] セクションを編集します。

以下のパラメーターを追加します。

rpc_server:spoolss = external
rpc_daemon:spoolssd = fork

必要に応じて、以下のパラメーターを設定できます。

パラメーター	デフォルト	説明
`spoolssd:prefork_min_children`	5	子プロセスの最小数
`spoolssd:prefork_max_children`	25	子プロセスの最大数
`spoolssd:prefork_spawn_rate`	5	新しい接続が確立されると、Samba は、このパラメーターに設定した新しい子プロセスの数を、`spoolssd:prefork_max_children` に設定された値までフォークします。
`spoolssd:prefork_max_allowed_clients`	100	子プロセスが処理するクライアントの数
`spoolssd:prefork_child_min_life`	60	子プロセスの最小有効期間 (秒単位)。最小は 60 秒です。

/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
smb サービスを再起動します。
```
# systemctl restart smb
```
サービスを再起動すると、Samba が自動的に smbd 子プロセスを開始します。
```
# ps axf
...
30903 smbd
30912  \_ smbd
30913      \_ smbd
30914      \_ smbd
30915      \_ smbd
...
```

2.7.3. Samba でのプリントサーバーのサポートの有効化

本セクションでは、Samba でプリントサーバーのサポートを有効にする方法を説明します。

手順

Samba サーバーで CUPS を設定し、そのプリンターを CUPS バックエンドに追加します。CUPS でプリンターを設定する方法は、プリントサーバーの CUPS Web コンソール (https://print_server_host_name:631/help) で提供されているドキュメントを参照してください。
注記
Samba は、CUPS が Samba プリントサーバーにローカルにインストールされている場合に限り、CUPS に印刷ジョブを転送できます。
/etc/samba/smb.conf ファイルを編集します。
1. spoolssd サービスを有効にする場合は、以下のパラメーターを [global] セクションに追加します。
```
rpc_server:spoolss = external
rpc_daemon:spoolssd = fork
```
2. 印刷バックエンドを設定するには、[printers] セクションを追加します。
```
[printers]
        comment = All Printers
        path = /var/tmp/
        printable = yes
        create mask = 0600
```
  重要
  [printers] 共有名はハードコーディングされており、変更はできません。
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
firewall-cmd ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。
```
# firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload
```
smb サービスを再起動します。
```
# systemctl restart smb
```

サービスを再起動すると、Samba は CUPS バックエンドに設定したすべてのプリンターを自動的に共有します。特定のプリンターのみを手動で共有する場合は、「特定のプリンターの手動共有」を参照してください。

2.7.5. Windows クライアント用の自動プリンタードライバーダウンロードの設定

Windows クライアント用に Samba プリントサーバーを実行している場合は、ドライバーをアップロードし、プリンターを事前設定できます。ユーザーがプリンターに接続すると、Windows により、ドライバーが自動的にクライアントにダウンロードされ、インストールされます。ユーザーがインストールするのに、ローカル管理者の権限を必要としません。また、Windows は、トレイの数などの事前設定済みのドライバー設定を適用します。

このセクションの一部は、Samba Wiki で公開されているドキュメント「Setting up Automatic Printer Driver Downloads for Windows Clients」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。

前提条件

Samba がプリントサーバーとして設定されている。

2.7.5.1. プリンタードライバーに関する基本情報

本セクションでは、プリンタードライバーに関する一般的な情報を説明します。

対応しているドライバーモデルのバージョン

Samba は、Windows 2000 以降および Windows Server 2000 以降でサポートされているプリンタードライバーのモデルバージョン 3 のみに対応します。Samba は、Windows 8 および Windows Server 2012 で導入されたドライバーモデルのバージョン 4 には対応していません。ただし、これ以降の Windows バージョンは、バージョン 3 のドライバーにも対応しています。

パッケージ対応ドライバー

Samba は、パッケージ対応ドライバーに対応していません。

アップロードするプリンタードライバーの準備

Samba プリントサーバーにドライバーをアップロードする場合は、以下を行います。

ドライバーが圧縮形式で提供されている場合は、ドライバーを展開します。
一部のドライバーでは、Windows ホストにドライバーをローカルにインストールするセットアップアプリケーションを起動する必要があります。特定の状況では、インストーラーはセットアップの実行中にオペレーティングシステムの一時フォルダーに個別のファイルを抽出します。アップロードにドライバーファイルを使用するには、以下のコマンドを実行します。
1. インストーラーを起動します。
2. 一時フォルダーから新しい場所にファイルをコピーします。
3. インストールをキャンセルします。

プリントサーバーへのアップロードをサポートするドライバーは、プリンターの製造元にお問い合わせください。

クライアントに 32 ビットおよび 64 ビットのプリンター用ドライバーを提供

32 ビットと 64 ビットの両方の Windows クライアントのプリンターにドライバーを提供するには、両方のアーキテクチャーに対して、同じ名前のドライバーをアップロードする必要があります。たとえば、32 ビットのドライバー Example PostScript および 64 ビットのドライバー Example PostScript (v1.0) をアップロードする場合は、その名前が一致しません。その結果、ドライバーのいずれかをプリンターに割り当てることしかできなくなり、両方のアーキテクチャーでそのドライバーが使用できなくなります。

2.7.5.2. ユーザーがドライバーをアップロードおよび事前設定できるようにする

プリンタードライバーをアップロードおよび事前設定できるようにするには、ユーザーまたはグループに SePrintOperatorPrivilege 特権が付与されている必要があります。printadmin グループにユーザーを追加する必要があります。Red Hat Enterprise Linux に samba パッケージをインストールすると、このグループが自動的に作成されます。printadmin グループには、1000 未満で利用可能な一番小さい動的システムの GID が割り当てられます。

手順

たとえば、SePrintOperatorPrivilege 権限を printadmin グループに付与するには、以下のコマンドを実行します。
```
# net rpc rights grant "printadmin" SePrintOperatorPrivilege \
       -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully granted rights.
```
注記
ドメイン環境では、SePrintOperatorPrivilege をドメイングループに付与します。これにより、ユーザーのグループメンバーシップを更新し、権限を集中的に管理できます。

SePrintOperatorPrivilege が付与されているユーザーとグループの一覧を表示するには、以下を実行します。

# net rpc rights list privileges SePrintOperatorPrivilege \
       -U "DOMAIN\administrator"
Enter administrator's password:
SePrintOperatorPrivilege:
  BUILTIN\Administrators
  DOMAIN\printadmin

2.7.5.3. print$ 共有の設定

Windows のオペレーティングシステムは、プリントサーバーの共有 print$ から、プリンタードライバーをダウンロードします。この共有名は Windows でハードコーディングされており、変更はできません。

以下の手順は、/var/lib/samba/drivers/ ディレクトリーを print$ として共有し、ローカルの printadmin グループのメンバーがプリンタードライバーをアップロードすることを有効にする方法を説明します。

手順

[print$] セクションを /etc/samba/smb.conf ファイルに追加します。
```
[print$]
        path = /var/lib/samba/drivers/
        read only = no
        write list = @printadmin
        force group = @printadmin
        create mask = 0664
        directory mask = 2775
```
以下の設定を使用します。
printadmin グループのメンバーだけがプリンタードライバーを共有にアップロードできます。
- 新規に作成されたファイルおよびディレクトリーのグループは printadmin に設定されます。
- 新規ファイルの権限は 664に設定されます。
- 新しいディレクトリーの権限は、2775 に設定されます。
プリンターの 64 ビットドライバーのみをアップロードするには、/etc/samba/smb.conf ファイルの [global] セクションにこの設定を含めます。
```
spoolss: architecture = Windows x64
```
この設定がないと、少なくとも 32 ビットバージョンでアップロードしたドライバーのみが表示されます。
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
Samba 設定を再読み込みします。
```
# smbcontrol all reload-config
```
printadmin グループが存在しない場合は作成します。
```
# groupadd printadmin
```

SePrintOperatorPrivilege 権限を、printadmin グループに付与します。

# net rpc rights grant "printadmin" SePrintOperatorPrivilege \
       -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully granted rights.

SELinux を、enforcing モードで実行する場合は、そのディレクトリーに samba_share_t コンテキストを設定します。
```
# semanage fcontext -a -t samba_share_t "/var/lib/samba/drivers(/.*)?"
# restorecon -Rv /var/lib/samba/drivers/
```

/var/lib/samba/drivers/ ディレクトリーに権限を設定します。

POSIX ACL を使用する場合は、以下を設定します。

# chgrp -R "printadmin" /var/lib/samba/drivers/
# chmod -R 2775 /var/lib/samba/drivers/

Windows ACL を使用する場合は、以下を設定します。

プリンシパル	アクセス	適用先
`CREATOR OWNER`	完全な制御	サブフォルダーおよびファイルのみ
`認証されたユーザー`	読み取りおよび実行、フォルダーのコンテンツの一覧表示、読み取り	このフォルダー、サブフォルダー、およびファイル
`printadmin`	完全な制御	このフォルダー、サブフォルダー、およびファイル

Windows での ACL の設定に関する詳細は、Windows のドキュメントを参照してください。

2.7.5.4. クライアントが Samba プリントサーバーを信頼できるようにする GPO の作成

セキュリティー上の理由から、最新の Windows オペレーティングシステムでは、クライアントが、信頼できないサーバーから、パッケージ対応ではないプリンタードライバーをダウンロードできないようにします。プリントサーバーが AD のメンバーである場合は、Samba サーバーを信頼するために、ドメインに Group Policy Object (GPO) を作成できます。

前提条件

Samba プリントサーバーが、AD ドメインのメンバーである。
GPO の作成に使用する Windows コンピューターに、RSAT (Windows Remote Server Administration Tools) がインストールされている。詳細は、Windows のドキュメントを参照してください。

手順

AD ドメインの 管理者 ユーザーなど、グループポリシーの編集が可能なアカウントを使用して、Windows コンピューターにログインします。
Group Policy Management Console を開きます。
AD ドメインを右クリックし、Create a GPO in this domain, and Link it here を選択します。
Legacy Printer Driver Policy などの GPO の名前を入力して、OK をクリックします。新しい GPO がドメインエントリーの下に表示されます。
新たに作成した GPO を右クリックして Edit を選択し、Group Policy Management Editor を開きます。
Computer Configuration → Policies → Administrative Templates → Printers の順にクリックします。
ウィンドウの右側で、Point and Print Restriction をダブルクリックして、ポリシーを編集します。
1. ポリシーを有効にし、以下のオプションを設定します。
  1. Users can only point and print to these servers を選択し、このオプションの横にあるフィールドに、Samba プリントサーバーの完全修飾ドメイン名 (FQDN) を入力します。
  2. Security Prompts の両チェックボックスで、Do not show warning or elevation prompt を選択します。
2. OK をクリックします。
Package Point and Print - Approved servers をダブルクリックして、ポリシーを編集します。
1. ポリシーを有効にして、Show ボタンをクリックします。
2. Samba プリントサーバーの FQDN を入力します。
3. OKをクリックして、Show Contents ウィンドウとポリシーのプロパティーウィンドウの両方を閉じます。
Group Policy Management Editor を閉じます。
Group Policy Management Console を閉じます。

Windows ドメインメンバーがこのグループポリシーを適用すると、ユーザーがプリンターに接続する際に、プリンタードライバーが Samba サーバーから自動的にダウンロードされます。

2.7.5.5. ドライバーのアップロードおよびプリンターの事前設定

Windows クライアントで Print Management アプリケーションを使用してドライバーをアップロードし、Samba プリントサーバーでホストされるプリンターを事前設定します。詳細は、Windows のドキュメントを参照してください。

2.8. Samba サーバーのパフォーマンスチューニング

本章では、特定の状況で Samba のパフォーマンスを改善できる設定と、パフォーマンスが低下する可能性のある設定を説明します。

このセクションの一部は、Samba Wiki に公開されているドキュメント「Performance Tuning」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。

前提条件

Samba が、ファイルサーバーまたはプリントサーバーとして設定されている。

2.8.1. SMB プロトコルバージョンの設定

新しい SMB バージョンごとに機能が追加され、プロトコルのパフォーマンスが向上します。最新の Windows および Windows Server オペレーティングシステムは、常に最新のプロトコルバージョンに対応しています。Samba がプロトコルの最新バージョンも使用している場合は、Samba に接続する Windows クライアントで、このパフォーマンス改善を活用できます。Samba では、server max protocol のデフォルト値が、対応している安定した SMB プロトコルの最新バージョンに設定されます。

注記

常に最新の安定した SMB プロトコルバージョンを有効にするには、server max protocol パラメーターを設定しないでください。このパラメーターを手動で設定する場合は、最新のプロトコルバージョンを有効にするために、それぞれ新しいバージョンの SMB プロトコルで設定を変更する必要があります。

次の手順では、server max protocol パラメーターでデフォルト値を使用する方法を説明します。

手順

/etc/samba/smb.conf ファイルの [global] セクションから server max protocol パラメーターを削除します。
Samba 設定を再読み込みします。
```
# smbcontrol all reload-config
```

2.8.2. 大量のファイルを含むディレクトリーとの共有の調整

Linux は、大文字と小文字を区別するファイル名に対応しています。このため、Samba はファイルの検索時またはアクセス時に、大文字と小文字のファイル名のディレクトリーをスキャンする必要があります。小文字または大文字のいずれかでのみ新しいファイルを作成するように共有を設定すると、パフォーマンスが向上します。

前提条件

Samba が、ファイルサーバーとして設定されている。

手順

共有の全ファイルの名前を小文字に変更します。
注記
この手順の設定を使用すると、小文字以外の名前が付けられたファイルは表示されなくなります。
共有のセクションに以下のパラメーターを設定します。
```
case sensitive = true
default case = lower
preserve case = no
short preserve case = no
```
パラメーターの詳細は、man ページの smb.conf(5) を参照してください。
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
Samba 設定を再読み込みします。
```
# smbcontrol all reload-config
```

これらの設定を適用すると、この共有に新しく作成されるすべてのファイルの名前が小文字になります。この設定により、Samba はディレクトリーを大文字と小文字で分けたスキャンが不要になり、パフォーマンスが向上します。

2.8.3. パフォーマンスが低下する可能性のある設定

デフォルトでは、Red Hat Enterprise Linux のカーネルは、ネットワークパフォーマンスを高めるように調整されています。たとえば、カーネルはバッファーサイズに自動チューニングメカニズムを使用しています。/etc/samba/smb.conf ファイルで socket options パラメーターを設定すると、これらのカーネル設定が上書きされます。結果として、このパラメーターの設定により、ほとんどの場合は、Samba ネットワークのパフォーマンスが低下します。

カーネルの最適化された設定を使用するには、/etc/samba/smb.conf の [global] セクションから socket options パラメーターを削除します。

2.9. 頻繁に使用される Samba コマンドラインユーティリティー

本章では、Samba サーバーで作業する場合によく使用されるコマンドを説明します。

2.9.1. net ユーティリティーの使用

net ユーティリティーを使用すると、Samba サーバーで複数の管理タスクを実行できます。本セクションでは、net ユーティリティーで最も頻繁に使用されるサブコマンドを説明します。

前提条件

samba-common-tools パッケージがインストールされている。

2.9.1.1. net ads join コマンドおよび net rpc join コマンドの使用

net ユーティリティーの join サブコマンドを使用すると、Samba を AD ドメインまたは NT4 ドメインに参加させることができます。ドメインに参加するには、/etc/samba/smb.conf ファイルを手動で作成し、必要に応じて PAM などの追加設定を更新する必要があります。

重要

Red Hat は、realm ユーティリティーを使用してドメインに参加させることを推奨します。realm ユーティリティーは、関連するすべての設定ファイルを自動的に更新します。詳細は「Samba のドメインへの参加」を参照してください。

手順

以下の設定で /etc/samba/smb.conf ファイルを手動で作成します。

AD ドメインメンバーの場合:

[global]
workgroup = domain_name
security = ads
passdb backend = tdbsam
realm = AD_REALM

NT4 ドメインメンバーの場合:

[global]
workgroup = domain_name
security = user
passdb backend = tdbsam

/etc/samba/smb.conf ファイルの [global] セクションに、* デフォルトドメインおよび参加するドメイン用の ID マッピング設定を追加します。詳細は「Samba ID マッピング」を参照してください。
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
ドメイン管理者としてドメインに参加します。
- AD ドメインに参加するには、以下のコマンドを実行します。
```
# net ads join -U "DOMAIN\administrator"
```
- NT4 ドメインに参加するには、以下のコマンドを実行します。
```
# net rpc join -U "DOMAIN\administrator"
```
/etc/nsswitch.conf ファイルのデータベースエントリー passwd および group に winbind ソースを追加します。
```
passwd:     files winbind
group:      files winbind
```
winbind サービスを有効にして起動します。
```
# systemctl enable winbind
# systemctl start winbind
```
必要に応じて、authselect ユーティリティーを使用して PAM を設定します。
詳細は、man ページの authselect(8) を参照してください。
AD 環境では、必要に応じて Kerberos クライアントを設定します。
詳細は、Kerberos クライアントのドキュメントを参照してください。

2.9.1.2. net rpc rights コマンドの使用

Windows では、アカウントおよびグループに特権を割り当て、共有での ACL の設定やプリンタードライバーのアップロードなどの特別な操作を実行できます。Samba サーバーでは、net rpc rights コマンドを使用して権限を管理できます。

設定可能な権限の一覧表示

利用可能な特権とその所有者をすべて表示するには、net rpc rights list コマンドを使用します。以下に例を示します。

net rpc rights list -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
     SeMachineAccountPrivilege  Add machines to domain
      SeTakeOwnershipPrivilege  Take ownership of files or other objects
             SeBackupPrivilege  Back up files and directories
            SeRestorePrivilege  Restore files and directories
     SeRemoteShutdownPrivilege  Force shutdown from a remote system
      SePrintOperatorPrivilege  Manage printers
           SeAddUsersPrivilege  Add users and groups to the domain
       SeDiskOperatorPrivilege  Manage disk shares
           SeSecurityPrivilege  System security

特権の付与

アカウントまたはグループへの特権を付与するには、net rpc rights grant コマンドを使用します。

たとえば、SePrintOperatorPrivilege 権限を、DOMAIN\printadmin グループに付与します。

# net rpc rights grant "DOMAIN\printadmin" SePrintOperatorPrivilege \
       -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully granted rights.

特権の取り消し

アカウントまたはグループから特権を取り消すには、net rpc rights revoke コマンドを使用します。

たとえば、DOMAIN\printadmin グループから SePrintOperatorPrivilege 権限を取り消すには、以下のコマンドを実行します。

# net rpc rights remoke "DOMAIN\printadmin" SePrintOperatorPrivilege \
       -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully revoked rights.

2.9.1.3. net rpc share コマンドの使用

net rpc share コマンドは、ローカルまたはリモートの Samba または Windows サーバーの共有の一覧表示、追加、および削除を行う機能を提供します。

共有の一覧表示

SMB サーバーの共有を一覧表示するには、net rpc share list コマンドを使用します。必要に応じて、-S server_name パラメーターをコマンドに渡して、リモートサーバーの共有を一覧表示します。以下に例を示します。

# net rpc share list -U "DOMAIN\administrator" -S server_name
Enter DOMAIN\administrator's password:
IPC$
share_1
share_2
...

注記

/etc/samba/smb.conf ファイルのセクション内に browseable = no が設定されている Samba サーバーでホストされている共有は、出力には表示されません。

共有の追加

net rpc share add コマンドを使用すると、SMB サーバーに共有を追加できます。

たとえば、C:\example\ ディレクトリーを共有するリモートの Windows サーバーに、共有 example を追加するには、以下のコマンドを実行します。

# net rpc share add example="C:\example" -U "DOMAIN\administrator" -S server_name

注記

Windows のディレクトリー名を指定する際は、パスの末尾のバックスラッシュを省略する必要があります。

このコマンドを使用して Samba サーバーに共有を追加するには、以下を行います。

-U パラメーターで指定したユーザーは、出力先サーバーで SeDiskOperatorPrivilege 特権が付与されている必要があります。
共有セクションを、/etc/samba/smb.conf ファイルに追加し、Samba を再読み込みするスクリプトを記述する必要があります。スクリプトは、/etc/samba/smb.conf の [global] セクションの add share command パラメーターで設定する必要があります。詳細は、man ページの smb.conf(5) の add share コマンド の説明を参照してください。

共有の削除

net rpc share delete コマンドを使用すると、SMB サーバーから共有を削除できます。

たとえば、example という名前の共有を、リモートの Windows サーバーから削除するには、以下のコマンドを実行します。

# net rpc share delete example -U "DOMAIN\administrator" -S server_name

このコマンドを使用して Samba サーバーから共有を削除するには、以下のコマンドを実行します。

-U パラメーターで指定したユーザーは、SeDiskOperatorPrivilege 特権が付与されている必要があります。
/etc/samba/smb.conf ファイルから共有のセクションを削除し、Samba を再読み込みするスクリプトを記述する必要があります。スクリプトは、/etc/samba/smb.conf の [global] セクションの delete share command パラメーターで設定する必要があります。詳細は、man ページの smb.conf(5) の delete share コマンド の説明を参照してください。

2.9.1.4. net user コマンドの使用

net user コマンドを使用すると、AD DC または NT4 PDC で以下の操作を実行できます。

すべてのユーザーアカウントの一覧を表示
ユーザーの追加
ユーザーの削除

注記

AD ドメイン用の ads、NT4 ドメイン用の rpc などの接続方法の指定は、ドメインユーザーアカウントを一覧表示する場合にのみ必要です。その他のユーザー関連のサブコマンドは、接続メソッドを自動検出できます。

-U user_name パラメーターをコマンドに渡して、要求されたアクションを実行できるユーザーを指定します。

ドメインユーザーアカウントの一覧表示

AD ドメイン内のユーザーを一覧表示するには、以下を実行します。

# net ads user -U "DOMAIN\administrator"

NT4 ドメインのユーザーを一覧表示するには、以下を実行します。

# net rpc user -U "DOMAIN\administrator"

ユーザーアカウントのドメインへの追加

Samba ドメインメンバーの場合は、net user add コマンドを使用して、ユーザーアカウントをドメインに追加できます。

たとえば、user アカウントをドメインに追加します。

以下のアカウントを追加します。

# net user add user password -U "DOMAIN\administrator"
User user added

必要に応じて、リモートプロシージャコール (RPC) シェルを使用して、AD DC または NT4 PDC でアカウントを有効にします。以下に例を示します。

# net rpc shell -U DOMAIN\administrator -S DC_or_PDC_name
Talking to domain DOMAIN (S-1-5-21-1424831554-512457234-5642315751)

net rpc> user edit disabled user: no
Set user's disabled flag from [yes] to [no]

net rpc> exit

ドメインからのユーザーアカウントの削除

Samba ドメインメンバーの場合は、net user delete コマンドを使用して、ドメインからユーザーアカウントを削除できます。

たとえば、ドメインから user アカウントを削除するには、以下のコマンドを実行します。

# net user delete user -U "DOMAIN\administrator"
User user deleted

2.9.1.5. net usershare コマンドの使用

Samba サーバーでは、root 権限なしでユーザーがディレクトリーを共有できるように設定できます。

2.9.1.5.1. ユーザーの共有機能の有効化

ユーザーがディレクトリーを共有できるようにするには、管理者が Samba でユーザー共有を有効にする必要があります。

たとえば、ローカルの example グループのメンバーのみがユーザー共有を作成できるようにするには、以下を実行します。

手順

ローカルの example グループが存在しない場合は作成します。
```
# groupadd example
```
ユーザー共有の定義を保存し、その権限を正しく設定するために、Samba 用のディレクトリーを準備します。以下に例を示します。
1. ディレクトリーを作成します。
```
# mkdir -p /var/lib/samba/usershares/
```
2. example グループの書き込み権限を設定します。
```
# chgrp example /var/lib/samba/usershares/
# chmod 1770 /var/lib/samba/usershares/
```
3. このディレクトリーの他のユーザーが保存したファイルの名前変更や削除を禁止するように sticky ビットを設定します。
/etc/samba/smb.conf ファイルを編集し、以下を [global] セクションに追加します。
1. ユーザー共有の定義を保存するように設定したディレクトリーのパスを設定します。以下に例を示します。
```
usershare path = /var/lib/samba/usershares/
```
2. このサーバーで Samba を作成できるユーザー共有の数を設定します。以下に例を示します。
```
usershare max shares = 100
```
  usershare max shares パラメーターにデフォルトの 0 を使用すると、ユーザー共有が無効になります。
3. 必要に応じて、ディレクトリーの絶対パスの一覧を設定します。たとえば、Samba が/data ディレクトリーおよび /srv ディレクトリーのサブディレクトリーの共有のみを許可するように設定するには、以下を設定します。
```
usershare prefix allow list = /data /srv
```
設定可能なユーザー共有関連のパラメーターの一覧は、man ページの smb.conf(5) の USERSHARES セクションを参照してください。
/etc/samba/smb.conf ファイルを検証します。
```
# testparm
```
Samba 設定を再読み込みします。
```
# smbcontrol all reload-config
```

これで、ユーザーが、ユーザー共有を作成できるようになりました。詳細は「ユーザー共有の追加」を参照してください。

2.9.1.5.2. ユーザー共有の追加

「ユーザーの共有機能の有効化」に従って Samba を設定したら、ユーザーは root 権限がなくても、net usershare add コマンドを実行して Samba サーバーのディレクトリーを共有できます。

net usershare add コマンドの構文:

net usershare add share_name path [[ comment ] | [ ACLs ]] [ guest_ok=y|n ]

重要

ユーザー共有の作成時に ACL を設定する場合は、ACL の前に comment パラメーターを指定する必要があります。空のコメントを設定するには、空の文字列を二重引用符で囲みます。

管理者が、/etc/samba/smb.conf ファイルの [global] セクションで usershare allow guests = yes に設定すると、ユーザーはユーザー共有上でのみゲストアクセスを有効にできることに注意してください。

例2.8 ユーザー共有の追加

ユーザーが、Samba サーバーで /srv/samba/ ディレクトリーを共有する場合があります。共有には、example という名前を付け、コメントを設定しないようにし、ゲストユーザーがアクセスできるようにします。また、共有権限は、AD\Domain Users グループへのフルアクセスと、その他のユーザーへの読み取り権限を設定する必要があります。この共有を追加するには、そのユーザーで以下を実行します。

$ net usershare add example /srv/samba/ "" \
       "AD\Domain Users":F,Everyone:R guest_ok=yes

2.9.1.5.3. ユーザー共有の設定の更新

ユーザー共有の設定を更新するには、同じ共有名と新しい設定で net usershare add コマンドを使用して共有を上書きします。「ユーザー共有の追加」を参照してください。

2.9.1.5.4. 既存のユーザー共有に関する情報の表示

ユーザーは、Samba サーバーで net usershare info コマンドを実行して、ユーザーの共有および設定を表示できます。

前提条件

ユーザー共有が Samba サーバーに設定されている。

手順

任意のユーザーが作成したすべてのユーザー共有を表示するには、以下のコマンドを実行します。
```
$ net usershare info -l
[share_1]
path=/srv/samba/
comment=
usershare_acl=Everyone:R,host_name\user:F,
guest_ok=y
...
```
コマンドを実行するユーザーが作成した共有のみを一覧表示するには、-l パラメーターを省略します。
特定の共有に関する情報のみを表示するには、共有名またはワイルドカードをコマンドに渡します。たとえば、名前が share_ で始まる共有の情報を表示する場合は、以下のコマンドを実行します。
```
$ net usershare info -l share_*
```

2.9.1.5.5. ユーザー共有の一覧表示

Samba サーバーで設定を行わずに利用可能なユーザー共有のみを一覧表示するには、net usershare list コマンドを使用します。

前提条件

ユーザー共有が Samba サーバーに設定されている。

手順

任意のユーザーが作成した共有を一覧表示するには、以下のコマンドを実行します。
```
$ net usershare list -l
share_1
share_2
...
```
コマンドを実行するユーザーが作成した共有のみを一覧表示するには、-l パラメーターを省略します。
特定の共有のみを一覧表示するには、共有名またはワイルドカードをコマンドに渡します。たとえば、名前が share_ で始まる共有のみを一覧表示するには、以下のコマンドを実行します。
```
$ net usershare list -l share_*
```

2.9.1.5.6. ユーザー共有の削除

ユーザー共有を削除するには、共有を作成したユーザーまたは root ユーザーで、net usershare delete コマンドを実行します。

前提条件

ユーザー共有が Samba サーバーに設定されている。

手順

$ net usershare delete share_name

2.9.2. rpcclient ユーティリティーの使用

rpcclient ユーティリティーを使用すると、ローカルまたはリモートの SMB サーバーでクライアント側の Microsoft Remote Procedure Call (MS-RPC) 機能を手動で実行できます。ただし、ほとんどの機能は、Samba が提供する個別のユーティリティーに統合されています。rpcclient は、MS-PRC 関数のテストにのみ使用します。

前提条件

samba-client パッケージがインストールされている。

例

たとえば、rpcclient ユーティリティーを使用して以下を行うことができます。

プリンターのスプールサブシステム (SPOOLSS) を管理します。

例2.9 プリンターへのドライバーの割り当て

# rpcclient server_name -U "DOMAIN\administrator" \
       -c 'setdriver "printer_name" "driver_name"'
Enter DOMAIN\administrators password:
Successfully set printer_name to driver driver_name.

SMB サーバーに関する情報を取得します。

例2.10 すべてのファイル共有および共有プリンターの一覧表示

# rpcclient server_name -U "DOMAIN\administrator" -c 'netshareenum'
Enter DOMAIN\administrators password:
netname: Example_Share
	remark:
	path:   C:\srv\samba\example_share\
	password:
netname: Example_Printer
	remark:
	path:   C:\var\spool\samba\
	password:

Security Account Manager Remote (SAMR) プロトコルを使用して操作を実行します。
例2.11 SMB サーバー上のユーザーの一覧表示
```
# rpcclient server_name -U "DOMAIN\administrator" -c 'enumdomusers'
Enter DOMAIN\administrators password:
user:[user1] rid:[0x3e8]
user:[user2] rid:[0x3e9]
```
スタンドアロンサーバーまたはドメインメンバーに対してコマンドを実行すると、ローカルデータベースのユーザーの一覧が表示されます。ADDC または NT4 PDC に対してコマンドを実行すると、ドメインユーザーの一覧が表示されます。

2.9.3. samba-regedit アプリケーションの使用

プリンター設定などの特定の設定は、Samba サーバーのレジストリーに保存されます。ncurses ベースの samba-regedit アプリケーションを使用して、Samba サーバーのレジストリーを編集できます。

Samba regedit

前提条件

samba-client パッケージがインストールされている。

手順

アプリケーションを起動するには、次のコマンドを入力します。

# samba-regedit

次のキーを使用します。

カーソルを上下に動かして、レジストリーツリーと値の間を移動します。
Enter - キーを開くか、値を編集します。
Tab - Key ペインと Value ペインを切り替えます。
Ctrl+C - アプリケーションを閉じます。

2.9.4. smbcacls ユーティリティーの使用

高度な Windows ACL または POSIX ACL を使用するローカルまたはリモートの Samba サーバー
Red Hat Enterprise Linux で、Windows でホストされる共有の ACL をリモートで管理

2.9.4.1. アクセス制御エントリー

ファイルシステムオブジェクトの各 ACL エントリーには、以下の形式のアクセス制御エントリー (ACE) が含まれます。

security_principal:access_right/inheritance_information/permissions

例2.12 アクセス制御エントリー

AD\Domain Users:ALLOWED/OI|CI/CHANGE

ACE には、以下が含まれます。

セキュリティープリンシパル

セキュリティープリンシパルは、ACL の権限が適用されるユーザー、グループ、または SID です。

アクセス権

オブジェクトへのアクセスが許可または拒否されるかどうかを定義します。値は ALLOWED または DENIED です。

継承情報

次の値を取ります。

表2.5 継承の設定

値	説明	マップ先
`OI`	オブジェクトの継承	このフォルダーおよびファイル
`CI`	コンテナーの継承	このフォルダーおよびサブフォルダー
`IO`	継承のみ	ACE は、現在のファイルまたはディレクトリーには適用されません。
`ID`	継承済	親ディレクトリーから ACE が継承されました。

また、値は以下のように組み合わせることができます。

表2.6 継承設定の組み合わせ

値の組み合わせ	Windows の `適用先` 設定にマップします。
`OI\|CI`	このフォルダー、サブフォルダー、およびファイル
`OI\|CI\|IO`	サブフォルダーおよびファイルのみ
`CI\|IO`	サブディレクトリーのみ
`OI\|IO`	ファイルのみ

権限

この値は、Windows の権限または smbcacls エイリアスを表す 16 進値になります。

1 つ以上の Windows の権限を表す 16 進値。

次の表に、Windows の高度な権限とそれに対応する値を 16 進法で表示します。

表2.7 Windows の権限とそれに対応する smbcacls 値を 16 進法で設定

Windows の権限	16 進値
完全な制御	`0x001F01FF`
フォルダーのスキャンおよびファイルの実行	`0x00100020`
フォルダーの一覧表示 / データの読み取り	`0x00100001`
属性の読み取り	`0x00100080`
拡張属性の読み取り	`0x00100008`
ファイルの作成/データの書き込み	`0x00100002`
フォルダーの作成/データの追加	`0x00100004`
属性の書き込み	`0x00100100`
拡張属性の書き込み	`0x00100010`
サブフォルダーおよびファイルの削除	`0x00100040`
削除	`0x00110000`
権限の読み取り	`0x00120000`
権限の変更	`0x00140000`
所有権の取得	`0x00180000`

smbcacls エイリアス。以下の表には、利用可能なエイリアスが表示されます。

表2.8 既存の smbcacls エイリアスとそれに対応する Windows の権限

`smbcacls` エイリアス	Windows の権限へのマッピング
`-R`	読み取り
`READ`	読み取りおよび実行
`W`	主な機能: ファイルの作成/データの書き込みフォルダーの作成/データの追加属性の書き込み拡張属性の書き込み権限の読み取り
`D`	削除
`%P`	権限の変更
`O`	所有権の取得
`X`	スキャン / 実行
`CHANGE`	修正
`FULL`	完全な制御

注記

2.9.4.2. smbcacls を使用した ACL の表示

手順

たとえば、//server/example 共有のルートディレクトリーの ACL を一覧表示するには、以下のコマンドを実行します。

# smbcacls //server/example / -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
REVISION:1
CONTROL:SR|PD|DI|DP
OWNER:AD\Administrators
GROUP:AD\Domain Users
ACL:AD\Administrator:ALLOWED/OI|CI/FULL
ACL:AD\Domain Users:ALLOWED/OI|CI/CHANGE
ACL:AD\Domain Guests:ALLOWED/OI|CI/0x00100021

コマンドの出力は以下のようになります。

REVISION - セキュリティー記述子の内部 Windows NT ACL リビジョン
CONTROL - セキュリティー記述子の制御
OWNER - セキュリティー記述子の所有者の名前または SID
GROUP - セキュリティー記述子のグループの名前または SID
ACL エントリー。詳細は「アクセス制御エントリー」を参照してください。

2.9.4.3. ACE マスク計算

# echo $(printf '0x%X' $(( hex_value_1 | hex_value_2 | ... )))

例2.13 ACE マスクの計算

以下の権限を設定します。

フォルダーのスキャン / ファイルの実行 (0x00100020)
フォルダーの一覧表示 / データの読み取り (0x00100001)
属性の読み取り (0x00100080)

以前の権限の 16 進値を計算するには、以下を入力します。

# echo $(printf '0x%X' $(( 0x00100020 | 0x00100001 | 0x00100080 )))
0x1000A1

ACE を設定または更新する場合は、戻り値を使用します。

2.9.4.4. smbcacls を使用した ACL の追加、更新、および削除

smbcacls ユーティリティーに渡すパラメーターに応じて、ファイルまたはディレクトリーから ACL を追加、更新、および削除できます。

ACL の追加

# smbcacls //server/example / -U "DOMAIN\administrator \
       --add ACL:"AD\Domain Users":ALLOWED/OI|CI/CHANGE

ACL の更新

ACL for SID principal_name not found

# smbcacls //server/example / -U "DOMAIN\administrator \
       --modify ACL:"AD\Domain Users":ALLOWED/OI|CI/READ

ACL の削除

ACL を削除するには、正確な ACL を持つ --delete パラメーターを smbcacls ユーティリティーに渡します。以下に例を示します。

# smbcacls //server/example / -U "DOMAIN\administrator \
       --delete ACL:"AD\Domain Users":ALLOWED/OI|CI/READ

2.9.5. smbclient ユーティリティーの使用

smbclient ユーティリティーを使用すると、コマンドラインの FTP クライアントと同様に、SMB サーバーのファイル共有にアクセスできます。たとえば、ファイルを共有にアップロードしたり、共有からダウンロードしたりできます。

2.9.5.1. 前提条件

samba-client パッケージがインストールされている。

2.9.5.2. smbclient 対話モードの動作

たとえば、DOMAIN\user アカウントを使用して サーバー でホストされる example 共有に認証するには、以下のコマンドを実行します。

# smbclient -U "DOMAIN\user" //server/example
Enter domain\user's password:
Try "help" to get a list of possible commands.
smb: \>

smbclient が共有に正常に接続すると、ユーティリティーはインタラクティブモードになり、以下のプロンプトが表示されます。

smb: \>

対話式シェルで利用可能なすべてのコマンドを表示するには、以下のコマンドを実行します。

smb: \> help

特定のコマンドのヘルプを表示するには、以下のコマンドを実行します。

smb: \> help command_name

2.9.5.3. 対話モードでの smbclient の使用

-c パラメーターを指定せずに smbclient を使用すると、ユーティリティーは対話モードを開始します。以下の手順では、SMB 共有に接続し、サブディレクトリーからファイルをダウンロードする方法を説明します。

手順

共有に接続します。

# smbclient -U "DOMAIN\user_name" //server_name/share_name

/example/ ディレクトリーに移動します。
```
smb: \> cd /example/
```

ディレクトリー内のファイルを一覧表示します。

smb: \example\> ls
  .                    D         0  Thu Nov 1 10:00:00 2018
  ..                   D         0  Thu Nov 1 10:00:00 2018
  example.txt          N   1048576  Thu Nov 1 10:00:00 2018

         9950208 blocks of size 1024. 8247144 blocks available

example.txt ファイルをダウンロードします。

smb: \example\> get example.txt
getting file \directory\subdirectory\example.txt of size 1048576 as example.txt (511975,0 KiloBytes/sec) (average 170666,7 KiloBytes/sec)

共有から切断します。
```
smb: \example\> exit
```

2.9.5.4. スクリプトモードでの smbclient の使用

-c パラメーターを smbclient に渡すと、リモートの SMB 共有でコマンドを自動的に実行できます。これにより、スクリプトで smbclient を使用できます。

以下の手順では、SMB 共有に接続し、サブディレクトリーからファイルをダウンロードする方法を説明します。

手順

# smbclient -U DOMAIN\user_name //server_name/share_name \
       -c "cd /example/ ; get example.txt ; exit"

2.9.6. smbcontrol ユーティリティーの使用

smbcontrol ユーティリティーを使用すると、smbd、nmbd、winbindd、またはこのすべてのサービスにコマンドメッセージを送信できます。この制御メッセージは、設定の再読み込みなどのサービスを指示します。

本セクションの手順では、reload-config メッセージタイプを すべて の宛先に送信することで、smbd、nmbd、winbindd のサービスの設定を再読み込みする方法を示します。

前提条件

samba-common-tools パッケージがインストールされている。

手順

# smbcontrol all reload-config

2.9.7. smbpasswd ユーティリティーの使用

smbpasswd ユーティリティーは、ローカルの Samba データベースでユーザーアカウントおよびパスワードを管理します。

前提条件

samba-common-tools パッケージがインストールされている。

手順

ユーザーとしてコマンドを実行すると、smbpasswd はコマンドを実行するユーザーの Samba パスワードを変更します。以下に例を示します。
```
[user@server ~]$ smbpasswd
New SMB password: password
Retype new SMB password: password
```
root で smbpasswd を実行すると、たとえば以下のようにユーティリティーを使用できます。
- 新しいユーザーを作成します。
```
[root@server ~]# smbpasswd -a user_name
New SMB password: password
Retype new SMB password: password
Added user user_name.
```
  注記
  Samba データベースにユーザーを追加する前に、ローカルのオペレーティングシステムにアカウントを作成する必要があります。『Configuring and managing system administration』の「新しいユーザーの追加」セクションを参照してください。
- Samba ユーザーを有効にします。
```
[root@server ~]# smbpasswd -e user_name
Enabled user user_name.
```
- Samba ユーザーを無効にします。
```
[root@server ~]# smbpasswd -x user_name
Disabled user ser_name
```
- ユーザーを削除します。
```
[root@server ~]# smbpasswd -x user_name
Deleted user user_name.
```

2.9.8. smbstatus ユーティリティーの使用

smbstatus ユーティリティーは以下について報告します。

各 smbd デーモンの PID ごとの接続を Samba サーバーに接続します。このレポートには、ユーザー名、プライマリグループ、SMB プロトコルのバージョン、暗号、および署名の情報が含まれます。
Samba 共有ごとの接続このレポートには、smbd デーモンの PID、接続しているマシンの IP、接続が確立された時点のタイムスタンプ、暗号、および署名情報が含まれます。
ロックされたファイルの一覧。レポートエントリーには、日和見ロック (oplock) タイプなどの詳細が含まれます。

前提条件

samba パッケージがインストールされている。
smbd サービスが実行している。

手順

# smbstatus

Samba version 4.7.1
PID  Username              Group                Machine                            Protocol Version  Encryption  Signing
-----------------------------------------------------------------------------------------------------------------------------
963  DOMAIN\administrator  DOMAIN\domain users  client-pc  (ipv4:192.0.2.1:57786)  SMB3_02           -           AES-128-CMAC

Service  pid  Machine    Connected at                  Encryption  Signing:
-------------------------------------------------------------------------------
example  969  192.0.2.1  Thu Nov  1 10:00:00 2018 CEST  -           AES-128-CMAC

Locked files:
Pid  Uid    DenyMode   Access    R/W     Oplock      SharePath           Name      Time
------------------------------------------------------------------------------------------------------------
969  10000  DENY_WRITE 0x120089  RDONLY  LEASE(RWH)  /srv/samba/example  file.txt  Thu Nov  1 10:00:00 2018

2.9.9. smbtar ユーティリティーの使用

smbtar ユーティリティーは、SMB 共有またはそのサブディレクトリーのコンテンツのバックアップを作成し、そのコンテンツを tar アーカイブに保存します。または、コンテンツをテープデバイスに書き込むこともできます。

本セクションの手順では、//server/example/ 共有にある demo ディレクトリーのコンテンツのバックアップを作成し、そのコンテンツを /root/example.tar アーカイブに保存する方法を説明します。

前提条件

samba-client パッケージがインストールされている。

手順

# smbtar -s server -x example -u user_name -p password -t /root/example.tar

2.9.10. testparm ユーティリティーの使用

重要

Red Hat では、このファイルの変更後に毎回 testparm を使用して、/etc/samba/smb.conf ファイルを検証することが推奨されます。

手順

root ユーザーで testparm ユーティリティーを実行します。

# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Unknown parameter encountered: "log levell"
Processing section "[example_share]"
Loaded services file OK.
ERROR: The idmap range for the domain * (tdb) overlaps with the range of DOMAIN (ad)!

Server role: ROLE_DOMAIN_MEMBER

Press enter to see a dump of your service definitions

# Global parameters
[global]
	...

[example_share]
	...

上記の出力例では、存在しないパラメーターと間違った ID マッピングの設定が報告されます。

testparm が設定内の間違ったパラメーター、値、またはその他のエラーを報告する場合は、問題を修正してから再度ユーティリティーを実行してください。

2.9.11. wbinfo ユーティリティーの使用

wbinfo ユーティリティーは、winbindd サービスが作成および使用する情報をクエリーし、返します。

前提条件

samba-winbind-clients パッケージがインストールされている。

手順

たとえば、以下のように、wbinfo を使用できます。

ドメインユーザーの一覧を表示します。
```
# wbinfo -u
AD\administrator
AD\guest
...
```

ドメイングループの一覧を表示します。

# wbinfo -g
AD\domain computers
AD\domain admins
AD\domain users
...

ユーザーの SID を表示します。

# wbinfo --name-to-sid="AD\administrator"
S-1-5-21-1762709870-351891212-3141221786-500 SID_USER (1)

ドメインおよび信頼に関する情報を表示します。

# wbinfo --trusted-domains --verbose
Domain Name   DNS Domain            Trust Type  Transitive  In   Out
BUILTIN                             None        Yes         Yes  Yes
server                              None        Yes         Yes  Yes
DOMAIN1       domain1.example.com   None        Yes         Yes  Yes
DOMAIN2       domain2.example.com   External    No          Yes  Yes

第3章 NFS 共有のエクスポート

システム管理者は、NFS サーバーを使用してネットワーク上のシステムのディレクトリーを共有できます。

3.1. NFS の概要

このセクションでは、NFS サービスの基本概念を説明します。

ネットワークファイルシステム (NFS) を利用すると、リモートのホストはネットワーク経由でファイルシステムをマウントし、そのファイルシステムをローカルにマウントしているファイルシステムと同じように操作できるようになります。また、リソースを、ネットワークの集中化サーバーに統合できるようになります。

NFS サーバーは、/etc/exports 設定ファイルを参照して、そのクライアントがエクスポート済みファイルシステムにアクセスできるかどうかを確認します。アクセスが可能なことが確認されると、そのユーザーは、ファイルおよびディレクトリーへの全操作を行えるようになります。

3.2. サポートされている NFS バージョン

このセクションでは、Red Hat Enterprise Linux でサポートされている NFS のバージョンとその機能の一覧を紹介します。

現在、Red Hat Enterprise Linux 8 は以下の NFS のメジャーバージョンをサポートしています。

NFS バージョン 3 (NFSv3) は安全な非同期書き込みをサポートしており、以前の NFSv2 よりもエラー処理において安定しています。64 ビットのファイルサイズとオフセットもサポートしているため、クライアントは 2 GB を超えるファイルデータにアクセスできます。
NFS バージョン 4 (NFSv4) はファイアウォールやインターネットを介して動作し、rpcbind サービスを必要とせず、アクセス制御リスト (ACL) をサポートし、ステートフルな操作を利用します。

NFS バージョン 2 (NFSv2) は、Red Hat のサポート対象外になりました。

デフォルトの NFS バージョン

Red Hat Enterprise Linux 8 のデフォルトの NFS バージョンは 4.2 です。NFS クライアントは、デフォルトで NFSv4.2 を使用してマウントを試行し、サーバーが NFSv4.2 に対応していない場合は NFSv4.1 にフォールバックします。マウントは後で NFSv4.0 に戻り、次に NFSv3 に戻ります。

マイナー NFS バージョンの機能

以下は Red Hat Enterprise Linux 8 における NFSv4.2 の機能です。

サーバー側コピー: NFS クライアントが copy_file_range() システムコールを使用してネットワークリソースを無駄にすることなく、データを効率的にコピーできるようにします。
スパースファイル: ファイルに 1 つ以上のホールを持たせることができます。ホールとは、割り当てられていない、またはゼロのみで構成される未初期化データブロックです。NFSv4.2 の lseek() 操作は seek_hole() と seek_data() をサポートしています。これにより、アプリケーションはスパースファイルのホールの場所をマップできます。
スペースの予約: ストレージサーバーが空き領域を予約することを許可します。これにより、サーバーで領域が不足することがなくなります。NFSv4.2 は、スペースを予約するための allocate() 操作、スペースの予約を解除するための deallocate() 操作、およびファイル内のスペースの事前割り当てまたは割り当て解除を行う fallocate() 操作に対応しています。
ラベル付き NFS: データアクセス権を強制し、NFS ファイルシステム上の個々のファイルに対して、クライアントとサーバーとの間の SELinux ラベルを有効にします。
レイアウトの機能強化: 一部の Parallel NFS (pNFS) サーバーがより良いパフォーマンス統計を収集できるようにする layoutstats() 操作が提供されます。

NFSv4.1 の機能は次のとおりです。

ネットワークのパフォーマンスおよびセキュリティーを強化し、pNFS のクライアント側サポートも含みます。
コールバックに個別の TCP 接続を必要としなくなりました。これにより、NAT やファイアウォールが干渉した場合など、クライアントと通信できない場合でも NFS サーバーは委任を許可できます。
応答が失われて、操作が 2 回送信された場合に特定の操作が不正確な結果を返すことがあるという以前の問題を防ぐために、1 回限りのセマンティクスを提供します (再起動操作を除く)。

3.3. NFSv3 と NFSv4 の TCP と UDP プロトコル

NFSv4 は、IP ネットワークで TCP (Transmission Control Protocol) の実行が必要です。

NFSv3 は、Red Hat Enterprise Linux の以前のバージョンで User Datagram Protocol (UDP) を使用することもできます。Red Hat Enterprise Linux 8 では、NFS over UDP はサポートされなくなりました。デフォルトでは、UDP は、NFS サーバーで無効になります。

3.4. NFS が必要とするサービス

このセクションでは、NFS サーバーの実行または NFS 共有のマウントに必要なシステムサービスの一覧を紹介します。Red Hat Enterprise Linux は、このサービスを自動的に開始します。

Red Hat Enterprise Linux では、NFS ファイル共有を提供するのに、カーネルレベルのサポートとサービスのプロセスの組み合わせを使用します。NFS のすべてのバージョンは、クライアントとサーバーとの間の Remote Procedure Call (RPC) に依存します。NFS ファイルシステムの共有やマウントには、実装されている NFS のバージョンに応じて次のようなサービスが連携して動作することになります。

nfsd

共有 NFS ファイルシステムに対する要求を処理する NFS サーバーです。

rpcbind

ローカルの RPC サービスからポート予約を受け取ります。その後、これらのポートは対応するリモートの RPC サービスによりアクセス可能であることが公開されます。rpcbind サービスは、RPC サービスへの要求に応答し、要求された RPC サービスへの接続を設定します。このプロセスは NFSv4 では使用されません。

rpc.mountd

NFS サーバーは、このプロセスを使用して NFSv3 クライアントの MOUNT 要求を処理します。要求されている NFS 共有が現在 NFS サーバーによりエクスポートされているか、またその共有へのクライアントのアクセスが許可されているかを確認します。マウントの要求が許可されると、nfs-mountd サービスは Success ステータスで応答し、この NFS 共有用の File-Handle を NFS クライアントに戻します。

rpc.nfsd

このプロセスでは、サーバーが公開している明示的な NFS のバージョンとプロトコルを定義できます。NFS クライアントが接続するたびにサーバースレッドを提供するなど、NFS クライアントの動的な要求に対応するため、Linux カーネルと連携して動作します。このプロセスは nfs-server サービスに対応します。

lockd

これはクライアントとサーバーの両方で実行されるカーネルスレッドです。Network Lock Manager (NLM) プロトコルを実装し、NFSv3 のクライアントがサーバーでファイルのロックを行えるようにします。NFS サーバーが実行中で、NFS ファイルシステムがマウントされていれば、このプロセスは常に自動的に起動します。

rpc.statd

このプロセスは、Network Status Monitor (NSM) RPC プロトコルを実装します。NFS サーバーが正常にシャットダウンされず再起動すると、NFS クライアントに通知します。rpc-statd サービスは、nfs-server サービスにより自動的に起動されるため、ユーザー設定は必要ではありません。このプロセスは NFSv4 では使用されません。

rpc.rquotad

このプロセスは、リモートユーザーのユーザークォーター情報を提供します。rpc-rquotad サービスは nfs-server サービスにより自動的に起動するため、ユーザー設定は必要ではありません。

rpc.idmapd

このプロセスは、ネットワークの NFSv4 の名前 (user@domain 形式の文字列) とローカルの UID および GID とのマッピングを行う NFSv4 クライアントおよびサーバーのアップコールを提供します。idmapd を NFSv4 で正常に動作させるには、/etc/idmapd.conf ファイルを設定する必要があります。最低でも NFSv4 マッピングドメインを定義する Domain パラメーターを指定する必要があります。NFSv4 マッピングドメインが DNS ドメイン名と同じ場合は、このパラメーターをスキップできます。クライアントとサーバーが ID マッピングの NFSv4 マッピングドメインに合意しないと、適切に動作しません。

rpc.idmapd を使用するのは NFSv4 サーバーだけで、nfs-idmapd サービスにより起動します。NFSv4 クライアントはキーリングベースの nfsidmap ユーティリティーを使用します。これは ID マッピングを実行するために、カーネルによりオンデマンドで呼び出されます。 nfsidmap に問題がある場合、クライアントは rpc.idmapd の使用にフォールバックします。

NFSv4 を使用する RPC サービス

マウントとロックのプロトコルは NFSv4 プロトコルに組み込まれています。サーバーは、既知の TCP ポート 2049 もリッスンします。そのため、NFSv4 は rpcbind サービス、lockd サービス、および rpc-statd サービスと対話する必要はありません。nfs-mountd サービスは、エクスポートを設定するために NFS サーバー上で引き続き必要となりますが、ネットワーク上の操作には関係しません。

3.5. NFS ホスト名の形式

このセクションでは、NFS 共有をマウントまたはエクスポートするときにホストの指定に使用するさまざまな形式を説明します。

次の形式でホストを指定できます。

単独のマシン

次のいずれかになります。

完全修飾ドメイン名 (これはサーバーにより解決されます)
ホスト名 (これはサーバーにより解決されます)
IP アドレス

ワイルドカードで指定された一連のマシン

文字列の一致を指定するには、* 文字または ? 文字を使用します。

ワイルドカードは IP アドレスと一緒に使用しないでください。ただし、逆引き DNS ルックアップが失敗した場合は、誤って動作する可能性があります。完全修飾ドメイン名でワイルドカードを指定する場合、ドット (.) はワイルドカードに含まれません。たとえば、*.example.com には one.example.com が含まれますが、one.two.example.com は含まれません。

IP ネットワーク

以下のいずれかの形式が有効です。

a.b.c.d/z (a.b.c.d がネットワークで z がネットマスクのビット数になります。たとえば 192.168.0.0/24)
a.b.c.d/netmask (a.b.c.d がネットワークで netmask がネットマスクになります。たとえば 192.168.100.8/255.255.255.0)

Netgroup

@group-name 形式 (group-name は NIS netgroup 名です)

3.6. NFS サーバーの設定

本セクションでは、NFS サーバーでエクスポートを構成する 2 つの方法の構文およびオプションを説明します。

設定ファイル /etc/exports を手動で編集する方法
コマンドラインで exportfs ユーティリティーを使用する方法

3.6.1. /etc/exports 設定ファイル

/etc/exports ファイルは、リモートホストにどのファイルシステムをエクスポートするかを制御し、オプションを指定します。以下の構文ルールに従います。

空白行は無視する。
コメント行は、ハッシュ記号 (#) で始める。
長い行はバックスラッシュ (\) で囲むことができる。
エクスポートするファイルシステムは、それぞれ 1 行で指定する。
許可するホストの一覧は、エクスポートするファイルシステムの後に空白文字を追加し、その後に追加する。
各ホストのオプションは、ホストの識別子の直後に括弧を追加し、その中に指定する。ホストと最初の括弧の間には空白を使用しない。

エクスポートエントリー

エクスポートするファイルシステムの各エントリーは、以下のように指定します。

export host(options)

各ホストにそれぞれオプションを付けて、複数のホストを 1 行で指定することもできます。この場合は、以下のように、各ホスト名の後に、そのホストに対するオプションを括弧を付けて追加します。ホストは空白文字で区切ります。

export host1(options1) host2(options2) host3(options3)

この構造では、次のようになります。

export: エクスポートするディレクトリー
host: エクスポートを共有するホストまたはネットワーク
options: ホストに使用されるオプション

例3.1 簡潔な /etc/exports ファイル

最も簡単な方法は、/etc/exports ファイルに、エクスポートするディレクトリーと、そのディレクトリーへのアクセスを許可するホストを指定することです。

/exported/directory bob.example.com

ここで、bob.example.com は、NFS サーバーから /exported/directory/ をマウントできます。この例ではオプションが指定されていないため、NFS はデフォルトのオプションを使用します。

重要

/etc/exports ファイルのフォーマットでは、特に空白文字の使用は非常に厳しく扱われます。ホストからエクスポートされるファイルシステムの間、そしてホスト同士の間には、必ず空白文字を挿入してください。また、それ以外の場所 (コメント行を除く) には、絶対に空白文字を追加しないでください。

たとえば、以下の 2 つの行は意味が異なります。

/home bob.example.com(rw)
/home bob.example.com (rw)

最初の行は、bob.example.com からのユーザーにのみ、/home ディレクトリーへの読み込み/書き込みアクセスを許可します。2 番目の行は、bob.example.com からのユーザーにはディレクトリーを読み込み専用 (デフォルト) でマウントすることを許可しており、その他のユーザーには読み込み/書き込みでマウントすることを許可します。

デフォルトのオプション

エクスポートエントリーのデフォルトオプションは次のとおりです。

ro

エクスポートするファイルシステムは読み込み専用です。リモートホストは、このファイルシステムで共有されているデータを変更できません。このファイルシステムで変更 (読み込み/書き込み) を可能にするには、rw オプションを指定します。

sync

NFS サーバーは、以前の要求で発生した変更がディスクに書き込まれるまで、要求に応答しません。代わりに非同期書き込みを有効にするには、async オプションを指定します。

wdelay

NFS サーバーは、別の書き込み要求が差し迫っていると判断すると、ディスクへの書き込みを遅らせます。これにより、複数の書き込みコマンドが同じディスクにアクセスする回数を減らすことができるため、書き込みのオーバーヘッドが低下し、パフォーマンスが向上します。これを無効にするには、no_wdelay を指定します。これは、デフォルトの sync オプションが指定されている場合に限り利用可能になります。

root_squash

(ローカルからではなく) リモートから接続している root ユーザーが root 権限を持つことを阻止します。代わりに、そのユーザーには、NFS サーバーにより、ユーザー ID nfsnobody が割り当てられます。これにより、リモートの root ユーザーの権限を、最も低いローカルユーザーレベルにまで下げて (squash)、権限を持たずにリモートサーバーに書き込むのを阻止します。この root squashing を無効にするには、no_root_squash オプションを指定します。

(root を含む) すべてのリモートユーザーの権限を下げるには、all_squash オプションを使用します。特定ホストのリモートユーザーに対して、NFS サーバーが割り当てるユーザー ID とグループ ID を指定するには、anonuid オプションと anongid オプションをそれぞれ以下のように使用します。

export host(anonuid=uid,anongid=gid)

ここで uid と gid は、それぞれユーザー ID 番号とグループ ID 番号になります。anonuid オプションと anongid オプションにより、共有するリモート NFS ユーザー用の特別なユーザーおよびグループアカウントを作成できます。

デフォルトでは、アクセス制御リスト (ACL) は、Red Hat Enterprise Linux では、NFS によりサポートされています。この機能を無効にするには、ファイルシステムをエクスポートする際に no_acl オプションを指定します。

デフォルトオプションと上書きオプション

エクスポートするファイルシステムのデフォルトはすべて、明示的に上書きする必要があります。たとえば、rw オプションを指定しないと、エクスポートするファイルシステムが読み込み専用として共有されます。以下は、/etc/exports の例になりますが、ここでは 2 つのデフォルトオプションを上書きしています。

/another/exported/directory 192.168.0.3(rw,async)

この例では、192.168.0.3 は /another/exported/directory/ の読み書きをマウントでき、ディスクへの書き込みはすべて非同期です。

3.6.2. exportfs ユーティリティー

exportfs ユーティリティーを使用すると、root ユーザーは NFS サービスを再起動せずにディレクトリーを選択してエクスポートまたはアンエクスポートできます。適切なオプションが指定されると、exportfs ユーティリティーはエクスポートされたファイルシステムを /var/lib/nfs/xtab に書き込みます。ファイルシステムへのアクセス権を決定する際には、nfs-mountd サービスが xtab ファイルを参照するため、エクスポートしたファイルシステムのリストの変更が直ちに反映されます。

一般的な exportfs オプション

exportfs で利用可能な一般的なオプションの一覧は以下のようになります。

-r: /etc/exports に記載されるすべてのディレクトリーから、/etc/lib/nfs/xtab に新しいエクスポート一覧を作成することで、ディレクトリーがエクスポートされることになります。結果的にこのオプションが /etc/exports のいずれかの変更でエクスポート一覧をリフレッシュすることになります。
-a: exportfs に渡されるその他のオプションに応じて、すべてのディレクトリーをエクスポートするかどうかを判断します。その他のオプションが指定されていない場合、exportfs は /etc/exports で指定されたすべてのファイルシステムをエクスポートします。
-o file-systems: /etc/exports 内に記載されていない、エクスポートされるディレクトリーを指定します。file-systems の部分を、エクスポートされる追加のファイルシステムに置き換えます。これらのファイルシステムは、/etc/exports で指定されたものと同じフォーマットでなければなりません。このオプションは、多くの場合は、エクスポートされるファイルシステムの一覧に永続的に追加する前に、エクスポートされるファイルシステムをテストするために使用されます。
-i: /etc/exports を無視します。コマンドラインから出されたオプションのみが、エクスポート用ファイルシステムの定義に使用されます。
-u: すべての共有ディレクトリーをエクスポートしません。コマンド exportfs -ua は、すべての NFS サービスを稼働状態に維持しながら、NFS ファイル共有を保留します。NFS 共有を再度有効にするには、exportfs -r を使用します。
-v: 詳細な表示です。exportfs コマンドを実行するときに表示されるエクスポート、または非エクスポートのファイルシステムの情報が、より詳細に表示されます。

exportfs ユーティリティーにオプションが渡されていない場合は、現在エクスポートされているファイルシステムのリストが表示されます。

3.7. NFS および rpcbind

このセクションでは、NFSv3 で必要とされる rpcbind サービスの目的を説明します。

rpcbind サービスは、リモートプロシージャーコール (RPC) サービスを、そのサービスがリッスンするポートにマッピングします。RPC のプロセスが開始すると、その開始が rpcbind に通知され、そのプロセスがリッスンしているポートおよびそのプロセスが処理することが予想される RPC プログラム番号が登録されます。クライアントシステムは、特定の RPC プログラム番号でサーバーの rpcbind と通信します。rpcbind サービスはクライアントを適切なポート番号にリダイレクトし、要求されたサービスと通信できるようにします。

RPC ベースのサービスは、クライアントの受信要求で接続を確立するのに、必ず rpcbind を使用します。したがって、RPC ベースのサービスが起動する前に、rpcbind が利用可能な状態にする必要があります。

rpcbind のアクセス制御ルールは、すべての RPC ベースのサービスに影響します。あるいは、NFS RPC デーモンごとにアクセス制御ルールを指定することもできます。

3.8. NFS のインストール

この手順では、NFS 共有のマウントまたはエクスポートに必要なすべてのパッケージをインストールします。

手順

nfs-utils パッケージをインストールします。
```
# yum install nfs-utils
```

3.9. NFS サーバーの起動

この手順では、NFS 共有をエクスポートするために必要な NFS サーバーの起動方法を説明します。

前提条件

NFSv2 または NFSv3 の接続をサポートしているサーバーの場合は、rpcbind サービスを実行している。rpcbind がアクティブであることを確認するには、次のコマンドを使用します。
```
$ systemctl status rpcbind
```
サービスが停止している場合は、起動して有効にします。
```
$ systemctl enable --now rpcbind
```

手順

NFS サーバーを起動し、システムの起動時に自動的に起動するようにするには、次のコマンドを使用します。
```
# systemctl enable --now nfs-server
```

3.10. NFS と rpcbind のトラブルシューティング

rpcbind サービスでは通信に使用するポート番号と RPC サービス間の調整を行うため、トラブルシューティングを行う際は、rpcbind を使用して現在の RPC サービスの状態を表示させると便利です。rpcinfo ユーティリティーを使用すると RPC ベースの各サービスとそのポート番号、RPC プログラム番号、バージョン番号、および IP プロトコルタイプ (TCP または UDP) が表示されます。

手順

rpcbind に対して適切な RPC ベースの NFS サービスが有効になっていることを確認するには、次のコマンドを使用します。

# rpcinfo -p

例3.2 rpcinfo -p コマンドの出力

以下に上記コマンドの出力例を示します。

   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100024    1   udp  37769  status
    100024    1   tcp  49349  status
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100021    1   udp  56691  nlockmgr
    100021    3   udp  56691  nlockmgr
    100021    4   udp  56691  nlockmgr
    100021    1   tcp  46193  nlockmgr
    100021    3   tcp  46193  nlockmgr
    100021    4   tcp  46193  nlockmgr

NFS サービスの 1 つが正しく起動しない場合、rpcbind は、そのサービスに対するクライアントからの RPC 要求を、正しいポートにマッピングできません。

多くの場合は、NFSが rpcinfo の出力に表示されていない時に NFS を再起動すると、サービスは rpcbind に正しく登録され、動作を開始します。
```
# systemctl restart nfs-server
```

3.11. ファイアウォールの内側で動作するように NFS サーバーの設定

NFS は rpcbind サービスを必要とします。これは RPC サービスのポートを動的に割り当て、ファイアウォールルールの設定で問題が発生する可能性があります。この手順では、ファイアウォールの内側で機能するように NFS サーバーを設定する方法を説明します。

手順

クライアントがファイアウォールの内側で NFS 共有にアクセスできるようにするには、/etc/nfs.conf ファイルの [mountd] セクションで RPC サービスを実行するポートを設定します。
```
[mountd]

port=port-number
```
これにより、-p port-number オプションが rpc.mount コマンドラインに追加されます (rpc.mount -p port-number)。
NFSv4.0 コールバックがファイアウォールを通過するように許可するには、/proc/sys/fs/nfs/nfs_callback_tcpport を設定して、サーバーがクライアントのそのポートに接続できるようにします。
この手順は、NFSv4.1 またはそれ以降には必要ありません。そして mountd、statd、および lockd の他のポート群は、純粋な NFSv4 環境では必要ありません。
RPC サービスの nlockmgr が使用するポートを指定するには、/etc/modprobe.d/lockd.conf ファイルで nlm_tcpport オプションと nlm_udpport オプションのポート番号を設定します。
NFS サーバーを再起動します。
```
#  systemctl restart nfs-server
```
NFS が起動しない場合は、/var/log/messages を確認してください。一般的に、すでに使用されているポート番号を指定した場合、NFS は起動しません。
変更が反映されたことを確認します。
```
# rpcinfo -p
```

3.12. ファイアウォールからの RPC クォータのエクスポート

ディスククォータを使用するファイルシステムをエクスポートする場合は、クォータの RPC (Remote Procedure Call) サービスを使用して、NFS クライアントにディスククォータデータを提供できます。

手順

rpc-rquotad サービスを有効にして起動します。
```
# systemctl enable --now rpc-rquotad
```
注記
rpc-rquotad サービスが有効になっている場合は、nfs-server サービスが起動した後に自動的に起動されます。
ファイアウォールの内側で、クォータの RPC サービスにアクセスできるようにするには、TCP (UDP が可能な場合は UDP) ポート 875 を開く必要があります。デフォルトのポート番号は /etc/services ファイルで定義します。
デフォルトのポート番号は、/etc/sysconfig/rpc-rquotad ファイルの RPCRQUOTADOPTS 変数に -p port-number を追加すると上書きできます。
デフォルトで、リモートホストはクォータのみを読み取ることができます。クライアントにクォータの設定を許可したい場合は、/etc/sysconfig/rpc-rquotad ファイルの RPCRQUOTADOPTS 変数に -S オプションを追加します。
/etc/sysconfig/rpc-rquotad ファイルでの変更が反映されるように rpc-rquotad を再起動します。
```
# systemctl restart rpc-rquotad
```

3.13. NFS over RDMA の有効化 (NFSoRDMA)

Red Hat Enterprise Linux 8 では、RDMA に対応するハードウェアが存在すると、RDMA (remote direct memory access) サービスが自動的に有効になります。

手順

rdma パッケージと rdma-core パッケージをインストールします。
```
# yum install rdma rdma-core
```
NFSoRDMA の server モジュールの自動読み込みを有効にするには、/etc/rdma/rdma.conf 設定ファイルの新しい行に SVCRDMA_LOAD=yes オプションを追加します。
/etc/nfs.conf ファイルの [nfsd] セクションにある rdma=20049 オプションで、NFSoRDMA サービスがクライアントをリッスンするポート番号を指定します。RFC 5667 規格では、RDMA を介して NFSv4 サービスを提供する場合、サーバーはポート 20049 をリッスンする必要があると規定されています。
/etc/rdma/rdma.conf ファイルには、デフォルトで XPRTRDMA_LOAD=yes オプションを設定する行が含まれています。これは rdma サービスに NFSoRDMA client モジュールをロードするように要求します。
nfs-server サービスを再起動します。
```
# systemctl restart nfs-server
```

3.14. NFSv4 専用サーバーの設定

NFS サーバー管理者は、NFSv4 のみをサポートするように NFS サーバーを設定できます。これにより、システムで開いているポートの数と実行中のサービスの数が最小限に抑えられます。

3.14.1. NFSv4 専用サーバーの長所と短所

このセクションでは、NFSv4 のみをサポートするように NFS サーバーを設定する長所と短所を説明します。

デフォルトでは、NFS サーバーは Red Hat Enterprise Linux 8 の NFSv2、NFSv3、および NFSv4 の接続をサポートします。ただし、NFS バージョン 4.0 以降のみをサポートするように NFS を設定することもできます。NFSv4 では rpcbind サービスがネットワークをリッスンする必要がないため、これにより、システムで開いているポートと実行中のサービスの数が最小限に抑えられます。

NFS サーバーが NFSv4 専用として設定されていると、NFSv2 または NFSv3 を使用して共有をマウントしようとするクライアントは、次のようなエラーでマウントに失敗します。

Requested NFS version or transport protocol is not supported.

必要に応じて、RPCBIND、MOUNT、および NSM のプロトコル呼び出しのリッスンを無効にすることもできます。これは NFSv4 専用の場合は不要です。

これらの追加オプションを無効にすると、次のような影響があります。

NFSv2 または NFSv3 を使用してサーバーから共有をマウントしようとするクライアントが応答しなくなります。
NFS サーバー自体が NFSv2 および NFSv3 のファイルシステムをマウントできなくなります。

3.14.2. NFS および rpcbind

このセクションでは、NFSv3 で必要とされる rpcbind サービスの目的を説明します。

3.14.3. NFSv4 のみをサポートするように NFS サーバーの設定

この手順では、NFS サーバーが NFS バージョン 4.0 以降のみをサポートするように設定する方法を説明します。

手順

/etc/nfs.conf 設定ファイルの [nfsd] セクションに次の行を追加して、NFSv2 および NFSv3 を無効にします。
```
[nfsd]

vers2=no
vers3=no
```
必要に応じて、RPCBIND、MOUNT、および NSM のプロトコル呼び出しのリッスンを無効にします。これは NFSv4 専用の場合は不要です。関連するサービスを無効にします。
```
# systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
```
NFS サーバーを再起動します。
```
# systemctl restart nfs-server
```

変更は、NFS サーバーを起動または再起動するとすぐに反映されます。

3.14.4. NFSv4 専用の設定の確認

この手順では、netstat ユーティリティーを使用して、NFS サーバーが NFSv4 専用モードで設定されていることを確認する方法を説明します。

手順

TCP プロトコルおよび UDP プロトコルでリッスンしているサービスを一覧表示するには、netstat ユーティリティーを使用します。

# netstat --listening --tcp --udp

例3.3 NFSv4 専用サーバーの出力

以下は、NFSv4 専用サーバーでの netstat の出力例です。RPCBIND、MOUNT、および NSM のリッスンも無効になります。nfs が唯一リッスンする NFS サービスとなります。

# netstat --listening --tcp --udp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:nfs             0.0.0.0:*               LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
tcp6       0      0 [::]:nfs                [::]:*                  LISTEN
udp        0      0 localhost.locald:bootpc 0.0.0.0:*

例3.4 NFSv4 専用サーバーを設定する前の出力

対照的に、NFSv4 専用サーバーを設定する前の netstat 出力には、sunrpc サービスと mountd サービスが含まれています。

# netstat --listening --tcp --udp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:40189           0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:46813           0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:nfs             0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:sunrpc          0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:mountd          0.0.0.0:*       LISTEN
tcp6       0      0 [::]:ssh                [::]:*          LISTEN
tcp6       0      0 [::]:51227              [::]:*          LISTEN
tcp6       0      0 [::]:nfs                [::]:*          LISTEN
tcp6       0      0 [::]:sunrpc             [::]:*          LISTEN
tcp6       0      0 [::]:mountd             [::]:*          LISTEN
tcp6       0      0 [::]:45043              [::]:*          LISTEN
udp        0      0 localhost:1018          0.0.0.0:*
udp        0      0 localhost.locald:bootpc 0.0.0.0:*
udp        0      0 0.0.0.0:mountd          0.0.0.0:*
udp        0      0 0.0.0.0:46672           0.0.0.0:*
udp        0      0 0.0.0.0:sunrpc          0.0.0.0:*
udp        0      0 0.0.0.0:33494           0.0.0.0:*
udp6       0      0 [::]:33734              [::]:*
udp6       0      0 [::]:mountd             [::]:*
udp6       0      0 [::]:sunrpc             [::]:*
udp6       0      0 [::]:40243              [::]:*

第4章 NFS のセキュア化

サーバーで NFS ファイルシステムをエクスポートする場合や、クライアントにマウントする際に、NFS セキュリティーリスクを最小限に抑え、サーバーのデータを保護するには、以下のセクションを考慮してください。

4.1. AUTH_SYS とエクスポート制御による NFS 保護

NFS は、エクスポートしたファイルへのアクセスを制御するために、以下の従来のオプションを提供します。

IP アドレスまたはホスト名を使用して、どのホストにどのファイルシステムのマウントを許可するかを、サーバー側で制限するオプションです。
サーバーは、ローカルユーザーの場合と同じ方法で、NFS クライアントのユーザーに対してファイルシステムの権限を強制します。従来は、NFS は AUTH_SYS コールメッセージ (AUTH_UNIX とも呼ばれます) を使用してこれを実行します。このメッセージは、クライアントに依存してユーザーの UID と GID を提示します。これは、悪意のあるクライアントや誤って設定されたクライアントが簡単にこの間違いを招き、ユーザーがアクセスすべきではないファイルにアクセスできる可能性があることを意味します。

潜在的なリスクを制限するため、多くの場合、管理者は、共通のユーザーおよびグループの ID に対して、ユーザー権限を読み取り専用または権限を下げてアクセスを制限します。ただし、このソリューションにより、NFS 共有が元々想定されている方法では使用されなくなります。

さらに、攻撃者が NFS ファイルシステムをエクスポートするシステムが使用する DNS サーバーを制御できた場合は、特定のホスト名または完全修飾ドメイン名に関連付けられたシステムを、承認されていないマシンに指定できます。これで、認証されていないマシンは、NFS 共有のマウントを許可するシステムになります。これは、ユーザー名やパスワードの情報が交換されず、NFS マウントに追加のセキュリティーが提供されるためです。

NFS 経由でディレクトリーのエクスポートを行う際にワイルドカードを使用する場合は慎重に行ってください。ワイルドカードの対象が予定よりも広い範囲のシステムを対象とする可能性があります。

4.2. `AUTH_GSS`を使用した NFS セキュリティー

NFS の全バージョンは、RPCSEC_GSS および Kerberos メカニズムをサポートします。

AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、どのユーザーがそのファイルにアクセスしているかを正確に表すために、サーバーはクライアントに依存しません。代わりに、暗号を使用してサーバーにユーザーを認証し、悪意のあるクライアントがそのユーザーの Kerberos 認証情報を持たずにユーザーになりすますことがないようにします。RPCSEC_GSS Kerberos メカニズムを使用することが、マウントを保護する最も簡単な方法になります。Kerberos の設定後は、追加の設定が不要になるためです。

4.3. Kerberos を使用するための NFS サーバーおよびクライアントの設定

Kerberos はネットワーク認証システムであり、対称暗号化と、信頼できるサードパーティー (KDC) を使用してクライアントとサーバーが相互に認証できるようにします。Red Hat では、Kerberos の設定に Identity Management (IdM) を使用することを推奨しています。

前提条件

Kerberos Key Distribution Centre (KDC) がインストールされ、設定されている。

手順

- NFS サーバー側で、nfs/hostname.domain@REALM プリンシパルを作成します。
- サーバーおよびクライアントの両方で、host/hostname.domain@REALM を作成します。
- クライアントとサーバーの各キータブに該当する鍵を追加します。
サーバー側で sec= オプションを使用して、希望するセキュリティーフレーバーを有効にします。すべてのセキュリティーフレーバーと非暗号化マウントを有効にするには、以下のコマンドを実行します。
```
/export *(sec=sys:krb5:krb5i:krb5p)
```
sec= オプションを使用するのに有効なセキュリティーフレーバーは、以下のようになります。
- sys - 暗号化の保護なし (デフォルト)
- krb5 - 認証のみ
- krb5i - インテグリティー保護
- krb5p - プライバシー保護
クライアント側で、sec=krb5 (もしくは設定に応じて sec=krb5i または sec=krb5p) をマウントオプションに追加します。
```
# mount -o sec=krb5 server:/export /mnt
```

4.4. NFSv4 セキュリティーオプション

NFSv4 には、Microsoft Windows NT モデルの機能や幅広い導入の経緯があるため、POSIX モデルではなく、Microsoft Windows NT モデルをベースとした ACL サポートが含まれます。

NFSv4 のもう 1 つの重要なセキュリティー機能は、ファイルシステムのマウントに MOUNT プロトコルを使用しなくなることです。MOUNT プロトコルは、プロトコルがファイルを処理する方法により、セキュリティー上のリスクが発生します。

4.5. マウントされた NFS エクスポートに対するファイル権限

リモートホストによりNFS ファイルシステムを読み取りまたは読み書きとしてマウントした場合は、権限が、各共有ファイルに対する唯一の保護なります。同じユーザー ID の値を共有する 2 つのユーザーが、異なるクライアントシステムに同じ NFS ファイルシステムをマウントすると、そのユーザーは互いのファイルを修正できるようになります。また、クライアントシステムで root としてログインした場合は、su - コマンドを使用して NFS 共有が設定されたファイルにアクセスできます。

デフォルトでは、アクセス制御リスト (ACL) は、Red Hat Enterprise Linux では NFS によりサポートされています。Red Hat では、この機能を有効にしておくことを推奨しています。

デフォルトでは、NFS がファイルシステムをエクスポートする際に、root squashing を使用します。これにより、NFS 共有にアクセスするユーザーのユーザー ID が、ローカルマシンの root ユーザーとして nobody に設定されます。root squashing は、デフォルトのオプション root_squash で制御されます。このオプションの詳細は、「NFS サーバーの設定」を参照してください。

NFS 共有を読み取り専用としてエクスポートする場合は、all_squash オプションの使用を検討してください。このオプションでは、エクスポートしたファイルシステムにアクセスするすべてのユーザーが、nfsnobody ユーザーのユーザー ID を取得します。

第5章 Red Hat Enterprise Linux 8 上のデータベースサーバー

5.1. データベースおよびデータベースサーバーの概要

データベースは、データの集合を構成します。データベースのデータは保存され、電子的にアクセスできます。

データベース内のデータの編成は、通常、以下をサポートするように設計されています。

現実のさまざまな側面のモデル化
属性に応じたデータのクエリーおよびフィルタリング

Red Hat Enterprise Linux 8 は、以下のデータベースサーバーを提供します。

MariaDB 10.3
MySQL 8.0
PostgeSQL 10
PostgreSQL 9.6

5.2. Red Hat Enterprise Linux 8 での MariaDB の使用

5.2.1. Red Hat Enterprise Linux 8 の MariaDB の概要

MariaDB サーバーは、MySQL テクノロジーをベースとしたオープンソースの高速で強力なデータベースサーバーです。

MariaDB は、データを構造化情報に変換して、データにアクセスする SQL インターフェースを提供するリレーショナルデータベースです。これには、複数のストレージエンジンとプラグイン、および地理的な情報システム (GIS) および JSON (JavaScript Object Notation) 機能が含まれます。

本セクションでは、「MariaDB のインストール」で、MariaDB サーバーをインストールする方法を説明します。また、「MariaDB 10.3 への移行」では、Red Hat Enterprise Linux 7 のデフォルトバージョンの MariaDB 5.5 から Red Hat Enterprise Linux 8 のデフォルトバージョンの MariaDB 10.3 に移行する方法について説明します。移行の前提条件として、「MariaDB データのバックアップ」で説明されているデータバックアップの実行があります。

5.2.2. MariaDB のインストール

MariaDB をインストールするには、以下の手順を行います。

AppStream リポジトリーで利用可能な mariadb パッケージおよび mariadb-server パッケージが、必要なサーバーにインストールされていることを確認します。
```
~]# yum install mariadb mariadb-server
```
mariadb サービスを起動します。
```
~]# systemctl start mariadb.service
```
mariadb サービスが、システムの起動時に起動するようにします。
```
~]# systemctl enable mariadb.service
```

注記

RPM パッケージの競合により、データベースサーバー MariaDB および MySQL を Red Hat Enterprise Linux 8.0 で並行してインストールできないことに注意してください。Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 用の Red Hat Software Collections では、コンポーネントの同時インストールが可能です。Red Hat Enterprise Linux 8 では、コンテナーで異なるバージョンのデータベースサーバーを使用できます。

5.2.2.1. MariaDB インストールセキュリティーの改善

MariaDB のインストール時に mysql_secure_installation コマンドを実行すると、セキュリティーが強化されます。

~]# mysql_secure_installation

このコマンドは、プロセスの各ステップを要求する完全にインタラクティブなスクリプトを起動します。

このスクリプトを使用すると、次の方法でセキュリティーを改善できます。

root アカウントのパスワードの設定
匿名ユーザーの削除
リモート (ローカルホスト外) の root ログインの拒否

5.2.3. MariaDB の設定

5.2.3.1. MariaDB サーバーのネットワーク設定

MariaDB サーバーをネットワーク用に設定するには、/etc/my.cnf.d/mariadb-server.cnf ファイルの [mysqld] セクションを使用します。ここには、以下の設定ディレクティブを設定できます。

bind-address
bind-address は、サーバーがリッスンするアドレスです。
可能なオプションは、ホスト名、IPv4 アドレス、または IPv6 アドレスです。
skip-networking +fna では、以下の値が利用できます。
0 - すべてのクライアントをリッスンする
1 - ローカルクライアントのみをリッスンする
port
MariaDB が TCP/IP 接続をリッスンするポート。

5.2.4. MariaDB データのバックアップ

5.2.4.1. MariaDB バックアップのタイプ

MariaDB データベースからデータのバックアップを取得するには、以下の 2 つの方法があります。

論理バックアップ
物理バックアップ

論理バックアップ は、データの復元に必要な SQL ステートメントで構成されます。この種類のバックアップは、情報およびレコードをプレーンテキストファイルにエクスポートします。

物理バックアップに対する論理バックアップの主な利点は、移植性と柔軟性です。データは、物理バックアップではできない他のハードウェア構成である MariaDB バージョンまたはデータベース管理システム (DBMS) で復元できます。

mariadb.service が稼働している場合は、論理バックアップを実行できることに注意してください。論理バックアップには、ログと設定ファイルが含まれません。

物理バックアップ は、コンテンツを格納するファイルおよびディレクトリーのコピーで構成されます。

物理バックアップは、論理バックアップと比較して、以下の利点があります。

出力が少なくなる。
バックアップのサイズが小さくなる。
バックアップおよび復元が速くなる。
バックアップには、ログファイルと設定ファイルが含まれる。

mariadb.service が実行していない場合や、データベースのすべてのテーブルがロックされていて、バックアップ中に変更しないようにする場合は、物理バックアップを実行する必要があります。

5.2.4.2. MariaDB のバックアップ方法

MariaDB データベースのデータのバックアップには、以下のいずれかの方法を使用できます。

「mysqldump を使用した論理バックアップ」
「Mariabackup ツールを使用した物理的なオンラインバックアップ」
「ファイルシステムのバックアップ」
「レプリケーションをバックアップソリューションとして使用」

5.2.4.3. mysqldump を使用した論理バックアップ

mysqldump クライアントはバックアップユーティリティーで、バックアップ目的でデータベースまたはデータベースの集合をダンプしたり、別のデータベースサーバーに転送したりできます。通常、mysqldump の出力は、テーブルの作成、テーブルの追加、またはテーブルの作成および追加を可能にする SQL ステートメントから構成されます。また、mysqldump は、CSV などのコンマ区切りテキスト形式、XML など、その他の形式のファイルも生成できます。

mysqldump を使用した論理バックアップの詳細は、MariaDB のドキュメントを参照してください。

mysqldump バックアップを実行するには、以下のいずれかのオプションを使用できます。

選択したデータベースをバックアップする。
あるデータベースのテーブルのサブセットのバックアップを作成する。
複数のデータベースをバックアップする。
すべてのデータベースをバックアップする。

5.2.4.3.1. mysqldump バックアップでよく使用されるコマンド

データベース全体のバックアップを取得するには、以下を実行します。
```
~]# mysqldump [options] db_name > backup-file.sql
```
あるデータベースで、テーブルのサブセットのバックアップを作成するには、コマンドの最後に選択したテーブルの一覧を追加します。
```
~]# mysqldump [options] db_name [tbl_name …]
```

ダンプファイルをサーバーに読み込むには、次を実行します。

~]# mysql db_name < backup-file.sql

または

~]# mysql -e "source /path-to-backup/backup-file.sql" db_name

データを MariaDB サーバー間でコピーしてデータベースを入力するには、以下を実行します。
```
~]# mysqldump --opt db_name | mysql --host=remote_host -C db_name
```
複数のデータベースを一度にダンプするには、次のコマンドを実行します。
```
~]# mysqldump [options] --databases db_name1 [db_name2 …] > my_databases.sql
```
すべてのデータベースをダンプするには、以下を実行します。
```
~]# mysqldump [options]--all-databases > all_databases.sql
```
mysqldump サポートするオプションの一覧を表示するには、以下を実行します。
```
~]$ mysqldump --help
```

5.2.4.4. Mariabackup ツールを使用した物理的なオンラインバックアップ

Mariabackup は、Percona Xtrabackup テクノロジーをベースとしたツールで、InnoDB、Aria、および MyISAM のテーブルの物理的なオンラインバックアップを実行できます。

AppStream リポジトリーの mariadb-backup パッケージが提供する Mariabackup は、MariaDB サーバーの完全バックアップ機能に対応します。これには、暗号化されたデータと圧縮データが含まれます。

Mariabackup をインストールするには、root で以下のコマンドを実行します。

~]# yum install mariadb-backup

Mariabackup を設定するには、作成する必要がある *.cnf 設定ファイル (/etc/my.cnf.d/mariabackup.cnf など) の [xtrabackup] セクションまたは [mysqld] セクションに以下の行を追加して、ユーザー名とパスワードを設定します。

[xtrabackup]
user=myuser
password=mypassword

重要

Mariabackup は、設定ファイルの [mariadb] セクションのオプションは読み込みません。MariaDB サーバーにデフォルト以外のデータディレクトリーが指定されている場合は、Mariabackup がデータディレクトリーを見つけることができるように、設定ファイルの [xtrabackup] セクションまたは [mysqld] セクションでこのディレクトリーを指定する必要があります。

このようなデータディレクトリーを指定するには、MariaDB 設定ファイルの [xtrabackup] セクションまたは [mysqld] セクションに以下の行を追加します。

datadir=/var/mycustomdatadir

注記

Mariabackup のユーザーがバックアップを操作するには、RELOAD、LOCK TABLES、および REPLICATION CLIENT の特権が必要です。

Mariabackup を使用してデータベースのバックアップを作成するには、以下のコマンドを実行します。

~]$ mariabackup --backup --target-dir <backup_directory> --user <backup_user> --password <backup_passwd>

target-dir オプションは、バックアップファイルを格納するディレクトリーを定義します。

完全バックアップを実行する場合は、ターゲットディレクトリーが空であるか、存在しない場合があることに注意してください。

Mariabackup によるバックアップの実行の詳細は、「Full Backup and Restore with Mariabackup」を参照してください。

5.2.4.5. ファイルシステムのバックアップ

ファイルシステムのバックアップを作成する場合は、データファイルを別の場所にコピーします。データファイルのコピー時に mariadb サービスが稼働していないことを確認してください。

MariaDB データファイルのファイルシステムのバックアップを作成するには、root で以下の手順を行います。

mariadb サービスを停止します。
```
~]# systemctl stop mariadb.service
```
データファイルを必要な場所にコピーします。
```
~]# cp -r /var/lib/mysql /backup-location
```
mariadb サービスを起動します。
```
~]# systemctl start mariadb.service
```

5.2.4.6. レプリケーションをバックアップソリューションとして使用

レプリケーションは、マスターサーバー用の代替バックアップソリューションです。マスターサーバーの複製となるスレーブサーバーを作成すると、マスターに影響を与えずに、スレーブでバックアップを実行できます。

警告

レプリケーションは、バックアップソリューションとしては十分ではありません。レプリケーションは、ハードウェア障害からマスターサーバーを保護しますが、データ損失に対する保護は保証しないためです。

レプリケーションをバックアップソリューションとして使用する場合は、MariaDB ドキュメンテーションを参照してください。

5.2.5. MariaDB 10.3 への移行

Red Hat Enterprise Linux 7 には、MySQL データベースファミリーからのサーバーのデフォルトの実装として、MariaDB 5.5 が同梱されています。新しいバージョンの MariaDB データベースサーバーは、Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 の Software Collections として利用できます。Red Hat Enterprise Linux 8 は、MariaDB 10.3 および MySQL 8.0 を提供します。

5.2.5.1. RHEL 7 と RHEL 8 のバージョンの MariaDB の違い

MariaDB 5.5 と MariaDB 10.3 において最も重要な変更点を以下に示します。

10.1 以降、同期マルチクラスターでもある MariaDB Galera Cluster が、MariaDB の標準に含まれるようになりました。
ARCHIVE ストレージエンジンはデフォルトで有効ではなくなるため、プラグインを明示的に有効にする必要があります。
BLACKHOLE ストレージエンジンはデフォルトで有効ではなくなるため、プラグインを明示的に有効にする必要があります。
InnoDB は、MariaDB 10.1 以前のバージョンで使用されていた XtraDB ではなく、デフォルトのストレージエンジンとして使用されます。
詳細は、「Why does MariaDB 10.2 use InnoDB instead of XtraDB?」を参照してください。
新しい mariadb-connector-c パッケージは、MySQL と MariaDB に共通のクライアントライブラリーを提供します。このライブラリーは、データベースサーバー MySQL および MariaDB のすべてのバージョンで使用できます。その結果、Red Hat Enterprise Linux 8 に同梱される MySQL サーバーまたは MariaDB サーバーのいずれかに構築されるアプリケーションの 1 つに接続できます。

MariaDB 5.5 から MariaDB 10.3 へ移行するには、「設定変更」の記載どおりに複数の設定を実行する必要があります。

5.2.5.2. 設定変更

MariaDB 5.5 から MariaDB 10.3 への推奨される移行パスは、最初に MariaDB 10.0 にアップグレードしてから、1 バージョンずつ順次アップグレードすることです。

MariaDB 5.5 から MariaDB 10.0 への移行時の設定の変更の詳細は、『Red Hat Software Collections』の「MariaDB 10.0 への移行」を参照してください。

以下の後続バージョンの MariaDB への以降と、必要な設定変更は、以下のドキュメントで説明します。

Red Hat Software Collections ドキュメントの「Migrating to MariaDB 10.1」
Red Hat Software Collections ドキュメントの「Migrating to MariaDB 10.2」
アップストリームのドキュメントの「Upgrading from MariaDB 10.2 to MariaDB 10.3」

注記

MariaDB 5.5 から MariaDB 10.3 へ直接移行することもできますが、上記の移行ドキュメントに記載されている違いにより必要とされる設定変更をすべて実行する必要があります。

5.2.5.3. mysql_upgrade ツールを使用したインプレースアップグレード

データベースファイルを Red Hat Enterprise Linux 8 に移行するには、Red Hat Enterprise Linux 7 の MariaDB ユーザーが、mysql_upgrade ツールを使用してインプレースアップグレードを実行する必要があります。

インプレースアップグレードを実行するには、Red Hat Enterprise Linux 8 システムの /var/lib/mysql/ データディレクトリーにバイナリーデータファイルをコピーして、mysql_upgrade ツールを使用する必要があります。

この方法を使用すると、以下からデータを移行できます。

Red Hat Enterprise Linux 7 バージョンの MariaDB 5.5
Red Hat Software Collections のバージョンは、以下の通りです。
- MariaDB 5.5 (サポート対象外になりました)
- MariaDB 10.0 (サポート対象外になりました)
- MariaDB 10.1
- MariaDB 10.2

MariaDB 10.2 へのアップグレードは、バージョンごとに行うことが推奨されます。移行は、Red Hat Software Collections Release Notes で該当する章を参照してください。

注記

Red Hat Enterprise Linux 7 バージョンの MariaDB からアップグレードする場合、ソースデータは /var/lib/mysql/ ディレクトリーに保存されます。Red Hat Software Collections バージョンの MariaDB の場合、ソースデータディレクトリーは /var/opt/rh/<collection_name>/lib/mysql/ です (/opt/rh/mariadb55/root/var/lib/mysql/ データディレクトリーを使用する mariadb55 を除く)。

重要

アップグレードを実行する前に、「MariaDB データのバックアップ」の説明に従って、MariaDB データベースに保存されている全データのバックアップを作成します。

インプレースアップグレードを実行する場合は、root で以下を行います。

Red Hat Enterprise Linux 8 システムに mariadb-server パッケージがインストールされていることを確認します。
```
~]# yum install mariadb-server
```
データのコピー時に、mariadb デーモンがソースおよびターゲットのシステムで実行していないことを確認します。
```
~]# systemctl stop mariadb.service
```
ソースの場所から、Red Hat Enterprise Linux 8 ターゲットシステムの /var/lib/mysql/ ディレクトリーにデータをコピーします。
ターゲットシステムでコピーされたファイルに適切なパーミッションと SELinux コンテキストを設定します。
```
~]# restorecon -vr /var/lib/mysql
```
ターゲットシステムで、MariaDB サーバーを起動します。
```
~]# systemctl start mariadb.service
```
mysql_upgrade コマンドを実行して、内部テーブルをチェックし、修復します。
```
~]# systemctl mysql_upgrade
```
アップグレードが完了したら、/etc/my.cnf.d/ ディレクトリーのすべての設定ファイルに MariaDB 10.3 の有効なオプションのみが含まれていることを確認してください。

重要

インプレースアップグレードに関連する特定のリスクと既知の問題があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、『MariaDB 10.3 Release Notes』を参照してください。

5.3. Red Hat Enterprise Linux 8 で PostgreSQL の使用

5.3.1. Red Hat Enterprise Linux 8 の PostgreSQL の概要

PostgreSQL サーバーは、SQL 言語をベースにした、オープンソースの堅牢かつ拡張性に優れたデータベースサーバーです。豊富なデータセットと、多数の同時ユーザーを管理できるオブジェクト関係データベースシステムを提供します。このような理由から、PostgreSQL サーバーは、大量のデータを管理するためにクラスターで使用できます。

PostgreSQL サーバーには、データの整合性の確保、耐障害性のある環境の構築、またはアプリケーションの構築を行うための機能が含まれます。データベースを再コンパイルすることなく、ユーザー独自のデータ型、カスタム関数、またはさまざまなプログラミング言語のコードでデータベースを拡張できます。

本セクションは、「PostgreSQL のインストール」で、PostgreSQL をインストールする方法を説明します。さらに「PostgreSQL 10.0 への移行」で、Red Hat Enterprise Linux 7 のデフォルトバージョンの PostgreSQL 9.2 から、Red Hat Enterprise Linux 8 のデフォルトバージョンの PostgreSQL 10.0 へ移行する方法を説明します。移行の前提条件に、データバックアップの実行があります。

5.3.2. PostgreSQL のインストール

RHEL 8 では、PostgreSQL サーバーは、2 つのストリームから提供される 10 と 9.6 の 2 つのバージョンで利用できます。本セクションでは、デフォルトストリームの PostgreSQL 10 を使用することを前提としています。ストリームの変更は、『ユーザー領域コンポーネントのインストール、管理、および削除』を参照してください。

注記

設計上、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできません。たとえば、postgresql モジュールから利用可能なストリーム (10 (デフォルト) または 9.6) から 1 つ選択する必要があります。Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 用の Red Hat Software Collections では、コンポーネントの同時インストールが可能です。Red Hat Enterprise Linux 8 では、コンテナーで異なるバージョンのデータベースサーバーを使用できます。

PostgreSQL をインストールするには、以下の手順に従います。

Application Stream リポジトリーで利用可能な postgresql-server パッケージが、必要なサーバーにインストールされていることを確認します。
```
~]# yum install postgresql-server
```
データディレクトリーを初期化します。
```
postgresql-setup --initdb
```
postgresql サービスを開始します。
```
~]# systemctl start postgresql.service
```
postgresql サービスが、システムの起動時に起動するようにします。
```
~]# systemctl enable postgresql.service
```

5.3.3. PostgreSQL の設定

PostgreSQL 設定を変更するには、/var/lib/pgsql/data/postgresql.conf ファイルを使用します。その後、postgresql サービスを再起動して、変更を有効にします。

systemctl restart postgresql.service

/var/lib/pgsql/data/postgresql.conf とは別に、PostgreSQL 設定を変更する他のファイルが存在します。

postgresql.auto.conf
pg_ident.conf
pg_hba.conf

postgresql.auto.conf ファイルは、/var/lib/pgsql/data/postgresql.conf と同様の基本的な PostgreSQL 設定を保持します。ただし、このファイルはサーバーの制御下にあります。これは、ALTER SYSTEM クエリーにより編集され、手動で編集することはできません。

pg_ident.conf ファイルは、外部の認証メカニズムから postgresql ユーザー ID へのユーザー ID のマッピングに使用されます。

pg_hba.conf ファイルは、PostgreSQL データベースに対する詳細なユーザー権限を設定するのに使用されます。

5.3.3.1. データベースクラスターの初期化

PostgreSQL データベースでは、すべてのデータはデータベースクラスターと呼ばれる 1 つのディレクトリーに保存されます。データの保存場所は選択できますが、Red Hat では、デフォルトの /var/lib/pgsql/data ディレクトリーにデータを保存することを推奨します。

このデータディレクトリーを初期化するには、次のコマンドを実行します。

postgresql-setup --initdb

5.3.4. PostgreSQL データのバックアップ

PostgreSQL データをバックアップするには、以下のいずれかの方法を使用します。

SQL ダンプ
ファイルシステムレベルのバックアップ
継続的アーカイブ

5.3.4.1. SQL ダンプを使用した PostgreSQL データのバックアップ

5.3.4.1.1. SQL ダンプの実行

SQL ダンプの方法は、SQL コマンドを使用したファイルの生成に基づいています。このファイルがデータベースサーバーにアップロードされると、ダンプ時と同じ状態でデータベースが再作成されます。SQL ダンプは、PostgreSQL クライアントアプリケーションである pg_dump ユーティリティーで保証されます。pg_dump コマンドの基本的な使用方法は、コマンドが結果を標準出力に書き込むことです。

pg_dump dbname > dumpfile

作成される SQL ファイルは、テキスト形式またはその他の異なる形式のいずれかになります。これにより並列処理が可能になり、オブジェクトの復元をより詳細に制御できます。

データベースにアクセスできる任意のリモートホストから、SQL ダンプを実行できます。pg_dump ユーティリティーは特殊な権限では機能しませんが、バックアップを作成するすべてのテーブルに対する読み取りアクセスが必要です。データベース全体のバックアップを作成するには、データベースのスーパーユーザーで実行する必要があります。

pg_dump が接続するデータベースサーバーを指定するには、以下のコマンドラインオプションを使用します。

ホストを定義する -h オプション。
デフォルトのホストは、ローカルホストか、PGHOST 環境変数で指定されているものです。
ポートを定義する -p オプション。
デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。

注記

pg_dump は、1 つのデータベースのみをダンプすることに注意してください。その情報はクラスター全体にあるため、ロールやテーブル空間に関する情報はダンプされません。

指定クラスターの各データベースのバックアップを作成し、ロールやテーブル空間の定義など、クラスター全体のデータを保持するには、pg_dumpall コマンドを使用します。

pg_dumpall > dumpfile

5.3.4.1.2. SQL ダンプからのデータベースの復元

SQL ダンプからデータベースを復元するには、次を行います。

新しいデータベース (dbname) を作成します。
```
createdb dbname
```
ダンプされたデータベースのオブジェクトを所有するか、オブジェクトに対する権限が許可されたユーザーがすべて存在していることを確認してください。
このようなユーザーが存在しない場合、復元は元の所有権と権限でオブジェクトの再作成に失敗します。
psql ユーティリティーを実行して、pg_dump ユーティリティーが作成したテキストファイルのダンプを復元します。
```
psql dbname < dumpfile
```

ここでの dumpfile は、pg_dump コマンドの出力になります。

非テキストファイルのダンプを復元する場合は、pg_restore ユーティリティーを使用します。

pg_restore non-plain-text-file

5.3.4.1.2.1. 別のサーバーでのデータベースの復元

pg_dump および psql はパイプに対する読み書きが可能であるため、あるサーバーから別のサーバーにデータベースを直接ダンプできます。

データベースを、サーバーから別のサーバーにダンプするには、以下のコマンドを実行します。

pg_dump -h host1 dbname | psql -h host2 dbname

5.3.4.1.2.2. 復元中の SQL エラーの処理

デフォルトでは、SQL エラーが発生すると、psql の実行が継続します。その結果、データベースは部分的にのみ復元されます。

このデフォルトの動作を変更する場合は、以下のいずれかの方法を使用します。

ON_ERROR_STOP 変数を設定して SQL エラーが発生した場合は、終了ステータスが 3 で psql を終了します。
```
psql --set ON_ERROR_STOP=on dbname < dumpfile
```
以下のいずれかのオプションで psql を使用して、復元が完全に完了またはキャンセルされるようにダンプ全体を 1 つのトランザクションとして復元することを指定します。
```
psql -1
```
または
```
psql --single-transaction
```
この方法を使用する場合は、多少のエラーでも、すでに何時間も実行している復元操作をキャンセルできます。

5.3.4.1.3. SQL ダンプの長所と短所

SQL ダンプには、他の PostgreSQL バックアップ方法と比較して、以下の長所があります。

SQL ダンプは、サーバーのバージョン固有ではない唯一の PostgreSQL バックアップメソッドです。pg_dump ユーティリティーの出力は、PostgreSQL の後続のバージョンに再読み込みできます。これは、ファイルシステムレベルのバックアップ、または継続的なアーカイブにはできません。
SQL ダンプは、32 ビットサーバーから 64 ビットサーバーへなど、異なるアーキテクチャーにデータベースを転送する際に有効な唯一の方法です。
SQL ダンプは、内部的に一貫性のあるダンプを提供します。ダンプは、pg_dump の実行開始時のデータベースのスナップショットを表します。
pg_dump ユーティリティーは、実行中のデータベースの他の操作をブロックしません。

SQL ダンプの短所は、ファイルシステムレベルのバックアップと比較して時間がかかることです。

5.3.4.1.4. 関連情報

SQL ダンプの詳細は、PostgreSQL 10 ドキュメンテーションを参照してください。

5.3.4.2. ファイルシステムレベルのバックアップを使用した PostgreSQL データのバックアップ

5.3.4.2.1. ファイルシステムレベルのバックアップの実行

ファイルシステムレベルのバックアップを作成するには、PostgreSQL がデータベースのデータを保存するために使用するファイルを別の場所にコピーする必要があります。

データベースクラスターの場所を選択し、「データベースクラスターの初期化」の説明に従ってこのクラスターを初期化します。
postgresql サービスを停止します。
```
~]# systemctl stop postgresql.service
```
ファイルシステムをバックアップする場合は、以下のような方法を使用します。
```
tar -cf backup.tar /var/lib/pgsql/data
```
postgresql サービスを起動します。
```
~]# systemctl start postgresql.service
```

5.3.4.2.2. ファイルシステムレベルのバックアップの長所と短所

ファイルシステムレベルのバックアップは、他の PostgreSQL バックアップ方法と比較して、以下の利点があります。

ファイルシステムレベルのバックアップは、通常、SQL ダンプよりも高速です。

ファイルシステムレベルのバックアップは、他の PostgreSQL バックアップ方法と比較して、以下の短所があります。

バックアップはアーキテクチャー固有で、Red Hat Enterprise Linux 7 固有のものです。アップグレードが正常に完了しなかった場合は、Red Hat Enterprise Linux 7 に戻るためのバックアップとしてのみ使用できますが、PostgreSQL 10.0 では使用できません。
データバックアップまたはデータ復元を行う前に、データベースサーバーをシャットダウンする必要があります。
特定の個別ファイルまたはテーブルのバックアップと復元はできません。ファイルシステムのバックアップは、データベースクラスター全体の完全バックアップと復元でのみ機能します。

5.3.4.2.3. ファイルシステムレベルのバックアップの代替アプローチ

ファイルシステムのバックアップの代替方法は、以下のとおりです。

データディレクトリーの一貫したスナップショット
rsync ユーティリティー

5.3.4.2.4. 関連情報

ファイルシステムレベルのバックアップの詳細は、PostgreSQL 10 ドキュメントを参照してください。

5.3.4.3. 継続的にアーカイブして PostgreSQL データのバックアップを作成

5.3.4.3.1. 継続的なアーカイブの概要

PostgreSQL は、データベースのデータファイルに対するすべての変更を、クラスターのデータディレクトリーの pg_wal/ サブディレクトリーで利用可能なログ先行書き込み (WAL) ファイルに記録します。このログは、主にクラッシュからの復元を目的としています。クラッシュ後、最後のチェックポイント以降に作成されたログエントリーを使用して、データベースの整合性まで復元できます。

オンラインバックアップ とも呼ばれる継続的なアーカイブ方法は、WAL ファイルとファイルシステムレベルのバックアップを組み合わせたものです。データベース復元が必要な場合は、ファイルシステムのバックアップからデータベースを復元してから、バックアップを作成した WAL ファイルからログを再生して、システムを現在の状態にすることができます。

このバックアップ方法には、少なくともバックアップの開始時刻まで戻る、アーカイブされた WAL ファイルの連続シーケンスが必要です。

継続的なアーカイブバックアップ方式の使用を開始する場合は、最初のベースバックアップを行う前に、WAL ファイルのアーカイブ手順を設定してテストしてください。

注記

pg_dump および pg_dumpall ダンプは、継続的にアーカイブするバックアップソリューションの一部として使用することができません。このダンプは、ファイルシステムレベルのバックアップではなく、論理バックアップを作成します。このため、WAL の再生で使用される十分な情報は含まれていません。

5.3.4.3.2. 継続的なアーカイブのバックアップの実行

継続的なアーカイブ方式を使用してデータベースのバックアップと復元を実行するには、以下の手順に従います。

「ベースバックアップの作成」
「継続的なアーカイブバックアップを使用したデータベースの復元」

5.3.4.3.2.1. ベースバックアップの作成

ベースバックアップを実行するには、pg_basebackup ツールを使用します。このツールは、個別のファイルまたは tar アーカイブの形式でベースバックアップを作成できます。

ベースバックアップを使用するには、ファイルシステムのバックアップ中およびバックアップ後に生成されたすべての WAL セグメントファイルを維持する必要があります。ベースバックアッププロセスでは、WAL アーカイブ領域に保存され、ファイルシステムのバックアップに必要な最初の WAL セグメントファイルの後に名前が付けられるバックアップ履歴ファイルが作成されます。バックアップ中に使用するファイルシステムのバックアップおよび WAL セグメントファイルをバックアップ履歴ファイルで安全にアーカイブすると、ファイルシステムバックアップの復元が必要なくなるため、アーカイブされたすべての WAL セグメントを、数値的に小さい名前で削除できます。ただし、データの復元が可能であることを確実にするため、複数のバックアップセットを維持することを検討してください。

バックアップ履歴ファイルは小さなテキストファイルで、pg_basebackup に付与したラベル文字列、開始時間および終了時間、およびバックアップの WAL セグメントが含まれます。ラベル文字列を使用して関連するダンプファイルを特定した場合に、どのダンプファイルを復元するかを確認するには、アーカイブされた履歴ファイルで十分となります。

継続的にアーカイブする方法では、アーカイブされた WAL ファイルをすべて、最後のベースバックアップに戻す必要があります。したがって、ベースバックアップの理想的な頻度は、以下に依存します。

アーカイブされた WAL ファイルで利用可能なストレージボリューム。
復元が必要な場合の、データ復元の最大許容期間。
最後のバックアップ以降の長い期間では、より多くの WAL セグメントが再生されるため、復元には時間がかかります。

ベースバックアップの作成の詳細は、PostgreSQL 10 ドキュメンテーションを参照してください。

5.3.4.3.2.2. 継続的なアーカイブバックアップを使用したデータベースの復元

継続的にバックアップを作成してデータベースを復元するには、以下を行います。

サーバーを停止します。
```
~]# systemctl stop postgresql.service
```
必要なデータを一時的な場所にコピーします。
必要に応じて、クラスターデータのディレクトリー全体と、すべてのテーブル空間をコピーします。既存データベースのコピーを 2 つ保持するには、システムに十分な空き領域が必要になることに注意してください。
十分な容量がない場合は、クラスターの pg_wal ディレクトリーの内容を保存します。これには、システムがダウンする前にアーカイブされなかったログが含まれます。
クラスターデータディレクトリー、および使用しているテーブル空間のルートディレクトリー下の既存ファイルおよびサブディレクトリーをすべて削除します。
ファイルシステムのバックアップからデータベースファイルを復元します。
以下の点を確認してください。
- ファイルは、正しい所有権 (root ではなくデータベースシステムのユーザー) で復元されます。
- ファイルは、正しい権限で復元されます。
- pg_tblspc/ サブディレクトリーのシンボリックリンクが正しく復元されます。
pg_wal/ サブディレクトリーにあるファイルをすべて削除します。
このファイルは、ファイルシステムのバックアップから作成されるため、非推奨になりました。pg_wal/ をアーカイブしていない場合は、適切な権限で再作成します。
手順 2 で保存した未アーカイブの WAL セグメントファイルがある場合は、pg_wal/ にコピーします。
クラスターデータディレクトリーに、recovery.conf 復元コマンドファイルを作成します。
サーバーを起動します。
```
~]# systemctl start postgresql.service
```
サーバーは復元モードに入り、引き続き必要なアーカイブファイル (WAL) を読み込みます。
外部エラーにより復元が終了した場合は、サーバーを再起動するだけで復元が続行します。復元プロセスが完了すると、サーバーは recovery.conf の名前を recovery.done に変更し、サーバーが通常のデータベース操作を開始する際に、誤って復元モードに再度入らないようにします。
データベースのコンテンツを確認して、データベースが必要な状態に復元されたことを確認します。
データベースが必要な状態に復元されていない場合は、手順 1 に戻ります。データベースが必要な状態に復元された場合は、pg_hba.conf ファイルを通常に復元して接続できるようにします。

継続バックアップを使用した復元の詳細は、PostgreSQL 10 のドキュメンテーションを参照してください。

5.3.4.3.3. 継続的なアーカイブの長所と短所

継続的なアーカイブは、PostgreSQL のその他のバックアップ方法と比較して、以下の利点があります。

継続的バックアップ方式では、バックアップ内の内部不整合がログ再生により修正されるため、完全に一貫性のないファイルシステムのバックアップを使用できます。ファイルシステムのスナップショットは必要ありません。tar または同様のアーカイブツールで十分です。
継続的にバックアップを行うには、継続的に WAL ファイルをアーカイブします。これは、ログ再生用の WAL ファイルの順序が無限に長くなる可能性があるためです。これは、特に大規模なデータベースで有用です。
継続的バックアップは、特定の時点への復旧 (ポイントインタイムリカバリー) をサポートします。WAL エントリーを最後まで再生する必要はありません。再生はいつでも停止でき、ベースバックアップを作成してから、データベースをいつでもその状態に復元できます。
一連の WAL ファイルが同じベースのバックアップファイルで読み込まれた別のマシンが継続的に利用可能である場合は、任意の時点で、データベースで現在に一番近いコピーで、他のマシンを復元できます。

継続的なアーカイブには、その他の PostgreSQL バックアップ方法と比較して、以下の短所があります。

継続バックアップ方法は、サブセットではなく、データベースクラスター全体の復元のみをサポートします。
継続的にバックアップするには、大きなアーカイブストレージが必要です。

5.3.4.3.4. 関連情報

継続的なアーカイブ方法の詳細は、PostgreSQL 10 ドキュメンテーションを参照してください。

5.3.5. PostgreSQL 10.0 への移行

Red Hat Enterprise Linux 7 には、PostgreSQL 9.2 が、PostgreSQL サーバーのデフォルトバージョンとして含まれます。また、PostgreSQL の複数のバージョンは、Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 の Software Collections として提供されます。Red Hat Enterprise Linux 8 は、PostgreSQL 10.0 および PostgreSQL 9.6 を提供します。

本セクションでは、Red Hat Enterprise Linux 7 システムバージョンの Postgreql 9.2 から、デフォルトのストリームで提供される Red Hat Enterprise Linux 8 バージョンの PostgreSQL 10 に移行することを前提としています。

Red Hat Enterprise Linux 7 の PostgreSQL は、Red Hat Enterprise Linux 8 で、データベースファイルの移行パスを 2 つ使用できます。

pg_upgrade ツールを使用した高速アップグレード
ダンプおよび復元のアップグレード

ダンプおよび復元のプロセスよりも高速なアップグレード方法を使用してください。

拡張機能の plpython または plpython2 を使用した ba * Cross-architecture upgrades * システム

+ Red Hat Enterprise Linux 8 のアプリケーションストリームリポジトリーには postgresql-plpython3 パッケージのみが含まれ、postgresql-plpython2 パッケージは含まれません。

高速アップグレードは、PostgreSQLの Red Hat Software Collections バージョンからの移行ではサポートされません。

PostgreSQL 9.2 から PostgreSQL 10.0 への移行の前提条件として、PostgreSQL データベースのバックアップを作成します。

データベースをダンプし、SQL ファイルのバックアップを実行することは、ダンプおよび復元プロセスに必要な部分です。ただし、高速アップグレードも実行する場合は、これを実行することが推奨されます。

5.3.5.1. pg_upgrade ツールを使用した高速アップグレード

高速アップグレードでは、バイナリーデータファイルを /var/lib/pgsql/data/ ディレクトリーにコピーし、pg_upgrade ツールを使用する必要があります。この方法は、Red Hat Enterprise Linux 7 バージョンの PostgreSQL 9.2 からデータを移行するのに使用できます。デフォルトでは、すべてのデータが、Red Hat Enterprise Linux 7 および Red Hat Enterprise Linux 8 の両方の /var/lib/pgsql/data/ ディレクトリーに保存されます。Red Hat Software Collections バージョンの PostgreSQL からの移行には、「ダンプおよび復元のアップグレード」を使用します。

重要

アップグレードを実行する前に、PostgreSQL データベースに保存されているすべてのデータのバックアップを作成します。

高速アップグレードを実行するには、以下の手順を使用します。

RHEL 8 システムで、postgresql-server パッケージおよび postgresql-upgrade パッケージをインストールします。
```
~]# yum install postgresql-server postgresql-upgrade
```
必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用している場合は、その 2 つのバージョンを RHEL 8 システムにインストールし、PostgreSQL 9.2 (postgresql-upgrade パッケージでインストール) および PostgreSQL 10 (postgresql-server パッケージでインストール) の両方に対してコンパイルします。サードパーティーの PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、postgresql-devel パッケージと postgresql-upgrade-devel パッケージの両方に対してビルドしてください。
以下の項目を確認します。
- 基本設定 - RHEL 8 システムで、サーバーがデフォルトの /var/lib/pgsql/data ディレクトリーを使用し、データベースが正しく初期化され、有効になっているかどうかを確認します。さらに、データファイルは、/usr/lib/systemd/system/postgresql.service ファイルに記載されているパスと同じパスに保存する必要があります。
- PostgreSQL サーバー - システムは複数の PostgreSQL サーバーを実行できます。これらのすべてのサーバーのデータディレクトリーが独立して処理されていることを確認してください。
- PostgreSQL サーバーモジュール - RHEL 7 で使用されていた PostgreSQL サーバーモジュールも、RHEL 8 システムにインストールされていることを確認してください。プラグインは、/usr/lib64/pgsql/ ディレクトリー (32 ビットシステムの /usr/lib/pgsql/ ディレクトリー) にインストールされます。
データのコピー時に、postgresql サービスがソースおよびターゲットのシステムで稼働していないことを確認します。
```
~]# systemctl stop postgresql.service
```
データベースファイルをソースの場所から RHEL 8 システムの /var/lib/pgsql/data/ ディレクトリーにコピーします。
PostgreSQL ユーザーで以下のコマンドを実行して、アップグレードプロセスを実行します。
```
~]$ /bin/postgresql-setup --upgrade
```
これでバックグラウンドで pg_upgrade プロセスが開始します。
障害が発生すると、postgresql-setup は通知のエラーメッセージを提供します。
/var/lib/pgsql/data-old から新規クラスターに、以前の設定をコピーします。
高速アップグレードは、新しいデータスタックで以前の設定を再利用せず、設定がゼロから生成されることに注意してください。古い設定と新しい設定を手動で組み合わせたい場合は、データディレクトリーの *.conf ファイルを使用します。
新しい PostgreSQL 10 サーバーを起動します。
```
~]# systemctl start postgresql.service
```
PostgreSQL ホームディレクトリーにある analyze_new_cluster.sh スクリプトを実行します。
```
su postgres -c '~/analyze_new_cluster.sh'
```
システムの起動時に PostgreSQL 10 サーバーを自動的に起動させる場合は、以下を実行します。
```
~]# systemctl enable postgresql.service
```

5.3.5.2. ダンプおよび復元のアップグレード

ダンプおよび復元のアップグレードを使用する場合は、すべてのデータベースのコンテンツを SQL ファイルのダンプファイルにダンプする必要があります。

ダンプおよび復元のアップグレードは高速なアップグレード方法よりも低速であり、生成された SQL ファイルで手動修正が必要になる場合があります。

この方法を使用すると、以下からデータを移行できます。

Red Hat Enterprise Linux7 バージョンの PostgreSQL 9.2
Red Hat Software Collections のバージョンは、以下の通りです。
- PostgreSQL 9.2 (サポート対象外になりました)
- PostgreSQL 9.4 (サポート対象外になりました)
- PostgreSQL 9.6
- PostgreSQL 10

Red Hat Enterprise Linux 7 および Red Hat Enterprise Linux 8 のシステムでは、PostgreSQL データは、デフォルトで /var/lib/pgsql/data/ ディレクトリーに保存されます。Red Hat Software Collections バージョンの PostgreSQLの場合、デフォルトのデータディレクトリーは /var/opt/rh/collection_name/lib/pgsql/data/ です (/opt/rh/postgresql92/root/var/lib/pgsql/data/ ディレクトリーを使用する postgresql92 を除く)。

ダンプおよび復元のアップグレードを実行するには、ユーザーを rootに変更し、以下の手順に従って、Red Hat Enterprise Linux 7 のベースシステムの PostgreSQL 9.2 バージョンから、Red Hat Enterprise Linux 8 のデフォルトバージョンの PostgreSQL 10 への移行を行います。

RHEL 7 システムで PostgreSQL 9.2 サーバーを起動します。
```
~]# systemctl start postgresql.service
```
RHEL 7 システムで、すべてのデータベースのコンテンツを pgdump_file.sql ファイルにダンプします。
```
su - postgres -c "pg_dumpall > ~/pgdump_file.sql"
```
データベースが正しくダンプされたことを確認します。
```
su - postgres -c 'less "$HOME/pgdump_file.sql"'
```
これにより、ダンプされた sql ファイルのパスが /var/lib/pgsql/pgdump_file.sql に表示されます。
RHEL 8 システムで、postgresql-server パッケージをインストールします。
```
~]# yum install postgresql-server
```
必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用している場合は、RHEL 8 システムにもインストールしてください。サードパーティーの PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、postgresql-devel パッケージに対してビルドします。
RHEL 8 システムで、PostgreSQL 10.0 サーバーのデータディレクトリーを初期化します。
```
~]# postgresql-setup --initdb
```
RHEL 8 システムで、pgdump_file.sql を PostgreSQL ホームディレクトリーにコピーし、ファイルが正しくコピーされたことを確認します。
```
su - postgres -c 'test -e "$HOME/pgdump_file.sql" && echo exists'
```
RHEL 7 システムから設定ファイルをコピーします。
```
su - postgres -c 'ls -1 $PGDATA/*.conf'
```
コピーされる設定ファイルは、以下のとおりです。
- /var/lib/pgsql/data/pg_hba.conf
- /var/lib/pgsql/data/pg_ident.conf
- /var/lib/pgsql/data/postgresql.conf
RHEL 8 システムで、新規の PostgreSQL 10 サーバーを起動します。
```
~]# systemctl start postgresql.service
```
RHEL 8 システムで、ダンプされた sql ファイルからデータをインポートします。
```
su - postgres -c 'psql -f ~/pgdump_file.sql postgres'
```

注記

Red Hat Software Collections バージョンの PostgreSQL からアップグレードする場合は、scl enable collection_name が含まれるようにコマンドを調整します。たとえば、rh-postgresql96 Software Collection からデータをダンプする場合は、以下のコマンドを使用します。

su - postgres -c 'scl enable rh-postgresql96 "pg_dumpall > ~/pgdump_file.sql"'

第6章印刷の設定

Red Hat Enterprise Linux 8 での印刷は、Common Unix Print System (CUPS) に基づいています。

本ガイドでは、CUPS サーバーとして動作できるようにマシンを設定する方法を説明します。

6.1. cups サービスのアクティブ化

本セクションでは、システムの cups サービスを有効にする方法を説明します。

前提条件

Appstream リポジトリーで利用可能な cups パッケージがインストールされている。
```
~]# yum install cups
```

手順

cups サービスを起動します。
```
~]# systemctl start cups
```
システムの起動時に、cups サービスが自動的に起動するように設定します。
```
~]# systemctl enable cups
```
必要に応じて、cups サービスのステータスを確認します。
```
~]$ systemctl status cups
```

6.2. 印刷設定ツール

印刷に関するさまざまなタスクを行うために、以下のいずれかのツールを選択できます。

CUPS の Web UI (ユーザーインターフェース)
GNOME Control Center

警告

Red Hat Enterprise Linux 7 で使用されていた 印刷設定 構成ツールは利用できなくなりました。

これらのツールを使用して達成できるタスクには、以下が含まれます。

新しいプリンターの追加および設定
プリンター設定の維持
プリンタークラスの管理

本ガイドでは、CUPS Web ユーザーインターフェース (UI) での印刷のみを説明します。GNOME Control Center を使用して印刷する場合は、GUI が利用可能である必要があります。GNOME Control Center を使用した印刷の詳細は、『デスクトップからの RHEL システムの管理』を参照してください。

6.3. CUPS Web UI へのアクセスおよび設定

このセクションでは、CUPS Web UI にアクセスする方法と、このインターフェースで印刷を管理できるように設定する方法を説明します。

CUPS Web UI にアクセスするには、以下のコマンドを実行します。

/etc/cups/cupsd.conf ファイルに ポート 631 を設定して、CUPS サーバーがネットワークから接続をリッスンできるようにします。
```
#Listen localhost:631
Port 631
```
/etc/cups/cupsd.conf ファイルに以下を追加して、マシンが CUPS サーバーにアクセスできるようにします。
```
<Location />
Allow from <your_ip_address>
Order allow,deny
</Location>
```
注記
<your_ip_address> を、システムの実際の IP アドレスに置き換えます。
cups.service を再起動します。
```
~]# systemctl restart cups
```
ブラウザーを開き、http://<IP_address_of_the_CUPS_server>:631/ に移動します。

Administration メニュー以外のすべてのメニューが利用できるようになりました。

Administration メニューをクリックすると、 Forbidden メッセージが表示されます。

Administration メニューにアクセスするには、「CUPS Web UI への管理アクセスの取得」の手順に従います。

6.3.1. CUPS Web UI への管理アクセスの取得

本セクションでは、CUPS Web UI への管理アクセスを取得する方法を説明します。

手順

CUPS Web UI の Administation メニューにアクセスするには、/etc/cups/cupsd.conf ファイルに以下を追加します。
```
<Location /admin>
Allow from <your_ip_address>
Order allow,deny
</Location>
```
注記
<your_ip_address> を、システムの実際の IP アドレスに置き換えます。
CUPS Web UI で設定ファイルにアクセスするには、/etc/cups/cupsd.conf ファイルに以下の内容を含めます。
```
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
Allow from <your_ip_address>
Order allow,deny
</Location>
```
注記
<your_ip_address> を、システムの実際の IP アドレスに置き換えます。
CUPS Web UI でログファイルにアクセスするには、/etc/cups/cupsd.conf ファイルに以下の内容を追加します。
```
<Location /admin/log>
AuthType Default
Require user @SYSTEM
Allow from <your_ip_address>
Order allow,deny
</Location>
```
注記
<your_ip_address> を、システムの実際の IP アドレスに置き換えます。
CUPS Web UI で認証された要求の暗号化の使用を指定するには、/etc/cups/cupsd.conf ファイルに DefaultEncryption を追加します。
```
DefaultEncryption IfRequested
```
この設定では、管理 メニューにアクセスする際に、プリンターの追加を許可されたユーザーのユーザー名を入力する認証ウィンドウが表示されます。ただし、DefaultEncryption を設定する方法は他にもあります。詳細は、man ページの cupsd.conf を参照してください。
cups サービスを再起動します。
```
~]# systemctl restart cups
```
警告
cups サービスを再起動しないと、/etc/cups/cupsd.conf の変更は適用されません。その結果、CUPS Web UI への管理アクセスは取得できません。

6.4. CUPS Web UI でのプリンターの追加

本セクションでは、CUPS Web ユーザーインターフェース を使用して新しいプリンターを追加する方法を説明します。

前提条件

「CUPS Web UI への管理アクセスの取得」の説明に従って、CUPS Web UI への管理アクセスを取得している。

手順

「CUPS Web UI へのアクセスおよび設定」の説明に従って、CUPS Web UI を起動します。
Adding Printers and Classes、Add printer の順に選択します。
ユーザー名とパスワードを使用して認証します。
重要
CUPS Web UI を使用して新しいプリンターを追加できるようにするには、次のいずれかのユーザーで認証を行う必要があります。
- スーパーユーザー
- sudo コマンドが提供する管理アクセスを持つユーザー (/etc/sudoers に記載されているユーザー)
- /etc/group 内の printadmin グループに属するすべてのユーザー
ローカルプリンターが接続されている場合、または CUPS が利用可能なネットワークプリンターを検出した場合は、プリンターを選択します。ローカルプリンターまたはネットワークプリンターが使用できない場合は、Other Network Printers からいずれかのプリンタータイプ (例: APP Socket/HP Jet direct) を選択し、プリンターの IP アドレスを入力し、Continue をクリックします。
上記のように APP Socket/HP Jet direct などを選択した場合は、プリンターの IP アドレスを入力し、Continue をクリックします。
名前、説明、場所など、新しいプリンターに関する詳細を追加できます。ネットワーク経由でプリンター共有を設定するには、以下で示すように、Share This Printer を使用します。
プリンターの製造元を選択し、Continue をクリックします。
または、下部の Browse… をクリックして、プリンターのドライバーとして使用する PPD (Postscript Printer Description) ファイルを指定することもできます。
プリンターのモデルを選択し、Add Printer をクリックします。
プリンターを追加したら、次のウィンドウでデフォルトの印刷オプションを設定できます。

Set Default Options をクリックすると、新しいプリンターが正常に追加されたことを確認するメッセージが表示されます。

6.5. CUPS Web UI でのプリンターの設定

本セクションでは、新しいプリンターの設定方法と、CUPS Web UI を使用してプリンターの設定を維持する方法を説明します。

前提条件

「CUPS Web UI への管理アクセスの取得」の説明に従って、CUPS Web UI への管理アクセスを取得している。

手順

設定可能なプリンターを表示するには、Printers メニューをクリックします。
構成するプリンターを選択します。
利用可能なメニューのいずれかを使用して、選択したタスクを実行します。
- メンテナンスタスクを行うために、メンテナンス を選択します。
- 管理タスクの Administration に移動します。
- また、Show Completed Jobs ボタンまたは Show All Jobs ボタンをクリックして、完了した印刷ジョブまたはアクティブなすべての印刷ジョブを確認することもできます。

6.6. CUPS Web UI を使用したテストページの印刷

このセクションでは、テストページを印刷して、プリンターが正常に機能することを確認する方法を説明します。

以下のいずれかの条件が満たされる場合は、テストページを出力できます。

プリンターが設定されている。
プリンターの設定が変更している。

前提条件

「CUPS Web UI への管理アクセスの取得」の説明に従って、CUPS Web UI への管理アクセスを取得している。

手順

Printers メニューに移動し、 Maintenance → Print Test Page をクリックします。

6.7. CUPS Web UI を使用した印刷オプションの設定

本セクションでは、CUPS Web UI で、メディアのサイズと種類、印刷の品質カラーモードなどの一般的な印刷オプションを設定する方法を説明します。

前提条件

「CUPS Web UI への管理アクセスの取得」の説明に従って、CUPS Web UI への管理アクセスを取得している。

手順

Administration メニューに移動し、Maintenance → Set Default Options をクリックします。
印刷オプションを設定します。

6.8. CUPS ログの使用

6.8.1. CUPS ログの種類

CUPS には、以下のようなログがあります。

エラーログ - エラー、警告、およびデバッグのメッセージを保存する
アクセスログ - CUPS クライアントおよび Web UI にアクセスした回数を示すメッセージを保存する
ページログ - 各プリントジョブに出力されるページの合計数を示すメッセージを保存する

Red Hat Enterprise Linux 8 では、その他のプログラムのログと一緒に、3 つのすべてのタイプが、systemd-journald のログに集中的に記録されます。

警告

Red Hat Enterprise Linux 8 では、ログが、Red Hat Enterprise Linux 7 で使用されていた /var/log/cups ディレクトリーの特定のファイルに保存されなくなりました。

6.8.2. CUPS ログへのアクセス

本セクションでは、以下のアクセス方法を説明します。

すべての CUPS ログ
特定の印刷ジョブの CUPS ログ
特定の時間枠内の CUPS ログ

6.8.2.1. すべての CUPS ログへのアクセス

手順

systemd-semanaged からの CUPS ログにフィルターをかけます。

$ journalctl -u cups

6.8.2.2. 特定の印刷ジョブの CUPS ログへアクセス

手順

特定の印刷ジョブのログにフィルターをかけます。

$ journalctl -u cups JID=N

ここで、N は、印刷ジョブの番号になります。

6.8.2.3. 特定の時間枠による CUPS ログへのアクセス

手順

指定した時間枠内でログにフィルターをかけます。

$ journalctl -u cups --since=YYYY-MM-DD --until=YYYY-MM-DD

ここで、YYYY は年、MM は月、DD は日です。

6.8.3. CUPS ログの場所の設定

本セクションでは、CUPS ログの場所を設定する方法を説明します。

Red Hat Enterprise Linux 8 では、CUPS ログはデフォルトで systemd-semanaged に記録されます。これは、/etc/cups/cups-files.conf ファイルの以下のデフォルト設定で保証されます。

ErrorLog syslog

重要

Red Hat では、CUPS ログのデフォルトの場所を維持することを推奨しています。

ログを別の場所に送信する場合は、/etc/cups/cups-files.conf ファイル内の設定を以下のように変更する必要があります。

ErrorLog <your_required_location>

警告

CUPS ログのデフォルトの場所を変更すると、予期しない動作や SELinux の問題が発生する可能性があります。

コンテキスト: configuring-printing

コンテキスト：Deploying-different-types-of-servers

法律上の通知

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat Training

さまざまな種類のサーバーのデプロイメント

Red Hat Enterprise Linux 8 にさまざまな種類のサーバーをデプロイするためのガイド

Red Hat ドキュメントへのフィードバック (英語のみ)

第1章 Apache HTTP Web サーバーの設定

1.1. Apache HTTP Web サーバーの概要

1.2. Apache HTTP Server への主な変更点

1.3. 設定の更新

1.4. httpd サービスの実行

1.4.1. サービスの起動

1.4.2. サービスの停止

1.4.3. サービスの再起動

1.4.4. サービスステータスの確認

1.5. 設定ファイルの編集

1.6. モジュールの使用

1.6.1. モジュールの読み込み

1.6.2. モジュールの作成

1.7. 仮想ホストの設定

1.8. SSL サーバーの設定

1.8.1. 証明書およびセキュリティーの概要

1.8.2. Web サーバーの証明書およびセキュリティー

1.9. mod_ssl モジュールの有効化

1.9.1. mod_ssl で異なるバージョンの TLS の有効化

1.9.2. TLS 証明書の自動プロビジョニングおよび更新

1.10. 既存の鍵および証明書の使用

1.11. コマンドラインを使用して HTTP 用および HTTPS 用にファイアウォールを設定

1.11.1. コマンドラインを使用した着信 HTTPS および HTTPS のネットワークアクセスの確認

1.12. 関連情報

1.12.1. インストールされているドキュメント

1.12.2. インストール可能なドキュメント

1.12.3. オンラインドキュメント

第2章 Samba をサーバーとして使用

前提条件

2.1. Samba サービス

2.2. testparm ユーティリティーを使用した smb.conf ファイルの検証

手順

2.3. Samba セキュリティーサービス

関連情報

2.4. Samba をスタンドアロンサーバーとして設定

2.4.1. スタンドアロンサーバーのサーバー構成の設定

手順

関連情報

2.4.2. ローカルユーザーアカウントの作成および有効化

前提条件

手順

2.5. Samba をドメインメンバーサーバーとして設定

2.5.1. Samba のドメインへの参加

手順

関連情報

2.5.2. Samba がドメインメンバーとして正しく参加されたことを確認

2.5.2.1. オペレーティングシステムが、ドメインのユーザーアカウントおよびグループを取得できるかどうかの検証

手順

2.5.2.2. AD ドメインユーザーが Kerberos チケットを取得できるかどうかの確認

前提条件

手順

2.5.2.3. 利用可能なドメインの一覧表示

手順

2.5.3. MIT Kerberos 用のローカル承認プラグインの使用

前提条件

手順

関連情報

2.5.4. Samba ID マッピング

2.5.4.1. Samba ID 範囲の計画

2.5.4.2. * デフォルトドメイン

2.5.5. 異なる Samba ID マッピングバックエンド

2.5.5.1. tdb ID マッピングバックエンドの使用

関連情報

2.5.5.2. ad ID マッピングバックエンドの使用

前提条件

手順

関連情報

2.5.5.3. rid ID マッピングバックエンドの使用

rid バックエンドを使用した利点

rid バックエンドを使用した場合の短所

手順

関連情報

2.5.5.4. autorid ID マッピングバックエンドの使用

autorid バックエンドを使用した利点

短所

手順