On Fri, 2005-04-08 at 20:59 +0200, Michael van Elst wrote: > On Fri, Apr 08, 2005 at 11:39:33AM -0700, David M. Fetter wrote: > > > It seems that when most of the rpms that have config files are upgraded, > > the working config is moved to some *.rpmsave file and the new one is > > put into place. What this basically means is that any services on a > > server where we might upgrade an rpm on will temporarily break. > > This assumes that the new software is able to work correctly > with the old config files. This might be even true for most > popular packages most of the time but for a real production > environment you want some proper configuration management.
Right. We actually have cfengine too for all of our configs. The dilemma is that when an rpm is updated it moves the config aside then restarts and bam we have downtime upon update. Cfengine comes along every 10 or 15 minutes and puts the proper config back into place, but we don't use cfengine to restart most of the services due to some issues we have had with trying to do it that way. So, the problem I'm trying to point out is that moving aside the running configs could cause unnecessary downtime even if it is for 10 or 15 minutes. Any down time is generally not good. Now I can understand that the some software won't work at all with an old config and I think at that juncture it is suitable for the running config to be moved aside to an *.rpmsave. It makes it so that it is blatantly obvious that the admin has to review it right away. However, most of the time, the running config works with slightly newer revisions of software and at that point it makes more sense to copy the new config to *.rpmnew so that when the admin has time they can go review the differences. It isn't really a matter of neglect on the admins' side of things, but in general most unix shops are understaffed and/or shorthanded due to the number of outstanding projects, so they may not have time to review every new config for every package and if it's not immediately necessary then why should they be forced to do that? In our shop, it is a goal to cut down the maintenance cost of maintaining software in general. Part of this project ended up using the fine OpenPKG product to assist with a good portion of the software management. We still have about 20-30 pieces of software that we have to manually maintain and keep current, but for the other 500+ pieces we are trying to incorporate it into an auto-update procedure. If it is the philosophy of OpenPKG to always move aside running configs to *.rpmsave regardless of whether it is necessary or not, then I suppose we will just need to manually update those pieces of software as well and pull them out of the automated update process. Unfortunately, this takes away from lowering the overall maintenance cost. All I'm trying to do is to see if I can bring up the discussion and maybe ultimately change the way the configs are handled during an upgrade of a package so that the maintenance cost can stay as minimal as possible. I completely agree with what you're saying and in a perfect world every admin would have the time to properly review thoroughly each piece of software prior to upgrade as well as each individual patch for the underlying OS. This, however, is not a perfect world and so we admins must make do and do the best we can to maintain stability in our environments. It becomes even more difficult to manage config changes like this with the more servers you have. From this stand point, it seems logical that there are reasons for using *.rpmnew and *.rpmsave for configs. Most of the time, *.rpmnew is sufficient and that's good because it can keep the maintenance costs down. When a piece of software changes a config so radically that it won't function with an old config, then using *.rpmsave to move aside the running config makes more sense. That is basically how I see it from the administrative aspect. I hope this makes some sense. I'm not trying to ruffle feathers or anything, I'm just trying to state what I think is a valid point. Thanks. > > Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
