手順

1. カーネルを更新するには、以下を実行します。

   # yum update kernel

   このコマンドは、カーネルと、利用可能な最新バージョンへのすべての依存関係を更新します。

2. システムを再起動して、変更を有効にします。

手順

1. 読み込むカーネルモジュールを選択します。

   モジュールは /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ ディレクトリーにあります。

2. 関連するカーネルモジュールを読み込みます。

   # modprobe <MODULE_NAME>

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

3. 必要に応じて、関連モジュールが読み込まれたことを確認します。

   $ lsmod | grep <MODULE_NAME>

   モジュールが正しく読み込まれた場合、このコマンドは関連するカーネルモジュールを表示します。以下は例になります。

   $ lsmod | grep serio_raw
   serio_raw              16384  0

手順

1. lsmod コマンドを実行して、アンロードするカーネルモジュールを選択します。

   カーネルモジュールに依存関係がある場合は、カーネルモジュールをアンロードする前に、これらをアンロードします。依存関係のあるモジュールを特定する方法は、「現在読み込まれているカーネルモジュールの一覧表示」および「カーネルモジュールの依存関係」を参照してください。

2. 関連するカーネルモジュールをアンロードします。

   # modprobe -r <MODULE_NAME>

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

   警告

   実行中のシステムで使用される場合は、カーネルモジュールをアンロードしないでください。これを行うと、システムが不安定になったり、動作しなくなったりすることがあります。

3. 必要に応じて、関連モジュールがアンロードされたことを確認します。

   $ lsmod | grep <MODULE_NAME>

   モジュールが正常にアンロードされた場合、このコマンドは出力を表示しません。

手順

1. 起動プロセス中に読み込むカーネルモジュールを選択します。

   モジュールは /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ ディレクトリーにあります。

2. モジュールの設定ファイルを作成します。

   # echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

3. 必要に応じて、関連モジュールが読み込まれたことを確認します。

   $ lsmod | grep <MODULE_NAME>

   上記のコマンド例は成功し、関連するカーネルモジュールを表示します。

手順

1. 拒否リストに追加するカーネルモジュールを選択します。

   $ lsmod
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1
   …​

   lsmod コマンドは、現在実行中のカーネルに読み込まれているモジュールの一覧を表示します。

   • もしくは、読み込みを阻止する、アンロードしたカーネルモジュールを特定します。

     すべてのカーネルモジュールは、/lib/modules/<KERNEL_VERSION>/kernel/<subsystem>/ ディレクトリーにあります。

2. 拒否リスト用の設定ファイルを作成します。

   # vim /etc/modprobe.d/blacklist.conf
   
   	# Blacklists <KERNEL_MODULE_1>
   	blacklist <MODULE_NAME_1>
   	install <MODULE_NAME_1> /bin/false
   
   	# Blacklists <KERNEL_MODULE_2>
   	blacklist <MODULE_NAME_2>
   	install <MODULE_NAME_2> /bin/false
   
   	# Blacklists <KERNEL_MODULE_n>
   	blacklist <MODULE_NAME_n>
   	install <MODULE_NAME_n> /bin/false
   	…​

   この例では、vim エディターで編集した blacklist.conf ファイルの内容を示しています。blacklist の行では、システムの起動プロセス中に関連のカーネルモジュールが自動的に読み込まれないように指定します。ただし、blacklist コマンドは、拒否リストに入っていない他のカーネルモジュールの依存関係としてのモジュールの読み込みを阻止することはありません。したがって、install の行では、モジュールのインストールの代わりに、/bin/false が実行されます。

   ハッシュ記号で始まる行は、ファイルがより読みやすいコメントです。

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

3. 再構築を行う前に、現在の初期 ramdisk イメージのバックアップコピーを作成します。

   # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img

   上記のコマンドは、新しいバージョンに予期しない問題が発生したときに、バックアップの initramfs イメージを作成します。

   • または、カーネルモジュールを拒否リストに指定するカーネルバージョンに対応する、その他の初期 ramdisk イメージのバックアップコピーを作成します。

     # cp /boot/initramfs-<SOME_VERSION>.img /boot/initramfs-<SOME_VERSION>.img.bak.$(date +%m-%d-%H%M%S)

4. 変更を反映するために新しい初期 ramdisk イメージを生成します。

   # dracut -f -v

   • 現在起動しているものとは異なるカーネルバージョンの初期 ramdisk イメージを構築する場合は、ターゲット initramfs とカーネルバージョンの両方を指定します。

     # dracut -f -v /boot/initramfs-<TARGET_VERSION>.img <CORRESPONDING_TARGET_KERNEL_VERSION>

5. システムを再起動します。

   $ reboot

手順

1. キーペア生成のパラメーターで設定ファイルを作成します。

   # cat << EOF > configuration_file.config
   [ req ]
   default_bits = 4096
   distinguished_name = req_distinguished_name
   prompt = no
   string_mask = utf8only
   x509_extensions = myexts
   
   [ req_distinguished_name ]
   O = Organization
   CN = Organization signing key
   emailAddress = E-mail address
   
   [ myexts ]
   basicConstraints=critical,CA:FALSE
   keyUsage=digitalSignature
   subjectKeyIdentifier=hash
   authorityKeyIdentifier=keyid
   EOF

2. X.509 公開鍵と秘密鍵のペアを以下の例のように作成します。

   # openssl req -x509 -new -nodes -utf8 -sha256 -days 36500
   -batch -config configuration_file.config -outform DER \
   -out my_signing_key_pub.der \
   -keyout my_signing_key.priv

   公開鍵は my_signing_key_pub.der ファイルに書き込まれます。この秘密鍵は my_signing_key.priv ファイルに書き込まれます。

   重要

   RHEL 8 では、鍵のペアの有効期限は重要です。キーの有効期限はありませんが、カーネルモジュールはその署名キーの有効期間内に署名する必要があります。たとえば、2019 でのみ有効な鍵を使用して、その鍵で 2019 で署名されたカーネルモジュールを認証できます。ただし、ユーザーはこの鍵を使用して 2020 でカーネルモジュールに署名することはできません。

3. 必要に応じて、以下の例のように公開鍵の有効期限を確認できます。

   # openssl x509 -inform der -text -noout -in <my_signing_key_pub.der>
   
   Validity
               Not Before: Feb 14 16:34:37 2019 GMT
               Not After : Feb 11 16:34:37 2029 GMT

4. カーネルモジュールを認証、読み込むすべてのシステムに公開鍵を登録します。

手順

1. 公開鍵を MOK リストに追加するようリクエストします。

   # mokutil --import my_signing_key_pub.der

   この MOK 登録リクエストに関するパスワードの入力と確認が求められます。

2. マシンを再起動します。

   この MOK 鍵登録リクエストは shim.efi が発見し、MokManager.efi を起動して UEFI コンソールからの登録が完了できるようになります。

3. このリクエストに関連付けたパスワードを入力し、登録を確認します。

   公開鍵が MOK リストに永続的に追加されます。

手順

1. 公開鍵がシステムキーリング上にあることを確認します。

   # keyctl list %:.builtin_trusted_keys

2. 任意のカーネルの /extra/ ディレクトリーにカーネルモジュールをコピーします。

   # cp my_module.ko /lib/modules/$(uname -r)/extra/

3. モジュールの依存関係の一覧を更新します。

   # depmod -a

4. カーネルモジュールを読み込み、正常にロードされたことを確認します。

   # modprobe -v my_module
   # lsmod | grep my_module

   1. 必要に応じて、起動時にモジュールを読み込むには、/etc/modules-loaded.d/my_module.conf ファイルに追加します。

      # echo "my_module" > /etc/modules-load.d/my_module.conf

手順

