diff options
| -rw-r--r-- | DISTRO_PACKAGE.md | 101 | ||||
| -rw-r--r-- | RELEASE_PROCESS.md | 6 | ||||
| -rw-r--r-- | pkg/api/handlers/compat/exec.go | 2 | ||||
| -rw-r--r-- | troubleshooting.md | 12 |
4 files changed, 113 insertions, 8 deletions
diff --git a/DISTRO_PACKAGE.md b/DISTRO_PACKAGE.md new file mode 100644 index 000000000..133c62d23 --- /dev/null +++ b/DISTRO_PACKAGE.md @@ -0,0 +1,101 @@ +# Podman Packaging + +This document is currently written with Fedora as a reference, intended for use +by packagers of other distros as well as package users. + +## Fedora Users +Podman v4 is available as an official Fedora package on Fedora 36 and rawhide. +This version of Podman brings with it a new container stack called +Netavark which serves as a replacement for CNI plugins +(containernetworking-plugins on Fedora), as well as Aardvark-dns, the +authoritative DNS server for container records. + +Both Netavark and Aardvark-dns are available as official Fedora packages on +Fedora 35 and newer versions and form the default network stack for new +installations of Podman 4.0. + +On Fedora 36 and newer, fresh installations of Podman v4 will +automatically install Aardvark-dns along with Netavark. + +To install Podman v4: + +```console +$ sudo dnf install podman +``` + +To update Podman from an older version to v4: + +```console +$ sudo dnf update podman +``` + +**NOTE:** Fedora 35 users will not be able to install Podman v4 using the default yum +repositories and are recommended to use the COPR repo below: + +```console +$ sudo dnf copr enable rhcontainerbot/podman4 + +# install or update per your needs +$ sudo dnf install podman +``` + +After installation, if you would like to migrate all your containers to use +Netavark, you will need to set `network_backend = "netavark"` under +the `[network]` section in your containers.conf, typically located at: +`/usr/share/containers/containers.conf` + +### Testing the latest development version` + +If you would like to test the latest unreleased upstream code, try the +podman-next COPR + +```console +$ sudo dnf copr enable rhcontainerbot/podman-next + +$ sudo dnf install podman +``` + +**CAUTION:** The podman-next COPR provides the latest unreleased sources of Podman, +Netavark and Aardvark-dns as rpms which would override the versions provided by +the official packages. + +## Distro Packagers + +The Fedora packaging sources for Podman are available at the [Podman +dist-git](https://src.fedoraproject.org/rpms/podman). + +The main `podman` package no longer explicitly depends on +containernetworking-plugins. The network stack dependencies are now handled in +the [containers-common](https://src.fedoraproject.org/rpms/containers-common) +package which allows for a single point of dependency maintenance for Podman +and Buildah. + +- containers-common +``` +Requires: container-network-stack +Recommends: netavark +``` + +- netavark +``` +Provides: container-network-stack = 2 +``` + +- containernetworking-plugins +``` +Provides: container-network-stack = 1 +``` + +This configuration ensures: +- New installations of Podman will always install netavark by default. +- The containernetworking-plugins package will not conflict with netavark and +users can install them together. + +## Listing bundled dependencies +If you need to list the bundled dependencies in your packaging sources, you can +process the `go.mod` file in the upstream source. +For example, Fedora's packaging source uses: + +``` +$ awk '{print "Provides: bundled(golang("$1")) = "$2}' go.mod | sort | uniq | sed -e 's/-/_/g' -e '/bundled(golang())/d' -e '/bundled(golang(go\|module\|replace\|require))/d' +``` diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index bc2e4c01f..3f63e5466 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -241,7 +241,11 @@ spelled with complete minutiae. ```shell $ git checkout vX.Y.Z - $ make podman-remote-release-darwin_amd64.zip podman-remote-release-darwin_arm64.zip podman-remote-release-windows_amd64.zip podman.msi podman-remote-static + $ make podman-remote-release-darwin_amd64.zip \ + podman-remote-release-darwin_arm64.zip \ + podman-remote-release-windows_amd64.zip \ + podman.msi \ + podman-remote-static $ mv podman-* bin/ $ cd bin/ $ tar -cvzf podman-remote-static.tar.gz podman-remote-static diff --git a/pkg/api/handlers/compat/exec.go b/pkg/api/handlers/compat/exec.go index c6f7e0318..def16d1b5 100644 --- a/pkg/api/handlers/compat/exec.go +++ b/pkg/api/handlers/compat/exec.go @@ -73,7 +73,7 @@ func ExecCreateHandler(w http.ResponseWriter, r *http.Request) { // Run the exit command after 5 minutes, to mimic Docker's exec cleanup // behavior. - libpodConfig.ExitCommandDelay = 5 * 60 + libpodConfig.ExitCommandDelay = runtimeConfig.Engine.ExitCommandDelay sessID, err := ctr.ExecCreate(libpodConfig) if err != nil { diff --git a/troubleshooting.md b/troubleshooting.md index 8bce8e50f..93f716e00 100644 --- a/troubleshooting.md +++ b/troubleshooting.md @@ -42,7 +42,7 @@ $ podman run -v ~/mycontent:/content:Z fedora touch /content/file Make sure the content is private for the container. Do not relabel system directories and content. Relabeling system content might cause other confined services on your machine to fail. For these -types of containers we recommend that disable SELinux separation. The option `--security-opt label=disable` +types of containers we recommend having SELinux separation disabled. The option `--security-opt label=disable` will disable SELinux separation for the container. $ podman run --security-opt label=disable -v ~:/home/user fedora touch /home/user/file @@ -157,7 +157,7 @@ When rootless Podman attempts to execute a container on a non exec home director #### Symptom If you are running Podman or Buildah on a home directory that is mounted noexec, -then they will fail. With a message like: +then they will fail with a message like: ``` podman run centos:7 @@ -166,7 +166,7 @@ standard_init_linux.go:203: exec user process caused "permission denied" #### Solution -Since the administrator of the system setup your home directory to be noexec, you will not be allowed to execute containers from storage in your home directory. It is possible to work around this by manually specifying a container storage path that is not on a noexec mount. Simply copy the file /etc/containers/storage.conf to ~/.config/containers/ (creating the directory if necessary). Specify a graphroot directory which is not on a noexec mount point and to which you have read/write privileges. You will need to modify other fields to writable directories as well. +Since the administrator of the system set up your home directory to be noexec, you will not be allowed to execute containers from storage in your home directory. It is possible to work around this by manually specifying a container storage path that is not on a noexec mount. Simply copy the file /etc/containers/storage.conf to ~/.config/containers/ (creating the directory if necessary). Specify a graphroot directory which is not on a noexec mount point and to which you have read/write privileges. You will need to modify other fields to writable directories as well. For example @@ -229,7 +229,7 @@ Rootless Podman requires the user running it to have a range of UIDs listed in / #### Symptom -An user, either via --user or through the default configured for the image, is not mapped inside the namespace. +A user, either via --user or through the default configured for the image, is not mapped inside the namespace. ``` podman run --rm -ti --user 1000000 alpine echo hi @@ -279,7 +279,7 @@ grep johndoe /etc/subuid /etc/subgid ### 11) Changing the location of the Graphroot leads to permission denied When I change the graphroot storage location in storage.conf, the next time I -run Podman I get an error like: +run Podman, I get an error like: ``` # podman run -p 5000:5000 -it centos bash @@ -323,7 +323,7 @@ Pulling an anonymous image that doesn't require authentication can result in an #### Symptom If you pull an anonymous image, one that should not require credentials, you can receive -and `invalid username/password` error if you have credentials established in the +an `invalid username/password` error if you have credentials established in the authentication file for the target container registry that are no longer valid. ``` |