vmtests will use the host-configured apt proxy verbatim even if it points at localhost

[Dan Watkins]

I run apt-cacher-ng on my dev machine so that my package builds etc. are faster. The curtin vmtests code picks up my configured apt proxy and passes it in to the VMs under test.

This, unsurprisingly, causes all my test runs to fail because the launched VMs aren't running an apt proxy at localhost:3142.

[Dan Watkins (oddbloke)]

My preferred solution here would be to rewrite localhost to something that would work in the VMs once launched, but that's likely to be hard. If we can't do that, then I think we should just not configure the proxy if it contains "localhost" (and perhaps emit a warning).

[Paride Legovini (paride)]

FYI I implemented a workaround for this some time ago:

https://git.launchpad.net/curtin/commit/?id=8c347f4d8782b63cb18678d17b4250cfefbdaa73

[Ryan Harper (raharper)]

On Thu, Jun 20, 2019 at 12:50 PM Paride Legovini <email address hidden>
wrote:

> FYI I implemented a workaround for this some time ago:
>
>
> https://git.launchpad.net/curtin/commit/?id=8c347f4d8782b63cb18678d17b4250cfefbdaa73
>
>
Dan doesn't want to have to remember this; and I'm included to agree that
if one is
present but has localhost (or 127.0.0.0, or ::1) it's fair to skip
configuring it and
emit a warning since it would be unreachable.

Can anyone think of a case where we can use a local bound proxy in the
target?

> --
> You received this bug notification because you are subscribed to curtin.
> Matching subscriptions: curtin-bugs-all
> https://bugs.launchpad.net/bugs/1833575
>
> Title:
> vmtests will use the host-configured apt proxy verbatim even if it
> points at localhost
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/curtin/+bug/1833575/+subscriptions
>

[Dan Watkins (oddbloke)]

Remembering would become less annoying with https://code.launchpad.net/~daniel-thewatkins/curtin/+git/curtin/+merge/369101, because I can just set CURTIN_VMTEST_APT_PROXY in my .zshrc, but I still think it's worth saving people from a confusing/annoying first set of failures if they do have a local proxy configured for their host.

> Can anyone think of a case where we can use a local bound proxy in the target?

I can't, but I propose that we only skip a local-bound proxy if we fall through to using the apt configuration on the host. That way, if people really do want to use a local-bound proxy, they can still use `apt_proxy=http://localhost:8000` to configure it _explicitly_.

What do people think?

[Ryan Harper (raharper)]

On Thu, Jun 20, 2019 at 1:40 PM Dan Watkins <email address hidden>
wrote:

> Remembering would become less annoying with https://code.launchpad.net
> /~daniel-thewatkins/curtin/+git/curtin/+merge/369101, because I can just
> set CURTIN_VMTEST_APT_PROXY in my .zshrc, but I still think it's worth
> saving people from a confusing/annoying first set of failures if they do
> have a local proxy configured for their host.
>
> > Can anyone think of a case where we can use a local bound proxy in the
> target?
>
> I can't, but I propose that we only skip a local-bound proxy if we fall
> through to using the apt configuration on the host. That way, if people
> really do want to use a local-bound proxy, they can still use
> `apt_proxy=http://localhost:8000` to configure it _explicitly_.
>
> What do people think?
>

Yes that sounds right. An explicit apt_proxy/CURTIN_VMTEST_APT_PROXY
we use verbatim otherwise as you suggest.

>
> --
> You received this bug notification because you are subscribed to curtin.
> Matching subscriptions: curtin-bugs-all
> https://bugs.launchpad.net/bugs/1833575
>
> Title:
> vmtests will use the host-configured apt proxy verbatim even if it
> points at localhost
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/curtin/+bug/1833575/+subscriptions
>