1. すべてのパラメーターとそれらの値を一覧表示するには、以下を実行します。

   # sysctl -a

   注記

   # sysctl -a コマンドは、ランタイム時およびシステムの起動時に調整できるカーネルパラメーターを表示します。

2. パラメーターを一時的に設定するには、以下の例のようにコマンドを実行します。

   # sysctl <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

   上記のサンプルコマンドは、システムの実行中にパラメーター値を変更します。この変更は、再起動なしですぐに適用されます。

   注記

   変更は、システムの再起動後にデフォルトに戻ります。

手順

1. すべてのパラメーターを一覧表示するには、以下を実行します。

   # sysctl -a

   このコマンドは、ランタイム時に設定できるカーネルパラメーターをすべて表示します。

2. パラメーターを永続的に設定するには、以下のコマンドを実行します。

   # sysctl -w <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE> >> /etc/sysctl.conf

   サンプルコマンドは、調整可能な値を変更して、/etc/sysctl.conf ファイルに書き込みます。これにより、カーネルパラメーターのデフォルト値が上書きされます。変更は、再起動なしで即座に永続的に反映されます。

手順

1. /etc/sysctl.d/ に新しい設定ファイルを作成します。

   # vim /etc/sysctl.d/<some_file.conf>

2. 以下のように、1 行ごとにカーネルパラメーターを含めます。

   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

3. 設定を保存します。

4. システムを再起動して、変更を有効にします。

   • また、再起動せずに変更を適用するには、以下を実行します。

     # sysctl -p /etc/sysctl.d/<some_file.conf>

     このコマンドにより、以前に作成した設定ファイルから値を読み取ることができます。

手順

1. 設定するカーネルパラメーターを特定します。

   # ls -l /proc/sys/<TUNABLE_CLASS>/

   コマンドが返した書き込み可能なファイルは、カーネルの設定に使用できます。読み取り専用権限を持つユーザーは、現在の設定についてフィードバックを提供します。

2. カーネルパラメーターにターゲットの値を割り当てます。

   # echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

   このコマンドでは、システムが再起動すると設定変更が消えます。

3. 必要に応じて、新しく設定した設定したカーネルパラメーターの値を確認します。

   # cat /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

1. 値。コンソールログレベル。コンソールに出力されるメッセージの最低優先度を定義します。
2. 値。明示的なログレベルが付いていないメッセージのデフォルトのログレベル。
3. 値。コンソールのログレベルに、可能な限り低いログレベル設定を設定します。

4. 値。起動時のコンソールのログレベルのデフォルト値を設定します。

   上記の各値は、エラーメッセージを処理するさまざまなルールを定義します。

手順

1. 以下のコマンドを実行して、kdump がシステムにインストールされているかどうかを確認します。

   $ rpm -q kexec-tools

   このパッケージがインストールされている場合は以下を出力します。

   kexec-tools-2.0.17-11.el8.x86_64

   このパッケージがインストールされていない場合は以下を出力します

   package kexec-tools is not installed

2. kdump および必要なパッケージをインストールします。

   # yum install kexec-tools

手順

1. root パーミッションで /etc/default/grub ファイルを編集します。

2. crashkernel= オプションを必要な値に設定します。

   たとえば、128 MB のメモリーを予約するには、以下を使用します。

   crashkernel=128M

   または、インストールされているメモリーの合計量に応じて、予約メモリーサイズを変数に設定できます。変数へのメモリー予約の構文は crashkernel=<range1>:<size1>,<range2>:<size2> です。以下は例になります。

   crashkernel=512M-2G:64M,2G-:128M

   上記の例では、システムメモリーの合計が 512 MB 以上 2 GB 未満の場合、64 MB のメモリーを予約します。メモリー合計サイズが 2 GB を超える場合は、128 MB が kdump 用に予約されます。

   • 予約済みメモリーのオフセット。

     crashkernel 予約は非常に早いため、特定の固定オフセットでメモリーを予約する必要があるシステムもあります。また、特別な用途にいくつかの領域を予約したいシステムもあります。オフセットが設定されると、予約メモリーはそこから開始されます。予約メモリーをオフセットするには、以下の構文を使用します。

     crashkernel=128M@16M

     上記の例は、kdump が 16 MB (物理アドレス 0x01000000) から始まる 128 MB のメモリーを予約していることを示しています。オフセットパラメーターが 0 に設定されている場合、または完全に省略されている場合、kdump は自動的に予約メモリーをオフセットします。上記のように、変数メモリー予約を設定する場合にもこの構文を使用します。この場合、オフセットは常に最後に指定されます (例: crashkernel=512M-2G:64M,2G-:128 _M@16 _M)。

3. 以下のコマンドを使用して、GRUB2 設定ファイルを更新します。

   # grub2-mkconfig -o /boot/grub2/grub.cfg

手順

1. root で、/etc/kdump.conf 設定ファイルを編集し、#core_collector makedumpfile -l --message-level 1 -d 31 の行頭にあるハッシュ記号 ("#") を削除します。
2. ダンプファイルの圧縮を有効にするには、以下のコマンドを実行します。

手順

1. root で、/etc/kdump.conf 設定ファイルの #failure_action の行頭にあるハッシュ記号 ("#") を削除します。

2. 値を任意のアクションに置き換えます。

   failure_action poweroff

手順

1. kdump サービスを有効にするには、以下のコマンドを実行します。

   # systemctl enable kdump.service

   これにより、multi-user.target のサービスが有効になります。

2. 現行セッションでサービスを開始するには、以下のコマンドを使用します。

   # systemctl start kdump.service

3. kdump サービスを停止するには、以下のコマンドを実行します。

   # systemctl stop kdump.service

4. kdump サービスを無効にするには、以下のコマンドを実行します。

   # systemctl disable kdump.service

手順

1. kdump を有効にしてシステムを再起動します。

2. kdump が動作していることを確認します。

   ~]# systemctl is-active kdump
   active

3. Linux カーネルを強制的にクラッシュさせます。

   echo 1 > /proc/sys/kernel/sysrq
   echo c > /proc/sysrq-trigger

   警告

   上記のコマンドによりカーネルがクラッシュし、再起動が必要になります。

   再度起動すると、/etc/kdump.conf で指定した場所 (デフォルトでは /var/crash/) にアドレス-YYYY-MM-DD-HHH:MM:SS/vmcore ファイルが作成されます。

   注記

   設定の妥当性を確認することに加え、このアクションを利用して、代表的な負荷が稼働しているときに、クラッシュダンプが完了するのにかかる時間を記録することができます。

手順

1. kexec ユーティリティーを実行します。

   # kexec -l /boot/vmlinuz-3.10.0-1040.el7.x86_64 --initrd=/boot/initramfs-3.10.0-1040.el7.x86_64.img --reuse-cmdline

   このコマンドは、kexec システムコールのカーネルおよび initramfs イメージを手動で読み込みます。

2. システムを再起動します。

   # reboot

   このコマンドはカーネルを検出し、すべてのサービスをシャットダウンしてから、kexec システムコールを呼び出して直前の手順で指定したカーネルに再起動します。

手順

1. 読み込みをブロックするカーネルモジュールを選択します。

   $ lsmod
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1

   lsmod コマンドは、現在実行中のカーネルに読み込まれているモジュールの一覧を表示します。

2. /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND= 変数を更新します。

   KDUMP_COMMANDLINE_APPEND="rd.driver.blacklist=hv_vmbus,hv_storvsc,hv_utils,hv_netvsc,hid-hyperv"

   modprobe.blacklist=<modules> 設定オプションを使用した以下の例も検討してください。

   KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"

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

   $ systemctl restart kdump

手順

