Hi Jérémy! On Thu, 07 Jun 2007, Jérémy Bobbio wrote:
> Even if it's a wishlist bug, I still have received nothing about your
> opinion on #421148.
Sorry for my silence, I'm still considering how to work with this...
> The patch is working fine for me, and I really think that it would
> be a great addition to privoxy in Debian.
My problem is, that I don't know whether such an option is a good
direction for the package. As a user, who has privoxy activated all
the time, this doesn't work for me personally, because using tor all
the time is too slow for me. It seems to me, that you see privoxy
only as an add-on to tor (in this situation your suggestion makes
sense to me), which you may enable/disable using tools like the
switchproxy firefox extension.
My setup looks a little bit different: I have two instances of privoxy
running (one on 8118 and the other on 8119), where the former proxies
to our company proxy server while the latter proxies to tor. I can
toggle between these two with switchproxy firefox extension.
To make tor really safe, the two instances use different configuration
files. The 8118 one uses the default config (with small local changes),
while the 8119 one uses the following actionsfiles: standard,
global-tor.action (advanced settings from standard.action), and
user-tor.action. Note that no "default.action" file with all the
exceptions was included.
Such an setup seems to be quite usable to me (at least for what I use
tor), but it's far away from anything that's simple to package.
I thought about simply adding your patch to the package, but I'm not
sure which drawbacks the usage of ucf and debconf driven config file
modification implies to updates of the package. One of my problems
with privoxy is, that upstream modifies the config file quite often,
while at least my setup with a modified listen-address,
enable-remote-toggle, enable-edit-actions, several
[permit|deny]-access and forward rules forces me to merge these
setting on every config file update. I'm not sure, whether this gets
harder with ucf and two versions of the config file (with/without
tor).
On the other hand, if we start configuring privoxy at installation
time using debconf, shouldn't the user asked for all other locally
configurable settings like listen-address, enable-remote-toggle,
enable-edit-actions, several [permit|deny]-access, and alternative
forward rules at installation time (as I said, I personally modify
these every time I upgrade the config file)? Can this be handled by
ucf without big trouble?
I also thought about splitting config into several parts and place
them in a config.d directory and build a new config by concatenating
the parts on privoxy startup to make upgrading easier when upstream
changes the config file, but I'm not sure whether this is really a
good idea since upstream doesn't support multiple configuration files
or includes.
On the other hand this would allow you to provide a
/etc/privoxy/config.d/99forward-tor file (maybe simply as part of the
the tor package), which contains
forward-socks4a / localhost:9050 .
So you may see, that I really thought about all this, but didn't find
a perfect solution. At least I'm not sure, whether your suggestion
causes trouble on upgrading and conflicts with other ideas.
> If you are too busy at the moment to upload a new version of the
> package, I could also do a NMU. Just tell me.
I'd like to study the ucf documentation first to understand whether
this leads me into a one-way, which implies big trouble on upcoming
config file upgrades.
Tschoeeee
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
pgpkSLjOrPZ18.pgp
Description: PGP signature
