torrc.d is comming

Development
31

The syntax is not implemented yet. We may have to wait until Tor 0.3.3 becomes stable? Enable it right will cause problems?

32

Tested this one, works well for me. :slight_smile:

1 Like
33

Other than that, the changes look good to me. :slight_smile:

1 Like
34

Yes, since unfortunately not yet implemented, I will git revert that. Thanks!

1 Like
35

This was done.

2 Likes
36

I am thinking that if the “parsing everything bug” is not fixed by the time Whonix 14 is released, should we not enable torrc.d feature by default but simply give users a sense it works? Specifically:

In the /etc/tor/torrc:

%include /etc/torrc.d/95_whonix.conf

In the /etc/torrc.d/95_whonix.conf:

%include /usr/local/etc/torrc.d/40_anon_connection_wizard.conf
%include /usr/local/etc/torrc.d/50_user.conf

We may also need to give extra parameter to Tor to make it stop complaining missing torrc files.

I do not like this workaround since it is too hacky. Another way needs us to teach users to keep their torrc.d directory clean and make sure it only contains torrc files. Maybe ship a script for users to do this?

Edit by Patrick: .torrc -> .conf

1 Like
37

Edit by Patrick: .torrc → .conf

The editor backup files ending with ~ and other unexpected file endings leave too much room for bugs. A blacklist approach is insufficient here. Hence, we need to wait unitl the .conf whitelist mechanism can be implemented.

Too non-obvious / difficult for users. That will have the majority of users slip through and a minority to get it right away.

For sure. Does it exist? What parameter is that?

But yes, we ought to do that. Very good idea!

1 Like
38

Patrick Schleizer:

For sure. Does it exist? What parameter is that?

But yes, we ought to do that. Very good idea!

I was thinking about these two:

--allow-missing-torrc: Do not require that configuration file
specified by -f exist if default torrc can be accessed.

--ignore-missing-torrc: Specifies that Tor should treat a missing
torrc file as though it were empty. Ordinarily, Tor does this for
missing default torrc files, but not for those specified on the
command line.

Unfortunately, the first parameter will only allow missing torrc that is
specified in command line and the second parameter will only ignore the
default torrc. There will still be an error causing Tor to stop when a
file specified in a file using %include is missing.

Writing all the files in the command line may not work neither because
Tor only accepts one torrc behind -f parameter?

What can we do then?

we need to wait unitl the .conf whitelist mechanism can be implemented.

I will try to do a patch against Tor myself if no one is going to work
on this soon. Whonix 14 probably cannot wait until 0.3.3 becomes stable on Apr 15, 2018.

But I hope:

For the most recent supported stable release only, we intend that:
Smaller bugs that significantly impact user experience will get fixed.

1 Like
39

I guess allow-missing-torrc and ignore-missing-torrc would work from /usr/share/tor/tor-service-defaults-torrc (which Whonix already modifies as you know). But to these prevent Tor from failing if an %include file is missing? Could you test that please?

