[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Please review vidalia debconf template



Dererk wrote:
> Justin B Rye wrote:
>>    Vidalia needs to communicate with the Tor daemon so that it can provide a
>>    graphical user interface for it. This can work in either of two ways:
>>     * let Vidalia start the Tor process
>>       (simple but not usable on a multi-user system);
>>     * give Tor a control port to communicate with Vidalia
>>       (recommended to prevent privilege escalation security exploits).
>>    For more information see "/usr/share/doc/vidalia/README.Debian".
[...]
>>   Template: vidalia/tor-daemon-interaction
>>   Type: select
>>   Choices-C: controlport, auto, manual
>>   __Choices: Control port, Auto-restart, Manual restart
>>   Default: control-port
>>   _Description: Vidalia/Tor communication method:
>>    Tor is already running. Please select a method to allow Vidalia to
>>    communicate with the Tor daemon.
>>     * Control port: leave Tor running and communicate via a control port
>>       (recommended on a multi-user system);
>>     * Auto-restart: stop Tor and let Vidalia start it (now and
>>       automatically on reboots, so that Tor is always running);
>>     * Manual restart: stop Tor and just let Vidalia start it whenever
>>       you run Vidalia.
[...]
> The very reason of the 'type:note' template to exist, was intended to
> give the user some background information about what the next question
> was to be talking about, why the user should care about changing some
> other software configuration, and such.

It seems to me the best thing to do with the information I need to
answer the next question is to arrange for it to be on my screen
while I'm making the decision...

In fact since the note only lists two options while the select
template offers three I'm finding it hard to see how they fit
together.

> I think I agree about some junk pieces, but appeared to me to bring them
> contextualization.
> 
> In that way, I try to make the user take a quick look at README.Debian,
> containing quick and painless information (not present in the current
> pkgs at archive), between other things, explaining different
> "communication methods", more than the template was mentioning.
> 
> Basically (and unfortunately I've realised I've never mentioned on none
> of both templates), the reason to raise this information at templates is
> found on the fact that most recommended option requires from some user
> interactions on running some process and editing *other* configuration
> files than this package's (tor's configuration).
> 
> I don't really would like to mention "control-port" as _an option_, I
> would rather stay at a "other methods" or something like that, because
> between other things, the older "no"-option included more than the
> "control-port" one (explained on the README.Debian file).

Does this mean that option one is in effect "leave vidalia/tor
communication unconfigured (see README for manual setup)"?

> Hope this explanation give a more practical context to most of the
> questions, please tell me if you require me to interact with some of
> your other questions in this mail or if they're for other list member's
> to debate (I don't really know how this works, thanks for being merciful
> :-) )

It's possible someone else on the list happens to know the answers,
but otherwise I'll keep guessing.

Another try, explicitly merging the note with the select template.
I'm also trying to organise it so it still makes sense in
dpkg-reconfigure runs after the user has made the required changes.

   Template: vidalia/tor-daemon-interaction
   Type: select
   Choices-C: foo, bar, baz
   __Choices: No restart, Automatic restart, On-demand restart
   Default: foo
   _Description: Tor restart scheme (for Vidalia):
    Vidalia needs to communicate with the running Tor daemon so that it
    can provide a graphical user interface for it. This requires either
    the manual reconfiguration of Tor to allow a secure connection
    (recommended) or a restart of Tor under Vidalia's control.
    .
    Please select a scheme:
     * No restart: leave Tor running for now. Vidalia will not be
       able to communicate with it until reconfigured - see
       "/usr/share/doc/vidalia/README.Debian";
     * Automatic restart: stop Tor now and let Vidalia start it (now
       and on reboots, so that Tor is always running);
     * On-demand restart: stop Tor and simply let Vidalia start it
       whenever you run Vidalia.

-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: