I guess if we want to Do This The Right Way (TM), we also should support users who wish to use multiple Whonix-Workstations.
Any suggestion how we do that?
Why don’t we let the user choose a name for the VMs and image names instead? Why attempt to autodetect it? We could default to Whonix-Gateway / Whonix-Workstation if user presses enter. And those who want to use a qemu Whonix-Gateway, simply import it again and name it “Whonix-Gateway qemu”. And those who want a second Whonix-Workstation just import it again and choose “ws2” as name.
Yes I definitely agree.
I had a design in mind that addresses the issues you bring up and is much more flexible but will require a radical rewrite and departure from the way we are doing things at the moment. Its much better to avoid hardcoded paths and settings as much as possible in order to keep this extendable. Now I don’t know much to determine if this is possible or a nightmare of complexity, for that I need your opinion.If you decide to go down that route even if it takes longer, there is no rush as long as we get this right and keep it open to future improvements in a way as easy as possible.
The perceived advantages will be discussed below in more detail after the sequence diagram.
[code]1. Script choose mode →
-
If GUI chosen check for dep.
a) if not present prompt: Your system does not appear to have the necessary packages to allow a script based GUI, please install any of the following and re-launch the script in this mode: zenity, yad, kdialog, gxmessage, xmessage [whatever else you want to inlcude here];
b) would take them back to [1] to choose another interface.
-
#Security warning#:
IMPORTANT: As a security precaution you are advised to shutdown any running Whonix instance currently attached to the internal virtual network. This is required to prevent cross contamination of the new machines being imported now, in the event that a powerful adversary has taken control over the ones in use.
Note: This is not required if you intend to create a new virtual network for the machines you are importing now.
[As an aside: This should be warned of at least in documentation somewhere for Virtualbox since it imports and adds new machines to the any internal network with the same name.]
- parallel variable settings panel that will allow the configuration of numerous settings. can be expanded over time for higher control over vm settings:
$path of image to work on !By default current dir
$path of xml !By default current dir
$name of xml
$vm name
$disk img name !Must be equivalent to name specified in $path of image whatever that is
$virtual net name !Default set to ‘Whonix’
$container type
$architecture ! Next to this option specify that its qemu only like this: (QEMU only)
Each variable can be arbitrarily set by the user with the exception of a few things that must be the same as specified. sed could replace the content in between the xml tag category in question and doesn’t have to find and replace a specific (hardcoded) expression.
- If duplicate detected in these variables only: img name in destination dir., vm name then prompt for
Dulicate domain vm name:
#Domain Duplicate Detected#
The current domain name is already in use. Please go back and change it to something else.
a) This is the only option provided in the event that a dupe domain is detected from virsh output. This check should precede the dupe checks that follow it and is a necessary condition to continue beyond that point.
*** Step placeholder here
img name overwrite dialogue:
#Image Overwrite#
A disk image with the same name currently exists in the destination directory. Would you like to overwrite it?
a) proceed to [6] Import
b) return to [4] to allow changing of img name
(***) at this point when attempting to register the virtual network, virsh will complain that there is a duplicate in that name. We should assume that the user made a conscious decision to choose this vnet to connect their machines to, and shoud therefore not change anything and silently discard he warning.
- Import[/code]
Perceived Advantages:
- This could potentially be done in one script that the user would run twice once for the gw and once for the ws. Or two copies of the script one with each machine could be supplied for those who only want to download one machine or the other.
- It allows the user much more freedom to customize the machine name and settings during the import process to conventions that suit them.
- Allows the bypassing of the whole current mess of arbitrarily naming the file & machine according to settings selected.
- This technique may be extended to allow more fine grained control over settings, for example amount of RAM devices attached etc.
- Allows a multiple workstations scenario
Should you choose it, this could be developed as to become a mainstream solution for seamless vm importing in libvirt. Minus the Whonix specific warnings this could be used generically for any vm and so could be offered for packaging in distro repos.
A simpler export script counterpart could be achieved, one that converts and sanitizes problematic xml tags in a machines configuration. This could be the xml of either an original or cloned machine. A user would need to only run this cleanup routine on a machine’s xml file to prepare it for proper portability. This would mimic the sanitization steps outlined on StackExchange but in an automated way for machine and network config files.