Monero Wallet/Daemon Isolation with Qubes + Whonix

my $0.02, dont forget to clone the blockchain vm.

Instead of sudo nano, I suggest using sudoedit (or gsudoedit if the default editor is graphic). The advantage is that the editor itself isn’t elevated. Only the behind the scenes mv equivalent is. It does it by copying the file, then opening the copy inside the editor. Only if changes were made does it modify the original. Otherwise it deletes the unedited copy.

Edit: Not sure how valid it is for Qubes.

2 Likes

Stupid question:
Does the blockchain sync start automatically, or do I have to enter some kind of command for that?

1 Like

Why wouldn’t it? Fom’s giant list of Qubes OS workarounds, tweaks and shenanigans - #12 by BEBF738VD (point 2)

2 Likes

Because of Qubes’ passwordless sudo business and qube isolation. I know about Qubes in a very generic novice level. Therefore I’m never sure how much something applies to it’s architecture as oppose to a plain monolithic OS. I often get surprised :sweat_smile:

I’ve always been of the opinion that the only stupid question is the one not asked :wink:

However, I’m hesitating here in this thread because I’m unsure how the mods approach a Q and A that’s not specific to Qubes. So far we’ve dealing with the challenges you face that are specific to Qubes, but your question moves us to something that’s specific to dealing with Monero daemon in general.

The short answer is no, it needs commands to start and stop it in a gentle manner. Sorry, I forgot that.

I’ll PM you with the commands, unless the mods tell me otherwise.

2 Likes

I got an update suggestion. On ArchWiki it is stated that this is the usual place to host user systemd unit files:

~/.config/systemd/user/ where the user puts their own units.

Therefore I decided to put mine there. It avoids the need for root (or sudo?) to own it. In such a setup, systemd already “knows” that the file is to be run as user. Therefore, the User and Group parameters become superfluous. In fact, I discovered the hard way they just confuse it. Of course, it means that the cp command in rc.local should be modified to this:

cp /home/user/.config/systemd/user/monerod.service /lib/systemd/user

Also, it looks like the service should be enabled. Maybe even restarted.

systemctl --user enable monerod
systemctl --user restart monerod

At the very least it helped me. The following two commands, and searching the errors on the web, helped me discover issues (including the one I mentioned):

systemctl -- user status monerod
journalctl --boot --user -f -u monerod
2 Likes

i would also like to know the commands because i was following this tutorial: How-to: Use Monero with Wallet Isolation in Qubes-Whonix ™ like @Mdogg was and now i will try to follow your guide, also thank you for the effort of writing this for all of us :smile:

2 Likes

I have trouble mining with this setup. I launch the mining daemon through the wallet with this command: start_mining 1 true true. It launches one mining thread, tells it to background-mine, and tells it to not query battery statues (which it can’t do anyway). After an hour, the log shows this message:

…[P2P9] WARNING global src/p2p/net_node.inl:2093 No incoming connections - check firewalls/routers allow port 18080

How do I solve it? Do I need to forward the port in some way?

Edit: Also, when I installed qubes 4.1 I set sys-net as a static disposable VM. I thought it may be worth mentioning.

This needs to be updated for Whonix 17 on Qubes 4.2

I had this setup working on whonix 15-16, but it is not working on Whonix 17. I want to try your solution here of using qvm-connect-tcp, however Whonix 17 no longer uses /etc/qubes-rpc/policy, so where would you setup the qubes.ConnectTCP info? In /etc/qubes/policy.d/ somewhere? It seems 30-user.policy is the only place you are supposed to edit there.

3 Likes

Qubes 4.2 is based on the new policy system. Now you must explicitly write the qrexec policy name you want to use in a policy file. For example, you could have a file here /etc/qubes/policy.d/30-user.policy with:

qubes.ConnectTCP +18081 monero-wallet @default allow target=monerod
3 Likes

Thanks! I added that and my connection worked immediately. To summarize, with Qubes 4.2 and Whonix 17 @MrA’s post should work, with the following changes @DVM gives above.

OLD Step 4 (in dom0)

NEW Step 4 (in dom0)

Edit the policy file:
sudo nano /etc/qubes/policy.d/30-user.policy

Add the following line:
qubes.ConnectTCP +18081 monero-wallet @default allow target=monerod

4 Likes

I had hopes I’d be saving myself some time, so I got around to upgrading a box to 4.2 using backups of monerod and wallet VMs moved to Whonix 17 on restore. However, despite the policy edit in dom0, monerod doesn’t want to fly. Did you use a backup for yours? @scallyob

journalctl tells me it doesn’t have /usr/bin/monerod to play with. (Guessing …) Does the edit also require a change to /qubes-rpc/user.monerod?

I reinstalled from 4.1 to 4.2 (and whonix 17) restored with qubes backup and just set the exact same policies from 4.1.

Everything works fine.

My policy is in

/etc/qubes-rpc/policy/qubes.ConnectTCP

monero-wallet-ws @default allow, target=monerod-ws

Is my current policy fine or insecure? (and future proof?)

That’s fine. It works for backward compatibility reasons, but you should use the new policy format as much as possible.

1 Like

I did an install in place from 4.1 to 4.2, then installed Whonix 17 template, made a modified one to work with my monero AppVMs and then switched that to be the template for them.

Whonix does not come with monerod installed so you do need to install it. The Whonix docs have you use flatpak, but I just manually download it from the monero project and copy the executables I need to /usr/bin/

I was checking this out as well. Is the policy stuff on the whonix wiki correct for QubesOS 4.2? Here: How-to: Use Monero with Wallet Isolation in Qubes-Whonix

It only mentions /etc/qubes-rpc/policy/user.monerod file and uses:

monero-wallet-ws monerod-ws allow

Which looks different from that of

The Whonix guide is using custom service with qrexec + socat and other is using Qubes OS service qubes.ConnectTCP:

Both are using old policy format so it’s better to change policy to the new format e.g.:

Can someone write a new guide on doing the Monero wallet, Monero daemon isolation with the new QubesOS qrexec policy architecture?