Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#4552 closed enhancement (implemented)

Have a "defaults" torrc file and a regular one

Reported by: nickm Owned by: nickm
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: config torrc tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

(Since I'm hoping to implement this, let's make a ticket. Hoping it's not a duplicate.)

Tor could support up to two torrc files: one installer-provided "defaults" file, and one user "torrc" file. Additionally, the user could provide arguments from the command line as they can today. These three places to put options would constitute three "zones" or "configuration sources" or something: "defaults", "torrc", and "cmdline".

The behavior for reading them would be as follows:

  • Any option set in cmdline would override torrc and defaults; any option set in torrc would override defaults.
  • This goes for linelist options too. For example, if the defaults exit policy was "ExitPolicy reject *:*" and the torrc had "ExitPolicy accept *:80\nExitPolicy reject *:*", then the torrc's ExitPolicy would _replace_ the defaults exit policy. Or if the torrc had "SocksPort auto" and the command line had "SocksPort 9050", then there would be exactly one socksport, as specified by the command line. This would be new behavior.
  • The behavior on saveconf would be to compute every option that differed from what its value had been after reading "defaults", and store that option's new value to "torrc".
  • HUP and equivalents would reload all options.

Unknown behaviors:

A) should SAVECONF store stuff that was on the command-line?
B) Where do we look for the defaults file?

What would be most useful at this point would be to confirm whether this approach would work for vidalia, TBB, arm, others.

Child Tickets

Change History (6)

comment:1 in reply to:  description Changed 7 years ago by arma

Replying to nickm:

(Since I'm hoping to implement this, let's make a ticket. Hoping it's not a duplicate.)

How does this design compare with #1922? Seems like #1922 allows more flexibility, e.g. a bridge "package" that adds a torrc file that makes you into a bridge.

comment:2 Changed 7 years ago by nickm

The difference is that this one actually has defined behavior for SAVECONF, and I can implement it by the end of the month. :)

comment:3 Changed 7 years ago by nickm

Status: newneeds_review

Please have a look at the multilevel_cfg branch in my public repository ; it may do the right thing here.

comment:4 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

It still looks okay to me, and still works in my testing. merging it.

comment:5 Changed 7 years ago by nickm

Keywords: tor-client added

comment:6 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.