40 サポート用システム情報の収集 #
マシンに関連するすべてのシステム情報の概要をすばやく参照できるよう、SUSE Linux Enterprise Serverではhostinfo
パッケージが提供されています。このパッケージは、システム管理者が汚染カーネル(サポートされていません)やサードパーティパッケージがマシンにインストールされていないかどうかを確認する場合にも役立ちます。
問題がある場合は、supportconfig
コマンドラインツールまたはYaST モジュールで詳細なシステムレポートを作成できます。どちらも、現在のカーネルのバージョン、ハードウェア、インストールされているパッケージ、パーティションセットアップなどのシステム情報を収集します。結果は、複数のファイルのTARアーカイブになります。サービス要求(SR)を開いた後、そのTARアーカイブをグローバルテクニカルサポートにアップロードできます。これは、レポートされた問題を特定したり、問題解決を支援したりするのに役立ちます。
また、既知の問題がないかどうかsupportconfig
の出力を分析することで、問題解決を迅速化できます。このために、SUSE Linux Enterprise Serverでは、Supportconfig Analysis
(SCA)用のアプライアンスとコマンドラインツールの両方が提供されています。
40.1 現在のシステム情報の表示 #
サーバへのログイン時に関連するすべてのシステム情報をすばやく簡単に参照するには、パッケージhostinfo
を使用します。このパッケージをマシンにインストールすると、そのマシンにログインしたすべてのroot
ユーザに対して、コンソールに次の情報が表示されます。
root
としてログインしたときのhostinfo
の出力 #Hostname: earth Current As Of: Fri 28 Sep 2018 03:18:57 PM CEST Distribution: SUSE Linux Enterprise Server 12 -Service Pack: 4 Architecture: x86_64 Kernel Version: 4.12.14-94.37-default -Installed: Mon 24 Sep 2018 10:43:46 AM CEST -Status: Not Tainted Last Updated Package: Fri 28 Sep 2018 03:18:55 PM CEST -Patches Needed: 0 -Security: 0 -3rd Party Packages: 0 IPv4 Address: eth0 192.168.1.1 Total/Free/+Cache Memory: 1812/360/1275 MB (70% Free) Hard Disk: /dev/sda 32 GB
この出力でカーネルのステータスがtainted
と表示される場合、詳細については、40.6項 「カーネルモジュールのサポート」を参照してください。
40.2 Supportconfigによるシステム情報の収集 #
グローバルテクニカルサポートに提出できる詳細なシステム情報のTARアーカイブを作成するには、supportconfig
コマンドラインツールまたはYaST モジュールを使用します。このコマンドラインツールは、デフォルトでインストールされるパッケージsupportutils
によって提供されます。YaST モジュールも、このコマンドラインツールが基になっています。
40.2.1 サービス要求番号の作成 #
Supportconfigアーカイブはいつでも生成できます。ただし、supportconfigデータをグローバルテクニカルサポートに提出するには、まずサービス要求番号を生成する必要があります。サービス要求番号はアーカイブをサポートにアップロードするために必要です。
サービス要求を作成するには、https://scc.suse.com/support/requestsにアクセスして、画面の指示に従います。12桁のサービス要求番号を記録します。
SUSEおよびMicro Focusは、システムレポートを機密データとして扱います。プライバシーに関する取り組みの詳細については、https://www.suse.com/company/policies/privacy/を参照してください。
40.2.2 YaSTでのSupportconfigアーカイブの作成 #
YaSTでシステム情報を収集するには、次の手順に従います。
YaSTを起動して、
モジュールを開きます。次のウィンドウで、ラジオボタンリストからsupportconfigオプションを1つ選択します。デフォルトでは、
があらかじめ選択されています。最初にレポート機能をテストしたい場合は、 を使用します。その他のオプションに関する背景情報については、supportconfig
のマニュアルページを参照してください。連絡先情報を入力します。情報は
basic-environment.txt
という名前のファイルに書き込まれ、作成するアーカイブに組み込まれます。情報収集プロセスの終了時にアーカイブをグローバルテクニカルサポートに送信する場合、
に入力する必要があります。YaSTによって自動的にアップロードサーバが提案されます。アーカイブを後で送信する場合、
は空白のままで構いません。情報の収集が開始します。
プロセスが完了したら、
で続行します。データ収集を確認します。ログファイルのファイル名を
で選択して、YaSTで内容を表示します。サポートへの送信前にTARアーカイブから除外したいファイルを削除するには、 を使用します。 で続行します。TARアーカイブを保存します。YaSTモジュールを
root
ユーザとして起動した場合、デフォルトではアーカイブを/var/log
に保存するよう提案されます(そうでない場合はホームディレクトリ)。ファイル名の形式は、nts_HOST_DATE_TIME.tbz
です。アーカイブをサポートに直接アップロードする場合は、ステップ 5でYaSTによって提案されたものです。
が有効になっていることを確認してください。ここに表示される は、アップロードをスキップする場合は、
を無効にします。変更内容を確認し、YaSTモジュールを閉じます。
40.2.3 コマンドラインからのsupportconfigアーカイブの作成 #
次の手順は、supportconfigアーカイブをサポートに直接送信せずにアーカイブを作成する方法を示しています。アーカイブをアップロードするには、特定のオプションを指定してコマンドを実行する必要があります。手順40.2「コマンドラインからのサポートへの情報の送信」を参照してください。
シェルを開き
root
になります。オプションなしで
supportconfig
を実行します。デフォルトのシステム情報が収集されます。ツールが操作を完了するまで待機します。
デフォルトのアーカイブ場所は
/var/log
で、ファイル名の形式はnts_HOST_DATE_TIME.tbz
です。
40.2.4 Supportconfigの一般的なオプション #
supportconfig
ユーティリティは、通常、オプションなしで呼び出されます。supportconfig
‑h
で、すべてのオプションを一覧表示するか、マニュアルページを参照してください。よくある使用事例については、次のリストで簡単に説明します。
- 収集する情報のサイズを削減する
最小オプション(
-m
)を使用します。supportconfig -m
- 情報を特定のトピックに限定する
すでにデフォルトの
supportconfig
出力で問題を特定し、その問題が特定の領域または機能セットにのみ関係することが判明している場合は、supportconfig
の次回実行時に収集する情報を特定の領域に限定する必要があります。たとえば、LVMに問題があることを検出した場合に、最近変更したLVMの設定をテストしたいときは、LVMに関連する最小限のsupportconfig情報のみを収集するのが適切です。supportconfig -i LVM
収集する情報を特定の領域に限定する場合に使用できる機能のキーワードを網羅したリストについては、次のコマンドを実行します。
supportconfig -F
- 追加の連絡先情報を出力に含める
supportconfig -E tux@example.org -N "Tux Penguin" -O "Penguin Inc." ...
(すべてを1行に記述)
- ローテーション済みログファイルの収集
supportconfig -l
これは、大規模なログを行う環境や、再起動後のsyslogによるログファイルのローテーション時にカーネルクラッシュが発生した場合に特に有効です。
40.3 グローバルテクニカルサポートへの情報の送信 #
システム情報をグローバルテクニカルサポートへ送信するには、YaSTsupportconfig
コマンドラインユーティリティを使用します。サーバに問題がありサポートの支援が必要な場合、まずサービス要求を開く必要があります。詳細については、40.2.1項 「サービス要求番号の作成」を参照してください。
次の例では、実際のサービス要求番号のプレースホルダとして12345678901を使用しています。12345678901は、40.2.1項 「サービス要求番号の作成」で作成したサービス要求番号に置き換えてください。
次の手順は、supportconfigアーカイブを作成済みであるものの、まだアップロードしていないことを想定しています。40.2.2項 「YaSTでのSupportconfigアーカイブの作成」のステップ 4で説明されているように、アーカイブに連絡先情報が含まれていることを確認してください。supportconfigアーカイブの生成と送信を一度に行う方法については、40.2.2項 「YaSTでのSupportconfigアーカイブの作成」を参照してください。
YaSTを起動して、
モジュールを開きます。既存のsupportconfigアーカイブのパスを
に指定するか、 をクリックしてアーカイブを参照します。YaSTによって自動的にアップロードサーバが提案されます。
次の手順は、supportconfigアーカイブを作成済みであるものの、まだアップロードしていないことを想定しています。supportconfigアーカイブの生成と送信を一度に行う方法については、40.2.2項 「YaSTでのSupportconfigアーカイブの作成」を参照してください。
インターネット接続のあるサーバの場合
デフォルトのアップロードターゲットを使用するには、次を実行します。
supportconfig -ur 12345678901
安全なアップロードターゲットには、次を使用します。
supportconfig -ar 12345678901
インターネット接続のないサーバの場合
次を実行します。
supportconfig -r 12345678901
/var/log/nts_SR12345678901
*tbzアーカイブをいずれかのFTPサーバに手動でアップロードします。詳細については、supportconfig
のマニュアルページを参照してください。
FTPサーバの着信ディレクトリにTARアーカイブが届くと、お客様のサービス要求に自動的に添付されます。
40.4 システム情報の分析 #
supportconfig
で作成したシステムレポートで既知の問題がないかどうかを分析すると、問題の早期解決に役立ちます。このために、SUSE Linux Enterprise Serverでは、Supportconfig Analysis
(SCA)用のアプライアンスとコマンドラインツールの両方が提供されています。SCAアプライアンスは非対話型のサーバサイドツールです。SCAツール(scatool
)はクライアント側で動作し、コマンドラインから実行します。どちらのツールも、関係するサーバからのsupportconfigアーカイブを分析します。サーバでの初回の分析は、SCAアプライアンス、またはscatoolが実行されているワークステーションで行われます。分析サイクルは運用サーバ上では実行されません。
アプライアンスとコマンドラインツールのどちらにも、関連する製品のsupportconfig出力を分析できるようにする製品固有のパターンが追加で必要になります。各パターンは、特定の既知の問題がないかどうかsupportconfigアーカイブを解析して評価するスクリプトです。パターンはRPMパッケージとして提供されます。
たとえば、SUSE Linux Enterprise 11マシン上で生成されたsupportconfigアーカイブを分析する場合は、SCAツールとともに(またはSCAアプライアンスサーバとして使用するマシン上に)パッケージsca-patterns-sle11
をインストールする必要があります。SUSE Linux Enterprise 10マシン上で生成されたsupportconfigアーカイブを分析するには、パッケージsca-patterns-sle10
が必要です。
独自のパターンを開発することもできます。これについては、40.4.3項 「カスタム分析パターンの開発」で簡単に説明されています。
40.4.1 SCAコマンドラインツール #
SCAコマンドラインツールでは、supportconfig
と、ローカルマシンにインストールされている特定の製品用の分析パターンの両方を使用してローカルマシンを分析できます。分析結果を示すHTMLレポートが作成されます。例については、図40.1「SCAツールによって生成されるHTMLレポート」を参照してください。
scatool
コマンドはsca-server-report
パッケージで提供されます。デフォルトではインストールされません。さらに、sca-patterns-base
パッケージ、およびscatool
コマンドを実行するマシンにインストールされている製品に一致する製品固有のsca-patterns-*
パッケージも必要です。
scatool
コマンドは、root
ユーザとして実行するか、sudo
を使用して実行します。SCAツールを呼び出すときに、既存のsupportconfig
TARアーカイブを分析するか、新しいアーカイブの生成と分析を同時に行うことができます。このツールは対話型コンソール(タブ補完機能を使用)も備えており、supportconfig
を外部マシンで実行したり、それ以降の分析をローカルマシンで実行したりできます。
次に、コマンドの例をいくつか示します。
sudo scatool
-s
supportconfig
を呼び出し、ローカルマシン上に新しいsupportconfigアーカイブを生成します。インストール済み製品に一致するSCA分析パターンを適用して、既知の問題がないかどうかアーカイブを分析します。分析結果から生成されたHTMLレポートのパスが表示されます。レポートは通常、supportconfigアーカイブのあるディレクトリと同じディレクトリに書き込まれます。sudo scatool
-s
-o
/opt/sca/reports/sudo scatool
-s
と同じですが、HTMLレポートは-o
で指定したパスに書き込まれる点が異なります。sudo scatool
-a
PATH_TO_TARBALL_OR_DIR指定したsupportconfigアーカイブファイル(またはsupportconfigアーカイブの展開先の指定ディレクトリ)を分析します。生成されたHTMLレポートは、supportconfigアーカイブまたはディレクトリと同じ場所に保存されます。
sudo scatool
-a
SLES_SERVER.COMPANY.COM外部サーバSLES_SERVER.COMPANY.COMとのSSH接続を確立し、そのサーバ上で
supportconfig
を実行します。その後、supportconfigアーカイブをローカルマシンにコピーし、そこで分析を行います。生成されたHTMLレポートは、デフォルトの/var/log
ディレクトリに保存されます(SLES_SERVER.COMPANY.COMにはsupportconfigアーカイブのみが作成されます)。sudo scatool
-c
scatool
の対話型コンソールを起動します。利用可能なコマンドを参照するには、<Tab>を2回押します。
他のオプションおよび詳細については、sudo scatool -h
を実行するか、scatool
のマニュアルページを参照してください。
40.4.2 SCAアプライアンス #
supportconfigアーカイブの分析にSCAアプライアンスを使用する場合は、専用のサーバ(または仮想マシン)をSCAアプライアンスサーバとして設定する必要があります。このSCAアプライアンスサーバを使用して、エンタープライズ内にある、SUSE Linux Enterprise ServerまたはSUSE Linux Enterprise Desktopが稼働するすべてのマシンからのsupportconfigアーカイブを分析できます。supportconfigアーカイブをアプライアンスサーバにアップロードするだけで分析を行うことができます。対話操作は必要ありません。MariaDBデータベースでは、SCAアプライアンスは、解析済みのsupportconfigアーカイブをすべて追跡します。アプライアンスのWebインタフェースからSCAレポートを直接参照できます。アプライアンスから管理者ユーザに電子メールでHTMLレポートを送信することもできます。詳細については、40.4.2.5.4項 「電子メールでのSCAレポートの送信」を参照してください。
40.4.2.1 インストールのクイックスタート #
コマンドラインから短時間でSCAアプライアンスをインストールしてセットアップするには、この手順に従います。この手順は上級者向けで、ベアインストールとセットアップコマンドに焦点を当てています。詳しい説明については、40.4.2.2項 「前提条件」~40.4.2.3項 「インストールと基本セットアップ」を参照してください。
WebおよびLAMPパターン
Webおよびスクリプティングモジュール(このモジュールを選択できるようにするにはマシンを登録する必要があります)
root
特権が必要
次のプロシージャのコマンドはすべてroot
として実行される必要があります。
アプライアンスをセットアップして稼働させた後は、手動での対話操作は必要ありません。したがって、cronジョブを使用してsupportconfigアーカイブを作成およびアップロードするには、この方法でアプライアンスをセットアップするのが理想的です。
アプライアンスをインストールするマシンでコンソールにログインし、次のコマンドを実行します。
zypper install sca-appliance-* sca-patterns-* vsftpd systemctl enable apache2 systemctl start apache2 systemctl enable vsftpd systemctl start vsftpd yast ftp-server
YaST FTPサーバで、
› › › › の順に選択し、 を作成します。次のコマンドを実行します。
systemctl enable mysql systemctl start mysql mysql_secure_installation setup-sca -f
このmysql_secure_installationにより、MariaDBの
root
パスワードが作成されます。
この方法でアプライアンスをセットアップするには、SSHパスワードを入力する際に手動での対話操作が必要になります。
アプライアンスをインストールするマシンでコンソールにログインします。
次のコマンドを実行します。
zypper install sca-appliance-* sca-patterns-* systemctl enable apache2 systemctl start apache2 sudo systemctl enable mysql systemctl start mysql mysql_secure_installation setup-sca
40.4.2.2 前提条件 #
SCAアプライアンスサーバを実行するには、次の前提条件が必要です。
すべての
sca-appliance-*
パッケージ。sca-patterns-base
パッケージ。さらに、アプライアンスで分析するsupportconfigアーカイブのタイプに合った、製品固有のsca-patterns-*
。Apache
PHP
MariaDB
匿名FTPサーバ(オプション)
40.4.2.3 インストールと基本セットアップ #
40.4.2.2項 「前提条件」に記載されているように、SCAアプライアンスには他のパッケージに対する依存関係がいくつかあります。そのため、SCAアプライアンスサーバをインストールしてセットアップする前に、次の手順で準備を行う必要があります。
ApacheおよびMariaDBに対して、
Web
およびLAMP
インストールパターンをインストールします。Apache、MariaDB、および匿名FTPサーバ(オプション)をセットアップします。詳細については、第32章 「Apache HTTPサーバ」と第33章 「YaSTを使用したFTPサーバの設定」を参照してください。
ApacheおよびMariaDBをブート時に起動するように設定します。
sudo systemctl enable apache2 mysql
両方のサービスを開始します。
sudo systemctl start apache2 mysql
これで、手順40.5「SCAアプライアンスのインストールと設定」の説明に従ってSCAアプライアンスをインストールしてセットアップできます。
パッケージをインストールしたら、setup-sca
スクリプトを使用して、SCAアプライアンスが使用するMariaDBの管理およびレポートデータベースの基本設定を行います。
このスクリプトを使用して、マシンからSCAアプライアンスにsupportconfigアーカイブをアップロードするための次のオプションを設定できます。
scp
匿名FTPサーバ
アプライアンスとSCA基本パターンライブラリをインストールします。
sudo zypper install sca-appliance-* sca-patterns-base
さらに、分析するsupportconfigアーカイブのタイプに合ったパターンパッケージをインストールします。たとえば、現在の環境にSUSE Linux Enterprise Server 11のサーバとSUSE Linux Enterprise Server 12のサーバがある場合、
sca-patterns-sle11
パッケージとsca-patterns-sle12
パッケージの両方をインストールします。利用可能なすべてのパターンをインストールする
zypper install sca-patterns-*
SCAアプライアンスの基本セットアップには、
setup-sca
スクリプトを使用します。スクリプトの呼び出し方法は、supportconfigアーカイブをどのようにSCAアプライアンスサーバにアップロードするかによって異なります。/srv/ftp/upload
ディレクトリを使用する匿名FTPサーバを設定済みの場合は、-f
オプションを指定してセットアップスクリプトを実行し、画面の指示に従います。setup-sca -f
注記: 別のディレクトリを使用するFTPサーバFTPサーバで
/srv/ftp/upload
以外のディレクトリを使用する場合は、まず、正しいディレクトリを指すように環境設定ファイル/etc/sca/sdagent.conf
および/etc/sca/sdbroker.conf
を調整します。scp
を使用してsupportconfigファイルをSCAアプライアンスサーバの/tmp
ディレクトリにアップロードする場合は、パラメータを指定せずにセットアップスクリプトを呼び出して、画面の指示に従います。setup-sca
セットアップスクリプトは要件チェックをいくつか実行し、必要なコンポーネントを設定します。2つのパスワードを入力するようプロンプトが表示されます。1つは、セットアップ済みのMariaDBのMySQL
root
パスワードで、もう1つは、SCAアプライアンスのWebインタフェースにログインするために使用するWebユーザのパスワードです。既存のMariaDBの
root
パスワードを入力します。これにより、SCAアプライアンスがMariaDBに接続できるようになります。Webユーザのパスワードを定義します。パスワードは
/srv/www/htdocs/sca/web-config.php
に書き込まれ、ユーザscdiag
のパスワードとして設定されます。ユーザ名とパスワードは後で随時変更できます。40.4.2.5.1項 「Webインタフェースのパスワード」を参照してください。
インストールとセットアップが正常に完了したら、すぐにSCAアプライアンスを使用できます。40.4.2.4項 「SCAアプライアンスの使用」を参照してください。ただし、Webインタフェースのパスワードの変更、SCAパターンのアップデートのソースの変更、アーカイブモードの有効化、電子メール通知の設定など、一部のオプションを変更する必要があります。詳細については、40.4.2.5項 「SCAアプライアンスのカスタマイズ」を参照してください。
SCAアプライアンスサーバ上のレポートには、分析済みのsupportconfigアーカイブが存在するマシンに関するセキュリティ関連情報が含まれているため、SCAアプライアンスサーバ上のデータを不正アクセスから保護してください。
40.4.2.4 SCAアプライアンスの使用 #
既存のsupportconfigアーカイブをSCAアプライアンスに手動でアップロードすることも、1つのステップで新しいsupportconfigアーカイブを作成してSCAアプライアンスにアップロードすることもできます。アップロードはFTPまたはSCP経由で行うことができます。どちらの場合も、SCAアプライアンスに接続できるURLが分かっている必要があります。FTP経由でのアップロードの場合、FTPサーバをSCAアプライアンス用に設定する必要があります。手順40.5「SCAアプライアンスのインストールと設定」を参照してください。
40.4.2.4.1 SCAアプライアンスへのSupportconfigアーカイブのアップロード #
supportconfigアーカイブを作成して(匿名) FTP経由でアップロードするには、次の手順に従います。
sudo supportconfig -U “ftp://SCA-APPLIANCE.COMPANY.COM/upload”
supportconfigアーカイブを作成してSCP経由でアップロードするには、次の手順に従います。
sudo supportconfig -U “scp://SCA-APPLIANCE.COMPANY.COM/tmp”
SCAアプライアンスが動作しているサーバの
root
ユーザのパスワードを入力するようプロンプトが表示されます。1つまたは複数のアーカイブを手動でアップロードする場合は、既存のアーカイブファイル(通常は
/var/log/nts_*.tbz
にあります)をSCAアプライアンスにコピーします。アップロード先には、アプライアンスサーバの/tmp
ディレクトリまたは/srv/ftp/upload
ディレクトリ(FTPがSCAアプライアンスサーバ用に設定されている場合)を使用します。
40.4.2.4.2 SCAレポートの表示 #
SCAレポートは、ブラウザがインストールされていて、SCAアプライアンスのレポートインデックスページにアクセス可能な任意のマシンから表示できます。
Webブラウザを起動し、JavaScriptとCookieが有効なことを確認します。
URLとして、SCAアプライアンスのレポートインデックスページを入力します。
https://sca-appliance.company.com/sca
不確かな場合は、システム管理者に問い合わせてください。
ログインするためのユーザ名とパスワードを入力するようプロンプトが表示されます。
図 40.2: SCAアプライアンスによって生成されるHTMLレポート #ログイン後、参照するレポートの日付をクリックします。
最初に
カテゴリをクリックして展開します。SCAによって特定された問題に直接関係する結果については、SUSE Knowledgebase (http://www.suse.com/support/kb/)を確認してください。問題解決に取り組みます。
問題の再発防止のために事前に対処できる結果がないかどうかを確認します。
40.4.2.5 SCAアプライアンスのカスタマイズ #
次の項では、Webインタフェースのパスワードを変更する方法、SCAパターンアップデートのソースを変更する方法、アーカイブモードを有効にする方法、および電子メール通知を設定する方法について説明します。
40.4.2.5.1 Webインタフェースのパスワード #
SCAアプライアンスのWebインタフェースにログインするには、ユーザ名とパスワードが必要です。デフォルトのユーザ名はscdiag
で、デフォルトのパスワードはlinux
です(特に指定されていない場合。手順40.5「SCAアプライアンスのインストールと設定」を参照してください)。パスワードを保護するため、デフォルトのパスワードはできる限り速やかに変更してください。ユーザ名を変更することもできます。
SCAアプライアンスサーバのシステムコンソールで
root
ユーザとしてログインします。エディタで
/srv/www/htdocs/sca/web-config.php
を開きます。必要に応じて、
$username
および$password
の値を変更します。ファイルを保存して終了します。
40.4.2.5.2 SCAパターンのアップデート #
デフォルトでは、すべてのsca-patterns-*
パッケージはroot
cronジョブによって定期的にアップデートされます。このジョブは夜間にsdagent-patterns
スクリプトを実行し、このスクリプトがzypper update sca-patterns-*
を実行します。定期的なシステムアップデートにより、SCAアプライアンスおよびパターンのすべてのパッケージがアップデートされます。SCAアプライアンスとパターンを手動でアップデートするには、以下を実行します。
sudo zypper update sca-*
デフォルトでは、アップデートはSUSE Linux Enterprise 12 SP5のアップデートリポジトリからインストールされます。必要に応じて、アップデートのソースをSMTサーバに変更できます。sdagent-patterns
は、zypper update sca-patterns-*
を実行する際に、現在設定されているアップデートチャネルからアップデートを取得します。このチャネルがSMTサーバにある場合、パッケージはそこから取得されます。
SCAアプライアンスサーバのシステムコンソールで
root
ユーザとしてログインします。エディタで
/etc/sca/sdagent-patterns.conf
を開きます。次のエントリを変更します。
UPDATE_FROM_PATTERN_REPO=1
変更後:
UPDATE_FROM_PATTERN_REPO=0
ファイルを保存して終了します。変更を適用するためにマシンを再起動する必要はありません。
40.4.2.5.3 アーカイブモード #
supportconfigアーカイブの分析が終了し、その結果がMariaDBデータベースに保存されると、アーカイブはすべてSCAアプライアンスから削除されます。ただし、トラブルシューティングのために、マシンからのsupportconfigアーカイブのコピーを保持しておくと便利です。デフォルトでは、アーカイブモードは無効になっています。
SCAアプライアンスサーバのシステムコンソールで
root
ユーザとしてログインします。エディタで
/etc/sca/sdagent.conf
を開きます。次のエントリを変更します。
ARCHIVE_MODE=0
変更後:
ARCHIVE_MODE=1
ファイルを保存して終了します。変更を適用するためにマシンを再起動する必要はありません。
アーカイブモードを有効にすると、SCAアプライアンスはsupportconfigファイルを削除せずに、/var/log/archives/saved
ディレクトリに保存します。
40.4.2.5.4 電子メールでのSCAレポートの送信 #
分析された各supportconfigのレポートHTMLファイルを、SCAアプライアンスから電子メールで送信できます。デフォルトでは、この機能は無効になっています。これを有効にすると、レポートの送信先電子メールアドレスのリストを定義したり、レポートの送信をトリガするステータスメッセージのレベル(STATUS_NOTIFY_LEVEL
)を定義したりできます。
STATUS_NOTIFY_LEVEL
に指定可能な値 #- $STATUS_OFF
HTMLレポートの送信を無効にします。
- $STATUS_CRITICAL
CRITICALが含まれるSCAレポートのみを送信します。
- $STATUS_WARNING
WARNINGまたはCRITICALが含まれるSCAレポートのみを送信します。
- $STATUS_RECOMMEND
RECOMMEND、WARNING、またはCRITICALが含まれるSCAレポートのみを送信します。
- $STATUS_SUCCESS
SUCCESS、RECOMMEND、WARNING、またはCRITICALが含まれるSCAレポートを送信します。
SCAアプライアンスサーバのシステムコンソールで
root
ユーザとしてログインします。エディタで
/etc/sca/sdagent.conf
を開きます。STATUS_NOTIFY_LEVEL
というエントリを探します。デフォルトでは、これは$STATUS_OFF
に設定されています(電子メール通知は無効です)。電子メール通知を有効にするには、
$STATUS_OFF
を、電子メールレポートを要求するステータスメッセージのレベルに変更します。次に例を示します。STATUS_NOTIFY_LEVEL=$STATUS_SUCCESS
詳細については、
STATUS_NOTIFY_LEVEL
に指定可能な値を参照してください。レポートの送信先の受信者リストを定義する
EMAIL_REPORT='root'
というエントリを探します。root
を、SCAレポートの送信先電子メールアドレスのリストに置き換えます。複数の電子メールアドレスはそれぞれスペースで区切る必要があります。次に例を示します。EMAIL_REPORT='tux@my.company.com wilber@your.company.com'
ファイルを保存して終了します。変更を適用するためにマシンを再起動する必要はありません。今後、すべてのSCAレポートは指定したアドレスに電子メールで送信されます。
40.4.2.6 データベースのバックアップと復元 #
SCAレポートが保存されているMariaDBデータベースをバックアップおよび復元するには、次の説明に従ってscadb
コマンドを使用します。
SCAアプライアンスが動作しているサーバのシステムコンソールで、
root
ユーザとしてログインします。次のコマンドを実行してアプライアンスを保守モードにします。
scadb maint
次のコマンドを実行してバックアップを開始します。
scadb backup
データはTARアーカイブ
sca-backup-*sql.gz
に保存されます。パターン作成データベースを使用して独自のパターンを開発している場合は(40.4.3項 「カスタム分析パターンの開発」を参照)、そのデータもバックアップします。
sdpdb backup
データはTARアーカイブ
sdp-backup-*sql.gz
に保存されます。次のデータを別のマシンまたは外部ストレージメディアにコピーします。
sca-backup-*sql.gz
sdp-backup-*sql.gz
/usr/lib/sca/patterns/local
(カスタムパターンを作成している場合にのみ必要)
次のコマンドを実行してSCAアプライアンスを再び有効にします。
scadb reset agents
バックアップからデータベースを復元するには、次の手順に従います。
SCAアプライアンスが動作しているサーバのシステムコンソールで、
root
ユーザとしてログインします。最も新しい
sca-backup-*sql.gz
およびsdp-backup-*sql.gz
TARアーカイブをSCAアプライアンスサーバにコピーします。ファイルを圧縮解除するため、次のコマンドを実行します。
gzip -d *-backup-*sql.gz
データをデータベースにインポートするため、次のコマンドを実行します。
scadb import sca-backup-*sql
パターン作成データベースを使用して独自のパターンを開発している場合、次のデータもインポートします。
sdpdb import sdp-backup-*sql
カスタムパターンを使用している場合は、
/usr/lib/sca/patterns/local
もバックアップデータから復元します。次のコマンドを実行してSCAアプライアンスを再び有効にします。
scadb reset agents
データベース内のパターンモジュールを更新します。
sdagent-patterns -u
40.4.3 カスタム分析パターンの開発 #
SCAアプライアンスには、独自のカスタムパターンの開発を可能にする、充実したパターン開発環境(SCA Pattern Database)が付属しています。パターンは、どのプログラム言語でも作成できます。パターンをsupportconfig分析プロセスで利用できるようにするには、/usr/lib/sca/patterns/local
に保存し、実行可能にする必要があります。SCAアプライアンスとSCAツールのどちらも、分析レポートの一部として、新しいsupportconfigアーカイブに照らしてカスタムパターンを実行します。独自のパターンを作成(およびテスト)する方法の詳細については、http://www.suse.com/communities/conversations/sca-pattern-development/を参照してください。
40.5 インストール時の情報収集 #
インストール時には、supportconfig
を使用できません。ただし、save_y2logs
を使用してYaSTからログファイルを収集することができます。このコマンドにより、/tmp
ディレクトリに.tar.xz
アーカイブが作成されます。
インストールの開始直後に問題が発生したときは、linuxrc
で作成したログファイルから情報を収集できる場合があります。linuxrc
は、YaSTが起動する前に実行される小さなコマンドです。このログファイルは、/var/log/linuxrc.log
にあります。
インストール時に使用可能だったログファイルが、インストールしたシステムでは使用できなくなってしまいました。インストーラの実行中に、インストールログファイルを正しく保存してください。
40.6 カーネルモジュールのサポート #
あらゆるエンタープライズ向けオペレーティングシステムにとって重要な要件は、利用環境に対して受けられるサポートのレベルです。カーネルモジュールは、ハードウェア(「コントローラ」)とオペレーティングシステムを結ぶものの中で最も重要です。SUSE Linux Enterpriseのカーネルモジュールにはすべてsupported
フラグが付いており、これは次の3つの値を取ります。
「yes」、したがって
supported
「external」、したがって
supported
「」 (空、未設定)、したがって
unsupported
次のルールが適用されます。
自己再コンパイルしたカーネルのすべてのモジュールには、デフォルトで「unsupported」のマークが付きます。
SUSEパートナーによってサポートされていて、
SUSE SolidDriverプログラム
を使用して配信されているカーネルモジュールには、「external」のマークが付きます。supported
フラグが設定されていない場合、そのモジュールをロードすると、カーネルが汚染されます。汚染カーネルはサポートされません。SUSE Linux Enterprise DesktopとSUSE Linux Enterprise Workstation Extensionのみで使用可能な追加のRPMパッケージ(kernel-FLAVOR-extra
)には、サポートされていないカーネルモジュールが含まれています。デフォルト(FLAVOR=default
|xen
|...)では、これらのカーネルはロードされません。さらに、これらのサポート対象外のモジュールはインストーラで利用できず、kernel-FLAVOR-extra
パッケージはSUSE Linux Enterpriseのメディアに含まれていません。Linuxカーネルのライセンスと互換性があるライセンスに従って提供されていないカーネルモジュールを使用しても、カーネルが汚染されます。詳細については、
/usr/src/linux/Documentation/sysctl/kernel.txt
、および/proc/sys/kernel/tainted
の状態を参照してください。
40.6.1 技術的背景 #
Linuxカーネル: SUSE Linux Enterprise
12 SP5
では、/proc/sys/kernel/unsupported
の値はデフォルトで2に設定されています(do not warn in syslog when loading unsupported modules (サポート対象外のカーネルのロード時にsyslogで警告しない)
)。このデフォルト値は、インストーラと、インストールしたシステムで使用されます。詳細については、/usr/src/linux/Documentation/sysctl/kernel.txt
を参照してください。modprobe
: モジュールの依存関係を確認して適切にモジュールをロードするためのmodprobe
ユーティリティは、supported
フラグの値を確認します。この値が「yes」または「external」であればモジュールはロードされ、他の値の場合はロードされません。この動作を無効にする方法については、40.6.2項 「サポート対象外のモジュールの使用」を参照してください。注記: サポートSUSEは一般的に、
modprobe -r
によるストレージモジュールの削除をサポートしていません。
40.6.2 サポート対象外のモジュールの使用 #
一般的なサポート可能性は重要ですが、サポート対象外のモジュールをロードしなければならないこともあります(たとえば、テストやデバッグを行う場合や、ハードウェアベンダーがホットフィックスを提供している場合など)。
デフォルト値を無効にするには、
/etc/modprobe.d/10-unsupported-modules.conf
を編集して、変数allow_unsupported_modules
の値を1
に変更します。initrdでサポート対象外のモジュールが必要な場合は、必ずdracut
-f
を実行してinitrdをアップデートしてください。モジュールを一度だけロードする場合は、
modprobe
で--allow-unsupported-modules
オプションを使用できます。詳細については、modprobe
のマニュアルページを参照してください。インストール時に、ドライバアップデートディスクを使用してサポート対象外のモジュールを追加できます。この場合、これらのモジュールはロードされます。ブート時およびそれ以降にサポート対象外のモジュールを強制的にロードするには、カーネルコマンドラインオプション
oem-modules
を使用します。suse-module-tools
パッケージのインストールおよび初期化時に、カーネルフラグTAINT_NO_SUPPORT
(/proc/sys/kernel/tainted
)が評価されます。カーネルがすでに汚染されている場合は、allow_unsupported_modules
が有効になります。これにより、インストール中のシステムでサポート対象外のモジュールが失敗しないようにします。インストール時にサポート対象外のモジュールが存在しておらず、もう1つの特殊なカーネルコマンドラインオプション(oem-modules=1
)を使用していない場合は、引き続きデフォルトで、サポート対象外のモジュールは許可されません。
サポート対象外のモジュールをロードおよび実行すると、カーネルとシステム全体がSUSEのサポート対象外になる点に注意してください。
40.7 その他の情報 #
man supportconfig
—supportconfig
のマニュアルページman supportconfig.conf
—supportconfig環境設定ファイルのマニュアルページman scatool
—scatool
のマニュアルページman scadb
—scadb
のマニュアルページman setup-sca
—setup-sca
のマニュアルページhttps://mariadb.com/kb/en/—MariaDBのマニュアル
http://httpd.apache.org/docs/および第32章 「Apache HTTPサーバ」—Apache Webサーバのマニュアル
第33章 「YaSTを使用したFTPサーバの設定」—FTPサーバのセットアップ方法のマニュアル
http://www.suse.com/communities/conversations/sca-pattern-development/—独自のSCAパターンを作成(およびテスト)する方法
http://www.suse.com/communities/conversations/basic-server-health-check-supportconfig/—「A Basic Server Health Check with Supportconfig」
https://community.microfocus.com/collaboration/gw/groupwise/w/groupwise/34308/create-your-own-supportconfig-plugin/—「Create Your Own Supportconfig Plugin」
http://www.suse.com/communities/conversations/creating-a-central-supportconfig-repository/—「Creating a Central Supportconfig Repository」