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

Re: use LB_APT_HTTP_PROXY in debootstrap and for udebs



On Mon, May 28, 2012 at 8:36 PM, Daniel Baumann
<daniel.baumann@progress-technologies.net> wrote:
> On 05/28/2012 09:12 PM, Rui Miguel P. Bernardo wrote:
>> Yes, we need to use those variables you have set in lb_config in
>> lb_bootstrap_debootstrap and lb_binary_debian-installer. With the vars
>> set by lb_config I suppose that's the next step?
>
> they are in the environment now and should be used by default, without
> any modification in the other lb_* stuff (that was the whole point of
> putting them into the environment in the first place). wget,
> cdebootstrap/debootstrap should just pick it up automatically.

I've installed squid proxy here and tested the latest lb_config changes again.
Indeed, it works out-of-the-box with squid, IIF you have http_proxy set
in the environment. If you don't have http_proxy in your environment,
squid is not used for debootstrap nor debian-installer, only in chroot.

That's what was happening when I've tested with apt-cacher-ng 2 days ago.
I don't use http_proxy variable in my system, just apt-cacher-ng with
LB_APT_HTTP_PROXY
option. I remember having troubles with chroot hooks downloads, and also
with sudo (which doesn't preserve user env vars), when I tested
http_proxy variable with apt-cacher-ng, so I don't use it.

I've tested again today, now just with the latest changes in lb_config,
with apt-cacher-ng and with export http_proxy="http://localhost:3142";
before running "lb config". It works IIF the http_proxy is preserved in
sudo or exported into root environment.

Some results:

1. Without having any http_proxy variable set anywhere and just setting
LB_APT_HTTP_PROXY, debootstrap and debian-installer stages will NOT use
neither squid nor apt-cacher-ng proxy. Just chroot stage will use it.

2. If I export http_proxy it will work with both squid and
apt-cacher-ng, but apt-cacher breaks chroot hooks if they download
things from the network (apt-cacher doesn't cache anything but debian
files).

3. It works with both squid and apt-cacher-ng even if I don't export
http_proxy anywhere in the environment and add the following code in the
beginning of lb_bootstrap_debootstrap and lb_binary_debian-installer
scripts:

if [ -n "${http_proxy}" ]
then
        export http_proxy
fi

Since http_proxy is usually set in the envronment for squid users, I
think it's fine to also export http_proxy in lb_bootstrap_debootstrap and
lb_binary_debian-installer.

At least it would safer, in the sense that apt-cacher users could use
LB_APT_HTTP_PROXY without setting http_proxy and without breaking binary
and chroot hooks with it. http_proxy would be only set in those
live-build scripts and would not interfere with chroot or binary hooks.
And it would work for both squid and apt-cacher users and also for sudo
users, since the http_proxy variable would not need to be preserved.

Ofcourse, that's what I find here. I can be wrong. I still didn't tested if this
would break (with apt-cacher) with hooks that make downloads, but it shouldn't.
The only problem I see is in lb_binary_debian-installer, with sparch
architecture,
which downloads a mini.iso file, and that would only happen with apt-cacher.

What do you guys think about this? Is this doable this way? With export in the
scripts? (/me ducks).

BTW, for a standard debian live-build

        lb config -d squeeze -a i386 --linux-flavours 486 \
                --archive-areas "main contrib non-free" \
                --debian-installer live

the time saved was about 3 minutes with a fast mirror. With 2
linux-flavours (486 and 686) it should be more depending on the mirror
(didn't test it).


Reply to: