さまざまな種類のサーバーのデプロイメント
Red Hat Enterprise Linux 8 にさまざまな種類のサーバーをデプロイするためのガイド
概要
オープンソースをより包摂的に
Red Hat は、コード、ドキュメント、および Web プロパティーにおける問題のある用語の修正に努めています。取り組みの開始として、マスター、スレーブ、ブラックリスト、ホワイトリストの 4 つの用語の修正に取り組みます。このため、これらの変更は今後の複数のリリースに対して段階的に実施されます。詳細は、弊社の CTO のメッセージを参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。
特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。
- ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
- マウスカーソルで、コメントを追加する部分を強調表示します。
- そのテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される手順に従ってください。
より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。
- Bugzilla の Web サイトにアクセスします。
- Component で Documentation を選択します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
- Submit Bug をクリックします。
第1章 Apache HTTP Web サーバーの設定
1.1. Apache HTTP Web サーバーの概要
Web サーバー は、Web 経由でクライアントにコンテンツを提供するネットワークサービスです。これは通常 Web ページを指しますが、他のドキュメントも当てはまります。Web サーバーは、ハイパーテキスト転送プロトコル (HTTP) を使用するため、HTTP サーバーとも呼ばれます。
Apache HTTP Server (httpd
) は、Apache Software Foundation が開発したオープンソースの Web サーバーです。
Red Hat Enterprise Linux の以前のリリースからアップグレードする場合は、適切に httpd
サービス設定を更新する必要があります。本セクションでは、新たに追加された機能の一部と、以前の設定ファイルの更新を説明します。
1.1.1. 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_ssl
を使用します。mod_nss
からの移行に関する詳細は、「Apache Web サーバー設定で秘密鍵と証明書を使用できるように 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.1.2. 設定の更新
Red Hat Enterprise Linux 7 で使用されている Apache HTTP Server バージョンから設定ファイルを更新するには、以下のいずれかのオプションを選択します。
-
/etc/sysconfig/httpd
を使用して環境変数を設定する場合は、代わりに systemd ドロップインファイルを作成します。 - サードパーティーのモジュールを使用する場合は、そのモジュールがスレッド化 MPM と互換性があることを確認してください。
- suexec を使用する場合は、ユーザーおよびグループの ID が新しい最小値に合致していることを確認します。
以下のコマンドを使用すると、設定に誤りがないかどうかを確認できます。
# apachectl configtest Syntax OK
1.2. Apache 設定ファイル
httpd
サービスが起動すると、デフォルトでは、表1.2「httpd サービスの設定ファイル」に一覧表示されている場所から設定が読み込まれます。
表1.2 httpd サービスの設定ファイル
パス | 説明 |
---|---|
| 主要設定ファイル。 |
| 主要設定ファイル内に含まれている設定ファイル用の補助ディレクトリー。 |
| Red Hat Enterprise Linux にパッケージ化されたインストール済みの動的モジュールを読み込む設定ファイルの補助ディレクトリー。デフォルト設定では、この設定ファイルが最初に処理されます。 |
デフォルト設定はほとんどの状況に適していますが、その他の設定オプションを使用することもできます。変更を有効にするには、まず Web サーバーを再起動します。httpd
サービスを再起動する方法は、「httpd サービスの管理」を参照してください。
設定に誤りがないことを確認するには、シェルプロンプトで以下のコマンドを実行します。
# apachectl configtest Syntax OK
間違いからの復元を容易にするため、編集する前にオリジナルファイルのコピーを作成します。
1.3. httpd サービスの管理
本セクションでは、httpd
サービスを起動、停止、および再起動するためのホットを説明します。
前提条件
- Apache HTTP Server がインストールされている。
手順
httpd
サービスを起動するには、以下を入力します。# systemctl start httpd
httpd
サービスを停止するには、以下を入力します。# systemctl stop httpd
httpd
サービスを再起動するには、次のコマンドを実行します。# systemctl restart httpd
1.4. シングルインスタンスの Apache HTTP サーバーの設定
本セクションでは、静的 HTML コンテンツを提供するために 1 つのインスタンスの Apache HTTP Server を設定する方法を説明します。
Web サーバーが、サーバーに関連付けられたすべてのドメインに対して同じコンテンツを提供する必要がある場合は、このセクションの手順に従います。異なるドメインに異なるコンテンツを提供する場合は、名前ベースの仮想ホストを設定します。詳細は「Apache 名ベースの仮想ホストの設定」を参照してください。
手順
httpd
パッケージをインストールします。# yum install httpd
ローカルのファイアウォールで TCP ポート
80
を開きます。# firewall-cmd --permanent --add-port=80/tcp # firewall-cmd --reload
httpd
サービスを有効にして起動します。# systemctl enable --now httpd
必要に応じて、HTML ファイルを
/var/www/html/
ディレクトリーに追加します。注記/var/www/html/
にコンテンツを追加する場合は、デフォルトでhttpd
を実行するユーザーがファイルとディレクトリーを読み取る必要があります。コンテンツの所有者は、root
ユーザーおよびグループ
、または管理者別のユーザーまたはグループのいずれかになります。コンテンツの所有者がroot
ユーザーおよびroot
ユーザーグループである場合は、他のユーザーがファイルを読み取る必要があります。すべてのファイルとディレクトリーの SELinux コンテキストは、
である必要があります。これはデフォルトで/var/www
ディレクトリー内のすべてのコンテンツに適用されます。
検証手順
Web ブラウザーで
http://server_IP_or_host_name/
に接続します。/var/www/html/
ディレクトリーが空であるか、index.html
またはindex.htm
ファイルが含まれていない場合は、Apache がRed Hat Enterprise Linux Test Page
を表示します。/var/www/html/
に異なる名前の HTML ファイルが含まれる場合は、http://server_IP_or_host_name/example.html
のように、そのファイルに URL を入力して読み込むことができます。
関連情報
- Apache の設定やお使いの環境へのサービスの適合に関する詳細は、Apache のマニュアルを参照してください。マニュアルのインストールの詳細は、「Apache HTTP Server の手動インストール」 を参照してください。
-
httpd
systemd
サービスの使用または調整の詳細は、httpd.service(8)
man ページを参照してください。
1.5. Apache 名ベースの仮想ホストの設定
名前ベースの仮想ホストは、Apache がサーバーの IP アドレスに解決する異なるドメインに対して異なるコンテンツを提供できるようにします。
本セクションの手順では、example.com
ドメインおよび example.net
ドメインの両方に、別のドキュメントルートディレクトリーを持つ仮想ホストを設定する方法を説明します。両方の仮想ホストが静的 HTML コンテンツに対応します。
前提条件
クライアントおよび Web サーバーは、
example.com
およびexample.net
ドメインを Web サーバーの IP アドレスに解決します。これらのエントリーは DNS サーバーに手動で追加する必要がある点に注意してください。
手順
httpd
パッケージをインストールします。# yum install httpd
/etc/httpd/conf/httpd.conf
ファイルを編集します。example.com
ドメインの以下の仮想ホスト設定を追加します。<VirtualHost *:80> DocumentRoot "/var/www/example.com/" ServerName example.com CustomLog /var/log/httpd/example.com_access.log combined ErrorLog /var/log/httpd/example.com_error.log </VirtualHost>
これらの設定は以下を構成します。
-
<VirtualHost *:80>
ディレクティブのすべての設定は、この仮想ホストに固有のものです。 -
DocumentRoot
は、仮想ホストの Web コンテンツへのパスを設定します。 ServerName
は、この仮想ホストがコンテンツを提供するドメインを設定します。複数のドメインを設定するには、
ServerAlias
パラメーターを設定に追加し、追加のドメインをこのパラメーターのスペースで区切ります。-
CustomLog
は、仮想ホストのアクセスログへのパスを設定します。 ErrorLog
は、仮想ホストのエラーログへのパスを設定します。注記Apache は、
ServerName
パラメーターおよびServerAlias
パラメーターに設定したどのドメインにも一致しない要求にも、設定にある最初の仮想ホストを使用します。これには、サーバーの IP アドレスに送信される要求も含まれます。
-
example.net
ドメイン向けに同様の仮想ホスト設定を追加します。<VirtualHost *:80> DocumentRoot "/var/www/example.net/" ServerName example.net CustomLog /var/log/httpd/example.net_access.log combined ErrorLog /var/log/httpd/example.net_error.log </VirtualHost>
両方の仮想ホストのドキュメントルートを作成します。
# mkdir /var/www/example.com/ # mkdir /var/www/example.net/
/var/www/
内にないDocumentRoot
パラメーターにパスを設定する場合は、両方のドキュメントルートにhttpd_sys_content_t
コンテキストを設定します。# semanage fcontext -a -t httpd_sys_content_t "/srv/example.com(/.*)?" # restorecon -Rv /srv/example.com/ # semanage fcontext -a -t httpd_sys_content_t "/srv/example.net(/.\*)?" # restorecon -Rv /srv/example.net/
以下のコマンドは、
/srv/example.com/
および/srv/example.net/
ディレクトリーにhttpd_sys_content_t
コンテキストを設定します。policycoreutils-python-utils
パッケージをインストールしてrestorecon
コマンドを実行する必要があります。ローカルのファイアウォールで
80
ポートを開きます。# firewall-cmd --permanent --add-port=80/tcp # firewall-cmd --reload
httpd
サービスを有効にして起動します。# systemctl enable --now httpd
検証手順
各仮想ホストのドキュメントルートに異なるサンプルファイルを作成します。
# echo "vHost example.com" > /var/www/example.com/index.html # echo "vHost example.net" > /var/www/example.net/index.html
-
ブラウザーを使用して
http://example.com
に接続します。Web サーバーは、example.com
仮想ホストからのサンプルファイルを表示します。 -
ブラウザーを使用して
http://example.net
に接続します。Web サーバーは、example.net
仮想ホストからのサンプルファイルを表示します。
関連情報
-
Apache 仮想ホストの設定に関する詳細は、Apache マニュアルの
仮想ホスト
のドキュメントを参照してください。マニュアルのインストールの詳細は、「Apache HTTP Server の手動インストール」 を参照してください。
1.6. Apache HTTP サーバーで TLS 暗号化の設定
デフォルトでは、Apache は暗号化されていない HTTP 接続を使用してクライアントにコンテンツを提供します。本セクションでは、TLS 暗号化を有効にし、Apache HTTP Server で頻繁に使用される暗号化関連の設定を行う方法を説明します。
前提条件
- Apache HTTP Server がインストールされ、実行している。
1.6.1. Apache HTTP Server への TLS 暗号化の追加
本セクションでは、example.com
ドメインの Apache HTTP Server で TLS 暗号化を有効にする方法を説明します。
前提条件
- Apache HTTP Server がインストールされ、実行している。
秘密鍵は
/etc/pki/tls/private/example.com.key
ファイルに保存されます。秘密鍵および証明書署名要求 (CSR) を作成する方法と、認証局 (CA) からの証明書を要求する方法は、CA のドキュメントを参照してください。または、お使いの CA が ACME プロトコルに対応している場合は、
mod_md
モジュールを使用して、TLS 証明書の取得およびプロビジョニングを自動化できます。-
TLS 証明書は
/etc/pki/tls/private/example.com.crt
ファイルに保存されます。別のパスを使用する場合は、この手順の適切な手順を調整します。 -
CA 証明書は
/etc/pki/tls/private/ca.crt
ファイルに保存されます。別のパスを使用する場合は、この手順の適切な手順を調整します。 - クライアントおよび Web サーバーは、サーバーのホスト名を Web サーバーのホスト名に解決します。
手順
mod_ssl
パッケージをインストールします。# dnf install mod_ssl
/etc/httpd/conf.d/ssl.conf
ファイルを編集し、以下の設定を<VirtualHost _default_:443>
ディレクティブに追加します。サーバー名を設定します。
ServerName example.com
重要サーバー名は、証明書の
Common Name
フィールドに設定されているエントリーと一致している必要があります。必要に応じて、
Subject Alt Names
(SAN) フィールドに追加のホスト名が含まれる場合、これらのホスト名にも TLS 暗号化を提供するようにmod_ssl
を設定できます。これを設定するには、ServerAliases
パラメーターと対応する名前を追加します。ServerAlias www.example.com server.example.com
秘密鍵、サーバー証明書、および CA 証明書へのパスを設定します。
SSLCertificateKeyFile "/etc/pki/tls/private/example.com.key" SSLCertificateFile "/etc/pki/tls/certs/example.com.crt" SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"
セキュリティー上の理由から、
root
ユーザーのみが秘密鍵ファイルにアクセスできるように設定します。# chown root:root /etc/pki/tls/private/example.com.key # chmod 600 /etc/pki/tls/private/example.com.key
警告秘密鍵に権限のないユーザーがアクセスした場合は、証明書を取り消し、新しい秘密鍵を作成し、新しい証明書を要求します。そうでない場合は、TLS 接続が安全ではなくなります。
ローカルのファイアウォールでポート
443
を開きます。# firewall-cmd --permanent --add-port=443 # firewall-cmd --reload
httpd
サービスを再起動します。# systemctl restart httpd
注記パスワードで秘密鍵ファイルを保護した場合は、
httpd
サービスの起動時に毎回このパスワードを入力する必要があります。
検証手順
-
ブラウザーを使用して、
https://example.com
に接続します。
関連情報
-
TLS の設定に関する詳細は、Apache マニュアルの
SSL/TLS 暗号化
についてのドキュメントを参照してください。マニュアルのインストールの詳細は、「Apache HTTP Server の手動インストール」 を参照してください。
1.6.2. Apache HTTP サーバーでサポートされる TLS プロトコルバージョンの設定
デフォルトでは、RHEL 8 の Apache HTTP Server は、最新のブラウザーにも互換性のある安全なデフォルト値を定義するシステム全体の暗号化ポリシーを使用します。たとえば、DEFAULT
ポリシーは、apache で TLSv1.2
プロトコルバージョンおよび TLSv1.3
プロトコルバージョンのみが有効になっていることを定義します。
本セクションでは、Apache HTTP Server がサポートする TLS プロトコルバージョンを手動で設定する方法を説明します。たとえば、環境が特定の TLS プロトコルバージョンのみを有効にする必要がある場合には、以下の手順に従います。
-
お使いの環境で、クライアントが弱い
TLS1
(TLSv1.0) プロトコルまたはTLS1.1
プロトコルも使用できるようにする必要がある場合は、 -
Apache が
TLSv1.2
プロトコルまたはTLSv1.3
プロトコルのみに対応するように設定する場合。
前提条件
- TLS 暗号化は、「Apache HTTP Server への TLS 暗号化の追加」 で説明されているようにサーバーで有効になります。
手順
/etc/httpd/conf/httpd.conf
ファイルを編集し、TLS プロトコルバージョンを設定する<VirtualHost>
ディレクティブに以下の設定を追加します。たとえば、TLSv1.3
プロトコルのみを有効にするには、以下を実行します。SSLProtocol -All TLSv1.3
httpd
サービスを再起動します。# systemctl restart httpd
検証手順
以下のコマンドを使用して、サーバーが
TLSv1.3
に対応していることを確認します。# openssl s_client -connect example.com:443 -tls1_3
以下のコマンドを使用して、サーバーが
TLSv1.2
に対応していないことを確認します。# openssl s_client -connect example.com:443 -tls1_2
サーバーがプロトコルに対応していない場合、このコマンドは以下のエラーを返します。
140111600609088:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70
- 必要に応じて、他の TLS プロトコルバージョンのコマンドを繰り返し実行します。
関連情報
-
システム全体の暗号化ポリシーの詳細は、man ページの
update-crypto-policies(8)
と、「システム全体の暗号化ポリシーの使用」を参照してください。 -
SSLProtocol
パラメーターの詳細は、Apache マニュアルのmod_ssl
ドキュメントを参照してください。マニュアルのインストールの詳細は、「Apache HTTP Server の手動インストール」 を参照してください。
1.6.3. Apache HTTP サーバーで対応している暗号の設定
デフォルトでは、RHEL 8 の Apache HTTP Server は、最新のブラウザーにも互換性のある安全なデフォルト値を定義するシステム全体の暗号化ポリシーを使用します。システム全体の暗号化が許可する暗号化の一覧は、/etc/crypto-policies/back-ends/openssl.config
ファイルを参照してください。
本セクションでは、Apache HTTP Server がサポートする暗号化を手動で設定する方法を説明します。お使いの環境で特定の暗号が必要な場合は、手順に従います。
前提条件
- TLS 暗号化は、「Apache HTTP Server への TLS 暗号化の追加」 で説明されているようにサーバーで有効になります。
手順
/etc/httpd/conf/httpd.conf
ファイルを編集し、SSLCipherSuite
パラメーターを、TLS 暗号を設定する<VirtualHost>
ディレクティブに追加します。SSLCipherSuite "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!SHA1:!SHA256"
この例では、
EECDH+AESGCM
、EDH+AESGCM
、AES256+EECDH
、およびAES256+EDH
暗号のみを有効にし、SHA1
およびSHA256
メッセージ認証コード (MAC) を使用するすべての暗号を無効にします。httpd
サービスを再起動します。# systemctl restart httpd
検証手順
Apache HTTP Server が対応するする暗号化のリストを表示するには、以下を行います。
nmap
パッケージをインストールします。# yum install nmap
nmap
ユーティリティーを使用して、対応している暗号を表示します。# nmap --script ssl-enum-ciphers -p 443 example.com ... PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A ...
関連情報
-
システム全体の暗号化ポリシーの詳細は、man ページの
update-crypto-policies(8)
と、「システム全体の暗号化ポリシーの使用」を参照してください。 -
SSLCipherSuite
パラメーターの詳細は、Apache マニュアルのmod_ssl
ドキュメントを参照してください。マニュアルのインストールの詳細は、「Apache HTTP Server の手動インストール」 を参照してください。
1.7. TLS クライアント証明書認証の設定
クライアント証明書認証により、管理者は、証明書を使用して認証したユーザーのみが Web サーバーのリソースにアクセスできます。本セクションでは、/var/www/html/Example/
ディレクトリーにクライアント証明書認証を設定する方法を説明します。
Apache HTTP Server が TLS 1.3 プロトコルを使用する場合、特定のクライアントには追加の設定が必要です。たとえば、Firefox で、about:config
メニューの security.tls.enable_post_handshake_auth
パラメーターを true
に設定します。詳細は、「Transport Layer Security version 1.3 in Red Hat Enterprise Linux 8」を参照してください。
前提条件
- TLS 暗号化は、「Apache HTTP Server への TLS 暗号化の追加」 で説明されているようにサーバーで有効になります。
手順
/etc/httpd/conf/httpd.conf
ファイルを編集し、以下の設定をクライアント認証を設定する<VirtualHost>
ディレクティブに追加します。<Directory "/var/www/html/Example/"> SSLVerifyClient require </Directory>
SSLVerifyClient require
の設定では、/var/www/html/Example/
ディレクトリーのコンテンツにクライアントがアクセスする前に、サーバーがクライアント証明書を正常に検証する必要があることを定義します。httpd
サービスを再起動します。# systemctl restart httpd
検証手順
curl
ユーティリティーを使用して、クライアント認証なしでhttps://example.com/Example/
URL にアクセスします。$ curl https://example.com/Example/ curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0
このエラーは、Web サーバーにクライアント証明書認証が必要であることを示しています。
クライアントの秘密鍵と証明書、および CA 証明書を
curl
に渡して、クライアント認証で同じ URL にアクセスします。$ curl --cacert ca.crt --key client.key --cert client.crt https://example.com/Example/
要求に成功すると、
curl
は/var/www/html/Example/
ディレクトリーに保存されているindex.html
ファイルを表示します。
関連情報
-
クライアント認証の詳細は、Apache マニュアルの
mod_ssl
設定方法を参照してください。マニュアルのインストールの詳細は、「Apache HTTP Server の手動インストール」 を参照してください。
1.8. Apache HTTP Server の手動インストール
本セクションでは、Apache HTTP Server のマニュアルをインストールする方法を説明します。本書では、以下のような詳細なドキュメントを提供します。
- 設定パラメーターおよびディレクティブ
- パフォーマンスチューニング
- 認証設定
- モジュール
- コンテンツのキャッシュ
- セキュリティーに関するヒント
- TLS 暗号化の設定
マニュアルをインストールした後は、Web ブラウザーを使用して表示できます。
前提条件
- Apache HTTP Server がインストールされ、実行している。
手順
httpd-manual
パッケージをインストールします。# yum install httpd-manual
必要に応じて、デフォルトでは、Apache HTTP Server に接続するすべてのクライアントはマニュアルを表示できます。
192.0.2.0/24
サブネットなど、特定の IP 範囲へのアクセスを制限するには、/etc/httpd/conf.d/manual.conf
ファイルを編集し、Require ip 192.0.2.0/24
設定を<Directory "/usr/share/httpd/manual">
ディレクティブに追加します。<Directory "/usr/share/httpd/manual"> ... Require ip 192.0.2.0/24 ... </Directory>
httpd
サービスを再起動します。# systemctl restart httpd
検証手順
-
Apache HTTP Server のマニュアルを表示するには、Web ブラウザーで
http://host_name_or_IP_address/manual/
に接続します。
1.9. モジュールの使用
httpd
サービスは、モジュールアプリケーションであるため、多数の Dynamic Shared Objects (DSO) と一緒に配布されます。これは、必要に応じてランタイム時に、動的に読み込まれたり、読み込みが破棄されたりします。このモジュールは、/usr/lib64/httpd/modules/
ディレクトリーにあります。
1.9.1. モジュールの読み込み
特定の DSO モジュールを読み込むには、LoadModule
ディレクティブを使用します。別のパッケージが提供するモジュールは、多くの場合、/etc/httpd/conf.modules.d/
ディレクトリーに独自の設定ファイルがあることに注意してください。
例1.1 mod_ssl DSO の読み込み
LoadModule ssl_module modules/mod_ssl.so
モジュールの読み込み後、Web サーバーを再起動して設定を再読み込みします。httpd
サービスを再起動する方法は、「httpd サービスの管理」を参照してください。
1.9.2. モジュールの作成
新しい DSO モジュールを作成するには、httpd-devel
パッケージがインストールされていることを確認します。これを行うには、root
で以下のコマンドを実行します。
# yum install httpd-devel
このパッケージには、モジュールをコンパイルするために必要なインクルードファイル、ヘッダーファイル、および APache eXtenSion (apxs
) ユーティリティーが含まれます。
作成したら、以下のコマンドでモジュールを構築できます。
# apxs -i -a -c module_name.c
ビルドが成功すると、Apache HTTP Server で配布されるその他のモジュールと同じ方法でモジュールを読み込むことができます。
1.10. Apache Web サーバー設定で秘密鍵と証明書を使用できるように NSS データベースからの証明書のエクスポート
RHEL 8 では Apache Web サーバーに mod_nss
モジュールが提供されなくなります。Red Hat は mod_ssl
モジュールの使用を推奨します。たとえば、RHEL 7 から RHEL 8 へ Web サーバーを移行したなどして、秘密鍵と証明書を Network Security Services (NSS) データベースに保存する場合は、以下の手順に従って、Privacy Enhanced Mail (PEM) 形式の鍵および証明書を抽出します。「Apache HTTP サーバーで TLS 暗号化の設定」 に従って、mod_ssl
設定のファイルを使用できます。
この手順では、NSS データベースが /etc/httpd/alias/
に保存され、エクスポートした秘密鍵と証明書を /etc/pki/tls/
ディレクトリーに保存することを前提としています。
前提条件
- 秘密鍵、証明書、および認証局(CA)の証明書は NSS データベースに保存されます。
手順
NSS データベースの証明書を一覧表示します。
#
certutil -d /etc/httpd/alias/ -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Example CA C,, Example Server Certificate u,u,u次の手順では、証明書のニックネームが必要です。
秘密鍵を抽出するには、鍵を PKCS #12 ファイルに一時的にエクスポートする必要があります。
秘密鍵に関連付けられた証明書のニックネームを使用して、鍵を PKCS #12 ファイルにエクスポートします。
#
pk12util -o /etc/pki/tls/private/export.p12 -d /etc/httpd/alias/ -n "Example Server Certificate"
Enter password for PKCS12 file: password Re-enter password: password pk12util: PKCS12 EXPORT SUCCESSFULPKCS #12 ファイルにパスワードを設定する必要があります。次の手順では、このパスワードが必要です。
PKCS #12 ファイルから秘密鍵をエクスポートします。
#
openssl pkcs12 -in /etc/pki/tls/private/export.p12 -out /etc/pki/tls/private/server.key -nocerts -nodes
Enter Import Password: password MAC verified OK一時 PKCS #12 ファイルを削除します。
#
rm /etc/pki/tls/private/export.p12
/etc/pki/tls/private/server.key
にパーミッションを設定し、root
ユーザーのみがこのファイルにアクセスできるようにします。#
chown root:root /etc/pki/tls/private/server.key
#chmod 0600 /etc/pki/tls/private/server.key
NSS データベースのサーバー証明書のニックネームを使用して CA 証明書をエクスポートします。
#
certutil -d /etc/httpd/alias/ -L -n "Example Server Certificate" -a -o /etc/pki/tls/certs/server.crt
/etc/pki/tls/certs/server.crt
にパーミッションを設定し、root
ユーザーのみがこのファイルにアクセスできるようにします。#
chown root:root /etc/pki/tls/certs/server.crt
#chmod 0600 /etc/pki/tls/certs/server.crt
NSS データベースの CA 証明書のニックネームを使用して、CA 証明書をエクスポートします。
#
certutil -d /etc/httpd/alias/ -L -n "Example CA
" -a -o /etc/pki/tls/certs/ca.crt「Apache HTTP サーバーで TLS 暗号化の設定」 に従って Apache Web サーバーを設定します。
-
SSLCertificateKeyFile
パラメーターを/etc/pki/tls/private/server.key
に設定します。 -
SSLCertificateFile
パラメーターを/etc/pki/tls/certs/server.crt
に設定します。 -
SSLCACertificateFile
パラメーターを/etc/pki/tls/certs/ca.crt
に設定します。
-
関連情報
-
certutil(1)
の man ページ -
pk12util(1)
の man ページ -
pkcs12(1ssl)
の man ページ
1.11. 関連情報
-
httpd(8)
-httpd
サービスの man ページで、コマンドラインオプションの一覧が記載されます。 -
httpd.service(8)
-httpd.service
ユニットファイルの man ページです。サービスのカスタマイズおよび機能強化の方法を説明します。 -
httpd.conf (5)
-httpd
設定ファイルの構造と場所を説明するhttpd
設定用の man ページです。 -
apachectl (8)
- Apache HTTP Server の制御インターフェースの man ページです。
第2章 NGINX の設定および構成
NGINX は、たとえば、次のように使用できる高パフォーマンスなモジュラーサーバーです。
- Web サーバー
- リバースプロキシー
- ロードバランサー
本セクションでは、このシナリオで NGINX を行う方法を説明します。
2.1. NGINX のインストールおよび準備
Red Hat は、アプリケーションストリームを使用して NGINX の異なるバージョンを提供します。本セクションでは、以下を行う方法を説明します。
- ストリームを選択し、NGINX をインストールします。
- ファイアウォールで必要なポートを開きます。
-
nginx
サービスの有効化および開始
デフォルト設定を使用すると、NGINX はポート 80
の Web サーバーとして実行され、/usr/share/nginx/html/
ディレクトリーのコンテンツを提供します。
前提条件
- RHEL 8 がインストールされている。
- ホストは Red Hat カスタマーポータルにサブスクライブしている。
-
デフォルトでは、
firewalld
サービスは有効で開始しています。
手順
利用可能な NGINX モジュールストリームを表示します。
#
yum module list nginx
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary nginx 1.14 [d] common [d] nginx webserver nginx 1.16 common [d] nginx webserver ... Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalledデフォルト以外のストリームをインストールする場合は、ストリームを選択します。
#
yum module enable nginx:stream_version
nginx
パッケージをインストールします。#
yum install nginx
NGINX がファイアウォールでサービスを提供するポートを開きます。たとえば、
firewalld
で HTTP (ポート 80) および HTTPS (ポート 443) のデフォルトポートを開くには、次のコマンドを実行します。#
firewall-cmd --permanent --add-port={80/tcp,443/tcp}
#firewall-cmd --reload
nginx
サービスがシステムの起動時に自動的に起動するようにします。#
systemctl enable nginx
必要に応じて、
nginx
サービスを起動します。#
systemctl start nginx
デフォルト設定を使用しない場合は、この手順を省略し、サービスを起動する前に NGINX を適切に設定します。
検証手順
yum
ユーティリティーを使用して、nginx
パッケージがインストールされていることを確認します。#
yum list installed nginx
Installed Packages nginx.x86_64 1:1.14.1-9.module+el8.0.0+4108+af250afe @rhel-8-for-x86_64-appstream-rpmsNGINX がサービスを提供するポートが firewalld で開いていることを確認します。
#
firewall-cmd --list-ports
80/tcp 443/tcpnginx
サービスが有効になっていることを確認します。#
systemctl is-enabled nginx
enabled
関連情報
- Subscription Manager の詳細は、『Subscription Manager の使用および設定』ガイドを参照してください。
- アプリケーションストリーム、モジュール、およびインストールパッケージの詳細は、『ユーザー空間コンポーネントのインストール、管理、および削除』を参照してください。
- ファイアウォールの設定に関する詳細は、『ネットワークのセキュリティー保護』を参照してください。
2.2. 異なるドメインに異なるコンテンツを提供する Web サーバーとしての NGINX の設定
デフォルトでは、NGINX はサーバーの IP アドレスに関連付けられたすべてのドメイン名のクライアントに同じコンテンツを提供する Web サーバーとして動作します。この手順では、NGINX を設定する方法を説明します。
-
/var/www/example.com/
ディレクトリーのコンテンツで、example.com
ドメインにリクエストを提供する。 -
/var/www/example.net/
ディレクトリーのコンテンツを使用して、example.net
ドメインにリクエストを提供する。 -
その他のすべてのリクエスト (たとえば、サーバーの IP アドレスまたはサーバーの IP アドレスに関連付けられたその他のドメイン) に
/usr/share/nginx/html/
ディレクトリーのコンテンツを指定します。
前提条件
- NGINX は、「NGINX のインストールおよび準備」の説明に従ってインストールされます。
クライアントおよび Web サーバーは、
example.com
およびexample.net
ドメインを Web サーバーの IP アドレスに解決します。これらのエントリーは DNS サーバーに手動で追加する必要がある点に注意してください。
手順
/etc/nginx/nginx.conf
ファイルを編集します。デフォルトでは、
/etc/nginx/nginx.conf
ファイルには catch-all 設定がすでに含まれています。設定からこの部分を削除した場合は、以下のサーバー
ブロックを/etc/nginx/nginx.conf
ファイルのhttp
ブロックに再追加します。server { listen 80 default_server; listen [::]:80 default_server; server_name _; root /usr/share/nginx/html; }
これらの設定は以下を構成します。
-
listen
ディレクティブは、サービスがリッスンする IP アドレスとポートを定義します。この場合、NGINX は IPv4 と IPv6 の両方のアドレスのポート80
でリッスンします。default_server
パラメーターは、NGINX がこのserver
ブロックを IP アドレスとポートに一致するリクエストのデフォルトとして使用していることを示します。 -
server_name
パラメーターは、このserver
ブロックに対応するホスト名を定義します。server_name
を_
に設定すると、このserver
ブロックのホスト名を受け入れるように NGINX を設定します。 -
root
ディレクティブは、このserver
ブロックの Web コンテンツへのパスを設定します。
-
example.com
ドメインの同様のserver
ブロックをhttp
ブロックに追加します。server { server_name example.com; root /var/www/example.com/; access_log /var/log/nginx/example.com/access.log; error_log /var/log/nginx/example.com/error.log; }
-
access_log
ディレクティブは、このドメインに別のアクセスログファイルを定義します。 -
error_log
ディレクティブは、このドメインに別のエラーログファイルを定義します。
-
example.net
ドメインの同様のserver
ブロックをhttp
ブロックに追加します。server { server_name example.net; root /var/www/example.net/; access_log /var/log/nginx/example.net/access.log; error_log /var/log/nginx/example.net/error.log; }
両方のドメインのルートディレクトリーを作成します。
#
mkdir -p /var/www/example.com/
#mkdir -p /var/www/example.net/
両方のルートディレクトリーに
httpd_sys_content_t
コンテキストを設定します。#
semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com(/.*)?"
#restorecon -Rv /var/www/example.com/
#semanage fcontext -a -t httpd_sys_content_t "/var/www/example.net(/.\*)?"
#restorecon -Rv /var/www/example.net/
これらのコマンドは、
/var/www/example.com/
ディレクトリーおよび/var/www/example.net/
ディレクトリーにhttpd_sys_content_t
コンテキストを設定します。policycoreutils-python-utils
パッケージをインストールしてrestorecon
コマンドを実行する必要があります。両方のドメインのログディレクトリーを作成します。
#
mkdir /var/log/nginx/example.com/
#mkdir /var/log/nginx/example.net/
nginx
サービスを再起動します。#
systemctl restart nginx
検証手順
各仮想ホストのドキュメントルートに異なるサンプルファイルを作成します。
#
echo "Content for example.com" > /var/www/example.com/index.html
#echo "Content for example.net" > /var/www/example.net/index.html
#echo "Catch All content" > /usr/share/nginx/html/index.html
-
ブラウザーを使用して
http://example.com
に接続します。Web サーバーは、/var/www/example.com/index.html
ファイルからのサンプルコンテンツを表示します。 -
ブラウザーを使用して
http://example.net
に接続します。Web サーバーは、/var/www/example.net/index.html
ファイルからのサンプルコンテンツを表示します。 -
ブラウザーを使用して
http://IP_address_of_the_server
に接続します。Web サーバーは、/usr/share/nginx/html/index.html
ファイルからのサンプルコンテンツを表示します。
2.3. NGINX Web サーバーへの TLS 暗号化の追加
本セクションでは、example.com
ドメインの NGINX Web サーバーで TLS 暗号化を有効にする方法を説明します。
前提条件
- NGINX は、「NGINX のインストールおよび準備」の説明に従ってインストールされます。
秘密鍵は
/etc/pki/tls/private/example.com.key
ファイルに保存されます。秘密鍵および証明書署名要求 (CSR) を作成する方法と、認証局 (CA) からの証明書を要求する方法は、CA のドキュメントを参照してください。
-
TLS 証明書は
/etc/pki/tls/certs/example.com.crt
ファイルに保存されます。別のパスを使用する場合は、この手順の適切な手順を調整します。 - CA 証明書がサーバーの TLS 証明書ファイルに追加されている。
- クライアントおよび Web サーバーは、サーバーのホスト名を Web サーバーのホスト名に解決します。
-
ポート
443
が、ローカルのファイアウォールで開いている。
手順
/etc/nginx/nginx.conf
ファイルを編集し、設定のhttp
ブロックに以下のserver
ブロックを追加します。server { listen 443 ssl; server_name example.com; root /usr/share/nginx/html; ssl_certificate /etc/pki/tls/certs/example.com.crt; ssl_certificate_key /etc/pki/tls/private/example.com.key; }
セキュリティー上の理由から、
root
ユーザーのみが秘密鍵ファイルにアクセスできるように設定します。#
chown root:root /etc/pki/tls/private/example.com.key
#chmod 600 /etc/pki/tls/private/example.com.key
警告秘密鍵に権限のないユーザーがアクセスした場合は、証明書を取り消し、新しい秘密鍵を作成し、新しい証明書を要求します。そうでない場合は、TLS 接続が安全ではなくなります。
nginx
サービスを再起動します。#
systemctl restart nginx
検証手順
-
ブラウザーを使用して、
https://example.com
に接続します。
2.4. HTTP トラフィックのリバースプロキシーとしての NGINX の設定
NGINX Web サーバーは、HTTP トラフィックのリバースプロキシーとして機能するように設定できます。たとえば、この機能を使用すると、リモートサーバーの特定のサブディレクトリーに要求を転送できます。クライアント側からは、クライアントはアクセスするホストからコンテンツを読み込みます。ただし、NGINX は実際のコンテンツをリモートサーバーから読み込み、クライアントに転送します。
この手順では、Web サーバーの /example
ディレクトリーへのトラフィックを、URL https://example.com
に転送する方法を説明します。
前提条件
- NGINX は、「NGINX のインストールおよび準備」 の説明に従ってインストールされます。
- 必要に応じて、TLS 暗号化がリバースプロキシーで有効になっている。
手順
/etc/nginx/nginx.conf
ファイルを編集し、リバースプロキシーを提供するserver
ブロックに以下の設定を追加します。location /example { proxy_pass https://example.com; }
location
ブロックは、NGINX が/example
ディレクトリーのすべての要求をhttps://example.com
に渡すことを定義します。SELinux ブール値パラメーター
httpd_can_network_connect
を1
に設定して、SELinux が NGINX がトラフィックを転送できるように設定します。#
setsebool -P httpd_can_network_connect 1
nginx
サービスを再起動します。#
systemctl restart nginx
検証手順
-
ブラウザーを使用して
http://host_name/example
に接続すると、https://example.com
の内容が表示されます。
2.5. NGINX を HTTP ロードバランサーとして設定
NGINX リバースプロキシー機能を使用してトラフィックを負荷分散できます。この手順では、アクティブな接続数が最も少ない数に基づいて、異なるサーバーにリクエストを送信する HTTP ロードバランサーとして NGINX を設定する方法を説明します。両方のサーバーが利用できない場合、この手順はフォールバックの理由として 3 番目のホストも定義します。
前提条件
- NGINX は、「NGINX のインストールおよび準備」 の説明に従ってインストールされます。
手順
/etc/nginx/nginx.conf
ファイルを編集し、以下の設定を追加します。http { upstream backend { least_conn; server server1.example.com; server server2.example.com; server server3.example.com backup; } server { location / { proxy_pass http://backend; } } }
backend
という名前のホストグループのleast_conn
ディレクティブは、アクティブな接続数が最も少ないホストによって NGINX がserver1.example.com
またはserver2.example.com
に要求を送信することを定義します。NGINX は、他の 2 つのホストが利用できない場合は、server3.example.com
のみをバックアップとして使用します。proxy_pass
ディレクティブをhttp://backend
に設定すると、NGINX はリバースプロキシーとして機能し、backend
ホストグループを使用して、このグループの設定に基づいて要求を配信します。least_conn
負荷分散メソッドの代わりに、以下を指定することができます。- ラウンドロビンを使用し、サーバー全体で要求を均等に分散する方法はありません。
-
ip_hash
- クライアントの、IPv4 アドレスの最初の 3 つのオクテット、または IPv6 アドレス全体から計算されたハッシュに基づいて、あるクライアントアドレスから同じサーバーに要求を送信します。 -
ユーザー定義のキーに基づいてサーバーを判断する
hash
。これは文字列、変数、または両方の組み合わせになります。consistent
パラメーターは、ユーザー定義のハッシュ化された鍵の値に基づいて、NGINX がすべてのサーバーに要求を分散するように設定します。 -
random
: 無作為に選択されたサーバーに要求を送信します。
nginx
サービスを再起動します。#
systemctl restart nginx
2.6. 関連情報
- 公式の NGINX は、https://nginx.org/en/docs/ を参照してください。Red Hat は本書を維持しておらず、インストールした NGINX バージョンでは機能しない可能性があることに注意してください。
第3章 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 がファイルサーバーおよびプリントサーバーとして機能できるようになります。
3.1. さまざまな Samba サービスおよびモードについて
本セクションでは、Samba に含まれるさまざまなサービスと設定可能なさまざまなモードを説明します。
3.1.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 に対応しません。
3.1.2. Samba セキュリティーサービス
/etc/samba/smb.conf
ファイルの [global]
セクションの security
パラメーターは、Samba がサービスに接続しているユーザーを認証する方法を管理します。Samba をインストールするモードに応じて、パラメーターは異なる値に設定する必要があります。
- AD ドメインメンバーに、
security = ads
を設定する。 このモードでは、Samba は Kerberos を使用して AD ユーザーを認証します。
Samba をドメインメンバーとして設定する方法は、「Samba を AD ドメインメンバーサーバーとして設定」を参照してください。
- スタンドアロンサーバーで、
security = user
を設定する。 このモードでは、Samba がローカルデータベースを使用して接続ユーザーを認証します。
Samba をスタンドアロンサーバーとして設定する方法は、「Samba をスタンドアロンサーバーとして設定」を参照してください。
- NT4 PDC または BDC に
security = user
を設定する。 - Samba は、このモードでは、ユーザーをローカルまたは LDAP データベースに認証します。
- NT4 ドメインメンバーで、
security = domain
を設定する。 Samba は、このモードでは、NT4 PDC または BDC にユーザーを接続する認証を行います。このモードは、AD ドメインメンバーには使用できません。
Samba をドメインメンバーとして設定する方法は、「Samba を AD ドメインメンバーサーバーとして設定」を参照してください。
関連情報
-
man ページの
smb.conf(5)
で、security
パラメーターの説明を参照してください。
3.1.3. Samba サービスおよび Samba クライアントユーティリティーが設定を読み込み、再読み込みするシナリオ
以下は、Samba サービスおよびユーティリティーが設定を読み込み、再読み込みするときの方法を説明します。
Samba サービスは、設定を再読み込みします。
- 3 分ごとに自動更新
-
手動要求では、たとえば、
smbcontrol all reload-config
コマンドを実行するとします。
- Samba クライアントユーティリティーは、起動時にのみ設定を読み取ります。
security
などの特定のパラメーターの適用には、smb
サービスの再起動が必要です。リロードには十分ではないことに注意してください。
関連情報
-
smb.conf(5)
man ページの「How configuration changes are apply
」セクション -
smbd(8)
、nmbd(8)
、およびwinbindd(8)
man ページ
3.1.4. 同じ方法での Samba 設定の編集
Samba サービスは、3 分ごとに設定を自動的に再読み込みします。この手順では、testparm
ユーティリティーを使用して設定を検証する前に、サービスが変更をリロードしないように Samba 設定を編集する方法を説明します。
前提条件
- Samba がインストールされている。
手順
/etc/samba/smb.conf
ファイルのコピーを作成します。#
cp /etc/samba/smb.conf /etc/samba/samba.conf.copy
- コピーされたファイルを編集し、必要な変更を加えます。
/etc/samba/samba.conf.copy
ファイルの設定を確認します。#
testparm -s /etc/samba/samba.conf.copy
testparm
がエラーを報告した場合は、修正してもう一度コマンドを実行します。/etc/samba/smb.conf
ファイルを新しい設定で上書きします。#
mv /etc/samba/samba.conf.copy
/etc/samba/smb.confSamba サービスが設定を自動的に再読み込みするか、または手動で設定を再読み込みするまで待ちます。
#
smbcontrol all reload-config
3.2. Samba 設定の確認
Red Hat は、/etc/samba/smb.conf
ファイルを更新するたびに Samba 設定を確認することを推奨します。本セクションでは、その詳細を説明します。
3.2.1. testparm ユーティリティーを使用した smb.conf ファイルの検証
testparm
ユーティリティーは、/etc/samba/smb.conf
ファイルの Samba 設定が正しいことを確認します。このユーティリティーは、無効なパラメーターおよび値を検出しますが、ID マッピングなどの間違った設定も検出します。testparm
が問題を報告しないと、Samba サービスは /etc/samba/smb.conf
ファイルを正常に読み込みます。testparm
は、設定されたサービスが利用可能であること、または期待通りに機能するかを確認できないことに注意してください。
Red Hat では、このファイルの変更後に毎回 testparm
を使用して、/etc/samba/smb.conf
ファイルを検証することが推奨されます。
前提条件
- Samba をインストールしている。
-
/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
が設定内の間違ったパラメーター、値、またはその他のエラーを報告する場合は、問題を修正してから再度ユーティリティーを実行してください。
3.3. Samba をスタンドアロンサーバーとして設定
Samba は、ドメインのメンバーではないサーバーとして設定できます。このインストールモードでは、Samba はユーザーを中央 DC ではなくローカルデータベースに認証します。また、ゲストアクセスを有効にして、ユーザーが、認証なしで 1 つまたは複数のサービスに接続できるようにすることもできます。
3.3.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 名まで展開します。これにより、クライアントごとに個別のログファイルが有効になります。オプションで、ファイルまたはプリンターの共有を構成します。以下を参照してください。
/etc/samba/smb.conf
ファイルを検証します。#
testparm
認証が必要な共有を設定する場合は、ユーザーアカウントを作成します。
詳細は 「ローカルユーザーアカウントの作成および有効化」 を参照してください。
firewall-cmd
ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。#
firewall-cmd --permanent --add-port={139/tcp,445/tcp}
#firewall-cmd --reload
smb
サービスを有効にして起動します。#
systemctl enable --now smb
関連情報
-
この手順で使用するパラメーターの詳細は、man ページの
smb.conf(5)
でパラメーターの説明を参照してください。
3.3.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 successfullySamba は、オペレーティングシステムのアカウントに設定されたパスワードを使用して認証を行いません。ただし、アカウントを有効にするには、パスワードを設定する必要があります。アカウントが無効になると、そのユーザーが接続した時に 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.
3.4. Samba ID マッピングの理解および設定
Windows ドメインは、ユーザーおよびグループを一意のセキュリティ識別子 (SID) で区別します。ただし、Linux では、ユーザーおよびグループごとに一意の UID と GID が必要です。Samba をドメインメンバーとして実行する場合は、winbindd
サービスが、ドメインユーザーおよびグループに関する情報をオペレーティングシステムに提供します。
winbindd
サービスが、ユーザーおよびグループの一意の ID を Linux に提供するようにするには、/etc/samba/smb.conf
ファイルで ID マッピングを設定する必要があります。
- ローカルデータベース (デフォルトドメイン)
- Samba サーバーがメンバーになっている AD または NT4 のドメイン
- ユーザーがこの Samba サーバーのリソースにアクセスする必要のある信頼ドメイン
Samba は、特定の設定に対して異なる ID マッピングバックエンドを提供します。最も頻繁に使用されるバックエンドは、以下の通りです。
バックエンド | ユースケース |
---|---|
|
|
| AD ドメインのみ |
| AD ドメインおよび NT4 ドメイン |
|
AD、NT4、および |
3.4.1. Samba ID 範囲の計画
Linux の UID および GID を AD に保存するか、Samba がそれを生成するように設定するかに関係なく、各ドメイン設定には、他のドメインと重複しない一意の ID 範囲が必要です。
重複する ID 範囲を設定すると、Samba が正常に機能しなくなります。
例3.1 一意の 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 つの範囲だけです。したがって、ドメイン範囲間で十分な容量を残しておきます。これにより、ドメインが拡大した場合に、後で範囲を拡張できます。
後で別の範囲をドメインに割り当てると、このユーザーおよびグループが作成したファイルおよびディレクトリーの所有権が失われます。
3.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 マッピングバックエンドの使用」 を参照してください。
3.4.3. tdb ID マッピングバックエンドの使用
winbindd
サービスは、デフォルトで書き込み可能な tdb
ID マッピングバックエンドを使用して、セキュリティー識別子 (SID)、UID、および GID のマッピングテーブルを格納します。これには、ローカルユーザー、グループ、組み込みプリンシパルが含まれます。
このバックエンドは、*
デフォルトドメインにのみ使用してください。以下に例を示します。
idmap config * : backend = tdb idmap config * : range = 10000-999999
関連情報
3.4.4. 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 属性名 | オブジェクトの種類 | マッピング先 |
---|---|---|
| ユーザーおよびグループ | オブジェクトのユーザー名またはグループ名 |
| ユーザー | ユーザー ID (UID) |
| グループ | グループ ID (GID) |
| ユーザー | ユーザーのシェルのパス |
| ユーザー | ユーザーのホームディレクトリーのパス |
| ユーザー | プライマリグループ ID |
[a]
idmap config DOMAIN:unix_nss_info = yes を設定している場合に限り、Samba がこの属性を読み込みます。
[b]
idmap config DOMAIN:unix_primary_group = yes を設定している場合に限り、Samba がこの属性を読み込みます。
|
前提条件
-
ユーザーおよびグループはいずれも、AD で一意の ID が設定され、ID が、
/etc/samba/smb.conf
ファイルで設定されている範囲内にある。ID が範囲外にあるオブジェクトは、Samba サーバーでは利用できません。 - ユーザーおよびグループには、AD ですべての必須属性が設定されている。必要な属性がないと、ユーザーまたはグループは Samba サーバーで使用できなくなります。必要な属性は、設定によって異なります。前提条件:
- Samba をインストールしている。
-
ID マッピングを除く Samba 設定が
/etc/samba/smb.conf
ファイルにある。
手順
/etc/samba/smb.conf
ファイルの[global]
セクションを編集します。デフォルトドメイン (
*
) に ID マッピング設定が存在しない場合は追加します。以下に例を示します。idmap config * : backend = tdb idmap config * : range = 10000-999999
AD ドメインの
ad
ID マッピングバックエンドを有効にします。idmap config DOMAIN : backend = ad
AD ドメインのユーザーおよびグループに割り当てられている ID の範囲を設定します。以下に例を示します。
idmap config DOMAIN : range = 2000000-2999999
重要この範囲は、このサーバーの他のドメイン構成と重複させることはできません。また、この範囲には、今後割り当てられる ID がすべて収まる大きさを設定する必要があります。詳細は 「Samba ID 範囲の計画」 を参照してください。
Samba が AD から属性を読み取る際に RFC 2307 スキーマを使用するように設定します。
idmap config DOMAIN : schema_mode = rfc2307
Samba が、対応する AD 属性からログインシェルおよびユーザーホームディレクトリーのパスを読み取るようにする場合は、以下を設定します。
idmap config DOMAIN : unix_nss_info = yes
または、すべてのユーザーに適用される、ドメイン全体のホームディレクトリーのパスおよびログインシェルを統一して設定できます。以下に例を示します。
template shell = /bin/bash template homedir = /home/%U
デフォルトでは、Samba は、ユーザーオブジェクトの
primaryGroupID
属性を、Linux のユーザーのプライマリーグループとして使用します。または、代わりにgidNumber
属性に設定されている値を使用するように Samba を設定できます。idmap config DOMAIN : unix_primary_group = yes
/etc/samba/smb.conf
ファイルを検証します。#
testparm
Samba 設定を再読み込みします。
#
smbcontrol all reload-config
関連情報
- 「* デフォルトドメイン」
-
この手順で使用するパラメーターの詳細は、man ページの
smb.conf(5)
およびidmap_ad(8)
を参照してください。 -
変数の置換の詳細は、man ページの
smb.conf(5)
のVARIABLE SUBSTITUTIONS
セクションを参照してください。
3.4.5. 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 が発生する場合があります。
前提条件
- Samba をインストールしている。
-
ID マッピングを除く Samba 設定が
/etc/samba/smb.conf
ファイルにある。
手順
/etc/samba/smb.conf
ファイルの[global]
セクションを編集します。デフォルトドメイン (
*
) に ID マッピング設定が存在しない場合は追加します。以下に例を示します。idmap config * : backend = tdb idmap config * : range = 10000-999999
ドメインの
rid
ID マッピングバックエンドを有効にします。idmap config DOMAIN : backend = rid
今後割り当てられるすべての RID が収まる大きさの範囲を設定します。以下に例を示します。
idmap config DOMAIN : range = 2000000-2999999
Samba は、そのドメインの RID がその範囲内にないユーザーおよびグループを無視します。
重要この範囲は、このサーバーの他のドメイン構成と重複させることはできません。詳細は 「Samba ID 範囲の計画」 を参照してください。
すべてのマッピングユーザーに割り当てられるシェルおよびホームディレクトリーのパスを設定します。以下に例を示します。
template shell = /bin/bash template homedir = /home/%U
/etc/samba/smb.conf
ファイルを検証します。#
testparm
Samba 設定を再読み込みします。
#
smbcontrol all reload-config
関連情報
- 「* デフォルトドメイン」
-
変数の置換の詳細は、man ページの
smb.conf(5)
のVARIABLE SUBSTITUTIONS
セクションを参照してください。 -
Samba が RID のローカル ID を計算する方法は、man ページの
idmap_rid(8)
を参照してください。
3.4.6. 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 が、設定された範囲外にあるユーザーとグループのみが除外されます。
前提条件
- Samba をインストールしている。
-
ID マッピングを除く Samba 設定が
/etc/samba/smb.conf
ファイルにある。
手順
/etc/samba/smb.conf
ファイルの[global]
セクションを編集します。*
デフォルトドメインのautorid
ID マッピングバックエンドを有効にします。idmap config * : backend = autorid
既存および将来の全オブジェクトに ID を割り当てられる大きさの範囲を設定します。以下に例を示します。
idmap config * : range = 10000-999999
Samba は、このドメインで計算した ID が範囲内にないユーザーおよびグループを無視します。
警告範囲を設定し、Samba がそれを使用して開始してからは、範囲の上限を小さくすることはできません。範囲にその他の変更を加えると、新しい ID 割り当てが発生し、ファイルの所有権が失われる可能性があります。
必要に応じて、範囲サイズを設定します。以下に例を示します。
idmap config * : rangesize = 200000
Samba は、
idmap config * : range
パラメーターに設定されている範囲からすべての ID を取得するまで、各ドメインのオブジェクトにこの数の連続 ID を割り当てます。すべてのマッピングユーザーに割り当てられるシェルおよびホームディレクトリーのパスを設定します。以下に例を示します。
template shell = /bin/bash template homedir = /home/%U
必要に応じて、ドメイン用の ID マッピング設定を追加します。個別のドメインの設定が利用できない場合、Samba は以前に設定した
*
デフォルトドメインのautorid
バックエンド設定を使用して ID を計算します。重要各ドメインに追加のバックエンドを設定する場合は、すべての ID マッピング設定の範囲がオーバーラップしないようにしてください。詳細は 「Samba ID 範囲の計画」 を参照してください。
/etc/samba/smb.conf
ファイルを検証します。#
testparm
Samba 設定を再読み込みします。
#
smbcontrol all reload-config
関連情報
-
バックエンドの計算された ID の詳細は、man ページの
idmap_autorid(8)
のTHE MAPPING FORMULAS
セクションを参照してください。 -
idmap config
rangesize
パラメーターの使用方法は、man ページのidmap_autorid(8)
のrangesize
パラメーターの説明を参照してください。 -
変数の置換の詳細は、man ページの
smb.conf(5)
のVARIABLE SUBSTITUTIONS
セクションを参照してください。
3.5. Samba を AD ドメインメンバーサーバーとして設定
AD または NT4 のドメインを実行している場合は、Samba を使用して Red Hat Enterprise Linux サーバーをメンバーとしてドメインに追加し、以下を取得します。
- その他のドメインメンバーのドメインリソースにアクセスする
-
sshd
などのローカルサービスに対してドメインユーザーを認証する - サーバーにホストされているディレクトリーおよびプリンターを共有して、ファイルサーバーおよびプリントサーバーとして動作する
3.5.1. RHEL システムの AD ドメインへの参加
本セクションでは、realmd
を使用して Samba Winbind を設定することで、Red Hat Enterprise Linux システムを AD ドメインに参加させる方法を説明します。
手順
AD で Kerberos 認証に非推奨の RC4 暗号化タイプが必要な場合は、RHEL でこの暗号のサポートを有効にします。
#
update-crypto-policies --set DEFAULT:AD-SUPPORT
以下のパッケージをインストールします。
#
yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients \ samba-winbind samba-common-tools samba-winbind-krb5-locator
ドメインメンバーでディレクトリーまたはプリンターを共有するには、
samba
パッケージをインストールします。#
yum install samba
既存の Samba 設定ファイル
/etc/samba/smb.conf
をバックアップします。#
mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
ドメインに参加します。たとえば、ドメイン
ad.example.com
に参加するには、以下のコマンドを実行します。#
realm join --membership-software=samba --client-software=winbind ad.example.com
上記のコマンドを使用すると、
realm
ユーティリティーが自動的に以下を実行します。-
ad.example.com
ドメインのメンバーシップに/etc/samba/smb.conf
ファイルを作成します。 -
ユーザーおよびグループの検索用の
winbind
モジュールを、/etc/nsswitch.conf
ファイルに追加します。 -
/etc/pam.d/
ディレクトリーの PAM (プラグ可能な認証モジュール) 設定ファイルを更新します。 -
winbind
サービスを起動し、システムの起動時にサービスを起動できるようにします。
-
- 必要に応じて、「Samba ID マッピングの理解および設定」 ファイルの別の ID マッピングバックエンド、またはカスタマイズした ID マッピングを設定します。詳細は、「Samba ID マッピングの理解および設定」 を参照してください。
winbind
サービスが稼働していることを確認します。#
systemctl status winbind
... Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago重要Samba がドメインのユーザーおよびグループの情報をクエリーできるようにするには、
smb
を起動する前にwinbind
サービスを実行する必要があります。samba
パッケージをインストールしてディレクトリーおよびプリンターを共有している場合は、smb
サービスを有効化して開始します。#
systemctl enable --now smb
-
必要に応じて、Active Directory へのローカルログインを認証する場合は、
winbind_krb5_localauth
プラグインを有効にします。「MIT Kerberos 用のローカル承認プラグインの使用」を参照してください。
検証手順
AD ドメインの AD 管理者アカウントなど、AD ユーザーの詳細を表示します。
#
getent passwd "AD\administrator"
AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bashAD ドメイン内のドメインユーザーグループのメンバーをクエリーします。
#
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
Kerberos 認証が期待どおりに機能することを確認します。
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
利用可能なドメインの表示:
#
wbinfo --all-domains
BUILTIN SAMBA-SERVER AD
関連情報
- 非推奨の RC4 暗号化を使用しない場合は、AD で AES 暗号化タイプを有効にすることができます。「GPO を使用した Active Directory で AES 暗号化タイプの有効化」 を参照してください。これは、AD の他のサービスに影響を及ぼす可能性があることに注意してください。
-
realm
ユーティリティーの詳細は、man ページのrealm(8)
を参照してください。
3.5.2. 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 }
関連情報
-
man ページの
winbind_krb5_localauth(8)
を参照してください。
3.6. IdM ドメインメンバーでの Samba の設定
本セクションでは、Red Hat Identity Management (IdM) ドメインに参加しているホストで Samba を設定する方法を説明します。IdM のユーザー、および可能であれば、信頼された Active Directory (AD) ドメインのユーザーは、Samba が提供する共有およびプリンターサービスにアクセスできます。
IdM ドメインメンバーでの Samba の使用はテクノロジープレビュー機能で、特定の制限が含まれています。たとえば、IdM 信頼コントローラーが Global Catalog Service をサポートしないため、AD が登録した Windows ホストは Windows で IdM ユーザーおよびグループを見つけることができません。さらに、IdM 信頼コントローラーは、Distributed Computing Environment / Remote Procedure Calls (DCE/RPC) プロトコルを使用する IdM グループの解決をサポートしません。これにより、AD ユーザーは、IdM クライアントから Samba の共有およびプリンターにしかアクセスできません。
IdM ドメインメンバーに Samba をデプロイする場合は、Red Hat にフィードバックをお寄せください。
前提条件
- ホストは、クライアントとして IdM ドメインに参加している。
- IdM サーバーとクライアントの両方が RHEL 8.1 以降で実行されている必要がある。
3.6.1. Samba をドメインメンバーにインストールするための IdM ドメインの準備
AD との信頼を確立し、IdM クライアントに Samba を設定する場合は、IdM サーバーの ipa-adtrust-install
ユーティリティーを使用して IdM ドメインを準備する必要があります。ただし、両方の状況が適用される場合でも、ipa-adtrust-install
は IdM マスターで 1 回のみ実行する必要があります。
前提条件
- PCP がインストールされている。
手順
必要なパッケージをインストールします。
[root@ipaserver ~]#
yum install ipa-server ipa-server-trust-ad samba-client
IdM 管理ユーザーとして認証します。
[root@ipaserver ~]#
kinit admin
ipa-adtrust-install
ユーティリティーを実行します。[root@ipaserver ~]#
ipa-adtrust-install
統合 DNS サーバーとともに IdM がインストールされていると、DNS サービスレコードが自動的に作成されます。
IdM が統合 DNS サーバーなしでインストールされると、
ipa-adtrust-install
は、続行する前に DNS に手動で追加する必要があるサービスレコードのリストを出力します。スクリプトにより、
/etc/samba/smb.conf
がすでに存在し、書き換えられることが求められます。WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration. Do you wish to continue? [no]:
yes
このスクリプトは、従来の Linux クライアントが信頼できるユーザーと連携できるようにする互換性プラグインである
slapi-nis
プラグインを設定するように求めるプロンプトを表示します。Do you want to enable support for trusted domains in Schema Compatibility plugin? This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users. Enable trusted domains support in slapi-nis? [no]:
yes
プロンプトが表示されたら、IdM ドメインの NetBIOS 名を入力するか、Enter を押して提案された名前を使用します。
Trust is configured but no NetBIOS domain name found, setting it now. Enter the NetBIOS name for the IPA domain. Only up to 15 uppercase ASCII letters, digits and dashes are allowed. Example: EXAMPLE. NetBIOS domain name [IDM]:
SID 生成タスクを実行して、既存ユーザーに SID を作成するように求められます。
Do you want to run the ipa-sidgen task? [no]:
yes
ディレクトリーを初めてインストールする際に、少なくとも 1 人のユーザー (IdM 管理者) が存在します。これはリソースを集中的に使用するタスクであるため、ユーザー数が多い場合は別のタイミングで実行できます。
(必要に応じて) デフォルトでは、Windows Server 2008 以降では、動的 RPC ポートの範囲は
49152-65535
として定義されます。ご使用の環境に異なる動的 RPC ポート範囲を定義する必要がある場合は、Samba が異なるポートを使用するように設定し、ファイアウォール設定でそのポートを開くように設定します。以下の例では、ポート範囲を55000-65000
に設定します。[root@ipaserver ~]#
net conf setparm global 'rpc server dynamic port range' 55000-65000
[root@ipaserver ~]#firewall-cmd --add-port=55000-65000/tcp
[root@ipaserver ~]#firewall-cmd --runtime-to-permanent
ipa
サービスを再起動します。[root@ipaserver ~]#
ipactl restart
smbclient
ユーティリティーを使用して、Samba が IdM からの Kerberos 認証に応答することを確認します。[root@ipaserver ~]#
smbclient -L server.idm.example.com -k
lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.12.3) ...
3.6.2. GPO を使用した Active Directory で AES 暗号化タイプの有効化
本セクションでは、グループポリシーオブジェクト (GPO) を使用して、Active Directory (AD) で AES 暗号化タイプを有効にする方法を説明します。IdM クライアントで Samba サーバーを実行するなど、RHEL 8 の機能には、この暗号化タイプが必要です。
RHEL 8 は、弱い DES および RC4 の暗号化タイプに対応していないことに注意してください。
前提条件
- グループポリシーを編集できるユーザーとして AD にログインしている。
-
Group Policy Management Console
がコンピューターにインストールされている。
手順
-
Group Policy Management Console
を開きます。 -
デフォルトドメインポリシー
を右クリックして、編集
を選択します。Group Policy Management Editor
を閉じます。 -
コンピューターの設定
→ポリシー
→Windows の設定
→セキュリティの設定
→ローカルポリシー
→セキュリティーオプション
に移動します。 -
ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する
をダブルクリックします。 -
AES256_HMAC_SHA1
を選択し、必要に応じて、将来の暗号化タイプ
を選択します。 - をクリックします。
-
Group Policy Management Editor
を閉じます。 -
既定のドメインコントローラーポリシー
に対して手順を繰り返します。 Windows ドメインコントローラー (DC) がグループポリシーを自動的に適用するまで待ちます。または、GPO を DC に手動で適用するには、管理者権限を持つアカウントを使用して次のコマンドを入力します。
C:\>
gpupdate /force /target:computer
3.6.3. IdM クライアントでの Samba サーバーのインストールおよび設定
本セクションでは、IdM ドメインに登録されたクライアントに Samba をインストールおよび設定する方法を説明します。
前提条件
- IdM サーバーとクライアントの両方が RHEL 8.1 以降で実行されている必要がある。
- IdM ドメインは、「Samba をドメインメンバーにインストールするための IdM ドメインの準備」で説明されているように準備されます。
- IdM に AD で設定された信頼がある場合は、Kerberos の AES 暗号化タイプを有効にします。たとえば、グループポリシーオブジェクト (GPO) を使用して、AES 暗号化の種類を有効にします。詳細は「GPO を使用した Active Directory で AES 暗号化タイプの有効化」を参照してください。
手順
ipa-client-samba
パッケージをインストールします。[root@idm_client]#
yum install ipa-client-samba
ipa-client-samba
ユーティリティーを使用して、クライアントを準備し、初期 Samba 構成を作成します。[root@idm_client]#
ipa-client-samba
Searching for IPA server... IPA server: DNS discovery Chosen IPA master: idm_server.idm.example.com SMB principal to be created: cifs/idm_client.idm.example.com@IDM.EXAMPLE.COM NetBIOS name to be used: IDM_CLIENT Discovered domains to use: Domain name: idm.example.com NetBIOS name: IDM SID: S-1-5-21-525930803-952335037-206501584 ID range: 212000000 - 212199999 Domain name: ad.example.com NetBIOS name: AD SID: None ID range: 1918400000 - 1918599999 Continue to configure the system with these values? [no]: yes Samba domain member is configured. Please check configuration at /etc/samba/smb.conf and start smb and winbind servicesデフォルトでは、
ipa-client-samba
は、ユーザーが接続したときにそのユーザーのホームディレクトリーを動的に共有するために、/etc/samba/smb.conf
ファイルに[homes]
セクションが自動的に追加されます。ユーザーがこのサーバーにホームディレクトリーがない場合、または共有したくない場合は、/etc/samba/smb.conf
から次の行を削除します。[homes] read only = no
ディレクトリーとプリンターを共有します。詳細は、次を参照してください。
ローカルファイアウォールで Samba クライアントに必要なポートを開きます。
[root@idm_client]#
firewall-cmd --permanent --add-service=samba-client
[root@idm_client]#firewall-cmd --reload
smb
サービスおよびwinbind
サービスを有効にして開始します。[root@idm_client]#
systemctl enable --now smb winbind
検証手順
samba-client
パッケージがインストールされている別の IdM ドメインメンバーで次の検証手順を実行します。
Kerberos チケット保証チケットの認証および取得
$
kinit example_user
Kerberos 認証を使用して、Samba サーバー上の共有を一覧表示します。
$
smbclient -L idm_client.idm.example.com
-k lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- example Disk IPC$ IPC IPC Service (Samba 4.12.3) ...
関連情報
-
設定中に
ipa-client-samba
が実行する手順の詳細は、man ページipa-client-samba(1)
を参照してください。
3.6.4. IdM が新しいドメインを信頼する場合は、IDマッピング構成を手動で追加
Samba では、ユーザーがリソースにアクセスする各ドメインの ID マッピング設定が必要です。IdM クライアントで実行している既存の Samba サーバーでは、管理者が Active Directory (AD) ドメインに新しい信頼を追加した後、ID マッピング設定を手動で追加する必要があります。
前提条件
- IdM クライアントで Samba を設定している。その後、IdM に新しい信頼を追加されています。
- Kerberos の暗号化タイプ DES および RC4 は、信頼できる AD ドメインで無効にしている。セキュリティー上の理由から、RHEL 8 はこのような弱い暗号化タイプに対応していません。
手順
ホストのキータブを使用して認証します。
[root@idm_client]#
kinit -k
ipa idrange-find
コマンドを使用して、新しいドメインのベース ID と ID 範囲のサイズの両方を表示します。たとえば、次のコマンドはad.example.com
ドメインの値を表示します。[root@idm_client]#
ipa idrange-find --name="AD.EXAMPLE.COM
_id_range" --raw --------------- 1 range matched --------------- cn: AD.EXAMPLE.COM_id_range ipabaseid: 1918400000 ipaidrangesize: 200000 ipabaserid: 0 ipanttrusteddomainsid: S-1-5-21-968346183-862388825-1738313271 iparangetype: ipa-ad-trust ---------------------------- Number of entries returned 1 ----------------------------次の手順で、
ipabaseid
属性およびipaidrangesize
属性の値が必要です。使用可能な最高の ID を計算するには、次の式を使用します。
maximum_range = ipabaseid + ipaidrangesize - 1
前の手順の値を使用すると、
ad.example.com
ドメインで使用可能な最大 ID は1918599999
(1918400000 + 200000 - 1) です。/etc/samba/smb.conf
ファイルを編集し、ドメインの ID マッピング構成を[global]
セクションに追加します。idmap config AD : range = 1918400000 - 1918599999 idmap config AD : backend = sss
ipabaseid
属性の値を最小値として指定し、前の手順で計算された値を範囲の最大値として指定します。smb
サービスおよびwinbind
サービスを再起動します。[root@idm_client]#
systemctl restart smb winbind
検証手順
新しいドメインからユーザーとして認証し、Kerberos チケット保証チケットを取得します。
$
kinit example_user
Kerberos 認証を使用して、Samba サーバー上の共有を一覧表示します。
$
smbclient -L idm_client.idm.example.com
-k lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- example Disk IPC$ IPC IPC Service (Samba 4.12.3) ...
3.6.5. 関連情報
-
RHEL 8 を IdM ドメインに参加させる方法の詳細は、
『Identity Management のインストール』
の「Identity Management クライアントのインストール」
を参照してください。
3.13. macOS クライアント向けの Samba の設定
fruit
仮想ファイルシステム (VFS) の Samba モジュールは、Apple サーバーメッセージブロック (SMB) クライアントとの互換性を強化します。
3.15. プリントサーバーとしての Samba の設定
Samba をプリントサーバーとして設定すると、ネットワーク上のクライアントが Samba を使用して印刷できます。さらに、Windows クライアントは、(Samba サーバーが設定されている場合は) Samba サーバーからドライバーをダウンロードすることもできます。
このセクションの一部は、Samba Wiki に公開されているドキュメント「Setting up Samba as a Print Server」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。
前提条件
Samba が、以下のいずれかのモードで設定されている。
3.15.1. 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 ...
3.15.2. Samba でのプリントサーバーのサポートの有効化
本セクションでは、Samba でプリントサーバーのサポートを有効にする方法を説明します。
手順
Samba サーバーで CUPS を設定し、そのプリンターを CUPS バックエンドに追加します。CUPS でプリンターを設定する方法は、プリントサーバーの CUPS Web コンソール (https://print_server_host_name:631/help) で提供されているドキュメントを参照してください。
注記Samba は、CUPS が Samba プリントサーバーにローカルにインストールされている場合に限り、CUPS に印刷ジョブを転送できます。
/etc/samba/smb.conf
ファイルを編集します。spoolssd
サービスを有効にする場合は、以下のパラメーターを[global]
セクションに追加します。rpc_server:spoolss = external rpc_daemon:spoolssd = fork
印刷バックエンドを設定するには、
[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 バックエンドに設定したすべてのプリンターを自動的に共有します。特定のプリンターのみを手動で共有する場合は、「特定のプリンターの手動共有」を参照してください。
3.15.3. 特定のプリンターの手動共有
Samba をプリントサーバーとして設定している場合、Samba は、デフォルトで CUPS バックエンドで設定されたプリンターをすべて共有します。以下の手順では、特定のプリンターのみを共有する方法を説明します。
前提条件
- Samba がプリントサーバーとして設定されている。
手順
/etc/samba/smb.conf
ファイルを編集します。[global]
セクションで、以下の設定で自動プリンター共有を無効にします。load printers = no
共有するプリンターごとにセクションを追加します。たとえば、Samba で CUPS バックエンドで
example
という名前のプリンターをExample-Printer
として共有するには、以下のセクションを追加します。[Example-Printer] path = /var/tmp/ printable = yes printer name = example
各プリンターに個別のスプールディレクトリーは必要ありません。
[printers]
セクションに設定したのと同じ spool ディレクトリーを、プリンターのpath
パラメーターに設定できます。
/etc/samba/smb.conf
ファイルを検証します。#
testparm
Samba 設定を再読み込みします。
#
smbcontrol all reload-config
3.16. Windows クライアント用の自動プリンタードライバーダウンロードの設定
Windows クライアント用に Samba プリントサーバーを実行している場合は、ドライバーをアップロードし、プリンターを事前設定できます。ユーザーがプリンターに接続すると、Windows により、ドライバーが自動的にクライアントにダウンロードされ、インストールされます。ユーザーがインストールするのに、ローカル管理者の権限を必要としません。また、Windows は、トレイの数などの事前設定済みのドライバー設定を適用します。
このセクションの一部は、Samba Wiki で公開されているドキュメント「Setting up Automatic Printer Driver Downloads for Windows Clients」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。
前提条件
- Samba がプリントサーバーとして設定されている。
3.16.1. プリンタードライバーに関する基本情報
本セクションでは、プリンタードライバーに関する一般的な情報を説明します。
対応しているドライバーモデルのバージョン
Samba は、Windows 2000 以降および Windows Server 2000 以降でサポートされているプリンタードライバーのモデルバージョン 3 のみに対応します。Samba は、Windows 8 および Windows Server 2012 で導入されたドライバーモデルのバージョン 4 には対応していません。ただし、これ以降の Windows バージョンは、バージョン 3 のドライバーにも対応しています。
パッケージ対応ドライバー
Samba は、パッケージ対応ドライバーに対応していません。
アップロードするプリンタードライバーの準備
Samba プリントサーバーにドライバーをアップロードする場合は、以下を行います。
- ドライバーが圧縮形式で提供されている場合は、ドライバーを展開します。
一部のドライバーでは、Windows ホストにドライバーをローカルにインストールするセットアップアプリケーションを起動する必要があります。特定の状況では、インストーラーはセットアップの実行中にオペレーティングシステムの一時フォルダーに個別のファイルを抽出します。アップロードにドライバーファイルを使用するには、以下のコマンドを実行します。
- インストーラーを起動します。
- 一時フォルダーから新しい場所にファイルをコピーします。
- インストールをキャンセルします。
プリントサーバーへのアップロードをサポートするドライバーは、プリンターの製造元にお問い合わせください。
クライアントに 32 ビットおよび 64 ビットのプリンター用ドライバーを提供
32 ビットと 64 ビットの両方の Windows クライアントのプリンターにドライバーを提供するには、両方のアーキテクチャーに対して、同じ名前のドライバーをアップロードする必要があります。たとえば、32 ビットのドライバー Example PostScript
および 64 ビットのドライバー Example PostScript (v1.0)
をアップロードする場合は、その名前が一致しません。その結果、ドライバーのいずれかをプリンターに割り当てることしかできなくなり、両方のアーキテクチャーでそのドライバーが使用できなくなります。
3.16.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
3.16.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
を開きます。 ウィンドウの右側で、
Point and Print Restriction
をダブルクリックして、ポリシーを編集します。ポリシーを有効にし、以下のオプションを設定します。
-
Users can only point and print to these servers
を選択し、このオプションの横にあるフィールドに、Samba プリントサーバーの完全修飾ドメイン名 (FQDN) を入力します。 Security Prompts
の両チェックボックスで、Do not show warning or elevation prompt
を選択します。
-
- OK をクリックします。
Package Point and Print - Approved servers
をダブルクリックして、ポリシーを編集します。-
ポリシーを有効にして、
Show
ボタンをクリックします。 Samba プリントサーバーの FQDN を入力します。
-
OK
をクリックして、Show Contents
ウィンドウとポリシーのプロパティーウィンドウの両方を閉じます。
-
ポリシーを有効にして、
-
Group Policy Management Editor
を閉じます。 -
Group Policy Management Console
を閉じます。
Windows ドメインメンバーがこのグループポリシーを適用すると、ユーザーがプリンターに接続する際に、プリンタードライバーが Samba サーバーから自動的にダウンロードされます。
関連情報
- グループポリシーの使用方法の詳細は、Windows のドキュメントを参照してください。
3.16.5. ドライバーのアップロードおよびプリンターの事前設定
Windows クライアントで Print Management
アプリケーションを使用してドライバーをアップロードし、Samba プリントサーバーでホストされるプリンターを事前設定します。詳細は、Windows のドキュメントを参照してください。
3.17. Samba サーバーのパフォーマンスチューニング
本章では、特定の状況で Samba のパフォーマンスを改善できる設定と、パフォーマンスが低下する可能性のある設定を説明します。
このセクションの一部は、Samba Wiki に公開されているドキュメント「Performance Tuning」に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。
前提条件
- Samba が、ファイルサーバーまたはプリントサーバーとして設定されている。
3.17.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
3.17.3. パフォーマンスが低下する可能性のある設定
デフォルトでは、Red Hat Enterprise Linux のカーネルは、ネットワークパフォーマンスが高くなるように調整されています。たとえば、カーネルはバッファーサイズに自動チューニングメカニズムを使用しています。/etc/samba/smb.conf
ファイルに socket options
パラメーターを設定すると、このカーネル設定が上書きされます。その結果、このパラメーターの設定により、ほとんどの場合は、Samba ネットワークのパフォーマンスが低下します。
カーネルの最適化された設定を使用するには、/etc/samba/smb.conf
の [global]
セクションから socket options
パラメーターを削除します。
3.18. Samba が、SMB バージョンがデフォルトよりも低いクライアントと互換性するように設定
Samba は、サポートしている最小サーバーメッセージブロック (SMB) バージョンに妥当で安全なデフォルト値を使用します。ただし、古い SMB バージョンを必要とするクライアントがある場合は、Samba を設定してサポートできます。
3.18.1. Samba サーバーで対応している最小 SMB プロトコルバージョンの設定
Samba では、/etc/samba/smb.conf
ファイルの server min protocol
パラメーターは、Samba サーバーが対応する SMB (server message block) プロトコルの最小バージョンを定義します。本セクションでは、SMB プロトコルの最小バージョンを変更する方法を説明します。
デフォルトでは、RHEL 8.2 以降の Samba では、SMB2 以降のプロトコルバージョンのみに対応します。Red Hat は、非推奨の SMB1 プロトコルを使用することは推奨されません。ただし、お使いの環境で SMB1 が必要な場合は、server min protocol
パラメーターを手動で NT1
に設定して、SMB1 を再度有効にできます。
前提条件
- Samba がインストールされ、設定されている。
手順
/etc/samba/smb.conf
ファイルを編集し、server min protocol
パラメーターを追加して、そのサーバーが対応する最小 SMB プロトコルバージョンに設定できます。たとえば、最小の SMB プロトコルバージョンをSMB3
に設定するには、以下を追加します。server min protocol = SMB3
smb
サービスを再起動します。#
systemctl restart smb
関連情報
-
server min protocol
パラメーターに設定できるプロトコルバージョンの一覧は、man ページのsmb.conf(5)
のserver max protocol
パラメーターの説明を参照してください。
3.19. 頻繁に使用される Samba コマンドラインユーティリティー
本章では、Samba サーバーで作業する場合によく使用されるコマンドを説明します。
3.19.1. net ads join コマンドおよび net rpc join コマンドの使用
net
ユーティリティーの join
サブコマンドを使用すると、Samba を AD ドメインまたは NT4 ドメインに参加させることができます。ドメインに参加するには、/etc/samba/smb.conf
ファイルを手動で作成し、必要に応じて PAM などの追加設定を更新する必要があります。
Red Hat は、realm
ユーティリティーを使用してドメインに参加させることを推奨します。realm
ユーティリティーは、関連するすべての設定ファイルを自動的に更新します。
手順
以下の設定で
/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 マッピング設定を追加します。 /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: fileswinbind
winbind
サービスを有効にして起動します。#
systemctl enable --now winbind
必要に応じて、
authselect
ユーティリティーを使用して PAM を設定します。詳細は、man ページの
authselect(8)
を参照してください。AD 環境では、必要に応じて Kerberos クライアントを設定します。
詳細は、Kerberos クライアントのドキュメントを参照してください。
3.19.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.
3.19.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
いいえ 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
3.19.5. rpcclient ユーティリティーの使用
rpcclient
ユーティリティーを使用すると、ローカルまたはリモートの SMB サーバーでクライアント側の Microsoft Remote Procedure Call (MS-RPC) 機能を手動で実行できます。ただし、ほとんどの機能は、Samba が提供する個別のユーティリティーに統合されています。rpcclient
は、MS-PRC 関数のテストにのみ使用します。
前提条件
-
samba-client
パッケージがインストールされている。
例
たとえば、rpcclient
ユーティリティーを使用して以下を行うことができます。
プリンターのスプールサブシステム (SPOOLSS) を管理します。
例3.7 プリンターへのドライバーの割り当て
#
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 サーバーに関する情報を取得します。
例3.8 すべてのファイル共有および共有プリンターの一覧表示
#
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) プロトコルを使用して操作を実行します。
例3.9 SMB サーバー上のユーザーの一覧表示
#
rpcclient server_name
-U "DOMAIN\administrator" -c 'enumdomusers' Enter DOMAIN\administrators password: user:[user1] rid:[0x3e8] user:[user2] rid:[0x3e9]スタンドアロンサーバーまたはドメインメンバーに対してコマンドを実行すると、ローカルデータベースのユーザーの一覧が表示されます。ADDC または NT4 PDC に対してコマンドを実行すると、ドメインユーザーの一覧が表示されます。
関連情報
サポートされるサブコマンドの一覧は、man ページの rpcclient(1)
の COMMANDS
セクションを参照してください。
3.19.6. samba-regedit アプリケーションの使用
プリンター設定などの特定の設定は、Samba サーバーのレジストリーに保存されます。ncurses ベースの samba-regedit
アプリケーションを使用して、Samba サーバーのレジストリーを編集できます。
前提条件
-
samba-client
パッケージがインストールされている。
手順
アプリケーションを起動するには、次のコマンドを入力します。
# samba-regedit
次のキーを使用します。
- カーソルを上下に動かして、レジストリーツリーと値の間を移動します。
- Enter - キーを開くか、値を編集します。
-
Tab -
Key
ペインとValue
ペインを切り替えます。 - Ctrl+C - アプリケーションを閉じます。
3.19.7. smbcontrol ユーティリティーの使用
smbcontrol
ユーティリティーを使用すると、smbd
、nmbd
、winbindd
、またはこのすべてのサービスにコマンドメッセージを送信できます。この制御メッセージは、設定の再読み込みなどのサービスを指示します。
本セクションの手順では、reload-config
メッセージタイプを すべて
の宛先に送信することで、smbd
、nmbd
、winbindd
のサービスの設定を再読み込みする方法を示します。
前提条件
-
samba-common-tools
パッケージがインストールされている。
手順
# smbcontrol all reload-config
関連情報
詳細情報および利用可能なコマンドメッセージタイプの一覧は、man ページの smbcontrol(1)
を参照してください。
3.19.8. smbpasswd ユーティリティーの使用
smbpasswd
ユーティリティーは、ローカルの Samba データベースでユーザーアカウントおよびパスワードを管理します。
前提条件
-
samba-common-tools
パッケージがインストールされている。
手順
ユーザーとしてコマンドを実行すると、
smbpasswd
はコマンドを実行するユーザーの Samba パスワードを変更します。以下に例を示します。[user@server ~]$
smbpasswd
New SMB password: password Retype new SMB password: passwordroot
でsmbpasswd
を実行すると、たとえば以下のようにユーティリティーを使用できます。新しいユーザーを作成します。
[root@server ~]#
smbpasswd -a user_name
New SMB password:password
` Retype new SMB password: [command]password` Added user user_name.注記Samba データベースにユーザーを追加する前に、ローカルのオペレーティングシステムにアカウントを作成する必要があります。『基本的なシステム設定の構成』の「コマンドラインでの新規ユーザーの追加」セクションを参照してください。
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.
関連情報
詳細は、man ページの smbpasswd(8)
を参照してください。
3.19.9. smbstatus ユーティリティーの使用
smbstatus
ユーティリティーは以下について報告します。
-
各
smbd
デーモンの PID ごとの接続を Samba サーバーに接続します。このレポートには、ユーザー名、プライマリグループ、SMB プロトコルのバージョン、暗号、および署名の情報が含まれます。 -
Samba 共有ごとの接続このレポートには、
smbd
デーモンの PID、接続しているマシンの IP、接続が確立された時点のタイムスタンプ、暗号、および署名情報が含まれます。 - ロックされたファイルの一覧。レポートエントリーには、日和見ロック (oplock) タイプなどの詳細が含まれます。
前提条件
-
samba
パッケージがインストールされている。 -
smbd
サービスが実行している。
手順
# smbstatus
Samba version 4.12.3
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
関連情報
詳細は、man ページの smbstatus(1)
を参照してください。
3.19.10. smbtar ユーティリティーの使用
smbtar
ユーティリティーは、SMB 共有またはそのサブディレクトリーのコンテンツのバックアップを作成し、そのコンテンツを tar
アーカイブに保存します。または、コンテンツをテープデバイスに書き込むこともできます。
前提条件
-
samba-client
パッケージがインストールされている。
手順
以下のコマンドを使用して、
//server/example/
共有上のdemo
ディレクトリーのコンテンツをバックアップして、/root/example.tar
アーカイブにコンテンツを保存するには、以下を実行します。#
smbtar -s server
-x example -u user_name -p password -t /root/example.tar
関連情報
詳細は、man ページの smbtar(1)
を参照してください。
3.19.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
関連情報
詳細は、man ページの wbinfo(1)
を参照してください。
第5章 NFS のセキュア化
サーバーで NFS ファイルシステムをエクスポートする場合や、クライアントにマウントする際に、NFS セキュリティーリスクを最小限に抑え、サーバーのデータを保護するには、以下のセクションを検討してください。
5.1. AUTH_SYS とエクスポート制御による NFS 保護
NFS は、エクスポートしたファイルへのアクセスを制御するために、以下の従来のオプションを提供します。
- サーバーは、IP アドレスまたはホスト名を使用して、どのホストにどのファイルシステムのマウントを許可するかをサーバー側で制限します。
-
サーバーは、ローカルユーザーの場合と同じ方法で、NFS クライアントのユーザーに対してファイルシステムの権限を強制します。従来は、NFS は
AUTH_SYS
コールメッセージ (AUTH_UNIX
とも呼ばれます) を使用してこれを実行していました。このメッセージは、クライアントが、ユーザーの UID と GID を提示します。これは、悪意のあるクライアントや誤って設定されたクライアントが簡単にこの間違いを招き、ユーザーがアクセスすべきではないファイルにアクセスできる可能性があることを意味します。
潜在的なリスクを制限するため、多くの場合、管理者は、共通のユーザー ID およびグループ ID に対して、ユーザー権限を読み取り専用にするか、権限を下げてアクセスを制限します。ただし、このソリューションにより、NFS 共有が元々想定されている方法では使用されなくなります。
さらに、攻撃者が、NFS ファイルシステムをエクスポートするシステムが使用する DNS サーバーを制御できた場合は、特定のホスト名または完全修飾ドメイン名に関連付けられたシステムを、承認されていないマシンに指定できます。これで、認証されていないマシンは、NFS 共有のマウントを許可するシステムになります。これは、ユーザー名やパスワードの情報が交換されず、NFS マウントに追加のセキュリティーが提供されるためです。
NFS 経由でディレクトリーのエクスポートを行う際にワイルドカードを使用する場合は慎重に行ってください。ワイルドカードの対象が予定よりも広い範囲のシステムを対象とする可能性があります。
関連情報
-
NFS および
rpcbind
のセキュリティーを保護するには、nftables
、firewalld
などを使用します。これらのフレームワークの設定の詳細は、man ページのnft(8)
およびfirewalld-cmd(1)
を参照してください。
5.2. AUTH_GSS
を使用した NFS セキュリティー
NFS の全バージョンは、RPCSEC_GSS および Kerberos のメカニズムに対応します。
AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、サーバーは、どのユーザーがそのファイルにアクセスしているかを正確に表すことをクライアントに依存しません。代わりに、暗号を使用してサーバーにユーザーを認証し、悪意のあるクライアントがそのユーザーの Kerberos 認証情報を持たずにユーザーになりすますことがないようにします。RPCSEC_GSS Kerberos メカニズムを使用することが、マウントを保護する最も簡単な方法になります。Kerberos の設定後は、追加の設定が不要になるためです。
5.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
を作成します。 - クライアントとサーバーのキータブに、対応する鍵を追加します。
-
NFS サーバー側で、
サーバーで、
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
関連情報
- Kerberos で保護された NFS 共有で root としてファイルを作成し、このファイルの root 所有権を維持する必要がある場合は、https://access.redhat.com/articles/4040141を参照してください。この設定は推奨されません。
- NFS 設定の詳細は、man ページの exports(5) および nfs(5) を参照してください。
5.4. NFSv4 セキュリティーオプション
NFSv4 には、Microsoft Windows NT モデルの機能や幅広い導入の経緯があるため、POSIX モデルではなく、Microsoft Windows NT モデルをベースとした ACL サポートが含まれます。
NFSv4 のもう 1 つの重要なセキュリティー機能は、ファイルシステムのマウントに MOUNT
プロトコルを使用しなくなることです。MOUNT
プロトコルは、プロトコルがファイルを処理する方法により、セキュリティー上のリスクが発生します。
5.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
オプションの使用を検討してください。このオプションでは、エクスポートしたファイルシステムにアクセスするすべてのユーザーが、nobody
ユーザーのユーザー ID を取得します。
第6章 NFS での pNFS SCSI レイアウトの有効化
データのアクセスに pNFS SCSI レイアウトを使用するように、NFS サーバーおよびクライアントを設定できます。pNFS SCSI は、ファイルへの長期接続のシングルクライアントアクセスに伴うユースケースで利点があります。
前提条件
- クライアントとサーバーの両方で、SCSI コマンドを同じブロックデバイスに送信する必要があります。つまり、ブロックデバイスは共有 SCSI バス上になければなりません。
- ブロックデバイスに XFS ファイルシステムが含まれている必要があります。
- SCSI デバイスは、 SCSI-3 Primary Commands 仕様で説明されているように、SCSI Persistent Reservation に対応している必要があります。
6.1. pNFS テクノロジー
pNFS アーキテクチャーでは、NFS のスケーラビリティーが改善されます。サーバーに pNFS が実装されると、クライアントは複数のサーバーで同時にデータにアクセスできるようになります。これにより、パフォーマンスが向上します。
pNFS は、RHEL では以下のストレージプロトコルまたはレイアウトに対応しています。
- ファイル
- Flexfiles
- SCSI
6.2. pNFS SCSI レイアウト
SCSI レイアウトは、pNFS ブロックレイアウトの作業に基づいています。このレイアウトは、SCSI デバイス全体に定義されます。これには、SCSI 永続予約に対応する必要がある論理ユニット (lUS) として、固定サイズのブロックが連続的に含まれています。LU デバイスは、SCSI デバイスの識別子で識別されます。
pNFS SCSI は、ファイルへの長期接続のシングルクライアントアクセスのユースケースで適切に実行されます。例として、メールサーバーまたはクラスターを格納している仮想マシンなどが挙げられます。
クライアントとサーバーとの間の操作
NFS クライアントが、ファイルからの読み取り、またはファイルへの書き込みを行うと、クライアントは LAYOUTGET
操作を実行します。サーバーは、SCSI デバイスのファイルの場所に反応します。このクライアントは、使用する SCSI デバイスを判断するために、GETDEVICEINFO
の追加操作が必要になる場合があります。正しく動作するのであれば、クライアントは、READ
操作および WRITE
操作をサーバーに送信する代わりに、SCSI デバイスに直接 I/O 要求を発行することができます。
クライアント間のエラーまたは競合により、サーバーがレイアウトを再び呼び出したり、クライアントにレイアウトを発行しなくなることがあります。この場合、クライアントは、SCSI デバイスに I/O 要求を直接送信するのではなく、サーバーへの READ
操作および WRITE
操作を再び実行します。
操作を監視するには、「pNFS SCSI レイアウト機能の監視」を参照してください。
デバイスの予約
pNFS SCSI は、予約の割り当てを通じてフェンシングを処理します。サーバーがレイアウトをクライアントに発行する前に、SCSI デバイスを予約して、登録したクライアントのみがデバイスにアクセスできるようにします。クライアントが、その SCSI デバイスに対してコマンドを実行できても、そのデバイスに登録されていない場合は、クライアントからの多くの操作が、そのデバイス上で失敗します。たとえば、サーバーが、そのデバイスのレイアウトをクライアントに送信していないと、クライアントの blkid
コマンドは、XFS ファイルシステムの UUID を表示できません。
サーバーは、独自の永続予約を削除しません。これにより、クライアントやサーバーの再起動時に、デバイスのファイルシステム内のデータが保護されます。SCSI デバイスを他の目的で使用するには、NFS サーバーで、手動で永続予約を削除する必要があります。
6.3. pNFS と互換性がある SCSI デバイスの確認
この手順では、SCSI デバイスが pNFS SCSI レイアウトに対応しているかどうかを確認します。
前提条件
以下のコマンドで、
sg3-utils
パッケージがインストールされている。# yum install sg3_utils
手順
サーバーおよびクライアントの両方で、適切な SCSI デバイスサポートを確認します。
# sg_persist --in --report-capabilities --verbose path-to-scsi-device
Persist Through Power Loss Active (
PTPL_A
) ビットが設定されるようにします。例6.1 pNFS SCSI をサポートする SCSI デバイス
以下は、pNFS SCSI に対応する SCSI デバイスにおける
sg_persist
出力の例になります。PTPL_A
ビットが1
を報告します。inquiry cdb: 12 00 00 00 24 00 Persistent Reservation In cmd: 5e 02 00 00 00 00 00 20 00 00 LIO-ORG block11 4.0 Peripheral device type: disk Report capabilities response: Compatible Reservation Handling(CRH): 1 Specify Initiator Ports Capable(SIP_C): 1 All Target Ports Capable(ATP_C): 1 Persist Through Power Loss Capable(PTPL_C): 1 Type Mask Valid(TMV): 1 Allow Commands: 1 Persist Through Power Loss Active(PTPL_A): 1 Support indicated in Type mask: Write Exclusive, all registrants: 1 Exclusive Access, registrants only: 1 Write Exclusive, registrants only: 1 Exclusive Access: 1 Write Exclusive: 1 Exclusive Access, all registrants: 1
関連情報
-
man ページの
sg_persist(8)
6.4. サーバーで pNFS SCSI の設定
この手順では、NFS サーバーが pNFS SCSI レイアウトをエクスポートするように設定します。
手順
- サーバーで、SCSI デバイスで作成した XFS ファイルシステムをマウントします。
NFS バージョン 4.1 以降をエクスポートするように NFS サーバーを設定します。
/etc/nfs.conf
ファイルの[nfsd]
セクションに、以下のオプションを設定します。[nfsd] vers4.1=y
pnfs
オプションを指定して、NFS で XFS ファイルシステムをエクスポートするように NFS サーバーを設定します。例6.2 pNFS SCSI をエクスポートする /etc/exports のエントリー
/etc/exports
設定ファイルの以下のエントリーにより、/exported/directory/
にマウントされているファイルシステムを、pNFS SCSI レイアウトとしてallowed.example.com
クライアントにエクスポートします。/exported/directory allowed.example.com(pnfs)
関連情報
- NFS サーバーの設定の詳細は、4章NFS 共有のエクスポートを参照してください。
6.5. クライアントで pNFS SCSI の設定
この手順では、pNFS SCSI レイアウトをマウントするように NFS クライアントを設定します。
前提条件
- NFS サーバーは、pNFS SCSI で XFS ファイルシステムをエクスポートするように設定されています。「サーバーで pNFS SCSI の設定」を参照してください。
手順
クライアントで、NFS バージョン 4.1 以降を使用して、エクスポートした XFS ファイルシステムをマウントします。
# mount -t nfs -o nfsvers=4.1 host:/remote/export /local/directory
NFS なしで XFS ファイルシステムを直接マウントしないでください。
関連情報
- NFS 共有のマウントの詳細は、「NFS 共有のマウント」を参照してください。
6.6. サーバーで pNFS SCSI 予約のリリース
この手順では、NFS サーバーが SCSI デバイスを維持している永続的な予約を解放します。これにより、pNFS SCSI をエクスポートする必要がなくなったら、SCSI デバイスを別の目的で使用できるようになります。
サーバーから予約を削除する必要があります。別の IT Nexus から削除することはできません。
前提条件
以下のコマンドで、
sg3-utils
パッケージがインストールされている。# yum install sg3_utils
手順
サーバーで、既存の予約をクエリーします。
# sg_persist --read-reservation path-to-scsi-device
例6.3 /dev/sda での予約のクエリー
# sg_persist --read-reservation /dev/sda LIO-ORG block_1 4.0 Peripheral device type: disk PR generation=0x8, Reservation follows: Key=0x100000000000000 scope: LU_SCOPE, type: Exclusive Access, registrants only
サーバーにある既存の登録を削除します。
# sg_persist --out \ --release \ --param-rk=reservation-key \ --prout-type=6 \ path-to-scsi-device
例6.4 /dev/sda にある予約の削除
# sg_persist --out \ --release \ --param-rk=0x100000000000000 \ --prout-type=6 \ /dev/sda LIO-ORG block_1 4.0 Peripheral device type: disk
関連情報
-
man ページの
sg_persist(8)
6.7. pNFS SCSI レイアウト機能の監視
pNFS クライアントとサーバーで、pNFS SCSI 操作が適切に行われることを犠牲にしているかどうか、または通常の NFS 操作にフォールバックするかどうかを監視できます。
前提条件
- pNFS SCSI クライアントとサーバーが設定されている。
6.7.1. nfsstat でサーバーの pNFS SCSI 操作の確認
この手順では、nfsstat
ユーティティを使用して、サーバーから pNFS SCSI 操作を監視します。
手順
サーバーから操作サービスを監視します。
# watch --differences \ "nfsstat --server | egrep --after-context=1 read\|write\|layout" Every 2.0s: nfsstat --server | egrep --after-context=1 read\|write\|layout putrootfh read readdir readlink remove rename 2 0% 0 0% 1 0% 0 0% 0 0% 0 0% -- setcltidconf verify write rellockowner bc_ctl bind_conn 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% -- getdevlist layoutcommit layoutget layoutreturn secinfononam sequence 0 0% 29 1% 49 1% 5 0% 0 0% 2435 86%
クライアントとサーバーは、以下の場合に pNFS SCSI 操作を使用します。
-
layoutget
カウンター、layoutreturn
カウンター、およびlayoutcommit
カウンターがインクリメントします。これは、サーバーがレイアウトを提供することを意味します。 -
サーバーの
read
カウンターおよびwrite
カウンターはインクリメントしません。これは、クライアントが SCSI デバイスに直接 I/O 要求を実行していることを意味します。
-
6.7.2. mountstats でクライアントからの pNFS SCSI 操作の確認
この手順では、/proc/self/mountstats
ファイルを使用して、クライアントから pNFS SCSI 操作を監視します。
手順
マウントごとの操作カウンターを一覧表示します。
# cat /proc/self/mountstats \ | awk /scsi_lun_0/,/^$/ \ | egrep device\|READ\|WRITE\|LAYOUT device 192.168.122.73:/exports/scsi_lun_0 mounted on /mnt/rhel7/scsi_lun_0 with fstype nfs4 statvers=1.1 nfsv4: bm0=0xfdffbfff,bm1=0x40f9be3e,bm2=0x803,acl=0x3,sessions,pnfs=LAYOUT_SCSI READ: 0 0 0 0 0 0 0 0 WRITE: 0 0 0 0 0 0 0 0 READLINK: 0 0 0 0 0 0 0 0 READDIR: 0 0 0 0 0 0 0 0 LAYOUTGET: 49 49 0 11172 9604 2 19448 19454 LAYOUTCOMMIT: 28 28 0 7776 4808 0 24719 24722 LAYOUTRETURN: 0 0 0 0 0 0 0 0 LAYOUTSTATS: 0 0 0 0 0 0 0 0
結果は以下のようになります。
-
LAYOUT
統計は、クライアントとサーバーが pNFS SCSI 操作を使用する要求を示します。 -
READ
およびWRITE
の統計は、クライアントとサーバーが NFS 操作にフォールバックする要求を示します。
-
第7章 Squid キャッシングプロキシーサーバーの設定
Squid は、コンテンツをキャッシュして帯域幅を削減し、Web ページをより迅速に読み込むプロキシーサーバーです。本章では、HTTP、HTTPS、FTP のプロトコルのプロキシーとして Squid を設定する方法と、アクセスの認証および制限を説明します。
7.1. 認証なしで Squid をキャッシングプロキシーとして設定
本セクションでは、認証なしでキャッシュプロキシーとして Squid の基本設定を説明します。以下の手順では、IP 範囲に基づいてプロキシーへのアクセスを制限します。
前提条件
-
/etc/squid/squid.conf
ファイルが、squid
パッケージにより提供されている。このファイルを編集した場合は、ファイルを削除して、パッケージを再インストールしている。
手順
squid
パッケージをインストールします。# yum install squid
/etc/squid/squid.conf
ファイルを編集します。localnet
の ACL (Access Control Lists) を、プロキシーを使用できる IP 範囲と一致するように変更します。acl localnet src 192.0.2.0/24 acl localnet 2001:db8:1::/64
デフォルトでは、
/etc/squid/squid.conf
ファイルには、localnet
の ACL に指定したすべての IP 範囲のプロキシーの使用を許可するhttp_access allow localnet
ルールが含まれます。http_access allow localnet
ルールの前に、localnet
の ACL をすべて指定する必要があります。重要お使いの環境に一致しない既存の
acl localnet
エントリーをすべて削除します。以下の ACL はデフォルト設定に含まれ、HTTPS プロトコルを使用するポートとして
443
を定義します。acl SSL_ports port 443
ユーザーが他のポートでも HTTPS プロトコルを使用できるようにするには、ポートごとに ACL を追加します。
acl SSL_ports port port_number
Squid が接続を確立できるポートに設定する
acl Safe_ports
ルールの一覧を更新します。たとえば、プロキシーを使用するクライアントがポート 21 (FTP)、80 (HTTP)、443 (HTTPS) のリソースにのみアクセスできるようにするには、設定に次のacl Safe_ports
ステートメントのみを保持します。acl Safe_ports port 21 acl Safe_ports port 80 acl Safe_ports port 443
デフォルトでは、設定には、
Safe_ports
ACL に定義されていないポートへのアクセス拒否を定義するhttp_access deny !Safe_ports
ルールが含まれています。cache_dir
パラメーターにキャッシュの種類、キャッシュディレクトリーへのパス、キャッシュサイズ、さらにキャッシュの種類ごとの設定を構成します。cache_dir ufs /var/spool/squid 10000 16 256
この設定により、以下が可能になります。
-
Squid は、キャッシュの種類
ufs
を使用します。 -
Squid は、キャッシュを
/var/spool/squid/
ディレクトリーに保存します。 -
キャッシュのサイズが最大
10000
MB になります。 -
Squid は、
/var/spool/squid/
ディレクトリーに16
個のレベル 1 サブディレクトリーを作成します。 Squid は、レベル 1 の各ディレクトリーに
256
個のサブディレクトリーを作成します。cache_dir
ディレクティブを設定しないと、Squid はキャッシュをメモリーに保存します。
-
Squid は、キャッシュの種類
cache_dir
パラメーターに/var/spool/squid/
以外のキャッシュディレクトリーを設定する場合は、以下を行います。キャッシュディレクトリーを作成します。
# mkdir -p path_to_cache_directory
キャッシュディレクトリーの権限を設定します。
# chown squid:squid path_to_cache_directory
SELinux を、
Enforcing
モードで実行する場合は、キャッシュディレクトリー用にsquid_cache_t
コンテキストを設定します。# semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?" # restorecon -Rv path_to_cache_directory
semanage
ユーティリティーがシステムで利用できない場合は、policycoreutils-python-utils
パッケージをインストールします。
ファイアウォールで
3128
ポートを開きます。# firewall-cmd --permanent --add-port=3128/tcp # firewall-cmd --reload
squid
サービスを有効にして開始します。# systemctl enable --now squid
検証手順
プロキシーが正しく機能することを確認するには、curl
ユーティリティーを使用して Web ページをダウンロードします。
# curl -O -L "https://www.redhat.com/index.html" -x "proxy.example.com:3128"
curl
でエラーが表示されず、index.html
ファイルが現在のディレクトリーにダウンロードされている場合は、プロキシーが動作します。
7.2. LDAP 認証を使用したキャッシングプロキシーとしての Squid の設定
本セクションでは、LDAP を使用してユーザーを認証するキャッシングプロキシーとしての Squid の基本設定を説明します。この手順では、認証されたユーザーのみがプロキシーを使用できるように設定します。
前提条件
-
/etc/squid/squid.conf
ファイルが、squid
パッケージにより提供されている。このファイルを編集した場合は、ファイルを削除して、パッケージを再インストールしている。 -
uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com
などのサービスユーザーが LDAP ディレクトリーに存在している。Squid はこのアカウントを使用して認証ユーザーを検索します。認証ユーザーが存在する場合、Squid はこのユーザーをディレクトリーにバインドして、認証を確認します。
手順
squid
パッケージをインストールします。# yum install squid
/etc/squid/squid.conf
ファイルを編集します。basic_ldap_auth
ヘルパーユーティリティーを設定するには、/etc/squid/squid.conf
の上部に以下の設定エントリーを追加します。auth_param basic program /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D "uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389
以下は、上記の例で
basic_ldap_auth
ヘルパーユーティリティーに渡されるパラメーターを説明します。-
-B base_DN
は、LDAP 検索ベースを設定します。 -
-D proxy_service_user_DN
は、Squid が、ディレクトリー内の認証ユーザーを検索する際に使用するアカウントの識別名 (DN) を設定します。 -
-W path_to_password_file
は、プロキシーサービスユーザーのパスワードが含まれるファイルへのパスを設定します。パスワードファイルを使用すると、オペレーティングシステムのプロセス一覧にパスワードが表示されなくなります。 -f LDAP_filter
は 、DAP 検索フィルターを指定します。Squid は、%s
変数を、認証ユーザーが提供するユーザー名に置き換えます。上記の例の
(&(objectClass=person)(uid=%s))
フィルターは、ユーザー名がuid
属性に設定された値と一致する必要があり、ディレクトリーエントリーにperson
オブジェクトクラスが含まれることを定義します。-ZZ
は、STARTTLS
コマンドを使用して、LDAP プロトコルで TLS 暗号化接続を強制します。以下の状況で-ZZ
を省略します。- LDAP サーバーは、暗号化された接続にを対応しません。
- URL に指定されたポートは、LDAPS プロトコルを使用します。
- -H LDAP_URL パラメーターは、プロトコル、ホスト名、IP アドレス、および LDAP サーバーのポートを URL 形式で指定します。
-
以下の ACL およびルールを追加して、Squid で、認証されたユーザーのみがプロキシーを使用できるように設定します。
acl ldap-auth proxy_auth REQUIRED http_access allow ldap-auth
重要これらの設定は、
http_access deny
all ルールの前に指定します。次のルールを削除して、
localnet
ACL で指定された IP 範囲のプロキシー認証を無効にします。http_access allow localnet
以下の ACL はデフォルト設定に含まれ、HTTPS プロトコルを使用するポートとして
443
を定義します。acl SSL_ports port 443
ユーザーが他のポートでも HTTPS プロトコルを使用できるようにするには、ポートごとに ACL を追加します。
acl SSL_ports port port_number
Squid が接続を確立できるポートに設定する
acl Safe_ports
ルールの一覧を更新します。たとえば、プロキシーを使用するクライアントがポート 21 (FTP)、80 (HTTP)、443 (HTTPS) のリソースにのみアクセスできるようにするには、設定に次のacl Safe_ports
ステートメントのみを保持します。acl Safe_ports port 21 acl Safe_ports port 80 acl Safe_ports port 443
デフォルトでは、設定には、
Safe_ports ACL
に定義されていないポートにアクセス拒否を定義するhttp_access deny !Safe_ports
ルールが含まれています。cache_dir
パラメーターにキャッシュの種類、キャッシュディレクトリーへのパス、キャッシュサイズ、さらにキャッシュの種類ごとの設定を構成します。cache_dir ufs /var/spool/squid 10000 16 256
この設定により、以下が可能になります。
-
Squid は、キャッシュの種類
ufs
を使用します。 -
Squid は、キャッシュを
/var/spool/squid/
ディレクトリーに保存します。 -
キャッシュのサイズが最大
10000
MB になります。 -
Squid は、
/var/spool/squid/
ディレクトリーに16
個のレベル 1 サブディレクトリーを作成します。 Squid は、レベル 1 の各ディレクトリーに
256
個のサブディレクトリーを作成します。cache_dir
ディレクティブを設定しないと、Squid はキャッシュをメモリーに保存します。
-
Squid は、キャッシュの種類
cache_dir
パラメーターに/var/spool/squid/
以外のキャッシュディレクトリーを設定する場合は、以下を行います。キャッシュディレクトリーを作成します。
# mkdir -p path_to_cache_directory
キャッシュディレクトリーの権限を設定します。
# chown squid:squid path_to_cache_directory
SELinux を、
Enforcing
モードで実行する場合は、キャッシュディレクトリー用にsquid_cache_t
コンテキストを設定します。# semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?" # restorecon -Rv path_to_cache_directory
semanage
ユーティリティーがシステムで利用できない場合は、policycoreutils-python-utils
パッケージをインストールします。
LDAP サービスユーザーのパスワードを
/etc/squid/ldap_password
ファイルに保存し、そのファイルに適切なパーミッションを設定します。# echo "password" > /etc/squid/ldap_password # chown root:squid /etc/squid/ldap_password # chmod 640 /etc/squid/ldap_password
ファイアウォールで
3128
ポートを開きます。# firewall-cmd --permanent --add-port=3128/tcp # firewall-cmd --reload
squid
サービスを有効にして開始します。# systemctl enable --now squid
検証手順
プロキシーが正しく機能することを確認するには、curl
ユーティリティーを使用して Web ページをダウンロードします。
# curl -O -L "https://www.redhat.com/index.html" -x "user_name:password@proxy.example.com:3128"
curl でエラーが表示されず、index.html
ファイルが現在のディレクトリーにダウンロードされている場合は、プロキシーが動作します。
トラブルシューティングの手順
ヘルパーユーティリティーが正しく機能していることを確認するには、以下の手順を行います。
auth_param
パラメーターで使用したのと同じ設定で、ヘルパーユーティリティーを手動で起動します。# /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D "uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389
有効なユーザー名とパスワードを入力し、Enter を押します。
user_name password
ヘルパーユーティリティーが
OK
を返すと、認証に成功しました。
7.3. kerberos 認証を使用したキャッシングプロキシーとしての Squid の設定
本セクションでは、Kerberos を使用して Active Directory (AD) にユーザーを認証するキャッシングプロキシーとしての Squid 基本設定を説明します。この手順では、認証されたユーザーのみがプロキシーを使用できるように設定します。
前提条件
-
/etc/squid/squid.conf
ファイルが、squid
パッケージにより提供されている。このファイルを編集した場合は、ファイルを削除して、パッケージを再インストールしている。 -
Squid をインストールするサーバーが、AD ドメインのメンバーである。詳細は、Red Hat Enterprise Linux 8 の
『さまざまな種類のサーバーのデプロイメント』
の「Samba をサーバーとして使用」を参照してください。
手順
以下のパッケージをインストールします。
yum install squid krb5-workstation
AD ドメイン管理者として認証します。
# kinit administrator@AD.EXAMPLE.COM
Squid 用のキータブを作成し、これを
/etc/squid/HTTP.keytab
ファイルに保存します。# export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab # net ads keytab CREATE -U administrator
HTTP
サービスプリンシパルをキータブに追加します。# net ads keytab ADD HTTP -U administrator
キータブファイルの所有者を
squid
ユーザーに設定します。# chown squid /etc/squid/HTTP.keytab
必要に応じて、キータブファイルに、プロキシーサーバーの完全修飾ドメイン名 (FQDN) の
HTTP
サービスプリンシパルが含まれていることを確認します。# klist -k /etc/squid/HTTP.keytab Keytab name: FILE:/etc/squid/HTTP.keytab KVNO Principal ---- --------------------------------------------------- ... 2 HTTP/proxy.ad.example.com@AD.EXAMPLE.COM ...
/etc/squid/squid.conf
ファイルを編集します。negotiate_kerberos_auth
ヘルパーユーティリティーを設定するには、/etc/squid/squid.conf
の上部に以下の設定エントリーを追加します。auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/HTTP.keytab -s HTTP/proxy.ad.example.com@AD.EXAMPLE.COM
以下は、上記の例の
negotiate_kerberos_auth
ヘルパーユーティリティーに渡されるパラメーターを説明します。-
-k ファイル
は、キータブファイルへのパスを設定します。squid ユーザーには、このファイルに対する読み取り権限があることに注意してください。 -s HTTP/host_name@kerberos_realm
は、Squid が使用する Kerberos プリンシパルを設定します。必要に応じて、以下のパラメーターのいずれかまたは両方をヘルパーユーティリティーに渡すことによりロギングを有効にできます。
-
-i
は、認証ユーザーなどの情報メッセージをログに記録します。 -d
は、デバッグロギングを有効にします。Squid は、ヘルパーユーティリティーから、
/var/log/squid/cache.log
ファイルのログにデバッグ情報を記録します。
-
以下の ACL およびルールを追加して、Squid で、認証されたユーザーのみがプロキシーを使用できるように設定します。
acl kerb-auth proxy_auth REQUIRED http_access allow kerb-auth
重要これらの設定は、
http_access deny all
ルールの前に指定する必要があります。次のルールを削除して、
localnet
ACL で指定された IP 範囲のプロキシー認証を無効にします。http_access allow localnet
以下の ACL はデフォルト設定に含まれ、HTTPS プロトコルを使用するポートとして
443
を定義します。acl SSL_ports port 443
ユーザーが他のポートでも HTTPS プロトコルを使用できるようにするには、ポートごとに ACL を追加します。
acl SSL_ports port port_number
Squid が接続を確立できるポートに設定する
acl Safe_ports
ルールの一覧を更新します。たとえば、プロキシーを使用するクライアントがポート 21 (FTP)、80 (HTTP)、443 (HTTPS) のリソースにのみアクセスできるようにするには、設定に次のacl Safe_ports
ステートメントのみを保持します。acl Safe_ports port 21 acl Safe_ports port 80 acl Safe_ports port 443
デフォルトでは、設定には、
Safe_ports
ACL に定義されていないポートへのアクセス拒否を定義するhttp_access deny !Safe_ports
ルールが含まれています。cache_dir
パラメーターにキャッシュの種類、キャッシュディレクトリーへのパス、キャッシュサイズ、さらにキャッシュの種類ごとの設定を構成します。cache_dir ufs /var/spool/squid 10000 16 256
この設定により、以下が可能になります。
-
Squid は、キャッシュの種類
ufs
を使用します。 -
Squid は、キャッシュを
/var/spool/squid/
ディレクトリーに保存します。 -
キャッシュのサイズが最大
10000
MB になります。 -
Squid は、
/var/spool/squid/
ディレクトリーに16
個のレベル 1 サブディレクトリーを作成します。 Squid は、レベル 1 の各ディレクトリーに
256
個のサブディレクトリーを作成します。cache_dir
ディレクティブを設定しないと、Squid はキャッシュをメモリーに保存します。
-
Squid は、キャッシュの種類
cache_dir
パラメーターに/var/spool/squid/
以外のキャッシュディレクトリーを設定する場合は、以下を行います。キャッシュディレクトリーを作成します。
# mkdir -p path_to_cache_directory
キャッシュディレクトリーの権限を設定します。
# chown squid:squid path_to_cache_directory
SELinux を、
Enforcing
モードで実行する場合は、キャッシュディレクトリー用にsquid_cache_t
コンテキストを設定します。# semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?" # restorecon -Rv path_to_cache_directory
semanage
ユーティリティーがシステムで利用できない場合は、policycoreutils-python-utils
パッケージをインストールします。
ファイアウォールで
3128
ポートを開きます。# firewall-cmd --permanent --add-port=3128/tcp # firewall-cmd --reload
squid
サービスを有効にして開始します。# systemctl enable --now squid
検証手順
プロキシーが正しく機能することを確認するには、curl
ユーティリティーを使用して Web ページをダウンロードします。
# curl -O -L "https://www.redhat.com/index.html" --proxy-negotiate -u : -x "proxy.ad.example.com:3128"
curl
でエラーが表示されず、index.html
ファイルが現在のディレクトリーに存在する場合は、プロキシーが機能します。
トラブルシューティングの手順
Kerberos 認証を手動でテストするには、以下を行います。
AD アカウントの Kerberos チケットを取得します。
# kinit user@AD.EXAMPLE.COM
必要に応じて、キーを表示します。
# klist
negotiate_kerberos_auth_test
ユーティリティーを使用して認証をテストします。# /usr/lib64/squid/negotiate_kerberos_auth_test proxy.ad.example.com
ヘルパーユーティリティーがトークンを返すと、認証に成功しました。
Token: YIIFtAYGKwYBBQUCoIIFqDC...
7.4. Squid でのドメインブラックリストの設定
多くの場合、管理者は特定のドメインへのアクセスをブロックする必要があります。本セクションでは、Squid でドメインブラックリストを設定する方法を説明します。
前提条件
- Squid が設定され、ユーザーはプロキシーを使用できます。
手順
/etc/squid/squid.conf
ファイルを編集し、以下の設定を追加します。acl domain_blacklist dstdomain "/etc/squid/domain_blacklist.txt" http_access deny all domain_blacklist
重要ユーザーまたはクライアントへのアクセスを許可する最初の
http_access allow
ステートメントの前に、このエントリーを追加します。/etc/squid/domain_blacklist.txt
ファイルを作成し、ブロックするドメインを追加します。たとえば、サブドメインを含むexample.com
へのアクセスをブロックし、example.net
をブロックするには、次の設定を追加します。.example.com example.net
重要squid 設定の
/etc/squid/domain_blacklist.txt
ファイルを参照している場合、このファイルは空にすることはできません。このファイルが空の場合、Squid は起動できません。squid
サービスを再起動します。# systemctl restart squid
7.5. Squid サービスが特定のポートまたは IP アドレスをリッスンするように設定
デフォルトでは、Squid プロキシーサービスはすべてのネットワークインターフェースの 3128
ポートでリッスンします。本セクションでは、ポートを変更し、Squid が特定の IP アドレスをリッスンするように設定する方法を説明します。
前提条件
-
squid
パッケージがインストールされている。
手順
/etc/squid/squid.conf
ファイルを編集します。Squid サービスがリッスンするポートを設定するには、
http_port
パラメーターにポート番号を設定します。たとえば、ポートを8080
に設定するには、次を設定します。http_port 8080
Squid サービスがリッスンする IP アドレスを設定するには、
http_port
パラメーターに IP アドレスとポート番号を設定します。たとえば、Squid がポート3128
の IP アドレス192.0.2.1
でのみリッスンするように設定するには、次を設定します。http_port 192.0.2.1:3128
複数の
http_port
パラメーターを設定ファイルに追加して、Squid が複数のポートおよび IP アドレスでリッスンするように設定します。http_port 192.0.2.1:3128 http_port 192.0.2.1:8080
Squid が別のポートをデフォルト (
3128
) として使用するように設定する場合は、以下を行います。ファイアウォールのポートを開きます。
# firewall-cmd --permanent --add-port=port_number/tcp # firewall-cmd --reload
SELinux を Enforcing モードで実行する場合は、ポートを
squid_port_t
ポートタイプ定義に割り当てます。# semanage port -a -t squid_port_t -p tcp port_number
semanage
ユーティリティーがシステムで利用できない場合は、policycoreutils-python-utils
パッケージをインストールします。
squid
サービスを再起動します。# systemctl restart squid
7.6. 関連情報
-
/etc/squid/squid.conf
で設定できる設定パラメーターの一覧と詳細な説明は、usr/share/doc/squid-<version>/squid.conf.documented
ファイルを参照してください。
第8章 データベースサーバー
8.1. データベースサーバーの概要
データベースサーバーは、一定量のメインメモリーとデータベース (DB) アプリケーションがインストールされているハードウェアデバイスです。このデータベースアプリケーションは、通常、小さくて高価なメインメモリーから DB ファイル (データベース) にキャッシュされたデータを書き込む手段としてサービスを提供します。サービスは、ネットワーク上の複数のクライアントに提供されます。利用できるデータベースサーバーの数は、マシンのメインメモリーおよびストレージにより異なります。
Red Hat Enterprise Linux 8 は、以下のデータベースアプリケーションを提供します。
- MariaDB 10.3
- MySQL 8.0
- PostgreSQL 10
- PostgreSQL 9.6
- PostgreSQL 12 - RHEL 8.1.1 以降で利用できます。
8.2. MariaDB の使用
8.2.1. 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 データのバックアップを作成する方法を説明します。データバックアップの実行は、MariaDB 移行の前提条件です。
8.2.2. MariaDB のインストール
MariaDB をインストールするには、以下の手順を行います。
特定のストリームを使用して
mariadb
モジュールをインストールして、そのシステムで MariaDB サーバーに必要なパッケージをすべて利用できる状態にします。# yum module install mariadb:10.3/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 では、コンテナーで異なるバージョンのデータベースサーバーを使用できます。
8.2.2.1. MariaDB インストールセキュリティーの改善
MariaDB のインストール時にセキュリティーを強化する場合は、次のコマンドを実行します。
このコマンドは、完全にインタラクティブなスクリプトを起動して、プロセスの各ステップのプロンプトを表示します。
# mysql_secure_installation
このスクリプトを使用すると、次の方法でセキュリティーを改善できます。
- root アカウントのパスワードの設定
- 匿名ユーザーの削除
- リモート (ローカルホスト外) の root ログインの拒否
8.2.3. MariaDB の設定
8.2.3.1. MariaDB サーバーのネットワーク設定
MariaDB サーバーをネットワーク用に設定するには、/etc/my.cnf.d/mariadb-server.cnf
ファイルの [mysqld]
セクションを使用します。ここには、以下の設定ディレクティブを設定できます。
bind-address
bind-address は、サーバーがリッスンするアドレスです。
可能なオプションは、ホスト名、IPv4 アドレス、または IPv6 アドレスです。
skip-networking
以下の値が使用できます。
0 - すべてのクライアントをリッスンする
1 - ローカルクライアントのみをリッスンする
port
MariaDB が TCP/IP 接続をリッスンするポート
8.2.4. MariaDB データのバックアップ
MariaDB データベースからデータのバックアップを取得するには、以下の 2 つの方法があります。
- 論理バックアップ
- 物理バックアップ
論理バックアップ は、データの復元に必要な SQL ステートメントで構成されます。この種類のバックアップは、情報およびレコードをプレーンテキストファイルにエクスポートします。
物理バックアップに対する論理バックアップの主な利点は、移植性と柔軟性です。データは、物理バックアップではできない他のハードウェア構成である MariaDB バージョンまたはデータベース管理システム (DBMS) で復元できます。
mariadb.service
が稼働している場合は、論理バックアップを実行できることに注意してください。論理バックアップには、ログと設定ファイルが含まれません。
物理バックアップ は、コンテンツを格納するファイルおよびディレクトリーのコピーで構成されます。
物理バックアップは、論理バックアップと比較して、以下の利点があります。
- 出力が少なくなる。
- バックアップのサイズが小さくなる。
- バックアップおよび復元が速くなる。
- バックアップには、ログファイルと設定ファイルが含まれる。
mariadb.service
が実行していない場合や、データベースのすべてのテーブルがロックされていて、バックアップ中に変更しないようにする場合は、物理バックアップを実行する必要があります。
以下のいずれかの MariaDB バックアップ方法で、MariaDB データベースのデータのバックアップを使用できます。
- mysqldump を使用した論理バックアップ
- Mariabackup ツールを使用した物理的なオンラインバックアップ
- ファイルシステムのバックアップ
- バックアップソリューションとしてレプリケーションを使用
8.2.4.1. mysqldump を使用した論理バックアップの実行
mysqldump クライアントはバックアップユーティリティーで、バックアップ目的でデータベースまたはデータベースの集合をダンプしたり、別のデータベースサーバーに転送したりできます。通常、mysqldump の出力は、サーバーテーブル構造を再作成する、それにデータを取り込む、またはその両方の SQL ステートメントで構成されます。また、mysqldump は、CSV などのコンマ区切りテキスト形式、XML など、その他の形式のファイルも生成できます。
mysqldump バックアップを実行するには、以下のいずれかのオプションを使用できます。
- 選択したデータベースをバックアップする。
- あるデータベースのテーブルのサブセットのバックアップを作成する。
- 複数のデータベースをバックアップする。
- すべてのデータベースをバックアップする。
8.2.4.1.1. mysqldump を使用したデータベース全体のバックアップ
手順
データベース全体のバックアップを取得するには、以下を実行します。
# mysqldump [options] db_name > backup-file.sql
8.2.4.1.2. mysqldump を使用したデータベースから一連のテーブルのバックアップ
手順
あるデータベースで、テーブルのサブセットのバックアップを作成するには、
mysqldump
コマンドの末尾に、選択したテーブルの一覧を追加します。# mysqldump [options] db_name [tbl_name …]
8.2.4.1.3. mysqldump でサーバーへのダンプファイルの読み込み
手順
ダンプファイルをサーバーに読み込むには、以下のいずれかを使用します。
# mysql db_name < backup-file.sql
# mysql -e "source /path-to-backup/backup-file.sql" db_name
8.2.4.1.4. mysqldump を使用した 2 つのデータベース間のデータのコピー
手順
データを MariaDB サーバー間でコピーしてデータベースを入力するには、以下を実行します。
# mysqldump --opt db_name | mysql --host=remote_host -C db_name
8.2.4.1.5. mysqldump で複数データベースのダンプ
手順
複数のデータベースを一度にダンプするには、次のコマンドを実行します。
# mysqldump [options] --databases db_name1 [db_name2 …] > my_databases.sql
8.2.4.1.6. mysqldump で全データベースのダンプ
手順
すべてのデータベースをダンプするには、以下を実行します。
# mysqldump [options] --all-databases > all_databases.sql
8.2.4.1.7. mysqldump オプションの確認
手順
mysqldump サポートするオプションの一覧を表示するには、以下を実行します。
$ mysqldump --help
8.2.4.1.8. 関連情報
mysqldump を使用した論理バックアップの詳細は、MariaDB のドキュメント を参照してください。
8.2.4.2. Mariabackup ツールを使用した物理的なオンラインバックアップ
Mariabackup は、Percona Xtrabackup テクノロジーをベースとしたツールで、InnoDB、Aria、および MyISAM のテーブルの物理的なオンラインバックアップを実行できます。
AppStream リポジトリーの mariadb-backup
パッケージが提供する Mariabackup は、MariaDB サーバーの完全バックアップ機能に対応します。これには、暗号化されたデータと圧縮データが含まれます。
前提条件
mariadb-backup
パッケージがシステムにインストールされている。# yum install mariadb-backup
Mariabackup には、バックアップを実行するユーザーの認証情報を指定している。この手順に示されるように、コマンドラインで認証情報を指定するか、または手順を適用する前に設定ファイルを指定します。設定ファイルを使用して認証情報を設定するには、最初にファイル (例:
/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」を参照してください。
8.2.4.3. Mariabackup ツールを使用したデータの復元
バックアップが完了したら、mariabackup
コマンドに以下のいずれかのオプションを使用して、バックアップからデータを復元できます。
-
--copy-back
-
--move-back
--copy-back
オプションを使用すると、元のバックアップファイルを保持できます。--move-back
オプションは、バックアップファイルをデータディレクトリーに移動し、元のバックアップファイルを削除します。
前提条件
mariadb
サービスが稼働していないことを確認します。# systemctl stop mariadb.service
- データディレクトリーが空であることを確認します。
8.2.4.3.1. バックアップファイルを維持しながら Mariabackup でデータの復元
元のバックアップファイルを維持しながらデータを復元するには、以下の手順を行います。
手順
mariabackup
コマンドを実行して、--copy-back
オプションを指定します。$ mariabackup --copy-back --target-dir=/var/mariadb/backup/
ファイルの権限を修正します。
データベースを復元するとき、Mariabackup は、バックアップのファイルおよびディレクトリーの権限を保持します。ただし、Mariabackup は、ユーザーおよびグループがデータベースを復元する際にファイルをディスクに書き込みます。したがって、バックアップの復元後に、MariaDB サーバーのユーザーおよびグループ (通常は共に
mysql
) が一致するように、データディレクトリーの所有者の調整が必要になることがあります。たとえば、ファイルの所有権を
mysql
ユーザーおよびグループに再帰的に変更するには、次のコマンドを実行します。# chown -R mysql:mysql /var/lib/mysql/
mariadb
サービスを起動します。# systemctl start mariadb.service
8.2.4.3.2. バックアップファイルの削除中に Mariabackup でデータの復元
データを復元し、元のバックアップファイルを保存しないようにするには、以下の手順を行います。
手順
--move-back
オプションを指定してmariabackup
コマンドを実行します。$ mariabackup --move-back --target-dir=/var/mariadb/backup/
ファイルの権限を修正します。
データベースを復元するとき、Mariabackup は、バックアップのファイルおよびディレクトリーの権限を保持します。ただし、Mariabackup は、ユーザーおよびグループがデータベースを復元する際にファイルをディスクに書き込みます。したがって、バックアップの復元後に、MariaDB サーバーのユーザーおよびグループ (通常は共に
mysql
) が一致するように、データディレクトリーの所有者の調整が必要になることがあります。たとえば、ファイルの所有権を
mysql
ユーザーおよびグループに再帰的に変更するには、次のコマンドを実行します。# chown -R mysql:mysql /var/lib/mysql/
mariadb
サービスを起動します。# systemctl start mariadb.service
8.2.4.3.3. 関連情報
詳細は「Full Backup and Restore with Mariabackup」を参照してください。
8.2.4.4. ファイルシステムのバックアップの実行
MariaDB データファイルのファイルシステムのバックアップを作成するには、root
ユーザーに切り替えて、MariaDB データディレクトリーの内容をバックアップの場所にコピーします。
現在の設定またはログファイルのバックアップも作成するには、以下の手順の中から任意の手順を選択します。
手順
mariadb
サービスを停止します。# systemctl stop mariadb.service
データファイルを必要な場所にコピーします。
# cp -r /var/lib/mysql /backup-location
必要に応じて、設定ファイルを必要な場所にコピーします。
# cp -r /etc/my.cnf /etc/my.cnf.d /backup-location/configuration
必要に応じて、ログファイルを必要な場所にコピーします。
# cp /var/log/mariadb/* /backup-location/logs
mariadb
サービスを起動します。# systemctl start mariadb.service
8.2.4.5. レプリケーションをバックアップソリューションとして紹介します。
レプリケーションは、マスターサーバー用の代替バックアップソリューションです。マスターサーバーの複製となるスレーブサーバーを作成すると、マスターに影響を与えずに、スレーブでバックアップを実行できます。マスターは、スレーブをシャットダウンしている間にも実行でき、データをバックアップできます。
レプリケーション自体は、バックアップソリューションとしては十分ではありません。レプリケーションは、ハードウェア障害からマスターサーバーを保護しますが、データ損失に対する保護は保証しないためです。この方法とともに、レプリケーションスレーブでその他のバックアップソリューションを使用することが推奨されます。
関連情報
レプリケーションをバックアップソリューションとして使用する場合は、MariaDB ドキュメンテーション を参照してください。
8.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 を提供します。
8.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 へ移行するには、「設定変更」の記載どおりに複数の設定を実行する必要があります。
8.2.5.2. 設定変更
MariaDB 5.5 から MariaDB 10.3 への推奨される移行パスは、最初に MariaDB 10.0 にアップグレードしてから、1 バージョンずつ順次アップグレードすることです。
バージョンを 1 つずつアップグレードする主な利点は、変更に対するデータと構成の両方を含む、データベースの適合に優れています。アップグレードは、RHEL 8 (MariaDB 10.3) で利用可能なものと同じメジャーバージョンで終了します。これにより、設定変更やその他の問題が大幅に低下します。
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」
- Red Hat Software Collections ドキュメントの「Migrating to MariaDB 10.3」
MariaDB 5.5 から MariaDB 10.3 へ直接移行することもできますが、上記の移行ドキュメントに記載されている違いにより必要とされる設定変更をすべて実行する必要があります。
8.2.5.3. mysql_upgrade ツールを使用したインプレースアップグレード
データベースファイルを Red Hat Enterprise Linux 8 に移行するには、Red Hat Enterprise Linux 7 の MariaDB ユーザーが、mysql_upgrade
ツールを使用してインプレースアップグレードを実行する必要があります。mysql_upgrade
ツールは、mariadb-server-utils
サブパッケージにより提供され、mariadb-server
パッケージの依存関係としてインストールされます。
インプレースアップグレードを実行するには、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 データベースに保存されている全データのバックアップを作成します。
インプレースアップグレードを実行する場合は、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』を参照してください。
8.2.6. Galera で MariaDB の複製
本セクションでは、Galera ソリューションを使用して MariaDB データベースを複製する方法を説明します。
8.2.6.1. MariaDB Galera Cluster の概要
Galera レプリケーションは、複数の MariaDB サーバーで構成される同期マルチマスター MariaDB Galera Cluster の作成に基づいています。
Galera レプリケーションと MariaDB データベースとの間のインターフェースは、書き込みセットレプリケーション API (wsrep API) で定義されます。
MariaDB Galera Cluster の主な機能は以下のとおりです。
- 同期のレプリケーション
- アクティブ/アクティブのマルチマスタートポロジー
- クラスターノードへの読み取りおよび書き込み
- 自動メンバーシップ制御、失敗したノードのクラスターからの削除
- 自動ノードの参加
- 行レベルの並列レプリケーション
- ダイレクトクライアント接続 (ユーザーはクラスターノードにログオンし、レプリケーションの実行中にノードを直接操作できます)
同期レプリケーションとは、サーバーがトランザクションに関連付けられた書き込みセットをクラスター内のすべてのノードにブロードキャストすることで、コミット時にトランザクションをレプリケートすることを意味します。クライアント (ユーザーアプリケーション) は、データベース管理システム (DBMS) に直接接続し、ネイティブの MariaDB と同様の動作が発生します。
同期レプリケーションは、クラスター内の 1 つのノードで発生した変更が、クラスター内の他のノードで同時に発生することを保証します。
そのため、同期レプリケーションには、非同期のレプリケーションと比べて次のような利点があります。
- 特定のクラスターノード間の変更の伝播に遅延がない
- すべてのクラスターノードには常に一貫性がある
- いずれかのクラスターノードがクラッシュしても、最新の変更は失われない
- すべてのクラスターノードのトランザクションが並列に実行する
- クラスター全体にわたる因果関係
関連情報
詳細は、アップストリームのドキュメントを参照してください。
8.2.6.2. MariaDB Galera クラスターを構築するためのコンポーネント
MariaDB Galera Cluster を構築できるようにするには、以下のパッケージをシステムにインストールしておく必要があります。
-
mariadb-server-galera
-
mariadb-server
-
galera
mariadb-server-galera
パッケージには、MariaDB Galera Cluster のサポートファイルとスクリプトが含まれます。
MariaDB アップストリームは、mariadb-server
パッケージにパッチを適用して、書き込みセットレプリケーション API (wsrep API) を組み込みます。この API は、Galera レプリケーションと MariaDB との間のインターフェースを提供します。
また、MariaDB のアップストリームでは galera
にパッチを適用して、MariaDB の完全サポートを追加します。galera
パッケージには、Galera Replication Library および Galera Arbitrator ツールが含まれます。Galera Replication Library は、レプリケーション機能全体を提供します。Galera Arbitrator は、スプリットブレインのシナリオで投票に参加するクラスターメンバーとして使用できます。ただし、Galera Arbitrator は実際のレプリケーションには参加できません。
関連情報
詳細は、アップストリームのドキュメントを参照してください。
8.2.6.3. MariaDB Galera クラスターのデプロイメント
前提条件
MariaDB Galera Cluster を構築するのに必要なソフトウェアがすべてシステムにインストールされている。これを確認するには、
mariadb:10.3
モジュールのgalera
プロファイルをインストールします。# yum module install mariadb:10.3/galera
これにより、以下のパッケージがインストールされます。
-
mariadb-server-galera
-
mariadb-server
galera
mariadb-server-galera
パッケージがmariadb-server
パッケージおよびgalera
パッケージを依存関係としてプルします。MariaDB Galera Cluster を構築するコンポーネントの詳細は、「MariaDB Galera クラスターを構築するためのコンポーネント」を参照してください。
-
MariaDB サーバーのレプリケーション設定は、システムを初めてクラスターに追加する前に更新する必要があります。
デフォルト設定は、
/etc/my.cnf.d/galera.cnf
ファイルに同梱されています。MariaDB Galera Cluster をデプロイする前に、以下の文字列で開始するように、すべてのノードの
/etc/my.cnf.d/galera.cnf
ファイルにwsrep_cluster_address
オプションを設定します。gcomm://
初期ノードでは、
wsrep_cluster_address
を空のリストとして設定できます。wsrep_cluster_address="gcomm://"
その他のすべてのノードに
wsrep_cluster_address
を設定して、実行中のクラスターに属するノードへのアドレスを追加します。以下に例を示します。wsrep_cluster_address="gcomm://10.0.0.10"
Galera Cluster アドレスの設定方法は、「Galera Cluster Address」を参照してください。
手順
ノードで以下のラッパーを実行して、新規クラスターの最初のノードをブートストラップします。
$ galera_new_cluster
このラッパーにより、MariaDB サーバーデーモン (
mysqld
) に--wsrep-new-cluster
オプションが指定されて実行されるようになります。このオプションは、接続する既存クラスターがないという情報を提供します。したがって、ノードは新規 UUID を作成し、新しいクラスターを特定します。注記mariadb
サービスは、複数の MariaDB サーバープロセスと対話する systemd メソッドをサポートします。したがって、複数の MariaDB サーバーを実行している場合は、インスタンス名を接尾辞として指定して、特定のインスタンスをブートストラップできます。$ galera_new_cluster mariadb@node1
各ノードで次のコマンドを実行して、その他のノードをクラスターに接続します。
# systemctl start mariadb
その結果、ノードはクラスターに接続し、それ自体をクラスターの状態と同期します。
関連情報
詳細は「Getting started with MariaDB Galera Cluster」を参照してください。
8.2.6.4. 新規ノードの MariaDB Galera クラスターへの追加
新規ノードを MariaDB Galera Cluster に追加するには、以下の手順に従います。
この手順に従って、既存のノードを再接続することもできます。
手順
特定のノードで、
/etc/my.cnf.d/galera.cnf
設定ファイルの[mariadb]
セクション内にあるwsrep_cluster_address
オプションで、1 つ以上の既存クラスターメンバーにアドレスを指定します。[mariadb] wsrep_cluster_address="gcomm://192.168.0.1"
新規ノードを既存クラスターノードのいずれかに接続すると、クラスター内のすべてのノードを表示できるようになります。
ただし、
wsrep_cluster_address
のクラスターの全ノードを表示することが推奨されます。したがって、1 つ以上のクラスターノードがダウンしても、その他のクラスターノードに接続することでノードがクラスターに参加できます。すべてのメンバーがメンバーシップに同意すると、クラスターの状態が変更します。新規ノードの状態がそのクラスターとは異なる場合は、他のノードとの整合性を保つために、IST (Incremental State Transfer) または SST (State Snapshot Transfer) のいずれかが要求されます。
関連情報
- 詳細は「Getting started with MariaDB Galera Cluster」を参照してください。
- SST (State Snapshot Transfer) の詳細は、「Introduction to State Snapshot Transfers」を参照してください。
8.2.6.5. MariaDB Galera クラスターの再起動
すべてのノードを同時にシャットダウンすると、クラスターが終了し、実行中のクラスターは存在しなくなります。ただし、クラスターのデータは引き続き存在します。
クラスターを再起動するには、「MariaDB Galera クラスターのデプロイメント」の説明に従って最初のノードをブートストラップします。
クラスターがブートストラップされず、最初のノードの mysqld
が systemctl start mariadb
コマンドで起動した場合、ノードは /etc/my.cnf.d/galera.cnf
ファイルの wsrep_cluster_address
オプションに記載されている中から少なくとも 1 つのノードに接続しようとします。ノードが現在実行していない場合は、再起動に失敗します。
関連情報
詳細は「Getting started with MariaDB Galera Cluster」を参照してください。
8.3. PostgreSQL の使用
8.3.1. PostgreSQL の概要
PostgreSQL サーバーは、SQL 言語をベースにした、オープンソースの堅牢かつ拡張性に優れたデータベースサーバーです。豊富なデータセットと、多数の同時ユーザーを管理できるオブジェクト関係データベースシステムを提供します。このような理由から、PostgreSQL サーバーは、大量のデータを管理するためにクラスターで使用できます。
PostgreSQL サーバーには、データの整合性の確保、耐障害性のある環境の構築、またはアプリケーションの構築を行うための機能が含まれます。データベースを再コンパイルすることなく、ユーザー独自のデータ型、カスタム関数、またはさまざまなプログラミング言語のコードでデータベースを拡張できます。
本セクションでは、「PostgreSQL のインストール」で PostgreSQL をインストールする方法や、「RHEL 8 バージョンの PostgreSQL への移行」 で、別のバージョンの PostgreSQL に移行する方法を説明します。移行の前提条件に、データバックアップの実行があります。
8.3.2. PostgreSQL のインストール
RHEL 8 では、PostgreSQL サーバーは複数のバージョンで利用でき、それぞれは個別のストリームで提供されます。
- PostgreSQL 10 - デフォルトのストリーム
- PostgreSQL 9.6
- PostgreSQL 12 - RHEL 8.1.1 以降利用できます。
設計上、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできません。したがって、postgresql
モジュールから利用可能なストリームのいずれかを選択する必要があります。RHEL 7 および RHEL 6 用の Red Hat Software Collections では、コンポーネントの並列インストールが可能です。RHEL 8 では、コンテナー内で異なるバージョンのデータベースサーバーを使用できます。
PostgreSQL をインストールするには、以下を実行します。
インストールするストリーム (バージョン) を有効にします。
# yum module enable postgresql:stream
stream を、選択した PostgreSQL サーバーのバージョンに置き換えます。
PostgreSQL 10 を提供するデフォルトストリームを使用する場合は、この手順を省略できます。
AppStream リポジトリーで利用可能な
postgresql-server
パッケージが、必要なサーバーにインストールされていることを確認します。# yum install postgresql-server
データディレクトリーを初期化します。
postgresql-setup --initdb
postgresql
サービスを開始します。# systemctl start postgresql.service
postgresql
サービスが、システムの起動時に起動するようにします。# systemctl enable postgresql.service
モジュールストリームの使用方法は、『ユーザー空間コンポーネントのインストール、管理、および削除』を参照してください。
RHEL 8 内の以前の postgresql
ストリームからアップグレードする場合は、「後続のストリームへの切り替え」と 「RHEL 8 バージョンの PostgreSQL への移行」 に記載されている両手順を実行します。
8.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 データベースに対する詳細なユーザー権限を設定するのに使用されます。
8.3.3.1. データベースクラスターの初期化
PostgreSQL データベースでは、すべてのデータはデータベースクラスターと呼ばれる 1 つのディレクトリーに保存されます。データの保存場所は選択できますが、Red Hat では、デフォルトの /var/lib/pgsql/data
ディレクトリーにデータを保存することを推奨します。
このデータディレクトリーを初期化するには、次のコマンドを実行します。
postgresql-setup --initdb
8.3.4. PostgreSQL データのバックアップ
PostgreSQL データをバックアップするには、以下のいずれかの方法を使用します。
- SQL ダンプ
- ファイルシステムレベルのバックアップ
- 継続的アーカイブ
8.3.4.1. SQL ダンプを使用した PostgreSQL データのバックアップ
8.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
8.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
8.3.4.1.2.1. 別のサーバーでのデータベースの復元
pg_dump および psql はパイプに対する読み書きが可能であるため、あるサーバーから別のサーバーにデータベースを直接ダンプできます。
データベースを、サーバーから別のサーバーにダンプするには、以下のコマンドを実行します。
pg_dump -h host1 dbname | psql -h host2 dbname
8.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
この方法を使用する場合は、多少のエラーでも、すでに何時間も実行している復元操作をキャンセルできます。
8.3.4.1.3. SQL ダンプの長所と短所
SQL ダンプには、他の PostgreSQL バックアップ方法と比較して、以下の長所があります。
- SQL ダンプは、サーバーのバージョン固有ではない唯一の PostgreSQL バックアップメソッドです。pg_dump ユーティリティーの出力は、PostgreSQL の後続のバージョンに再読み込みできます。これは、ファイルシステムレベルのバックアップ、または継続的なアーカイブにはできません。
- SQL ダンプは、32 ビットサーバーから 64 ビットサーバーへなど、異なるアーキテクチャーにデータベースを転送する際に有効な唯一の方法です。
- SQL ダンプは、内部的に一貫性のあるダンプを提供します。ダンプは、pg_dump の実行開始時のデータベースのスナップショットを表します。
- pg_dump ユーティリティーは、実行中のデータベースの他の操作をブロックしません。
SQL ダンプの短所は、ファイルシステムレベルのバックアップと比較して時間がかかることです。
8.3.4.1.4. 関連情報
SQL ダンプの詳細は、PostgreSQL ドキュメンテーション を参照してください。
8.3.4.2. ファイルシステムレベルのバックアップを使用した PostgreSQL データのバックアップ
8.3.4.2.1. ファイルシステムレベルのバックアップの実行
ファイルシステムレベルのバックアップを作成するには、PostgreSQL がデータベースのデータを保存するために使用するファイルを別の場所にコピーする必要があります。
- データベースクラスターの場所を選択し、「データベースクラスターの初期化」の説明に従ってこのクラスターを初期化します。
postgresql サービスを停止します。
# systemctl stop postgresql.service
ファイルシステムをバックアップする場合は、以下のような方法を使用します。
tar -cf backup.tar /var/lib/pgsql/data
postgresql サービスを起動します。
# systemctl start postgresql.service
8.3.4.2.2. ファイルシステムレベルのバックアップの長所と短所
ファイルシステムレベルのバックアップは、他の PostgreSQL バックアップ方法と比較して、以下の利点があります。
- ファイルシステムレベルのバックアップは、通常、SQL ダンプよりも高速です。
ファイルシステムレベルのバックアップは、他の PostgreSQL バックアップ方法と比較して、以下の短所があります。
- バックアップはアーキテクチャー固有で、Red Hat Enterprise Linux 7 固有のものです。アップグレードが正常に完了しなかった場合は、Red Hat Enterprise Linux 7 に戻るためのバックアップとしてのみ使用できますが、PostgreSQL 10.0 では使用できません。
- データバックアップまたはデータ復元を行う前に、データベースサーバーをシャットダウンする必要があります。
- 特定の個別ファイルまたはテーブルのバックアップと復元はできません。ファイルシステムのバックアップは、データベースクラスター全体の完全バックアップと復元でのみ機能します。
8.3.4.2.3. ファイルシステムレベルのバックアップの代替アプローチ
ファイルシステムのバックアップの代替方法は、以下のとおりです。
- データディレクトリーの一貫したスナップショット
- rsync ユーティリティー
8.3.4.2.4. 関連情報
ファイルシステムレベルのバックアップの詳細は、PostgreSQL ドキュメント を参照してください。
8.3.4.3. 継続的にアーカイブして PostgreSQL データのバックアップを作成
8.3.4.3.1. 継続的なアーカイブの概要
PostgreSQL は、データベースのデータファイルに対するすべての変更を、クラスターのデータディレクトリーの pg_wal/
サブディレクトリーで利用可能なログ先行書き込み (WAL) ファイルに記録します。このログは、主にクラッシュからの復元を目的としています。クラッシュ後、最後のチェックポイント以降に作成されたログエントリーを使用して、データベースの整合性まで復元できます。
オンラインバックアップ
とも呼ばれる継続的なアーカイブ方法は、WAL ファイルとファイルシステムレベルのバックアップを組み合わせたものです。データベース復元が必要な場合は、ファイルシステムのバックアップからデータベースを復元してから、バックアップを作成した WAL ファイルからログを再生して、システムを現在の状態にすることができます。
このバックアップ方法には、少なくともバックアップの開始時刻まで戻る、アーカイブされた WAL ファイルの連続シーケンスが必要です。
継続的なアーカイブバックアップ方式の使用を開始する場合は、最初のベースバックアップを行う前に、WAL ファイルのアーカイブ手順を設定してテストしてください。
pg_dump および pg_dumpall ダンプは、継続的にアーカイブするバックアップソリューションの一部として使用することができません。このダンプは、ファイルシステムレベルのバックアップではなく、論理バックアップを作成します。このため、WAL の再生で使用される十分な情報は含まれていません。
8.3.4.3.2. 継続的なアーカイブのバックアップの実行
継続的なアーカイブ方式を使用してデータベースのバックアップと復元を実行するには、以下の手順に従います。
8.3.4.3.2.1. ベースバックアップの作成
ベースバックアップを実行するには、pg_basebackup ツールを使用します。このツールは、個別のファイルまたは tar
アーカイブの形式でベースバックアップを作成できます。
ベースバックアップを使用するには、ファイルシステムのバックアップ中およびバックアップ後に生成されたすべての WAL セグメントファイルを維持する必要があります。ベースバックアッププロセスでは、WAL アーカイブ領域に保存され、ファイルシステムのバックアップに必要な最初の WAL セグメントファイルの後に名前が付けられるバックアップ履歴ファイルが作成されます。バックアップ中に使用するファイルシステムのバックアップおよび WAL セグメントファイルをバックアップ履歴ファイルで安全にアーカイブすると、ファイルシステムバックアップの復元が必要なくなるため、アーカイブされたすべての WAL セグメントを、数値的に小さい名前で削除できます。ただし、データの復元が可能であることを確実にするため、複数のバックアップセットを維持することを検討してください。
バックアップ履歴ファイルは小さなテキストファイルで、pg_basebackup に付与したラベル文字列、開始時間および終了時間、およびバックアップの WAL セグメントが含まれます。ラベル文字列を使用して関連するダンプファイルを特定した場合に、どのダンプファイルを復元するかを確認するには、アーカイブされた履歴ファイルで十分となります。
継続的にアーカイブする方法では、アーカイブされた WAL ファイルをすべて、最後のベースバックアップに戻す必要があります。したがって、ベースバックアップの理想的な頻度は、以下に依存します。
- アーカイブされた WAL ファイルで利用可能なストレージボリューム。
復元が必要な場合の、データ復元の最大許容期間。
最後のバックアップ以降の長い期間では、より多くの WAL セグメントが再生されるため、復元には時間がかかります。
ベースバックアップの作成の詳細は、PostgreSQL ドキュメンテーション を参照してください。
8.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 ドキュメンテーション を参照してください。
8.3.4.3.3. 継続的なアーカイブの長所と短所
継続的なアーカイブは、PostgreSQL のその他のバックアップ方法と比較して、以下の利点があります。
-
継続的バックアップ方式では、バックアップ内の内部不整合がログ再生により修正されるため、完全に一貫性のないファイルシステムのバックアップを使用できます。ファイルシステムのスナップショットは必要ありません。
tar
または同様のアーカイブツールで十分です。 - 継続的にバックアップを行うには、継続的に WAL ファイルをアーカイブします。これは、ログ再生用の WAL ファイルの順序が無限に長くなる可能性があるためです。これは、特に大規模なデータベースで有用です。
- 継続的バックアップは、特定の時点への復旧 (ポイントインタイムリカバリー) をサポートします。WAL エントリーを最後まで再生する必要はありません。再生はいつでも停止でき、ベースバックアップを作成してから、データベースをいつでもその状態に復元できます。
- 一連の WAL ファイルが同じベースのバックアップファイルで読み込まれた別のマシンが継続的に利用可能である場合は、任意の時点で、データベースで現在に一番近いコピーで、他のマシンを復元できます。
継続的なアーカイブには、その他の PostgreSQL バックアップ方法と比較して、以下の短所があります。
- 継続バックアップ方法は、サブセットではなく、データベースクラスター全体の復元のみをサポートします。
- 継続的にバックアップするには、大きなアーカイブストレージが必要です。
8.3.4.3.4. 関連情報
継続的なアーカイブ方法の詳細は、PostgreSQL ドキュメンテーション を参照してください。
8.3.5. RHEL 8 バージョンの PostgreSQL への移行
Red Hat Enterprise Linux 7 には、PostgreSQL 9.2 が、PostgreSQL サーバーのデフォルトバージョンとして含まれます。また、PostgreSQL の複数のバージョンは、RHEL 7 および RHEL 6 の Software Collections として提供されます。
Red Hat Enterprise Linux 8 は、PostgreSQL 10 (デフォルトの postgresql
ストリーム)、PostgreSQL 9.6、および PostgreSQL 12を提供します。
Red Hat Enterprise Linux 上の PostgreSQL のユーザーは、データベースファイルの移行パスを使用できます。
ダンプおよび復元のプロセスよりも高速なアップグレード方法を使用してください。
ただし、場合によっては高速アップグレードが機能せず、ダンプおよび復元プロセスしか使用できない場合があります。そのようなケースには、以下が含まれます。
- アーキテクチャー間のアップグレード
-
plpython
またはplpython2
拡張を使用するシステム。RHEL 8 AppStream リポジトリーにはpostgresql-plpython3
パッケージのみが含まれ、postgresql-plpython2
パッケージは含まれません。 - 高速アップグレードは、PostgreSQLの Red Hat Software Collections バージョンからの移行ではサポートされません。
新しいバージョンの PostgreSQL に移行するための前提条件として、すべての PostgreSQL データベースをバックアップします。
データベースをダンプし、SQL ファイルのバックアップを実行することは、ダンプおよび復元プロセスに必要な部分です。ただし、高速アップグレードも実行する場合は、これを実行することが推奨されます。
新しいバージョンの PostgreSQL に移行する前に、移行する PostgreSQL バージョンと、移行元と移行先のバージョンの間にあるすべて PostgreSQL バージョンの アップストリームの互換性ノート を参照してください。
8.3.5.1. pg_upgrade ツールを使用した高速アップグレード
高速アップグレードでは、バイナリーデータファイルを /var/lib/pgsql/data/
ディレクトリーにコピーし、pg_upgrade
ツールを使用する必要があります。
この方法を使用すると、データを移行できます。
- RHEL 7 システムバージョンの PostgreSQL 9.2 から、RHEL 8 バージョンの PostgreSQL 10へ
- RHEL 8 バージョンの PostgreSQL 10 から、RHEL 8 バージョンの PostgreSQL 12へ
RHEL 8 内の以前の postgresql
ストリームからアップグレードする場合は 「後続のストリームへの切り替え」の説明に従い、PostgreSQL データを移行します。
RHEL 内の PostgreSQL バージョンの組み合わせと、Red Hat Software Collections バージョンの PostgreSQL から RHEL への移行には、「アップグレードのダンプおよび復元」を使用します。
アップグレードを実行する前に、PostgreSQL データベースに保存されているすべてのデータのバックアップを作成します。
デフォルトでは、すべてのデータは、RHEL 7 および RHEL 8 システムの両方の /var/lib/pgsql/data/
ディレクトリーに保存されます。
以下の手順では、RHEL 7 システムバージョンの Postgreql 9.2 から、RHEL 8 バージョンの PostgreSQLへの移行を説明します。
高速アップグレードを実行するには、以下を実行します。
RHEL 8 システムで、移行するストリーム (バージョン)を有効にします。
# yum module enable postgresql:stream
stream を、選択した PostgreSQL サーバーのバージョンに置き換えます。
PostgreSQL 10 を提供するデフォルトストリームを使用する場合は、この手順を省略できます。
RHEL 8 システムで、
postgresql-server
パッケージおよびpostgresql-upgrade
パッケージをインストールします。# yum install postgresql-server postgresql-upgrade
必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用している場合は、その 2 つのバージョンを RHEL 8 システムにインストールし、PostgreSQL 9.2 (
postgresql-upgrade
パッケージでインストール) および対象バージョンの PostgreSQL (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/
ディレクトリー) にインストールされます。
-
基本設定 - RHEL 8 システムで、サーバーがデフォルトの
データのコピー時に、
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 サーバーを起動します。
# systemctl start postgresql.service
PostgreSQL ホームディレクトリーにある
analyze_new_cluster.sh
スクリプトを実行します。su postgres -c '~/analyze_new_cluster.sh'
システムの起動時に、新しい PostgreSQL サーバーを自動的に起動させる場合は、次のコマンドを実行します。
# systemctl enable postgresql.service
8.3.5.2. ダンプおよび復元のアップグレード
ダンプおよび復元のアップグレードを使用する場合は、すべてのデータベースのコンテンツを SQL ファイルのダンプファイルにダンプする必要があります。
ダンプおよび復元のアップグレードは高速なアップグレード方法よりも低速であり、生成された SQL ファイルで手動修正が必要になる場合があります。
この方法を使用すると、以下からデータを移行できます。
- Red Hat Enterprise Linux 7 システムバージョンの PostgreSQL 9.2
- 以前のバージョンの Red Hat Enterprise Linux 8 バージョンの PostgreSQL
Red Hat Software Collections の PostgreSQL の以前のバージョンまたは同等バージョン:
- PostgreSQL 9.2 (サポート対象外になりました)
- PostgreSQL 9.4 (サポート対象外になりました)
- PostgreSQL 9.6
- PostgreSQL 10
- PostgreSQL 12
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
を除く)。
RHEL 8 内の以前の postgresql
ストリームからアップグレードする場合は 「後続のストリームへの切り替え」の説明に従い、PostgreSQL データを移行します。
ダンプおよび復元のアップグレードを実行するには、ユーザーを root
に変更します。
以下の手順では、RHEL 7 システムバージョンの Postgreql 9.2 から、RHEL 8 バージョンの PostgreSQLへの移行を説明します。
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 システムで、移行するストリーム (バージョン)を有効にします。
# yum module enable postgresql:stream
stream を、選択した PostgreSQL サーバーのバージョンに置き換えます。
PostgreSQL 10 を提供するデフォルトストリームを使用する場合は、この手順を省略できます。
RHEL 8 システムで、
postgresql-server
パッケージをインストールします。# yum install postgresql-server
必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用している場合は、RHEL 8 システムにもインストールしてください。サードパーティーの PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、
postgresql-devel
パッケージに対してビルドします。RHEL 8 システムで、新しい PostgreSQL サーバーのデータディレクトリーを初期化します。
# 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 サーバーを起動します。
# 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"'
第9章 印刷の設定
Red Hat Enterprise Linux 8 での印刷は、Common Unix Print System (CUPS) に基づいています。
本ガイドでは、CUPS サーバーとして動作できるようにマシンを設定する方法を説明します。
9.1. cups サービスのアクティブ化
本セクションでは、システムの cups
サービスを有効にする方法を説明します。
前提条件
Appstream リポジトリーで利用可能な
cups
パッケージがインストールされている。# yum install cups
手順
cups
サービスを起動します。# systemctl start cups
システムの起動時に、
cups
サービスが自動的に起動するように設定します。# systemctl enable cups
必要に応じて、
cups
サービスのステータスを確認します。$ systemctl status cups
9.2. 印刷設定ツール
印刷に関するさまざまなタスクを行うために、以下のいずれかのツールを選択できます。
- CUPS の Web UI (ユーザーインターフェース)
- GNOME Control Center
Red Hat Enterprise Linux 7 で使用されていた 印刷設定 構成ツールは利用できなくなりました。
これらのツールを使用して達成できるタスクには、以下が含まれます。
- 新しいプリンターの追加および設定
- プリンター設定の維持
- プリンタークラスの管理
本ガイドでは、CUPS Web ユーザーインターフェース (UI) での印刷のみを説明します。GNOME Control Center を使用して印刷する場合は、GUI が利用可能である必要があります。GNOME コントロールセンター を使用した印刷の詳細は、「GNOME を使用した印刷の処理」を参照してください。
9.3. CUPS Web UI へのアクセスおよび設定
本セクションでは、CUPS Web ユーザーインターフェース (Web UI) にアクセスし、このインターフェースで印刷を管理できるように設定する方法を説明します。
手順
CUPS Web UI にアクセスするには、以下のコマンドを実行します。
/etc/cups/cupsd.conf
ファイルにポート 631
を設定して、CUPS サーバーがネットワークから接続をリッスンできるようにします。#Listen localhost:631 Port 631
警告CUPS サーバーがポート 631 でリッスンできるようにするには、サーバーがアクセスできるアドレスに対してこのポートを開きます。したがって、この設定は、外部ネットワークから到達できないローカルネットワークでのみ使用してください。サーバーが外部ネットワークからアクセス可能で、ローカルネットワーク用にのみポート 631 を開く必要がある場合は、
/etc/cups/cupsd.conf
ファイルに#Listen <server_local_IP_address>:631
を設定します。<server_local_IP_address> は、外部ネットワークから到達できない IP アドレスですが、ローカルマシンで利用できます。/etc/cups/cupsd.conf
ファイルに以下を追加して、システムが CUPS サーバーにアクセスできるようにします。<Location /> Allow from <your_ip_address> Order allow,deny </Location>
<your_ip_address> は、システムの実際の IP アドレスになります。サブネットに正規表現を使用することもできます。
警告CUPS 設定では、<Location> タグの
Allow from all
ディレクティブを利用できますが、外部インターネットネットワークに CUPS を開く場合や、サーバーがプライベートネットワークにある場合は、Red Hat では使用が推奨されません。Allow from all
を設定すると、ポート 631 からサーバーに接続できるすべてのユーザーがアクセスできるようになります。Port
ディレクティブを 631 に設定し、サーバーが外部ネットワークからアクセスできる場合は、インターネット上の誰もがシステムの CUPS サービスにアクセスできます。cups.service を再起動します。
# systemctl restart cups
ブラウザーを開き、
http://<IP_address_of_the_CUPS_server>:631/
に移動します。Administration
メニュー以外のすべてのメニューが利用できるようになりました。Administration
メニューをクリックすると、 Forbidden メッセージが表示されます。Administration
メニューにアクセスするには、「CUPS Web UI への管理アクセスの取得」の手順に従います。
9.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 への管理アクセスは取得できません。
関連情報
-
/etc/cups/cupsd.conf
ファイルを使用して CUPS サーバーを設定する方法は、man ページのcupsd.conf
を参照してください。
9.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
をクリックすると、新しいプリンターが正常に追加されたことを確認するメッセージが表示されます。

9.5. CUPS Web UI でのプリンターの設定
本セクションでは、新しいプリンターの設定方法と、CUPS Web UI を使用してプリンターの設定を維持する方法を説明します。
前提条件
- 「CUPS Web UI への管理アクセスの取得」の説明に従って、CUPS Web UI への管理アクセスを取得している。
手順
設定可能なプリンターを表示するには、
Printers
メニューをクリックします。構成するプリンターを選択します。
利用可能なメニューのいずれかを使用して、選択したタスクを実行します。
メンテナンスタスクを行うために、
メンテナンス
を選択します。管理タスクの
Administration
に移動します。-
また、
Show Completed Jobs
ボタンまたはShow All Jobs
ボタンをクリックして、完了した印刷ジョブまたはアクティブなすべての印刷ジョブを確認することもできます。
9.6. CUPS Web UI でテストページの印刷
このセクションでは、テストページを印刷して、プリンターが正常に機能することを確認する方法を説明します。
以下のいずれかの条件が満たされる場合は、テストページを出力できます。
- プリンターが設定されている。
- プリンターの設定が変更している。
前提条件
「CUPS Web UI への管理アクセスの取得」の説明に従って、CUPS Web UI への管理アクセスを取得している。
手順
Printers
メニューに移動し、Maintenance
→Print Test Page
をクリックします。
9.7. CUPS Web UI で印刷オプションの設定
本セクションでは、CUPS Web UI で、メディアのサイズと種類、印刷の品質カラーモードなどの一般的な印刷オプションを設定する方法を説明します。
前提条件
「CUPS Web UI への管理アクセスの取得」の説明に従って、CUPS Web UI への管理アクセスを取得している。
手順
Administration
メニューに移動し、Maintenance
→Set Default Options
をクリックします。印刷オプションを設定します。
9.8. プリントサーバーの証明書のインストール
プリントサーバーの証明書をインストールするには、以下のいずれかのオプションを選択します。
- 自己署名証明書を使用した自動インストール
- 証明書と、認証局が生成した秘密鍵を使用した手動インストール
前提条件
サーバーの cupsd デーモンの場合:
/etc/cups/cupsd.conf
ファイルの以下のディレクティブを設定します。Encryption Required
cups サービスを再起動します。
$ sudo systemctl restart cups
自己署名証明書を使用した自動インストール
このオプションを使用すると、CUPS は証明書とキーを自動的に生成します。
自己署名証明書は、Identity Management (IdM)、Active Directory (AD)、または Red Hat Certificate System (RHCS) の認証局が生成する証明書と同様に、強力なセキュリティーを提供しませんが、セキュアなローカルネットワーク内にあるプリントサーバーに使用できます。
手順
CUPS Web UI にアクセスするには、ブラウザーを開き、
https://<server>:631
に移動します。<server> は、サーバーの IP アドレスまたはサーバーのホスト名のいずれかです。
注記CUPS が初めてシステムに接続すると、ブラウザーは自己署名証明書が潜在的なセキュリティーリスクであることを示す警告を表示します。
続行しても安全かを確認するには、
Advanced…
をクリックします。Accept the Risk and Continue
をクリックします。
CUPS が自己生成された証明書と鍵の使用を開始するようになりました。
自動インストール後に CUPS Web UI にアクセスすると、ブラウザーのアドレスバーに警告アイコンが表示されます。これは、セキュリティーリスクの警告を確認してセキュリティー例外を追加したためです。この警告アイコンを永続的に削除する場合は、証明書と、認証局が生成した秘密鍵を使用して手動インストールを実行します。
証明書と、認証局が生成した秘密鍵を使用した手動インストール
パブリックネットワーク内にあるプリントサーバー、またはブラウザーで警告を永続的に削除するには、証明書とキーを手動でインポートします。
前提条件
- IdM、AD、または RHCS 認証局により生成される証明書および秘密鍵ファイルがある。
手順
-
CUPS Web UI を使用するシステムの
/etc/cups/ssl
ディレクトリーに.crt
ファイルおよび.key
ファイルをコピーします。 コピーしたファイルを
<hostname>.crt
および<hostname>.key
に変更します。<hostname> を CUPS Web UI に接続するシステムのホスト名に置き換えます。
以下のパーミッションを名前変更ファイルに設定します。
-
# chmod 644 /etc/cups/ssl/<hostname>.crt
-
# chmod 644 /etc/cups/ssl/<hostname>.key
-
# chown root:root /etc/cups/ssl/<hostname>.crt
-
# chown root:root /etc/cups/ssl/<hostname>.key
-
cups サービスを再起動します。
-
# systemctl restart cupsd
-
9.9. Samba で Kerberos 認証による Windows 印刷サーバーへの印刷
samba-krb5-printing
ラッパーを使用すると、Red Hat Enterprise Linux にログインした Active Directory (AD) ユーザーは、Kerberos を使用して Active Directory (AD) に対して認証して、Windows 印刷サーバーに印刷ジョブを転送するローカルの CUPS 印刷サーバーに印刷できます。
この設定の利点は、Red Hat Enterprise Linux 上の CUPS の管理者が、設定で固定ユーザー名およびパスワードを保存する必要がないことです。CUPS は、印刷ジョブを送信するユーザーの Kerberos チケットで AD に対して認証します。
本セクションでは、このシナリオに CUPS を設定する方法を説明します。
Red Hat は、ローカルシステムから CUPS への印刷ジョブの送信のみに対応し、Samba 印刷サーバーでプリンターを再共有しません。
前提条件
- ローカルの CUPS インスタンスに追加するプリンターが、AD 印刷サーバーで共有されている。
- Red Hat Enterprise Linux ホストを、AD のメンバーとして参加させている。詳細は「RHEL システムの AD ドメインへの参加」を参照してください。
-
CUPS が Red Hat Enterprise Linux にインストールされており、
cups
サービスが実行している。詳細は「cups サービスのアクティブ化」を参照してください。 -
プリンターの PPD (PostScript Printer Description) ファイルは、
/usr/share/cups/model/
ディレクトリーに保存されます。
手順
samba-krb5-printing
パッケージ、samba-client
パッケージ、およびkrb5-workstation
パッケージをインストールします。# yum install samba-krb5-printing samba-client krb5-workstation
必要に応じて、ドメイン管理者として認証を行い、Windows 印刷サーバーで共有されるプリンターの一覧を表示します。
# kinit administrator@AD_KERBEROS_REALM # smbclient -L win_print_srv.ad.example.com -k Sharename Type Comment --------- ---- ------- ... Example Printer Example ...
必要に応じて、CUPS モデルの一覧を表示して、プリンターの PPD 名を指定します。
lpinfo -m ... samsung.ppd Samsung M267x 287x Series PXL ...
次の手順でプリンターを追加する場合は、PPD ファイルの名前が必要です。
CUPS にプリンターを追加します。
# lpadmin -p "example_printer" -v smb://win_print_srv.ad.example.com/Example -m samsung.ppd -o auth-info-required=negotiate -E
コマンドは、以下のオプションを使用します。
-
-p printer_name
は、CUPS にプリンターの名前を設定します。 -
-v URI_to_Windows_printer
は、Windows プリンターに URI を設定します。smb://host_name/printer_share_name
形式を使用します。 -
-m PPD_file
は、プリンターが使用する PPD ファイルを設定します。 -
-o auth-info-required=negotiate
は、印刷ジョブをリモートサーバーに転送する際に CUPS が Kerberos 認証を使用するように設定します。 -
-E
はプリンターを有効にし、CUPS はプリンターのジョブを受け付けます。
-
検証手順
- AD ドメインユーザーとして Red Hat Enterprise Linux ホストにログインします。
AD ドメインユーザーとして認証します。
# kinit domain_user_name@AD_KERBEROS_REALM
ローカルの CUPS 印刷サーバーに追加したプリンターにファイルを出力します。
# lp -d example_printer file
9.10. CUPS ログの使用
9.10.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
ディレクトリーの特定のファイルに保存されなくなりました。
9.10.2. CUPS ログへのアクセス
本セクションでは、以下のアクセス方法を説明します。
- すべての CUPS ログ
- 特定の印刷ジョブの CUPS ログ
- 特定の時間枠内の CUPS ログ
9.10.2.1. すべての CUPS ログへのアクセス
手順
- systemd-semanaged からの CUPS ログにフィルターをかけます。
$ journalctl -u cups
9.10.2.2. 特定の印刷ジョブの CUPS ログへアクセス
手順
- 特定の印刷ジョブのログにフィルターをかけます。
$ journalctl -u cups JID=N
ここで、N
は、印刷ジョブの番号になります。
9.10.2.3. 特定の時間枠による CUPS ログへのアクセス
手順
- 指定した時間枠内でログにフィルターをかけます。
$ journalctl -u cups --since=YYYY-MM-DD --until=YYYY-MM-DD
ここで、YYYY
は年、MM
は月、DD
は日です。
9.10.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
法律上の通知
このページには機械翻訳が使用されている場合があります (詳細はこちら)。