On Tue, Jan 21, 2025 at 8:47 AM Erik Slagter <erik@xxxxxxxxxxxx> wrote:
Hi Lennart,
That is exactly the answer I expected, if only because apparently
systemd does it exactly that ;-)
But not everything needs to be enterprise-grade. This is going to run
inside my own house in a piece of network that's completely trusted. I
can completely imagine it's not sane to do this with the system or even
session bus, but this is a very simple "request value x for me"
mechanism, on it's own bus.
It's now running on SUN RPC (with just as little security), but I fear
that one has had it's longest time, being around for > 30 years and I am
getting the feeling support is fading. It's also not great to develop
for. I had a quick look at SOAP but support in C++ seems to be next to
non-existing and needs a web server. Latest hot stuff seems to be gRPC
but it's overly complicated and bloated. So I'd like to with DBus which
happily does what I need.
Well, at least SunRPC can have Kerberos authentication available for it (RPCSEC_GSS). In theory, if I recall correctly, D-Bus uses the SASL framework and could be made to use GSSAPI or SCRAM (or maybe even TLS with client certificates), but no current implementation supports any of that; all are designed to be local-only.
...Though on the other hand, didn't Microsoft once ship a network D-Bus-based IoT system as part of Windows? I believe that's what "AllJoyn" was.
I'm not sure if SOAP inherently requires a "web server"? It requires an HTTP server, yes, but that doesn't necessarily mean a whole Apache2 or IIS. Accepting HTTP requests is not fundamentally much different from e.g. a D-Bus server (except with more overhead; I'd prefer JSON-RPC over SOAP, but anything HTTP-based is definitely not light in itself).
(For my hobby projects I started with JSON-RPC over HTTPS, and ended up with JSON-RPC inside Kerberos over raw TCP – but both were almost equally self-contained "RPC servers", in that both kinds of requests were served in-process and not through any 'web' stack.)
Mantas Mikulėnas
