Rewrite Agent to a service because we need the ability to a) serve an API and b) to be able to spawn sub-processes. about agent HOT 4 CLOSED

@vpetersson
I believe DBus is suitable for providing RPC API. You can check the caller's PID and UID, you have static typing and async, and there're bindings for every major language.
For Python there's https://github.com/LEW21/pydbus which is recommended by Freedesktop. Its dependencies are all present in Debian Stretch (as well as Ubuntu) APT repo. And it provides a ready-to-use systemd interaction like starting/stopping services, notifications, etc.

from agent.

@a-martynovich My major reservation for DBUS is that it is a bit more complicated to develop for versus a restful API and thus makeing it a bit more complicated for 3rd party app developers to integrate with our credential manager.

from agent.

@vpetersson If you look at pydbus examples they don't look too complicated. A unix socket based JSON API is not much easier (if not harder) to use, because it requires establishing socket connection, watching it, packing and unpacking the data. Either way we'll have to provide an easy to use API library for 3rdparty devs which will handle connection details itself.

I forgot that DBus won't work in Docker, thus making it a bit harder for CircleCI testing. But that also goes to systemd and journalctl which agent uses.

So when we're prototyping a unix socket JSON interface is fine, but it doesn't suit your global purpose.

from agent.

I've spent some time thinking about this, and I think you are right about using DBUS. However, it doesn't fully solve the problem, so here is what I suggest:

• Ignore the API side for now and only worry about converting the agent from a cronjob to a service
• For #86, let's ignore the API, but instead draw inspiration from Kuberenetes Secrets. What I mean by that is that we simply write the secret to a file on disk and use proper file permission.

from agent.