apt-cacher-ng and aptly

[foom...@gmail.com]

Hi,

Anyone had experience of using apt-cacher-ng against a repository created with aptly?

Cheers,

Matt

[Alexander Dupuy]

On 2014-06-04, at 14:47, foom...@gmail.com wrote:

Anyone had experience of using apt-cacher-ng against a repository created with aptly?

No, but I am about to set up a (non-“NG”) apt-cacher instance as a a front end that will direct certain prefixes (e.g. ubuntu) at the standard Ubuntu archives, while other prefixes will be directed to a local aptly repository.

I’m doing this for two reasons - one is that I don’t want to waste disk space mirroring the entirety of the base precise/trusty repositories (for both 64- and 32-bit) since *they will never change* (so snapshot functionality is uninteresting).  I will use aptly mirrors and snapshots only for the {precise,trusty}-{security,updates} components, using local prefixes in my /etc/apt/sources.list like this:

deb http://repo.example.net/ubuntu/ trusty main universe restricted multiverse

deb http://repo.example.net/mybuntu-main/ trusty-security main

deb http://repo.example.net/mybuntu-universe/ trusty-security universe

deb http://repo.example.net/mybuntu-main/ trusty-updates main

deb http://repo.example.net/mybuntu-universe/ trusty-updates universe

(The need for “mybuntu-main” and “mybuntu-universe” is because of aptly’s current inability to publish

multiple components to a single prefix - https://github.com/smira/aptly/issues/36 - once that is solved,

I can merge the prefixes into “mybuntu” and let apt-cacher’s PATH_MAP functionality support the old ones).

The other reason for using apt-cacher is that it allows me to just use the “non-production” `aptly serve` HTTP server, since apt-cacher will be handling the client requests, and I can avoid having to set up a “real” HTTP server like Apache or nginx.

[“mybuntu” is just a placeholder for the real, better, names, just like example.net, of course]

I don’t expect any major difficulties with this approach, but will certainly file issues and can share details directly or on this list.

@alex

[Alexander Dupuy]

Constantin <asu...@gmail.com> wrote:

Have you had any luck setting up apt-cacher with aptly?

Yes, I did do this and it worked quite well.  I used the basic `aptly serve` on port 8080, and put standard Ubuntu apt-cacher (no NG) on port 80, as I didn’t need any other web service on this host.

I am also trying to re-map security.debian.org using:

Remap-debsec repo-aptly.visma.com:8080 /debian-security

Have you tried this ?

The systems that were using this repo server had a customized /etc/apt/sources.list, so I didn’t need to do anything very tricky (like remapping) on the server; I used a custom prefix for the aptly repos, e.g.:

deb http://aptly.example.net/ubuntu/ precise main universe restricted multiverse

deb http://aptly.example.net/rev34/ precise-security main universe

deb http://aptly.example.net/rev34/ precise-updates main universe

And I just put something like the following in /etc/apt-cacher/apt-cacher.conf on the server “aptly.example.net” (name changed):

path_map = ubuntu archive.ubuntu.com/ubuntu rev34 localhost:8080/rev34 rev35 localhost:8080/rev35

When I needed to roll out a tested update snapshot, I just bumped the “rev#” in the clients’ sources.list files and the next auto-update would pull the aptly-snapshotted version of (security) updates.

@alex

[Constantin]

This is working, to remap string to aptly repo.

But this involves to make changes to the source list.

I was more interested to map security.debian.org to aptly.

If you try:

path_map = security.debian.org http://debian-repository-aptly:8080/

The requests are reaching the aptly server, but on the client apt gives the following error:

E: GPG error: http://security.debian.org wheezy/updates Release: The following signatures were invalid: NODATA 1 NODATA 2

Did you meet this situation/error ?

Regards.