Support /usr/*/registries.conf*

[sysrich]

We have support for distros shipping config for storage, containers, seccomp and more into /usr/share/containers with sysadmins being able to write system wide config in /etc/containers and user config in $HOME/.config/containers

However, for registry configuration we only support /etc/containers and $HOME/.config/containers

(source: https://github.com/containers/image/blob/main/docs/containers-registries.conf.d.5.md)

The inability to provide a distro registry config in /usr/share/containers is the reason why openSUSE still cannot ship shortnames, because we wouldn't want to potentially overwrite/complicate the sysadmins own registry config in /etc (as a general rule *SUSE is trying to avoid packaging anything in /etc as much as possible)

Is there any reason for the current omission? Can we add support for registries config in /usr as we do for so much else already?

[vrothberg]

Thanks for reaching out, @sysrich!

registries.conf has been in /etc/containers/ since I can remember, so I defer to the elders:
@rhatdan @mtrmac PTAL

Regarding the sequence of loading the various files it would probably be:

1. /usr/share/containers/registries.conf{.d}
2. /etc/containers/registries.conf{.d}

[JanZerebecki]

With a /usr provided default care must be taken to make it easy to override the default. That is here: clearing all alias entries; clearing all registry entries; overwriting the mirrors of one registry prefix. Compare with the usability of using a https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html L line for the system default files.

[vrothberg]

Thanks! So it's probably more reasonable to read from /etc/containers/registries.conf{.d} only if present (and ignore /usr/).

[JanZerebecki]

No, that will be confusing as the other config directories don't work that way and more work as most people likely will not want to clear the system provided aliases from shortnames. It is just that it should be easy if one wants to. Compare to if a symlink at boot and installation is created if it doesn't exist from /etc/containers/registries.conf.d/shortnames.conf to /usr/share/containers/registries.conf.d/shortnames.conf then it is easy to remove the symlink and replace it with an empty file.

To get the same usability when config is always also loaded from /usr one needs to have a way to clear groups, like "[aliases] = []" and "[[registry.mirror]] = []" or something.

[rhatdan]

I believe we should ship the "distros" defaults in /usr and leave /etc/ to the system administrator, so I support changing this.

[mtrmac]

Thanks! So it's probably more reasonable to read from /etc/containers/registries.conf{.d} only if present (and ignore /usr/).

Yes, the .d directories are the hard part. This has to somehow fit into the pre-existing logic of newConfigWrapperWithHomeDir, and presumably we don’t want all of /usr/*/registries.conf.d installed by various RPMs to be completely ignored when the user, or some other RPM, adds a single *.d (or *.conf?) to /etc/.

---

With a /usr provided default care must be taken to make it easy to override the default.

Making the individual *.d entries incremental seems necessary, then. That’s already the case for most individual options, and easy enough for [[registries]] (just copy&paste the one prefix-scoped entry).

For aliases, we already have a way to remove a single alias, as well.

Clearing all of them… ugh, a special-semantic entry (remove-all-previous-aliases=true??) ? The [[aliases]] table doesn’t leave a namespace for adding a special-semantic entry like that, at least not with a natural name.

Alternatively… do we really need to clear all of the entries? What for? Presumably the distribution is not going to gratuitously add broken [[registry]] entries; and any deployment only cares about [[alias]] entries relevant to the application, so removing extraneous ones seems unnecessary.

---

A reminder: Short-name aliases are almost exclusively an interactive users’ convenience feature; thus they are naturally a per-user property, or at best a system-wide default installed by a distribution for the common cases. Any application that has installation steps involving “add a short-name alias” is doing it wrong (because it is impossible to install side-by-side with another application that uses a conflicting alias); it should be using fully-qualified names instead.

---

Overall, this does seem possible to design, and it is a very reasonable desire.

[JanZerebecki]

People can still remove the shortname package if it is a separate package and only weakly dependent on via suggests. So in practice maybe nobody will miss an empty-all-previous-entries.

[Luap99]

This is being worked on for Podman 6 https://github.com/containers/podman/blob/main/contrib/design-docs/config-file-parsing.md