Bug#261415: network installation always asks for proxy
On Mon, Jan 23, 2017 at 10:33:38AM +0100, Philip Hands wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
>
> > On Fri, 28 Feb 2014 23:49:59 +0100 Cyril Brulebois <kibi@debian.org> wrote:
> >> Martin Pitt <martin@piware.de> (2004-03-24):
> >> > - network installation always asks for proxy; I know what a proxy is,
> >> > but not all potential users may; would it be possible to try without
> >> > proxy first and ask for proxy settings only if direct connection
> >> > does not work? Never mind if that is not possible, just asking :-)
> >>
> >> Some translations have a less-techy way of explaining what a proxy is,
> >> and a default empty value should just be OK (people are expected to
> >> install Debian by pressing Enter most of the time, right? :)). I'm not
> >> sure we want to play with trial-and-error in d-i too muchâ?¦
> >>
> >> Tagging wontfix for now to allow for somebody to step up and say
> >> otherwise.
> >
> > I do think we ought to attempt autodetection for this. As long as a
> > means exists for preseeders and expert installs to specify one anyway
> > (for optional caching proxies), autodetecting by default seems like a
> > good idea, to eliminate one of the more highly technical questions in
> > the install.
>
> I've certainly been behind site-wide filtering that plays badly with
> package downloads, where someone in the IT department has routed round
> that by setting up a secret ADSL line that can be used if one specifies
> a proxy using IP:port that's scribbled on the office whiteboard.
>
> I suspect that pretty-much any test you can think of will result in you
> going via the filter, and thus getting really dire download rates (In
> the case I'm thinking of ~20kbits/s on a 10Gbit/s line, out-of-hours --
> the filter was also not caching its own results, so it didn't even speed
> up for subsequent downloads)
Bypassing someone's local caching proxy would similarly make someone
unhappy. However, that scenario seems sufficiently rare compared to the
common case that I think we can tell people, via release notes, that
they should either do an expert install or otherwise specify the proxy
another way. Or, as you sugest below, let people cancel and go back.
> Making it difficult to perform a test install on such a site will drive
> new users elsewhere.
>
> Of course, incomprehensible questions will also drive users elsewhere,
> so we need to make sure that people understand that they almost
> certainly don't care, unless they already know that they do care.
>
> I could imagine using auto-detection to populate default values for a
> site's proxy, assuming that the software to achieve that has a decent
> chance of success, and isn't too big.
In the general case, you'd need a Javascript interpreter. :)
> Alternatively, one could make sure that the subsequent package download
> progress page made it clear that it would be safe to cancel that, and
> that doing so would let one back up and specify a proxy to go via and
> then retry the install -- that would let the person looking at a
> download that's going depressingly slowly plenty of time to remember
> that they have a faster alternative, and the reassurance that they can
> switch to it without having to start the install from scratch (assuming
> we can get the code to work that way).
That sounds reasonable.
- Josh Triplett
Reply to: