Menu Close
第3章 Capsule Server での追加設定の実行
3.1. katello エージェントのインストール
クライアントのリモートアップデートを許可するために、katello エージェントをインストールすることが推奨されます。Capsule Server のベースシステムは Satellite Server のクライアントであるため、katello エージェントがインストールされている必要があります。
作業開始前の準備
- Satellite Server で Satellite Tools リポジトリーが有効にされている必要があります。
- Satellite Server で Satellite Tools リポジトリーが同期されている必要があります。
katello-agent のインストール手順:
- システムにログインします。
このバージョンの Satellite 向け Satellite Tools リポジトリーを有効にします。
# subscription-manager repos \ --enable=rhel-7-server-satellite-tools-6.5-rpms
パッケージをインストールします。
# yum install katello-agent
3.2. Capsule Server でリモート実行の有効化
Capsule Server のホストでコマンドを実行する場合は、リモート実行が有効である必要があります。
デフォルトでは、外部の Capsule はリモート実行機能が無効になっています。Capsule Server でリモート実行を使用するには、以下のコマンドを実行して、これを有効にする必要があります。
# satellite-installer --scenario capsule \ --enable-foreman-proxy-plugin-remote-execution-ssh
3.3. Capsule Server へのライフサイクル環境の追加
Capsule Server でコンテンツ機能が有効な場合は、環境を追加して、Capsule が Satellite Server のコンテンツを同期し、コンテンツをホストシステムに提供できるようにする必要があります。
リポジトリーが CDN から更新されるたびに自動で Capsule が同期されるようになるので、ライブラリー ライフサイクル環境を Capsule Server に割り当てないでください。自動的に同期されると、Capsule 上の複数のシステムリソースや Satellite と Capsule 間のネットワーク帯域幅、および Capsule 上の利用可能なディスク領域が消費される可能性があります。
Satellite Server の Hammer CLI または Satellite Web UI を使用できます。
手順
ライフサイクル環境を Capsule Server に追加するには、以下の手順を実行します。
- Satellite Web UI で、インフラストラクチャー > Capsule に移動し、ライフサイクルを追加する Capsule を選択します。
- 編集 をクリックしてから、ライフサイクル環境 タブをクリックします。
- 左のメニューから、Capsule に追加するライフサイクル環境を選択し、 送信 をクリックします。
- Capsule のコンテンツを同期するには、概要 タブをクリックしてから 同期 ボタンをクリックします。
- 最適化された同期 または 完全な同期 を選択します。
CLI をご利用の場合
Capsule Serverの全一覧を表示するには、以下のコマンドを入力します。
# hammer capsule list
返された ID をメモします。
その ID を使用して、Capsule Server の詳細を確認します。
# hammer capsule info --id capsule_id
利用可能なライフサイクル環境を確認し、環境 ID を書き留めます。
# hammer capsule content available-lifecycle-environments \ --id capsule_id
Capsule Server で利用可能なライフサイクル環境を表示するには、以下のコマンドを入力して、組織名と ID をメモします。
# hammer capsule content available-lifecycle-environments --id capsule_id
ライフサイクル環境を Capsule Server に追加します。
# hammer capsule content add-lifecycle-environment \ --id capsule_id --organization "My_Organization" \ --environment-id environment_id
Capsule Server に追加する各ライフサイクル環境に対して手順を繰り返します。
Satellite Server 環境のすべてのコンテンツを Capsule Server に同期するには、以下のコマンドを実行します。
# hammer capsule content synchronize --id capsule_id
Satellite Server 環境の特定のライフサイクル環境を Capsule Server と同期するには、以下のコマンドを実行します。
# hammer capsule content synchronize --id external_capsule_id \ --environment-id environment_id
3.4. 管理対象ホスト上での電源管理の有効化
Capsule Server でベースボード管理コントローラー (BMC) を有効にすると、IPMI (Intelligent Platform Management Interface) または類似したプロトコルを使用して管理対象ホストで電源管理コマンドを使用できます。
Satellite Capsule サーバー上の BMC サービスを使用すると、さまざまな電源管理タスクを実行できます。この機能の基礎となるプロトコルは IPMI です (BMC 機能とも呼ばれます)。IPMI は、ホストの CPU から独立して実行する専用プロセッサーに接続された管理対象ハードウェア上で、特別なネットワークインターフェースを使用します。多くのインスタンスでは、BMC 機能はシャーシ管理の一部としてシャーシベースのシステムに組み込まれます (シャーシの専用モジュール)。
BMC サービスの詳細は『ホストの管理』の「追加のネットワークインターフェースの設定」を参照してください。
作業開始前の準備
- すべての管理対象ホストに BMC タイプのネットワークインターフェースが搭載されている必要があります。Satellite はこの NIC を使用して適切な認証情報をホストに渡します。
管理対象ホスト上での電源管理の有効化
オプションを使用してインストーラーを実行し、BMC を有効にします。
# satellite-installer --scenario capsule \ --foreman-proxy-bmc "true" \ --foreman-proxy-bmc-default-provider "freeipmi"
3.5. Capsule Server で DNS、DHCP、および TFTP の設定
Capsule Server で DNS、DHCP、および TFTP を設定できます。
Capsule Server が外部 DNS および DHCP サービスを使用するよう設定することもできます。詳細については、「外部サービスの設定」を参照してください。
設定可能な全オプションを表示するには、satellite-installer --scenario capsule --help
コマンドを実行します。
作業開始前の準備
-
DNS サーバーの適切なネットワーク名 (
dns-interface
) が用意されている必要があります。 -
DHCP サーバーの適切なインターフェース名 (
dhcp-interface
) が用意されている必要があります。
Capsule Server での DNS、DHCP、および TFTP の設定
ご使用の環境に該当するオプションを使用して Capsule インストーラーを実行します。
以下の例は、完全なプロビジョニングサービスを示してます。
# satellite-installer --scenario capsule \ --foreman-proxy-dns true \ --foreman-proxy-dns-managed true \ --foreman-proxy-dns-interface eth0 \ --foreman-proxy-dns-zone example.com \ --foreman-proxy-dns-forwarders 172.17.13.1 \ --foreman-proxy-dns-reverse 13.17.172.in-addr.arpa \ --foreman-proxy-dhcp true \ --foreman-proxy-dhcp-managed true \ --foreman-proxy-dhcp-interface eth0 \ --foreman-proxy-dhcp-range "172.17.13.100 172.17.13.150" \ --foreman-proxy-dhcp-gateway 172.17.13.1 \ --foreman-proxy-dhcp-nameservers 172.17.13.2 \ --foreman-proxy-tftp true \ --foreman-proxy-tftp-managed true \ --foreman-proxy-tftp-servername $(hostname)
DHCP、DNS および TFTP サービスの情報は、『プロビジョニングガイド』の「ネットワークサービスの設定」セクションを参照してください。
3.6. カスタムサーバー証明書を使用した Capsule Server の設定
Red Hat Satellite 6 には、デフォルトの SSL 証明書が含まれており、Satellite Server、Capsule Server、およびすべてのホスト間で暗号化通信を可能にします。必要な場合は、デフォルト証明書をカスタム証明書に置き換えることができます。たとえば、会社のセキュリティーポリシーで、特定の認証局から SSL 証明書を取得する必要があると規定されている場合などです。
前提条件
- カスタムの証明書で設定した Satellite Server。詳しい情報は、『オンラインネットワークからの Satellite Server のインストール』の「カスタムサーバー証明書での Satellite Server の設定」を参照してください。
- インストールされ Satellite Server に登録された Capsule サーバー。詳細は「2章Capsule Server のインストール」を参照してください。
各 Capsule サーバー上のカスタム証明書を使用するには、以下の手順を実行します。
3.6.1. Capsule Server 向けの SSL 証明書の取得
SSL 証明書には、PEM エンコードを使用してください。
- 各サーバーの証明書は一意であるため、Satellite Server の証明書は Capsule Server で使用しないでください。
手順
Satellite Serve で、Capsule Server 向けのカスタム SSL 証明書を取得します。
root
ユーザーのみがアクセスできる、全ソース証明書ファイルの保存用のディレクトリーを作成します (例:/root/capsule_cert
)。# mkdir
/root/capsule_cert
これらの例では、ディレクトリーは
/root/capsule_cert
です。複数の Capsule Server がある場合は、ディレクトリー名をサーバー名と同じに指定します。たとえば、capsule_apac
とcapsule_emea
という名前の Capsule Server がある場合は、それぞれ capsule_apac と capsule_emea という名前のディレクトリーを作成すると良いでしょう。これは必須ではありませんが、特定の Capsule Server のファイルを別の Capsule Server で使用するリスクが軽減されます。証明書署名要求 (CSR) を署名する秘密鍵を作成します。
注記Capsule Server 向けの秘密鍵がすでにある場合は、この手順を省略します。
# openssl genrsa -out
/root/capsule_cert/capsule_cert_key.pem
4096証明書署名要求 (CSR) 用に
/root/sat_cert/openssl.cnf
設定ファイルを作成し、以下の内容を追加します。[ req_distinguished_name ]
セクションで、組織の情報を入力します。注記証明書の Common Name (CN) およびは Subject Alternative Name (SAN) の DNS.1 は、証明書を使用するサーバーの完全修飾ドメイン名 (FQDN) と同じでなければなりません。要求しているのが Satellite Server の証明書の場合には、これは Satellite Server の FQDN で、Capsule サーバーの証明書の場合には、Capsule サーバーの FQDN です。
サーバーの FQDN を確認するには、該当するサーバーでコマンド
hostname -f
を実行します。[ req ] req_extensions = v3_req distinguished_name = req_distinguished_name x509_extensions = usr_cert prompt = no [ req_distinguished_name ] C = Country Name (2 letter code) ST = State or Province Name (full name) L = Locality Name (eg, city) O = Organization Name (eg, company) OU = The division of your organization handling the certificate CN = capsule.example.com [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth, clientAuth, codeSigning, emailProtection subjectAltName = @alt_names [ usr_cert ] basicConstraints=CA:FALSE nsCertType = client, server, email keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, clientAuth, codeSigning, emailProtection nsComment = "OpenSSL Generated Certificate" subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer [ alt_names ] DNS.1 = capsule.example.com
証明書署名要求 (CSR) を作成します。
# openssl req -new \ -key /root/sat_cert/satellite_cert_key.pem \ -out /root/sat_cert/satellite_cert_csr.pem \ -config /root/sat_cert/openssl.cnf
証明局に証明書署名要求を送信します。同じ証明局が Satellite Server と Capsule Server の証明書に署名する必要があります。
要求を送信する場合は、証明書の有効期限を指定してください。証明書署名要求を送信する方法は異なるため、推奨の方法について認証局にお問い合わせください。要求への応答で、認証局バンドルと署名済み証明書を別々のファイルで受け取ることになります。
3.6.2. Capsule Server の SSL 証明書の検証
Satellite サーバーで、katello-certs-check
コマンドを使用して Capsule サーバーの証明書入力ファイルを検証します。このプロセスでは、Capsule Server の鍵、CSR、および SSL 証明書が Capsule Server から Satellite Server にコピーされている必要があります。
# katello-certs-check \ -c /root/capsule_cert/capsule_cert.pem \ 1 -k /root/capsule_cert/capsule_cert_key.pem \ 2 -b /root/capsule_cert/ca_cert_bundle.pem 3
証明書が正常に検証された場合、出力には以下の情報が含まれます。
Validation succeeded
katello-certs-check
コマンドの出力である capsule-certs-generate
コマンドをメモして、以下の手順で使用します。
3.6.3. Capsule サーバーの証明書アーカイブファイルの作成
Capsule サーバーのインストーラーでは、サーバーの証明書がアーカイブファイルで必要になります。このファイルを作成するには、Satellite Server で capsule-certs-generate
コマンドを使用します。
capsule-certs-generate
コマンドは、各外部 Capsule Server に対して 1 回だけ実行する必要があります。これらの例では、capsule.example.com
が FQDN の例であり、capsule_certs.tar
がアーカイブファイル名の例です。これらを、ご使用の環境に適切な値に置き換えます。既存の証明書アーカイブファイルを上書きしないように注意してください。たとえば、capsule1
と capsule2
という名前の Capsule Server がある場合は、証明書アーカイブファイルの名前として capsule1_certs.tar
と capsule2_certs.tar
を指定できます。
Satellite Server で実行すると、パラメーターなど capsule-certs-generate
コマンドが katello-certs-check
で出力されます。詳しい情報は、『オンラインネットワークからの Satellite Server のインストール』の「カスタムサーバー証明書での Satellite Server の設定」を参照してください。
-
エディターで
capsule-certs-generate
コマンドのコピーを準備します。 -
Capsule Server の FQDN に一致するよう
--foreman-proxy-fqdn
の値を編集し、証明書アーカイブファイルのファイルパスおよび名前に一致するよう--certs-tar
の値を編集します。 -
Capsule Server をインストールしていない場合は、
--certs-update-server
パラメーターを削除します。これは、既存の Capsule Server の証明書を更新するためにのみ使用されます。 -
編集した
capsule-certs-generate
コマンドをテキストエディターから端末にコピーします。 編集した
capsule-certs-generate
コマンドを実行します。capsule-certs-generate
コマンドの例# capsule-certs-generate --foreman-proxy-fqdn capsule.example.com \ --certs-tar /root/capsule_cert/capsule_certs.tar \ --server-cert /root/capsule_cert/capsule_cert.pem \ --server-key /root/capsule_cert/capsule_cert_key.pem \ --server-ca-cert /root/sat_cert/ca_cert_bundle.pem \ --certs-update-server
Satellite サーバーで、証明書アーカイブファイルを Capsule サーバーにコピーします。要求された場合は
root
ユーザーのパスワードを提供します。この例では、アーカイブファイルを
root
ユーザーのホームディレクトリーにコピーしていますが、別の場所にコピーすることもできます。# scp /root/capsule_cert/capsule_certs.tar root@capsule.example.com:
capsule-certs-generate
コマンドの出力である satellite-installer
コマンドをメモして、以下の手順で使用します。
3.6.4. Capsule Server のカスタム証明書のインストール
この手順は、Capsule サーバーで完了してください。
Capsule サーバーのカスタム証明書をインストールするには、satellite-installer
スクリプトをカスタムパラメーターで実行します。コマンドとパラメーターは、「Capsule サーバーの証明書アーカイブファイルの作成」のcapsule-certs-generate
コマンドで得た出力を使用します。
-
エディターで
satellite-installer
コマンドのコピーを準備をします。 -
--foreman-proxy-content-certs-tar
の値を、証明書アーカイブファイルの場所に変更します。 -
Capsule サーバーで追加機能を有効にする場合は、それらのパラメーターを
satellite-installer
コマンドに追加します。インストーラーの全パラメーターを確認するには、satellite-installer --scenario capsule --help
コマンドを実行してください。 -
編集した
satellite-installer
コマンドをテキストエディターから端末にコピーします。 編集した
satellite-installer
コマンドを実行します。カスタム
satellite-installer
コマンドの例# satellite-installer --scenario capsule \ --foreman-proxy-content-parent-fqdn "satellite.example.com" \ --foreman-proxy-register-in-foreman "true" \ --foreman-proxy-foreman-base-url "https://satellite.example.com" \ --foreman-proxy-trusted-hosts "satellite.example.com" \ --foreman-proxy-trusted-hosts "capsule.example.com" \ --foreman-proxy-oauth-consumer-key "FeQsbASvCjvvaqE6duKH6SoYZWg4jwjg" \ --foreman-proxy-oauth-consumer-secret "7UhPXFPDBongvdTbNixbsWR5WFZsKEgF" \ --foreman-proxy-content-certs-tar "/root/capsule_certs.tar" \ --puppet-server-foreman-url "https://satellite.example.com"
satellite-installer
コマンドの値は、capsule-certs-generate
コマンドの出力からも分かるように、各 Capsule Server に対して一意です。したがって、複数の Capsule Server で同じコマンドを使用しないでください。
証明書が関連するすべてのホストにデプロイされた後であっても、証明書アーカイブファイル (.tar ファイル) は削除しないでください。このファイルは、Capsule サーバーをアップグレードする場合などに必要になります。インストーラーで証明書アーカイブファイルが検出されない場合は、以下のようなメッセージが表示されて失敗します。
[ERROR YYYY-MM-DD hh:mm:ss main] tar -xzf /var/tmp/srvcapsule01.tar returned 2 instead of one of [0]
3.6.5. すべてのホストへの Capsule Server の新しい証明書のインストール
外部の Capsule サーバーに接続するホストにはサーバーのカスタム証明書が必要です。すべての Capsule サーバーのホストで以下のコマンドを実行します。
Satellite Server のホスト名ではなく、Capsule サーバーのホスト名を使用します。
# yum -y localinstall \
http://capsule.example.com/pub/katello-ca-consumer-latest.noarch.rpm
3.7. mongod へのアクセスの制限
データ損失の危険を減らすために、MongoDB データベースデーモン mongod
へのアクセスは apache
ユーザーと root
ユーザーにだけ許可する必要があります。
Satellite Server と Capsule Server で mongod
へのアクセスを制限するには、以下のコマンドを使用します。
ファイヤーウォールを設定します。
# firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 27017 -m owner --uid-owner apache -j ACCEPT \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 27017 -m owner --uid-owner apache -j ACCEPT \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 27017 -m owner --uid-owner root -j ACCEPT \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 27017 -m owner --uid-owner root -j ACCEPT \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -o lo -p \ tcp -m tcp --dport 27017 -j DROP \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 1 -o lo -p \ tcp -m tcp --dport 27017 -j DROP \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 28017 -m owner --uid-owner apache -j ACCEPT \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 28017 -m owner --uid-owner apache -j ACCEPT \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 28017 -m owner --uid-owner root -j ACCEPT \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 0 -o lo -p \ tcp -m tcp --dport 28017 -m owner --uid-owner root -j ACCEPT \ && firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -o lo -p \ tcp -m tcp --dport 28017 -j DROP \ && firewall-cmd --direct --add-rule ipv6 filter OUTPUT 1 -o lo -p \ tcp -m tcp --dport 28017 -j DROP
変更を永続化します。
# firewall-cmd --runtime-to-permanent