[development] Multisite risks (formerly multisite complication)

Steven Jones steven.jones at computerminds.co.uk
Sun Nov 14 17:13:50 UTC 2010


One consideration with multisites is that if you allow a user to use
PHP in Drupal (block visibility, input format, etc.) then they will be
able to read the settings.php for all your sites, and thus connect to
all the databases.
Aegir uses 'cloaked' credentials to handle this, putting the database
details in the vhost files, and then just pulling those into the
settings.php file for Drupal.

Regards
Steven Jones
ComputerMinds ltd - Perfect Drupal Websites

Phone : 024 7666 7277
Mobile : 07702 131 576
Twitter : darthsteven
http://www.computerminds.co.uk



On 13 November 2010 22:58, Cameron Eagans <cweagans at gmail.com> wrote:
> In any case, multisite is a good thing, I think. Updates are a piece of
> cake, but you should keep two codebases around. Put all of your multisites
> on codebase A and let them run for a while. When updates are available, pull
> the updates down on codebase B and move your site directories over one by
> one and run update.php. It's a good process, and it's easily scriptable. It
> also happens to be the same process that Aegir uses (more or less).
> Thanks,
> Cameron
>
>
>
> On Sat, Nov 13, 2010 at 13:33, Chris Skene <chris at xtfer.com> wrote:
>>
>> All the previous points about Multisite and its advantages/disadvantages
>> are valid, however in your case, as you plan to zap the database regularly
>> and it doesn't sound like data integrity is important, I would probably
>> start with multisite as well.
>> I will add, that if you are using APC to improve performance, multisite
>> has big performance benefits over separate codebases, as APC will reuse all
>> the files. The benefits are partly lost with separate code bases.
>> Either way, however, I would use git to manage the platform off a separate
>> repository.
>> Chris Skene
>> chris at xtfer.com
>>
>> On 14/11/2010, at 2:56 AM, jeff at ayendesigns.com wrote:
>>
>> I don't know. I'll try that out. In thinking this through, another
>> question sprung to mind:
>>
>> If these categories are going to be various demos, with the intent of
>> pushing a database overwrite hourly to repair any pummeling done via users
>> playing with the admin panel, are there risks in them sharing the same code
>> base with production multisite sites?
>>
>> On 11/12/2010 09:38 PM, Christopher Skene wrote:
>>
>> Does having a site folder called sub.domain.category_1 work? You may need
>> a symlink in your root folder to this folder, called "category_1".
>>
>> On 13/11/2010 12:29 PM, <jeff at ayendesigns.com> wrote:
>>
>> Right, so sub.domain/category_1 would run off the same code instance as
>> sub.domain/category_2, but separate db's
>>
>> On 11/12/2010 08:23 PM, Christopher Skene wrote:
>> >
>> >
>> > So you want different sites on each categor...
>
>


More information about the development mailing list