I am still working on this. I spent 3 days on it a few weeks ago. I ended up reviewing the source code of many packages, and did a short audit on packagekit and gnome-packagekit to find ways to resolve issue.
Aug 19 2015
Aug 15 2015
Go nuts at it ;)
Aug 12 2015
It would be nice to eliminate anything that is not Qubes specific in qubes-whonix pacakge completely, or as much as possible. Anything you can take out of it by intergrating into Whonix would be a good thing.
Aug 7 2015
I am pretty sure that is a yes too :)
Jul 14 2015
I did have a look at the software over the weekend, which BTW is GNU GPL v3 licensed.
Jul 10 2015
I will have to take a look at the current source of software-center and play around with it a bit to be able to provide that answer. I will look into it this weekend :)
Jul 5 2015
Does for me:
qubesdb-read /qubes-vm-type ->TemplateVM
I agree inventing a new gui updater is not ideal.
I don't know if I understand the question. Are you trying to read from another VM from the one you are currently in?
From the VM the script is currently running in.
For example, if your are in the Whonix Gateway ProxyVM, are you trying to read something from the TemplateVM?
I'll rephrase question ...:
some script running inside an some AppVM and asks: "Am I a TemplateVM or StandaloneVM?"
qubesdb-read: replies "You are a TemplateVM."
or qubesdb-read: replies "You are a StandaloneVM."
Jul 4 2015
Or what about writing some utility, maybe even part of a wrapper that verifies the source.list sources first?
There are two technical questions still open. I'll restate/clarify those.
 Is it possible to read from within a script if it is running within a StandaloneVM or TemplateBasedVM using qubesdb-read or so? I mean something like qubesdb-read /standalone -> yes, no or qubesdb-read /template-based -> yes, no.
