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.

Comments

Gary Feldman’s picture

Gary Feldman commented

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.

venkat-rk’s picture

venkat-rk commented

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.

karldied’s picture

karldied commented

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!

cog.rusty’s picture

cog.rusty commented

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.

venkat-rk’s picture

venkat-rk commented

@CogRusty: Good point. Will keep it in mind.

pcwick’s picture

pcwick commented

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

venkat-rk’s picture

venkat-rk commented

Thanks for all the inputs, encouragement and links:-)

cog.rusty’s picture

cog.rusty commented

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)]

venkat-rk’s picture

venkat-rk commented

Thanks! I will post an updated structure in a day or two.

pcwick’s picture

pcwick commented

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

Gary Feldman’s picture

Gary Feldman commented

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.

zach harkey’s picture

zach harkey commented

---- 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.)

zach harkey’s picture

zach harkey commented

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.

venkat-rk’s picture

venkat-rk commented

@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.

sillygwailo’s picture

sillygwailo
Location Toronto, ON
commented

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.

karldied’s picture

karldied commented

Pursuing Incorrect /sites/all documentation, I grouped some of the multi-site doc under Multi-site installation and set-up.

File and directory management remains under 'best practices'.

-karldied

venkat-rk’s picture

venkat-rk commented

@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:(

venkat-rk’s picture

venkat-rk commented

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?

karldied’s picture

karldied commented
Component: Admin Guide » Installation

Yesterday in comment 16, I mentioned changes to address 103915 - Incorrect /sites/all documentation. Today I finished updates for issue 103915.

/node/53705 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.

cog.rusty’s picture

cog.rusty commented

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.

cog.rusty’s picture

cog.rusty commented

If I was not clear, I refer to the capability to move your site to another path and/or name.

boris mann’s picture

boris mann commented

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.

cog.rusty’s picture

cog.rusty commented

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?

cog.rusty’s picture

cog.rusty commented

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.

boris mann’s picture

boris mann commented

This is where this crosses over into best practices and there is no one "right answer".

karldied’s picture

karldied commented

@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.

cog.rusty’s picture

cog.rusty commented

Good, but I would be wary of trying to explain Unix shortcuts and Windows junctions where there is a natural solution...

cog.rusty’s picture

cog.rusty commented

... I meant "Unix symlinks"

karldied’s picture

karldied commented

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.

victorkane’s picture

victorkane commented

I would include, either in section I or II, a sub-section entitled "Multi-site use cases", including, for example:

* Load balancing
* Running a Drupal Bryght-like hosting site
* ???

This would be very helpful for people to understand the needs users have experienced giving rise to the feature's implementation, and various forms of implementation.

tom_taylor’s picture

tom_taylor commented

It would be good if you can have instructions on how to sym link across cpanel accounts.

So if you own a server and can run the whm, you should be able to share one install across different accounts.

This is handy so each cpanel account is seperate for the site.

Would make my life allot easier when updating websites which are made with drupal.

venkat-rk’s picture

venkat-rk commented

tom_taylor, thanks, at last I found someone with a similar need to run multiple sites from a single code base while still giving each domain its own full fledged cpanel account. The typical advice for multisite seems to suggest using vhosts or aliased domains (basically using A records and CNAMES on the main domain) that would NOT give full fledged control panel accounts to the domains.

Just to be sure that I understand you correctly, is your need similar to the situation described here:
http://support.bryght.com/vps/multiple-sites#comment-803

pcwick’s picture

pcwick commented

Here's another Drupal Multisite tutorial for reference with emphasis on using domain parking, symlinks and virtual hosts.

http://www.contractwebdevelopment.com/drupal-multisite-configurations-an...

wayland76’s picture

wayland76 commented

a) What about using the Multiple Domains module?
b) Did anything ever happen with this?

wiredescape’s picture

wiredescape commented

Re: comments 31 & 32

I also have been searching for a way set up multisites and give clients access to email, etc. through individual control panel accounts. Have run into a dead end so far. Before finding venkat-rk and Tom_Taylor's posts I haven't found any other mention of it!

I asked a number of hosts about using a Reseller account with cPanel and WHM to create a Drupal multisite where all domains would be symlinked to the one code base and each domain is provided a separate cPanel. Basically they said due to security issues it would be impossible on a shared server for the following reason (paraphrased):

Shared environments are restricted to running scripts owned by the domain. For security PHP openbase_dir is used to prevent users from accessing other users files. This would not allow using symlinks to the Drupal base core from the individual domains as they do not have ownership of the files they are linking to.

The bottom line answer was “So this sort of requirement I doubt would work anywhere unless you are running your own server. It is simply too open ended... to be secure.”

The most common recommendation was to use add-on domains in a single shared account. This allows multisites but does not provide full fledged control panel accounts to the domains. I suppose a dedicated server is the solution to this type of setup...

wayland76’s picture

wayland76 commented

You might be able to do something with https://www.nearlyfreespeech.net/ who allow you to have multiple domains, and have some kind of API. Then again, maybe it'd require a fair bit of work. Note: I'm not associated with them, except as a happy customer.

venkat-rk’s picture

venkat-rk commented

I am not sure if this helps anyone, but after banging my head against this seemingly insurmountable problem (since I am very security conscious and had php running as suexec, not as an apache module and also had open_basedir restriction on the server, thus ruling out the use of symlinks), I finally got a drupal developer to make me a great shell script that when run as root, does the following on a cPanel server:

1.) Copies the drupal core to the web root of a domain or a sub-domain, sets up a db user and a db in the cPanel hosting account and then lets you visit www.example.com/install.php to set up drupal. It sets the right permissions on all the files and makes sure settings.php is not writable after the install.
2.) It then lets you (while still in the same shell session or any time later) add any number of contrib modules and themes to the same install.
3.) It lets you install in a subdomain for development and moves the site automatically to the main domain when you need to go live.

For me, the biggest plus, apart from the easy drupal set up is that the script allows a client full access to their cPanel (hosting account's control panel), unlike the typical multisite solutions where the domains are parked on top of one domain and therefore prevent clients from accessing their hosting accounts.

What it doesn't do:

1.) Automatic updates of core and contributed modules for each site
2.) Automatically creating and deleting subdomains (using the WHM/cPanel API)

The script only works on a cPanel VPS, but it may also work on a cPanel reseller account if you have root access and can install your own software.

If anyone is interested in getting this script, please email me through my contact form. I want to be frank and say that I am looking to recoup at least some of my expenses as I spent a small fortune on this. I hope to spend on further enhancements to the module too. One distant day in the future, my hope is that this will live as a module on drupal.org

Admins, if you think this message is inappropriate for any reason, please remove.

Venkat

dokumori’s picture

dokumori commented
Project: Documentation » Drupal core
Version: » 7.x-dev
Component: Installation » documentation

Changed the component to reflect the new component categorization. See http://drupal.org/node/301443
-dokumori

dokumori’s picture

dokumori commented
Project: Drupal core » Documentation
Version: 7.x-dev »
Component: documentation » New documentation
tgeller’s picture

tgeller commented

Venkat-Rk: How's this going?

alexanderpas’s picture

alexanderpas commented

subscribing.

venkat-rk’s picture

venkat-rk commented
Version: » 6.x-1.x-dev

tgeller, I am sorry to say I have totally abandoned my effort on this. Between severe RSI, starting my own business and having to care for my family, this has been completely pushed to the background. I hope someone else can pick it up and run with it.

dokumori, I had to set the version as 6.x (the only one available) as drupal wouldn't allow me to submit the comment until I selected the version.

leehunter’s picture

leehunter commented
Assigned: venkat-rk » Unassigned
add1sun’s picture

add1sun commented
Version: 6.x-1.x-dev »

Just FYI, I've closed the other "placeholder" issue for this. #141741: placeholder for multisite documentation - codebase locations and domain locations

alexanderpas’s picture

alexanderpas commented
Issue tags: +multi-site
leehunter’s picture

leehunter commented
Status: Active » Fixed

Since this was only an only RFC for a proposal which has since been dropped and Emmajane has recently done some work cleaning up the Multisite page, I'm marking this as fixed.

Not that the multisite section is now perfect but it probably needs a fresh look in the context of the overall doc IA work.

Status: Fixed » Closed (fixed)
Issue tags: -multi-site

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +multi-site

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.