• Sales: 1-800-961-2888
  • Support: 1-800-961-4454

Adding an Additional WordPress Site to an Existing WordPress Deployment


This tutorial walks through the process of manually adding an additional WordPress site to an existing WordPress Deployment on Cloud Servers.

Note that in most situations, it's better to create a new WordPress Deployment for each site. This allows for better performance, security, and scalability, and is much easier to manage. Furthermore, creating a new WordPress Deployment is a simple process involving just a few clicks through the Cloud Control Panel.

Adding a site to an existing Deployment requires changes to the configurations for multiple services. The effort may be acceptable when the existing Deployment runs well under capacity or when you're trying to minimize the number of server instances you maintain.

Connect to the Backend Server

  1. Log in to the Cloud Control Panel. From the Servers tab, select Deployments.

    Deployments selection in the Cloud Control Panel

  2. From the Deployments list, click on the name of the Deployment you would like to add an additional WordPress site to.

    List of Deployments in the Cloud Control Panel

  3. From the list of servers, click the name of the "backend" server to view its details page.

    List of servers in the Deployment with the master node highlighted

    On the backend server's detail page, you will find the PublicNet IP address in the Networks section.

  4. Use the public IP address from the server details page and the private key provided with the Deployment to ssh to the backend server.

    ssh root@<ip_address_of_backend_server> -i /path/to/key
    

    If you do not have the private key, you can reset the backend server's root password. For help connecting to your server via ssh, please see the articles on using ssh with a private key in our Knowledge Center for Mac and Linux or Windows.

Database Setup

  1. After logging in, run the mysql command to connect to MySQL.

    mysql
    
  2. Create a database for the new WordPress site with the create database command in the MySQL shell. For this example we'll call the site "blogsrock.rackspace.com".

    create database blogsrock_rackspace_com;
    
  3. Create a user and password for this site. Please use a strong password (not like the one in this tutorial).

    grant all on `blogsrock_rackspace_com`.* to 'blogsrock'@'localhost' identified by 'mystrongpassword';
    
  4. Grant access for this user when connecting from our web servers. For this tutorial we are going to grant access to all 10.x.x.x IP addresses; however, for additional security, you can replace this with the specific ServiceNet IP addresses of your web servers.

    grant all on `blogsrock_rackspace_com`.* to 'blogsrock'@'10.%' identified by 'mystrongpassword';
    
  5. When you are finished, type exit to leave MySQL and type exit again to disconnect from the backend server.

WordPress Setup

