Another PHP5 problem
nightrecon at hotmail.com
Fri Jun 17 22:49:18 UTC 2011
Jack L. Stone wrote:
> 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
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.
More information about the freebsd-questions