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.
- No need to add
- 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
runsmkdir -p /usr/local/etc/torrc.d
- anon-connection-wizard writes to
/usr/local/etc/torrc.d
- might need to amend anon-gw-anonymizer-config/etc/apparmor.d/local/system_tor.anondist at master · Whonix/anon-gw-anonymizer-config · GitHub?
- 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
?