Beneath the dark glass of the monitor glowed the faintest hint of green light. A little green square blinked in the corner like a pulsating heartbeat. The whine of cathodes was palpable.

About a dozen of us stared silently into the darkness of their own monitor, as if entering a trance. A voice from behind us broke the spell: “This is called the ‘cursor’.”

The room was long and narrow, the walls lined with computers. Everyone sat with their backs to each other; together yet alone. The only human interaction was through an occasional brush against the chair-back as the teacher slowly paced the room.

And thus we were introduced to the personal computer — sitting in front of us at almost half our size, returning its own perplexed and curious gaze.

It was probably an Apple IIe. The green phosphor screen, the raised keyboard, the giant floppy disk drives. I vividly remember the sound it made while reading the disc. It was the early 1990’s and I was about 10 years old. That particular model was nearing its end of life. But it would mark a beginning for mine.

Sometimes our trip to the computer lab involved playing a game as a small group. In retrospect, it was a team-building experience. We weighed the risks and rewards. We made decisions collectively. We shared successes and failures. And if it was Oregon Trail, we always failed.

One day our teacher presented us with an ambitious class project. We were to create our own book. Each student would come up with a short story and illustrate it themself. We experienced the entire publishing process: writing, editing and layout. When everyone’s story was finished, we waited for the books to be bound. On release day, everyone was presented their own copy and read their story in front of the class. What a sense of accomplishment!

Creative collaboration. It started in that little computer lab. It continues with every project I take on.

—Mark Chambers

Mark David Chambers

Drupal 7 Website Migration to Ubuntu 14.04 LTS Server

Written by Mark Chambers on

There are various ways of transferring files between Linux systems. scp uses encryption making it a good option when copying sensitive data between two remote locations. For this use case, rsync makes the most sense as we will be transferring files between development, testing and production servers all on the same local network.

In this guide I am moving a Drupal installation, but these instructions can be applied to any other use case.

1: Copying the files

We will be working on our new server, copying files to it from the old server.

In the following command, the first path denotes the source directory, the second is the destination directory (if it doesn't exist it will be created). However, /var/www/html/ should be there, as it is Ubuntu's default Apache web directory.

For user enter your source server’s admin user name. For remote.host enter the IP or domain name of your source server.

Note: Include the trailing slash on the source directory to prevent it from being created inside the destination directory. In other words, you can think of a trailing / on a source as meaning "copy the contents of this directory" into html as opposed to "copy the directory by name", which would result in html/example.com. Note, however, that the attributes of example.com (user, group, permissions) will still be applied to html.

sudo rsync -rlptDvz [email protected]:/var/www/vhosts/bigmarker.de/og.bigmarker.de/ /var/www/html/

Because of sudo, the permissions of all files will be root.

2: Fix file attributes

2.1: Make Apache root readable

sudo chmod 755 /var/www/html

2.2: Make web site files belong to dev

Go to webroot:

cd /var/www/html

find all root-owned files and directories and chown to dev:

find . -user root -group root -print0 | xargs -0 sudo chown -v -h dev:dev

2.3: Fixing Drupal’s various directories

Allow module updates:

sudo chown www-data:www-data /var/www/html/sites/default/

Allow Drupal to create new shared-site directories:

sudo chown www-data:www-data /var/www/html/sites/all

Allow Drupal to install modules, libraries and translations:

sudo chown -R www-data:www-data /var/www/html/sites/all/libraries
sudo chown -R www-data:www-data /var/www/html/sites/all/modules
sudo chown -R www-data:www-data /var/www/html/sites/all/translations

Allow Drupal users to save content:

sudo chown -R www-data:www-data /var/www/html/sites/default/files

Fix Composer Manager directory:

sudo chown dev:dev /var/www/html/sites/default/files/private/composer/composer.*

3: Copying the database

Opening your website in a browser should produce the follow:

PDOException: SQLSTATE[HY000] [1045] Access denied for user 'ogu'@'localhost' (using password: YES) in lock_may_be_available() (line 167 of /var/www/html/includes/lock.inc).

This is a good error. It’s looking for our database.

We will export a MySQL database from our old server, then import it to our new one.

3.1: Export database

To export, we need command line access on the old server.

For this example, we will assume our MySQL user name is ogu and our database name is og.

We will now export and compress the database in one command:

mysqldump -u ogu -p og | gzip -9 > /var/www/vhosts/bigmarker.de/ogdb.sql.gz

Enter password for the database user ogu.

Note: The -9 option is for max compression. But on extremely large databases, that could mean a longer compress time. Leave blank for the default level of 7, or pick another number.

3.2: Copy database to the new server

Going back to our command line for the new server:

sudo scp [email protected]:/var/www/vhosts/bigmarker.de/ogdb.sql.gz /var/www

3.3: Prepare MySQL for import

Log into mysql as root:

mysql -p

Enter the password you chose for MySQL during installation.

Now let’s create an empty database. We will again call it og so that Drupal's settings.php doesn't have to be changed:

CREATE DATABASE og;

Now we want to setup the same user and password for the database as we had on the old server. In our example we will call the user ogu. Be sure to replace 'password' with your password. The '' symbols must be included. 

CREATE USER 'ogu'@'localhost' IDENTIFIED BY 'password';

At this point ogu has no permissions to do anything. Let's fix that:

GRANT ALL PRIVILEGES ON * . * TO 'ogu'@'localhost';

For our changes to take effect, we run:

FLUSH PRIVILEGES;

That's it for now.

quit

3.4: Import database

From the directory containing the gzipped database, we can run this combined command:

gunzip < /var/www/ogdb.sql.gz | mysql -u root -p og

We just unzipped and imported all tables and rows into the empty database called og which we created before.

Now visit your site and you should come to the landing page.

4: Setup Apache

By default, Ubuntu’s Apache server ignores any .htaccess files which are in a web directory’s root and subfolders.

This results in being able to see the front page of your Drupal site, but coming no further than that. Trying to log in or access any other page may result in either a white screen or a server connection error.

4.1: Enable mod_rewrite

We need to activate mod_rewrite.

sudo a2enmod rewrite

This will activate the module or alert you that the module is already in effect

4.2: Allow changes from .htaccess

Open the default Apache configuration:

sudo vi /etc/apache2/sites-enabled/000-default.conf

Inside that file, you will find the <VirtualHost *:80> block on line 1. Inside of that block, add the following block:

<Directory /var/www/html>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>

Your file should now match the following. Make sure that all blocks are properly indented.

<VirtualHost *:80>
    <Directory /var/www/html>
        ...
    </Directory>
    ...
</VirtualHost>

4.3: Restart apache

To put our changes into effect, restart Apache.

sudo service apache2 restart

Your Drupal site should now let you further in.

5: Modifying the PHP Configuration

The Drupal Status page shows us a the PHP memory limit. To see other server variables, click on more information in the PHP row; this will take us to the phpinfo page.

Under “Core” we can see many of the variables we could change. We will modify some of the common ones now.

Rather that edit the main configuration file, we will create our own .ini file for overriding PHP's default settings.

To see where to put this, look at the row “Scan this dir for additional .ini files”. In my case it’s /etc/php/5.6/apache2/conf.d. That is where we will create our custom .ini file:

sudo vi /etc/php/5.6/apache2/conf.d/10-custom.ini

Add your overrides to the file. Mine are as follows:

memory_limit = 512M
max_execution_time = 60
post_max_size = 100M
upload_max_filesize = 100M

Restart the web server to enable the changes:

sudo service apache2 restart