> Yes, of course, I would up2date in the test environment first. But > what I don't quite understand: do I have to stop running services when > doing so?
The update should stop and restart anything it is replacing, and, depending on how good the person doing the RPM packaging is, it shouldn't clobber any of your configuration files. So far, only about 80% of the updates from the distributors have been good about that, so it's still a good idea to be cautious. (We have seen improvement in this area recently, though -- looks like the Debian folks have made some impact in getting their QA levels adopted elsewhere. Debian packages are consistently better in this area.) > I mean: what else is needed before/after running up2date in order to avoid > ... > all eventualities that should be avoided (whatever they are)? What we do: 1) A good file-level backup of the target Linux guest. Bacula or other Linux-based backup tools are your friend here. 2) A tripwire baseline run on the test server image (we use this as part of a method to find out *exactly* what the package(s) changed. You could get some of this by unpacking the RPMs, but this technique works consistently on all sorts of Unixen, some of which don't use RPM. The security weenies like it too because it gives them a baseline snapshot of what *should* be there). 3) Run the online update tool on the test image. 4) Run a tripwire delta (to find out what changed). 5) Test (list of RPMs and applications is helpful here) and document problems. 6) Package remediation of problems as a local RPM (if needed). Makes propagating fixes easier if we do them in RPM format -- it's a little more work, but it pays off. 7) Add update and remediation RPMs to local repository. 8) Schedule and deploy updates and remediation RPMs from local repository on production servers. We don't recommend running online update directly from the distributors servers in order to be both bandwidth-friendly and to ensure that we test everything that goes in production. 9) Update tripwire baselines for production servers. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
