[CentOS-mirror] Mirroring the vault

Wed Apr 15 13:55:59 UTC 2015
Thomas Bellman <bellman at nsc.liu.se>

Hash: SHA1

On 2015-04-15 13:32, Fabian Arrotin wrote:

> There are also 4 non centos.org nodes that are actually fetching vault
> content , and those have better bandwidth/machines that we do
> (reminder : we're using community donated dedicated servers).
> I can't speak for those external mirrors, and I have zero view on
> their bandwidth usage/stats for vault content.

We are one of those mirrors.  Over the last five months, we have used
an average of slightly below 50 Mbit/s, but that is the sum of both
vault and the ordinary CentOS (and EPEL, which we are also mirroring).
I do have logs from all three protocols (HTTP, FTP and RSYNC), but I
don't have any collected statistics of which parts of our mirrors have
been accessed how much.

(And the bottleneck is neither our network, nor the server itself.
We could easily handle much larger load, if people were just accessing
us more.  But if the light load we get is representative for what
other people get, or if there is something [like geo-IP] that causes
us to get so few accesses.)

> OTOH, I (personally) think that vault is like giving a gun for people
> to shoot themselves in the foot : using
> deprecated/unpatched/unsecured/unmaintained packages on a distro is
> not what I'd consider best practice. There are a *few* corner cases
> where it can be handy, but those are already mirroring internally
> those versions, for specific usage, and don't rely on vault.centos.org

Having access to the source RPMs is very important to us.  Both current
and historical versions, to be able to see what has actually changed.

Having access to old versions of the binary RPMs is not quite as important
(we can usually rebuild them from the source RPMs), but it is definitely
convenient to see which versions were used previously and examine them.
In some rare cases we may even downgrade.  (For example, I think it took
almost two months after CentOS 6.6 was released until we found out that
IP-over-Infiniband was broken in that kernel; because it didn't actually
break until you restarted the subnet manager.  For a while we ran a 6.5
kernel with some security fixes from 6.6 backported; now we run a 6.6
kernel with the IPoIB stuff picked from 6.5.)

	/Thomas Bellman (mirror.nsc.liu.se)
Version: GnuPG v1