1. 次のコマンドを実行して、crashkernel= の推定値を出力します。

   # kdumpctl estimate
   
   Encrypted kdump target requires extra memory, assuming using the keyslot  with minimum memory requirement
      Reserved crashkernel:    256M
      Recommended crashkernel: 652M
   
      Kernel image size:   47M
      Kernel modules size: 8M
      Initramfs size:      20M
      Runtime reservation: 64M
      LUKS required size:  512M
      Large modules: <none>
      WARNING: Current crashkernel size is lower than recommended size 652M.

2. crashkernel= の値を必要な値まで上げて、必要なメモリーの量を設定します。
3. システムを再起動します。

手順

1. Kernel Dump タブを開き、kdump サービスを開始します。
2. コマンドラインで kdump のメモリー使用量を設定します。

3. クラッシュダンプの場所 オプションの横にあるリンクをクリックします。

   

4. ドロップダウンメニューから ローカルファイルシステム を選択し、ダンプを保存するディレクトリーを指定します。

   

   • または、ドロップダウンから SSH 経由のリモート オプションを選択し、SSH プロトコルを使用して、vmcore をリモートマシンに送信します。

     Server、ssh key、Directory の各フィールドに、リモートマシンのアドレス、ssh キーの場所、およびターゲットディレクトリーを入力します。

   • または、ドロップダウンから NFS 経由のリモート オプションを選択し、マウント フィールドに入力して、NFS プロトコルを使用して vmcore をリモートマシンに送信することもできます。

     注記

     圧縮 チェックボックスにチェックマークを入れ、vmcore ファイルのサイズを小さくします。

5. カーネルをクラッシュして、設定をテストします。

   
   警告

   この手順では、カーネルの実行を中断し、システムクラッシュやデータの損失が発生します。

手順

1. /etc/kdump.conf ファイルを編集し、final_action パラメーターを追加します。

   final_action <reboot | halt | poweroff>

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

   kdumpctl restart

手順

1. kdump のインストールと設定

2. /etc/default/grub ファイルの GRUB_CMDLINE_LINUX の行に fadump=on を追加します。

   GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto
   rd.lvm.lv=rhel/root rhgb quiet fadump=on"

3. (この操作は必須ではありません) 予約ブートメモリーサイズに、デフォルト値を使わずに具体的な値を指定する場合は、/etc/default/grub の GRUB_CMDLINE_LINUX に crashkernel=xxM を追加します。xx は必要なメモリーサイズ (メガバイト単位) に指定してください。

   GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=xxM rd.lvm.lv=rhel/root rhgb quiet fadump=on"

   重要

   Red Hat は、すべての起動オプションを実行する前に、起動オプションをすべてテストすることを推奨します。クラッシュカーネルから起動時に Out of Memory (OOM) エラーが発生する場合は、クラッシュカーネルが正常に起動できるまで crashkernel= 引数で指定する値を増やします。この場合は、トライアンドエラーが必要になることがあります。

手順

1. sadump に対して kdump が予想どおりに起動するように /etc/sysctl.conf ファイルで以下の行を追加または編集します。

   kernel.panic=0
   kernel.unknown_nmi_panic=1

   警告

   特に、kdump の後にシステムが再起動しないようにする必要があります。kdump が vmcore ファイルの保存失敗後にシステムを再起動すると、sadump を呼び出すことができません。

2. /etc/kdump.conf の failure_action パラメーターを halt または shell として適切に設定します。

   failure_action shell

手順

1. 関連するリポジトリーを有効にします。

   # subscription-manager repos --enable baseos repository

   # subscription-manager repos --enable appstream repository

   # subscription-manager repos --enable rhel-8-for-x86_64-baseos-debug-rpms

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

   # yum install crash

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

   # yum install kernel-debuginfo

   パッケージは実行中のカーネルに対応し、ダンプ分析に必要なデータを提供します。

手順

1. crash ユーティリティーを起動するには、2 つの必要なパラメーターをコマンドに渡す必要があります。

   • debug-info (圧縮解除された vmlinuz イメージ) (特定の kernel-debuginfo パッケージに含まれる /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux など）

   • 実際の vmcore ファイル。/var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

     その結果の crash コマンドの以下のようになります。

     # crash /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore

     kdump で取得したのと同じ <kernel> のバージョンを使用します。

     例15.1 crash ユーティリティーの実行

     以下の例は、4.18.0-5.el8.x86_64 カーネルを使用して、2018 年 10 月 6 日 (14:05 PM) に作成されたコアダンプの分析を示しています。

     ...
     WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values
     
           KERNEL: /usr/lib/debug/lib/modules/4.18.0-5.el8.x86_64/vmlinux
         DUMPFILE: /var/crash/127.0.0.1-2018-10-06-14:05:33/vmcore  [PARTIAL DUMP]
             CPUS: 2
             DATE: Sat Oct  6 14:05:16 2018
           UPTIME: 01:03:57
     LOAD AVERAGE: 0.00, 0.00, 0.00
            TASKS: 586
         NODENAME: localhost.localdomain
          RELEASE: 4.18.0-5.el8.x86_64
          VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018
          MACHINE: x86_64  (2904 Mhz)
           MEMORY: 2.9 GB
            PANIC: "sysrq: SysRq : Trigger a crash"
              PID: 10635
          COMMAND: "bash"
             TASK: ffff8d6c84271800  [THREAD_INFO: ffff8d6c84271800]
              CPU: 1
            STATE: TASK_RUNNING (SYSRQ)
     
     crash>

2. 対話型プロンプトを終了して crash を終了するには、crash または q を使用します。

   例15.2 crash ユーティリティーの終了

   crash> exit
   ~]#

手順

1. Kernel Oops Analyzer ツールにアクセスします。

2. カーネルクラッシュの問題を診断するには、vmcore に生成されたカーネルの oops ログをアップロードします。

   • テキストメッセージまたは vmcore-dmesg.txt を入力として指定して、カーネルクラッシュの問題を診断することも可能です。

     
3. DETECT をクリックして、makedumpfile からの情報に基づいて既知のソリューションと oops メッセージを比較します。

手順

1. kdump サービスが有効でアクティブであることを確認します。

   # systemctl is-enabled kdump.service && systemctl is-active kdump.service enabled active

   kdump が有効ではなく、実行されていない場合は、必要な設定をすべて設定し、kdump サービスが有効化されていることを確認します。

2. 起動カーネルの initramfs イメージを、early kdump 機能で再構築します。

   dracut -f --add earlykdump

3. rd.earlykdump カーネルコマンドラインパラメーターを追加します。

   grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="rd.earlykdump"

4. システムを再起動して、変更を反映させます。

   reboot

5. 必要に応じて、rd.earlykdump が正常に追加され、early kdump 機能が有効になっていることを確認します。

   # cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-187.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet rd.earlykdump
   
   # journalctl -x | grep early-kdump
   Mar 20 15:44:41 redhat dracut-cmdline[304]: early-kdump is enabled.
   Mar 20 15:44:42 redhat dracut-cmdline[304]: kexec: loaded early-kdump kernel

1. カーネルパッチモジュールは、/var/lib/kpatch/ ディレクトリーにコピーされ、次回の起動時に systemd を介して、カーネルへの再適用として登録されます。
2. 実行中のカーネルに kpatch モジュールがロードされ、新しいコードのメモリー内の場所を指定するポインターを使用して、新しい機能が ftrace メカニズムに登録されます。
3. パッチが当てられた機能にカーネルがアクセスすると、ftrace メカニズムにリダイレクトされます。これにより、元々の機能は回避され、パッチを当てたバージョンの機能にカーネルをリダイレクトします。

手順

1. 必要に応じて、カーネルバージョンを確認します。

   # uname -r
   4.18.0-94.el8.x86_64

2. カーネルのバージョンに一致するライブパッチパッケージを検索します。

   # yum search $(uname -r)

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

   # yum install "kpatch-patch = $(uname -r)"

   上記のコマンドでは、特定カーネルにのみに最新の累積パッチをインストールし、適用します。

   ライブパッチパッケージのバージョンが 1-1 以上である場合には、パッケージにパッチモジュールが含まれます。この場合、ライブパッチパッケージのインストール時に、カーネルにパッチが自動的に適用されます。

   カーネルパッチモジュールは、今後の再起動時に systemd システムおよびサービスマネージャーにより読み込まれる /var/lib/kpatch/ ディレクトリーにもインストールされます。

   注記

   指定のカーネルに利用可能なライブパッチがない場合は、空のライブパッチパッケージがインストールされます。空のライブパッチパッケージには、kpatch_version-kpatch_release 0-0 (例: kpatch-patch-4_18_0-94-0-0.el8.x86_64.rpm) が含まれます。空の RPM のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。

4. 必要に応じて、カーネルがパッチを当てていることを確認します。

   # kpatch list
   Loaded patch modules:
   kpatch_4_18_0_94_1_1 [enabled]
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
   …​

   この出力は、カーネルパッチモジュールがカーネルに読み込まれていることを示しています。つまり、カーネルは現在、kpatch-patch-4_18_0-94-1-1.el8.x86_64.rpm パッケージの最新の修正でパッチが当てられています。

手順

1. 必要に応じて、インストール済みの全カーネルと、現在実行中のカーネルを確認します。

   # yum list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64         4.18.0-240.10.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   kernel-core.x86_64         4.18.0-240.15.1.el8_3           @rhel-8-for-x86_64-baseos-rpms
   ...
   
   # uname -r
   4.18.0-240.10.1.el8_3.x86_64

2. kpatch-dnf プラグインをインストールします。

   # yum install kpatch-dnf

3. カーネルライブパッチの自動サブスクリプションを有効にします。

   # yum kpatch auto
   Updating Subscription Management repositories.
   Last metadata expiration check: 19:10:26 ago on Wed 10 Mar 2021 04:08:06 PM CET.
   Dependencies resolved.
   ==================================================
    Package                             Architecture
   ==================================================
   Installing:
    kpatch-patch-4_18_0-240_10_1        x86_64
    kpatch-patch-4_18_0-240_15_1        x86_64
   
   Transaction Summary
   ===================================================
   Install  2 Packages
   …​

   このコマンドは、現在インストールされているすべてのカーネルをサブスクライブして、カーネルライブパッチを受け取ります。このコマンドは、インストールされている全カーネルに、最新の累積パッチ (存在する場合) をインストールして適用します。

   今後、カーネルを更新すると、新しいカーネルのインストールプロセス中にライブパッチが自動的にインストールされます。

   カーネルパッチモジュールは、今後の再起動時に systemd システムおよびサービスマネージャーにより読み込まれる /var/lib/kpatch/ ディレクトリーにもインストールされます。

   注記

   指定のカーネルに利用可能なライブパッチがない場合は、空のライブパッチパッケージがインストールされます。空のライブパッチパッケージには、kpatch_version-kpatch_release 0-0 (例: kpatch-patch-4_18_0-240-0-0.el8.x86_64.rpm) が含まれます。空の RPM のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。

4. 必要に応じて、インストールされているすべてのカーネルにパッチが当てられていることを確認します。

   # kpatch list
   Loaded patch modules:
   kpatch_4_18_0_240_10_1_0_1 [enabled]
   
   Installed patch modules:
   kpatch_4_18_0_240_10_1_0_1 (4.18.0-240.10.1.el8_3.x86_64)
   kpatch_4_18_0_240_15_1_0_2 (4.18.0-240.15.1.el8_3.x86_64)

   この出力から、実行中のカーネルとインストールされている他のカーネル両方に kpatch-patch-4_18_0-240_10_1-0-1.rpm と kpatch-patch-4_18_0-240_15_1-0-1.rpm パッケージそれぞれからの修正が適用されたことが分かります。

手順

1. ライブパッチパッケージを選択します。

   # yum list installed | grep kpatch-patch
   kpatch-patch-4_18_0-94.x86_64        1-1.el8        @@commandline
   …​

   上記の出力例は、インストールしたライブパッチパッケージを一覧表示します。

2. ライブパッチパッケージを削除します。

   # yum remove kpatch-patch-4_18_0-94.x86_64

   ライブパッチパッケージが削除されると、カーネルは次回の再起動までパッチが当てられたままになりますが、カーネルパッチモジュールはディスクから削除されます。今後の再起動では、対応するカーネルにはパッチが適用されなくなります。

3. システムを再起動します。

4. ライブパッチパッケージが削除されたことを確認します。

   # yum list installed | grep kpatch-patch

   パッケージが正常に削除された場合、このコマンドでは何も出力されません。

5. 必要に応じて、カーネルのライブパッチソリューションが無効になっていることを確認します。

   # kpatch list
   Loaded patch modules:

   この出力例では、現在読み込まれているパッチモジュールがないため、カーネルにパッチが適用されておらず、ライブパッチソリューションがアクティブでないことが示されています。

手順

1. カーネルパッチモジュールを選択します。

   # kpatch list
   Loaded patch modules:
   kpatch_4_18_0_94_1_1 [enabled]
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)
   …​

2. 選択したカーネルパッチモジュールをアンインストールします。

   # kpatch uninstall kpatch_4_18_0_94_1_1
   uninstalling kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

   • アンインストールしたカーネルモジュールが読み込まれていることに注意してください。

     # kpatch list
     Loaded patch modules:
     kpatch_4_18_0_94_1_1 [enabled]
     
     Installed patch modules:
     <NO_RESULT>

     選択したモジュールをアンインストールすると、カーネルは次回の再起動までパッチが当てられますが、カーネルパッチモジュールはディスクから削除されます。

3. システムを再起動します。

4. 必要に応じて、カーネルパッチモジュールがアンインストールされていることを確認します。

   # kpatch list
   Loaded patch modules:
   …​

   上記の出力例では、ロードまたはインストールされたカーネルパッチモジュールが表示されていません。したがって、カーネルにパッチが適用されておらず、カーネルのライブパッチソリューションはアクティブではありません。

手順

1. kpatch.service が有効化されていることを確認します。

   # systemctl is-enabled kpatch.service
   enabled

2. kpatch.service を無効にします。

   # systemctl disable kpatch.service
   Removed /etc/systemd/system/multi-user.target.wants/kpatch.service.

   • 適用されたカーネルモジュールが依然としてロードされていることに注意してください。

     # kpatch list
     Loaded patch modules:
     kpatch_4_18_0_94_1_1 [enabled]
     
     Installed patch modules:
     kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

3. システムを再起動します。

4. 必要に応じて、kpatch.service のステータスを確認します。

   # systemctl status kpatch.service
   ● kpatch.service - "Apply kpatch kernel patches"
      Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

   この出力テストサンプルでは、kpatch.service が無効になっており、実行されていないことを証明しています。したがって、カーネルのライブパッチソリューションはアクティブではありません。

5. カーネルパッチモジュールがアンロードされたことを確認します。

   # kpatch list
   Loaded patch modules:
   <NO_RESULT>
   
   Installed patch modules:
   kpatch_4_18_0_94_1_1 (4.18.0-94.el8.x86_64)

   上記の出力例では、カーネルパッチモジュールがインストールされていても、カーネルにパッチが適用されていないことを示しています。

手順

