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.
Stupid question:
Does the blockchain sync start automatically, or do I have to enter some kind of command for that?
Why wouldn’t it? Fom’s giant list of Qubes OS workarounds, tweaks and shenanigans - #12 by BEBF738VD (point 2)
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
I’ve always been of the opinion that the only stupid question is the one not asked
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.
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
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
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.
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
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
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.
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?