[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