I was wondering if you currently have any post installation triggers that you emit when Whonix has completed installing.
I suppose you mean during the build process after installation of packages by build-steps.d/1700_install-packages?
Yes, hopefully this is very well supported. For one, there is the chroot scripts mechanism, chroot-scripts-post.d, see:
Also if you look into the build-steps.d folder (https://github.com/Whonix/Whonix/tree/master/build-steps.d) you can sneak in your stuff at any point. 
I had a few issues installing the whonix-qubes package before installing Whonix gateway or workstation so I placed the installation afterwards which allows me to make sure certain services are enabled / disabled.
If you want to install a package before all others, you can either create a build step that runs before build-steps.d/1700_install-packages. But I don't think this will be needed. I guess it's best if you look here.
In this script https://github.com/Whonix/Whonix/blob/master/build-steps.d/1700_install-packages#L350 search for that line:
pkg-install-maybe anon-shared-build-apt-sources-tpo
Then add
pkg-install-maybe whonix-qubes
above it.
Should we install the package on all images by default + make sure the whonix-qubes packages only does stuff when running inside Qubes? This would make standalone VMs easier where users download qcow2 (or raw) images from whonix.org if you still want to support that use case in future. Otherwise, if it should be only installed when running withing Qubes builder, then we can easily add a [font=courier]–target qubes[/font] command line option, which sets a Qubes specific variable, that will be obeyed by build-steps.d/1700_install-packages.
(Command line parser: https://github.com/Whonix/Whonix/blob/master/help-steps/parse-cmd#L120)
I want to try to install it before Whonix again though to be able to remove custom code from the template into the whonix-qubes package that is needed just to be able to get Whonix to build thereby keeping anything Whonix related in this one package.
Okay.
This will allow you to quickly see any work arounds I needed to use so we can implement those fixes in the mainline code itself and not needing to touch the Qubes templates.
Yes, getting fixed into mainline sounds very good.
With so many packages that Whonix installs, I even wonder if there is one master package that will always be installed last to trigger the event when using the build system.
That master package would be the package whonix-gateway or whonix-workstation. But I don't think that would be a good mechanism. Custom builders might skip installation of that package. There probably much better hooks as described above.
Currently this is what has to be done after Whonix is installed. If no trigger event exists for the specific package, I can just create a trigger based on some file that gets installed or modified (most likely candidate is to watch the /etc/init.d file)
1. I need to place this file. Can it be placed before whonix begins installation?
mkdir -p /root/.whonix
touch /root/.whonix/first_run_initializer.done
You could write a build step called build-steps.d/1600_qubes that therefore runs before build-steps.d/1700_install-packages or we can reintroduce the chroot-scripts-pre.d mechanism.
2. This needs to be appended. I do not know what package it belongs to but can watch the file itself
echo 'WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="1"' >> /etc/whonix.d/30_whonixcheck_default
That should be fixed in whonixcheck that comes with Whonix 10. I think we discussed/fixed this elsewhere already but not sure. If you get this updated file for testing, it should work out of the box:
https://github.com/Whonix/whonixcheck/blob/master/usr/lib/whonixcheck/check_virtualizer#L65
As a side note, generally, when having the “.d” mechanism (Configuration Files - Kicksecure) it’s best not to touch the original file but to ship one that overrules the default setting. (Higher number named file.)
3. Need to make sure Tor is disabled. I think you may already do this though
Whonix comes with Tor disabled by default for a long time now.
“DisableNetwork 1” is set in anon-gw-anonymizer-config/usr/share/tor/tor-service-defaults-torrc.anondist at master · Whonix/anon-gw-anonymizer-config · GitHub which means “Tor do no networking at all!”. The Tor service starts upon first boot, but does nothing. That should be totally fine. The default /etc/tor/torrc comes with out commented “#DisableNetwork 0”, which does nothing by default. (anon-gw-anonymizer-config/etc/tor/torrc.anondist at master · Whonix/anon-gw-anonymizer-config · GitHub)
We then rely on whonixsetup (or whonix-setup-wizard in Whonix 10) for in commenting “DisableNetwork 0” (= enable networking) in /etc/tor/torrc.
That works for build process and first boot. But you want to disable Tor after Whonix has been started once and after “DisableNetwork 0” has been set in /etc/tor/torrc already? Because you need this for template updating or so?
4. Need to make sure sdwdate is disabled. I get many weird errors pop up otherwise stating I can't connect even though it just connected. I think the errors are cached. I re-enable both Tor and sdwdate just before whonix-setup.
Actually, sdwdate should just patiently and quietly wait as long as the Tor daemon is started but in "DisableNetwork 1" (= network disabled) mode. For hours, days, and so forth. Issues are coming if you disable the Tor daemon from starting.
Or it’s a systemd issue? I don’t know why Whonix, based on Debian wheezy in Qubes is using systemd anyhow. Sdwdate’s init script has a “# X-Start-Before: tor”, which means, Tor should start before sdwdate, so sdwdate wouldn’t run into a closed (not yet created) Tor socket.
5. Need to disable spice-vdagent since it is not needed
Hm. I see. It is weird having it installed on Qubes. I think this could be a solution:
Let's make spice-vdagent a "weak recommended package"?:
https://www.whonix.org/forum/index.php/topic,852
6. Need to disable swap-file-creator since it is not needed
swap-file-creator has to be ported to systemd anyhow. At the moment you can only disable the daemon startup or append "exit 0" to /etc/default/swap-file-creator. Would it help if there was a .d config folder to easily drop a snippet to disable it in Whonix 10?
7. Need to disable whonix-initializer as its unwanted ;)
I see. Another weird dependency. It always boils down again to package manager technical limitations:
https://www.whonix.org/wiki/Whonix_Debian_Packages#Technical_Stuff
Anyhow. Making we could split the anon-shared-packages-recommended (anon-meta-packages/debian/control at master · Whonix/anon-meta-packages · GitHub) package and the whonix-shared-packages-dependencies (anon-meta-packages/debian/control at master · Whonix/anon-meta-packages · GitHub) package.
whonix-initializer isn’t very useful for [font=arial]–target root[/font] builds anyhow.
Have some *-non-kvm-qemu-virtualbox-vmware-? package and/or *-kvm-qemu-virtualbox-vmware-? which does not depend on swap-file-creator, whonix-initializer?
So, most of the above I think I can just add watch triggers on the files themselves.
I think it's best to avoid triggers where ever possible and to find cleaner, more robust, more long term solutions.
Another idea I just had was to just build all the Whonix Debian packages but not install them with the Whonix builder. Thats what Qubes does; first all modules are created in a development chroot environment.
Then, another chroot environment is created for the template itself without needing all the build tools installed.
Interesting!
Whonix kinda support it. Just [font=arial]–target root[/font] don’t profit from it yet. For building raw images (etc.), the build dependencies are not installed inside the images. They’re only installed on the build host. But if you are using [font=arial]–target root[/font], then build dependencies are installed on the same systems as the target system (= root).
Instead I would just include every package required as a Depends or Recommend within the whonix-qubes package and when I install whonix-qubes, it will install all the Whonix packages from the repo created by the builder on the file system which then gives me more control over the process. Would this work?
Probably, yes. Would require quite some work, but sounds interesting.
https://www.whonix.org/wiki/Dev/Source_Code_Intro#Chroot_Scripts would have to be added somehow - or omitted. Or we can somehow get rid of them altogether.
I wouldn’t advice making the whonix-qubes package a jack of all trades device, though. I.e. not be 1) ship Whonix specific configs and scripts for Qubes support + 2) depend on lots of custom package selections. (That doesn’t mean, I am opposed to it! Just saying.) It would be better to split the package into 1) and for dependencies (2)) another package. Perhaps package the mainline GitHub - Whonix/anon-meta-packages better so the whonix-qubes package has to do as little as possible.
