Push mirroring is a form of mirroring that minimizes the time it takes for changes to the archive to reach mirrors. The master server uses a triggering mechanism to immediately inform the client mirror that it needs to be updated.
Push mirroring takes a little more effort to set up since the maintainers of the upstream and downstream mirror must exchange information. The benefit is that the upstream mirror initiates the mirror process immediately after its archive has been updated. This allows changes to the archive to propagate extremely quickly.
Explanation of the method
First some background on ssh. Ssh allows people to connect to accounts on different machines in a secure way. Not only are passwords never passed in the clear, once you connect to a machine you are basically guaranteed that future connections will be to the same machine. This prevents many man-in-the-middle attacks.
One capability ssh has is the ability for a user to take the public identity key for a user on another machine and add it to a file of authorized keys on your machine. By default, the user on the other machine (who has the private identity key associated with the public identity key given to you) then has login privileges to your account. It is possible, though, to add text to an authorized key restricting the type of access a person accessing your account using that key has.
So to protect the downstream mirror, the key provided by the upstream mirror has text added to it to limit it to only give the person accessing your account permission to do one thing — start the program on your machine that updates your mirror. Even if someone (an evil third party) was able to break the key, the most they could do is to start the mirror program on your machine. You do not even have to worry about multiple copies of the program being started as a lockfile is used.
On the upstream end, rsync can be configured to restrict who can mirror a given area by username and password. These are totally separate from /etc/passwd so a push server doesn't have to worry about giving others access to their machine. As it is set up, the username and password are passed in the clear. This shouldn't be a problem though, as the worst that can happen is that a third party gains the ability to mirror Debian from that site.
Setting up a push client mirror
It is best to set this up using the account of an ordinary user, not root. The contents of the public ssh key given to you by the upstream mirror should be placed in ~<user>/.ssh/authorized_keys.
To become a push client for the FTP archive, you will need to set up
mirroring using our standard ftpsync script set.
Copy ftpsync.conf.sample to
ftpsync.conf and modify it to
suit your system and the values provided by upstream.
Push-Primary client sites
Push-Primary client mirrors, also referred to as Tier-1 mirrors, are the push client mirrors which are allowed to mirror from our master archives.
If your site is very well connected (both very good bandwidth and well connected to major backbones) and you are willing to let other sites mirror from your site, you may want to let us know so we can consider you for a push mirror. However, don't expect it to happen very soon because we already have a fair number of Tier-1 mirrors.
If your site is becoming a Push-Primary for the FTP archive, you will need one of these files:
- public SSH2 key used by ftp-master.debian.org
- public SSH2 key used by syncproxy.eu.debian.org
- public SSH2 key used by syncproxy.wna.debian.org
If your site is becoming a Push-Primary for the WWW pages, you will need the public SSH2 key used by www-master.debian.org.
Setting up a push server mirror
Given the large number of mirrors and the size of the Debian archive, it is not feasible for all the mirrors to use the master archive site as the upstream source for Debian (i.e. their push server mirror). It is much more efficient if the load is distributed among a number of push mirrors distributed throughout the globe.
Push server mirrors should be push client mirrors of the master archive (or perhaps another push server), and they should contain a mirror of the entire Debian archive.
See the details on setting up a push server.