Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

Red Hat Enterprise Linux 8

Web サーバーとリバースプロキシー、ネットワークファイルサービス、データベースサーバー、メールトランスポートエージェント、およびプリンターのセットアップと設定

概要

Red Hat Enterprise Linux 8 上で Apache HTTP Web サーバーまたは NGINX Web サーバーを設定して実行します。Samba や NFS などのネットワークファイルサービスを設定して使用します。MariaDB、MySQL、または PostgreSQL データベースサーバーをインストールして設定し、データをバックアップして移行します。Postfix メールトランスポートエージェントをデプロイして設定します。CUPS サーバーを使用した印刷を設定します。

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

Red Hat は質の高いドキュメントを提供することに尽力しており、皆様からのフィードバックを大切にしています。改善にご協力いただくため、Red Hat Jira トラッキングシステムを通じてご提案やエラー報告をお寄せください。

手順

  1. Jira の Web サイトにログインします。

    アカウントがない場合、アカウント作成オプションを選択します。

  2. 上部のナビゲーションバーで Create をクリックします。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. ダイアログの下部にある Create をクリックします。

第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 の詳細は、以下の表を参照してください。

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

    ListenFree [IP-address:]portnumber [protocol]

    MPM

    event、worker、prefork、mpm_winnt、mpm_netware、mpmt_os2

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

  • 以下のモジュールが削除されました。

  • 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 は起動後に設定ファイルを読み取ります。次の表に、設定ファイルの場所のリストを示します。

Expand
表1.2 httpd サービスの設定ファイル
パス説明

/etc/httpd/conf/httpd.conf

主要設定ファイル。

/etc/httpd/conf.d/

主要設定ファイル内に含まれている設定ファイル用の補助ディレクトリー。

/etc/httpd/conf.modules.d/

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 名ベースの仮想ホストの設定 を参照してください。

手順

  1. httpd パッケージをインストールします。 

    # yum install httpd

  2. firewalld を使用する場合は、ローカルのファイアウォールで TCP ポート 80 を開きます。 

    # firewall-cmd --permanent --add-port=80/tcp
# firewall-cmd --reload

  3. httpd サービスを有効にして起動します。 

    # systemctl enable --now httpd

  4. 必要に応じて、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 を指定して読み込むことができます。

1.7. Apache 名前ベースの仮想ホストの設定
リンクのコピー

名前ベースの仮想ホストを使用すると、Apache は、サーバーの IP アドレスに解決されるドメイン別に異なるコンテンツを提供できます。

別々のドキュメントルートディレクトリーを使用して、example.com ドメインと example.net ドメインの両方に仮想ホストを設定できます。どちらの仮想ホストも静的 HTML コンテンツを提供します。

前提条件

  • クライアントおよび Web サーバーは、example.com および example.net ドメインを Web サーバーの IP アドレスに解決します。

    これらのエントリーは DNS サーバーに手動で追加する必要がある点に注意してください。

手順

  1. httpd パッケージをインストールします。 

    # yum install httpd

  2. /etc/httpd/conf/httpd.conf ファイルを編集します。

    1. 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 アドレス対してに送信される要求も含まれます。

  3. 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>

  4. 両方の仮想ホストのドキュメントルートを作成します。 

    # mkdir /var/www/example.com/
# mkdir /var/www/example.net/

  5. 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 コマンドを実行する必要があります。

  6. firewalld を使用する場合は、ローカルのファイアウォールでポート 80 を開きます。 

    # firewall-cmd --permanent --add-port=80/tcp
# firewall-cmd --reload

  7. httpd サービスを有効にして起動します。 

    # systemctl enable --now httpd

検証

  1. 仮想ホストのドキュメントルートごとに異なるサンプルファイルを作成します。 

    # echo "vHost example.com" > /var/www/example.com/index.html
# echo "vHost example.net" > /var/www/example.net/index.html
  2. ブラウザーを使用して http://example.com に接続します。Web サーバーは、example.com 仮想ホストからのサンプルファイルを表示します。
  3. ブラウザーを使用して 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 を設定する方法を説明します。

手順

  1. サービスプリンシパルを作成し、HTTP/<SERVER_NAME>@realm プリンシパルの keytab ファイルへのアクセスを有効にします。 

    # ipa service-add HTTP/<SERVER_NAME>

  2. /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 ユーザーは異なります。

  3. 以下の内容で /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

  4. gssproxy サービスを再起動して、有効にします。 

    # systemctl restart gssproxy.service
# systemctl enable gssproxy.service

1.8.2. Apache HTTP Web サーバーが共有するディレクトリーに Kerberos 認証の設定
リンクのコピー

この手順では、/var/www/html/private/ ディレクトリーに Kerberos 認証を設定する方法を説明します。

前提条件

  • gssproxy サービスが設定され、実行されている。

手順

  1. /var/www/html/private/ ディレクトリーを保護するように mod_auth_gssapi を設定します。 

    <Location /var/www/html/private>
  AuthType GSSAPI
  AuthName "GSSAPI Login"
  Require valid-user
</Location>

  2. システムユニット設定のドロップインファイルを作成します。 

    # systemctl edit httpd.service

  3. 次のパラメーターをシステムのドロップインファイルに追加します。 

    [Service]
Environment=GSS_USE_PROXY=1

  4. systemd 設定をリロードします。 

    # systemctl daemon-reload

  5. httpd サービスを再起動します。 

    # systemctl restart httpd.service

検証

  1. Kerberos チケットを取得します。 

    # kinit
  2. ブラウザーで、保護されているディレクトリーの 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 サーバーで 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 アドレスに対して解決します。

手順

  1. mod_ssl パッケージをインストールします。 

    # yum install mod_ssl

  2. /etc/httpd/conf.d/ssl.conf ファイルを編集し、以下の設定を <VirtualHost _default_:443> ディレクティブに追加します。

    1. サーバー名を設定します。 

      ServerName example.com

サーバー名は、証明書の Common Name フィールドに設定されているエントリーと一致している必要があります。

  1. 必要に応じて、証明書の Subject Alt Names (SAN) フィールドに追加のホスト名が含まれる場合に、これらのホスト名にも TLS 暗号化を提供するように mod_ssl を設定できます。これを設定するには、ServerAliases パラメーターと対応する名前を追加します。 

    ServerAlias www.example.com server.example.com

  2. 秘密鍵、サーバー証明書、および CA 証明書へのパスを設定します。 

    SSLCertificateKeyFile "/etc/pki/tls/private/example.com.key"
SSLCertificateFile "/etc/pki/tls/certs/example.com.crt"
SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"

    1. セキュリティー上の理由から、root ユーザーのみが秘密鍵ファイルにアクセスできるように設定します。 

      # chown root:root /etc/pki/tls/private/example.com.key
# chmod 600 /etc/pki/tls/private/example.com.key
      警告

      秘密鍵に権限のないユーザーがアクセスした場合は、証明書を取り消し、新しい秘密鍵を作成し、新しい証明書を要求します。そうでない場合は、TLS 接続が安全ではなくなります。

    2. firewalld を使用する場合は、ローカルのファイアウォールでポート 443 を開きます。 

      # firewall-cmd --permanent --add-port=443/tcp
# firewall-cmd --reload

    3. 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 プロトコルのみに対応するように設定する場合。

前提条件

手順

  1. /etc/httpd/conf/httpd.conf ファイルを編集し、TLS プロトコルバージョンを設定する <VirtualHost> ディレクティブに以下の設定を追加します。たとえば、TLSv1.3 プロトコルのみを有効にするには、以下を実行します。 

    SSLProtocol -All TLSv1.3

  2. httpd サービスを再起動します。 

    # systemctl restart httpd

検証

  1. 以下のコマンドを使用して、サーバーが TLSv1.3 に対応していることを確認します。 

    # openssl s_client -connect example.com:443 -tls1_3

  2. 以下のコマンドを使用して、サーバーが 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
  3. 必要に応じて、他の TLS プロトコルバージョンのコマンドを繰り返し実行します。

1.9.3. Apache HTTP サーバーで対応している暗号の設定
リンクのコピー

デフォルトでは、Apache HTTP サーバーは、安全なデフォルト値を定義するシステム全体の暗号化ポリシーを使用します。これは、最近のブラウザーとも互換性があります。システム全体の暗号化で使用可能な暗号化のリストは、/etc/crypto-policies/back-ends/openssl.config ファイルを参照してください。

Apache HTTP Server がサポートする暗号を手動で設定できます。お使いの環境で特定の暗号が必要な場合は、以下の手順に従います。

前提条件

手順

  1. /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) を使用するすべての暗号を無効にします。

  2. httpd サービスを再起動します。 

    # systemctl restart httpd

検証

  1. Apache HTTP Server が対応する暗号化のリストを表示するには、以下を行います。

    1. nmap パッケージをインストールします。 

      # yum install nmap

    2. 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
...

1.10. TLS クライアント証明書認証の設定
リンクのコピー

クライアント証明書認証を使用すると、管理者は、証明書で認証したユーザーのみが Web サーバーのリソースにアクセスできるようにすることが可能です。/var/www/html/Example/ ディレクトリーにクライアント証明書認証を設定できます。

Apache HTTP Server が TLS 1.3 プロトコルを使用する場合、特定のクライアントには追加の設定が必要です。たとえば、Firefox で、about:config メニューの security.tls.enable_post_handshake_auth パラメーターを true に設定します。

前提条件

手順

  1. /etc/httpd/conf/httpd.conf ファイルを編集し、以下の設定をクライアント認証を設定する <VirtualHost> ディレクティブに追加します。 

    <Directory "/var/www/html/Example/">
  SSLVerifyClient require
</Directory>

    SSLVerifyClient require の設定では、/var/www/html/Example/ ディレクトリーのコンテンツにクライアントがアクセスする前に、サーバーがクライアント証明書を正常に検証する必要があることを定義します。

  2. httpd サービスを再起動します。 

    # systemctl restart httpd

検証

  1. 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 サーバーにクライアント証明書認証が必要であることを示しています。

  2. クライアントの秘密鍵と証明書、および 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) を提供します。

手順

  1. mod_security、mod_security_crs、および httpd パッケージをインストールします。 

    # yum install -y mod_security mod_security_crs httpd

  2. httpd サーバーを起動します。 

    # systemctl restart httpd

検証

  1. ModSecurity Web ベースアプリケーションファイアウォールが Apache HTTP サーバーで有効になっていることを確認します。 

    # httpd -M | grep security
 security2_module (shared)

  2. /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 がインストールされ、有効になっている。

手順

  1. 任意のテキストエディターで /etc/httpd/conf.d/mod_security.conf ファイルを開きます。以下はその例です。 

    # vi /etc/httpd/conf.d/mod_security.conf

  2. SecRuleEngine On で始まる行の後に、次のサンプルルールを追加します。 

    SecRule ARGS:data "@contains evil" "deny,status:403,msg:'param data contains evil data',id:1"

    前のルールでは、data パラメーターに evil の文字列が含まれている場合、ユーザーによるリソースの使用を禁止しています。

  3. 変更を保存し、エディターを終了します。

  4. httpd サーバーを再起動します。 

    # systemctl restart httpd

検証

  1. test.html ページを作成します。 

    # echo "mod_security test" > /var/www/html/test.html

  2. httpd サーバーを再起動します。 

    # systemctl restart httpd

  3. HTTP リクエストの GET 変数に悪意のあるデータが含まれない test.html をリクエストします。 

    $ curl http://localhost/test.html?data=good

mod_security test

  4. 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 do not have permission to access this resource.</p>
</body></html>

  5. /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 サーバーマニュアルのインストール
リンクのコピー

Apache HTTP Server のマニュアルをインストールできます。このマニュアルには、以下のような詳細なドキュメントが含まれます。

  • 設定パラメーターおよびディレクティブ
  • パフォーマンスチューニング
  • 認証設定
  • モジュール
  • コンテンツのキャッシュ
  • セキュリティーに関するヒント
  • TLS 暗号化の設定

マニュアルをインストールした後は、Web ブラウザーを使用して表示できます。

前提条件

  • Apache HTTP Server がインストールされ、実行している。

手順

  1. httpd-manual パッケージをインストールします。 

    # yum install httpd-manual

  2. オプション: デフォルトでは、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>

  3. httpd サービスを再起動します。 

    # systemctl restart httpd

検証

  1. 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 パッケージをインストールしている。

手順

  1. /etc/httpd/conf.modules.d/ ディレクトリーの設定ファイルでモジュール名を検索します。 

    # grep mod_ssl.so /etc/httpd/conf.modules.d/*

  2. モジュール名が見つかった設定ファイルを編集し、モジュールの LoadModule ディレクティブをコメント解除します。 

    LoadModule ssl_module modules/mod_ssl.so

  3. RHEL パッケージがモジュールを提供していないなどの理由でモジュールが見つからなかった場合は、次のディレクティブを使用して /etc/httpd/conf.modules.d/30-example.conf などの設定ファイルを作成します。 

    LoadModule ssl_module modules/<custom_module>.so

  4. httpd サービスを再起動します。 

    # systemctl restart httpd

1.13.2. カスタム Apache モジュールのコンパイル
リンクのコピー

独自のモジュールを作成し、モジュールのコンパイルに必要なインクルードファイル、ヘッダーファイル、および APache eXtenSion (apxs) ユーティリティーを含む httpd-devel パッケージを使用してビルドできます。

前提条件

  • httpd-devel パッケージがインストールされている。

手順

  • 次のコマンドでカスタムモジュールをビルドします。 

    # apxs -i -a -c module_name.c

検証

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 データベースに保存されます。

手順

  1. 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

    次の手順では、証明書のニックネームが必要です。

  2. 秘密鍵を抽出するには、鍵を PKCS #12 ファイルに一時的にエクスポートする必要があります。

    1. 秘密鍵に関連付けられた証明書のニックネームを使用して、鍵を 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 ファイルにパスワードを設定する必要があります。次の手順では、このパスワードが必要です。

    2. 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

    3. PKCS #12 の一時ファイルを削除します。 

      # rm /etc/pki/tls/private/export.p12

  3. /etc/pki/tls/private/server.key にパーミッションを設定し、root ユーザーのみがこのファイルにアクセスできるようにします。 

    # chown root:root /etc/pki/tls/private/server.key
# chmod 0600 /etc/pki/tls/private/server.key

  4. NSS データベースのサーバー証明書のニックネームを使用して CA 証明書をエクスポートします。 

    # certutil -d /etc/httpd/alias/ -L -n "Example Server Certificate" -a -o /etc/pki/tls/certs/server.crt

  5. /etc/pki/tls/certs/server.crt にパーミッションを設定し、root ユーザーのみがこのファイルにアクセスできるようにします。 

    # chown root:root /etc/pki/tls/certs/server.crt
# chmod 0600 /etc/pki/tls/certs/server.crt

  6. NSS データベースの CA 証明書のニックネームを使用して、CA 証明書をエクスポートします。 

    # certutil -d /etc/httpd/alias/ -L -n "Example CA" -a -o /etc/pki/tls/certs/ca.crt

  7. 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 に設定します。

第2章 NGINX の設定および設定
リンクのコピー

NGINX は、次のように使用できる高パフォーマンスなモジュラーサーバーです。

  • Web サーバー
  • リバースプロキシー
  • ロードバランサー

2.1. NGINX のインストールおよび準備
リンクのコピー

Red Hat は、アプリケーションストリームを使用して NGINX の異なるバージョンを提供します。以下を実行できます。

  • ストリームを選択し、NGINX をインストールします。
  • ファイアウォールで必要なポートを開きます。
  • nginx サービスの有効化および開始

デフォルト設定を使用すると、NGINX はポート 80 の Web サーバーとして実行され、/usr/share/nginx/html/ ディレクトリーからコンテンツを提供します。

前提条件

  • RHEL 8 がインストールされている。
  • ホストが Red Hat カスタマーポータルにサブスクライブしている。
  • firewalld サービスが有効になり、開始されました

手順

  1. 利用可能な 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

  2. デフォルト以外のストリームをインストールする場合は、そのストリームを選択します。 

    # yum module enable nginx:stream_version

  3. nginx パッケージをインストールします。 

    # yum install nginx

  4. NGINX がファイアウォールでサービスを提供するポートを開きます。たとえば、firewalld で HTTP (ポート 80) および HTTPS (ポート 443) のデフォルトポートを開くには、次のコマンドを実行します。 

    # firewall-cmd --permanent --add-port={80/tcp,443/tcp}
# firewall-cmd --reload

  5. nginx サービスがシステムの起動時に自動的に起動するようにします。 

    # systemctl enable nginx

  6. オプション: nginx サービスを起動します。 

    # systemctl start nginx

    デフォルト設定を使用しない場合は、この手順を省略し、サービスを起動する前に NGINX を適切に設定します。

重要

PHP モジュールには特定の NGINX バージョンが必要です。互換性のないバージョンを使用すると、新しい NGNIX ストリームにアップグレードするときに競合が発生する可能性があります。PHP 7.2 ストリームと NGNIX 1.24 ストリームを使用する場合は、NGINX をインストールする前に新しい PHP ストリーム 7.4 を有効にすることでこの問題を解決できます。

検証

  1. 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-rpms

  2. NGINX がサービスを提供するポートが firewalld で開いていることを確認します。 

    # firewall-cmd --list-ports
80/tcp 443/tcp

  3. nginx サービスが有効になっていることを確認します。 

    # systemctl is-enabled nginx
enabled

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 サーバーに手動で追加する必要がある点に注意してください。

手順

  1. /etc/nginx/nginx.conf ファイルを編集します。

    1. デフォルトでは、/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 コンテンツへのパスを設定します。

    2. 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 ディレクティブは、このドメインに別のエラーログファイルを定義します。

    3. 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;
}

  2. 両方のドメインのルートディレクトリーを作成します。 

    # mkdir -p /var/www/example.com/
# mkdir -p /var/www/example.net/

  3. 両方のルートディレクトリーに 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 コマンドを実行する必要があります。

  4. 両方のドメインのログディレクトリーを作成します。 

    # mkdir /var/log/nginx/example.com/
# mkdir /var/log/nginx/example.net/

  5. nginx サービスを再起動します。 

    # systemctl restart nginx

検証

  1. 仮想ホストのドキュメントルートごとに異なるサンプルファイルを作成します。 

    # 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
  2. ブラウザーを使用して http://example.com に接続します。Web サーバーは、/var/www/example.com/index.html ファイルからのサンプルコンテンツを表示します。
  3. ブラウザーを使用して http://example.net に接続します。Web サーバーは、/var/www/example.net/index.html ファイルからのサンプルコンテンツを表示します。
  4. ブラウザーを使用して 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 が、ローカルのファイアウォールで開放されている。

手順

  1. /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;
}

  2. セキュリティー上の理由から、root ユーザーのみが秘密鍵ファイルにアクセスできるように設定します。 

    # chown root:root /etc/pki/tls/private/example.com.key
# chmod 600 /etc/pki/tls/private/example.com.key
    警告

    秘密鍵に権限のないユーザーがアクセスした場合は、証明書を取り消し、新しい秘密鍵を作成し、新しい証明書を要求します。そうでない場合は、TLS 接続が安全ではなくなります。

  3. nginx サービスを再起動します。 

    # systemctl restart nginx

検証

  • ブラウザーを使用して、https://example.com に接続します。

2.4. HTTP トラフィックのリバースプロキシーとしての NGINX の設定
リンクのコピー

NGINX Web サーバーは、HTTP トラフィックのリバースプロキシーとして機能するように設定できます。たとえば、この機能を使用すると、リモートサーバーの特定のサブディレクトリーに要求を転送できます。クライアント側からは、クライアントはアクセス先のホストからコンテンツを読み込みます。ただし、NGINX は実際のコンテンツをリモートサーバーから読み込み、クライアントに転送します。

この手順では、Web サーバーの /example ディレクトリーへのトラフィックを、URL https://example.com に転送する方法を説明します。

前提条件

  • NGINX は、NGINX のインストールと準備 に記載されている手順に従ってインストールされます。
  • 必要に応じて、TLS 暗号化がリバースプロキシーで有効になっている。

手順

  1. /etc/nginx/nginx.conf ファイルを編集し、リバースプロキシーを提供する server ブロックに以下の設定を追加します。 

    location /example {
    proxy_pass https://example.com;
}

    location ブロックでは、NGINX が /example ディレクトリー内の全要求を https://example.com に渡すことを定義します。

  2. SELinux ブール値パラメーター httpd_can_network_connect を 1 に設定して、SELinux が NGINX がトラフィックを転送できるように設定します。 

    # setsebool -P httpd_can_network_connect 1

  3. nginx サービスを再起動します。 

    # systemctl restart nginx

検証

  • ブラウザーを使用して http://host_name/example に接続すると、https://example.com の内容が表示されます。

2.5. NGINX の HTTP ロードバランサーとしての設定
リンクのコピー

NGINX リバースプロキシー機能を使用してトラフィックを負荷分散できます。この手順では、HTTP ロードバランサーとして NGINX を設定して、アクティブな接続数が最も少ないサーバーがどれかを基にして、要求を異なるサーバーに送信する方法を説明します。どちらのサーバーも利用できない場合には、この手順でフォールバックを目的とした 3 番目のホストも定義します。

前提条件

手順

  1. /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: 無作為に選択されたサーバーに要求を送信します。

  2. nginx サービスを再起動します。 

    # systemctl restart nginx

第3章 Samba をサーバーとして使用
リンクのコピー

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

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

  • Active Directory (AD) または NT4 ドメインメンバー
  • スタンドアロンサーバー

  • NT4 プライマリードメインコントローラー (PDC) またはバックアップドメインコントローラー (BDC)

    注記

    Red Hat は、NT4 ドメインに対応する Windows バージョンの既存のインストールでのみ、PDC モードおよび BDC モードをサポートします。Red Hat では、新しい Samba NT4 ドメインを設定しないことを推奨します。これは、Windows 7 および Windows Server 2008 R2 以降の Microsoft オペレーティングシステムが NT4 ドメインに対応していないためです。

    Red Hat は、Samba を AD ドメインコントローラー (DC) として実行することはサポートしていません。

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

3.1. さまざまな Samba サービスおよびモードについて
リンクのコピー

samba パッケージは複数のサービスを提供します。環境と設定するシナリオに応じて、これらのサービスが 1 つ以上必要となり、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 設定が必要です。Samba を Active Directory と連携して使用する場合、AD 環境では DNS が名前解決を処理するため、相互運用性のために nmbd は必要ありません。

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 ドメインメンバーサーバーとして設定 を参照してください。

以下は、Samba サービスおよびユーティリティーによる設定の読み込み、再読み込み時を説明します。

  • Samba サービスは、設定を再読み込みする時:

    • 3 分ごとに自動更新
    • 手動要求の場合に smbcontrol all reload-config コマンドを実行するとします。
  • Samba クライアントユーティリティーは、起動時にのみ設定を読み取ります。

security などの特定のパラメーターの適用には、smb サービスの再起動が必要です。再読み込みだけでは十分ではないことに注意してください。

3.1.4. 安全な方法での Samba 設定の編集
リンクのコピー

Samba サービスは、3 分ごとに設定を自動的に再読み込みします。testparm ユーティリティーでの設定の検証前にサービスが変更を再読み込みしないように、安全な方法で Samba 設定を編集できます。

前提条件

  • Samba がインストールされている。

手順

  1. /etc/samba/smb.conf ファイルのコピーを作成します。 

    # cp /etc/samba/smb.conf /etc/samba/samba.conf.copy
  2. コピーして作成したファイルを編集し、必要な変更を加えます。

  3. /etc/samba/samba.conf.copy ファイルの設定を確認します。 

    # testparm -s /etc/samba/samba.conf.copy

    testparm がエラーを報告した場合は、修正してもう一度コマンドを実行します。

  4. /etc/samba/smb.conf ファイルを新しい設定に上書きします。 

    # mv /etc/samba/samba.conf.copy /etc/samba/smb.conf

  5. 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 ファイルが存在する。

手順

  1. 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 マッピングの設定が報告されます。

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

3.3. Samba をスタンドアロンサーバーとして設定
リンクのコピー

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

3.3.1. スタンドアロンサーバーのサーバー設定の設定
リンクのコピー

Samba スタンドアロンサーバーのサーバー設定を設定できます。

手順

  1. samba パッケージをインストールします。 

    # yum install samba

  2. /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 名までデプロイメントします。これにより、クライアントごとに個別のログファイルが有効になります。

  3. オプション: ファイルまたはプリンターの共有を設定します。参照:

  4. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  5. 認証が必要な共有を設定する場合は、ユーザーアカウントを作成します。

    詳細は ローカルユーザーアカウントの作成および有効化 を参照してください。

  6. firewall-cmd ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。 

    # firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload

  7. smb サービスを有効にして起動します。 

    # systemctl enable --now smb

3.3.2. ローカルユーザーアカウントの作成および有効化
リンクのコピー

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

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

example という名前のローカル Samba ユーザーを作成できます。

前提条件

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

手順

  1. オペレーティングシステムアカウントを作成します。 

    # useradd -M -s /sbin/nologin example

    このコマンドは、ホームディレクトリーを作成せずに、example アカウントを追加します。アカウントが Samba への認証のみに使用される場合は、/sbin/nologin コマンドをシェルとして割り当て、アカウントがローカルでログインしないようにします。

  2. オペレーティングシステムのアカウントにパスワードを設定して、これを有効にします。 

    # passwd example
Enter new UNIX password: password
Retype new UNIX password: password
passwd: password updated successfully

    Samba は、オペレーティングシステムのアカウントに設定されたパスワードを使用して認証を行いません。ただし、アカウントを有効にするには、パスワードを設定する必要があります。アカウントが無効になると、そのユーザーが接続した時に Samba がアクセスを拒否します。

  3. Samba データベースにユーザーを追加し、そのアカウントにパスワードを設定します。 

    # smbpasswd -a example
New SMB password: password
Retype new SMB password: password
Added user example.

    このアカウントを使用して Samba 共有に接続する場合に、このパスワードを使用して認証を行います。

  4. 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 マッピングバックエンドを提供します。最も頻繁に使用されるバックエンドは、以下の通りです。

Expand
バックエンドユースケース

tdb

* デフォルトドメインのみ

ad

AD ドメインのみ

rid

AD ドメインおよび NT4 ドメイン

autorid

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 から以下の属性を読み込みます。

Expand
AD 属性名オブジェクトの種類マッピング先

sAMAccountName

ユーザーおよびグループ

オブジェクトのユーザー名またはグループ名

uidNumber

ユーザー

ユーザー ID (UID)

gidNumber

グループ

グループ ID (GID)

loginShell [a]

ユーザー

ユーザーのシェルのパス

unixHomeDirectory [a]

ユーザー

ユーザーのホームディレクトリーのパス

primaryGroupID [b]

ユーザー

プライマリーグループ ID

[a] idmap config DOMAIN:unix_nss_info = yes を設定している場合に限り、Samba がこの属性を読み込みます。
[b] idmap config DOMAIN:unix_primary_group = yes を設定している場合に限り、Samba がこの属性を読み込みます。

前提条件

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

手順

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

    1. デフォルトドメイン (*) に ID マッピング設定が存在しない場合は追加します。以下に例を示します。 

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

    2. AD ドメインの ad ID マッピングバックエンドを有効にします。 

      idmap config DOMAIN : backend = ad

    3. AD ドメインのユーザーおよびグループに割り当てられている ID の範囲を設定します。以下に例を示します。 

      idmap config DOMAIN : range = 2000000-2999999
      重要

      この範囲は、このサーバーの他のドメイン設定と重複させることはできません。また、この範囲には、今後割り当てられる ID がすべて収まる大きさを設定する必要があります。詳細は、Samba ID 範囲の計画 を参照してください。

    4. Samba が AD から属性を読み取る際に RFC 2307 スキーマを使用するように設定します。 

      idmap config DOMAIN : schema_mode = rfc2307

    5. Samba が、対応する AD 属性からログインシェルおよびユーザーホームディレクトリーのパスを読み取るようにする場合は、以下を設定します。 

      idmap config DOMAIN : unix_nss_info = yes

      または、すべてのユーザーに適用される、ドメイン全体のホームディレクトリーのパスおよびログインシェルを統一して設定できます。以下に例を示します。 

      template shell = /bin/bash
template homedir = /home/%U

    6. デフォルトでは、Samba は、ユーザーオブジェクトの primaryGroupID 属性を、Linux のユーザーのプライマリーグループとして使用します。または、代わりに gidNumber 属性に設定されている値を使用するように Samba を設定できます。 

      idmap config DOMAIN : unix_primary_group = yes

  2. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  3. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

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 ファイルにある。

手順

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

    1. デフォルトドメイン (*) に ID マッピング設定が存在しない場合は追加します。以下に例を示します。 

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

    2. ドメインの rid ID マッピングバックエンドを有効にします。 

      idmap config DOMAIN : backend = rid

    3. 今後割り当てられるすべての RID が収まる大きさの範囲を設定します。以下に例を示します。 

      idmap config DOMAIN : range = 2000000-2999999

      Samba は、そのドメインの RID がその範囲内にないユーザーおよびグループを無視します。

      重要

      この範囲は、このサーバーの他のドメイン設定と重複させることはできません。また、この範囲には、今後割り当てられる ID がすべて収まる大きさを設定する必要があります。詳細は、Samba ID 範囲の計画 を参照してください。

    4. すべてのマッピングユーザーに割り当てられるシェルおよびホームディレクトリーのパスを設定します。以下に例を示します。 

      template shell = /bin/bash
template homedir = /home/%U

  2. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  3. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

3.4.6. autorid ID マッピングバックエンドの使用
リンクのコピー

autorid ID マッピングバックエンドを使用するように Samba ドメインメンバーを設定できます。

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 ファイルにある。

手順

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

    1. * デフォルトドメインの autorid ID マッピングバックエンドを有効にします。 

      idmap config * : backend = autorid

    2. 既存および将来の全オブジェクトに ID を割り当てられる大きさの範囲を設定します。以下に例を示します。 

      idmap config * : range = 10000-999999

      Samba は、このドメインで計算した ID が範囲内にないユーザーおよびグループを無視します。

      警告

      範囲を設定し、Samba がそれを使用して開始してからは、範囲の上限を小さくすることはできません。範囲にその他の変更を加えると、新しい ID 割り当てが発生し、ファイルの所有権が失われる可能性があります。

    3. オプション: 範囲のサイズを設定します。以下に例を示します。 

      idmap config * : rangesize = 200000

      Samba は、idmap config * : range パラメーターに設定されている範囲からすべての ID を取得するまで、各ドメインのオブジェクトにこの数の連続 ID を割り当てます。

      注記

      rangesize を設定する場合は、適宜範囲を調整する必要があります。この範囲は rangesize の倍数である必要があります。

    4. すべてのマッピングユーザーに割り当てられるシェルおよびホームディレクトリーのパスを設定します。以下に例を示します。 

      template shell = /bin/bash
template homedir = /home/%U

    5. オプション: ドメイン用の ID マッピング設定を追加します。個別のドメインの設定が利用できない場合、Samba は以前に設定した * デフォルトドメインの autorid バックエンド設定を使用して ID を計算します。

      重要

      この範囲は、このサーバーの他のドメイン設定と重複させることはできません。また、この範囲には、今後割り当てられる ID がすべて収まる大きさを設定する必要があります。詳細は、Samba ID 範囲の計画 を参照してください。

  2. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  3. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

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 ドメインを解決できる DNS サーバーを使用します。
  • ホストの時刻は AD の時刻と同期されており、タイムゾーンの設定は正しいです。

手順

  1. AD で Kerberos 認証に非推奨の RC4 暗号化タイプが必要な場合は、RHEL でこの暗号のサポートを有効にします。 

    # update-crypto-policies --set DEFAULT:AD-SUPPORT

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

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

  3. ドメインメンバーでディレクトリーまたはプリンターを共有するには、samba パッケージをインストールします。 

    # yum install samba

  4. 既存の Samba 設定ファイル /etc/samba/smb.conf をバックアップします。 

    # mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

  5. ドメインに参加します。たとえば、ドメイン 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 サービスを起動し、システムの起動時にサービスを起動できるようにします。

  6. オプション: /etc/samba/smb.conf ファイルで、別の ID マッピングバックエンドまたはカスタマイズした ID マッピング設定を指定します。

    詳細は、Samba ID マッピングの理解と設定 を参照してください。

  7. winbind サービスが稼働していることを確認します。 

    # systemctl status winbind
...
   Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago
    重要

    Samba がドメインのユーザーおよびグループの情報をクエリーできるようにするには、smb を起動する前に winbind サービスを実行する必要があります。

  8. samba パッケージをインストールしてディレクトリーおよびプリンターを共有している場合は、smb サービスを有効化して開始します。 

    # systemctl enable --now smb
  9. Active Directory へのローカルログインを認証する場合は、winbind_krb5_localauth プラグインを有効にします。MIT Kerberos 用のローカル承認プラグインの使用

検証

  1. AD ドメインの AD 管理者アカウントなど、AD ユーザーの詳細を表示します。 

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

  2. AD ドメイン内のドメインユーザーグループのメンバーをクエリーします。 

    # getent group "AD\Domain Users"
    AD\domain users:x:10000:user1,user2

  3. オプション: ファイルとディレクトリーの権限を設定するときに、ドメインのユーザーおよびグループを使用できることを確認します。たとえば、/srv/samba/example.txt ファイルの所有者を AD\administrator に設定し、グループを AD\Domain Users に設定するには、以下のコマンドを実行します。 

    # chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt

  4. Kerberos 認証が期待どおりに機能することを確認します。

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

      # kinit administrator@AD.EXAMPLE.COM

    2. キャッシュされた 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

  5. 利用可能なドメインの表示: 

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

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
}

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 にフィードバックをお寄せください。

AD ドメインのユーザーが Samba によって提供される共有およびプリンターサービスにアクセスする必要がある場合は、AES 暗号化タイプが AD になっていることを確認してください。詳細は、GPO を使用した Active Directory での AES 暗号化タイプの有効化 を参照してください。

前提条件

  • ホストは、クライアントとして 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 権限がある。

手順

  1. 必要なパッケージをインストールします。 

    [root@ipaserver ~]# yum install ipa-server-trust-ad samba-client

  2. IdM 管理ユーザーとして認証します。 

    [root@ipaserver ~]# kinit admin

  3. ipa-adtrust-install ユーティリティーを実行します。 

    [root@ipaserver ~]# ipa-adtrust-install

    統合 DNS サーバーとともに IdM がインストールされていると、DNS サービスレコードが自動的に作成されます。

    IdM が統合 DNS サーバーなしで IdM をインストールすると、ipa-adtrust-install は、続行する前に DNS に手動で追加する必要があるサービスレコードのリストを出力します。

  4. スクリプトにより、/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

  5. このスクリプトは、従来の 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

  6. プロンプトが表示されたら、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]:

  7. SID 生成タスクを実行して、既存ユーザーに SID を作成するように求められます。 

    Do you want to run the ipa-sidgen task? [no]: yes

    これはリソースを集中的に使用するタスクであるため、ユーザー数が多い場合は別のタイミングで実行できます。

  8. オプション: 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

  9. ipa サービスを再起動します。 

    [root@ipaserver ~]# ipactl restart

  10. smbclient ユーティリティーを使用して、Samba が IdM サイドからの Kerberos 認証に応答することを確認します。 

    [root@ipaserver ~]# smbclient -L ipaserver.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. IdM クライアントでの Samba サーバーのインストールおよび設定
リンクのコピー

IdM ドメインに登録されたクライアントに Samba をインストールして設定できます。

前提条件

手順

  1. ipa-client-samba パッケージをインストールします。 

    [root@idm_client]# yum install ipa-client-samba

  2. 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

  3. デフォルトでは、ipa-client-samba は、ユーザーが接続したときにそのユーザーのホームディレクトリーを動的に共有するために、/etc/samba/smb.conf ファイルに [homes] セクションが自動的に追加されます。ユーザーがこのサーバーにホームディレクトリーがない場合、または共有したくない場合は、/etc/samba/smb.conf から次の行を削除します。 

    [homes]
    read only = no

  4. ディレクトリーとプリンターを共有します。詳細は、以下を参照してください。

  5. ローカルファイアウォールで Samba クライアントに必要なポートを開きます。 

    [root@idm_client]# firewall-cmd --permanent --add-service=samba-client
[root@idm_client]# firewall-cmd --reload

  6. smb サービスおよび winbind サービスを有効にして開始します。 

    [root@idm_client]# systemctl enable --now smb winbind
    注記

    nmbd サービスは開始しないでください。Samba を Active Directory と連携して使用する場合、AD 環境では DNS が名前解決を処理するため、相互運用性のために NetBIOS は必要ありません。

検証

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)
...

3.6.3. IdM が新しいドメインを信頼する場合は、ID マッピング設定を手動で追加
リンクのコピー

Samba では、ユーザーがリソースにアクセスする各ドメインの ID マッピング設定が必要です。IdM クライアントで実行している既存の Samba サーバーでは、管理者が Active Directory (AD) ドメインに新しい信頼を追加した後、ID マッピング設定を手動で追加する必要があります。

前提条件

  • IdM クライアントで Samba を設定している。その後、IdM に新しい信頼が追加されている。
  • Kerberos の暗号化タイプ DES および RC4 は、信頼できる AD ドメインで無効にしている。セキュリティー上の理由から、RHEL 8 はこのような弱い暗号化タイプに対応していません。

手順

  1. ホストのキータブを使用して認証します。 

    [root@idm_client]# kinit -k

  2. 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 属性の値が必要です。

  3. 使用可能な最高の ID を計算するには、次の式を使用します。 

    maximum_range = ipabaseid + ipaidrangesize - 1

    前の手順の値を使用すると、ad.example.com ドメインで使用可能な最大 ID は 1918599999 (1918400000 + 200000 - 1) です。

  4. /etc/samba/smb.conf ファイルを編集し、ドメインの ID マッピング設定を [global] セクションに追加します。 

    idmap config AD : range = 1918400000 - 1918599999
idmap config AD : backend = sss

    ipabaseid 属性の値を最小値として指定し、前の手順で計算された値を範囲の最大値として指定します。

  5. 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.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 が、以下のいずれかのモードで設定されている。

手順

  1. ディレクトリーが存在しない場合は作成します。以下に例を示します。 

    # mkdir -p /srv/samba/example/

  2. SELinux を、enforcing モードで実行する場合は、そのディレクトリーに samba_share_t コンテキストを設定します。 

    # semanage fcontext -a -t samba_share_t "/srv/samba/example(/.*)?"
# restorecon -Rv /srv/samba/example/

  3. ディレクトリーにファイルシステムの ACL を設定します。詳細は、以下を参照してください。

  4. /etc/samba/smb.conf ファイルにサンプル共有を追加します。たとえば、共有の write-enabled を追加するには、次のコマンドを実行します。 

    [example]
	path = /srv/samba/example/
	read only = no
    注記

    ファイルシステムの ACL に関係なく、read only = no を設定しないと、Samba がディレクトリーを読み取り専用モードで共有します。

  5. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  6. firewall-cmd ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。 

    # firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload

  7. 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.

前提条件

  • ACL を設定する Samba 共有がある。

手順

  1. /srv/samba/example/ ディレクトリーのグループを Domain Users に設定します。 

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

  2. グループに読み取りと書き込みの権限を付与する: 

    # chmod 2770 /srv/samba/example/
    注記

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

3.7.3. POSIX ACL を使用する Samba 共有での拡張 ACL の設定
リンクのコピー

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

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

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

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

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

前提条件

  • ACL を設定する Samba 共有がある。

手順

  1. /etc/samba/smb.conf ファイルの共有セクションで以下のパラメーターを有効にして、拡張 ACL の ACL 継承を有効にします。 

    inherit acls = yes

    詳細は、man ページの smb.conf(5) のパラメーターの説明を参照してください。

  2. smb サービスを再起動します。 

    # systemctl restart smb

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

    例3.2 拡張 ACL の設定

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

    1. ユーザーアカウントのプライマリーグループへの自動許可権限を無効にします。 

      # setfacl -m group::--- /srv/samba/example/
# setfacl -m default:group::--- /srv/samba/example/

      ディレクトリーのプライマリーグループは、さらに動的な CREATOR GROUP プリンシパルにマッピングされます。Samba 共有で拡張 POSIX ACL を使用すると、このプリンシパルは自動的に追加され、削除できません。

    2. ディレクトリーに権限を設定します。

      1. Domain Admins グループに読み取り、書き込み、および実行の権限を付与します。 

        # setfacl -m group:"DOMAIN\Domain Admins":rwx /srv/samba/example/

      2. Domain Users グループに読み取りおよび実行の権限を付与します。 

        # setfacl -m group:"DOMAIN\Domain Users":r-x /srv/samba/example/

      3. その他 の ACL エントリーに権限を設定し、その他の ACL エントリーに一致しないユーザーへのアクセスを拒否します。 

        # setfacl -R -m other::--- /srv/samba/example/

      この設定は、このディレクトリーにのみ適用されます。Windows では、これらの ACL は このフォルダーのみ のモードにマッピングされます。

    3. 前の手順で設定した権限を、このディレクトリーに作成した新規ファイルシステムのオブジェクトから継承できるようにするには、以下のコマンドを実行します。 

      # 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 にマッピングします。

    Expand
    プリンシパルアクセス適用先

    Domain\Domain Admins

    完全な制御

    このフォルダー、サブフォルダー、およびファイル

    Domain\Domain Users

    読み取りおよび実行

    このフォルダー、サブフォルダー、およびファイル

    Everyone [a]

    なし

    このフォルダー、サブフォルダー、およびファイル

    owner (Unix User\owner) [b]

    完全な制御

    このフォルダーのみ

    primary_group (Unix User\primary_group) [c]

    なし

    このフォルダーのみ

    CREATOR OWNER [d] [e]

    完全な制御

    サブフォルダーおよびファイルのみ

    CREATOR GROUP [e] [f]

    なし

    サブフォルダーおよびファイルのみ

    [a] Samba は、このプリンシパルの権限を その他 の ACL エントリーからマッピングします。
    [b] Samba は、ディレクトリーの所有者をこのエントリーにマッピングします。
    [c] Samba は、ディレクトリーのプライマリーグループをこのエントリーにマッピングします。
    [d] 新規ファイルシステムオブジェクトでは、作成者はこのプリンシパルの権限を自動的に継承します。
    [e] POSIX ACL を使用する共有では、このプリンシパルの設定または削除には対応していません。
    [f] 新規ファイルシステムオブジェクトの場合、作成者のプライマリーグループは、自動的にこのプリンシパルの権限を継承します。

3.8. POSIX ACL を使用する共有への権限の設定
リンクのコピー

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

注記

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

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

前提条件

  • POSIX ACL との共有が設定されている。

3.8.1. ユーザーおよびグループに基づいた共有アクセスの設定
リンクのコピー

ユーザーおよびグループに基づいたアクセス制御により、特定のユーザーおよびグループの共有へのアクセスを許可または拒否できます。

前提条件

  • ユーザーまたはグループベースのアクセスを設定する Samba 共有がある。

手順

  1. たとえば、Domain Users グループの全メンバーが、ユーザー アカウントのアクセスが拒否されている時に共有にアクセスできるようにするには、共有の設定に以下のパラメーターを追加します。 

    valid users = +DOMAIN\"Domain Users"
invalid users = DOMAIN\user

    無効なユーザー パラメーターの優先度は、有効なユーザー パラメーターよりも高くなります。たとえば、ユーザー アカウントが Domain Users グループのメンバーである場合に上述の例を使用すると、このアカウントへのアクセスは拒否されます。

  2. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

3.8.2. ホストベースの共有アクセスの設定
リンクのコピー

ホストベースのアクセス制御により、クライアントのホスト名、IP アドレス、または IP 範囲に基づいて、共有へのアクセスを許可または拒否できます。

以下の手順では、IP アドレスの 127.0.0.1、IP 範囲の 192.0.2.0/24、およびホストの client1.example.com を有効にして共有にアクセスする方法と、client2.example.com ホストへのアクセスを拒否する方法を説明します。

前提条件

  • ホストベースのアクセスを設定する Samba 共有がある。

手順

  1. 以下のパラメーターを、/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 アドレスに解決すると、このホストへのアクセスは拒否されます。

  2. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

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. SeDiskOperatorPrivilege 特権の付与
リンクのコピー

Windows ACL を使用する共有に対する権限を設定できるのは、SeDiskOperatorPrivilege 特権が付与されているユーザーおよびグループのみです。

手順

  1. たとえば、SeDiskOperatorPrivilege 特権を DOMAIN\Domain Admins グループに付与するには、以下のコマンドを実行します。 

    # net rpc rights grant "DOMAIN\Domain Admins" SeDiskOperatorPrivilege -U "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully granted rights.
    注記

    ドメイン環境では、SeDiskOperatorPrivilege をドメイングループに付与します。これにより、ユーザーのグループメンバーシップを更新し、権限を集中的に管理できます。

  2. 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 サーバーに設定されている。

手順

  1. すべての共有に対してグローバルに有効にするには、次の設定を /etc/samba/smb.conf ファイルの [global] セクションに追加します。 

    vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes

    または、共有のセクションに同じパラメーターを追加して、個別の共有に対して Windows ACL サポートを有効にできます。

  2. smb サービスを再起動します。 

    # systemctl restart smb

3.9.3. Windows ACL を使用する共有の追加
リンクのコピー

/srv/samba/example/ ディレクトリーのコンテンツを共有し、Windows ACL を使用する example という名前の共有を作成できます。

手順

  1. ディレクトリーが存在しない場合は作成します。以下に例を示します。 

    # mkdir -p /srv/samba/example/

  2. SELinux を、enforcing モードで実行する場合は、そのディレクトリーに samba_share_t コンテキストを設定します。 

    # semanage fcontext -a -t samba_share_t "/srv/samba/example(/.*)?"
# restorecon -Rv /srv/samba/example/

  3. /etc/samba/smb.conf ファイルにサンプル共有を追加します。たとえば、共有の write-enabled を追加するには、次のコマンドを実行します。 

    [example]
	path = /srv/samba/example/
	read only = no
    注記

    ファイルシステムの ACL に関係なく、read only = no を設定しないと、Samba がディレクトリーを読み取り専用モードで共有します。

  4. すべての共有の [global] セクションで Windows ACL サポートを有効にしていない場合は、以下のパラメーターを [example] セクションに追加して、この共有に対してこの機能を有効にします。 

    vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes

  5. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  6. firewall-cmd ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。 

    # firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload

  7. 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 です。
継承情報

次の値を取ります。

Expand
表3.1 継承の設定
値説明マップ先

OI

オブジェクトの継承

このフォルダーおよびファイル

CI

コンテナーの継承

このフォルダーおよびサブフォルダー

IO

継承のみ

ACE は、現在のファイルまたはディレクトリーには適用されません。

ID

継承済

親ディレクトリーから ACE が継承されました。

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

Expand
表3.2 継承設定の組み合わせ
値の組み合わせWindows の 適用先 設定にマップします。

OI|CI

このフォルダー、サブフォルダー、およびファイル

OI|CI|IO

サブフォルダーおよびファイルのみ

CI|IO

サブディレクトリーのみ

OI|IO

ファイルのみ

権限

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

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

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

    Expand
    表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 エイリアス。以下の表には、利用可能なエイリアスが表示されます。

    Expand
    表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 グループのメンバーのみがユーザー共有を作成できるようにするには、以下を実行します。

手順

  1. ローカルの example グループが存在しない場合は作成します。 

    # groupadd example

  2. ユーザー共有の定義を保存し、その権限を正しく設定するために、Samba 用のディレクトリーを準備します。以下に例を示します。

    1. ディレクトリーを作成します。 

      # mkdir -p /var/lib/samba/usershares/

    2. example グループの書き込み権限を設定します。 

      # chgrp example /var/lib/samba/usershares/
# chmod 1770 /var/lib/samba/usershares/
    3. このディレクトリーの他のユーザーが保存したファイルの名前変更や削除を禁止するように sticky ビットを設定します。

  3. /etc/samba/smb.conf ファイルを編集し、以下を [global] セクションに追加します。

    1. ユーザー共有の定義を保存するように設定したディレクトリーのパスを設定します。以下に例を示します。 

      usershare path = /var/lib/samba/usershares/

    2. このサーバーで Samba を作成できるユーザー共有の数を設定します。以下に例を示します。 

      usershare max shares = 100

      usershare max shares パラメーターにデフォルトの 0 を使用すると、ユーザー共有が無効になります。

    3. オプション: ディレクトリーの絶対パスのリストを設定します。たとえば、Samba が /data ディレクトリーおよび /srv ディレクトリーのサブディレクトリーの共有のみを許可するように設定するには、以下を設定します。 

      usershare prefix allow list = /data /srv

    設定可能なユーザー共有関連のパラメーターのリストは、システム上の smb.conf(5) man ページの USERSHARES セクションを参照してください。

  4. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  5. 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 サーバーに設定されている。

手順

  1. 任意のユーザーが作成したすべてのユーザー共有を表示するには、以下のコマンドを実行します。 

    $ net usershare info -l
[share_1]
path=/srv/samba/
comment=
usershare_acl=Everyone:R,host_name\user:F,
guest_ok=y
...

    コマンドを実行するユーザーが作成した共有のみをリスト表示するには、-l パラメーターを省略します。

  2. 特定の共有に関する情報のみを表示するには、共有名またはワイルドカードをコマンドに渡します。たとえば、名前が share_ で始まる共有の情報を表示する場合は、以下のコマンドを実行します。 

    $ net usershare info -l share_*

3.11.5. ユーザー共有のリスト表示
リンクのコピー

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

前提条件

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

手順

  1. 任意のユーザーが作成した共有をリスト表示するには、以下のコマンドを実行します。 

    $ net usershare list -l
share_1
share_2
...

    コマンドを実行するユーザーが作成した共有のみをリスト表示するには、-l パラメーターを省略します。

  2. 特定の共有のみをリスト表示するには、共有名またはワイルドカードをコマンドに渡します。たとえば、名前が 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

手順

  1. /etc/samba/smb.conf ファイルを編集します。

    1. これが、このサーバーで設定した最初のゲスト共有である場合は、以下を行います。

      1. [global] セクションに map to guest = Bad User を設定します。 

        [global]
        ...
        map to guest = Bad User

        この設定により、ユーザー名が存在しない限り、Samba は間違ったパスワードを使用したログイン試行を拒否します。指定したユーザー名がなく、ゲストアクセスが共有で有効になっている場合、Samba は接続をゲストのログインとして処理します。

      2. デフォルトでは、Samba は、Red Hat Enterprise Linux の nobody アカウントにゲストアカウントをマッピングします。または、別のアカウントを設定することもできます。以下に例を示します。 

        [global]
        ...
        guest account = user_name

        このパラメーターに設定するアカウントは、Samba サーバーにローカルに存在する必要があります。セキュリティー上の理由から、Red Hat は有効なシェルを割り当てていないアカウントを使用することを推奨しています。

    2. guest ok = yes の設定を、[example] 共有セクションに追加します。 

      [example]
        ...
        guest ok = yes

  2. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  3. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

3.13. MacOS クライアント向けの Samba の設定
リンクのコピー

fruit 仮想ファイルシステム (VFS) の Samba モジュールは、Apple サーバーメッセージブロック (SMB) クライアントとの互換性を強化します。

3.13.1. MacOS クライアントにファイル共有を提供する Samba 設定の最適化
リンクのコピー

fruit モジュールは、Samba の MacOS クライアントとの互換性を強化します。Samba サーバーでホストされているすべての共有に対してモジュールを設定して、MacOS クライアント向けにファイル共有を最適化できます。

注記

fruit モジュールをシステム全体で有効にします。MacOS を使用するクライアントは、クライアントがサーバーへの最初の接続を確立する時に、サーバーメッセージブロックバージョン 2 (SMB2) Apple (AAPL) プロトコル拡張をネゴシエートします。クライアントが最初に AAPL 拡張機能を有効にせずに共有に接続すると、クライアントはサーバーの共有に拡張機能を使用しません。

前提条件

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

手順

  1. /etc/samba/smb.conf ファイルを編集し、[global] セクションの VFS モジュール fruit および streams_xattr を有効にします。 

    vfs objects = fruit streams_xattr
    重要

    streams_xattr を有効にする前に、fruit モジュールを有効にする必要があります。fruit モジュールは、別のデータストリーム (ADS) を使用します。このため、streams_xattr モジュールも有効にする必要があります。

  2. オプション: 共有で macOS Time Machine サポートを提供するには、/etc/ samba/smb.conf ファイルの共有設定に次の設定を追加します。 

    fruit:time machine = yes

  3. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  4. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

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

3.14.2. 対話モードでの smbclient の使用
リンクのコピー

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

手順

  1. 共有に接続します。 

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

  2. /example/ ディレクトリーに移動します。 

    smb: \> d /example/

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

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

         9950208 blocks of size 1024. 8247144 blocks available

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

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

  5. 共有から切断します。 

    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) で提供されているドキュメントを参照してください。

手順

  1. /etc/samba/smb.conf ファイルを編集します。

    1. [printers] セクションを追加して、Samba で印刷バックエンドを有効にします。 

      [printers]
        comment = All Printers
        path = /var/tmp/
        printable = yes
        create mask = 0600
      重要

      [printers] 共有名はハードコーディングされており、変更はできません。

    2. CUPS サーバーが別のホストまたはポートで実行されている場合は、[printers] セクションで設定を指定します。 

      cups server = printserver.example.com:631

    3. 多数のプリンターがある場合は、待機秒数を CUPS に接続されているプリンターの数よりも大きい値に設定します。たとえば、100 台のプリンターがある場合は、[global] セクションに次のように設定します。 

      rpcd_spoolss:idle_seconds = 200

      この設定が環境内でスケーリングされない場合は、[global] セクションで rpcd_spoolss ワーカーの数も増やします。 

      rpcd_spoolss:num_workers = 10

      デフォルトでは、rpcd_spoolss は 5 つのワーカーを開始します。

  2. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  3. firewall-cmd ユーティリティーを使用して必要なポートを開き、ファイアウォール設定を再読み込みします。 

    # firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload

  4. 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 がプリントサーバーとして設定されている。

手順

  1. /etc/samba/smb.conf ファイルを編集します。

    1. [global] セクションで、以下の設定で自動プリンター共有を無効にします。 

      load printers = no

    2. 共有するプリンターごとにセクションを追加します。たとえば、Samba で CUPS バックエンドで example という名前のプリンターを Example-Printer として共有するには、以下のセクションを追加します。 

      [Example-Printer]
        path = /var/tmp/
        printable = yes
        printer name = example

      各プリンターに個別のスプールディレクトリーは必要ありません。[printers] セクションに設定したのと同じ spool ディレクトリーを、プリンターの path パラメーターに設定できます。

  2. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  3. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

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 ホストにドライバーをローカルにインストールするセットアップアプリケーションを起動する必要があります。特定の状況では、インストーラーはセットアップの実行中にオペレーティングシステムの一時フォルダーに個別のファイルを抽出します。アップロードにドライバーファイルを使用するには、以下のコマンドを実行します。

    1. インストーラーを起動します。
    2. 一時フォルダーから新しい場所にファイルをコピーします。
    3. インストールをキャンセルします。

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

クライアントに 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 が割り当てられます。

手順

  1. たとえば、SePrintOperatorPrivilege 権限を printadmin グループに付与するには、以下のコマンドを実行します。 

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

    ドメイン環境では、SePrintOperatorPrivilege をドメイングループに付与します。これにより、ユーザーのグループメンバーシップを更新し、権限を集中的に管理できます。

  2. 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 グループのメンバーがプリンタードライバーをアップロードすることを有効にする方法を説明します。

手順

  1. [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 に設定されます。

    1. 全プリンター向けに 64 ビットドライバーのみをアップロードするには、/etc/samba/smb.conf ファイルの [global] セクションに以下の設定を含めます。 

      spoolss: architecture = Windows x64

      この設定がないと、少なくとも 32 ビットバージョンでアップロードしたドライバーのみが表示されます。

    2. /etc/samba/smb.conf ファイルを検証します。 

      # testparm

    3. Samba 設定を再読み込みします。 

      # smbcontrol all reload-config

    4. printadmin グループが存在しない場合は作成します。 

      # groupadd printadmin

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

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

    6. SELinux を、enforcing モードで実行する場合は、そのディレクトリーに samba_share_t コンテキストを設定します。 

      # semanage fcontext -a -t samba_share_t "/var/lib/samba/drivers(/.*)?"

# restorecon -Rv /var/lib/samba/drivers/

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

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

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

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

        Expand
        プリンシパルアクセス適用先

        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 のドキュメントを参照してください。

手順

  1. AD ドメインの 管理者 ユーザーなど、グループポリシーの編集が可能なアカウントを使用して、Windows コンピューターにログインします。
  2. Group Policy Management Console を開きます。

  3. AD ドメインを右クリックし、Create a GPO in this domain, and Link it here を選択します。

    Samba で GPO の新規作成
  4. Legacy Printer Driver Policy などの GPO の名前を入力して、OK をクリックします。新しい GPO がドメインエントリーの下に表示されます。
  5. 新たに作成した GPO を右クリックして Edit を選択し、Group Policy Management Editor を開きます。

  6. Computer Configuration → Policies → Administrative Templates → Printers の順にクリックします。

    Samba でプリンターの GPO グループの選択

  7. ウィンドウの右側で、Point and Print Restriction をダブルクリックして、ポリシーを編集します。

    1. ポリシーを有効にし、以下のオプションを設定します。

      1. Users can only point and print to these servers を選択し、このオプションの横にあるフィールドに、Samba プリントサーバーの完全修飾ドメイン名 (FQDN) を入力します。

      2. Security Prompts の両チェックボックスで、Do not show warning or elevation prompt を選択します。

        Samba GPO のポイントおよび印刷
    2. OK をクリックします。

  8. Package Point and Print - Approved servers をダブルクリックして、ポリシーを編集します。

    1. ポリシーを有効にして、Show ボタンをクリックします。

    2. Samba プリントサーバーの FQDN を入力します。

      Samba GPO で承認されたサーバー
    3. OK をクリックして、Show Contents ウィンドウとポリシーのプロパティーウィンドウの両方を閉じます。
  9. Group Policy Management Editor を閉じます。
  10. Group Policy Management Console を閉じます。

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

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 モードで動作します。これを使用すると、FIPS 準拠環境で Samba を実行したり、コンプライアンス要件を満たしたりできます。

  • Samba は、AES 暗号化を使用する Kerberos 認証を使用する Active Directory (AD) または Red Hat Enterprise Linux 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 モードでサポートされるモードで実行する。

手順

  1. RHEL で FIPS モードを有効にします。 

    # fips-mode-setup --enable

  2. サーバーを再起動します。 

    # reboot

  3. 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 パラメーターでデフォルト値を使用する方法を説明します。

手順

  1. /etc/samba/smb.conf ファイルの [global] セクションから、server max protocol パラメーターを削除します。

  2. Samba 設定を再読み込みします。 

    # smbcontrol all reload-config

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

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

前提条件

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

手順

  1. 共有の全ファイルの名前を小文字に変更します。

    注記

    この手順の設定を使用すると、小文字以外の名前が付けられたファイルは表示されなくなります。

  2. 共有のセクションに、以下のパラメーターを設定します。 

    case sensitive = true
default case = lower
preserve case = no
short preserve case = no

    パラメーターの詳細は、システム上の smb.conf(5) man ページの説明を参照してください。

  3. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  4. 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 パラメーターを削除します。

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 がインストールされ、設定されている。

手順

  1. /etc/samba/smb.conf ファイルを編集し、server min protocol パラメーターを追加して、そのサーバーが対応する最小 SMB プロトコルバージョンに設定できます。たとえば、最小の SMB プロトコルバージョンを SMB3 に設定するには、以下を追加します。 

    server min protocol = SMB3

  2. smb サービスを再起動します。 

    # systemctl restart smb

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 ユーティリティーは、関連するすべての設定ファイルを自動的に更新します。

手順

  1. 以下の設定で /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
  2. /etc/samba/smb.conf ファイルの [global] セクションに、* デフォルトドメインおよび参加するドメイン用の ID マッピング設定を追加します。

  3. /etc/samba/smb.conf ファイルを検証します。 

    # testparm

  4. ドメイン管理者としてドメインに参加します。

    • AD ドメインに参加するには、以下のコマンドを実行します。 

      # net ads join -U "DOMAIN\administrator"

    • NT4 ドメインに参加するには、以下のコマンドを実行します。 

      # net rpc join -U "DOMAIN\administrator"

  5. /etc/nsswitch.conf ファイルのデータベースエントリー passwd および group に winbind ソースを追加します。 

    passwd:     files winbind
group:      files winbind

  6. winbind サービスを有効にして起動します。 

    # systemctl enable --now winbind

  7. オプション: authselect ユーティリティーを使用して PAM を設定します。

    詳細は、システム上の authselect(8) man ページを参照してください。

  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 パラメーターで設定する必要があります。詳細は、システム上の smb.conf(5) man ページにある add share command の説明を参照してください。
共有の削除

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 パラメーターで設定する必要があります。詳細は、システム上の smb.conf(5) man ページの delete share command の説明を参照してください。

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 アカウントをドメインに追加します。

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

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

  2. オプション: リモートプロシージャコール (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]

    スタンドアロンサーバーまたはドメインメンバーに対してコマンドを実行すると、ローカルデータベースのユーザーのリストが表示されます。AD DC または NT4 PDC に対してコマンドを実行すると、ドメインユーザーのリストが表示されます。

3.20.6. samba-regedit アプリケーションの使用
リンクのコピー

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

samba regedit

前提条件

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

手順

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

# samba-regedit

次のキーを使用します。

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

3.20.7. smbcontrol ユーティリティーの使用
リンクのコピー

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

前提条件

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

手順

  • reload-config メッセージタイプを all 宛に送信して、smbd、nmbd、winbindd サービスの設定をリロードします。 
# smbcontrol all reload-config

3.20.8. smbpasswd ユーティリティーの使用
リンクのコピー

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

前提条件

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

手順

  1. ユーザーとしてコマンドを実行すると、smbpasswd はコマンドを実行するユーザーの Samba パスワードを変更します。以下に例を示します。 

    [user@server ~]$ smbpasswd
New SMB password: password
Retype new SMB password: password

  2. 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.

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

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

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

第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 パッケージを追加でインストールする必要があります。

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 アドレスは静的です。

手順

  1. bind パッケージおよび bind-utils パッケージをインストールします。 

    # yum install bind bind-utils

    これらのパッケージは BIND 9.11 を提供します。BIND 9.16 が必要な場合は、bind9.16 および bind9.16-utils パッケージをインストールしてください。

  2. BIND を change-root 環境で実行する場合は、bind-chroot パッケージをインストールします。 

    # yum install bind-chroot

    デフォルトである enforcing モードで SELinux を使用するホストで BIND を実行すると、より安全になることに注意してください。

  3. /etc/named.conf ファイルを編集し、options ステートメントに次の変更を加えます。

    1. 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; };

    2. allow-query ステートメントを更新して、クライアントがこの DNS サーバーにクエリーを実行できる IP アドレスおよび範囲を設定します。 

      allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };

    3. allow-recursion ステートメントを追加して、BIND が再帰クエリーを受け入れる IP アドレスおよび範囲を定義します。 

      allow-recursion { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
      警告

      サーバーのパブリック IP アドレスで再帰を許可しないでください。そうしないと、サーバーが大規模な DNS 増幅攻撃の一部になる可能性があります。

    4. デフォルトでは、BIND は、ルートサーバーから権限のある DNS サーバーに再帰的にクエリーを実行することにより、クエリーを解決します。または、プロバイダーのサーバーなど、他の DNS サーバーにクエリーを転送するように BIND を設定することもできます。この場合、BIND がクエリーを転送する DNS サーバーの IP アドレスのリストを含む forwarders ステートメントを追加します。 

      forwarders { 198.51.100.1; 203.0.113.5; };

      フォールバック動作として、フォワーダーサーバーが応答しないと、BIND はクエリーを再帰的に解決します。この動作を無効にするには、forward only; ステートメントを追加します。

  4. /etc/named.conf ファイルの構文を確認します。 

    # named-checkconf

    コマンドが出力を表示しない場合は、構文に間違いがありません。

  5. 着信 DNS トラフィックを許可するように firewalld ルールを更新します。 

    # firewall-cmd --permanent --add-service=dns
# firewall-cmd --reload

  6. BIND を開始して有効にします。 

    # systemctl enable --now named

    change-root 環境で BIND を実行する場合は、systemctl enable --now named-chroot コマンドを使用して、サービスを有効にして開始します。

検証

  1. 新しく設定した DNS サーバーを使用してドメインを解決します。 

    # dig @localhost www.example.org
...
www.example.org.    86400    IN    A    198.51.100.34

;; Query time: 917 msec
...

    この例では、BIND が同じホストで実行し、localhost インターフェイスでクエリーに応答することを前提としています。

    初めてレコードをクエリーした後、BIND はエントリーをそのキャッシュに追加します。

  2. 前のクエリーを繰り返します。 

    # dig @localhost www.example.org
...
www.example.org.    85332    IN    A    198.51.100.34

;; Query time: 1 msec
...

    エントリーがキャッシュされるため、エントリーの有効期限が切れるまで、同じレコードに対するそれ以降のリクエストは大幅に高速化されます。

4.4. BIND DNS サーバーでのログの設定
リンクのコピー

bind パッケージによって提供されるデフォルトの /etc/named.conf ファイル内の設定は、default_debug チャネルを使用し、メッセージのログを /var/named/data/named.run ファイルに記録します。default_debug チャネルは、サーバーのデバッグレベルがゼロ以外の場合にのみエントリーをログに記録します。

さまざまなチャネルおよびカテゴリーを使用して、BIND を設定して、定義された重大度でさまざまなイベントを個別のファイルに書き込むことができます。

前提条件

  • BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
  • named または named-chroot サービスが実行しています。

手順

  1. /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 がチャネルにログ記録する必要がある重大度レベルを含むログメッセージの宛先を定義します。イベントのタイムスタンプ、カテゴリー、および重大度のログ記録を有効にするなどの追加設定はオプションですが、デバッグ目的で役立ちます。

  2. ログディレクトリーが存在しない場合は作成し、このディレクトリーの named ユーザーに書き込み権限を付与します。 

    # mkdir /var/named/log/
# chown named:named /var/named/log/
# chmod 700 /var/named/log/

  3. /etc/named.conf ファイルの構文を確認します。 

    # named-checkconf

    コマンドが出力を表示しない場合は、構文に間違いがありません。

  4. 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

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 サービスが実行しています。

手順

  1. /etc/named.conf ファイルを編集して、次の変更を行います。

    1. 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; };

    2. ACL のニックネームをサポートするステートメントで使用します。たとえば、次のようになります。 

      allow-query { internal-networks; dmz-networks; };
allow-recursion { internal-networks; };

  2. /etc/named.conf ファイルの構文を確認します。 

    # named-checkconf

    コマンドが出力を表示しない場合は、構文に間違いがありません。

  3. 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
...

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、および minimum フィールドの数値は、時間を秒単位で定義します。ただし、読みやすくするために、時間の接尾辞 (m は分、h は時間、d は日など) を使用してください。たとえば、3h は 3 時間を表します。

4.6.2. BIND プライマリーサーバーでの正引きゾーンの設定
リンクのコピー

正引きゾーンは、名前を IP アドレスやその他の情報にマップします。たとえば、ドメイン example.com を担当している場合は、BIND で転送ゾーンを設定して、www.example.com などの名前を解決できます。

前提条件

  • BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
  • named または named-chroot サービスが実行しています。

手順

  1. /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 アドレスに対してのみ許可します。

  2. /etc/named.conf ファイルの構文を確認します。 

    # named-checkconf

    コマンドが出力を表示しない場合は、構文に間違いがありません。

  3. たとえば、次の内容で /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 アドレスを設定します。

  4. named グループだけがそれを読み取ることができるように、ゾーンファイルに安全なアクセス許可を設定します。 

    # chown root:named /var/named/example.com.zone
# chmod 640 /var/named/example.com.zone

  5. /var/named/example.com.zone ファイルの構文を確認します。 

    # named-checkzone example.com /var/named/example.com.zone
zone example.com/IN: loaded serial 2022070601
OK

  6. 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 です。192.0.2.0/28 など、異なるネットワークサイズの逆引きゾーンを作成する場合は、ゾーンの名前が 28-2.0.192.in-addr.arpa です。

前提条件

  • BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
  • named または named-chroot サービスが実行しています。

手順

  1. /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 アドレスに対してのみ許可します。

  2. /etc/named.conf ファイルの構文を確認します。 

    # named-checkconf

    コマンドが出力を表示しない場合は、構文に間違いがありません。

  3. たとえば、次の内容で /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) レコードを設定します。

  4. named グループのみがそれを読み取ることができるように、ゾーンファイルに安全なアクセス許可を設定します。 

    # chown root:named /var/named/2.0.192.in-addr.arpa.zone
# chmod 640 /var/named/2.0.192.in-addr.arpa.zone

  5. /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

  6. 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 サービスが実行しています。

手順

  1. オプション: /etc/named.conf ファイル内のゾーンファイルへのパスを特定します。 

    options {
    ...
    directory       "/var/named";
}

zone "example.com" {
    ...
    file "example.com.zone";
};

    ゾーンの定義の file ステートメントで、ゾーンファイルへのパスを見つけます。相対パスは、options ステートメントの directory に設定されたディレクトリーからの相対パスです。

  2. ゾーンファイルを編集します。

    1. 必要な変更を行います。

    2. SOA (Start of Authority) レコードのシリアル番号を増やします。

      重要

      シリアル番号が以前の値以下の場合、セカンダリーサーバーはゾーンのコピーを更新しません。

  3. ゾーンファイルの構文を確認します。 

    # named-checkzone example.com /var/named/example.com.zone
zone example.com/IN: loaded serial 2022062802
OK

  4. 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 検証では、正確なシステム時刻が重要です。

手順

  1. /etc/named.conf ファイルを編集し、DNSSEC を有効にするゾーンに dnssec-policy default; と inline-signing yes; を追加します。 

    zone "example.com" {
    ...
    dnssec-policy default;
    inline-signing yes;
};

  2. BIND をリロードします。 

    # systemctl reload named

    change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

  3. 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==
  4. ゾーンの公開鍵を親ゾーンに追加するように要求します。これを行う方法の詳細については、ドメインプロバイダーまたはレジストリーにお問い合わせください。

検証

  1. 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 インターフェイスでクエリーに応答することを前提としています。

  2. 公開鍵が親ゾーンに追加され、他のサーバーに伝播されたら、サーバーが署名付きゾーンへのクエリーで認証済みデータ (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 サービスが実行している。

手順

  1. 既存のプライマリーサーバーで、以下を行います。

    1. 共有キーを作成し、/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 に追加します。

      後でセカンダリーサーバーでもコマンドの出力が必要になります。

    2. /etc/named.conf ファイルのゾーン定義を編集します。

      1. allow-transfer ステートメントで、サーバーがゾーンを転送するために example-transfer-key ステートメントで指定されたキーを提供する必要があることを定義します。 

        zone "example.com" {
    ...
    allow-transfer { key example-transfer-key; };
};

        または、allow-transfer ステートメントで BIND アクセス制御リスト (ACL) ニックネームを使用します。

      2. デフォルトでは、ゾーンが更新された後、BIND は、このゾーンにネームサーバー (NS) レコードを持つすべてのネームサーバーに通知します。セカンダリーサーバーの NS レコードをゾーンに追加する予定がない場合は、BIND がこのサーバーに通知するように設定できます。そのために、このセカンダリーサーバーの IP アドレスを含む also-notify ステートメントをゾーンに追加します。 

        zone "example.com" {
    ...
    also-notify { 192.0.2.2; 2001:db8:1::2; };
};

    3. /etc/named.conf ファイルの構文を確認します。 

      # named-checkconf

      コマンドが出力を表示しない場合は、構文に間違いがありません。

    4. BIND をリロードします。 

      # systemctl reload named

      change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

  2. 将来のセカンダリーサーバーで、以下を行います。

    1. /etc/named.conf ファイルを次のように編集します。

      1. プライマリーサーバーと同じキー定義を追加します。 

        key "example-transfer-key" {
        algorithm hmac-sha256;
        secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ=";
};

      2. /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 という名前のキーを使用して、プライマリーサーバーに対する認証を行います。

    2. /etc/named.conf ファイルの構文を確認します。 

      # named-checkconf

    3. BIND をリロードします。 

      # systemctl reload named

      change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

  3. オプション: プライマリーサーバーのゾーンファイルを変更し、新しいセカンダリーサーバーの NS レコードを追加します。

検証

セカンダリーサーバーで次の手順を実行します。

  1. 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 コマンドを使用してジャーナルエントリーを表示します。

  2. BIND がゾーンファイルを作成したことを確認します。 

    # ls -l /var/named/slaves/
total 4
-rw-r--r--. 1 named named 2736 Jul  6 15:08 example.com.zone

    デフォルトでは、セカンダリーサーバーはゾーンファイルを未修正のバイナリー形式で保存することに注意してください。

  3. セカンダリーサーバーから転送されたゾーンのレコードをクエリーします。 

    # 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 サービスが実行しています。

手順

  1. /etc/named.conf ファイルを編集し、次の変更を行います。

    1. options ステートメントに response-policy 定義を追加します。 

      options {
    ...

    response-policy {
        zone "rpz.local";
    };

    ...
}

      response-policy の zone ステートメントで RPZ のカスタム名を設定できます。ただし、次のステップのゾーン定義で同じ名前を使用する必要があります。

    2. 前の手順で設定した 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 アドレスに対してのみ許可します。

  2. /etc/named.conf ファイルの構文を確認します。 

    # named-checkconf

    コマンドが出力を表示しない場合は、構文に間違いがありません。

  3. たとえば、次の内容で /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) を参照してください。

  4. /var/named/rpz.local ファイルの構文を確認します。 

    # named-checkzone rpz.local /var/named/rpz.local
zone rpz.local/IN: loaded serial 2022070601
OK

  5. BIND をリロードします。 

    # systemctl reload named

    change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

検証

  1. NXDOMAIN エラーを返すように RPZ で設定されている example.org のホストを解決しようとします。 

    # dig @localhost www.example.org
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30286
...

    この例では、BIND が同じホストで実行し、localhost インターフェイスでクエリーに応答することを前提としています。

  2. RPZ でクエリーを破棄するように設定されている example.net ドメイン内のホストの解決を試みます。 

    # dig @localhost www.example.net
...
;; connection timed out; no servers could be reached
...

4.9. RHEL 7 から RHEL 8 へのバインド移行
リンクのコピー

バインドを RHEL 7 から RHEL 8 に移行するには、次の方法でバインド設定を調整する必要があります。

  • dnssec-lookaside 自動 設定オプションを削除します。
  • listen-on-v6 設定オプションのデフォルト値が none から any に変更されたため、バインドは デフォルトで設定されたすべての IPv6 アドレスをリッスンします。
  • ゾーンの更新が許可されている場合、複数のゾーンで同じゾーンファイルを共有することはできません。複数のゾーン定義で同じファイルを使用する必要がある場合は、allow-updates が none のみを使用していることを確認してください。空でない update-policy を使用したり、inline-signing を有効にしたりしないでください。それ以外の場合は、in-view 句を使用してゾーンを共有します。

更新されたコマンドラインオプション、デフォルトの動作、および出力形式:

  • インターフェイスごとに使用される UDP リスナーの数は、プロセッサーの数に応じて変更されました。バインド に -U 引数を使用してこれを上書きできます。
  • 統計チャネル で使用される XML 形式が変更されました。
  • rndc の flushtree オプションは、DNSSEC 検証の失敗と特定の名前レコードをフラッシュするようになりました。
  • /etc/named.iscdlv.key ファイルの代わりに /etc/named.root.key ファイルを使用する必要があります。/etc/named.iscdlv.key ファイルは利用できなくなりました。
  • クエリーログ形式が変更され、クライアントオブジェクトのメモリーアドレスが含まれるようになりました。デバッグに役立ちます。
  • named および dig ユーティリティーは現在、デフォルトで DNS COOKIE (RFC 7873) を送信するようになりましたが、これは制限的なファイアウォールや侵入検知システムでは機能しない可能性があります。この動作は 、send-cookie 設定オプションを使用して変更できます。
  • dig ユーティリティーは 、拡張 DNS エラー (EDE、RFC 8914) をテキスト形式で表示できます。

4.10. dnstap を使用して DNS クエリーを記録する
リンクのコピー

ネットワーク管理者は、ドメインネームシステム (DNS) の詳細を記録して、DNS トラフィックパターンの分析、DNS サーバーのパフォーマンスの監視、DNS 問題のトラブルシューティングを行うことができます。受信する名前クエリーの詳細を監視してログに記録する高度な方法が必要な場合は、named サービスから送信されたメッセージを記録する dnstap インターフェイスを使用します。DNS クエリーをキャプチャーおよび記録して、Web サイトまたは IP アドレスに関する情報を収集できます。

前提条件

  • bind-9.11.26-2 パッケージ以降のバージョンがインストールされている。
警告

BIND バージョンがすでにインストールされ、実行されている場合、新しいバージョンの BIND を追加すると、既存のバージョンが上書きされます。

手順

  1. /etc/named.conf ファイルの options ブロックを編集して、dnstap とターゲットファイルを有効にします。 

    options
{
# ...
dnstap { all; }; # Configure filter
dnstap-output file "/var/named/data/dnstap.bin";
# ...
};
# end of options

  2. ログに記録する DNS トラフィックのタイプを指定するには、/etc/named.conf ファイルの dnstap ブロックに dnstap フィルターを追加します。次のフィルターを使用できます。

    • auth: 権威ゾーンの応答または回答。
    • client: 内部クライアントクエリーまたは回答。
    • forwarder: 転送クエリーまたは応答。
    • resolver: 反復的解決クエリーまたは応答。
    • update: 動的ゾーン更新要求。
    • all: 上記のオプションのいずれか。

    • query または response: query または response キーワードを指定しない場合、dnstap は両方を記録します。

      注記

      dnstap フィルターでは、dnstap {} ブロック内に ; で区切った複数の定義を含めます。次の構文を使用してください。dnstap { ( all | auth | client | forwarder | resolver | update ) [ ( query | response ) ]; …​ };

  3. 変更を適用するために、named サービスを再起動します。 

    # systemctl restart named.service

  4. アクティブなログの定期的なロールアウトを設定します。

    次の例では、cron スケジューラーは、ユーザーが編集したスクリプトの内容を 1 日に 1 回実行します。roll オプションに値 3 指定し、dnstap が最大 3 つのバックアップログファイルを作成できるようにしています。この値 3 は、dnstap-output 変数の version パラメーターをオーバーライドし、バックアップログファイルの数を 3 に制限します。また、バイナリーログファイルは別のディレクトリーに移動されて名前が変更されます。3 つのバックアップログファイルがすでに存在する場合でも、ファイルの接尾辞が .2 に達することはありません。サイズ制限に基づくバイナリーログの自動ローリングで十分な場合は、このステップを省略できます。 

    Example:

sudoedit /etc/cron.daily/dnstap

#!/bin/sh
rndc dnstap -roll 3
mv /var/named/data/dnstap.bin.1 /var/log/named/dnstap/dnstap-$(date -I).bin

# use dnstap-read to analyze saved logs
sudo chmod a+x /etc/cron.daily/dnstap

  5. dnstap-read ユーティリティーを使用して、人間が判読できる形式でログを処理および分析します。

    次の例では、dnstap-read ユーティリティーは出力を YAML ファイル形式で出力します。 

    Example:

dnstap-read  -p /var/named/data/dnstap.bin

第5章 NFS サーバーのデプロイ
リンクのコピー

ネットワークファイルシステム (NFS) プロトコルを使用すると、リモートユーザーはネットワーク経由で共有ディレクトリーをマウントし、ローカルにマウントされたディレクトリーと同じように使用できます。また、リソースを、ネットワークの集中化サーバーに統合できるようになります。

5.1. NFSv4 のマイナーバージョンの主な機能
リンクのコピー

NFSv4 の各マイナーバージョンでは、パフォーマンスとセキュリティーの向上を目的とした機能強化が導入されます。この強化を利用して NFSv4 の可能性を最大限に活用すれば、ネットワーク全体で効率的かつ信頼性の高いファイル共有を実現できます。

NFSv4.2 の主な機能

サーバー側コピー
サーバー側コピーは、ネットワーク経由でデータを転送せずにサーバー上のファイルをコピーする NFS サーバーの機能です。
スパースファイル
ファイルに 1 つ以上の空きスペース、つまりギャップを持たせることができます。ギャップとは、ゼロのみで構成される未割り当てまたは未初期化データブロックです。これにより、アプリケーションがスパースファイル内のホールの位置を計画できるようになります。
領域の予約
クライアントが、データを書き込む前にストレージサーバー上の領域を予約または確保できます。これにより、サーバーの領域不足が防止されます。
ラベル付き NFS
データアクセス権を強制し、NFS ファイルシステム上の個々のファイルに対して、クライアントとサーバーとの間の SELinux ラベルを有効にします。
レイアウトの機能強化
Parallel NFS (pNFS) サーバーがより優れたパフォーマンス統計情報を収集できるようにする機能を提供します。

NFSv4.1 の主な機能

pNFS のクライアント側サポート
クラスター化されたサーバーへの高速 I/O のサポートにより、複数のマシンへのデータ保存、データへの直接アクセス、メタデータの更新の同期が可能になります。
セッション
セッションは、クライアントに属する接続に関連するサーバーの状態を維持します。この種類のセッションは、各リモートプロシージャーコール (RPC) 操作の接続の確立と終了に関連するオーバーヘッドを削減し、パフォーマンスと効率を向上させます。

NFSv4.0 の主な機能

RPC とセキュリティー
RPCSEC_GSS フレームワークにより、RPC のセキュリティーが強化されます。NFSv4 プロトコルで、インバンドセキュリティーネゴシエーション用の新しい操作が導入されました。これにより、クライアントがファイルシステムリソースにセキュアにアクセスするためのサーバーポリシーをクエリーできるようになります。
プロシージャーと操作の構造
NFS 4.0 で、COMPOUND プロシージャーが導入されました。これにより、クライアントが複数の操作を 1 つの要求にマージして RPC を削減できるようになりました。
ファイルシステムモデル

NFS 4.0 は、階層型ファイルシステムモデルを保持し、ファイルをバイトストリームとして扱い、国際化のために名前を UTF-8 でエンコードします。

  • ファイルハンドルの種類

    揮発性のファイルハンドルにより、サーバーがファイルシステムの変更に適応できます。また、クライアントが、永続的なファイルハンドルを必要とせずに、必要に応じて適応できます。

  • 属性タイプ

    ファイル属性構造には、必須属性、推奨属性、および名前付き属性が含まれています。各属性は異なる目的を果たします。NFSv3 から派生した必須属性は、ファイルタイプを区別するために必要です。一方、ACL などの推奨属性は、アクセス制御を強化します。

  • マルチサーバー名前空間

    名前空間は、複数のサーバー全体を対象に、属性に基づいてファイルシステム転送を簡素化します。また、参照、冗長性、シームレスなサーバー移行をサポートします。

OPEN および CLOSE 操作
これらの操作により、ファイルの検索、作成、セマンティック共有を 1 カ所で組み合わせて、ファイルアクセス管理を効率化できます。
ファイルロック
ファイルロックがプロトコルに含まれているため、RPC コールバックが不要になります。ファイルロックの状態は、リースベースのモデルに基づいてサーバーによって管理されます。リースの更新に失敗すると、サーバーによって状態が解放されることがあります。
クライアントのキャッシュと委譲
キャッシュは以前のバージョンと似ています。属性とディレクトリーのキャッシュのタイムアウトが、クライアントによって決定されます。NFS 4.0 の委譲により、サーバーがクライアントに特定の役割を割り当てることができます。これにより、特定のファイル共有セマンティクスが確保され、サーバーとの直接のやり取りなしでローカルファイル操作が可能になります。

5.2. AUTH_SYS 認証方式
リンクのコピー

AUTH_SYS 方式 (AUTH_UNIX とも呼ばれます) は、クライアント認証メカニズムです。AUTH_SYS を使用すると、クライアントがファイルにアクセスするときに、ユーザーのアイデンティティーと権限を確認するために、ユーザーのユーザー ID (UID) とグループ ID (GID) をサーバーに送信します。AUTH_SYS は、クライアントが提供する情報に依存するため、誤って設定された場合に不正アクセスを受ける可能性があり、セキュリティーが低いと考えられています。

マッピングメカニズムにより、UID と GID の割り当てがシステム間で異なる場合でも、NFS クライアントが適切な権限でサーバー上のファイルにアクセスできます。UID と GID は、次のメカニズムによって NFS クライアントとサーバーの間でマッピングされます。

直接マッピング

UID と GID は、NFS サーバーとクライアントによってローカルシステムとリモートシステム間で直接マッピングされます。これを行うには、NFS ファイル共有に参加しているすべてのシステム間で一貫した UID と GID の割り当てが必要です。たとえば、クライアント上の UID 1000 のユーザーは、サーバー上の UID 1000 のユーザーがアクセスできる共有上のファイルにのみアクセスできます。

管理者は、NFS 環境での ID 管理を簡素化するために、多くの場合、LDAP やネットワーク情報サービス (NIS) などの集中型サービスを利用して、複数のシステムにわたる UID と GID のマッピングを管理します。

ユーザー ID とグループ ID のマッピング
NFS サーバーおよびクライアントは、idmapd サービスを使用して、異なるシステム間で UID と GID を変換し、一貫した ID 識別と権限の割り当てを実現できます。

5.3. AUTH_GSS 認証方式
リンクのコピー

Kerberos は、セキュアでないネットワーク上でクライアントとサーバーのセキュアな認証を可能にするネットワーク認証プロトコルです。対称鍵暗号を使用し、ユーザーとサービスを認証するために、信頼できる Key Distribution Center (KDC) を必要とします。

AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、ファイルにアクセスしているユーザーを正しく表すために、サーバーがクライアントに依存することがありません。代わりに、暗号化を使用してサーバーに対してユーザーを認証します。これにより、悪意のあるクライアントがユーザーの Kerberos 認証情報を持たないユーザーになりすますことを防ぎます。

/etc/exports ファイルの sec オプションで、共有が提供する Kerberos セキュリティー方式を 1 つ以上定義します。クライアントはこれらの方法のいずれかを使用して共有をマウントできます。sec オプションは次の値をサポートします。

  • sys: 暗号化保護なし (デフォルト)
  • krb5: 認証のみ
  • krb5i: 認証と整合性保護
  • krb5p: 認証、整合性チェック、およびトラフィック暗号化

方式が提供する暗号化機能が多いほど、パフォーマンスが低下することに注意してください。

5.4. エクスポートされたファイルシステムのファイル権限
リンクのコピー

エクスポートされたファイルシステムのファイル権限によって、NFS 経由でファイルとディレクトリーにアクセスするクライアントのアクセス権が決まります。

NFS ファイルシステムがリモートホストによってマウントされると、各共有ファイルに対する保護がファイルシステムの権限だけになります。同じユーザー ID (UID) の値を共有する 2 つのユーザーが、異なるクライアントシステムに同じ NFS ファイルシステムをマウントした場合、そのユーザーはお互いのファイルを変更できます。

NFS は、クライアント上の root ユーザーをサーバー上の root ユーザーと同等のものとして扱います。ただし、NFS サーバーは、NFS 共有にアクセスするときに、デフォルトで root を nobody アカウントにマップします。この動作は root_squash オプションにより制御します。

5.5. NFS サーバーに必要なサービス
リンクのコピー

Red Hat Enterprise Linux (RHEL) は、NFS ファイル共有を提供するのに、カーネルモジュールとユーザー空間プロセスの組み合わせを使用します。

Expand
表5.1 NFS サーバーに必要なサービス
Service nameNFS バージョン説明

nfsd

3、4

共有 NFS ファイルシステムに対する要求を処理する NFS カーネルモジュール。

rpcbind

3

このプロセスは、ローカルのリモートプロシージャーコール (RPC) サービスからのポート予約を受け入れ、それを使用可能にするかアドバタイズして、対応するリモート RPC サービスがポート予約にアクセスできるようにします。rpcbind サービスは、要求に応答し、指定された RPC サービスへの接続を設定します。

rpc.mountd

3、4

このサービスは NFSv3 クライアントからの MOUNT 要求を処理します。NFSv4 サーバーはこのサービスの内部機能を使用します。

要求されている NFS 共有が現在 NFS サーバーによりエクスポートされているか、またその共有へのクライアントのアクセスが許可されているかを確認します。

rpc.nfsd

3、4

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

nfs-server サービスがこのプロセスを起動します。

lockd

3

このカーネルモジュールは、Network Lock Manager (NLM) プロトコルを実装します。これにより、クライアントがサーバー上のファイルをロックできるようになります。RHEL は、NFS サーバーの実行時にこのモジュールを自動的にロードします。

rpc.rquotad

3、4

このサービスは、リモートユーザーのユーザークォータ情報を提供します。

rpc.idmapd

4

このプロセスは、NFSv4 名 (`user@domain` 形式の文字列) とローカルのユーザー ID およびグループ ID をマッピングする NFSv4 クライアントおよびサーバーのアップコールを提供します。

gssproxy

3、4

このサービスは、rpc.nfsd に代わって krb5 認証を処理します。

nfsdcld

4

このサービスは、NFSv4 クライアント追跡デーモンを提供します。このデーモンは、ネットワークパーティションとサーバーの再起動中に他のクライアントが競合するロックを取得したときに、サーバーがロックの回収を許可するのを防止します。

rpc.statd

3

このサービスは、ローカルホストが再起動したときに他の NFSv3 クライアントに通知し、リモート NFSv3 ホストが再起動したときにカーネルに通知します。

5.6. /etc/exports 設定ファイル
リンクのコピー

/etc/exports ファイルは、サーバーがエクスポートするディレクトリーを制御します。各行に、エクスポートポイント、ディレクトリーのマウントが許可されているクライアントの空白区切りのリスト、および各クライアントのオプションが含まれています。 

<directory> <host_or_network_1>(<options_1>) <host_or_network_n>(<options_n>)...

以下は /etc/exports のエントリーの各部分です。

<directory>
エクスポートするディレクトリー。
<host_or_network>
エクスポートを共有するホストまたはネットワーク。たとえば、ホスト名、IP アドレス、または IP ネットワークを指定できます。
<options>
ホストまたはネットワークのオプション。

クライアントとオプションの間にスペースを追加すると、動作が変わります。たとえば、次の行はそれぞれ意味が異なります。 

/projects	client.example.com(rw)
/projects	client.example.com (rw)

最初の行では、サーバーは client.example.com にのみ、/projects ディレクトリーを読み取り/書き込みモードでマウントすることを許可します。他のホストは共有をマウントできません。一方、2 番目の行では、client.example.com と (rw) の間にスペースがあるため、サーバーはディレクトリーを読み取り専用モード (デフォルト設定) で client.example.com にエクスポートします。他のすべてのホストは、読み取り/書き込みモードで共有をマウントできます。

NFS サーバーは、エクスポートされた各ディレクトリーに対して次のデフォルト設定を使用します。

Expand
表5.2 /etc/exports のエントリーのデフォルトオプション
デフォルト設定説明

ro

ディレクトリーを読み取り専用モードでエクスポートします。

sync

NFS サーバーは、以前の要求で発生した変更がディスクに書き込まれるまで、要求に応答しません。

wdelay

別の書き込み要求が保留中であると疑われる場合、サーバーはディスクへの書き込みを遅延します。

root_squash

クライアントの root ユーザーがエクスポートされたディレクトリーに対して root 権限を持つことを防ぎます。root_squash を有効にすると、NFS サーバーは root からのアクセスをユーザー nobody にマッピングします。

5.7. NFSv4 専用サーバーの設定
リンクのコピー

ネットワーク内に NFSv3 クライアントが存在しない場合は、NFSv4 またはその特定のマイナープロトコルバージョンのみをサポートするように NFS サーバーを設定できます。サーバー上で NFSv4 のみを使用すると、ネットワークに開放されるポートの数が減ります。

手順

  1. nfs-utils パッケージをインストールします。 

    # dnf install nfs-utils

  2. /etc/nfs.conf ファイルを編集し、次の変更を加えます。

    1. NFSv3 を無効にするには、[nfsd] セクションの vers3 パラメーターを無効にします。 

      [nfsd]
vers3=n

    2. オプション: 特定の NFSv4 マイナーバージョンのみが必要な場合は、すべての vers4.<minor_version> パラメーターのコメントを解除し、各パラメーターを適切に設定します。次に例を示します。 

      [nfsd]
vers3=n
# vers4=y
vers4.0=n
vers4.1=n
vers4.2=y

      この設定では、サーバーは NFS バージョン 4.2 のみを提供します。

      重要

      特定の NFSv4 マイナーバージョンのみが必要な場合は、そのマイナーバージョンのパラメーターのみを設定してください。予期しないマイナーバージョンのアクティブ化や非アクティブ化を回避するために、vers4 パラメーターのコメントは解除しないでください。vers4 パラメーターは、デフォルトですべての NFSv4 マイナーバージョンを有効または無効にします。ただし、vers4 を他の vers パラメーターと組み合わせて設定すると、この動作は変わります。

  3. NFSv3 関連のすべてのサービスを無効にします。 

    # systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket

  4. NFSv3 マウント要求をリッスンしないように rpc.mountd デーモンを設定します。次の内容を含む /etc/systemd/system/nfs-mountd.service.d/v4only.conf ファイルを作成します。 

    [Service]
ExecStart=
ExecStart=/usr/sbin/rpc.mountd --no-tcp --no-udp

  5. systemd マネージャーの設定を再ロードし、nfs-mountd サービスを再起動します。 

    # systemctl daemon-reload
# systemctl restart nfs-mountd

  6. オプション: 共有するディレクトリーを作成します。以下に例を示します。 

    # mkdir -p /nfs/projects/

    既存のディレクトリーを共有する場合は、このステップをスキップしてください。

  7. /nfs/projects/ ディレクトリーに必要な権限を設定します。 

    # chmod 2770 /nfs/projects/
# chgrp users /nfs/projects/

    これらのコマンドは、/nfs/projects/ ディレクトリーの users グループの書き込み権限を設定し、このディレクトリーに作成される新しいエントリーに対して同じグループを自動的に設定します。

  8. 共有する各ディレクトリーについて、/etc/exports ファイルにエクスポートポイントを追加します。 

    /nfs/projects/     192.0.2.0/24(rw) 2001:db8::/32(rw)

    このエントリーは、/nfs/projects/ ディレクトリーを共有し、192.0.2.0/24 および 2001:db8::/32 サブネット内のクライアントに読み取りおよび書き込みアクセスを許可します。

  9. firewalld で適切なポートを開きます。 

    # firewall-cmd --permanent --add-service nfs
# firewall-cmd --reload

  10. NFS サーバーを有効にして起動します。 

    # systemctl enable --now nfs-server

検証

  • サーバー上で、設定した NFS バージョンのみがサーバーから提供されていることを確認します。 

    # cat /proc/fs/nfsd/versions
-3 +4 -4.0 -4.1 +4.2

  • クライアントで次の手順を実行します。

    1. nfs-utils パッケージをインストールします。 

      # dnf install nfs-utils

    2. エクスポートされた NFS 共有をマウントします。 

      # mount server.example.com:/nfs/projects/ /mnt/

    3. users グループのメンバーであるユーザーとして、/mnt/ にファイルを作成します。 

      # touch /mnt/file

    4. ファイルが作成されたことを確認するためにディレクトリーの内容をリスト表示します。 

      # ls -l /mnt/
total 0
-rw-r--r--. 1 demo users 0 Jan 16 14:18 file

5.8. オプションの NFSv4 サポートを備えた NFSv3 サーバーの設定
リンクのコピー

NFSv3 クライアントを現在も使用しているネットワークでは、NFSv3 プロトコルを使用して共有を提供するようにサーバーを設定します。ネットワーク内に新しいクライアントもある場合は、さらに NFSv4 を有効にできます。デフォルトでは、Red Hat Enterprise Linux の NFS クライアントは、サーバーが提供する最新の NFS バージョンを使用します。

手順

  1. nfs-utils パッケージをインストールします。 

    # dnf install nfs-utils

  2. オプション: デフォルトでは、NFSv3 と NFSv4 が有効になっています。NFSv4 が必要ない場合、または特定のマイナーバージョンのみが必要な場合は、すべての vers4.<minor_version> パラメーターのコメントを解除し、各パラメーターを適切に設定します。 

    [nfsd]
# vers3=y
# vers4=y
vers4.0=n
vers4.1=n
vers4.2=y

    この設定では、サーバーは NFS バージョン 3 と 4.2 のみを提供します。

    重要

    特定の NFSv4 マイナーバージョンのみが必要な場合は、そのマイナーバージョンのパラメーターのみを設定してください。予期しないマイナーバージョンのアクティブ化や非アクティブ化を回避するために、vers4 パラメーターのコメントは解除しないでください。vers4 パラメーターは、デフォルトですべての NFSv4 マイナーバージョンを有効または無効にします。ただし、vers4 を他の vers パラメーターと組み合わせて設定すると、この動作は変わります。

  3. デフォルトでは、NFSv3 の RPC サービスはランダムなポートを使用します。ファイアウォール設定を有効にするには、/etc/nfs.conf ファイルで固定ポート番号を設定します。

    1. [lockd] セクションで、nlockmgr RPC サービスの固定ポート番号を設定します。以下に例を示します。 

      [lockd]
port=5555

      この設定により、サービスが UDP プロトコルと TCP プロトコルの両方にこのポート番号を自動的に使用するようになります。

    2. [statd] セクションで、rpc.statd サービスの固定ポート番号を設定します。以下に例を示します。 

      [statd]
port=6666

      この設定により、サービスが UDP プロトコルと TCP プロトコルの両方にこのポート番号を自動的に使用するようになります。

  4. オプション: 共有するディレクトリーを作成します。以下に例を示します。 

    # mkdir -p /nfs/projects/

    既存のディレクトリーを共有する場合は、このステップをスキップしてください。

  5. /nfs/projects/ ディレクトリーに必要な権限を設定します。 

    # chmod 2770 /nfs/projects/
# chgrp users /nfs/projects/

    これらのコマンドは、/nfs/projects/ ディレクトリーの users グループの書き込み権限を設定し、このディレクトリーに作成される新しいエントリーに対して同じグループを自動的に設定します。

  6. 共有する各ディレクトリーについて、/etc/exports ファイルにエクスポートポイントを追加します。 

    /nfs/projects/     192.0.2.0/24(rw) 2001:db8::/32(rw)

    このエントリーは、/nfs/projects/ ディレクトリーを共有し、192.0.2.0/24 および 2001:db8::/32 サブネット内のクライアントに読み取りおよび書き込みアクセスを許可します。

  7. firewalld で適切なポートを開きます。 

    # firewall-cmd --permanent --add-service={nfs,rpc-bind,mountd}
# firewall-cmd --permanent --add-port={5555/tcp,5555/udp,6666/tcp,6666/udp}
# firewall-cmd --reload

  8. NFS サーバーを有効にして起動します。 

    # systemctl enable --now rpc-statd nfs-server

検証

  • サーバー上で、設定した NFS バージョンのみがサーバーから提供されていることを確認します。 

    # cat /proc/fs/nfsd/versions
+3 +4 -4.0 -4.1 +4.2

  • クライアントで次の手順を実行します。

    1. nfs-utils パッケージをインストールします。 

      # dnf install nfs-utils

    2. エクスポートされた NFS 共有をマウントします。 

      # mount -o vers=<version> server.example.com:/nfs/projects/ /mnt/

    3. 指定した NFS バージョンを使用して共有がマウントされたことを確認します。 

      # mount | grep "/mnt"
server.example.com:/nfs/projects/ on /mnt type nfs (rw,relatime,vers=3,...

    4. users グループのメンバーであるユーザーとして、/mnt/ にファイルを作成します。 

      # touch /mnt/file

    5. ファイルが作成されたことを確認するためにディレクトリーの内容をリスト表示します。 

      # ls -l /mnt/
total 0
-rw-r--r--. 1 demo users 0 Jan 16 14:18 file

5.9. NFS サーバーでクォータサポートを有効にする
リンクのコピー

ユーザーまたはグループが保存できるデータの量を制限する場合は、ファイルシステムにクォータを設定できます。クォータは、NFS サーバー上の rpc-rquotad サービスにより、NFS クライアント上のユーザーにも適用されます。

前提条件

  • NFS サーバーが実行および設定されている。
  • ext または XFS ファイルシステムにクォータが設定されています。

手順

  1. エクスポートするディレクトリーでクォータが有効になっていることを確認します。

    • ext ファイルシステムの場合は、次のように入力します。 

      # quotaon -p /nfs/projects/
group quota on /nfs/projects (/dev/sdb1) is on
user quota on /nfs/projects (/dev/sdb1) is on
project quota on /nfs/projects (/dev/sdb1) is off

    • XFS ファイルシステムの場合は、次のように入力します。 

      # findmnt /nfs/projects
TARGET    	SOURCE	FSTYPE OPTIONS
/nfs/projects /dev/sdb1 xfs	rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,usrquota,grpquota

  2. quota-rpc パッケージをインストールします。 

    # dnf install quota-rpc

  3. オプション: デフォルトでは、クォータ RPC サービスはポート 875 で実行されます。別のポートでサービスを実行する場合は、/etc/sysconfig/rpc-rquotad ファイルの RPCRQUOTADOPTS 変数に -p <port_number> を追加します。 

    RPCRQUOTADOPTS="-p __<port_number>__"

  4. オプション: デフォルトでは、リモートホストはクォータの読み取りのみが可能です。クライアントにクォータの設定を許可するには、/etc/sysconfig/rpc-rquotad ファイルの RPCRQUOTADOPTS 変数に -S オプションを追加します。 

    RPCRQUOTADOPTS="-S"

  5. firewalld でポートを開きます。 

    # firewall-cmd --permanent --add-port=875/udp
# firewall-cmd --reload

  6. rpc-rquotad サービスを有効にして起動します。 

    # systemctl enable --now rpc-rquotad

検証

  1. クライアントで以下を実行します。

    1. エクスポートされた共有をマウントします。 

      # mount server.example.com:/nfs/projects/ /mnt/

    2. クォータを表示します。コマンドは、エクスポートされたディレクトリーのファイルシステムによって異なります。以下に例を示します。

      • マウントした全 ext ファイルシステムの特定ユーザーのクォータを表示するには、次のように入力します。 

        # quota -u <user_name>
Disk quotas for user demo (uid 1000):
     Filesystem     space     quota     limit     grace     files     quota      limit     grace
server.example.com:/nfs/projects
             0K       100M      200M                  0         0         0

      • XFS ファイルシステムのユーザーおよびグループのクォータを表示するには、次のように入力します。 

        # xfs_quota -x -c "report -h" /mnt/
User quota on /nfs/projects (/dev/vdb1)
            Blocks
User ID     Used     Soft     Hard     Warn/Grace
---------- ---------------------------------
root        0        0        0        00 [------]
demo        0        100M     200M     00 [------]

5.10. NFS サーバーで NFS over RDMA を有効にする
リンクのコピー

NFS サーバーとクライアントの両方が RDMA 経由で接続されている場合、クライアントは NFS over Remote Direct Memory Access (NFSoRDMA) を使用してエクスポートされたディレクトリーをマウントできます。

RDMA は、クライアントシステムがストレージサーバーのメモリーから自身のメモリーへデータを直接転送することを可能にするプロトコルです。これにより、ストレージのスループットが向上し、サーバーとクライアント間のデータ転送の遅延が減少し、両側の CPU 負荷が軽減されます。

前提条件

  • NFS サービスが実行および設定されている。
  • InfiniBand または RDMA over Converged Ethernet (RoCE) デバイスがサーバーにインストールされている。
  • サーバーに IP over InfiniBand (IPoIB) が設定され、InfiniBand デバイスに IP アドレスが割り当てられている。

手順

  1. rdma-core パッケージをインストールします。 

    # dnf install rdma-core

  2. パッケージがすでにインストールされている場合は、/etc/rdma/modules/rdma.conf ファイル内の xprtrdma および svcrdma モジュールのコメントが解除されていることを確認します。 

    # NFS over RDMA client support
xprtrdma
# NFS over RDMA server support
svcrdma

  3. オプション: デフォルトでは、NFS over RDMA はポート 20049 を使用します。別のポートを使用する場合は、/etc/nfs.conf ファイルの [nfsd] セクションで rdma-port 設定を指定します。 

    rdma-port=<port>

  4. firewalld で NFSoRDMA ポートを開きます。 

    # firewall-cmd --permanent --add-port={20049/tcp,20049/udp}
# firewall-cmd --reload

    20049 以外のポートを設定する場合は、ポート番号を変更します。

  5. nfs-server サービスを再起動します。 

    # systemctl restart nfs-server

検証

  1. InfiniBand ハードウェアを搭載したクライアントで、次の手順を実行します。

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

      # dnf install nfs-utils rdma-core

    2. エクスポートされた NFS 共有を RDMA 経由でマウントします。 

      # mount -o rdma server.example.com:/nfs/projects/ /mnt/

      デフォルト (20049) 以外のポート番号を設定する場合は、コマンドに port=<port_number> を渡します。 

      # mount -o rdma,port=<port_number> server.example.com:/nfs/projects/ /mnt/

    3. rdma オプションを使用して共有がマウントされたことを確認します。 

      # mount | grep "/mnt"
server.example.com:/nfs/projects/ on /mnt type nfs (...,proto=rdma,...)

Red Hat Enterprise Linux Identity Management (IdM) を使用すると、NFS サーバーを IdM ドメインに参加させることができます。これにより、ユーザーとグループを一元管理し、認証、整合性保護、トラフィック暗号化に Kerberos を使用できるようになります。

前提条件

  • NFS サーバーが Red Hat Enterprise Linux Identity Management (IdM) ドメインに 登録されている。
  • NFS サーバーが実行および設定されている。

手順

  1. IdM 管理者として Kerberos チケットを取得します。 

    # kinit admin

  2. nfs/<FQDN> サービスプリンシパルを作成します。 

    # ipa service-add nfs/nfs_server.idm.example.com

  3. IdM から nfs サービスプリンシパルを取得し、/etc/krb5.keytab ファイルに保存します。 

    # ipa-getkeytab -s idm_server.idm.example.com -p nfs/nfs_server.idm.example.com -k /etc/krb5.keytab

  4. オプション: /etc/krb5.keytab ファイル内のプリンシパルを表示します。 

    # klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 nfs/nfs_server.idm.example.com@IDM.EXAMPLE.COM
   1 nfs/nfs_server.idm.example.com@IDM.EXAMPLE.COM
   1 nfs/nfs_server.idm.example.com@IDM.EXAMPLE.COM
   1 nfs/nfs_server.idm.example.com@IDM.EXAMPLE.COM
   7 host/nfs_server.idm.example.com@IDM.EXAMPLE.COM
   7 host/nfs_server.idm.example.com@IDM.EXAMPLE.COM
   7 host/nfs_server.idm.example.com@IDM.EXAMPLE.COM
   7 host/nfs_server.idm.example.com@IDM.EXAMPLE.COM

    デフォルトでは、ホストを IdM ドメインに参加させると、IdM クライアントがホストプリンシパルを /etc/krb5.keytab ファイルに追加します。ホストプリンシパルがない場合は、ipa-getkeytab -s idm_server.idm.example.com -p host/nfs_server.idm.example.com -k /etc/krb5.keytab コマンドを使用して追加します。

  5. ipa-client-automount ユーティリティーを使用して、IdM ID のマッピングを設定します。 

    #  ipa-client-automount
Searching for IPA server...
IPA server: DNS discovery
Location: default
Continue to configure the system with these values? [no]: yes
Configured /etc/idmapd.conf
Restarting sssd, waiting for it to become available.
Started autofs

  6. /etc/exports ファイルを更新し、クライアントオプションに Kerberos セキュリティー方式を追加します。以下に例を示します。 

    /nfs/projects/      	192.0.2.0/24(rw,sec=krb5i)

    クライアントが複数のセキュリティー方式を選択できるようにするには、それらをコロンで区切って指定します。 

    /nfs/projects/      	192.0.2.0/24(rw,sec=krb5:krb5i:krb5p)

  7. エクスポートされたファイルシステムを再ロードします。 

    # exportfs -r

第6章 Squid キャッシングプロキシーサーバーの設定
リンクのコピー

Squid は、コンテンツをキャッシュして帯域幅を削減し、Web ページをより迅速に読み込むプロキシーサーバーです。この章では、HTTP、HTTPS、FTP のプロトコルのプロキシーとして Squid を設定する方法と、アクセスの認証および制限を説明します。

6.1. 認証なしで Squid をキャッシングプロキシーとして設定
リンクのコピー

認証なしで Squid をキャッシュプロキシーとして設定できます。以下の手順では、IP 範囲に基づいてプロキシーへのアクセスを制限します。

前提条件

  • /etc/squid/squid.conf ファイルが、squid パッケージにより提供されている。このファイルを編集した場合は、ファイルを削除して、パッケージを再インストールしている。

手順

  1. squid パッケージをインストールします。 

    # yum install squid

  2. /etc/squid/squid.conf ファイルを編集します。

    1. 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 エントリーをすべて削除します。

    2. 以下の ACL はデフォルト設定にあり、HTTPS プロトコルを使用するポートとして 443 を定義します。 

      acl SSL_ports port 443

      ユーザーが他のポートでも HTTPS プロトコルを使用できるようにするには、ポートごとに ACL を追加します。 

      acl SSL_ports port port_number

    3. 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 で定義されていないポートへのアクセス拒否を定義します。

    4. 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 はキャッシュをメモリーに保存します。

  3. cache_dir パラメーターに /var/spool/squid/ 以外のキャッシュディレクトリーを設定する場合は、以下を行います。

    1. キャッシュディレクトリーを作成します。 

      # mkdir -p path_to_cache_directory

    2. キャッシュディレクトリーの権限を設定します。 

      # chown squid:squid path_to_cache_directory

    3. 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 パッケージをインストールします。

  4. ファイアウォールで 3128 ポートを開きます。 

    # firewall-cmd --permanent --add-port=3128/tcp
# firewall-cmd --reload

  5. squid サービスを有効にして開始します。 

    # systemctl enable --now squid

検証

プロキシーが正しく機能することを確認するには、curl ユーティリティーを使用して Web ページをダウンロードします。 

# curl -O -L "https://www.redhat.com/index.html" -x "proxy.example.com:3128"

curl でエラーが表示されず、index.html ファイルが現在のディレクトリーにダウンロードされている場合は、プロキシーが動作します。

6.2. LDAP 認証を使用したキャッシングプロキシーとしての Squid の設定
リンクのコピー

Squid を、LDAP を使用してユーザーを認証するキャッシングプロキシーとして設定できます。この手順では、認証されたユーザーのみがプロキシーを使用できるように設定します。

前提条件

  • /etc/squid/squid.conf ファイルが、squid パッケージにより提供されている。このファイルを編集した場合は、ファイルを削除して、パッケージを再インストールしている。
  • uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com などのサービスユーザーが LDAP ディレクトリーに存在します。Squid はこのアカウントを使用して認証ユーザーを検索します。認証ユーザーが存在する場合、Squid はこのユーザーをディレクトリーにバインドして、認証を確認します。

手順

  1. squid パッケージをインストールします。 

    # yum install squid

  2. /etc/squid/squid.conf ファイルを編集します。

    1. 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 は、LDAP 検索フィルターを指定します。Squid は、%s 変数を、認証ユーザーにより提供されるユーザー名に置き換えます。

        上記の例の (&(objectClass=person)(uid=%s)) フィルターは、ユーザー名が uid 属性に設定された値と一致する必要があり、ディレクトリーエントリーに person オブジェクトクラスが含まれることを定義します。

      • -ZZ は、STARTTLS コマンドを使用して、LDAP プロトコルで TLS 暗号化接続を強制します。以下の状況で -ZZ を省略します。

        • LDAP サーバーは、暗号化された接続に対応しません。
        • URL に指定されたポートは、LDAPS プロトコルを使用します。
      • -H LDAP_URL パラメーターは、プロトコル、ホスト名、IP アドレス、および LDAP サーバーのポートを URL 形式で指定します。

    2. 以下の ACL およびルールを追加して、Squid で、認証されたユーザーのみがプロキシーを使用できるように設定します。 

      acl ldap-auth proxy_auth REQUIRED
http_access allow ldap-auth
      重要

      http_access deny all ルールの前にこの設定を指定します。

    3. 次のルールを削除して、localnet ACL で指定された IP 範囲のプロキシー認証の回避を無効にします。 

      http_access allow localnet

    4. 以下の ACL はデフォルト設定にあり、HTTPS プロトコルを使用するポートとして 443 を定義します。 

      acl SSL_ports port 443

      ユーザーが他のポートでも HTTPS プロトコルを使用できるようにするには、ポートごとに ACL を追加します。 

      acl SSL_ports port port_number

    5. 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 で定義されていないポートへのアクセス拒否を定義します。

    6. 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 はキャッシュをメモリーに保存します。

  3. cache_dir パラメーターに /var/spool/squid/ 以外のキャッシュディレクトリーを設定する場合は、以下を行います。

    1. キャッシュディレクトリーを作成します。 

      # mkdir -p path_to_cache_directory

    2. キャッシュディレクトリーの権限を設定します。 

      # chown squid:squid path_to_cache_directory

    3. 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 パッケージをインストールします。

  4. LDAP サービスユーザーのパスワードを /etc/squid/ldap_password ファイルに保存し、ファイルに適切なパーミッションを設定します。 

    # echo "password" > /etc/squid/ldap_password
# chown root:squid /etc/squid/ldap_password
# chmod 640 /etc/squid/ldap_password

  5. ファイアウォールで 3128 ポートを開きます。 

    # firewall-cmd --permanent --add-port=3128/tcp
# firewall-cmd --reload

  6. 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 ファイルが現在のディレクトリーにダウンロードされている場合は、プロキシーが動作します。

トラブルシューティングの手順

ヘルパーユーティリティーが正しく機能していることを確認するには、以下の手順を行います。

  1. 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

  2. 有効なユーザー名とパスワードを入力し、Enter を押します。 

    user_name password

    ヘルパーユーティリティーが OK を返すと、認証に成功しました。

6.3. kerberos 認証を使用したキャッシングプロキシーとしての Squid の設定
リンクのコピー

Squid を、Kerberos を使用して Active Directory (AD) に対してユーザーを認証するキャッシングプロキシーとして設定できます。この手順では、認証されたユーザーのみがプロキシーを使用できるように設定します。

前提条件

  • /etc/squid/squid.conf ファイルが、squid パッケージにより提供されている。このファイルを編集した場合は、ファイルを削除して、パッケージを再インストールしている。

手順

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

    # yum install squid krb5-workstation

  2. AD ドメイン管理者として認証します。 

    # kinit administrator@AD.EXAMPLE.COM

  3. Squid 用のキータブを作成し、それを /etc/squid/HTTP.keytab ファイルに保存し、HTTP サービスプリンシパルをキータブに追加します。 

    # export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
# net ads keytab CREATE -U administrator
# net ads keytab ADD HTTP -U administrator

  4. オプション: システムが (adcli 経由で) 最初にレルムを使用して AD ドメインに参加している場合、次の手順に従って HTTP プリンシパルを追加し、squid 用のキータブファイルを作成します。

    1. HTTP サービスプリンシパルをデフォルトのキータブファイル /etc/krb5.keytab に追加し、検証します。 

      # adcli update -vvv --domain=ad.example.com --computer-name=PROXY --add-service-principal="HTTP/proxy.ad.example.com" -C
# klist -kte /etc/krb5.keytab | grep -i HTTP

    2. /etc/krb5.keytab ファイルをロードし、HTTP 以外のすべてのサービスプリンシパルを削除し、残りのプリンシパルを /etc/squid/HTTP.keytab ファイルに保存します。 

      # ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  l -e
slot | KVNO | Principal
-----------------------------------------------------------------------------
1 |    2 |            PROXY$@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
2 |    2 |            PROXY$@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
3 |    2 |         host/PROXY@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
4 |    2 |         host/PROXY@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
5 |    2 | host/proxy.ad.example.com@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
6 |    2 | host/proxy.ad.example.com@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
7 |    2 | HTTP/proxy.ad.example.com@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
8 |    2 | HTTP/proxy.ad.example.com@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)

      ktutil の対話型シェルで、さまざまなオプションを使用して、不要なプリンシパルをすべてキータブから削除できます。次に例を示します。 

      ktutil:  delent 1
       
      ktutil:  l -e

slot | KVNO | Principal
-------------------------------------------------------------------------------
1 |   2 | HTTP/proxy.ad.example.com@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
2 |   2 | HTTP/proxy.ad.example.com@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)

ktutil:  wkt /etc/squid/HTTP.keytab
ktutil:  q
      警告

      SSSD または Samba/winbind がマシンアカウントのパスワードを更新すると、/etc/krb5.keytab 内のキーが更新される可能性があります。更新後、/etc/squid/HTTP.keytab 内のキーは機能しなくなるため、ktutil の手順を再度実行して新しいキーをキータブにコピーする必要があります。

  5. キータブファイルの所有者を squid ユーザーに設定します。 

    # chown squid /etc/squid/HTTP.keytab

  6. オプション: キータブファイルに、プロキシーサーバーの完全修飾ドメイン名 (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
...

  7. /etc/squid/squid.conf ファイルを編集します。

    1. 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 ファイルにデバッグ情報のログに記録します。

    2. 以下の ACL およびルールを追加して、Squid で、認証されたユーザーのみがプロキシーを使用できるように設定します。 

      acl kerb-auth proxy_auth REQUIRED
http_access allow kerb-auth
      重要

      http_access deny all ルールの前にこの設定を指定します。

    3. 次のルールを削除して、localnet ACL で指定された IP 範囲のプロキシー認証の回避を無効にします。 

      http_access allow localnet

    4. 以下の ACL はデフォルト設定にあり、HTTPS プロトコルを使用するポートとして 443 を定義します。 

      acl SSL_ports port 443

      ユーザーが他のポートでも HTTPS プロトコルを使用できるようにするには、ポートごとに ACL を追加します。 

      acl SSL_ports port port_number

    5. 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 で定義されていないポートへのアクセス拒否を定義します。

    6. 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 はキャッシュをメモリーに保存します。

  8. cache_dir パラメーターに /var/spool/squid/ 以外のキャッシュディレクトリーを設定する場合は、以下を行います。

    1. キャッシュディレクトリーを作成します。 

      # mkdir -p path_to_cache_directory

    2. キャッシュディレクトリーの権限を設定します。 

      # chown squid:squid path_to_cache_directory

    3. 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 パッケージをインストールします。

  9. ファイアウォールで 3128 ポートを開きます。 

    # firewall-cmd --permanent --add-port=3128/tcp
# firewall-cmd --reload

  10. 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 ファイルが現在のディレクトリーに存在すると、プロキシーが機能します。

トラブルシューティングの手順

  1. AD アカウントの Kerberos チケットを取得します。 

    # kinit user@AD.EXAMPLE.COM

  2. オプション: チケットを表示します。 

    # klist

  3. negotiate_kerberos_auth_test ユーティリティーを使用して認証をテストします。 

    # /usr/lib64/squid/negotiate_kerberos_auth_test proxy.ad.example.com

    ヘルパーユーティリティーがトークンを返す場合は、認証に成功しました。 

    Token: YIIFtAYGKwYBBQUCoIIFqDC...

6.4. Squid でのドメイン拒否リストの設定
リンクのコピー

多くの場合、管理者は特定のドメインへのアクセスをブロックする必要があります。このセクションでは、Squid でドメインの拒否リストを設定する方法を説明します。

前提条件

  • Squid が設定され、ユーザーはプロキシーを使用できます。

手順

  1. /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 ステートメントの前にこれらのエントリーを追加します。

  2. /etc/squid/domain_deny_list.txt ファイルを作成し、ブロックするドメインを追加します。たとえば、サブドメインを含む example.com へのアクセスをブロックして、example.net をブロックするには、以下を追加します。 

    .example.com
example.net
    重要

    squid 設定の /etc/squid/domain_deny_list.txt ファイルを参照している場合は、このファイルは空にすることはできません。このファイルが空の場合、Squid は起動できません。

  3. squid サービスを再開します。 

    # systemctl restart squid

6.5. Squid サービスが特定のポートまたは IP アドレスをリッスンするように設定
リンクのコピー

デフォルトでは、Squid プロキシーサービスは、すべてのネットワークインターフェイスの 3128 ポートでリッスンします。ポートを変更し、Squid が特定の IP アドレスをリッスンするように設定できます。

前提条件

  • squid パッケージがインストールされている。

手順

  1. /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

  2. Squid が別のポートをデフォルト (3128) として使用するように設定する場合は、以下のようになります。

    1. ファイアウォールのポートを開きます。 

      # firewall-cmd --permanent --add-port=port_number/tcp
# firewall-cmd --reload

    2. enforcing モードで SELinux を実行した場合は、ポートを squid_port_t ポートタイプ定義に割り当てます。 

      # semanage port -a -t squid_port_t -p tcp port_number

      semanage ユーティリティーがシステムで利用できない場合は、policycoreutils-python-utils パッケージをインストールします。

  3. squid サービスを再開します。 

    # systemctl restart squid

第7章 データベースサーバー
リンクのコピー

Red Hat Enterprise Linux 10 に MariaDB、MySQL、または PostgreSQL データベースサーバーをインストールします。選択したデータベースサーバーを設定し、データのバックアップを作成し、データを新しいバージョンのデータベースサーバーに移行します。

7.1. データベースサーバーの概要
リンクのコピー

データベースサーバーは、データベース管理システム (DBMS) の機能を提供するサービスです。DBMS は、データベース管理のためのユーティリティーを提供し、エンドユーザー、アプリケーション、およびデータベースと対話します。

Red Hat Enterprise Linux 8 は、以下のデータベース管理システムを提供します。

  • MariaDB 10.3
  • MariaDB 10.5 - RHEL 8.4 以降で利用できます。
  • MariaDB 10.11 - RHEL 8.10 以降で利用可能
  • MySQL 8.0
  • PostgreSQL 10
  • PostgreSQL 9.6
  • PostgreSQL 12 - RHEL 8.1.1 以降で利用できます。
  • PostgreSQL 13: RHEL 8.4 以降で利用できます。
  • PostgreSQL 15 - RHEL 8.8 以降で利用可能
  • PostgreSQL 16 - RHEL 8.10 以降で利用可能

7.2. MariaDB の使用
リンクのコピー

MariaDB サーバーは、高性能なオープンソースのリレーショナルデータベース管理システム (RDBMS) です。MySQL テクノロジーを基盤に構築されており、データアクセス用の強力な SQL インターフェイスと、複数のストレージエンジンのサポートなどの高度な機能を備えています。

RHEL システムへの MariaDB のインストールと設定方法、MariaDB データのバックアップ方法、以前の MariaDB バージョンからの移行方法、および MariaDB Galera Cluster を使用したデータベースのレプリケーション方法について学びます。

7.2.1. MariaDB のインストール
リンクのコピー

RHEL 8 では、アプリケーションストリームの初期バージョンとして MariaDB 10.3 が提供されます。RHEL 8 のマイナーリリースでは、より短いライフサイクルを持つモジュールとして、追加の MariaDB バージョンが提供されます。

RHEL 8 では、MariaDB サーバーは以下のバージョンで利用可能であり、それぞれが個別のストリームによって提供されます。

  • MariaDB 10.3
  • MariaDB 10.5 - RHEL 8.4 以降で利用できます。
  • MariaDB 10.11 - RHEL 8.10 以降で利用可能
重要

設計上、同じモジュールの 1 つのバージョン (ストリーム) のみをインストールでき、RPM パッケージが競合するため、MariaDB と MySQL を同じホストにインストールすることはできません。代わりに、コンテナー内でデータベースサーバーサービスを実行することもできます。単一ホスト上で複数の MariaDB および MySQL インスタンスを実行するためのコンテナーの使用方法については、 こちらを参照してください。

手順

  1. MariaDB サーバーパッケージをインストールするには、mariadb モジュールからストリーム (バージョン) を選択し、サーバー プロファイルを指定します。以下に例を示します。 

    # yum module install mariadb:10.3/server

  2. mariadb サービスを有効にして起動します。 

    # systemctl enable --now mariadb.service

  3. MariaDB 10.3 のインストール時にセキュリティーを強化するには、以下を入力してください。 

    $ mysql_secure_installation

    このコマンドは、完全にインタラクティブなスクリプトを起動して、プロセスの各ステップのプロンプトを表示します。このスクリプトを使用すると、次の方法でセキュリティーを改善できます。

    • root アカウントのパスワードの設定
    • 匿名ユーザーの削除

    • リモート root ログインの拒否 (ローカルホスト外)

      注記

      mysql_secure_installation スクリプトは、MariaDB 10.5 以降では不要になりました。セキュリティー強化機能は、MariaDB 10.5 以降のデフォルト動作の一部となっています。

パッケージから MariaDB または MySQL をインストールする場合、同じホスト上でこれらのサービスのうち 1 つのみ、かつその 1 つのバージョンのみを実行できます。代わりに、コンテナー内でサービスを実行することもできます。

次のような環境を構成できます。

  • 同じホスト上で MariaDB または MySQL の複数のインスタンスを実行したい。
  • MariaDB と MySQL の両方を同じホストで実行したい。
注記

データベースサーバーのコンテナー名とホストポートは異なっている必要があります。

前提条件

  • container-tools モジュールがインストールされている。

手順

  1. Red Hat カスタマーポータルアカウントを使用して、registry.redhat.io レジストリーに認証します。 

    # podman login registry.redhat.io

    すでにコンテナーレジストリーにログインしている場合は、このステップをスキップしてください。

  2. コンテナー内で MySQL 8.0 を実行する: 

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mysql_root_password> -p <host_port_1>:3306 rhel8/mysql-80

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  3. MariaDB 10.5 をコンテナー内で実行する: 

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_2>:3306 rhel8/mariadb-105

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  4. MariaDB 10.11 をコンテナー内で実行する: 

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_3>:3306 rhel8/mariadb-1011

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  5. クライアントがネットワーク上のデータベースサーバーにアクセスできるように、ファイアウォールでホストポートを開きます。 

    # firewall-cmd --permanent --add-port={<host_port>/tcp,<host_port>/tcp,...}
# firewall-cmd --reload

検証

  1. 実行中のコンテナーに関する情報を表示します。 

    $ podman ps

  2. データベースサーバーに接続し、root としてログインします。 

    # mysql -u root -p -h localhost -P <host_port> --protocol tcp

7.2.3. MariaDB の設定
リンクのコピー

MariaDB サーバーをネットワーク用に設定するには、以下の手順に従ってください。

手順

  1. /etc/my.cnf.d/mariadb-server.cnf ファイルの [mysqld] セクションを編集します。以下の設定ディレクティブを設定できます。

    • bind-address: サーバーがリッスンするアドレスです。設定可能なオプションは以下のとおりです。

      • ホスト名
      • IPv4 アドレス
      • IPv6 アドレス

    • skip-networking: サーバーが TCP/IP 接続をリッスンするかどうかを制御します。以下の値が使用できます。

      • 0 - すべてのクライアントをリッスンする
      • 1 - ローカルクライアントのみをリッスンする
    • port - MariaDB が TCP/IP 接続を待機するポート。

  2. mariadb サービスを再起動します。 

    # systemctl restart mariadb.service

7.2.4. MariaDB サーバーでの TLS 暗号化の設定
リンクのコピー

デフォルトでは、MariaDB は暗号化されていない接続を使用します。セキュアな接続では、MariaDB サーバーで TLS サポートを有効にし、クライアントが暗号化された接続を確立するように設定します。

7.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 のドキュメントを参照してください。

手順

  1. 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/

  2. MariaDB サーバーがファイルを読み込めるように、CA およびサーバー証明書にパーミッションを設定します。 

    # chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem

    証明書は、セキュアな接続が確立される前は通信の一部であるため、任意のクライアントは認証なしで証明書を取得できます。そのため、CA およびサーバーの証明書ファイルに厳密なパーミッションを設定する必要はありません。

  3. サーバーの秘密鍵を /etc/pki/tls/private/ ディレクトリーに保存します。 

    # mv <path>/server.example.com.key.pem /etc/pki/tls/private/

  4. サーバーの秘密鍵にセキュアなパーミッションを設定します。 

    # chmod 640 /etc/pki/tls/private/server.example.com.key.pem
# chgrp mysql /etc/pki/tls/private/server.example.com.key.pem

    承認されていないユーザーが秘密鍵にアクセスできる場合は、MariaDB サーバーへの接続は安全ではなくなります。

  5. SELinux コンテキストを復元します。 

    #  restorecon -Rv /etc/pki/tls/
7.2.4.2. MariaDB サーバーでの TLS 暗号化の設定
リンクのコピー

デフォルトでは、MariaDB は暗号化されていない接続を使用します。よりセキュアな接続のために、MariaDB サーバーで Transport Layer Security (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) フィールドが、サーバーのホスト名と一致します。

手順

  1. /etc/my.cnf.d/mariadb-server-tls.cnf ファイルを作成します。

    1. 以下の内容を追加して、秘密鍵、サーバー、および 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

    2. 証明書失効リスト (CRL) がある場合は、MariaDB サーバーがそれを使用するように設定します。 

      ssl_crl = /etc/pki/tls/certs/example.crl.pem

    3. 必要に応じて、MariaDB 10.5.2 以降を実行する場合は、暗号化せずに接続を拒否できます。この機能を有効にするには、以下を追加します。 

      require_secure_transport = on

    4. 必要に応じて、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 をサポートします。

  2. mariadb サービスを再起動します。 

    # systemctl restart mariadb.service

検証

トラブルシューティングを簡素化するには、ローカルクライアントが TLS 暗号化を使用するように設定する前に、MariaDB サーバーで以下の手順を実行します。

  1. MariaDB で TLS 暗号化が有効になっていることを確認します。 

    # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'have_ssl';"
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| have_ssl      | YES             |
+---------------+-----------------+

    have_ssl 変数が yes に設定されている場合、TLS 暗号化が有効になります。

  2. MariaDB サービスが特定の TLS バージョンのみをサポートするように設定している場合は、tls_version 変数を表示します。 

    # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'tls_version';"
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tls_version   | TLSv1.2,TLSv1.3 |
+---------------+-----------------+
7.2.4.3. 特定のユーザーアカウントに TLS で暗号化された接続を要求する
リンクのコピー

機密データの転送を保護するために、特定の MariaDB ユーザーアカウントに対して TLS 暗号化接続を必須とするように設定できます。

すべての接続にセキュアなトランスポートが必要なサーバーで設定できない場合は (require_secure_transport = on)、TLS 暗号化を必要とするように個別のユーザーアカウントを設定します。

前提条件

  • MariaDB サーバーの TLS サポートが有効になっている。
  • セキュアなトランスポートを必要とするように設定するユーザーが存在する。
  • クライアントは、サーバーの証明書を発行した CA 証明書を信頼している。

手順

  1. 管理ユーザーとして MariaDB サーバーに接続します。 

    # mysql -u root -p -h server.example.com

    管理ユーザーがリモートでサーバーにアクセスする権限を持たない場合は、MariaDB サーバーでコマンドを実行し、localhost に接続します。

  2. REQUIRE SSL 句を使用して、ユーザーが TLS 暗号化接続を使用して接続する必要があるよう強制します。 

    MariaDB [(none)]> ALTER USER 'example'@'%' REQUIRE SSL;

検証

  1. TLS 暗号化を使用して、example ユーザーとしてサーバーに接続します。 

    # mysql -u example -p -h server.example.com --ssl
...
MariaDB [(none)]>

    エラーが表示されず、インタラクティブな MariaDB コンソールにアクセスできる場合は、TLS との接続は成功します。

  2. 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)。

7.2.5. デフォルトで TLS 暗号化を使用するように MariaDB クライアントを設定する
リンクのコピー

RHEL では、MariaDB クライアントが TLS 暗号化を使用するようにグローバルに設定でき、サーバー証明書の Common Name(CN) がユーザーが接続するホスト名と一致することを検証できます。これにより、man-in-the-middle 攻撃 (中間者攻撃) を防ぎます。

前提条件

  • MariaDB サーバーの TLS サポートが有効になっている。
  • サーバー証明書を発行した認証局 (CA) が RHEL で信頼されていない場合は、CA 証明書がクライアントにコピーされています。

手順

  1. RHEL が、サーバー証明書を発行した CA を信頼しない場合は、以下を行います。

    1. CA 証明書を /etc/pki/ca-trust/source/anchors/ ディレクトリーにコピーします。 

      # cp <path>/ca.crt.pem /etc/pki/ca-trust/source/anchors/

    2. すべてのユーザーが CA 証明書ファイルを読み取りできるようにするパーミッションを設定します。 

      # chmod 644 /etc/pki/ca-trust/source/anchors/ca.crt.pem

    3. CA 信頼データベースを再構築します。 

      # update-ca-trust

  2. 以下の内容で /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

7.2.6. 論理ダンプを使用した MariaDB データのバックアップと復元
リンクのコピー

MariaDB データの論理バックアップは、データの復元に必要な SQL ステートメントで構成されます。物理バックアップに対する論理バックアップの利点は、異なるハードウェア構成や MariaDB バージョンでもデータを復元できることです。

7.2.6.1. mysqldump を使用した論理バックアップの実行
リンクのコピー

mysqldump ユーティリティーを使用すると、データベースサーバーが稼働中でも MySQL および MariaDB データベースをバックアップし、エクスポートしたデータを SQL ファイルに保存できます。データが失われた場合に回復できるように、バックアップをセキュアな場所に保存してください。

注記

MariaDB 10.5 以降では、mysqldump は mariadb-dump ユーティリティーへのシンボリックリンクになっています。

mysqldump でよく見られるシナリオは以下のとおりです。

  • 単一のデータベースのバックアップ
  • 複数のデータベースのバックアップ
  • すべてのデータベースのバックアップ

mysqldump ユーティリティーは、出力を単一のファイルに保存します。複数のデータベースをバックアップする際に、データベースごとに 1 つのファイルが必要な場合は、各データベースを個別にバックアップしてください。

注記

mysqldump ユーティリティーはデータベースのみをバックアップできます。これには、mysql データベースに格納されているサーバー設定も含まれます。ただし、このユーティリティーは /etc/my.cnf などの設定ファイルはバックアップしません。

前提条件

  • mariadb または mysqld サービスが稼働しています。
  • root アカウントなど、データベースをバックアップする権限を持つ認証情報を持っている。

手順

  • 一貫性のある包括的なデータベースの論理バックアップを作成する。 

    # mysqldump -u <username> -p --routines --events --triggers --single-transaction --result-file=backup.sql --databases <database_1> <database_2>

    各項目の説明:

    -u <username>
    ユーティリティーがデータベースサーバーに接続するために使用するユーザー名を設定します。
    -p
    パスワードの入力を求めます。
    --routines
    バックアップにストアドプロシージャーと関数を含めます。
    --events
    スケジュールされたイベントをバックアップに含めます。
    --triggers
    バックアップにトリガーを含めます。
    --single-transaction

    InnoDB などのトランザクションストレージエンジンを使用するデータベースに対して、整合性の取れたスナップショットの作成を開始します。単一のトランザクションを使用すると、すべての読み取り操作が、ダンプ開始時点のデータベースの状態を反映したものになります。

    MyISAM などの非トランザクションストレージエンジンをまだ使用している場合は、整合性のあるバックアップを確保するために、--single-transaction ではなく --lock-tables オプションを使用してください。

    --result-file=<output_file>
    mysqldump が 出力を保存するファイルを指定します。
    --databases <list_of_databases>

    バックアップするデータベースを定義します。または、すべてのデータベースを一度にバックアップするには、--all-databases オプションを使用します。

    重要

    データベースのバックアップには、そのデータベースのデータのみが含まれます。ユーザーアカウントやその他のサーバー設定は含まれません。サーバーは、この重要なセキュリティー情報とシステム情報を、別の MySQL システムデータベースに保存します。したがって、これらの設定を保持する必要がある場合は、mysql もバックアップする必要があります。

検証

  • サンドボックス環境でバックアップを復元し、データが正しいことを確認します。

  • データベースをリモート MySQL サーバーにロードするには、以下を実行します。 

    # mysql --host=remote_host < backup-file.sql

  • 1 つのデータベースからテーブルのサブセットをダンプするには、mysqldump コマンドの末尾に、選択したテーブルのリストを追加します。 

    # mysqldump [options] db_name [tbl_name ...] > backup-file.sql

  • 1 つのデータベースからダンプされたリテラルなテーブルのサブセットをロードするには、次のコマンドを実行します。 

    # mysql db_name < backup-file.sql
    注記

    この時点で、db_name データベースが存在している必要があります。

  • mysqldump が サポートするオプションのリストを表示するには、以下を実行してください。 

    $ mysqldump --help
7.2.6.2. SQL 形式のダンプから MariaDB のデータを復元する
リンクのコピー

1 つまたは複数のデータベースを SQL ファイルにバックアップした場合は、このファイルを使用してデータベース構造とそのデータを再作成できます。

前提条件

  • mariadb サービスが実行中である。
  • root アカウントなど、データを復元する権限を持つ認証情報を持っている。

手順

  1. 復元するデータベースがすでに存在し、SQL ファイルに DROP TABLE IF EXISTS ステートメントが含まれていない場合は、テーブルまたはデータベース全体を手動で削除する必要があります。

    • テーブルを削除するには、次のように入力します。 

      # mariadb -u root -p -e "DROP TABLE <database>.<table>;"

      SQL ファイルが再作成するすべてのテーブルに対して、このコマンドを繰り返してください。

    • データベースを削除するには、次のように入力します。 

      # mariadb -u root -p -e "DROP DATABASE <database>;"

      SQL ファイルが再作成するデータベースごとに、このコマンドを繰り返してください。

  2. SQL ファイルをインポートします。 

    # mariadb -u root -p < backup.sql"

検証

  • MariaDB データベースに接続してデータを照会します。次に例を示します。 

    # mariadb -u root -p <database> -e "*SELECT * FROM <table>;"

7.2.7. 物理コピーを使用した MariaDB データのバックアップと復元
リンクのコピー

MariaDB データの物理バックアップには、コンテンツを格納しているファイルとディレクトリーが含まれます。通常、この方法はより高速で、サイズが小さくなります。

7.2.7.1. mariabackup を使用した物理的なオンラインバックアップの実行
リンクのコピー

サーバーの実行中に、mariabackup ユーティリティーを使用して InnoDB、Aria、および MyISAM テーブルをバックアップすることにより、MariaDB サーバーの物理的なオンラインバックアップを作成できます。このユーティリティーは、暗号化および圧縮されたデータを含む MariaDB サーバーの完全バックアップ機能をサポートします。

前提条件

  • mariadb-backup パッケージがシステムにインストールされている。 

    # yum install mariadb-backup
  • Mariabackup には、バックアップを実行するユーザーの認証情報を指定する必要があります。認証情報はコマンドラインまたは設定ファイルで指定できます。
  • Mariabackup のユーザーは、RELOAD、LOCK TABLES、および REPLICATION CLIENT の権限が必要です。

手順

  • コマンドラインで認証情報を提供する間にバックアップを作成するには、以下を実行します。 

    $ mariabackup --backup --target-dir <backup_directory> --user <backup_user> --password <backup_passwd>

    target-dir オプションは、バックアップファイルを格納するディレクトリーを定義します。完全バックアップを実行する場合は、ターゲットディレクトリーが空であるか、存在しない必要があります。

    ユーザー オプションおよび パスワード オプションにより、ユーザー名とパスワードを設定できます。

  • 設定ファイルに認証情報を設定してバックアップを作成するには、次のコマンドを実行します。

    1. /etc/my.cnf.d/ ディレクトリーに設定ファイルを作成します (例: /etc/my.cnf.d/mariabackup.cnf)。

    2. 以下の行を新規ファイルの [xtrabackup] セクションまたは [mysqld] セクションに追加します。 

      [xtrabackup]
user=myuser
password=mypassword

    3. バックアップを実行します。 

      $ mariabackup --backup --target-dir <backup_directory>
7.2.7.2. mariabackup を使用したデータの復元
リンクのコピー

mariabackup ユーティリティーによって作成された MariaDB バックアップがある場合は、同じユーティリティーを使用してデータを復元できます。

前提条件

  • mariadb サービスが停止しています。
  • データディレクトリーが空です。
  • mariabackup のユーザーには、RELOAD、LOCK TABLES、および REPLICATION CLIENT 特権が必要です。

手順

  1. データを復元するには、次のいずれかのオプションを使用します。

    • /var/mariadb/backup/ ディレクトリー内のバックアップからデータを復元し、元のバックアップファイルを保持するには、次のように入力します。 

      $ mariabackup --copy-back --target-dir=/var/mariadb/backup/

    • /var/mariadb/backup/ ディレクトリー内のバックアップからデータを復元し、元のバックアップファイルを削除するには、次のように入力します。 

      $ mariabackup --move-back --target-dir=/var/mariadb/backup/

  2. ファイルの権限を修正します。たとえば、ファイルの所有権を mysql ユーザーおよびグループに再帰的に変更するには、次のコマンドを実行します。 

    # chown -R mysql:mysql /var/lib/mysql/

    データベースを復元する際、mariabackup は、バックアップのファイルおよびディレクトリー特権を保持します。ただし、mariabackup は、ユーザーおよびグループがデータベースを復元する際にファイルをディスクに書き込みます。したがって、バックアップを復元した後、MariaDB サーバーのユーザーとグループに合わせてデータディレクトリーの所有者を調整する必要があります。

  3. mariadb サービスを起動します。 

    # systemctl start mariadb.service
7.2.7.3. MariaDB サーバーでのファイルシステムバックアップの実行
リンクのコピー

ファイルシステムレベルのバックアップは、MariaDB インスタンス全体をバックアップする高速な方法です。この方法では、データの整合性を保つために mariadb サービスをシャットダウンする必要があります。

重要

ファイルシステムレベルのバックアップは、アーキテクチャーと MariaDB バージョンに固有のものです。この方法でバックアップしたデータを、異なるアーキテクチャーまたは MariaDB バージョンで復元することはできません。

手順

  1. mariadb サービスを停止します。 

    # systemctl stop mariadb.service

  2. バックアップディレクトリーを作成します。次に例を示します。 

    # mkdir -p /root/mariadb-backup/{data,config}/

  3. データディレクトリーをバックアップします。 

    # cp -rp /var/lib/mysql/ /root/mariadb-backup/data/

  4. 設定ファイルをバックアップします。 

    # cp -rp /etc/my.cnf /etc/my.cnf.d/ /root/mariadb-backup/config/

  5. mariadb サービスを起動します。 

    # systemctl start mariadb.service
7.2.7.4. MariaDB サーバーでのファイルシステムバックアップの復元
リンクのコピー

MariaDB インスタンスが破損した場合は、以前にデータディレクトリーと設定ファイルを含むファイルシステムバックアップを実行済みであれば、このバックアップからインスタンスを復元できます。

前提条件

手順

  1. mariadb サービスを停止します。 

    # systemctl stop mariadb.service

  2. 現在の /var/lib/mysql/ ディレクトリーを削除します。 

    # rm -rf /var/lib/mysql/

  3. バックアップからデータディレクトリーを復元します。 

    # cp -rp /root/mariadb-backup/data/mysql/ /var/lib/

  4. /var/lib/mysql/ ディレクトリーの所有権を正しく設定します。 

    # chown -R mysql:mysql /var/lib/mysql/

  5. /var/lib/mysql/ ディレクトリーの SELinux コンテキストを復元します。 

    # restorecon -Rv /var/lib/mysql/

  6. 現在の設定ファイルを削除します。 

    # rm -rf /etc/my.cnf /etc/my.cnf.d/

  7. バックアップから設定ファイルを復元します。 

    # cp -rp /root/mariadb-backup/config/my.cnf /root/mariadb-backup/config/my.cnf.d/ /etc/

  8. 設定ファイルの所有権を正しく設定します。 

    # chown -R root:root /etc/my.cnf /etc/my.cnf.d/

  9. 設定ファイルの SELinux コンテキストを復元します。 

    # restorecon -Rv /etc/my.cnf /etc/my.cnf.d/

  10. mariadb サービスを起動します。 

    # systemctl start mariadb.service

検証

  • MariaDB データベースに接続してデータを照会します。次に例を示します。 

    # mariadb -u root -p <database> -e "*SELECT * FROM <table>;"

7.2.8. Galera で MariaDB を複製する
リンクのコピー

Galera ソリューションを使用して MariaDB データベースをレプリケートすることで、高可用性とデータの整合性を実現する同期型のマルチソースクラスターを作成できます。

警告

レプリケーション自体は、バックアップソリューションとしては十分ではありません。レプリケーションは、ハードウェア障害からソースサーバーを保護しますが、データ損失に対する保護は保証していません。

7.2.8.1. MariaDB Galera Cluster の概要
リンクのコピー

MariaDB Galera Cluster は、すべてのノードへの書き込みを可能にして、クラスター全体のデータの整合性を確保する同期型のマルチソースレプリケーションを提供します。

Galera レプリケーションと MariaDB データベースとの間のインターフェイスは、書き込みセットレプリケーション API (wsrep API) で定義されます。

MariaDB Galera Cluster の主な機能は以下のとおりです。

  • 同期のレプリケーション
  • アクティブ/アクティブのマルチソーストポロジー
  • クラスターノードへの読み取りおよび書き込み
  • 自動メンバーシップ制御、失敗したノードのクラスターからの削除
  • 自動ノードの参加
  • 行レベルの並列レプリケーション
  • ダイレクトクライアント接続: ユーザーはクラスターノードにログインし、レプリケーションの実行中にノードを直接操作できます。

同期レプリケーションとは、サーバーがトランザクションに関連付けられた書き込みセットをクラスター内のすべてのノードにブロードキャストすることで、コミット時にトランザクションをレプリケートすることを意味します。クライアント (ユーザーアプリケーション) は、データベース管理システム (DBMS) に直接接続し、ネイティブの MariaDB と同様の動作が発生します。

同期レプリケーションは、クラスター内の 1 つのノードで発生した変更が、クラスター内の他のノードで同時に発生することを保証します。

そのため、同期レプリケーションには、非同期のレプリケーションと比べて次のような利点があります。

  • 特定のクラスターノード間の変更の伝播に遅延がない
  • すべてのクラスターノードには常に一貫性がある
  • いずれかのクラスターノードがクラッシュしても、最新の変更は失われない
  • すべてのクラスターノードのトランザクションが並列に実行する
  • クラスター全体にわたる因果関係
7.2.8.2. MariaDB Galera Cluster を構築するためのコンポーネント
リンクのコピー

正常に動作し、同期レプリケーションを行う MariaDB Galera Cluster をデプロイする前に、中核となるソフトウェアコンポーネントをインストールし、その機能を理解する必要があります。そのコンポーネントとは、具体的には MariaDB サーバー、Galera Replication ライブラリー、および補助的な Galera パッケージです。

MariaDB Galera Cluster を構築するには、システムに以下のパッケージをインストールする必要があります。

  • mariadb-server-galera - MariaDB Galera Cluster のサポートファイルとスクリプトが含まれています。
  • mariadb-server - MariaDB アップストリームによって書き込みセットレプリケーション API (wsrep API) が含まれるようにパッチが適用されています。この API は、Galera レプリケーションと MariaDB 間のインターフェイスを提供します。

  • galera - MariaDB アップストリームによってパッチが適用され、[application]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、および MariaDB 10.11 には、それぞれ /usr/lib/systemd/system/garbd.service および /usr/sbin/garbd-wrapper ファイルに、Red Hat 版の garbd systemd サービスと galera パッケージのラッパースクリプトが含まれています。RHEL 8.6 以降、RHEL に同梱されている MariaDB は、/usr/share/doc/galera/garb-systemd および /usr/share/doc/galera/garbd.service にあるこれらのファイルのアップストリームバージョンも提供しています。
7.2.8.3. MariaDB Galera クラスターのデプロイメント
リンクのコピー

必要なパッケージをインストールし、クラスターの設定を行い、最初のノードをブートストラップして新しいクラスターを作成することにより、MariaDB Galera Cluster をデプロイできます。

前提条件

  • クラスター内のすべてのノードに TLS が設定 されている。

  • すべてのノード上のすべての証明書の Extended Key Usage フィールドが次のように設定されている。 

    TLS Web Server Authentication, TLS Web Client Authentication

手順

  1. MariaDB Galera Cluster パッケージをインストールするには、mariadb モジュールからストリーム (バージョン) を選択し、galera プロファイルを指定します。以下に例を示します。 

    # yum module install mariadb:10.3/galera

    その結果、次のパッケージが依存関係とともにインストールされます。

  2. システムを初めてクラスターに追加する前に、MariaDB サーバーのレプリケーション設定を更新します。デフォルト設定は、/etc/my.cnf.d/galera.cnf ファイルで配布されます。MariaDB Galera Cluster をデプロイする前に、すべてのノードの /etc/my.cnf.d/galera.cnf ファイルで wsrep_cluster_address オプションを次の文字列で始まるように設定してください。 

    gcomm://

    • 初期ノードでは、wsrep_cluster_address を空のリストとして設定できます。 

      wsrep_cluster_address="gcomm://"

    • その他のすべてのノードに wsrep_cluster_address を設定して、実行中のクラスターに属するノードへのアドレスを追加します。以下に例を示します。 

      wsrep_cluster_address="gcomm://10.0.0.10"

      Galera Cluster アドレスの設定方法は、Galera Cluster Address を参照してください。

  3. /etc/my.cnf.d/galera.cnf 設定ファイルで wsrep_on=1 オプションを設定して、すべてのノードで wsrep API を有効にします。

  4. TLS 鍵と証明書を含む Galera 設定ファイルに wsrep_provider_options 変数を追加します。以下に例を示します。 

    wsrep_provider_options="socket.ssl_cert=/etc/pki/tls/certs/source.crt;socket.ssl_key=/etc/pki/tls/private/source.key;socket.ssl_ca=/etc/pki/tls/certs/ca.crt"

  5. ノードで以下のラッパーを実行して、新規クラスターの最初のノードをブートストラップします。 

    # galera_new_cluster

    このラッパーにより、MariaDB サーバーデーモン (mysqld) に --wsrep-new-cluster オプションが指定されて実行されるようになります。このオプションは、接続する既存クラスターがないという情報を提供します。したがって、ノードは新規 UUID を作成し、新しいクラスターを特定します。

    注記

    mariadb サービスは、複数の MariaDB サーバープロセスと対話する systemd メソッドをサポートします。したがって、複数の MariaDB サーバーが実行中の場合は、インスタンス名を接尾辞として指定することで、特定のインスタンスをブートストラップできます。 

    # galera_new_cluster mariadb@node1

  6. 各ノードで次のコマンドを実行して、その他のノードをクラスターに接続します。 

    # systemctl start mariadb.service

    その結果、ノードはクラスターに接続し、それ自体をクラスターの状態と同期します。

検証

7.2.8.4. MariaDB Galera クラスターのステータスを確認する
リンクのコピー

MariaDB Galera クラスターの健全性、パフォーマンス、同期を監視し、確保することが重要です。そのためには、各ノードのステータス変数をクエリーして、ノードとクラスターを監視できます。

MariaDB Galera クラスターのステータスを確認するには、次のクエリーを使用します。

  • クラスター内のノードの数を表示します。 

    # mysql -u root -p -e 'show status like "wsrep_cluster_size";'
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 4     |
+--------------------+-------+

  • ノードのクラスターコンポーネントのステータスを表示します。 

    # mysql -u root -p -e 'show status like "wsrep_cluster_status";'
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| wsrep_cluster_status | Primary |
+----------------------+---------+

    wsrep_cluster_status 変数の値は、現在のノードが属するクラスターコンポーネントのステータスを示します。以下の値が使用できます。

    • Primary: クラスターは正常に機能しています。定足数が満たされています。正常なクラスターでは、すべてのノードが Primary を報告します。
    • Non-primary: ノードはクラスターのプライマリーコンポーネントへの接続を失い、アクティブクラスターの一部ではなくなりました。ただし、ノードは引き続き読み取りクエリーを処理できますが、書き込み操作を処理することはできません。
    • Disconnected: ノードはどのクラスターコンポーネントにも接続されていません。その結果、クエリーを受け入れることができず、データはレプリケートされません。

  • ノードのステータスを表示します。 

    # mysql -u root -p -e 'show status like "wsrep_local_state_comment";'
+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+

    wsrep_local_state_comment 変数の頻繁に使用される値は次のとおりです。

    • Synced: ノードはクラスター内で完全に同期されており、レプリケーションにアクティブに参加しています。
    • Desynced: ノードは引き続きクラスターの一部ですが、状態の遷移で主にビジー状態です。
    • Joining: ノードはクラスターへの参加処理中です。
    • Joined: ノードはクラスターに正常に参加しました。クラスターから書き込みセットを受信して適用できます。
    • Donor: ノードは現在、State Snapshot Transfer (SST) を提供しています。新しいノードが参加して完全な状態の遷移が必要な場合、クラスターは既存のノードを選択して必要なデータを送信します。

  • ノードがクラスターからの書き込みセットを受け入れるかどうかを確認します。 

    # mysql -u root -p -e 'show status like "wsrep_ready";'
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wsrep_ready   | ON    |
+---------------+-------+

    wsrep_ready 変数が ON の場合、ノードはコンポーネントを正常に初期化し、クラスターに接続されています。さらに、ノードは同期されているか、クエリーを処理できる状態に達しています。

  • ノードが他のホストとネットワーク接続されているか確認します。 

    # mysql -u root -p -e 'show status like "wsrep_connected";'
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| wsrep_connected | ON    |
+-----------------+-------+

    ON 値は、ノードがクラスター内の少なくとも 1 つのメンバーに接続されていることを意味します。

  • 最後の FLUSH STATUS コマンド以降、またはサーバーの起動以降の書き込みセットのローカル受信キューの平均サイズを表示します。 

    # mysql -u root -p -e 'show status like "wsrep_local_recv_queue_avg";'
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| wsrep_local_recv_queue_avg | 0.012 |
+----------------------------+-------+

    0 に近い値は理想的な状態であり、ノードが書き込みセットを受信するとそれを適用し続けることを示します。値が継続的に高い、または増加している場合は、ディスク I/O が遅いなどのパフォーマンスのボトルネックが発生している可能性があります。

  • フロー制御ステータスを表示します。 

    # mysql -u root -p -e 'show status like "wsrep_flow_control_paused";'
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| wsrep_flow_control_paused | 0     |
+---------------------------+-------+

    この変数は、ローカル受信キューがいっぱいでフロー制御がトリガーされたために、ノードが一時停止され、新しい着信トランザクションを処理できない時間の割合を表します。値が 0 に近い場合、ノードはレプリケーションワークロードを効率的に継続していることを示します。値が 1.0 に近づくと、ノードが書き込みセットの適用で頻繁または継続的に問題に遭遇し、クラスターのボトルネックになる可能性があることを意味します。

    ノードが頻繁に一時停止する場合は、/etc/my.cnf.d/galera.cnf ファイルの wsrep_slave_threads パラメーターを調整できます。

  • ノードが並列に適用できる最小シーケンス番号と最大シーケンス番号間の平均距離を表示します。 

    # mysql -u root -p -e 'show status like "wsrep_cert_deps_distance";'
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| wsrep_cert_deps_distance | 1     |
+--------------------------+-------+

    値が大きいほど、並列度が高くなります。これは、/etc/my.cnf.d/galera.cnf ファイルの wsrep_slave_threads パラメーターで使用できる最適な値です。

7.2.8.5. 新規ノードの MariaDB Galera Cluster への追加
リンクのコピー

ノードの設定ファイルでクラスターアドレスを設定することにより、MariaDB Galera Cluster に新しいノードを追加したり、既存のノードに再接続したりできます。

手順

  • 特定のノードで、/etc/my.cnf.d/galera.cnf 設定ファイルの [mariadb] セクション内にある wsrep_cluster_address オプションで、1 つ以上の既存クラスターメンバーにアドレスを指定します。 

    [mariadb]
wsrep_cluster_address="gcomm://192.168.0.1"

    新規ノードを既存クラスターノードのいずれかに接続すると、クラスター内のすべてのノードを表示できるようになります。

    ただし、wsrep_cluster_address のクラスターの全ノードを表示することが推奨されます。

    したがって、1 つ以上のクラスターノードがダウンしても、その他のクラスターノードに接続することでノードがクラスターに参加できます。すべてのメンバーがメンバーシップに同意すると、クラスターの状態が変更します。新規ノードの状態がクラスターの状態と異なる場合、新しいノードは Incremental State Transfer (IST) または State Snapshot Transfer (SST) のいずれかを要求し、他のノードとの一貫性を確保します。

7.2.8.6. MariaDB Galera Cluster の再起動
リンクのコピー

すべてのノードを同時にシャットダウンすると、クラスターが終了し、実行中のクラスターは存在しなくなります。ただし、クラスターのデータは引き続き存在します。クラスターを再起動するには、まず最初のノードをブートストラップします。

警告

クラスターがブートストラップされておらず、最初のノードの mariadb が systemctl start mariadb.service コマンドのみで起動された場合、ノードは /etc/my.cnf.d/galera.cnf ファイルの wsrep_cluster_address オプションにリストされているノードの少なくとも 1 つに接続しようとします。現在実行中のノードがない場合、再起動は失敗します。

7.2.9. MariaDB 10.3 への移行
リンクのコピー

mysql_upgrade ユーティリティーを使用してデータベースサーバーのインプレースアップグレードを実行することで、MariaDB データベースを RHEL 8 バージョンの MariaDB 10.3 に移行できます。

RHEL 7 には、MySQL データベースファミリーのサーバーとして、デフォルトの実装として MariaDB 5.5 が含まれています。MariaDB データベースサーバーの最新バージョンは、RHEL 7 用の Software Collections として提供されています。RHEL 8 は、MariaDB 10.3、MariaDB 10.5、MariaDB 10.11、および MySQL 8.0 を提供します。

このセクションでは、RHEL 7 または Red Hat Software Collections 版の MariaDB から MariaDB 10.3 への移行について説明します。

7.2.9.1. RHEL 7 と RHEL 8 のバージョンにおける MariaDB の主な相違点
リンクのコピー

RHEL 8 上の MariaDB 10.3 では、Galera Cluster の統合、新しいストレージエンジン、InnoDB のデフォルト設定、MySQL と MariaDB の互換性を確保するための統一クライアントライブラリーなど、重要な変更が導入されています。

MariaDB 5.5 と MariaDB 10.3 の最も重要な変更点は以下のとおりです。

  • MariaDB Galera Cluster は、同期型マルチソースクラスターであり、MariaDB 10.1 以降、標準機能として搭載されています。
  • ARCHIVE ストレージエンジンはデフォルトでは有効になっていないため、プラグインを明示的に有効にする必要があります。
  • BLACKHOLE ストレージエンジンはデフォルトでは有効になっていないため、プラグインを明示的に有効にする必要があります。

  • MariaDB 10.1 以前のバージョンで使用されていた XtraDB に代わり、InnoDB がデフォルトのストレージエンジンとして使用されます。

    詳細は、XtraDB ではなく InnoDB を 参照してください。

  • 新しい mariadb-connector-c パッケージは、MySQL と MariaDB に共通のクライアントライブラリーを提供します。このライブラリーは、MySQL および MariaDB データベースサーバーのどのバージョンでも使用できます。その結果、ユーザーはアプリケーションのビルドを、Red Hat Enterprise Linux 8 に同梱されている MySQL および MariaDB サーバーのいずれかに接続できるようになります。

MariaDB 5.5 から MariaDB 10.3 に移行するには、複数の 設定変更を 行う必要があります。

7.2.9.2. 設定変更
リンクのコピー

MariaDB を 5.5 から 10.3 にアップグレードする場合は、一度に 1 つのマイナーバージョンずつアップグレードしてください。まず MariaDB 10.0 へのアップグレードから始め、その後、一つずつバージョンアップしていってください。

MariaDB 5.5 から MariaDB 10.0 への移行時の設定変更に関する詳細は、Red Hat Software Collections ドキュメントの MariaDB 10.0 への移行を 参照してください。

MariaDB の次々のバージョンへの移行と、それに必要な設定変更については、以下のドキュメントに記載されています。

注記

MariaDB 5.5 から MariaDB 10.3 への直接移行も可能ですが、上記の移行ドキュメントに記載されている相違点によって必要となるすべての設定変更を行う必要があります。

7.2.9.3. mysql_upgrade ユーティリティーを使用したインプレースアップグレード
リンクのコピー

データファイルをコピーし、mysql_upgrade ユーティリティーを使用してインプレースアップグレードを実行することで、MariaDB データベースを RHEL 7 から RHEL 8 に移行できます。

この方法を使用すると、以下からデータを移行できます。

  • 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 へのアップグレードは、1 バージョンずつ順番に行うことを推奨します。Red Hat Software Collections のリリースノート にある、それぞれの移行に関する章を参照してください。

MariaDB の RHEL 7 バージョンからアップグレードする場合、ソースデータは /var/lib/mysql/ ディレクトリーに保存されます。Red Hat Software Collections バージョンの MariaDB の場合、ソースデータディレクトリーは /var/opt/rh/<collection_name>/lib/mysql/ です (ただし、mariadb55 は /opt/rh/mariadb55/root/var/lib/mysql/ データディレクトリーを使用します)。

重要

インプレースアップグレードには、特定のリスクと既知の問題があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題の詳細、およびインプレースアップグレードに関する一般的な情報については、MariaDB 10.3 リリースノートを 参照してください。

前提条件

  • MariaDB データベースと設定ファイルのバックアップを作成しました。

手順

  1. RHEL 8 システムに mariadb-server パッケージがインストールされていることを確認します。 

    # yum install mariadb-server

  2. データのコピー時に、mariadb サービスがソースおよびターゲットのシステムで稼働していないことを確認します。 

    # systemctl stop mariadb.service
  3. ソースの場所から RHEL 8 ターゲットシステムの /var/lib/mysql/ ディレクトリーにデータをコピーします。

  4. ターゲットシステムでコピーされたファイルに適切なパーミッションと SELinux コンテキストを設定します。 

    # restorecon -vr /var/lib/mysql

  5. 対象システム上で MariaDB サーバーを起動します。 

    # systemctl start mariadb.service

  6. mysql_upgrade コマンドを実行して、内部テーブルをチェックし、修復します。 

    $ mysql_upgrade
  7. アップグレードが完了したら、/etc/my.cnf.d/ ディレクトリー内のすべての設定ファイルに MariaDB 10.3 に有効なオプションのみが含まれていることを確認してください。

7.2.10. RHEL 8 バージョンの MariaDB 10.3 から MariaDB 10.5 へのアップグレード
リンクのコピー

RHEL 8 上で MariaDB データベースをバージョン 10.3 から 10.5 にアップグレードすることで、新しいバージョンの新機能や改善点を活用できます。

主な機能強化や変更点については、RHEL 8.4 リリースノートの リリースノートを 参照してください。

mariadb-upgrade ユーティリティーは、mariadb-server-utils サブパッケージにより提供され、mariadb-server パッケージの依存関係としてインストールされます。

重要

既存設備のアップグレードには、特定の危険や既知の問題が伴います。たとえば、一部のクエリーが機能しなくなったり、アップグレード前とは異なる順序で実行されたりする可能性があります。たとえば、一部のクエリーが動作しなかったり、アップグレード前とは異なる順序で実行される場合があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、MariaDB 10.5 Release Notes を参照してください。

前提条件

  • MariaDB データベースと設定ファイルのバックアップを作成しました。

手順

  1. MariaDB サーバーを停止します。 

    # systemctl stop mariadb.service

  2. 以下のコマンドを実行して、後続のストリームに切り替えるためのシステムの準備が整っているかどうかを判断します。 

    # yum distro-sync

    このコマンドは、Nothing to do.Complete! のメッセージで終了する必要があります。詳細は、後のストリームへの切り替えを 参照してください。

  3. システムで mariadb モジュールをリセットします。 

    # yum module reset mariadb

  4. 新しい mariadb:10.5 モジュールストリームを有効にします。 

    # yum module enable mariadb:10.5

  5. インストール済みパッケージを同期し、ストリーム間の変更を実行します。 

    # yum distro-sync

    これにより、インストールされているすべての MariaDB パッケージが更新されます。

  6. /etc/my.cnf.d/ ディレクトリーにあるオプションファイルに、MariaDB 10.5 で有効なオプションのみが含まれるように設定を調整してください。詳細は、MariaDB 10.4 および MariaDB 10.5 のアップストリームのドキュメントを参照してください。

  7. MariaDB サーバーを起動します。

    • Galera クラスターのプライマリーノードをアップグレードする場合は、以下を入力してください。 

      # galera_new_cluster

      mariadb サービスが自動的に起動します。

    • Galera クラスターでスタンドアロンまたはレプリカとして実行されているデータベースをアップグレードする場合は、以下を入力してください。 

      # systemctl start mariadb.service

  8. mariadb-upgrade ユーティリティーを実行して、内部テーブルをチェックおよび修復してください。

    • Galera クラスターノードをアップグレードする場合は、以下を入力してください。 

      # mariadb-upgrade --skip-write-binlog

    • スタンドアロンで実行されているデータベースをアップグレードする場合: 

      # mariadb-upgrade

7.2.11. RHEL 8 バージョンの MariaDB 10.5 から MariaDB 10.11 へのアップグレード
リンクのコピー

yum および mariadb-upgrade ユーティリティーを使用して、mariadb:10.5 モジュールストリームから mariadb:10.11 モジュールストリームにアップグレードします。

主な機能強化や変更点については、RHEL 8.10 リリースノートの リリースノートを 参照してください。

mariadb-upgrade ユーティリティーは、mariadb-server-utils サブパッケージにより提供され、mariadb-server パッケージの依存関係としてインストールされます。

重要

既存設備のアップグレードには、特定の危険や既知の問題が伴います。たとえば、一部のクエリーが機能しなくなったり、アップグレード前とは異なる順序で実行されたりする可能性があります。これらのリスクと問題、およびインプレースアップグレードに関する全般的な情報は、MariaDB 10.11 Release Notes を参照してください。

前提条件

  • MariaDB データベースと設定ファイルのバックアップを作成しました。

手順

  1. MariaDB サーバーを停止します。 

    # systemctl stop mariadb.service

  2. 以下のコマンドを実行して、後続のストリームに切り替えるためにシステムの準備が整っているかどうかを判断します。 

    # yum distro-sync

    このコマンドは、Nothing to do.Complete! のメッセージで終了する必要があります。詳細は、後のストリームへの切り替えを 参照してください。

  3. システムで mariadb モジュールをリセットします。 

    # yum module reset mariadb

  4. 新しい mariadb:10.11 モジュールストリームを有効にします。 

    # yum module enable mariadb:10.11

  5. インストール済みパッケージを同期し、ストリーム間の変更を実行します。 

    # yum distro-sync

    これにより、インストール済みのすべての MariaDB パッケージが更新されます。

  6. /etc/my.cnf.d/ ディレクトリーにあるオプションファイルに MariaDB 10.11 で有効なオプションのみが含まれるように設定を調整してください。詳細は、MariaDB 10.6 および MariaDB 10.11 のアップストリームドキュメントを参照してください。

  7. MariaDB サーバーを起動します。

    • Galera クラスターのプライマリーノードをアップグレードする場合は、以下を入力してください。 

      # galera_new_cluster

      mariadb サービスは自動的に起動します。

    • Galera クラスターでスタンドアロンまたはレプリカとして実行されているデータベースをアップグレードする場合は、以下を入力してください。 

      # systemctl start mariadb.service

  8. mariadb-upgrade ユーティリティーを実行して、内部テーブルをチェックおよび修復してください。

    • Galera クラスターノードをアップグレードする場合は、以下を入力してください。 

      # mariadb-upgrade --skip-write-binlog

    • スタンドアロンで実行されているデータベースをアップグレードする場合は、以下を入力してください。 

      # mariadb-upgrade

7.2.12. MariaDB クライアントアプリケーションの開発
リンクのコピー

MariaDB クライアントアプリケーションは、MariaDB クライアントライブラリーを使用して開発する必要があります。これらのアプリケーションを構築するために必要な開発ファイルとプログラムは、mariadb-connector-c-devel パッケージによって提供されます。

直接ライブラリー名を使用する代わりに、mariadb-connector-c-devel パッケージで配布されている mariadb_config プログラムを使用します。このプログラムにより、正しいビルドフラグが確実に返されるようになります。

7.3. MySQL の使用
リンクのコピー

MySQL サーバーは、高性能なオープンソースのリレーショナルデータベース管理システム (RDBMS) です。データアクセス用の SQL インターフェイスと、複数のストレージエンジンのサポートなどの高度な機能を備えています。

RHEL システムへの MySQL のインストールと設定方法、MySQL データのバックアップ方法、以前の MySQL バージョンからの移行方法、および MySQL のレプリケーション方法について学びます。

7.3.1. MySQL のインストール
リンクのコピー

RHEL 8 では、アプリケーションストリームの初期バージョンとして MySQL 8.0 が提供されます。RHEL 8 のマイナーリリースでは、ライフサイクルの短いモジュールとして追加の MySQL バージョンが提供されます。

重要

設計上、同じモジュールの 1 つのバージョン (ストリーム) のみをインストールでき、RPM パッケージが競合するため、MariaDB と MySQL を同じホストにインストールすることはできません。代わりに、コンテナー内でデータベースサーバーサービスを実行することもできます。単一ホスト上で複数の MariaDB および MySQL インスタンスを実行するためのコンテナーの使用方法については、 こちらを参照してください。

手順

  1. MySQL サーバーパッケージをインストールします。

    • MySQL 8.0 の場合は、mysql モジュールから 8.0 ストリームを選択し、サーバー プロファイルを指定します。 

      # yum module install mysql:8.0/server

    • MySQL 8.4 の場合は、mysql モジュールから 8.4 ストリームを選択し、サーバー プロファイルを指定します。 

      # yum module install mysql:8.4/server

  2. オプション:MySQL 8.0 をインストールしている場合は、セキュリティーを向上させるために、非推奨の mysql_native_password 認証プラグインの代わりに caching_sha2_password を使用することを検討してください。caching_sha2_password プラグインを有効にするには:

    1. /etc/my.cnf.d/mysql-server.cnf ファイルを編集してください。

    2. [mysqld] セクションに以下の設定を追加してください。 

      authentication_policy=caching_sha2_password

  3. mysqld サービスを有効にして起動します。 

    # systemctl enable --now mysqld.service

  4. セキュリティーを強化する: 

    $ mysql_secure_installation

    このコマンドは、完全にインタラクティブなスクリプトを起動して、プロセスの各ステップのプロンプトを表示します。このスクリプトを使用すると、次の方法でセキュリティーを改善できます。

    • root アカウントのパスワードの設定
    • 匿名ユーザーの削除
    • リモート root ログインの拒否 (ローカルホスト外)

パッケージから MariaDB または MySQL をインストールする場合、同じホスト上でこれらのサービスのうち 1 つのみ、かつその 1 つのバージョンのみを実行できます。代わりに、コンテナー内でサービスを実行することもできます。

次のような環境を構成できます。

  • 同じホスト上で MariaDB または MySQL の複数のインスタンスを実行したい。
  • MariaDB と MySQL の両方を同じホストで実行したい。
注記

データベースサーバーのコンテナー名とホストポートは異なっている必要があります。

前提条件

  • container-tools モジュールがインストールされている。

手順

  1. Red Hat カスタマーポータルアカウントを使用して、registry.redhat.io レジストリーに認証します。 

    # podman login registry.redhat.io

    すでにコンテナーレジストリーにログインしている場合は、このステップをスキップしてください。

  2. コンテナー内で MySQL 8.0 を実行する: 

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mysql_root_password> -p <host_port_1>:3306 rhel8/mysql-80

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  3. MariaDB 10.5 をコンテナー内で実行する: 

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_2>:3306 rhel8/mariadb-105

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  4. MariaDB 10.11 をコンテナー内で実行する: 

    $ podman run -d --name <container_name> -e MYSQL_ROOT_PASSWORD=<mariadb_root_password> -p <host_port_3>:3306 rhel8/mariadb-1011

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  5. クライアントがネットワーク上のデータベースサーバーにアクセスできるように、ファイアウォールでホストポートを開きます。 

    # firewall-cmd --permanent --add-port={<host_port>/tcp,<host_port>/tcp,...}
# firewall-cmd --reload

検証

  1. 実行中のコンテナーに関する情報を表示します。 

    $ podman ps

  2. データベースサーバーに接続し、root としてログインします。 

    # mysql -u root -p -h localhost -P <host_port> --protocol tcp

7.3.3. MySQL の設定
リンクのコピー

MySQL サーバーをネットワーク接続用に設定するには、以下の手順に従ってください。

手順

  1. /etc/my.cnf.d/mysql-server.cnf ファイルの [mysqld] セクションを編集します。以下の設定ディレクティブを設定できます。

    • bind-address: サーバーがリッスンするアドレスです。設定可能なオプションは以下のとおりです。

      • ホスト名
      • IPv4 アドレス
      • IPv6 アドレス

    • skip-networking: サーバーが TCP/IP 接続をリッスンするかどうかを制御します。以下の値が使用できます。

      • 0 - すべてのクライアントをリッスンする
      • 1 - ローカルクライアントのみをリッスンする
    • port: MySQL が TCP/IP 接続をリッスンするポート。

  2. mysqld サービスを再起動します。 

    # systemctl restart mysqld.service

7.3.4. MySQL サーバーでの TLS 暗号化の設定
リンクのコピー

デフォルトでは、MySQL は暗号化されていない接続を使用します。セキュアな接続では、MariaDB サーバーで TLS サポートを有効にし、クライアントが暗号化された接続を確立するように設定します。

7.3.4.1. MySQL サーバーに CA 証明書、サーバー証明書、および秘密鍵を配置する
リンクのコピー

MySQL サーバーで TLS 暗号化を有効にする前に、認証局 (CA) 証明書、サーバー証明書、および秘密鍵を MySQL サーバーに保存します。

前提条件

  • Privacy Enhanced Mail(PEM) 形式の以下のファイルがサーバーにコピーされています。

    • サーバーの秘密鍵: server.example.com.key.pem
    • サーバー証明書: server.example.com.crt.pem
    • 認証局 (CA) 証明書: ca.crt.pem

    秘密鍵および証明書署名要求 (CSR) の作成や、CA からの証明書要求に関する詳細は、CA のドキュメントを参照してください。

手順

  1. 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/

  2. MySQL サーバーがファイルを読み取れるように、CA とサーバー証明書のパーミッションを設定します。 

    # chmod 644 /etc/pki/tls/certs/server.example.com.crt.pem /etc/pki/tls/certs/ca.crt.pem

    証明書は、セキュアな接続が確立される前は通信の一部であるため、任意のクライアントは認証なしで証明書を取得できます。そのため、CA およびサーバーの証明書ファイルに厳密なパーミッションを設定する必要はありません。

  3. サーバーの秘密鍵を /etc/pki/tls/private/ ディレクトリーに保存します。 

    # mv <path>/server.example.com.key.pem /etc/pki/tls/private/

  4. サーバーの秘密鍵にセキュアなパーミッションを設定します。 

    # chmod 640 /etc/pki/tls/private/server.example.com.key.pem
# chgrp mysql /etc/pki/tls/private/server.example.com.key.pem

    承認されていないユーザーが秘密鍵にアクセスできる場合、MySQL サーバーへの接続は安全ではなくなります。

  5. SELinux コンテキストを復元します。 

    # restorecon -Rv /etc/pki/tls/
7.3.4.2. MySQL サーバーでの TLS 暗号化の設定
リンクのコピー

デフォルトでは、MySQL は暗号化されていない接続を使用します。よりセキュアな接続のために、MySQL サーバーで Transport Layer Security (TLS) サポートを有効にし、暗号化された接続を確立するようにクライアントを設定できます。

前提条件

  • MySQL サーバーがインストールされました。
  • mysqld サービスが実行されている。

  • 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) フィールドは、サーバーのホスト名と一致します。

手順

  1. /etc/my.cnf.d/mysql-server-tls.cnf ファイルを作成します。

    1. 以下の内容を追加して、秘密鍵、サーバー、および CA 証明書へのパスを設定します。 

      [mysqld]
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

    2. 証明書失効リスト (CRL) がある場合は、それを使用するように MySQL サーバーを設定します。 

      ssl_crl = /etc/pki/tls/certs/example.crl.pem

    3. オプション: 暗号化なしの接続試行を拒否します。この機能を有効にするには、以下を追加します。 

      require_secure_transport = on

    4. オプション: サーバーがサポートする必要がある TLS バージョンを設定します。たとえば、TLS 1.3 のみをサポートするには、次を追加します。 

      tls_version = TLSv1.3

      デフォルトでは、サーバーは TLS 1.2 と TLS 1.3 をサポートします。

  2. mysqld サービスを再起動します。 

    # systemctl restart mysqld.service

検証

トラブルシューティングを簡素化するには、ローカルクライアントが TLS 暗号化を使用するように設定する前に、MySQL サーバーで以下の手順を実行します。

  1. MySQL で TLS 暗号化が有効になっていることを確認します。 

    # mysql -u root -p -h <MySQL_server_hostname> -e "SHOW session status LIKE 'Ssl_cipher';"
+---------------+------------------------+
| Variable_name | Value                  |
+---------------+------------------------+
| Ssl_cipher    | TLS_AES_256_GCM_SHA384 |
+---------------+------------------------+

  2. MySQL サーバーが特定の TLS バージョンのみをサポートするように設定している場合は、tls_version 変数を表示します。 

    # mysql -u root -p -e "SHOW GLOBAL VARIABLES LIKE 'tls_version';"
+---------------+---------+
| Variable_name | Value   |
+---------------+---------+
| tls_version   | TLSv1.3 |
+---------------+---------+

  3. サーバーが正しい CA 証明書、サーバー証明書、および秘密鍵ファイルを使用していることを確認します。 

    # mysql -u root -e "SHOW GLOBAL VARIABLES WHERE Variable_name REGEXP '^ssl_ca|^ssl_cert|^ssl_key';"
+-----------------+-------------------------------------------------+
| Variable_name   | Value                                           |
+-----------------+-------------------------------------------------+
| ssl_ca          | /etc/pki/tls/certs/ca.crt.pem                   |
| ssl_capath      |                                                 |
| ssl_cert        | /etc/pki/tls/certs/server.example.com.crt.pem   |
| ssl_key         | /etc/pki/tls/private/server.example.com.key.pem |
+-----------------+-------------------------------------------------+
7.3.4.3. 特定のユーザーアカウントに TLS で暗号化された接続を要求する
リンクのコピー

機密データの送信を保護するために、特定の MySQL アカウントに対して TLS 暗号化接続を必須とするように設定できます。

すべての接続にセキュアなトランスポートが必要なサーバーで設定できない場合は (require_secure_transport = on)、TLS 暗号化を必要とするように個別のユーザーアカウントを設定します。

前提条件

  • MySQL サーバーで TLS サポートが有効になっている。
  • セキュアなトランスポートを必要とするように設定するユーザーが存在する。
  • CA 証明書がクライアントに保存されている。

手順

  1. 管理ユーザーとして MySQL サーバーに接続します。 

    # mysql -u root -p -h server.example.com

    管理ユーザーがリモートでサーバーにアクセスするパーミッションを持たない場合は、MySQL サーバーでコマンドを実行し、localhost に接続します。

  2. REQUIRE SSL 句を使用して、ユーザーが TLS 暗号化接続を使用して接続する必要があるよう強制します。 

    MySQL [(none)]> ALTER USER 'example'@'%' REQUIRE SSL;

検証

  1. TLS 暗号化を使用して、example ユーザーとしてサーバーに接続します。 

    # mysql -u example -p -h server.example.com
...
MySQL [(none)]>

    エラーが表示されず、インタラクティブな MySQL コンソールにアクセスできる場合は、TLS による接続は成功しています。

    デフォルトでは、サーバーが TLS 暗号化を提供している場合、クライアントは自動的にその TLS 暗号化を使用します。したがって、--ssl-ca=ca.crt.pem および --ssl-mode=VERIFY_IDENTITY オプションは必須ではありません。ただし、これらのオプションを使用するとクライアントはサーバーの ID を検証するため、セキュリティーが向上します。

  2. TLS を無効にして、example ユーザーとして接続を試みます。 

    # mysql -u example -p -h server.example.com --ssl-mode=DISABLED
ERROR 1045 (28000): Access denied for user 'example'@'server.example.com' (using password: YES)

    このユーザーには TLS が必要なのにもかかわらず無効になっているため、サーバーはログインの試行を拒否しました (--ssl-mode=DISABLED)。

7.3.5. MySQL クライアントで CA 証明書の検証を使用して TLS 暗号化をグローバルで有効にする
リンクのコピー

MySQL サーバーが TLS 暗号化をサポートしている場合は、クライアントが安全な接続のみを確立し、サーバー証明書を検証するように設定してください。この手順では、サーバー上のすべてのユーザーで TLS サポートを有効にする方法を説明します。

7.3.5.1. デフォルトで TLS 暗号化を使用するように MySQL クライアントを設定する
リンクのコピー

RHEL では、MySQL クライアントが TLS 暗号化を使用するようにグローバルに設定でき、サーバー証明書の Common Name (CN) が、ユーザーが接続するホスト名と一致することを検証します。これにより、man-in-the-middle 攻撃 (中間者攻撃) を防ぎます。

前提条件

  • MySQL サーバーで TLS サポートが有効になっている。
  • CA 証明書は、クライアントの /etc/pki/tls/certs/ca.crt.pem ファイルに保存されます。

手順

  • 以下の内容で /etc/my.cnf.d/mysql-client-tls.cnf ファイルを作成します。 

    [client]
ssl-mode=VERIFY_IDENTITY
ssl-ca=/etc/pki/tls/certs/ca.crt.pem

    これらの設定は、MySQL クライアントが TLS 暗号化を使用すること、およびクライアントがホスト名をサーバー証明書の CN と比較することを定義します (ssl-mode=VERIFY_IDENTITY)。さらに、CA 証明書 (ssl-ca) へのパスも指定します。

検証

  • ホスト名を使用してサーバーに接続し、サーバーの状態を表示します。 

    # 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-mode=VERIFY_IDENTITY パラメーターにより接続が失敗します。たとえば、localhost に接続する場合は、以下のようになります。 

    # mysql -u root -p -h localhost -e status
ERROR 2026 (HY000): SSL connection error: error:0A000086:SSL routines::certificate verify failed

7.3.6. mysql_native_password 認証 から caching_sha2_password 認証へのユーザー移行
リンクのコピー

デフォルトでは、RHEL 8 上の MySQL 8.0 は、非推奨の mysql_native_password 認証プラグインを使用します。セキュリティーを強化するには、caching_sha2_password プラグインを使用してください。

前提条件

  • mysqld サービスが実行されている。

手順

  1. たとえば、MySQL サーバーにログインします。 

    # mysql -u root -p

  2. mysql_native_password プラグインを使用しているアカウントを表示します。 

    mysql> SELECT user, host, plugin from mysql.user WHERE plugin='mysql_native_password';
+------+-----------+-----------------------+
| user | host      | plugin                |
+------+-----------+-----------------------+
| root | localhost | mysql_native_password |
| ...  | ...       | ...                   |
+------+-----------+-----------------------+

  3. mysql_native_password を使用している各アカウントについて、そのレコードを更新します。 

    mysql> ALTER USER '<username>'@'<host>' IDENTIFIED WITH caching_sha2_password BY '<password>';

  4. MySQL サーバーからログアウトしてください。 

    mysql> exit;

検証

  1. 検証対象のアカウントが caching_sha2_password プラグインを使用していることを確認してください。 

    # mysql -u root -p -e "SELECT user, host, plugin from mysql.user WHERE user='<username>';"

  2. ユーザーとして認証する: 

    # mysql -u <username> -p
Enter password: <password>

  3. MySQL サーバーからログアウトしてください。 

    mysql> exit;

7.3.7. 論理ダンプを使用した MySQL データのバックアップと復元
リンクのコピー

MySQL データの論理バックアップは、データの復元に必要な SQL ステートメントで構成されます。物理バックアップに対する論理バックアップの利点は、異なるハードウェア構成や MySQL バージョンでもデータを復元できることです。

7.3.7.1. mysqldump を使用した論理バックアップの実行
リンクのコピー

mysqldump ユーティリティーを使用すると、データベースサーバーが稼働中でも MySQL および MariaDB データベースをバックアップし、エクスポートしたデータを SQL ファイルに保存できます。データが失われた場合に回復できるように、バックアップをセキュアな場所に保存してください。

mysqldump でよく見られるシナリオは以下のとおりです。

  • 単一のデータベースのバックアップ
  • 複数のデータベースのバックアップ
  • すべてのデータベースのバックアップ

mysqldump ユーティリティーは、出力を単一のファイルに保存します。複数のデータベースをバックアップする際に、データベースごとに 1 つのファイルが必要な場合は、各データベースを個別にバックアップしてください。

注記

mysqldump ユーティリティーはデータベースのみをバックアップできます。これには、mysql データベースに格納されているサーバー設定も含まれます。ただし、このユーティリティーは /etc/my.cnf などの設定ファイルはバックアップしません。

前提条件

  • mariadb または mysqld サービスが稼働しています。
  • root アカウントなど、データベースをバックアップする権限を持つ認証情報を持っている。

手順

  • 一貫性のある包括的なデータベースの論理バックアップを作成する。 

    # mysqldump -u <username> -p --routines --events --triggers --single-transaction --result-file=backup.sql --databases <database_1> <database_2>

    各項目の説明:

    -u <username>
    ユーティリティーがデータベースサーバーに接続するために使用するユーザー名を設定します。
    -p
    パスワードの入力を求めます。
    --routines
    バックアップにストアドプロシージャーと関数を含めます。
    --events
    スケジュールされたイベントをバックアップに含めます。
    --triggers
    バックアップにトリガーを含めます。
    --single-transaction

    InnoDB などのトランザクションストレージエンジンを使用するデータベースに対して、整合性の取れたスナップショットの作成を開始します。単一のトランザクションを使用すると、すべての読み取り操作が、ダンプ開始時点のデータベースの状態を反映したものになります。

    MyISAM などの非トランザクションストレージエンジンをまだ使用している場合は、整合性のあるバックアップを確保するために、--single-transaction ではなく --lock-tables オプションを使用してください。

    --result-file=<output_file>
    mysqldump が 出力を保存するファイルを指定します。
    --databases <list_of_databases>

    バックアップするデータベースを定義します。または、すべてのデータベースを一度にバックアップするには、--all-databases オプションを使用します。

    重要

    データベースのバックアップには、そのデータベースのデータのみが含まれます。ユーザーアカウントやその他のサーバー設定は含まれません。サーバーは、この重要なセキュリティー情報とシステム情報を、別の MySQL システムデータベースに保存します。したがって、これらの設定を保持する必要がある場合は、mysql もバックアップする必要があります。

検証

  • サンドボックス環境でバックアップを復元し、データが正しいことを確認します。

  • データベースをリモート MySQL サーバーにロードするには、以下を実行します。 

    # mysql --host=remote_host < backup-file.sql

  • 1 つのデータベースからテーブルのサブセットをダンプするには、mysqldump コマンドの末尾に、選択したテーブルのリストを追加します。 

    # mysqldump [options] db_name [tbl_name ...] > backup-file.sql

  • 1 つのデータベースからダンプされたリテラルなテーブルのサブセットをロードするには、次のコマンドを実行します。 

    # mysql db_name < backup-file.sql
    注記

    この時点で、db_name データベースが存在している必要があります。

  • mysqldump が サポートするオプションのリストを表示するには、以下を実行してください。 

    $ mysqldump --help
7.3.7.2. SQL 形式のダンプから MySQL のデータを復元する
リンクのコピー

1 つまたは複数のデータベースを SQL ファイルにバックアップした場合は、このファイルを使用してデータベース構造とそのデータを再作成できます。

前提条件

  • mysqld サービスが実行されている。
  • root アカウントなど、データを復元する権限を持つ認証情報を持っている。

手順

  1. 復元するデータベースがすでに存在し、SQL ファイルに DROP TABLE IF EXISTS ステートメントが含まれていない場合は、テーブルまたはデータベース全体を手動で削除する必要があります。

    • テーブルを削除するには、次のように入力します。 

      # mysql -u root -p -e "DROP TABLE <database>.<table>;"

      SQL ファイルによって再作成されるすべてのテーブルに対してこのコマンドを繰り返します。

    • データベースを削除するには、次のように入力します。 

      # mysql -u root -p -e "DROP DATABASE <database>;"

      SQL ファイルによって再作成されるすべてのデータベースに対してこのコマンドを繰り返します。

  2. SQL ファイルをインポートします。 

    # mysql -u root -p < backup.sql"

検証

  • MySQL データベースに接続してデータを照会します。次に例を示します。 

    # mysql -u root -p <database> -e "*SELECT * FROM <table>;"

7.3.8. 物理コピーを使用した MySQL データのバックアップと復元
リンクのコピー

MySQL データの物理バックアップには、コンテンツを格納しているファイルとディレクトリーが含まれます。通常、この方法はより高速で、サイズが小さくなります。

7.3.8.1. MySQL サーバーでのファイルシステムバックアップの実行
リンクのコピー

ファイルシステムレベルのバックアップは、MySQL インスタンス全体をバックアップする高速な方法です。この方法では、データの整合性を保つために mysqld サービスをシャットダウンする必要があります。

重要

ファイルシステムレベルのバックアップは、アーキテクチャーと MySQL バージョンに固有のものです。この方法でバックアップしたデータを、異なるアーキテクチャーまたは MySQL バージョンで復元することはできません。

手順

  1. mysqld サービスを停止します。 

    # systemctl stop mysqld.service

  2. バックアップディレクトリーを作成します。次に例を示します。 

    # mkdir -p /root/mysqld-backup/{data,config}/

  3. データディレクトリーをバックアップします。 

    # cp -rp /var/lib/mysql/ /root/mysqld-backup/data/

  4. 設定ファイルをバックアップします。 

    # cp -rp /etc/my.cnf /etc/my.cnf.d/ /root/mysqld-backup/config/

  5. mysqld サービスを開始します。 

    # systemctl start mysqld.service
7.3.8.2. MySQL サーバーでのファイルシステムバックアップの復元
リンクのコピー

MySQL インスタンスが破損した場合は、以前にデータディレクトリーと設定ファイルを含むファイルシステムバックアップを実行済みであれば、このバックアップからインスタンスを復元できます。

前提条件

手順

  1. mysqld サービスを停止します。 

    # systemctl stop mysqld.service

  2. 現在の /var/lib/mysql/ ディレクトリーを削除します。 

    # rm -rf /var/lib/mysql/

  3. バックアップからデータディレクトリーを復元します。 

    # cp -rp /root/mysqld-backup/data/mysql/ /var/lib/

  4. /var/lib/mysql/ ディレクトリーの所有権を正しく設定します。 

    # chown -R mysql:mysql /var/lib/mysql/

  5. /var/lib/mysql/ ディレクトリーの SELinux コンテキストを復元します。 

    # restorecon -Rv /var/lib/mysql/

  6. 現在の設定ファイルを削除します。 

    # rm -rf /etc/my.cnf /etc/my.cnf.d/

  7. バックアップから設定ファイルを復元します。 

    # cp -rp /root/mysqld-backup/config/my.cnf /root/mysqld-backup/config/my.cnf.d/ /etc/

  8. 設定ファイルの所有権を正しく設定します。 

    # chown -R root:root /etc/my.cnf /etc/my.cnf.d/

  9. 設定ファイルの SELinux コンテキストを復元します。 

    # restorecon -Rv /etc/my.cnf /etc/my.cnf.d/

  10. mysqld サービスを開始します。 

    # systemctl start mysqld.service

検証

  • MySQL データベースに接続してデータを照会します。次に例を示します。 

    # mysql -u root -p <database> -e "*SELECT * FROM <table>;"

7.3.9. TLS 暗号化を使用した MySQL のレプリケーション
リンクのコピー

TLS 暗号化を使用した MySQL レプリケーションを設定すると、ソースサーバーとレプリカサーバーの間にセキュアなデータレプリケーション環境を構築できます。

警告

レプリケーション自体は、バックアップソリューションとしては十分ではありません。レプリケーションは、ハードウェア障害からソースサーバーを保護しますが、データ損失に対する保護は保証していません。

7.3.9.1. MySQL ソースサーバーの設定
リンクのコピー

MySQL ソースサーバーを適切に実行し、TLS プロトコルを介してデータベースサーバーで行われたすべての変更をレプリケートするために必要な設定オプションを設定できます。

前提条件

  • ソースサーバーがインストールされている。

  • ソースサーバーに TLS が設定 されている。

    重要

    ソース証明書とレプリカ証明書が、同じ認証局によって署名されている必要があります。

手順

  1. [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

      このオプションを使用して、特定のデータベースをレプリケーションから除外します。

  2. mysqld サービスを再起動します。 

    # systemctl restart mysqld.service
7.3.9.2. MySQL レプリカサーバーの設定
リンクのコピー

レプリケーションを成功させるために MySQL レプリカサーバーに必要な設定オプションを設定できます。

前提条件

  • レプリカサーバーがインストールされている。

  • レプリカサーバーに TLS が設定 されている。

    重要

    ソース証明書とレプリカ証明書が、同じ認証局によって署名されている必要があります。

手順

  1. [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

      このオプションを使用して、特定のデータベースをレプリケーションから除外します。

  2. mysqld サービスを再起動します。 

    # systemctl restart mysqld.service
7.3.9.3. MySQL ソースサーバーでのレプリケーションユーザーの作成
リンクのコピー

レプリカサーバーが接続してデータの変更を受信できるように、MySQL ソースサーバー上で適切な権限を持つレプリケーションユーザーを作成する必要があります。

前提条件

手順

  1. レプリケーションユーザーを作成します。 

    mysql> CREATE USER 'replication_user'@'replica_server_hostname' IDENTIFIED WITH mysql_native_password BY 'password';

  2. ユーザーにレプリケーション権限を付与します。 

    mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'replica_server_hostname';

  3. MySQL データベースの付与テーブルをリロードします。 

    mysql> FLUSH PRIVILEGES;

  4. ソースサーバーを読み取り専用状態に設定します。 

    mysql> SET @@GLOBAL.read_only = ON;
7.3.9.4. レプリカサーバーをソースサーバーに接続する
リンクのコピー

MySQL レプリカサーバーで、認証情報とソースサーバーのアドレスを設定する必要があります。次の手順を使用して、レプリカサーバーを実装します。

前提条件

手順

  1. レプリカサーバーを読み取り専用状態に設定します。 

    mysql> SET @@GLOBAL.read_only = ON;

  2. レプリケーションソースを設定します。 

    mysql> CHANGE REPLICATION SOURCE TO
       SOURCE_HOST='source_hostname',
       SOURCE_USER='replication_user',
       SOURCE_PASSWORD='password',
       SOURCE_AUTO_POSITION=1,
       SOURCE_SSL=1,
       SOURCE_SSL_CA='path_to_ca_on_source',
       SOURCE_SSL_CAPATH='path_to_directory_with_certificates',
       SOURCE_SSL_CERT='path_to_source_certificate',
       SOURCE_SSL_KEY='path_to_source_key';

  3. MySQL レプリカサーバーでレプリカスレッドを開始します。 

    mysql> START REPLICA;

  4. ソースサーバーとレプリカサーバーの両方で、読み取り専用状態の設定を解除します。 

    mysql> SET @@GLOBAL.read_only = OFF;

  5. オプション: デバッグの目的で、レプリカサーバーのステータスを検査します。 

    mysql> SHOW REPLICA STATUS\G;
    注記

    レプリカサーバーの起動または接続に失敗した場合は、SHOW MASTER STATUS コマンドの出力に表示されるバイナリーログファイルの位置に続く特定の数のイベントをスキップできます。たとえば、定義された位置から最初のイベントをスキップします。 

    mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

    レプリカサーバーを再起動してみてください。

  6. オプション: レプリカサーバーでレプリカスレッドを停止します。 

    mysql> STOP REPLICA;
7.3.9.5. MySQL サーバーでのレプリケーションの検証
リンクのコピー

テストデータベースを作成し、ソースサーバーとレプリカサーバーのレプリケーションステータスを確認することで、MySQL レプリケーションが正しく動作していることを検証できます。

手順

  1. ソースサーバーにサンプルデータベースを作成します。 

    mysql> CREATE DATABASE test_db_name;
  2. test_db_name データベースが、レプリカサーバーで複製されていることを確認します。

  3. ソースサーバーまたはレプリカサーバーのいずれかで以下のコマンドを実行して、MySQL サーバーのバイナリーログファイルに関するステータス情報を表示します。 

    mysql> SHOW MASTER STATUS;

    ソースで実行されたトランザクションの GTID のセットを示す Executed_Gtid_Set 列は、空であってはなりません。

    注記

    レプリカサーバーで SHOW REPLICA STATUS を使用すると、同じ GTID のセットが Executed_Gtid_Set 行に表示されます。

7.3.10. MySQL 8.0 の RHEL 8 バージョンへの移行
リンクのコピー

RHEL 7 には、MySQL データベースファミリーのサーバーとして、デフォルトの実装として MariaDB 5.5 が含まれています。Red Hat Software Collections の RHEL 7 向け製品には、MySQL 8.0 と複数のバージョンの MariaDB が含まれています。RHEL 8 は、MySQL 8.0、MariaDB 10.3、および MariaDB 10.5 を提供します。

この手順では、mysql_upgrade ユーティリティーを使用して、Red Hat Software Collections 版の MySQL 8.0 から RHEL 8 版の MySQL 8.0 に移行する方法について説明します。mysql_upgrade ユーティリティーは、mysql-server パッケージによって提供されます。

注記

Red Hat Software Collections 版の MySQL では、ソースデータディレクトリーは /var/opt/rh/rh-mysql80/lib/mysql/ です。RHEL 8 では、MySQL データは /var/lib/mysql/ ディレクトリーに保存されます。

前提条件

  • MySQL データベースと設定ファイルのバックアップを作成しました。

手順

  1. mysql-server パッケージが RHEL 8 システムにインストールされていることを確認します。 

    # yum install mysql-server

  2. データのコピー時に、mysqld サービスがソースシステムとターゲットシステムのどちらでも実行されていないことを確認してください。 

    # systemctl stop mysqld.service
  3. RHEL 7 ソースシステムの /var/opt/rh/rh-mysql80/lib/mysql/ ディレクトリーから RHEL 8 ターゲットシステムの /var/lib/mysql/ ディレクトリーにデータをコピーします。

  4. ターゲットシステムでコピーされたファイルに適切なパーミッションと SELinux コンテキストを設定します。 

    # restorecon -vr /var/lib/mysql

  5. mysql:mysql が、/var/lib/mysql ディレクトリー内のすべてのデータの所有者であることを確認してください。 

    # chown -R mysql:mysql /var/lib/mysql

  6. 対象システム上で MySQL サーバーを起動します。 

    # systemctl start mysqld.service

    注: 以前のバージョンの MySQL では、内部テーブルのチェックと修復に mysql_upgrade コマンドが必要でした。これは、サーバーの起動時に自動的に実行されるようになりました。

7.3.11. RHEL 8 上の MySQL 8.0 から MySQL 8.4 へのアップグレード
リンクのコピー

RHEL 8 上で MySQL データベースをバージョン 8.0 から 8.4 にアップグレードすることで、新機能や改善点を利用できます。

主な機能強化や変更点については、RHEL 8.10 リリースノートの リリースノートを 参照してください。

前提条件

  • あなたは RHEL 8 上で MySQL 8.0 を実行しています。
  • あなたは RHEL 8.10 を使用しています。
  • MySQL データベースと設定ファイルのバックアップを作成しました。

手順

  1. MySQL アカウントがまだ mysql_native_password 認証プラグインを使用しているかどうかを確認します。 

    # mysql -u root -p -e "SELECT user, host, plugin from mysql.user WHERE plugin='mysql_native_password';"

    デフォルトでは、RHEL 8 上の MySQL 8.4 では、非推奨の mysql_native_password プラグインは無効になっています。コマンドがレコードを返した場合、続行する前に以下のいずれかのオプションを選択してください。

  2. mysqld サービスを停止します。 

    # systemctl stop mysqld.service

  3. モジュール式の MySQL 8.4 ストリームに切り替えましょう。 

    # dnf module switch-to mysql:8.4
  4. /etc/my.cnf.d/ ディレクトリーにあるファイルに、MySQL 8.4 に有効な設定のみが含まれるように設定を調整してください。詳細は、上流のドキュメント を参照してください。

  5. mysqld サービスを開始します。 

    # systemctl start mysqld.service

    サービスが起動すると、MySQL は内部テーブルを自動的にチェック、修復、更新します。

7.3.12. MySQL クライアントアプリケーションの開発
リンクのコピー

MariaDB クライアントアプリケーションは、MariaDB クライアントライブラリーを使用して開発する必要があります。これらのアプリケーションを構築するために必要な開発ファイルとプログラムは、mariadb-connector-c-devel パッケージによって提供されます。

直接ライブラリー名を使用する代わりに、mariadb-connector-c-devel パッケージで配布されている mariadb_config プログラムを使用します。このプログラムにより、正しいビルドフラグが確実に返されるようになります。

7.4. PostgreSQL の使用
リンクのコピー

PostgreSQL サーバーは、SQL 言語に基づいた、堅牢で拡張性の高いオープンソースのデータベースサーバーです。PostgreSQL サーバーは、大規模なデータセットと多数の同時ユーザーを管理できるオブジェクトリレーショナルデータベースシステムを提供します。

PostgreSQL サーバーには、データの整合性の確保、耐障害性のある環境やアプリケーションの構築を行うための機能が含まれます。PostgreSQL サーバーを使用すると、データベースを再コンパイルすることなく、独自のデータ型、カスタム関数、またはさまざまなプログラミング言語のコードでデータベースを拡張できます。

RHEL システムに PostgreSQL をインストールして設定する方法、PostgreSQL データをバックアップする方法、および PostgreSQL の以前のバージョンから移行する方法を説明します。

7.4.1. PostgreSQL のインストール
リンクのコピー

RHEL 8 では、アプリケーションストリームの初期バージョンとして PostgreSQL 9.6 が提供されます。RHEL 8 のマイナーリリースでは、より短いライフサイクルを持つモジュールとして、追加の PostgreSQL バージョンが提供されます。

RHEL 8 では、PostgreSQL は以下のバージョンで利用可能であり、それぞれが個別のストリームによって提供されます。

  • PostgreSQL 10 - デフォルトストリーム
  • PostgreSQL 9.6
  • PostgreSQL 12 - RHEL 8.1.1 以降で利用できます。
  • PostgreSQL 13: RHEL 8.4 以降で利用できます。
  • PostgreSQL 15 - RHEL 8.8 以降で利用可能
  • PostgreSQL 16 - RHEL 8.10 以降で利用可能
注記

設計上、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできません。したがって、postgresql モジュールから利用可能なストリームのいずれかを選択する必要があります。コンテナー内では、異なるバージョンの PostgreSQL データベースサーバーを使用できます。詳しくは、コンテナー内で複数の PostgreSQL バージョンを実行するを 参照してください。

モジュールストリームの使用方法については、ユーザー空間コンポーネントのインストール、管理、および削除 を参照してください。

手順

  1. postgresql モジュールからストリーム (バージョン) を選択し、サーバープロファイルを指定することで、PostgreSQL サーバーパッケージをインストールします。以下に例を示します。 

    # yum module install postgresql:16/server

    postgres のスーパーユーザーが自動的に作成されます。

  2. データベースクラスターを初期化します。 

    # postgresql-setup --initdb

    Red Hat は、デフォルトの /var/lib/pgsql/data ディレクトリーにデータを保存することを推奨します。

  3. postgresql サービスを開始します。 

    # systemctl start postgresql.service

  4. postgresql サービスが、システムの起動時に起動するようにします。 

    # systemctl enable postgresql.service

7.4.2. コンテナーを使用して単一ホスト上で複数の PostgreSQL インスタンスを実行する
リンクのコピー

同じホスト上で異なるバージョンの PostgreSQL を実行するには、コンテナー内で実行する必要があります。なぜなら、同じモジュールの複数のバージョン (ストリーム) を並行してインストールすることはできないからです。

前提条件

  • container-tools モジュールがインストールされている。

手順

  1. Red Hat カスタマーポータルアカウントを使用して、registry.redhat.io レジストリーに認証します。 

    # podman login registry.redhat.io

    すでにコンテナーレジストリーにログインしている場合は、このステップをスキップしてください。

  2. コンテナー内で PostgreSQL 13 を実行する: 

    $ podman run -d --name <container_name> -e POSTGRESQL_USER=<user_name> -e POSTGRESQL_PASSWORD=<password> -e POSTGRESQL_DATABASE=<database_name> -p <host_port_1>:5432 rhel8/postgresql-13

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  3. コンテナー内で PostgreSQL 15 を実行する: 

    $ podman run -d --name <container_name> -e POSTGRESQL_USER=<user_name> -e POSTGRESQL_PASSWORD=<password> -e POSTGRESQL_DATABASE=<database_name> -p <host_port_2>:5432 rhel8/postgresql-15

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

  4. コンテナー内で PostgreSQL 16 を実行する: 

    $ podman run -d --name <container_name> -e POSTGRESQL_USER=<user_name> -e POSTGRESQL_PASSWORD=<password> -e POSTGRESQL_DATABASE=<database_name> -p <host_port_3>:5432 rhel8/postgresql-16

    このコンテナーイメージの使用方法の詳細は、Red Hat Ecosystem Catalog を 参照してください。

    注記

    2 つのデータベースサーバーのコンテナー名とホストポートが異なっている必要があります。

  5. クライアントがネットワーク上のデータベースサーバーにアクセスできるように、ファイアウォールでホストポートを開きます。 

    # firewall-cmd --permanent --add-port={<host_port_1>/tcp,<host_port_2>/tcp,...}
# firewall-cmd --reload

検証

  1. 実行中のコンテナーに関する情報を表示します。 

    $ podman ps

  2. データベースサーバーに接続し、root としてログインします。 

    # psql -u postgres -p -h localhost -P <host_port> --protocol tcp

7.4.3. PostgreSQL ユーザーの作成
リンクのコピー

特定の権限を持つ PostgreSQL ユーザーを作成して、データベースへのアクセスを管理し、ユーザーの特権を制御することで、セキュアなデータベース管理を実現できます。

PostgreSQL ユーザーは以下のタイプのものです。

  • postgres Linux システムユーザー: PostgreSQL サーバーおよびクライアントアプリケーション (pg_dump など) を実行するためにのみ使用します。データベース作成およびユーザー管理などの、PostgreSQL 管理上の対話的な作業には postgres システムユーザーを使用しないでください。
  • データベースのスーパーユーザー: デフォルトの postgres PostgreSQL スーパーユーザーは、postgres システムユーザーとは関係ありません。/var/lib/pgsql/data/pg_hba.conf ファイルで postgres スーパーユーザーのアクセスを制限できます。それ以外の場合、他のパーミッションの制限はありません。他のデータベースのスーパーユーザーを作成することもできます。

  • 特定のデータベースアクセスパーミッションを持つロール:

    • データベースユーザー: デフォルトでログインするパーミッションがあります。
    • ユーザーのグループ: グループ全体のパーミッションを管理できるようにします。

ロールはデータベースオブジェクト (テーブルや関数など) を所有でき、SQL コマンドを使用して他のロールにオブジェクト特権を割り当てることができます。

標準のデータベース管理権限には SELECT、INSERT、UPDATE、DELETE、TRUNCATE、REFERENCES、TRIGGER、CREATE、CONNECT、TEMPORARY、EXECUTE、および USAGE が含まれます。

ロール属性は、LOGIN、SUPERUSER、CREATEDB、および CREATEROLE などの特別な権限です。

重要

ほとんどのタスクをスーパーユーザー以外のロールとして実行します。一般的な方法として、CREATEDB および CREATEROLE の権限を持つロールを作成し、このロールをデータベースおよびロールのすべてのルーチン管理に使用します。

前提条件

  • PostgreSQL サーバーがインストールされている。
  • データベースクラスターが初期化されている
  • /var/lib/pgsql/data/postgresql.conf ファイルの password_encryption パラメーターが scram-sha-256 に設定されている。
  • /var/lib/pgsql/data/pg_hba.conf ファイル内のエントリーが、認証方法として scram-sha-256 ハッシュアルゴリズムを使用している。

手順

  1. postgres システムユーザーとしてログインするか、このユーザーに切り替えます。 

    # su - postgres

  2. PostgreSQL インタラクティブターミナルを起動します。 

    $ psql
psql (16.4)
Type "help" for help.

postgres=#

  3. オプション: 現在のデータベース接続に関する情報を取得します。 

    postgres=# \conninfo
You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".

  4. mydbuser という名前のユーザーを作成し、パスワードを設定して、そのユーザーに CREATEROLE および CREATEDB パーミッションを割り当てます。 

    postgres=# CREATE USER mydbuser WITH PASSWORD '<password>' CREATEROLE CREATEDB;
CREATE ROLE

    これで、mydbuser ユーザーは、日常的なデータベース管理操作 (データベースの作成とユーザーインデックスの管理) を実行できるようになりました。

  5. \q メタコマンドを使用して、インタラクティブターミナルからログアウトします。 

    postgres=# \q

検証

  1. mydbuser として PostgreSQL ターミナルにログインし、ホスト名を指定して、初期化中に作成されたデフォルトの postgres データベースに接続します。 

    # psql -U mydbuser -h 127.0.0.1 -d postgres
Password for user mydbuser:
Type the password.
psql (16.4)
Type "help" for help.

postgres=>

  2. データベースを作成します。 

    postgres=> CREATE DATABASE <db_name>;

  3. セッションからログアウトします。 

    postgres=# \q

  4. mydbuser として新しいデータベースに接続します。 

    # psql -U mydbuser -h 127.0.0.1 -d <db_name>
Password for user mydbuser:
psql (16.4)
Type "help" for help.
mydatabase=>

7.4.4. PostgreSQL の設定
リンクのコピー

データベースクラスターディレクトリー内の設定ファイルを編集して、データベースのパラメーター、認証、およびクライアントアクセスを設定することで、PostgreSQL を設定できます。デフォルトでは、PostgreSQL は /var/lib/pgsql/data/ ディレクトリーを使用します。

PostgreSQL 設定は、次のファイルで構成されます。

  • postgresql.conf - データベースクラスターのパラメーターを設定するために使用されます。
  • postgresql.auto.conf - postgresql.conf と同様に、基本的な PostgreSQL の設定を保持します。ただし、このファイルはサーバーの管理下にあります。これは、ALTER SYSTEM クエリーにより編集され、手動で編集することはできません。
  • pg_ident.conf - 外部認証メカニズムからのユーザーアイデンティティーを PostgreSQL ユーザーアイデンティティーにマッピングするために使用されます。
  • pg_hba.conf は、PostgreSQL データベースのクライアント認証を設定するために使用されます。

PostgreSQL の設定を変更するには、以下の手順に従ってください。

手順

  1. /var/lib/pgsql/data/postgresql.conf ファイルを編集し、データベースクラスターパラメーターの基本設定を行います。次に例を示します。 

    log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
password_encryption = scram-sha-256

  2. /var/lib/pgsql/data/pg_hba.conf ファイルを編集し、クライアント認証を設定します。次に例を示します。 

    # TYPE    DATABASE       USER        ADDRESS              METHOD
local     all            all                              trust
host      postgres       all         192.168.93.0/24      ident
host      all            all         .example.com         scram-sha-256

  3. postgresql サービスを再起動して、変更を有効にします。 

    # systemctl restart postgresql.service

7.4.5. PostgreSQL サーバーにおける TLS 暗号化の設定
リンクのコピー

デフォルトでは、PostgreSQL は暗号化されていない接続を使用します。よりセキュアな接続のために、PostgreSQL サーバーで Transport Layer Security (TLS) サポートを有効にし、暗号化された接続を確立するようにクライアントを設定できます。

前提条件

  • TLS 秘密鍵を作成済みであり、かつ認証局 (CA) によって PostgreSQL サーバー用のサーバー証明書が発行されている。
  • PostgreSQL サーバーがインストールされている。
  • データベースクラスターが初期化されている

手順

  1. 秘密鍵とサーバー証明書を /var/lib/pgsql/data/ ディレクトリーに保存します。 

    # cp server.{key,crt} /var/lib/pgsql/data/

  2. 秘密鍵と証明書の所有権を設定します。 

    # chown postgres:postgres /var/lib/pgsql/data/server.{key,crt}

  3. PostgreSQL サーバーのみがファイルを読み取れるように、サーバー証明書のパーミッションを設定します。 

    # chmod 0400 /var/lib/pgsql/data/server.key

    証明書は、セキュアな接続が確立される前は通信の一部であるため、任意のクライアントは認証なしで証明書を取得できます。したがって、サーバー証明書ファイルに厳密なパーミッションを設定する必要はありません。

  4. /var/lib/pgsql/data/postgresql.conf ファイルを編集し、次の変更を加えます。

    1. scram-sha-256 ハッシュアルゴリズムを設定します。 

      password_encryption = scram-sha-256

    2. TLS 暗号化を有効にします。 

      ssl = on

  5. /var/lib/pgsql/data/pg_hba.conf ファイルを編集し、TLS 暗号化と scram-sha-256 ハッシュアルゴリズムを使用するように認証エントリーを更新します。たとえば、TLS 暗号化を有効にするには、host エントリーを hostssl に変更し、最後の列に scram-sha-256 ハッシュアルゴリズムを設定します。 

    hostssl    all    all    192.0.2.0/24    scram-sha-256

  6. postgresql サービスを再起動します。 

    # systemctl restart postgresql.service

検証

  • postgres スーパーユーザーを使用して PostgreSQL サーバーに接続し、\conninfo メタコマンドを実行します。 

    # psql "postgresql://postgres@localhost:5432" -c '\conninfo'
Password for user postgres:
You are connected to database "postgres" as user "postgres" on host "192.0.2.1" at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)

7.4.6. 論理ダンプを使用した PostgreSQL データのバックアップと復元
リンクのコピー

PostgreSQL データの論理バックアップは、データの復元に必要な SQL ステートメントで構成されます。物理バックアップに対する論理バックアップの利点は、異なるハードウェア構成や PostgreSQL バージョンでもデータを復元できることです。

SQL ダンプのメソッドは、SQL コマンドを使用したダンプファイルの生成に基づいています。ダンプがデータベースサーバーにアップロードされると、ダンプ時と同じ状態でデータベースが再作成されます。

SQL ダンプは、次の PostgreSQL クライアントアプリケーションによって実現されます。

  • pg_dump は、ロールまたはテーブル空間に関するクラスター全体の情報なしに単一のデータベースをダンプします。
  • pg_dumpall は、指定のクラスターに各データベースをダンプし、ロールやテーブル空間定義などのクラスター全体のデータを保持します。

デフォルトでは、pg_dump コマンドおよび pg_dumpall コマンドは、結果を標準出力に書き込みます。ダンプをファイルに保存するには、出力を SQL ファイルにリダイレクトします。作成される SQL ファイルは、テキスト形式またはその他の形式のいずれかになります。これにより並列処理が可能になり、オブジェクトの復元をより詳細に制御できます。

データベースにアクセスできる任意のリモートホストから、SQL ダンプを実行できます。

7.4.6.1. SQL ダンプの長所と短所
リンクのコピー

SQL ダンプは、データベースの構造とデータを SQL ステートメントの形式で含むテキストファイルです。

利点:

  • SQL ダンプは、サーバーのバージョン固有ではない唯一の PostgreSQL バックアップメソッドです。pg_dump ユーティリティーの出力は、PostgreSQL の後のバージョンに再ロードできますが、ファイルシステムレベルのバックアップや継続的なアーカイブではこれは不可能です。
  • SQL ダンプは、32 ビットサーバーから 64 ビットサーバーへなど、異なるアーキテクチャーにデータベースを転送する際に有効な唯一の方法です。
  • SQL ダンプは、内部的に一貫性のあるダンプを提供します。ダンプは、pg_dump の実行開始時のデータベースのスナップショットを表します。
  • pg_dump ユーティリティーは、実行中のデータベースの他の操作をブロックしません。

欠点:

  • SQL ダンプは、ファイルシステムレベルのバックアップに比べて時間がかかります。
7.4.6.2. pg_dump を使用した単一の PostgreSQL データベースのバックアップ
リンクのコピー

pg_dump ユーティリティーを使用してデータベース構造とデータをファイルにエクスポートすることにより、単一の PostgreSQL データベースのバックアップを作成できます。

前提条件

  • postgres スーパーユーザーまたはデータベース管理者特権を持つユーザーとしてログインしている。

手順

  • クラスター全体の情報なしでデータベースをダンプします。 

    $ pg_dump <db_name> > <dump_file>

    pg_dump が接続するデータベースサーバーを指定するには、以下のコマンドラインオプションを使用します。

    • ホストを定義する -h オプション

      デフォルトのホストは、ローカルホストか、PGHOST 環境変数で指定されているものです。

    • ポートを定義する -p オプション

      デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。

7.4.6.3. pg_dump を使用した単一の PostgreSQL データベースの復元
リンクのコピー

pg_restore ユーティリティーを使用してデータベース構造とデータを再作成することで、SQL ダンプファイルから PostgreSQL データベースを復元できます。

前提条件

  • postgres スーパーユーザーまたはデータベース管理者特権を持つユーザーとしてログインしている。

手順

  1. 新しいデータベースを作成します。 

    $ createdb <db_name>
  2. ダンプされたデータベースのオブジェクトを所有するか、オブジェクトに対する権限が許可されたユーザーがすべて存在していることを検証してください。このようなユーザーが存在しない場合、復元は元の所有権と権限でオブジェクトの再作成に失敗します。

  3. psql ユーティリティーを実行して、pg_dump ユーティリティーが作成したテキストファイルのダンプを復元します。 

    $ psql <db_name> < <dump_file>

    ここでの <dump_file> は、pg_dump コマンドの出力になります。テキスト以外のファイルダンプを復元するには、代わりに pg_restore ユーティリティーを使用します。 

    $ pg_restore <non-plain_text_file>
7.4.6.4. pg_dumpall を使用した PostgreSQL サーバー上の全データベースのバックアップ
リンクのコピー

pg_dumpall ユーティリティーを使用して、すべてのデータベースとクラスター全体のデータを 1 つのファイルにエクスポートすることにより、PostgreSQL サーバー上の全データベースのバックアップを作成できます。

前提条件

  • postgres スーパーユーザーまたはデータベース管理者特権を持つユーザーとしてログインしている。

手順

  • データベースクラスターのすべてのデータベースをダンプし、クラスター全体のデータを保存します。 

    $ pg_dumpall > <dump_file>

    pg_dumpall が接続するデータベースサーバーを指定するには、次のコマンドラインオプションを使用します。

    • ホストを定義する -h オプション

      デフォルトのホストは、ローカルホストか、PGHOST 環境変数で指定されているものです。

    • ポートを定義する -p オプション

      デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。

    • デフォルトのデータベースを定義する -l オプション。

      このオプションにより、初期化時に自動的に作成された postgres データベースとは異なるデフォルトのデータベースを選択できます。

7.4.6.5. pg_dumpall を使用した PostgreSQL サーバー上の全データベースの復元
リンクのコピー

psql ユーティリティーを使用してデータベースクラスター全体を再作成することで、pg_dumpall ファイルから PostgreSQL サーバー上のすべてのデータベースを復元できます。

前提条件

  • postgres スーパーユーザーまたはデータベース管理者特権を持つユーザーとしてログインしている。

手順

  1. ダンプされたデータベースのオブジェクトを所有するか、オブジェクトに対する権限が許可されたユーザーがすべて、すでに存在していることを検証してください。このようなユーザーが存在しない場合、復元は元の所有権と権限でオブジェクトの再作成に失敗します。

  2. psql ユーティリティーを実行して、pg_dumpall ユーティリティーにより作成されたテキストファイルのダンプを復元します。 

    $ psql < <dump_file>

    ここでの <dump_file> は、pg_dumpall コマンドの出力になります。

7.4.6.6. 復元中の SQL エラーの処理
リンクのコピー

デフォルトでは、SQL エラーが発生した場合でも psql ユーティリティーは実行を継続します。これは、データベースが部分的にしか復元されない原因となります。データの整合性を確保するために、エラー時に停止するように psql を設定できます。

前提条件

  • postgres スーパーユーザーまたはデータベース管理者特権を持つユーザーとしてログインしている。

手順

  • ON_ERROR_STOP 変数を設定して SQL エラーが発生した場合は、終了ステータスが 3 で psql を終了します。 

    $ psql --set ON_ERROR_STOP=on dbname < dumpfile

  • ダンプ全体が単一のトランザクションとして復元されるように指定して、復元が完全に完了するかキャンセルされるようにします。

    • psql ユーティリティーを使用してテキストファイルのダンプを復元する場合: 

      $ psql -1

    • pg_restore ユーティリティーを使用してテキストファイル以外のダンプを復元する場合: 

      $ pg_restore -e

      この方法を使用する場合は、多少のエラーでも、すでに何時間も実行している復元操作をキャンセルできます。

7.4.7. 物理コピーを使用した PostgreSQL データのバックアップと復元
リンクのコピー

PostgreSQL データの物理バックアップには、コンテンツを格納しているファイルとディレクトリーが含まれます。通常、この方法はより高速で、サイズが小さくなります。

7.4.7.1. PostgreSQL サーバーでのファイルシステムバックアップの実行
リンクのコピー

ファイルシステムレベルのバックアップは、PostgreSQL インスタンス全体をバックアップする高速な方法です。この方法では、データの整合性を保つために postgresql サービスをシャットダウンする必要があります。

重要

PostgreSQL のファイルシステムレベルのバックアップは、アーキテクチャーと RHEL メジャーバージョンに固有のものです。この方法でバックアップしたデータは、異なるアーキテクチャーまたは RHEL メジャーバージョンで復元することはできません。

手順

  1. postgresql サービスを停止します。 

    # systemctl stop postgresql.service

  2. バックアップディレクトリーを作成します。次に例を示します。 

    # mkdir -p /root/postgresql-backup/

  3. /var/lib/pgsql/ ディレクトリーをバックアップします。 

    # cp -rp /var/lib/pgsql/ /root/postgresql-backup/

    /var/lib/pgsql/ には、設定ファイル、データファイル、ログなど、PostgreSQL データベースサーバーの重要なファイルがすべて含まれています。

  4. postgresql サービスを開始します。 

    # systemctl start postgresql.service
7.4.7.2. PostgreSQL サーバーでのファイルシステムバックアップの復元
リンクのコピー

PostgreSQL インスタンスが破損した場合は、以前にデータディレクトリーを含むファイルシステムバックアップを実行済みであれば、このバックアップからインスタンスを復元できます。

前提条件

手順

  1. postgresql サービスを停止します。 

    # systemctl stop postgresql.service

  2. 現在の /var/lib/pgsql/ ディレクトリーを削除します。 

    # rm -rf /var/lib/pgsql/

  3. バックアップからデータディレクトリーを復元します。 

    # cp -rp /root/postgresql-backup/pgsql/ /var/lib/

  4. /var/lib/pgsql/ ディレクトリーの所有権を正しく設定します。 

    # chown -R postgres:postgres /var/lib/pgsql/

  5. /var/lib/pgsql/ ディレクトリーの SELinux コンテキストを復元します。 

    # restorecon -Rv /var/lib/pgsql/

  6. postgresql サービスを開始します。 

    # systemctl start postgresql.service

検証

  1. postgres ユーザーとしてログインします。

  2. データベースに接続します。 

    $ psql <database>

  3. データベース内のデータにアクセスします。 

    <database>=# SELECT * FROM <table>;

  4. PostgreSQL サービスから切断します。 

    <database>=# \q

7.4.8. 継続的アーカイブを使用した PostgreSQL データのバックアップと復元
リンクのコピー

継続的アーカイブを使用すると、WAL ファイルとベースバックアップを組み合わせることで、ポイントインタイムリカバリーと高可用性に対応した堅牢な PostgreSQL バックアップを作成できます。

PostgreSQL は、データベースのデータファイルに対するすべての変更を、クラスターのデータディレクトリーの pg_wal/ サブディレクトリーにあるログ先行書き込み (WAL) ファイルに記録します。このログは、主にクラッシュからの復元を目的としています。クラッシュが発生した後、最後のチェックポイント以降に作成されたログエントリーを使用して、データベースを整合性の取れた状態に復元できます。

オンラインバックアップとも呼ばれる継続的なアーカイブメソッドは、WAL ファイルを、稼働中のサーバーまたはファイルシステムレベルのバックアップで実行されるベースバックアップの形式でデータベースクラスターのコピーと組み合わせます。

データベースの復元が必要な場合は、データベースクラスターのコピーからデータベースを復元してから、バックアップした WAL ファイルからログをリプレイすることで、システムを現在の状態に戻すことができます。

継続的なアーカイブメソッドでは、少なくとも最後のベースバックアップの開始時間までさかのぼって、アーカイブされたすべての WAL ファイルの連続したシーケンスを保持する必要があります。そのため、基本バックアップの理想的な頻度は、次の条件により異なります。

  • アーカイブされた WAL ファイルで利用可能なストレージボリューム。
  • 復元が必要な場合の、データ復元の最大許容期間。最後のバックアップからの期間が長い場合、システムはより多くの WAL セグメントを再生するため、回復に時間がかかります。
注記

pg_dump および pg_dumpall SQL ダンプは、継続的にアーカイブするバックアップソリューションの一部として使用することができません。SQL ダンプは論理バックアップを生成しますが、WAL 再生で使用する上で十分な情報は含まれていません。

7.4.8.1. 継続的なアーカイブの長所と短所
リンクのコピー

継続的アーカイブは、データベースのトランザクションログファイルを継続的に保存することで、データのバックアップ、高可用性、およびポイントインタイムリカバリー (PITR) のための堅牢な手法を提供する機能です。

利点:

  • 継続的なバックアップメソッドでは、バックアップ内の内部不整合がログ再生により修正されるため、整合性が完全に取れないベースバックアップを使用することができます。したがって、実行中の PostgreSQL サーバーでベースバックアップを実行できます。
  • ファイルシステムのスナップショットは必要ありません。tar または同様のアーカイブユーティリティーで十分です。
  • 継続的にバックアップを行うには、継続的に WAL ファイルをアーカイブします。これは、ログ再生用の WAL ファイルの順序が無限に長くなる可能性があるためです。これは、特に大規模なデータベースで有用です。
  • 継続的バックアップは、特定の時点への復旧 (ポイントインタイムリカバリー) をサポートします。WAL エントリーを最後まで再生する必要はありません。再生はいつでも停止でき、ベースバックアップを作成してから、データベースをいつでもその状態に復元できます。
  • 一連の WAL ファイルが同じベースのバックアップファイルで読み込まれた別のマシンが継続的に利用可能である場合は、任意の時点で、データベースで現在に一番近いコピーで、他のマシンを復元できます。

欠点:

  • 継続バックアップ方法は、サブセットではなく、データベースクラスター全体の復元のみをサポートします。
  • 継続的にバックアップするには、大きなアーカイブストレージが必要です。
7.4.8.2. WAL アーカイブの設定
リンクのコピー

PostgreSQL サーバーでログ先行書き込み (WAL) アーカイブを有効にすると、バックアップやポイントインタイムリカバリーのために、WAL セグメントファイルを取得して保存できます。

稼働中の PostgreSQL サーバーは、一連の WAL レコードを生成する。サーバーは、このシーケンスを WAL セグメントファイルに物理的に分割します。このファイルには、WAL シーケンスの位置を反映する数値名が与えられます。WAL のアーカイブを使用しない場合は、セグメントファイルは再利用され、より大きなセグメント番号に名前が変更されます。

WAL データをアーカイブする場合、各セグメントファイルの内容がキャプチャーされ、新しい場所に保存されてから、セグメントファイルが再利用されます。別のマシン上の NFS マウントディレクトリー、テープドライブ、または CD など、コンテンツの保存場所には複数のオプションがあります。

WAL レコードには、設定ファイルへの変更が含まれていないことに注意してください。

手順

  1. /var/lib/pgsql/data/postgresql.conf ファイルで以下を行います。

    1. wal_level 設定パラメーターを replica 以降に設定します。
    2. archive_mode パラメーターを on に設定します。

    3. archive_command 設定パラメーターでシェルコマンドを指定します。cp コマンド、別のコマンド、またはシェルスクリプトを使用できます。

      以下に例を示します。 

      archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'

      %p パラメーターは、アーカイブするファイルの相対パスに置き換えられ、%f パラメーターはファイル名に置き換えられます。

      このコマンドは、アーカイブ可能な WAL セグメントを /mnt/server/archivedir/ ディレクトリーにコピーします。%p パラメーターおよび %f パラメーターを置き換えると、実行されたコマンドは以下のようになります。 

      test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

      アーカイブされる新規ファイルごとに同様のコマンドが生成されます。

      注記

      archive コマンドは、完了した WAL セグメントでのみ実行されます。WAL トラフィックをほとんど生成しないサーバーでは、トランザクションの完了とアーカイブストレージへの安全な記録の間にかなりの遅延が生じる可能性があります。アーカイブされていないデータの古さを制限するには、以下を行います。

      • archive_timeout パラメーターを設定して、サーバーが特定の頻度で新しい WAL セグメントファイルに切り替えるように強制します。
      • pg_switch_wal パラメーターを使用して、セグメント切り替えを強制し、トランザクションが終了後すぐにアーカイブされるようにします。

  2. postgresql サービスを再起動して、変更を適用します。 

    # systemctl restart postgresql.service
  3. アーカイブコマンドをテストし、既存のファイルが上書きされないこと、失敗した場合にゼロ以外の終了ステータスが返されることを確認します。
  4. データを保護するには、セグメントファイルがグループまたはワールド読み取りアクセスを持たないディレクトリーにアーカイブされていることを確認してください。
7.4.8.3. ベースバックアップの作成
リンクのコピー

pg_basebackup ユーティリティーを使用すると、バックアップと復元のために、データベースの整合性の取れたスナップショットを取得し、PostgreSQL ベースバックアップを作成できます。

ベースバックアッププロセスは、WAL アーカイブ領域に保存され、ベースバックアップに必要な最初の WAL セグメントファイルにちなんで名付けられたバックアップ履歴ファイルを作成します。

バックアップ履歴ファイルは、開始時間および終了時間、およびバックアップの WAL セグメントが含まれる小さなテキストファイルです。ラベル文字列を使用して関連するダンプファイルを特定した場合は、バックアップ履歴ファイルを使用して復元するダンプファイルを判断できます。

注記

データを確実に復元できるようにするために、複数のバックアップセットを維持することを検討してください。

前提条件

  • postgres スーパーユーザー、データベース管理者特権を持つユーザー、または少なくとも REPLICATION 権限を持つその他のユーザーとしてログインしている。
  • ベースバックアップ中およびベースバックアップ後に生成されたすべての WAL セグメントファイルを保持する必要があります。

手順

  1. pg_basebackup ユーティリティーを使用してベースバックアップを実行します。

    • 個々のファイル (プレーン形式) としてベースバックアップを作成するには、以下を実行します。 

      $ pg_basebackup -D backup_directory -Fp

      backup_directory は、任意のバックアップの場所に置き換えます。

      テーブル空間を使用し、サーバーと同じホストでベースバックアップを実行する場合は、--tablespace-mapping オプションも使用する必要があります。そうしないと、バックアップを同じ場所に書き込もうとすると、バックアップが失敗します。

    • tar アーカイブ (tar および圧縮形式) としてベースバックアップを作成するには、以下を実行します。 

      $ pg_basebackup -D backup_directory -Ft -z

      backup_directory は、任意のバックアップの場所に置き換えます。

      このようなデータを復元するには、ファイルを正しい場所に手動で抽出する必要があります。

    pg_basebackup が接続するデータベースサーバーを指定するには、以下のコマンドラインオプションを使用します。

    • ホストを定義する -h オプション

      デフォルトのホストは、ローカルホストまたは PGHOST 環境変数により指定されたホストです。

    • ポートを定義する -p オプション

      デフォルトのポートは、PGPORT 環境変数またはコンパイル済みデフォルトで示されます。

  2. ベースバックアッププロセスが完了すると、バックアップ履歴ファイルで指定されている、データベースクラスターのコピーとバックアップ中に使用された WAL セグメントファイルを安全にアーカイブします。
  3. ベースバックアップで使用されている WAL セグメントファイルよりも数値が小さい WAL セグメントを削除します。これらはベースバックアップよりも古く、復元には必要ないためです。
7.4.8.4. 継続的なアーカイブバックアップを使用したデータベースの復元
リンクのコピー

ベースバックアップを復元し、アーカイブされた WAL ファイルを適用してポイントインタイムリカバリーを行うことで、PostgreSQL データベースを復元できます。

手順

  1. サーバーを停止します。 

    # systemctl stop postgresql.service

  2. 必要なデータを一時的な場所にコピーします。

    必要に応じて、クラスターデータのディレクトリー全体と、すべてのテーブル空間をコピーします。既存データベースのコピーを 2 つ保持するには、システムに十分な空き領域が必要になることに注意してください。

    十分な容量がない場合は、クラスターの pg_wal ディレクトリーの内容を保存します。これには、システムがダウンする前にアーカイブされなかったログが含まれます。

  3. クラスターデータディレクトリー、および使用しているテーブルスペースのルートディレクトリー下の既存ファイルおよびサブディレクトリーをすべて削除します。

  4. ベースバックアップからデータベースファイルを復元します。

    以下の点を確認してください。

    • ファイルは、正しい所有権 (root ではなくデータベースシステムのユーザー) で復元されます。
    • ファイルは、正しいパーミッションで復元されます。
    • pg_tblspc/ サブディレクトリーのシンボリックリンクが正しく復元されます。

  5. pg_wal/ サブディレクトリーにあるファイルをすべて削除します。

    このファイルは、ベースバックアップから作成されるため、非推奨になりました。pg_wal/ をアーカイブしていない場合は、適切な権限で再作成します。

  6. 手順 2 で保存したアーカイブされていない WAL セグメントファイルを pg_wal/ にコピーします。

  7. クラスターデータディレクトリーの recovery.conf リカバリーコマンドファイルを作成し、restore_command 設定パラメーターにシェルコマンドを指定します。cp コマンド、別のコマンド、またはシェルスクリプトを使用できます。以下に例を示します。 

    restore_command = 'cp /mnt/server/archivedir/%f "%p"'

  8. サーバーを起動します。 

    # systemctl start postgresql.service

    サーバーは復元モードに入り、必要なアーカイブ済み WAL ファイルの読み込みを開始します。

    外部エラーにより復元が終了した場合は、サーバーを再起動して復元を続行します。復元プロセスが完了すると、サーバーは recovery.conf の名前を recovery. done に変更します。これにより、サーバーが通常のデータベース操作を開始した後に誤って復元モードに戻ることが防止されます。

  9. データベースのコンテンツを確認して、データベースが必要な状態に復元されたことを検証します。

    データベースが必要な状態に復元されていない場合は、手順 1 に戻ります。データベースが必要な状態に復元された場合は、pg_hba.conf ファイルでクライアント認証設定を復元して接続できるようにします。

7.4.9. PostgreSQL データベースをあるサーバーから別のサーバーに直接転送する
リンクのコピー

pg_dump および psql ユーティリティーを使用して PostgreSQL データベースをバックアップし、別の PostgreSQL サーバー上で直接復元できます。この方法を使用すると、中間ファイルなしで 1 つのステップでデータベースを転送できます。

前提条件

  • postgres ユーザーとしてログインしている。

手順

  • ソースサーバーからターゲットサーバーにデータベースを転送します。 

    $ pg_dump -h <source_server> <db_name> | psql -h <destination_server> <db_name>

7.4.10. RHEL 8 バージョンの PostgreSQL への移行
リンクのコピー

すでに RHEL 7 上で PostgreSQL を実行していて、データベースソフトウェアを RHEL 8 を実行するホストに移行したい場合は、データベースを移行できます。

Red Hat Enterprise Linux 上で PostgreSQL を使用しているユーザーは、データベースファイルの移行に 2 つの方法を選択できます。

  • pg_upgrade ユーティリティーを使用した高速アップグレード
  • ダンプおよび復元のアップグレード

高速アップグレードメソッドは、ダンプおよび復元のプロセスよりも速くなります。ただし、場合によっては高速アップグレードが機能せず、ダンプおよび復元プロセスしか使用できない場合があります。そのようなケースには、以下が含まれます。

  • アーキテクチャー間のアップグレード
  • plpython または plpython2 拡張を使用するシステム。RHEL 8 AppStream リポジトリーには postgresql-plpython3 パッケージのみが含まれ、postgresql-plpython2 パッケージは含まれません。
  • Red Hat Software Collections バージョンの PostgreSQL からの移行では、高速アップグレードはサポートされていません。

PostgreSQL の最新バージョンへの移行の前提条件として、すべての PostgreSQL データベースをバックアップしてください。

データベースをダンプし、SQL ファイルのバックアップを実行することは、ダンプおよび復元プロセスで必要であり、高速アップグレードメソッドとして推奨されます。

7.4.10.1. pg_upgrade ユーティリティーを使用した高速アップグレード
リンクのコピー

システム管理者であれば、高速アップグレード方式を使用して PostgreSQL の最新バージョンにアップグレードできます。高速アップグレードを実行するには、バイナリーデータファイルを /var/lib/pgsql/data/ ディレクトリーにコピーし、pg_upgrade ユーティリティーを使用します。

この方法を使用すると、データを移行できます。

  • RHEL 7 システム版の PostgreSQL 9.2 から RHEL 8 版の PostgreSQL 10 へ
  • RHEL 8 版の PostgreSQL 10 から RHEL 版の PostgreSQL 12 へ
  • RHEL 8 版の PostgreSQL 12 から RHEL 版の PostgreSQL 13 へ
  • RHEL 版 PostgreSQL 13 から RHEL 版 PostgreSQL 15 へ
  • RHEL 版 PostgreSQL 15 から RHEL 版 PostgreSQL 16 へ

RHEL 8 内の以前の PostgreSQL ストリームからアップグレードする場合は、より新しいストリームへの切り替え で説明されている手順に従ってから、PostgreSQL データを移行してください。

RHEL 内の他の PostgreSQL バージョンの組み合わせ間での移行、および Red Hat Software Collections バージョンの PostgreSQL から RHEL への移行には、ダンプとリストアのアップグレードを 使用します。

以下の手順では、高速アップグレード方式を使用して、RHEL 7 システムバージョンの PostgreSQL 9.2 から RHEL 8 バージョンの PostgreSQL に移行する方法について説明します。

前提条件

  • PostgreSQL データベースと設定ファイルのバックアップを作成しました。

手順

  1. RHEL 8 システムで、移行するストリーム (バージョン) を有効にします。 

    # yum module enable postgresql:stream

    ストリームを、選択したバージョンの PostgreSQL サーバーに置き換えてください。

    PostgreSQL 10 を提供するデフォルトのストリームを使用する場合は、この手順を省略できます。

  2. RHEL 8 システムで、postgresql-server パッケージおよび postgresql-upgrade パッケージをインストールします。 

    # yum install postgresql-server postgresql-upgrade

    オプションとして、RHEL 7 で PostgreSQL サーバーモジュールを使用していた場合は、RHEL 8 システムにも 2 つのバージョンでインストールしてください。PostgreSQL 9.2 用にコンパイルされたもの (postgresql-upgrade パッケージとしてインストール) と、PostgreSQL のターゲットバージョン用にコンパイルされたもの (postgresql-server パッケージとしてインストール) です。サードパーティー製の PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、postgresql-devel パッケージと postgresql-upgrade-devel パッケージの両方に対してビルドしてください。

  3. 以下の項目を確認します。

    • 基本設定 - RHEL 8 システムで、サーバーがデフォルトの /var/lib/pgsql/data ディレクトリーを使用し、データベースが正しく初期化され、有効になっているかどうかを確認します。さらに、データファイルは、/usr/lib/systemd/system/postgresql.service ファイルに記載されているパスと同じパスに保存する必要があります。
    • PostgreSQL サーバー: システム上で複数の PostgreSQL サーバーを実行できます。これらのすべてのサーバーのデータディレクトリーが独立して処理されていることを確認してください。
    • PostgreSQL サーバーモジュール:RHEL 7 で使用していた PostgreSQL サーバーモジュールが、RHEL 8 システムにもインストールされていることを確認してください。プラグインは /usr/lib64/pgsql/ ディレクトリー (32 ビットシステムの場合は /usr/lib/pgsql/ ディレクトリー) にインストールされることに注意してください。

  4. データのコピー時に、postgresql サービスがソースおよびターゲットのシステムで稼働していないことを確認します。 

    # systemctl stop postgresql.service
  5. データベースファイルをソースの場所から RHEL 8 システムの /var/lib/pgsql/data/ ディレクトリーにコピーします。

  6. PostgreSQL ユーザーとして以下のコマンドを実行して、アップグレードプロセスを実行してください。 

    # postgresql-setup --upgrade

    これでバックグラウンドで pg_upgrade プロセスが開始します。

    障害が発生すると、postgresql-setup は通知のエラーメッセージを提供します。

  7. /var/lib/pgsql/data-old から新規クラスターに、以前の設定をコピーします。

    高速アップグレードは、新しいデータスタックで以前の設定を再利用せず、設定がゼロから生成されることに注意してください。古い設定と新しい設定を手動で組み合わせたい場合は、データディレクトリーの *.conf ファイルを使用します。

  8. 新しい PostgreSQL サーバーを起動します。 

    # systemctl start postgresql.service

  9. 新しいデータベースクラスターを分析します。

    • PostgreSQL 13 以前のバージョンの場合: 

      su postgres -c '~/analyze_new_cluster.sh'

    • PostgreSQL 15 以降の場合: 

      su postgres -c 'vacuumdb --all --analyze-in-stages'
      注記

      場合によって、ALTER COLLATION name REFRESH VERSION を使用する必要があります。詳細は、アップストリームのドキュメント を参照してください。

  10. 新しい PostgreSQL サーバーを起動時に自動的に起動させたい場合は、以下を実行してください。 

    # systemctl enable postgresql.service
7.4.10.2. ダンプおよび復元のアップグレード
リンクのコピー

ダンプおよび復元のアップグレードを使用する場合は、すべてのデータベースのコンテンツを SQL ファイルのダンプファイルにダンプする必要があります。ダンプおよび復元のアップグレードは高速なアップグレード方法よりも低速であり、生成された SQL ファイルで手動修正が必要になる場合があります。

この方法を使用すると、以下からデータを移行できます。

  • Red Hat Enterprise Linux 7 システム版 PostgreSQL 9.2
  • Red Hat Enterprise Linux 8 の PostgreSQL の以前のバージョン

  • Red Hat Software Collections に含まれる、以前のバージョンまたは同等バージョンの PostgreSQL:

    • PostgreSQL 9.2(サポート終了)
    • PostgreSQL 9.4(サポート終了)
    • PostgreSQL 9.6(サポート終了)
    • PostgreSQL 10
    • PostgreSQL 12
    • PostgreSQL 13

RHEL 7 および RHEL 8 システムでは、PostgreSQL データはデフォルトで /var/lib/pgsql/data/ ディレクトリーに保存されます。Red Hat Software Collections バージョンの PostgreSQL の場合、デフォルトのデータディレクトリーは /var/opt/rh/collection_name/lib/pgsql/data/ です (ただし、postgresql92 は /opt/rh/postgresql92/root/var/lib/pgsql/data/ ディレクトリーを使用します)。

RHEL 8 内の以前の PostgreSQL ストリームからアップグレードする場合は、より新しいストリームへの切り替え で説明されている手順に従ってから、PostgreSQL データを移行してください。

ダンプおよび復元のアップグレードを実行するには、ユーザーを root に変更します。

以下の手順では、RHEL 7 システム版の PostgreSQL 9.2 から RHEL 8 版の PostgreSQL への移行について説明します。

手順

  1. RHEL 7 システム上で、PostgreSQL 9.2 サーバーを起動します。 

    # systemctl start postgresql.service

  2. RHEL 7 システムで、すべてのデータベースのコンテンツを pgdump_file.sql ファイルにダンプします。 

    su - postgres -c "pg_dumpall > ~/pgdump_file.sql"

  3. データベースが正しくダンプされたことを確認します。 

    su - postgres -c 'less "$HOME/pgdump_file.sql"'

    これにより、ダンプされた sql ファイルのパスが /var/lib/pgsql/pgdump_file.sql に表示されます。

  4. RHEL 8 システムで、移行するストリーム (バージョン) を有効にします。 

    # yum module enable postgresql:stream

    ストリームを、選択したバージョンの PostgreSQL サーバーに置き換えてください。

    PostgreSQL 10 を提供するデフォルトのストリームを使用する場合は、この手順を省略できます。

  5. RHEL 8 システムで、postgresql-server パッケージをインストールします。 

    # yum install postgresql-server

    必要に応じて、RHEL 7 で PostgreSQL サーバーモジュールを使用していた場合は、RHEL 8 システムにもそれらをインストールしてください。サードパーティー製の PostgreSQL サーバーモジュールをコンパイルする必要がある場合は、postgresql-devel パッケージに対してビルドしてください。

  6. RHEL 8 システム上で、新しい PostgreSQL サーバーのデータディレクトリーを初期化します。 

    # postgresql-setup --initdb

  7. RHEL 8 システムでは、pgdump_file.sql を PostgreSQL のホームディレクトリーにコピーし、ファイルが正しくコピーされたことを確認してください。 

    su - postgres -c 'test -e "$HOME/pgdump_file.sql" && echo exists'

  8. RHEL 7 システムから設定ファイルをコピーします。 

    su - postgres -c 'ls -1 $PGDATA/*.conf'

    コピーされる設定ファイルは、以下のとおりです。

    • /var/lib/pgsql/data/pg_hba.conf
    • /var/lib/pgsql/data/pg_ident.conf
    • /var/lib/pgsql/data/postgresql.conf

  9. RHEL 8 システム上で、新しい PostgreSQL サーバーを起動します。 

    # systemctl start postgresql.service

  10. RHEL 8 システムで、ダンプされた sql ファイルからデータをインポートします。 

    su - postgres -c 'psql -f ~/pgdump_file.sql postgres'
    注記

    Red Hat Software Collections バージョンの PostgreSQL からアップグレードする場合は、コマンドに scl enable collection_name を含めるように調整してください。たとえば、rh-postgresql96 Software Collection からデータをダンプする場合は、以下のコマンドを使用します。 

    su - postgres -c 'scl enable rh-postgresql96 "pg_dumpall > ~/pgdump_file.sql"'

postgresql RHEL システムロールを使用すると、PostgreSQL データベースサーバーのインストールと管理を自動化できます。デフォルトでは、このロールは、PostgreSQL サービス設定ファイルでパフォーマンス関連の設定を自動的に指定することで、PostgreSQL を最適化します。

7.4.11.1. postgresql RHEL システムロールを使用した、既存の TLS 証明書による PostgreSQL の設定
リンクのコピー

postgresql RHEL システムロールを使用すると、既存の証明書と秘密鍵を使用して安全なデータベース設定を自動化し、PostgreSQL を TLS 暗号化で設定できます。

注記

postgresql ロールは、firewalld サービスでポートを開くことができません。PostgreSQL サーバーへのリモートアクセスを許可するには、firewall RHEL システムロールを使用するタスクを Playbook に追加します。

前提条件

  • コントロールノードと管理対象ノードの準備が完了している。
  • 管理対象ノードへの接続に使用するアカウントに、そのノードに対する sudo 権限がある。

  • 管理対象ノードの秘密鍵と証明書が、コントロールノードの次のファイルに保存されている。

    • 秘密鍵: ~/<FQDN_of_the_managed_node>.key
    • 証明書: ~/<FQDN_of_the_managed_node>.crt

手順

  1. 機密性の高い変数を暗号化されたファイルに保存します。

    1. vault を作成します。 

      $ ansible-vault create ~/vault.yml
New Vault password: <vault_password>
Confirm New Vault password: <vault_password>

    2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。 

      pwd: <password>
    3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

  2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。 

    ---
- name: Installing and configuring PostgreSQL
  hosts: managed-node-01.example.com
  vars_files:
    - ~/vault.yml
  tasks:
    - name: Create directory for TLS certificate and key
      ansible.builtin.file:
        path: /etc/postgresql/
        state: directory
        mode: 755

    - name: Copy CA certificate
      ansible.builtin.copy:
        src: "~/{{ inventory_hostname }}.crt"
        dest: "/etc/postgresql/server.crt"

    - name: Copy private key
      ansible.builtin.copy:
        src: "~/{{ inventory_hostname }}.key"
        dest: "/etc/postgresql/server.key"
        mode: 0600

    - name: PostgreSQL with an existing private key and certificate
      ansible.builtin.include_role:
        name: redhat.rhel_system_roles.postgresql
      vars:
        postgresql_version: "16"
        postgresql_password: "{{ pwd }}"
        postgresql_ssl_enable: true
        postgresql_cert_name: "/etc/postgresql/server"
        postgresql_server_conf:
          listen_addresses: "'*'"
          password_encryption: scram-sha-256
        postgresql_pg_hba_conf:
          - type: local
            database: all
            user: all
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '127.0.0.1/32'
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '::1/128'
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '192.0.2.0/24'
            auth_method: scram-sha-256


    - name: Open the PostgresQL port in firewalld
      ansible.builtin.include_role:
        name: redhat.rhel_system_roles.firewall
      vars:
        firewall:
          - service: postgresql
            state: enabled

    サンプル Playbook で指定されている設定は次のとおりです。

    postgresql_version: <version>

    インストールする PostgreSQL のバージョンを設定します。設定できるバージョンは、管理対象ノードで実行されている Red Hat Enterprise Linux で使用可能な PostgreSQL バージョンによって異なります。

    postgresql_version 変数を変更して Playbook を再度実行しても、PostgreSQL をアップグレードまたはダウングレードすることはできません。

    postgresql_password: <password>

    postgres データベーススーパーユーザーのパスワードを設定します。

    postgresql_password 変数を変更して Playbook を再度実行しても、パスワードを変更することはできません。

    postgresql_cert_name: <private_key_and_certificate_file>

    管理対象ノード上の証明書と秘密鍵の両方のパスとベース名を、.crt および key 接尾辞なしで定義します。PostgreSQL の設定中に、ロールが /var/lib/pgsql/data/ ディレクトリーにこれらのファイルを参照するシンボリックリンクを作成します。

    証明書と秘密鍵は管理対象ノード上にローカルに存在している必要があります。Playbook に示されているように、ansible.builtin.copy モジュールのタスクを使用して、コントロールノードから管理対象ノードにファイルを転送できます。

    postgresql_server_conf: <list_of_settings>

    ロールが設定する必要がある postgresql.conf 設定を定義します。ロールはこれらの設定を /etc/postgresql/system-roles.conf ファイルに追加し、このファイルを /var/lib/pgsql/data/postgresql.conf の最後に含めます。その結果、postgresql_server_conf 変数の設定により、/var/lib/pgsql/data/postgresql.conf 内の設定がオーバーライドされます。

    postgresql_server_conf で異なる設定を使用して Playbook を再実行すると、/etc/postgresql/system-roles.conf ファイルが新しい設定で上書きされます。

    postgresql_pg_hba_conf: <list_of_authentication_entries>

    /var/lib/pgsql/data/pg_hba.conf ファイル内のクライアント認証エントリーを設定します。詳細は、PostgreSQL のドキュメントを参照してください。

    この例では、PostgreSQL への次の接続を許可します。

    • ローカル UNIX ドメインソケットを使用した暗号化されていない接続。
    • IPv4 および IPv6 ローカルホストアドレスへの TLS 暗号化接続。
    • 192.0.2.0/24 サブネットからの TLS 暗号化接続。リモートアドレスからのアクセスは、postgresql_server_conf 変数の listen_addresses 設定も適切に設定した場合にのみ可能であることに注意してください。

    postgresql_pg_hba_conf で異なる設定を使用して Playbook を再実行すると、/var/lib/pgsql/data/pg_hba.conf ファイルが新しい設定で上書きされます。

    Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.postgresql/README.md ファイルを参照してください。

  3. Playbook の構文を検証します。 

    $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  4. Playbook を実行します。 

    $ ansible-playbook --ask-vault-pass ~/playbook.yml

検証

  • postgres スーパーユーザーを使用して PostgreSQL サーバーに接続し、\conninfo メタコマンドを実行します。 

    # psql "postgresql://postgres@managed-node-01.example.com:5432" -c '\conninfo'
Password for user postgres:
You are connected to database "postgres" as user "postgres" on host "192.0.2.1" at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)

    出力に TLS プロトコルのバージョンと暗号の詳細が表示される場合、接続は機能し、TLS 暗号化が有効になっています。

Red Hat Enterprise Linux の Identity Management (IdM) から発行され、certmonger サービスによって管理される証明書を使用して、安全なデータベース設定を自動化するために、postgresql RHEL システムロールを使用して PostgreSQL を TLS 暗号化で設定できます。

注記

postgresql ロールは、firewalld サービスでポートを開くことができません。PostgreSQL サーバーへのリモートアクセスを許可するには、firewall RHEL システムロールを使用するタスクを Playbook に追加します。

前提条件

手順

  1. 機密性の高い変数を暗号化されたファイルに保存します。

    1. vault を作成します。 

      $ ansible-vault create ~/vault.yml
New Vault password: <vault_password>
Confirm New Vault password: <vault_password>

    2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。 

      pwd: <password>
    3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

  2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。 

    ---
- name: Installing and configuring PostgreSQL
  hosts: managed-node-01.example.com
  vars_files:
    - ~/vault.yml
  tasks:
    - name: PostgreSQL with certificates issued by IdM
      ansible.builtin.include_role:
        name: redhat.rhel_system_roles.postgresql
      vars:
        postgresql_version: "16"
        postgresql_password: "{{ pwd }}"
        postgresql_ssl_enable: true
        postgresql_certificates:
          - name: postgresql_cert
            dns: "{{ inventory_hostname }}"
            ca: ipa
            principal: "postgresql/{{ inventory_hostname }}@EXAMPLE.COM"
        postgresql_server_conf:
          listen_addresses: "'*'"
          password_encryption: scram-sha-256
        postgresql_pg_hba_conf:
          - type: local
            database: all
            user: all
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '127.0.0.1/32'
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '::1/128'
            auth_method: scram-sha-256
          - type: hostssl
            database: all
            user: all
            address: '192.0.2.0/24'
            auth_method: scram-sha-256


    - name: Open the PostgresQL port in firewalld
      ansible.builtin.include_role:
        name: redhat.rhel_system_roles.firewall
      vars:
        firewall:
          - service: postgresql
            state: enabled

    サンプル Playbook で指定されている設定は次のとおりです。

    postgresql_version: <version>

    インストールする PostgreSQL のバージョンを設定します。設定できるバージョンは、管理対象ノードで実行されている Red Hat Enterprise Linux で使用可能な PostgreSQL バージョンによって異なります。

    postgresql_version 変数を変更して Playbook を再度実行しても、PostgreSQL をアップグレードまたはダウングレードすることはできません。

    postgresql_password: <password>

    postgres データベーススーパーユーザーのパスワードを設定します。

    postgresql_password 変数を変更して Playbook を再度実行しても、パスワードを変更することはできません。

    postgresql_certificates: <certificate_role_settings>
    certificate ロールの設定を含む YAML ディクショナリーのリスト。
    postgresql_server_conf: <list_of_settings>

    ロールが設定する必要がある postgresql.conf 設定を定義します。ロールはこれらの設定を /etc/postgresql/system-roles.conf ファイルに追加し、このファイルを /var/lib/pgsql/data/postgresql.conf の最後に含めます。その結果、postgresql_server_conf 変数の設定により、/var/lib/pgsql/data/postgresql.conf 内の設定がオーバーライドされます。

    postgresql_server_conf で異なる設定を使用して Playbook を再実行すると、/etc/postgresql/system-roles.conf ファイルが新しい設定で上書きされます。

    postgresql_pg_hba_conf: <list_of_authentication_entries>

    /var/lib/pgsql/data/pg_hba.conf ファイル内のクライアント認証エントリーを設定します。詳細は、PostgreSQL のドキュメントを参照してください。

    この例では、PostgreSQL への次の接続を許可します。

    • ローカル UNIX ドメインソケットを使用した暗号化されていない接続。
    • IPv4 および IPv6 ローカルホストアドレスへの TLS 暗号化接続。
    • 192.0.2.0/24 サブネットからの TLS 暗号化接続。リモートアドレスからのアクセスは、postgresql_server_conf 変数の listen_addresses 設定も適切に設定した場合にのみ可能であることに注意してください。

    postgresql_pg_hba_conf で異なる設定を使用して Playbook を再実行すると、/var/lib/pgsql/data/pg_hba.conf ファイルが新しい設定で上書きされます。

    Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.postgresql/README.md ファイルを参照してください。

  3. Playbook の構文を検証します。 

    $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

    このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

  4. Playbook を実行します。 

    $ ansible-playbook --ask-vault-pass ~/playbook.yml

検証

  • postgres スーパーユーザーを使用して PostgreSQL サーバーに接続し、\conninfo メタコマンドを実行します。 

    # psql "postgresql://postgres@managed-node-01.example.com:5432" -c '\conninfo'
Password for user postgres:
You are connected to database "postgres" as user "postgres" on host "192.0.2.1" at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)

    出力に TLS プロトコルのバージョンと暗号の詳細が表示される場合、接続は機能し、TLS 暗号化が有効になっています。

第8章 Postfix SMTP サーバーのデプロイと設定
リンクのコピー

Postfix メール転送エージェント (MTA) を使用して、SMTP プロトコルを用いてホスト間でメールメッセージを転送することで、メールインフラストラクチャーを設定できます。Postfix は、メールのルーティングと配信を行うサーバー側アプリケーションです。

Postfix を使用して、ローカルメールサーバーの設定、null クライアントメールリレーの作成、複数のドメインの宛先としての Postfix サーバーの使用、検索用ファイルに代わる LDAP ディレクトリーの選択を行うことができます。

postfix パッケージは、/etc/postfix/ ディレクトリーに複数の設定ファイルを提供します。

メールインフラストラクチャーを設定するには、次の設定ファイルを使用します。

  • main.cf - Postfix のグローバル設定が含まれています。
  • master.cf - メール配信を実現するために、Postfix とさまざまなプロセスの相互作用を指定します。
  • access - Postfix への接続が許可されるホストなどのアクセスルールを指定します。
  • transport - メールアドレスをリレーホストにマップします。
  • エイリアス - ユーザー ID エイリアスを記述するメールプロトコルに必要な設定可能なリストが含まれています。このファイルは、/etc/ ディレクトリーにあることに留意してください。

Postfix の主な機能:

  • 一般的なメール関連の脅威から保護するためのセキュリティー機能
  • 仮想ドメインおよびエイリアスのサポートを含むカスタマイズオプション

8.1. Postfix SMTP サーバーのインストールおよび設定
リンクのコピー

メールメッセージを受信、保存、配信するように Postfix SMTP サーバーを設定できます。システムインストール時にメールサーバーパッケージを選択しない場合、Postfix はデフォルトでは利用できません。

前提条件

手順

  1. Sendmail ユーティリティーを削除します。 

    # yum remove sendmail

  2. Postfix をインストールします。 

    # yum install postfix

  3. Postfix を設定するには、/etc/postfix/main.cf ファイルを編集し、以下の変更を加えます。

    1. デフォルトでは、Postfix は loopback インターフェイスでのみメールを受信します。特定のインターフェイスをリッスンするように Postfix を設定するには、inet_interfaces パラメーターをこれらのインターフェイスの IP アドレスに更新します。 

      inet_interfaces = 127.0.0.1/32, [::1]/128, 192.0.2.1, [2001:db8:1::1]

      すべてのインターフェイスをリッスンするように Postfix を設定するには、以下を設定します。 

      inet_interfaces = all

    2. gethostname() 関数によって返される完全修飾ドメイン名 (FQDN) とは異なるホスト名を Postfix が使用するようにしたい場合は、myhostname パラメーターを追加します。 

      myhostname = smtp.example.com

      たとえば、Postfix は処理するメールのヘッダーにこのホスト名を追加します。

    3. ドメイン名が myhostname パラメーターのものと異なる場合は、mydomain パラメーターを追加します。 

      mydomain = example.com

    4. myorigin パラメーターを追加し、mydomain の値に設定します。 

      myorigin = $mydomain

      この設定では、Postfix はホスト名ではなく、ローカルで投稿されたメールの発信元としてドメイン名を使用します。

    5. mynetworks パラメーターを追加し、メールの送信が許可される信頼できるネットワークの IP 範囲を定義します。 

      mynetworks = 127.0.0.1/32, [::1]/128, 192.0.2.1/24, [2001:db8:1::1]/64

      インターネットなどの信頼できないネットワークからのクライアントがこのサーバー経由でメールを送信できるようにするには、後の手順でリレー制限を設定する必要があります。

  4. main.cf ファイルの Postfix 設定が正しいか確認します。 

    # postfix check

  5. postfix サービスが起動時に開始できるように有効化し、開始します。 

    # systemctl enable --now postfix

  6. smtp トラフィックがファイアウォールを通過することを許可し、ファイアウォールルールをリロードします。 

    # firewall-cmd --permanent --add-service smtp
# firewall-cmd --reload

検証

  1. postfix サービスが実行していることを確認します。 

    # systemctl status postfix

    • オプション: 出力が停止し、待機中、またはサービスが実行されていない場合は、postfix サービスを再起動します。 

      # systemctl restart postfix

    • オプション: /etc/postfix/ ディレクトリーの設定ファイル内のオプションを変更した後、postfix サービスをリロードして、これらの変更を適用します。 

      # systemctl reload postfix

  2. システム上のローカルユーザー間のメール通信を確認します。 

    # echo "This is a test message" | mail -s <subject> <user@mydomain.com>

  3. メールサーバーが外部 IP 範囲からのメールを外部ドメインに中継していないことを確認するには、以下の手順に従います。

    1. mynetworks で定義したサブネット内にないクライアントにログインします。
    2. メールサーバーを使用するようにクライアントを設定します。
    3. メールサーバーの mydomain で指定したドメイン以外のメールアドレスにメールを送信してみます。たとえば、non-existing-user@redhat.com にメールを送信してみます。

    4. /var/log/maillog ファイルを確認します。 

      554 Relay access denied - the server is not going to relay.
250 OK or similar - the server is going to relay.

トラブルシューティング

  • エラーが発生した場合は、/var/log/maillog を確認してください。

8.2. Postfix サーバーの TLS 設定のカスタマイズ
リンクのコピー

Transport Layer Security (TLS) を使用すると、メールの通信を暗号化してセキュリティーを強化できます。たとえば、TLS 設定をカスタマイズして、自己署名証明書の代わりに信頼できる信頼済み証明書局 (CA) の証明書を使用することができます。

RHEL 8 では、TLS 暗号化プロトコルが Postfix サーバーでデフォルトで有効になっています。基本的な Postfix TLS 設定には、受信 SMTP 用の自己署名証明書と、発信 SMTP の日和見 TLS が含まれています。

前提条件

  • サーバーに postfix パッケージがインストールされている。
  • 信頼できる認証局 (CA) によって署名された証明書と秘密鍵を持っている。

  • 以下のファイルを Postfix サーバーにコピーしている。

    • サーバー証明書: /etc/pki/tls/certs/postfix.pem
    • 秘密鍵y: /etc/pki/tls/private/postfix.key

手順

  1. 以下の行を /etc/postfix/main.cf ファイルに追加して、Postfix が実行されているサーバー上の証明書と秘密鍵ファイルへのパスを設定します。 

    smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key

  2. /etc/postfix/main.cf ファイルを編集して、受信した SMTP 接続を認証されたユーザーのみに制限します。 

    smtpd_tls_auth_only = yes

  3. postfix サービスをリロードして変更を適用します。 

    # systemctl reload postfix

検証

  • TLS 暗号化を使用してメールを送信するようにクライアントを設定します。

    注記

    Postfix クライアント TLS アクティビティーに関する追加情報を取得するには、/etc/postfix/main.cf の次の行を変更して、ログレベルを 0 から 1 に増やします。 

    smtp_tls_loglevel = 1

8.3. すべての電子メールをメールリレーに転送するように Postfix を設定する
リンクのコピー

すべての電子メールをメールリレーに転送する場合は、Postfix サーバーを Null クライアントとして設定できます。この設定では、Postfix はメールを別のメールサーバーに転送するだけで、メールの受信はできません。

前提条件

  • サーバーに postfix パッケージがインストールされている。
  • メールを転送するリレーホストの IP アドレスまたはホスト名がある。

手順

  1. Postfix がローカルの電子メール配信を受け入れ、それが Null クライアントになるのを防ぐには、/etc/postfix/main.cf ファイルを編集し、以下の変更を加えます。

    1. mydestination パラメーターを空の値に等しくなるように設定して、すべてのメールを転送するように Postfix を設定します。 

      mydestination =

      この設定では、Postfix サーバーはメールの宛先ではなく、null クライアントとして機能します。

    2. Null クライアントからメールを受信するメールリレーサーバーを指定します。 

      relayhost = [<ip_address_or_hostname>]

      リレーホストはメール配信を行います。<ip_address_or_hostname> を角括弧で囲みます。

    3. メールを配信するために、ループバックインターフェイスでのみリッスンするように Postfix メールサーバーを設定します。 

      inet_interfaces = loopback-only

    4. Postfix がすべての送信メールの送信者ドメインをリレーメールサーバーの企業ドメインに書き換えるには、以下を設定します。 

      myorigin = relay.example.com

    5. ローカルメール配信を無効にするには、設定ファイルの最後に次のディレクティブを追加します。 

      local_transport = error: local delivery disabled

    6. mynetworks パラメーターを追加して、Postfix が 127.0.0.0/8 IPv4 ネットワークと [::1]/128 IPv6 ネットワークから送信されたローカルシステムからの電子メールをメールリレーサーバーに転送するようにします。 

      mynetworks = 127.0.0.0/8, [::1]/128

  2. main.cf ファイルの Postfix 設定が正しいか確認します。 

    # postfix check

  3. postfix サービスを再起動して変更を適用します。 

    # systemctl restart postfix

検証

  • 電子メール通信がメールリレーに転送されていることを確認します。 

    # echo "This is a test message" | mail -s <subject> <user@example.com>

トラブルシューティング

  • エラーが発生した場合は、/var/log/maillog を確認してください。

8.4. Postfix を複数のドメインの宛先として設定する
リンクのコピー

Postfix を、複数のドメインのメールを受信できるメールサーバーとして設定できます。この設定では、Postfix は、指定されたドメイン内のアドレスに送信された電子メールの最終宛先として機能します。

次のような環境を構成できます。

  • 同じ電子メール宛先を指す複数の電子メールアドレスを設定する。
  • 複数のドメインの受信メールを同じ Postfix サーバーにルーティングする。

前提条件

  • Postfix サーバーを設定している。

手順

  1. /etc/postfix/virtual 仮想エイリアスファイルで、各ドメインのメールアドレスを指定します。各電子メールアドレスを新しい行に追加します。 

    <info@example.com>   <user22@example.net>
<sales@example.com>  <user11@example.org>

    この例では、Postfix は info@example.com に送信されたすべての電子メールを user22@example.net にリダイレクトし、sales@example.com に送信された電子メールを user11@example.org にリダイレクトします。

  2. 仮想エイリアスマップのハッシュファイルを作成します。 

    # postmap /etc/postfix/virtual

    このコマンドは、/etc/postfix/virtual.db ファイルを作成します。/etc/postfix/virtual ファイルを更新した後に、このコマンドを常に再実行する必要があります。

  3. Postfix /etc/postfix/main.cf 設定ファイルで、virtual_alias_maps パラメーターを追加して、ハッシュファイルを指すようにします。 

    virtual_alias_maps = hash:/etc/postfix/virtual

  4. postfix サービスをリロードして変更を適用します。 

    # systemctl reload postfix

検証

  • 仮想メールアドレスの 1 つに電子メールを送信して、設定をテストします。

トラブルシューティング

  • エラーが発生した場合は、/var/log/maillog を確認してください。

8.5. LDAP ディレクトリーの検索テーブルとしての使用
リンクのコピー

Lightweight Directory Access Protocol (LDAP) サーバーを使用してアカウント、ドメイン、またはエイリアスを保存する場合は、LDAP サーバーを検索テーブルとして使用するように Postfix を設定できます。検索用ファイルの代わりに LDAP を使用すると、中央データベースを使用できます。

前提条件

  • サーバーに postfix パッケージがインストールされている。
  • 必要なスキーマおよびユーザークレデンシャルを持つ LDAP サーバーがある。
  • Postfix を実行しているサーバーに postfix-ldap プラグインがインストールされている。

手順

  1. 以下の内容で /etc/postfix/ldap-aliases.cf ファイルを作成して、LDAP 検索パラメーターを設定します。

    1. LDAP サーバーのホスト名を指定します。 

      server_host = ldap.example.com

    2. LDAP 検索のベースドメイン名を指定します。 

      search_base = dc=example,dc=com
    3. オプション: 要件に応じて LDAP 検索フィルターと属性をカスタマイズします。ディレクトリーを検索するフィルターのデフォルトは query_filter = mailacceptinggeneralid=%s です。

  2. 以下の内容を追加して、LDAP ソースを /etc/postfix/main.cf 設定ファイルの検索テーブルとして有効にします。 

    virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf

    詳細は、/usr/share/doc/postfix/README_FILES/LDAP_README および /usr/share/doc/postfix/README_FILES/DATABASE_README ファイルを参照してください。

  3. postmap コマンドを実行して LDAP 設定を確認します。これは、構文エラーまたは接続の問題をチェックします。 

    # postmap -q @example.com ldap:/etc/postfix/ldap-aliases.cf

  4. postfix サービスをリロードして変更を適用します。 

    # systemctl reload postfix

検証

  • テストメールを送信して、LDAP 検索が正しく機能していることを確認します。/var/log/maillog のメールログでエラーがないか確認します。

8.6. 認証されたユーザーのリレーを行う送信メールサーバーとしての Postfix の設定
リンクのコピー

認証されたユーザーのメールをリレーするように Postfix を設定できます。このシナリオでは、Postfix を送信メールサーバーとして設定することで、ユーザーが認証を行い、自分のメールアドレスを使用して SMTP サーバー経由でメールを送信できるようにします。

前提条件

  • Postfix サーバーを設定している。

手順

  1. Postfix を送信メールサーバーとして設定するには、/etc/postfix/main.cf ファイルを編集し、以下を追加します。

    1. SMTP 認証を有効にします。 

      smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes

    2. TLS を使用しないアクセスを無効にします。 

      smtpd_tls_auth_only = yes

    3. 認証されたユーザーに対してのみメールリレーを許可します。 

      smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

    4. オプション: ユーザーが自分の電子メールアドレスを送信者としてのみ使用するように制限します。 

      smtpd_sender_restrictions = reject_sender_login_mismatch

  2. postfix サービスをリロードして変更を適用します。 

    # systemctl reload postfix

検証

  • TLS および SASL をサポートする SMTP クライアントで認証します。SMTP 認証が正しく機能することを確認するために、テストメールを送信してください。

8.7. 同じホストで実行している Postfix から Dovecot への電子メールの配信
リンクのコピー

UNIX ソケット経由で LMTP を使用して、受信メールを同じホスト上の Dovecot に配信するように Postfix を設定できます。このソケットは、ローカルマシンの Postfix と Dovecot との間の直接通信を有効にします。

前提条件

手順

  1. /etc/postfix/main.cf ファイルの Dovecot にメールを配信するために LMTP プロトコルと UNIX ドメインソケットを使用するように Postfix を設定します。

    • 仮想メールボックスを使用する場合は、次のコンテンツを追加します。 

      virtual_transport = lmtp:unix:/var/run/dovecot/lmtp

    • 仮想以外のメールボックスを使用する場合は、次のコンテンツを追加します。 

      mailbox_transport = lmtp:unix:/var/run/dovecot/lmtp

  2. postfix をリロードして変更を適用します。 

    # systemctl reload postfix

検証

  • LMTP ソケットが正しく動作することを確認するために、テストメールを送信してください。/var/log/maillog のメールログでエラーがないか確認します。

8.8. Postfix から別のホストで実行されている Dovecot への電子メールの配信
リンクのコピー

ネットワーク経由で Postfix メールサーバーと Dovecot 配信エージェントの間にセキュアな接続を確立できます。そのためには、LMTP サービスを設定して、メールサーバー間でメールを配信するためにネットワークソケットを使用するようにします。

デフォルトでは、LMTP プロトコルは暗号化されていません。ただし、TLS 暗号化を設定した場合、Dovecot は LMTP サービスに同じ設定を自動的に使用します。続いて、SMTP サーバーは、LMTP 経由で STARTTLS コマンドを使用してそれに接続できます。

前提条件

手順

  1. 以下の内容を追加して、/etc/postfix/main.cf ファイルで Dovecot にメールを配信するために LMTP プロトコルと INET ドメインソケットを使用するように Postfix を設定します。 

    mailbox_transport = lmtp:inet:<dovecot_host>:<port>

    <dovecot_host> を Dovecot サーバーの IP アドレスまたはホスト名に置き換え、<port> を LMTP サービスのポート番号に置き換えます。

  2. postfix サービスをリロードして変更を適用します。 

    # systemctl reload postfix

検証

  • リモートの Dovecot サーバーがホストするアドレスにテストメールを送信し、Dovecot のログを確認してメールが正常に配信されたことを確認してください。

8.9. Postfix サービスを保護する
リンクのコピー

暗号化を使用するように設定し、さまざまな攻撃によるリスクを軽減する設定を適用することで、Postfix メール転送エージェントを保護します。これには、SASL を使用して SMTP 認証 (AUTH) を設定し、サービス拒否 (DoS) 攻撃に対する脆弱性を軽減するための制限を設定することが含まれます。

Postfix は、SMTP (Simple Mail Transfer Protocol) を使用して他の MTA 間で電子メッセージを配信したり、クライアントや配信エージェントに電子メールを送信したりするメール転送エージェント (MTA) です。MTA は相互間のトラフィックを暗号化できますが、デフォルトではそうしない場合があります。

8.9.2. DoS 攻撃を制限するための Postfix 設定オプション
リンクのコピー

特定の Postfix オプションを設定することで、サービス拒否 (DoS) 攻撃を制限できます。これには、大量のトラフィックからサーバーを保護するために、レート制限とメッセージサイズ制限を厳格に設定することが含まれます。

攻撃者は、サーバーに大量のトラフィックを送り込んだり、クラッシュを引き起こすような情報を送信したりすることで、サービス拒否 (DoS) 攻撃を引き起こすことができる。/etc/postfix/main.cf ファイルで制限を設定することにより、このような攻撃のリスクを軽減するようにシステムを設定できます。既存のディレクティブの値を変更することも、<directive> = <value> という形式のカスタム値を使用して新しいディレクティブを追加することもできます。

DoS 攻撃を制限するには、次のディレクティブのリストを使用します。

smtpd_client_connection_rate_limit
クライアントがこのサービスに対して時間単位あたりに実行できる接続試行の最大数を制限します。デフォルト値は 0 です。これは、クライアントが時間単位で Postfix が受け入れることができる数と同じ数の接続を行うことができることを意味します。デフォルトでは、ディレクティブは信頼できるネットワークのクライアントを除外します。
anvil_rate_time_unit
レート制限を計算するための時間単位を定義します。デフォルト値は 60 秒です。
smtpd_client_event_limit_exceptions
接続およびレート制限コマンドからクライアントを除外します。デフォルトでは、ディレクティブは信頼できるネットワークのクライアントを除外します。
smtpd_client_message_rate_limit
時間単位あたりのクライアントからの要求に対するメッセージ配信の最大数を定義します (Postfix が実際にそれらのメッセージを受け入れるかどうかは関係ありません)。
default_process_limit
特定のサービスを提供する Postfix 子プロセスのデフォルトの最大数を定義します。master.cf ファイル内の特定のサービスでは、このルールを無視できます。デフォルトでは、値は 100 です。
queue_minfree
キューファイルシステムでメールを受信するために必要な最小の空き容量を定義します。このディレクティブは現在、Postfix SMTP サーバーがメールを受け入れるかどうかを決定するために使用されています。デフォルトでは、Postfix SMTP サーバーは、空き容量が message_size_limit の 1.5 倍未満の場合に、MAIL FROM コマンドを拒否します。空き容量の最小値をこれよりも高く指定するには、message_size_limit の 1.5 倍以上の queue_minfree 値を指定します。デフォルトの queue_minfree 値は 0 です。
header_size_limit
メッセージヘッダーを格納するためのメモリーの最大量をバイト単位で定義します。ヘッダーが大きい場合、余分なヘッダーは破棄されます。デフォルトでは、値は 102400 バイトです。
message_size_limit
エンベロープ情報を含むメッセージの最大サイズをバイト単位で定義します。デフォルトでは、値は 10240000 バイトです。

8.9.3. Postfix が SASL を使用する設定
リンクのコピー

Postfix メール転送エージェントを、Simple Authentication and Security Layer (SASL) を使用するように設定できます。これにより、電子メッセージの送受信時の認証が強化されます。

Postfix は SASL ベースの SMTP 認証 (AUTH) をサポートしています。SMTP AUTH は Simple Mail Transfer Protocol の拡張です。現在、Postfix SMTP サーバーは次の方法で SASL 実装をサポートしています:

Dovecot SASL
Postfix SMTP サーバーは、UNIX ドメインソケットまたは TCP ソケットのいずれかを使用して、Dovecot SASL 実装と通信できます。Postfix と Dovecot アプリケーションが別のマシンで実行している場合は、この方法を使用します。
Cyrus SASL
有効にすると、SMTP クライアントは、サーバーとクライアントの両方でサポートおよび受け入れられる認証方法を使用して、SMTP サーバーで認証する必要があります。

前提条件

  • dovecot パッケージがシステムにインストールされている

手順

  1. Dovecot をセットアップします。

    1. /etc/dovecot/conf.d/10-master.conf ファイルに次の行を含めます。 

      service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

      前の例では、Postfix と Dovecot の間の通信に UNIX ドメインソケットを使用しています。また、/var/spool/postfix/ ディレクトリーにあるメールキュー、および postfix ユーザーとグループの下で実行しているアプリケーションを含む Postfix SMTP サーバーのデフォルト設定を想定しています。

    2. オプション: TCP 経由で Postfix 認証リクエストをリッスンするように Dovecot をセットアップします。 

      service auth {
  inet_listener {
      port = <port-number>
  }
}

    3. /etc/dovecot/conf.d/10-auth.conf ファイルの auth_mechanisms パラメーターを編集して、電子メールクライアントが Dovecot での認証に使用する方法を指定します。 

      auth_mechanisms = plain login

      auth_mechanisms パラメーターは、さまざまなプレーンテキストおよび非プレーンテキストの認証方法をサポートしています。

  2. /etc/postfix/main.cf ファイルを変更して Postfix をセットアップします。

    1. Postfix SMTP サーバーで SMTP 認証を有効にします。 

      smtpd_sasl_auth_enable = yes

    2. SMTP 認証用の Dovecot SASL 実装の使用を有効にします。 

      smtpd_sasl_type = dovecot

    3. Postfix キューディレクトリーに相対的な認証パスを指定します。相対パスを使用すると、Postfix サーバーが chroot で実行しているかどうかに関係なく、設定が確実に機能することに注意してください。 

      smtpd_sasl_path = private/auth

      この手順では、Postfix と Dovecot の間の通信に UNIX ドメインソケットを使用します。

      通信に TCP ソケットを使用する場合に、別のマシンで Dovecot を探すように Postfix を設定するには、次のような設定値を使用します。 

      smtpd_sasl_path = inet: <IP_address> : <port_number>

      前の例で、ip-address を Dovecot マシンの IP アドレスに置き換え、port-number を Dovecot の /etc/dovecot/conf.d/10-master.conf ファイルで指定されたポート番号に置き換えます。

    4. Postfix SMTP サーバーがクライアントに提供する SASL メカニズムを指定します。暗号化されたセッションと暗号化されていないセッションに異なるメカニズムを指定できることに注意してください。 

      smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

      前のディレクティブは、暗号化されていないセッションでは匿名認証が許可されず、暗号化されていないユーザー名またはパスワードを送信するメカニズムが許可されていないことを指定しています。暗号化セッション (TLS を使用) の場合、非匿名認証メカニズムのみが許可されます。

第9章 Dovecot IMAP および POP3 サーバーの設定と管理
リンクのコピー

Dovecot は、セキュリティーを重視する高パフォーマンスのメール配信エージェント (MDA) です。IMAP または POP3 互換の電子メールクライアントを使用して Dovecot サーバーに接続し、電子メールを読んだりダウンロードしたりできます。

Dovecot の主な機能:

  • セキュリティーを重視する設計と実装
  • 大規模環境でのパフォーマンスを向上させるために、高可用性を実現する双方向レプリケーションをサポート
  • 高パフォーマンスの dbox メールボックス形式だけでなく、互換性の理由から mbox と Maildir もサポート
  • 破損したインデックスファイルの修正などの自己修復機能
  • IMAP 標準への準拠
  • IMAP および POP3 クライアントのバグを回避するための回避策をサポート

9.1. PAM を使用した Dovecot サーバーの設定 PAM 認証を使用した Dovecot サーバーの設定
リンクのコピー

Dovecot は、ユーザーデータベースとして Name Service Switch (NSS) インターフェイスをサポートし、認証バックエンドとして Pluggable Authentication Module (PAM) フレームワークをサポートします。この設定により、Dovecot は、NSS を介してサーバー上でローカルに利用可能なユーザーにサービスを提供できます。

アカウントが次の場合に PAM 認証を使用します。

  • /etc/passwd ファイルでローカルに定義されている。
  • リモートデータベースに保存されているが、System Security Services Daemon (SSSD) またはその他の NSS プラグインを介してローカルで利用できる。

9.1.1. Dovecot のインストール
リンクのコピー

Dovecot をインストールすることは、IMAP または POP3 サーバーをセットアップする最初のステップです。

dovecot パッケージは以下を提供します。

  • dovecot サービスとそれを管理するユーティリティー
  • Dovecot がオンデマンドで開始するサービス (認証など)
  • サーバーサイドメールフィルタリングなどのプラグイン
  • /etc/dovecot/ ディレクトリーの設定ファイル
  • /usr/share/doc/dovecot/ ディレクトリーのドキュメント

手順

  • dovecot パッケージをインストールします。 

    # yum install dovecot
    注記

    Dovecot がすでにインストールされていて、クリーンな設定ファイルが必要な場合は、/etc/dovecot/ ディレクトリーを名前変更するか削除してください。その後、パッケージを再インストールします。設定ファイルを削除しないと、yum uninstall dovecot コマンドは /etc/dovecot/ 内の設定ファイルをリセットしません。

9.1.2. Dovecot サーバーでの TLS 暗号化の設定
リンクのコピー

Dovecot はセキュアなデフォルト設定を提供します。たとえば、TLS はデフォルトで有効になっており、認証情報と暗号化されたデータをネットワーク経由で送信します。Dovecot サーバーで TLS を設定するには、証明書と秘密鍵ファイルへのパスを設定するだけです。

Diffie-Hellman パラメーターを生成および使用して完全前方秘匿性 (PFS) を提供することにより、TLS 接続のセキュリティーを向上させる。

前提条件

  • Dovecot がインストールされています。

  • 次のファイルが、サーバー上のリストされた場所にコピーされました。

    • サーバー証明書: /etc/pki/dovecot/certs/server.example.com.crt
    • 秘密鍵: /etc/pki/dovecot/private/server.example.com.key
    • 認証局 (CA) 証明書: /etc/pki/dovecot/certs/ca.crt
  • サーバー証明書の Subject DN フィールドのホスト名は、サーバーの完全修飾ドメイン名 (FQDN) と一致します。

手順

  1. 秘密鍵ファイルにセキュアな権限を設定します。 

    # chown root:root /etc/pki/dovecot/private/server.example.com.key
# chmod 600 /etc/pki/dovecot/private/server.example.com.key

  2. Diffie-Hellman パラメーターを使用してファイルを生成します。 

    # openssl dhparam -out /etc/dovecot/dh.pem 4096

    サーバーのハードウェアとエントロピーによっては、4096 ビットの Diffie-Hellman パラメーターを生成するのに数分かかる場合があります。

  3. /etc/dovecot/conf.d/10-ssl.conf ファイルで証明書と秘密鍵ファイルへのパスを設定します。

    1. ssl_cert および ssl_key パラメーターを更新し、サーバーの証明書と秘密鍵へのパスを使用するように設定します。 

      ssl_cert = </etc/pki/dovecot/certs/server.example.com.crt
ssl_key = </etc/pki/dovecot/private/server.example.com.key

    2. ssl_ca パラメーターをコメント解除し、CA 証明書へのパスを使用するように設定します。 

      ssl_ca = </etc/pki/dovecot/certs/ca.crt

    3. ssl_dh パラメーターをコメント解除し、Diffie-Hellman パラメーターファイルへのパスを使用するように設定します。 

      ssl_dh = </etc/dovecot/dh.pem
    重要

    Dovecot がファイルからパラメーターの値を確実に読み取るようにするには、パスの先頭に < 文字を付ける必要があります。

9.1.3. 仮想ユーザーを使用するための Dovecot の準備
リンクのコピー

デフォルトでは、Dovecot はサービスを使用するユーザーとして、ファイルシステム上で多くのアクションを実行します。しかし、Dovecot のバックエンドを設定して、これらの操作を実行するためにローカルユーザーを 1 人使用するようにすると、いくつかの利点があります。

利点:

  • Dovecot は、ユーザーの ID (UID) を使用する代わりに、特定のローカルユーザーとしてファイルシステムアクションを実行します。
  • ユーザーは、サーバー上でローカルに利用できる必要はありません。
  • すべてのメールボックスとユーザー固有のファイルを 1 つのルートディレクトリーに保存できます。
  • ユーザーは UID とグループ ID (GID) を必要としないため、管理作業が軽減されます。
  • サーバー上のファイルシステムにアクセスできるユーザーは、これらのファイルにアクセスできないため、メールボックスやインデックスを危険にさらす可能性はありません。
  • レプリケーションのセットアップはより簡単です。

前提条件

  • Dovecot がインストールされています。

手順

  1. vmail ユーザーを作成します。 

    # useradd --home-dir /var/mail/ --shell /usr/sbin/nologin vmail

    Dovecot は後でこのユーザーを使用してメールボックスを管理します。セキュリティー上の理由から、この目的で dovecot または dovenull システムユーザーを使用しないでください。

  2. /var/mail/ 以外のパスを使用する場合は、それに SELinux コンテキスト mail_spool_t を設定します。例: 

    # semanage fcontext -a -t mail_spool_t "<path>(/.*)?"
# restorecon -Rv <path>

  3. /var/mail/ への書き込み権限を vmail ユーザーにのみ付与します。 

    # chown vmail:vmail /var/mail/
# chmod 700 /var/mail/

  4. /etc/dovecot/conf.d/10-mail.conf ファイルの mail_location パラメーターをコメント解除し、メールボックスの形式と場所を設定します。 

    mail_location = sdbox:/var/mail/%n/

    この設定の場合:

    • Dovecot は、single モードで高パフォーマンスの dbox メールボックス形式を使用します。このモードでは、サービスは、maildir 形式と同様に、各メールを個別のファイルに保存します。
    • Dovecot はパス内の %n 変数をユーザー名に解決します。これは、各ユーザーがメールボックス用に個別のディレクトリーを持つようにするために必要です。

9.1.4. PAM を Dovecot 認証バックエンドとして使用する
リンクのコピー

デフォルトでは、Dovecot は Name Service Switch (NSS) インターフェイスをユーザーデータベースとして使用し、Pluggable Authentication Module (PAM) フレームワークを認証バックエンドとして使用します。Dovecot を環境に合わせて設定をカスタマイズし、仮想ユーザー機能を使用して管理を簡素化しましょう。

前提条件

  • Dovecot がインストールされています。
  • 仮想ユーザー機能が設定されています。

手順

  1. /etc/dovecot/conf.d/10-mail.conf ファイルの first_valid_uid パラメーターを更新して、Dovecot に対して認証できる最小のユーザー ID (UID) を定義します。 

    first_valid_uid = 1000

    デフォルトでは、1000 以上の UID を持つユーザーが認証を受けることができます。必要に応じて、last_valid_uid パラメーターを設定して、Dovecot がログインを許可する最大の UID を定義することもできます。

  2. /etc/dovecot/conf.d/auth-system.conf.ext ファイルで、次のように override_fields パラメーターを userdb セクションに追加します。 

    userdb {
  driver = passwd
  override_fields = uid=vmail gid=vmail home=/var/mail/%n/
}

    固定値のため、Dovecot は /etc/passwd ファイルからこれらの設定をクエリーしません。そのため、/etc/passwd に定義されたホームディレクトリーが存在する必要はありません。

9.1.5. Dovecot 設定の完了
リンクのコピー

Dovecot をインストールして設定したら、firewalld サービスで必要なポートを開き、サービスを有効にして開始します。その後、サーバーをテストできます。

前提条件

  • 以下は Dovecot で設定されています。

    • TLS 暗号化
    • 認証バックエンド
  • クライアントは認証局 (CA) 証明書を信頼します。

手順

  1. IMAP または POP3 サービスのみをユーザーに提供する場合は、/etc/dovecot/dovecot.conf ファイルの protocol パラメーターをコメント解除し、必要なプロトコルに設定します。たとえば、POP3 を必要としない場合は、次のように設定します。 

    protocols = imap lmtp

    デフォルトでは、imap、pop3、および lmtp プロトコルが有効になっています。

  2. ローカルファイアウォールでポートを開きます。たとえば、IMAPS、IMAP、POP3S、および POP3 プロトコルのポートを開くには、次のように入力します。 

    # firewall-cmd --permanent --add-service=imaps --add-service=imap --add-service=pop3s --add-service=pop3
# firewall-cmd --reload

  3. dovecot サービスを有効にして開始します。 

    # systemctl enable --now dovecot

検証

  1. Dovecot に接続してメールを読むには、Mozilla Thunderbird などのメールクライアントを使用します。メールクライアントの設定は、使用するプロトコルによって異なります。

    Expand
    表9.1 Dovecot サーバーへの接続設定
    Protocolポート接続セキュリティー認証方法

    IMAP

    143

    STARTTLS

    PLAIN[a]

    IMAPS

    993

    SSL/TLS

    PLAIN[a]

    POP3

    110

    STARTTLS

    PLAIN[a]

    POP3S

    995

    SSL/TLS

    PLAIN[a]

    [a] クライアントは、TLS 接続を介して暗号化されたデータを送信します。したがって、認証情報は開示されません。

    デフォルトでは、Dovecot は TLS を使用しない接続ではプレーンテキスト認証を受け入れないため、この表には暗号化されていない接続の設定がリストされていないことに注意してください。

  2. デフォルト以外の値を含む設定を表示します。 

    # doveconf -n

9.2. LDAP 認証を使用した Dovecot サーバーのセットアップ
リンクのコピー

インフラストラクチャーが LDAP サーバーを使用してアカウントを保存している場合、それに対して Dovecot ユーザーを認証できます。この場合、アカウントはディレクトリー内で一元的に管理され、ユーザーは Dovecot サーバー上のファイルシステムへのローカルアクセスを必要としません。

複数の Dovecot サーバーをレプリケーション機能付きでセットアップしてメールボックスの可用性を高める予定がある場合にも、集中管理型アカウントはメリットとなります。

9.2.1. Dovecot のインストール
リンクのコピー

Dovecot をインストールすることは、IMAP または POP3 サーバーをセットアップする最初のステップです。

dovecot パッケージは以下を提供します。

  • dovecot サービスとそれを管理するユーティリティー
  • Dovecot がオンデマンドで開始するサービス (認証など)
  • サーバーサイドメールフィルタリングなどのプラグイン
  • /etc/dovecot/ ディレクトリーの設定ファイル
  • /usr/share/doc/dovecot/ ディレクトリーのドキュメント

手順

  • dovecot パッケージをインストールします。 

    # yum install dovecot
    注記

    Dovecot がすでにインストールされていて、クリーンな設定ファイルが必要な場合は、/etc/dovecot/ ディレクトリーを名前変更するか削除してください。その後、パッケージを再インストールします。設定ファイルを削除しないと、yum uninstall dovecot コマンドは /etc/dovecot/ 内の設定ファイルをリセットしません。

9.2.2. Dovecot サーバーでの TLS 暗号化の設定
リンクのコピー

Dovecot はセキュアなデフォルト設定を提供します。たとえば、TLS はデフォルトで有効になっており、認証情報と暗号化されたデータをネットワーク経由で送信します。Dovecot サーバーで TLS を設定するには、証明書と秘密鍵ファイルへのパスを設定するだけです。

Diffie-Hellman パラメーターを生成および使用して完全前方秘匿性 (PFS) を提供することにより、TLS 接続のセキュリティーを向上させる。

前提条件

  • Dovecot がインストールされています。

  • 次のファイルが、サーバー上のリストされた場所にコピーされました。

    • サーバー証明書: /etc/pki/dovecot/certs/server.example.com.crt
    • 秘密鍵: /etc/pki/dovecot/private/server.example.com.key
    • 認証局 (CA) 証明書: /etc/pki/dovecot/certs/ca.crt
  • サーバー証明書の Subject DN フィールドのホスト名は、サーバーの完全修飾ドメイン名 (FQDN) と一致します。

手順

  1. 秘密鍵ファイルにセキュアな権限を設定します。 

    # chown root:root /etc/pki/dovecot/private/server.example.com.key
# chmod 600 /etc/pki/dovecot/private/server.example.com.key

  2. Diffie-Hellman パラメーターを使用してファイルを生成します。 

    # openssl dhparam -out /etc/dovecot/dh.pem 4096

    サーバーのハードウェアとエントロピーによっては、4096 ビットの Diffie-Hellman パラメーターを生成するのに数分かかる場合があります。

  3. /etc/dovecot/conf.d/10-ssl.conf ファイルで証明書と秘密鍵ファイルへのパスを設定します。

    1. ssl_cert および ssl_key パラメーターを更新し、サーバーの証明書と秘密鍵へのパスを使用するように設定します。 

      ssl_cert = </etc/pki/dovecot/certs/server.example.com.crt
ssl_key = </etc/pki/dovecot/private/server.example.com.key

    2. ssl_ca パラメーターをコメント解除し、CA 証明書へのパスを使用するように設定します。 

      ssl_ca = </etc/pki/dovecot/certs/ca.crt

    3. ssl_dh パラメーターをコメント解除し、Diffie-Hellman パラメーターファイルへのパスを使用するように設定します。 

      ssl_dh = </etc/dovecot/dh.pem
    重要

    Dovecot がファイルからパラメーターの値を確実に読み取るようにするには、パスの先頭に < 文字を付ける必要があります。

9.2.3. 仮想ユーザーを使用するための Dovecot の準備
リンクのコピー

デフォルトでは、Dovecot はサービスを使用するユーザーとして、ファイルシステム上で多くのアクションを実行します。しかし、Dovecot のバックエンドを設定して、これらの操作を実行するためにローカルユーザーを 1 人使用するようにすると、いくつかの利点があります。

利点:

  • Dovecot は、ユーザーの ID (UID) を使用する代わりに、特定のローカルユーザーとしてファイルシステムアクションを実行します。
  • ユーザーは、サーバー上でローカルに利用できる必要はありません。
  • すべてのメールボックスとユーザー固有のファイルを 1 つのルートディレクトリーに保存できます。
  • ユーザーは UID とグループ ID (GID) を必要としないため、管理作業が軽減されます。
  • サーバー上のファイルシステムにアクセスできるユーザーは、これらのファイルにアクセスできないため、メールボックスやインデックスを危険にさらす可能性はありません。
  • レプリケーションのセットアップはより簡単です。

前提条件

  • Dovecot がインストールされています。

手順

  1. vmail ユーザーを作成します。 

    # useradd --home-dir /var/mail/ --shell /usr/sbin/nologin vmail

    Dovecot は後でこのユーザーを使用してメールボックスを管理します。セキュリティー上の理由から、この目的で dovecot または dovenull システムユーザーを使用しないでください。

  2. /var/mail/ 以外のパスを使用する場合は、それに SELinux コンテキスト mail_spool_t を設定します。例: 

    # semanage fcontext -a -t mail_spool_t "<path>(/.*)?"
# restorecon -Rv <path>

  3. /var/mail/ への書き込み権限を vmail ユーザーにのみ付与します。 

    # chown vmail:vmail /var/mail/
# chmod 700 /var/mail/

  4. /etc/dovecot/conf.d/10-mail.conf ファイルの mail_location パラメーターをコメント解除し、メールボックスの形式と場所を設定します。 

    mail_location = sdbox:/var/mail/%n/

    この設定の場合:

    • Dovecot は、single モードで高パフォーマンスの dbox メールボックス形式を使用します。このモードでは、サービスは、maildir 形式と同様に、各メールを個別のファイルに保存します。
    • Dovecot はパス内の %n 変数をユーザー名に解決します。これは、各ユーザーがメールボックス用に個別のディレクトリーを持つようにするために必要です。

9.2.4. LDAP を Dovecot 認証バックエンドとして使用する
リンクのコピー

通常、LDAP ディレクトリー内のユーザーは、ディレクトリーサービスに対して自分自身を認証できます。Dovecot は、これを使用して、ユーザーが IMAP または POP3 サービスにログインする場合、ユーザーを認証できます。

LDAP 認証を使用する利点はいくつかあります。たとえば、以下のようなものです。

  • 管理者は、ディレクトリーでユーザーを集中管理できます。
  • LDAP アカウントには、特別な属性は必要ありません。LDAP サーバーから認証を受けることができれば十分です。したがって、この方法は、LDAP サーバーで使用されるパスワード保存方式とは無関係です。
  • ユーザーは、Name Service Switch (NSS) インターフェイスと Pluggable Authentication Module (PAM) フレームワークを介して、サーバー上でローカルに利用できる必要はありません。

前提条件

  • Dovecot がインストールされています。
  • 仮想ユーザー機能が設定されています。
  • LDAP サーバーへの接続は、TLS 暗号化をサポートします。
  • Dovecot サーバー上の RHEL は、LDAP サーバーの認証局 (CA) 証明書を信頼します。
  • ユーザーが LDAP ディレクトリーの異なるツリーに保存されている場合、ディレクトリーを検索するための Dovecot 専用の LDAP アカウントが存在します。このアカウントには、他のユーザーの識別名 (DN) を検索する権限が必要です。

手順

  1. /etc/dovecot/conf.d/10-auth.conf ファイルで認証バックエンドを設定します。

    1. 不要な auth-*.conf.ext 認証バックエンド設定ファイルの include ステートメントをコメントアウトします。次に例を示します。 

      #!include auth-system.conf.ext

    2. 次の行をコメント解除して、LDAP 認証を有効にします。 

      !include auth-ldap.conf.ext

  2. /etc/dovecot/conf.d/auth-ldap.conf.ext ファイルを編集し、次のように override_fields パラメーターを userdb セクションに追加します。 

    userdb {
  driver = ldap
  args = /etc/dovecot/dovecot-ldap.conf.ext
  override_fields = uid=vmail gid=vmail home=/var/mail/%n/
}

    固定値のため、Dovecot は LDAP サーバーからこれらの設定をクエリーしません。したがって、これらの属性も存在する必要はありません。

  3. 次の設定で /etc/dovecot/dovecot-ldap.conf.ext ファイルを作成します。

    1. LDAP 構造に応じて、次のいずれかを設定します。

      • ユーザーが LDAP ディレクトリーの異なるツリーに保存されている場合は、動的 DN 検索を設定します。 

        dn = cn=dovecot_LDAP,dc=example,dc=com
dnpass = password
pass_filter = (&(objectClass=posixAccount)(uid=%n))

        Dovecot は、指定された DN、パスワード、およびフィルターを使用して、ディレクトリー内の認証ユーザーの DN を検索します。この検索では、Dovecot はフィルター内の %n をユーザー名に置き換えます。LDAP 検索で返される結果は 1 つだけであることに注意してください。

      • すべてのユーザーが特定のエントリーに保存されている場合は、DN テンプレートを設定します。 

        auth_bind_userdn = cn=%n,ou=People,dc=example,dc=com

    2. LDAP サーバーへの認証バインドを有効にして、Dovecot ユーザーを確認します。 

      auth_bind = yes

    3. URL を LDAP サーバーに設定します。 

      uris = ldaps://LDAP-srv.example.com

      セキュリティー上の理由から、LDAP プロトコル上で LDAPS または STARTTLS コマンドを使用した暗号化された接続のみを使用してください。後者の場合は、さらに tls = yes を設定に追加します。

      証明書の検証を機能させるには、LDAP サーバーのホスト名が TLS 証明書で使用されているホスト名と一致する必要があります。

    4. LDAP サーバーの TLS 証明書の検証を有効にします。 

      tls_require_cert = hard

    5. ベース DN には、ユーザーの検索を開始する DN を設定します。 

      base = ou=People,dc=example,dc=com

    6. 検索範囲を設定します。 

      scope = onelevel

      Dovecot は、指定されたベース DN のみを onelevel スコープで検索し、サブツリーも subtree スコープで検索します。

  4. /etc/dovecot/dovecot-ldap.conf.ext ファイルにセキュアな権限を設定します。 

    # chown root:root /etc/dovecot/dovecot-ldap.conf.ext
# chmod 600 /etc/dovecot/dovecot-ldap.conf.ext

9.2.5. Dovecot 設定の完了
リンクのコピー

Dovecot をインストールして設定したら、firewalld サービスで必要なポートを開き、サービスを有効にして開始します。その後、サーバーをテストできます。

前提条件

  • 以下は Dovecot で設定されています。

    • TLS 暗号化
    • 認証バックエンド
  • クライアントは認証局 (CA) 証明書を信頼します。

手順

  1. IMAP または POP3 サービスのみをユーザーに提供する場合は、/etc/dovecot/dovecot.conf ファイルの protocol パラメーターをコメント解除し、必要なプロトコルに設定します。たとえば、POP3 を必要としない場合は、次のように設定します。 

    protocols = imap lmtp

    デフォルトでは、imap、pop3、および lmtp プロトコルが有効になっています。

  2. ローカルファイアウォールでポートを開きます。たとえば、IMAPS、IMAP、POP3S、および POP3 プロトコルのポートを開くには、次のように入力します。 

    # firewall-cmd --permanent --add-service=imaps --add-service=imap --add-service=pop3s --add-service=pop3
# firewall-cmd --reload

  3. dovecot サービスを有効にして開始します。 

    # systemctl enable --now dovecot

検証

  1. Dovecot に接続してメールを読むには、Mozilla Thunderbird などのメールクライアントを使用します。メールクライアントの設定は、使用するプロトコルによって異なります。

    Expand
    表9.2 Dovecot サーバーへの接続設定
    Protocolポート接続セキュリティー認証方法

    IMAP

    143

    STARTTLS

    PLAIN[a]

    IMAPS

    993

    SSL/TLS

    PLAIN[a]

    POP3

    110

    STARTTLS

    PLAIN[a]

    POP3S

    995

    SSL/TLS

    PLAIN[a]

    [a] クライアントは、TLS 接続を介して暗号化されたデータを送信します。したがって、認証情報は開示されません。

    デフォルトでは、Dovecot は TLS を使用しない接続ではプレーンテキスト認証を受け入れないため、この表には暗号化されていない接続の設定がリストされていないことに注意してください。

  2. デフォルト以外の値を含む設定を表示します。 

    # doveconf -n

9.3. MariaDB SQL 認証を使用した Dovecot サーバーのセットアップ
リンクのコピー

ユーザーとパスワードを MariaDB SQL サーバーに保存する場合、それをユーザーデータベースと認証バックエンドとして使用するように、Dovecot を設定できます。この設定では、アカウントをデータベースで集中管理するため、ユーザーは Dovecot サーバー上のファイルシステムにローカルアクセスできません。

複数の Dovecot サーバーをレプリケーションでセットアップして、メールボックスを高可用性にする予定がある場合にも、集中管理されたアカウントは利点があります。

9.3.1. Dovecot のインストール
リンクのコピー

Dovecot をインストールすることは、IMAP または POP3 サーバーをセットアップする最初のステップです。

dovecot パッケージは以下を提供します。

  • dovecot サービスとそれを管理するユーティリティー
  • Dovecot がオンデマンドで開始するサービス (認証など)
  • サーバーサイドメールフィルタリングなどのプラグイン
  • /etc/dovecot/ ディレクトリーの設定ファイル
  • /usr/share/doc/dovecot/ ディレクトリーのドキュメント

手順

  • dovecot パッケージをインストールします。 

    # yum install dovecot
    注記

    Dovecot がすでにインストールされていて、クリーンな設定ファイルが必要な場合は、/etc/dovecot/ ディレクトリーを名前変更するか削除してください。その後、パッケージを再インストールします。設定ファイルを削除しないと、yum uninstall dovecot コマンドは /etc/dovecot/ 内の設定ファイルをリセットしません。

9.3.2. Dovecot サーバーでの TLS 暗号化の設定
リンクのコピー

Dovecot はセキュアなデフォルト設定を提供します。たとえば、TLS はデフォルトで有効になっており、認証情報と暗号化されたデータをネットワーク経由で送信します。Dovecot サーバーで TLS を設定するには、証明書と秘密鍵ファイルへのパスを設定するだけです。

Diffie-Hellman パラメーターを生成および使用して完全前方秘匿性 (PFS) を提供することにより、TLS 接続のセキュリティーを向上させる。

前提条件

  • Dovecot がインストールされています。

  • 次のファイルが、サーバー上のリストされた場所にコピーされました。

    • サーバー証明書: /etc/pki/dovecot/certs/server.example.com.crt
    • 秘密鍵: /etc/pki/dovecot/private/server.example.com.key
    • 認証局 (CA) 証明書: /etc/pki/dovecot/certs/ca.crt
  • サーバー証明書の Subject DN フィールドのホスト名は、サーバーの完全修飾ドメイン名 (FQDN) と一致します。

手順

  1. 秘密鍵ファイルにセキュアな権限を設定します。 

    # chown root:root /etc/pki/dovecot/private/server.example.com.key
# chmod 600 /etc/pki/dovecot/private/server.example.com.key

  2. Diffie-Hellman パラメーターを使用してファイルを生成します。 

    # openssl dhparam -out /etc/dovecot/dh.pem 4096

    サーバーのハードウェアとエントロピーによっては、4096 ビットの Diffie-Hellman パラメーターを生成するのに数分かかる場合があります。

  3. /etc/dovecot/conf.d/10-ssl.conf ファイルで証明書と秘密鍵ファイルへのパスを設定します。

    1. ssl_cert および ssl_key パラメーターを更新し、サーバーの証明書と秘密鍵へのパスを使用するように設定します。 

      ssl_cert = </etc/pki/dovecot/certs/server.example.com.crt
ssl_key = </etc/pki/dovecot/private/server.example.com.key

    2. ssl_ca パラメーターをコメント解除し、CA 証明書へのパスを使用するように設定します。 

      ssl_ca = </etc/pki/dovecot/certs/ca.crt

    3. ssl_dh パラメーターをコメント解除し、Diffie-Hellman パラメーターファイルへのパスを使用するように設定します。 

      ssl_dh = </etc/dovecot/dh.pem
    重要

    Dovecot がファイルからパラメーターの値を確実に読み取るようにするには、パスの先頭に < 文字を付ける必要があります。

9.3.3. 仮想ユーザーを使用するための Dovecot の準備
リンクのコピー

デフォルトでは、Dovecot はサービスを使用するユーザーとして、ファイルシステム上で多くのアクションを実行します。しかし、Dovecot のバックエンドを設定して、これらの操作を実行するためにローカルユーザーを 1 人使用するようにすると、いくつかの利点があります。

利点:

  • Dovecot は、ユーザーの ID (UID) を使用する代わりに、特定のローカルユーザーとしてファイルシステムアクションを実行します。
  • ユーザーは、サーバー上でローカルに利用できる必要はありません。
  • すべてのメールボックスとユーザー固有のファイルを 1 つのルートディレクトリーに保存できます。
  • ユーザーは UID とグループ ID (GID) を必要としないため、管理作業が軽減されます。
  • サーバー上のファイルシステムにアクセスできるユーザーは、これらのファイルにアクセスできないため、メールボックスやインデックスを危険にさらす可能性はありません。
  • レプリケーションのセットアップはより簡単です。

前提条件

  • Dovecot がインストールされています。

手順

  1. vmail ユーザーを作成します。 

    # useradd --home-dir /var/mail/ --shell /usr/sbin/nologin vmail

    Dovecot は後でこのユーザーを使用してメールボックスを管理します。セキュリティー上の理由から、この目的で dovecot または dovenull システムユーザーを使用しないでください。

  2. /var/mail/ 以外のパスを使用する場合は、それに SELinux コンテキスト mail_spool_t を設定します。例: 

    # semanage fcontext -a -t mail_spool_t "<path>(/.*)?"
# restorecon -Rv <path>

  3. /var/mail/ への書き込み権限を vmail ユーザーにのみ付与します。 

    # chown vmail:vmail /var/mail/
# chmod 700 /var/mail/

  4. /etc/dovecot/conf.d/10-mail.conf ファイルの mail_location パラメーターをコメント解除し、メールボックスの形式と場所を設定します。 

    mail_location = sdbox:/var/mail/%n/

    この設定の場合:

    • Dovecot は、single モードで高パフォーマンスの dbox メールボックス形式を使用します。このモードでは、サービスは、maildir 形式と同様に、各メールを個別のファイルに保存します。
    • Dovecot はパス内の %n 変数をユーザー名に解決します。これは、各ユーザーがメールボックス用に個別のディレクトリーを持つようにするために必要です。

9.3.4. Dovecot 認証バックエンドとして MariaDB SQL データベースを使用する
リンクのコピー

Dovecot は、MariaDB データベースからアカウントとパスワードを読み取り、これを使用して、ユーザーが IMAP または POP3 サービスにログインする場合、ユーザーを認証できます。

MariaDB 認証方式の利点は以下のとおりです。

  • 管理者は、データベースでユーザーを集中管理できます。
  • ユーザーはサーバー上でローカルにアクセスできません。

前提条件

  • Dovecot がインストールされています。
  • 仮想ユーザー機能が設定されています。
  • MariaDB サーバーへの接続では、TLS 暗号化がサポートされます。
  • dovecotDB データベースは MariaDB に存在し、users テーブルには、少なくとも username および password 列が含まれています。
  • password 列には、Dovecot がサポートするスキームで暗号化されたパスワードが含まれています。
  • パスワードは、同じスキームを使用するか、{pw-storage-scheme} 接頭辞を使用します。
  • MariaDB ユーザー dovecot は、dovecotDB データベースの users テーブルに対する読み取り権限を持っています。
  • MariaDB サーバーの TLS 証明書を発行した認証局 (CA) の証明書は、Dovecot サーバーの /etc/pki/tls/certs/ca.crt ファイルに保存されます。

手順

  1. dovecot-mysql パッケージをインストールします。 

    # yum install dovecot-mysql

  2. /etc/dovecot/conf.d/10-auth.conf ファイルで認証バックエンドを設定します。

    1. 不要な auth-*.conf.ext 認証バックエンド設定ファイルの include ステートメントをコメントアウトします。次に例を示します。 

      #!include auth-system.conf.ext

    2. 次の行をコメント解除して、SQL 認証を有効にします。 

      !include auth-sql.conf.ext

  3. /etc/dovecot/conf.d/auth-sql.conf.ext ファイルを編集し、override_fields パラメーターを userdb セクションに次のように追加します。 

    userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
  override_fields = uid=vmail gid=vmail home=/var/mail/%n/
}

    固定値のため、Dovecot はこれらの設定を SQL サーバーからクエリーしません。

  4. 次の設定で /etc/dovecot/dovecot-sql.conf.ext ファイルを作成します。 

    driver = mysql
connect = host=mariadb_srv.example.com dbname=dovecotDB user=dovecot password=dovecotPW ssl_ca=/etc/pki/tls/certs/ca.crt
default_pass_scheme = SHA512-CRYPT
user_query = SELECT username FROM users WHERE username='%u';
password_query = SELECT username AS user, password FROM users WHERE username='%u';
iterate_query = SELECT username FROM users;

    データベースサーバーに対して TLS 暗号化を使用するには、ssl_ca オプションに MariaDB サーバー証明書を発行した CA の証明書のパスを設定します。証明書の検証を機能させるには、MariaDB サーバーのホスト名が TLS 証明書で使用されているホスト名と一致する必要があります。

    データベースのパスワード値に {pw-storage-scheme} 接頭辞が含まれている場合は、default_pass_scheme 設定を省略できます。

    ファイル内のクエリーは、次のように設定する必要があります。

    • user_query パラメーターの場合、クエリーは Dovecot ユーザーのユーザー名を返す必要があります。また、クエリーは 1 つの結果のみを返す必要があります。
    • password_query パラメーターの場合、クエリーはユーザー名とパスワードを返す必要があり、Dovecot は user および password 変数でこれらの値を使用する必要があります。したがって、データベースが異なる列名を使用している場合は、AS SQL コマンドを使用して、結果の列の名前を変更してください。
    • iterate_query パラメーターの場合、クエリーはすべてのユーザーのリストを返す必要があります。

  5. /etc/dovecot/dovecot-sql.conf.ext ファイルにセキュアな権限を設定します。 

    # chown root:root /etc/dovecot/dovecot-sql.conf.ext
# chmod 600 /etc/dovecot/dovecot-sql.conf.ext

9.3.5. Dovecot 設定の完了
リンクのコピー

Dovecot をインストールして設定したら、firewalld サービスで必要なポートを開き、サービスを有効にして開始します。その後、サーバーをテストできます。

前提条件

  • 以下は Dovecot で設定されています。

    • TLS 暗号化
    • 認証バックエンド
  • クライアントは認証局 (CA) 証明書を信頼します。

手順

  1. IMAP または POP3 サービスのみをユーザーに提供する場合は、/etc/dovecot/dovecot.conf ファイルの protocol パラメーターをコメント解除し、必要なプロトコルに設定します。たとえば、POP3 を必要としない場合は、次のように設定します。 

    protocols = imap lmtp

    デフォルトでは、imap、pop3、および lmtp プロトコルが有効になっています。

  2. ローカルファイアウォールでポートを開きます。たとえば、IMAPS、IMAP、POP3S、および POP3 プロトコルのポートを開くには、次のように入力します。 

    # firewall-cmd --permanent --add-service=imaps --add-service=imap --add-service=pop3s --add-service=pop3
# firewall-cmd --reload

  3. dovecot サービスを有効にして開始します。 

    # systemctl enable --now dovecot

検証

  1. Dovecot に接続してメールを読むには、Mozilla Thunderbird などのメールクライアントを使用します。メールクライアントの設定は、使用するプロトコルによって異なります。

    Expand
    表9.3 Dovecot サーバーへの接続設定
    Protocolポート接続セキュリティー認証方法

    IMAP

    143

    STARTTLS

    PLAIN[a]

    IMAPS

    993

    SSL/TLS

    PLAIN[a]

    POP3

    110

    STARTTLS

    PLAIN[a]

    POP3S

    995

    SSL/TLS

    PLAIN[a]

    [a] クライアントは、TLS 接続を介して暗号化されたデータを送信します。したがって、認証情報は開示されません。

    デフォルトでは、Dovecot は TLS を使用しない接続ではプレーンテキスト認証を受け入れないため、この表には暗号化されていない接続の設定がリストされていないことに注意してください。

  2. デフォルト以外の値を含む設定を表示します。 

    # doveconf -n

9.4. 2 つの Dovecot サーバー間のレプリケーションの設定
リンクのコピー

双方向のレプリケーションを使用すると、Dovecot サーバーを高可用性にすることができ、IMAP および POP3 クライアントは両方のサーバーのメールボックスにアクセスできます。Dovecot は、各メールボックスのインデックスログの変更を追跡し、競合を安全な方法で解決します。

両方の複製パートナーでこの手順を実行します。

注記

レプリケーションは、サーバーペア間でのみ機能します。したがって、大規模なクラスターでは、複数の独立したバックエンドペアが必要になります。

前提条件

  • 両方のサーバーが同じ認証バックエンドを使用します。できれば、LDAP または SQL を使用して、アカウントを集中管理してください。
  • Dovecot ユーザーデータベース設定は、ユーザーリストをサポートします。これを確認するには、doveadm user '*' コマンドを使用します。
  • Dovecot は、ユーザー ID (UID) ではなく、vmail ユーザーとしてファイルシステム上のメールボックスにアクセスします。

手順

  1. /etc/dovecot/conf.d/10-replication.conf ファイルを作成し、その中で次の手順を実行します。

    1. notify および replication プラグインを有効にします。 

      mail_plugins = $mail_plugins notify replication

    2. service replicator セクションを追加します。 

      service replicator {
  process_min_avail = 1

  unix_listener replicator-doveadm {
    mode = 0600
    user = vmail
  }
}

      これらの設定により、dovecot サービスの開始時に、Dovecot は 1 つ以上のレプリケータープロセスを開始します。さらに、このセクションは replicator-doveadm ソケットの設定を定義します。

    3. service aggregator セクションを追加して、replication-notify-fifo パイプと replication-notify ソケットを設定します。 

      service aggregator {
  fifo_listener replication-notify-fifo {
    user = vmail
  }
  unix_listener replication-notify {
    user = vmail
  }
}

    4. service doveadm セクションを追加して、レプリケーションサービスのポートを定義します。 

      service doveadm {
  inet_listener {
    port = 12345
  }
}

    5. doveadm レプリケーションサービスのパスワードを設定します。 

      doveadm_password = replication_password

      パスワードは、両方のサーバーで同じにする必要があります。

    6. レプリケーションパートナーを設定します。 

      plugin {
  mail_replica = tcp:server2.example.com:12345
}

    7. オプション: 並列 dsync プロセスの最大数を定義します。 

      replication_max_conns = 20

      replication_max_conns のデフォルト値は 10 です。

  2. /etc/dovecot/conf.d/10-replication.conf ファイルにセキュアな権限を設定します。 

    # chown root:root /etc/dovecot/conf.d/10-replication.conf
# chmod 600 /etc/dovecot/conf.d/10-replication.conf

  3. Dovecot が doveadm レプリケーションポートを開くことができるように、SELinux ブール値 nis_enabled を有効にします。 

    setsebool -P nis_enabled on

  4. レプリケーションパートナーのみがレプリケーションポートにアクセスできるように、firewalld ルールを設定します。次に例を示します。 

    # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.0.2.1/32" port protocol="tcp" port="12345" accept"
# firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv6" source address="2001:db8:2::1/128" port protocol="tcp" port="12345" accept"
# firewall-cmd --reload

    IPv4 アドレスのサブネットマスク /32 と IPv6 アドレスのサブネットマスク /128 は、指定されたアドレスへのアクセスを制限します。

  5. この手順は、他のレプリケーションパートナーでも実行します。

  6. Dovecot をリロードします。 

    # systemctl reload dovecot

検証

  1. 1 つのサーバーのメールボックスでアクションを実行し、Dovecot が変更を他のサーバーにレプリケートしたかどうかを確認します。

  2. レプリケーターステータスを表示します。 

    # doveadm replicator status
Queued 'sync' requests        0
Queued 'high' requests        0
Queued 'low' requests         0
Queued 'failed' requests      0
Queued 'full resync' requests 30
Waiting 'failed' requests     0
Total number of known users   75

  3. 特定のユーザーのレプリケーターステータスを表示します。 

    # doveadm replicator status example_user
username        priority  fast sync  full sync  success sync  failed
example_user    none      02:05:28   04:19:07   02:05:28      -

9.5. ユーザーを IMAP メールボックスに自動的に登録する
リンクのコピー

通常、IMAP サーバー管理者は、Dovecot が Sent や Trash などの特定のメールボックスを自動的に作成し、ユーザーをそれらに登録することを望んでいます。これは設定ファイルに設定できます。

さらに、特殊用途のメールボックス を定義できます。多くの場合、IMAP クライアントは、メールの送信など、特別な目的のためにメールボックスを定義することをサポートしています。ユーザーが正しいメールボックスを手動で選択して設定する必要がないようにするために、IMAP サーバーは IMAP LIST コマンドで special-use 属性を送信できます。その後、クライアントはこの属性を使用して、送信済みメールのメールボックスなどを識別および設定できます。

前提条件

  • Dovecot が設定されている。

手順

  1. /etc/dovecot/conf.d/15-mailboxes.conf ファイルの inbox namespace セクションを更新します。

    1. auto = subscribe 設定を、ユーザーが利用できるようにする必要がある各特殊用途のメールボックスに追加します。次に例を示します。 

      namespace inbox {
  ...
  mailbox Drafts {
    special_use = \Drafts
    auto = subscribe
  }

  mailbox Junk {
    special_use = \Junk
    auto = subscribe
  }

  mailbox Trash {
    special_use = \Trash
    auto = subscribe
  }

  mailbox Sent {
    special_use = \Sent
    auto = subscribe
  }
  ...
}

      メールクライアントがより特殊用途のメールボックスをサポートしている場合は、同様のエントリーを追加できます。special_use パラメーターは、Dovecot が special-use 属性でクライアントに送信する値を定義します。

      詳細は、/usr/share/doc/dovecot/wiki/MailboxSettings.txt ファイルを参照してください。

    2. オプション: 特別な目的のない他のメールボックスを定義する場合は、ユーザーの受信トレイにそれらの mailbox セクションを追加します。次に例を示します。 

      namespace inbox {
  ...
  mailbox "Important Emails" {
    auto = <value>
  }
  ...
}

      auto パラメーターは、次のいずれかの値に設定できます。

      • subscribe: メールボックスを自動的に作成し、ユーザーを登録します。
      • create: ユーザーを登録せずに、メールボックスを自動的に作成します。
      • no (デフォルト): Dovecot はメールボックスを作成することも、ユーザーを登録することもしません。

  2. Dovecot をリロードします。 

    # systemctl reload dovecot

検証

  • IMAP クライアントを使用してメールボックスにアクセスします。

    auto = subscribe が設定されたメールボックスは、自動的に表示されます。クライアントが特殊用途のメールボックスと定義された目的をサポートしている場合、クライアントはそれらを自動的に使用します。

9.6. LMTP ソケットと LMTPS リスナーの設定
リンクのコピー

Postfix などの SMTP サーバーは、Local Mail Transfer Protocol (LMTP) を使用してメールを Dovecot に配信します。

SMTP サーバーが実行されている場合:

  • Dovecot と同じホストで、LMTP ソケットを使用します。

  • 別のホストで、LMTP サービスを使用する

    デフォルトでは、LMTP プロトコルは暗号化されていません。ただし、TLS 暗号化を設定した場合、Dovecot は LMTP サービスに同じ設定を自動的に使用します。その後、SMTP サーバーは、LMTPS プロトコルまたは LMTP 上の STARTTLS コマンドを使用して接続できます。

前提条件

  • Dovecot がインストールされています。
  • LMTP サービスを設定する場合、Dovecot で TLS 暗号化が設定されます。

手順

  1. LMTP プロトコルが有効になっていることを確認します。 

    # doveconf -a | grep -E "^protocols"
protocols = imap pop3 lmtp

    出力に lmtp が含まれている場合、プロトコルは有効になっています。

  2. lmtp プロトコルが無効になっている場合は、/etc/dovecot/dovecot.conf ファイルを編集し、protocols パラメーターの値に lmtp を追加します。 

    protocols = ... lmtp

  3. LMTP ソケットまたはサービスが必要かどうかに応じて、/etc/dovecot/conf.d/10-master.conf ファイルの service lmtp セクションで次の変更を行います。

    • LMTP ソケット: デフォルトでは、Dovecot は自動的に /var/run/dovecot/lmtp ソケットを作成します。

      オプション: 所有権と権限をカスタマイズします。 

      service lmtp {
  ...
  unix_listener lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
  ...
}

    • LMTP サービス: inet_listener サブセクションを追加します。 

      service lmtp {
  ...
  inet_listener lmtp {
    port = 24
  }
  ...
}

  4. SMTP サーバーのみが LMTP ポートにアクセスできるように、firewalld ルールを設定します。次に例を示します。 

    # firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.0.2.1/32" port protocol="tcp" port="24" accept"
# firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv6" source address="2001:db8:2::1/128" port protocol="tcp" port="24" accept"
# firewall-cmd --reload

    IPv4 アドレスのサブネットマスク /32 と IPv6 アドレスのサブネットマスク /128 は、指定されたアドレスへのアクセスを制限します。

  5. Dovecot をリロードします。 

    # systemctl reload dovecot

検証

  1. LMTP ソケットを設定した場合は、Dovecot がソケットを作成したことと、権限が正しいことを確認します。 

    # ls -l /var/run/dovecot/lmtp
srw-------. 1 postfix postfix 0 Nov 22 17:17 /var/run/dovecot/lmtp

  2. LMTP ソケットまたはサービスを使用して、Dovecot にメールを送信するように、SMTP サーバーを設定します。

    LMTP サービスを使用する場合は、SMTP サーバーが LMTPS プロトコルを使用するか、STARTTLS コマンドを送信して暗号化された接続を使用するようにしてください。

9.7. Dovecot で IMAP または POP3 サービスを無効にする
リンクのコピー

デフォルトでは、Dovecot は IMAP および POP3 サービスを提供します。そのうちの 1 つだけが必要な場合は、もう 1 つを無効にして、攻撃サーフェスを減らすことができます。

前提条件

  • Dovecot がインストールされています。

手順

  1. /etc/dovecot/dovecot.conf ファイルの protocols パラメーターをコメント解除し、必要なプロトコルを使用するように設定します。たとえば、POP3 を必要としない場合は、次のように設定します。 

    protocols = imap lmtp

    デフォルトでは、imap、pop3、および lmtp プロトコルが有効になっています。

  2. Dovecot をリロードします。 

    # systemctl reload dovecot

  3. ローカルファイアウォールで不要になったポートを閉じます。たとえば、POP3S および POP3 プロトコルのポートを閉じるには、次のように入力します。 

    # firewall-cmd --remove-service=pop3s --remove-service=pop3
# firewall-cmd --reload

検証

  • dovecot プロセスによって開かれた LISTEN モードのすべてのポートを表示します。 

    # ss -tulp | grep dovecot
tcp  LISTEN 0  100  0.0.0.0:993  0.0.0.0:*  users:(("dovecot",pid=1405,fd=44))
tcp  LISTEN 0  100  0.0.0.0:143  0.0.0.0:*  users:(("dovecot",pid=1405,fd=42))
tcp  LISTEN 0  100     [::]:993     [::]:*  users:(("dovecot",pid=1405,fd=45))
tcp  LISTEN 0  100     [::]:143     [::]:*  users:(("dovecot",pid=1405,fd=43))

    この例では、Dovecot は TCP ポート 993 (IMAPS) と 143 (IMAP) のみをリッスンします。

    ソケットを使用する代わりにポートをリッスンするようにサービスを設定した場合、Dovecot は LMTP プロトコルのポートのみを開くことに注意してください。

ManageSieve プロトコルを使用して、Sieve スクリプトをサーバーにアップロードできます。Sieve スクリプトは、受信メールに対してサーバーが検証して実行するルールとアクションを定義します。

たとえば、ユーザーは Sieve を使用して特定の送信者からのメールを転送でき、管理者はグローバルフィルターを作成して、スパムフィルターによってフラグが付けられたメールを別の IMAP フォルダーに移動できます。

ManageSieve プラグインは、Sieve スクリプトと ManageSieve プロトコルのサポートを Dovecot IMAP サーバーに追加します。

警告

TLS 接続を介した ManageSieve プロトコルの使用をサポートするクライアントのみを使用してください。このプロトコルの TLS を無効にすると、クライアントはネットワーク経由で認証情報をプレーンテキストで送信します。

前提条件

  • Dovecot が設定され、IMAP メールボックスを提供します。
  • TLS 暗号化は Dovecot で設定されます。
  • メールクライアントは、TLS 接続を介して ManageSieve プロトコルをサポートします。

手順

  1. dovecot-pigeonhole パッケージをインストールします。 

    # yum install dovecot-pigeonhole

  2. /etc/dovecot/conf.d/20-managesieve.conf の次の行をコメント解除して、sieve プロトコルを有効にします。 

    protocols = $protocols sieve

    この設定により、すでに有効になっている他のプロトコルに加えて、Sieve が有効になります。

  3. firewalld で ManageSieve ポートを開きます。 

    # firewall-cmd --permanent --add-service=managesieve
# firewall-cmd --reload

  4. Dovecot をリロードします。 

    # systemctl reload dovecot

検証

  1. クライアントを使用し、Sieve スクリプトをアップロードします。次の接続設定を使用します。

    • ポート: 4190
    • 接続セキュリティー: SSL/TLS
    • 認証方法: PLAIN
  2. Sieve スクリプトをアップロードしたユーザーにメールを送信します。メールがスクリプトのルールと一致する場合は、サーバーが定義されたアクションを実行することを確認します。

9.9. Dovecot が設定ファイルを処理する方法
リンクのコピー

dovecot パッケージは、メインの設定ファイル /etc/dovecot/dovecot.conf、および /etc/dovecot/conf.d/ ディレクトリー内の複数の設定ファイルを提供します。Dovecot は、サービスの開始時にファイルを組み合わせて設定を構築します。

複数の設定ファイルの主な利点は、設定をグループ化し、読みやすくすることです。単一の設定ファイルを使用する場合は、代わりに /etc/dovecot/dovecot.conf ですべての設定を維持し、そのファイルからすべての include および include_try ステートメントを削除できます。

詳細は、/usr/share/doc/dovecot/wiki/ConfigFile.txt および /usr/share/doc/dovecot/wiki/Variables.txt ファイルを参照してください。

第10章 印刷の設定
リンクのコピー

Red Hat Enterprise Linux では、Common UNIX Printing System (CUPS) によって印刷を管理します。ユーザーはホスト上の CUPS でプリンターを設定して印刷します。さらに、CUPS でプリンターを共有し、ホストをプリントサーバーとして使用できます。

CUPS は次のプリンターへの印刷をサポートしています。

  • AirPrint™ および IPP Everywhere™ プリンター
  • 従来の PostScript Printer Description (PPD) ベースのドライバーを備えたネットワークおよびローカル USB プリンター

10.1. CUPS のインストールと設定
リンクのコピー

CUPS を使用してローカルホストから印刷できます。このホストを使用してネットワーク内でプリンターを共有し、プリントサーバーとして機能させることもできます。

手順

  1. cups パッケージをインストールします。 

    # yum install cups

  2. CUPS をプリントサーバーとして設定する場合は、/etc/cups/cupsd.conf ファイルを編集し、次の変更を加えます。

    1. CUPS をリモートで設定する場合、またはこのホストをプリントサーバーとして使用する場合は、CUPS がリッスンする IP アドレスとポートを設定します。 

      Listen 192.0.2.1:631
Listen [2001:db8:1::1]:631

      デフォルトでは、CUPS は localhost インターフェイス (127.0.0.1 および ::1) でのみリッスンします。IPv6 アドレスは角括弧で囲んで指定します。

      重要

      信頼できないネットワーク (インターネットなど) からのアクセスを許可するインターフェイスをリッスンするように CUPS を設定しないでください。

    2. <Location /> ディレクティブでそれぞれの IP 範囲を許可することで、サービスにアクセスできる IP 範囲を設定します。 

      <Location />
  Allow from 192.0.2.0/24
  Allow from [2001:db8:1::1]/32
  Order allow,deny
</Location>

    3. <Location /admin> ディレクティブで、CUPS 管理サービスにアクセスできる IP アドレスと範囲を設定します。 

      <Location /admin>
  Allow from 192.0.2.15/32
  Allow from [2001:db8:1::22]/128
  Order allow,deny
</Location>

      この設定では、IP アドレス 192.0.2.15 および 2001:db8:1::22 を持つホストのみが管理サービスにアクセスできます。

    4. オプション: Web インターフェイスで設定ファイルとログファイルへのアクセスを許可する IP アドレスと範囲を設定します。 

      <Location /admin/conf>
  Allow from 192.0.2.15/32
  Allow from [2001:db8:1::22]/128
  ...
</Location>

<Location /admin/log>
  Allow from 192.0.2.15/32
  Allow from [2001:db8:1::22]/128
  ...
</Location>

  3. firewalld サービスを実行し、CUPS へのリモートアクセスを設定する場合は、firewalld で CUPS ポートを開きます。 

    # firewall-cmd --permanent --add-port=631/tcp
# firewall-cmd --reload

    複数のインターフェイスを持つホストで CUPS を実行する場合は、必要なネットワークにアクセスを制限することを検討してください。

  4. cups サービスを有効にして起動します。 

    # systemctl enable --now cups

検証

  • ブラウザーを使用して、http://<hostname>:631 にアクセスします。Web インターフェイスに接続できれば、CUPS は動作しています。

    Administration タブなどの一部の機能では、認証と HTTPS 接続が必要であることに注意してください。デフォルトでは、CUPS は HTTPS アクセスに自己署名証明書を使用するため、認証時の接続はセキュアではありません。

10.2. CUPS サーバーでの TLS 暗号化の設定
リンクのコピー

CUPS は TLS 暗号化接続をサポートしており、デフォルトでは、サービスは認証を必要とするすべてのリクエストに対して暗号化接続を強制します。TLS 暗号化接続により、CUPS サーバーとの安全な通信が保証されます。

証明書が設定されていない場合、CUPS は秘密鍵と自己署名証明書を作成します。これで十分なのは、ローカルホスト自体から CUPS にアクセスする場合だけです。ネットワーク経由でセキュアに接続するには、認証局 (CA) によって署名されたサーバー証明書を使用します。

警告

暗号化を使用しなかった場合、または自己署名証明書を使用した場合、中間者 (MITM) 攻撃により、次のような情報が漏洩する可能性があります。

  • Web インターフェイスを使用して CUPS を設定する際の管理者の認証情報
  • ネットワーク経由で印刷ジョブを送信する際の機密データ

前提条件

  • CUPS が設定されている。
  • あなたは秘密鍵を作成し、認証局 (CA) がその秘密鍵に対してサーバー証明書を発行しました。
  • 中間証明書をサーバー証明書にアタッチしている (サーバー証明書を検証するために中間証明書が必要な場合)。
  • CUPS にはサービスが鍵を読み取るときにパスワードを入力するオプションがないため、秘密鍵はパスワードで保護されません。

  • 証明書の正規名 (CN) またはサブジェクト代替名 (SAN) フィールドが、次のいずれかと一致する。

    • CUPS サーバーの完全修飾ドメイン名 (FQDN)
    • DNS によってサーバーの IP アドレスに解決されるエイリアス
  • 秘密鍵とサーバー証明書ファイルが、Privacy Enhanced Mail (PEM) 形式を使用している。
  • クライアントが CA 証明書を信頼している。

手順

  1. /etc/cups/cups-files.conf ファイルを編集し、次の設定を追加して自己署名証明書の自動作成を無効にします。 

    CreateSelfSignedCerts no

  2. 自己署名証明書と秘密鍵を削除します。 

    # rm /etc/cups/ssl/<hostname>.crt /etc/cups/ssl/<hostname>.key

  3. オプション: サーバーの FQDN を表示します。 

    # hostname -f
     
    server.example.com

  4. 秘密鍵とサーバー証明書を /etc/cups/ssl/ ディレクトリーに保存します。次に例を示します。 

    # mv /root/server.key /etc/cups/ssl/server.example.com.key
# mv /root/server.crt /etc/cups/ssl/server.example.com.crt
    重要

    CUPS では、秘密鍵に <fqdn>.key、サーバー証明書ファイルに <fqdn>.crt という名前を付ける必要があります。エイリアスを使用する場合は、ファイルに <alias>.key および <alias>.crt という名前を付ける必要があります。

  5. root ユーザーのみがこのファイルを読み取ることができるように、秘密鍵にセキュアなパーミッションを設定します。 

    # chown root:root /etc/cups/ssl/server.example.com.key
# chmod 600 /etc/cups/ssl/server.example.com.key

    証明書は、セキュアな接続を確立する前のクライアントとサーバー間の通信の要素であるため、どのクライアントも認証なしで証明書を取得できます。したがって、サーバー証明書ファイルに厳密なパーミッションを設定する必要はありません。

  6. SELinux コンテキストを復元します。 

    # restorecon -Rv /etc/cups/ssl/

  7. オプション: 証明書の CN フィールドと SAN フィールドを表示します。 

    # openssl x509 -text -in /etc/cups/ssl/server.example.com.crt
     
    Certificate:
  Data:
    ...
    Subject: CN = server.example.com
    ...
    X509v3 extensions:
      ...
      X509v3 Subject Alternative Name:
        DNS:server.example.com
  ...

  8. サーバー証明書の CN または SAN フィールドにサーバーの FQDN とは異なるエイリアスが含まれている場合は、ServerAlias パラメーターを /etc/cups/cupsd.conf ファイルに追加します。 

    ServerAlias alternative_name.example.com

    この場合、以降の手順で FQDN の代わりに代替名を使用します。

  9. デフォルトでは、CUPS は、Web インターフェイスの /admin ページで管理タスクを実行する場合など、タスクで認証が必要な場合にのみ暗号化接続を強制します。

    CUPS サーバー全体の暗号化を強制するには、/etc/cups/cupsd.conf ファイル内のすべての <Location> ディレクティブに Encryption Required を追加します。次に例を示します。 

    <Location />
  ...
  Encryption Required
</Location>

  10. CUPS を再起動します。 

    # systemctl restart cups

検証

  1. ブラウザーを使用して、https://<hostname>:631/admin/ にアクセスします。アクセスするには、ブラウザーが CA 証明書を信頼している必要があります。接続が成功すれば、CUPS で TLS 暗号化が正しく設定されています。
  2. サーバー全体の暗号化を必須とするように設定した場合は、http://<hostname>:631/ にアクセスします。この場合、CUPS は Upgrade Required というエラーを返します。

トラブルシューティング

  • cups サービスの systemd ジャーナルエントリーを表示します。 

    # journalctl -u cups

    HTTPS プロトコルを使用した Web インターフェイスへの接続に失敗した後、ジャーナルに Unable to encrypt connection: Error while reading file というエラーが含まれている場合は、秘密鍵とサーバー証明書ファイルの名前を確認します。

10.3. Web インターフェイスで CUPS サーバーを管理するための管理権限の付与
リンクのコピー

CUPS 管理者が他のサービスで予期せぬ権限を取得することを避けるため、CUPS 管理者専用のグループを使用してください。

デフォルトでは、sys、root、および wheel グループのメンバーは、Web インターフェイスで管理タスクを実行できます。しかし、他の特定のサービスもこれらのグループを使用します。たとえば、wheel グループのメンバーは、デフォルトで sudo を使用して root 権限でコマンドを実行できます。CUPS 管理者専用のグループを使用することで、これらのユーザーが CUPS インターフェイスのみにアクセスできることを保証できます。

前提条件

  • CUPS が設定されている。
  • 使用するクライアントの IP アドレスに、Web インターフェイスの管理領域にアクセスする権限がある。

手順

  1. CUPS 管理者用のグループを作成します。 

    # groupadd cups-admins

  2. Web インターフェイスでサービスを管理する必要があるユーザーを、cups-admins グループに追加します。 

    # usermod -a -G cups-admins <username>

  3. /etc/cups/cups-files.conf ファイルの SystemGroup パラメーターの値を更新し、cups-admin グループを追加します。 

    SystemGroup sys root wheel cups-admins

    cups-admin グループのみに管理アクセス権を与える必要がある場合は、パラメーターから他のグループ名を削除します。

  4. CUPS を再起動します。 

    # systemctl restart cups

検証

  1. ブラウザーを使用して、https://<hostname_or_ip_address>:631/admin/ にアクセスします。

    注記

    ユーザーは HTTPS プロトコルを使用する場合のみ、Web UI の管理領域にアクセスできます。

  2. 管理タスクの実行を開始します。たとえば、Add printer をクリックします。

  3. Web インターフェイスで、ユーザー名とパスワードの入力を求められます。続行するには、cups-admins グループのメンバーであるユーザーの認証情報を使用して認証します。

    認証が成功すると、このユーザーは管理タスクを実行できます。

10.4. プリンタードライバーを含むパッケージ
リンクのコピー

Red Hat Enterprise Linux (RHEL) は、CUPS 用のプリンタードライバーを含むさまざまなパッケージを提供しています。必要なパッケージをインストールした後、CUPS Web インターフェイスまたは lpinfo -m コマンドを使用してドライバーのリストを表示できます。

Expand
表10.1 ドライバーパッケージのリスト
パッケージ名プリンター用ドライバー

cups

Zebra、Dymo

c2esp

Kodak

foomatic

Brother、Canon、Epson、Gestetner、HP、Infotec、Kyocera、Lanier、Lexmark、NRG、Ricoh、Samsung、Savin、Sharp、Toshiba、Xerox など

gutenprint-cups

Brother、Canon、Epson、Fujitsu、HP、Infotec、Kyocera、Lanier、NRG、Oki、Minolta、Ricoh、Samsung、Savin、Xerox など

hplip

HP

pnm2ppa

HP

splix

Samsung、Xerox など

パッケージによっては、同じプリンターベンダーまたはモデル用の、異なる機能を持つドライバーが含まれている場合があることに注意してください。

10.5. プリンターがドライバーレス印刷をサポートしているかどうかの確認
リンクのコピー

CUPS はドライバーレス印刷をサポートしています。つまり、ハードウェア固有のソフトウェアをプリンターに提供しなくても印刷できます。

ドライバー不要の印刷を行うには、プリンターはクライアントにその機能を通知し、以下のいずれかの規格を使用する必要があります。

  • AirPrint™
  • IPP Everywhere™
  • Mopria®
  • Wi-Fi Direct Print Services

ipptool ユーティリティーを使用すると、プリンターがドライバーレス印刷をサポートしているかどうかを確認できます。

前提条件

  • プリンターまたはリモートプリントサーバーが、インターネット印刷プロトコル (IPP) をサポートしている。
  • ホストが、プリンターまたはリモートプリントサーバーの IPP ポートに接続できる。デフォルトの IPP ポートは 631 です。

手順

  • ipp-versions-supported 属性と document-format-supported 属性を照会し、get-printer-attributes テストに合格することを確認します。

    • リモートプリンターの場合は、次のように入力します。 

      # ipptool -tv ipp://<ip_address_or_hostname>:631/ipp/print get-printer-attributes.test | grep -E "ipp-versions-supported|document-format-supported|get-printer-attributes"
       
      Get printer attributes using get-printer-attributes      [PASS]
    ipp-versions-supported (1setOf keyword) = ...
    document-format-supported (1setOf mimeMediaType) = ...

    • リモートプリントサーバー上のキューの場合は、次のように入力します。 

      # ipptool -tv ipp://<ip_address_or_hostname>:631/printers/<queue_name> get-printer-attributes.test | grep -E "ipp-versions-supported|document-format-supported|get-printer-attributes"
       
      Get printer attributes using get-printer-attributes      [PASS]
    ipp-versions-supported (1setOf keyword) = ...
    document-format-supported (1setOf mimeMediaType) = ...

    ドライバーレス印刷が機能することを確認するには、出力で次のことを確認します。

    • get-printer-attributes テストが PASS を返す。
    • プリンターがサポートする IPP バージョンが 2.0 以降である。

    • 形式のリストに次のいずれかが含まれている。

      • application/pdf
      • image/urf
      • image/pwg-raster
    • カラープリンターの場合、前述の形式のいずれかに加えて、image/jpeg が出力に含まれている。

10.6. Web インターフェイスを使用した CUPS へのプリンターの追加
リンクのコピー

ユーザーが CUPS 経由で印刷できるようにするには、事前にプリンターを追加する必要があります。ネットワークプリンターと、USB 経由などで CUPS ホストに直接接続されているプリンターの両方を使用できます。

CUPS ドライバーレス機能を使用するか、PostScript Printer Description (PPD) ファイルを使用してプリンターを追加できます。

注記

CUPS はドライバーレス印刷を優先しており、ドライバーの使用は非推奨です。

Red Hat Enterprise Linux (RHEL) は、mDNS レスポンダーにクエリーを実行することでリクエストを解決する、Name Service Switch Multicast DNS プラグイン (nss-mdns) を提供しません。そのため、RHEL では、mDNS を使用したローカルドライバーレスプリンターの自動検出とインストールは利用できません。この問題を回避するには、1 台のプリンターを手動でインストールするか、cups-browsed を使用してリモートプリントサーバーで使用可能な多数の印刷キューを自動的にインストールします。

前提条件

手順

  1. ブラウザーを使用して、https://<hostname>:631/admin/ にアクセスします。

    Web インターフェイスには HTTPS プロトコルを使用して接続する必要があります。使用しないと、セキュリティー上の理由から、CUPS が後のステップで認証できなくなります。

  2. Add printer をクリックします。
  3. ユーザーがまだ認証されていない場合、CUPS は管理ユーザーの認証情報の入力を求めます。許可されたユーザーのユーザー名とパスワードを入力します。
  4. ドライバーレス印刷を使用せず、追加するプリンターが自動的に検出された場合は、それを選択し、Continue をクリックします。

  5. プリンターが検出されなかった場合は、以下を実行します。

    1. プリンターがサポートするプロトコルを選択します。

      プロトコルの選択

      プリンターがドライバーレス印刷をサポートしており、この機能を使用する場合は、ipp または ipps プロトコルを選択します。

    2. Continue をクリックします。

    3. プリンターまたはリモートプリントサーバー上のキューへの URL を入力します。

      プリンターの URL を入力
    4. Continue をクリックします。

  6. 名前を入力し、必要に応じて説明と場所を入力します。CUPS をプリントサーバーとして使用し、他のクライアントが CUPS を介してこのプリンターで印刷できるようにする場合は、Share this printer も選択します。

    プリンターの詳細の追加
  7. Make リストからプリンターの製造元を選択します。プリンターの製造元がリストにない場合は、Generic を選択するか、プリンターの PPD ファイルをアップロードします。
  8. Continue をクリックします。

  9. プリンターのモデルを選択します。

    • プリンターがドライバーレス印刷をサポートしている場合は、IPP Everywhere を選択します。なお、以前にプリンター固有のドライバーをローカルにインストールしていた場合は、リストに <printer_name> - IPP Everywhere などのエントリーも含まれている可能性があります。
    • プリンターがドライバーレス印刷をサポートしていない場合は、モデルを選択するか、プリンターの PPD ファイルをアップロードします。
    プリンターモデルの選択
  10. Add Printer をクリックします。

  11. Set printer options ページの設定とタブは、ドライバーとプリンターがサポートする機能によって異なります。このページを使用して、用紙サイズなどのデフォルトのオプションを設定します。

    プリンターオプションの設定
  12. Set default options をクリックします。

検証

  1. Web インターフェイスで Printers タブを開きます。
  2. プリンターの名前をクリックします。
  3. Maintenance リストで、Print test page を選択します。

トラブルシューティング

10.7. lpadmin ユーティリティーを使用した CUPS へのプリンターの追加
リンクのコピー

ユーザーが CUPS 経由で印刷できるようにするには、事前にプリンターを追加する必要があります。ネットワークプリンターと、USB 経由などで CUPS ホストに直接接続されているプリンターの両方を使用できます。

CUPS ドライバーレス機能を使用するか、PostScript Printer Description (PPD) ファイルを使用してプリンターを追加できます。

注記

CUPS はドライバーレス印刷を優先しており、ドライバーの使用は非推奨です。

Red Hat Enterprise Linux (RHEL) は、mDNS レスポンダーにクエリーを実行することでリクエストを解決する、Name Service Switch Multicast DNS プラグイン (nss-mdns) を提供しません。そのため、RHEL では、mDNS を使用したローカルドライバーレスプリンターの自動検出とインストールは利用できません。この問題を回避するには、1 台のプリンターを手動でインストールするか、cups-browsed を使用してリモートプリントサーバーで使用可能な多数の印刷キューを自動的にインストールします。

前提条件

手順

  • CUPS にプリンターを追加します。

    • ドライバーレスサポートを使用してプリンターを追加するには、次のように入力します。 

      # lpadmin -p Demo-printer -E -v ipp://192.0.2.200/ipp/print -m everywhere

      お使いのプリンターで -m everywhere オプションが機能しない場合は、-m driverless:<uri> を試してください (例: -m driverless:ipp://192.0.2.200/ipp/print)。

    • ドライバーレスサポートを使用してリモートプリントサーバーのキューを追加するには、次のように入力します。 

      # lpadmin -p Demo-printer -E -v ipp://192.0.2.201/printers/example-queue -m everywhere

      お使いのプリンターで -m everywhere オプションが機能しない場合は、-m driverless:<uri> を試してください (例: -m driverless:ipp://192.0.2.200/printers/example-queue)。

    • ファイル内のドライバーを使用してプリンターを追加するには、次のように入力します。 

      # lpadmin -p Demo-printer -E -v socket://192.0.2.200/ -P /root/example.ppd

    • ファイル内のドライバーを使用してリモートプリントサーバーのキューを追加するには、次のように入力します。 

      # lpadmin -p Demo-printer -E -v ipp://192.0.2.201/printers/example-queue -P /root/example.ppd

    • ローカルドライバーデータベース内のドライバーを使用してプリンターを追加するには、次の手順を実行します。

      1. データベース内のドライバーをリスト表示します。 

        # lpinfo -m
         
        drv:///sample.drv/generpcl.ppd Generic PCL Laser Printer

      2. データベース内のドライバーへの URI を使用してプリンターを追加します。 

        # lpadmin -p Demo-printer -E -v socket://192.0.2.200/ -m drv:///sample.drv/generpcl.ppd

    これらのコマンドでは、次のオプションを使用します。

    • -p <printer_name>: CUPS 内のプリンターの名前を設定します。
    • -E: プリンターを有効にします。CUPS はそのプリンターのジョブを受け付けます。このオプションは -p の後に指定する必要があることに注意してください。詳細は、man ページのオプションの説明を参照してください。
    • -v <uri>: プリンターまたはリモートプリントサーバーキューへの URI を設定します。
    • -m <driver_uri>: ローカルドライバーデータベースから取得した指定のドライバー URI に基づいて PPD ファイルを設定します。
    • -P <PPD_file>: PPD ファイルへのパスを設定します。

検証

  1. 使用可能なプリンターを表示します。 

    # lpstat -p
     
    printer Demo-printer is idle. enabled since Fri 23 Jun 2023 09:36:40 AM CEST

  2. テストページを印刷します。 

    # lp -d Demo-printer /usr/share/cups/data/default-testpage.pdf

CUPS の Web インターフェイスは、プリンターの管理タスクを実行するためのグラフィカルなオプションを提供します。

プリンター管理者は、場合によってはプリントサーバー上でさまざまなタスクを実行する必要があります。以下に例を示します。

  • 技術者がプリンターを修理している間のプリンターの一時停止などのメンテナンスタスク
  • プリンターのデフォルト設定の変更などの管理タスク

これらのタスクは、CUPS の Web インターフェイスを使用して実行できます。

前提条件

手順

  1. ブラウザーを使用して、https://<hostname>:631/printers/ にアクセスします。

    Web インターフェイスには HTTPS プロトコルを使用して接続する必要があります。使用しないと、セキュリティー上の理由から、CUPS が後のステップで認証できなくなります。

  2. 設定するプリンターの名前をクリックします。
  3. メンテナンスタスクを実行するか管理タスクを実行するかに応じて、リストから必要なアクションを選択します。
  4. ユーザーがまだ認証されていない場合、CUPS は管理ユーザーの認証情報の入力を求めます。許可されたユーザーのユーザー名とパスワードを入力します。
  5. タスクを実行します。

10.9. Samba を使用した Kerberos 認証による Windows プリントサーバーへの印刷
リンクのコピー

samba-krb5-printing ラッパーを使用すると、Red Hat Enterprise Linux (RHEL) にログインした Active Directory (AD) ユーザーは、Kerberos を使用して Active Directory (AD) に対して認証して、Windows プリントサーバーに印刷ジョブを転送するローカルの CUPS プリントサーバーに印刷を出力できます。

この設定の利点は、RHEL 上の CUPS の管理者が、設定で固定ユーザー名およびパスワードを保存する必要がないことです。CUPS は、印刷ジョブを送信するユーザーの Kerberos チケットで AD に対して認証します。

注記

Red Hat は、ローカルシステムから CUPS への印刷ジョブの送信のみをサポートしています。Samba プリントサーバー上のプリンターの再共有はサポートしていません。

前提条件

  • ローカルの CUPS インスタンスに追加するプリンターが、AD プリントサーバーで共有されている。
  • あなたは AD のメンバーとして RHEL ホストに参加しました。
  • CUPS が RHEL にインストールされており、cups サービスが実行されている。
  • プリンターの PostScript Printer Description (PPD) ファイルが /usr/share/cups/model/ ディレクトリーに保存されている。

手順

  1. samba-krb5-printing、samba-client、および krb5-workstation パッケージをインストールします。 

    # yum install samba-krb5-printing samba-client krb5-workstation

  2. 必要に応じて、ドメイン管理者として認証を行い、Windows プリントサーバーで共有されるプリンターの一覧を表示します。 

    # smbclient -L win_print_srv.ad.example.com -U administrator@AD_KERBEROS_REALM --use-kerberos=required
     
    	Sharename       Type      Comment
	---------       ----      -------
	Example         Printer   Example

  3. 必要に応じて、CUPS モデルのリストを表示して、プリンターの PPD 名を指定します。 

    lpinfo -m
     
    samsung.ppd Samsung M267x 287x Series PXL

    次のステップでプリンターを追加する場合は、PPD ファイルの名前が必要です。

  4. CUPS にプリンターを追加します。 

    # lpadmin -p "example_printer" -v smb://win_print_srv.ad.example.com/Example -m samsung.ppd -o auth-info-required=negotiate -E

    このコマンドでは次のオプションを使用します。

    • -p printer_name は、CUPS にプリンターの名前を設定します。
    • -v URI_to_Windows_printer は、Windows プリンターに URI を設定します。smb://host_name/printer_share_name という形式を使用します。
    • -m PPD_file は、プリンターが使用する PPD ファイルを設定します。
    • -o auth-info-required=negotiate は、印刷ジョブをリモートサーバーに転送する際に CUPS が Kerberos 認証を使用するように設定します。
    • -E はプリンターを有効にします。CUPS はそのプリンターのジョブを受け付けます。

検証

  1. AD ドメインユーザーとして RHEL ホストにログインします。

  2. AD ドメインユーザーとして認証します。 

    # kinit domain_user_name@AD_KERBEROS_REALM

  3. ローカルの CUPS プリントサーバーに追加したプリンターにファイルを出力します。 

    # lp -d example_printer file

cups-browsed サービスは、DNS サービス検出 (DNS-SD) と CUPS ブラウジングを使用して、共有リモートプリンターのすべて、またはフィルタリング後のサブセットを、ローカルの CUPS サービスで自動的に利用できるようにします。ワークステーションでこの機能を使用すると、信頼できるプリントサーバー上のプリンターのみを使用可能に設定できます。

プリントサーバーが多数のプリンターを共有している場合、リストに表示されるプリンターの数を減らすために、参照するプリンターを特定の条件でフィルタリングするように cup-browsed を設定することもできます。

注記

アプリケーションの印刷ダイアログが DNS-SD などの他のメカニズムを使用してリモートプリンターのリストを表示している場合、cups-browsed は影響を及ぼしません。また、cups-browsed サービスは、ユーザーがリストにないプリンターに手動でアクセスすることを妨げるものではありません。

前提条件

  • CUPS サービスがローカルホストで設定されている。

  • リモート CUPS プリントサーバーが存在する。このサーバーには次の条件が適用されます。

    • サーバーが、クライアントからアクセス可能なインターフェイスでリッスンしている。
    • /etc/cups/cups.conf ファイル内のサーバーの <Location /> ディレクティブにある Allow from パラメーターにより、クライアントの IP アドレスからのアクセスが許可されている。
    • サーバーがプリンターを共有している。
    • ファイアウォールルールにより、クライアントからサーバーの CUPS ポートへのアクセスが許可されている。

手順

  1. /etc/cups/cups-browsed.conf ファイルを編集し、次の変更を加えます。

    1. ポーリングするリモート CUPS サーバーごとに BrowsePoll パラメーターを追加します。 

      BrowsePoll remote_cups_server.example.com
BrowsePoll 192.0.2.100:1631

      リモート CUPS サーバーが 631 とは異なるポートでリッスンする場合は、ホスト名または IP アドレスに <port> を追加します。

    2. オプション: フィルターを設定して、ローカル CUPS サービスに表示されるプリンターを制限します。たとえば、名前に sales_ が含まれるキューをフィルタリングするには、次のパラメーターを追加します。 

      BrowseFilter name sales_

      さまざまなフィールド名でフィルタリングしたり、フィルターを無効にしたり、正確な値を照合したりできます。詳細は、システムの cups-browsed.conf(5) man ページのパラメーターの説明と例を参照してください。

    3. オプション: ポーリング間隔とタイムアウトを変更して、参照サイクルの数を制限します。 

      BrowseInterval 1200
BrowseTimeout 6000

      プリンターが参照リストから消えるのを避けるために、BrowseInterval と BrowseTimeout の両方を同じ比率で増やしてください。つまり、BrowseInterval の値を 5 またはそれ以上の整数で乗算し、その結果の値を BrowseTimeout に使用します。

      デフォルトでは、cups-browsed は 60 秒ごとにリモートサーバーをポーリングし、タイムアウトは 300 秒です。ただし、キューの数が多いプリントサーバーでこれらのデフォルト値を使用すると、大量のリソースが消費される可能性があります。

  2. cups-browsed サービスを有効にして起動します。 

    # systemctl enable --now cups-browsed

検証

  • 使用可能なプリンターをリスト表示します。 

    # lpstat -v
     
    device for Demo-printer: implicitclass://Demo-printer/

    プリンターの出力に implicitclass が含まれていれば、cups-browsed サービスが CUPS でプリンターを管理しています。

10.11. systemd ジャーナルの CUPS ログへのアクセス
リンクのコピー

デフォルトでは、CUPS はログメッセージを systemd ジャーナルに保存します。これには、エラーメッセージ、アクセスログエントリー、ページログエントリーが含まれます。

前提条件

手順

  • ログエントリーを表示します。

    • すべてのログエントリーを表示するには、次のように入力します。 

      # journalctl -u cups

    • 特定の印刷ジョブのログエントリーを表示するには、次のように入力します。 

      # journalctl -u cups JID=<print_job_id>

    • 特定の期間内のログエントリーを表示するには、次のように入力します。 

      # journalectl -u cups --since=<YYYY-MM-DD> --until=<YYYY-MM-DD>

      YYYY は年に、MM は月に、DD は日に置き換えます。

10.12. systemd ジャーナルではなくファイルにログを保存するように CUPS を設定する
リンクのコピー

デフォルトでは、CUPS はログメッセージを systemd ジャーナルに保存します。ログメッセージをファイルに保存するように CUPS を設定することもできます。

前提条件

手順

  1. /etc/cups/cups-files.conf ファイルを編集し、AccessLog、ErrorLog、および PageLog パラメーターを、これらのログファイルを保存するパスに設定します。 

    AccessLog /var/log/cups/access_log
ErrorLog /var/log/cups/error_log
PageLog /var/log/cups/page_log

  2. /var/log/cups/ 以外のディレクトリーにログを保存するように CUPS を設定する場合は、このディレクトリーに cupd_log_t SELinux コンテキストを設定します。たとえば、次のように設定します。 

    # semanage fcontext -a -t cupsd_log_t "/var/log/printing(/.*)?"
# restorecon -Rv /var/log/printing/

  3. cups サービスを再起動します。 

    # systemctl restart cups

検証

  1. ログファイルを表示します。 

    # cat /var/log/cups/access_log
# cat /var/log/cups/error_log
# cat /var/log/cups/page_log

  2. /var/log/cups/ 以外のディレクトリーにログを保存するように CUPS を設定した場合は、ログディレクトリーの SELinux コンテキストが cupsd_log_t であることを確認します。 

    # ls -ldZ /var/log/printing/
     
    drwxr-xr-x. 2 lp sys unconfined_u:object_r:cupsd_log_t:s0 6 Jun 20 15:55 /var/log/printing/

10.13. 高可用性 CUPS プリントサーバー環境の設定
リンクのコピー

クライアントが中断することなくプリンターにアクセスする必要がある場合は、複数のホストに CUPS を設定し、印刷キュー参照機能を使用して高可用性を実現できます。印刷クライアントは、さまざまな印刷サーバーにより共有される印刷キューを自動的に設定します。

クライアントが印刷ジョブをローカル印刷キューに送信すると、クライアント上の CUPS はジョブを印刷サーバーの 1 つにルーティングし、印刷サーバーはそのジョブを処理してプリンターに送信します。

手順

  1. 2 台以上のサーバーに CUPS をセットアップします。

    1. CUPS をインストールして設定します。
    2. TLS 暗号化を有効にします。

    3. lpadmin ユーティリティー または Web インターフェイス を使用して、すべての CUPS インスタンスに印刷キューを追加します。Web インターフェイスを使用する場合は、プリンターを追加するときに Share this printer オプションを選択してください。lpadmin ユーティリティーでは、この設定がデフォルトで有効になります。

      重要

      高可用性シナリオでは、1 台のプリントサーバー上の各キューには、他のサーバー上に完全に同じ名前のキューが必要です。lpstat -e コマンドを使用すると、各サーバーのキュー名を表示できます。

      オプション: 各サーバーのキューを、異なるプリンターを参照するように設定できます。

  2. 印刷クライアントの場合は以下を行います。

    1. /etc/cups/cups-browsed.conf ファイルを編集し、各 CUPS 印刷サーバーの BrowsePoll ディレクティブを追加します。 

      BrowsePoll print_server_1.example.com:631
BrowsePoll print_server_2.example.com:631

    2. cups サービスと cups-browsed サービスの両方を有効にして起動します。 

      # systemctl enable --now cups cups-browsed

検証

  • クライアントで使用可能なプリンターを表示します。 

    # lpstat -t
     
    device for Demo-printer: implicitclass://Demo-printer/
Demo-printer accepting requests since Fri 22 Nov 2024 11:54:59 AM CET
printer Demo-printer is idle.  enabled since Fri 22 Nov 2024 11:54:59 AM CET
...

    出力例は、Demo-printer キューが implicitclass バックエンドを使用していることを示しています。その結果、cups-browsed は、このキューの印刷ジョブを、このクライアントの BrowsePoll ディレクティブで指定されたホストにルーティングします。

10.14. CUPS ドキュメントへのアクセス
リンクのコピー

CUPS では、CUPS サーバーにインストールされているサービスのドキュメントにブラウザーからアクセスできます。

CUPS のドキュメントには以下が含まれます。

  • コマンドラインによるプリンターの管理やアカウンティングなどに関する管理ドキュメント
  • man ページ
  • 管理 API などのプログラミングドキュメント
  • 参考資料
  • Specifications

前提条件

手順

  1. ブラウザーを使用して、http://<hostname_or_ip_address>:631/help/ にアクセスします。
  2. Online Help Documents のエントリーを展開し、参照するドキュメントを選択します。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る