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