I don’t know. Replacing tor_status.py with a bash script does not look straight forward, what with the return strings and the functions set_enabled/set_disabled. It’s quite imbricated actually. And it has been extensively tested and it works.
Now the logic in tor_status.py differs slightly from ft_m_1.
tor start
tor reload
if tor status != 0
tor start
if tor status != 0
- return cannot connect
But basically, like in ft_m_1, it performs a second “tor start” because /run/tor.control and /run/tor/tor.pid are not created on the first one, whatever the sleep time between the commands.
The weird issue is that the extra step is required only when tor_status.py is run after reboot. Just retested now, without rebooting Whonix-Gateway.
leave only two lines in tor_status.py logic:
service tor start
return ‘tor_enabled’
in terminal: sudo service tor stop
in /etc/tor/torrc: #DisableNetwork 0
run whonix-setup-wizard -> tor is running, whonixcheck OK.
if line.strip() == 'DisableNetwork 0':
line_exists = True
return 'tor_already_enabled'
Because the user might have manually stopped Tor (or Tor crashed or the system killed it because of RAM issues or whatever). In that case, the tor_already_enabled message is nice, but whonix-setup-wizard should still make sure the Tor service is actually running by starting it.
Yes, it is a bug. Have added extra tor status check in 4859ab8. It’s tested, working fine with a single “tor start”.
There is another commit prior to that one. Allow opening external links in first use notice page. Without it, the page was going blank when clicking Platform-specific Desktop Tips. Now, it pops “Link confirm open Error”.
Instead of sleep, we could see if running `sync` (http://linux.die.net/man/8/sync) sufficed - or the python equivalent of it. A `sync` doesn't hurt either way.
I have removed all the sleep() lines. From earlier tests, I'm confident they are not necessary.
There is an equivalent to sync/flush in python, but in this context, because the tor commands are run in the shell, it cannot not be very useful. May be it’s worth trying with the shell “sync”, after the first ‘service tor start’.
Yes, it is a bug. Have added extra tor status check in [url=https://github.com/troubadoour/whonix-setup-wizard/commit/4859ab8c19ed084137ba78c56df391d87a51f9a5]4859ab8[/url]. It's tested, working fine with a single "tor start".
Looks good now. Also merged.
Now, it pops "Link confirm open Error".
The usual error…?
Link Confirm Open does not support opening links on Gateway for security reasons.
Use Tor Browser under Workstation to browse the internet.
Is that a problem? I guess there is nothing we can do about that?
Is this still necessary?
/usr/lib/whonixsetup_check_for_start is autostarted through /etc/xdg/autostart/whonix-setup-wizard.desktop, so it's guaranteed, that X has been started.
Is this still necessary?
/usr/lib/whonixsetup_check_for_start is autostarted through /etc/xdg/autostart/whonix-setup-wizard.desktop, so it’s guaranteed, that X has been started.
Link Confirm Open does not support opening links on Gateway for security reasons.
Use Tor Browser under Workstation to browse the internet.
Is that a problem? I guess there is nothing we can do about that?[/quote]
We could the remove the HTML “<a href=” in translations, but it would not look so nice. And we have links from whonixcheck in msgdispatcher_dispatch_x, so…
/usr/lib/whonixsetup_check_for_start is autostarted through /etc/xdg/autostart/whonix-setup-wizard.desktop, so it’s guaranteed, that X has been started.[/quote]
Yes, I will remove it.
if line.strip() == 'DisableNetwork 0':
line_exists = True
return 'tor_already_enabled'
Because the user might have manually stopped Tor (or Tor crashed or the system killed it because of RAM issues or whatever). In that case, the tor_already_enabled message is nice, but whonix-setup-wizard should still make sure the Tor service is actually running by starting it.
Otherwise you’re indeed already using a very similar startup logic. It should work.[/quote]
In Qubes, I check tor status like this:
def maybe_reload_tor():
torrc = '/etc/tor/torrc'
if os.path.exists(torrc):
try:
with open(torrc, 'r') as infile:
text = infile.read()
except (IOError):
return
if re.search(r'^DisableNetwork 0$', text, re.MULTILINE):
try:
if subprocess.check_output(['systemctl', 'is-enabled', 'tor']).strip() == 'enabled':
subprocess.call(['systemctl', 'reload', 'tor'])
pass
except (subprocess.CalledProcessError):
pass
I have tested the setup-wizard and seems to be working very nice. Good job!
I am preparing a Whonix 9.6 release for withing the next week or so and was wondering if there are any show stoppers on why I should not use the current version for that release.
One thing of note that you may want to consider before final release is complying to python’s PEP8 standards (class names CamelCase; method names snake_case). There is autopep8 and pep8 you can grab from pypi to analyze your code.
I’m not a fan of the re module (a bit cryptic when rereading) but it’s good to know.
One thing of note that you may want to consider before final release is complying to python's PEP8 standards (class names CamelCase; method names snake_case). There is autopep8 and pep8 you can grab from pypi to analyze your code.
Yes, I will do, thanks for the tips. And if you have any other remark on the code to make it better, please feel free tell. As far as I know, you are the only "real" python coder around, so your advice is always welcome.
