Create an APT mirror for internal and production use

[matze]

Description

When provisioning either development boxes or the production system, we always run into the risk of external dependencies being currently unavailable or, in a worst-case scenario, being gone entirely. Especially APT, the Debian/Ubuntu package manager, is something that provides a LOT of dependencies for us (and in fact we have had known issues with it just recently) but should be rather easy to mirror.

Tasks

1. Determine possible APT mirroring software we could use. Since there's plenty, this probably may require a more detailed set of requirements in advance, but getting an overview should be faily easy.
2. Integrate the mirror setup with our infrastructure (create Puppet manifests for it).
3. Migrate at least other modude requiring APT packages, for demonstration purpose.
4. Close this ticket but continue migrating modules (e.g. in additional tickets or while working on them anyway).

Note that 3. might not be applicable; depending on the software we choose in 1. and the setup we create in 2., it may not support partial migration (at least not without explicit apt-preferences on each client), in which case a full-grown, direct migration may become a better option.

[fhd]

I think this would be most useful if we actually control which packages/versions get into the mirror. Like this:

1. We have only one APT source on all nodes - our mirror
2. We only mirror packages we actually use, only in the versions we actually use
3. We regularly do an apt upgrade on all nodes - which will be pretty safe then (there's apt-cron for this e.g.)

That'll make e.g. security update deployments easier. Also, it'll allow us to pin versions, something we hardly do at all so far, and which is a bit messy with both APT pinning and Puppet.

What do you guys think of that?

[fhd]

Sorry, undid your changes thanks to Trac...

[matze]

Agreed, although it might become a bit tricky do determine which packages are actually in use. Sure, APT can tell us that. But I doubt that there's only *provisioned* packages on the production servers, so they probably need a bunch of other packages in addition to those we'll find if we dump that information on provisioned development boxes only..

[fhd]

True, if it's too much of a hassle it's not a good option. But I have no idea how/if we can do that in our own APT mirror.

Even if it's doable, I'm not fully convinced it'll be better than pinning/upgrading via Puppet. We're hardly doing any pinning so far - I suppose it's a bit of a different topic.

[matze]

Fair enough, I agree. It can be considered a different topic than mirroring.

Version pinning is something I associate with requirements, specification, code, dependencies and build-processes (in short: software), whilst mirroring is something motivated by reliability issues and thus operational.

Therefore, I consider pinning via Puppet the better option. It's additional documentation in-source (*.pp), where any changes are then tracked like any other part of the software under version control. It's also independent from the mirror itself, where one can then focus on the operational requirements (e.g. availability). And don't forget that the mirror setup itself is also tracked (*.pp again..).