クライアントのトラブルシューティング

1. 自動インストール

ベースチャンネルによっては、新しい自動インストールプロファイルは、必要なパッケージがないチャンネルにサブスクライブされる場合があります。

自動インストールを動作させるには、次のパッケージが必要です。

  • pyOpenSSL

  • rhnlib

  • libxml2-python

  • spacewalk-koan

この問題を解決するには、まず次の点について確認してください。

  • 自動インストールプロファイルのベースチャンネルに関するツールソフトウェアチャンネルを組織およびユーザーで使用できることを確認します。

  • ツールチャンネルが子チャンネルとしてSUSE Managerで使用できることを確認します。

  • 関連するチャンネルで、必要なパッケージと依存関係が使用可能であることを確認します。

2. ベアメタルシステム

ネットワークのベアメタルシステムが［システム］リストに自動的に追加されない場合、まず次の点について確認してください。

  • pxe-default-imageパッケージがインストールされている必要があります。

  • ファイルのパスおよびパラメータが正しく設定されている必要があります。rhn.conf設定ファイルで指定された場所に、pxe-default-imageで提供されるvmlinuz0ファイルとinitrd0.imgファイルがあることを確認します。

  • ベアメタルシステムをSUSE Managerサーバに接続するネットワーク機器が正しく動作していて、そのサーバからSUSE ManagerサーバのIPアドレスにアクセスできることを確認します。

  • プロビジョニングするベアメタルシステムは、ブートシーケンスでPXEブートが有効になっている必要があり、オペレーティングシステムをブートしていない必要があります。

  • DHCPサーバは、ブート中にDHCPリクエストに応答する必要があります。PXEブートメッセージで次の点を確認してください。

    • DHCPサーバが目的のIPアドレスを割り当てている。

    • DHCPサーバがSUSE ManagerサーバのIPアドレスをブート用にnext-serverとして割り当てている。

  • Cobblerが実行中であり検出機能が有効なことを確認してください。

ブート後すぐに青いCobblerメニューが表示される場合、検出が開始されています。 正常に完了しない場合、自動シャットダウンを一時的に無効にして、問題の診断に活用してください。自動シャットダウンを無効にするには:

  1. Cobblerメニューで矢印キーを使用してpxe-default-profileを選択し、タイマーが切れる前にTabキーを押します。

  2. カーネルブートパラメータspacewalk-finally=runningを追加します。そのためには、統合されたエディタを使用します。その後、Enterキーを押してブートを続行します。

  3. ユーザ名をroot、パスワードをlinuxにしてシェルに入力し、デバッグを続行します。

重複プロファイル

技術的な制約により、新しいベアメタルシステムを以前に検出されたシステムと高い信頼性で区別することはできません。 したがって、ベアメタルシステムの電源を複数回オンにしないことをお勧めします。この操作を実行するとプロファイルの重複が発生します。

3. サポートが終了したCentOS 6クライアントのブートストラップ

CentOS 6はサポート終了になっており、このオペレーティングシステム用にクライアントリポジトリで提供されるイメージは失効しています。 これらのパッケージを使用した新しいCentOS 6クライアントのブートストラップは失敗します。 この障害は、インストールおよびブートストラップが完了しているCentOS 6クライアントでは発生しません。

新しいCentOS 6クライアントをブートストラップする必要がある場合、既存のリポジトリを編集し、正しいURLを反映します。

プロシージャ: 新しいCentOS 6クライアントのブートストラップのトラブルシューティング

  1. CentOS 6クライアントのコマンドプロンプトで、CentOS-Base.repoファイルを開きます。このファイルは/etc/yum.repos.d/ディレクトリにあります。

  2. mirrorlistエントリを見つけます。これはmirrorlist.centos.orgを指しています。 エントリは複数存在する可能性があります。 次に例を示します。

    mirrorlist=http://mirrorlist.centos.org/?release=6&arch=$basearch&repo=os

  3. mirrorlistエントリをコメントアウトし、パッケージマネージャがURLを探さないようにします。

  4. baseurl行を編集し、vault.centos.org URLを指すようにし、CentOS 6のリポジトリを指定します。 次に例を示します。

    baseurl=https://vault.centos.org/centos/6/os/$basearch/

  5. ファイルでリストされている各リポジトリで繰り返します。

  6. クライアントをブートストラップします。 CentOSクライアントのブートストラップの詳細については、CentOSクライアントの登録を参照してください。

