This is gated behind a new option in `podman system migrate`,
`--migrate-db`, or by a system restart being performed.
BoltDB support was removed in Podman 6, so we are certain that,
when we start Podman, a SQLite state is in use. However, if we
also detect a valid BoltDB state, we will attempt a migration.
Migration is performed by retrieving all volumes, pods, and
containers (in that order, to ensure there are no dependency
conflicts) from the Bolt database, when adding them to the SQLite
database. If there is a conflict - IE, a container exists in both
SQLite and Bolt - we skip migration for that object. The old DB
is then renamed so we do not try to migrate it again.
Our ability to test complex migration scenarios is limited, but
this should handle simple migrations easily.
This is a heavily adapted version of #27660 rebuilt to work with
Podman 6.0. Substantial changes were required to throw errors
when a BoltDB database is detected and no migration is being
performed. Firstly, for automatic on-reboot migrations, we need
to have a deferred error returned by getDBState (very early in
runtime initialization) that is only acted on much later (once we
know for certain a state refresh is/is not being performed).
The `system migrate --migrate-db` command was much more
problematic. Conceptually, it's not terrible - add a flag to the
runtime to suppress errors, set that flag only when calling the
`system migrate` command with `--migrate-db` - but it unveiled a
serious problem with how we do runtime init (special flags to the
runtime were being ignored because the image runtime set the
Libpod runtime first and had none of the proper handling) which
took a genuinely annoying amount of time to identify and fix.
This cannot be tested automatically, as the ability to create Bolt
databases has been entirely removed with Podman 6.
This also includes 9b810aed3a from
the v5.8 branch by Luap99, which I have had to squash into this
commit to satisfy the build-each-commit check. It was just a
simplification of the SQLite path check.
Signed-off-by: Matt Heon <matthew.heon@pm.me>
Podman defaults to the directory of the Containerfile when no context dir is explicitly provided.
When running podman build with process subsituiton, `podman build -f <(echo "FROM scratch")`,
the Containerfile path expands to `/dev/fd/<NUM>`, which makes `/dev/fd` the context dir.
When building, Buildah attempts to create an overlay mount on top of the `/dev/fd` context dir, which fails.
In these cases, use a temp context dir instead: `$TMPDIR/podman-build-context-$randnum`
Fixes: https://github.com/containers/podman/issues/28113
Signed-off-by: Ashley Cui <acui@redhat.com>
Update build.sh to run gofumpt on generated .pb.go files, and apply
formatting to existing generated files. This fixes gofumpt and inamedparam
lint errors on macOS CI and ensures future regenerations will be
automatically formatted.
Signed-off-by: Lokesh Mandvekar <lsm5@linux.com>
The config.go file has a build tag that was never used. Also remove
unused functions from other files.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Avoid reading /proc/filesystems on every container creation when
running as a service by caching the result.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Introducing a new `podmand system` subcommand to prepare a Windows host
to run Hyper-V based Podman machines: `hyperv-prep`.
When executed it:
- creates of the registry keys for VSocks
- adds the current user to the Hyper-V administrators group
This command requires an administrator terminal.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Hyper-V VMs require some specific Windows registry keys to allow the
communication between the host and the guest. Creating these registry
keys require elevated privileges.
These keys were created during the first Podman `machine init` and
removed when the last Podman machine is removed.
In this commit we skip the creation of the keys if they already exist in
the registry. So that admin privileges aren't required anymore, even for
the creation of the first Podman machine.
In other words, if the keys are pre-created by an administrator, user
will be able to create and remove machines without requiring to run any
elevated command. Even for the first podman machine.
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
Replace remaining references to Slirp/slirp4netns in code comments
with Pasta or remove them where the reference is no longer relevant.
Signed-off-by: Lokesh Mandvekar <lsm5@linux.com>
The podman module paths are moving from github.com/containers/podman to
go.podman.io/podman. This will help with future mobility.
Signed-off-by: Brent Baude <bbaude@redhat.com>
Currently, running Podman on Hyper-V as a non-administrator requires the user to be a member of the "Hyper-V Administrators" local group. If they are not, various WMI calls fail with access denied.
This commit automates the permission setup.
1. During podman machine init, if Podman is running with elevated privileges (required for registry/networking setup anyway), it will now automatically add the current user to the localized "Hyper-V Administrators" group
2. If a user is added to the group, the change is not reflected until the next login. We now detect this state and explicitly instruct the user to log out and back in.
3. Modified the Hyper-V stubber to handle permission checks at the method level rather than the provider selection level (GetAll). This allows init to continue far enough to perform the elevation and setting.
Signed-off-by: lstocchi <lstocchi@redhat.com>
This PR reflects the upstream change of moving the buildah module from
github.com/containers/buildah to go.podman.io/buildah.
Signed-off-by: Brent Baude <bbaude@redhat.com>
Use shared configfile instead of custom policy.json path handling.
This updates ocipull to rely on signature.DefaultPolicy(), removes
explicit SignaturePolicyPath, and replaces trust's custom default-policy
path logic with common configfile code.
Replace hidden `--policypath` with --signature-policy` and require
it for `trust set` command instead of path resolution based on
configfile.
For `trust get`, the `--signature-policy` is optional.
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
The Docker client (docker run) sends /wait then /start, but it only
sends /start after receiving the 200 OK response from /wait. Previously,
the event subscription for the "died" event was set up after the 200 was
sent, creating a window where a fast-exiting container (e.g. hello-world)
could emit its "died" event before the subscription was ready, causing
the client to hang forever.
Fix this by subscribing to "died" events before flushing the 200 status
code. This guarantees the event listener is ready before the client can
send /start, eliminating the race entirely.
Fixes: https://github.com/containers/podman/issues/28514
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
These are two new Buildah flags that we need to wire into Podman
(both local and remote) and document, with the interesting note
that one requires the other and a check needed to be added for
that.
Also: secret parsing was tightened up in Buildah, and was
breaking the remote build tests. Rewire it to use the new parser
Buildah made, which ends up simplifying the code considerably.
Tests are back to passing afterwards.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
This was implemented by containers/netavark #1369; this commit
completes the process by wiring it into Podman. We now respect
the CLI order for configured networks - if a user passes
`--net net1,net2` we guarantee that net1 will be configured
before net2.
For containers created before this patch, we don't retain enough
information to configure networks in CLI order, so we use
alphabetical order instead to still guarantee consistency.
No breaking API changes have been made, but we do add a new
field to supplement the existing map to (optionally) provide
ordering information. The Podman CLI will always pass this.
Existing applications that do not will, again, receive]
deterministic ordering based on an alphabetical sort of network
names.
This requires the latest version of Netavark to work properly.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
With netavark v2 we start to default to strict isolation mode in
netavark[1] as such that already matches the docker behavior.
Therefore no longer hard code the isolate option in the compat api.
Podman v6 is requires netavark v2 for other changes already so we do
not need to worry about podman 6 + older netavark here.
[1] https://github.com/containers/netavark/pull/1438Fixes: #27349
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The systemd timer created for health checks did not pass global
podman flags to the subprocess, causing it to use default storage
settings instead of matching the parent process. This is most
visible with --transient-store, where the healthcheck looks up
the container in the default store instead of the volatile one.
Extract GlobalPodmanArgs() from CreateExitCommandArgs so both the
exit command and healthcheck timer share the same set of global
flags (--root, --runroot, --transient-store, --storage-driver, etc.).
Fixes: https://github.com/containers/podman/issues/28483
Signed-off-by: Jan Rodák <hony.com@seznam.cz>
