Lennart Poettering
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.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release