I am experiencing the following problem with Whonix 15 (buster-proposed-updates repo enabled), specifically with whonix-ws template. Everytime I start a VM based on it, the following message appears.
###############################################################################
msgdispatcher script bug.
No panic. Nothing is broken. Just some rare condition has been hit.
Try again later. There is likely a solution for this problem.
Please see Whonix News, Whonix Blog and Whonix User Help Forum.
Please report this bug!
who_ami: user
msgdispatcher_identifier: whonixcheck
error_text: sudo --non-interactive msgdisptacher_username=ā$msgdisptacher_usernameā msgdispatcher_identifier=ā$msgdispatcher_identifierā msgdispatcher_appendix=āmessagex_doneā ā$delete_wrapperā
last exit_code: 1
###############################################################################
I run tasketās Qubes-VM-Hardening script v 0.9.3. Disabling vm-boot-protect does not change the situation.
Ok, thanks for your answer.
I updated msgcollector and the message error when I start a whonix-ws based VM is:
###############################################################################
msgdispatcher script bug.
No panic. Nothing is broken. Just some rare condition has been hit.
Try again later. There is likely a solution for this problem.
Please see Whonix News, Whonix Blog and Whonix User Help Forum.
Please report this bug!
who_ami: user
msgdisptacher_username: whonixcheck
msgdispatcher_identifier: whonixcheck
msgdispatcher_appendix:
delete_wrapper: /usr/lib/msgcollector/msgdispatcher_delete_wrapper
error_text: sudo --non-interactive msgdisptacher_username=ā$msgdisptacher_usernameā msgdispatcher_identifier=ā$msgdispatcher_identifierā msgdispatcher_appendix=āmessagex_doneā ā$delete_wrapperā
last exit_code: 1
#######################################################
Just for the record: I tried to change the template for these VMs with a whonix-ws-15 where tasketās VM-hardening script is not installed. In this case, no problems detected when a VM is started.
I got the identical error message⦠but none of my Whonix 15 templates currently have Qubes-VM-hardening installed.
And the error is not very repeatable.
At first glance, the main variables may be startup timing (race condition?) and the fact that qubes-rpc VMAuth is set to āaskā in dom0, as per the qvmh installation procedure. (I am getting VMAuth popups for sys-whonix when starting a terminal or browser for a whonix-ws based appvm, but not when starting a terminal in the whonix-ws template.)
Also, I recall using Whonix about a month ago and didnāt experience these issues.
I would prefer addressing the issues sans qvmh before troubleshooting with qvmh, but Iāll try installing it in a whonix-ws-15 clone for now to see if the error message becomes more predictable, VMAuth prompts are affected, etc.
Installing qvmh makes the error occur consistently. But I already see a probable cause in the error message: āmsgdispatcher_identifier: whonixcheck error_text: sudoā¦ā
Its my understanding that āsudoā should not be used in system or application scripts bc its a user invocation tool. The appropriate command for switching users in scripts would be āsuā (both qvmh and Qubes-VPN-Support have examples of displaying user messages via āsuā); also note its generally only workable when invoking it as root to switch to a less privileged user.
Even if this werenāt the case, scripting with sudo doesnāt appear to be compatible with this type of āvm-sudoā Qubes configuration (even though it seems fine with the permissive Qubes default config for obvious reasons).
msgdispatcher should not cause any sudoers prompt. If it does, it would require fixing its /etc/sudoers.d/ exception file. Can you try without Qubes-VM-hardening and sudo requirement only?
Also good to change exit code of delete wrapper to know if delete wrapper or sudo is failing.
sudo has a switch --noninteractive. Using this a lot in Whonix. Works great.
āsudo should not be used non-interactiveā: citation required.
Right, the VMAuth prompts come from sys-whonix, and this seems to be the result of an appvm connecting or disconnecting with the sys-whonix proxyvm. So maybe no direct relation to what whonix-ws is doing (although that is an issue in itself).
Re: su vs sudo in scripts⦠It may not matter here if you are always running sudo as root or have a sudoers.d config as you indicated. But su appears to be the convention as its usually a core command in Linux distros, while sudo may be optional on some (such as fedora). Never saw sudo in init.d/cron scripts for example, and the sudo --non-interactive option was added relatively recently in 2011. I think Qubes scripts only use su. But I digressā¦
I didnāt activate the vm-boot-protect* service after installing it, so my prediction is that it will behave the same when only sudo is reconfigured. Iāll have to test a bit more to be sure.
Update: Iām continuing to experience this msgdispatcher error with unmodified templates. The last time was today when sys-whonix displayed it when beginning template updates (sys-whonix had just started). However, the system was under a bit of stress as it was also updating dom0 and playing music at the same time.
Msgdisptcher error in sys-whonix, anon-whonix, as well as a one-time whonix.
###############################################################################
## msgdispatcher script bug.
## No panic. Nothing is broken. Just some rare condition has been hit.
## Try again later. There is likely a solution for this problem.
## Please see Whonix News, Whonix Blog and Whonix User Help Forum.
## Please report this bug!
##
## who_ami: user
##
## msgdisptacher_username: whonixcheck
## msgdispatcher_identifier: whonixcheck
## msgdispatcher_appendix:
## delete_wrapper: /usr/lib/msgcollector/msgdispatcher_delete_wrapper
##
## error_text: sudo --non-interactive msgdisptacher_username="$msgdisptacher_username" msgdispatcher_identifier="$msgdispatcher_identifier" msgdispatcher_appendix="messagex_done" "$delete_wrapper"
## last exit_code: 1
###############################################################################
The problem arose after installing Qubes-VM-hardening.
My actions for whonix-gw-15 and whonix-ws-15:
Download Qubes-VM-Hardening
cd Qubes-VM-hardening
sudo bash install
sudo bash configure-sudo-prompt
Added vm-boot-protect service (without root) for sys-whonix and anon-whonix
Also, after running anon-whonix or whonix-dispVM in dom0 from sys-whonix, an invitation is sent. The specified solution in (qubes-os .org/doc/vm-sudo/)
```
ALL ALL=NOPASSWD: /usr/sbin/virt-what
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck restart
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck start
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck stop
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck status
```
In fact, I have the same problem as the tasket described in this thread. And since the problem has not yet been resolved, it is obvious that me should not enable VMAuth and vm-boot-protect for Whonix. I think itās worth adding to the documentation that these functions are experimental for Whonix and cause errors.
Added more debugging code in Whonix developers repository (will flow to other repositories as per usual) if anyone likes to test this. Weāll now probably get an exact error message why it is failing.