CentOS 6のサポート終了の詳細については、http://mirror.centos.org/centos/6/readmeを参照してください。

4. サポート終了製品のブートストラップリポジトリ

サポートされている製品を同期するとき、ブートストラップリポジトリは、自動的に作成され、SUSE Managerサーバに再生成されます。 製品がサポート終了になり、サポートされなくなったが、製品の使用を継続する場合、ブートストラップリポジトリを手動で作成する必要があります。

ブートストラップリポジトリの詳細については、ブートストラップリポジトリを参照してください。

プロシージャ: サポート終了製品のブートストラップリポジトリの作成

  1. SUSE Managerサーバのコマンドプロンプトで、rootとして、 --forceオプションを指定して使用可能なサポート対象外のブートストラップリポジトリの一覧を表示してください。たとえば下記のようになります:

    mgr-create-bootstrap-repo --list --force
1. SLE-11-SP4-x86_64
2. SLE-12-SP2-x86_64
3. SLE-12-SP3-x86_64

  2. 製品ラベルとして適切なリポジトリ名を使用して、ブートストラップリポジトリを作成します。

    mgr-create-bootstrap-repo --create SLE-12-SP2-x86_64 --force

ブートストラップリポジトリを手動で作成しない場合、必要な製品およびブートストラップリポジトリでLTSSが使用できるかどうかを確認できます。

5. 複製したSaltクライアント

ハイパーバイザ複製ユーティリティを使用していて、複製したSaltクライアントを登録しようすると、次のエラーが発生します。

残念ながら、このシステムは見つかりませんでした。

新しい複製システムのマシンIDが既存の登録済みシステムのマシンIDと同じことが原因です。 マシンIDを手動で調整してエラーに対処すると、複製したシステムを正常に登録できます。

詳細および手順については、Troubleshooting Registering Cloned Clientsを参照してください。

6. FQDNS grainの無効化

FQDNS grainは、システムのすべての完全修飾DNSサービスのリストを返します。 この情報の収集は、通常、高速プロセスですが、DNS設定が間違っていると、長時間かかる可能性があります。 場合によっては、クライアントが無応答またはクラッシュする場合があります。

この問題を回避するには、Saltフラグを使用してFQDNS grainを無効にできます。 grainを無効にした場合、ネットワークモジュールを使用して、FQDNSサービスを提供できます。この場合、クライアントが無応答になるリスクはありません。

この操作は、古いSaltクライアントにのみ適用されます。 最近Saltクライアントを登録した場合、FQDNS grainはデフォルトで無効になっています。

SUSE Managerサーバのコマンドプロンプトで、次のコマンドを使用してFQDNS grainを無効にします。

salt '*' state.sls util.mgr_disable_fqdns_grain

このコマンドを実行すると、各クライアントが再起動され、サーバが処理する必要があるSaltイベントが生成されます。 クライアント数が多い場合、バッチモードでコマンドを実行できます。

salt --batch-size 50 '*' state.sls util.mgr_disable_fqdns_grain

バッチコマンドの実行完了を待機します。 Ctrl+Cでプロセスを中断しないでください。

7. noexecで/tmpをマウントする

Saltはクライアントのファイルシステム上の/tmpからリモートコマンドを実行します。 したがって、noexecオプションを指定して/tmpをマウントしないでください。 この問題を解決する別の方法は、一時ディレクトリパスをSaltサービスに指定されたTMPDIR環境変数で上書きして、noexecオプションが設定されていないディレクトリを指すようにすることです。 Salt Bundleを使用する場合はsystemdドロップイン設定ファイル/etc/systemd/system/venv-salt-minion.service.d/10-TMPDIR.confを使用し、クライアントでsalt-minionを使用する場合は/etc/systemd/system/salt-minion.service.d/10-TMPDIR.confを使用することをお勧めします。 ドロップイン設定ファイルの内容の例を次に示します。

[Service]
Environment=TMPDIR=/var/tmp

8. noexecで/var/tmpをマウントする

Salt SSHは、/var/tmpを使用して、Salt Bundleを配備し、バンドルされたPythonを使用してクライアント上でSaltコマンドを実行しています。 したがって、noexecオプションを指定して/var/tmpをマウントしないでください。 ブートストラッププロセスがクライアントに到達するためにSalt SSHを使用しているため、/var/tmpがnoexecオプションでマウントされたクライアントをWeb UIでブートストラップすることはできません。

9. grainを渡してイベントを開始する

Saltクライアントは、起動するたびに、machine_id grainをSUSE Managerに渡します。SUSE Managerは、このgrainを使用して、クライアントが登録されたかどうかを判定します。 このプロセスでは、同期Saltコールが必要です。同期Saltコールは、その他のプロセスをブロックするため、多数のクライアントを同時に起動する場合、大幅な遅延が発生する可能性があります。

この問題を克服するために、別々のSaltコールを回避するための新しい機能がSaltに導入されました。

この機能を使用するには、この機能をサポートしているクライアントのクライアント設定に設定パラメータを追加できます。

このプロセスを簡単にするには、mgr_start_event_grains.slsヘルパーSaltの状態を使用します。

この操作は、登録済みのクライアントにのみ適用されます。 最近Saltクライアントを登録した場合、この設定パラメータはデフォルトで追加されています。

SUSE Managerサーバのコマンドプロンプトで、次のコマンドを使用してstart_event_grains設定ヘルパーを有効にします。

salt '*' state.sls util.mgr_start_event_grains

このコマンドを実行すると、必要な設定がクライアントの設定ファイルに追加され、クライアントを再起動したときに適用されます。 クライアント数が多い場合、バッチモードでコマンドを実行できます。

salt --batch-size 50 '*' state.sls mgr_start_event_grains

10. プロキシの接続およびFQDN

プロキシ経由で接続されているクライアントがWeb UIに表示されることがありますが、そのようなクライアントがプロキシ経由で接続されていることは示されません。 完全修飾ドメイン名(FQDN)を使用して接続していない場合、SUSE Managerでプロキシが認識されないと、この動作が発生することがあります。

この動作を修正するには、プロキシのクライアント設定ファイルでgrainとして追加のFQDNを指定します。

grains:
  susemanager:
     custom_fqdns:
       - name.one
       - name.two

11. Red Hat CDNチャンネルと複数の証明書

Red Hatコンテンツデリバリネットワーク(CDN)チャンネルは複数の証明書を提供することがありますが、SUSE Manager Web UIは単一の証明書しかインポートできません。 CDNがSUSE Manager Web UIで認識されている証明書とは異なる証明書を提示した場合、証明書が正確であっても検証が失敗し、リポジトリへのアクセスパーミッションが拒否されます。 次のようなエラーメッセージが生じます。

[error]（[エラー]）
Repository '<repo_name>' is invalid.（リポジトリ'<repo_name>'は無効です。）
<repo.pem> Valid metadata not found at specified URL（有効なメタデータが指定されているURLで見つかりませんでした）
History:（履歴:）
 - [|] Error trying to read from '<repo.pem>'（'<repo.pem>'からの読み込み時にエラーが発生しました）
 - Permission to access '<repo.pem>' denied.（'<repo.pem>'へのアクセスが拒否されました。）
