Multisite Broke After Drush 'archive-restore'
[ Ubuntu-12.04; Drupal-7.17; Drush-5.8 ] I backed up a copy of my (multi-site) using Drush's 'archive-backup'. The 'tgz' file was transferred to another machine and "installed" with the 'archive-restore' command. The site basically works except for one important aspect: multi-site. I've checked that the multiple databases were created, enabled Apache2's 'mod_rewite', and made sure each site's "settings.php' had the right content and permissions, but "no go". :( The odds are high that I've just "forgotten to do something", but can't remember what it is! Any ideas? Thanks, -- Prof Kenneth H Jacker khj@cs.appstate.edu Computer Science Dept www.cs.appstate.edu/~khj Appalachian State Univ Boone, NC 28608 USA
On 11/15/12 12:51 PM, Kenneth Jacker wrote:
[ Ubuntu-12.04; Drupal-7.17; Drush-5.8 ]
I backed up a copy of my (multi-site) using Drush's 'archive-backup'. The 'tgz' file was transferred to another machine and "installed" with the 'archive-restore' command.
The site basically works except for one important aspect: multi-site.
I've checked that the multiple databases were created, enabled Apache2's 'mod_rewite', and made sure each site's "settings.php' had the right content and permissions, but "no go". :(
The odds are high that I've just "forgotten to do something", but can't remember what it is!
Any ideas?
Thanks, And how do you mean that multi-site isn't working?
Are the alternate sites "dead", or do all domains just use default? Since multi-site keys off the domain name of the request, how are you testing this, have you changed your DNS, (and waited the day for it to propagate)? Are you using test sub domains (and is the multi-site set up to handle this?) -- Richard Damon
Thanks for your prompt reply! rd> And how do you mean that multi-site isn't working? I am so embarrassed ... I posted a request for help with a non-specific, "something is wrong" problem "description". My apologies. In fact, yesterday I was thinking that I'd done this ("network unfriendly") act, and needed to post a followup. Hopefully more useful, comments follow ... rd> Are the alternate sites "dead", or do all domains just use default? rd> rd> Since multi-site keys off the domain name of the request, how are you rd> testing this, ... No matter how I enter the site (even with a plain IP address) displays one of (always the same) non-default sites. 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! rd> ... have you changed your DNS, (and waited the day for it to rd> propagate)? Yes. Though most of my testing has been with the IP address (pending the movement of additional domain names to the new site). rd> Are you using test sub domains (and is the multi-site set up to rd> handle this?) No sub-domains. Again, my regrets for the poor initial post ... not my usual behavior! Thanks again for your comments/questions, -Kenneth PS I just did a bit more testing ... I removed *all* of the multisites directories except 'default' from /var/www/sites, and cleared all Drupal caches. I also cleared the browser (Chrome) cache. Reloading using the IP address displayed the content (except an image) of one of the removed multisites ... weird! Maybe something is cached in MySQL?
On Fri, Nov 16, 2012 at 10:12 AM, Kenneth Jacker wrote:
No matter how I enter the site (even with a plain IP address) displays one of (always the same) non-default sites. 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!
That depends on the httpd configuration, not really a Drupal issue. The numeric address is getting remapped before Drupal sees the connection.
rd> ... have you changed your DNS, (and waited the day for it to rd> propagate)?
Yes. Though most of my testing has been with the IP address (pending the movement of additional domain names to the new site).
I never test with the numeric address, instead I map the address to a planned site name in my client hosts file. On Windows that file on my system is C:\Windows\system32\Drivers\etc\hosts and it uses the standard xx.xx.xx.xx SITE syntax. On the server side, I always set up the VHOSTs even though the public DNS hasn't been updated. This way Drupal sees the correct site name because that is what I enter into the browser.
rd> Are you using test sub domains (and is the multi-site set up to rd> handle this?)
No sub-domains.
Doesn't really matter, it depends on what Drupal sees as the URL in the request.
Again, my regrets for the poor initial post ... not my usual behavior!
Thanks again for your comments/questions,
-Kenneth
PS I just did a bit more testing ...
I removed *all* of the multisites directories except 'default' from /var/www/sites, and cleared all Drupal caches. I also cleared the browser (Chrome) cache.
Reloading using the IP address displayed the content (except an image) of one of the removed multisites ... weird!
Maybe something is cached in MySQL?
Are you using differing databases for each site? You might check the sessions table, variable table and system table. Going to admin/modules and clicking the Submit button will action changes to the system table to correct data in that table. -- Earnie -- https://sites.google.com/site/earnieboyd
*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 ...
On Fri, Nov 16, 2012 at 9:21 PM, Kenneth Jacker <khj@be.cs.appstate.edu> wrote:
*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).
It is done in the config file. There is a default DocumentRoot being set somewhere in your config settings. Since I don't have access to those files it is difficult to be specific.
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
Yes.
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'.
It's not that difficult; Ubuntu sets it up by default.
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?
Well since you have sites-enabled you also have sites-available. You would create the file in sites-available and then use a2ensite "site name" to enable it. Maybe http://www.debuntu.org/2006/02/22/7-virtual-hosting-using-apache-2 would help you?
Right now there is, I believe, only one virtual host with multiple "Directories" defined in between <VirtualHost *:80> ... </VirtualHost> tags.
This is the default. If you have multiple DocumentRoots then that isn't correct; I'm not sure what you mean by "multiple "Directories"".
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? !
Yes, the host name is mapped in the hosts file on the client, it doesn't need to be on the server unless the server accesses the host name for some reason. Then a VirtualHost using the non-DNS registered name is created and apache will DTRT.
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').
Ok, good.
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.
The big large button at the bottom of the module list; or the "Enter/Return" button on your keyboard may do it by default.
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. :)
No problem, it's what I do.
-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.
You would need to review the settings of the httpd daemon of the source to determine how it was routing each site.
No matter. I'm learning a lot through this discussion ...
We never quit doing that. -- Earnie -- https://sites.google.com/site/earnieboyd
On 11/16/12 12:11 PM, Earnie Boyd wrote:
On Fri, Nov 16, 2012 at 10:12 AM, Kenneth Jacker wrote:
No matter how I enter the site (even with a plain IP address) displays one of (always the same) non-default sites. 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! Is there anything in sites/sites.php? this controls "non-standard" multi-site mapping. What url's are you using and what site directory is it going to? That depends on the httpd configuration, not really a Drupal issue. The numeric address is getting remapped before Drupal sees the connection. If apache is differentiating the sites into different document roots, then the site is NOT using multi-site. By definition, multi-site has multiple domains (and such) being routed to the same document root and Drupal uses the access pattern to determine which "site" directory to use for it.
-- Richard Damon
On Fri, Nov 16, 2012 at 10:47 PM, Richard Damon wrote:
If apache is differentiating the sites into different document roots, then the site is NOT using multi-site. By definition, multi-site has multiple domains (and such) being routed to the same document root and Drupal uses the access pattern to determine which "site" directory to use for it.
Huh? The multi-site in this case is more than one site listed in the sites directory. The DocumentRoot can be specified differently and a symlink used to create that directory or the DocumentRoot could be the same directory for each Virtual site. I tend to have a directory structure of SITE/htdocs and htdocs is a symlink to the Drupal version used for the site. This allows me to but the access and error logs in the SITE directory for that site. This gives me control to upgrade one site at a time when I do an upgrade. It is kind of difficult to execute update.php on more than one site with certainty that the process completes. If an issue arises then you want to focus on that issue until it is resolved because the site is down. I don't want all sites down at once. -- Earnie -- https://sites.google.com/site/earnieboyd
participants (3)
-
Earnie Boyd -
Kenneth Jacker -
Richard Damon