Perhaps I know an easier way than patching Tor. However, patching Tor is good nontheless because we wouldn’t know when they implement the include wild card feature (example: %include folder/*.conf)

We could use a systemd drop-in file (similar to your pull request) where we overwrite

ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor
ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config
ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0

First line we keep unmodified. Second and third line we extend with

  • -f /usr/local/etc/torrc.d/40_anon_connection_wizard.conf
  • -f /usr/local/etc/torrc.d/50_user.conf

Add --allow-missing-torrc and --ignore-missing-torrc if needed. Or perhaps we better add it there than torrc defaults file?

/etc/torrc.d/ can be dropped. (It wouldn’t be implemented so we should avoid the confusion of having this folder.)

/etc/tor/torrc can be reverted to Whonix 13 version in anon-gw-anonymizer package. I.e. just as if we didn’t change the file from perspective of a package upgrade. No modifications of user’s existing /etc/tor/torrc during Whonix 14 upgrade.

Package that may need modification:

  • anon-gw-anonymizer-config
  • acw - probably not?

Do you think you could work on this one?

1 Like
40

The parsing all problem will not be fixed at least until:

  • milestone: => Tor: 0.3.4.x-final
1 Like
41

Here is what I did:

sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --allow-missing-torrc --ignore-missing-torrc -f /etc/tor/torrc -f /usr/local/etc/torrc.d/40_anon_connection_wizard.conf -f /usr/local/etc/torrc.d/50_user.conf --RunAsDaemon 0

The configurations in /usr/local/etc/torrc.d/40_anon_connection_wizard.conf does not take effect. I guess this approach does not work?

42

That is really nice to have. But I am afraid these two commands are only available as commandline parameters.

1 Like
43

All we want to do is to make sure /usr/local/etc/torrc.d/40_anon_connection_wizard.conf and /usr/local/etc/torrc.d/50_user.conf exists.

So shall we do:

ExecStartPre=/usr/bin/touch /usr/local/etc/torrc.d/40_anon_connection_wizard.conf

1 Like
44

iry:

Here is what I did:

sudo /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc --allow-missing-torrc --ignore-missing-torrc -f /etc/tor/torrc -f /usr/local/etc/torrc.d/40_anon_connection_wizard.conf -f /usr/local/etc/torrc.d/50_user.conf --RunAsDaemon 0

The configurations in /usr/local/etc/torrc.d/40_anon_connection_wizard.conf does not take effect. I guess this approach does not work?

I speculate -f can only be used once.

1 Like
45

iry:

All we want to do is to make sure
/usr/local/etc/torrc.d/40_anon_connection_wizard.conf and
/usr/local/etc/torrc.d/50_user.conf exists.

So shall we do:

ExecStartPre=/usr/bin/touch /usr/local/etc/torrc.d/40_anon_connection_wizard.conf

Idea: Great!

iry:

All we want to do is to make sure /usr/local/etc/torrc.d/40_anon_connection_wizard.conf and /usr/local/etc/torrc.d/50_user.conf exists.

So shall we do:

ExecStartPre=/usr/bin/touch /usr/local/etc/torrc.d/40_anon_connection_wizard.conf
Implementation:
Wouldn’t work. Also mkdir -p beforehand would be required. Anyhow.

systemd tmpfiles.d is the proper mechanism for that. To find some examples:

find . -type f -not -iwholename '*.git*'

(Got a shortcut for that.)


./packages/sdwdate/usr/lib/tmpfiles.d/sdwdate.conf


./packages/bootclockrandomization/usr/lib/tmpfiles.d/bootclockrandomization.conf


./packages/anon-ws-disable-stacked-tor/usr/lib/tmpfiles.d/anon-ws-disable-stacked-tor.conf

./packages/anon-shared-helper-scripts/usr/lib/tmpfiles.d/anon-shared-helper-scripts.conf

./packages/rads/usr/lib/tmpfiles.d/rads.conf


./packages/usability-misc/usr/lib/tmpfiles.d/50_openvpn_unpriv.conf


./packages/whonixcheck/usr/lib/tmpfiles.d/whonixcheck.conf

When copying and pasting a solution like this, it’s also useful to grep
a few filenames to see other places where they may have to be
referenced. See sdwdate.conf etc.

mygrep -r /usr/lib/tmpfiles.d/bootclockrandomization.conf
+ exec grep --exclude=README.md --exclude=GPLv2 --exclude=GPLv3
--exclude=COPYING --exclude=changelog.upstream-old1 --exclude-dir=mnt
--exclude-dir=qubes-src/linux-template-builder/mnt
--exclude=changelog.upstream --exclude-dir=.git
--exclude-dir=chroot-debian --exclude-dir=chroot-jessie -r
/usr/lib/tmpfiles.d/bootclockrandomization.conf
packages/bootclockrandomization/debian/bootclockrandomization.postinst:
systemd-tmpfiles --create
/usr/lib/tmpfiles.d/bootclockrandomization.conf >/dev/null || true

I.e. looking into for example into
bootclockrandomization/debian/bootclockrandomization.postinst would
reveal the required postinst snippet.

1 Like
46

There is one disadvantage of the systemd tmpfiles mechanism.

These files would be created inside a Qubes-Whonix-Gateway TemplateVM as
well as in a Qubes TemplateBased Whonix-Gateay ProxyVM. Not the cleanest
solution. But I guess acceptable.

On a second thought, it has to be seen if systemd tmpfiles works in
/usr/local. I doubt it has been used there before. But we’ll find out.
Otherwise we think more about ExecStartPre. There is a distinction for
systemd unit drop-ins between override and extend, if I remember
correctly? We wouldn’t want to override for simplicity (in case the
upstream ExecStartPre changes and we don’t notice, so don’t catch up,
therefore introduce unwanted/unaware differences). We’d want to extend
so we don’t interfere.

1 Like
47

Hi Patrick!

I am sorry for the delay of my response. And thank you so much for teaching me on the working flow. I do find it really helpful.

I tested with the following configurations (Let’s call it torrcd.conf for now):

d /usr/local/etc/torrc.d/ 0755 root staff
f /usr/local/etc/torrc.d/40_anon_connection_wizard.conf 0755 root staff
f /usr/local/etc/torrc.d/50_user.conf 0755 root staff

user@host:~$ cat /etc/torrc.d/95_whonix.conf 
## Do not edit this file!
## Please create and add modifications to the following file instead:
## /usr/local/etc/torrc.d/50_user.conf
%include /usr/local/etc/torrc.d/40_anon_connection_wizard.conf
%include /usr/local/etc/torrc.d/50_user.conf

It partly works as expected but here are some problems:

  1. The systemd-tmpfile will only auto execute once at boot time, which means when /usr/local/etc/torrc.d/50_user.conf is deleted somehow after the boot up, and then when user would like to restart Tor again, Tor will fail to start, unless they reboot or manually execute systemd-tmpfile. Therefore, it would be helpful if we could find a way to make sure those directory and files exist by using ExecStartPre in /lib/systemd/system/tor@default.service.d/40_torrcd-workaround.conf.

  2. If we decide to go for tmpfiles rather than ExecStartPre, we should put the torrcd.conf in a Whonix-Gateway-Only package instead of anon-connection-wizard package. Because even if it is related to the anon-connection-wizard, we should assume Whonix without anon-connection-wizard installed should also work.

It seems postinst snippets are all containing other components for example:

source /usr/lib/anon-shared-helper-scripts/torsocks-remove-ld-preload

case "$1" in
   configure)
      adduser --home /nonexistent --quiet --system --group whonixcheck || true

      ## Compatibility with anon-ws-disable-stacked-tor.
      addgroup debian-tor 2>/dev/null || true

      ## Add whonixcheck to group debian-tor so it can read
      ## /var/run/tor/control.authcookie which is required to check for Tor
      ## bootstrap test.
      addgroup whonixcheck debian-tor

Do we also need somethign similar to this part? Or do we just need:

## workaround for 'dh_installinit should run systemd-tmpfiles if a
## /usr/lib/tmpfiles.d/ snippet gets shipped for systemd-only packages
## also' - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795519
# In case this system is running systemd, we need to ensure that all
# necessary tmpfiles (if any) are created before starting.
if [ -d /run/systemd/system ] ; then
        systemd-tmpfiles --create /usr/lib/tmpfiles.d/torrcd.conf >/dev/null || true
fi

true "INFO: debhelper beginning here."
1 Like
48

I agree that we should extend instead of overriding, for ExecStartPre, putting setting in service.d should be extending, not orveriding I guess?

Yes, this will not work as epected. Is there another way to make sure certain files and directory exist? I searched online, but have not found a solution.

Thank you very much!

1 Like
49

iry:

I agree that we should extend instead of overriding, for ExecStartPre, putting setting in service.d should be extending, not orveriding I guess?

Yes.

ExecStartPre= is needed to overwrite all previous ones.

ExecStartPre=something extends.

Yes, this will not work as epected. Is there another way to make sure certain files and directory exist? I searched online, but have not found a solution.

Sounds good!

1 Like
50

Do we also need somethign similar to this part? Or do we just need:

## workaround for 'dh_installinit should run systemd-tmpfiles if a
## /usr/lib/tmpfiles.d/ snippet gets shipped for systemd-only packages
## also' - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795519
# In case this system is running systemd, we need to ensure that all
# necessary tmpfiles (if any) are created before starting.
if [ -d /run/systemd/system ] ; then
        systemd-tmpfiles --create /usr/lib/tmpfiles.d/torrcd.conf
/dev/null || true
fi

true "INFO: debhelper beginning here."

Only that is required.

iry:

  1. The systemd-tmpfile will only auto execute once at boot time, which means when /usr/local/etc/torrc.d/50_user.conf is deleted somehow after the boot up, and then when user would like to restart Tor again, Tor will fail to start, unless they reboot or manually execute systemd-tmpfile. Therefore, it would be helpful if we could find a way to make sure those directory and files exist by using ExecStartPre in /lib/systemd/system/tor@default.service.d/40_torrcd-workaround.conf.

Makes sense.

  1. If we decide to go for tmpfiles rather than ExecStartPre, we should put the torrcd.conf in a Whonix-Gateway-Only package instead of anon-connection-wizard package. Because even if it is related to the anon-connection-wizard, we should assume Whonix without anon-connection-wizard installed should also work.

Theoretical: Yes, into anon-gw-anonymizer-config package.

Practical: ExecStartPre touch method is better.

Actually: we need probably both… tmpfiles and ExecStartPre.
ExecStartPre for reasons you explained.

tmpfiles to create the folder. Because without the folder existing,
ExecStartPre touch would fail.

1 Like