Drupal multi-site, sharing core with symlinks.

Sounds cool... I don't have any suggestions, but I would like to hear of any notes for anyone looking to do similar stuff in the future.
--
Please read the handbook, search the forums, then ask...
http://drupal.etopian.net (Drupal Support) | http://www.drupalshowcase.com

I'm running quite a similar setup in dedicated CentOS / CPanel box with at least of that number of sites (some of them more than 3k uniques per day) and there has not been any problems so far. Using symlinks, too and a script to build additional sites. Hope this helps.

I've been running multiple Drupal setups with symlinks for a while now on FreeBSD and Debian systems. No problems at all here.

I don't redirect public_html (or in my case web/public), though, instead I symlink the individual Drupal files and directories inside it. I don't symlink the sites directory, so I'm not using Drupal's multi-site feature. Each site has its own sites/default/settings.php just like any ordinary Drupal site.

Everything that isn't symlinked is automatically unique to each site, just as it would be if I weren't doing the symlinking. So each site gets its own favicon.ico and files subdirectory by default, along with any other non-Drupal files and directories needed for that site.

I think this avoids all of the issues you mentioned with sharing the entire public_html. As far as Apache and Drupal are concerned, each site is a separate website just as it would be if you weren't doing the symlinking.

I share the modules and themes from the common installation, but I could always make those directories unique for a particular site by unlinking and copying them. In fact, I could put an entire site onto its own non-shared code that way--and I wouldn't have to change the site configuration at all.

I have my shared Drupal code in ~/common/drupal-production/ and the following script in ~/common/scripts. After creating a new site, I just set up the database and run this script from that site's public HTML directory:

#!/bin/sh

# The Drupal source directory
source=~/common/drupal-production

check() {
    test -e $1 && {
        echo
        echo "$PWD/$1 exists, Drupal installation canceled"
        echo
        exit 1
    }
}

check index.html  # not part of Drupal, but suspicious

check .htaccess
check index.php
check cron.php
check index.php
check xmlrpc.php

check database
check includes
check misc
check modules
check scripts
check themes

echo
echo "Installing Drupal in $PWD"
echo "Linked to $source"
echo
echo "Type OK to install:"

read ok
case $ok in
  [Oo][Kk] )
    echo
    echo "Installing now..."
    echo
    ;;
  * )
    echo
    echo "Installation canceled"
    echo
    exit 2
    ;;
esac

cp $source/.htaccess .

# cp $source/favicon.ico .

test -d sites || {
    mkdir sites
    mkdir sites/default
    cp $source/sites/default/settings.php sites/default
}

ln -s $source/cron.php cron.php
ln -s $source/index.php index.php
ln -s $source/xmlrpc.php xmlrpc.php

ln -s $source/database database
ln -s $source/includes includes
ln -s $source/misc misc
ln -s $source/modules modules
ln -s $source/scripts scripts
ln -s $source/themes themes

echo
echo "Drupal installed in $PWD"
echo
echo "Now edit $PWD/sites/default/settings.php to enter your URL and database info"
echo
echo "Also create $PWD/favicon.ico"
echo "or copy $source/favicon.ico there"
echo

What about security in this shared installation? How to separate privileges of different users from different installation?

Speed. I think this can help to improve perfomance - these scripts can be cached better than separate.

I started to do something like what Geary's doing (well, exactly like what he's doing) but came across the multisite feature. That seemed to require a lot less complexity, so I went ahead with it.

So far, it's working pretty well. I've been porting sites over to Civicspace 8.2 from different versions of Drupal and CivicSpace. The sites do not share content (of course) and are on separate virtual server hosts.

The software is installed by a single symlink to the shared copy of CivicSpace (Drupal). Installation is done via a script that creates the database and makes that symlink.

Now, I'm hitting a wall. The files/ dir is shared. That's not what I want. Please, anyone, does the following sound like a reasonable way to proceed.

1. instead of symlinking the entire directory, symlink the following files individually:
.htaccess
cron.php
drupal2civicrm_sync.php
includes/
index.php
install.php
misc/
modules/
themes/
update.php
xmlrpc.php

2. The sites/ dir is a special case. I want to create that by copying files over. This way, each domain cannot see the other domains' config files. I think the sites/ dir is a security hole -- because you can guess the path from the site's URL, and then write a script to read the settings.php file.

3. The files/ dir is a special case, too. I want separate files/ for each site.

I'm very new to this, having done it only a half day so far. Am I thinking about this issue in the right way?

We are running a symlink Drupal multisite for a lot of customers now together with Plesk. Runs without problems and depending on your structure there are no problems with the security.
We symlinked about everything except the sites folder (so one site could be subdevided in multiple sites) and the index.php and .htaccess file.
You have to make sure users don't have the php input format ofcourse and in our situation we added a disallow for the settings.php in the .htaccess file in case the setup with chmod would go wrong.

http://justinhileman.info/blog/2007/06/a-more-secure-drupal-multisite-in...

--
http://www.drupaler.co.uk/

Building on comments above, I've implemented a shared code-base system which keeps user data separate, allows contributed modules/themes to be shared or single-site, and allows core updates to be applied selectively. It also works with PHP user_base security, prevents users modifying shared code or symlinks, and works perfectly with user control panels like cPanel and supports any file transfer method your users want to use.

Each drupal core version is owned by a 'cms' user and installed at:
/usr/local/drupal/

So 6.12 would be:
/usr/local/drupal/drupal-6.12

Each site is deployed with 2 sets of symlinks:
/home/[username]/drupal_home
contains the reference to the version of drupal to be used:
/home/[username]/drupal_home/current -> /usr/local/drupal/drupal-6.12

/home/[username]/public_html
Symlinks in here reference the drupal_home symlink above:
/home/[username]/public_html/modules -> ../drupal_home/current/modules

This means that to update this site to a new version of drupal, simply change the drupal_home link:
/home/[username]/drupal_home/current -> /usr/local/drupal/drupal-6.13

And all the public_html linked files/folders (as detailed in other posts above) will be instantly updated. The sites/all folder is symlinked to the shared codebase, and contains shared contributed modules and themes. Themes and modules unique to one site are put in the sites/default folder, so they are not visible to any other users. Likewise the files folder is only accessible by the site's user.

I've written scripts to deploy new sites (based on Geary's fantastic suggestions above) and extended them to make deployment even easier. For example the install script dumps a snapshot of a skeleton installation and uses this to create a new database for the user's site etc. I also have a skeleton file structure which is copied to the public_html directory when drupal is first setup, which contains the basic layout for the sites and files folders. The access privileges for these files and folders are then set to allow both the user and drupal (running under Apache as 'nobody' group) to read and write as appropriate. Update scripts allow you to move the drupal_home directory while maintaining or rebuilding the links, and a version changer simply updates the current version to a different specified one.

The scripts allow you to install in sub-directories of the public_html folder (or anywhere else), and optionally specify the owning user, drupal_home folder, database name, database user (if different) and various other options.

Where is the best place to post these scripts (if there is interest)? They're quite long so I'm reluctant to post them at the bottom of an already long thread...

Nice information I have ever on Drupal.org.

Thank you.

Anyone able to do this for drupal 8?