Please check if the URIs defined for this repository are pointing to a valid repository.（このリポジトリ用に定義されているURIが有効なリポジトリを指しているかどうかを確認してください。
Skipping repository '<repo_nam' because of the above error.（上記エラーのため、リポジトリ'<repo_name>'をスキップします。）
Could not refresh the repositories because of errors.（エラーが発生したため、リポジトリを更新できませんでした。）
HH:MM:SS RepoMDError: Cannot access repository. Maybe repository GPG keys are not imported（HH:MM:SS RepoMDError: リポジトリにアクセスできません。リポジトリGPGキーがインポートされていない可能性があります）

この問題を解決するには、すべての有効な証明書を1つの.pemファイルにマージし、SUSE Managerで使用する証明書を再作成します。

手順: 複数のRed Hat CDN証明書の解決

  1. Red Hat クライアントのコマンドプロンプトで、rootとして、/etc/pki/entitlement/からすべての現行の証明書を単一の rh-cert.pemファイルに収集します。

    cat 866705146090697087.pem 3539668047766796506.pem redhat-entitlement-authority.pem > rh-cert.pem

  2. /etc/pki/entitlement/からすべての現行のキーを単一のrh-key. pemファイルに収集します。

    cat 866705146090697087-key.pem 3539668047766796506-key.pem > rh-key.pem

次に、CDNでRed Hat Enterprise Linuxクライアントを登録するの手順に従って、新しい証明書をSUSE Managerサーバにインポートできます。

12. Web UIからの登録は失敗するが、エラーが表示されない

Web UIからの初期登録では、すべてのSaltクライアントがSalt SSHを使用しています。

その性質上、Salt SSHクライアントはサーバにエラーを報告しません。

ただし、Salt SSHクライアントは、エラーを検査できるログを/var/log/salt-ssh.logにローカルに保存します。

13. 古いクライアントの登録

CentOS 6、 Oracle Linux 6、Red Hat Enterprise Linux 6、SUSE Linux Enterprise Server with Expanded Support 6、またはSUSE Linux Enterprise Server11の各クライアントを登録して使用するには、 SUSE Manager サーバを設定して旧式のSSL暗号化をサポートする必要があります。

コマンドプロンプトで登録しようすると、次のような内容を示すエラーが発生します。

Repository '<Repository_Name>' is invalid.
（リポジトリ'<Repository_Name>'は無効です。）
[|] Valid metadata not found at specified URL(s)
Please check if the URIs defined for this repository are pointing to a valid repository.
（有効なメタデータが指定されているURLで見つかりませんでした。
このリポジトリ用に定義されているURIが有効なリポジトリを指しているかどうかを確認してください。
）Skipping repository '<Repository_Name>' because of the above error.
（上記のエラーのため、リポジトリ'<Repository_Name>'をスキップします。
）Download (curl) error for 'www.example.com':（'www.example.com'に(curl)エラーをダウンロードします:
）Error code:（エラーコード:）Unrecognized error
Error message: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version
（認識できないエラー
エラーメッセージ: エラー:1409442E:SSLルーチン:SSL3_READ_BYTES:tlsv1 警告プロトコルバージョン）

Web UIで登録しようすると、次のような内容を示すエラーが発生します。

Rendering SLS 'base:bootstrap' failed:（SLS 'base:bootstrap'のレンダリングに失敗しました:）Jinja error:（Jinjaエラー:）>>> No TLS 1.2 and above for RHEL6 and SLES11.（>>> RHEL6およびSLES11ではTLS 1.2以降は使用できません。）Please check your Apache config.（Apache設定を確認してください。）
...

ApacheではTLS v1.2を必要とするため、この動作が発生しますが、古いオペレーティングシステムは、このバージョンのTLSプロトコルをサポートしていません。 このエラーを修正するには、サーバ上のApacheが広範なプロトコルバージョンを受け入れる必要があります。 SUSE Managerサーバでrootとして/etc/apache2/ssl-global.conf設定ファイルを開き、SSLProtocol行を検索し、次のように更新します。

SSLProtocol all -SSLv2 -SSLv3

