Instructions for administering our rsync mirror system.

Kurt Lieber  Author
Shyam Mani  Editor

Updated 2009/09/17

1.  Creating a new rsync mirror

Abstract

Warning: This file refers to the OLD administration system. New system documentation available here.

Setting up a new rsync mirror involves the following steps:

Bugzilla

The first step in creating a new rsync mirror is for the user to file a bug on http://bugs.gentoo.org. From there, the mirror admin should acknowledge the bug and verify that the following information was provided as part of the initial report:

If part of the information is missing, please request it as a follow-up to the bug. Then, continue to the next step.

Probationary Period

New rsync mirror candidates need to go through a probationary period of at least 48 hours and preferably 96 hours where their server is checked periodically for timely updates with rsync1.us.gentoo.org. To set this up, the mirror admin must modify the iptables ruleset on rsync1.us.gentoo.org. ssh into rsync1.us.gentoo.org and perform the following operations:

Code Listing 1.1: Use vim and sudo to edit /etc/init.d/rsync

# sudo /usr/bin/vim /etc/init.d/rsync

Code Listing 1.2: Look for the Testing section and add the new mirror there

#######
#
# TESTING MIRRORS
# PUT MIRRORS THAT ARE IN THE TESTING PHASE HERE
# MAKE SURE TO REFERENCE THE BUGZILLA # SO WE CAN TRACK THEM
#
######

        #bug #12345
	     addMirror 192.168.1.1

Note: Each entry should consist of at least two lines; a comment that references the bug number and the actual access entry. The access line must take the form of addMirror <ip address>

You must also manually add the rule to the existing iptables ruleset:

Code Listing 1.3: Adding the entry to the existing itpables ruleset using sudo

# sudo /sbin/iptables -A tcp_packets -p TCP -s <ip address> --dport 873 -j tcp_allowed

From there, monitor the rsync mirror over the next 48-96 hours to ensure it is updating on :00 and :30 intervals. If the mirror shows inconsistencies of any type, report them on the bug entry and work with the server admin to resolve them if possible.

Note: A "TODO" item is to write a script that will automate the monitoring process during the probationary period.

Adding DNS entries

After the mirror candidate has passed the probationary period, the mirror admin should create DNS entries for the mirror. Each mirror needs 5 distinct DNS records:

Important: To ensure we can quickly and easily remove problematic rsync mirrors from our rotations, new entries should be created with a TTL of no longer than 20 minutes.

Important: DNS round robin rotations do not support the use of CNAMEs in rotations. Any record in a round robin rotation must be an A record.

Note: Because rsync.gentoo.org as well as rsync.europe.gentoo.org, rsync.us.gentoo.org and rsync.namerica.gentoo.org are getting full, mirror admins should use their discretion when adding servers to these rotations. In general, only servers which support at least 25 users, have a 10Mbps connection to the internet and are on a server with sufficient resources should be added to these rotations.

To create the entries, log into UltraDNS using the mirror administration account information and create the records via the web interface.

Adding Directional DNS

For the master rsync.gentoo.org rotation, we use Directional DNS to "target" specific sets of mirrors at users based on the location of their IP address. While it is easiest to think of this feature as geo-location, it actually relies more on the user's network connection and its proximity to the various UltraDNS servers. To enable the Directional DNS service, follow these steps:

Important: Mirror administrators should periodically ensure that rsync.gentoo.org does not return too many records for any one particular set. When there are more than approximately 22 records returned as part of a round robin set, it becomes larger than what UDP can handle. This causes DNS to failover and try TCP instead. This causes problems with users who have TCP port 53 blocked.

Updating the iptables access list

Once the mirror candidate is up and functioning, the mirror administrator should update the entry in the rsync1.us.gentoo.org iptables access list to reflect the change.

Code Listing 1.4: Use vim and sudo to edit /etc/init.d/rsync

# sudo /usr/bin/vim /etc/init.d/rsync

Code Listing 1.5: Move the entry in the Testing Mirrors section to the appropriate part of the file

#######
#
# TESTING MIRRORS
# PUT MIRRORS THAT ARE IN THE TESTING PHASE HERE
# MAKE SURE TO REFERENCE THE BUGZILLA # SO WE CAN TRACK THEM
#
######

        #bug #12345
         addMirror 192.168.1.1
(delete the entry above and move it to the appropriate section below)
[snip]

# .us RSYNC MIRRORS

        # rsync5.us     "Joe Admin <joe@admin.com>"
		addMirror 192.168.1.1

Note: Each entry should consist of at least two lines; a comment that references the server administrator and their email address as well as a line containing the actual access entry. The access line must take the form of addMirror <ip address>

2.  Updating an rsync mirror

Updating an rsync mirror involves many of the same steps above, except there is no probationary period and the existing records are simply changed, rather than new records being added.

3.  Deleting an rsync mirror

To delete an rsync mirror, simply complete the following steps:

Code Listing 3.1: Deleting the entry from the existing itpables ruleset using sudo

# sudo /sbin/iptables -D tcp_packets -p TCP -s <ip address>