Fixes: https://github.com/containers/podman/issues/25002
Also add the ability to inspect containers for
UseImageHosts and UseImageHostname.
Finally fixed some bugs in handling of --no-hosts for Pods,
which I descovered.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
This significantly simplifies the ceromony of running a Podman command
in integration tests, from
> session := p.Podman([]string{"stop", id})
> session.WaitWithDefaultTimeout()
> Expect(session).Should(ExitCleanly())
to
> p.PodmanExitCleanly("stop", id)
There are >4650 instances of ExitCleanly() in the tests,
and many could be migrated; this does not do that.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Introduce a new option "size" to configure the maximum size of the
user namespace configured by keep-id.
Closes: https://github.com/containers/podman/issues/24837
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Passing the hostname allows netavark to include it in DHCP lease
requests which, in an environment where DDNS is used, can cause
DNS entries to be created automatically.
* The current Hostname() function in container.go was updated to
check the new `container_name_as_hostname` option in the
CONTAINERS table of containers.conf. If set and no hostname
was configured for the container, it causes the hostname to be
set to a version of the container's name with the characters not
valid for a hostname removed. If not set (the default), the original
behavior of setting the hostname to the short container ID is
preserved.
* Because the Hostname() function can return the host's hostname
if the container isn't running in a private UTS namespace, and we'd
NEVER want to send _that_ in a DHCP request for a container, a new
function NetworkHostname() was added which functions like Hostname()
except that it will return an empty string instead of the host's
hostname if the container is not running in a private UTS namespace.
* networking_common.getNetworkOptions() now uses NetworkHostname()
to set the ContainerHostname member of the NetworkOptions structure.
That member was added to the structure in a corresponding commit in
common/libnetwork/types/network.go.
* Added test to containers_conf_test.go
Signed-off-by: George Joseph <g.devel@wxy78.net>
If the source dir is owned by another user then the test the chown will
fail assuming we run the tests rootless. This function is only used by
the quadlet tests and for the purpose all we need is to read the files
so the simple fix is remove the chown as this should make the tests pass
on the special debian gating env.
Fixes#24802
Signed-off-by: Paul Holzinger <git@holzinger.dev>
This test a pretty much useless, it checks that a connection attempt on
the default socket fails. But this is incorrect as the socket is outside
of the test control as such it might be ready to accept connections as
thus the test can fail locally or as reported here in the debian tests.
Given that a simple connection fails does not add any value I opted to
remove it.
Fixes#24803
Signed-off-by: Paul Holzinger <git@holzinger.dev>
This commit simplifies the systemd parser logic, and it solves an
infinite loop when using a continuation line.
Closes: https://github.com/containers/podman/issues/24810
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
When the --index flag is used, `manifest annotate` shouldn't be
expecting a second non-flag argument.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
This highlights a bug in common where the compression format is reset if the format is v2s2, even if its a valid compression format.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
This solves several problems with copying into volumes on a
container that is not running.
The first, and most obvious, is that we were previously entirely
unable to copy into a volume that required mounting - like
image volumes, volume plugins, and volumes that specified mount
options.
The second is that this fixed several permissions and content
issues with a fresh volume and a container that has not been run
before. A copy-up will not have occurred, so permissions on the
volume root will not have been set and content will not have been
copied into the volume.
If the container is running, this is very low cost - we maintain
a mount counter for named volumes, so it's just an increment in
the DB if the volume actually needs mounting, and a no-op if it
doesn't.
Unfortunately, we also have to fix permissions, and that is
rather more complicated. This involves an ugly set of manual
edits to the volume state to ensure that the permissions fixes
actually worked, as the code was never meant to be used in this
way. It's really ugly, but necessary to reach full Docker
compatibility.
Fixes#24405
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
* Add --hosts-file flag to container create, container run and pod create
* Add HostsFile field to pod inspect and container inspect results
* Test BaseHostsFile config in containers.conf
Signed-off-by: Gavin Lam <gavin.oss@tutamail.com>
This matches the behavior of other volume and mount types. Image
volumes and volumes/mounts from the `--volumes-from` flag should
be overridden by actual user-specified named volumes and mounts,
but this was not true for overlay mounts. Fortunately, our
duplicate-mount detection logic still works, so we got a good
error message at least.
The fix is simple - extend our supersede logic, which currently
only works with named volumes and mounts, to also work with
overlay mounts.
Fixes#24555
Signed-off-by: Matt Heon <mheon@redhat.com>
This way has a huge disadvantage: The user will not see an error when he
uses a non-existent option. Another disadvantage is, that if we add more
options within podman, they might collide with the names chosen by
plugins. Such issues might be hard to debug.
The advantage is that the usage is very nice:
--network bridge:opt1=val1,opt2=val2.
Alternatively, we could put this behind `opt=`, which is harder to use,
but would solve all issues above:
--network bridge:opt=opt1=val1,opt=opt2=val2
Signed-off-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
All the backend work was done a while back for image volumes, so
this is effectively just plumbing the option in for volumes in
the parser logic. We do need to change the return type of the
volume parser as it only worked on spec.Mount before (which does
not have subpath support, so we'd have to pass it as an option
and parse it again) but that is cleaner than the alternative.
Fixes#20661
Signed-off-by: Matt Heon <mheon@redhat.com>
First, creating a global file /etc/system-fips was never a good idea for
testing as it affects other running tests at the same time.
And as of a recent change to FIPS mounts[1] we no longer use the file so
the test breaks with c/common v0.61. Instead it uses the kernel file
/proc/sys/crypto/fips_enabled which requires the real fips mode to be
activated and that in turn requires a reboot. As such this is not
somthing that can be tested in upstream CI like that.
[1] https://github.com/containers/common/pull/2174
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
- fix issues found by recvcheck
- skip k8s files from recvcheck
- remove two removed linters gomnd and execinquery
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
These tests verify that podman successfully adds (or
fails to add) a connection to an SSH server based on
the entries in the `~/.ssh/known_hosts` file.
In particular `system connection add` should succeed if:
- there is no `know_hosts` file
- `known_hosts` has an entry that matches the first protocol/key returned
by the SSH server
- `known_hosts` has an entry that matches the first protocol/key returned
by the SSH server
- `known_hosts` has an entry for another SSH server, not for the target server
It should fail if the `known_host` file has an entry for
the target server that matches the protocol but not the key.
Depends on containers/common#2212
Fixes#23575
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
This commit resolves an issue where network creation and removal events were not being logged in `podman events`. A new function has been introduced in the `events` package to ensure consistent logging of network lifecycle events. This update will allow users to track network operations more effectively through the event log, improving visibility and aiding in debugging network-related issues.
Fixes: #24032
Signed-off-by: Sainath Sativar <Sativar.sainath@gmail.com>
By default today, the container is always started if its pod is also
started. This prevents to create custom with systemd where containers in
a pod could be started through their `[Install]` section.
We add a key `StartWithPod=`, enabled by default, that enables one to
disable that behavior.
This prevents the pod service from changing the state of the container
service.
Fixes#24401
Signed-off-by: Farya L. Maerten <me@ltow.me>
This fixes two problems, first if a port is published and exposed it
should not be shown twice. It is enough to show the published one.
Second, if there is a huge range the ports were no grouped causing the
output to be unreadable basically. Now we group exposed ports like we do
with the normal published ports.
Fixes#23317
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
There is no good reason for the special case, kube and pod units
definitely need it. Volume and network units maybe not but for
consistency we add it there as well. This makes the docs much easier to
write and understand for users as the behavior will not differ.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
As documented in the issue there is no way to wait for system units from
the user session[1]. This causes problems for rootless quadlet units as
they might be started before the network is fully up. TWhile this was
always the case and thus was never really noticed the main thing that
trigger a bunch of errors was the switch to pasta.
Pasta requires the network to be fully up in order to correctly select
the right "template" interface based on the routes. If it cannot find a
suitable interface it just fails and we cannot start the container
understandingly leading to a lot of frustration from users.
As there is no sign of any movement on the systemd issue we work around
here by using our own user unit that check if the system session
network-online.target it ready.
Now for testing it is a bit complicated. While we do now correctly test
the root and rootless generator since commit ada75c0bb8 the resulting
Wants/After= lines differ between them and there is no logic in the
testfiles themself to say if root/rootless to match specifics. One idea
was to use `assert-key-is-rootless/root` but that seemed like more
duplication for little reason so use a regex and allow both to make it
pass always. To still have some test coverage add a check in the system
test to ask systemd if we did indeed have the right depdendencies where
we can check for exact root/rootless name match.
[1] https://github.com/systemd/systemd/issues/3312Fixes#22197
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
