Marek just announced Qubes have added the experimental Whonix templates to the community repo to which allows installation in a few steps instead of needing to build from source. [url=https://groups.google.com/forum/#!topic/qubes-users/X0GvIdpQtcM]Redirecting to Google Groups
[quote=““Marek Marczykowski-Górecki””]Hi all,
I’ve just uploaded two new templates:
whonix-gateway-experimental
whonix-workstation-experimental
This made Whonix easily available in Qubes, without need of many manual
steps. All the code is already in my main git repositories. Of course
you can also build the template yourself. There is prepared config for
that in qubes-builder/example-configs/whonix.conf.
You can install them by calling in dom0:
sudo qubes-dom0-update --enablerepo=qubes-templates-community
qubes-template-whonix-gateway-experimental
qubes-template-whonix-workstation-experimental
Then you’ll need to create a couple of VMs:
- ProxyVM with whonix-gateway-experimental as a template
- AppVM with whonix-workstation-experimental as a template
Then set the new ProxyVM as netvm for AppVM and both templates. At first
startup there will be some simple configuration to do.
As a name suggests, this is still experimental, requires some more
testing and should not be used to serious things yet. But it is very
close to the final state.
This all was possible thanks to enormous work done by nrgaway. Thanks![/quote]
Awesome! 
A BIG personal thanks from me and the Whonix community to you, nrgaway! You rock!
I will plan on spreading this out wider to people soon.
Questions:
-
What needs to be well maintained and regularly updated in the code base for this template to stay current, secure, and functional across time (e.g. Whonix Build Version, Internal IP Routing, Firewall Rules, etc)?
-
What’s the process for future updates getting into this (I assume binary) Qubes community template? And who’s responsible for doing this? Do the Qubes devs need to build a new binary for each update, or can others somehow maintain this Qubes community template?
[quote=“WhonixQubes, post:2, topic:725”]Awesome! 
A BIG personal thanks from me and the Whonix community to you, nrgaway! You rock!
I will plan on spreading this out wider to people soon.[/quote]
Thanks! 
Questions:
-
What needs to be well maintained and regularly updated in the code base for this template to stay current, secure, and functional across time (e.g. Whonix Build Version, Internal IP Routing, Firewall Rules, etc)?
-
What’s the process for future updates getting into this (I assume binary) Qubes community template? And who’s responsible for doing this? Do the Qubes devs need to build a new binary for each update, or can others somehow maintain this Qubes community template?
There are a handful of configuration files that will need to be turned into a Debian package. I don’t have too much experience with that so I have not done that yet, but I have placed the files that need to be maintained into a structured format which I believe Debian packaging can use (including file permissions in .facl). I propose these files become part of the Whonix repos to allow others to be able to develop with them as well. Here are the actual files:
[ul][li]Gateway: https://github.com/nrgaway/linux-template-builder/tree/wheezy/scripts_debian/wheezy%2Bwhonix-gateway/files[/li]
[li]Workstation: https://github.com/nrgaway/linux-template-builder/tree/wheezy/scripts_debian/wheezy%2Bwhonix-workstation/files[/li][/ul]
Once these files are in a Debian package the Qubes templates can be updated via apt-get so any issues with the Qubes related implementation could be updated before a Whonix release, like the ‘arm’ issue.
If Whonix provides updates to it’s newest versions via the repo, then Qubes can also be updated the same way then; making sure its package specific Debian package is also ready for release as well. As for the major upgrades where it is not possible to upgrade using the repo, then a new template would need to be created by Qubes team.
Awesome! Good work!
Packaging should be simple due to generic packaging. (GitHub - Kicksecure/dist-base-files: base files for distributions - several important miscellaneous files, such as /etc/hostname, /etc/hosts, /var/lib/dbus/machine-id and more) Just look at some generally packaged Whonix package and mimic that. And if all cords break, I can do that myself since it’s not that much work. When you’re ready for that discussion, please open a new thread, because I will have some questions and comments first.
[quote=“nrgaway, post:3, topic:725”]There are a handful of configuration files that will need to be turned into a Debian package. I don’t have too much experience with that so I have not done that yet, but I have placed the files that need to be maintained into a structured format which I believe Debian packaging can use (including file permissions in .facl). I propose these files become part of the Whonix repos to allow others to be able to develop with them as well. Here are the actual files:
[ul][li]Gateway: https://github.com/nrgaway/linux-template-builder/tree/wheezy/scripts_debian/wheezy%2Bwhonix-gateway/files[/li]
[li]Workstation: https://github.com/nrgaway/linux-template-builder/tree/wheezy/scripts_debian/wheezy%2Bwhonix-workstation/files[/li][/ul][/quote]
Yes! Great idea. I second this.
[quote=“nrgaway, post:3, topic:725”]Once these files are in a Debian package the Qubes templates can be updated via apt-get so any issues with the Qubes related implementation could be updated before a Whonix release, like the ‘arm’ issue.
If Whonix provides updates to it’s newest versions via the repo, then Qubes can also be updated the same way then; making sure its package specific Debian package is also ready for release as well. As for the major upgrades where it is not possible to upgrade using the repo, then a new template would need to be created by Qubes team.[/quote]
Perfect! This Debian Apt package integration to the Whonix repos for the nrgaway Whonix files is a great way to go.
I can see how this way would help all around, with User source builds, User template upgrades, Qubes team template maintenance, and Whonix team development.
