torrc.d is comming

iry · June 28, 2017, 2:19am

It makes sense. Debian bug reporting instructions says:

Don’t file bugs upstream

If you file a bug in Debian, don’t send a copy to the upstream software maintainers yourself, as it is possible that the bug exists only in Debian. If necessary, the maintainer of the package will forward the bug upstream.

iry · June 28, 2017, 2:54am

Done!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866187

Patrick · July 1, 2017, 10:31am

What’s the order of config file parsing as per Debian tor package default?

Parse first /usr/share/tor/tor-service-defaults-torrc?
Parse last (in lexical order) /etc/torrc.d?
Parse second /etc/torrc?

Is this stated by Debian yet? Could you ask please?

iry · July 3, 2017, 1:34am

Daniel answered on @tor-dev:

The precedence for tor options is the following (1 overrides 2, etc…):

Command line options.

Configuration file options (your /etc/torrc).

Defaults file options (your /usr/share/tor/tor-service-defaults-torrc).

In the same file, options that appear later override earlier options.

Currently, there is no torrc.d directory created when you install the tor package. However, you can use a %include in the configuration file or in the defaults file. When you insert a %include in a file, it works as if all the options for the included file or folder were written on the line of the %include. If you’re including a folder, the files will be processed in lexicographic order and files starting with a dot will be ignored.

Here is an example:

tor-service-defaults-torrc:
SomeOption 0
%include /etc/tor/torrc.d/ # SomeOption is now 2
SomeOption 3 # SomeOption is now 3

/etc/tor/torrc.d/01_one:
SomeOption 1

/etc/tor/torrc.d/02_two:
SomeOption 2

With this configuration, the value for some option is 3.
But we can have a torrc with %include too:

/etc/torrc:
SomeOption 4 # SomeOption is now 4
%include /etc/tor/foo.torrc # SomeOption is now 5
SomeOption 6 # SomeOption is now 6

/etc/tor/foo.torrc:
SomeOption 5

With both these files, the value for SomeOption is 6.

There are also different types of options and some can take multiple values. For more information see the section “Mid-level semantics” on this file: doc/torrc_format.txt · HEAD · The Tor Project / Core / Tor · GitLab

iry · July 8, 2017, 12:10pm

//cc @JasonJAyalaP

iry · November 6, 2017, 4:30am

Should we suggest user use a separate file /etc/torrc.d/bridges.torrc as configuration file? Or a more general question: should user use /etc/torrc.d/ or /etc/tor/torrc ?

Advantage:

The torrc configuration is more modularized ;

Disadvantage:

torrc configuration will be more scattered. Sometime users may forget they put a .torrc in /etc/torrc.d/ which they do not want anymore.
Although torrc.d feature is available in Tor stable now, it has not been decided by Debian on which directory to use as default torrc.d directory.

Patrick · November 6, 2017, 1:39pm

Always go for .d whenever possible. We recommend this at
Configuration Files - Kicksecure but I think a
more general advice on configuration files editing would be useful as
well in the wiki. @torjunkie

Otherwise users get an dpkg interactive conflict resolution dialog.

(

)

Which will confuse them even more. They might:

select “overwrite” and loose their settings or,
select nothing and keep the update stalled.
select “not overwrite” and miss recommended changes by upstream
(Debian or Whonix)

The fewest of them will be able to merge upstream changes with their
local changes.

As for /etc/torrc.d/bridges.torrc the file name part bridges.torrc
is not ideal.

Good that you are using an extension .torrc. Using no extension (if
that would even work) is not so great. Harder to parse. Easier to
source *.torrc rather than parsing * and then skipping files
ending ~ (graphical editor backup files) and files ending -dpkg.old
or similar.

I think adding a number_ prefix would be better. Such as 50_user.torrc.

There are a few .d folders and it’s not well standardized. But I would
suggest 50_ for users. 10_ for Debian, 20_ for torproject, 30_
for Whonix and so forth. Somehow a useful stackable order. An ordering
where the more upstream something is (Linux (most upstream) → Debian
(distribution) → Ubuntu (derivative of Debian, further downstream than
Debian)). Could you please look at existing .d folders of any other
projects tell me what you think? Perhaps discuss this with Tor Project.

