Thanks.
Unfortunately, I can’t figure the answers from this.
Were you able to learn something?
I didn’t look into it.
The answers to your questions from my understanding:
It’s just a DVM that is used to run different internal Qubes OS tasks outside of dom0
User is not supposed to use it since it’s intended to be used for internal Qubes OS tasks only.
It’s not supported.
Maybe there are some possible workarounds or hacks to do this but developers are not interested in supporting them because it could take too much time for uncertain gains and it’s better to use this time on issues with more priority.
Thanks.
1 and 2 are still quite vague. Hopefully someone else may tell us more.
It’s not supported.
Hm. If that is really so, then all the claims about passwordless root being optional and possible to disable would turn out meaningless.
Check these issues:
I didn’t look too much into it, maybe it’s already supported.
Maybe.
The problem is that since I don’t know what are the actual functions of that DVM, I don’t know how to test/compare how all of them work with/without passwordless root. So, it is all related.
AFAIK these particular VMs only run installation/configuration scripts, which is impossible without root. And you have to trust such (signed) scripts anyway, don’t you?
AFAIK these particular VMs only run installation/configuration scripts, which is impossible without root.
It is still not clear if it is only install/config. Yes, for the activity you mention root is required. However, that doesn’t necessarily mean that in-every-VM unrestricted root is required. Since I don’t know how exactly this works through the help of this special management DVM, it is difficult to have certainty about either. In any case, there is the contradiction between the possibility of (freedom to choose) something and the requirement for the opposite.
And you have to trust such (signed) anyway, don’t you?
What does this mean?
You’ve been told what the functions are - the most obvious one being in
passing salt states to qubes for action, and passing results back to
dom0.
If you are concerned about this, create a disposable template without
passwordless root, and use it as base for the mgmt disposable. See what
happens.
If you do not want to use passwordless root there is a documented method
for using a dom0 prompt before applying sudo. Use that if you will.
You’ve been told what the functions are - the most obvious one being in
passing salt states to qubes for action, and passing results back to
dom0.
Which are the others (the not so obvious ones)? That is what I am trying to understand.
To put it differently: What will break if one damages/deletes that special VM? How to re-create it from scratch? Is it possible to use Qubes OS without it and what will be the effects of that?
If you are concerned about this, create a disposable template without
passwordless root, and use it as base for the mgmt disposable. See what
happens.
Unfortunately, I don’t have a spare (non-production) system for tests involving modification of essential OS parts. So, before trying (and potentially breaking) anything, I prefer to understand how it works, what might the possible effects of modifying it be, and how to recover from unfortunate results, then decide how to proceed - based on knowledge, not based on trial and error. Since the documentation says nothing about it, I am asking in the forum.
If you do not want to use passwordless root there is a documented method
for using a dom0 prompt before applying sudo. Use that if you will.
I am aware of that method. My question is about whether passwordless root (installing the package for it) is required for the mgmt disposable or not, as the documentation is self-contradictory about that particular aspect.
I do not believe there’s special things in that qube’s private volume. You just need to create a disposable qube named “default-mgmt-dvm” based on a “full” template ( fedora-38 instead of fedora-38-minimal ) and that’s all.
I personally think you have reached somewhere that hardly anyone has explored before. So there might not be immediate and comprehensive answer to your question.
As for this, there’s no contradiction in the doc. For a minimal template ( without any preconditon ), you can choose whether to install qubes-core-agent-passwordless-root. But a bare minimal template isn’t enough to perform adminstrative tasks as a default-mgmt-dvm. So you’ll need qubes-core-agent-passwordless-root if you want that minimal template to be also the template of your default-mgmt-dvm.
For example, you can choose whether to install tor in a template. But if you want to connect to the onion network, tor becomes mandatory.
You just need to create a disposable qube named “default-mgmt-dvm” based on a “full” template ( fedora-38 instead of fedora-38-minimal ) and that’s all.
If that is so, why does the documentation say that for default-mgmt-dvm all that is necessary is to install 2 specific packages? Why doesn’t it say that a full template is required.
So you’ll need qubes-core-agent-passwordless-root if you want that minimal template to be also the template of your default-mgmt-dvm.
IOW, passwordless root is not a choice but an unavoidable requirement for this particular qube. Is that what you mean?
I personally think you have reached somewhere that hardly anyone has explored before. So there might not be immediate and comprehensive answer to your question.
Should that one be asked in a separate thread then?
You are right. I missed the “from scratch” part in your original post. I didn’t think you were asking for a minimal setup.
Yes.
Not really, I think. What I mean is that someone has to dig for the info, and it’s unreliable to wait for some random person to do this for you. Please, if you would like, dig the info yourself. Probably by looking through the source code.
Thanks. I guess this clarifies question 3.
I am not asking anyone to dig into source code for me (or vice versa). It is a Sisyphean effort to look for answers this way, especially in the particular case. I think I will try a separate thread. Maybe someone would know.
Do I understand correctly that in 4.2 default-mgmt-dvm is no longer necessary and it safe to delete it?
No - what make you think so?
Or better, “necessary” for what?
What do you mean by “safe” in this context?
Other than removing dom0, you are free to remove any qube or
package.
It’s still used for, at minimum, qvm-console-dispvm, but no other usages come to mind right now.
Edit: oh and the “Plan B” or “Paranoid mode” backup restore function, though that one is partially broken anyway (can be made to work, however…issue being tracked here).
No - what make you think so?
The new way updates run (I don’t see any dispVMs created on the fly as before).
Or better, “necessary” for what?
For updates.
What do you mean by “safe” in this context?
As in “not used, therefore unnecessary, therefore safe to remove”. But from your words I understand that is not the case.
Still, I wonder how exactly it is used as I have never seen it (or any derivatives of it) start since I upgraded to 4.2. What can you say about that?
The new way updates run (I don’t see any dispVMs created on the fly as before).
This is very strange. When the GUI tool, Qubes Update, is used - the above is true. However, if I use the command line Salt formulas, given in the docs, dispVMs get created and started like in 4.1.