I am really not sure why the caller even should have the option to set
this. We should always use the correct isolation type based on the
privileges the server runs under never the client. podman-remote build
seems to send the default based on its local privs which was wrong as
well. To fix this I also changed the client to send the default if the
isolation flag is not set.
Fixes#22109
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
when the "bind" option is used, do not use the "rprivate" propagation
as it would inhibit the effect of "bind", instead default to "private".
Closes: https://github.com/containers/podman/issues/22107
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
New run_minikube() helper, modeled after run_podman(). Echoes
each command being run and its output. On failure, runs minikube logs.
Addresses (does not close) #21931 which is hitting us hard in CI.
Probably quay flakes, but it's impossible to tell without logs.
Also: bug fix: one "run podman" fixed to run_podman
Signed-off-by: Ed Santiago <santiago@redhat.com>
Always teardown the network, trying to reuse the netns has caused
a significant amount of bugs in this code here. It also never worked
for containers with user namespaces. So once and for all simplify this
by never reusing the netns. Originally this was done to have a faster
restart of containers but with netavark now we are much faster so it
shouldn't be that noticeable in practice. It also makes more sense to
reconfigure the netns as it is likely that the container exited due
some broken network state in which case reusing would just cause more
harm than good.
The main motivation for this change was the pasta change to use
--dns-forward by default. As the restarted contianer had no idea what
nameserver to use as pasta just kept running.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
By default we just ignored any localhost reolvers, this is problematic
for anyone with more complicated dns setups, i.e. split dns with
systemd-reolved. To address this we now make use of the build in dns
proxy in pasta. As such we need to set the default nameserver ip now.
A second change is the option to exclude certain ips when generating the
host.containers.internal ip. With that we no longer set it to the same
ip as is used in the netns. The fix is not perfect as it could mean on a
system with a single ip we no longer add the entry, however given the
previous entry was incorrect anyway this seems like the better behavior.
Fixes#22044
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
do not generate a duplicated range when --userns=keep-id:uid=0 or
--userns=keep-id:gid=0 are used.
Closes: https://github.com/containers/podman/issues/22078
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Bump to the version of Buidah in it's main branch to get the
CVE-2024-1753 fix.
[NO NEW TESTS NEEDED]
Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
Belated followup to #21981. (Looks like I started to add this
functionality back in 2020 but left it unfinished. Tsk tsk.)
docs/source/Commands.rst is unnecessary duplication. It _should_
be autogenerated, but I can't figure out how to cleanly add
that to our Make process. This PR is an interim cross-check
until we get that resolved:
- everything in podman --help must have a matching entry
in Commands.rst (top-level commands only)
- check for dups and out-of-sequence in Commands.rst
- also for anything in Commands.rst that is not in --help
Fix existing mismatches in Commands.rst.
Also, #21784 removed a format specifier that I was using in
regression tests. Switch to using something else, to get
test passing again. Given the fact the correct solution
is autogenerating Commands.rst, I choose not to add new
tests for the rst xref.
Also, executive decision, remove volume.rst. It is not referenced
from anywhere, it looks like a lonely orphan remnant from days
of yore.
Signed-off-by: Ed Santiago <santiago@redhat.com>
In some environments, such as the one described in
https://github.com/containers/podman/issues/20927, the default route
is given as nexthop gateways. That is, it's a multipath routes with
multiple gateways.
That means that pasta(1), after commit 6c7623d07bbd ("netlink: Add
support to fetch default gateway from multipath routes"), can start
and use a default gateway from that route.
Just like in pasta(1), in these tests, the default route indicates
which upstream interface we should pick. If we ignore multipath
routes, IPv6 addresses and gateway addresses themselves won't be
available, so, while pasta is now able to configure the container,
IPv6 tests will expect to find no address and no gateway, hence fail
due to the mismatch.
Try to get routes, including gateway addresses and interface names,
from nexthop objects, in case the selection of a regular default
route yields no results.
Link: https://github.com/containers/podman/issues/20927Closes: #20927
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
This removes the need for any `Provides: bundled()` we needed in spec
files.
The updated Provides will be visible in the build logs and can also be
verified with `rpm -q --provides $RPM_FILE`.
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>