A detailed instruction has been written in the new /etc/tor/torrc file (in Whonix, the path is /etc/tor/torrc.anondist-orig) shipped with the Tor nightly:
## Configuration options can be imported from files or folders using the %include
## option with the value being a path. If the path is a file, the options from the
## file will be parsed as if they were written where the %include option is. If
## the path is a folder, all files on that folder will be parsed following lexical
## order. Files starting with a dot are ignored. Files on subfolders are ignored.
## The %include option can be used recursively.
#%include /etc/torrc.d/
#%include /etc/torrc.custom
Should we change a way to organize the tor configuration files in Whonix?
if so, we probably also need to do minor changes on other related/influenced part, eg. the command line used to restart/reload Tor?
ps. It seems updating to Tor nightly in Whonix will not update the /etc/tor/torrc file automatically. I will investigate on this and post the findings below
Definitely. Waiting for this feature for a long time.
Once Debian ships the includes by default in /usr/share/tor/tor-service-defaults-torrc, Whonix should config-package-dev undisplace/usr/share/tor/tor-service-defaults-torrc.anondist so we are back to using Debian defaults.
And Whonix’s settings which are currently in tor-service-defaults-torrc because there was no .d support should be moved into the appropriate new place.
Meanwhile for Whonix 14 we should probably add the include to Whonix’s current tor-service-defaults-torrc so anon-connection-wizard can work. The include we add should be probably be the very same what Debian is going to add. So we later won’t have to bother with a folder migration.
If not already done in Debian tor master… Could you please post a Debian feature request against the tor package so they’ll add parsing include to /usr/share/tor/tor-service-defaults-torrc?
Dunno why that would be required, but “perhaps so yes”.
at least from version 0.3.2.0-alpha-dev, both /etc/tor/torrc.anondist-orig in Whonix and /etc/tor/torrc in debian8 will include the instruction on include feature.
However, the feature has not been enabled in /usr/share/tor/tor-service-defaults-torrc.
Agree! I will keep up with what include path will be added by Debian.
Sure thing! But please forgive my ignorance on this problem. It seems Whonix is using the Tor from:
deb http://deb.torproject.org/torproject.org jessie main
deb-src http://deb.torproject.org/torproject.org jessie main
So the upstream of the problem should be tpo instead of Debian?
Also, teor said on the @tor-dev that:
You probably need a %include directive in /etc/tor/torrc.
If you get this working, please submit a patch to the Debian bug tracker.
Should the include be added to /etc/tor/torrc or /usr/share/tor/tor-service-defaults-torrc? Or we can leave it for Debian to decide?
Up to Debian to decide. I would hope they go for tor-service-defaults-torrc and guess they will. Otherwise still better to go with Debian, to keep the delta of Whonix to Debian small. So Whonix keeps simpler and better understandable. Less complexity. Unless going for these goals creates a bigger mess than deriving from it.
It’s a good question. The packager of deb.torproject.org is the same as tor from packages.debian.org. If that change is made in Debian, it probably flows back to Tor Project. This was my thinking. However, asking Tor Project about deb.torproject.org is a good idea as well.
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.
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: torrc_format.txt\doc - tor - Tor's source code
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.
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.
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.
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).
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.torrcUseBridges 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?)
