When an unsupported limit on cgroups V1 rootless systems
is requested, podman prints an warning message and
ignores the option/flag.
```
Target options/flags:
--cpu-period, --cpu-quota, --cpu-rt-period, --cpu-rt-runtime,
--cpus, --cpu-shares, --cpuset-cpus, --cpuset-mems, --memory,
--memory-reservation, --memory-swap, --memory-swappiness,
--blkio-weight, --device-read-bps, --device-write-bps,
--device-read-iops, --device-write-iops, --blkio-weight-device
```
Related to https://github.com/containers/podman/discussions/10152
Signed-off-by: Toshiki Sonoda <sonoda.toshiki@fujitsu.com>
Refactor the --creds option. I went with the one in podman-pull
The main difference between all of them is the '####' line,
differences in the param descriptions. podman-pull had the
clearest one.
This is another one that hack/markdown-preprocess-review is
good for reviewing.
Signed-off-by: Ed Santiago <santiago@redhat.com>
After pulling/creating an image of a foreign platform, Podman will
happily use it when looking it up in the local storage and will not
pull down the image matching the host platform.
As discussed in #12682, the reasoning for it is Docker compatibility and
the fact that user already rely on the behavior. While Podman is now
emitting a warning when an image is in use not matching the local
platform, the documentation was lacking that information.
Fixes: #15300
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
...and, tweak markdown-process-review so it can detect and
remove identical files, making review easier.
Signed-off-by: Ed Santiago <santiago@redhat.com>
This exposed a nasty bug in our system-test setup: Ubuntu (runc)
was writing a scratch containers.conf file, and setting CONTAINERS_CONF
to point to it. This was well-intentionedly introduced in #10199 as
part of our long sad history of not testing runc. What I did not
understand at that time is that CONTAINERS_CONF is **dangerous**:
it does not mean "I will read standard containers.conf and then
override", it means "I will **IGNORE** standard containers.conf
and use only the settings in this file"! So on Ubuntu we were
losing all the default settings: capabilities, sysctls, all.
Yes, this is documented in containers.conf(5) but it is such
a huge violation of POLA that I need to repeat it.
In #14972, as yet another attempt to fix our runc crisis, I
introduced a new runc-override mechanism: create a custom
/etc/containers/containers.conf when OCI_RUNTIME=runc.
Unlike the CONTAINERS_CONF envariable, the /etc file
actually means what you think it means: "read the default
file first, then override with the /etc file contents".
I.e., we get the desired defaults. But I didn't remember
this helpers.bash workaround, so our runc testing has
actually been flawed: we have not been testing with
the system containers.conf. This commit removes the
no-longer-needed and never-actually-wanted workaround,
and by virtue of testing the cap-drops in kube generate,
we add a regression test to make sure this never happens
again.
It's a little scary that we haven't been testing capabilities.
Also scary: this PR requires python, for converting yaml to json.
I think that should be safe: python3 'import yaml' and 'json'
works fine on a RHEL8.7 VM from 1minutetip.
Signed-off-by: Ed Santiago <santiago@redhat.com>
This also adds FreeBSD equivalents to the functions moved to
oci_conmon*_linux.go. For openUnixSocket, we create a temporary symlink
to shorten the path to something that fits into sockaddr_un.
[NO NEW TESTS NEEDED]
Signed-off-by: Doug Rabson <dfr@rabson.org>
This function depends on linux-specific functionality in /proc/fd to
allow connecting to local domain sockets with pathnames too long for
sockaddr_un.
[NO NEW TESTS NEEDED]
Signed-off-by: Doug Rabson <dfr@rabson.org>