|
Top-level
 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. 5 comments
… 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). |
Gregory's Server
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, …