[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

[graphical gui] Whonix Setup Wizard / Anon Connection Wizard - Technical Discussion


#382

Qubes 4.0-Whonix 14

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 https://www.torproject.org/download/download#warning
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.


#383

Thank you so much for your suggestion, Patrick!

Done:

https://github.com/irykoon/anon-connection-wizard/commit/9c722b994cd53d20889d9f3dd95dbe04498985fa

https://github.com/irykoon/anon-connection-wizard/commit/813f3c88e6045c1e9337bc31ab93f420234aedcd


#384

Hi @Patrick !

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:

    command = 'systemctl --no-pager restart tor@default'
    tor_status = call(command, shell=True)

    if tor_status != 0:
        return 'cannot_connect'

    command = 'systemctl --no-pager status tor@default'
    tor_status = call(command, shell=True)

    if tor_status != 0:
        return 'cannot_connect'

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.

What do you think? :slight_smile:


#385

Hi @troubadour ! I am really glad to see you back!!

Thank you so much for your testing!

Yes, the reason why /etc/torrc.d/ does not exist is because it is not persistent in a TemplateBasedVm in Qubes. I guess the solution is here:

I can definitely do a pull request to make /etc/torr.d persistent but:

  1. it seems the directory for torrc.d has not been set by upstream (Debian).
  2. would you please tell me which file should be modified to add the rule, @Patrick ?

#386

How could condition elif self.tor_status == 'missing_disablenetwork_line': be triggered anyhow if we have repair_torrc?



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.


#387

It’s not as easy as adding binds+=( '/etc/torrc.d' ) to /usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf.


#388

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
  • anon-gw-anonymizer-config debian/anon-gw-anonymizer-config.postinst runs mkdir -p /usr/local/etc/torrc.d
  • anon-connection-wizard writes to /usr/local/etc/torrc.d
  • might need to amend https://github.com/Whonix/anon-gw-anonymizer-config/blob/master/etc/apparmor.d/local/system_tor.anondist?
  • 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?


#389
            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

#390

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?


#391

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! :slight_smile:


#392

Awesome idea! Thank you so much for your feedback, Patrick! This is the right way to go I believe!

Not before you told me! :slight_smile:

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!


#393

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.


#394

This is an apparmor caused issue. Updated local system_tor.anondist in anon-gw-anonymizer-config.

https://github.com/troubadoour/anon-gw-anonymizer-config/commit/4965ce527c1b099875146246d6c8ce775e85444f

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.


#395

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.


#396

Tor fails to start when using %include /etc/torrc.d while that folder does not exist.


Whonix 14 (Anon Connection Wizard) - Cannot start tor@default
#397

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.


#398

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?


#399

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:

  1. make anon-connection-wizard translatable by python module gettext: https://docs.python.org/3.6/library/gettext.html
  2. remove all the Whonix specific part from anon-connection-wizard
  3. do not “hardcode Job for tor@default.service”
  4. apply str(sys.exc_info()[0]) when necessary

#400

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.

#401

Yes, thanks for noticing!