varlink: add ability to talk to remote Varlink service binary via ssh #32560
Conversation
github-actions
bot
added
documentation
util-lib
please-review
This comment was marked as outdated.
This comment was marked as outdated.
poettering
force-pushed
the
varlink-double-fd
branch
from
c1624ae to
e727cca
Compare
poettering
force-pushed
the
varlink-double-fd
branch
6 times, most recently
from
9efde3e to
2eff9c9
Compare
poettering
force-pushed
the
varlink-double-fd
branch
3 times, most recently
from
42c36a6 to
e8b3749
Compare
There was a problem hiding this comment.
This could really do with some kind of integration test.
A man page example would also help a lot in understanding how to use this.
Also, the title feels wrong in a way. This allows you to invoke a command on a remote host and communicate with it using varlink. On its own it doesn't really allow you to talk to a running service on a remote host using varlink.
Shouldn't this also add systemd-varlink-bridge like we have systemd-stdio-bridge for D-Bus which connects to a varlink service running on a remote host?
There's no need, we already support that. See varlinkctl(1) man page. You can already access remote services that are bound to some AF_UNIX socket. This requires the new support for connecting to a remote AF_UNIX socket via "ssh -W". Only available since OpenSSH 9.4, which is really recent though. systemd-stdio-bridge is a concept from a time where "ssh -W" didn't exist. I mean, we can't kill it for now, as older ssh versions are still popular. And maybe it even makes sense to keep after that, since it actually patches the negotation protocol of D-Bus to disable fd passing, since that doesn't work via ssh. (This concept like this doesn't exist in varlink anyway, hence no need for anything like this in a varlink world). To summarize, with this PR we support two different things:
And neither requires any particular tool on the other side to invoke, we just need the target socket or binary to talk to. |
When invoking another process via a pair of pipes it makes sense to allow reading from one fd, and writing from another. Teach our varlink code to do so optionally. (sd-bus supports something similar, fill the gap). This is preparation for a later commit that uses this to talk to remote SSH invocations via pipes.
…ents This makes use of the functionality added in the previous commit to implement the client-side functionality for talking to servers via a pair of fds.
… servers This adds the server-side for varlink connections over two distinct fds.
This adds varlink_server_add_connection_stdio() as wrapper around varlink_server_add_connection_pair(), that steals stdin/stdout fds and turns them into a varlink connection. To be safe it replaces stdin/stdout with /dev/null fds.
poettering
changed the title
poettering
force-pushed
the
varlink-double-fd
branch
from
e8b3749 to
ebc4a76
Compare
|
rebased, addressed the issues, added examples to the varlinkctl man page and a CI test. ptal. |
DaanDeMeyer
added
good-to-merge/waiting-for-ci 👍
github-actions
bot
removed
the
good-to-merge/waiting-for-ci 👍
So far our varlink client could connect to remote AF_UNIX sockets via SSH. This adds a 2nd SSH-based transport: invoke a binary remotely via ssh, and talk to it via stdin/stdout.
This is v257 material, don't bother with this for v256