Information
ID: 456
PHID: PHID-TASK-wbd5d6aug3dwpysfvz3k
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal
Description
@bnvk suggested to shrink various #whonixcheck error messages. For example…
[ERROR] [whonixcheck] Tor Bootstrap Result:
Whonixcheck gave up waiting after 120 seconds.
Tor Circuit: established
Bootstrapping 5 % done. Tor reports: NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY=“Done”
Possible issues:
Is the host’s internet connection working?
Whonix-Gateway will need a few moments for bootstrapping the Tor network.
Do you live in a censored area?
Recommendations:
1.)
Shut down Whonix and try to get the Tor Browser Bundle from https://www.torproject.org
working on your host. If you cannot get the Tor Browser Bundle to work, you will most certainly not get Whonix to work either.
The Tor Browser Bundle is great for testing if you live in a censored area. If you need bridges for the Tor Browser Bundle,
you will need them for Whonix as well.
2.)
Try again: dom0 → Start Menu → ServiceVM: sys-whonix → Whonix Check
or in Terminal: whonixcheck
or in Terminal with debugging: whonixcheck --debug --verbose
3.)
Use arm, connection page two, to see if Tor is connected:
dom0 → Start Menu → ServiceVM: sys-whonix → Arm
or in Terminal: arm
to remove “after 120 seconds”
to have a Details
button that expands upon click
to have a More Help
button that opens a help file
This requires #msgcollector , namely msgdispatcher_dispatch_x (written in #python ) modifications.
Comments
joysn1980
2017-01-24 10:41:29 UTC
Another old task
msgcollector/usr/lib/msgcollector/msgdispatcher_dispatch_x at master · joysn/msgcollector · GitHub
Major Change was done
Using QMessageBox instead of QDialog
Reason :- MessageBox easily supports extensible text (Showdetails/Hide Details)
Using own QMessageBox on top of QMessageBox to reset the size of the message box
Use the default icons for Info/Warn/Error instead of /usr/share/icons/oxygen/64x64/status/
User can still supply its own icon and use it.
Please review
Standalone testing can be done using
./msgdispatcher_dispatch_x ‘info’ ‘title’ ‘[INFO] [whonixcheck] Tor Bootstrap Result:’ 0
./msgdispatcher_dispatch_x ‘info’ ‘title’ ‘[INFO] [whonixcheck] Tor Bootstrap Result:’ 1
./msgdispatcher_dispatch_x ‘error’ ‘title’ ‘[ERROR] [whonixcheck] Tor Bootstrap Result:’ 0
./msgdispatcher_dispatch_x ‘warning’ ‘title’ ‘[ERROR] [whonixcheck] Tor Bootstrap Result:’ 0
I have also tested it by putting it in /usr/lib/msgcollector/
Works fine. Couple of screen shots
{F109727}
{F109724}
Patrick
2017-01-24 13:15:47 UTC
This is mostly a #usability question. Wondering if better to only have a Show Details
button or to have both, a Show Details
and More Help
button. How can we make such error messages most helpful for the user?
What about this…
Main (the usual as of before this ticket) popup:
[ERROR] [whonixcheck] Tor Bootstrap Result:
Whonixcheck gave up waiting.
Possible issues:
Is the host’s internet connection working?
Whonix-Gateway will need a few moments for bootstrapping the Tor network.
Do you live in a censored area?
Recommendations:
1.)
Try again: dom0 → Start Menu → ServiceVM: sys-whonix → Whonix Check
2.)
See More Help button for more help.
More Help
:
Shut down Whonix and try to get the Tor Browser Bundle from https://www.torproject.org working on your host. If you cannot get the Tor Browser Bundle to work, you will most certainly not get Whonix to work either.
The Tor Browser Bundle is great for testing if you live in a censored area. If you need bridges for the Tor Browser Bundle, you will need them for Whonix as well.
Technical details
:
Tor Circuit: established
Bootstrapping 5 % done. Tor reports: NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"
You could try re-running whonixcheck in Terminal:
whonixcheck
Use arm, connection page two, to see if Tor is connected:
dom0 -> Start Menu -> ServiceVM: sys-whonix -> Arm
or in Terminal: arm
Check /var/run/tor/log
Any opinions? Any other proposals?
joysn1980
2017-01-28 03:13:33 UTC
The issue here is that - msgdispatcher_dispatch_x is a generic script, which displays the message that comes to it.
Now, the question is - what is the best way to find out a generic way to split a message into the below three parts
Part that comes inside message being displayed
Part that comes inside 'Show Details"
Part that comes inside ‘More Help’
What I did was to modify this script to find a generic way to split the message into such a way that we have two parts -
Part that is displayed by default
Part that is comes with “Show Details”
Now, coming to your proposal. Why do you think you should differentiate between “Details” and “more help”. Don’t you think there is no line between them? After all
Now, the question is how do we implement your proposal. I think it is a much larger change.
We need to formalize all message so that we have 3 parts to it.
a) Default Message
b) Details
c) More Help
And this should be done to all the messages.
Once done, we can probably implement that too.
Personally I feel that there is very hazy line between “Details” and “More Help”. It is not very intuitive to tell what comes under what category. “Details” is all about “More”. My 2 cents.
Let me know what you think about refurbishing all the messages that is being used by “msgdispatcher_dispatch_x”?
Patrick
2017-01-28 15:57:54 UTC
! In T456#11896, @joysn1980 wrote:
The issue here is that - msgdispatcher_dispatch_x is a generic script, which displays the message that comes to it.
Now, the question is - what is the best way to find out a generic way to split a message into the below three parts
Part that comes inside message being displayed
Part that comes inside 'Show Details"
Part that comes inside ‘More Help’
The calling script (such as whonixcheck) would pass that by command line option, such as --message "this message"
, --details "these details"
, "--mhelp "more help"
. Or if that does not work well, pass it by environment variables.
Why do you think you should differentiate between “Details” and “more help”.
Details are more like technical details. Interesting for advanced users, developers and for bug reports.
Don’t you think there is no line between them?
While writing these help messages and gathering output for it, it’s hard to think about lines between them. So the calling script (such as whonixcheck) would define which part goes where and then pass it to msgdispatcher_dispatch_x.
Personally I feel that there is very hazy line between “Details” and “More Help”. It is not very intuitive to tell what comes under what category. “Details” is all about “More”. My 2 cents.
Yes, sure. Perhaps all error messages and help advice should be in the main popup and only technical details being hidden under the details button.