Allow podman network reload to be run as rootless user. While it is
unlikely that the iptable rules are flushed inside the rootless cni
namespace, it could still happen. Also fix podman network reload --all
to ignore errors when a container does not have the bridge network mode,
e.g. slirp4netns.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
The source ip for the rootlesskit port forwarder was hardcoded to the
standard slirp4netns ip. This is incorrect since users can change the
subnet used by slirp4netns with `--network slirp4netns:cidr=10.5.0.0/24`.
The container interface ip is always the .100 in the subnet. Only when
the rootlesskit port forwarder child ip matches the container interface
ip the port forwarding will work.
Fixes#9828
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Add a new --rootless-cni option to podman unshare to also join the
rootless-cni network namespace. This is useful if you want to connect
to a rootless container via IP address. This is only possible from the
rootless-cni namespace and not from the host namespace. This option also
helps to debug problems in the rootless-cni namespace.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
The CNI plugins need access to iptables in $PATH. On debian /usr/sbin
is not added to $PATH for rootless users. This will break rootless
cni completely. To prevent breaking existing users add /usr/sbin to
$PATH in podman if needed.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
If a user only has a local dns server in the resolv.conf file the dns
resolution will fail. Instead we create a new resolv.conf which will use
the slirp4netns dns.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
With the new rootless cni supporting network connect/disconnect is easy.
Combine common setps into extra functions to prevent code duplication.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Instead of creating an extra container create a network and mount
namespace inside the podman user namespace. This ns is used to
for rootless cni operations.
This helps to align the rootless and rootful network code path.
If we run as rootless we just have to set up a extra net ns and
initialize slirp4netns in it. The ocicni lib will be called in
that net ns.
This design allows allows easier maintenance, no extra container
with pause processes, support for rootless cni with --uidmap
and possibly more.
The biggest problem is backwards compatibility. I don't think
live migration can be possible. If the user reboots or restart
all cni containers everything should work as expected again.
The user is left with the rootless-cni-infa container and image
but this can safely be removed.
To make the existing cni configs work we need execute the cni plugins
in a extra mount namespace. This ensures that we can safely mount over
/run and /var which have to be writeable for the cni plugins without
removing access to these files by the main podman process. One caveat
is that we need to keep the netns files at `XDG_RUNTIME_DIR/netns`
accessible.
`XDG_RUNTIME_DIR/rootless-cni/{run,var}` will be mounted to `/{run,var}`.
To ensure that we keep the netns directory we bind mount this relative
to the new root location, e.g. XDG_RUNTIME_DIR/rootless-cni/run/user/1000/netns
before we mount the run directory. The run directory is mounted recursive,
this makes the netns directory at the same path accessible as before.
This also allows iptables-legacy to work because /run/xtables.lock is
now writeable.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Make sure we do not display the expected error when using podman network
reload. This is already done for iptables-legacy however iptables-nft
creates a slightly different error message so check for this as well.
The error is logged at info level.
[NO TESTS NEEDED] The test VMs do not use iptables-nft so there is no
way to test this. It is already tested for iptables-legacy.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Make sure to pass the cni interface descriptions to cni teardowns.
Otherwise cni cannot find the correct cache files because the
interface name might not match the networks. This can only happen
when network disconnect was used.
Fixes#9602
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Only the the network mode bridge supports cni networks.
Other network modes cannot use network connect/disconnect
so we should throw a error.
Fixes#9496
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
The libpod network logic knows about networks IDs but OCICNI
does not. We cannot pass the network ID to OCICNI. Instead we
need to make sure we only use network names internally. This
is also important for libpod since we also only store the
network names in the state. If we would add a ID there the
same networks could accidentally be added twice.
Fixes#9451
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
We missed bumping the go module, so let's do it now :)
* Automated go code with github.com/sirkon/go-imports-rename
* Manually via `vgrep podman/v2` the rest
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The allocated `tmpNetworkStatus` must be allocated with the length 0.
Otherwise append would add new elements to the end of the slice and
not at the beginning of the allocated memory.
This caused inspect to fail since the number of networks did not
matched the number of network statuses.
Fixes#9234
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
The mtu default value is currently forced to 65520.
This let the user control it using the config key network_cmd_options,
i.e.: network_cmd_options=["mtu=9000"]
Signed-off-by: bitstrings <pino.silvaggio@gmail.com>
when inspecting a container that is only connected to the default
network, we should populate the default network in the container inspect
information.
Fixes: #6618
Signed-off-by: baude <bbaude@redhat.com>
MH: Small fixes, added another test
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
if a CNI network is added to the container, use the IP address in that
network instead of hard-coding the slirp4netns default.
commit 5e65f0ba30f3fca73f8c207825632afef08378c1 introduced this
regression.
Closes: https://github.com/containers/podman/issues/9065
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when
using rootlesskit.
Closes: https://github.com/containers/podman/issues/5138
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Systemd is now complaining or mentioning /var/run as a legacy directory.
It has been many years where /var/run is a symlink to /run on all
most distributions, make the change to the default.
Partial fix for https://github.com/containers/podman/issues/8369
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Just checking for `rootless.IsRootless()` does not catch all the
cases where slirp4netns is in use - we actually allow it to be
used as root as well. Fortify the conditional here so we don't
fail in the root + slirp case.
Fixes#7883
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
This adds a new command, 'podman network reload', to reload the
networks of existing containers, forcing recreation of firewall
rules after e.g. `firewall-cmd --reload` wipes them out.
Under the hood, this works by calling CNI to tear down the
existing network, then recreate it using identical settings. We
request that CNI preserve the old IP and MAC address in most
cases (where the container only had 1 IP/MAC), but there will be
some downtime inherent to the teardown/bring-up approach. The
architecture of CNI doesn't really make doing this without
downtime easy (or maybe even possible...).
At present, this only works for root Podman, and only locally.
I don't think there is much of a point to adding remote support
(this is very much a local debugging command), but I think adding
rootless support (to kill/recreate slirp4netns) could be
valuable.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
a bug was being caused by the fact that the container network results
were not being updated properly.
given that jhon is on PTO, this PR will replace #8362
Signed-off-by: baude <bbaude@redhat.com>
* Make endpoint compatibile with docker-py network expectations
* Update specgen helper when called from compat endpoint
* Update godoc on types
* Add test for network/container create using docker-py method
* Add syslog logging when DEBUG=1 for tests
Fixes#8361
Signed-off-by: Jhon Honce <jhonce@redhat.com>
This makes things a lot more clear - if we are actually joining a
CNI network, we are guaranteed to get a non-zero length list of
networks.
We do, however, need to know if the network we are joining is the
default network for inspecting containers as it determines how we
populate the response struct. To handle this, add a bool to
indicate that the network listed was the default network, and
only the default network.
Signed-off-by: Matthew Heon <mheon@redhat.com>
this enables the ability to connect and disconnect a container from a
given network. it is only for the compatibility layer. some code had to
be refactored to avoid circular imports.
additionally, tests are being deferred temporarily due to some
incompatibility/bug in either docker-py or our stack.
Signed-off-by: baude <bbaude@redhat.com>
this enables the ability to connect and disconnect a container from a
given network. it is only for the compatibility layer. some code had to
be refactored to avoid circular imports.
additionally, tests are being deferred temporarily due to some
incompatibility/bug in either docker-py or our stack.
Signed-off-by: baude <bbaude@redhat.com>
Convert the existing network aliases set/remove code to network
connect and disconnect. We can no longer modify aliases for an
existing network, but we can add and remove entire networks. As
part of this, we need to add a new function to retrieve current
aliases the container is connected to (we had a table for this
as of the first aliases PR, but it was not externally exposed).
At the same time, remove all deconflicting logic for aliases.
Docker does absolutely no checks of this nature, and allows two
containers to have the same aliases, aliases that conflict with
container names, etc - it's just left to DNS to return all the
IP addresses, and presumably we round-robin from there? Most
tests for the existing code had to be removed because of this.
Convert all uses of the old container config.Networks field,
which previously included all networks in the container, to use
the new DB table. This ensures we actually get an up-to-date list
of in-use networks. Also, add network aliases to the output of
`podman inspect`.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The error message reported is overlay complicated and the added test does not
really help the user.
Currently the error looks like:
podman run -p 80:80 fedora echo hello
Error: failed to expose ports via rootlessport: "cannot expose privileged port 80, you might need to add "net.ipv4.ip_unprivileged_port_start=0" (currently 1024) to /etc/sysctl.conf, or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied\n"
After this change
./bin/podman run -p 80:80 fedora echo hello
Error: cannot expose privileged port 80, you might need to add "net.ipv4.ip_unprivileged_port_start=0" (currently 1024) to /etc/sysctl.conf, or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied
Control chars have been eliminated.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
podman can now support adding network aliases when running containers
(--network-alias). It requires an updated dnsname plugin as well as an
updated ocicni to work properly.
Signed-off-by: baude <bbaude@redhat.com>
When creating a container in a pod the podname was always set as
the dns entry. This is incorrect when the container is not part
of the pods network namespace. This happend both rootful and
rootless. To fix this check if we are part of the pods network
namespace and if not use the container name as dns entry.
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
When a container either joins a pod that shares the network
namespace or uses `--net=container:` to share the network
namespace of another container, it does not have its own copy of
the CNI results used to generate `podman inspect` output. As
such, to inspect these containers, we should be going to the
container we share the namespace with for network info.
Fixes#8073
Signed-off-by: Matthew Heon <mheon@redhat.com>
After seeing #7759, I decided to look at the calls in
Podman and Buildah to see if we had issues with strings.Split()
calls where an "=" (equals) sign was in play and we expected
to split on only the first one.
There were only one or two that I found in here that I think
might have been troubling, the remainder are just adding
some extra safety.
I also had another half dozen or so that were checking length
expectations appropriately, those I left alone.
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
We were only including the CNI Network fields in the output of
`podman inspect` when the container was not running. It's simple
enough to fix (populate with empty structs, since we can't fill
anything without a CNI response to get IP address assigned, etc).
This is necessary for Docker compatibility.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
In case os.Open[File], os.Mkdir[All], ioutil.ReadFile and the like
fails, the error message already contains the file name and the
operation that fails, so there is no need to wrap the error with
something like "open %s failed".
While at it
- replace a few places with os.Open, ioutil.ReadAll with
ioutil.ReadFile.
- replace errors.Wrapf with errors.Wrap for cases where there
are no %-style arguments.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Usage:
```
$ podman network create foo
$ podman run -d --name web --hostname web --network foo nginx:alpine
$ podman run --rm --network foo alpine wget -O - http://web.dns.podman
Connecting to web.dns.podman (10.88.4.6:80)
...
<h1>Welcome to nginx!</h1>
...
```
See contrib/rootless-cni-infra for the design.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This adds support for the --cidr parameter that is supported
by slirp4netns since v0.3.0. This allows the user to change
the ip range that is used for the network inside the container.
Signed-off-by: Adis Hamzić <adis@hamzadis.com>
