在F33 Silverblue rawhide上使用toolbox时,输入新创建的toolbox会报错如下...
/usr/bin/id: cannot find name for group ID 1000
在toolbox里面,发出命令时需要sudoer权限,比如dnf之类的……
sudo dnf install vim-enhanced terminator 会向用户显示以下提示...
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
然后,如果我输入用户密码,结果是密码尝试失败......
[sudo] password for ssnow:
Sorry, try again.
[sudo] password for ssnow:
Sorry, try again.
这个问题最初是在https://discussion.fedoraproject.org/t/toolbox-and-root/22123/29报告的,我最初认为用户系统必须以某种方式被破坏。 直到我安装了新的生皮版本的 Silverblue。
IMO,它可能与我进入工具箱容器时收到的第一条消息有关。 也许没有将用户映射为容器的根。
我在Fedora Workstation 32和Fedora Workstation 33 (在虚拟机上)做了一些测试,我可以确认在 F32 上工作正常,但在 F33 上我遇到了同样的问题。
因此,这是Fedora 33本身的问题,而不仅仅是Silverblue版本。
经过一些测试,我发现了一些差异:
2.0.2
2.1.0-dev
/etc/group
和/etc/shadow
是不同的。在Fedora 33的工具箱容器中,用户没有自己的组,也不在组wheel
。
此外,用户在/etc/shadow
文件中没有条目并且root
用户已锁定密码。
Fedora 32和Fedora 33之间/etc/group
文件(容器内)的差异。 用户的用户名是vagrant
:
--- f32-image-f33/group 2020-08-14 19:19:38.734363987 +0000
+++ f33-image-f33/group 2020-08-14 19:17:39.018504713 +0000
@@ -8,7 +8,7 @@
lp:x:7:
mem:x:8:
kmem:x:9:
-wheel:x:10:vagrant
+wheel:x:10:
cdrom:x:11:
mail:x:12:
man:x:15:
@@ -26,4 +26,3 @@
utempter:x:35:
ssh_keys:x:999:
tcpdump:x:72:
-vagrant:x:1000:
/etc/shadow
的差异:
--- f32-image-f33/shadow 2020-08-14 19:15:25.125242112 +0000
+++ f33-image-f33/shadow 2020-08-14 19:17:11.658920405 +0000
@@ -1,4 +1,4 @@
-root::18488:0:99999:7:::
+root:!locked::0:99999:7:::
bin:*:18473:0:99999:7:::
daemon:*:18473:0:99999:7:::
adm:*:18473:0:99999:7:::
@@ -12,4 +12,3 @@
ftp:*:18473:0:99999:7:::
nobody:*:18473:0:99999:7:::
tcpdump:!!:18481::::::
-vagrant::18488:0:99999:7:::
问题仍然存在于 rawhide (F33SB) 中,但不再弹出进入工具箱的消息 (/usr/bin/id: cannot find name for group ID 1000)。
我确认我也看到了错误(/usr/bin/id:找不到组 ID 1000 的名称)所以我删除了 fedora-toolbox-33 图像并重新创建了工具箱,但现在我不能使用sudo
命令。 我现在卡住了。
我跟进了前几天所做的调查结果,并设法让sudo
工作。
(所有这些都在 VM 中的Fedora Workstation 33中)
[vagrant@ci-node-33 ~]$ toolbox create
Created container: fedora-toolbox-33
Enter with: toolbox enter
toolbox
进入容器并尝试命令sudo
:⬢[vagrant<strong i="18">@toolbox</strong> ~]$ sudo ls
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for vagrant:
它失败! :失望的:
podman
进入容器:[vagrant@ci-node-33 ~]$ podman exec -it fedora-toolbox-33 /bin/bash
shadow
文件中(正如我在之前的评论中所示),我删除并重新创建了用户,尝试使用相同的命令和toolbox
执行的参数(在init-container
命令中):# Delete the user
⬢[root<strong i="32">@toolbox</strong> /]# userdel --force vagrant
# Create the user
⬢[root<strong i="33">@toolbox</strong> /]# useradd --home-dir /home/vagrant/ --no-create-home --shell /bin/bash --uid 1000 --groups wheel vagrant
# Check the user groups (this time are OK)
⬢[root<strong i="34">@toolbox</strong> /]# id vagrant
uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant),10(wheel)
# Delete the user password
⬢[root<strong i="35">@toolbox</strong> /]# passwd --delete vagrant
Removing password for user vagrant.
passwd: Note: deleting a password also unlocks the password.
passwd: Success
# Check that the user is at the file /etc/shadow (this is important for PAM authentication and sudo)
⬢[root<strong i="36">@toolbox</strong> /]# grep vagrant /etc/shadow
vagrant::18493:0:99999:7:::
# Logout from the container
⬢[root<strong i="37">@toolbox</strong> /]# exit
[vagrant@ci-node-33 ~]$
toolbox
进入容器并尝试sudo
命令:[vagrant@ci-node-33 ~]$ toolbox enter
⬢[vagrant<strong i="44">@toolbox</strong> vagrant]$ sudo id
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
uid=0(root) gid=0(root) groups=0(root)
现在它起作用了! :微笑:
在init-container
命令(在此附近的某处)中,用户生成似乎出了点问题。
感谢您报告此事并试图找到罪魁祸首! 似乎 Rawhide 中的 Podman 在创建容器时改变了它处理--userns=keep-id
选项的方式。 它现在创建用户和组。 第一个问题似乎与此功能本身有关,因为尽管具有正确的 GUID,但用户组没有名称(我报告了上游:https://github.com/containers/podman/issues/7389)。
另一部分(必须为 sudo 输入密码)是由@juanje指出的代码路径仅在当前用户不存在于容器中时才触发的事实引起的。 该代码负责创建用户,将其添加到正确的组并删除用户和 root 的密码。 我认为init-container
命令中的代码需要稍微重构一下才能在这种情况下调用。
Rawhide中的Podman似乎改变了方式
它在创建时处理 --userns=keep-id 选项
容器。 它现在创建用户和组。 这
第一个问题似乎与此功能有关
本身因为用户组没有名称
尽管有正确的 GUID(我报告上游:
容器/podman#7389)。
似乎它实际上并没有创建组。 否则你会有一个名字。 它只是创建用户。
我想知道它是否也在创建一个主目录。 我希望不是。
https://github.com/containers/podman/pull/6829是有问题的 Podman 更改。
现在我在 Silverblue 32 上使用 fedora- toolbox:f32 image 发生了这种情况
工具箱版本:0.0.93
播客版本:2.0.5
现在我在 Silverblue 32 上使用 fedora- toolbox:f32 image 发生了这种情况
工具箱版本:0.0.93
播客版本:2.0.5
是的,我现在在任何新的 F32 工具箱实例上都有关于 Silverblue 32 的问题。 使用旧的工具箱实例,它仍然有效,但不适用于新的创作。 因此,无论采取什么措施来“修复”它,都会在 F32 上破坏它。
可以使用工具箱 0.0.93 和 podman 2.0.5 在 Fedora 32 SB 上确认此问题。
这不仅与 Fedora 相关或仅限于 Fedora,带有工具箱 0.0.94 和 podman 2.0.5 的 Arch 也有同样的问题。
现在我在 Silverblue 32 上使用 fedora- toolbox:f32 image 发生了这种情况
工具箱版本:0.0.93
播客版本:2.0.5
那是因为 Podman 2.0.5 进入了 Fedora 32。
是否可以为 podman 或工具箱添加一些测试来捕捉这样的回归? Silverblue 真的鼓励人们使用 Toolbox,为此,Toolbox 需要像 gnome-terminal 本身一样可靠。
是否可以为 podman 或工具箱添加一些测试
捕捉这样的回归? Silverblue 真的很鼓励
一个使用 Toolbox,为此 Toolbox 需要
与 gnome-terminal 本身一样可靠。
事实证明,让 Podman 团队关心向后兼容性或检查某些更改是否会破坏 Toolbox 是一场令人惊讶的艰苦战斗。 @HarryMichal一直在追查故障并推动测试,但进展缓慢。
是否可以为 podman 或工具箱添加一些测试
捕捉这样的回归? Silverblue 真的很鼓励
一个使用 Toolbox,为此 Toolbox 需要
与 gnome-terminal 本身一样可靠。事实证明,让 Podman 团队关心向后兼容性或检查某些更改是否会破坏 Toolbox 是一场令人惊讶的艰苦战斗。 @HarryMichal一直在追查故障并推动测试,但进展缓慢。
我想避免这个问题的一种方法是让 Silverblue 为 podman 提供一个单独的 rpm 存储库,并且只允许通过针对工具箱的回归测试的更新
应该什么时候进行 f32 更新?
它越早达到 3 正业:)
你可以自己跟踪 -> https://bodhi.fedoraproject.org/updates/FEDORA-2020-306addaac0
这个业力系统对我来说是新的,它是如何工作的?
您将需要 FAS id( Fedora 帐户 id)来登录 bodhi 系统并对更新进行投票。 见https://fedoraproject.org/wiki/Bodhi#Karma
在 SilverBlue 上,我可以只提取给定的包并进行测试吗? 似乎需要重新定位以测试包。 无需接触我的基本系统即可测试包(如果可能,包括容器)的任何方法都可以。
在 SilverBlue 上,我可以只提取给定的包并进行测试吗?
似乎需要重新定位以测试包。
任何测试包装的方法(包括容器、
如果可能的话)不需要接触我的基本系统就可以了。
rpm-ostree override replace
和rpm-ostree override reset
是您的朋友。
不幸的是,您无法在容器内测试诸如 Podman 和 Toolbox 之类的东西。
非常感谢@juanje的解决方法
# Create the user
⬢[root<strong i="7">@toolbox</strong> /]# useradd --home-dir /home/vagrant/ --no-create-home --shell /bin/bash --uid 1000 --groups wheel vagrant
我在 Silverblue 主机上为我的用户所做的唯一更改是将主目录设为/var/home/<user>
这应该重新开放吗? 0.0.95 肯定仍在发生。 toolbox create
似乎将用户放入来宾的 /etc/passwd 中,但忘记复制/etc/group
条目。 容器中的echo 'martin:x:1000' | sudo tee -a /etc/group
类的东西修复了它。
在https://github.com/containers/toolbox/issues/549#issuecomment -685740230 中记录了相同的体验——在那里评论,因为这不会(通常)破坏 sudo。
0.0.95 肯定仍在发生。 工具箱创建似乎
将用户放入来宾的 /etc/passwd 好吧,但忘记了
复制 /etc/group 条目。 就像是
回声'马丁:x :1000' | sudo tee -a /etc/group 在容器中修复它。
还在发生什么? 您的意思是您在进入容器时看到此错误:
/usr/bin/id: cannot find name for group ID 1000
那是https://github.com/containers/podman/issues/7389
我避免向 Toolbox 本身添加类似的解决方法,因为它不会正确地将诸如/etc/login.defs
类的因素考虑在内。
还是我误会了?
@debarshiray :感谢 podman 问题指针! 这看起来确实是根本原因。 与此同时,上面的解决方法很容易。
最有用的评论
这应该重新开放吗? 0.0.95 肯定仍在发生。
toolbox create
似乎将用户放入来宾的 /etc/passwd 中,但忘记复制/etc/group
条目。 容器中的echo 'martin:x:1000' | sudo tee -a /etc/group
类的东西修复了它。