第8章 既知の問題

本章では、Red Hat Enterprise Linux 7.9 の既知の問題を説明します。

8.1. 認証および相互運用性

最新のコンテナーイメージを使用して ipa-server をアップグレードすると、Active Directory との信頼が適切に動作しません。

最新バージョンのコンテナーイメージを使用して IdM サーバーをアップグレードすると、Active Directory ドメインとの既存の信頼は機能しなくなります。この問題を回避するには、既存の信頼を削除して、アップグレード後に再確立してください。

(BZ#1819745)

8.2. コンパイラーおよびツール

RHEL に同梱される GCC スレッドサニタイザーが動作しない

カーネルメモリーマッピングにおける非互換性変更により、RHEL の GNU C Compiler (GCC) コンパイラーのバージョンに同梱されるスレッドサニタイザーが動作しなくなりました。さらには、スレッドサニタイザーが互換性のないメモリーレイアウトには適用されません。これにより、RHEL に同梱される GCC スレッドサニタイザーは使用されなくなります。

回避策として、コードのビルドには、Red Hat Developer Toolset に同梱されるバージョンの GCC を使用してください。ここでは、スレッドサニタイザーが使用されています。

(BZ#1569484)

8.3. インストールおよび起動

DISA STIG プロファイルを使用して Server with GUI としてインストールされたシステムが正しく起動しない

DISA STIG プロファイルでは、xorg-x11-server-common (X Windows) パッケージの削除が要求されますが、デフォルトターゲットの変更は要求されません。そのため、システムは GUI を実行するように設定されていますが、X Windows パッケージがありません。したがって、システムが正常に起動しません。この問題を回避するには、Server with GUI ソフトウェアの選択で DISA STIG プロファイルを使用しないか、package_xorg-x11-server-common_removed ルールを削除してプロファイルをカスタマイズします。

(BZ#1648162)

8.4. カーネル

kdump の実行時に radeon ドライバーによってハードウェアが正しくリセットされない

kdump プロセスを実行した場合など、現在実行中のカーネルからカーネルを起動した場合に、現在は radeon カーネルドライバーによってハードウェアが適切にリセットされません。代わりに、kdump カーネルが突然終了するため、残りの kdump サービスが失敗します。

この問題を回避するには、/etc/kdump.conf ファイルに以下の行を追加して、kdumpradeon を無効にします。

dracut_args --omit-drivers "radeon"

その後、マシンおよび kdump を再起動します。

このシナリオでは、kdump 時にグラフィックは利用できませんが、kdump は問題なく完了します。

(BZ#1168430)

Windows Server 2019 ホストの RHEL 7 ゲストコンソールへの接続が遅い

Windows Server 2019 ホストで、RHEL 7 をマルチユーザーモードでゲストオペレーティングシステムとして使用すると、ゲストのコンソール出力へ接続するのに想定よりもはるかに長い時間がかかります。この問題を回避するには、SSH を使用してゲストに接続するか、ホストとして Windows Server 2016 を使用します。

(BZ#1706522)

RHEL 7 の Amazon c5a マシンで vmcore ファイルの生成に失敗する

Amazon c5a マシンでは、kdump カーネル内の フラットモード で設定されている場合に、Advanced Programmable Interrupt Controller (APIC) がローカル APIC (LAPIC) の割り込みをルーティングできなくなります。これにより、kdump カーネルは起動に失敗し、kdump カーネルで vmcore ファイルを保存して詳細な分析ができなくなります。

この問題を回避するには、以下のコマンドを実行します。

  1. crashkernel 引数を 256M に設定して、クラッシュカーネルサイズを増やします。

    $ grubby-args="crashkernel=256M" --update-kernel
    /boot/vmlinuz-`uname -r`
  2. /etc/sysconfig/kdump ファイルを編集して nr_cpus=9 オプションを設定します。

    KDUMP_COMMANDLINE_APPEND="irqpoll" *nr_cpus=9*
    reset_devices
    cgroup_disable=memory mce=off numa=off udev.children-
    max=2 panic=10 acpi_no_memhotplug
    transparent_hugepage=never nokaslr novmcoredd
    hest_disable

これにより、kdump カーネルは 9 つの CPU で起動し、カーネルクラッシュ時に vmcore ファイルがキャプチャーされます。kdump カーネルで 9 つの CPU が有効化されるため、kdump サービスは、大量のクラッシュカーネルメモリーを使用して vmcore ファイルをダンプできます。したがって、クラッシュカーネルには kdump カーネルの起動に 256 MB のサイズを確保してください。

(BZ#1844522)

一部の kretprobes を有効にするとカーネルパニックを引き起こす可能性がある

以下の関数 の kretprobes を使用すると CPU のハードロックが発生する可能性があります。

  • _raw_spin_lock
  • _raw_spin_lock_irqsave
  • _raw_spin_unlock_irqrestore
  • queued_spin_lock_slowpath

そのため、上記の kprobe イベントを有効にすると、システムの応答に失敗します。この状況では、カーネルパニックがトリガーされます。この問題を回避するには、上記の関数への kretprobes の設定を避けて、システム応答の失敗を防ぐようにしてください。

(BZ#1838903)

UEFI セキュアブートが有効になっているシステムで kdump サービスが失敗する

最新の RHEL カーネルバージョンで、UEFI セキュアブートが有効なシステムを起動すると、kdump サービスは起動に失敗します。上記のシナリオでは、kdump が以下のエラーメッセージを報告します。

kexec_file_load failed: Required key not available

この動作は、以下のいずれかが原因で表示されます。

  • 最新のカーネルバージョンでクラッシュカーネルを起動する。
  • /etc/sysconfig/kdump ファイルの KDUMP_KERNELVER 変数を最新のカーネルバージョンに設定する。

これにより、kdump が起動しなくるので、クラッシュイベント時にダンプコアは保存されません。

この問題を回避するには、以下のいずれかを使用します。

  • 最新の RHEL 7 修正でクラッシュカーネルを起動します。
  • etc/sysconfig/kdumpKDUMP_KERNELVER が最新のカーネルバージョンを使用するように設定します。

これにより、上記のシナリオで kdump が正常に起動します。

(BZ#1862840)

RHEL インストーラーが iSCSI ストレージを検出しない可能性がある

RHEL インストーラーでは、一部のオフロード iSCSI ホストバスアダプター (HBA) の iSCSI に関連するカーネルコマンドラインオプションが自動的に設定されない場合があります。そのため、RHEL インストーラーで iSCSI ストレージが検出されない可能性があります。

この問題を回避するには、インストーラーのブート時に、カーネルコマンドラインに以下のオプションを追加します。

rd.iscsi.ibft=1 rd.iscsi.firmware=1

これらのオプションにより、OS 設定前のファームウェア構成で、ネットワーク設定および iSCSI ターゲット検出が有効になります。

このファームウェアで、iSCSI ストレージが設定されるので、インストーラーは iSCSI ストレージを検出し、使用できます。

(BZ#1871027)

mlx5e_rep_neigh_update 作業キューの競合状態が原因でカーネルパニックをトリガーすることがあります。

Single Root I/O Virtualization (SR-IOV) 機能の switchdev in-kernel ドライバーモデルを使用して mlx5 デバイス上でカプセル化アクションをオフロードすると、mlx5e_rep_neigh_update の作業キューで競合状態が発生する可能性があります。したがって、カーネルパニックによりシステムが予期せずに終了し、以下のメッセージが表示されます。

Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]

Currently, a workaround or partial mitigation to this problem is not known.

(BZ#1874101)

kdump では Hyper-V 仮想マシンの nr_cpus 値を 2 以上に設定できない

Microsoft Hyper-V ハイパーバイザーで RHEL 7.9 をゲストオペレーティングシステムとして使用すると、nr_cpus パラメーターが 2 以上に設定されている場合に kdump カーネルが応答しなくなることがあります。この問題を回避するには、ゲストの /etc/sysconfig/kdump ファイルに指定されているデフォルトの nr_cpus=1 パラメーターを変更しないでください。

(BZ#1773478)

8.5. ネットワーク

Red Hat Enterprise Linux 7 で、MD5 ハッシュアルゴリズムを使用した署名の検証が無効になる

MD5 で署名された証明書を必要とする WPA (Wi-Fi Protected Access) の AP (Enterprise Access Point) に接続することはできません。この問題を回避するには、wpa_supplicant.service ファイルを /usr/lib/systemd/system/ ディレクトリーから /etc/systemd/system/ ディレクトリーにコピーして、そのファイルの Service のセクションに以下の行を追加します。

Environment=OPENSSL_ENABLE_MD5_VERIFY=1

次に、root で systemctl daemon-reload コマンドを実行し、サービスファイルを再ロードします。

重要

MD5 証明書は安全性が非常に低いため、Red Hat は使用を推奨していません。

(BZ#1062656)

bind-utils DNS ルックアップユーティリティーがサポートする検索ドメインは glibc よりも少ない

bind-utils パッケージの dighost および nslookup DNS ルックアップユーティリティーがサポートする検索ドメインは最大 8 個であるのに対して、システムの glibc リゾルバーがサポートする検索ドメイン数に制限はありません。これにより、/etc/resolv.conf ファイルの検索にドメインが 8 個以上含まれる場合には、アプリケーションとは異なる結果が返される可能性があります。

この問題を回避するには、以下のいずれかを使用します。

  • フルネームをドットで終了させる
  • resolv.conf の検索句に含めるドメイン数を 8 個以下にする

3 つを超えるドメインを使用することは推奨されません。

(BZ#1758317)

BIND 9.11 ではクエリーロギングが有効な場合にクエリーエラーのログ重大度が変更される

BIND 9.11 の更新により、クエリーロギングが有効な場合に query-errors のログの重大度が debug 1 から info に変わります。その結果、エラーを説明する追加のログエントリーがクエリーログに表示されるようになりました。この問題を回避するには、/etc/named.conf ファイルの logging セクションに以下のステートメントを追加します。

category query-errors { default_debug; };

これにより、クエリーエラーがデバッグログに戻ります。

または、以下のステートメントを使用して、クエリーエラーメッセージをすべて破棄します。

category querry-errors { null; };

その結果、以前の BIND 9.9.4 リリースと同様の形式で、名前クエリーのみがロギングされます。

(BZ#1853191)

正引きゾーンcheck-names オプションが許可されていない場合に named-chroot サービスが起動に失敗する

以前のリリースでは、正引きゾーン 定義で check-names オプションの使用が許可されていました。

bind 9.11 にリベース。以下の zone タイプのみ:

  • master
  • slave
  • stub
  • hint

check-names ステートメントを使用します。

そのため、以前は 正引きゾーン 定義で許可されていた check-names オプションが受け入れられなくなり、named-chroot サービスの開始時に失敗します。この問題を回避するには、masterslavestub または hint を除き、すべての ゾーン タイプから check-names オプションを削除します。

これにより、named-chroot サービスがエラーなしで起動できるようになります。無視されたステートメントでは、提供されるサービスは変更されないことに注意してください。

(BZ#1851836)

NFQUEUE ターゲットによって queue-cpu-fanout フラグがオーバーライドされる

--queue-bypass および --queue-cpu-fanout オプションを使用した iptables の NFQUEUE ターゲットによって、--queue-cpu-fanout オプションが誤ってオーバーライドされます (--queue-bypass オプションの後に配置された場合)。つまり、--queue-cpu-fanout オプションが無視されます。

この問題を回避するには、--queue-cpu-fanout オプションの前に --queue-bypass オプションを配置し直します。

(BZ#1851944)

8.6. セキュリティー

Audit の実行可能な監視機能がシンボリックリンクで機能しない

-w オプションによって提供されるファイルモニタリングでは、パスを直接追跡できません。デバイスと inode へのパスを解決して、実行したプログラムとの比較を行う必要があります。実行可能なシンボリックリンクを監視する監視機能は、メモリーで実行されるプログラムではなく、デバイスとシンボリックリンク自体の inode を監視します。これは、シンボリックリンクの解決から確認できます。監視機能がシンボリックリンクを解決して作成される実行プログラムを取得する場合でも、ルールは別のシンボリックリンクから呼び出されるマルチコールバイナリーでトリガーされます。これにより、誤検出でログがいっぱいになります。したがって、Audit の実行可能な監視機能は、シンボリックリンクでは機能しません。

この問題を回避するには、プログラム実行可能ファイルの解決されたパスに対して監視機能を設定し、comm= フィールドまたは proctitle= フィールドに記載されている最後のコンポーネントを使用して、生成されるログメッセージをフィルタリングします。

(BZ#1421794)

別の SELinux コンテキストに移行中にファイルを実行する場合は、追加のパーミッションが必要

RHEL 7.8 の CVE-2019-11190 における修正のバックポートにより、別の SELinux コンテキストに移行中にファイルを実行するには、以前のリリースよりも多くのパーミッションが必要となります。

ほとんどの場合、domain_entry_file() インターフェースによって、新たに必要なパーミッションが SELinux ドメインに付与されます。ただし、実行されたファイルがスクリプトの場合は、インタープリターのバイナリーを実行するパーミッションがターゲットドメインにないことがあります。新たに必要なパーミッションがないと、AVC 拒否が生じます。このような場合に SELinux が enforcing モードで実行されていると、カーネルは、SIGSEGV または SIGKILL シグナルでプロセスを強制終了する可能性があります。

selinux-policy パッケージに含まれるドメインのファイルで問題が発生した場合は、このコンポーネントに対してバグを報告してください。このコンポーネントがカスタムポリシーモジュールの一部である場合、Red Hat は以下の標準の SELinux インターフェースを使用して、不足しているパーミッションを付与することを推奨します。

  • corecmd_exec_shell() (シェルスクリプト用)
  • corecmd_exec_all_executables() (Perl や Python など、bin_t のラベルが付いたインタープリターの場合)

詳細は、selinux-policy-doc パッケージが提供する /usr/share/selinux/devel/include/kernel/corecommands.if ファイル、およびカスタマーポータルの記事「An exception that breaks the stability of the RHEL SELinux policy API」を参照してください。

(BZ#1832194)

OpenSCAP で多数のファイルをスキャンすると、システムがメモリーを使い切ってしまう

OpenSCAP スキャナーでは、スキャンが完了するまで、収集したすべての結果がメモリーに保存されます。そのため、たとえば大規模な Server with GUI および Workstation パッケージグループから大量のファイルをスキャンすると、RAM が少ないシステムでメモリーが不足する可能性があります。

この問題を回避するには、RAM が少ないシステムで、より小さいパッケージグループ (例: Server および Minimal Install) を使用します。大規模なパッケージグループを使用する必要がある場合は、システムの仮想環境またはステージング環境に十分なメモリーがあるかどうかをテストしてください。または、スキャンプロファイルを調整して、/ ファイルシステム全体の再帰を行う、以下のルールの選択を解除することができます。

  • rpm_verify_hashes
  • rpm_verify_permissions
  • rpm_verify_ownership
  • file_permissions_unauthorized_world_writable
  • no_files_unowned_by_user
  • dir_perms_world_writable_system_owned
  • file_permissions_unauthorized_suid
  • file_permissions_unauthorized_sgid
  • file_permissions_ungroupowned
  • dir_perms_world_writable_sticky_bits

これにより、OpenSCAP スキャナーによってシステムのメモリー不足が引き起こされることが回避されます。

(BZ#1829782)

RHEL 7 で、SHA-1 を使用した RSA 署名を完全に無効化できない

OpenSSH で ssh-rsa 署名アルゴリズムが新しい SHA2 (rsa-sha2-512rsa-sha2-256) 署名を使用できるように設定する必要があるため、RHEL 7 では SHA1 アルゴリズムを完全に無効にすることはできません。この制限を回避するには、RHEL 8 に更新するか、SHA2 のみを使用する ECDSA/Ed25519 鍵を使用します。

(BZ#1828598)

CIS プロファイルで rpm_verify_permissions が失敗する

rpm_verify_permissions ルールでは、ファイルパーミッションがパッケージのデフォルトパーミッションと比較されます。ただし、scap-security-guide パッケージで提供される Center for Internet Security (CIS) プロファイルでは、一部のファイルパーミッションがデフォルトよりも厳格なものに変更されます。その結果、rpm_verify_permissions を使用した特定ファイルの検証が失敗します。この問題を回避するには、これらのファイルに以下のパーミッションがあることを手作業で確認します。

  • /etc/cron.d (0700)
  • /etc/cron.hourly (0700)
  • /etc/cron.monthly (0700)
  • /etc/crontab (0600)
  • /etc/cron.weekly (0700)
  • /etc/cron.daily (0700)

関連機能の詳細は、SCAP セキュリティーガイドで、CIS RHEL 7 Benchmark v2.2.0 に一致するプロファイルを提供 を参照してください。

(BZ#1838622)

OpenSCAP ファイルの所有権関連のルールはリモートユーザーおよびグループバックエンドでは機能しない

設定チェック向けに OpenSCAP スイートが使用する OVAL 言語の機能に制限があります。一部のシステムユーザー、グループ、および ID がリモートにある場合に、完全なリストを取得できない場合があります。たとえば、システムユーザー、グループおよび ID が LDAP などの外部データベースに保存されている場合が挙げられます。

そのため、ユーザー ID またはグループ ID に関連するルールは、リモートユーザーの ID にアクセスできません。したがって、このような ID はシステム外のものとして判断され、準拠したシステムでスキャンが失敗する可能性があります。scap-security-guide パッケージでは、以下のルールが影響を受けます。

  • xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned
  • xccdf_org.ssgproject.content_rule_no_files_unowned_by_user

この問題の回避策として、リモートユーザーを定義するシステムでユーザーまたはグループ ID を処理するルールが失敗する場合は、障害が発生した部分を手動で確認します。OpenSCAP スキャナーを使用すると、--oval-results オプションと --report オプションを併せて指定できます。このオプションは、問題のあるファイルおよび UID を HTML レポートに表示し、手動のリビジョンプロセスを単純化します。

また、RHEL 8.3 では、scap-security-guide パッケージのルールに local-user のバックエンドのみが評価されていることを示す警告が含まれています。

(BZ#1721439)

rpm_verify_permissions および rpm_verify_ownership が Essential Eight プロファイルで失敗する

rpm_verify_permissions ルールでは、ファイルパーミッションがパッケージのデフォルトパーミッションと比較されます。一方、rpm_verify_ownership ルールでは、ファイル所有者がパッケージのデフォルト所有者と比較されます。ただし、scap-security-guide パッケージで提供される Australian Cyber Security Centre (ACSC) Essential Eight プロファイルでは、一部のファイルパーミッションと所有者がデフォルトよりも厳格なものに変更されます。その結果、rpm_verify_permissions および rpm_verify_ownership を使用した特定ファイルの検証が失敗します。この問題を回避するには、/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache ファイルの所有者が root であり、ファイルに suid ビットと sgid ビットが設定されていることを手動で確認します。

(BZ#1778661)

Service Disabled ルールにはサービスのマスクが必要

Service Disabled タイプの SCAP セキュリティーガイドのルールの説明はあいまいです。この説明には、サービスを無効化およびマスクするオプションがありますが、ユーザーがサービスを無効にするか、マスクするか、またはその両方を行うかどうかは指定しません。実際、サービスを無効にするだけで、ルールは常に失敗します。この問題を回避するには、サービスをマスクして Service Disabled ルールを満たすようにします。その結果、サービスがマスクされると Service Disabled ルールがパスします。

(BZ#1891435)

8.7. サーバーおよびサービス

SAP の compat-unixODBC234 パッケージには、unixODBC ライブラリーを読み込むためのシンボリックリンクが必要である

RHEL 7 では unixODBC パッケージバージョン 2.3.1 が利用できます。さらに、compat-unixODBC234 パッケージバージョン 2.3.4 は、RHEL 7 for SAP Solutions sap-hana リポジトリーから入手できます。詳細は、新規パッケージ: SAP 向けの compat-unixODBC234 を参照してください。

unixODBC バージョン 2.3.1 と 2.3.4 のマイナーな ABI の相違点により、バージョン 2.3.1 で構築されたアプリケーションはバージョン 2.3.4 では機能しない場合があります。この互換性の問題を防ぐために、compat-unixODBC234 パッケージは、このパッケージで利用可能な共有ライブラリーに異なる SONAME を使用します。このライブラリーファイルは、/usr/lib64/libodbc.so.2.0.0 ではなく、/usr/lib64/libodbc.so.1002.0.0 にあります。

これにより、dlopen() 関数を使用してランタイムに unixODBC ライブラリーを読み込む unixODBC バージョン 2.3.4 で構築されたサードパーティーアプリケーションは、以下のエラーメッセージでライブラリーを読み込むことができません。

/usr/lib64/libodbc.so.2.0.0: cannot open shared object file: No such file or directory

この問題を回避するには、以下のシンボリックリンクを作成します。

# ln -s /usr/lib64/libodbc.so.1002.0.0 /usr/lib64/libodbc.so.2.0.0

また、必要に応じて compat-unixODBC234 パッケージからの他のライブラリー向けに同様のシンボリックリンクを作成します。

compat-unixODBC234 パッケージは、ベースの RHEL 7 unixODBC パッケージと競合することに注意してください。そのため、compat-unixODBC234 をインストールする前に unixODBC をアンインストールしてください。

(BZ#1844443)

OpenLDAP ライブラリー間のシンボルの競合により、httpd でクラッシュが発生することがある

OpenLDAP が提供する libldap ライブラリーと libldap_r ライブラリーの両方が、単一のプロセス内にロードされ、使用されると、これらのライブラリー間でシンボルの競合が発生する可能性があります。そのため、httpd 設定によって mod_security または mod_auth_openidc モジュールもロードされると、PHP ldap 拡張機能を使用する Apache httpd 子プロセスが突然終了する可能性があります。

Apache Portable Runtime (APR) ライブラリーに対する今回の更新では、APR_DEEPBIND 環境変数を設定することでこの問題を回避できます。これにより、httpd モジュールのロード時に RTLD_DEEPBIND 動的リンカーオプションを使用できるようになります。APR_DEEPBIND 環境変数を有効にすると、競合するライブラリーをロードする httpd 設定でクラッシュが発生しなくなります。

(BZ#1739287)

8.8. ストレージ

iSCSI ターゲットを削除した後に SCSI デバイスを削除できない

ネットワークまたはターゲット側の設定変更により iSCSI セッションが中断されるなど、トランスポートの問題により SCSI デバイスが BLOCKED の場合、トランスポートエラーの復旧でブロックされている間は、接続デバイスを削除できません。delete sysfs コマンド (/sys/block/sd*/device/delete) を使用して SCSI デバイスを削除しようとすると、永久にブロックされる可能性があります。

この問題を回避するには、セッションモード (セッション ID を指定) またはノードモード (ブロックされたセッションと一致するターゲット名とポータルを指定) のいずれかで、iscsiadm logout コマンドを使用して、トランスポートセッションを終了します。復旧セッションで iSCSI セッションログアウトを実行すると、セッションが終了し、SCSI デバイスが削除されます。

(BZ#1439055)

8.9. 仮想化

IBM POWER の RHEL 7.9 仮想マシンで、ホットプラグされたデバイスが検出されないことがある

RHEL 8.3 以降のハイパーバイザーの IBM POWER システムで起動した RHEL 7.9 仮想マシンでは、仮想マシンが完全に起動される前にホットプラグされた PCI デバイスが検出されません。この問題を回避するには、仮想マシンを再起動します。

(BZ#1854917)

8.10. クラウド環境の RHEL

Azure のリモートマシンへのネットワークがアクセラレートされた NIC を使用する RHEL 7 仮想マシンのコアダンプに失敗する

現在、kdump ユーティリティーを使用した、Microsoft Azure ハイパーバイザー上の RHEL 7 仮想マシンのコアダンプファイルのリモートマシンへの保存は、仮想マシンがネットワークアクセラレーションを有効化して NIC を使用している場合は適切に動作しません。これにより、kdump 操作が失敗します。

この問題が発生しないようにするには、以下の行を /etc/kdump.conf ファイルに追加し、kdump サービスを再起動します。

extra_modules pci_hyperv

(BZ#1846667)

cloud-init を使用して設定された RHEL 8 仮想マシンで、パスワードログインによる SSH がデフォルトで使用できない

セキュリティー上の理由から、cloud-init ユーティリティーの設定の ssh_pwauth オプションがデフォルトで 0 に設定されるようになりました。したがって、cloud-init を使用して設定された RHEL 8 仮想マシンに SSH 経由で接続する場合は、パスワードログインを使用できません。

cloud-init を使用して設定された RHEL 8 仮想マシンへの SSH 接続にパスワードログインを使用する必要がある場合は、仮想マシンをデプロイする前に /etc/cloud/cloud.cfg ファイルで ssh_pwauth: 1 を設定します。

(BZ#1685580)


このページには機械翻訳が使用されている場合があります (詳細はこちら)。