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>
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>
Tremendous amount of changes in here, but all should amount to
the same thing: changing Go import paths from v5 to v6.
Also bumped go.mod to github.com/containers/podman/v6 and updated
version to v6.0.0-dev.
Signed-off-by: Matt Heon <mheon@redhat.com>
The PodmanOptionsKey is never used anywhere so it is pointless to add
this. Second having several functions to return the same context makes
no sense so fold them all into one. Lastly create the context once and
always return the same one instead of having to nil check each time.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Moving from Go module v4 to v5 prepares us for public releases.
Move done using gomove [1] as with the v3 and v4 moves.
[1] https://github.com/KSubedi/gomove
Signed-off-by: Matt Heon <mheon@redhat.com>
Before this, for some special Podman commands (system reset,
system migrate, system renumber), Podman would create a first
Libpod runtime to do initialization and flag parsing, then stop
that runtime and create an entirely new runtime to perform the
actual task. This is an artifact of the pre-Podman 2.0 days, when
there was almost no indirection between Libpod and the CLI, and
we only used one runtime because we didn't need a second runtime
for flag parsing and basic init.
This system was clunky, and apparently, very buggy. When we
migrated to SQLite, some logic was introduced where we'd select a
different database location based on whether or not Libpod's
StaticDir was manually set - which differed between the first
invocation of Libpod and the second. So we'd get a different
database for some commands (like `system reset`) and they would
not be able to see existing containers, meaning they would not
function properly.
The immediate cause is obviously the SQLite behavior, but I'm
certain there's a lot more baggage hiding behind this multiple
Libpod runtime logic, so let's just refactor it out. It doesn't
make sense, and complicates the code. Instead, make Reset,
Renumber, and Migrate methods of the libpod Runtime. For Reset
and Renumber, we can shut the runtime down afterwards to achieve
the desired effect (no valid runtime after). Then pipe all of
them through the ContainerEngine so cmd/podman can access them.
As part of this, remove the SystemEngine part of pkg/domain. This
was supposed to encompass these "special" commands, but every
command in SystemEngine is actually a ContainerEngine command.
Reset, Renumber, Migrate - they all need a full Libpod and access
to all containers. There's no point to a separate engine if it
just wraps Libpod in the exact same way as ContainerEngine. This
consolidation saves us a bit more code and complexity.
Signed-off-by: Matt Heon <mheon@redhat.com>
The --module can only be parsed on the root level. It cannot work on
the command level, because it must be "manually" parsed on init() to
make sure the specified configuration files/modules are loaded prior to
parsing the flags via Cobra.
Hence move --module from the "persistent" to the "local" flags which
will yield an error instead of doing nothing when being specified on the
command level:
```
$ ./bin/podman run --module=foo.conf --rm alpine
Error: unknown flag: --module
See 'podman run --help'
```
Reported in #20000.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Shortcuts like unix:path and unix:/path do not work everywhere,
so make sure to use unix://path when quoting the url (or address)
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
Support a new concept in containers.conf called "modules". A "module"
is a containers.conf file located at a specific directory. More than
one module can be loaded in the specified order, following existing
override semantics.
There are three directories to load modules from:
- $CONFIG_HOME/containers/containers.conf.modules
- /etc/containers/containers.conf.modules
- /usr/share/containers/containers.conf.modules
With CONFIG_HOME pointing to $HOME/.config or, if set, $XDG_CONFIG_HOME.
Absolute paths will be loaded as is, relative paths will be resolved
relative to the three directories above allowing for admin configs
(/etc/) to override system configs (/usr/share/) and user configs
($CONFIG_HOME) to override admin configs.
Pulls in containers/common/pull/1599.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
This commit creates a new command `podmansh` command which can be used by
administrators to provide a confined shell to their users.
The user will only have access to the volumes and capabilities for that
user.
Co-authored-by: Paul Holzinger <pholzing@redhat.com>
Co-authored-by: Daniel Walsh <dwalsh@redhat.com>
Co-authored-by: Petr Lautrbach <lautrbach@redhat.com>
Co-authored-by: Ed Santiago <santiago@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
there are no commands that are not supported by rootless mode, but
some commands require to run in the user namespace.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Also fix a number of duplicate words. Yet disable the new `dupword`
linter as it displays too many false positives.
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Use `Default()` instead of re-loading containers.conf.
Also rework how the containers.conf objects are handled for parsing the
CLI. Previously, we were conflating "loading the defaults" with
"storing values from the CLI" with "libpod may further change fields"
which ultimately led to various bugs and test failues.
To address the issue, separate the defaults from the values from the CLI
and properly name the fields to make the semantics less ambiguous.
[NO NEW TESTS NEEDED] as it's not a functional change.
Fixes: containers/common/issues/1200
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Alias
podman --context -> podman --connection
podman context use -> podman system connection default
podman context rm -> podman system connection rm
podman context create -> podman system connection add
podman context ls ->podman system connection ls
podman context inspect ->podman system connection ls --json (For
specified connections)
Podman context is a hidden command, but can be used for existing scripts
that assume Docker under the covers.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Docker supports -H and --host for specify the listening socket. Podman
should support them also in order to match the CLI.
These will not be documented since Podman defaults to using the
--url option.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We now use the golang error wrapping format specifier `%w` instead of
the deprecated github.com/pkg/errors package.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
* Replace "setup", "lookup", "cleanup", "backup" with
"set up", "look up", "clean up", "back up"
when used as verbs. Replace also variations of those.
* Improve language in a few places.
Signed-off-by: Erik Sjölund <erik.sjolund@gmail.com>
I do not know why this code was added but it is wrong. We should never
use a plugin dir as config dir. Also this will fail for netavark. The
correct default will be set in c/common so podman should not touch it.
[NO NEW TESTS NEEDED]
Ref #13183
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Heuristic to initialize TunnelMode/remote podman:
- Podman built with remote tag
- Podman running on darwin or windows GOOS
- CONTAINER_HOST or CONTAINER_CONNECTION set in environment
- --remote flag given on command line
- From containers.conf, Engine.Remote == true and GOOS == linux
Otherwise, podman will run in ABIMode/linked against libpod library.
Fixes#12866
Signed-off-by: Jhon Honce <jhonce@redhat.com>
This reverts commit 91e21bed48.
XDG_RUNTIME_DIR is required for the authfile path. We cannot unset it.
[NO TESTS NEEDED]
Fixes#11725
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Depending how the user logs in to the root account, XDG_RUNTIME_DIR is
set to /run/user/0 or it is unset. For conmon we already set it always
to an empty string. The inconsistency is causing issues for the dnsname
plugin. To fix it unset XDG_RUNTIME_DIR for the podman process.
[NO TESTS NEEDED]
Fixes#10806Fixes#10745
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
add a new annotation for the "system migrate" command to not move the
pause process to a separate cgroup.
The operation is not needed since "system migrate" destroys the pause
process, so there won't be any process left to move to a cgroup.
[NO TESTS NEEDED]
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
[NO TESTS NEEDED]
This commit cleans up two issues:
* Most commands support all EngineModes so default to that. Let
outlayers declare their intent.
* Use cobra.Annotations to set supported EngineMode. This simplies
instantiating commands as there is now one method to communicate a
commands requirements rather than two.
* Combined aliased commands into one file
* Fixed aliased commands where Args field did not match
* Updated examples in README.md for writing commands
* Remove redundant flag DisableFlagsInUseLine in cobra.Command
initialization.
Signed-off-by: Jhon Honce <jhonce@redhat.com>
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>
Allow automatic generation for shell completion scripts
with the internal cobra functions (requires v1.0.0+).
This should replace the handwritten completion scripts
and even adds support for fish. With this approach it is
less likley that completions and code are out of sync.
We can now create the scripts with
- podman completion bash
- podman completion zsh
- podman completion fish
To test the completion run:
source <(podman completion bash)
The same works for podman-remote and podman --remote and
it will complete your remote containers/images with
the correct endpoints values from --url/--connection.
The completion logic is written in go and provided by the
cobra library. The completion functions lives in
`cmd/podman/completion/completion.go`.
The unit test at cmd/podman/shell_completion_test.go checks
if each command and flag has an autocompletion function set.
This prevents that commands and flags have no shell completion set.
This commit does not replace the current autocompletion scripts.
Closes#6440
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
--remote pre-check was providing usage context, which was also being
provided by the root podman command.
Fixes#7273
Signed-off-by: Jhon Honce <jhonce@redhat.com>
Use cobra.Command.FParseErrWhitelist to no longer require --remote to be
the first argument in flags when using CLI
Signed-off-by: Jhon Honce <jhonce@redhat.com>