1. CPU 消費を制限するアプリケーションのプロセス ID (PID) を特定します。

   # top
   top - 11:34:09 up 11 min,  1 user,  load average: 0.51, 0.27, 0.22
   Tasks: 267 total,   3 running, 264 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 49.0 us,  3.3 sy,  0.0 ni, 47.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.0 st
   MiB Mem :   1826.8 total,    303.4 free,   1046.8 used,    476.5 buff/cache
   MiB Swap:   1536.0 total,   1396.0 free,    140.0 used.    616.4 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  99.3   0.1   0:32.71 sha1sum
    5760 jdoe      20   0 3603868 205188  64196 S   3.7  11.0   0:17.19 gnome-shell
    6448 jdoe      20   0  743648  30640  19488 S   0.7   1.6   0:02.73 gnome-terminal-
       1 root      20   0  245300   6568   4116 S   0.3   0.4   0:01.87 systemd
     505 root      20   0       0      0      0 I   0.3   0.0   0:00.75 kworker/u4:4-events_unbound
   ...

   top プログラムの出力例は、PID 6955 (具体例のアプリケーション sha1sum) が CPU リソースを大量に消費することを示しています。

2. cpu リソースコントローラーディレクトリーにサブディレクトリーを作成します。

   # mkdir /sys/fs/cgroup/cpu/Example/

   上記のディレクトリーは、特定のプロセスを配置でき、特定の CPU 制限をプロセスに適用できるコントロールグループです。同時に、一部の cgroups-v1 インターフェースファイルと cpu コントローラー固有のファイルがディレクトリーに作成されます。

3. 必要に応じて、新しく作成されたコントロールグループを確認します。

   # ll /sys/fs/cgroup/cpu/Example/
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cgroup.procs
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 cpu.shares
   -r—​r—​r--. 1 root root 0 Mar 11 11:42 cpu.stat
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 notify_on_release
   -rw-r—​r--. 1 root root 0 Mar 11 11:42 tasks

   この出力例は、特定の設定や制限を表す cpuacct.usage、cpu.cfs._period_us などのファイルを示しています。これは、Example コントロールグループのプロセスに設定できます。各ファイル名の前に、そのファイルが属するコントロールグループコントローラーの名前が接頭辞として追加されることに注意してください。

   デフォルトでは、新しく作成されたコントロールグループは、システムの CPU リソース全体へのアクセスを制限なしで継承します。

4. コントロールグループの CPU 制限を設定します。

   # echo "1000000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us
   # echo "200000" > /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us

   cpu.cfs_period_us ファイルは、制御グループの CPU リソースへのアクセスが再割り当てされる頻度について、マイクロ秒単位の期間 (ここでは「us」と表示されますが µs) を表します。上限は 1 秒で、下限は 1000 マイクロ秒です。

   cpu.cfs_quota_us ファイルは、(cpu.cfs_period_us で定義されるように) コントロールグループのすべてのプロセスを 1 期間中に実行できる合計時間をマイクロ秒単位で表します。1 期間中にコントロールグループ内のプロセスがクォータで指定された時間をすべて使いきるとすぐに、残りの期間はスロットルされて、次の期間まで実行できなくなります。下限は 1000 マイクロ秒です。

   上記のコマンド例は、CPU 時間制限を設定して、Example コントロールグループでまとめられているすべてのプロセスは、1 秒ごと (cpu.cfs_period_us に定義されている) に、0.2 秒間だけ (cpu.cfs_quota_us に定義されている) 実行できるようにしています。

5. 必要に応じて、制限を確認します。

   # cat /sys/fs/cgroup/cpu/Example/cpu.cfs_period_us /sys/fs/cgroup/cpu/Example/cpu.cfs_quota_us
   1000000
   200000

6. アプリケーションの PID を Example コントロールグループに追加します。

   # echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs
   
   or
   
   # echo "6955" > /sys/fs/cgroup/cpu/Example/tasks

   上記のコマンドは、目的のアプリケーションが Example コントロールグループのメンバーとなるようするので、Example コントロールグループに設定された CPU 制限は超えません。PID は、システム内の既存のプロセスを表します。ここで PID 6955 は、プロセス sha1sum /dev/zero & に割り当てられ、cpu コントローラーの使用例を示すために使用されました。

7. アプリケーションが指定のコントロールグループで実行されていることを確認します。

   # cat /proc/6955/cgroup
   12:cpuset:/
   11:hugetlb:/
   10:net_cls,net_prio:/
   9:memory:/user.slice/user-1000.slice/user@1000.service
   8:devices:/user.slice
   7:blkio:/
   6:freezer:/
   5:rdma:/
   4:pids:/user.slice/user-1000.slice/user@1000.service
   3:perf_event:/
   2:cpu,cpuacct:/Example
   1:name=systemd:/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

   上記の出力例は、目的のアプリケーションのプロセスが Example のコントロールグループで実行され、アプリケーションのプロセスに CPU 制限が適用されることを示しています。

8. スロットルしたアプリケーションの現在の CPU 使用率を特定します。

   # top
   top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
   Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
   MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
   MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
   
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    6955 root      20   0  228440   1752   1472 R  20.6   0.1  47:11.43 sha1sum
    5760 jdoe      20   0 3604956 208832  65316 R   2.3  11.2   0:43.50 gnome-shell
    6448 jdoe      20   0  743836  31736  19488 S   0.7   1.7   0:08.25 gnome-terminal-
     505 root      20   0       0      0      0 I   0.3   0.0   0:03.39 kworker/u4:4-events_unbound
    4217 root      20   0   74192   1612   1320 S   0.3   0.1   0:01.19 spice-vdagentd
   ...

   PID 6955 の CPU 消費が 99% から 20% に減少していることに注意してください。

手順

1. サービスのメモリー使用量を制限するには、以下のように /usr/lib/systemd/system/example.service ファイルを変更します。

   …​
   [Service]
   MemoryLimit=1500K
   …​

   上記の設定では、(example.service が含まれる) コントロールグループで実行されるプロセスの最大メモリー消費量に制限があります。

   注記

   測定単位のキロバイト、メガバイト、ギガバイト、またはテラバイトを指定するには、接尾辞 K、M、G、または T を使用します。

2. すべてのユニット設定ファイルを再読み込みします。

   # systemctl daemon-reload

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

   # systemctl restart example.service

4. システムを再起動します。

5. 必要に応じて、変更が反映されたことを確認します。

   # cat /sys/fs/cgroup/memory/system.slice/example.service/memory.limit_in_bytes
   1536000

   この出力例では、メモリー消費量が約 1,500 キロバイトに制限されていることを示しています。

   注記

   memory.limit_in_bytes ファイルは、メモリー制限を 4096 バイトの倍数 (AMD64 および Intel 64 に固有のカーネルページサイズ) として保存します。実際のバイト数は、CPU アーキテクチャーによって異なります。

手順

1. サービスユニットを停止します。

   # systemctl stop <name>.service

2. サービスユニットを無効にします。

   # systemctl disable <name>.service

3. 関連するユニット設定ファイルを削除します。

   # rm /usr/lib/systemd/system/<name>.service

4. すべてのユニット設定ファイルを再度読み込み、変更を有効にします。

   # systemctl daemon-reload

手順

1. プロセスが対話するリソースコントローラーを表示するには、# cat proc/<PID>/cgroup コマンドを実行します。

   # cat /proc/11269/cgroup
   12:freezer:/
   11:cpuset:/
   10:devices:/system.slice
   9:memory:/system.slice/example.service
   8:pids:/system.slice/example.service
   7:hugetlb:/
   6:rdma:/
   5:perf_event:/
   4:cpu,cpuacct:/
   3:net_cls,net_prio:/
   2:blkio:/
   1:name=systemd:/system.slice/example.service

   この出力例は、対象のプロセスに関するものです。今回の例では、example.service ユニットに属する PID 11269 で識別されるプロセスです。systemd ユニットファイルの仕様で定義されているように、適切なコントロールグループにプロセスが置かれているかどうかを判断できます。

   注記

   デフォルトでは、デフォルトのリソースコントローラーがすべて自動的にマウントされるため、リソースコントローラーの一覧にある項目とその順序は、systemd が起動するすべてのユニットで同じになります。

手順

1. 現在実行中の cgroups の動的アカウントを表示するには、# systemd-cgtop コマンドを実行します。

   # systemd-cgtop
   Control Group                            Tasks   %CPU   Memory  Input/s Output/s
   /                                          607   29.8     1.5G        -        -
   /system.slice                              125      -   428.7M        -        -
   /system.slice/ModemManager.service           3      -     8.6M        -        -
   /system.slice/NetworkManager.service         3      -    12.8M        -        -
   /system.slice/accounts-daemon.service        3      -     1.8M        -        -
   /system.slice/boot.mount                     -      -    48.0K        -        -
   /system.slice/chronyd.service                1      -     2.0M        -        -
   /system.slice/cockpit.socket                 -      -     1.3M        -        -
   /system.slice/colord.service                 3      -     3.5M        -        -
   /system.slice/crond.service                  1      -     1.8M        -        -
   /system.slice/cups.service                   1      -     3.1M        -        -
   /system.slice/dev-hugepages.mount            -      -   244.0K        -        -
   /system.slice/dev-mapper-rhel\x2dswap.swap   -      -   912.0K        -        -
   /system.slice/dev-mqueue.mount               -      -    48.0K        -        -
   /system.slice/example.service                2      -     2.0M        -        -
   /system.slice/firewalld.service              2      -    28.8M        -        -
   ...

   この出力例では、現在実行中の cgroups が、リソースの使用状況 (CPU、メモリー、ディスク I/O 負荷) 別に表示されています。デフォルトでは 1 秒ごとに一覧が更新されます。そのため、コントロールグループごとに、実際のリソースの使用状況について動的な見解が得られるようになります。

1. 選択したサービスで、CPU 時間割り当てポリシーオプションに割り当てた値を確認します。

   $ systemctl show --property <CPU time allocation policy option> <service name>

2. root として、CPU 時間割り当てポリシーのオプションで必要な値を設定します。

   # systemctl set-property <service name> <CPU time allocation policy option>=<value>

   注記

   cgroup プロパティーは、プロパティーの設定直後に適用されます。したがって、このサービスを再起動する必要はありません。

1. 選択したサービスで、メモリー割り当て設定オプションに割り当てた値を確認します。

   $ systemctl show --property <memory allocation configuration option> <service name>

2. root として、メモリー割り当ての設定オプションで必要な値を設定します。

   # systemctl set-property <service name> <memory allocation configuration option>=<value>

1. 選択したサービスで、I/O 帯域幅設定オプションに割り当てた値を確認します。

   $ systemctl show --property <I/O bandwidth configuration option> <service name>

2. root として、I/O 帯域幅の設定オプションで必要な値を設定します。

   # systemctl set-property <service name> <I/O bandwidth configuration option>=<value>

1. 選択したサービスで CPUAffinity ユニットファイルオプションの値を確認します。

   $ systemctl show --property <CPU affinity configuration option> <service name>

2. root として、アフィニティーマスクとして使用する CPU 範囲の CPUAffinity ユニットファイルで必要な値を設定します。

   # systemctl set-property <service name> CPUAffinity=<value>

3. サービスを再起動して変更を適用します。

   # systemctl restart <service name>

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

   # vi /etc/systemd/system.conf

2. CPUAffinity= オプションを検索して、CPU 数を設定します。
3. 編集したファイルを保存し、サーバーを再起動して変更を適用します。

1. 選択したサービスで NUMAPolicy ユニットファイルオプションの値を確認します。

   $ systemctl show --property <NUMA policy configuration option> <service name>

2. root として、NUMAPolicy ユニットファイルオプションに必要なポリシータイプを設定します。

   # systemctl set-property <service name> NUMAPolicy=<value>

3. サービスを再起動して変更を適用します。

   # systemctl restart <service name>

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

   # vi /etc/systemd/system.conf

2. NUMAPolicy オプションを検索し、ポリシー種別を設定します。
3. 編集したファイルを保存し、サーバーを再起動して変更を適用します。

手順

1. bcc-tools をインストールします。

   # yum install bcc-tools

   BCC ツールは、/usr/share/bcc/tools/ ディレクトリーにインストールされます。

2. 必要に応じて、ツールを検証します。

   # ll /usr/share/bcc/tools/
   ...
   -rwxr-xr-x. 1 root root  4198 Dec 14 17:53 dcsnoop
   -rwxr-xr-x. 1 root root  3931 Dec 14 17:53 dcstat
   -rwxr-xr-x. 1 root root 20040 Dec 14 17:53 deadlock_detector
   -rw-r--r--. 1 root root  7105 Dec 14 17:53 deadlock_detector.c
   drwxr-xr-x. 3 root root  8192 Mar 11 10:28 doc
   -rwxr-xr-x. 1 root root  7588 Dec 14 17:53 execsnoop
   -rwxr-xr-x. 1 root root  6373 Dec 14 17:53 ext4dist
   -rwxr-xr-x. 1 root root 10401 Dec 14 17:53 ext4slower
   ...

   上記の一覧にある doc ディレクトリーには、各ツールのドキュメントが含まれます。

1. ある端末で execsnoop プログラムを実行します。

   # /usr/share/bcc/tools/execsnoop

2. 別の端末で、以下のように実行します。

   $ ls /usr/share/bcc/tools/doc/

   これにより、ls コマンドの短命プロセスが作成されます。

3. execsnoop を実行している端末は、以下のような出力を表示します。

   PCOMM	PID    PPID   RET ARGS
   ls   	8382   8287     0 /usr/bin/ls --color=auto /usr/share/bcc/tools/doc/
   sed 	8385   8383     0 /usr/bin/sed s/^ *[0-9]\+ *//
   ...

   execsnoop プログラムは、新しいプロセスごとに出力行を出力するため、システムリソースを消費します。また、ls などの非常に短期間に実行されるプログラムのプロセスを検出します。なお、ほとんどの監視ツールはそれらを登録しません。

   execsnoop 出力には以下のフィールドが表示されます。

   • PCOMM - 親プロセス名。(ls)
   • PID - プロセス ID(8382)
   • ppid: 親プロセス ID。(8287)
   • RET - exec() のシステム呼び出しの戻り値 (0)。プログラムコードを新規プロセスに読み込みます。
   • ARGS - 引数を使用して開始したプログラムの場所。

1. ある端末で opensnoop プログラムを実行します。

   # /usr/share/bcc/tools/opensnoop -n uname

   上記の出力では、uname コマンドのプロセスによってのみ開かれるファイルの内容が出力されます。

2. 別の端末で、以下を実行します。

   $ uname

   上記のコマンドは、特定のファイルを開きます。このファイルは次のステップでキャプチャーされます。

3. opensnoop を実行している端末は、以下のような出力を表示します。

   PID    COMM 	FD ERR PATH
   8596   uname 	3  0   /etc/ld.so.cache
   8596   uname 	3  0   /lib64/libc.so.6
   8596   uname 	3  0   /usr/lib/locale/locale-archive
   ...

   opensnoop プログラムは、システム全体で open() システム呼び出しを監視し、uname が開こうとしたファイルごとに出力行を出力します。

   opensnoop 出力には、以下のフィールドが表示されます。

   • PID - プロセス ID(8596)
   • COMM - プロセス名 (uname)
   • FD - ファイルの記述子。開いたファイルを参照するために open() が返す値。(3)
   • ERR - すべてのエラー

   • PATH - open() で開こうとしたファイルの場所。

     コマンドが、存在しないファイルを読み込もうとすると、FD コラムは -1 を返し、ERR コラムは関連するエラーに対応する値を出力します。その結果、opennoop は、適切に動作しないアプリケーションの特定に役立ちます。

