第44章 既知の問題

Atomic Host の RHEV OVA イメージが機能しない

現在、Atomic Host の RHEV OVA イメージは RHEV にインポートできません。

詳細は、この Bugzilla を参照してください。

podman、buildah、および scopeo にイメージのフルネームが必要

現在、podman、buildah、および scopeo を使用してイメージを操作する場合、rhel7-aarch64 などのイメージの短縮名は使用できません。その代わりに、registry.access.redhat.com/rhel7-aarch64 のように、レジストリーを含むフルネームを指定します。

$ podman pull registry.access.redhat.com/rhel7-aarch64

etcd 3.2.22-24 イメージに誤ったバージョンのバイナリーが含まれている

2019 年 1 月 31 日木曜日、Red Hat は誤ってラベル付けされたバージョンの etcd を公開しました。この誤ったイメージは、rhel-7-server-extras-rpms チャンネルおよび Red Hat Container Catalog でリリースされました。具体的には、3.2.22-24 というラベルの付いた etcd コンテナーがリリースされ、そのコンテナーイメージ内に etcd 3.3.11 が含まれていました。2019 年 2 月 5 日火曜日までに、Red Hat はこの問題を認識し、etcd コンテナーと RPM チャンネルを正しいイメージに戻しました。etcd コンテナー 3.2.22-18 が正しいコンテナーになりました。

OpenShift 3.0 から 3.9 は、etcd のインストールにデフォルトで RPM を使用します。OpenShift 3.10 から 3.11 は、etcd のインストールにコンテナーイメージを使用します。すべてのお客様がこの問題の影響を受けるわけではありません。1 月 31 日から 2 月 5 日の 6 日間に、RHEL ホストにアタッチされた RHEL7 チャンネルを使用して RPM ベースの etcd を実行し、etcd ホストにインストールされているすべての RPM に対して yum update を実行した場合、誤った RPM がプルされています。または、コンテナーベースの etcd を実行していて、1 月 31 日から 2 月 5 日までの 6 日間にクラスターをアップグレードしたり、etcd ノードをスケールアップしたり、最新の etcd コンテナーイメージを手動でインストールしたりした場合、正しくないコンテナーイメージがプルされています。

この問題の詳細と、システムが影響を受けているかどうかを確認する方法は、この ナレッジベースの記事 を参照してください。

buildah パッケージがデフォルトで含まれていない

buildah パッケージは、RHEL Atomic Host 7.5.3 にはデフォルトで含まれていません。これを追加するには、以下を実行します。

# rpm-ostree install buildah

現在の計画では、個別にインストールする必要がないように、buildah パッケージを RHEL Atomic Host 7.5.4 に含めることを予定しています。

podman のチェックポイントおよび復元機能が機能しない

CRIU で発生したバグにより、podman のチェックポイントおよび復元機能が機能しません。Docker は影響を受けません。

新規インストールで ostree リモート設定が欠落している可能性がある

RHEL Atomic Host 7.5.0 の新規インストールでは、ostree リモート設定が欠落している可能性があります。その結果、rpm-ostreed デーモンが起動すると、リモートの設定が見つからず、rpm-ostree コマンドがハングします。

これまでのところ、この問題は新しいキックスタートインストールで発見されていますが、ISO またはクラウドのインストールでは発見されていません。

問題を解決するには、次の手順に従います。

systemd を実行しているコンテナーが機能しない

Atomic Host 7.5.0 より前では、バグが原因で、container_manage_cgroup SELinux ブール値は、ブール値がオンかオフかに関係なく、コンテナーによる cgroup 設定の変更を許可していました。7.5.0 では、これは修正されています。systemd でコンテナーを実行する必要がある場合は、ブール値を on に設定する必要があります。

# setebool -P container_manage_cgroup on

詳細は、こちらのナレッジベースソリューション を参照してください。

アップグレード後に古い LVM 設定ファイルを利用できない場合がある

Atomic Host のアップグレード中に LVM 操作が発生した場合、アップグレード後に古い LVM 設定ファイルを利用できない場合があります。次のエラーメッセージが表示されます。

Failed to read modified config file 'lvm/...'

これを回避するには、アップグレード中に LVM 操作が発生しないようにします。

発生する可能性のある一般的な LVM 操作は、シンプールの自動拡張です。シンプールの自動拡張を防ぐには、次の方法でアップグレードします。

root パーティションの領域が少なすぎるため、アップグレードできない場合がある

デフォルトの Atomic Host の root パーティションが小さすぎるため、アップグレードできない場合があります。アップグレードするには、ルート論理ボリュームの拡張が必要になる場合があります。次のセクションを参照してください。

または、以前のデプロイメントをプルーニングして、root パーティションの領域を解放することもできます。

root パーティションの背景情報は、Red Hat Enterprise Linux Atomic Host でのストレージの管理 を参照してください。

