Fix usage of export when rootless containers are used without vfs. We
join the conmon process namespaces as the container is running in a
different one.
There can be a problem if the user specify a different path for the
conmon process, and then the file is deleted. In this case podman
won't be able to find the conmon process to join.
Closes: https://github.com/containers/libpod/issues/2027
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
podman play kube adds the ability for the user to recreate pods and containers
from a Kubernetes YAML file in libpod.
Signed-off-by: baude <bbaude@redhat.com>
Display the trust policy of the host system. The trust policy is stored in the /etc/containers/policy.json file and defines a scope of registries or repositories.
Signed-off-by: Qi Wang <qiwan@redhat.com>
We need to recommend that users use Systemd unit files if they want
the container to restart automatically.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
no longer require the service object be output to a different file; we should be
doing this inline with the pods for user convenience.
Signed-off-by: baude <bbaude@redhat.com>
when deleting infra containers, we were not checking the error of the
image deletion and therefore resulting in not reporting the error.
Fixes#1991
Signed-off-by: baude <bbaude@redhat.com>
Returns user if user is logged-in to the registry. Returns error
if not logged in with non-zero status code.
Signed-off-by: Theodore Cowan <theodore-cowan@pluralsight.com>
Many RH images use a fully-qualified path to docker in their RUN
labels. While initially we wanted an exact match for substituting
commands, docker is a good exception.
Bug #1623282
Signed-off-by: baude <bbaude@redhat.com>
Going through and adding options (like tls-verify, signature option, etc)
to some varlink endpoints (like push/pull) many of which had not been
updated since their original authoring.
Signed-off-by: baude <bbaude@redhat.com>
when starting or running a container that has --rm, if the starting
container fails (like due to an invalid command), the container should
get removed.
Resolves: #1985
Signed-off-by: baude <bbaude@redhat.com>
when using a driver different than vfs, the mount is probably in a
different mount namespace thus not accessible from the host. Avoid
the confusion by not allowing mount when a different driver is used.
Closes: https://github.com/containers/libpod/issues/1964
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
With rootless containers we cannot really restart an existing container
as we would need to join the mount namespace as well to be able to reuse
the storage, so ensure the container is stopped first.
Closes: https://github.com/containers/libpod/issues/1965
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
like podman stop of containers, we should allow the user to specify
a timeout override when stopping pods; otherwise they have to wait
the full timeout time specified during the pod/container creation.
Signed-off-by: baude <bbaude@redhat.com>
DockerRegistryOptions.DockerInsecureSkipTLSVerify as an types.OptionalBool
can now represent that value, so forceSecure is redundant.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
DockerRegistryOptions.DockerInsecureSkipTLSVerify as an types.OptionalBool
can now represent that value, so forceSecure is redundant.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Following SystemContext.DockerInsecureSkipTLSVerify, make the
DockerRegistryOne also an OptionalBool, and update callers.
Explicitly document that --tls-verify=true and --tls-verify unset
have different behavior in those commands where the behavior changed
(or where it hasn't changed but the documentation needed updating).
Also make the --tls-verify man page sections a tiny bit more consistent
throughout.
This is a minimal fix, without changing the existing "--tls-verify=true"
paths nor existing manual insecure registry lookups.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Per discussion with Dan, it would be better to automatically
handle potential runtime errors by automatically syncing if they
occur. Retaining the flag for `ps` makes sense, as we won't even
be calling the OCI runtime and as such won't see errors if the
state desyncs, but rm can be handled automatically.
The automatic desync handling code will take some additional work
so we'll land this as-is (sync on ps is enough to solve most
desync issues).
Signed-off-by: Matthew Heon <mheon@redhat.com>
The previous commit added support for --sync to podman rm to
ensure state inconsistencies would not prevent containers from
being removed.
Add the flag to podman ps as well, so that all containers can be
forcibly synced and all state inconsistencies resolved.
Signed-off-by: Matthew Heon <mheon@redhat.com>
With the changes made recently to ensure Podman does not hit the
OCI runtime as often to sync state, we can find ourselves in a
situation where the runtime's state does not match ours.
Add a --sync flag to podman rm to ensure we can still remove
containers when this happens.
Signed-off-by: Matthew Heon <mheon@redhat.com>
Add support for podman volume and its subcommands.
The commands supported are:
podman volume create
podman volume inspect
podman volume ls
podman volume rm
podman volume prune
This is a tool to manage volumes used by podman. For now it only handle
named volumes, but eventually it will handle all volumes used by podman.
Signed-off-by: umohnani8 <umohnani@redhat.com>
podman login reg.io/username/image works as well now. It picks
the registry and checks for authentication, if none exist it
will prompt for username and password.
If the credentials exist but are not valid, it will prompt the
user for new valid credentials.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Allow user to prune unused/unnamed images, the layer images from building,
via podman rmi --prune.
Allow user to prune stopped/exiuted containers via podman rm --prune.
This should resolve#1910
Signed-off-by: baude <bbaude@redhat.com>
when deleting all images, we need to iterate all the images deleting on those who dont
have children first. And then reiterate until they are all gone.
This resolves#1926
Signed-off-by: baude <bbaude@redhat.com>
when a user specifies --pod to podman create|run, we should create that pod
automatically. the port bindings from the container are then inherited by
the infra container. this signicantly improves the workflow of running
containers inside pods with podman. the user is still encouraged to use
podman pod create to have more granular control of the pod create options.
Signed-off-by: baude <bbaude@redhat.com>
Part of the motivation for 800eb863 (Hooks supports two directories,
process default and override, 2018-09-17, #1487) was [1]:
> We only use this for override. The reason this was caught is people
> are trying to get hooks to work with CoreOS. You are not allowed to
> write to /usr/share... on CoreOS, so they wanted podman to also look
> at /etc, where users and third parties can write.
But we'd also been disabling hooks completely for rootless users. And
even for root users, the override logic was tricky when folks actually
had content in both directories. For example, if you wanted to
disable a hook from the default directory, you'd have to add a no-op
hook to the override directory.
Also, the previous implementation failed to handle the case where
there hooks defined in the override directory but the default
directory did not exist:
$ podman version
Version: 0.11.2-dev
Go Version: go1.10.3
Git Commit: "6df7409cb5a41c710164c42ed35e33b28f3f7214"
Built: Sun Dec 2 21:30:06 2018
OS/Arch: linux/amd64
$ ls -l /etc/containers/oci/hooks.d/test.json
-rw-r--r--. 1 root root 184 Dec 2 16:27 /etc/containers/oci/hooks.d/test.json
$ podman --log-level=debug run --rm docker.io/library/alpine echo 'successful container' 2>&1 | grep -i hook
time="2018-12-02T21:31:19-08:00" level=debug msg="reading hooks from /usr/share/containers/oci/hooks.d"
time="2018-12-02T21:31:19-08:00" level=warning msg="failed to load hooks: {}%!(EXTRA *os.PathError=open /usr/share/containers/oci/hooks.d: no such file or directory)"
With this commit:
$ podman --log-level=debug run --rm docker.io/library/alpine echo 'successful container' 2>&1 | grep -i hook
time="2018-12-02T21:33:07-08:00" level=debug msg="reading hooks from /usr/share/containers/oci/hooks.d"
time="2018-12-02T21:33:07-08:00" level=debug msg="reading hooks from /etc/containers/oci/hooks.d"
time="2018-12-02T21:33:07-08:00" level=debug msg="added hook /etc/containers/oci/hooks.d/test.json"
time="2018-12-02T21:33:07-08:00" level=debug msg="hook test.json matched; adding to stages [prestart]"
time="2018-12-02T21:33:07-08:00" level=warning msg="implicit hook directories are deprecated; set --hooks-dir="/etc/containers/oci/hooks.d" explicitly to continue to load hooks from this directory"
time="2018-12-02T21:33:07-08:00" level=error msg="container create failed: container_linux.go:336: starting container process caused "process_linux.go:399: container init caused \"process_linux.go:382: running prestart hook 0 caused \\\"error running hook: exit status 1, stdout: , stderr: oh, noes!\\\\n\\\"\""
(I'd setup the hook to error out). You can see that it's silenly
ignoring the ENOENT for /usr/share/containers/oci/hooks.d and
continuing on to load hooks from /etc/containers/oci/hooks.d.
When it loads the hook, it also logs a warning-level message
suggesting that callers explicitly configure their hook directories.
That will help consumers migrate, so we can drop the implicit hook
directories in some future release. When folks *do* explicitly
configure hook directories (via the newly-public --hooks-dir and
hooks_dir options), we error out if they're missing:
$ podman --hooks-dir /does/not/exist run --rm docker.io/library/alpine echo 'successful container'
error setting up OCI Hooks: open /does/not/exist: no such file or directory
I've dropped the trailing "path" from the old, hidden --hooks-dir-path
and hooks_dir_path because I think "dir(ectory)" is already enough
context for "we expect a path argument". I consider this name change
non-breaking because the old forms were undocumented.
Coming back to rootless users, I've enabled hooks now. I expect they
were previously disabled because users had no way to avoid
/usr/share/containers/oci/hooks.d which might contain hooks that
required root permissions. But now rootless users will have to
explicitly configure hook directories, and since their default config
is from ~/.config/containers/libpod.conf, it's a misconfiguration if
it contains hooks_dir entries which point at directories with hooks
that require root access. We error out so they can fix their
libpod.conf.
[1]: https://github.com/containers/libpod/pull/1487#discussion_r218149355
Signed-off-by: W. Trevor King <wking@tremily.us>
