Package: autopkgtest
Version: 5.49
Severity: normal
When building an image with autopkgtest-build-qemu, having
auto-apt-proxy installed triggers successful proxy configuration in the
guest, but this then breaks user scripts that run apt operations.
For example, on a host with approx (port 9999) and auto-apt-proxy
installed, a minimal user script with
chroot "$1" apt-get update
will eventually fail with
Could not connect to 10.0.2.2:9999 (10.0.2.2), connection timed out
Unable to connect to 10.0.2.2:9999
Per the log, at the time the script is run, the environment contains
AUTOPKGTEST_SETUP_APT_PROXY=http://127.0.0.1:9999
http_proxy=http://127.0.0.1:9999
AUTOPKGTEST_APT_PROXY=http://10.0.2.2:9999
Because the user script is run after setup-testbed, it would seem that
the generated /etc/apt/apt.conf.d/01proxy, using AUTOPKGTEST_APT_PROXY
from above, triggers this behavior.
I don't have a solution in mind yet. Splitting setup-testbed to run some
tasks after the user script would be an overkill that could also affect
third-party utilities that rely on setup-testbed.
A hacky way to do this would be for autopkgtest-build-qemu to
temporarily move 01proxy out of the way for running the user script.
This hacky way can also be implemented by user scripts themselves. As a
workaround, my own user scripts temporarily restore the use of
AUTOPKGTEST_SETUP_APT_PROXY:
chroot "\$1" /bin/sh <<EOF
[ -f /etc/apt/apt.conf.d/01proxy ] && mv /etc/apt/apt.conf.d/01proxy /01proxy
if [ -n "\${AUTOPKGTEST_SETUP_APT_PROXY:-}" ]; then
echo "Acquire::http { Proxy \"\$AUTOPKGTEST_SETUP_APT_PROXY\"; };" > \
/etc/apt/apt.conf.d/01user-script-setup-proxy
fi
apt-get ...
rm -f /etc/apt/apt.conf.d/01user-script-setup-proxy
[ -f /01proxy ] && mv /01proxy /etc/apt/apt.conf.d/01proxy
EOF
It's arguable that this is not an autopkgtest bug, but performing APT
operations is arguably one of those things that a user customization
script might typically do.
Best,
Christian
