[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Whonix 14 / Qubes 3.2 Testing Thread

Development
#1

Whonix 14 will support both Qubes 3.2 & 4.0. (ref)

To test Whonix-14 on Qubes 3.2 choose:

  1. Install from unstable repo:
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-ws
  1. Upgrade existing Whonix-13 templates:
    https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14
Invalid instructions

How to Test Whonix 14 on Qubes 3.2

get rpm signing keys

any vm with connectivity:

curl --proto =https --tlsv1.2 -O https://raw.githubusercontent.com/QubesOS/qubes-installer-qubes-os/master/qubes-release/RPM-GPG-KEY-qubes-4-templates-community

dom0:

qvm-run --pass-io <src-vm> 'cat /path/to/RPM-GPG-KEY-qubes-4-templates-community' > /home/user/RPM-GPG-KEY-qubes-4-templates-community

sudo cp ~/RPM-GPG-KEY-qubes-4-templates-community /etc/pki/rpm-gpg/

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-templates-community

edit yum repos

dom0:
sudo vi /etc/yum.repos.d/qubes-templates.repos

in [qubes-templates-community] section, change baseurl to:
http://yum.qubes-os.org/r4.0/templates-community

after you download the templates, you can change r4.0 back to r$releasever

remove existing whonix templates

sudo yum remove qubes-template-whonix-{gw,ws}

install new templates

sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-whonix-{gw,ws}

update templates

create appvms

#2

Testing Checklist (Upgrade Path)

https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14

watch journalctl for errors

sudo journalctl -f

test components with --verbose settings

(whonix-gw, whonix-ws, sys-whonix, anon-whonix)

boot: pass
networking: route, iptables, netstat
updates-proxy: can’t test - missing dom0 updates
control port filter
whonixcheck
sdwdate
dispVM
tor
torbrowser
applications
…

2 Likes
#3

upgrade notes

https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14

Instructions do not produce any errors.

Konsole crashes when attempting to save output. (Signal: Segmentation fault (11))

Should the Salt scripts be run for users on 3.2 or only after upgrading to R4? Answer: Yes, for all.

And will those changes play nicely with existing Whonix 13 VMs?

I can take a look but can’t find them…
salt management scripts are in Qubes/qubes-mgmt-salt-dom0-virtual-machines repo.

1 Like
#4

Yes.

#5

Won’t these salt scripts be problematic for users with non-standard Whonix VM names? whonix-gw, sys-whonix, whonix-ws, anon-whonix seem to be hardcoded?

I see instructions have steps for updating qubes.UpdatesProxy for differently named VMs. Not sure what anon-whonix.sls does but sys-whonix and whonix-ws-dvm may not exist on existing 3.2 systems.

Simple GUI would be useful for managing qubes.UpdatesProxy. @iry Would go in Dom0 / System Tools: Whonix Update Manager
Which templates would you like to update through Whonix?
Which whonix gateway VM would you like to use to update?
Use clearnet or onion repos? (currently both are used)

Not a fan of GUI everything but this is something most users will probably have to deal with. Lots of syntax errors bound to happen.

Can’t qubes.UpdatesProxy be set automatically by Global UpdateVM settings? (maybe that setting doesn’t exist in R4?)

2 Likes
#6

You have to manually replicate what salt does.

Now you’ll probably ask, what does salt do. :slight_smile: Good question.

Can you read all files matching whonix on https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/ and ending with the .sls extension?

What salt does has just now been documented by me. But for Qubes R4.

https://www.whonix.org/wiki/Dev/Qubes#salt

For Qubes R3.2 slightly different.

https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/tree/release3.2/qvm

Yes, so it will be an issue documenting. When you create a VM based on whonix-ws, then it will probably inherit the tag anon-vm. Could you verify please?

But what when cloning a Whonix TemplateVM?

  • When you upgrade a pre-R4 released Whonix template, it might not have the tag anon-vm. So the cloned would not have either. So it needs to be manually set.
  • And when you start with a new R4 installation and clone it, gets to tag anon-vm inherited? Could you verify please?

Yes, currently not easy.

Not that I know. NetVM is set to none which will certainly confuse lots of users. That looks strange in qubes-vm-settings. Next to NetVM perhaps there should be a field UpdateVM next to the NetVM setting in qubes-vm-settings, which would define i.e. configure /etc/qubes-rpc/policy/qubes.UpdatesProxy?

Global Qubes VM setting UpdateVM as far as I know only configures what dom0 shall use.

2 Likes
#7

https://github.com/QubesOS/qubes-issues/issues/3412

#8

Hi @entr0py !

I would like to confirm if you are proposing a potentially useful GUI application called Whonix Update Manager which will work in dom0 for Qubes 4 and/or later?

I can definitely look into the problem but could you and @Patrick share some insights on these two questions first:

  1. Can this problem be solved alternatively than using a GUI application nicely?
  2. How long will this GUI application be useful aproximately?

Thank you so much! :slight_smile:

1 Like
#9

https://github.com/QubesOS/qubes-issues/issues/3118

#10

It’s not clear to me users would notice there is a Qubes-Whonix Update GUI so we could still have this issue, even if an Qubes-Whonix Update GUI could make it easier to change the settings.

Would my suggestions

be solve this and avoid a Qubes-Whonix Update GUI? Or are these just complementary?

1 Like
#11

@iry Thanks for checking in. I think @Patrick’s ideas would address my usability concerns and at the same time, be more consistent with the Qubes’ UX. We should save your talents for more important projects. :slight_smile:

BTW, can anon-connection-wizard configure apt.sources to only use onion repos or clearnet repos? What’s the point of using onion repos if we’re downloading clearnet versions anyway? other than redundancy?

1 Like
#12

entr0py:

@iry Thanks for checking in. I think @Patrick’s ideas would address my usability concerns and at the same time, be more consistent with the Qubes’ UX. We should save your talents for more important projects. :slight_smile:

Great!

BTW, can anon-connection-wizard configure apt.sources to only use onion repos or clearnet repos?

No, that’s not the right tool for it. anon-connection-wizard is more
like tor-connection-wizard (did you ask about the name change @iry?) so
no unrelated features should be mixed into it.

What’s the point of using onion repos if we’re downloading clearnet versions anyway? other than redundancy?

It’s a big change. With Whonix 14 we’re doing a big scale test if these
are working stable. If it is working stable, it will be onion only for
Whonix 15.

Whonix VirtualBox 14.0.0.5.5 Testers Wanted!
#13

Hi @entr0py !

Patrick’s answer to this question is exactly what I thought. anon-connection-wizard should be (only) in charge of connecting to the Tor network.

Yes. Here is the ticket: https://trac.torproject.org/projects/tor/ticket/23632
No response received, though.

2 Likes
#15

qubes-template-whonix-*

Might not work? Try qubes-template-whonix-gw.

Could you try please…?

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-ws

And if it doesn’t work create a ticket at
https://github.com/QubesOS/qubes-issues/issues?

#17

I have several applications that had been failing to start in Whonix 14. Unsetting environmental variable XDG_CONFIG_DIRS seems to fix most of them.

TorMessenger is one such application.

CoyIM may have been another.

I am testing several communications applications in Qubes 3.2/Whonix 14. Including RetroShare, CoyIM, Ricochet, Riot.im, CoyIM, TorMessenger, etc etc

Several of these would not start, and I noticed that some were throwing segmentation fault errors. So, I found the posts about torbrowser crashing, and was able to apply the same advice.

I assume there are no security risks with unsetting this variable? It will just default to some order of searching config directories?

Any idea what is causing the crash? Directories listed that do not exist perhaps?

#18

Environment variables will be fixed after installing upgrades (just now
uploaded) as well as reboot.

1 Like
#19

To development?

I am on testers, and just upgraded (several whonix packages including whonixcheck and whonix-legacy), but after rebooting all of Qubes, I am still Seg Faulting.

I still need to unset the variable in order to run.

user@host:~$ riot-web 
Segmentation fault
user@host:~$ unset XDG_CONFIG_DIRS && riot-web 
Starting auto update with base URL: https://riot.im/download/desktop/update/
Auto update not supported on this platform
#20

Whonix 14?

Upgraded from stretch repository? developers, testers and
proposed-updates also but I don’t want users on developers.

Got whonix-legacy 4.2-1? Check:

dpkg -l | grep whonix-legacy

Your /var/lib/dpkg/info/whonix-legacy.preinst should look like this:

Most important is this part:

Is there file
/var/lib/whonix/do_once/thirteen_dot_x_to_fourteen_dot_x_version_5 or
similar?

Qubes reboot not required for sure btw. Only VM reboot required.

#21

Yes, of course.

Yes, I am on Stretch-Testers.

ii  whonix-legacy                                  3:4.2-1                                                   all          Prepare older Build Versions of Whonix for Upgrade

It does.

Got that.

Not in that location. That directory has only one file:

bind-dirs-legacy-function-version-1

rebooting Template and TemplateBassedAppVM didn’t correct issue, so I rebooted the entire machine.

This is a clean install of Whonix 14 from Qubes Repo, not an upgraded of Whonix 13. FWIW

1 Like
#22

Thanks! Good report, that helps a lot.

I think I sorted this.

Upgraded whonix-legacy package should be uploaded soon. When that happens, please upgrade. Then shutdown all Whonix VMs. Then restart the TemplateBasedVMs. (The usual process to make áą•ackage upgrades take effect in TemplateBasedVMs.) Should be fixed by then.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]