[documentation] [Documentation task] Drupal multi-site setup documentation: request for comments
karldied
drupal-docs at drupal.org
Thu Jan 18 23:23:36 UTC 2007
Issue status update for
http://drupal.org/node/104340
Post a follow up:
http://drupal.org/project/comments/add/104340
Project: Documentation
Version: <none>
Component: Installation
Category: tasks
Priority: normal
Assigned to: venkat-rk
Reported by: venkat-rk
Updated by: karldied
Status: active
Comments 23-26 addressed in /node/53705. I specified the shortname (I
used 'moniker') to be in /drupal/sites/moniker rather than
/drupal/files/moniker, so that it will be backed up with a simple backup
of the /sites directory. Also changed the sym link paragraph and the one
preceding it to bulleted lists.
karldied
Previous comments:
------------------------------------------------------------------------
Wed, 20 Dec 2006 01:45:05 +0000 : venkat-rk
I thought I woud take a stab at trying to write to a multi-site set up
guide with inputs from the community. I may only be able to do this in
little bits, though.
After reading some forum posts and the sections in Robert Douglass'
book, I have the following broad structure in mind. Feel free to suggest
additions or changes for a better structure. Once we agree upon the
structure, I will add book pages and post them for review.
*I. Introduction*
* What is multi-site
* Benefits of multi-site
*II. Options for Multi-site*
* Multi-site using one code base and different databases for different
domains/sub-domains
* Multi-site using one code base and one database with prefixed tables
for different domains/sub-domains
*III. Ways to configure Multi-site in Drupal*
* Using Apache Vhosts (editing httpd.conf)
* Using symlinks
*IV. Setting up Multi-site step by step*
* Create a database on the specific domain/sub-domain or run prefix.sh
and create a prefixed database
* For each site, create a subdirectory under ..sites/
* Put settings.php under that subdirectory and configure the db
parameters
* Create a files directory under the subdirectory
* Update the file system path at ../admin/settings
*V. Setting up site specific modules and themes*
* Put under a separate 'modules' and 'themes' directory within the
subdirectory
What else? What about sharing tables between sites and across
databases? What about setting up multi-site using Cpanel or Plesk? Any
best practices?
Please chip in with comments, suggestions and links to make this a
useful guide. After a few significant comments/posts, I will post an
updated structure on this thread.
Thanks in advance,
Venkat.
------------------------------------------------------------------------
Wed, 20 Dec 2006 19:50:13 +0000 : Gary Feldman
"Using Apache Vhosts (editing httpd.conf)
"
Keep in mind that many users won't have access to httpd.conf, but may
have access to tools such as CPanel. People who are maintaining their
own httpd.conf files probably don't need as much help as those who
don't.
------------------------------------------------------------------------
Thu, 21 Dec 2006 02:26:08 +0000 : venkat-rk
You are right about httpd.conf, but I ran into an interesting situation
with a shared hosting provider who gives access to it. I think it is
ixwebhosting.com
Also the idea is to capture all important stuff in the handbook. There
may be situations when even relative non-geeks get a VPS and try to do
this (I know I am one!), so this section would help them.
------------------------------------------------------------------------
Fri, 22 Dec 2006 16:09:24 +0000 : karldied
Gary wrote: People who are maintaining their own httpd.conf files
probably don't need as much help as those who don't.
venkat-rk wrote: There may be situations when even relative non-geeks
get a VPS and try to do this (I know I am one!), so this section would
help them.
I'm another of those relative non-geeks who have access to httpd.conf,
but need help. Thanks!
------------------------------------------------------------------------
Fri, 22 Dec 2006 16:41:48 +0000 : CogRusty
About httpd.conf, don't forget the people who download and install an
AMP package with whatever default settings and want to give Drupal a
try. Judging by the support questions, they seem to be many and
inexperienced. Both Windows users who just want it to work and Linux
folks fiddling randomly.
------------------------------------------------------------------------
Sat, 23 Dec 2006 11:48:52 +0000 : venkat-rk
@CogRusty: Good point. Will keep it in mind.
------------------------------------------------------------------------
Thu, 04 Jan 2007 09:39:52 +0000 : pcwick
I think this looks like a great start to a much needed doc. In answer
to your questions, I think I would structure thus:
II. Options for Multi-site
* Multi-site using one code base and different databases for
different domains/sub-domains
* Multi-site using one code base and one database with prefixed
tables for different domains/sub-domains
* Sharing tables between sites and across databases
III. Ways to configure Multi-site in Drupal
* Using Apache Vhosts (editing httpd.conf)
* Using symlinks
* Using Cpanel or a similar web panel
- I think it probably best to refer users to the documentation for
their respective panel. Dreamhost, for example, uses a proprietary web
panel.
You'll definitely want to reference "Use the /sites directory to keep
Drupal tidy" under best practices: http://drupal.org/node/53705
I'm wondering if the installer complicates the multi-site setup
procedure for newer users. Perhaps you'll want to indicate that you are
describing a fully manual install, or maybe explain how to build a
multi-site setup when the user has already created a single-site setup
with the installer. Seems some sort of clarification along these lines
will be useful to those who have never manually installed Drupal.
You might want to mention that themes and modules placed in the new
"sites/ALL" directory will be common to all sites.
http://drupal.org/node/22283
You probably know, but some of your work is already done in INSTALL.txt
------------------------------------------------------------------------
Thu, 04 Jan 2007 11:57:16 +0000 : venkat-rk
Thanks for all the inputs, encouragement and links:-)
------------------------------------------------------------------------
Thu, 04 Jan 2007 13:38:37 +0000 : CogRusty
I rephrased and moved a few item and some of the emphasis according to
what I think users often fail to do, I added a few notes, and this is
what I suggest. (Still needs work)
I. Multi-site: Introduction
-- Multi-site: One Drupal installation for many sites
-- Multi-site: Benefits and disadvantages
-- Multi-site: What you need to do
[Site access and database(s), mention of the next sections]
II. Multi-site: Ways to configure access to your sites
-- Multi-site: Setting up Drupal for different sub-directories,
sub-domains, domains
---- Multi-site: The settings.php file, the /sites directory and its
subdirectories
-- Multi-site: Setting up the server for a Drupal multi-site
[The need for directing the requests to Drupal's directory without
altering the request URL]
---- Multi-site: Using Apache Vhosts (editing httpd.conf)
---- Multi-site: Using symlinks
---- Multi-site: Using Cpanel or a similar web panel
[Note: For simplicity, assume non-shared database tables in any
examples if needed]
III. Multi-site: Ways to configure your database(s)
-- Multi-site: Using different databases for different sites
-- Multi-site: Using one database with prefixed tables for different
sites
-- Multi-site: Sharing tables between sites and across databases
---- Some common table-sharing cases
---- Some rules for shared tables (let's call them "advanced"...)
[ e.g. - If you share even one leaf entity with numeric IDs, you must
also share the 'sequences' table.
- If you un-share a leaf entity you must also un-share all its
dependent tables containing its ID (for example if you un-share users
you must also un-share nodes)
- If you share a dependent table containing another table's IDs you
must also share that other table (for example if you share nodes you
must also share users)]
------------------------------------------------------------------------
Thu, 04 Jan 2007 15:01:28 +0000 : venkat-rk
Thanks! I will post an updated structure in a day or two.
------------------------------------------------------------------------
Mon, 08 Jan 2007 01:28:17 +0000 : pcwick
Here is a tutorial called "Drupal Multisite for Dummies" that may be a
good reference, or even a good start...
http://drupal.org/node/107347
------------------------------------------------------------------------
Mon, 08 Jan 2007 18:28:06 +0000 : Gary Feldman
I stand corrected on the need for httpd.conf advice.
Now I worry about people adding virtual hosts, but not getting the
permissions right, but that can turn into a black hole.
------------------------------------------------------------------------
Thu, 11 Jan 2007 03:06:26 +0000 : Zach Harkey
"
---- Multi-site: Using Apache Vhosts (editing httpd.conf)
---- Multi-site: Using symlinks
---- Multi-site: Using Cpanel or a similar web panel
"
This is kind of confusing since, they are technically all using Apache
VirtualHosts, and this implies a complete separation of methods. Perhaps
a better breakdown would be:
-- Multi-site: Server-side methods for hosting multiple domains from
the same document root
---- Multi-site: Reconfigure VirtualHost blocks (requires shell access
to httpd.conf)
------ Change DocumentRoot for child domain
------ Add ServerAlias for parent domain
---- Multi-site: Replace Document root with a symlink (requires shell
access)
---- Multi-site: Control Panel specific examples (Cpanel, Plesk, Ensim,
etc.)
------------------------------------------------------------------------
Thu, 11 Jan 2007 03:16:36 +0000 : Zach Harkey
Also, one of the biggest stumbling blocks with multi-site setups comes
when people don't lower the TTL on their DNS records before they start
testing multi-site configurations.
------------------------------------------------------------------------
Thu, 11 Jan 2007 07:27:49 +0000 : venkat-rk
@Zach, thanks for your insights. It looks like I did the right thing by
putting this issue up for comments since the resulting work is far more
likely to be useful than me writing some stuff without inputs.
------------------------------------------------------------------------
Thu, 11 Jan 2007 21:03:43 +0000 : Richard Eriksson
I just published our documentation for multisite at
http://support.bryght.com/vps/multiple-sites I consider it a work in
progress since this thread has a lot of good ideas for additions and
clarifications. The documentation I wrote is specific to Bryght's VPS
setup, which isn't terribly unusual, but it won't require us to cover
the possible variations that others will have. All that said, I'm
interested in helping out with the Drupal.org handbook where I can. The
writeup is licensed under the same license as Drupal.org, so feel free
to use the bits you want.
------------------------------------------------------------------------
Tue, 16 Jan 2007 05:37:12 +0000 : karldied
Pursuing Incorrect /sites/all documentation [1], I grouped some of the
multi-site doc under Multi-site installation and set-up [2].
File and directory management [3] remains under 'best practices'.
-karldied
[1] http://drupal.org/node/103915
[2] http://drupal.org/node/43816
[3] http://drupal.org/node/22283
------------------------------------------------------------------------
Tue, 16 Jan 2007 07:56:22 +0000 : venkat-rk
@Richard: Thanks! That's a very handy guide for the VPS context. I will
be sure to use it.
@karldied: Thanks. I wonder if you or anyone else could comment on the
following that I found on http://drupal.org/node/49605, one of the pages
you grouped together. The sub-heading is 'Apache configuration':
"When using virtual hosting, do not create a separate virtual domain
for each site -- only for the first site. When using a control panel
such as cPanel or Ensim, create only the first domain.
"
Does this mean that I shouldn't create the additional domains in the
hosting account (whether shared, reseller or VPS)? If yes, how does one
go about providing control panel (cpanel or others) access to the
clients for their domains for managing emails, site stats, dbs or
whatever? A common situation is one where a webmaster does all the work
for the client but may choose to give limited access to the domain's
control panel. This method seems to suggest that a drupal multi-site
setup totally discounts that possibility.
It looks like I am not getting something:(
------------------------------------------------------------------------
Tue, 16 Jan 2007 08:12:32 +0000 : venkat-rk
*Will drupal Multi-site setup on shared IP result in SEO penalties?*
I read the following yesterday on an SEO site in the context of links
and SEO and wondered if it has any relevance in the context of a drupal
multisite-siteup on a shared IP address as most shared hosting, reseller
and basic VPS hosting run multiple sites on shared IPs:
"Google favors websites that have many links located on different IP
Addresses...If you think about it, it makes sense that Google gives
priority to websites that have links on many IP Addresses rather than
many links all on the same IP Address. This helps eliminate the
possibility of people controlling the search engines.
If Google didn't look at IP Addresses, I could simply create 1 website
with thousands of pages and link to another 1 of my websites from all
pages. I would then have thousands of links pointing to my website and a
#1 ranking...
Unfortunately, Google's smarter than that and you can't do it.
"
If this has any truth in it, then the consequences may be harsher for
drupal webmasters who also handle domain name stuff for their clients
AND make the whois info private. According to Matt Cutts of Google, a
combination of private whois info and multiple sites (not drupal
multi-site) on the same IP or something to that effect sets off a red
flag...I can't find the entry now, but Matt was responding to a blog
entry comment that talked about a recent SEO conference somewhere where
he politely confronted a small biz owner who had adopted this very
tactic. Of course, his sites were penalized.
This isn't directly relevant to drupal multi-site install, but if it's
true, would be a useful tip to highlight. Comments?
------------------------------------------------------------------------
Thu, 18 Jan 2007 01:40:37 +0000 : karldied
Yesterday in comment 16, I mentioned changes to address 103915 -
Incorrect /sites/all documentation [4]. Today I finished updates for
issue 103915.
/node/53705 [5] is now updated to describe best practices for the
/sites directory in multi-site installations. However, some of comments
on the page deal with broader multi-site issues, including a list to a
dozen links about Server side issues with multiple sites.
[4] http://drupal.org//node/103915
[5] http://drupal.org//node/53705
------------------------------------------------------------------------
Thu, 18 Jan 2007 05:57:42 +0000 : CogRusty
Personally I consider it /bad practice/ to place 'files' under
'/sites/example.com/files'. This is a sure way to make your file links
dependent on your current domain name.
What I consider relatively better practice for a multisite's files is
to place them under '/files/s1' where 's1' is a general short
identifying name of the site which you can reuse elsewhere.
Also, I am not sure why multiple 'tmp' files are needed, so I think one
'files/tmp' would be enough.
------------------------------------------------------------------------
Thu, 18 Jan 2007 06:01:39 +0000 : CogRusty
If I was not clear, I refer to the capability to move your site to
another path and/or name.
------------------------------------------------------------------------
Thu, 18 Jan 2007 16:01:32 +0000 : Boris Mann
"Personally I consider it bad practice to place 'files' under
'/sites/example.com/files'. This is a sure way to make your file links
dependent on your current domain name.
"
It is easy to move. Create a symlink from your new domain name -- ln -s
/sites/example.com /sites/example2.com. Voila. Easy, and it keeps all
files for the site in *one* place.
Re: /sites/example.com/tmp -- this is again to keep all files for a
site together. If you have full control over the server and know
everything that is on there, no problem using /tmp. If there are
multiple sites, each having their own /tmp is a bit better security.
------------------------------------------------------------------------
Thu, 18 Jan 2007 17:01:26 +0000 : CogRusty
"It is easy to move. Create a symlink from your new domain name -- ln -s
/sites/example.com /sites/example2.com. Voila. Easy, and it keeps all
files for the site in *one* place.
"
That should work, but there is a price. My links entered in the content
would appear with the old domain name (a development site name or
anything). Is that worth it if I can just remember that a site's files
are somewhere under /files?
------------------------------------------------------------------------
Thu, 18 Jan 2007 17:09:49 +0000 : CogRusty
On second thought, I see that I could create symlinks under /files and
use those in the first place. So I would have the best of both words
(all site data in one place and domain-independent links). A handbook
explanation would be a bit elaborate though.
------------------------------------------------------------------------
Thu, 18 Jan 2007 20:00:08 +0000 : Boris Mann
This is where this crosses over into best practices and there is no one
"right answer".
------------------------------------------------------------------------
Thu, 18 Jan 2007 20:41:48 +0000 : karldied
@CogRusty: Making a sym link from /drupal/files/shortname makes good
sense to me if there is a need as you've described. I'll add that to the
topic.
This is a topic with many options, one of the reasons for the separate
"Multi-site setup of /sites dir" vs "Basic /sites dir setup". There's
already a description of using links to point to /sites/default or from
/sites/default, so this isn't any more complex.
@Boris: Thanks for the confirmation on using /sites/example.com/tmp
being a good practice, though how it improves security is not obvious to
me, so I hesitate to just flatly state it.
------------------------------------------------------------------------
Thu, 18 Jan 2007 22:57:45 +0000 : CogRusty
Good, but I would be wary of trying to explain Unix shortcuts and
Windows junctions where there is a natural solution...
------------------------------------------------------------------------
Thu, 18 Jan 2007 22:59:20 +0000 : CogRusty
... I meant "Unix symlinks"
More information about the documentation
mailing list