nrgaway claimed T373: Qubes templates: graphical updater (Apper) broken.
nrgaway added a comment to T373: Qubes templates: graphical updater (Apper) broken.
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.
nrgaway added a comment to T162: qubes-whonix handling of /etc/timezone and /etc/localtime.
nrgaway added a comment to T395: integrate whonix-firewall-plugin.sh into whonix-gw-firewall.
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.
nrgaway added a comment to T384: disable qubes.SetDateTime / qubes.SyncNtpClock in Qubes-Whonix VMs.
I did have a look at the software over the weekend, which BTW is GNU GPL v3 licensed.
nrgaway added a comment to T371: improve whonixcheck output in Qubes.
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?
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."
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.
nrgaway added a comment to T351: let qubes-whonix master branch reflect latest commits.
nrgaway added a comment to T170: check Qubes build script for apt-get update network / gpg failure security issues.
nrgaway added a comment to T366: cover Qubes specific steps in advice by whonixcheck.
Do you mean TemplateVM or dom0.
nrgaway added a comment to T338: make tb-updater installation path configurable / change default installation directory to ~/.tb.
I will revert the change for now by adding a comment to the configuration file that sets the path.
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.
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.
nrgaway added a comment to T248: whonixcheck workaround can be removed in qubes-whonix 10.
since I was still getting those errors in Whonix 10.
Could you just not change the apparmor-profile?
nrgaway added a comment to T344: whonix_firewall should add the --wait option to iptables statements.
nrgaway added a comment to T288: Qubes Whonix 10 - Testing Instructions and Issues.
nrgaway changed the status of T170: check Qubes build script for apt-get update network / gpg failure security issues from Open to Review.
The Qubes build script will fail the install of the template if any apt-get errors are returned.
nrgaway lowered the priority of T162: qubes-whonix handling of /etc/timezone and /etc/localtime from Normal to Low.
nrgaway lowered the priority of T173: triggers interest-noawait /etc/resolv.conf will probably not work from Normal to Low.
nrgaway closed T177: remove duplicate ipv4 forwarding disable as Resolved.
nrgaway closed T184: Add missing docstrings to Python classes and methods as Resolved.
nrgaway created T344: whonix_firewall should add the --wait option to iptables statements.
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.
So user data will also be in ~/bin? Doesn't this require user user having write access to ~/bin?
nrgaway added a comment to T337: install Tor Browser by default in Qubes-Whonix.
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 start it as user; never usually start a program as root.
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.
nrgaway added a comment to T315: disable rads, whonix-initializer and swap-file-creator systemd unit files in qubes-whonix.
I don't consider enable SystemdUnit hacks if there are no other deb-installer solutions to ensure a proper state.
nrgaway added a comment to T322: obfsproxy not working on Qubes R3.
Thanks for all the info. I will test it out over the weekend!
nrgaway created T322: obfsproxy not working on Qubes R3.
nrgaway added a comment to T316: systemd units are not enabled by default.
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?
nrgaway added a comment to T312: /etc/systemd/system/unit.service.d vs /lib/systemd/system/unit.service.d.
My understanding is distribution package file go in /lib/systemd/system.
nrgaway added a comment to T300: replace timesync progress bar by tray icon sdwdate-gui.
Let me know when you start this.
nrgaway closed T233: qubes-whonix update issue because of bug in whonix-setup-wizard / whonix_repository as Resolved.
nrgaway added a comment to T233: qubes-whonix update issue because of bug in whonix-setup-wizard / whonix_repository.
nrgaway closed T247: qubes-whonix 10 ./whonix_build command needs to be updated for Whonix 10 as Resolved.
nrgaway closed T275: Qubes Whonix 9.6.9 and 10.0.5 is ready as Resolved.
nrgaway added a comment to T295: Speedup Whonix 11 build time.
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.
nrgaway closed T278: building Whonix11 for qubes-whonix: Package installation errors as Resolved.
nrgaway closed T278: building Whonix11 for qubes-whonix: Package installation errors, a subtask of T273: control-port-filter-python.service exits pre-maturely, as Resolved.
nrgaway added a comment to T278: building Whonix11 for qubes-whonix: Package installation errors.
nrgaway reopened T298: add --target qubes as "Open".
nrgaway reopened T298: add --target qubes, a subtask of T296: disable kde power management in VMs, as Open.
nrgaway added a comment to T298: add --target qubes.
nrgaway added a comment to T274: control-port-filter-proxy sd_notify support.
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.
nrgaway added a comment to T306: rads skip mechanism.
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.
nrgaway added a comment to T304: systemd unit file for Tor package?.
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.
nrgaway created T295: Speedup Whonix 11 build time.
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.
nrgaway created T293: Maybe document Whonix services boot process.
Should prevent installation of that package.
I was able to identify all the issue that prevented complete and successful build.
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.
nrgaway closed T176: use GATEWAY_IPv4_DROP_INVALID_INCOMING_PACKAGES_POST_HOOK instead of editing /usr/bin/whonix_firewall as Resolved.
nrgaway renamed T275: Qubes Whonix 9.6.9 and 10.0.5 is ready from Qubes Whonix 9.6.8 and 10.0.5 is ready to Qubes Whonix 9.6.9 and 10.0.5 is ready.
nrgaway created T288: Qubes Whonix 10 - Testing Instructions and Issues.
nrgaway added a comment to T275: Qubes Whonix 9.6.9 and 10.0.5 is ready.
Thanks, tests are successful for me.
@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.
nrgaway renamed T275: Qubes Whonix 9.6.9 and 10.0.5 is ready from Qubes Whonix 9.6.8 and 10.0.4 is ready to Qubes Whonix 9.6.8 and 10.0.5 is ready.