Collaboration

Saving bandwidth with a local mirror

Previously, I reviewed both the Debian apt and SUSE YOU update mechanisms. Both systems enable administrators to keep servers up to date with the latest security patches and updates downloaded from internet repositories

After touring the features of apt and YaST update mechanisms, it’s clear that if you want to update multiple computers within your LAN, a definite advantage will be gained by keeping a local mirror of the update repositories; one update package can be 30 MB+ on its own. If you need to deploy this to 10-20 servers in a farm it doesn’t make sense to download 600 MB from the internet when 30 MB will suffice. The update programs can have their repository location customised; therefore, it makes sense to download the available packages once (to a local mirror) and point your apt or YaST there.

There are a few things which should be considered while planning your local mirror: first of all, you need to make sure that there is enough disk space available. A Debian mirror can sport over 100 GB of data. Normally, you can get a major saving in disk space by excluding the architectures that are not used on your network: alpha, arm, hppa, m68k, mips, mpisel, powerpc, s390 and sparc are not required by the majority; i386 and ia64 architectures should fulfill most needs. Excluding the unused types will return a massive reduction in wasted space. A second consideration should be the amount of bandwidth consumed by the initial synchronisation with an external mirror. Even with high-speed business lines, the huge amount of data being transferred will likely slow down internet connectivity for quite some time—it’s probably best to run this initial sync overnight or even better over a weekend. Future synchronisation runs will not need to run outside of office hours as the amount of data downloaded will be trivial.

So, we have reviewed which architectures are used on our network, allocated the required resources (e.g. disk space) and decided on a good time to create our initial mirror—how do we move forward? I’m looking to create a local Debian repository so I have two options: using the repository mirroring script provided here by Debian, or using a script/package called ‘debmirror’. I am personally more interested in debmirror as it can also be used to mirror Ubuntu repositories without modification.

Installation is of course a breeze:

# apt-get install debmirror

The default configuration is found in /usr/share/doc/debmirror/debmirror.conf; any directives found in /etc/debmirror.conf will override the default configuration. I would recommend putting a full copy of the file in /etc and modifying this one:

# cp /usr/share/doc/debmirror/debmirror.conf /etc

# vi /etc/debmirror.conf

The configuration file has many customisable options which can be read about in the man pages, the most important are:

@dists=’’ - This specifies which distribution versions should be mirrored.

@sections=’’ - This controls which repository sections will be mirrored; you may, for example, only want to take updates from the main section but not the universe.

@arches=’’ - This dictates which architectures should be mirrored (as previously discussed).

$post_cleanup=0/1 - Delete files no longer on the remote site, but only after a successful sync (e.g. no errors).

$check_md5=0/1 - Check the MD5 of files after download to verify their integrity.

$dry_run=0/1 - Perform a dry run, good to test your settings.

Once the configuration has been completed, setting off a synchronisation run couldn’t be easier:

# debmirror /path/to/local/mirror

Those wanting to use debmirror to create an Ubuntu mirror should take a look at this support post for some guidance. The main variables to take note of are:

host=au.archive.ubuntu.com (this one for Australia)

method=http

root=ubuntu/

dist=breezy (change to your dist)

section=main,restricted,universe

arch=x86

I hope this has shown how simple the process of configuring a local mirror can be. The debmirror script can be called from crontab at your preferred interval; I would suggest that once per day is more than adequate. If you have any preferred method for mirroring repositories, why not leave a comment and share it with us…

Editor's Picks

Free Newsletters, In your Inbox