We want to return a map of containermounts where the key is container
id and it points to the mountpath.
Issue #2215
Signed-off-by: baude <bbaude@redhat.com>
The --queit option is supposed to suppress the pulling messages
when a new image is being pulled down.
This patch fixes this issue.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
initial enablement of podman-remote version. includes add a APIVersion const
that will allow us to check compatibility between host/client when connections
are made.
also added client related information to podman info.
Signed-off-by: baude <bbaude@redhat.com>
Masking main level, image, and container commands that are not yet
implemented for the remote client. As each command is completed, be
sure to unmask it.
Also, masking podman command line switches that are not applicable
to the remote client.
Signed-off-by: baude <bbaude@redhat.com>
This will now verify labels passed in by the user.
Will also prevent users from accidently relabeling their homedir.
podman run -ti -v ~/home/user:Z fedora sh
Is not a good idea.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Return errors when executing the --format templates. Otherwise,
Podman will just silently ignore them and not print any output
that could guide user into solving the issue.
Fixes: #2159
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
We clean up the code by eliminating stuttering references when we embed
the runtime struct into localRuntime. Makes for less change in the future
as well.
++ jhonce
Signed-off-by: baude <bbaude@redhat.com>
Add the ability to run the integration (ginkgo) suite using
the remote client.
Only the images_test.go file is run right now; all the rest are
isolated with a // +build !remotelinux. As more content is
developed for the remote client, we can unblock the files and
just block single tests as needed.
Signed-off-by: baude <bbaude@redhat.com>
We were never loading the storage.conf file to grab mountOptions.
This is causing us to not use metacopyup option when running with
overlay.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
when defining containers, we missed the conditional logic to allow
the container to be defined with "WithPod" and so forth. I had to
slightly modify the createcontainer process to pass a libpod.Pod
that could override things; use nil as no pod.
Signed-off-by: baude <bbaude@redhat.com>
When --pod is specified then join both the user and mount namespace
for the pod so we can initialize the storage.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
If we are not able to make arbitrary changes to the RLIMIT_NOFILE when
lacking CAP_SYS_RESOURCE, don't fail but bump the limit to the maximum
allowed. In this way the same code path works with rootless mode.
Closes: https://github.com/containers/libpod/issues/2123
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Avoid generating
quay.io/openshift-release-dev/ocp-release@sha256@sha256:239... and
similar when the image name is already digest-based [1]. It's not
clear exactly how we get into this state, but as shown by the unit
tests, the new code handles this case correctly (while the previous
code does not).
[1]: https://github.com/containers/libpod/issues/2086
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #2106
Approved by: rhatdan
Apply the default AppArmor profile at container initialization to cover
all possible code paths (i.e., podman-{start,run}) before executing the
runtime. This allows moving most of the logic into pkg/apparmor.
Also make the loading and application of the default AppArmor profile
versio-indepenent by checking for the `libpod-default-` prefix and
over-writing the profile in the run-time spec if needed.
The intitial run-time spec of the container differs a bit from the
applied one when having started the container, which results in
displaying a potentially outdated AppArmor profile when inspecting
a container. To fix that, load the container config from the file
system if present and use it to display the data.
Fixes: #2107
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The --sig-proxy option in both 'podman attach' and 'podman run' default
to true, and there's no reason for 'podman start --attach' to be any
different. However, since it only makes sense to proxy signals when
the container is attached, 'podman start --sig-proxy' will continue to
error if --attach isn't used.
Signed-off-by: Debarshi Ray <rishi@fedoraproject.org>
