Cobbler 2.0.11 Hack to Limit Rsync Bandwidth

I was having a problem with one of my cobbler app installs, where the rsync run would overload the already-loaded network signal. This is a pipe where we're already doing a lot of management, because the physical premises are not conducive to an upgrade (and we're not doing QoS yet; I know, I know).

Lanton Vhengani was also having the same problem back in 2008, and although Mr DeHaan was considering adding a switch to the rsync invocation from within the cobbler app, it's not yet appeared.  Lanton found the section where the rsync invocation is literally called out, and provided a great patch hint for the source.  It still works under 2.0.11 .

diff -uBb /usr/lib/python2.4/site-packages/cobbler/action_reposync.py\~ /usr/lib/python2.4/site-packages/cobbler/action_reposync.py
--- /usr/lib/python2.4/site-packages/cobbler/action_reposync.py~        2011-04-20 08:40:48.000000000 -0400
+++ /usr/lib/python2.4/site-packages/cobbler/action_reposync.py 2011-07-16 22:00:22.000000000 -0400
@@ -220,6 +220,7 @@
         if not repo.mirror.endswith("/"):
             repo.mirror = "%s/" % repo.mirror

+        spacer = " --bwlimit=50"
         # FIXME: wrapper for subprocess that logs to logger
         cmd = "rsync -rltDv %s --delete --exclude-from=/etc/cobbler/rsync.exclude %s %s" % (spacer, repo.mirror, dest_path)
         rc = utils.subprocess_call(self.logger, cmd)

restart cobblerd before testing, and there you go:  Bandwidth isn't pinned and the boss is happier.  That's a pretty small setting there, but I'll open it up after Centos6 comes down completely -- the periodic kicks the pipe will take when 1-2 RPMs are updated will be so small I can push it up a bit higher.