Building / Installing podman as non-root

[aschofie]

From what I've read it seems to be the answer to everything that ails docker. Images in user directory, containers with only user permissions, no daemon, etc. Yet every guide to installing seems to rely on the system's package manager, and the build seems to rely on packages being installed (runc, common), that would also require permissions to the system's package manager.

So how can I get podman to run on a system where I only have normal user access?

[giuseppe]

that is more difficult to get as you'd need to install all dependencies in your home directory and prepare all the configuration files to use/point the right executables. We have nothing at the moment for bootstrapping podman and its dependencies from scratch for an unprivileged user.

The easiest would be to install it on the system, but still use the unprivileged users for running the containers.

[baude]

@rhatdan ptal, im in agreement with @giuseppe here in that our goal as upstream here is to provide an unprivileged way to run the installed podman -- not to install podman outside the scope of the system. wdyt?

[rhatdan]

I have no problem is someone wants to go through the procedure to get it documented, I don't see us needing to support this though.
As a thought experiment how far could a user get with building podman, slirp4netns and fuse-overlayfs in their homedir?

[mheon]

I think you can actually get it all built, but it's going to be a massive pain to get every build dependency installed.

[rhatdan]

I agree.

[giuseppe]

Depending on the host, it can be quite painful for fuse-overlayfs, this is what I need to do for xenial: https://github.com/containers/fuse-overlayfs/blob/master/.travis.yml#L30-L34

It is possible to have a static build for fuse-overlayfs but that requires to use a Dockerfile.

I am afraid this documentation will easily get obsoleted. I think it could go only in a blog post, if someone is interested.

[baude]

closing this is this is not an upstream problem