[support] Multisite Broke After Drush 'archive-restore'

Kenneth Jacker khj at be.cs.appstate.edu
Sat Nov 17 02:21:37 UTC 2012


*Warning*:  long reply!

 >> I'd think if anything would "trigger" the "default" site (and its
  >> associated "settings.php" file) content, it'd be coming in as a
  >> non-DNS, bare IP address!
  >> 
  eb> That depends on the httpd configuration, not really a Drupal
  eb> issue.  The numeric address is getting remapped before Drupal sees
  eb> the connection.

To what and how is it being "remapped"?

What aspect of Apache2 does this (I ask so that I might check there for
more info/confirmation).

  >> Though most of my testing has been with the IP address (pending the
  >> movement of additional domain names to the new site) ...
  >> 
  eb> I never test with the numeric address, instead I map the address to a
  eb> planned site name in my client hosts file.  On Windows that file on my
  eb> system is C:\Windows\system32\Drivers\etc\hosts and it uses the
  eb> standard xx.xx.xx.xx SITE syntax.

I could do that ... in Linux, where the file is /etc/hosts. So,
something like this?

       1.2.3.4  plannedsite.com

  eb> On the server side, I always set up the VHOSTs even though the
  eb> public DNS hasn't been updated.

Hmmm ... though as mentioned before I've had quite a bit of experience
with kernels, networking, Apache, etc., I have done little with the
"virtual hosting" part of 'httpd'.

Might you suggest (if you have the time!) what VHOST "config lines" I'd
add to /etc/apache2/apache2.conf (or maybe a file symbolically linked in
/etc/apache2/sites-enabled) for my "plannedsite.com" example?

Right now there is, I believe, only one virtual host with multiple
"Directories" defined in between <VirtualHost *:80> ... </VirtualHost> tags.

  eb> This way Drupal sees the correct site name because that is what I
  eb> enter into the browser.

So you mean you associate the bare IP address with the non-DNS
registered domain name via a VirtualHost?  Is it possible that I'm
beginning to understand this? !

  >> Maybe something is cached in MySQL?

  eb> Are you using differing databases for each site?

Yes.  And each site's "settings.php" file defines the appropriate DB
(which I verified was created via 'phpmyadmin').

  eb> You might check the sessions table, variable table and system
  eb> table.

No sure exactly what I'm looking for ;-), but will check those tables
out later.

  eb> Going to admin/modules and clicking the Submit button will action
  eb> changes to the system table to correct data in that table.

Maybe just an "operator error", but I see no "Submit" button when I
bring up Drupal's "modules" page.


Sorry for the lengthy letter, but I am trying to give you (and other
possible "lurkers") as much info as possible.

And thanks very much for taking the time to help me.  :)


  -Kenneth

PS  One thing that bothers me about all of this is that I didn't have to
    use VHOSTs and the "hosts" file modification on the "source" site
    (the one I "archived" with 'drush').  It works fine.  The problem is
    with the "new" (duplicate) site created via a 'drush' restore.  The
    first site works, but the second doesn't.

    No matter.  I'm learning a lot through this discussion ... 
  


More information about the support mailing list