On Tue, 2005-03-08 at 07:41 +0100, Michael van Elst wrote: > On Mon, Mar 07, 2005 at 05:22:21PM -0800, David M. Fetter wrote: > > David, > > > Also, I still might have to > > maintain that none of the rpms should ever do a restart on their own. > > This should be a controlled thing that is done through some > > administrative function. In our environment, one of the biggest > > problems with OpenPKG right now is that they all want to restart on on > > upgrade. We cannot have this happen without explicit control and timing > > over it. > > I guess this is an eternal discussion.
Haha. Yes, indeed. We are delving into the philosophical world of administrative. An area of concept that is more religion than science. ;-) > In my world upgrading > isn't a safe operation either and the minimum that must be > done with an upgrade is an automated _shutdown_ of the old > service because doing nothing is better than doing something wrong. > > In a production environment you need some kind of configuration > management. Deployment then starts with shutting down services, > continues with rolling out the new version, installing new > configuration files from a repository, and finally restarting > services. If you can't take that downtime (and we are still > talking about minutes) then you want a high availability > solution anyway. Yeah, we actually use cfengine for all of that. Therefore, we have no need at all for a package to do any restarting of it's own. One thing one of my co-workers mentioned is that it would at least be nice if there was a --norestart or something along those lines. Then the rpms could contain the postinstall bits that restart them, but it is optional to not have it do so. Then if this was somehow incorporated into the build tools, it would be super nice. ;-) > > This is nothing that OpenPKG provides out of the box. > > For the non-productive environment I believe the automated restart > of services is a convenience. Yes, I would definitely agree with you here. I think that also part of the problem is that most of the packages seem to copy aside the working configs to $config.rpmsave and overwrite it with the default one. If instead, the rpms copied the new default configs to $config.rpmnew as a standard then at least when it restarted things most likely will not break. It would be up to the administrative staff to then do some comparison between the new config and their working config to see if anything in the new one needs to be added or modified in their working config. I think this would be a good thing that would probably resolve the problems we have been seeing with the rpms restarting on install. > > Greetings, -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
