Monero Wallet/Daemon Isolation with Qubes + Whonix

User Support Guides
#22

UPDATE

For those members who are unfamiliar and find they need to upgrade their isolation to the latest Whonix 16:

Assumptions:

  • You’re upgrading from the Whonix 15 template you have to Whonix 16 released a few days back (rather than installing the isolation from scratch with Whonix 16).
  • You originally used the guide linked in the OP.
  • You’ve already upgraded your Whonix template to 16.
  • You’ve named your Wallet and Daemon VMs as in the guide above.
  • Both these VMs are not running in your Qubes Manager.

In Dom0 terminal

  1. Clone your whonix-ws-16 template:
    qvm-clone whonix-ws-16 whonix-ws-16-monero

  2. Move your wallet and daemon VMs to the clone:
    qvm-prefs monerod-ws template whonix-ws-16-monero

and

qvm-prefs monero-wallet-ws template whonix-ws-16-monero

  1. Complete the section 2.1 to 2.4.

Note:
In 2.2.1 and 2.2.2 change kwrite to nano and once you’ve pasted the script in each of the files, save/close them with CTRL+x.

Fire up your daemon to sync and you should be good to go.

Edit: and while you’re at it, increase the monerod-ws volume to 120Gb

#23

I had @helge’s problem as well:

I followed the Qubes documentation for opening a single TCP port to another qube, which ended up working.

Steps:

  1. Follow all the steps linked in the above github guide
  2. Do not add the socat TCP-LISTEN command to /rw/config/rc.local in the wallet VM. Instead, add qvm-connect-tcp ::18081 to rc.local (you can’t have both qvm-connect-tcp and socat bind to the same port, so I choose to forgo socat)
  3. Create a TCP connect policy in dom0: /etc/qubes-rpc/policy/qubes.ConnectTCP:
monero-wallet-ws @default allow,target=monerod-ws
  1. Run qvm-connect-tcp ::18081 in monero-wallet-ws or restart the wallet VM and let rc.local handle it

My monero wallet VM then connected to the monero daemon VM.

Please test this method to see if it works. I’m also not entirely sure why this worked, and what parts of the github guide are strictly necessary to make the qvm-connect-tcp method work. I imagine this would preserve the split-* security model because of the policy because the TCP port is only available to be used from monero-wallet-ws to monerod-ws?

2 Likes
#24

Did a fresh install of 4.1rc3 last week and had to do the tcp port like qubes-kernel-5.8 suggested.

Monerod and wallet are showing syncing, how when checking the Active: status of monerod-mainnet it shows as failed “start request repeated too quickly”. Not sure if this is the right thread but not sure what’s going on or how to troubleshoot it.

1 Like
#25

I planned to sit down and upgrade in the coming days. Did you find a cause/solution to what you mention?

#26

Hi I just finished installing monerod-ws monero-wallet-ws and syncing blockchain.
But How can I my existing wallet? where should I put wallet file in monero-wallet-ws?
Do I have to put it under same directory with monero-wallet-cli which is in /usr/local/bin?

#27

Do you mean /etc/qubes-rpc/policy/qubes.ConnectTCP or /etc/qubes-rpc/qubes.ConnectTCP?

I already have a /etc/qubes-rpc/qubes.ConnectTCP` and it says inside

"PORT="$1"
[[  -z  "$PORT"...

exit 1
fi

didn’ type whole thing, can’t paste into qube of anything now for a reason

This also does not work and when did create /etc/qubes-rpc/policy/qubes.ConnectTCP then USB does not connect. Had to delete this to get USB work.

#28

As I wrote, you want to add instructions to allow the wallet VM to talk to the daemon VM in dom0 in /etc/qubes-rpc/policy/qubes.ConnectTCP.

#29

The wallet is accessed using two files (at least that’s what’s on my system): your private key and your wallet file. You need both to access the wallet.

The easiest way to access the wallet is to keep your wallet file and key file in the same directory. Then you can run monero-wallet-cli from anywhere in the wallet VM and if you give it the absolute path to your wallet, it will find the keys in that directory as well and load the wallet.

In the case of an AppVM, you want to make sure your wallet survives reboot, so put it in any persistent directory.

#30

I didn’t have that directory or that file and when I created it I could no longer access USB qube after system boot

should use “sudo nano” and then create file in that directory or is this done wrong?

#31

What does it mean/is the issue if monerod is connected, monero wallet is connected to monerod, but monerod-mainnet is not starting?

Going to attempt to install again using tcp method.

#32

I followed the various tips here and got everything to work, however space is somewhat limited and I’m unable to fit the entire blockchain on my drive so I was thinking of running a pruned node.

I edited the monerod-mainnet.service to include --prune-blockchain and created a new daemon qube, however it still seems to be downloading the entire blockchain.

If I run sudo monerod --prune-blockchain I get two errors:

F Error starting server: Failed to bind IPv4 (set to required)
E Exception in main! Failed to initialize p2p server.

Furthermore sudo monero-blockhain-prune shows the following, despite the daemon is attempting to sync the whole blockchain.

E Blockchain is already pruned, use --copy-pruned-database to copy it anyway

Suggestions? Thanks in advance

#33

Hi guys, have had this working for a while now, although now I’m going to have to update with the newer version wallet software in the monerod and wallet VMs, how easy is it to do that?

Is it just a case of rerunning the install command and installing the newer monerod over the old one in the same location and then copying the new wallet file to the wallet VM and installing?

Do I have to worry about it trying to re-download the node?

Thanks

#34

Yes.

The wallet and config files won’t be changed / moved so there should be no need to do it.

No, it should work as it is.

1 Like
#35

Thanks for the reply

just tried to update via command line in my monerod-vm and got;

user@host:~$ monerod update download
2022-05-15 13:45:06.662	I Monero 'Oxygen Orion' (v0.17.3.0-release)
Error: Problem fetching info-- rpc_request:

probably something I’m not allowing due to the way it wrote my config during setup I guess?

Would you recommend temporarily changing my config file paramenters to allow update via command line or just doing it exactly the same way I set it up the first time and installing the new monerod right over the top of the old?

This is what I used the first time

sudo install -g staff -m 0755 -o root ~/monero-<VERSION NUMBER>/monero-blockchain-* ~/monero-<VERSION NUMBER>/monerod -t /usr/local/bin/

The wallet and config files won’t be changed / moved so there should be no need to do it.

Just to clarify a few things;

You are saying in my separate wallet VM I don’t need to replace my old wallet with the updated wallet file?

  1. Wouldn’t my wallet version in my separate wallet VM then be outdated/insecure?

  2. Finally, if I update one but not the other, is there any danger of some sort of version mismatch with my monerod in monerod-VM being a different version to my wallet in wallet-VM?

Thanks again

#36

I’d just download the new monero wallet manually. But you can try to comment out the restricted-rpc=true in your config if you have it then try to download monero wallet with monerod and return your config back afterwards.

Clarify what you mean by:

updated wallet file

Do you mean as it says - wallet file wallet.dat in ~/Monero/... directory or you mean updating your monero wallet software?
You need to update monero wallet software in both monerod-ws and in monero-wallet-ws.

#37

OK, don’t like the idea of the rpc hack around, looks a bit risky, I’ll just download it manually and then just install it over the top using the same command I used for the original setup if you don’t see a problem with that

sudo install -g staff -m 0755 -o root ~/monero-<VERSION NUMBER>/monero-blockchain-* ~/monero-<VERSION NUMBER>/monerod -t /usr/local/bin/

Sorry, I meant updating the ‘actual’ wallet program in my monero-wallet-ws VM by just copying the new wallet binaries over

Thanks for all of your help

#38

That should work just fine.

1 Like