It is exactly the same Tor version I used to test.
No. I did not enable apparmor. It is very likely the reason.
We need some extra apparmor rules then, I guess? I will look into that! 
1 Like
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!
2 Likes
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.
1 Like
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.
2 Likes
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.
Forget that. Trying to catch up.
2 Likes
Tor fails to start when using %include /etc/torrc.d while that folder does not exist.
1 Like
Yes, that’s what I found out.
We will keep https://github.com/Whonix/whonix-setup-wizard indefinite since we need Whonix Repository GUI Tool (kdesudo whonix-setup-wizard repository).
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.
3 Likes
https://github.com/Whonix/anon-gw-anonymizer-config/pull/7
One thing I am not quiet sure:
- /usr/local/etc/torrc.d/ r,
- /usr/local/etc/torrc.d/* r,
+ /usr/local/etc/torrc.d/ rw,
+ /usr/local/etc/torrc.d/* rw,
It seems we should give the write permissions, correct?
1 Like
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?
TODO:
- make anon-connection-wizard translatable by python module
gettext: 23.1. gettext — Multilingual internationalization services — Python 3.6.15 documentation - remove all the Whonix specific part from anon-connection-wizard
- do not “hardcode Job for tor@default.service”
- apply
str(sys.exc_info()[0])when necessary
1 Like
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.
Yes, thanks for noticing!
1 Like
This is https://github.com/Whonix/whonixcheck/blob/master/usr/lib/whonixcheck/check_tor_config.bsh which is in essence running:
sudo --non-interactive -u debian-tor tor --verify-config
- Could you please confirm that
sudo --non-interactive -u debian-tor tor --verify-configwill exit non-zero (1)? (echo $?) - Could you please confirm, that Tor is actually running?
sudo systemctl status tor@default - And Tor is also functional, connectivity is working?
In that case, it looks like a bug in tor --verify-config.
Tor’s systemd unit /lib/systemd/system/tor@default.services used to run tor --verify-config, but apparently no longer doing so in Debian stretch.
It seems like tor --verify-config seems to report missing Tor .d config folder as an error while Tor itself does not. This I would consider a bug. If that is true, could you report a bug against Tor please?
1 Like
After running anon-connection-wizard, checked with
sudo --non-interactive -u debian-tor tor --verify-config; echo "exit code $?"
It returns exit 0.
Dec 31 17:00:30.156 [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 31 17:00:30.156 [notice] Tor can’t help you if you use it wrong! Learn how to be safe at Tor Project | Download
Dec 31 17:00:30.157 [notice] Read configuration file “/etc/tor/torrc”.
Configuration was valid
exit code 0
Restarting tor is OK, everything is functional, but whonixcheck is still complaining.
If we comment out the line %include /etc/tor/torrc.d in /etc/torrc, then whonixcheck runs without tor warning.
1 Like
Alright, so I think it’s an tor --verify-config bug.
Shall I disable this check in whonixcheck or we just make sure that folder exists in next upgrade (Whonix 14 of course, another iteration, package upgrade can be very soon).
1 Like
I think it would be better to create the folder in the, or a package instead of disabling the check, because other things might get wrong in /etc/tot/torrc, user tampering being one.
2 Likes
Or may be not. whonixcheck is still complaining when /etc/torrc.d exists.
2 Likes
apparmor is not allowing whonixcheck to read /etc/torrc.d. I’ll update the the profile.
2 Likes
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?
No there was no concern about gettext. When we started to get rid of the hard coded messages in the scripts, we found that solution (the gui-message script was written by nrgaway).
Later, I have been in touch with the people at translatewiki. They told me that yaml files solution was not standard and that we would run into problems sooner or later. I do not remember the exact content of the conversation, but at the end they did recommend gettext. I had no time to dig into it.
2 Likes
troubadour:
at the end they did recommend gettext. I had no time to dig into it.
Sounds great! Let’s use gettext for the Whonix applications for more
translatable form and less dependencies!
1 Like
I got the complain again when the VM is started however when I tried the following command line, it seems there is nothing wrong with the Tor configuration.
user@host:~$ sudo --non-interactive -u debian-tor tor --verify-config
Jan 03 18:50:17.363 [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.
Jan 03 18:50:17.363 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 03 18:50:17.363 [notice] Read configuration file "/etc/tor/torrc".
Configuration was valid
user@host:~$ echo $?
0
user@host:~$ sudo systemctl 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: active (running) since Wed 2018-01-03 18:49:16 UTC; 1min 29s ago
Process: 961 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config (
Process: 929 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor (code=exited, status=0/SUCCESS)
Main PID: 995 (tor)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/system-tor.slice/tor@default.service
└─995 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
1 Like