Podman: A tool for managing OCI containers and pods

Last update: Jan 1, 2023

Comments: 17

Podman: A tool for managing OCI containers and pods

Podman (the POD MANager) is a tool for managing containers and images, volumes mounted into those containers, and pods made from groups of containers. Podman is based on libpod, a library for container lifecycle management that is also contained in this repository. The libpod library provides APIs for managing containers, pods, container images, and volumes.

Latest Version: 3.0.0
- Latest Remote client for Windows
- Latest Remote client for MacOs
- Latest Static Remote client for Linux
Continuous Integration:
GoDoc:

Overview and scope

At a high level, the scope of Podman and libpod is the following:

Support for multiple container image formats, including OCI and Docker images.
Full management of those images, including pulling from various sources (including trust and verification), creating (built via Containerfile or Dockerfile or committed from a container), and pushing to registries and other storage backends.
Full management of container lifecycle, including creation (both from an image and from an exploded root filesystem), running, checkpointing and restoring (via CRIU), and removal.
Support for pods, groups of containers that share resources and are managed together.
Support for running containers and pods without root or other elevated privileges.
Resource isolation of containers and pods.
Support for a Docker-compatible CLI interface.
No manager daemon, for improved security and lower resource utilization at idle.
Support for a REST API providing both a Docker-compatible interface and an improved interface exposing advanced Podman functionality.
In the future, integration with CRI-O to share containers and backend code.

Podman presently only supports running containers on Linux. However, we are building a remote client which can run on Windows and OS X and manage Podman containers on a Linux system via the REST API using SSH tunneling.

Roadmap

Further improvements to the REST API, with a focus on bugfixes and implementing missing functionality
Integrate libpod into CRI-O to replace its existing container management backend
Improvements on rootless containers, with a focus on improving the user experience and exposing presently-unavailable features when possible

Communications

If you think you've identified a security issue in the project, please DO NOT report the issue publicly via the GitHub issue tracker, mailing list, or IRC. Instead, send an email with as many details as possible to [email protected]. This is a private mailing list for the core maintainers.

For general questions and discussion, please use the IRC #podman channel on irc.freenode.net.

For discussions around issues/bugs and features, you can use the GitHub issues and PRs tracking system.

There is also a mailing list at lists.podman.io. You can subscribe by sending a message to [email protected] with the subject subscribe.

Rootless

Podman can be easily run as a normal user, without requiring a setuid binary. When run without root, Podman containers use user namespaces to set root in the container to the user running Podman. Rootless Podman runs locked-down containers with no privileges that the user running the container does not have. Some of these restrictions can be lifted (via --privileged, for example), but rootless containers will never have more privileges than the user that launched them. If you run Podman as your user and mount in /etc/passwd from the host, you still won't be able to change it, since your user doesn't have permission to do so.

Almost all normal Podman functionality is available, though there are some shortcomings. Any recent Podman release should be able to run rootless without any additional configuration, though your operating system may require some additional configuration detailed in the install guide.

A little configuration by an administrator is required before rootless Podman can be used, the necessary setup is documented here.

Out of scope

Specialized signing and pushing of images to various storage backends. See Skopeo for those tasks.
Support for the Kubernetes CRI interface for container management. The CRI-O daemon specializes in that.

OCI Projects Plans

The plan is to use OCI projects and best of breed libraries for different aspects:

Runtime: We use the OCI runtime tools to generate OCI runtime configurations that can be used with any OCI-compliant runtime, like crun and runc.
Images: Image management uses the containers/image library.
Storage: Container and image storage is managed by containers/storage.
Networking: Networking support through use of CNI.
Builds: Builds are supported via Buildah.
Conmon: Conmon is a tool for monitoring OCI runtimes, used by both Podman and CRI-O.
Seccomp: A unified Seccomp policy for Podman, Buildah, and CRI-O.

Podman Information for Developers

For blogs, release announcements and more, please checkout the podman.io website!

Installation notes Information on how to install Podman in your environment.

OCI Hooks Support Information on how Podman configures OCI Hooks to run when launching a container.

Podman API Documentation on the Podman REST API.

Podman Commands A list of the Podman commands with links to their man pages and in many cases videos showing the commands in use.

Podman Troubleshooting Guide A list of common issues and solutions for Podman.

