torrc.d is comming

Development
21

iry:

Done:
[tor-dev] Proposal: only parse .torrc files in torrc.d directory

Great!

Btw… After a while (undefined time)… Please create a ticket from
what has been consensus among the developers from that discussion on
trac.torproject.org. Please reference the thread. Additionally, I like
to reference the ticket being created on the mailing list to neatly link
everything together.

Alternatively, you could also skip the mailing list discussion and post
right on trac.torproject.org.

1 Like
22

Thank you so much for your guidance, Patrick!

Done:

2 Likes
23

When I install the package locally using make deb-icup, I got a hint to do: systemctl daemon-reload so that the new configurations will take effect.

I am wondering if this is something we should take care of in the package installation process? If so, what’s the proper way to auto execute systemctl daemon-reload? In Makefile I guess?

Thank you very much!

1 Like
24

minor thing:
Downstream discussion to link everything together
I meant the discussion on Tor mailing list where they had consensus.

1 Like
25

Makefile: no, it’s not for such purposes. Doesn’t work (or super hacky).

Debian maintainer scripts: yes.

For standard cases, debhelper does this (among a lot other repetitive magic) for us. (Grep Whonix source code for (#DEBHELPER#).)

The debhelper token #DEBHELPER#in maintainer scripts such as postinst gets replaced with actual debhelper code. Example:

/var/lib/dpkg/info/sdwdate.postinst

(And /var/lib/dpkg/info/sdwdate.* / /var/lib/dpkg/info/*.* files more generally.)

This is sufficient for common use cases for systemd.

Adding a drop-in for a third party package (in our example: tor) is not a that common case.

So in this case we should add indeed to (already existing) postinst:

Could you add this please?

Not having this is a minor bug. We didn’t spot it yet since after reboot systemctl daemon-reload is no longer required.

But it’s not a clean solution. The upstream bug against the debian systemd pacakge should be:

debhelper should run systemctl --system daemon-reload when a package is shipping a systemd drop-in file in /lib/systemd/system/service.service.d/

Could you report that bug please?

26

After the recent tor mailing list discussion, let’s change the extension .torrc to .conf? I doubt they’ll go with *.torrc since no one uses that. How did we invent that anyhow? .conf is more likely. Will work on the change accordingly now.

The testers-only release is ready for upload, but I’ll recreate to get this change in.

1 Like
27

Please review.

(More packages need changes. I am in process of doing that.)

1 Like
28
29

https://github.com/Whonix/whonixcheck/commit/37b2dc8484e2f97718f62ca6a23d4ea28f62e3df

https://github.com/Whonix/whonixsetup/commit/887437c65205eb79ad95815f79f13d34dc847e42

FYI

one='\.torrc'
two='\.conf'
find . -type f -not -iwholename '*.git*' -exec sed -i "s#$one#$two#g" {} \;

(The . had to be escaped by using .\.)

1 Like
30

All done. Please review. Hopefully no new bug was introduced with this.

1 Like
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