[ale] Virtual hosting and PHP apps

David Hillman hillmands at gmail.com
Thu Apr 14 12:29:30 EDT 2011


I fixed it.  Duh!  I had copied one of the host configuration files and then
modified that to create another host, forgetting that I hadn't reloaded
httpd after the last set of changes.  What a stupid mistake.  Thanks for all
the replies.


On Thu, Apr 14, 2011 at 11:58 AM, Michael B. Trausch <mike at trausch.us>wrote:

> On 04/14/2011 11:14 AM, David Hillman wrote:
> > I am using a Linode VPS to test a couple of Drupal apps using Apache
> > virtual hosts.  One of the problems I am having is the files from one
> > host is bleeding over into another host; ie, if I put files in host A, I
> > can access those files from host B.  What gives?  Is that an Apache
> > issue?  If it is, how do I fix it?  I used the instructions from
> > Linode's website to set up the virtual hosts with SSL.  I went over the
> > files about 5 times each to make sure all the folder names were correct.
> >  Is there a document somewhere that lays out the architecture of virtual
> > hosting?  I want to be able to trace  what exactly happens when a
> > request is made to a specific host.
>
> Tar up the configuration directory (sans the SSL key/cert) and attach
> that your reply to this, so that we can see what the configuration is.
> If you need to do any sterilization of the configuration, let us know
> exactly what was sterilized.
>
> Just a simple "tar cjf apache-config.tar.bz2 /etc/apache2" will work,
> though use the --exclude option to omit your SSL key and certificate
> (sending those will mean that they would be in the public archive and
> thus you would have to consider them compromised).
>
> My guess would be that you have overlapping document roots or somehow or
> another you have a configuration stanza that is mapping the same space
> into multiple virtual hosts.
>
> > The other issue is finding a good way to deploy Drupal easily to a test
> > server and then to a production server, with all of the security and
> > database tables in place.  I have heard some people use Ant, spit and
> > duct tape.  I have never used Ant much.  On the Windows side, I have
> > used msconOn my laptop, I use Turnkey Linux virtual machine devices to
> > test locally, so all the setup is done for me there.
>
> You should read "Continuous Delivery: Reliable Software Releases through
> Build, Test, and Deployment Automation" by Farley, David, Humble, and
> Jez.  It is an _AWESOME_ book and will get you thinking hard about your
> application's lifecycle and how you get from testing to production.  I
> would highly, highly recommend that book.  Highly.
>
> Also, don't fall into the trap that most interpreted-language developers
> (particularly Web developers) seem to fall into:  do not assume that a
> traditional development stack will not work for you.  Sure, "make all"
> might be a no-op in your project, since there won't be anything to
> compile (unless you have PHP extensions written in C to speed up your
> code base, but since writing extensions for PHP is hairy, that's likely
> to not be the case).  But having a normal development harness is a good
> thing.  Perhaps instead of compilation you can use "make all" to do
> something very simple, like "php -l" on each source file to ensure that
> the sources are at least syntactically valid PHP.
>
> Then you could even go so far as to use make to build your deployment
> package or whatever.  By using make, you can use "make test".  And that
> there is enough to get you to be able to work with a some sort of a
> build bot.  From there it's just figuring out what (human) processes
> need to be used to get from the successful build on a build bot to
> staging to testing to production.
>
> Again, I highly recommend reading Continuous Delivery.  It will give you
> _lots_ of ideas.
>
>        --- Mike
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110414/1738f672/attachment.html 


More information about the Ale mailing list