Podman Usage Transfer Useful information for ops and dev transfer as it relates to infrastructure that utilizes Podman. This page includes tables showing Docker commands and their Podman equivalent commands.

Tutorials Tutorials on using Podman.

Remote Client A brief how-to on using the Podman remote-client.

Basic Setup and Use of Podman in a Rootless environment A tutorial showing the setup and configuration necessary to run Rootless Podman.

Release Notes Release notes for recent Podman versions.

Contributing Information about contributing to this project.

Buildah and Podman relationship

Buildah and Podman are two complementary open-source projects that are available on most Linux platforms and both projects reside at GitHub.com with Buildah here and Podman here. Both, Buildah and Podman are command line tools that work on Open Container Initiative (OCI) images and containers. The two projects differentiate in their specialization.

Buildah specializes in building OCI images. Buildah's commands replicate all of the commands that are found in a Dockerfile. This allows building images with and without Dockerfiles while not requiring any root privileges. Buildah’s ultimate goal is to provide a lower-level coreutils interface to build images. The flexibility of building images without Dockerfiles allows for the integration of other scripting languages into the build process. Buildah follows a simple fork-exec model and does not run as a daemon but it is based on a comprehensive API in golang, which can be vendored into other tools.

Podman specializes in all of the commands and functions that help you to maintain and modify OCI images, such as pulling and tagging. It also allows you to create, run, and maintain those containers created from those images. For building container images via Dockerfiles, Podman uses Buildah's golang API and can be installed independently from Buildah.

A major difference between Podman and Buildah is their concept of a container. Podman allows users to create "traditional containers" where the intent of these containers is to be long lived. While Buildah containers are really just created to allow content to be added back to the container image. An easy way to think of it is the buildah run command emulates the RUN command in a Dockerfile while the podman run command emulates the docker run command in functionality. Because of this and their underlying storage differences, you can not see Podman containers from within Buildah or vice versa.

In short, Buildah is an efficient way to create OCI images while Podman allows you to manage and maintain those images and containers in a production environment using familiar container cli commands. For more details, see the Container Tools Guide.

Podman Former API (Varlink)

Podman formerly offered a Varlink-based API for remote management of containers. However, this API was replaced by the REST API. Varlink support has been removed as of the 3.0 release. For more details, you can see this blog.

Static Binary Builds

The Cirrus CI integration within this repository contains a static_build job which produces a static Podman binary for testing purposes. Please note that this binary is not officially supported with respect to feature-completeness and functionality and should be only used for testing.

Owner

Containers

Open Repository for Container Tools

https://github.com/containers/libpod

Comments

Support native source folder for volume mount in remote model

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Currently, looks like in podman's remote client case, bind volume will use source folders on podman server's host, could we support (or give some configurations to choose) using source folders on podman client's host?

podman client and podman server may run in different hosts, or one runs in the host, the other runs in a VM. Have the ability to mount folders on the client side might be able to open more use cases...

After podman 2 upgrade, systemd fails to start in containers on cgroups v1 hosts

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

I was repeatedly building working containers with podman this morning when my OS (Ubuntu 20.04) notified me that podman 2.0 was available and I elected to install it.

Shortly afterword, I can no longer SSH to a newly build and launched container. I see this as output to podman container list -a:

CONTAINER ID  IMAGE                        COMMAND                                       CREATED         STATUS             PORTS                                             NAMES
0e7692779754  k8s.gcr.io/pause:3.2                                                       21 seconds ago  Up 17 seconds ago  127.0.0.1:2222->22/tcp, 127.0.0.1:3000->3000/tcp  505f2a3b385a-infra
537b8ed4db9c  localhost/devenv-img:latest  -c exec /sbin/init --log-target=journal 3>&1  20 seconds ago  Up 17 seconds ago                                                    devenv

This is frustrating: I don't any references to a container named "pause", yet one is running and listening on the ports my container had published, yet my container isn't listening on any ports at all.

I read the podman 2.0 release notes and don't see any notes about a related breaking change.

I did search the project for references to "infra containers" because I sometimes see that term mentioned in error messages. I find references to "infra containers" in the code, but I can't find references in the documentation.

They seem related to this issue and it would be great if there was more accessible user documentation about "infra containers"

Steps to reproduce the issue:

