navaati
April 27, 2019, 1:52pm
1
Hi.
I’m starting to try fedora-toolbox before migrating to Silverblue and apparently I can’t run podman commands (so probably no buildah commands either) from inside the toolbox.
$ podman start haproxy-test
I realize I could just go out of the toolbox, start my container, and go back. Still… Do you think there could be a way to make it smoother ?
refi64
April 27, 2019, 3:55pm
2
Hmm I don’t think this would be possible. At least off the top of my head rootless podman uses fuse-overlayfs, but FUSE doesn’t work inside namespaces. Not quite sure how it would go if switching to the VFS backend, but glancing at the error it still might not work…
navaati
April 27, 2019, 4:00pm
3
Mmh, I was thinking about a less “recursive” solution, such as escaping to the host for launching containers.
Now that I’m thinking about it podman doesn’t work but Docker, with its daemon approach, would probably work… But don’t tell Dan Walsh
refi64
April 28, 2019, 4:51am
4
Ah for this you can use the varlink api , as long as you pass the varlink socket into the container (whether the api was started via systemd or podman varlink) it should work.
This Github issue talks about running Podman from toolbox:
opened 12:35PM - 25 Apr 19 UTC
closed 06:02PM - 05 Aug 19 UTC
kind/feature
<!--
---------------------------------------------------
BUG REPORT INFORMATIO… N
---------------------------------------------------
Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST
**NOTE** A large number of issues reported against Podman are often found to already be fixed
in more current versions of the project. Before reporting an issue, please verify the
version you are running with `podman version` and compare it to the latest release
documented on the top of Podman's [README.md](../README.md). If they differ, please
update your version of Podman to the latest possible and retry your command before creating
an issue.
If you are filing a bug against `podman build`, please instead file a bug
against Buildah (https://github.com/containers/buildah/issues). Podman build
executes Buildah to perform container builds, and as such the Buildah
maintainers are best equipped to handle these bugs.
-->
**Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)**
/kind feature
**Use case:**
On a very slim system like Fedora Silverblue, i'd like to use a rootless podman container as my development environment shell (to have additional tools which are not available on Silverblue host, and bind mount my $HOME or a subdirectory of it). This shell container should be able to manage my rootless podman, so that i can work on projects that require running containers.
**Describe the results you received:**
The first part -- mapping the host and container user transparently (e.g. UID 1000 on host being UID 1000 in container) -- is already achievable via using custom `--uidmap` / `--gidmap` parameters. The approach is nicely described in a [commit message in Toolbox project](https://github.com/debarshiray/toolbox/commit/cfcf4eb31e14b3a300804840d315c62bc32e15ae).
With the uidmap/gidmap i can be user 1000 both in the container and on the host, so mounting $HOME into the container works transparently. With bind mounting `$XDG_RUNTIME_DIR` i can query running podman containers using `podman ps` and i see them, including the container i'm running the command from. However, once i try to run `podman images`, i get a permission error:
`Error: Could not get runtime: mkdir /home/jistr/.local/share/containers/storage/overlay/l: permission denied`
**Describe the results you expected:**
I'd like to be able to run `podman images` from the container and get a list of images in my rootless podman on the host, while keeping the requirement that i act as the same UID inside and outside the container, and i'm not using podman as root.
I guess we'd have to persuade the rootless podman in the container to not try to enter another user namespace, because we are already inside the namespace meant for rootless containers of the given user?
If what i'm asking for is impossible or very impractical, is there an alternative usage pattern for achieving what's described in "use case" section above?
**Additional information you deem important (e.g. issue happens only occasionally):**
I've been experimenting with running the container like this for now:
```
UID_MAX=65536
UID_HIGHER_START=$((UID+1))
UID_HIGHER_COUNT=$((UID_MAX-UID))
podman run \
-e XDG_RUNTIME_DIR \
-v $XDG_RUNTIME_DIR:$XDG_RUNTIME_DIR \
\
-v /etc/passwd:/etc/passwd:ro \
-v /etc/group:/etc/group:ro \
-v /etc/nsswitch.conf:/etc/nsswitch.conf:ro \
-v /etc/security/limits.d:/etc/security/limits.d:ro \
-v /usr/lib/passwd:/usr/lib/passwd \
-v /usr/lib/group:/usr/lib/group \
--uidmap $UID:0:1 \
--uidmap 0:1:$UID \
--uidmap $UID_HIGHER_START:$UID_HIGHER_START:$UID_HIGHER_COUNT \
--gidmap $UID:0:1 \
--gidmap 0:1:$UID \
--gidmap $UID_HIGHER_START:$UID_HIGHER_START:$UID_HIGHER_COUNT \
--user $UID:$UID \
\
-v $HOME:$HOME \
-v /var/home:/var/home \
--privileged \
--rm \
--net host \
--pid host \
--security-opt label=disable \
--volume /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket \
--volume /dev/bus:/dev/bus \
--volume /dev/dri:/dev/dri \
--volume /dev/fuse:/dev/fuse \
-ti \
localhost/testimage \
bash
```
**Output of `podman version`:**
Same on host and in the container:
```
Version: 1.2.0
RemoteAPI Version: 1
Go Version: go1.11.5
OS/Arch: linux/amd64
```
**Output of `podman info --debug`:**
The output below is from the host. In the container the command crashes with the same error as when running `podman images`.
```
debug:
compiler: gc
git commit: ""
go version: go1.11.5
podman version: 1.2.0
host:
BuildahVersion: 1.7.2
Conmon:
package: podman-1.2.0-2.git3bd528e.fc29.x86_64
path: /usr/libexec/podman/conmon
version: 'conmon version 1.12.0-dev, commit: d88bb0e63cb70f9787a8e410716924f380af361f'
Distribution:
distribution: fedora
version: "29"
MemFree: 14722519040
MemTotal: 25196142592
OCIRuntime:
package: runc-1.0.0-85.dev.gitdd22a84.fc29.x86_64
path: /usr/bin/runc
version: |-
runc version 1.0.0-rc6+dev
commit: 1d3f73d4086533a858613bc4b6af2b5e882f4730
spec: 1.0.1-dev
SwapFree: 8589930496
SwapTotal: 8589930496
arch: amd64
cpus: 4
hostname: split
kernel: 5.0.7-200.fc29.x86_64
os: linux
rootless: true
uptime: 19h 51m 39.87s (Approximately 0.79 days)
insecure registries:
registries: []
registries:
registries:
- docker.io
- registry.fedoraproject.org
- quay.io
- registry.access.redhat.com
- registry.centos.org
store:
ConfigFile: /home/jistr/.config/containers/storage.conf
ContainerStore:
number: 3
GraphDriverName: overlay
GraphOptions:
- overlay.mount_program=/usr/bin/fuse-overlayfs
GraphRoot: /home/jistr/.local/share/containers/storage
GraphStatus:
Backing Filesystem: extfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
ImageStore:
number: 7
RunRoot: /run/user/1000
VolumePath: /home/jistr/.local/share/containers/storage/volumes
```
**Additional environment details (AWS, VirtualBox, physical, etc.):**
Fedora Silverblue workstation, physical
Quote from the issue: “You’d need toolbox Git master for this to work best. ”
Disclaimer: I have not tried toolbox myself.
!