Return-Path: Delivered-To: apmail-httpd-docs-archive@httpd.apache.org Received: (qmail 40319 invoked by uid 500); 25 Jul 2003 09:58:06 -0000 Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: docs@httpd.apache.org Delivered-To: mailing list docs@httpd.apache.org Received: (qmail 40293 invoked from network); 25 Jul 2003 09:58:05 -0000 X-Lotus-FromDomain: TELEKURS DEUTSCHLAND GMBH From: Michael.Schroepl@telekurs.de To: docs@httpd.apache.org Message-ID: Date: Fri, 25 Jul 2003 11:54:33 +0200 Subject: Re: upgrading Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on mail02.telekurs.com/Telekurs(Release 5.0.12 |February 13, 2003) at 25.07.2003 11:58:13, Serialize by Router on mail02.telekurs.com/Telekurs(Release 5.0.12 |February 13, 2003) at 25.07.2003 11:58:15, Serialize complete at 25.07.2003 11:58:15 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >> Here's a patch to install.xml to deal with upgrading. Feedback welcome. > Can we really be sure that all upgrades will be that smooth? I know that > people try their best to make it so, but there could still be bigger > changes even in 2.0.x and definetely in 2.1.x. The upgrade procedure I am using tries to take care of any such issues. For mission critical production machines, one of the things you want to have (and maybe just to please your boss ;-) is an easy way to undo an upgrade in case it turns out to cause any problems. I am doing this by not overwriting the previous installation at all. I can have any number of Apache installations on a machine. They just need to be installed into coexisting directories (whose names contain the version number in my case, set by "--prefix"). So I will install a new Apache version next to the previous one, instead of overwriting it. On the same level of directory hierarchy, I have a symbolic link named "productive" that points to the version I am running productively; this one will be used in jobs that start and stop the Apache server (these jobs don't have to be updated). One important part of my concept is that an Apache configuration dies not belong to an Apache installation. I don't use the "conf" directory of the Apache tree for this purpose - I have the confi- guration in some separate directory. My httpd.conf contains just two lines: 1. a directive to set the Port for listening 2. an "include" directive for the rest of the configuration. By this, I can easily run two different Apaches with the same configuration at the same time (on different ports), and don't have any configuration duplicated. I can run the new version on my productive machine while the old version is still serving content to visitors. I can check whether everything works on the real machine. I could even let our custo- mers do the same tests by telling them the port I use for testing if the service is mission critical for them as well. And when I am satisfied with the change, I edit the "Port" direc- tive in both httpd.conf files, restart both Apaches, and now have the new version run productively (on Port 80). Finally, I adapt the symbolic link "current", and that's it. But I could still have this upgrade undone in one minute in case anything turns out nasty. Having this in mind, upgrading to each and every new version is a lot less stressful ... Regards, Michael --------------------------------------------------------------------- To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org For additional commands, e-mail: docs-help@httpd.apache.org