Description

When refactoring zypp we more than once thought about having a zyppd that can run in the background, multiple zypper instances could connect to it receiving current operations and, if the user rights match, control the operation.

Goals

  • Have a simple zyppd with some clearly defined protocol running
  • Investigate protocol options: dbus vs json-rpc
  • Simple frontend that can connect and run some task

Resources

  • C++ / C compiler
  • libzypp/zypper source code

Looking for hackers with the skills:

Nothing? Add some keywords!

This project is part of:

Hack Week 25

Activity

  • 21 days ago: j_renner liked this project.
  • 22 days ago: zbenjamin started this project.
  • 22 days ago: zbenjamin originated this project.

  • Comments

    • zbenjamin
      21 days ago by zbenjamin | Reply

      So as for a protocol there seem to be only a couple of options:

      • sdbus , would be what many service implementations use nowadays but couple us to systemd + dbus. Drawback here is that our minimal container images do not have systemd/dbus running so i'd need to fall back to peer-to-peer mode
      • the libzypp implementation of Stomp, would need a good amount of work to support things peer authentication
      • varlink, a library that is meant for exactly the use case "system services not using dbus"

    • zbenjamin
      21 days ago by zbenjamin | Reply

      Also not available in our minimal images: polkit, this would've been one of the strong points for dbus/system since we'd not need to do authentication ourselves.

    • zbenjamin
      21 days ago by zbenjamin | Reply

      varlink seems to be the most promising one for now, so i will go with that

    • zbenjamin
      20 days ago by zbenjamin | Reply

      After some playing around with varlink it turns out that it has limitations when it comes to bidirectional communication. Messages must be strictly linear, one call -> direct answer. The server can not send spontaneous messages to the client without a previous message call. There is a way to stream "more" answers but it would require to have 2 sockets per client. Things like "prompt user" or "progress" would need a monitor socket making the whole architecture way too complex. We want to have a simple API clients can use

    • zbenjamin
      14 days ago by zbenjamin | Reply

      I started to implement the server via our already existing STOMP implementation. Instead of going for the full protocol the code would just use the STOMP frame to package the messages but not the actual communication procedure. However due to legacy zypp's code structure its not possible to simply let it run a task while also waiting for messages over the socket, instead i'd need to worker thread i can push messages into. So I did not get very far and also wanted to look into another small project playing with AI supported coding. I need to continue this in the next hackweek.

    Similar Projects

    This project is one of its kind!