toolbox status and expected usage #458
Comments
|
@dghubble my understanding of #38 is that it has been basically acknowledged that original One side effect of this is that it does not have to follow the same command-line arguments as the CL one, and any further bugs or UX friction you see would be better reported directly upstream (unless it's some integration woe). |
|
Ok, I created an issue over there. I'm not too worried over what the syntax is, just that it be able to do something for me (and for linking to as a way to use hack/special case tools that don't belong on-host). |
|
Ok to close if you like! I'll wait on their reply and close too. |
|
@dghubble that makes sense. I think that the real missing thing on our side is a docpage showing 1) that there is a |
|
Unfortunately https://github.com/containers/toolbox doesn't run on FCOS. This fails because the The FCOS Then if you go past this error (by using your own image), the tool is almost unusable to troubleshoot network issues as it runs in a rootless setup in which for instance it is impossible to run |
|
I think I ended up just using podman directly. Maybe there is a case for recommending podman and funneling feature requests there? The original CL toolbox (systemd-nspawn as I recall) handled weird edge case needs, but that was before container engines had features they do today. I can't actually put my finger on what features I'd want toolbox to have anymore (edit: it may have cool abilities I'm unaware of) |
|
We've finally resorted to use an adapted version of https://github.com/coreos/toolbox/blob/master/rhcos-toolbox. No more rootless podman FTW :) |
|
In the gentlest way, if toolbox hasn't been usable, maybe the package isn't required? I originally only turned to toolbox out of debugging habbit from using the original CoreOS toolbox. But podman by itself has been quite capable of handing my needs in debugging scenarios. Run containers with nearly any constraint dropped in a pinch for tcpdump, ipvsadm, etc. The way forward is providing a podman example or two to drop different namespace isolation? |
I honestly do share this feeling. At the same time there has been some heated debate in the past, and I don't feel comfortable personally spearheading this. I could help improving our docs side though. As an additional datapoint, |
Don't call get_group_for_sudo() on the host during create(). That runs on the host, and thus will check which sudo group exists on the host. But that is entirely irrelevant for sudo inside the container, and it breaks when trying to create a Debian or Ubuntu based toolbox on a Fedora host (or vice versa). This also causes problem on CoreOS[0][1] Also, there is no point in running the `podman create` command with an extra sudo group, normal user privileges are just fine. init_container() will call get_group_for_sudo() inside the container and initialize the groups correctly there. containers#401 [0] containers#423 [1] coreos/fedora-coreos-tracker#458
I recently wanted to use
toolboxand I'm unsure of the status. I remember some discussions about different flavors and now I see its marked done.I must be doing something very wrong or maybe this isn't supposed to work yet. Admittedly, I'm approaching this having only ever used CoreOS Container Linux toolbox (never the RPM) and infrequently.
Versions
The text was updated successfully, but these errors were encountered: