On Fri, 2005-09-09 at 14:26, Lamar Owen wrote: > On Friday 09 September 2005 13:49, Les Mikesell wrote: > > files here. I'm asking for repeatable actions with all the > > same stuff available plus possibly some new things I'd prefer > > to ignore. > > Ok, Les, try: > rsync the header cache (found in /var/cache/yum/$repository/header) from the > test box to production (they are small files) > yum -C update (on the production box target of the rsync). Assuming the test > box repository is populated from the internet (you said internet connectivity > from production was better than to the test box), then the update on > production should pull in the right files (assuming they still exist on that > repository, which they might or might not). > > And see if that helps. The 'yum -C' keeps yum from updating the cache; if > you're good, you can edit these headers and remove things you don't want. > > You seem to need a staging repo box out with the production boxes to help with > your testbox -> production bandwidth bottleneck. The testbox(s) are at a location with developers/QA people and so-so bandwidth. Production servers are at an assortment of places with excellent internet connectivity but so-so private line connectivity back to the location of the test boxes. It would be realistic to rsync the whole /var/cache/yum, packages and all, to one of the production boxes at each location, then using it as a staging relay from there to all the others. I can use the --bwlimit feature of rsync to throttle as needed. But poking around I see some xml gunk that I didn't expect (hadn't looked closely since it was just headers, packages, and header.info). I wonder if the installed RPM data gets cached now too. -- Les Mikesell lesmikesell at gmail.com