I have not tested it lately, but the same goes for the regular Debian templates ... sort of.
Yes to all the questions
Jul 1 2015
I replied to comments in the Qubes ML thread you created :)
Jun 30 2015
I see your point.
Jun 28 2015
Do you mean TemplateVM or dom0.
Jun 24 2015
Jun 23 2015
I will revert the change for now by adding a comment to the configuration file that sets the path.
Jun 19 2015
I can revert to use original path although if talking about 'reasonable expectations for uniform default behaviour' and wanting to keep all the Whonix variations similar we may want to consider changing the path for all the other versions as well then since the /home/user/opt is the proper and defacto standard location path to install pre-built personal/private binary applications that are not XDG aware.
Jun 15 2015
What ya mean? Is it causing issues? In following standards or defacto standards the ~/opt directory is the correct spot to place pre-built packages that do not adhere to XDG specs.
Jun 11 2015
Its now in etc/whonix.d/40_qubes:WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="1"
since I was still getting those errors in Whonix 10.
Jun 7 2015
Could you just not change the apparmor-profile?
Works well, thank you.
Jun 6 2015
Your PR will not merge as I made too many changes today. I already changed the qubes-whonix code to use --wait (https://github.com/nrgaway/qubes-whonix/blob/Whonix11/usr/lib/qubes-whonix/init/whonix-firewall-plugin.sh
- Error when attempting to update in Whonix 10
The Qubes build script will fail the install of the template if any apt-get errors are returned.
Just happened again when booting... I have to to detect it now
Jun 5 2015
I think an option make more sense, so as not to confuse existing users on other platforms like virtualbox. I personally do not like any non standard directory within ~/home/user unless its a .hidden directory.
Jun 4 2015
I tried to use a systemd drop in snippet but it did not work for ifup@.service.
The only reason is since I was under impression the file will be downloaded and may fail, compared to downloading the file initially and knowing it won't fail since the file is already in local repo directory.
I currently have it tied into the GATEWAY_IPv4_DROP_INVALID_INCOMING_PACKAGES_POST_HOOK hook.
I start it as user; never usually start a program as root.
Jun 3 2015
You just place it in the ~/bin directory. That's where all of my 'personal' binaries go that are not part of a package.
It should fail as the build would not be complete.
I noticed tor-browser installs in the root of the users home directory.
May 31 2015
Currently Setup is run differently for the Template vs an AppVM.
May 26 2015
I don't consider enable SystemdUnit hacks if there are no other deb-installer solutions to ensure a proper state.
May 22 2015
Thanks for all the info. I will test it out over the weekend!
@Patrick I was wondering if this is working in regular Whonix 10? If so can you give me some clues on how to troubleshoot it (startup scripts, configuration locations, expected firewall rules) since I have never used it before
May 21 2015
I guess just not using spaces would be the way to go. I used to not use spaces, but then added them as it seems like that should be supported and works with systemd, just not the deb-systemd-helper
May 20 2015
That's a nasty upstream bug for deb-systemd-helper. You would have thought that would have been fixed for Jessie stable release. Do you know if there is a reported issue on it upstream?
May 18 2015
Those are already disabled. As well, I have already created a systemd rule for whonix-initializer and just created one for swap-file-creator. As stated I have the rads one already from your PR
May 17 2015
My understanding is distribution package file go in /lib/systemd/system.
May 16 2015
Let me know when you start this.
Resolved with qubes-whonix unreleased 9.6.9 and 10
Marek says he sees improvement. I may too; its hard to tell at this point; need a few more dozen builds to get a better idea.
No longer an issue with 188.8.131.52.4-developers-only
With --target qubes I get following error:
May 15 2015
I be testing it soon. Looks like only new options are --unsafe-io true and --target qubes
Difficult question. I am debating with myself. The normal case should be no daemons crashing. If they do crash. something is very wrong that we should apply a-real-fix (tm) to, no? On the other hand, If the service was crashing due to some hypothetical parsing issue, I would actually prefer the affected user noticing and reporting an issue. An automatically restarted service with no one noticing because of the auto restart would be bad. The daemon is very stable at this preset. How much code would be added by implementing the sd_notify protocol? A reason against would be if it's getting complexer so we actually understand it less. If it's just a few lines, that doesn't apply.
I have already reviewed your PRs and there is nothing I can see to prevent build errors and I have also merged them into a test branch I am using for building this weekend. Will merge into master once everything confirmed working.
The qubes-whonix-tor.service was implemented to solve the issue you were talking about where Tor would sometimes not start properly on boot.
sd_notify would be used if you want to have watchdog monitor the service. If the service does not respond within X amount of seconds (IE did not send a notification it was still active within this time period), then systemd would then restart the service.
May 10 2015
May 3 2015
- HOW TO RE-INSTALL qubes-whonix
May 2 2015
Your instructions sound good. I recommend to hit the edit button for instruction posts and to copy it over to the wiki https://www.whonix.org/wiki/Qubes/Upgrade_from_9_to_10 or so. Unfortunately, phabricator uses markdown and mediawiki uses mediawiki syntax.
Is the 184.108.40.206.7-developers-only tag supposed to be available? While most submodules are cloning properly, I get this error:
May 1 2015
skippable package installation:
On Whonix 10, all packages installed in build-steps.d/1700_install-packages by pkg-install-maybe (as opposed of being installed as part of a dependency) are skippable through the whonix_build_script_skip_package_install environment variable. Example:whonix_build_script_skip_package_install+=" anon-shared-build-fix-grub " export whonix_build_script_skip_package_install
Should prevent installation of that package.
I was able to identify all the issue that prevented complete and successful build.
- What to do if you ran a apt-get dist-upgrade not using the upgrade method above
Yes. Done, migrated (copied) qubes-whonix 10.0.5-1 from developers to testers repository.
Want to post a blog post? Otherwise I guess very few will notice these instructions. Got a blog account already?
I am not sure it's wise telling testers to enable the developers repository. That could break badly at some point. The developers repository is a playground for me to upload and install from packages where I am not 100% certain they are not going to break the package manager.
I have been about to get Whonix 11 to successfully build using the 220.127.116.11.1-developers-only tag (since submodules seemed broken on master branch), although the build process kept asking for input starting at line 450 of 1700_install-packages and all the way until it exited. I just kept entering c manually since by that stage everything had already been installed:# 1700_install-packages:450 --> "$WHONIX_SOURCE_HELP_STEPS_FOLDER/remove-local-temp-apt-repo" INFO: Setting... export UWT_DEV_PASSTHROUGH="1" INFO: Variable anon_dist_build_version was already set to: 18.104.22.168.1 /home/user/Whonix/help-steps/pre: line 20: error_: command not found ... + true 'INFO: Currently running script: /home/user/Whonix/help-steps/unprevent-daemons-from-starting ' + true 'INFO: Currently running script: /home/user/Whonix/help-steps/unchroot-raw ' + true 'INFO: Skipping script, because ANON_BUILD_INSTALL_TO_ROOT=1: /home/user/Whonix/help-steps/unmount-raw' + true 'INFO: Currently running script: ././build-steps.d/2300_run-chroot-scripts-post-d '
Apr 30 2015
- Testers Update instructions
Thanks, tests are successful for me.
Apr 29 2015
@Patrick, I created a new version that hopefully solves the control-port-filter-python not re-enabling properly... I had a typo in the maintainers postinst configuration file.
Maybe you want to give an upgrade a try. The required qubes package is now also in the ITL test repo so you should be able to attempt an update. DO NOT FORGET TO BACKUP (CLONE) your existing whonix proxy :)