[consulting] Drupal site development but with restrictions

[Owen Barton]

Another consideration in forcing multiple disparate sites into a single
docroot (that don't otherwise want/need to be a multisite) is that it
introduces some security tradeoffs, because the sites often cannot be
effectively isolated from one another: all the sites normally end up
running under a single system user account (and can read each others
settings.php for example) - meaning that if one site is compromised then
they are all are.

Thanks!
- Owen

On Mon, Aug 20, 2012 at 2:57 PM, Ryan Cross <drupal at ryancross.com> wrote:

> With a bit of experience from a client who basically did the same thing,
> and also reading between the lines a bit, I think this an awkward mix of
> cost-based and policy-based decision making from people not knowledgable
> about the details.
>
> For an Acquia managed cloud service, they charge an additional
> (substantial) $ figure for each additional webroot. So, it seems people are
> either told/sold or come to their own conclusion that they can save money
> and support multiple sites with a single webroot and Drupal's multisite
> capabilities. However, the client doesn't seem to always understand that
> this effectively slows down their innovation and delivery cycles by
> requiring any deployments of code to go out to all their sites (and thus
> requires extensive testing across multiple sites for even a small change
> intended only for a single site). This is also coupled with a common sense,
> risk mitigation policy, which proposes that there is a vetted / approved
> set of code that can be used and any deviations are a no-no.
>
> A few points of advice:
>
>    - As mentioned, make sure that the client understands what they are
>    getting into.
>       - Point out how the perceived cost savings of this approach will
>       likely limit their options down the line and/or cost them more over all.
>       - Advocate heavily against this approach, but address their
>       concerns in alternate ways.
>    - Suggest/insist that they define a policy/procedure around getting
>    new modules approved and custom modules & patches approved as well.
>       - Don't forget to point out that Acquia's support model is
>       specifically there to cater for ALL modules (including custom code and
>       patches), so in this way they are "covered"
>       - Also indicate whether they have the capabilities to review and
>       judge code and their ability to turn around approvals on new code (they
>       will probably realize they don't have this and back off a bit)
>    - Find other "providers" who will working with the client (perhaps
>    internal staff members) and will also be subject to this new approach and
>    get them to support and reiterate the concerns with this approach.
>       - You might be able to figure out who originally proposed this and
>       get some understanding of their motivations/rationale. Then either help
>       them understand the problems this will impose and/or help address their
>       motivations with alternative solutions.
>
>
>
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20120820/91d23a47/attachment.html