Package: apt-cacher
Version: 1.7.6
Severity: important
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
We are rolling out an Emdebian-based project in a LAN with weak internet
connectivity, so caching of packages is a substantial requirement for fast
redeployments of our test images. Apt-cacher was shown to be a pretty good
fit for our usecase, though with a nit...
* What exactly did you do (or not do) that was effective (or
ineffective)?
While exploring our options, we brought over mirrors of (Em)Debian
repositories and deployed as local mirrors. There is also a corporate HTTP
proxy to access the internet for i.e. updates.
It is possible to configure a "localhost" or otherwise local server as a
backend server for a source (via "path_map") and use it if "use_proxy=0".
However, the internet sources are not accessible because explicit use of
the proxy is required by corporate networking.
It is possible to configure the internet sources like "ftp.XYZ.debian.org"
as backend servers for the sources and access them with "use_proxy=1".
However, the local (faster) mirrors of available packages, as well as
origin repositories of our own development, are thus inaccessible for
apt-cacher - because the corporate proxy does not relay those local
resources (hosted on each developer's "localhost" in the extreme case - and
obviously resolving to a different system by the corporate proxy server).
* What was the outcome of this action?
We could not simultaneously configure to use some sources accessible only
without an HTTP proxy and some requiring one.
For developer notebooks that travel from corporate to open networks and
back, it would also be very beneficial to have dual access attempts (with
and without proxy) to some but not all resources (internet origin servers).
* What outcome did you expect instead?
Accessibility of both local (direct) and internet (proxied and/or direct)
origin repository servers with a single configuration of apt-cacher.
It is my understanding that at the moment this separate approach is not
catered for. I believe a proper solution would be to add lists of backend
hosts that should or should not be accessed with an http_proxy, and it
should be valid to have a host listed in both lists (with both ways tried
in this case, if the first attempt over whichever transport fails).
contact: [email protected]
*** End of the template - remove these lines ***
-- System Information:
Debian Release: 7.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt-cacher depends on:
ii debconf [debconf-2.0] 1.5.49
ii dpkg 1.16.10
ii ed 1.6-2
ii libfilesys-df-perl 0.92-4+b1
ii libfreezethaw-perl 0.5001-1
ii libio-interface-perl 1.06-1+b1
ii libnetaddr-ip-perl 4.062+dfsg-1
ii libsys-syscall-perl 0.23-1
ii libwww-curl-perl 4.15-1+b2
ii libwww-perl 6.04-1
ii lsb-base 4.1+Debian8
ii perl 5.14.2-21+deb7u1
ii ucf 3.0025+nmu3
ii update-inetd 4.43
Versions of packages apt-cacher recommends:
ii libberkeleydb-perl 0.51-1
Versions of packages apt-cacher suggests:
pn libio-socket-inet6-perl <none>
-- debconf information:
* apt-cacher/mode: daemon
