Another PHP5 problem

[Michael Powell]

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