podman run --systemd=always -it -p "127.0.0.1:2222:22" solita/ubuntu-systemd-ssh

Describe the results you received:

Initializing machine ID from random generator. Failed to create /user.slice/user-1000.slice/session-8.scope/init.scope control group: Permission denied Failed to allocate manager object: Permission denied [!!!!!!] Failed to allocate manager object.

Describe the results you expected:

For this test, the container should boot to the point where this line appears:

  [  OK  ] Reached target Multi-User System.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

podman version 2.0.0

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.15.0
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.18, commit: '
  cpus: 4
  distribution:
    distribution: ubuntu
    version: "20.04"
  eventLogger: file
  hostname: mark-x1
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.4.0-37-generic
  linkmode: dynamic
  memFree: 1065062400
  memTotal: 16527003648
  ociRuntime:
    name: runc
    package: 'containerd.io: /usr/bin/runc'
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc10
      commit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
      spec: 1.0.1-dev
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.0
      commit: unknown
      libslirp: 4.2.0
  swapFree: 19345408
  swapTotal: 1027600384
  uptime: 72h 32m 43.91s (Approximately 3.00 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/mark/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 2
    stopped: 0
  graphDriverName: vfs
  graphOptions: {}
  graphRoot: /home/mark/.local/share/containers/storage
  graphStatus: {}
  imageStore:
    number: 122
  runRoot: /run/user/1000/containers
  volumePath: /home/mark/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 0
  BuiltTime: Wed Dec 31 19:00:00 1969
  GitCommit: ""
  GoVersion: go1.13.8
  OsArch: linux/amd64
  Version: 2.0.0

Package info (e.g. output of rpm -q podman or apt list podman):

podman/unknown,now 2.0.0~1 amd64 [installed]

Additional environment details (AWS, VirtualBox, physical, etc.):

Package up podman for vanilla Debian
This is separate from the PPA work that's already being done. This issue will track efforts towards getting podman in vanilla Debian.

Update: Debian tickets

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=wnpp

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930440 :: libpod / podman

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928083 :: buildah

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880199 :: skopeo
Cirrus: Bump Fedora to release 35

What this PR does / why we need it:

Update the "Fedora" VM used in testing to version 35 (beta), and the "Prior Fedora" version to 34. Stop testing with Fedora 33. Also resolve a TODO in setup - the needed packages are now bundled into the images.

NOTE: The Fedora 35 image is now based on a BTRFS root filesystem.

How to verify it

CI will pass

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

Depends on: #11955 and #11979 and ##12110 and #12121 or #12120 and #12060 and #12162 and #12342 and #12343 and https://github.com/containers/automation_images/pull/93

How to access docker api on a mac

/kind feature

Description

I've been following https://github.com/containers/podman/blob/main/docs/tutorials/mac_experimental.md on my mac, specifically -

podman machine init --cpus 6 --disk-size 200
podman machine start
podman build ...
podman run ...

Actually works pretty well :-) However next I want to use a docker client ( specifically the fabric8 maven plugin to build images, but we can test with docker command ), but I see -

$ docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

I read at https://github.com/containers/podman/blob/main/docs/source/markdown/podman-system-service.1.md that there is an option to provide the API service, but this fails with -

$ podman system service
Error: unrecognized command `podman system service`
Try 'podman system --help' for more information.

Steps to reproduce the issue:

On a mac with podman machine running, run podman system service

Describe the results you received:

Error: unrecognized command podman system service

Describe the results you expected:

Able to connect to the socket from a docker client (outside the machine)

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

$ podman version
Client:
Version:      3.3.0
API Version:  3.3.0
Go Version:   go1.16.6
Built:        Fri Aug 20 18:47:23 2021
OS/Arch:      darwin/amd64

Server:
Version:      3.3.0
API Version:  3.3.0
Go Version:   go1.16.6
Built:        Fri Aug 20 20:36:14 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

$ podman info --debug
host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.29-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: '
  cpus: 6
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: localhost
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.13.12-200.fc34.x86_64
  linkmode: dynamic
  memFree: 2224381952
  memTotal: 25198764032
  ociRuntime:
    name: crun
    package: crun-0.21-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.21
      commit: c4c3cdf2ce408ed44a9e027c618473e6485c635b
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.9-1.fc34.x86_64
    version: |-
      slirp4netns version 1.1.8+dev
      commit: 6dc0186e020232ae1a6fcc1f7afbc3ea02fd3876
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 0
  swapTotal: 0
  uptime: 4h 50m 50.8s (Approximately 0.17 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 18
  runRoot: /run/user/1000/containers
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.0
  Built: 1629488174
  BuiltTime: Fri Aug 20 19:36:14 2021
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.3.0

Additional environment details (AWS, VirtualBox, physical, etc.):

mac client with podman machine running.

I did wonder if the technique I need is to somehow tunnel the socket running inside the podman machine to outside ... but I couldn't find this in the docs.

"Error: invalid configuration, cannot specify resource limits without cgroups v2 and --cgroup-manager=systemd"

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Steps to reproduce the issue:

podman run -it --rm fedora:32

Describe the results you received:

Error: invalid configuration, cannot specify resource limits without cgroups v2 and --cgroup-manager=systemd

Describe the results you expected:

#

Additional information you deem important (e.g. issue happens only occasionally):

Happens all the time

Output of podman version:

Version:            1.9.1
RemoteAPI Version:  1
Go Version:         go1.14.2
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  gitCommit: ""
  goVersion: go1.14.2
  podmanVersion: 1.9.1
host:
  arch: amd64
  buildahVersion: 1.14.8
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.15-1.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.15, commit: 33da5ef83bf2abc7965fc37980a49d02fdb71826'
  cpus: 8
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: file
  hostname: tmp.scylladb.com
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.6.7-300.fc32.x86_64
  memFree: 5275238400
  memTotal: 33541488640
  ociRuntime:
    name: crun
    package: crun-0.13-2.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.13
      commit: e79e4de4ac16da0ce48777afb72c6241de870525
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.0.0-1.fc32.x86_64
    version: |-
      slirp4netns version 1.0.0
      commit: a3be729152a33e692cd28b52f664defbf2e7810a
      libslirp: 4.2.0
  swapFree: 16869486592
  swapTotal: 16869486592
  uptime: 93h 3m 6.55s (Approximately 3.88 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/avi/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.0.0-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.0.0
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/avi/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  volumePath: /home/avi/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

podman-1.9.1-1.fc32.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):

Fully updated Fedora 32.

Running containers inside of a container environment (with docker-compose.yml) using podman?

/kind feature

Description

I'd like to be able to run and test batches of containers defined with docker-compose.yml. As it is now, doing this with actual Docker inside an environment that runs through Docker gets rather risky and leaky in all kinds of bad ways.

For building containers, I'm starting to use buildah for this, but I don't quite yet have an answer for running them. The goal is to be able to build and test in a manner that is consistent with how people can do it on their local machines, and easily transition to OpenShift for production run environments.

Additional environment details (AWS, VirtualBox, physical, etc.): GitLab CI runners with Docker container (of Fedora with buildah + podman)
Version 4.x not updating with apt update Ubuntu 20.04

On Ubuntu 20.04, Podman is stuck at version 3.4.2. Running apt update doesn't update it to the 4.x version. I followed the instructions here: https://podman.io/getting-started/installation.html#linuxmint-20x.
error running container: error from /usr/bin/crun creating container for [/bin/sh -c pip install -r requirements.txt]: mount `/proc` to `/proc`: Operation not permitted
Hi Team,

I have created a running rootless openshift container using a Dockerfile. I followed below link for creating Rootless Podman without the privileged flag. I'm able to build java spring application but when I try to build python application using Dockerfile that has pip install then I'm getting below error. Can you please let us know what else config required to resolve below error?

https://www.redhat.com/sysadmin/podman-inside-kubernetes

error running container: error from /usr/bin/crun creating container for [/bin/sh -c pip install -r requirements.txt]: mount /proc to /proc: Operation not permitted

If there is a "pip install" command in a Dockerfile, then Podman build fails with error " mount /proc to /proc: Operation not permitted"

Podman build creates docker image, if Dockerfile does not have "pip install" command

podman --version :: podman version 3.2.2

podman info ::

host: arch: amd64 buildahVersion: 1.21.0 cgroupControllers: [] cgroupManager: cgroupfs cgroupVersion: v1 conmon: package: conmon-2.0.27-2.fc34.x86_64 path: /usr/bin/conmon version: 'conmon version 2.0.27, commit: ' cpus: 12 distribution: distribution: fedora version: "34" eventLogger: file hostname: cliservice-7dff79cbd7-n7krd idMappings: gidmap: - container_id: 0 host_id: 1000 size: 1 - container_id: 1 host_id: 10000 size: 5000 uidmap: - container_id: 0 host_id: 1000 size: 1 - container_id: 1 host_id: 10000 size: 5000 kernel: 4.18.0-240.22.1.el8_3.x86_64 linkmode: dynamic memFree: 55972347904 memTotal: 67230187520 ociRuntime: name: crun package: crun-0.20.1-1.fc34.x86_64 path: /usr/bin/crun version: |- crun version 0.20.1 commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL os: linux remoteSocket: path: /tmp/podman-run-1000/podman/podman.sock security: apparmorEnabled: false capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT rootless: true seccompEnabled: true seccompProfilePath: /usr/share/containers/seccomp.json selinuxEnabled: false serviceIsRemote: false slirp4netns: executable: /usr/bin/slirp4netns package: slirp4netns-1.1.9-1.fc34.x86_64 version: |- slirp4netns version 1.1.8+dev commit: 6dc0186e020232ae1a6fcc1f7afbc3ea02fd3876 libslirp: 4.4.0 SLIRP_CONFIG_VERSION_MAX: 3 libseccomp: 2.5.0 swapFree: 0 swapTotal: 0 uptime: 21h 24m 42.97s (Approximately 0.88 days) registries: default-route-openshift-image-registry.apps.cfa.devcloud.intel.com: Blocked: false Insecure: true Location: default-route-openshift-image-registry.apps.cfa.devcloud.intel.com MirrorByDigestOnly: false Mirrors: [] Prefix: default-route-openshift-image-registry.apps.cfa.devcloud.intel.com quay.io: Blocked: false Insecure: true Location: quay.io MirrorByDigestOnly: false Mirrors: [] Prefix: quay.io search:

registry.fedoraproject.org

registry.access.redhat.com

registry.centos.org

docker.io

quay.io store: configFile: /home/podman/.config/containers/storage.conf containerStore: number: 0 paused: 0 running: 0 stopped: 0 graphDriverName: overlay graphOptions: overlay.mount_program: Executable: /usr/bin/fuse-overlayfs Package: fuse-overlayfs-1.5.0-1.fc34.x86_64 Version: |- fusermount3 version: 3.10.4 fuse-overlayfs: version 1.5 FUSE library version 3.10.4 using FUSE kernel interface version 7.31 graphRoot: /home/podman/.local/share/containers/storage graphStatus: Backing Filesystem: overlayfs Native Overlay Diff: "false" Supports d_type: "true" Using metacopy: "false" imageStore: number: 5 runRoot: /tmp/podman-run-1000/containers volumePath: /home/podman/.local/share/containers/storage/volumes version: APIVersion: 3.2.2 Built: 1624664959 BuiltTime: Fri Jun 25 23:49:19 2021 GitCommit: "" GoVersion: go1.16.4 OsArch: linux/amd64 Version: 3.2.2

------------------------------------------------------Dockerfile- Start-------------------------------------------

FROM quay.io/podman/stable:latest

RUN touch /etc/subgid /etc/subuid
&& chmod g=u /etc/subgid /etc/subuid /etc/passwd
&& echo podman:10000:5000 > /etc/subuid
&& echo podman:10000:5000 > /etc/subgid

RUN yum install -y
python3-pip
python3 python3-wheel
git
java-11-openjdk.x86_64

RUN pip install jupyterlab

ARG MAVEN_VERSION=3.8.1 ARG BASE_URL=https://apache.osuosl.org/maven/maven-3/${MAVEN_VERSION}/binaries

RUN mkdir -p /usr/share/maven /usr/share/maven/ref
&& curl -fsSL -o /tmp/apache-maven.tar.gz ${BASE_URL}/apache-maven-${MAVEN_VERSION}-bin.tar.gz
&& tar -xzf /tmp/apache-maven.tar.gz -C /usr/share/maven --strip-components=1
&& rm -f /tmp/apache-maven.tar.gz
&& ln -s /usr/share/maven/bin/mvn /usr/bin/mvn
&& yum install wget -y
&& yum install unzip -y
&& wget -q https://services.gradle.org/distributions/gradle-3.3-bin.zip
&& unzip gradle-3.3-bin.zip -d /opt
&& rm gradle-3.3-bin.zip

ENV JAVA_HOME /usr/lib/jvm/jre-11-openjdk/ ENV MAVEN_HOME /usr/share/maven ENV GRADLE_HOME /opt/gradle-3.3 ENV PATH $PATH:/opt/gradle-3.3/bin

COPY registries.conf /etc/containers/ COPY login-script.sh /etc/containers/ RUN chmod -R 777 /etc/containers/login-script.sh USER podman

WORKDIR /data

ENTRYPOINT ["/etc/containers/login-script.sh"]

-------------------------------------------Dockerfile End-------------------------------------------

SELinux: container exits with code 139

kind bug

Description

podman run busybox echo hello world returns exit code 139. 139 is not part of the listed exit codes in https://github.com/projectatomic/libpod/blob/master/docs/podman-run.1.md

Steps to reproduce the issue:

I'm provisioning a Vagrant Box using the vagrantfile

Vagrant.configure('2') do |config|
  config.vm.box = "fedora/27-cloud-base"

  # Docker
  config.vm.provision :docker

  # Install appc tools & rocket
  config.vm.provision :shell,inline: <<EOF


EOF
end

> vagrant ssh
Last login: Thu Jul 19 20:49:03 2018 from 10.0.2.2
[vagrant@localhost ~]$ sudo -s
[root@localhost vagrant]# podman run busybox echo hello world
[root@localhost vagrant]# echo $?
139

Output of podman version:

podman version 0.7.1

Output of podman info:

host:
  MemFree: 85467136
  MemTotal: 509480960
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 1
  hostname: localhost.localdomain
  kernel: 4.13.9-300.fc27.x86_64
  os: linux
  uptime: 13m 1.36s
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
store:
  ContainerStore:
    number: 2
  GraphDriverName: overlay
  GraphOptions:
  - overlay.override_kernel_check=true
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
  ImageStore:
    number: 1
  RunRoot: /var/run/containers/storage```

**Additional environment details (AWS, VirtualBox, physical, etc.):**

see Vagrantfile above

Cirrus: Support testing of VM cache-image changes

Previously, it was quite difficult to affect changes to VM cache images without lots of manual work. This commit adds a new optional testing task which mirrors the official-image build task which only runs on master. In contrast, the new task may be run at any time in a PR, but including a magic phrase in the PR description:

Update documentation to describe the new task and inform on it's usage.

Signed-off-by: Chris Evich [email protected]
[Feature]: Disable automatic publishing of all ports for kube play
Feature request description

Currently podman kube play automatically publishes all ports which are defined in Kubernetes YAMLs as containerPort.

Kubernetes YAML example:

apiVersion: v1 kind: Pod metadata: name: all-ports-published-reproducer spec: containers: - name: all-ports-published-reproducer-nginx image: "docker.io/bitnami/nginx:1.23" env: - name: NGINX_HTTP_PORT_NUMBER value: "8082" ports: - name: http containerPort: 8082

Podman command: podman kube play all-ports-published-reproducer.yaml

Output of podman port --latest: 8082/tcp -> 0.0.0.0:8082

Users should be able to disable this behavior to prevent accidentally publishing ports to the outside world.

Suggest potential solution

Similiarly to #16880 a new flag --publish-all like the one in podman run should be added to podman kube play.
This flag should accept a boolean parameter which is true by default to preserve the current behavior.

If --publish-all=false is set ports should not be automatically published and only be published if the Kubernetes YAML explicitly defines the hostPort field.

Kubernetes YAML example with explicit hostPort set.

apiVersion: v1 kind: Pod metadata: name: all-ports-published-reproducer spec: containers: - name: all-ports-published-reproducer-nginx image: "docker.io/bitnami/nginx:1.23" env: - name: NGINX_HTTP_PORT_NUMBER value: "8082" ports: - name: http containerPort: 8082 hostPort: 80

Have you considered any alternatives?

Podman Quadlets would be an alternative but would prevent users from using already existing Kubernetes YAMLs / Helm charts.

Additional context

#16766 introduces a change to publish ports on a random port instead of reusing the containerPort field of the Kubernetes YAML if hostPort is not set.
If the new flag --publish-all is set to false and the hostPort field is explicitly set to 0 the port should be published on a random port.

Even if firewalld is active on the server netavark currently allows these automatically published ports to be reachable from the outside world, which might be a security concern.
Resolve symlink path for qemu directory if possible
Fixes https://github.com/containers/podman/issues/17026 Fixes https://github.com/NixOS/nixpkgs/issues/169118

Related: https://github.com/NixOS/nixpkgs/pull/163015

Does this PR introduce a user-facing change?

None
[Bug]: aarch64-darwin: podman installed from nixpkgs uses wrong path for edk2-aarch64-code.fd
Issue Description

podman 4.3.1 installed via nixpkgs, I get an error about the path to edk2-aarch64-code.fd upon podman machine start. Several prior related issues and PRs:

https://github.com/containers/podman/issues/12379

https://github.com/containers/podman/issues/13394

https://github.com/NixOS/nixpkgs/issues/169118

https://github.com/NixOS/nixpkgs/pull/163015

https://github.com/containers/podman/issues/12379

It looks like the current code requires minimal changes to work with nixpkgs -- just resolve the symlink to the real location of qemu in the nix path and everything works.

Steps to reproduce the issue

Steps to reproduce the issue

nix shell nixpkgs#podman

podman machine init

podman machine start

Describe the results you received

Error about path to edk2-aarch64-code.fd (sorry, now getting a different error about the socket -- will update this with the error output after a reboot).

UPDATE:

$ podman machine start Starting machine "podman-machine-default" Waiting for VM ... Error: qemu exited unexpectedly with exit code 1, stderr: qemu-system-aarch64: -drive file=edk2-aarch64-code.fd,if=pflash,format=raw,readonly=on: Could not open 'edk2-aarch64-code.fd': No such file or directory

Describe the results you expected

Podman starts

podman info output

$ podman --version podman version 4.3.1 `podman info` gives an error

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

No

Additional environment details

MacOS 13.1, nixpkgs 22.11

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[Bug]: 4.2.0 play kube with service-container=true fails to launch all pods defined in a single kube yaml.

Issue Description

I'm trying to launch multiple pods defined in a single kube yaml using podman-kube@$escaped.service. However, it only managed to launch the first pod defined in the file. /usr/lib/systemd/user/[email protected] shows: ExecStart=/usr/bin/podman play kube --replace --service-container=true %I

If the kube yaml file is launched manually by using the same command, .i.e. podman play kube --replace --service-container=true kube.yaml, it also shows the same issue.

If --service-container=true is not specified, all pods were able to launch.

Steps to reproduce the issue

Create a kube.yaml containing multiple pods.
Use systemctl --user start podman-kube@$escaped.service to start the pods.

The same issue can also be reproduced by using podman play kube --replace --service-container=true kube.yaml

Describe the results you received

Only the first pod defined in the kube.yaml was launched.

Describe the results you expected

All pods in the kube.yaml should launch.

podman info output

host:
  arch: amd64
  buildahVersion: 1.27.1
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.4-1.module+el8.7.0+17064+3b31f55c.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.4, commit: 64e1fe3ac604668d46b6efda338a9ba5a9b91b98'
  cpuUtilization:
    idlePercent: 92.33
    systemPercent: 1.39
    userPercent: 6.28
  cpus: 4
  distribution:
    distribution: '"rhel"'
    version: "8.7"
  eventLogger: file
  hostname: rhel8-7-ecs
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 4.18.0-425.3.1.el8.x86_64
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 5981913088
  memTotal: 16595697664
  networkBackend: cni
  ociRuntime:
    name: runc
    package: runc-1.1.4-1.module+el8.7.0+17064+3b31f55c.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.1.4
      spec: 1.0.2-dev
      go: go1.18.7
      libseccomp: 2.5.2
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_NET_RAW,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-2.module+el8.7.0+17064+3b31f55c.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 8476684288
  swapTotal: 8476684288
  uptime: 44h 37m 21.00s (Approximately 1.83 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/user01/.config/containers/storage.conf
  containerStore:
    number: 11
    paused: 0
    running: 11
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/user01/.local/share/containers/storage
  graphRootAllocated: 32074952704
  graphRootUsed: 16048635904
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 25
  runRoot: /run/user/1000/containers
  volumePath: /home/user01/.local/share/containers/storage/volumes
version:
  APIVersion: 4.2.0
  Built: 1666812227
  BuiltTime: Thu Oct 27 03:23:47 2022
  GitCommit: ""
  GoVersion: go1.18.7
  Os: linux
  OsArch: linux/amd64
  Version: 4.2.0

Podman in a container

Privileged Or Rootless

Rootless

Upstream Latest Release

Additional environment details

RHEL 8.6

Additional information

No response

[CI:DOCS] Improve basic tutorial
Closes #17019

Use -l consistently instead of mixing <container_id> , --latest and -l.

Guide the reader to use the container id instead of -l when using the remote Podman client.

Signed-off-by: biergit [email protected]

Does this PR introduce a user-facing change?

None
Improve basic usage tutorial by mentioning limited support for "--latest" / "-l"

The commands in the basic usage tutorial do not work for Windows and probably neither for Mac (see "--latest" documentation). I would suggest to either mention the current limitation around using the "--latest" flag or go with something that works in all environments to improve the first impression when picking up Podman.

Podman: A tool for managing OCI containers and pods

Podman: A tool for managing OCI containers and pods

Overview and scope

Roadmap

Communications

Rootless

Out of scope

OCI Projects Plans

Podman Information for Developers

Buildah and Podman relationship

Podman Former API (Varlink)

Static Binary Builds

Owner

Containers

Comments

Support native source folder for volume mount in remote model

After podman 2 upgrade, systemd fails to start in containers on cgroups v1 hosts

Package up podman for vanilla Debian

Update: Debian tickets

Cirrus: Bump Fedora to release 35

What this PR does / why we need it:

How to verify it

Which issue(s) this PR fixes:

Special notes for your reviewer:

How to access docker api on a mac

"Error: invalid configuration, cannot specify resource limits without cgroups v2 and --cgroup-manager=systemd"

Running containers inside of a container environment (with docker-compose.yml) using podman?

Version 4.x not updating with apt update Ubuntu 20.04

error running container: error from /usr/bin/crun creating container for [/bin/sh -c pip install -r requirements.txt]: mount `/proc` to `/proc`: Operation not permitted

SELinux: container exits with code 139

Cirrus: Support testing of VM cache-image changes

[Feature]: Disable automatic publishing of all ports for kube play

Feature request description

Suggest potential solution

Have you considered any alternatives?

Additional context

Resolve symlink path for qemu directory if possible

Does this PR introduce a user-facing change?

[Bug]: aarch64-darwin: podman installed from nixpkgs uses wrong path for edk2-aarch64-code.fd

Issue Description

Steps to reproduce the issue

Describe the results you received

Describe the results you expected

podman info output

Podman in a container

Privileged Or Rootless

Upstream Latest Release

Additional environment details

Additional information

[Bug]: 4.2.0 play kube with service-container=true fails to launch all pods defined in a single kube yaml.

Issue Description

Steps to reproduce the issue

Describe the results you received

Describe the results you expected

podman info output

Podman in a container

Privileged Or Rootless

Upstream Latest Release

Additional environment details

Additional information

[CI:DOCS] Improve basic tutorial

Does this PR introduce a user-facing change?

Improve basic usage tutorial by mentioning limited support for "--latest" / "-l"

Related tags

a tool for getting metrics in containers

Gorsair hacks its way into remote docker containers that expose their APIs

Experimental code execution microservice based on Docker containers.

Apptainer: Application containers for Linux

A fluxcd controller for managing manifests declared in jsonnet

[TOOL, CLI] - Filter and examine Go type structures, interfaces and their transitive dependencies and relationships. Export structural types as TypeScript value object or bare type representations.

The forgotten go tool that executes and caches binaries included in go.mod files.

A tool to run queries in defined frequency and expose the count as prometheus metrics.

CodePlayground is a playground tool for go and rust language.

Nomad Pack is a templating and packaging tool used with HashiCorp Nomad.

Tool for printing a directory tree and indicating the space it occupies.

A profiling tool to peek and profile the memory or cpu usage of a process

LDMud OBJ_DUMP Parser and Database Tool

A tool to download and install TiDB components

Tool, language and decoders for inspecting binary data.

This application is a tool that allows you to prepare mail designs specific to your group and make Christmas raffles.