 2️⃣3️⃣ Here's the 23rd post highlighting key new features of the upcoming v257 release of systemd. #systemd257 In systemd, as mentioned in one of the previous installments, we are adopting the Varlink IPC at more and more places. To interface with Varlink IPC from the command line we provide the "varlinkctl" tool. "varlinkctl introspect <socket>" for example introspects which method calls, types, and errors a service provides. Similar, "varlinkctl call <socket> <method> <json>" calls a method. 8 comments
the usual systemd socket activation protocol) that it shall respond to Varlink queries via a passed in socket fd. The path may also be prefixed with "ssh-unix:" in which case an SSH connection is made to some remote Varlink service. New with v257 is that "ssh-exec:" is now also available which also sets up an SSH connection, but invokes a specified binary on the remote side, talking to it via standard input/output. All four ways to communicate (connect to AF_UNIX socket, execute binary, … … connect to remote AF_UNIX socket, execute remote binary), are also accessible via sd-varlink. Or in other words: it's now almost as easy to talk to a local Varlink socket as it is to talk to a remote one. (This is super handy in combination with the AF_VSOCK support we provide for SSH'ing into local VMs, added in v256). And that's it for today!  @pid_eins Do I understand correctly that the remote varlink socket does not need to know about being queried remotely? It does not need to be a v257 varlink socket? @fluchtkapsel the service won't know it's called remotely. I mean there are hints (i.e. if ssh-exec: is used the process name of your ppid is going to be ssh, and if you do ssh-unix: then your SO_PEERCRED will be ssh).  @l0kod the varlink specs discourage that, but sd-varlink supports it on transports that know the concept (i.e. on af_unix). systemd makes use of it at various places. |
Gregory's Server
Here are two examples using that:
varlinkctl introspect /run/systemd/io.systemd.Credentials
and
varlinkctl call /run/systemd/io.systemd.Credentials io.systemd.Credentials.Encrypt '{"text":"foobar"}'
The 2nd argument always specifies the entrypoint socket to talk to. In most cases where you call this locally that's the file system path of an AF_UNIX socket. However this can also be the path to an executable, in which case the executable is invoked and told via $LISTEN_FDNAMES (i.e.