tor-control-panel will be installed by default after upgrades. Uploaded to testers repository. 
Merged your commits.
Yes, that would be the obvious location for repair_torrc. But if we move it there, it would be lost for Debian users (repair_torrc is no longer run from tor-control-panel).
Not exactly. It looks like systemd is catching Tor errors, while Tor log just reports exiting cleanly when it does not start or is stopped abnormally. So systemd journal is more comprehensive, but does not add the warn or error tags which are used for highlighting lines in Tor log.
There is a plan to add a Find button in the Logs tab (like in Vidalia), and the tags would be helpful for this option.
Have to run some more tests to figure out.
Will look into it. It used to work in Qubes, it never worked in plain Debian.
1 Like
anon-shared-helper-scripts would be a dependency.
Installation of tor-control-panel for Debian users would still be simple. As simple as:
Once/if we manage to get both anon-shared-helper-scripts and tor-control-panel uploaded to packages.debian.org it would be installabe as simple as sudo apt-get install tor-control-panel.
1 Like
Moved repair_torrc in anon-shared-helper-scripts.
A batch of atomic commits in tor-control-panel before this one, which sets the new path:
Added anon-shared-helper-scripts dependency in the last commit.
The modified repair_torrc
whonix-setup-wizard is updated for tor-control-panel.
1 Like
from tor_control_panel import torrc_gen, info
Now anon-shared-helper-scripts depends on tor-control-panel.
Could you please move also torrc_gen, info to anon-shared-helper-scripts?
What that is done both whonixsetup (CLI) and tor-control-panel (GUI) can just depend on anon-shared-helper-scripts.
The added advantage of that is that a Whonix CLI version (RPI version being worked on) doesn’t pull any GUI packages.
In the first un-pushed version, repair_torrc was not depending on tor-control-panel. It’s reverted.
It makes some code redundant.
For the time being, it would not be wise to move torrc_gen.py into anon-shared-helper-scripts, too much complication.
info.py is ugly, and should not stay as is. The plan is to make a real translatable mechanism, gettext like. I have some clues on that, but it’s not quite clear yet.
1 Like
Desktop file fix.
Bug fix.
1 Like
All merged.
One bug. To reproduce.
sudo systemctl mask tor
sudo rm -r /var/run/tor
kdesudo tor-control-panel
File "/usr/lib/python3/dist-packages/tor_control_panel/tor_control_panel.py", line 634, in refresh_logs
with open(self.tor_log_html, 'w') as fw:
FileNotFoundError: [Errno 2] No such file or directory: '/var/run/tor/html-log'
Refuses to start.
Could you please reset whonix-setup-wizard to be auto starting anon-connection-wizard? For first boot the wizard is a bit easier.
Done.
Probably fixed in
Aren’t we try to fix corner cases, created by developers trying every possible situation?
In that case (removing /var/run/tor), swdate-gui-qubes logically shows Tor is not running because the Tor file system watcher looks at /var/run/tor and torrc. If the former is deleted, the watcher stops and would have to be restarted when Tor is restarted and recreates /var/run/tor. Feasible, but is it worth the code complication?
The same applies if we remove torrc. swdate-gui-qubes shows Tor is disabled and tor-control-panel refuses to start. This can be fixed by running repair_torrc in tor-control-panel, but again, is it worth?
1 Like
Yes, probably. Have pushed a few commits in tor-control-panel.
Left with an issue in sdwdate-gui-qubes when /var/run/tor/ is deleted.
1 Like
All merged.
Btw also all readme’s of all packages updated.
Radically simplified.
(using generic readme developer-meta-files/README_generic.md at master · Kicksecure/developer-meta-files · GitHub)
That’s a good question. I keep wondering. Often I try to foresee what would happen on disk errors where parts of the files don’t exist.
Maybe not situations created by developers but created by users.
An onion-grater corner case is that it fails to start if networking does not come up (due to some unidentified update bug). Then even if networking gets manually restarted, the system still doesn’t work and no hint to restart onion-grater. So ideally onion-grater could gracefully handle non-existing network and wait for it.
Not great but ok. Could instruct user to do something (start tor-control-panel, if installed, on gateway).
The refusal to start is very much worth fixing. We rely on it as a diagnosis tool. While it doesn’t have to be able to fix all things that users can mess up, it’s good if it at least hints whats wrong.
However we probably should not go as far as fixing a system where the user deleted /usr/share/tor/tor-service-defaults-torrc in Whonix. 
Was done a couple fo days ago.
Sorry I did not describe the commits.
Probably overkill. But if we had the template, that would be a matter of copying a file.
A logic fix.
1 Like
tor_is_enabled = tor_status.tor_status() == ‘tor_enabled’ and not
tor_status.tor_status() == ‘missing_disablenetwork_line’
tor_status.tor_status() just returns one keyword. Or could it be
‘tor_enabled’ and at the same time ‘missing_disablenetwork_line’?
I doubt it can be ‘missing_disablenetwork_line’ and ‘tor_enabled’ at the
same time? So I don’t understand that logic anyhow.
Yes, the logic is flawed, again.
There is an easy fix, just returning tor_disabled if the DisableNetwork line is missing. Or there is more…
tor_status.py does not parse all the files in /etc/torrc.d. If a line DisableNetwork 1 is written in the user’s torrc file (why not ?), we have no way to know it. Tor, sdwdate and whonixcheck will be aware though.
Also, if the line is commented, tor_status.py cannot parse it either. However, anon-connection-wizard can deal with the commented line on reboot, because it rewrites torrc in anon-connection-wizard.py
1 Like
Because anon-gw-anonymizer-config/torrc.anondist at master · Whonix/anon-gw-anonymizer-config · GitHub only uses /etc/torrc.d/95_whonix.conf which only uses:
%include /usr/local/etc/torrc.d/40_tor_control_panel.conf
%include /usr/local/etc/torrc.d/50_user.conf
We’re not really using whole torrd.d. Why? Because torrc.d/*.conf isn’t implemented yet (Tor Project ticket exists- Parse only .torrc files in torrc.d directory (#25140) · Issues · Legacy / Trac · GitLab). Without only parsing *.conf files with appendix like ~ (graphical editor backup files) and .dpkg-old would also be parsed leading to unexpected behavior.
So the ideal way would be “same way like Tor does”. From the Tor startup command, to tor-service-defaults-torrc, to /etc/tor/torrrc and always evaluating the %include statements.
Bash pull request in progress.
//cc @iry
It should be done in
I created files containing DisableNetwork 1 with any appendix (.anything or .conf.anything) in torrc.d. glob parses only .conf files.
It is a big commit, some changes in torrc/torrc.d path in several files.
In the maze, I have commented this part:
### start Tor
#command = 'systemctl --no-pager restart tor@default'
#tor_status_code = call(command, shell=True)
#if tor_status_code != 0:
#return 'cannot_connect', tor_status_code
### we have to reload to open /var/run/tor/control and create /var/run/tor/control.authcookie
#command = 'systemctl reload tor@default.service'
#tor_status_code = call(command, shell=True)
#command = 'systemctl --no-pager status tor@default'
#tor_status_code= call(command, shell=True)
#if tor_status_code != 0:
#return 'cannot_connect', tor_status_code
#return 'tor_enabled', tor_status_code
tor-control-panel is restarting Tor after any action, and it looks like that today we do not have to reload Tor after enabling the network. Tested after reboot.
1 Like
Forget the last commit. Will revert. I was carried away in coding, without reading closely enough.
1 Like
On the other hand, do we have to wait for https://trac.torproject.org/projects/tor/ticket/25140 to implemented .conf parsing only? Isn’t it the default extension for the .d mechanism?
In https://github.com/Whonix/anon-shared-helper-scripts/pull/3#issuecomment-377913469, you wrote
Parsing only *.conf rather than * is very important (and an easy code change) indeed.
That’s what I believe too. The last commit in tor-control-panel just implements that.
But we have to parse .conf in tor_enabled_check, or whonixcheck will complain if a file with a ~ or whichever extension exist in torrc.d.
The real thing, parsing as Tor does, would have to be done in a new python script, as you suggest.
1 Like