torrc.d is comming

Development
16

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 :slight_smile:

1 Like
17

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!

1 Like
18

iry:

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.

2 Likes
19

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 :slight_smile:

2 Likes
20

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

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