General usage

[jwmelto]

Getting Started

The top-level README.md needs a link to ReadTheDocs

Configuration

The latest "Getting Started" guide uses v0.10.0-unique features, even though the latest EPEL package is v0.9.0. Users who install the packages as suggested cannot follow the guide.

"Getting Started" should use TCP (since that is what older versions support) and can document Unix-domain sockets as an alternative for v0.10.0 and later systems.

Usage

On a moderately secure RHEL 9.4 system, DBus access is not allowed. For example, as an unprivileged user, the python snippet

from bluechi.api import Controller

for node in Controller().list_nodes():
    # node[name, obj_path, status, peer_ip]
    print(f"Node: {node[0]}, State: {node[2]}")

raises an exception:

dasbus.error.DBusError: Sender is not authorized to send message

Similarly, the bluechi-is-online tool (for any command besides "help" or "version") returns

Failed to get property: Permission denied

It is unclear whether a policy needs to be added to /etc/dbus-1/system.d/ or some other configuration change is required. While it is obvious that many systemctl commands do require elevated privilege, basic query and status commands do not. Similarly, BlueChi should allow read-only access to general users "out of the box".

[mwperina]

Hi @jwmelto,
as automotive is the main area for BlueChi and we haven't got any requirements from that area to allow access to BlueChi for non-privileged users, we don't have any plans for BlueChi 1.0 to provide some limited read-only access to non-privileged users.
If you want non-privileged users to access BlueChi, you can use policykit to add permissions for dbus access to the specific userr, but that means this user will become a privileged user with complete access to BlueChi.

Regards,
Martin

[jwmelto]

Digging deeper, I'm trying to prove out a multi-node configuration, where the second "node" is a container running on the host (and sharing its network).

I can inspect services in the container, but it cannot control (or status) on the host. Do I need to run a controller on any node that I want to issue commands? Maybe I misunderstood the roles of agent and controller.

[jwmelto]

By the way, all the examples in https://bluechi.readthedocs.io/en/latest/getting_started/examples_bluechictl/ show running as a non-privileged user. This doesn't work for me. If it should, it would be nice to fix.

[mkemel]

To control services on the host, you need to run an agent on the host as well.

To play with bluechi on a single machine with containers, you can follow this workshop, I think it showcases and explains basic architecture and functionality pretty well.
In the first step - prefer building a new container image instead of pulling, we haven't updated it with the latest bluechi version.

[jwmelto]

That workshop is very helpful (and a bit eye opening).

I notice the demo image pulls other images into it (podman inside podman). I've seen mention of this use case but failed to comprehend the utility, until now.

Is it safe to say that the architecture here is that there is a single controller, and agents everywhere else? It seems that a fundamental limitation is that control operations (i.e., bluechictl or Python API) talk to the controller via DBus, and the controller talks to agents via TCP?

If that is the case, I need to NOT run a controller on my host, but just run a container with web app and controller, and run agents everywhere else.

[mkemel]

In this demo we run the outer container to simulate hosts, and the inner containers are for the services needed for the web app. This was done just for the sake of setup simplicity and in order to have less issues during the workshop. Think of the outer containers as VMs or physical machines.

Regarding architecture:

1. There is a single controller
2. There can be multiple agents, everywhere you want to control systemd services. They can run on other hosts, but if you want to control services on the host running the controller - you need to have an agent there as well.
3. Controller talks to agents via DBus over either TCP or UDS for a local controller-agent interaction (this was not showcased in the workshop)
4. Agents talk to local systemd over DBus.

You run your web app where you want it to run, and if you want to control it via bluechi - you need to have a systemd unit for it. Systemd can control both regular and containerized (e.g. with the help of Quadlet as shown in the workshop) apps. You run your controller where you want to control the whole thing.

Helping you with architecture would be easier if you could provide your target setup.