Red Hat Training
A Red Hat training course is available for RHEL 8
さまざまな種類のサーバーのデプロイメント
Red Hat Enterprise Linux 8 にさまざまな種類のサーバーをデプロイするためのガイド
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
Red Hat ドキュメントへのフィードバック (英語のみ)
当社のドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
特定の文章に関するコメントの送信
- Multi-page HTML 形式でドキュメントを表示し、ページが完全にロードされてから右上隅に Feedback ボタンが表示されていることを確認します。
- カーソルを使用して、コメントを追加するテキスト部分を強調表示します。
- 強調表示されたテキストの近くに表示される Add Feedback ボタンをクリックします。
- フィードバックを追加し、Submit をクリックします。
Bugzilla からのフィードバック送信 (アカウントが必要)
- Bugzilla の Web サイトにログインします。
- Version メニューから正しいバージョンを選択します。
- Summary フィールドにわかりやすいタイトルを入力します。
- 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.2. Apache HTTP Server への主な変更点
Apache HTTP Server が、RHEL 7 のバージョン 2.4.6 から、RHEL 8 のバージョン 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 Server 設定で秘密鍵と証明書を使用できるように NSS データベースからの証明書のエクスポート」 を参照してください。-
mod_perl
-
-
RHEL 8 の Apache HTTP Server が使用するデフォルトの DBM 認証データベースのデフォルトタイプが、
SDBM
からdb5
に変更になりました。 -
Apache HTTP Server の
mod_wsgi
モジュールが Python 3 に更新されました。WSGI アプリケーションは Python 3 でしか対応していないため、Python 2 から移行する必要があります。 Apache HTTP Server を使用してデフォルトで設定されたマルチプロセッシングモジュール (MPM) は、マルチプロセスのフォークモデル (
prefork
として知られています) から、高パフォーマンスのマルチスレッドモデルevent
に変更しました。スレッドセーフではないサードパーティーのモジュールは、交換または削除する必要があります。設定した MPM を変更するには、
/etc/httpd/conf.modules.d/00-mpm.conf
ファイルを編集します。詳細は、man ページのhttpd.service(8)
を参照してください。- suEXEC によりユーザーに許可される最小 UID および GID はそれぞれ 1000 および 500 です (以前は 100 および 100 でした)。
-
/etc/sysconfig/httpd
ファイルは、httpd
サービスへの環境変数の設定に対応するインターフェイスではなくなりました。systemd サービスに、httpd.service(8)
の man ページが追加されています。 -
httpd
サービスを停止すると、デフォルトで自動停止が使用されます。 -
mod_auth_kerb
モジュールが、mod_auth_gssapi
モジュールに置き換わりました。
1.3. 設定の更新
Red Hat Enterprise Linux 7 で使用されている Apache HTTP Server バージョンから設定ファイルを更新するには、以下のいずれかのオプションを選択します。
-
/etc/sysconfig/httpd
を使用して環境変数を設定する場合は、代わりに systemd ドロップインファイルを作成します。 - サードパーティーのモジュールを使用する場合は、そのモジュールがスレッド化 MPM と互換性があることを確認してください。
- suexec を使用する場合は、ユーザーおよびグループの ID が新しい最小値に合致していることを確認します。
以下のコマンドを使用すると、設定に誤りがないかどうかを確認できます。
# apachectl configtest Syntax OK
1.4. Apache 設定ファイル
デフォルトでは、httpd
は起動後に設定ファイルを読み取ります。次の表に、設定ファイルの場所のリストを示します。
表1.2 httpd サービスの設定ファイル
パス | 詳細 |
---|---|
| 主要設定ファイル。 |
| 主要設定ファイル内に含まれている設定ファイル用の補助ディレクトリー。 |
| Red Hat Enterprise Linux にパッケージ化されたインストール済みの動的モジュールを読み込む設定ファイルの補助ディレクトリー。デフォルト設定では、この設定ファイルが最初に処理されます。 |
デフォルト設定はほとんどの状況に適していますが、その他の設定オプションを使用することもできます。変更を有効にするには、まず Web サーバーを再起動します。
設定に誤りがないことを確認するには、シェルプロンプトで以下のコマンドを実行します。
# apachectl configtest
Syntax OK
間違いからの復元を容易にするため、編集する前にオリジナルファイルのコピーを作成します。
1.5. httpd サービスの管理
本セクションでは、httpd
サービスを起動、停止、および再起動する方法を説明します。
前提条件
- Apache HTTP Server がインストールされている。
手順
httpd
サービスを起動するには、以下を入力します。# systemctl start httpd
httpd
サービスを停止するには、以下を入力します。# systemctl stop httpd
httpd
サービスを再起動するには、以下を入力します。# systemctl restart httpd
1.6. シングルインスタンスの Apache HTTP Server 設定
本セクションでは、シングルインスタンスの Apache HTTP Server を設定して静的 HTML コンテンツを提供する方法を説明します。
サーバーに関連付けられた全ドメインに、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
ユーザーおよびroot
ユーザーグループの場合には、他のユーザーがファイルを読み取れるようにする必要があります。すべてのファイルとディレクトリーの SELinux コンテキストはhttpd_sys_content_t
である必要があります。これはデフォルトで/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 HTTP サーバーマニュアルのインストール
-
man ページの
httpd.service(8)
を参照してください。
1.7. Apache 名前ベースの仮想ホストの設定
名前ベースの仮想ホストを使用すると、サーバーの IP アドレスに対して解決するドメイン別に、Apache が異なるコンテンツを提供できるようにします。
本セクションの手順では、ドキュメントルートディレクトリーが異なる 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/
DocumentRoot
パラメーターのパスが/var/www/
内にない設定を行う場合は、両方のドキュメントルートに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
仮想ホストからのサンプルファイルを表示します。
1.8. Apache HTTP Web サーバーの Kerberos 認証の設定
Apache HTTP Web サーバーで Kerberos 認証を実行するために、RHEL 8 は mod_auth_gssapi
Apache モジュールを使用します。Generic Security Services API (GSSAPI
) は、Kerberos などのセキュリティーライブラリーを使用する要求を行うアプリケーションのインターフェイスです。gssproxy
サービスでは、httpd
サーバーに特権の分離を実装できます。これにより、セキュリティーの観点からこのプロセスが最適化されます。
削除した mod_auth_kerb
モジュールは、mod_auth_gssapi
モジュールに置き換わります。
前提条件
-
httpd
パッケージおよびgssproxy
パッケージがインストールされている。 -
Apache Web サーバーが設定され、
httpd
サービスが実行している。
1.8.1. IdM 環境で GSS-Proxy の設定
この手順では、Apache HTTP Web サーバーで Kerberos 認証を実行するように GSS-Proxy
を設定する方法を説明します。
手順
サービスプリンシパルを作成し、HTTP/<SERVER_NAME>@realm プリンシパルの
keytab
ファイルへのアクセスを有効にします。# ipa service-add HTTP/<SERVER_NAME>
/etc/gssproxy/http.keytab
ファイルに保存されているプリンシパルのkeytab
を取得します。# ipa-getkeytab -s $(awk '/^server =/ {print $3}' /etc/ipa/default.conf) -k /etc/gssproxy/http.keytab -p HTTP/$(hostname -f)
このステップでは、パーミッションを 400 に設定すると、
root
ユーザーのみがkeytab
ファイルにアクセスできます。apache
ユーザーは異なります。以下の内容で
/etc/gssproxy/80-httpd.conf
ファイルを作成します。[service/HTTP] mechs = krb5 cred_store = keytab:/etc/gssproxy/http.keytab cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U euid = apache
gssproxy
サービスを再起動して、有効にします。# systemctl restart gssproxy.service # systemctl enable gssproxy.service
関連情報
-
gssproxy(8)
の man ページ -
gssproxy-mech(8)
の man ページ -
gssproxy.conf(5)
の man ページ
1.8.2. Apache HTTP Web サーバーが共有するディレクトリーに Kerberos 認証の設定
この手順では、/var/www/html/private/
ディレクトリーに Kerberos 認証を設定する方法を説明します。
前提条件
-
gssproxy
サービスが設定され、実行されている。
手順
/var/www/html/private/
ディレクトリーを保護するようにmod_auth_gssapi
を設定します。<Location /var/www/html/private> AuthType GSSAPI AuthName "GSSAPI Login" Require valid-user </Location>
以下の内容で
/etc/systemd/system/httpd.service
ファイルを作成します。.include /lib/systemd/system/httpd.service [Service] Environment=GSS_USE_PROXY=1
systemd
設定をリロードします。# systemctl daemon-reload
httpd
サービスを再起動します。# systemctl restart httpd.service
検証手順
Kerberos チケットを取得します。
# kinit
- ブラウザーで、保護されているディレクトリーの URL を開きます。
1.9. Apache HTTP サーバーで TLS 暗号化の設定
デフォルトでは、Apache は暗号化されていない HTTP 接続を使用してクライアントにコンテンツを提供します。本セクションでは、TLS 暗号化を有効にし、Apache HTTP Server で頻繁に使用される暗号化関連の設定を行う方法を説明します。
前提条件
- Apache HTTP Server がインストールされ、実行している。
1.9.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/certs/example.com.crt
ファイルに保存されます。別のパスを使用する場合は、この手順で対応する手順を調整します。 -
認証局証明書は
/etc/pki/tls/certs/ca.crt
に保存されています。別のパスを使用する場合は、この手順で対応する手順を調整します。 - クライアントおよび Web サーバーは、サーバーのホスト名を Web サーバーの IP アドレスに対して解決します。
手順
mod_ssl
パッケージをインストールします。# yum 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/tcp # firewall-cmd --reload
httpd
サービスを再起動します。# systemctl restart httpd
注記パスワードで秘密鍵ファイルを保護した場合は、
httpd
サービスの起動時に毎回このパスワードを入力する必要があります。
検証手順
-
ブラウザーを使用して、
https://example.com
に接続します。
1.9.2. Apache HTTP サーバーでサポートされる TLS プロトコルバージョンの設定
デフォルトでは、RHEL の Apache HTTP Server は、最新のブラウザーにも互換性のある安全なデフォルト値を定義するシステム全体の暗号化ポリシーを使用します。たとえば、DEFAULT
ポリシーでは、TLSv1.2
および TLSv1.3
プロトコルバージョンのみが Apache で有効になるように定義します。
本セクションでは、Apache HTTP Server がサポートする TLS プロトコルバージョンを手動で設定する方法を説明します。たとえば、環境が特定の TLS プロトコルバージョンのみを有効にする必要がある場合には、以下の手順に従います。
-
お使いの環境のクライアントで、セキュリティーの低い
TLS1
(TLSv1.0) プロトコルまたはTLS1.1
プロトコルも使用できるようにする必要がある場合。 -
Apache が
TLSv1.2
プロトコルまたはTLSv1.3
プロトコルのみに対応するように設定する場合。
前提条件
- Apache HTTP Server への TLS 暗号化の追加 で説明されているとおり、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 プロトコルバージョンのコマンドを繰り返し実行します。
関連情報
-
update-crypto-policies(8)
の man ページ - Using system-wide cryptographic policies.
-
SSLProtocol
パラメーターの詳細については、Apache マニュアルのmod_ssl
のドキュメント Apache HTTP サーバーマニュアルのインストール を参照してください。
1.9.3. Apache HTTP サーバーで対応している暗号の設定
デフォルトでは、Apache HTTP サーバーは、安全なデフォルト値を定義するシステム全体の暗号化ポリシーを使用します。これは、最近のブラウザーとも互換性があります。システム全体の暗号化で使用可能な暗号化の一覧は、/etc/crypto-policies/back-ends/openssl.config
ファイルを参照してください。
本セクションでは、Apache HTTP Server がサポートする暗号化を手動で設定する方法を説明します。お使いの環境で特定の暗号が必要な場合は、以下の手順に従います。
前提条件
- Apache HTTP Server への TLS 暗号化の追加 で説明されているとおり、TLS 暗号化がサーバーで有効になります。
手順
/etc/httpd/conf/httpd.conf
ファイルを編集し、TLS 暗号を設定する<VirtualHost>
ディレクティブにSSLCipherSuite
パラメーターを追加します。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 ...
関連情報
-
update-crypto-policies(8)
の man ページ - Using system-wide cryptographic policies.
- SSLCipherSuite
1.10. 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 を参照してください。
前提条件
- Apache HTTP Server への TLS 暗号化の追加 で説明されているとおり、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
ファイルを表示します。
1.11. ModSecurity を使用した Web サーバー上の Web アプリケーションの保護
ModSecurity は、Apache、Nginx、IIS などのさまざまな Web サーバーでサポートされているオープンソースの Web アプリケーションファイアウォール (WAF) であり、Web アプリケーションのセキュリティーリスクを軽減します。ModSecurity は、サーバーを設定するためのカスタマイズ可能なルールセットを提供します。
mod_security-crs
パッケージには、クロス Web サイトスクリプティング、不正なユーザーエージェント、SQL インジェクション、トロイの木馬、セッションハイジャック、およびその他の不正使用に対するルールを含むコアルールセット (CRS) が含まれています。
1.11.1. Apache 用 ModSecurity Web ベースアプリケーションファイアウォールのデプロイ
ModSecurity をデプロイして、Web サーバー上で Web ベースアプリケーションの実行に関連するリスクを軽減するには、Apache HTTP サーバー用の mod_security
および mod_security_crs
パッケージをインストールします。mod_security_crs
パッケージは、ModSecurity Web ベースのアプリケーションファイアウォール (WAF) モジュールのコアルールセット (CRS) を提供します。
手順
mod_security
、mod_security_crs
、およびhttpd
パッケージをインストールします。# yum install -y mod_security mod_security_crs httpd
httpd
サーバーを起動します。# systemctl restart httpd
検証
ModSecurity Web ベースアプリケーションファイアウォールが Apache HTTPサーバーで有効になっていることを確認します。
# httpd -M | grep security security2_module (shared)
/etc/httpd/modsecurity.d/activated_rules/
ディレクトリーにmod_security_crs
によって提供されるルールが含まれていることを確認します。# ls /etc/httpd/modsecurity.d/activated_rules/ ... REQUEST-921-PROTOCOL-ATTACK.conf REQUEST-930-APPLICATION-ATTACK-LFI.conf ...
1.11.2. ModSecurity へのカスタムルールの追加
ModSecurity コアルールセット (CRS) に含まれるルールがシナリオに適合せず、追加の攻撃の可能性を防ぎたい場合は、カスタムルールを ModSecurity Web ベースアプリケーションファイアウォールで使用されるルールセットに追加できます。次の例は、単純なルールの追加を示しています。より複雑なルールを作成するには、ModSecurity Wiki Web サイトのリファレンスマニュアルを参照してください。
前提条件
- ModSecurity for Apache がインストールされ、有効になっている。
手順
任意のテキストエディターで
/etc/httpd/conf.d/mod_security.conf
ファイルを開きます。以下はその例です。# vi /etc/httpd/conf.d/mod_security.conf
SecRuleEngine On
で始まる行の後に、次のサンプルルールを追加します。SecRule ARGS:data "@contains evil" "deny,status:403,msg:'param data contains evil data',id:1"
前のルールでは、
data
パラメーターにevil
の文字列が含まれている場合、ユーザーによるリソースの使用を禁止しています。- 変更を保存し、エディターを終了します。
httpd
サーバーを再起動します。# systemctl restart httpd
検証
test.html
ページを作成します。# echo "mod_security test" > /var/www/html/test.html
httpd
サーバーを再起動します。# systemctl restart httpd
HTTP リクエストの
GET
変数に悪意のあるデータが含まれないtest.html
をリクエストします。$ curl http://localhost/test.html?data=good mod_security test
HTTP リクエストの
GET
変数に悪意のあるデータが含まれるtest.html
をリクエストします。$ curl localhost/test.html?data=xxxevilxxx <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access this resource.</p> </body></html>
/var/log/httpd/error_log
ファイルを確認し、param data containing an evil data
メッセージでアクセスを拒否するログエントリーを見つけます。[Wed May 25 08:01:31.036297 2022] [:error] [pid 5839:tid 139874434791168] [client ::1:45658] [client ::1] ModSecurity: Access denied with code 403 (phase 2). String match "evil" at ARGS:data. [file "/etc/httpd/conf.d/mod_security.conf"] [line "4"] [id "1"] [msg "param data contains evil data"] [hostname "localhost"] [uri "/test.html"] [unique_id "Yo4amwIdsBG3yZqSzh2GuwAAAIY"]
関連情報
1.12. 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.13. Apache モジュールの操作
httpd
サービスはモジュラーアプリケーションであり、多数の 動的共有オブジェクト (DSO) で拡張できます。動的共有オブジェクト は、必要に応じて実行時に動的にロードまたはアンロードできるモジュールです。これらのモジュールは /usr/lib64/httpd/modules/
ディレクトリーにあります。
1.13.1. DSO モジュールのロード
管理者は、サーバーがロードするモジュールを設定することにより、サーバーに含める機能を選択できます。特定の DSO モジュールを読み込むには、LoadModule
ディレクティブを使用します。別のパッケージが提供するモジュールは、多くの場合、/etc/httpd/conf.modules.d/
ディレクトリーに独自の設定ファイルがあることに注意してください。
前提条件
-
httpd
パッケージをインストールしている。
手順
/etc/httpd/conf.modules.d/
ディレクトリーの設定ファイルでモジュール名を検索します。# grep mod_ssl.so /etc/httpd/conf.modules.d/*
モジュール名が見つかった設定ファイルを編集し、モジュールの
LoadModule
ディレクティブのコメントを外します。LoadModule ssl_module modules/mod_ssl.so
RHEL パッケージがモジュールを提供していないなどの理由でモジュールが見つからなかった場合は、次のディレクティブを使用して
/etc/httpd/conf.modules.d/30-example.conf
などの設定ファイルを作成します。LoadModule ssl_module modules/<custom_module>.so
httpd
サービスを再起動します。# systemctl restart httpd
1.13.2. カスタム Apache モジュールのコンパイル
独自のモジュールを作成し、モジュールのコンパイルに必要なインクルードファイル、ヘッダーファイル、および APache eXtenSion
(apxs
) ユーティリティーを含む httpd-devel
パッケージを使用してビルドできます。
前提条件
-
httpd-devel
パッケージがインストールされている。
手順
次のコマンドでカスタムモジュールをビルドします。
# apxs -i -a -c module_name.c
検証手順
- DSO モジュールのロード で説明されている方法でモジュールをロードします。
1.14. Apache Web Server 設定で秘密鍵と証明書を使用できるように NSS データベースからの証明書のエクスポート
RHEL 8 では Apache Web Server に 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 SUCCESSFUL
PKCS #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.15. 関連情報
-
httpd(8)
-
httpd.service(8)
-
httpd.conf(5)
-
apachectl(8)
- GSS-Proxy を使用した Apache httpd の操作。
- PKCS #11 で暗号化ハードウェアを使用するようにアプリケーションを設定
第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 は Web サーバーとして機能し、サーバーの IP アドレスに関連付けられた全ドメイン名のクライアントに、同じコンテンツを提供します。この手順では、NGINX を設定する方法を説明します。
-
/var/www/example.com/
ディレクトリーのコンテンツで、example.com
ドメインに対するリクエストに対応する。 -
/var/www/example.net/
ディレクトリーのコンテンツで、example.net
ドメインに対するリクエストに対応する。 -
その他の全リクエスト (たとえば、サーバーの IP アドレスまたはサーバーの IP アドレスに関連付けられたその他のドメイン) に
/usr/share/nginx/html/
ディレクトリーのコンテンツを指定します。
前提条件
- NGINX がインストールされている
クライアントおよび Web サーバーは、
example.com
およびexample.net
ドメインを Web サーバーの IP アドレスに解決します。これらのエントリーは DNS サーバーに手動で追加する必要がある点に注意してください。
手順
/etc/nginx/nginx.conf
ファイルを編集します。デフォルトでは、
/etc/nginx/nginx.conf
ファイルには catch-all 設定がすでに含まれています。設定からこの部分を削除した場合は、以下のserver
ブロックを/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 がインストールされている。
秘密鍵は
/etc/pki/tls/private/example.com.key
ファイルに保存されます。秘密鍵および証明書署名要求 (CSR) を作成する方法と、認証局 (CA) からの証明書を要求する方法は、CA のドキュメントを参照してください。
-
TLS 証明書は
/etc/pki/tls/certs/example.com.crt
ファイルに保存されます。別のパスを使用する場合は、この手順で対応する手順を調整します。 - CA 証明書がサーバーの TLS 証明書ファイルに追加されている。
- クライアントおよび Web サーバーは、サーバーのホスト名を Web サーバーの IP アドレスに対して解決します。
-
ポート
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 がインストールされている
- 必要に応じて、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 がインストールされている
手順
/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 バージョンで機能しない可能性があることに注意してください。
- PKCS #11 で暗号化ハードウェアを使用するようにアプリケーションを設定
第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 プロトコルを使用してファイル共有およびプリントサービスを提供します。また、サービスは、リソースのロックと、接続ユーザーの認証を担当します。ドメインメンバーを認証するには、
smbd
にwinbindd
が必要です。smb
systemd
サービスが起動し、smbd
デーモンが停止します。smbd
サービスを使用するには、samba
パッケージをインストールします。nmbd
このサービスは、NetBIOS over IPv4 プロトコルを使用してホスト名および IP 解決を提供します。名前解決に加え、
nmbd
サービスで SMB ネットワークを参照して、ドメイン、作業グループ、ホスト、ファイル共有、およびプリンターを探すことができます。このため、サービスはこの情報をブロードキャストクライアントに直接報告するか、ローカルまたはマスターのブラウザーに転送します。nmb
systemd
サービスは、nmbd
デーモンを起動し、停止します。最近の SMB ネットワークは、クライアントおよび IP アドレスの解決に DNS を使用することに注意してください。Kerberos の場合は、稼働中の 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 ドメインメンバーサーバーとして設定 を参照してください。
関連情報
-
smb.conf(5)
man ページの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.conf
Samba サービスが設定を自動的に再読み込みするか、または手動で設定を再読み込みするまで待ちます。
# smbcontrol all reload-config
3.2. testparm ユーティリティーを使用した smb.conf ファイルの検証
testparm
ユーティリティーは、/etc/samba/smb.conf
ファイルの Samba 設定が正しいことを確認します。このユーティリティーは、無効なパラメーターおよび値を検出しますが、ID マッピングなどの間違った設定も検出します。testparm
が問題を報告しないと、Samba サービスは /etc/samba/smb.conf
ファイルを正常に読み込みます。testparm
は、設定されたサービスが利用可能であること、または期待通りに機能するかを確認できないことに注意してください。
Red Hat では、このファイルの変更後に毎回 testparm
を使用して、/etc/samba/smb.conf
ファイルを検証することが推奨されます。
前提条件
- 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-service=samba # firewall-cmd --reload
smb
サービスを有効にして起動します。# systemctl enable --now smb
関連情報
-
smb.conf(5)
man ページ
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
関連情報
- * デフォルトドメイン
-
smb.conf(5)
およびidmap_ad(8)
man ページ -
smb.conf(5)
man ページの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 がその範囲内にないユーザーおよびグループを無視します。
重要この範囲は、このサーバーの他のドメイン設定と重複させることはできません。また、この範囲には、今後割り当てられる ID がすべて収まる大きさを設定する必要があります。詳細は、Samba ID 範囲の計画 を参照してください。
すべてのマッピングユーザーに割り当てられるシェルおよびホームディレクトリーのパスを設定します。以下に例を示します。
template shell = /bin/bash template homedir = /home/%U
/etc/samba/smb.conf
ファイルを検証します。# testparm
Samba 設定を再読み込みします。
# smbcontrol all reload-config
関連情報
- * デフォルトドメイン
-
smb.conf(5)
man ページのVARIABLE SUBSTITUTIONS
セクション -
RID からのローカル ID の計算については、
idmap_rid(8)
man ページを参照してください。
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 を割り当てます。注記rangesize を設定する場合は、適宜範囲を調整する必要があります。この範囲は rangesize の倍数である必要があります。
すべてのマッピングユーザーに割り当てられるシェルおよびホームディレクトリーのパスを設定します。以下に例を示します。
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
関連情報
-
idmap_autorid(8)
man ページのTHE MAPPING FORMULAS
セクション -
idmap_autorid(8)
man ページのrangesize
パラメーターの説明 -
smb.conf(5)
man ページのVARIABLE SUBSTITUTIONS
セクション
3.5. Samba を AD ドメインメンバーサーバーとして設定
AD または NT4 のドメインを実行している場合は、Samba を使用して Red Hat Enterprise Linux サーバーをメンバーとしてドメインに追加し、以下を取得します。
- その他のドメインメンバーのドメインリソースにアクセスする
-
sshd
などのローカルサービスに対してドメインユーザーを認証する - サーバーにホストされているディレクトリーおよびプリンターを共有して、ファイルサーバーおよびプリントサーバーとして動作する
3.5.1. RHEL システムの AD ドメインへの参加
Samba Winbind は、Red Hat Enterprise Linux (RHEL) システムを Active Directory (AD) に接続するための System Security Services Daemon (SSSD) の代替手段です。本セクションでは、realmd
を使用して Samba Winbind を設定して、RHEL システムを 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
サービスを起動し、システムの起動時にサービスを起動できるようにします。
-
-
必要に応じて、
/etc/samba/smb.conf
ファイルの別の ID マッピングバックエンド、またはカスタマイズした ID マッピングを設定します。詳細は、SambaID マッピングの理解と設定 を参照してください。 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/bash
AD ドメイン内のドメインユーザーグループのメンバーをクエリーします。
# 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 暗号化タイプを有効にすることができます。See
- GPO を使用した Active Directory で AES 暗号化タイプの有効化これは、AD の他のサービスに影響を及ぼす可能性があることに注意してください。
-
realm(8)
man ページ
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 }
関連情報
-
winbind_krb5_localauth(8)
man ページ.
3.6. IdM ドメインメンバーでの Samba の設定
本セクションでは、Red Hat Identity Management (IdM) ドメインに参加しているホストで Samba を設定する方法を説明します。IdM のユーザー、および可能であれば、信頼された Active Directory (AD) ドメインのユーザーは、Samba が提供する共有およびプリンターサービスにアクセスできます。
IdM ドメインメンバーで Samba を使用する機能は、テクノロジープレビュー機能で、特定の制限が含まれています。たとえば、IdM 信頼コントローラーは Active Directory グローバルカタログサービスをサポートしておらず、分散コンピューティング環境/リモートプロシージャコール (DCE/RPC) プロトコルを使用した IdM グループの解決をサポートしていません。結果として、AD ユーザーは、他の IdM クライアントにログインしている場合、IdM クライアントでホストされている Samba 共有とプリンターにのみアクセスできます。Windows マシンにログインしている AD ユーザーは、IdM ドメインメンバーでホストされている Samba 共有にアクセスできません。
IdM ドメインメンバーに Samba をデプロイしているお客様は、ぜひ Red Hat にフィードバックをお寄せください。
前提条件
- ホストは、クライアントとして IdM ドメインに参加している。
- IdM サーバーとクライアントの両方が RHEL 8.1 以降で実行されている必要がある。
3.6.1. Samba をドメインメンバーにインストールするための IdM ドメインの準備
IdM クライアントに Samba を設定する前に、IdM サーバーで ipa-adtrust-install
ユーティリティーを使用して IdM ドメインを準備する必要があります。
ipa-adtrust-install
コマンドを自動的に実行するシステムは、AD 信頼コントローラーになります。ただし、ipa-adtrust-install
は、IdM サーバーで 1 回のみ実行する必要があります。
前提条件
- IdM サーバーがインストールされている。
- パッケージをインストールし、IdM サービスを再起動するには、root 権限が必要です。
手順
必要なパッケージをインストールします。
[root@ipaserver ~]# yum install ipa-server-trust-ad samba-client
IdM 管理ユーザーとして認証します。
[root@ipaserver ~]# kinit admin
ipa-adtrust-install
ユーティリティーを実行します。[root@ipaserver ~]# ipa-adtrust-install
統合 DNS サーバーとともに IdM がインストールされていると、DNS サービスレコードが自動的に作成されます。
IdM が統合 DNS サーバーなしで IdM をインストールすると、
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
これはリソースを集中的に使用するタスクであるため、ユーザー数が多い場合は別のタイミングで実行できます。
(必要に応じて) デフォルトでは、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 -U user_name --use-kerberos=required
lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.15.2) ...
3.6.2. GPO を使用した Active Directory で AES 暗号化タイプの有効化
本セクションでは、グループポリシーオブジェクト (GPO) を使用して、Active Directory (AD) で AES 暗号化タイプを有効にする方法を説明します。IdM クライアントで Samba サーバーを実行するなど、RHEL の特定の機能には、この暗号化タイプが必要です。
RHEL は、弱い DES および RC4 の暗号化タイプをサポートしなくなった点に注意してください。
前提条件
- グループポリシーを編集できるユーザーとして AD にログインしている。
-
Group Policy Management Console
がコンピューターにインストールされている。
手順
-
Group Policy Management Console
を開きます。 -
デフォルトドメインポリシー
を右クリックして、編集
を選択します。Group Policy Management Editor
を閉じます。 -
コンピューターの設定
→ポリシー
→Windows の設定
→セキュリティーの設定
→ローカルポリシー
→セキュリティーオプション
に移動します。 -
ネットワーク セキュリティー: Kerberos で許可する暗号化の種類を設定する
をダブルクリックします。 -
AES256_HMAC_SHA1
を選択し、必要に応じて、将来の暗号化タイプ
を選択します。 - OK をクリックします。
-
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 認証を使用して、Samba サーバー上の共有を一覧表示します。
$
smbclient -L idm_client.idm.example.com -U user_name --use-kerberos=required
lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- example Disk IPC$ IPC IPC Service (Samba 4.15.2) ...
関連情報
-
ipa-client-samba(1)
の man ページ
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 認証を使用して、Samba サーバー上の共有を一覧表示します。
$
smbclient -L idm_client.idm.example.com -U user_name --use-kerberos=required
lp_load_ex: changing to config backend registry Sharename Type Comment --------- ---- ------- example Disk IPC$ IPC IPC Service (Samba 4.15.2) ...
3.6.5. 関連情報
3.7. POSIX ACL を使用した Samba ファイル共有の設定
Samba は、Linux サービスとして、POSIX ACL との共有に対応します。chmod
などのユーティリティーを使用して、Samba サーバーの権限をローカルに管理できます。拡張属性に対応するファイルシステムに共有が保存されている場合は、複数のユーザーおよびグループで ACL を定義できます。
代わりにきめ細かい Windows ACL を使用する必要がある場合は、Windows ACL を使用する共有の設定 を参照してください。
このセクションの一部は、Samba Wiki に公開されているドキュメント Setting up a Share Using POSIX ACLs に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。
3.7.1. POSIX ACL を使用する共有の追加
本セクションでは、/srv/samba/example/
ディレクトリーのコンテンツを提供し、POSIX ACL を使用する example
という名前の共有を作成する方法を説明します。
前提条件
Samba が、以下のいずれかのモードで設定されている。
手順
ディレクトリーが存在しない場合は作成します。以下に例を示します。
# mkdir -p /srv/samba/example/
SELinux を、
enforcing
モードで実行する場合は、そのディレクトリーにsamba_share_t
コンテキストを設定します。# semanage fcontext -a -t samba_share_t "/srv/samba/example(/.*)?" # restorecon -Rv /srv/samba/example/
ディレクトリーにファイルシステムの ACL を設定します。詳細は、次を参照してください。
/etc/samba/smb.conf
ファイルにサンプル共有を追加します。たとえば、共有の write-enabled を追加するには、次のコマンドを実行します。[example] path = /srv/samba/example/ read only = no
注記ファイルシステムの ACL に関係なく、
read only = no
を設定しないと、Samba がディレクトリーを読み取り専用モードで共有します。/etc/samba/smb.conf
ファイルを検証します。# testparm
firewall-cmd
ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。# firewall-cmd --permanent --add-service=samba # firewall-cmd --reload
smb
サービスを再起動します。# systemctl restart smb
3.7.2. POSIX ACL を使用する Samba 共有での標準的な Linux ACL の設定
Linux の標準 ACL は、所有者、グループ、その他の未定義ユーザーの権限の設定に対応します。ユーティリティーの chown
、chgrp
、および chmod
を使用して ACL を更新できます。正確な制御が必要な場合は、より複雑な POSIX ACL を使用します。以下を参照してください。
Setting extended ACLs on a Samba share that uses POSIX ACLs.
以下の手順では、/srv/samba/example/
ディレクトリーの所有者を root
ユーザーに設定し、Domain Users
グループに読み取りおよび書き込みの権限を付与して、他のすべてのユーザーのアクセスを拒否します。
前提条件
- ACL を設定する Samba 共有がある。
手順
# chown root:"Domain Users" /srv/samba/example/ # chmod 2770 /srv/samba/example/
ディレクトリーで set-group-ID (SGID) ビットを有効にすると、新しいディレクトリーエントリーを作成したユーザーのプライマリーグループに設定する通常の動作の代わりに、すべての新しいファイルとサブディレクトリーのデフォルトグループが、そのディレクトリーグループのデフォルトグループに自動的に設定されます。
関連情報
-
chown(1)
およびchmod(1)
の man ページ
3.7.3. POSIX ACL を使用する Samba 共有での拡張 ACL の設定
共有ディレクトリーが保存されているファイルシステムが拡張 ACL に対応している場合は、それを使用して複雑な権限を設定できます。拡張 ACL には、複数のユーザーおよびグループの権限を指定できます。
拡張 POSIX ACL を使用すると、複数のユーザーおよびグループで複雑な ACL を設定できます。ただし、設定できるのは以下の権限のみです。
- アクセスなし
- 読み取りアクセス
- 書き込みアクセス
- 完全な制御
フォルダーの作成やデータの追加
など、詳細な Windows 権限が必要な場合は、Windows ACL を使用するように共有を設定します。Windows ACL で共有の設定
以下の手順では、共有で拡張 ACL を有効にする方法を説明します。また、拡張 ACL の設定例も含まれています。
前提条件
- ACL を設定する Samba 共有がある。
手順
/etc/samba/smb.conf
ファイルの共有セクションで以下のパラメーターを有効にして、拡張 ACL の ACL 継承を有効にします。inherit acls = yes
詳細は、man ページの
smb.conf(5)
のパラメーターの説明を参照してください。smb
サービスを再起動します。# systemctl restart smb
ディレクトリーの ACL を設定します。以下に例を示します。
例3.2 拡張 ACL の設定
以下の手順は、
/srv/samba/example/
ディレクトリーに対して、Domain Admins
グループに読み取り、書き込み、および実行の権限、Domain Users
グループに対する読み取りおよび実行の権限を設定し、その他の全員のアクセスを拒否します。ユーザーアカウントのプライマリーグループへの自動許可権限を無効にします。
# setfacl -m group::--- /srv/samba/example/ # setfacl -m default:group::--- /srv/samba/example/
ディレクトリーのプライマリーグループは、さらに動的な
CREATOR GROUP
プリンシパルにマッピングされます。Samba 共有で拡張 POSIX ACL を使用すると、このプリンシパルは自動的に追加され、削除できません。ディレクトリーに権限を設定します。
Domain Admins
グループに読み取り、書き込み、および実行の権限を付与します。# setfacl -m group:"DOMAIN\Domain Admins":rwx /srv/samba/example/
Domain Users
グループに読み取りおよび実行の権限を付与します。# setfacl -m group:"DOMAIN\Domain Users":r-x /srv/samba/example/
その他
の ACL エントリーに権限を設定し、その他の ACL エントリーに一致しないユーザーへのアクセスを拒否します。# setfacl -R -m other::--- /srv/samba/example/
この設定は、このディレクトリーにのみ適用されます。Windows では、これらの ACL は
このフォルダーのみ
のモードにマッピングされます。前の手順で設定した権限を、このディレクトリーに作成した新規ファイルシステムのオブジェクトから継承できるようにするには、以下のコマンドを実行します。
# setfacl -m default:group:"DOMAIN\Domain Admins":rwx /srv/samba/example/ # setfacl -m default:group:"DOMAIN\Domain Users":r-x /srv/samba/example/ # setfacl -m default:other::--- /srv/samba/example/
この設定では、プリンシパルの
このフォルダーのみ
モードが、このフォルダー、サブフォルダー、およびファイル
に設定されます。
Samba は、手順に設定されている権限を、以下の Windows ACL にマッピングします。
プリンシパル アクセス 適用先 Domain\Domain Admins
完全な制御
このフォルダー、サブフォルダー、およびファイル
Domain\Domain Users
読み取りおよび実行
このフォルダー、サブフォルダー、およびファイル
Everyone
[a]なし
このフォルダー、サブフォルダー、およびファイル
owner (Unix User\owner) [b]
完全な制御
このフォルダーのみ
primary_group (Unix User\primary_group) [c]
なし
このフォルダーのみ
完全な制御
サブフォルダーおよびファイルのみ
なし
サブフォルダーおよびファイルのみ
[a] Samba は、このプリンシパルの権限をその他
の ACL エントリーからマッピングします。[b] Samba は、ディレクトリーの所有者をこのエントリーにマッピングします。[c] Samba は、ディレクトリーのプライマリーグループをこのエントリーにマッピングします。[d] 新規ファイルシステムオブジェクトでは、作成者はこのプリンシパルの権限を自動的に継承します。[e] POSIX ACL を使用する共有では、このプリンシパルの設定または削除には対応していません。[f] 新規ファイルシステムオブジェクトの場合、作成者のプライマリーグループは、自動的にこのプリンシパルの権限を継承します。
3.8. POSIX ACL を使用する共有への権限の設定
必要に応じて、Samba 共有へのアクセスを制限または許可するには、/etc/samba/smb.conf
ファイルの共有のセクションに特定のパラメーターを設定します。
共有ベースの権限は、ユーザー、グループ、またはホストが共有にアクセスできるかどうかを管理します。この設定は、ファイルシステムの ACL には影響しません。
共有ベースの設定を使用して共有へのアクセスを制限します。たとえば、特定のホストからのアクセスを拒否します。
前提条件
- POSIX ACL との共有が設定されている。
3.8.1. ユーザーおよびグループに基づいた共有アクセスの設定
ユーザーおよびグループに基づいたアクセス制御により、特定のユーザーおよびグループの共有へのアクセスを許可または拒否できます。
前提条件
- ユーザーまたはグループベースのアクセスを設定する Samba 共有がある。
手順
たとえば、
Domain Users
グループの全メンバーが、ユーザー
アカウントのアクセスが拒否されている時に共有にアクセスできるようにするには、共有の設定に以下のパラメーターを追加します。valid users = +DOMAIN\"Domain Users" invalid users = DOMAIN\user
無効なユーザー
パラメーターの優先度は、有効なユーザー
パラメーターよりも高くなります。たとえば、ユーザー
アカウントがDomain Users
グループのメンバーである場合に上述の例を使用すると、このアカウントへのアクセスは拒否されます。Samba 設定を再読み込みします。
# smbcontrol all reload-config
関連情報
-
smb.conf(5)
man ページ
3.8.2. ホストベースの共有アクセスの設定
ホストベースのアクセス制御により、クライアントのホスト名、IP アドレス、または IP 範囲に基づいて、共有へのアクセスを許可または拒否できます。
以下の手順では、IP アドレスの 127.0.0.1
、IP 範囲の 192.0.2.0/24
、およびホストの client1.example.com
を有効にして共有にアクセスする方法と、client2.example.com
ホストへのアクセスを拒否する方法を説明します。
前提条件
- ホストベースのアクセスを設定する Samba 共有がある。
手順
以下のパラメーターを、
/etc/samba/smb.conf
ファイルの共有の設定に追加します。hosts allow = 127.0.0.1 192.0.2.0/24 client1.example.com hosts deny = client2.example.com
hosts deny
パラメーターは、hosts allow
よりも優先順位が高くなります。たとえば、client1.example.com
がhosts allow
パラメーターに一覧表示されている IP アドレスに解決すると、このホストへのアクセスは拒否されます。Samba 設定を再読み込みします。
# smbcontrol all reload-config
関連情報
-
smb.conf(5)
man ページ
3.9. Windows ACL で共有の設定
Samba は、共有およびファイルシステムオブジェクトへの Windows ACL の設定に対応します。これを使用すると、以下が可能になります。
- きめ細かな Windows ACL を使用する
- Windows を使用して共有権限およびファイルシステムの ACL を管理する
または、POSIX ACL を使用するように共有を設定することもできます。詳細は、POSIX ACL を使用する Samba ファイル共有の設定 を参照してください。
このセクションの一部は、Samba Wiki に公開されているドキュメント Setting up a Share Using Windows ACLs に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。
3.9.1. SeDiskPrivilege 特権の付与
Windows ACL を使用する共有に対する権限を設定できるのは、SeDiskOperatorPrivilege
特権が付与されているユーザーおよびグループのみです。
手順
たとえば、
SeDiskOperatorPrivilege
特権をDOMAIN\Domain Admins
グループに付与するには、以下のコマンドを実行します。#
net rpc rights grant "DOMAIN\Domain Admins" SeDiskOperatorPrivilege -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password: Successfully granted rights.注記ドメイン環境では、
SeDiskOperatorPrivilege
をドメイングループに付与します。これにより、ユーザーのグループメンバーシップを更新し、権限を集中的に管理できます。SeDiskOperatorPrivilege
が付与されているすべてのユーザーおよびグループを一覧表示するには、以下のコマンドを実行します。#
net rpc rights list privileges SeDiskOperatorPrivilege -U "DOMAIN\administrator"
Enter administrator's password: SeDiskOperatorPrivilege: BUILTIN\Administrators DOMAIN\Domain Admins
3.9.2. Windows ACL サポートの有効化
Windows ACL に対応する共有を設定するには、Samba でこの機能を有効にする必要があります。
前提条件
- ユーザー共有が Samba サーバーに設定されている。
手順
すべての共有に対してグローバルに有効にするには、次の設定を
/etc/samba/smb.conf
ファイルの[global]
セクションに追加します。vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes
または、共有のセクションに同じパラメーターを追加して、個別の共有に対して Windows ACL サポートを有効にできます。
smb
サービスを再起動します。#
systemctl restart smb
3.9.3. Windows ACL を使用する共有の追加
本セクションでは、/srv/samba/example/
ディレクトリーのコンテンツを共有する example
という名前の共有を作成し、Windows ACL を使用する方法を説明します。
手順
ディレクトリーが存在しない場合は作成します。以下に例を示します。
#
mkdir -p /srv/samba/example/
SELinux を、
enforcing
モードで実行する場合は、そのディレクトリーにsamba_share_t
コンテキストを設定します。#
semanage fcontext -a -t samba_share_t "/srv/samba/example(/.*)?"
#restorecon -Rv /srv/samba/example/
/etc/samba/smb.conf
ファイルにサンプル共有を追加します。たとえば、共有の write-enabled を追加するには、次のコマンドを実行します。[example] path = /srv/samba/example/ read only = no
注記ファイルシステムの ACL に関係なく、
read only = no
を設定しないと、Samba がディレクトリーを読み取り専用モードで共有します。すべての共有の
[global]
セクションで Windows ACL サポートを有効にしていない場合は、以下のパラメーターを[example]
セクションに追加して、この共有に対してこの機能を有効にします。vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes
/etc/samba/smb.conf
ファイルを検証します。#
testparm
firewall-cmd
ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。#
firewall-cmd --permanent --add-service=samba
#firewall-cmd --reload
smb
サービスを再起動します。#
systemctl restart smb
3.9.4. Windows ACL を使用する共有の共有権限とファイルシステム ACL の管理
Windows ACL を使用する Samba 共有で共有権限およびファイルシステムの ACL を管理するには、コンピューターの管理
などの Windows アプリケーションを使用します。詳細は、Windows のドキュメントを参照してください。または、smbcacls
ユーティリティーを使用して ACL を管理します。
Windows からファイルシステムの権限を変更するには、SeDiskOperatorPrivilege
権限が付与されたアカウントを使用する必要があります。
3.10. smbcacls で SMB 共有上の ACL の管理
smbcacls
ユーティリティーは、SMB 共有に保存されたファイルおよびディレクトリーの ACL を一覧表示、設定、および削除できます。smbcacls
を使用して、ファイルシステムの ACL を管理できます。
- 高度な Windows ACL または POSIX ACL を使用するローカルまたはリモートの Samba サーバー
- Red Hat Enterprise Linux で、Windows でホストされる共有の ACL をリモートで管理
3.10.1. アクセス制御エントリー
ファイルシステムオブジェクトの各 ACL エントリーには、以下の形式のアクセス制御エントリー (ACE) が含まれます。
security_principal:access_right/inheritance_information/permissions
例3.3 アクセス制御エントリー
AD\Domain Users
グループに、Windows 上の このフォルダー、サブフォルダー、およびファイル
に適用される 変更
権限がある場合、ACL には以下の ACE が含まれます。
AD\Domain Users:ALLOWED/OI|CI/CHANGE
ACE には、以下が含まれます。
- セキュリティープリンシパル
- セキュリティープリンシパルは、ACL の権限が適用されるユーザー、グループ、または SID です。
- アクセス権
-
オブジェクトへのアクセスが許可または拒否されるかどうかを定義します。値は
ALLOWED
またはDENIED
です。 - 継承情報
次の値を取ります。
表3.1 継承の設定
値 詳細 マップ先 OI
オブジェクトの継承
このフォルダーおよびファイル
CI
コンテナーの継承
このフォルダーおよびサブフォルダー
IO
継承のみ
ACE は、現在のファイルまたはディレクトリーには適用されません。
ID
継承済
親ディレクトリーから ACE が継承されました。
また、値は以下のように組み合わせることができます。
表3.2 継承設定の組み合わせ
値の組み合わせ Windows の 適用先
設定にマップします。OI|CI
このフォルダー、サブフォルダー、およびファイル
OI|CI|IO
サブフォルダーおよびファイルのみ
CI|IO
サブディレクトリーのみ
OI|IO
ファイルのみ
- 権限
この値は、Windows の権限または
smbcacls
エイリアスを表す 16 進値になります。1 つ以上の Windows の権限を表す 16 進値。
次の表に、Windows の高度な権限とそれに対応する値を 16 進法で表示します。
表3.3 Windows の権限とそれに対応する smbcacls 値を 16 進法で設定
Windows の権限 16 進値 完全な制御
0x001F01FF
フォルダーのスキャンおよびファイルの実行
0x00100020
フォルダーの一覧表示 / データの読み取り
0x00100001
属性の読み取り
0x00100080
拡張属性の読み取り
0x00100008
ファイルの作成/データの書き込み
0x00100002
フォルダーの作成/データの追加
0x00100004
属性の書き込み
0x00100100
拡張属性の書き込み
0x00100010
サブフォルダーおよびファイルの削除
0x00100040
削除
0x00110000
権限の読み取り
0x00120000
権限の変更
0x00140000
所有権の取得
0x00180000
ビット単位の
OR
演算を使用すると、複数の権限を 1 つの 16 進値として組み合わせることができます。詳細は、ACE マスク計算 を参照してください。smbcacls
エイリアス。以下の表には、利用可能なエイリアスが表示されます。表3.4 既存の smbcacls エイリアスとそれに対応する Windows の権限
smbcacls
エイリアスWindows の権限へのマッピング -R
読み取り
READ
読み取りおよび実行
W
主な機能:
- ファイルの作成/データの書き込み
- フォルダーの作成/データの追加
- 属性の書き込み
- 拡張属性の書き込み
- 権限の読み取り
D
削除
%P
権限の変更
O
所有権の取得
X
スキャン / 実行
CHANGE
修正
FULL
完全な制御
注記権限を設定する際に、1 文字のエイリアスを組み合わせることができます。たとえば、Windows の権限の
Read
およびDelete
を適用するようにRD
を設定できます。ただし、1 文字以外のエイリアスを複数組み合わせたり、エイリアスと 16 進値を組み合わせることはできません。
3.10.2. smbcacls を使用した ACL の表示
SMB 共有で ACL を表示するには、smbcacls
ユーティリティーを使用します。--add
などの操作パラメーターを付けずに smbcacls
を実行すると、ユーティリティーは、ファイルシステムオブジェクトの ACL を表示します。
手順
たとえば、//server/example
共有のルートディレクトリーの ACL を一覧表示するには、以下のコマンドを実行します。
# smbcacls //server/example / -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
REVISION:1
CONTROL:SR|PD|DI|DP
OWNER:AD\Administrators
GROUP:AD\Domain Users
ACL:AD\Administrator:ALLOWED/OI|CI/FULL
ACL:AD\Domain Users:ALLOWED/OI|CI/CHANGE
ACL:AD\Domain Guests:ALLOWED/OI|CI/0x00100021
コマンドの出力は以下のようになります。
-
REVISION
- セキュリティー記述子の内部 Windows NT ACL リビジョン -
CONTROL
- セキュリティー記述子の制御 -
OWNER
- セキュリティー記述子の所有者の名前または SID -
GROUP
- セキュリティー記述子のグループの名前または SID -
ACL
エントリー。詳細は、アクセス制御エントリー を参照してください。
3.10.3. ACE マスク計算
ほとんどの場合、ACE を追加または更新するときは、既存の smbcacls エイリアスとそれに対応する Windows アクセス許可に リストされている smbcacls
エイリアスを使用します。
ただし、Windows の権限と それに対応する smbcacls 値を 16 進法でリストしたように高度な Windows の権限 を設定する場合は、ビット単位の OR
操作を使用して正しい値を計算する必要があります。以下のシェルコマンドを使用して値を計算できます。
# echo $(printf '0x%X' $(( hex_value_1 | hex_value_2 | ... )))
例3.4 ACE マスクの計算
以下の権限を設定します。
- フォルダーのスキャン / ファイルの実行 (0x00100020)
- フォルダーの一覧表示 / データの読み取り (0x00100001)
- 属性の読み取り (0x00100080)
以前の権限の 16 進値を計算するには、以下を入力します。
# echo $(printf '0x%X' $(( 0x00100020 | 0x00100001 | 0x00100080 )))
0x1000A1
ACE を設定または更新する場合は、戻り値を使用します。
3.10.4. smbcacls を使用した ACL の追加、更新、および削除
smbcacls
ユーティリティーに渡すパラメーターに応じて、ファイルまたはディレクトリーから ACL を追加、更新、および削除できます。
ACL の追加
このフォルダー、サブフォルダー、およびファイル
の CHANGE
権限を AD\Domain Users
グループに付与する //server/example
共有のルートに ACL を追加するには、以下のコマンドを実行します。
# smbcacls //server/example / -U "DOMAIN\administrator --add ACL:"AD\Domain Users":ALLOWED/OI|CI/CHANGE
ACL の更新
ACL の更新は、新しい ACL の追加に似ています。ACL を更新する場合は、--modify
パラメーターと既存のセキュリティープリンシパルを使用して ACL を上書きします。smbcacls
が ACL 一覧内でセキュリティープリンシパルを検出すると、ユーティリティーは権限を更新します。これを行わないと、以下のエラーでコマンドが失敗します。
ACL for SID principal_name not found
たとえば、AD\Domain Users
グループの権限を更新し、このフォルダー、サブフォルダー、およびファイル
の READ
に設定するには、以下のコマンドを実行します。
# smbcacls //server/example / -U "DOMAIN\administrator --modify ACL:"AD\Domain Users":ALLOWED/OI|CI/READ
ACL の削除
ACL を削除するには、正確な ACL を持つ --delete
パラメーターを smbcacls
ユーティリティーに渡します。以下に例を示します。
# smbcacls //server/example / -U "DOMAIN\administrator --delete ACL:"AD\Domain Users":ALLOWED/OI|CI/READ
3.11. ユーザーが Samba サーバーのディレクトリーを共有できるようにする
Samba サーバーでは、root 権限なしでユーザーがディレクトリーを共有できるように設定できます。
3.11.1. ユーザーの共有機能の有効化
ユーザーがディレクトリーを共有できるようにするには、管理者が Samba でユーザー共有を有効にする必要があります。
たとえば、ローカルの example
グループのメンバーのみがユーザー共有を作成できるようにするには、以下を実行します。
手順
ローカルの
example
グループが存在しない場合は作成します。# groupadd example
ユーザー共有の定義を保存し、その権限を正しく設定するために、Samba 用のディレクトリーを準備します。以下に例を示します。
ディレクトリーを作成します。
# mkdir -p /var/lib/samba/usershares/
example
グループの書き込み権限を設定します。# chgrp example /var/lib/samba/usershares/ # chmod 1770 /var/lib/samba/usershares/
- このディレクトリーの他のユーザーが保存したファイルの名前変更や削除を禁止するように sticky ビットを設定します。
/etc/samba/smb.conf
ファイルを編集し、以下を[global]
セクションに追加します。ユーザー共有の定義を保存するように設定したディレクトリーのパスを設定します。以下に例を示します。
usershare path = /var/lib/samba/usershares/
このサーバーで Samba を作成できるユーザー共有の数を設定します。以下に例を示します。
usershare max shares = 100
usershare max shares
パラメーターにデフォルトの0
を使用すると、ユーザー共有が無効になります。必要に応じて、ディレクトリーの絶対パスの一覧を設定します。たとえば、Samba が
/data
ディレクトリーおよび/srv
ディレクトリーのサブディレクトリーの共有のみを許可するように設定するには、以下を設定します。usershare prefix allow list = /data /srv
設定可能なユーザー共有関連のパラメーターの一覧は、man ページの
smb.conf(5)
のUSERSHARES
セクションを参照してください。/etc/samba/smb.conf
ファイルを検証します。# testparm
Samba 設定を再読み込みします。
# smbcontrol all reload-config
これで、ユーザーが、ユーザー共有を作成できるようになりました。
3.11.2. ユーザー共有の追加
Samba でユーザー共有機能を有効にすると、ユーザーは net usershare add
コマンドを実行して、root
権限なしで Samba サーバーのディレクトリーを共有できます。
net usershare add
コマンドの構文:
net usershare add
share_name path [[ comment ] | [ ACLs ]] [ guest_ok=y|n ]
ユーザー共有の作成時に ACL を設定する場合は、ACL の前に comment パラメーターを指定する必要があります。空のコメントを設定するには、空の文字列を二重引用符で囲みます。
管理者が、/etc/samba/smb.conf
ファイルの [global]
セクションで usershare allow guests = yes
に設定すると、ユーザーはユーザー共有上でのみゲストアクセスを有効にできることに注意してください。
例3.5 ユーザー共有の追加
ユーザーが、Samba サーバーで /srv/samba/
ディレクトリーを共有する場合があります。共有には、example
という名前を付け、コメントを設定しないようにし、ゲストユーザーがアクセスできるようにします。また、共有権限は、AD\Domain Users
グループへのフルアクセスと、その他のユーザーへの読み取り権限を設定する必要があります。この共有を追加するには、そのユーザーで以下を実行します。
$ net usershare add example /srv/samba/ "" "AD\Domain Users":F,Everyone:R guest_ok=yes
3.11.3. ユーザー共有の設定の更新
ユーザー共有の設定を更新するには、同じ共有名と新しい設定で net usershare add
コマンドを使用して共有を上書きします。ユーザー共有の追加 を参照します。
3.11.4. 既存のユーザー共有に関する情報の表示
ユーザーは、Samba サーバーで net usershare info
コマンドを実行して、ユーザーの共有および設定を表示できます。
前提条件
- ユーザー共有が Samba サーバーに設定されている。
手順
任意のユーザーが作成したすべてのユーザー共有を表示するには、以下のコマンドを実行します。
$ net usershare info -l [share_1] path=/srv/samba/ comment= usershare_acl=Everyone:R,host_name\user:F, guest_ok=y ...
コマンドを実行するユーザーが作成した共有のみを一覧表示するには、
-l
パラメーターを省略します。特定の共有に関する情報のみを表示するには、共有名またはワイルドカードをコマンドに渡します。たとえば、名前が
share_
で始まる共有の情報を表示する場合は、以下のコマンドを実行します。$ net usershare info -l share_*
3.11.5. ユーザー共有の一覧表示
Samba サーバーで設定を行わずに利用可能なユーザー共有のみを一覧表示するには、net usershare list
コマンドを使用します。
前提条件
- ユーザー共有が Samba サーバーに設定されている。
手順
任意のユーザーが作成した共有を一覧表示するには、以下のコマンドを実行します。
$ net usershare list -l share_1 share_2 ...
コマンドを実行するユーザーが作成した共有のみを一覧表示するには、
-l
パラメーターを省略します。特定の共有のみを一覧表示するには、共有名またはワイルドカードをコマンドに渡します。たとえば、名前が
share_
で始まる共有のみを一覧表示するには、以下のコマンドを実行します。$ net usershare list -l share_*
3.11.6. ユーザー共有の削除
ユーザー共有を削除するには、共有を作成したユーザーまたは root
ユーザーで、net usershare delete
コマンドを実行します。
前提条件
- ユーザー共有が Samba サーバーに設定されている。
手順
$ net usershare delete share_name
3.12. 認証なしでアクセスを許可する共有の設定
特定の状況では、認証なしでユーザーが接続できるディレクトリーを共有します。これを設定するには、共有でゲストアクセスを有効にします。
共有に認証を使用しないと、セキュリティーリスクとなる場合があります。
3.12.1. 共有へのゲストアクセスの有効化
共有でゲストアクセスが有効になっている場合、Samba はゲスト接続を、guest account
パラメーターで設定したオペレーティングシステムアカウントにマッピングします。少なくとも以下のいずれかの条件が満たされると、ゲストユーザーはこの共有のファイルにアクセスできます。
- アカウントがファイルシステムの ACL に一覧表示されます。
-
その他
のユーザーの POSIX 権限はこれを許可します。
例3.6 ゲスト共有の権限
ゲストアカウントを nobody
(デフォルト) にマッピングするように Samba を設定している場合は、下記の例の ACL が、以下を行うようになります。
-
ゲストユーザーが
file1.txt
の読み込みを許可する -
ゲストユーザーによる
file2.txt
の読み込みおよび修正を許可する -
ゲストユーザーが
file3.txt
を読み込んだり修正しないようにする
-rw-r--r--. 1 root root 1024 1. Sep 10:00 file1.txt -rw-r-----. 1 nobody root 1024 1. Sep 10:00 file2.txt -rw-r-----. 1 root root 1024 1. Sep 10:00 file3.txt
手順
/etc/samba/smb.conf
ファイルを編集します。これが、このサーバーで設定した最初のゲスト共有である場合は、以下を行います。
[global]
セクションにmap to guest = Bad User
を設定し ます。[global] ... map to guest = Bad User
この設定により、ユーザー名が存在しない限り、Samba は間違ったパスワードを使用したログイン試行を拒否します。指定したユーザー名がなく、ゲストアクセスが共有で有効になっている場合、Samba は接続をゲストのログインとして処理します。
デフォルトでは、Samba は、Red Hat Enterprise Linux の
nobody
アカウントにゲストアカウントをマッピングします。または、別のアカウントを設定することもできます。以下に例を示します。[global] ... guest account = user_name
このパラメーターに設定するアカウントは、Samba サーバーにローカルに存在する必要があります。セキュリティー上の理由から、Red Hat は有効なシェルを割り当てていないアカウントを使用することを推奨しています。
guest ok = yes
の設定を、[example]
共有セクションに追加します。[example] ... guest ok = yes
/etc/samba/smb.conf
ファイルを検証します。# testparm
Samba 設定を再読み込みします。
# smbcontrol all reload-config
3.13. MacOS クライアント向けの Samba の設定
fruit
仮想ファイルシステム (VFS) の Samba モジュールは、Apple サーバーメッセージブロック (SMB) クライアントとの互換性を強化します。
3.13.1. MacOS クライアントにファイル共有を提供する Samba 設定の最適化
本セクションでは、サーバーでホストされるすべての Samba 共有に fruit
モジュールを設定し、MacOS クライアントの Samba ファイル共有を最適化する方法を説明します。
Red Hat は、fruit
モジュールをグローバルに有効にすることを推奨します。MacOS を使用するクライアントは、クライアントがサーバーへの最初の接続を確立する時に、サーバーメッセージブロックバージョン 2 (SMB2) Apple (AAPL) プロトコル拡張をネゴシエートします。クライアントが最初に AAPL 拡張機能を有効にせずに共有に接続すると、クライアントはサーバーの共有に拡張機能を使用しません。
前提条件
- Samba が、ファイルサーバーとして設定されている。
手順
/etc/samba/smb.conf
ファイルを編集し、[global]
セクションの VFS モジュールfruit
およびstreams_xattr
を有効にします。vfs objects = fruit streams_xattr
重要streams_xattr
を有効にする前に、fruit
モジュールを有効にする必要があります。fruit
モジュールは、別のデータストリーム (ADS) を使用します。このため、streams_xattr
モジュールも有効にする必要があります。必要に応じて、共有で macOS Time Machine のサポートを提供する場合は、
/etc/samba/smb.conf
ファイルの共有設定に次の設定を追加します。fruit:time machine = yes
/etc/samba/smb.conf
ファイルを検証します。# testparm
Samba 設定を再読み込みします。
# smbcontrol all reload-config
関連情報
-
vfs_fruit(8)
の man ページ ファイル共有の設定
3.14. smbclient ユーティリティーを使用した SMB 共有へのアクセス
smbclient ユーティリティーを使用すると、コマンドラインの FTP クライアントと同様に、SMB サーバーのファイル共有にアクセスできます。たとえば、ファイルを共有にアップロードしたり、共有からダウンロードしたりできます。
前提条件
-
samba-client
パッケージがインストールされている。
3.14.1. smbclient 対話モードの動作
たとえば、DOMAIN\user
アカウントを使用して サーバー
でホストされる example
共有に認証するには、以下のコマンドを実行します。
# smbclient -U "DOMAIN\user" //server/example Enter domain\user's password: Try "help" to get a list of possible commands. smb: \>
smbclient
が共有に正常に接続すると、ユーティリティーはインタラクティブモードになり、以下のプロンプトが表示されます。
smb: \>
対話式シェルで利用可能なすべてのコマンドを表示するには、以下のコマンドを実行します。
smb: \> help
特定のコマンドのヘルプを表示するには、以下のコマンドを実行します。
smb: \> help command_name
関連情報
-
smbclient(1)
man ページ
3.14.2. 対話モードでの smbclient の使用
-c
パラメーターを指定せずに smbclient
を使用すると、ユーティリティーは対話モードを開始します。以下の手順では、SMB 共有に接続し、サブディレクトリーからファイルをダウンロードする方法を説明します。
手順
共有に接続します。
# smbclient -U "DOMAIN\user_name" //server_name/share_name
/example/
ディレクトリーに移動します。smb: \>
d /example/
ディレクトリー内のファイルを一覧表示します。
smb: \example\>
ls
. D 0 Thu Nov 1 10:00:00 2018 .. D 0 Thu Nov 1 10:00:00 2018 example.txt N 1048576 Thu Nov 1 10:00:00 2018 9950208 blocks of size 1024. 8247144 blocks availableexample.txt
ファイルをダウンロードします。smb: \example\>
get example.txt
getting file \directory\subdirectory\example.txt of size 1048576 as example.txt (511975,0 KiloBytes/sec) (average 170666,7 KiloBytes/sec)共有から切断します。
smb: \example\>
exit
3.14.3. スクリプトモードでの smbclient の使用
-c
パラメーターを smbclient
に渡すと、リモートの SMB 共有でコマンドを自動的に実行できます。これにより、スクリプトで smbclient
を使用できます。
以下の手順では、SMB 共有に接続し、サブディレクトリーからファイルをダウンロードする方法を説明します。
手順
-
以下のコマンドで共有に接続して
example
ディレクトリーに移動し、example.txt
ファイルをダウンロードします。
# smbclient -U DOMAIN\user_name //server_name/share_name -c "cd /example/ ; get example.txt ; exit"
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 でのプリントサーバーのサポートの有効化
デフォルトでは、プリントサーバーサポートは Samba で有効になっていません。Samba をプリントサーバーとして使用するには、Samba を適切に設定する必要があります。
印刷ジョブとプリンター操作には、リモートプロシージャコール (RPC) が必要です。デフォルトでは、Samba は RPC を管理するためにオンデマンドで rpcd_spoolss
サービスを開始します。最初の RPC 呼び出し中、または CUPS でプリンターリストを更新するときに、Samba は CUPS からプリンター情報を取得します。これには、プリンターごとに約 1 秒かかる場合があります。そのため、プリンターが 50 台を超える場合は、rpcd_spoolss
設定を調整してください。
前提条件
プリンターが CUPS サーバーで設定されている。
CUPS でプリンターを設定する方法は、プリントサーバーの CUPS Web コンソール (https://print_server_host_name:631/help) で提供されているドキュメントを参照してください。
手順
/etc/samba/smb.conf
ファイルを編集します。[printers]
セクションを追加して、Samba で印刷バックエンドを有効にします。[printers] comment = All Printers path = /var/tmp/ printable = yes create mask = 0600
重要[printers]
共有名はハードコーディングされており、変更はできません。CUPS サーバーが別のホストまたはポートで実行されている場合は、
printers
セクションで設定を指定します。cups server = printserver.example.com:631
多数のプリンターがある場合は、待機秒数を CUPS に接続されているプリンターの数よりも大きい値に設定します。たとえば、100 台のプリンターがある場合は、
[global]
セクションに次のように設定します。rpcd_spoolss:idle_seconds = 200
この設定が環境内でスケーリングされない場合は、
[global]
セクションでrpcd_spoolss
ワーカーの数も増やします。rpcd_spoolss:num_workers = 10
デフォルトでは、
rpcd_spoolss
は 5 つのワーカーを開始します。
/etc/samba/smb.conf
ファイルを検証します。# testparm
firewall-cmd
ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。# firewall-cmd --permanent --add-service=samba # firewall-cmd --reload
smb
サービスを再起動します。# systemctl restart smb
サービスを再起動すると、Samba は CUPS バックエンドに設定したすべてのプリンターを自動的に共有します。特定のプリンターのみを手動で共有する場合は、特定のプリンターの手動共有 を参照してください。
検証
印刷ジョブを送信します。たとえば、PDF ファイルを印刷するには、次のように入力します。
# smbclient -Uuser //sambaserver.example.com/printer_name -c "print example.pdf"
3.15.2. 特定のプリンターの手動共有
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. Samba プリントサーバーでの 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.3. print$ 共有の設定
Windows のオペレーティングシステムは、プリントサーバーの共有 print$
から、プリンタードライバーをダウンロードします。この共有名は Windows でハードコーディングされており、変更はできません。
以下の手順は、/var/lib/samba/drivers/
ディレクトリーを print$
として共有し、ローカルの printadmin
グループのメンバーがプリンタードライバーをアップロードすることを有効にする方法を説明します。
手順
[print$]
セクションを/etc/samba/smb.conf
ファイルに追加します。[print$] path = /var/lib/samba/drivers/ read only = no write list = @printadmin force group = @printadmin create mask = 0664 directory mask = 2775
以下の設定を使用します。
-
printadmin
グループのメンバーだけがプリンタードライバーを共有にアップロードできます。 -
新規に作成されたファイルおよびディレクトリーのグループは
printadmin
に設定されます。 -
新規ファイルの権限は
664
に設定されます。 -
新しいディレクトリーの権限は、
2775
に設定されます。
-
全プリンター向けに 64 ビットドライバーのみをアップロードするには、
/etc/samba/smb.conf
ファイルの[global]
セクションに以下の設定を含めます。spoolss: architecture = Windows x64
この設定がないと、少なくとも 32 ビットバージョンでアップロードしたドライバーのみが表示されます。
/etc/samba/smb.conf
ファイルを検証します。# testparm
Samba 設定を再読み込みします。
# smbcontrol all reload-config
printadmin
グループが存在しない場合は作成します。# groupadd printadmin
SePrintOperatorPrivilege
権限を、printadmin
グループに付与します。# net rpc rights grant "printadmin" SePrintOperatorPrivilege -U "DOMAIN\administrator" Enter DOMAIN\administrator's password: Successfully granted rights.
SELinux を、
enforcing
モードで実行する場合は、そのディレクトリーにsamba_share_t
コンテキストを設定します。# semanage fcontext -a -t samba_share_t "/var/lib/samba/drivers(/.)?" # *restorecon -Rv /var/lib/samba/drivers/
/var/lib/samba/drivers/
ディレクトリーに権限を設定します。POSIX ACL を使用する場合は、以下を設定します。
# chgrp -R "printadmin" /var/lib/samba/drivers/ # chmod -R 2775 /var/lib/samba/drivers/
Windows ACL を使用する場合は、以下を設定します。
プリンシパル アクセス 適用先 CREATOR OWNER
完全な制御
サブフォルダーおよびファイルのみ
認証されたユーザー
読み取りおよび実行、フォルダーのコンテンツの一覧表示、読み取り
このフォルダー、サブフォルダー、およびファイル
printadmin
完全な制御
このフォルダー、サブフォルダー、およびファイル
Windows での ACL の設定に関する詳細は、Windows のドキュメントを参照してください。
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
を開きます。 Computer Configuration → Policies → Administrative Templates → Printers の順にクリックします。
ウィンドウの右側で、
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. FIPS モードが有効なサーバーでの Samba の実行
本セクションでは、FIPS モードが有効な状態で Samba を実行する制限の概要を説明します。また、Samba を実行している Red Hat Enterprise Linux ホストで FIPS モードを有効にする手順も提供します。
3.17.1. FIPS モードでの Samba の使用制限
以下の Samba モードと機能は、指定された条件下で FIPS モードで動作します。
- Samba は、AES 暗号化を使用する Kerberos 認証を使用する Active Directory (AD) または Red Hat Identity Management (IdM) 環境でのみ、ドメインメンバーとして使用できます。
- Active Directory ドメインメンバーのファイルサーバーとして Samba を使用する。ただし、クライアントは Kerberos を使用してサーバーに対して認証する必要があります。
FIPS のセキュリティーが強化されているため、FIPS モードが有効な場合は、以下の Samba 機能およびモードは機能しません。
- RC4 暗号がブロックされていることによる NT LAN Manager (NTLM) 認証
- サーバーメッセージブロックバージョン 1 (SMB1) プロトコル
- NTLM 認証を使用することによるスタンドアロンファイルサーバーモード
- NT4- スタイルのドメインコントローラー
- NT4- スタイルのドメインメンバーRed Hat は、IdM がバックグラウンドで使用するプライマリードメインコントローラー (PDC) 機能のサポートを継続することに留意してください。
- Samba サーバーに対するパスワード変更Active Directory ドメインコントローラーに対して Kerberos を使用してパスワードの変更のみを実行できます。
以下の機能は FIPS モードでテストされていないため、Red Hat ではサポートされていません。
- プリントサーバーとしての Samba の実行
3.17.2. FIPS モードでの Samba の使用
本セクションでは、Samba を実行する RHEL ホストで FIPS モードを有効にする方法を説明します。
前提条件
- Samba が Red Hat Enterprise Linux ホストに設定されている。
- Samba は、FIPS モードでサポートされるモードで実行する。
手順
RHEL で FIPS モードを有効にします。
# fips-mode-setup --enable
サーバーを再起動します。
# reboot
testparm
ユーティリティーを使用して、設定を確認します。# testparm -s
コマンドがエラーや非互換性を表示する場合は、Samba が正常に機能するように修正してください。
3.18. Samba サーバーのパフォーマンスチューニング
本章では、特定の状況で Samba のパフォーマンスを改善できる設定と、パフォーマンスが低下する可能性のある設定を説明します。
このセクションの一部は、Samba Wiki に公開されているドキュメント Performance Tuning に掲載されています。ライセンスは、CC BY 4.0 にあります。著者および貢献者は、Wiki ページの history タブを参照してください。
前提条件
- Samba が、ファイルサーバーまたはプリントサーバーとして設定されている。
3.18.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.18.2. 大量のファイルを含むディレクトリーとの共有の調整
Linux は、大文字と小文字を区別するファイル名に対応しています。このため、Samba はファイルの検索時またはアクセス時に、大文字と小文字のファイル名のディレクトリーをスキャンする必要があります。小文字または大文字のいずれかでのみ新しいファイルを作成するように共有を設定すると、パフォーマンスが向上します。
前提条件
- Samba が、ファイルサーバーとして設定されている。
手順
共有の全ファイルの名前を小文字に変更します。
注記この手順の設定を使用すると、小文字以外の名前が付けられたファイルは表示されなくなります。
共有のセクションに、以下のパラメーターを設定します。
case sensitive = true default case = lower preserve case = no short preserve case = no
パラメーターの詳細は、man ページの
smb.conf(5)
を参照してください。/etc/samba/smb.conf
ファイルを検証します。# testparm
Samba 設定を再読み込みします。
# smbcontrol all reload-config
この設定が適用されと、この共有に新たに作成されるすべてのファイルの名前が小文字になります。この設定により、Samba はディレクトリーを大文字と小文字で分けたスキャンが不要になり、パフォーマンスが向上します。
3.18.3. パフォーマンスが低下する可能性のある設定
デフォルトでは、Red Hat Enterprise Linux のカーネルは、ネットワークパフォーマンスが高くなるように調整されています。たとえば、カーネルはバッファーサイズに自動チューニングメカニズムを使用しています。/etc/samba/smb.conf
ファイルに socket options
パラメーターを設定すると、このカーネル設定が上書きされます。その結果、このパラメーターの設定により、ほとんどの場合は、Samba ネットワークのパフォーマンスが低下します。
カーネルの最適化された設定を使用するには、/etc/samba/smb.conf
の [global]
セクションから socket options
パラメーターを削除します。
3.19. Samba がデフォルトの SMB バージョンよりも前のバージョンのクライアントと互換対応するような設定
Samba は、サポート対象の最小サーバーメッセージブロック (SMB) バージョンに妥当で安全なデフォルト値を使用します。ただし、以前の SMB バージョンを必要とするクライアントがある場合は、Samba を設定してサポートできます。
3.19.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
関連情報
-
smb.conf(5)
man ページ
3.20. 頻繁に使用される Samba コマンドラインユーティリティー
本章では、Samba サーバーで作業する場合によく使用されるコマンドを説明します。
3.20.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.20.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.20.3. net rpc share コマンドの使用
net rpc share
コマンドは、ローカルまたはリモートの Samba または Windows サーバーの共有の一覧表示、追加、および削除を行う機能を提供します。
共有の一覧表示
SMB サーバーの共有を一覧表示するには、net rpc share list
コマンドを使用します。必要に応じて、-S server_name
パラメーターをコマンドに渡して、リモートサーバーの共有を一覧表示します。以下に例を示します。
# net rpc share list -U "DOMAIN\administrator" -S server_name Enter DOMAIN\administrator's password: IPC$ share_1 share_2 ...
/etc/samba/smb.conf
ファイルのセクション内に browseable = no
が設定されている Samba サーバーでホストされている共有は、出力には表示されません。
共有の追加
net rpc share add
コマンドを使用すると、SMB サーバーに共有を追加できます。
たとえば、C:\example\
ディレクトリーを共有するリモートの Windows サーバーに、共有 example
を追加するには、以下のコマンドを実行します。
# net rpc share add example="C:\example" -U "DOMAIN\administrator" -S server_name
Windows のディレクトリー名を指定する際は、パスの末尾のバックスラッシュを省略する必要があります。
このコマンドを使用して Samba サーバーに共有を追加するには、以下を行います。
-
-U
パラメーターで指定したユーザーは、出力先サーバーでSeDiskOperatorPrivilege
特権が付与されている必要があります。 -
共有セクションを、
/etc/samba/smb.conf
ファイルに追加し、Samba を再読み込みするスクリプトを記述する必要があります。スクリプトは、/etc/samba/smb.conf
の[global]
セクションのadd share command
パラメーターで設定する必要があります。詳細は、man ページのsmb.conf(5)
のadd share コマンド
の説明を参照してください。
共有の削除
net rpc share delete
コマンドを使用すると、SMB サーバーから共有を削除できます。
たとえば、example という名前の共有を、リモートの Windows サーバーから削除するには、以下のコマンドを実行します。
# net rpc share delete example -U "DOMAIN\administrator" -S server_name
このコマンドを使用して Samba サーバーから共有を削除するには、以下のコマンドを実行します。
-
-U
パラメーターで指定したユーザーは、SeDiskOperatorPrivilege
特権が付与されている必要があります。 -
/etc/samba/smb.conf
ファイルから共有のセクションを削除し、Samba を再読み込みするスクリプトを記述する必要があります。スクリプトは、/etc/samba/smb.conf
の[global]
セクションのdelete share command
パラメーターで設定する必要があります。詳細は、man ページのsmb.conf(5)
のdelete share コマンド
の説明を参照してください。
3.20.4. net user コマンドの使用
net user
コマンドを使用すると、AD DC または NT4 PDC で以下の操作を実行できます。
- すべてのユーザーアカウントの一覧を表示
- ユーザーの追加
- ユーザーの削除
AD ドメイン用の ads
、NT4 ドメイン用の rpc
などの接続方法の指定は、ドメインユーザーアカウントを一覧表示する場合にのみ必要です。その他のユーザー関連のサブコマンドは、接続メソッドを自動検出できます。
-U user_name
パラメーターをコマンドに渡して、要求されたアクションを実行できるユーザーを指定します。
ドメインユーザーアカウントの一覧表示
AD ドメイン内のユーザーを一覧表示するには、以下を実行します。
# net ads user -U "DOMAIN\administrator"
NT4 ドメインのユーザーを一覧表示するには、以下を実行します。
# net rpc user -U "DOMAIN\administrator"
ユーザーアカウントのドメインへの追加
Samba ドメインメンバーの場合は、net user add
コマンドを使用して、ユーザーアカウントをドメインに追加できます。
たとえば、user
アカウントをドメインに追加します。
以下のアカウントを追加します。
# net user add user password -U "DOMAIN\administrator" User user added
必要に応じて、リモートプロシージャコール (RPC) シェルを使用して、AD DC または NT4 PDC でアカウントを有効にします。以下に例を示します。
# net rpc shell -U DOMAIN\administrator -S DC_or_PDC_name Talking to domain DOMAIN (S-1-5-21-1424831554-512457234-5642315751) net rpc>
user edit disabled user: no
Set user's disabled flag from [yes] to [no] net rpc>exit
ドメインからのユーザーアカウントの削除
Samba ドメインメンバーの場合は、net user delete
コマンドを使用して、ドメインからユーザーアカウントを削除できます。
たとえば、ドメインから user
アカウントを削除するには、以下のコマンドを実行します。
# net user delete user -U "DOMAIN\administrator" User user deleted
3.20.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 に対してコマンドを実行すると、ドメインユーザーの一覧が表示されます。
関連情報
-
rpcclient(1)
man ページ
3.20.6. samba-regedit アプリケーションの使用
プリンター設定などの特定の設定は、Samba サーバーのレジストリーに保存されます。ncurses ベースの samba-regedit
アプリケーションを使用して、Samba サーバーのレジストリーを編集できます。
前提条件
-
samba-client
パッケージがインストールされている。
手順
アプリケーションを起動するには、次のコマンドを入力します。
# samba-regedit
次のキーを使用します。
- カーソルを上下に動かして、レジストリーツリーと値の間を移動します。
- Enter - キーを開くか、値を編集します。
-
Tab -
Key
ペインとValue
ペインを切り替えます。 - Ctrl+C - アプリケーションを閉じます。
3.20.7. smbcontrol ユーティリティーの使用
smbcontrol
ユーティリティーを使用すると、smbd
、nmbd
、winbindd
、またはこのすべてのサービスにコマンドメッセージを送信できます。この制御メッセージは、設定の再読み込みなどのサービスを指示します。
本セクションの手順では、reload-config
メッセージタイプを すべて
の宛先に送信することで、smbd
、nmbd
、winbindd
のサービスの設定を再読み込みする方法を示します。
前提条件
-
samba-common-tools
パッケージがインストールされている。
手順
# smbcontrol all reload-config
関連情報
-
smbcontrol(1)
man ページ
3.20.8. smbpasswd ユーティリティーの使用
smbpasswd
ユーティリティーは、ローカルの Samba データベースでユーザーアカウントおよびパスワードを管理します。
前提条件
-
samba-common-tools
パッケージがインストールされている。
手順
ユーザーとしてコマンドを実行すると、
smbpasswd
はコマンドを実行するユーザーの Samba パスワードを変更します。以下に例を示します。[user@server ~]$ smbpasswd New SMB password: password Retype new SMB password: password
root
でsmbpasswd
を実行すると、たとえば以下のようにユーティリティーを使用できます。新しいユーザーを作成します。
[root@server ~]# smbpasswd -a user_name New SMB password:
password
Retype new SMB password:password
Added user user_name.注記Samba データベースにユーザーを追加する前に、ローカルのオペレーティングシステムにアカウントを作成する必要があります。基本的なシステム設定の設定の コマンドラインでの新規ユーザーの追加 セクションを参照してください。
Samba ユーザーを有効にします。
[root@server ~]# smbpasswd -e user_name Enabled user user_name.
Samba ユーザーを無効にします。
[root@server ~]# smbpasswd -x user_name Disabled user user_name
ユーザーを削除します。
[root@server ~]# smbpasswd -x user_name Deleted user user_name.
関連情報
-
smbpasswd(8)
man ページ
3.20.9. smbstatus ユーティリティーの使用
smbstatus
ユーティリティーは以下について報告します。
-
各
smbd
デーモンの PID ごとの接続を Samba サーバーに接続します。このレポートには、ユーザー名、プライマリーグループ、SMB プロトコルのバージョン、暗号、および署名の情報が含まれます。 -
Samba 共有ごとの接続このレポートには、
smbd
デーモンの PID、接続しているマシンの IP、接続が確立された時点のタイムスタンプ、暗号、および署名情報が含まれます。 - ロックされたファイルの一覧。レポートエントリーには、日和見ロック (oplock) タイプなどの詳細が含まれます。
前提条件
-
samba
パッケージがインストールされている。 -
smbd
サービスが実行している。
手順
# smbstatus Samba version 4.15.2 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
関連情報
-
smbstatus(1)
man ページ
3.20.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
関連情報
-
smbtar(1)
の man ページ
3.20.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
関連情報
-
wbinfo(1)
man ページ
3.21. 関連情報
-
smb.conf(5)
man ページ -
/usr/share/docs/samba-version/
ディレクトリーには、Samba プロジェクトが提供する一般的なドキュメント、サンプルスクリプト、および LDAP スキーマファイルが含まれています。 - Setting up Samba and the Clustered Trivial Database (CDTB) to share directories stored on an GlusterFS volume
- Red Hat Enterprise Linux での SMB 共有のマウント
第4章 BIND DNS サーバーのセットアップおよび設定
BIND は、Internet Engineering Task Force (IETF) の DNS 標準およびドラフト標準に完全に準拠した機能豊富な DNS サーバーです。たとえば、管理者は BIND を次のように頻繁に使用します。
- ローカルネットワークでの DNS サーバーのキャッシング
- ゾーンの権威 DNS サーバー
- ゾーンに高可用性を提供するセカンダリーサーバー
4.1. SELinux を使用した BIND の保護または change-root 環境での BIND の実行に関する考慮事項
BIND インストールを保護するには、次のことができます。
change-root 環境なしで
named
サービスを実行します。この場合、enforcing
モードの SELinux は、既知の BIND セキュリティー脆弱性の悪用を防ぎます。デフォルトでは、Red Hat Enterprise Linux は SELinux をenforcing
モードで使用します。重要RHEL で SELinux を
enforcing
モードで使用して BIND を実行すると、change-root 環境で BIND を実行するよりも安全です。name-chroot
サービスを change-root 環境で実行します。管理者は、change-root 機能を使用して、プロセスとそのサブプロセスのルートディレクトリーが
/
ディレクトリーとは異なるものであることを定義できます。named-chroot
サービスを開始すると、BIND はそのルートディレクトリーを/var/named/chroot/
に切り替えます。その結果、サービスはmount --bind
コマンドを使用して、/etc/named-chroot.files
にリストされているファイルおよびディレクトリーを/var/named/chroot/
で使用できるようにし、プロセスは/var/named/chroot/
以外のファイルにアクセスできません。
BIND を使用する場合:
-
通常モードでは、
named
サービスを使用します。 -
change-root 環境では、
named-chroot
サービスを使用します。これには、named-chroot
パッケージを追加でインストールする必要があります。
関連情報
-
named(8)
man ページのRed Hat SELinux BIND security profile
セクション
4.2. BIND 管理者リファレンスマニュアル
bind
パッケージに含まれる総合的な BIND Administrator Reference Manual
には、次の内容が記載されています。
- 設定例
- 高度な機能に関するドキュメント
- 設定リファレンス
- セキュリティーに関する考慮事項
bind
パッケージがインストールされているホストで BIND Administrator Reference Manual
を表示するには、ブラウザーで /usr/share/doc/bind/Bv9ARM.html
ファイルを開きます。
4.3. BIND をキャッシュ DNS サーバーとして設定する
デフォルトでは、BIND DNS サーバーは、成功したルックアップと失敗したルックアップを解決してキャッシュします。その後、サービスはキャッシュから同じレコードへの要求に応答します。これにより、DNS ルックアップの速度が大幅に向上します。
前提条件
- サーバーの IP アドレスは静的です。
手順
bind
パッケージおよびbind-utils
パッケージをインストールします。# yum install bind bind-utils
これらのパッケージは BIND 9.11 を提供します。BIND 9.16 が必要な場合は、
bind9.16
およびbind9.16-utils
パッケージをインストールしてください。BIND を change-root 環境で実行する場合は、
bind-chroot
パッケージをインストールします。# yum install bind-chroot
デフォルトである
enforcing
モードで SELinux を使用するホストで BIND を実行すると、より安全になることに注意してください。/etc/named.conf
ファイルを編集し、options
ステートメントに次の変更を加えます。listen-on
およびlisten-on-v6
ステートメントを更新して、BIND がリッスンする IPv4 インターフェイスおよび IPv6 インターフェイスを指定します。listen-on port 53 { 127.0.0.1; 192.0.2.1; }; listen-on-v6 port 53 { ::1; 2001:db8:1::1; };
allow-query
ステートメントを更新して、クライアントがこの DNS サーバーにクエリーを実行できる IP アドレスおよび範囲を設定します。allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
allow-recursion
ステートメントを追加して、BIND が再帰クエリーを受け入れる IP アドレスおよび範囲を定義します。allow-recursion { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
警告サーバーのパブリック IP アドレスで再帰を許可しないでください。そうしないと、サーバーが大規模な DNS 増幅攻撃の一部になる可能性があります。
デフォルトでは、BIND は、ルートサーバーから権限のある DNS サーバーに再帰的にクエリーを実行することにより、クエリーを解決します。または、プロバイダーのサーバーなど、他の DNS サーバーにクエリーを転送するように BIND を設定することもできます。この場合、BIND がクエリーを転送する DNS サーバーの IP アドレスのリストを含む
forwarders
ステートメントを追加します。forwarders { 198.51.100.1; 203.0.113.5; };
フォールバック動作として、フォワーダーサーバーが応答しないと、BIND はクエリーを再帰的に解決します。この動作を無効にするには、
forward only;
ステートメントを追加します。
/etc/named.conf
ファイルの構文を確認します。# named-checkconf
コマンドが出力を表示しない場合は、構文に間違いがありません。
着信 DNS トラフィックを許可するように
firewalld
ルールを更新します。# firewall-cmd --permanent --add-service=dns # firewall-cmd --reload
BIND を開始して有効にします。
# systemctl enable --now named
change-root 環境で BIND を実行する場合は、
systemctl enable --now named-chroot
コマンドを使用して、サービスを有効にして開始します。
検証
新しく設定した DNS サーバーを使用してドメインを解決します。
# dig @localhost www.example.org ... www.example.org. 86400 IN A 198.51.100.34 ;; Query time: 917 msec ...
この例では、BIND が同じホストで実行し、
localhost
インターフェイスでクエリーに応答することを前提としています。初めてレコードをクエリーした後、BIND はエントリーをそのキャッシュに追加します。
前のクエリーを繰り返します。
# dig @localhost www.example.org ... www.example.org. 85332 IN A 198.51.100.34 ;; Query time: 1 msec ...
エントリーがキャッシュされるため、エントリーの有効期限が切れるまで、同じレコードに対するそれ以降のリクエストは大幅に高速化されます。
次のステップ
- この DNS サーバーを使用するようにネットワーク内のクライアントを設定します。DHCP サーバーが DNS サーバー設定をクライアントに提供する場合は、それに応じて DHCP サーバーの設定を更新します。
関連情報
- SELinux を使用した BIND の保護または change-root 環境での BIND の実行に関する考慮事項
-
named.conf(5)
man ページ -
/usr/share/doc/bind/sample/etc/named.conf
- BIND 管理者リファレンスマニュアル
4.4. BIND DNS サーバーでのログの設定
bind
パッケージによって提供されるデフォルトの /etc/named.conf
ファイル内の設定は、default_debug
チャネルを使用し、メッセージのログを /var/named/data/named.run
ファイルに記録します。default_debug
チャネルは、サーバーのデバッグレベルがゼロ以外の場合にのみエントリーをログに記録します。
さまざまなチャネルおよびカテゴリーを使用して、BIND を設定して、定義された重大度でさまざまなイベントを個別のファイルに書き込むことができます。
前提条件
- BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
-
named
またはnamed-chroot
サービスが実行しています。
手順
/etc/named.conf
ファイルを編集し、category
およびchannel
フレーズをlogging
ステートメントに追加します。次に例を示します。logging { ... category notify { zone_transfer_log; }; category xfer-in { zone_transfer_log; }; category xfer-out { zone_transfer_log; }; channel zone_transfer_log { file "/var/named/log/transfer.log" versions 10 size 50m; print-time yes; print-category yes; print-severity yes; severity info; }; ... };
この設定例では、BIND はゾーン転送に関連するメッセージのログを
/var/named/log/transfer.log
に記録します。BIND は最大10
バージョンのログファイルを作成し、最大サイズが50
MB に達するとローテーションします。category
句は、BIND がカテゴリーのメッセージを送信するチャネルを定義します。channel
句は、バージョン数、最大ファイルサイズ、および BIND がチャネルにログ記録する必要がある重大度レベルを含むログメッセージの宛先を定義します。イベントのタイムスタンプ、カテゴリー、および重大度のログ記録を有効にするなどの追加設定はオプションですが、デバッグ目的で役立ちます。ログディレクトリーが存在しない場合は作成し、このディレクトリーの
named
ユーザーに書き込み権限を付与します。# mkdir /var/named/log/ # chown named:named /var/named/log/ # chmod 700 /var/named/log/
/etc/named.conf
ファイルの構文を確認します。# named-checkconf
コマンドが出力を表示しない場合は、構文に間違いがありません。
BIND を再起動します。
# systemctl restart named
change-root 環境で BIND を実行する場合は、
systemctl restart named-chroot
コマンドを使用してサービスを再起動します。
検証
ログファイルの内容を表示します。
# cat /var/named/log/transfer.log ... 06-Jul-2022 15:08:51.261 xfer-out: info: client @0x7fecbc0b0700 192.0.2.2#36121/key example-transfer-key (example.com): transfer of 'example.com/IN': AXFR started: TSIG example-transfer-key (serial 2022070603) 06-Jul-2022 15:08:51.261 xfer-out: info: client @0x7fecbc0b0700 192.0.2.2#36121/key example-transfer-key (example.com): transfer of 'example.com/IN': AXFR ended
関連情報
-
named.conf(5)
man ページ - BIND 管理者リファレンスマニュアル
4.5. BIND ACL の作成
BIND の特定の機能へのアクセスを制御することで、サービス拒否 (DoS) などの不正アクセスや攻撃を防ぐことができます。BIND アクセス制御リスト (acl
) ステートメントは、IP アドレスと範囲のリストです。各 ACL には、指定された IP アドレスと範囲を参照するために allow-query
などのいくつかのステートメントで使用できるニックネームがあります。
BIND は、ACL で最初に一致したエントリーのみを使用します。たとえば、ACL { 192.0.2/24; !192.0.2.1; }
を定義し、IP アドレス 192.0.2.1
でホストが接続すると、2 番目のエントリーでこのアドレスが除外されていてもアクセスが許可されます。
BIND には次の組み込み ACL があります。
-
none
: どのホストとも一致しません。 -
any
: すべてのホストに一致します。 -
localhost
: ループバックアドレス127.0.0.1
と::1
、および BIND を実行するサーバー上のすべてのインターフェイスの IP アドレスに一致します。 -
localnets
: ループバックアドレス127.0.0.1
と::1
、および BIND を実行するサーバーが直接接続しているすべてのサブネットに一致します。
前提条件
- BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
-
named
またはnamed-chroot
サービスが実行しています。
手順
/etc/named.conf
ファイルを編集して、次の変更を行います。acl
ステートメントをファイルに追加します。たとえば、127.0.0.1
、192.0.2.0/24
、および2001:db8:1::/64
に対してinternal-networks
という名前の ACL を作成するには、次のように入力します。acl internal-networks { 127.0.0.1; 192.0.2.0/24; 2001:db8:1::/64; }; acl dmz-networks { 198.51.100.0/24; 2001:db8:2::/64; };
ACL のニックネームをサポートするステートメントで使用します。たとえば、次のようになります。
allow-query { internal-networks; dmz-networks; }; allow-recursion { internal-networks; };
/etc/named.conf
ファイルの構文を確認します。# named-checkconf
コマンドが出力を表示しない場合は、構文に間違いがありません。
BIND をリロードします。
# systemctl reload named
change-root 環境で BIND を実行する場合は、
systemctl reload named-chroot
コマンドを使用してサービスをリロードします。
検証
設定された ACL を使用する機能をトリガーするアクションを実行します。たとえば、この手順の ACL は、定義された IP アドレスからの再帰クエリーのみを許可します。この場合は、ACL の定義に含まれていないホストで次のコマンドを入力して、外部ドメインの解決を試みます。
# dig +short @192.0.2.1 www.example.com
コマンドが出力を返さないと、BIND はアクセスを拒否し、ACL は機能しています。クライアントで詳細な出力を得るには、
+short
オプションを指定せずにコマンドを使用します。# dig @192.0.2.1 www.example.com ... ;; WARNING: recursion requested but not available ...
関連情報
-
The BIND Administrator Reference Manual の
Access control lists
セクション。
4.6. BIND DNS サーバーでのゾーンの設定
DNS ゾーンは、ドメインスペース内の特定のサブツリーのリソースレコードを含むデータベースです。たとえば、example.com
ドメインを担当している場合は、BIND でそのゾーンを設定できます。その結果、クライアントは www.example.com
をこのゾーンで設定された IP アドレスに解決できます。
4.6.1. ゾーンファイルの SOA レコード
SOA (Start of Authority) レコードは、DNS ゾーンで必要なレコードです。このレコードは、たとえば、複数の DNS サーバーがゾーンだけでなく DNS リゾルバーに対しても権限を持っている場合に重要です。
BIND の SOA レコードの構文は次のとおりです。
name class type mname rname serial refresh retry expire minimum
読みやすくするために、管理者は通常、ゾーンファイル内のレコードを、セミコロン (;
) で始まるコメントを使用して複数の行に分割します。SOA レコードを分割する場合は、括弧でレコードをまとめることに注意してください。
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2022070601 ; serial number 1d ; refresh period 3h ; retry period 3d ; expire time 3h ) ; minimum TTL
完全修飾ドメイン名 (FQDN) の末尾にあるドットに注意してください。FQDN は、ドットで区切られた複数のドメインラベルで設定されます。DNS ルートには空のラベルがあるため、FQDN はドットで終わります。したがって、BIND はゾーン名を末尾のドットなしで名前に追加します。末尾にドットがないホスト名 (例: ns1.example.com
) は、ns1.example.com.example.com.
に展開されます。これは、プライマリーネームサーバーの正しいアドレスではありません。
SOA レコードのフィールドは次のとおりです。
-
name
: ゾーンの名前 (つまりorigin
)。このフィールドを@
に設定すると、BIND はそれを/etc/named.conf
で定義されたゾーン名に展開します。 -
class
: SOA レコードでは、このフィールドを常に Internet (IN
) に設定する必要があります。 -
type
: SOA レコードでは、このフィールドを常にSOA
に設定する必要があります。 -
mname
(マスター名): このゾーンのプライマリーネームサーバーのホスト名。 -
rname
(責任者名): このゾーンの責任者の電子メールアドレス。形式が異なりますのでご注意ください。アットマーク (@
) をドット (.
) に置き換える必要があります。 serial
: このゾーンファイルのバージョン番号。セカンダリーネームサーバーは、プライマリーサーバーのシリアル番号の方が大きい場合にのみ、ゾーンのコピーを更新します。形式は任意の数値にすることができます。一般的に使用される形式は
<year><month><day><two-digit-number>
です。この形式を使用すると、理論的には、ゾーンファイルを 1 日に 100 回まで変更できます。-
refresh
: ゾーンが更新された場合は、プライマリーサーバーをチェックする前にセカンダリーサーバーが待機する時間。 -
retry
: 試行が失敗した後、セカンダリーサーバーがプライマリーサーバーへのクエリーを再試行するまでの時間。 -
expire
: 以前の試行がすべて失敗した場合に、セカンダリーサーバーがプライマリーサーバーへのクエリーを停止した後の時間。 -
minimum
: RFC 2308 は、このフィールドの意味を負のキャッシュ時間に変更しました。準拠リゾルバーは、NXDOMAIN
名エラーをキャッシュする期間を決定するために使用します。
refresh
、retry
、expire
、および maximum
フィールドの数値は、時間を秒単位で定義します。ただし、読みやすくするために、時間の接尾辞 (m
は分、h
は時間、d
は日など) を使用してください。たとえば、3h
は 3 時間を表します。
4.6.2. BIND プライマリーサーバーでの正引きゾーンの設定
正引きゾーンは、名前を IP アドレスやその他の情報にマップします。たとえば、ドメイン example.com
を担当している場合は、BIND で転送ゾーンを設定して、www.example.com
などの名前を解決できます。
前提条件
- BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
-
named
またはnamed-chroot
サービスが実行しています。
手順
/etc/named.conf
ファイルにゾーン定義を追加します。zone "example.com" { type master; file "example.com.zone"; allow-query { any; }; allow-transfer { none; }; };
これらの設定により、次が定義されます。
-
このサーバーは、
example.com
ゾーンのプライマリーサーバー (type master
) です。 -
/var/named/example.com.zone
ファイルはゾーンファイルです。この例のように相対パスを設定すると、このパスは、options
ステートメントのdirectory
に設定したディレクトリーからの相対パスになります。 - どのホストもこのゾーンにクエリーを実行できます。または、IP 範囲または BIND アクセス制御リスト (ACL) のニックネームを指定して、アクセスを制限します。
- どのホストもゾーンを転送できません。ゾーン転送を許可するのは、セカンダリーサーバーをセットアップする際に限られ、セカンダリーサーバーの IP アドレスに対してのみ許可します。
-
このサーバーは、
/etc/named.conf
ファイルの構文を確認します。# named-checkconf
コマンドが出力を表示しない場合は、構文に間違いがありません。
たとえば、次の内容で
/var/named/example.com.zone
ファイルを作成します。$TTL 8h @ IN SOA ns1.example.com. hostmaster.example.com. ( 2022070601 ; serial number 1d ; refresh period 3h ; retry period 3d ; expire time 3h ) ; minimum TTL IN NS ns1.example.com. IN MX 10 mail.example.com. www IN A 192.0.2.30 www IN AAAA 2001:db8:1::30 ns1 IN A 192.0.2.1 ns1 IN AAAA 2001:db8:1::1 mail IN A 192.0.2.20 mail IN AAAA 2001:db8:1::20
このゾーンファイル:
-
リソースレコードの既定の有効期限 (TTL) 値を 8 時間に設定します。時間の
h
などの時間接尾辞がない場合、BIND は値を秒として解釈します。 - ゾーンに関する詳細を含む、必要な SOA リソースレコードが含まれています。
-
このゾーンの権威 DNS サーバーとして
ns1.example.com
を設定します。ゾーンを機能させるには、少なくとも 1 つのネームサーバー (NS
) レコードが必要です。ただし、RFC 1912 に準拠するには、少なくとも 2 つのネームサーバーが必要です。 -
example.com
ドメインのメールエクスチェンジャー (MX
) としてmail.example.com
を設定します。ホスト名の前の数値は、レコードの優先度です。値が小さいエントリーほど優先度が高くなります。 -
www.example.com
、mail.example.com
、およびns1.example.com
の IPv4 アドレスおよび IPv6 アドレスを設定します。
-
リソースレコードの既定の有効期限 (TTL) 値を 8 時間に設定します。時間の
named
グループだけがそれを読み取ることができるように、ゾーンファイルに安全なアクセス許可を設定します。# chown root:named /var/named/example.com.zone # chmod 640 /var/named/example.com.zone
/var/named/example.com.zone
ファイルの構文を確認します。# named-checkzone example.com /var/named/example.com.zone zone example.com/IN: loaded serial 2022070601 OK
BIND をリロードします。
# systemctl reload named
change-root 環境で BIND を実行する場合は、
systemctl reload named-chroot
コマンドを使用してサービスをリロードします。
検証
example.com
ゾーンからさまざまなレコードをクエリーし、出力がゾーンファイルで設定したレコードと一致することを確認します。# dig +short @localhost AAAA www.example.com 2001:db8:1::30 # dig +short @localhost NS example.com ns1.example.com. # dig +short @localhost A ns1.example.com 192.0.2.1
この例では、BIND が同じホストで実行し、
localhost
インターフェイスでクエリーに応答することを前提としています。
4.6.3. BIND プライマリーサーバーでの逆引きゾーンの設定
逆ゾーンは、IP アドレスを名前にマップします。たとえば、IP 範囲 192.0.2.0/24
を担当している場合は、BIND で逆引きゾーンを設定して、この範囲の IP アドレスをホスト名に解決できます。
クラスフルネットワーク全体の逆引きゾーンを作成する場合は、それに応じてゾーンに名前を付けます。たとえば、クラス C ネットワーク 192.0.2.0/24
の場合は、ゾーンの名前が 2.0.192.in-addr.arpa
です。190.0.2.0/28
など、異なるネットワークサイズの逆引きゾーンを作成する場合は、ゾーンの名前が 28-2.0.192.in-addr.arpa
です。
前提条件
- BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
-
named
またはnamed-chroot
サービスが実行しています。
手順
/etc/named.conf
ファイルにゾーン定義を追加します。zone "2.0.192.in-addr.arpa" { type master; file "2.0.192.in-addr.arpa.zone"; allow-query { any; }; allow-transfer { none; }; };
これらの設定により、次が定義されます。
-
2.0.192.in-addr.arpa
逆引きゾーンのプライマリーサーバー (type master
) としてのこのサーバー。 -
/var/named/2.0.192.in-addr.arpa.zone
ファイルはゾーンファイルです。この例のように相対パスを設定すると、このパスは、options
ステートメントのdirectory
に設定したディレクトリーからの相対パスになります。 - どのホストもこのゾーンにクエリーを実行できます。または、IP 範囲または BIND アクセス制御リスト (ACL) のニックネームを指定して、アクセスを制限します。
- どのホストもゾーンを転送できません。ゾーン転送を許可するのは、セカンダリーサーバーをセットアップする際に限られ、セカンダリーサーバーの IP アドレスに対してのみ許可します。
-
/etc/named.conf
ファイルの構文を確認します。# named-checkconf
コマンドが出力を表示しない場合は、構文に間違いがありません。
たとえば、次の内容で
/var/named/2.0.192.in-addr.arpa.zone
ファイルを作成します。$TTL 8h @ IN SOA ns1.example.com. hostmaster.example.com. ( 2022070601 ; serial number 1d ; refresh period 3h ; retry period 3d ; expire time 3h ) ; minimum TTL IN NS ns1.example.com. 1 IN PTR ns1.example.com. 30 IN PTR www.example.com.
このゾーンファイル:
-
リソースレコードの既定の有効期限 (TTL) 値を 8 時間に設定します。時間の
h
などの時間接尾辞がない場合、BIND は値を秒として解釈します。 - ゾーンに関する詳細を含む、必要な SOA リソースレコードが含まれています。
-
ns1.example.com
をこの逆引きゾーンの権威 DNS サーバーとして設定します。ゾーンを機能させるには、少なくとも 1 つのネームサーバー (NS
) レコードが必要です。ただし、RFC 1912 に準拠するには、少なくとも 2 つのネームサーバーが必要です。 -
192.0.2.1
および192.0.2.30
アドレスのポインター (PTR
) レコードを設定します。
-
リソースレコードの既定の有効期限 (TTL) 値を 8 時間に設定します。時間の
named
グループのみがそれを読み取ることができるように、ゾーンファイルに安全なアクセス許可を設定します。# chown root:named /var/named/2.0.192.in-addr.arpa.zone # chmod 640 /var/named/2.0.192.in-addr.arpa.zone
/var/named/2.0.192.in-addr.arpa.zone
ファイルの構文を確認します。# named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.in-addr.arpa.zone zone 2.0.192.in-addr.arpa/IN: loaded serial 2022070601 OK
BIND をリロードします。
# systemctl reload named
change-root 環境で BIND を実行する場合は、
systemctl reload named-chroot
コマンドを使用してサービスをリロードします。
検証
逆引きゾーンからさまざまなレコードをクエリーし、出力がゾーンファイルで設定したレコードと一致することを確認します。
# dig +short @localhost -x 192.0.2.1 ns1.example.com. # dig +short @localhost -x 192.0.2.30 www.example.com.
この例では、BIND が同じホストで実行し、
localhost
インターフェイスでクエリーに応答することを前提としています。
4.6.4. BIND ゾーンファイルの更新
サーバーの IP アドレスが変更された場合など、特定の状況では、ゾーンファイルを更新する必要があります。複数の DNS サーバーが 1 つのゾーンを担ってる場合は、この手順をプライマリーサーバーでのみ実行してください。ゾーンのコピーを保存する他の DNS サーバーは、ゾーン転送を通じて更新を受け取ります。
前提条件
- ゾーンが設定されました。
-
named
またはnamed-chroot
サービスが実行しています。
手順
オプション:
/etc/named.conf
ファイル内のゾーンファイルへのパスを特定します。options { ... directory "/var/named"; } zone "example.com" { ... file "example.com.zone"; };
ゾーンの定義の
file
ステートメントで、ゾーンファイルへのパスを見つけます。相対パスは、options
ステートメントのdirectory
に設定されたディレクトリーからの相対パスです。ゾーンファイルを編集します。
- 必要な変更を行います。
SOA (Start of Authority) レコードのシリアル番号を増やします。
重要シリアル番号が以前の値以下の場合、セカンダリーサーバーはゾーンのコピーを更新しません。
ゾーンファイルの構文を確認します。
# named-checkzone example.com /var/named/example.com.zone zone example.com/IN: loaded serial 2022062802 OK
BIND をリロードします。
# systemctl reload named
change-root 環境で BIND を実行する場合は、
systemctl reload named-chroot
コマンドを使用してサービスをリロードします。
検証
追加、変更、または削除したレコードを照会します。たとえば、次のようになります。
# dig +short @localhost A ns2.example.com 192.0.2.2
この例では、BIND が同じホストで実行し、
localhost
インターフェイスでクエリーに応答することを前提としています。
4.6.5. 自動鍵生成およびゾーン保守機能を使用した DNSSEC ゾーン署名
DNSSEC (Domain Name System Security Extensions) でゾーンに署名して、認証およびデータの整合性を確保できます。このようなゾーンには、追加のリソースレコードが含まれます。クライアントはそれらを使用して、ゾーン情報の信頼性を検証できます。
ゾーンの DNSSEC ポリシー機能を有効にすると、BIND は次のアクションを自動的に実行します。
- キーを作成します。
- ゾーンに署名します
- 鍵の再署名や定期的な交換など、ゾーンを維持します。
外部 DNS サーバーがゾーンの信頼性を検証できるようにするには、ゾーンの公開キーを親ゾーンに追加する必要があります。これを行う方法の詳細については、ドメインプロバイダーまたはレジストリーにお問い合わせください。
この手順では、BIND に組み込まれている default
の DNSSEC ポリシーを使用します。このポリシーは、単一の ECDSAP256SHA
鍵署名を使用します。または、独自のポリシーを作成して、カスタムキー、アルゴリズム、およびタイミングを使用します。
前提条件
-
BIND 9.16 以降がインストールされている。この要件を満たすには、
bind
の代わりにbind9.16
パッケージをインストールします。 - DNSSEC を有効にするゾーンが設定されている。
-
named
またはnamed-chroot
サービスが実行しています。 - サーバーは時刻をタイムサーバーと同期します。DNSSEC 検証では、正確なシステム時刻が重要です。
手順
/etc/named.conf
ファイルを編集し、DNSSEC を有効にするゾーンにdnssec-policy default;
を追加します。zone "example.com" { ... dnssec-policy default; };
BIND をリロードします。
# systemctl reload named
change-root 環境で BIND を実行する場合は、
systemctl reload named-chroot
コマンドを使用してサービスをリロードします。BIND は公開鍵を
/var/named/K<zone_name>.+<algorithm>+<key_ID>.key
ファイルに保存します。このファイルを使用して、親ゾーンが必要とする形式でゾーンの公開鍵を表示します。DS レコード形式:
# dnssec-dsfromkey /var/named/Kexample.com.+013+61141.key example.com. IN DS 61141 13 2 3E184188CF6D2521EDFDC3F07CFEE8D0195AACBD85E68BAE0620F638B4B1B027
DNSKEY 形式:
# grep DNSKEY /var/named/Kexample.com.+013+61141.key example.com. 3600 IN DNSKEY 257 3 13 sjzT3jNEp120aSO4mPEHHSkReHUf7AABNnT8hNRTzD5cKMQSjDJin2I3 5CaKVcWO1pm+HltxUEt+X9dfp8OZkg==
- ゾーンの公開鍵を親ゾーンに追加するように要求します。これを行う方法の詳細については、ドメインプロバイダーまたはレジストリーにお問い合わせください。
検証
DNSSEC 署名を有効にしたゾーンのレコードについて、独自の DNS サーバーにクエリーを実行します。
# dig +dnssec +short @localhost A www.example.com 192.0.2.30 A 13 3 28800 20220718081258 20220705120353 61141 example.com. e7Cfh6GuOBMAWsgsHSVTPh+JJSOI/Y6zctzIuqIU1JqEgOOAfL/Qz474 M0sgi54m1Kmnr2ANBKJN9uvOs5eXYw==
この例では、BIND が同じホストで実行し、
localhost
インターフェイスでクエリーに応答することを前提としています。公開鍵が親ゾーンに追加され、他のサーバーに伝播されたら、サーバーが署名付きゾーンへのクエリーで認証済みデータ (
ad
) フラグを設定することを確認します。# dig @localhost example.com +dnssec ... ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ...
4.7. BIND DNS サーバー間のゾーン転送の設定
ゾーン転送により、ゾーンのコピーを持つすべての DNS サーバーが最新のデータを使用することが保証されます。
前提条件
- 将来のプライマリーサーバーでは、ゾーン転送を設定するゾーンが設定されている。
- 将来のセカンダリーサーバーでは、BIND はキャッシュネームサーバーなどとして設定されている。
-
両方のサーバーで、
named
サービスまたはnamed-chroot
サービスが実行している。
手順
既存のプライマリーサーバーで、以下を行います。
共有キーを作成し、
/etc/named.conf
ファイルに追加します。# tsig-keygen example-transfer-key | tee -a /etc/named.conf key "example-transfer-key" { algorithm hmac-sha256; secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ="; };
このコマンドは、
tsig-keygen
コマンドの出力を表示し、自動的に/etc/named.conf
に追加します。後でセカンダリーサーバーでもコマンドの出力が必要になります。
/etc/named.conf
ファイルのゾーン定義を編集します。allow-transfer
ステートメントで、サーバーがゾーンを転送するためにexample-transfer-key
ステートメントで指定されたキーを提供する必要があることを定義します。zone "example.com" { ... allow-transfer { key example-transfer-key; }; };
または、
allow-transfer
ステートメントで BIND アクセス制御リスト (ACL) ニックネームを使用します。デフォルトでは、ゾーンが更新された後、BIND は、このゾーンにネームサーバー (
NS
) レコードを持つすべてのネームサーバーに通知します。セカンダリーサーバーのNS
レコードをゾーンに追加する予定がない場合は、BIND がこのサーバーに通知するように設定できます。そのために、このセカンダリーサーバーの IP アドレスを含むalso-notify
ステートメントをゾーンに追加します。zone "example.com" { ... also-notify { 192.0.2.2; 2001:db8:1::2; }; };
/etc/named.conf
ファイルの構文を確認します。# named-checkconf
コマンドが出力を表示しない場合は、構文に間違いがありません。
BIND をリロードします。
# systemctl reload named
change-root 環境で BIND を実行する場合は、
systemctl reload named-chroot
コマンドを使用してサービスをリロードします。
将来のセカンダリーサーバーで、以下を行います。
/etc/named.conf
ファイルを次のように編集します。プライマリーサーバーと同じキー定義を追加します。
key "example-transfer-key" { algorithm hmac-sha256; secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ="; };
/etc/named.conf
ファイルにゾーン定義を追加します。zone "example.com" { type slave; file "slaves/example.com.zone"; allow-query { any; }; allow-transfer { none; }; masters { 192.0.2.1 key example-transfer-key; 2001:db8:1::1 key example-transfer-key; }; };
これらの設定状態:
-
このサーバーは、
example.com
ゾーンのセカンダリーサーバー (type slave
) です。 -
/var/named/slaves/example.com.zone
ファイルはゾーンファイルです。この例のように相対パスを設定すると、このパスは、options
ステートメントのdirectory
に設定したディレクトリーからの相対パスになります。このサーバーがセカンダリーであるゾーンファイルをプライマリーサーバーから分離するには、それを/var/named/slaves/
ディレクトリーなどに保存します。 - どのホストもこのゾーンにクエリーを実行できます。または、IP 範囲または ACL ニックネームを指定して、アクセスを制限します。
- このサーバーからゾーンを転送できるホストはありません。
-
このゾーンのプライマリーサーバーの IP アドレスは
192.0.2.1
および2001:db8:1::2
です。または、ACL ニックネームを指定できます。このセカンダリーサーバーは、example-transfer-key
という名前のキーを使用して、プライマリーサーバーに対する認証を行います。
-
このサーバーは、
/etc/named.conf
ファイルの構文を確認します。# named-checkconf
BIND をリロードします。
# systemctl reload named
change-root 環境で BIND を実行する場合は、
systemctl reload named-chroot
コマンドを使用してサービスをリロードします。
-
オプション: プライマリーサーバーのゾーンファイルを変更し、新しいセカンダリーサーバーの
NS
レコードを追加します。
検証
セカンダリーサーバーで次の手順を実行します。
named
サービスのsystemd
ジャーナルエントリーを表示します。# journalctl -u named ... Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: Transfer started. Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: connected using 192.0.2.2#45803 Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: transferred serial 2022070101 Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer status: success Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer completed: 1 messages, 29 records, 2002 bytes, 0.003 secs (667333 bytes/sec)
change-root 環境で BIND を実行する場合は、
journalctl -u named-chroot
コマンドを使用してジャーナルエントリーを表示します。BIND がゾーンファイルを作成したことを確認します。
# ls -l /var/named/slaves/ total 4 -rw-r--r--. 1 named named 2736 Jul 6 15:08 example.com.zone
デフォルトでは、セカンダリーサーバーはゾーンファイルを未修正のバイナリー形式で保存することに注意してください。
セカンダリーサーバーから転送されたゾーンのレコードをクエリーします。
# dig +short @192.0.2.2 AAAA www.example.com 2001:db8:1::30
この例では、この手順で設定したセカンダリーサーバーが IP アドレス
192.0.2.2
でリッスンしていると想定しています。
4.8. DNS レコードを上書きするように BIND で応答ポリシーゾーンを設定する
管理者は、DNS のブロックとフィルタリングを使用して、DNS 応答を書き換えて、特定のドメインまたはホストへのアクセスをブロックできます。BIND では、応答ポリシーゾーン (RPZ) がこの機能を提供します。NXDOMAIN
エラーを返す、クエリーに応答しないなど、ブロックされたエントリーに対してさまざまなアクションを設定できます。
環境内に複数の DNS サーバーがある場合は、この手順を使用してプライマリーサーバーで RPZ を設定し、後でゾーン転送を設定して、セカンダリーサーバーで RPZ を使用できるようにします。
前提条件
- BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
-
named
またはnamed-chroot
サービスが実行しています。
手順
/etc/named.conf
ファイルを編集し、次の変更を行います。options
ステートメントにresponse-policy
定義を追加します。options { ... response-policy { zone "rpz.local"; }; ... }
response-policy
のzone
ステートメントで RPZ のカスタム名を設定できます。ただし、次のステップのゾーン定義で同じ名前を使用する必要があります。前の手順で設定した RPZ の
zone
定義を追加します。zone "rpz.local" { type master; file "rpz.local"; allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; }; allow-transfer { none; }; };
これらの設定状態:
-
このサーバーは、
rpz.local
という名前の RPZ のプライマリーサーバー (type master
) です。 -
/var/named/rpz.local
ファイルはゾーンファイルです。この例のように相対パスを設定すると、このパスは、options
ステートメントのdirectory
に設定したディレクトリーからの相対パスになります。 -
allow-query
で定義されたホストは、この RPZ をクエリーできます。または、IP 範囲または BIND アクセス制御リスト (ACL) のニックネームを指定して、アクセスを制限します。 - どのホストもゾーンを転送できません。ゾーン転送を許可するのは、セカンダリーサーバーをセットアップする際に限られ、セカンダリーサーバーの IP アドレスに対してのみ許可します。
-
このサーバーは、
/etc/named.conf
ファイルの構文を確認します。# named-checkconf
コマンドが出力を表示しない場合は、構文に間違いがありません。
たとえば、次の内容で
/var/named/rpz.local
ファイルを作成します。$TTL 10m @ IN SOA ns1.example.com. hostmaster.example.com. ( 2022070601 ; serial number 1h ; refresh period 1m ; retry period 3d ; expire time 1m ) ; minimum TTL IN NS ns1.example.com. example.org IN CNAME . *.example.org IN CNAME . example.net IN CNAME rpz-drop. *.example.net IN CNAME rpz-drop.
このゾーンファイル:
-
リソースレコードの既定の有効期限 (TTL) 値を 10 分に設定します。時間の
h
などの時間接尾辞がない場合、BIND は値を秒として解釈します。 - ゾーンに関する詳細を含む、必要な SOA (Start of Authority) リソースレコードが含まれます。
-
このゾーンの権威 DNS サーバーとして
ns1.example.com
を設定します。ゾーンを機能させるには、少なくとも 1 つのネームサーバー (NS
) レコードが必要です。ただし、RFC 1912 に準拠するには、少なくとも 2 つのネームサーバーが必要です。 -
このドメイン内の
example.org
およびホストへのクエリーに対してNXDOMAIN
エラーを返します。 -
このドメイン内の
example.net
およびホストにクエリーを破棄します。
アクションおよび例の完全なリストは、IETF draft: DNS Response Policy Zones (RPZ) を参照してください。
-
リソースレコードの既定の有効期限 (TTL) 値を 10 分に設定します。時間の
/var/named/rpz.local
ファイルの構文を確認します。# named-checkzone rpz.local /var/named/rpz.local zone rpz.local/IN: loaded serial 2022070601 OK
BIND をリロードします。
# systemctl reload named
change-root 環境で BIND を実行する場合は、
systemctl reload named-chroot
コマンドを使用してサービスをリロードします。
検証
NXDOMAIN
エラーを返すように RPZ で設定されているexample.org
のホストを解決しようとします。# dig @localhost www.example.org ... ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30286 ...
この例では、BIND が同じホストで実行し、
localhost
インターフェイスでクエリーに応答することを前提としています。RPZ でクエリーを破棄するように設定されている
example.net
ドメイン内のホストの解決を試みます。# dig @localhost www.example.net ... ;; connection timed out; no servers could be reached ...
第5章 NFS 共有のエクスポート
システム管理者は、NFS サーバーを使用して、ネットワーク上のシステムのディレクトリーを共有できます。
5.1. NFS の概要
本セクションでは、NFS サービスの基本概念を説明します。
ネットワークファイルシステム (NFS) を利用すると、リモートのホストがネットワーク経由でファイルシステムをマウントし、そのファイルシステムを、ローカルにマウントしているファイルシステムと同じように操作できるようになります。また、リソースを、ネットワークの集中化サーバーに統合できるようになります。
NFS サーバーは、/etc/exports
設定ファイルを参照して、そのクライアントがエクスポート済みファイルシステムにアクセスできるかどうかを確認します。アクセスが可能なことが確認されると、そのユーザーは、ファイルおよびディレクトリーへの全操作を行えるようになります。
5.2. 対応している NFS バージョン
本セクションでは、Red Hat Enterprise Linux でサポートされている NFS のバージョンと、その機能の一覧を紹介します。
現在、Red Hat Enterprise Linux 8 は、以下の NFS のメジャーバージョンに対応しています。
- NFS バージョン 3 (NFSv3) は安全な非同期書き込みに対応しており、以前の NFSv2 よりもエラー処理において安定しています。64 ビットのファイルサイズとオフセットにも対応しているため、クライアントは 2 GB を超えるファイルデータにアクセスできます。
-
NFS バージョン 4 (NFSv4) は、ファイアウォールやインターネットを介して動作し、
rpcbind
サービスを必要とせず、アクセス制御リスト (ACL) に対応し、ステートフルな操作を利用します。
NFS バージョン 2 (NFSv2) は、Red Hat のサポート対象外になりました。
デフォルトの NFS バージョン
Red Hat Enterprise Linux 8 のデフォルトの NFS バージョンは 4.2 です。NFS クライアントは、デフォルトで NFSv4.2 を使用してマウントを試行し、サーバーが NFSv4.2 に対応していない場合は NFSv4.1 にフォールバックします。マウントは後で NFSv4.0 に戻り、次に NFSv3 に戻ります。
NFS のマイナーバージョンの機能
以下は、Red Hat Enterprise Linux 8 における NFSv4.2 の機能です。
- サーバー側コピー
-
NFS クライアントが
copy_file_range()
システムコールを使用してネットワークリソースを無駄にすることなく、データを効率的にコピーできるようにします。 - スパースファイル
-
ファイルに 1 つ以上の ホール を持たせることができます。ホールとは、割り当てられていない、またはゼロのみで設定される未初期化データブロックです。NFSv4.2 の
lseek()
操作はseek_hole()
とseek_data()
に対応しています。これにより、アプリケーションはスパースファイルのホールの場所をマップできます。 - 領域の予約
-
ストレージサーバーが空き領域を予約することを許可します。これにより、サーバーで領域が不足することがなくなります。NFSv4.2 は、領域を予約するための
allocate()
操作、領域の予約を解除するためのdeallocate()
操作、およびファイル内の領域の事前割り当てまたは割り当て解除を行うfallocate()
操作に対応しています。 - ラベル付き NFS
- データアクセス権を強制し、NFS ファイルシステム上の個々のファイルに対して、クライアントとサーバーとの間の SELinux ラベルを有効にします。
- レイアウトの機能強化
-
一部の Parallel NFS (pNFS) サーバーがより良いパフォーマンス統計を収集できるようにする
layoutstats()
操作が提供されます。
NFSv4.1 の機能は次のとおりです。
- ネットワークのパフォーマンスおよびセキュリティーを強化し、pNFS のクライアント側サポートも含みます。
- コールバックに個別の TCP 接続を必要としなくなりました。これにより、NAT やファイアウォールが干渉した場合など、クライアントと通信できない場合でも NFS サーバーは委任を許可できます。
- 応答が失われ、操作が 2 回送信された場合に特定の操作が不正確な結果を返すことがあるという以前の問題を防ぐために、1 回限りのセマンティクスを提供します (再起動操作を除く)。
5.3. NFSv3 と NFSv4 の TCP プロトコルと UDP プロトコル
NFSv4 は、IP ネットワークで TCP (Transmission Control Protocol) の実行が必要です。
NFSv3 は、Red Hat Enterprise Linux の以前のバージョンで User Datagram Protocol (UDP) を使用することもできます。Red Hat Enterprise Linux 8 では、NFS over UDP に対応しなくなりました。デフォルトでは、UDP は、NFS サーバーで無効になります。
5.4. NFS が必要とするサービス
本セクションでは、NFS サーバーの実行または NFS 共有のマウントに必要なシステムサービスの一覧を紹介します。Red Hat Enterprise Linux は、このサービスを自動的に開始します。
Red Hat Enterprise Linux では、NFS ファイル共有を提供するのに、カーネルレベルのサポートとサービスのプロセスの組み合わせを使用します。NFS のすべてのバージョンは、クライアントとサーバーとの間の RPC (Remote Procedure Call) に依存します。NFS ファイルシステムの共有やマウントには、実装されている NFS のバージョンに応じて、次のようなサービスが連携して動作することになります。
nfsd
- 共有 NFS ファイルシステムに対する要求を処理する NFS サーバーカーネルモジュールです。
rpcbind
-
ローカルの RPC サービスからポート予約を受け取ります。その後、これらのポートは、対応するリモートの RPC サービスによりアクセス可能であることが公開されます。
rpcbind
サービスは、RPC サービスへの要求に応答し、要求された RPC サービスへの接続を設定します。このプロセスは NFSv4 では使用されません。 rpc.mountd
-
NFS サーバーは、このプロセスを使用して NFSv3 クライアントの
MOUNT
要求を処理します。要求されている NFS 共有が現在 NFS サーバーによりエクスポートされているか、またその共有へのクライアントのアクセスが許可されているかを確認します。マウントの要求が許可されると、nfs-mountd
サービスは Success ステータスで応答し、この NFS 共有用の File-Handle を NFS クライアントに戻します。 rpc.nfsd
-
このプロセスでは、サーバーが公開している明示的な NFS のバージョンとプロトコルを定義できます。NFS クライアントが接続するたびにサーバースレッドを提供するなど、NFS クライアントの動的な要求に対応するため、Linux カーネルと連携して動作します。このプロセスは、
nfs-server
サービスに対応します。 lockd
- クライアントとサーバーの両方で実行するカーネルスレッドです。Network Lock Manager (NLM) プロトコルを実装し、NFSv3 のクライアントが、サーバーでファイルのロックを行えるようにします。NFS サーバーが実行中で、NFS ファイルシステムがマウントされていれば、このプロセスは常に自動的に起動します。
rpc.statd
-
このプロセスは、Network Status Monitor (NSM) RPC プロトコルを実装します。NFS サーバーが正常にシャットダウンされずに再起動すると、NFS クライアントに通知します。
rpc-statd
サービスは、nfs-server
サービスにより自動的に起動されるため、ユーザー設定は必要ありません。このプロセスは NFSv4 では使用されません。 rpc.rquotad
-
このプロセスは、リモートユーザーのユーザークォーター情報を提供します。
quota-rpc
パッケージが提供するrpc-rquotad
サービスは、nfs-server
の起動時にユーザーが起動する必要があります。 rpc.idmapd
このプロセスは、ネットワークの NFSv4 の名前 (
user@domain
形式の文字列) と、ローカルの UID および GID のマッピングを行う NFSv4 のクライアントおよびサーバーのアップコールを提供します。idmapd
を NFSv4 で正常に動作させるには、/etc/idmapd.conf
ファイルを設定する必要があります。少なくとも、NFSv4 マッピングドメインを定義するDomain
パラメーターを指定する必要があります。NFSv4 マッピングドメインが DNS ドメイン名と同じ場合は、このパラメーターは必要ありません。クライアントとサーバーが ID マッピングの NFSv4 マッピングドメインに合意しないと、適切に動作しません。rpc.idmapd
を使用するのは NFSv4 サーバーだけで、nfs-idmapd
サービスにより起動します。NFSv4 クライアントは、キーリングベースのnfsidmap
ユーティリティーを使用します。これはカーネルによりオンデマンドで呼び出され、ID マッピングを実行します。nfsidmap
に問題がある場合は、クライアントがrpc.idmapd
の使用にフォールバックします。
NFSv4 を使用する RPC サービス
NFSv4 プロトコルには、マウントとロックのプロトコルが組み込まれています。サーバーは、既知の TCP ポート 2049 もリッスンします。そのため、NFSv4 は rpcbind
サービス、lockd
サービス、および rpc-statd
サービスと対話する必要はありません。nfs-mountd
サービスは、エクスポートを設定するために NFS サーバーで引き続き必要となりますが、ネットワーク上の操作には関与しません。
5.5. NFS ホスト名の形式
本セクションでは、NFS 共有をマウントまたはエクスポートするときにホストの指定に使用するさまざまな形式を説明します。
次の形式でホストを指定できます。
- 単独のマシン
次のいずれかになります。
- 完全修飾ドメイン名 (サーバーにより解決)
- ホスト名 (サーバーにより解決)
- IP アドレス
- IP ネットワーク
以下のいずれかの形式が有効です。
-
a.b.c.d/z
-a.b.c.d
がネットワークで、z
がネットマスクのビット数になります (例:192.168.0.0/24
)。 -
a.b.c.d/netmask
-a.b.c.d
がネットワークで、netmask
がネットマスクになります (例:192.168.100.8/255.255.255.0
)。
-
- Netgroup
-
@group-name
形式 -group-name
は NIS netgroup 名です。
5.6. NFS サーバーの設定
本セクションでは、NFS サーバーでエクスポートを設定する 2 種類の構文およびオプションを説明します。
-
設定ファイル
/etc/exports
を手動で編集する方法 -
コマンドラインで
exportfs
ユーティリティーを使用する方法
5.6.1. /etc/exports 設定ファイル
/etc/exports
ファイルは、リモートホストにどのファイルシステムをエクスポートするかを制御し、オプションを指定します。以下の構文ルールに従います。
- 空白行は無視する。
-
コメント行は、ハッシュ記号 (
#
) で始める。 -
長い行は、バックスラッシュ (
\
) で改行できる。 - エクスポートするファイルシステムは、それぞれ 1 行で指定する。
- 許可するホストの一覧は、エクスポートするファイルシステムの後に空白文字を追加し、その後に追加する。
- 各ホストのオプションは、ホストの識別子の直後に括弧を追加し、その中に指定する。ホストと最初の括弧の間には空白を使用しない。
エクスポートエントリー
エクスポートするファイルシステムの各エントリーは、以下のように指定します。
export host(options)
各ホストにそれぞれオプションを付けて、複数のホストを 1 行で指定することもできます。この場合は、以下のように、各ホスト名の後に、そのホストに対するオプションを括弧を付けて追加します。ホストは空白文字で区切ります。
export host1(options1) host2(options2) host3(options3)
この構造では、次のようになります。
- export
- エクスポートするディレクトリー
- host
- エクスポートを共有するホストまたはネットワーク
- options
- ホストに使用されるオプション
例5.1 簡潔な /etc/exports ファイル
最も簡単な方法は、/etc/exports
ファイルに、エクスポートするディレクトリーと、そのディレクトリーへのアクセスを許可するホストを指定することです。
/exported/directory bob.example.com
ここで、bob.example.com
は、NFS サーバーから /exported/directory/
をマウントできます。この例ではオプションが指定されていないため、NFS はデフォルトのオプションを使用します。
/etc/exports
ファイルの形式では、特に空白文字の使用が非常に厳しく扱われます。ホストからエクスポートするファイルシステムの間、そしてホスト同士の間には、必ず空白文字を挿入してください。また、それ以外の場所 (コメント行を除く) には、空白文字を追加しないでください。
たとえば、以下の 2 つの行は意味が異なります。
/home bob.example.com(rw) /home bob.example.com (rw)
最初の行は、bob.example.com
からのユーザーにのみ、/home
ディレクトリーへの読み取り/書き込みアクセスを許可します。2 番目の行では、bob.example.com
からのユーザーにディレクトリーを読み取り専用 (デフォルト) でマウントすることを許可し、その他のユーザーに読み取り/書き込みでマウントすることを許可します。
デフォルトのオプション
エクスポートエントリーのデフォルトオプションは次のとおりです。
ro
- エクスポートするファイルシステムは読み取り専用です。リモートホストは、このファイルシステムで共有されているデータを変更できません。このファイルシステムで変更 (読み取り/書き込み) を可能にするには、rw オプションを指定します。
sync
-
NFS サーバーは、以前の要求で発生した変更がディスクに書き込まれるまで、要求に応答しません。代わりに非同期書き込みを有効にするには、
async
オプションを指定します。 wdelay
-
NFS サーバーは、別の書き込み要求が差し迫っていると判断すると、ディスクへの書き込みを遅らせます。これにより、複数の書き込みコマンドが同じディスクにアクセスする回数を減らすことができるため、書き込みのオーバーヘッドが低下し、パフォーマンスが向上します。これを無効にするには、
no_wdelay
オプションを指定します。これは、デフォルトの sync オプションが指定されている場合に限り利用できます。 root_squash
(ローカルからではなく) リモートから接続している root ユーザーが root 権限を持つことを阻止します。代わりに、そのユーザーには、NFS サーバーにより、ユーザー ID
nobody
が割り当てられます。これにより、リモートの root ユーザーの権限を、最も低いローカルユーザーレベルにまで下げて (squash)、高い確率でリモートサーバーへの書き込む権限を与えないようにすることができます。この root squashing を無効にするには、no_root_squash
オプションを指定します。(root を含む) すべてのリモートユーザーの権限を下げるには、
all_squash
オプションを使用します。特定ホストのリモートユーザーに対して、NFS サーバーが割り当てるユーザー ID とグループ ID を指定するには、anonuid
オプションとanongid
オプションを以下のように使用します。export host(anonuid=uid,anongid=gid)
uid と gid は、それぞれユーザー ID とグループ ID の番号になります。
anonuid
オプションとanongid
オプションにより、共有するリモート NFS ユーザー用に、特別なユーザーアカウントおよびグループアカウントを作成できます。
Red Hat Enterprise Linux の NFS では、デフォルトでアクセス制御リスト (ACL) に対応しています。この機能を無効にするには、ファイルシステムをエクスポートする際に no_acl
オプションを指定します。
デフォルトオプションと上書きオプション
エクスポートするすべてのファイルシステムの各デフォルトは、明示的に上書きする必要があります。たとえば、rw
オプションを指定しないと、エクスポートするファイルシステムが読み取り専用として共有されます。以下は、/etc/exports
の例になりますが、ここでは 2 つのデフォルトオプションを上書きします。
/another/exported/directory 192.168.0.3(rw,async)
この例では、192.168.0.3
は /another/exported/directory/
の読み書きをマウントでき、ディスクへの書き込みはすべて非同期になります。
5.6.2. exportfs ユーティリティー
root ユーザーは、exportfs
ユーティリティーを使用すると、NFS サービスを再起動せずにディレクトリーを選択してエクスポートまたはアンエクスポートできます。適切なオプションが指定されると、exportfs
ユーティリティーは、エクスポートされたファイルシステムを /var/lib/nfs/xtab
に書き込みます。ファイルシステムへのアクセス権を決定する際には、nfs-mountd
サービスが xtab
ファイルを参照するため、エクスポートしたファイルシステムのリストの変更が直ちに反映されます。
一般的な exportfs オプション
exportfs
で利用できる一般的なオプションの一覧は以下のようになります。
-r
-
/var/lib/nfs/etab
に新しいエクスポート一覧を作成して、/etc/exports
に一覧表示されているディレクトリーをすべてエクスポートします。このオプションにより、/etc/exports
に変更が加えられると、エクスポート一覧が効果的に更新されます。 -a
-
exportfs
に渡されるその他のオプションに応じて、すべてのディレクトリーをエクスポートするかどうかを判断します。その他のオプションが指定されていないと、exportfs
は、/etc/exports
で指定されたすべてのファイルシステムをエクスポートします。 -o file-systems
-
/etc/exports
内に記載されていない、エクスポートされるディレクトリーを指定します。file-systems の部分を、エクスポートされる追加のファイルシステムに置き換えます。これらのファイルシステムは、/etc/exports
で指定されたものと同じフォーマットでなければなりません。このオプションは、多くの場合、エクスポートされるファイルシステムの一覧に永続的に追加する前に、エクスポートされるファイルシステムをテストするために使用されます。 -i
-
/etc/exports
を無視します。コマンドラインで指定されたオプションのみが、エクスポート用ファイルシステムの定義に使用されます。 -u
-
すべての共有ディレクトリーをエクスポートしなくなります。
exportfs -ua
コマンドは、すべての NFS サービスを稼働状態に維持しながら、NFS ファイル共有を保留します。NFS 共有を再度有効にするには、exportfs -r
を使用します。 -v
-
詳細な表示です。
exportfs
コマンドを実行するときに表示されるエクスポート、または非エクスポートのファイルシステムの情報が、より詳細に表示されます。
exportfs
ユーティリティーにオプションが渡されていない場合は、現在エクスポートされているファイルシステムのリストが表示されます。
関連情報
5.7. NFS および rpcbind
本セクションでは、NFSv3 で必要とされる rpcbind
サービスの目的を説明します。
rpcbind
サービスは、RPC (Remote Procedure Call) サービスを、そのサービスがリッスンするポートにマッピングします。RPC のプロセスが開始すると、その開始が rpcbind
に通知され、そのプロセスがリッスンしているポートと、そのプロセスが処理することが予想される RPC プログラム番号が登録されます。クライアントシステムは、特定の RPC プログラム番号でサーバーの rpcbind
と通信します。rpcbind
サービスは、クライアントを適切なポート番号にリダイレクトし、要求されたサービスと通信できるようにします。
RPC ベースのサービスは、rpcbind
を使用して、クライアントの受信要求で接続を確立します。したがって、RPC ベースのサービスが起動する前に、rpcbind
を利用可能な状態にする必要があります。
rpcbind
のアクセス制御ルールは、すべての RPC ベースのサービスに影響します。あるいは、NFS RPC デーモンごとにアクセス制御ルールを指定することもできます。
関連情報
-
rpc.mountd(8)
man page -
rpc.statd(8)
man page
5.8. NFS のインストール
この手順では、NFS 共有のマウントまたはエクスポートに必要なすべてのパッケージをインストールします。
手順
nfs-utils
パッケージをインストールします。# yum install nfs-utils
5.9. NFS サーバーの起動
この手順では、NFS 共有をエクスポートするために必要な NFS サーバーの起動方法を説明します。
前提条件
NFSv3 の接続に対応しているサーバーで、
rpcbind
サービスを実行している。rpcbind
がアクティブであることを確認するには、次のコマンドを実行します。$ systemctl status rpcbind
サービスが停止している場合は、起動して有効にします。
$ systemctl enable --now rpcbind
手順
システムの起動時に、NFS サーバーを起動して自動的に起動するようにするには、次のコマンドを使用します。
# systemctl enable --now nfs-server
関連情報
5.10. NFS と rpcbind のトラブルシューティング
rpcbind
サービスでは通信に使用するポート番号と RPC サービス間の調整を行うため、トラブルシューティングを行う際は、rpcbind
を使用して現在の RPC サービスの状態を表示させると便利です。rpcinfo
ユーティリティーは、RPC ベースの各サービスとそのポート番号、RPC プログラム番号、バージョン番号、および IP プロトコルタイプ (TCP または UDP) が表示されます。
手順
rpcbind
に対して適切な RPC ベースの NFS サービスが有効になっていることを確認するには、次のコマンドを実行します。# rpcinfo -p
例5.2 rpcinfo -p コマンドの出力
以下に、上記コマンドの出力例を示します。
program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 20048 mountd 100005 1 tcp 20048 mountd 100005 2 udp 20048 mountd 100005 2 tcp 20048 mountd 100005 3 udp 20048 mountd 100005 3 tcp 20048 mountd 100024 1 udp 37769 status 100024 1 tcp 49349 status 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 3 tcp 2049 nfs_acl 100021 1 udp 56691 nlockmgr 100021 3 udp 56691 nlockmgr 100021 4 udp 56691 nlockmgr 100021 1 tcp 46193 nlockmgr 100021 3 tcp 46193 nlockmgr 100021 4 tcp 46193 nlockmgr
NFS サービスの 1 つが正しく起動しないと、
rpcbind
は、そのサービスに対するクライアントからの RPC 要求を、正しいポートにマッピングできません。多くの場合は、NFS が
rpcinfo
の出力に表示されていない時に NFS を再起動すると、サービスがrpcbind
に正しく登録され、動作を開始します。# systemctl restart nfs-server
関連情報
5.11. ファイアウォールの背後で動作するように NFS サーバーを設定する手順
NFS には rpcbind
サービスが必要です。このサービスは RPC サービスのポートを動的に割り当て、ファイアウォールルールの設定で問題が発生する可能性があります。以下のセクションでは、サポートが必要な場合に、ファイアウォールの内側で機能するように NFS バージョンを設定する方法を説明します。
NFSv3
これには、NFSv3 をサポートするサーバーがすべて含まれます。
- NFSv3 専用サーバー
- NFSv3 と NFSv4 の両方に対応するサーバー
- NFSv4 専用
5.11.1. ファイアウォールの内側で動作するように NFSv3 対応サーバーを設定する手順
次の手順では、NFSv3 に対応するサーバーを設定し、ファイアウォールの内側で実行する方法を説明します。これには、NFSv3 専用サーバー、および NFSv3 と NFSv4 の両方をサポートするサーバーが含まれます。
手順
クライアントがファイアウォールの背後にある NFS 共有にアクセスできるようにするには、NFS サーバーで次のコマンドを実行してファイアウォールを設定します。
firewall-cmd --permanent --add-service mountd firewall-cmd --permanent --add-service rpc-bind firewall-cmd --permanent --add-service nfs
/etc/nfs.conf
ファイルで、RPC サービスnlockmgr
が使用するポートを次のように指定します。[lockd] port=tcp-port-number udp-port=udp-port-number
または、
/etc/modprobe.d/lockd.conf
ファイルで、nlm_tcpport
およびnlm_udpport
を指定することもできます。NFS サーバーで以下のコマンドを実行して、ファイアウォールで指定したポートを開きます。
firewall-cmd --permanent --add-port=<lockd-tcp-port>/tcp firewall-cmd --permanent --add-port=<lockd-udp-port>/udp
以下のように、
/etc/nfs.conf
ファイルの[statd]
セクションを編集して、rpc.statd
の静的ポートを追加します。[statd] port=port-number
NFS サーバーで以下のコマンドを実行して、ファイアウォールに追加したポートを開きます。
firewall-cmd --permanent --add-port=<statd-tcp-port>/tcp firewall-cmd --permanent --add-port=<statd-udp-port>/udp
ファイアウォール設定を再読み込みします。
firewall-cmd --reload
rpc-statd
サービスを最初に再起動してから、nfs-server
サービスを再起動します。# systemctl restart rpc-statd.service # systemctl restart nfs-server.service
または、
/etc/modprobe.d/lockd.conf
ファイルのlockd
ポートを指定した場合は、次のコマンドを実行します。/proc/sys/fs/nfs/nlm_tcpport
と/proc/sys/fs/nfs/nlm_udpport
の現在の値を更新します。# sysctl -w fs.nfs.nlm_tcpport=<tcp-port> # sysctl -w fs.nfs.nlm_udpport=<udp-port>
rpc-statd
サービスおよびnfs-server
サービスを再起動します。# systemctl restart rpc-statd.service # systemctl restart nfs-server.service
5.11.2. ファイアウォールの内側で実行されるように NFSv4 専用サーバーを設定する手順
次の手順では、NFSv4 専用サーバーをファイアウォールの内側で実行するように設定する方法を説明します。
手順
クライアントがファイアウォールの背後にある NFS 共有にアクセスできるようにするには、NFS サーバーで次のコマンドを実行してファイアウォールを設定します。
firewall-cmd --permanent --add-service nfs
ファイアウォール設定を再読み込みします。
firewall-cmd --reload
NFS サーバーを再起動します。
# systemctl restart nfs-server
5.11.3. ファイアウォールの内側で動作するように NFSv3 クライアントを設定する手順
ファイアウォールの内側で実行するように NFSv3 クライアントを設定する手順は、ファイアウォールの内側で実行するように NFSv3 サーバーを設定する手順と似ています。
設定するマシンが NFS クライアントとサーバーの両方である場合には、NFSv3 対応サーバーがファイアウォールの内側で実行されるように設定する手順 で説明されている手順に従います。
以下の手順では、ファイアウォールの内側でのみ NFS クライアントマシンを設定する方法を説明します。
手順
クライアントがファイアウォールの内側で NFS クライアントにコールバックを実行できるようにするには、NFS クライアントで以下のコマンドを実行して
rpc-bind
サービスをファイアウォールに追加します。firewall-cmd --permanent --add-service rpc-bind
/etc/nfs.conf
ファイルで、RPC サービスnlockmgr
が使用するポートを次のように指定します。[lockd] port=port-number udp-port=upd-port-number
または、
/etc/modprobe.d/lockd.conf
ファイルで、nlm_tcpport
およびnlm_udpport
を指定することもできます。NFS クライアントで以下のコマンドを実行して、ファイアウォールで指定したポートを開きます。
firewall-cmd --permanent --add-port=<lockd-tcp-port>/tcp firewall-cmd --permanent --add-port=<lockd-udp-port>/udp
以下のように、
/etc/nfs.conf
ファイルの[statd]
セクションを編集して、rpc.statd
の静的ポートを追加します。[statd] port=port-number
NFS クライアントで以下のコマンドを実行して、ファイアウォールに追加したポートを開きます。
firewall-cmd --permanent --add-port=<statd-tcp-port>/tcp firewall-cmd --permanent --add-port=<statd-udp-port>/udp
ファイアウォール設定を再読み込みします。
firewall-cmd --reload
rpc-statd
サービスを再起動します。# systemctl restart rpc-statd.service
または、
/etc/modprobe.d/lockd.conf
ファイルのlockd
ポートを指定した場合は、次のコマンドを実行します。/proc/sys/fs/nfs/nlm_tcpport
と/proc/sys/fs/nfs/nlm_udpport
の現在の値を更新します。# sysctl -w fs.nfs.nlm_tcpport=<tcp-port> # sysctl -w fs.nfs.nlm_udpport=<udp-port>
rpc-statd
サービスを再起動します。# systemctl restart rpc-statd.service
5.11.4. ファイアウォールの内側で動作するように NFSv4 クライアントを設定する手順
この手順は、クライアントが NFSv4.0 を使用している場合に限り行います。その場合は、NFSv4.0 コールバックのポートを開く必要があります。
この手順は、NFSv4.1 以降では必要ありません。これは、新しいプロトコルバージョンでは、クライアントによって開始された同じ接続でサーバーがコールバックを実行するためです。
手順
NFSv4.0 コールバックがファイアウォールを通過できるようにするには、以下のように
/proc/sys/fs/nfs/nfs_callback_tcpport
を設定して、サーバーがクライアントのそのポートに接続できるようにします。# echo "fs.nfs.nfs_callback_tcpport = <callback-port>" >/etc/sysctl.d/90-nfs-callback-port.conf # sysctl -p /etc/sysctl.d/90-nfs-callback-port.conf
NFS クライアントで以下のコマンドを実行して、ファイアウォールの指定のポートを開きます。
firewall-cmd --permanent --add-port=<callback-port>/tcp
ファイアウォール設定を再読み込みします。
firewall-cmd --reload
5.12. ファイアウォールからの RPC クォータのエクスポート
ディスククォータを使用するファイルシステムをエクスポートする場合は、クォータの RPC (Remote Procedure Call) サービスを使用して、NFS クライアントにディスククォータデータを提供できます。
手順
rpc-rquotad
サービスを有効にして起動します。# systemctl enable --now rpc-rquotad
注記rpc-rquotad
サービスが有効になっている場合は、nfs-server サービスが起動した後に自動的に起動されます。ファイアウォールの内側で、クォータの RPC サービスにアクセスできるようにするには、TCP (UDP が可能な場合は UDP) の 875 ポートを開く必要があります。デフォルトのポート番号は
/etc/services
ファイルで定義します。デフォルトのポート番号は、
/etc/sysconfig/rpc-rquotad
ファイルのRPCRQUOTADOPTS
変数に-p port-number
を追加すると上書きできます。-
デフォルトで、リモートホストはクォータのみを読み取ることができます。クライアントにクォータの設定を許可したい場合は、
/etc/sysconfig/rpc-rquotad
ファイルのRPCRQUOTADOPTS
変数に-S
オプションを追加します。 rpc-rquotad
を再起動して、/etc/sysconfig/rpc-rquotad
ファイルの変更を反映します。# systemctl restart rpc-rquotad
5.13. NFS over RDMA の有効化 (NFSoRDMA)
リモートダイレクトメモリーアクセス (RDMA) サービスは、Red Hat EnterpriseLinux 8 の RDMA 対応ハードウェアで自動的に機能します。
手順
rdma-core
パッケージをインストールします。# yum install rdma-core
xprtrdma
およびsvcrdma
の行が/etc/rdma/modules/rdma.conf
ファイルでコメント化されていることを確認します。# NFS over RDMA client support xprtrdma # NFS over RDMA server support svcrdma
NFS サーバーで、ディレクトリー
/mnt/nfsordma
を作成し、それを/etc/exports
にエクスポートします。# mkdir /mnt/nfsordma # echo "/mnt/nfsordma *(fsid=0,rw,async,insecure,no_root_squash)" >> /etc/exports
NFS クライアントで、サーバーの IP アドレスを使用して nfs-share をマウントします (例:
172.31.0.186)\
)。# mount -o rdma,port=20049 172.31.0.186:/mnt/nfs-share /mnt/nfs
nfs-server
サービスを再起動します。# systemctl restart nfs-server
関連情報
5.14. 関連情報
第6章 NFS のセキュア化
サーバーで NFS ファイルシステムをエクスポートする場合や、クライアントにマウントする際に、NFS セキュリティーリスクを最小限に抑え、サーバーのデータを保護するには、以下のセクションを検討してください。
6.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
などを使用します。 -
nft(8)
man ページ -
firewalld-cmd(1)
man ページ
6.2. AUTH_GSS
を使用した NFS セキュリティー
NFS の全バージョンは、RPCSEC_GSS および Kerberos のメカニズムに対応します。
AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、サーバーは、どのユーザーがそのファイルにアクセスしているかを正確に表すことをクライアントに依存しません。代わりに、暗号を使用してサーバーにユーザーを認証し、悪意のあるクライアントがそのユーザーの Kerberos 認証情報を持たずにユーザーになりすますことがないようにします。RPCSEC_GSS Kerberos メカニズムを使用することが、マウントを保護する最も簡単な方法になります。Kerberos の設定後は、追加の設定が不要になるためです。
6.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
- インテグリティー保護- ユーザー認証に Kerberos V5 を使用し、データの改ざんを防ぐために安全なチェックサムを使用して NFS 操作の整合性チェックを実行します。
krb5p
- プライバシー保護- ユーザー認証、整合性チェックに Kerberos V5 を使用し、トラフィックの傍受を防ぐため NFS トラフィックの暗号化を行います。これが最も安全な設定になりますが、パフォーマンスのオーバーヘッドも最も高くなります。
-
クライアントで、
sec=krb5
(もしくは設定に応じてsec=krb5i
またはsec=krb5p
) をマウントオプションに追加します。# mount -o sec=krb5 server:/export /mnt
関連情報
- krb5 セキュアな NFS で root としてファイルの作成推奨されません。
-
exports(5)
man ページ -
nfs(5)
man ページ
6.4. NFSv4 セキュリティーオプション
NFSv4 には、Microsoft Windows NT モデルの機能や幅広い導入の経緯があるため、POSIX モデルではなく、Microsoft Windows NT モデルをベースとした ACL サポートが含まれます。
NFSv4 のもう 1 つの重要なセキュリティー機能は、ファイルシステムのマウントに MOUNT
プロトコルを使用しなくなることです。MOUNT
プロトコルは、プロトコルがファイルを処理する方法により、セキュリティー上のリスクが発生します。
6.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 を取得します。
第7章 NFS での pNFS SCSI レイアウトの有効化
データのアクセスに pNFS SCSI レイアウトを使用するように、NFS サーバーおよびクライアントを設定できます。pNFS SCSI は、ファイルへの長期接続のシングルクライアントアクセスに伴うユースケースで利点があります。
前提条件
- クライアントとサーバーの両方で、SCSI コマンドを同じブロックデバイスに送信する必要があります。つまり、ブロックデバイスは共有 SCSI バス上になければなりません。
- ブロックデバイスに XFS ファイルシステムが含まれている必要があります。
- SCSI デバイスは、 SCSI-3 Primary Commands 仕様で説明されているように、SCSI Persistent Reservation に対応している必要があります。
7.1. pNFS テクノロジー
pNFS アーキテクチャーでは、NFS のスケーラビリティーが改善されます。サーバーに pNFS が実装されると、クライアントは複数のサーバーで同時にデータにアクセスできるようになります。これにより、パフォーマンスが向上します。
pNFS は、RHEL では以下のストレージプロトコルまたはレイアウトに対応しています。
- ファイル
- Flexfiles
- SCSI
7.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 サーバーで、手動で永続予約を削除する必要があります。
7.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
) ビットが設定されるようにします。例7.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
関連情報
-
sg_persist(8)
man page
7.4. サーバーで pNFS SCSI の設定
この手順では、NFS サーバーが pNFS SCSI レイアウトをエクスポートするように設定します。
手順
- サーバーで、SCSI デバイスで作成した XFS ファイルシステムをマウントします。
NFS バージョン 4.1 以降をエクスポートするように NFS サーバーを設定します。
/etc/nfs.conf
ファイルの[nfsd]
セクションに、以下のオプションを設定します。[nfsd] vers4.1=y
pnfs
オプションを指定して、NFS で XFS ファイルシステムをエクスポートするように NFS サーバーを設定します。例7.2 pNFS SCSI をエクスポートする /etc/exports のエントリー
/etc/exports
設定ファイルの以下のエントリーにより、/exported/directory/
にマウントされているファイルシステムを、pNFS SCSI レイアウトとしてallowed.example.com
クライアントにエクスポートします。/exported/directory allowed.example.com(pnfs)
注記エクスポートしたファイルシステムを、パーティションだけでなく、ブロックデバイス全体に作成する必要があります。
関連情報
7.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 ファイルシステムを直接マウントしないでください。
関連情報
7.6. サーバーでの pNFS SCSI 予約の解放
この手順では、NFS サーバーが SCSI デバイスを維持している永続的な予約を解放します。これにより、pNFS SCSI をエクスポートする必要がなくなったら、SCSI デバイスを別の目的で使用できるようになります。
サーバーから予約を削除する必要があります。別の IT Nexus から削除することはできません。
前提条件
以下のコマンドで、
sg3-utils
パッケージがインストールされている。# yum install sg3_utils
手順
サーバーで、既存の予約をクエリーします。
# sg_persist --read-reservation path-to-scsi-device
例7.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
例7.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
関連情報
-
sg_persist(8)
man page
第8章 Squid キャッシングプロキシーサーバーの設定
Squid は、コンテンツをキャッシュして帯域幅を削減し、Web ページをより迅速に読み込むプロキシーサーバーです。本章では、HTTP、HTTPS、FTP のプロトコルのプロキシーとして Squid を設定する方法と、アクセスの認証および制限を説明します。
8.1. 認証なしで Squid をキャッシングプロキシーとして設定
本セクションでは、認証なしでキャッシュプロキシーとして Squid の基本設定を説明します。以下の手順では、IP 範囲に基づいてプロキシーへのアクセスを制限します。
前提条件
-
/etc/squid/squid.conf
ファイルが、squid
パッケージにより提供されている。このファイルを編集した場合は、ファイルを削除して、パッケージを再インストールしている。
手順
squid
パッケージをインストールします。# yum install squid
/etc/squid/squid.conf
ファイルを編集します。localnet
アクセス制御リスト (ACL) を、プロキシーを使用できる 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
デフォルトでは、設定には
http_access deny !Safe_ports
ルールが含まれ、Safe_ports
ACL で定義されていないポートへのアクセス拒否を定義します。cache_dir
パラメーターにキャッシュの種類、キャッシュディレクトリーへのパス、キャッシュサイズ、さらにキャッシュの種類ごとの設定を設定します。cache_dir ufs /var/spool/squid 10000 16 256
この設定により、以下が可能になります。
-
Squid は、
ufs
キャッシュタイプを使用します。 -
Squid は、キャッシュを
/var/spool/squid/
ディレクトリーに保存します。 -
キャッシュのサイズが
10000
MB まで大きくなります。 -
Squid は、
16
個の レベル 1 サブディレクトリーを/var/spool/squid/
ディレクトリーに作成します。 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
ファイルが現在のディレクトリーにダウンロードされている場合は、プロキシーが動作します。
8.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
デフォルトでは、設定には
http_access deny !Safe_ports
ルールが含まれ、Safe_ports
ACL で定義されていないポートへのアクセス拒否を定義します。cache_dir
パラメーターにキャッシュの種類、キャッシュディレクトリーへのパス、キャッシュサイズ、さらにキャッシュの種類ごとの設定を設定します。cache_dir ufs /var/spool/squid 10000 16 256
この設定により、以下が可能になります。
-
Squid は、
ufs
キャッシュタイプを使用します。 -
Squid は、キャッシュを
/var/spool/squid/
ディレクトリーに保存します。 -
キャッシュのサイズが
10000
MB まで大きくなります。 -
Squid は、
16
個の レベル 1 サブディレクトリーを/var/spool/squid/
ディレクトリーに作成します。 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
を返すと、認証に成功しました。
8.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 file
は、キータブファイルへのパスを設定します。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
デフォルトでは、設定には
http_access deny !Safe_ports
ルールが含まれ、Safe_ports
ACL で定義されていないポートへのアクセス拒否を定義します。cache_dir
パラメーターにキャッシュの種類、キャッシュディレクトリーへのパス、キャッシュサイズ、さらにキャッシュの種類ごとの設定を設定します。cache_dir ufs /var/spool/squid 10000 16 256
この設定により、以下が可能になります。
-
Squid は、
ufs
キャッシュタイプを使用します。 -
Squid は、キャッシュを
/var/spool/squid/
ディレクトリーに保存します。 -
キャッシュのサイズが
10000
MB まで大きくなります。 -
Squid は、
16
個の レベル 1 サブディレクトリーを/var/spool/squid/
ディレクトリーに作成します。 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...
8.4. Squid でのドメイン拒否リストの設定
多くの場合、管理者は特定のドメインへのアクセスをブロックする必要があります。本セクションでは、Squid でドメインの拒否リストを設定する方法を説明します。
前提条件
- Squid が設定され、ユーザーはプロキシーを使用できます。
手順
/etc/squid/squid.conf
ファイルを編集し、以下の設定を追加します。acl domain_deny_list dstdomain "/etc/squid/domain_deny_list.txt" http_access deny all domain_deny_list
重要ユーザーまたはクライアントへのアクセスを許可する最初の
http_access allow
ステートメントの前にこれらのエントリーを追加します。/etc/squid/domain_deny_list.txt
ファイルを作成し、ブロックするドメインを追加します。たとえば、サブドメインを含むexample.com
へのアクセスをブロックして、example.net
をブロックするには、以下を追加します。.example.com example.net
重要squid 設定の
/etc/squid/domain_deny_list.txt
ファイルを参照している場合は、このファイルは空にすることはできません。このファイルが空の場合、Squid は起動できません。squid
サービスを再開します。# systemctl restart squid
8.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
enforcing モードで SELinux を実行した場合は、ポートを
squid_port_t
ポートタイプ定義に割り当てます。# semanage port -a -t squid_port_t -p tcp port_number
semanage
ユーティリティーがシステムで利用できない場合は、policycoreutils-python-utils
パッケージをインストールします。
squid
サービスを再開します。# systemctl restart squid
8.6. 関連情報
-
設定パラメーター
usr/share/doc/squid-<version>/squid.conf.documented
第9章 データベースサーバー
9.1. データベースサーバーの概要
データベースサーバーは、データベース管理システム (DBMS) の機能を提供するサービスです。DBMS は、データベース管理のためのユーティリティーを提供し、エンドユーザー、アプリケーション、およびデータベースと対話します。
Red Hat Enterprise Linux 8 は、以下のデータベース管理システムを提供します。
- MariaDB 10.3
- MariaDB 10.5 - RHEL 8.4 以降で利用できます。
- MySQL 8.0
- PostgreSQL 10
- PostgreSQL 9.6
- PostgreSQL 12 - RHEL 8.1.1 以降利用できます。
- PostgreSQL 13: RHEL 8.4 以降で利用できます。
9.2. MariaDB の使用
MariaDB サーバーは、MySQL テクノロジーに基づくオープンソースの高速で堅牢なデータベースサーバーです。ここでは、RHEL システムに MariaDB をインストールして設定する方法、MariaDB データをバックアップする方法、MariaDB の以前のバージョンから移行する方法、および MariaDB Galera クラスター を使用してデータベースを複製する方法について説明します。
9.2.1. MariaDB の概要
MariaDB は、データを構造化情報に変換して、データにアクセスする SQL インターフェイスを提供するリレーショナルデータベースです。これには、複数のストレージエンジンとプラグイン、および地理的な情報システム (GIS) および JSON (JavaScript Object Notation) 機能が含まれます。
Red Hat Enterprise Linux 8 の場合は、以下を説明します。
- MariaDB のインストールで、MariaDB サーバーをインストールする方法について。
- MariaDB の設定 の MariaDB 設定を調整する方法
- MariaDB データのバックアップ の MariaDB データのバックアップ方法
- MariaDB 10.3 への移行 の RHEL 7 のデフォルトバージョン MariaDB 5.5 から RHEL 8 のデフォルトバージョン MariaDB 10.3 へ移行する方法。
- MariaDB 10.3 から MariaDB 10.5 へのアップグレード の RHEL 8 内で MariaDB 10.3 から MariaDB 10.5 へアップグレードする方法
- Galera で MariaDB を複製するで、MariaDB Galera クラスター を使用したデータベースの複製方法について。
9.2.2. MariaDB のインストール
RHEL 8 では、MariaDB サーバーは、それぞれ個別のストリームにより提供される以下のバージョンで利用できます。
- MariaDB 10.3
- MariaDB 10.5 - RHEL 8.4 以降で利用できます。
MariaDB をインストールするには、以下の手順を行います。
手順
mariadb
モジュールからストリーム (バージョン) を選択し、server
プロファイルを指定して MariaDB サーバーパッケージをインストールします。以下に例を示します。# yum module install mariadb:10.3/server
mariadb
サービスを起動します。# systemctl start mariadb.service
mariadb
サービスが、システムの起動時に起動するようにします。# systemctl enable mariadb.service
MariaDB 10.3 に推奨: MariaDB をインストールする際のセキュリティーを向上させるには、次のコマンドを実行します。
$ mysql_secure_installation
このコマンドは、完全にインタラクティブなスクリプトを起動して、プロセスの各ステップのプロンプトを表示します。このスクリプトを使用すると、次の方法でセキュリティーを改善できます。
- root アカウントのパスワードの設定
- 匿名ユーザーの削除
リモート root ログインの拒否 (ローカルホスト外)
注記mysql_secure_installation スクリプトは、MariaDB 10.5 以降では価値がなくなりました。セキュリティーの強化は、MariaDB 10.5 以降のデフォルトの動作の一部です。
RPM パッケージが競合しているため、RHEL 8 では MariaDB および MySQL データベースサーバーを同時にインストールすることはできません。RHEL 7 用の Red Hat Software Collections では、コンポーネントの同時インストールが可能です。RHEL 8 では、コンテナー内で異なるバージョンのデータベースサーバーを使用できます。
9.2.3. MariaDB の設定
MariaDB サーバーをネットワーク用に設定するには、以下の手順に従います。
手順
/etc/my.cnf.d/mariadb-server.cnf
ファイルの[mysqld]
セクションを編集します。以下の設定ディレクティブを設定できます。bind-address
: サーバーがリッスンするアドレスです。設定可能なオプションは以下のとおりです。- ホスト名
- IPv4 アドレス
- IPv6 アドレス
skip-networking
: サーバーが TCP/IP 接続をリッスンするかどうかを制御します。以下の値が使用できます。- 0 - すべてのクライアントをリッスンする
- 1 - ローカルクライアントのみをリッスンする
-
port
: MariaDB が TCP/IP 接続をリッスンするポート。
mariadb
サービスを再起動します。# systemctl restart mariadb.service
9.2.4. MariaDB サーバーでの TLS 暗号化の設定
デフォルトでは、MariaDB は暗号化されていない接続を使用します。安全な接続のために、MariaDB サーバーで TLS サポートを有効にし、暗号化された接続を確立するようにクライアントを設定します。
9.2.4.1. MariaDB サーバーに CA 証明書、サーバー証明書、および秘密鍵を配置する
MariaDB サーバーで TLS 暗号化を有効にする前に、認証局 (CA) 証明書、サーバー証明書、および秘密鍵を MariaDB サーバーに保存します。
前提条件
Privacy Enhanced Mail(PEM) 形式の以下のファイルがサーバーにコピーされています。
-
サーバーの秘密鍵:
server.example.com.key.pem
-
サーバー証明書:
server.example.com.crt.pem
-
認証局 (CA) 証明書:
ca.crt.pem
秘密鍵および証明書署名要求 (CSR) の作成や、CA からの証明書要求に関する詳細は、CA のドキュメントを参照してください。
-
サーバーの秘密鍵:
手順
CA およびサーバー証明書を
/etc/pki/tls/certs/
ディレクトリーに保存します。# mv <path>/server.example.com.crt.pem /etc/pki/tls/certs/ # mv <path>/ca.crt.pem /etc/pki/tls/certs/
MariaDB サーバーがファイルを読み込めるように、CA およびサーバー証明書にパーミッションを設定します。
# chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem
証明書は、セキュアな接続が確立される前は通信の一部であるため、任意のクライアントは認証なしで証明書を取得できます。そのため、CA およびサーバーの証明書ファイルに厳密なパーミッションを設定する必要はありません。
サーバーの秘密鍵を
/etc/pki/tls/private/
ディレクトリーに保存します。# mv <path>/server.example.com.key.pem /etc/pki/tls/private/
サーバーの秘密鍵にセキュアなパーミッションを設定します。
# chmod 640 /etc/pki/tls/private/server.example.com.key.pem # chgrp mysql /etc/pki/tls/private/server.example.com.key.pem
承認されていないユーザーが秘密鍵にアクセスできる場合は、MariaDB サーバーへの接続は安全ではなくなります。
SELinux コンテキストを復元します。
# restorecon -Rv /etc/pki/tls/
9.2.4.2. MariaDB サーバーでの TLS の設定
セキュリティーを向上させるには、MariaDB サーバーで TLS サポートを有効にします。その結果、クライアントは TLS 暗号化を使用してサーバーでデータを送信できます。
前提条件
- MariaDB サーバーをインストールしている。
-
mariadb
サービスが実行している。 Privacy Enhanced Mail(PEM) 形式の以下のファイルがサーバー上にあり、
mysql
ユーザーが読み取りできます。-
サーバーの秘密鍵:
/etc/pki/tls/private/server.example.com.key.pem
-
サーバー証明書:
/etc/pki/tls/certs/server.example.com.crt.pem
-
認証局 (CA) 証明書
/etc/pki/tls/certs/ca.crt.pem
-
サーバーの秘密鍵:
- サーバー証明書のサブジェクト識別名 (DN) またはサブジェクトの別名 (SAN) フィールドは、サーバーのホスト名と一致します。
手順
/etc/my.cnf.d/mariadb-server-tls.cnf
ファイルを作成します。以下の内容を追加して、秘密鍵、サーバー、および CA 証明書へのパスを設定します。
[mariadb] ssl_key = /etc/pki/tls/private/server.example.com.key.pem ssl_cert = /etc/pki/tls/certs/server.example.com.crt.pem ssl_ca = /etc/pki/tls/certs/ca.crt.pem
証明書失効リスト (CRL) がある場合は、それを使用するように MariaDB サーバーを設定します。
ssl_crl = /etc/pki/tls/certs/example.crl.pem
必要に応じて、MariaDB 10.5.2 以降を実行する場合は、暗号化せずに接続を拒否できます。この機能を有効にするには、以下を追加します。
require_secure_transport = on
必要に応じて、MariaDB 10.4.6 以降を実行する場合は、サーバーが対応する TLS バージョンを設定できます。たとえば、TLS 1.2 および TLS 1.3 をサポートするには、以下を追加します。
tls_version = TLSv1.2,TLSv1.3
デフォルトでは、サーバーは TLS 1.1、TLS 1.2、および TLS 1.3 をサポートします。
mariadb
サービスを再起動します。# systemctl restart mariadb
検証
トラブルシューティングを簡素化するには、ローカルクライアントが TLS 暗号化を使用するように設定する前に、MariaDB サーバーで以下の手順を実行します。
MariaDB で TLS 暗号化が有効になっていることを確認します。
# mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'have_ssl';" +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | have_ssl | YES | +---------------+-----------------+
have_ssl
変数がyes
に設定されている場合、TLS 暗号化が有効になります。MariaDB サービスが特定の TLS バージョンのみをサポートするように設定している場合は、
tls_version
変数を表示します。# mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'tls_version';" +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tls_version | TLSv1.2,TLSv1.3 | +---------------+-----------------+
9.2.4.3. 特定のユーザーアカウントに TLS で暗号化された接続を要求する
機密データにアクセスできるユーザーは、ネットワーク上で暗号化されていないデータ送信を回避するために、常に TLS で暗号化された接続を使用する必要があります。
すべての接続にセキュアなトランスポートが必要なサーバーで設定できない場合は (require_secure_transport = on
)、TLS 暗号化を必要とするように個別のユーザーアカウントを設定します。
前提条件
- MariaDB サーバーで TLS サポートが有効になっている。
- セキュアなトランスポートを必要とするように設定するユーザーが存在する。
手順
管理ユーザーとしてMariaDB サーバーに接続します。
# mysql -u root -p -h server.example.com
管理ユーザーがリモートでサーバーにアクセスする権限を持たない場合は、MariaDB サーバーでコマンドを実行し、
localhost
に接続します。REQUIRE SSL
句を使用して、ユーザーが TLS 暗号化接続を使用して接続する必要があるよう強制します。MariaDB [(none)]> **ALTER USER __'example__'@__'%'__ REQUIRE SSL;**
検証
TLS 暗号化を使用して、
example
ユーザーとしてサーバーに接続します。# mysql -u example -p -h server.example.com --ssl ... MariaDB [(none)]>
エラーが表示されず、インタラクティブな MariaDB コンソールにアクセスできる場合は、TLS との接続は成功します。
TLS を無効にして、
example
ユーザーとして接続を試みます。# mysql -u example -p -h server.example.com --skip-ssl ERROR 1045 (28000): Access denied for user 'example'@'server.example.com' (using password: YES)
このユーザーに TLS が必要だが無効になっているため、サーバーはログインの試行を拒否しました (
--skip-ssl
)。
9.2.5. MariaDB クライアントでの TLS 暗号化のグローバルな有効化
MariaDB サーバーが TLS 暗号化に対応している場合は、安全な接続のみを確立し、サーバー証明書を検証するようにクライアントを設定します。この手順では、サーバー上のすべてのユーザーで TLS サポートを有効にする方法を説明します。
9.2.5.1. デフォルトで TLS 暗号化を使用するように MariaDB クライアントを設定する
RHEL では、MariaDB クライアントが TLS 暗号化を使用するようにグローバルに設定でき、サーバー証明書の Common Name (CN) が、ユーザーが接続するホスト名と一致することを検証します。これにより、man-in-the-middle 攻撃 (中間者攻撃) を防ぎます。
前提条件
- MariaDB サーバーで TLS サポートが有効になっている。
- サーバー証明書を発行した認証局 (CA) が RHEL で信頼されていない場合は、CA 証明書がクライアントにコピーされています。
手順
RHEL が、サーバー証明書を発行した CA を信頼しない場合は、以下を行います。
CA 証明書を
/etc/pki/ca-trust/source/anchors/
ディレクトリーにコピーします。# cp <path>/ca.crt.pem /etc/pki/ca-trust/source/anchors/
すべてのユーザーが CA 証明書ファイルを読み取りできるようにするパーミッションを設定します。
# chmod 644 /etc/pki/ca-trust/source/anchors/ca.crt.pem
CA 信頼データベースを再構築します。
# update-ca-trust
以下の内容で
/etc/my.cnf.d/mariadb-client-tls.cnf
ファイルを作成します。[client-mariadb] ssl ssl-verify-server-cert
これらの設定は、MariaDB クライアントが TLS 暗号化 (
ssl
) を使用し、クライアントがホスト名をサーバー証明書 (ssl-verify-server-cert
) の CN と比較することを定義します。
検証
ホスト名を使用してサーバーに接続し、サーバーの状態を表示します。
# mysql -u root -p -h server.example.com -e status ... SSL: Cipher in use is TLS_AES_256_GCM_SHA384
SSL
エントリーにCipher in use is…
が含まれている場合、接続は暗号化されています。このコマンドで使用するユーザーには、リモートで認証するパーミッションがあることに注意してください。
接続するホスト名がサーバーの TLS 証明書のホスト名と一致しない場合、
ssl-verify-server-cert
パラメーターにより接続が失敗します。たとえば、localhost
に接続する場合は、以下のようになります。# mysql -u root -p -h localhost -e status ERROR 2026 (HY000): SSL connection error: Validation of SSL server certificate failed
関連情報
-
mysql(1)
man ページの--ssl*
パラメーターの説明。
9.2.6. MariaDB データのバックアップ
Red Hat EnterpriseLinux 8 で MariaDB データベースからデータをバックアップする主な方法は 2 つあります。
- 論理バックアップ
- 物理バックアップ
論理バックアップ は、データの復元に必要な SQL ステートメントで設定されます。この種類のバックアップは、情報およびレコードをプレーンテキストファイルにエクスポートします。
物理バックアップに対する論理バックアップの主な利点は、移植性と柔軟性です。データは、物理バックアップではできない他のハードウェア設定である MariaDB バージョンまたはデータベース管理システム (DBMS) で復元できます。
mariadb.service
が稼働している場合は、論理バックアップを実行できることに注意してください。論理バックアップには、ログと設定ファイルが含まれません。
物理バックアップ は、コンテンツを格納するファイルおよびディレクトリーのコピーで設定されます。
物理バックアップは、論理バックアップと比較して、以下の利点があります。
- 出力が少なくなる。
- バックアップのサイズが小さくなる。
- バックアップおよび復元が速くなる。
- バックアップには、ログファイルと設定ファイルが含まれる。
mariadb.service
が実行していない場合や、データベースのすべてのテーブルがロックされていて、バックアップ中に変更しないようにする場合は、物理バックアップを実行する必要があります。
以下のいずれかの MariaDB バックアップ方法で、MariaDB データベースのデータのバックアップを使用できます。
-
mysqldump
を使用した論理バックアップ -
Mariabackup
ユーティリティーを使用した物理的なオンラインバックアップ - ファイルシステムのバックアップ
- バックアップソリューションとしてレプリケーションを使用
9.2.6.1. mysqldump を使用した論理バックアップの実行
mysqldump クライアントはバックアップユーティリティーで、バックアップ目的でデータベースまたはデータベースの集合をダンプしたり、別のデータベースサーバーに転送したりできます。通常、mysqldump の出力は、サーバーテーブル構造を再作成する、それにデータを取り込む、またはその両方の SQL ステートメントで設定されます。mysqldump は、XML および (CSV などの) コンマ区切りテキスト形式など、他の形式でファイルを生成することもできます。
mysqldump バックアップを実行するには、以下のいずれかのオプションを使用できます。
- 選択したデータベースを 1 つまたは複数バックアップ
- すべてのデータベースをバックアップする。
- あるデータベースのテーブルのサブセットのバックアップを作成する。
手順
単一のデータベースをダンプするには、以下を実行します。
# mysqldump [options] --databases db_name > backup-file.sql
複数のデータベースを一度にダンプするには、次のコマンドを実行します。
# mysqldump [options] --databases db_name1 [db_name2 …] > backup-file.sql
すべてのデータベースをダンプするには、以下を実行します。
# mysqldump [options] --all-databases > backup-file.sql
1 つ以上のダンプされたフルデータベースをサーバーにロードし直すには、以下を実行します。
# mysql < backup-file.sql
データベースをリモート MariaDB サーバーにロードするには、以下を実行します。
# mysql --host=remote_host < backup-file.sql
あるデータベースでテーブルのサブセットをダンプするには、
mysqldump
コマンドの末尾に、選択したテーブルの一覧を追加します。# mysqldump [options] db_name [tbl_name …] > backup-file.sql
1 つのデータベースからダンプされたテーブルのサブセットをロードするには、以下を実行します。
# mysql db_name < backup-file.sql
注記この時点で、db_name データベースが存在している必要があります。
mysqldump がサポートするオプションの一覧を表示するには、以下を実行します。
$ mysqldump --help
関連情報
- mysqldump を使用した論理バックアップの詳細は、MariaDB のドキュメント を参照してください。
9.2.6.2. Mariabackup ユーティリティーを使用した物理的なオンラインバックアップの実行
Mariabackup は、Percona XtraBackup テクノロジーをベースとしたユーティリティーです。これにより、InnoDB、Aria、および MyISAM テーブルの物理的なオンラインバックアップを実行できます。このユーティリティーは、AppStream リポジトリーから mariadb-backup
パッケージで提供されます。
Mariabackup は、MariaDB サーバーの完全バックアップ機能に対応します。これには、暗号化されたデータおよび圧縮データが含まれます。
前提条件
mariadb-backup
パッケージがシステムにインストールされている。# yum install mariadb-backup
- Mariabackup には、バックアップを実行するユーザーの認証情報を指定する必要があります。認証情報はコマンドラインまたは設定ファイルで指定できます。
-
Mariabackup のユーザーは、
RELOAD
、LOCK TABLES
、およびREPLICATION CLIENT
の権限が必要です。
Mariabackup を使用してデータベースのバックアップを作成するには、以下の手順を行います。
手順
コマンドラインで認証情報を提供する間にバックアップを作成するには、以下を実行します。
$ mariabackup --backup --target-dir <backup_directory> --user <backup_user> --password <backup_passwd>
target-dir
オプションは、バックアップファイルを格納するディレクトリーを定義します。完全バックアップを実行する場合は、ターゲットディレクトリーが空であるか、存在しない必要があります。ユーザー
オプションおよびパスワード
オプションにより、ユーザー名とパスワードを設定できます。設定ファイルに認証情報を設定してバックアップを作成するには、次のコマンドを実行します。
-
/etc/my.cnf.d/
ディレクトリーに設定ファイルを作成します (例:/etc/my.cnf.d/mariabackup.cnf
)。 以下の行を新規ファイルの
[xtrabackup]
セクションまたは[mysqld]
セクションに追加します。[xtrabackup] user=myuser password=mypassword
バックアップを実行します。
$ mariabackup --backup --target-dir <backup_directory>
-
Mariabackup は、設定ファイルの [mariadb]
セクションのオプションは読み込みません。MariaDB サーバーにデフォルト以外のデータディレクトリーが指定されている場合は、Mariabackup がデータディレクトリーを見つけることができるように、設定ファイルの [xtrabackup]
セクションまたは [mysqld]
セクションでこのディレクトリーを指定する必要があります。
デフォルト以外のデータディレクトリーを指定するには、MariaDB 設定ファイルの [xtrabackup]
セクションまたは [mysqld]
セクションに以下の行を追加します。
datadir=/var/mycustomdatadir
9.2.6.3. Mariabackup ユーティリティーを使用したデータの復元
バックアップが完了したら、mariabackup
コマンドに以下のいずれかのオプションを使用して、バックアップからデータを復元できます。
-
--copy-back
を使用すると、元のバックアップファイルを保持できます。 -
--move-back
は、バックアップファイルをデータディレクトリーに移動し、元のバックアップファイルを削除します。
Mariabackup ユーティリティーを使用してデータを復元するには、以下の手順に従います。
前提条件
mariadb
サービスが実行されていないことを確認します。# systemctl stop mariadb.service
- データディレクトリーが空であることを確認します。
-
Mariabackup のユーザーは、
RELOAD
、LOCK TABLES
、およびREPLICATION CLIENT
の権限が必要です。
手順
mariabackup
コマンドを実行します。データを復元し、元のバックアップファイルを保持するには、
--copy-back
オプションを使用します。$ mariabackup --copy-back --target-dir=/var/mariadb/backup/
データを復元し、元のバックアップファイルを削除するには、
--move-back
オプションを使用します。$ 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
9.2.6.4. ファイルシステムのバックアップの実行
MariaDB データファイルのファイルシステムバックアップを作成するには、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
バックアップされたデータをバックアップ場所から
/var/lib/mysql
ディレクトリーに読み込む際は、mysql:mysql
が/var/lib/mysql
内のすべてのデータの所有者であることを確認してください。# chown -R mysql:mysql /var/lib/mysql
9.2.6.5. バックアップソリューションとしてレプリケーションを使用
レプリケーションは、ソースサーバー用の代替バックアップソリューションです。ソースサーバーの複製となるレプリカサーバーを作成すると、ソースに影響を与えずにレプリカでバックアップを実行できます。ソースは、レプリカをシャットダウンする間に依然として実行でき、レプリカからデータのバックアップを作成できます。
レプリケーション自体は、バックアップソリューションとしては十分ではありません。レプリケーションは、ハードウェア障害からソースサーバーを保護しますが、データ損失に対する保護は保証していません。この方法とともに、レプリカでその他のバックアップソリューションを使用することが推奨されます。
9.2.7. MariaDB 10.3 への移行
RHEL 7 には、MySQL データベースファミリーからのサーバーのデフォルトの実装として、MariaDB 5.5 が同梱されています。新しいバージョンの MariaDB データベースサーバーは、RHEL 7 の Software Collections として利用できます。RHEL 8 は、MariaDB 10.3、MariaDB 10.5、および MySQL 8.0 を提供します。
ここでは、MariaDB の RHEL 7 または Red Hat Software Collections バージョンから MariaDB 10.3 への移行を説明します。RHEL 8 内で MariaDB 10.3 から MariaDB 10.5 へ移行する場合は、MariaDB 10.3 から MariaDB 10.5 へのアップグレード を参照してください。
9.2.7.1. RHEL 7 と RHEL 8 のバージョンにおける MariaDB の主な相違点
MariaDB 5.5 および MariaDB 10.3 における最も重要な変更点を以下に示します。
- 10.1 以降、同期マルチソースクラスターのMariaDB Galera クラスター は、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 に移行するには、MariaDB への移行 の説明に従って複数の設定変更を実行する必要があります。
9.2.7.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 へ直接移行することもできますが、上記の移行ドキュメントに記載されている違いにより必要とされる設定変更をすべて実行する必要があります。
9.2.7.3. mysql_upgrade ユーティリティーを使用したインプレースアップグレード
データベースファイルを RHEL 8 に移行するには、RHEL 7 の MariaDB ユーザーは、mysql_upgrade
ユーティリティーを使用してインプレースアップグレードを実行する必要があります。mysql_upgrade
ユーティリティーは、mariadb-server-utils
サブパッケージにより提供され、mariadb-server
パッケージの依存関係としてインストールされます。
インプレースアップグレードを実行するには、RHEL 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.3
MariaDB 10.3 へのアップグレードは、バージョンごとに連続して行うことが推奨されます。移行は、Release Notes for Red Hat Software Collections で該当する章を参照してください。
RHEL 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
を除く)。
mysql_upgrade ユーティリティーを使用してアップグレード を実行するには、以下の手順を行います。
前提条件
- アップグレードを実行する前に、MariaDB データベースに保存されている全データのバックアップを作成します。
手順
RHEL 8 システムに
mariadb-server
パッケージがインストールされていることを確認します。# yum install mariadb-server
データのコピー時に、
mariadb
サービスがソースおよびターゲットのシステムで稼働していないことを確認します。# systemctl stop mariadb.service
-
ソースの場所から RHEL 8 ターゲットシステムの
/var/lib/mysql/
ディレクトリーにデータをコピーします。 ターゲットシステムでコピーされたファイルに適切なパーミッションと SELinux コンテキストを設定します。
# restorecon -vr /var/lib/mysql
ターゲットシステムで、MariaDB サーバーを起動します。
# systemctl start mariadb.service
mysql_upgrade
コマンドを実行して、内部テーブルをチェックし、修復します。$ mysql_upgrade
-
アップグレードが完了したら、
/etc/my.cnf.d/
ディレクトリー内のすべての設定ファイルに MariaDB 10.3 に対して有効なオプションのみが含まれていることを確認します。
インプレースアップグレードに関連する特定のリスクと既知の問題があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、MariaDB 10.3 Release Notes を参照してください。
9.2.8. MariaDB 10.3 から MariaDB 10.5 へのアップグレード
ここでは、RHEL 8 における MariaDB 10.3 から MariaDB 10.5 への移行について説明します。
9.2.8.1. MariaDB 10.3 と MariaDB 10.5 の主な相違点
MariaDB 10.3 と MariaDB 10.5 の間の重要な変更点には以下が含まれます。
-
MariaDB はデフォルトで
unix_socket
認証プラグインを使用するようになりました。このプラグインを使用すると、ローカルの UNIX ソケットファイルを介して MariaDB に接続する際に、オペレーティングシステムの資格情報を使用できます。 -
MariaDB
は、mariadb-*
という名前のバイナリーと、mariadb-*
バイナリーを指すmysql*
シンボリックリンクを追加します。たとえば、mysqladmin
、mysqlaccess
、およびmysqlshow
のシンボリックリンクは、mariadb-admin
、mariadb-access
、およびmariadb-show
のバイナリーをそれぞれポイントします。 -
各ユーザーロールに合わせて、
SUPER
特権が複数の特権に分割されました。その結果、一部のステートメントで必要な特権が変更されました。 -
並列のレプリケーションでは、
slave_parallel_mode
はデフォルトでoptimistic
に設定されるようになりました。 -
InnoDB ストレージエンジンで、変数のデフォルトが変更されました (
innodb_adaptive_hash_index
はOFF
へ、innodb_checksum_algorithm
はfull_crc32
へ変更)。 MariaDB は、以前使用された
readline
ライブラリーではなく、MariaDB コマンド履歴 (.mysql_history
ファイル) を管理する基盤となるソフトウェアのlibedit
実装を使用するようになりました。この変更は、.mysql_history
ファイルを直接使用しているユーザーに影響します。.mysql_history
は MariaDB または MySQL アプリケーションによって管理されるファイルであるため、ユーザーは直接ファイルでは機能しないことに注意してください。人間が判読可能な外観は偶然です。注記セキュリティーを強化するために、履歴ファイルの維持を考慮することができます。コマンド履歴の記録を無効にするには、以下を実行します。
-
存在する場合は、
.mysql_history
ファイルを削除します。 以下のいずれかの方法を使用します。
-
MYSQL_HISTFILE
変数を/dev/null
に設定し、これをシェルの起動ファイルに追加します。 .mysql_history
ファイルを/dev/null
へのシンボリックリンクに変更します。$ ln -s /dev/null $HOME/.mysql_history
-
-
存在する場合は、
MariaDB Galera クラスター がバージョン 4 にアップグレードされ、以下の主な変更点が加えられました。
- Galera は、サイズ制限なしのトランザクションの複製をサポートする、新しいストリーミングレプリケーション機能を追加します。ストリーミングレプリケーションの実行時に、クラスターは小さなフラグメントでトランザクションを複製します。
- Galera が Global Transaction ID (GTID) に完全に対応するようになりました。
-
/etc/my.cnf.d/galera.cnf
ファイルのwsrep_on
オプションのデフォルト値が1
から0
に変更され、エンドユーザーが必要な追加オプションを設定せずにwsrep
レプリケーションを開始できないようにします。
MariaDB 10.5 の PAM プラグインへの変更には、以下が含まれます。
-
MariaDB 10.5 は、PAM (Pluggable Authentication Modules) プラグインの新バージョンを追加します。PAM プラグインバージョン 2.0 は、個別の
setuid root
ヘルパーバイナリーを使用して PAM 認証を実行します。これにより、MariaDB が追加の PAM モジュールを使用できるようになります。 -
ヘルパーバイナリーは、
mysql
グループのユーザーによってのみ実行できます。デフォルトでは、グループにはmysql
ユーザーのみが含まれます。Red Hat では、このヘルパーユーティリティーを介してスロットルまたはログの記録をせずにパスワード推測攻撃を防ぐために、管理者がmysql
グループにユーザーをさらに追加しないことを推奨しています。 -
MariaDB 10.5 では、プラグ可能な認証モジュール (PAM) プラグインとその関連ファイルが新しいパッケージ
mariadb-pam
に移動しました。したがって、MariaDB
に PAM 認証を使用しないシステムに、新しいsetuid root
バイナリーが導入されることはありません。 -
mariadb-pam
パッケージには、両方の PAM プラグインバージョンが含まれています。バージョン 2.0 はデフォルトで、バージョン 1.0 はauth_pam_v1
共有オブジェクトライブラリーとして利用できます。 -
MariaDB サーバーでは、
mariadb-pam
パッケージはデフォルトでインストールされません。MariaDB 10.5 で PAM 認証プラグインを利用できるようにするには、mariadb-pam
パッケージを手動でインストールします。
9.2.8.2. RHEL 8 バージョンの MariaDB 10.3 から MariaDB 10.5 へのアップグレード
この手順では、yum
および mariadb-upgrade
ユーティリティーを使用して、mariadb:10.3
モジュールストリームから mariadb:10.5
モジュールストリームにアップグレードする方法を説明します。
mariadb-upgrade
ユーティリティーは、mariadb-server-utils
サブパッケージにより提供され、mariadb-server
パッケージの依存関係としてインストールされます。
前提条件
- アップグレードを実行する前に、MariaDB データベースに保存されている全データのバックアップを作成します。
手順
MariaDB サーバーを停止します。
# systemctl stop mariadb.service
以下のコマンドを実行して、後続のストリームに切り替えるためのシステムの準備が整っているかどうかを判断します。
# yum distro-sync
このコマンドは、Nothing to do.Complete! のメッセージで終了する必要があります。詳細は、後続のストリームへの切り替え を参照してください。
システムで
mariadb
モジュールをリセットします。# yum module reset mariadb
新しい
mariadb:10.5
モジュールストリームを有効にします。# yum module enable mariadb:10.5
インストール済みパッケージを同期し、ストリーム間の変更を実行します。
# yum distro-sync
これにより、インストールされている MariaDB パッケージがすべて更新されます。
-
/etc/my.cnf.d/
にあるオプションファイルに MariaDB 10.5 に対して有効なオプションのみが含まれるように、設定を調整します。詳細は、MariaDB 10.4 および MariaDB 10.5 のアップストリームドキュメントを参照してください。 MariaDB サーバーを起動します。
スタンドアロンを実行しているデータベースをアップグレードする場合:
# systemctl start mariadb.service
Galera クラスターノードをアップグレードする場合:
# galera_new_cluster
mariadb
サービスが自動的に起動します。
mariadb-upgrade ユーティリティーを実行して、内部テーブルをチェックし、修復します。
スタンドアロンを実行しているデータベースをアップグレードする場合:
# mariadb-upgrade
Galera クラスターノードをアップグレードする場合:
# mariadb-upgrade --skip-write-binlog
インプレースアップグレードに関連する特定のリスクと既知の問題があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、MariaDB 10.5 Release Notes を参照してください。
9.2.9. Galera で MariaDB を複製する
本セクションでは、Red Hat Enterprise Linux 8 の Galera ソリューションを使用して、MariaDB データベースを複製する方法を説明します。
9.2.9.1. MariaDB Galera クラスターの概要
Galera レプリケーションは、複数の MariaDB サーバーで設定される同期マルチソース MariaDB Galera クラスター の作成に基づいています。レプリカが通常読み取り専用である従来のプライマリー/レプリカ設定とは異なり、MariaDB Galera クラスターのノードはすべて書き込み可能にすることができます。
Galera レプリケーションと MariaDB データベースとの間のインターフェイスは、書き込みセットレプリケーション API (wsrep API) で定義されます。
MariaDB Galera クラスター の主な機能は以下のとおりです。
- 同期のレプリケーション
- アクティブ/アクティブのマルチソーストポロジー
- クラスターノードへの読み取りおよび書き込み
- 自動メンバーシップ制御、失敗したノードのクラスターからの削除
- 自動ノードの参加
- 行レベルの並列レプリケーション
- ダイレクトクライアント接続: ユーザーはクラスターノードにログインし、レプリケーションの実行中にノードを直接操作できます。
同期レプリケーションとは、サーバーがトランザクションに関連付けられた書き込みセットをクラスター内のすべてのノードにブロードキャストすることで、コミット時にトランザクションをレプリケートすることを意味します。クライアント (ユーザーアプリケーション) はデータベース管理システム (DBMS) に直接接続し、ネイティブの MariaDB と同様の動作が発生します。
同期レプリケーションは、クラスター内の 1 つのノードで発生した変更が、クラスター内の他のノードで同時に発生することを保証します。
そのため、同期レプリケーションには、非同期のレプリケーションと比べて次のような利点があります。
- 特定のクラスターノード間の変更の伝播に遅延がない
- すべてのクラスターノードには常に一貫性がある
- いずれかのクラスターノードがクラッシュしても、最新の変更は失われない
- すべてのクラスターノードのトランザクションが並列に実行する
- クラスター全体にわたる因果関係
9.2.9.2. MariaDB Galera クラスターを構築するためのコンポーネント
MariaDB Galera クラスター を構築するには、システムに以下のパッケージをインストールする必要があります。
-
mariadb-server-galera
: MariaDB Galera クラスター のサポートファイルとスクリプトが含まれます。 -
mariadb-server
: MariaDB アップストリームがパッチを適用し、書き込みセットレプリケーション API (wsrep API) を組み込みます。この API は、Galera レプリケーションと MariaDB との間のインターフェイスを提供します。 galera
: MariaDB アップストリームがパッチを適用し、MariaDB の完全サポートを追加します。galera
パッケージには、以下の内容が含まれます。- Galera Replication Library は、レプリケーション機能全体を提供します。
- Galera Arbitrator ユーティリティーは、スプリットブレインのシナリオで投票に参加するクラスターメンバーとして使用できます。ただし、Galera Arbitrator は実際のレプリケーションには参加できません。
-
Galera Arbitrator ユーティリティーのデプロイに使用される Galera Systemd service および Galera wrapper script。RHEL 8 の MariaDB 10.3 および MariaDB 10.5 には、Red Hat バージョンの
garbd
systemd サービスと、/usr/lib/systemd/system/garbd.service
ファイルおよび/usr/sbin/garbd-wrapper
ファイルにそれぞれあるgalera
パッケージのラッパースクリプトが含まれています。RHEL 8.6 以降、MariaDB 10.3 および MariaDB 10.5 は、/usr/share/doc/galera/garb-systemd
および/usr/share/doc/galera/garbd.service
にあるこれらのファイルのアップストリームバージョンも提供するようになりました。
9.2.9.3. MariaDB Galera クラスターのデプロイメント
前提条件
mariadb
モジュールからストリーム (バージョン) を選択し、galera
プロファイルを指定して、MariaDB Galera クラスター パッケージをインストールします。以下に例を示します。# {PackageManagerCommand} module install mariadb:10.3/galera
これにより、以下のパッケージがインストールされます。
-
mariadb-server-galera
-
mariadb-server
galera
mariadb-server-galera
パッケージがmariadb-server
パッケージおよびgalera
パッケージを依存関係としてプルします。MariaDB Galera Cluster をビルドするためにインストールする必要があるパッケージについては、MariaDB クラスターをビルドするためのコンポーネント を参照してください。
-
MariaDB サーバーのレプリケーション設定は、システムを初めてクラスターに追加する前に更新する必要があります。
デフォルト設定は、
/etc/my.cnf.d/galera.cnf
ファイルで配布されます。MariaDB Galera クラスター をデプロイする前に、以下の文字列で開始するように、すべてのノードの
/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
その結果、ノードはクラスターに接続し、それ自体をクラスターの状態と同期します。
9.2.9.4. 新規ノードの MariaDB Galera クラスターへの追加
新規ノードを MariaDB Galera クラスター に追加するには、以下の手順に従います。
この手順に従って、既存のノードを再接続することもできます。
手順
特定のノードで、
/etc/my.cnf.d/galera.cnf
設定ファイルの[mariadb]
セクション内にあるwsrep_cluster_address
オプションで、1 つ以上の既存クラスターメンバーにアドレスを指定します。[mariadb] wsrep_cluster_address="gcomm://192.168.0.1"
新規ノードを既存クラスターノードのいずれかに接続すると、クラスター内のすべてのノードを表示できるようになります。
ただし、
wsrep_cluster_address
のクラスターの全ノードを表示することが推奨されます。したがって、1 つ以上のクラスターノードがダウンしても、その他のクラスターノードに接続することでノードがクラスターに参加できます。すべてのメンバーがメンバーシップに同意すると、クラスターの状態が変更します。新規ノードの状態がクラスターの状態と異なる場合、新しいノードは Incremental State Transfer (IST) または State Snapshot Transfer (SST) のいずれかを要求し、他のノードとの一貫性を確保します。
9.2.9.5. MariaDB Galera クラスターの再起動
すべてのノードを同時にシャットダウンすると、クラスターが終了し、実行中のクラスターは存在しなくなります。ただし、クラスターのデータは引き続き存在します。
クラスターを再起動するには、MariaDB Galera クラスターの設定の説明に従って、最初のノードをブートストラップします。
クラスターがブートストラップされず、最初のノードの mysqld
が systemctl start mariadb
コマンドでのみ起動した場合、ノードは /etc/my.cnf.d/galera.cnf
ファイルの wsrep_cluster_address
オプションに記載されている少なくとも 1 つのノードに接続しようとします。ノードが現在実行していない場合は、再起動に失敗します。
9.3. MySQL の使用
MySQL サーバーは、オープンソースの高速で堅牢なデータベースサーバーです。ここでは、RHEL システムに MySQL をインストールして設定する方法、MySQL データをバックアップする方法、MySQL の以前のバージョンから移行する方法、および MySQL を複製する方法について説明します。
9.3.1. MySQL を使い始める
MySQL は、データを構造化情報に変換して、データにアクセスする SQL インターフェイスを提供するリレーショナルデータベースです。これには、複数のストレージエンジンとプラグイン、および地理的な情報システム (GIS) および JSON (JavaScript Object Notation) 機能が含まれます。
ここでは、以下について説明します。
- MySQL のインストール で、MySQL サーバーをインストールする方法について。
- MySQL の設定 で、MySQL 設定を調整する方法について。
- MySQL データのバックアップ で、MySQL データをバックアップする方法について。
- MySQL 8.0 の RHEL 8 バージョンへの移行 で MySQL データを移行する方法。
- MySQL の複製 で、MySQL データベースを複製する方法について。
9.3.2. MySQL のインストール
RHEL 8 では、MySQL 8.0 サーバーは mysql:8.0
モジュールストリームとして利用できます。
MySQL をインストールするには、以下の手順に従います。
手順
mysql
モジュールから8.0
ストリーム (バージョン) を選択し、server
プロファイルを指定して、MySQL サーバーパッケージをインストールします。# yum module install mysql:8.0/server
mysqld
サービスを開始します。# systemctl start mysqld.service
mysqld
サービスを有効にして、起動時に起動するようにします。# systemctl enable mysqld.service
推奨手順: MySQL のインストール時にセキュリティーを強化するには、次のコマンドを実行します。
$ mysql_secure_installation
このコマンドは、完全にインタラクティブなスクリプトを起動して、プロセスの各ステップのプロンプトを表示します。このスクリプトを使用すると、次の方法でセキュリティーを改善できます。
- root アカウントのパスワードの設定
- 匿名ユーザーの削除
- リモート root ログインの拒否 (ローカルホスト外)
RPM パッケージが競合しているため、RHEL 8 では MySQL および MariaDB データベースサーバーを同時にインストールすることはできません。RHEL 7 用の Red Hat Software Collections では、コンポーネントの同時インストールが可能です。RHEL 8 では、コンテナー内で異なるバージョンのデータベースサーバーを使用できます。
9.3.3. MySQL の設定
MySQL サーバーをネットワーク用に設定するには、以下の手順に従います。
手順
/etc/my.cnf.d/mysql-server.cnf
ファイルの[mysqld]
セクションを編集します。以下の設定ディレクティブを設定できます。bind-address
: サーバーがリッスンするアドレスです。設定可能なオプションは以下のとおりです。- ホスト名
- IPv4 アドレス
- IPv6 アドレス
skip-networking
: サーバーが TCP/IP 接続をリッスンするかどうかを制御します。以下の値が使用できます。- 0 - すべてのクライアントをリッスンする
- 1 - ローカルクライアントのみをリッスンする
-
port
: MySQL が TCP/IP 接続をリッスンするポート。
mysqld
サービスを再起動します。# systemctl restart mysqld.service
9.3.4. MySQL データのバックアップ
Red Hat Enterprise Linux 8 でMySQL データベースからデータをバックアップする主な方法は 2 つあります。
- 論理バックアップ
- 物理バックアップ
論理バックアップ は、データの復元に必要な SQL ステートメントで設定されます。この種類のバックアップは、情報およびレコードをプレーンテキストファイルにエクスポートします。
物理バックアップに対する論理バックアップの主な利点は、移植性と柔軟性です。データは、物理バックアップではできない他のハードウェア設定である MySQL バージョンまたはデータベース管理システム (DBMS) で復元できます。
mysqld.service
が実行されている場合は、論理バックアップを実行できることに注意してください。論理バックアップには、ログと設定ファイルが含まれません。
物理バックアップ は、コンテンツを格納するファイルおよびディレクトリーのコピーで設定されます。
物理バックアップは、論理バックアップと比較して、以下の利点があります。
- 出力が少なくなる。
- バックアップのサイズが小さくなる。
- バックアップおよび復元が速くなる。
- バックアップには、ログファイルと設定ファイルが含まれる。
mysqld.service
が実行されていない場合、またはバックアップ中の変更を防ぐためにデータベース内のすべてのテーブルがロックされている場合は、物理バックアップを実行する必要があることに注意してください。
以下の MySQL バックアップアプローチのいずれかを使用して、MySQL データベースからデータをバックアップできます。
-
mysqldump
を使用した論理バックアップ - ファイルシステムのバックアップ
- バックアップソリューションとしてレプリケーションを使用
9.3.4.1. mysqldump を使用した論理バックアップの実行
mysqldump クライアントはバックアップユーティリティーで、バックアップ目的でデータベースまたはデータベースの集合をダンプしたり、別のデータベースサーバーに転送したりできます。通常、mysqldump の出力は、サーバーテーブル構造を再作成する、それにデータを取り込む、またはその両方の SQL ステートメントで設定されます。mysqldump は、XML および (CSV などの) コンマ区切りテキスト形式など、他の形式でファイルを生成することもできます。
mysqldump バックアップを実行するには、以下のいずれかのオプションを使用できます。
- 選択したデータベースを 1 つまたは複数バックアップ
- すべてのデータベースをバックアップする。
- あるデータベースのテーブルのサブセットのバックアップを作成する。
手順
単一のデータベースをダンプするには、以下を実行します。
# mysqldump [options] --databases db_name > backup-file.sql
複数のデータベースを一度にダンプするには、次のコマンドを実行します。
# mysqldump [options] --databases db_name1 [db_name2 ...] > backup-file.sql
すべてのデータベースをダンプするには、以下を実行します。
# mysqldump [options] --all-databases > backup-file.sql
1 つ以上のダンプされたフルデータベースをサーバーにロードし直すには、以下を実行します。
# mysql < backup-file.sql
データベースをリモート MySQL サーバーにロードするには、以下を実行します。
# mysql --host=remote_host < backup-file.sql
あるデータベースでテーブルのサブセットをダンプするには、
mysqldump
コマンドの末尾に、選択したテーブルの一覧を追加します。# mysqldump [options] db_name [tbl_name ...] > backup-file.sql
1 つのデータベースからダンプされたテーブルのサブセットをロードするには、以下を実行します。
# mysql db_name < backup-file.sql
注記この時点で、db_name データベースが存在している必要があります。
mysqldump がサポートするオプションの一覧を表示するには、以下を実行します。
$ mysqldump --help
9.3.4.2. ファイルシステムのバックアップの実行
MySQL データファイルのファイルシステムバックアップを作成するには、MySQL データディレクトリーの内容をバックアップ場所にコピーします。
現在の設定またはログファイルのバックアップも作成するには、以下の手順の中から任意の手順を選択します。
手順
mysqld
サービスを停止します。# systemctl stop mysqld.service
データファイルを必要な場所にコピーします。
# cp -r /var/lib/mysql /backup-location
必要に応じて、設定ファイルを必要な場所にコピーします。
# cp -r /etc/my.cnf /etc/my.cnf.d /backup-location/configuration
必要に応じて、ログファイルを必要な場所にコピーします。
# cp /var/log/mysql/* /backup-location/logs
mysqld
サービスを開始します。# systemctl start mysqld.service
バックアップされたデータをバックアップ場所から
/var/lib/mysql
ディレクトリーに読み込む際は、mysql:mysql
が/var/lib/mysql
内のすべてのデータの所有者であることを確認してください。# chown -R mysql:mysql /var/lib/mysql
9.3.4.3. バックアップソリューションとしてレプリケーションを使用
レプリケーションは、ソースサーバー用の代替バックアップソリューションです。ソースサーバーの複製となるレプリカサーバーを作成すると、ソースに影響を与えずにレプリカでバックアップを実行できます。ソースは、レプリカをシャットダウンする間に依然として実行でき、レプリカからデータのバックアップを作成できます。
MySQLデータベースを複製する方法の手順については、MySQL の複製 を参照してください。
レプリケーション自体は、バックアップソリューションとしては十分ではありません。レプリケーションは、ハードウェア障害からソースサーバーを保護しますが、データ損失に対する保護は保証していません。この方法とともに、レプリカでその他のバックアップソリューションを使用することが推奨されます。
9.3.5. MySQL 8.0 の RHEL 8 バージョンへの移行
RHEL 7 には、MySQL データベースファミリーからのサーバーのデフォルトの実装として、MariaDB 5.5 が同梱されています。RHEL 7 用の Red Hat Software Collections オファリングは、MySQL 8.0 と MariaDB のいくつかのバージョンを提供します。RHEL 8 は、MySQL 8.0、MariaDB 10.3、および MariaDB 10.5 を提供します。
この手順では、mysql_upgrade
ユーティリティーを使用した MySQL 8.0 の Red Hat Software Collections バージョンから MySQL 8.0 の RHEL8 バージョンへの移行について説明します。mysql_upgrade
ユーティリティーは、mysql-server
パッケージによって提供されます。
MySQLの Red Hat Software Collections バージョンでは、ソースデータディレクトリーは /var/opt/rh/rh-mysql80/lib/mysql/
です。RHEL 8 では、MySQL データは /var/lib/mysql/
ディレクトリーに保存されます。
前提条件
- アップグレードを実行する前に、MySQL データベースに保存されているすべてのデータをバックアップすること。
手順
mysql-server
パッケージが RHEL 8 システムにインストールされていることを確認します。# yum install mysql-server
データのコピー時に、
mysqld
サービスがソースシステムとターゲットシステムのどちらでも実行されていないことを確認してください。# systemctl stop mysqld.service
-
RHEL 7 ソースシステムの
/var/opt/rh/rh-mysql80/lib/mysql/
ディレクトリーから RHEL 8 ターゲットシステムの/var/lib/mysql/
ディレクトリーにデータをコピーします。 ターゲットシステムでコピーされたファイルに適切なパーミッションと SELinux コンテキストを設定します。
# restorecon -vr /var/lib/mysql
mysql:mysql
が、/var/lib/mysql
ディレクトリー内のすべてのデータの所有者であることを確認してください。# chown -R mysql:mysql /var/lib/mysql
ターゲットシステムで MySQL サーバーを起動します。
# systemctl start mysqld.service
注意: MySQL の以前のバージョンでは、内部テーブルをチェックおよび修復するために
mysql_upgrade
コマンドが必要でした。これは、サーバーの起動時に自動的に実行されるようになりました。
9.3.6. MySQL の複製
MySQL には、基本的なものから高度なものまで、レプリケーション用のさまざまな設定オプションが用意されています。このセクションでは、グローバルトランザクション識別子 (GTID) を使用して、新しくインストールした MySQL サーバーに MySQL でレプリケートするトランザクションベースの方法について説明します。GTID を使用すると、トランザクションの識別と整合性の検証が簡素化されます。
MySQL でレプリケーションを設定するには、以下を行う必要があります。
レプリケーションに既存の MySQL サーバーを使用する場合は、最初にデータを同期する必要があります。詳細は、アップストリームのドキュメント を参照してください。
9.3.6.1. MySQL ソースサーバーの設定
このセクションでは、MySQL ソースサーバーがデータベースサーバーで行われたすべての変更を適切に実行および複製するために必要な設定オプションについて説明します。
前提条件
- ソースサーバーがインストールされている。
手順
[mysqld]
セクションの/etc/my.cnf.d/mysql-server.cnf
ファイルに以下のオプションを含めます。bind-address=source_ip_adress
このオプションは、レプリカからソースへの接続に必要です。
server-id=id
id は一意である必要があります。
log_bin=path_to_source_server_log
このオプションは、MySQL ソースサーバーのバイナリーログファイルへのパスを定義します。例:
log_bin=/var/log/mysql/mysql-bin.log
gtid_mode=ON
このオプションは、サーバー上でグローバルトランザクション識別子 (GTID) を有効にします。
enforce-gtid-consistency=ON
サーバーは、GTID を使用して安全にログに記録できるステートメントのみの実行を許可することにより、GTID の整合性を強化します。
オプション:
binlog_do_db=db_name
選択したデータベースのみを複製する場合は、このオプションを使用します。選択した複数のデータベースを複製するには、各データベースを個別に指定します。
binlog_do_db=db_name1 binlog_do_db=db_name2 binlog_do_db=db_name3
オプション:
binlog_ignore_db=db_name
このオプションを使用して、特定のデータベースをレプリケーションから除外します。
mysqld
サービスを再起動します。# systemctl restart mysqld.service
9.3.6.2. MySQL レプリカサーバーの設定
このセクションでは、レプリケーションを成功させるために MySQL レプリカサーバーに必要な設定オプションについて説明します。
前提条件
- レプリカサーバーがインストールされている。
手順
[mysqld]
セクションの/etc/my.cnf.d/mysql-server.cnf
ファイルに以下のオプションを含めます。server-id=id
id は一意である必要があります。
relay-log=path_to_replica_server_log
リレーログは、レプリケーション中に MySQL レプリカサーバーによって作成されたログファイルのセットです。
log_bin=path_to_replica_sever_log
このオプションは、MySQL レプリカサーバーのバイナリーログファイルへのパスを定義します。例:
log_bin=/var/log/mysql/mysql-bin.log
このオプションはレプリカでは必須ではありませんが、強く推奨します。
gtid_mode=ON
このオプションは、サーバー上でグローバルトランザクション識別子 (GTID) を有効にします。
enforce-gtid-consistency=ON
サーバーは、GTID を使用して安全にログに記録できるステートメントのみの実行を許可することにより、GTID の整合性を強化します。
log-replica-updates=ON
このオプションにより、ソースサーバーから受信した更新がレプリカのバイナリーログに記録されます。
skip-replica-start=ON
このオプションは、レプリカサーバーの起動時に、レプリカサーバーがレプリケーションスレッドを開始しないようにします。
オプション:
binlog_do_db=db_name
特定のデータベースのみを複製する場合は、このオプションを使用します。複数のデータベースを複製するには、各データベースを個別に指定します。
binlog_do_db=db_name1 binlog_do_db=db_name2 binlog_do_db=db_name3
オプション:
binlog_ignore_db=db_name
このオプションを使用して、特定のデータベースをレプリケーションから除外します。
mysqld
サービスを再起動します。# systemctl restart mysqld.service
9.3.6.3. MySQL ソースサーバーでのレプリケーションユーザーの作成
レプリケーションユーザーを作成し、このユーザーにレプリケーショントラフィックに必要なパーミッションを付与する必要があります。この手順は、適切なパーミッションを持つレプリケーションユーザーを作成する方法を示しています。これらの手順は、ソースサーバーでのみ実行してください。
前提条件
- ソースサーバーは、MySQL ソースサーバーの設定 で説明されているように、インストールおよび設定されている。
手順
レプリケーションユーザーを作成します。
mysql> CREATE USER 'replication_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';
ユーザーにレプリケーション権限を付与します。
mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'replica_server_ip';
MySQL データベースの付与テーブルを再読み込みします。
mysql> FLUSH PRIVILEGES;
ソースサーバーを読み取り専用状態に設定します。
mysql> SET @@GLOBAL.read_only = ON;
9.3.6.4. レプリカサーバーをソースサーバーに接続する
MySQL レプリカサーバーでは、認証情報とソースサーバーのアドレスを設定する必要があります。次の手順を使用して、レプリカサーバーを実装します。
前提条件
- ソースサーバーは、MySQL ソースサーバーの設定 で説明されているように、インストールおよび設定されている。
- レプリカサーバーは、MySQL レプリカサーバーの設定 で説明されているように、インストールおよび設定されている。
- レプリケーションユーザーを作成している。MySQL ソースサーバーでのレプリケーションユーザーの作成 を参照してください。
手順
レプリカサーバーを読み取り専用状態に設定します。
mysql> SET @@GLOBAL.read_only = ON;
レプリケーションソースを設定します。
mysql> CHANGE REPLICATION SOURCE TO -> SOURCE_HOST='source_ip_address', -> SOURCE_USER='replication_user', -> SOURCE_PASSWORD='password', -> SOURCE_AUTO_POSITION=1;
MySQL レプリカサーバーでレプリカスレッドを開始します。
mysql> START REPLICA;
ソースサーバーとレプリカサーバーの両方で、読み取り専用状態の設定を解除します。
mysql> SET @@GLOBAL.read_only = OFF;
オプション: デバッグの目的で、レプリカサーバーのステータスを検査します。
mysql> SHOW REPLICA STATUS\G;
注記レプリカサーバーの起動または接続に失敗した場合は、
SHOW MASTER STATUS
コマンドの出力に表示されるバイナリーログファイルの位置に続く特定の数のイベ