2️⃣ Here's the 2nd post highlighting key new features of the upcoming v260 release of systemd. #systemd260 #systemd

systemd is adopting the IPC system in more and more places. One nice thing about Varlink is that it is conceptually close to HTTP, in its request/response semantics. This is on purpose to make bridging the web world and the low-level system world easy.

@michaelvogt has beeing working on a Varlink/HTTP bridge in Rust, with various bells and whistles, including…

…the ability to authenticate connections via classic SSH keys (mutual TLS is supported too of course).

The bridge can be used to expose local Varlink services to remote peers via HTTP, opening up those services to the HTTP world. But sometimes the other direction is useful too: i.e. being able to access remote Varlink services exposed via HTTP via sd-varlink + varlinkctl. With v260 that's easy to do: if you specify a Varlink service not via an AF_UNIX socket path, but via an HTTP URL…

…then sd-varlink/varlinkctl will fork off /usr/lib/systemd/varlink-bridges/http (and analogue for https, or any other protocol scheme), and communicate through it.

In fact, Michael's bridge implements this client side too, and hence after installing it, you can do stuff such as:

varlinkctl call httqs://my.web-server.com:8080/ws/sockets/io.systemd.Hostname io.systemd.Hostname.Describe {}

and the right thing will happen. (I replaced a p with a q in the above, to trick Mastodon's formatting.)

Michael's bridge is hosted here: https://github.com/systemd/varlink-http-bridge

@pid_eins

The code has no license :)

Cc @michaelvogt

@Foxboron @pid_eins Yeah, sorry, its all very fresh! Fixing this now :)