Docker/Podman開発日誌
今日は1日Podmanを弄ってました。
先日、教えていただいたPodmanのCnetOS7のコンテナイメージを起動したのですがコンテナのNICがONならなかった。
警備体制は万全である
Podmanは、デーモンやRoot権限なしでも使用できるのがその特徴になるのですが（DockerでもRootless機能は実装はされています。）今日は、その特徴を活かすべく午後の早い時間は、一般ユーザーでCentOS7のコンテナイメージを起動させて作業をしていました。
しかし、CnetOS7のコンテナイメージをプルして起動をしてコマンドを投入したところエラー返ってきてしまいました。
CnetOS8のコンテナイメージでも状況が同じ・・・
投入コマンド
podman run centos echo "run rootless containers"
#標準エラー
/usr/bin/coreutils: error while loading shared libraries: librt.so.1: cannot change memory protections
ジャーナルログを確認すると
7月 17 11:43:28 glabo5.dev.example.jp systemd[1757]: Started podman-2103.scope.
7月 17 11:43:29 glabo5.dev.example.jp kernel: SELinux: mount invalid. Same superblock, different security settings for (dev mqueue, type mqueue)
7月 17 11:43:32 glabo5.dev.example.jp dbus-daemon[887]: [system] Activating service name='org.fedoraproject.Setroubleshootd' requested by ':1.46' (uid=0 pid=864 comm="/usr/sbin/sedispatch " label="system_u:system_r:auditd_t:s0") (using servicehelper)
7月 17 11:43:32 glabo5.dev.example.jp dbus-daemon[887]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
7月 17 11:43:33 glabo5.dev.example.jp setroubleshoot[2156]: AnalyzeThread.run(): Cancel pending alarm
7月 17 11:43:33 glabo5.dev.example.jp dbus-daemon[887]: [system] Activating service name='org.fedoraproject.SetroubleshootPrivileged' requested by ':1.62' (uid=995 pid=2156 comm="/usr/libexec/platform-python -Es /usr/sbin/setroub" label="system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023") (using servicehelper)
7月 17 11:43:33 glabo5.dev.example.jp dbus-daemon[887]: [system] Successfully activated service 'org.fedoraproject.SetroubleshootPrivileged'
7月 17 11:43:34 glabo5.dev.example.jp setroubleshoot[2156]: SELinux is preventing echo from read access on the file /usr/lib64/librt-2.28.so. For complete SELinux messages run: sealert -l 48863d11-aaee-4b3d-a842-befd47b83fb5
7月 17 11:43:34 glabo5.dev.example.jp setroubleshoot[2156]: SELinux is preventing echo from read access on the file /usr/lib64/librt-2.28.so.
***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.
/usr/lib64/librt-2.28.so default label should be lib_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /usr/lib64/librt-2.28.so
***** Plugin catchall (1.49 confidence) suggests **************************
If you believe that echo should be allowed read access on the librt-2.28.so file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'echo' --raw | audit2allow -M my-echo
# semodule -X 300 -i my-echo.pp
7月 17 11:43:34 glabo5.dev.example.jp setroubleshoot[2156]: AnalyzeThread.run(): Set alarm timeout to 10SELinuxがきっちり仕事をしておりアクセス権エラーになっていました。
なので一旦SELinuxのアクセス制御を無効にして実際に事象の原因がSElinuxなのかを確認しました。
現在の設定を確認
getenforce
# 有効です
Enforcing無効化に設定
sudo setenforce 0
getenforce
# 無効（正確にはアクセス拒否はしないがログには書き込む状態
Permissiveリトライ
podman run centos echo "run rootless containers"
# 成功
run rootless containersSElinuxの制御の問題だと確定したので、先ほどのジャーナルログに提示されていたSElinuxのコンテキスト書き換え提案を実施します。
まずは、許可設定ファイルを生成
sudo -i
ausearch -c 'echo' --raw | audit2allow -M my-echo生成した設定ファイルの確認
cat my-echo.temodule my-echo 1.0;
require {
type data_home_t;
type container_t;
class file read;
}
#============= container_t ==============
allow container_t data_home_t:file read;
設定を実施
semodule -i my-echo.ppSELinuxを有効に戻して一般ユーザーで再度コマンドを実行
exit
sudo setenforce 1
getenforce
# 有効にもどりました
Enforcingコマンドを再実行
podman run centos echo "run rootless containers"
# 実行できることが確認できました。
run rootless containers問題なく実行できることを確認、念のため別のコマンドも実行して確認
podman run centos cat /etc/redhat-release正常に実行できました
CentOS Linux release 8.3.2011コンテナが無事に稼働してコマンドの投入もできたので「yum update」を実行したところ今度は、パッチ配布用のサーバのURLが見つかりませんとエラーになりました；
コンテナにログインしてipコマンドを打ったのですがそもそもipコマンド自体がないと言われてしましました。
Podman：Rootlessネットワーク
Podmanのネットワーク設定について色々調べたところ、どうやら一般ユーザで実行した場合は、Podmanのホスト側にPodman用のブリッジ接続NICができない設計のと言うことがわかりました。
https://qiita.com/akiakishitai/items/f38feeb08f4a68cd7a33
まぁNICの設定になるので管理者権限を必要とするため適正な動きなのかなと思います。
おそらくPodman設計的には、「コンテナ自体の集合はユーザー各自でそれぞれ好きに作ってその中で勝手に連携してOKです。でもお外に公開するときは管理者の許可をとってね」っという事なんじゃないかなと思います。
しかし今回は、リポジトリサーバを作りたいので外に行けないのそもそも役割を果たせないと言うことになります。
単純に中継用のプロキシサーバなりを管理者権限で作ってそこ経由という風なのが前述のPodman設計思想的な構成なんだと思うのですが・・・流石に初回の構築でしかもローカル用のリポジトリサーバでそこまで複雑にする気もまだ理解度もなかったので今回は、Root権限で実装する方針に変更しました。
外出禁止令は解けず
気を取り直してRoot権限で改めてCnetOS7のコンテナイメージをプルして起動・・・しかし状況が変わらず（CentOS8も同様でした
さらに調べたところPodman用の仮想NICのアクセス許可が必要という記事を見かけたのでfirewallでそれらを許可しました。
sudo firewall-cmd --zone=public --change-interface=cni-podman0
sudo firewall-cmd --zone=public --add-source=10.88.0.0/16
sudo firewall-cmd --runtime-to-permanent
sudo firewall-cmd --zone=public --list-allこの設定を行ったらCentOS8の方は、外への通信が確立してパッケージアップデートやインストールができるようになりました。
しかしCnetOS7の方は、やはりダメな状態でした。
Podmanホスト側では、起動しているコンテナ分のNICが作られているのですがコンテナないでNICを見ることができない状態です。
この時点でもう夕方になってしまいこのまま原因調査し続けても得策ではないと考えたのではやりCentOS8での実装は諦めてCnetOS7でDockerを使ってまずは実装する事にしました。
Dockerの方が情報も多いのでまだ慣れていない技術なのでそうした方がいいと思いました。
あすは、Dockerで挑戦です。
参考書籍も届いたので
https://www.amazon.co.jp/gp/product/4295005525/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
また明日、挑戦！
お疲れ様でした。
この記事が気に入ったらサポートをしてみませんか？