So if I have say, Firefox, open in a disposable qube and that is the only thing running in that Qube; how can I open a terminal in that Qube? I presume I need to do this with some commands from dom0 terminal?
Note the name of the disposable qube from the title bar - then just
qvm-run <name> <command> from dom0
I presume I need to do this with some commands from dom0 terminal?
You can click on the Q icon in the system tray, select your Qube of interest, and click “Run Terminal”.
Also, in i3, if the window from this VM is in focus, Meta+Enter should open the terminal for you.
A nice use-case for this is being able to open multiple documents on the same dispVM. However, there is not on-interface solution to this. Only through the terminal / through “run command in qube” as suggested.
This came up in the securedrop-workstation a while ago:
A nice use-case for this is being able to open multiple documents on
the same dispVM.
I do this all day long. This workflow  works not only for URLs but
also for files / documents.
However, there is not on-interface solution to this.
Basically you configure qubes.OpenInVM to always ask… that will
produce the dom0 dialog where you can choose the already existing
disposable qube as target.
That’s 100% pure GUI after it was setup once.
Thanks a lot for the tip. Always learning!
In the section above we’ve seen how using the ‘ask’ RPC policy allowed us to start a (disp)VM once and use it for opening subsequent URLs (or files) to avoid having to wait insane amounts of time for dispVMs to start. However this comes at the price of a loss in compartmentalization. It is thus up to the user to carefully pick destination VMs and to manage the lifecycle of dispVMs, killing it/them when necessary when a clean state is required.
@sven the way you suggest is great already. However, I’m particularly afraid of the highlighted part. I haven’t yet played too much with the RPC policies. But before digging into that, I’d like to ask you if the following is possible: having a named dispVM that is the predefined for srcVM.
That way, when the user clicked on “open in VM” (on the file manager), it would be the default target, so the user would not have to “carefully pick”.
I’d like to ask you if the following is possible: having a named
dispVM that is the predefined for srcVM.
… you mean target – right?
That way, when the user clicked on “open in VM” (on the file
manager), it would be the default target, so the user would not have
to “carefully pick”.
$anyvm $dispvm ask,default_target=my_special_dvm
Nope. I mean source VM. For example. I’d like the default dispVM to be a named one, so that it always opens attachments on that same one, without me needing to select a target (named) dispVM.
Hmmm… Perhaps we need to be a little clearer on the definitions? Is this correct?
srcVM: Part 1: The qube that contains the attachment/document to be opened (edited/viewed).
srcVM: Part 2: Also in its settings contains the Default DisposableVM Template.
Default DisposableVM Template: The template qube to use for the created dispVM (duh! ).
dispVM: The qube created on-the-fly. Also the targetVM.
@deeplow : If I understand you correctly, you would like an enhancement to change “Default DisposableVM Template” to “Default DisposableVM”, which could be either a Named dispVM or a DisposableVM Template. In the former case the Named dispVM would be (re-)used; in the latter case a new dispNNNN would be created each time, as now.
While only DisposableVM Templates are in the drop-down list in the Qubes Manager, interestingly qvm-prefs allows specifying a Named dispVM - but unfortunately it doesn’t take and actually resets the Default DisposableVM Template to None, without displaying any error - likely a bug?
@Sven : He may be asking if a set of entries is possible like:
vm1 $dispvm default_target=nameddispvm1forvm1
vm2 $dispvm default_target=nameddispvm2forvm2
Or I may just be confused!
I’m afraid my question has steered the thread into another (yet interesting direction). But the original point seems to have been addressed and this goes in a very similar direction.
Played around with it a bit and now I know what’s I’d like. I’d like to be able to set a named dispVM as the default dispVM for the
srcVM such that whenever one clicks
open in dispVM it would only boot one dispVM (the named one) and subsequent
open in dispVM would open in the same one. This would make the workflow equivalent the one detailed by @Sven but without the need for the RPC dialogue for selecting the default target qube.
Hopefully I’m explaining myself correctly.
Basically my conclusion was that it is not possible because a named dispVM is of type
DispVM and we can only select as
Default disposableVM template an
AppVM marked as
DisposableVM template. Kinda confusing…
This would make the workflow equivalent the one detailed by @Sven but
without the need for the RPC dialogue for selecting the default
Well, if you set the policy to “ask,target=my_named_dispvm” then the
dialog will come up but your named dispvm is preselected. So all you
need to do it hit the [OK] button. …that’s not quite what you wanted
but pretty close.
Yup. I think as close as we’ll get for now. Thanks again for the tip.
srcVM $dispvm allow,target=targetVM
seems to eliminate the prompt…
Of course, you’d need such a line for each srcVM…
The way I use this is to set named disposableVMs with the
qubes-shutdown-idle service configured for a short shutdown (2 mins I
I use mailcaps and mimeinfo to set opening most files in a disposableVM,
and alias “open” to “qvm-open-in-dvm”.
Because all the heavy lifting is done in
I have keyboard shortcuts to set/unset the default allow rules. That gives
me the flexibility of changing from “open files in separate disposableVM”
to “open files in the same disposableVM”.
You should be able to set this up yourself with minimal effort: if you
need help shout out.
This is it. Thanks!!
Yes, I was already thinking of doing exactly the same.
This makes me think about the possibility of dynamic RPC policies. Basically
/etc/qubes-rpc/policy/qubes.OpenInVM could be an executable file who’s output would be the the actual policy. But this is probably a topic on its own.
Thank you. If I need, I’ll ping you then.