1. ある端末で biotop プログラムを実行します。

   # /usr/share/bcc/tools/biotop 30

   このコマンドにより、ディスク上で I/O 操作を実行する上位のプロセスを監視できます。この引数は、コマンドが 30 秒の概要を生成するようにします。

   注記

   引数を指定しないと、デフォルトでは 1 秒ごとに出力画面が更新されます。

2. 別の端末では、以下のようになります。

   # dd if=/dev/vda of=/dev/zero

   上記のコマンドは、ローカルのハードディスクデバイスからコンテンツを読み込み、出力を /dev/zero ファイルに書き込みます。この手順では、biotop を示す特定の I/O トラフィックを生成します。

3. biotop を実行している端末は、以下のような出力を表示します。

   PID    COMM             D MAJ MIN DISK       I/O  Kbytes     AVGms
   9568   dd               R 252 0   vda      16294 14440636.0  3.69
   48     kswapd0          W 252 0   vda       1763 120696.0    1.65
   7571   gnome-shell      R 252 0   vda        834 83612.0     0.33
   1891   gnome-shell      R 252 0   vda       1379 19792.0     0.15
   7515   Xorg             R 252 0   vda        280  9940.0     0.28
   7579   llvmpipe-1       R 252 0   vda        228  6928.0     0.19
   9515   gnome-control-c  R 252 0   vda         62  6444.0     0.43
   8112   gnome-terminal-  R 252 0   vda         67  2572.0     1.54
   7807   gnome-software   R 252 0   vda         31  2336.0     0.73
   9578   awk              R 252 0   vda         17  2228.0     0.66
   7578   llvmpipe-0       R 252 0   vda        156  2204.0     0.07
   9581   pgrep            R 252 0   vda         58  1748.0     0.42
   7531   InputThread      R 252 0   vda         30  1200.0     0.48
   7504   gdbus            R 252 0   vda          3  1164.0     0.30
   1983   llvmpipe-1       R 252 0   vda         39   724.0     0.08
   1982   llvmpipe-0       R 252 0   vda         36   652.0     0.06
   ...

   biotop 出力には、以下のフィールドが表示されます。

   • PID - プロセス ID(9568)
   • COMM - プロセス名。(dd)
   • DISK - 読み取り操作を実行するディスク。(vda)
   • I/O - 実行された読み取り操作の数。(16294)
   • kbytes - 読み取り操作によって使用したバイト数 (KB)。(14,440,636)
   • AVGms - 読み取り操作の平均 I/O 時間。(3.69)

1. 端末で xfsslower プログラムを実行します。

   # /usr/share/bcc/tools/xfsslower 1

   上記のコマンドは、XFS ファイルシステムが、読み込み、書き込み、開く、または同期 (fsync) 操作を実行するのに費やした時間を測定します。1 引数を指定すると、1 ms よりも遅い操作のみが表示されます。

   注記

   引数を指定しないと、xfsslower はデフォルトで 10 ms よりも低速な操作を表示します。

2. 別の端末で、たとえば以下を実行します。

   $ vim text

   上記のコマンドは、vim エディターでテキストファイルを作成し、XFS ファイルシステムと特定の対話を開始します。

3. xfsslower を実行している端末は、前の手順でファイルを保存した場合と同様の内容を示しています。

   TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
   13:07:14 b'bash'        4754   R 256     0           7.11 b'vim'
   13:07:14 b'vim'         4754   R 832     0           4.03 b'libgpm.so.2.1.0'
   13:07:14 b'vim'         4754   R 32      20          1.04 b'libgpm.so.2.1.0'
   13:07:14 b'vim'         4754   R 1982    0           2.30 b'vimrc'
   13:07:14 b'vim'         4754   R 1393    0           2.52 b'getscriptPlugin.vim'
   13:07:45 b'vim'         4754   S 0       0           6.71 b'text'
   13:07:45 b'pool'        2588   R 16      0           5.58 b'text'
   ...

   上記の各行はファイルシステム内の操作を表し、特定のしきい値よりも時間がかかります。xfsslower は、操作に想定以上に時間がかかるなど、ファイルシステムで発生し得る問題を表面化するのに適しています。

   xfsslower 出力には、以下のフィールドが表示されます。

   • COMM - プロセス名。(b'bash')

   • T - 操作の種類。(R)

     • Read
     • Write
     • Sync
   • OFF_KB - ファイルオフセット(KB)。(0)
   • FILENAME - 読み取り、書き込み、または同期するファイルです。

手順

1. TPM を使用して信頼できる鍵を作成するには、次のコマンドを実行します。

   # keyctl add trusted <name> "new <key_length> [options]" <key_ring>

   • 構文に基づいて、以下のようにサンプルコマンドを作成します。

     # keyctl add trusted kmk "new 32" @u
     642500861

     このコマンドは、kmk という名前の信頼できる鍵を 32 バイト (256 ビット) の長さで作成し、ユーザーキーリング (@u) に配置します。鍵の長さは 32 から 128 バイト (256 から 1024 ビット) です。

2. カーネルキーリングの現在の構造を一覧表示するには、以下を実行します。

   # keyctl show
   Session Keyring
          -3 --alswrv    500   500  keyring: _ses
    97833714 --alswrv    500    -1   \_ keyring: _uid.1000
   642500861 --alswrv    500   500       \_ trusted: kmk

3. ユーザー空間のブロブに鍵をエクスポートするには、次のコマンドを実行します。

   # keyctl pipe 642500861 > kmk.blob

   このコマンドは、pipe サブコマンドと kmk のシリアル番号を使用します。

4. ユーザー空間のブロブから信頼できる鍵を読み込むには、ブログを引数として add サブコマンドを使用します。

   # keyctl add trusted kmk "load `cat kmk.blob`" @u
   268728824

5. TPM で保護された信頼できる鍵に基づいて、安全な暗号化された鍵を作成します。

   # keyctl add encrypted <pass:quotes[name]> "new [format] <pass:quotes[key_type]>:<pass:quotes[primary_key_name]> <pass:quotes[keylength]>" <pass:quotes[key_ring]>

   • 構文に基づいて、すでに作成された信頼できる鍵を使用して暗号化鍵を生成します。

     # keyctl add encrypted encr-key "new trusted:kmk 32" @u
     159771175

     このコマンドは、前の手順で生成した TPM で保護された信頼できる鍵 (kmk) を、暗号化鍵を生成する プライマリーキー として使用します。

手順

1. 無作為な数列を使用してユーザーキーを生成します。

   # keyctl add user kmk-user "$(dd if=/dev/urandom bs=1 count=32 2>/dev/null)" @u
   427069434

   このコマンドは、kmk-user という名前のユーザーキーを生成し、プライマリーキー として動作させ、このユーザーキーを使用して実際の暗号化鍵を保護します。

2. 前の手順で取得したプライマリーキーを使用して、暗号化鍵を生成します。

   # keyctl add encrypted encr-key "new user:kmk-user 32" @u
   1012412758

3. 必要に応じて、指定したユーザーキーリングにあるすべての鍵を一覧表示します。

   # keyctl list @u
   2 keys in keyring:
   427069434: --alswrv  1000  1000 user: kmk-user
   1012412758: --alswrv  1000  1000 encrypted: encr-key

手順

