Don't need this email as we have podman-monitor email listed wherever
relevant.
[NO NEW TESTS NEEDED]
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
Small fixes for bugs in the hyperv code that were made obvious when
manually preparing to run pkg/machine/e2e with windows and hyperv.
Also includes vendoring a new libhvee and solves bug where json config
was not being removed.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
Fix unquoted string vars. Something like this:
is $output "what we expect"
...will fail with a misleading error message if $output is "".
Also fix typos in a diagnostic; this was causing unhelpful message
on failure
Signed-off-by: Ed Santiago <santiago@redhat.com>
A nearly-trivial first effort to use the new ExitCleanly().
Requires using the new CITEST_IMAGE (see prior commit)
because nginx causes the tests to fail:
[FAILED] Unexpected warnings seen on stderr: \
level=warning \
msg="HEALTHCHECK is not supported for OCI image format ...
Oh, I also took the liberty of rewriting "play kube" -> "kube play".
Signed-off-by: Ed Santiago <santiago@redhat.com>
Combined test for (exitcode == 0) && (nothing on stderr).
Returns more useful diagnostic messages than the default:
old: Expected N to equal 0
new: Command failed with exit status N
new: Unexpected warnings seen on stderr: "...."
Signed-off-by: Ed Santiago <santiago@redhat.com>
Finally, after so many years, let's start using testimage:YYYYMMDD.
Use it in place of LABELS_IMAGE, which nothing/nowhere was using.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Use the `newer` pull policy only for the "latest" tag and default to
using `missing` otherwise. This speeds up `kube play` as it'll skip
reaching out to the registry and also fixes other side-effects described
in #19801.
Fixes: #19801
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Since we do not want the mapping to be applied to uids,
we should use the `g` flag in the mapping in the example
as well.
Follow up of #18173
Signed-off-by: Sergio Oller <sergioller@gmail.com>
When pulling from an OCI source, make sure to preseve the optional name.
For instance, a podman pull oci:/tmp/foo:quay.io/foo/bar:latest should
pull the image and name it quay.io/foo/bar:latest.
While at it, also fix a bug when pulling an OCI without the optional
name. Previously, we used the path to name the image which will error in
most cases due to invalid characters (e.g., capital ones). Hence, apply
the same trick as for the dir transport and generate a sha.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Use `add_compression` field from `containers.conf` if found instead and
`CLI` field `--add-compression` is not set.
Signed-off-by: Aditya R <arajan@redhat.com>
in gvisor-vsock-tap upstream, there is a binary called 'vm' which is
used for routing traffic from a tap over something like vsock. In
Fedora, the binary is named 'gvforwarder'.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
the remote username was being set too "late" for hyperv and the username
for ssh connections was blank.
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
... by updating for a c/common API change.
[NO NEW TESTS NEEDED]: Only moves unchanged code,
should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In `pkg/bindings/containers/ResizeExecTTY`, `sessionID` is the actual required
parameter, instead of `nameOrId`.
[NO NEW TESTS NEEDED]
Signed-off-by: Yiliang Yang <yangyiliang@gmail.com>
pkg/api/handlers is used for type definitions by pkg/bindings,
i.e. podman-remote; a libimage dependency means that podman-remote
would also include libimage.
Instead, move the ImageDataToImageInspect function close to the
only user (and make it private).
[NO NEW TESTS NEEDED]: Only moves unchanged code (apart from a required
warning fix), should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
getImageFromSpec has just make exactly the same Inspect call.
[NO NEW TESTS NEEDED]: This adds no new functionality, and
it's hard to test that a duplicate call didn't happen without
(intrusive and hard-to-maintain) mocks.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
These jobs have been failing since early August due to
technical/scripting problems. Disable/remove entirely since a fix is
unlikely to be implemented anytime soon.
Ref: Abandoned recent attempt at debugging
https://github.com/containers/podman/pull/19720
Signed-off-by: Chris Evich <cevich@redhat.com>
Motivation
===========
This feature aims to make --uidmap and --gidmap easier to use, especially in rootless podman setups.
(I will focus here on the --gidmap option, although the same applies for --uidmap.)
In rootless podman, the user namespace mapping happens in two steps, through an intermediate mapping.
See https://docs.podman.io/en/latest/markdown/podman-run.1.html#uidmap-container-uid-from-uid-amount
for further detail, here is a summary:
First the user GID is mapped to 0 (root), and all subordinate GIDs (defined at /etc/subgid, and
usually >100000) are mapped starting at 1.
One way to customize the mapping is through the `--gidmap` option, that maps that intermediate mapping
to the final mapping that will be seen by the container.
As an example, let's say we have as main GID the group 1000, and we also belong to the additional GID 2000,
that we want to make accessible inside the container.
We first ask the sysadmin to subordinate the group to us, by adding "$user:2000:1" to /etc/subgid.
Then we need to use --gidmap to specify that we want to map GID 2000 into some GID inside the container.
And here is the first trouble:
Since the --gidmap option operates on the intermediate mapping, we first need to figure out where has
podman placed our GID 2000 in that intermediate mapping using:
podman unshare cat /proc/self/gid_map
Then, we may see that GID 2000 was mapped to intermediate GID 5. So our --gidmap option should include:
--gidmap 20000:5:1
This intermediate mapping may change in the future if further groups are subordinated to us (or we stop
having its subordination), so we are forced to verify the mapping with
`podman unshare cat /proc/self/gid_map` every time, and parse it if we want to script it.
**The first usability improvement** we agreed on #18333 is to be able to use:
--gidmap 20000:@2000:1
so podman does this lookup in the parent user namespace for us.
But this is only part of the problem. We must specify a **full** gidmap and not only what we want:
--gidmap 0:0:5 --gidmap 5:6:15000 --gidmap 20000:5:1
This is becoming complicated. We had to break the gidmap at 5, because the intermediate 5 had to
be mapped to another value (20000), and then we had to keep mapping all other subordinate ids... up to
close to the maximum number of subordinate ids that we have (or some reasonable value). This is hard
to explain to someone who does not understand how the mappings work internally.
To simplify this, **the second usability improvement** is to be able to use:
--gidmap "+20000:@2000:1"
where the plus flag (`+`) states that the given mapping should extend any previous/default mapping,
overriding any previous conflicting assignment.
Podman will set that mapping and fill the rest of mapped gids with all other subordinated gids, leading
to the same (or an equivalent) full gidmap that we were specifying before.
One final usability improvement related to this is the following:
By default, when podman gets a --gidmap argument but not a --uidmap argument, it copies the mapping.
This is convenient in many scenarios, since usually subordinated uids and gids are assigned in chunks
simultaneously, and the subordinated IDs in /etc/subuid and /etc/subgid for a given user match.
For scenarios with additional subordinated GIDs, this map copying is annoying, since it forces the user
to provide a --uidmap, to prevent the copy from being made. This means, that when the user wants:
--gidmap 0:0:5 --gidmap 5:6:15000 --gidmap 20000:5:1
The user has to include a uidmap as well:
--gidmap 0:0:5 --gidmap 5:6:15000 --gidmap 20000:5:1 --uidmap 0:0:65000
making everything even harder to understand without proper context.
For this reason, besides the "+" flag, we introduce the "u" and "g" flags. Those flags applied to a
mapping tell podman that the mapping should only apply to users or groups, and ignored otherwise.
Therefore we can use:
--gidmap "+g20000:@2000:1"
So the mapping only applies to groups and is ignored for uidmaps. If no "u" nor "g" flag is assigned
podman assumes the mapping applies to both users and groups as before, so we preserve backwards compatibility.
Co-authored-by: Tom Sweeney <tsweeney@redhat.com>
Signed-off-by: Sergio Oller <sergioller@gmail.com>
Specify that by default if only one of uidmap or gidmap is given, the other one is copied
Co-authored-by: Tom Sweeney <tsweeney@redhat.com>
Signed-off-by: Sergio Oller <sergioller@gmail.com>
this version of libhvee contains fixes related to machine stop required
for windows hyperv
[NO NEW TESTS NEEDED]
Signed-off-by: Brent Baude <bbaude@redhat.com>
