After upgrading to portage-2.1.2-r12, rsyncing to my local mirror (rsync.au.gentoo.org) fails: # emerge --sync >>> Starting rsync with rsync://136.186.1.76/gentoo-portage... >>> Checking server timestamp ... [snip] --prune-empty-dirs requires protocol 29 or higher (negotiated 28). rsync error: protocol incompatibility (code 2) at compat.c(108) [receiver=2.6.9] !!! Rsync has not successfully finished. It is recommended that you keep !!! trying or that you use the 'emerge-webrsync' option if you are unable !!! to use rsync due to firewall or other restrictions. This should be a !!! temporary problem unless complications exist with your network !!! (and possibly your system's filesystem) configuration. Rsyncing to other mirrors (e.g. namerica) seems works, but only if the server is running rsync-2.6.9 and/or supports protocol 29.
Infra, is it feasible to make sure all of our rsync mirrors have a recent version of rsync?
Note that --prune-empty-dirs isn't essential. We can simply remove it from PORTAGE_RSYNC_OPTS if necessary. It's only an optimization to prune 6755 empty directories that are left behind when **/files/digest-* are excluded for bug #167668.
I did a quick 'n dirty scan of the rsync mirrors listed on mirrors.xml with the following command and found 6 servers not using protocol version 29. for i in $(wget -O - 'http://www.gentoo.org/main/en/mirrors.xml?passthru=1' 2>/dev/null | sed -ne '/rsync:\/\//s/^.\+"\(.\+\)".\+$/\1/p'); do rm /tmp/timestamp.chk 2>/dev/null; rsync --prune-empty-dirs ${i}/gentoo-portage/metadata/timestamp.chk /tmp/timestamp.chk &>/dev/null || echo "**WINNER**: ${i} - $?"; done The servers that return error 2 are the old ones. In order of their appearance on mirrors.xml, they are: rsync://modzer0.cs.uaf.edu/gentoo/ rsync://gentoo.mirrors.easynews.com/gentoo/ rsync://ftp.belnet.be/gentoo/ rsync://linux.rz.ruhr-uni-bochum.de/gentoo/ rsync://ftp.rhnet.is/gentoo rsync://ftp.swin.edu.au/gentoo Sick 'em boys!
After looking again, I realized this is in no way a complete list of rsync mirrors. I started building a list of the DNS roundrobin addresses for the rsync mirrors and checking them. So far, from rsync.gentoo.org and rsync.us.gentoo.org, I found the following. I'll add more as I get more DNS addresses to scan. trillian.gtlib.gatech.edu [128.61.111.9]
Ok, this should be the last one :) The mirrors listed in comment 3 appear to be rsync mirrors for the distfiles/releases/snapshots/etc. These below are portage rsync mirrors that have a protocol version <29. trillian.gtlib.gatech.edu [128.61.111.9] = @RSYNCD: 28 mirror.cs.mun.ca [134.153.48.2] = @RSYNCD: 27 ftp.cc.swin.edu.au [136.186.1.76] = @RSYNCD: 28 niue.belnet.be [193.190.198.20] = @RSYNCD: 28 fido.online.kz [212.154.208.7] = @RSYNCD: 26 These are non-responsive. galapagos.gentoo.gr.jp [211.14.6.124] (No route to host) potato.vegetable.org.uk [62.197.40.130] (Connection refused)
Created attachment 111673 [details] python script that identifies bad rsync mirrors This script walks all the servers reachable from http://mirrorstats.gentoo.org/rsync/ and outputs the data to stdout as a spreadsheet of tab-separated values. Here are the servers that currently have rsync protocol < 29: Rotation Server FQDN IP Addresss Rsync Protocol Version rsync.asia.gentoo.org fido.online.kz 212.154.208.7 26 rsync.au.gentoo.org ftp.cc.swin.edu.au 136.186.1.76 28 rsync.be.gentoo.org niue.belnet.be 193.190.198.20 28 rsync.ca.gentoo.org mirror.cs.mun.ca 134.153.48.2 27 rsync.cn.gentoo.org fido.online.kz 212.154.208.7 26 rsync.de.gentoo.org c3-4-7.rz.ruhr-uni-bochum.de 134.147.32.114 28 rsync.dk.gentoo.org niue.belnet.be 193.190.198.20 28 rsync.europe.gentoo.org niue.belnet.be 193.190.198.20 28 rsync.fr.gentoo.org gentoo.modulix.net 195.210.43.85 27 rsync.hu.gentoo.org skynet.netmasters.hu 195.56.151.2 27 rsync.is.gentoo.org draupnir.rhnet.is 130.208.16.26 26 rsync.lu.gentoo.org niue.belnet.be 193.190.198.20 28 rsync.namerica.gentoo.org mirror.cs.mun.ca 134.153.48.2 27 rsync.namerica.gentoo.org trillian.gtlib.gatech.edu 128.61.111.9 28 rsync.nl.gentoo.org mirror.scarlet-internet.nl 213.204.195.9 28 rsync.nl.gentoo.org speedtest.scarlet.nl 213.204.195.9 28 rsync.pl.gentoo.org posejdon.po.opole.pl 217.173.198.6 27 rsync.se.gentoo.org pc1043.pc.hv.se 193.10.192.105 27 rsync.th.gentoo.org fido.online.kz 212.154.208.7 26 rsync.uk.gentoo.org niue.belnet.be 193.190.198.20 28 rsync.us.gentoo.org trillian.gtlib.gatech.edu 128.61.111.9 28
I'd like to chime in as a mirror admin. In our case, the system serving out the mirrors runs on RHEL. It's infeasible to build and maintain an rsync package that's ahead of what Red Hat provides. If all the various Gentoo mirrors ran Gentoo, it wouldn't be a big deal to require a bleeding edge version of rsync, but that's unfortunately not the case, so it will be a very difficult task to bring all the mirrors up to a compatible version. From my point of view, it seems best to immediately remove --prune-empty-dirs from portage now that the incompatibility is known. It would be appropriate to start by evaluating whether the change is worth all the work to update the mirrors, and then work with the mirror administrators to update things before rolling out the change in a well-announced manner. As best I can tell, there's no immediate need for portage to use the new rsync feature, so there should be plenty of time to implement it in a sane and responsible manner.
(In reply to comment #7) > it will be a very > difficult task to bring all the mirrors up to a compatible version. Are you talking about public rsync mirrors or private ones? If you're talkin about private rsync servers then you can always set non-default PORTAGE_RSYNC_OPTS on all your client machines. The public rsync mirrors that the attached script finds are mostly on protocol version 29 already (>=rsync-2.6.4). Less than 15% of the responsive public mirrors have a lower protocol version. In svn r6105 I've fixed the emerge --sync code so that it will retry (up to PORTAGE_RSYNC_RETRIES) with other servers if it encounters a protocol incompatibility. That should mostly prevent users from noticing those <15% (I was hoping they'd be removed from the rotation soon anyway).
(In reply to comment #8) > Are you talking about public rsync mirrors or private ones? I'm referring to public mirrors, where the mirror admin has no control over the client machines. In my specific situation, it's a mirror of various Linux distributions serving a campus of ~30,000 and we'd prefer that the Gentoo users not have to go offsite for their updates. > In svn r6105 I've fixed the emerge --sync code so that it will retry (up to > PORTAGE_RSYNC_RETRIES) with other servers if it encounters a protocol > incompatibility. That should mostly prevent users from noticing those <15% (I > was hoping they'd be removed from the rotation soon anyway). Hoping the problem goes away is not a fix. I still think that if you're going to change the package manager in such a way that makes it incompatible with the current infrastructure, you need to do so with a *lot* more foresight. At this point it's Portage that's broken, not the mirrors. The mirrors are running in accordance with the official Gentoo documentation and the Portage change makes it unable to use a chunk of them. I may be overlooking something, but the rsync option in question seems to provide a relatively small optimization. Is it even worth all this?
(In reply to comment #9) > I may be overlooking something, but the rsync option in question seems to > provide a relatively small optimization. Is it even worth all this? Not really. I'm going to remove it. Thanks for your feedback. :)
(In reply to comment #10) > (In reply to comment #9) > > I may be overlooking something, but the rsync option in question seems to > > provide a relatively small optimization. Is it even worth all this? > > Not really. I'm going to remove it. Thanks for your feedback. :) This "relatively small optimization" saves 27M or so on ext3 probably even more if the user has xattr enabled.
Seems ftp.cc.swin.edu.au now works (didnt yesterday) ...
In portage-2.1.2-r13, --prune-empty-dirs is no longer in the default PORTAGE_RSYNC_OPTS. Users can add it to PORTAGE_RSYNC_EXTRA_OPTS if they want.