Now that the database is ready, we can begin installing WordPress on the master node.

  1. From the Deployment's detail page, click the link for the "master" server.

    List of Deployments with the backend node highlighted

    On the master server's detail page, you will find the PublicNet IP address in the Networks section.

  2. Use the IP address and private key to connect to the server via ssh.

    ssh root@<ip_address_of_master_server> -i /path/to/key
    
  3. After logging in, run cd /var/www/vhosts to navigate to the web directory.

    cd /var/www/vhosts
    

    The directory should contain subdirectories for any WordPress sites that are already configured on the server.

  4. Make a new directory for the new site, with WordPress subdirectories.

    mkdir -p blogsrock.rackspace.com/{conf,http_docs,.ssh}
    

    The new directory should contain subdirectories named conf, http_docs, and .ssh.

    # ls -l blogsrock.rackspace.com
    total 20
    drwxr-xr-x 5 root root 4096 Dec  3 16:23 ./
    drwxr-xr-x 4 root root 4096 Dec  3 16:23 ../
    drwxr-xr-x 2 root root 4096 Dec  3 16:23 conf/
    drwxr-xr-x 2 root root 4096 Dec  3 16:23 http_docs/
    drwxr-xr-x 2 root root 4096 Dec  3 16:23 .ssh/
    
  5. Once we have our directory structure, we can grab the latest WordPress tarball and extract it using wget and tar.

    wget http://wordpress.org/latest.tar.gz && tar --strip-components 1 -xvf latest.tar.gz -C http_docs/
    
  6. Change to the http_docs directory.

    cd http_docs/
    

    The extracted WordPress files should be present, including the wp-config-sample.php file.

  7. Copy the wp-config-sample.php file to make a new WordPress config file.

    mv wp-config-sample.php wp-config.php
    
  8. Edit the new configuration file and add some extras to help with file permissions and load balancing.

    For HTTP-only sites, you can easily make the necessary changes by running, all on one line:

    echo -e "define('FS_METHOD', \"direct\");\ndefine('FS_CHMOD_DIR', (02775 & ~umask()));\ndefine('FS_CHMOD_FILE', (0664 & ~ umask()));\ndefine('FORCE_SSL_ADMIN', false);\nif ( isset(\$_SERVER['HTTP_X_PROXY_PROTO']) && \$_SERVER['HTTP_X_PROXY_PROTO'] == 'HTTPS' ) { \$_SERVER['HTTPS'] = 1; }" >> wp-config.php
    

    If you are running an HTTPS site, run this command instead:

    echo -e "define('FS_METHOD', \"direct\");\ndefine('FS_CHMOD_DIR', (02775 & ~umask()));\ndefine('FS_CHMOD_FILE', (0664 & ~ umask()));\ndefine('FORCE_SSL_ADMIN', true);\nif ( isset($_SERVER['HTTP_X_PROXY_PROTO']) && \$_SERVER['HTTP_X_PROXY_PROTO'] == 'HTTPS' ) { \$_SERVER['HTTPS'] = 1; }" >> wp-config.php
    
  9. Generate new secure keys using the WordPress API.

    curl -q https://api.wordpress.org/secret-key/1.1/salt/
    

    You should get some output like this:

    define('AUTH_KEY',         'V}zrS|PsyH3]!p!AEufS{7:Jjy);(ooKx/aG-S6VWcpd3D47zc3Xr~2=.W3|Yfw:');
    define('SECURE_AUTH_KEY',  'w1|o-0:5i};kj&V1SY}2O[2MGTwo8NhoI2+Gmj!qDgG<~1A+*,DAQ?^0xO_&g%se');
    define('LOGGED_IN_KEY',    'Ce6g>+OA$u+-H5`/ZU|f#`=J,rb!.-^ayr20jG.BF$Q7q>]G&lPG nTS^Ox*mMET');
    define('NONCE_KEY',        'G$Or)@Rp%Im#eezD{P.P[/eMv9q_wNe+.GVt| y,rN~sA;`y@UY76S|J[p7-n*s&');
    define('AUTH_SALT',        '$iPgS$t^,h!=YSW0ju*jqmk!@eLAn<JM?tG/+5c=|-#[8*G7-mnp6HG!t{J3>o4u');
    define('SECURE_AUTH_SALT', 'ciy$1-c^X-mkb<2ULD7+ua;_kjd9ku&:bZX>}B-GnI5ITu`(q)]3{p#TQ)-:`w@c');
    define('LOGGED_IN_SALT',   'VE]+84A?6Qen-p`iuthBw;Cqh:z2-9)Rdcw2AY_7?W;D`W5T7ATmJHrK~}-1`e2E');
    define('NONCE_SALT',       'XV}nFzYqXJ}jr)tD2vZ`-|!w]f>3;*`?#U8*l(C:/*)w.cf}6i{Adw@,Yj7p(F?d');
    
  10. Edit the wp-config.php file to replace the default keys with the keys generated in the previous step.

    nano wp-config.php
    

    Replace nano in that command with your text editor of choice.

  11. Edit the wp-config.php file to replace the default database values with the database name, username, and password created in the previous section.

    The relevant section of the config file looks like this:

    // ** MySQL settings - You can get this info from your web host ** //
    /** The name of the database for WordPress */
    define('DB_NAME', 'database_name_here');
    
    /** MySQL database username */
    define('DB_USER', 'username_here');
    
    /** MySQL database password */
    define('DB_PASSWORD', 'password_here');
    
    /** MySQL hostname */
    define('DB_HOST', 'localhost');
    

    For the DB_HOST value, replace localhost with the ServiceNet IP address of the backend server.

  12. Download a script called wordpress-cli-installer that we will use to simplify the final steps of the WordPress setup.

    wget https://raw.github.com/nexcess/wordpress-cli-installer/master/wordpress-cli-installer.sh
    
  13. Run wordpress-cli-installer, passing it arguments for the site's base URL, title, admin email address, and WordPress location.

    sh wordpress-cli-installer.sh -b 'http://blogsrock.rackspace.com' -T 'BLOGS ROCK' -e 'admin@example.com' /var/www/vhosts/blogsrock.rackspace.com/http_docs/
    
  14. Remove the wordpress-cli-installer script.

    rm wordpress-cli-installer.sh
    

