Skip to main content

Drupal 7 multi-site installation


Background

This is a guide for setting up a multi-site Drupal configuration that I put together when re-installing a hosted server. I'm using Fedora 20 on the server so there are F20 specific individual instructions and commands. You may have to adjust these steps slightly for your specific distribution.

This multi site installation is a bit of a different approach from the official Drupal 7 (the version currently released) INSTALL.txt. Drupal does have a bunch of documentation around multi-site installations that you might want to look at.

The approach of this multi-site drupal configuration is to set up a series of per-site directories, databases and configurations. Some other approaches use a single database but this approach was chosen to make it easier to move or migrate a site from one server to another as well as to simplify upgrading Drupal with new releases.

For the purposes of this guide I’ve used {site1} and {site2} for the two sites. You can have as many sites as you’d like though, just repeat the sections for as many sites as you want.

The per-site directory layout looks something like:

/var/www/{site1}/
        drupal/ # site-specific configuration (drupal is pointed to this folder)
                settings.php
                files # symlink to /var/www/{site1}/files
        files/ # site-specific files
        htdocs # symlink to the common drupal install
/var/www/{site2}/
        drupal/
                settings.php
                files
        files/
        htdocs
…

Another aspect of this installation approach is the use of a separate ‘sites’ configuration. This enables modules and themes to be kept outside of the system drupal directory. This directory layout looks like: 
/etc/drupal/7/
        sites/
                all/
                default/
                {site1} # symlink to /var/www/{site1}/drupal
                {site2} # symlink to /var/www/{site2}/drupal
        private/
        profile/


/usr/share/drupal7/
        sites # symlink to /etc/drupal/7/sites

Install and configure services

> yum install httpd community-mysql-server
> yum install php php-pdo php-gd php-mbstring php-mysqlnd

> yum install php-devel gcc
> pecl install uploadprogress

# enable pecl uploadprogress extension in php by adding ‘extension=uploadprogress.so’ to /etc/php.ini

# start httpd and have it start at boot
> systemctl start httpd.service
> systemctl enable httpd.service

# start mysqld and have it start at boot
> systemctl enable mysqld.service 
> systemctl start mysqld.service

# enable firewall access for the web server
> firewall-cmd --zone=public --permanent --add-service=http
> firewall-cmd --zone=public --permanent --add-service=https
> firewall-cmd --reload
> firewall-cmd --list-all-zones
# You should see 'http' and 'https' listed in the 'public' zone

Drupal install

I chose to install Drupal from a .tar.gz from the Drupal website so I knew exactly where and what was being installed. You may want to use your distributions package manager to install Drupal rather than following these steps. You may have to poke around or read a bit to find out what/where things are installed if you end up going that route. 
# extract drupal
> cd ~/
> mkdir downloads
> cd downloads
> wget http://ftp.drupal.org/files/projects/drupal-7.28.tar.gz
> tar xvzf drupal-7.28.tar.gz
> mv drupal-7.28 /usr/share/drupal7

Setup the multi-site directories

> cd /var/www
> mkdir {site1}
> cd {site1}
> ln /usr/share/drupal7 htdocs -s
> mkdir files
> chown apache files
> mkdir drupal
> cd drupal
> ln /var/www/{site1}/files files -s
> cp /usr/share/drupal7/sites/default/default.settings.php settings.php
> chown apache settings.php

> cd /var/www
> mkdir {site2}
> cd {site2}
> ln /usr/share/drupal7 htdocs -s
> mkdir files
> chown apache files
> mkdir drupal
> cd drupal
> ln /var/www/{site2}/files files -s
> cp /usr/share/drupal7/sites/default/default.settings.php settings.php
> chown apache settings.php

...
Repeat this approach for as many sites as you would like to host.

Apache configuration

edit /etc/httpd/conf/httpd.conf to add: 
# Virtual hosts
Include conf/vhosts.conf

