Qube Manager redesign (visual connections between qubes, drag & drop, zooming) (status: mockup)

[ddevz]

@Ferdinand_Heinrich

The core change is what I call “Deck view”. It’s the currently selected tab in the mockup and its features would be:

Your idea sounds neat. Here is related info on a previous attempt, but your idea looks better then this one:

Visualize Qubes Configuration Without Trust / A Use Case for the Qubes Admin API

Objective: Be able to visualize your configuration using qvm-ls-mermaid like this: qvm-ls-mermaid/examples/1.png at master · 3hhh/qvm-ls-mermaid · GitHub [image] , but without trusting it in dom0 qvm-ls-mermaid is written by 3hhh/tripleh and can be installed in dom0. And while we don’t specifically distrust tripleh, we don’t necessarily trust him either. (Sorry @tripleh ! ). The idea is that instead of doing a security review of each line of code in qvm-ls-me…

Which ultimately comes from this:

GitHub - 3hhh/qvm-ls-mermaid: Qubes OS network & RPC graphs

One issue that happens with mermaid is that once your system has a lot of qubes (for example, qvm-ls | wc shows 170 qubes on my system), the automatic layout algorithm will sometimes try to put like 100 of them on one line next to each other, (going far “off the page”). (note: trying qvm-ls-mermaid now just gives me a “Maximum text size in diagram exceeded”, so I cannot confirm these things as I am saying them)

My point is:

• Looking at this for ideas for kinds of relationships you may want to present may be a good thing
• That the algorithm for laying out the nodes in a automatic way will probably become a focus point. You may want to see if someone already has a good automatic layout algorithm that’s part of a library that’s small enough for people to feel comfortable adding it to dom0

@likeafox

To my mind the graph should only be describing network connectivity (or even relationships generally, but power state is not a relationship).

I notice he has a “Qube connections: Network” box in the upper right corner. I’m assuming the thinking is about only displaying one relationship at a time, where the user could change “Network” to “Template”, or “Policy Group” or whatever?

However, “power state” should be determinable from each graph, since when someone wants to know something about a VM, more then 80% of the time the VM will probably be currently running, making it a easy way to visually find the VM you want and not the many, many non-running VMs. It could be something as simple as greying it out.

Also note he was displaying the security label colors (which is probably a good idea)

@Ferdinand_Heinrich

It will be a KDE app (Plasma Desktop 6, more specifically) because I would like to provide easy access to theming and I prefer Qt 6.

My guess is that a KDE app would probably not get accepted for dom0 as it would pull in tons of kde libraries, however you can read the “visualize qube config without trust” on how to use the Qubes Admin API to run qubes-manager not in Dom0. (I.E. by putting your new qubes-manager in a qube and running it from there with enhanced, but restricted permissions)

And finally a rabbit hole to go down about information about expressing information beyond security label color:

Picking a system for selecting colors/security labels for qubes

(Got good feedback already, so information from comments responding to this post have been added to this post) Definition of “security labels”: For this document, I’ll refer to all the types of important security related information that would be good to be known about a qube when making decisions about it as “security labels” (colors will be one way of expressing that information) What we want to express: Some information we might need to convey through the security labels is How vulnerab…

(tip: don’t try to handle every use case. at some point you have to give up reading about new use cases and actually do something, but it can be good to know what the issues that may come down the line are)