1. 以下のカーネルコマンドラインパラメーターを追加します。

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="ima_policy=appraise_tcb ima_appraise=fix evm=fix"

   このコマンドは、現在のブートエントリーの fix モードで IMA および EVM を有効にしてユーザーが IMA 測定を収集し、更新できるようにします。

   ima_policy=appraise_tcb カーネルコマンドラインパラメーターにより、カーネルは、デフォルトの TCB (Trusted Computing Base) 測定ポリシーと評価手順を使用するようになります。評価部分は、以前の測定と現在の測定が一致しないファイルへのアクセスを禁止します。

2. 再起動して変更を適用します。

3. 必要に応じて、パラメーターがカーネルコマンドラインに追加されていることを確認します。

   # cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ima_policy=appraise_tcb ima_appraise=fix evm=fix

4. カーネルマスターキーを作成して、EVM 鍵を保護します。

   # keyctl add user kmk "$(dd if=/dev/urandom bs=1 count=32 2> /dev/null)" @u
   748544121

   カーネルマスターキー (kmk) はすべて、カーネル領域メモリーに保持されます。カーネルマスターキー kmk の 32 バイトの Long 値は、/dev/urandom ファイルの乱数バイト数から生成し、ユーザーの (@u) キーリングに配置します。鍵のシリアル番号は、前の出力の 2 行目にあります。

5. kmk 鍵をもとに暗号化された EVM 鍵を作成します。

   # keyctl add encrypted evm-key "new user:kmk 64" @u
   641780271

   kmk を使用して 64 バイトの long 型ユーザーキー (evm-key) を生成してユーザー (@u) のキーリングに配置します。鍵のシリアル番号は、前の出力の 2 行目にあります。

   重要

   ユーザーキーの名前は evm-key (EVM サブシステムが想定して使用している名前) にする必要があります。

6. エクスポートする鍵のディレクトリーを作成します。

   # mkdir -p /etc/keys/

7. kmk 鍵を検索し、その値をファイルにエクスポートします。

   # keyctl pipe keyctl search @u user kmk > /etc/keys/kmk*

   このコマンドは、カーネルマスターキー (kmk) の非暗号化値を、以前に定義した場所 (/etc/keys/) にあるファイルに配置します。

8. ユーザーキー evm-key を検索し、その値をファイルにエクスポートします。

   # keyctl pipe keyctl search @u encrypted evm-key > /etc/keys/evm-key

   このコマンドは、ユーザーの evm-key 鍵の暗号化値を、任意の場所にあるファイルに追加します。evm-key は、すでにカーネルのマスターキーにより暗号化されています。

9. 必要に応じて、新規作成されたキーを表示します。

   # keyctl show
   Session Keyring
   974575405   --alswrv     0        0      keyring: _ses
   299489774   --alswrv     0    65534       \_ keyring: _uid.0
   748544121   --alswrv     0        0           \_ user: kmk
   641780271   --alswrv     0        0           \_ encrypted: evm-key

   同様の出力が表示されるはずです。

10. EVM をアクティベートします。

    # echo 1 > /sys/kernel/security/evm

11. 必要に応じて、EVM が初期化されていることを確認します。

    # dmesg | tail -1
    […​] evm: key initialized

手順

1. テストファイルを作成します。

   # echo <Test_text> > test_file

   IMA および EVM には、サンプルファイル test_file にハッシュ値が割り当てられ、拡張属性として保存されます。

2. ファイルの拡張属性を検証します。

   # getfattr -m . -d test_file
   # file: test_file
   security.evm=0sAnDIy4VPA0HArpPO/EqiutnNyBql
   security.ima=0sAQOEDeuUnWzwwKYk+n66h/vby3eD
   security.selinux="unconfined_u:object_r:admin_home_t:s0"

   上記の出力例では、SELinux、IMA ハッシュ値、および EVM ハッシュ値に関連する拡張属性を示しています。EVM は、security.evm 拡張属性をアクティブに追加し、ファイルのコンテンツの整合性に直接関連する security.ima などの他のファイルの xattrs に対するオフライン改ざんを検出します。security.evm フィールドの値は、evm-key ユーザーキーで生成された Hash-based Message Authentication Code (HMAC-SHA1) になります。

手順

1. 必要に応じて、図の目的で inventory ファイルを確認します。

   #  cat /home/jdoe/<ansible_project_name>/inventory
   [testingservers]
   pdoe@192.168.122.98
   fdoe@192.168.122.226
   
   [db-servers]
   db1.example.com
   db2.example.com
   
   [webservers]
   web1.example.com
   web2.example.com
   192.0.2.42

   ファイルは [testingservers] グループと他のグループを定義します。これにより、特定のシステムのコレクションに対して Ansible Engine をより効果的に実行できます。

2. Ansible Engine 操作のデフォルトおよび権限昇格を設定するための設定ファイルを作成します。

   1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      #  vi /home/jdoe/<ansible_project_name>/ansible.cfg

   2. 以下の内容をファイルに挿入します。

      [defaults]
      inventory = ./inventory
      
      [privilege_escalation]
      become = true
      become_method = sudo
      become_user = root
      become_ask_pass = true

      [defaults] セクションは、管理対象ホストのインベントリーファイルへのパスを指定します。[privilege_escalation] セクションでは、指定した管理対象ホストのユーザー権限が root に移行されることを定義します。これは、カーネルパラメーターを正常に設定するために必要です。Ansible Playbook を実行すると、ユーザーパスワードの入力が求められます。管理対象ホストへの接続後に、sudo により root に自動的に切り替わります。

3. kernel_settings ロールを使用する Ansible Playbook を作成します。

   1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      #  vi /home/jdoe/<ansible_project_name>/kernel_roles.yml

      このファイルは Playbook を表し、通常は、inventory ファイルから選択した特定の管理対象ホストに対して実行される、プレイ とも呼ばれるタスクの順序付きリストが含まれます。

   2. 以下の内容をファイルに挿入します。

      ---
      - name: Configure kernel settings
        hosts: testingservers
      
        vars:
          kernel_settings_sysctl:
            - name: fs.file-max
              value: 400000
            - name: kernel.threads-max
              value: 65536
          kernel_settings_sysfs:
            - name: /sys/class/net/lo/mtu
              value: 65000
          kernel_settings_transparent_hugepages: madvise
      
        roles:
          - linux-system-roles.kernel_settings

      name キーは任意です。任意の文字列をラベルとしてプレイに関連付け、プレイの対象を特定します。プレイの hosts キーは、プレイを実行するホストを指定します。このキーの値または値は、管理対象ホストの個別名または inventory ファイルで定義されているホストのグループとして指定できます。

      vars セクションは、設定する必要がある、選択したカーネルパラメーター名および値が含まれる変数の一覧を表します。

      roles キーは、vars セクションで説明されているパラメーターおよび値を設定するシステムロールを指定します。

      注記

      必要に応じて、Playbook のカーネルパラメーターとその値を変更することができます。

4. 必要に応じて、プレイ内の構文が正しいことを確認します。

   #  ansible-playbook --syntax-check kernel-roles.yml
   
   playbook: kernel-roles.yml

   以下の例では、Playbook の検証が成功したことを示しています。

5. Playbook を実行します。

   #  ansible-playbook kernel-roles.yml
   BECOME password:
   
   PLAY [Configure kernel settings]  ... PLAY RECAP **
   fdoe@192.168.122.226       : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0
   pdoe@192.168.122.98        : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0

   Ansible Engine が Playbook を実行する前に、パスワードの入力を求められます。これにより、管理対象ホストのユーザーが root に切り替わります。これは、カーネルパラメーターの設定に必要です。

   recap セクションは、すべての管理対象ホストのプレイが正常に終了したこと (failed=0)、および 4 つのカーネルパラメーターが適用されたこと (changed=4) を示しています。

6. 管理対象ホストを再起動して、影響を受けるカーネルパラメーターをチェックし、変更が適用され、再起動後も維持されていることを確認します。