July 2020 - Podman - Podman List Archives

shouldn't the current directory be the default context for "podman build"?
by Robert P. J. Day 12 Dec '24

12 Dec '24

"man podman-build" suggests that the context argument is optional: SYNOPSIS podman build [options] [context] podman image build [options] [context] ... If no context directory is specified, then Podman will assume the current working directory as the build context, which should contain the Containerfile. but if i have a directory with nothing but a Containerfile, i get: $ podman build Error: no context directory specified, and no containerfile specified $ OTOH, specifying context of current directory: $ podman build . STEP 1: FROM alpine:latest ... etc etc ... thoughts? rday

4 5

image signing
by Hendrik Haddorp 29 Mar '21

29 Mar '21

Hi, is OpenPGP the only supported image signing open supported by podman / skopeo or are there other options? Using OpenGPG works quite fine for me so far but in the end we are trying to sign an image using an IBM 4765 crypto card and so far have not figured out how this can play together. thanks, Hendrk

4 12

Getting Docker Discourse running with Podman
by Philip Rhoades 10 Jan '21

10 Jan '21

People, I can run the discourse image with docker, export the container and import it as an image into podman. The script that manages docker discourse containers is: /var/discourse/launcher and is attached. It would be good if it were possible to just replace all the occurrences of "docker" with "podman", fix version numbers etc and be able to use the script - but can any gurus see dockerisms in the script that will cause podman gotchas for this idea? Thanks, Phil. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: phil(a)pricom.com.au

3 4

Podman API v1.0 Deprecation and Removal Notice
by Tom Sweeney 01 Aug '20

01 Aug '20

