[kwlug-disc] Drupal Multi-site Hosting

[Khalid Baheyeldin]

On Mon, Feb 8, 2010 at 10:57 AM, <john at netdirect.ca> wrote:

> I'm noticing that have more and more Drupal sites. Most are internal but
> increasingly more and more are customer sites. We have been installing
> separate Drupal instances for each web site and it becomes time consuming
> to keep them all up-to-date and we risk becoming insecure if we miss one.
>
> I know that Drupal can handle multi-site hosting per instance and I'm now
> considering doing just that. It seems clear how to go about doing this,
> but I'm worried about the consequences.
>

Drupal has multisite built in. All you need to do is to have a:

sites/example1.com/settings.php
sites/example2.com/settings.php
..etc.

In each settings.php, you have it point to a different database.

All the shared modules and themes go into sites/all/modules and
sites/all/themes. They are available to all sites.

All site specific files (user pictures, images, attachments, ...etc.) go
into sites/example1.com/files

Site specific modules go into sites/example1.com/modules and
sites/example1/themes.

Stuff that is not modules, but rather 3rd party (e.g. WYSIWYG editors) go
into sites/all/library or similar (something outside modules/themes, but
under sites/all, and the specific module will have a setting to point to
this directory. This avoids the editor itself being overwritten if you
upgrade its module.

Does anyone know any gotchas in doing this?
>
> The multi-site hosting seems easy:
>
> - Install one copy with a generous assortment of useful (and active)
> modules and themes,
>

Yes, they go in sites/all/modules and sites/all/themes. That way they shared
across all sites.


> - Create a sites/customer.com directory structure and matching Linux user
> so they can upload modules, themes and files,
> - Create a database,
> - Create an Apache config for the domain,
>
> This should allow customers to upload/download themes, additional modules,
> and control their own site's users and settings. They can use the base
> modules (in sites/all/modules) or add their own.
>

Don't allow customers to upload themes or modules on a shared multi site
setup. They should only be allowed to upload to their own "files" directory
and nothing else.
They can download something insecure or leave stuff lagging and you have an
attack vector on ALL sites.

You should kind of vet what modules they want, but not allow them to self
serve. That is unless you run PHP in a very restrictive way (suExec in CGI).

Another module you want to disable across all sites and physically remove
is the php module in 6.x. Otherwise, if one of your customers allows PHP in
comments, ALL your sites are insecure.

There is also a paranoia module that you may want to check out.

I could set up three instances, one for 5.x, 6.x and 7.x and put the
> user's sites/customer.com directory in whichever instance they want. Then,
> when needed, I'd only have to do one update to affect all sites for a
> given version. When a user wants to upgrade, we run through the upgrade
> process except move the sites/customer.com to the new instance, then run
> the update process to update their database.
>

I do this for our sites. We use symlinks to point a site to the new version,
so
we don't have to upgrade them all en masse, but rather one by one as time
permits.

Say all sites are hosted in /home/www/live, which is a symlink to a Drupal
6.

Drupal 7 comes out, and we do /home/www/d7. We change the vhost for the site
that will be upgraded to point to the d7 directory, backup the database,
copy the "files" directory there, and run update.php for that site only.

One unique thing in this is that we most of our customers rely on us to do
> the web site administration, however we do have customers that work with
> their site at an content level (e.g. they don't change site-wide configs
> like modules, themes or such.)
>

Means that they will not upload themes or modules either, which makes your
server more secure.


> We would have to concern ourselves with making sure some customers are
> prepped before upgrading.
>

We had a presentation on upgrading in the fall at the Waterloo Region Drupal
Users Group. You can get the slides from here
http://groups.drupal.org/node/32558. Also some detailed articles on Andre's
site.


> Is any hosting provider doing this effectively?
>

You may also want to look into the Aegir hosting system for Drupal.

http://groups.drupal.org/aegir-hosting-system

And then you can present your findings/experience in the Drupal Waterloo
Group!

John Van Ostrand
> Net Direct Inc.
>
> CTO, co-CEO
> 564 Weber St. N. Unit 12
> map
>
> Waterloo, ON N2L 5C6
>
> john at netdirect.ca
> Ph: 866-883-1172
> ext.5102
> Linux Solutions / IBM Hardware
> Fx: 519-883-8533
>
>
>
> _______________________________________________
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at kwlug.org
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
>



-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20100208/7b8f0710/attachment.htm>