System Setup

Now we'll make some changes to the system to accommodate the new WordPress site.

  1. Create a new user for the site, setting the user's home directory to the new site's directory. For example:

    useradd -M -d /var/www/vhosts/blogsrock.rackspace.com -p 'mystrongpassword' -s '/bin/bash' -U -G www-data wp_user2
    
  2. Set up a new SSH key-pair for lsyncd connections between the master and backend nodes in the root user's .ssh directory.

    cd .ssh
    ssh-keygen -f id_rsa.lsyncd
    mv id_rsa.lsyncd.pub authorized_keys
    
  3. Change to the conf subdirectory of the new site.

    cd /var/www/vhosts/blogsrock.rackspace.com/conf/
    
  4. Copy any configuration files for the existing WordPress site to the new directory.

    cp /var/www/vhosts/iloveblog.rackspace.com/conf/* /var/www/vhosts/blogsrock.rackspace.com/conf/
    
  5. Change the name of the new config file to match the new site.

    mv iloveblog.rackspace.com__http.conf blogsrock.rackspace.com__http.conf
    

    If your site supports HTTPS you'll also need to rename the copied HTTPS configuration file.

    mv iloveblog.rackspace.com__https.conf blogsrock.rackspace.com__https.conf
    
  6. Edit the configuration file to use the domain name of the new site in place of the existing site.

    sed -i 's/iloveblog.rackspace.com/blogsrock.rackspace.com/g' blogsrock.rackspace.com__http.conf
    

    If your site supports HTTPS you'll need to make the same change to the HTTPS file.

    sed -i 's/iloveblog.rackspace.com/blogsrock.rackspace.com/g' blogsrock.rackspace.com__https.conf
    
  7. If your site supports HTTPS, you will need to change the SSL certificate being used in the new "https" file to point to the SSL certificate for the new site. Specific instructions for this step are beyond the scope of this tutorial.

  8. Set appropriate permissions for all the new site's directories and files. Replace wp_user2 with the name of the user you created for the site in the System Setup section of this tutorial.

    cd /var/www/vhosts/blogsrock.rackspace.com/
    chown -R wp_user2:www-data http_docs
    chown -R wp_user2:wp_user2 conf .ssh
    chmod 2775 http_docs
    find http_docs/ -type d -exec chmod 2775 {} \;
    find http_docs/ -type f -exec chmod 0664 {} \;
    

Apache Setup

Next we need to create an Apache virtual host config file for the new site.

  1. Change directory to Apache's sites-available directory.

    cd /etc/apache2/sites-available
    
  2. Copy the existing site's configuration file for the new site.

    cp iloveblog.rackspace.com.conf blogsrock.rackspace.com.conf
    
  3. Edit the new virtual host configuration file to change any domain references for the new site.

    sed -i 's/iloveblog.rackspace.com/blogsrock.rackspace.com/g' blogsrock.rackspace.com.conf
    

Varnish Setup

Just like Apache, we need to copy the existing site's Varnish config to a new file and change the domain name it looks for as well.

  1. Change to the Varnish include directory.

    cd /etc/varnish/include/
    
  2. Copy the existing site's configuration file for the new site.

    cp iloveblog.rackspace.com_.vcl blogsrock.rackspace.com_.vcl
    
  3. Edit the new virtual host configuration file to change any domain references for the new site.

    sed -i 's/iloveblog.rackspace.com/blogsrock.rackspace.com/g' blogsrock.rackspace.com_.vcl
    

Lsyncd Setup

Now we need to add the new site to our lsyncd configuration so that the master server knows to push content for the new site to the slave servers.

  1. Change to the lsyncd configuration directory.

    cd /etc/lsyncd/
    
  2. Open the lsync.conf.lua file for editing to add a node for the new site.

    nano lsync.conf.lua
    

    Replace nano in that command with your text editor of choice.

  3. For each slave server in the WordPress Deployment, make a new sync section, changing the source value to match the new site, the target value to match the new system user, and changing the directory reference in the excludeFrom value.

    The lsync.conf.lua file consists of a settings section followed by one or more sync sections, one for each slave site. Since our example Deployment only has one slave, we only have to add one new sync section. You can copy the existing sync section then modify the directory references and username in the new section to match the new site.

    For our example site, the edited file looks like this:

    settings = {
       logfile    = "/var/log/lsyncd/lsyncd.log",
       statusFile = "/var/log/lsyncd/lsyncd-status.log",
       statusInterval = 5,
       pidfile = "/var/run/lsyncd.pid"
    }
      sync{
            default.rsync,
            source="/var/www/vhosts/iloveblog.rackspace.com/http_docs",
            target="wp_user@<slave_node_ip_address>:/var/www/vhosts/iloveblog.rackspace.com/http_docs",
            excludeFrom="/etc/lsyncd/lsyncd.exclude",
            rsyncOps={"-rlpgoDvz", "-e", "/usr/bin/ssh -i /var/www/vhosts/iloveblog.rackspace.com/.ssh/id_rsa.lsyncd -o StrictHostKeyChecking=no"}
      }
      sync{
            default.rsync,
            source="/var/www/vhosts/blogsrock.rackspace.com/http_docs",
            target="wp_user2@<slave_node_ip_address>:/var/www/vhosts/blogsrock.rackspace.com/http_docs",
            excludeFrom="/etc/lsyncd/lsyncd.exclude",
            rsyncOps={"-rlpgoDvz", "-e", "/usr/bin/ssh -i /var/www/vhosts/blogsrock.rackspace.com/.ssh/id_rsa.lsyncd -o StrictHostKeyChecking=no"}
      }
    

Slave Setup

Next, we need to create the new user on each slave node in order to prepare for the new site. To do this, we are going to setup the Deployment's SSH key (the one we used to log in to each node) on the master server and use pssh to make the process faster.

  1. Edit root's private key file to add the Deployment's SSH private key.

    nano ~/.ssh/id_rsa
    

    Replace nano in that command with your text editor of choice.

  2. Add the Deployment's SSH private key to the file and save the change. If the file isn't empty, add the key on a new line at the end of the file.

  3. Change permissions on the key file so only root can access it.

    chmod 600 ~/.ssh/id_rsa
    
  4. Install pssh on the master server.

    apt-get update
    apt-get install pssh
    
  5. Run pssh to add the new user to each slave server. Note that the -H flag here is only used once, but you should repeat it for each additional slave node you have.

    parallel-ssh -P -H <ip_address_of_slave_node> -x "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null" useradd -M -d /var/www/vhosts/blogsrock.rackspace.com -p 'mystrongpassword' -s '/bin/bash' -U -G www-data wp_user2
    

    You should see pssh report SUCCESS for each slave node.

  6. Run an id command through pssh to verify the user creation on each slave node, again adding -H flags for each additional slave node.

    parallel-ssh -P -H <ip_address_of_slave_node> -x "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null" id wp_user2
    

    You should see something similar to the following from each slave node:

    uid=1001(wp_user2) gid=1001(wp_user2) groups=1001(wp_user2),33(www-data)
    
  7. Copy the new site's content from the master server to each slave server using rsync.

    rsync -avz -e ssh /var/www/vhosts/blogsrock.rackspace.com root@<slave_node_ip>:/var/www/vhosts
    

    Repeat the rsync for each slave node in your Deployment.

  8. Copy the Apache and Varnish configuration files to the slave nodes.

    To make things easier we'll use a loop with the parallel-scp command (part of the pssh package). Add extra -H flags for each additional slave node.

    for file in /etc/apache2/sites-available/blogsrock.rackspace.com.conf /etc/varnish/include/blogsrock.rackspace.com_.vcl; do parallel-scp -H <ip_address_of_slave_node> -x "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null" $file $file; done
    

This is the Final Countdown

Now we can finally start putting everything together and run the new site.

  1. Restart lsyncd on the master node in order to start syncing content for the new site to the slaves.

    /etc/init.d/lsyncd restart
    
  2. Enable the new site's Apache configuration on the master server and slave nodes.

    parallel-ssh -i -H <ip_address_of_slave_node> -x "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null" /usr/sbin/a2ensite blogsrock.rackspace.com.conf; /usr/sbin/a2ensite blogsrock.rackspace.com.conf
    
  3. Reload Apache's configuration on the master server and slave nodes.

    parallel-ssh -i -H <ip_address_of_slave_node> -x "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null" service apache2 reload; service apache2 reload
    
  4. Reload Varnish's configuration on the master server and slave nodes.

    parallel-ssh -i -H <ip_address_of_slave_node> -x "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null" service varnish reload; service varnish reload
    

Congratulations, your new site is online!







© 2011-2013 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


See license specifics and DISCLAIMER