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

Travelling on Spirit airlines out of Boston Logan airport? Here are some tips.

I attended CES 2017 in Las Vegas. Booking the trip late I ended up on Spirit airlines. It was both non-stop, making it six hours to Las Vegas from Boston, and affordable, less than $300 for a one way trip compared to around $700 with JetBlue. Here are some tips that might help you when travelling on Spirit from Boston Logan airport. Eat Spirit is located in the B-terminal, gates B-37 and 38, with its own TSA security checkpoint. While it does have restrooms and places to sit the food selection is limited to a single food stand. I'd recommend eating at the Legal C Bar (number 77 in the image below) prior to going through the terminal security checkpoint. The food and service there were great. Drink The water and other drinks are cheaper if you buy them at the food cart rather than on the flight. Seats The seats on Spirit don't recline. They do this to reduce weight, seat cost, seat maintenance costs, and so seats don't impact the free space of other passengers,...
3 comments
Read more

Yocto recipe SRC_URI for a BitBucket / GitHub ssh git repository

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing  Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...
2 comments
Read more