Add documentation for undocumented API parameters across multiple endpoints:
System:
- POST /libpod/system/prune: all, volumes, external, build, filters
Pods:
- DELETE /libpod/pods/{name}: timeout
- GET /libpod/pods/stats: stream, delay
Volumes:
- DELETE /volumes/{name}: timeout
- DELETE /libpod/volumes/{name}: timeout
Containers:
- GET /libpod/containers/stats: all
- POST /libpod/containers/{name}/restart: timeout
- POST /libpod/containers/{name}/resize: running
Images:
- POST /images/create: retry, retryDelay
- GET /images/json: shared-size
Exec:
- POST /libpod/exec/{id}/resize: running
Generate:
- GET /libpod/generate/{name}/systemd: templateUnitFile
Signed-off-by: Tim Zhou <tizhou@redhat.com>
Fix a few new issues reported by the linter update.
There is no need to copy the capAdd/capDrop slice in the compat create
endpoint as they are only read and not modified.
For the other code preallocate the slices so we safe memory allocations.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Replace the JSON marshal/unmarshal round-trip in Inherit() with
copier.Copy. json.Unmarshal reuses existing slice backing arrays
and does not zero struct fields absent from the JSON (omitempty),
so mount options like "ro" from one mount would leak into another
mount at the same backing-array position.
Fixes the case where running:
podman run --pod mypod \
--mount type=bind,src=/a,target=/mylog \
--mount type=bind,src=/b,target=/mytmp,ro=true \
alpine touch /mylog/a
incorrectly fails with "Read-only file system" because /mylog
inherits "ro" from /mytmp.
Fixes: https://issues.redhat.com/browse/RHEL-154348
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
The JSONProgress is not part of moby/moby API anymore:
f4127d76c5
To stay compatible with the previous client version, this commit backports
the jsonmessage.JSONProgress.String() and uses it to genereate
the progress report.
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
Replace github.com/docker/docker API imports with github.com/moby/moby
across compat handlers, swagger models, and tests to align with upstream
type definitions.
Fixes: #27536.
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
This allows things like compose project names to be associated with log
messages and later used in log processing and analysis.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
For remote operation, start the remote service with --tls-details:
using --tls-details on the client side will only affect client's
connection.
This should eventually include many more tests - track down all current
uses of libpod.Runtime.{SystemContext,imageContext,LibimageRuntime}.
That will come later
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Currently validation that log tag requires journald driver is done in several
places and emits only warning. Making it an error and moving to
`(c *Container) validate()` is a more correct approach.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
There is exactly one caller, with two code paths, and each only
needs _half_ of the function - and they really only share the
parentFlags and Quiet logic. It's easier to do things
directly.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
When we have the _precise_ knowledge of where the parameter boundaries
are, and an API that allows us to express that, just _do that_ instead
of completely unnecessarily worrying about spaces in parameter values.
Also, this allows us to format the code to make the option and value
correspondence much easier to see.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to centralize the conversion from entities.PodmanConfig
to bindings.Options, we will add more code there.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Right now, this correctly handles pullOptions.credentials
which were ignored previously (admittedly that field is never set
by anything...); in the future, it will ensure the two c/image users
won't get out of sync again.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This will make it easier to add one more option,
and removes a risk of passing options in an incorrect order.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This way, the CLI can still call pkg/domain/infra, without needing
a "remote || linux || freebsd" build tag.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Require (linux || freebsd), because the code already does that, in practice.
This just means macOS users of IDEs aren't hit with thousands of compilation
errors (and then the IDE can open an Linux-specific file and then process it
under the Linux assumption, which works much better).
This commit contains the parts that differ somehow.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Require (linux || freebsd), because the code already does that, in practice.
This just means macOS users of IDEs aren't hit with thousands of compilation
errors (and then the IDE can open an Linux-specific file and then process it
under the Linux assumption, which works much better).
This commit ONLY replaces
//go:build !remote
with
//go:build !remote && (linux || freebsd)
and is split from the rest to allow mechanically verifying that fact,
and focusing a review on the other kinds of changes.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
closes: #27411
Adjust SUB_UID and SUB_GID ranges to support running rootless Podman inside a rootless run Podman container.
Also add a test to verify the change and prevent regression.
By default, a new user is assigned the following sub-ID ranges:
SUB_UID_MIN=100000, SUB_GID_MIN=100000, SUB_UID_COUNT=65536, SUB_GID_COUNT=65536
This means the user’s sub-UID and sub-GID ranges are 100000–165535.
When the container is run rootless with the user defined below, ID mappings occur as follows:
- Container ID 0 (root) maps to user ID 1000 on the host (which is the user created below).
- Container IDs 1–65536 map to IDs 100000–165535 on host (the subid range previously mentioned).
If a new user is created inside this container (to build containers for example), it will
attempt to use the default sub-ID range (100000–165535). However, this exceeds the container’s
available ID mapping, since only IDs up to 65536 are mapped. This causes nested rootless Podman
to fail.
To enable container-in-container builds, the sub-ID ranges for the user must be large enough
to provide at least 65536 usable IDs. A minimum SUB_UID_COUNT and SUB_GID_COUNT of 165536 is
required, but 1,000,000 is used here to provide additional margin.
1,000,000 matches the subid range other machines are using, defined in [ignition.go](69b397af49/pkg/machine/ignition/ignition.go (L284-L289)).
The script of other machines modify the subid files directly for 1 user, the `sed` command used in
this fix mimics that.
The test is added as en extension to the 'simple init with username' test case, to prevent having
to create a new VM.
Signed-off-by: dvorst <87502756+dvorst@users.noreply.github.com>
Add a per-volume 'nocreate' option that prevents automatic creation of
named volumes when they don't exist. When specified, Podman will fail
if the volume is not found instead of creating it automatically.
Usage: -v myvolume:/data:nocreate
--mount type=volume,src=myvolume,dst=/data,nocreate
See: #27862
Signed-off-by: Ygal Blum <ygal.blum@gmail.com>
ConfigToSpec() serializes the container config to JSON and deserializes
it into a SpecGenerator. Both structs use the JSON tag "secret_env" but
with incompatible types: the container config uses map[string]*secrets.Secret
(complex objects) while the specgen uses map[string]string (env var name
to secret name). This causes an unmarshal error when cloning containers
that use --secret with type=env.
Fix this by saving and clearing EnvSecrets before JSON marshal (same
pattern as existing tmpSystemd/tmpMounts), then converting the secret
objects to name strings and assigning them to the specgen afterward.
Also fix FillOutSpecGen to not overwrite env secrets populated by
ConfigToSpec when no new secrets are provided on the command line.
Fixes: #28130
Signed-off-by: Ozgur As <ozgur@live.com>
The client and server version can mismatch in which case the client may
fail on something the newer server can understand or the other way
around. Given the server has to parse and validate that output no matter
what there does not seem to be a strong argument for doing this on the
client side again.
Also this means we do leak the sourcepolicy package into the remote
client.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Pass --mount settings and the contents of the --source-policy-file
argument to remote builds.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As I outlined in the design docs this is broken, there are several
data races here because we write to the config files that can be read by
other goroutines in parallel which violates the go memory model and
thus can lead to runtime panics and undefined behavior.
One could fix with a mutex but that would make the whole code base much
more ugly and there is still the risk that something would access this
field without the mutex held.
I am not sure we have any users using this, it never worked for the
storage side and since the service is a not a daemon any user could just
stop and start it again to re-read the files without having to stop
running containers.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
