Changes between Version 1 and Version 2 of faq/drupal/configuration

Timestamp:

Mar 25, 2008, 5:59:24 PM (17 years ago)

Author:

Daniel Kahn Gillmor

Comment:

--

faq/drupal/configuration

@@ -3 +3 @@
 May First/People Link has one installation of Drupal on each of our shared servers. All sites running Drupal have the option of using this single copy of Drupal. The advantage of this approach is that when a security patch is released for Drupal that fixes a vulnerability, we can apply the patch in one place and everyone who is using our single copy of the Drupal source will immediately benefit from the patch.
 
-How does it work?
+== Why not use traditional drupal "multi-site"? ==
 
-Drupal has a method for running more than one web site using the same core Drupal source. It's called "multi-site." Using multi-site - you can place as many directories in your Drupal sites directory as you want, each one named after the domain name of the separate site you want to create. 
+Drupal has a method for running more than one web site using the same core Drupal source. It's called "[http://drupal.org/node/43816 multi-site]". Using multi-site, you can place as many directories in your Drupal sites directory as you want, each one named after the domain name of the separate site you want to create. 
 
 We do not use this approach for two reasons:
 
- * It means everyone has to use the same DocumentRoot - you cannot, for example, add your own robots.txt file or decide you want to customize your .htaccess file
+ * It means everyone has to use the same DocumentRoot - you cannot, for example, add your own `robots.txt` file or decide you want to customize your `.htaccess` file
  * It does not work with suPHP - a security mechanism that restricts the permissions of your Drupal installation to just your account. When using multi-site, a vulnerability in one site can be used to do damage to another site on the same server.
 
 In short, the multi-site approach is both restrictive and insecure.
 
+== How does the MF/PL approach work? ==
+
 Our approach uses symlinks instead. It is designed to work with suPHP, in which the PHP process running runs with the privileges of the user who owns the file.
 
-Using our approach, every member has their own web directory, which they control. The web directory contains symlinks to all the top level directories in Drupal core (includes, misc, etc.) except for the files and sites directories - these are real directories under the control of the user. In addition, each top level file (index.php, cron.php, etc) is symlinked in the user's web directory, but with the name index.drupal.php, cron.drupal.php. Finally, every top level file is created and owned by the user with the original Drupal name (index.php, cron.php) and with a simple one line of php code which includes the Drupal symlink. For example, index.php contains: "require_once('index.drupal.php');". An example web directory listing looks like this:
-
+Using our approach, every member has their own web directory, which they control. The web directory contains symlinks to all the top level directories in Drupal core (`includes`, `misc`, etc.) except for the files and sites directories - these are real directories under the control of the user. In addition, each top level file (`index.php`, `cron.php`, etc) is symlinked in the user's web directory, but with the name `index.drupal.php`, `cron.drupal.php`, etc. Finally, every top level file is created and owned by the user with the original Drupal name (`index.php`, `cron.php`) and with a simple one line of php code which includes the Drupal symlink. For example, `index.php` contains:
+{{{
+require_once('index.drupal.php');
+}}}
+An example web directory listing looks like this:
 {{{
 0 jm@chavez:web$ ls -l