Creating Sites Directories

+1

Is there a reason the multi site module does not create a sub folder in the site folder for every new site?
Yes. The reason is that it's a big security hole/risk if your sites directory (and drupal base code) is writable by the web server. These directories should be read-only.

Instead multisite-manager works so that you only need a SINGLE directory for all the sites--this default directory is used for all of them (but you can make explicit exceptions by making a directory for a specific sub-site)

So, properly configured, multisite manager does not require any post-site-creation administrative action for the site to be ready.

This is a much better and secure setup than something that scripts the building of a new directory, each time.

If I understand correctly, if you share the settings.php folder among all the sites, you can not use multiple databases.

I am interested because I have a search function in one of my modules (hotel module) and it pulls results from all sites, not just the site in which the site was run. I there need to separate my databases or modify the module. I want site creation to an automated process and not need any file creation...

If I understand correctly, if you share the settings.php folder among all the sites, you can not use multiple databases.
That's not correct. settings.php is WHERE you specify the database. But it's a PHP script, so my approach in Multisite Manager is we put some logic into the SINGLE settings.php which decides the database. There's a little page when you install the module to help create that script, and I think the INSTALL file still has an ugly example.

http://drupalcode.org/viewvc/drupal/contributions/modules/multisite_mana...

It's an obscure feature, but Drupal supports accessing certain tables from separate DBs (see the documentation in the default settings.php file). It sounds like if it's not too late, you might want to do that with your hotel module.

Just a random contribution:
Although webserver-writable code is indeed a huge risk on shared hosts, this security gap is much much smaller on stand-alone VPS hosting where you have no neighbours to worry about. IMO.

I've done a system where my client can invent sites (almost) on the fly a bit like is described in the OP.

But anyway, although you may not need Aegir (only a handful of people in the world do) you can maybe take a lesson from what it does.
It creates a queue of actions that need to be run by a privileged user, but does not do them itself.

So your webserver can create a text file in its files dir 'sites_to_be_created.info' or something, containing the URI/identifier of the site dir you want.
And you can run a cronjob every minute as a higher user that can create (I just copy from a sites/template dir) the new subsite and set up permissions securely. (and remove the task from the queue)

You've covered most of your bases that way. Be sure to not get tempted to put code logic into your txt file though :-)
... just an abstract thought for you.

I'll grant you it's a HUGE risk if the host is shared (an environment which we work on), but the risk on a stand-alone host just means your code/system is the exposure liability. Considering the number of security notices that come out for Drupal and many Drupal modules, I don't think this is minimal. (I think drupal is pretty robust, but the module system means that your system is as weak as any of your modules).

It creates a queue of actions that need to be run by a privileged user, but does not do them itself.
You can setup Multisite Manager to do this. It was a contributed feature, so looking at where it is, it's not surprising that it's not so visible, but if you make an entry in your {variables} table so variable_get('multisite_manager_install_immediate') returns FALSE, then you can place the file multisite_manager.admin.inc in your base drupal directory and run it as a privileged (database) user. If anyone wants to document this better here: http://drupal.org/node/427804 that would be awesome :-) and I'll take a patch that better documents this in INSTALL and maybe exposes it in the Help section.

I think a single settings directory is much nicer in addition to the added security benefit. Why create tons of near-identical files on the file system, when you can have one centralized one--especially when Drupal (along with my module :-) makes it super easy to do overrides when it's useful.

But, though I haven't investigated Aegir, I'm sure it has it's uses. The Drupal module system is all about that--use the module that fits your use case.

cheers,
sky

ah, it's been a while since I looked at the code. It's in the admin settings, and then you have to use multisite_manager/admin/multisite_manager_batch_install.php

Sounds good, it's a valid approach, nice to know it's been tried.

Why create tons of near-identical files on the file system, when you can have one centralized one
<digression>
Different requirements, that's all. I needed to be able to create site instances in one place, develop them up, then migrate them individually to a different multisite 'silo'. To treat them as individually portable, with their own /files dir and occasionally their own theme. So pretty much standard Drupal multisite advantages.
Meshing them to closely with their context doesn't suit me. I like to be able to back up a stand-alone site instance by zipping its site dir+db.

But the first few steps were for rapid prototyping and build, and there it much resembled the multisite manage features, creating instances through the web UI.
I can't speak for the current version of multisite manger, though I evaluated it a long time ago, it just didn't quite mesh with the approach I was taking.

Also, because the 'create' phase was on a private dev server, I was confident about the security aspect in this case. Even though I believe it's mostly OK in some cases, I still would try not deploy web-writable code on a live site!