Currently containers created via DOCKER API without specifying
StopTimeout are defaulting to 0 seconds. This change should
default them to setting in containers.conf normally 10 seconds.
Fixes: https://github.com/containers/podman/issues/19139
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Unset the NOTIFY_SOCKET environment variable after sending the MAIN_PID
and READY message. This avoids any unintentional side-effects of other
code paths using the socket assuming they'd run in a non-server
short-lived Podman process.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
This reverts commit 5b148a0a68360892f57603b77e73c69e32fb7b7e.
Reverting to treating the `pull` query parameter as a boolean.
Because of deceiving Docker API documentation it was assumed that the
parameter is pull-policy, however that is not true. Docker does treat
`pull` as a boolean. What is interesting is that Docker indeed accepts
strings like `always` or `never` however Docekr both of these strings
treat as `true`, not as pull-policy. As matter of the fact it seems
there is no such a thing as pull-policy in Docker.
More context https://github.com/containers/podman/issues/17778#issuecomment-1673931925
Signed-off-by: Matej Vasek <mvasek@redhat.com>
Compat api for containers/stop should take -1 value
Add support for `podman stop --time -1`
Add support for `podman restart --time -1`
Add support for `podman rm --time -1`
Add support for `podman pod stop --time -1`
Add support for `podman pod rm --time -1`
Add support for `podman volume rm --time -1`
Add support for `podman network rm --time -1`
Fixes: https://github.com/containers/podman/issues/17542
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Adds support for --add-compression which accepts multiple compression
formats and when used it will add all instances in a manifest list with
requested compression formats.
Signed-off-by: Aditya R <arajan@redhat.com>
Adds support for `since` as a valid filter option for `podman volume ls`
and `podman volume prune`.
Implements: #19228
Initially suggested from: #19119
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Fixes a bug where `podman volume ls` with multiple `label` filters would
return volumes that matched *any* of the filters, not *all* of them.
Adapts generating volume filter functions to be more in
line with how it is done for containers and pods.
Fixes: #19219
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Adds an `--podman-only` flag to `podman generate kube` to allow for
reserved annotations to be included in the generated YAML file.
Associated with: #19102
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
When I reworked pod removal to provide more detailed errors
(including per-container errors, not just a single multierror
with all errors squashed), I made it part of the struct returned
by the REST API and assumed that would be enough to get errors
through to clients. Unfortunately, in case of an overarching
error removing the pod (as any error with any container would
cause), we don't send the response struct that would include the
container errors - we just send a standardized REST error. We
could work around this with custom, potentially backwards
incompatible error handling for the REST pod delete endpoint, or
we could just do what was done before, and package up all the
errors in a multierror to send to the other side. Of those
options, the multierror seems far simpler.
Fixes#19159
Signed-off-by: Matt Heon <mheon@redhat.com>
Adds a `--no-trunc` flag to `podman kube generate` preventing the
annotations from being trimmed at 63 characters. However, due to
the fact the annotations will not be trimmed, any annotation that is
longer than 63 characters means this YAML will no longer be Kubernetes
compatible. However, these YAML files can still be used with `podman
kube play` due to the addition of the new flag below.
Adds a `--no-trunc` flag to `podman kube play` supporting YAML files with
annotations that were not truncated to the Kubernetes maximum length of
63 characters.
Signed-off-by: Jake Correnti <jakecorrenti+github@proton.me>
Previous tests have worked by pure chance since the client and server
ran on the same host; the server picked up the credentials created by
the client login.
Extend the gating tests and add a new integration test which is further
capable of exercising the remote code.
Note that fixing authentication support requires adding a new
`--authfile` CLi flag to `manifest inspect`. This will at least allow
for passing an authfile to be bindings. Username and password are not
yet supported.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
This endpoint queried the same package versions twice causing it to be
slower than info. Because it already called info we can just reuse the
package versions from there.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This ended up more complicated then expected. Lets start first with the
problem to show why I am doing this:
Currently we simply execute ps(1) in the container. This has some
drawbacks. First, obviously you need to have ps(1) in the container
image. That is no always the case especially in small images. Second,
even if you do it will often be only busybox's ps which supports far
less options.
Now we also have psgo which is used by default but that only supports a
small subset of ps(1) options. Implementing all options there is way to
much work.
Docker on the other hand executes ps(1) directly on the host and tries
to filter pids with `-q` an option which is not supported by busybox's
ps and conflicts with other ps(1) arguments. That means they fall back
to full ps(1) on the host and then filter based on the pid in the
output. This is kinda ugly and fails short because users can modify the
ps output and it may not even include the pid in the output which causes
an error.
So every solution has a different drawback, but what if we can combine
them somehow?! This commit tries exactly that.
We use ps(1) from the host and execute that in the container's pid
namespace.
There are some security concerns that must be addressed:
- mount the executable paths for ps and podman itself readonly to
prevent the container from overwriting it via /proc/self/exe.
- set NO_NEW_PRIVS, SET_DUMPABLE and PDEATHSIG
- close all non std fds to prevent leaking files in that the caller had
open
- unset all environment variables to not leak any into the contianer
Technically this could be a breaking change if somebody does not
have ps on the host and only in the container but I find that very
unlikely, we still have the exec in container fallback.
Because this can be insecure when the contianer has CAP_SYS_PTRACE we
still only use the podman exec version in that case.
This updates the docs accordingly, note that podman pod top never falls
back to executing ps in the container as this makes no sense with
multiple containers so I fixed the docs there as well.
Fixes#19001
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2215572
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The libpod API does not set a default. Also PodTop is podman sepecific
so we can just rmeove this extra branch there.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Users may want to replace the secret used within containers, without
destroying the secret and recreating it.
Partial fix for https://github.com/containers/podman/issues/18667
Make sure podman --remote secret inspect and podman secret inspect
return the same error message.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
This adds the 'system service' command to the build on FreeBSD and
suppresses the call to servicereaper.Start which is only needed to
support slirp4netns on Linux. A stub for compat.StatsContainer is also
added - stats are still supported via the libpod.StatsContainer API
call.
[NO NEW TESTS NEEDED]
Signed-off-by: Doug Rabson <dfr@rabson.org>
It is pretty complicated to display the secret on the host, but is
not really secured. This patch makes it easier to examine the secret.
Partial fix for https://github.com/containers/podman/issues/18667
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Somehow my error message in top was never printed for the compat API,
the libpod one using the same code worked fine. Turns out the compat one
is using this buffered writter instaed but never made sure to flush it
before closing the connection.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Wait before sending status code 200 for the first top call and if that
fails return a proper error code.
This was leading to some confusion in [1] because podman just reported
200 but did not wirte anything back.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2215572
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Support two new wait conditions, "healthy" and "unhealthy". This
further paves the way for integrating sdnotify with health checks which
is currently being tracked in #6160.
Fixes: #13627
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Massage the internal APIs to use a string slice instead of a state slice
for passing wait conditions. This paves the way for waiting on
non-state conditions such as "healthy".
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Make sure that the create endpoint does not always return 200 even in
case of a failure. Some of the code had to be massaged since encoding a
report implies sending a 200.
Fixes: #15828
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Make sure that the push endpoint does not always return 200 even in case
of a push failure. Some of the code had to be massaged since encoding a
report implies sending a 200.
Fixes: #18751
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The platform parameter has been ignored such that images have been
looked up by name only.
Fixes: #18951
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
The "removed" condition mapped to an undefined state which ultimately
rendered the wait endpoint to return an incorrect exit code. Instead,
map "removed" to "exited" to make sure Podman returns the expected
exit code.
Fixes: #18889
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
This probably should have been in the API since the beginning,
but it's not too late to start now.
The extra information is returned (both via the REST API, and to
the CLI handler for `podman rm`) but is not yet printed - it
feels like adding it to the output could be a breaking change?
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Fixes: https://github.com/containers/podman/issues/18239
[NO NEW TESTS NEEDED]
@test "podman build -f test" in test/system/070-build.bats
Will test this. This was passing when run on a local system since
the remote end was using the clients path to read the Containerfile
The issue is it would not work in a podman machine since the
Containerfile would/should be a different path.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Also reflect removed/deprecated fields in the compat API.
[NO NEW TESTS NEEDED]
Signed-off-by: Renovate Bot <bot@renovateapp.com>
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
