On Mon, Feb 8, 2010 at 10:57 AM, <span dir="ltr"><<a href="mailto:john@netdirect.ca">john@netdirect.ca</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm noticing that have more and more Drupal sites. Most are internal but<br>
increasingly more and more are customer sites. We have been installing<br>
separate Drupal instances for each web site and it becomes time consuming<br>
to keep them all up-to-date and we risk becoming insecure if we miss one.<br>
<br>
I know that Drupal can handle multi-site hosting per instance and I'm now<br>
considering doing just that. It seems clear how to go about doing this,<br>
but I'm worried about the consequences.<br></blockquote><div><br>Drupal has multisite built in. All you need to do is to have a:<br><br>sites/<a href="http://example1.com/settings.php">example1.com/settings.php</a> <br>
sites/<a href="http://example2.com/settings.php">example2.com/settings.php</a> <br>..etc.<br><br>In each settings.php, you have it point to a different database.<br><br>All the shared modules and themes go into sites/all/modules and sites/all/themes. They are available to all sites.<br>
<br>All site specific files (user pictures, images, attachments, ...etc.) go into sites/<a href="http://example1.com/files">example1.com/files</a><br><br>Site specific modules go into sites/<a href="http://example1.com/modules">example1.com/modules</a> and sites/example1/themes.<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Does anyone know any gotchas in doing this?<br>
<br>
The multi-site hosting seems easy:<br>
<br>
- Install one copy with a generous assortment of useful (and active)<br>
modules and themes,<br></blockquote><div><br>Yes, they go in sites/all/modules and sites/all/themes. That way they shared<br>across all sites.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Create a sites/<a href="http://customer.com" target="_blank">customer.com</a> directory structure and matching Linux user<br>
so they can upload modules, themes and files,<br>
- Create a database,<br>
- Create an Apache config for the domain,<br>
<br>
This should allow customers to upload/download themes, additional modules,<br>
and control their own site's users and settings. They can use the base<br>
modules (in sites/all/modules) or add their own.<br></blockquote><div><br>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.<br>
They can download something insecure or leave stuff lagging and you have an attack vector on ALL sites.<br><br>You should kind of vet what modules they want, but not allow them to self <br>serve. That is unless you run PHP in a very restrictive way (suExec in CGI).<br>
<br>Another module you want to disable across all sites and physically remove<br>is the php module in 6.x. Otherwise, if one of your customers allows PHP in<br>comments, ALL your sites are insecure.<br><br>There is also a paranoia module that you may want to check out.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I could set up three instances, one for 5.x, 6.x and 7.x and put the<br>
user's sites/<a href="http://customer.com" target="_blank">customer.com</a> directory in whichever instance they want. Then,<br>
when needed, I'd only have to do one update to affect all sites for a<br>
given version. When a user wants to upgrade, we run through the upgrade<br>
process except move the sites/<a href="http://customer.com" target="_blank">customer.com</a> to the new instance, then run<br>
the update process to update their database.<br></blockquote><div><br>I do this for our sites. We use symlinks to point a site to the new version, so <br>we don't have to upgrade them all en masse, but rather one by one as time<br>
permits.<br> <br>Say all sites are hosted in /home/www/live, which is a symlink to a Drupal 6.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
One unique thing in this is that we most of our customers rely on us to do<br>
the web site administration, however we do have customers that work with<br>
their site at an content level (e.g. they don't change site-wide configs<br>
like modules, themes or such.)<br></blockquote><div><br>Means that they will not upload themes or modules either, which makes your server more secure.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We would have to concern ourselves with making sure some customers are<br>
prepped before upgrading.<br></blockquote><div><br>We had a presentation on upgrading in the fall at the Waterloo Region Drupal Users Group. You can get the slides from here <a href="http://groups.drupal.org/node/32558">http://groups.drupal.org/node/32558</a>. Also some detailed articles on Andre's site.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is any hosting provider doing this effectively?<br></blockquote><div><br>You may also want to look into the Aegir hosting system for Drupal.<br><br><a href="http://groups.drupal.org/aegir-hosting-system">http://groups.drupal.org/aegir-hosting-system</a><br>
<br>And then you can present your findings/experience in the Drupal Waterloo Group! <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
John Van Ostrand<br>
Net Direct Inc.<br>
<br>
CTO, co-CEO<br>
564 Weber St. N. Unit 12<br>
map<br>
<br>
Waterloo, ON N2L 5C6<br>
<br>
<a href="mailto:john@netdirect.ca">john@netdirect.ca</a><br>
Ph: 866-883-1172<br>
ext.5102<br>
Linux Solutions / IBM Hardware<br>
Fx: 519-883-8533<br>
<br>
<br>
<br>
_______________________________________________<br>
<a href="http://kwlug-disc_kwlug.org" target="_blank">kwlug-disc_kwlug.org</a> mailing list<br>
<a href="http://kwlug-disc_kwlug.org" target="_blank">kwlug-disc_kwlug.org</a>@<a href="http://kwlug.org" target="_blank">kwlug.org</a><br>
<a href="http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank">http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Khalid M. Baheyeldin<br><a href="http://2bits.com">2bits.com</a>, Inc.<br><a href="http://2bits.com">http://2bits.com</a><br>Drupal optimization, development, customization and consulting.<br>
Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra<br>Simplicity is the ultimate sophistication. -- Leonardo da Vinci<br>