Provide fallback search registries if the OS does not configure any

[amanjohar]

Debian 11, cockpit-podman backports fresh install.

Unable to search for images.

Missing registries entries.

[amanjohar]

podman pull works properly in the shell. can someone help me fix this.

[amanjohar]

Edit the /etc/containers/registries.conf and add the following lines to fix this.

[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com', 'registry.centos.org']

Save and restart podman and cockpit.

[amanjohar]

These sources come from /etc/containers/registries.conf. Here's a snippet:

[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com', 'registry.centos.org']

Originally posted by @garrett in #55 (comment)

[garrett]

I've just installed a fresh Debian 11 in a VM in GNOME Boxes and, indeed, when you install Cockpit-Podman from the backports registry, it pulls in a podman with an unconfigured container registry file.

Cockpit Podman should handle an unconfigured registry file in a more graceful way.

Eventually, we might want to handle registry editing.

Should we handle this as a one-off and make it a click to pre-populate with default registries? If so, which ones?

At a minimum, we need to handle the case when the registries.conf file is effectively empty (either does not exist, is empty, or has everything commented out.

Here are the contents of /etc/containers/registries.conf after installing Cockpit and Cockpit-Podman on Debian 11:

# For more information on this configuration file, see containers-registries.conf(5).
#
# NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES
# We recommend always using fully qualified image names including the registry
# server (full dns name), namespace, image name, and tag
# (e.g., registry.redhat.io/ubi8/ubi:latest). Pulling by digest (i.e.,
# quay.io/repository/name@digest) further eliminates the ambiguity of tags.
# When using short names, there is always an inherent risk that the image being
# pulled could be spoofed. For example, a user wants to pull an image named
# `foobar` from a registry and expects it to come from myregistry.com. If
# myregistry.com is not first in the search list, an attacker could place a
# different `foobar` image at a registry earlier in the search list. The user
# would accidentally pull and run the attacker's image and code rather than the
# intended content. We recommend only adding registries which are completely
# trusted (i.e., registries which don't allow unknown or anonymous users to
# create accounts with arbitrary names). This will prevent an image from being
# spoofed, squatted or otherwise made insecure.  If it is necessary to use one
# of these registries, it should be added at the end of the list.
#
# # An array of host[:port] registries to try when pulling an unqualified image, in order.
# unqualified-search-registries = ["example.com"]
#
# [[registry]]
# # The "prefix" field is used to choose the relevant [[registry]] TOML table;
# # (only) the TOML table with the longest match for the input image name
# # (taking into account namespace/repo/tag/digest separators) is used.
# #
# # If the prefix field is missing, it defaults to be the same as the "location" field.
# prefix = "example.com/foo"
#
# # If true, unencrypted HTTP as well as TLS connections with untrusted
# # certificates are allowed.
# insecure = false
#
# # If true, pulling images with matching names is forbidden.
# blocked = false
#
# # The physical location of the "prefix"-rooted namespace.
# #
# # By default, this equal to "prefix" (in which case "prefix" can be omitted
# # and the [[registry]] TOML table can only specify "location").
# #
# # Example: Given
# #   prefix = "example.com/foo"
# #   location = "internal-registry-for-example.net/bar"
# # requests for the image example.com/foo/myimage:latest will actually work with the
# # internal-registry-for-example.net/bar/myimage:latest image.
# location = internal-registry-for-example.com/bar"
#
# # (Possibly-partial) mirrors for the "prefix"-rooted namespace.
# #
# # The mirrors are attempted in the specified order; the first one that can be
# # contacted and contains the image will be used (and if none of the mirrors contains the image,
# # the primary location specified by the "registry.location" field, or using the unmodified
# # user-specified reference, is tried last).
# #
# # Each TOML table in the "mirror" array can contain the following fields, with the same semantics
# # as if specified in the [[registry]] TOML table directly:
# # - location
# # - insecure
# [[registry.mirror]]
# location = "example-mirror-0.local/mirror-for-foo"
# [[registry.mirror]]
# location = "example-mirror-1.local/mirrors/foo"
# insecure = true
# # Given the above, a pull of example.com/foo/image:latest will try:
# # 1. example-mirror-0.local/mirror-for-foo/image:latest
# # 2. example-mirror-1.local/mirrors/foo/image:latest
# # 3. internal-registry-for-example.net/bar/image:latest
# # in order, and use the first one that exists.

[jelly]

The standard Arch Linux package also does not configure any registries, which will make it harder to work with the redesign which relies on image searching for creating a new container. Should there be a message when you load the page that no registries have been configured?

[garrett]

Should there be a message when you load the page that no registries have been configured?

Yes, that seems like a good place for it.

In addition to the message, there should be a way to quickly/easily solve it too.

Since it affects both Debian and Arch (and possibly others, like Ubuntu, but I haven't checked), I'd consider this something to work on once the create button lands... unless we handle this as a two part solution where the first part is quick:

1. Mention that there are no registries found in /etc/containers/registries.conf and suggest a command to run to add the registries. (Is there a way to do this via the podman command line? Or does the file need to be edited, like with echo XYZ >> /etc/containers/registeries.conf
2. Change the message and solution so that Cockpit can directly add the registries, instead of telling someone to resort to a command line.
3. (Optional?) Perhaps add full registry editing at some point in time. (Add, remove, suggested registries, etc.)

If solution # 2 is easy enough, we could just skip to that. But I'm assuming solution # 1 would be quick stopgap to prevent a "no images found" issue.

[martinpitt]

My opinion, and some notes from IRC discussion:

• Changing /etc/containers/registries.conf from cockpit is a no-go. This is a package-maintained config file. However, there is a registries.d/ drop-in directory which can be used for that case.
• It seems a bit awkward/broken that distros configure no default registries. Let's file bugs for the affected ones.
• My preferred fix would be for c-podman to have a builtin fallback registry list (docker.io and quay.io at least) if the OS has no default registries configured.
• If the former is somehow not possible (but I'd need to be convinced pretty hard about that!), then IMHO, garrett's option 2 to create a default file from the UI is an acceptable (but blatant) hack. It also needs to work for a non-privileged user and put it into ~/.config/containers/ if desired/required.
• In either case, the search dialog would need some functionality to somehow manually specify a new registry. E.g. for downloading a fedoraproject.org registry image on Debian, or when there is a custom local registry. We can't rely on these being present in the config files, as one normally doesn't need that on the CLI (all CLI operations should always give the fully qualified container name)

[jelly]

We can add the registries in code if they are empty, but that won't help us as the search api expects registries to be configured or a specific registry provded in the search term as docker.io/fedora.

So I'm afraid we have to create a dropin file as:

[root@fedora-34-127-0-0-2-2201 ~]# cat /etc/containers/registries.d/10-podman-search.conf
unqualified-search-registries = ["docker.io", "quay.io"]

So this issue is applicable for Debian, Ubuntu & Arch Linux

On ubuntu

root@ubuntu:~# dlocate /etc/containers/registries.conf
golang-github-containers-common: /etc/containers/registries.conf.d
golang-github-containers-common: /etc/containers/registries.conf.d/shortnames.conf
golang-github-containers-image: /etc/containers/registries.conf

For debian/ubuntu I found this bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978650

[martinpitt]

As I said, I veto that c-podman creates a config file with unqualified-search-registries. The Debian maintainer already wontfix'ed that bug, and I fully agree. This totally goes against the direction/intention of what podman upstream tries to do. shortnames.conf is fine, but the Debian packages already ship that.

We need to make the search dialog requiring you to specify/select a registry, as that's just what a non-monopoly container registry world looks like. As I said, we can of course do an internal fallback and add docker.io and quay.io to the registry selector if the distro does not configure any registry. That should work with the current API (as you would always search within a given explicit registry), doesn't require changing the system configuration files, and the search results should still include the fully qualified name so that the user sees where an image comes from.