Bug#366715: installation-report: Installer gets stuck if it can't access security.debian.org
On Wed, 2006-05-10 at 16:38 -0400, Joey Hess wrote:
> John Winters wrote:
> > I'm trying to use the Debian Installer etch beta 2 to install systems
> > within a fairly tightly firewalled network.
> >
> > Although the installer prompts to ask what repository it should use for
> > the main packages it then tries to use a hard-coded source (presumably
> > security.debian.org) to check for security updates, without first
> > seeking permission to do this or guidance on how to do it.
> >
> > In our network, this fails (slowly) because all direct outgoing http requests
> > are dropped at the firewall. After a significant delay a message
> > appears explaining what has happened and offering the option to continue
> > (it advises that the problem should be investigated and corrected
> > later). If one then selects the "Continue" button, nothing further
> > happens. The installation process does not move on and there's no way
> > to get back to the menu.
>
> You need to wait for it to time out a second time. This problem has
> already been fixed in apt-setup 0.10 unstable, which will only have the
> first timeout and not the second.
Glad to hear it.
>
> > 1) Ask before attempting to get security updates. (Obviously default to
> > yes).
>
> There's no good reason to ask.
Well, no - clearly there is a good reason to ask.
> If the machine is network connected it
> should make every possible effort to use security updates,
True, and by failing to ask it is not making every possible effort to
use them.
> doing anything else is asking to be insecure.
Because it doesn't ask the current behaviour is *less* secure than it
could potentially be. The updates are there and available to be
installed, but by being inflexible the installer *prevents* me using
them.
> If you really want to disable it, you can preseed
> apt-setup/security_host to an empty string, as documented in the
> installation manual.
Where? I've read all the apparently relevant chunks of the installation
manual but can find nothing like that documented in it. I've even had a
fresh look now that you've told me it's there, and I still can't find
it. The problem with a very large manual like that (with no index) is
that it's only really useful to the person who wrote it, and thus who
knows what's there.
> > 2) Ask where to get them from. I have a local copy of them but there
> > seems to be no way to tell the installer to use this local copy.
>
> apt-setup/security_host can be used to override this.
> However, the security team doesn't like mirrors of security.debian.org,
> and asking that kind of question in any regular install is counter to
> our UI guidelines. We try to avoid asking questions when there's a
> default that will work for 99.99% of users.
>
> > 3) Ask for proxy information. This can (and in our case does) differ
> > from the proxy information needed to access the main package repository.
> > Obviously again - default to the same proxy information as previously
> > entered.
>
> While it seems that apt might support per-host proxy settings, I think
> you'd be better off fixing your network. I doubt that anyone else will
> ever have such a setup,
Clearly you have little experience of real-world networks. This is just
the sort of problem which a non-admin on a Windows network has to deal
with on a daily basis.
If you have administrator access it's easy, but if not it's hard to
impossible. Yes, the particular network on which I was trying to do it
is badly set up, but the problem is equally the fault of bad defaults in
the Debian installer. Just saying, "It's the other components fault -
fix that" is the worst form of buck-passing.
Sorry to be short, but it's been a long and hard day and you need to
realise that a response like yours does the Debian project (which I
greatly admire) absolutely no favours.
John
--
John Winters, Wallingford, Oxon, England
i = (free (NULL); i++);
Reply to: