On a machine behind a firewall enforcing the use of a web proxy, like
the setup I have in my lap (simulating schools around the country), the
LTSP plugin scripts are unable to use wget and similar tools to check
what they can reach on the web.

The fix is to add code similar to the one in base-installer, where
http_proxy and https_proxy is passed on when set.  See
<URL: http://anonscm.debian.org/cgit/d-i/base-installer.git/tree/debian/bootstrap-base.postinst >.

Please add code similar to this in the ltsp-client-builder postinst:

  load_proxy_conf() {
    db_get mirror/protocol || true
    local PROTOCOL="$RET"
    if [ "$PROTOCOL" = "http" ]; then
        db_get mirror/http/proxy
        http_proxy="$RET" || true
        if [ "$http_proxy" ]; then
            export http_proxy
        fi
    fi
    if [ "$http_proxy" ] ; then
        logger "info: using http_proxy=$http_proxy."
    else
        logger "info: no proxy used."
    fi
  }
  load_proxy_conf

The function is similar to the one we provide in /lib/debian-edu-common
within d-i from the debian-edu-install package. :)

By the time ltsp-client-builder runs, apt should be configured in the
installed system, and the http-proxy plugin should use the proxy
configured in apt:

  /usr/share/ltsp/plugins/ltsp-build-client/Debian/010-http-proxy

It doesn't currently have code for https_proxy, but it would be
reasonably easy to add. In the apt configuration, there's also
ftp_proxy, not sure if that's needed as well.

This is feasible to add, although I'd like to know why it isn't working
with the plugins already in place...


live well,
  vagrant

[Vagrant Cascadian]

Right.  But I guess it is running too late. :(

We use http now for everything, so Debian Edu do not need the ftp
proxy nor the https proxy.  But I agree, settig them all would be
fine. :)

The wget call in the script
<URL: https://anonscm.debian.org/cgit/debian-edu/debian-edu-config.git/tree/share/ltsp/plugins/ltsp-build-client/Debian-custom/000-arch-detection >
got stuck because wget did not use the proxy set in d-i.  I had to add
a timeout to avoid a endless hang.

...

I don't think this is appropriate to fix in ltsp-client-builder, as it
won't work when running outside of debian-installer.

I'd suggest fixing the above 000-arch-detection script to set the proxy
in the same way the http-proxy plugin is doing:

        if [ -z "$http_proxy" ]; then
                eval $(apt-config shell http_proxy acquire::http::proxy)
                [ "$http_proxy" = "false" ] && http_proxy=""
                export http_proxy
        fi

The 000-arch-detection script you've referenced also abuses the
commandline processing internals ($option_*_value) which means you're
overriding the commandline options specified by the user, for what it's
worth.

live well,
  vagrant

[Vagrant Cascadian]

I thought ltsp-client-builder was a udeb only to be used inside
debian-installer?  In what other environment is ltsp-client-builder
used?

Good idea.

Control: tags -1 wontfix

ltsp-client-builder udeb is essentially a wrapper around the
ltsp-build-client commandline tool. By setting the http_proxy variable
in the udeb, it doesn't resolve the issue when running the tool from the
commandline.

live well,
  vagrant

[Vagrant Cascadian]

Sure.  But in this case, my proposal is to set the proxy to the value
used by debian-installer when running as part of debian-installer.
This is different from and should be different from running it on the
command line outside debian-installer, as the values from d-i should
be used in this environment.

Outside d-i, I would expect ltsp-build-client to inherit proxy values
from the current environment, and this work already as far as I can
tell.

But ltsp-build-client does use the proxy configured in apt regardless of
weather it's running in debian-installer or not, and apt is configured
by debian-installer...

But the script you referenced earlier would fail when run outside of
debian-installer, because it runs before the proxy values are set in the
ltsp-build-client plugins.

Given that the only code that breaks here is not part of LTSP, I think
it is appropriate to fix it in that code, not in LTSP.


live well
  vagrant