We are looking at developing an enterprise Drupal architecture using multisite as the overall hosting solution. We have setup a proof of concept with multisite and it works great. The more complicated step is having some modules that need to be not only available to all sites, but also configured with specific settings when the site is deployed. For example, we will want to have CKEditor available for all sites, but also configured a specific way and be enabled automatically. Making it available in the /sites/all/modules folder works great, it is that automatically enabled and configured part that is troublesome.
Our sites will be hosted using subfolders, not subdomains, so the Domain module will not work for us. At this point, we are thinking of creating a site configured the way we want, then doing a database dump for it. Then when we provision a new site, create it using the database dump as that will have everything configured. This is less than ideal not only for having to tweek database info, but as we bring new modules online, we will want to enable them for all existing sites.
Any ideas would be welcome
Comments
You might look into either
You might look into either Installation Profiles: http://drupal.org/project/installation+profiles
Or the Features module http://drupal.org/project/features
Features; we have a similar
Features; we have a similar situation which is part of why I wrote the Network Manager (http://drupal.org/project/network_manager) module. It doesn't automate the syncing of settings and things but it's a good information / decision engine to help you get things synchronized. Also, if you want to get really crazy, you could start sharing some tables across installs / DBs so that you don't have to maintain them as much. We do this with users so we're not creating accounts everywhere in our "network" of sites.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
+1 Features +1 Installation Profile and Drush
Database dumps is quite an outdated way of maintaining base configurations for Drupal sites.
As mentioned by jastraat you should consider Installation Profiles and the Features module.
Features allow you to dump configuration out to code, which makes it easier to maintain and track. You should also consider using strongarm with Features.
Installation Profiles allow you do define base site configurations which can be replicated many times.
Drush will allow you to run actions against allow of your sites using the command line.
Why are you using subdirectories rather than subdomains? Although you have the overhead of managing the DNS, subdomains provide a lot more flexibility as your project grows.
I would strongly recommend against sharing any tables between sites, it reduces flexibility and makes upgrading to any new major of Drupal very painful.
Subdomains vs folders
The short answer is, that decision is not under my workgroup's control, and politics makes it a non-starter.
Aegir
Take a look at the latest Aegir too. Allows you to deploy multiple sites onto a platform (installation of Drupal core). It can bulid the profile on the fly using drush_make so you can specify all the modules/themes/libraries that you want in sites/all. You can then migrate/clone your sites between platforms. This is what leveraging at UC Berkeley.
You may want to figure out:
Aegir info: http://developmentseed.org/taxonomy/term/664/feed
Re: Aegir
Ordinarily I would recommend aegir for such a project, but in this case the requirement is for sites to be deployed to sub directories, not sub domains. I can see this getting pretty ugly fast, but that is one of the requirements stated by the OP.