mirror of
https://github.com/systemd/systemd.git
synced 2026-06-24 08:47:49 +00:00
382f141fea
So far we didn't provide any concept to enumerate local Varlink services. Let's change that. Let's define very light-weight scheme for this: provide a well-known dir /run/varlink/registry/ where services that implement public interfaces can link their sockets into. When enumerating services it's thus sufficient to enumerate inodes in that directory. The usecase for this is twofold: 1. It's simply very useful to be able to see which public services are bound on the local system, for debugging/admin/development purposes. 2. At Amutable we'd like to optionally provide a HTTP-to-Varlink bridge on individual nodes, that allows remote peers (after authentication) to access local Varlink services. For that it's essential we know the list of services and their entrypoints to expose, it would be security-wise highly problematic for clients to provide AF_UNIX entrypoint paths when connecting. hence: let's instead just have a dir with the public stuff, and let's ensure the HTTP-to-Varlink bridge simply exposes that stuff, and nothing else. Non-public interfaces (such as the oomd interfaces between PID 1 and oomd), and interfaces with multiple implementors (such as the resolved hook interface, or the metrics collection stuff) should not be linked in. This is inspired by the Varlink.org "registry" concept, briefly explained here: https://varlink.org/FAQ#how-do-i-find-the-service-which-implements-a-local-interface Note however that the described Varlink interface is not actually implemented here, the directory is introduced however in a fashion that conceptually matches the registry defined there, and would allow us to implement the registry interface on top of it. (One of the reason the registry Varlink API is not implemented right now is that the URI format it relies on is entirely unspecified in the Varlink docs right now. Some research needs to be done to extract what's implemented in the reference implementation and to determine how it maps to the Varlink entrypoint address format systemd's own tooling currently uses) This primarily installs the symlinks via Symlinks= in unit files and via a new tmpfiles.d/ drop-in. But since we touch all .socket units relating to Varlink this also sets the FileDescriptorName= to varlink for each, just to minimize diffrences and make things work more alike (the services in questin don't care about the name, so this doesn't change). In one case we replace a pair of separate sockets for two closely related varlink services by a socket and a symlink, so that we can safely use Symlinks= to also install the registry symlinks.