atomic uninstall ですべての sssd コンテナーがアンインストールされる

sssd コンテナーで次のコマンドを実行します。

$ atomic uninstall --name=container-name

すると、container-name sssd コンテナーだけでなく、すべての sssd コンテナーが誤ってアンインストールされます。

これを回避するには、他の sssd コンテナーを使用している場合は、sssd コンテナーをアンインストールしないでください。

IBM POWER8 シリーズでメモリー cgroups をスワップなしで使用できない

IBM Power Systems のリトルエンディアンバリアントの "runc exec" コマンドは、AMD64 および Intel 64 よりもはるかに多くのメモリーを使用します。したがって、メモリー不足を防ぐために、cgroup のメモリー制限を 100 メガバイト未満に設定しないでください。

デフォルトでユーザー名前空間が許可されていない

デフォルトでは、新しい 7.4 カーネルはユーザー名前空間の数を 0 に制限しています。

これを回避するには、ユーザー名前空間の上限を増やします。

# echo 15000 > /proc/sys/user/max_user_namespaces

docker を使用した場合、Cockpit は dockerd を起動できるが、docker-latest を使用した場合は起動できない

RHEL Atomic Host 7.3.5 以降、docker の代わりに docker-latest を使用して実行すると、Cockpit のサービス関連の機能が期待どおりに機能しない場合があります。特に、docker-latest を使用して実行した場合、Cockpit は docker デーモンの起動に失敗します。

TCP ポートを介した Docker デーモンの公開は安全ではない

Docker デーモンは認証を行わないため、Docker デーモンを TCP ポートにバインドすると、その TCP ポートにアクセスできるすべてのプロセスに root アクセスが付与されます。Red Hat は、Docker を TCP ポートにバインドしないことを推奨しています。詳細は、アクセスポートのオプション を参照してください。

先に atomic install を使用しなかった場合、atomic scan でインターネットへの接続が試行される

atomic install コマンドを使用して openscap コンテナーイメージをインストールすると、/etc/oscapd/oscapd.ini 設定ファイルがホストマシンに配置され、コンテナーに公開されます。oscapd.ini ファイルには、Open Vulnerability and Assessment Language (OVAL) コンテンツの取得元の場所に関する情報が含まれています。デフォルト設定では、コンテナー内の CVE データを使用するため、明示的に設定しない限りインターネットに接続しません。atomic install を使用せず、atomic scan で直接スキャンを開始すると、Atomic はコンテナーを取得し、INSTALL ラベルを無視してすぐに実行します。そのため、/etc/oscapd/oscapd.ini はホストシステムに配置されず、コンテナーに公開されません。また、コンテナー内の openscap-daemon 自体のデフォルトの動作が使用されます。デフォルトの動作では、Red Hat の URL から CVE データをダウンロードし、インターネットに接続します。そのため、opscapd.ini ファイルの設定が使用されるように、コンテナーをスキャンする前に atomic install を使用することを推奨します。これを使用しなかった場合も、スキャンは機能しますが、両方の場合での openscap-daemon の動作の違いに注意してください。

Red Hat Enterprise Linux Atomic Host は FIPS モードをサポートしていない

RHEL Atomic Host で FIPS モードを有効にすることはできません。

Atomic Host の 7.2.7 より古いリリースバージョンから 7.3 へのアップグレードがエラーで失敗する

RHEL Atomic Host 7.2.6-1 以前から 7.3 にアップグレードしようとすると、次のエラーで失敗します。

"error: fsetxattr: Invalid argument"

次の 3 つの回避策があります。

1) SELinux を無効にして、通常どおりアップグレードします。

# setenforce 0
# atomic host upgrade

2) rpm-ostreed を停止し、SELinux コンテキストを変更します。

#	systemctl stop rpm-ostreed
#	cp /usr/libexec/rpm-ostreed /usr/local/bin/rpm-ostreed
#	chcon -t install_exec_t /usr/local/bin/rpm-ostreed
#	/usr/local/bin/rpm-ostreed
#	atomic host upgrade

3) 最初に Atomic Host 7.2.7 をデプロイしてからアップグレードします。

#	 atomic host deploy 7.2.7
#	 systemctl reboot
#	 atomic host upgrade

Atomic Host が /usr をマウントポイントとしてサポートしていない

Atomic Host は /usr をマウントポイントとしてサポートしていません。結果として、そのようなパーティションレイアウトが設定されている場合、Anaconda がクラッシュする可能性があります。この問題を回避するには、/usr をマウントポイントにしないでください。

データ損失を回避するために、etcdctl backup が以前の etcd メンバーのバックアップを再利用する

以前は、データベースのサイズが 700 MB を超えるとメンバーを etcd クラスターに追加できず、データが失われていました。この問題を回避するために、etcdctl backup コマンドが拡張され、以前の etcd メンバーのバックアップを再利用するオプションが追加されました。