iry · November 6, 2017, 7:05pm

TODO:

Could you please look at existing .d folders of any other
projects tell me what you think? Perhaps discuss this with Tor Project.
update Wiki
rename /etc/torrc.d/anon-connection-wizard.torrc to /etc/torrc.d/51_anon-connection-wizard.torrc ? I am not sure if it should be 49 or 51 but since anon-connection-wizard is used by user, anon-connection-wizard.torrc should also be seen as user configuration.

Patrick · November 6, 2017, 7:14pm

Please make that 40_. Reason: not by a distribution but also not done manually by the user. Done with a gui tool. 50_ could be used to override settings by the gui tool the user disagrees with (mostly theoretic at this point).

iry · November 6, 2017, 8:13pm

Thank you for your guidance, @Patrick !

Done: Rename /etc/torrc.d/anon-connection-wizard.torrc to /etc/torrc.d/40_a… · irykoon/anon-connection-wizard@64fc291 · GitHub

I will do a pull request later with other fixed and changes

iry · November 6, 2017, 8:32pm

Doudble check: DisableNetwork 0 should also go to /etc/torrc.d/50_user.torrc and it should not appear in any other .torrc correct?

If it is correct, anon-connection-wizard’s repair_torrc.py and tor_status.py and whonix-setup-wizard’s tor_status.py should be changed.

(actually we need to remove tor_status.py from whonix-setup-wizard packet, correct?)

Thank you very much!

Patrick · November 6, 2017, 10:02pm

iry:

Patrick:

I would suggest 50_ for users. 10_ for Debian, 20_ for torproject, 30_for Whonix and so forth.

Doudble check: DisableNetwork 0 should also go to /etc/torrc.d/50_user.torrc and it should not appear in any other .torrc correct?

When using anon-connection-wizard gui:

DisableNetwork 0 can be in a torrc file generated by
anon-connection-wizard 40_...

Manually:

Recommend use of /etc/torrc.d/50_user.torrc.

But I am not too sure about this yet. Someone who first did it manually
using /etc/torrc.d/50_user.torrc UseBridges 0 and then uses
anon-connection-wizard UseBridges 1 would result in actually
UseBridges 0.

So it’s not perfect yet. I guess nothing similar has been done before
that’s why we struggle with this?

Solution? anon-connection-wizard should parse all Tor config files and
warn/abort (not enable/restart Tor) about any conflicting (final)
result? That would be future work.

(actually we need to remove tor_status.py from whonix-setup-wizard packet, correct?)

Yes.

iry · November 6, 2017, 11:32pm

Yes, this can be a solution. I am going to think the problem and I will let you know if I came up with any other solutions

iry · February 3, 2018, 10:40pm

Done:
https://lists.torproject.org/pipermail/tor-dev/2018-February/012888.html

Patrick · February 4, 2018, 10:41am

iry:

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

I find that Tor will also parse filename~, which is a backup created by some editor. Problem with that is it is too hard to realize for a user. Users think they have changed the Tor settings but actually not, they may result in using the old settings.

Shall I do a proposal to TPO to strictly parse .torrc files only?

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

Yes, please. That seems more consistent. They also wouldn’t want to

parse files ending ‘.dpkg-old’ (not uncommon…).

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.

iry · February 4, 2018, 8:26pm

Thank you so much for your guidance, Patrick!

Done:

iry · February 4, 2018, 8:58pm

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!

Patrick · February 5, 2018, 12:51pm

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

Patrick · February 5, 2018, 1:07pm

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:

github.com

Kicksecure/usability-misc/blob/d571ffb72a5e7c5c1b88c1c80e0b9cf353f72917/debian/usability-misc.postinst#L76-L79


      
          ## Make systemd drop-in config snippets take effect.
          if [ -d /run/systemd/system ]; then
                  systemctl --system daemon-reload >/dev/null || true
          fi

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?

Patrick · February 5, 2018, 9:12pm

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.