As of podman 1.8.0, because of commit da7595a, the default approach of providing
port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport,
for the purpose of providing super performance. The side-effect of this switch is
source within the container to the port-forwarded service always appears to originate
from 127.0.0.1 (see issue #5138).
This commit allows a user to specify if they want to revert to the previous approach
of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance,
restores usefulness of seeing incoming traffic origin IP addresses.
The change should be transparent; when not specified, rootlessport will continue to be
used, however if specifying --net slirp4netns:slirplisten the old approach will be used.
Note: the above may imply the restored port-forwarding via slirp4netns is not as
performant as the new rootlessport approach, however the figures shared in the original
commit that introduced rootlessport are as follows:
slirp4netns: 8.3 Gbps,
RootlessKit: 27.3 Gbps,
which are more than sufficient for many use cases where the origin of traffic is more
important than limits that cannot be reached due to bottlenecks elsewhere.
Signed-off-by: Aleks Mariusz <m.k@alek.cx>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This allows us to determine if the container auto-detected that
systemd was in use, and correctly activated systemd integration.
Use this to wire up some integration tests to verify that systemd
integration is working properly.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We were only using the Command field in specgen when determining
whether to enable systemd if systemd=true (the default) was used.
This does not include the entrypoint, and does not include any
entrypoint/command sourced from the image - so an image could be
running systemd and we'd not correctly detect this. Using the
full, final command resolves this and matches Podman v1.9.x
behavior.
Fixes#6920
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
fedora removed the systemd package from its standard container image causing our systemd pid1 test to fail. Replacing usage of fedora to ubi-init.
adding ubi images to the cache for local tests.
also, remove installation of test/policy.json to the system wide /etc/containers
Signed-off-by: Brent Baude <bbaude@redhat.com>
Some time ago, we moved the Seccomp policy (and related setup
code) to a place where all our tools could share it [1]. We did
not, however, remove the in-repo seccomp.json file. Over the last
year or so, the in-repo seccomp policy has become progressively
more and more outdated, with no effort made to maintain it
(because what sense is there in keeping a duplicate?). Today, a
friend came to me and asked if a Podman container could access
keyctl, assuming it could not because he was reading the outdated
Seccomp policy which does not allow it. Since it's becoming clear
that this file is doing no good and actively causing confusion,
let's just drop it.
[1] https://github.com/seccomp/containers-golang
Signed-off-by: Matthew Heon <mheon@redhat.com>
I confused STDIN and STDOUT's file descriptors (it's 0 and 1, I
thought they were 1 and 0). As such, we were looking at whether
we wanted to print STDIN when we looked to print STDOUT. This
bool was set when `-i` was set in at the `podman exec` command
line, which masked the problem when it was set.
Fixes#6890Fixes#6891Fixes#6892
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Currently we are sending over pids-limits from the user even if they
never modified the defaults. The pids limit should be set at the server
side unless modified by the user.
This issue has led to failures on systems that were running with cgroups V1.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We properly determined what sig-proxy should be set to, but we
never passed that along to the backend. As such, cases where the
default swapped (mostly when `--attach` was specified but the
`--sig-proxy` flag was not) were not handled correctly
Fixes#6928
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
In `podman inspect` output for containers and pods, we include
the command that was used to create the container. This is also
used by `podman generate systemd --new` to generate unit files.
With remote podman, the generated create commands were incorrect
since we sourced directly from os.Args on the server side, which
was guaranteed to be `podman system service` (or some variant
thereof). The solution is to pass the command along in the
Specgen or PodSpecgen, where we can source it from the client's
os.Args.
This will still be VERY iffy for mixed local/remote use (doing a
`podman --remote run ...` on a remote client then a
`podman generate systemd --new` on the server on the same
container will not work, because the `--remote` flag will slip
in) but at the very least the output of `podman inspect` will be
correct. We can look into properly handling `--remote` (parsing
it out would be a little iffy) in a future PR.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Allow more variants to yield json output for `podman version` and
`podman info`. Instead of comparing strings, use a regex and add
unit and e2e tests.
Fixes: #6927
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
This patch fixes connection counters for v2 endpoints
Idletracker was moved to a new package to prevent package cycle.
Hijacking code still remains in wrong place and should be moved
later to isolated package
Signed-off-by: Sami Korhonen <skorhone@gmail.com>
After this patch v2 hijacking endpoints, exec/start and
containers/attach follow rfc 7230 specification.
Connection will only be upgraded, if client specifies upgrade
headers:
For tcp connections:
Connection: Upgrade
Upgrade: tcp
For unix socket connections:
Connection: Upgrade
Upgrade: sock
There are currently no checks if upgrade type actually matches with
available protocols. Implementation just protocol that client
requested
Signed-off-by: Sami Korhonen <skorhone@gmail.com>
StateHijacked is a terminal state. If hijacked connection
is registered as an active connection, connection will
never be unregistered. This causes two issues
First issue is that active connection counters are off.
Second issue is a resource leak caused by connection
object that is stored to a map.
After this patch hijacked connections are no longer
visible in counters. If a counter for hijacked
connections is required, podman must track
connections returned by Hijacker.Hijack()
It might make sense to develop abstraction layer for
hijacking - and move all hijacking related code to a
separate package. Hijacking code is prone to resource
leaks and it should be thoroughly tested.
Signed-off-by: Sami Korhonen <skorhone@gmail.com>
This was inspired by https://github.com/cri-o/cri-o/pull/3934 and
much of the logic for it is contained there. However, in brief,
a named return called "err" can cause lots of code confusion and
encourages using the wrong err variable in defer statements,
which can make them work incorrectly. Using a separate name which
is not used elsewhere makes it very clear what the defer should
be doing.
As part of this, remove a large number of named returns that were
not used anywhere. Most of them were once needed, but are no
longer necessary after previous refactors (but were accidentally
retained).
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We are using these dependencies just to get the device from path.
These dependencies no longer build on Windows, so simply cloning
the deviceFromPath function, we can eliminate the need for this
vendoring.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Add a `context.Context` to the log APIs to allow for cancelling
streaming (e.g., via `podman logs -f`). This fixes issues for
the remote API where some go routines of the server will continue
writing and produce nothing but heat and waste CPU cycles.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
- fix saving&loading oci format. Close#6544
- support loading using image name without "localhost/" prefix when reading from ociarchive/dir saved from this semantics
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Signed-off-by: Qi Wang <qiwan@redhat.com>