The Podman v1.0 API relied on the varlink library (https://github.com/varlink/libvarlink) to handle the underlying client/server calls from the Podman client to the host where the Podman service was running. About one year ago, the Podman team was notified that the varlink library was being deprecated and there would be no further development and little support for it from the varlink library team. This led the Podman team to investigate the use of other client/server technologies and it was decided to develop a RESTful API for Podman using the native Go libraries. This new Podman v2.0 RESTful API was released along with Podman v2.0 in June of 2020 and replaces the Podman API v1.0. As of that time the Podman v1.0 API for Podman is considered to be deprecated. If there are issues with the Podman v1.0 API in versions of Podman prior to v2.0 and those versions are still under support on Red Hat Enterprise Linux (RHEL), the Podman team will make a best effort to address those issues. However, no new feature requests for the v1.0 API will be considered and any problems found with the v1.0 API in Podman v2.0 will not be addressed. The new Podman v2.0 RESTful API is split into two halves: one providing a Docker-compatible API, and a Libpod API providing support for Podman’s unique features such as pods. The new API works in both a rootful and a rootless environment. It is a much more flexible solution and Podman will not have a dependency on another project in order to supply an API. For more information on the Podman v2.0 RESTful API please see articles on the podman.io site (https://podman.io/) and also the documentation for the Podman v2.0 RESTful API (http://docs.podman.io/en/latest/Reference.html) Distributions have to support services for the length of their support agreements. The Podman development team wants to be free to update the version of Podman during this support cycle. Therefore, we are planning to drop support for Podman API v1.0 from distributions Red Hats is the packagers for. The version of Podman, 2.*, which is contained in Fedora 33, scheduled to be released around Oct 31, 2020, will ship with no varlink support. We also plan to drop support from the RHEL8.4 release, spring 2021. Other distributions like OpenSUSE have already disabled varlink support and we have heard that other distributions will follow suit. This also serves as a notification that the Podman v1.0 (varlink) API will be removed from the main GitHub branch of Podman in the near future. With the release of Podman v2.0 the Podman developers deprecated the Podman v1.0 API in favor of the new Podman v2.0 RESTful API. The plan is to remove varlink completely from the Podman v3.0 development branch which will be created some time after September 2020. A 30 day notification of the final removal date will be posted on the https://podman.iosite and also on the Podman mailing list, along with social media once it is definitively determined. If you have any questions or concerns about this notification, please send a note to the Podman mailing list or create an issue on Podman’s GitHub (https://github.com/containers/podman/issues) repository. Note: This notice will be posted to the podman.io site early next week.

2 2

New version of podman available
by Daniel Walsh 27 Jul '20

27 Jul '20

Mainly bugfix release. Please try this out. Please try this out. We would like to know if there are any issues, before it gets released to your favorite distributions. v2.0.3 <https://github.com/containers/podman/releases/tag/v2.0.3> @mheon <https://github.com/mheon> mheon <https://github.com/mheon> released this 16 hours ago · 364 commits <https://github.com/containers/podman/compare/v2.0.3...master> to master since this release Features * The |podman search| command now allows wildcards in search terms. * The |podman play kube| command now supports the |IfNotPresent| pull type. Changes * The |--disable-content-trust| flag has been added to Podman for Docker compatibility. This is a Docker-specific option and has no effect in Podman; it is provided only to ensure command line compatibility for scripts (#7034 <https://github.com/containers/podman/issues/7034>). * Setting a static IP address or MAC address for rootless containers and pods now causes an error; previously, they were silently ignored. * The |/sys/dev| folder is now masked in containers to prevent a potential information leak from the host. Bugfixes * Fixed a bug where rootless Podman would select the wrong cgroup manager on cgroups v1 systems where the user in question had an active systemd user session (#6982 <https://github.com/containers/podman/issues/6982>). * Fixed a bug where systems with Apparmor could not run privileged containers (#6933 <https://github.com/containers/podman/issues/6933>). * Fixed a bug where ENTRYPOINT and CMD from images were improperly handled by |podman play kube| (#6995 <https://github.com/containers/podman/issues/6995>). * Fixed a bug where the |--pids-limit| flag to |podman create| and |podman run| was parsed incorrectly and was unusable (#6908 <https://github.com/containers/podman/issues/6908>). * Fixed a bug where the |podman system df| command would error if untagged images were present (#7015 <https://github.com/containers/podman/issues/7015>). * Fixed a bug where the |podman images| command would display incorrect tags if a port number was included in the repository. * Fixed a bug where Podman did not set a default umask and default rlimits (#6989 <https://github.com/containers/podman/issues/6989>). * Fixed a bug where protocols in port mappings were not recognized unless they were lower-case (#6948 <https://github.com/containers/podman/issues/6948>). * Fixed a bug where information on pod infra containers was not included in the output of |podman pod inspect|. * Fixed a bug where Podman's systemd detection (activated by the enabled-by-default |--systemd=true| flag) would not flag a container for systemd mode if systemd was part of the entrypoint, not the command (#6920 <https://github.com/containers/podman/issues/6920>). * Fixed a bug where |podman start --attach| was not defaulting |--sig-proxy| to true (#6928 <https://github.com/containers/podman/issues/6928>). * Fixed a bug where |podman inspect| would show an incorrect command (|podman system service|, the command used to start the server) for containers created by a remote Podman client. * Fixed a bug where the |podman exec| command with the remote client would not print output if the |-t| or |-i| flags where not provided. * Fixed a bug where some variations of the |--format {{ json . }}| to |podman info| (involving added or removed whitespace) would not be accepted (#6927 <https://github.com/containers/podman/issues/6927>). * Fixed a bug where Entrypoint could not be cleared at the command line (if unset via |--entrypoint=""|, it would be reset to the image's entrypoint) (#6935 <https://github.com/containers/podman/issues/6935>). API * Fixed a bug where the events endpoints (both libpod and compat) could potentially panic on parsing filters. * Fixed a bug where the compat Create endpoint for containers did not properly handle Entrypoint and Command. * Fixed a bug where the Logs endpoint for containers (both libpod and compat) would not properly handle client disconnect, resulting in high CPU usage. * The type of filters on the compat events endpoint has been adjusted to match Docker's implementation (#6899 <https://github.com/containers/podman/issues/6899>). * The idle connection counter now properly handles hijacked connections. * All endpoints that hijack will now properly print headers per RFC 7230 standards. Misc * Updated containers/common to v0.14.6

3 2

Anyone on this list from jfrog/artifactory or know of anyone
by Daniel Walsh 22 Jul '20

22 Jul '20

We seem to have an issue with Podman working with Artifactory that we would like to work through with their engineering team. https://github.com/containers/podman/issues/4254 Would love to have a contact name.

2 1

connecting a container to a bridge network and the host network
by Hendrik Haddorp 21 Jul '20

21 Jul '20

Hi, is it possible to connect a container to a bridge network and also to the host network? I would like for my container to have full access to the hosts network interfaces but still have an IP in the normal bridge network so that other containers can communicate with it normally. thanks, Hendrik

3 4

podman --version 2.0.2 is released
by Daniel Walsh 08 Jul '20

08 Jul '20

We would appreciate people playing with and testing it. We are trying to fix as many small bugs as possible, as quick as possible. Since Podman 2.0 was a major rewrite of the CLI, we are seeing some issues especially around corner cases. Thanks for helping out the community.

1 0

The Podman repository has been renamed
by Daniel Walsh 08 Jul '20

08 Jul '20

The Podman repository has been renamed By Matt Heon GitHub <https://github.com/mheon> The Podman <https://podman.io/> repository on Github is moving from github.com/containers/libpod <https://github.com/containers/libpod> to github.com/containers/podman <https://github.com/containers/podman>! Read on to find out why, and how it will affect you. Three years ago, we created a new Git repository to hold our new container-management tool and the library it was based on. At the time, Podman was not named Podman, but |kpod| - a name no one on the team liked, and one we’d hoped to replace quickly. Given this, we decided to name the repository after the library we’d written to manage containers - |libpod|. Four months after that, we made the first public release of the tool, and with it came a new name - Podman (POD MANager). The rest is, as they say, history. The Podman team is incredibly grateful for the success we’ve seen since then, and the way that the community has grown. ... https://podman.io/blogs/2020/07/07/repo-rename.html

1 0

Supported versions of golang for building Podman.
by Daniel Walsh 08 Jul '20

08 Jul '20

We are going through a rough transition right now, with us dropping support for golang 1.12. This is causing some pain in Ubuntu and Debian communities. The issues is some of the code we vendor from other projects has added requirements that only work on golang 1.13 and beyond. Currently the stable branch of golang is 1.14 and 1.13. Valentin Rothberg reports to me. > Good news is that we are lucky: Debian testing and unstable are both > on Go 1.14 (https://packages.debian.org/search?keywords=golang) He suggests: > a policy that our tools (at new release) must be compatible with the > officially supported versions of Go, which is always the last two > major/minor versions. In case of Podman 2.0: 1.14 and 1.13. If we can > commit to that, the community can't really get angry at us; it's > reasonable to move on once a version hits EOL. However, breaking > changes are always an annoyance ... I agree with this suggestion. And think this is the way we should go forward. We are also working to make sure we can build on Ununtu LTS. RHEL and Centos already can use the golang 1.13 compilers.

1 0