From owner-freebsd-questions@FreeBSD.ORG Fri Jun 17 22:49:18 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD2081065673 for ; Fri, 17 Jun 2011 22:49:18 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 60AF68FC1B for ; Fri, 17 Jun 2011 22:49:18 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QXhqm-0004jW-Pb for freebsd-questions@freebsd.org; Sat, 18 Jun 2011 00:49:16 +0200 Received: from pool-173-79-85-36.washdc.fios.verizon.net ([173.79.85.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Jun 2011 00:49:16 +0200 Received: from nightrecon by pool-173-79-85-36.washdc.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Jun 2011 00:49:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Michael Powell Followup-To: gmane.os.freebsd.questions Date: Fri, 17 Jun 2011 18:49:51 -0400 Lines: 69 Message-ID: References: <64D6EF8B-A799-4D8C-A688-FC020CCFEFD1@d3photography.com> <3.0.1.32.20110615175738.019581f8@sage-american.com> <3.0.1.32.20110615155910.019581f8@sage-american.com> <3.0.1.32.20110615150619.019581f8@sage-american.com> <3.0.1.32.20110615090401.0181fea8@sage-american.com> <3.0.1.32.20110615090401.0181fea8@sage-american.com> <3.0.1.32.20110615150619.019581f8@sage-american.com> <3.0.1.32.20110615155910.019581f8@sage-american.com> <3.0.1.32.20110615175738.019581f8@sage-american.com> <3.0.1.32.20110615191858.018e54e0@sage-american.com> <64D6EF8B-A799-4D8C-A688-FC020CCFEFD1@d3photography.com> <85B7376289F04B2596EBE3090DB9D970@rivendell> <3.0.1.32.20110616085819.018c54e0@sage-american.com> <0122428124834D73AAE4EE5178CEE27C@rivendell> <3.0.1.32.20110616105844.027f64f8@sage-american.com> <3.0.1.32.20110616144533.0196a408@sage-american.com> <3.0.1.32.2011 0617192644.03caff20@38.106.15.121> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-173-79-85-36.washdc.fios.verizon.net Subject: Re: Another PHP5 problem X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 22:49:18 -0000 Jack L. Stone wrote: [snip] > > A note of concern was that apache22 changes the path to the document root > by inserting ../www/apache22/data > versus the previous ../www/data doc root. > > Of course my vhosts and a bunch of other things of importance now reside > within the ../www path. I suppose I can change the doc root within the > apache22 config file(s) but I can forsee some possible breakage in things > on a production server when before, when moving from apache-1.3 to > apache2, web things were put in the same path and without any > modifications needed. I suppose this only affects the main host server > stuff and things left in the ../www placement will still work as before > according to the present setup. > > In examining the apache22 Makefile I see some places that the path might > be changed, but don't know if that is the best idea vs maybe changing the > doc root in apache22 config. A 3rd choice is to move stuff contained in > the ../www/cgi-bin phpMyAdmin ...etc things that the main host needs to > find in the new location. > > What did you fellows do about this issue that worked best for you assuming > y'all had vhosts and similar stuff to worry about? Me I just bit the bullet and went with the new locations as they were installed as defaults. I moved my content to the location. None of my content cared about the underlying file system path, however there is code that does. When faced with this most of the time there is some configuration utility that can be run to make changes, with the actual data you enter being stored in a database backend. This then becomes a choice of "is it easier to simply modify the docroot in the .conf files?", if you have this situation. I made the choice I did because none of my code cared. My thinking was it would be better to have this arrangement in place for catastrophe requiring a complete reinstall from scratch. Changing the docroot in the .conf files (vhosts have docroot and Directory directives as well) is not as dangerous as it sounds. For example, when you change httpd.conf and later attempt to pkg_delete or deinstall the port you'll see a message about it not matching the checksum of the original and it will be left intact and not deleted. Same goes for updating with portupgrade, it will not replace your changed files either. So my first choice would be use the new layout and move file content. If this creates more problems than it's worth because too much code relies on being aware of the underlying file system, changing the docroot in the .conf files is the lesser of two evils but not as dangerous as it sounds. > Methinks this is my last question before moving to production servers. You're doing it right by testing with a test server first. I only have 7 FreeBSD servers at work (we're a winderZ shop) with 2 at home. The 2 at home are close to being exactly the same as the ones at work in that the same environment and apps are installed with configurations pretty much the same. I use portupgrade for maintenance and upgrades. I've learned over time one trick with portupgrade is to check often, and upgrade in very small batches. I've noticed a higher probability of a hiccup when too much time goes by and now a hundred things all need updating at the same time. Update policies and procedures will vary by shop, such as doing a dump for being able to roll back, etc. What I do is test out any potential update on the servers at home first. If I get the warm fuzzy and everything is smooth I will then do the ones at work. -Mike