I could not exactly reproduce the error. Same configuration.
The wizard is completing normally. However, after restarting sys-whonix (or more often rebooting, Qubes 4.0 being rather unstable), whonixcheck reports the following:
ERROR: Tor Config Check Result:
Your /etc/tor/torrc file contains at least one error.
(Tor exit code: 1)
Tor reports:
Dec 24 12:59:45.294 [notice] Tor 0.3.1.9 (git-df96a13e9155c7bf) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0f, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2.
Dec 24 12:59:45.294 [notice] Tor canāt help you if you use it wrong! Learn how to be safe at Tor Project | Download
Dec 24 12:59:45.294 [notice] Read configuration file ā/etc/tor/torrcā.
Dec 24 12:59:45.296 [warn] Error reading included configuration file or directory: ā/etc/torrc.dā.
Dec 24 12:59:45.296 [err] Reading config failedāsee warnings above.
Very likely because ā/etc/torrc.dā does not exist.
I have yet to read the whole discussion about this %include line, and many other issues.
I created a clean and latest proxy-vm from Whonix-14-gateway template, trying to reproduce the error, but failed. It seems @troubadour failed to reproduce it, too.
I doubt that the reason why Tor fails to starts is because āconfig has only commentsā. I also doubt this is a anon-connection-wizard specific problem.
It works like this to get the error: anon-connection-wizard uses tor_status.py ( the one in anon-connection-wizard package, not the one in whonox-setup-wizard package) to start Tor.
It will examine the exit codes of the following two commands and return cannot_connect when one of the exit code is not 0. Specifically:
Would you please run the two commands in a shell to see what will happen?
I personally prefer the idea to only include āDisableNetwork 0ā in /etc/tor/torrc. Because it will serve as a final switch indicating if Tor will be enabled or disabled. It does not make much sense when users have explicitly want to enable/disable Tor in anon-connection-wizard but fail because there is another out of date āDisableNetwork 0ā line in another .torrc file which is not easy to find out.
Btw I suggest updating form Qubes testing repository for dom0 and templates. It fixed many issues for me related to VM startup bugs. And I keep starting VMs from command line. That works reliable. Start menu not so much.
This is because then /etc/torrc.d snippets installed in whonix-gw TemplateVM would not reach TemplateBased sys-whonix once sys-whonix has been started at least once. sys-whonix then uses its local /etc/torrc.d and ignored changes from whonix-gw Template VM.
Implementation proposal:
qubes-whonix /usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf needs no changes.
No need to add binds+=( '/usr/local//etc/torrc.d' ) because /usr/local is already persistent in TemplateBasedVMs in by Qubes default anyhow.
anon-gw-anonymizer-config ships /etc/torrc.d/95_whonix.torrc including %include /usr/local/etc/torrc.d
let Debian process /etc/tor/torrc.d first, then process Whonix /usr/local/etc/torrc.d later?
we recommend users to use /etc/torrc.d/98_user.torrc or /usr/local/etc/torrc.d/50_user.torrc?
we recommend users to avoid editing /etc/tor/torrc so we can update as needed? (Only once the interactive dpkg conflict resolution dialog.)
That way:
Qubes sorted
no need to wait for Debian torrc.d?
no need to modify anon-gw-anonymizer-config /etc/tor/torrc, speak no interactive dpkg conflict resolution dialog, we can update /etc/tor/torrc as needed (catch up with Debian later)?
What do you think?
This is still without your last two git commits.
user@host:~$ sudo systemctl --no-pager restart tor@default
Job for tor@default.service failed because the control process exited with error code.
See "systemctl status tor@default.service" and "journalctl -xe" for details.
user@host:~$ sudo systemctl --no-pager status tor@default
ā tor@default.service - Anonymizing overlay network for TCP
Loaded: loaded (/lib/systemd/system/tor@default.service; static; vendor preset: enabled)
Drop-In: /lib/systemd/system/tor@default.service.d
āā30_qubes.conf, 40_obfs4proxy-workaround.conf, 40_qubes.conf
Active: failed (Result: exit-code) since Sun 2017-12-24 17:48:11 UTC; 11s ago
Process: 6448 ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 (code=exited, status=1/FAILURE)
Process: 6446 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config (code=exited, status=0/SUCCESS)
Process: 6443 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor (code=exited, status=0/SUCCESS)
Main PID: 6448 (code=exited, status=1/FAILURE)
Dec 24 17:48:11 host systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
Dec 24 17:48:11 host systemd[1]: Failed to start Anonymizing overlay network for TCP.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Unit entered failed state.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Failed with result 'exit-code'.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Service hold-off time over, scheduling restart.
Dec 24 17:48:11 host systemd[1]: Stopped Anonymizing overlay network for TCP.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Start request repeated too quickly.
Dec 24 17:48:11 host systemd[1]: Failed to start Anonymizing overlay network for TCP.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Unit entered failed state.
Dec 24 17:48:11 host systemd[1]: tor@default.service: Failed with result 'exit-code'.
Not too helpful. Weāre back to the Tor log I posted above.
Letās compare Tor version.
user@host:~$ dpkg -l | grep "ii tor"
ii tor 0.3.1.9-1~d90.stretch+1 amd64 anonymizing overlay network for TCP
Do you have apparmor enabled? It could be apparmor or systemd preventing read access to /etc/torrc.d! Where does Torās apparmor profile allow /etc/tor/torrc or /etc let alone /etc/torrc.d?
self.tor_status_page.text.setText('<p><b>Tor failed to (re)start.</b></p>\
<p>Job for tor@default.service failed because the control process \
exited with error code.</p>\
<p>See "systemctl status tor@default.service" and \
"journalctl -xe" for details.</p>\
<p>You may not be able to use any network facing application for now.</p>')
I donāt think it is a good idea to hardcode Job for tor@default.service failed because the control process \ exited with error code..
I suggest to store the output for the systemctl restart / status commands, and if it failed, have a drop down box where you show the literal output?
Btw did you know str(sys.exc_info()[0])? I find that very useful to catch unforeseeable exceptions, to write the output the the user so we can have a good bug report without having to ask for details / no issues to reproduce.
try:
with open(self.status_path, 'rb') as f:
status = pickle.load(f)
except:
error_msg = "Unexpected error: " + str(sys.exc_info()[0])
print(error_msg)
return
Only when repair_torrc.py and/or the parsing in tor_status.py do not work as expected (which is really rare). Is it a good idea to have this case just in case oneās repair_torrc and/or tor_status corrupted? Because it may be easier for us to debug it rather than let it fail silently?
Awesome idea! Thank you so much for your feedback, Patrick! This is the right way to go I believe!
Not before you told me!
One reason why I love Whonix development is that I can really learn a lot from your and other peopleās valuable feedback! I will definitely see where I can apply the use of it! Thank you, Patrick!
I see. So like in this probably apparmor caused case.
We always should be prepared for all cases.
This is a code philosophy question.
I personally prefer to have good bug handling code. I donāt like crashing / disappearing applications / empty gui pages. Neither I like having to ask users to reproduce to generate more debug information. Since often not all corner cases can be foreseen (and corner cases are more likely being introduced after major Debian upgrades, ports to lets say qt4 to qt5, ports to lets say python2.7 to python3), I like to have good error handling code. That is, if something got wrong, I like capturing the output of what went wrong (exception message) as well as a defensive collection (the bug handling itself should not error out due to disk read errors) of information (torrc. torrc.d snippets), and showing this in an for the user accessible way.
Other people however seem to prefer to write more correct code (who doesnāt) and to keep the code short (or are they just lazy / lack time / donāt have that idea?). That is they prefer to error out without such an error case handling function. Less code has other advantages. Looks less daunting to new contributors, more eyes, more contributions. So I am not discarding that as a valid strategy either.
This is an apparmor caused issue. Updated local system_tor.anondist in anon-gw-anonymizer-config.
Allowing read/write in /etc because ot the creation of /etc/torrc.d.
By the way, shouldānt the package anon-connection-wizard create the directory on installation in whonix-gw, because if itās created in sys-whonix at the first run, it will be lost at the next shutdown.
By the way, shouldānt the package anon-connection-wizard create the directory on installation in whonix-gw, because if itās created in sys-whonix at the first run, it will be lost at the next shutdown.
We have a standalone whonix-repository-wizard. Apparently it never landed in Whonix. I made the package at a time I wanted to separate the setup and repository tools. Itās still and old makefile but it builds without warnings.
The directory structure has been modified for python 3, and itās ported to python 3 and pyqt5.
Hi @troubadour ! I know that Whonix has been using guimessage module to do the translation, but I just learned a more standard and widely used way to do this is using gettext. Do you know if there was any concern that makes us use guimessage instead of gettext?
Even the %include /etc/torrc.d line exits and Tor is actually working, still, there is a scary complain:
ERROR: Tor Config Check Result:
Your /etc/tor/torrc file contains at least one error.
(Tor exit code: 1)
Tor reports:
Dec 30 12:27:00.938 [notice] Tor 0.3.1.9 (git-df96a13e9155c7bf) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0f, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.1.2.
Dec 30 12:27:00.938 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 30 12:27:00.938 [notice] Read configuration file "/etc/tor/torrc".
Dec 30 12:27:00.940 [warn] Error reading included configuration file or directory: "/etc/torrc.d".
Dec 30 12:27:00.940 [err] Reading config failed--see warnings above.
