On Wed, 2005-09-07 at 23:21 -0500, Les Mikesell wrote: > On Wed, 2005-09-07 at 22:39, Greg Knaddison wrote: > > > Or better yet, > > > a way to tell it that .... > > > you want it now to apply exactly the same changes on > > > an important machine that you tested elsewhere > > > > As long as you use specific instructions to yum like "yum install > > foo.1-3.386" and you have a clean and simple set of conf/repos files, > > then yum will do a very specific thing. If you have multiple > > repositories in your configuration and you just say "yum update" then > > it might not behave exactly as you desire. > > If you managed a set of servers running homegrown code that > may or may not be sensitive to library and utility program > versions, what steps would you use to keep a test server > up to date, then after performing any needed application > testing, to roll out the same changes to the production > servers in various different locations? I would use yum to keep the testing system up to date, and use rsync to copy specific RPM packages to the production server. I would not install yum on the production server at all if you need to control things tightly. yum keeps the RPMs in /var/cache/yum/*/packages/. Also remember that you need to refresh your testing platform regularly. By this, I mean that you should boot your test system from a CD, completely clear its disk, and rsync an exact image of your production server over. Otherwise, you risk having the two drift apart over time. When I worked for a large financial institution, changes were tested locally by the developers, rolled to a "testing" server where they were tested by others, then rolled to a "staging" server where they were subjected to a large battery of automated tests, and then finally rolled to production. Rolls always took place on Friday night. Once a roll was declared a success, the testing and staging servers were erased and replaced with near-perfect images of the production servers (the only difference was that the data sets were trimmed so that only the first gig of each table was moved). The testing software was kept in /usr/local, and production servers where not permitted to have anything in /usr/local. We used to complain that it would take a month to fix a comma, but it did keep us out of trouble. ;-) -David