apt-cacher in main

[Kevin Fries]

On Wed, 2007-11-14 at 18:27 -0500, Scott Abbey wrote:
> I think the point of moving it is so that it receives official support from
> Canonical. That way those on paid support contracts can still expect
> assistance from Canonical when using the package. Canonical only provides
> paid support for packages in main and restricted. Universe and multiverse
> receive community support only.

Ahhh (he says with bells going off like a Las Vegas slot machine)

In that case, I would like to second that motion.  Especially with Jeos
coming out.  Not all VM need to have a public facing.  I often set up
servers in a VM based environment where one or more machines are not
given access to the outside network (only internal networking between
the virtual machines).  Without apt-cacher you either need to allow that
machine access to the Internet, or do without updates.

Example:  Several VMs use a central set of accounts.  You store those
accounts in LDAP.  If the LDAP server only has networking between the
VMs, you do not have to worry about setting up TLS.  But the second that
machine has external visibility, TLS it mandatory.  Any time you can
relax the security, things run faster and more reliably.  So, by putting
that LDAP server in an inaccessible place, allows you to run without all
those layers of security (good design trumps good security every time).

Given this example, the machine with no external network support, can
use whichever machine has apt-cacher as a proxy to get updates, without
compromising its security.  Given the announcement of Ubunut Jeos,
moving apt-cacher to a place where it will get support.

But I still think it would be cool if the install process scanned the
local net looking for any machine with port 3142 open, and reconfigured
apt to use the cache by default.

-- 
Kevin Fries
Senior Linux Engineer
Computer and Communications Technology, Inc
A Division of Japan Communications Inc.