On Mon 12 Sep 2022 at 18:57:40 (+0100), Adam Weremczuk wrote:
> On 12/09/2022 16:42, David Wright wrote:
> > On Mon 12 Sep 2022 at 14:33:59 (+0100), Adam Weremczuk wrote:
> > > Switching to apt-cacher-ng brings no immediate joy :(
> > > 
> > > CLIENT (192.168.100.243)
> > > sudo apt update
> > > Err:5 http://192.168.100.1:3142/security stretch/updates Release
> > >    503  DNS error for hostname security: No address associated with
> > > hostname. If security refers to a configured cache repository, please
> > > check the corresponding configuration file.
> > > E: The repository 'http://192.168.100.1:3142/security stretch/updates
> > > Release' does not have a Release file.
> > 
> > I would expect to see lines like:
> > 
> > Get:2 http://security.debian.org/debian-security bullseye-security/main 
> > amd64 libgdk-pixbuf-2.0-0 amd64 2.42.2+dfsg-1+deb11u1 [147 kB]
> > 
> > but with stretch/updates rather than bullseye-security, of course,
> > as the syntax was regularised.
> > 
> > > SERVER (192.168.100.1)
> > > 1662988978|E|769|192.168.100.243|security/dists/stretch/updates/InRelease
> > > [HTTP error, code: 503]
> > > 1662988978|M|Download of security/dists/stretch/updates/Release aborted
> > > 
> > > Why a DNS error if I use IPs internally for this exercise?
> > 
> > AFAIK apt-cacher-ng still needs to make contact with debian-security
> > as part of the process.
> > 
> > > Is there something wrong with sources.list on the SERVER:
> > > 
> > > deb http://ftp.uk.debian.org/debian stretch main contrib non-free
> > > deb-src http://ftp.uk.debian.org/debian stretch main contrib non-free
> > > deb http://security.debian.org/ stretch/updates main contrib non-free
> > > deb-src http://security.debian.org/ stretch/updates main contrib non-free
> > 
> > Mine were as attached, with an extra part to security's address.
> > 
> > > sudo apt update
> > > Ign:1 http://ftp.uk.debian.org/debian stretch InRelease
> > > Ign:2 http://hwraid.le-vert.net/debian stretch InRelease
> > > Hit:3 http://ftp.uk.debian.org/debian stretch Release
> > > Get:4 http://security.debian.org stretch/updates InRelease [59.1 kB]
> > > Fetched 59.1 kB in 0s (119 kB/s)
> > > Reading package lists... Done
> > > Building dependency tree
> > > Reading state information... Done
> > > 381 packages can be upgraded. Run 'apt list --upgradable' to see them.
> 
> I've tried your list and the server updates fine.
> 
> On a client I see again:
> 
> sudo apt update
> Ign:1 http://192.168.100.1:3142/debian stretch InRelease
> Ign:2 http://192.168.100.1:3142/debian-security stretch/updates InRelease
> Hit:3 http://192.168.100.1:3142/debian stretch-updates InRelease
> Hit:4 http://192.168.100.1:3142/debian stretch-backports InRelease
> Hit:5 http://192.168.100.1:3142/debian stretch Release
> Err:6 http://192.168.100.1:3142/debian-security stretch/updates Release
>   503  DNS error for hostname debian-security: Name or service not
> known. If debian-security refers to a configured cache repository,
> please check the corresponding configuration file.
> Reading package lists... Done
> E: The repository 'http://192.168.100.1:3142/debian-security
> stretch/updates Release' does not have a Release file.
> N: Updating from such a repository can't be done securely, and is
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user
> configuration details.
> 
> It looks like there is something wrong with debian-security repo
> specifically.

Did you change your sources.list on the client to make it the same as
the server's?

In case it's not clear, sources.list is not changed for apt-cacher-ng.
You tell it to use the proxy either manually, eg:

# apt-get -o Acquire::http::Proxy="http://192.168.1.14:3142/"; …

of through /etc/apt/apt.conf (or, better, a file in /etc/apt/apt.conf.d/):

Acquire::http::Proxy "http://192.168.1.14:3142/";;

For a laptop, you can turn proxying on and off with the "tricks" shown in
§8.13 of the User Manual in the docs (if it's not the server, of course).

BTW, from what you have posted, it may have escaped you that the
server should also be a client, with its proxy address set to the same
address as all the other clients. That will halve your bandwidth.
Keep that in mind in the penultimate paragraph.

> Could the fact that the client has no internet connectivity play a role?
> I would imagine this is a typical scenario where you want to use apt-cacher.

That implies that neither client nor server have access to the
internet, doesn't it? It's not something I've tried to do as the
internet is effectively always on here, so I'm not certain.

Going right back to the days of dial-up, I played around with apt-move
for a while, but after I had access to Zip® drives and a Jaz® drive,
I just copied /var/cache/apt/archives at work (on Janet) and ran
dpkg -i   at home to install them. (The   apt install ./foo.deb
command wasn't available back then.)

My guess is that most people use apt-cacher-ng as I do, to serve a
number of clients (including itself) on a LAN, saving their own
bandwidth and that of the Debian servers/mirrors.

One word of advice: serving to clients running a more recent
distribution from a server running an older one can cause problems,
because of minor improvements that are sometimes made in the way
the archives and the cache are handled and stored.

Bear in mind that if you install a new distribution from scratch,
and then start running apt-cacher-ng on it, you can feed the contents
of its own /var/cache/apt/archives/ (from the installation) into its
new cache by copying the debs into /var/cache/apt-cacher-ng/_import/
(ibid §8.1). So run   apt update   on the new server (with proxying
set) and an old client.

You can also feed it all the previous distribution's packages if you
still them to copy in the same way. But in this case, an old client
will need to run   apt update   *before* apt-cacher-ng will be able
to move the debs from …/_import/ into their places in its cache.

Cheers,
David.

Reply via email to