In `podman inspect` output for containers and pods, we include
the command that was used to create the container. This is also
used by `podman generate systemd --new` to generate unit files.
With remote podman, the generated create commands were incorrect
since we sourced directly from os.Args on the server side, which
was guaranteed to be `podman system service` (or some variant
thereof). The solution is to pass the command along in the
Specgen or PodSpecgen, where we can source it from the client's
os.Args.
This will still be VERY iffy for mixed local/remote use (doing a
`podman --remote run ...` on a remote client then a
`podman generate systemd --new` on the server on the same
container will not work, because the `--remote` flag will slip
in) but at the very least the output of `podman inspect` will be
correct. We can look into properly handling `--remote` (parsing
it out would be a little iffy) in a future PR.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
With the advent of Podman 2.0.0 we crossed the magical barrier of go
modules. While we were able to continue importing all packages inside
of the project, the project could not be vendored anymore from the
outside.
Move the go module to new major version and change all imports to
`github.com/containers/libpod/v2`. The renaming of the imports
was done via `gomove` [1].
[1] https://github.com/KSubedi/gomove
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
This change ensures that we only override a container's entrypoint if it
is set to something other than `nil`.
Signed-off-by: Matt Brindley <58414429+maybe-sybr@users.noreply.github.com>
Add support to auto-update containers running in systemd units as
generated with `podman generate systemd --new`.
`podman auto-update` looks up containers with a specified
"io.containers.autoupdate" label (i.e., the auto-update policy).
If the label is present and set to "image", Podman reaches out to the
corresponding registry to check if the image has been updated. We
consider an image to be updated if the digest in the local storage is
different than the one of the remote image. If an image must be
updated, Podman pulls it down and restarts the container. Note that the
restarting sequence relies on systemd.
At container-creation time, Podman looks up the "PODMAN_SYSTEMD_UNIT"
environment variables and stores it verbatim in the container's label.
This variable is now set by all systemd units generated by
`podman-generate-systemd` and is set to `%n` (i.e., the name of systemd
unit starting the container). This data is then being used in the
auto-update sequence to instruct systemd (via DBUS) to restart the unit
and hence to restart the container.
Note that this implementation of auto-updates relies on systemd and
requires a fully-qualified image reference to be used to create the
container. This enforcement is necessary to know which image to
actually check and pull. If we used an image ID, we would not know
which image to check/pull anymore.
Fixes: #3575
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The --rmi flag will delete the container image after its execution
unless that image is already been used by another container(s).
This is useful when one wants to execute a container once and remove
any resources attached to it.
Signed-off-by: Boaz Shuster <boaz.shuster.github@gmail.com>
This patch allows users to specify the list of capabilities required
to run their container image.
Setting a image/container label "io.containers.capabilities=setuid,setgid"
tells podman that the contained image should work fine with just these two
capabilties, instead of running with the default capabilities, podman will
launch the container with just these capabilties.
If the user or image specified capabilities that are not in the default set,
the container will print an error message and will continue to run with the
default capabilities.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Before Libpod supported named volumes, we approximated image
volumes by bind-mounting in per-container temporary directories.
This was handled by Libpod, and had a corresponding database
entry to enable/disable it.
However, when we enabled named volumes, we completely rewrote the
old implementation; none of the old bind mount implementation
still exists, save one flag in the database. With nothing
remaining to use it, it has no further purpose.
Signed-off-by: Matthew Heon <mheon@redhat.com>
this uses the specgen structure to create containers rather than the outdated createconfig. right now, only the apiv2 create is wired up. eventually the cli will also have to be done.
Signed-off-by: Brent Baude <bbaude@redhat.com>
fix#4876
Add `--device-cgroup-rule` to podman create and run. This enables to add device rules after the container has been created.
Signed-off-by: Qi Wang <qiwan@redhat.com>
Add pkg/seccomp to consolidate all seccomp-policy related code which is
currently scattered across multiple packages and complicating the
creatconfig refactoring.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
support a custom tag to add to each log for the container.
It is currently supported only by the journald backend.
Closes: https://github.com/containers/libpod/issues/3653
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Implement a policy for selecting a seccomp profile. In addition to the
default behaviour (default profile unless --security-opt seccomp is set)
add a second policy doing a lookup in the image annotation.
If the image has the "io.containers.seccomp.profile" set its value will be
interpreted as a seccomp profile. The policy can be selected via the
new --seccomp-policy CLI flag.
Once the containers.conf support is merged into libpod, we can add an
option there as well.
Note that this feature is marked as experimental and may change in the
future.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
As it stands, createconfig is a huge struct. This works fine when the only caller is when we create a container with a fully created config. However, if we wish to share code for security and namespace configuration, a single large struct becomes unweildy, as well as difficult to configure with the single createConfigToOCISpec function.
This PR breaks up namespace and security configuration into their own structs, with the eventual goal of allowing the namespace/security fields to be configured by the pod create cli, and allow the infra container to share this with the pod's containers.
Signed-off-by: Peter Hunt <pehunt@redhat.com>
Move to containers/image v5 and containers/buildah to v1.11.4.
Replace an equality check with a type assertion when checking for a
docker.ErrUnauthorizedForCredentials in `podman login`.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
For non-Podman users of Libpod, we don't want to force the exit
command to use ARGV[0], which probably does not support a cleanup
command.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
"init" is a quite common name for the command executed in a container
image and Podman ends up using the systemd mode also when not
required.
Be stricter on enabling the systemd mode and not enable it
automatically when the basename is "init" but expect the full path
"/usr/sbin/init".
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This requires updating all import paths throughout, and a matching
buildah update to interoperate.
I can't figure out the reason for go.mod tracking
github.com/containers/image v3.0.2+incompatible // indirect
((go mod graph) lists it as a direct dependency of libpod, but
(go list -json -m all) lists it as an indirect dependency),
but at least looking at the vendor subdirectory, it doesn't seem
to be actually used in the built binaries.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In order to run Podman with VM-based runtimes unprivileged, the
network must be set up prior to the container creation. Therefore
this commit modifies Podman to run rootless containers by:
1. create a network namespace
2. pass the netns persistent mount path to the slirp4netns
to create the tap inferface
3. pass the netns path to the OCI spec, so the runtime can
enter the netns
Closes#2897
Signed-off-by: Gabi Beyer <gabrielle.n.beyer@intel.com>
This is mostly used with Systemd, which really wants to manage
CGroups itself when managing containers via unit file.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Previously, we use CreateConfig's Command to populate container
Command (which is used as CMD for Inspect and Commit).
Unfortunately, CreateConfig's Command is the container's full
command, including a prepend of Entrypoint - so we duplicate
Entrypoint for images that include it.
Maintain a separate UserCommand in CreateConfig that does not
include the entrypoint, and use that instead.
Fixes#3708
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
In order to run Podman with VM-based runtimes unprivileged, the
network must be set up prior to the container creation. Therefore
this commit modifies Podman to run rootless containers by:
1. create a network namespace
2. pass the netns persistent mount path to the slirp4netns
to create the tap inferface
3. pass the netns path to the OCI spec, so the runtime can
enter the netns
Closes#2897
Signed-off-by: Gabi Beyer <gabrielle.n.beyer@intel.com>
allow a container to run in a new cgroup namespace.
When running in a new cgroup namespace, the current cgroup appears to
be the root, so that there is no way for the container to access
cgroups outside of its own subtree.
By default it uses --cgroup=host to keep the previous behavior.
To create a new namespace, --cgroup=private must be provided.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
the compilation demands of having libpod in main is a burden for the
remote client compilations. to combat this, we should move the use of
libpod structs, vars, constants, and functions into the adapter code
where it will only be compiled by the local client.
this should result in cleaner code organization and smaller binaries. it
should also help if we ever need to compile the remote client on
non-Linux operating systems natively (not cross-compiled).
Signed-off-by: baude <bbaude@redhat.com>
We made changes earlier that empty storage options when setting
storage driver explicitly. Unfortunately, this breaks rootless
cleanup commands, as they lose the fuse-overlayfs mount program
path.
Fix this by passing along the storage options to the cleanup
process.
Also, fix --syslog, which was broken a while ago (probably when
we broke up main to add main_remote).
Fixes#3326
Signed-off-by: Matthew Heon <mheon@redhat.com>
The on-failure restart option supports restarting only a given
number of times. To do this, we need one additional field in the
DB to track restart count (which conveniently fills a field in
Inspect we weren't populating), plus some plumbing logic.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Unify handling for the --volume, --mount, --volumes-from, --tmpfs
and --init flags into a single file and set of functions. This
will greatly improve readability and maintainability.
Further, properly handle superceding and conflicting mounts. Our
current patchwork has serious issues when mounts conflict, or
when a mount from --volumes-from or an image volume should be
overwritten by a user volume or named volume.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Play kube was passing the pod, but CreateConfig was not. Unify it
so they both do, so we can remove some unnecessary duplicate
lookup code.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The goal here is to keep only the configuration directly used to
build the container in CreateConfig, and scrub temporary state
and helpers that we need to generate. We'll keep those internally
in MakeContainerConfig.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Right now, there are two major API calls necessary to turn a
filled-in CreateConfig into the options and OCI spec necessary to
make a libpod Container. I'm intending on refactoring both of
these extensively to unify a few things, so make a common
frontend to both that will prevent API changes from leaking out
of the package.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
build a podman-remote binary for windows that allows users to use the
remote client on windows and interact with podman on linux system.
Signed-off-by: baude <bbaude@redhat.com>
The --read-only-tmpfs option caused podman to mount tmpfs on /run, /tmp, /var/tmp
if the container is running int read-only mode.
The default is true, so you would need to execute a command like
--read-only --read-only-tmpfs=false to turn off this behaviour.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We were never using it. It's actually a potentially quite sizable
field (very expensive to decode an array of structs!). Removing
it should do no harm.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Matthew Heon
Valentin Rothberg
maybe-sybr
Daniel J Walsh
Brent Baude
OpenShift Merge Robot
Boaz Shuster
Matthew Heon
Qi Wang
Giuseppe Scrivano
Peter Hunt
Jakub Filak
Nalin Dahyabhai
Miloslav Trmač
Gabi Beyer
James Cassell