You can use any admin client tool (all qvm- commands) from admin client qube as long as the policy required for their function allows it. Which is really a subset of “you can request any qrexec service from dom0, which includes admin API by the way”
This is the audience for the proposed terminology amendment. “Normal” person will never get themself confused investigating the difference between “admin qube”, deprecated “AdminVM”, and “AdminVM” klass.
Taking a deep breath, and skipping the rest of this thread.
Maybe there is a joke here that I am not getting!
I took it as: they don’t know/care of any of the terms so can’t be confused
I disagree, and I dont think this term would be helpful.
What does “client” mean here? How many people coming to Qubes for the
first time would understand how it is used in this context? What is it a
“client” of? What is the thing called that makes it a client?
I think that this term is not unambiguous and is unclear.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Yes, it is. Which is exactly why I proposed this solution. It’s
simple and allows the administrator (whether that is user or not) to
set exact limits on what the remotely accessible qube can do. You may
want to give full control. You may want to limit control to one or two
qubes/templates. That’s what the policies are for.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Thanks. I just wanted someone with higher competence to confirm it.
As I said, I am already deploying it, though locally, but in the context of AdmiVM, accessing it is trivial.
I think they meant “It has clients” not itself being a client. But let me not speak in their name.
That part is easy. Running qubes-core-admin-client = admin client qube. There might be some confusion around what “running qubes-core-admin-client” means, but the concept should be simple enough to explain even to a newcomer.
It is a client of qubes-core-admin (of qubesd strictly speaking, which is the central part of qubes-core-admin, correct me if I’m wrong), but the details of what makes qubes-core-admin, which also kind of pulls qrexec daemons into the conversation, can be hard to grasp. Easy for a user that read and understood admin API and qrexec docs, which is the hard part.
Don’t know, of course. Introduction chapter of the docs doesn’t mention admin at all, and “getting started” just barely touches on the admin qube, saying that the only admin qube is dom0, and moves on.
Similarly, installation chapter doesn’t mention admin at all.
My guess is newcomers can (and probably do?) start with just remembering that admin qube means dom0, or not bothering with admin-related terms at all, and revisit the topic once they have better familiarity with Qubes OS.
If anything this reinforces the confusion: if only admin qube is dom0, and dom0 is the only AdminVM, why people say second admin qube is possible? Does it mean second admin qube is also AdminVM? And then they stumble upon old forum topics / blog posts that casually throw AdminVM around like it is not a hard-coded class unique to dom0.
The term “admin client qube” is good because it points to the distinct feature of an admin client qube, a feature that separates it from other administration- and management-related infrastructure. What makes it unclear to you? Or perhaps I am missing the point you’re making?
Rightly so. It’s not an introductory topic.
AdminVM is an outdated term, which should no longer be used, We stopped
using “VM” and replaced it with “qube” some time ago. (The same for
NetVM, ProxyVM, AudioVM, etc). If you read posts and announcements from
some years ago, you will see that the VM usage is common. It should no
longer be used.
You will see that similar terms are still used for some properties of
a qube - netvm, audiovm,dispvm - and klasses. None of the klass names
should be used to describe qubes.
dom0 is the only admin qube on install. There are no options on a
standard install to create a separate admin qube, (though I have done
this with PXE rollouts and custom built iso). This does not mean that it
need be the only admin qube.
Some users or administrators may wish to create a second admin qube - or
third, or …).
AdminVM as the name of a klass in Qubes is clearly different from
something that is a property of a qube. If users cannot understand this
they should probably not be trying to use an admin qube at all.
Similarly users who try to work with posts and forum threads from years ago
without some critical understanding are unlikely to be successful.
I disagree. I understand the intention but I think it will be more
confusing for ordinary users. I dont intend to adopt this term.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
TBH if I had seen it coming that the term “admin client qube” would turn out so controversial, I would never have suggested it. Probably the worst outcome would be only adding it as one more of several terms people continue using to refer to the same thing. Maybe in the future I’ll say “a qube that uses the admin API” instead. It’s wordier, but it has the advantage of not suggesting that there’s a somehow special kind of qube involved.
Cause that’s my sticking point with the existing terms. They seem to shroud the thing in a fog of specialness and subtly misleading mental models. To illustrate how bad it can get: After I had already contributed code to qubes-core-admin-client it still took me a while before it really clicked that a) this code can be used as-is in other qubes too, not only in dom0; and then again even later b) it’s not necessary to give such qubes an all-or-nothing block of permissions. Like what the hell, it was just RPC calls all along??
Sure, klass is not something you can change after creating a qube, but correlation between “admin qube” and “AdminVM” is nonetheless possible considering that dom0 is the only one of both by default. Especially for a user trying to understand what makes a qube admin.
Do they have any other good option? I just grepped the doc, “admin qube” is mentioned in 3 places: term in the glossary (one sentence), similar mention in “Getting started”, and one sentence in “System architecture” of the developer documentation. The latter being:
The admin qube distribution (various customizations, special services, such as for receiving and verifying updates, in the future: custom distro)
None of these offer an explanation of the overlap caused by the old terminology, or an alternative to old blog posts using new terminology, or even a note saying “klass AdminVM has nothing to do with admin qube. Do not use klass names to describe qubes”. Does it mean set of users unlikely to be successful includes everybody?
I agree to disagree, but by itself it won’t improve the situation. If the new term is unacceptable, perhaps you could offer an alternative to help resolve the confusion?
Also a side note, why do you think klass names should not be used to describe qubes? They are used to describe qubes by the system itself, it is only fair to follow. Correct me if I’m wrong, but most klasses fit function of qube types exactly. AdminVM is an outlier, another one being perhaps disposable template (but that one is very close as only the ability to spawn disposables is missing from klass, otherwise it is a conventional AppVM).
I have had no problems adopting any term so far, once I learned distinctions from look-a-likes and how the term carrier can benefit me with my goals.