ToddGee.commie

I have created a nifty set of scripts for managing collections of Drupal installations.  I find them indispensable for maintaining a large stable of Drupal sites. The scripts allow for automated install and patching of Drupal installations as well as a host of other administrative tasks.  They enforce and leverage my best practices for Drupal deployments.

See the README for full information on the scripts within the library as well as usage guidelines:
http://svn.toddgee.com/drupalScripts/README

One thing I've often wished for is the ability to insert user-written CSS into a page or set of pages on a Drupal site.

It would: 

Found this site with cool, free site templates offered
http://www.ramblingsoul.com/
 
Another:
http://themebot.com/website-templates/drupal-themes

Some links to themes I like:
http://drupal.org/project/affaires
http://themegarden.org/drupal50/?q=node&theme=thirteen
used for http://friendsofgoetheschool.org/
http://drupal.org/node/204929
used for http://chicagobiketrailers.org

While doing a search for the AC site, I found the following javascript wysiwyg editors:

YUI
Review
Couldn't find a demo. Seems to have detractors (see review comments). Doesn't seem to play with the IMCE file uploader (whatever that is).

Introduction

When I first signed up for DreamHost account, I understood, but wasn't overly fond of the way they ran web requests.

All requests to a deployed website on DreamHost are made in the context of the user owning the website.  That is, if a website is deployed under user 'X', calls into that website are performed as user 'X'.  This allows DreamHost to isolate security breaches to the user of the (defective) website.  However, this also has implications for those who use canned software (like Drupal) -- if a defect is found and a website is comprimised, files within that software could be modified as the call is done as the owning user.  Setting restrictive permissions on the file doesn't help as the files are owned by the calling user and (in a truly compromised environment) the file permissions could be modified.  On a traditional system, this wouldn't be an issue as web-initiated calls would be made by the (highly restricted) apache (et. al.) user with permission to only read (and not write) only those files to which it needed to have access.

What follows is the scheme I ended up coming up w/ to work around this issue.  (Other issues continue to exist of course, this is just my solution for this one particular one.)  In this discussion, I'll talk about Drupal sites; but the scheme is the same regardless of what files are deployed on a site.  The initial setup had only my primary user that owned all sites and files.  The files for my Drupal site ("site") were kept in a directory webroot/drupal/<sitename> (relative to the primary user's home directory).