create /etc/httpd/conf/vhosts.conf 
<VirtualHost *:80>
        ServerName {site1}
        ServerAlias *.{site1}
        DocumentRoot "/var/www/{site1}/htdocs"

        RewriteEngine on
        # map ip only requests to this site by default
        # NOTE: It would be nice to use ${SERVER_ADDR} on the right hand side
        #       but this doesn't work. So use the server's ip address instead, with
        #       dots escaped with \
        RewriteCond %{HTTP_HOST} ^123\.321.\123.\321$
        RewriteRule ^/(.*) http://{site1}

        <Directory "/var/www/{site1}/htdocs">
                Options Includes FollowSymLinks
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
</VirtualHost>


<VirtualHost *:80>
        ServerName {site2}
        ServerAlias *.{site2}
        DocumentRoot "/var/www/{site2}/htdocs"
        RewriteEngine on
        <Directory "/var/www/{site2}/htdocs">
                Options Includes FollowSymLinks
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
</VirtualHost>

Create the ‘sites’ structure outside of the drupal install directory

Placing the 'sites' directory outside of the install directory can make it easier to backup and restore the site-wide configuration of modules and themes and can reduce the risk of overwriting your sites files when upgrading Drupal. 
> mkdir /etc/drupal/7/sites
> mkdir /etc/drupal/7/private
> chown apache /etc/drupal/7/private

> cd /usr/share/drupal7
> mv sites sites.old
# symlink in /usr/share/drupal7 of ‘sites’ to /etc/drupal/7/sites
> ln /etc/drupal/7/sites /usr/share/drupal7/sites -s

> cd /etc/drupal/7/sites/
> mkdir default
> cp /usr/share/drupal7/sites.old/default/default.settings.php /etc/drupal/7/sites/default
> ln /var/www/{site1}/drupal {site1} -s
> ln /var/www/{site2}/drupal {site2} -s

Creating mysql database and accounts

Setup {site1}

Create database

> mysql
create database {site1}_drupal;
create user ‘{site1}_user’@’localhost’;
set password for ‘{site1}_user’@’localhost’ = password({site1_password});
grant all on {site1}_drupal.* to ‘{site1}_user’@’localhost’;

Perform Drupal setup

Visit the url for {site1} in your web browser and run through the installation.

Setup {site2}

Create database

> mysql
create database {site2}_drupal;
create user ‘{site2}_user’@’localhost’;
set password for '{site2}_user'@'localhost' = password('{site2_password}');
grant all on {site2}_drupal.* to '{site2}_user'@'localhost';

Perform Drupal setup

Visit the url for {site2} in your web browser and run through the installation.
Labels:

Comments

Post a Comment

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr
5 comments
Read more

Graco Swing By Me - Battery to AC wall adapter modification

If you have one of these Graco battery powered swings you are probably familiar with the cost of C batteries! The swing takes four of them and they only last a handful of days. I'm not sure if the newer models support being plugged into the wall but ours didn't. If you are a little familiar with electronics and soldering, here is a rough guide on how you can modify yours to plug in! I wasn't sure how exactly to disassemble the swing side where the batteries were. I was able to open up the clamshell a bit but throughout this mod I was unable to determine how to fully separate the pieces. I suspect that there is some kind of a slip plate on the moving arm portion. The two parts of the plastic are assembled and the moving arm portion with the slip plate is slid onto the shaft. Because of the tension in that slip plate it doesn't want to back away, and because of the mechanicals that portion of the assembly doesn't appear accessible in order to free it. I was
Post a Comment
Read more

Memory efficient queuing of variable length elements

In embedded environments memory can be a critical driver of the design of data structures and containers. Computing resources have been expanding steadily each year but there are still a wide range of systems with far less than a megabyte of memory. On systems with tens of kilobytes of memory, structures are often designed to be compact to maximize data density. Rather than splurging on memory aligned elements that would be faster for the processor to access, a developer will typically use types with minimal sizes based on the known range of values that the element is intending to hold. Fixed sized buffers At my day job a fixed size pool of messages was implemented to hold message data. While this achieved one design goal of using statically allocated buffers, avoiding dynamic allocations that might fail at runtime, it isn't efficient if there is a wide range of message sizes. It isn't efficient because each message uses a message buffer. With small message sizes the buff
2 comments
Read more