この操作は、サーバ上で手動で実行する必要があります。その際、該当する場合には、プロキシでSaltの状態にします。 変更後、各システムでapacheサービスを再起動します。

14. ダウンとして表示されるSaltクライアントおよびDNS設定

Saltクライアントが実行されている場合でも、パッケージの更新や状態の適用などのアクションは、次のメッセージで失敗としてマークされる可能性があります。

Minionがダウンしているか、接続できませんでした。

この場合、アクションのスケジュールを変更してみてください。スケジュールの変更が成功した場合、問題の原因はDNS設定の誤りである可能性があります。

Saltクライアントが再起動されたとき、またはグレインが更新された場合、クライアントはFQDNグレインを計算し、グレインが続行されるまで応答しません。SUSE Managerサーバでスケジュールされたアクションが実行される場合、SUSE Managerサーバは、実際のアクションの前にクライアントに対してtest.pingを実行して、クライアントが実際に実行され、アクションをトリガできることを確認します。

デフォルトでは、SUSE Managerサーバはtest.pingコマンドからの応答を取得するために5秒間待機します。5秒以内に応答が受信されない場合、アクションは失敗に設定され、クライアントがダウンしているか、接続できなかったというメッセージが表示されます。

これを修正するには、クライアントのDNS解決を修正して、クライアントがFQDNの解決中に5秒間スタックしないようにします。

これができない場合は、SUSE Managerサーバ上の/etc/rhn/rhn.confファイルのjava.salt_presence_ping_timeoutの値を4より大きい値に増やしてみてください。

例:

java.salt_presence_ping_timeout = 6

その後、次のコマンドを使用してspacewalk-servicesを再起動します。

spacewalk-services restart

この値を大きくすると、minionに到達できないのかminionが応答しないのかをSUSE Managerサーバが確認するのに時間がかかり、SUSE Managerサーバの全体的な速度が低下したり応答しなくなったりします。

15. Salt 3000からSalt Bundleへの移行

15.1. SUSE Linux Enterprise Server 12、Red Hat Enterprise Linux 7、またはCentOS 7 minions (Salt 3000 EOL)をSalt Bundleに切り替える

プロシージャ: util.mgr_switch_to_venv_minionを使用して状態をvenv-salt-minionに切り替える

  1. まず、pillarを指定せずにutil.mgr_switch_to_venv_minionを適用します。 venv-salt-minionに切り替わり、etcに設定ファイルがコピーされます。 元のsalt-minionの設定およびそのパッケージはクリーンアップされません。

    salt <minion_id> state.apply util.mgr_switch_to_venv_minion

  2. util.mgr_switch_to_venv_minionを適用し、mgr_purge_non_venv_saltをTrueに設定してsalt-minionを削除し、mgr_purge_non_venv_salt_filesをTrueに設定してsalt-minionに関するすべてのファイルを削除します。 この2番目の手順によって、最初の手順が処理されたことが保証され、古い設定ファイルおよび古くなったsalt-minionパッケージが削除されます。

    salt <minion_id> state.apply util.mgr_switch_to_venv_minion pillar='{"mgr_purge_non_venv_salt_files": True, "mgr_purge_non_venv_salt": True}'

15.2. SUSE Linux Enterprise Server 12、Red Hat Enterprise Linux 7、またはCentOS 7 SSH minions (Salt 3000 EOL)をSalt Bundleに切り替える

プロシージャ: Salt SSHをサポートするSalt Bundleを有効にする

  1. /etc/rhn/rhn.confで次の行を指定します。

    web.ssh_salt_pre_flight_script = /usr/share/susemanager/salt-ssh/preflight.sh

web.ssh_use_salt_thin = false

  2. ssh_run_pre_flightをtrueに設定して、Salt Master /etc/salt/master.d/ssh-preflight.confの追加のドロップイン設定ファイルを作成します。

    ssh_run_pre_flight: true

  3. spacewalk-service restartを使用してサービスを再起動します。