[systemd-devel] Remote api for systemd via separate daemon

Lennart Poettering lennart at poettering.net
Sat Feb 28 10:27:36 PST 2015


On Sat, 28.02.15 17:25, Peter Paule (systemd-devel at fedux.org) wrote:

> While reading the news about dkr swarm and seeing what's going on at
> CoreOS' fleet, a mail to the ML from 2013 came into my mind.
> 
> There was someone asking for some network API for systemd, if I remember
> correctly. I think the answer was no, because you don't want systemd to be
> exposed to the "outer" world. I'm not keen to expose systemd to the
> network work either.
> 
> But looking at fleet there seems to be some need to start/stop
> services/machines from remote. I asked myself if it does make sense to
> expose a subset of systemd's functionality to the network by introducing
> a small daemon - e.g. systemd-remoted - to the systemd ecosystem.
> 
> I can image, that the daemon could expose:
> 
> * Starting/Stopping of services
> * Starting/Stopping of VMs/containers
> * Pulling machines using machinectl pull-*
> * Maybe even something about the load of node where the daemon is
>   running.
> 
> The daemon could use some kind of rpc like REST+JSON or even the new kid
> on the block "google's grpc" (https://github.com/grpc/grpc, HTTP2, with
> bindings for c, c++, ruby, python, go, ...) to expose the API.
> 
> I would see this daemon more as ground layer for some other cluster
> daemon which makes use of systemd-remoteds api.
> 
> Does this make sense to you or is this totally non-sense and should
> better be solved elsewhere?

Note that we do expose most of our APIs remotely, but not via HTTP,
currently. All the bus APIs we expose are remotely accessible via SSH,
and this is used in all out tools like "systemctl", "loginctl" and
"machinectl". Our bus API library "sd-bus.h" has high-level support
for this too to make this easy for other apps to use.

We also have a HTTP REST API for querying the journal already
implemented in systemd-journal-gatewayd.

I think having a HTTP REST API for the core systemd APIs might makes
sense too, but I am concerned that as long as there isn't a commonly
used client for it the API would just bitrot and be incomplete.

Also note that Cockpit might have parts in place for this, including
some more or less generic HTTP to dbus glue...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list