パッケージのアップグレード後に rhel-push-plugin サービスが再起動しない

Docker サービスは、それ自体より先に rhel-push-plugin を起動する必要があります。しかし、docker および docker-rhel-push-plugin パッケージをアップグレードした後、Docker デーモンは、rhel-push-plugin サービスを再起動せずに、メモリー内の既存の rhel-push-plugin サービスを使用しながら再起動します。この問題を回避するには、最初に rhel-push-plugin を手動で再起動し、その後 docker サービスを再起動します。

etcd の現在のバージョンが etcd クラスターのバージョンよりも古い場合、etcd が起動しない

etcd は、etcd のバージョンが etcd クラスターのバージョンよりも古いかどうかを確認します。古い場合、etcd は起動せず、etcd に依存するアプリケーションで障害が発生する可能性があります。この問題により、RHEL Atomic Host がバージョン 7.2.6 から以前のバージョンに正常にロールバックできなくなりました。

Kubernetes クラスターで、ノードがマスターより新しい場合、ノードが起動しない場合がある

Kubernetes クラスターでは、マスターにノードよりも古いバージョンの Kubernetes が含まれていると、ノードが起動しない場合があります。この問題を回避するには、必ず最初にマスターノードをアップグレードしてください。その結果、クラスターは期待どおりに機能し続けます。

Docker 1.10 で、コンテナー内で一部の syscall が失敗する原因となる secomp フィルターが導入された

回避策として、コンテナーの作成時に --security-opt seccomp:unconfined オプションを Docker に渡します。Docker は、ブロックされた呼び出しとその背後にある理由の包括的なリストを含むヘルプページを管理しています。https://docs.docker.com/engine/security/seccomp/ を参照してください。このリストは、Red Hat Enterprise Linux でブロックされているものと完全に同一ではないことに注意してください。

Docker を 1.9 から 1.10 にアップグレードすると、イメージのメタデータが失われる

特定の状況下で、Docker 1.9 から Docker 1.10 にアップグレードすると、Docker イメージタグのメタデータが失われる可能性があります。基礎となるイメージレイヤーはそのまま残り、docker images -a を実行すると表示されます。メタデータがリモートレジストリーに存在する場合は、docker pull を再実行するだけでメタデータを復元できます。このコマンドは、既存のレイヤーデータの転送を回避しながら、メタデータを復元します。

Atomic Host のインストールでは BTRFS が提供されるが、サポートされていない

RHEL Atomic Host インストーラーは BTRFS をパーティションオプションとして提供しますが、ツリーには btrfs-progs が含まれていません。したがって、インストーラーでこのオプションを選択すると、別のオプションを選択するまでインストールを続行できません。

root パーティションの空き領域が不足した場合

RHEL Atomic Host は、ルートパーティションに 3 GB のストレージを割り当てます。これには、Docker ボリューム (実行中のコンテナーがホストシステムから要求できるストレージの単位) が含まれます。これにより、root パーティションのストレージ領域が不足しやすくなります。十分な領域がない場合、atomic host upgrade によるアップグレードは失敗します。より多くのボリューム領域をサポートするには、システムに物理ストレージを追加するか、root 論理ボリュームを拡張する必要があります。デフォルトでは、他のボリュームの 40% がコンテナーイメージの保存用に予約されます。残りの 60% は、root パーティションの拡張に使用できます。詳細な手順は、https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/getting-started-with-containers/#changing_the_size_of_the_root_partition_after_installation を参照してください。

RHEL Atomic Host でレスキューモードが機能しない

Anaconda インストーラーは、レスキューモードの場合、以前にインストールされた Atomic Host システムを見つけることができません。したがって、レスキューモードは機能しないため、使用しないでください。

brandbot.path サービスにより、7.1 インストールで subscription-manager が /etc/os-release ファイルを変更する場合がある

/etc/os-release ファイルは、atomic host upgrade コマンドを使用して Atomic Host を 7.2 にアップグレードした後でも、まだ 7.1 バージョンを指定している場合があります。これは、基礎となる ostree ツールが、変更されたファイルを /etc に保存するために発生します。回避策として、7.2 にアップグレードした後、次のコマンドを実行します。

cp /usr/etc/os-release /etc

これにより、/etc/os-release ファイルは変更されていない状態に戻ります。brandbot.path は 7.2.0 ではマスクされているため、subscription-manager によって今後変更されることはなく、将来のアップグレードで正しいバージョンが表示されます。

kube-apiserver をポート 443 でセキュアモードで実行すると、一部の機能が失われる

回避策として、以下を実行して kube-apiserver バイナリーを変更する必要があります。

# chown root:root /usr/bin/kube-apiserver
# chmod 700 /usr/bin/kube-apiserver
# setcap CAP_NET_BIND_SERVICE=ep /usr/bin/kube-apiserver